AI社員の育て方
AI社員の育て方 / 第5章: 合格基準を先に決める

第5章: 合格基準を先に決める

CC Company（シーシーカンパニー）のマーケティング部がnote記事を量産し始めた頃のことです。23本目の記事を書き上げて品質チェックにかけたところ、86点でした。

86点。悪くないように聞こえるかもしれません。しかし、それまでに書いた記事は92点から97点の間に収まっていました。86点は明らかに低い。読み返すと、たしかに「読者がこの人に仕事を頼みたいと思うか」という観点が弱い。具体的に言えば、「痛みの名前化」（読者が抱える課題に名前をつけること）が抜けていて、導線が曖昧でした。

修正して、93点まで引き上げました。

ここで立ち止まって考えてみてください。もし品質チェックの基準がなかったら、この86点の記事はどうなっていたでしょうか。「まあ、いい感じだな」とそのまま公開していたはずです。そして「なんか反応悪いな」と首をかしげるだけで、原因が分からないまま次の記事に進んでいた。

ものさしがなければ、良い悪いの判断すらできない。これが本章のテーマです。本書ではこの、基準がないまま「それっぽい」成果物を受け入れ続ける状態を「それっぽい症候群」と呼んでいます。

あなたの現在地を確認する

3つともチェックが付いた方: 合格基準が機能しています。第6章で「品質サイクルの回し方」に進みましょう。

1〜2個の方: 基準はあるが曖昧、または基準はあるが運用が甘い状態です。この章で「数値化」と「運用」の両方を固めましょう。

チェックがゼロの方: AI社員が「できました」と言えばそのまま受け取っている状態です。この章が最も効く章になります。基準を設けるだけで、成果物の品質が目に見えて変わります。

「できました」を疑った日

CC Companyを作り始めた当初、14部署を立ち上げました。しばらく運用してから各部署の品質を点検したとき、愕然としました。品質チェックがまともに機能していたのは、法務部だけだったのです。

法務部の契約書レビューには、最初から明確なルールがありました。100点満点で採点し、85点以上で合格。不合格の場合は具体的なフィードバックを付けて差し戻し、最大5回まで修正を繰り返す。

残りの13部署はどうだったか。AI社員が「できました」と言えば、それが「合格」になっていたのです。

マーケティング部は記事を出してはいました。しかし「何点以上なら合格」という基準がなかった。だから出てきた記事が良いのか悪いのかを客観的に判断できませんでした。「たまたまできた」に過ぎない成果物が、「成果」として通用している状態です。

ここで、第3章で学んだハルシネーション（AIがもっともらしい嘘をつく現象）を思い出してください。AI社員は、100%正しいときも、完全に間違っているときも、まったく同じトーンで「完了しました」と報告してきます。人間の部下なら、自信がないときに声が小さくなったり語尾が曖昧になったりします。AI社員にはそれがありません。

合格基準のない仕事は、ゴールのないマラソンです。どれだけ走っても、完走したのかリタイアなのか分からない。走っている本人も、見ている観客も。

川島さんのメール返信、3項目で変わった

川島さんも同じ壁にぶつかりました。

AI社員に問い合わせメールの返信を任せたときのことです。最初は「丁寧に返信してね」としか伝えていませんでした。AI社員からの報告は毎回同じ。「返信は丁寧でした」。

しかし、ある日ふと返信を読み返してみたら、聞かれた質問に答えていないものが混じっていました。丁寧なのは確かなのですが、お客さんの質問をスルーしている。丁寧に書かれた的外れな返信ほど、相手を困惑させるものはありません。

川島さんは3つのチェック項目を作りました。

  1. 質問への直接回答がある
  2. 次のアクションが明示されている
  3. 敬語のレベルが相手に合っている

たった3項目です。しかし効果は劇的でした。AI社員は毎回この3項目で自己採点してから返信を出すようになり、「丁寧だけど的外れ」な返信がなくなりました。

