第2回-上流ハーネス：GitHubの業務資料をAzure AI SearchとMicrosoft Foundryで使う：検索・同期・Webアプリの実装例

Posted at 2026-09-25

※お役に立てたらストック、いいねをよろしくお願いします！！

＜本記事のターゲット層＞

Microsoft Foundryのエージェントを社内アプリから使いたいエンジニア
GitHubで更新する資料をAzure AI Searchへ反映したいAI基盤担当者
非エンジニア向けのAIアプリに、検索・権限・監査を組み込みたいチーム

第1回では、上流工程向けハーネスとして、案件・顧客・業務ルール・決定履歴をAIが参照できるようにする考え方を紹介しました。

今回は、その資料をどう実装へつなげるかを扱います。テーマはシンプルです。

GitHubで更新した資料を、必要な人だけが検索し、Microsoft Foundryのエージェントへ根拠として渡すにはどうするか。

公開サンプル UpstreamHarnessLab では、GitHub、Azure AI Search、Microsoft Foundry、Webアプリを役割ごとに分けました。この記事では、サンプルで実装した範囲と、Azure上でこれから確認する範囲を分けて説明します。

🔷 1. GitHub、Azure AI Search、Microsoft Foundryの役割を分ける

最初に、各サービスの役割を固定します。

サービス	担当すること
GitHub	資料・コードの更新、レビュー、承認、変更履歴の管理
Azure AI Search	承認済み資料や設計・製造根拠を検索しやすい単位で保存
Webアプリ	利用者の目的・権限・対象を確認し、検索とエージェント呼び出しを仲介
Microsoft Foundry	Instructionsと検索結果をもとに、根拠と確認事項を含む回答を作成

サービスごとに、資料更新、検索、回答生成の役割を分けます。

ここで重要なのは、Microsoft FoundryのエージェントがGitHubのファイルを自動で読み続けるわけではない点です。GitHubで資料を更新しても、エージェントのInstructionsや検索インデックスが勝手に変わることはありません。

そのため、次の2種類の更新を分けて考えます。

AGENTS.md のような共通ルールを変えた場合は、Prompt AgentのInstructionsを更新する。
業務資料・設計・製造コードを変えた場合は、Azure AI Searchの検索用コピーを同期する。

🔷 2. `AGENTS.md` をPrompt AgentのInstructionsへ登録する

AGENTS.md は、AIが作業を始めるときの共通ルールを置くファイルです。たとえば、参照する資料の順番、推測で確定してはいけないこと、根拠を回答に残すこと、権限変更や外部送信を実行しないことを書きます。

公開サンプルの apps/FoundryPilot は、選択したMarkdownをPrompt AgentのInstructionsとして登録します。まずは、ローカルで登録対象を確認します。

cd D:\source\UpstreamHarnessLab
dotnet run --project .\apps\FoundryPilot

問題がなければ、Foundryプロジェクトのエンドポイントとモデルデプロイ名を設定して登録します。

$env:FOUNDRY_PROJECT_ENDPOINT = "https://<プロジェクトのエンドポイント>"
$env:FOUNDRY_MODEL_DEPLOYMENT = "<モデルデプロイ名>"

dotnet run --project .\apps\FoundryPilot -- --register

この操作では、upstream-requirements-pilot というPrompt Agentの新しいバージョンが作成されます。Foundryのプレイグラウンドでは、このエージェントを選択して動作を確認できます。

🔹 未記入テンプレートはInstructionsへ入れない

FoundryのInstructionsで、{{...}} のような二重波括弧を含む文字列はテンプレート式として処理され、エラーになる場合があります。ハーネスの未記入テンプレートをそのまま登録せず、実際に利用する承認済み資料や、二重波括弧を含まない共通ルールを選びます。

資料を更新しただけでは、登録済みPrompt AgentのInstructionsは変わりません。変更内容をレビューしてから、新しいバージョンを登録しましょう。

🔷 3. Azure AI Searchのインデックスと差分同期を作る

資料が数十個を超えると、毎回すべてをエージェントへ渡す方法は現実的ではありません。質問に必要な箇所だけを検索するため、公開サンプルでは2種類のインデックスを用意しています。

インデックス	保存するもの
`harness-knowledge-v1`	承認済みの業務資料、業務ルール、決定、レビュー観点
`repository-evidence-v1`	設計書、API定義、ソースコード、テスト

