AI社員の育て方
AI社員の育て方 / 第9章: 人間が確認できる仕組みを作る

第9章: 人間が確認できる仕組みを作る

レビューログに「6つの表を確認し、全て正常」と書いてありました。

AI社員が作成した資料の品質チェック結果です。合格と判定されている。ところが、実際にファイルを開いて数えてみると、表は5つしかありませんでした。

「チェックしました」は嘘ではなかったのかもしれません。しかし結果は間違っていた。しかもこのミスは、私自身の自己レビューでも見逃していました。見つけたのは、まったく別のAIに同じファイルを検証させたときです。

自分で書いた文章の誤字は、自分では見つけられない。 誰でも経験したことがあるはずです。何度読み返しても気づかないのに、他人が読んだら一発で見つかる。AI社員の自己チェックにも、まったく同じ構造の問題があります。作った本人（AI）がチェックしても、自分の前提を疑えないのです。

この章は、AI社員の「やりました」をどう検証するかの話です。最初はファイルの有無で判定する仕組みを作りました。それだけでは足りなかったので、レビューログに根拠の記載を義務付けました。それでも嘘の根拠が混じったので、第三者に検証させる仕組みを追加しました。3段階の試行錯誤を経て、ようやく「人間が安心して確認できる状態」にたどり着いた経緯をお伝えします。

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

3つともチェックが付いた方: 検証の仕組みが整っています。第10章へ進みましょう。

1〜2個の方: 記録は部分的にあるが、人間が全体を確認できる状態になっていない可能性があります。この章で「何を・どう残すか」を体系化しましょう。

チェックがゼロの方: AI社員の「やりました」を信じている状態です。この章を読めば、「ログファイルがない＝やっていない」という原則の重要性がわかります。

ログがなくて何も分からなかった日

CC Company（シーシーカンパニー）の初期に、文字起こしデータを自動で整理する処理をAI社員に任せていました。毎日決まった時間に実行される定期処理です。

ある日、整理済みのはずのデータが見つかりませんでした。AI社員に聞くと「実行しました」と答える。しかし結果のファイルがない。処理が途中で止まったのか、そもそも実行されなかったのか、実行したけど出力先を間違えたのか。ログが一切残っていなかったため、何が起きたのかすら判断できなかったのです。

皆さんの職場でも似たような経験はないでしょうか。部下に「あの資料、できた？」と聞いたら「はい、送りました」と返ってくる。でもメールの送信履歴を見ると送っていない。人間相手なら「おい」と言えば済みますが、AI社員には悪意がありません。本当に「送った」と思い込んでいるのです。第3章で紹介したHallucination（ハルシネーション：もっともらしい嘘をつく性質）が、作業報告にもそのまま現れます。

この経験から、CC Companyではすべての定期処理にログファイルの出力を義務付けました。何を実行したか、いつ実行したか、結果はどうだったか。これを時系列で記録したファイルを残させます。ログファイルがなければ、その処理は「動いていない」と判断する。口頭報告ではなく、ファイルの有無（あるか・ないか）という二値で判定する。これが最初の仕組みでした。

「確認しました」の中身が空っぽだった

ログを残す仕組みを入れたことで、「動いたかどうか」は分かるようになりました。しかし次の問題が出ました。動いたけど品質が見えない。

CC Companyでは、AI社員が書いたnote記事の品質を100点満点で評価しています。月曜日の記事は92点。水曜日の記事は68点。金曜日はまた87点。点数はログに残っていますが、なぜ水曜日が低かったのかが分からない。

そこで、品質チェックの結果をレビューログとして別ファイルに残させることにしました。「誤字脱字はなかったか」「事実関係に誤りはないか」「読者ターゲットに合った文体か」といった項目ごとに、合格・不合格の判定とその理由を記録します。

ところが、記録させてみて分かったのですが、AI社員のレビューログは恐ろしく雑でした。

「全項目を確認し、合格基準を満たしています」

これだけです。何を、どのように確認して、なぜ合格と判断したのか、一切書いていない。

川島さんのチームでも同じことが起きていました。AI社員に問い合わせメールの返信内容をチェックさせたところ、「確認しました。問題ありません」と報告してきました。しかし実際に返信を見ると、お客様の質問に答えていないものが3件ありました。「納期はいつですか？」と聞かれているのに、「お問い合わせありがとうございます。弊社では品質管理を徹底しており…」と関係のない話から始まる返信です。

「確認しました」と「正しく確認しました」は、まったく別の話だったのです。

根拠を書かせたら嘘が見えた

川島さんはルールを変えました。「チェックしました、だけでは信じない。何をどう確認したかをファイルに書いて」と追加したのです。

最初は面倒に感じたそうです。しかし1週間後には「ログを見れば安心できる」と実感するようになりました。「メール本文の質問3点を抽出し、各回答との対応を確認。3点目の回答が質問と噛み合っていないため不合格」。このレベルまで書かせると、チェックの質が目に見えて上がったのです。