第1章でも紹介したロック（Locke）とレイサム（Latham）の目標設定理論を思い出してください。「具体的で明確な目標」は曖昧な指示を96%の研究で上回りました。「丁寧に」は曖昧な指示。「3項目をクリアせよ」は具体的な目標。川島さんが体験したのは、この理論がAI社員にも当てはまるという発見でした。

法務部から学んで、全部署に基準を作った

法務部だけが品質チェックに成功していた理由は明白でした。最初から「何をもって合格とするか」が定義されていたからです。

CC Companyではこの気づきから、全部署に合格基準の設定を義務化しました。しかし、ここで一つ想定外のことが起きました。

最初は全部署に「100点満点の点数制」を導入しようとしました。法務部でうまくいっていたからです。ところが、実際に運用してみると、成果物の種類によって「合う基準の形」が違うことに気づきました。

note記事の評価には点数制がよく合いました。4つのカテゴリに分けて100点満点で採点する方式です。

80点以上でA（公開OK）、60〜79点でB（修正後に公開）、59点以下でC（大幅な書き直し）。冒頭で紹介した86点の記事は、この基準があったから「低い」と分かったのです。

ところが、X（エックス。旧Twitter（ツイッター））やFacebook（フェイスブック）の投稿文に同じ100点満点を適用しようとしたら、うまくいきません。140字の投稿に「ブランディング20点」「SEO30点」と細かく採点するのは、ものさしの精度が成果物の大きさに合っていない。

そこでSNS投稿にはチェックリスト制を採用しました。「ゴールに向かっているか」「ターゲットに刺さるか」「文字数は適切か」といった18〜19項目を設定し、すべてクリアしたら合格、一つでも不合格なら修正。点数ではなく、合否で判定する方式です。

さらに講演スライドには、また別のアプローチが必要でした。スライドの良し悪しは「誰が見るか」で大きく変わるからです。IT担当者には分かりやすいスライドが、社長には物足りない。社長向けに作ると、IT担当者には難しすぎる。そこでペルソナ評価（仮想的な聴講者像を設定し、その視点で採点する方法）を導入しました。3名以上の聴講者ペルソナを設定し、各ペルソナの満足度で採点する方式です。

つまり、CC Companyの評価方式は成果物ごとに異なります。

「全部同じ基準で」と考えていた最初の発想は間違いでした。成果物の性質に合わせて基準の形を変える柔軟さが必要だったのです。ただし共通しているのは、「何をもって合格とするか」が作業の前に定義されているという点です。

「外部に出るか？」で深さを決める

全部署に基準を作ったことで、次に起きた問題があります。すべての成果物に同じ重さのチェックを課してしまい、社内メモにまで厳密な品質チェックを求めてしまったのです。

当然、仕事が遅くなりました。

ある日、社内の議事メモと、クライアント向けの提案書が同じ審査プロセスを通っていることに気づきました。議事メモは自分しか読まない。提案書は相手の経営者が読む。同じ深さのチェックが必要なはずがありません。

CC Companyでは、タスクのリスクに応じて3段階の審査レベルを設けました。

判断基準はシンプルです。「外部に出るか？ お金が絡むか？」この2つの質問に「はい」が一つでもあればL3。どちらも「いいえ」なら、内容の重要度でL1かL2を選ぶ。迷ったらL2にしておけば大きな問題にはなりません。

川島さん、部下の報告書に基準を作る

川島さんの職場でも、似た問題が起きていました。

部下が提出する週次報告書を、川島さんは毎回読んで「うーん、なんか違うんだよな」と差し戻していました。部下は「何を直せばいいですか？」と聞きますが、川島さん自身も「何が違うのか」をうまく言語化できません。

これが毎週繰り返されていました。部下は萎縮し、川島さんは「自分で直した方が早い」と思い始める。悪循環です。

