Borisが語るClaude Codeへの依頼方法｜目的・労力・検証の3点

「普通に話す」の意味を、雑に頼むことと取り違えない

Borisは、同僚に頼むようにClaudeへ話せばよいと述べています。多くの仕事では、細かな手順や形式を過剰に指定する必要はなく、目標を渡すことが大事だ、という趣旨です。

ここで見落としたくないのは「多くの仕事では」という範囲です。すべての仕事に計画が不要だとも、プロンプトは何を書いても同じだとも言っていません。Sonnet 3.5の頃との比較も、本人の使い方についての説明であり、あらゆる業務で差が出なくなったことを証明する実験結果ではありません。元投稿

たとえば、同僚へ「この資料、いい感じにして」とだけ頼めば、認識はずれます。経営会議で判断に使う資料なのか、新入社員に説明する資料なのかで、残す数字も説明の細かさも変わるからです。

一方、「この段落を15文字短くして、次にこの図を右へ動かして、最後に余白を調整して」と手順だけを並べても、読み手が判断できる資料になるとは限りません。作業の指示は具体的でも、仕事の目的は伝わっていない状態です。

そこで依頼の順番を変えます。最初に、誰が何をできる状態にしたいのかを伝える。そのうえで、必要な背景と守る条件を添える。方法を選ぶ余地を残しつつ、完成したと判断できる基準は曖昧にしない。この役割分担なら、人間が一手ずつ操作を指図する負担を減らせます。

Claude Codeの公式ガイドも、目的を確かめるテストや画面比較を渡すこと、具体的な文脈を示すことを勧めています。小さく明確な修正は直接頼み、不確実な変更では調査と計画を挟む、という使い分けです。公式ベストプラクティス

目標は「何を作るか」から、使う場面まで書く

目標を伝えるときに便利なのが、「誰が」「何をしたとき」「どうなればよいか」の3点です。特別な書式にする必要はありません。自然な文章の中で、この3つが読めれば十分です。

「検索機能を改善して」だけでは、検索を速くしたいのか、目的に合う結果を出したいのか、画面を見やすくしたいのかが分かりません。まず次のように、困っている場面を言葉にします。

「営業担当が会社名の一部を入力したとき、目的の顧客を一覧から選べるようにしたい。今は正式名称と完全一致しないと見つからない。同じ会社の表記違いは候補に出しつつ、別会社を同一扱いにはしないでほしい」

これなら、何のために変えるのかが伝わります。実装方法を先に決めなくても、候補の表示、検索の仕組み、表記の扱いを検討する方向が定まります。

ただし、この文章だけで「別会社」の判定基準まで確定したわけではありません。判断できない例があれば、実データを加工したサンプルで確かめる必要があります。略称をどこまで許すのか、住所が違う支店を同じ会社として扱うのか。こうした業務上の決定は、コードを読むだけでは埋まらないことがあります。

依頼する側が渡すべきなのは、AIが調べれば分かるファイルの全説明より、関係者だけが知っている事情です。「今週の営業会議で使う」「利用者はキーボード操作が中心」「既存のCSV出力との互換性が必要」といった背景は、見た目以上に実装の判断を左右します。

逆に、正確には分かっていない原因を決めつけるのは避けたいところです。「キャッシュが壊れているから直して」より、「更新しても古い値が出る。キャッシュの影響は仮説なので、保存処理と取得処理を含めて原因を確認して」と渡すほうが、誤った前提に仕事を縛りません。

目標がよく書けているか迷ったら、完成物の名前を隠して読んでみてください。それでも、誰の何が楽になるか分かるなら、仕事の目的まで伝わっています。

労力は「全力で」だけでなく、何に使うかを伝える

「時間をかけていいので、品質を優先して」。これは大切な意向ですが、これだけでは調査を増やすのか、見た目を磨くのか、例外を確認するのかが決まりません。使ってよい時間と、使うべき時間の配分は別の話です。

たとえば、社内で1回だけ使う小さなスクリプトなら、理解しやすさを優先し、将来の拡張に備えた大きな設計までは求めない判断があります。一方、毎日売上を集計する処理なら、欠損、重複、日付の区切り、再実行時の扱いまで詰める価値が高くなります。

同じ「集計して」でも、使い道によって力の入れどころを変えるわけです。

依頼文では、たとえばこう補えます。

