AIレビューの設計

AIレビューの設計

チェックリストで「好みレビュー」を排除し、品質を安定させる

AIを導入しても回らなくなる現場の典型はこうです。

• AIが下書きを出す
• レビューが重くなる
• 直しが増える
• 結局、人が最初から書いた方が早い
• 使われなくなる

これはAIの問題ではありません。

レビューが属人化していることが原因です。

「なんか違う」

「もっとプロっぽく」

「弱い」

「刺さらない」

こういう"感想レビュー"は、直しの方向がブレます。

ブレると、AIも人も疲れます。

だから必要なのは、これです。

レビューを「好み」から「条件」に変える

＝チェックリストで品質を定義する

この記事が想定する読者：AIのレビューが重くて直しが増え、結局人が書いた方が早いと感じている担当者。

判断を誤るとどうなるか：「なんか違う」などの感想レビューだと方向がブレてAIも人も疲れ、使われなくなる。レビューを3層（Gate／Quality／Polish）に分け、要確認タグとコメントの型で負荷を下げると失敗しにくい。

結論：レビューは3層に分けると壊れない

レビュー項目を全部同じ重さで扱うと破綻します。

おすすめは「3層」です。

Gateだけ通せば最低限公開できる。

Qualityで安定する。

Polishは時間があるときだけ。

この設計が、運用を止めません。

1) Gate：重大事故チェック（公開の関所）

ここは ゼロを目指す領域です。

1つでも引っかかったら「差し戻し」ではなく「公開不可」です。

Gateチェックリスト（汎用）

• [ ] 価格・条件・規約を未確認で断定していない
• [ ] 数字・統計を出典なしで提示していない
• [ ] 禁止領域（法務/医療/金融等）を断定していない
• [ ] 成果保証・誇大表現になっていない
• [ ] 公開不可情報（固有名詞・内部情報）を含んでいない
• [ ] 一次情報と矛盾していない（または要確認扱い）

Gateを通せない文章は、うまく直すより先に

前提・参照元・例外集を整備する必要があります。

権限設計（Lv3を人が握る）と一次情報の固定は、AIに任せる範囲の決め方とAI時代の文章品質管理で解説しています。

2) Quality：品質チェック（安定運用の心臓）

Gateを通っても、読みにくい・伝わらない文章は成果が出ません。

ここで「再現性」と「判断可能性」を担保します。

Qualityチェックリスト（汎用）

• [ ] 目的と読者が冒頭で明示されている
• [ ] 前提（制約/条件）が明示されている
• [ ] 結論→理由→手順→チェックの流れになっている
• [ ] 抽象語で逃げず、具体例がある
• [ ] 次に取る行動が明確（読者の1歩が書かれている）
• [ ] 矛盾がない（前後で言っていることが一致）

3) Polish：磨き込み（余裕があるときだけ）

ここは"勝ち筋"を作る領域ですが、必須ではありません。

運用が止まるなら、切り捨てます。

Polishチェック（例）

• [ ] 文章が冗長でない（1文が長すぎない）
• [ ] 専門用語に説明がある
• [ ] 見出しが「読む価値」を示している
• [ ] 具体例が現場に近い
• [ ] 読者の反論（不安/疑問）を先回りして潰している

レビューを軽くする「要確認タグ」運用

レビュー負荷が重い最大要因は、

どこを見ればいいか分からないことです。

そこで、AIに義務化します。

確定できない領域には必ず「要確認タグ」を付ける

要確認タグ（例）

• 【要確認：価格/条件】
• 【要確認：規約/法務】
• 【要確認：数値/出典】
• 【要確認：公開可否】
• 【要確認：最新性】

レビュー担当はタグだけ見ればいい。

照合が終わったらタグを外す。

これだけでレビューは軽くなります。

要確認タグの設計と権限設計への組み込みは、AIに任せる範囲の決め方とAI時代の文章品質管理で扱っています。

「差し戻し」を減らすレビューコメントの書き方

属人化を止めるには、レビューコメントの型が重要です。

おすすめはこの3点セットです。

例

• NG： なんか違う
• OK： 「Quality-3（結論→理由→手順→チェック）に違反。手順が抽象なので、手順を3ステップで具体化。参照：仕様書○○」

この型にするだけで、直しが速くなります。

役割分担（RACI最小版）でレビューを崩さない

レビューが崩れるのは「誰が最終責任か」が曖昧なときです。

最小はこれで十分です。

1人運用でもOK。

ただし Gateだけは絶対に省略しない。

RACIの全体像は、AIに任せる範囲の決め方で解説しています。

週次改善：レビューKPIと直結させる

レビュー設計は、KPIと組むとさらに強くなります。

レビューが重いのは「人が悪い」のではなく、

プロトコルが薄いサインです。

運用を数字で見る方法は、AI運用のKPI設計で扱っています。

まとめ：AIレビューは"条件化"すると軽くなる

• Gate（重大事故）
• Quality（品質）
• Polish（磨き）

この3層でレビューを設計し、

要確認タグで見る場所を明確にし、

コメントを型にすれば、AI運用は回ります。

判断の土台として押さえておくこと

• レビューは3層（Gate／Quality／Polish）で設計する：Gateは重大事故チェック・公開の関所。Qualityは品質の心臓。Polishは余裕があるときだけ。全部同じ重さにすると破綻する。
• 要確認タグで「見る場所」を限定し、コメントは違反項目・直し方・参照一次情報の3点で型化する：属人化を止めると負荷が下がる。
• 次の一手：品質4原則はAI時代の文章品質管理、権限・要確認タグはAIに任せる範囲の決め方、KPIはAI運用のKPI設計、例外集は例外集の作り方を参照する。