クレート

ワークスペースは複数のレイヤーに分割されています。エッジクレートは外部の世界とやり取りし、コアクレートはオーケストレーションを行い、サポートクレートはユーティリティを提供します。各クレートには独自の rustdoc があります。API (rustdoc) を参照してください。

レイヤー: コア

`zeroclaw-runtime`

zerocode のエージェントループ、セキュリティポリシーの適用、SOP エンジン、cron スケジューラ、SubAgent のライフサイクル、および RPC レイヤーです。その他すべての core および edge クレートに依存します。

注目すべきサブモジュール:

agent/: メインのリクエスト/レスポンスループ、ストリーミング、ツール呼び出しのオーケストレーション
security/: ポリシータイプ、サンドボックス検出、OTP、緊急停止
sop/: 標準作業手順（SOP）エンジン（SOP → 概要を参照）
subagent/: SubAgent の生成とライフサイクル（委譲とSubAgentを参照）
cron/、daemon/、heartbeat/: スケジューリングと長時間実行プロセスの管理
skills/: スキルのコンパイルと実行
service/: systemd / launchctl / Windows サービス統合
rpc/: zerocode の RPC レイヤー

`zeroclaw-config`

TOMLスキーマとその検証。対応するもの：

自律レベルの列挙型（ReadOnly / Supervised / Full）
暗号化されたシークレットストア（ローカルキーファイル）
ワークスペースの解像度（環境変数、Homebrew パス、XDG、コンテナ検出）
スキーマのバージョン管理とマイグレーション

すべてのユーザー向け設定キーは、このクレートから生成されるリファレンス → 設定に文書化されています。

`zeroclaw-api`

カーネルABI。コア公開トレイトを定義します。これには以下が含まれます：

ModelProvider: ストリーミング機能フラグを備えた LLM クライアントインターフェース
Channel: 受信/送信メッセージングサーフェス
Tool: エージェントから呼び出し可能な機能
Memory: 会話の保存と取得
Observer: 型付きメトリクス／可観測性シンク

ランタイムはこれらのトレイトにのみ依存しており、具体的な実装には依存していません。これにより、プロバイダー/チャンネル/ツールの追加は、コアをパッチするのではなく、トレイトを実装するだけで済むようになります。

レイヤー: エッジ

`zeroclaw-providers`

すべての LLM クライアント実装に加えて、ルーティングおよびリトライのラッパーを含みます。一覧については Model Providers → Overview を参照してください。

構造:

traits.rs: zeroclaw-api からの re-export とプロバイダー内部のヘルパー
anthropic.rs、openai.rs、ollama.rs など: ネイティブプロバイダーごとに1ファイル
compatible.rs: 20以上のプロバイダー（Groq、Mistral、xAI、Veniceなど）で再利用される単一のOpenAI互換実装
router.rs: ヒントベースの呼び出しごとのモデルルート選択
reliable.rs: リトライ / バックオフ / クールダウン、およびモデルプロバイダーの順序付きフォールバックラッパー
streaming.rs: SSE解析、トークン推定、ツールコールのデルタ

`zeroclaw-channels`

30以上のメッセージングインテグレーション。カタログについてはチャンネル → 概要をご覧ください。

すべてのチャネルは zeroclaw-api の Channel トレイトを実装します。各チャネルはフィーチャーゲートされており、最小ビルドにはコンパイル時に含めたチャネルのみが含まれます。

orchestrator/ サブモジュールは、メッセージストリーミング、ドラフト更新、複数メッセージ分割、および ACP サーバーを処理します。

`zeroclaw-gateway`

HTTP/WebSocketゲートウェイ。ランタイムを以下で公開します：

REST API（セッション、メモリ、ステータス、cron管理）
ストリーミング応答用のWebSocket
Webダッシュボード（静的アセット + 認証）
Webhookエンドポイント（チャネルからプッシュされるインバウンド用）

ペアリングはデフォルトで必要です。[gateway.allow_public_bind = true] を設定すると、0.0.0.0 へのバインドが可能になります。

`zeroclaw-tools`

エージェントが呼び出す呼び出し可能なツール。CLIのzeroclawサブコマンドとは混同しないでください。

