ツールの失敗は入力修正・再認証・再試行・結果照会に分ける
同じ失敗を何度もモデルへ返して続行させない。直せる入力、一時障害、認可拒否、操作の結果不明を分け、許可された復旧だけを実行側で選べるようにする。
用語
- エラー分類
- 失敗の原因と、その後に許される行動を分けること。
- バックオフ
- 再試行までの待ち時間を設け、障害中の連続呼び出しを抑える方法。
- 結果不明
- 外部操作が完了したか、失敗したかを現在の観測では確定できない状態。
図と例
失敗の種類を判定 → 許される復旧を選ぶ → 期限と再試行安全性を確認 → 復旧または担当へ引き継ぐ
仮定の例：CRMへの住所変更で日付形式の不備なら入力を直せる。権限不足なら処理を止め、正規の権限確認へ進む。変更要求を送った後に応答が消えた場合は、失敗と決め付けて再送せず、操作IDと現在のCRM状態を照合する。
実際のサービス・製品では
Model Context Protocol
MCPの2025-11-25版はJSON-RPCのプロトコルエラーと、isErrorを持つツール実行エラーを区別する。ツールエラーには入力や業務上の失敗も含まれる。どの失敗を再試行してよいかは、実行側のルールとして設計する。
資料を読む
解説
顧客の連携先で、期限切れ資格情報、入力の型違い、業務上の拒否、過負荷、応答消失を試す。復旧回数と同じ失敗の反復を記録し、上限到達や権限変更が必要な場合は人へ戻す。
エラー分類は原因と、その後に許される行動を分けて定めたもの。入力不備なら不足項目を示して修正し、権限不足なら正規の権限確認や再認証へ戻す。モデルが別のアカウントを試して制限を回避してはいけない。一時障害は期限と予算の範囲でバックオフし、書き込みでは再試行の安全性を確認する。タイムアウトは操作の失敗を意味するとは限らないため、結果不明なら操作IDで照会する。プロトコルの成功と業務の成功も異なり、MCPではツール結果のisErrorを含めて扱う。エラー文は不足項目や次の手段を伝え、秘密や内部ログ全文をモデルへ流さない。
トレードオフ
- 復旧可能な入力不備をモデルへ返す
- 得るもの：不足条件を補い処理を進められる
- 払うもの：修正可能な範囲と回数の制限が必要
- 状態と権限に関わる失敗を実行側で制御する
- 得るもの：危険な再送や権限回避を防ぐ判断を固定できる
- 払うもの：エラーと外部結果の照会経路を整える必要がある
さらに学ぶ
チェック
顧客のCRMが権限不足を返した。モデルが別の接続アカウントを探そうとしている。適切な扱いは？
- どれか通るまで別アカウントで繰り返す
- 実行を止め、正規の権限確認や必要な再認証へ戻す
- 同じ操作を無制限に再送する
解答と解説
実行を止め、正規の権限確認や必要な再認証へ戻す
権限不足はアカウントを替えて回避する対象ではない。検証した依頼者に許可された経路で確認する。入力修正や一時障害の再試行とは復旧方法が異なる。