自律型 AI スウォーム

AI エージェントに夜通しで機能を実装させる。理論上は良いアイデアです。でも現実には、朝起きたら半端なマイグレーション、2 つの壊れたファイル、そして「完了しました」という陽気なメッセージが待っています。

この失敗パターンはよくあることです。モデルが弱いわけではありません。1 つの長時間エージェントに仕事を詰め込みすぎているのが原因です。タスクの選択、計画の保持、コードの編集、出力の確認、そしてシップしても安全かの判断、これをすべて 1 つのエージェントがやろうとしている。

この記事ではその問題を解決します。ここで紹介するのは「自律型 AI スウォーム」、つまり自動化された AI オーケストレーションです。30 分ごとにトリガーが発火し、オーケストレーターがプロジェクトの状態を読んでスペシャリストを 1 人か複数ルーティングし、5 つのゲートを通過して初めて「完了」と認めます。

夜間エージェント実行が壊れる 5 つのパターン

「自律型」を謳うデモの多くは難しい部分を隠しています。コードを書かせるのは簡単です。何時間も正しい判断を出し続けさせるのが難しい。

代表的な 5 つの失敗パターンをまとめます。

1. トリガーがない

システムを正しいタイミングで起こすものが何もない。

結局自分でプロンプトを打たなければならないか、寝る前に長い実行を走らせて翌朝まで生き残ることを祈るしかありません。20 分で止まったら、そこで終わりです。

解決策はシンプルです。定期トリガー 1 つ。30 分ごとにシステムが起き上がり、何が起きたかを確認し、次の行動を決める。

2. ルーティングがない

1 つのエージェントが、プロジェクトマネージャー、アーキテクト、フロントエンド、バックエンド、テスター、レビュアーを全部兼任させられる。

効率的に見えますが、そうではありません。計画・実装・検証がコンテキストウィンドウの中で場所を奪い合い、実行がぶれていきます。何が終わって、何がブロックされて、何がまだ証明を必要としているか、エージェントが把握できなくなります。

解決策は役割分離です。オーケストレーターはルーティングだけ担当し、スペシャリストが実行します。判断する頭脳と作業する手が干渉しなくなります。

3. ガードレールがない

エージェントはコードを書いた後、ファイルが存在するという理由だけでタスクを完了とマークします。

それはシップとは違います。ファイルが存在しても、型チェックが通っていない、リントが通らない、ビルドが壊れている、シークレットが漏れている、テストが全く書かれていない、という状態は十分あり得ます。

解決策はゲートスタックです。重要なチェックをすべて通過するまで完了にしない。

4. 証拠がない

エージェントは機能が完了したと言いますが、システム内に何も証明するものがありません。

これは AI セキュリティでも同じ問題です。証拠のない発見はノイズです。証拠のない機能は wishful thinking です。

解決策はサイクルごとに動く検証です。エージェント自身の自信より強い、アウトプットを信頼できる根拠が必要です。

5. 実行間でメモリがない

長い実行が止まります。再起動します。次のエージェントは前のエージェントが何をしていたか知りません。

結果として重複作業、競合した編集、本当の進捗ではなく曖昧なサマリーが積み重なります。システムは動き続けますが、グルグル回っているだけです。

解決策は外部ステートです。オーケストレーターはサイクルごとに現在のプロジェクト状態を読み、それを元にルーティングします。エージェントの記憶ではなく。

なぜ単一エージェントでは足りないか

よくある答えは「1 つのエージェントにテストが通るまで続けさせればいい」というものです。

ワンショットプロンプトよりはマシです。でもそれだけでは不十分。

単一エージェントは持続性の問題を解決します。ルーティングは解決しません。専門化は解決しません。自分の仕事を自分で採点する問題は解決しません。計画するのか、実装するのか、修正するのか、止まるのかを判断する問題も解決しません。

これがワーカーとスウォームの違いです。

単一ワーカーは 1 つのタスクを繰り返します。

スウォームは起き上がり、状態を読み、役割を選び、適切なワーカーを動かし、結果を確認し、次に進むか眠るかを決める小さなシステムです。

だからこのスウォームは分散クラスターでも Kubernetes コントロールプレーンでも抽象的な「エージェントメッシュ」でもありません。もっとシンプルです。1 台のマシン、1 つのリポジトリ、1 つの定期トリガー、1 つのオーケストレーター、1 人か複数のスペシャリスト。並行作業が必要なときはデタッチされたワークツリーを使います。

スウォームの構成

この AI オーケストレーションスウォームには 5 つの部品があります：

