Azure AI FoundryのUser feedback loggingとは？公開プレビューの変更点と確認ポイント

Azure AI FoundryでAIエージェントを運用している場合、今回の「User feedback logging in Microsoft Foundry」は、ユーザーの「良かった・悪かった」という反応を単なるアンケート結果ではなく、実際のリクエストトレースと結び付けて分析できるようにする重要な変更です。2026年6月4日に公開・更新された公式アップデートでは、AIエージェントを利用するエンドユーザーからの thumbs up/down、評価スコア、カスタム注釈などの構造化フィードバックを取得し、Azure Monitor上のリクエストトレースへ自動的に関連付ける機能として案内されています。(Microsoft Azure)

結論として、管理者は Application Insights接続、RBAC、保存期間、個人情報の扱い、プレビュー利用条件 を確認し、開発者は フィードバックUI、OpenTelemetryイベント送信、トレース相関、KQLでの確認方法 を押さえる必要があります。まだ公開プレビューのため、本番環境へ全面展開する前に、検証環境でデータ設計と運用フローを固めるのが現実的です。Microsoftのドキュメントでも、プレビュー機能はSLAなしで提供され、本番ワークロードでは推奨されないとされています。(Microsoft Learn)

Azure AI FoundryのUser feedback loggingは何が変わるのか

User feedback loggingは、AIエージェントに対するユーザーの主観的な評価を、Azure AI Foundryの観測データとして扱いやすくする機能です。

従来も、アプリケーション側で「いいね」「低評価」「星評価」「コメント」を独自に保存することはできました。しかし、それだけでは「どの応答に対する評価なのか」「その応答ではどのプロンプト、ツール呼び出し、検索結果、モデル応答が関係していたのか」まで追いにくい問題がありました。

今回の機能では、エンドユーザーのフィードバックをOpenTelemetryのセマンティック規約に沿った構造化イベントとして送信し、特定のtraceまたはspanに関連付けます。これにより、トレース、メトリック、ユーザー評価を同じテレメトリ基盤で扱えるようになります。(Microsoft Learn)

観点	従来ありがちな運用	User feedback logging導入後
ユーザー評価の保存	独自DBやログに個別保存	OpenTelemetryイベントとして送信
原因調査	評価と実行ログを手作業で突合	評価イベントから該当trace/spanへたどれる
分析単位	「低評価が何件あったか」中心	低評価と遅延、例外、検索結果、ツール実行を関連分析
改善サイクル	PMやCSの定性情報に偏りやすい	実際のエージェント実行データと組み合わせて改善
監視基盤	アプリごとに分散しがち	Application Insightsや互換バックエンドに集約可能

重要なのは、これは「フィードバックボタンを自動で作ってくれる機能」ではない点です。実際のアプリ画面でどのように評価を集めるかは、開発者が設計します。そのうえで、集めた評価を標準化されたイベントとしてAzure MonitorやApplication Insightsへ流す、という位置づけです。

対象者と影響範囲

この変更の影響を受けるのは、Azure AI FoundryでAIエージェントや生成AIアプリケーションを開発・運用しているチームです。特に、すでにApplication InsightsやAzure Monitorでエージェントのトレースを見ている組織では、比較的自然に取り込めます。

対象者	確認すべきポイント
Azure管理者	FoundryプロジェクトとApplication Insightsの接続、RBAC、保存期間、課金
AIアプリ開発者	thumbs up/down、星評価、コメントなどをどの画面で収集するか
SRE・運用担当	低評価とエラー、遅延、ツール失敗をどう相関分析するか
セキュリティ・法務・監査担当	フィードバックやトレースに個人情報、機密情報が入らない設計
プロダクト担当	ユーザー満足度をどの評価軸で測るか、改善優先度へどう反映するか

特に影響が大きいのは、社内向けCopilot、問い合わせ対応エージェント、RAGアプリ、業務自動化エージェントのように、実利用者の反応をもとに継続改善したいケースです。

たとえば、問い合わせ対応エージェントで「回答は速いが低評価が多い」場合、単なる性能監視だけでは問題を見落とします。User feedback loggingを使うと、低評価の応答に紐づく検索クエリ、参照ドキュメント、ツール呼び出し、モデル応答を確認しやすくなります。

実装前に確認すべき前提条件

Microsoft Learnの手順では、エンドユーザーフィードバックを記録する前提として、FoundryプロジェクトにApplication Insightsリソースを接続し、アプリケーション側でOpenTelemetryの計装を構成することが示されています。Pythonの場合はPython 3.9以降、および azure-ai-projects、azure-monitor-opentelemetry などのパッケージが前提として挙げられています。(Microsoft Learn)

