【新卒エンジニア向け】Claude Code、とりあえずこれ読んどけばOKなまとめ（2026年版）

Posted at 2026-07-11

はじめに

はじめまして、学生エンジニアのfuyunokiです。

この度、新卒として入社した会社でClaudeを使えるようになったので、自分用に調べたことをまとめてみました。せっかくなので記事として公開します。同じように「会社でClaude Code使えるようになったけど何から手を付ければ…」となっている新卒・若手エンジニアの助けになれば嬉しいです。

正直、最初にドキュメントを眺めた時は機能が多すぎて「結局何を覚えればいいんだ…」となりました。なのでこの記事では、公式ドキュメントに書いてある内容だけでなく、現役エンジニアの方々のブログやAnthropic社内の事例なども漁って、実際の運用でどう使われているかまで含めてまとめています。

対象読者はタイトル通り「これからClaude Codeを触る人」です。逆に、もう使い倒してる人には目新しい情報はないかもしれません

1. まずはインストール

2026年現在、公式ドキュメントを見るとネイティブインストーラー推奨にしっかり変わっていました。npm経由のインストールは非推奨（Deprecated）扱いになっています。理由としては、Node.jsのバージョン差でチーム内で動作が微妙に違う問題や、sudo npm install -g にまつわる権限トラブルを踏みがちだった、というあたりのようです。自分も最初npmで入れようとして少し詰まったので、これから入れる人は素直にネイティブインストーラーを使うのが良さそうです。

Mac / Linux

curl -fsSL https://claude.ai/install.sh|bash

Windows

PowerShellを開いて以下を実行するだけです（管理者権限は不要）。

irm https://claude.ai/install.ps1|iex

irm（Invoke-RestMethod）でAnthropicのサーバーからインストールスクリプトを取得し、iex（Invoke-Expression）でそのまま実行する、という一行です。Node.jsのインストールも不要で、~\.local\bin\claude.exe に入ります。Bashツールを使わせたい場合はGit for Windowsを別途入れておくのがおすすめで、入れていない場合はPowerShellがシェルツールとして使われます。

CMDを使っている場合は以下（irmはPowerShell専用のコマンドなのでCMDでは動きません）。

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

WSL上で使いたい場合は、Mac/Linuxと同じ curl コマンドをWSLのターミナル内で実行します。ネイティブWindows対応も進んでいますが、慣れないうちはWSL経由の方が情報も多く安定すると思います。

どうしてもnpmを使いたい場合

互換目的であれば以下でも動きますが、sudo は絶対NGです。権限エラーが出た場合は、nvmでNode.jsをホームディレクトリ配下に入れ直すのが正しい対処法とのこと。

npminstall -g @anthropic-ai/claude-code

動作確認〜初回起動

claude --versionclaude

初回起動時にブラウザが自動で開いて、Anthropicアカウント（Pro/Max/Teams/Enterprise/APIコンソール）でのOAuth認証を求められます。認証トークンは ~/.claude/ にローカル保存されるので、一度通せば以降はログイン不要です。

必要スペックの目安：macOS 13以降 / Ubuntu 20.04+・Debian 10+ / WSL付きWindows 10（1809+）、RAM 4GB以上（大規模コードベースなら8GB推奨）。処理自体はAnthropic側のサーバーで行われるので、手元のPCにGPUは要りません。

2. 初期設定：日本語で使いたい・モデルを選びたい

Claude Codeは日本語の指示にも普通に対応してくれます。最初に「日本語で答えて」と一言添えるか、後述するCLAUDE.mdに書いておくと安定して日本語で返してくれるようになります。
/model コマンドでモデルを切り替えられます。重い設計判断や複雑なバグ調査はOpus系、普段の実装作業はSonnet系、単純作業を大量にこなすときはHaiku系、みたいにタスクの重さに応じて使い分けるのがコスト・速度の両面でお得です。ここは意外と見落としがちなポイントかもしれません。

