メルカリ「Arca」— AI時代の高速プロトタイピング基盤（Platform Engineering Kaigi 2026）¶
作成日: 2026-09-27 出典: 荒井良太（株式会社メルカリ）「メルカリにおけるAI時代の高速プロトタイピング基盤『Arca』」Platform Engineering Kaigi 2026（Speaker Deck 公開 2026-09-26） 関連: aiコーディングエージェント_sandbox隔離と権限運用_他社比較_整理 / エアークローゼット_非エンジニア内製化_sandbox_mcpと議事録rag_整理 / layerx_ai_agent基盤_bedrock_litellm_durable_temporal_整理 / 社内mcp共通基盤_認証認可ログ_整理 / メルカリ_socrates_データ基盤とマルチエージェント_整理
0. 要点（3行）¶
- 一言で: 「エージェント入りの、消えない社内VPS」を URL 1本で配る基盤。PdM・デザイナーが AI で作ったプロトタイプの「これ、どこで動かせばいいですか？」に答える。
- 安全性の核は「外に出る経路を1本に絞り、キーをマシンに置かない」。全送信を Go 製 HTTP プロキシに集約し、TLS 終端＋CEL ルールで検査、API キーはプロキシが後付けする。エージェントが乗っ取られても漏れるキーがマシン内に無い。
- コストは「24h 無通信で自動停止 → Pod 削除・ディスクはスナップショット化」で押さえる（Hyperdisk Balanced → Snapshot で約4割減）。結果、ユニークアクセス 1,029 人・作成者 346 名・マシン 631 台まで広がった。
1. 背景 — なぜ作ったか¶
- AI の発達で、コーディングエージェントに指示すればエンジニア以外でも動くものが作れるようになった（コードを書けることが前提ではなくなった）
- すると次のボトルネックは「どこで動かすか・どう安全に共有するか」になる
- Arca のコンセプト = 「AIエージェント時代の VPS」（exe.dev に着想。exe.dev は永続ディスク・SSH・公開ホスト名付きの Linux VM をエージェント向けに提供するサービス）
| 柱 | 中身 |
|---|---|
| 簡単に | 永続ボリューム付き VPS のような環境。エージェント・社内ツール連携を標準装備 |
| 安全に | 環境にガードレールを組み込み。会社アカウントでのログイン必須 |
| 共有できる | URL を送るだけで共有。複数人で共同開発も可能 |
社内での使われ方（プロトタイピング以外にも拡大）: アイデア検証（新機能・改善案を触れる形に）／社内ダッシュボード（検索・レコメンド指標、ユーザーリサーチ結果）／チームの入口ページ／社内ハッカソン（アイデア募集から成果物公開まで Arca 上で完結）。
2. 全体アーキテクチャ¶
アプリ作成者 ──> Cloud IAP ──> arca.example.com（コンソール / API）──作成──┐
│
アプリ利用者 ──> Cloud IAP ──> <machine>.arca.example.com ──┐ ▼
│ ┌──── GKE ────────────────────────┐
└──>│ マシン(Pod, gVisor) │
│ ├ アプリ │
│ ├ エージェント │
│ ├ arcad（透過プロキシ/リレー） │
│ └ 永続ボリューム /home │
└──────────┬──────────────────────┘
│ 80/443 はすべて CONNECT
▼
Arca HTTP プロキシ / AI プロキシ（コントロールプレーン）
│ 検査・キー付加・予算制御
▼
インターネット / LLM
- 基盤は Google Kubernetes Engine（GKE）。マシン = GKE Sandbox（gVisor）の Pod + 永続ボリューム（
/home） - 入口は2つ（作成者向けコンソール/API、利用者向けマシン URL）とも Cloud IAP で社内認証
- 出口は 1本（HTTP プロキシ / AI プロキシ）。発表では同じ図を「マシンができるまで」「外に出る経路は1本」「URL で届く」の3視点で使い回していた
3. 「簡単に」始められる工夫¶
3-1. プロンプトを送るとエージェント入りマシンが起動¶
起動高速化のための仕込み: - マシン用サービスアカウントを事前作成してプールしておく（SA 作成待ちを消す） - 準備済みディスクイメージから永続ボリュームを作り、gVisor Pod を起動 - プロダクトごとのイメージを用意し、開発環境セットアップ済みの状態で起動
3-2. 「エージェント専用の、消えない1台」¶
- 永続ボリュームがあるので VPS のようにその場でサービスを動かせる。DB・Redis 等のステートフルなコンポーネントもマシン内で気軽に動かせる
- エージェントがすぐ作業を始められるよう事前配置:
AGENTS.mdなどのガイドライン（環境固有の手順を知った状態で開始）- 社内標準の技術スタック（例: Go）とデザインシステムをデフォルト採用
- Linear・GitHub・LiteLLM など社内ツールと連携済み
- 社内共有の Claude Code プラグイン・エージェントスキルをプリインストール
3-3. 手元のエージェントから操作¶
- CLI
arcactlとエージェント用スキルを提供。各自の Claude Code 等から Arca の全操作（マシン作成・共有設定も）がコンソールを開かずにできる
4. 「安全に」使える工夫（本発表の山場）¶
脅威モデル: エージェントは自律的にコマンド実行・外部通信する。指示の解釈違いやプロンプトインジェクションで意図しない操作をしうる。手元 PC や社内認証情報をそのまま渡すと、API キー漏えい・社内データ外部送信の影響範囲が大きい。 → 通信とキーを基盤側で制御し、影響範囲を閉じ込める。
4-1. プロキシの実装（Go）¶
マシン内プロセス(UID=ユーザー別)
│ 80/443
▼ iptables で横取り
arcad リレー ── 通信元プロセスの UID を特定して伝える
│ CONNECT
▼
HTTP プロキシ（コントロールプレーン, Go）
├ 独自 CA で TLS 終端 → パス・ヘッダーまで検査
├ CEL ルールで許可/拒否
└ 認証情報を付加
▼
インターネット
4-2. 許可されていない通信は「403＋案内文」¶
- 許可外エンドポイントには HTTP 403 と、「outbound 先を制限している。追加が必要なら Slack #arca へ」という趣旨の案内メッセージを返す
- エージェントがメッセージを読んで人間に案内できる — エラー文をエージェント向け UI として設計している点がうまい
- ルールは CEL（Common Expression Language） でメソッド・ホスト・パス等を条件に書ける。TLS 終端しているので HTTPS でもパス/ヘッダー単位で判定可能
4-3. キーをマシン内に置かない¶
- 各種 API キーは HTTP プロキシで自動付加（エージェントはキー無しでリクエスト）
- GitHub は リポジトリ単位で read/write を絞ったトークンを付加。さらに git / REST / GraphQL を検査し、社内 Organization 以外への書き込みは拒否
- 個人に紐づくキーを付加するケースは、個人ごとに Linux ユーザーを分け、通信元 UID で特定（共同開発マシンでも誰の権限か区別できる）
4-4. Webhook の受け付け¶
- マシンごとにトークン付きエンドポイントを発行
- マシンは直接応答しない。事前設定したステータスコード/ボディを Arca が代わりに返し、リクエストは非同期でマシンに配送
- → マシン上のアプリに脆弱性があっても外部から悪用されにくい（受信側も「経路1本」）
4-5. Google Cloud 権限¶
- 各マシンはユニークな GCP サービスアカウントを持ち、ユーザーがそこに権限付与できる
- 複数マシンで共有する SA を作り、マシンがその権限を借用（impersonate）できる → プロダクトごとに必要権限を事前に揃えておける
5. 「共有できる」工夫¶
- 既定は非公開。Google Drive のように権限付与して URL を送るだけ
- URL はマシン内の特定ポートへ自動プロキシ。認可はコントロールプレーンのプロキシで行う（アプリ側に認証実装が不要）
- プロトタイプのページに直接コメントしてフィードバックでき、作成者に通知が届く
- 社内メンバー管理システムと連携し、個人・チーム単位で共有
| 権限 | できること |
|---|---|
| Viewer | アプリを使う・ページに直接コメント（作成者に通知） |
| Editor | マシンの中に入って変更・エージェントを使って一緒に開発（1マシンを複数人で共同開発） |
6. コストを抑える工夫¶
| 施策 | 仕組み | 効果 |
|---|---|---|
| 自動停止 | CPU はオーバーコミット、メモリは保証。24h トラフィックが無いマシンは停止 → Pod 削除、/home（PV）は永続化し次回復元。停止中 URL にアクセスするとその画面から起動 |
常時確保リソースの解放 |
| ビンパッキング | 起動しっぱなしだと Pod 配置が断片化 → 自動停止を機に再配置。マシン用に MostAllocated strategy の kube-scheduler を別途デプロイ | 少ないノードに詰める |
| 自動スナップショット | 停止時に永続ボリュームを Hyperdisk Balanced → Snapshot（Standard）へ移行 | 約4割のコスト減 |
| ゾーン跨ぎ起動 | ディスクはゾーンに紐づくが、スナップショットからは任意ゾーンで復元できる | ノード有効活用・特定ゾーンのリソース枯渇に対応 |
| LLM 予算 | エージェントは LiteLLM 経由で LLM を呼ぶ。マシンごとに予算設定。超過時はエラーレスポンスに予算申請の案内を入れる | エージェントを自由に走らせてもコスト上限を管理 |
7. 利用状況と基盤の外でやったこと¶
- ユニークアクセス 1,029 人 / Arca でアプリを作った人 346 名 / マシン 631 台（発表時点）
- 基盤の外:
- 利用者 Slack チャンネルでつまずきに毎日回答（スタートアップのような手厚いサポート・速いレスポンス）
- エージェント自身が案内役になるメッセージを用意（弾かれた通信先・予算超過など）
- 社内ハッカソンで全社的に使ってもらった
- 成果: アイデアを形にして共有するハードルが下がり、職種を問わず浸透、想定外のユースケースにも拡大
8. 考察 — 他社との比較で見えるもの¶
8-1. 比較対象¶
注: 以下は Vault 内の既存ノート同士の突き合わせ。各社一次資料は各ノート作成時に確認したもので、本ノート作成時に再確認はしていない。
| 比較対象 | 何の基盤か | Arca と同じ点 | Arca と違う点 | ノート / 出典 |
|---|---|---|---|---|
| エアークローゼット Sandbox MCP | 非エンジニアが Claude Code で作ったアプリを、ワンコマンドで社内 SSO 付き本番 URL（2〜5分）に公開する基盤 | 非エンジニアの「作った後どこで動かす？」を解く。AI の実装の正しさに依存せず基盤側のゲートで守る | 「公開の出口」側の基盤。Arca は作業環境（消えない VPS）ごと配り、egress・キー・LLM 予算まで握る | エアークローゼット_非エンジニア内製化_sandbox_mcpと議事録rag_整理 / Zenn |
| LayerX AI エージェント基盤 | AWS サーバーレス上で業務エージェント（Bedrock AgentCore / Lambda Durable Functions / Temporal / n8n）を動かす全社基盤 | LiteLLM を LLM ゲートキーパーにし、仮想キー＋ユーザー/プロジェクト別予算上限 | 業務エージェントの実行基盤で、個人のプロトタイプ環境ではない。統制は「顧客データ境界だけ厳格、他は速度優先」 | layerx_ai_agent基盤_bedrock_litellm_durable_temporal_整理 / Speaker Deck |
| Claude Code / OpenAI Codex | コーディングエージェント製品自体の隔離 | deny-by-default / allowlist-first の egress | OS ネイティブ sandbox（Seatbelt / bubblewrap / Landlock+seccomp）で製品が自分を縛る。Arca は会社が外側に gVisor Pod ＋出口プロキシを被せる | aiコーディングエージェント_sandbox隔離と権限運用_他社比較_整理 / Anthropic・Codex |
| Cursor | 同上 | 強い隔離はクラウド側に寄せる | ローカルは檻なし、Cloud Agent は VM | 同上 / Cursor docs |
| GitHub Copilot coding agent | 同上 | 環境ごと隔離（ephemeral な Actions 環境）＋ firewall | 人間が Approve を押すまで CI を走らせないゲートが主軸 | 同上 / GitHub docs |
| Devin（Cognition） | 同上 | 環境レベルで隔離 | VM レベル隔離（自前カーネル）。Arca は gVisor（ユーザー空間カーネル）で VM より軽い | 同上 / Cognition |
Arca 固有に見える点: 上記の中で「API キーをマシン内に置かず、TLS 終端プロキシが後付けする」「GitHub への書き込みを GraphQL レベルで社内 Org に限定する」まで基盤側でやっているのは Arca だけ（既存ノートの範囲では）。
8-2. Arca の設計判断の整理¶
| 観点 | Arca の選択 | 含意 |
|---|---|---|
| 隔離単位 | gVisor Pod ＋ 永続 /home |
使い捨て sandbox でなく「消えない1台」。ステートフルなプロトタイプが作れる |
| 出口制御 | 全通信を1本のプロキシに集約、TLS 終端＋CEL | ネットワーク層でなくアプリ層（パス・GraphQL）で判定できる |
| 秘密情報 | マシンに置かない・プロキシが付加 | プロンプトインジェクションで「持ち出せるキーが無い」。最も効く設計判断 |
| 受信 | Webhook も代理応答＋非同期配送 | 公開面を基盤に寄せ、脆弱なアプリを直接晒さない |
| エラー設計 | 403/予算超過に人間向け案内文 | エージェントが読む前提のエラーメッセージ＝サポートコストの削減策 |
| コスト | 自動停止＋スナップショット＋専用スケジューラ | 「作りっぱなし」が大量発生する非エンジニア利用に効く |
- 独自 CA で TLS 終端する方式はマシン内ツールが CA を信頼する設定が前提になる。証明書ピンニングするクライアントの扱いは発表では触れられていない（未確認）
9. まとめ — 一言で / いつ参考にするか¶
一言で: 「エージェントに自由を与える代わりに、出口とキーと財布を基盤が握る」。
| 状況 | Arca から借りるべきアイデア |
|---|---|
| 非エンジニアに AI コーディング環境を配りたい | 永続 VPS 型＋ AGENTS.md・社内スキルのプリインストール |
| エージェントの秘密情報漏えいが怖い | キーをプロキシで後付け、環境内にキーを置かない |
| 外部送信を細かく制限したい | TLS 終端プロキシ＋ CEL でメソッド/ホスト/パス判定 |
| 作ったアプリを安全に社内共有したい | IAP ＋ コントロールプレーンで認可、Viewer/Editor の2権限 |
| 放置マシンのコストが膨らむ | 24h 無通信で停止、ディスクをスナップショットへ、MostAllocated でビンパッキング |
| LLM コストの上限管理 | LiteLLM でマシン単位予算、超過エラーに申請手順を載せる |
参考リンク¶
- 発表資料: https://speakerdeck.com/ryotarai/niokeru-ai-jidai-no-kousoku-kiban-arca
- exe.dev（着想元）: https://exe.dev/ / https://blog.exe.dev/meet-exe.dev
- GKE Sandbox（gVisor）: https://cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods
- CEL（Common Expression Language）: https://cel.dev/
- kube-scheduler の MostAllocated スコアリング: https://kubernetes.io/docs/concepts/scheduling-eviction/resource-bin-packing/
- LiteLLM: https://docs.litellm.ai/
- 比較: エアークローゼット Sandbox MCP（Zenn）: https://zenn.dev/aircloset/articles/65efe9614f8e73
- 比較: LayerX AI エージェント基盤（AWS Summit Japan 2026）: https://speakerdeck.com/kanny/building-an-ai-agent-platform-at-layerx
- 比較: Anthropic「How we contain Claude」: https://www.anthropic.com/engineering/how-we-contain-claude
- 比較: OpenAI Codex agent approvals & security: https://developers.openai.com/codex/agent-approvals-security
- 関連（未精読）: Build First, Discuss Later: How Prototypes Speed Up Product Decisions（Mercari Engineering）: https://engineering.mercari.com/en/blog/entry/20260615-build-first-discuss-later/
- 関連（未精読）: メルカリが明かす「Claude Code全社展開」「シャドーAI対策」を支える仕組み（@IT）: https://atmarkit.itmedia.co.jp/ait/articles/2608/04/news002.html
作成: 2026-09-27 ／ 最終更新: 2026-09-27