シリーズ: AI とともにコードを学ぶ

6つのMCPツールと、アダプタが次に解放するもの(現在は17個)

6つのMCPツールから17個へ、統治の仕方は変わらないまま。

6つのツールが契約だ stdioトランスポート、デフォルト拒否、完全な監査ログ raku.* MCPサーバー load_world_model ingest_frame set_render_target get_scene_state start_simulation get_metrics エンジンが権限を持ち続ける。モデルは意図を提供する。
MCPを話せるどんなモデルでも、1つのベンダー非依存の境界を通じてランタイムを駆動できる。

MCPを話せるどんなモデルでも、ベンダーごとのカスタム統合なしにランタイムを駆動できる。RakuAIの6ツール契約は、決定論的権限を持つランタイムを現実のものにする境界であり、それが他者が構築するインフラへと変わる転換点だ。

ランタイムは3月末からModel Context Protocolを話している。出荷されたコミットは138b538b、「feat(mcp): reframe MCP server from game-agent control to world model runtime orchestration」だ。そのコミットメッセージにあるフレーミングの変化こそがこの投稿の本質であり、そこからの次の一手こそ書き留めておきたいことだ。

今日のランタイムにおけるMCPの姿

6つのツール、src/mcp/raku_mcp_server.pyにあるPythonサーバー、stdio経由のトランスポート、名前空間raku.*。呼び出し元ごと、ツールごとに強制されるデフォルト拒否のパーミッション。すべての呼び出しは監査ログに記録される。

6つのツールとは。

  1. load_world_model(adapter_name, config) はワールドモデルのバックエンドを登録する。今日のところ、アダプタ名はプレースホルダーだ。VideoPredictor-v2NeuralRadianceFieldPhysicsFoundation。明日には本物のアダプタになる。
  2. ingest_frame(adapter_name, frame_data, frame_index, timestamp) は生成モデルからのフレームをランタイムのシーングラフに渡す。
  3. get_scene_state(include_physics, include_transforms) はワールドの読み取り専用スナップショットだ。どのモードでも安全。
  4. set_render_target(target_type, config) はワールドがどこにレンダリングされるかを設定する。WebGL、VRヘッドセット、ネイティブウィンドウ、オフスクリーン。
  5. start_simulation(tick_rate, max_duration, realtime) はシミュレーションループを開始する。サンドボックスと開発環境のみ。本番サーバーはこの呼び出しを拒否する。
  6. get_metrics() はパフォーマンスのスナップショットを返す。FPS、フレーム時間、ノード数、アダプタの負荷、稼働時間。どのモードでも安全。

読み取り専用のツールはあらゆる環境で動作する。変更系のツール(load、ingest、set、start)はサンドボックスと開発環境でのみ動作する。本番環境の姿勢は「外部エージェントは尋ねることはできるが、命令することはできない」だ。この姿勢は呼び出し元ではなくサーバー側で強制される。振る舞いの悪いパートナーが誤って本番のワールドモデルを変更してしまうことはない。

なぜこの6つで、他のものではないのか

3月以前のMCPサーバーの初期バージョンは、ゲームエージェント向けのツールを公開していた。move_npcset_dialogplace_objectquery_inventory。これらは境界にとって間違ったツールだ。それらはエンジンレベルの関心事ではなく、アプリケーションレベルの関心事だ。それらは、エンジンをエージェントが手を突っ込む対象にしてしまう。エンジンは本来、エージェントがその上で動く土台であるべきだ。

PR #1311でのこのリフレーミングは、ツール表面を入れ替えた。新しいツールはワールドモデルの抽象概念に対して動作する。バックエンドを読み込む、フレームを押し込む、状態を問い合わせる、レンダリングを設定する、シミュレーションを開始する、メトリクスを読む。NPCを動かしたいエージェントは、エンジンのmove_npcを呼び出すのではなく、ワールドモデルアダプタを通じてフレームを押し込むことでそれを行う。エンジンは物理演算、衝突判定、スコアリング、マルチプレイヤーの状態について権限を持ち続ける。ワールドモデルは寄与者であって、支配者ではない。

その区別こそが、エンジンが反対側にどのワールドモデルがいるかについて不可知論的でいられるようにするものだ。Genie、Runway、シャットダウン前のSora、独自の社内モデル、物理演算のファウンデーションモデル、実験的なニューラルラディアンスフィールドレンダラー。それらすべてが同じ6ツールの表面を話す。それらのどれも、シミュレーションの中で実際に何が起きているかについてのエンジンの権限を上書きすることはできない。

これが「決定論的権限ランタイム」という言葉が実際に意味することだ。私たちはパートナーとの会話でこのフレーズをよく使う。MCPの表面こそが、それを真実にするものだ。

今日と次に来るものの間のギャップ

MCPが今どこに立っているかの正直な姿はこうだ。サーバーは本物であり、セキュリティ層は堅牢であり、スキーマは型付けされており、監査ログは機能しており、そしてアダプタはスタブである。

