AIエージェントに「記憶」を与える ― Icarus Memory Protocolの全貌

出典: note.com / 2026-03-31

AIエージェントに「記憶」を与える ― Icarus Memory Protocolの全貌

2026年、AIエージェントは驚くほど賢くなった。コードを書き、文章を生成し、データを分析する。だが、彼らには致命的な弱点がある。

記憶がない。

セッションが終われば、すべてを忘れる。昨日あなたと何を話したか、どんなタスクを完了したか、何を学んだか──何ひとつ覚えていない。まるで毎朝、記憶喪失で目覚める人間のようだ。

さらに深刻な問題がある。複数のAIエージェントを同時に走らせている場合、彼らは互いの存在すら知らない。エージェントAが3時間かけて調査した結果を、エージェントBはゼロから調べ直す。エージェントCが発見したバグの修正方法を、エージェントDは知らないまま同じバグに苦しむ。

これは単なる不便ではない。AIエージェントが本当の意味で「チーム」として機能するためには、記憶の共有が不可欠だ。人間のチームだって、メモを共有し、引き継ぎ書を残し、Slackで情報を流す。AIエージェントにも同じ仕組みが必要なのだ。

この問題に、驚くほどシンプルな解決策を提示したプロジェクトがある。Icarus Memory Protocolだ。

Icarus Memory Protocolとは何か

Icarus Memory Protocolは、@IcarusHermes（Hermes開発コミュニティ）によって2026年3月に公開されたオープンソースプロジェクトだ。GitHubリポジトリは github.com/esaradev/icarus-daedalus で、公開からわずか数週間でStar 179、Fork 11を獲得している。

このプロトコルの設計思想は、拍子抜けするほどシンプルだ。

「~/fabric/ というフォルダにMarkdownファイルを書く。それだけ。」

データベースは不要。専用サーバーも不要。複雑なAPIも不要。ホームディレクトリの下に fabric というフォルダを作り、そこにMarkdownファイルを読み書きする。AIエージェントの「記憶」は、すべてこのフォルダの中のテキストファイルとして存在する。

コアのセットアップスクリプトはわずか50行程度のbashで完結する。以下がその概要だ。

── setup.sh（概要）──

#!/bin/bash

FABRIC_DIR=“$HOME/fabric”

mkdir -p “$FABRIC_DIR/hot”

mkdir -p “$FABRIC_DIR/warm”

mkdir -p “$FABRIC_DIR/cold”

mkdir -p “$FABRIC_DIR/relay”

mkdir -p “$FABRIC_DIR/training”

echo “Fabric directory initialized at $FABRIC_DIR”

────────────────────

たったこれだけで、AIエージェントに「記憶」が生まれる。このシンプルさこそが、Icarus Memory Protocolの最大の強みだ。

技術アーキテクチャ ― 3つの層で構成される記憶システム

シンプルとはいえ、Icarus Memory Protocolの内部設計はよく考えられている。大きく分けて、メモリ層、リレー層、ツール＆フック層の3つで構成される。

【メモリ層：YAML frontmatter付きMarkdownファイル】

記憶の最小単位は、1つのMarkdownファイルだ。各ファイルにはYAML frontmatter（ファイル先頭のメタデータ領域）が付いており、作成日時、作成者、タグ、優先度などの情報が構造化されている。具体的なファイルの例は後述するが、人間が普通のテキストエディタで開いて読める形式になっている。

【3階層ティアリング：hot → warm → cold】

Icarusの記憶管理で特徴的なのが、3階層のティアリング（階層化）だ。人間の記憶にも短期記憶と長期記憶があるように、Icarusの記憶にも「鮮度」がある。

**hot（24時間以内）：**直近の記憶。エージェントが最初に検索する領域。現在進行中のタスク、直近の会話内容、未処理の依頼などが格納される。ファイルは ~/fabric/hot/ ディレクトリに置かれる。

**warm（1〜7日）：**少し前の記憶。hotから時間が経過したエントリが自動的に移動される。まだ参照される可能性があるが、最優先ではない情報。~/fabric/warm/ に格納。

**cold（7日超）：**長期記憶。古いがアーカイブとして価値がある情報。~/fabric/cold/ に格納。検索対象にはなるが、通常の呼び出しでは自動的には参照されない。

