なぜ「指示書」に事実を書き込むと壊れるのか

AIエージェントに仕事を任せていると、ある日突然、指示通りに動かなくなることがあります。プロンプトを直した記憶はないのに、判断だけがずれていく。原因を探ると、たいてい同じパターンに行き着きます。役割や手順を書いた指示書の中に、価格や優先順位、担当といった「今の事実」まで一緒に書き込んでしまっているのです。

事実は動きます。価格は改定され、優先順位は入れ替わり、担当は交代します。ところが指示と事実が同じファイルに同居していると、事実を1つ書き換えるたびに、本来は動かしたくない指示書という場所を毎回開いて編集することになります。編集の手が増えるほど、書き間違いや消し忘れが起き、指示の一部が事実の更新に巻き込まれて壊れます。

これは些細な運用の癖ではなく、設計の問題です。壊れているのは事実ではなく、事実と指示を同じ場所に置いたという構造そのものだといえます。

一般的な「ナレッジ整備」で語られない実務の難所

AIエージェントのナレッジ設計を調べると、「ドキュメントを論理的に整理する」「重複や矛盾する情報を避ける」「定期的に見直す」といった助言に多く出会います。どれも正しく、否定するところはありません。ただ、こうした助言はたいてい「ドキュメントを整備した後」から先を語っていません。

実務でつまずくのは、整備した後にファイルが増え、同じ事実が複数の場所に書かれてしまう局面です。たとえば「今月の優先事業はどれか」という事実が、ロードマップにも、週次レポートにも、個別の指示書にも書かれているとします。優先事業が変わったとき、3か所すべてを同じタイミングで書き換えられるとは限りません。書き換えが1か所でも遅れると、AIエージェントは矛盾に気づいて報告するのではなく、目の前で読んだファイルの記述をそのまま採用してしまいます。矛盾は静かに紛れ込み、気づいた頃には、どちらの記述が正しい判断根拠だったのか分からなくなっています。

つまり難所は「整理するかどうか」ではなく、「同じ事実を何か所に書くか」と「事実が変わったときにどこを直せば全体に反映されるか」という参照構造の設計にあります。

指示ファイルと知識ファイルを分ける

この難所への対応として有効なのが、AIエージェントに読み込ませるファイルを、役割で2種類に分けることです。1つは「指示ファイル」で、役割・手順・判断基準・禁止事項など、めったに変わらないルールを書く場所です。もう1つは「知識ファイル」で、価格・優先順位・在庫・担当・進捗など、日々動く事実や状態を書く場所です。

指示ファイルの中には、事実そのものを書き込みません。代わりに「価格は知識ファイルの◯◯を参照する」「優先順位は◯◯を参照する」という参照先だけを書きます。事実が変わったときは知識ファイルだけを更新すればよく、指示ファイルには一切手を触れません。壊れる可能性がある編集を、そもそも指示ファイルから遠ざけてしまう発想です。

relmeaでも、業務を担うAIエージェントの定義本体(役割・手順・判断基準)と、そこから参照する状態ファイル(価格・優先順位・アカウント設計など)を、明確に別ファイルへ分けて運用しています。定義本体には変えない「ルール」だけを書き、変わり続ける「今の状態」は別ファイルに任せる、という切り分けです。

知識ファイルを分けるときは、粒度の設計も同時に必要です。1ファイルに1テーマだけを書くと見通しはよくなりますが、テーマを細かく割りすぎると、AIエージェントも人も「今回必要な事実がどのファイルにあるか」を探す手間が増えます。逆に複数テーマを1つの知識ファイルにまとめると、探す手間は減りますが、ある事実を確認するためだけに、関係のない他のテーマの記述まで毎回読み込むことになります。

目安としては、更新のタイミングが同じ事実同士はまとめ、更新のタイミングが異なる事実は別ファイルに分ける、という基準が実務的です。たとえば「価格」と「在庫」は改定のタイミングが違うことが多く、同じファイルに同居させると、価格だけを直したいときにも在庫の記述まで読み直す羽目になります。

状態の「真実の源」を1箇所に決める

