Claude API advisorツールの結果が暗号化される条件

advisor_redacted_resultとadvisor_resultはどう違うか

Claude APIのadvisorツールを呼ぶと、advisor_tool_resultブロックのcontentに助言が入ります。このcontentは判別可能なユニオン型で、中身の形はcontent.typeの値で2通りに分かれます。advisor_resultはtextフィールドに助言の全文がそのまま入る平文形式、advisor_redacted_resultはencrypted_contentフィールドに読めないブロブが入る暗号化形式です。どちらが返るかはリクエスト内容ではなく、advisorに指定したモデルだけで機械的に決まります。

分岐は次の対応です。

advisor_resultとadvisor_redacted_resultはどちらもstop_reasonフィールドを持ちます。ただしこれは常に入るわけではなく、ツール定義でmax_tokensを設定した呼び出しでだけ現れ、設定していなければ省略されます。値はend_turn(通常終了)またはmax_tokens(上限到達による打ち切り)で、トップレベルのMessages APIのstop_reasonと同じ値の体系です。

条件はタスクの内容にもプロンプトにも依存しません。同じリクエストでもtools配列のmodelをclaude-opus-5からclaude-opus-4-8に変えるだけで、返ってくるcontent.typeが丸ごと切り替わります。したがって「advisorの助言を画面に表示したい」という要件があるなら、モデル選定の段階でこの表を確認する必要があります。Fable/Mythos系とOpus 5をadvisorに使う限り、advisorのテキストをクライアント側で読む方法はありません。

executorとadvisorの組み合わせには互換性の制約があります。advisorはClaude Sonnet 4.6以上かつexecutorと同等以上の能力であることが必須で、Opus 5・Fable 5・Fable 5.1・Mythos 5・Mythos 5.1をexecutorに使う場合、有効なadvisorは同じく暗号化結果を返すモデル(Fable 5.1・Mythos 5.1・Mythos 5・Fable 5・Opus 5の範囲)に限られます。つまりこれらのexecutorではclaude-opus-4-8をadvisorに指定できず、指定すると無効なペアとしてAPIが400 invalid_request_errorを返します。

なぜ結果が暗号化されるモデルがあるのか

公式ドキュメントは暗号化の理由そのものを明言していません。ただし挙動から読み取れる範囲では、advisorモデル自身の出力(thinkingを含む)を外部に見せない設計という説明が筋として通ります。advisorは自分のtoolを持たず、コンテキスト管理も行わない専用のサブ推論として動き、thinkingブロックは結果が返る前に破棄されます。テキストの助言だけがexecutorに渡る設計思想の延長で、advisorモデル側のポリシーによっては、その助言テキスト自体もクライアントの目に触れさせない、という選択が取られていると見ることもできます。この解釈は公式に明記された仕様ではなく、モデル別の挙動から逆算した読みである点は留保しておきます。

一方で、実運用上重要なのは理由よりも扱い方です。暗号化されていても、advisorの助言そのものはexecutorの動作に反映されます。次のターンでサーバーがencrypted_contentを復号し、executorのプロンプトへ平文として差し込む仕組みだからです。クライアントに見えないだけで、advisorの判断がexecutorの応答に影響しない、という意味ではありません。

ラウンドトリップで書き換えてはいけない理由

advisor_tool_resultブロックを次のターンのmessagesに積み戻すとき、advisor_redacted_resultの中身は改変せずそのまま送り返す必要があります。encrypted_contentはサーバー側だけが復号できる形式のため、クライアント側で部分的に編集したり、別の文字列に差し替えたりすると、サーバーは復号に失敗し、advisorが実際に出した助言をexecutorが受け取れなくなります。

この制約はadvisor_result(平文)でも同じです。textが読めるからといって、要約や整形を加えてから送り返すと、executorが参照する助言の内容がリクエストごとに変わってしまいます。どちらの形式でも、round-tripは常にそのままが原則です。

