Coder Agent Relayとは、銀行や防衛機関も使えるAI開発の仕組み

gen
gen

@gennnn 28本

サムネイル

Cursorを会社で使わせてもらえない、という声、けっこう聞きます。

Coderには、セキュリティチームがCursorの利用を丸ごと止めた顧客が数十社あるそうです。

2026年9月2日、その構造そのものを組み替える発表が出ました。

銀行や防衛機関のエンジニアは、なぜAIコーディングエージェントを使えなかったのか

止めているのはセキュリティチームで、理由はモデルの性能でも料金でもありません。

Cursor Cloud Agentsは既定だとCursor側が用意したマシンの上で動き、そこにリポジトリが展開されます。

つまりソースコードとシークレットが、自社の外に出る。

銀行や防衛機関や官公庁だと、この時点で社内規程に引っかかって終わりです。

CoderのCEOであるRob Whiteleyさんは、2026年9月2日のプレスリリースでこう言っています。

企業がAIエージェントを拒否したことは一度もない。拒否されたのは導入モデルのほうだ

同じくWhiteleyさんはThe New Stackの取材で、Cursorを止めた数十社について「Cursorに何か問題があるからではなく、単に構造が噛み合っていないだけ」とも話しています。

そこで出てくる数字がわりと衝撃でした。

Coder社内では、エンジニアの1%がトークン支出の40%を占めているそうです。

問題は金額ではなく、使い倒している人とまったく使えていない人の差がそこまで開いていること。

規制の厳しい会社では、この「使えていない側」に社員が丸ごと入ります。

Coder Agent Relayとは、推論をCursorに残して実行だけ自社インフラに戻す仕組みです

先に整理しておくと、推論と実行を分ける発想そのものはCursorが先に出しています。

2026年3月25日に一般提供が始まったセルフホスト版のクラウドエージェントでは、組織が自分の環境にworkerというプロセスを立て、CursorのクラウドへHTTPSでアウトバウンド接続します。

推論とプランニング、つまり「次に何をするか考える部分」はCursorのクラウドで回り続け、ファイル操作やコマンド実行といったツール呼び出しだけがworkerに投げられる。

コードもツール実行もビルド成果物も、自社の環境から出ません。

ただ、そのworkerを立てて運用し続けること自体がインフラの仕事です。

Agent Relayが足しているのは、まさにそこでした。

Coderの説明では、Cursorのクラウドエージェントのセッションと自社のCoderワークスペースの間を仲介し、セッションが生きている間そのワークスペースのライフサイクルを管理する、とあります。

裏側はこうです。

エージェント提供側が「エージェントの作業をどこで実行するか」というcompute poolを設定できるようになっていて、Coderが自分をそのpoolの1つとして登録する。

開発者がセッションを開始するとCursor側からリソース要求が飛んできて、Agent Relayがワークスペースを起動し、テンプレートを適用し、ワークスペース内のデーモンとCursorの外部サービスの間に安全な接続を張ります。

事前ビルドしたワークスペースを使えばウォームスタートします。

これだけ動いていて、開発者が見る画面はアプリもwebもモバイルも今まで通りです。

そして個人的にいちばん効くと思ったのが、ID周りの扱いです。

Agent Relayは受け取ったリクエストを組織のIDプロバイダに突き合わせるので、エージェントのコミットもツール呼び出しもファイルアクセスも、人間の開発者とまったく同じ帰属で記録される。

「誰がやったのか分からないコミット」が発生しません。

Cursor Cloud Agentsのセキュリティは、モデルの拒否ではなく環境の壁で守ります

Coderが挙げている防御は4点あります。

  1. 境界の制御。ワークスペースは顧客のクラウド、VPC、オンプレのどれかで動きます。ネットワーク出口ポリシーはプラットフォームチームが一度決めれば全ワークスペースに一律で効きます
  2. 構造としてのサンドボックス。環境は分離され、使い捨てで、1タスクだけにスコープされます。許可されていないリソースへのアクセスはインフラ層で止まります
  3. ポリシーをインフラとして持つ。承認済みのモデルとデータソースを環境レベルで一度定義すれば、チームごとに設定し直さなくても組織全体に継承されます
  4. 監査ログ。アクセス、実行、変更に加えて、ブロックされた操作まで記録が残ります

