マルチエージェントを並列に動かすとき、まず思い浮かぶのは、中央のエージェントが仕事を分解して子エージェントへ配る構成です。分かりやすく検証もしやすい一方、依頼と結果が中央へ集まるため、エージェント数を増やすほど司令塔のコンテキストと処理待ちが効いてきます。

kiro-flockは、この調整を中央エージェントではなくAmazon S3上の共有状態へ移したAWSの参照実装です。Amazon EC2上で動くKiro CLIエージェントは互いに直接通信せず、それぞれのログを読み合って次の仕事を決めます。

では、司令塔をなくせばマルチエージェントはそのまま拡張しやすくなるのでしょうか。仕組みを追うと、答えはエージェント数ではなく、仕事の分けやすさと検証をどこに置くかで決まると分かります。

S3の共有ログへ調整を移すと中央の待ち行列がなくなる

kiro-flockの共有環境には、全体の目標を書くdirectionファイル、エージェントごとの追記専用ログ、成果物を置く作業領域があります。中央のプロセスが計画、割り当て、集約を担うのではなく、各エージェントが同じ目標と近隣のログを材料に一つの貢献を選びます。

各反復では新しいKiro CLIセッションを開始し、directionと限られた数の近隣ログを読み、成果物を書き、最後に「何をしたか」「結果」「次に取り組む意図」を自分のログへ追記します。別のエージェントはその記録を次の反復で読み、追従するか、別の角度を掘るか、作業を止めるかを自分で判断します。

共有先にS3を使える背景には、オブジェクトのPUTとDELETEに対して全リージョンで強いread-after-write整合性を提供するというAmazon S3のデータ整合性があります。ただし、S3がエージェント同士の合意や成果物の正しさまで保証するわけではありません。各エージェントが自分のログを所有する設計で書き込み競合を避け、収束はログを読む側のループに任せています。

この構成なら、一つのエージェントが停止しても失われるのはそのエージェントの反復だけです。その代わり、途中の判断を毎回裁定する中央の検証者もいなくなります。ここが単なるスケールアウトとは違うところですね。

並列に分けられる仕事ほど自己組織化の利点を使いやすい

自己組織化クラスタが合うのは、大きな目標へ向けて準独立な貢献を多数積み上げられる仕事です。大規模コードベースのレビュー、既知の移行先へ多数のモジュールを更新する作業、テストや設計案の並列生成では、厳密な順序よりも探索の幅と並列性が価値になります。

一方、手順の前後関係が強い処理、途中ごとに承認が要る変更、低遅延の対話処理では、中央オーケストレーターが持つ順序制御と検証ゲートのほうが役立ちます。Google Researchによるエージェント構成の比較でも、並列化しやすい金融推論では中央調整が単一エージェントを上回った一方、逐次的な計画では調整コストにより全マルチエージェント構成の性能が低下しました。また、中央検証のない独立構成では誤りの増幅が大きくなったと報告されています。

リング・メッシュ・スウォームは「誰のログを読むか」を変える

全員へ同じ情報を見せると、早い段階の案が事実上の総意になり、別案が育ちにくくなります。kiro-flockは情報の見え方を調整するため、実行中にも切り替えられる3種類の方式を用意しています。公式リポジトリでは、次のように実装されています。

• Amorphous（リング）: 各エージェントが左右R個ずつ、合計2R個の固定された近隣ログを読みます。エージェント総数Nが増えても一つのエージェントが読む量を一定に保ちやすく、情報がゆっくり広がるぶん異なる案を育てられます。
• Mesh（完全可視）: 全エージェントが全員の最新ログを読みます。合意は速いものの、読む文脈はNに比例し、初期案への同調も起きやすくなります。
• Swarm（最新活動優先）: 直近に活動したK個のエージェントを読みます。動きのある仕事へ集まりやすい一方、Nに対してKが小さすぎると、同じサブタスクがホットスポットになります。

リングで一つの情報が全体へ届くまでの目安はceil(N / 2R)反復です。たとえばN=100、R=2なら25反復で、標準の30秒間隔なら伝播だけで約12分半になります。これはモデル上の目安であり、成果物の完成時間や品質を保証する値ではありません。

