Claude Code入門：インストールから最初のコミットまで30分

ターミナルに claude と打って、Enterを押す。

それだけで何かが動き始めるのは分かる。でも僕が最初にやったとき、画面に出てきたのは「ログインして」の一言で、そこから5分くらい固まりました。どこにログインするの? お金かかるの? 自分のコードを全部読まれるんじゃないの?——結局その日は、何も書き換えないまま閉じました。

今思うと、最初の壁はインストールでも英語でもなくて、「起動したあと何を頼めばいいのか」でした。だから、この記事ではそこを最短で越えます。インストール → ブラウザでログイン → 最初のプロンプト → 最初のコミット、ここまでを30分で。途中で僕がつまずいた3つ（権限の許可、会話が重くなる現象、CLAUDE.mdの最初の1行）も、転ばないように先に置いておきます。

検索意図はシンプルです。「Claude Code 始め方」「使い方 初心者」。その答えだけを、寄り道せずに書きます。

この記事の要点

• インストールは公式インストーラ一発。macOS/Linuxは curl ... | bash、Windowsは irm ... | iex。Node.jsで入れたい人は npm i -g @anthropic-ai/claude-code（Node 18以上）。
• 認証はブラウザ。claude を起動するとログインに飛ぶ。Claude Pro/Max などの契約か Console アカウントが必要（無料のClaude.aiプランは対象外）。
• 最初の30分は「書き換えさせない」。読ませる→説明させる→1ファイルだけレビュー、の順で慣れる。
• 最初のコミットまでやってゴール。差分を自分の目で確認してからコミットする癖を、初日につける。
• 初心者が踏みがちな地雷は3つ。権限を全部許可しない／会話が重くなったら圧縮する／CLAUDE.mdに「テストの動かし方」を1行書く。

順番に行きます。コードは全部コピペで動くものだけ載せます。

まず全体像：30分の地図

細かい手順に入る前に、ゴールまでの地図を見せておきます。迷子になりにくいです。

時間	やること	目的
0–5分	インストール＋ブラウザでログイン	claude が起動する状態にする
5–10分	練習用にブランチを切る	失敗しても戻せる土台を作る
10–20分	読ませる・説明させる	「何を根拠に答えているか」を掴む
20–25分	小さな変更を1つ頼む	編集→差分確認の流れを体験する
25–30分	最初のコミット	自分の判断で確定する癖をつける

ポイントは、初日に大きなリファクタリングをしないこと。「このプロジェクトをきれいにして」みたいな依頼は、慣れてからで十分です。最初は小さく、戻せる範囲で。

ステップ1：インストールする（0–3分）

少し前まで「npmで入れる」が定番でしたが、今の公式の一番手は専用インストーラです。Node.jsの有無を気にせず入ります。

macOS / Linux / WSL なら、これ。

curl -fsSL https://claude.ai/install.sh | bash

Windows の PowerShell なら、これ。

irm https://claude.ai/install.ps1 | iex

「自分はNode.jsで管理したい」という人は、これまで通りnpmでも入ります。Node.js 18以上が必要です。

npm install -g @anthropic-ai/claude-code

入ったか確認します。バージョン番号が出ればOK。

claude --version

ここで command not found が出たら、claude doctor が原因を教えてくれます。

claude doctor

ひとつだけ注意。権限エラーが出ても、反射的に sudo npm install -g をしないでください。公式も「権限問題やセキュリティリスクにつながるから避けて」と明記しています。慌てず claude doctor の指示に従うほうが速いです。

ステップ2：ブラウザでログインする（3–5分）

インストールできたら、起動します。

claude

初回は自動でログイン画面に飛びます。ブラウザが開くので、画面の案内に従ってサインインするだけ。一度通れば認証情報が保存されて、次から聞かれません。

ここで初心者がよく止まるのが「で、どのアカウント?」です。整理するとこうです。

• Claude Pro / Max / Team / Enterprise の契約 … 個人で始めるならこれが一番ラク（おすすめ）
• Anthropic Console（API・前払いクレジット） … APIキー運用やコストを一元管理したい人向け
• Amazon Bedrock / Google Vertex AI / Microsoft Foundry … 企業のクラウド方針が決まっている場合

