AIDANエイダン
ログイン

第3章 コンテキスト・メモリ・状態

学習目標

  • コンテキスト劣化と注意予算を説明し、コンテキストに入れる情報の選定基準を設けます。
  • 圧縮、ツール結果の整理、構造化メモ、サブエージェントから、タスクの性質に合う手法を選びます。
  • 会話履歴・タスク状態・長期記憶・業務上の正本を区別し、長時間実行でのコンテキスト汚染を防ぎます。
  • チェックポイントと冪等性によって中断後の再開を設計し、再開時の外部状態を確認します。
  • 複数セッションにまたがるタスクを、次の実行者が引き継げる構成にします。

はじめに

2日間のタスクを任せたエージェントが、2日目の午後に妙なことを言います。「作業はほぼ終わりました」。確認すると、半分は手つかずで、初日の午前にチームと合意したルールの一つは跡形もなく消えています。エージェントが怠けたのではありません。その間にコンテキストは何度も満杯になり、そのたびに要約に置き換えられました。要約は流れをつなぎましたが、正確な状態は守れなかったのです。

人でいえば、メモを取らず記憶だけで長期プロジェクトを進めるようなものです。この章では、エージェントにメモ帳と業務日誌を持たせる方法を扱います。何をコンテキストに入れ、何を外に置くか、圧縮・外部メモリ・サブエージェントをどう選ぶか、汚染をどう防ぐかを整理し、チェックポイント、再開、引き継ぎへ進みます。

重要な概念

コンテキストは有限の予算である

Anthropicはコンテキストエンジニアリングを、推論中にモデルへ渡す最適なトークン集合を選び、維持する戦略全体と定義しています。プロンプトエンジニアリングが指示文を磨く作業だとすれば、コンテキストエンジニアリングは、システムプロンプト、ツール定義、ツール結果、メッセージ履歴、外部データまで、モデルが見るものすべてを扱います。

根拠となるのはコンテキスト劣化（context rot）です。コンテキスト内のトークンが増えるほど、そこにある情報を正確に思い出す能力が下がるという観察です。同じ記事は、LLMには注意予算（attention budget）があると説明しています。Transformerは各トークンとコンテキスト内の他のトークンとの関係を計算するため、関係の数はトークン数の二乗（n²）に比例して増え、トークンが増えるほど注意（アテンション）が分散します。新しいトークンは一つずつ、この予算を使います。

たとえるなら、コンテキストは机の上の空間です。机が広くても、書類をすべて広げると今必要な一枚を見つけにくくなります。ウィンドウが大きいとは、多く入れられるという意味であり、入れたものを同じようにうまく使えるという意味ではありません。

何を入れるか：高度、ツール、例

同じ記事は、コンテキストの構成要素ごとに基準を示しています。

要素 避けること 目指すこと
システムプロンプト 複雑で壊れやすいif-elseロジックの埋め込み、逆に具体的な手掛かりのない漠然とした指針 行動を導けるほど具体的で、柔軟でもある「適切な高度」
ツール 機能が広すぎる、または使うツールの判断があいまいになる肥大したツール群 人間のエンジニアが見ても、どのツールを使うべきか即座に判断できる構成
例 境界事例をすべて並べた一覧 期待する行動をよく示す、多様で代表的な少数の例

「適切な高度」は飛行機の高度にたとえた表現です。低すぎれば地形の一つ一つにぶつかり、高すぎれば目的地が見えません。例外180件をルールとして列挙したプロンプトは、一つ直すたびに別の事例が壊れます。原則と代表例に置き換え、期待する行動は評価セット（第4章）で守るほうが維持しやすくなります。

必要時の検索と段階的な開示

すべてのデータを事前に入れる代わりに、ファイルパス・保存済みクエリ・リンクなどの軽量な識別子だけを持ち、必要時にツールで取得する方式を必要時の検索（just-in-time retrieval）と呼びます。Claude Codeは大きなデータを丸ごと読まず、headやtailなどのコマンドで必要な部分だけを見ます。エージェントが探索しながら必要な文脈を少しずつ見つけることを、段階的な開示（progressive disclosure）と呼びます。人が本全体を暗記せず、目次やしおりを使うのと同じです。

必要時の検索が常に優れるわけではありません。実行中の探索は、事前に入れるより遅いからです。そのため同記事は混合戦略を紹介しています。Claude CodeはCLAUDE.mdを最初から入れ、他のファイルはglobやgrepで随時探します。ほぼ毎回必要な安定した資料は事前に、大きく頻繁に変わる資料は検索して使う方式です。法律や金融のように文脈の変動が比較的少ない分野では、事前に入れる割合を増やせます。