1. トリガー: 30 分ごとの起動。
2. オーケストレーター: 1 つのメインセッションがコンテキストを読んで次の手を決める。
3. スペシャリスト: プランナー、ビルダー、デザイナー、テスター、ガード。オーケストレーターは 1 人か複数をルーティングできる。
4. ゲート: lint、型チェック、クリーンビルド、コミットガード、テストスイート。
5. アウトプット: すべてのチェックを通過すれば機能完了。通過しなければスウォームは作業を続けるか眠る。

全体の流れはこうなります：

30-minute trigger
      ↓
orchestrator reads state
      ↓
pick the next task
      ↓
dispatch one specialist or several
      ↓
run quality gates
      ↓
ship, continue, or sleep

重要なのは「エージェントを増やすこと」ではありません。すべてのサイクルに明確な仕事があることです。

デタッチされたオーケストレーターは並行モードです。2〜3 つの独立した機能に作業が分割できるときに使います。

ステップ 1: トリガー

トリガーは 30 分ごとの ping 1 つです。

システムの cron ジョブで実装できます。Claude Code Desktop のスケジュールタスクでも実装できます。スケジューラーのブランドは重要ではありません。重要なのはリズムです。

このリズムには 2 つの効果があります。

まず、システムに複数回のリカバリーチャンスを与えます。午前 2:07 に実行が止まっても、2:30 に次のサイクルが起き上がって続きを進めます。

次に、システムを安く読みやすく保ちます。毎秒トークンを消費する常駐エージェントは不要です。起きて、判断して、動いて、止まる自動化パターンが必要です。

このセットアップでトリガーは一言で表せます：

cron ジョブ 1 つ。スウォーム全体をスケジュールする。

これが正しいメンタルモデルです。スケジューラー 1 つ。クラウドプラットフォームではない。

ステップ 2: オーケストレーター

オーケストレーターは頭脳です。

自分で機能全体を実装しようとしない。これが第一のルールです。

オーケストレーターの仕事は現在の状態を読んで「次の手は何か?」という 1 つの問いに答えることです。

この問いは思ったより絞られています。オーケストレーターはプロダクト戦略を考えているわけではありません。すでに存在するコンテキストを読んでいます：

• 最後に試みたタスク
• 変更されたファイル
• 通過したチェック
• 失敗したチェック
• ブロックされているもの
• 完了に最も近い機能

状態を把握したら、適切なスペシャリストに作業をルーティングします。作業がきれいに分割できるなら複数のスペシャリストに同時にルーティングします。

次の手を決める。

この説明が正確です。オーケストレーターは「メインワーカー」ではなく、ディスパッチャーです。

ステップ 3: スペシャリスト

このスウォームには 5 つのスペシャリスト役割があります。

名前は変えて構いません。重要なのは名前ではありません。

重要なのは、各エージェントが「機能を作る」より絞られた仕事を持っていることです。それによってブレが減り、サイクルごとのアウトプットが安定します。

ここがエージェントチームの設計で多くの人が失敗する点でもあります。5 つのエージェントを立ち上げて、全員に同じプロンプトを渡す。それはチームではなく複製です。

本物のスペシャリストは自分の仕事に必要なコンテキストだけを持ちます。

プランナーはタスクとプロジェクトの形状が必要です。

ビルダーは対象ファイルと受け入れ基準が必要です。

デザイナーは UI 要件とコンポーネントの制約が必要です。

テスターは失敗条件とチェック項目が必要です。

ガードはポリシーが必要です。

オーケストレーターはすべてのスペシャリストを毎回起動する必要はありません。

スペシャリスト 1 人で十分なこともあります。作業が分割できるときはオーケストレーターが複数のスペシャリストに並行ルーティングします。

クリーンな並行作業には分離したセッションか別の Git ワークツリーを使います。各スペシャリストはリポジトリの自分専用コピーで作業し、他のスペシャリストのファイルを踏まずに済みます。.gitignore、.gitkeep、マイグレーション、テスト、UI ファイルも、各ワーカーが自分のレーンを持つことで管理しやすくなります。

「1 つのオーケストレーター、1 人か複数のスペシャリスト」の実態はそういうことです。

並行作業をどうマージするか

並行作業は 2 つのスペシャリストが同じファイルを触るまでは有用です。

だから各スペシャリストは自分の Git ワークツリーで作業します。スペシャリストが並行で構築している間、メインブランチはクリーンなままです。

スペシャリストが終わっても、ブランチはそのまま main にマージされません。デタッチドモードでは、bounded merge helper を通ります。1 ブランチずつ。1 つのターゲットブランチ。シンプルなフォールバックルール。

マージがクリーンなら取り込まれます。