含む: browser、http_request、web_search、shell、file_read、file_write、ハードウェアプローブ（hardware_board_info、hardware_memory_read）など。詳細はツール → 概要を参照。

各ツールはファクトリ経由で登録され、Fluentローカライズされた文字列によってモデルに説明されます。

レイヤー: サポート

`zeroclaw-memory`

会話のメモリと検索。SQLite がデフォルトのバックエンドです。マルチインスタンス展開で共有かつ同時書き込みに対応するストアが必要な場合は、--features memory-postgres を介して PostgreSQL を利用できます。オプション:

埋め込みバックエンド（OpenAI、Ollama、ローカル）
保存された会話に対するベクトル検索（PostgreSQLを使用している場合はpgvector）
メモリ統合（要約、事実抽出）

`zeroclaw-tool-call-parser`

モデル側のツール呼び出し構文の解析。プロバイダー間のバリエーションに対応します：

OpenAIスタイルの tool_calls JSON
Anthropicスタイルの <tool_use> ブロック
Qwen/Ollamaの関数呼び出しフォーマット
ネイティブツール呼び出しストリーミングデルタ

`zeroclaw-plugins`

サンドボックス化されたWASMプラグインホスト: コンポーネントモデルプラグイン (tool、channel、memory、skillバンドル) を、呼び出しごとのfuelおよびメモリ制限のもとWASIでインプロセスに読み込みます。開発 → プラグインプロトコルを参照してください。

`zeroclaw-hardware`

ハードウェア抽象化: GPIO、I2C、SPI、USB。プラットフォームで制御されます。ハードウェア → 概要を参照してください。

ワークスペース内のすべてのログイベントに対する単一の出力面。ディスク上のJSONLスキーマ（LogEvent）、エイリアスにバインドされた属性レジストリ（ATTRIBUTION_FIELDS + COMPOSITE_PREFIXES）、すべての tracing::* 呼び出しをキャプチャする tracing-subscriber Layer、record! および scope! マクロ、ローリングトリムライター、/api/logs の背後にあるページネーション対応のカーソルリーダー、Prometheus / OTel コンシューマー向けの型付き Observer へのブリッジを管理します。architecture/logging.md を参照してください。

`zeroclaw-spawn`

tokio::spawn の公式ラッパーです。spawn! マクロを提供します。このマクロは、すべてのバックグラウンドタスクを呼び出し元の現在のアトリビューションスパンで計測するため、spawn されたフューチャー内で発行された record! は親の agent_alias / channel / session_key を継承します。呼び出し箇所では、tokio::spawn を直接使用する代わりに spawn! を使用します。

`zeroclaw-infra`

プロセスレベルのサポート: デバウンサー、ウォッチドッグ、SQLite セッションバックエンド。トレーシング/メトリクスのレイヤーではありません。それは zeroclaw-log です。config、sessions、memory、logs、costs、cron、gateway メタデータにわたる状態の所有権と永続性の境界については、Runtime state and persistence を参照してください。

`zeroclaw-macros`

設定スキーマ、ツール登録、およびチャンネル登録のマクロを導出します。ワークスペース全体でボイラープレートを削減します。

`zerocode`

ターミナルUI。apps/zerocode/ 配下の独立したアプリとして構築されています。これは独自のワークスペースメンバーであり、zeroclaw-* クレートへの依存はありません（独立したi18nカタログについてはドキュメントと翻訳 → zerocode strings を参照してください）。

機能フラグ

マイクロカーネルのロードマップ（RFC #5574）は、機能フラグの分類体系を定義しています。ユーザーにとっての実用的な影響は以下の通りです：

default: 適切なコアビルド
ci-all: CI向けにすべてを有効化
channel-<name>: チャンネルごとのオプトイン（例: channel-matrix、channel-discord）
hardware: ハードウェアサブシステムを有効化する
gateway、acp-bridge、whatsapp-web: オプトインの機能グループ

プロバイダーはフィーチャーゲートされていません。すべてコンパイルに含まれます。チャネルの選択がビルドごとの主要な設定項目です。完全な一覧については、トップレベルの Cargo.toml の [features] テーブルを参照してください。

ZeroClaw Docs