AIのチェックは増やすほど抜ける｜1本にして観点で割る

「AIに書かせたものを、AIにチェックさせたい」「でもチェックを増やしたら、かえって何も進まなくなった」——AIに仕事を任せ始めた人が、ほぼ必ず一度は通る場所です。

結論から言うと、AIのチェックは本数を増やすのではなく、1本にまとめて中を「観点」で割るのが正解です。そして作った直後にやるべきは、落とすテストではなく「合格でいい」と思っている過去の成果物を通してみる較正です。

株式会社Fyveは、自社の発信も納品物も「AIが作り、別のAIが検品してから外に出す」形で運用しています。この記事では、私が実際にチェックを増やして失敗し、1本に統合し直したときに何が変わったのかを、そのまま設計の話として書きます。

結論｜チェックは「本数」で増やすな。「観点」で増やせ

先に答えだけ置いておきます。AIに自分の成果物を検品させる仕組みを作るときの原則は、3つだけです。

• 検査は1本にまとめ、その中を「観点」で割る。分けるのは実行の回数ではなく、見る角度
• 作った直後にやるのは「落とすテスト」ではなく「通すテスト」。合格でいいと思っている過去の成果物を通し、落ちたら検査のほうを直す
• 観点ごとに「どこが引っかかったか」を返させる。「ダメ」しか返さない検査は使えない

この3つは、AIに限った話ではありません。人がやるチェックリストでも、レビューでも、承認フローでも、そのまま効きます。以下、なぜそうなるのかを順に書いていきます。

なぜ「チェックを増やす」方向に手が動くのか

AIの出力に一度でも痛い目を見ると、人は必ずチェックを足したくなります。事実が違っていた日は「事実チェック」を足し、文体が崩れた日は「文体チェック」を足し、前と同じことを書いていた日は「重複チェック」を足す。追加は簡単ですし、足した瞬間は確実に安心できます。

この動きが自然なのは、チェックを足すコストが、その場では見えないからです。1本足すのに数分しかかかりません。効果は「前より安全になったはず」という感覚で返ってきます。コストは後から、しかも静かにやってきます。

私も同じ道を通りました。公開前に通す検査を、気づいたときに1本ずつ足していった結果、種類ごとに独立した検査が並ぶ状態になっていました。当時の私は、それを「守りが厚くなった」と思っていました。実際には、逆のことが起きていました。

チェックを本数で増やすと起きる4つのこと

1｜同じものを何度も読ませる分、時間と費用がそのまま増える

いちばん分かりやすい代償がこれです。検査を3本並べるということは、同じ原稿を3回読ませるということです。AIにとって「読む」は無料ではありません。原稿が長ければ長いほど、読み込みの分がそのまま3倍になります。

しかも読み込みの中身は、3回ともほぼ同じです。文体を見るときも、事実を見るときも、重複を見るときも、渡している原稿は同じ1本。つまり増えているのは判断の量ではなく、同じ情報を運ぶ往復の回数だけです。ここが「本数で割る」設計のいちばん無駄な部分になります。

時間についても同じです。1本あたり数十秒で終わる検査でも、直列に3本並べれば待ち時間は3倍になります。公開前の最後の関門が遅くなると、人は必ず「今日は急ぐから飛ばそう」と言い出します。検査が形骸化する最初のきっかけは、たいてい速度です。

2｜チェックどうしが矛盾して、直しようがなくなる

本数で割った検査は、お互いの存在を知りません。それぞれが自分の担当範囲だけを見て、独立に判定を返します。ここから、実務でいちばん厄介な現象が生まれます。片方が「直せ」と言い、もう片方が「そのままでいい」と言う状態です。

たとえば「同じ言い回しが続いているので変えろ」と文体の検査が言い、「その表現は正式名称なので変えるな」と事実の検査が言う。どちらも、自分の観点では正しい判定です。矛盾しているのは検査ではなく、矛盾を裁く場所がどこにもないという設計のほうです。

1本にまとまっていれば、この矛盾はそもそも起きません。同じ1回の判断の中で「言い回しは重複しているが、これは正式名称なので変えない」と結論まで出せます。観点の衝突は、判断の中でしか解けないのです。別々の実行に分けた時点で、解けなくなります。

3｜どれが落としたのか分からなくなる

検査が3本あって、最後に「不合格」だけが返ってきたとき、あなたはまずどれが落としたのかを探すところから始めることになります。3本ならまだ追えますが、5本、6本と増えると、原因の特定そのものが仕事になります。

