3-1 Claude Code 初指示｜最初に覚えるプロンプト 5 型

このレッスンで身につくこと

第 3 章のスタート地点である本レッスンは、Claude Code に最初の指示を出す最初の 30 分 を扱います。インストールを終えてターミナルを開いた直後、「で、何を打てばいいんだっけ？」となる瞬間がほぼ全員に訪れます。そこで止まる人と、最初の 1 時間で 10 個のファイルを作れる人の差は、指示の出し方を 5 パターン知っているかどうか で決まります。

所要時間 — 約 30 分（実機で 1 つずつ試すなら 60 分） 難易度 — ★☆☆☆☆（前提知識ゼロでも OK。第 2 章のインストールが終わっていれば即着手できる）

はじめに — 「最初の 1 個」が一番怖い

Claude Code をインストールして、ターミナルに claude と打って、> のプロンプトが出てきた瞬間 — ほぼ全員がフリーズします。

「何を打てばいいんだっけ？」「いきなり業務のあれを頼んだら壊れない？」「英語じゃないとダメ？」「変なことを書いたら API 料金が爆発する？」 — そんな小さな迷いが 10 個ほど積み重なって、結局その日は何も打たずに閉じてしまう。これが Claude Code の 最大の挫折ポイント です。

このレッスンの真の目的は、その「最初の 1 行」を投げ込ませること です。テクニックや料金体系の話は後回しでも構いません。とにかく、==読んでいる最中にもう 1 回ターミナルに戻って、> の右に何か打ってください。指示は 1 行で構いません。「hello.txt を作って」でも、「このフォルダにあるファイルを一覧表示して==」でも、何でもよい。

ここから先は、「最初の 30 分」を最大化するための 5 つの基本パターン を紹介します。それぞれが独立した「型」なので、好きな順番で読み飛ばしても構いません。

なぜ「いきなり大きい指示」がダメなのか

5 つのパターンに入る前に、ひとつだけ 絶対に避けてほしい失敗パターン の話をします。それは 「いきなり大きい指示を出してしまう」 ことです。

具体例で見てみましょう。

> 当社の業務管理システムを作って。
> 勤怠・経費・有給申請・契約管理・顧客管理・売上分析が全部入っていて、
> モバイル対応で、Slack 通知も入っていて、Google カレンダーと連携して、
> 月末には自動でレポートが PDF で出てくるやつ。

これ、たぶんあなたの頭の中の「Claude Code でやってみたい仕事」に近いはずです。でも、初日にこれを投げてはいけません。理由は 3 つあります。

理由 1 — 指示の解像度が結果の解像度になる

Claude Code は 指示が曖昧なら結果も曖昧 になります。「業務管理システム」と言われても、画面は何枚？データは MySQL？SQLite？認証は？権限は？ — 100 の問いが Claude の頭の中で発生します。

そのまま走らせると、Claude は デフォルト判断の連続 で「それっぽい何か」を作ります。出来上がったものを見て「これじゃない」と言うと、修正に 1 時間かかる。最初の解像度の低さが、最後まで雪だるま式に膨らみます。

理由 2 — どこで間違えたか分からなくなる

大きい指示を出すと、Claude は途中で たくさんの判断 をします。データベース選び、フォルダ構成、ライブラリ選び、命名規則、認証方式、UI フレームワーク、ファイル分割 — どれか 1 つ間違えただけで、最終物が崩れます。

そして どこで間違えたかが追跡できなくなる。「全部やり直す」しかなくなり、結果として 30 分かけて学べたはずのことを 30 分かけてやり直す ことになります。

理由 3 — トークンコストが跳ね上がる

第 1 章で触れたとおり、Claude Code は トークン量に応じて課金 されます。大きい指示は、1 回の応答が長く・往復が多くなりがち で、1 セッションで $5 を超えることも珍しくありません。

小さい指示を 10 個積み重ねるほうが、合計コストは半分以下になることが多い です。これは「コード生成」というタスクの性質によるもので、長い文脈を保ったまま全体を作るより、短い指示で部品を作って組み立てるほうが、圧倒的にトークン効率が良いからです。

ここからは、その「小さい指示」を 5 つのパターン に分けて紹介します。

基本パターン 1 — 「○○を作って」型

