使い方: シナリオを読み、選択肢から答えを決めてから、解説をタップで展開。
調査会社のリサーチ自動化チームは、coordinatorエージェントが検索・分析・要約の3種の専門subagentに処理を委譲する調査パイプラインを構築している。1回の調査リクエストで10〜30件のトピックを処理し、各トピックは独立している。外部の検索APIは時々レート制限（429）を返し、分析subagentは稀にタイムアウトする。実測では全体の2〜5%のトピックでsubagentの1つが失敗する。ユーザーへの報告はP95で30秒以内に開始すること（逐次ストリーミング・完了待ちではない）が要求され、成功率95%以上がSLAだ。
実装後のテストで、subagentの1つが失敗したトピックについて、coordinatorが最終レポートからそのトピックを丸ごと欠落させたり、逆に失敗したセクションに幻の内容を生成してしまう事例が確認された。SLAと成功率の両方を満たす設計はどれか。
エージェントの部分失敗は「隠す」でも「全部やり直し」でもなく、構造化されたエラーを上位エージェントに返して判断させるのが本番設計。エラーもモデルに読める情報として渡すのがTool Designの原則。
マルチエージェントシステムでは部分失敗が常態であるため、失敗の扱いを「制御フロー（コード側で握る）」から「モデルへの情報提供（構造化エラーの返却と判断委譲）」に移すのが本番設計の原則。Claudeのtool使用では、失敗したtool呼び出しをtool_resultとして返却する際にエラー内容を構造化して含めることで、モデルが次のアクション（再試行・代替手段・部分完了の扱い）を状況に応じて判断できる。これにより「リトライすべき失敗（429）」と「リトライしても無意味な失敗（入力不備）」を同一コードパスでなく、文脈に応じて処理できる。
参照: docs.claude.com tool use実装ガイド（2026-09-05確認）
SaaS企業のプラットフォームチームは、Claude APIを使った社内ツール運用エージェントを構築している。エージェントはユーザーの依頼（「本番DBのスロークエリ一覧を取って原因仮説を出して」等）を受け、社内ツールをtool呼び出しで操作し、結果を踏まえて次のtool呼び出しや最終回答を生成する、いわゆるエージェントループを実装する。1回の依頼でtool呼び出しは平均4回・最大12回発生し、月間APIコスト予算は固定で、無限ループが起これば即座に予算を破綻させる。チームはAnthropic公式SDKのレスポンス仕様に基づいてループを実装することにした。
レスポンスのstop_reason仕様に忠実で、かつ無限ループと「途中終了」の両方を防ぐループ実装はどれか。
stop_reasonがtool_useである間はtoolを実行して結果をmessagesに追加して再リクエストし、stop_reasonがend_turnになったらループを抜ける。あわせて反復回数の上限（safety ceiling）も別途設けるエージェントループの正終了条件はstop_reason == "tool_use"で継続・end_turnで停止。テキストの完了フレーズや固定回数はどちらも「途中終了」と「無限ループ」を両方生む。
Claude APIのMessages APIでは、モデルがtoolを呼びたいときはstop_reason: "tool_use"で応答し、tool_useブロックとともに終了する。クライアント（ループ側）はtoolを実行し、その結果をtool_resultブロックとしてmessagesに追加して再リクエストする。モデルがもうtoolを必要とせず最終回答を出すときはstop_reason: "end_turn"で応答する。したがって「tool_useの間はループ・end_turnで抜ける」が仕様に忠実な終了条件である。実務ではモデルが自律的に終了しない異常系（タスクの迷子・予算暴走）に備え、反復上限やタスク予算を安全網（secondary）として併設する。なおstop_reasonはmax_tokens・pause_turn・refusalなど他の値も取りうるため、実運用のコードでは未知の値へのフォールバックも必要である。
stop_reason: APIレスポンスがなぜ終了したかを示す仕様上のフィールド。tool_use（tool呼び出し待ち）・end_turn（モデルが自発的に終了）・max_tokens・pause_turn・refusal等の値を取る。エージェントループの分岐の正典stop_reasonが示すまで繰り返す構成。エージェントアーキテクチャの最小単位pause_turnやrefusalへの分岐も実装済みか、上限到達時のユーザー通知があるかmax_tokensでなく自前フラグ）を監視しているかstop_reasonの全値を網羅する分岐の保守参照: docs.claude.com tool use実装ガイド（2026-09-05確認）
開発チームではClaude Codeを使ったレビュー体制を整備し、「コードベース構造を解析してモジュール依存のレポートを出すカスタムスキル」を作成した。スキルは毎回非常に長い構造レポートを出力する。ところが3回目の実行あたりから、メインセッションが1回目にマップしたモジュールの内容について質問に答えられなくなり、「この種のサービスは通常こういう構成です」という一般論に逃げる（実際のコードベースの内容を忘れたような挙動）事例が出始めた。チームの作業制約として、レビュー中はメインセッションで並行して複数の質問応答をこなす必要があり、セッション全体を再起動できない。
原因に直接効く修正はどれか。
/compactを実行して会話履歴を要約し、トークン予算を回収する運用に変える~/.claude/skills/へ移動して個人スキルにし、出力が自分のセッションにしか流れないようにするcontext: forkを追加し、スキルを分離されたsubagentコンテキストで実行してメインセッションへは要約のみ返す大量出力を毎回メインセッションに流すとコンテキストが食いつぶされる。context: forkでsubagentコンテキストに分離し、要約だけ返すのが原因への直接対処。
Claude Codeのセッションは単一のコンテキスト窓を共有しており、長いスキル出力が都度流れ込むと、初期に読み込んだコードベースの情報がコンテキスト窓の実用範囲から押し出され、モデルが「一般論に逃げる」挙動を示す。これはコンテキスト窓の物理的な上限でなく、実効的な情報密度の問題として現れる。カスタムスキルのfrontmatterでcontext: forkを指定すると、スキルは独立したsubagentのコンテキストで実行され、メインセッションへは結果の要約のみが返る。これにより「重い解析」と「対話の記憶」を別のコンテキストに分離できる。チーム共有コードベースではSKILL.md自体はリポジトリ内で共有しつつ、実行コンテキストだけを分離するのが定石である。
context: fork: スキルのSKILL.md frontmatterで指定する実行コンテキストの指定。スキルを独立したsubagentコンテキストで実行し、メインセッションの会話コンテキストを汚染しない/compactは本番で劣る。【本番で劣る理由】要約で1回目に得た詳細なコードベース知識そのものが落ちるため、「1回目にマップした内容に答えられない」という症状をむしろ悪化させる。「セッション全体を再起動できない」制約下で記憶を捨てるのは方向が逆。【有効な別シナリオ】履歴の詳細が不要な長時間セッションの延命には有効。【現場の検証点】compact後に古い質問へ答えられるかのリグレッション確認をしたか~/.claude/skills/への移動は「誰のスキルか」のスコープ変更であって、実行コンテキストは変わらない。チーム共有も失う。原因（メインセッションへの蓄積）に無関係。【有効な別シナリオ】個人用の実験的スキルを本番共有から隔離したい場合は適切。【現場の検証点】移動前後でメインセッションのトークン消費が変わらないことを実測したか参照: code.claude.com Skills ドキュメント（2026-09-05確認）
業務システムの受付チームは、非構造化文書（問い合わせメール・申請書の自由記載欄）から「案件ID・発生日・金額・担当者名」の4フィールドを抽出するパイプラインを運用している。日次で10万件を処理し、後続の会計システムが厳密なスキーマを要求するため、フィールドの欠落や型の崩れ（金額が「約10万円」と文字列で入る等）は0件が理想だ。レビュー用プロンプトでは、4つのフィールド名と各フィールドの意味を散文で説明している。しかし本番実行の統計を取ると、実行ごとにフィールドが1つ欠けたり、出力の形（JSONの構造）が変わったりする事例が絶えない。
この崩れに最も直接的に効く2つの変更を選べ。
形式の揺れへの本質的な対処は「機械に強制させる（スキーマ）」と「例示で型を教える（few-shot）」の2本。説明文を増やす・位置を変えるは本質でない。
LLMの散文出力は確率的であるため、「フィールド名を説明する」だけでは出力形式は保証されない。本番で形式を保証する第一の手段は構造化出力（JSON Schemaを定義し、tool_useのパラメータや構造化出力APIでスキーマに合う形のみを出力させる・厳密検証strictを併用する）であり、第二の手段はfew-shot例示（完成形の入出力例をそのまま示す）である。両者は補完関係にある: スキーマは構造（JSONの形・必須フィールド）を強制し、few-shotは内容の粒度（「約10万円」を100000に正規化する等・型や表記の揺れ）を矯正する。対照的に「説明を詳しくする」「定義の場所を変える」「要件を再掲する」は散文出力の確率性を変える力が弱い。
additionalProperties: falseと必須フィールドの指定と組み合わせる参照: docs.claude.com structured outputs ガイド（2026-09-05確認）
開発者支援プラットフォームのチームは、エージェントから外部の在庫管理APIを問い合わせるMCPツールを実装している。このAPIは利用者が多く、「該当商品なし」（正常系の一種）・レート制限（429）・タイムアウトが日常的に発生する。実装者の制約として、エージェントは人間の確認なしで複数のツールを連続実行するため、エラー発生時にエージェント自身が適切に回復できること（諦めず・暴走もせず）が要件だ。ツールの戻り値の設計として、この要件に最も沿うものはどれか。
ツールのエラーはエージェントが読んで判断できる形で返すのが原則。「隠す」「生のまま渡す」「見えないところでリトライし続ける」はいずれも回復不能・暴走の原因。
ツール設計の原則として、エラーは「構造化された結果」としてモデルに返却するのが本番設計である。モデルはエラーの種別と再試行可否を読むことで、「そのまま再試行する」「別の検索語で再実行する」「ユーザーに報告する」といった文脈に応じた回復行動を選べる。対照的に、エラーを隠す（空の成功応答）とモデルは「該当なし」と「システム障害」を区別できず誤った回答をする。生の例外文字列はトークンを浪費し、モデルが誤解する情報を増やす。ツール内部の無限リトライはレート制限を悪化させ（429の連鎖）、停止条件を欠くため暴走の温床になる。
参照: docs.claude.com tool use実装ガイド（2026-09-05確認）
EC運営会社のカスタマーサポートチームは、返金・請求の不一致・口座変更を自動処理するエージェントを導入した。目標は初回接触解決率80%以上・自動処理の費用対効果は人件費と比べて明確に有利。ただし規約として、返金額が5万円を超える案件・本人確認が取れない案件・顧客が明示的に人間を要求した案件は人間のオペレーターが処理しなければならない。導入テストでは、自動処理が破綻した案件をエージェントが不自然な回答で粘り続け、顧客が二度手間になった事例と、逆に簡単な問い合わせまで人間に投げて自動化メリットが消えた事例の両方が観測された。
エスカレーション設計として最も適切なのはどれか。
エスカレーションの本体は「必ず人間」という規約条件を機械判定で実装すること。モデルの自然挙動や回数トリガーへの丸投げは「粘る」「投げすぎ」の両方を生む。引き継ぎ時の経緯要約が二度手間を防ぐ。
カスタマーサポートエージェントの信頼性設計では、エスカレーションを2層に分ける。第1層は規約・ポリシー由来のハード条件（金額しきい値・本人確認・顧客の明示要求）で、これはモデルの判断に任せず機械的に判定して強制する。第2層は解決不能の軟条件（ツールが失敗を繰り返す・類似問い合わせの解決策が無い等）で、こちらはプロンプトでモデルに判断を許可する。両層を混ぜないことが重要で、ハード条件をプロンプトの言い回しに任せると例外運用で破られる。引き継ぎ時には経緯の要約（顧客の問題・試行した解決策・顧客の感情状態）を添え、オペレーターの二度手間を防ぐ。
参照: docs.claude.com tool use実装ガイド（2026-09-05確認）
開発チームはプルリクエストを出した時点でClaude Codeに「変更差分をレビューし、指摘を構造化データで返す」処理を自動実行させたい。実行環境はCIランナー（ターミナル対話ができない・人間が画面を見ていない）で、指摘は後続のジョブがJSONとしてパースしてGitHubのコメントに投稿する。実行のたびに承認待ちで止まることがあってはならず、CI上のジョブには最小権限を与えたい。レビュー品質を保つため、1回の実行で完結させたい。
Claude CodeをCI/CDで無人実行するための設定として正しいのはどれか。
-pフラグ・print mode）で起動し、--output-format jsonで結果を構造化して受け取る。実行を許可するツールを明示的に限定して権限を最小化する無人実行は-p（print mode・非対話）+ --output-format json（構造化出力）+ ツール権限の明示的限定の組み合わせ。対話モードは承認待ちで止まる・テキストの正規表現パースは壊れやすい。
Claude Codeには人間の入力なしで1回の実行を完結させる非対話モード（-p・print mode）があり、CI/CDでの自動実行の正典である。--output-format jsonを併用すると、結果をテキストの文字列解析でなく構造化データとして受け取れ、後続ジョブのパースが頑健になる。CIランナーでは人間がいないため、対話的な承認プロンプトが発生する設定だと実行が停止する。これを避けるため、実行を許可するツール（読み取り系ツール等）を明示的に限定し、権限の確認をそもそも発生させない設計にするのが最小権限の原則に合う。セッションはジョブごとに独立するため、CI上の各実行は互いに汚染されない。
-p（print mode）: Claude Codeの非対話モード。プロンプトを1回与えて結果を受け取り終了する・CI/CD自動実行の基本形--output-format json: 出力をJSONで受け取るオプション。後続のパイプラインが文字列解析ではなく構造化データを消費できる参照: code.claude.com CLI リファレンス（2026-09-05確認）
保険会社の処理チームは、申請書の自由記載から「契約番号・事故日・請求額・連絡先」を抽出するパイプラインを運用している。後続システムに渡すため、出力はJSON Schemaで必須4フィールド・型固定としている。運用統計を見ると、抽出自体はほぼ成功するが、スキーマ検証に失敗するレコードが日次で数百件発生している。内訳を実査すると、①申請書に該当情報が記載されていないフィールドでモデルが「不明」という文字列を型違反のまま入れる、②検証失敗したレコードがそのまま破棄され、手動再処理の山になっている、の2種が大半だった。検証は厳密に保ちたい（緩めたくない）。
この失敗に構造的に対処する2つの変更を選べ。
欠損はnullという値として表現し（スキーマを緩めない）、検証失敗はエラーをモデルに返して修正させるリトライループで自己修復させる。スキーマ緩和・温度変更・フリーテキスト化はいずれも問題を後段へ先送りするだけ。
スキーマ検証失敗には2種類の原因があり、対処も分かれる。①「入力に情報が無い」型の失敗は、モデルが存在しない値を捏造するか型違反の文字列（「不明」等）を入れることで起きる。対処はnullable設計（欠損を明示的なnullとして表現するようスキーマと指示の両面で定義）であり、これにより「欠損」と「抽出の失敗」を区別でき、捏造（ハルシネーション）も防げる。②「抽出は合っているが形式が崩れた」型の失敗は、validation-retryループ（検証エラーメッセージをモデルへ返し、修正を指示して再検証する・上限付き）で自己修復させる。検証そのものは緩めないのが原則で、緩和は問題を後段の静かな破損に変えるだけである。
参照: docs.claude.com structured outputs ガイド（2026-09-05確認）
社内DXチームは、エージェントから社内システムを操作できるよう、REST APIのエンドポイント1個に対応するツールを1個ずつ定義して合計20個のツールをMCPサーバーで公開した。ところが実テストで、モデルが類似したツールを取り違える（顧客検索と注文検索を混同する等）・引数を間違える事例が多発した。ツールの説明文は機械生成の簡素なもので、各ツールは平均3〜5個しかパラメータを持たない。エージェントの実タスクは「顧客の注文履歴を調べて問題を特定する」等、6種類程度の業務タスクに収束している。
エージェントのツール選択精度を上げる設計として最も適切なのはどれか。
モデルのツール選択精度はツール数が少なく・説明が具体的であるほど上がる。エンドポイント=ツールの1:1公開は選択肢を20個も提示する設計ミスで、業務タスク単位への統合が正解。
モデルはツール一覧の中からタスクに合うものを選ぶが、選択精度は候補数と説明の質に強く依存する。実務の指針として、同時に公開するツールは少数（4〜5個程度が目安）に絞り、各説明には「いつ使うか・引数の意味・何を返すか・エラー時の挙動」を具体的に書くのが良い設計とされる。APIのエンドポイント構造をそのままツールに写すと、モデルにとっての選択肢だけが増えて説明の区別はつかなくなる。正しい抽象化レベルは「エンドポイント」でなく「業務タスク」であり、タスク単位のツールは内部で複数のAPI呼び出しをまとめられる。
参照: docs.claude.com tool use実装ガイド（2026-09-05確認）
通信会社のサポート部門は、1件の問い合わせを数十ターンにわたって処理するサポートエージェントを運用している。顧客の契約情報の照会・プラン変更の試行・エラーの調査など、1セッションで大量のツール結果が会話に蓄積する。運用3ヶ月で、セッション後半になるほど初期に確認した契約内容についての質問に答えられなくなり、同じ確認を顧客に繰り返す事例が増えた。会話の途中で「エラー: コンテキスト長超過」で実行が止まる事例も出ている。顧客との会話は止められない（セッションの再開は顧客体験として不可）。
この劣化への対処として最も適切なのはどれか。
長時間セッションの定石は要約による履歴圧縮+重要事実の明示的保持。「エラーが出てから削除」「窓の大きさで押し切る」「会話を打ち切る」はいずれも顧客体験か情報のどちらかを失う。
長い会話では、ツール結果の蓄積がコンテキスト窓の実効容量を食い潰し、初期の重要情報がモデルから「遠くなる」。対処の基本は2本立てである。第1に履歴の圧縮（compaction・要約への置き換え）で、会話を続けられる長さに保つ。第2に、圧縮で落ちては困る情報（契約番号・確認済みの事実・顧客の制約）を要約の外に構造化して明示保持する。圧縮だけだと要約が要約を圧縮する連鎖で重要事実が風化するため、「何を絶対に落とさないか」の明示が信頼性の要である。なおエラー後の対処療法（超過してからの削除）は、削除時点の選択が雑になりがちで、モデルがすでに劣化した状態を長く運用することになる。
参照: docs.claude.com context management ガイド（2026-09-05確認）