AIが作った資料、そのまま出してない？Claude Codeで「AI部下」に検品させる神ワザ7選

AIが優秀になるほど抜ける「最後の1工程」

　突然ですが、製造業の品質保証部門を想像してください。製品の検品は、いくつもの項目を2人1組でダブルチェックして、記録も残す。そんな部署でも、AIが作った資料になると話が変わりがちです。

　Claude Codeに作ってもらった助成金の申請資料を、自分で軽く読んで、そのまま提出してしまう。あとで見返したら、対象人数と単価の掛け算が1桁ズレていて青ざめる……研修でこのような例を話すと、多くの方が「うちでも起きそうだ」という顔をされます。

　製品の検品はプロ級でも、AIが作った資料には同じ発想が向いていない。よく考えると、これは特別な話ではありません。「作った本人が、自分で読み返して、大丈夫だと思い込む」のは、人間が昔からやってきた失敗の典型パターンです。自分の書いた文章の誤字には気づきにくいのに、他人の文章の誤字にはすぐ気づく。あの現象が、AIの成果物でもそのまま起きています。

　これまで、Claude Codeを「並列で働かせる」「記憶を仕込んで育てる」「手順書を渡して任せきる」方法を紹介してきました。ただ、AI部下が優秀になり、任せる仕事が増えるほど、実は見落とされがちな工程があります。それが「出す前に誰が見るか」です。

　今回は、非エンジニアでも今日からできる、Claude Codeの「AI部下」に検品させて、提出前の事故を防ぐ方法を、コピペで使えるプロンプトとスキルテンプレ付きで解説します。

【5分でできる】まず試したい「AI検品」即効プロンプト3選

　最後まで読む時間がない方のために、そのままコピペで使える検品プロンプトを3本先にお渡しします。

■即効プロンプト1. 新しいセッションを開いて、ゼロから見せる
　同じチャットの続きで「これ見直して」と言うのは、実は一番弱い検品です。Claude Codeはあなたとのやり取りの流れを踏まえたまま見返すので、「さっき自分がそう判断した理由」を無意識に引きずってしまいます。一番シンプルで効果が高いのは、新しいセッションを開いて、成果物だけを渡すことです。

プロンプト

あなたは今回はじめてこの資料を読む、社内の第三者レビュー担当です。
作成の経緯や作成者の意図は知らないものとして、以下の資料だけを根拠にチェックしてください。

【資料】
（ここに検品してほしい資料を貼り付け、またはファイルを指定）

【チェック観点】
1. 数字の計算・単位が合っているか
2. 根拠が示されていない断定がないか
3. 誤字脱字、表記ゆれ
4. 読んで意味が通らない箇所

【出力】
- 指摘一覧（該当箇所を引用しながら）
- 「ここは問題なし」と判断した箇所も、理由をひと言添える

※注意: 資料の背景説明を先に読まず、資料そのものだけで判断してください。判断に迷う箇所は「問題なし」に倒さず、指摘に含めてください。

■即効プロンプト2. 「5つの観点」で一気にチェックさせる
プロンプト

以下の資料を、次の5つの観点でチェックしてください。観点ごとに「OK / 要修正 / 要確認」で判定し、理由を添えてください。

【資料】
（検品対象を貼り付け）

【観点】
1. 事実確認: 出典のない断定、確認が必要な数字・固有名詞
2. 数字: 計算・単位・表と本文の食い違い
3. 論理: 根拠と結論の間に飛躍がないか
4. 誤字脱字・表記ゆれ
5. 形式: フォーマット逸脱、必須項目の欠落

【出力】
- 観点別の判定表
- 総合評価（このまま提出可能か / 修正が必要か）

※注意: 判断に迷う場合は「OK」に倒さず「要確認」にしてください。