最初に覚えるパターンは、「○○を作って」 です。これが Claude Code の 80% を占めるくらいの基本動詞。ファイル作成・テンプレ作成・サンプル生成、ぜんぶこの型です。

形

> {何を} を作って。
> {細かい仕様: 名前・項目・形式・サイズ など}

例 1 — hello.txt

最初の 1 行はこれで OK。

> hello.txt を作って。中身は「Claude Code を触り始めました 2026-05-19」

Claude Code は「ファイルを書き込みますか？」と確認してきます。==y でファイル作成 。これだけで、あなたは Claude Code に最初の指示を出した人類== に分類されます。

「これ何の意味があるの？」 と思うかもしれません。意味は、Claude Code が確認プロンプトを出す体験を一度経験すること です。あの (y/n) を 1 回見ておけば、次から「勝手にディスクが書き換わるかも」という不安が消えます。

例 2 — index.html

次は HTML を 1 枚。

> index.html を作って。
> 「こんにちは、Claude Code」と表示する H1 タグだけのシンプルなページ。
> 日本語が文字化けしないよう charset=utf-8 を入れて。

出来上がったファイルをダブルクリックして、ブラウザで開いてみてください。「あ、ちゃんと表示される」という感覚を 1 度味わうことが大事です。

例 3 — sample.csv

サンプルデータも 1 行で作れます。

> sample.csv を作って。列は「日付, 商品, 金額」。
> 2026-05-01〜2026-05-10 の 10 行分、それっぽいダミーデータ。
> 金額は 500〜5000 円の範囲でばらつかせて。

後のパターンで「読み込む」「集計する」「グラフ化する」と段階的に深めていけます。サンプル CSV は 練習素材として最強 なので、最初に 1 個作っておくのを習慣にしましょう。

例 4 — README.md

ドキュメントもこのパターン。

> README.md を作って。
> プロジェクト名は「claudecode-practice」、
> 目的は「Claude Code を 30 日で習熟する」、
> セクションは「概要・進め方・成果・参考」の 4 つ。
> 各セクションは見出し + 2-3 行の本文をプレースホルダで。

プレースホルダで というのが地味な技。「ここは後で書く」を Claude にやらせて、箱だけ用意 してもらうと、自分の頭が整理されます。

「作って」型のコツ — 「何を／どんな形で／何を含めて」

「作って」型の指示は、次の 3 つを最低限入れると 結果が安定 します。

基本パターン 2 — 「○○を読んで要約」型

次のパターンは 「○○を読んで要約」 です。Claude Code は、自分のディスクにあるファイルを 自由に読める ので、長いドキュメントを要約させるのが圧倒的に速いです。

形

> {ファイル名 / フォルダ} を読んで、{何を / どう要約 / 何形式で} 出して。

例 1 — README を要約

> README.md を読んで、3 行で要約して。

たった 1 行 ですが、これだけでも実用的。長い README を毎回読み直すコストが、3 行に圧縮されます。

例 2 — フォルダ全体の俯瞰

> このフォルダの中身を再帰的に見て、何のプロジェクトか 5 行で説明して。

新しい職場の引き継ぎフォルダを渡されたとき、これが 入口の地図 になります。==ls -R を眺めても分からなかったプロジェクトが、5 行の自然文で見えてくる==。

例 3 — エラーログを読ませる

> error.log を読んで、頻発しているエラーパターンを 3 つに分類して。
> それぞれの発生回数と、推定原因も書いて。

1000 行のログを目で追う仕事を 10 秒に圧縮 できます。Claude Code が「分類して」「カウントして」をやってくれるので、人間は 推定原因の検証 に集中できます。

例 4 — 議事録から TODO 抽出

> meeting-2026-05-18.txt を読んで、TODO 項目だけを抽出して。
> 形式: 「- [ ] 担当者: TODO 内容 (期限)」
> 担当者・期限が明示されていないものは「(要確認)」と書く。

これも実務で頻繁に使うパターン。議事録の生テキストを渡すだけで、アクションリストの草稿が 30 秒で出てきます。

「読んで要約」型のコツ — 「何形式で・何文字で・何を残すか」

「読んで」型の指示は、出力形式を明示 すると安定します。

基本パターン 3 — 「○○を実行して結果報告」型

3 つ目のパターンは 「○○を実行して結果報告」 です。Claude Code は シェルコマンドを自分で実行 できるので、「動かしてみてどうだったか」までを 1 セットで頼めます。

