Xiora AI 組織アーキテクチャ: 9 agent + orchestrator + 憲法投入で何が変わったか

Introduction

Xiora は、単独創業者 1 名 + AI 社員複数名で 5 プロダクトを 24/7 運用しています。この構成を実現するために、私たちは 「9 agent + orchestrator + 憲法投入」 の AI 組織アーキテクチャを設計しました。

本記事では、Xiora AI Org spec v1.0 (services/platform/XioraAIOrg/) の設計思想と、実装で得られた知見を、developer / CTO 向けに公開します。

背景 — 「AI エージェント」の実運用が難しい理由

2025 年以降、AI エージェント (LLM ベースの自律エージェント) の実用化が進む一方で、実運用で以下のような課題が繰り返し観察されました。

1. 暴走リスク: エージェントが想定外の action を実行し、外部システムに影響を与える

2. 責任分界の曖昧さ: 複数エージェントが同じ判断領域に手を出し、結果が非決定的になる

3. 監査可能性の欠如: どのエージェントがいつ何を決めたかのログが分散し、後から追跡できない

4. 憲法/ポリシーの散逸: 各エージェントに個別の system prompt があり、組織全体で「何をしない」が統一されない

Xiora AI Org spec v1.0 は、これら 4 課題に対する具体的な設計解として設計されました。

---

Layer 構成

Xiora の AI 組織は 3 層で構成されます。

Layer 1: Orchestrator (単一責任)

services/platform/XioraAIOrg/app/orchestrator/ に実装。組織全体で 1 個のみ、AI 社員間の task queue 管理・優先度判定・承認 gate の実行を担う。

Orchestrator は自ら判断を下しません (LLM を呼びません、決定論的にルーティングだけをする)。判断は必ず下層の Agent に委譲され、Orchestrator は結果を Reo 承認 queue に集約します。

Layer 2: Agents (9 role)

各 Agent は「役割」を持ち、以下 9 種類に整理されます。

| Code | Role | 責任範囲 |

| ---- | ---- | -------- |

| CEO | Chief Executive | Reo proxy、escalation format 化 |

| CTO | Chief Technology | 技術方針、コードレビュー一次判定 |

| PROD | Product | 仕様書 draft、gap 検出 |

| SALES | Sales | 見込み顧客 follow-up proposal |

| SUPP | Support | 既存顧客への問い合わせ返信 draft |

| MKT | Marketing | LP コピー、SEO draft |

| LEGAL | Legal | 規約・特商法・プラポリ draft 監視 |

| FIN | Finance | 月次売上・コスト集計 draft |

| OPS | Operations | インフラ監視、障害検知一次通知 |

(実際の 12 社員は上記 9 role に加え、Data / Writer / QA を追加した拡張構成。spec v1.0 は 9 role を core とする)

Layer 3: Substrate (LLM providers)

services/platform/XioraAIOrg/app/substrate/ に実装。以下 2 tier で構成:

• L1_LOCAL: Ollama (llama3.2 / qwen2.5 等) — cost ¥0、privacy 高、latency 中
• L2_CLOUD: Claude API (Sonnet 4.6 / Opus 4.7) — cost 有、privacy 中 (ゼロデータリテンション設定)、latency 低

各 Agent は「タスク種別」に応じて L1 → L2 の順で fallback。ゼロ予算運用では L1 のみで完結する task が多く、Claude API 呼び出しは 「複雑な文章 draft」「長文コード生成」等に限定しています。

---

憲法投入 (Constitution Injection)

Xiora AI Org の中核は 「憲法投入」 の仕組みです。

docs/PROJECT_GUIDELINES.md に組織全体の「やらないこと」「守るべきこと」を明記し、全 Agent の system prompt にランタイムで注入します。

具体的には、Orchestrator が Agent 呼び出し時に以下を実施します。

1. docs/PROJECT_GUIDELINES.md を読み込み

2. Agent の role-specific prompt に prefix として憲法を追加

3. Agent の action 実行前に、憲法違反可能性を regex + LLM (低コスト L1) で 2 段チェック

4. 違反検知時は Orchestrator が action を拒否、Reo 承認 queue に「憲法違反疑い」として上げる

これにより、以下が保証されます。

• 組織全体で「何をしない」が統一 される (規約変更 = 1 ファイル書き換えで全 Agent に反映)
• 監査可能性: 憲法違反検知ログは xai_agent_audit_log に永続化、後から追跡可能
• 暴走防止: 憲法違反系の action は Orchestrator layer で必ずブロックされる

---

Permanent Human Gate (5 領域のみ)

Xiora AI Org では、Reo (代表) の承認が 永続的に必須 な action を 5 領域に限定しています。

| Gate | 内容 |

| ---- | ---- |

| billing | 課金設定変更 (Stripe live flip 等) |

| delete | データ・アカウント削除 |

