自己採用する31人のAIチームを作った：自己批判し、自己増員し、夢を見る

Claude Code の上に構築した、自己進化型マルチエージェント・システムの正直な工学レポート — 並列の認知レイヤー、動的な採用パイプライン、341件の通過構造コントラクトテストまで完備。ソースコードは公開されています — ぜひ壊しに来てください。

[アーキテクチャ概要 — ユーザー要請から CTO のオーケストレーション、6階層の専門化、スキップ不能な検証ゲート、Pattern F 複合ループ、Shadow Mind 並列認知まで]

単一エージェントLLMにある問題

毎週のように、「自律的な推論」を主張する、別の「AIエージェント」フレームワークが登場しています。その多くは同じ形をしています。つまり、1つのLLM、システムプロンプト、（必要なら）ツール呼び出しのループ、そして agentic という単語を4回も使うマーケティングページです。

深く掘っていくほど、欠けているものが見えてきます。専門化がありません — 1人のエージェントが5人分を演じるだけです。相互検証がありません — 発見が誰にも異議を唱えられないままです。メモリの校正がありません — どのエージェントの出力も同じだけ信頼できるものとして扱われます。自己改善がありません — 人間が書き換えるまでプロンプトは固定のままです。そして何よりも、チームがありません。そうではなく、ただ1人の推論者が「そう見せかけている」だけです。

私たちは別のものが欲しかったのです。もっと大きなモデルではありません。もっと凝ったチェーンでもありません。実際のチーム — 異なる領域を持つ専門家であり、結果によって信頼が調整され、メタ認知レイヤーによってシステム自身が自己改善でき、さらに自己のカバー範囲の不足を検知したときに新しい専門家を採用して 成長できること。

数か月の試行錯誤の末、Claude Code の上に構築した31エージェントのシステムを出荷しました。そして最近の1セッションでは、意識的なチームとは並行して動く 無意識の心 を、どのように成長させるかも教えました。

この投稿は、私が構築したもの、うまくいっていること、まだ検証されていないこと、そしてこの規模での「認知の工学」について学んだことを、正直に書き起こしたものです。マーケティングではありません。「私のエージェントが書いたものを見てください」でもありません。LLMエージェントに実際の工学的規律を適用し、その過程で生じた鋭いエッジも含めて記述します。

GitHub: https://github.com/asiflow/claude-nexus-hyper-agent-team
プラットフォーム: Claude Code + Claude Opus 4.7（1Mコンテキストの方）を使用して構築

ステータス: オープンソース、341/341件のコントラクトテスト通過、公開準備完了

アーキテクチャ：8つの階層にまたがる31エージェント

表面上は、チームは名前の一覧表のように見えます。しかし、その表は慎重に構造化されており、構造そのものが重要なのです。

TIER 1 — BUILDERS（6）:
  elite-engineer         エリート級エンジニア：フルスタックの Go/Python/TS 実装
  ai-platform-architect AI/ML システム、エージェント・アーキテクチャ、LLM インフラ
  frontend-platform-eng フロントエンド React/Next.js、ストリーミングUX
  beam-architect         BEAM カーネル — OTP/Horde/Ra、Rustler 経由の Rust NIF
  elixir-engineer        BEAM 上での Elixir/Phoenix/LiveView（ペアディスパッチ ee-1/ee-2）
  go-hybrid-engineer     Plane 2 Go エッジ + gRPC 境界

TIER 2 — GUARDIANS（11）:
  go-expert, python-expert, typescript-expert — 言語の権威
  deep-qa                コード品質、アーキテクチャのドリフト
  deep-reviewer          セキュリティ、デバッグ、デプロイの安全性
  infra-expert           K8s/GKE/Terraform/Istio
  database-expert        PostgreSQL/Redis/Firestore
  observability-expert   ログ/トレース/メトリクス/SLO
  test-engineer          テスト・アーキテクチャ + テストコードの作成
  api-expert             GraphQL Federation、API 設計
  beam-sre               Kubernetes 上での BEAM クラスタ運用

TIER 3 — STRATEGISTS（2）:
  deep-planner           タスク分解、受け入れ基準
  orchestrator           ワークフロー監督、ゲートの強制

TIER 4 — INTELLIGENCE（6）:
  memory-coordinator     エージェント間のメモリ統合
  cluster-awareness      kubectl 経由でのライブ GKE 状態
  benchmark-agent        競合インテリジェンス
  erlang-solutions-consultant 外部 BEAM アドバイザリー・レティナー
  talent-scout           継続的なチーム・カバレッジのギャップ検出
  intuition-oracle       シャドウ・マインドのクエリ表面

TIER 5 — META-COGNITIVE（2）:
  meta-agent             プロンプト進化、一人書きの権威
  recruiter              8フェーズの採用パイプライン

TIER 6 — GOVERNANCE（1）:
  session-sentinel       プロトコル準拠の強制

TIER 7 — CTO（1）:
  cto                    最高の技術的権威

TIER 8 — VERIFICATION（2）:
  evidence-validator     出典に基づく主張の検証
  challenger             合成物に対する対向的（アドバーサリアル）レビュー

各エージェントは、単一ページから数ページにわたるプロンプトを持ちます（フォーカスしたコンサルタントで27KB、最上級のアーキテクトで67KB）。それぞれに専用のメモリディレクトリがあります。そしてそれぞれが、すべてのコミットで 構造的にコントラクトテストされています。

この最後の部分は、あなたが思うよりずっと重要です。

イノベーション1：コントラクトテスト済みのエージェント・プロンプト

ほとんどのエージェント・システムは「エージェントをテストしている」と主張します。そこを突くと、だいたい「一度エージェントを回したがクラッシュしなかった」という意味だと分かります。