コンフリクトがあれば 3 つのステップを試みます。まずクリーンな git merge。次に簡単なケースの決定論的自動解決。最後にファイルごとの LLM 解決と、散文出力への厳格な拒否。これでマージパスを整然と予測可能に保ちます。

それでも解決できなければ、マージを停止してブランチを失敗済みとしてマークします。

これが重要な点です。スウォームは「全部マージしてうまくいくことを祈る」システムではありません。ルール付きの並行作業です。

ステップ 4: フルスタック実行パス

ビルダーステージこそシステムが真価を発揮する場所です。

多くのエージェントデモは「エージェントがファイルを書いた」で終わります。私たちはその逆を目指しました。データベースから live 出力まで続くパスです。

だからスウォームのビルドフェーズは「コードを書く」とは表現しません。代わりに：

エージェントはフルスタックを実行する。

このシステムでは、オーケストレーターが実際の機能が触れるレイヤー全体をルーティングできます：

• データベース作業
• バックエンドロジック
• ページと UI の配線
• デザインの仕上げ
• テスト

データベースから live まで。手動ステップゼロで 1 つの機能を届ける。

「フルスタック」を平たく定義するとこうなります。このシステムでは「地球上のすべての技術」を意味しません。ストレージから画面まで 1 つの機能を現実にするために必要なレイヤーを意味します。

データベースが変わってもページが変わらなければ、機能は完了していません。

ページが変わってもテストが落ちていれば、機能は完了していません。

ローカルでビルドが通ってもコミットガードがシークレットを検出すれば、機能は完了していません。

スウォームはその連鎖が閉じるまで各レイヤーを進み続けます。

ステップ 5: 5 つのゲート

ガードフェーズこそシステムを信頼できるものにする部分です。

これがなければ、スウォームは壊れた作業を高速に量産するだけの機械になります。

ゲートスタックには 5 つのチェックがあります：

「エージェントにシップさせてあとはなんとかなる」の正反対です。

通過しなければ何もシップしない。

これはスローガンではありません。ルールです。

5 つのゲートには 2 つの役割があります。

まず、壊れたコードが main に届くのを防ぎます。

次に、次の行動について信頼できるシグナルをオーケストレーターに渡します。型チェックが失敗したら、次の動作は「完了を喜ぶ」ではありません。「修正をルーティングする」です。

つまりゲートは安全チェックだけでなく、ルーティングシグナルでもあります。

アウトプットはどう見えるか

目標は「エージェントが 4 時間動いた」ではありません。

目標は「戻ってきたら機能が本当に完成している」です。

だからスウォームの最終フェーズは「サマリー」や「レポート」とは呼びません。アウトプットと呼びます。

一晩の実行ログはこんな形になります：

• 2:00 AM: 認証システムを計画
• 2:30 AM: 3 つの API エンドポイントを実装
• 3:00 AM: 47 件のテストを実行
• 3:30 AM: プロダクションにデプロイ

この順番が重要です。システムがランダムではなく秩序ある作業をしている証拠になります。

4 時間で認証が構築・テスト・シップされた。

自律型ビルドシステムの証明として、これが正しいフォーマットです。短い。具体的。検証可能。

「モデルがよく考えていた」でも「システムが有望に見えた」でもなく、機能がラインを越えた。

オートメーションの実際の動き方

「自律型」という言葉はトリガーが曖昧だと意味をなしません。

オートメーションは魔法ではありません。スケジュールされた起動から始まります。

最もシンプルなバージョンはシステムの cron エントリで、30 分ごとに新しい実行を開始します。概念的にはこうなります：

*/30 * * * * cd /path/to/repo && claude -p "run the swarm orchestrator for the next task"

これだけでリズムを作れます。

Claude Code Desktop のスケジュールタスクでも同じパターンを使えます。Desktop アプリがスケジュールを保持し、設定した間隔で新しいセッションを開始します。起動後の仕事は同じです：

1. スケジュールされた実行が始まる
2. オーケストレーターが現在のプロジェクト状態を読む
3. 1 人か複数のスペシャリストが次のタスクを受け取る
4. 結果がゲートを通る
5. システムがシップ・リトライ・眠るを選択

cron と Desktop スケジュールタスクの選択はアーキテクチャではなく運用の問題です。

cron は最もシンプルなマシンレベルのトリガーが欲しいときに使います。

Desktop スケジュールタスクは見えるスケジュール、履歴、シェルスクリプトを手書きせずに毎回新鮮な Claude セッションが欲しいときに使います。

重要なのは、すべての実行が新鮮に始まり、現在の状態を見ることができることです。それがスウォームを壊れにくく持続可能にします。

何も準備できていないときの動作

良いスウォームにはスリープ状態が必要です。

小さなことに見えますが、そうではありません。