そして原因を追う作業は、検査を通すたびに発生します。1回で終わりません。この「毎回発生する調査コスト」が、検査を外したくなる二番目の理由です。

4｜いちばん怖いのは「動いていないチェック」に気づけなくなること

ここが本題です。検査を本数で増やしたときの本当の代償は、費用でも速度でもありません。どれか1本が動いていなくても、誰も気づけなくなることです。

検査が1本しかなければ、それが壊れた日は何も通らなくなります。おかしいとすぐ分かります。ところが検査が5本あると、そのうち1本が黙って動かなくなっても、残りの4本が正常に「合格」を返し続ける。全体としては今日も無事に通った、という顔をして進んでいきます。

「全部通った」は「全部が検査した」ではありません。この2つを混同したまま何日も回すと、その間に出した成果物はまったく検品されていない観点を抱えたまま外に出ていることになります。しかも、それに気づくきっかけがありません。壊れたことを教えてくれるのは、たいてい読み手や取引先です。

本数が少ないほど壊れたときに気づける、というのはここから来ています。安全のために足したはずの本数が、安全を確認する能力そのものを削っている——これが、私が実際にやってしまった失敗です。

「多層チェックがいい」という助言と矛盾しないのか

ここで疑問が出ると思います。AIのレビューについては「単体の精度には限界があるので、層を分けて多層で見るべきだ」という話が定番だからです。私自身も、コードレビューの文脈では同じことを書いています。

Claude CodeAIコードレビューの実践法｜ガイドライン×多層チェックで精度を上げる

矛盾はしていません。「層を分ける」と「実行を分ける」は違う話だからです。多層で見るべきだという主張の中身は、「1つの雑な基準で丸ごと判定させるな、見る角度をはっきり分けろ」ということです。それは観点の話です。

一方、本記事で「増やすな」と言っているのは、同じ原稿を何度も渡し直す、実行の回数のほうです。観点は増やしていい。というより、増やすべきです。増やしてはいけないのは、その観点を運ぶための往復です。

言い換えると、こうなります。

この表の右下、「壊れたら全部止まるので気づける」を弱点だと感じる人がいるかもしれません。逆です。止まってくれる壊れ方は、いちばん安全な壊れ方です。怖いのは、止まらずに静かに欠ける壊れ方のほうです。

直し方1｜検査は1本にまとめ、中を「観点」で割る

観点の割り方——「見る角度」で分ける

1本にまとめると決めたら、次にやるのは観点の設計です。ここで大事なのは、観点は「何を守りたいか」で割るということです。処理の種類や、チェックの実装方法で割るのではありません。

私が公開物に対して使っている観点は、おおむね次の4つに整理できます。

この4つは、互いに重なりません。ここが重要です。観点が重なっていると、同じ指摘が2回返ってきて、どちらを直せばいいのか分からなくなるからです。観点を作ったら「この2つは、同じものを別の言葉で見ていないか」を必ず確認してください。

1本にまとめると、具体的に何が変わるか

やることは単純です。原稿を渡すのは1回。そのうえで「次の観点それぞれについて判定してください」と観点のリストを添え、観点ごとに結果を返させる。それだけです。

変わるのは3点あります。ひとつ目は、読み込みが1回で済むこと。ふたつ目は、観点どうしがぶつかったときに、その場で「こちらを優先する」と裁けること。みっつ目は、検査が動いていない日には何も通らなくなるので、壊れたことがその日のうちに分かることです。

特に3つ目は、後から効いてきます。無人で回している工程では、「エラーが出て止まる」ほうが「静かに素通りする」よりはるかにありがたい。止まってくれれば直せますが、素通りは何日も気づけません。

観点を割るときにやりがちな失敗

3つ挙げておきます。私が全部やりました。

失敗1｜観点を細かく割りすぎる。10個も15個も観点を並べると、1つあたりの判断が薄くなります。全部に「問題なし」と返ってきて、しかもそれが本当かどうか確かめようがない状態になります。守りたいものの単位で数えて、多くても5つか6つに収めるのが実用的です。

失敗2｜観点に「良い記事かどうか」のような大きすぎる問いを入れる。これは観点ではなく感想です。合否が人によって変わる問いを検査に入れると、その検査は毎回ちがう答えを返すようになり、信用できなくなります。観点は、合否が誰にとっても同じになる形まで具体化する必要があります。

失敗3｜観点を足すたびに検査そのものを作り直す。観点は増えます。増えていいのですが、そのたびに全体を書き直していると、前に効いていた観点が知らないうちに消えます。観点はリストとして足せる形にしておき、検査の本体は触らない——この分け方にしておくと、あとが楽です。

