📌
#05 2つ目のエージェントを作る決断
2つ目のエージェントを作る決断
― “1体 → 2体”になった瞬間、世界が変わった ―
前回の記事では、
1つ目のエージェントを使い始めたことで見えてきた課題や、
次に必要な役割の“兆し”について書いた。
今回は、その兆しが 「決断」 に変わる瞬間の話。
## 🔥 2つ目のエージェントを作る決断は、意外と重かった
1つ目のエージェントが動き始めたとき、
「次も作ろう！」と勢いで行くかと思っていた。
でも実際は違った。
- 本当に必要なのか？
- 役割が重複しないか？
- 1つ目を拡張した方がいいのでは？
- エージェントが増えると管理が大変では？
そんな迷いがあった。
特に大きかったのは、
「エージェントを増やす＝複雑さも増える」
という現実。
だからこそ、2つ目を作る決断は慎重だった。
## 🎯 2つ目のエージェントの役割は“自然に決まった”
迷いはあったけれど、
1つ目のエージェントを使い込むうちに、
次に作るべき役割は自然と浮かび上がってきた。
それが 「テストスコープを作るエージェント」。
レビューだけでは業務は回らない。
そもそもレビューする“材料”が必要だ。
[仕様] → [テストスコープ] → [レビュー]
この最初の部分が手動のままだった。
だから、2つ目のエージェントは
「スコープ生成」 に決めた。
## 🎨 図解：2つ目のエージェントが必要になった理由
┌──────────────────────────────┐
│ 🐣 1つ目のエージェント（レビュー） │
└───────────────┬──────────────┘
│
▼
「レビューはできるけど…」
│
▼
┌──────────────────────────────┐
│ 📄 スコープが手動のまま… │
│ ・粒度がバラバラ │
│ ・書き方が人によって違う │
│ ・時間がかかる │
└──────────────────────────────┘
│
▼
┌──────────────────────────────┐
│ ✨ 2つ目のエージェント：スコープ生成 │
└──────────────────────────────┘
## 🧪 2つ目のエージェントを作るときに意識したこと
① 1つ目と役割が重ならないこと
- レビューは1つ目
- スコープ生成は2つ目
この境界線を明確にした。
② 1つ目のエージェントの“弱点”を補うこと
1つ目はレビューに特化している。
だから、スコープ生成は別のエージェントに任せる。
③ 2体になったときの“連携”を意識する
エージェントが2体になると、
急に“連携”が必要になる。
- スコープ生成 → レビュー
- 出力形式の統一
- 文脈の受け渡し
このあたりは、後々かなり効いてくる。
## 🛠️ 実際に作ってみて分かったこと
2つ目のエージェントを作った瞬間、
世界が変わった。
● 1体のときとは違う“システム感”が生まれる
「エージェントが複数いる」というだけで、
急に“チーム”っぽくなる。
● 役割の境界線が重要になる
曖昧にするとすぐに破綻する。
● 連携の設計が必要になる
1体のときは考えなくてよかった部分。
● エージェントが増えると、Vault構造が効き始める
Intent / Context / Agents / Result の流れが
本当に役に立つようになる。
## 🎨 図解：1体 → 2体になった瞬間の変化
[1体の世界]
┌──────────────┐
│ 🤖 Reviewer │
└──────────────┘
│
▼
「材料がない…」
[2体の世界]
┌──────────────┐ ┌──────────────┐
│ 📝 ScopeGen │ --> │ 🤖 Reviewer │
└──────────────┘ └──────────────┘
│ │
▼ ▼
「材料ができた！」 「レビューできる！」
## ✨ この時期の学び
- エージェントは“増やすこと”が目的ではない
- 必要性が自然に見えてきたときが作りどき
- 役割の境界線を明確にすることが大事
- 2体になると急に“連携”が必要になる
- Vault構造が本格的に効き始める
## 🚀 次回予告：第6回
「エージェントが2体になったことで起きた混乱と進化」
- 役割の境界線が曖昧になった瞬間
- 連携の難しさ
- 2体運用で初めて見えた“次の課題”
- 3体目の兆し
ここから、エージェント開発は
“単体開発”から“システム開発”へ
進化していく。
Discussion