3. CLAUDE.md ― プロジェクトの「取扱説明書」

CLAUDE.mdは、Claude Codeがセッション開始時に自動で読み込んでくれる設定ファイルです。ここに書いた内容は、以降のやり取りすべての前提知識として扱われます。いわば「初めて入るプロジェクトに配属された時に先輩から渡される資料」みたいなイメージで捉えると分かりやすいと思います。

どこに置くか

場所	適用範囲
`~/.claude/CLAUDE.md`	全プロジェクト共通
プロジェクトのルート `CLAUDE.md`	そのプロジェクト全体
サブディレクトリ（例：`src/CLAUDE.md`）	そのディレクトリ配下のみ

書き方に迷ったら `/init`

プロジェクトのルートで /init を叩くと、Claude Codeがコードベースを解析して、そのプロジェクトに合わせたCLAUDE.mdの雛形を自動生成してくれます。何を書けばいいか分からず手が止まるくらいなら、とりあえず /init してから中身を調整していくのが早いです。

書くべきこと

Claudeがコードを読むだけでは推測できないビルド・テストコマンド
プロジェクト固有のアーキテクチャや設計方針
チームのコーディング規約（デフォルトでは分からないもの）
テストの実行手順、推奨ツール
よくある落とし穴や非自明な挙動（「このディレクトリだけビルド手順が違う」等）

逆に書かなくていいこと

コードを読めば分かること
一般的な言語・フレームワークの規約
頻繁に変わるAPI仕様の詳細
「きれいなコードを書く」みたいな自明すぎる方針

CLAUDE.mdは毎回全文がコンテキストに乗ってくるので、書きすぎるとかえってノイズになるようです。要点だけに絞って、細かい作業手順は後述のSkillsやカスタムコマンドに切り出す方が、プロジェクトが育ってきたときに効いてくる設計だと感じました。

4. いちいち確認されてイライラする問題 → 権限設定で解決

Claude Codeはデフォルトだと、ファイル変更やコマンド実行のたびに [y/n] の確認を求めてきます。安全のためではあるんですが、git commit や npm install みたいな定型操作まで毎回止まるのは正直テンポが悪いです。

/permissions コマンドで、ツール・コマンドごとに「常に許可」「常に確認」「常に拒否」を設定できます。

# 例：git commit を常に許可claude allow"git commit"
# 例：ファイル編集全般を常に許可claude allow edit

最初は最小限の許可からスタートして、信頼できる定型操作（lint実行、テスト実行、git系コマンドなど）を少しずつ許可リストに足していくのが安全な進め方だと思います。逆に破壊的な操作（force push、DB操作、本番デプロイなど）は最後まで自動承認しないようにするのが無難です。ここをうっかり緩めると事故った時のダメージがでかいので気を付けたいところ。

5. 基本の型：Explore → Plan → Implement → Commit

Anthropicが推奨している開発フローはこの4段階です。

Explore（探索）：Plan Modeで、まず関連コードを読ませて現状を把握させる
Plan（計画）：Plan Modeのまま、実装方針・変更範囲を言語化させる
Implement（実装）：Normal Modeに切り替えて、計画に沿って実装させる
Commit（コミット）：差分をレビューし、コミット・PR作成

いきなり「実装して」と投げる、いわゆる「バイブコーディング」は使い捨てのプロトタイプなら良いんですが、本番コードでやると普通に事故ります。特に複数ファイルにまたがる変更や、既存アーキテクチャへの影響が大きい変更は、先に計画を書かせて人間がレビューしてから実装させるというワンクッションを挟むだけで、手戻りがかなり減る印象です。

とはいえ、1ファイル数行で終わるような単純作業まで律儀にPlan Modeを踏む必要はなくて、タスクの大きさで使い分けるのが実践的だと思います。

6. コンテキストウィンドウ管理、これが一番大事かもしれない

