OpenAI APIの提供終了ラッシュ、7月23日に旧モデル15系統が一斉停止｜外注で作った社内AIツールは誰が守るのか——開発会社に今週投げる質問リストと保守契約の点検箇所

最初に結論を書く。OpenAIの公式ドキュメントによると、4日後の2026年7月23日、gpt-5-chat-latest・gpt-5-codex・computer-use-preview・o3-deep-researchを含む15系統のモデルがAPIから一斉に削除される。続いて8月26日にはAssistants APIそのものが完全終了し、9月24日にはVideos API（sora-2系）、10月23日にはgpt-4・gpt-4-turbo・gpt-3.5-turboといった2024〜2025年の主力モデル群が停止する。2026年の後半は、ほぼ毎月どこかの停止日が来る「提供終了カレンダー」で埋まっている。

この記事が向き合うのは、移行の技術手順ではない。2024年から2025年にかけて開発会社に外注して作った社内AIチャットボット・問い合わせ対応ボット・文書検索ツールが、この停止日に該当するかどうかを、発注した側が把握していないという問題だ。自社で作っていないから、どのAPIのどのモデルで動いているかは開発会社しか知らない。保守契約が切れていたり、納品後にベンダーとの接点が途絶えていたりすれば、停止日を教えてくれる人は誰もいない。そして期日が来ると、障害でもサイバー攻撃でもなく、単に「予告どおりの仕様」としてツールは止まる。

やるべきことは3つに絞れる。第一に、今週中に開発会社へ本記事の質問リストを投げ、自社ツールの技術的な足場を一覧で出させること。第二に、保守契約書を開き、外部APIの仕様変更・提供終了への対応が契約範囲に入っているかを確認すること。第三に、移行見積もりが出てきたときに、その金額と工数が妥当かを判断する軸をあらかじめ持っておくことだ。本記事はこの3つを、技術者でない経営者・決裁者がそのまま使える形で示す。

この記事を読むべき人

• 2024〜2025年に開発会社へ外注して、社内チャットボット・FAQボット・文書要約・議事録ツールなどを作った会社の経営者・役員
• 納品後の保守契約を結んでいない、または更新せずに切れたまま運用している会社
• 「うちのAIツールはOpenAIですか？　どのモデルですか？」と聞かれて即答できない情シス担当・管理部門
• 開発会社から「モデル移行が必要です」という連絡と見積もりを受け取ったが、その金額が妥当か判断できない決裁者
• 開発を担当したベンダーと連絡が取りにくくなっている、あるいは担当者が退職・会社が事業縮小している場合

逆に、自社のエンジニアがコードを管理していて、OpenAIからの廃止通知メールを日常的に受け取り、対応を進めている会社であれば、本記事の大半は確認済みの内容のはずだ。その場合は停止日の一覧表だけ確認して戻ってもらえばよい。

事実整理：2026年下半期、何がいつ止まるのか

まず一次ソースで事実を固める。以下はすべてOpenAIの公式ドキュメント「Deprecations」（2026年7月19日確認）に記載されている確定スケジュールである。

この表から、発注側の経営判断に関わる事実を4点だけ抜き出す。

第一に、7月23日の停止は4月22日に告知済みであり、突然の話ではない。OpenAIは影響を受ける利用者へメールで通知し、ドキュメントにも掲載してきた。つまり「知らなかった」としたら、通知が自社に届かない構造になっていたということだ（この構造問題は次章で扱う）。

第二に、Assistants APIの終了はモデルの入れ替えではなく、APIそのものの廃止である点だ。2025年8月下旬に告知され（OpenAIの公式ページ内でも告知日の表記が8月20日と26日で揺れている）、約1年の猶予を経て2026年8月26日に完全終了する。OpenAIはResponses APIとConversations APIへの移行ガイドを公開しているが、これは設定変更で済む話ではなく、会話管理やファイル検索の仕組みを作り直す改修を伴い得る。ここが、単純なモデル名差し替えと工数の桁が変わる分岐点になる。

第三に、Videos API（sora-2系）には公式の移行先が示されていない。表の「記載なし」は書き漏れではなく、公式ドキュメント上で推奨代替が空欄になっている。動画生成を業務フローに組み込んでいた場合、これは移行ではなく機能の存廃判断になる。

