Claude Code入門:インストールから最初の30分で成果を出す始め方
Claude Codeの始め方を初心者向けに解説。安全設定、最初のプロンプト、既存コード理解、失敗例まで実務目線で整理。
Claude Codeは、ターミナルから使うAIコーディングエージェントです。 ただし、最初に大事なのは「AIに全部作らせる道具」と思わないことです。
初心者が最初に成功しやすい使い方は、既存コードを読ませる、変更前に計画を出させる、小さな修正を一緒に確認する、この3つです。 いきなり「アプリを全部作って」と頼むと、コード量が増えるだけで、何が正しいのか判断しづらくなります。
この記事では、Claude Codeを初めて触る人が、最初の30分で「これは仕事に使える」と実感するところまで案内します。 公式の Advanced setup、Common workflows、CLI reference を確認しつつ、Masaが実際に記事制作とサイト運用で使っている安全寄りの流れに落とし込みました。
読み終わったら、次は CLAUDE.mdの書き方ガイド と Claude Codeのコンテキスト管理 に進むと、毎回の品質がかなり安定します。
Claude Codeで最初に理解すること
Claude Codeは、チャット画面でコードを聞くツールとは違います。 プロジェクトのファイルを読み、必要なら検索し、許可された範囲で編集し、テストやビルドのコマンドまで実行できます。
ここで初心者がつまずくポイントは、できることが多いぶん、任せ方を間違えると変更範囲が大きくなることです。 つまり入門で覚えるべきことは、難しいプロンプト術ではなく「安全な作業単位の切り方」です。
最初はこの順番で十分です。
| 順番 | やること | 目的 |
|---|---|---|
| 1 | インストールと認証 | まず起動できる状態にする |
| 2 | 読み取り中心でコードを説明させる | プロジェクト理解を助けてもらう |
| 3 | 小さな修正だけ依頼する | 変更範囲を見失わない |
| 4 | テストや差分確認を一緒に行う | 壊れていないことを確認する |
| 5 | メモやCLAUDE.mdに残す | 次回の再現性を上げる |
この順番を守るだけで、かなり事故が減ります。
インストール前に準備するもの
公式ドキュメントでは、Claude CodeはWindows、macOS、Linuxで利用できます。 WindowsならPowerShellまたはCMD、macOSやLinuxならBash/Zshで作業できます。 Git for Windowsを入れておくと、WindowsでもBash系のツールが使いやすくなります。
最低限、次を確認してください。
- Claude Codeを使えるClaudeアカウント
- インターネット接続
- 作業してよいプロジェクトフォルダ
- Gitで差分を確認できる状態
- 失敗しても困らないブランチ
いきなり本番ブランチで始めるのはおすすめしません。 最初は練習用リポジトリか、作業ブランチで試してください。
git status
git switch -c try-claude-code
もし git switch が使えない環境なら、次でも構いません。
git checkout -b try-claude-code
2026年版のインストール手順
現在の公式手順では、ネイティブインストーラが推奨されています。 macOS、Linux、WSLなら次です。
curl -fsSL https://claude.ai/install.sh | bash
Windows PowerShellなら次です。
irm https://claude.ai/install.ps1 | iex
Windows CMDで実行する場合はPowerShell用コマンドと混ぜないでください。
PS C:\ と表示されているならPowerShell、C:\ だけならCMDです。
ここを間違えると、インストール以前のところで止まります。
インストール後は次の2つを確認します。
claude --version
claude doctor
claude doctor は、インストール状態や設定の問題を見つけるための診断コマンドです。
最初の段階で一度実行しておくと、後から「なぜ動かないのか」を探す時間が減ります。
従来どおりnpm経由のインストールも可能です。
ただし、権限エラーを避けるため、公式ドキュメントでも sudo npm install -g は避けるべき扱いです。
npm install -g @anthropic-ai/claude-code
迷ったら、まずは公式のネイティブインストーラを使ってください。
最初の30分でやること
インストールできたら、作業したいプロジェクトのルートで起動します。
cd my-project
claude
初回はブラウザでログインが求められます。 ブラウザが開かない場合は、ターミナルに表示されるURLやコードを使って認証します。
最初の30分は、実装よりも「このプロジェクトをClaude Codeに読ませる」時間にしてください。 おすすめの流れはこれです。
1. プロジェクト構成を説明してもらう
2. 主要な入口ファイルを特定してもらう
3. テスト、ビルド、開発サーバーのコマンドを確認する
4. 触ってよい範囲と触ってはいけない範囲を伝える
5. 小さな変更を1つだけ依頼する
最初のプロンプトは、このまま貼って大丈夫です。
このプロジェクトを初めて触ります。
まずはファイルを編集せず、読み取りだけで以下を整理してください。
- 何をするアプリか
- 主要なディレクトリと役割
- 開発サーバー、テスト、ビルドのコマンド候補
- 変更すると危なそうなファイル
- 最初に読むべきファイル5つ
まだコードは変更しないでください。
「まだコードは変更しない」と明示するのがポイントです。 Claude Codeは便利ですが、初心者の最初の目的は、速く書くことではなく、何が起きているか分かる状態を作ることです。
危険な権限を避ける安全設定
Claude Codeは権限確認をしながら動きます。
公式の権限ドキュメントでは、読み取り、Bash実行、ファイル編集で承認の扱いが違うことが説明されています。
初心者は、まず default または plan の発想で使うのが安全です。
特に注意したいのは、権限確認を飛ばすモードです。
bypassPermissions や --dangerously-skip-permissions は、隔離されたコンテナやVMのような壊れてもよい環境以外では使わない方がいいです。
便利に見えますが、初心者の学習段階では「何を許可したか」を見て覚える方が価値があります。
CLIから安全寄りに始めるなら、計画モードを使います。
claude --permission-mode plan
また、許可ルールを確認したいときは、セッション内で次を使います。
/permissions
よくある安全ルールは、読み取りやバージョン確認は許可し、削除やpushは都度確認する形です。 プロジェクト設定に入れる場合の考え方は次のようになります。
{
"permissions": {
"allow": [
"Bash(git status)",
"Bash(git diff *)",
"Bash(npm run test *)",
"Bash(npm run build *)"
],
"deny": [
"Bash(git push *)",
"Bash(rm -rf *)",
"Read(.env)",
"Read(**/.env)"
]
}
}
この例は「絶対にこのまま全員に配る設定」ではありません。
大切なのは、危ない操作を最初から自動化しないことです。
特に .env、秘密鍵、顧客データ、請求情報、Git push、削除系コマンドは慎重に扱ってください。
既存コードを読むためのプロンプト
Claude Codeが一番役立つ入門タスクは、既存コードの読解です。 新しいプロジェクトに入ったとき、まず全体地図を作らせると、その後の修正がかなり楽になります。
このリポジトリの処理の流れを、初心者にも分かるように説明してください。
特に以下を見てください。
- ユーザーが最初に触る画面またはCLI入口
- データが入ってから表示・保存されるまでの流れ
- 外部APIやDBに触る箇所
- テストがある場所
- 変更時に壊れやすい境界
推測で断定せず、根拠になったファイル名も添えてください。
次に、変更候補を出させます。
このプロジェクトで、初心者が最初に取り組みやすい改善タスクを5つ提案してください。
条件は以下です。
- 1タスク30分以内
- 変更ファイルは最大2つ
- テストまたは手動確認の方法がある
- 本番データや認証まわりに触らない
各タスクに、難易度、リスク、確認方法を付けてください。
ここまでで、かなり使える「作業チケット」ができます。 Claude Codeを単なるコード生成器ではなく、先輩エンジニアのような読解補助として使うイメージです。
実例1:READMEを改善する
最初の実装タスクとして安全なのはREADME改善です。 壊れてもアプリ本体に影響しにくく、プロジェクト理解にもなります。
README.mdを改善したいです。
まず現在のREADMEとpackage.jsonを読んで、足りない情報を箇条書きで出してください。
その後、私が承認した項目だけ編集してください。
承認後に編集してもらうときは、範囲を絞ります。
README.mdに「開発環境の起動方法」と「テストの実行方法」だけ追加してください。
新しいツールや未確認のコマンドは書かず、package.jsonから確認できる内容だけにしてください。
この流れなら、Claude Codeが勝手に大きな構成変更をするリスクが低いです。
実例2:小さなバグを直す
バグ修正では、再現手順を渡すほど精度が上がります。 「なんか動かない」ではなく、「どの操作で、何が期待と違ったか」を渡します。
以下の不具合を調査してください。
現象:
- 検索ボックスに空白だけを入れると、結果が0件ではなく全件表示されます。
期待:
- 空白だけの場合は検索していない扱いにしたいです。
制約:
- まず原因候補を説明してください。
- 変更は1ファイルだけにしてください。
- 修正後に実行すべきテストまたは手動確認も提示してください。
Claude Codeが修正した後は、必ず差分を見ます。
git diff
差分をレビューさせるのも有効です。
今のgit diffをレビューしてください。
意図しない変更、過剰な抽象化、テスト不足があれば指摘してください。
問題がなければ、手動確認手順を3つにまとめてください。
実例3:無料PDFや教材に進む導線を作る
このサイトのように記事、無料PDF、有料教材、相談をつなげたい場合も、最初からLP全体を作らせるより、小さな導線から始める方が安全です。
この記事の読者が次に取る行動を整理したいです。
本文を読んで、初心者向けのCTAを3案作ってください。
条件:
- 売り込み感を強くしない
- 無料PDF、教材、相談の順に自然につなげる
- 1案あたり80文字以内
- 読者の不安を減らす表現にする
その後、既存コンポーネントに合わせて実装します。
既存の記事ページで使われているCTA表現を確認し、
同じトーンでこのページ末尾にCTAを追加してください。
新しいコンポーネントは作らず、既存パターンに合わせてください。
Claude Codeは「新しく作る」より「既存パターンに合わせる」方が安定します。 初心者ほど、毎回この言い方を入れると結果がよくなります。
よくある失敗例
一番多い失敗は、最初のプロンプトが大きすぎることです。 「このアプリをいい感じにして」では、Claude Codeも判断基準を持てません。 タスク、対象ファイル、確認方法を小さく切ってください。
二つ目は、権限を広げすぎることです。 早く進めたい気持ちは分かりますが、最初からpushや削除を自動承認にすると、レビューの機会が消えます。 慣れるまでは、面倒でも確認ダイアログを見てください。
三つ目は、実行結果を見ないことです。
Claude Codeが「修正しました」と言っても、テスト、ビルド、画面確認、git diff のどれかで確認する必要があります。
四つ目は、会話が長くなりすぎたまま続けることです。
話題が増えたら /compact や引き継ぎメモを使い、次のセッションで何をすべきかを短く残します。
詳しくは コンテキスト管理ガイド で整理しています。
詰まったときのチェックリスト
動かないときは、いきなり再インストールする前に、次を順番に見ます。
claude --versionは通るかclaude doctorは何を警告しているか- 作業ディレクトリは正しいか
- Gitの差分は意図したものだけか
.envや秘密情報を読ませようとしていないか- WindowsならPowerShellとCMDのコマンドを混ぜていないか
- WSLやSSHならブラウザ認証コードを貼る流れになっていないか
--permission-modeを危険な設定にしていないか- テストコマンドはpackage.jsonなどに実在するか
Claude Codeにチェックさせるなら、こう頼みます。
Claude Codeが期待通り動きません。
まだファイルは編集せず、原因切り分けだけ手伝ってください。
環境:
- OS:
- シェル:
- 実行したコマンド:
- 表示されたエラー:
- 期待していた動作:
まず確認すべき順番を、危険度の低いものから並べてください。
Masaの検証メモ
Masaがこのサイト運用で試した限り、Claude Code入門で一番効果があったのは、最初から自動化しすぎないことでした。 記事生成、翻訳、ビルド、デプロイまで任せると便利ですが、最初は「読む」「計画する」「1ファイルだけ直す」の順番にした方が失敗が少ないです。
特に、権限確認を残したまま git diff とビルド結果を見る運用にすると、AIが書いたコードを自分の判断に戻せます。
逆に、確認を飛ばして長時間走らせると、後から差分の意図を追うのがつらくなります。
これはブログ運用でも開発案件でも同じでした。
初心者向けに一言でまとめるなら、Claude Codeは「作業を丸投げする相手」ではなく、「作業を小さくして一緒に進める相手」です。
次に読むもの
まずこの記事の流れで、1つのプロジェクトを読ませて、小さなREADME改善かバグ修正を試してください。 そのあと、次の順番で進むと迷いにくいです。
- 非エンジニアなら 非エンジニア向けClaude Code入門
- プロジェクトごとのルールを整えるなら CLAUDE.mdの書き方ガイド
- 長い作業で迷子になるなら コンテキスト管理ガイド
- 作業効率を上げたいなら Claude Code生産性向上Tips
手元で見ながら進めたい人向けに、無料の Claude Code Quick Reference Cheatsheet も用意しています。 チーム導入や研修、既存プロジェクトへの安全な組み込みまで相談したい場合は、教材や相談導線から状況を共有してください。 最初の一歩を小さく切るだけで、Claude Codeはかなり頼れる相棒になります。
無料PDF: Claude Code はじめてのチートシート
まずは無料PDFで基本コマンドと最初の使い方をまとめて確認してください。登録後はそのままテンプレート集や導入相談にも進めます。
スパムは送りません。登録情報は厳重に管理します。
Claude Codeを仕事で使える形にしませんか?
無料PDFで基礎を固めたあと、すぐ使えるテンプレート集で試し、必要なら業務自動化や導入相談まで進められます。
この記事を書いた人
Masa
Claude Codeの実務活用、導入設計、収益導線改善を検証しているエンジニア。10言語の技術メディアを運営中。
関連書籍・参考図書
この記事のテーマに関連する書籍を楽天ブックスで探せます。
※ 当サイトは楽天市場のアフィリエイトプログラムに参加しています。上記リンクから商品をご購入いただくと、運営者に紹介料が支払われる場合があります。
関連記事
Claude Code初回リポジトリ監査チェックリスト: 編集前20分で迷子を防ぐ
Claude Codeで既存コードを触る前に、入口、危険領域、検証コマンド、CTA導線を20分で確認する実務チェックリスト。
Claude Code Harness Lite: 初心者が安全に変更するための小さな足場
大きな自動化の前に使う、読み取り、変更、検証、公開確認を分けるClaude Codeの軽量ハーネスです。
Claude CodeのRepo Map初回パス: 既存コードを安全に読み始める手順
Claude Codeで既存リポジトリを読む最初の30分。編集前の地図作り、実例、失敗例、無料PDFと教材導線までまとめます。