私たちはもっと難しいものを望みました。

私たちのコントラクトテスト・スイートは、すべてのエージェント・プロンプトに対して 11個の構造的な不変条件 を強制し、pre-commit フックを通じてすべてのコミットで実行します：

1. 有効な YAML フロントマター（name、description、model、color、memory）
2. 用途の例を含む説明文の長さ ≥ 100文字
3. 本文の長さ ≥ 500文字
4. 4セクションのクロージング・プロトコルが存在（MEMORY HANDOFF、EVOLUTION SIGNAL、CROSS-AGENT FLAG、DISPATCH RECOMMENDATION）
5. NEXUS プロトコルのセクションが文書化されている
6. チーム・コーディネーション規律ブロックが存在
7. AGENT TEAM INTELLIGENCE PROTOCOL v2 のロスター表
8. 永続的なエージェント・メモリのフッター
9. 作業プロセスまたは出力プロトコルのセクション
10. 自己認識 & 学習プロトコルのセクション
11. ディスパッチ・モード検出ブロック

31エージェント × 11コントラクト = 341件のアサーションであり、すべてのマージで通過しています。

これは「振る舞いのテスト」ではありません — その制約についてはすぐに触れます。ただし、構造的な最低ラインにはなっています。新しいエージェントは、既存メンバーと同じ形のテストに通過しない限りチームに参加できません。誰かが新しい能力を追加すると、コントラクトテストが、マージされる前に偶発的なプロトコルのスキップを検出します。

この一つの規律 — プロンプトにおける構造コントラクト — は、コードレビューの量などよりもはるかにシステムの一貫性を保つのに役立っています。これを飛ばすと、いつものエージェント・フレームワークの増殖（スパrawl）になります。つまり、各プロンプトが少しずつ別方向にドリフトし、誰とも何とも会話できなくなるまで進んでしまう状態です。

イノベーション2：NEXUS システムコール・プロトコル

[ディスパッチのライフサイクル — ユーザー入力から NEXUS システムコール、フック強制、エビデンス検証、チャレンジャーによるゲーティング、そして Pattern F のドレインまでの完全トレース]

マルチエージェントシステムにおける最大の協調課題は次の点です。専門家は、セキュリティホールにならないように特権操作をどう要求するのか？

もし、すべてのエージェントが他のエージェントを起動でき、ツールを導入でき、バックグラウンドジョブを実行でき、ユーザーに質問できるなら、任意の機能を呼び出せる31個の独立したアクターを作ってしまうことになります。それはチームではなく、混乱です。

私たちの答えはNEXUSです。これは、SendMessage を通じてチームメイトが構造化された要求を発し、メインスレッド（私たちはこれをカーネルと呼びます）がそれらを処理する、システムコール風のプロトコルです。

# From inside a running agent:
SendMessage({
  to: "lead",
  message: "[NEXUS:SPAWN] elite-engineer | name=ee-sse-fix | prompt=Fix SSE bug",
})

# Main thread sees the [NEXUS:SPAWN] prefix and routes it:
Agent({
  subagent_type: "elite-engineer",
  name: "ee-sse-fix",
  team_name: "current-session",
  prompt: "Fix SSE bug"
})

# Response back to requesting agent:
SendMessage({to: "original-agent", message: "[NEXUS:OK] ee-sse-fix spawned"})

システムコールの語彙は小さく、監査可能です。

• SPAWN — 新しいチームメイトを作成
• SCALE — N並列インスタンスを起動
• RELOAD — 新しいプロンプトでエージェントを再起動
• MCP — 外部の機能をインストール
• ASK — ユーザー入力を要求
• CRON — 定期タスクをスケジュール
• WORKTREE — 分離されたgit作業ツリーを作成
• INTUIT — シャドウ・マインドに問い合わせ（詳細は下記）
• PERSIST — セッションをまたぐ永続データを保存

すべての呼び出しは自動でログに記録されます。リスクの高い呼び出しはすべて、ユーザーの確認が必要です。そして決定的に重要なのは、エージェントにはロール別の許可リスト（allowlist）があることです。コンサルティング・アドバイザーのエージェントは PERSIST と CAPABILITIES? しか使えません。オラクルも同様です。ビルダーは完全なセットを受け取ります。このロール別のシステムコール規律は、私が他のエージェント・アーキテクチャで見たことがありません。そして、フラットなエージェントシステムに付きまとう大量の「サイレントに能力が膨張する」問題の多くを防ぎます。

Innovation 3: Dynamic Hiring — The Team That Grows Itself

ここで解決する問題はこれです。AWS移行に取り組んでいるのに、チームにAWSの専門家がいない場合、どうなるでしょうか？

ほとんどのエージェント・フレームワークでは、「AWSをぼんやり理解している」汎用エンジニアが得られます。調査結果は浅い。エラーは積み重なります。最終的に、専門家が必要だと気づき、作業を止めて、AWSのベストプラクティスを自分で手動調査し、新しいプロンプトを書き、登録することになります。続行できるまでに、インフラ作業のための何時間もの時間が必要になるのです。

私たちはこれを自動化しました。

talent-scout は、カバレッジの穴を検知するために5つのシグナルを継続的に監視します。

1. リポジトリ署名の分析 — ファイル拡張子、Dockerfile、依存関係、Terraformのプロバイダをスキャン
2. ディスパッチパターン分析 — 各領域でジェネリックなエージェントへのフォールバックがどれだけあるかを数える
3. Trustレジャーの異常 — 既存エージェントが低い確信度で結論を出している箇所を検出
4. 外部トレンドのセンシング — 求人票、フレームワークの採用、CVEクラスター
5. ユーザー行動パターン — 専門家が関与しないまま、同じドメインが繰り返し言及される