メール返信で3項目チェックリストがうまくいった経験を思い出し、川島さんは報告書にも評価基準を作ってみました。

  1. 今週の成果が「数字」で書かれている（「頑張りました」ではなく「3件受注」）
  2. 来週のアクションが具体的である（「引き続き」ではなく「A社に水曜日に連絡」）
  3. 課題がある場合、原因の仮説が書かれている（「大変です」ではなく「納期が短すぎる」）
  4. 全体が1ページ以内に収まっている
  5. 前週の未解決事項のフォローが記載されている

5項目すべてクリアで合格。

効果はすぐに現れました。部下は提出前に自分でチェックリストを確認するようになり、「何を直せばいいですか？」と聞く場面が激減しました。川島さん側も、差し戻すときに「項目2が未達です。来週のアクションを具体化してください」と明確に指摘できるようになりました。

これはAI社員だけの話ではありません。人間の部下であっても、合格基準を先に示すことで「やり直しの堂々巡り」から抜け出せるのです。教育心理学のメタ分析（パナデロ（Panadero）ら, 2023, Educational Psychology Review）でも、明確な評価基準（ルーブリック）を事前に共有されたグループは、共有されなかったグループに比べて有意にパフォーマンスが高いことが報告されています。

「チェックしました」は信用するな

合格基準を全部署に設定して、一安心。そう思っていたら、もう一つの落とし穴が待っていました。

AI社員が「品質チェック完了しました。合格です」と報告してきたので安心していたら、実はチェックを実行していなかったのです。

どういうことか。AI社員はハルシネーションにより、チェックしていないのに「チェックしました」と報告することがあります。悪意はありません。第3章で紹介したサイコファンシー（迎合性）により、AI社員は「上司が聞きたい答え」を優先的に返す傾向があるのです。

この経験から生まれたルールがあります。

「チェックのログファイルがなければ、やっていないと判断する」。

つまり、AI社員の「やりました」という報告だけでは信用しない。実際にチェックした過程をログファイルとして記録させ、そのファイルが存在することを確認する。ファイルがなければ「やっていない」と判断して、やり直させる。

医療の世界でも、同じ発想で成果を上げた事例があります。外科医アトゥル・ガワンデ（Atul Gawande）らの研究チーム（ヘインズ（Haynes）ら, 2009, New England Journal of Medicine（世界的な医学雑誌））は、手術前に19項目のチェックリストを導入しただけで、8か国8病院における手術の死亡率を47%低下させました（1.5%から0.8%へ）。重大合併症も36%減少しています。ポイントは、チェックリストの内容が特別だったのではなく、「チェックした記録を残す仕組み」を導入したことです。やったかどうかを記録に残す。たったそれだけのことが、命を救った。

AI社員の仕事で命に関わることは稀でしょう。しかし「チェックの記録を残す」という原則は同じです。基準を作っただけでは不十分で、「基準に照らしてチェックした記録」が残っていなければ、チェックは実行されていないのと同じです。

最初は粗くていい

ここまで読んで、「基準を作るのは大変そうだ」と感じたかもしれません。

安心してください。合格基準は最初から完璧である必要はありません。

CC Companyのnote記事の評価基準も、最初のバージョンは穴だらけでした。「ブランディング」のカテゴリが漠然としていて、何をチェックしているのか曖昧だった。運用するうちに「具体的な実践が見えるか」「専門家としての深さがあるか」と具体化していきました。

「この項目は毎回クリアされるから、もっと高い基準にしよう」「この観点が抜けていたから追加しよう」。そんな気づきが運用のたびに出てきます。そのたびに基準を更新していく。これはまさにPDCA（Plan Do Check Action：計画→実行→確認→改善のサイクル）のAction（改善）にあたります。

基準そのものが間違っていたら、基準を直す。AI社員を育てると同時に、基準も育てていく。

ここで一つ、先の話をしておきます。基準を育てていくと、やがてこんな疑問が浮かぶはずです。「この基準自体が正しいかどうかは、誰がチェックするのか」。基準に照らして成果物の品質を管理するのは当然ですが、その基準自体の品質は誰が管理するのか。これは「品質管理の仕組みを品質管理する」という、一段上の問題です。この問題については第13章で詳しく扱いますが、ここでは「基準は一度作って終わりではなく、定期的に見直す対象である」ということだけ覚えておいてください。