確認項目	実務上の見方
Foundryプロジェクト	対象エージェントがどのプロジェクトに属しているかを整理する
Application Insights	新規作成か既存リソース接続かを決める
OpenTelemetry	既存のOTelパイプラインがある場合は流用可否を確認する
RBAC	ログ閲覧者、運用者、開発者の権限を分ける
SDK・ランタイム	使用言語とSDKバージョンがプレビュー手順に合うか確認する
データ保持・課金	Application InsightsとLog Analyticsの設定に従う点を確認する

トレース設定では、FoundryプロジェクトにApplication Insightsを接続すると、サーバーサイドトレースを利用できるようになります。ドキュメントでは、FoundryのTraces画面からApplication Insightsを作成または接続する流れが案内されています。(Microsoft Learn)

ただし、トレースが有効になっていることと、ユーザーフィードバックが正しく記録されることは別です。ユーザーが評価ボタンを押したタイミングで、該当するtrace/spanに関連付く形でイベントを送信できるよう、アプリ側の実装が必要です。

取得できるフィードバックの種類

Microsoft Learnでは、人間による評価を gen_ai.evaluation.result というOpenTelemetryイベントとして扱い、主にBinaryとLikert 5-pointの2種類が説明されています。Binaryは合格・不合格、つまりthumbs up/downのような評価で、Likert 5-pointは1〜5の段階評価です。(Microsoft Learn)

評価タイプ	用途	スコア範囲	向いている場面
Binary	良い・悪い、役に立った・立たなかった	0.0または1.0	チャット回答直後の簡易評価
Likert 5-point	5段階評価、星評価、満足度評価	1.0〜5.0	回答品質や信頼性を細かく見たい場合
カスタム注釈	低評価理由や改善分類	実装設計による	「根拠不足」「古い情報」「回答が長い」などの分類

実務では、最初から自由記述コメントを大量に集めるより、Binaryまたは5段階評価に「低評価理由」を選択式で追加する設計がおすすめです。

たとえば、低評価時に次のような理由を選べるようにします。

回答が間違っている
根拠が不足している
質問の意図と違う
情報が古い
回答が長すぎる
操作手順が分かりにくい

自由記述だけにすると、個人情報や機密情報が入力されやすくなります。選択式の注釈を中心にすれば、分析しやすく、セキュリティリスクも抑えやすくなります。

管理者が確認すべき設定

Application Insightsの接続状態

最初に確認すべきなのは、FoundryプロジェクトにApplication Insightsが接続されているかです。FoundryのトレースはApplication Insightsに保存され、Azure Monitor側でも確認できます。Microsoft Learnでは、FoundryプロジェクトのTraces画面またはConnected resourcesからApplication Insightsを接続する手順が示されています。(Microsoft Learn)

既存のApplication Insightsを接続する場合は、他システムのログと混在して分析しづらくならないかを確認します。PoCや検証段階では専用リソースを使い、本番導入時に集約方針を決めると安全です。

RBACと閲覧権限

フィードバックログは、ユーザーの満足度だけでなく、プロンプト、モデル出力、ツール引数、検索結果といった機微な情報に近いデータと結び付きます。そのため、開発者全員に広く閲覧権限を与えるのではなく、役割に応じて最小権限にします。

Microsoft Learnでは、ログベースのクエリには接続されたApplication InsightsリソースやLog Analyticsワークスペースへのアクセスが必要で、Log Analytics Readerロールが例として示されています。(Microsoft Learn)

おすすめの分け方は次の通りです。

役割	権限設計の考え方
アプリ開発者	検証環境のログ閲覧、必要な範囲のKQL実行
運用担当	本番テレメトリの監視、アラート確認
セキュリティ担当	監査目的の閲覧、保持期間・アクセスレビュー
プロダクト担当	集計済みダッシュボード閲覧。生ログ閲覧は必要最小限

保存期間とコスト

フィードバックイベントはApplication InsightsやLog Analyticsの設定に従って保存されます。Microsoft Learnでも、トレースデータの保持期間と課金は接続先のApplication InsightsおよびLog Analytics構成に従うと説明されています。(Microsoft Learn)

低評価理由やコメントを細かく取り始めると、イベント数とデータ量が増えます。全ユーザー・全応答で評価イベントを必ず送る設計にする前に、次の方針を決めておきましょう。

項目	判断基準
保存期間	改善分析に必要な期間。例：30日、90日、180日
収集対象	全応答か、評価操作があった応答のみか
コメント保存	自由記述を保存するか、選択式理由だけにするか
環境分離	開発・検証・本番でApplication Insightsを分けるか
監査要件	個人情報や業務データを含む可能性があるか

