2026年1月30日に開催しました、コーディングエージェント勉強会#1～CLAUDE.mdとスラッシュコマンドで気軽に始めるClaude Code～の内容といただいた質問への回答内容を含めて、講師の伊志嶺さんが下記記事をブラッシュアップしてくれました！必見です👀
オンデマンド配信も行っております！下記よりお申込みください💻👀
peatix
Connpass
TECHPLAY
Claude Code をインストールしたものの、「何から始めればいいのかわからない」と感じていませんか。Skills、Agents、Hooks といった設定項目を調べるうちに、「自分にはまだ早いのでは」と思ってしまう方も多いかもしれません。
しかし、ご安心ください。実は、たった4つのポイントを押さえるだけで、Claude Code を効果的に使い始めることができます。本記事では、筆者自身の経験と社内勉強会での知見をもとに、今日から実践できる4つの Tips を深掘りしてお伝えします。
はじめに - なぜ Claude Code を選ぶのか
Cursor、CodeX、GitHub Copilot など、さまざまなコーディングエージェントが登場しています。その中で Claude Code が多くの開発者に選ばれている理由は何でしょうか。
まず挙げられるのは、Claude Opus 4.5 の高い性能です。コードの理解力、生成の正確さ、そして複雑な要件への対応力において、多くの開発者から高い評価を得ています。
しかし、それだけではありません。Claude Code には「Harness」と呼ばれるエージェント制御の仕組みが備わっています。Harness とは、Agents・Skills・Hooks といった機能群の総称であり、エージェントの自律性を高めながらも、決まった品質やルールに従ったコードを書かせることを可能にします。この Harness があることで、開発における一貫した品質を維持しやすくなります。
ツール選択の指針 - 少人数開発か、大規模チームか
筆者の経験から、ツール選択には開発チームの規模が大きく影響します。
少人数開発・個人開発には Claude Code がおすすめです。 Claude Code は Harness による高いカスタマイズ性を持ち、1人の開発者が大きな生産性を発揮できる設計になっています。自分の業務を効率化したい方や、少人数で開発を進めるチームには最適な選択肢です。
大規模チームには Cursor や GitHub Copilot が適している場合があります。 その理由は主に3つあります。
- モデルロックイン（特定モデルへの依存）の回避: Cursor は Claude だけでなく Gemini や GPT など複数のモデルに対応しています。将来的に別のモデルが優位になった場合でも、モデルを切り替えるだけで同じ仕組みを使い続けることができます。
- ガバナンスの整備: 大規模チームで多数のコーディングエージェントを運用する場合、Claude Code ではガバナンス（統制）の整備が難しい面があります。Cursor や GitHub Copilot は組織的な管理機能が充実しています。
- 横連携の課題: コーディングエージェントはタスク間の情報共有が苦手です。大規模チームで複数人が同時に開発を進める場合、この課題がより顕著になります。
ただし、大規模チームであっても、まず少人数で Claude Code を試してから判断するというアプローチは有効です。本記事で紹介する4つの Tips は、どのコーディングエージェントにも応用できる普遍的な考え方でもあります。
Claude Code での開発の流れ（概要図）
4つの Tips を組み合わせると、以下のような開発サイクルになります。まず全体像を把握してから、各 Tip の詳細に進みましょう。
1. タスク分解: まず、実装したい機能を「機能単位」で分解します（Tip 1）。たとえば ToDo アプリなら、「作成機能」「一覧表示」「編集機能」「削除機能」といった具合です。
2. Plan モードで計画: 各タスクを始める前に、Shift+Tab で Plan モードに切り替えます（Tip 2）。エージェントに計画を立てさせ、認識を合わせてから実装に入ります。
3. 実装と確認: 計画に沿って実装を進め、動作確認を行います。
4. /clear でリセット: タスクが完了したら /clear を実行し、コンテキストをリセットします（Tip 3）。これにより、次のタスクに集中できる状態になります。
5. 繰り返し: 2〜4 を各タスクごとに繰り返します。
6. /init で CLAUDE.md 更新: プロジェクトに大きな変更があったら /init を実行し、プロジェクトの説明書を作成・更新します（Tip 4）。
この流れを意識することで、Claude Code を効果的に活用できます。それでは、各 Tip を詳しく見ていきましょう。
Tip 1 - タスクは「機能単位」で分解する
Claude Code を効果的に活用するための最初のポイントは、タスクの分解方法にあります。ここで重要なのは、「技術スタック」ではなく「機能単位」で分解するという考え方です。
なぜ機能単位なのか
従来の開発では、「まずデータベース設計をして、次にバックエンドの API を作り、最後にフロントエンドを実装する」という技術スタックごとの分担が一般的でした。人間のチームでは、フロントエンド担当・バックエンド担当というように、それぞれの得意分野に応じた分業が自然だったためです。
しかし、コーディングエージェントを使う場合、この分け方は効率的ではありません。その理由は、コーディングエージェントはタスク間で情報を共有することが苦手だからです。
たとえば、技術スタックで分けて「データベースのスキーマを設計して」「API を作って」「フロントエンドを作って」と別々のタスクとして依頼した場合、それぞれのタスク内では正しく動作するコードが書けても、いざ結合してみると動かない、ということが起こり得ます。API の仕様とフロントエンドの期待する形式が微妙にずれていたり、データベースの型とバックエンドの扱いが一致していなかったり。単体テストは通っても、結合テストが通らないという事態です。
そこで有効なのが、「機能単位」での分解です。具体例として、ToDo アプリを考えてみましょう。
技術スタックで分解した場合:
- タスク1: データベーステーブルを作成する
- タスク2: バックエンド API を実装する
- タスク3: フロントエンドを実装する
機能単位で分解した場合:
- タスク1: ToDo の作成機能を実装する（DB、API、UI すべて含む）
- タスク2: ToDo の一覧表示機能を実装する
- タスク3: ToDo の編集機能を実装する
- タスク4: ToDo の削除機能を実装する
機能単位で分解することで、エージェントは1つのタスク内でデータベースからフロントエンドまでを一気に実装できます。結合テストもその場で行えるため、動作確認が確実になります。
認知負債（Cognitive Debt）を防ぐ
タスクを機能単位で分解するもう1つの重要な理由があります。それは「認知負債」の防止です。
認知負債とは、コーディングエージェントに実装を任せすぎた結果、コードがどういう状況になっているか誰も把握できなくなる状態を指します。技術的負債（Technical Debt）がコードの品質に関する問題であるのに対し、認知負債はコードに対する人間の理解に関する問題です。
エージェントに大きなタスクをまとめて依頼すると、一度に大量のコードが生成されます。その結果、人間がコードの内容を確認しきれず、何が実装されているのか把握できないまま開発が進んでしまいます。
タスクを機能単位で細かく分解すれば、1つのタスクが完了するたびに人間がコードをレビューし、動作を確認できます。「この機能はこう実装されている」と理解した上で次のタスクに進むことで、認知負債の蓄積を防ぐことができます。
タスク粒度の考え方
ここで重要なのは、タスクの粒度はできる限り細かくするという点です。タスクが大きくなるほどエージェントが把握すべき情報も増え、性能が落ちやすくなります。ただし、細かくしすぎて結合テストや E2E テストができなくなっては本末転倒です。**「結合テストができる最小単位」**を意識してタスクを切り分けることが、Claude Code を効果的に使うコツです。
一方で、タスクの内容を細かく定義しすぎる必要はありません。 先ほどの ToDo アプリの例のように、「作成機能を実装する」「一覧表示を実装する」程度のざっくりとした粒度で十分です。実装を進める中で最適な形が見えてくるため、事前に詳細な仕様を決めすぎないことも大切です。
大事なのは、人間がタスクの完了ごとにちゃんと結果を確認し、想定通りの実装がされているかを見ながら少しずつ進めていくことです。
並列タスク実行の注意点
複数のコーディングエージェントに同時にタスクを任せたくなることがあるかもしれません。しかし、前述の通り、コーディングエージェントは横の連携が苦手です。
結合テスト単位でタスクを分けて、それぞれを別のエージェントに同時に実行させると、競合（コンフリクト）が発生する可能性があります。あるエージェントが変更したファイルを別のエージェントも同時に変更しようとする、といった事態です。
そのため、基本的には 1人の開発者が順番にタスクを進めていくスタイルが推奨されます。 Claude Code は少人数で大きな生産性を発揮する設計であり、1人が集中してタスクを1つずつ完了させていく方が、結果的に効率が良くなります。
Tip 2 - まずは Plan モードで全体を把握させる
Claude Code には「Plan モード」という機能があります。Shift+Tab で切り替えることができ、エージェントに実装前の計画を立てさせることができます。
[screenshot:Claude Code の画面左下に表示される「Plan」モード表示。Shift+Tab で切り替えた状態を示す]
Plan モードの基本と2つのメリット
Plan モードでは、エージェントがタスクを受け取った後、すぐにコードを書き始めるのではなく、まず以下のことを行います。
- タスクの要件を整理する
- 既存のコードベースを確認する
- 不明点や確認すべき事項を洗い出す
- 実装の計画を立てる
「いきなりコードを書かせればいいのでは」と思われるかもしれません。しかし、Plan モードを使うことで、2つの大きなメリットが得られます。
1つ目は、認識違いを事前に防げることです。たとえば、「ToDo の作成機能を実装して」とお願いしたとき、Plan モードを使わないと、エージェントは自分の解釈でどんどん実装を進めてしまいます。後から「ここは違う」「この項目も必要だった」と気づいても、修正に時間がかかることがあります。
Plan モードを使うと、エージェントは「ToDo には期限日を含めますか」「優先度の項目は必要ですか」といった確認を事前に行ってくれます。この段階で認識を合わせておくことで、手戻りを大幅に減らすことができます。
2つ目は、生成されるコードの品質が上がることです。Plan モードでは、エージェントがタスクの全体像を把握してから実装に入ります。「この機能にはどんなコンポーネントが必要か」「API の設計はどうすべきか」「エラーハンドリングはどこで行うか」といったことを事前に整理するため、場当たり的ではない、一貫性のあるコードが生成されやすくなります。
Plan モードを使わないと、エージェントは場当たり的な実装をしてしまい、何度やってもうまくいかないという状況に陥ることがあります。
失敗例と対処法
Plan モードを使っていても、エージェントが想定と異なる計画を立てることがあります。筆者が実際に経験した例を紹介します。
「ToDo の作成機能のみを実装して」と指示したところ、エージェントは計画の中に削除機能まで含めようとしていました。計画をよく確認すると、「フロントエンドに削除ボタンを配置する」という項目が含まれていたのです。
このような場合は、計画の修正を指示してから再度プランを作成させます。 たとえば「削除機能は不要です。作成機能のみに絞ってください」と伝えれば、エージェントは計画を修正してくれます。
Plan モードでの失敗を減らすためのポイントは以下の通りです。
- 命令文に十分なコンテキストを含める: 何をしてほしいかだけでなく、何をしてほしくないかも明示します。
- 既存実装の参照を指示する: 「既存の実装を参考にして」と伝えることで、プロジェクトの方針に沿った計画が立ちやすくなります。
- 計画を必ず確認する: 変更対象ファイル、実装内容、検証方法など、計画の各項目を丁寧に確認します。特にエージェントが余計な変更をしようとしていないかに注意してください。
Tip 3 - /clear と /compact を使い分ける
/clear は Claude Code を使う上で、一番使うと言っても過言ではないコマンドです。
/clear
[screenshot:Claude Code で /clear コマンドを実行した直後の画面。コンテキストがリセットされ、新しいセッションが開始された状態]
/clear の基本 - なぜコンテキストリセットが重要か
コーディングエージェントの LLM（大規模言語モデル）は、会話が長くなるほど、また把握すべきコードが増えるほど、性能が低下する傾向があります。
これを理解するために、コンテキストを「短期記憶」に例えてみましょう。人間も一度に大量の情報を渡されると、最初に言われたことを忘れてしまったり、関係のない情報に引きずられて適切でない判断をしてしまったり、作業が雑になってしまったりします。コーディングエージェントもまったく同じです。
具体的には、コンテキストが増えすぎると以下のような現象が起こります。
- 会話の初期に伝えた情報を忘れてしまう
- 関係のないコードの情報に引きずられて、適切でない実装をしてしまう
- 同じ処理をぐるぐる繰り返し始める
- 応答が遅くなる
コンテキストは少なければ少ないほど良い -- これがコーディングエージェントを扱う上での基本原則です。必要な情報だけが入っている状態が、エージェントにとって最も望ましい状態です。
/clear を使うべきタイミング
では、いつ /clear を実行すべきでしょうか。主に2つのタイミングがあります。
1. タスクが完了した時
これは Tip 1 のタスク分解と連動しています。「ToDo の作成機能」を実装し、動作確認が完了したら /clear を実行し、「ToDo の一覧表示機能」に進む、という流れです。1つのタスクが終わるたびにコンテキストをリセットすることで、次のタスクに集中できる状態を作ります。
2. エラー修正に取り組む前
実装中にエラーが発生した場合、そのままの状態でエラー修正を指示するのではなく、一旦 /clear を実行してからエラー修正に取り組む方法が有効です。
なぜなら、それまでの実装過程のコンテキストが残っていると、エージェントが誤った前提に引きずられたまま修正を試みることがあるためです。一度コンテキストをリセットし、フラットな状態からエラーを調査させることで、先入観のない正確な修正が期待できます。
/compact を使うべきタイミング
Claude Code には /clear の他に /compact というコマンドもあります。/compact は、コンテキストを完全にリセットするのではなく、会話の要約を保持したまま圧縮するコマンドです。
/compact は、以下のような場合に使います。
- 1つのタスクの途中で、コンテキストが大きくなりすぎたと感じた時
- タスクが予想以上に大きく、途中でエージェントの精度が落ちてきた時
- コンテキストを引き継ぎたいが、会話が長くなりすぎた時
ただし、筆者の実感としては、/clear を使うことが圧倒的に多いです。 /compact は会話の要約を残してくれますが、その要約自体がコンテキストを消費するため、/clear ほどのリフレッシュ効果は得られません。また、Claude Code はコンテキストが上限に達すると自動的に /compact 相当の処理を実行してくれます。
迷った場合は /clear を選ぶ、というのが筆者のおすすめする指針です。
Tip 4 - コンテキストエンジニアリングを意識する
4つ目の Tip は、エージェントに与えるコンテキスト（文脈情報）を意図的に設計するという考え方です。その第一歩が /init コマンドによる claude.md の作成です。
/init で CLAUDE.md を作成・更新する
プロジェクトに大きな変更があったら、以下のコマンドを実行してみてください。
/init
このコマンドは、プロジェクトのルートディレクトリに CLAUDE.md というファイルを自動生成します。CLAUDE.md は、Claude Code がすべての動作を行う前に最初に読み込む「プロジェクトの説明書」です。ここには以下のような情報が記載されます。
- プロジェクトの概要と目的
- 使用している技術スタック
- ディレクトリ構成
- コーディング規約やルール
- よく使うコマンド
CLAUDE.md があることで、/clear でコンテキストをリセットした後も、エージェントはプロジェクトの基本情報を素早く把握できます。逆に CLAUDE.md がないと、エージェントは毎回0の状態からプロジェクト全体を眺めて把握しようとするため、時間がかかる上に把握漏れが発生する可能性があります。
/init を実行するタイミングは、プロジェクトに大きな変更があった時です。例えば、新しい機能の追加、ディレクトリ構成の変更、ライブラリの導入など、プロジェクトの構造や全体像が変わるような変更があった場合が目安です。CLAUDE.md が古いままだと、エージェントが現在とは異なる状況を前提に行動してしまいます。
ただし、/init の実行にはある程度の時間がかかるため、小さな修正のたびに実行する必要はありません。作業時間とのトレードオフになります。
コンテキスト＝短期記憶という考え方
Tip 3 でも触れましたが、コンテキストエンジニアリングを理解する上で最も重要な考え方は、コンテキストはエージェントの短期記憶であるということです。
短期記憶が大きくなりすぎると、人間と同様にエージェントの判断力が鈍ります。必要な情報だけが適切に整理されている状態が、最もパフォーマンスを発揮できる状態です。
この考え方を持つと、以下のような行動が自然に導かれます。
-
CLAUDE.mdには本当に必要な情報だけを書く -
/clearを積極的に使い、コンテキストを小さく保つ - 大量のファイルを一度に読み込ませない
- 情報は必要な時にだけエージェントに取得させる
情報の置き場所を設計する
コンテキストエンジニアリングの実践として、情報をどこに配置するかの設計が重要です。
CLAUDE.md に書くもの（不変の情報）:
- プロジェクトの概要と目的
- 使用技術スタック
- コーディング規約
- ディレクトリ構成の基本方針
- よく使うコマンド
- 「ユーザーとの会話は全て日本語で行うこと」などの基本ルール
別ドキュメントに書くもの（変化する情報）:
- 現在の実装状況
- 進行中のタスクリスト
- 画面遷移図
- 機能仕様の詳細
別ドキュメントに配置した情報は、CLAUDE.md にその場所を記載しておき、Claude Code が必要な時に参照できるようにします。こうすることで、CLAUDE.md の読み込み時点では最小限のコンテキストで済み、必要な情報だけをその都度取得するという効率的な運用が可能になります。
Agents / Skills に書くもの（役割・能力に関する情報）:
- 特定の役割に必要な手順やルール（Agents）
- 特定の作業に必要な能力やプロンプト（Skills）
これらは Claude Code の高度な機能ですが、コンテキストを役割や能力ごとに分離できるため、コンテキストエンジニアリングの観点からも有効です。詳しくは「次のステップへ」のセクションで紹介します。
CLAUDE.md は Claude Code に編集させる
CLAUDE.md を更新する際、手動で直接編集するよりも、Claude Code 自身に編集を指示する方法がおすすめです。
良い CLAUDE.md とは、できる限り短い文章で明確に要件を伝えるものです。しかし、そのような簡潔で的確な文章を人間が考えるのは意外と難しいものです。Claude Code に「この内容を claude.md に追記して」「この部分をもっと簡潔にして」と指示すれば、短く明確な文章に整えてくれます。
もちろん手動で編集しても問題はありませんが、エージェントに任せた方が効率的で、結果的に良い CLAUDE.md ができることが多いです。
Playwright MCP サーバーで動作確認を自動化する
4つの Tips とは別に、Web アプリ開発時にぜひ導入しておきたいツールを紹介します。それが Playwright MCP サーバーです。
Playwright MCP サーバーとは、コーディングエージェントが自律的に Web ブラウザを操作できるようにする仕組みです。MCP（Model Context Protocol）は、エージェントが外部ツールと連携するための標準的なプロトコル（通信規約）です。
導入は非常に簡単で、以下の1コマンドで完了します。
claude mcp add playwright -- npx @anthropic-ai/playwright-mcp@latest
Playwright MCP サーバーを導入することで、エージェントが実装後に自分で Web アプリを操作して動作確認（E2E テスト）を行えるようになります。「フォームに値を入力して送信する」「ボタンをクリックして画面遷移を確認する」といった操作をエージェントが自律的に実行してくれるため、人間がブラウザを操作して確認する手間を大幅に削減できます。
Web アプリ開発の場合は、ぜひ最初に導入しておくことをおすすめします。
まとめ - 4つの Tips で今日から始めよう
本記事では、Claude Code を効果的に使いこなすための4つの Tips を深掘りして解説しました。
-
タスクは「機能単位」で分解する -- 技術スタックではなく、結合テストできる機能単位で分割します。認知負債を防ぐためにも、1つずつ完了させて確認しながら進めましょう。タスクの粒度はざっくりで構いません。
-
Plan モードで全体を把握させる -- Shift+Tab で Plan モードに切り替え、実装前に計画を立てさせます。計画が想定と異なる場合は修正を指示し、承認後は
/clearしてから実装に入ると精度が上がります。 -
/clear と /compact を使い分ける -- コンテキストは短期記憶です。タスク完了時やエラー修正前に
/clearでリセットし、エージェントの性能を維持しましょう。迷ったら/clearを選ぶのがおすすめです。 -
コンテキストエンジニアリングを意識する --
/initでclaude.mdを最新に保ち、情報の置き場所を設計します。不変の情報はclaude.mdに、変化する情報は別ドキュメントに配置しましょう。
敷居が高く見える Claude Code ですが、実はこの4つだけで十分に使い始められます。 まずはシンプルなプロジェクトで、これらの Tips を実践してみてください。
次のステップへ
基本を押さえたら、次は Claude Code のより高度な機能に段階的に挑戦してみましょう。以下の順序で学んでいくことをおすすめします。
1. カスタムスラッシュコマンド
よく使うプロンプトをテンプレートとして保存し、スラッシュコマンドで簡単に呼び出せるようにする機能です。たとえば /create-pr（プルリクエスト作成）のように、繰り返し使う命令を定義しておくことで、入力の手間を省けます。最も手軽に始められる拡張機能です。
2. Skills（能力）
Skills は、コーディングエージェントに持たせたい「能力」を定義する仕組みです。画像生成、特定のフレームワークでのコーディングなど、特定の作業に必要な知識や手順をスキルとして定義できます。また、コミュニティで公開されているスキルをプラグインとしてインストールすることもできます。
3. Agents（役割）
Agents は、コーディングエージェントに「役割」を持たせる仕組みです。Skills が「能力」であるのに対し、Agents は「部下」のようなものだと考えてください。バックエンド担当、フロントエンド担当のように役割を分けることで、それぞれのエージェントが担当範囲に集中できます。
Agents の最大のメリットは、コンテキストの分離です。サブエージェント（部下）が調査や実装で使ったコンテキストは、メインのエージェント（上司）には持ち込まれません。上司は結果だけを受け取ればよいため、コンテキストが肥大化しにくくなります。これはコンテキストエンジニアリングの観点から非常に有効です。
4. Hooks（自動処理）
Hooks は、特定のイベントに応じて自動的に処理を実行する機能です。たとえば、特定の拡張子のファイルを編集した時にリンターやフォーマッターを実行する、タスク完了時に Slack に通知を送る、といった自動化が可能です。
これらの機能は、本記事で紹介した4つの Tips を習慣化した後に、徐々に取り入れていくことをおすすめします。焦る必要はありません。まずは基本を身につけ、Claude Code での開発に慣れてから、次のステップに進んでいきましょう。
最後までお読みいただき、ありがとうございました。
これからも役立つ技術情報をお届けしますので、ぜひフォローお願いしますす！
💡コーディングエージェント勉強会#2 開催決定！！！💡
大好評につき、第2弾を2月27日（金）に開催いたします。
▼▼お申込みはこちらからお願いします🌟▼▼
また、アポロでは仲間を積極募集中です！
ご興味のある方は是非求人をチェックしてみてください！