Claude Codeで専用スタッフを作る?!「サブエージェント」機能と設定方法をイチから解説します

「このままコーダーで、3年後も食べていけるだろうか？」
AIが進化するほど、手を動かすだけの作業者の単価は下がり続けます。これからのWeb制作で生き残るのは、AIに指示を出す「司令塔」側に回った人だけです。

14日間で「作業者」から「AI Webディレクター」へ転身する集中プラン『10倍速 AIワークフロー マスタープラン』を公開中です。プロの個別メンタリング＆8日間の全額返金保証付き。

（先着限定、6月21日まで）

» 「司令塔」側に回る14日間プランを見る

これまでの記事では、作業を登録してコマンド化するSkillsや外部ツールと連携するためのMCPを紹介してきました。今回ご紹介する サブエージェントもClaudeCodeで使える仕組みの一つで、ある業務を担当する専門スタッフを配置するような機能です。

この記事では、ClaudeCodeのサブエージェントの基本的な仕組みを理解しながら、クライアントとのやりとりやメモをLP（ランディングページ）の要件定義書に整理してくれる担当エージェントを1体作るところまでを体験します。

• Claude Codeのサブエージェントを知る
• 要件定義をアシストするエージェントを作ろう
• Claude Codeサブエージェント作成
• 作成したサブエージェント使ってみる
• まとめ

Claude Codeのサブエージェントを知る

サブエージェントとは

サブエージェントとは、特定の仕事に特化したAIを別に用意して、メインのClaude Codeが必要なときにその仕事を任せる仕組みです。

イメージとしては、専門スタッフをあなたの制作チームに加えるようなもの。
Skillがよく使う指示を一発で呼べる機能なら、サブエージェントは特定の仕事だけを専門に担当してくれるAIを別に用意する機能です。

たとえばLPを1ページ作るときでも、「要件をまとめる」「文章を考える」「コードに落とす」など様々な工程がありますよね。これをすべてメインのClaude Codeだけに任せると、会話がどんどん長くなり、途中から指示がぶれやすくなります。
そこで、工程ごとに専任の担当者（＝サブエージェント）を用意すると、それぞれが自分の仕事だけに集中できるため、結果がまとまりやすくなります。

たとえばこんなことができます。

メインのClaude Codeが「司令塔」となり、サブエージェントに仕事を振ります。
サブエージェントは与えられた仕事を片付けて、結果だけをメインに渡します。

あなたが実際に使用する際には、いつも通りClaude Codeに話しかけるだけでOK。
それだけでも、メインClaudeは「どのエージェントに仕事を振るか」判断してくれます。モデルの選択のように切り替える必要も、裏側でどのサブエージェントが動いているかを細かく意識する必要もありません。
もちろん「このサブエージェントに処理してほしい」と指定することもできますよ。

Skillとの違い

同じように「登録しておく」機能でも、SkillとサブエージェントはClaude内での動き方が異なります。

「別の作業スペース」とは、メインのClaude Codeとは切り離された場所でAIが動いているイメージです。ちょうど、同じ会社の別フロアで作業している同僚のような感じで、仕事が終わったら結果だけをメインに持ってきてくれます。使う側としては、この仕組みをあまり意識しなくて大丈夫です。

メリットはこういったところにあります。

• 本筋のやりとりが、作業ログで埋まらない
• 「ファイルを読むだけ」「メモを書くだけ」のような制限を担当ごとにかけられる
• 担当によって使うAIモデルを変えられる（速さ優先など）

どこに保存される？

サブエージェントは、フォルダの中に置いたマークダウンファイル（.md）として保存します。
Skillと同じく、置く場所によって使える範囲が変わります。

パソコン全体に効く場所（グローバル）
Windows: C:\Users\ユーザー名.claude\agents
Mac:     /Users/ユーザー名/.claude/agents/
└── requirements-organizer.md   ← サブエージェントのファイル
└── copywriter.md
└── coder.md

***

プロジェクトの中だけに効く場所（ローカル）
プロジェクトフォルダ/
└── .claude/
└── agents/
└── requirements-organizer.md

ファイル名は何でも構いません（nameという設定で識別されるため）。
まずはプロジェクト内（.claude/agents/ フォルダ）から試してみましょう。

要件定義をアシストするエージェントを作ろう

今回作るエージェントの完成イメージ

Web制作を請け負うと、クライアントからの情報がバラバラな形で届くことがよくあります。
最初の依頼時に条件として言われたこと、ヒアリングで聞き取ったこと、ヒアリング後に「さっきは○○って言ったけど…」とメールで送られてくる…。

