/init（イニット）

Claude Codeを使い始めた最初の1〜2日の人向け

/init は、いま開いているフォルダの中身をClaude Codeに観察させて、プロジェクト用の覚え書きファイル CLAUDE.md の雛形を半自動で書かせるスラッシュコマンドです。コマンドの後ろに何も書き足さず、/init とだけ叩いて使います。

立ち上げ初日にこれを叩くだけで、Claudeは「ビルドコマンドはこれ」「テストはこう走らせる」「ファイル配置はこの規約」という骨格を勝手に書き起こします。私は新しいプロジェクトに入った日のいちばん最初に必ず叩いています。手で CLAUDE.md を一から書くのと比べて、初動が雑でも形になるのが大きい。

噛み砕くと

新しい職場の初日、机の上に「うちの会社の決まりごと」と書かれた白紙のノートが置かれている、とイメージしてみてください。/init はその白紙のノートに、Claudeが社内を一周見て回って「会議は毎週火曜」「経費精算は月末締め」みたいな観察メモを下書きしてくれるイメージです。

本人が一から書こうとすると、何を書けばいいか思いつかない。だけど誰かが7割書いてくれていれば、あとは違うところを直すだけで済みます。これが心理的に大きい。

下書きは完璧ではないので、結局あとで自分の手で削ったり書き足したりすることになる。それでもゼロから書き始めるより圧倒的に速い。私はいつもこれを「最初の補助輪」と呼んでいます。

そもそも CLAUDE.md には何を書くものか（公式の推奨）

/init が出してくれる下書きを活かすには、その下書きが何を埋めるためのファイルなのかを先に押さえておくと早い。Claude Code 公式の説明では、CLAUDE.md は「Claudeに毎セッション持たせておきたい前提」を書く場所で、追加するきっかけは大きく4つです。

• Claudeが同じ間違いを2回した時。同じ訂正をするのが面倒になったらCLAUDE.mdに書く合図
• コードレビューで「これはClaudeが知っておくべき前提だった」と気付いた時
• 毎セッションで同じ修正指示や前置きを口で繰り返している時
• 新しい仲間がチームに入った時、最初に伝えるべき前提知識

そして書く中身は次の4カテゴリが中核です。

• ビルドや起動の手順: npm run dev でローカル起動、npm test でテスト実行、みたいな実行コマンド
• コード規約・命名規則: インデント幅、ファイル名のつけ方、関数の書き方など
• プロジェクトの構造: APIハンドラは src/api/handlers/ 配下、画像は public/images/ 配下、みたいな置き場所
• 「いつもこうして」ルール: コミット前に必ずテストを走らせる、PRはdraftで作る、料理ブログなら全記事に栄養成分表をつける、みたいなプロジェクト固有の決まり

/init はこの4カテゴリを、フォルダの中身を観察して推測した状態で下書きしてくれます。たとえば package.json があれば「ビルドコマンドはたぶんこれだろう」と判断するし、テストファイルが置いてあれば「テスト実行手順はこのへん」と書きます。観察できないもの（毎回守らせたい固有ルール）は人間が後で書き足す前提です。

なお、個人のクセ（自分の検証用URL、自分専用の仮データなど）は CLAUDE.md ではなく CLAUDE.local.md に分けます。後者はチームで共有しないファイルで、gitignoreで除外する前提。両方使い分けるとチームメンバーから「読みやすい」と言われました。

もう一段詳しい話（CLAUDE.mdの中身の具体例・育て方・落とし穴）は CLAUDE.md の辞書ページ に分けてあります。/init で出てきた下書きをどう育てていくか、まで踏み込みたい場合はそちら。

空っぽのフォルダで叩いても、ほぼ何も書いてくれない

これがいちばん最初に踏みやすい落とし穴です。/init はフォルダの中身を観察してメモを書くコマンドなので、観察対象がゼロだと出力もスカスカになります。

具体的には、空っぽのフォルダで /init を叩くと「特に観察できる構造がなかったので最小限のスケルトンだけ置いておきます」みたいな、ほぼ白紙の CLAUDE.md が出来上がる。これは私も最初の頃やらかしました。

逆に、すでに CLAUDE.md が存在している状態で /init を叩くと、上書きはされません。代わりに「いまの CLAUDE.md はここが薄いので、こう足したらどうですか」という改善提案だけが返ってきます。これは安全側に倒した良い設計だと感じています。

「料理ブログを始める」を例に、実際の手順を見る

料理ブログを作る想定で、写真整理スクリプトとレシピ用のMarkdownファイルが何個か入っているフォルダを用意したとします。これに /init を叩くと、Claudeがどう振る舞うか順に追います。

ステップ1: フォルダの準備

まずターミナルでブログ用フォルダに移動します。空っぽではなく、すでに何かしら素材ファイルが入っている状態にしておくのがコツ。

$ cd ~/projects/cooking-blog
$ ls
recipes/  photos/  scripts/  package.json  README.md

ステップ2: Claude Codeを起動

そのフォルダの中で claude と打ってClaude Codeを起動します。

$ claude

ステップ3: /init を叩く

起動直後のチャット入力欄に /init とだけ打ってEnter。コマンドの後ろに何も書き足しません。