本質は2で、この書き方がマジで正しいと思いました。

原文は「モデルの拒否に頼るのではなく、インフラ層でブロックする」という表現をしています。

プロンプトインジェクションを食らってエージェントが妙なコマンドを打とうとしても、そのワークスペースがそもそも外に出られない。

モデルに「それはできません」と言わせる設計は、モデルが言わなかった瞬間に崩れます。

環境の壁は、モデルが何を出力しようが崩れません。

Coderのブログでは、この境界機能をAgent Firewallと呼んでいます。

RBACや監査ログと一緒に自動で適用されるので、エージェント専用のセキュリティモデルを別途組む必要はない、と書かれています。

ローンチパートナーのSpaceXAIは、今年Cursorを買収した親会社でした

ここが今回いちばん面白かったところです。

Agent Relayのローンチパートナーは、Cursorではなく「SpaceXAI」名義で発表されています。

SpaceXAIが何者かというと、xAIです。

2026年2月にSpaceXがxAIを評価額およそ37兆円(2,500億ドル)で取り込み、7月6日にxAIがSpaceXAIへブランド変更しました(Grokの名前はそのまま据え置きです)。

そして6月16日、SpaceXがCursorの運営会社Anysphereを約9兆円(600億ドル)の全株式交換で買収すると発表し、8月14日に完了しました。

CursorはSpaceXAIの傘下に入っています。

資本の並びはSpaceX、SpaceXAI、Anysphere(Cursor)です。

つまり今回のローンチパートナーは、先月買ったばかりの子会社プロダクトについて「実行環境はお客さんのインフラに戻します」と言っている。

SpaceXAIでパートナーシップを統括するToni Adamsさんのコメントがこれです。

Coderは、そうしたチームが完全に管理下に置く環境の中でCursorを動かす道を用意してくれる。開発者が求める体験を保ちながら、必要なセキュリティ管理も維持できる

親会社のクラウドに集約する、ではなく、顧客の壁の内側に戻す。

買った側が自社クラウドへの囲い込みを選ばなかったところに、この設計判断の重さがあると思います。

Coder WorkspacesとCursorの統合は、まだデザインパートナー限定のプレビューです

正直に書くと、今日から試せるものではありません。

Coder Agent Relay for Cursorはデザインパートナーとのプライベートプレビュー段階で、一般提供の日付は出ていません。

案内ページはありますが、入口は営業窓口経由です。

銀行や防衛機関が実際に導入した実績の話ではなく、設計が固まった段階の話だと読んでおくのが正確です。

ただ、業界の反応は速かったです。

9月2日にプレスリリースが出て、翌3日にSD Times、4日にAIwireとThe New Stackが後追いしました。

英語圏の開発者向けメディアが3日で拾っています。

日本語の解説はまだほとんど見当たりません。

銀行の話に見えて、推論と実行の分離は個人開発にも効きます

持ち帰れるものが2点あります。

1: 語彙として持っておく価値があります。

フィンテックや官公庁系の受託や常駐に入ると、セキュリティ要件のヒアリングで「そのエージェントはどこで動くのか」「ネットワークの出口はどう絞っているのか」「監査ログは誰の名前で残るのか」を必ず聞かれます。

Coder Workspaces、ネットワーク出口ポリシー、環境レベルのサンドボックス。

この3語を知っているだけで、その場の会話が通ります。

2: 設計としてそのまま転用できます。

推論はAPIに投げる。

ツール実行は自分のコンテナに閉じ込めて、出口のドメインを絞る。

操作ログは実行者の名前で残す。

個人開発でも同じ形は作れますし、この形にしておくと後から会社で使う話になったときに説明できます。

「AIエージェントが会社で使えない」の原因は、モデルの賢さではなく、どこで動いているのかという配置の問題でした。

次に別のベンダーが同じ構造を出してきたとき、この分離を知っていれば一目で読めます。