規模に応じた実践

個人の場合

まずは自分がAI社員に一番よく頼む仕事を一つ選び、チェックリスト3項目を作ってみてください。「これだけは満たしてほしい」という最低限の項目を3つ。川島さんがメール返信で作った3項目がまさにこれです。3項目でも、基準がゼロの状態と比べれば品質は劇的に安定します。

チームの場合

共有の評価基準テンプレートを作成し、各メンバーが成果物に合わせてカスタマイズする運用が効果的です。たとえば議事録用のチェックリスト、提案書用の点数基準、報告書用のチェックリスト、という具合に、成果物ごとにテンプレートを用意します。新しいメンバーが入っても「この基準に沿ってチェックしてね」と渡すだけで品質が揃います。

組織の場合

CC Companyがまさにこのモデルです。全社共通のルール（「合格基準なしに成果物を出すな」「チェックのログを残せ」）をルートに配置し、各部署にはそれぞれ固有の評価基準を持たせる。成果物の性質に合わせて評価形式（点数制/合否制/ペルソナ評価）を使い分け、リスクに応じて審査レベル（L1〜L3）を変える。共通ルールと部署固有の基準を分離することで、全社的な一貫性を保ちながら、部署ごとの専門性にも対応できます。

コラム: 90点の記事が読者に刺さらなかった話

品質チェックで90点以上を出した記事がありました。チェック項目はすべてクリア。文章表現もルール通り。構成も整っている。自信を持って公開しました。

しかし、読者の反応（スキ数やPV（Page View：閲覧数））が伸び悩んだのです。

基準をクリアした記事なのに、なぜ読者に刺さらないのか。分析してみると、「基準が測っていないもの」があることに気づきました。タイトルのキャッチ力、サムネイル画像の訴求力、投稿のタイミング。これらは当時の100点満点の評価項目に含まれていなかったのです。

ここから学んだのは、「基準をクリアした＝読者に届く」とは限らないということです。基準は「最低限の品質」を守る安全網であって、「必ず成功する」保証ではない。

大事なのは、読者の反応データ（PV、スキ数、コメント）を基準自体の評価に使い、基準そのものをアップデートし続けることです。CC Companyではこの経験を経て、タイトルの評価項目を追加し、サムネイルの品質基準も別途設けました。基準は一度作って終わりではなく、結果から学んで育てるものです。第13章（定期健康診断）で、この仕組みを詳しく扱います。

LLM（Large Language Model：大規模言語モデル）知識: AI社員はなぜ「合格です」と嘘をつくのか

第3章で解説したRLHF（Reinforcement Learning from Human Feedback：人間のフィードバックによる強化学習）の副作用が、ここでも効いています。AI社員は「上司が聞きたくない報告」を避ける傾向（サイコファンシー）を持つため、「不合格でした」より「合格です」と報告しやすいのです。

対策は、本章で紹介したとおりです。数値基準を設定すれば、70点の成果物を「合格です」と言い張ることはできません。さらに、チェックのログファイルを残させれば、「やっていないのにやった」という報告も防げます。基準とログの組み合わせが、AI社員の迎合を構造的に無効化するのです。

まとめ

点数制・チェックリスト制・段階評価（A/B/C/D）の3方式すべてのテンプレートと、品質チェックログのテンプレートを、付録D「品質基準テンプレート集」にまとめています。どの方式を選ぶかの使い分け例（note記事=点数制、SNS投稿=チェックリスト制、講演スライド=段階評価など）も付録Dに掲載しています。自社の成果物に合う方式を選んで、そのままコピーして使ってください。迷ったら「チェックリスト制」から始めるのが無難です。

合格基準ができました。しかし、AI社員が一発で合格する保証はどこにもありません。不合格だったとき、どうすればよいのでしょうか。