午前2時、RunbookOps編で整えた手順書にしたがって、オンコール担当は問い合わせ対応エージェントをフォールバック用のモデルに切り替えました。ところが10分たってもタイムアウト率は下がらず、フォールバック先でもエラー率が上がり始めます。停止条件に該当したため、手順を中断して二次対応チームにエスカレーションしました。ここまでは手順書どおりです。
二次対応チームが調べると、どうやら原因は社内ではなく、モデルの提供元の側にありそうです。しかし提供元のステータスページは「すべて正常」のまま。サポートケースを起票すると、数時間後に届いた最初の返信はこうでした。「該当リクエストのリクエストID、発生時刻（UTC）、使用モデル、エラーレスポンスの全文をお送りください」。
ところが、アプリケーションのログにはエラーメッセージの1行しか残っていません。リクエストIDは記録しておらず、APIゲートウェイのログは24時間でローテートされていました。ケースは「再現した際に改めて情報をお送りください」という返信で止まり、障害は翌日の昼に”自然に”直りました。原因は分からないままです。提供元に聞くしかない障害で、聞くための材料がなかったのです。
筆者はネットワーク機器ベンダーのNOC（ネットワーク運用センター）とTAC（テクニカルアシスタンスセンター）で長く働いてきました。TACは、お客様からの障害の問い合わせを提供元の側で受ける部門です。机の反対側に座っていた経験から断言できるのは、同じ障害でも、最初の問い合わせに何が書かれているかで解決までの時間は大きく変わるということです。そして、その差を生むのは提供元の技術力よりも、問い合わせる側の”準備”であることが少なくありません。
本稿は、AIエージェントを業務で運用している企業の運用担当者、SRE、情報システム部門、そしてAgentOpsの仕組みづくりを任された方を対象に、モデル・MCPサーバー・SaaSといった提供元へのエスカレーションを、その場の頑張りではなく運用規律にするための設計を整理します。
- はじめに——”提供元待ち”は、待つ側の設計で短くできる
- 本稿の位置づけ
- なぜ”提供元待ち”が長くなるのか
- ベンダー管理の全体像——6つの規律
- 規律1：リクエストIDと再現情報を保全する
- 規律2：サポートケースを標準テンプレートで起票し、追跡する
- 規律3：社内の重大度と提供元のサポート区分の対応表を作る
- 規律4：提供元のSLAと社内SLOをすり合わせる
- 規律5：規約・価格・廃止通知を監視し、変更管理につなぐ
- 規律6：ベンダースコアカードで提供元の実績を測る
- 提供元の種類ごとの違い
- 運用サイクル——いつ、何を見るか
- よくある落とし穴
- ベンダー管理（VendorOps）チェックリスト
- よくある質問（Q&A）
- まとめ——”提供元待ち”を、運用で短くする
- 参考リンク
- 関連記事
はじめに——”提供元待ち”は、待つ側の設計で短くできる
AIエージェントは、ほぼ例外なく社外のサービスに依存しています。推論はLLMの提供元のAPIに、ツール呼び出しはMCPサーバーや外部SaaSに、データは別のクラウドサービスに。社内の構成をいくら丁寧に管理しても、障害の原因が社外にあれば、最後は提供元に調べてもらうしかありません。
このとき多くの組織では、「提供元の対応待ち」がそのまま障害の長さになります。しかし実際には、待ち時間の多くは提供元の調査時間ではなく、情報のやり取りの往復に使われています。「ログをください」「その時刻は何時（どのタイムゾーン）ですか」「どのモデルですか」「影響を受けているユーザー数は」——この往復を1回減らすごとに、解決は数時間から1日単位で早くなります。
本稿で扱う「ベンダー管理（VendorOps）」とは、次の3つを仕組みとして回すことを指します。
- 聞ける：障害が起きた時点で、提供元が調査に必要とする証拠（リクエストIDと再現情報）がそろっている
- 伝わる：誰が起票しても、影響と緊急度が正しく伝わる形式で、正しい窓口に、正しい重大度で届く
- 先回りできる：規約・価格・モデル廃止などの”予告された変化”を障害になる前に捉え、提供元の実績を数字で評価できる
本稿の位置づけ
AgentOpsシリーズでは、ChangeOps → ProblemOps → CMDB → EventOps → RunbookOpsと、ITILの流れに沿って運用規律を積み上げてきました。そこでまだ扱っていないのが「社外の当事者」です。本稿は、これまでの記事で”提供元に渡す”と書いてきた部分の続きを扱います。
| 記事 | 扱う範囲 | 本稿との関係 |
|---|---|---|
| インシデント運用編（9/5） | 重大度の判定、指揮系統、事後レビュー | 本稿は、社内の重大度を提供元のサポート区分に翻訳する部分を扱う |
| 変更管理（ChangeOps）編 | 変更カレンダー、作業手順書、切り戻し | 提供元からの廃止・仕様変更の通知を、社内の変更作業として起票する入口になる |
| 問題管理（ProblemOps）編（10/17） | 再発分析とKEDB | 提供元の不具合番号と回避策を、既知のエラーとして登録する |
| 構成管理（CMDB）編（10/20） | 依存関係の地図と影響範囲分析 | どのCIがどの提供元・どの契約に依存しているかを持たせる土台 |
| イベント管理（EventOps）編（10/23） | アラートの相関、ステータスページとの突き合わせ | ステータスページが”正常”のままでも、こちらから提供元に知らせる手順を扱う |
| ランブック運用（RunbookOps）編（10/26） | 実行できる手順書、停止条件とエスカレーション | 停止条件の先にある“社外へのエスカレーション”を扱う（直接の続編） |
なぜ”提供元待ち”が長くなるのか
1. 証拠が残っていない
冒頭の例のように、提供元が調査の起点にするリクエストIDや正確な発生時刻が記録されていないケースは珍しくありません。提供元のシステムは1日に膨大な数のリクエストを処理しています。「昨夜2時ごろ、タイムアウトが多発した」という情報だけでは、提供元はあなたのリクエストを特定できません。特定できないリクエストは、調査できないのです。
2. 窓口と契約が分からない
障害が起きてから「どこに連絡すればいいのか」「うちの契約に電話サポートは付いているのか」「アカウントの管理者は誰か」を調べ始める組織は少なくありません。担当者が退職していて、サポートポータルにログインできる人がいない——という事態も起きます。クラウド事業者経由でモデルを使っている場合は、モデルの開発元ではなくクラウド事業者のサポートが一次窓口になる、という点も見落とされがちです。
3. 重大度と影響が伝わらない
社内では”全社の問い合わせ窓口が止まっている重大障害”でも、提供元に届いた文面が「APIがときどきエラーになります」であれば、提供元は通常の問い合わせとして扱います。逆に、何でも最高の重大度で起票していると、本当に緊急のときに信用されなくなります。社内の重大度を、提供元が判断できる言葉と区分に翻訳する仕組みが必要です。
4. 起票したら”待つだけ”になる
ケースを起票した時点で、社内の対応が止まってしまうこともよくあります。誰がケースを追いかけるのか決まっておらず、提供元からの質問メールが担当者個人の受信箱で埋もれ、回答期限を過ぎてケースが自動クローズされる。提供元とのやり取りも、社内のインシデント対応の一部として管理しなければ、待ち時間は際限なく延びます。
ベンダー管理の全体像——6つの規律
| 規律 | やること | 防ぐ失敗 |
|---|---|---|
| 規律1 | リクエストIDと再現情報を、障害が起きる前から保全する | 証拠が残っていない |
| 規律2 | サポートケースを標準テンプレートで起票し、起票後も追跡する | 伝わらない／待つだけになる |
| 規律3 | 社内の重大度と提供元のサポート区分の対応表を作る | 緊急度が伝わらない／信用を失う |
| 規律4 | 提供元のSLAと社内SLOをすり合わせる | 守れない社内目標／期待と現実のずれ |
| 規律5 | 規約・価格・廃止通知を監視し、変更管理につなぐ | 予告されていたのに気づかない |
| 規律6 | ベンダースコアカードで提供元の実績を測る | ”なんとなく不満”のまま改善しない |
6つの規律の土台になるのが、ベンダー台帳です。提供元ごとに、次の情報を1か所にまとめておきます。CMDB編で整えたCIとひもづけておけば、「このエージェントが止まったら、どの提供元に、どの契約で、どの窓口に連絡するか」が一目で分かります。
| 項目 | 内容の例 |
|---|---|
| 提供元・製品 | LLM提供元A（推論API）、MCPサーバーB、SaaS C |
| 契約・プラン | エンタープライズ契約／従量課金のセルフサーブ／OSS（契約なし） |
| 一次窓口 | サポートポータル、電話番号、クラウド事業者のサポート、GitHub Issuesなど |
| 起票できる人 | サポートポータルの権限を持つ担当者（最低2名、個人ではなく役割で管理） |
| サポート区分の定義 | 提供元が定める重大度・優先度の区分と、初回応答の目標時間 |
| SLA | 対象範囲、測定方法、除外事項、救済内容 |
| 情報源 | ステータスページ、変更履歴、廃止予定の一覧、通知の受信先 |
| 関連するCI | 依存しているエージェント・サービス（CMDBのCI） |
| アカウント担当 | 営業担当、テクニカルアカウントマネージャー（契約にある場合） |
規律1：リクエストIDと再現情報を保全する
”show tech”にあたるものを、平常時から残しておく
ネットワーク機器のTACでは、お客様に最初にお願いする情報がほぼ決まっていました。機器の構成と状態をまとめて出力するコマンド（いわゆる”show tech”）の結果、発生時刻、そして正常時との違いです。これがそろっていれば、TAC側はすぐに調査を始められます。そろっていなければ、最初の数往復はすべて”情報集め”に消えます。
AIエージェントの世界で”show tech”にあたるのが、リクエストIDを中心とした、1件ごとのリクエストのメタデータです。主要なLLM提供元の多くは、APIのレスポンスヘッダーにリクエストを一意に識別するIDを返しています（ヘッダー名は提供元によって異なるため、各社のドキュメントで確認してください）。提供元の調査は、このIDから始まります。
記録しておくべき項目
障害が起きてから集めるのではなく、すべての外部呼び出しについて、平常時から次の項目をログに残します。
| 項目 | 内容 | なぜ必要か |
|---|---|---|
| リクエストID | 提供元がレスポンスで返す識別子 | 提供元が該当リクエストを特定する唯一の確実な手がかり |
| 発生時刻（UTC） | リクエスト送信時刻と応答受信時刻（ミリ秒まで） | タイムゾーンの取り違えは往復の原因の定番 |
| モデル名・版 | エイリアスではなく、実際に処理したモデルのスナップショットID | 「最新版」を指すエイリアスは、裏で版が変わる |
| エンドポイント・リージョン | 呼び出し先のURL、リージョン、クラウド経由ならそのサービス名 | 障害がリージョンや経路に限定されることがある |
| 主要なパラメータ | 最大トークン数、温度、ストリーミングの有無、ツール定義の数 | 特定の条件でだけ起きる不具合の切り分け |
| 入出力の規模 | 入力・出力のトークン数、画像やファイルの有無 | 大きな入力でのみ起きるタイムアウトなどの切り分け |
| 結果 | HTTPステータス、エラーコード、エラーレスポンスの本文、応答時間 | エラーメッセージの”要約”ではなく原文が必要 |
| 社内のトレースID | エージェントの実行単位・会話単位のID | 社内ログと提供元の調査結果を突き合わせるため |
MCPサーバーやSaaSのAPIについても同じです。リクエストIDを返さない提供元の場合は、送信時刻・送信元IP・呼び出したツール名・社内で付与した相関IDを組み合わせて、提供元が自社のログを検索できる情報を残しておきます。
保持期間は”提供元の調査が終わるまで”を基準にする
冒頭の例のように、ログのローテーションが早すぎると、ケースを起票した時点で証拠がありません。夜間に起きた障害を翌営業日に起票し、提供元から最初の返信が来るまでに数日かかることもあります。外部呼び出しのメタデータは、少なくとも数週間は保持することを勧めます。プロンプトや応答の本文そのものは個人情報や機密を含みやすいため、本文とメタデータで保持期間を分けるのが現実的です。
LLM特有の”再現しにくさ”に備える
LLMの応答は同じ入力でも毎回変わり得るため、「この入力で必ず再現します」と言えないことが多くあります。そこで、再現手順の代わりに統計的な再現情報を渡します。
- 頻度：「15分間で1,200リクエスト中、約180件がタイムアウト」のように、分母と分子で示す
- 失敗例と成功例の両方：失敗したリクエストIDを複数件と、同じ時間帯に成功したリクエストIDを数件。TACでも、正常時との差分は最も強力な手がかりでした
- 時間帯の境界：いつから始まり、いつ収まったか（収まっていないか）
- 条件の偏り：特定のモデル、リージョン、入力サイズ、ツールの組み合わせに偏っていないか
規律2：サポートケースを標準テンプレートで起票し、追跡する
起票テンプレート
ケースの起票は、障害対応の最中に、疲れた担当者が書くことが多いものです。だからこそ、空欄を埋めれば提供元が調査を始められるテンプレートを用意しておきます。
【件名】
[本番影響あり] 推論APIで断続的なタイムアウト（モデル：xxxx-2026-xx-xx／リージョン：xx）
【1. 問題の要約（1〜2文）】
2026-10-31 17:05 UTC 以降、推論APIへのリクエストの約15%が
60秒でタイムアウトしています。現在も継続中です。
【2. 業務への影響】
- 影響を受けているサービス：顧客向け問い合わせ対応エージェント
- 影響範囲：全顧客の問い合わせ（推定 1時間あたり約3,000件）
- 社内の重大度：Sev2（回避策で一部縮退運転中）
【3. 発生状況（事実のみ）】
- 開始時刻：2026-10-31 17:05 UTC（継続中／終了時刻：—）
- 頻度：17:05〜17:20 UTCの1,200リクエスト中、約180件がタイムアウト
- 条件の偏り：入力8,000トークン以上で発生率が高い。ストリーミング有無に関係なし
- エラー内容：HTTP 504（レスポンス本文の全文を下記に添付）
【4. 識別情報】
- 組織ID／プロジェクトID：xxxx
- 失敗したリクエストID（5件）：req_xxxx, req_xxxx, ...
- 同時間帯に成功したリクエストID（3件）：req_xxxx, ...
【5. こちらで確認・実施済みのこと】
- ステータスページ：17:30 UTC時点で障害情報なし
- 直近24時間の社内の変更作業：なし（変更カレンダー確認済み）
- 回避策：フォールバック用モデルへ切り替え済み。ただし同様の事象が一部発生
【6. お願いしたいこと】
- 提供元側での障害・劣化の有無の確認
- 原因と、恒久対策・回避策の見込み
【7. 連絡先】
- ケース担当：運用チーム（共有アドレス：xxxx@example.com）
- 本番影響が続く間は、電話での連絡も可：xxx-xxxx-xxxx（対応時間：24時間）テンプレートのポイントは4つです。
- 影響を事実と数字で書く：「大変困っています」ではなく、影響を受けている業務、件数、継続時間で書きます。提供元が重大度を判断する根拠になります
- 確認済みのことを書く：提供元が最初に聞く定番の質問（社内で変更はなかったか、ステータスページは見たか）に先回りして答えます
- 1ケース1問題：関係しそうな別の症状を同じケースに書き足すと、調査の担当や優先度が混乱します。別の問題は別のケースにし、互いのケース番号を参照し合います
- 個人ではなく役割で連絡先を書く：担当者の休暇や交代でやり取りが途切れないようにします
提供元に渡す情報は”必要最小限”にする
調査のためにプロンプトや応答の本文を求められることがあります。ここには顧客の個人情報や社内の機密が含まれていることが多いため、渡す前に契約上の取り扱い（データ処理に関する契約など）と社内規程を確認し、可能な限りマスキングするか、合成データで再現した例を渡します。まずリクエストIDとメタデータだけで調査を依頼し、本文が必要と言われた段階で、必要な範囲だけを渡すのが基本です。
起票後のケースを、社内のインシデントとして追跡する
ケースは起票して終わりではありません。次のルールを決めておきます。
- ケース担当を1人決める：インシデントの指揮者とは別に、提供元とのやり取りの窓口を明確にする
- ケース番号をインシデントのチケットに記録する：提供元からの返信、こちらの回答、状態の変化もチケットに転記する
- 更新の間隔を決める：提供元から一定時間連絡がなければ、こちらから状況を確認する
- 回避策の作業は提供元を待たない：RunbookOps編の手順書による回避策と、提供元への問い合わせは並行して進めます。提供元の回答待ちで社内の対応を止めない
- クローズの条件を決める：回避策で直っただけでケースを閉じず、原因の報告（RCA）を求めるかどうかを判断してから閉じる
提供元から原因と回避策の回答が得られたら、ProblemOps編のKEDBに、提供元の不具合番号とケース番号を添えて既知のエラーとして登録します。同じ症状が再発したとき、次の担当者は”ゼロから問い合わせる”必要がなくなります。
規律3：社内の重大度と提供元のサポート区分の対応表を作る
重大度は”翻訳”が必要
社内の重大度（Sev1〜Sev4など）と、提供元が定めるサポートの区分は、名前も定義も一致しません。ネットワーク機器ベンダーのTACでは、重大度を4段階程度に分け、最も高い区分は”本番環境の停止”、次が”深刻な性能劣化や機能の喪失”といった形で定義するのが一般的でした。AIサービスの提供元も、契約プランによって同様の区分を設けていることがあります。一方、従量課金のセルフサーブ契約では、区分そのものがなく、メールでの問い合わせのみという場合もあります。
そこで、提供元ごとに”社内のSev1は、この提供元のどの区分で、どの手段で起票するか”を事前に決めておきます。
| 社内の重大度 | 状況の例 | 提供元の区分（例） | 起票の手段 | 社内での追加アクション |
|---|---|---|---|---|
| Sev1 | 本番のエージェントが停止し、回避策がない | 最高区分（本番停止） | 電話またはポータルの緊急窓口。起票後すぐに電話で確認 | アカウント担当にも並行して連絡。更新は30分〜1時間ごとに確認 |
| Sev2 | 回避策で縮退運転中。影響は継続 | 2番目の区分（深刻な劣化） | ポータルから起票 | 更新は数時間ごとに確認。悪化したら区分の引き上げを依頼 |
| Sev3 | 一部の機能・一部のユーザーに影響 | 3番目の区分 | ポータルから起票 | 営業時間内に追跡 |
| Sev4 | 質問、仕様の確認、機能要望 | 最低区分 | ポータルまたはフォーラム | 定例で確認 |
多くのベンダーでは、最も高い区分のケースはWebフォームではなく電話での起票や、起票後の電話連絡を求めています。夜間にWebフォームから最高区分で起票しても、実際には翌朝まで誰も見ていなかった——ということが起きないよう、提供元ごとの”本当に急ぐときの連絡手段”を台帳に書いておきます。
重大度は誠実に、変化したら更新する
TACの側にいると、すべてのケースを最高区分で起票するお客様には、どうしても慎重にならざるを得ませんでした。重大度は”交渉の道具”ではなく、提供元が限られた人員をどこに振り向けるかを決めるための情報です。重大度は事実に基づいて誠実に付け、状況が悪化したら、その事実を添えて引き上げを依頼する——このほうが、結果的に早く、確実に対応してもらえます。逆に、回避策で影響がなくなったら、こちらから区分の引き下げを申し出ることも信頼につながります。
提供元の区分が合わないときのエスカレーション経路
ケースの進み方に問題があるときのために、エスカレーションの経路も確認しておきます。一般的には、ケースの担当エンジニア → サポートの当番マネージャー（デューティーマネージャー） → アカウント担当（営業、テクニカルアカウントマネージャー）という順です。どの段階で、誰に、どの情報を添えて連絡するかを台帳に書き、エスカレーションは”強い言葉”ではなく”事実の更新”で行うことをチームの共通認識にしておきます。
規律4：提供元のSLAと社内SLOをすり合わせる
SLAを”読める”ようにする
提供元のSLA（サービスレベル契約）は、社内のSLO（サービスレベル目標）を決めるうえで重要な前提ですが、そのまま信じると期待とのずれが生まれます。台帳に記録する際は、次の点を確認します。
- 対象範囲：APIの可用性だけが対象か。応答の遅さ（レイテンシ）や応答の品質は対象外であることが多い
- 測定方法：何をもって”利用不可”とするか（特定のエラーコードのみ、一定時間以上の連続した失敗のみ、など）
- 除外事項：計画メンテナンス、プレビュー版の機能、利用者側の原因、レート制限による拒否など
- 救済の内容：多くの場合はサービスクレジット（利用料金の一部返還）で、業務上の損失を補填するものではない
- 応答時間と解決時間の区別：サポートの目標時間は”初回応答まで”であることが多く、”解決まで”を約束するものではない
セルフサーブの契約では、SLA自体が提示されていないこともあります。その場合は、自社で外形監視（定期的なテストリクエスト）を行い、提供元の実際の可用性と応答時間を自分で測るしかありません。この測定値は、規律6のスコアカードにもそのまま使えます。
依存の掛け算で、社内SLOの上限を知る
エージェントが複数の提供元に直列に依存している場合、エージェント全体の可用性は、各提供元の可用性の掛け算が上限になります。たとえば、推論APIが99.9%、ツールとして呼び出すSaaSが99.5%であれば、両方が必要なエージェントの可用性の上限はおよそ99.4%です。
| 構成 | 依存先の可用性 | エージェント全体の上限（概算） |
|---|---|---|
| 推論APIのみ | 99.9% | 99.9% |
| 推論API ＋ SaaS（直列） | 99.9% × 99.5% | 約99.4% |
| 推論API ＋ SaaS ＋ MCPサーバー（直列） | 99.9% × 99.5% × 99.0% | 約98.4% |
| 推論APIを2系統で冗長化 ＋ SaaS | （1 − 0.001 × 0.001）× 99.5% | 約99.5%（冗長化が独立に機能する前提） |
この計算をせずに「社内SLOは99.9%」と決めると、提供元が自分の約束を守っていても、社内の目標は達成できません。社内SLOを提供元より高く設定するなら、フォールバック先の確保やキャッシュ、縮退運転など、提供元に依存しない手段がセットで必要です。なお、冗長化の効果は、2系統が同時に落ちない（独立している）ことが前提です。同じ提供元の別モデルや、同じクラウドの同じリージョンでは、冒頭の例のように同時に影響を受けることがあります。
エラーバジェットの消費を”提供元起因”で分けて記録する
SLOに対するエラーバジェット（許容できる失敗の量）を管理している場合は、その消費を「社内起因」と「提供元起因」に分けて記録します。提供元起因の消費が大きければ、社内の開発を止めるよりも、冗長化や提供元の見直しに投資すべきだという判断材料になります。
規律5：規約・価格・廃止通知を監視し、変更管理につなぐ
”予告された障害”を見逃さない
提供元に起因する障害のなかには、実は事前に予告されていたものが少なくありません。モデルの廃止日、APIの旧バージョンの提供終了、レート制限の変更、価格改定——こうした通知は、提供元の変更履歴やメールで告知されています。それでも障害になるのは、通知が担当者個人の受信箱に届き、誰も対応しないまま期日を迎えるからです。
| 通知の種類 | 起こり得ること | 主な情報源 |
|---|---|---|
| モデルの廃止・提供終了 | 期日以降、指定したモデルへのリクエストがエラーになる | 提供元の廃止予定一覧、メール通知 |
| APIの仕様変更・旧版の終了 | パラメータやレスポンスの形式が変わり、連携が壊れる | 変更履歴（チェンジログ）、開発者向けのお知らせ |
| レート制限・利用枠の変更 | ピーク時に制限にかかり、エラーが増える | アカウントの管理画面、メール通知 |
| 価格改定 | 同じ使い方でコストが急増する | 料金ページ、メール通知 |
| 利用規約・データの取り扱い方針の変更 | 社内規程や顧客との契約に抵触する可能性が生じる | 規約ページの改定履歴、メール通知 |
| MCPサーバー・SDKの互換性のない更新 | ツール定義や認証方式が変わり、呼び出しが失敗する | リリースノート、リポジトリのリリース |
監視の仕組み
- 受信先を共有アドレスにする：提供元からの通知は、個人ではなくチームの共有アドレスやチャットのチャンネルで受け取ります
- 購読できるものは購読する：ステータスページの通知、変更履歴のフィード、リポジトリのリリース通知などを、同じチャンネルに集めます
- 定期的に”見に行く”：通知が来ない変更（規約ページの改定など）もあるため、台帳の情報源を月に1回は確認します
- 期日を台帳で管理する：モデルの廃止日やAPIの終了日を台帳に記録し、期日の一定期間前にアラートを出します
通知を受けたら、変更作業として起票する
通知を受け取ったら、CMDBで影響を受けるCIを洗い出し、ChangeOps編の変更作業として起票します。モデルの切り替えであれば、評価・切り替え・切り戻しの手順を作業手順書に書き、変更カレンダーに載せます。提供元の変更は、社内の変更プロセスの入口として扱う——これが”予告された障害”を防ぐ最も確実な方法です。
規律6：ベンダースコアカードで提供元の実績を測る
”なんとなく不満”を数字にする
「あの提供元はサポートが遅い」「最近障害が多い気がする」——こうした印象は、数字がなければ改善の話し合いにも、契約の見直しにもつながりません。規律1〜5で記録してきた情報を、提供元ごとのスコアカードにまとめます。
| 指標 | 計算方法・内容 | 何が分かるか |
|---|---|---|
| 提供元起因のインシデント数・影響時間 | 期間内に提供元が原因だったインシデントの件数と合計時間 | 提供元の安定性 |
| 実測の可用性・応答時間 | 外形監視で測った値と、SLAの値の比較 | SLAと実態のずれ |
| 初回応答時間 | ケース起票から提供元の最初の実質的な返信までの時間（区分ごと） | サポートの反応の速さ |
| 解決時間 | ケース起票から原因の特定または回避策の提示までの時間 | サポートの解決力 |
| 情報の再要求回数 | 1ケースあたり、提供元から追加情報を求められた回数 | こちらの起票の質（規律1・2の成果） |
| ステータスページの反映遅延 | 社内で検知した時刻から、ステータスページに障害が掲載されるまでの時間 | 提供元の情報公開の速さ。こちらから知らせる必要性の高さ |
| 通知のリードタイム | 廃止・仕様変更の通知から実施日までの期間 | 変更への備えやすさ |
| 原因報告（RCA）の提供率 | 重大なインシデントのうち、原因の報告を受けられた割合 | 提供元の透明性 |
注目してほしいのが「情報の再要求回数」です。これは提供元の評価であると同時に、自社の起票の質を測る指標でもあります。再要求が多ければ、まず自社のログとテンプレートを見直します。スコアカードは提供元を責めるための道具ではなく、双方の改善点を事実で話し合うための道具です。
定期的にレビューし、提供元と共有する
四半期ごとにスコアカードを見直し、エンタープライズ契約の提供元であれば、アカウント担当との定例の場で共有します。「この四半期、ステータスページの掲載が社内検知から平均で40分遅れていた」といった事実を示せば、提供元も改善の優先度を判断しやすくなります。契約の更新時期には、スコアカードが提供元の継続・切り替え・冗長化の判断材料になります。
提供元の種類ごとの違い
一口に”提供元”といっても、契約の形によって期待できることは大きく違います。台帳では、提供元を次のように分類しておくと、障害時の動き方が決めやすくなります。
| 区分 | 例 | 主な窓口 | 期待できること・注意点 |
|---|---|---|---|
| エンタープライズ契約 | LLM提供元の法人向けプラン、SaaSの上位プラン | サポートポータル、電話、アカウント担当 | 重大度区分と応答目標がある。RCAを依頼できることが多い |
| クラウド事業者経由 | クラウドのマネージドサービス経由で利用するモデル | クラウド事業者のサポート | 一次窓口はクラウド事業者。サポート契約のプランで応答目標が変わる |
| セルフサーブ（従量課金） | 個人・小規模向けのAPI利用 | ヘルプセンター、メール | 応答目標がないことも多い。外形監視と冗長化で自衛する |
| OSS・コミュニティ | オープンソースのMCPサーバー、ライブラリ | リポジトリのIssue | 保証はない。版の固定、フォーク、自前での修正、代替への切り替えを自社で判断する |
特にOSSのMCPサーバーは、手軽に導入できる反面、障害時に”聞く相手”がいません。本番の業務で使う場合は、版を固定し、変更内容を確認してから更新し、メンテナンスが止まった場合の代替手段を決めておくことが、そのままベンダー管理になります。
運用サイクル——いつ、何を見るか
| 頻度 | やること | 担当 |
|---|---|---|
| 障害のたび | テンプレートでの起票、ケースの追跡、KEDBへの登録、RCAの依頼判断 | ケース担当 |
| 通知のたび | 影響を受けるCIの洗い出しと、変更作業としての起票 | 運用チーム |
| 毎月 | 台帳の情報源の確認、廃止期日の確認、起票できる人の権限の確認 | 運用チーム |
| 四半期ごと | スコアカードのレビュー、提供元との定例、SLAと社内SLOの見直し | 運用リーダー |
| 契約更新時 | スコアカードに基づく継続・切り替え・冗長化の判断 | 運用リーダー・調達・情報システム部門 |
よくある落とし穴
- リクエストIDを記録していない：最も多く、最も簡単に防げる失敗です。外部呼び出しのラッパーで一律に記録するようにします
- エラーメッセージを”要約”して渡す：「タイムアウトしています」ではなく、エラーレスポンスの原文を渡します
- タイムゾーンを書かない：「2時ごろ」が日本時間なのかUTCなのかで、提供元の調査対象は9時間ずれます
- サポートポータルの権限が1人に集中している：その人が不在のときに起票できません。役割で管理し、最低2名に権限を持たせます
- ステータスページが”正常”だから起票しない：提供元がまだ気づいていないだけかもしれません。こちらの報告が、提供元の障害検知のきっかけになることもあります
- 提供元の回答を待って社内の対応を止める：回避策の実行と提供元への問い合わせは、必ず並行で進めます
- 回避策で直ったらケースを閉じてしまう：原因が分からないままでは、同じ障害が再発します。RCAを求めるか、KEDBに”原因不明”として残すかを判断します
ベンダー管理（VendorOps）チェックリスト
| 領域 | 確認項目 |
|---|---|
| 台帳 | 提供元ごとに、契約・窓口・起票できる人・サポート区分・SLA・情報源が1か所にまとまっているか |
| 台帳 | CMDBのCIと提供元がひもづいているか |
| 証拠 | すべての外部呼び出しで、リクエストID・UTC時刻・モデルの版・エラーの原文が記録されているか |
| 証拠 | 外部呼び出しのメタデータを、提供元の調査に間に合う期間保持しているか |
| 起票 | 影響・事実・確認済み事項・識別情報を含む起票テンプレートがあるか |
| 起票 | 提供元に渡す情報のマスキングと、契約上の取り扱いの確認手順があるか |
| 追跡 | ケース担当、更新の間隔、ケース番号のチケットへの記録が決まっているか |
| 重大度 | 社内の重大度と提供元の区分・起票手段の対応表が、提供元ごとにあるか |
| 重大度 | エスカレーションの経路（当番マネージャー、アカウント担当）が確認されているか |
| SLA/SLO | SLAの対象範囲・除外事項・救済内容を把握し、依存の掛け算で社内SLOの上限を確認したか |
| 通知 | 提供元からの通知を共有アドレス・共有チャンネルで受け取っているか |
| 通知 | 廃止期日を台帳で管理し、通知を変更作業として起票しているか |
| 測定 | スコアカード（インシデント数、初回応答時間、再要求回数など）を四半期ごとに見直しているか |
よくある質問（Q&A）
Q1. 小さな会社で、提供元と特別なサポート契約を結んでいません。それでもベンダー管理は必要ですか？
むしろ必要です。サポート契約がなければ、提供元の応答に期待できる部分が小さいぶん、自社で備えるしかありません。まずはリクエストIDの記録（規律1）、通知の共有アドレスでの受信（規律5）、外形監視による実測（規律4・6）の3つから始めてください。いずれも大きな費用はかからず、問い合わせる場合も、情報がそろっていればメールでのやり取りでも解決が早くなります。
Q2. ステータスページに障害が出ていなくても、提供元に問い合わせるべきですか？
はい。ステータスページの更新は、提供元が障害を確認し、公表を判断してから行われるため、実際の発生よりも遅れるのが普通です。特定のリージョンや特定の条件でだけ起きる劣化は、提供元がまだ気づいていないこともあります。リクエストIDと頻度を添えて早めに起票すれば、提供元の調査のきっかけになり、結果的に自社の復旧も早まります。
Q3. 調査のためにプロンプトや顧客のデータを提供元に渡してもよいのでしょうか？
渡す前に、提供元とのデータの取り扱いに関する契約、自社のプライバシーポリシー、顧客との契約を確認してください。基本は、まずリクエストIDとメタデータだけで調査を依頼し、本文が必要になった段階で、マスキングした本文や合成データで再現した例を渡すことです。判断に迷う場合は、法務や個人情報保護の担当者に相談することを勧めます。
Q4. OSSのMCPサーバーで障害が起きた場合は、どうすればよいですか？
リポジトリのIssueで報告するのが基本ですが、回答や修正の期限は保証されません。障害時は、まず固定している版への切り戻しや、そのツールの一時的な無効化（RunbookOps編の手順書）で業務への影響を止めます。そのうえで、Issueへの報告、自社での修正（必要ならフォーク）、商用の代替製品への切り替えのどれを選ぶかを判断します。本番で使い続けるなら、メンテナンスの状況を定期的に確認し、台帳に”保証なし”と明記しておくことが重要です。
Q5. 提供元の対応が遅いと感じたとき、どうエスカレーションすればよいですか？
まず、ケースの重大度が実際の影響に合っているかを確認し、合っていなければ、影響の事実を添えて区分の引き上げを依頼します。それでも進まない場合は、サポートの当番マネージャーへのエスカレーションを依頼し、エンタープライズ契約であればアカウント担当にも状況を共有します。いずれの段階でも、感情的な表現ではなく、「影響を受けている件数」「継続時間」「これまでのやり取りの経緯」という事実を示すことが、最も効果的なエスカレーションです。
まとめ——”提供元待ち”を、運用で短くする
AIエージェントの障害の原因が社外にあるとき、最後に頼れるのは提供元です。しかし、提供元が調査を始められるかどうか、どれだけ早く解決に向かうかは、問い合わせる側の準備で大きく変わります。
1. 聞ける準備をする。 リクエストID、UTC時刻、モデルの版、エラーの原文を、障害が起きる前から記録し、提供元の調査に間に合う期間保持します。これがAIエージェントの”show tech”です。
2. 正しく伝え、追いかける。 起票テンプレートで影響を事実と数字で伝え、社内の重大度を提供元の区分に翻訳します。起票後もケース担当を決めて追跡し、回避策は提供元を待たずに進めます。
3. 先回りし、測る。 SLAと社内SLOをすり合わせ、廃止や仕様変更の通知を変更管理の入口にし、スコアカードで提供元と自社の双方の改善点を事実で話し合います。
提供元は、障害対応の”外側”にいる存在ではありません。依存している以上、提供元とのやり取りも運用の一部です。“提供元に聞くしかない障害”で手が止まらないように、聞く準備を運用規律にしておく——それが、社外に依存するAIエージェントを安定して運用するための最後のピースです。
参考リンク
- Google SRE Book: Service Level Objectives
- Google SRE Book: Embracing Risk
- Google SRE Workbook: Implementing SLOs
- Anthropic API Docs: Errors（リクエストIDについての記載を含む）
- OpenAI Platform: Deprecations
- Model Context Protocol（公式サイト）
関連記事
- 【AgentOps・ランブック運用（RunbookOps）編】”手順書はあるのに、夜中に誰も使えない”をなくす
- 【AgentOps・イベント管理（EventOps）編】”アラートが100件鳴って、原因は1つ”をなくす
- 【AgentOps・構成管理（CMDB）編】依存関係の地図と影響範囲分析
- 【AgentOps・問題管理（ProblemOps）編】再発分析と既知のエラー管理
- 【AgentOps・変更管理（ChangeOps）編】変更カレンダー・MOP・切り戻し
- 【AgentOps・HumanOps編】承認キューとエスカレーション
免責事項
本記事は、AIエージェントの運用における提供元（ベンダー）とのやり取りと管理の一般的な考え方を整理したものであり、特定の製品・サービスのサポート内容、SLA、動作を保証するものではありません。各提供元のサポート区分、SLA、データの取り扱いは契約やプランによって異なります。実際の運用にあたっては、ご自身の契約内容、利用するサービスの最新のドキュメント、社内の規程を必ずご確認ください。
コメント