Claude Code 最初の使い方｜初プロンプト・安全な進め方とおすすめタスク5選

本記事は「Claude Code をインストールして起動はできた、けれど何を打てばいいのか分からない」という方のための、最初の数日間用の入門書です。プログラミング以外の用途も含めて、最初に試して外しにくい 5 タスクをまとめました。失敗してもダメージのない選び方と、結果の読み方、うまくいかないときの対処までを 1 記事で扱います。

🌱 最初のタスクは何を選ぶべきか

ひとことで：小さい・元に戻せる・既存ファイルを壊さない、の 3 条件で選びます。

「便利そうだから本番のリポジトリでいきなり使ってみよう」は、初日にやってはいけない選択です。Claude Code は強力なぶん、設定や指示の癖が分かる前に大きなタスクを投げると想定外の編集が一気に通ってしまうリスクがあります。

最初のタスクを選ぶ基準は、シンプルにこの 3 つです。

• 小さい：5〜10 分で結果が出るスコープに留める
• 元に戻せる：Git や手動コピーで一発リセットできる
• 既存ファイルを壊さない：読み取り中心、書き換えるなら必ず差分プレビューを挟む

この 3 つを満たすタスクを「Hello World タスク」と呼ぶことにします。最初の数日はこの縛りプレイで感覚をつかんでください。

🛡️ 作業前チェック：これだけはやってから始める

ひとことで：Git バックアップ・パーミッション・起動場所・機密情報、の 4 点を確認します。

最初のプロンプトを打つ前に、次の 4 つだけは必ず確認してください。

Git で現状をコミットしておく

「Hello World タスク」とはいえ、実行前のスナップショットを取っておくのが基本です。Git を使っているプロジェクトなら、まず git status で何も未コミットの変更がない状態にし、git commit 後の状態から作業を始めるのが安全です。Git を使っていないフォルダで試すなら、フォルダごとコピーして退避してから始めましょう。

default パーミッションモード（毎回確認）になっているか

Claude Code は最初の起動時、default モード（ファイル変更・コマンド実行のたびに確認を求める）で動きます。慣れる前に「自動承認」「全部許可」のようなモードに切り替えるのは禁物です。慣れてきたらモードを緩める方法は別記事（パーミッションと安全設定ガイド）で扱います。最初の 1〜2 週間は default のまま我慢してください。

自分のディレクトリで起動する

Claude Code は起動したフォルダの中身を作業対象にします。他人のプロジェクト・チームの本番リポジトリ・OS の重要フォルダで試すのは絶対に避けてください。練習用に専用のフォルダを 1 つ作って、そこで触るのが正解です。

機密情報のファイルが近くにないか

.env（API キーやパスワードを置く慣例的なファイル）・個人情報を含む CSV・社外秘の設計書などが起動フォルダ内にあると、Claude が読み取ってしまう可能性があります。最初は機密ゼロの練習フォルダで試すのが一番安心です。

✏️ 最初のプロンプトの型

ひとことで：「何を／どこを見て／どう終われば完了か」の 3 要素を入れるだけで、結果が安定します。

最初のプロンプトに身構えすぎる必要はありません。次の 3 要素を 1〜2 文で書くだけで、Claude の出力はぐっと安定します。

要素	書く内容	例
何をしたい	達成したいゴール	「README の文体を統一したい」
どこを見て	対象ファイル・フォルダ	「README.md を見て」
どう終わったらいい	完了の判定基準	「差分を見せてから書き換えて」

3 要素を 1 文にまとめると

README.md の文体を統一して誤字を直して。書き換える前に差分を見せてね。

これだけで、Claude は対象ファイルを読み、編集内容を考え、差分を提示してから書き換えてくれます。完了条件として「差分を見せて」と入れることで、いきなり書き換えさせず確認の一拍を置けるのがコツです。

なお、より精緻な「Goal / Context / Constraints / Done when」の 4 要素設計は別記事（[CC-14] Claude Code プロンプト設計）でくわしく解説します。最初は 3 要素で十分です。

🎁 Hello World タスク 5 選：分野別の入り口

ひとことで：プログラミング・データ・文章・3DCG・記録の 5 分野で、外しにくいタスクを 1 つずつ用意しました。

Claude Code は「コードを書くだけのツール」ではありません。ファイル操作とテキスト処理の汎用エージェントとして、文章・データ・クリエイティブ素材の整理にも使えます。ここでは 5 分野から 1 タスクずつ、コピペでそのまま試せる依頼文を紹介します。

タスク 1：プロジェクトの全体構造を説明してもらう（プログラミング）

このプロジェクトの全体構造を読んで、
主要なファイル 5 つと役割を表で教えて。
ファイルは編集しないでね。

安全ポイント：「ファイルは編集しないでね」と書くことで、読み取りだけのタスクに限定できます。Claude のコード理解力を体感する王道タスクで、新しいリポジトリのキャッチアップにも応用できます。

タスク 2：CSV ファイルの整理・集計（データ作業）

sales.csv を読んで、月別の合計金額を表にして。
元ファイルは変更しないで、出力は別ファイル `sales_monthly.csv` に書き出してね。

安全ポイント：「元ファイルは変更しないで・別ファイルに書き出して」を入れることで、原本が壊れないようにします。Excel や Google スプレッドシートを開かずに、自然言語で集計が完了する体験は新鮮です。CSV 以外（TSV / Markdown 表）でも同じ調子で頼めます。

タスク 3：Markdown 文書の校正・要約（文章作業）

