ハクソク

世界を動かす技術を、日本語で。

Googleが実験的エージェントオーケストレーションテストベッド「Scion」をオープンソース化

33日前原文(infoq.com)

概要

  • Scion は、複数のエージェントを コンテナで分離実行 する実験的なオーケストレーション基盤
  • 各エージェントは 独立したアイデンティティと認証情報 を持ち、 共有ワークスペース で協働
  • Google はScionを「エージェントのハイパーバイザー」と表現
  • 多様なエージェント （Gemini, Claude Code, Codex等）を 同時並行処理 で管理
  • ゲーム「Relics of the Athenaeum」 でScionの機能をデモ

Scion：分散エージェントオーケストレーション基盤

  • Scion は、ローカルやリモートの計算リソース上で 複数のエージェントをコンテナ内で同時実行 するためのテストベッド
  • 開発者は 専門化されたエージェント群 を、 分離されたID・認証情報・共有ワークスペース とともに利用可能
  • 「エージェントのハイパーバイザー」 として、エージェントメモリやチャットルーム、タスク管理などの 各種コンポーネントを統合管理
  • Claude Code、Gemini CLI、Codex などの「ディープエージェント」を、 独立したコンテナ・gitワークツリー・認証情報 で分離運用
  • 各エージェントは プロジェクト内の異なる領域 で作業し、 競合や干渉を防止

Scionの特徴と設計思想

  • ローカル、リモートVM、Kubernetesクラスタ 上でエージェントを柔軟に配置
  • タスクグラフ を管理し、 動的に進化・並列実行 させることで、 コーディング、監査、テスト など多様なゴールを同時追求
  • 固定エージェント群 に依存せず、 長寿命な専門型エージェント と 単発タスク用の短命エージェント を混在運用
  • 分離重視 の安全設計：エージェントの行動をルールで制約するのではなく、 コンテナやワークツリー、インフラのネットワーク制御で外部から制限
  • --yoloモード （自由度高い実行）を推奨しつつ、 外部ガードレール で安全性を確保

対応エージェント・実行環境

  • ハーネス（adapter） を介して、 Gemini, Claude Code, OpenCode, Codex などの人気エージェントを統合管理
  • Codex, OpenCode は現時点で部分サポート
  • Docker, Podman, Apple containers, Kubernetes など多様なコンテナ実行環境に対応
  • プロファイル名 で実行環境を切り替え可能

Scion独自用語

  • grove ：プロジェクト単位
  • hub ：オーケストレーションの中枢コントロールプレーン
  • runtime broker ：hubが稼働するマシン
  • その他、Scion特有の用語体系

デモゲーム「Relics of the Athenaeum」

  • Google はScionの能力を示すため、 エージェント協働型ゲーム 「Relics of the Athenaeum」のコードベースを公開
  • 異なるハーネス上で動作する 複数エージェントが連携し、キャラクターを演じながら計算パズルを解決
  • game runner が新キャラクター/エージェントを生成し、各エージェントがさらにワーカーや専門エージェントを動的生成
  • 共有ワークスペース を通じたデータの読み書き、 ダイレクトメッセージや全体ブロードキャスト による協調

参考リンク

著者： Sergio De Simone

Hackerたちの意見

彼らはコードをドキュメントの奥深くに埋め込んでるみたいだね: https://github.com/GoogleCloudPlatform/scion

└

そうそう、実は3月の終わりにこれにスターを付けたんだけど、まだ戻ってきてなかったんだ。誰かが投稿してくれて嬉しい、すごく興味深いね。

この見出しを見て、別のSCIONを思い出したよ: > https://en.wikipedia.org/wiki/SCION_(Internet_architecture)

これを試すのが楽しみだな。Gastown[1]での体験はポジティブだけどバラつきが大きかったから、同じジャンルのScionがもっと良くなることを願ってる。Gastownの主な不満点は、(1) 高いこと、(2) 自分の設定を試みてもClaudeモデル以外使えないこと、(3) ビーズやdoltバグデータベースのバックアップやリモート追加の方法が分からないからインストールに手を出すのが怖いこと、(4) アップグレードするとよく無駄な手間がかかってコンテキストを失うこと。これらは全部自分のスキルの問題かもしれないけど、ちゃんとマニュアルは読んでるよ。でも、Gastownは結果を出してくれるからすごい。市長とポールキャットたちの対話や調整には魔法のようなものがあって、Claude Codeだけよりもさらに良い体験につながるんだ。 1. https://github.com/gastownhall/gastown/

