はじめに

これは「AIに長いプロンプトを食わせれば賢くなる」という話ではない。

むしろ逆で、AIは忘れるし、読み落とすし、もっともらしく間違えることを前提にした運用を組んだ話だ。

私は数か月にわたり、数十ファイルへ膨らむ長期案件をClaudeとChatGPTで扱ってきた。途中で使うモデルも変わったし、セッションも何度も切れた。資料も増え続けた。

最初に困ったのは「AIの記憶力」だった。

最終的に出した答えは、記憶を増やすことではなかった。

コンテキストを保存するのではなく、必要なコンテキストを再構築できる仕組みを保存する。

この考えに至るまで、運用はだいたい次の順で変化した。

20ファイルへ圧縮
    ↓
Workで分析資料が増殖（21〜42）
    ↓
00番をREADMEとして作成
    ↓
00番を「正典」に昇格
    ↓
深掘りルールを外部化
    ↓
Google Driveをライブ検索
    ↓
AI成果物そのものを監査
    ↓
複数AIを役割分担して相互レビュー
    ↓
学習結果を00番へ戻す

以下は、その実運用から得た設計パターンである。

1. 最初は「最大20ファイルにまとめて」だった

最初にClaudeへ資料整理を頼んだとき、私はChatGPTからGoogle Driveを直接参照できることを知らなかった。

当時は、プロジェクトへ置ける情報源の上限を約25ファイルだと考えていた。

そこでClaudeに、

大量の資料を最大20ファイル程度へまとめてほしい

と頼んだ。

こうして1番から20番までのファイルができた。

これは格好いい情報設計ではない。

単に上限へ押し込むための圧縮だった。

ただ、ここで偶然ひとつ良いことが起きた。

原本をそのまま並べるのではなく、

原文保存
時系列
規程
論点整理
会話ログ
レビュー

のように、役割ごとの中間資料が生まれた。

後から考えると、これが最初の重要な転換だった。

AIへ必要なのは「全部の原本を常時抱えさせること」ではなく、どんな種類の資料が存在するかを構造化することだった。

2. Workを使ったら、今度は42ファイルまで増えた

その後、ChatGPT Workで重い調査・分析を進めた。

そこで21番以降の分析資料が増え、42番まで到達した。

この段階では資料の役割が変わった。

1〜20番が主に「材料を扱える形にする層」だったのに対して、21番以降には、

論点別レビュー
反証
手続の構造分析
実行計画
提出候補
セルフレビュー結果

のような下流成果物が増えた。

すると、新しい問題が起きる。

AIは、下流の分析資料に書かれた内容を、上流の事実だと思って再利用することがある。

たとえば、

一次資料
  ↓
転記
  ↓
整理
  ↓
分析
  ↓
戦略案

という5段階があったとして、戦略案だけを見たAIが、その中の推論を「確認済みの事実」として扱う可能性がある。

ファイル数より、参照方向の管理が問題になった。

3. そこで「00番」を作った

40ファイルを超えたところで、先頭に00というファイルを作った。

最初の役割は単純だった。

AI向けREADMEである。

00には、

この案件は何を扱っているか
どの番号に何が入っているか
最初に何を読むか
どの資料がどの資料から作られたか
原本へ戻る必要があるのはどんなときか

を書いた。

ファイルを増やすほど、AIには「情報」より先に地図が必要になる。

この時点で、私の関心はコンテキスト量からコンテキストのルーティングへ移った。

4. READMEだった00番を「正典」に変えた

次の問題は、時間だった。

長期案件では、昨日正しいと思っていた分析が今日ひっくり返る。

実際にAIへ何度も起きた。

タイトルだけ見てファイルの役割を誤認する
規程名だけ検索し、「存在しない」と判断する
逐語録の一発言を制度上の事実だと思う
条件の似た二つの文書を同じ構造だと扱う
古い分析を新しい一次資料より優先する

過去資料を全部修正して回るのは現実的ではない。

そこで00番へ、もうひとつ役割を持たせた。

**「現在、何を採用するか」を管理する正典（canonical document）**である。

ここで大事なのは、過去の間違いを消さないことだった。

私は次のようにした。

