Symbiont ドキュメント¶

Symbiont 2.0： 更新前に移行ガイドとリリースの検証を確認してください。プロンプトキャッシュとガバナンス下の改善機能は明示的な有効化が必要なオプションです。既存エージェントで自動的に有効になることはありません。

エージェント型アプリケーションを構築するための、ポリシー制御プラットフォーム。明示的なポリシー、アイデンティティ、監査制御の下で AI エージェントとツールを実行します。

目的に応じた読み進め方¶

本ドキュメントは 3 つの異なる目的に向けて書かれています。目的ごとに必要なページも読む順序も異なるため、一覧を順に読むのではなく、自分に合った経路を選んでください。

信頼できるかどうかを評価する。 実際に強制されているのは何か、単に記録されているだけなのは何か、そして主張の境界はどこにあるのかを知る必要があります。.symbi ファイルを一度も書かないかもしれません。

1. 30 秒でゲートを確かめる — 後述。オフラインで、インストールを前提としません
2. セキュリティモデル — 信頼境界、3 つの分離ティア、検証ではなく信頼している対象
3. 準備済み呼び出し — 認可とは何か、そしてなぜ再生できないのか
4. 保護された実行監査 — ジャーナルが証明すること、しないこと
5. 承認のライフサイクル — レビューに束縛された解放、期限、承認者の識別の限界
6. 封じ込めガイド — 現在のカバー範囲と、率直に述べた未対応箇所
7. 公開された評価 — DOI 10.5281/zenodo.20043247

エージェントを構築し運用する。 まず動くプロジェクトが必要で、次に、別の担当者が当番のときにも保たれる囲いが必要です。

1. ゲートを確かめる — 成功ではなく拒否から始める
2. はじめに — インストール、symbi init、最初のエージェント
3. DSL ガイド — エージェント定義。強制されるルールの部分集合についてはインライン作用ポリシーも参照
4. コマンドの分離 — ツールが実際に動作するワーカーを設定する
5. ToolClad — 宣言的なツールコントラクトとスコープの強制
6. 承認のライフサイクル — 人の判断を要する拒否に対する正しい答え
7. ランタイムアーキテクチャと API リファレンス — 配備する段階で
8. Symbi Shell（Beta） — 対話的なオーサリングと Gate パネル

仕様を読む。 適合性、再現性、そして標準がベンダーから切り離せるかどうかを重視しています。

1. Open Agent Trust Stack — 仕様（CC BY 4.0）、OATS Extended C1–C7 + E1–E8
2. 推論ループ — 実装された型状態の ORGA サイクル
3. 準備済み呼び出し — 認可オブジェクトとその回帰テストのカバー範囲
4. セキュリティモデル — Tier 3 のゲスト認証を含む、各ティアの保証
5. 発表済みの研究 — Typestate ORGA Loops、ToolClad、Empirical Evaluation
6. コントリビューション — 再現用のハーネスはリポジトリに含まれています

AI コーディングエージェントにセットアップさせますか？ 何かに手を付ける前に https://symbiont.dev/agent-guide.md を読ませてください。最新の文法とフラグ、そして「セットアップのエラーをポリシーの緩和で解決してはならない」という恒久的なルールを記した、安定したプレーンテキストの指示ファイルです。

まず確かめる — オフライン、API キー不要¶

まずは Symbiont に何かを拒否させてみてください。ここで使うのは、ランタイムが実際の推論ループに組み込むのと同じ Cedar ゲートを単体で評価したものです。したがって、ここでの拒否は実行時の拒否と同じです。モデルプロバイダーも Docker もプロジェクトも不要です。

インストール：

curl -fsSL https://raw.githubusercontent.com/ThirdKeyAI/Symbiont/main/scripts/install.sh | bash
export PATH="$HOME/.symbi/bin:$PATH"

2 つのポリシーを書き、それに照らして評価する：

mkdir -p /tmp/p && cat > /tmp/p/policy.cedar <<'EOF'
forbid(principal, action == Symbi::Action::"tool_call::list_agents",   resource);
permit(principal, action == Symbi::Action::"tool_call::system_health", resource);
EOF

