AIのAPI提供終了に備える｜廃止予定の調べ方と棚卸し手順

「ある朝、動いていたはずの自動処理が止まっていた」「原因を調べたら、使っていたAIのAPIが提供終了していた」——外部のAIサービスに業務を預けている人ほど、この不安は他人事ではありません。

結論から言うと、AIの提供終了はほぼ例外なく数ヶ月前に公開の場所で予告されています。差がつくのは情報の有無ではなく、その予告を見に行く工程を持っているかどうかだけです。

株式会社Fyveは、外部のAIサービスを複数またぐ処理を毎日無人で動かしています。この記事では、実際に自分の運用が影響を受けた経験をもとに、使っているAIの「止まる日」を1枚に集める手順をお伝えします。

10日間で、3つのAPIが相次いで止まる

2026年8月、別々の会社の、別々のサービスが、10日間のうちに3つ止まります。まずは事実だけを整理します。

8月17日｜Google「Imagen 4」の3エンドポイント

Googleの画像生成モデル Imagen 4 のうち、imagen-4.0-generate-001、imagen-4.0-fast-generate-001、imagen-4.0-ultra-generate-001 の3つが2026年8月17日に停止しました。公式ドキュメントには「The Imagen 4 standard, ultra, and fast endpoints are deprecated and will be shut down on August 17, 2026」と明記されています（Gemini API 公式ドキュメント）。

この予告は2026年6月15日のリリースノートに載っていました（Gemini API リリースノート）。予告から停止まで約2ヶ月です。

移行先は Gemini 3.1 Flash Image と案内されていますが、注意が必要なのはモデル名を差し替えるだけでは済まないケースがある点です。呼び出しに使うメソッドの体系ごと変わるため、「モデルIDの文字列を書き換えれば動く」という前提で見積もると足りません。

8月18日（本日）｜Google「Content API for Shopping」

Googleの公式移行ガイドは、Content API for Shopping の終了日を「August 18, 2026」と明記しています（Content API for Shopping 移行ガイド）。後継は Merchant API です。

これはECを運営している事業者に直接効きます。商品データをGoogleマーチャントセンターへ送る経路がこのAPIだからです。移行しないまま呼び出しを続けた場合、v2.1のエンドポイントは HTTP 410 Gone を返すようになると、複数の実装者向け解説が一致して伝えています。

そして、Googleは延長申請のフォームを公式に用意しています。移行ガイドには「Need additional time to migrate? Request an extension using the Content API for Shopping extension request form.」という案内があります。間に合わなかった場合に打つ手がゼロではない、という点は知っておく価値があります（延長される具体的な期日は申請フォーム側の案内で確認してください）。

8月26日｜OpenAI「Assistants API」

OpenAIの廃止一覧には、Assistants API の停止日が「2026-08-26」と記載されています（OpenAI Deprecations）。/v1/assistants 系のエンドポイントが使えなくなり、移行先は Responses API と Conversations API です。

この3つのうち、私がもっとも危ないと考えているのはこれです。理由は次のセクションで説明します。

怖いのは「消える」ことではなく「固まる」こと

APIが止まると聞くと、多くの人はサービスがエラー画面になる姿を想像します。実際にはそうならないことのほうが多く、そちらのほうが厄介です。

Content API for Shopping を例にとります。このAPIが止まって困るのは「Google上の商品表示が消える」ことではありません。止まるのは「更新」です。すでに登録されている商品データはそのまま残り、価格も在庫も、最後に同期できた時点のまま固まります。

つまり、売り切れた商品が「在庫あり」のまま出続け、値上げしたはずの商品が旧価格のまま表示される。見た目は完全に正常で、注文も入ります。壊れていないように見えるまま、中身だけが古くなる——これが実害の出方です。

エラーで落ちてくれるトラブルは、まだ親切なほうです。誰かが気づいて対応が始まるからです。本当に怖いのは、動いているように見えて中身が更新されていない状態が、誰にも検知されないまま続くことです。

