【AI×設計レビュー】面倒な「反映もれの確認」を、サクっと誰でもできるように。Copilotのエージェントを育てた話

Last updated at 2026-09-16Posted at 2026-09-16

はじめに

「基本設計書の内容は、全部詳細設計書にもれなく記載できてるんだよね？」

詳細設計書のレビュー会で、PMやPLがこう聞く場面があります。返ってくるのは、たいていこれです。

「してます。大丈夫です」

ただ、言い方に少し間が空くことがある。全部書けてます（たぶん）、と言っているように聞こえる。

誰かを疑いたいわけではありません。確認した過程が見えないから、毎回聞くしかない。

はじめまして、JJです。SESとして現場に出ている、QA出身のPMOです。

直近では、noteに「上位資料の要件、漏れなく反映できてる？」複数チームの同じ指摘を、Copilotで確かめてみた話を、QiitaにCopilotの設計書レビューを、そのまま渡せるExcelにするまでを書いています。

今回は、その設計書レビューのエージェントに網羅性の観点を足していった過程を書きます。

ポイントは、エージェントを一度作って終わりにしないことです。最初から作り込まず、小さく試して、返ってきたものを見ながら育てる。 私の場合、いい形になるまでに2回のつまずきがありました。どちらも、直したのは精度ではなく渡す情報と、出力の置き場所です。

この記事では、次の三つを持ち帰れます。

設計書レビューのエージェントを、作り込まずに小さく試して使い始める流れ
レビューを受けた人の声を、エージェントの改良に変える手順
既存のレビュー記録表を壊さずに、指摘の位置情報を届ける直し方

🎯 やりたかったのは、「たぶん」を潰すこと
🌱 出発点は、雑な希望で作ったエージェント
🧊 一つ目のつまずき「それは詳細設計書に書くので」
🧩 打ち手は、渡す資料を増やすことだった
✅ 何が変わったか
📍 二つ目のつまずき「その列、記録表にありません」
🔁 いまの形は、対話型のエージェント
👀 人が決めること
🚧 エージェント機能を使えない場合
まとめ

🎯 やりたかったのは、「たぶん」を潰すこと

確かめたいのは、これだけです。

基本設計書から詳細設計書へ引き継ぐべき内容が、漏れなく反映されているか。

ところが、レビュー会の冒頭でその説明があることは多くありません。だから毎回聞くことになる。信じるか、聞き直すか、どちらかしかない。この状態を仕組みで抜けたいというのが出発点でした。

なぜそう思ったのかという背景はnoteのほうに書いたので、ここでは作り方だけに絞ります。

前提です。

使うのは、Copilotのエージェント作成機能です。特定製品の仕様や利用可否については触れません
AIへ渡す情報は、所属組織のルール上利用を許可された情報だけにしてください
例に出す表と指示文はすべてダミーです。 実際の設計書やレビュー記録は載せていません
推論に強いモデルを選べる環境なら、先に選んでおいてください。 同じ依頼でもモデル設定で結果が変わりました。詳しくは前回のQiitaに書いています

🌱 出発点は、雑な希望で作ったエージェント

最初にやったことは、たいしたことではありません。

エージェント作成機能に「設計書のレビューをしたい」という雑な希望を出しただけです。

このとき、基本設計書用とか詳細設計書用とか、専属のエージェントを作るつもりはありませんでした。 そこまで考えていなかった、というのが正直なところです。

できたエージェントを、まず基本設計書に使ってみました。流れはとてもシンプルです。

エージェントを起動する
    ↓
レビュー対象の設計書を添付する
    ↓
レビューしてもらう

出力はチャット上に表で返ってきます。お試しだったので、参考程度にと思いながら、その表をExcelへ転記して、レビューを受ける人へ渡してみました。

（この転記をなくして、いつものレビュー記録表へ直接出させるまでは前回のQiitaに書いています。この記事では、そこから先の話をします）

まず1回、添付して出させてみる。 ここまでは10分もかかりません。エージェントを作り込むのは、使ってからで間に合います。

🧊 一つ目のつまずき「それは詳細設計書に書くので」

渡した結果、こういう声をもらいました。

基本設計書のレビューだけれど、詳細設計書やほかの設計書に書く内容だから、あえて基本設計書には書いていない。そういう観点の指摘が多数出ている。そこは改善したほうがよい。

自分で気づいたわけではありません。渡した相手から教えてもらいました。

