AIモデル提供終了への企業の対応｜移行6手順と期日一覧【2026】

2026年8月5日、Anthropic の Claude Opus 4.1（claude-opus-4-1-20250805）が公式ドキュメント上の提供終了（retirement）日を迎えました。提供終了を過ぎたモデルへの API リクエストは失敗します。つまり、業務システムにモデル名を直書きしていた企業は、その日を境に処理が止まります。

AI を業務に組み込んだ会社にとって、モデルの提供終了は「AI業界のニュース」ではなく自社の運用リスクです。この記事では、なぜ提供終了が起きるのか、何が壊れるのか、公式に確定している期日はどれか、そして中小企業が現実的に取れる移行手順を、各社の一次情報だけを根拠にまとめます。

結論：企業がやるべきことは4つだけ

AIモデルの提供終了に対する企業の対応は、突き詰めると次の4点に集約されます。特別な体制も専任担当も不要で、年に2回ほどこれを回せば事故はほぼ防げます。

1. 棚卸し：自社のどのツール・どの業務がどのモデル名を使っているかを一覧にする
2. 期日照合：ベンダーの公式「廃止（deprecation）ページ」だけを見て、終了日を突き合わせる
3. 検証と再調整：後継モデルで同じ入力を流し、出力の差分を人が見て、プロンプトを直す
4. 切替と監視：終了日の1か月以上前に切り替え、切替後しばらくは出力を目視で確認する

ベンダーの通知期間は、最短の Anthropic でも提供終了の60日以上前、OpenAI は一般提供モデルで6か月以上前とそれぞれ公式に定めています。つまり、対応の時間は必ず与えられます。事故が起きるのは「通知が来ていたのに、誰も自社の使用箇所を把握していなかった」ケースです。

なぜAIモデルは提供終了するのか（世代交代の周期）

AIモデルは、ソフトウェアというより設備に近い存在です。1つのモデルを提供し続けるには GPU の計算資源を常時確保しておく必要があり、新モデルを出すたびに古い世代の分を空けなければ容量が足りません。Anthropic は公式ドキュメントで、モデルの提供終了は「新しいモデルのリリースのための容量を確保するため」だと明記しています。

結果として、各社のモデルには次のようなライフサイクルが設定されています。Anthropic の用語がもっとも分かりやすいので、これを共通言語として覚えておくと他社の告知も読み解けます。

実際の周期は、2025年から2026年の実績を見ると登場からおおむね1年〜1年半で提供終了というペースです。たとえば Claude Opus 4.1 は2025年8月のモデル ID を持ち、2026年6月5日に廃止告知、2026年8月5日に提供終了。ちょうど1年で一巡しています。「一度組み込んだら5年使える」という感覚で設計すると、必ずどこかで詰まります。

提供終了で業務の何が壊れるのか

「モデルが終わる」と聞いてもピンとこない方のために、実際に現場で起きる壊れ方を3種類に整理します。厄介なのは、1番だけが分かりやすく壊れ、2番と3番は静かに壊れることです。

1. API 呼び出しが止まる（分かりやすい故障）

モデル名をコードや設定に直書きしている場合、提供終了日を過ぎるとリクエストがエラーで返ります。社内チャットボット、問い合わせの自動分類、日報の要約、スプレッドシートに組み込んだ関数など、裏側で静かに動いている自動化ほど気づくのが遅れます。エラー通知を仕込んでいなければ、「先週から要約が入っていない」と後から発覚します。

2. 出力の質や癖が変わる（静かな劣化）

後継モデルに切り替えれば動きはします。ただし同じ指示でも出力の長さ・語調・箇条書きの粒度は変わります。新モデルのほうが性能は高いのに、既存の運用にとっては「今までと違う」ことが問題になる、というのはよくある話です。文字数を前提にレイアウトしていた帳票、決まった形式で後続処理に渡していたテキストなどは、性能が上がったせいで崩れます。

3. プロンプトが効かなくなる（設計前提のズレ）

世代交代では、モデルの挙動そのものだけでなくAPI の仕様も変わります。実例として Anthropic は、Claude Opus 4.7 以降のモデルで temperature・top_p・top_k といったパラメータを廃止扱いとし、既定値以外を指定すると 400 エラーを返す仕様にしました。「出力のブレを抑えるため temperature を 0 に固定する」という定番の実装が、新モデルではそのままエラーになるということです。

また、旧モデル向けに長年チューニングした「言うことを聞かせるための呪文」の類は、新モデルでは不要になったり、逆に出力を歪めたりします。プロンプトは資産であると同時に特定モデルへの依存でもある、と考えておくのが安全です。