各ファイルを見出しや一定文字数ごとに分割し、本文と一緒に資料ID、版、コミット、対象ID、状態、適用期間、分類、許可グループを保存します。これにより、たとえば「承認済み」「この顧客」「この案件」「利用者が所属するグループ」という条件で検索できます。

まずはインデックスを作成します。サンプルでは、検証を始めやすいAPIキー方式を採用しています。

cd D:\source\UpstreamHarnessLab

$env:AZURE_SEARCH_ENDPOINT = "https://<検索サービス名>.search.windows.net"
$env:AZURE_SEARCH_ADMIN_KEY = "<管理者キー>"

dotnet run --project .\apps\SearchIndexProvisioner -- --apply

管理者キーは、インデックスの作成・更新と同期処理にだけ使います。Webアプリやブラウザへ渡してはいけません。検索を実行するアプリでは、権限を絞ったクエリキーを使う構成にします。

🔹 GitHubでの削除を検索結果へ残さない

SearchIndexSync は、承認済みの資料と架空の設計・製造リポジトリを読み取り、追加・更新・削除をAzure AI Searchへ反映します。テンプレート、archive、90_Examples、未記入のテンプレート式を含むファイルは同期対象外です。

cd D:\source\UpstreamHarnessLab

# Azureへ変更を送らず、対象だけを確認する
dotnet run --project .\apps\SearchIndexSync

# 環境変数を設定済みの場合に差分同期する
dotnet run --project .\apps\SearchIndexSync -- --apply

ローカルのドライランでは、架空の業務資料3チャンク、設計・製造サンプル16チャンクを準備できることを確認しました。Azure上の実インデックス作成と実同期は、接続先と管理者キーを設定した後に確認する項目です。

承認済みの変更だけを検索に反映し、不要になった資料を残しません。

GitHub Actionsで自動化する場合は、main へのマージを契機に SearchIndexSync --apply を実行します。検証ではActions secretsにエンドポイントと管理者キーを保存できます。本番では、GitHub ActionsのOIDCとAzure RBACへ移行し、長期利用する管理者キーを減らします。

🔷 4. WebアプリとAgent Frameworkで、根拠付きの回答を作る

Foundryのプレイグラウンドは、AI基盤担当者が動作を確かめるには便利です。一方で、PMや営業に毎回エージェントを選び、入力する資料を判断してもらう画面としては向いていません。

公開サンプルの apps/HarnessWebSample では、次の2つから目的を選べます。

業務・要件整理: 要件の不足、制約、未決事項を整理する。
営業向け実現性評価: 設計・製造の根拠をもとに、実現可否、影響範囲、概算の大きさ、確認事項を下書きする。

レビュー処理には、Agent Frameworkで要件レビュー、整合性確認、レビュー統合を順に実行するサンプルも用意しました。役割を分けることで、一つのエージェントにすべての確認を任せるよりも、どの観点を確認したかを追いやすくなります。

非エンジニア向け画面では、目的選択とサーバー側の検索制御を分けます。

現状の営業向け実現性評価は、架空の sample-repositories/ をサーバー側で直接読み込むサンプルです。Azure AI Searchの検索結果をWebアプリからエージェントへ渡す部分は、今後の検証項目です。

実運用へ進めるときは、利用者が入力した条件をそのまま検索フィルターに使いません。サーバー側で、次の条件を組み立てます。

Entra IDから得た利用者のグループ
選択済みの顧客・製品・案件ID
資料の承認状態と適用期間
情報分類と許可グループ

この制御がないと、別顧客の資料や廃止済みのルールを、AIへ渡してしまう可能性があります。

✅ 5. まとめ：まずは架空資料で同期から回答までを確認する

今回のサンプルでは、資料更新、検索、回答生成を別々の役割として実装しました。

GitHubで資料を更新し、レビューと承認を行う。
Azure AI Searchへ、承認済みの資料と設計・製造の根拠を同期する。
Webアプリが利用者の目的と対象を確認し、必要な根拠を検索する。
Microsoft Foundryのエージェントが、Instructionsと根拠を使って回答を作る。

最初の検証では、実データを使わない1案件・1製品・1顧客の資料を用意すると安全です。資料の追加、更新、削除、検索、質問回答を一連で確認してください。

その後に、Entra ID、OIDC、Azure RBAC、監査ログ、社内の情報管理ルールを追加していきます。AIの回答精度だけでなく、どの資料を参照し、誰が承認し、いつ更新したかを追跡できる状態を目指しましょう。