Claude Code 最初の30分でやること一覧|印刷して使えるチェックリスト
Claude Codeを入れた最初の30分でやることを、印刷して上から潰せるチェックリストに。インストール確認・初プロンプト・権限設定・小タスク・コミットを表とコマンドで。
「Claude Code、とりあえず入れた。で、最初に何をやればいいんだっけ?」
僕が初めて起動したときの第一声がこれでした。ドキュメントは読んだ。コマンドも打てる。なのに最初の一手が決まらず、気づけば30分、空のターミナルを眺めて何も生み出していませんでした。
このページは、そのときの僕に渡したかったものです。物語でも理屈でもなく、上から順にチェックを入れていくだけの確認リスト。印刷してデスクに貼るか、手元のメモに丸ごとコピーして、終わった項目に印を付けながら使ってください。読み物が欲しい人向けの導線は最後に置いておきます。
この記事の要点
- 最初の30分は「大きく作る時間」ではなく、インストール確認・初プロンプト・権限設定・小タスク1個・コミットを上から潰す時間。
- このページは確認リストに徹する。時系列の体験談は最初の30分でやったこと、寄り道なしの導入手順は5分クイックスタート、最初の1タスクの手順は最初の1タスク手順書へ。
- 各フェーズに「完了の合図」を1行だけ決める。決めないと30分後に成果が残らない。
- 権限は最初から広げない。読み取り中心、編集は都度確認、削除・push・本番DBは最初は全部止める。
- 仕上げに
git statusとgit diffを見て、最後にコミット1個を残せたら30分は成功。
印刷用:30分チェックリスト全体像
まずは全体を1枚で。各フェーズに時間の目安と「これが終わったら次へ進む合図」を付けました。細かい手順は後ろのセクションで1つずつ潰します。
| 時間 | フェーズ | やること | 完了の合図 |
|---|---|---|---|
| 0–5分 | インストール確認 | バージョン表示・ログイン・起動 | claude --version が数字を返す |
| 5–10分 | 初プロンプト | 調査だけ頼む(編集禁止と明示) | 入口・コマンド・危険箇所が箇条書きで出る |
| 10–15分 | 権限設定 | allow/deny を最小で書く | push と .env 読み取りが禁止になっている |
| 15–25分 | 小タスク1個 | 戻せる作業を1つだけ実行 | 差分が1ファイル〜数ファイルに収まる |
| 25–30分 | 確認とコミット | diff を見てコミット | コミット1個と検証メモが残る |
この表の右端「完了の合図」が一番大事です。ここが曖昧だと、30分後に「何か触ったけど何が良くなったのか分からない」状態に逆戻りします。各フェーズは合図が出るまで次へ進まない、と決めてください。
0–5分:インストール確認チェックリスト
まず、本当に動く状態になっているかを確かめます。「入れたつもり」で初プロンプトに進むと、エラーの原因がインストールなのか依頼文なのか切り分けられなくなります。
- ターミナル(Windowsは PowerShell かGit Bash)を開いた
-
claude --versionがバージョン番号を返した - 作業したいリポジトリのフォルダに移動した
-
claudeで起動し、初回はログインを済ませた - ログイン後、対話画面が表示された
未インストールなら、公式の概要ページに各環境の入れ方が載っています。ネイティブインストールはmacOS / Linux / WSLなら curl -fsSL https://claude.ai/install.sh | bash、Windows PowerShellなら irm https://claude.ai/install.ps1 | iex の1行です。Claude Codeは、公式の言葉を借りれば「コードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと連携するエージェント型のコーディングツール」。だからこそ、最初に範囲を決めずに任せると事故ります。
ここでのゴールは小さく、「数字が返る・対話画面が出る」だけ。これが確認できたら次へ進みます。
5–10分:初プロンプトのチェックリスト
最初の依頼は実装ではなく調査にします。初心者ほど「この機能を作って」と言いたくなりますが、その前にClaude Codeが何を読み、何を危険と判断したかを見ておくと、後の作業がぐっと安全になります。
- 最初の依頼に「まだ編集しないで」と明記した
- 入口ファイル・主要コマンド・危険なディレクトリを一度に聞いた
- 返ってきたコマンドを自分の目でも読んで、危ないものがないか確認した
- 30分でやる「小さくて戻せる」候補を出させた
僕が毎回貼っている調査用の依頼文がこれです。下のブロックを丸ごとコピーして使えます。
このリポジトリを読んで、次を教えてください。
1. 主要な入口ファイル
2. 僕がたぶん使うことになるコマンド
3. 最初は触らない方がいい危険なディレクトリ
4. 30分で終わる、戻しやすくて価値のある最初の小タスク1つ
まだファイルは編集しないでください。短い計画と、あなたなら実行する確認コマンドだけ先に出してください。
このプロンプトの狙いは、入口・コマンド・危険箇所・最小タスクを同時に出させること。最初の5分は書く時間ではなく、地図を作る時間です。リポジトリの見取り図づくりだけを深掘りしたいならリポジトリ地図の作り方も合わせてどうぞ。
10–15分:権限設定チェックリスト
ここが、初心者が一番すっ飛ばして一番事故るフェーズです。Claude Codeは賢いですが、賢さと安全は別物。最初に柵を作ってから走らせます。
- 読み取り中心、編集は都度確認から始めると決めた
-
git pushを deny に入れた -
.envとその系列ファイルの読み取りを deny に入れた - 削除や本番DB操作を許可リストに入れていないことを確認した
- 普段の作業ツリーで
bypassPermissionsを使っていない
公式の権限ドキュメントでは、ルールが「deny → ask → allow」の順で評価され、deny が常に最優先だと説明されています。つまり「念のため禁止」を1つ書いておけば、allowが何であろうとそこは止まる、ということ。最初の30分は、この「念のため禁止」を厚めに置くのが正解です。
設定例はこのあとのコマンドセクションにまとめました。なお bypassPermissions(全プロンプトを飛ばすモード)は、公式でも「コンテナやVMなど隔離された環境でだけ使うこと」と明記されています。初日の本番リポジトリで使うものではありません。プラン段階だけ調べたいなら、編集しない plan モードから入るのも手です。
15–25分:最初の小タスク チェックリスト
候補が出たら、作業対象を1つだけに絞ります。複数同時はこの時間では確実に破綻します。初日に向くのは、次のような戻しやすい仕事です。
- 失敗しているテストを「どの入力で、どの期待値とずれているか」言語化させた
- 既存画面の小さな文言やボタンの表記を1つ直した
- バグ報告を「環境・操作・期待・実際・関連ログ」に整理した
-
CLAUDE.mdの最小ドラフト(禁止コマンド・ビルド・テスト・レビュー観点)を1枚書いた - 途中で別の問題を見つけても広げず、「次回の候補」とメモに逃がした
タスク選びの基準はシンプルに3つ。戻しやすい・検証しやすい・誰かに意味がある。この3つを満たすなら、リンク修正でもテストの原因説明でも十分な成果です。逆に「認証まわりを全部リファクタ」みたいな初手は、戻すのも確認するのも重すぎてアウト。
依頼文の型、git diff の見方、コミットまでをもっと丁寧に追いたい人は最初の1タスク手順書に細かく書いています。このページではあくまで「チェックを入れる」ところまで。
25–30分:確認とコミットのチェックリスト
最後の5分で、やったことを証拠として残します。「たぶん動く」はレビューを通りません。
-
git status --shortで差分の範囲を確認した -
git diffを自分の目で読んだ(AIの説明だけで信じない) - プロジェクトに合うビルドかテストを1つ実行した
- 画面変更ならローカルで見た、またはスクショを撮った
- コミット1個を、何をしたか分かるメッセージで残した
- 「変更・確認済み・未確認・次の一手」を4行でメモした
差分が想定より広い、.env や設定ファイルに手が入っている、知らないファイルが消えている——このどれかに当てはまったら、コミットせずに一度止まります。広すぎる差分は、ほぼ確実に依頼が大きすぎたサインです。検証メモの型をテンプレ化したいなら検証メモのワークフロー、次回への引き継ぎはセッション引き継ぎテンプレートが使えます。
コピペで使えるコマンド集
ここはコピペ用です。まず、最初の30分で必要な基本情報を集める確認スクリプト。ファイルは一切変更しません。macOS / Linux / WSL / Git Bashで、リポジトリ直下に置いて実行します。
#!/usr/bin/env bash
set -euo pipefail
echo "== Claude Code のバージョン =="
claude --version || echo "claude が見つかりません。先にインストールしてください。"
echo "== 今いる場所 =="
pwd
echo "== git の状態 =="
git status --short
echo "== package.json のスクリプト =="
if [ -f package.json ]; then
node -e "const p=require('./package.json'); console.log(p.scripts || {})"
else
echo "package.json はありません"
fi
echo "== 説明書っぽいファイル =="
find . -maxdepth 2 \( -name 'README*' -o -name 'CLAUDE.md' -o -name 'AGENTS.md' \) -print
echo "== 最近変更されたファイル =="
git diff --name-only
次に、最初に入れておく権限設定の最小例です。.claude/settings.json に置きます。コマンド名は自分のリポジトリに合わせて調整してください。要点は、よく使う安全なコマンドだけ allow し、push と秘密ファイルは deny で確実に止めることです。
{
"permissions": {
"allow": [
"Bash(git status *)",
"Bash(git diff *)",
"Bash(npm run build)",
"Bash(npm test *)"
],
"deny": [
"Bash(git push *)",
"Read(.env)",
"Read(.env.*)"
]
}
}
最後に、30分の締めに残す引き継ぎメモのテンプレ。first-30-handoff.mjs として保存し、中身を書き換えて実行すると、毎回そろった形式で出力されます。
const handoff = {
やったこと: "ボタンの文言を1つ直し、商品・研修リンクが消えていないことを確認した。",
確認済み: ["git status --short", "npm run build"],
未確認: ["スマホ表示でのレイアウト"],
次の一手: "ローカルで開いて、幅390pxでボタン周りを見る。",
};
for (const [見出し, 値] of Object.entries(handoff)) {
const 本文 = Array.isArray(値) ? 値.map((x) => `- ${x}`).join("\n") : 値;
console.log(`## ${見出し}\n${本文}\n`);
}
よくある質問
Q. このチェックリストは初回だけ使うものですか? いいえ。新しいリポジトリに入るたびに使えます。インストール確認は飛ばしてよくなりますが、「調査→権限→小タスク→コミット」の型は2回目以降も効きます。むしろ慣れてからの方が、雑に大きく頼みがちなので柵が役立ちます。
Q. 物語版・導入版・このリストの違いは? このページは「上から潰す確認リスト」に徹しています。僕の時系列の体験談が読みたいなら最初の30分でやったこと、とにかく最短で動かしたいなら5分クイックスタート、最初の1タスクを手取り足取り進めたいなら最初の1タスク手順書が向いています。
Q. 最初から bypassPermissions で楽をしたら駄目ですか?
本番の作業ツリーでは避けてください。公式でも隔離環境専用とされています。最初の30分は読み取り中心で十分に成果が出ます。速さは、慣れてから安全と分かった操作だけ allow に格上げして稼ぐものです。
Q. 小タスクが思いつきません。
初プロンプトの調査結果に候補を出させてください。それでも迷うなら、リンク切れの修正、失敗テストの原因説明、エラーログの整理、CLAUDE.md の最小ドラフトのどれか。どれも戻しやすく、検証も軽いので初日向きです。
Q. 30分で動くものが完成しなくても大丈夫? 大丈夫です。このセッションの成果物は「動く大機能」ではなく、リポジトリ地図・小さな差分1つ・検証メモ・次の一手。コミット1個と4行のメモが残れば、その30分は成功です。
実際に試した結果
このチェックリストを自分のサイトのリポジトリで実際に上から回してみました。一番効いたのは、地味ですが「初プロンプトで必ず『まだ編集しないで』と書く」ことと、「権限の deny を先に厚く置く」ことの2つでした。
調査だけ先にさせると、Claude Codeが触ろうとした危険ディレクトリが事前に分かり、小タスクの選び方がはっきりします。deny を先に書いておくと、依頼が少し大きすぎたときも push や .env 読み取りの手前で勝手に止まる。結果、最後の git diff がいつも小さく収まり、レビューが速くなりました。
賢いAIを探すより、転んでもケガしない順番を1枚のリストにしておく。遠回りに見えて、これが初日の30分を一番ムダにしない方法でした。慣れてきたら、自分用のプロンプトや CLAUDE.md、レビュー観点をClaudeCodeLabの教材とテンプレートで整えると、2回目以降がさらに速くなります。
無料PDF: Claude Code はじめてのチートシート
まずは無料PDFで基本コマンドと最初の使い方をまとめて確認してください。登録後はそのままテンプレート集や導入相談にも進めます。
スパムは送りません。登録情報は厳重に管理します。
Claude Codeを仕事で使える形にしませんか?
まず無料PDFで基本を固め、繰り返し使う作業はGumroad教材へ、チーム導入や権限設計は導入相談へ進めます。
この記事を書いた人
Masa
Claude Codeの実務活用、導入設計、収益導線改善を検証しているエンジニア。10言語の技術メディアを運営中。
関連書籍・参考図書
この記事のテーマに関連する書籍を楽天ブックスで探せます。
※ 当サイトは楽天市場のアフィリエイトプログラムに参加しています。上記リンクから商品をご購入いただくと、運営者に紹介料が支払われる場合があります。
関連記事
Claude Codeのコマンドを覚えたのに手が止まる人へ、最初の一手を安全に出す型
コマンド表を覚えたのに何を頼めばいいか分からない。読むだけで終わらず、初めての一手を安全に通すまでの手順とプロンプト雛形を紹介します。
Claude Codeで既存リポジトリの最初の1編集を安全にする導入手順
他人が書いた既存コードにClaude Codeを入れる初日に、触らせる範囲・禁止領域・検証コマンドを先に決めて事故を防ぐ実践手順。
Claude Codeに最初の1タスクを任せる依頼文の書き方
Claude Codeへの最初の依頼で事故らないために、目的・触ってよい範囲・検証・戻し方を1枚にまとめる依頼文の型を、コピペ例つきで紹介します。