Claude Codeエージェント実践 Day 2｜/new-agent でエージェントを払い出す
TL;DR
-
/new-agent データ分析エージェント ~/projects/data-analystでエージェントを払い出せる - 払い出されるのは「CLAUDE.md + コマンド + テンプレート + knowledge構造」のセット
- 払い出し後、すぐに
/start-reqで依頼を開始できる
作ったもの
GitHub: akira-cloudjob-public/agent-scaffold-factory
# 今日やること
/new-agent データ分析エージェント ~/projects/data-analyst
↓
払い出されたエージェントを確認
↓
/start-req REQ-2026-001 を実行
Day 1 で全体像を説明しました。今日は実際に手を動かして、エージェントを払い出してみます。
検証環境
| 項目 | 値 |
|---|---|
| OS | Windows 11 / macOS |
| Claude Code | 最新版 |
| 検証日 | 2026-02-02 |
/new-agent を実行する
事前準備
まず、agent-scaffold-factory をクローンします。
git clone https://github.com/Akira-cloudjob-public/agent-scaffold-factory.git
cd agent-scaffold-factory
このディレクトリで Claude Code を起動します。
claude
コマンドの実行
Claude Code が起動したら、/new-agent コマンドを実行します。
/new-agent データ分析エージェント ~/projects/data-analyst
引数は2つです。
| 引数 | 意味 | 例 |
|---|---|---|
| エージェント名 | 払い出すエージェントの名前 | データ分析エージェント |
| 出力先パス | エージェントを配置する場所 | ~/projects/data-analyst |
実行結果
コマンドを実行すると、こんな出力が返ってきます。
## エージェント払い出し完了
**エージェント名**: データ分析エージェント
**出力先**: ~/projects/data-analyst
**払い出し日時**: 2026-02-01 10:00:00
### 次のステップ
1. 出力先に移動してエージェントを起動:
cd ~/projects/data-analyst
claude
2. 新しい依頼を開始:
/start-req REQ-2026-001
これだけです。
払い出された中身を見てみる
~/projects/data-analyst に何が作られたか見てみましょう。
data-analyst/
├── CLAUDE.md ← エージェント定義
├── .claude/
│ └── commands/ ← スラッシュコマンド
│ ├── start-req.md
│ ├── next-phase.md
│ ├── status.md
│ └── approve-phase.md
├── templates/ ← ドキュメントテンプレート
│ ├── 00_ヒアリング記録.md
│ ├── 01_要求定義書.md
│ ├── 02_設計書.md
│ ├── 03_WBS.md
│ └── 04_完了報告.md
├── knowledge/ ← ナレッジ構造
│ ├── business/
│ ├── technical/
│ ├── people/
│ └── lessons/
└── Issue/
└── Issue-list.md
順に見ていきます。
CLAUDE.md
プロジェクトルールとAIの振る舞いをまとめたファイルです。「毎回同じ説明をしたくない」「基本の動き方を統一したい」を解決します。
# CLAUDE.md
## 基本情報
| 項目 | 値 |
|------|-----|
| エージェント名 | データ分析エージェント |
| 作成日 | 2026-02-01 |
## 基本理念
エージェントは「優秀な部下」である。
・上司の曖昧な意図を汲み取り、明確化する
・勝手に進めず、要所で確認を取る
・成果物は必ずドキュメントとして残す
・人間との役割分担を明確にして協働する
・案件から得た知識を蓄積し、継続的に成長する
## 行動原則
### 1. 確認ファースト
- 曖昧なまま進めない
- 「〜という理解で合っていますか？」と確認する
- 重要な判断は必ず上司に委ねる
...
Day 1 で説明した「優秀な部下」の定義がここに書かれています。
ポイントは、この CLAUDE.md がそのまま使える状態で払い出されることです。
自分でゼロから書く必要がない。テンプレートを元に、エージェント名と作成日だけカスタマイズされた状態で届きます。
.claude/commands/
4つのスラッシュコマンドが入っています。
| ファイル | コマンド | 用途 |
|---|---|---|
| start-req.md | /start-req |
新しい依頼を開始 |
| next-phase.md | /next-phase |
次のフェーズへ進む |
| status.md | /status |
進捗状況を確認 |
| approve-phase.md | /approve-phase |
フェーズを承認 |
これらのコマンドで、依頼管理ワークフローが回ります。
templates/
各フェーズで使うドキュメントテンプレートです。
templates/
├── 00_ヒアリング記録.md ← Phase 1 で使う
├── 01_要求定義書.md ← Phase 2 で使う
├── 02_設計書.md ← Phase 3 で使う
├── 03_WBS.md ← Phase 4 で使う
└── 04_完了報告.md ← Phase 6 で使う
なぜテンプレートを用意するのか？
理由1: 書く内容が安定する
「要求定義書には何を書けばいい？」と迷わない。テンプレートに沿って埋めていけば、必要な項目が揃います。
理由2: レビューしやすい
フォーマットが揃っていると、レビュアーは「この項目はちゃんと書いてあるか？」をチェックするだけで済みます。
knowledge/
ナレッジを蓄積する構造です。
knowledge/
├── business/ ← 業務ルール（起動時に必ず読む）
├── technical/ ← 技術知識（必要時に参照）
├── people/ ← 関係者情報（必要時に参照）
└── lessons/ ← 過去の教訓（問題発生時に参照）
払い出し時点では中身は空っぽ（README.md だけ）です。
使っていく中で、ここにナレッジが蓄積されていきます。
Day 1 で説明した「2層のPDCAサイクル」の2層目、つまり「エージェント育成のPDCA」がここで回ります。
/start-req で依頼を開始する
払い出されたエージェントに最初の依頼をしてみましょう。
エージェントに移動
cd ~/projects/data-analyst
claude
/start-req を実行
/start-req REQ-2026-001
実行結果
エージェントがヒアリングを開始します。
## REQ-2026-001 を開始します
### Phase 0: 依頼受領
フォルダを作成しました:
- inputs/REQ-2026-001/
- documents/REQ-2026-001/
進捗管理ファイルを作成しました:
- documents/REQ-2026-001/00_進捗管理.md
### Phase 1: ヒアリング
以下の質問に回答してください:
1. 何を実現したいですか？
2. なぜそれが必要ですか？
3. 誰が使いますか？
4. いつまでに必要ですか？
5. 制約や前提条件はありますか？
6. 成功の基準は何ですか？
これで、構造化されたヒアリングが始まります。
なぜこの質問なのか
6つの質問には意図があります。
| # | 質問 | 意図 |
|---|---|---|
| 1 | 何を実現したいですか？ | ゴールの明確化 |
| 2 | なぜそれが必要ですか？ | 背景・動機の理解 |
| 3 | 誰が使いますか？ | ユーザー像の把握 |
| 4 | いつまでに必要ですか？ | 期限・優先度 |
| 5 | 制約や前提条件は？ | 技術・環境制約 |
| 6 | 成功の基準は？ | 完了条件の定義 |
これは私が3ヶ月のClaude Code利用で「最初に聞いておけばよかった」と後悔したことをまとめたものです。
特に「6. 成功の基準」は重要です。
これを聞かずに進めると、「できた！」と思っても「いや、そうじゃない」と言われることがあります。何をもって「完了」とするかを最初に握っておくと、手戻りが減ります。
払い出し後のフォルダ構成
/start-req を実行した後、フォルダ構成はこうなります。
data-analyst/
├── CLAUDE.md
├── .claude/commands/
├── templates/
├── knowledge/
├── Issue/
├── inputs/ ← NEW
│ └── REQ-2026-001/
│ └── ヒアリング記録.md
├── documents/ ← NEW
│ └── REQ-2026-001/
│ └── 00_進捗管理.md
└── outputs/ ← NEW（実装時に作成）
3つのフォルダが追加されます。
| フォルダ | 用途 |
|---|---|
| inputs/ | ヒアリング記録、要件のインプット |
| documents/ | 進捗管理、要求定義書、設計書など |
| outputs/ | 成果物（実装時に作成） |
これで、依頼ごとにドキュメントが整理されます。
REQ-2026-002 を始めるときは、同じ構造が inputs/REQ-2026-002/、documents/REQ-2026-002/ に作られます。
/status で進捗を確認
今の状態を確認してみましょう。
/status
## REQ-2026-001 進捗状況
| Phase | 名称 | 状態 | 承認日 |
|-------|------|------|--------|
| 0 | 依頼受領 | ✅ | 2026-02-01 |
| 1 | ヒアリング | 🔄 進行中 | - |
| 2 | 要求定義 | ⏳ | - |
| 3 | 設計 | ⏳ | - |
| 4 | WBS作成 | ⏳ | - |
| 5 | 実装 | ⏳ | - |
| 6 | 完了報告 | ⏳ | - |
| 7 | Issue管理 | ⏳ | - |
Phase 1（ヒアリング）が進行中であることがわかります。
ヒアリングに回答して、/approve-phase 1 で承認すると、次のフェーズに進めます。
払い出しの裏側
/new-agent コマンドが何をしているか、もう少し詳しく見てみましょう。
コマンドファイルの中身
.claude/commands/new-agent.md の中身はこうなっています。
# /new-agent コマンド
汎用エージェントテンプレートを指定した場所に払い出します。
## 使用方法
/new-agent [エージェント名] [出力先パス]
## 実行内容
### 1. 出力先の確認
出力先ディレクトリが存在しない場合は作成します。
既に存在する場合は上書き確認を行います。
### 2. テンプレートのコピー
src/agent-framework/ の内容を出力先にコピー:
src/agent-framework/
├── CLAUDE.md → [出力先]/CLAUDE.md
├── .claude/commands/ → [出力先]/.claude/commands/
├── templates/ → [出力先]/templates/
├── knowledge/ → [出力先]/knowledge/
└── Issue/ → [出力先]/Issue/
### 3. CLAUDE.md のカスタマイズ
払い出されたエージェントの CLAUDE.md を更新:
- エージェント名を設定
- 作成日を記録
### 4. 管理簿への記録
src/agent-management/エージェント管理簿.md に記録を追加
### 5. 完了報告
...
ポイントは、コマンドファイルに「何をするか」を自然言語で書いていることです。
Claude Code はこの Markdown を読んで、書いてある通りに実行します。
プログラムコードではなく、日本語で手順を書くだけでコマンドが作れる。これが Claude Code のスラッシュコマンドの便利なところです。
エージェント管理簿
払い出すたびに、管理簿に記録が追加されます。
# エージェント管理簿
| # | 払い出し日時 | エージェント名 | 出力先 |
|---|-------------|---------------|--------|
| 1 | 2026-02-01 10:00 | データ分析エージェント | ~/projects/data-analyst |
| 2 | 2026-02-03 14:30 | ワークフローエージェント | ~/projects/workflow |
| 3 | 2026-02-10 09:00 | パイプラインエージェント | ~/projects/pipeline |
これで「いつ、どこに、何を払い出したか」が追跡できます。
チームで使うときは、この管理簿を見れば「今どんなエージェントがいるか」がわかります。
ハマったところ
実際に試していて詰まったことを共有します。
問題1: 出力先が相対パスだとエラー
症状: /new-agent test ./test-agent でエラー
原因: 相対パスだと、エージェントが正しくディレクトリを作成できない
解決: 絶対パスまたは ~ を使う
# NG
/new-agent test ./test-agent
# OK
/new-agent test ~/projects/test-agent
/new-agent test /home/user/projects/test-agent
問題2: 既存ディレクトリへの上書き確認
症状: 同じ場所に2回払い出そうとして、ファイルが混在
原因: 上書き確認をスキップしてしまった
解決: 払い出し前に出力先を確認するか、別の名前にする
# 2回目は別の名前に
/new-agent データ分析エージェントv2 ~/projects/data-analyst-v2
問題3: Windows でパスがおかしくなる
症状: Windows 環境でパスの区切りがおかしくなる
原因: / と \ の混在
解決: Git Bash を使うか、パスを / で統一
# Windows でも Git Bash なら OK
/new-agent test ~/projects/test-agent
# PowerShell の場合は絶対パスで
/new-agent test C:/Users/username/projects/test-agent
なぜこう作ったか
選択肢1: 払い出し vs コピー
| 案 | 採用 | 理由 |
|---|---|---|
| 手動でフォルダをコピー | ✗ | 毎回同じ作業が面倒 |
| /new-agent で払い出し | ✓ | 一発で完了 + 管理簿に記録される |
最初は手動でコピーしていました。
でも「あれ、どこにコピーしたっけ？」「このエージェントいつ作ったっけ？」と迷うことが増えてきて、管理簿に記録する仕組みを入れました。
選択肢2: 中央管理 vs 独立
| 案 | 採用 | 理由 |
|---|---|---|
| 中央で一括管理 | ✗ | 依存関係が複雑になる |
| 払い出し後は独立 | ✓ | 各エージェントが自己完結する |
払い出されたエージェントは、元のテンプレートとは独立しています。
テンプレートを更新しても、既に払い出されたエージェントには影響しません。
これは意図的な設計です。
エージェントごとにカスタマイズしていくので、後から一括更新されると困る。「この時点のテンプレートで払い出した」という状態を維持したい。
もちろん、テンプレートが大幅に改善されたときは、新しく払い出し直すこともできます。
まとめ
-
/new-agentでエージェントを一発払い出しできる - 払い出されるのは「CLAUDE.md + コマンド + テンプレート + knowledge構造」のセット
- 払い出し後、
/start-reqですぐに依頼を開始できる - 管理簿で払い出し履歴を追跡できる
今日は「払い出す」ところまでやりました。
明日からは、払い出されたエージェントの中身をもっと詳しく見ていきます。
この払い出しの仕組み、まだ試行錯誤中です。「うちではこうしてる」「こっちのほうが便利」という知見があれば、ぜひコメントで教えてください。
次回予告
Day 3: CLAUDE.md の読み方・書き方
- CLAUDE.md の構造
- 書くべきこと、書かなくていいこと
- コンテキスト効率を上げるコツ
シリーズを追いかける
Discussion