ファイルを2種類に分けるだけでは、同じ事実が複数の知識ファイルに重複して書かれる問題は解決しません。次に必要なのは、1つの事実につき「ここが正しい」と決めた置き場所を1箇所だけ定めることです。設計の考え方としては、これを状態の真実の源を1つに絞る、と呼びます。

具体的には、次のような割り当てをあらかじめ決めておきます。

  • 型や仕様の定義は、このファイルに書く
  • 要件や仕様の変更履歴は、このファイルに書く
  • 進捗や完了状況は、このファイルに書く

他のファイルは、その事実を必要とする場面でも数値や結論を書き写すのではなく、真実の源となるファイルの参照先だけを書きます。これにより、事実を更新する作業は常に1箇所で完結し、他のファイルは「参照している」というだけで自動的に最新の状態に追従します。更新の手間が減るだけでなく、どのファイルを読んだかによってAIエージェントの答えが変わる、という事態も防げます。

もう1つ見落とされがちなのが、事実を変えたときに「この事実を参照している側」を漏れなく見つけられるか、という逆引きの設計です。真実の源を1箇所に決めても、どのファイルがその源を参照しているかの一覧がなければ、更新時に見落としが残ります。参照する側のファイル冒頭に「この項目は◯◯を参照する」と明記しておく、あるいは参照元の一覧を索引側に書いておくといった、逆引きできる仕掛けをあわせて用意しておくことが必要です。

索引と実体を分けて渡す

知識ファイルを整理していくと、今度は別の問題に直面します。関連する知識をすべて1つのファイルにまとめると、そのファイル自体が肥大化し、AIエージェントに毎回全文を読ませることになります。かといって知識を細切れに分けすぎると、どのファイルに何が書いてあるかを、AIエージェント自身が把握できなくなります。

ここで有効なのが、知識を「索引」と「実体」の二段構えで渡す考え方です。索引は、各知識ファイルの1行サマリーと置き場所だけをまとめた薄い一覧で、AIエージェントには基本的にこの索引だけを渡します。実体は、詳細な手順や背景事情を書いた厚いファイルで、索引を見て「これが必要そうだ」と判断したときだけ、AIエージェント自身が該当ファイルを開きにいきます。

この二段構えにより、AIエージェントは常に全知識を抱え込む必要がなくなり、必要な知識だけを必要な場面で参照できます。索引に何を載せ、実体に何を残すかという線引きは、知識が増えるたびに見直す価値がある設計判断です。

逆に、知識を渡しすぎることにも別の弊害があります。関連しそうな情報をとにかく詰め込んで渡すと、AIエージェントは本来関係のない前提条件まで判断材料に取り込んでしまい、結論がぶれやすくなります。索引を薄く保つ目的は、読ませる分量を減らすことだけでなく、AIエージェントが今回の判断に本当に必要な事実だけを見て考えられる状態を保つことにもあります。渡す知識を絞る基準は、量の多さではなく、今回の判断に関係するかどうかで決めるのが実務的です。

AIに任せる部分、人が判断する部分

ここまでの設計は、事実の更新作業をAIエージェントに任せることを前提にしています。実際、知識ファイルの中身の書き換え、たとえば価格の反映や進捗の更新、担当の変更といった作業は、参照構造さえ決まっていればAIエージェントに任せて問題のない領域です。

一方で、次の2つは人が判断すべき領域として残しておくことをおすすめします。

  • どの事実を「真実の源」にするか、という置き場所そのものの決定
  • 指示ファイルの側、つまり役割・手順・禁止事項の変更

置き場所の決定は、事業の構造そのものを表す意思決定であり、後から変えるとすべての参照先を洗い出す手間が発生します。指示ファイルの変更は、事実の更新とは異なるリズムで動くべきもので、日々の事実更新に紛れて無自覚に書き換えられることを避ける必要があります。AIエージェントには「事実の更新」という実行を任せ、人には「構造をどう決めるか」という判断を残す。この線引きを最初に決めておくことが、長く壊れない参照構造を作れるかどうかの分かれ目になります。