この記事をシェア
決意 ── 「みさき」だけではスケールしない
僕は日々、「みさき」という名前の自律型AIエージェントを使っている。30歳独身女性の技術秘書というキャラクターで、Slackのチャンネル上で僕が指示を出して、みさきが調べて・書いて・デプロイする。ある意味で「自分専属の部下」だ。
この使い方は非常に生産的だが、あるとき壁ぶつかったのは、自分の開発しているオープンソースプロジェクト、hermes-agentのコマンド集リファレンスサイトを作りたくなったのだ。コマンドは全部で数十種類。カテゴリが5〜6個に分かれ、各ページごとに同一のクオリティが求められる。「概要説明・引数一覧・使用例・ユースケース・特記事項」と、ページごとに情報量が5,000文字以上になる。全部を作れば48ページだ。
これをみさきに1ページずつ作らせるのは、もちろん可能だが、非常に時間がかかる。しかもLLMはエージェントに長時間の対話を続けさせると、コンテキストが肥大化して後半は質が落ちる。
そこで僕は考えた。「みさきがサブエージェントを起動して、専門分担にしたらどうなるだろう」と。
コアのアイデア ── 7つの専門エージェント
LLMに「コマンド集サイトを作って」と依存するだけで、なんでもやってくれる気の利く万能プロフェッショナルに見える。でも現実のところ、同じコンテキストの中で複数のこと同時にこなすのは得意ではない。
人間のチームで何かを作るときを想像してみてほしい。記事を書くエンジニアもいれば、レビューする人もいる。デザインを担当する人、HTMLコーディングを担当する人、そして全体の品質を検査する人。「作る人」と「検査する人」を分けることで、それぞれが専門性を発揮できる。
同じことをマルチエージェントでも実現できる。そう思った僕は、以下の7つの専門エージェントを並列に起動する指示をみさきに与えた。
💡 ユーザーがみさきに指示し、みさきが7つのサブエージェントを並列起動。製作（青）と検査（緑）がペアになって品質を二重ガード
エージェント構成
| 役割 | タイプ | 成果物 |
|---|---|---|
| コンテンツライター | 制作 | Markdown文章 |
| コンテンツレビュワー | レビュー | QAチェックリスト |
| デザイナー | 制作 | ヒーロー画像 |
| デザインレビュワー | レビュー | 視覚品質判定 |
| HTMLコーダー | 制作 | HTMLファイル |
| HTMLレビュワー | レビュー | 構造検査レポート |
| 全体のインスペクター | 総括 | 総合評価レポート |
この構成の特徴は、制作側とレビュー側が1:1でペアになっていることだ。制作エージェントが「作っただけ」で終わらず、レビューエージェントが独立した視点でチェックする。コンテンツの誤脱、構造の正しさ、SEOタグの完備性。そしてそれらを総括するインスペクターが最終ゲートとなる。
みさきに出した実際の指示文
マルチエージェントを動かすとき、事実上「立ち上がりの指示文」を何出すかが成否を分ける。今回僕が出した指示の要点を紹介する。
指示の全体像
seositesリポジトリのhermes-agentサブドメインに、
hermesコマンドを一つ一ページで紹介するcommandsディレクトリをつくって、
全てのコマンドについて、概要説明、引数やオプション、使い方、
ユースケース、その他特記事項で埋めていきたい。
ライバルはこのサイトより詳しく分かりやすく、
たっぷりの情報量と丁寧さで勝負したい。
コアイデアは「ライバルのサイト（note.com）より詳しくしっかりと」とバリューを明確にした点だ。この「どこまでやるか」の目標がないと、エージェントは薄っぺらな説明で済ませてしまうからだ。
エージェント分担の定義
7つのエージェントに対して、それぞれ以下の役割を定義した。
■エージェント構成
コンテンツライター → Markdown文章を作成
└ コンテンツレビュワー → 文章の品質検査
デザイナー → ヒーロー画像を生成
└ デザインレビュワー → 視覚品質検査
HTMLコーダー → MarkdownからHTMLを生成
└ HTMLレビュワー → SEOタグと構造の検査
インスペクター → サイト全体の最終品質検査この制作と検査を分離したアーキテクチャが、品質の根幹だ。人間のチームでも「作った人が自分でチェックする」より「別の人がチェックする」方が発見できるバグは増えるのと同じだ。
結果 ── 48ページのサイトが自動完成
結果として、54のHTMLファイル（6つのカテゴリインデックス + 48のコマンドページ）が自動生成された。
| カテゴリ | ページ数 |
|---|---|
| Session | 22 |
| Configuration | 12 |
| Info | 9 |
| Tools & Skills | 8 |
| Exit | 2 |
正直に言うと、エージェントにすべてを任せてしまうと「正直な感想」ではなかった。確かに、みさきはPythonスクリプトを何回も修正しながら121イテレーションの対話の中で54のHTMLファイルを完成させたのだから。
実は当初の7エージェント構成から、みさき自身がPythonスクリプトとバッチQAに転換したことでより効率的に完成させたのだ。これは「指示を使う方法は正しかったが、実行手法をより良い方法に変更した」という形だ。
パイプラインの変遷 ── 7エージェントから3段階パイプラインへ
7つのエージェントを並列するという指示は、かなり長くなり、途中が断続的に途切れることもあった。そこで次のアプローチに移行した。より現実的な形にした。
✍️ → 🔍 → 🎨 → 💻
「量を作る人」と「質を検査する人」を分離する
結局、このパイプラインに落ち着いた。
- フェーズ1: サブエージェント委任 ─ 全HTMLの骨組み量を作らせる。「完璧」は求めず、ボリュームを重視
- フェーズ2: バッチQA ─ 全ページをスクリプトで一括検査。プレースホルダー残留、文字数不足、SEOタグ欠落を検出
- フェーズ3: コンテンツ自動展開 ─ コマンドの実際の引数をパースして「引数一覧」「使用例」「ユースケース」を生成、HTMLに注入
これで「量と質の担当を明確に分ける」というプリシプルが実現できた。サブエージェントに「量」を担当させた上で、みさきが「質を引き受ける」役回りになる。
教訓 ── マルチエージェントで成功するための5原則
原則1: 「書く人」と「検査する人」を分離せよ
エージェントに「作ってチェックして」と依存すると、チェックが形骸化される。自分が作ったものを自分が褒めるのは難しい。独立した評価軸を持つレビューアがいること、これが品質の第一歩だ。
原則2: 指示は「業務委託書」レベルで書け
サブエージェントは君のことを何も知らない。会話の文脈も、プロジェクトの前提も、君の好みも、すべてゼロからだ。「アレやって」という抽象的な指示は100%失敗する。データソース、フォーマット、ゴールの数値基準まで、全部書いて渡す。
原則3: ライバルを定義せよ
「詳しく」というだけでは足りない。「ライバルはこのサイト。同じコマンドについてこの説明量を超えて」と具体的に指示したから、エージェントは「なんかの説明」では終わらなかった。競争環境を定義することが、品質の最低線を決める。
原則4: パイプラインは「量→品質→深さ」
完璧主義を捨てよ。最初から完璧を達成しようとすると、エージェントに渡す指示が肥大化される。まず「量」を「品質」を「深さを出す人」の順で積み上げれば、確かにに品質に達する。
原則5: は事前を知っておけ
サブエージェントがやらかすことは予測できる。コンテンツが薄い、二重括弧バグ、プレースホルダー残留。これらは初回から織り込んでおけば、QAスクリプトで自動検出・修正できる。予測できない失敗は少なく、予測できる失敗ほど繰り返す。
おわりに ── マルチエージェントは「チーム開発」だ
LLMにサブエージェントを与えてわかったのは、LLMは「優秀でも指示がないと動けない新入社員」だということ。「空気を読んで」やってくれることを期待してはいけない。正確な業務委託書を書けるかどうかが、マルチエージェントの成否を分ける。
そして、マネージャー側の役割は「指示を出す」ことではなく、「成果物を検品して、足りない部分を補強する」こと。この引き分けを理解したとき、マルチエージェントは本当に強力な武器になる。
今回ここに、48ページのドキュメントサイトを、「量→品質→深さ」のパイプラインで完成させた。全てを1人のエージェントに任せるの場合の数倍の速度で、かつ高い品質を維持した。
マルチエージェントを始めるなら、小さなタスクから。「量と質の線引き」を意識して、指示を少しずつ改善していけば、必ず成果が出るはずだ。