直し方2｜作った直後は「落とすテスト」より先に「通すテスト」

較正とは——合格でいいと思っている過去の成果物を、そのまま通す

検査を作ると、誰もがまず「ちゃんと落ちるか」を試したくなります。わざと機密を入れた文章を作って、止まるかどうかを見る。これ自体は正しい確認です。ただし、順番が逆です。

最初にやるべきなのは、通すテストのほうです。具体的には、自分が「これは合格でいい」と思っている過去の成果物を、そのまま検査にかける。すでに世に出していて、何の問題も起きなかったもの。手元にある、いちばん自信のある1本です。

これを私は「較正」と呼んでいます。体重計に何も載せずにゼロを合わせるのと同じで、基準そのものが正しい位置にあるかを確かめる作業です。落とす方向の確認だけをしていると、この基準がどんどん厳しい側にずれていきます。

落ちたとき、直すのは成果物ではなく検査のほう

ここが較正のいちばん重要な一点です。合格でいいと思っていた見本が落ちたとき、疑うべきは見本ではなく、検査です。

実際にやってみると、かなりの確率で落ちます。私の場合も、問題なく公開できていた過去の記事が、作ったばかりの検査では落ちました。中身を見ると、検査が「疑わしい表現」を広く取りすぎていて、通常の書き方まで拾っていました。成果物は正しく、基準がずれていたわけです。

もしここで「検査が落としたのだから、見本のほうを直そう」と考えてしまうと、話が反転します。以後、あなたの成果物はずれた基準に合わせて作られていくことになります。これは品質が上がったのではなく、基準に振り回されているだけです。

判断の順番を決めておくと迷いません。見本が落ちたら、まず「この指摘は、本当に外に出したら困ることか」を自分に聞く。困らないなら検査を緩める。困るなら、それは見本のほうが甘かったということなので、見本を直して基準は維持する。先に問うのは常に検査のほうです。

較正を飛ばした検査は、必ず人の手で外される

較正しないまま運用に入れた検査は、たいてい厳しすぎます。厳しすぎる検査は、正しいものまで落とします。すると何が起きるか。人が手で外し始めます。

最初は「今日は急ぐから、この1回だけ飛ばす」です。次は「あの検査はいつも誤検知するから、基本的に無視でいい」になります。最後には、検査は仕組みとしては存在しているのに、誰も結果を見ていない状態になります。これが形骸化です。

形骸化した検査は、無いより悪い。「検査してあります」という表示だけが残り、実質は無防備だからです。無いなら人は警戒しますが、あると思っていると警戒しません。較正は、この最悪の状態を避けるための工程です。

直し方3｜「ダメ」だけ返す検査は使えない

観点ごとに「どこが」を返させる

3つ目の原則です。検査が返していいのは「合格／不合格」だけではありません。不合格なら、どの観点の、どこが、なぜ引っかかったのかまで返させます。

理由は単純で、返ってこないと直せないからです。「不合格」とだけ言われた原稿を前にして、人ができることは総当たりで読み直すことだけです。それは検査の役目を人に押し戻しているのと同じで、自動化した意味がありません。

返させる内容は、最低でも次の3つです。

• どの観点で落ちたか（機密なのか、事実なのか、体裁なのか）
• 本文のどこか（該当する箇所をそのまま引用させる。位置の説明ではなく、原文の抜き出し）
• なぜダメか（「規約違反」ではなく「取引先が特定できるため」のように、判断の理由）

特に2つ目の「原文をそのまま抜き出させる」は効きます。抜き出せない指摘は、たいてい実際には本文に無いことを言っているからです。引用を義務づけるだけで、根拠のない指摘がかなり減ります。

返答の形をこちらで決めておく

もうひとつ、地味ですが効果が大きいのが、返答の形をこちらで固定してしまうことです。自由な文章で返させると、その日によって書き方が変わり、合否をどう読み取ればいいのかが毎回ぶれます。

「観点ごとに、合否と、該当箇所と、理由を並べて返す」という形をあらかじめ指定しておく。そうすると、合否の読み取りが機械的になり、人が解釈する余地が減ります。人が読んで判断しなければならない検査結果は、検査が終わっていないのと同じです。

この「合否を機械が判定できる形にする」という考え方は、検品を工程として設計するときの土台になります。詳しくは別記事にまとめています。

AI業務効率化AIに任せる手順書の書き方｜検品を工程に埋め込む

私の実運用｜検査を1本に統合したときに起きたこと