検索に成功しても、正解を見つけたとは限りません。検索結果には、出典の信頼性、文書の適用時点、現在のユーザーのアクセス権限を伴わせる必要があります。根拠を見つけられないときに「存在しない」と断定せず「見つからなかった」と言わせることも、検索設計の一部です。

情報の四つの層

長時間実行システムには、性質の異なる四つの情報があります。混同すると事故につながります。

層 例 権威 寿命
会話履歴 メッセージとツール結果 低い。要約・切り詰めが起こる セッション
タスク状態 進捗ファイル、チェックポイント 再開の根拠 タスク完了まで
長期記憶 ユーザーの好み、学んだ教訓 参考資料。検証が必要 定めた有効期限まで
業務上の正本 注文、送金、承認の記録 最も高い。事実の基準 法律・業務上の保存期間

業務上の正本（system of record）は、業務上の事実の最終的な基準となるシステムです。エージェントが「返金を処理した」と記憶しても、実際に返金したかは決済システムの台帳が決めます。再開時の次の作業を決める根拠は、会話履歴ではなくタスク状態です。タスク状態と正本が食い違えば、正本を優先します。

圧縮とツール結果の整理

圧縮（compaction）は、ウィンドウが上限に近づくと会話を要約し、その要約で新しいウィンドウを始める手法です。Anthropicは、よい圧縮はアーキテクチャ上の決定、未解決のバグ、実装の詳細を残し、重複するツール出力を捨てると説明しています。圧縮用プロンプトは、まず漏れをなくす方向（再現率）で調整し、次に余分を減らす方向（適合率）で調整するよう勧めています。

最も軽く安全な圧縮は、ツール結果の整理です。会話の奥に残るツール結果の原文は、通常は再読不要だからです。プラットフォームの機能もあります。Claude APIのコンテキスト編集（context editing）は、サーバー側で古いツール結果を消す戦略を提供し、開始条件（trigger）、直近に残す個数（keep）、一度に削除する最小量（clear_at_least）、削除しないツール（exclude_tools）を設定できます。Claude APIにはサーバー側の圧縮（ベータ）もあり、OpenAI Agents SDKにはセッション履歴をResponses APIで圧縮するセッション実装があります。名前やオプションは変わり得るため、ドキュメントを確認してください。

注意

要約は流れをつなぎますが、正確な状態を守れない場合があります。「どこまで済んだか」「何を決めたか」など正確さが必要な情報は、圧縮に任せず、コンテキスト外の構造化記録として置いてください。

構造化メモと外部メモリ

構造化メモは、エージェントがコンテキストウィンドウの外にメモを書き、後で読み直す手法です。Anthropicの例は、Claude Codeのタスクリスト、NOTES.mdファイル、数千ステップにわたって進捗と地図を記録したポケモンのゲーム実験です。明確な節目のある反復タスクに適します。

これを製品機能にしたのがメモリツールです。Claudeのメモリツールはクライアント側で動きます。モデルが/memories以下のファイル操作を要求すると、アプリケーションのハンドラーが自ら定めた保存先で実行するため、安全対策もアプリケーションの責任です。文書は、すべてのパスを正規化して/memoriesの外に出ないか検証し（../などのパストラバーサル攻撃を防止）、機密情報を除き、ファイルサイズを制限し、長く使っていないファイルを削除するよう勧めています。

Google ADKは二つの層を区別します。セッションと状態は現在の一つの会話の短期記憶で、メモリサービスは過去の複数の会話から検索して使う長期記憶の保存先です（add_session_to_memoryで追加し、search_memoryで探します）。開発用のインメモリ実装は再起動で消えるため、運用では永続化された実装を使います。

サブエージェントでコンテキストを隔離する

サブエージェント構成は、専門化したサブエージェントが新しいウィンドウで集中的に作業し、圧縮した結果だけを返す方式です。Anthropicによると、サブエージェントは数万トークンを探索しても、通常は1,000〜2,000トークンの要約を返します。探索のノイズが主エージェントのウィンドウに入らず、主エージェントは統合と判断に集中できます。並列探索が有利な複雑な調査に適しています。

