escalation-governance

エスカレーションのガバナンス

概要

モデルのエスカレーション（haiku→sonnet→opus）では、速度とコストを推論能力と引き換えます。このトレードオフには正当な理由が必要です。

基本原則： エスカレーションは、より深い推論を本当に必要とするタスクのためのものであり、「もっと賢いモデルなら解決できるかもしれない」という理由で行うものではありません。

鉄則

NO ESCALATION WITHOUT INVESTIGATION FIRST

エスカレーションは決して近道ではありません。現在のモデルでは不十分な理由を理解していないなら、エスカレーションは時期尚早です。

エスカレーションすべき場合

正当なエスカレーションのきっかけ：

きっかけ	説明	例
真の複雑さ	タスク自体が、きめ細かな判断を必要とする	セキュリティポリシーのトレードオフ
推論の深さ	不確実性を伴う複数段階の推論	アーキテクチャの決定
前例のないパターン	適用できる既存のパターンがない	初めての実装
重大な影響	エラーのコストを考えれば、能力への投資が正当化される	本番環境へのデプロイ
曖昧さの解消	複数の妥当な解釈を比較検討する必要がある	仕様の明確化

エスカレーションすべきでない場合

不適切なエスカレーションのきっかけ：

アンチパターン	不適切な理由	代わりに行うこと
「もっと賢いモデルなら解決できるかもしれない」	これは手当たり次第に試しているだけです	根本原因を調査する
何度も試して失敗する	能力不足ではなく、アプローチが間違っていることを示しています	自分の前提を問い直す
時間的なプレッシャー	急いだからといって、タスクの複雑さが変わるわけではありません	系統的な調査のほうが早く済みます
調査せずに不確実だと判断する	まだ理解しようと試みていません	まず根拠を集める
「念のため」	安全性が高まるわけではなく、リソースを浪費します	実際の複雑さを評価する

判断フレームワーク

エスカレーションする前に、次の質問に答えてください。

1. 問題を理解できていますか？

• 現在のモデルでは不十分な理由を説明できますか？
• 具体的にどの推論能力が不足しているかを特定しましたか？
• これは能力の不足ですか、それとも知識の不足ですか？

知識不足の場合： さらに情報を集めてください。エスカレーションはしないでください。

2. 系統的に調査しましたか？

• エラーメッセージや出力を注意深く読みましたか？
• 同様の問題を解決した事例がないか確認しましたか？
• 仮説を立てて検証しましたか？
• このコードベースでは、対象となる問題がすでに何通り実装されており、 そのうちどれが現行ですか？

1つの問題に対する実装が2つ共存していると、タスクは実際より難しく見えます。これは知識不足です。参照検索で実装の数を確認し、エスカレーションする前に両方を読んでください（問題を「ある懸念のモデル」と呼んでいる docs/knowledge-corpus/decoherence.md を参照してください）。

調査していない場合： まず調査を完了してください。

3. エスカレーションは適切な解決策ですか？

• 現在のモデルのまま、別のアプローチで対応できますか？
• タスク自体が複雑なのですか、それとも自分で複雑にしているのですか？
• タスクをより小さな部分に分ければ解決しやすくなりますか？

分割できる場合： エスカレーションせず、タスクを分割してください。

4. トレードオフを正当化できますか？

• エスカレーションのコスト（レイテンシ、トークン、費用）はどれくらいですか？
• そのメリット（精度、安全性、網羅性）は何ですか？
• メリットはコストに見合っていますか？

見合わない場合： エスカレーションしないでください。

エスカレーションの手順

エスカレーションが正当化される場合：

1. 理由を記録する - 現在のモデルでは不十分な理由を明記します
2. 範囲を指定する - どの具体的なサブタスクに、より高い能力が必要かを明確にします
3. 成功の基準を定める - エスカレーションしたタスクが成功したと、どのように判断するかを定義します
4. 速やかに戻る - 推論タスクの後は、効率のよいモデルに戻します

エスカレーションの理由として不十分なもの

エスカレーションには、タスクに関連した理由が必要です。よくある以下の理由は、先ほどの4つのステップを満たしていません。それぞれの制約が、その理由では不十分な理由を示しています。

• 「複雑です」では、現在のモデルでは不十分だと判明した試行が必要です。複雑さだけでは、モデルの失敗を予測できません。
• 「念には念を入れて」では、リスクが特定されていません。より大きなモデルを使うと、誰も特定していないリスクを減らすことなく、コストだけが増えます。
• 「試したけれど失敗しました」では、試行回数と失敗した理由が必要です。まだ調査されていない失敗は、多くの場合、より大きなモデルでも繰り返されるコンテキストの問題です。
• 「ユーザーは品質を期待しています」は、テスト、レビュー、根拠を含むプロセスによって満たされます。モデルのサイズで、それらが得られるわけではありません。
• 「今回だけ」でも、文書化された理由が必要です。理由のない例外を繰り返すと、それが標準になってしまうためです。
• 「時は金なり」は調査を優先する考え方です。より大きなモデルで試行錯誤を繰り返すより、現在のモデルで体系的に確認するほうが速く済みます。