原本          → 消さない
古い分析      → 消さない
失敗した仮説  → 必要なら残す
現在の採用判断 → 00に置く

つまり、履歴を書き換えるのではなく、現在の解釈だけ一か所に集約する。

Gitでいえば、過去コミットを全部書き換えるのではなく、現在のHEADがどこかを明示する感覚に近い。

5. 「全部読め」では品質は上がらなかった

Google Driveを直接検索できると分かったとき、一見すると問題は解決したように思えた。

25ファイル制限を気にする必要がない。

では毎回全部読ませればいいか。

実際には違った。

資料が100個あれば、100個読むほど良いとは限らない。

ノイズが増えるし、コストも増える。重要な一次資料が、大量の派生資料に埋まる。

必要だったのは「全部読む」ではなく、

どんな問いのとき、どこまで探索すればよいか

というルールだった。

6. 「深掘り」をプロンプトではなく運用規則にした

そこで、00番とは別に深掘り調査ルールを作った。

通常の質問では、

00
↓
必要最小限の関連資料
↓
回答

で終える。

一方、「深掘りして」「全部追って」と指定したときだけ、探索モードを変える。

深掘りルールの主要部分は、次のようなものだ。

最初の有力資料で止まらない

ひとつ答えらしきものが見つかっても終了しない。

別時点、別媒体、別人物、反対方向の資料を探す。

ファイル番号ではなく「資料種別×論点」で探す

「11番と12番を読む」のように固定しない。

逐語録
メール
チャット
規程
公式資料
状態ログ
過去レビュー

などの種別から、人物・期間・論点で候補を探す。

ファイルが増えても探索ルールが壊れにくい。

反証を必ず探す

自説に合う資料だけで止めない。

ただし、ここにはもう一段ある。

反証の前提も検証する。

相手側に有利に見える説明でも、その制度理解が間違っていれば反証としての重さは変わる。

矛盾を勝手に解消しない

二つの資料が食い違ったら、AIが「たぶんこういう意味だろう」で丸めない。

日時・情報源・確度を付けて両方残す。

探索終了条件を持つ

「何となく十分読んだ」で終わらせない。

主要候補について、

確認済み
未確認
該当なし
原資料未取得

を区別する。

7. これで普通のChatでも「深く調べる方法」を持てるようになった

ここが、自分にとって一番大きかった。

高コストなWorkを毎回使わなくても、普通のChatが、

00で現在地を理解する
深掘りルールを読む
Driveから候補を探す
一次資料へ戻る
反証を探す
未確認を未確認のまま残す

という手順を再現できるようになった。

重要だったのはモデルへ知識を詰め込んだことではない。

「どう調べるか」を外部ファイルへ出したことだった。

私はこれを、AIの性能拡張というより探索手順の永続化だと考えている。

8. さらに「AIの答え」自体を監査対象にした

運用を続けると、もう一段問題が出た。

AIはセルフレビューさせても間違える。

なので、

「自分の回答をレビューして」

だけでは足りない。

実際には、次のような多段階レビューを使うようになった。

1. 初回案
2. 自己レビュー
3. 修正版
4. 修正版をもう一度レビュー
5. MD等へ書き出して会話コンテキストから切り離す
6. 「他人の文書だと思ってレビュー」
7. 必要なら別セッション／別モデルへ渡す

これは同じAIに「もっと考えて」と言っているのではない。

役割・視点・コンテキストを変えている。

9. 「既知の間違い」をテストケースとして残す

AI品質を「今回は賢そうだった」で評価するのをやめた。

過去に実際に誤判定した論点を、テストケースとして残す。

概念的にはこうだ。

known_trap = {
    "premise": "一見すると違反に見える",
    "hidden_evidence": "別資料に例外条件が存在",
    "expected": "断定せず、追加資料を探す"
}

if ai_conclusion == "即断":
    reject_current_review()

既知の落とし穴を踏むなら、その回の「網羅的レビュー」は信用しない。

これはLLMを信用するのではなく、LLMをテストする発想である。

10. 複数AIは多数決させない

最近はClaudeとChatGPTを両方使っている。

ただし、

Claudeに聞く
ChatGPTに聞く
同じ答えなら正解

とはしない。

