SaaS・IT

【2026年最新】Claude Code新規プロジェクト立ち上げ7手順

Q: Claude Codeの新規プロジェクトでは、最初に何を頼むべきですか？

最初は実装ではなく、リポジトリ調査、検証コマンドの確認、CLAUDE.md作成、権限設計を頼むのがおすすめです。いきなり大きな機能を作るより、作業ルールと検証ループを先に整える方が安定します。

Q: /initで作ったCLAUDE.mdはそのまま使えますか？

そのまま使い始めることはできますが、短く整理するのが実務向きです。公式ドキュメントでは/initがコードベースを分析してスターターのCLAUDE.mdを作ると説明されていますが、最終的には人間がプロジェクト固有のルールに絞るべきです。

Q: bypassPermissionsを使えば立ち上げは速くなりますか？

速くなる場面はありますが、初回の標準設定にするのはおすすめしません。公式permissionsでは、bypassPermissionsは隔離されたコンテナやVMのような環境で使うべきだと説明されています。通常のローカル開発ではdefaultやplanから始める方が安全です。

公開 2026年6月24日更新 2026年7月27日

Claude Codeを使って新規プロジェクトをゼロから立ち上げる7ステップを解説。技術選定からCI/CD、テスト戦略まで現場エンジニアが今日から使える実践ガイド。

結論：Claude Codeで新規プロジェクトを立ち上げるなら、最初の1時間は「実装」ではなく、実行環境・CLAUDE.md・権限・検証コマンド・MCP・hooksを決める時間に使うのがいちばん安全です。

要点1：2026年7月7日時点の公式ドキュメントでは、Claude CodeはターミナルCLI、Web、デスクトップ、VS Code、JetBrains IDE、Slack、CI/CDで利用できると案内されています。ローカル環境が必要な新規開発はCLI、手元に環境がないリポジトリ調査や並列タスクはWebが向いています。
要点2：新規プロジェクトでは、/initで生成するCLAUDE.md、/permissionsで管理する権限、.claude/settings.jsonの共有設定を最初に固定します。ここを後回しにすると、後半で「なぜこのコマンドを実行したのか」を追跡しにくくなります。
要点3：最初の成功条件は「アプリが完成した」ではなく、「Claude Codeが自分でテスト・ビルド・lintを実行し、失敗時に戻れる運用ができた」です。

対象読者：Claude Codeで新規Webアプリ、社内ツール、API、バッチ、SaaSプロトタイプを立ち上げたい開発者・PM・技術責任者。

今日やること：既存または空のリポジトリでclaudeを起動し、まず/init、/permissions、検証コマンドの3点だけを整えてください。

事例区分：実装パターン解説。本記事は、Claude Code公式ドキュメントで確認できる機能をもとに、新規プロジェクト立ち上げ時の標準手順として再構成したものです。特定企業の導入成果や未公開数値は扱いません。

「Claude Codeで新規プロジェクトを始めるなら、最初に何を作らせればいいですか？」

この質問、開発チームの導入相談でかなり頻繁に出ます。正直に言うと、最初に「ログイン画面を作って」「Next.jsで管理画面を作って」と頼むと、うまくいく時もあります。でも、チーム開発ではその前に決めるべきことが多いんです。どのコマンドで検証するのか。どのファイルを触ってよいのか。環境変数はどこまで見せるのか。PR前に何を証跡として残すのか。

私が最初に見るのは、コードそのものより「Claude Codeが迷わず作業できるレールがあるか」です。人間の新メンバーにREADME、開発環境、レビュー基準、テスト手順を渡すのと同じで、Claude Codeにもプロジェクトの作法を渡す必要があります。

この記事では、Claude Codeの新規プロジェクト立ち上げを7手順に分けて解説します。公式ドキュメントで確認できる/init、CLAUDE.md、/permissions、settings、MCP、hooks、plan modeを使い、現場でそのまま使えるHTML記事としてまとめました。

動作環境と前提：2026年7月時点で確認すること

まず、この記事の前提を固定します。Claude Codeは更新が速いので、この記事では2026年7月7日に公式ドキュメントを確認した範囲だけを扱います。公式のAdvanced setupでは、Claude Codeの対応環境としてmacOS 13.0以降、Windows 10 1809以降またはWindows Server 2019以降、Ubuntu 20.04以降、Debian 10以降、Alpine Linux 3.19以降、4GB以上のRAM、インターネット接続、Bash/Zsh/PowerShell/CMDが案内されています。