> /init

ステップ4: Claudeがフォルダを観察

Claudeが package.json 、 scripts/ の中身、 README.md を順に読み取って、ビルド手順・依存関係・既存のフォルダ構成を把握します。1〜2分かかることもある。

ステップ5: CLAUDE.md の下書きが出てくる

観察が終わると、こんな感じの CLAUDE.md が提案されます。

# Cooking Blog Project

## ビルド・実行
- 写真整理: `node scripts/optimize-photos.js`
- ローカル確認: `npm run dev`

## ファイル配置
- レシピ本文: `recipes/*.md`
- 写真素材: `photos/`
- ビルドスクリプト: `scripts/`

## 規約
- レシピのファイル名はkebab-case（例: tomato-pasta.md）
- 写真は1200x800にリサイズしてから `photos/` に置く

ここで初心者がやりがちな勘違いがあります。「Claudeがこれを書いた＝完成」ではない。これはあくまで観察ベースの叩き台で、自分のブログのトーン・運営方針・更新頻度のような「中身を見ても分からない情報」は当然抜けています。

ステップ6: 中身を直して保存する

提案された下書きをよく読んで、抜けている運営ルール（例:「タイトルは英語と日本語の両方を書く」「投稿前に必ず写真の著作権を確認する」）を書き足します。書き足す方法は二通りあって、 /claude-md でファイルの書き方を覚えて自分の手で開くか、 /memory で CLAUDE.md を開いて編集する流れになります。

つまり /init を叩くと何が手に入るのか

• 手に入るもの: フォルダの構造をClaudeが観察した結果として、ビルドコマンド・ファイル配置・命名規約などが書かれた CLAUDE.md の下書き
• 手に入らないもの: あなた自身の運営方針・トーン・人間相手のルール（編集会議の頻度、デザインの好み等）。これらは観察では出てこないので、後から自分で書き足す前提
• 意味が薄い場面: ファイルが何も入っていない空フォルダで叩いた時。観察素材がないので、ほぼ白紙の CLAUDE.md しか出てこない

使いどころ3シナリオ

シナリオ1: 料理ブログを始める初日

レシピを書き溜めるフォルダ、写真をリサイズするスクリプト、ビルド用の package.json をひと通り置き終えたあと、まだ CLAUDE.md がない状態で /init を叩きます。Claudeが「写真は photos/ に置いてある」「レシピは recipes/*.md 形式」みたいな観察結果を下書きしてくれるので、私はそこに「タイトルは料理名＋分量で書く」「公開前に必ずプレビューする」を足して完成させます。

シナリオ2: 既存のオープンソースを git clone してきた直後

GitHubで気になったプロジェクトをコピーしてきた時、いきなりコードを触るより先に /init を叩くのがおすすめです。Claudeが README.md や設定ファイルを読み込んで、「このプロジェクトはこう動かす」「テストはこう走る」を CLAUDE.md にまとめてくれます。読み解きの初手として、たぶんこれより速い方法はない。

シナリオ3: 半年放置していた古いプロジェクトに戻ってきた時

過去の自分が書いたコードに戻ると「これどうやって動かすんだっけ」がほぼ毎回起きます。 CLAUDE.md がない状態で /init を叩けば、Claudeが現状のフォルダを観察し直して、いまの自分が把握しやすい形でまとめ直してくれる。記憶の再起動装置として優秀です。

初心者が踏みやすい落とし穴

• 空っぽのフォルダで叩く。観察対象がないので、出てくる CLAUDE.md もほぼ白紙。最低限 README.md や設定ファイルを置いてから叩くこと
• 下書きをそのまま完成扱いする。観察ベースの叩き台なので、運営方針や個人の好みは抜けている。読み返して必ず手を入れる
• 既存の CLAUDE.md が消えると思って叩くのを怖がる。すでにファイルがある場合は上書きされず改善提案だけが返るので、安心して叩いて大丈夫
• 毎セッション叩く。 /init はプロジェクト立ち上げ初日の作業。日常的に叩くものではない。叩くたびに同じ提案が出てくるだけで時間の無駄になる
• 一発で完璧を期待する。出てくるのはあくまで雛形。育てるのはあなたの仕事です
• 大きい機能を増やしたい時に CLAUDE_CODE_NEW_INIT=1 を知らないまま叩く。この設定値を先にオンにしてから /init を叩くと、 CLAUDE.md だけでなく Skills や Hooks までセットで作るかを順に聞いてくる対話モードになります。プロジェクトの規模が大きいなら、最初からこちらを使うほうが手戻りが少ない

書き方

/init

やってみるとこうなる

入力

/init

出力例

Claudeがフォルダの中身（package.json / scripts/ / README.md など）を観察し、ビルドコマンド・ファイル配置・命名規約をまとめた CLAUDE.md の下書きを提案する。すでに CLAUDE.md がある場合は上書きせず、改善提案だけを返す。

関連項目

• CLAUDE.md（クロードドットエムディー）
• /memory（メモリ）
• /agents（エージェンツ）
• /clear（クリア）
• Skills（スキルズ）

公式ドキュメント

https://code.claude.com/docs/en/memory