開発者が実装で見るべきポイント

フィードバックUIは「押しやすさ」と「分析しやすさ」を両立させる

ユーザーから評価を集めるUIは、複雑にしすぎると使われません。まずは、AI応答の直下に「役に立った」「役に立たなかった」を置くのが現実的です。

ただし、Binary評価だけでは改善理由が分かりにくいため、低評価時だけ理由を1つ選ばせる設計が有効です。

例として、社内ナレッジ検索エージェントなら次のようにします。

UI項目	目的
役に立った	成功応答の傾向を把握
役に立たなかった	問題応答の抽出
低評価理由	RAG、プロンプト、UI、情報鮮度のどこを直すべきか分類
任意コメント	再現に必要な補足。ただし入力内容の注意書きが必要

自由記述欄には、「個人情報、パスワード、顧客名、契約情報などは入力しないでください」と明記しましょう。トレースはユーザー入力、モデル出力、ツール引数などの機微情報を含む可能性があるため、Microsoft Learnでも秘匿情報をプロンプトやspan属性に保存しないこと、個人情報や機密情報を最小化・マスクすることが推奨されています。(Microsoft Learn)

trace/spanとの関連付けを壊さない

User feedback loggingの価値は、評価イベントが該当リクエストのtrace/spanに結び付くことにあります。評価ボタンを押したときに、どのエージェント応答に対するフィードバックなのかを失うと、単なる満足度ログになってしまいます。

実装時は、少なくとも次の情報をアプリ側で保持できるようにします。

情報	理由
response IDまたはメッセージID	画面上のどの回答への評価かを識別する
trace ID	Application Insights上のトレースへ関連付ける
span ID	可能であれば対象処理をより細かく追跡する
agent名・バージョン	モデルやプロンプト変更前後で比較する
評価値	Binaryまたは5段階評価として分析する
評価理由	改善カテゴリを分類する

特に、フロントエンドだけで評価を受け付け、バックエンド側でtrace情報を持っていない構成では注意が必要です。応答生成時に返した識別子を、評価送信時にも渡せるように設計しておきます。

Application Insightsで確認できるようにする

フィードバックイベントは、Application Insightsの customEvents から確認できます。Microsoft Learnでは、gen_ai.evaluation.result イベントをKQLで集計する例が示されています。(Microsoft Learn)

検証時は、次のような観点で確認します。

customEvents
| where name == "gen_ai.evaluation.result"
| summarize
    total = count(),
    avgScore = avg(todouble(customDimensions["gen_ai.evaluation.score.value"]))
  by tostring(customDimensions["gen_ai.evaluation.name"]), bin(timestamp, 1h)
| order by timestamp desc

この段階で確認したいのは、単にイベントが出ているかだけではありません。次の3点を必ず見ます。

確認項目	失敗例
評価イベントが記録される	ボタンを押してもcustomEventsに出ない
スコアが正しい	thumbs downなのにpass扱いになる
traceと関連付く	評価は見えるが、該当する応答やspanへ追えない

移行・展開時の注意点

既存の独自フィードバックDBはすぐに捨てない

すでに独自DBでユーザー評価を保存している場合、公開プレビュー段階で即座に置き換えるのは避けたほうが安全です。まずは二重書き込み、または検証環境での並行運用にします。

既存運用	推奨する移行方法
DBにgood/badだけ保存	同じイベントをOpenTelemetryにも送信して比較
コメントを全文保存	個人情報マスキングや選択式理由への移行を検討
管理画面で集計済み	Application InsightsのKQL結果と差分確認
CS部門が手作業分類	低評価理由の選択肢を設計し、分類を標準化

独自DBはアプリ内の問い合わせ対応やCS業務で使い続け、OpenTelemetry側はトレース相関と運用分析に使う、という分担も現実的です。

プレビュー機能として段階展開する

Azure Updatesのステータスでは、In previewはすべてのAzure顧客が非本番用途・テスト目的で利用できる段階として説明されています。(Microsoft Azure) そのため、最初から全ユーザーに展開するより、対象エージェントや対象部門を絞って始めます。

おすすめの展開順は次の通りです。

段階	実施内容
検証環境	Application Insights接続、イベント送信、KQL確認
社内限定	開発者・運用担当・一部業務ユーザーでフィードバック収集
限定本番	特定エージェントや一部画面で収集。既存ログと比較
拡大展開	保存期間、権限、ダッシュボード、運用フローを確定して展開

本番トラフィックに近い環境で検証する場合でも、プレビューであることを前提に、障害時にユーザー体験へ影響しない設計にします。フィードバック送信に失敗しても、チャットやエージェント実行自体は継続できるようにしておくべきです。