「まず既存の処理と入力データを確認して、今回の数字がずれる理由を絞ってください。見た目の整形より、集計条件と例外の確認を優先します。修正に関係のない大規模な設計変更は今回の対象に含めません」

この文では、品質を下げずに作業の広がりを抑えています。原因が分かる前に画面を整えることも、単発の依頼を大きな作り直しへ広げることも、目的にはつながりにくいからです。

また、「十分に考えて」は特定の設定値を変更する命令と同じではありません。自然言語で伝える作業方針と、利用環境のモデル設定、使えるツール、実行時間の制約は別々に確認する必要があります。言葉を強くするだけで、使えない環境が使えるようになるわけではありません。

途中で費用や時間の見積もりが大きく変わりそうなら、そこで判断材料を出すように頼みます。「ここまでに何が分かり、次の調査で何を確かめ、どれぐらい追加の作業が必要か」を説明してもらえば、続けるかどうかを理由に基づいて決められます。

質を優先する依頼ほど、何でも増やすより、誤ると困るところへ時間を使うことが大事です。

検証は「確認して」で終わらせず、合否が分かる形にする

検証を頼むときは、どの結果を見れば成功と判断できるかを考えます。仕事そのものから返ってくる結果が分かれば、説明文が読みやすく自信に満ちていても、実際の出来を確かめられるからです。

たとえば、画面を作る仕事なら、コードを書けたことと、画面に表示できたことは別です。さらに、表示できたことと、利用者が目的の操作を最後まで行えたことも分かれます。

検索窓の見た目ができても、入力して結果が出なければ使えません。結果が出ても、項目を選んだときに別の顧客が開けば問題は残っています。「検索機能を実装しました」という一文だけでは、この違いが見えません。

そこで、完了報告に次の内容を含めてもらいます。

・何を実行して確かめたか。 ・入力や操作に対し、どんな結果が返ったか。 ・どの条件は確認できていないか。 ・確認できない理由は、環境、権限、データ不足のどれか。

この4つがあれば、報告を読んだ人が追加で確認すべき範囲を判断できます。テストに失敗したことを隠さず、失敗した条件が読めるだけでも、次の行動はかなり明確になります。

ここで、AIが都合よく通せる基準を作らないことも大切です。出力ファイルが存在するだけで合格にすると、中身が空でも通ってしまう。処理中のエラーを無視し、正常に終わったと報告するだけでは、利用者の問題は解消されません。

検証条件は、依頼時の困りごとへ戻して書きます。「保存ボタンを押すと、再読み込み後にも編集内容が残っている」。このように観察できる結果があれば、コードの書き方が変わっても合否を確かめられます。

完璧な判定を最初から用意する必要はありません。まず、今回もっとも困っている現象が直ったことを確かめる方法を1つ作る。次に、その修正で壊れやすい隣の動作を確認する。この順番なら、検査だけが際限なく増えるのを避けられます。

バグ修正：原因の仮説と、直った証拠を分ける

ここからは、3つの考え方を依頼文へ落とし込みます。最初は、管理画面で編集内容が保存されないケースです。以下は説明用に作った架空の状況です。

「顧客メモを編集して保存すると、その場では更新されます。ただしページを再読み込みすると元の文章に戻ります。長い文章のときに起きたという報告がありますが、長さが原因かは未確認です。

通常の編集操作で、保存後に再読み込みしても内容が残るようにしてください。まず再現条件と保存の流れを調べ、原因が分かってから必要な範囲を直してください。今回関係する保存処理の確認を優先し、画面全体の作り直しは対象外です。

修正前に問題を再現できたかを記録し、修正後に同じ条件で再確認してください。短い文章、改行を含む文章、日本語を含む文章も確認し、実施した内容と結果を示してください。再現や確認に必要な環境へ接続できない場合は、その時点で分かっている範囲を報告してください」

目標は、再読み込み後にも編集内容が残ること。労力を使う先は、再現条件と保存経路の調査。検証は、同じ条件で修正前後を確かめることです。

この依頼で、最初から「入力欄の文字数制限を外して」と指示していない点が大事です。長文で起きるという報告が正しくても、画面、通信、保存先、表示時の処理のどこで壊れているかは別に調べる必要があります。仮説を1つに固定すると、別の場所にある原因を見落としかねません。

