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

「AIに作業は任せられるけど、出してきた成果物のチェックが追いつかない」——AIを実務に組み込み始めた人が、必ずぶつかる壁です。

結論から言うと、検品を「あとでまとめてやる別作業」にした瞬間に仕組みは破綻します。任せる作業の手順書そのものに、検品を一つの工程として埋め込むのが唯一の解決策です。

株式会社Fyveでは、調査・記録・下ごしらえといった裏方の定常業務をAIに任せる仕組みを日々運用しています。本記事では、その運用で私が実際に使っている「検品を工程に埋め込む手順書」の書き方を、具体例つきで解説します。

なぜ「任せた後の検品」は失敗するのか

AIに仕事を任せるとき、多くの人は「AIが作る」→「あとで自分が確認する」という2ステップで考えます。この分け方が、そもそも事故のもとです。

検品を人間の善意に頼ると必ず抜ける

「あとで確認する」は、忙しい日・眠い夜・件数が多い日にいちばん先に省略されます。私自身、AIが出してきた成果物を10本連続でチェックしていると、7本目あたりから明らかに目が滑ります。検品を人間の集中力や善意に依存させた時点で、それは「たまにしか働かない検品」になります。

手順書に「最後に人間が確認する」とだけ書いてある運用は、実質「検品なし」と同じだと考えたほうが安全です。しかも件数が増えるほど、確認の質は下がります。1日1件なら丁寧に見られても、1日50件を人が全部見るのは現実的ではありません。任せる量を増やしたいのに、検品が人の目視のままだと、そこが真っ先にボトルネックになります。

いちばん怖いのは「静かな失敗」

派手にエラーを吐いて止まる失敗は、まだ気づけるので軽症です。本当に怖いのは、AIが「それらしい成果物」を平然と出してきて、そのまま通ってしまう静かな失敗です。

私は以前、AIに下書きを保存させる自動化で、すでに古くなった下書きに上書きし続けているのに一度も気づかなかったことがあります。エラーは一切出ていませんでした。手順書に「保存できたか」を確認する工程しか無く、「正しいものを保存できたか」を確認する工程が無かったからです。この経験で、検品は工程として書き込まないと存在しないのだと痛感しました。

検品を工程に埋め込む3つの原則

「あとで確認」をやめ、検品を作業手順の中に一工程として組み込む。そのときに私が守っている原則が3つあります。

原則1｜合否を機械が判定できる形にする

「よさそうならOK」という曖昧な基準は、工程にできません。検品を工程にするには、合格条件を「見ればYes/Noで答えられる形」まで落とし込む必要があります。

たとえば私が使っている条件は、「必要な項目がすべて埋まっているか」「要約文が空でなく規定の文字数に収まっているか」「同じ内容が過去のものと重複していないか」といったように、すべて機械がYes/Noで返せる形にしています。判定が人の感覚に依存する条件は、そもそも検品工程に向きません。

原則2｜検品する主体を、作業した主体から分離する

作った本人（AI）に「これで合ってますか？」と聞くと、たいてい「合っています」と返ってきます。作業したのと同じ文脈で自己採点させても、甘くなるのは人間と同じです。

そこで私は、検品を別のプロセスに完全に分離しています。作業をしたAIとは別に、まっさらな状態の検品役AIを立ち上げ、「あなたは第三者の検査担当です」と役割を与え、成果物を"評価対象のデータ"として渡す。作り手の意図や都合を一切知らない状態で採点させることで、身内チェックの甘さを構造的に排除しています。

原則3｜疑わしきは止める（fail-closed）

検品工程で最後に決めるべきは「判定できなかったとき、どちらに倒すか」です。私は必ず「止まる」側に倒します。検品で不合格だったときはもちろん、そもそも判定結果がうまく取れなかったとき・途中で処理が落ちたときも、すべて次の工程へ進めず保留箱へ回します。

「よくわからないけどたぶん大丈夫だから出す」を許すと、検品工程はあってないものになります。判定不能は"合格"ではなく"保留"に倒す。これが無人でAIを走らせても事故を出さない最後の砦です。