■即効プロンプト3. 指摘への対応ルールを先に決めておく
　検品させて指摘が返ってきても、扱い方を決めていないと、結局すべて自分で読み直して判断することになり、時短になりません。あらかじめ「指摘の重み付け」までさせるのがコツです。このプロンプトは、上記の2つのプロンプトで指摘一覧を出させた検品セッションの続きで、同じセッションに貼って使ってください。

プロンプト

先ほどの指摘一覧を、次の3段階に分類し直してください。

【分類基準】
- 修正必須: 事実誤認、計算間違い、機密情報の露出など、直さないと事故になるもの
- 修正推奨: 誤解を招きうる表現、読みにくい箇所
- 判断保留: AIには判断できず、人間の確認が必要な事項

【出力】
分類ごとに指摘をまとめ、「修正必須」には具体的な修正案も添えてください。

AIが作ったものをチェックする「基本の3段階」

　「Claude Codeで検品」というと難しく聞こえますが、ビジネス利用では次の3段階で考えるとシンプルです。

■段階1：同じセッションで「見直して」と言う（簡単だけど効果は弱め）
　もっとも手軽なのはこれです。ただし、効果は限定的です。理由は単純で、同じセッションは、その資料を作ったときの前提や判断をそのまま覚えているからです。「この表現でいいと思って書いた」という判断を、見直すときも引きずってしまいます。人間で言えば、自分で書いたレポートを自分で校正するのに近い状態です。

■段階2：新しいセッション・別セッションで検品する（基本形）
　次に効くのが、セッションを分けることです。新しいセッションでは、それまでの会話履歴は引き継がれないため、その資料を作ったときの細かな判断過程から距離を置いて確認できます。ただし、CLAUDE.mdやauto memoryなど、セッションをまたいで読み込まれる前提情報は残ります。そのため、「作成の経緯は考慮せず、成果物だけを根拠に確認して」と明示するのがポイントです。

　以前紹介したsubagentsも、実はこの目的にそのまま使えます。アンソロピックはforeground（メイン作業を止めて実行）とbackground（同時に裏で走らせる）の両方を説明していますが、検品なら「本文を書き終えたら、その内容だけを渡して別のsubagentに確認させる」使い方が向いています。

　書いた本人（メインの会話）と、確認する担当（独立したコンテキストのsubagent）を分ける。これが検品の基本形です。

■段階3：検品専用の手順書（スキル）を持たせた担当に任せる（応用形）
　さらに一歩進めると、「スキル」の出番です。毎回同じ観点でチェックしてほしいなら、「検品担当」用のSKILL.mdを一本作っておけば、いつも同じ基準の検品担当がすぐ呼び出せます。これは後ほど神ワザ6で詳しく紹介します。

「作った本人に検品させない」の“本当の意味”

　人間の職場で、製造ラインの担当者と検品ラインの担当者を分けるのには理由があります。作った本人は、無意識に「これでいいはず」というバイアスを持って自分の仕事を見てしまうからです。冒頭の品質保証部門の方が、製品には2人1組のダブルチェックを徹底しているのに、AIが作った資料には同じ発想を向けていなかったのは、まさにこの盲点でした。

　Claude Codeでも構造は同じです。ある文書を書いたセッションは、その文書を書くために「こう解釈しよう」「この情報は省いていいはず」という無数の小さな判断を積み重ねています。その積み重ねの延長で見直しても、判断そのものを疑い直すのは苦手です。

　一方、初めてその資料を見るセッションは、作成時の会話履歴や細かな判断過程を持っていません。だからこそ、「この数字、根拠は？」「ここ、話が飛んでない？」と、書いた本人には見えなくなっていた箇所を拾えます。

　もちろん、これは万能ではありません。検品担当のセッションも、同じ仕組みの上で動いている以上、書いた側と似たクセを持つこともあります。「別セッションにすれば完璧」ではなく、「同じセッションよりは独立した目になる」くらいの認識で使うのが実務的です（この点は後ほどもう一度触れます）。 【次ページ】【保存版】事故とサヨナラ…超実用「AI検品」神ワザ7選