言われてみればそのとおりです。AIは、その現場で「どの文書に何を書くか」がどう決まっているかを知りません。 だから、基本設計書に無いものを機械的に拾って、指摘として並べます。

ここで大事なのは、これを失敗として片づけないことです。課題がはっきりしたので、直すところが見えました。 渡していなければ「なんとなく精度が悪い」で終わっていたと思います。

お試しでも、人に渡してみてください。 一人で眺めていても、この声は出てきません。

最初から100点なはずがないんです。仮説を立てて、使ってみて、インサイトをもらって、ブラッシュアップする。その繰り返しで100点に近づけていく。そんなんでいいんです。まずは行動です。

もちろん、渡す相手に迷惑をかけないようにはします。その資料を渡してよいか、出力に明らかな間違いが混ざっていないか。そこの裏どりだけ先にやっておくのがミソです。

🧩 打ち手は、渡す資料を増やすことだった

同じころ、冒頭の「たぶん」をどうにかしたいと考えていました。そこで思いついたのがこれです。

上位資料も一緒に添付して、網羅性の観点を組み込んでレビューしてもらえばいいのではないか。

一つ目のつまずきと、この思いつきは、同じ場所につながります。どちらも「AIに渡す情報が足りていない」という話でした。指示文の書き方の問題ではありません。

やったことは、エージェントを作り直すことではありません。エージェント編集のチャットで、追加してほしいことを依頼しただけです。

依頼したのは、こういう趣旨のことです。

レビュー対象の設計書だけでなく、その上位資料も添付します。
上位資料に書かれている内容が、レビュー対象の設計書に
漏れなく反映されているかという観点を、レビューに加えてください。

これでブラッシュアップされたエージェントを、次のレビューで使いました。

エージェントは、作り直すより育てるほうが早いです。 対話で足せる範囲なら、それで済みます。

✅ 何が変わったか

手応えがありました。

具体的には、詳細設計書のレビュー会で、基本設計書をインプットとして添付し、網羅性の観点を入れて出力してもらいました。

返ってきたのは、この3種類の指摘です。

指摘の種類	内容
記載なし	基本設計書にあって、詳細設計書にない箇所
文言の差異	同じことを指しているが、言葉が食い違っている箇所
整合性の差異	ロジックなど、内容そのものが噛み合っていない箇所

指摘する観点が絞られたことで、本来やりたかったレビュー指摘がかなり明確になりました。

一つ目のつまずきで出ていた「そこは詳細設計書に書くので」という的外れな指摘も、私の環境では減りました。

なぜ減ったのかを、断定はできません。上位資料を渡せば文書間の役割分担まで必ず判断できる、という話ではないからです。少なくとも、対象の設計書だけを見せていたときより、文書どうしの関係を踏まえた指摘が増えました。

📍 二つ目のつまずき「その列、記録表にありません」

指摘の中身がよくなったので、次はどこへの指摘なのかを分かるようにしたいと思いました。

最初にやったのは、単純です。レビュー結果の表に、列を追加しました。 基本設計書のどの章のどの部分に対する指摘なのかを書かせる列です。

これはこれで見やすかったです。

ところが、そのあとで困りました。

前回のQiitaに書いたとおり、プロジェクトのレビュー記録表を添付して、そこへ出力させる流れにしていました。その記録表に、追加したかった列はありません。

記録表そのものを直せば入りますが、プロジェクト全体で使っているものなので、影響が読めません。

そこで方針を変えました。列を足すのをやめて、指摘の文章そのものに位置情報を含めるようにしました。

指摘内容には、どの設計書の、どのシートの、どの章の、
どの記載に対する指摘なのかが分かるように書いてください。

出力例です。

指摘事項
基本設計書「機能一覧」シート 2-3 検索条件に記載のある検索期間の上限について、詳細設計書側に対応する記述が見当たりません
基本設計書「機能一覧」シート 2-1 権限制御と、詳細設計書 4.2 の記述で、対象となる利用者の範囲が食い違っています

（ダミーです）

これで、いつもの見慣れたレビュー記録表へ、そのまま出力できるようになりました。

見やすさだけを取るなら、列を足したほうがよかったかもしれません。ただ、受け取る側が普段使っている様式を変えずに済むほうが、運用として続きます。

AIにとってきれいな表を作るより、現場がすでに使っている表へ合わせる。 前回のQiitaでも書いた判断ですが、ここでも同じでした。

