外部APIの提供終了に備える。通知を読める人と移行予算を決める

外部APIの提供終了では、責任分担を決めます。通知の主担当と代替担当、影響調査、顧客調整、予算・切替の決裁者を置きます。通知が開発担当者の受信箱で止まれば、経営は期限も顧客影響も把握できません。

僕なら、一つの案件台帳を作り、受信、技術調査、顧客調整、経営判断の順に責任を渡します。各段階に担当を置けば、通知の受信から切替までを一人が抱える事態も避けられます。経営者はAPIの細部を追う代わりに、「何が確認済みなら予算を付け、切替を承認するか」を先に決めます。

切替の判断材料がそろうのは、提供者が代替先を示した時点より後です。自社の重要機能、連携方法、顧客への説明まで、誰がどこまで確かめればよいのでしょうか。責任の受け渡しが見える条件付きの例で考えます。

外部APIの提供終了への対応は、通知を読む責任から始める

変更通知の宛先と、社内で判断できる人は別々になりがちです。契約やクラウドのアカウントを作った人はメールを受け取れても、対象機能や顧客への影響まで判断できるとは限りません。担当者個人の注意力に頼らず、通知を社内案件へ変える仕組みとして扱うべきです。

製品固有の例を見ると、通知経路が一つではないことが分かります。Microsoft Foundry Models lifecycle and support policyでは、GAモデルの終了通知は稼働中のデプロイがあるサブスクリプション所有者へメールで送られます。Azure Service Healthには影響を受けるサブスクリプションへの勧告が表示され、メール、テキストメッセージ、Webhookのアラートも設定できます。Models APIではライフサイクル状態と非推奨日を確認できます。2026年9月21日時点のMicrosoft Foundry固有の仕様で、適用範囲は同製品に限られます。

この仕様を実務へ移すなら、ベンダーアカウントの名義人とは別に、通知を読む主担当、代替担当、定期確認する公式画面またはAPIを社内台帳に定めます。複数の通知経路を社内の責任へ接続するために僕が提案する方法です。Microsoftが定めた義務や分類とは区別してください。

主担当は原文を保存し、対象サービス、終了時期、提供者が示す代替候補、社内の技術調査担当を一つの案件として登録します。移行案の作成は技術調査担当へ渡します。代替担当には休暇や退職への備えに加え、通知が案件化されたかを相互に確認する役割を持たせます。ここまで定めれば、届いたメールが放置される空白を減らせます。

責任者の名前が決まっても、経営会議へ上げる条件がなければ台帳は通知一覧で止まります。終了時期が記載された、利用中の対象が見つかった、代替候補の確認が必要になった場合のいずれかで技術調査へ渡す、といった社内条件まで決めておくことが重要です。条件を経営の言葉へ直す役割が空いているなら、経営と技術をつなぐ人がいないと、会議は決まらないで整理した「論点の前処理」と同じ問題が起きています。

影響調査は、API呼び出しの外側まで見る

サービス名と終了時期の二項では、技術調査の範囲が狭くなります。外部APIとの接点には、サーバーから送るリクエストに加え、ブラウザ側のライブラリ、Webhook、提供者側で動く自動処理があり、いずれにも変更が波及し得ます。

StripeのAPI upgradesによると、アカウントのAPIバージョン更新は、バージョンヘッダーのないAPI呼び出しに加え、Stripe.jsが返すオブジェクト、Webhookエンドポイントへ送られるオブジェクト、アカウントの既定バージョンを使う自動課金処理にも影響し得ます。一方、明示的なバージョンを設定したWebhookエンドポイントには、そのバージョンが使われます。2026年9月21日時点のStripe固有の影響範囲で、適用範囲は同製品に限られます。

この例は、調査の問いへ変換して使います。受信担当から技術調査担当へ渡すときは、外向きAPI呼び出し、ブラウザ側ライブラリ、Webhook、提供者側の自動処理、顧客別の利用経路のうち、自社に何があるかを確認対象にします。Stripeの影響範囲を手掛かりに僕が組み立てた実務上の観点です。同社所定の分類や全社共通の義務とは区別してください。

顧客別の利用経路を含めると、技術的に動くかどうかと、顧客へ変更を説明する必要があるかどうかを分けられます。自社内部で完結する切替と、顧客の設定変更や確認が関わる切替では、経営が用意すべき判断が異なります。技術調査担当から顧客調整担当へ、「調整が必要」「現時点では不明」のどちらかを返し、顧客対応は後者が引き取ります。

一つの案件台帳で、顧客調整と移行予算までつなぐ

