長いインタラクションの会話コンテキスト管理

長いインタラクションにわたる会話コンテキストの管理は、Claude Certified Architect — Foundations（CCA-F）試験のドメイン 5.1 を支える基幹トピックである。タスクステートメント 5.1「長いインタラクションにわたって重要な情報を保存するように会話コンテキストを管理する」は、ドメイン 5 で最も試験に出るシナリオを構成する。それは、トランザクションファクト（注文番号・払い戻し金額・約束された配達日・顧客が述べた期待）が会話の拡大につれてドリフト・曖昧化・消失することを許してはならないマルチイシューセッションを処理しなければならないカスタマーサポート解決エージェントのシナリオだ。長いインタラクションにわたる会話コンテキストの管理において行うすべてのアーキテクチャ上の選択、会話履歴の再生方法・事例ファクトブロックの配置場所・ツール出力のトリミングの積極性・段階的に要約するか逐語的にアーカイブするか、は直接エージェントがチケットを正しく解決するか、3 ターン後に期限切れの払い戻しポリシーをハルシネーションするかを形作る。

本学習ノートでは、CCA-F 受験者が長いインタラクションにわたる会話コンテキストの管理においてマスターすることが期待される全体像を説明する：有限のリソースとしての context window のメカニクス・段階的要約パターンとそのリスク・lost-in-the-middle 効果・トランザクションの忠実性のための事例ファクトブロックアーキテクチャ・蓄積前のツール出力トリミング・セクションヘッダーと位置的顕著性・会話履歴の再生戦略・そして 720 点のかすりパスと 985 点のパフォーマンスを分ける試験の罠。

有限のリソースとしての context window — なぜ長いインタラクションの管理がアーキテクチャの問題なのか

Claude の context window は、システムプロンプト・ツール定義・会話履歴・ツール結果・ユーザーの現在のターンを同時に保持するワーキングメモリだ。Claude 4 モデルでは window は大きいが、「大きい」ことは「無限」を意味しない。試験は長いインタラクションにわたる会話コンテキストの管理をアーキテクチャの問題として扱うか、事後のパッチとして扱うかをテストする。window 内のすべてのトークンは他のすべてのトークンと注目を競い合う。行アイテムごとに 40 フィールドを持つ冗長な注文ルックアップは、3 ターン前の顧客の実際の苦情を押し出す可能性がある。冗長なシステムプロンプトはチケットを解決する払い戻しポリシーを押し出す可能性がある。

試験における前提は、単純に「window を大きくする」ことはできないということだ。情報が context window に入り・持続し・出る方法をアーキテクチャとして設計しなければならない。このアーキテクチャを形作る 3 つの力がある：

1. 蓄積 — ツール結果・アシスタントの返答・ユーザーターンはセッション長さとともに線形に積み重なる。
2. 位置的顕著性 — window 内のすべてのトークンが等しく想起されるわけではない；始まりと終わりが中間を支配する。
3. 意味的ドリフト — 簿記トークンとシグナルトークンの比率が拡大するにつれ、Claude の実際のユーザーの意図への根拠が侵食される。

なぜ context window がドメイン 5.1 を支配するか

CCA-F 試験のすべてのカスタマーサポート解決エージェントアーキテクチャ問題は、最終的に context window のトレードオフに帰着する。ターン 1〜8 を要約してターン 9〜15 のスペースを作るべきか？注文を再取得するか 2 ターン前の要約を信頼するか？40 フィールドの注文ペイロードを Claude が見る前に 5 フィールドに削減するか？これらは実装の問いではなくアーキテクチャの問いであり、試験は window が満杯になった後ではなくなる前にそれらについて推論する受験者を評価する。

段階的要約 — 最近の詳細を保存するための以前のターンの圧縮

段階的要約は、会話が拡大するにつれて以前の冗長なターンを短い機械生成の要約に置き換えるパターンだ。30 ターンのカスタマーサポートセッションは、ターン 31 での Claude への提示にあたり、ターン 1〜15 を 1 段落にまとめた要約・3 つの逐語的なターン（16〜18）の中間コンテキスト・最後の 12 ターン全文で表現されるかもしれない。段階的要約は忠実性を犠牲にして context window のヘッドルームを確保する。これがまさに試験の罠が存在する場所だ。

段階的要約のメカニクス

段階的要約は通常、アプリケーションレベル（コードが次のリクエストを送信する前に古いターンをまとめる）または Claude Code の /compact のようなセッションレベルのコマンドで実装される。どちらも動作は同じだ：N ターンを取り、凝縮した説明を生成し、原文を破棄またはアーカイブする。

段階的要約が適切な場面：