【確定】主要3社の提供終了カレンダー（公式ソースあり）

ここからは各社の公式ドキュメントに掲載されている確定情報のみを載せます（すべて2026年8月5日に一次ソースで確認）。二次的なまとめ記事やAI生成のニュースサイトには、実在しない日付が複数サイトで一致して載っていることが実際にあります。期日は必ず提供元の公式ページで確認してください。

Anthropic（Claude）

Anthropic は Claude API・AWS 上の Claude Platform・Microsoft Foundry についての日程を公開しています（Amazon Bedrock と Google Cloud はパートナー側が別途スケジュールを持つため日付が異なります）。

なお Opus 4.1 については、確認日（2026年8月5日）時点の公式一覧でも状態表記は「Deprecated」、終了日は「Tentative retirement date（暫定の提供終了日）」として 2026年8月5日 と記載されています。表記が Retired に切り替わった時点で、リクエストは失敗します。当日に慌てて確認するのではなく、前倒しで切り替えておくべき理由がここにあります。Claude 側の世代交代の全体像はClaude Opus 5の料金とプランを整理した解説と、Claudeの次のモデルはいつ出るかを追った記事で継続的に追っています。

OpenAI

OpenAI は公式の deprecations ページで、モデルだけでなくAPI・機能単位の廃止も同じ表に載せているのが特徴です。業務影響という意味では、こちらのほうが大きいことがあります。

とくに Assistants API の2026年8月26日終了は、社内向けアシスタントを外注で作った企業に効きます。モデル名の置換では済まず、実装の作り直しが必要になるためです。心当たりがあれば、この記事を読んだ今日のうちに開発元へ確認してください。

Google（Gemini）

Google の Gemini API は、廃止ページに掲載する日付を「retire される可能性がある最も早い日」と定義しており、正確な終了日は事前通知で伝えるという運用です。したがって Google の日付は「この日より前には消えない」という下限として読みます。

【未確定】噂・推測のレベルで扱うべき話

ここから下は公式に確定していない情報です。確定情報と混ぜると判断を誤るため、信頼度の記号（◎公式／○報道／△リーク／×根拠なし）を付けて分けます。△と×は、社内の意思決定の根拠にしないでください。

実務上の原則はシンプルです。移行計画に書き込んでよい日付は、提供元の公式ドキュメントに載っているものだけ。それ以外は「そのうち来る」という心構えの材料に留めます。これから出る新モデルの見通しは2026年後半に登場するAIモデルを信頼度つきで整理した一覧にまとめており、新モデルが出るタイミングは旧モデルの廃止告知が来るタイミングでもあります。

移行の6ステップ（提供終了に間に合わせる手順）

告知から終了までの期間は、Anthropic で最短60日、OpenAI の一般提供モデルで6か月。この間にやるべきことを順に並べます。所要期間の目安は、社内利用中心の中小企業で合計2〜4週間程度（実作業日ベースでは数日）です。

ステップ1：棚卸し（どこで何を使っているか）

最初にやるのは開発ではなく調査です。次の場所を洗い出し、1枚のシートにまとめます。ここが曖昧なままだと、以降の全工程が空回りします。

• 自社開発のアプリ・スクリプト（コード内のモデル名の文字列を検索）
• Google Apps Script やスプレッドシートの関数に埋め込んだ AI 呼び出し
• Zapier・Make などの自動化ツールの AI ステップ
• 外注したシステム（開発会社に「使用モデル名を教えてほしい」と依頼する）
• SaaS に内蔵された AI 機能（自社では制御できないが、挙動が変わる可能性がある枠として記録）

OpenAI・Anthropic とも、管理画面からAPI キーごと・モデルごとの利用実績を CSV で書き出せます（Anthropic は Console の Usage ページから Export）。記憶や口頭確認より、この実績データのほうが確実です。「使っていないつもりだったモデルが動いていた」を見つけられます。

ステップ2：影響範囲の特定（止まったら誰が困るか）

棚卸しした一覧に、「止まったときの業務影響」を大・中・小で付けます。顧客に直接見える機能（問い合わせ対応・見積の自動生成）は大、社内の効率化（議事録要約）は中、試作段階のものは小、という具合です。優先順位が決まれば、限られた時間をどこに使うかで迷いません。

ステップ3：後継モデルの検証（同じ入力で並べて見る）