統合前——増やすほど、どれも信用できなくなった

私は、外に出す文章を無人で作る工程を回しています。人が見る前に必ず検品を通す設計で、そこに検査を1本ずつ足していきました。事実が怪しかった日、体裁が崩れた日、過去記事と内容が近すぎた日——そのたびに1本足しました。

ある時点で気づいたのは、どの検査も「合格」を返しているのに、出てくるものが良くなっていないことでした。調べると、いくつかの検査は条件のかけ違いで実質的に何も見ていない状態になっていました。それでも全体は毎回きれいに完走していました。エラーは1件も出ていません。

これが、本数で割ることの本当の怖さです。壊れているのに、正常に見える。止まってさえくれれば、その日に直せた話でした。

統合後——1回読ませて、観点ごとに返す

そこで、並んでいた検査を1本に統合し、中を観点で割り直しました。原稿を渡すのは1回。観点は、外に出してはいけないもの・個人が特定できる情報・事実の整合・自分で決めた作法の4つ。観点ごとに、合否と該当箇所と理由を返させる形にしました。

変わったのは主に3点です。

• 読み込みが1回になった——同じ原稿を何度も渡す往復が消え、待ち時間も費用も観点の数に比例しなくなった
• 指摘が1か所にまとまった——どの観点で落ちたのかを探す作業が消えた
• 壊れたら止まるようになった——検査が動かない日は何も通らない。静かに素通りする経路が無くなった

3つ目は、見た目には「不便になった」変更です。実際、統合してから何も公開できない日が出ました。ですが、その日は本来なら検品されないまま外に出ていた日です。止まったこと自体が、仕組みが機能している証拠でした。

較正で分かったこと——落ちていたのは成果物ではなく基準だった

統合した検査を運用に入れる前に、較正をやりました。手元にある、自分が「これは問題なく出せた」と思っている過去の成果物を、そのまま通してみたのです。

落ちました。しかも、通したかった見本のほうが落ちました。中身を確認すると、検査が「疑わしい」と判定する範囲を広く取りすぎていて、通常の説明の中に出てくる一般的な表現まで拾っていたことが分かりました。

ここで見本のほうを書き換えていたら、私は以後ずっと、必要のない自主規制をかけた文章を書き続けていたはずです。実際には検査の側を調整しました。落ちたのは成果物ではなく、基準でした。

この較正を、私は検査を触るたびに繰り返しています。観点を1つ足したとき、判定の書き方を変えたとき、必ず「通したい見本」を1本通す。落とす確認より先に、通す確認です。

AI以外でも同じ｜チェックリスト・レビュー・承認フロー

承認者を増やしても品質は上がらない

ここまでAIの話として書いてきましたが、この構造はAIに固有のものではありません。人がやるチェックでも、まったく同じことが起きます。

いちばん分かりやすいのが承認フローです。ミスが起きるたびに承認者を1人足していく組織があります。3人が順番に承認する仕組みになったとき、品質は3倍になっているでしょうか。実際には逆で、「他の2人も見ているから大丈夫だろう」という気持ちが全員に働きます。責任が薄まる分、1人あたりの見る目は甘くなります。

そして、そのうち1人が形式的に押しているだけになっても、書類は通り続けます。残りの2人が承認しているからです。本数で割った検査が壊れても気づけないのと、同じ形です。

人がやる場合も「1回で、観点ごとに」

やり方も同じです。承認者を増やすのではなく、1人が1回見る。ただし観点を明示して、観点ごとに確認させる。「見ておいて」ではなく「金額・宛先・日付・条件の4点を、それぞれ確認して結果を書いて」にする。

これだけで、見落としの発生場所が特定できるようになります。何かが漏れたとき、「誰が見落としたか」ではなく「どの観点が抜けていたか」を議論できる。人を責める場所が、仕組みを直す場所に変わります。

チェックリストも同様です。項目を増やすほど、人は上から順に形式的に埋めるようになります。項目数ではなく、守りたいものの単位で数えて、その単位を減らさないほうが機能します。

今日からやる3ステップ

ステップ1｜今あるチェックを全部書き出す

最初にやるのは、棚卸しです。いま自分が何本のチェックを持っているのかを、全部書き出してください。AIに依頼している検品、手元のチェックリスト、頭の中でだけやっている確認——形式は問いません。

書き出したら、それぞれに「これは何を守るためのものか」を1行で添えます。書けないものが出てきたら、それは目的を失った検査です。多くの場合、1回だけ起きた失敗の記念碑として残っているだけで、今はもう何も守っていません。