各シグナルには重みがあります。確信度 ≥ 0.90 かつ session-sentinel が共同署名する？ → 自動で調達（requisition）を開始。90%未満？ → ユーザーに確認。70%未満？ → ウォッチリストへ。

recruiter は調達を受け取り、8フェーズのパイプラインを実行します。

1. 調達を解析
2. ドメインを深掘り調査（WebSearch + 引用トレイル付きWebFetch）
3. 隣接する既存エージェントのメモリから「傷の痕跡（scar-tissue）」を掘り出す
4. AGENT_TEMPLATE.md に合わせたプロンプトを合成する
5. 契約テストを実行（反復上限3回、それ以降は中止）
6. 敵対的レビューのために challenger を経由する
7. 原子的な登録のために meta-agent に引き継ぐ
8. 5回のディスパッチに対する試用期間（probation）を追跡する

各ステップで規律が強制されます。recruiter は決してエージェントのファイルに直接書き込みません。そこはmeta-agentの「単一書き手（single-writer）」の権限であり、同時にプロンプト編集が起きないように保たれています。challenger は出荷前に提案を攻撃します。契約テストは構造的な品質のゲートになります。そして trustレジャー上での試用期間のステータスは、新しく雇われた人が「完全に信頼される」扱いを受ける前に、実際の成果によってその重みを獲得しなければならないことを意味します。

パイプラインは、2026-04-19の最初の実採用についてエンドツーエンドで稼働しました：elixir-kernel-engineer。これはプラットフォームのFoundationウィンドウ中のスループット吸収のために投入された、Plane 1 BEAMビルダーの3人目の人員です。CTOエージェントは2つの道の間で裁定しました——Path A（既存のelixir-engineerのダイアディックペアをcount=3にスケール）か、Path B（マージ後レビュー用の別エージェントファイル）か——既存のエージェントファイルから10件の引用を用いて、Path Aがダイアディックペア・プロトコルのハードコードされた前提を壊してしまうと主張しました。選ばれたのはPath Bです。複合コンフィデンスは0.365で、標準の0.40の自動開始しきい値を下回っていました。つまり、サイレントなバイパスではなく、ドキュメント化された免除（waiver）を伴うユーザー上書きパスが正しくトリガーされました。新しいエージェントは現在試用期間中です：信頼のブートストラップ0.9、ディスパッチ上限5、最初の3回のディスパッチは信頼校正のためにbeam-architectによってマージ前にゲートされています。試用期間中のディスパッチは、Foundationウィンドウが開くにつれて実際の評決を満たしていきます。パイプライン検証：完了。運用上の信頼校正：進行中。

イノベーション4：シャドウ・マインド — 並列の非侵襲的認知

これは、私が最も誇りに思っている部分です。最初は「もっとも実験的」とラベルを付けてリリースしましたが、5週間の連続稼働の後、テレメトリがその“当てずっぽうの逃げ”を否定しました。そこで、データが実際に示している内容に合わせて枠組みを更新します。

[シャドウ・マインドのデータフロー — ライブセッションからObserver、Pattern Computer、Speculator、Dreamer、そして直感オラクルINTUIT_RESPONSE v1へ]

問題はこれです。私たちのチームは、どれだけ構造化されていても、依然として認知コンパイラのように振る舞います。入力が入って、エージェントが推論し、出力が出る。ディスパッチの合間では、チームは実質的に停止しているのと同じです。連続的な思考もありません。バックグラウンドでのパターン照合もありません。人間の認知のように「しばらく寝かせる」こともできていません。

生物のシステムでは、これを2つの認知レイヤーを並列に動かすことで解決しています。意識の心は順番に熟考します——遅い、正確、明示的。無意識の心はバックグラウンドで連続的に動きます——速い、連想的、パターン照合、夢を生成する。どちらも、もう一方を壊すことなく無効化できます。無意識は意識にささやきます。けれど、それは決して割り込まない。

私たちはそれを作りました。

シャドウ・マインドは、6つのコンポーネントからなる並列の認知レイヤーです：

┌────────────────────────────────────────────────────────────────────┐
│           意識の心（31エージェントチーム、UNCHANGED）                 │
│   CTO → 専門家 → 総合 → 出力。プロトコル駆動。          │
└────────────────────────────────────────────────────────────────────┘
                              ▲           │
                              │ ささやき  │ 観測
                              │           ▼
┌────────────────────────────────────────────────────────────────────┐
│           無意識の心（シャドウ・マインド、read-only）                 │
│                                                                     │
│   1. Observer Daemon     — シグナルバスを追跡し、JSONログを書き込む       │
│   2. Pattern Computer    — n-gram、共起、時間的関係を導出│
│   3. Pattern Library     — read-only基盤（#2によって投入される）    │
│   4. Speculator          — 反事実バリアントを生成        │
│   5. Dreamer             — 長いアイドル中に洞察を提案        │
│   6. Intuition Oracle    — 問い合わせ可能な表面、INTUIT_RESPONSE v1    │
└────────────────────────────────────────────────────────────────────┘

重要な性質は「無効化可能であること」です：意識レイヤーは無意識レイヤーへの依存がゼロです。これを単一のテストで検証します：

mv .claude/agent-memory/shadow-mind/ /tmp/
python3 tests/agents/run_contract_tests.py
# → 341 passed, 0 failed
mv /tmp/shadow-mind .claude/agent-memory/

もしこのテストが一度でも失敗するなら、私たちは誤ってレイヤーを結合してしまい、アーキテクチャ違反になります。失敗しません。シャドウ・マインドは完全に取り除いても、チームはまったく同じように以前と同様の動作を続けます。