• 以前のファイル読み込みがすでに現在の推論に反映されている長い探索的コーディングセッション。
• 以前のウェブ検索が安定した理解に統合されている研究会話。
• 以前の質問の正確な言い回しが無関係なチュートリアルや Q&A セッション。

段階的要約が積極的に危険な場面：

• 数値の約束・金額・日付・ステータスコードが逐語的に残らなければならないカスタマーサポートセッション。
• 顧客が述べた期待の正確な言い回しが法的なアーティファクトであるコンプライアンスに縛られた会話。
• 注文 ID・予約番号・SLA コミットメントが下流アクションを固定するトランザクションエージェント。

段階的要約のリスク — 数値的および意味的ドリフト

長いインタラクションにわたる会話コンテキストの管理で最も高頻度の失敗モードは、段階的要約がトランザクションファクトを静かに曖昧な文章に変異させることだ。「注文 #4812 で 4 月 26 日までに 15 パーセントの払い戻しを約束された」と言った顧客は、要約後には「顧客は最近の注文に対してまもなく払い戻しを期待している」になる。3 つの数値的なアンカー、つまりパーセンテージ・注文番号・日付、がすべて失われる。エージェントの次のターンは自信を持って誤った数字を生成し、その誤った数字は実際の顧客の結果に伝播する。

試験に関連する教訓は、段階的要約は設計上有損であり、セッション開始前にどのファクトが損失を許容できないかを選択し、それらを異なるアーキテクチャにルーティングしなければならないということだ。

Lost-in-the-Middle 効果 — 長いコンテキストにおける位置的顕著性

lost-in-the-middle 効果とは、大規模言語モデルが長い context window の始まりまたは終わりに配置された情報を確実に処理するが、中間に配置された情報は省略・過小評価・取得に失敗する可能性があるという、よく記録された現象だ。この効果は Claude 固有のバグではなく、transformer のアテンションが長い入力シーケンスにわたって顕著性を分散させる方法の特性であり、入力長とともにスケールする。顧客の SLA ティアを 20,000 トークンの会話履歴の中間に埋め込んだカスタマーサポート解決エージェントは、最上部または最下部に配置したものよりも統計的に SLA ティアを忘れる可能性が高い。

効果の測定と予測

実際には、カスタマーサポート解決エージェントを設計する受験者は、最初の 2〜3k トークンを超えていて、長いプロンプトの終わりから 1〜2k トークン以上手前にある任意のファクトが、Claude によって過小評価されるリスクにさらされていると仮定するべきだ。試験は正確なトークン閾値をテストしているのではなく、効果が存在するかのように設計するかどうかをテストしている。すべての支持材料を中間のツール結果のブロブに配置し、Claude が関連するファクトを見つけることを信頼する設計は失敗する；主要な発見の要約を先頭に配置し、詳細なツール出力を明示的なセクションヘッダーで後に配置する設計は合格する。

軽減プレイブック

lost-in-the-middle 効果を軽減する 4 つの具体的な動作：

1. 主要な発見を先頭に配置する。 集約入力の最初に、生の詳細の前に最も重要な結論の短い要約を置く。
2. 重要なファクトを末尾に繰り返す。 次のターンの判断を左右する 1〜2 のファクトを、プロンプトの最後、つまり Claude の返答スロットの直前に繰り返す。
3. 明示的なセクションヘッダーを使う。 ## 顧客プロフィール・## 注文履歴・## 未解決の約束 のようなヘッダーで長いコンテンツを構造化し、Claude が非構造化ブロブとして扱うのではなく入力をナビゲートできるようにする。
4. トランザクションファクトを事例ファクトブロックに移動する。 交渉不可能なファクトの小さな集合を、毎プロンプトの固定された顕著な位置に逐語的に含まれる専用ブロックに抽出する。要約からも中間埋めからも免疫を持つ。

事例ファクトブロック — ターンをまたいだ永続的なトランザクションの忠実性

事例ファクトブロックは、カスタマーサポート解決エージェントシナリオにおける段階的要約リスクへのアーキテクチャ的な回答だ。構造化され・機械管理され・逐語的にレンダリングされたトランザクションファクト（金額・日付・注文番号・ステータス・顧客が述べた期待）のブロックであり、要約された会話履歴の外側に存在し、固定された顕著な位置ですべての後続の API リクエストに含まれる。事例ファクトブロックはドメイン 5.1 で最も頻繁にテストされるアーキテクチャパターンだ。

事例ファクトブロックの解剖学

よく設計された事例ファクトブロックは次のようなものだ：

<case_facts>
customer_id: C-9281
sla_tier: Platinum (4-hour response)
open_issue_ids: T-48122, T-48140
transactions:
  - order_id: "#4812"
    amount_usd: 289.40
    promised_refund_pct: 15
    promised_refund_by: "2026-04-26"
    current_status: "awaiting approval"