echo '{"tool_name":"list_agents"}'   | symbi policy evaluate --stdin --policies /tmp/p --json
echo '{"tool_name":"system_health"}' | symbi policy evaluate --stdin --policies /tmp/p --json

{"decision":"deny","reason":"deny policies matched: policy_0","tool":"list_agents", ...}
{"decision":"allow","reason":"allow policies matched: policy_1","tool":"system_health", ...}

次に、引数の検証が実行前に呼び出しを止める様子を確認する：

symbi tools init greet
symbi tools validate
symbi tools test greet --arg target=example

greet                                    OK

  ✓ target (string): example → OK

  Command:   greet example
  Cedar:     Tool::Greet / execute_tool

  [dry run — command not executed]

拒否されることこそがデモンストレーションです。成功した実行で終わるクイックスタートが証明するのは、プログラムが動いたということだけであり、それはどのエージェントフレームワークのクイックスタートでも証明できます。

エージェントを実行するにはモデルプロバイダーが必要です。はじめにに進んでください。

Symbiont とは？¶

Symbiont は、明示的なポリシー、アイデンティティ、監査制御の下で AI エージェントとツールを実行するための Rust ネイティブプラットフォームです。

ほとんどのエージェントフレームワークはオーケストレーションに焦点を当てています。Symbiont は、エージェントが実際のリスクを伴う実環境で実行される場合に何が起こるかに焦点を当てています：信頼されないツール、機密データ、承認境界、監査要件、再現可能な実施。

仕組み¶

Symbiont はエージェントの意図と実行権限を分離します：

1. エージェントが提案 — 推論ループ（Observe-Reason-Gate-Act）を通じてアクションを提案
2. ランタイムが準備 — 引数を正規化し、コントラクト、解決された作用、選択されたサンドボックス、期限を 1 つの不変な呼び出しとして固定
3. ポリシーが決定 — Cedar とサポートされるインラインルールの両方が許可する必要があります。拒否されたアクションはブロックされ、承認が指定されたアクションは人間に回送されます
4. 記録が先に残る — 作用の前に必須となるジャーナル書き込みが、ディスパッチより先に成功する必要があります
5. ワーカーが実行 — 選択されたサンドボックスの内部で実行され、ホスト上で実行されることはありません

モデル出力は実行権限として扱われることはありません。ランタイムが実際に何が起こるかを制御します。

コア機能¶

追加機能：ツール/スキルコンテンツの脅威スキャン、cron スケジューリング、永続エージェントメモリ、ハイブリッド RAG 検索（LanceDB/Qdrant）、webhook 検証、配信ルーティング、OTLP テレメトリ、HTTP セキュリティ強化、チャネルアダプター（Slack/Teams/Mattermost）、および Claude Code と Gemini CLI のガバナンスプラグイン。

プロジェクトをスキャフォールドする¶

symbi init        # インタラクティブ：プロファイル、SchemaPin モード、サンドボックスティア。
                  # symbiont.toml、agents/、policies/、docker-compose.yml、および
                  # 生成された SYMBIONT_MASTER_KEY を含む .env を書き込みます。
symbi run <agent> # フルランタイムを起動せずに単一エージェントを実行
symbi up          # 自動設定でフルランタイムを起動
symbi shell       # インタラクティブなエージェントオーケストレーションシェル（Beta）

CI 向けの非インタラクティブ実行：

symbi init --profile assistant --schemapin tofu --sandbox tier1 --no-interact

Docker を使う場合 — イメージの WORKDIR はマウント先とは異なるため、--dir を渡します：

docker run --rm -v $(pwd):/workspace ghcr.io/thirdkeyai/symbi:latest \
  init --profile assistant --no-interact --dir /workspace
docker compose up

ランタイム API は http://localhost:8080、HTTP 入力は http://localhost:8081 で公開されます。

その他のインストール方法 — Homebrew（brew tap thirdkeyai/tap && brew install symbi）、cargo install symbi（Rust 1.89 以降と protobuf-compiler が必要）、または GitHub Releases。詳細ははじめにをご覧ください。

最初のエージェント¶

metadata {
    version = "1.0.0"
    author = "your-name"
    description = "Writes one reviewed file"
}

