- 公開日
外部連携の変更監視では、利用中の接続先と業務を結ぶ一覧を用意し、公式通知を影響のある利用箇所へ対応付けます。そのうえで、移行を引き取る担当、代替手段、試験、切替期限、間に合わない場合の停止方法を決めます。通知の受領は対応の開始であり、移行完了は実際の利用先と業務結果を確認して判定します。
監視する単位を、サービス名から利用箇所へ絞る
「文書サービスを使っている」という記録だけでは、どの廃止通知が自社に関係するかを決められません。モデルやサービスの名称に加え、利用しているAPI、版、認証方式、接続アカウント、コネクタやSDKなどの仲介部分を記録します。SDKはAPIを呼び出すためのライブラリです。自社コードが直接呼ぶ場合と、コネクタの内部で呼ばれる場合では、変更を確認する相手も異なります。
記録の対象は、本番で毎日動く処理だけではありません。月次の集計、障害時だけ使う代替経路、担当者の手動実行も含めて、利用部署に確認します。短期間のアクセス記録に出てこない連携を、未使用と即断しないためです。MCPサーバーのように接続先そのものが信頼境界になる連携の評価は「MCPサーバーを信頼境界として評価する」、MCPサーバーの更新で挙動が変わった場合の確認と復帰は「MCPサーバー更新の互換性を確かめ検証済み構成へ戻す」で扱っています。
依存一覧には、少なくとも次を結びます。ここで示す項目は運用の設計案であり、全サービス共通の必須様式ではありません。
| 確認する対象 | 一覧に残す内容 |
|---|---|
| 接続先 | 提供者、API・機能名、利用版、環境、接続先の識別情報 |
| 利用箇所 | 呼び出すアプリ・処理、利用部署、上流の入力と下流の出力先 |
| 渡す情報と権限 | 情報の種類、利用主体、読取り・更新の範囲、保持条件の確認先 |
| 変更の入口 | 公式廃止一覧、変更履歴、対象アカウントの通知、契約上の連絡先 |
| 対応責任 | 通知を確認する担当、改修担当、業務の受入担当、代理担当 |
接続先の識別に必要なのは、秘密鍵の本文ではありません。認証情報は所定の管理先へ置き、台帳には参照先や管理担当を記します。誰がどの業務で使うかを追えれば、通知の宛先になっている一人が不在でも対応を引き継げます。
公式通知を、具体的な変更案件へ変える
提供者の公式廃止一覧や変更履歴に加え、利用アカウントに届く通知を確認します。アカウント別の適用日や地域・プランの条件がある場合は、一般向けの発表と照合します。サービスの稼働状況ページが正常でも、将来の廃止や互換性の変更がないことの証明にはなりません。
実例として、OpenAI APIのDeprecationsでは、廃止予定の通知と停止日、推奨移行先が掲載され、電子メールと公式文書による案内を説明しています。また、廃止予定として案内されるdeprecated、アクセスできなくなるshutdown、更新が行われないlegacyを区別しています。この用語と通知方針は同サービスの説明であり、他の提供者へ同じ期限や意味を当てはめません。
通知を受けたら、原文のURLまたは許可された保存先、通知日、確認日、変更対象、適用条件、停止日時と時間帯を残します。「来月末」のような表現なら、元通知の日付から確定できるかを調べ、不明なまま社内締切を作りません。通常の予告期間があるサービスでも例外はあり得るため、長い猶予を前提にせず、当該通知を確認します。
変更案件には「確認済み」「影響調査中」「移行準備中」「試験待ち」「切替確認中」「完了」などの状態を設けます。「影響なし」とするなら、使っている版や機能が対象外である根拠と確認者を残します。利用版が不明なら、影響なしではなく調査が残っている状態です。
架空の廃止通知を、文書検索業務へ対応付ける
以下は架空の文書検索APIの例です。提供者、仕様、日付、担当の分担は説明用の仮定であり、実際の通知や移行試験の結果ではありません。
A社は、問い合わせ担当者が社内マニュアルを探す「文書案内アプリ」から、連携アダプターを経由して文書検索APIのv1を呼び出しています。送るのは質問文と部署識別子です。許可された部署の文書だけを読み取り、回答案と出典を担当者に返します。顧客への送信や文書更新は、この連携の範囲に含めません。
提供者から、次の通知を受けたと仮定します。
「通知日：2026年11月2日。文書検索API v1は2027年1月31日18時、日本時間で停止します。移行候補はv2です。v2では本文を返す項目名と、文書の参照権限を指定する方法が変わります。」
この通知を、依存一覧の「文書案内アプリ→連携アダプター→検索API v1」へ結びます。業務への影響は、呼出しが止まることだけではありません。項目の読取りを直さなければ本文が空になり、認可の対応を誤れば許されない部署の文書が返る可能性があります。通知にない変更を推測で確定せず、新旧の仕様と契約・設定を照合する項目にします。
| 受け渡し | 渡す内容 | 受け手が返す判断 |
|---|---|---|
| 運用担当→開発担当 | 通知原文、利用中のv1と呼出箇所、停止日時 | 対象機能の有無、変更差分、未確認箇所、改修見通し |
| 開発担当→情報管理担当 | v2の送信項目、接続先、権限、保持条件の差分 | 許可される構成、追加確認、採用を保留する条件 |
| 開発担当→業務の受入担当 | 試験版、期待出力、正常・拒否・停止の記録 | 検索業務として使えるか、残る不具合、切替可否 |
| 受入担当→運用担当 | 承認した構成、切替範囲、復帰条件 | 切替実施の記録と、旧経路が残っていない確認 |
運用担当は、開発側の試験記録と業務側の受入判断を受け取ってから、切替を進める状態へ更新します。担当者名だけでなく、未回答時に引き継ぐ代理担当も置きます。
代替候補では、データと権限を引き継げるか確かめる
公式の推奨移行先があっても、自社の業務と同じ条件で使えるとは限りません。本例では、質問文と部署識別子をv2へ送ってよいか、部署ごとの参照範囲を表現できるか、引用先が利用者に開けるかを確認します。別の提供者へ移すなら、送信先や情報の保持条件も改めて確認します。
旧APIの認証情報を新しい接続先へそのままコピーしたり、エラーを解消するために広い権限を与えたりすることを、移行手順の前提にしません。OWASPのLLM06:2025 Excessive Agencyは、必要な機能・権限に絞り、下流で認可を確認することを勧めています。本例でも、読取り専用という範囲と部署の境界を維持できることを移行条件にします。
v2が要件を満たさない、または必要な確認が期限に間に合わない場合は、別候補の評価や手作業への切替を選びます。例えば、担当者が許可されたマニュアルを直接開き、AIによる検索回答の提供を一時停止する方法です。この代替には検索の手間が増えるため、対象業務と利用者への案内を業務責任者が決めます。
正常・拒否・停止を試し、期限までの判断を分ける
移行試験は、本番文書や顧客への送信を使わず、権限区分を持つ架空の文書と試験環境で行う設計にします。通常の質問には、許可された文書の本文と出典が返り、利用者が出典を開けることを確かめます。項目名の変更後も、空の本文を正常回答として扱わないことが必要です。
権限不足の試験では、他部署の試験文書を取得しようとした要求が拒否され、本文が返らないことを確認します。認可エラーを「該当文書なし」に置き換えて回答を続けないことも見ます。権限設定が確認できなければ、その経路での回答を保留し、管理者の確認へ回します。
停止の試験では、v1が利用できない状態を模擬し、許可を確認していない別サービスへ自動転送しないこと、古い回答を最新として返さないこと、利用者に利用不可と確認先を伝えられることを確かめます。これは試験計画であり、ここで実行済みの合格を報告しているわけではありません。
本例の社内日程は、2027年1月15日に試験結果を受け入れるか判断し、1月22日に切替、1月29日までに旧経路の呼出しが残っていないか確認する、と仮定します。提供者の停止日は1月31日18時です。社内の各日程にも時刻と担当を設定し、不具合の修正と再確認に必要な余裕が足りるかを見積もります。試験が未完なら社内の切替を延期しても、提供者の停止期限は残ります。期限までに確認を終えられない場合は、手作業などの代替を使う判断を先に行います。
旧APIへ戻す案が使えるのは、旧APIが利用可能で、戻してよい条件を満たす間だけです。停止後にも戻せる前提で切替を進めません。提供者が停止日を変更した場合は、影響調査の記録と社内日程も更新し、受入担当へ判断を戻します。
通知から実際の切替まで、記録で閉じる
完了には、移行先での業務確認に加え、アプリ設定、定期処理、障害時の経路、利用部署の手動手順から旧接続が外れたことを確認します。一度呼出しに成功しただけでは、月次処理や代替経路まで移ったとは言えません。実行記録と設定一覧、利用部署の確認を組み合わせ、未確認の経路は残件として扱います。
監視頻度は、停止までの余裕、重要度、実際の変更頻度に応じて決めます。通知の転送設定だけで安心せず、受領から担当割当てまで届くか、担当不在や通知先変更で止まっていないかを確認します。未処理の案件には、期限と次に判断する担当を残します。監視の記録は、通知が届いた証拠だけでなく、利用中の接続をいつ、誰の確認で切り替えたかまで追える形にします。
外部ツールの仕様変更後にプロンプトを再評価する手順は「外部ツール仕様変更後にプロンプトを再評価する」、LLMを複数ベンダーへ切り替えるための抽象化層の作り方は「LLMを複数ベンダーへ切り替える抽象化層の作り方」で解説しています。