customer_stated_expectations:
  - "15% refund on order #4812 by April 26"
  - "No repeat of the delivery delay from order #4199"
</case_facts>

3 つの特性が重要だ：

1. 機械管理。 アプリケーションコード（モデルではなく）がブロックの権威だ。ツール結果がフィールドを更新し、モデルはブロックを文章で編集しない。
2. 逐語的再生。 ブロックはセッションのすべての後続リクエストにバイト単位で同一の状態で含まれ、要約から再生成されない。
3. 顕著な配置。 ブロックはユーザーメッセージスタックの先頭（または末尾）に置かれ、ツール結果の中間に埋まらない。

ブロックに含めるべきもの vs 要約された履歴に残すもの

事例ファクトブロックはゴミ箱ではない。次の 3 つの基準をすべて満たすファクトのみを含める：

• トランザクション的 — 具体的な数値・日付・ID・金額・ステータス。
• 永続的 — 現在のターン以上に関連がある。
• 交渉不可能 — 損失または歪曲が実際の顧客への損害を引き起こす。

会話的なニュアンス・親睦を深める交換・探索的な明確化は事例ファクトブロックに属さない；それらは（場合によっては要約された）会話履歴に属する。ブロックを詰め込みすぎると、ブロック自体の中で lost-in-the-middle 効果が再び発生して目的が失われる。

ツール出力トリミング — 蓄積前のトークン膨張の停止

ツール結果はコンテキストに蓄積し、関連性に対して不均衡にトークンを消費する。単一の注文ルックアップツール呼び出しは、解決エージェントの推論に関連するのは 5 つのフィールド（注文 ID・ステータス・合計・約束された配達日・現在の追跡イベント）だけなのに、40 以上のフィールド（顧客住所・請求住所・配送業者コード・重量・寸法・行アイテムの税率・通貨コード・為替レートのタイムスタンプ）を返すかもしれない。15 ターンセッションにわたるすべての注文ルックアップが 40 フィールドの JSON を context window にダンプした場合、実際の問題が表面化する前にエージェントは簿記に溺れる。

トリミングが蓄積前に行われなければならない理由

試験は、冗長なツール出力がコンテキストに入った後に後処理しようとする受験者を罠にかける。たとえば、ターン 9 で以前の 8 つのツール結果を単一のメモに要約する。その動作はターン 9 以降には多少役立つが、それらの 8 つの膨らんだ結果がターン 2〜8 の間 window に存在して他のシグナルを押し出したという事実には何もしない。正しいアーキテクチャはツール境界でトリミングし、膨張が最初からコンテキストに入らないようにする。

具体的には：ツールハンドラーコードが注文ルックアップサービスから 40 フィールドを受け取り、関連する 5 フィールドを抽出し、それら 5 つのみを含む tool_result を返す。これは基礎となるサービスが返すものとは別個の意図的な整形ステップだ。

フィールド選択のヒューリスティック

• 次の推論ステップが何を必要とするかを問う。 エージェントの次の判断が「約束された配達をまだ守れるか？」であれば、関連するフィールドはステータス・現在の ETA・約束された配達日だ。それ以外はすべてノイズだ。
• ID を残し、文章を削除する。 ID とステータスは安価で後から参照されることが多い；自由形式のサービス説明は高価で再び参照されることはほとんどない。
• 精度が意味的に重要でない場合は丸めるか切り捨てる。 小数点以下 12 桁の座標はトークンを追加するがシグナルを追加しない。
• 構造的な繰り返しを集約する。 10 個の行アイテムが同じ配送ステータスを持つ場合、「10 アイテム、すべて 2026-04-22 に出荷済み」と要約し、フィールドを 10 回繰り返さない。

会話履歴の再生 — すべてのリクエストで完全な履歴を渡す

Messages API はステートレスだ：Claude がターンをまたいで一貫性を維持するために、すべてのリクエストに完全な以前の会話履歴を含めなければならない。これは機能であり制限ではない。アプリケーション（プロバイダーではなく）が何を覚え・要約し・忘れるかを制御できるからだ。しかし、不注意な再生は context window を冗長な簿記で満たす最速の方法でもある。

逐語的に再生するもの vs 圧縮して再生するもの

カスタマーサポート解決エージェントシナリオにおける正規の分割：

• 逐語的に再生する： 事例ファクトブロック・最新の 3〜5 のユーザー/アシスタントターン・現在アクティブなツール定義。
• 圧縮して再生する： 段階的要約に凝縮した、より古いユーザー/アシスタントターン。
• 再生しない： 情報がすでに事例ファクトブロックやアシスタントの要約に蒸留されている古いツール結果；すでに解決されたエラーターン；現在は廃止された計画につながった推論スクラッチ。

