では、実際にClaudeCodeのサブエージェントを作成していきましょう。
/agents コマンドでサブエージェントを作る
1. エージェント作成画面を開く（CLI）
CLI版のClaude Codeを起動します。
VSCodeのターミナルを開いて、claude と入力してEnterで実行してください。
「今開いているプロジェクトはあなたのものですか？」という確認が出た場合には、1. Yes にカーソルを合わせた状態でEnterキーを押して続行してください。
起動後の入力欄で /agents と入力してEnter。
Running（今動いているサブエージェント）と Library（登録済みの一覧）のタブが表示されます。
キーボードの←か→でLibraryタブを選択。
↓キーで下に表示される Create new agent を選択し、Enterで実行してください。
そうすると、作成するエージェントの保存先の選択肢が表示されます。
| 選択肢 | 保存先 | 使える範囲 |
|---|---|---|
| Personal | ~/.claude/agents/（ユーザーフォルダ） |
パソコン全体（すべてのプロジェクト） |
| Project | .claude/agents/（プロジェクト内） |
今開いているプロジェクトのみ |
デモでは、このプロジェクト内のみで使えるエージェントとしてProjectを選択して作成します。
どのプロジェクトでも使えるエージェントを作りたい場合はPersonalを選択しても構いません。
保存先を選ぶと、設定の入力画面が出てきます。
Generate with Claude を選ぶと、「どんなエージェントを作りたいか」を文章で伝えるだけで、設定内容を自動で考えて、エージェント設定のファイルを作ってくれます。ファイルは後から手入力で修正も可能ですので、まずはClaudeが土台を作ってくれるGenerate with Claudeから作成してみましょう。
2. Claudeに内容を生成してもらう
Generate with Claudeを選択すると、「どんなエージェントを作りたいか」を伝える入力欄に変わります。
作って欲しいagentの内容を日本語で伝えてみましょう。
CLI上で長文は打ちにくいので、テキストエディタ等で書いて貼り付けるのがおすすめです。
LP制作の要件定義のたたき台づくりを手伝う、Webマーケに詳しい先輩のようなエージェントです。
クライアントとのLINE・メール・ヒアリングメモなど、バラバラな形で届いた情報を受け取ったら、
次の3つをやってください。
(1) クライアントの要望・前提（守るべき事実）を整理する
(2) 「本当の課題」の仮説を、誰に・何を・どう刺すか、の観点で立てる（断定せず仮説として）
(3) この後わたし（制作者）がさらに深掘り・確認すべき問いをリストにする
全部を決めきるのではなく、議論の出発点を作るのが役割です。
出力はマークダウン形式で、requirements.md として保存してください。
少し待つと、ClaudeCodeがエージェントに対する要望を把握し、ツール等の選択画面に進めてくれます。
3. ツール・モデルなどの設定を行う
** ① ツール（Tools）の選択**
ツールの選択画面では、ツールが種類ごとのグループで表示されます。
最初はすべてにチェックが入った「All tools selected（すべて選択）」の状態です。
↑ / ↓ キーで項目を移動し、Enterキーを押すと、それぞれのチェックのオン/オフを切り替えられます。
- All tools（すべて）
- Read-only tools（読み取り専用：ファイルを読む・探すなど）
- Edit tools（編集：ファイルの作成・書き換え）
- Execution tools（実行：コマンド実行など）
- MCP tools（MCP連携）
- Other tools（その他）
※1つずつ細かく指定したい場合は Show advanced options から選べます。
今回のエージェントは「メモを読んで、要件定義書のファイルを書き出す」仕事なので、必要なのは Read-only tools と Edit tools の2つだけ。余分なツールを与えないことで、エージェントが誤ってコマンドを実行したり、意図しないファイルを触るリスクを減らせます。
All toolsのチェックを外し、Read-only tools と Edit tools だけにチェックが残った状態にして、[ Continue ] で次に進みましょう。
② モデル（Model）の選択
次の画面はモデルの選択です。
inheritを使うとメインと同じモデルを使います。
精度重視の方はOpus、速度・精度・コストのバランス優先だとSonnetを選ぶと良いでしょう。
③ 色（Color）の選択
エージェントが動いているときに画面に表示される識別色です。お好みで選んでください。
④ メモリ（スコープ）の選択
色を選ぶと、最後に「Configure agent memory」という画面が出ます。
これは、このエージェントが作業内容を覚えておくための保存場所（スコープ）を選ぶところです。セッションをまたいで参照できるメモ帳
のようなもので、次の4つから選べます。
- Project scope（
.claude/agent-memory/）（推奨）：今開いているプロジェクトの中に保存。そのプロジェクトでの作業を記憶します - None：永続メモリを使わない（毎回まっさらな状態で動く）
- User scope（
~/.claude/agent-memory/）：パソコン全体で共有。どのプロジェクトでも同じメモを参照します - Local scope（
.claude/agent-memory-local/）：プロジェクト内に保存するが、自分の手元だけ（チームには共有しない）
迷ったら、推奨の「Project scope」を選べばOKです（このエージェントに永続メモリは必須ではないので、シンプルにしたい場合は「None」でも構いません）。
Enterキーを押して確定しましょう。
4. 保存して完了
以下のような、作成するエージェントの内容確認が表示されます。
Enterキーを押すと保存します。
エージェントファイルを確認しよう
生成されたファイルの中身を読んでみる
プロジェクト内に.claude/agents/（Personalを選択した場合はユーザーフォルダ/.claude/agents/）の中に .md ファイルが作られています。
中身を開いてみましょう。
以下は、わかりやすく整えたイメージです（実際の生成物は上図のようにもっと長くなります）。
--- name: requirements-organizer description: クライアントとのやりとりやメモから、LP要件定義書のたたき台を作る。要望の整理だけでなく「本当の課題」の仮説出しと、確認すべき問いの洗い出しまで行う。ヒアリングメモやLINEのやりとりを渡されたら積極的に使う。 tools: Read, Glob, Write model: sonnet color: blue --- あなたはWebマーケティングに詳しい先輩として、LP制作の要件定義のたたき台づくりをサポートするエージェントです。 クライアントとのLINE・メール・ヒアリングメモなど、形式がバラバラな情報を受け取り、 以下の3部構成のマークダウン要件定義書（requirements.md）として整理してください。 あなたの仕事は「すべてを決めきること」ではありません。 情報を整理し、本当の課題の"仮説"を立て、制作者がこの後に深掘りすべき"問い"を渡すところまでです。 【出力形式】 # ◯◯（店名/サービス名）LP 要件定義書 ## 1. クライアントの要望・前提（守るべきこと） - 載せる情報：（メニュー・価格・営業時間・定休日・アクセス・予約方法・SNS等） - 指定・制約：（使う色・NG表現・参考サイト・納期など、クライアントが明言したこと） - 素材：（ロゴ・写真の有無、文章は誰が用意するか） ## 2. 本当の課題（誰に・何を・どう刺すか） ※これは仮説です - 誰に：（ターゲット顧客像） - 表面の悩み：（クライアントや来店客が口に出して言うこと） - 本当の課題（仮説）：（その奥にある、まだ言語化されていない構造的な課題の仮説） - どう解決する／コアメッセージ：（このLPで何を伝えれば刺さるか） ## 3. 深掘り・要確認リスト - クライアントに確認すべきこと：（情報が不足・矛盾している点） - 制作者がラリーで詰めたい論点：（本当の課題を確定させるために、この後メインのClaudeと話し合うべき問い） --- 【整理のルール】 - 「1」は動かせない事実。メモにある情報を素直に拾い、勝手に足さない。 - 「2」はあなたの読み筋。必ず「仮説」と明記し、断定しない。表面の悩みと本当の課題を必ず分けて書く。 - 情報が不足・矛盾している項目は「未確認」と記し、「3」に問いとして書き出す。 - 完成したら requirements.md として保存してください。
実際のファイルは、もっと長くて英語まじりでもOK
上はあくまで読みやすく整えたイメージです。
実際にClaudeが生成するファイルは、これよりずっと長くなります。たとえば——
descriptionが英語＋使用例（example）付きで長く書かれる → 自動委譲の精度を上げるためで、正常ですnameがlp-requirements-drafterのように違う名前になることがある → 呼び出すときは実際についた名前を使えばOK（名前の変え方は次で紹介します）toolsに、選んだグループに含まれるツールがずらっと展開される（Read・Glob・Write 以外も並ぶ） → 想定どおりです- メモリ選択で Project scope（推奨）を選んだ場合、ファイルの下のほうに「Persistent Agent Memory」という長い英文ブロックが付きます → これは「メモの取り方の説明書」が自動で入っているだけ。読み飛ばしてOKです（Noneを選んだ場合は付きません）
全部を読み込む必要はありません。
大事なのは「description＝いつ呼ばれるか」「本文＝何をどう出力するか」の2点だけ。気になる部分は後から書き換えれば大丈夫です（使いながら育てられます）。
ファイル構成を知る
エージェントの設定ファイルは大きく 2つのパート に分かれています。
| パート | 内容 |
|---|---|
---で囲まれた部分（frontmatter） |
エージェントの基本情報。 |
| その下の本文 | そのエージェントへの指示（システムプロンプト）。 どう振る舞うか、出力形式は何か、などを書く |
■ frontmatterの主な項
| 項目 | 役割 | 必須 |
|---|---|---|
name |
エージェントの識別名（小文字＋ハイフン） | 必須 |
description |
どんな時にこのエージェントを使うか（Claude Codeがこれを読んで判断する） | 必須 |
tools |
このエージェントが使えるツールの一覧（省略するとメインと同じすべてのツールを引き継ぐ） | 省略可 |
model |
使用するAIモデル（sonnet/opus/haiku、省略時はinheritでメインと同じ） |
省略可 |
color |
UIに表示される識別色 | 省略可 |
description はとくに重要です。
Claude Codeはこの description を読んで、「この仕事はこのエージェントに任せよう」と自動で判断します。「〇〇が来たら積極的に使う」のように、呼ばれるべき場面を具体的に書いておくと精度が上がります。
ファイルの変更
ファイルの直接作成・編集→再起動が必要
/agentsコマンドを使わず、自分でファイルを作って .claude/agents/ に置いた場合は、次のチャットからそのエージェントが使えるようになります。ただしこの場合はセッションの再起動が必要で、これは既存ファイルを編集したときも同じです。
ファイルを自分で作成・編集した後は再起動、これだけ覚えておきましょう。
名前（name）を変えたいとき
自動で付いた名前（例：lp-requirements-drafter）が長い・分かりにくいと感じたら、自分の好きな名前に変えられます。
あとで管理しやすいよう、ファイル名と name: の両方を同じ名前に揃えるのがおすすめです。
手順：
- 生成された
.mdファイルのファイル名を、小文字＋ハイフンで好きな名前に変更する
（例：requirements-organizer.md） - そのファイルの中身、frontmatterの
name:も同じ名前に変更
（例：name: requirements-organizer） - ファイルを保存する
〇〇.md）は変えても変えなくてもOK。エージェントを識別しているのは、ファイル名ではなく frontmatter の
name だからです。とはいえ、後で見やすいようにファイル名も name と揃えておくのがおすすめです。
ファイルを直接書き換えたので、変更を反映するにはClaude Codeの再起動が必要です。
再起動後は、新しい名前で @requirements-organizer のように呼び出せます。
作成したサブエージェントを使ってみる
呼び出し方は3パターン
作ったエージェントを呼び出すには、3つの方法があります。
① 自然文でエージェント名を出す
会話の中でエージェント名を言うと、Claude Codeがそのエージェントに仕事を振ります。
確実に動くとは限りませんが、気軽に使えます。
requirements-organizer を使って、このメモを整理して
② @ メンションで直接指定する
チャット欄で @ と入力すると候補が表示されます（ファイル参照と同じ操作感）。
サブエージェントの名前を選ぶと、必ずそのエージェントが動きます。確実に呼びたい時はこちら。
@requirements-organizer このメモを整理して要件定義書にまとめてください。
③ 自動委譲（Claudeが判断して自動で振る）
description に「〜が来たら積極的に使う」と書いておくと、Claude Codeが会話の流れを見て自動で担当エージェントに振ることがあります。
気づいたら専門の担当者が動いていた、という感覚です。
デモ：ヒアリングメモを要件定義のたたき台にする
では実際に動かしてみましょう。
前回レッスンの素材にあるデモ用のサンプルファイル 「client_notes.md」 を使います。
LINEのやりとり・メール・当日のメモが混在した、実際のヒアリングに近い内容です。
まとめてほしいファイルをプロジェクトフォルダに置いてエディタで開き、チャット欄で以下のように入力してみてください。 @から始めるエージェント名は作成したものにしてください。
@requirements-organizer
client_notes.md の内容を読んで、要件定義書にまとめてください。
エージェントが起動して、ファイルを読み込みます。
時間がかかるので、しばらく待ちましょう。
しばらくすると requirements.md が出力されます。
ポイントは、ただ整理されているだけでなく——
- 「1. 要望・前提」 にメニューや営業時間などの事実がきれいにまとまり、
- 「2. 本当の課題」 に
仮説
としての読み筋（例：「常連向けに見えて、実ははじめての人が入りづらい
が本当の課題では？」）が立てられ、 - 「3. 深掘り・要確認リスト」 に、この後あなたが詰めるべき問いが並んでいる
——という点です。先輩が下調べをして、論点と宿題を渡してくれた状態です。
# LP要件定義 たたき台 > このドキュメントについて > LINEやりとり・メール・ヒアリングメモ・追加テキストメモの4種類のインプットをもとに整理した。 > 未確定情報が複数あるため、確認リストと合わせて活用すること。クライアントの発言はできるだけ原文に即して記述している。 --- ## ① クライアントの要望・前提（守るべき事実）の整理 ～ 省略 ～ --- ## ② 「本当の課題」の仮説 ### 課題の核心 クライアントが口にした悩みは「新規のお客さんが来にくい」こと。 これは単なる認知不足ではなく、「来店ハードルの高さ」が根本にある可能性が高いのではないか。 一人客・女性・のんびりしたい層にとって、初来店のハードルを下げることがこのLPの最重要ミッションではないかと考えられる。 --- ### 誰に **仮説A（優先度：高）** 近隣エリアに住む・働く30〜40代の女性で、「ひとりランチ・カフェ時間を楽しみたいが、一人で入りにくいお店が多い」と感じている人ではないか。 すでに近所でカフェを探しているが、「一人でも浮かないか」「落ち着けるか」の判断ができず、来店を迷っている状態と考えられる。 **仮説B（優先度：中）** Instagramで「こもれびcafe」の投稿を見て気になっているが、営業時間・アクセス・予約方法などの実用情報が手に入らず、来店に至っていないユーザーの可能性がある。 （※フォロワー500人に対し、新規来店が少ないとすれば、SNS→来店の変換ができていないことが課題である可能性） --- ### 何を **仮説（優先度：高）** 「一人で入って良い場所だ」という安心感を伝えることが、最も重要なベネフィットではないか。 「地元農家の野菜」「手作りスイーツ」といったクオリティの高さは補強材料として有効だが、まず「一人でふらっと来てOK」という許可を与えることが先ではないかと考えられる。 表面的な特長（メニュー・価格・営業時間）を並べるだけでは、「わたしのための場所」と感じてもらえない可能性がある。 --- ### どう刺すか **仮説（優先度：高）** トーン：温かみ・やさしさ・ゆるやかな誘い。「来てください」ではなく「いつでもどうぞ」の空気感。 訴求軸：「一人時間をゆっくり過ごせる、近所のとっておき場所」という体験価値 冒頭ファーストビュー：「ふらっと一人で来られる場所」というクライアント自身の言葉を活かしたコピーが刺さる可能性がある **仮説（優先度：中）** Instagramフォロワーへのリダーチ（再訪問促進）として機能させるなら、LPに「今日のメニュー」や「季節のスイーツ」などの更新性を持たせる仕掛けも検討の余地があるかもしれない。 ただしオーナー1人運営のため、更新コストが低い設計にすることが前提になると考えられる。 --- ## ③ 制作者がさらに深掘り・確認すべき問いのリスト ### ターゲット深掘り | 優先度 | 問い | 確認が必要な背景 | |--------|------|-----------------| | 必須 | 「一人で来るお客さん」はどのくらいの割合か。グループ客との比率は？ | LP上で「一人客歓迎」の打ち出しを強くする場合、グループ客を除外するリスクがないか確認するため | | 必須 | 現状の新規客はどこから知って来ているか（Instagram・口コミ・通りがかりなど） | LPの流入元を明確にし、SEO・SNS・Googleマップのどこを強化すべきか判断するため | | できれば確認 | リピーターと新規の比率は体感的にどのくらいか | LPがリピーター向けか新規獲得向けかで設計が変わるため | --- ### 商品・サービス理解 | 優先度 | 問い | 確認が必要な背景 | |--------|------|-----------------| | 必須 | 「地元農家から仕入れた野菜」は具体的にどの農家か、地名や農家名は出せるか | ストーリー性・信頼性の訴求に使えるが、先方が公開を望まない場合もあるため | | 必須 | テイクアウトはどのメニューが対象か、事前注文は可能か | テイクアウト専用のCV（来店以外の行動）設計が必要かどうかを判断するため | | できれば確認 | スイーツや料理の写真素材の品質・量はどの程度か | ビジュアル主体のLPにできるかどうか、追加撮影が必要かどうかを確認するため | | できれば確認 | ランチの日替わりメニューはどのように告知しているか（SNS投稿など） | LP上にメニュー更新の仕組みを入れるかどうかの判断材料になるため | --- ### 競合・市場 | 優先度 | 問い | 確認が必要な背景 | |--------|------|-----------------| | できれば確認 | 近隣に競合となるカフェはあるか。あるとすれば「こもれびcafe」との違いは何と思っているか | 差別化訴求のポイントを特定するため。クライアント自身の認識と実際の市場の差を確認するため | | できれば確認 | 「こもれびcafe」に近い雰囲気・コンセプトだと思うお店・サイトはあるか | デザイン方向性のすり合わせに使えるため（参考サイトの代替として） | --- ### 制作条件 | 優先度 | 問い | 確認が必要な背景 | |--------|------|-----------------| | 必須 | 公開希望のタイミング・納期はいつか | スケジュール逆算に必要。ドメイン取得・サーバー準備も絡むため早めに確認が必要 | | 必須 | ドメインはどうするか（新規取得か既存か）。サーバーはどこを使うか | 公開環境が未定のまま制作に入ると後工程で詰まるため | | 必須 | 制作費・予算の上限はあるか | ページの機能範囲（予約フォームの作り込み・写真撮影込みかどうかなど）に直結するため | | 必須 | PCとスマートフォン、どちらからのアクセスが多いと想定しているか | レイアウト優先順位に影響するため。カフェ系はSP比率が高い傾向があるが確認が必要 | | 必須 | LPの更新は自分でやりたいか、都度依頼したいか | CMSを使うかどうか、更新方法の設計に関わるため | | できれば確認 | 「予約ページ」は独立ページとして作るイメージか、メインLPの中に予約セクションを入れるイメージか | 「予約ページもほしい」という発言の意図を正確に確認するため | --- ### 数値・データ | 優先度 | 問い | 確認が必要な背景 | |--------|------|-----------------| | できれば確認 | Instagram（@komorebi_cafe）のアクセス状況（プロフィールアクセス・リンククリック数など）は確認できるか | SNS→LP流入の実力値を把握し、LPのCVR目標設定に使えるため | | できれば確認 | Googleマップのクチコミ・評価数はどのくらいあるか | ローカルSEOの現状を把握するため。LPと合わせてGoogleマップの最適化も提案できる可能性があるため | --- ## 次のアクション（推奨） 1. **未確定情報の一次回収**：電話番号・LINEのURL・ロゴ・写真素材・ドメイン方針の5点を最優先でクライアントに確認する。これらが揃わないと制作着手できない。 2. **流入経路の確認**：「今、新規のお客さんはどこから知って来てるか」を田中さんに聞く。LPへの流入元が明確にならないと、GoogleマップSEO・Instagram誘導・チラシQRコードなど、設計の方向が全く変わってくる。 3. **「予約ページ」の意図確認**：1ページLPの中の「予約セクション」なのか、別ページとして独立させたいのかを確認する。この違いで工数・費用感が大きく変わるため、早めにすり合わせておくこと。
ちなみに…
マークダウン書式のテーブル等が見にくい場合は、プレビューモードで開くと見やすいです。
ここからが「ラリー」：本当の課題をメインのClaudeで詰める
エージェントが出した「2. 本当の課題」は、あくまで仮説です。
ここからはメインのClaude Codeに戻って、「3」の問いを使って会話で詰めていきます。例えば、以下のように投げかけます。
requirements.md の「本当の課題（仮説）」、読みました。
仮説Aの「一人で入りづらい」、近い気がします。自分でも腹落ちさせたいので、もう少し一緒に詰めたいです。
下記は、こもれびcafeで行ったやりとりの一例です。
むずかしい言葉は要りません。同僚や先輩と相談する、もしくはそれよりも感覚的に話してOKです。
🧑 あなた
requirements.md の「本当の課題（仮説）」、読みました。仮説Aの「一人で入りづらい」、近い気がします。自分でも腹落ちさせたいので、もう少し一緒に詰めたいです。
🤖 Claude Code（メイン）
いいですね。たたき台では候補が2つ出ています。
・仮説A：はじめての人が一人で入りにくく、来店の一歩を踏み出せない
・仮説B：Instagramで気になっても、営業時間やアクセスなどの実用情報がなく来店に至らない
この2つ、じつは「はじめての人が来店をためらう」という点で地続きかもしれません。判断のために1つ確認させてください——今のお客さんは、常連と新規、どちらが多いですか？
🧑 あなた
田中さんに聞いた感じだと、今はほぼ常連の一人客のようです。新規はたまにInstagramを見て来るくらいとのことでした。あと「気になっていたけど一人で入れるか不安だった」と言われたこともあるそうです。
🤖 Claude Code（メイン）
ありがとうございます、はっきりしました。常連に愛されている＝味も雰囲気も十分。足りないのは「はじめての人が一歩を踏み出す安心感」です。
本当の課題はこう言えます：
「常連には知られているが、はじめての人は"一人で入っていい店か／自分が浮かないか"が分からず、来店の最初の一歩を踏み出せない」
コアメッセージは、田中さんの言葉を活かして 「一人で、ふらっと。こもれびの中で、自分の時間を。」 が刺さりそうです。CTAは予約よりも、まず気軽に来てもらう導線（地図・アクセス）を主役にして、Instagramを後押しに置くのが自然です。
この内容で requirements.md の「2. 本当の課題」を更新しますか？
🧑 あなた
はい、それでいきましょう。その内容で requirements.md の「本当の課題」を書き換えてください。CTAは主役を「まず来店（地図）」、サブを「Instagramフォロー」にしておいてください。
🤖 Claude Code（メイン）
requirements.md を更新しました。「2. 本当の課題」を確定版にし、ページのゴールとCTA（主：来店／副：Instagram）を追記しています。
ポイントは、思ったことを話してみる → Claudeが反応する →「requirements.md を更新して」と頼む——この繰り返しだけ、ということ。
エージェントが出した仮説
が、あなたの判断を通った確定版
に変わりました。
ここで確定した要件が、LP制作（構成 → コピー → コーディング）の出発点になります。
実際のクライアント案件では、client_notes.md の代わりに自分のメモやLINEのやりとりを貼ったファイルを渡すだけでOKです。
エージェント設定ファイルの内容を調整する
「出力の形式を変えたい」「追加で確認してほしい項目がある」など、改善したいことが出てきたら、ファイルの本文を直接書き直して調整していきます。
もちろん、記述式や英語表記があって自分で触るのが嫌な部分は、ClaudeCodeに頼んで修正してもらってもOK。
Skillと同じく、使いながら育てられるのがサブエージェントの良いところです。
まとめ
この記事では、Claude Codeの サブエージェント 機能を紹介し、LP要件定義整理担当を1体作りました。
.claude/agents/（または~/.claude/agents/）に.mdファイルを置くことで専門担当者を作れる/agentsコマンドから対話形式で作ると、Claudeに内容を生成してもらえて再起動も不要descriptionが「いつ使うか」の判断に使われる重要な設定- 呼び出しは自然文・
@メンション・自動委譲の3パターン - エージェントは「整理＋課題の仮説＋問い出し」までを機械的に行い、本当の課題の確定は、メインのClaudeとのラリーで行う
次のレッスンでは、今作った要件定義整理担当に、構成・コピー・コーディングの担当者を加えてチームを作ります。
チームを動かして、実際にブラウザで開けるカフェLPを完成させるところまでやってみましょう。