活用シーン別の見方

RAGアプリの回答品質改善

RAGアプリでは、「低評価」の原因がモデルではなく検索・文書・チャンク分割にあることがよくあります。

User feedback loggingで低評価イベントとトレースを関連付けると、次のような調査がしやすくなります。

低評価理由	見るべきトレース情報	改善アクション
根拠がない	取得された文書、検索クエリ	検索クエリ生成、引用表示を改善
情報が古い	参照ドキュメント、更新日	ナレッジソースの更新フローを見直す
質問と違う	ユーザー入力、プロンプト	意図分類やプロンプトを調整
回答が長い	出力トークン数	要約指示、回答テンプレートを調整

業務エージェントの運用品質監視

業務エージェントでは、正確性だけでなく、応答速度やツール実行の安定性も重要です。Agent Monitoring Dashboardでは、トークン使用量、レイテンシ、成功率、評価結果などを確認できると説明されています。(Microsoft Learn)

たとえば、ユーザー評価が下がった時間帯にレイテンシも悪化していれば、回答内容よりも応答速度が満足度を下げている可能性があります。逆に、レイテンシは正常でも低評価が増えている場合は、検索結果やプロンプト変更の影響を疑うべきです。

プロンプト改善とA/B検証

エージェントのプロンプトを変更したときは、リリース前後でフィードバック指標を比較します。

見るべき指標は、単純な平均スコアだけではありません。

指標	見る理由
低評価率	改悪が起きていないか
高評価率	改善効果が出ているか
低評価理由の内訳	どの問題が残っているか
エージェントバージョン別スコア	変更前後の差分を把握する
レイテンシ別スコア	遅延が満足度に影響していないか

プロンプト変更、検索設定変更、モデル変更を同時に行うと、どれが評価に影響したのか分かりにくくなります。できるだけ変更単位を分けて、評価ログを比較しましょう。

失敗しやすいポイントと対策

失敗しやすいポイント	起きる問題	対策
評価UIだけ作ってtrace IDを持たない	低評価の原因を追えない	応答生成時のIDを評価送信時にも渡す
自由記述コメントを無制限に保存する	個人情報や機密情報が混入する	選択式理由を基本にし、自由記述は注意書きとマスキングを行う
全ユーザーに一気に展開する	プレビュー機能の制約に巻き込まれる	検証環境、社内限定、限定本番の順に広げる
RBACを広く付与する	生ログを見られる人が増えすぎる	Entraグループと最小権限で管理する
低評価率だけを見る	原因が品質、遅延、UIのどれか分からない	トレース、レイテンシ、ツール実行結果と併せて見る
既存DBをすぐ廃止する	CS業務や既存レポートに影響する	しばらく並行運用して差分を確認する

特に注意したいのは、フィードバックを「ユーザー満足度の数字」としてだけ扱うことです。User feedback loggingの本当の価値は、低評価そのものではなく、低評価に至った実行過程を追える点にあります。

導入前チェックリスト

Azure AI FoundryでUser feedback loggingを試す前に、次の項目を確認してください。

チェック項目	確認内容
対象エージェント	どのAIエージェントで試すか決めたか
評価UI	thumbs up/down、5段階評価、理由選択のどれを使うか
Application Insights	Foundryプロジェクトに接続済みか
OpenTelemetry	アプリ側でイベント送信できるか
trace相関	評価対象の応答とtrace/spanを結び付けられるか
RBAC	閲覧者と管理者の権限を分離したか
保存期間	ログ保持期間とコスト見積もりを確認したか
個人情報対策	コメント欄、プロンプト、ツール引数の扱いを決めたか
KQL確認	`gen_ai.evaluation.result` を検索できるか
展開計画	検証環境から段階的に展開する計画か

まず何から始めるべきか

最初にやるべきことは、検証用のAzure AI FoundryプロジェクトでApplication Insightsを接続し、1つのエージェントに対してthumbs up/downだけを記録する最小構成を作ることです。

そのうえで、Application InsightsのKQLで gen_ai.evaluation.result が確認できるか、評価イベントから該当トレースへたどれるかを見ます。ここまで確認できてから、5段階評価、低評価理由、ダッシュボード、アラート、既存フィードバックDBとの連携を検討すると、設計の手戻りを抑えられます。

Azure AI FoundryのUser feedback loggingは、AIエージェント改善を「感覚的な改善」から「実データに基づく改善」へ進めるための機能です。ただし、プレビュー段階では本番前提で作り込みすぎず、トレース設計、権限、プライバシー、保存コストを確認しながら、小さく導入するのが安全です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。