agent writer() {
    capabilities = ["write"]

    with sandbox = "docker", timeout = 20.seconds {}

    policy files {
        allow: "edit_file" if invocation.arguments.path == "result.txt"
        deny:  "edit_file" if invocation.arguments.content == ""
    }
}

インラインの policy ブロックはコンパイルされ、Cedar と並んで強制されます — 両方が許可する必要があります。サポートされる部分集合は意図的に小さく、ランタイムが強制できないルールは、黙って無視されるのではなく、モデルが呼び出される前に呼び出しを失敗させます。正確な文法についてはインライン作用ポリシーを、metadata、schedule、webhook、channel ブロックについては DSL ガイドをご覧ください。

インタラクティブシェル (Beta)¶

symbi shell は、LLM 支援によるエージェント、ツール、ポリシーのオーサリング、マルチエージェントパターン（/chain、/parallel、/race、/debate）のオーケストレーション、スケジュールとチャネルの管理、リモートランタイムへのアタッチを行うための ratatui ベースのターミナル UI です。Ctrl+G を押すと Gate パネルが開き、保留中のアクションをレビューできます。ステータスは beta であり、コマンドサーフェスと永続化フォーマットはマイナーリリース間で変更される可能性があります。Symbi Shell ガイドおよびシェルのワークスペース設定を参照してください。

シングルエージェントのデプロイ (Beta)¶

シェルの /deploy コマンドは、アクティブなエージェントをパッケージ化し、Docker（/deploy local）、Google Cloud Run（/deploy cloudrun）、または AWS App Runner（/deploy aws）にデプロイします。OSS スタックはシングルエージェント構成です。マルチエージェントトポロジーはクロスインスタンスメッセージングで構成します。Symbi Shell — デプロイ を参照してください。

アーキテクチャ¶

graph TB
    A[Policy Engine — Cedar] --> B[Core Runtime]
    B --> C[Reasoning Loop — ORGA]
    B --> D[DSL Parser]
    C --> P[Prepared Call]
    P --> G[Escalation Gate]
    P --> E[Sandbox Worker]
    P --> I[Protected Journal]

    subgraph "Scheduling"
        S[Cron Scheduler]
        H[Session Isolation]
        R[Delivery Router]
    end

    subgraph "Channels"
        SL[Slack]
        TM[Teams]
        MM[Mattermost]
    end

    subgraph "Knowledge"
        J[Context Manager]
        K[Vector Search]
        L[RAG Engine]
        MD[Agent Memory]
    end

    subgraph "Trust Stack"
        M[MCP Client]
        N[SchemaPin]
        O[AgentPin]
        SK[Threat Scanner]
    end

    C --> S
    S --> H
    S --> R
    R --> SL
    R --> TM
    R --> MM
    C --> J
    C --> M
    J --> K
    J --> L
    J --> MD
    M --> N
    C --> O
    C --> SK

セキュリティモデル¶

Symbiont はシンプルな原則に基づいて設計されています：モデル出力を実行権限として信頼すべきではありません。

アクションはランタイム制御を通じて流れます：

• ゼロトラスト — すべてのエージェント入力はデフォルトで信頼されない
• 準備済み呼び出し — 認可された呼び出しは固定され、単回限りで、ディスパッチ時に再検査される
• ポリシーチェック — すべてのツール呼び出しの前に、Cedar とサポートされるインラインルールの両方がフェイルクローズで評価される
• ツール検証 — ツールスキーマの SchemaPin 暗号学的検証
• 封じ込め — Docker、gVisor、Firecracker のワーカーを使用し、ホストへのフォールバックはない
• オペレーター承認 — リクエスト全体を人間がレビューし、ID ではなくダイジェストによって解放する
• シークレット制御 — Vault/OpenBao バックエンド、暗号化ローカルストレージ、エージェント名前空間
• 監査ログ — 作用のあとではなく、その前に書き込まれる改ざん防止レコード

詳細についてはセキュリティモデルガイドを、現在のカバー範囲と残された未対応箇所については封じ込めガイドをご覧ください。

主張していないこと¶

保証だけを並べたセキュリティのページは、ただ信じてほしいと言っているにすぎません。以下の限界は、後から発見されるのではなく、ここで明示しておきます：