Quickstartでは、macOS・Linux・WSL向けのNative Install、Homebrew、WinGetなどの導入方法が示されています。npmで入れる方法も公式のAdvanced setupにありますが、チームで手順書を作るならNative Installかパッケージマネージャーのどちらを標準にするか、最初に決めておくのが実務的です。

確認項目	新規プロジェクトでの判断	確認コマンド例
Claude Code本体	チーム内でインストール方式をそろえる。HomebrewやWinGetは自動更新ではない点も運用に入れる。	`claude --version`
GitHub連携	Web版で作業するならGitHubリポジトリが必要。新規なら空リポジトリを先に作る。	`gh auth status`
検証コマンド	最初から`test`、`lint`、`typecheck`、`build`の有無を明示する。	`npm test` / `npm run build`
権限モード	初回はplanまたはdefaultを推奨。自動承認は隔離環境でだけ検討する。	`/permissions`

ここで大事なのは、インストール手順を暗記することではありません。新規プロジェクトの「標準環境」を決めることです。個人開発なら多少ばらついても進みますが、チームでClaude Codeを使うなら、バージョン確認、権限、検証コマンドの3つは最初に固定した方が後から楽になります。

手順1：CLI・Web・IDEのどこで始めるかを決める

Claude Codeは、ターミナルCLIだけのツールではありません。QuickstartではCLIの基本手順が説明され、Web quickstartではブラウザやモバイルからクラウド環境で実行する方法が説明されています。Web版はAnthropic管理のクラウドVMでリポジトリをcloneし、作業後にブランチをpushする流れです。一方、ローカルCLIは自分のマシン上の設定、ツール、ネットワーク、ローカルDB、社内VPNなどを使いやすいのが強みです。

新規プロジェクトの立ち上げでは、次のように分けると判断しやすいです。

実行場所	向いているケース	注意点
Terminal CLI	ローカルDB、Docker、社内ツール、既存の秘密情報に依存する開発。	ローカルの権限設計を誤ると、意図しないファイル変更やコマンド実行が起きやすい。
Claude Code on the web	GitHub上のリポジトリをクラウドで触りたい、複数タスクを並列で進めたい、ローカルcheckoutなしで調査したい。	公式ドキュメント上、開始にはGitHubリポジトリが必要。新規なら空リポジトリを先に作る。
IDE連携	人間がエディタで確認しながら差分を細かく見たいフロントエンドやUI実装。	IDE連携だけに寄せず、CLIで再現できる検証コマンドを残す。

最初のおすすめは、ローカルCLIでプロジェクトの基礎設定を作り、その後にWebやIDEを追加する流れです。理由はシンプルで、CLAUDE.md、.claude/settings.json、.mcp.jsonなどのプロジェクト設定を先に置けるからです。設定が整ってからWeb版を使うと、クラウド側でも作業の前提が揃いやすくなります。

cd ~/projects/expense-review-app
claude

# 最初に聞く質問例
このリポジトリの現状を読み、まだ決まっていない開発前提を箇条書きで整理してください。
不足している情報があれば、最初に質問してから作業を開始してください。

この段階では、まだ「アプリを作って」とは言いません。まずClaude Codeに現状を調査させます。公式Best practicesでも、いきなり実装に入るのではなく、探索、計画、実装を分ける流れが推奨されています。新規プロジェクトでは特に、最初の探索でフレームワーク、パッケージ管理、テスト方針、デプロイ先、秘密情報の扱いを洗い出しておくと後戻りが減ります。

関連する基本設計は、Claude Code法人導入ガイドと、チーム展開に焦点を当てたClaude Codeチーム展開の実践記事もあわせて読むと整理しやすいです。

手順2：空リポジトリに最小の足場を作る

新規プロジェクトでよくある失敗が、「Claude Codeに全部決めてもらう」ことです。これは速く見えますが、後から人間がレビューしにくくなります。最初の足場は、人間が決める部分とClaude Codeに任せる部分を分けましょう。