「うちは使っていない」と思っている人ほど当事者になりやすい

ここまで読んで「自分はAPIなんて直接使っていない」と感じた方こそ、確認する価値があります。

作ってもらった仕組みの中身は、頼んだ本人が知らない

8月26日に停止する OpenAI の Assistants API は、2024年から2025年にかけて「ChatGPTを使った仕組み」を外部に発注した場合、その内部で使われている可能性が現実的にあります。当時、社内向けのチャットボットや問い合わせ応答の仕組みを作る標準的な選択肢の1つがこのAPIだったからです。

問題は、発注した本人はAPIの名前を知らないという点です。知っているのは作った人だけで、その人との契約はもう終わっているかもしれません。「何が使われているか分からないものが、事業の一部として動いている」——これが、外注でAIを導入した場合に生まれる典型的な死角です。

手順書の粒度や検品の設計については、こちらの記事でも扱っています。

AI業務効率化AIに任せる手順書の書き方｜検品を工程に埋め込む

私の場合も、他人事ではありませんでした

私は毎日、外部のAIサービスを複数またぐ処理を無人で動かしています。記事の下書き生成、図版の作成、公開前の点検までを機械に任せる構成です。

今回停止した Imagen 4 は、まさにその画像生成のフォールバック経路に関わる場所でした。主経路が失敗したときにGoogleの画像生成へ切り替える設計にしていたため、「普段は使っていないが、まさかのときに使う」という一番気づきにくい位置に外部依存が埋まっていたことになります。

普段動いている経路の障害はすぐ気づきます。しかし予備の経路が死んでいることには、本番で必要になるまで気づけません。棚卸しをするときは、主経路だけでなく予備の経路も同じ列に並べる必要があります。

3件とも、何ヶ月も前から公開の場所で予告されていた

ここまで不安を煽るような書き方になりましたが、この記事の主張は「AIは危ないから使うな」ではありません。むしろ逆です。

3件とも、事前に公開の場所で予告されていました。Imagen 4 は2ヶ月前のリリースノート、Content API for Shopping は Merchant API を後継として案内する形で段階的に、Assistants API は Responses API の公開時点から移行方針が示されていました。

予告期間はベンダーによって違う

実際にOpenAIの廃止一覧を読むと、来年1月分まで日付が並んでいます。

この表から読み取れることが1つあります。OpenAIの予告期間はおおむね6ヶ月で揃っているのに対し、Googleの Imagen 4 は約2ヶ月でした。

つまり「予告があるから大丈夫」ではなく、提供元によって猶予の長さが2倍から3倍違うと考えておくべきです。半年あるつもりで構えていると、2ヶ月しかないベンダーで足をすくわれます。棚卸しのときは、依存先ごとに猶予の相場が違う前提で優先順位を付けてください。

差がつくのは「見に行く工程」があるかどうか

予告は公開されていた。移行先も用意されていた。延長申請の窓口まであった。それでも当日に止まって慌てる人がいます。

この差は、情報を持っているかどうかではありません。情報を取りに行く工程が、自分の仕事の中に組み込まれているかどうかです。

AIに関するニュースは毎日大量に流れてきます。ただし流れてくるのは「新しいモデルが出た」「新機能が追加された」という増える話ばかりです。事業を止めるのは減るほうで、減る話はニュースになりません。廃止予定ページという地味な場所に、静かに載るだけです。

だから、こちらから見に行く工程を作る必要があります。以下がその手順です。

AIの「止まる日」を1枚にまとめる5つの手順

手順1｜事業に繋がっている外部サービスを全部書き出す

まず、自分の事業が動くために必要な外部サービスを、思いつく限り書き出します。ここで重要なのは、次の3種類をすべて同じ紙に並べることです。

• 自分で契約したもの——ChatGPT、各種AIのAPI、クラウド、決済、メール配信など
• 過去に誰かに作ってもらったもの——外注した仕組みの中で使われているサービス。分からなければ、作った相手に「何を使っているか」を聞く。それができないなら請求書と設定画面から辿る
• 予備として置いているもの——普段は動かないフォールバック経路。前述のとおり、ここが一番気づけない