再生順序が重要

事例ファクトブロックをターンのユーザーメッセージシーケンスの先頭付近に配置し、その後に圧縮された歴史的要約・次に逐語的な最新ターン・次に現在のユーザーメッセージが続く。この順序は最も重要なトランザクションファクトに最高の顕著性の位置を与え、逐語的な最新ターンを返答スロットに隣接して保つ。context window の両端がシグナルを運び、中間が（より寛容な）要約された履歴を運ぶ。

セクションヘッダー — 長い入力をナビゲート可能にする

集約入力が長くなるとき（たとえばツール結果が 3 つの同時ルックアップを 1 つのペイロードにパッケージングする）、非構造化された連結は Claude に非構造化ブロブを走査させる。明示的なセクションヘッダー（## 顧客プロフィール・## アクティブな事例ファクト・## 注文 4812 の詳細・## 最近の連絡履歴）はブロブをナビゲート可能なドキュメントに変え、lost-in-the-middle のペナルティを大幅に削減する。

ヘッダー設計の原則

• 構造ではなくコンテンツに名前を付ける。 ## 注文 4812 の詳細 は ## セクション 3 より優れている。
• ターンをまたいでヘッダーを安定させる。 毎ターン同じヘッダーテキストを使うことで、Claude が情報の場所に一貫したメンタルモデルを構築できる。
• ツール呼び出しではなく意味単位でグループ化する。 同じ注文についての複数のツール結果は ## 注文 4812 の詳細 の 1 つのヘッダーの下にまとめ、## ツール呼び出し 1 の結果 / ## ツール呼び出し 2 の結果 に分割しない。
• 目次を先頭に置く。 非常に長い入力では、後に続くセクションを列挙する 2 行の要約を先頭に置くことで、Claude が関連する資料を見つけるのを助ける。

主要な発見の要約と組み合わせたセクションヘッダー

lost-in-the-middle 効果の最強の軽減策は、先頭に配置された主要な発見の要約とその下の詳細に対するセクションヘッダーを組み合わせることだ。要約は Claude に何を結論付けるかを告げ、ヘッダーは Claude にどこで確認するかを告げる。どちら単独も両方を合わせたほど強力ではない。

白話文解釋（平易な言葉での解説）

抽象的なアーキテクチャパターンは、具体的なものと結びつくときに定着する。異なる領域から意図的に引き出した 3 つの比喩が、長いインタラクションにわたる会話コンテキストの管理の全体像を固定する。

比喩 1：料理人のメモカード

忙しい居酒屋のコース料理の最中に働く料理人を想像してほしい。料理人には広大なメンタルワークスペースがあるが、12 品のコース料理の最中にはそのスペースがノイズでいっぱいになる。ソースの煮詰め・盛り付けのタイミング・注文の火加減・アレルギーの情報など、すべてを完璧な明確さで同時に保持することはできない。だから料理人はカウンターの上に小さなメモカードをクリップで留めておく：14 番テーブルはセリアック病、22 番テーブルはステーキをミディアムレアで正確に注文した、6 番テーブルの VIP にはデザートをサービスすると約束した。そのメモカードが事例ファクトブロックだ。料理人は 14 番テーブルとサーバーが交わした雑談を忘れるかもしれない・どのテーブルが最初にパンを頼んだかを曖昧にするかもしれない・過去 1 時間のサービスを「忙しかった、クレームなし」と要約するかもしれない。しかし 14 番テーブルのセリアック病の情報はメモカードに逐語的に残る。メモカードは料理人の内部的な要約に従わないからだ。

比喩を延長しよう：下働きが料理人に、その朝届いたすべての食材の完全な仕入れ明細書（40 の SKU・数量・ベンダーコード・賞味期限）を渡した。料理人がその明細書全体をカウンターにホチキスで留めたら、メモカードが埋まってしまう。そのため仕込み担当がツール出力をトリミングする：料理人のカウンターに届く前に、明細書は「サーモンの品質良好、ブッラータが 2 ケース不足 — 本日のスペシャルに変更、メニューへの影響なし」に削減される。料理人が実際に読むのはそのトリミングされたメモだ。料理人は完全な明細書を読まない；完全な明細書はメモカードを押し出さない。

最後に：料理人は常にまずメモカードを見て、各コースの盛り付け直前にもう一度見る。それが位置的顕著性だ。注意の先頭と末尾であり、中間ではない。

比喩 2：司書のピンボード