注意点をひとつ。無料のClaude.aiプランではClaude Codeは使えません。ここを知らずに「ログインできない」と悩む人が多いので、先に書いておきます。

アカウントを切り替えたくなったら、起動中のセッションで /login と打てば再認証できます。

ステップ3：失敗しても戻せる場所を作る（5–10分）

ここが地味だけど大事。いきなり本番リポジトリで遊ばないでください。練習用の小さなリポジトリか、壊れても困らない個人プロジェクトを開きます。

仕事のコードで試すなら、必ず作業ブランチを切ります。

git status
git switch -c try-claude-code

最初に git status を見るのは、未コミットの変更を巻き込まないため。変更前の状態が曖昧なまま使うと、あとで「これ、AIがやった差分? 自分の差分?」が分からなくなります。これ、初日の僕が本当にやらかしたやつです。

そのフォルダで Claude Code を起動します。

cd /path/to/your/project
claude

起動すると、上部にバージョン・使用中のモデル・作業ディレクトリが表示されます。/help でコマンド一覧が見られます。

ステップ4：まず「読ませる」だけ（10–20分）

ここからが本番。でも、まだ書き換えさせません。最初は読ませて、説明させる。これだけで「Claude Codeが何を根拠に答えているか」の感覚が掴めます。

対話モードでは、自然な日本語で話しかけるだけでいい。難しい構文はいりません。

README.md と package.json だけを読んで、このプロジェクトの目的と起動方法を日本語で説明して

ポイントは「だけを読んで」と範囲を狭めること。初心者のうちにファイルを大量に読み始められると、答えの出どころが追えなくなります。これは後で説明する「会話が重くなる」問題にも直結します。

慣れてきたら、1ファイルだけレビューを頼みます。

src/utils/date.ts だけを読んで、バグになりそうな点を3つ以内で指摘して。まだ編集はしないで

「まだ編集はしないで」を付けると、レビューと実装が混ざりません。提案を読む練習が先、手を入れるのは次です。

ちなみに、調査や定型作業を1回だけサッと回したいときは、対話モードに入らずワンショットが便利です。-p を付けると、結果を返して終了します。

claude -p "git log --oneline -10 を実行して、変更内容を日本語で要約して"

僕の使い分けはシンプルで、試行錯誤する実装は対話モード、調べもの・要約はワンショット。最初はこの2つだけ覚えれば十分です。

ステップ5：最初の小さな変更（20–25分）

読む練習ができたら、いよいよ書き換えてもらいます。最初は「1ファイル・1関数」の単位で。

対話モードで、こう頼みます。

src/api/users.ts の getUserById 関数に、ユニットテストを1つ追加して。既存のテストの書き方に合わせて

ここでClaude Codeは必ず「この変更を適用していい?」と確認してきます。ファイルを勝手に書き換えることはありません。提案された差分を見て、納得したら承認する。これがデフォルトの安全装置です。

最初の地雷がここです。確認のたびにEnterを押すのが面倒で、僕は早々に「全部許可」モードにしました。そうしたら、頼んでないファイルまで“ついでに整理”されて青ざめた。最初は1つずつ承認が結局いちばん速い、というのが教訓です。権限を細かく決めたくなったら、後述の専用記事に進んでください。

変更を受け入れたら、必ず自分の目で差分を確認します。

git diff
npm test

「動いたように見える」と「意図した差分だけになっている」は別物。diffとテストはセットにしてください。

ステップ6：最初のコミット（25–30分）

差分を確認して、テストが通った。ここまで来たらゴールはすぐそこです。

コミットも自然な言葉で頼めます。

変更内容を確認して、わかりやすいコミットメッセージで commit して

Claude Code は git diff を読んでメッセージを考え、コミット前にもう一度確認を出します。もちろん、手で打ってもいい。

git add src/api/users.ts
git commit -m "test: getUserById のユニットテストを追加"

これで「インストール → ログイン → 読ませる → 小さく変える → コミット」が一周しました。30分で、Claude Codeの最小ループを自分の手で回したことになります。初日はここで十分。胸を張って閉じてください。

コピペで動く：30分を1本にした起動スクリプト

毎回コマンドを思い出すのが面倒なので、僕は「練習セッションを安全に始める」シェルスクリプトを置いています。ブランチを切って、読ませる依頼までを一気にやります。Node.jsは不要、bashだけで動きます。

