はじめに
PMとしてソフトウェア開発のクライアントワークをしています。資料のレビューをClaudeで3回回す仕組みを作り、一度受けた指摘を次の資料で受けずに済むようになりました。きっかけは、一緒に働いていた統括PMに資料作成が速い理由を聞いたことです。
統括PMは、資料同士をAIにレビューさせていた
ある案件で、私は補佐のPMとして入っていました。上にいたのは、複数の案件に責任者として入る統括PMです。それでも、その方の資料は速くて質も高いものでした。
理由を聞くと、要求、要件、設計書、実装手順書といった開発資料を一式Googleドライブにまとめ、Claudeに資料同士をレビューさせていました。資料のあいだの矛盾やつながっていない点、表記揺れといった細かいズレをAIに拾わせるやり方です。
確定した上流の資料を材料にレビューさせる
話を聞いて、自分のやり方も変えました。関連資料をフォルダにまとめ、それを材料にレビューするようClaudeに指示しています。
たとえば詳細設計書を作るときは、確定した要件定義書と基本設計書を材料にレビューさせます。資料同士で用語や名称が食い違っていれば、上流の資料に揃えるのがルールです。
過去の指摘をレビュー観点の一覧にする
過去に受けた指摘のうち、その場限りの指摘は除き、次の資料でも使える指摘だけを残してレビュー観点の一覧にまとめました。Claudeはこの一覧に沿ってレビューします。観点は「重要」と「通常」に分けています。
# 内容レビューで確認する観点
目標: 指摘漏れゼロ
## 重要
外れると結論、範囲、総額が変わる項目。
または読み手が資料の前提を取り違える項目。
### 比較対象と範囲
- 依頼者と合意した比較対象と、本文で比べている構成要素が一致している
- 本文に、対象の層以外の製品や構成要素が入っていない
- スコープの境界が曖昧な箇所がない。境界をまたぐ処理や費用を、含むか含まないか明記している
- 範囲を示す図があり、本文の範囲と一致している
### 図解
- 文だけでは分かりにくい構成、範囲、データの流れが、図で示されている。図がない場合は、図を入れる箇所と図の内容を指摘する
### 費用
- 内訳に、テスト、レビュー、PM、インフラ構築の行がある
- 総額に、別の判断で決まる費用が入っていない
- 人月単価が現実的な水準である
### 文章
- 誰が何を作るかを、初見の人が読み取れる
## 通常
外れても結論は変わらず、表現や明記の不足で済む項目。
### 構成
- すべての表の直前に導入文がある
### 費用
- 含むテストと含まないテストが、種類ごとに書かれている
- 比率で出した工数の比率が、全体の規模に見合っている
- 為替レートが書かれている
- クラウド利用料の対象環境が、前提事項に書かれている
重要の先頭にある「比較対象と範囲」は、私自身が比較対象とスコープのずれで指摘を受けた経験と対応しています。
この一覧を持たせてから、以前は細かいものを含めて10件ほど受けていた指摘が、最後のほうは2〜3件になりました。
内容レビューは、まっさらなAIエージェントで3回直列に回す
内容レビューは、前の会話を引き継がない新しいAIエージェントで3回順番に行います。
- 1回目：観点と推敲ルールの全項目で、資料の全文を確認して指摘を出す
- 2回目：1回目の指摘を受け取り、1回目が拾えていない指摘と1回目の誤りを探す
- 3回目：1回目と2回目の指摘を受け取り、まだ拾えていない指摘と誤りを探す
途中で指摘が0件になっても、残りの回は省略しません。全項目の確認結果と全文を見たという宣言がない回は、やり直しです。
1回目で平均20件ほど、2回目と3回目でも5〜10件ほどの指摘が出ます。合わせて30〜40件ほどを実際に修正しています。
AIは指摘を出すだけで、資料は直しません。指摘ごとに「直す」「判断が必要」「スキップ」の区分が付き、どれを直すかは私が決めます。
表記はスクリプトで全件検出し、AIは判定だけする
内容レビューの反映後に、表記チェックを1回行います。用語集にある使わない言葉や資料ごとに決めた表記、文末の揺れなど、機械的に拾えるものはPythonのスクリプトで全件検出します。「変える」を「変更する」にするような言い換えも、活用形まで拾います。
AIに任せるのは、検出結果を1件ずつ判定することと用語集にない口語を探すことだけです。
手順と観点はObsidianに置き、スキルは実行方法だけにする
手順と観点の正はObsidianに置いています。Claudeのスキル側にはClaudeでどう実行するかだけを書き、中身は毎回Obsidianから読ませます。両者が食い違ったらObsidianに従います。顧客名や案件固有の名称は、Obsidianには書き込みません。
資料作成/
├ 00_資料作成の入口.md
├ ツールごとの制約とルール/
│ └ Googleドキュメントの制約と作業ルール.md
├ 資料を作る/
│ ├ スキル_資料を作る手順.md
│ └ 資料を作るときに確認する観点.md
├ 資料をレビューする/
│ ├ 内容レビュー/
│ │ ├ スキル_内容レビューの手順.md
│ │ └ 内容レビューで確認する観点.md
│ ├ 表記チェック/
│ │ ├ スキル_表記チェックの手順.md
│ │ ├ 表記チェックで確認する観点.md
│ │ └ 表記チェックの検査スクリプト.py
│ └ レビュー指摘への対応/
│ └ スキル_レビュー指摘への対応手順.md
└ 資料作成とレビューに共通のルール/
├ 使わない言葉と言い換えの用語集.md
├ 文章の推敲ルール.md
└ 資料の書式ルール.md
資料を作ったら、内容レビュー、指摘の反映、表記チェック、人のレビュー指摘への対応の順に進めます。
残っている課題
この仕組みが担っているのは、ミスの指摘と修正です。基本的な構造の矛盾やミスは大体拾えるようになりました。
一方で、説明が分かりにくい箇所や、どこにどんな図を入れると見やすいかの判断は、まだAIにできていません。こうした付加価値を考える部分は、別のエージェントに任せられないか考えているところです。
また、前提を丁寧に伝えないとAIのレビューがうまくいかないことも多くあります。最終的には人のチェックが必ず必要です。