形

> {コマンド / スクリプト / テスト} を実行して、結果を {要約 / 評価 / 整形} して。

例 1 — シンプルにコマンドを叩く

> このフォルダで `du -sh *` を実行して、サイズが大きい順に並び替えて。

これだけで、どのフォルダが容量を食っているか が一目瞭然。==自分で du のオプションを思い出さなくていい== のが地味に楽です。

例 2 — Python スクリプトを書いて実行

> sample.csv を読み込んで、金額列の合計を計算する Python スクリプトを書いて、
> そのまま実行して結果を教えて。

Claude Code は スクリプトを書く → 実行する → 結果を報告 までを 1 ターンでやってくれます。「書いて終わり」じゃなく、「結果まで含めて報告」 というのがこのパターンの肝。

例 3 — テストを動かす

> `npm test` を実行して、失敗したテストだけを抽出して。
> 失敗の原因が「同じパターン」のものはまとめて分類して。

CI の失敗ログを目で追う地獄 から解放されます。「同じ原因で 30 件落ちている」のような分類を、Claude が自動でやってくれます。

例 4 — 結果に応じて次のアクションも頼む

> `git status` を実行して、未コミットの変更があれば内容を 3 行で要約して。
> 変更がなければ「クリーン」と答えて。

条件分岐を含めた指示 も自然に通ります。1 つのコマンドで「状態確認 + 要約」を済ませる 流儀に慣れると、定型作業がほぼゼロ秒で片付きます。

「実行して」型のコツ — 「実行 + 観察 + 報告」を 1 セットで

「実行して」型の指示は、実行・観察・報告 の 3 ステップを 1 つの指示にまとめると効果が最大化します。

基本パターン 4 — 「複数の○○を一括処理」型

4 つ目は 「複数の○○を一括処理」 です。Claude Code の真価が出るパターン。同じ作業を 100 回繰り返す ような仕事を、1 行の指示で終わらせます。

形

> {対象のパターン} を全部対象に、{処理} を一括で実行して。

例 1 — 100 個のファイル名を一括変換

> このフォルダにある photo-*.JPG を全部、photo-*.jpg にリネームして。
> 拡張子だけ小文字に。

手動でやったら 5 分、Claude にやらせると 5 秒。それも、Bash のループ を書いて実行するという、本来は中級者向けの作業を 日本語で頼める。

例 2 — 全 PDF からテキスト抽出して 1 つの CSV へ

> このフォルダの全 PDF からテキストを抽出して、
> ファイル名 + 本文の最初の 200 文字を 1 行ずつ、summary.csv にまとめて。

営業資料・契約書・領収書の山を、1 つの検索可能な表に変える定番技。情報の埋蔵量 が一気に変わります。

例 3 — 複数 Markdown を 1 つの index に集約

> docs/ 配下の全 *.md を読んで、ファイル名・タイトル（H1）・1 行サマリーを
> index.md にまとめて、ファイル名でアルファベット順に並べて。

ドキュメントが散らかったプロジェクト を、自分用の目次ファイルで救う技。検索性が即座に上がります。

例 4 — 全ファイルから共通パターンを抽出

> このフォルダの全 *.log を grep して、
> ERROR / WARN の出現回数をファイル別に集計して。
> 表形式で出して。

==grep -r と awk と sort の組み合わせ を、自分で書かなくていい。コマンドの暗記が不要 になることで、Linux コマンドが急に親しみやすくなる== 副次効果もあります。

「一括処理」型のコツ — 「対象範囲・処理内容・出力先」を明示

一括処理は 規模が大きい ので、3 つの軸を必ず明示してください。

基本パターン 5 — 「対話的に改善」型

5 つ目は 「対話的に改善」 です。これは型というより 姿勢 に近い。一発で完璧を目指さず、3〜5 ターンで仕上げる 心構えです。

形

> （Turn 1）{初期版を作って}
> （Turn 2）{ここを変えて}
> （Turn 3）{これも追加}
> （Turn 4）{もう一回見直して}

例 — ランディングページを 4 ターンで仕上げる

Turn 1 — まずざっくり作る。

> 架空のカフェ「CAFE BLUE」のランディングページを HTML 1 枚で作って。
> メニュー（コーヒー、ラテ、カプチーノ）と営業時間（9:00-18:00）を載せて。