第四に、OpenAIは今後のモデル引退の予告期間を方針として明文化している。一般提供モデルは最低6ヶ月前、chat系・codex系・deep research系などの特化バリアントは最低3ヶ月前、名前に「preview」が付くモデルは2週間程度の短い予告で引退し得る、という基準だ。この方針の意味は重い。自社ツールがpreviewモデルの上に作られていた場合、2週間前の通知で止まることを、OpenAIは公式に留保している。どのモデルの上に自社の業務が載っているかは、もはや技術的な細部ではなく、事業継続の前提条件である。

なお、混同しやすい点を先に整理しておく。ここで止まるのはAPI、つまり開発会社がプログラムからOpenAIのモデルを呼び出す経路である。社員がブラウザで使うChatGPT（有料プラン含む）の画面上のモデル提供とは告知体系が別であり、この表をChatGPTの利用可否と読み替えてはいけない。逆も同じで、「ChatGPTは普通に使えているから大丈夫」は、API側で動く自社ツールの安全を何も保証しない。

なぜ「外注で作った社内AIツール」が最も危ないのか

対象技術の一覧だけなら、OpenAIのページを見れば分かる。問題は、外注構築のツールには、停止日に気づけない構造的な理由が3つ重なっていることだ。ここが本記事の中心であり、自社が当てはまるかを一つずつ確かめてほしい。

理由1：2024〜2025年の外注案件は、いま消える技術の「当時の標準」で作られている

2023年末に登場したAssistants APIは、社内文書を読み込ませて質問に答えさせる、会話の文脈を覚えさせる、といったチャットボットに必要な機能をAPI側がまとめて提供する仕組みだった。ゼロから作るより早く安く納品できるため、社内ボットやFAQ応対ツールの受託開発で広く採用された。同じ時期の標準モデルはgpt-4o・gpt-4-turbo・gpt-3.5-turboであり、コスト重視の案件ではgpt-3.5-turboが既定の選択だった。つまり、2024〜2025年に「AIチャットボットを作ってください」と発注した案件は、8月26日に終了するAssistants APIと、10月23日に停止する旧モデル群のどちらか、あるいは両方の上に載っている可能性が高い。これは特定の開発会社の手抜きではない。当時の合理的な技術選定が、2年後の提供終了ラッシュで一斉に期限を迎えているだけだ。だからこそ「うちのベンダーはちゃんとした会社だから大丈夫」という信頼は、この問題への答えにならない。確かめる以外の方法がない。

理由2：OpenAIの廃止通知は、発注側には届かない

OpenAIは廃止を決めると、対象モデルを実際に利用している顧客へメールで通知すると明言している。ここで「顧客」とは、APIアカウントの保有者である。外注構築の場合、APIアカウントとAPIキーは開発会社の名義で発行されていることが珍しくない。その場合、廃止通知は開発会社に届き、発注側の あなたの会社には一通も来ない。開発会社が保守契約に基づいて監視していれば通知は活きるが、保守契約が切れていれば、通知メールは誰にも読まれずに流れる。担当エンジニアの退職、開発会社の事業転換・廃業があれば、なおさらだ。自社名義でアカウントを持っている場合でも、通知メールの宛先が「構築時に作った管理用アドレス」で、いま誰も受信箱を見ていないというケースは多い。停止情報が自社に到達する経路が存在するか——これは今週確認すべき項目の中でも最優先に近い。

理由3：止まり方が「静かな全損」であり、障害対応の常識が通用しない

通常のシステム障害は、時間が経てば復旧する。だから現場は「AIボットの調子が悪い」程度の認識で数日様子を見てしまう。しかし提供終了によるエラーは仕様であり、待っても直らない。放置された社内ツールは、停止日を境に「応答しないボタン」になり、現場が使うのをやめ、数週間後に誰かが「そういえばあれ、動いてないですよね」と口にして初めて発覚する。顧客向けに組み込んでいた場合は、この発覚の遅れがそのまま顧客体験の毀損になる。さらに厄介なのは、復旧作業が「元に戻す」ではなく「移行する」になることだ。停止後に慌てて着手すると、移行先の選定・改修・検証を、ツールが止まったままの状態で進めることになる。同じ作業でも、停止前にやれば計画的な改修、停止後にやれば止血しながらの突貫工事であり、かかる費用も社内の混乱もまるで違う。

移行には3つの重さがある——見積もりを受け取る前に知っておく判断軸

開発会社に確認を投げると、多くの場合「移行が必要です」という回答と見積もりが返ってくる。そのとき発注側が丸腰だと、金額の妥当性を判断できず、言い値で承認するか、根拠なく値切って関係を壊すかの二択になる。まず、移行作業には重さの異なる3つの類型があることを押さえてほしい。

