Google、実験的エージェントオーケストレーション用テストベッド Scion をオープンソース公開
(googlecloudplatform.github.io)- コンテナ内で同時実行される LLM ベースのエージェントを、ローカルマシンからリモートクラスタまでまたいで管理するよう設計された実験的プラットフォーム
- 各エージェントは 独立したアイデンティティ、認証情報、ワークスペース を持つ隔離プロセスとして動作し、コーディング・監査・テストなど多様な目標を動的かつ並列に推進
- 「エージェントのためのハイパーバイザー」 と定義され、行動ルールをコンテキストに注入する代わりに、コンテナ・git ワークツリー・ネットワークポリシーで外部から隔離する思想を採用
- Gemini CLI、Claude Code、OpenCode、Codex など主要エージェントを ハーネス(harness) アダプタとして統合し、Docker・Podman・Apple Container・Kubernetes をランタイムとしてサポート
- エージェントのライフサイクル(Phase)、現在の行動(Activity)、詳細状態(Detail)を 3次元状態モデル で追跡し、協調シナリオをデモゲームのコードベースで実演
Scion とは?
- コンテナで同時実行される LLM ベースのエージェント群 を、ローカルマシン、リモート VM、Kubernetes クラスタ全体で管理する実験的オーケストレーション用テストベッド
- エージェントごとに独立したアイデンティティ・認証情報・ワークスペースを付与し、リサーチ・コーディング・監査・テストなど異なる目標を 動的に進化する並列タスクグラフ として実行
- Google は Scion を 「エージェントのためのハイパーバイザー」 と定義し、エージェントメモリ・チャットルーム・タスク管理を独立した(orthogonal)関心事として統合
中核設計思想: 制約より隔離
- エージェントの行動をルールで制限する代わりに、コンテナ・git ワークツリー・ネットワークポリシー のようなインフラレベルの境界で安全性を確保
- エージェントは
--yoloモードで自由に実行される一方、隔離レイヤー が外部からガードレールを担う - この方式により、エージェントのコンテキストに複雑なルールを注入する必要がなくなり、エージェントは自身のタスクのみに集中可能
中核概念 (用語集)
Scion は独自の用語体系を使うため、以下の概念を先に理解する必要がある
- Agent: LLM + Harness ループを実行する隔離プロセス。Scion の基本実行単位であり、独立したアイデンティティ・認証情報・ワークスペースを保有
- Grove: エージェントが存在するプロジェクトワークスペース。ファイルシステムの
.scionディレクトリに対応し、git リポジトリのルートまたはユーザーホームフォルダに配置可能- git ベースの Grove は UUID v5 (リポジトリ URL から決定論的に生成)、Hub ネイティブ Grove は UUID v4 を使用
- Hub: ホスト型 Scion アーキテクチャの 中央コントロールプレーン。ユーザー・Grove・ランタイムブローカー間の状態を調整する「頭脳」の役割
- OAuth ベースのアイデンティティ・認証管理、エージェント/Grove/テンプレート状態の中央 DB 保存、ライフサイクルコマンドのディスパッチ、Web Dashboard を通じた協業ビューを提供
- Profile: 特定のランタイムと Harness 設定を束ねて定義する 実行環境仕様。「Local Docker」「Production Kubernetes」など、環境間の切り替え時にテンプレートを修正せず Profile だけを差し替え可能
- Harness: Gemini CLI・Claude Code・Codex など特定の LLM ツールを Scion エコシステムに統合する アダプタ。
start,stop,attach,resumeのような汎用 Scion コマンドが、どのエージェントでも一貫して動作するよう処理 - Template: エージェント生成の青写真。基本設定・システムプロンプト・ツールを定義し、
.scion/templates/に保存- 標準提供テンプレート(
gemini,claude,opencode,codex)に加え、「セキュリティ監査者」「React エキスパート」のような カスタム役割テンプレート も作成可能
- 標準提供テンプレート(
- Runtime: エージェントコンテナを実行するインフラレイヤー。Docker・Podman・Apple Container・Kubernetes をサポート
- Runtime Broker: Hub に登録して実行容量を提供するコンピューティングノード(サーバー・ラップトップ・K8s クラスタ)。エージェントのライフサイクル管理、ワークスペース同期、ログストリーミングを担当
アーキテクチャ: Manager-Worker 構造
- scion CLI: ホスト側でエージェントのライフサイクルをオーケストレーションするツール。Grove(プロジェクトワークスペース)管理とテンプレート管理(
scion templates)を提供 - Agents: Docker などの隔離ランタイムコンテナ内で Gemini CLI・Claude Code・Codex などのエージェントソフトウェアを実行
- 基本的な利用フロー:
scion init— プロジェクトルートで.scionディレクトリを作成scion start <agent-name> "<task>"— エージェントを起動scion attach <agent-name>— エージェントセッションにインタラクティブ接続、またはscion logsで出力を確認scion resume <agent-name>— 中断されたエージェントを状態を保持したまま再起動
ワークスペース戦略: git 隔離方式
エージェントごとに独立した git ワークスペースを付与する方式は 2 つに分かれる
- ローカルモード — Git Worktrees: Hub なしで実行する場合に使用
../.scion_worktrees/<grove>/<agent>パスに専用ブランチを持つワークツリーを作成- コンテナ内部の
/workspaceにマウントされ、同一リポジトリ履歴を共有しつつ独立した作業ディレクトリを持つ - 作業完了後に
git merge <agent-branch>で手動マージ
- Hub モード — Git Init + Fetch: Hub 利用時に適用
- ブローカーが
SCION_GIT_CLONE_URL,SCION_GIT_BRANCH,GITHUB_TOKENをコンテナに注入 - コンテナ内部で
sciontool initがワークスペースを初期化し、HTTPS でリポジトリを fetch した後scion/<agent-name>ブランチをチェックアウト - ホストの SSH 認証情報は不要で、
GITHUB_TOKENが必要 - すべてのブローカーマシンでリポジトリのローカル存在有無に関係なく 一貫した動作 を保証
- ブローカーが
リソース隔離メカニズム
- ファイルシステム: エージェントごとの専用ホームディレクトリをコンテナにマウント
- Shadow Mounts (tmpfs):
.scion設定データや他エージェントのワークスペースにアクセスできないよう、tmpfs シャドウマウント で遮断 - 認証情報:
gcloud認証などの機密認証情報は読み取り専用マウントまたは環境変数注入により、そのエージェントにのみ限定して公開 - Grove データの外部化: non-git Grove データとエージェントのホームディレクトリを外部化し、エージェントがワークスペース内で他エージェントのデータを走査(traverse)できないようにする
エージェント状態モデル (3次元)
エージェント状態を 3 つの次元で追跡し、インフライベントとエージェントの認知状態を区別
- Phase (ライフサイクル段階):
created→provisioning→cloning→starting→running→stopping→stopped(またはerror) - Activity (running 中のエージェント行動):
idle,thinking,executing,waiting_for_input,blocked,completed,limits_exceeded,offlinecompleted,blocked,limits_exceededは 「sticky」 状態で、エージェントが明示的に再起動または停止されるまで維持blockedはエージェント自身が設定し、下位エージェントの完了待ちであることを示し、システムが エラーと誤認するのを防止offlineはエージェントのハートビートが一定時間検出されないと発生し、認証トークン更新失敗が原因の可能性がある
- Detail: 現在の Activity に関する追加コンテキスト (ツール名、メッセージ、タスク要約など自由形式)
プラグインシステム
hashicorp/go-pluginベースのプラグインアーキテクチャでシステム拡張が可能で、gRPC 通信を使用- メッセージブローカープラグイン: エージェント通知および構造化メッセージングのためのカスタムメッセージ配信バックエンドを提供
- エージェントハーネスプラグイン: コアコードベースを修正せず、新しい LLM ツールを Scion に統合するカスタムハーネスを実装可能
- 現在は 初期段階(foundational stage) にあり、両プラグインタイプともリファレンス実装を提供
1件のコメント
Hacker Newsのコメント
今回は Scion をぜひ使ってみたい
以前、同じ系統の Gastown を使ったことがあるが、結果は良かったもののばらつきが大きかった
Gastownへの主な不満は、(1) 高価、(2) Claudeモデルのみを強制使用、(3) 内部データベースのバックアップやリモート接続が難しい、(4) アップグレード時にしばしば コンテキスト喪失 が発生すること
それでも市場の他のツールより、会話と協業において「魔法のような」結果を出してくれる
Googleのアプローチは興味深い
私は Optio という Agent Orchestrationプラットフォーム を作ったが、Notion、Github Issues、Jira、Linearのようなチケットシステムと統合し、コードエージェントがPRのマージまで進められるよう設計した
Scionの 長時間実行エージェント と コンテナ間通信 のサポートが印象的だ
ただ、私はk8s上に構築したので、Scionは独自の control plane の再実装 を試みているように見え、少し懐疑的でもある
「制約より隔離」という哲学は正しい方向に思える
コンテナは境界を提供するが、内部で何が実行されているかは見えない
Scionがどれだけ多くの 実行コンテキスト を公開するのか気になる。そうでなければ、LiteLLM攻撃のように、実行後になって初めて被害が分かる状況が起こりうる
複数段階の状態と telemetry があります
基本的にはhookシステムがデータを収集し、OpenTelemetryをサポートしている場合はそれを クラウドコレクター に送ります
一部のアクティビティはエージェントが自己報告し、その情報は control plane に反映されます
コードがドキュメントの奥深くに埋もれていた
GitHubリポジトリ を探さなければならなかった
方向性はGastownと似ているが、いくつかの中核機能が欠けているようだ
特に formula機能 はゲームチェンジャーだった
欠けている機能は意図的な設計です。ScionはGastownの言う「gascity」により近い — ユーザーがオーケストレーションのキャラクターと定義を自分で持ち込む構造です
この例 を見ると、単純な Markdownベースのオーケストレーション です
Scionは ゲームエンジン の役割を果たし、GastownをScion上へ移植する作業が進んでいます
プロジェクトはまだ 初期の実験段階 なので不安がある
ローカルモードは安定しているが、Hubベースのワークフローは80%ほど検証済み、Kubernetesランタイムは荒削りだという
だから今はGastownのほうがより良い選択かもしれない
タイトルを見て別の SCION（インターネットアーキテクチャ） を思い浮かべた
Wikipediaの記事 参照
エージェントをもっと試してみたいが、会社が Claude Code にしか課金してくれない
しかもTOS上、他の用途でAPIを使ってはいけない
同じような状況の人はいる？ トークンベース課金もすぐ高くつく
本当にすごい！ 私も最近似たものを作ってみた
Parallax をいじってみて、関連内容を ブログ にまとめた