あなたのAIエージェントは、あなたが伝えた内容の半分をすでに忘れている

本記事は、エージェンティックエンジニアリングとAI駆動開発に関するシリーズの第7回目です。前回の記事ではコンテキストとその管理について述べ、実用的なヒントを提供することを約束しました。当初は、OctobatchとQuality Playbook（オープンソースプロジェクト）を構築する際に私が使用した具体的なコンテキスト管理テクニックを紹介するつもりでした。これらのプロジェクトでは、Claude CodeやCursorなどのAIツールがすべてのコードを書き、私はAIと協力してすべての作業を計画・調整しています。しかし、この記事を書いているうちに、これらのテクニックを記事執筆にも適応していることに気づきました。それは驚きでした！私はAIスキルを開発する人々がコンテキスト管理を改善し、スキルをより効率的に実行できるようにするための方法を探してきました。結局、これらの同じテクニックは、Claude.aiやChatGPTのようなチャットボットを使用している場合でも、AIツールを使用するすべての人に適用できることがわかりました。

開示：私はこの記事シリーズを管理するために複数のAIツールを使用しています。私の主要なツールは、ブレインストーミングと記事のリサーチ、ノート、バックログ管理のためのClaude Cowork、そして机を離れているときにドラフトを読み上げてノートを取るためのGeminiモバイルアプリです。これらのツールを使用中に起こった出来事をお話しします。なぜなら、コンテキスト管理が開発者だけの問題ではないことを示す良い例だからです。

この記事を書いている間、私はGeminiモバイルアプリを使ってドラフトを読み上げ、ノートを取っていました。セッションの途中で、以前のノートがまだ組み込まれていないか確認するよう依頼したところ、以前のノートにアクセスできないと言われました。これは奇妙で非常識に思えました。なぜなら、そのノートはセッション内の数プロンプト前に取ったばかりだからです。会話を遡って以前のノートを見ることはできましたが、なぜかそのノートを「知らない」状態でした。

何が起こったかというと、Geminiが私に知らせずに会話を圧縮し、セッション前半のノートが…消えてしまったのです。ウェブチャットAIが以前に話したことを忘れたように見える経験があるなら、私と同じようにコンテキスト圧縮を体験したことになります。コンテキストとコンテキストウィンドウの基本を理解するだけでも、そのようなフラストレーションを防ぐのに大きな違いをもたらします。

このことは、20年以上前に『Applied Software Project Management』（2005年）で書いた内容を思い出させました：「議論の中で発見された重要な情報は、開発プロセス中にチームが参照する必要があり、その情報が文書化されていない場合、チームは同じ議論を繰り返さなければならない。」これは人間のチームとプロジェクト会議について書いたものですが、AIセッションにも同様に当てはまります。

これでコンテキストの話題に戻ります。前回の記事で書いたコンテキストは、次の記事でも取り上げます。なぜなら、AIと協働する際に最も重要な概念の一つだからです。

**コンテキストの喪失は目に見えませんが、それでもフラストレーションを引き起こします**

コンテキストとは、会話中にAIがワーキングメモリとして保持するすべてのものです：あなたが伝えたこと、AIがあなたに伝えたこと、読み込んだファイルや指示、システムがその過程で作成した内部メモなど。これらすべては固定サイズのコンテキストウィンドウ（AIの短期記憶、現在考えているもの）に収められており、ウィンドウがいっぱいになると、AIは何かを手放さなければなりません。ツールによって処理方法は異なります：古いメッセージを切り捨てるもの、会話を要約に圧縮するもの（要約は完全に見えても詳細は失われます）、一貫性のない動作を始めるものがあり、AIが何かを忘れたのか、最初から理解していなかったのか判断できなくなります。結果は同じです：AIはあなたが伝えたこと、共同で決定したこと、セッションの初期に気づいた詳細を失います。そして、忘れたことを教えてくれません。残っている情報に基づいて、自信に満ちた出力を生成し続けるだけです。