類型A：モデル名の差し替えで済むケース。 使っているAPIは存続し、モデルだけが停止対象の場合だ。プログラム上の変更自体は小さい。ただし「変更が小さい」と「作業が小さい」は別物である。モデルが替われば回答の品質・口調・拒否のしかた・出力形式が変わり、業務で使える水準かの検証が必要になる。この検証を省いた「モデル名を変えるだけなので30分です」という対応は、安いのではなく検証を放棄しているだけだ。モデル交代が本番システムの品質をどう変えるかは、LLMのEOLに備えるモデル移行テストの作り方で詳しく扱っている。

類型B：廃止されるAPIからの作り直しを伴うケース。 Assistants APIで構築されたツールがこれに当たる。会話履歴の管理、アップロードした文書の検索、外部ツールの呼び出しといった仕組みを、Responses API・Conversations APIの流儀で組み直す必要がある。加えて、旧API側に溜まっている資産——会話スレッドの履歴、読み込ませた文書、調整済みの指示文——をどう引き継ぐかというデータ移行の論点が乗る。類型Aとは工数の桁が違って当然であり、逆に、Assistants API案件に対して類型A相当の軽い見積もりが出てきたら、それは安心材料ではなく調査不足のサインとして扱うべきだ。

類型C：移行先が存在しないケース。 Videos APIのように公式の代替が示されていない場合、問いは「どう移行するか」ではなく「この機能を今後も持つか」に変わる。他社サービスへの乗り換え、機能の凍結、業務フロー自体の見直しを比較する経営判断であり、開発会社に見積もりを出させる前に、発注側がこの判断を済ませておく必要がある。

そのうえで、出てきた見積もりの妥当性は次の軸で見る。まともな移行見積もりには、（1）現状調査（どこで何を呼んでいるかの確定）、（2）移行方針の設計と差分の説明、（3）移行作業そのもの、（4）業務データを使った動作検証、（5）切替と切り戻し手順、の5要素が金額の内訳として見えているはずだ。内訳がなく一式いくらの概算だけ、しかも現状調査をせずに金額が出てくる場合、その数字は自社の実態を反映していない。反対方向のレッドフラグもある。モデル停止への対応相談に対して「これを機に全面リプレースを」と大規模刷新へ話を広げる提案は、必要な場合も確かにあるが、期限が4日後・5週間後と迫っている局面で唯一の選択肢として出てくるなら、期限の切迫を値札に転嫁されていないか疑ってよい。緊急対応（停止回避の最小限の措置)と、恒久対応（設計の見直し）を分けて見積もらせるのが、期限つき案件の基本形だ。

もう一つ、費用負担の前提も整理しておく。外部APIの仕様変更・提供終了は開発会社が起こしたことではないため、納品時に正しく動いていた以上、その対応費用が有償になること自体は一般に不当ではない（個別の契約内容によるため、金額が大きい場合は契約書とあわせて法務にも確認してほしい）。発注側が争うべきは「無償でやれ」ではなく、内訳の透明性と、類型A/B/Cのどれに該当するかの根拠である。ここを詰めるだけで、見積もり協議はかなり健全になる。

今週、開発会社に投げる質問リスト

以下は、そのままメールに貼って送れることを意図した質問リストだ。技術の細部を発注側が理解する必要はない。回答が一覧表で返ってくるか、期限内に返ってくるか、それ自体が開発会社の管理状態の診断になる。

• 1. 弊社向けに構築したシステムが呼び出している外部AIサービスと、APIの種類・モデル名（スナップショット指定を含む）を一覧で提示してください。 ——この一覧が数営業日で出てこない場合、構成が文書管理されていない可能性が高い。それ自体が是正すべきリスクである。
• 2. その一覧のうち、OpenAIが公表している2026年7月23日・8月26日・9月24日・10月23日の各停止日に該当するものはどれですか。 ——停止カレンダーとの突合を発注側でやる必要はない。突合させて、該当有無を回答させる。
• 3. Assistants APIを使用していますか。使用している場合、8月26日までの移行方針・概算費用・スケジュールを提示してください。 ——前章の類型Bに当たるかどうかを最初に切り分ける質問である。
• 4. OpenAIのAPIアカウントはどちらの名義ですか。OpenAIからの廃止通知メールは、現在誰に届いていますか。 ——通知の到達経路の確認。ベンダー名義なら、今後の通知を発注側にも転送・共有する運用をこの機会に合意する。
• 5. 現行の保守契約（保守契約がない場合はその旨）において、外部APIの仕様変更・提供終了への対応は範囲に含まれますか。含まれない場合、どういう条件で対応可能ですか。 ——責任分界を文書で確認する。口頭の「対応しますよ」で止めない。
• 6. 移行を行う場合、何をもって「移行完了」としますか。弊社の実際の業務データ・想定質問での動作確認は含まれますか。 ——検証なしの切替を防ぐ。完了条件が「エラーが出ないこと」だけなら、品質検証が抜けている。
• 7. 上記1〜4について、今週中の回答をお願いします。 ——7月23日が目前のため、全部の回答を待たず、まず該当有無だけでも先に確定させる。

