プレビュー版のモデル（Preview model）には、抗いがたい魅力があります。
安定版よりも速くて安く、時には明らかに高性能なことさえあります。一度うまく動いてしまうと、ついつい「当面はこれで大丈夫だろう」と決めつけ、より刺激的な他の課題へと意識が向いてしまいがちです。
これは、そんな過信が最終的にどのような結果を招いたかについての物語です。
完璧に動いていた Preview model…その最後
私たちは、自社の業務をサポートするために複数の社内用 AI Agent を構築・運用していました。いくつかの特定のタスクにおいて、Gemini の Preview model が安定版よりも優れたパフォーマンスを示しました。Prompt も入力データも同じなのに、出力の一貫性が高く、レイテンシも低かったのです。
そこで、それらのモデルを採用することにしました。
数週間、すべては順調でした。それらの Agent たちはバックグラウンドで静かに動作し、期待通りの仕事をこなしていました。
ところがある日、一斉に応答がなくなったのです。
それはドラマチックな壊れ方ではありませんでした。クラッシュしたわけでも、明らかなエラーメッセージが出たわけでもなく、見た目上は何も「壊れて」いませんでした。リクエストは送信されるものの、レスポンスが返ってこない。最初は、システムのどこかに潜んでいる「昨日まで動いていたのに」という、よくある原因不明の問題の一つに見えました。
ログを確認し、コードを再チェックした結果、原因は拍子抜けするほど単純なものでした。その Preview model のエンドポイントが削除されていたのです。変更履歴（Changelog）では事前に廃止（Deprecation）の通知が出ていたのですが、単に私たちが見落としていただけでした。
モデルの置き換え自体はすぐ終わりました。設定を変更し、簡単な検証を行うだけで、Agent たちは無事に復旧しました。
技術的には些細な修正です。しかしプロセスとしては、私たちが無意識に抱えていた「良くない習慣」が露呈した瞬間でした。
問題はモデルそのものではなかった
問題は、Preview model が不安定だったり危険だったりすることではありません。問題は、私たちがそのモデルを「永続的な依存関係」として扱ってしまったことです。
私たちは、以下の要素の管理については非常に規律を持って取り組んでいます。
- ライブラリのバージョン
- API の変更
- インフラのアップデート
- 価格の改定
しかし、モデルそのものは一種の「グレーゾーン」にありました。一度動いてしまえば、意識の外に追いやられてしまいます。Preview というラベルが明確な警告であるにもかかわらず、そのライフサイクルを能動的に追跡していなかったのです。
Preview model は、ほとんど予告なく消えたり、挙動が変わったり、価格が改定されたりすることがあります。ウォッチしていない限り、それらはすべて不意打ちになります。
障害から学んだ運用の変更
今回の失敗は致命的ではありませんでしたが、回避可能なものでした。そこで私たちは、社内プロジェクトにおける AI 関連の依存管理を見直しました。
具体的な変更点は以下の通りです。
-
週次での Changelog 可視化
n8n を使って主要な AI プロバイダーの Changelog をスキャンし、チームのチャンネルに週次のサマリーを投稿するワークフローを構築しました。内容はあえて退屈なものに限定しています。廃止予定、価格改定、レート制限（Rate limit）、API の変更など。目的は緊急対応ではなく、単に状況を把握することです。 -
モデルのライフサイクルに関する明示的な記録
Preview や Experimental モデルを使用するプロジェクトでは、以下のドキュメント化を必須としました。- なぜそのモデルを選んだのか
- 安定版のフォールバック（代替案）は何か
- 切り替えが必要になった場合、何に影響が出るのか
-
直前の差し替えではなく、早期の評価
廃止が予想されるモデルがある場合、早めに代替案のテストを行います。動かなくなってから慌てるのではなく、パフォーマンス、コスト、そして後続システムへの影響をあらかじめ比較しておくようにしました。
意外な副産物：レート制限の変更を事前に察知
このプロセス変更の副産物は、すぐに現れました。
毎週のアップデートを実際に読むようになったことで、Gemini API の無料枠におけるレート制限（Rate limit）の変更にいち早く気づくことができたのです。以前の私たちなら、タイムアウトが発生し始めてからようやく重い腰を上げていたでしょう。
このケースでは、社内ツールへの影響がないことを事前に確認し、今後の実験に対する計画を調整することができました。「何も壊れなかった」——これこそが、この運用の狙いそのものです。
最後に
今回の件は、ハルシネーション（幻覚）の問題でも、推論（Reasoning）の失敗でもありませんでした。モデルが急に指示に従わなくなったわけでもありません。それは、「以前は動いていた」という問い合わせとして現れ、誰かが退屈なドキュメントの一行に気づいた瞬間に解決するような問題でした。
現実世界のシステムにおける AI 関連のトラブルの多くは、このような姿をしています。地味で、退屈で、そしてソフトウェア工学の最も華やかでない部分——バージョン管理、依存関係の管理、変更の追跡——に完全に紐付いています。
Preview model を使うことは無謀ではありません。それが一時的なものであることを忘れるのが無謀なのです。
もしあなたのシステムが Preview、Experimental、あるいは Early Access とラベル付けされたものに依存しているなら、更新履歴をチェックすることはもはや任意ではありません。それはエンジニアとしての重要な仕事の一部なのです。