エージェントのスキーマ

エージェントは、フロントマターでエスカレーションのヒントを宣言できます。

model: haiku
escalation:
  to: sonnet                 # Suggested escalation target
  hints:                     # Advisory triggers (orchestrator may override)
    - security_sensitive     # Touches auth, secrets, permissions
    - ambiguous_input        # Multiple valid interpretations
    - novel_pattern          # No existing patterns apply
    - high_stakes            # Error would be costly

重要なポイント：

• ヒントは参考情報であり、必須ではありません。
• 最終的な決定権はオーケストレーターにあります。
• オーケストレーターは、ヒントがなくてもエスカレーションできます（より広いコンテキストに基づくため）。
• オーケストレーターは、ヒントを無視することもできます（実際にはタスクが簡単な場合）。

オーケストレーターの権限

オーケストレーター（通常は Opus）が、エスカレーションの最終判断を下します。

ヒントに従う： ヒントが観察された状況と一致する場合
エスカレーションするよう上書きする： コンテキスト上必要な場合（ヒントがなくても）
現在のモデルを使い続けるよう上書きする： ヒントから想定されるよりタスクが簡単な場合
ヒントを超えてエスカレーションする： ヒントが sonnet を示していても、opus に切り替えます。

会話のコンテキストを踏まえたオーケストレーターの判断は、静的なヒントより優先されます。

危険信号 — 停止して調査する

次のように考えていることに気づいたら：

• 「より優れたモデルで試してみよう」
• 「これは簡単なはずなのに、うまくいかない」
• 「あらゆることを試した」（ただし、なぜ失敗したのか調査していない）
• 「より賢いモデルなら、どうすればよいか分かるだろう」
• 「なぜうまくいかないのか分からない」

これらはすべて、停止して、まず調査する必要があることを意味します。

エージェントのワークフローとの連携

Agent starts task at assigned model
├── Task succeeds → Complete
└── Task struggles →
    ├── Investigate systematically
    │   ├── Root cause found → Fix at current model
    │   └── Genuine capability gap → Escalate with justification
    └── Don't investigate → WRONG PATH
        └── "Maybe escalate?" → NO. Investigate first.

クイックリファレンス

状況	対応
タスク自体が、繊細な推論を必要とする	エスカレーションする
エージェントが確信を持てないが、まだ調査していない	まず調査する
複数回の試行が失敗した	モデルではなく、アプローチを見直す
セキュリティ上の判断／重大な影響を伴う判断	エスカレーションする
「もっと賢いモデルなら分かるかもしれない」	この理由だけでエスカレーションしない
ヒントが該当するが、実際にはタスクが簡単	上書きして、現在のモデルを使い続ける
ヒントは該当しないが、実際にはタスクが複雑	上書きして、エスカレーションする

モデルの能力に関する注意事項

MCP ツール検索（Claude Code 2.1.7+）： Haiku モデルは MCP ツール検索をサポートしていません。ワークフローで多くの MCP ツールを使用する場合（説明がコンテキストの 10% を超える場合）、ツールは後から読み込まれるのではなく、haiku で最初に読み込まれます。そのため、コンテキストが大幅に消費される可能性があります。MCP ツールを多用するワークフローでは sonnet へのエスカレーションを検討するか、haiku エージェントがネイティブツール（Read、Write、Bash など）のみを使用するようにしてください。

Claude.ai MCP コネクタ（Claude Code 2.1.46+）： claude.ai コネクタを設定済みのユーザーには、MCP ツールが追加で自動読み込みされ、ツール説明全体の量が増えることがあります。そのため、haiku エージェントがツール検索のしきい値である 10% を超える可能性が高まります。MCP ツールを多用するワークフローについてエスカレーションを判断する際は、/mcp で claude.ai コネクタのツール数を確認し、考慮してください。 エスカレーションに代わる努力レベルの調整（Opus 4.6／Claude Code 2.1.32以降）：Opus 4.6 では、努力レベル（low、medium、high）を指定できるアダプティブシンキングが導入されました。Opus 4.6 では 2.1.72 で max レベルが削除され、high がこのモデルの上限になりました。Claude Code 2.1.111 では max が再導入され、Opus 4.7 専用に high と max の間の xhigh が追加されました。他のモデルでは xhigh は high にフォールバックします。記号：○（low） ◐（medium） ●（high） ◉（xhigh） ★（max）。/effort（2.1.111 以降はインタラクティブなスライダー）または /effort auto を使うと、設定をリセットできます。モデルを切り替える前に、現在のモデルで努力レベルを調整すれば十分かどうかを検討してください。