Claude Codeのパフォーマンスは、コンテキストウィンドウ（会話の記憶容量）が埋まるほど下がっていきます。これは公式・非公式問わずいろんな記事で口を揃えて言われていて、Claude Codeを使いこなす上で一番重要な原則な気がしています。

よく使うコマンド

コマンド	役割
`/clear`	会話履歴をリセットし、コンテキストをゼロにする
`/compact`	会話を要約してコンテキストを節約する
`/rewind`	以前のチェックポイントに巻き戻す
`/help`	利用可能なコマンド一覧を表示

あるあるな失敗パターン

「ついで」タスクの持ち込み：あるタスクの途中で無関係な質問を挟んで、また元のタスクに戻る。コンテキストが無関係な情報で埋まって精度が落ちる。→ 無関係なタスクに移る前に必ず /clear。
同じ間違いの繰り返し修正：Claudeが間違えて、修正指示を出しても直らず、また修正…のループ。失敗した試行錯誤の履歴でコンテキストが汚染されている状態です。→ 2回訂正しても直らなかったら /clear して、学んだ内容を盛り込んだ新しいプロンプトで最初からやり直す方が結果的に早いらしいです。自分も何度か沼ったのでこれは実感としても分かります。

無関係なタスクに切り替えるタイミングでは、こまめに /clear する習慣をつけておくのが良さそうです。

7. カスタムスラッシュコマンドで「毎回同じこと打ってる」を消す

「毎回同じ指示文を打っている」作業は、スラッシュコマンドとして保存できます。.md ファイルを1つ置くだけで、/コマンド名 として呼び出せるようになります。

置き場所

プロジェクト単位（チーム共有）：.claude/commands/
ユーザー単位（個人用・全プロジェクト共通）：~/.claude/commands/

ファイル名（拡張子を除く）がそのままコマンド名になります。review-pr.md を作れば /review-pr で呼び出せる、というシンプルな仕組みです。

記述例

---allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)argument-hint: [message]description: Create a git commit---Create a git commit with message: $ARGUMENTS

$ARGUMENTS でコマンド実行時に渡した引数を受け取れます（$1, $2 みたいな位置引数指定もOK）。allowed-tools でそのコマンドが使えるツール・コマンドを制限でき、description は / を打った際の候補一覧に表示されます。

実際の現場では、「ブランチ作成 → コミット → PR作成」までの一連の流れをコマンド化したり、コーディングガイドラインを事前チェックしてからコミットさせたりする使い方が結構広く行われているようです。

育て方のコツ

いきなり凝ったコマンドを作るより、直近1週間で一番多く打っている定型文をまず1つコマンド化するのが定石みたいです。「個人用コマンド → プロジェクトコマンド（チーム共有）→ プラグイン（複数プロジェクト・チーム横断で配布）」という順で育てていくと、誰も使わないコマンドを量産せずに済むとのこと。コマンド数が20〜30個を超えると選ぶのに迷うオーバーヘッドが出てくるらしいので、カテゴリごとにプレフィックスを付けて整理しておくと良さそうです。

8. Skills（スキル）

繰り返し行う作業を「定義済みの手順」としてまとめておく仕組みです。.claude/skills/<スキル名>/SKILL.md に配置します。

---
name: {スキル名}
description: {本スキルの説明}
disable-model-invocation: true (claudeが自動が実行しないようにする)
allowed-tools: Bash, Read, Edit---（スキルの内容・手順）

disable-model-invocation: true を指定すると、Claudeが勝手に自動発動せず、手動で明示的に呼び出した時だけ使われるようになります。
allowed-tools で使用できるツールを限定できます。

スラッシュコマンドとの使い分けの目安は、「呼ばれたら動く＝スラッシュコマンド」「文脈に応じて自動で発動してほしい・補足ファイルやスクリプトを伴う複雑な作業＝Skill」という感じで捉えておくと分かりやすいです。ちなみに現在の公式ドキュメントでは .claude/commands/ は互換性のためのレガシー形式扱いになっていて、.claude/skills/ 形式が推奨の方向に移りつつあるようです。新しく作るならSkills形式で書いておくのが無難かもしれません。

