本番稼働から半年。仕訳の下書きも問い合わせの振り分けも、毎日静かに動いていた仕組みが、ある朝エラーで止まる。ログを見ると、指定していたモデルが「提供終了」になっている。別の場面を想定すると、止まりはしなかったが、月次の締めで例外の件数が先月の2倍に増えていた。原因は、モデルの名前は同じまま中身が新しい版に切り替わっていたこと。どちらも、作った人が悪いのではありません。AI のモデルは、ソフトウェアの部品として見ると寿命が短く、しかも寿命の長さをベンダーが決める。この前提を運用に組み込んでいないと、本番後に止まる時期が来ます。
この記事は、ハブ記事で書いた FDE（Forward Deployed Engineer）の4条件のうち、4つ目「本番まで持っていき、動かし方も渡す」の、本番後の部分だけを扱います。扱うのは4つ。本番後に起きる変化（提供終了・仕様変更・価格改定・出力の変化）を、各ベンダーが公開している廃止（deprecation）のルールで確認できる事実として整理する。それを業務側から見るとどう見えるかを、経理の仕訳候補と問い合わせ分類の例で書く。FDE が本番前に決めておく5つと、切替の5段階の手順。そして月次の運用に組み込む点検項目。Anthropic・OpenAI・Google Cloud・Microsoft の公式ドキュメントと、当社が経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験を一般化して書いています。
AI のモデルには提供終了日がある。告知から終了までは Anthropic が60日以上、OpenAI が一般提供モデルで6か月以上、Google Cloud は公開から12か月以上の提供、Microsoft Foundry は公開時に18か月後の終了日が決まる。だから FDE は本番前に、モデルの版を日付付きで固定する、本番データから抜いた回帰テストセットを持つ、切替の判断者（Echo 役）と手順を決める、費用を四半期ごとに再見積する、変更を1行ずつ記録する、の5つを決めておく。切替は新旧並走→差分確認→Echo 役の承認→切替→1サイクル監視の順で、月次会議に「終了日までの残日数」と「回帰テストの結果」を載せて回す。
この記事の要約
本番後に起きる4つの変化——提供終了・仕様変更・価格改定・出力の変化
前提から確認します。AI のモデルは、クラウド会計ソフトや kintone のような「契約している限り使える」製品とは違い、ひとつの版（バージョン）ごとに提供終了日があります。ベンダーは新しいモデルを出すと、古いモデルを順に「非推奨（deprecated）」にし、一定期間の後に「終了（retired）」にする。終了したモデルへの要求は失敗します。Anthropic の公式ドキュメントは、終了したモデルの状態を「もう利用できない。終了したモデルへのリクエストは失敗する」と定義し、Microsoft Foundry のドキュメントは、終了後の推論要求はすべて 410 Gone を返すと書いています。エラーの形は違っても、業務側から見れば同じです。ある日、動かなくなる。
では、告知から終了までにどのくらいの猶予があるのか。主要4社の公式ページに書かれている値だけを表にします。数字はどれも2026年9月5日時点の公式ページの記載で、ベンダーが改定すれば変わります。
| ベンダー（サービス） | 告知から終了までの期間（公式ページの記載） | 公式ページに載っている実例 | 公式ページ |
|---|---|---|---|
| Anthropic（Claude API） | 公開済みモデルは終了の「少なくとも60日前」に通知。稼働中のモデルにも「〜より早くはならない」暫定終了日を明示 | Opus 4.1 は 2026年6月5日告知→8月5日終了。Sonnet 4・Opus 4 は 4月14日告知→6月15日終了 | Model deprecations |
| OpenAI（API） | 一般提供モデルは「少なくとも6か月」、その派生（chat・codex 等）は「少なくとも3か月」、プレビューは「2週間など、ずっと短い」 | gpt-5 系の日付付き版は 2026年6月11日告知→12月11日終了 | Deprecations |
| Google Cloud（Gemini） | 対象モデルは「公開から少なくとも12か月」提供。終了日は延びることはあっても前倒しにはならない。短期提供モデルは「後継の公開から45日」で終了 | gemini-2.5-pro は 2025年6月17日公開→2026年10月20日終了 | Model versions and lifecycle |
| Microsoft（Foundry / Azure OpenAI） | 一般提供モデルは公開時に「18か月後」の終了日が設定され、12か月で新規顧客向けに非推奨。終了の「少なくとも60日前」に通知。プレビューは30日前。終了日の延長は不可 | gpt-4o（2024-05-13 版）は 2026年10月1日に終了し、Standard 配備は後継へ自動更新 | Foundry Models lifecycle and support policy |
表から読み取れることは3つあります。第一に、一般提供モデルの猶予は Anthropic と Microsoft の「60日」が最短で、実績もほぼその日数（Anthropic の Opus 4.1 は告知から終了まで61日）です。プレビュー版はさらに短く、OpenAI は2週間、Microsoft は30日です。60日は、月次で締める業務なら締めが2回しか来ない長さで、その間に切替と検証を終える必要がある。第二に、Google Cloud と Microsoft は「公開日から数える」方式で、Microsoft は公開時点で18か月後の終了日が決まっている。つまり導入した日に、終了日が分かる。第三に、同じモデルでも提供元で終了日が違う。Anthropic のページは、Amazon Bedrock と Google Cloud 経由の Claude は「提供者が独自の終了スケジュールを設定する」と明記しています。Microsoft のページも、Anthropic・DeepSeek・Mistral AI などのモデルは標準の18か月ではなく12か月と書いている。どこから使っているかで、寿命が変わります。
提供終了のほかに、動いたまま起きる変化が3つあります。ひとつは仕様変更で、モデル本体ではなく API の指定項目が使えなくなるもの。Anthropic のページには、出力のばらつきを調整する temperature などの項目が Claude Opus 4.7 以降のモデルでは非推奨になり、既定値以外を指定すると 400 エラーを返すこと、Python SDK の 1.0 以降ではこの項目そのものが削除されたことが書かれています。モデルを替えていなくても、SDK を更新した日に止まる例です。
ふたつめは価格改定です。当社の Claude 仕様変更まとめで追ったとおり、2026年6月に公開された Sonnet 5 は「導入価格の後に9月1日から値上げ」と案内され、8月に値上げが取りやめになりました。上がる方向も下がる方向も、告知から実施まで数週間で動く。本番前に見積った月額は、その時点のモデルと価格で計算した値でしかありません。
みっつめが、いちばん気づきにくい「出力の変化」です。モデルの版を固定していれば、同じ入力に対する出力の傾向は保たれます。Microsoft のドキュメントは一般提供モデルを「重みと API が固定され、セキュリティ修正は出力に影響しない」と定義している。逆に、日付なしの名前（エイリアス）で呼んでいたり、Microsoft の Standard 配備のように終了時に後継へ自動更新される設定になっていたりすると、名前は同じまま中身が替わり、出力が変わります。冒頭の「例外件数が2倍」はこれです。エラーが出ないので、気づくのは締めの日になる。
「動いていたものが変わる」を業務側から見る——仕訳候補と問い合わせ分類
ここまではベンダー側の話でした。同じ出来事を業務側の席から見ると、症状は3種類に分かれます。止まる（終了・仕様変更）、変わる（出力の変化）、高くなる（価格改定・使用量の増加）。それぞれ、誰の何がどうなるかを2つの業務で書きます。
経理の仕訳候補。経理業務を FDE 方式で本番化する記事で書いた構成では、AI が請求書から勘定科目・税区分・部門の候補を作り、経理担当が確認して確定します。「止まる」が起きると、締め日の朝から候補が出ず、経理担当は全件を手入力に戻す。月200件なら、確認だけだった作業が入力に変わり、締めが1〜2日遅れます。「変わる」はもっと厄介で、候補は出続けるのに、前月まで「通信費」だったものが「消耗品費」で出てくる、税区分の候補が経過措置の扱いで揺れる、といった形で現れる。経理担当は1件ずつ直せるので誰も報告せず、月次の例外件数だけが増える。承認者が気づくのは、判断表と突き合わせたときです。「高くなる」は、後継モデルが長い説明を返すようになって出力トークンが増えた、単価が上がった、の2通りで、請求書が来る翌月に分かります。
問い合わせ分類。顧客や社内からの問い合わせを AI が「請求」「不具合」「解約」「その他」に分類し、担当へ振り分ける仕組みでは、「止まる」と全件が未分類の箱に溜まり、当番が手で振り分けます。「変わる」は分類の分布が動く形で出ます。後継モデルが「解約」を広めに取るようになれば、解約担当の件数が増え、営業担当に回るべき相談が解約の列に並ぶ。回答期限を決めている会社では、この列の遅れがそのまま期限超過になります。どの業務でも共通するのは、「変わる」は当日には見えず、月次の件数と分布で初めて見える、という点です。だから対策も月次の点検に置きます。
| 症状 | きっかけ | 仕訳候補（経理）で起きること | 問い合わせ分類で起きること | 気づく時期 |
|---|---|---|---|---|
| 止まる | 提供終了、API の指定項目の廃止、SDK の更新 | 候補が出ず全件手入力。締めが1〜2日遅れる | 全件が未分類に溜まり、当番が手で振り分ける | 当日（エラー） |
| 変わる | エイリアス指定で中身が後継に替わる、自動更新 | 科目・税区分の候補が揺れ、例外件数が増える。担当は直せるので報告されない | 分類の分布が動き、特定の担当に件数が偏る。回答期限の超過 | 月次の締め・集計 |
| 高くなる | 単価の改定、後継モデルの出力が長い | 月額が見積を上回る | 同左 | 翌月の請求 |
FDE が本番前に決める5つ
当社は、本番移行の前に次の5つを決め、成果物の記事で書いた「動かし方」の中に含めて Echo 役（顧客側で業務と仕組みを引き継ぐ担当）へ渡します。5つとも技術的に難しいものはなく、決めていないことが問題になる類のものです。
| 決めること | 内容 | 決める人 | 残す場所 |
|---|---|---|---|
| ①モデルの版の固定 | 日付付きのモデル名（例: 2025-09-29 版）で指定し、日付なしの名前や「最新」を指すエイリアスを使わない。自動更新の設定は切る | FDE が提案、情シスが承認 | 設定ファイルと運用手順の1ページ目 |
| ②回帰テストセット | 本番データから抜いた50〜200件の入力と、確定済みの正解。合格基準（一致率と、不一致を許さない項目） | FDE と現場担当が作り、Echo 役が持つ | 業務側の道具（表計算・kintone）に置く。FDE 側に置かない |
| ③切替の判断者と手順 | 誰が「切り替える」と言うか（Echo 役）、誰が実行するか（情シス）、戻す条件は何か | 経営が任命、Echo 役が運用 | 運用手順の「切替」の章 |
| ④費用の再見積の頻度 | 四半期ごとと、モデル切替のたび。実測の使用量×現行単価で計算し直す | Echo 役が計算、経営が確認 | 月次報告の1行 |
| ⑤変更の記録 | いつ・誰が・何から何へ・回帰テストの結果・承認者、を1件1行 | 実行した人がその場で書く | 業務側の道具に一覧で |
①の「版の固定」が起点です。固定しなければ②以降が成り立たない。Anthropic の使用状況の一覧は Console からエクスポートでき、API キーとモデルごとの利用が出ます。Microsoft は Models API で各モデルの終了日を参照でき、Standard 配備には自動更新の設定（新しい既定版が出たら更新する／終了時のみ更新する／更新しない）が用意されています。どのベンダーでも、「いまどの版を使っているか」を一覧で答えられる状態を、本番移行の条件にします。
②の回帰テストセットは、切替のときだけ使うものではありません。月に1回、現行モデルで流して結果が変わっていないことを確かめる。これが「変わる」を月次で見つける、当社の標準の手段です。件数は業務によりますが、当社の目安は、判断表にある例外の条件を1件ずつ含めた上で50〜200件。正解は現場担当が確定したものを使い、AI の出力をそのまま正解にしない。合格基準は一致率だけでなく、「金額が閾値を超える仕訳は1件も不一致を許さない」のように、業務上の重要度で分けて書きます。
③〜⑤は受け入れ体制の記事の会議体に乗せます。切替の判断は週次で Echo 役が出し、費用の再見積は月次報告の1行として経営が見る。変更の記録は、FDE の失敗パターンで挙げた「⑦権限・監査を後回し」の対策でもあります。監査で「この仕訳候補はどのモデルの、いつの版が出したものか」と聞かれたとき、変更記録の1行がなければ答えられません。
切替の手順——新旧並走から1サイクル監視まで5段階
切替そのものは、設定を1か所変えるだけです。手順が5段階あるのは、変える前に差分を見て、変えた後に業務が回ることを確かめるためで、当社は次の順で回しています。
①新旧並走。新しいモデルを、本番と同じ入力で裏側で動かします。出力は業務には使わず、記録だけ取る。期間は1〜2週間、月次で締める業務なら締め1回分。Microsoft のドキュメントは、後継モデルを終了の約90日前から試せるようにすると書いていて、Anthropic も「終了日の十分前に新モデルで徹底的に試すこと」を勧めている。並走の期間を取れるかどうかは、告知の週に動き始めるかどうかで決まります。
②差分確認。回帰テストセットを新旧両方で流し、一致率と、不一致の内訳を出します。内訳は「新が正しい」「旧が正しい」「どちらとも言えない」の3つに分け、あわせて1件あたりの費用と処理時間を比べる。ここで数字を出しておくと、③の承認が「なんとなく良さそう」ではなく「一致率97%、不一致の6件のうち4件は新が正しい、費用は1件あたり2割減」という判断になります。
③Echo 役の承認。不一致を判断表と照らし、プロンプト（AI への指示文）や判断表を直すか、新モデルの出力を受け入れて判断表を更新するかを決めます。決めた内容は変更記録に書く。ここで承認者を Echo 役に固定する理由は、切替の影響を受けるのが業務側だからです。情シスや FDE が「動いたから切り替えた」と進めると、月次の例外件数が増えた理由を経理担当が知らない、という状態になります。
④切替。設定を変える前に、戻す条件と戻し方を確認します。戻す条件は、たとえば「例外件数が並走期間の平均の1.5倍を超えたら」「回答期限の超過が週に3件を超えたら」のように、数字で書く。ただし、旧モデルが提供終了している場合は戻せません。だから告知の週に①を始め、終了の1か月前までに④を終える。この「1か月前」は、⑤で締め1回分を監視し、問題があれば旧モデルが生きているうちに戻すための余裕です。
⑤1サイクル監視。締め1回分、例外件数・費用・処理時間を週次で見ます。並走期間の数字が比較の基準になる。1サイクル回って基準内に収まれば、変更記録に「完了」と書いて終わり。そのうえで回帰テストセットに、この切替で見つかった不一致の入力を足しておくと、次の切替で同じ確認を繰り返さずに済みます。
月次の運用に組み込む点検項目
受け入れ体制の記事で書いた月次30分の会議に、次の項目を足します。担当は Echo 役と情シスで、FDE が抜けた後もこの表だけで回るようにするのが目的です。所要時間は、慣れれば月に1〜2時間。
| 点検項目 | 確認すること | 情報源 | 担当 | 頻度 |
|---|---|---|---|---|
| 廃止告知の有無 | 使用中のモデルに新しい告知・終了日が出ていないか。ベンダーからのメールを見落としていないか | 各ベンダーの廃止ページ（上の表）、通知メール、Microsoft は Azure Service Health | 情シス | 月次 |
| 使用モデルの棚卸し | 本番で呼んでいるモデル名と版が、変更記録の最新行と一致しているか。日付なしの名前が混ざっていないか | Anthropic は Console の使用状況エクスポート、Microsoft は Models API、そのほかは設定ファイル | 情シス | 月次 |
| 終了日までの残日数 | 使用中の各モデルの終了日（暫定含む）と残日数。60日を切っていたら切替に着手 | 廃止ページの暫定終了日 | Echo 役 | 月次 |
| 回帰テストの実行 | 現行モデルで回帰テストセットを流し、前月と一致率が変わっていないか | 回帰テストセット | Echo 役 | 月次 |
| 例外件数と分布 | 仕訳の例外件数、分類の担当別件数が、前月から大きく動いていないか | 業務側の集計 | 現場担当 | 月次 |
| 費用の実測と再見積 | 実測の使用量×現行単価。四半期ごとに見積を引き直す | ベンダーの請求、価格ページ | Echo 役 | 月次（再見積は四半期） |
| SDK・API の変更 | 更新予定の SDK に、使用中の指定項目の廃止が含まれていないか | ベンダーの移行ガイド、リリースノート | 情シス | 更新前 |
この表で最も効くのは「終了日までの残日数」です。Anthropic のページは稼働中のモデルにも「〜より早くはならない」という暫定の終了日を出しており、Google Cloud と Microsoft は公開日から数える方式なので、告知を待たなくても残日数は計算できる。残日数が60日を切ったら、告知が来ていなくても①新旧並走に入る。これで、告知メールを見落としたときの保険になります。
費用の再見積は、費用の記事で書いた見積書の項目とは別に、稼働後の実測で引き直すものです。本番前の見積は「想定件数×想定トークン×当時の単価」で、3つとも稼働後に変わる。四半期ごとに実測で置き換え、切替のたびに②の差分確認で出た1件あたりの費用で置き換える。経営が月次で見るのはこの1行で足ります。
当社の考え——モデルの寿命を「業務の前提」にする
当社は、モデルの更新と廃止を障害ではなく、業務の前提として扱うべきだと考えています。ソフトウェアの部品としての AI モデルは、公開から1〜2年で廃止される。各社の公式ページに廃止日が書かれている以上、避けられません。避けられないものを障害として扱うと、そのたびに緊急対応になり、担当者が疲れ、FDE が抜けた後に仕組みが止まる。前提として扱えば、月次の点検表の1行と、年に1〜2回の切替手順で済みます。
この記事で書いた5つと切替手順は、着任1週間の記事でいう「データ棚卸し」の延長でもあります。着任時に業務とデータを棚卸ししたのと同じ型で、稼働後はモデルと費用を棚卸しする。棚卸しの主体は FDE から Echo 役に移り、表の項目は変わらない。FDE が本番前に決める5つは、その引き継ぎのために先に用意しておくものです。
モデルの変化そのものは、Claude 仕様変更まとめのように、当社でも3か月に1回の頻度で追い続けています。追いきれない場合は、月次の点検表の「廃止告知の有無」と「残日数」の2行だけでも続けてください。止まる前に気づける確率が、それだけで大きく変わります。
まとめ
本番稼働後の AI は、モデルの提供終了・仕様変更・価格改定・出力の変化で壊れます。告知から終了までの猶予は、Anthropic が60日以上、OpenAI が一般提供モデルで6か月以上、Google Cloud は公開から12か月以上の提供、Microsoft Foundry は公開時に18か月後の終了日が決まり、終了後は旧モデルに戻せない。業務側では、止まる（当日）、変わる（月次の件数で見える）、高くなる（翌月の請求で見える）の3つの症状として現れます。
FDE が本番前に決めるのは、モデルの版の固定、回帰テストセット、切替の判断者（Echo 役）と手順、費用の再見積の頻度、変更の記録の5つ。切替は新旧並走→差分確認→Echo 役の承認→切替→1サイクル監視の順で、告知の週に始めて終了の1か月前に終える。月次の点検表には、廃止告知・使用モデルの棚卸し・残日数・回帰テスト・例外件数・費用・SDK の変更の7行を置く。これを「動かし方」に含めて Echo 役に渡すところまでが、FDE の仕事です。
FDE を募集しています（会計FDE／FDE・業務システム）
経理の月次をAIで本番まで持っていく「会計FDE」（会計士・経理責任者・管理部門経験者）と、要件が固まる前に動くものを出して本番まで運ぶ「FDE（業務システム）」（ITコンサル・PM/PL・情シス出身者）を正社員で募集しています。応募でなくても構いません。まず30分の「キャリア相談」から。採用のお問い合わせフォームに「キャリア相談希望」と書いて送ってください。
稼働中の AI の「モデル切替」と月次点検を、一緒に設計します
使用中のモデルの棚卸し、版の固定、回帰テストセットの作成、切替手順と戻す条件、月次の点検表を、貴社の業務と既存システムに合わせて作ります。すでに稼働している仕組みの「提供終了の告知が来た」「出力が変わった気がする」「費用が見積を超えた」からのご相談も受けています。経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験をもとに対応します。