Claude Codeエージェント実践 Day 14｜Week 2 まとめ — 部下育成モデルでエージェントを育てる
TL;DR
- Week 2 で「汎用エージェントをデータ分析の専門家に育てる」一連の流れを実践した
- この過程を 4フェーズの部下育成モデル（設計する → やらせてみる → 指導する → 任せる）として整理した
- 売上分析に限らず、繰り返す定型業務なら同じフレームワークで専門スキルを育てられる
作ったもの
Week 2 の成果物:
| 成果物 | 内容 |
|---|---|
| data-analysis-agent | データ分析に特化した Claude Code エージェント |
| Sales Skill | 売上データの定型分析を自律実行するスキル |
| サンプルデータ | BigQuery 環境構築用の CSV + DDL + ロードスクリプト |
# Week 2 で育てたエージェントの構成
data-analysis-agent/
├── CLAUDE.md ← 行動ルール定義
├── .claude/
│ ├── commands/
│ │ └── query.md ← /query コマンド（Commands 期）
│ └── skills/
│ └── sales-analysis/SKILL.md ← Sales Skill（Skills 期）
├── knowledge/
│ ├── business/ ← 業務ルール
│ ├── technical/
│ │ └── bigquery.md ← テーブル定義・クエリパターン
│ └── lessons/
│ └── knowledge-log.md ← ナレッジログ（タグ付き）
└── sample-data/ ← BQ 環境セットアップ用
├── ddl/
│ ├── create_tables.sql
│ └── load_data.sh
└── csv/
├── sales.csv (1,047件)
├── customers.csv (50件)
└── products.csv (9件)
agent-scaffold-factory（汎用テンプレート）から払い出して、データ分析の専門エージェントに育てた完成形です。リポジトリに含まれるサンプルデータで、BigQuery 環境を再現できます。
Week 2 の最終日です。今日は7日間で実践してきた内容を振り返りつつ、「部下育成モデル」という考え方を整理します。
Day 7 で共有した「2層のPDCA」が知識を蓄積するサイクルなら、今日の「部下育成モデル」は スキルを育てるサイクル です。2層のPDCA がエージェント全体の運用モデルだとすると、部下育成モデルはその中の1つの業務スキルを育てるための具体的な手順書にあたります。
検証環境
| 項目 | 値 |
|---|---|
| OS | Windows 11 |
| Claude Code | 最新版 |
| BigQuery | analytics データセット |
| 検証日 | 2026-02-14 |
Week 2 のおさらい
まず、Week 2 で何をしたかを振り返ります。
| Day | テーマ | やったこと |
|---|---|---|
| 8 | 専門エージェントの設計 | 汎用エージェントに「何を追加すれば専門家になるか」を設計した |
| 9 | bq CLI コマンドと MCP を追加 |
/query コマンドと BigQuery ナレッジを実装した |
| 10 | Cloud SDK 再インストール | 環境トラブルの対処（コラム） |
| 11 | 動かしてみる | 実際の売上データに /query を当てた。概ね動いたが問題も見つかった |
| 12 | フィードバックとナレッジ蓄積 | 3つの問題を指摘し、修正し、タグ付きナレッジとして記録した |
| 13 | 昇格チェックと Skills 化 | 4観点の昇格チェックを実施し、Sales Skill にパッケージした |
Day 8-10 は「作る側の話」、Day 11-13 は「使う側の話」でした。
この流れを振り返ってみると、新入社員を育てるプロセスと似ていることに気づきました。
部下育成モデル — 4つのフェーズ
全体像
Week 2 の経験を整理すると、エージェントのスキルを育てるには4つのフェーズがあるとわかりました。
| Phase | 部下育成の例え | エージェントの実装 |
|---|---|---|
| 1. 設計する | 業務マニュアルを用意する | Commands + ナレッジ + ツール |
| 2. やらせてみる | 最初の仕事を任せる | 実タスクで動かして結果を見る |
| 3. 指導する | レビューして指摘する | フィードバック → ナレッジ蓄積 |
| 4. 任せる | 権限を移譲する | 昇格チェック → Skills 化 |
Phase 3 は一度では終わりません。「指導する → 再テスト → まだダメ → また指導する」のループを繰り返し、十分なナレッジが蓄積されたら昇格チェックに進む流れです。
Phase 1: 設計する（Day 8-9）
部下の例え: 「来月から売上分析を担当してもらう。業務マニュアルと使うツールを用意しておく」
このフェーズでは、エージェントが業務を実行するのに必要な環境を整えます。
Week 2 で用意したもの:
| 追加したもの | ファイル | 役割 |
|---|---|---|
| コマンド | .claude/commands/query.md |
/query で分析を実行する手順書 |
| ナレッジ | knowledge/technical/bigquery.md |
テーブル構造・SQL方言・注意事項 |
| ツール | bq CLI + MCP Google Sheets | BigQuery へのアクセス手段 |
| ルール |
CLAUDE.md に出力形式を定義 |
3点セット（レポート + SQL + ローデータ） |
ポイントは、コマンドに「手順」を書くこと です。
# /query コマンド（抜粋）
## 実行手順
1. bigquery.md を参照してスキーマを確認する
2. 自然言語を SQL に変換する（Text-to-SQL）
3. **生成した SQL を提示し、実行前に確認を取る**
4. bq CLI で実行する
5. 3点セットで報告する
3番目の「確認を取る」が Commands 期の特徴です。新入社員に「必ず上司に見せてから送ってね」と指示するのと同じ。初めから自律的にやらせない。
設計フェーズで意識すること
私が Day 8-9 で意識していたことを整理します。
1. 既存のフレームワークに乗せる
ゼロから専門エージェントを作るのではなく、汎用エージェント（agent-scaffold-factory）に専門知識を追加する形にしました。CLAUDE.md の行動原則、ナレッジ管理の仕組み、Phase 管理のコマンドはそのまま使える。
2. ツール選定は「CLI があるなら CLI」
BigQuery には bq CLI がある。CLI は引数が明確で、エージェントが学習しやすい。MCP は CLI がないもの（Google Sheets など）に使う。
3. 出力形式を最初に決める
「3点セット」というルールを先に決めたことで、Day 11 以降の評価基準が明確になりました。「何を出力すべきか」が曖昧だと、指導のしようがなくなる。
Phase 2: やらせてみる（Day 11）
部下の例え: 「じゃあ、先月の売上を地域別にまとめてもらっていい？」
設計が終わったら、実際のタスクをやらせてみます。
Day 11 では、以下の2つの依頼をエージェントに出しました。
| # | 依頼 | 結果 |
|---|---|---|
| 1 | 先月の売上を地域別に見たい | SQL 生成 → 確認 → 実行 → 3点セット出力。成功 |
| 2 | カテゴリ別の粗利益も見たい | products テーブルとの JOIN を自分で判断。成功 |
概ねうまくいきました。ただ、よく見ると3つの問題が見つかりました。
| 問題 | 内容 |
|---|---|
| 日付ハードコード | 「先月」と言ったのに WHERE date >= '2026-01-01' と固定値を使った |
| 考察の混入 | 「バンドル戦略で粗利改善の余地あり」という提案がレポートに入った |
| スコープ逸脱 | 既存のレポートファイルを勝手に読んで統合した |
これは想定通りです。最初から完璧にやれる新入社員はいない。問題を発見すること自体が、Phase 2 の目的。
やらせてみるフェーズで意識すること
1. 最初は単純なタスクから
いきなり「月次レポート全体を作って」ではなく、「先月の売上を地域別に」から始めた。スコープを小さくすることで、何がうまくいって何がダメかを切り分けやすくなります。
2. 結果を記録する
エージェントの出力を残しておく。Day 12 のフィードバックの材料になる。
3. 感情的にならない
間違った出力が出ても「ダメだ」ではなく「なぜそうなったか」を分析する。エージェントは悪意でやっているわけではなく、知識やルールが足りないだけです。
Phase 3: 指導する（Day 12）
部下の例え: 「ここ、日付が固定になっているよ。こういう場合は CURRENT_DATE() を使ってね」
Phase 2 で見つかった問題を1つずつ指摘し、改善させます。
Day 12 で行ったフィードバックは3件:
| 問題 | フィードバック | 修正箇所 |
|---|---|---|
| 日付ハードコード | 「先月」は CURRENT_DATE() ベースにする |
bigquery.md にルール追加 |
| 考察の混入 | レポートはファクトのみ。考察は入れない | query.md の出力形式を修正 |
| スコープ逸脱 | 指示外のファイルを読まない | CLAUDE.md にスコープルール追加 |
修正後に同じ依頼を再テストし、改善を確認しました。
ナレッジの記録方法
ここで重要なのが、フィードバックをどう記録するかです。
Day 12 では「スキル候補ナレッジ」と「一般ナレッジ」の2種類に分けて記録しました。
# スキル候補ナレッジ（タグ付き）
## [analytics.sales] 2026-02-11 相対期間は CURRENT_DATE() を使う
- 状況: 「先月の売上を地域別に」と依頼したらハードコードされた
- 判断: CURRENT_DATE() ベースにする
- 確認: ルール追加後の再テストで2回とも改善（2026-02-12）
# 一般ナレッジ（タグなし）
## 2026-02-12 レポート再利用時のルール適用漏れ
- 内容: report_v2.md の出力時に v1 を勝手に読んで統合した
- 分類理由: 一回限りの事象。スキルに含めるものではない
タグの意味: [analytics.sales] というタグは「将来 Sales Skill に持っていくナレッジ」を示している。タグがあるものだけがスキル昇格の候補になります。
このタグ付け記録法については スキル化前提のナレッジ記録ガイド で詳しく解説しています。
指導フェーズで意識すること
1. 問題を再現可能にする
「なんか変だった」ではなく、「この依頼に対してこの出力が返ってきた」と具体的に記録する。
2. ルールを修正したら再テストする
フィードバックして終わりではなく、同じ依頼をもう一度やらせて改善を確認する。「確認済み」のフラグがないナレッジは、昇格チェックで使えません。
3. すべてをスキル化しない
一回限りの事象（環境依存、偶発的なもの）はスキル候補にしない。「何度も繰り返される判断パターン」だけをタグ付きナレッジにする。
Phase 4: 任せる（Day 13）
部下の例え: 「もう売上分析は一人で大丈夫だね。定型のものは確認なしで進めていいよ」
Phase 3 を繰り返してナレッジが蓄積されたら、「任せていいか」を判定します。
Day 13 で実施した昇格チェック:
| チェック観点 | 内容 | 判定 |
|---|---|---|
| ナレッジ蓄積 |
[analytics.sales] タグのナレッジが6件。クエリパターン4種 + ルール2種で売上分析を網羅 |
✅ |
| 動作安定性 | 同じ依頼に対して3回実行し、同等の結果（SQL構造・出力形式が一致） | ✅ |
| ルール遵守 |
CURRENT_DATE() 使用、SELECT * 未使用、考察なし、スコープ遵守 |
✅ |
| 出力品質 | 3点セットの形式、ファクトのみの記述、数値の正確性 | ✅ |
全項目合格 → Sales Skill にパッケージ。
Skills 化で変わること
昇格前後の比較:
| 項目 | Commands 期（/query） | Skills 期（Sales Skill） |
|---|---|---|
| トリガー | /query 先月の売上を地域別に |
「先月の売上を地域別に見て」 |
| SQL 確認 | 毎回確認 | 既知パターンは確認なし |
| クエリ設計 | 毎回ゼロから生成 | 蓄積パターンから選択 |
| 確認ステップ | SQL確認あり | なし |
ただし、既知パターン以外は引き続き確認を取る。「何でも自動」ではなく「この業務は自動」という限定的な移譲です。
任せるフェーズで意識すること
1. 昇格チェックなしに任せない
「なんとなくうまくいっているから」で任せると、いつか事故になる。チェック観点を明確にして判定する。
2. スコープを限定する
「データ分析全般」ではなく「売上分析の定型パターン」に限定した。スコープが広すぎると品質が担保できません。
3. 不合格なら戻る
昇格チェックに落ちたら Phase 3 に戻ってナレッジを追加する。昇格は目的ではなく結果。
フレームワークとしての部下育成モデル
ここまでは売上分析の具体例でした。ここからは、このモデルを他の業務にも使える 汎用フレームワーク として整理します。
4つのフェーズの抽象化
各フェーズの汎用チェックリスト
Phase 1: 設計する
- 対象業務の入力と出力が明確か
- 必要なツール（CLI / MCP）が揃っているか
- テーブル定義やスキーマのナレッジを用意したか
- コマンドに「確認ステップ」が含まれているか
- 出力形式を定義したか
Phase 2: やらせてみる
- 最初のタスクはスコープが小さいか
- エージェントの出力を記録しているか
- 問題があったら、原因を分析したか
Phase 3: 指導する
- フィードバックを具体的に伝えたか
- ルール修正後に再テストしたか
- ナレッジをスキル候補 / 一般に分類したか
- スキル候補にタグを付けたか
Phase 4: 任せる
- 昇格チェック4観点を実施したか（ナレッジ蓄積・動作安定性・ルール遵守・出力品質）
- スコープを限定しているか
- 不合格の場合に戻るパスがあるか
他の業務への適用例
売上分析で使ったこのモデルは、他の定型業務にも適用できます。
例1: 経費精算エージェント
| Phase | 内容 |
|---|---|
| 設計する | 経費カテゴリ定義、承認フロー、CSV取込コマンド |
| やらせてみる | 交通費精算を1件やらせる |
| 指導する | 「消費税の計算が違う」→ ルール修正 |
| 任せる | 交通費精算は自動、特殊経費は確認 |
例2: 議事録エージェント
| Phase | 内容 |
|---|---|
| 設計する | 議事録テンプレート、音声文字起こし MCP |
| やらせてみる | 定例会議の議事録を作らせる |
| 指導する | 「決定事項と議論中を区別して」→ テンプレート修正 |
| 任せる | 定例会議の議事録は自動生成 |
例3: 在庫管理エージェント
| Phase | 内容 |
|---|---|
| 設計する | 在庫テーブル定義、発注閾値ルール、bq CLI |
| やらせてみる | 「現在の在庫状況を見せて」 |
| 指導する | 「リードタイム考慮が抜けてる」→ ナレッジ追加 |
| 任せる | 日次の在庫レポートは自動 |
いずれも構造は同じです。繰り返す業務 + ツールでアクセスできるデータ + スコープを限定できる という3条件を満たすなら、このフレームワークが使えます。
適用の3条件
| # | 条件 | 理由 |
|---|---|---|
| 1 | 繰り返す業務である | 1回きりの業務は Skills 化する意味がない |
| 2 | ツールでデータにアクセスできる | CLI / MCP で操作できないとエージェントが手出しできない |
| 3 | スコープを限定できる | 「何でもやる」は品質が担保できない。対象を絞る |
逆に言えば、これを満たさない業務（一回限りの調査、人間の判断が中心の業務、ツールがない領域）は無理に Skills 化しないほうがいい。Commands のまま人間がトリガーし、毎回確認する運用で十分です。
Week 1 との接続 — 2層のPDCA × 部下育成モデル
Day 7 で紹介した「2層のPDCA」と、今日の「部下育成モデル」はどう関係するのか。
整理するとこうなります:
| 概念 | スコープ | サイクル |
|---|---|---|
| 2層のPDCA（Layer 2） | エージェント全体 | 案件を跨いで知識を蓄積する |
| 部下育成モデル | 1つの業務スキル | Commands → Skills への成長 |
2層のPDCA は「エージェントの運用基盤」であり、部下育成モデルはその上で「個別のスキルを育てる手順」です。
知識蓄積との連携
部下育成モデルの Phase 3（指導する）で蓄積されるナレッジは、2層のPDCA の Layer 2 に自然に組み込まれます。
Phase 3 で記録したナレッジ
├── スキル候補ナレッジ [タグ付き]
│ → Phase 4 で Skills に昇格
│ → knowledge/technical/ または Skills の一部になる
│
└── 一般ナレッジ [タグなし]
→ knowledge/lessons/ に蓄積
→ 3回繰り返されたら business/ にルール昇格
スキル候補ナレッジは部下育成モデルの中で消費される。一般ナレッジは 2層のPDCA で蓄積される。2つのサイクルが自然に連携している構造です。
ハマったところ
Week 2 を通じてハマったことを共有します。
問題1: 設計に時間をかけすぎた
症状: Day 8-9 でコマンドとナレッジを「完璧に」作ろうとして、なかなか Phase 2 に進めなかった。
原因: 設計段階で想定できることには限界がある。実際にやらせてみないとわからない問題が多い。
解決: 最低限動く状態（コマンド + テーブル定義）で Phase 2 に進み、問題が出たら Phase 3 で直す方針に切り替えた。
Day 12 で修正した3つの問題（日付ハードコード、考察混入、スコープ逸脱）は、いずれも設計段階では予測できなかったもの。完璧な設計を目指すより、早く Phase 2 に入るほうが結果的に速い。
問題2: Skills 化を焦った
症状: Day 11 の結果が「概ねうまくいった」ので、すぐに Skills 化したくなった。
原因: 「概ね」は「完全に」ではない。3つの問題を放置したまま Skills 化すると、自律実行時に事故になる。
解決: Day 12 でフィードバックを丁寧に行い、すべての問題を修正・再テストしてから Day 13 の昇格チェックに進んだ。
部下育成で言えば、「まだ心配なところがあるのに任せてしまう」のと同じ。急いで移譲すると手戻りが大きくなります。
問題3: ナレッジの分類に迷った
症状: 「これはスキル候補か、一般ナレッジか」の判断に時間がかかった。
原因: 判断基準が曖昧だった。
解決: 「この知識がないと、エージェントが同じ業務を自律的にこなせるか？」という問いに統一した。答えが「No」ならスキル候補。
例えば、「CURRENT_DATE() を使う」は Yes（これがないと毎回日付がハードコードされる）。「v2 という名前から v1 を推測した」は No（一回限りの推論ミス）。
Week 3 への接続
Week 2 では「1つのエージェントに1つのスキルを育てる」ことをやりました。
Week 3 では、ここからスコープを広げます。
具体的には:
- エージェントのモデリング: 「何をエージェント化すべきか」「どう分割すべきか」を設計する
- パイプライン: 複数のエージェントが協調して動く仕組みを作る
- 大量データの処理パターン: BigQuery だけでは完結しないケースへの対応
今回の売上分析エージェントは「依頼を受けて答える」というシンプルな構造でした。Week 3 では、「データを取る」「変換する」「レポートにする」というステップを複数のエージェントに分担させるパターンに挑戦します。
まとめ
- Week 2 で「汎用エージェントをデータ分析の専門家に育てる」一連の流れを実践した
- この過程を 4フェーズの部下育成モデル として整理した
- Phase 1: 設計する（ツール・コマンド・ナレッジを用意）
- Phase 2: やらせてみる（実タスクで動かし、問題を発見）
- Phase 3: 指導する（フィードバック → ナレッジ蓄積）
- Phase 4: 任せる（昇格チェック → Skills 化 → 移譲）
- このフレームワークは、繰り返す業務 + ツールでアクセスできるデータ + スコープを限定できる という3条件を満たすなら、売上分析以外にも適用できる
- 完成した data-analysis-agent は GitHub で公開。サンプルデータ付きで BigQuery 環境を再現できる
Week 2、お付き合いいただきありがとうございました。
Week 1 の「仕組みを作る話」から、Week 2 の「育てる話」に進みました。エージェントは設定して終わりではなく、使いながら育てるもの。そのプロセスを「部下育成」に重ねることで、非エンジニアの方にも伝わればいいなと思っています。
Week 3 では、複数のエージェントを組み合わせたパイプラインに挑戦します。引き続きよろしくお願いします。
シリーズを追いかける
Discussion