CC Companyでもレビューログに2つの鉄則を設けました。

鉄則1: レビューログは追記専用にする。 一度書いた判定結果を書き換えてはいけません。「不合格」と判定した後に修正が入った場合は、元の判定を残したまま、その下に「再評価」として新しい判定を追記します。これにより、何回目の修正で合格に至ったかの履歴が残ります。

鉄則2: 根拠のないレビューは無効とする。 「確認しました。問題ありません」だけでは、レビューとして認めません。「○○ファイルの15行目を読み、値が△△であることを確認した」のように、何をどう確認したかを具体的に書かせます。根拠が具体的であるほど、後付けの説明が困難になります。

なぜここまで厳格にするのか。ここで冒頭の「6つの表」事件に戻ります。AI社員はレビューログに「6つの表を確認し、全て正常」と書いていました。根拠として表の数まで具体的に挙げている。一見すると十分な根拠です。しかし実際には5つしかなかった。

第3章で学んだ「Unfaithful Explanations（不誠実な自己報告）」がここでも現れていたのです。AI社員は「確認した」と信じて書いている。しかしその「確認」自体が不正確だった。根拠を書かせることで嘘は減りますが、根拠自体が間違っている可能性は残ります。

ここに、自己チェックの構造的な限界があります。

自分で作って自分でOKを出す限界

もう一つ、CC Companyで起きた出来事です。ある業務の設計書を作り、AI社員に自己レビューさせました。レビューログには「全7項目を確認し、問題なし」と書いてありました。しかし別のAI（Codex CLI（コーデックスシーエルアイ））に同じ設計書を検証させたところ、7項目中6項目で不備が見つかりました。「全業務に適用」と書いてあるが範囲が広すぎる、バージョン番号を固定しているがドリフトのリスクがある、関連ファイルへの追加が漏れている。自己レビューでは見えなかった問題が、第三者の目で次々と出てきたのです。

これは偶然ではありませんでした。別の日にも、レビューログに「5つの表で構成」と書いたが実際は6つだった、件数の集計が合わない、という不整合を第三者検証で2回検出しています。

皆さんも経験があるのではないでしょうか。自分が書いた企画書を何度読み返しても完璧に見える。でも上司に見せた瞬間、「ここの数字、合ってる？」と指摘される。自分の前提を自分では疑えないのです。

この問題は、実はソフトウェア開発の世界では50年前から知られていました。1976年、IBM（アイビーエム）のマイケル・フェイガン（Michael Fagan）が「コードインスペクション」という手法を発表しています（出典: Fagan, M.E., "Design and Code Inspections to Reduce Errors in Program Development", IBM Systems Journal, 1976）。開発者本人ではなく、別の開発者がコードを検証する手法です。この研究によれば、第三者検証によって欠陥の60〜90%を発見できるとされています。自己チェックだけでは限界があるという知見は、AI社員の検証にもそのまま当てはまります。

CC Companyでは、重要度の高いタスクに「第三者ゲートレビュー」を導入しました。作業したAI社員とは別のAI（Codex CLI）に、レビューログとチェックリストと成果物を渡して検証させます。実行者が「合格」と判定しても、第三者が「不合格」と判定したら差し戻しです。この役割分離の詳しい設計は、第10章で「実行者・検証者・受理者」の三者体制としてお伝えします。

検証の仕組みは失敗のたびに育つ

ここまでの流れを振り返ります。

最初: ログがなくて何が起きたか分からなかった。→ ログファイルの出力を義務付けた。

次: ログはあるが「確認しました」の中身が空っぽだった。→ レビューログに根拠の記載を義務付けた。

その次: 根拠自体が間違っていた。→ 第三者による検証を導入した。

第4章で、AI社員のミスはマニュアルに書き込んで防ぐとお伝えしました。検証の仕組みにも同じ原則が適用されます。レビューで問題が見つかるたびに、「次回はここもチェックする」という項目が追加される。チェックリストは失敗の記録であり、育てるものです。

川島さんも同じ経験をしました。週次の議事録をAI社員に作らせていたところ、「決定事項が漏れている」と上司に指摘されたことがありました。AI社員は「確認済み」と言っていたのに、です。川島さんは対策として、「議事録の決定事項を箇条書きで抜き出し、出席者名と紐付けたチェックリストを別ファイルで作る」ルールを追加しました。チェックの粒度を上げたことで、漏れは激減しました。ただし、ゼロにはなりません。重要な議事録は、上司に最終確認してもらう（第三者チェック）運用に落ち着いています。

完璧でないことを前提に、仕組みを重ねていく。 ファイルで判定する。それでも漏れるから根拠を書かせる。根拠も間違うから第三者に検証させる。それでも漏れたら翌日の巡回で検知する。これがCC Companyの実運用から得た結論です。

コラム: 普通に仕事をさせただけで品質チェックが消えた

