自律型AIスウォーム

あるAIエージェントに夜間に機能を構築するよう依頼します。理論上は良さそうです。実際には、半分しか完了していないマイグレーション、壊れた2つのファイル、そしてタスクが完了したという陽気なメッセージで目が覚めます。

この失敗パターンは一般的です。モデルが弱いから失敗したのではありません。1つの長時間実行するエージェントが同時に多すぎる仕事をしなければならないから失敗したのです。タスクを選択し、計画を保持し、コードを編集し、出力を確認し、リリースが安全かどうかを決定する。

これがこの記事で修正することです。以下は自律型AIスウォームです。より平易に言えば、自動化されたAIオーケストレーションです。1つのトリガーが30分ごとに発火します。1つのオーケストレーターがプロジェクトの状態を読み取り、1人または複数の専門家にルーティングし、何かが完了と見なされる前に5つのゲートを確認します。

夜間エージェント実行が失敗する5つの方法

ほとんどの「自律型」デモは難しい部分を隠しています。エージェントにコードを書かせるのは簡単です。何時間も正しい決定を下し続けさせるのが難しい部分です。

これらが最初に現れる5つの失敗モードです。

1. トリガーがない

適切なタイミングでシステムを起動するものがありません。

まだそこに座ってプロンプトを入力しなければなりません。あるいは就寝前に大きな実行を開始して一晩中生き残ることを願います。20分後に実行が止まれば、そこで全部終わりです。

修正は簡単です。1つの時間ベースのトリガー。30分ごとにシステムが起動し、何が起きたかを確認し、次に何をするかを決定します。

2. ルーティングがない

1つのエージェントがプロジェクトマネージャー、アーキテクト、フロントエンドエンジニア、バックエンドエンジニア、テスター、レビュアーを演じることを強いられます。

効率的に聞こえます。実際はそうではありません。同じコンテキストウィンドウで計画、実装、検証が場所を争います。実行が迷走します。エージェントは何が完了し、何がブロックされ、何にまだ証拠が必要かを追えなくなります。

修正は役割の分離です。1つのオーケストレーターがルーティングします。専門エージェントが実行します。ルーティングの脳と作業者の脳がお互いを踏み台にすることをやめます。

3. ガードレールがない

エージェントがコードを書き、ファイルが存在するからタスクが完了とマークします。

それはリリースと同じではありません。ファイルは存在していても型チェックに失敗し、リントに失敗し、ビルドを壊し、シークレットを漏らし、テストを完全に見逃す可能性があります。

修正はゲートスタックです。重要なチェックに合格しなければ実行は完了と見なされません。

4. 証拠がない

エージェントが機能が完了したと言いますが、システムの何もそれを証明しません。

これはAIセキュリティでも現れる同じ問題です。証拠のない発見事項はノイズです。証拠のない機能は希望的観測です。

修正はすべてのサイクルで実行される検証です。システムはエージェント自身の自信より強い出力を信頼する理由を必要とします。

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

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

重複した作業、矛盾する編集、実際の進捗の代わりにあいまいな要約が得られます。システムは動き続けていますが、円を描いて動いています。

修正は外部状態です。オーケストレーターはすべてのサイクルの前に現在のプロジェクト状態を読み取り、1つのエージェントが覚えていることからではなく、そこからルーティングします。

単一エージェントでは十分でない理由

通常の答えは「テストが合格するまで1つのエージェントに続けさせる」です。

それはワンショットプロンプトよりも優れています。まだ十分ではありません。

単一エージェントは永続性に役立ちます。ルーティングを解決しません。専門化を解決しません。エージェントが自分の作業を採点するという問題を解決しません。計画するか、構築するか、修正するか、停止するかを決定するという問題を解決しません。

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

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

スウォームは起動し、状態を読み取り、役割を選択し、適切なワーカーを実行し、結果を確認し、前進するか睡眠状態に入るかを決定する小さなシステムです。