ステップ2｜1本に束ねて、観点として並べ直す

次に、書き出したチェックを「守りたいもの」でグループにします。同じものを守っているチェックは、1つの観点に統合します。ここで数が半分以下に減るのが普通です。

グループができたら、それを1本の検査の中の観点リストとして並べます。渡す原稿は1回。観点ごとに、合否と該当箇所と理由を返させる。実行を1つにして、観点をリストにする——この形に組み替えるだけです。

ステップ3｜合格させたい見本を1つ通す

最後が較正です。運用に入れる前に、「これは合格でいい」と思っている過去の成果物を1本、そのまま通してください。

通ったら、そのまま運用に入れて構いません。落ちたら、指摘を1件ずつ見て「これは本当に外に出したら困ることか」を判断します。困らないなら、検査を緩める。この作業を、通るまで繰り返します。

ここを飛ばして運用に入れると、高い確率で厳しすぎる検査になり、数週間後には誰も結果を見なくなります。較正にかかる時間は、たいてい30分程度です。形骸化した検査を作り直す手間に比べれば、比較になりません。

よくある質問

Q1｜観点はいくつまで作っていいですか

実用的な上限は5つか6つです。それを超えると、1つあたりの判断が薄くなり、全部に「問題なし」が並ぶだけの結果になりがちです。増やしたくなったら、まず既存の観点と重なっていないかを確認してください。多くの場合、新しい観点ではなく既存の観点の説明不足です。

Q2｜1本にまとめると、1つの観点の精度が落ちませんか

観点の説明が雑なら落ちます。ただしそれは本数の問題ではなく、観点の書き方の問題です。「機密が入っていないか」だけでは判断が揺れますが、「取引先・個人名・具体的な金額・内部でしか通じない呼び名が本文にあれば不合格」まで書けば、1本の中でも判定は安定します。精度を決めるのは実行回数ではなく、基準の具体性です。

Q3｜重い検査と軽い検査を混ぜていいですか

性質が違うものは分けて構いません。ここで言う「増やすな」は、同じ原稿を同じように読み直す検査のことです。原稿を読む必要がない機械的な確認——たとえば決められた項目が空になっていないか、長さが下限を割っていないか——は、読み込みを伴わないので、まとめる対象ではありません。読ませる検査は1本に。読ませない確認はその外に、と考えると整理しやすくなります。

Q4｜落ちたときに、AIへそのまま直させていいですか

観点によります。体裁や作法の逸脱なら、直させて再度通す運用で問題ありません。ただし事実の誤り・機密・個人情報で落ちたときは、自動で直させないほうが安全です。この3つは「表現を変えて検査を通す」ことができてしまうため、問題が消えたのではなく、見えなくなっただけという結果になり得ます。落ちた理由が重いものほど、人に返す。

Q5｜検査するAIと、本文を書くAIは同じでいいですか

分けたほうがいいです。同じ流れの中で書いたものを自分で検品させると、書いたときの前提をそのまま引き継いで読んでしまうため、思い込みが検査を素通りします。ここで言う「分ける」は実行を増やすことではなく、書いた文脈を持ち込ませないことです。原稿だけを渡して、経緯を知らない状態で読ませる。これは本数の話ではなく、独立性の話です。

まとめ｜検査の強さは本数ではなく、観点と較正で決まる

AIに自分の成果物を検品させるとき、安心を求めて手が動く方向は「チェックを足す」です。ですが、足した本数は安全とほとんど関係がありません。関係があるのは、見る角度が漏れなく揃っているかと、その基準が正しい位置に較正されているかの2つだけです。

最後にもう一度、3つの原則を置いておきます。

• 検査は1本にまとめ、中を観点で割る。増やすのは見る角度であって、実行の回数ではない
• 作った直後は、落とすテストより先に通すテスト。合格でいいと思っている見本が落ちたら、直すのは検査のほう
• 観点ごとに、どこが引っかかったかを返させる。「ダメ」しか返さない検査は、仕事を人に押し戻しているだけ

そして、この設計のいちばんの利点は壊れたときに気づけることです。検査が1本なら、動かなくなった日は何も通りません。不便に見えますが、静かに素通りされるより、はるかに安全です。株式会社Fyveが無人の工程を組むときに、いちばん優先しているのはこの性質です。

AIに任せる範囲を広げるほど、最後に効いてくるのは「どれだけ守りを厚くしたか」ではなく「守りが動いていることを、どうやって知るか」になります。まずは手元のチェックを全部書き出すところから始めてみてください。