| permission | 権限変更 (Agent の scope 拡大) |

| contract | 契約締結 (受託契約、SaaS 契約等) |

| KYC | 本人確認関連 (Stripe KYC、銀行口座開設等) |

この 5 領域以外は Agent が自律実行可能 です。逆に言えば、この 5 領域はどれだけ AI が進化しても、Reo 承認なしに実行できません。

これは「AI に何を任せて、何を任せないか」の設計判断です。「全部任せる」でも「何も任せない」でもなく、責任と権限の境界を明確に引く ことが、単独創業で AI を実運用する上で最重要でした。

---

実装の勘所

1. Orchestrator は LLM を呼ばない

Orchestrator が LLM を呼ぶと、Orchestrator 自体が非決定的になり、監査が困難になります。Xiora では Orchestrator を 決定論的なルーティング層 に徹底し、判断は Agent に委譲する設計を選択しました。

2. Agent 間通信は Orchestrator 経由のみ

Agent A → Agent B の直接通信は禁止。全て Orchestrator を経由します。これにより:

• 通信ログが 1 箇所に集約
• Circular dependency の防止
• Agent の差し替え・削除が容易 (Orchestrator の routing table 変更のみ)

3. LLM output は必ず agent_action_proposal を経由

Agent が直接 external system (git, API, DB) を触ることを禁止。全ての action は agent_action_proposal テーブルに proposal として書き込み、Orchestrator が承認判定を実行 → 承認済みなら executor が action を実行する分離設計としています。

これにより、Agent の LLM output が誤動作しても、executor 層で最終的な action ブロックが可能です。

4. 憲法違反検知は regex → LLM の 2 段構え

軽量な regex 検査 (禁止表現リスト、URL パターン等) を最初に実行し、grey zone のみ LLM (L1_LOCAL) に判定させます。全ての output を LLM 検査に回すのはコスト過大なので、規模の経済で 2 段構えにしています。

5. Audit log は WORM (Write Once Read Many) 志向

xai_agent_audit_log テーブルは、insert only (update / delete なし)。改ざん検知のため、行ごとに前行の hash を含む chain 構造を採用しています。

---

M10.3 達成で何が変わったか

Xiora AI Org spec v1.0 の M10.3 マイルストーン (2026 年 7 月時点で達成済み) では、以下を確立しました。

• 9 agent (core) の role 定義と system prompt (BUILD_PLAN §M10.1)
• Orchestrator の task queue + routing table 実装 (BUILD_PLAN §M10.2)
• 憲法投入 pipeline と audit log の永続化 (BUILD_PLAN §M10.3)

これにより、それまで「Reo が手動で prompt を打ち込んで Claude と対話する」という運用から、「Reo は承認判断だけを行い、Agent が自律的にタスクを進める」運用へ移行できました。

具体的な効果:

• Reo の作業時間 / 日: 8 時間 → 15-30 分 (承認セッションのみ)
• 障害検知〜対応開始: 数時間 → 数分 (Ops Agent が自律で 1 次対応 draft)
• 新プロダクト立ち上げ工数: 数週間 → 数日 (Product Agent が仕様 draft、CTO Agent がコード draft)

「Reo が寝ている間に、Xiora が動き続ける」体験が、実運用として成立しました。

---

課題と今後の計画

M10.3 は core の確立に過ぎず、以下の課題が残っています。

• Agent 間の意見対立 (Sales vs Legal) の自動調停 → 現状は Reo escalation で人力解決
• 憲法の版管理: 憲法 v1 → v2 移行時の Agent への段階的反映
• LLM cost の予算 gate: 月次 cap を超えないための自動 fallback 強化
• 12 week BUILD_PLAN の M10.4 以降 (認証・監査・障害 recovery) の実装

これらは services/platform/XioraAIOrg/BUILD_STATUS.md と MAPPING_TO_BRAIN.md に沿って段階的に実装していきます。

---

Xiora の受託開発について

Xiora は自社プロダクトの他、AI 導入コンサル・受託開発を承っております。以下のような案件をお受けしています。

• AI エージェント組織の設計・実装: 貴社の業務プロセスに合わせた Multi-Agent アーキテクチャの設計
• 憲法投入 / 監査 log 設計: コンプライアンス要件の高い業界での AI 導入
• Claude API + Local LLM ハイブリッド構成: cost / privacy 要件に応じた LLM 選定

お問い合わせは info@xiora-official.com までご連絡ください。

---

参考リンク

• Xiora コーポレートサイト: https://xiora-official.com/
• 受託開発 (AI 導入コンサル): https://xiora-official.com/ai-consulting.html
• Xiora AI Org 内部仕様: services/platform/XioraAIOrg/ (README / CLAUDE.md / BUILD_STATUS.md)

---

筆者: Xiora 代表 沓澤 怜士 (kutsuzawa reo)

連絡: info@xiora-official.com

---