9. Hooks（フック）

特定のイベント（ファイル編集後、コマンド実行前後など）に連動して、シェルコマンドを自動実行する仕組みです。.claude/settings.json に設定します。

代表的な使い方は、ファイルを編集するたびにLinter（ESLintなど）を自動実行する、コミット前に必ずガイドラインチェックを走らせる、といった「機械的にできるチェックをClaudeに毎回強制させる」パターンです。人間側のレビュー負荷を減らしてくれる効果があります。

10. サブエージェント

メインの会話とは独立したコンテキストで、特定のタスクだけを実行させる仕組みです。メインのコンテキストウィンドウを圧迫せずに済むのが利点です。

---
name: security-reviewer
description: コードのセキュリティ脆弱性をレビューする
tools: Read, Grep, Glob
model: opus
---
あなたはシニアセキュリティエンジニアです。以下の観点でコードをレビューしてください：
- インジェクション系の脆弱性（SQLインジェクション、XSS、コマンドインジェクションなど）
- 認証・認可の不備
- コード中の秘密情報・認証情報の埋め込み

「サブエージェントを使ってこのコードのセキュリティレビューをして」のように、サブエージェントの使用と指示内容を明示的にプロンプトへ書くと意図通りに動きやすいようです。応用として、コードを書くClaudeとレビューするClaudeを別セッションに分ける「Writer/Reviewer」パターンも有効らしいです。直前まで自分が書いたコードって、どうしても評価が甘くなりがちなので、レビュー専用のフレッシュなコンテキストを使う方が精度が上がるというのは、人間のコードレビューにも通じる話だなと思いました。

11. MCP（Model Context Protocol）

外部アプリ・サービスと連携する仕組みです。/plugin でプラグイン（Skills・Hooks・サブエージェント・MCPサーバーをひとまとめにした配布単位）のマーケットプレイスを覗けます。

代表的な連携先はこのあたりです。

GitHub：PR作成・レビューコメント返信・Issueのトリアージ
Slack：作業完了通知やエラーアラートの自動投稿
PostgreSQL / MySQL：自然言語でのクエリ実行・スキーマ確認
Figma：デザインデータの読み込みとUIへの反映

型付き言語で開発している場合は、コード知能系のプラグイン（シンボルナビゲーションや編集後の自動エラー検出）を入れておくとClaudeの精度が上がりやすい、と公式ドキュメントでも紹介されていました。

12. 現役エンジニアの実践知（自分で追加調査した分）

ここからは、ネットには無かったけど調べていて「これは覚えておきたい」と思った小ネタをまとめます。

レビューを「指摘探し」にさせない

レビュー役のClaudeに「問題点を探して」とだけ指示すると、実害のない些細な指摘まで大量に返ってくることがあるそうです。これを律儀に全部潰そうとすると、不要な抽象化や過剰な防御的コードが増える、いわゆる「オーバーエンジニアリング」を招くとのこと。「正しさや要件に影響する問題だけ報告して、それ以外は任意扱いにして」と伝えるのがコツみたいです。

こまめなコミットは人間だけでなくClaudeのためでもある

タスクのステップごとにコミットを作らせておくと、Claudeが誤った方向に進んだ場合でも、人間・Claudeどちらもすぐ前の状態に戻せます。一気に大きな変更をさせてからまとめて確認するより、事故った時のリカバリが圧倒的に速くなります。

UI実装は「見せてから直す」の反復が効く

モックアップ画像を渡して実装させ、実装結果のスクリーンショットを撮らせてモックと比較・修正させる、というループを2〜3回回すと完成度がぐっと上がる、という報告が結構ありました。一発で仕上げようとせず、最初から反復前提で進めるのがコツのようです。