人間が決めるべきなのは、プロダクトの境界です。たとえば「管理画面を作る」ではなく、「社内の申請データをCSVで取り込み、承認状態を一覧し、担当者がコメントを残せる最小アプリ」と書きます。Claude Codeが決めてよいのは、既存の技術選定や規約に沿ったファイル分割、テスト追加、実装順序です。

まだフレームワークが未定なら、最初のプロンプトは実装依頼ではなく比較依頼にします。

新規の社内ツールを作ります。
要件は以下です。

- 社内ユーザーだけが使う
- CSVをアップロードして一覧表示する
- 承認ステータスとコメントを保存する
- 最初は10名程度の利用を想定する
- 将来はSSOと監査ログを追加したい

Next.js、FastAPI + React、Railsの3案で比較してください。
比較軸は、初期実装の速さ、テストしやすさ、認証追加のしやすさ、運用負荷です。
仮定した点は必ず「仮定」と明記してください。
不足している情報があれば、最初に質問してから作業を開始してください。

この時点でClaude Codeに聞きたいのは「正解」ではなく「選定理由」です。特にPMや技術責任者が関わる場合、後から「なぜこの構成にしたのか」を説明できることが重要です。技術選定の論点は、Claude Codeで技術選定とアーキテクチャ比較を行う手順にも整理されています。

足場を作る時は、Claude Codeに「最小構成」と「検証コマンド」を同時に出させます。実装だけを依頼すると、テストが後回しになりやすいからです。

選定した構成で、最小のプロジェクト足場を作る計画を出してください。

必須条件:
- 初回コミット前に動く検証コマンドを用意する
- READMEに起動手順を書く
- サンプルデータを1つ入れる
- テストまたは型チェックのどちらかを必ず実行可能にする
- まず計画だけを出し、私の承認後にファイル変更してください

ここで「まず計画だけ」と明記するのがポイントです。Claude Codeのpermission modeには、plan modeがあります。公式permissionsの説明では、plan modeはファイルを読み、読み取り専用のシェルコマンドで探索するが、ソースファイルは編集しないモードとして説明されています。新規プロジェクトの初期設計では、実装前にplan modeで一度止めるだけで、かなりレビューしやすくなります。

手順3：`/init`でCLAUDE.mdを作り、短く保つ

Claude Codeの新規プロジェクト立ち上げで最も重要なファイルがCLAUDE.mdです。公式memoryドキュメントでは、プロジェクトのCLAUDE.mdは./CLAUDE.mdまたは./.claude/CLAUDE.mdに置けると説明されています。また、/initを実行すると、Claude Codeがコードベースを分析し、ビルドコマンド、テスト手順、プロジェクト規約を含むスターターのCLAUDE.mdを生成できます。

実際の運用では、/initで作ったあとに人間が削るのが大事です。公式Best practicesでも、CLAUDE.mdは毎セッション読み込まれるため、広く適用されることだけを書くべきで、長すぎると本当に守ってほしい指示が埋もれると説明されています。目安として、公式memoryドキュメントでは1つのCLAUDE.mdを200行未満にすることが推奨されています。

/init

/init後に追加したいのは、次のような「Claude Codeがコードから推測できない情報」です。

ローカル起動に必要な環境変数名。ただし値は書かない。
テスト実行時に必要な外部サービスやモックの使い方。
このプロジェクト固有の命名規則、ディレクトリ責務、避けたい実装方針。
PR前に必ず実行するコマンド。
触ってはいけない生成ファイル、マイグレーション、設定ファイル。

逆に、一般的なプログラミング知識や長いAPI仕様はCLAUDE.mdに入れない方がよいです。リンクや別ファイルに逃がし、必要な時だけ読ませる方がコンテキストを節約できます。

# CLAUDE.mdに入れる内容の例

## Project commands
- Install: npm ci
- Typecheck: npm run typecheck
- Test: npm test
- Build: npm run build

## Development rules
- API handlers live under src/server/api/.
- UI components live under src/components/.
- Do not edit generated files under src/generated/.
- Before proposing completion, run typecheck and the smallest relevant test.

## Security
- Never print .env values.
- Use .env.example for required variable names only.
- Ask before changing auth, billing, or database migration files.

このファイル設計をさらに深掘りしたい場合は、Claude CodeのCLAUDE.md設計ガイドが関連します。新規プロジェクトでは、この記事の手順3とあわせて読むと、初回のCLAUDE.mdを過剰に膨らませずに済みます。