会話の途中でadvisorのモデルを切り替えることもできます。前のターンではclaude-opus-4-8が返したadvisor_resultが履歴に残り、次のターンからclaude-opus-5に切り替えれば新しい呼び出しはadvisor_redacted_resultになります。このとき履歴には2種類のcontent.typeが混在するため、受信側の実装はcontent.typeで必ず分岐させる必要があります。片方の形式だけを前提にパースするコードは、モデルを切り替えた瞬間に壊れます。

プロンプトキャッシュへの影響は形式で変わらない

executor側のキャッシュ設計では、暗号化かどうかを気にする必要がありません。advisor_tool_resultブロックはほかのコンテンツブロックと同様にキャッシュ可能で、そのブロックの後に置いたcache_controlのブレークポイントはヒットします。executorのプロンプトには、クライアントがtextを受け取ったかencrypted_contentを受け取ったかに関わらず、常に復号済みの平文の助言が入っているため、キャッシュの挙動は両方の結果形式で同一です。クライアントから見た可読性と、サーバー内部でexecutorが参照する中身は別の話だと分けて考えると理解しやすくなります。

advisor自身の側にも独立したキャッシュ層があり、ツール定義にcachingを設定すると同一会話内でのadvisorの過去トランスクリプトをキャッシュできます。ただしこれは結果の暗号化・非暗号化とは無関係な、advisor呼び出し側だけのコスト最適化です。

エラー時は暗号化の議論の対象外になる

advisorの呼び出しが失敗すると、content.typeはadvisor_resultでもadvisor_redacted_resultでもなくadvisor_tool_result_errorになり、error_codeだけが入ります。max_uses_exceeded(呼び出し回数の上限到達)、overloaded(advisor側の容量超過)、prompt_too_long(会話がadvisorのコンテキストウィンドウを超過)などが該当し、暗号化・平文どちらの形式でもないため、実装側では3つ目の分岐として扱う必要があります。エラーが起きてもリクエスト全体は失敗せず、executorは助言なしで応答を続けます。

ZDR(Zero Data Retention)との関係

advisorツールは、Claude APIのZDR(ゼロデータ保持)対象機能の一覧で「対象」に分類されています。理由として公式が挙げているのは、advisorモデルの出力がAPIレスポンスに含まれて返る一方、レスポンスを返したあとサーバー側に何も保存されない、という設計です。暗号化されたencrypted_contentはクライアントには読めませんが、これはZDRの可否とは別の軸です。ZDRは「サーバー側にレスポンス後もデータを残すかどうか」の話で、encrypted_contentは「クライアント側でその場のレスポンスを読めるかどうか」の話です。両立していて矛盾しません。

一方でHIPAA対応(保護対象の保健情報を扱う仕組み)の一覧では、advisorツールは対象外です。医療情報を扱う組織がHIPAA準拠を必要とする場合、advisorツールをそのまま使う設計は避けたほうが安全です。ZDR自体の適用範囲や、契約形態ごとの違いはClaude Zero Data Retentionが有効になる契約形態の切り分けで扱っています。

なおFable 5.1・Mythos 5.1・Fable 5・Mythos 5は、advisorとして使うかどうかに関係なく「30日間データ保持が必須のCovered Model」に指定されており、明示的な許可なしにZDR対象外になります。これらのモデルがadvisorとして暗号化結果を返す事実と、Covered Modelとして30日保持が必須という事実は、公式ドキュメント上は別々の理由付けで説明されており、同じ設計判断から来ているとは書かれていません。Opus 5はCovered Modelの一覧に含まれない一方で、advisorとしては同じadvisor_redacted_resultを返すため、2つの分類が単純に一致するわけではない点は誤解しないようにしたいところです。

advisorツールの提供範囲はbeta段階で、Claude APIとClaude Platform on AWSでのみ利用できます。Amazon Bedrock・Google Cloud・Microsoft Foundryでは現時点で提供されていません。

Claude Managed Agentsでは型の議論が及ばない