長い調査質問を持つ利用者を助けている参考係の司書を想像してほしい。司書はデスクの上に見えるピンボードを持っている。そこには：利用者の名前・具体的な調査質問・言及された締め切り・司書が行った約束（たとえば「午後 3 時までにマイクロフィルム室を確認すると言った」）がある。司書の後ろには、検索中に引き出した本の増え続けるスタックがある。スタックが会話履歴だ。

経験の浅い司書は片付けた本を棚に戻し、代わりにインデックスカードに書かれた要約（「建築の本 5 冊、すべてパラディオ期を扱う、バロックについては何もなし」）と交換することを学ぶ。それが段階的要約だ。建築に関する本にはうまく機能する。特定の請求番号はその期間がカバーされた時点で重要ではなくなったからだ。しかし利用者の述べた締め切りや約束された内容には機能しない。それらはピンボードに利用者自身の言葉で残る。それらを曖昧にすることは司書の暗黙の契約を破ることになるからだ。

2 時間後に戻ってきた利用者は、まずピンボードを見る（注意の先頭）・次にインデックスカードの要約を読む（圧縮された中間）・そして利用者に直接最後の半時間について尋ねる（逐語的な最新のコンテキスト）という司書にサービスを受ける。誰かが利用者の締め切りをインデックスカードのスタックの中間に埋めたら、それは失われる。それがlost-in-the-middle 効果だ。

比喩 3：持ち込み可試験の要点シート

8 時間かけて 40 問の持ち込み可試験を受けている学生を想像してほしい。学生は完全な教科書（会話履歴）にアクセスできるが、すべての問題ですべてのページを読むことはできない。そのため学生はデスクの先頭に 1 ページの要点シートを構築する：半分の問題に出てくる 6 つの公式・3 つの定理・2 つの定数。新しい問題に移るたびに、学生はまず要点シートを読み返す。要点シートが事例ファクトブロックだ。

教科書自体には章の見出し・セクションの見出し・索引がある。セクションヘッダーであり、学生が最初からスキャンせずに正しいページに飛べるようにする。学生は、最もよく使う公式を要点シートに入れ、教科書のタブを章ごとに整理することが、「必要なときに見つける」というオープンブック戦略を大幅に上回ることを学ぶ。後者は限られた注意を無駄にする。

そして学生は教科書のすべてのページをデスクにコピーしない。ほとんどを本の中に残す。すぐに利用可能でなければならないファクトだけが要点シートに載る。これがツール出力トリミングだ：関連するフィールドが引き出されてピン留めされ、残りはソースに留まる。

どの比喩がどの試験キューに対応するか

• 段階的要約のリスク・事例ファクトブロック・トランザクションの忠実性 → 料理人のメモカードの比喩。
• lost-in-the-middle 効果・セクションヘッダー・位置的顕著性 → 司書のピンボードとインデックスカードの比喩。
• ツール出力トリミング・コンテキスト予算・選択的想起 → 持ち込み可試験の要点シートの比喩。

構造化されたコンテキストログ vs 文章の要約 — 機械可読な状態

長いインタラクションにわたる会話コンテキストの管理における微妙だが試験でテストされる選択は、ターンをまたいで持続する状態を機械可読なログ（YAML・JSON・キーバリューブロック）として保存するか、文章の要約として保存するかだ。答えはコンテキスト依存だ：

• 機械可読（事例ファクトブロック・ステータスログ・未解決の約束リスト） — アプリケーションがプログラム的に更新またはクエリするものには使う。機械可読な状態は段階的に更新・検証・一貫してレンダリングするのが容易だ。
• 文章の要約（以前の会話の物語的圧縮） — 会話の雰囲気・関係構築のキュー・本質的に物語である探索的推論には使う。文章は有損だが、YAML ができない形でインタラクションの感覚を保持する。

カスタマーサポート解決エージェントはハイブリッドから恩恵を受ける：事例ファクト・約束・トランザクションには機械可読ブロック；会話履歴のより古いターンには文章の要約。試験の誤答選択肢はしばしば「すべてを文章として要約する」または「すべてを JSON としてログに記録する」を提案する。両方の極端は誤りだ。正しいアーキテクチャはコンテンツタイプごとに適切な表現を選ぶ。

コンテキストをリセットするとき — セッションが劣化していることの認識

段階的要約・事例ファクトブロック・ツール出力トリミングを使っても、非常に長いセッションは最終的に劣化する。長いインタラクションにわたる会話コンテキストの管理には、正しい動作がさらなるパッチではなく意図的なリセットであることを知ることが含まれる。

コンテキストリセットが正しい動作であるシグナル：

• エージェントが事例ファクトブロックに逐語的にあるファクトと矛盾し始める。
• ツール呼び出しが同じ引数で以前の呼び出しを繰り返し始める（失われた状態のシグナル）。
• エージェントが決して起こらなかった出来事や約束を参照する（ハルシネーションの増加）。
• ターンあたりのレイテンシがタスクの複雑さではなく総コンテキストサイズに相関する形で上昇する。