だからこのスウォームは分散クラスター、Kubernetesコントロールプレーン、抽象的な「エージェントメッシュ」ではありません。それよりはるかにシンプルです。1台のマシン。1つのリポジトリ。1つの時間ベースのトリガー。1つのオーケストレーター。1人または複数の専門家。作業がきれいに分割されるときに並列モードとしてデタッチされたワークツリーを使用します。

スウォームの形

このようなAIオーケストレーションスウォームには5つの動く部分があります。

1. トリガー: 30分ごとの1回の起動。
2. オーケストレーター: 1つのメインセッションがコンテキストを読み取り次の動きを選びます。
3. 専門家: プランナー、ビルダー、デザイナー、テスター、ガード。オーケストレーターは1人または複数にルーティングできます。
4. ゲート: リント、型、クリーンビルド、コミットガード、テストスイート。
5. 出力: すべてのチェックに合格すれば機能は準備完了。そうでなければスウォームは作業を続けるか睡眠状態に入ります。

全体の形:

30分トリガー
      ↓
オーケストレーターが状態を読み取る
      ↓
次のタスクを選択
      ↓
1人または複数の専門家にディスパッチ
      ↓
品質ゲートを実行
      ↓
リリース、継続、または睡眠

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

デタッチされたオーケストレーターはここで重要です。並列モードだからです。作業がきれいな境界を持つ2〜3つの独立した機能に分割されるときに使用します。

ステップ1: トリガー

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

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

リズムは2つのことをします。

まず、システムに回復するための複数のチャンスを与えます。午前2時7分に実行が死んでも、次のサイクルが午前2時30分に起動して続行します。

次に、システムを安価で読みやすく保ちます。毎秒トークンを消費し続けるエージェントは不要です。起動し、決定し、行動し、停止する自動化パターンが必要です。

このようなセットアップでは、トリガーステップは1行で要約されます。

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

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

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

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

機能全体を自分でやろうとしません。これが最初のルールです。

その仕事は現在の状態を読み取り、1つの質問に答えることです。次の動きは何か?

その質問は聞こえるより狭いです。オーケストレーターは製品戦略を発明しません。すでに存在するコンテキストを読み取ります。

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

その状態が揃えば、適切な専門家に作業をルーティングするか、作業がきれいに分割される場合は複数の専門家にルーティングします。

だからカルーセルのコピーはこう言います。

次の動きを選択する。

この文は重要です。オーケストレーターを正しく定義しているからです。「メインワーカー」ではありません。ディスパッチャーです。

ステップ3: 専門家

このスウォームは5つの専門家の役割を使用します。

名前は変えられます。名前は重要な部分ではありません。

重要なのは各エージェントが「機能を構築する」より狭い仕事を持つことです。それにより迷走が減り、サイクルごとの出力の一貫性が高まります。

これはほとんどのエージェントチームセットアップが間違える点でもあります。5つのエージェントを起動し、全部に同じプロンプトを与えます。それはチームではありません。それは重複です。

本物の専門家は自分の仕事に必要なコンテキストだけが必要です。

プランナーはタスクとプロジェクトの形を必要とします。

ビルダーはターゲットファイルと受け入れ基準を必要とします。

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

テスターは失敗条件とチェックを必要とします。

ガードはポリシーを必要とします。

オーケストレーターは毎回5つ全部を起動する必要はありません。

1人の専門家で十分な場合もあります。作業が分割される場合、オーケストレーターは複数の専門家を並列でファンアウトします。

きれいなバージョンは、独立したセッションまたは別々のGitワークツリーを使用します。各専門家はリポジトリの独自のコピーを取得し、自分の部分を実行し、別の専門家のファイルを踏まないようにします。これが並列作業を汚くなく本物にする方法です。.gitignore、.gitkeep、マイグレーション、テスト、UIファイルなどの基本的なリポジトリの詳細でも、各ワーカーに独自のレーンがある場合の方が推論が簡単です。

それが「1つのオーケストレーター。1人または複数の専門家。」が実際に意味することです。

並列作業がどのようにマージされるか