自動運転（auto-accept）はコアロジック以外で使う

確認プロンプトを都度スキップしてClaudeに自律的に作業させる「auto-accept mode」は、プロトタイピングや周辺機能なら有効です。Anthropic社内でも、クリーンなGit状態から自律作業させて、8割くらいできたところで人間が最終調整する、という使い方が報告されていました。ただしコアなビジネスロジックに関わる変更では、詳細な指示を出しながら同期的に進める方が事故りにくい、とされています。このあたりは「どこまで任せるか」の線引きとして参考になりました。

新しいコードベースへのオンボーディングに使う

「このAPIはどう設計されている？」「この機能は誰が最後に触った？」みたいな、ペアプログラミング相手に聞くような質問をそのままClaude Codeに投げて、コードベースの探索に使う使い方が広がっているようです。Git履歴を辿って設計意図や変更理由まで調べさせることもできて、特別なプロンプトの工夫をしなくても、質問するだけでClaudeが勝手にコードを探索して答えてくれるとのこと。新卒でいきなり大きいコードベースに放り込まれた身としては、これは結構ありがたい使い方だなと感じました。

モノレポとの相性

スキーマ・API定義・実装が1つのリポジトリ内に揃っているモノレポ構成は、Claudeが一箇所でコンテキストを把握しやすく、相性が良いという指摘もありました。

13. つまずきポイント集

症状	原因・対処
`claude: command not found`	PATHが通っていない。シェル設定を再読み込み（`source ~/.zshrc` 等）するか、PATHに手動追加
`npm install -g` で権限エラー	`sudo` は使わない。nvmでNode.jsをホームディレクトリ配下に入れ直すか、ネイティブインストーラーに切り替える
コマンド選択に迷うほどコマンドが増えた	カテゴリプレフィックスで整理、使われないコマンドは棚卸しする
同じ間違いを何度も直させている	`/clear` して、失敗から学んだ内容を盛り込んだ新しいプロンプトで仕切り直す
レビュー結果が指摘だらけで消化しきれない	「正しさ・要件に影響する問題だけ」と指示範囲を絞る

14. まとめ：最初の1週間でやることリスト

ネイティブインストーラーでセットアップし、claude を一度起動して認証を済ませる
プロジェクトのルートで /init を実行し、CLAUDE.mdの雛形を作る（不要な記述は削る）
/permissions で、lintやテスト実行など安全な操作から許可リストに追加する
まずは小さいタスクをExplore→Plan→Implement→Commitの流れで1つやってみる
1週間で「同じ指示を何度も打っているな」と感じた作業を1つ、カスタムスラッシュコマンドにする
無関係なタスクに移るときは /clear を習慣化する

Claude Codeは機能が多くて、最初はどうしても情報量に圧倒されがちですが、実際に使う機能はプロジェクトの性質でかなり絞られてくると思います。まずはCLAUDE.md・権限設定・/clear の3つだけ押さえて使い始めて、必要になった機能（Skills、Hooks、サブエージェント、MCP）はその都度足していくのが、挫折せずに済む進め方かなと思います。

皆さんの参考になれば幸いです。何か訂正点あればコメントいただけると助かります

参考記事

公式ドキュメント・公式発信

個人・企業ブログ（実践知・Tips）
5. Claude Codeですべての日常業務を爆速化しよう！ - Qiita（@minorun365）
6. Claude Codeをはじめて触るエンジニアのためのざっくり入門 - Zenn（スタフェステックブログ）
7. 【Claude Codeの活用事例】よく使うカスタムスラッシュコマンド5選！ - Findy Tech Blog
8. Claude Codeカスタムスラッシュコマンド集 Part1 - ENECHANGE Developer Blog
9. Claude Code: カスタムスラッシュコマンドの作り方を理解する - BioErrorLog Tech Blog
10. Claude Codeのインストール完全ガイド【2026】｜全OS対応・npm非推奨対策 - 株式会社Uravation

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up