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

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

GitHub Copilotなどの生成AIを、要件定義やレビューにも広げたいエンジニア
PM、営業、企画、業務担当者とAI利用の前提をそろえたいチーム
30分の技術セッションで、上流工程のAI活用を具体的に伝えたい方

生成AIを使っていると、「コードを読ませれば、あとはAIが考えてくれる」と感じる場面があります。ですが、要件定義や営業提案のような上流工程では、コードだけでは判断できません。

たとえば営業から「会員ランクごとに返品期限を変える機能は実装できますか。できるなら工数はどの程度ですか」と質問された場合を考えてみます。回答には、現在の実装だけでなく、製品仕様、顧客との約束、業務ルール、過去に採用しなかった案、あるいは発生した不具合、承認が必要な変更を確認する必要があります。

この記事では、AIが業務上の判断に必要な情報を参照できる状態にするための、上流工程向けハーネスエンジニアリングを紹介します。ここで言うハーネスエンジニアリングは、資料、実行手順、確認条件、人間が判断する条件を整備する考え方を指します。

🔷 1. 既存システムのAI支援から、上流工程の判断支援へ

8月には、既存システムをAIが安全に理解・変更・検証できるようにするハーネスエンジニアリングを扱いました。公開資料では、AIへ渡すべきものはコードだけではなく、目的、対象、完了条件、実行手順、制約、承認条件であると整理しています。

人間とAIの担当を、次のように分けると考えやすくなります。

担当	主な役割
人間	目的、優先順位、制約、受け入れ条件等の決定、顧客への約束
AI	調査、影響確認、下書き作成、実装案、検証案、結果の整理

既存システムの変更であれば、コード、設定、テスト、ログ、画面確認の方法が主な判断材料です。一方、上流工程では顧客条件、業務ルール、決定履歴、承認条件も必要になります。

上流工程では、もっともらしい文章を作ることよりも、回答に必要な前提を取り違えないことが重要です。AIが知らない条件を、もっともらしく補完してしまう状態は避けなければなりません。

上流工程のAI活用では、コード以外の判断材料を整えます。

この違いが、今回の出発点です。AIに渡す資料を増やすこと自体が目的ではありません。質問に対して、どの資料を確認すればよいかをチーム単位で再現できるようにします。

🔷 2. 誰が何を更新し、AIがいつ参照するかを決める

資料を一つの巨大なMarkdownにまとめると、更新責任や参照する範囲があいまいになります。そこで、情報の種類ごとにファイルを分けます。

ファイル	主に記録する内容	主な利用場面
`AGENTS.md`	読む順番、禁止事項、必須確認、詳細資料への参照先	AIが作業を始めるときの共通ルール
`PROJECT.md`	目的、範囲、制約、スケジュール	PMが要件の不足や未決事項を整理するとき
`PRODUCT.md`	対象者、機能、用語、仕様	企画・営業・開発が製品の前提を確認するとき
`CUSTOMER.md`	顧客の業務背景、課題、個別条件	営業やPMが顧客向けの提案を考えるとき
`BUSINESS_RULES.md`	計算・判定条件、例外、適用範囲	業務担当者と開発者が条件を確認するとき
`DECISION_LOG.md`	決定内容、理由、決定者、影響範囲	過去の判断を確認するとき
`REVIEW_POINTS.md`	確認観点、合格条件、責任分担	要件・設計・提案をレビューするとき

それぞれの資料には、本文だけでなく、少なくとも次の項目を持たせます。

資料IDと版
状態（下書き、レビュー中、承認済み、廃止済み）
適用開始日・終了日
情報分類
管理責任者と承認者
適用対象の会社・顧客・製品・案件ID

こうしておくと、AIが古い判断や下書きを回答根拠として使うことを避けやすくなります。また、資料を更新する人と確認する人が決まるため、ファイルだけが増えて放置される問題も減らせます。

AIが参照する資料は、利用者と質問に合わせて選びます。

🔹 `AGENTS.md` はFoundryで自動的に読まれるわけではありません

