生成AIのモデル切り替えに備える設計と分離の考え方
参照したAIgram
目次
概要
生成AIを業務に入れるとき、「どのモデルが一番賢いか」で迷われる方は多いと思います。ただ、実際に問題になりやすいのは、選んだモデルが使えなくなったときに何が起きるかのほうです。
Moonshot AIのKimi K3を巡っては、Anthropicの「Claude Fable 5」を不正に蒸留したのではないかという疑惑が米政府高官から指摘され、モデルの来歴やライセンス、輸出規制の確認と、特定モデルへの依存を減らす構成の必要性が示されました Kimi K3で問われるAIモデル調達のリスク。この記事は確認事項として、モデル変更時に短期間で切り替えられるか、プロンプト・評価基準・ログ・業務データ・外部ツールとの接続が特定ベンダーの仕様に強く依存していないか、モデルを変更した場合の品質低下を測定できるか、を挙げています。
この3点は、事例を並べてみると同じ形に行き着きます。セガは複数の内製ツールが共通で使える「共通AIサーバー」をOllamaなどで開発し、高負荷なAI処理を1カ所に集約しました セガ、Ollamaで共通AIサーバー構築し処理集約。エクサウィザーズは社内開発の「AIフローデザイナー」に「大植のレビュー観点」を設定し、経営会議資料を自動チェックする仕組みを構築して起案者にも開放しました AIフローデザイナーで経営会議レビューを起案者に開放。神戸市はDifyを活用したAI基盤「KOBE AI PORT」で、条例・規則や市会議事録といった独自データを取り込んだ情報検索チャットと、議事録作成・アンケート集計・音声解説生成のアプリケーションを整備しました 神戸市KOBE AI PORTの庁内AI活用。
モデル切り替えに備える設計とは、呼び出し先・評価基準・業務データを、利用する側のツールや業務から分けて持つことです。分けてあれば、モデルが変わっても差し替える範囲が限られます。
モデルの入れ替えは外部要因でも起こる
Moonshot AIは2026年7月16日（中国時間）にKimi K3を発表しました。総パラメーター数2.8兆のMixture of Experts（MoE）型モデルで、すでにKimiのWebサービスやAPIを通じて利用でき、モデルウェイトは2026年7月27日までに公開する方針が示されていました 。
その直後に持ち上がったのが、冒頭の不正蒸留疑惑です。ここで注目したいのは、疑惑の真偽そのものよりも、利用する側が置かれる立場のほうです。記事は、モデル提供企業が制裁や取引規制の対象になれば、APIの停止、クラウド事業者による取り扱い中止、決済や保守の停止といった事態につながり、モデルを利用する企業にも間接的に影響が及ぶ可能性があると指摘しています。
つまり、モデルの入れ替えは自分たちの都合だけで起きるわけではありません。記事も、現時点でそのモデルを利用できるかどうかだけではなく、外部環境の変化によって調達や運用が止まる可能性も考慮しておく必要があるとしています。
- モデルの開発主体と、訓練データに関する説明を確認する
- 教師モデルの利用条件と、モデルウェイトのライセンスを確認する
- 第三者から提起されている知的財産上の問題の有無を確認する
- 提供が止まった場合に、業務のどこが停止するかを整理しておく
呼び出し先を共通サーバーに集約する
では、切り替えやすい形とはどういうものか。セガの事例が分かりやすい形を示しています 。
セガはゲーム開発現場にGPU搭載のパソコンが多数あるという事情を生かし、ローカルLLMの代表的なソフトウェアである「Ollama」などを使って、複数の内製ツールが共通で利用できる共通AIサーバーを開発しました。内製ツールとローカルで動くLLMや音声認識AIとの連携を進めています
。
講演で岳鳴涛エンジニアは、共通AIサーバーの導入により高負荷なAI処理を1カ所に集約しつつツールは軽量なままで使え、サーバー側は常に最新の技術を適用でき、ツール側で特に意識せずにそれらの技術を使えると語っています。
ツール側がモデルを直接呼ばず、サーバーを経由する。この構成では、モデルを更新したり差し替えたりする作業がサーバー側に閉じます。ツールを1本ずつ改修する必要がありません。
呼び出し先を1カ所にまとめておくと、モデルの変更で手を入れる場所も1カ所で済みます。
評価基準を文書化しワークフローへ渡す
呼び出し先を分けても、「何をもって良い出力とするか」が担当者の頭の中にあるままでは、モデルが変わったときに判断がやり直しになります。
エクサウィザーズでは、経営会議資料のレビューを、これまで頭の中にある言語化されていない観点で行っていました。そのため起案者にとっては「どこを見られるのか」が事前には分からず、指摘を受けてから修正する往復や心理的な負担が生じていた可能性がある、と振り返っています 。
そこで、社内開発のワークフロー型LLM「AIフローデザイナー」でワークフローを構築しました。資料を投入すれば、あらかじめ設定した「大植のレビュー観点」に沿って自動でチェックが実行されます。観点の実装は、AIの指摘がずれていると感じたときに「なぜ違うのか」を突き詰めてプロンプトを書き換える反復で進められました。確認の順番を「市場の定義」から「競合との差別化」へと論理構造に沿って整理したり、指摘の粒度をより具体的に落とし込んだりする調整が行われています。
この磨き上げたレビューAIは、経営会議の起案者にも開放されました。現場で自らAIと壁打ちをして、想定される論点や課題を先に解消しておく使い方が想定されています。
- 判断の観点を、担当者の頭の中から取り出して文章にする
- 観点を確認する順番まで含めて、ワークフローに設定する
- 出力のずれを見つけたら、その都度プロンプトを書き換える
- 出来上がった観点を、判断する側だけでなく作る側にも渡す
評価基準を文書として外に出しておけば、それはモデルから独立した資産になります。
業務データを基盤側に置き用途別に使う
3つ目に分けておきたいのが、業務データです。
神戸市の「KOBE AI PORT」は、LGWAN環境から直接アクセスできるポータルとして開発されました。外部ネットワークに接続するパソコンを使わずに通常の業務用パソコンから利用でき、ネットワーク間のファイル移行作業なしに自治体独自ナレッジの共有と活用ができるようになっています 。
情報検索チャットには、条例・規則や市会議事録といった神戸市独自のデータが取り込まれ、条例・規則の該当箇所などを検索できます。同じ基盤の上に、議事録作成、アンケート集計、音声解説生成という業務別のアプリケーションが用意されています。データは基盤側にあり、用途ごとのアプリケーションはその上に載る形です
。
データを使える形に整えること自体も、モデルとは別の作業として成立します。富士フイルムビジネスイノベーションと杉並区の実証実験では、「認識・構造化」AI技術が、形式の異なる行政評価関連文書を施策単位で分解・整理し、共通のデータ構造に変換したうえで、生成AI（行政評価AIエージェント）が内部データと公開データを横断的に分析して評価文案を提案する流れが検証されました 杉並区行政評価を認識・構造化AIで支援。構造化された共通のデータは、その後にどのモデルが処理するかとは切り離して持てます。
用途ごとにモデルを選び分ける
呼び出し先・評価基準・業務データを分けておくと、モデルを1つに絞る必要がなくなります。
Kimi K3の記事も、料金や性能を踏まえて複数のモデルを適材適所で使い分けるマルチモデル構成が潮流となりつつあるとしたうえで、特定モデルが使えなくなった場合の冗長性確保という観点からもその重要性が高まっていると述べています 。
実際の使い分けは、そこまで大がかりな話ではありません。エクサウィザーズの大植氏は、日常的な生成AIの利用にマルチLLM対応の自社サービス「exaBase 生成AI」を使い、並行してGoogleの「NotebookLM」も活用しています。あえて複数のツールを立ち上げるのは、それぞれに得意領域があるからだと説明しています。NotebookLMが「理解」に強いのに対し、AIフローデザイナーは特定の観点に沿って決まったステップで「処理」を走らせるのに適している、という整理です 。
モデルを提供する側も、用途別の選択肢を増やしています。Googleは、AIエージェント向けにトークン使用量を削減し性能を改善したGemini 3.6 Flash、低遅延の大量処理向けのGemini 3.5 Flash-Lite、CodeMenderで脆弱性の検出・検証・修正案作成を担うGemini 3.5 Flash Cyberを公開しました Google Gemini新3モデルでAIエージェントを強化。
- 得意領域が違うことを前提に、用途ごとに使うモデルを決める
- 1つのモデルに全業務を通さず、業務単位で依存先を分散させる
- 提供側の新モデルが増えたときに、差し替え候補として評価する
品質差の測定手段を先に用意する
切り替えられる構成にしたとしても、切り替えた後に品質がどう変わったかが分からなければ、判断できません。Kimi K3の記事が挙げる確認事項のひとつが、まさに「モデルを変更した場合の品質低下を測定できるのか」です 。
測定の手段は、事例の中にすでに出てきています。エクサウィザーズのレビューAIでは、過去の経営会議の資料と照らし合わせながらプロンプトの調整が繰り返されました 。過去の資料と、そのときに出るべき指摘の組み合わせがあれば、モデルを変えた後にも同じ資料を通して結果を比べられます。
神戸市の情報検索チャットは、生成AIの回答に根拠となる参照資料を明示します 。回答の裏づけが示されていれば、回答が変わったときに、どこを見て判断が変わったのかを確認できます。
- 過去の実務資料と、期待する出力の組み合わせを手元に残す
- 回答の根拠が確認できる形で出力させる
- モデルを変更したら、同じ資料を通して結果を比較する
品質を測る材料は、切り替えの前に作っておくものです。切り替えてから用意しても、比べる相手がありません。
結論
Kimi K3の記事は、どのAIが最も優れているかという目先の比較から、予期せぬ外部環境変化や公開停止にも耐え得るAI利用の「仕組み」をどう構築するかという問いへシフトさせる必要がありそうだ、と結んでいます 。そのうえで、切り替えの所要期間、プロンプト・評価基準・ログ・業務データ・外部ツール接続のベンダー依存、品質低下の測定可否を確認事項として挙げています。
ここまでの事例は、いずれも利用する側から実行基盤を分離した構成をとっています。セガは呼び出し先を共通AIサーバーへ集約し 、エクサウィザーズは評価観点をワークフローに設定し 、神戸市はDify基盤に独自データを取り込みました 。
- 呼び出し先をサーバーや基盤に集約し、業務ツールから直接モデルを呼ばない
- 評価基準を文章にしてワークフローに設定し、担当者の頭の中から取り出す
- 業務データを基盤側に置き、用途別のアプリケーションから参照する
- 用途ごとにモデルを選び分け、切り替え後の品質を比較する材料を先に用意する
難しい発想は必要ありません。今使っているモデルがある日使えなくなったとして、どこに手を入れることになるかを一度書き出してみる。手を入れる場所が業務のあちこちに散らばっているなら、そこが分離を進めるべき場所です。