さらに詳しく説明する前に、専門用語を確認しましょう。「スキル」と「エージェント」という用語を見かけたことがあるかもしれませんが、スキルはAIのライブラリ、エージェントは対話型の実行可能ファイルと考えてください。完全に正確な定義ではありませんが、開発者であればこの議論には十分です。

スキルやエージェントをコーディングする際、すぐにコンテキストの問題に直面します。AIに任せる作業は複雑であることが多く、コンテキストウィンドウがすぐにいっぱいになり、AIは圧縮を開始します：会話の古い部分を圧縮または削除して新しい情報のためのスペースを作ります。圧縮は常に最もフラストレーションがたまり、不便なタイミングで発生するように思えます。考えてみれば当然です。最も多くの情報を会話に投入したまさにその時にコンテキスト制限に達し、その情報を失うことが最も大きなコストとなるのです。

そのため、AIを人間のチームと同じ欠点を持ちながら、AIの性質によってその欠点が増幅されたものと考えると役立つことがよくあります。先週の会議で何かを忘れた人間は、思い出させてもらえば覚えているかもしれません。コンテキスト圧縮で情報を失ったAIは、情報が消えているため覚えていません。しかし、あなたにもできることがあります。そして、そのテクニックは、自律型AIスキルを構築している場合でも、単にチャットボットに20分前に伝えたことを覚えさせようとしている場合でも同じであることがわかりました。

私が繰り返し使う4つのテクニックにたどり着きました。それぞれのテクニックは、ある時点でAIが重要な何かを忘れ、その情報をファイルに保存することで対応したことに由来しています。特別なツールは必要ありません。そして驚いたことに、これらのテクニックはすべて、ソフトウェア構築とこのような執筆プロジェクトの管理の両方に有用であることが判明しました。Claude、ChatGPT、Geminiとチャットしているときでも、Claude CoworkやCodexのようなデスクトップツールを使用しているときでも同じです。以下が私が最も価値があると考えるテクニックです：

1. **探索と文書作成を分離する**：AIに一度のパスで何かを解明させ、同時にフォーマットされた出力を生成するよう求めないでください。

1. **継続プロンプトではなくハンドオフ文書を使用する**：古いセッションを閉じる前に、次のセッションが知る必要があるすべてをAIに書き留めさせてください。

1. **手順ではなく受入基準をAIに与える**：「完了」の状態を伝え、ステップを詳細に説明しないでください。

1. **仕様書をAIツール間のブリッジとして使用する**：共有文書を、すべてのツールが読み取る単一の真実の情報源にします。

**探索と文書作成の分離**

AIに複雑なタスクを依頼するとき、気づかないうちに2つのことを同時に依頼していることがよくあります。それは、何かを解明することと、フォーマットされた出力を生成することです。問題は、解明には注意力が必要であり、出力の生成にも注意力が必要であり、モデルが持つ注意力は限られていることです。同じプロンプトで両方のタスクを組み合わせると、モデルはどちらかを手抜きし始め、どちらを手抜きしたかを判断できません。

私はQuality Playbook（任意のコードベースに対して構造化コードレビューを実行するオープンソースのAIコーディングスキル）でこれに遭遇しました。その機能の1つは、ソースコードから要件を導出することです：コードを読み取り、コードが約束する動作（私はこれを行動契約と呼びます）を特定し、要件文書を生成します。当初、これはすべて1回のパスで行われていました。問題は、1回のパスでの要件生成が約70件の要件で注意力を使い果たしてしまうことでした。モデルはコード内で以前に気づいた行動契約を忘れてしまい、その忘却は完全に見えませんでした。スタックトレースやエラーメッセージはなく、不完全な出力が残り、何が欠けているかを知る方法もありませんでした。私は作業を2つの独立したプロンプトに分割することで修正しました：

• 各ソースファイルを読み取り、観察したすべての行動契約をCONTRACTS.mdにシンプルなリストとして書き留めてください。
• CONTRACTS.mdとドキュメントを読み取り、そこから要件を導出してREQUIREMENTS.mdに書き込んでください。

