「移行先が案内されている」は使い続けられる保証ではない｜非推奨告知の読み方

利用しているAIモデルに「このモデルは2026年○月○日で提供を終えます。代わりに△△をお使いください」という告知が出たとき、読み手は2つの情報を同時に受け取ります。終わる日と、次に使うものです。

最初は、この2つは同じ重さの情報だと思っていました。どちらも同じ表に並び、同じ告知の中にあります。しかし提供終了の告知と、その実施の告知を並べて読むと、片方だけが動いていました。終わる日は動かず、次に使うものの案内が別の版に替わっていました。

先に、扱わない範囲を置きます。本記事は特定の製品やベンダーの評価をしません。どのモデルが優れているかという比較も扱いません。扱うのは、非推奨の告知という文書が、何を約束していて何を約束していないかだけです。

本記事が立てる仮説はこれです——移行先が書かれていることで「連続性が保証された」と読んでしまうのは、告知が1つの表の形で提示されるからではないか。表の左列と右列は対になって見えますが、片方は日付の約束で、もう片方はその時点の案内です。

30秒で要点

• 同じ6モデルの提供終了について、告知の投稿と実施の投稿で案内された移行先が別の版になっていた
• 一致していたのは対象モデルと提供終了日。食い違ったのは移行先の案内だけである
• 後の投稿が挙げた版は、最初の告知日より後に出たものだった。どちらの投稿も、それぞれの公開日時点では整合している
• 「ページが書き換えられた」とは書けない。 確認できるのは2つの投稿が違う内容を示していることまで
• 「削除に利用者の対応は不要」と「代替モデルへのアクセスを有効にする必要がある場合がある」は、同じ投稿に両方書かれている

告知の投稿と実施の投稿で、移行先が違っていた

参照するのは、GitHub Changelog の2つの投稿です（いずれも2026年10月31日に確認）。

1つ目は Upcoming deprecation of selected GitHub Copilot models in mid-October（公開日 2026年9月18日）。6つのモデルを2026年10月19日付で提供終了すると告知し、それぞれに「推奨される代替（Suggested alternative）」を示しています。影響範囲は Copilot Chat・インライン編集・ask および agent モード・コード補完を含むすべての Copilot 体験、と書かれています。

2つ目は GitHub Copilot models deprecated on October 19, 2026（公開日 2026年10月19日）。本文は、この提供終了が「2026年9月18日に告知されたもの」であることを明記しています。対象の6モデルも終了日も、1つ目と一致します。

一致していないのは、代替として示された版です。同日（2026年10月31日）に両ページを取得して、表の文字列を照合しました。

表が収まらない場合は、横にスクロールできます

6行のうち5行で、右列の版が違います。これは取得したタイミングによる読み取りの差ではありません。 同じ日に両方を開いて並べた結果です。

もう1点、細かいようで性質の違う差があります。影響範囲の表現が、9月18日の投稿では "all"、10月19日の投稿では "most" になっています。

どちらの投稿も、それぞれの公開日時点では筋が通っている

ここで気をつけたいのは、この食い違いを「誤り」として読まないことです。

OpenAI の GPT-6.1 Sol の紹介ページ（2026年10月31日に確認）には、GPT-6 Sol と GPT-6 Luna について "Sep 22, 2026"、GPT-6.1 Sol について "Sep 29, 2026" という日付が記されています。本文は GPT-6.1 Sol を GPT-6 Sol のアップグレードと説明しており、順序もこの日付と整合します。

この2つの日付は、いずれも最初の告知日である9月18日より後です。つまり9月18日の時点で、GPT-6.1 Sol はまだ世に出ていません。その日に書ける代替は、その日に選べるものだけです。

そして10月19日の投稿は、実施の時点で選べるものを示しています。こちらも、その日時点では筋が通っています。

どちらのページも、公開された日においては整合しています。 旧い版を誤って書いたという話ではありません。

そのうえで、確認できていないことを明示します。9月18日のページが後から更新されたかどうかは分かりません。 2026年10月31日時点のそのページは依然として GPT-5.6 系を示しており、10月19日のものは別の投稿です。本記事が確認できたのは、2つの投稿が異なる代替を示していることと、後の投稿が挙げた版が最初の告知日より後に出たものであることの2点だけです。更新の有無も、意図や過失も、この材料からは分かりません。

ここから言えるのは、告知の中で情報の性質が違うということです。

• 対象モデルと提供終了日：2つの投稿で一致していた。実施の予定として扱える
• 代替の案内：2つの投稿で食い違った。その投稿が書かれた時点の案内として扱うのが実態に近い

「対応は不要」と「設定が必要な場合がある」は両立する

10月19日の投稿には、運用上の補足が2つ並んでいます。

1つは、非推奨モデルの削除に利用者側の作業は不要（"No action is required to remove the deprecated models."）という記述です。

もう1つは、Copilot Enterprise の管理者は、代替モデルへのアクセスを Copilot 設定のモデルポリシーで有効にする必要がある場合があるという記述です。利用できるかどうかは、当該モデルについてポリシーが有効になっているかを確認すればよい、と続きます。

この2つは矛盾していません。消えるものを消す作業は不要だが、代わりを使えるようにする作業は必要な場合がある、という構造です。ただし読み手が「対応不要」の一語だけを拾うと、後者が落ちます。

なお、これは Copilot Enterprise についての記述です。個人向けのプランに同じ操作が必要だとは書かれていません。

告知から終了までの間隔は、短く繰り返されている

同種の提供終了は1回限りの出来事ではありません。GitHub Changelog には、別の Upcoming deprecation of selected GitHub Copilot models という投稿もあり、同じ形式で別のモデル群の提供終了が告知されています。