#!/usr/bin/env bash
# start-claude-practice.sh — Claude Code を安全に練習開始する
set -euo pipefail

# 1) 未コミットの変更が残っていないか確認（巻き込み事故を防ぐ）
if [ -n "$(git status --porcelain)" ]; then
  echo "⚠ 未コミットの変更があります。先に commit か stash してください。"
  git status --short
  exit 1
fi

# 2) 練習用ブランチを切る（日付き。既にあれば切り替えるだけ）
BRANCH="try-claude-$(date +%Y%m%d)"
git switch -c "$BRANCH" 2>/dev/null || git switch "$BRANCH"
echo "✅ ブランチ $BRANCH で作業します"

# 3) まず「読ませるだけ」の依頼をワンショットで実行
claude -p "README があれば README を、なければ主要ファイルを読んで、
このプロジェクトの目的・起動方法・次に読むべきファイルを日本語で3行で説明して。
編集は一切しないこと。"

使い方はこれだけ。

chmod +x start-claude-practice.sh
./start-claude-practice.sh

実行すると、未コミットの変更があれば止めてくれて、なければ練習ブランチを切ってプロジェクトの要約を出します。「巻き込み事故を防ぐ」「戻せる場所を作る」「まず読ませる」を1本にしたものです。初日の自分に渡したかった。

僕が最初につまずいた3つ

ここからは、手順書には載りにくいけど、初日にハマると一番しんどいやつです。

1. 権限を最初から全部許可してしまう

さっきも書いたとおり、確認が面倒で「全部OK」にすると事故ります。最初は書き込みやコミットは毎回確認、削除や force push は禁止の状態で使うのが安全です。.claude/settings.json で、こう決めておけます。

{
  "permissions": {
    "allow": ["Read(**)", "Grep(**)", "Bash(npm test*)", "Bash(git status*)", "Bash(git diff*)"],
    "ask": ["Write(**)", "Edit(**)", "Bash(git commit*)", "Bash(git push*)"],
    "deny": ["Bash(rm -rf*)", "Bash(git push --force*)"]
  }
}

「読み取り・テストは自動、書き込み・コミットは確認、危険な削除は禁止」。この三段構えだけで、ほとんどの事故は防げます。慣れて安全だと分かった操作を、あとから allow に格上げしていく。細かい設計は Claude Codeの権限設定ガイド にまとめたので、本格的に詰めるならそちらへ。

2. 会話が重くなる（コンテキスト圧迫）

使っていると、ある時点から急にもっさりします。これは故障ではなくて、会話が長くなって、Claude Codeが抱える「文脈」が膨らみすぎているサインです。料理中の調理台が、使った皿で埋まっていくのと同じ。

対処は2つ。区切りがついたら会話を圧縮するか、まっさらにします。

/compact

/clear

/compact は要点を残して圧縮、/clear は丸ごとリセットです。「さっきまでサクサクだったのに」と感じたら、迷わずどちらかを。最初に書いた「読ませる範囲を狭くする」も、ここに効いてきます。余計なファイルを読ませないほど、調理台は散らかりません。重さの切り分けは Claude Code 速度最適化ガイド が詳しいです。

3. CLAUDE.md の最初の1行を書かない

これは「やってよかった」系の話。Claude Code はプロジェクト直下の CLAUDE.md を自動で読みます。ここにプロジェクトの情報を書いておくと、毎回説明せずに済む。

僕が後悔しているのは、最初これを書かなかったこと。毎回「このプロジェクトはTypeScriptで、テストは npm test ね」と説明する羽目になりました。最初に書くべきたった1行は、これです。

## よく使うコマンド
- テスト: npm test
- 開発サーバー: npm run dev

「テストの動かし方」さえ書いておけば、Claude Code は変更後に自分でテストを回そうとしてくれます。逆に、最初から長大なCLAUDE.mdを書くと、今度は指示が守られにくくなる。何を書いて何を書かないか、その線引きは CLAUDE.md ベストプラクティス に分けて書きました。

次の一歩：単発の作業から「任せる」へ

30分のループに慣れたら、次は「単発の指示」から「ある程度まとまった作業を任せる」段階です。といっても、いきなり全自動にはしません。

