Claude Codeを絶対にサボらせない完全解説マニュアル

Claude Codeに仕事を頼んだら、途中で切り上げて返ってきた。そんな経験はないでしょうか。

実はこれ、能力が足りないから起きているのではありません。どこまでやれば合格かが決まっていないから起きています。

私はこれを、さぼりぐせのある優秀な新人だと思うことにしています。頭はとてもいいのに、放っておくと一番ラクな答えを返してくるからです。

私は毎日10時間以上Claude Codeを使い、チームで導入できるレベルまで作り込む仕事をしています。その中で、サボらせないルールの作り方と、そのルールを作っても効かなくなる落とし穴の両方にぶつかってきました。

Claude Codeとは、指示を出すと自分の判断でコードや文章の作業を最後まで進めるAIツールのことです。この自律性の高さこそが、今回向き合うテーマの正体です。

この記事では、実際に使っているいわゆるプロンプトの実例つきで、ルールの作り方と落とし穴の直し方を完全解説します。そのまま使える指示文の例も紹介するので、読んだその日から自分のAI運用に取り入れられます。

そもそもなぜClaude Codeはサボるのか

Claude Codeは、答えを作るとき、それらしく見えて手数の少ない形を選びやすい性質を持っています。少なく書いても多く書いても、見た目の体裁は同じように整ってしまうため、体裁が整った時点で本人としては仕事が終わったことになるのです。

だから、指示を強くしても直りません。直るのは、仕事のルールを決めたときです。

なぜルールが無いとサボりが直らないのか

ルールが決まっていない仕事は、どこまでやれば終わりなのかが本人にも分かりません。逆にルールさえ決まっていれば、能力が高い相手ほどきっちり埋めてきます。

指示を具体的にすることの効き目は、開発元の公式ガイドにもはっきり書かれています。

Claudeは、明確ではっきりした指示によく応えます。どんな出力がほしいのかを具体的に伝えることが、結果を良くする助けになります。

指示文を強くするのではなく、細かくする。この違いが結果を分けます。

サボりを性格の問題として扱うと直らない

私も最初のころは、指示の言い方を強くすれば直ると思っていました。もっと丁寧に、もっと真剣にお願いする。ですが結果はほとんど変わりませんでした。ラクな道が残っている限り、そちらが選ばれるからです。

変わったのは、お願いの強さではなく仕事のルールを変えたときでした。数を決める、言葉を縛る、途中で止まれないようにする。人間の新人教育でも同じで、気合いを求めるより先に、業務の手順書と合格の基準を渡したほうが早く戦力になります。ここから先の5つのルールは、その手順書と基準をClaude Code向けに書いたものだと思ってください。

もう1つ知っておくと気がラクになるのが、この性質は使い手の腕とは関係なく出るということです。指示を書くのに慣れてきたと思っていた時期ほど、指示が短くなりがちです。短い指示ほど、埋める余白が本人の判断に委ねられます。だからルールは、慣れてからこそ効いてくるのです。

Claude Codeをサボらせないための5つのルール

私が実際に使っているルールは5つあります。

書くべき項目の数と出力フォーマットを先に決めて渡す

5つ書いてほしいなら5つと数字で言います。数のない仕事は、終わりの形が決まりません。数を決めるのは、締め切りを決めるのと同じです。

数だけでなく、出力フォーマットもそろえておきます。見出しの階層や1項目あたりの行数、必ず入れる欄の名前まで書いて渡すと、抜けている欄が一目で分かるようになります。

使ってほしくない言葉の一覧を渡す

一覧を渡すと、書けない言葉がある分、中身を書くしかなくなります。ふわっとした一文で埋めていた場所が、具体的な手順や数字に置き換わっていきます。

途中で切り上げるのを先に止めておく

省略しないでください、と後から言っても、すでに出てきた答えは戻りません。だから指示文の中に、最初から止める一文を置いておきます。

長い作業をひと息で頼むと、途中で力尽きた分がそのまま抜けになります。先に構成だけ出させて承認してから本文に進ませる、段階承認をはさむのも有効です。ずれたまま最後まで走る事故がなくなります。

書き終わったあとに自分で採点させる

提出する前に、決めた基準と照らして確かめてから終わること、という一文を足します。自己採点をさせると、書いている途中では見えていなかった抜けが自分から出てきます。

別のAIにその採点を見直させる

作った本人が採点すると、どうしても自分に甘くなります。別のAIに見てもらった瞬間、見つかる抜けは一気に増えます。この考え方は、開発元の実務ガイドにも書かれています。

検証を担当する別のエージェントは、新しいモデルにその結果への反証を試させるので、作業をした本人が自分を採点することにならない。

この5つを入れる前と後で、返ってくるものの再現性が変わります。毎回ちがう出来のものが返ってくる状態から、だいたい同じ出来のものが返ってくる状態へ。この再現性こそが、Claude Codeに仕事を任せられるかどうかの分かれ目です。