手順4：権限モードとsettingsを先に決める

Claude Codeは、ファイルを読む、コマンドを実行する、ファイルを書き換えるという強い操作ができます。だからこそ、権限設計は「後で」ではなく「最初」にやります。公式permissionsドキュメントでは、読み取り専用操作は承認不要、Bashコマンドやファイル変更は承認が必要という基本が示されています。また、/permissionsで許可・確認・拒否ルールを管理できます。

公式permissionsでは、deny、ask、allowの順で評価されることも明記されています。つまり、広いdenyルールは狭いallowルールより強く働きます。この挙動を理解せずにBash全体を雑にdenyすると、Claude Codeが必要な検証コマンドを実行できなくなることがあります。

新規プロジェクトでは、次の方針で始めるのが現実的です。

フェーズ	推奨モード	理由
初回調査	`plan`または`default`	読み取り中心で、意図しない編集を避ける。
小さな差分の実装	`default`または`acceptEdits`	編集承認を確認しながら、繰り返し作業の摩擦を下げる。
隔離環境の検証	`auto`または限定的な自動承認	公式上autoはresearch preview。安全確認を前提に使う。
本番に近い環境	`default`中心	破壊的操作、秘密情報、外部送信を人間が確認する。

bypassPermissionsは便利に見えますが、公式permissionsでは、コンテナやVMのような隔離環境でだけ使うべきだと説明されています。新規プロジェクトの初日からこれを標準にするのは避けた方がよいです。

/permissions

チームで共有する設定は、公式settingsドキュメントに従って.claude/settings.jsonに置きます。個人だけの設定は.claude/settings.local.jsonです。公式settingsでは、Managed、CLI引数、Local、Project、Userという優先順位も示されています。新規プロジェクトでは、チームに共有するものと個人の実験設定を混ぜないことが重要です。

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(npm test)",
      "Bash(npm run typecheck)",
      "Bash(npm run build)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)",
      "Edit(.env*)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl * | bash)",
      "Read(.env)"
    ]
  }
}

上の設定はあくまでサンプルです。実際には、プロジェクトのパッケージマネージャー、CI、開発環境に合わせて調整してください。権限設計をさらに詳しく見たい場合は、Claude Codeの権限設計チームガイドが参考になります。

手順5：検証コマンドをClaude Codeに渡す

Claude Codeに任せるプロジェクトほど、検証コマンドが重要です。公式Best practicesでは、Claudeにテスト、ビルド、スクリーンショット比較など、実行できるチェックを渡すことが推奨されています。チェックがなければ、Claude Codeは「見た目上できた」と判断するしかありません。チェックがあれば、失敗を読み、修正し、再実行できます。

新規プロジェクトでは、最初のREADMEとCLAUDE.mdに同じ検証コマンドを書きます。人間用のREADMEとClaude Code用のCLAUDE.mdを分ける理由は、読み手が違うからです。READMEは新メンバーに説明する文章、CLAUDE.mdはClaude Codeが毎回参照する短い作業指示です。

このプロジェクトの検証コマンドを整備してください。

条件:
- package.jsonのscriptsを読み、存在するコマンドだけを使う
- 存在しないコマンドを勝手に追加しない
- READMEに「開発」「テスト」「ビルド」の3項目を追記する
- CLAUDE.mdには、PR前に実行する最小コマンドだけを書く
- 最後に実際に実行したコマンドと結果を報告する

もしまだテストがないなら、最初から大きなテストスイートを作らせる必要はありません。最初は「型チェックが通る」「1つの純粋関数テストが通る」「主要ページがビルドできる」だけでも十分です。重要なのは、Claude Codeが自分で実行できる合格条件を持つことです。

たとえばTypeScriptの新規管理画面なら、初日の完了条件は次のようにします。

完了条件	合格ライン	Claude Codeへの指示
型チェック	`npm run typecheck`が成功する	型エラーを隠さず、原因を説明して修正する
単体テスト	新規追加したロジックに小さなテストがある	関連する最小テストだけを先に実行する
ビルド	`npm run build`が成功する	失敗時はログを読み、根本原因を直す
差分説明	変更ファイルと意図が説明されている	「何を変えたか」「なぜ変えたか」「確認したこと」を報告する