このシナリオでのリセットは通常意味する：事例ファクトブロックとコンパクトな文章の要約をアプリケーションストレージに永続化し・新しい会話セッションを開き・持続された状態をターン 1 の先頭に再挿入し・続行する。正しく行えば、顧客は境界に気づかない。誤って行えば（たとえば事例ファクトブロックを再生せずに再初期化する）、エージェントは顧客が述べた期待を「忘れ」、セッションは崩壊する。

典型的な試験の罠 — CCA-F シナリオが実際に何をテストしているか

CCA-F ドメイン 5.1 は長いインタラクションにわたる会話コンテキストの管理に関連する 5 つの罠パターンを繰り返し活用する。

罠 1：「段階的要約は非可逆ではない」

誤答の表現：「段階的要約を使用してトークン使用量を削減しながらすべてのトランザクションファクトを保持する。」段階的要約は設計上有損だ。圧縮する。トランザクションコンテンツに対してそれを非有損としてフレーミングするか、事例ファクトブロックの代替としてフレーミングするどの回答も誤りだ。

罠 2：「より大きな context window が問題を解決する」

誤答の表現：「より大きな context window を持つモデルに移行して lost-in-the-middle が問題にならないようにする。」より大きな window は lost-in-the-middle 効果を修正しない。多くの場合それを悪化させる。より多くの中間が存在するからだ。正しい回答はアーキテクチャ的（事例ファクトブロック・セクションヘッダー・先頭の主要な発見）であり、容量拡張ではない。

罠 3：「蓄積された後にツール出力をトリミングする」

誤答の表現：「5 ターンごとに以前のすべてのツール結果を単一のメモに要約してトークンを節約する。」事後の要約は以降に対して限定的に役立つが、すでに発生した置き換えを取り消すことは何もしない。試験正解の動作はツール境界でトリミングすることで、結果がコンテキストに入る前から行う。

罠 4：「事例ファクトブロックは Claude によって更新される」

誤答の表現：「返答の一部として事例ファクトブロックを維持・更新するよう Claude に指示する。」事例ファクトブロックはモデルではなくアプリケーションコードによって機械管理される。モデルにブロックを書き直させると、ブロックが存在するために防ごうとしている段階的要約ドリフトをまさに再導入する。

罠 5：「Lost-in-the-Middle はより強いプロンプトで修正される」

誤答の表現：「'注意深く読み中間のセクションを見逃さないように' をシステムプロンプトに追加する。」プロンプトのリマインダーは位置的顕著性バイアスに対して意味のある反撃をしない。修正は構造的だ：重要な情報を始まりまたは終わりに置き、中間にセクションヘッダーを追加する。

実践アンカー — カスタマーサポート解決エージェントのタスク 5.1 シナリオ問題テンプレート

長いインタラクションにわたる会話コンテキストの管理に結びついた CCA-F 実践問題は 6 つの繰り返しパターンに分類される。詳細な問答項目は ExamLab CCA-F 問題バンクにある；以下のテンプレートはナビゲートするために必要なパターン認識をトレーニングする。

テンプレート A：ドリフトする払い戻し金額

カスタマーサポート解決エージェントのセッションが 22 ターン実行されている。ターン 12 で顧客は「注文 #4812 で 4 月 26 日までに 15% の払い戻しを約束された」と述べた。ターン 20 でエージェントは以前の会話を要約し「注文 4812 で払い戻しが約束された」と言及した。ターン 22 でエージェントは要約に基づいて 10% の払い戻しを提案する。最も可能性が高い根本原因と正しいアーキテクチャ上の修正は何か？

• 根本原因： 段階的要約が 15% の数値と 4 月 26 日の日付を曖昧な文章に圧縮した。
• 正しい修正： 顧客がターン 12 に期待を述べたときに事例ファクトブロックを作成し、毎ターンすべてのプロンプトに逐語的に含め、要約から明示的に除外する。

テンプレート B：埋まった SLA ティア

エージェントには 24,000 トークンの会話履歴がある。顧客のプラチナ SLA ティアは初期のツール結果で述べられ、それ以来繰り返されていない。ターン 18 のエージェントの返答はチケットを標準優先度でルーティングする。最も可能性が高い根本原因と正しいアーキテクチャ上の修正は何か？

• 根本原因： lost-in-the-middle 効果 — SLA ティアが context window の中間に埋まっていた。
• 正しい修正： SLA ティアを事例ファクトブロック（先頭に配置）に移動し、詳細な入力に ## SLA というセクションヘッダーを追加して、そのファクトが顕著な位置に存在するようにする。

