Claude Codeで制作依頼の不足と矛盾を見つける方法

8件の架空依頼で着手できるかを判定する

目的や締切、素材の使用許可が抜けたまま制作を始めると、あとで手戻りが起きます。この記事では、架空の動画制作依頼8件（requests.json）と判定規則（judging-rules.md）をClaude Codeに読ませます。依頼ごとに「着手できる（ready）」か「確認待ち（hold）」かを判定させ、その結果を人があらかじめ決めておいた答えと照合します。最後に、足りない情報を誰に確認するかを整理します。

使うファイルは、教材ページで配布している練習セット production-review-practice にすべて入っています。依頼の内容も、商品も、確認担当者も架空です。判定規則は練習用に作ったもので、実際の掲載先の規約や仕様を表すものではありません。

依頼1件には、次のような項目があります。

判定規則は11条あり、記録するissue codeは10種類です。判定の基準日は2026年10月14日です。8件の依頼には、空欄、0秒の尺、食い違う尺、基準日より前の締切といった問題が仕込まれています。

入力と判定規則と期待結果を別の場所に置く

ZIPを展開すると、最上位に production-review-practice フォルダができます。中身は次の二つに分かれています。

期待結果は、人が判定規則に沿って決めた答えです。AIが出した結果ではありません。期待結果が実行フォルダにあると、AIがそれを読んで答えを写せてしまいます。そのため、exercise/ の3ファイルだけを別のフォルダへコピーします。下の例ではZIPを ~/Downloads に展開しています。自分の環境に合わせて読み替えてください。

mkdir -p ~/cc-practice/request-check
cp ~/Downloads/production-review-practice/exercise/requests.json \
   ~/Downloads/production-review-practice/exercise/judging-rules.md \
   ~/Downloads/production-review-practice/exercise/prompt.txt \
   ~/cc-practice/request-check/
ls ~/cc-practice/request-check

ls で表示されるのが上の3ファイルだけなら、準備は完了です。Claude Codeをまだ入れていない場合は、インストール手順の記事か公式のクイックスタートを見て、claude --version でバージョン番号が表示されるのを確かめてから進めてください。

コピー先でCLIを1回実行する

教材の手順では、prompt.txt に書かれた指示を実行します。比較できるように、実測で渡した指示文を載せておきます。

requests.json と judging-rules.md を読み、8件すべての不足と矛盾を判定してください。入力を推測で補完せず、規則の基準日を使ってください。results の id、decision、issue_codes、confirmation（誰に何を確認するかを短い日本語で記載）を返してください。外部への送信や制作開始は行いません。

実測では、印刷モード（-p）のCLIに上の指示を渡し、ユーザー設定とMCPを読み込まない条件で1回実行しました。CLIがJSONで返した応答は、ホスト側のスクリプトが actual-results.json として保存しています。Claude Codeが自分でファイルに書き込んだわけではありません。

実測に近い条件で試す参考コマンドです。実測はCLI 2.1.285と構造化出力を使いましたが、下の例は文章としての応答を保存するため、そのままでは照合用JSONにならない場合があります。各フラグの意味はCLIリファレンスに載っています。--setting-sources project はプロジェクトの設定だけを読み込む指定です。--strict-mcp-config に空の --mcp-config を組み合わせると、MCPサーバーを使わずに実行できます。

cd ~/cc-practice/request-check
claude -p --model claude-opus-5-5 --tools Read --allowedTools Read --setting-sources project --strict-mcp-config --mcp-config '{"mcpServers":{}}' "$(cat prompt.txt)" > actual-results.json

このコマンドでは、シェルのリダイレクト（>）が応答をファイルに保存します。応答の前後に説明文やコードブロックの記号が付いていたら、JSONの部分だけを残してください。手で直した場合は、そのことも記録しておきます。照合の前に python3 -m json.tool actual-results.json > /dev/null を実行し、JSONの構文エラーがないことを確認します。

8件の結果を期待結果と照合する

照合は、AIに渡していない answer-key/ を使って、教材の最上位フォルダから実行します。

cd ~/Downloads/production-review-practice
python3 answer-key/check_result.py ~/cc-practice/request-check/actual-results.json

照合スクリプトが比べるのは id、decision、issue_codes の3つだけです。confirmation の文章は照合の対象外です。Python 3がない場合は、answer-key/ の期待結果と出力を目で見比べて照合できます。

2026年10月14日に1回実行したときの出力と照合結果は次のとおりです。

照合の記録では、件数が8件であること、IDに重複がないこと、期待したIDがすべてそろっていることを確認しました。そのうえで、8件中8件が一致しました。ただし、これは架空データと練習用の規則で1回だけ実行した結果です。何度実行しても同じ結果になるとは限りませんし、実際の依頼書で同じ精度が出るとも言えません。

照合の対象外になる確認先の文章は、人が読みます。たとえばR01には「架空の制作確認担当 Aの確認を経て進行可」と出力されました。しかし ready は規則上の不足がないことを示すだけで、制作を始めてよいという承認ではありません。また、R05からR08では尺や締切の確認先が制作確認担当になっていました。尺や締切を依頼者が決める体制なら、宛先を依頼者に変えてください。

不足情報を次の依頼へ戻す

hold になった依頼は、確認する相手ごとにまとめて戻すと、やり取りの回数を減らせます。次の表は、上の出力をもとに人が書き直した質問の例です。

R06のように値が食い違うときは、AIや作業者がどちらかを選んで進めず、依頼者に決めてもらいます。依頼書にどの項目を用意しておけば抜けが減るかは、AI広告制作のためのクリエイティブブリーフの記事が参考になります。

回答が返ってきても、元の requests.json は上書きしないでください。新しい作業フォルダへ入力3ファイルを複製し、その中の requests.json に回答を反映します。新しいフォルダで実行し、2回目の記録として残します。元の answer-key は修正後の入力の正解ではないため、そのまま合否判定に使いません。更新版を照合する場合は、人が期待結果も事前に更新します。

実行ごとに記録を残す

教材の measurement-and-updates/run-log.csv に、1回の実行につき1行を追記します。最初から入っている example-baseline の行は今回の記録例です。自分の結果は my-run の行か新しい行に書き、記録例の値と混ぜないようにします。

今回の記録（example-baseline の行）は次のとおりです。

CSVの空欄は0ではなく「未計測」という意味です。実行していない回を成功として書かないでください。照合できなかった回は、失敗または未照合として残します。

次の一歩

毎回同じ前提で判定させたい場合は、教材のCLAUDE.mdの記入例を使えます。書き方はCLAUDE.mdの記事で解説しています。ただし、CLAUDE.mdに書くのは作業上の指示です。ファイルの読み書きや外部への接続、送信の権限を制限するものではなく、実際のサービスでの認証や最小権限の設定の代わりにはなりません。

まずは練習セットで1回実行し、期待結果と実際の結果を別々に保存するところから始めてください。

入力データと確認用紙を教材ページで受け取る