要約では困る結果もあります。表やコードのように一文字も変えてはいけない成果物を主エージェントが転記すると、コンテキストを占有し、転記ミスも生じます。Anthropicのリサーチシステムは、サブエージェントが結果を外部ストレージ（ファイルなど）へ書き、軽量な参照（ファイルパス、ストレージキーなど）だけを返すことで、情報の欠落とトークンの浪費を減らしました。同記事は、コンテキストが200,000トークンを超えると切り詰められるため、リードエージェントが計画をメモリに保存する方法も紹介しています。

三つの手法の用途は次のように整理できます。

手法 適したタスク 失われ得るもの
圧縮 長いやり取りが必要なタスク 正確な状態、初期の決定
構造化メモ 節目が明確な反復タスク メモに書かなかったこと
サブエージェント 並列探索が有利な調査 要約から落ちた詳細（原文は参照で保持）

コンテキスト汚染を防ぐ

コンテキスト汚染は、誤った、古い、または信頼できない情報が蓄積し、その後の判断を継続的にゆがめる現象です。原因は三つあります。失敗した試行の痕跡（同じエラーを出す試行が並び、モデルがその経路にとらわれること）、信頼できない内容（Webページや文書内の指示）、古い記憶（すでに変わった事実）です。

防ぐためのルールは次のとおりです。

  1. 役目を終えたツール結果の原文を削除し、必要な要点と参照だけを残す。
  2. 同じ失敗が続いたら失敗記録を一行の要約に縮め、新しい方法を明示して再開する。必要なら新しいサブエージェントに任せる。
  3. 外部の内容は出典を示して指示と区別し、中の文を指示として実行しない（第5章）。
  4. 記憶項目には出典と観察時刻を付け、古い項目は再確認するか破棄する。
  5. ユーザーの発言を検証せずシステム指示のレベルへ引き上げない。記憶はデータであり、権限ではない。

プロンプトキャッシュとコンテキスト構成

長時間実行エージェントは、似た先頭部分を数十、数百回再送します。プロンプトキャッシュは、この反復する先頭部分（prefix）の処理を再利用し、コストとレイテンシを減らします。Claude API文書では、キャッシュはtools、system、messagesの順に先頭部分を構成し、ある層が変わるとその層と後ろの全層が無効になります。ツール定義の変更は全キャッシュを無効にします。デフォルトの寿命は5分で、利用のたびに更新され、1時間のオプションもあります。モデルごとにキャッシュ可能な最小長があり、それより短い先頭部分は指定してもキャッシュされません。応答のcache_read_input_tokensとcache_creation_input_tokensでヒットを確認します。

よくあるキャッシュ無効化の原因は、毎回変わる値（現在時刻、リクエスト番号）を固定指示より前に置くこと、ツール定義を毎回作り直して内容や順序を変えること、キー順がランダムなJSONシリアライズを使うことです。変わらないものを前に、変わるものを後ろに置くのが原則です。ツール結果の整理もキャッシュと競合します。削除位置以降が無効になるため、文書は一度に十分な量を削除し、無効化の代償に見合うようにすること（clear_at_least）を勧めています。

チェックポイントと冪等性

外部に影響する長時間タスクは、失敗時に最初からやり直してはいけません。Anthropicのリサーチシステムの記事は、エージェントは状態を持ち、誤りが蓄積すると指摘し、エラー地点から再開するシステムに、再試行ロジックや定期チェックポイントなどの決定的な安全装置を組み合わせたと記しています。小さな失敗でも致命的になり得るため、ツールが失敗している事実をエージェントに知らせることも勧めています。

チェックポイントは、再開できるよう段階ごとの結果を永続保存した地点で、冪等キーは、同じリクエストを繰り返しても効果を一度だけにする識別子です。設計要素は三つです。

  1. 各段階で何を、いつ、どのような結果で行ったかを永続ストレージに記録する。
  2. 外部呼び出しには、タスクと対象から決定的に生成した冪等キーを付ける（例：タスクID:対象ID:段階）。
  3. 再開時はモデルの記憶ではなく、保存した記録と正本で次の作業を決める。

中断後の再開設計

保存地点から続ければ安全とは限りません。保存後に外の世界が変わった可能性があるからです。再開手順には次の確認を含めます。

確認 理由
外部状態との照合 最後の記録後に外部操作が実際に行われたか、正本や参照APIで確認
期限の確認 承認、認証情報、プレビュー識別子、ハンドルがまだ有効か
実行の所有権 別のワーカーがすでに同じタスクを取得していないか（一定期間だけ有効な占有権であるリースと、その期限で管理）
バージョン互換性 保存状態を現在のコードとエージェント定義で読めるか