テンプレート C：膨らんだ注文ルックアップ

エージェントの注文ルックアップツールは行アイテムごとに 40 フィールドの JSON ペイロードを返す。セッション全体で 8 回のツール呼び出しの後、会話履歴が簿記に支配されている。エージェントは実際の顧客の苦情を見逃し始める。正しいアーキテクチャ上の修正は何か？

• 正しい修正： ツール出力をツール結果の整形レイヤーで関連するフィールド（注文 ID・ステータス・合計・約束された配達日・現在の追跡イベント）に削減し、結果が context window に入る前に行う。下流の要約に後処理をまかせない。

テンプレート D：「自分のメモリを更新する」誤答選択肢

提案されたアーキテクチャは、システムプロンプトで Claude に各返答の先頭に「ケースノート」セクションを維持し会話の進行とともに更新するよう指示する。このアーキテクチャが欠陥を持つ理由は何か？

• 理由： モデル管理の状態は、事例ファクトブロックが存在するために防ごうとしている段階的要約ドリフトと同様の影響を受ける。状態はツール結果が構造化された更新を促すアプリケーションコードによって機械管理されなければならない。Claude に自己管理メモリを促すことは、試験が繰り返し指摘する誤答選択肢だ。

テンプレート E：中間に埋まった主要な発見

研究合成エージェントが 3 つのツール結果を 6,000 トークンの組み合わせ入力に集約する。最も重要な発見は中間のツール結果の 2 段落目にある。次のターンでエージェントは発見を参照しない。正しいアーキテクチャ上の修正は何か？

• 正しい修正： 集約入力の先頭に主要な発見の要約を置き（3 つの最も重要な結論を箇条書きにする）、明示的なセクションヘッダーで詳細なコンテンツを整理し（## 発見 A・## 発見 B・## 発見 C）、必要に応じてプロンプトの末尾に最も決定を左右する単一のファクトを繰り返す。

テンプレート F：リセットトリガー

セッションが 45 ターン実行され、エージェントは今なお事例ファクトブロックに逐語的にあるファクトと矛盾している。次の正しい動作は何か？

• 正しい動作： コンテキストが現在のセッション内では回復不可能なレベルまで劣化したというシグナルを認識する。事例ファクトブロックとコンパクトな文章の要約を永続化し・新しい会話セッションを開き・ターン 1 に持続された状態を再挿入し・続行する。現在のセッションにさらに要約を追加しない。セッションはすでに飽和している。

長いインタラクションにわたる会話コンテキストの管理 よくある質問

lost-in-the-middle 効果とは何か、CCA-F でどう軽減するか？

lost-in-the-middle 効果とは、長いコンテキスト言語モデルの位置的顕著性バイアスだ：長い入力の始まりと終わりにある情報は確実に想起されるが、中間の情報は Claude の推論から過小評価または省略される可能性がある。長いインタラクションにわたる会話コンテキストの管理における軽減はプロンプトではなく構造的だ：集約入力の先頭に主要な発見を置く・末尾に決定を左右するファクトを繰り返す・明示的なセクションヘッダーで長いコンテンツを整理して Claude がナビゲートできるようにする・毎ターン固定された顕著な位置にレンダリングされる事例ファクトブロックに交渉不可能なファクトを移動する。「中間を注意深く読むように」というプロンプトリマインダーは誤答選択肢だ。修正はどこにファクトが置かれるかであり、どのように探すよう求めるかではない。

事例ファクトブロックとは何か、なぜカスタマーサポート解決エージェントに重要か？

事例ファクトブロックとは、アプリケーションコード（モデルではなく）が権威となる構造化された・機械管理された・逐語的にレンダリングされたプロンプト領域で、セッションのトランザクションファクト（注文番号・金額・パーセンテージ・日付・ステータス・顧客が述べた期待・SLA ティア）を保持する。ツール結果がフィールドを更新し、ブロックは固定された顕著な位置にすべての後続の API リクエストにバイト単位で同一の状態で含まれる。カスタマーサポート解決エージェントの会話の段階的要約は「注文 #4812 で 4 月 26 日までに 15% の払い戻し」を「払い戻しがまもなく約束された」に静かに圧縮するため重要だ。その損失は誤った顧客の結果に伝播する。事例ファクトブロックは、エージェントを要約ドリフトと lost-in-the-middle 効果の両方に対して堅牢にするアーキテクチャパターンだ。

段階的要約の最大のリスクは何か？