探索を広げたい序盤はリング、方向が見えてきたらスウォーム、最終的な整合を急ぐ段階ではメッシュへ切り替える、という流れが考えられます。トポロジーは見た目の違いではなく、多様性、コンテキスト量、収束速度の配分そのものです。

毎回セッションを作り直すことで過去の思い込みを共有状態から切り離す

新しいセッションを反復ごとに起動するのは、一見すると非効率です。しかし会話履歴を持ち越すと、近隣の状況が変わっても、エージェントが最初の解釈を引きずるdriftが起きます。kiro-flockは、残す状態を共有ログと成果物に限定し、毎回そこから現在の状況を読み直します。

それでも失敗はなくなりません。メッシュを早く使えばgroupthinkが起き、スウォームのKが小さければ一部の仕事へ集中し、前回の成果物を退避しなければ古いファイルを現在の文脈として読んでしまいます。共有状態を採用するなら、セッション履歴だけでなく、可視範囲と実行単位ごとのデータ分離も制御対象です。

また、中央の検証を外した以上、最終成果物には別のゲートが要ります。コード移行なら全テストの実行、設計案なら人または独立レビュー担当による採否判断など、クラスタの外側に完了条件を置くのが自然です。自己組織化は検証を不要にする仕組みではありません。

kiro-flockを試す前に権限・停止条件・費用上限を決める

2026年8月12日時点のkiro-flock公式READMEは、CDKをbootstrap済みのAWSアカウント、Node.js 20以降、Python 3、AWS CLI v2、Kiro CLI、対象のKiroサブスクリプションを前提にしています。設定の入口は短く、テンプレートをコピーしてリージョンとプロファイルを記入し、セットアップを実行します。

cp install.config.template install.config
# install.configでREGIONとPROFILEを設定
./setup.sh

セットアップはS3、EC2、AWS Lambda、Amazon API Gateway、Amazon Cognitoなどをデプロイし、KiroのAPIキーをAWS Systems Manager Parameter Storeへ保存します。Kiro CLIのheadless modeは対話なしで動くため、許可するツールを事前に決める必要があります。ドキュメントも、全ツール許可より--trust-toolsで必要なカテゴリだけを渡す方法を勧めています。

そして、これは本番用製品ではなく、学習・検証用のサンプルです。READMEは単一の運用者が専用AWSアカウントで試す前提を明記し、現状の課題として、クラスタ単位では広いS3書き込み権限、制限のない外向き通信、本番向け認証・監視・入力検証の不足などを挙げています。本番や共有環境へ近づける前に、少なくともクラスタごとのIAM権限、egress、監視、データ分類を設計し直す必要があります。

中央オーケストレーターやメッセージブローカーがなくても、費用が消えるわけではありません。Kiroの利用枠に加えて、エージェント分のEC2、S3の保存とリクエスト、制御面のLambdaとAPI Gateway、実行後分析のAmazon Bedrockが費用要因です。最初の実験では専用アカウントまたは分離した環境を使い、AWS Budgetsの通知、最大反復数、アイドル時の停止、削除手順まで先に決めておきたいところです。

自己組織化クラスタは司令塔の代替ではなく別の調整方式

kiro-flockが示したのは、中央司令塔を強化し続ける以外にも、共有状態と局所的な観測でエージェントを協調させる道があることです。準独立な仕事を大量に並べ、多様な案を残したいなら、この方式は中央の待ち行列と単一障害点を外せます。

ただし、順序、途中承認、厳密な正しさが中心の仕事では、中央検証はボトルネックであると同時に安全装置です。実務では、仕事を分解できるかを先に見極め、情報の可視範囲をトポロジーで調整し、クラスタの外側に最終ゲートを置く。この3点がそろって初めて、自己組織化を「エージェントを増やす実験」から設計判断へ変えられます。

出典

• Title: Scaling patterns for self-organizing multi-agent clusters with Kiro
• URL: https://aws.amazon.com/blogs/architecture/scaling-patterns-for-self-organizing-multi-agent-clusters-with-kiro/