AIエージェントとは、Claude Codeのように指示を受けて自分で判断しながら作業を進めるAIツール全般を指す言葉です。この5つのルール1つずつの具体的な作り方、渡す順番、採点表の作り方まではAIエージェントをサボらせない指示と仕組みの作り方で詳しく扱っています。

Claude Codeがルールだけではサボらなくなるとは限らない2つの落とし穴

ここまでの5つのルールを作っただけでは、実はまだ足りません。私自身、ルールを作ったのにすり抜けるという壁に何度もぶつかりました。

原因を探っていくと、ルールの中身ではなく、ルールを見張る側に見落としがあると分かってきました。

チェックの仕組みが気づかないうちに止まっている

自己採点や別のAIによる検証も、一度作って動かし始めると、動いていることが当たり前になります。

処理に時間がかかりすぎて途中で打ち切られていても、誰かがその瞬間に気づかない限り、止まっていること自体が放置されます。見張る係を置いたつもりが、その係自身が働いているかを誰も見ていない、という状態です。

似た対策としては、どこまでできたら完了なのかという完了の定義を先に決めておく方法があります。ほかにも、hookによる自動チェックを組み込む方法や一次情報との照合、複数のAIによる多数決で安定させる方法が知られています。hookとは、特定の操作の前後で自動的に決まった処理を走らせる仕組みのことです。

どの対策にも共通して、その仕組みが今も生きているかという視点が抜けやすいのです。完了の定義を決めても、それを照合するチェックが止まっていれば通ってしまいます。

直したこととメモしただけのものを混同している

課題を見つけたとき、あとで直しますとメモするだけで終わらせてしまうことがあります。

メモした瞬間は対応したような気分になります。ですが、実際に直したものとメモのままのものを分けて数えていないと、どちらも同じ対応済みに見えてしまいます。

とあるエンジニアの方は、この状態をやったとやれたは別の事実だと表現しています。

やったとやれたは別の事実だ。やれたことを証明するまで完了ではない。

言われてみれば当たり前ですが、この2つを分けて考える習慣がないと、メモしただけのものまで完了扱いになってしまうのです。

入口と出口の2か所に見張りを置く

先ほど触れた段階承認と、この2つの落とし穴対策は組み合わせると効果が高まります。構成の段階で一度承認を通し、完成した段階で別の検証を通す。入口と出口の2か所に関所を置く形になります。

入口だけだと、途中で方向がずれたまま最後まで走ります。出口だけだと、根っこからずれていた場合に全部を作り直すことになります。2か所に置くと、ずれが小さいうちに見つかるので、直す手間そのものが小さくなります。

関所を増やしすぎると今度は止まってばかりになるので、私は入口と出口の2つに絞っています。作り直しが軽い作業なら出口だけで十分で、半日かかる作業なら入口にも置いたほうが結果的に早く終わります。

Claude Codeで実際に起きた落とし穴の実例

サボりの形を整理する

サボりの形は、私が繰り返し出会ってきたものだけでも、次の表のように整理できます。

サボりの形	実際に返ってくるもの
数を減らす	頼んだ数の半分ほどで書き終えて報告してくる
途中で切り上げる	前半だけ書いて、あとは同じ流れですと添えて終わる
具体を書かない	状況を見て決めます、と中身のない言い方で埋める
形を勝手に変える	渡した出力フォーマットを無視して自己流に短くする
検証を飛ばす	確認したと報告するが、実際には確認の手順を通っていない

この5つは別々の問題に見えて、原因は1本につながっています。どれも、どこまでやれば合格なのかが決まっていない状態、または合格の線を照合するチェックが止まっている状態で起きているのです。

私自身が経験した実例

私自身、Claude Codeに書かせた原稿を同じAIに見直させたことがあります。

決まりを破っていないか確認してと頼み、大丈夫ですと返ってきました。

ところが実際に開いてみると、決まりを破った箇所がそのまま残っていました。

同じAIに自分の仕事を採点させても、自分のミスには気づきにくいのです。

自分で書いた文章の誤字は、何度読み返しても見つからないのに、他の人が読むとすぐに見つかることがありますよね。

AIも同じで、自分が作ったものを自分で疑う視点は弱くなりがちです。作った側は、自分がどう考えて書いたかを知っています。その前提が頭にある分、書いていない部分まで補って読んでしまうのです。

検証する側にその前提を渡さなければ、書かれた文字だけで判断するので、抜けがそのまま抜けとして見えます。だから私は、作った側が書いた制作メモを検証役には見せない運用にしています。人間の検品でも、作業者の説明を聞きながら検品すると甘くなりますよね。見るのはモノと基準、という形に寄せると、検証の力が落ちません。

チェックの仕組みが止まる形としてよくあるのは、処理に時間がかかりすぎて途中で打ち切られるケースです。

不合格を知らせる係が黙っていても、それが合格の証なのか係が止まっているだけなのかは、外からは見分けがつきません。

課題の扱いでも同じことが起きます。

あとで直しますとメモした項目と、実際に手を動かして直した項目を分けて数えていないと、どちらも対応済みの列に並びます。

対応済みという言葉だけを信じていたら、この見落としには気づけません。

