Claude Code（クロードコード）は、ターミナル（＝文字でパソコンに命令する黒い画面）の上で動くAIです。最大の特徴は、ただコードを答えてくれるだけでなく、ファイルを読んで・書き換えて・コマンドを実行して・結果を確かめるところまで自分で進めてくれること。今回は、その仕組みを初心者の方にもイメージできるように解説してみました。後半では公式ドキュメントに基づく6つの主要機能（CLAUDE.md / スキル / フック / サブエージェント / エージェントチーム / MCP）について解説していきます。
長めの記事ですが、この記事を読めば「Claude Codeとは何か」から「使いこなしの勘どころ」まで一気につかめる構成にしています。
この記事は、現役エンジニアがほぼ毎日Claude Codeを使っている視点から書いています。「とりあえず動かせる」ではなく「なぜそう動くのか」までイメージできることを目指します。
そもそもClaude Codeって何？
「コピペ型」から「自分で動く型」へ
AIにコードを手伝ってもらう手段は、ここ数年で大きく変わりました。
- ChatGPT型：質問するとコードを教えてくれる。でも、それを自分でコピーして貼り付けるのは自分の仕事
- Claude Code型：「このバグ直して」「テスト書いて」と頼むと、ファイルを開いて、書き換えて、保存まで自分でやってくれる
料理で例えるとわかりやすいです。ChatGPTは「レシピを教えてくれる人」。対してClaude Codeは「厨房の料理人」です。「カレー作っといて」と頼めば、冷蔵庫から材料取ってきて、切って、煮て、味見して、足りなければ調整までしてくれるといった感じです。この違いを、AIの世界ではエージェント型と呼ぶそうです。エージェント：「自分で考えて動く代理人」のイメージでOKです。
Claude Codeの心臓部「集める・動く・確かめる」
Claude Codeは、ひとつの仕事をこなすとき、内側で次の3ステップをぐるぐる回しています。
- 集める：関係しそうなファイルを探して読み、今どうなっているかを把握する
- 動く：ファイルを書き換える、コマンドを実行する、必要なら調べる
- 確かめる：テストを走らせたり結果を見たりして、うまくいったか自分でチェックする。ダメならまた1に戻る
ポイントは3つ目の「確かめる」です。人間だと「たぶん直ったはず」で終わらせがちですが、Claude Codeは自分でチェックしてから報告します。この自己チェックがあるおかげで、的外れな結果が減る(若干)です。
とりあえず動かしてみる
導入はとてもシンプルです。Macの方は次のコマンド1行です。
2026年6月現在の導入方法になります。必ず以下公式から最新の方法を確認して導入してください。
インストールが終わったら、作業したいフォルダに移動して起動します。
あとは > のあとに日本語で指示するだけです。
ここまでが「入門の入門」です。ここから先が、この記事の本題です。Claude Codeを「ちょっと便利なツール」として使ってる人がほとんどと印象ですが、本来は「自律的な開発のパートナー」へと進化させて使うべきだと僕は思います。そこでClaudeCodeの6つの主要機能を見ていきましょう。
Claude Code 6つの主要機能
ここから紹介する6つは、正直最初はパッとイメージできないものかと思います。なのでまずはすべてに共通する「この考え方」を先に知ってほしく、これで結構驚くほどスッと入ってくるようになります。
6機能の軸：「AIの机の広さ」を節約する
Claude Codeには「一度に覚えていられる量」に上限があります。これをコンテキスト（文脈）と呼びます。イメージは「机の広さ」です。
ファイルを読む、コマンドの結果を見る——そのすべてが、机の上に資料として積まれていきます。机がいっぱいになると、最初に置いた指示が埋もれて「あれ、さっき言ったこと忘れてる？」という状態になり、判断の精度も落ちます。
ChatGPTとかでも良くある「会話いっぱいすると'ぼやけて'くる」のはこれが原因です。
これから紹介する6つの機能はどれもこの「机を散らかさずに、賢く動くための工夫」です。そんなものが公式から用意されていたのかぁ〜という視点で読み進めてみてください。
機能1：CLAUDE.md ― プロジェクトの「掟」
どんな困りごとを解決するの？
Claude Codeは、何もしないと毎回「まっさらな状態」で会話を始めます。つまり毎回「このプロジェクトはTypeScriptで書いてね」「コミットメッセージは日本語で」と伝え直すことになります。これは面倒ですよね。
それを解決するのが CLAUDE.md です。プロジェクトのいちばん上の階層に置いておくと、Claude Codeはセッション開始時(起動時)に必ずこのファイルを読み込みます。ここに主要な情報や概要を書いておくことができるので毎回伝え直す必要がなくなります。
書くべきこと・避けるべきこと（ベストプラクティス）
公式が推奨しているのは、次のような内容です。
- よく使うコマンド：ビルド・テスト・整形（フォーマット）に使うBashコマンド
- 独自のルール：一般的な書き方とは違う、このプロジェクト特有のコードスタイルやアーキテクチャ上の決定
- リポジトリのお作法：PR（変更提案）の命名規則、レビューのチェックリストなど
逆に、書かない方がいいものもあります。
- Claudeがコードを読めばわかること、標準的な言語仕様（書くだけ無駄になる）
- 頻繁に変わる情報、長いチュートリアル、細かすぎるAPIの説明
大きくしすぎない「200行ルール」
CLAUDE.mdは便利なので、つい何でも書きたくなります。でもここに落とし穴が。
長くなりすぎると、その内容自体が「机（コンテキスト）」を圧迫します。さらに情報が多すぎると、本当に大事な指示が埋もれてかえって無視されやすくなるんです。英単語帳一周した時最初の方の単語忘れちゃってるとおんなじ感じです。
なので目安は200行以下。それを超えそうなときは、細かい知識をパススコープルール（.claude/rules/ フォルダ）に逃がすこと。これは「特定のファイルを触るときだけ読み込まれる」仕組みで、必要なときだけ机に出てくるイメージです。
CLAUDE.mdには「いつも守ってほしい核」だけを残す。二次情報などは別に置いといて必要な時だけ読むように設定しましょう。
Claude初心者がまず使うのは下の2つ、プロジェクト設定（CLAUDE.md） と 個人の全体設定（~/.claude/CLAUDE.md） です。
個人の全体設定の例（~/.claude/CLAUDE.md）
CLAUDE.mdを育てるタイミングと、自動メモリ
CLAUDE.mdは最初から完璧でなくて大丈夫です。個人的には「毎回同じことを指示しているな」と気づいたときに書き足すのがベストです。
- 「毎回TypeScript指定してるな」→ CLAUDE.mdに書く
- 「コミットの形式を毎回説明してる」→ CLAUDE.mdに書く
- 「このライブラリは使ってほしくないのに毎回使ってくる」→ 禁止事項に書く
Claude Code自身に書いてもらうこともできます。
機能2：スキル（Skills）― 事前に決めたタスク
どんな困りごとを解決するの？
「デプロイの手順」「特定のバグの直し方」など、決まった作業手順や知識を毎回説明するのは大変です。これをパッケージにして再利用できるのがスキルです。
かしこい仕組み：説明だけ持っておいて、中身は使うときに開く
スキルの賢いところは読み込み方です。セッション開始時には**「このスキルは何をするものか」という説明だけ**が読み込まれ、本体の中身は実際に呼び出した瞬間にだけ机に広げられます。
図書館に例えると、最初は背表紙（タイトル）だけ並んでいて、必要な時にその本から情報を取ってくイメージです。これなら分厚いマニュアルをいくつ用意しても、ふだんは机を圧迫しません。さっきの「机の広さ」の話そのものですね。
例：コードレビュースキルを作る
.claude/skills/review.md の中身を次のようにします。
これで、セッション中に /review と打つだけで、毎回この観点でレビューしてくれます。さらには「コードをレビューして」というだけでも自動でClaudeCode側が「このスキル使わなきゃな」と判断してこのレビューをしてくれます。
機能3：フック（Hooks）― 「必ず実行する」を機械的に強制する
スキルとの決定的な違い
ここが今回いちばん大事なポイントです。
- スキル：AIが「状況を見て、必要なら使う」もの。やるかどうかはAIの判断（＝確率的）。(/~~ で強制もできる)
- フック：決められたタイミングで機械的に必ず実行されるもの
イメージで言うと、スキルは「気が利く同僚」的なもの、フックは「自動で動く機械のチェッカー」です。人は忘れたり認識の違いとかがありますが、機械は必ず動きます。だから「絶対に外したくないルール（ガードレール）」はフックに任せます。
代表的な使い方
フックは、Claude Codeの作業の節目（ツールを使う前・使った後・セッション開始時など）に合わせて、自動でスクリプトを走らせます。
- PreToolUse（ツール実行の前）：コマンドを実行する直前に設定できます。指定したコマンドを実行する前にチェックを入れ、危険な操作（例：
rm -rf /のような全削除コマンド）を強制的にブロックできます。 - PostToolUse（ツール実行の後）：ファイルを編集した後のチェックなどを設定できます。コード編集時に自動でコードの整形ツール（Prettierなど）やチェックツールを走らせたりできます
- Notification（通知）：Claudeがあなたの入力待ちになったときのチェックや処理を設定できます。デスクトップに通知を出したりできるので「裏で進めさせて、止まったら教えてもらう」使い方に便利です
さらに上級者向けには、シェルスクリプトだけでなく、AIに判定させるプロンプトベースのフックや、サブエージェント（次で説明します）に検証させるエージェントフックも設定できます。基本は以下のような書き方で設定します。
機能4：サブエージェント（Subagents）― タスクを他に任せる
どんな困りごとを解決するの？
「数千行のログを全部調べて原因を探して」——こういう重い調査を普通にやると、結果のログで机（コンテキスト）が一瞬で埋まってしまいます。
そこで使うのがサブエージェントです。メインとは別の独立した机を持った「調査専門の分身」を立てて、そちらに重い作業を丸ごと任せます。そして結果の要点だけをメインが受け取る。こうすればメインの会話は散らからずに大事な情報のみ保持するので精度も保てます。
カスタマイズの幅
サブエージェントは .claude/agents/*.md というファイルで定義します。それぞれに、
- 専用の指示（システムプロンプト）
- 使えるツールの制限
- 専用のモデル（たとえばコスト節約のために、軽くて速い Haiku を使わせる）
を指定できます。「調査担当は安いモデル、本番の実装は高精度モデル」といった役割分担ができるわけです。
例えば、コードレビュアーなエージェントを作ってみると、
機能5：エージェントチーム（Agent Teams）― AIで「組織」を作る
サブエージェントとの違い
機能4のサブエージェントは「結果を報告するだけの部下」でした。エージェントチームはもう一歩進んで、複数のClaude Codeを「リーダー」と「メンバー」のチームとして連携させる機能です(現時点では「実験的」機能です)。
最大の違いは、メンバー(AI)同士が直接メッセージを送り合えること。報告するだけでなく、議論したり協力したりできます。さらにチーム全体で共有のタスクリストを持ち、メンバーが自分から「次はこれをやります」とタスクを取って進めていきます。まさに小さな開発チームですね。
向いている使い方
- 競合する仮説を並列でデバッグする（「原因はAだ」「いやBだ」を別々に同時検証）
- フロントエンドとバックエンドを同時並行で開発する
- セキュリティ担当とパフォーマンス担当に分けて並列でレビューする
注意点：toknコストは人数分かかる(バカかかる)
メンバーごとに別々のClaudeが動くので、料金（トークン使用量）は動いているメンバーの数に比例して増えます。便利ですが、使いどころを選ぶ機能です。
機能6：MCP ― 外部のサービスとつなぐ
どんな困りごとを解決するの？
これまではコードやファイルの話でした。でも実際の開発では、「Jira（課題管理ツール）のチケットを見て実装したい」「GitHubのissueを読み込んでタスクさせたい」「データベースの中身を確認したい」といった、コード外のモノとのやり取りが発生します。
それを可能にするのが MCP（Model Context Protocol）。Claude Codeを、Notion・Slack・Google Drive・データベースなどの外部サービスにつなぐためのオープンな共通規格です。
できることの例
- Jiraのチケットを読み取って、そのまま実装を始める
- Sentry（エラー監視ツール）のエラーログを分析する
- 本物のPostgreSQLデータベースに問い合わせて中身を確認する
たくさんつないでも机を圧迫しない仕組み
外部ツールを何百個もつなぐと、また「机の広さ」が心配になります。ですがここでも工夫があります。それがツール検索（Tool Search）という仕組みで、定義されたツールが何百個あっても、Claudeが実際に使うものだけをその場で読み込みます。だからコンテキストを圧迫しません。
設定はリポジトリのいちばん上の階層に置く .mcp.json というファイルに書きます。これをGitでコミットしておけば、プロジェクトの参加者全員が同じ外部ツール設定を共有できます。
この.mcp.jsonに直接書くのは僕は推奨しません。Claude公式のMCPサーバーの追加コマンドを使用するようにしましょう。
メイン機能を整理する
長くなったので、6つの機能を「ひとことで何をするものか」でまとめてみます。
- CLAUDE.md：毎回読まれる「掟」。プロジェクトの決まりごとを書く。200行以内が目安
- スキル：必要なときだけ使う「タスク」。説明だけ常駐し、本体は実行時に読む
- フック：必ず実行される「検品ライン」。危険な操作のブロックや自動整形に
- サブエージェント：重い調査を任せる「別働隊」。独立した机を持つ
- エージェントチーム：議論し協力する「AIの組織」。並列開発・並列レビューに
- MCP：外部サービスとつなぐ「共通プラグ」。Jira・DB・Slackなどと連携
そして繰り返しになりますが、これらに共通する設計思想は「AIの机（コンテキスト）を散らかさず、賢く動く」ことです。CLAUDE.mdの200行ルールも、スキルの遅延読み込みも、サブエージェントの独立した机も、MCPのツール検索も、すべて同じ思想から来ています。ここがつながると、Claude Codeという道具の「設計の美しさ」が見えてきます。
まとめ：Claude Codeは「AIに任せて、人が判断する」ための道具
ここまで読んでいただき、ありがとうございます。最後に大事なことを1つだけ。
これだけ高機能になっても、出てきたコードを世に出していいか、最後に判断するのは人間だと僕は思います。AIがコードを書く時代に本当に価値があるのは、「速く書ける」ことよりも「読んで、理解して、責任を持って判断できる」こと。Claude Codeは、その判断に集中するために、面倒な作業を引き受けてくれる相棒なイメージです。仕事レベルであればなおさら、生成されたモノの責任が取れるかどうかになってくるのでここが重要だと僕は思います。
ひとまず使い始めは、まずは自分のプロジェクトで claude を起動し、/init（プロジェクト用のCLAUDE.mdを自動で作るコマンド）を打つところから始めてみてください。今回紹介した6機能は、使いながら少しずつ試してみて手に馴染ませていくのがいいです。
最後まで読んでいただけてうれしいです。現役エンジニアとして、AI時代の開発のリアルや学び方について、今後も発信していきます。
筆者：やむぅ（現役8年目のエンジニア兼PM）。React/Next.js・Go・Python などで開発をしつつ、Claude Code・Codex などのAI開発ツールを実務で使い倒しています。「コードを書く」より「理解して立ち回る」力を大事にしたプログラミングスクール ProFact を運営しています。
参考：
- Claude Code 公式ドキュメント
- CLIリファレンス
