AIに会社の文脈を理解させる技術～上流工程・非エンジニアにも広げるハーネスエンジニアリング実践～

生成AIの活用は、コード生成や既存システムの理解だけに留まりません。 要件定義、基本設計、業務整理、レビュー、社内合意形成といった上流工程にも活用できます。

しかし、上流工程ではソースコード以上に扱う文脈が複雑です。 プロダクトごとの仕様、プロジェクトごとの制約、顧客ごとの業務背景、会社ごとのルール、意思決定者の関心、承認プロセス、スケジュール、過去の判断履歴など、AIに正しく渡すべき情報は多岐にわたります。

本セッションでは、8月の「既存システムをAIに理解させるハーネスエンジニアリング」から一歩進めて、会社全体で使えるAI活用の仕組みとして、上流工程向けのハーネスエンジニアリングを紹介します。

GitHub Copilot や Azure AI Foundry を活用しながら、AGENTS.md、PROJECT.md、PRODUCT.md、CUSTOMER.md、BUSINESS_RULES.md、DECISION_LOG.md、REVIEW_POINTS.md などをどのように整備し、エンジニアだけでなく、PM、営業、企画、業務担当者も使える形にするかを整理します。

AIに「何となく聞く」のではなく、AIが迷わず判断できる地図を作る。 個人のプロンプト術から、会社全体で再利用できるAI活用基盤へ進めるための実践的な考え方を共有します。

Transcript

