前回までで、Claude Code を入れて、最初の会話をして、CLAUDE.md も置けた。
でも次でけっこう止まるんですよね。で、何を頼めば仕事になるの？ で迷う。
今回はそこを埋める話です。
結論からいく
Claude Code を入れて、最初の会話までできた。
ここで次にやるべきなのは、機能を勉強することでも、全部自動化しようとすることでもない。
最初の30分でやるべきなのは、1つ成果物を出す こと。
具体的にはこの3つのどれか1つで十分。
- 長文を3行で要約する
- ぐちゃっとしたメモを箇条書きに整理する
- メールや議事メモの下書きを作る
最初に1回「ちゃんと役に立つじゃん」を作れると、そのあと何を頼めばいいかの感覚が一気に掴みやすくなります。
私も最初は「何ができるの？」を聞き続けて終わったんですが、雑メモを整理させた瞬間に「あ、これ仕事で使える」に変わりました。
最初の30分で必要なのは「理解」より「成功体験」
Claude Code を触り始めた直後って、ついこうなりがちです。
- 何ができるのか一覧で知りたい
- どこまで自動でやってくれるのか試したい
- せっかくだから大きい仕事を投げてみたい
でも、ここでいきなり大きい仕事を投げると、だいたい失敗します。
返ってくる文章はそれっぽいのに、仕事は1ミリも進んでない。最初に起きやすいのはあれです。
理由はシンプルで、まだ自分の側にも「どう頼めばいいか」の型がないから。
最初の30分は、AIの可能性を探る時間というより、頼み方の型を1個つかむ時間 にした方がうまくいきます。
30分の進め方はこれだけでいい
1. 元データを1つ用意する
最初はゼロから考えさせない方がラクです。
おすすめはこのどれか。
- 自分が読みにくい長文
- 箇条書きがぐちゃぐちゃなメモ
- 送る前のメールや議事メモのたたき台
2. 出力形式を先に決める
「要約して」だけだと、返ってくる形が毎回ブレます。
なので最初からこう決めます。
- 3行で
- 箇条書き5点で
- 丁寧すぎない文体で
- 社内向けの口調で
3. うまくいかなかったら、仕事を変えずに言い方を変える
最初の失敗で「使えない」と判断するのは早いです。
けっこう多いのが、能力不足じゃなくて前提不足。
なので、まずは仕事を変えずに、条件を足して言い換える方が当たりやすいです。
まず試すならこの3パターン
1. 長文を3行で要約する
これは一番失敗しにくいです。
たとえば、長いドキュメントや議事録メモを渡して、こう頼みます。
以下の文章を、忙しい人向けに3行で要約して。
専門用語はできるだけ減らして、
「何が決まったか」と「次に何をするか」が分かる形にして。
これのいいところは、出力の良し悪しを判断しやすいこと。
- 短すぎる
- 抽象的すぎる
- 次アクションが抜けてる
みたいなズレが見えやすいので、次の修正もやりやすいです。
うまくいかなかったら、こう言い換えます。
3行要約に加えて、
最後に「次アクション」を1行だけ別で出して。
社内共有にそのまま貼れるトーンで。
2. ぐちゃっとしたメモを箇条書きに整理する
次に相性がいいのが、頭の中にある雑メモの整理です。
たとえばこんな状態のテキスト。
- 先方に連絡
- 仕様まだ固まってない
- たぶん来週レビュー
- デザインも確認必要
- 誰が持つか決める
これをそのまま渡して、こう頼みます。
以下のメモを整理して、
「確認事項」「未決定」「次アクション」の3つに分けて箇条書きにして。
重複している内容はまとめていい。
これ、頭の中が散らかってる時にかなり効きます。
特に「自分の中では分かってるけど、他人に渡せる形になってない」情報を整えるのがうまいです。
もし返ってきた内容が薄いなら、分類軸をもっと明示します。
「現状」「困っていること」「今週やること」の3つに分けて。
箇条書きは各3件以内で、曖昧な表現はそのまま残さず言い換えて。
3. メールや議事メモの下書きを作る
これは「白紙がしんどい」時にいちばん効きます。
たとえば、頭の中にある要点だけ渡してこう頼みます。
以下の要点をもとに、
社内向けの短い共有メールの下書きを作って。
- 今日の打ち合わせでレビューは来週に延期
- デザイン確認がまだ残っている
- 実装担当は明日決める
硬すぎず、でも雑すぎない文体で。
件名案も1つつけて。
ここで大事なのは、完成品を期待しすぎない こと。
最初の目的は「そのまま送れる完璧な文」じゃなくて、白紙を前に止まる時間を消すこと です。
なので、60点でも前進です。
もし文体が違うなら、そこだけ直します。
もう少し口語寄りで。
社内チャットに貼るくらいの軽さにして。
でも要点は削らないで。
うまくいかない時は、だいたい「頼み方」が広すぎる
最初にありがちな失敗はこれです。
これいい感じに整理して
これだと、AIから見ると自由度が高すぎます。
何をもって「いい感じ」なのかが分からない。
なので、最低でもこの3つは入れた方が安定します。
- 何を渡しているのか
- どんな形で返してほしいか
- 誰向けの文か
たとえば同じ依頼でも、こっちの方がかなり通りやすいです。
以下は打ち合わせ直後の雑メモです。
社内共有向けに、
「決まったこと」「保留」「次アクション」の3つに分けて整理して。
箇条書きで、各3件以内にして。
この差だけで、返ってくる内容の使いやすさはかなり変わります。
最初の30分でやらないこと
ここはかなり大事。
最初の30分では、次みたいなことはやらなくていいです。
- いきなり大きい業務全体を任せる
- 「全部いい感じにやって」と丸投げする
- 機能を全部試して理解しようとする
- コード生成や自動化をいきなり本番運用に乗せる
最初は、小さく渡して、小さく返ってきて、小さく成功する で十分。
この感覚がつかめると、そのあとに「要約以外もいけるな」「整理だけじゃなく比較も頼めそうだな」と広げやすくなります。
30分後のゴールはこれ
この30分で目指すゴールは、すごく地味です。
- 1つ成果物が出た
- その時の頼み方が分かった
- 失敗した時の言い換え方が1個分かった
これだけで十分です。
Claude Code は、最初から完璧に使いこなすものというより、頼み方の型を少しずつ覚える道具 だと思った方がハマりにくいです。
前回で「自分仕様にする」ところまで終わったなら、今回は「最初の成果物を出す」ところまで行く。
この2段階がつながると、ようやく「便利そう」じゃなくて「実際に使える」に変わってきます。
ここまで来ると、次に必ずぶつかるのが
どこまで任せてよくて、どこからは人が持つべきか
の境界線です。
次はそこを書きます。