「LINEでは営業時間、メールには別の指定が…

あのときのメモはどこに書いたっけ。

そもそも、このお店は何を一番伝えるべきなんだろう？」

これらの情報をまとめるだけでも一苦労。さらに、最初にまとめておくべき情報には性質の違う2つの層がある、ということも意識しないといけません。

①の「要望の整理」はAIが一発で得意な作業です。
一方②の「本当の課題」は、すぐには答えが出ません。クライアント自身も言葉にできていないことが多く、対話しながら少しずつ掘り当てるものです。

今回作るエージェントは、この2つの橋渡し役です。
バラバラなメモを受け取ると、①要望を整理し → ②本当の課題の仮説を立て → ③この後あなたが確認・深掘りすべき問いを並べて返してくれます。

完成すると、こんな流れになります。

①〜③をエージェントが、④をあなた＋メインのClaudeが担当する、という分担です。

クライアントヒアリングで確認しておきたい項目

ここで挙げる項目は、さきほどの①クライアントの要望・前提にあたる部分です。
ヒアリング経験がまだ少ない方向けに、LP制作でよく確認する項目をまとめておきます。
「何を聞けばいいかわからない」という場合は、このリストを参考にしてみてください。

より詳細なリストは、この記事で配布している素材にある 「ヒアリング確認項目リスト.md」 もご活用ください。
クライアントへのアンケートや、ヒアリング前のチェックシートとして使えます。

デモに使用した素材

クライアントからバラバラに送られてきたリクエストの見本を素材としてご用意しています。
サブエージェント作成をやってみたいけれど、架空案件を考えるの面倒だな…という方は素材をのままま使う、自分のクライアントを思い出して編集してご活用ください。

本記事で使用したサンプル（ヒアリング内容メモ）をダウンロード

Claude Codeサブエージェント作成

では、実際にClaudeCodeのサブエージェントを作成していきましょう。

/agents コマンドで作る

1. エージェント作成画面を開く（CLI）

CLI版のClaude Codeを起動します。
VSCodeのターミナルを開いて、claude と入力してEnterで実行してください。

「今開いているプロジェクトはあなたのものですか？」という確認が出た場合には、1. Yes にカーソルを合わせた状態でEnterキーを押して続行してください。

起動後の入力欄で /agents と入力してEnter。

Running（今動いているサブエージェント）と Library（登録済みの一覧）のタブが表示されます。
キーボードの←か→でLibraryタブを選択。
↓キーで下に表示される Create new agent を選択し、Enterで実行してください。

そうすると、作成するエージェントの保存先の選択肢が表示されます。

デモでは、このプロジェクト内のみで使えるエージェントとして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の主な項

description はとくに重要です。
Claude Codeはこの description を読んで、「この仕事はこのエージェントに任せよう」と自動で判断します。「〇〇が来たら積極的に使う」のように、呼ばれるべき場面を具体的に書いておくと精度が上がります。

ファイルの変更

ファイルの直接作成・編集→再起動が必要

/agentsコマンドを使わず、自分でファイルを作って .claude/agents/ に置いた場合は、次のチャットからそのエージェントが使えるようになります。ただしこの場合はセッションの再起動が必要で、これは既存ファイルを編集したときも同じです。
ファイルを自分で作成・編集した後は再起動、これだけ覚えておきましょう。

名前（name）を変えたいとき

自動で付いた名前（例：lp-requirements-drafter）が長い・分かりにくいと感じたら、自分の好きな名前に変えられます。
あとで管理しやすいよう、ファイル名と name: の両方を同じ名前に揃えるのがおすすめです。

手順：

1. 生成された .md ファイルのファイル名を、小文字＋ハイフンで好きな名前に変更する
   （例：requirements-organizer.md）
2. そのファイルの中身、frontmatterの name: も同じ名前に変更
   （例：name: requirements-organizer）
3. ファイルを保存する

ファイルを直接書き換えたので、変更を反映するには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. 深掘り・要確認リスト」 に、この後あなたが詰めるべき問いが並んでいる

——という点です。先輩が下調べをして、論点と宿題を渡してくれた状態です。

📄 出力された requirements.md の全文を見る ▾

# 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です。

💬 Claude Codeとの会話全文を見る ▾

ポイントは、思ったことを話してみる → 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とのラリーで行う

吉田 光利

Skillhub代表 & Edbase代表

教育者&起業家です。今は教育テック系のSkillhubとEdbase（エドベース）という会社をやっています。強みはビジネス構築からデザイン、プログラミング、サーバー構築までひと通できることです。著書に「起業のWeb技術」日本実業出版社があります。