この階層間の移動を自動で行うのが curator.py だ。cronジョブやsystemdタイマーで定期実行され、各エントリのタイムスタンプを確認し、閾値を超えたファイルを適切なディレクトリに移動する。

── curator.pyの動作イメージ ──

import os, shutil

from datetime import datetime, timedelta

HOT_THRESHOLD = timedelta(hours=24)

WARM_THRESHOLD = timedelta(days=7)

for entry in scan_entries(”~/fabric/hot/”):

age = datetime.now() - entry.created_at

if age > HOT_THRESHOLD:

shutil.move(entry.path, ”~/fabric/warm/”)

for entry in scan_entries(”~/fabric/warm/”):

age = datetime.now() - entry.created_at

if age > WARM_THRESHOLD:

shutil.move(entry.path, ”~/fabric/cold/”)

──────────────────────────

【リレー層：SQLiteベースのエージェント間メッセージキュー】

記憶の共有だけでなく、エージェント同士がメッセージをやり取りする仕組みも用意されている。それが relay.py だ。

relay.pyは ~/fabric/relay/ ディレクトリにSQLiteデータベースを置き、軽量なメッセージキューを実現する。エージェントAが「この調査結果を確認してほしい」というメッセージをキューに入れると、エージェントBがセッション開始時にそのメッセージを受け取る。

なぜメモリ層がMarkdownなのにリレー層はSQLiteなのか。これは合理的な設計判断だ。メッセージキューは「読んだら消す」一時的なデータであり、人間が読む必要がない。SQLiteのトランザクション保証とアトミックな読み書きが適している。一方、記憶（メモリ）は永続的で人間も参照するため、Markdownが適している。

【ツール＆フック層：11ツール + 4フック】

Icarusは、AIエージェントが記憶を操作するための11個のツールを提供する。主要なものを紹介しよう。

**fabric_write：**新しい記憶エントリを作成する。タイトル、内容、タグ、優先度を指定してMarkdownファイルを生成する。

**fabric_recall：**記憶を検索する。キーワードやタグで過去のエントリを呼び出す。hot → warm → cold の順に検索し、最も関連性の高いエントリを返す。

**fabric_search：**全文検索。fabric_recallよりも広範な検索を行い、複数のエントリをリストで返す。

**fabric_pending：**未処理のタスクやメッセージを確認する。セッション開始時に「やるべきこと」を把握するために使う。

**fabric_archive：**エントリを手動でcold層に移動する。

**fabric_relay：**他のエージェントにメッセージを送信する。

**fabric_eval：**現在使用中のモデルの性能を評価する。

**fabric_switch_model：**評価結果に基づいてモデルを切り替える。

これらのツールに加えて、4つのフックがエージェントのライフサイクルに組み込まれている。

**on_session_start：**セッション開始時に自動実行。fabric_pendingを呼び出し、未処理タスクやメッセージを確認する。前回のセッションの記憶を自動的にロードする。

**pre_llm_call：**LLM（大規模言語モデル）への問い合わせ前に実行。関連する記憶エントリを自動的にコンテキストに追加する。

**post_llm_call：**LLMの応答後に実行。重要な情報を自動的にfabric_writeで記録する。

**on_session_end：**セッション終了時に実行。作業内容のサマリーを自動生成し、保存する。

この4つのフックにより、エージェントは意識しなくても自動的に記憶を読み書きする。開発者が明示的にfabric_writeを呼ばなくても、重要な情報は勝手に記録される。

なぜファイルシステムなのか ― 「愚直さ」という戦略

AIの記憶システムを設計するとき、多くのエンジニアは真っ先にデータベースを検討するだろう。PostgreSQL、MongoDB、Redis、あるいはベクトルデータベースのPineconeやWeaviate。しかしIcarusは、これらをすべて退けて、ファイルシステム上のMarkdown+YAMLという最もプリミティブな方法を選んだ。

なぜか。理由は3つある。

第一に、人間が読める。

データベースに格納されたデータは、専用のクライアントやクエリがなければ中身を確認できない。だがMarkdownファイルなら、テキストエディタで開くだけで読める。catコマンドで表示できる。ブラウザでも読める。デバッグが圧倒的に楽になる。

