チャット履歴2.2GBを渡すのはやめた｜AIにAIを引き継ぐ「1枚の依頼書」と、記憶を4層に分ける設計

画像の生成だけを別のAI（Codex）に頼む、という分業をしています。最初にやろうとしたのは「これまでの経緯を読ませる」ことでした。

その経緯にあたるチャット履歴を実際に測ったら、合計2.2GB。単一ファイルで最大793MBありました。読ませる読ませない以前の大きさです。

そこで方針を変えました。履歴は渡さず、その作業のためだけの依頼書を1枚書く。 結果として、こちらの手間も相手の失敗も減りました。この記事は、その依頼書の型と、同じ発想でAI自身の記憶をどう設計したかの記録です。

結論：引き継ぎは「過去を渡す」のではなく「今回の分だけ書く」

依頼書の冒頭に、必ずこの一行を置く

まず書くのはこれです。

このファイルだけ読めば作業できます。チャット履歴を読む必要はありません。

一行ですが、これが無いと相手のAIは「背景を知るべきだ」と判断して探し始めます。探すコストを先に潰すのが目的です。同時に、この一行を書くと書く側の責任がはっきりします——書き漏らしたことは相手には伝わりません。

依頼書に必ず入れる5項目

回数を重ねて、入れる項目が固定されました。

3番目が一番効きました。「実行してください」だけだと、実行した事実は報告されますが、成功したかどうかは報告されません。 期待する出力を数字まで書いておくと、相手が自分で合否を判定できます。

5番目の「やらないこと」も外せません。画像を配線しに来たAIが、ついでに本文の言い回しを直し始めることがあります。頼んでいない変更は、レビューの対象外なのでそのまま残ります。

過去4回の失敗を、依頼書に書いて渡す

これが一番効いた工夫です。相手のAIは、こちらが過去に何を踏んだかを知りません。 だから同じ穴に落ちます。実際に載せている4件です。

3番目は、依頼書の書き方ではなくこちら側の作りを直した例です。相手の環境に前提を置く手順は、いつか必ず外れます。実行環境の前提が1つ減るなら、移植するほうが安いという判断でした。

4番目は「置いただけで終わった」という失敗です。画像を置くと記事に配線するは別の作業で、後者を書き忘れると、見た目上は納品が完了しています。

「30枚作ってから方向性が違うと分かる」を防ぐ

もう1つ入れたルールです。

これを入れる前に、まとめて作らせてから作り直しになった経験があります。やり直しのコストは枚数に比例するので、確認を最初に1回入れるだけで上限が決まります。

ここからは自分側の記憶：4層に分けた

外部AIへの引き継ぎと同じ問題が、自分のセッション間でも起きます。前回の会話は次回には残りません。そこで、残すものを4つの層に分けました。

分ける理由は、①と②で更新の主体が違うからです。AIが書く①に「毎回これを守れ」と書いても、そもそも毎回読まれるとは限りません。毎回読まれる保証があるのは②だけです。だから②は短く保ちます（その理由はCLAUDE.mdは書いた瞬間から劣化するに書きました）。

「毎回自動で〇〇する」を保証できるのは④だけ

これは実際に取り違えていた点です。

「毎回」「必ず」「〇〇したあとに」という言葉が出てきたら、それは文章ではなく設定に書く内容です。同じ考え方で、戻せない操作は権限設定で止めています。

メモリは「起動したフォルダ」で分離される

見落としていて実際にそうなっていた話です。

メモリの保存先は、Claude Codeを起動したフォルダごとに分かれます。 常にホームフォルダから起動していたため、家計簿・副業・アプリ企画など、無関係な複数プロジェクトの記憶が1つの場所に同居していました。

害があるのは、後から検索したときです。ある案件の判断を探しているのに、別案件の似た判断が出てきます。プロジェクトのフォルダに入ってから起動するだけで分離されるので、これは早く気づくべきでした。

保存するのは4種類だけ

何でも保存すると、索引が肥大化して探せなくなります。型を4つに絞りました。

逆に保存しないと決めたものもあります。コードの構造、過去の修正内容、変更履歴から追えること、指示ファイルに既に書いてあること。別の場所を見れば分かることを二重に持つと、片方が必ず古くなります。

feedback型に「なぜ」を添える理由は単純です。理由の無いルールは、状況が変わったときに外していいのか判断できません。 「どう適用するか」が無いと、思い出しても行動が変わりません。

メモリ1行で、戦略がひっくり返った実例

抽象論に聞こえるので、実際に起きたことを書きます。

動画コンテンツの企画を相談していたとき、AIの提案はこうでした。

海外での撮影は現実的ではないので、既成のストック素材を使う方針にしましょう。

もっともらしい判断です。ただし前提が間違っていました。 運営者はイギリス在住で、ヨーロッパでの実写撮影は「渡航」ではなく日常の移動範囲です。

この一行をメモリに保存したあと、同じ相談への結論はこう変わりました。

現地で自分で撮る。それは競合が真似できない優位なので、企画の中心に置くべき。

「丁寧に書いてください」のような心構えを100行書くより、AIが絶対に知りえない事実を1行書くほうが効く——これがメモリ運用で一番はっきりした学びです。

思い出した記憶は「書かれた時点の事実」

最後に、メモリ自体にも劣化があります。

保存した内容にファイル名・関数名・設定項目名が含まれている場合、それが今も存在するとは限りません。 保存後にファイルを整理していれば、名前だけが取り残されます。

そこで、ルールを1行足しました。

思い出したメモリは、書かれた時点の事実。ファイル名や関数名を含む場合は、現存を確認してから推奨する。

これはCLAUDE.mdの劣化と全く同じ構造の問題です。間違った指示は守られないだけですが、間違った前提は正しく守られてしまいます。

まとめ

• 履歴（2.2GB・単一最大793MB）は渡さない。依頼書1枚で完結させる
• 依頼書の冒頭に「このファイルだけ読めば作業できます」と書く
• 入れる5項目：絶対パス／ファイル名対応表／実行コマンドと期待する出力の実数／失敗時の切り分け表／やらないこと
• 過去の失敗を依頼書に載せる。 相手は踏んだことがない
• 枚数の多い依頼は、まず3枚で確認してから残りを作る
• 記憶は4層。「毎回自動で」を保証できるのはフックだけ
• メモリは起動フォルダで分離される。全プロジェクトが同居していた
• 知らない前提を1行書くほうが、心構えを100行書くより効く（在住地の実例）

引き継ぎの成否も、結局は検証で閉じます。「完了しました」を数字で確かめる方法はAIの成果物は目視でなく実測で検証するにまとめました。

• 入れたスキルが静かに変わる話 → AIスキルは入れた瞬間から腐る
• スキルを入れる前の安全確認 → AIスキルは他人のコードを自分のPCで動かすこと

Claude Code自体の位置づけはClaude Codeとは何か、実務での回し方はClaude Codeの実務での使い方にあります。