長い依頼ほど、最初の一文が雑だと全部がぐらつく。ここを省くと、Claude Code は賢くても状況の読み違いを起こしやすいし、あとから「その前提じゃない」と手戻りする。だから最初にやるのは、要望を盛ることではなく、前提を1行に潰すことだ。前提の一行要約、冒頭サマリー、状況の一文整理、呼び方は何でもいいが、役目は同じである。
たとえば、ファイル整理を頼むときに「このフォルダをなんとかして」では弱い。何を残すのか、何を消すのか、どこまで触っていいのかが曖昧すぎる。逆に、冒頭で前提を1行に圧縮しておくと、以降の指示が全部ぶれにくくなる。Claude Code は長文を読めるが、だからこそ最初の地図が雑だと、余計な探索にコンテキストを使ってしまう。
まずは、この形を叩き台にするといい。
前提: 目的は「案件ごとにファイルを整理し、重複や不要物を見つけること」。削除は提案までで、実行前に確認を挟む。
この1行だけで、だいぶ違う。目的、範囲、禁止事項が入っているからだ。長い依頼の冒頭でやるべきなのは、自己紹介でも長い事情説明でもない。依頼全体の「読み方」を先に渡すことだ。
実際に使うなら、依頼文の最初をこう整える。
前提: この作業は「年度ごとの書類フォルダを整理して、古い重複資料を見つける」ためのもの。削除は勝手に実行せず、候補を出したあとで止めてほしい。
やってほしいこと:
1. フォルダ構成を把握する
2. 似たファイル名や重複の候補を挙げる
3. そのまま残すもの、見直すものを分ける
4. 最後に、こちらが確認しやすい形で一覧にする
この書き方のいいところは、最初の1行が「全体の前提」、その下が「作業手順」になる点だ。順番が逆だとまずい。いきなり作業を並べると、Claude Code は細部に引っ張られて、肝心のゴールを取り違えることがある。筆者は以前、前提を後ろに回して「とにかくこのディレクトリを整理して」と投げたせいで、出力はそれっぽいのに、残したい資料の扱いがずれて手戻りした。たかが一行、されど一行だ。
この「一行に圧縮する」コツは、情報を削ることではない。むしろ、依頼の中で本当に効く要素だけ残すことにある。入れるべきなのは、だいたいこの3つだ。
ひとつ目は目的だ。何のための作業か。
ふたつ目は制約だ。削除しない、変更前に確認する、出力形式を揃える、など。
みっつ目は対象の境界だ。どのフォルダ、どの文書、どの期間、どの案件か。
逆に、前提の一行に細かい手順を詰め込みすぎると、ただの長い冒頭になる。そこは分ける。前提は「何をする場か」を決めるだけ。やり方の細部は、そのあとに渡す。
たとえば、文書作成でも同じだ。長い依頼の最初に、こう置くと安定する。
前提: これは社内向けの案内文を、読みやすく、かつ硬すぎない文体で整える依頼だ。事実関係は変えず、文章の冗長さだけ削ってほしい。
この一文があるだけで、不要な校正や過剰な言い換えをかなり防げる。Claude Code は雑に頼むと、親切心でやりすぎることがある。表現を整えるつもりが、意味まで薄まる、というやつだ。前提を先に固定しておけば、そういう暴れ方を抑えやすい。
ただし、前提の一行要約には落とし穴もある。短くすること自体が目的になると、中身が抜ける。たとえば「整理してください」だけに圧縮したら、それはもはや前提ではない。大事なのは、短いのに判断材料が残っていることだ。迷ったら、次の形に落とすといい。
前提: 目的はX、対象はY、やってよいのはAまで、Bは確認なしで触らない。
この型はかなり強い。長い依頼でも、冒頭にこれがあるだけで、後続の指示が読みやすくなる。しかも、あとで見返したときに「自分は何を頼んだのか」がすぐ分かる。依頼文は相手のためだけでなく、自分のためのメモでもあるからだ。
応用すると、前提の一行要約は「毎回書く定型文」にしておくと便利だ。案件整理、ファイル整理、文章校正、仕様確認、どれでも使える。中身は少しずつ変えてもいいが、冒頭で状況を一文で整理する癖だけは残す。長い依頼の成功率が上がるし、手戻りの回数が目に見えて減る。
最後に、やってはいけないことを一つだけはっきり言う。前提を長文の中に埋もれさせるな。見出しより下に置いたり、説明の途中でぼかしたりすると、せっかくの効果が消える。冒頭に置くから効く。1行に潰すから効く。これだけは外さない方がいい。