ここは誤解しやすい点です。GitHubに置いた AGENTS.md を、Microsoft Foundryのエージェントが自動で読み続けるわけではありません。

今回の公開サンプルでは、FoundryPilot が AGENTS.md を含む選択済みMarkdownを、Prompt AgentのInstructionsとして登録します。つまり、AGENTS.md はエージェントが毎回守る共通ルールの入力になります。

GitHub上のファイルを更新したときは、内容を確認したうえで新しいエージェントバージョンを登録します。資料の変更とエージェントの命令更新を同じ作業として扱わないことがポイントです。

🔷 3. 営業質問を、設計と実装の根拠付き下書きへ変える

上流工程向けハーネスの効果が分かりやすいのは、営業からのカスタマイズに関する質問(以降、実現性評価と呼びます)です。

ここでは、架空の質問を使います。

会員ランクごとに返品期限を変える機能は実装できますか。可能であれば、影響範囲と概算工数を教えてください。

この質問へ、AIが「できます。工数は3人日です」とだけ答えるのは危険です。少なくとも、以下を確認する必要があります。

返品期限に関する現在の業務ルール
会員ランクを取得するAPIやデータの有無
返品期限を使う画面、バックエンド、外部連携、テスト
過去に一律の返品期限を採用した理由
変更時に顧客・運用・法務などの確認が必要か

公開サンプルでは、返品期限変更を題材にした架空の設計資料、OpenAPI定義、C#実装、テストを用意しました。営業向け実現性評価エージェントは、これらを根拠にして次の順で下書きを作ります。

実現可否
根拠
影響範囲
概算の大きさ（S/M/L）と確度
リスク・制約
確認事項
人間が次に判断すること

営業向けのAI回答は、根拠と確認事項を人間の判断へつなげます。

S/M/Lは、営業やPMが早い段階で論点をそろえるための概算です。正式な工数、契約条件、顧客への約束をAIが決めるものではありません。回答に「確認が必要な条件」と「決める担当者」を残すことで、AIの回答結果を「下書き」として、安全に次の会話へ使えます。

🔷 4. 実務へ入れる前に、資料の扱いと確認手順を決める

上流工程では、顧客情報、未公開の設計、価格、社内ルールを扱う可能性があります。便利だからといって、AIにどの情報も平等な扱いをさせてはいけません。

最初に、資料を次のように分類すると進めやすくなります。

区分	例	AIへの扱い
公開可	公開済み製品情報、公開規約	内容を確認して利用する
社内限定	社内ルール、未公開の設計	社内のアクセスに限定し、更新者とレビュー者を記録する
機密	契約条件、顧客の業務詳細、価格・戦略	必要最小限にし、識別子や金額を置換する
入力対象外	個人情報、認証情報、秘密鍵、接続文字列	AIの入力や検索対象に含めない

本記事を参考にして実証を始める段階では、実データを使わない架空の1案件・1製品・1顧客を選ぶ方法がおすすめです。公開サンプルもこの方針で作っています。

また、AI活用の効果を確認するには、次のような項目を比較できます。

成果物の修正回数と差し戻し理由
要件・制約・例外条件の見落とし件数
担当者が追加説明した回数と所要時間
回答から、参照した資料・版・判断者を追跡できる割合

現時点では、社内資料を使った比較結果はありません。公開サンプルで実装とローカル確認を行った範囲と、今後の社内実証で確認する範囲を分けて扱うことが重要です。

✅ 5. まとめ：最初は一つの質問と一つの案件から始める

上流工程でAIを使うときは、プロンプトを長くする前に、AIが確認する情報と、人間が判断する場面を整理しましょう。

コード以外に、顧客条件、業務ルール、決定履歴、承認条件が必要です。
資料ごとに、記載内容、更新者、承認者、参照する質問を決めます。
営業の実現性評価では、AIに正式見積を任せず、根拠・影響範囲・確認事項を下書きさせます。
最初は架空の小さな対象で、資料追加、レビュー、質問回答の流れを確認できます。

次回は、GitHubで管理する資料をAzure AI Searchへ同期し、Microsoft FoundryのエージェントとWebアプリで利用する実装を紹介します。

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