AIに何かを頼むとき、最初から作り方まで指示すると、AIが知っているもっと良いやり方を引き出せません。いまは「実現したいこと」だけを伝え、分からないところはAIに質問させてから進めてもらっています。この記事では、このブログの改善を Claude Code（文章で頼むと、ファイルを読んだり直したりして作業してくれるAIの道具）に頼んだときのやり取りを例に、その頼み方を紹介します。
困っていたこと
AIに頼むときの困りごとは、大きく2つありました。
1つ目は、作り方を自分で決めて指示してしまうことです。私はプログラミングが得意ではありません。その私が「こう作って」と手段まで決めると、AIはその手段の中で動きます。もっと良いやり方があっても、そこにはたどり着きません。
2つ目は、AIが推測で進めてしまうことです。こちらの説明が足りない部分を、AIはそれらしく埋めて先へ進みます。できあがったものを見て「そういう意味ではなかった」と気づくと、やり直しになります。
この記事を書くにあたって、Claude Code から私に質問してもらい、答えを記録しました（ここでは「聞き取り」と呼びます）。作り方ではなく実現したいことを伝えるようになった理由を聞かれたとき、私はこう答えました。
最初から作り方を指示してしまうと、本当はもっといいやり方をAIは知っているのに、引き出せないことになるので、自分が実現したいことを言って、手段はAIに考えてもらうようにして選別してる
手段を考えるのはAIの仕事にして、私は出てきた案から選ぶ（選別する）側に回る、という分担です。
最初の頼み方
例として、このブログ（きりはすの開発ノート）の記事づくりを見直したときの頼み方を紹介します。このブログの記事は、私の開発の記録から作った「素材」（記事の材料をまとめたメモ）をもとに、Claude Code が下書きしています。指示文の中の「kirihasu-devlog」は、このブログのことです。
当時の記事には、2つの不満がありました。記事に画像が入っていないこと。そして、内容が「何を作ったか」の報告になっていて、AIをどう使ったかのノウハウが無いことです。そこで、Claude Code に次のように頼みました。
kirihasu-devlogの改善して 今は記事に画像が入ってなかったり、内容が何を作ったかで、どうAIを活用しているかのノウハウの部分がない 例えば、指示の仕方だったり、実現したことから伝えて、精度を高めるために追加で質問させるとか、私が使う中でどう試行錯誤しているのかを伝えたい
この指示には、どのファイルをどう直すか、といった作り方は1つも入っていません。書いたのは次の3つだけです。
- いまの状態（画像が無い、作ったものの話ばかり）
- そのどこに困っているか（AIの使い方のノウハウが無い）
- どうなってほしいか（私の試行錯誤を伝えたい）
どこを直せば良いかは、記事を作るプログラムや設定のファイルを読めるAIのほうが細かく調べられます。だから私は、実現したいことと、その例だけを渡しました。
AIに聞き返させたこと
この最初の指示には「質問して」とは書いていません。それでも Claude Code はすぐに直し始めませんでした。先に、記事を作る仕組み、公開中の11本の記事、記事の素材の元になっているタスク台帳（私の作業を1件ずつ記録している表）を読みました。そのうえで、原因は「素材に頼み方が記録されていない」ことだと示しました。
そして作業を始める前に、私にしか決められないことを3つ、選択肢を付けて質問してきました。1つ目は画像の入れ方です。
記事の画像はどう入れますか？（9/11に「画像は使わない」と決めていたものを変更します）
私が選んだ答えは次のとおりです。
AIにアップロードを許可
「アップロードを許可」は、AIが画像をブログへ送れるようにする、という意味です。以前、私は「画像は使わない」と決めていました。Claude Code は、その決定を変えることになると質問の中で断っています。過去の決定を、AIが勝手に上書きしなかったわけです。
2つ目は、頼み方の素材をどこから取るかでした。
「どうAIに頼んだか・どう試行錯誤したか」の素材は、どこから取りますか？（複数可）
AIが質問して私が答える、AIとの会話ログ、AIのルール作りの変遷、台帳のメモの本人の言葉
3つ目は、記事の中身の比重でした。
記事の中身の比重はどうしますか？
全記事を頼み方中心に
選択肢の文は、Claude Code が書いたものです。私はその中から選んだだけです。それでも、「どこまで変えるか」「何を材料にするか」という方針は、私が決めた形になりました。この記事も、2つ目の答えにある「AIが質問して私が答える」聞き取りをもとに書いています。
この流れを図にすると、次のようになります。
flowchart LR A["実現したいことを伝える"] --> B["AIが仕組みを調べる"] B --> C["AIが質問する"] C --> D["私が選んで答える"] D --> E["AIが進める"] E -- "迷う点が出たら" --> C
AIが推測で進めてしまうところ
今回は Claude Code が自分から質問してくれました。ただ、いつもそうとは限りません。AIには、分からないところを推測で埋めて進めるくせがあります。
私がAIに追加で質問させるようにした理由を、聞き取りではこう答えています。
AIは推測で進めるので、推測で進めないように追加質問させてもらうと精度があがった
AIは、指示に書かれていないところを、もっともらしい推測で埋めます。たとえば今回なら「画像は使わない」という以前の決定を守るのか、変えるのか。これは私にしか決められません。AIが推測でどちらかに決めて進めていたら、あとで直すことになったかもしれません。
そこで私は、AIに質問させたいときに使う、決まった言い方を持っています。
分からないことがあれば推測で進めずに私に質問してクリアにしてから進めるようにしてください
ポイントは「推測で進めずに」と、AIのくせをはっきり止めていることです。「質問してもいいよ」と許すだけでなく、推測するくらいなら聞いてほしい、と頼んでいます。
Claude Code の公式の使い方ガイド（Best practices）にも、「Claude は意図を推測できるが、心を読むことはできない」という趣旨の説明があります。大きな機能を作るときは、先に Claude から質問させて、技術的なことや見落としがちな点を聞き出す方法も紹介されています（参考にした資料を参照）。
どう確かめ、どう判断したか
Claude Code は、質問の前に調べた結果と原因（素材に頼み方が記録されていない）を示していました。原因が先に分かると、聞かれている3つがその原因に合った質問かどうかを、こちらで見ることができます。
もう1つ見たのは、質問の数です。Claude Code の質問は3つだけでした。プログラムの直し方や、直したものが正しく動くかを確かめるテスト、説明の文書の直し方は、私に確認せずに進めています。質問を3つに絞ったのは Claude Code の判断で、私が数を指定したわけではありません。
ここが、質問させる頼み方で大事なところだと考えています。私が決めたいのは方針です。コードの書き方は、私が聞かれても判断できません。AIが「本人にしか決められないこと」と「自分で決めてよいこと」を分けて聞いてくれたので、私は3つの選択肢を選ぶだけで済みました。
判断の分かれ目は、次のように整理できます。
- 私の好みや、以前の決定にかかわること → AIに質問させて、私が選ぶ
- 作り方や、AIのほうが詳しいこと → AIに任せる
できたもの
3つの答えをもとに、このブログの記事づくりの方針が変わりました。
- 記事には、アイキャッチ（記事の先頭に出る看板の画像）と、余計なものが写っていないか確かめてから素材に入れた画面の画像を入れる。
- 頼み方の素材は、聞き取り、会話ログ、ルールの変遷、台帳のメモの本人の言葉から取る。
- すべての記事を、頼み方を中心に書く。
質問は3つ、私がしたのは選択肢を選ぶことだけでした。それで、方針の分かれ目を私が決め、残りの作業をAIに任せることができました。
次に同じことを頼むなら
今回の頼み方を、ほかの作りたいものにも使える形にまとめました。〇〇や△△は、自分の場合に置き換えてください。
〇〇を改善したい。
今は△△になっていて、□□が足りないのが困っている。
最終的には、◇◇できるようにしたい。
作り方は任せます。まず今の状態を調べて、原因を教えてください。
分からないことがあれば推測で進めずに、私にしか決められないことだけを選択肢付きで質問してください。
最初の3行で、いまの状態・困っていること・実現したいことを伝えます。作り方は書きません。最後の2行で、推測で進めないこと、聞くのは本人にしか決められないことだけにすることを頼みます。選択肢を付けてもらうと、答えるのが楽になります。
まとめ
- 作り方ではなく、いまの状態・困っていること・実現したいことを伝える。手段はAIに考えてもらい、自分は選ぶ側に回る。
- 「推測で進めずに質問して」と、AIのくせをはっきり止める一言を入れる。
- 質問は「本人にしか決められないこと」に絞ってもらい、作り方の細部はAIに任せる。
次にAIへ頼むときは、送る前に、作り方ではなく実現したいことが書けているかを見直してみてください。
参考にした資料
この記事は、筆者の開発記録をもとにAI（Claude）が下書きし、筆者が確認して公開しています。