代わりに…	次を検討してください…	条件
Haiku → Sonnet	Haiku を使い続ける	タスクは依然として決定論的で、必要なのはコンテキストの追加だけ
Sonnet → Opus	Opus@medium	高度なアーキテクチャ分析ではなく、適度な推論が必要
Opus@medium → 「もう一度試す」	Opus@high または「ultrathink」	より深い推論を要する、真に複雑なタスク
Opus 4.7@high → エスカレーション	Opus 4.7@xhigh または @max	特に Opus 4.7 で高度なアーキテクチャ分析が必要

デフォルトの努力レベルの変更（2.1.68以降）：Max および Team のサブスクライバーでは、Opus 4.6 のデフォルトが中程度の努力レベルになりました。/model を使って努力レベルを変更するか、プロンプトに「ultrathink」と入力すると、次のターンで高い努力レベルが有効になります。

Opus 4／4.1 の提供終了（2.1.68以降）：Opus 4 と 4.1 は、ファーストパーティ API で利用できなくなりました。これらのモデルを固定しているユーザーは、自動的に Opus 4.6 に移行されます。model フロントマターを使うエージェントに必要な操作はありません。移行は透過的に行われます。

Sonnet 4.5 → 4.6 の移行（2.1.69以降）：Pro／Max／Team Premium で Sonnet 4.5 を使っているユーザーは、自動的に Sonnet 4.6 に移行されます。Sonnet を参照するエージェントのモデルフロントマターも、透過的に解決されます。claude-opus-4-0 と claude-opus-4-1 の --model フラグは、非推奨バージョンではなく Opus 4.6 に正しく解決されるようになりました。

努力レベルパラメーターの修正（2.1.70以降）：カスタム Bedrock 推論プロファイルや標準以外の Claude モデル識別子を使った場合に発生する API 400 エラー This model does not support the effort parameter を修正しました。これにより、すべてのデプロイ構成で努力レベルの調整が安定して機能するようになりました。

各プロバイダーでの Opus 4.6 のデフォルト化（2.1.73以降）：Bedrock、Vertex、Microsoft Foundry のデフォルトモデルが Opus 4.6 になりました（従来は Opus 4.1）。サブエージェントの model: opus／sonnet／haiku エイリアスは、すべてのプロバイダーで現行バージョンに解決されるようになりました。以前は、より古いバージョン（例：4.6 ではなく Opus 4.1）に暗黙的にダウングレードされていました。この修正により、サードパーティプロバイダーでのエージェントディスパッチワークフローが、ファーストパーティ API の動作と一致するようになりました。

modelOverrides 設定（2.1.73以降）：モデルピッカーの項目を、プロバイダー固有の ID（Bedrock の推論プロファイル ARN、Vertex のバージョン名、Foundry のデプロイ名）に割り当てます。モデルの選択を特定の推論プロファイルにルーティングする場合に使用してください。設定の詳細については、モデル最適化ガイドを参照してください。

/output-style の非推奨化（2.1.73以降）：代わりに /config を使用してください。プロンプトキャッシュを改善するため、出力スタイルはセッション開始時に固定されるようになりました。

エージェントのフロントマターでの完全なモデル ID（2.1.74以降）：エージェントの model: フィールドで、エイリアス（opus、sonnet、haiku）に加えて、完全なモデル ID（例：claude-opus-4-6）を指定できるようになりました。以前は、完全な ID は暗黙的に無視されていました。エージェントでは --model と同じ値を指定できるようになりました。

努力レベルの調整は、エスカレーションのガバナンスフレームワークに取って代わるものではありません。追加の軸を提供するものです。変更するモデルや努力レベルを問わず、「まず調査する」という鉄則は引き続き適用されます。

終了条件

• 「エスカレーションする／しない」の判断が、「エスカレーションする場合」または「エスカレーションしない場合」の表にある具体的なトリガーを明示して示されており、複雑さについて曖昧に述べていません。
• エスカレーションを推奨する場合は、エスカレーションを実行する前に、具体的な対象モデルとサブタスクの範囲が記録されています。
• 「より賢いモデルなら解決できるかもしれない」を理由にエスカレーションした場合は、アイアン・ローの違反としてフラグ付けし、阻止されています。
• 現在のモデルで対応できる小さな部分にタスクを分解できる場合は、エスカレーションではなく、その分解が提案されています。