🔁 いまの形は、対話型のエージェント

さらに手を入れて、いまはこういう流れになっています。

エージェントを起動する
    ↓
レビュー対象のファイルをチャットへ添付する
    ↓
インプットとした設計書や資料はあるか、エージェントが聞いてくる
    ↓
上位資料を添付する
    ↓
その工程のレビュー記録表（プロジェクト公式のもの）を添付する
    ↓
Excelのレビュー記録表が出力される

エージェント側から聞いてくる形にしたのが要点です。 こちらが毎回思い出して添付する形だと、忘れます。忘れると、一つ目のつまずきに戻ります。

ここでやったのは、AIの精度を上げることではありません。人は必要な資料を添付し忘れる、という前提でフローのほうを変えました。 精度の問題に見えていたものが、実は手順の問題だった、という話です。

工程ごとに専用のエージェントを作らなくても使える形を目指して、記録表は毎回その工程のものを添付する作りにしました。私が試したのは基本設計書と詳細設計書のレビューまでですが、この形なら添付するものを差し替えるだけで済みます。最初は専属を意識していなかったのですが、結果的にそれでよかったことになります。

👀 人が決めること

ここから先はAIの仕事ではありません。

出てきた記録表を、設計書を書いた本人と有識者へ渡します。渡すときの言い方は、連載を通じて同じです。

これはAIが出した指摘です。必ず正しいとは限りませんし、全部を直さなければいけないものでもありません。根拠をもって「これは直す必要がある」と判断できたものだけ、公的な指摘として取り込んでください。

分担はこうです。

	内容
AIに任せる	上位資料との突き合わせ、一次判定、該当箇所の特定、記録表への出力
人が決める	本当に記載がないのか、それが問題か、対応するか、渡してよい資料はどれか

「記載が見当たりません」は、記載がないことの証明ではありません。 AIは読み落としも誤読もします。AIが出すのは確認候補まで。問題かどうかは人が決めます。

この線引きは連載を通じて変えていません。

🚧 エージェント機能を使えない場合

会社や現場のポリシーでエージェント機能を使えない場合も、ここまでの型は使えます。

レビュー対象と一緒に上位資料も添付する
出力先にいつものレビュー記録表を指定する
指摘の文章に位置情報を含めさせる

この3つは、通常のチャットでも同じように依頼できます。エージェントにする利点は、毎回書かなくて済むことと、向こうから聞いてくれることです。順番と渡すものが同じなら、効果は変わりません。

まとめ

今回やったのは、精度の高いプロンプトを書くことではありません。

最初から作り込まない。使ってから育てる。 改良のきっかけは、お試しの出力を渡した相手からもらった
AIの精度より先に、渡す情報を疑う。 足りなかったのは指示文ではなく、上位資料だった
出力はAIに合わせず、既存の運用へ合わせる。 列を足すのをやめ、指摘の文章に位置情報を含めた
AIが出すのは確認候補まで。判断は人が持つ

最初から完成したエージェントを作る必要はありません。まずは設計書を1つ添付して、出力を眺めるところからで十分です。私もそこから始めました。

エージェントを育てるのは、AIがかなり助けてくれます。 対話で「これも見てほしい」と足せば、たいてい足りました。

でも、どの資料を渡してよいか、その指摘が本当か、記録表をどう運用するかを決めるのは人です。

最後に、対話型にしたもう一つの理由を書いておきます。

プロンプトを自分で組み立てられる人には、エージェントは要らないと思います。 都度書けばいいからです。でも、プロジェクトにはいろんな人がいます。得意な人もいれば、そうでない人もいる。誰が使っても、毎回できるだけ同じ結果が出る。 そこを工夫したかったので、向こうから聞いてくる形にしました。

AIやツールのような便利なものを使って属人化を減らし、品質の民主化に近づけたい、というのが根っこにある考えです。もちろん、最後に判断するのは人だという線は動かせません。それでも、人が判断する手前までを仕組みで揃えておけば、判断する人はもっと楽になるはずです。

私はこれからも、レビュー会で「たぶん」が出るたびに、そこは仕組みで救えないかなと考えていこうと思います。

これまでに書いた記事

note

Qiita

※本稿は筆者の実務経験をもとに、案件・顧客・組織・人物・数値などを特定できないよう抽象化・再構成しています。AIへは利用を許可された情報だけを入力し、掲載する事実、表現、公開範囲は筆者が確認します。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up