1. 主要ページへ移動
  2. メニューへ移動
  3. ページ下へ移動

QES ブログ

記事公開日

【Copilot Studio】多言語対応エージェントの応用テクニック(後編)

  • このエントリーをはてなブックマークに追加

この記事のポイント

Microsoft Copilot Studioで、プロンプトだけによる多言語対応の限界と、発言内容から言語を自動判定してフォールバック対応する応用テクニックを検証します(2026年8月時点の検証結果、前編の続編)。

  • プロンプトだけでは不安定:
    セカンダリ言語を設定せず指示文だけで多言語対応させると、生成回答の言語追従は20回中8回程度(再現性40%)にとどまり、固定メッセージは追従しない
  • 言語自動判定で応用範囲を拡張:
    発言内容から言語を判定するトピックを組めば、セカンダリ言語として追加していない言語にも、プライマリ言語へのフォールバックという形である程度対応できる

こんにちは!DXソリューション営業本部の近藤です。

前編では、Copilot Studioで多言語対応のエージェントを作る基本手順と、テスト時に気づいた「あいさつと回答の言語がずれる」という注意点をご紹介しました。
後編となる本記事では、もう一歩踏み込んで、プロンプトだけで多言語対応させた場合の挙動と、発言内容から言語を自動判定してセカンダリ言語未設定の言語にも対応させる応用的な方法を検証していきます。

※前編(エージェントの作成方法とセカンダリ言語のローカライズ手順)をまだご覧でない方は、先にそちらをご確認いただくとスムーズです。

発展編:プロンプトだけで多言語対応できる?

先に結果をお伝えすると、セカンダリ言語を設定せず、指示文(プロンプト)だけで多言語対応させようとすると、生成回答の言語追従は20回中8回程度(再現性40%)にとどまり、あいさつなどの固定メッセージは一度も入力言語に追従しませんでした。

Microsoft公式のリリースノートには「生成回答は会話言語に自動適応する」という記述があり、これを根拠に「セカンダリ言語の設定なしでも、指示文だけで多言語対応できるのでは」という仮説を立てて試してみました。
セカンダリ言語(英語)を一度削除し、指示文だけの状態で英語の質問を20回試行した結果は次のとおりです。

英語で追従(成功)
8 / 20回
日本語のまま(未追従)
12 / 20回
 

試行順(1〜20回目):日・英・日・日・英・英・英・日・英・日・日・日・日・英・日・日・日・日・英・英

結果は20回中12回が日本語、8回が英語という、成功率40%程度の不安定なものでした。
固定メッセージについては、セカンダリ言語を設定していない状態では、何度試しても常に日本語のままでした。

なぜプロンプトだけでは不安定になるのか:
生成回答は生成AIがそのつど文脈から言語を判断して出力しているため、明示的な言語設定がない状態では判断がぶれやすいと考えられます。
筆者の検証環境ではこの結果でしたが、モデルやプロンプトの書き方によって再現性は変わる可能性があります。
本気で多言語対応するのであれば、セカンダリ言語の設定とローカライズを省略しない方が安全です。

応用編:発言内容から言語を自動判定してみる

ここから先は少し発展的な内容です。
実際に試してみると、生成オーケストレーションが有効なエージェントであれば、「メッセージを受信した時」トリガーのトピックとプロンプトを使って発言言語を判定し、システム変数User.Languageを動的に設定することで、セカンダリ言語として追加していない言語にも、ある程度フォールバックで対応できることが分かりました。

作り方の骨格は次のとおりです。
1. トリガーが「メッセージを受信した時」の新規トピックを作成する
2. 「新しいプロンプト」を追加し、指示欄に「このメッセージが書き込まれる言語を決定する:」と入力する
3. テキスト変数Message(サンプルデータ:「ユーザーからのメッセージ」)を挿入し、出力形式をJSONに設定する
4. プロンプトの入力にActivity.Text、出力にDetectedLanguageを設定する
5. 条件ノードで判定結果を「Japanese」「English」「その他のすべての条件(フォールバック)」の3つに分岐させ、各分岐でシステム変数User.Languageを設定する

実際に組んだトピック全体は、次のような構成になりました。まず全体の流れを確認してから、各部分の動作を見ていきます。

Japanese・English・その他のすべての条件の3分岐すべてにUser.Language変数の設定ノードが配置された、最終的なトピックキャンバス

まずは、プロンプト部分が発言内容から言語を正しく判定できているかをテストしました。
日本語のサンプルデータ(「ユーザーからのメッセージ」)を入力すると、{"language": "Japanese"}という判定結果が返ってきました。

言語自動判定プロンプトのテスト画面。サンプルデータ「ユーザーからのメッセージ」に対し{"language": "Japanese"}という判定結果が表示されている

続けて英語・中国語・韓国語のサンプルデータでもテストしたところ、いずれも正しく言語が判定されました。

言語自動判定プロンプトのテスト画面。英語のサンプルデータ「What kind of company is QES?」に対し{"language": "English"}という判定結果が表示されている

中国語入力(「QES是一家什么样的公司?」)に対しても、{"language": "Chinese"}と正しく判定されました。

言語自動判定プロンプトのテスト画面。中国語のサンプルデータ「QES是一家什么样的公司?」に対し{"language": "Chinese"}という判定結果が表示されている

韓国語(「QES는 어떤 회사인가요?」)も同様に判定できました。

言語自動判定プロンプトのテスト画面。韓国語のサンプルデータ「QES는 어떤 회사인가요?」に対し{"language": "Korean"}という判定結果が表示されている