Turn 2 — 見た目を整える。

> さっきのページ、もう少しモダンなデザインにして。
> 配色は青系、フォントは Inter。

Turn 3 — 要素を追加。

> ヘッダーにロゴ用のプレースホルダ（150x40）と、
> フッターに「営業時間外はテイクアウト不可」の注意書きを追加。

Turn 4 — 仕上げ。

> 全体を見直して、レスポンシブ対応を確認して。
> スマホでも崩れないか、CSS の問題があれば直して。

4 ターン使って 5 分で 1 ページ 。Turn 1 で完璧を目指していたら 30 分かけても 60% の出来 だったはず。細切れにすることで、結果が安定する というのが対話的改善の核心です。

「対話的に改善」型のコツ — 「8 割 → 2 割」の分割

完璧な指示で 100% を狙うより、8 割の指示で 8 割の結果を出してから、2 割を会話で詰める ほうが、合計時間が短くなります。

5 つのパターンを 1 枚にまとめる

ここまでの 5 パターンを 1 枚に圧縮します。このカードを Notion や Obsidian や Slack の自分宛 DM に貼っておく と、来週から実務で迷わなくなります。

プロンプト失敗あるある 5 つ

5 パターンを覚えても、失敗するときは失敗します。最初の 30 日でほぼ全員が踏む失敗を、5 つ並べておきます。事前に知っておけば 8 割は回避できます。

失敗 1 — あいまい指示で「想定外」が量産される

> いい感じのページを作って

「いい感じ」は Claude にも分かりません。Claude のセンスは 学習データの平均値 なので、凡庸な「それっぽい」 が返ってきます。

対策 — 「いい感じ」を 3 つの形容詞に置き換える。「モダンで・余白多めで・青系で」のように、形容詞は最低 3 つ重ねる。これだけで結果が劇的に絞れます。

失敗 2 — 文脈不足で「再現できない」と返される

> このデータを集計して

「このデータ」がどこにあるのか、Claude には分かりません。ファイルパスが暗黙的に共有されていると勘違い するのが、人間がやりがちな最大のミス。

対策 — ファイル名・場所・形式を明示。「==./data/sales.csv を読んで、商品列でグループ化して合計を出して==」のように、ファイルパス・対象列・処理内容を 1 文に詰め込む。

失敗 3 — 一度に詰め込みすぎて「どこで間違えたか」が消える

> CSV を読んでデータを集計して HTML レポートを作って
> グラフも入れて Slack 通知もして PDF にもエクスポートして

「読んで・集計して・HTML・グラフ・Slack・PDF」の 6 工程を 1 指示にまとめると、どこかで必ず破綻 します。Claude が誤解しても、人間も追跡できません。

対策 — 1 指示 1 ゴール。「まず CSV を読んで集計→HTML レポート」だけ。Slack 通知や PDF はその後で。小さく刻んで・確認しながら・積み上げる。

失敗 4 — 前提ズレ（環境・バージョン・パスの違い）

> Python スクリプトで Excel を開いて処理して

Python のバージョンは？openpyxl は入ってる？Mac？Windows？Excel のパスは？ — 前提が共有されないと、Claude のデフォルト判断と環境が食い違って動かない ことが頻繁に起こります。

対策 — 環境の前提を最初に伝える。「==Mac、Python 3.11、openpyxl インストール済み==」のように、最初の指示か、CLAUDE.md（第 5 章で学ぶ）に書いておくと、毎回明示しなくて済みます。

失敗 5 — 否定形だらけで「何をしてほしいか」が伝わらない

> 派手じゃなくて、ごちゃごちゃしてなくて、英語じゃなくて、
> 縦長すぎなくて、画像が重くなくて、JavaScript を使いすぎないように

「〜じゃない」を 6 回重ねた指示 は、Claude にも人間にも理解困難です。否定形は 選択肢を絞らない ので、結果が安定しません。

対策 — 肯定形に翻訳。「落ち着いた配色で・余白多めで・日本語で・1 画面に収まる長さで・SVG アイコンで・CSS だけで」のように、「やってほしいこと」 に書き換える。否定 1 個＝肯定 1 個 に翻訳する習慣を。

プロンプトテンプレート集 — そのままコピペで使える 5 本

ここまでの内容を凝縮したテンプレを 5 本置いておきます。手元の Notion や Obsidian や CLAUDE.md にコピペしておくと、来週からの仕事が変わります。