台帳の役割は、次の担当者が動ける状態を作ることです。通知原文と技術メモが別々に保存され、顧客担当は口頭で聞き、経営者には見積もりだけが届くという分断があると、予算を出すべきか、調査を続けるべきかを判断できません。

僕なら、一つの終了案件に次の項目を持たせます。下記の公式資料が示す確認事項を土台にした僕の実務案で、各社所定の書式とは別のものです。

台帳から、誰が次の空欄を埋めるかまで読み取れることが大切です。未確定事項が残っていても、担当者と、何が分かれば判断できるかが明記されていれば保留を管理できます。

たとえば、提供終了の通知に代替モデルが記載され、自社ではそのモデルを顧客向け機能に利用しているとします。技術調査担当は自社の重要機能と代表データで候補を確かめ、APIの互換性や利用条件を台帳へ戻します。顧客調整担当は、顧客側の設定変更や説明が要るかを確認します。経営者は、確認作業と切替作業を誰が担うか、既存の開発予定とどちらを優先するかを決め、そのための移行予算を承認します。金額を仮置きしなくても、予算を付ける対象と決裁条件は具体化できます。

この流れの根拠となる公式仕様も、製品ごとに限定して読む必要があります。Google CloudのModel versions and lifecycleは、対象モデルのリリース日、終了日、代替モデルを表で示し、掲載済みの終了時期は延長される可能性がある一方、掲載日より早まることはないとしています。また、終了によるエラーへ急いで対応する手順として、推奨される代替先へアプリケーションを変更し、ミッションクリティカルな全機能をテストし、通常の方法で更新をデプロイするよう案内しています。2026年9月21日時点で同ページに掲載される対象モデルについての仕様と手順です。

Microsoftも前掲資料で、代替モデルを自社のアプリケーション、プロンプト、代表データで評価し、移行前にAPI互換性、機能対応、デプロイ種別とリージョンの可用性、容量、クォータを確認するよう案内しています。2026年9月21日時点のMicrosoft Foundryモデルに対する移行条件です。Google CloudとMicrosoftの資料を合わせて読むと、終了時期、代替候補、自社の重要機能、代表データ、互換性、利用条件の確認結果を経営判断へつなぐ台帳を設計できます。台帳自体は、両社の所定書式と区別した僕の実務提案です。

台帳の更新担当と決裁者は、技術部門と経営の間で決める必要があります。CTO代行を入れると、組織の意思決定はどう変わるのかで扱うように、技術情報を決裁可能な論点へ変える役割を社内外のどこに置くかも、同時に決めてください。

切替判断は、代替先の有無より確認条件で行う

代替先が公表されると、移行方針まで決まったように見えます。しかし、公表された候補にも自社での確認は必要です。経営者は「推奨先へ変えます」という報告を受け取ったら、確認済みの項目と、受け入れて切り替える未確定事項を尋ねます。

Stripeは前掲の公式資料で、コード上で連携対象のAPIバージョンを明示し、新しいバージョンを試すときはテスト環境または本番環境のAPI呼び出しでStripe-Versionヘッダーを設定する方法を案内しています。そして、コードが新バージョンを処理できると確信してからWorkbenchで更新する手順を示しています。2026年9月21日時点のStripe固有の切替手順です。

Google Cloudは重要機能のテスト後に通常の方法で更新をデプロイするよう案内し、Microsoftは自社の代表データによる評価と互換性、機能、可用性などの確認を挙げています。各資料を根拠に、僕なら切替の社内条件を、自社の代表データと重要機能での確認、連携面の互換性、利用条件、顧客への変更説明、実施手順がそろった状態と定めます。各社資料の原則を経営判断へ移し、原典所定の共通分類や義務と区別した実務案です。

未確定事項は、その内容、確認する担当、切替前に解消するのか経営判断で受け入れるのかを台帳へ残します。全項目の確定を待たず、経営者は顧客への影響、既存の開発予定、確認と切替に必要な仕事を並べ、どこへ人と予算を割くかを決めます。技術的な正解の選定は、技術調査担当が担う領域です。

外部APIの提供終了への対応を自社で実行できる条件は明快です。通知を読む主担当と代替担当が決まり、技術調査がAPI呼び出し以外の接点と顧客別経路まで確認し、顧客調整の要否が経営へ届き、切替の確認条件と責任者が一つの案件台帳でつながっていることです。その台帳を見ても次に動く人が分からないなら、移行先の比較より先に責任の空欄を埋めてください。四段階の受け渡しが見えれば、移行予算を「終了期限までに何を確認し、誰が切り替えるための費用か」という形で説明できます。