■ アイキャッチファイル名: claude-code-06-eyecatch.pngalt: Claude Code への頼み方を変えると返ってくるものが変わることを表したイメージ図
Flat vector editorial illustration, wide 16:9, deep indigo background. Two hands passing apackage toward a terminal window: one package is loosely and carelessly wrapped, coming apart(dim); the other is neatly and carefully wrapped, glowing soft amber. Same object, differenthandover. The terminal returns a corresponding result for each. Calm, instructive, warm.Include Japanese text in a clean modern gothic sans-serif:
- Large heading upper left: 「Claude Code 入門」
- Subtitle beneath: 「第6回 頼み方」
- Small caption lower right: 「2026年8月版」
Text crisp, correctly formed Japanese characters, high contrast.Deep indigo (#1B1C4B) base with amber (#F4A62A) accents. Text in white and amber.No English words, no logos, no watermark.
■ 図1：曖昧な基準と、判定できる基準（本文「1」の直後）ファイル名: claude-code-06-fig01-vague-vs-measurable.pngalt: 曖昧な指示と、機械が判定できる指示の違いを示した図
Flat vector comparison diagram, 16:9, deep indigo background, split left and right.LEFT: a shape with soft, blurred, undefined edges — you cannot tell where it begins or ends.Dim, muted indigo.RIGHT: the same shape but with a clean, precise outline and small measurement marks along itsedge. Glows soft amber.Include Japanese text in clean gothic sans-serif:
- Above left: 「読みやすく書いて」 beneath: 「基準が人によって違う」
- Above right: 「20行以内、ネストは3段まで」 beneath: 「同じ答えになる」
Deep indigo (#1B1C4B) base, amber (#F4A62A) on the right shape. Text crisp.No English words, no logos, no watermark.
■ 図2：頭の中の前提は渡らない（本文「2」の直後）ファイル名: claude-code-06-fig02-unspoken-context.pngalt: 自分の頭の中にある前提は、書かないと相手に渡らないことを示した図
Flat vector diagram, 16:9, deep indigo background. On the left, a head silhouette containingseveral small note shapes (the assumptions). An arrow points right toward a terminal window,but only ONE note actually travels along the arrow — the rest stay inside the head, dim. Thesingle travelling note glows soft amber, and the terminal looks incomplete as a result.Include Japanese text in clean gothic sans-serif:
- Above the head: 「自分の中にある前提」
- Beside the notes staying behind: 「書かないと渡らない」
- Beside the travelling note: 「渡ったのはこれだけ」
Deep indigo (#1B1C4B) base, amber (#F4A62A) on the travelling note. Text crisp.No English words, no logos, no watermark.
■ 図3：できているか、と合っているか（本文「3-2」の直後）ファイル名: claude-code-06-fig03-done-vs-correct.pngalt: 形式が整っていることと、内容が正しいことは別だと示した図
Flat vector diagram, 16:9, deep indigo background. Two check marks side by side. The left checkmark sits on a neatly formatted document outline (dim). The right check mark sits on the samedocument but with a magnifying glass examining its contents, glowing soft amber. The visualpoint: the first only confirms the shape, the second confirms the substance.Include Japanese text in clean gothic sans-serif:
- Under left: 「できているか」 beneath: 「形が整っている」
- Under right: 「合っているか」 beneath: 「中身が正しい」
Deep indigo (#1B1C4B) base, amber (#F4A62A) on the right. Text crisp.No English words, no logos, no watermark.
■ 図4：足すのではなく、否定してから渡す（本文「4-2」の直後）ファイル名: claude-code-06-fig04-supersede-old.pngalt: 新しい方針を足すだけでは古い方針が残り、名指しで否定すると入れ替わることを示した図
Flat vector comparison diagram, 16:9, deep indigo background, split top and bottom.TOP row: a stack where a new card is placed on top of an old card — the old card is stillvisible underneath, peeking out. Dim.BOTTOM row: the old card is clearly crossed out with a line through it, and the new card sitscleanly beside it, glowing soft amber.Include Japanese text in clean gothic sans-serif:
- Beside top row: 「新しいものを足すだけ」 beneath: 「古いほうが残る」
- Beside bottom row: 「古いほうを名指しで否定してから渡す」 beneath: 「入れ替わる」
Deep indigo (#1B1C4B) base, amber (#F4A62A) on the bottom row. Text crisp.No English words, no logos, no watermark.
====================================================================–>
シリーズも最終回です。
第5回まで、インストール、使い方、コマンド、設定、拡張機能を扱ってきました。ただ、実際に使っていていちばんつまずくのは、たぶんここだと思います。
思ったとおりに動かない。
頼んだのに違うものが返ってくる。日によって出来が違う。同じことを頼んでいるつもりなのに、結果が安定しない。
自分も、しばらくはモデルの調子のせいだと思っていました。 今日は賢い、今日は雑だ、と。
でも1年ほど使ってみて分かったのは、そのばらつきの多くは、こちらの頼み方で説明がついたということでした。同じことを頼んでいるつもりで、渡している情報が毎回違っていた。
この回では、実際に効いた5つを、失敗した例と一緒に書きます。
先に5つを挙げておきます。
- 「いい感じに」と言わない
- 前提を先に渡す
- 返ってきたものを疑う
- 方針を変えるときは、古いほうを名指しで否定する
- 一度に全部を頼まない
この記事で分かること
- 指示が曖昧になっていないかの見分け方
- 何を先に渡せば結果が安定するか
- 返ってきたものを、どう確認するか
- 長く使うほど起きる「古い指示が戻ってくる」現象への対処
- 大きな依頼の分け方
1. 「いい感じに」と言わない
1-1. 最初にやめたのが、これでした
自分は以前、こう頼んでいました。
この関数を、読みやすく整理してください返ってくるものが、思っていたのと違う。それで「うまく伝わらないな」と思っていました。
でも、悪いのは相手ではありませんでした。自分の中にも、明確な基準がなかったんです。
1-2. 「読みやすい」は人によって違う
短い文が読みやすい人もいれば、多少長くても流れがつながっているほうを読みやすいと感じる人もいます。
基準が自分の頭の中にしかないものは、伝わりようがありません。
1-3. 判定できる形に言い換える
× 読みやすく整理して
○ 1つの関数が20行を超えないように分割して。
分割した関数には、何をするかが分かる名前を付けて文章を書かせるときも同じです。
× もう少し丁寧に書いて
○ 各項目に、具体例を1つずつ添えて。
専門用語が出たら、その場で一言の説明を足して1-4. これは、自分の整理でもあります
やってみると気づくのですが、判定できる形に書き直す作業は、自分が何を求めているのかを決める作業です。
「読みやすく」としか言えなかったのは、自分でも何をもって完成とするかを決めていなかったからでした。
決められないものは、相手にも決められません。 面倒ですが、ここを一度やっておくと、以降がずっと楽になります。
2. 前提を先に渡す
2-1. 渡したつもりになっている
同じ依頼でも、前提を渡すかどうかで結果がはっきり変わります。
自分がやりがちだったのは、頭の中にある前提を、渡したつもりになることでした。自分にとっては当たり前すぎて、書く必要を感じない。でも相手は、こちらの頭の中を見られません。
2-2. 3つ渡すだけで変わります
誰が使うか。何のためか。何を避けたいか。 この3つだけでも、精度が変わります。
（前提なし）
この文章を直してください
（前提あり）
この文章を直してください。
・読むのは、この分野を知らない人
・ブログに載せる、5分ほどで読める記事
・専門用語は残してよいが、初めて出てきたときに説明が要る
・堅すぎる表現は避けたい2-3. 毎回書くのが面倒なら
よく使う前提は、メモに残して貼り付けています。 毎回書き直すより、ずっと楽です。
プロジェクトで固定の前提なら、第4回で扱った CLAUDE.md に書いておくと、毎回渡さなくて済みます。
3. 返ってきたものを疑う
3-1. 見ているつもりで、承認していた
ここは、1年でいちばん痛い目を見た部分です。
自分は、返ってきたものを「見ている」つもりでした。目を通して、問題がなさそうなら次へ進む。
あるとき気づきました。やっていたのは確認ではなく、承認でした。
しかも、相手が優秀なほど、この傾向は強くなります。 それらしく、自信のある書き方で返ってくると、疑うきっかけがなくなります。
3-2. 「できているか」ではなく「合っているか」
対策は、大げさなものではありません。返ってきたものを見るとき、一つだけ自分に聞くようにしました。
「これは、合っているか」
「できているか」ではありません。形式が整っていることと、内容が正しいことは、別だからです。
3-3. 実際にあった失敗
集計をする処理を書かせて、それらしい数字が返ってきたので、そのまま使っていました。
あとで確かめたら、端の1件を数え落としていました。
エラーは出ません。それどころか、数字はずっと出ていた。ただ、その数字が正しくなかった。
落ちてくれるほうが、まだ親切です。落ちれば気づいて直します。それらしい数字は、疑うきっかけをくれません。
3-4. 特に確かめるもの
数字、固有名詞、日付、引用。 ここは、それらしい間違いがいちばん紛れ込みやすい場所です。
コードなら、「動いた」の次に「意図したとおりに動いているか」を確認します。動くことと、正しいことは別です。
4. 方針を変えるときは、古いほうを名指しで否定する
これは、長く使うほど効いてきます。
4-1. 直したはずのものが、戻ってくる
一度伝えた前提を、あとで変えたくなることがあります。「やっぱりこのやり方はやめよう」と。
そのとき自分は、新しい方針だけを伝えていました。
しばらくすると、古いほうが戻ってきます。「前はこうしていましたよね」と、やめたはずのやり方で。何度直しても、忘れた頃にまた出てくる。
4-2. 上書きしたつもりが、追記になっている
推測ですが、こう捉えると腑に落ちます。
自分は上書きしたつもりでいるが、実際には追記になっている。
新しい指示を足しても、古い指示が消えるわけではない。だから、そのときの流れによっては、古いほうが優先されてしまう。
4-3. 名指しで否定してから渡す
× これからはBの形でお願いします
○ 以前はAの形で頼んでいましたが、（理由）のためAはやめました。
これからはBの形にしてください。
Aの形が出てきたら、それは古い指示です古いほうを名指しで否定してから、新しいものを渡す。 それだけですが、戻ってくる頻度がはっきり減りました。
4-4. CLAUDE.md に残す場合
第4回でも触れましたが、削除するのではなく、廃止として残すのが効きます。
# 廃止した方針
- ~~Aのやり方~~ → 廃止（理由）。今後はBを使う。
Aが出てきたら、それは古い指示です。削除すると、手元からは消えるのに振る舞いには残ることがあります。しかも「Aはやめた」という情報まで一緒に消えるので、戻ってきたときに否定する根拠がなくなります。
5. 一度に全部を頼まない
5-1. 大きく投げると、細部が雑になる
以前は、大きな依頼を一度に投げていました。「これを全部やって」と。
すると、全体としては形になっているのに、細部が雑になる。しかも、どこがまずいのかを探すのが大変でした。塊が大きいほど、確認する範囲も大きくなります。
5-2. 方針を確認してから、中身に入る
× この資料を全部作ってください
○ まず、章立てだけ出してください
（確認して、直してから）
○ この章立てで、1章目だけ書いてください遠回りに見えますが、結局こちらのほうが早いです。方向が違っていたときに、戻る距離が短くて済みます。
一度に全部作らせて方向が違っていたら、全部やり直しになります。
5-3. プランモードを使う
第2回で扱ったプランモードが、まさにこれです。
Shift + Tab でプランモードにすると、読むだけで、変更しません。 何をするつもりかを提示させて、こちらが承認してから実行に移せます。
大きな作業ほど、プランモードから入ると事故が減ります。
6. うまくいかないときの見直し順
「思ったとおりに動かない」と感じたら、この順で見直してください。
1. 基準は判定できる形になっているか。 「いい感じに」「適切に」「きれいに」と書いていないか。
2. 前提を渡したか。 誰が使うか、何のためか、何を避けたいか。
3. 一度に頼みすぎていないか。 分ければ、どこがずれたか分かります。
4. 古い指示が残っていないか。 以前と違うことを頼んでいるなら、明示的に否定したか。
5. 会話が長くなりすぎていないか。 第3回の /context で確認して、/compact か /clear を。
6. そもそも見えているか。 起動したフォルダの外のファイルは見えません（第2回）。
多くの場合、1か2で解決します。 拡張機能を足す前に、ここを見直したほうが早いことがほとんどでした。
7. 1年やって思うこと
最後に、少しだけ感想を書かせてください。
頼み方を直す作業は、相手に合わせる作業ではありませんでした。
「いい感じに」としか言えなかったのは、自分が何を求めているか分かっていなかったから。前提を渡せなかったのは、自分の前提を言葉にしていなかったから。確認できなかったのは、何をもって正しいとするかを決めていなかったから。
全部、相手の問題ではなく、自分の側の曖昧さでした。
頼み方を直していく過程は、そのまま、自分の考えをはっきりさせていく作業だったと思います。
だからこの5つは、AIに向けたテクニックというより、人に何かを頼むときにも、たぶん同じように効きます。 ただ、AIを相手にしたほうが、曖昧さが結果に跳ね返ってくるのが速いので、学ぶには向いていました。
まとめ
- 「いい感じに」と言わない。 判定できる形に言い換える
- 判定できる形にする作業は、自分の基準を決める作業
- 前提を先に渡す。 誰が使うか、何のためか、何を避けたいか
- 固定の前提は CLAUDE.md へ。毎回書かなくて済む
- 「できているか」ではなく「合っているか」を聞く。 数字・固有名詞・日付は特に
- 方針を変えるときは、古いほうを名指しで否定してから渡す
- CLAUDE.md では、削除せず「廃止した方針」として残す
- 一度に全部頼まない。 方針を確認してから中身に入る
- 大きな作業はプランモードから
シリーズのまとめ
全6回、お読みいただきありがとうございました。
第1回 インストールと料金。 何ができるものか、いくらかかるか、どう入れるか。
第2回 基本の使い方。 どこで起動するか、ファイルの渡し方、止め方と戻し方。
第3回 コマンドと起動オプション。 用途から引ける早見表。
第4回 設定と権限。 確認を減らして、かつ安全にする方法。
第5回 MCP・Skill・Plugin。 3つの違いと、選び方。
第6回 頼み方。 思ったとおりに動かないときの見直し方。
全部を一度に覚える必要はありません。 自分の場合、最初の1か月は第1回と第2回の内容だけで足りていました。設定を詰め始めたのは、確認プロンプトが煩わしくなってからです。
困ったときに、必要な回を開いてもらえれば十分です。
※本記事の情報は2026年8月時点のものです。仕様は変更されることがあるため、最新の情報は公式ドキュメントをご確認ください。