ここが移行の本体です。過去の実データを10〜30件用意し、旧モデルと後継モデルの両方に同じ入力を流して、出力を横に並べて比較します。評価は自動化しようとせず、業務を知っている人が目視するのが結局いちばん速く、確実です。見るべき観点は次の4つです。

• 形式：文字数・箇条書きの数・見出しの有無など、後続処理が前提にしている形が保たれているか
• 語調：顧客に出る文章なら、丁寧さ・硬さが従来と揃っているか
• 正確さ：固有名詞・数値の扱いが雑になっていないか
• コスト：新モデルは単価も応答の長さも変わる。月額がいくらになるか概算する

ステップ4：プロンプトの再調整

差分が出たら、モデルではなくプロンプト側を直します。旧モデル向けに積み上げた細かい制約は、いったん削って必要な分だけ戻すほうが早いことが多いです。あわせて、廃止されたパラメータ（前述の temperature など）を指定していないかも確認します。出力形式を厳密に保ちたい場合は、プロンプトで頼むより構造化出力の機能で形式そのものを固定するほうが、次の世代交代にも耐えます。

ステップ5：切替（終了日の1か月以上前に）

切替は提供終了日の1か月以上前に済ませます。理由は単純で、問題が出たときに旧モデルへ戻せる余地を残すためです。終了日当日に切り替えると、退避先がありません。設定は1か所（環境変数や設定シート）にまとめ、そこを書き換えるだけで全体が切り替わる状態にしておくと、次回が数分で終わります。

ステップ6：切替後の監視

切替後の1〜2週間は、出力を人が目視で確認する期間と決めておきます。あわせて、API がエラーを返したときに気づける通知（メールやチャットへの自動投稿）を入れておくと、次に別のモデルが終了したときも「静かに止まったまま数週間」を防げます。

ここまで読んで「うちの場合はどこから手をつければいいのか」が判断しづらい、という場合もあると思います。Mihata では AI 導入支援として、こうしたモデル移行の棚卸しから後継モデルの検証まで、社内の担当者と一緒に進めるお手伝いをしています。記事の途中で恐縮ですが、必要そうであれば覗いてみていただけると嬉しいです。

中小企業が現実的に取れる4つの備え

専任のエンジニアがいない会社でも、次の4つは今日から実行できます。いずれも「次にモデルが終わったときの作業量を減らす」ための投資です。

1. モデル名をコードに直書きしない

モデル名は設定ファイル・環境変数・スプレッドシートの設定シートなど、非エンジニアでも書き換えられる1か所に置きます。これだけで、移行作業が「コード改修」から「1行の書き換え」に変わります。逆に「最新版を自動で使う」エイリアス指定は、意図しないタイミングで挙動が変わるため、業務システムではバージョンを固定した具体的なモデル名を使うほうが安全です（Google も本番用途には特定の安定版モデルの利用を推奨しています）。

2. 出力を人が確認する運用を残す

AI の出力を無検査で顧客に届ける設計にしていると、モデル交代のたびに事故のリスクを負います。金額・日付・固有名詞など間違えたら困る要素を含む出力には、必ず人の確認を1段挟む。これは提供終了対策としてだけでなく、AI 運用全体の基本です。

3. ベンダーの廃止ポリシーを契約前に見る

AI を組み込んだシステムを外注・購入するときは、裏側のモデル提供元がどれだけの猶予を約束しているかを確認します。公式に明示されている通知期間は次のとおりです。

実務での読み方は「プレビュー版・preview と名の付くモデルは、業務の基幹に入れない」です。2週間の猶予では社内調整すら間に合いません。試すのは自由ですが、止まっても困らない用途に限るのが原則です。

4. 半年に1度、棚卸しシートを見直す

廃止告知はメールで届きますが、届く先はAPI キーを作った人のアドレスです。退職者のアドレスや、外注先だけに届いて自社に伝わらない、というのがよくある抜け穴になります。カレンダーに半年ごとの予定を入れ、公式の廃止ページを開いて自社の使用モデルと突き合わせる。この15分の習慣が、いちばん費用対効果の高い対策です。

まとめ

AIモデルの提供終了は、避けられない前提条件です。2026年8月5日の Claude Opus 4.1 を皮切りに、8月26日には OpenAI の Assistants API、9月24日には Sora 2 系と、この先も数か月おきに期日が続きます。

大事なのは、驚かないための準備を平時にしておくことです。使用箇所を一覧化し、モデル名を差し替えやすい形にしておき、公式の廃止ページを半年に1度見る。これだけで、提供終了は「ニュースを見て慌てる事件」から「予定どおりの作業」に変わります。