README.md の文体を「です・ます調」に統一して、誤字を直して。
書き換える前に、変更点の差分を見せてね。

安全ポイント：差分プレビューを入れることで、書き換える前に内容を判断できます。ブログ下書き・議事録・社内ドキュメントなど、Markdown で書かれた文書ならどれでも応用可能です。「要約」を頼んでもよく、長い議事録から TL;DR（要約）を抜き出すのにも使えます。

タスク 4：テクスチャや素材ファイルの一括リネーム（3DCG・クリエイティブ）

textures フォルダの PNG ファイルを `T_アセット名_種類.png` の規則でリネームして。
実行前に、変換表（旧名 → 新名）を Markdown 表で見せてね。
それを見て OK と言ったら実行してね。

安全ポイント：「変換表を見せて → OK で実行」の 2 段階構成にすることで、いきなりリネームが走るのを防げます。3DCG アーティストやデザイナーが、命名規則がバラバラなアセットを一括で揃えたいときの定番タスクです。コピー先を別フォルダにする運用にすればさらに安全です。

タスク 5：開発日記やプロジェクト概要の自動生成（記録・ドキュメント）

git log の直近 1 週間分を読んで、
開発日記を Markdown 形式で `devlog/2026-05-week2.md` に作って。
新規ファイルなので、上書きの心配はないよ。

安全ポイント：新規ファイル作成のため、既存ファイルへの影響がありません。git log から週次・月次の振り返りを自動生成する運用は、個人開発・チーム開発のどちらでも便利です。Notion や Slack に貼る素材作りにも応用できます。

🔍 結果の読み方と採用判断

ひとことで：差分・出力・計画の 3 種類を見て、Accept・修正依頼・Reject を選びます。

Claude Code の結果は、見るべきポイントが 3 種類あります。「全部 OK」と「全部却下」の二択で考えず、部分的に修正依頼を出せるのが Claude Code の強みです。

Edit ツールの差分（ファイル編集の提案）

ファイル編集が提案されると、ターミナル／アプリ上に赤緑の差分が表示されます。チェックする観点は 3 つです。

• 意図と一致しているか：頼んだ内容を踏み外していないか
• 巻き込み事故がないか：頼んでいない箇所まで編集されていないか
• 既存の規約を守っているか：インデント・命名・スタイルが揃っているか

問題なければ Accept、軽微な修正なら追加プロンプトで「ここだけ変えて」、根本的におかしければ Reject で取り下げます。

Bash ツールの出力（コマンド実行）

npm install や git status のようなコマンド実行のときは、実行前の確認ダイアログが出ます。コマンドの中身が想定と一致しているか、副作用が大きすぎないか、を見てから許可してください。慣れないうちは、毎回コマンド全文を読むのを習慣にしましょう。

Plan の提示（計画モード）

「まず計画を立てて見せて」と頼んだ場合、Claude はファイルを編集せず計画書だけを提示します。計画段階で方針を確認できるので、大きなタスクではこの方式が圧倒的に安全です。

採用 / 一部修正依頼 / 却下の判断軸

状態	判断	次のアクション
意図通り	Accept	そのまま採用
大筋は合っているが一部違う	修正依頼	「◯◯だけ変えて」と追加プロンプト
方向性が違う	Reject	やり直し or プロンプトを書き直す

🆘 うまくいかないときの対処

ひとことで：「思ったのと違う」「途中で止まった」「許可ダイアログが多い」の 3 パターンに、それぞれ対処があります。

最初の数日でつまずくのは、だいたい次の 3 パターンに分類できます。

「思ったのと違う結果になる」

プロンプトに具体性を足して再依頼するのが基本です。「綺麗にして」「いい感じに」のような曖昧な指示は、Claude も人間も同じく解釈に迷います。

❌ 「README をいい感じにして」 ✅ 「README の文体を です・ます調 に統一して、見出しが連続している箇所には間に 1 段落の説明を入れて」

具体的にどう違ったかを 1〜2 行追加するだけで、次の出力は格段に意図に近づきます。

「途中で止まった・固まった」

Esc キーで現在のタスクを止めて、状況を整理して再開するのが基本です。何度も同じところで止まるなら、/clear（会話履歴をリセット）で一度フレッシュにするのも有効です。コンテキストが膨らみすぎているサインのことが多いので、タスクをもっと小さく刻んで頼み直すと進みます。

「許可ダイアログが多すぎてめんどくさい」

慣れるまでは default モードのまま我慢するのが正解です。許可ダイアログは「今、AI が何をしようとしているか」を強制的にレビューさせる安全機構なので、序盤に省略すると事故率が跳ね上がります。

「これは毎回許可していい」と確信できるコマンドが見えてきたら、設定で個別に許可リストへ加える方法があります。詳しい運用は別記事（パーミッションと安全設定ガイド）で扱います。

📚 次に読む記事

ここまで体験できたら、次のステップは「プロンプトの精度を上げる」と「毎回同じ指示を書かなくて済むようにする」の 2 方向に進めます。

• プロンプトを安定させたい → Claude Code プロンプト設計（CC-14）
• プロジェクト固有のルールを永続化したい → CLAUDE.md 完全ガイド（CC-03）
• 許可ダイアログに疲れてきた → パーミッションと安全設定ガイド（CC-05）

タスクの種類を増やしたい方は、実践ワークフロー集（CC-04）で「探索 → 計画 → 実装 → 検証」の流れを試してみるのもおすすめです。