Copilot Studioはさまざまなモデルを提供しています。 これらのモデルタイプは、意図された用途や入手可能性に基づいています。 AIモデルの選択は一度きりの設計決定ではありません。 モデルは導入され、更新され、一般公開され、デフォルトとして選択され、最終的には廃止されます。 あるモデルでうまく機能するエージェントが、同じモデルファミリーのモデルと全く異なる振る舞いをすることもあります。
モデルライフサイクル管理を、すべてのCopilot Studioエージェントの継続的な運用手法として扱いましょう。 モデル変更の発見、候補モデルの評価、廃止準備、影響を受けたエージェントの移行、展開後の品質監視のための繰り返し可能なプロセスを確立します。
エージェントが使用するモデルを変更することは、単なるモデル選択の変更であることは稀です。 新しいモデルは命令をより文字通りに解釈し、ツールの選択を変え、異なる応答長やフォーマットを生成し、遅延を変化させることができます。 各モデル変更を、評価、指導・ツールの改良、承認、導入後の監視を含む移行として計画してください。
基本原則は柔軟性を重視し、保守的に運用し、すべてのアップグレードに評価を含み、 新しいモデルにアップグレードするたびにサイレント回帰のリスクがあります。 すべてのモデル変更を避けることで、退職時に緊急事態が起こることが保証されます。
生産エージェントには以下のライフサイクルを適用します:
- 新モデル、更新モデル、デフォルトモデル、そして廃止モデルを発見しましょう。
- 各モデルに依存するエージェント、環境、所有者、ビジネスプロセスをインベントリ化しましょう。
- 候補モデルを確立した基準値と比較して評価します。
- 文書化された品質および運用基準を用いて移行を承認すること。
- 組織のアプリケーションライフサイクル管理(ALM)プロセスを通じて展開します。
- 生産結果を監視し、新たに発見されたシナリオを回帰分析スイートに追加します。
- モデルやエージェントの要件が進化するにつれて、このプロセスを繰り返します。
この記事は発見と在庫管理について扱っています。 シリーズは続きます:
- AIモデルのアップグレードタイミングを決める:アップグレードの決定、前提条件、退職への対応。
- モデル移行を実行し検証する:評価、承認、展開、監視。
モデルライフサイクル管理には、エージェントオーナー、メーカー、プラットフォーム管理者、テスター、セキュリティおよびコンプライアンスチーム、リリース承認者間の調整が必要です。 モデル変更で緊急の移行が発生する前に所有権を割り当てましょう。
モデルの状況を理解する
モデル変更を計画する前に、Copilot Studioがどのようにモデルを分類しているか、組織が実際に使用できるモデル、そしてそれぞれに依存するエージェントについて知っておく必要があります。
モデルリリースの種類を理解する
Copilot Studioは、リリースおよび可用性の分類でモデルを識別します。 これらの分類は、モデルをどのように統治し、どこで使用するかを決定するのに役立ちます。 モデル名、リリース段階、地域の入手状況、引退状況は時間とともに変化します。 常に 地域ごとのモデルの利用可能性 を確認し、静的なモデルリストに頼らず、最新の情報を確認してください。
デフォルトモデルを使うエージェントは、デフォルトモデルがアップグレードされるたびに新しいモデルに移行します。計画していたかどうかに関わらずです。 高リスクで大量のエージェントの場合は、デフォルトを追跡するのではなく特定のモデルを選択し、すべてのモデル変更が移行プロセスを経るようにしましょう。
Warnung
実験モデルやプレビューモデルは、可用性が限られ、応答品質にばらつき、遅延やメッセージ消費量の違い、タイムアウト、地域ごとにデータ処理の考慮事項がある場合があります。 Copilot Studioは制作エージェントにはおすすめしません。 プレビューや実験モデルを使ったエージェントを公開し、ユーザーがそれとやり取りしても、その利用は設定された料金で請求されます。
モデル使用カテゴリをエージェントの目的に合わせて調整してください
Copilot Studioは各モデルに、そのモデルが最適化されている用途を記述する使用カテゴリをタグ付けします。 エージェントのワークロードに適したカテゴリーを選ぶことは、品質、遅延、クレジット消費に影響を与えます。
- Deep:意図的で多段階的な推論とツールサポートワークフローに最適化されています。 複雑な分析、ポリシー分析、ドキュメント統合に最適です。 最も高いレイテンシーとクレジット消費を伴います。
- Auto:クエリを動的にルーティングすることで混合ワークロードをカバーします。 予測不能または多様なクエリの複雑さを持つヘルプデスクや従業員エージェントに最適です。 レイテンシとコストはターンごとに異なります。
- 一般:日常チャットの速度とコストに最適化され、軽いグラウンディングを行っています。 ドラフト作成、要約、FAQスタイルの回答、簡単なアクション自動化に最適です。 最も低いレイテンシとクレジット消費。
モデル 利用カテゴリで詳しくはこちらをご覧ください。
Important
最も一般的なアップグレードミスは、使用カテゴリの不一致であり、例えば大量のFAQエージェントを 一般的な モデルから ディープ モデルに移してしまい、ディー プ モデルの方がスコアが高いためです。 回答の質はわずかに改善される一方で、遅延やクレジット消費は急激に増加します。 この変更はユーザー体験とコストの純後退です。
外部モデルと管理者のコントロールを理解する
Anthropic、xAI、Mistralなどの外部プロバイダーのモデルをエージェントの主要モデルとして使うことができます。 詳細については、「 プライマリ AI モデルとして外部モデルを選択する」を参照してください。
管理者設定は、環境内でメーカーが選択できるモデルを制御します。 利用可能なとドキュメント化されたモデルでも、必要な設定がオンになっていなければ移行するエージェントには利用できない場合があります。
| 管理者設定 | モデルの利用可能性への影響 |
|---|---|
| プレビューと試験的な AI モデル | メーカーが環境内でプレビューモデルや実験モデルを選択する前にオンにしてください。 |
| 地域間でのデータ移動 | クロスジオモデルには必須です。 テナント管理者はPower Platform管理センター内のこの環境レベルの設定を管理します。 |
| 外部モデル | 環境または環境グループの外部プロバイダーを起動します。 また、Microsoft 365 管理センターで各プロバイダーへのアクセスを個別に許可する必要があります。 この要件により、外部モデルは2つの独立した管理者アクションを必要とする唯一のクラスとなります。 |
Note
プレビューモデルと実験モデル、外部モデルは別々の設定で管理されます。 一方のタイプを有効にしても、もう一方のタイプは有効になりません。 管理者はプレビューや実験モデルを許可しつつ、外部モデルはブロックするか、その逆も可能です。
移行を計画する前に、候補モデルがターゲット環境でメーカーに利用可能かどうかを確認してください。 Copilot Studioのモデルリストは管理者の設定を反映しており、特定のエージェントが使えるものの現実的なものです。 AI モデル選択の管理者管理について詳しく学びましょう。
モデルの入手可能性を定期的に確認します
エージェント のために定期的に主要なAIモデル を見直しましょう。 現在のモデルリストの権威ある情報源です。 新しいモデルは導入時にそこに現れ、既存モデルは一般に入手可能になったり、デフォルトになったり、引退したりと更新されます。
以下の資料を組み合わせてご利用ください:
| 情報源 | 説明 |
|---|---|
| エージェントのために主要なAIモデルを選択してください | モデルの入手可能性や新モデル導入の主要な情報源:モデル名、使用カテゴリタグ、リリースタグ、地域ごとの可用性、クロスジオフラグ、引退状態、米国政府のクラウド利用可能性、管理者制御。 |
| Copilot Studioのモデルリスト、エージェントの概要ページにあるモデル一覧 | 管理者の設定に基づいて、環境内の特定のエージェントが実際に利用できるものは何でしょうか。 |
| 引退したAIモデルの使用を続けてください | 引退したモデルの互換性ウィンドウの仕組みと、それを有効にする方法について。 |
| Microsoft 365メッセージセンターおよびPower Platformの管理者通知 | 入居者をターゲットにした変更や退職通知。 |
| Copilot Studioのリリース計画とCopilot Studioの新要素 | 先を見据えたモデルと能力ロードマップ。 |
| 早期リリースサイクル環境 | プラットフォームやモデルの変更がビジネスクリティカルな環境に到達する前に検証を進めましょう。 |
| Copilot Studioのクレジットと収容人数を管理する | テナントが何を使い、どの消費量で、モデルごとに判断してください。 |
| モデルプロバイダーアップグレードガイダンス | モデル世代間の挙動変化とそれに対応するプロンプトの変更。 |
また、以下の場合にレビューをトリガーしてください:
- 関連するモデルがプレビューまたは一般公開で利用可能になります。
- デフォルトのモデルが変わる。
- モデルの引退または自動アップグレードが発表されます。
- 組織の地域でモデルが利用可能になります。
- この組織はクロスジオ処理、外部モデル、プレビューおよび実験モデルを可能にします。
- 生産監視は、品質、遅延、信頼性、消費に関する懸念を特定し、他のモデルが対応できるものを特定します。
モデルとエージェントの在庫を管理しましょう
Power Platform管理センター、Power Platform CLI、またはPower Platform APIで提供されているエージェントインベントリを使って、特定のモデルを使用しているエージェントを特定しましょう。 この情報を活用して、影響を受ける企業や技術オーナーとのモデルライフサイクルコミュニケーションを開始しましょう。
Power Platform管理センターで以下のいずれかの表示をご利用ください:
| Power Platform管理センタービュー | 使用方法 |
|---|---|
| なんとか>Copilot Studio>モデル列 | テナント全体のエージェントを確認し、それぞれのエージェントに設定されたモデルを特定します。 結果をフィルターまたはエクスポートして、退職予定のモデルを使用しているエージェントを見つけてください。 |
| ライセンス>Copilot Studio>環境>メッセージ消費詳細>LLMモデル列 | 環境を選択し、LLMモデルごとのメッセージ消費をレビューします。 このビューを使って、廃止モデルに関連する環境、エージェント、最近の消費状況を特定しましょう。 |
モデル別にエージェントを探すためにインベントリAPIをクエリしてください
Power Platform管理センターのビューは、結果を手動で確認・エクスポートするのに効果的です。 同じ情報をプログラムで収集したいときは、代わりに インベントリAPI をクエリしてください。そうすればエージェントの列挙はスクリプト化され、スケジュールされ、テナント全体で繰り返し処理され、レポートを手動でダウンロードするのではなくなりましょう。 大規模なエージェント資産を持つ組織は、退職移行時に影響を受けたエージェントリストをオンデマンドで更新し、ライフサイクルイベント間で最新に保つことができます。
インベントリAPIは、エージェント名、表示名、環境、設定済みモデルを単一のテナント全体のクエリで返すため、他のデータソースとの相関は必要ありません。
クエリを実行する前に:
- Power Platform管理者またはDynamics 365管理者の役割を持つアカウントでサインインしてください。
-
https://api.powerplatform.com/リソースのアクセストークンを取得してください。 - 入居者向けの エージェント在庫 が有効になっているか確認してください。
リソースクエリエンドポイントにPOSTリクエストを送信し、 microsoft.copilotstudio/agents リソースタイプでフィルタリングし、必要なフィールド(以下 properties.model)を投影します。
POST https://api.powerplatform.com/resourcequery/resources/query?api-version=2024-10-01
Authorization: Bearer <access-token>
Content-Type: application/json
{
"TableName": "PowerPlatformResources",
"Clauses": [
{
"$type": "where",
"FieldName": "type",
"Operator": "in~",
"Values": ["'microsoft.copilotstudio/agents'"]
},
{
"$type": "project",
"FieldList": [
"name",
"properties.displayName",
"properties.model",
"environmentId = tostring(properties.environmentId)"
]
}
],
"Options": { "Top": 200 }
}
レスポンスはエージェントごとに1つのレコードを返します。 応答のフィールド名はドットの代わりにアンダースコアで表示されるため、 properties.model は properties_modelとして返されます。
{
"totalRecords": 158,
"count": 200,
"data": [
{
"name": "00000000-0000-0000-0000-000000000000",
"properties_displayName": "Sample Agent",
"properties_model": "GPT-5 Auto",
"environmentId": "00000000-0000-0000-0000-000000000000"
}
]
}
応答には totalRecords が含まれ、結果を切り落とすと skipToken 値が加わります。 その値を返して返 Options.SkipToken 、すべてのレコードが取得されるまでリクエストを繰り返します。
収集された記録をご properties_model ごとにまとめて、テナント全体で各モデルがどこで使われているかを見極めます。 以下の例は、Copilot Studioのデフォルトモデルを使用しているか、Microsoft 365 Copilot体験で動作するエージェントを除き、モデルごとのテナントごとのエージェント数を示しています。
Model Count
----- -----
Claude Sonnet 4.6 24
GPT-5 Chat 22
GPT-5.5 Chat 5
GPT-5 Auto 4
Claude Sonnet 4.5 3
Claude Opus 4.6 2
Claude Opus 4.7 1
Claude Opus 5 1
Claude Sonnet 5 1
GPT-4o 1
GPT-5.6 Reasoning 1
リタイアメントが発表された際、リタイアモデル上の同じ結果セットをフィルタリングし、影響を受けたエージェント、その環境、エージェントIDのリストを作成します。
environmentId値を使って各エージェントを名前付き環境にマッピングし、その結果をその環境の所有者にルーティングします。 詳細な退職対応については「 モデル退職への対応 」をご覧ください。
詳細については、以下を参照してください。
環境スコープの詳細はPower PlatformのCLIを使いましょう
単一の環境でエージェントとソリューションコンテキストが必要な場合、例えば一つの環境での移行準備時に pac copilot list を活用してください:
pac copilot list --environment <environment-id-or-url>
コマンドはエージェント名、Copilot ID、コンポーネント状態、管理ステータス、ソリューションID、ステータスコード、ステートコードを返します。 この出力にはモデルは含まれていないため、在庫APIを使ってモデルごとにエージェントを識別してください。
pac admin listを使って環境名やIDを取得してください。
各エージェントごとに何を記録すべきか
モデルだけでは移行計画を立てるには不十分です。 各エージェントごとに以下の内容を記録し、退職発表時に誰に連絡すべきか、どのエージェントが必要な仕事かを把握できるようにしましょう。
- エージェント名、エージェントID、環境、そして開発、テスト、本番環境 などの環境タイプ。
- ビジネスの重要性。
- 事業主、技術者、テスター、リリース承認者。
- 構成モデルとそのリリースタグ。
- エージェントがデフォルトのモデルを使うのか、特定の選択モデルを使うのか。
- クロスジオ処理の要件と地域別制約。
- エージェントが標準ハーネスで動作しているのか、GitHub Copilot ハーネスで動作しているのか、評価テスト方法を決定するかを判断します。 「 ハーネスを選ぶ」で詳しく学びましょう。
- 回帰テストセットの場所と最後のベースライン実行の日付。
- 引退したモデルの窓が使用されているかどうか、いつ期限切れか、そして誰がそれを承認したのか。
次のステップ
モデルの状況を理解し、エージェントの在庫が整ったら、意思決定基準を使ってアップグレードが必要かどうかを判断しましょう。