検品ゲートを挟んだAIの流れ図。生成→検品ゲート→合格は次工程へ・不合格や判定不能は保留（fail-closed）

Claude CodeAIにどこまで任せるか｜「直す」と「決める」の線引きを仕組みにする

検品を「後付け」するとなぜ形骸化するのか

この3原則を話すと、「じゃあ既存の手順書の最後に検品ステップを足せばいい」と考えたくなります。ですが、検品は後付けだと形だけになりがちです。理由は3つあります。

1つ目は、後付けの検品は「作業が終わってから」動くため、疲れているタイミング・締め切り間際に飛ばされやすいことです。2つ目は、後付けだと合格条件が言語化されておらず、「まあ大丈夫だろう」で通ってしまうこと。3つ目は、作業の流れと切り離された検品は、そもそも実行され忘れることです。

だから私は、新しい作業をAIに任せると決めた時点で、「どう作らせるか」と同じ熱量で「どう検品するか」を先に設計します。検品は品質保証のためのオプションではなく、作業の一部です。作る工程と検品する工程を、最初からセットで手順書に書く。この順番を守るだけで、形骸化はかなり防げます。

検品を後工程に置く場合と埋め込み工程にする場合の比較図。後付けは飛ばされて形骸化し、埋め込みは飛ばせず止まる

私の実運用｜手順書に検品を埋めた4つの例

原則だけだと抽象的なので、私が実際に自動化の手順書へ書き込んでいる検品工程を、具体的に4つ紹介します。

例1｜別のAIに検品させ、合格した成果物だけ次へ進める

作業が終わった直後に、独立した検品工程を挟みます。機密情報や個人情報が混じっていないか、事実関係の裏取りが取れているか、決めた書式を守っているか——これらを、作り手とは別プロセスの検品役AIがチェックします。

合格したものだけを次の工程へ進め、不合格や判定不能は保留箱へ。人間が見るのは、保留に回った例外分だけです。「全部を人が見る」から「引っかかった分だけ人が見る」へ切り替えるだけで、任せられる量が一気に増えます。設計上のポイントは、検品役が成果物の中身に引きずられない形にしておくことです。成果物はあくまで評価対象のデータとして扱わせる。ここが緩いと、チェックする側がチェックされる側に流されてしまいます。

例2｜スクリーンショットを証拠にして事実誤りを捕まえる

AIは、それらしい数字やバージョン名を平気で作ります。これを防ぐために、事実に関わる部分は「AIの記憶」ではなく「一次情報の実物」で裏を取る工程を入れています。

具体的には、公式ページを自動でスクリーンショット撮影し、その画像を証拠として本文と突き合わせます。実際、この工程がAIの書いた古いバージョン表記の誤りを捕まえ、公式の最新表記に直したことがあります。スクリーンショット＝証拠＝ファクトチェックが、そのまま一つの検品工程になっているわけです。

例3｜台帳で二重投入・重複を止める

自動化で地味に効くのが「同じものを二度出さない」検品です。私は処理した成果物をすべて台帳に記録し、新しく出すものが台帳にすでに無いかを照合してから次へ進めます。

この照合工程が無いと、仕組みが少し止まって再開したときに同じ投稿を二重に出す、といった事故が起きます。重複チェックは派手さはありませんが、「出す前に必ず台帳と突き合わせる」を工程化しておくだけで、無人でも破綻しにくくなります。

例4｜保存したら読み直して整合を確認する

「保存に成功した」と「正しく保存された」は別物です。そこで、書き込み処理のあとに必ずもう一度読み直して、意図した内容がそのまま入っているかを確認する工程を挟みます。

先ほどの「静かな失敗」を防ぐのがこの工程です。書いて終わりにせず、書いた結果を機械が読み返す。この一手間を手順書に足すだけで、気づけない事故の多くは検知できるようになります。読み直しの工程は、外部のサービスにデータを渡す処理や、上書きが起きうる処理ほど効きます。取り返しがつきにくい操作の直後こそ、「本当に意図どおりになったか」を機械の目で確認しておく価値があります。