その最後の一語こそが、この土曜日の重みだ。6つのツールはadapter_nameという文字列を受け付ける。スタブのアダプタ(VideoPredictor-v2NeuralRadianceFieldPhysicsFoundation)は、ディスパッチ経路を証明するプレースホルダーだ。src/environment/にはVeoEnvironmentAdapterRunwayEnvironmentAdapterのための骨組みファイルがあるが、まだ本物のモデルには配線されていない。

次の一手は、反対側に本物のパートナーモデルを据えた、エンドツーエンドの1つのアダプタだ。GDCでの会話で何度も出てきた候補は、ingest_frameを通じてシーンフレームデータを送り込むビデオ予測器(Runway、あるいはより小さいオープンモデル)で、その間エンジンが下で物理と衝突を扱う、というものだ。ビジュアルが生成モデルから出てきて、ゲームプレイがエンジンから出てくるデモ。どちらの側もMCP境界を通じてしか相手のことを知らなくてよい。

そのデモがうまくいけば、他のすべてのアダプタは決まった形になる。難しい部分は統合ではない。難しい部分は契約だ。契約とは6つのツールのことだ。

これがパートナーにとって何を意味するか

具体的な2つのこと、どちらも声に出して言う価値がある。

MCPを話せるどんなエージェントでもランタイムを駆動できる。 自分たちの生成物を本物のエンジンに対してテストしたいモデルラボは、カスタム統合を必要としない。彼らはMCPクライアントを書き、自分たちのバックエンドでload_world_modelを呼び出し、ingest_frameでフレームを押し込み、get_scene_stateでシーン状態を読む。あとはエンジンがやってくれる。パートナーは自分たちのモデルのための本物の評価表面を手に入れる。私たちは、エンジンがベンダー非依存であることの本物の実証を手に入れる。

ランタイムの上にツールを構築するどんな開発者も同じ表面を使える。 MCPサーバーはパートナー専用のAPIではない。それがAPIそのものだ。オーサリングツールを構築するスタジオ、バッチ評価を実行する研究者、新しいセンサーを統合するハードウェアパートナー、そのすべてが同じ6つのツールを手に入れる。公開されているAPIの背後に隠れた別の「内部」APIは存在しない。あるのはMCP表面と、SDKが使うC APIだけであり、それがランタイムの公開面のすべてだ。

まだやるべき堅牢化

書き留めて、確実に片付けたい3つの作業。

本番デプロイのハーネス。 MCPサーバーは今日、テスト内でインスタンス化されている。それにはサービステンプレートが必要だ。モード・認証トークン・レート制限のための環境変数設定、ヘルスチェックエンドポイント、優雅なシャットダウン、コンテナパッケージング。標準的な運用衛生だ。華やかではない。それは、動くサーバーをデプロイ可能なサーバーに変えるものだ。

マルチプロバイダのフォールバック。 プライマリのアダプタが遅いか利用不可のとき、サーバーはセカンダリにルーティングできるべきだ。この戦略についてはしばらく戦略文書で語られてきた。実装はまだ着地していない。形はシンプルだ。テストこそが本当の仕事になるだろう。

アダプタ・バウンティプログラム。 一つのアダプタがエンドツーエンドで動作し、契約が証明されたら、正しい一手はそのアダプタ契約を公開し、エコシステムにもっと多くのアダプタを書くよう招待することだ。Genieを知る誰かによるGenieアダプタ。Marbleを知る誰かによるMarbleアダプタ。研究グループによるカスタムモデルアダプタ。私たちの仕事は「すべてのモデルを統合する」ことではなく、「契約を公開し、実装をレビューする」ことになる。

その最後の一手こそ、私が最も楽しみにしているものだ。それは、MCPが自分たち専用に作ったツールであることをやめ、他の人々がその上に構築するインフラになる転換点だ。

この先の1週間

この土曜日の朝に私が起票しているキューには、最初の本物のアダプタが含まれている。具体的に絞り込まれたスコープ、狭いターゲット、うまくいけば今月末までに動くデモ。うまくいかなければ、契約について何を見誤ったかを、まだ安く変更できるうちに学べる。

もしあなたがモデルラボにいて、生成モデルと話すランタイムのためのMCPスタイルの境界がどうあるべきかについて意見があるなら、今週こそそれを共有する好機だ。契約はまだ確定していない。今のコメントは、四半期後のコメントよりコストが低い。

6つのツール、デプロイ済み、監査済み、スキーマ型付け済み、デフォルト拒否。次はアダプタだ。この境界は本物だ。その上で動く仕事は、この後にやってくる。

土曜日、動き続ける。

1つのMCP契約を通じて本物のエンジンを駆動する

あなたのモデルがModel Context Protocolを話せるなら、本番の空間ランタイムをオーケストレーションできる——ベンダー非依存、デフォルト拒否、すべての呼び出しが監査される。この契約は、まだ安く形作れるうちはコメントを受け付けている。

← すべての記事