返答が来たら、見るべきポイントは2つある。一つは証拠の形式だ。「確認しましたが問題ありません」という一文と、「モデル一覧はこの通りで、7/23対象はなし、Assistants APIは未使用」という表つきの回答では、信頼してよい度合いがまったく違う。もう一つは7月23日対象が見つかった場合の初動だ。残り日数を考えると、この場合は恒久対応を待たず、暫定のモデル差し替えと最低限の動作確認をまず実施し、品質の詰めを後追いにする二段構えが現実的になる。なお、OpenAIは停止日以降の継続利用について、条件次第で専用キャパシティの提供に応じ得るとドキュメントで案内している。どうしても期日に間に合わない基幹用途がある場合、この選択肢の可否を確認する価値はある。

開発会社と連絡が取れない、あるいは廃業している場合は、質問リストの宛先がなくなる。この場合、ソースコードと構成情報を自社が保有しているか（納品物に含まれていたか）がすべての起点になり、保有していれば別の開発会社による調査で同じ情報は復元できる。保有していなければ、ツールの再構築を含めた判断になる。いずれにせよ停止日は待ってくれないため、社外の技術者に調査を依頼する判断を早めに下すべき局面だ。

保守契約のどこを見るか——「保守しているのに止まる」を防ぐ

質問5に関わる契約の話を、発注側の視点でもう少し掘る。多くの保守契約の範囲は、サーバーの稼働監視、障害時の一次対応、軽微な修正、問い合わせ対応で構成されている。ここに外部サービスの仕様変更・提供終了の監視と対応が明記されていることは、実は多くない。つまり「保守契約を払い続けているのに、API停止でツールが止まり、その復旧は別途見積もり」という事態は、契約上は矛盾なく起こり得る。保守料を払っている安心感と、実際にカバーされている範囲のずれが、この提供終了ラッシュで一気に表面化する。

いま結んでいる契約、またはこれから更新する契約で確認・追加を検討すべきは次の4点だ。第一に、外部API・外部サービスの廃止情報の監視と、発注側への通知義務が保守範囲に入っているか。移行作業自体は別費用でも構わないが、「止まることを事前に知らせる」の部分は保守の中核に置くべきだ。第二に、廃止告知が出た際の影響調査と報告の初動期限（たとえば告知から2週間以内に該当有無と概算影響を報告する、など）が定められているか。第三に、利用しているAPI・モデル名の一覧を納品物・保守報告の一部として維持更新する義務があるか。今回のように発注側が慌てて問い合わせる状況は、この台帳が常時共有されていれば起こらない。第四に、契約終了時にソースコード・構成情報・APIアカウントの引き継ぎがどう定められているか。ベンダーを変えられない状態は、それ自体が価格交渉力の喪失を意味する。

これらは新規の開発発注でも同じように効く。AI関連の開発は、作って終わりではなく外部基盤の変化に追随し続ける前提で契約を設計する必要があり、その設計は発注前にしかできない。開発会社への発注や契約条件の整理に不安がある場合は、システム開発の発注前相談で契約・見積もりの観点を先に整えておくことを勧める。

FAQ——よくある疑問

Q1. 社員はChatGPTを使っているだけで、開発したツールはない。この話は関係ないか。

ブラウザやアプリでChatGPTを使っているだけなら、今回のAPI停止カレンダーの直接の対象ではない。ただし2点確認してほしい。一つは、SaaSとして契約している業務ツール（チャットボット、議事録、要約など）の裏側がOpenAI APIで動いているケースで、この場合の移行責任はSaaS事業者側にあるが、品質や仕様が変わる可能性はある。もう一つは、現場の誰かが個人的にAPIを使った小さな自動化を作っているケースだ。会社が把握していないAI利用の洗い出しという広い論点は、AIツールのExit条件設計の記事で扱っている。