ただしこの3本目は、単独の根拠には使いません。 URL のスラッグに含まれる日付と、本文に表示されている公開日が一致しておらず、どの告知のページを読んでいるのかを確定できなかったためです。この不一致は、2026年10月31日の確認で再現しました。

このページから受け取るのは、告知から提供終了までの間隔が約1か月という水準で繰り返されているという傍証までです。個別の版数や日付は主張に使いません。

約1か月という間隔自体は、妥当か不当かを言える材料がありません。言えるのは、その期間のあいだに、案内される代替が入れ替わる余地があるということです。実際に入れ替わった例が、先ほどの表です。

確かなことと、この記事で踏み込んでいないこと

確かなこと：9月18日の投稿が6モデルの提供終了を2026年10月19日付で告知していること、10月19日の投稿が同じ告知の実施であると明記していること、2つの投稿で対象と終了日が一致し代替の版が食い違っていること、影響範囲の表現が "all" と "most" で異なること、代替として挙がった版の日付が最初の告知日より後であること、削除に対応不要という記述とモデルポリシーの設定が必要な場合があるという記述が同じ投稿に並んでいること。これらはいずれも、2026年10月31日に確認した上記のページに書かれています。

踏み込んでいないこと：

• ページが後から更新されたかどうか。確認していません
• GitHub や各ベンダーの意図・過失。材料がありません
• Grok や Gemini の各版が世に出た日付。各社の一次情報を開いていないため、GitHub のページに書かれていた文字列としてのみ扱っています
• 提供終了によって利用者側に生じた具体的な支障。それを示す情報源を持っていません
• 製品としての優劣。本記事は告知文書の読み方を扱っており、どのサービスを選ぶべきかという話はしていません

ベンダーの発表のどこまでを契約判断に使えるかという一般論はベンダー発表のどこまでを契約判断に使えるかに、移行の費用そのものの見積もりはスイッチングコストとベンダーロックインとは？に整理があります。

判断軸：告知を「期限の情報」と「時点の案内」に分けて読む

ここまでの整理から導かれる判断軸は1つです——非推奨の告知を受け取ったら、期限の情報と時点の案内を分けて記録する。

分け方は単純です。

• 期限の情報：対象と終了日。2つの投稿で一致していた部分であり、計画の起点にできる
• 時点の案内：代替の提示。読んだ日付とセットで記録し、実施日が近づいたら読み直す対象にする

この軸が効くのは、読み手の側に理由があるからです。告知は1つの表として提示されます。左列に消えるもの、右列に代わりのもの。表の形は、左右が同じ確からしさで対になっているように読ませます。 時刻表や料金表と同じ見た目だからです。しかし実際には、左列は決定事項で、右列はその日の状況の写しです。

実務の記録に落とすと、違いはここに出ます。

• ❌ 「2026年10月19日に提供終了。代替は□□に決定」
• ✅ 「2026年10月19日に提供終了（確定）。代替の案内は9月18日時点で□□（要再確認）。実施日の2週間前に告知ページを再読」

後者は、再読の予定が記録に残ります。前者は、□□を前提に組んだ検証計画が、知らないうちに別の版を指すことになります。

移行先が替わること自体は、必ずしも不利益ではありません。より新しいものが案内されているなら、利用者にとって好ましい場合もあります。問題になるのは、替わったことを知らないまま、替わる前の前提で計画を組んでいる状態です。

最小検証：告知ページを最後に読んだ日付を1件書き出す

次の手順を1回だけ実行すると、この論点が自分の運用に当てはまるかが分かります。

1. 現在依存しているAIモデル・APIを1つ選ぶ（本番で使っているもの、または見積もりの前提に入っているもの）
2. その提供終了・非推奨に関する告知ページを最後に読んだ日付を記録から探す
3. 見つかったら、同じページをいま開いて、代替の案内と期限を突き合わせる
4. 記録が見つからない場合は、それ自体が結果です。いま読んで、今日の日付とともに記録する

ここで数えたいのは、差分の有無ではありません。「最後に読んだ日付」を答えられる依存が何件あるかです。分母は依存しているモデル・APIの数、分子は日付を答えられたものの数。この比率が低いほど、移行の計画は、いつの時点の案内に基づいているかが分からない状態になっています。

1件で足ります。1件で日付が出てこなければ、他も同じ状態である可能性が高くなります。

告知を読むときに立ち返る問い

非推奨の告知を前にしたときに立ち返りたいのは、「この文書のどこが、日付の約束なのか」という問いです。約束の部分は計画に使えます。それ以外は、読んだ日とセットで持っておく情報です。

もう1つは、「この案内を最後に読んだのはいつか」という問いです。同じページでも、読んだ時点によって内容が違いうることが分かっていれば、日付のない記録は未完成だと分かります。

終わる日は決まっています。次に使うものは、その日になってみないと分かりません。この2つを同じ強さで信じると、計画のほうが先に壊れます。

参考資料・引用元

• Upcoming deprecation of selected GitHub Copilot models in mid-October — GitHub Changelog（公開日 2026年9月18日。2026年10月31日確認）
• GitHub Copilot models deprecated on October 19, 2026 — GitHub Changelog（公開日 2026年10月19日。2026年10月31日確認）
• Upcoming deprecation of selected GitHub Copilot models — GitHub Changelog（スラッグの日付と本文の公開日が一致しないため、間隔の傍証としてのみ参照。2026年10月31日確認）
• Introducing GPT-6.1 Sol — OpenAI（ページ本文に記された日付の確認に使用。2026年10月31日確認）