さらに、保存に失敗したら画面上で成功したように見せないことも検討対象になります。通信に失敗したケースまで確認できるなら、入力内容が失われないか、利用者へ失敗が伝わるかを見る。この確認は、正常に保存できるケースとは分けて記録します。

修正後の報告が「保存できました」だけなら、まだ質問が残ります。どの文章で、どの画面で、何回目の保存を確かめたのか。反対に「検証環境で、改行を含む日本語のメモを保存し、再読み込み後に一致を確認した。本番環境は未確認」と書かれていれば、証明できた範囲が読めます。

これは報告を長くするための作法ではありません。自分が再確認する場所を、根拠を持って絞るためのものです。

画面改善：「見やすい」を、迷わず操作できる状態へ変える

次は管理画面の改善です。「かっこよくして」「今っぽくして」だけでは、見た目の好みと使いやすさが混ざります。何を改善したいかを、操作する人の場面に落とします。

「問い合わせ一覧で、担当者が未対応の項目を見つけ、詳細を開き、担当者を割り当てられるようにしたいです。今は対応済みと未対応の見分けがつきにくく、項目を開かないと状態が分かりません。

既存の色と文字の雰囲気を引き継ぎながら、状態と次に押すボタンが分かるように整えてください。装飾を増やすより、一覧での判断と操作を優先します。文言や項目の順番を変える場合は、その理由が説明できる形にしてください。

通常の一覧に加え、0件、長い問い合わせ名、担当者未設定の状態を確認してください。パソコンと幅の狭い画面で、文字の重なりや横にはみ出す部分がないかを画像で確かめてください。担当者の割り当て後に表示へ反映されるところまで確認し、見た目と操作の確認結果を分けて報告してください」

この場合、目標は「未対応の問い合わせを見つけて割り当てる」ことです。色や余白の調整は、その目標を助けるための手段になります。

見た目を確かめるだけだと、通常データが数件入った画面で十分だと思いがちです。しかし、実務では項目名が長いことも、結果が0件になることもあります。きれいなスクリーンショット1枚に合う設計が、これらの条件でも読みやすいとは限りません。

確認する画面幅を決めるときも、数字を並べれば安心というわけではありません。利用者が主に使う端末と、崩れやすい境目を選びます。スマートフォンの幅で表示しただけなら、その幅での確認です。実際の端末で押しやすさまで確かめた場合とは分けて扱います。

操作の確認も、ボタンを押せるか、保存の通信が成功するか、再読み込み後も担当者が残るかに分けます。保存処理を変更しない場合でも、画面の変更が既存の操作を妨げていないかは確認が必要です。

「もっとおしゃれに」という修正を繰り返す前に、利用者が迷う場面を1つ挙げる。すると、改善案を好みだけで採点せず、目的に近づいたかで判断しやすくなります。

毎回伝えることと、仕事ごとに伝えることを分ける

ここまでの例を全部毎回貼り付ける必要はありません。むしろ、いつも同じ前提を繰り返しているなら、共通の説明をまとめるほうが扱いやすくなります。

Claude Codeには、継続して伝えたい指示を書くCLAUDE.mdがあります。公式資料では、人が書く指示と、Claudeが記録する自動メモリが区別されています。また、どちらも文脈として参照するもので、操作を強制的に禁止する設定そのものではありません。公式のメモリ説明

この仕組みを使うなら、共通の指示には、毎回変わらない事情を置きます。たとえば「どのコマンドで動作確認するか」「生成物ではなく元ファイルを修正するか」「このプロジェクトでは日付をどの地域の時刻で扱うか」といった項目です。

一方、「今週の調査対象」「今回直す画面」「今日の締め切り」は仕事ごとの依頼へ置きます。期限の過ぎた指示が共通ファイルに残ると、次の依頼を邪魔する可能性があるためです。

共通ファイルを充実させるときも、失敗するたびに説明を追記するだけでは、似た指示や矛盾する指示が増えてしまいます。「前回は何を取り違えたのか」「今回も必要な前提か」を考え、短い規則へ直すほうが再利用しやすくなります。

たとえば「もっとちゃんと確かめて」という曖昧な指示を、「画面の保存操作を変えた場合は、再読み込み後の値まで確認する」へ書き換える。具体的な失敗から、別の仕事にも使える確認方法を取り出すわけです。

ただし、パスワードや秘密の値を、便利だからという理由で共通の説明に並べる必要はありません。必要なのは、認証情報の管理方法や正規の利用手順です。指示を充実させることと、秘密をたくさん渡すことは別です。

