Claude Code最初の30分チェックリスト：初心者が安全に始める手順

最初の30分は「大きく作る時間」ではなく「安全に勝つ時間」

Claude Codeを初めて開いた人がつまずく理由は、ツールが難しいからだけではありません。最初の依頼が大きすぎる、権限の境界があいまい、確認コマンドを決めていない、作業メモを残さない。この4つが重なると、30分後に「何か触ったけれど、何が良くなったのか分からない」という状態になります。

Claude Codeは、公式の概要で説明されている通り、コードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと連携できるエージェント型のコーディングツールです。便利な反面、初心者の最初の仕事は「任せること」ではなく「安全に任せる枠を作ること」です。

この記事では、Claude Codeの最初の30分を、リポジトリ理解、作業範囲の決定、検証、次回への引き継ぎに分けます。より細かい最初のタスク選びはClaude Code First Task Runbookを、リポジトリの見取り図作りはRepo Map First Passを、作業後のメモはSession Handoff Templateを合わせて読むと流れがつながります。

初心者が最初に覚える用語

「リポジトリ」は、アプリのコード、設定、ドキュメント、テストがまとまった作業フォルダです。「エージェント」は、指示を受けて調査、編集、検証まで進める相棒のような実行役です。「権限」は、Claude Codeにどのファイルを読ませるか、どのコマンドを許可するかという安全柵です。公式のpermissionsドキュメントでは、読み取り、編集、Bashコマンドなどを細かく制御できることが説明されています。

「CLAUDE.md」は、Claude Codeに毎回読ませるプロジェクト用の説明書です。コーディング規約、禁止事項、検証コマンド、レビュー観点を書いておくと、毎回長い説明を貼らずに済みます。公式のmemoryドキュメントも、プロジェクト指示と記憶の考え方を確認するのに役立ちます。

「検証」は、作業が正しいと判断するための証拠です。npm run build、npm test、git diff、画面確認、ログ確認などが該当します。Claude Codeに「直して」と頼むだけではなく、「このコマンドで確認して」とセットで頼むと、成果がレビューしやすくなります。

30分で残すべき成果物

最初の30分で狙う成果は、巨大な機能追加ではありません。次の4つが残れば十分です。

成果物	内容	なぜ重要か
リポジトリ地図	入口ファイル、主要ディレクトリ、実行コマンド	迷子のまま編集しないため
小さな成果	1つの失敗テストの説明、1つの文言修正、1つの再現手順	レビュー可能なサイズにするため
検証メモ	実行したコマンド、成功、失敗、未確認点	「動いたはず」を避けるため
次回の一手	次に頼む最小タスク	2回目のセッションを速くするため

ここで大切なのは、Claude Codeの能力を試すことより、作業の型を作ることです。型があれば、バグ修正、記事更新、テスト追加、設定整理などに横展開できます。

0分から5分：境界を先に決める

最初の依頼は実装ではなく調査にします。初心者ほど、いきなり「この機能を作って」と言いたくなりますが、その前にClaude Codeが何を読んだのか、何を危険と判断したのかを見ます。

Read this repository and tell me:
1. the main entry points
2. the commands I will probably need
3. the risky directories I should avoid first
4. the safest high-value first task for a 30-minute session

Do not edit files yet. Give me a short plan and the proof command you would run.

このプロンプトの狙いは、入口、コマンド、危険箇所、最小タスクを同時に出させることです。公式のcommon workflowsにも、調査、修正、テスト、コミットのような段階的な進め方が紹介されています。最初の5分は、書く時間ではなく、読む時間として使います。

5分から20分：1つだけ選ぶ

候補が出たら、作業対象を1つに絞ります。初心者に向いているオンボーディング用途は、次の4つです。

1つ目は、失敗しているテストの説明です。Claude Codeに「原因を推測して」ではなく「どのテストが、どの入力で、どの期待値とずれているかを説明して」と頼みます。まだ修正しなくても、失敗の形を言語化できれば成果です。

2つ目は、既存画面の小さな文言やCTA修正です。たとえばボタン文言、説明文、リンク先の確認です。収益導線があるサイトなら、/products/や/training/への導線が消えていないかまで確認します。

3つ目は、バグ報告の再現手順化です。「ログイン後にたまに落ちる」ではなく、環境、操作、期待結果、実際の結果、関連ログに分けてメモ化します。Claude Codeに再現条件を整理させると、実装前の不確実性が下がります。

4つ目は、CLAUDE.mdの最小ドラフトです。最初から完璧なチーム規約を書く必要はありません。禁止コマンド、ビルドコマンド、テストコマンド、レビューで見る観点だけを書けば、次回のセッションが安定します。設定ファイルの考え方は公式のsettingsドキュメントで確認できます。

コピペで使える確認スクリプト

Mac、Linux、WSLなら、次のスクリプトをリポジトリ直下で実行すると、最初の30分で必要な基本情報を集められます。ファイルは変更しません。

#!/usr/bin/env bash
set -euo pipefail

echo "== location =="
pwd

echo "== git status =="
git status --short

echo "== package scripts =="
if [ -f package.json ]; then
  node -e "const p=require('./package.json'); console.log(p.scripts || {})"