ここまでのadvisor_tool_resultブロックとcontent.type分岐の話は、tools配列にadvisorツールを追加する通常のAPI呼び出しが前提です。Claude Managed Agentsのセッションでは事情が異なります。advisorはツール定義ではなく、エージェントのマルチエージェントrosterのエントリとして構成し、助言はレスポンス中のadvisor_tool_resultブロックではなく、セッションのイベントストリーム上のthread eventとして届きます。roster側のadvisorエントリにはmax_uses・max_tokens・cachingのオプションもありません。本記事で扱った平文・暗号化の分岐やcontent.typeによるパース方針は、Managed Agentsのroster経由のadvisorには当てはまらない点に注意してください。

ログ・オブザーバビリティ実装への影響

社内のリクエストログやオブザーバビリティ基盤にadvisor_tool_resultの中身をそのまま記録する設計は、advisorモデルの選び方次第で意味が変わります。claude-opus-4-8をadvisorにしていれば、ログには助言の平文がそのまま残ります。これはデバッグには便利ですが、advisorの助言に機密情報や個人情報が混じる可能性があるワークロードでは、ログ基盤側でのマスキング・アクセス制御の対象に含める必要が出てきます。

一方、Opus 5やFable系をadvisorにしている場合、ログに残るのはencrypted_contentという不透明なブロブだけです。ログを見ても助言の中身は追えないため、「advisorが具体的に何を提案してexecutorがどう動いたか」をデバッグしたい場合は、advisorのモデル選定を平文が返るものに変えるか、executor側の最終出力やツール呼び出しのログから間接的に推測するしかありません。チーム内でadvisorの提案内容を監査・デバッグしたい要件があるなら、モデル選定の時点でこの制約を織り込んでおく必要があります。

実装時に確認しておくチェックリスト

advisorツールを組み込む際、結果の形式まわりで見落としがちな点を挙げます。

• content.typeで必ず分岐する: advisor_result / advisor_redacted_result / advisor_tool_result_errorの3種類を想定し、どれか1つだけを前提にパースしない
• advisorモデルを設定で切り替え可能にしているなら、両方の形式に対応できているか確認する: 環境変数やコンフィグでadvisorモデルを差し替えられる実装は、テスト環境では平文モデル、本番では暗号化されるモデルを使っていて、本番でだけ表示が崩れるという事故が起きやすい
• encrypted_contentをUIにそのまま出さない: 意味を持たない文字列なので、暗号化される可能性のあるモデルを使う場合は「advisorが助言を検討中」のような代替表示を用意する
• ラウンドトリップ時に中身を書き換えない: 平文でも要約・整形をせず、受け取ったブロックをそのままmessagesに積み戻す
• HIPAA準拠が必要なワークロードでは採用可否を事前に確認する: advisorツールはZDR対象だがHIPAA対象外という前提でアーキテクチャを組む

最小構成の実装は別記事にある

tools配列へのadvisor_20260301エントリの書き方、max_uses・max_tokens・cachingといった任意パラメータ、executorとadvisorの組み合わせ制約はClaude APIのadvisor toolを実装する最小構成にまとめています。本記事は結果の型がどう分岐しどう扱うべきかに絞り、料金の内訳はClaude API advisorツールの課金構造、コストを抑える具体策はClaude API advisorツールのコスト削減に分けています。

まとめ

advisorツールの結果は、advisorに指定したモデルだけでadvisor_result(平文)とadvisor_redacted_result(暗号化)のどちらが返るかが決まります。Opus 5・Fable 5・Fable 5.1・Mythos 5・Mythos 5.1をadvisorにすると暗号化され、それ以外の対応モデルなら平文です。暗号化されていてもexecutorの応答には反映され、次のターンへはどちらの形式も改変せずround-tripさせる必要があります。キャッシュの挙動は形式で変わらず、ZDR対象である一方HIPAA対象外という点は、医療系のワークロードで採用を検討する前に必ず確認しておくべき条件です。