Claude Code の使い方 — 入門記事の次にやる 4 つのこと

Claude Code の使い方を説明した記事は多いのですが、そのほとんどは 「インストールして、最初の 1 回を動かすまで」で終わっています。 実際に困り始めるのはその後です — 同じ指示を毎回書いている、確認ダイアログが 多すぎる、そして作業の途中で 5 時間の利用制限に当たる。このページは入門記事が終わるところから始めて、 その 3 つを順に片付けます。

前提として、Claude Code は「チャットにコードを貼るツール」ではなく、 ターミナルでリポジトリの中に住むエージェントです。ファイルを読み、書き換え、 テストを走らせ、コミットまで行います。だから最初にやるべきことは、 使い方を覚えることではなく、プロジェクトのルールを渡すことです。

最初の 3 手 — 起動、/init、具体的な依頼

インストール直後にやる価値があるのはこの 3 つだけです。特に 2 番目の /init を飛ばすと、以降の全セッションで同じ説明を繰り返すことになります。

# 1. プロジェクトのディレクトリで起動する（ここが全ての前提）
cd ~/work/my-app
claude

# 2. 最初の一手は /init — リポジトリを読んで CLAUDE.md を書き出す
> /init

# 3. 以降は普通の日本語で頼む。ファイル名を添えるほど精度が上がる
> src/api/user.ts のバリデーションを zod に置き換えて、テストも直して

/init はリポジトリを読んで CLAUDE.md を生成します。生成された内容は下書きなので、そのままにせず必ず手で直してください。 次の節がその中身の話です。

CLAUDE.md — 毎回説明していることを 1 回だけ書く

CLAUDE.md はプロジェクトのルートに置く Markdown ファイルで、セッションのたびに自動で読み込まれます。ここに書くべきなのは「コードを読んでも分からないこと」だけです。

# CLAUDE.md — プロジェクトのルート、git にコミットする

## コマンド
- テスト: npm test（1 ファイルだけなら npm test -- path/to/file）
- 型チェック: npx tsc --noEmit
- Lint: npm run lint

## 決めごと
- 日付は必ず date-fns。moment は使わない。
- API ハンドラは app/api/**/route.ts のみ。lib に書かない。
- コミットメッセージは日本語、prefix は feat / fix / docs。

## 触ってはいけない場所
- db/migrations/ — 生成物。手で編集しない。

逆に書かないほうがよいものもはっきりしています。ディレクトリ構成や関数の説明は コードを読めば分かるので不要です。CLAUDE.md は毎回のリクエストに乗るため、長くすると確実にトークンを消費します — 短く、決めごとだけ。git にコミットすればチーム全員に同じルールが効きます。

権限 — 確認の回数を減らす、ただし飛ばしすぎない

ファイルの書き換えやコマンド実行のたびに確認が入ります。これは安全装置なので、 全部を消すのではなく「読み取り・検証系だけ許可する」のが実務的な落とし所です。 セッション中に「常に許可」を選べば記憶され、 .claude/settings.json に書けばプロジェクト単位で固定できます。

すべての確認を飛ばすフラグも用意されていますが、削除やリモートへの push まで無確認になります。使ってよいのは、壊れても捨てられるコンテナや 使い捨ての作業ツリーの中だけです。判断基準と安全な使い方は --dangerously-skip-permissions の使いどころ にまとめてあります。

カスタムコマンド — 同じ頼み方を毎回書かない

レビュー、リリース前チェック、コミットメッセージの整形のように 毎回ほぼ同じ頼み方をする作業は、コマンドにしてしまえます。.claude/commands/ に Markdown を置くだけです。

# .claude/commands/review.md — 置くだけで /review として使える
指定されたファイルをレビューして、次の 3 点だけ指摘してください。

1. 実際に落ちる条件があるバグ（再現手順を添える）
2. 既存のユーティリティで置き換えられる重複
3. テストが無い分岐

スタイルの好みは指摘しないでください。

これで /review src/api/user.ts と打てば同じ観点のレビューが返ります。 git にコミットすればチームで共有でき、レビュー基準そのものをリポジトリに置けます。 実務で効くコマンドの型は Claude Code workflows に英語で詳しく書いています。

5 時間ウィンドウが閉じたときの続け方

サブスクリプションの利用枠は 5 時間のローリングウィンドウで管理されていて、作業が乗ってきた午後に閉じます。 上位プランに変えてもその瞬間には開きません。選択肢は実質 3 つです。

3 番目はサブスクを解約せずに行えます。次の 2 行が設定されている間だけ従量課金になり、変数を消せば元のサブスクに戻ります。

# 5 時間ウィンドウが閉じても作業を続けるための 2 行。
# この変数が設定されている間だけ従量課金になり、消せば元のサブスクに戻る。
export ANTHROPIC_BASE_URL=https://api.kunavo.com
export ANTHROPIC_AUTH_TOKEN=sk-kn-...

# 補助的な処理を一番安いモデルに逃がす 1 行（毎セッション効く）
export ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5

料率はカタログからそのまま読み込んでいます: Claude Sonnet 4.6 は 1M トークンあたり $1.20 / $6.00、Claude Haiku 4.5 は $0.40 / $2.00。前払い残高から引かれるので、使わなかった月の請求は 0 です。サブスクと従量課金のどちらが安いか、1 ステップあたりの実額と損益分岐点は Claude Code 料金 で計算しています。ウィンドウの仕組みそのものは Claude Pro の制限、 どのモデルを既定にするかは Opus と Sonnet の違い にあります。

精度が上がる頼み方、下がる頼み方

最後に、使い方の巧拙が一番出る部分です。ファイル名とパスを添えると探索に使うトークンが減り、結果が速く正確になります —「バリデーションを直して」より「src/api/user.ts のバリデーションを zod に置き換えて」。

そして、大きな依頼を 1 回で投げないこと。変更 → テスト → 次の変更と区切れば、失敗しても戻る場所がはっきりします。エラーが出たときの 切り分けは Claude Code の 401 エラー など個別のページにまとめてあります。

よくある質問