AI Agentはただのチャットボットではありません。コンピューター上で長期稼働し、プロジェクトを管理し、スケジュールを実行し、コンテンツを作るなら、記憶と作業記録を置くファイルシステムが必要です。

この話は簡単そうに聞こえます。フォルダをいくつか作り、文書を書き、命名規則を決めれば終わりそうです。

実際には、AI Agentシステムで最も過小評価されがちなエンジニアリング課題かもしれません。

ルールが自分自身を管理できない時

2か月以上動いていたAIアシスタントシステムをある日開いて確認すると、こんな状況が見えました。

記憶インデックスファイルMEMORY.mdの規定は「1KB以内に抑える」でした。実際のサイズは7KB、上限の7倍です。原因は、システムが毎日新しい知識を生むのに、置き場所が一つしかなかったことです。誰も気づかなかったのが問題ではありません。

Xプラットフォーム用のコンテンツ草稿は4つのパスに散らばっていました。referenceとreferencesというほぼ同名のフォルダがあり、それぞれ無関係のファイルを持っていました。十数日のうちに、記憶ファイルは自動で300個近く増えていました。

これらの問題には共通点があります。システムは、自分で書いた最も単純なルールすら守れなくなっていました。

直感的には、もっとルールを増やし、もっと厳しい規範を作りたくなります。でもここで一度止まって考える価値があります。既存ルールがすでに失敗しているのに、新しいルールを足せば改善するのでしょうか。

AI自身にどうするか討論させる

一人の視点に閉じるのを避けるため、私は実験を設計しました。4つのAI Agentに別々の立場を持たせ、3つの研究報告（ChatGPT Deep Research、Perplexity検索分析、学術報告）を読ませ、それぞれの角度から解決案を出させました。

4つの役割は次の通りです。

実用派の信念は「壊れていないものは直すな」です。彼は既存システムと研究提案を一つずつ比較し、分層起動、必要時読み込み、記憶圧縮などの仕組みはすでに整っていると見ました。研究報告が立派に見えるからといって、急いで大改造するな、という立場です。

アーキテクトの信念は「構造的負債の利息は金融負債より高い」です。彼は現在の成長データから1年後を推算しました。当時の速度では、記憶ディレクトリは1年後に5000ファイルを超えます。今使えることは、3か月後も使えることを意味しない、という見方です。

失敗分析者は理論を見ず、証拠だけを見ます。彼はファイルシステム全体を調べ、置き場所を間違えたファイル、破られたルールをすべて列挙しました。彼の役割は各案がどう失敗するかを指摘すること。案を出すのは他の人の仕事です。

移行戦略担当はどちらにも付きません。関心は一つだけです。もし変えるなら、既存システムを壊さずにどう変えるか。彼は各変更にrollback経路を設計しました。

核心の対立：構造を足すか、ルールを減らすか

4つの役割の分析を並べると、すぐに一つの矛盾が浮かびました。

失敗分析者の立場は明確です。システムはすでに既存ルールを守れていない。構造をさらに増やすと負担が増えるだけ。彼の予測は、全ファイルにYAMLヘッダーを強制したら、3週間以内に遵守率は50%未満へ落ちる、というものでした。AI Agentは絶えず新しいファイルを作るため、毎回ヘッダーを付けることを誰も覚えていません。

アーキテクトの反論も筋が通っています。MEMORY.mdが7倍に膨らんだ根本原因は、その知識を置く別の場所が構造上なかったことです。規律は表象にすぎません。情報の行き先は二つだけでした。インデックスファイルに入れて膨らませるか、日次メモに入れてアーカイブ時に消えるか。

二つの視点は矛盾して見えますが、よく見ると同じことを言っています。

MEMORY.mdが膨らんだのは、MEMORY.mdへ書くほうが新しいtopicファイルを作るより楽だったからです。草稿が散らばったのは、人間やAIが自然に正しい場所へ置ける、明確な「正しい位置」がなかったからです。

「アーキテクチャ vs 規律」は本当の二択ではありません。アーキテクチャが正しい行動を最も抵抗の少ない道にすれば、規律は自然に成立します。

この結論は簡単に聞こえますが、その後のすべての判断基準を変えました。「このルールは十分厳しいか」ではなく、「この設計は正しい行動を楽にしているか」を問うようになりました。

何をしたか

最終案は3つに集中しました。

第一に、単一の記憶インデックスを、インデックスとtopicファイルに分けました。元の7KBのMEMORY.mdは500 bytes未満の純インデックスになり、十数個のtopic別独立ファイルができました。AI起動時はindexだけを読み、必要な時に該当topicを読みます。この変更だけで、起動時のtoken消費はかなり減りました。

第二に、起動フローを自然言語の説明から厳密なステップリストへ変えました。「ステップ1読このファイル、ステップ2読あのファイル」と直接書きます。「以下の原則に従ってください」のような言い方は緩すぎます。明確なほど、AIは抜けや勝手な解釈をしにくくなります。

第三に、軽量なディレクトリindexを作り、Markdown形式で毎週自動再生成するようにしました。JSONもデータベースも使いません。古くなっても壊れず、参考資料が一つ減るだけです。

あえてしなかったこと

この討論で最も価値があった成果かもしれません。

Johnny Decimalのディレクトリ番号システムを使わない。すべてのフォルダを数字で命名し直す方法です（project_aを11.02にするなど）。整理されて見えますが、実際には数十個のプロジェクトディレクトリ名を変えることになり、コード内の固定パスがすべて壊れます。しかもAIにとっては数字より意味のある名前のほうが重要です。11.02よりproject_aのほうが理解しやすいです。