else
  echo "package.json not found"
fi

echo "== likely docs =="
find . -maxdepth 2 \( -name 'README*' -o -name 'CLAUDE.md' -o -name 'AGENTS.md' \) -print

echo "== recent changed files =="
git diff --name-only

Windows PowerShellで始める場合は、こちらを使います。

$ErrorActionPreference = "Stop"

Write-Host "== location =="
Get-Location

Write-Host "== git status =="
git status --short

Write-Host "== package scripts =="
if (Test-Path package.json) {
  node -e "const p=require('./package.json'); console.log(p.scripts || {})"
} else {
  Write-Host "package.json not found"
}

Write-Host "== likely docs =="
Get-ChildItem -Force -File -Include README*,CLAUDE.md,AGENTS.md -Recurse -Depth 2 |
  Select-Object -ExpandProperty FullName

Write-Host "== recent changed files =="
git diff --name-only

作業後の引き継ぎメモは、次のJavaScriptをfirst-30-handoff.mjsとして保存して実行できます。中身を書き換えるだけで、毎回同じ形式のメモを出せます。

const handoff = {
  outcome: "Adjusted one CTA sentence and confirmed the product/training links stayed visible.",
  verified: ["git status --short", "npm run build"],
  notVerified: ["Mobile visual check"],
  nextStep: "Open the page locally and inspect the CTA area at 390px width.",
};

for (const [label, value] of Object.entries(handoff)) {
  const body = Array.isArray(value) ? value.map((item) => `- ${item}`).join("\n") : value;
  console.log(`## ${label}\n${body}\n`);
}

権限をチームでそろえる場合は、最初から広く許可しすぎない設定を使います。次はJSONとしてそのまま読める例です。実際のコマンド名は自分のリポジトリに合わせてください。

{
  "permissions": {
    "allow": [
      "Bash(git status *)",
      "Bash(npm run build)",
      "Bash(npm test *)"
    ],
    "deny": [
      "Bash(git push *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

よくある失敗例と避け方

失敗例1は、最初から「全部直して」と頼むことです。Claude Codeは広い範囲を調べられますが、初回に広すぎる依頼を出すと、確認すべき差分も広がります。避け方は、1ファイル、1テスト、1画面、1リンクのどれかに絞ることです。

失敗例2は、bypassPermissionsのような強い権限を、普段使いの作業ツリーで使うことです。公式のpermissionsページでも、強い権限モードは隔離された環境で使うべきものとして説明されています。初心者は、読み取り中心、編集は都度確認、削除やpushは禁止から始めるのが安全です。

失敗例3は、検証コマンドを最後まで決めないことです。「たぶん動く」はレビューで通りません。作業前に「成功条件はnpm run buildが通ること」「記事ならdescriptionが120文字以内」「コードフェンスが閉じていること」のように書きます。

失敗例4は、秘密情報を読ませることです。.env、APIキー、顧客データ、未公開の契約情報は、必要がない限り読ませません。Claude Codeのsecurityドキュメントを読み、読み取り禁止のルールを先に入れておくと事故を減らせます。

失敗例5は、セッション終了時にメモを残さないことです。次回また同じ調査から始まり、時間を失います。作業後は、変更点、確認した証拠、未確認点、次の最小タスクを4行で残します。検証メモの型はVerification Receipt Workflowにもまとめています。

30分の実行手順

0分から5分は、リポジトリ地図を作ります。Claude Codeに調査だけを頼み、編集しないよう明示します。出てきたコマンドは、自分でも読んで危険なものがないか確認します。

5分から10分は、候補タスクを1つ選びます。選ぶ基準は、戻しやすいこと、検証しやすいこと、ユーザーやチームに意味があることです。たとえば、記事のリンク修正、失敗テストの原因説明、エラーログの整理は良い候補です。

10分から20分は、作業を実行します。この時間は短いので、途中で別の問題を見つけても広げません。「それは次回の候補」としてメモに逃がします。

20分から27分は、検証します。git status --shortで差分の有無を確認し、プロジェクトに合ったビルドやテストを1つ実行します。画面の変更ならスクリーンショットやローカル確認も証拠になります。

27分から30分は、引き継ぎを書きます。ここでメモを残すと、次回のClaude Codeセッションだけでなく、人間のレビューも速くなります。

次に進む導線

個人で練習するなら、まず無料チートシートで安全な依頼文と確認コマンドを手元に置くのが早いです。自分のリポジトリに合わせたプロンプト、CLAUDE.md、レビュー観点をまとめたい場合はClaudeCodeLabの教材とテンプレートを使ってください。チームで権限、hooks、レビュー証跡、オンボーディング研修まで整えるならClaude Code研修・相談が次の選択肢です。

この記事で紹介した内容を実際に試した結果、最初から実装を頼むより、先にリポジトリ地図、禁止事項、検証コマンド、引き継ぎメモを決めた方が、30分後の差分が小さく、レビューが速くなりました。特に「編集しないで調査だけ」と最初に書くこと、最後にgit status --shortを確認することは、初心者でもすぐ効果が出る安全策でした。