2026年9月の第一週に、AnthropicがClaude 5.1（9月1日）、GoogleがGemini 3.8 Flash（9月2日）、OpenAIがGPT-6 Astra（9月3日）とほぼ3日連続で主要モデルをリリースした。この週、社内で「で、結局どれ使えばいい？」という質問が何度か来た。
そのとき気づいたのは、質問の立て方が変わったということだ。以前は「一番性能の良いモデルはどれか」という問い方が多かった。今は「どの業務にどのモデルが適しているか」に変わってきている。この変化は、企業でのAI基盤の評価軸が変わってきたことを映している。
この記事で分かること：
- 2026年秋の主要モデル一斉更新後、大企業のAI基盤選定で変えた4つの評価軸
- Copilot Studio・Dify Enterprise・Power Automateを使っている立場からの、モデル選択の実際
- 企業環境でのマルチモデル戦略の考え方
対象読者：大企業でAI・デジタル化推進を担当している方。複数のAIモデルやプラットフォームを比較検討している方。個人的な実感を中心に書くので、技術比較としてよりも「導入担当者の判断の視点」として読んでほしい。
「どのモデルが一番か」という問いが変わった理由
3日で3社が主要モデルをリリースする、という状況は今回が初めてではない。ただ、今回が「ベンチマーク数値の更新」だけに留まらなかったのは、それぞれのモデルが既存のエンタープライズ製品と深く統合されていたからだと思っている。
- Claude 5.1：AnthropicのAPIとClaude Code経由で、Difyのエージェント・パイプラインが直接使う。Claude Codeの自動実行環境も当然このモデルへのアップグレードの影響を受ける
- Gemini 3.8 Flash：Google WorkspaceのCopilot相当機能（Gemini for Workspace）が強化され、組織としてGoogleスイートを使っている場合はモデル変更が半自動で来る
- GPT-6 Astra：Azure OpenAI ServiceのモデルラインナップにGPT-6が加わることで、Copilot StudioやAzure AI Studioで使えるモデルの選択肢が変わる
この3つは単体のAPIとして使うだけでなく、既存の業務システム・ワークフローと統合された形で動いている。モデルが変わると、プロンプトの挙動が変わり、RAGの品質が変わり、API単価が変わる。「どのモデルが一番か」という問いより「今使っているフローに何が起きるか」という問いの方が実務的になってきた。
変えた4つの評価軸
1. ガバナンス——モデルが変わったときの通知と制御ができるか
これまでのモデル選定ではキャプチャできなかった観点が「ガバナンス」だ。具体的には「どのワークフローがどのモデルバージョンを使っているか」を把握できるか、という問いになる。
大企業でAIを使い始めると、いつの間にか多数のフローがAIに依存するようになる。そこでモデルのバージョンが変わると（あるいは廃止されると）、影響を受けるフローを特定するのが難しくなる。
Copilot Studioでは、どのエージェントがどのモデルを使っているかを一覧できる管理機能が強化されてきている。Dify Enterpriseでも、フロー設定のバックアップ・エクスポートと、モデルプロバイダーの設定の分離が整備されてきた。
評価軸として加えたのは「モデルバージョン固定ができるか」「廃止通知の仕組みがあるか」「影響を受けるフローの一覧を出せるか」の3点だ。これが弱いプラットフォームは、モデル更新のたびに想定外のフロー挙動の変化が起きるリスクが高い。
2. マルチモデル前提の設計——1社のモデルに依存しない構成にできるか
2026年9月の1週間に3社がリリースした、という状況は、今後も続く。そうなると「1社のモデルに全フローを依存させる」構成は、コスト・性能・リスクの面で不安定になる。
自分の現場では、目的別にモデルを使い分ける方向に設計を変えた：
- 定型の文書処理・要約：コスト重視で、精度よりも速度・単価のバランスが取れたモデルを選ぶ。Claude 3系やGemini Flash系
- 複雑な推論・設計の相談：能力重視で、最新の主力モデルを使う。Claude 5系・GPT-6系
- コード生成・技術タスク：Claude Codeの実績を参考に、コード関連はAnthropic系が安定している印象がある
Dify Enterpriseはモデルプロバイダーをプラグイン形式で追加できる構成なので、新しいモデルが出たときにプロバイダーを追加して切り替えやすい。Copilot StudioはMicrosoftのモデルラインナップに基本的に縛られるが、Azureモデルカタログの範囲が広がってきているため、選択肢は増えつつある。
「どのモデルでも動く設計」を目指すより「切り替えるときのコストが低い設計」の方が現実的だと感じている。具体的には：プロンプトにモデル固有の文法を入れない、レスポンス形式（JSON/Markdown）に一貫性を持たせる、モデルを変えたときの出力の差分をテストできる仕組みを持つ。
3. コスト設計——入力・出力トークン数の見積もりを事前に持つ
新しいモデルが出るたびに、価格も変わる。GPT-6・Gemini 3.8・Claude 5.1のリリースに合わせて、API単価の見直しが行われた。
大企業でAI活用が広がると、API費用が想定外に膨らむことがある。自分の現場で重要視するようになったのは「1リクエストあたりの平均トークン数」の把握だ。
Difyのフロー実行履歴には、各ステップのトークン消費量が記録される。これを定期的に集計することで、モデルが変わったときの単価との掛け算で費用の変化を試算できる。「新しいモデルの方が性能が良い」という理由だけでアップグレードすると、入出力トークン数がモデルによって変わるため、費用も予測なしに変動する。
注意：API単価と入出力トークン数の積がコストになるが、モデルによって「同じプロンプトに対する出力長が変わる」ことがある。高性能なモデルほど詳細な回答を返す傾向があり、これが出力トークン数の増加に直結する。コスト試算は必ず「この出力量を生み出すモデル」で試算する必要がある。
4. 移行コスト——モデルを変えたときの検証コストを見積もれるか
「モデルAからモデルBに変えたい」となったとき、何を確認しなければならないかがあらかじめリストアップできるか、という観点だ。
移行時の主なチェックポイント：
| チェック項目 | 確認内容 |
|---|---|
| プロンプトの挙動 | 同じプロンプトで、出力の品質・形式が変わっていないか |
| レスポンス形式 | JSONや特定フォーマットの出力が正しく得られているか |
| トークン上限 | コンテキストウィンドウのサイズが変わっていないか |
| 処理時間 | 本番でのレイテンシが許容範囲内か |
| 費用 | 実際の使用量での費用変化 |
Dify Enterpriseではフローのエクスポートとステージング環境が使えるので、本番と同じ入力データで新モデルの挙動を先に確認できる。Copilot Studioは今のところ同等の「ステージング環境」機能が弱いため、小規模なフローから切り替えてモニタリングする段階的アプローチを取っている。
移行コストが大きいほど「最新モデルに追随するメリット」が相対的に下がる。「新しいモデルが出たら即アップグレード」より「6か月ごとに主要フローを見直す」サイクルの方が、大企業の管理工数に合っていると感じている。
モデル評価で変わらなかった観点
変えた4つを書いてきたが、変わらなかった観点も明示しておく。
セキュリティ・データ取り扱いの方針確認は変わらない：どのモデルを使う場合でも、入力データがモデル学習に使われないか、データが特定のリージョンに保存されているか、GDPR・国内法令への対応状況を確認するプロセスは変わっていない。新しいモデルが出ると改めてプライバシーポリシーの確認が必要になる。
ベンチマーク数値だけで判断しない原則も変わらない：MMLU・HumanEvalなどのベンチマークスコアは参考にするが、「自社の実際のユースケースで試した結果」を最優先にする原則は維持している。ベンチマークと現場の体感が乖離することは珍しくない。
自分の現場での現状
2026年秋時点での自分の環境の整理：
- Copilot Studio：Microsoft提供モデル（GPT-4o系・Azure OpenAI）を使用。GPT-6の組み込み時期を確認中
- Dify Enterprise：Claude 5系を主力に使用。Gemini 3.8 Flash Liteをコスト最適化が必要な処理に試験導入中
- Power Automate：AIビルダーのモデルバージョンはMicrosoftが管理するため、自動で更新される。影響範囲のモニタリングを定期的に実施
正直なところ、3社がほぼ同時にリリースすると、評価が追いつかない。「まず今使っているものの挙動が変わっていないかを確認する」が最初の作業になっている。新機能への対応は、その後だ。
この記事で確認できていないこと
今回書いた内容は自分の現場での経験・判断に基づくもので、以下は確認できていない点として記しておく：
- Gemini 3.8 FlashをDify Enterpriseに組み込んだときの挙動（まだ試験導入段階）
- GPT-6 AstraのAzure OpenAI Serviceでの提供開始日程（2026年10月24日時点で未確認）
- マルチモデル構成のコスト最適化については、別の記事で具体的な数値とともに報告する予定
関連記事：Dify Enterpriseの社内AI基盤設計の考え方について → https://note.com/light_tern636/n/n420a39eb7475