複数のコーディングエージェントを運用しているチームでは、タスクの引き継ぎが日常茶飯事です。Sonnetのワーカーがコードを変更し、Opusのレビュアーがそれをチェックする。Claude Codeエージェントの処理が行き詰まれば、タスクはCodexエージェントへと移る。9月28日にリリースされたClaude Sonnet 5.5は、これまでも薄々事実だったことを明文化しました。それは、「モデルの思考プロセス（reasoning）は作業成果と一緒には引き継がれない」ということです。AnthropicのSonnet 5.5の新機能ページには、すべてのthinking block（思考ブロック）に「それを生成したモデルが記録される」と記載されており、他のモデルがSonnet 5.5のブロックを読み取ることはできません。
厄介なのは、それが極めて静かに起きることです。モデルが読み取れないブロックを含むリクエストが送られると、APIはモデルに渡す前にそのブロックを密かに破棄します。リクエスト自体は成功し、破棄されたブロックの料金は請求されず、残る痕跡はinput_transformationsのエントリのみです（それもthinking-binding-controls-2026-08-01ベータヘッダーを送信した場合にしか現れません）。レビュアーエージェントには「なぜそうしたのか」という理由のないdiffだけが渡り、エラーも発生しないため、実際よりも背景を把握できているように見えてしまうのです。
要点（TL;DR）
モデルをまたぐエージェントの引き継ぎコンテキストに関して、覚えておくべきルールは1つだけです。「引き継ぎを生き残るコンテキストは、タスク上に明記されたものだけ」ということです。思考ブロックは、生成したモデル、まったく同一の会話、そしてSonnet 5.5の場合はアカウントにもバインド（紐付け）されています。各エージェントの実行終了時には、必ず引き継ぎコメントを残すようにしてください。そこには、下した決定とその理由、前提条件、試して失敗したアプローチ、未解決の検討事項、変更したファイル、実行したチェック内容を含めます。独自にハーネスを構築している場合は、履歴を決して書き換えず追記専用（append-only）にしてください。
思考ブロックを縛る3つのバインディング
思考ブロックとは、モデルが1ターンの中で生成した思考プロセスのことであり、後続のリクエストで再利用する前にAPIが検証する署名が付与されて返されます。preserved thinking（思考の保持）のドキュメントには3つのバインディング（制約）が記載されており、そのそれぞれがチーム内で既に行われている引き継ぎパターンに当てはまります。
モデル：Sonnet 5.5は、Sonnet 5、Opus 4.8、Haiku 4.5、およびそれ以前のモデルからのブロックを読み取ることができますが、Opus 5、Opus 5.5、Fable、Mythosからのブロックは読み取れません。ここで重要なのは「方向性」です。会話の途中でモデルを切り替えることに関するAnthropicの注記によれば、Sonnet 5からSonnet 5.5へ移行する会話では思考プロセスが維持されますが、Sonnet 5.5から他のモデルへ移行する会話では、それ以降のターンは思考なしで実行されます。これには、拒否されたSonnet 5.5のリクエストの一部をSonnet 5で再試行する、Anthropic独自のサーバーサイドフォールバックも含まれます。
会話：ブロックが利用できるのは、それが生成されたときと完全に一致するシステムプロンプト、ツール、メッセージの直後に続く場合のみです。ドキュメントのFAQにはその影響が明確に説明されています。思考プロセスを別の会話に持ち越すことはできないため、新しい会話はタスク状態の要約（目標、下した決定、ここまでのファイルと結果、次のステップ）から開始する必要があります。タスクが別のエージェントに移動すると、ランタイムは新しいセッションを開始します。これは、同じモデルであっても新しい会話になります。AIセッション間でのコンテキスト維持で解説したように、ツールの新しいセッションがまっさらな状態から始まるのと同じ理由です。
アカウント：Sonnet 5.5のブロックは、それを生成したアカウント、またはそれに紐付けられたアカウントでのみ機能します。Anthropicのローンチ告知では、この制約が影響する例として、Claude Codeでのセッション途中でのアカウント切り替えが挙げられています。
まとめると、エージェント間では思考プロセスは元々引き継がれていなかったのです。Sonnet 5.5はそれをAPIの仕様（コントラクト）として明確に規定しました。
思考が静かに破棄される3つの引き継ぎシナリオ
| 引き継ぎ | 引き継がれるもの | 失われるもの | 通知・検知手段 |
|---|---|---|---|
| Sonnet 5.5のワーカーエージェントからOpus 5.5のレビュアーエージェントへ | diff、リポジトリ、タスクの説明とコメント | Sonnet 5.5の思考プロセス。他のモデルは読み取れず、レビューの実行自体も新しいセッションとなるため | エージェント間では通知なし。単一のAPI会話内であれば、ベータヘッダー指定時にmodel_binding_mismatchエントリが出力 |
| Claude CodeエージェントからCodexエージェントへ | diff、ブランチ、タスクの記録、リポジトリの共有ルールファイル | Claudeの思考プロセスすべてとClaude Codeのセッション状態。Codexは独自の会話を開始するため | なし |
| 同一モデル、別アカウント（Claude Codeのセッション中でのアカウント切り替え、または保存したセッションを別アカウントの認証情報で再実行する場合） | 可視トランスクリプト：メッセージ、ツール呼び出し、実行結果 | 最初のアカウントで生成されたSonnet 5.5のすべての思考ブロック | Claude APIおよびGoogle Cloudでは、ベータヘッダー指定時にorganization_binding_mismatchエントリが出力。それ以外は何も通知なし |
最後の列こそが問題の本質です。3つの引き継ぎはいずれもエラーなく成功し、引き継いだ側のエージェントは前のエージェントが把握していた情報よりも少ない知識のまま、自信満々に回答を返します。ワーカーが懸念を抱いていた変更であっても、別のモデルのレビュアーがそれを承認してしまうことがあります。その懸念は、レビュアーが決して目にすることのない思考ブロックの中にしか存在しなかったからです。
以前、コーディングエージェント間の切り替えにおいて「コードは保持されるが、思考プロセスは破棄される」と書きました。現在ではこの現象がAPIレベルでも当てはまります。これは、同一コードベースでClaude CodeとCodexを併用しているチームや、エスカレーションを行うルーティングルールを設定しているチームにとって極めて重要です。Sonnet 5.5かOpus 5.5か：タスクをどちらのエージェントに割り当てるべきかで述べたように、難易度の高いタスクをSonnet 5.5のワーカーからOpus 5.5へとエスカレーションする場合、その引き継ぎはすべて表の1行目のケースに該当します。
思考を引き継げないとき、引き継ぎノートに何を記載すべきか
コーディングエージェントの引き継ぎノートの役割はただ1つ、次の作業者が読める場所に、重要な思考プロセスを「文章として書き残す」ことです。以下の項目は、Anthropicが推奨する要約フォーマットを拡張したものであり、思考ブロックには保持されていてもdiffには決して現れない2つの要素、すなわち「なぜその方針を選んだのか」と「どの方針をすでに除外したのか」をカバーしています。タスクを引き渡す可能性のあるすべてのエージェントの指示に、以下を貼り付けてください。
Before you finish, post one comment on the Task that starts with "Handoff".
Write it for a reader who has this Task and the diff, and nothing else.
Decisions: each choice you made and the reason for it, one line each
Assumptions: what you took as true without verifying it
Tried, failed: approaches you ruled out and why, so nobody retries them
Open questions: what a person or the next Agent has to decide
Files touched: paths changed, and which ones are unfinished
Checks run: exact commands and their results; name any check you skipped
Next step: the one action you would take next
実効性を担保するために、押さえておくべき3つのポイントがあります。
思考プロセスそのものではなく、「決定事項」を求めること：Sonnet 5.5は、思考プロセスの抽出（reasoning extraction）に対するセーフティクラシファイアを搭載した最初のSonnetです。そのreasoning_extractionという拒否カテゴリは、内部の思考プロセスを回答テキストにそのまま再現させようとする要求を対象とします。「思考内容をコメントに貼り付けて」という指示は拒否対象になりますが、「下した決定とそれぞれの理由をリストアップして」という指示であれば通常の報告として扱われます。
「試して失敗したこと」が最も時間を節約する：行き詰まったアプローチはdiffには現れません。引き継ぎノートがなければ、次のエージェントも同じ袋小路に迷い込むことになります。
チェック内容は「実行コマンドと出力結果」を残す：「テスト合格」は単なる主張に過ぎません。実行されたコマンドとテスト件数の出力こそが、レビュアーが再実行して確認できる確固たる証拠となります。
使い分けの基準：1つのエージェントがアサインからレビューまでを単一の実行で完了し、最終的に受け入れる人間がdiffを精読する場合は、ノートを省略しても構いません。しかし、タスクの担当者（Assignee）が変わる、モデルが変わる、あるいはレビュアーエージェントに渡される瞬間には、必ずノートを必須にしてください。コーディングエージェントの引き継ぎテンプレートでは人間とエージェントの間の連携を扱っていますが、今回のノートはエージェント同士の連携をカバーするものです。
独自ハーネスを構築している場合、履歴の編集はエラー対象に
大半の読者にとって、ここは読み飛ばして問題ありません。preserved thinkingのドキュメントによれば、Claude Code、claude.ai、Claude Managed Agents、またはClaude Agent SDKがリクエストを構築している場合は何も変わりません。影響を受けるのは、自前のコードからMessages APIを直接呼び出している場合です。
2026年8月31日 00:00 UTC以降に作成されたアカウントでは、Claude API、Amazon Bedrock、Google Cloudのいずれにおいても、Sonnet 5.5の思考ブロックより前の要素（システムプロンプト、ツール、過去のメッセージ）を変更した上でその思考ブロックを再送（リプレイ）すると、400エラーが返されます。それ以前のアカウントではリクエスト側で明示的にオプトインした場合にのみこのチェックが行われますが、これには罠があります。開発者自身のアカウント（古いキー）では正常にパスしても、自作ツールを新しいアカウントのキーで実行したユーザーが最初に400エラーに直面することになるのです。対策は、「会話履歴を追記専用（append-only）に保つこと」です。
- セッション開始時にシステムプロンプトとツールを固定（フリーズ）する。指示を変更したい場合は、会話の途中にシステムメッセージを追記する形で行います。これはSonnet 5.5ではサポートされていますが、Sonnet 5ではサポートされていません。
- アシスタントのターンは、空の思考ブロックも含め、返されたそのままの形式で送り返す。
- 過去のターンを書き換えるのではなく、API経由で圧縮（Compact）を行う。オンデマンド圧縮（ベータ版
compact-2026-09-04）は、対象となるメッセージの代わりに送信可能な署名付きサマリーブロックを返します。ドキュメントが推奨するシンプルな圧縮方法では、1つの要約メッセージと次の指示のみを送信するため、過去の思考ブロックがリプレイされることはありません。
{ "role": "system", "content": "Review found a race in the retry path. Do not change the public API." }
ベータヘッダーを使用している場合、prefix_mismatch_behavior: "drop_block"を指定すると、エラーを返す代わりに不整合のあるブロックを破棄します。ただしドキュメントでも明記されている通り、これは変更を根本的に解決しているのではなく、単に覆い隠しているに過ぎません。
Anthropicが推奨する圧縮の形に注目してください。思考プロセスをリプレイできないとき、Anthropicが提示する解決策は「文章による要約」です。これはまさに、別の形をした「引き継ぎノート」に他なりません。
Sharklyにおける引き継ぎ情報の管理
タスクこそが共有の記録であり、セッションを超えて存続するものは他にないため、引き継ぎ情報はタスク上に記録されるべきです。タスクは、Conversation（コメントベースの対話）、コメントや変更内容のActivityタイムライン、そして各実行のExecutions履歴を保持します。チームに向けたエージェントのテキストは、その実行に紐付いたコメントとして保存されます。エージェントが回答を必要とする場合、その質問はコメントとしてタスクに書き戻され、タスクは「人間の返答待ち」状態となり、質問はその担当者の受信トレイ（Inbox）に届きます。
この仕組みの真価が発揮されるのが担当者の再割り当て（Reassignment）です。担当者をSonnet 5.5エージェントからOpus 5.5のレビュアーやCodexエージェントへと変更すると、次の実行は生のトランスクリプトからではなく、タスクの情報をもとに開始されます。Sharklyのドキュメントには、タスク起点での実行に含まれる情報がリストアップされています。タイトルと説明文、直近のコメントと実行のトリガーとなったコメント、エージェントへの指示、そしてリポジトリです。引き継ぎコメントもこのリストに含まれます。前のエージェントの思考プロセスは含まれませんが、モデルを変更した時点でAPIがどうせ破棄してしまうため、これで全く問題ありません。
ここから2つの習慣が導き出されます。1つは、チーム全体に共有すべき結論はコメントやタスクの説明文に記載するということ。エージェントとの個別チャットで決まったことは、タスクを次の担当者に移す前に必ずそこに反映させます。もう1つは、実行時に直近のコメントが読み込まれるため、タスク全体を通じて守るべき決定事項はタスクの説明文に集約しておくということです。
ここで「プロバイダー非依存（provider neutrality）」の強みが活きてきます。エージェントはランタイムのデフォルトモデルに従うため、引き継ぎルールをエージェントの指示に記述しておけば、次のランタイムがSonnet 5.5上のClaude Codeであれ、別のモデル上のCodexであれ、全く同様に機能します。セットアップ手順はSharklyでClaude Sonnet 5.5エージェントを実行する方法にまとめられています。エージェントは調査、実行、テスト、報告を行い、人間は方向性を定め、権限を付与し、次のエージェントが読むのと同じ記録をもとに成果物を承認します。これこそが、エージェントの作業に対する人間のオーナーシップを支える基盤なのです。
preserved thinkingはFable 5.1で導入され、今ではOpus 5.5とSonnet 5.5にも適用されています。「思考プロセスが引き継がれること」に依存しない引き継ぎ体制を構築しておけば、将来モデルが変更されてもワークフローが破綻することはありません。すでに複数のエージェントを運用しているなら、Sharklyを使えばタスクと成果物を一元管理できます。