AIエージェントが何を覚えているのか、何を忘れたのか、何を誤って記録したのか──人間がいつでも直接確認し、必要なら手で修正できる。これは運用上、極めて大きなメリットだ。

第二に、gitで管理できる。

~/fabric/ ディレクトリでgit initすれば、記憶の全履歴がバージョン管理される。いつ何が記録され、いつ変更され、いつ削除されたか。すべてgit logで追跡できる。複数マシン間の同期もgit push/pullで実現できる。

── gitによる記憶の管理 ──

cd ~/fabric

git init

git add .

git commit -m “Initial memory snapshot”

記憶の変更履歴を確認

git log —oneline

特定の時点の記憶に戻す

git checkout abc1234 — hot/task-report.md

────────────────────────

第三に、どんなフレームワークからも読み書きできる。

Markdownファイルの読み書きは、あらゆるプログラミング言語で可能だ。Python、JavaScript、Go、Rust、あるいはシェルスクリプト。特別なSDKもドライバもいらない。ファイルを開いて読むだけ。書くだけ。

これは、Icarusが特定のAIフレームワークに依存しないことを意味する。Hermes、OpenClaw、LangChain、AutoGen──どんなフレームワークのエージェントでも、ファイルシステムにアクセスできるなら Icarusの記憶を利用できる。

Icarusの設計者は、この方針を次のように表現している。

「最も愚直な方法が、最も堅牢である。」

データベースはクラッシュする。接続が切れる。スキーマの変更で壊れる。だがファイルシステムは、OSが動いている限り動く。テキストファイルは、50年前に書かれたものでも今日読める。この「退屈なほどの安定性」が、AIエージェントの記憶基盤にはふさわしい。

自己学習機能 ― 働きながら自分を鍛える

Icarus Memory Protocolの中でも特に野心的なのが、自己学習機能だ。エージェントが日常の作業を行いながら、その作業履歴から自動的に訓練データを抽出し、自分自身のモデルをファインチューニングする仕組みが組み込まれている。

【訓練データの自動抽出】

エージェントの作業履歴（fabric内のエントリ）から、3種類の訓練ペアが自動生成される。

**1. 指示-応答ペア：**ユーザーからの指示と、エージェントが生成した応答のペア。「こういう指示が来たら、こう答えるべき」というパターンを学習する。

**2. コンテキスト-判断ペア：**与えられたコンテキスト（状況情報）と、エージェントが下した判断のペア。「こういう状況では、こう判断すべき」というパターンを学習する。

**3. エラー-修正ペア：**エージェントが犯したミスと、その修正内容のペア。「こういうミスをしたら、こう直すべき」というパターンを学習する。これは特に重要で、同じミスを二度と繰り返さないための仕組みだ。

【Together AIによるファインチューニング】

抽出された訓練データは、Together AIのファインチューニングAPIを使ってQwen2-7Bモデルに適用される。Qwen2-7Bは70億パラメータの比較的軽量なモデルで、ファインチューニングのコストと時間を抑えられる。

このプロセスは自動化されており、一定量の訓練データが蓄積されると自動的にファインチューニングジョブが実行される。

── 自己学習ループの流れ ──

エージェントが通常の作業を行う
post_llm_call フックが作業内容を記録
訓練データ抽出スクリプトが3種のペアを生成
~/fabric/training/ に JSONL形式で保存
一定量が蓄積されたらTogether AI APIでファインチューン実行
新モデルが利用可能になる
fabric_eval で新旧モデルを比較評価
fabric_switch_model で優れた方に自動切替

──────────────────────────────

【fabric_eval と fabric_switch_model】

ファインチューニングされたモデルが本当に改善されているかを確認するのが fabric_eval だ。事前に用意された評価タスクを新旧両方のモデルに実行させ、精度や応答品質を比較する。

評価結果が一定の基準を満たせば、fabric_switch_model が自動的にモデルを切り替える。満たさなければ、既存モデルを維持する。このフィードバックループにより、エージェントは**「働きながら自分を鍛える」**ことができる。

これは、人間で言えば「仕事をしながらスキルアップする」のと同じだ。特別な訓練期間を設ける必要はない。日常業務そのものが訓練になる。