1. INTRODUCTION AIに会社の文脈を 理解させる技術 上流工程・非エンジニアにも広げる ハーネスエンジニアリング実践 エンジニア × PM・営業・企画・業務担当者 01 / 44
2. PROFILE 自己紹介 Ochtum（オクトゥム） ちなみにゲームのハンドルネームです 猫とゲームを愛するエンジニアです。IT関連の情報 発信と、ゲームや日常をポストしています。よかっ たらフォローしてください!! X Qiita GitHub Speaker Deck PrairieCards ochtum18 ochtum ochtum ochtum ochtum Prairie Cards プロフィール 02 / 44
3. COMMUNITY & MEETUP 普段参加しているコミュニティ・勉強会 ① Ochtumは技術コミュニティ・勉強会に参加しています コミュニティ .NETラボ .NET・Microsoft製品・開発技術 毎月第4土曜日を基本とする、Microsoft技術の定期勉強会。 現地／YouTube Liveのハイブリッド開催や、発表資料の公開も。 コミュニティ ITエンジニア One Up 勉強会 AIエージェント活用・キャリア・エンジニア同士の交流 エンジニアの市場価値向上をテーマにした、学びと交流の場。 開催例：Claude Code活用LT、AI時代のキャリア・経験共有。 開催情報・参加方法は、各カードのQRから 03 / 44
4. COMMUNITY & MEETUP 普段参加しているコミュニティ・勉強会 ② Ochtumは技術コミュニティ・勉強会に参加しています コミュニティ エンジニアコミュニティ ORION 技術の共有・意見交換・エンジニア同士の交流 技術LT＋質問・意見交換と、その後の懇親会。 仕事・学び・遊びの3つの視点。Discordでの技術雑談・情報共有も。 個人主催の勉強会 大空七菜さん主催の勉強会 Power Platform・TypeScriptなどの技術イベント 主催：大空七菜さん（アイドルシステム）／元アイドルの若手CEO。 2026年4月創業のSES企業。Microsoft系技術の情報発信とも親和性。 会場で見かけたら、ぜひ声をかけてください！ 04 / 44
5. UPCOMING EVENT 参加予定のイベント Ochtumは、個人開発エンジニア向けイベントに参加予定です 共通の登壇テーマ 開催予定 個人開発 × AI・BaaSによる 10/26 「アイデアを最速で形にしたい」エンジニアへ 個人開発・ ハッカソン 爆速プロトタイピング 要件の肥大化で未完成 技術選定の迷い・停滞 BaaS：認証・データ保存などを提供するバックエンドサービス 企画中のプログラム 登壇 約30分 匿名質問への回答 パネルディスカッション 開催者からのご案内をもとに作成。日程・プログラムは予定です。 05 / 44
6. INTRODUCTION 8月の振り返りと今日のゴール 参加者が部門間の要望整理に必要な資料と確認手順を説明できる 対象工程 ／ AIの参照情報 8月：既存システム 今回：上流工程と他部署 コード・設定・テスト 顧客条件・業務ルール・承認条件 理解 → 変更 → 検証 要望 → 根拠付き下書き → 人間の判断 本発表でいうハーネスはAI向けの資料・手順・確認条件の組み合わせである [A] 06 / 44
7. CONTENTS 今日の説明順 発表者が要望整理からFoundry参照までの流れを順に説明する 問題提起 営業と開発の確認事項 p. 8–8 提案 職種別のAIの入口 p. 9–10 本文① 上流工程の資料と責任 p. 11–15 本文② 設計・製造の照合 p. 16–21 本文③ 業務検索・MCP調査・Web利用 p. 22–30 まとめ 本文①〜③の要点と結論 p. 31–32 共通の題材：会員ランク別の返品期限変更 [A] 07 / 44
8. 問題提起 営業と開発が要望の前提を共有できているか？ 営業と開発が顧客条件と技術的制約をすり合わせる必要がある 同じ要望に必要な情報 営業・社員からの質問 開発が確認したい条件 会員ランク別の返品期限 現行仕様・過去の決定 実現可否・影響範囲・概算 会員情報・API・テスト AIが不足している条件を確認事項として残す [A] 08 / 44
9. 提案 職種ごとのAIの入口を用意する エンジニアと非エンジニアが同じ資料を参照する「AI支援環境」を作る 入力：営業質問：返品期限をランク別に変更したい ／ 出力：人間による正式見積・顧客への回答 エンジニア 共通の参照資料 GitHub Copilot等のAIエージェント ハーネス・設計資料・実 装・テスト PM・営業・企画・業務担当者 根拠 根拠付き下書き 実現性・不明点・次の判断者 参照 / サーバー側で取得 Webアプリ → Microsoft Foundry Microsoft FoundryはAIエージェントの設定・実行基盤である 人間が正式見積と顧客への約束を決める [A] 09 / 44
10. 提案 個人毎の入力を辞めて、会社全体で再利用できる仕組みへ 変える 利用者が承認済みの共通資料と対象別の条件を使い分ける 比較する点 個人ごとに毎回説明 会社全体で再利用 前提の入力 個人のプロンプト・記憶 承認済み資料・共通の確認手順 利用する画面 詳しい人による都度の資料選択 開発：Copilot等／他職種：目的別Web 変更の反映 各自の入力を手作業で修正 更新担当が命令・検索用コピーを更新 会社共通：禁止事項・確認手順 ／ 対象別：製品・顧客・案件の条件 更新担当者が承認後の変更を反映し、次の質問でも利用できるようにする [A] 10 / 44
11. 本文① / 上流工程の資料 共通の手順・ルールをAGENTS.mdに定める AIが参照資料・回答項目・人間への確認先を共通ルールに従ってそろえる 工程 担当 成果物 完了条件 1. 質問と対象 営業・PM 質問・顧客・製品・案件ID 確認対象の一致 2. 根拠の確認 AI 参照資料・版・未確定条件 承認済み資料との対応 3. 下書きとレビュ ー AI → PM・開発 根拠付き下書き・差し戻し理由 次の判断者の特定 共通ルール：AGENTS.md ／ 読む順番・禁止事項・必須確認 資料担当者がレビューで判明した不足条件を該当するMarkdownへ反映する [A] 11 / 44
12. 本文① / 上流工程の資料 各部門がそれぞれの資料を担当して更新する 資料管理者が資料の記載内容・更新担当・利用場面を対応付ける ファイル 記録する内容 主な更新担当／利用場面（例） PROJECT.md 目的・範囲・制約・日程 PM／要件の不足・未決事項 PRODUCT.md 対象者・機能・用語・仕様 企画・開発／製品の前提 CUSTOMER.md 業務背景・課題・個別条件 営業・PM／顧客への提案 各部門の責任者が各Markdownの更新者と承認者を指名する [A] 12 / 44
13. 本文① / 上流工程の資料 ルール・過去案件での決定理由(ログ)・合格条件(観点)を 資料に残す AIが業務ルール・決定履歴・レビュー観点を回答の根拠として参照する ファイル 記録する内容 返品期限変更での確認点 BUSINESS_RULES.md 条件・例外・適用範囲 返品期限・手動承認の例外 DECISION_LOG.md 決定・理由・決定者・影響範囲 一律7日を採用した理由 REVIEW_POINTS.md 観点・合格条件・責任 期限計算・顧客への確認先 業務担当者が例外条件と過去の判断理由をレビューで確認する [A] 13 / 44
14. 本文① / 上流工程の資料 資料の版と適用範囲を記録する（変更履歴を残す） 資料管理者が承認状態・適用期間・責任者を本文と一緒に管理する 管理項目 資料と一緒に残す情報 資料ID・版 参照した資料と版の識別 状態・適用期間 下書き／レビュー中／承認済み／廃止済み、開始日・終了日 対象ID 会社・顧客・製品・案件 情報分類・責任者 公開可／社内限定／機密／入力対象外、管理者・承認者 AIが未承認の条件を確定事項として扱わない [A] 14 / 44
15. 本文① / 上流工程の資料 意思決定者の考え方と判断基準を記録する AIが確認相手の重視事項に合わせて判断材料をそろえる 確認相手（例） 重視する条件（本人へ確認） 主な記録先 PM 日程・範囲・予算への影響 PROJECT.md 営業・顧客窓口 既存の約束・顧客への説明 CUSTOMER.md 業務責任者 例外運用・運用負荷 BUSINESS_RULES.md／REVIEW_POINTS.md 開発責任者 変更範囲・連携制約・保守性 設計資料／REVIEW_POINTS.md PMが判断事項・確認相手・期限・未決条件をPROJECT.mdへ対応付ける [A] ／ 架空の運用例 15 / 44
16. 本文② / 設計と製造 設計と製造の機能別対応表を作る AIが返品期限変更に関係する設計・API・コード・テストを照合する 設計リポジトリ 製造リポジトリ 照合する内容 docs/returns-policy-change.md ReturnWindowService.cs 現行7日と変更候補 api/returns-api.yaml ReturnEligibilityEndpoint.cs APIの入力・出力 docs/constraints.md MembershipClient.cs 会員ランクと履歴の有無 docs/decision-log.md ReturnWindowServiceTests.cs 決定理由とテスト条件 架空の設計・製造サンプル ／ 提案：読み取り専用GitHub MCPで照合（接続は未実施） 開発者が機能とファイルの対応を設計変更時に確認する [C] [B] 16 / 44
17. 本文② / 設計と製造 AIが現行仕様と変更候補を分けて読む（ハーネスで実現す る） AIが一般7日・シルバー14日・ゴールド30日の候補を未承認の要望として扱う 承認状態 ／ 期間 ／ 未決事項 承認済みの現行仕様 営業からの変更候補 全会員：7日 DEC-RET-001：運用の単純化 一般：7日／シルバー：14日／ゴール ド：30日 手動承認の例外 起算日・途中のランク変更：未確定 法人・定期購入・予約商品：未確定 PMと業務担当者が起算日とランク変更時の扱いを決める [C] 17 / 44
18. 本文② / 設計と製造 7日の定数(返品期限)だけでなく周辺条件を確認する 開発者が会員ランク取得・期限表示・外部連携・テストを変更範囲として確認する ReturnWindowService.cs 注文時点のランク履歴：未保存 private const int DefaultReturnWindowDays = 7; WMS（倉庫管理）：期限日1件 // 現行実装からの抜粋（省略あり） モバイル：deadline表示 var deadline = deliveredAt.Date .AddDays(DefaultReturnWindowDays) 確認点：起算日の境界・手動例外 .AddDays(1).AddTicks(-1); 開発者が期限の境界時刻と手動例外を受け入れ条件で検証する [C] 18 / 44
19. 本文② / 設計と製造 AIが現行仕様から実装提案を行い、人間(営業等)が提案を決 定する AIが返品期限変更の責務・API入出力・外部連携の案を下書きする 設計の論点 AIが比較する候補（未採用） 人間が決める条件 ランク取得 返品時に照会／注文時に保存 判定時点・取得失敗時・責務 APIの入出力 期限のみ／適用ルールと理由も返す 互換性・必要項目・公開範囲 WMS連携 現行項目を維持／期限や判定を追加 外部制約・連携時点・受け入れ条件 架空の活用例：既存資料を参照 → 設計候補の比較 → 人間の方式決定 開発・業務責任者が方式と判定条件を確認し、設計・API・テストへ反映する [A] ／ 架空の運用例 19 / 44
20. 本文② / 設計と製造 AIが調査結果を提案書にまとめて、各部門担当者が開発者 に話を持っていけるようにする AIが実現可否・影響範囲・概算・確認事項を人間の判断へ渡す 回答の項目 出力内容の例・記入方針 実現可否 ＋ 根拠 条件付きの暫定判断／資料名・版・コミット 影響範囲 期限計算・会員情報・API・テスト 概算の大きさ ＋ 確度 S/M/L／前提と不確実性（この資料では未算定） リスク・制約 ＋ 確認事項 ランク履歴・起算日・規約・運用 人間が次に判断すること 正式見積・承認・顧客への回答 PM・開発・営業が正式見積と顧客への回答を確認して決める [A] 20 / 44
21. 本文② / 設計と製造 関係者が提案書を確認して社内合意を進める AIが未決条件を残し、営業・PM・業務・開発が社内合意を進める 承認が必要な条件（例） 確認先（権限規程に従う） 判断に渡す材料 顧客への約束を変更 営業責任者・顧客窓口 既存の約束・変更案・顧客確認 日程・予算・範囲を変更 PM・案件の承認権限者 影響範囲・概算の前提・日程案 例外運用・連携方式を変更 業務責任者・開発責任者 例外条件・設計案・合格条件 GitHubの資料承認 ≠ 業務変更・顧客への約束の承認 PMが合意後の決定・理由・決定者・影響範囲・適用日をDECISION_LOG.mdに残す [A] ／ 架空の運用例 21 / 44
22. 本文③ / Foundryからの活用 今回、各部門が使うWebアプリの構想です。 業務検索とコード調査を分けるイメージです。 Foundryが業務資料を使い、GitHub MCPで設計・コードを追加調査する 入力：目的・対象・質問（認可を実装する構成案） ／ GitHub 承認済みの業務資料 同期 出力：根拠付き下書き → 人間の判断 Azure AI Search 適用条件付きで検索 根拠 Webアプリ 本人確認・検索の仲介 質問 Microsoft Foundry 調査判断・下書き作成 結果 版登録 AGENTS.md → Instructions 読み取り専用GitHub MCP レビュー後に版登録 GitHub上の設計・コード・テストソース 要求 Foundryが読み取り専用ツールで根拠を集め、人間が正式判断を行う [B] [5] [7] ／ 構成案：MCP接続・評価は未実施 22 / 44
23. 本文③ / Foundryからの活用 共通ルール(AGENT.mdなど）をInstructionsに登録するこ とで、Webアプリでもハーネスを効かせる構想です 運用担当者がレビュー済みの指示文をFoundryPilotで登録する UpstreamHarnessLab / apps/FoundryPilot # 登録内容の確認（Azureへの書き込みなし） dotnet run --project .\apps\FoundryPilot # 設定・レビュー後の登録操作 dotnet run --project .\apps\FoundryPilot -- --register 前提： FOUNDRY_PROJECT_ENDPOINT ／ FOUNDRY_MODEL_DEPLOYME NT 登録例：upstream-requirementspilot ／ 新しい版 運用担当者が未記入テンプレート（{{...}}）を除き、新版を登録する [B] 23 / 44
24. 本文③ / Foundryからの活用 AI Search(業務資料)とGitHub MCP(設計・製造リポジト リ）の参照先を分ける Webアプリが業務資料を検索し、Foundryが設計・コードをMCPで取得する 参照経路 対象 今回の位置付け harness-knowledge-v1 承認済み業務資料・ルール・決定 AI Searchで継続利用 読み取り専用GitHub MCP 設計・API・コード・テストソース 必要な箇所を繰り返し取得（案） repository-evidence-v1 既存の設計・製造の検索用コピー 比較・移行用／MCPでは任意 検索用コピー：資料ID・版・コミット・対象ID・状態・期間・分類・許可グループ チャンク＝元資料を分割した検索単位 ／ MCP取得結果＝パス・SHAを記録 開発者が既存のコード索引とMCP調査を比較して移行範囲を決める [B] ／ 構成案：MCP接続・評価は未実施 24 / 44
25. 本文③ / Foundryからの活用 GitHubアクションで追加・更新・削除を検索へ反映する 同期ジョブが承認済み資料の変更をSearchIndexSyncで反映する 入力：承認済みの変更 ／ 出力：不要な資料を含まない検索結果 1. レビュー・承認 2. mainへマージ 3. 差分同期 4. 検索確認 対象資料と版 GitHubの変更履歴 追加・更新・削除 廃止資料の除外 承認済み SearchIndexSync ／ ドライラン → --apply 同期除外：テンプレート・archive・90_Examples Actions起動： 構成案 反映結果 Azure上での実同期は検証済みです [B] ／ 実同期の検証状況：発表者確認（2026-09-25） 25 / 44
26. 本文③ / Foundryからの活用 Foundryが読み取りツールを使い分ける Foundryが検索・ファイル取得・履歴確認でリポジトリの根拠を集める ツール 読む対象 返品期限変更での使い方 search_code GitHubのコード検索 返品期限・クラス名から候補を探す get_file_contents ファイル／ディレクトリ ReturnWindowService.cs と関連ファイル list_commits / get_commit コミット履歴・変更内容 変更時期・差分の確認 MCP＝AIが外部の操作を呼び出すための接続方式 get_file_contents：shaで版を指定 ／ search_code：任意SHAの完全検索ではない Foundryが候補ファイルを対象SHAで読み直して根拠の版をそろえる [B] [5] ／ 構成案：MCP接続・評価は未実施 26 / 44
27. 本文③ / Foundryからの活用 Foundryが取得結果から次の調査対象を選ぶ Foundryが返品期限の検索・読解・追加調査を上限内で繰り返す 入力：業務資料＋返品期限の質問 ／ 出力：根拠・影響候補・確認事項 1. 候補を探す 2. ファイル読解 3. 関連箇所へ進む 4. 根拠と不足を整理 返品期限・クラス名 search_code 定数・利用箇所 get_file_contents 会員情報・API テストソース・設計 パス・SHA・未確認事 項 十分なら下書きへ 不足あり・上限内なら追加検索 停止条件：根拠が十分 ／ 回数・時間・取得量の上限 ／ アクセス拒否 Foundryが調査上限に達したら未確認範囲を残して人間へ引き継ぐ [B] [5] [7] ／ 構成案：MCP接続・評価は未実施 27 / 44
28. 本文③ / Foundryからの活用 開発者が読み取り調査と実行検証を区別する 開発者がMCP調査の対象範囲と人間へ戻す条件を決める 今回の読み取り構成で行うこと 別の機能・環境が必要なこと GitHub上のファイル・履歴の取得 ローカルの未push変更の取得 テストソースから確認観点を抽出 ビルド・テストの実行 識別子検索で関連箇所を探す 完全な呼び出し関係・影響範囲の保証 対象外：コード変更・PR作成・ワークフロー実行 ／ 検索漏れは「存在しない」の証明ではない 人間が未確認箇所を調査し、ビルド・テストで変更案を検証する [B] [5] ／ 構成案：MCP接続・評価は未実施 28 / 44
29. 本文③ / Foundryからの活用 非エンジニアがWebアプリで目的と対象を選ぶ Webサーバーが検索条件とMCPの参照範囲を利用者の権限で制限する 入力：質問：返品期限をランク別に変えられるか ／ 出力：営業と開発の次の会話 利用者の画面 サーバー 根拠の収集 回答表示 業務・要件整理／営業 向け実現性評価 認証済み利用者 対象ID・許可リポジト リ 業務資料：AI Search 設計・コード：GitHub MCP 資料ID・パス・SHA 未確認事項・エージェ ント版 目的・対象・質問 権限・対象で制限 Foundryで下書 き生成 Webサーバーがブラウザ指定の検索条件やリポジトリをそのまま信用しない [B] [1] [8] ／ 構成案：MCP接続・評価は未実施 29 / 44
30. 本文③ / Foundryからの活用 運用担当者が操作権限と閲覧範囲を分けて制限する 運用担当者がSearch用とGitHub MCP用の資格情報をサーバー側で管理する 用途 資格情報と操作の制限 別に必要な制御 作成・同期 管理者キー／Webには渡さない 作成・同期だけに限定 業務資料の検索 クエリキー／サーバーに保持 本人確認・対象ID・許可グループ GitHub MCP 限定PAT等＋readonly＋許可ツール 対象リポジトリの認可 利用者のブラウザ Searchキー・PATの配布なし 共有PAT ≠ 利用者本人の権限 運用担当者が利用者ごとの閲覧認可をサービス資格情報とは別に実装する [B] [3] [6] [8] ／ 構成案：MCP接続・評価は未実施 30 / 44
31. まとめ まとめ：今回お伝えした3つのポイント 営業・PM・開発担当者が、共通の資料を使って要望を具体化する 本文のテーマ 発表した内容 ① 上流工程のハーネス AGENTS.mdと役割別Markdown 会社の文脈・参照手順・判断条件の整理 ② 設計と製造の連携 設計・API・コード・テストの対応付け 同じ機能の仕様・実装・変更影響の照合 ③ 非エンジニアへの展開 FoundryのInstructions＋AI Search＋読み取り専用GitHub MCP 共通ルール・業務検索・コード調査を使うWeb画面 個人のプロンプト術から、会社全体で再利用できるAI活用基盤へ [A] [B] [C] [5] 31 / 44
32. まとめ 開発・運用担当者が既存の資料とAI支援を 非エンジニアへ広げる 営業・PM・開発担当者が根拠付き下書きを部門間の相談に使う 01 共通ルールと更新担当 02 業務資料の検索＋読み取り専用GitHub MCP 03 目的別Web画面と人間の承認 せっかく作ったものを、非エンジニアにも。 [A] 32 / 44
33. THANK YOU ありがとうございました ご質問・ご感想をお聞かせください Ochtum（オクトゥム） 33 / 44
34. 補足 補足：資料の情報分類 情報管理者がAIへ渡す資料を4区分で整理する 区分 例 試行時の扱い 公開可 公開済み製品情報 内容確認のうえ利用 社内限定 社内ルール・未公開設計 社内アクセス・更新者・レビュー者 機密 契約・顧客業務・価格 必要最小限／識別子・金額の置換 入力対象外 個人情報・認証情報・秘密鍵 入力・検索対象から除外 開発・運用担当者が最初の実証を実データを使わない架空案件に限定する [A] 34 / 44
35. 補足 運用担当者が作成・ドライラン・差分同期を順に確認する 運用担当者が接続先と資格情報を設定し、適用前の対象を確認する 操作 UpstreamHarnessLab のルートで実行するコマンド インデックス作成 dotnet run --project .\apps\SearchIndexProvisioner -- --apply 同期対象の確認 dotnet run --project .\apps\SearchIndexSync 差分の適用 dotnet run --project .\apps\SearchIndexSync -- --apply 設定：AZURE_SEARCH_ENDPOINT = https://<サービス名>.search.windows.net 設定：AZURE_SEARCH_ADMIN_KEY = <管理者キー>（共有資料には値を残さない） 初稿時のドライラン：業務3チャンク／設計・製造16チャンク 運用担当者が検証環境で対象を確認してから --apply を実行する [B] 35 / 44
36. 補足 開発・運用担当者が自動化と本番認証を段階的に確認する 開発・運用担当者が実同期の確認とActions構成案を区別する 段階 設定・実装すること 現在の扱い 実同期 SearchIndexSync → Azure AI Search 検証済み（発表者確認） Actionsで自動起動 mainマージ → --apply／検証用secrets 構成案・起動確認は別途 本番の資格情報 OIDCで認証・Azure RBACで権限制限 アプリ側のキー依存も変更・検証 実同期の検証状況：発表者確認（2026-09-25）／Web検索連携・作成単独試験は別 開発・運用担当者が認証方式・最小権限・監査ログを実環境で検証する [B] [4] ／ 実同期：発表者確認（2026-09-25） 36 / 44
37. 補足 AIが要件レビュー・整合性確認・レビュー統合を分担する Agent Frameworkのサンプルが三つの確認を順に実行する 順序 確認すること（役割の説明例） 次へ渡す内容 1. 要件レビュー 要件の不足・制約・例外の確認 指摘と根拠、未決条件 2. 整合性確認 資料間の条件・判断の食い違い 矛盾する箇所と確認先 3. レビュー統合 指摘をまとめ、判断事項を整理 根拠付き下書き・人間の確認事項 レビュー担当者が統合結果の根拠と未決条件を確認して採否を決める [B] 37 / 44
38. 補足 実証担当者が同じ質問で修正・見落とし・追跡性を測る 実証担当者が対象条件をそろえ、導入前後の差を記録する 評価する観点 記録する単位 比較時の注意 成果物の修正 修正回数・差し戻し理由 同じ完了条件で比較 条件の見落とし 要件・制約・例外の見落とし件数 レビュー観点を統一 追加説明 担当者の説明回数・所要時間 確認に使った時間も記録 根拠の追跡 資料・版・判断者まで追える回答の割合 分母：対象回答数 実証担当者が件数・所要時間・追跡できる割合を、差し戻し理由と比較する [A] 38 / 44
39. 補足 開発・運用担当者がMCP接続と調査制御を設定する 開発・運用担当者が限定したGitHub接続をFoundryのエージェント定義へ登録する 設定する箇所 最小構成の方針（実装・検証が必要） 接続先 https://api.githubcopilot.com/mcp/x/repos/readonly 許可ツール search_code / get_file_contents / list_commits / get_commit 資格情報・承認 限定PAT等をプロジェクト接続で管理／組織の承認方針 調査・回答 回数・時間・取得量で停止／パス・SHA・未確認事項を記録 参照認可はPATの範囲とサーバー側で強制。repo: 指定やInstructionsだけでは認可にならない。 開発・運用担当者が範囲外の参照と書き込み要求の拒否を確認する [B] [6] [7] [8] ／ 構成案：MCP接続・評価は未実施 39 / 44
40. 参照資料 参照資料：原稿と公開サンプル 読者が原稿とサンプルの出典を確認できる 資料・発行元 配布ZIP内の参照先／確認日 [A] 第1回：AIに会社の文脈を理解させる技術 Ochtum・提供原稿 assets/sources/articles/article-1.md 確認日：2026-09-25 [B] 第2回：GitHubの業務資料をAzure AI SearchとMicrosoft Foundryで使う Ochtum・提供原稿 assets/sources/articles/article-2.md 確認日：2026-09-25 [C] UpstreamHarnessLab：架空の設計・製 造資料とREADME 提供された架空サンプル assets/sources/sample-repositories/README.md 確認日：2026-09-25 HTMLはリンクから参照可。PDF単独では同梱ファイルを開けないため、ZIPも配布。 配布ZIPに元記事2本・図6点・架空サンプルを同梱 40 / 44
41. 参照資料 参照資料：検索とFoundryの公式情報 読者が検索制御とFoundry連携の公式情報を確認できる 資料・確認範囲 URL／確認日 [1] セキュリティフィルター 検索結果のグループ別絞り込み Microsoft Learn https://learn.microsoft.com/en-us/azure/search/search-securitytrimming-for-azure-search 確認日：2026-09-23 [2] FoundryのAI Searchツール サービス側の接続機能 Microsoft Learn https://learn.microsoft.com/en-us/azure/foundry/agents/howto/tools/ai-search?view=foundry 確認日：2026-09-23 本編：Webサーバー仲介方式 ／ 公式：FoundryのSearchツール接続 41 / 44
42. 参照資料 参照資料：資格情報と自動化の公式情報 読者がAPIキーの権限差とAzure向けOIDC設定を確認できる 資料・発行元 URL／確認日 [3] APIキーの権限差 Microsoft Learn https://learn.microsoft.com/en-us/azure/search/search-security-api-keys 確認日：2026-09-25 [4] Azure向けOIDC設定 GitHub Docs https://docs.github.com/en/actions/how-tos/secure-your-work/securityharden-deployments/oidc-in-azure 確認日：2026-09-25 読者がサンプルの構成案とサービスの仕様を区別して確認する [3] [4] 42 / 44
43. 参照資料 参照資料：GitHub MCPのツールと読み取り専用接続 読者がMCPの仕様と今回の構成案を区別して確認する 資料・発行元 URL／確認日 [5] GitHub MCP Server: repository tools GitHub https://github.com/github/github-mcp-server 確認日：2026-09-25 [6] Remote GitHub MCP: read-only endpoints GitHub https://github.com/github/github-mcp-server/blob/main/docs/remoteserver.md 確認日：2026-09-25 読者が利用可能なツールと認証条件を接続先環境で確認する [5] [6] 43 / 44
44. 参照資料 参照資料：FoundryのMCP接続と認証 読者がMCPの仕様と今回の構成案を区別して確認する 資料・発行元 URL／確認日 [7] Connect to Model Context Protocol servers Microsoft Learn https://learn.microsoft.com/en-us/azure/foundry/agents/howto/tools/model-context-protocol 確認日：2026-09-25 [8] Set up MCP server authentication Microsoft Learn https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/mcpauthentication 確認日：2026-09-25 読者が利用可能なツールと認証条件を接続先環境で確認する [7] [8] 44 / 44