Agent Builderでソーシャルメディア・コンテンツ・エージェントを構築する
本章では、Foundry ToolkitのAgent Builderを使用して、実用的なソーシャルメディア・コンテンツ・エージェントを構築する手順を説明します。目的は単にテキストを生成することではなく、適切なフォローアップの質問を投げかけ、信頼できるコンテキストを使用し、チームが実際にレビューして公開できる出力を返すアシスタントを作成することです。
最後まで進めると、Visual Studio Codeでアイデアからテスト済みのプロンプト・エージェントの動作まで移行するための、反復可能なワークフローが手に入ります。
問題の定義：グラウンデッド・エージェントは決定システムである
有益な視点として、このエージェントを単なるテキストジェネレーターではなく、決定システムとして扱うことがあります。出力の品質は、相互に関連する3つの決定に依存します。
- 明確化のための質問をするタイミング：例えば、プロンプトにオーディエンスやトーンに関する情報が欠けている場合、エージェントはコピーのドラフト作成前に質問すべきです。
- ツールを呼び出すタイミング：プロンプトがマイクロソフトのテクノロジに言及している場合、エージェントはコピーのドラフト作成前に公式ドキュメントを取得すべきです。
- レビュー用に最終コンテンツを成形する方法：エージェントは、チームのスタイルガイドに従ってドラフトをフォーマットし、参考資料へのリンクを含めるべきです。
これらの決定が明確であればあるほど、チームはより予測可能で信頼性の高い動作を得ることができます。
それが、「賢そうに聞こえる」ものと「公開しても安全な」ものの違いです。
同じプロンプトをグラウンディングありとかなしで実行してみると、これを実際に確認できます。グラウンデッドバージョンは通常、曖昧な主張が少なくなり、トレーサビリティが向上します。これは、技術的なメッセージを公開する際にコンテンツチームがまさに求めているものです。
前提条件
構築を始める前に、セットアップの準備ができているか確認しましょう。本章では、エージェントのオーサリング、ツールのグラウンディング、および評価を組み合わせるため、前提条件が欠けていると途中でフローが中断してしまう可能性があります。
以下に挙げるすべての項目がすでに準備されていれば、寄り道をすることなく本章の全手順を実行できるはずです。
- Visual Studio Codeのセットアップ：Foundry ToolkitがインストールされたVisual Studio Code。
- プロジェクトアクセス：Foundry Toolkitで接続されたMicrosoft Foundryプロジェクト。
- モデルの準備状況：エージェントを動かすために利用可能な、少なくとも1つのデプロイ済みモデル。
- GitHub Copilotのサポート：ガイド付き評価セットアップのためにVisual Studio Codeで有効化されたGitHub Copilot。
- 評価データ：JSONLデータセット（または合成データを生成する準備）。
セットアップの確認ができたら、何を作っているのか、そしてなぜその設計上の選択が重要なのかを正確に定義できます。
これで、セットアップモードからビルドモードに移行します。
学習内容
目標とする成果物は、開発者向けマーケティングワークフロー向けのソーシャルコンテンツアシスタントです。これは、粗削りなキャンペーン入力を構造化されたドラフトコンテンツに変換しつつ、必要な詳細が不足している場合には明確化のための質問を行います。
ここでは、以下の方法を学びます。
- コンテンツドラフトの生成：LinkedInのコピー、短いキャプション、キャンペーンの切り口を作成する。
- 多様な入力の処理：簡単なテキスト、機能ノート、スクリーンショット、目標を基にして作業する。
- 品質ガードレールの適用：システム指示からトーンと構造の制約に従う。
- レビュー可能な出力の返却：マーケターやデベロッパーアドボケイトが素早く検証できるように応答をフォーマットする。
設定画面を触る前に、このローコードパターンがなぜ価値があるのかを明確にしておきましょう。
ステップ1：Agent Builderでエージェントを作成する
Foundry Toolkitの「Developer Tools」を開き、エージェントを作成するためのビルドパスを開きます。本章であえて最初にローコードパスを使用するのは、カスタムコードを書く前に動作を素早くテストできるようにするためです。
ヒント：実装の一貫性を保つために、役割固有の名前を使用し、プロジェクトにすでにデプロイされているモデルを選択してください。
以下の手順に従ってエージェントを作成します。
- 「Developer Tools」 -> 「Build」 -> 「Create an agent」 -> 「Open Agent Builder」に移動します。
- Dev Social Content Assistantのような、役割を明確に表す名前を割り当てます。
- 簡潔な文章作成、指示への従順さ、およびマルチモーダル入力に適したモデルを選択します。
Agent Builderでエージェント作成フローを開始すると、以下のような画面が表示されます。
図01：Agent Builderでの新しいエージェントの作成。
次に、エージェントの役割、オーディエンス、および出力の期待値を定義する指示（プロンプト）を設定する必要があります。
ステップ2：強力な指示（プロンプト）を定義する
強力なシステムプロンプトは、役割、オーディエンス、境界線、および出力の形状を具体的に定義します。あいまいな指示は通常、あいまいなコピーや一貫性のないフォローアップ動作を生み出すため、これが重要になります。
ソーシャルコンテンツエージェントの指示を作成する際に考慮すべき点は以下の通りです。
- 役割の明確さ：開発者向けコンテンツを制作するソーシャルメディアチームをサポートする。
- 動作ルール：必要な詳細が欠けている場合は、フォローアップの質問をする。
- トーンの制約：誇張された主張を避け、明確な技術的価値を含める。
- 出力構造：最終コピーを、根拠や前提条件から切り離す。
以下は、これらの要件を満たすシステムプロンプトの例です。独自のスタイルやチームのニーズに合わせて適宜調整してください。
図02：ソーシャルコンテンツエージェントのシステムプロンプトの指示を定義する。
指示が確実なものになったら、エージェントを保存して、再利用可能なプロジェクトアセットにします。
ステップ3：プロンプト・エージェントを保存して登録する
指示を定義したら、エージェントをFoundryプロジェクトに保存し、プロジェクトリソースに表示させます。これにより、一時的な編集セッションが、チームが後から再確認できる追跡可能な成果物に変わります。
またこれにより、ツールを追加する前のクリーンなベースバージョンが得られます。
「Save」ボタンをクリックします。「Save to Foundry」と「Save to local file」の2つのオプションが表示されます。Save to Foundryを選択してください。
図03：再利用とバージョニングのために、エージェントをプロジェクトリソースに保存する。
エージェントを保存したら、信頼できるマイクロソフトのドキュメントに接続するためのツールを追加できます。
ステップ4：グラウンデッドなコンテキストのためにMCPツールを追加する
信頼性の高いコンテンツエージェントは、ベースモデルの記憶だけに依存すべきではありません。このワークフローでは、MCPを介して、Microsoft Learn MCPサーバー経由で信頼できるマイクロソフトのドキュメントにエージェントを接続します。
このシナリオでは、キャンペーンテキストが製品の機能、リリース詳細、またはプラットフォームの動作に言及する場合、グラウンディングが重要になります。
-
「Tool」セクションで、「+」をクリックし、「MCP Server」を選択します。
図04：ツールでMCPサーバーを選択する。
次に、どのMCPサーバーを選択するかを指定する必要があります。
-
利用可能なサーバーのリストからMicrosoft Learn MCPサーバーを選択します。
図05：グラウンデッドな応答のために、MCPサーバーツールをエージェントに追加する。
ツールを追加するだけでは不十分であるため、次のステップは、エージェントにツールを使用するタイミングを教えることです。
ステップ5：指示にツール使用ガイダンスを追加する
ツールを追加するのは作業の半分にすぎません。いつツール呼び出しが必要であり、どのように順序付けるべきかをエージェントに伝える、指示レベルのガイダンスも必要です。
これがないと、エージェントが検索をスキップしたり、一貫性のない方法でツールを呼び出したりする可能性があります。
実際には、「プロンプトがマイクロソフトのテクノロジについて質問している場合は、出力をドラフトする前に公式ドキュメントを取得する」といった明示的なトリガーロジックが必要です。
- 決定ロジック：ユーザーがマイクロソフトのテクノロジについて質問したタイミングを検出する。
- 計画の動作：コピーを生成する前にどのような情報が必要かを特定する。
- ツールの選択：適切なMicrosoft Learn MCPツールにルーティングする。
- グラウンデッドな出力：事前の推測ではなく、検証済みのソースに基づいて応答を作成する。
エージェントがいつツールを呼び出し、取得したコンテキストをどのように使用すべきかを理解できるように、システムプロンプトでこれをどのように表現するかの例を以下に示します。エージェントに対して、ステップごとに考え、意図を分析し、どのツールを呼び出すか、および追加のツール呼び出しの可能性を決定するよう求めます。最後に、取得したコンテキストに対してエージェントができることとできないことを制限するガイダンスを追加します。
図06：エージェントの指示にツール使用ガイダンスを追加する。
この段階で、プレイグラウンドで現実的なテストを実行します。
ここで、エージェントが実際に何ができるのかが示されます。
ステップ6：エージェント・プレイグラウンドでテストする
指示とツールが設定できたら、Agent Builderのプレイグラウンドで実際のプロンプトを直接実行します。合成された一行のテキストではなく、チームが実際に受け取るキャンペーンのリクエストを反映したプロンプトを使用してください。
このステップでは、動作の品質がすぐに目に見えるようになります。
例えば、開発者向けの「GitHub Copilot app」に関するLinkedInの投稿を作成するように求め、アシスタントが信頼できるコンテキストを取得すると同時に、役立つフォローアップの質問をしてくるかどうかを確認します。
テストの際に確認すべき点は以下の通りです。
- ツールの検証：Microsoft Learnに対してドキュメント検索が呼び出されていることを確認する。
- 応答の品質：ドラフトの有用性、構造、コールトゥアクション（CTA）の配置を確認する。
- フォローアップの動作：必要に応じてエージェントが明確化のための質問を行うことを確認する。
- 透明性：要求されたときに根拠（ラショネール）が表示されることを検証する。
入力されたプロンプト、呼び出されたツール、およびエージェントからの最終出力を示す以下の画像をご覧ください。
図07：現実的なプロンプトを使用して、プレイグラウンドでエージェントをテストする。
手動テストは有用ですが、次のステップこそが品質を測定可能にする場所です。
ステップ7：評価（Evaluations）による検証のスケール
評価（Evaluations）は、複数のテスト行にわたって動作の品質を測定するための反復可能な方法です。これにより、明確なメトリクスに対してエージェントをスコアリングし、どこに改善が必要かを特定できます。
手動のプレイグラウンドテストは有用ですが、反復可能な品質管理としてはスケールしません。このステップでは、組み込みの評価ワークフローを導入し、複数のテスト行にわたって明確なメトリクスに対して動作をスコアリングできるようにします。
さらに進む前に理解しておくべき2つの主要な概念があります。
- 評価（Evaluation）：テスト行のデータセットに対してエージェントの動作をスコアリングする構造化されたプロセス。各行には入力プロンプトと期待される出力があり、評価では実際の応答と期待される応答を比較します。
- 評価者（Evaluator）：エージェントの応答の品質を判断するためにメトリクスを適用するスコアリングメカニズム。評価者のメトリクスの例には、タスクへの準拠度、流暢さ、関連性、グラウンデッドネス（根拠の正確さ）などがあります。
Foundry Toolkitには、評価に対する優れた組み込みサポートがあるため、セットアップの手順を順に見ていきましょう。
エージェントを作成すると、評価のセットアップを支援する評価エリアも用意されています。テストプロンプトと期待される出力のデータセットを作成し、評価を実行してエージェントのパフォーマンスを確認するというのがそのコンセプトです。
このようなエージェントがあるとして、評価をセットアップする方法は以下の通りです。
-
評価エリアを選択し、データセットを生成するよう選択します（左上のボタン）。
下の画像にある「Evaluation」タブを確認し、それを選択します。
-
左上のボタンをクリックして、データセットの生成を選択します。
まず最初に、データセット生成用のプロンプトテンプレートを表示するモデルが表示されます。プロンプトを確認し、データセットの生成を選択します。これにより、評価に使用できるテスト行が含まれたJSONLファイルが作成されます。
モデルに対して実行できる、生成されたプロンプトのセットの例は以下の通りです。
-
評価を実行してエージェントをテストします（再生アイコンを選択）。
各プロンプトがエージェントに対してどのように実行されるかを確認でき、結果に対して「いいね！（thumbs up）」または「よくないね！（thumbs down）」をつけることができます。
図08：エージェントの評価設定を構成する。
これは、生成されたデータセットに対してエージェントがどのようにパフォーマンスを発揮しているかを素早く把握するための優れた方法です。エージェントの指示、ツール、その他の設定を調整し、評価を再実行してパフォーマンスが向上するかどうかを確認できます。
簡単な質問
エージェントが洗練された出力を生成したとしても、主要な製品の事実がどこから来たのかを説明できない場合、外部への公開用としてそれを信用できますか？
回答
ほとんどの本番チームにおいて、答えは「いいえ」です。トレーサブルなグラウンディングのない洗練された表現は、特に技術的な主張においてレビューのリスクを生み出します。信頼性の高い公開ワークフローには、質の高い言語と検証可能なソース活用の両方が必要です。
今後の展望
プロンプトベースのソーシャルコンテンツアシスタントを検証した後の次のステップは、より高度なエージェントエンジニアリングです。よりリッチなツールオーケストレーション、より強力なデータセット、および本番志向のデプロイと監視ワークフローへと拡張していくことができます。
次の章では、この基盤の上に構築を行い、複雑さが増しても動作の品質が維持されるようにします。
あなたは後から修正するのではなく、今まさに信頼性を構築しているのです。
詳細情報
ハンズオンフローの終了後により深く学びたい場合は、以下のリソースをガイド付きの拡張パスとして活用してください。エージェントの基礎から始め、次に実装とデプロイのリファレンスへと進むことで、各リンクが前の内容の上に積み重なっていくようになっています。この順序は、チームが通常プロンプトエージェントのプロトタイプから本番対応のエージェントワークフローへと成熟していく過程を反映しています。
- Copilot Chat workflows: Visual Studio CodeのドキュメントでCopilot Chatのガイダンスを確認する。
- Azure AI Foundry overview: より広いプラットフォームとワークフローサーフェスを理解する。
- Azure AI Agents overview: コアとなるエージェントの概念とライフサイクルのガイダンスを確認する。
- Azure AI Agents quickstart: 実用的なエージェントをエンドツーエンドで構築して実行する。
- Foundry SDK development guide: SDKベースの実装パターンを探索する。
- Azure Developer CLI documentation: 再現性のあるプロジェクトおよびデプロイワークフローにazdを使用する。
- Model deployment reference: Azure AI FoundryでOpenAIモデルをデプロイする。