見落としの型を整理すると、次の表のようになります。

見落としの型	気づきにくい理由	気づくきっかけ
チェック自体の停止	止まっていても普段どおりに見える	わざと失敗するデータを通す
起票と実装の混同	メモした時点で対応済みに見える	直した件数とメモの件数を分けて数える
自己採点の甘さ	自分の作業は自分では疑いにくい	別の立場から確認させる

この3つの型に共通しているのは、どれも悪意ではなく仕組みの穴で起きるという点です。Claude Codeが嘘をつこうとしているわけではありません。合格の基準と、それを照合する経路のどこかが途切れているだけです。だからこそ、直すべきは気合いではなく経路のほうです。止まっている検知器を直す、起票と実装を別の欄で数える、検証役に制作メモを見せない。どれも一度作れば、以後は毎回同じように働きます。

経路を作ったあとも、放っておけばまた同じ場所が緩みます。負荷が増えて処理が重くなったとき、真っ先に削られるのはこうした見張りの部分だからです。だから作って終わりにせず、月に一度は検知器そのものにわざと失敗するデータを通して、まだ生きているかを確認する習慣まで含めて設計しておくと安心です。

完了したのに実は何も変わっていなかったという現象そのものについてはAIエージェントが嘘をつく現象を見破る3つのステップで詳しく扱っています。

サボりの型そのものを先に知っておきたい方はAIエージェントがサボる5パターンもあわせてどうぞ。

サボらせないために使えるプロンプト実例

ここまでのルールと落とし穴対策を、そのままコピーして使える指示文の形にまとめました。ステップ1で数を固定し、ステップ2でチェックの仕組みを見張ります。ステップ3で起票と実装の混同を防ぎ、ステップ4で別の立場から確認させます。

こうしたプロンプトの型を実際に運用した記録はAI活用の無料メルマガでも随時お届けしています。

これは、項目数を先に決めて渡すルールを、そのまま指示にしたものです。数を決めるだけで、返ってくる分量のばらつきがはっきり減ります。

これは、チェックの仕組み自体が動いているかを見張る、をそのまま指示にしたものです。

普段どおりのデータで試すと、動いているように見えてしまうため、あえて失敗する形を用意することがポイントです。

これは、直したこととメモしただけのものを分けて数える、を反映したプロンプトです。

対応済みという一言に逃げず、数字で分けて報告させることで、やったつもりの状態が見えるようになります。

同じ会話の中で作った本人にもう一度確認させるより、視点を切り替える一言を挟むだけで、出てくる指摘が変わります。

Claude Codeをサボらせないために迷いやすいところ

5つのルールを一度に全部入れないとダメですか？

一度に入れなくて大丈夫です。効きが早いのは項目数を先に決めて渡すルールなので、まずそこだけ入れてみてください。返ってくる分量が安定したら、次のルールを1つずつ足していくと、どれが効いたのか分かります。

チェックの仕組みが止まっていないかはどう確認すればいいですか？

わざと失敗するデータを1つ用意して、定期的にそのチェックへ通す方法が確実です。普段のデータだけを通していると、止まっていても気づきにくくなります。

直したこととメモしただけのものはどう区別すればいいですか？

課題の一覧に済と未のような印を付け、実際にファイルや成果物を確認した件数だけを済に数える方法が有効です。数字にすることで、やったつもりを防げます。

自己採点だけでは足りないのはなぜですか？

自分が作ったものを自分で疑う視点は弱くなりがちだからです。私自身、同じAIに見直させても決まりを破った箇所を見逃されたことがあります。

別のAIを用意するのは大変ではないですか？

同じツールの中で別の担当として立てれば足ります。新しく契約を増やす必要はありません。大事なのは別のサービスを使うことではなく、作った側の思考を渡さない状態で見てもらうことです。

ルールと見張りの両方が揃って、初めてサボらせなくなる

Claude Codeにルールを作ることは、決して無駄ではありません。

ただしルールを作って終わりにするのではなく、そのルール自体が今も動いているかを見張ること。そして、直したこととメモしただけを分けて数えること。

この2つまでセットにして初めて、サボりから抜け出せます。

私も最初から落とし穴に気づいていたわけではなく、実際にすり抜けを経験してから、1つずつ見張る仕組みを足してここまで来ました。ルールを決める前は、頼むたびに出来栄えがばらついていました。ルールを決めたあとは、だいたい同じ出来のものが返ってくるようになりました。さらに見張る仕組みを足したあとは、すり抜けた箇所だけを確認すれば済むようになりました。

減ったのは作業そのものではなく、探す時間のほうでした。ルールを作る作業も見張る仕組みも、一度作れば使い回せます。今日決めた数の指定と止める言葉の一覧は、明日の別の仕事にもそのまま渡せます。だから最初の1回だけ手間をかける価値があるのです。

まずは今日、頼む項目の数を1つ決めて渡してみてください。そこからサボらせない運用は始まります！

こうしたルールと見張りの作り方を、実際に試した記録つきで届けているのがAI活用の無料メルマガです。

―――――――――