そして3回目のパスで、すべての契約に対応する要件があるかをチェックし、ギャップがあれば、ギャップのあるファイルに対してステップ1に戻ります。重要なのは、CONTRACTS.mdが外部メモリであることです。モデルが以前に気づいた行動契約を「忘れた」場合、その忘却は通常見えません。しかし契約ファイルを使えば、すべての観察結果が要件作業の開始前に記録されるため、カバーされていない契約は目に見える検索可能なギャップとなります。何が忘れられたかを確認し、修正できます。

原則：AIに、何が存在するかを解明し、同時にフォーマットされた出力を書くよう要求しないでください。モデルは両方を同時に行おうとして注意力を使い果たします。AIに複雑なタスクを依頼するときは、実際には2つのことを同時に依頼していないか考えてください。「このコードベースを分析してレポートを書く」は2つのタスクです。「この文書を読んで改善案を提案する」は2つのタスクです。それらを分割し、最初のパスで観察結果をファイルに書き込ませてから、2回目のパスでそれらを処理させましょう。

**継続プロンプトではなくハンドオフ文書を使用する**

AIコーディングツールと長時間のセッションを経験したことのある人なら誰でも、コンテキストが古くなり始める瞬間を感じたことがあるでしょう。AIは1時間前には問題なく処理していた詳細を追跡できなくなったり、以前言ったことと矛盾したりします。セッションは遅くなり、AIが行き詰まってあなたが伝えた情報でいっぱいになったように見えるため、しばしば再起動する必要があります。このまま続ければ、修正に多くの時間を費やして進歩が得られないという感覚があります。

ほとんどの開発者は、セッションが長くなりすぎた場合、2つの方法のいずれかで対応します：問題を押し通すか、新しいセッションを開始してすべてをゼロから説明し直そうとします。どちらのアプローチもコンテキストを失う原因になります：前者は圧縮による損失、後者は不完全な再説明による損失です。そしてどちらもフラストレーションがたまります！特に、AIとそのコンテキストを構築するために多くの時間を費やした直後だからです。

3つ目の選択肢があります。セッションを閉じる前に、AIにハンドオフ文書を書かせてください：次のセッションが知る必要があるすべてを捉えたファイルで、現在のセッションが完全なコンテキストを持っている間に書かれます。重要なのは、関連する詳細がまだ作業コンテキストに新鮮なうちに、そしてそれ自体または別のAIが読める形式で書くようAIに依頼することです。

私はこれをQuality Playbookに、フェーズ間の通信の中核として組み込みました。Playbookを単一のプロンプトから独立したフェーズに分割したとき、各フェーズをコンテキストの継承なしで完全に独立したセッションとして実行する必要がありました。そのため、各フェーズはスタンドアロンの起動プロンプトファイルを持ちます。各起動プロンプトは次の構造に従います：新しいセッションがこの作業をコールドスタートで引き継げるようなハンドオフ文書を書いてください。知る必要があるすべてを含めてください。各起動プロンプトは、前のフェーズが何を達成したかから始まり、何が凍結されているかについての明確な境界を含み、残りの作業の各部分がどの将来のフェーズに属するかを名前指定します。そうしないと、AIがまだフェーズ2にいる間に親切にフェーズ3の作業を始めてしまうからです。各フェーズはまた、完了したエージェントが次のセッションが知る必要があることを書き留める、必須の将来を見据えたハンドオフで終わります。

原則：各ハンドオフは完全な状態スナップショットです。入ってくるAIエージェントは、以前の起動プロンプトやチャット履歴を読む必要はありません。必要なものはすべて現在のハンドオフファイルにあります：現在の状態、未コミットの変更など。

（記事は長いため、ここでは核心部分のみを提示しています。元の記事では、「受入基準の提示」と「仕様書をブリッジとして使用する」という2つのテクニックとまとめについても議論されています。）