並列作業は2人の専門家が同じファイルに触れるまでは有用です。

だからこそ各専門家は独自のGitワークツリーで作業します。専門家が並列で構築する間、メインブランチはきれいなままです。

専門家が終了すると、そのブランチはすぐにマージされません。デタッチされたモードでは、制限されたマージヘルパーを通ります。一度に1つのブランチ。1つのターゲットブランチ。シンプルなフォールバックルール。

マージがきれいであれば、着地します。

競合がある場合、システムは3つのステップを試みます。まず、きれいなgit merge。次に、簡単なケースの決定論的自動解決。3番目、散文出力の厳格な拒否を持つファイルごとのLLM解決。これによりマージパスがタイトで予測可能に保たれます。

それが何も機能しなければ、マージは停止してブランチは失敗としてマークされます。

これは重要です。スウォームは「すべてをマージして祈る」ではありません。ルールを持つ並列作業です。

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

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

多くのエージェントデモは「エージェントがファイルを書いた」で止まります。その逆が欲しかったのです。データベースからライブ出力までのパスが欲しかったのです。

だからスウォームのビルドフェーズは「コードを書く」とは表現されません。次のように表現されます。

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

このようなシステムでは、オーケストレーターが実際の機能が触れる本物のレイヤーをまたいでルーティングできます。

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

だからスライド4は次で終わります。

データベースからライブへ。1つの機能、手動ステップゼロ。

ここはフルスタックを平易な言葉で定義する適切な場所でもあります。このシステムでは「地球上のすべてのテクノロジー」を意味しません。1つの機能をストレージから画面まで本物にするために必要なレイヤーを意味します。

データベースが変更されてもページが変更されなければ、機能は完成していません。

ページが変更されてもテストが失敗すれば、機能は完成していません。

すべてがローカルでビルドされてもコミットガードがシークレットをフラグ立てすれば、機能は完成していません。

スウォームはそれらのレイヤーを通じてチェーンが閉じるまで動き続けます。

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

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

それなしでは、スウォームは壊れた作業を高速で生成する方法にすぎません。

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

これは「エージェントにリリースさせて最善を祈る」の正反対です。

ここのコピーは理由があってストレートです。

合格なしでは何もリリースされない。

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

5つのゲートは2つの仕事をします。

まず、悪いコードがmainに届くのを止めます。

次に、オーケストレーターに次に何をすべきかの信頼できるシグナルを与えます。型チェックが失敗した場合、次の動きは「祝う」ではありません。次の動きは「修正をルーティングする」です。

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

出力の見た目

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

目標は: 戻ってきたとき機能が実際に完成していること。

だからこそスウォームの最後のフェーズは「要約」や「レポート」と呼ばれません。出力と呼ばれます。

夜間の実行はこのように読めます。

• 午前2時: 認証システムを計画
• 午前2時30分: 3つのAPIエンドポイントを構築
• 午前3時: 47のテストを実行
• 午前3時30分: 本番にデプロイ

このシーケンスは重要です。システムがランダムな作業ではなく秩序立てた作業をしていることを証明するからです。

シンプルな例:

4時間。認証が構築、テスト、リリースされました。

それが自律的なビルドシステムの正しい証明形式です。短い。具体的。検証可能。

「モデルの推論が本当に良かった」ではありません。「システムが有望に見えた」でもありません。機能がラインを越えました。

自動化が実際にどのように動くか

この部分は重要です。「自律型」は「トリガーがあいまい」であれば意味が薄れるからです。

自動化は魔法ではありません。スケジュールされた起動から始まります。

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

*/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 セッションが欲しい場合。

重要なのは、すべての実行が新鮮に始まり、すべての実行が現在の状態を見られることです。それがスウォームを脆弱でなく耐久性のあるものにします。

何も準備できていないときどうなるか

優れた自動化スウォームには睡眠状態が必要です。

これは小さなことのように聞こえます。そうではありません。

何も変わらず、ゲートが失敗せず、機能が前進するほど近くない場合、オーケストレーターは状態を記録して停止すべきです。スケジューラーが発火したからといって仕事を強制すべきではありません。