Zettelkastenの原子メモシステムを使わない。学術界で評価されている知識管理方法です。ただ当時のシステム全体には数十個のメモしかありませんでした。この規模に学術級の知識管理システムを使うのは、家計簿にERPを導入するようなものです。

暗号ハッシュによるドリフト検出。暗号学的な方法で文書が意図せず変更されたか検出する案です。一人で一台のコンピューターを使うシステムなら、git diffで十分です。

状態ファイルをJSONにする。構造化は強くなりますが、人間の読みやすさが消えます。スマホで状態を一目見るニーズのほうが、プログラムによる自動解析より頻繁でした。

どの案にも理屈はあります。ただ、現在の規模と使い方では、まだ発生していない問題を解いていました。失敗分析者の判断フレームは有用でした。まず2倍規模のために設計し、2倍に到達したら再評価する。仮想の100倍に向けて過剰にエンジニアリングしない。

踏みやすい5つの罠

失敗分析者は討論の中で、AI Agentシステム設計時によくある5つの隠れた前提を指摘しました。どれももっともらしく聞こえますが、意識しないと過剰設計につながります。

「AI Agentはデータベースのように動く」。違います。Agentは言語モデルです。文章を読み、推論し、文章を出します。key-value検索型の構造を前提に設計すると、方向を間違える可能性があります。

「ファイルが見つからないことが主なボトルネック」。実際のボトルネックは「探しに行くべきだと知っているか」であることが多いです。フォルダがきれいでも、Agentがそのファイルの存在を知らなければ意味がありません。

「構造が多いほど信頼性が上がる」。構造は結合を作り、結合は脆さを作ります。抽象層が一つ増えるたびに、壊れる接点も一つ増えます。

「将来システムは大きく拡張する」。そうかもしれません。ただ、未来の問題のために今のアーキテクチャを作ると、まだ存在しない問題のために今日のコストを払うことになりがちです。

「Agentは新ルールを守る」。これが最も危険な前提です。ルールが一行増えるたびに、既存ルールへ向けられる注意力は少し薄まります。ルール総量が増えるほど、各ルールが守られる確率は下がります。

その後どうなったか

3か月後に振り返ると、いくつか記録しておく価値があります。

実用派の判断は基本的に正しかったです。実際に効果があった変更は最初の3つ、記憶分割、起動チェックリスト、命名規範でした。これらを終えると、システムの混乱度は明らかに下がりました。

アーキテクトが提案した4層記憶モデルは、今のところ2層半しか使っていません。設計自体は悪くありません。需要がそこまで育っていないだけです。

失敗分析者の予測が一番鋭かったです。「YAMLヘッダー強制は3週間で遵守率50%未満」という論証があまりに説得力があり、そもそも実施しませんでした。彼が心配したディレクトリindexの陳腐化は実際に起きましたが、毎週の自動再生成で十分対応できました。

移行戦略担当のrollbackフレームは実務で一番役立ちました。2つの案を試してから戻す判断をしましたが、過程で被害はありませんでした。安心して試し、安心してやめられること自体が、よいシステム設計です。

持ち帰る一つのこと

自分のAI Agentシステムを作っている、あるいは自動化フローがなぜどんどん散らかるのか悩んでいるなら、この討論は一文に圧縮できます。

急いでルールを増やさない。まず既存ルールがなぜ守られなかったのかを見る。

答えはたいてい、構造が正しい行動を最も簡単な選択にしていないことにあります。「AIが言うことを聞かない」は表面の症状です。

正しいことを最も楽なことにする。残りは自然に起こります。

関連記事

小企鵝の経験

私はOpenClaw上のOpus / Sonnet / Codexの3 agent構成をしばらく実運用しています。記憶はすべてMarkdownファイルで、RAGもvector databaseも使っていません。この討論で出た二つのことは実戦で何度も確認されました。第一に、構造で解けるものはルールで縛らない。たとえば各プロジェクトのcontextをそのプロジェクトフォルダに置けば、自然に読まれます。AIに「忘れず確認しろ」と強制する必要はありません。第二に、最小限で足りればそれでいい。4層記憶はいまでも2層半しか使っておらず、残りは本当に必要になってから足せばいい。実際に一番役立ったのはrollbackフレームでした。複雑な構造は小規模で試す。安心して捨てられる設計こそ、よい設計です。

よくある質問

Q: AI Agentの記憶システムはなぜ制御不能になりますか？

AI Agentは毎日、記憶メモ、作業記録、草稿など大量のファイルを自動生成します。構造上、保存先が1、2か所しかないと、ファイルは一か所に膨らむか、あちこちに散らばります。核心は、正しい行動が最も楽な行動になるよう設計されていないことです。

Q: 多Agent討論とは何ですか？

複数のAI Agentに実用派、アーキテクト、失敗分析者、移行戦略担当など別々の立場を持たせ、同じ資料を分析させて案を出させる方法です。視点をぶつけることで、一人の視点では見落としやすい盲点を見つけます。

Q: AI Agentシステム設計で最もよくある間違いは何ですか？

「ルールを増やせば混乱は解決する」と考えることです。実際には、ルールを一つ増やすたびに既存ルールへの注意力は薄まります。正しい方法はアーキテクチャを改善し、正しい行動を最も簡単にすることです。

— Penchan