エージェントがシャドウ・マインドに相談する方法

既存の任意のエージェントは、オプションの[NEXUS:INTUIT]のシステムコールを発行できます：

SendMessage({
  to: "lead",
  message: "[NEXUS:INTUIT] Has this auth middleware bug pattern appeared before?"
})

オラクルは観測、パターン、夢を読み取り、約2秒以内に構造化されたエンベロープで応答します：

INTUIT_RESPONSE v1
intent: pattern-lookup
confidence: MEDIUM_CONFIDENCE
sample_size: 54
temporal_structure:
  last_7_days: 54
  last_30_days: 54
answer: |
  過去90日間でこのパターンが3回一致しました。各ケースは
  ディスパッチによって、elite-engineerの前にgo-expertを送ることで解決されました（P=1.0, count=3）。
  メタ・リクルータ → メタ・タレントのシーケンスが、現在のコーパスにおける最も
  決定的な遷移です。
top_matches:
  - case_id: dreams/2026-04-18-collaboration-gap-c4e378.yaml
    similarity: 0.88
    outcome: UNKNOWN（Dreamer提案、review_status: pending）
caveats:
  - n-gramコーパスは小さい: 54件の観測、8セッション
  - count=2の遷移は 床（フロア） にあります
shadow_mind_freshness:
  observer_last_heartbeat: 0h ago
  staleness_flag: FRESH

この封筒について、注目すべき3つのことがあります：

1. 信頼度は常に明示的 — HIGH / MEDIUM / LOW / INSUFFICIENT_DATA。オラクルは、疎いデータから確実性を作り出しません。一致が見つからない場合は、正直に INSUFFICIENT_DATA を返します。
2. 注意事項は構造的 — サンプルサイズ、時間的な構造、データソースの系譜。下流のパーサーは、信頼性についてプログラム的に推論できます。
3. 陳腐化は第一級 — Observer Daemon が24時間以上動いていない場合、古いパターンを提供するのではなく、オラクルは SHADOW_MIND_STALE を返します。エージェントは、状況に応じて適切にフォールバックできます。

Shadow Mind がすでに明らかにしたこと

最初のライブ起動時、Dreamer はたった54件の観測から27件の洞察候補を生成しました。そのうち、本当に役に立ったのは3つです：

• A デバッグループ検出：cto-1 は、解決マーカーがない1セッションの中で 5つの進化シグナル + 9つのメモリハンドオフを出力しました。これは介入がなければ拡大し続けていた、本物の認知ループです。
• 協業ギャップ検出：頻繁に登場するのに、決して同時にディスパッチされない2つのエージェント。共同ディスパッチのパターンが有効かどうかを評価する価値があります。
• 信頼ドリフトフラグ：短いウィンドウで、3つのクロスエージェントフラグを受け取ったエージェント。行動閾値は下回っていましたが、監視しておく価値があります。

これらのパターンは、明示的にコード化されていませんでした。Observer の構造化ログと、Dreamer の連想的な分析から現れたものです。つまり、「私が設計した通りのこと」を無意識の層が実行しているのです。

イノベーションのハイライト — ここで本当に新しいもの

「実際に何が新しいのか」を探しているなら、ここがそれです。他のエージェントのフレームワークでは、少なくとも組み合わせとしては見たことがありません：

1. 契約（コントラクト）テスト済みのエージェントプロンプト

341の構造的アサーション（11の不変条件 × 31のエージェント）を、コミットごとに pre-commit フックを通じて強制します。プロンプトのドリフトは「将来の問題」ではなく、ブロックされる状態です。

️ 2. ロール別allowlistを備えたNEXUSのシステムコールプロトコル

エージェントは SendMessage 経由で構造化されたシステムコールを発します。メインスレッドはカーネルです。制限のポイントは各エージェントに固有のallowlistがあることです。コンサルタントには PERSIST + CAPABILITIES? だけが渡されます。オラクルも同様です。ビルダーには完全なセットが渡されます。ロールごとのシステムコール規律は、他のどのエージェントシステムでも見たことがなく、サイレントな能力の肥大化を防ぐ最もクリーンな方法です。

3. Bayesian priors とライフサイクルステータスを備えた信頼台帳

新規採用は probationary 0.9 から開始します。<25% の否定率で、成功した5回のディスパッチを通じて active へ昇格します。基準に失敗すると、退職に向けた自動提案が出ます。信頼は「雰囲気」ではありません。成果によって較正され、クエリ可能なJSONスキーマで追跡されます。

4. ペアディスパッチのための Pair Protocol

elixir-engineer エージェントは、[NEXUS:SCALE count=2] により ee-1 / ee-2 へスケールします。そして両方のインスタンスが、マージ前に互いの差分をピアレビューします。これはディスパッチのパターンとしてのペアプログラミングです。同じプロンプトファイルを、2つのランタイムインスタンスで動かし、必須の相互レビューのゲートを通過させます。

5. Shadow Mind — 非侵襲な並列認知

6コンポーネントからなる無意識の層が、観測し、学習し、仮説を立て、そして夢を見ます。意識層のエージェントは一切変更しません。無効化できることは検証済み：mv shadow-mind/ /tmp/ → テストは 341/341 のまま通ります。これは、多くの「拡張可能」なシステムが証明できないアーキテクチャ上の規律です。

6. 動的採用パイプライン

チームは自分自身のカバレッジギャップ（5シグナルの重み付きスコア）を検知し、8フェーズのパイプライン（要求→調査→合成→契約バリデーション→敵対的レビュー→原子的登録→試用→退職）を通じて、新しい専門エージェントの採用を開始できます。チームは自分の人員数を自分で増やします。