テスト生成やTDDの進め方は、Claude Codeのテスト生成・TDDガイドも関連します。新規プロジェクトでは、機能追加より先に「落ちるテストをどう扱うか」を決めておくと、後半の手戻りが減ります。

手順6：MCPとhooksは「初日から全部」ではなく用途限定で入れる

Claude CodeはMCPで外部ツールに接続できます。公式MCPドキュメントでは、MCPサーバーにより、issue tracker、monitoring、database、design toolsなどと接続し、貼り付けではなく直接参照・操作できると説明されています。新規プロジェクトでは魅力的ですが、初日から多くのMCPを入れる必要はありません。

最初に入れる候補は、開発フローに直結するものだけです。

Issue tracker：要件やチケットを参照する。
GitHub：PR、issue、レビュー文脈を扱う。
Figma：UI実装でデザインを参照する。
PostgreSQLなどのDB：開発用DBに限定してスキーマを確認する。
監視ツール：既存サービスのエラー調査に使う。

公式MCPドキュメントでは、HTTP transportでの追加例としてclaude mcp add --transport httpが紹介されています。また、プロジェクト共有のMCPは.mcp.jsonのスコープで扱えます。新規プロジェクトでは、チーム共有すべきMCPと個人だけで使うMCPを分けてください。

# HTTP MCPサーバーを追加する例
claude mcp add --transport http notion https://mcp.notion.com/mcp

MCPの注意点は、外部コンテンツを取るサーバーにはprompt injectionリスクがあることです。公式MCPドキュメントでも、接続前に信頼できるサーバーか確認するよう注意されています。新規プロジェクトでは、最初から本番DBや顧客データに接続するのではなく、開発用・読み取り専用・サンプルデータから始めるのが安全です。

より詳しいMCP設計は、Claude Code MCP実践ガイドと、チーム認証に踏み込んだMCP OAuth認証とチーム配布の記事が関連します。

hooksも同じです。公式hooks guideでは、hooksはClaude Codeのライフサイクル上の特定ポイントで実行されるユーザー定義のシェルコマンドで、整形、通知、コマンド検証、プロジェクトルール強制などに使えると説明されています。新規プロジェクト初日は、PostToolUseでformatを走らせる、Notificationで待ち状態を知らせる、Stopで検証コマンドを走らせる、くらいから始めると扱いやすいです。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npm run format -- --write"
          }
        ]
      }
    ]
  }
}

ただし、hooksは決定的に実行される仕組みです。便利だからといって、重いE2Eテストや外部APIへの送信を毎回走らせると、開発体験が悪くなります。最初は軽いformat、lint、保護ファイルのブロック、通知に限定しましょう。hooksの具体例は、Claude Code hooks自動化ガイドにまとめています。

手順7：最初の実装は「探索→計画→小さな差分→検証」で閉じる

ここまで整ったら、ようやく最初の実装です。公式Best practicesでは、特に不確実な変更や複数ファイルにまたがる変更では、探索、計画、実装、コミットという流れが紹介されています。新規プロジェクト初日の差分は、小さく閉じるのがコツです。

たとえば、社内申請ツールの初回差分なら「CSVアップロード、DB保存、一覧、認証、監査ログ」を一気に頼むのではなく、「サンプルCSVを読み、型付きのプレビュー画面に出す」までにします。認証やDBは後で構いません。最初に動作確認できる垂直スライスを作ると、Claude Codeも人間も次の判断をしやすくなります。

最初の実装として、CSVプレビューだけを作ってください。

スコープ:
- サンプルCSVを読み込む
- 画面にテーブル表示する
- 保存、認証、承認ワークフローはまだ作らない
- 追加したロジックには最小テストを付ける
- 実装前に変更予定ファイルを列挙する
- 実装後にtypecheck、関連テスト、buildの結果を報告する

不足している情報があれば、最初に質問してから作業を開始してください。

新規プロジェクトでは「まだ作らないもの」を明記するのが大事です。Claude Codeは親切なので、曖昧な依頼だと周辺機能まで作ろうとします。スコープ外を先に書くと、差分が小さく保てます。

作業完了後は、Claude Codeに証跡を出してもらいます。

完了報告では、次の形式でまとめてください。