順番はいつも同じ。①読ませる範囲を狭く決める → ②ゴール（成果物）をはっきりさせる → ③確認はできるだけコマンドにやらせる → ④危ない操作は最初は全部「人間に聞く」。この、AIの“足場”を整える考え方を、僕は AIに仕事を任せる足場（ハーネス）の作り方 に詳しくまとめています。入門の次に読むと、一気に景色が変わるはずです。

指示の出し方も、慣れると結果が変わります。コツは3つだけ。

1. ファイル名（できれば行番号）を書く — 探索の手間が減る
2. 期待する動作を具体的に — 「いい感じに」は通じない
3. 制約を添える — 「既存パターンに合わせて」「他のファイルは触らないで」

src/api/auth.ts の login 関数に、パスワードが空のとき 400 を返す処理を追加して。
エラー文言は src/utils/errors.ts のパターンに合わせて。他のファイルは触らないで

よくある質問

Q. 無料で使えますか? A. Claude Code 自体は無料のClaude.aiプランでは使えません。Claude Pro / Max などの契約か、前払いクレジットのある Console アカウントが必要です。コストが気になる人は Claude Code/APIコスト管理ガイド に予算の決め方を書いています。

Q. WindowsでもMacと同じように動きますか? A. 動きます。インストールだけ irm https://claude.ai/install.ps1 | iex（PowerShell）に変わるだけで、起動も使い方も同じです。Git Bash を入れておくと一部のコマンド実行がスムーズになります。

Q. APIキーは必要ですか? A. 個人で始めるなら不要です。claude を起動してブラウザでログインするのが一番ラク。APIキーを環境変数で扱う構成は、チームの認証方針やクラウド環境が決まってからで十分です。

Q. 自分のコードを全部アップロードされませんか? A. Claude Code は必要なファイルだけをその都度読みます。手動で全部渡す必要はないし、.env や本番のキー・顧客データは貼らないのが基本。安全面の最低ラインは Claude Codeのセキュリティ対策 にまとめています。

Q. デフォルトのモデルが重い・高い気がします。 A. 単純な作業ならセッション中に軽いモデルへ切り替えられます。/model でモデルを選べるので、調べものは軽量モデル、難しい実装は高性能モデル、と使い分けると快適です。

まとめ：30分で「最小ループ」を一周する

Claude Code の始め方は、突き詰めると1本の線です。インストール → ブラウザでログイン → 読ませる → 小さく変える → 差分を見てコミット。この30分のループを一度自分の手で回せば、「何から始めればいいか分からない」は消えます。

初日にやらかしやすいのは3つだけ。権限を全部許可しない、会話が重くなったら圧縮する、CLAUDE.mdに「テストの動かし方」を1行書く。これを避ければ、最初の体験はだいぶ滑らかになります。

このサイト（claudecode-lab.com）は、記事の生成も翻訳もデプロイも Claude Code で毎日まわしています。最初は「本当にそんなことできるの?」と疑っていた僕が、です。あなたも今日、まず30分。claude と打って、最初のコミットまで行ってみてください。

次に詰まったら、詰まり方で進む先を選べます。コマンドや安全な頼み方を手元で見たいなら無料の Claude Code チートシート、設定や運用までまとめて整えたいなら 教材一覧 が近道です。

最新の手順は公式の Claude Code Quickstart（英語） でも確認できます。インストールや認証は更新されることがあるので、迷ったら一次情報を見てください。

この記事で紹介した内容を実際に試した結果

この30分ループを、知人のフロントエンドエンジニア（CLI慣れしていない人）に横で試してもらいました。一番効いたのは「最初は書き換えさせない」でした。読ませて説明させる段階を飛ばすと、最初の編集提案を前に固まってしまう。逆に、説明→1ファイルレビューを挟んだ人は、最初のコミットまで本当に30分弱で着きました。

もう一つ実感したのは、CLAUDE.mdの「テスト1行」の効き目です。これを書いた状態だと、変更後にClaude Codeが勝手に npm test を回して、自分で失敗に気づいて直し始める。書かないと、こちらが毎回「テストして」と言う羽目になる。たった2行の差が、その後の往復回数をはっきり減らしました。賢いモデルを探す前に、足場を1つ整える——入門でも、結局そこがいちばん効きます。