実際の動作例 ― 具体的なファイルとコマンド

抽象的な説明だけでは分かりにくいので、具体的な動作例を見てみよう。

【エントリの具体例：Markdownファイル】

以下は、~/fabric/hot/ に保存される典型的なエントリの例だ。

── ~/fabric/hot/2026-03-31-api-research.md ──

title: “Stripe API v3の調査結果”

created: 2026-03-31T14:30:00+09:00

author: agent-alpha

tags: [api, stripe, payment, research]

priority: high

status: complete

tier: hot

Stripe API v3の調査結果

概要

Stripe API v3では、Payment Intentsの作成フローが大幅に変更された。

主な変更点

confirm_payment が非同期に変更
webhook署名の検証方法が更新
idempotency_key の有効期限が24時間から72時間に延長

推奨アクション

既存のpayment.pyを v3対応に更新する必要あり
webhook_handler.py の署名検証ロジックを修正

導入の容易さ ― コピーするだけで動く

Icarus Memory Protocolの導入は、驚くほど簡単だ。

【Hermesプラグインとしてインストールする場合】

Hermesフレームワークを使っている場合、プラグインディレクトリにファイルをコピーするだけで完了する。

── Hermesへのインストール ──

git clone https://github.com/esaradev/icarus-daedalus.git

cp -r icarus-daedalus/plugins/fabric ~/.hermes/plugins/

Hermesを再起動

hermes restart

────────────────────────────

これだけだ。npmやpipでのインストールも、設定ファイルの編集も必要ない。ファイルをコピーし、再起動する。それで動く。

【他のフレームワークから利用する場合】

Hermes以外のフレームワーク（OpenClaw、LangChain、AutoGen等）から利用する場合は、bashアダプター経由でIcarusの機能にアクセスできる。

── bash adapter経由での利用 ──

記憶の書き込み

./fabric-adapter.sh write —title “調査結果” —content ”…” —tags “api,research”

記憶の検索

./fabric-adapter.sh recall —query “Stripe API” —limit 5

未処理タスクの確認

./fabric-adapter.sh pending

メッセージの送信

./fabric-adapter.sh relay —to “agent-bravo” —message “タスク完了”

──────────────────────────────────────────

bashアダプターは内部的にMarkdownファイルの読み書きとrelay.pyの呼び出しを行うだけなので、あらゆる環境で動作する。Dockerコンテナの中でも、リモートサーバー上でも、ラズベリーパイの上でも。

【コスト：¥0】

Icarus Memory Protocol自体は完全無料だ。オープンソースであり、外部サービスへの依存もない（自己学習機能を使う場合のみTogether AIの料金が発生するが、記憶機能だけなら一切コストはかからない）。必要なのは、ファイルを保存できるディスクスペースだけだ。

制限と課題 ― 銀の弾丸ではない

Icarus Memory Protocolは優れた設計だが、万能ではない。現時点での制限と課題を正直に述べておく。

【リアルタイム同期ではない】

複数マシンにまたがるエージェント間で記憶を共有する場合、ファイルの同期はrsyncやgit pushに依存する。つまり、エージェントAが記憶を書き込んでから、エージェントB（別マシン上）がそれを読めるようになるまでにタイムラグがある。

rsyncの実行間隔が5分なら、最大5分のラグが発生する。リアルタイム性が求められるユースケース（例：チャットボットの即座の引き継ぎ）には向かない。同一マシン上のエージェント同士であれば、ファイルシステムを直接共有するため、この問題は発生しない。

【ティアリングの閾値調整が必要】

hot → warm → cold の移行閾値（デフォルトでは24時間と7日）が、すべてのユースケースに最適とは限らない。短期集中型のプロジェクトでは、24時間のhot期間は長すぎるかもしれない。逆に、数週間にわたる長期プロジェクトでは、7日でcoldに移るのは早すぎるかもしれない。

現時点では、これらの閾値は curator.py の定数として定義されており、変更するにはファイルを直接編集する必要がある。将来的には設定ファイルでの柔軟な調整が望まれる。

【大量エントリ時のスケーラビリティ】