フレームワークも支援します。OpenAI Agents SDKでは、人の承認を待つ実行をRunStateとしてシリアライズし、DBやキューに保存してから復元して継続できます。文書は、シリアライズ状態には承認判断、保留中のツール呼び出しと引数も含まれるため、サーバー管理の保存先に置き、信頼できるスナップショットだけを復元し、エージェント定義やSDKのバージョンを状態と一緒に保存するよう勧めています。Google ADKでは、状態はイベントのstate_deltaとして記録しなければ保存されません。サービスから取得したセッションのsession.stateを直接変更すると追跡されず、保存されない場合があります。状態値にはシリアライズ可能な基本型だけを使います。

長時間タスクの引き継ぎ

Anthropicの長時間コーディングエージェント実験では、二つの失敗が観察されました。一度に多くを進めようとして途中でコンテキストが尽きる失敗と、後続セッションが部分的な進捗を見て完了と宣言する失敗です。対策は役割の分離でした。

  • 初期化エージェント（最初のセッション）：開発サーバーを起動するinit.sh、作業記録のclaude-progress.txt、最初に追加したファイルを示す初回コミット、200個を超える機能をすべて「不合格」とした機能一覧を作ります。
  • コーディングエージェント（以後のセッション）：一度に一つの機能だけを進め、変更意図を明記したコミットメッセージと進捗記録で次のセッションへの痕跡を残し、環境を整った状態にして終了します。

機能一覧は、Markdownよりモデルが不適切に変更・上書きする可能性が低いJSONにしました。コーディングエージェントはpassesフィールドだけを変更でき、テストの削除や変更は許可しないと明記しました。新しいセッションは作業ディレクトリを確認し、Git履歴と進捗ファイルを読み、最優先の未完了機能を選び、開発サーバーを起動して基本動作をテストした後に作業を始めました。機能は、人と同じようにエンドツーエンドでテストして確認した後だけ、合格としました。

この実験を一般化したものが、引き継ぎパッケージです。次の実行者が長い会話全体を読まずに継続できる文書です。目標と完了基準、完了項目と検証結果、残作業と優先順位、確認済みの事実と未確認の仮定、成果物と外部操作の識別子、次の行動の前提と追加承認が必要な箇所を含めます。「ほぼ完了」のような自己評価ではなく、検証済みの成果物を書くことが要点です。

会話状態をどこに置くか

会話履歴の管理主体も決める必要があります。OpenAI Agents SDKには三つの方式があります。結果を次の入力リストへ直接渡す手動管理、実行前に履歴を読み込み実行後に新規項目を保存するセッション、サーバー側の会話管理（conversation_idまたはprevious_response_id）です。文書は、会話ごとに永続化戦略を一つ選ぶよう求めています。同じ実行でセッションとサーバー側の継続オプションは併用できず、クライアント管理の履歴とサーバー管理の状態を混ぜると、文脈が重複し得ると警告しています。

Google ADKの状態はキーの接頭辞で範囲を定めます。

接頭辞 範囲
なし 現在のセッション
user: 同じアプリ内の、そのユーザーの全セッション
app: そのアプリの全ユーザーと全セッション
temp: 一回の呼び出し（invocation）内。終了時に破棄

範囲を間違えると、一人の情報が別のユーザーへ漏れたり、必要な情報が次のセッションで消えたりします。

さらに深く

チェックポイントと外部副作用の間の隙間

チェックポイントの保存と外部システムの変更は、一つのトランザクションにはまとめられません。外部呼び出しの成功直後、結果を記録する前にプロセスが停止する可能性があります。再開コードが記録だけを見ると「まだ実行していない」と判断し、同じ操作を繰り返します。

この隙間に対処する標準手順は、意図の記録 → 実行 → 結果の記録です。実行前に「この冪等キーでこの操作を行う」と記録し、実行して、結果を記録します。再開時に意図だけあって結果のない項目を見つけたら、再実行する前に冪等キーで外部システムへ処理済みか照会します。処理済みなら結果だけを記録し、未処理なら同じキーで実行します。外部システムが冪等キーに対応していなければ、重複実行の被害が大きい操作ほど人の確認を通してください。すべての段階を取り消せないタスクなら、第5章の補償処理も併せて設計する必要があります。

記憶のライフサイクル

