複数のAIエージェント（自律的にタスクを分解・実行するソフトウェア）を組み合わせて開発業務を回す構成が、海外の開発者コミュニティで具体的な形になって公開されています。oh-my-hermesと呼ばれるオープンソースプロジェクトは、119個の「skill（スキル）」を41カテゴリに整理し、リサーチから計画・実行・レビューまでを一気通貫でこなす仕組みを持っています。
本記事は、複数のAIエージェントを社内ツールや開発パイプラインに組み込みたいと考えているアーキテクトやテックリードに向けた内容です。個々のスキルの使い方紹介ではなく、この規模のエージェント群を設計するときに何を非機能要件として押さえるべきか、という観点で整理します。
119スキル・41カテゴリという規模が意味すること
まず押さえておきたいのは、このプロジェクトの文書量です。ワークフローを定義したリファレンス文書は919キロバイト、文字数にして概ね70万字規模あります。
この規模のドキュメントを人力で全部読んで運用ルールを把握するのは現実的ではありません。実際にこのプロジェクトを分析した記事も、スクリプトでドキュメントを機械的にパースし、スキルごとの構造データを抽出する手法を取っています。
ここが設計上の重要な示唆です。エージェント基盤が大きくなるほど、人間が仕様を目視で追う運用は破綻します。エージェント自体の構成情報を構造化データとして持ち、機械的に検証・可視化できる状態を保つことが、スキル数が2桁を超えたあたりから必須になってきます。
具体的には、スキル定義をYAMLやJSONなど機械可読な形式で管理し、CI（継続的インテグレーション）で「未定義の役割を参照していないか」「循環依存がないか」といったチェックを自動化する設計が現実的な選択肢です。
役割（role）ベースの分担が可用性とセキュリティに効く理由
このプロジェクトでは、全スキルが9つの役割のいずれかを担う設計になっています。guide（案内役）、researcher（調査役）、planner（計画役）、operator（実行役）、memory-keeper（記憶管理役）、handoff-guide（引き継ぎ役）、builder（構築役）、tracker(進捗追跡役)、reviewer（レビュー役）の9種類です。
この役割分離は、マイクロサービスアーキテクチャにおける責務分割と似た発想です。1つのエージェントに全権限を持たせず、役割ごとに権限とコンテキストを絞ることで、暴走時の被害範囲を限定できます。
たとえばoperator役のスキルは、システムに直接コマンドを実行する権限を持ちます。これをresearcher役やguide役と明確に分離しておけば、調査目的で呼び出したエージェントが誤って本番環境に書き込む、といった事故を構造的に防ぎやすくなります。
セキュリティレビューを担当するreview系のスキルが7個用意されている点も見逃せません。コードレビュー・セキュリティチェック・法務チェックが個別のスキルとして独立しているのは、単一のエージェントに全チェックを担わせるのではなく、専門性ごとに検証プロセスを分割する設計判断だと読み取れます。
計画フェーズを厚くする設計は技術的負債の予防策
41カテゴリのうち、スキル数が最も多いのはoperations(運用・財務・人事支援など)の13個、次いでplanning(計画立案)が11個、research(調査)が10個という構成です。
注目したいのはplanningカテゴリの厚みです。planという基本の構造化計画スキルに加え、ralplan（レビューゲート付きの合意形成型プランニング）、adversarial-consensus（複数の視点から提案を批判的に検証する仕組み）といったスキルが用意されています。
これは、いきなりコードを書かせるのではなく、計画段階で複数の視点からレビューを通す設計思想の表れです。ソフトウェア開発において、要件の誤解や設計判断のミスは、実装後に発覚するほど修正コストが跳ね上がります。これはいわゆる「手戻りコスト曲線」と呼ばれる考え方で、上流工程でのレビューが技術的負債の予防に直結するという原則そのものです。
adversarial-consensusのように意図的に対立する視点を用意する設計は、単一のAIモデルの判断バイアスに依存しない仕組みとも言えます。1つのLLM（大規模言語モデル）が出した結論をそのまま採用するのではなく、複数の評価軸を通過させてから実行フェーズに進める、という多段階の意思決定プロセスです。
既存のワークフロー基盤との比較で見る位置づけ
この構成を評価する上で、既存の技術と比較しておくと理解が深まります。
CI/CDパイプラインにおけるステージゲート(各段階で条件を満たさないと次に進めない仕組み)や、GitHub Actionsのjob依存関係の設計思想と、oh-my-hermesのrole分離・レビューゲートの発想は近いものがあります。違いは、CI/CDが決定的なルールベースの検証であるのに対し、AIエージェントの役割分担は自然言語による判断を含む点です。
つまり、ルールで検証しきれない部分(要件の妥当性や設計の是非など)を、複数の役割を持つエージェントの合議で補おうとしている、という理解が近いでしょう。これは可用性やセキュリティの担保方法として、決定的な仕組み(スキーマ検証やテスト自動化)とAI判断を組み合わせるハイブリッド設計とも言えます。
一方で、AI判断を挟む部分は決定的な検証と違って結果の再現性が保証されません。同じ入力でも実行のたびに判断がぶれる可能性がある、という点は非機能要件として明確に認識しておく必要があります。
導入を検討する際に確認すべきポイント
自社でこの種のマルチエージェント構成を検討する場合、以下の点を確認しておくと判断がしやすくなります。
- スキル定義がテキストベースで管理されているか(バージョン管理・差分レビューが可能か)
- 各エージェントの権限がoperator相当の実行権とresearcher相当の閲覧権で分離されているか
- レビューゲートを通過しないと本番相当の操作に進めない設計になっているか
- 監視系のスキル(observability相当、5個程度が目安)が状態と性能を可視化できているか
- 障害時にどのロールのエージェントが暴走したかを追跡できるログ設計になっているか
これらは、oh-my-hermesのようなプロジェクトのドキュメント構成(Roles定義・Workflow Reference)を実際に開いて、自社のユースケースに当てはめて確認できる項目です。ドキュメントが公開されている場合は、役割定義のセクションとレビューゲートに関する記述を優先的に読むと、設計思想の骨格がつかみやすくなります。
まとめ
119という数のスキルそのものよりも、それを支える設計原則に注目する価値があります。
- 役割(role)ベースの権限分離は、マイクロサービスの責務分割と同じ発想でエージェントの暴走リスクを抑える
- 計画フェーズにレビューゲートと対立的検証を厚く配置する設計は、技術的負債の予防策として機能する
- ルールベースの決定的検証とAIによる合議判断を組み合わせるハイブリッド構成は、再現性の課題を伴う
自社でエージェント基盤を検討する際は、まずスキル定義が構造化データとして管理できているか、役割ごとの権限境界が明確かどうかを確認するところから始めるのがよさそうです。