1. 変更したファイル
2. 変更理由
3. 実行した検証コマンドと結果
4. まだ未実装の範囲
5. 次に着手するなら最小の1タスク

「成功しました」だけで終わらず、検証ログに基づいて説明してください。

この報告形式をCLAUDE.mdにも短く書いておくと、毎回のレビューが楽になります。実装そのものより、レビュー可能な差分と検証ログを残すことが、Claude Codeをチーム開発に入れる時の基本です。plan modeの使い分けは、Claude Code plan mode実践ガイドもあわせて確認してください。

新規プロジェクト用の最小ファイル構成

では、実際にどんなファイルを置けばいいのか。新規プロジェクトの初日におすすめする最小構成は次の通りです。

.
├── README.md
├── CLAUDE.md
├── .env.example
├── .gitignore
├── .claude/
│   ├── settings.json
│   └── rules/
│       └── frontend.md
├── .mcp.json
├── docs/
│   ├── product-brief.md
│   ├── architecture.md
│   └── decisions/
│       └── 0001-initial-stack.md
└── src/

この構成は、すべてを最初から埋めるためのものではありません。空でもよいので、置き場所を決めるための構成です。Claude Codeに「要件はどこにあるか」「設計判断はどこに残すか」「自分が毎回読むべき指示はどこか」を示せるだけで、会話のぶれが減ります。

ファイル	役割	注意点
`README.md`	人間向けの起動手順、背景、開発コマンド。	長くなりすぎたらdocsに分離する。
`CLAUDE.md`	Claude Codeが毎回読む作業ルール。	短く保つ。一般論は書かない。
`.claude/settings.json`	チーム共有の権限、hooks、環境設定。	個人設定は`settings.local.json`に分ける。
`.mcp.json`	プロジェクトで共有するMCPサーバー設定。	秘密値を直書きしない。
`docs/decisions/`	技術選定や設計判断の記録。	Claude CodeにADR更新を依頼しやすい。

私がレビューするときも、最初にこのあたりを見ます。機能の出来より先に、プロジェクトが「次の人に引き継げる状態」かどうかを見るんです。Claude Codeは速いので、足場が弱いと弱いまま大量の差分が生まれます。逆に足場が整っていると、かなり安心して小さなタスクを任せられます。

コピペで使える初回プロンプト集

ここでは、新規プロジェクトの初日に使えるプロンプトをまとめます。丸投げではなく、Claude Codeが質問、計画、検証を挟む形にしています。

1. リポジトリ調査プロンプト

このリポジトリを新規プロジェクトとして立ち上げます。
まず実装はせず、以下を調査してください。

- 使用言語とフレームワーク
- パッケージマネージャー
- 起動、テスト、ビルド、lint、typecheckのコマンド候補
- まだ不足しているREADMEや設定
- Claude Codeが作業する前に人間へ確認すべき点

ファイル変更はしないでください。
仮定した点は必ず「仮定」と明記してください。

2. CLAUDE.md生成後の改善プロンプト

/init

生成されたCLAUDE.mdをレビューしてください。
目的は、毎セッション読む価値がある短い指示だけに絞ることです。

残す:
- このプロジェクト固有のコマンド
- コーディング規約
- テスト方針
- 触ってはいけないファイル

削る:
- 一般的なプログラミング知識
- コードから推測できる説明
- 長いチュートリアル
- 変化しやすい外部仕様

変更案を先に提示し、承認後に編集してください。

3. 権限設計プロンプト

このプロジェクトでClaude Codeに許可する操作を整理してください。

分類してください:
- 常に許可してよい読み取り操作
- 都度確認すべきBashコマンド
- 原則禁止すべきコマンド
- 編集前に確認すべきファイル

その上で、.claude/settings.jsonに入れるpermissions案を作ってください。
危険な許可を入れる場合は、理由と代替案を説明してください。

4. 最初の垂直スライス設計プロンプト

このプロダクトの最初の垂直スライスを提案してください。

条件:
- 1日以内にレビューできる差分にする
- 認証、課金、外部API連携は必要になるまで作らない
- UI、データ構造、最小テストを含める
- 実装前に変更ファイルと検証コマンドを出す

候補を3つ出し、最も小さく価値がある案を推奨してください。

5. hooks導入プロンプト

このプロジェクトに最初に入れるhooksを提案してください。

