AIに成果物を作らせ、そのまま同じAIに採点させると、評価が甘くなりがちです。作った理由や意図をすでに知っている状態で振り返るため、粗が見えにくくなるのは自然なことです。運営元では、この問題に対して「作った人と評価する人を分ける」という単純な原則を組織のルールにし、Skillとして各部署に統一の形で配布しています。それが/reviewです。
生成と評価を別人格に分ける
Customer Serviceを除く全部署に、クリティカルレビュー専任の担当を置いています。成果物を作ったメンバー自身ではなく、この専任担当が批判的な視点で精査し、その結果をディレクターに報告します。ディレクターが確認し、必要なら担当者に修正を指示するという流れです。作業したAIがそのまま評価まで担うと、意図の正当化が入り込みやすくなります。役割を分けて、評価だけを独立したコンテキストで行わせることが狙いです。
評価はA〜Dの4段階
評価スケールは4段階に固定してあります。SKILL.mdの記載は次の通りです。
| グレード | 意味 |
|---|---|
| A | 高品質・承認推奨 |
| B | 軽微な修正で承認可 |
| C | 修正後再レビュー必要 |
| D | 根本的見直し推奨 |段階を固定しておくことで、レビュワーごとに評価の粒度がばらつくのを防いでいます。「悪くない」「まあいい」といった曖昧な表現に逃げず、必ずどこかのグレードに当てはめて報告する仕組みです。
指摘は重大・中程度・軽微で分ける
問題点を並列に列挙するだけでは、担当者はどこから直せばいいか分かりません。そのためレビューでは指摘の重大度を分けて報告する形式を取っています。加えて、批判一辺倒にならないよう良い点も必ず書くこと、指摘には改善案を添えること、根拠と論理に基づくことを原則としています。「なんとなく質が低い」という感覚的な指摘は認めていません。
評価基準そのものを毎回議論しない
レビュー観点や報告フォーマットを担当者ごとに毎回考えさせると、部署間で基準がぶれます。運営元では、評価基準と報告フォーマットをSkillとして固定し、全部署が同じ物差しでレビューする形にしています。評価対象は成果物の品質だけではありません。組織の公開ルールとの整合や文章規範の適用痕跡、成果物の置き場所やファイルの後始末といった観点も、レビューの共通チェック項目として組み込まれています。品質評価と運用ルールの遵守確認を1つのレビュー行為にまとめることで、レビュー担当が見るべき範囲を毎回定義し直す手間をなくしています。
自分の組織で真似るには
- 自己採点をさせない。成果物を作ったAIやメンバーとは別の主体に評価させるだけで、指摘の精度が上がります。同じAIでも、評価用に別のコンテキストで起動させれば効果があります。
- 評価基準と報告フォーマットをSkill化する。グレードの段階、指摘の重大度分け、良い点も書くという原則を固定して配布すれば、担当者や部署が変わっても評価の粒度がぶれません。
- 品質だけでなく運用ルールの遵守もレビュー項目に含める。成果物の出来栄えとルール違反のチェックを別々の作業にせず、1回のレビューでまとめて確認できるようにしておくと、抜け漏れが減ります。