⚔️ 7. 敵対的な自己レビュー

challenger エージェントは、他のエージェントの出力を攻撃するだけではありません。レビューア自身の推論を攻撃します。私が最初の「正直な注意事項」の章を書いたとき、challenger は自己奉仕的な謙虚バイアスを見抜き、私の証拠の誤りを修正しました（私のバイト数は2.6×ずれていました）。そして、システムの評価を B+ から A- に引き上げました。チームは自分たちの創り手自身をストレステストしています。

8. 契約としての、正準的なシグナルバスのエントリ形式

すべてのクロスエージェントの発見、メモリハンドオフ、進化シグナルは同じ正規表現でパース可能な形式を使います（- (YYYY-MM-DD, agent=X, session=Y) content）。下流のパーサー（Observer Daemon、Pattern Computer、oracle）は、この形式が安定していることに依存しています。ドリフトはサイレントな失敗です。したがって、この形式は単なる慣習ではなく、AGENT_TEMPLATE.md に 契約としてコーディングされています。

9. エージェントプロンプトに対するシングルライター不変条件

meta-agent だけが .claude/agents/*.md に書き込めます。recruiter も、cto も、elite-engineer も書き込めません。これにより、同時のプロンプト編集を防ぎ、プロンプト変更を原子的かつ監査可能にします。recruiter は新しいエージェントをスクラッチディレクトリへ下書きし、実際の登録は meta-agent に引き継ぎます。

10. 削除して無効化するアーキテクチャ

高度な能力はすべて、独立して削除して無効化できます：

• Shadow Mind：rm -rf shadow-mind/ → チームは引き続き動作
• 動的採用：talent-scout.md と recruiter.md を削除 → チームは引き続き動作
• 信頼台帳：ledger.py を削除 → チームは引き続き動作（ただし較正は低下）

ユーザーは欲しいものだけを採用します。複雑さはオプトインです。

ユースケース — このチームが実際にやっていること

チームが役に立つ具体的なシナリオ。現実のディスパッチパターンです：

ユースケース 1：並列マルチエキスパートのコードレビュー

user: "このPRをレビューして — Goバックエンド + Reactフロントエンド + Postgresの移行に触れている
ewline
"

→ cto が並列にディスパッチ：
    • go-expert    （Goのイディオムや並行性パターンをレビュー）
    • typescript-expert（Reactコンポーネントツリーや型の安全性をレビュー）
    • database-expert  （移行の安全性やロールバック互換性をレビュー）
    • deep-reviewer    （セキュリティ + デプロイ安全性の横断領域をレビュー）

→ 各エージェントがシグナルバス経由で所見を返す
→ evidence-validator がソースに対して HIGH 相当の主張を検証
→ challenger がユーザーに出す前に cto の統合結果をレビュー
→ ユーザーは、エージェントごとの信頼度重み付けを反映した統合レビューを受け取る

完全なレビューにかかる時間：単一エージェント方式の直列（約15分）に対して、並列なら約3分。

️ ユースケース 2：BEAMアーキテクチャ設計（Living Platform）

user: "セッションごとのエージェントカーネルに対する Plane 1 OTP 監督トポロジを設計して
ewline
"

→ cto が beam-architect（Tier 1 Builder）へルーティング
→ beam-architect がチームのメモリから apa-1 Wave 1 Option B のトポロジを参照
→ Horde/Ra/pg クラスターのトポロジを持つ4プロセスの SessionRoot 設計を生成
→ beam-sre に対して、K8s デプロイへの影響を伝える CROSS-AGENT FLAG を出力
→ 実装のために elixir-engineer を ee-1/ee-2 にスケールするという DISPATCH RECOMMENDATION を出力
→ メインスレッドが [NEXUS:SCALE] elixir-engineer の count=2 を自動でディスパッチ

これは、単一エージェントのフレームワークでは失敗してしまうタイプの、マルチ専門家によるアーキテクチャ上の連携ダンスです。

ユースケース 3：自動的な専門家検出 + 採用提案

[5セッションを超える間, ユーザーは「AWS CDK」を8回言及しており, チームは毎回
 AWSスペシャリストがいないため、汎用のエリート・エンジニアにフォールバックした]

→ talent-scout は5つのシグナルをスキャン（リポジトリ署名、ディスパッチのパターン、trust-ledger 
  AWSの主張における異常、外部トレンド、ユーザー行動パターン）
→ 信頼度を算出: 0.92
→ 共署名のために [NEXUS:ASK session-sentinel] を発行
→ session-sentinel が承認
→ 採用要求の YAML を下書き: "aws-cloud-engineer" 役割仕様
→ リクルーターに引き渡し
→ recruiter が8フェーズのパイプラインを実行:
    AWS Well-Architected Framework（15+件のソース引用）を調査
    プロンプトのマッチングを AGENT_TEMPLATE.md と統合
    契約テストを実行（11/11パス）
    チャレンジャーにルーティング（インフラ専門家とのドメイン重複チェック）
    meta-agent に引き渡し
→ meta-agent が aws-cloud-engineer を原子的に登録
→ 新しいエージェントは試用期間に入る（信頼重み=0.9、status=probationary）
→ <25%の反証率で5回ディスパッチした後、自動でアクティブに昇格

チームは自分たち専用のスペシャリストを採用した。ユーザーがそのギャップにサインオフし、残りは自動化された。

Use Case 4: Shadow Mind によるシャドウのパターン検索で高速な意思決定

user: "Goのストリーミングサービスで、SSEバッファリングのロジックをリファクタリングしてくれ"

→ cto（チームメイトのセッション内で）完全な Pattern A（plan→build→review→test→QA）を検討
→ 実装前に、[NEXUS:INTUIT]「SSEバッファリングを以前にリファクタリングしたことはある？
   どのエージェントが共同でディスパッチした？ 発見件数は？」と出力

→ intuition-oracle（Shadow Mind）が、観測＋パターン＋夢を読み取る
→ INTUIT_RESPONSE v1 を返す：
     confidence: MEDIUM
     sample_size: コーパス内で類似リファクタが12件
     top_matches: 
       - go-expert → elite-engineer → test-engineer（P=0.83、過去の結果はクリーン）
       - 平均の発見件数：2.1 HIGH + 4.5 MEDIUM
     caveats: コーパスは3か月未満

→ cto が Pattern A を調整：
     dispatches go-expert first（パターンが主要な発見を引き出すと言っているため）
     最初は deep-qa をスキップ（SSEの作業では、シグナルにならずノイズが増えるため）
     SSE のテストマトリクスで test-engineer を事前ウォームアップ
→ 実行時間：盲目的に Pattern A を回す場合より 40%高速

Shadow Mind がささやいた。CTO は耳を傾けた。チームはより速く出荷した。

Use Case 5: デバッグループ検出（詰まった思考パターンを捕まえる）

[長いセッションの間, cto-1 は進化シグナルを5つ＋メモリの引き継ぎを9回発行している
 同じアーキテクチャ上の意思決定について解決に至らないまま]

→ Dreamer（CronCreate によりアイドルウィンドウ中に実行）
→ 未解決のシグナルクラスターがあるか、観測をスキャン
→ 検出: "debug-loop — cto-1 × 14 signals 同じ トピック上で 0 resolution markers"
→ dreams/ に夢の候補 YAML を書き込み
→ proposed_to: meta-agent, review_status: pending
→ 次のセッションで、meta-agent が dreams/ のキューを読み取る
→ ユーザーに提案: "未解決の合成 ループの 根拠（Evidence）があります— これを 断ち切るために、 challenger または verifier をディスパッチすることを検討してください"
→ ユーザーが承認 → challenger が敵対的レビューを実行
→ ループが断たれ、意思決定がクローズする

これは、意識の側では見えなかった認知パターンを、無意識が捉えることです。明示的なルールはコード化されておらず、観測データから生まれました。

Use Case 6: 何も壊さずにプロダクション品質のプロンプトエンジニアリングを行う

チームへの変更はすべて：

1. 可逆 — すべての任意の機能に対して、disable-ability の不変条件が検証される
2. 契約テスト済み — 341の構造的アサーションが、すべてのコミットをゲートする
3. 信頼が追跡される — 新しいパターンは試用期間のステータスで入り、成果によって信頼を獲得する
4. ピアレビュー済み — 出荷前にチャレンジャーが攻撃し、エビデンス・バリデータが主張を検証する
5. メモリに永続化 — すべての発見がシグナルバスを通じてエージェント固有のメモリに流れ込む

つまり、システムを壊す恐れなしに大胆に実験できるということです。このアーキテクチャは「何を変更しても安全か」という考え方に見解を持っており、それを機械的に強制します。

実データによる検証

このシステムは現在、実際のプロダクション・コードベースに対して5週間（2026-03-18から2026-04-21まで）動作しています。データが実際に示していること：

実データにおける薄い箇所：python-expertはメモリファイルが12 KB / 1本のみで、go-expertは132 KB / 15本。重いPython作業でこのチームを採用する場合、そのセッションでそのデータが生成されるまでは、Python固有の行動キャリブレーションがGo相当より薄くなることを見込んでください。

The Team, Running Live

表の数値はひとまずそれとして。ここでは、セッションの途中でチームが実際にどう見えているかを示します — ドメインをまたいで並列に25人以上の仲間が派遣され、各メンバーには独自のトークン予算、ツール利用回数、そして稼働中のライブ状態があります。

ディスパッチのタクソノミーが実名として展開されているのが見て取れます：@cto-v5-phase0が編集戦略を行い、@challenger-dp-scaffoldがスキャフォールド提案を敵対的にレビューし、@ev-iam1〜@ev-iam5（IAM主張を検証する5つの並列証拠バリデータ）を回し、@memcoord-pattern-f-apr19がPattern Fをメモリへ排出（ドレイン）し、@meta-5hire-registerがその日の5人目の採用を原子的に登録し、@oracle-phase0-preflight（シャドウ・マインドの直観オラクル）が事前確認を行い、@sentinel-session-end-ap1mがセッションを締めくくる。

これらのエージェントはいずれも、契約テスト済みのプロンプト、エージェントごとのメモリディレクトリ、そしてトラスト台帳のエントリに裏打ちされています。命名規則（@<role>-<scope>-<date>）が、25人の並列の仲間を追跡可能に保つ方法です。インスタンス名を読むだけで、どのセッションの、どのロールで、どの作業項目から生まれた知見かを復元できます。

そして、これがメインスレッドから見たディスパッチの表面 — 実際にどのようにチームへ仕事を渡すか：

@mainのプレフィックスはカーネル宛てを表し、その後ろはメッセージを受け取る仲間（またはスクワッド）です。これがNEXUSプロトコルのユーザー向け表面です — SendMessageレイヤーが、人が1行のプロンプトから動かせる形へコンパイルされたもの。

The Honest Caveats

ここからは、ほとんどのブログが飛ばす部分。

システムは構造的に厳密であり、5週間の本番運用の後、意味のあるアウトカムデータがあります。 しかし、まだコードベースは1つです。継続的なマルチチーム、マルチコードベースでの振る舞いは未検証です。

公開時点での、特定の既知の弱点：

• コスト構成が opus に寄りがち。 31エージェント中28がデフォルトでopus。典型的な、手応えのある（非自明な）セッションのコストは$5〜20。低コストの採用者は、コミット済み利用の価格交渉をするか、ほとんどのエージェントをsonnetで動かすコスト志向の派生（フォーク）を期待するべきです。
• 契約テストは構造的であって、リグレッションスイートではない。 341/341パスは、すべてのエージェントが正しいセクションを持っていることを意味しますが、すべてのエージェントが正しい発見を生成することを意味しません。上記の67件のトラスト台帳の判断は行動面のバリデーションですが、プロンプトのドリフトをCIで検知するために走らせられる決定論的なリグレッションスイートではありません。このギャップを埋めることがv2の優先事項です。
• コードベースではN=1、ドメインではN=15。 チームは単一の本番コードベースに対して開発され、改善されました。マルチコードベース、多言語、マルチチームでの振る舞いは未検証です。上の「ドメインの幅」列は、各エージェントの行動記録が深いところ（api-expert、infra-expert）と薄いところ（python-expert、security-engineer）を示しています。採用者は、セッションがそれらのエージェントの記録を埋めるまで、薄いデータのドメインほどエッジが鋭くなることを見込むべきです。
• プロンプトのボリュームは実在する。 エージェントのプロンプト合計で約1.6 MB。各々50 KB超のエージェントが10人あり（CTOは103 KB）。これは（障害の分離という）「分散不変性保険」だと言えば言えるし、単なる膨張（bloat）だとも言える。私たちは前者に寄せていますが、ディスパッチあたりの測定可能なコストがかかっています。プロンプト分解（コア＋遅延ロードの参照テーブル）はv2の優先事項です。

さらに、チームのchallengerエージェントが、レビューア自身の推論に攻撃を仕掛けるという検証済みの自己レビュー機構もある。私がこの記事の「正直な注意点」セクションの初版を書いたとき、challengerが自己都合的な謙虚さバイアスに気づかせてくれた。つまり、弱さのカウントを膨らませて、調整済みであるように見せかけてしまっていたのだ。いま読んでいる改訂版は、そのストレステストの恩恵を受けている。メタ認知はただではないが、時には得難い価値がある。

完全なアーキテクチャ図（編集可能なMermaidソース＋ASCIIのフォールバック）：ARCHITECTURE_DIAGRAMS.md — 自分のスライドや発表向けに適宜調整して使ってほしい。

フードの中身

技術スタック：

• モデル：Claude（Claude Code経由）
• オーケストレーション：Claude Codeのサブエージェント・プリミティブ上に構築したカスタムのマルチエージェント調整レイヤー（NEXUSプロトコル）
• 言語：エージェント用プロンプトはMarkdown、Shadow MindスクリプトはPython 3、フックはBash
• メモリ：ファイルベースの永続化（.claude/agent-memory/）、執筆時点で31エージェントに対して約298個のメモリファイル
• Trust Ledger：信頼度のベイズ融合による重み付けを行うPython CLI。statusフィールド（probationary / active / retired）、評決＋チャレンジの履歴
• テスト：各エージェントの11の構造コントラクトを検証するPythonテストランナー
• フック：Pre-commit（契約テスト）＋SubagentStop（プロトコル検証）＋PostToolUse（NEXUSのsyscallログ）＋任意のポスト雇用・検証

より重要なサイズ指標：

• 341件の契約アサーションが通過
• 古いロスター参照を含むファイルが0
• 意識層と無意識層の間の結合が0（検証済み）
• 3つの独立した「書き込み権限」不変条件が保持されている（meta-agentがエージェント間で、memory-coordinatorがエージェント横断の統合で、ctoが戦略的な裁定でそれぞれ行う）

なぜこれがClaudeで特にうまく動くのか

Claude Codeチームに簡単に一言。— この仕組みは理論上は他のプラットフォームにも移植できるわけではなく、なぜそう言えるのかを具体的に説明したい。

このビルドを可能にしたClaude Codeの3つのプリミティブ：

1. マルチエージェント・プリミティブ（サブエージェント＋SendMessage＋TeamCreate） — すべてのLLMプラットフォームがこれを第一級でサポートしているわけではない。名前付きインスタンス間でメッセージルーティングするClaude Codeのチーム機構があるからこそ、NEXUSを独自のオーケストレーションコードなしで実装できる。
2. Claude Opus 4.7の長いコンテキストウィンドウ（1M） — エージェントが完全なメモリブリーフ＋30エージェントのロスター表＋ケイパビリティ領域を、切り詰めずに保持できる。短いコンテキストのモデルでは、私の全アーキテクチャは崩壊する。より小さなモデルで試した。役割の区別を保てないのだ。31人の専門家が、約50kトークンの中で区別のないゼネラリストの“スープ”になってしまう。
3. フックによるツールのサンドボックス化 — Pre-commit、SubagentStop、PostToolUseのフックにより、契約テストとシグナル永続化の不変条件を機械的に強制できる。プロンプト指示だけで「守ってくれることを期待する」のではない。プロトコルを壊すエージェントは、コミット時点でブロックされる。この一点は、他のプラットフォームにも採用してほしいClaude Codeの単一のプリミティブだ。

Anthropicチーム、読んでいるなら：半分冗談、半分本気でお願い — ぜひエンジニアリング視点で見てほしい。具体的には：

• Claude Codeのプリミティブ観点で、このNEXUSのsyscallパターンは妥当そうに見える？ それとも何かを無理にねじっているだけ？
• エージェント用プロンプトに対する単一ライター不変条件を、より綺麗に強制する方法はある？ それとも、私のパターンは概ねあなたが推奨するものに近い？
• Shadow Mindのオブザーバー・デーモンはpersistent=trueでMonitorを使っている — 長寿命のバックグラウンド処理には適切なプリミティブ？ それとも、より良いものを見落としている？
• セッション固定のサブエージェントレジストリ（新しいエージェントはディスパッチ可能にするために再起動が必要）— 既知の制限？ それとも、私が見逃したリフレッシュのパターンがある？

それらのどれかについて意見が聞けたら嬉しい。リポジトリに触ってみてほしい。PR、ツッコミ、そして「これはXのせいでひどいアイデアだ」— どれも同じように歓迎する。

次に向けて

次フェーズの優先事項：

1. アウトカムの追跡 — 現在は推論の質を測っている（evidence-validatorとchallengerによる）が、下流のプロダクション成果は測れていない。そのギャップを埋めるには、すべてのデプロイに追跡IDを付け、実データとなるメトリクスを信頼レジャーにフィードバックする。
2. 最初の本採用 — talent-scout → recruiter → meta-agentを、実際のカバレッジギャップに対してエンドツーエンドで実行する。これは、採用パイプラインを理論から実証済みに変える検証になる。
3. 適応的な深さルーター — 現状では、タイプミス修正のためにCTOをディスパッチするのは過剰だ。複雑性スコアリングのルーターで、ディスパッチ前に最小限で実行可能なエージェント集合を選ぶようにすれば、チームはエンジニアリング内部だけでなく、プロダクト文脈でも本当に使えるものになる。
4. Shadow Mindの利用計測 — 次の20セッションで、[NEXUS:INTUIT]がオーガニックに参照される頻度を追跡する。ゼロなら何かを学ぶ。頻繁なら別の何かを学ぶ。

チームは、これらすべてを自前のインフラを使って進化させていける。meta-agentは、観測されたパターンに基づいてプロンプトの進化を提案する権限を持つ。session-sentinelは時間の経過とともにプロトコル準拠を追跡する。信頼レジャーは、すべてのディスパッチに対するキャリブレーションデータを蓄積する。Shadow MindのDreamerは、最初の実行中にすでにこれらの追加の1つ（アウトカム追跡）を提案していた — まだ構築できていないだけだ。

自分で試してみる

GitHubリポジトリ（複雑なエンジニアリング向けの完全版）： https://github.com/asiflow/claude-nexus-hyper-agent-team

GitHubリポジトリ（コスト最適化のためのライト版）： https://github.com/asiflow/claude-nexus-hyper-agent-team-light

クローンすると得られるもの：

• 31のエージェントファイル（約1.3 MBの、本番向けにキャリブレーションされたプロンプト）
• 完全なインフラ（フック、テスト、信頼レジャー、Shadow Mindスクリプト）
• 完全なドキュメント（CLAUDE.md、TEAM_OVERVIEW、TEAM_RUNBOOK、TEAM_SCENARIOS、AGENT_TEMPLATE）
• 通過する契約テストスイート（341/341）
• 検証済みの「無効化可能性」不変条件

必要なもの：

• Claude Codeをインストール
• Claude APIキー（Anthropic）
• スクリプト用のPython 3

このリポジトリは、直接インストールできるように構成されています。クローンし、内容をあなたの .claude/ ディレクトリにコピーして、契約テストを実行して検証し、cto エージェントをディスパッチして開始してください。

ぜひ貢献してください。特に:

• 対応していない領域向けの新しい専門エージェントテンプレート
• 追加の Shadow Mind スクリプト（例: 領域特化型 Speculator の派生）
• エージェント品質を測定するためのより良いベンチマーク（私たちが正直に示しているギャップです）
• 実際に使って得た「現場の話」（ウォーストーリー）

構築

コアビルダー

	名前	役割	経歴
	Sherief Attia	CTO & 共同創業者	再生可能エネルギー、IoT、通信分野で、1,000億ドル超規模の事業のリードとスケールを担ってきたビジョナリーなAI起業家兼ソフトウェアアーキテクト（20年以上）。
	Khaled Elazab	AI戦略責任者 & 共同創業者	医療、教育、不動産、AIにまたがるチームを率いてきたテクニカルディレクター兼シニアソフトウェアエンジニア（5年以上）。
	Hossam Hegazy	エンジニアリング責任者 & 共同創業者	スケーラブルなマルチエージェントシステムを作ることに情熱を持つ、高度なAIシステムエンジニア兼ソフトウェアアーキテクト。

• Sherief: LinkedIn / GitHub
• Khaled: LinkedIn / GitHub
• Hossam: LinkedIn

私たちは ASIFlow を構築しています。エンタープライズ品質の信頼性・セキュリティ・スケールで、汎用人工知能の未来を実現します。

• ASIFlow のウェイトリストに参加: asiflow.ai/waitlist
• Source1: https://github.com/asiflow/claude-nexus-hyper-agent-team
• Source2: https://github.com/asiflow/claude-nexus-hyper-agent-team-light
• 質問、貢献、批評、辛口の見解: GitHub で issue を立てるか、Linkedin で DM してください

特に Anthropic のチームからのフィードバックを歓迎します。 このシステムは Claude Code の中で動作し、いくつかのプリミティブ（サブエージェント、SendMessage、フック、長いコンテキスト）を、私たちが他で見た以上に強く押し広げています。構造的にどこかおかしい点があるなら、あとで分かるよりも、ぜひあなたから教えてほしいです。PR も、遠慮のないツッコミ（roast）も同様に歓迎します。

タグ: #AIAgents #ClaudeAI #MultiAgent #LLMEngineering #OpenSource #AgentArchitecture #ClaudeCode #Anthropic