任せる範囲は、プロンプトと権限の両方で決める

目標を渡して進めてもらう場合でも、閲覧、編集、公開などをどこまで許可するかは決めておきたいところです。

Claude Codeの公式資料では、プロンプトやCLAUDE.mdが行動の意図を伝える一方、実際のツール利用の可否は権限の仕組みが制御すると説明されています。文章で「触らないで」と書くことと、アクセスを設定で制限することは役割が異なります。公式の権限設定

たとえば記事制作なら、情報を読み、原稿を作り、校正するところまで任せる運用があります。公開を人が確認する運用なら、その境目を依頼にも実行環境にも反映させます。コード修正では、作業用環境での検証と、利用者がいる本番環境への反映は別の段階です。

このとき「何かあったら聞いて」だけでは、人によって重要さの基準が変わります。「集計ルールが未確定なら確認する」「外部へ公開する操作の前で止める」など、判断を戻す条件を具体的にします。

任せる範囲がはっきりしていると、その範囲の中では細かな作業ごとの確認を減らしやすくなります。「何を決めてよいか分からない」という理由で、調査の途中に何度も立ち止まることを避けるためです。

次の依頼では、完成条件を1文足してみる

ここまで読んで、毎回こんな長い依頼文を書かなければならないのか、と感じたかもしれません。実際には、仕事が小さく、前提を共有できていれば、もっと短く始められます。

「この一覧の誤字を直し、同じ表記がほかにもないか確認してください。変更した箇所が分かる形で報告してください」

この程度でも、目的、必要な広がり、確認してほしいことが読めます。単純な修正に、調査計画から大きなテスト一式まで付ける必要はありません。

反対に、影響が大きく曖昧な仕事なら、初めに調べてもらう段階を設けます。「まず既存の仕組みと困っている条件を整理し、判断が必要な点を出してください」と依頼すれば、その結果を見て実装の範囲を決められます。

そして、ずれが起きたら、失敗した出力だけを直して終わらせず、何が伝わっていなかったかを振り返ります。目標を取り違えたのか。必要な調査を省いたのか。完了の基準が甘かったのか。この3つに分けると、次の依頼で足すべき説明が見えます。

毎回プロンプト全体を書き直すより、「保存したあとに再読み込みして確かめる」「公式の発表日と記事の日付を分ける」といった具体的な一文を足すほうが、修正の理由も残ります。

次にClaude Codeへ仕事を頼むときは、まず最後にこう添えてみてください。

「何を確認できたら完了と判断するかを決め、その確認結果を示してください。確認できなかった部分は、できた部分と分けて報告してください」

そのうえで、もっとも大切な確認条件を自分でも1つ渡す。バグなら再現した操作、画面なら利用者が終えたい操作、記事なら出典、集計なら数字の定義です。

AIに仕事を任せるとき、人間が持っておきたいのは、すべての手順を知っていることより、何のための仕事で、どこを確かめたいかという判断です。そこが言葉になると、依頼も、修正のやりとりも、完成したものの評価も具体的になります。

この記事が参考になった方は、Claude Code Studio @ Japan（@ClaudeCode_love）へ。Claude Codeの更新や使い方を、一次情報と実務の視点から整理してお届けします。

短く始める記入例です。長い依頼文が必要とは限りません。次の3行を今回の仕事へ置き換え、結果を判断できる条件だけ残します。

目的：顧客メモを保存し、再読み込みしても同じ文章が残る。
調査：再現条件と保存経路を調べる。画面全体の作り直しは含めない。
検証：同じ日本語・改行入りメモで修正前後を比較する。接続できない環境は未確認と報告する。

報告も「直った」だけで終えず、「検証用画面で保存後の一致を確認。本番には接続できず未確認」のように、確認した場所と残る作業を分けます。この文は報告の書式例で、実際の修正結果ではありません。

3項目を、完成条件へ落とし込む

完了報告で受け取るもの

よくある質問

短い依頼なら何でもよいですか？

必要な前提や完成条件は省きません。手順の細かさは仕事に合わせて選びます。

まとめ

次の依頼で、目的・労力・確認方法の3点を使ってみてください。完了後は、依頼文と実際の確認結果を比べ、伝わらなかった条件だけを次回の依頼へ反映します。