少なくとも私の実際のセッションでは、傾向に差があった。

Claude側で役立った傾向

強い仮説を早めに出す
「この事実をどう使えるか」まで進む
非対称や交渉上のレバレッジを拾う

ChatGPT側で役立った傾向

主語・条件節・時点を細かく照合する
一次資料の射程を超えた断定を止める
外部へ出せる表現まで落とす

これは「Claudeは攻め、ChatGPTは守り」という一般論ではない。

私の案件・セッションで観察された差として扱っている。

そして差が出たら、平均しない。

強い仮説
    +
安全に確定できる表現

を両方保存する。

証明できないが価値のあるものは「内部仮説」に落とす。

最終的な強度はAIの多数決ではなく、原本・録音・メール等の証拠階層で決める。

11. 今の構造

現在のイメージを単純化するとこうなる。

                  ┌─────────────┐
                  │   00 正典    │
                  │ 現在地・地図 │
                  └──────┬──────┘
                         │
             ┌───────────┴───────────┐
             │                       │
       通常ルート               深掘りルート
             │                       │
      必要最小限だけ          深掘り調査ルール
             │                       │
             └───────────┬───────────┘
                         ↓
                Google Drive資料群
                         ↓
                一次資料へロールバック
                         ↓
              AIレビュー／相互監査
                         ↓
                  人間が採否判断
                         ↓
               学習事項を00へ還流

00は巨大な知識ファイルではない。

AIが必要な知識へ戻るためのルータである。

12. 最小構成で真似するなら

ここまで大規模にする必要はない。

長期プロジェクトなら、私はまず4ファイルで始める。

`00_CANON.md`

プロジェクトの目的
現在の確定事項
資料マップ
読み順
重要な訂正履歴

`SOURCE_MAP.md`

一次資料
転記
整理資料
分析資料
外部提出物

の対応関係。

`DEEP_DIVE_RULES.md`

最初の資料で止まらない
反証を探す
未確認を埋めない
一次資料へ戻る
探索終了条件

`KNOWN_FAILURES.md`

過去のAI誤読と、正しい判定条件。

これだけでも、単にチャット履歴へ依存するよりかなり強い。

13. バックアップもAI運用の一部になった

AIにファイル編集まで任せるなら、バックアップは別問題ではない。

私の現在の手順は、

バックアップ作成
↓
元ファイルとバックアップを再取得
↓
一致確認
↓
本体編集
↓
編集後に再取得
↓
意図した差分だけか確認

である。

ポイントは「バックアップを作った」とAIが報告したことを信用しないこと。

復旧点として本当に同じものが存在するかまで確認する。

生成AIをファイルシステムへ接続すると、文章生成能力だけでなく、変更管理まで設計対象になる。

14. 一番大きかった学び

最初は「25ファイルしか入らない」と思って、20ファイルへ圧縮した。

今はDriveから大量の資料を直接探せる。

技術的な制限はかなり変わった。

それでも、最初に作った情報構造は無駄にならなかった。

むしろ資料へ自由にアクセスできるようになったからこそ、

何を読むか
何を読まないか
どの順番で読むか
どこまで戻れば事実なのか
いつ探索を終えるか

の価値が上がった。

結局、私が作っていたのは「AIの記憶」ではなかった。

AIが何度でも文脈を復元するための外部OSだった。

まとめ

長期案件で私が一番効いたと感じているのは、巨大なプロンプトでも、特定モデルへの乗り換えでもない。

次の5つだった。

入口となる正典を一つ作る
原本→整理→分析→戦略の参照方向を管理する
深掘りの探索手順を外部化する
AI成果物そのものを監査する
複数AIは多数決ではなく役割分担する

AIは忘れる。

モデルも変わる。

セッションも切れる。

だから、記憶を永続化するより、

忘れても戻れる仕組みを作る。

今のところ、それが一番壊れにくかった。

補足：この記事自体について

この記事は、実際に長期案件を複数AIと運用する中で作った情報管理・監査手順を、案件固有情報を除いて一般化したものです。

特定モデルの性能比較を目的としたものではありません。モデルごとの役割差も、私の実際のセッションで観測された挙動を運用へ取り込んだものです。