記憶エントリが数万件、数十万件に達した場合、ファイルシステムベースの検索は遅くなる可能性がある。fabric_recallやfabric_searchは基本的にディレクトリを走査してファイルを読み込むため、エントリ数に比例して検索時間が増加する。

この問題に対しては、いくつかの緩和策が考えられる。ファイル名にタイムスタンプとタグを含めることで、ファイルを開かずにある程度のフィルタリングが可能になる。また、定期的にインデックスファイルを生成し、全文検索を高速化する仕組みも検討されている。ただし、現時点では数千件程度のエントリであれば実用上の問題は報告されていない。

【セキュリティ面の考慮】

記憶がプレーンテキストのMarkdownファイルとして保存されるため、機密情報の取り扱いには注意が必要だ。APIキーやパスワード、個人情報などがエントリに含まれる場合、ファイルシステムのパーミッション設定や暗号化を別途検討する必要がある。Icarus自体にはデータの暗号化機能は含まれていない。

未来：AGIへの一歩 ― 群れから軍へ

Icarus Memory Protocolは、単なる「便利なメモ帳」ではない。その先に見据えているのは、エージェント同士が自律的に協調する世界だ。

現在のAIエージェントは、基本的に人間の指示で動く。人間がタスクを与え、エージェントが実行し、結果を人間に返す。複数エージェントを使う場合でも、タスクの分配と統合は人間が行っている。

だがIcarusの記憶共有とリレー機能を使えば、エージェント同士がタスクを自律的に受け渡すことが可能になる。

調査エージェントが情報を収集し、分析エージェントに渡す。分析エージェントが結論を出し、実装エージェントに渡す。実装エージェントがコードを書き、テストエージェントに渡す。テストエージェントが問題を発見したら、実装エージェントに差し戻す。

この一連の流れの中で、人間はボトルネックにならない。人間は最初に方針を示し、最後に結果を確認するだけでよい。中間のプロセスはエージェント同士が自律的に進める。

これは小さな変化のように見えるかもしれない。だが、その意味は深い。

記憶を持たないエージェントは、いくら数を増やしても、それぞれが孤立した個体に過ぎない。10体のエージェントがいても、1体のエージェントの10倍の仕事ができるわけではない。むしろ、重複作業や情報の断絶により、効率は1体の場合より悪くなることすらある。

だが、記憶を共有し、通信できるエージェント群は違う。彼らは組織になる。1+1が3にも5にもなる。専門化し、分業し、互いの成果を積み上げることができる。

Icarus Memory ProtocolのREADMEには、こんな一節がある。

「通信なき軍は、軍ではない。ただの群れである。」

AIエージェントに記憶と通信を与えること。それは、群れを軍に変えることだ。

もちろん、Icarusだけで AGI（汎用人工知能）が実現するわけではない。だが、AGIへの道のりにおいて、「エージェント間の記憶共有」は避けて通れない課題だ。そしてIcarusは、その課題に対する最もシンプルで実用的な解答の一つを示している。

まとめ ― シンプルさが生む可能性

Icarus Memory Protocolの魅力は、そのシンプルさにある。

フォルダを作る。Markdownを書く。読む。それだけで、AIエージェントに記憶が生まれ、エージェント同士が協調できるようになる。

技術的には何も革新的なことをしていない。ファイルシステム、Markdown、YAML、SQLite、cron──すべて枯れた技術だ。だからこそ、壊れない。どんな環境でも動く。誰でも理解できる。

50行のbashスクリプトから始まったこのプロジェクトが、AIエージェントの協調のあり方を変えるかもしれない。少なくとも、その可能性を感じさせるだけの設計と実装がここにはある。

AIエージェントを運用している方、複数エージェントの連携に課題を感じている方は、一度 ~/fabric/ ディレクトリを作ってみてほしい。それがAGIへの小さな一歩になるかもしれない。

**リポジトリ：**github.com/esaradev/icarus-daedalus

**ライセンス：**MIT

**必要なもの：**bash、Python 3.8以上、ディスクスペース

コスト：¥0

この記事は note.com から KTBLOG に移行されました。元記事: https://note.com/famous_prawn2009/n/ne54fbe5eb56a

AIエージェントに「記憶」を与える ― Icarus Memory Protocolの全貌