目的:
- 編集後のformat
- Claude Codeが待っている時の通知
- 保護ファイルへの変更ブロック
- 終了前の軽量な検証

重いE2Eや外部API送信は初期hooksに入れないでください。
設定案を出し、どのイベントで発火するか説明してください。

6. 完了報告フォーマット固定プロンプト

今後、このプロジェクトで作業完了を報告するときは次の形式にしてください。

- 変更したファイル
- 変更理由
- 実行した検証コマンド
- 検証結果
- 未解決のリスク
- 次の最小タスク

このルールをCLAUDE.mdに短く追記する案を出してください。
追記は私が承認してから行ってください。

どのプロンプトにも共通しているのは、「不足している情報は質問」「仮定は仮定と明記」「先に計画」「検証結果を報告」の4点です。Claude Codeは強力ですが、チーム開発では説明責任も必要です。プロンプトでその型を固定しておくと、出力の品質が安定します。

【要注意】よくある失敗パターンと回避策

失敗1：初日に大きすぎる実装を頼む

❌「認証付きのSaaSを全部作って」

⭕「まず、サンプルデータを一覧表示する最小画面だけを作って。保存、認証、課金はスコープ外」

なぜ重要かというと、Claude Codeは広い依頼にも応えようとするからです。新規プロジェクトでスコープが広いと、フレームワーク選定、DB設計、認証、UI、テストが一度に混ざります。レビュー対象が大きくなり、何が正しいのか判断しにくくなります。

失敗2：`CLAUDE.md`を長い設計書にする

❌「プロダクト背景、API仕様、全画面の説明、全DBカラムをCLAUDE.mdに入れる」

⭕「CLAUDE.mdには作業ルールだけを書き、詳細仕様はdocs/に分ける」

公式Best practicesでも、CLAUDE.mdは毎セッション読み込まれるため短く保つべきだと説明されています。長いファイルはコンテキストを圧迫し、守ってほしいルールが埋もれます。人間でも長すぎる手順書は読まれません。Claude Codeでも同じです。

失敗3：権限を広く許可しすぎる

❌「初日からbypassPermissionsで全部許可する」

⭕「初回はdefaultまたはplanで始め、検証コマンドだけを限定的にallowする」

公式permissionsでは、bypassPermissionsは隔離されたコンテナやVMのような環境で使うべきだと説明されています。ローカルの本物の作業環境で広く許可すると、意図しない変更やコマンド実行のリスクが上がります。便利さより、再現性とレビュー可能性を優先してください。

失敗4：検証コマンドがないまま完了扱いにする

❌「見た目はできたので完了」

⭕「typecheck、関連テスト、buildのいずれかを実行し、結果を報告してから完了」

Claude Codeに限らず、AIエージェントは検証できるゴールがあるほど強くなります。公式Best practicesでも、テストやビルドなどClaudeが読めるチェックを渡すことが推奨されています。新規プロジェクトでは、機能数より先に検証ループを作る方が長期的に安定します。

30分・半日・1週間の立ち上げロードマップ

最後に、実務で使いやすい時間軸に落とします。新規プロジェクトをClaude Codeで始める時は、初日から全体最適を狙わず、30分、半日、1週間の3段階で進めると破綻しにくいです。

時間軸	やること	完了条件
最初の30分	インストール確認、ログイン、`claude --version`、`/init`、`/permissions`。	Claude Codeがプロジェクトを読み、編集前に計画を出せる。
半日	`CLAUDE.md`、README、`.claude/settings.json`、検証コマンド、最小の垂直スライス。	小さな差分が入り、検証コマンドの結果が報告される。
1週間	MCP、hooks、ADR、PRレビュー、チーム展開ルールを追加。	人間のレビュー基準とClaude Codeの作業ルールが一致する。

ここでいう「完了」は、プロダクト完成ではありません。新規プロジェクトとして、安全に反復できる状態になったという意味です。Claude Codeの価値は、最初の一発で大きな機能を出すことだけではなく、毎回の変更を小さく、検証可能に、レビューしやすくするところにあります。

もしDockerやdevcontainerまで含めて初期環境を固めたい場合は、Claude Codeとdevcontainerによる安全なチーム導入、リリース前の運用まで見たい場合はClaude Codeのデプロイ・リリースガイドも関連します。