段階的要約は設計上有損だ：以前のターンを短い要約に圧縮し、コンテキスト window のヘッドルームと引き換えに忠実性を犠牲にする。最大のリスクは（1）数値的ドリフト — パーセンテージ・金額・日付が曖昧な文章に一般化される；（2）識別子の損失 — 注文番号・チケット ID・顧客 ID が「その注文」「そのチケット」に削減される；（3）約束の歪曲 — 顧客が述べた期待がモデルの言い換えになる；（4）静かな失敗 — 要約は一貫した文章として読まれるため損失はレビュー時に見えず、エージェントが劣化した情報に基づいて行動したときにのみ表面化する。軽減策：要約される前にトランザクションファクトを事例ファクトブロックに抽出する。

ツール出力はなぜ context window に入った後ではなく入る前にトリミングされるべきか？

後のトリミングは以降に対して役立つが、すでに発生した置き換えには何もしない。8 つの冗長な注文ルックアップ結果がターン 2〜8 の間 window に存在したなら、それらはすでに他のシグナル（事例ファクトブロック・主要な発見・顧客の実際の苦情）を window の中間に押しやっており、そこで lost-in-the-middle 効果がそれらを攻撃する。ツール結果の整形レイヤーでトリミングすること（アプリケーションコードが 40 フィールドの応答から関連する 5 フィールドを抽出して tool_result を出力する）は、それら 35 の冗長なフィールドが決してトークンを消費せず・シグナルを押しやらず・顕著なコンテンツを置き換えないことを意味する。境界でトリミングし、後から遡ってではない。

事例ファクトブロックに入れるものと要約された会話履歴に残すものをどう判断するか？

各情報に 3 つの基準を適用する：それはトランザクション的か（具体的な数値・日付・ID・金額・ステータス）・永続的か（現在のターン以上に関連がある）・交渉不可能か（損失または歪曲が実際の顧客への損害を引き起こす）？3 つすべてが真なら、事例ファクトブロックに属する。そうでなければ、（場合によっては要約された）会話履歴に属する。関係構築の交換・探索的な明確化・会話の雰囲気は履歴に留まる。ブロックを詰め込みすぎると、ブロック自体の中で lost-in-the-middle 効果が再び発生して目的が失われる。

セクションヘッダーはどのように長いコンテキストの信頼性を向上させるか？

セクションヘッダー（## 顧客プロフィール・## 注文 4812 の詳細・## 未解決の約束）は非構造化の中間ブロブをナビゲート可能なドキュメントに変える。ヘッダーがなければ Claude は長い入力を線形にスキャンしなければならない；ヘッダーがあれば Claude は入力を、場所が意味に対応する構造化ドキュメントとして扱える。ヘッダーは先頭に配置された主要な発見の要約と組み合わせたときに最も効果的だ。要約は Claude に何を結論付けるかを告げ、ヘッダーは Claude にどこで確認するかを告げる。Claude が情報の場所に一貫したメンタルモデルを構築できるよう、ターンをまたいでヘッダーテキストを安定させること。

コンテキストを完全にリセットするタイミング vs 現在のセッションにパッチを当て続けるタイミングをどう判断するか？

セッションがそれ自身の window 内で回復不可能なレベルまで劣化したシグナルを見たときにリセットする：エージェントが事例ファクトブロックに逐語的にあるファクトと矛盾する・ツール呼び出しが同じ引数で以前の呼び出しを繰り返す（失われた状態のシグナル）・エージェントが決して起こらなかった出来事や約束をハルシネーションする・またはターンあたりのレイテンシがタスクの複雑さではなく総コンテキストサイズに相関する形で上昇する。正しいリセットは事例ファクトブロックとコンパクトな文章の要約をアプリケーションストレージに永続化し・新しいセッションを開き・持続された状態をターン 1 に再挿入する。顧客は境界に気づかないはずだ。誤ったリセットは持続された状態を再生せずに再初期化し、リセットが保存することになっていた顧客が述べた期待を正確に破棄する。

さらなる学習リソース

• Claude Certified Architect — Foundations（CCA-F）試験ガイド: https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf
• Context windows — Claude API Docs: https://docs.anthropic.com/en/docs/build-with-claude/context-windows
• Long context prompting tips — Claude API Docs: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/long-context-tips
• Building effective agents — escalation and human-in-the-loop: https://docs.anthropic.com/en/docs/build-with-claude/agentic-loop
• コミュニティ合格報告（893/1000、Kishor Kukreja、2026-04-09）: https://medium.com/@kishorkukreja/i-passed-anthropics-claude-certified-architect-foundations-exam-with-a-score-of-893-1000-2206c27efd6c

関連 ExamLab トピック: セッション状態・再開・フォーキング、大規模コードベース探索のコンテキスト管理、マルチソース合成における情報の出典と不確実性、エスカレーションと曖昧さ解決の効果的なパターン。