何も変わっておらず、ゲートが失敗しておらず、十分に前進できる機能がなければ、オーケストレーターは状態をログして停止すべきです。スケジューラーが発火したからといって無理やり作業を作ってはいけません。

それがシステムをクリーンに保つ方法です。

トリガーはチャンスを作ります。偽の緊急感は作りません。

汎用エージェントフレームワークよりうまくいく理由

汎用エージェントフレームワークは部品を提供しますが、動作ルールは提供しません。

エージェントを生成するツールがあります。メッセージを渡すツールがあります。構造の感触はあります。でも結局これを自分で決めなければなりません：

• システムがいつ起き上がるか
• どの状態を読むか
• 次のタスクをどう選ぶか
• 重複作業をどう避けるか
• ステップが完了したとみなす条件
• シップをブロックするもの

これが本質的な問いです。

スウォームがうまくいくのは、これらに事前に答えているからです。

トリガーがリズムを与えます。

オーケストレーターがルーティングを与えます。

スペシャリストが集中力を与えます。

ゲートが証明を与えます。

アウトプットがゴールラインを与えます。

汎用フレームワークはこの形を載せられます。でもこの形の代わりにはなれません。

自分のバージョンを作る方法

大きなスタックは必要ありません。

最小構成から始めます：

one scheduler
one orchestrator
one or several specialists
three to five quality gates
one state file or report directory

そしてこのルールに従います。

1. トリガーを安くシンプルに保つ

定期起動で動くなら、常駐エージェントを動かさないでください。

30 分の ping でほとんどの夜間ビルドシステムには十分です。常時活動コストを払わずにリトライ動作が得られます。

2. ルーティングと実行を分ける

オーケストレーターに実装作業をさせないでください。

頭脳がワーカーを兼任すると、ルーティング品質が落ちてコンテキストがすぐに混濁します。

3. 各スペシャリストに絞った仕事を与える

1 つのエージェントが計画・コーディング・デザイン・検証を同じパスでやってはいけません。

絞られたプロンプトは採点しやすく、リトライしやすく、置き換えやすい。

複数のスペシャリストが並行で動くなら、明確な境界を与えます。各スペシャリストが自分のチェックアウトを編集する別ワークツリーが最もクリーンな方法です。

4. ゲートは忠告ではなくブロックにする

警告だけを書くゲートはゲートではありません。

ビルドが壊れているなら、システムは「機能完了」のふりをするのではなく修正をルーティングしなければなりません。

5. 証拠をエージェントの自己申告の外に置く

エージェントが「完了」と言っても証拠ではありません。

証拠はチェック、テスト、ログ、成功したビルドから来ます。外部シグナルは内部の自信に勝ります。

6. 意図的に眠る

何も準備できていなければ、状態をログして眠ります。

これは見た目以上に重要です。止まる判断ができないシステムは高コストで混乱したものになります。

このシステムの正体

直接の答えをします。「これは crontab なのか?」という問いに。

トリガーレベルでは、はい、cron に形は似ています。

1 つのスケジューラーが 30 分ごとにシステムを起こします。そのスケジューラーは：

• マシン上の本物の crontab エントリ
• Claude Code Desktop のスケジュールタスク

のどちらかです。

ただし、スウォームはスケジューラー単体ではありません。

全体の流れは：

1. スケジューラーが発火
2. 新鮮なセッションが起き上がる
3. オーケストレーターが状態を読む
4. オーケストレーターが次の手を選ぶ
5. 1 人か複数のスペシャリストが動く
6. ゲートが結果を確認
7. システムがシップ・リトライ・眠る

だから正解は「crontab だ」でも「AI フレームワークだ」でもありません。

これは自動化された AI スウォームです。

有効な形の一つ：

main session -> route work -> sub-agents -> gates -> sleep

もう一つの有効な形：

main session -> partition 2-3 independent features -> spawn isolated worktree sessions -> merge back safely

どちらも同じアイデアです。明確な役割、境界のあるマージルール、1 つのゴールラインを持った自動化された AI オーケストレーション。

このパターンが使える他の場面

形がわかれば、機能開発以外にも使えます。

同じスウォームパターンが活きるケース：

• セキュリティレビュー
• 依存関係の監査
• コンテンツ生成
• アナリティクスのトリアージ
• PR のお守り

スケジューラーがシステムを起こします。オーケストレーターが状態を確認します。1 人か複数のスペシャリストが絞られた作業をします。ゲートがアウトプットが十分かを決めます。そしてスウォームはまた眠ります。

これがすべてのモデルです。

1 つの ping。1 つの頭脳。1 人か複数のスペシャリスト。5 つのゲート。起きたら機能が完成している。