プロンプト部分の判定精度を確認できたところで、実際にトピックへ質問を投げて、条件分岐と回答が想定どおりに動くかを確認しました。
日本語で「QESはどんな会社ですか?」と質問すると、実行トレース上で「Japanese」の条件分岐が実際に通り、日本語で回答が返ってきました。

言語自動判定トピックを組み込んだ状態で、日本語の質問に対して「Japanese」の条件分岐が実行され、日本語で回答が返ってきている実行トレース画面

続けて英語で「What kind of company is QES?」と質問すると、同様に「English」の条件分岐が実行され、英語で回答が返りました。
いずれも、言語セレクターを操作せずに、発言内容だけで言語が切り替わっています。

言語自動判定トピックを組み込んだ状態で、英語の質問に対して「English」の条件分岐が実行され、英語で回答が返ってきている実行トレース画面

ここで気になっていたのが、セカンダリ言語として追加していない中国語で質問した場合の挙動です。
中国語で「QES是一家什么样的公司?」と質問したところ、トピックの実行トレース上では「その他のすべての条件」(フォールバック)分岐が実行され、User.Languageが「Japanese」に設定されたことが確認できました。
そして回答は、冒頭に「申し訳ありませんが、当アシスタントは日本語でのご案内となります。」という一文が自動的に付与された上で、日本語による会社概要が続きました。

中国語で質問した際に「その他のすべての条件」分岐が実行され、User.Languageが日本語に設定された実行トレースと、「当アシスタントは日本語でのご案内となります」という断りの一文が自動で付与された回答が同時に表示されている画面

なぜ未対応言語なのに自然な断り文が付いたのか:
この「日本語でのご案内となります」という一文は、あらかじめ用意していた固定文ではありません。
User.Languageが日本語にフォールバックしたという状況を、生成回答を作るモデル自身が文脈として解釈し、断りの一文を自然に生成したと考えられます。
これは仕組みとして保証された動作ではなく、生成AIの解釈に依存する挙動である点には留意が必要です。

最後に、この言語自動判定トピックを組み込んだ状態で、あいさつメッセージが1つの会話の中でどう変化するかも確認しました。
言語セレクターを一切操作せず、同じテストセッション内で、"hello"(英語)→ 英語のあいさつ、「こんにちは」(日本語)→ 日本語のあいさつ、「你好」(中国語)→ 日本語へのフォールバック(絵文字付きで多少パラフレーズ)と、3ターン連続で応答言語が切り替わりました。

同じテストセッション内で、hello(英語)、こんにちは(日本語)、你好(中国語)と3ターン連続で入力し、それぞれの言語(中国語は日本語へフォールバック)であいさつが切り替わっている画面

言語自動判定トピックを組み込むことで、あいさつのような固定メッセージもUser.Language経由で動的に切り替えられるようになることが確認できました。
なお公式ドキュメントでは、この動的な言語切り替えの方法は、ブラウザーベースの言語検出とは併用できない旨が明記されています。
しかも、一度でもUser.Language変数がこのトピックで設定されると、その後トピックを無効化・削除しても、ブラウザーベースの言語検出は元には戻りません(設定した言語がユーザーごとのオーバーライドとして保持されたままになります)。元に戻すには、エージェントに/debug clearstateコマンドを送信し、永続化された言語のオーバーライドをクリアする必要があります。
公式ドキュメントも、両方の方式を試す・検証する場合は別のテストエージェントを使うことを推奨しています。
どちらの方式を使うかは、エージェントの利用シーンに合わせて事前に決めておくことをおすすめします。

よくある質問

Q. プロンプト(指示文)だけで多言語対応させることはできますか?

部分的には可能ですが不安定です。
筆者の検証では、ナレッジベースの生成回答は20回中8回程度しか入力言語に追従せず、固定メッセージは一度も追従しませんでした。安定した多言語対応には、セカンダリ言語の設定とローカライズが必要です。

Q. セカンダリ言語として追加していない言語で質問するとどうなりますか?

筆者の検証では、言語自動判定トピックを組み込むと、未対応言語(中国語)からもプライマリ言語(日本語)へのフォールバックが機能し、モデルが自動的に「日本語でのご案内となります」という断りの一文を回答に加えていました。

まとめ:プロンプトだけの多言語対応と、言語自動判定による応用

後編でご紹介した内容の学びは2つです。
1つ目は、セカンダリ言語を設定せずプロンプトだけで多言語対応させようとすると、生成回答の言語追従は20回中8回程度と不安定で、固定メッセージは追従しないため、本気で多言語対応するならセカンダリ言語の設定とローカライズを省略しない方が安全だということ。
2つ目は、発言内容から言語を自動判定するトピックを組めば、セカンダリ言語として追加していない言語にも、プライマリ言語へのフォールバックという形で応用的に対応できることです。

前編でご紹介した基本手順とあわせて、ぜひ自社のエージェント作成にお役立てください。


また、QESでは、Power Platform導入時の支援から、アプリケーション開発、導入後の保守サポートまで対応しています。
以下のリンクからご提供しているサービスの詳細をご確認いただけます。

※このブログで参照されている、Microsoft、Copilot、Copilot Studioは、米国およびその他の国におけるMicrosoftの商標または登録商標です。

  • このエントリーをはてなブックマークに追加

お問い合わせ

Contact

ご質問やご相談、サービスに関する詳細など、何でもお気軽にご連絡ください。下記のお問い合わせフォームよりお気軽に送信ください。

お問い合わせ

資料ダウンロード

Download

当社のサービスに関する詳細情報を掲載した資料を、下記のページよりダウンロードいただけます。より深く理解していただける内容となっております。ぜひご活用ください。

資料ダウンロード