AIエージェントの「無限メモリ」より大切なこと——508件の記憶を会社の仕組みに変えた方法
Claude CodeやCodexに何を覚えさせ、何を忘れさせ、どこで誤りを止めるのか。実運用から整理した5層設計
AIエージェントに「無限メモリ」を持たせる。
聞こえはとても魅力的です。Claude CodeやCodexを使っていて、前回伝えたことを忘れられたり、別のプロジェクトの前提をもう一度説明したりした経験があれば、なおさらでしょう。
ただ、会社の実務でAIを使い続けてきた私の結論は、少し違います。
AIに必要なのは、何でも覚える巨大な記憶庫ではありません。何を正しい情報として扱い、今の仕事に何を取り出し、古い判断をどう更新し、重大なミスをどこで止めるかという「記憶の設計」です。
私の環境のメモリ領域には、現在508件のMarkdown記録があります。これは運用中の507件とアーカイブ1件の合計です。主な内訳は、過去の失敗から得たルールが214件、プロジェクト固有の情報が89件、再利用できる設計・運用知識が194件、そのほかのユーザー情報や索引です。
さらに、ルール違反や見落としを機械的に止めるためのフックスクリプトが42本あります。
この数字だけを見ると、かなり大きな「AIの記憶」に見えるかもしれません。しかし、効果が出た理由は量ではありません。正本、索引、分類された知識、意思決定ログ、強制力を分離したことです。
この記事では、私がAI支援で700万行を超えるコードを書き、複数の会社・クライアント業務を並行してきた中で組み上げた、AIエージェントの5層メモリ設計を公開します。
特定の製品を入れれば完成する話ではありません。Markdownファイルだけでも、小さく始められます。
本当に怖いのは「忘れること」ではなく「間違って覚えること」
AIのメモリについて話すと、ほとんどの場合は「どれだけ長く覚えられるか」が焦点になります。
しかし、実務で問題になるのは、記憶が消えることだけではありません。
- 半年前の方針を、現在も有効な決定として使う
- あるクライアントの例外ルールを、別の会社にも適用する
- 会議で出ただけの案を、確定事項として実装する
- 「次から気をつける」という反省文を保存し、同じミスを繰り返す
- 大量の資料を読み込ませた結果、重要な指示が埋もれる
記憶が多いほど、この危険はむしろ増えます。
人間でも、古いメモ、未確定の議事録、正式な規程が同じ机に積まれていたら、情報量が多いことは安心材料になりません。どれが正本か分からないからです。
AIも同じです。
Anthropicは、AIエージェントのコンテキストを無限の倉庫ではなく、限りある資源として扱い、必要な情報を選んで入れる重要性を説明しています。詳しくは公式のEffective context engineering for AI agentsにあります。
また、長い入力の中に正解が含まれていても、その情報が文脈の中央付近にあると利用性能が下がりやすいことは、論文Lost in the Middleでも報告されています。
つまり、保存容量を増やすだけでは足りません。
重要なのは、今の仕事に必要な、正しい、最新の情報だけを、適切な順序でAIに渡すことです。
私が最初に失敗したのは「注意事項を保存すれば再発しない」と考えたこと
私も当初は、AIがミスをするたびに注意事項を書き足していました。
「この操作をしてはいけない」
「完了と言う前に必ず確認する」
「クライアント固有の情報を混ぜない」
文章にして残せば、次は守られると思っていたからです。
ところが、同じ種類の違反が一つの作業中に4回、5回と起きることがありました。メモには正しいことが書いてあります。AIも読み返せば理解できます。それでも、長い作業の途中では抜けます。
この経験から、私は役割を分けました。
メモリは、事実・理由・判断基準を残す場所。フックやテストは、違反を物理的に止める場所。
たとえば、リリース前に型検査・テスト・ビルドが必要なら、「必ず実行すること」とメモに書くだけにはしません。完了を宣言する前に、検査結果が存在するかを機械的に確認します。
会社別の作業で意思決定ログが更新されていなければ、作業終了時に検知します。機密情報を含む可能性があるファイルをコミットしようとすれば止めます。一定以上に大きくなったコードは、自動検査の対象にします。
「覚えている」と「守れる」は別の能力です。
この区別が、現在の5層設計の出発点になりました。
AIエージェントの記憶を5つの層に分ける
私が現在使っている構造を、役割ごとに整理すると次のようになります。
| 層 | 役割 | 代表的な内容 | ここで解決する問題 |
|---|---|---|---|
| 1. 正本 | 優先順位と絶対ルールを定める | 会社規程、開発規約、権限、禁止事項 | どの情報を信じるか分からない |
| 2. 索引 | 必要な知識への入口を示す | MEMORY.md、カテゴリ一覧、検索語 | 全資料を毎回読んで文脈が膨らむ |
| 3. 知識 | 再利用できる事実と学びを蓄積する | 失敗パターン、設計原則、案件知識 | 同じ説明や調査を繰り返す |
| 4. 意思決定 | 「現在の結論」と履歴を分ける | 決定日、理由、代替案、変更履歴 | 古い案を現行方針と誤認する |
| 5. 強制力 | 守るべき条件を機械的に検査する | フック、テスト、CI、権限制御 | 分かっているのに同じミスをする |
ポイントは、この5つを一つの巨大なデータベースに押し込まないことです。
それぞれに寿命も、更新者も、呼び出すタイミングも異なります。
第1層：正本——AIが迷ったときに戻る「憲法」
最上位に置くのは、プロジェクトの正本です。
私の環境では、AIへの基本指示、会社ごとの規程、開発時の禁止事項、情報の優先順位を明文化しています。
特に大切なのは、新しい指示と古い記憶が矛盾したとき、必ず新しい指示を優先すると決めていることです。
メモリは過去の参考情報です。現在の指示への反証として使わせてはいけません。
このルールがないと、AIは以前の成功体験を忠実に再現しようとして、今の依頼を曲げることがあります。記憶力が高いAIほど、古い前提を一貫して守ってしまう危険があります。
正本に入れるのは、数が少なく、変更頻度が低く、違反時の影響が大きいものです。
- 情報の優先順位
- 顧客情報・認証情報の取り扱い
- 変更してよい範囲
- 公開や削除など、外部に影響する操作の承認条件
- 品質を「完了」と呼ぶための基準
逆に、一時的なタスクのメモや個別バグの詳細をここへ詰め込むと、憲法が読めなくなります。
第2層：索引——全部を読むのではなく、読む場所を決める
508件のメモを、AIに毎回すべて読ませることはありません。
代わりに、最初に読む短い索引を置きます。索引には、どの種類の仕事で、どの知識群を探すかだけを書きます。
たとえば、公開フォームを変更するなら、入力検証、迷惑送信対策、本番確認の知識へ進む。権限を変更するなら、認証、実権限、画面表示、データベースポリシーの知識へ進む。クライアント文書なら、会社情報、過去の意思決定、公開可否の知識へ進む、という具合です。
これは図書館の蔵書を毎朝すべて机に積むのではなく、目録から必要な棚へ行く設計です。
索引は、内容そのものより短く保ちます。「答え」ではなく「答えがどこにあるか」を示すためです。
検索機能を導入する場合も、索引は不要になりません。検索語が曖昧なら、類似度の高い別案件の情報を拾うことがあるからです。先に仕事の種類と探索範囲を絞ることで、検索の精度が上がります。
第3層：知識——事実、理由、再利用条件をセットで残す
ここが、一般に「AIのメモリ」と呼ばれる部分です。
私は知識を大きく分けています。
- 過去の指摘と、再発防止の判断基準
- プロジェクト固有の構成や現在地
- 複数案件で使える設計・運用の原則
- 利用者や会社についての安定した情報
ただし、「○○で失敗した」だけでは、次の仕事に使えません。
良い知識メモには、少なくとも次の4点を入れます。
- 何が起きたか
- なぜ問題だったか
- 次回は何を確認するか
- どの条件では、この知識を使わないか
4番目が意外に重要です。
たとえば、あるシステムで有効だった権限設計が、別の業務でも正しいとは限りません。「複数組織を持つサービスだけに適用する」「管理者の代理表示と実権限を分離する」といった適用条件がなければ、過剰な一般化が起きます。
AIにとって便利なメモは、断定的な一行ではありません。再利用できる判断の単位になっているメモです。
第4層：意思決定——案、決定、現在の状態を混ぜない
会議録には、多くの「まだ決まっていない話」が含まれます。
アイデア、懸念、仮説、宿題、見積もり、将来案。これらをそのまま長期記憶に入れると、数か月後にAIが確定事項として扱う危険があります。
そこで、会社や重要テーマごとに意思決定ログを分けています。
最低限、次の項目を残します。
- 決定日
- 決定した内容
- 決定理由
- 採用しなかった選択肢
- 影響する資料やシステム
- 後日変更された場合の新しい決定
古い決定を消さないことも大切です。
「以前はAだったが、2026年8月からBに変わった」と履歴を残せば、過去の資料を読むときに矛盾の理由が分かります。最新版だけを上書きすると、古い実装や文書がなぜその形なのか分からなくなります。
私の運用では、会社関連の資料を変更したのに意思決定ログが更新されていない場合、作業終了時に検知する仕組みも入れています。ログを「余裕があれば書く議事録」ではなく、仕事の完了条件にしたかったからです。
第5層：強制力——重要なルールは、AIの注意力に任せない
最後の層が、フック、テスト、CI、権限制御です。
この層だけは、記憶ではありません。しかし、会社でAIを使うなら、記憶システムの一部として設計すべきです。
ルールの扱いは、影響度で分けます。
| ルールの種類 | 適した実装 |
|---|---|
| 背景を理解すればよい | 知識メモ |
| 作業時に確認すべき | チェックリスト、テンプレート |
| 忘れると品質が落ちる | 自動テスト、レビューゲート |
| 情報漏えい・データ破壊につながる | 権限制御、実行前ブロック |
「注意してください」という文章は、最後の2つには弱すぎます。
私が42本のフックスクリプトを持つようになったのも、AIを信用していないからではありません。人間にもAIにも、集中力と作業文脈には限界があるからです。
ルールを守るために毎回思い出す必要があるなら、その運用はまだ仕組みになっていません。
実際の処理は「保存」ではなく、この循環で動く
5層は、次の順番で使います。
依頼を受ける
↓
正本で、優先順位・禁止事項・完了条件を確認する
↓
索引から、今回必要な知識の範囲を絞る
↓
関連する知識メモと意思決定ログだけを取得する
↓
現物のコード・資料・データで、現在の状態を確認する
↓
実行する
↓
フック・テスト・レビューゲートで検証する
↓
新しい決定や再利用可能な学びだけを記録する
ここで重要なのは、メモリに書かれていることを、そのまま現実だとみなさないことです。
コードなら現在のコード、契約なら締結済みの契約書、会社情報なら最新の正本資料が現実です。メモリは探索を速くする地図であって、現地そのものではありません。
地図と現地が違えば、現地を確認し、地図を更新します。
匿名事例：権限の問題は「以前直した」で終わらせない
ある予約業務システムで、管理者が別の役割の画面を確認する機能を扱ったことがあります。
ここでは、「画面上でどの役割として見えるか」と「実際にどの権限を持つか」を混ぜると危険です。表示を一般利用者に切り替えたつもりが実権限まで変わる、あるいは表示だけ変わって管理者権限が見えないところで残る、といった問題が起こり得ます。
その案件だけを修正して終われば、次のシステムで同じ設計ミスが起きます。
そこで、次のように分けて記録しました。
- 案件固有の状態は、プロジェクト知識へ保存する
- 「表示上の役割と実権限を分離する」という原則は、再利用知識へ保存する
- 採用した方式と理由は、意思決定ログへ残す
- 権限境界の回帰確認は、テスト項目として強制する
一つの障害から、一つの長文メモを作るのではありません。
同じ事実を、将来どの場面で使うかによって分解するのがポイントです。
この考え方は、権限だけでなく、請求、通知、個人情報、公開フォームなどにも使えます。
Agentmemoryのようなツールは、5層のどこに入るのか
AIエージェント向けのメモリ製品は、ここ数年でかなり実用的になっています。
たとえばオープンソースのAgentmemoryは、MCP経由の記憶操作、全文・ベクトル・グラフを組み合わせた検索、複数エージェント間の共有などを提供しています。2026年8月時点の公式READMEでは、Claude CodeやCodex向けの接続方法も案内されています。
こうしたツールは有力です。ただし、私なら5層のうち、主に第2層の検索と第3層の知識保存を強化する部品として使います。
置き換えさせないものもあります。
- 正本の優先順位
- 誰が決定を変更できるか
- 現在有効な意思決定の管理
- 情報漏えいや破壊操作を止める強制力
検索性能が高くても、取得した古い情報を現行方針より優先すれば危険です。エージェント間で共有できても、顧客ごとの境界が曖昧なら情報が混ざります。自動保存できても、未確定の発言まで永久記憶にするとノイズが増えます。
導入前には、機能数より次を確認します。
- 記憶のスコープを会社・案件・利用者ごとに隔離できるか
- 何が保存されたかを人間が確認・修正・削除できるか
- 古い情報と新しい情報が競合したときの優先順位を決められるか
- 機密情報を外部サービスへ送る範囲が明確か
- 障害時に、メモリなしでも最低限の仕事を継続できるか
- Windows、WSL、デスクトップアプリなど、実際の利用環境で制約がないか
最後の点も地味に重要です。導入記事では「数分で完成」と見えても、公式手順を読むとOSや利用形態によって手順が異なることがあります。製品を評価するときは、紹介記事より、現在のREADME、リリースノート、未解決の問題を確認します。
ツールは便利です。しかし、ツールを入れることと、会社の記憶が設計されることは別です。
まずは5つのMarkdownファイルから始めればよい
最初から508件のメモも、42本のフックも必要ありません。
小さな会社や一人の開発環境なら、次の5ファイルから始められます。
AI-RULES.md # 正本。優先順位、禁止事項、完了条件
MEMORY.md # 索引。どの仕事で何を読むか
LEARNINGS.md # 再利用できる失敗・設計知識
DECISIONS.md # 日付、結論、理由、変更履歴
CHECKLIST.md # まだ自動化していない検証項目
最初の1週間は、検索基盤を作らなくても構いません。
AIが同じことを二度聞いてきたら、索引か知識に残す。重要な判断が変わったら、意思決定ログへ追記する。同じミスが二度起きたら、チェックリストか自動検査へ移す。
この運用だけでも、「すべてを一つの指示ファイルに追記する」状態から抜けられます。
30日で育てるなら、この順番
導入を30日で区切るなら、私は次の順で進めます。
1週目：正本と意思決定を分ける
現在の長いプロンプトやルール集を見直し、「常に守るもの」と「過去の参考情報」を分離します。
重要な会議について、決定、理由、未決事項を分けて記録します。
2週目：知識を3分類する
少なくとも、失敗からの学び、案件固有情報、再利用できる原則を分けます。
各メモに適用条件と更新日を付けます。
3週目：取り出し方を整える
索引を作り、仕事の種類ごとに読む場所を決めます。
件数が増えてから、全文検索やベクトル検索を検討します。検索ツールの導入を先にすると、整理されていない情報を高速に探せるだけになりがちです。
4週目：繰り返すミスを自動で止める
過去30日で2回以上起きたミスを洗い出します。
チェックリストで十分か、テストが必要か、操作そのものを禁止すべきかを決めます。自動化の優先順位は、頻度と損失の大きさで決めます。
効果は「保存件数」ではなく、4つの数字で測る
メモリ基盤を導入すると、保存件数や検索回数を見たくなります。
しかし、会社にとって重要なのは、記憶庫が成長したことではありません。仕事が良くなったかどうかです。
私は次の4つを見ます。
| 指標 | 見る理由 |
|---|---|
| 同じ説明を繰り返した回数 | 引き継ぎと索引が機能しているか |
| 古い前提による手戻り件数 | 正本と意思決定ログが機能しているか |
| 同種ミスの再発件数 | 知識が検査・強制力へ移されたか |
| 必要情報に到達する時間 | 検索範囲と分類が適切か |
メモの数が増えているのに手戻りも増えるなら、記憶システムは改善ではなく負債になっています。
反対に、メモの数が少なくても、判断が速くなり、同じ事故が減り、新しい担当者が迷わないなら、十分に価値があります。
AIエージェントを「詳しい新人」から「会社の仕組み」に変える
メモリを持たないAIは、毎回ゼロから説明が必要な、能力の高い新人に似ています。
一方で、何でも自動保存するAIは、机いっぱいに過去資料を積み上げた古参社員に似ています。知識は豊富でも、どれが最新か分からなければ安心して任せられません。
会社で必要なのは、その中間です。
正本で優先順位を定める。索引で必要な場所へ案内する。知識を適用条件つきで蓄える。意思決定を履歴として管理する。そして、重大な条件は仕組みで守る。
この5層がそろうと、AIの記憶は便利機能ではなく、会社の運用資産になります。
私自身、508件のメモを一度に作ったわけではありません。同じ説明をしたら残す。同じミスが起きたら分類する。二度と起こしてはいけないものは、文章から仕組みへ移す。その積み重ねです。
AIエージェントのメモリを考えるとき、最初の問いは「何件保存できるか」ではありません。
何を正本にするか。何を検索するか。何を忘れさせるか。何を機械的に止めるか。
ここが決まって初めて、メモリーツールの機能が生きます。
IIWAYO.TECHでは、AIを導入するだけでなく、業務の正本、意思決定、権限、品質ゲートまで含めて設計しています。AIシステム開発や、AIと人間の役割分担を前提にしたFlow Codingも、同じ考え方の延長にあります。
ツールの比較だけでなく、自社の仕事に残る仕組みを作りたい方は、お問い合わせからご相談ください。BANSOU CTO™として、現在の資料・判断・運用を整理するところから伴走します。
伊藤翔太
株式会社IIWAYO.TECH 代表取締役 / 株式会社リサスティー 代表取締役