網羅性より、まず全部出すことを優先してください。後から足せます。

手順2｜提供元の「廃止予定」ページを探して日付を集める

主要な提供元は、廃止予定を一覧で公開しています。ブックマークしておくべきページは次のとおりです。

それ以外のサービスは「サービス名 + deprecation」または「サービス名 + 提供終了」で検索すれば、たいてい公式の告知ページに辿り着きます。見つからない場合は、そのサービスが廃止予定を公開していないということなので、それ自体をリスクとして記録しておきます。

手順3｜日付の横に「止まったら何が止まるか」を書く

ここがこの作業の本体です。そして、ほとんどの人が飛ばす工程でもあります。

「Assistants APIが8月26日に停止」とだけ書いたシートは、実際には機能しません。読んでも動けないからです。書くべきなのは、その隣の列です。

• ×「Content API for Shopping が停止する」→ 何をすればいいか判断できない
• ○「商品の価格と在庫がGoogleに反映されなくなる。古い価格のまま注文が入る」→ 緊急度が即座に分かる

技術の言葉を、業務の言葉に翻訳する。この1列があるかどうかで、シートが「読まれる資料」になるか「作っただけの資料」になるかが決まります。経営判断をする人がAPIの名前を知る必要はありませんが、何が止まるかは知っている必要があります。

手順4｜その日付をカレンダーに登録する

シートは見に行かないと読めませんが、カレンダーは向こうから来ます。停止日を登録し、その1ヶ月前にも通知を置いてください。

前述のとおり予告期間は2ヶ月から6ヶ月あります。今日気づけば、たいていのケースで間に合います。逆に言えば、間に合わなくなる唯一の原因は「気づくのが当日だった」ことです。

手順5｜延長申請の窓口があるかを確認する

意外に知られていませんが、移行が間に合わない事業者向けに延長申請の窓口が用意されていることがあります。今回のContent API for Shoppingがまさにそれで、Googleは公式に延長申請フォームを案内しています。

間に合わないと分かった時点で慌てて実装を急ぐより、まず窓口の有無を調べたほうが早い場合があります。これも「調べる工程」の一部です。

シートに書く項目（テンプレート）

1枚にまとめるときの列は、次の6つで足ります。凝ったツールは要りません。表計算ソフト1枚で十分です。

1回作れば、あとは更新するだけです。作成に半日、月次の見直しに15分といったところです。

止まるだけではない——値段が変わる日、持ち主が変わる日

外部に預けているものが、こちらの都合と無関係に動く経路は「停止」だけではありません。

1つ目は値段が変わることです。従量課金のAIは、モデルの世代交代や需要の変動で単価も条件も動きます。コストの設計は、モデルの選択だけでなく、どの契約形態で回すかによって桁が変わります。

2つ目は持ち主が変わることです。2026年8月、決済大手のStripeが、複数のAIモデルを1つのAPIに束ねるゲートウェイ「OpenRouter」を買収する見込みだとBloombergが報じました（TechCrunch）。ただし、この件について両社は正式発表しておらず、Stripeは取材に対し「噂や憶測にはコメントしない」と回答しています。あくまで報道段階の話です。

買収そのものの当否はここでの論点ではありません。押さえておきたいのは、外部に預けたものは「止まる・値段が変わる・持ち主が変わる」の3方向に動きうるという構造のほうです。どれも自分では止められません。だから、動いたときに何が起きるかを事前に知っておく必要があります。

どの工程を外部に預け、どの工程を手元に残すかという判断については、こちらでも整理しています。

AI業務効率化AIは全部クラウドに預けるな｜手元で回す工程の選び方

私が無人運用で持っている3つの備え

最後に、実際に自分の運用でやっていることを3つ挙げます。特別なことはしていません。

1｜主要な工程にはフォールバック経路を置く