長期記憶は、一度誤って保存すると複数のタスクに繰り返し影響します。そのため記憶にもライフサイクルが必要です。

  1. 昇格基準：何を記憶として残すか決めます。一度きりの発言ではなく、繰り返された情報やユーザーが確認した情報だけを残します。
  2. 出典と時点：誰がいつ話し、どの根拠で確認したかを一緒に保存します。
  3. 競合の解決：新情報が古い記憶と異なる場合は、鮮度と出典の権威で決め、変更履歴を残します。
  4. 期限と再確認：有効期限を設け、過ぎたら再確認するか破棄します。
  5. 訂正と削除の伝播：ユーザーが削除を求めたら、原本だけでなく検索インデックスや、その記憶から作った要約まで削除します。

五つ目は個人情報保護の義務にも関わるため、保存・削除の基準は適用法令と規約に合わせ、個人情報の担当者と定めてください。技術面では、記憶ストレージをユーザー別に隔離し、実際に削除されたかを確認する試験を設けます。

メモリと圧縮のポリシーも評価する

圧縮プロンプトや記憶ポリシーを変えると、コストが減っても精度が落ちる場合があります。ポリシー自体を評価対象にしてください。記憶のないベースラインと比較し、圧縮直後に以前の決定を正確に守れるか問う課題を入れ、意図的に古い記憶を与えて排除できるか確認します。強制中断後の再開成功率もよい指標です。

実務の場面

天の川ブックス：1,800冊の変換作業で忘れられた決定

電子書籍の流通会社「天の川ブックス」は、旧形式の電子書籍1,800冊を新形式に変換し、アクセシビリティ情報を補う作業をエージェントに任せました。最初は自動圧縮を有効にした一つの長いセッションでした。3日目にエージェントは、初日にチームと決めたルール（「表の画像の代替テキストは原文のキャプションから取得する」）を忘れ、140冊を別の方法で処理しました。バリデーターを実行せず「完了」にした本も60冊ありました。

チームは二つの案を却下しました。より大きなコンテキストウィンドウのモデルに変える案は、要約で決定が失われる問題を先送りするだけだと考えました。システムプロンプトに「決定を忘れない」と書く案は、記憶をモデルに任せる同じ失敗だと考えました。

新しい構成では、初回セッションは初期化だけを行います。1,800冊の状態（pending、converted、validated、failed）と検証結果のパスを含むbooks.json、合意した変換ルールを書くdecisions.md、変換器とバリデーターを実行するinit.shを作ってコミットします。以降のセッションは開始時にこの3ファイルとGit履歴を読み、一度に20冊ずつ処理します。状態をvalidatedにできるのはバリデーターの合格後だけで、バリデーターの原文ログは要点だけを残してコンテキストから消します。新しいルールができたら、まずdecisions.mdに記録してコミットし、それから作業を続けます。

次の1,000冊では手戻りがなく、検証せず完了にした本もありませんでした。セッションあたりのコンテキスト使用量は、むしろ減りました。

うね政策研究所：3日間の調査を引き継ぐ

「うね政策研究所」は、韓国全国の基礎自治体の若者向け住宅支援政策を3日間調査して比較表を作ります。初日のセッションは「41か所中23か所の調査完了」という要約を残しました。翌朝、依頼元が比較基準に所得要件を追加し、調査済みの自治体2か所が支援金額を変更して公示しました。2日目のセッションは初日の要約を信じ、残る18か所だけを調査しました。完成した比較表には変更前の金額が2件残り、初日に調べた23か所の所得要件欄は空白でした。

チームは案を比較しました。初日の全会話を次のセッションに渡す案は、コンテキストを占めても何が変わったかを示しません。毎日最初から調査する案はコストが3倍でした。そこで引き継ぎパッケージと再開点検を選びました。

引き継ぎパッケージには、比較基準文書のバージョン、自治体ごとの状態と調査済みフィールド、根拠URLと確認時刻、まだ仮定である項目、次のセッションで最初に行う作業を書きます。新しいセッションは開始前に基準文書のバージョンを確認し、変わっていれば、新設フィールドが空の自治体を再調査対象に戻します。確認から24時間を超えた根拠は、まず公示ページの更新有無を確認します。調査結果は自治体ごとのファイルに保存し、セッションはそのパスだけを持ちます。

次の調査では基準が1回、5自治体の公示が変更されましたが、最終表に古い値は一つも残りませんでした。