• ホストの設定、ワーカーのイメージ、コンテナランタイム、運用者が用意した推論エンドポイント、注入された SDK 実装は、検証された構成要素ではなく信頼された構成要素です。
• 封じ込めはすべてのエントリーポイントで完全ではありません。公開のブラウザ実行、全体の受付制御、自動的なリプレイや復旧は、利用できないか、これらの契約の対象外です。
• 推論ループは、ツールのエラーやポリシーによる拒否のあとでも Completed に到達し得ます。個々のツールの結果を確認してください。終端の書き込みは、作用が発生したあとで失敗することがあります。エラーはロールバックではありません。 ジャーナルの欠落や不完全さは証拠の不在であって、成功の証拠ではありません。
• 端末での承認者の識別情報は、ローカル運用者の実効 UID です。これは OS のアカウントであり、独立に検証された個人ではありません。レビューのダイジェストは厳密なリクエストを束縛しますが、人がそれを読んだことを証明するものではありません。
• 決定論的に条件を揃えた実験室での試行は、それぞれのシナリオを立証します。モデルの脱出率を示すものではありません。
• SOC 2、HIPAA、ISO 27001 は、監査証跡が適合を目指している対象です。認証を取得しているわけでも、取得を示唆するものでもありません。

すべてのガイド¶

封じ込めとガバナンス

• 封じ込めガイド — 運用ワークフロー、アーキテクチャ、移行、残された未対応箇所
• 準備済み呼び出し — 厳密な呼び出し単位の認可と Cedar のリクエスト形状
• 承認のライフサイクル — 端末、TUI、チャットでのレビュー
• 保護された実行監査 — 実行の識別、ジャーナルの検証、不完全な結果
• クラッシュの調査 — 再実行せずに、中断された実行と未解決の作用を検証
• インライン作用ポリシー — 強制される DSL ルールの部分集合
• コマンドの分離 — ツールとパーサー向けのワーカー設定
• 操作単位のファイル権限 — 宣言された入力、上限付きの新規出力、パーサーの分離
• Docker の所有権 — ライフタイム、クリーンアップ、復旧
• 対話型ターミナル — 封じ込められた PTY セッション
• シェルのワークスペース — TUI におけるガバナンス下のファイルツールとコマンドツール
• 管理 CLI — 外部の AI CLI を封じ込められた子プロセスとして実行する
• ガバナンス下のブローカー — 仲介されるツール呼び出し API
• DSL 呼び出しコンテキスト — 呼び出し元の識別情報と固定されたプロジェクトルート
• スケジュールされた実行 — 呼び出し ID と終端の結果
• 呼び出しの冪等性 — 永続的な CLI リクエストの識別と安全な結果取得

コア

• はじめに — インストール、設定、最初のエージェント
• Symbi Shell（Beta） — オーサリング、オーケストレーション、リモートアタッチのためのインタラクティブ TUI
• セキュリティモデル — ゼロトラストアーキテクチャ、ポリシー実施、分離ティア
• ランタイムアーキテクチャ — ランタイム内部と実行モデル
• 推論ループ — ORGA サイクル、ポリシーゲート、サーキットブレーカー
• DSL ガイド — エージェント定義言語リファレンス
• ToolClad — 宣言的なツールコントラクト、引数の検証、スコープの強制
• MCP ツール — ガバナンス下の Model Context Protocol アクセス
• API リファレンス — HTTP API エンドポイントと設定
• スケジューリング — Cron エンジン、配信ルーティング、デッドレターキュー
• HTTP 入力 — Webhook サーバー、認証、レート制限
• Firecracker セットアップ — Tier 3 のカーネル、rootfs、ゲストトランスポート
• Firecracker 管理ホストサービス — オプションの jailer、ホスト側の制限、watchdog の配備
• セッション型（実験的） — エージェント間プロトコルの適合性監視

コミュニティとリソース¶

• エージェント向けガイド: symbiont.dev/agent-guide.md — セットアップを行う AI コーディングエージェントへの指示
• パッケージ: crates.io/crates/symbi | npm symbiont-sdk-js | PyPI symbiont-sdk
• SDK: JavaScript/TypeScript | Python
• プラグイン: Claude Code | Gemini CLI
• 課題: GitHub Issues
• ライセンス: Apache 2.0 (Community Edition)

次のステップ¶