FAQ：Claude Code新規プロジェクト立ち上げでよくある質問

Q1. Claude Codeの新規プロジェクトでは、最初に何を頼むべきですか？

最初は実装ではなく、リポジトリ調査、検証コマンドの確認、CLAUDE.md作成、権限設計を頼むのがおすすめです。いきなり大きな機能を作るより、作業ルールと検証ループを先に整える方が安定します。

Q2. `/init`で作った`CLAUDE.md`はそのまま使えますか？

そのまま使い始めることはできますが、短く整理するのが実務向きです。公式ドキュメントでは/initがコードベースを分析してスターターのCLAUDE.mdを作ると説明されていますが、最終的には人間がプロジェクト固有のルールに絞るべきです。

Q3. 新規プロジェクトでWeb版とCLI版のどちらを使うべきですか？

ローカルDB、Docker、社内VPN、手元の開発ツールに依存するならCLIが扱いやすいです。GitHub上のリポジトリをクラウドで並列に進めたい場合や、ローカルcheckoutなしで調査したい場合はWeb版が向いています。Web版を使う場合、公式ドキュメント上はGitHubリポジトリが必要です。

Q4. `bypassPermissions`を使えば立ち上げは速くなりますか？

速くなる場面はありますが、初回の標準設定にするのはおすすめしません。公式permissionsでは、bypassPermissionsは隔離されたコンテナやVMのような環境で使うべきだと説明されています。通常のローカル開発ではdefaultやplanから始める方が安全です。

Q5. MCPは初日から入れるべきですか？

必要なものだけ入れるのがよいです。Issue tracker、GitHub、Figma、開発用DBのように、開発フローに直結するものから始めます。外部コンテンツを取得するMCPサーバーはprompt injectionリスクもあるため、信頼性とスコープを確認してから接続してください。

Q6. hooksはどこまで自動化すべきですか？

初日は軽いformat、通知、保護ファイルのブロック、軽量な検証に限定するのが現実的です。hooksは決定的に実行される仕組みなので、重いE2Eや外部API送信を毎回走らせると開発体験が悪くなります。

Q7. 新規プロジェクトの初回タスクはどれくらい小さくすべきですか？

1日以内に人間がレビューできる差分にしてください。たとえば「CSVを読み込んでプレビュー表示する」「1つのAPIエンドポイントを作ってテストする」くらいが扱いやすいです。認証、課金、外部連携、監査ログは、必要なタイミングで小さく追加します。

参考・出典

Quickstart — Claude Code Docs（参照日: 2026-07-07）
Advanced setup — Claude Code Docs（参照日: 2026-07-07）
How Claude remembers your project — Claude Code Docs（参照日: 2026-07-07）
Claude Code settings — Claude Code Docs（参照日: 2026-07-07）
Configure permissions — Claude Code Docs（参照日: 2026-07-07）
Connect Claude Code to tools via MCP — Claude Code Docs（参照日: 2026-07-07）
Automate actions with hooks — Claude Code Docs（参照日: 2026-07-07）
Best practices for Claude Code — Claude Code Docs（参照日: 2026-07-07）
Get started with Claude Code on the web — Claude Code Docs（参照日: 2026-07-07）
Claude Code changelog — Claude Code Docs（参照日: 2026-07-07）

まとめ：今日から始める3つのアクション

今日やること：対象リポジトリでclaudeを起動し、/initと/permissionsを実行してください。実装依頼はその後です。
今週中にやること：CLAUDE.md、.claude/settings.json、README、検証コマンドを見直し、チームで同じ手順を使える状態にしてください。
今月中にやること：MCP、hooks、ADR、PRレビューの運用を追加し、Claude Codeが作った差分を人間がレビューしやすい開発フローにしてください。

あわせて読みたい：

Claude Code実践テクニック完全ガイド — 日常開発で使う基本パターンを広く確認する
Claude Codeで大規模コードベースを理解するオンボーディング手順 — 新規だけでなく既存プロジェクト参加にも使える
Claude Codeコードレビュー効率化ガイド — 初回差分をレビューしやすくする

次回予告：次の記事では、Claude Codeで新規プロジェクトを作った後の「初回PRレビューと修正ループ」をテーマに、レビュー観点、テスト追加、差分分割の進め方を解説します。

著者：佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。

ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。