GPT-4oと4.1が2027年1月14日にAPIから消える。載せ替え費用は誰が持つか
2026年10月14日、OpenAIの廃止予定ページに4モデルの停止日が入りました。稼働中のAIシステムに必要な載せ替え作業4つと、保守契約の3つの型を整理します。
2024 年から 2025 年にかけて社内に入れた AI 機能は、かなりの割合が GPT-4o か GPT-4.1 の上に載っている。チャットボット、問い合わせの一次回答、帳票の読み取り、議事録の要約。当時それが標準的な選択だった。
2026 年 10 月 14 日、OpenAI の廃止予定（deprecations）ページに、その 4 モデルの停止日が入った。2027 年 1 月 14 日に API から削除される。
稼働しているシステムの側から見ると、これは「新しいモデルが出た」という話ではない。止まる日が決まった部品が、動いている装置の中に入っているという話である。
公表されている事実
OpenAI の API ドキュメントの廃止予定ページに書かれている内容だけを並べる。
2026 年 10 月 14 日告知分（停止は 2027 年 1 月 14 日）
| 対象 | 識別子 | 示されている代替 |
|---|---|---|
| GPT-4o | gpt-4o-2024-08-06 / gpt-4o-2024-11-20 |
gpt-6-luna |
| GPT-4o mini | gpt-4o-mini-2024-07-18 |
gpt-6-luna |
| GPT-4.1 | gpt-4.1-2025-04-14 |
gpt-6-luna |
| GPT-4.1 mini | gpt-4.1-mini-2025-04-14 |
gpt-6-luna |
あわせて、これらをファインチューニングした版は、ベースモデルと同じ日程で停止すると明記されている。
近い順に並べた、ほかの停止日
同じページには、ほかの系列の停止日も載っている。日付が近いものから並べると次のようになる。
| 停止日 | 対象 |
|---|---|
| 2026 年 10 月 31 日 | 既存の Evals（評価の設定）が読み取り専用になる |
| 2026 年 11 月 30 日 | v1/prompts API と再利用プロンプトオブジェクト／Agent Builder／Evals のダッシュボードと API |
| 2026 年 12 月 1 日 | 画像生成の旧モデル（gpt-image-1-mini / gpt-image-1.5 など） |
| 2026 年 12 月 11 日 | GPT-5 と o3 の初期スナップショット（gpt-5-2025-08-07 / o3-2025-04-16 など） |
| 2027 年 1 月 6 日 | 音声合成の旧モデル（tts-1 / tts-1-hd など） |
| 2027 年 1 月 14 日 | GPT-4o / GPT-4o mini / GPT-4.1 / GPT-4.1 mini |
| 2027 年 1 月 20 日 | 旧世代の音声・リアルタイム系 |
| 2027 年 2 月 26 日 | 文字起こしの旧モデル（whisper-1 / gpt-4o-transcribe など） |
| 2027 年 4 月 1 日 | gpt-5.1 / gpt-5.3-codex / gpt-5.4-nano |
移行先の案内も書かれている。再利用プロンプトはアプリ側のコードへ内容を移す、Agent Builder は Agents SDK か ChatGPT Workspace Agents へ（ChatKit は継続）、という形である。
ファインチューニング済みモデルが先に停止する件（2026 年 10 月 23 日）と、ファインチューニング自体の受付終了は、ファインチューニング済み旧モデルが10月23日に停止。新規作成も2027年1月で終了で扱った。今回はベースモデルそのものに期限が付いた点が違う。
発注者・企業への影響
ここからは見立てである。
1. 影響が出るのは「これから作るもの」ではなく「もう動いているもの」
新規の案件は、最初から新しいモデルで作れば済む。困るのは、2 年前・1 年前に納品を受けて、そのまま回っているシステムである。
発注側がまず確認したいのは、次の 1 点だけでよい。
当社のシステムは、どのモデルの識別子を呼んでいるか。
これは開発会社に聞けば即答できる。コードか設定ファイルに書いてあるからである。回答が gpt-4o-2024-08-06 のような日付付きの識別子なら、上の表のどこかに当たる。回答が gpt-4o のような日付なしの名前でも、その名前が指す先が消える以上、どこかで差し替えが必要になると考えられる。モデル名を書いても前提が固定されない構造はDeepSeekが9月14日の提供終了を撤回。モデル名を書いても前提は固定できないで整理した。
2. 載せ替えは「1 行の書き換え」では終わらない
公式ページには代替モデルが示されている。ただし代替が示されていることと、差し替えれば同じ結果になることは別である。実務で発生しうる作業は、おおよそ 4 つに分かれると考えられる。
- 呼び出しの書き換え（識別子の変更、パラメータの差異の吸収）。ここは軽い
- プロンプトの再調整。モデルが変われば同じ指示で同じ出力にはならない。出力の形式を前提にした後続処理があるほど影響が広い
- 精度の再確認。納品時に合格とした基準を、新しいモデルで満たすか測り直す。評価用のデータが残っていなければ、その作成から
- 運用費の再試算。単価とトークンの消費量が変わる。思考（reasoning）に課金される設計なら消費量の読みも変わる
重いのは 2 と 3 である。精度をどう測るかを納品時に決めていなかった案件は、「直った」と言える基準が社内に無いところから始めることになる。精度の測り方はAIの精度をどう評価するか。発注者が知るべき指標と落とし穴にまとめた。
3. 「誰が払うか」は保守契約の書き方で決まっている
載せ替えの費用負担は、たいてい次の 3 つのどれかに落ちる。
| 保守契約の書き方 | 載せ替え費用の扱い |
|---|---|
| 「外部サービスの仕様変更への対応」が保守に含まれている | 月額の中。追加費用なし |
| 保守は「不具合の修正」に限定されている | 別案件として追加見積もり |
| 保守契約自体がない（納品で終わり） | 全額が新規の発注 |
3 番目は珍しくない。初期費用を抑えるために保守を外した案件では、提供終了のたびに単発の発注が必要になる。保守の範囲の決め方はAI開発の保守費用の相場。契約に含めるべき範囲で扱っている。
いま契約中なら、保守契約の条項を読み返して、どの型かを確認するのが先である。追加見積もりになる型だった場合、1 月 14 日の直前は各社が同じ作業を抱える時期になる。見積もりを取るなら前倒しのほうが条件は選べると考えられる。
4. 11 月 30 日の 3 件は、開発中の案件に効く
v1/prompts、Agent Builder、Evals のダッシュボード。この 3 つは作る側が使う道具である。これらを前提に設計された仕掛けがあると、納品前に組み替えが必要になる。
いま開発が走っている案件では、「11 月 30 日に停止する機能を前提にした部分があるか」を 1 度聞いておくとよい。無ければ 1 往復で終わる確認である。
見積依頼・保守契約に入れる 4 行
これから発注する案件では、提供終了が必ず来る前提で次を書面に入れておく。
- 使用するモデルの識別子を見積書に明記する（「最新モデル」では範囲が決まらない）
- 提供元が提供終了を告知したときの対応を、保守の範囲に含めるか別途かを決める
- 載せ替え時の精度の再確認の手順と合格基準、および評価用データの引き渡しを納品物に含める
- モデル変更で運用費が変わった場合の扱い（上限額、超えたときの通知）
見積書の前提条件と有効期限の読み方はAI開発の見積書の前提条件と有効期限の読み方に、無料で相見積もり・相談の案件票では保守の範囲と求める精度水準を選択式で揃えている。
まとめ
公表されたのは停止日の一覧である。発注側がそこから取り出せるのは、AI を使ったシステムには数年単位で載せ替えの工事費がかかるという前提そのものだと考えられる。
初期費用と月額だけで比べた見積もりには、この工事費の行がない。3 年で見るなら、そこを含めて比べたほうが実際の総額に近づく。
参考・出典
- OpenAI「Deprecations」（API ドキュメント、2026 年 10 月 14 日告知分を含む） https://developers.openai.com/api/docs/deprecations
AI開発の見積もりを、同じ条件で比べる。
条件を整理した 1 枚の案件票で複数のAI開発会社に依頼。初期費用だけでなく、データ整備・API 費・精度検証・保守・権利まで同じ列で比較できます。