はじめに
QA出身のPMO、JJです。
AIに設計書をレビューさせてみたものの、出てきたものを、そのまま担当者に渡せない。 この記事は、そこで止まっている人向けです。
私も同じところで止まりました。チャットにファイルを添付して「レビューして」と頼む。指摘は返ってくる。でも渡せない。
そこから5つ手を入れて、いつも使っているレビュー記録表（Excel）がそのまま出てくる状態まで持っていきました。その手順と、途中で見つけた判断基準を書きます。
なぜこれをやろうと思ったのかという経緯は、noteに書きました。この記事では手順に絞ります。
「たぶん大丈夫だろう」から「ここは直そう」へ。非エンジニアのPMOがCopilotで設計書レビューを試した話
この記事の前提
- 使っているのはCopilotです。ただし考え方は、ファイル添付とファイル生成ができるAIなら応用できると思います。
- AIへ渡す資料は、所属組織のルール上、利用を許可された情報だけにしてください。私の場合は、設計書を添付することについてあらかじめ承諾を得ています。ここは各自の環境で確認が必要な部分です。
- 実際の設計書、レビュー記録、プロンプト全文は載せていません。この記事のプロンプト例は、読者が試せるように私が組み直したものです。
こういう症状が出ていませんか
そのまま渡せない原因は、だいたいこの5つのどれかです。私は全部当たりました。
| 症状 | 何が足りていないか | この記事のどこで直すか |
|---|---|---|
| 指摘が簡素で、精度がいまひとつ | 推論の設定が弱い | 手順1 |
| 的外れな指摘が混じる | 背景と参考資料を渡していない | 手順2 |
| 毎回、指摘の内容がランダムに変わる | 渡す情報の型が固定されていない | 手順2 |
| 渡すたびにExcelへ転記している | 出力先がチャットのまま | 手順3 |
| 返ってくる形が毎回違う | 出力フォーマットを指定していない | 手順4 |
| 全量の抜け漏れ、上位資料とのつながりが分からない | 記録の作り方そのものの問題 | この記事では扱いません（末尾で触れます） |
上5つを直すのが、この記事の範囲です。
やってみて分かったのですが、出てこなかったのはAIのせいだけではありませんでした。私が渡した情報が足りていなかった。
全体の流れ
手順1 プロンプトより先に、モデル設定を見る → 症状1
↓
手順2 観点と参考資料を、AIから聞いてくるようにする → 症状2・3
↓
手順3 出力先を、チャットからExcelへ移す → 症状4
↓
手順4 出力フォーマットに、いつもの記録表を指定する → 症状5
↓
手順5 渡すときに、前置きを付ける → 運用
手順1: プロンプトより先に、モデル設定を見る
順番として、プロンプトを直す前にここを確認してください。
私は「自動」のまま使っていました。というより、モデルを選べること自体を知りませんでした。明示的に選び直したところ、指摘の精度も、後述するExcel出力の安定性も変わりました。
プロンプトをいくら工夫しても届かなかったところに、設定ひとつで届いてしまった。これが正直なところです。
確認する順番
- モデル設定に「自動」以外の選択肢があるかを見る
- あるなら、推論を厚くする設定を試す
- それでも足りない分を、プロンプトで補う
順番を逆にすると、設定で解決する問題をプロンプトで解こうとして時間を使います。私がそうでした。
比べるときの注意
- 同じ設計書と、同じプロンプトで比べます。 両方変えると、何が効いたのか分からなくなります。
- どのモデルが良いかは、時期・環境・用途で変わります。ここで言いたいのは特定のモデルの優劣ではなく、選択肢の有無を先に確認するということです。
- 選べるものは環境によって違います。まず自分の環境で何が選べるかを見てください。
手順2: 観点と参考資料を、AIから聞いてくるようにする
プロンプトを直すとき、書き方の方向を変えました。
必要なことを全部こちらから書くのをやめて、AIのほうから聞いてくるようにしました。
指示文の例です。
これから詳細設計書のレビューを行います。
いきなりレビューを始めないでください。
私が資料を渡す前に、次の2点を私に質問してください。
1. 今回のレビューで重点的に確認したい観点
2. 参考にすべき上位資料（基本設計書など）
私が回答して資料を添付したら、そこで初めてレビューを始めてください。
なぜ「聞いてもらう」ほうがいいのか
自分が使っているAIの機能を、全部把握している人は少ないと思います。何を渡せば精度が上がるのかを、こちらが先回りして全部書くのは難しい。だったら、聞いてもらったほうが確実です。
聞かれれば答えられます。レビュー観点は普段見ているものがありますし、参考資料も手元にあります。
足りないのは知識ではなく、渡し忘れです。
この形が症状3も直す理由
毎回同じ質問が返ってくるので、渡す情報の型が質問の形で固定されます。 プロンプトを毎回書き直さなくても、入力がそろうようになります。
症状2（的外れ）と症状3（毎回変わる）は、原因が同じところにあります。
手順3: 出力先を、チャットからExcelへ移す
指摘はチャット上に表で返ってきます。表としては読めるのですが、担当者へ渡すにはExcelへ転記する必要があります。
レビュー結果は、チャット上の表ではなく、
Excelファイルとして生成してください。
ここを飛ばすと仕組みが続かない理由
転記はレビューのたびに発生します。1回なら我慢できても、毎回だと続きません。
「AIにレビューさせてみた」で終わってしまう原因の多くは、精度ではなくこの手作業にあると思っています。 人の手が挟まる工程が残っている限り、その仕組みは定着しません。
精度の改善より先に、手作業をゼロにできないかを見たほうがいいです。
手順4: 出力フォーマットに、いつもの記録表を指定する
Excelで出せるようになったら、次はフォーマットです。
手順2の「聞いてくる」プロセスに、3つ目を足します。
（手順2の指示に追記）
3. 出力に使うレビュー記録表のテンプレート
テンプレートを受け取ったら、指摘事項は
そのフォーマットに厳密に従って出力してください。
列の追加や削除はしないでください。
聞かれたので、いつも使っている空のテンプレートを添付します。中身の入った実物ではなく、空の様式です。
出てきたのは、いつも自分たちが使っている、見慣れたレビュー記録表でした。フォーマットが同じというだけでなく、誰が見ても、どこに対する、どういう指摘なのかが分かる形になっていました。
新しい様式を作らないほうがいい理由
レビュー記録表は、担当者が普段から読み書きしているものです。見慣れた形で届けば、それがAI由来かどうかに関係なく、いつもの仕事として処理できます。
AIを持ち込むとき、新しいツールや新しい様式まで一緒に持ち込むと、受け取る側の負担が増えます。出力の形は、現場にすでにあるものへ寄せる。 これは他の作業へ応用するときにも効く判断だと思っています。
空の様式を渡す理由
- 中身が入っていると、レイアウトが崩れることがあります
- 中身が入っていると、AIへの入力範囲の判断が必要になります。空の様式なら、その判断が要りません
手順5: 渡すときに、前置きを付ける
出力がそろったら、担当者へ渡します。
私が添えたのは、こういう趣旨のことです。
これはAIが出した指摘です。必ず正しいとは限りませんし、全部を必ず修正しなければいけない指摘表でもありません。
そのうえで、こうお願いしました。
このなかで「確かにこれは修正する必要があるな」と、根拠をもって判断できたものだけを、公的な指摘として取り込んで対応してください。
これを手順に入れる理由
気遣いの話ではなく、手順の一部だと考えています。
前置きなしでAIの指摘一覧を渡すと、受け取った側は2つのうちどちらかに寄ります。全部直さなければと思って疲弊するか、AIの指摘だからと最初から相手にしないかです。どちらでもレビューの質は上がりません。
判断の余地があることを明示して初めて、相手は専門知識を使って選べます。
AIを使うのがこれからという現場ほど、この前置きは効きます。
この方法が効くとき、効かないとき
手順そのものより、こちらのほうが大事かもしれません。
効くと思うもの
- 出力の様式が決まっている成果物のレビュー。レビュー記録表、指摘一覧、チェックリストなど
- 上位資料がある文書。詳細設計書、テスト設計書、仕様書など
- レビュー観点が言語化できているもの
効きにくいと思うもの
| 条件 | どこで詰まるか |
|---|---|
| 出力の様式が決まっていない | 手順4が使えず、渡す形を毎回考えることになる |
| レビュー観点が人の頭にしかない | 手順2でAIに聞かれても答えられない |
| 図が主体の資料 | テキストとして渡せる情報が少なく、指摘も浅くなる |
| 上位資料がない | 手順2で渡すものがなく、的外れな指摘が減らない |
前提が変わると成立しないもの
- AIへ資料を添付できない環境。 この記事の全手順が成立しません
- モデルを選べない環境。 手順1が飛びます。手順2〜5は使えます
うまくいかないときの見直しどころ
| 起きること | 見直すところ |
|---|---|
| 精度が上がらない | プロンプトを疑う前に、モデル設定（手順1）。ここを飛ばしていることが多い |
| AIが質問せずにレビューを始めてしまう | 手順2の「いきなり始めないでください」を指示の先頭に置く。順序を入れ替えるだけで変わることがある |
| 指摘が的外れ | 参考資料が渡せていない。上位資料を添付できているか確認する |
| 毎回フォーマットが変わる | テンプレート添付が抜けている。手順4を「聞いてくる」形にすると抜けにくい |
| Excelは出るがレイアウトが崩れる | テンプレートに中身が入っている可能性がある。空の様式を渡す |
| 担当者が指摘表を放置する | 手順5の前置きが伝わっていない。渡し方を口頭で補う |
| 直す前より時間がかかっている | どこかに手作業が残っている。転記が復活していないか確認する |
AIに任せること / 人が決めること
| 内容 | なぜ | |
|---|---|---|
| AIに任せる | 指摘の洗い出し | 人が見きれない量を扱える |
| 指定フォーマットへの整形 | 転記の手作業をなくせる | |
| Excelファイルの生成 | 同上 | |
| 人が決める | レビュー観点 | ここを任せると、何を見たのか分からないレビューになる |
| 渡す参考資料 | 入力範囲の判断は人の責任 | |
| 指摘を対応するかどうか | 専門知識と文脈が要る | |
| 最終的な品質責任 | 手放せない |
観点と参考資料を人が決めているのが要点です。 ここをAIに任せると、出力はそれらしくなりますが、何を根拠にした指摘なのかを追えなくなります。
まとめ
明日から試すなら、この順です。
- モデル設定を見る。 「自動」以外の選択肢があれば試す。プロンプトを直すのはその後
- AIから観点と参考資料を聞いてくるプロンプトにする。渡し忘れが減り、入力の型も固定される
- 出力はExcelで直接生成させる。 転記の手作業を残すと続かない
- 出力フォーマットは、現場でいつも使っている様式を指定する。 新しい様式を持ち込まない
- 渡すときに前置きを付ける。 判断の余地を明示して、専門知識のある人に選んでもらう
判断基準としては、この2つが応用しやすいと思っています。
- 手作業が残る工程は、精度より先に潰す
- 出力の形は、現場にすでにあるものへ寄せる
扱わなかったこと
冒頭の症状のうち、6つ目が残っています。
全量に対して何が抜けているのか。上位の資料とのつながりはどうなっているのか。
ここに手をつけるために、レビュー記録表の指摘ひとつひとつに「該当箇所」の列を持たせています。この列を手がかりにすれば、基本設計書の内容が詳細設計書に抜けなく反映されているか、というトレーサビリティの確認にも使えるはずです。
こちらは現在、担当者に確認してもらっている最中です。結果が出たら、また書きます。
※ この記事は、筆者が利用を許可された環境と情報だけで試している個人の経験です。CopilotおよびAIモデルの一般的な仕様や利用条件を説明するものではありません。実際の設計書、レビュー記録、プロンプト全文、画面キャプチャは掲載していません。記事中のプロンプト例は、読者が試せるように筆者が組み直したものです。