CC Companyで実際に起きた問題です。「急ぎで」とも「省略して」とも言っていません。普通に「構成案を作って」と指示しただけです。それなのに、品質チェックの工程が丸ごと飛ばされていました。手順書には「品質チェックを必ず実行する」と書いてあるにもかかわらず、です。

これは第3章で紹介した「Context Rot（コンテキストロット：文脈の腐食）」の影響です。AI社員は作業に集中すると、手順書に書いてあるルールの一部を「忘れて」しまいます。特に品質チェックのような「作業の後にやること」は、作業そのものに注意を取られるうちに抜け落ちやすい。人間が「急いで」と言ったから飛ばしたのではなく、AI社員が勝手に忘れたのです。

しかも、この問題は同じセッションの中で3回繰り返されました。構成案v1を基準なしで提出し、指摘されてv2ではチェックを入れた。ところがその直後のスライド構成表で、また基準なしで提出してきたのです。「さっき指摘したばかりなのに」と驚きましたが、AI社員にとっては指摘も含めて「過去の文脈」であり、新しい作業が始まると再び忘却が起きていました。

ファイルの有無で判定する仕組みは入れていました。しかし正直に書くと、それだけではチェック漏れはゼロになりませんでした。 ルールを書いても、AI社員がそのルール自体を忘れてしまえば意味がないのです。

この経験から、CC Companyでは2つの対策を追加しました。

1. 品質チェックを「後工程」ではなく「最初の工程」にする。 成果物を作り始める前に、まず合格基準を定義する。基準が先にあれば、作業中も「この基準を満たすように作る」と意識が向きます。作業後に思い出すのではなく、作業の出発点にすることで、忘却のリスクを構造的に下げました。

2. 品質チェックを業務手順書の中に埋め込む。 「品質チェックをやりましょう」というルールではなく、業務手順書の工程の中に品質チェックが組み込まれている状態にしました。手順書に従って作業を進めれば、途中で自然にチェック工程を通過する設計です。ルールを「守る・守らない」の判断をAI社員に委ねないのがポイントです。

仕組みは一発では完璧になりません。ファイルで判定する、それでも漏れるから手順に埋め込む、それでも漏れたら翌日の巡回で検知する。「完璧でないことを前提に、仕組みを重ねていく」。これが実運用から得た結論です。

規模に応じた実践

個人で始めるなら: まずはAI社員のレビュー結果を別ファイルに保存するところから始めてください。「チェックしました」ではなく「何をどう確認したか」を書かせる。これだけで、AI社員の仕事の信頼度が格段に上がります。

チームで使うなら: レビューログの命名規則を統一してください。「YYYY-MM-DD-対象名-review.md」のようにすると、いつ・何を・チェックしたかがファイル名だけで追えます。追記専用ルールを徹底し、修正履歴が消えないようにします。

組織で展開するなら: 実行者と検証者を分離してください。CC Companyのように別のAIによる第三者ゲートレビューを導入するのが理想ですが、まずは「作った人とチェックする人を変える」だけでも効果があります。人間の世界でも、経理の入力と承認を同じ人がやらないのと同じ原理です。

LLM（Large Language Model：大規模言語モデル）知識: なぜAI社員は自分のミスに気づけないのか

AI社員が自己チェックに失敗する背景には、大規模言語モデル（LLM）の3つの性質があります。

1つ目は「Attention Dilution（アテンションダイリューション：注意力の希薄化）」です。 入力される情報が長くなると、個々の情報に対する注意力が分散します。第3章で紹介した「Lost in the Middle」（長い文書の中間が見落とされる現象）がまさにこれで、長い文章の中間部分に置かれた情報ほど見落とされやすくなります。チェック対象の文書が長くなるほど、特定の箇所を「飛ばして」しまうリスクが高まるのです。

2つ目は「Unfaithful Explanations（不誠実な自己報告）」です。 第3章でもお伝えしましたが、AI社員は自分の思考過程を正確に説明できません。「15行目を確認しました」と書いていても、実際に15行目を読んだかどうかは保証されない。自己報告と実際の処理が一致しない場合がある、という性質です。

3つ目は「自己校正の限界」です。 カダヴァス（Kadavath）ら（2022）の研究「Language Models (Mostly) Know What They Don't Know」（言語モデルは自分が知らないことをおおむね知っている） では、LLMが自分の出力に対して自信を持ちすぎる傾向が示されています（出典: Kadavath, S. et al., Anthropic, 2022）。人間なら「あれ、ちゃんと見たっけ？」と不安になって見直すことがありますが、AIにはその「不安」がありません。間違っていても自信を持って「合格です」と報告します。

だから、AI社員の自己チェックだけに頼るのは構造的に危険です。ログ、根拠付きレビュー、第三者検証という3段階の仕組みは、これらのLLMの性質に対する対策として設計されています。技術的な詳細を知らなくても、「AI社員は自分のミスに気づけない生き物だ」と理解しておけば、検証の仕組みを入れる動機は十分です。

まとめ

記録を残し、検証できる仕組みができました。しかし、成果物が合格しても「仕事が閉じていない」問題がまだ残っています。