画像生成のように「外部サービスが1つ落ちると工程全体が止まる」箇所には、別系統の経路を用意しています。ただし前述のとおり、予備を置いたら予備も棚卸しの対象に入れることが条件です。予備が死んでいる予備は、無いのと同じどころか、あると誤解している分だけ危険です。

2｜点検が動かないときは「公開しない」設計にする

これは実際に効きました。私の運用では、記事を公開する前に別のAIが内容を点検する工程を挟んでいます。この点検が何らかの理由で動かなかった場合、記事は公開せず下書きに退避するという設計にしています。

そして先日、まさにその状況が起きました。API廃止ではなく認証セッションの失効という別の止まり方でしたが、点検役のAIが起動できない状態が続いたのです。しかも処理そのものはエラーで落ちず、原稿の生成までは正常に進んでいました。

もし「点検が通らなくても公開する」設計にしていたら、点検されていない記事が公開され続けていたはずです。疑わしいときは進めないという一線を機械側に持たせておくと、外部依存が壊れたときの被害が「止まる」だけで済みます。

チェックを増やすより、通す条件を1本に絞るほうが機能するという話は、こちらでも書いています。

AI業務効率化AIのチェックは増やすほど抜ける｜1本にして観点で割る

3｜月に1回、シートを見直す時間を固定する

棚卸しは、作った日がピークで、あとは劣化していきます。使うサービスは増え、廃止予定は追加されるからです。

私は月次で見直す時間を決めています。作業自体は15分程度です。新しく使い始めたサービスを足し、廃止予定ページを開いて日付が増えていないかを見る。それだけです。頻度より、決まった日に必ずやることのほうが効きます。

よくある質問

自分が何のAPIを使っているか分かりません。どこから調べればいいですか

3つの入口があります。1つ目はクレジットカードの明細と請求書——課金が発生しているサービスは必ずここに出ます。2つ目は各サービスの管理画面のログイン履歴です。3つ目は、システムを作った相手への確認です。この3つで、実務上はほぼ洗い出せます。

移行作業は自分でやるべきですか、外注すべきですか

判断材料になるのは、猶予がどれだけ残っているかです。数ヶ月あるなら、内容を理解したうえで進める価値があります。数週間しかないなら、まず延長申請の窓口を探すことを優先してください。慌てて移行して別の不具合を作るより、期限を延ばして落ち着いて対応するほうが安全です。

廃止予定ページを毎日チェックする必要がありますか

ありません。予告期間は短くても2ヶ月あるため、月1回で十分間に合います。むしろ毎日見ようとすると続かず、結果的に一度も見なくなります。月次に固定するほうが確実です。

小さな会社でもここまでやる必要がありますか

規模が小さいほど必要だと考えています。担当者が複数いる会社なら誰かが気づく可能性がありますが、1人で回している場合、気づく人は自分しかいません。加えて、小規模な事業ほど外注で作った仕組みへの依存度が高くなりがちです。

まとめ

2026年8月17日にGoogleの Imagen 4 が、8月18日に Content API for Shopping が、8月26日にOpenAIの Assistants API が停止します。3件とも別々の会社で、別々の経路で予告されていました。

大事なのは、この3件に対応することではありません。次に来る停止日を、当日ではなく数ヶ月前に知る仕組みを持つことです。

• 外部サービスを全部書き出す（契約したもの・作ってもらったもの・予備の経路）
• 提供元の廃止予定ページから日付を集める
• 日付の横に「止まったら何が止まるか」を業務の言葉で書く
• カレンダーに停止日と1ヶ月前の通知を入れる
• 延長申請の窓口があるか確認する

止まったこと自体は、事故ではありません。予告されていたのですから、対応可能な出来事です。事故になるのは、止まる日を知らなかったときだけです。

AIを業務に組み込むということは、外部の都合で動くものを事業の一部にするということでもあります。株式会社Fyveは、導入して終わりではなく、こうした「止まったときにどうなるか」まで含めて設計することを大切にしています。