└

まだ複数のエージェントを同時に扱う作業に飛び込んでいない者として、ガスタウンのようなツールはどこが一番役立つの？

└

Imbueのmngrは見たことある？同じようなエネルギーを感じるし、役立つかもしれないよ。 https://imbue.com/product/mngr/

└

スカイオンは「エージェントのハイパーバイザー」として面白そうだね。Kubernetesの影響を受けていて、エージェント実行のための基盤は便利なプリミティブだ。ガスタウンはエージェントをエコシステムに繋げる点でスカイオンよりも進んでいると思う。私の感覚では、ガスタウンやそれに似たものはスカイオンの上にレイヤーとして構築できるかもしれない。ダン・シャピロはエージェントオーケストレーションにおいて最も重要な2つの能力、同時実行性とループについて私の考えを形作る手助けをしてくれた。現在、スカイオンは同時実行性しか提供していないし、ガスタウンもループよりも同時実行性に重きを置いている。Fabroは、ループと同時実行性の両方をうまく実現しようとしている新しいOSSプロジェクトで、今取り組んでいるところだ。 https://github.com/fabro-sh/fabro （いつかスカイオンの上に構築されるべきかもしれないね。）

└

私も似たようなハーネスを作ったよ。私のはMacでSeatbeltを使った軽量サンドボックスと、LinuxでBubblewrapを使ったもの。最初はDockerも使ってたけど、やめちゃった。これらの2つのサンドボックスのおかげで、プロジェクトフォルダだけは読み書き可能で、他はすべて読み取り専用にできるのが気に入ってる。これで、コードはサンドボックス内でも外と同じように動くし、パスもそのまま。サンドボックス内の.gitフォルダも読み取り専用で、外部のエージェントだけがコミットできる。サンドボックス化は--yoloモードを実現するために意図されていて、自律的な時間を最大化したかった。作業は個々のタスクに分かれている。タスクを実装するためにPlan ModeやTodoWriterツールを使うこともできたけど、今はすべてのエージェントが持ってるからね。でも、私はtask.mdファイルで計画を立てることにした。これなら反復的に編集できるし、ユーザーのリクエストから始まり、チェックボックス付きのステップを持つ計画に発展する。計画はジャッジエージェントによってレビューされて（yoloモードで新しいコンテキストの中で）、その後ワーカーエージェントがゲートを解決する。ゲートは、すぐにテストする、徹底的にテストするというワークフローを強制する。yoloモードでもう一つの実装ジャッジがある。そして最後に、メモリ/bootstrapドキュメントを更新する。タスクファイルはgitリポジトリに入る。ユーザーのメッセージもすべてログに記録して、ジャッジエージェントで意図の検証を行う。ジャッジは「チャット -> タスク -> 計画 -> コード -> テスト」というチェーンに沿って意図を検証する。何も失われず、プロジェクトはその歴史を覚えて理解している。実際、私は過去の作業を振り返るタスクを実行するのが好きで、task.mdが以前のタスクを「食べて」、ローカルでは見えない一般的なプロジェクトの視点を生み出す。私のシステムでは、すべてがmdファイルで、gitでログされてバージョン管理されている。自分の記憶を抽出するのに問題はないし、実際、過去の作業を振り返ることをこのハーネスの基本的な操作にしている。主にコーディングに使っているけど、深い研究や文献レビュー、テーマの整理、トピックに関するチュータリング、投資計画、エージェント実験ループのオーケストレーション（自動研究）にも同じくらい良い。これは、task.mdが単なる汎用プログラミングパイプラインで、ゲートが自然言語の指示だから、あらゆる認知作業に使えるからだ。私が実行した最長のtask.mdは700ステップで、完了するのに数時間かかったけど、信頼性があったよ。 https://github.com/horiacristescu/claude-playbook-plugin