間違えやすいポイント

  1. 「ウィンドウが大きければコンテキスト管理は不要だ」 数字が大きければ全部入りそうですが、埋まるほど想起の精度は落ちます。大きなウィンドウは管理の必要性を先送りするだけです。
  2. 「圧縮要約なら進捗状態も保存される」 要約で流れがつながると安心しますが、正確な状態や初期の決定は落ちる場合があります。正確さが必要なものは構造化記録にします。
  3. 「再開時はモデルにどこまで済んだか聞けばよい」 もっともらしく答えるので便利ですが、新プロセスのモデルは以前の実行を知りません。状態は記録と正本から判断します。
  4. 「チェックポイントから続ければ安全だ」 保存した事実は安心感を与えますが、その後に外部状態が変わったり、承認が失効したりしている可能性があります。再開前に照合します。
  5. 「サブエージェントが表全体を返せば正確だ」 原本を直接受け取るので正確に見えますが、リードが転記してコンテキストが埋まり、値が変わることがあります。結果はストレージに置き、参照を渡します。
  6. 「ユーザーの発言をそのまま長期記憶に入れればパーソナライズできる」 最も速い方法ですが、未検証の昇格は古い情報や指示注入の入口になります。
  7. 「ツール結果は頻繁に消すほどよい」 ウィンドウは軽くなりますが、そのたびにプロンプトキャッシュが無効になり得ます。十分な量を一度に消します。

ひと目でわかるまとめ

項目 覚えておく答え
コンテキストが有限である理由 コンテキスト劣化、注意予算、トークン間のn²の関係
システムプロンプトの基準 適切な高度、少数の代表例
必要時の検索 軽量な識別子＋必要時にロード。安定した中核資料は事前に
最も軽い圧縮 古いツール結果の整理
手法の選択 やり取りが多ければ圧縮、節目があればメモ、並列調査ならサブエージェント
正確な状態の置き場所 コンテキスト外の構造化記録。正本と食い違えば正本を優先
キャッシュを守る配置 変わらないものを前、変わるものを後ろ
再開手順 記録を読む → 外部状態と照合 → 期限・所有権・バージョンを確認 → 冪等キーで実行
引き継ぎ 検証済み成果物、事実と仮定の区別、次の行動の前提

公式ドキュメントで確認する

セルフチェック

3-1. コンテキストウィンドウが大きくなっても管理が必要な理由を、「注意予算」という言葉を使って説明してください。

3-2. 古いツール結果の削除が最も軽い圧縮とされる理由と、プロンプトキャッシュと併用する際の注意点を説明してください。

3-3. 会話履歴、タスク状態、長期記憶、業務上の正本のうち、再開時に次の作業を決める根拠とすべきものを挙げ、それが正本と食い違う場合の対応を説明してください。

3-4. 長時間コーディングのハーネスが機能一覧をJSONにして合否フィールドだけを変更させる設計は、どのような失敗を防ぐのか説明してください。

3-5. チェックポイントを「意図の記録 → 実行 → 結果の記録」の順で残す理由を、結果記録の直前にプロセスが停止した場合を例に説明してください。

3-6. 長期記憶の各項目に出典と観察時刻を保存する理由を二つ挙げてください。

3-7. 3日間の調査を別の実行者に渡す引き継ぎ文書の目次を五行で設計し、各行に含める内容を一文ずつ書いてください。

実習課題

実習

進捗ファイルと強制停止後の再開（60分）

  1. 50個以上の項目を順に処理するタスク（文書要約、データ変換など）を選ぶ。
  2. 項目ごとの状態（pending、in_progress、done、failed）、冪等キー、結果のパスを含むJSON進捗ファイルを設計する。
  3. 外部への書き込みには、意図の記録 → 実行 → 結果の記録を適用する。
  4. 実行中の任意の時点で3回プロセスを強制終了して再実行する。1回は外部書き込み直後に終了する。

完了基準： 進捗ファイルに基づいて再実行が続き、二重処理された項目がなく、最終結果が中断なしの実行と同じなら完了とする。

実習

圧縮前後の情報欠落を検査する（40分）

  1. 30ターン以上続いた実際のエージェント会話を一つ選ぶ（機密情報は削除する）。
  2. 後続の作業に不可欠な情報を10個（決定、未解決の問題、識別子、数値）、人が先に抽出して一覧にする。
  3. 現在の圧縮プロンプトで要約を作り、10個のうち何個が正確に残ったか数える。
  4. 欠落した項目を基に圧縮プロンプトを修正して再計数する。その後、要約を短くしてもスコアを維持できるか確認する。

完了基準： 修正後のプロンプトが10個中9個以上を保持し、修正前後の保持数と要約の長さが表として残っていれば完了とする。