これがシステムをきれいに保つ方法です。

トリガーは機会を作ります。偽の緊急性は作りません。

なぜこれが汎用エージェントフレームワークより優れているか

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

エージェントを起動するツールが得られます。メッセージを渡すツールが得られます。構造の感覚が得られます。そして依然として決定しなければなりません。

• システムがいつ起動するか
• どんな状態を読み取るか
• どのように次のタスクを選ぶか
• 重複した作業をどのように避けるか
• ステップを完了させるものは何か
• リリースをブロックするものは何か

それらが本物の質問です。

スウォームはそれらを事前に答えるから機能します。

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

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

専門家が集中を与えます。

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

出力がゴールラインを与えます。

汎用フレームワークはその形をホストできます。置き換えることはできません。

自分のバージョンを構築する方法

これを複製するために巨大なスタックは不要です。

この最小の形から始めます。

1つのスケジューラー
1つのオーケストレーター
1人または複数の専門家
3〜5つの品質ゲート
1つの状態ファイルまたはレポートディレクトリ

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

1. トリガーを安価に保つ

時間ベースの起動が機能するなら、常に起動しているエージェントを実行しないでください。

30分のpingはほとんどの夜間ビルドシステムに十分です。継続的な活動に支払うことなくリトライ動作が得られます。

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

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

脳がワーカーでもある場合、ルーティングの品質が下がり、コンテキストがすぐに汚れます。

3. すべての専門家に狭い仕事を与える

1つのエージェントが同じパスで計画し、コーディングし、デザインし、検証すべきではありません。

狭いプロンプトは評価しやすく、リトライしやすく、置き換えやすいです。

複数の専門家が並列で実行される場合、それぞれに明確な境界を与えます。各専門家が同じファイルをめぐって争う代わりに独自のチェックアウトを編集するため、別々のワークツリーが最もきれいなバージョンです。

4. ゲートにアドバイスではなくブロックさせる

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

ビルドが壊れている場合、システムは機能が完成したふりをする代わりに修正をルーティングしなければなりません。

5. エージェントの自己報告の外に証拠を保つ

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

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

6. 意図的に睡眠する

何も準備できていない場合、状態を記録して睡眠します。

これは聞こえるより重要です。システムは停止を決定できないとき高価でごちゃごちゃになります。

このシステムが実際に何であるか

これがあなたの質問への直接的な答えです。それはcrontabですか?

トリガーレベルでは、はい、cron形式です。

30分ごとにシステムを起動する1つのスケジューラーがあります。そのスケジューラーは次のいずれかです。

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

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

完全なフローは:

1. スケジューラーが発火
2. 新しいセッションが起動
3. オーケストレーターが状態を読み取る
4. オーケストレーターが次の動きを選ぶ
5. 1人または複数の専門家が実行
6. ゲートが結果を確認
7. システムがリリース、リトライ、または睡眠

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

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

有効な形の1つ:

メインセッション -> 作業をルーティング -> サブエージェント -> ゲート -> 睡眠

別の有効な形:

メインセッション -> 2〜3の独立した機能に分割 -> 隔離されたワークツリーセッションを起動 -> 安全にマージバック

両方とも同じアイデアです。明確な役割、制限されたマージルール、1つのゴールラインを持つ自動化されたAIオーケストレーション。

このパターンが他にどこで適用できるか

形が見えれば、機能ビルド以外でも使えます。

同じスウォームパターンは次のことにも機能します。

• セキュリティレビュー
• 依存関係の監査
• コンテンツ制作
• アナリティクスのトリアージ
• PRの世話

スケジューラーがシステムを起動します。オーケストレーターが状態を確認します。1人または複数の専門家が狭い作業をします。ゲートが出力が十分に良いかどうかを決定します。そしてスウォームは再び睡眠状態に入ります。

それがモデル全体です。

1回のping。1つの脳。1人または複数の専門家。5つのゲート。目が覚めたとき機能が完成。