Q2. 7月23日の対象だと分かった。残り4日で間に合うのか。

対象がモデル停止（類型A）であれば、暫定対応としてのモデル差し替え自体は短期間で可能なことが多く、開発会社が稼働できるなら物理的に間に合う余地は十分ある。重要なのは、この局面では「完璧な移行」を狙わないことだ。まず止まらない状態を確保し、品質検証と恒久設計は停止日を越えてから詰める。逆に間に合わない場合も、何が止まり、どの業務にどれだけ影響するかを事前に把握して現場へ告知しておけば、被害は「予告済みの一時停止」に抑えられる。最悪なのは、対応もせず告知もせず当日を迎えることである。

Q3. 開発会社から「対応済みです」と回答が来た。それで安心してよいか。

回答の中身による。モデル・API一覧と、停止カレンダーとの突合結果、切替後の検証記録が示されているなら信頼してよい。「対応済み」の一文だけなら、何をどう確認したのかを追加で聞くべきだ。誠実な開発会社ほど、証拠つきの回答を求められることを嫌がらない。むしろこの確認のやり取りは、今後も毎年続く提供終了対応をその会社に任せられるかを見極める機会になる。

Q4. 移行費用は結局、発注側が払うしかないのか。

納品時に契約どおり動いていたものが外部要因で動かなくなる場合、その対応が有償となるのは一般的な整理であり、支払い自体を拒む筋は立てにくい（個別の契約条件によるため、断定はしない）。発注側が主張すべきは金額のゼロ化ではなく、内訳の開示、類型A/B/Cの根拠、緊急対応と恒久対応の分離だ。また、見積もりが自社の実態に対して過大でないかを第三者に検証させる方法もある。金額の桁が大きい、または複数ツールが同時に対象になった場合は、セカンドオピニオンを取る費用対効果は十分にある。

Q5. 今回を乗り切れば、しばらくは安心か。

安心できない。表のとおり停止日は12月まで毎月のように続き、OpenAIは予告期間の方針（一般モデル6ヶ月・特化モデル3ヶ月・previewは2週間程度）を明文化した。これは提供終了が例外的な事件ではなく、定常的な運用サイクルであるという宣言に等しい。発注側の対応も一回きりの防災訓練ではなく、自社のAIツールが何の上で動いているかの台帳を持ち、廃止情報が自社に届く経路を確保し、保守契約にその監視を組み込む、という恒常運用に切り替える必要がある。今回の質問リストへの回答一式は、そのままその台帳の初版になる。

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、開発会社とのやり取りと並行して、第三者の視点を入れる価値がある。

• 質問リストを送ったが、回答が期限までに返ってこない、または一覧の形で出てこない
• Assistants API利用が判明し、提示された移行見積もりの規模感が妥当か社内で判断できない
• 複数のAIツール・複数のベンダーが同時に停止対象になり、優先順位を自社で付けられない
• 開発会社と連絡が取れず、ソースコードや構成情報の所在も分からない
• この機会に、AIツールの台帳整備と保守契約の見直しまで一気にやり切りたいが、社内に推進役がいない

GXOのAI導入可否アセスメントは、売りたい開発案件ありきではなく発注側の立場で、自社AIツールの現状把握、移行要否の切り分け、ベンダー見積もりの妥当性検証を整理する30分の壁打ちから始められる。移行にあわせてツールの作り直しや機能拡張まで踏み込む判断になった場合は、AI・自動化支援で設計から実装まで対応する。7月23日と8月26日は動かない期日だ。「うちのツールは何の上で動いているのか」という一問に、今週中に答えが出る状態を作ってほしい。判断に迷う点があれば、お問い合わせフォームから現状把握だけの相談でも構わない。

参考ソース

• OpenAI 公式ドキュメント「Deprecations」 https://developers.openai.com/api/docs/deprecations （2026年7月19日確認。7月23日・8月26日・9月24日・10月23日ほか各停止日、対象モデル一覧、予告期間の方針、Assistants APIの移行先の記載を確認）

本記事の停止日・対象・移行先は2026年7月19日時点のOpenAI公式ドキュメントの記載に基づきます。スケジュールは変更される可能性があるため、対応の実行前に必ず一次ソースを再確認してください。移行類型・質問リスト・契約点検の観点はGXO独自の判断フレームであり、費用負担・契約解釈に関する記述は一般論です。個別の契約判断は契約書の条文と法務専門家の確認を優先してください。