テンプレ 1 — 作って型（ファイル生成）

> {ファイル名} を作って。
> 形式: {HTML / CSS / Python / Markdown / CSV など}
> 含める要素:
> - {要素 1}
> - {要素 2}
> - {要素 3}
> 制約: {文字コード / フレームワーク / 行数 など}
> 出力場所: {パス}

テンプレ 2 — 読んで要約型

> {ファイル / フォルダ} を読んで、以下の形式で要約して。
> 形式: {3 行 / 箇条書き 5 個 / 表 / Markdown のリスト}
> 必ず保持する情報: {数字 / 人名 / 日付 / etc}
> 省略してよい情報: {挨拶 / 重複 / 形式的な前置き}

テンプレ 3 — 実行して報告型

> 以下を実行して結果を報告して。
> コマンド: {コマンド / スクリプト}
> 観察ポイント: {失敗だけ / 件数 / 異常値}
> 報告形式: {3 行 / 表 / 上位 5 件}
> 安全弁: 破壊的操作（rm / git push / DROP など）は実行前に確認

テンプレ 4 — 一括処理型

> 以下の一括処理を実行して。
> 対象範囲: {このフォルダ / *.csv / サブフォルダ含む}
> 処理内容: {リネーム / 抽出 / 集計 / マージ}
> 出力先: {ファイル名 / 標準出力}
> 必須ルール:
> 1. 元ファイルは変更しない
> 2. 処理前に対象ファイル数と処理内容を報告
> 3. 承認後に実行

テンプレ 5 — 対話的改善型

> （Turn 1）まず {対象} のラフ版を作って。
>   要素は最低限の {最小要素}。デザインや細部は後で詰める。
> （Turn 2 以降は会話で）
>   - 「{部分} を {こう} 変えて」
>   - 「{要素} を追加して」
>   - 「全体を見直して {観点} で改善して」

やってみよう — 30 分で 5 パターン全部を 1 回ずつ叩く

ここまで読んだら、今日中に 5 パターンを 1 回ずつ叩いてください。30 分で全部できます。読んで終わると、明日には忘れます。

30 分メニュー

5 分 × 5 タスク。手元のターミナルで順番にやるだけ。

最後の 0

「壊しても困らない場所」を 1 つ作る

実機で叩く前に、練習用フォルダ を 1 つ作ってください。

mkdir ~/claudecode-practice
cd ~/claudecode-practice
claude

このフォルダは 「壊しても困らないサンドボックス」 です。Claude Code はカレントディレクトリを起点に動くので、このフォルダの中だけで好き放題やる 限り、業務ファイルや個人ファイルが事故で壊れることはありません。

まとめ

このレッスンで押さえてほしいことを 6 つ並べます。自分の言葉で 3 行で説明できる ようになるまで、何度か戻ってきても OK です。

1. 「いきなり大きい指示」は NG。最初は小さく・確認できる・壊れないを徹底
2. 5 つの基本パターン（作る・読む・実行・一括・対話）で 80% の業務がカバーできる
3. 指示は 形容詞 3 つ重ね・ファイルパス明示・1 指示 1 ゴール の 3 原則
4. 否定形を肯定形に翻訳 する習慣をつける（「派手じゃなく」→「落ち着いた配色で」）
5. 対話的改善 — 8 割 → 2 割で詰めるほうが、合計時間が短くなる
6. 練習用フォルダ を 1 つ作って、最初の 30 日はそこで遊ぶ

<Quiz question="Claude Code に最初の指示を出すとき、最も避けるべきパターンはどれ？" options={["業務システム全体を 1 つの指示で作らせる","1 つのファイルだけ作る小さな指示から始める","練習用フォルダを作ってからその中で叩く"]} answer={0} />

<Quiz question="「いい感じのページを作って」が失敗指示になる主な理由は？" options={["Claude Code が日本語を読めないから","「いい感じ」の解像度が低く、結果が凡庸になりがちだから","API 料金が高くなるから"]} answer={1} />

次のレッスン 3-2: ファイルを作らせる では、本レッスンで覚えた 「作って」型 を、HTML・Markdown・Python・CSV など ファイル形式別 に深掘りします。「実務で使えるファイル」を 自分の業務向け に量産する型を体に入れます。