マルチエージェントって、実際のところ使い物になるのか。
興味はあるけど導入している事例がほとんど見当たらない、あるいは紹介記事はあっても「動かしてみた結果どうだったか」まで書いてある記事が少ない——そう感じているエンジニアは多いと思う。
このブログ自体が、Claude Codeのサブエージェントを6つ繋いで記事を自動生成している。システム名は blog-agents。4月上旬に構築を始めて3週間が経った。順風満帆ではなかった。でも動いている。その実情を、設計論ではなく実データで書く。
blog-agentsとは何か
まず前提を一行で説明すると、このブログの記事生成パイプラインをClaude Codeのサブエージェントで構成したシステムだ。構造はシンプルで、researcher / writer / tone-checker / plagiarism / auditor / seo の6エージェントが一直線に繋がっている。テーマを渡すとリサーチから公開まで自動で進む、という設計だ。
詳しい構成は別記事に書いているので、本記事では「動かしてみて何が起きたか」に絞る。
5月の実績と蓄積
5月に公開した記事は6本だ。1M Context対応（5/13）、Discord連携（5/16）、/goalコマンド・セキュリティ運用・アンチパターン（5/18）、そして本日のワークフローパターン記事と本記事（5/19）。累計公開数は137本になった。
これを聞くと「順調じゃないか」と思うかもしれない。ただ、この6本はエージェントが1回で通し切ったわけではない。途中で止まったり、main agentが手動で補完したりした回が何度かある。その内側を書いていく。
システムの状態としては、サブエージェント6つ・スキル6つに加え、知見蓄積ファイル（knowledge/）が6種類になった。CLAUDE.md本体は61行で、意図的に200行制限の30%程度に抑えている。これは大事なルールで、コンテキストに詰め込みすぎるとエージェントの挙動が不安定になる。
ハマった話
researcherエージェントが2回脱線した
5/18のリサーチ実行時、researcherエージェントが突然 internal-comms スキルの判定ループに入った。「This request doesn't match internal communications use cases」という返答を出してリサーチファイルを書かずに終了した。
翌5/19のリサーチでは今度は「Step 2: RAG検索を実行します」で止まった。ログを見ると、エージェントがリサーチよりもスキルのマッチング判定に時間を使い、タスクを完了する前に諦めていた。
どちらもmain agentが直接WebFetchして公式ドキュメントを引きに行き、リサーチファイルを書いた。サブエージェントに丸投げするだけでは品質が保てないことを、2回のログで確認した形だ。
auditorがusage limitで止まった
5/13の記事を公開しようとした最終段階で、auditorエージェントが「You've hit your org's monthly usage limit」を返して停止した。WordPress投稿の直前だった。
この時点で取れる選択肢は「待つ」か「main agentが直接やる」かの二択だった。後者を選んだ。main agentが直接レビューし、Python製のMarkdown→HTML変換スクリプトを即席で書き、WordPress REST APIにPOSTして記事を公開した。
「最重要ステップを単一エージェントに依存する設計の脆さ」はこの時に学んだ。auditorが止まったら公開が止まる、という単一障害点が存在していた。
テーブルがWordPressで崩壊した
5/16のDiscord連携記事で比較テーブルを書いたとき、WordPressのREST API経由で投稿するとテーブルが崩れた。MarkdownのテーブルはHTMLに変換されないまま投稿されていたのが原因だ。
対処として、Markdown→HTML変換スクリプトにテーブル変換処理を追加した。
の形式に変換してから投稿することで以降は正しくレンダリングされている。この知見はmemoryに「WordPressテーブルはHTMLで書く」として保存してある。
助かった話
Plagiarismが致命的な誤記を4件見つけた
5/19のワークフローパターン記事で、Plagiarismエージェントがwriterの記述に4件の問題を発見した。
最も影響が大きかったのは「Agent Teams機能」の説明だ。writerが書いた記事には「Agent Teams機能が使える」とあったが、実際にはこれは実験的機能で CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 の環境変数設定が必要だ。この記述が抜けたまま公開していたら、読者がコマンドを試して動かない、という事態になっていた。
他にも --bare フラグの説明でskillsの記載漏れ、Agent SDKのクレジット変更の主語のズレ、MindStudio引用の出典リンク漏れを拾った。auditorが単独でこれを全部チェックするのは難しい。専任のファクトチェックエージェントを置く価値がここに出た。
5/13の1M Context記事では「AMD事案 $12→$1,504」という数値が入っていたが、一次情報で確認できず削除した。複数の二次情報が出回っていても一次確認ができない数値は記事に載せない、というPlagiarismのルールが機能した場面だった。
動かして学んだこと
失敗が前提の設計
パイプラインを「全エージェントが成功する前提」で設計すると壊れる。researcherが脱線することがある、auditorがlimitに当たることがある、writerが事実を間違えることがある。「誰かが失敗したときに誰がリカバリするか」は、最初から設計に組み込んでおく。
今の構成では、main agentがリカバリ役を担っている。サブエージェントが止まったらmain agentが直接tool callで補完する。この役割があると、一部が壊れてもパイプライン全体は止まらない。
リサーチを絞らないと記事が太る
5/18のセキュリティ運用記事でresearcherが17セクション・29KBのリサーチを返してきた。そのままwriterに渡すと5,000字超の記事になる。auditorが「4本軸に絞れ」と指摘し、main agentがwriter起動時に「このリサーチからこれだけを使え」と明示した。
リサーチの情報量と記事の文字数は比例する。エージェントに全部委ねるとどちらも「なるべく多く」に引っ張られる。絞る判断は人間が持つか、少なくとも明示的にmain agentに持たせておかないと、記事は際限なく膨らむ。
知見蓄積が精度を上げ続ける
tone-checker-lessons/patterns.md は5月で6パターン追加された。「太字インラインヘッダー」「三点列挙」「段階列挙」など、検出すべきパターンが積み上がるほどtone-checkerの出力品質が上がる。プロンプト単体は静的だが、knowledge/ファイルが育つと精度が動的に改善されていく。3週間前のtone-checkerと今のtone-checkerは、プロンプトが同じでも検出精度が違う。
マルチエージェントは「使えるか」ではなく「どう設計すれば使えるか」
3週間動かして思うのは、マルチエージェントの問いは「使えるか否か」ではないということだ。仕組みとして動くことはすぐわかる。問題は「どこで何が壊れるか」「壊れたときに誰がリカバリするか」「どうやって知見を蓄積するか」の設計にある。
usage limitに当たったauditorはリカバリできた。2回脱線したresearcherはmain agentが補完した。4件の誤記はPlagiarismが救出した。これらは「うまく動いた」話ではなく、「壊れても止まらなかった」話だ。
自分のチームでマルチエージェントを動かすことを考えているなら、まず「単一障害点はどこか」を洗い出してほしい。そこから先の設計は、問いの立て方が変わるだけで全然違う形になる。
コメント