└

結局、決定論的なパスを持つワークフローを追加したんだ。RAW APIコールやCLI、エージェントも使えるようにね。これが大きな差別化ポイントだったと思う。あと、pi-monoも追加して、GeminiやK2.5、GLM-5など、いろんなモデルを使うようになった。問題は、ほとんどの人が一つのプロバイダーに依存したソリューションを作ってることだと思う。コスト・クオリティ・スピードのバランスを改善するための自己学習能力に焦点を当てるべきだよね。参考までに: https://github.com/desplega-ai/agent-swarm

このプロジェクトはまだ初期段階で実験的です。コアコンセプトは決まっていますが、粗い部分があることを期待してください。ローカルモード: 比較的安定 - ハブベースのワークフロー: ~80% 検証済み - Kubernetesランタイム: 初期段階で既知の粗い部分がある。今のところGastownの方が良い選択なのかな？よく分からないけど、「比較的安定」っていうのはあまり良い感じがしない。

└

ガスタウンが他の選択肢よりもいい選択だと思うなんて、想像もつかないよね。

これはGas Townの方向性に向かっているけど、いくつかのコア機能が欠けているみたいだね。フォーミュラを持つことはゲームチェンジャーだった。

└

[ここにスカイオンの主な著者とアーキテクトがいます] 欠けている機能はほとんど意図的なものです。これは、ガスタウンの「ガスシティ」としての計画に近いです。自分のオーケストレーションキャラクターや定義を持ち込んでください。このオーケストレーションの例を見てみてください https://github.com/ptone/scion-athenaeum これはただのマークダウンです。スカイオンはゲームエンジンです（スカイオンで動作するようにガスタウンを移植中です）。

Googleのアプローチを見るのは本当に興味深いね。最近、私のアプローチであるOptioを共有したんだけど、これもエージェントオーケストレーションプラットフォームなんだ: https://news.ycombinator.com/item?id=47520220 私はチケッティングシステム（Notion、Github Issues、Jira、Linear）との統合にもっと焦点を当てて、PRをマージするために特にコーディングエージェントが働くようにしてた。Scionの長時間実行エージェントやコンテナ間通信のサポートは本当に興味深いね。これに基づいていくつか機能を計画しなきゃ。彼らのいくつかのコンセプトはあまり理解できないけど、私はk8sの上に構築することを選んだのに対して、彼らは制御プレーンを再現しようとしているみたい。再現やグローブ/ハブが本当に必要なのか少し懐疑的だけど、初めて実際に見たときにもっと理解できるかもしれない。

制約よりも隔離が正しい哲学のように思える。コンテナは境界を提供するけど、その中で何が動いているかは見えないからね。Scionがどれだけ実行コンテキストを表面化するのか気になる。そうでないと、LiteLLM攻撃のように、何かが動いて被害を与える前に気づかない状況になっちゃう。

└

[scionの主要著者兼アーキテクトです] 状態とテレメトリーにはいくつかの層があるよ。最初はほとんどのハーネスで利用できるフックシステムによって提供される。その後、OpenTelemetryを提供するものは、正規化されて生のまま（両方を保持して）クラウドコレクターに転送される。最後に、一部のアクティビティは、制御プレーンに反映できる組み込みツールセットを使ってエージェントによって「自己報告」される。

これは本当に期待できそうだね。ただ、隔離層としてコンテナを使う選択について気になってる。エージェントを信頼できないものとして扱って完全に隔離するのが目的なら、マイクロVMの方が良い選択肢だと思う。でも、OCIランタイムをサポートしているなら、もしかしたらkataコンテナを使えるかもしれない。仕事の後に調べてみるよ。

おい、Google、君たちのこと大好きなんだけど、いつも中途半端なものをサポートなしでリリースしてる気がする。ADKは（今も）素晴らしいけど、みんながもっと声を上げて推してくれないと。昔のMicrosoft .netみたいな感じだね。これからどうなるか見てみよう。応援してるよ！

見て、実際にGoを使ってるGoogleのプロジェクトだよ。ただ、毎回ソースからコンパイルするのはあんまり魅力的じゃないけど。