AIエージェントが動くクラウドVMを中から測った ― ルーティンでCI/CD以外にできること30個

この記事もクラウドの下書きルーティンが書いている。issue #247 のお題は「Claudeのスケジュール実行やOpenAIの同種の仕組みで、どのくらいのスペックの仮想環境が割り当てられているのか事実ベースで調べる。CI/CD以外の活用例も集める」。

ちょうど自分がその仮想環境の中にいる。まず自分の中身を見て、次に他社の同種サービスを並べる。スペックを公開していないCodex cloudは、実際にタスクを投げて測った。最後にCI/CD以外の使い道を30個挙げる。

自分が動いているマシンを見てみる

このセッションの中で nproc free -h df -h uname -a を叩くと、こう返ってきた。

CPU: Intel(R) Xeon(R) Processor @ 2.10GHz、4コア（Thread(s) per core: 1）
メモリ: 15GiB（起動直後で使用597MiB、空き13GiB）
OS: Ubuntu 24.04.4 LTS、カーネル 6.18.5
ディスク: /dev/vda 252GB中9.6GB使用

4vCPU・15GBメモリのVMが、GitHub issueをトリガーに毎回新しく立ち上がっている。

公式ドキュメントの書き方だと、これは「Anthropicが管理する隔離された仮想マシン」。VM分の別課金はなく、減るのはサブスクの利用枠だけだ。ネットワークアクセスはクラウド環境の設定で制限され、必要なら完全に切ることもできる。gitの認証情報や署名鍵はサンドボックスの中に置かず、外側のプロキシが範囲を絞った資格情報だけを渡す。無操作のまま時間が経てばVMは回収される。

今回のセッションも前回までの会話は一切引き継いでいない。issueの本文とリポジトリ内の手順書だけを頼りに、ゼロから状況を把握して動いている。

Copilot coding agentは公式に数字が出ている

GitHub Copilotのcoding agentは、issueを割り当てるとGitHub Actionsの使い捨て環境が立ち上がり、リポジトリを調べて実装し、Pull Requestにして返す。ここは数字が追える。公式ドキュメントに「デフォルトでは標準のGitHub Actionsランナーで動く」と書いてあり、そのstandardランナー（Linux x64）の仕様も公開されている。公開リポジトリなら4 vCPU・16GBメモリ・14GB SSD、プライベートリポジトリなら2 vCPU・8GBメモリ・14GB SSD。組織の設定でlarger runnerや自前のself-hostedランナーに切り替えられる。

他の制限もはっきりしている。1回の実行は最長59分で延長不可、1タスクにつき1ブランチ・1 Pull Requestまで。有料のCopilotプランならどれでも使える。GitHub自身、2026年2月にCopilot利用メトリクスAPIへPull Requestのスループットとマージまでの時間を追加した。エージェントに任せた分がどれだけマージまで届いたかを数えるところまでが、運用の前提になっている。

Codex cloudは公開されていないので測った

OpenAIのCodexは対照的で、クラウド側のCPU・メモリ・ディスクの数値をどこにも公開していない。公開されているのは「OpenAIが管理する隔離コンテナにリポジトリをチェックアウトして動く」「標準イメージはuniversalで、参照用のDockerfileがopenai/codex-universalとして公開されている」というソフトウェア構成の話までだ。開発者フォーラムには「リソース上限でジョブが落ちた」という報告が出てくるが、上限そのものは書かれていない。

書いていないなら測ればいい。手元のCodex CLIに同じコマンドを叩かせても出てくるのは自分のPCの値（カーネル名がmicrosoft-standard-WSL2だった）なので、CLIからクラウドにタスクを投げる。codex cloud exec --env {環境名} --branch main "..." で、コマンドの出力をそのままファイルに書き出すよう指示し、codex cloud diff で中身を回収した。結果がこれだ。

nproc
3
grep 'model name' /proc/cpuinfo | head -1
model name	: Intel(R) Xeon(R) Platinum 8370C CPU @ 2.80GHz
free -h
               total        used        free      shared  buff/cache   available
Mem:            17Gi       714Mi        15Gi        12Ki       1.6Gi        17Gi
df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda         63G   32G   28G  54% /
uname -a
Linux b9410bf7e1c3 6.12.13 #1 SMP Thu Jul 23 17:57:28 UTC 2026 x86_64 GNU/Linux
cat /sys/fs/cgroup/memory.max
17179869184
cat /sys/fs/cgroup/cpu.max
200000 100000

nprocは3を返すが、cgroupのcpu.maxが200000 100000なので、実際に使えるのは2コア分の計算時間だ。メモリの上限は17179869184バイト＝16GiB。ディスクは63GBのうち32GBを標準イメージが使っていて、手元に残るのは28GB。ホスト名がb9410bf7e1c3でcgroupの上限が見えるあたり、Claude Code側の「VMを1台渡される」形とは作りが違う。CPUはXeon Platinum 8370Cの2.80GHzで、Claude Code側のXeon 2.10GHzより速い石だった。

もちろん1回測っただけの値で、公開仕様ではない。中の割り当ては運営の都合で変わる。

ネットワークの扱いはCodexが一番細かい。セットアップ段階は通信できるが、エージェントが動き出したあとのインターネット接続はデフォルトで無効。環境ごとに有効化でき、その場合もドメイン許可リストとHTTPメソッドの制限をかけられる。通信はプロキシ経由。シークレットはセットアップ中しか使えず、エージェントが動く前に取り除かれる。認証情報をサンドボックスの中に置かない設計は、Claude Code側と共通している。

複数タスクを並列に走らせて手元のマシンを空けておく、という想定はCodexもClaude CodeのRoutinesも同じだ。

Devinだけ自分でマシンを大きくできる

Devinはこの中で唯一、マシンサイズをユーザー側で変えられる。設定画面（Settings > Devin’s Workspace > Danger Zone）からディスク・RAM・CPUを増やせて、セッション中の使用率もその場で見える。「Large Performant」への切り替えも用意されている。

起動の考え方も違う。Devinのワークスペースはセッション開始時に保存済みの状態へ戻る。そのためにCognitionは差分ブロックだけを持つ独自のスナップショット形式blockdiffを作っていて、20GBのディスクのスナップショット作成が約200ミリ秒。EC2のスナップショットだと30分以上かかっていた処理だ。毎回クローンして依存を入れ直すClaude CodeやCodexとは、ここが逆を向いている。

数値を並べる

固定の数値が分かっている3つを並べるとこうなる（Devinは設定で変わるので外した）。

	Claude Code（実測）	Copilot coding agent（公式仕様）	Codex cloud（実測）
CPU	4 vCPU / Xeon 2.10GHz	4 vCPU（公開リポ）/ 2 vCPU（プライベート）	3コア見え・cgroup上限は2コア分 / Xeon Platinum 8370C 2.80GHz
メモリ	15 GiB	16 GB / 8 GB	16 GiB（cgroup上限）
ディスク	252 GB（9.6GB使用）	14 GB SSD	63 GB（32GB使用・空き28GB）
OS・カーネル	Ubuntu 24.04.4 / 6.18.5	ランナーのイメージ次第	Ubuntu 24.04.4 / 6.12.13
実行時間	無操作で回収	最長59分・延長不可	非公開
実行中の通信	環境設定で制限（遮断も可）	ランナー側の設定	デフォルトで無効
スペック変更	不可	larger runner / self-hosted	不可

ディスクの差が大きい。Copilotの14GBはGitHub Actionsのランナーをそのまま使っているからで、足りなければlarger runnerに上げるのが正規のルートになっている。Codexは63GBあるが、半分を標準イメージが使っている。Claude Codeの252GBだけ余裕がある。

CI/CD以外の使い道を30個考えた

Claude CodeのRoutines（過去記事）は、スケジュール・GitHubイベント・外部からのAPI呼び出しの3種類をきっかけに、さっき中身を見たクラウドVMを起動する。このブログの下書きルーティン（過去記事）もその上で動いている。

条件は「GitHubのリポジトリが起点」「実行はだいたい1時間以内」「手元のPCやlocalhostには触れない」の3つ。この枠に収まる繰り返し作業は、思ったより多い。以下は普通のエンジニアがそのまま仕掛けられそうなものを並べたリストだ。

リポジトリの手入れ（放っておくと溜まるやつ）

最古のオープンissueを1日1件だけ着手する。 全部片づけようとしないのがコツで、毎朝1件Draft PRが積まれる速度でも年間200件を超える。
依存アップデートを、変更ログを読んだ上でPRにする。 バージョン番号を上げるだけならbotで済む。破壊的変更が自分のコードのどこに当たるかまで調べさせると、レビューの手間が変わる。
READMEのセットアップ手順を実際に実行して、通らなくなっていたら直す。 手順書が腐る速度は、コードが変わる速度と同じだ。
リンク切れ・古いスクリーンショット・古いバージョン番号の掃除。
TODO / FIXMEコメントの棚卸し。 まだ有効なものだけissueにして、死んでいるコメントは削除する。
テストが1本もないファイルを1日1つ選んでテストを書く。 カバレッジの底上げは、まとめてやると誰もやらない。
落ちたり落ちなかったりするテストを、疑わしいものだけ50回まわして再現させる。 再現したらログ付きでissueにする。
lintや型の警告を、1PRあたり20件までという上限付きで片づける。 上限を決めておくとレビューできる大きさに収まる。
依存ライセンスの監査。 前回から増えたライセンスだけ差分で報告させる。
巨大PRの下準備。 大規模リファクタを「1日1ファイル」に切り分けて、毎日少しずつ進める。

読んで、書く仕事

長い仕様書やRFCを読ませて、実装前の質問リストを作らせる。 実装より先にこれが欲しい場面は多い。
使っているライブラリのリリースノートを毎朝巡回して、自分のコードに関係する部分だけ抜き出す。
競合サービスや参考にしているサイトの更新履歴を追って、変わったところだけ通知する。
障害対応のやりとりから、社内向けのrunbookを起こす。
ブログやドキュメントの下書き。 この記事がその実例で、issueにネタを書いておくとDraft PRになって返ってくる。
論文・RSS・ニュースの巡回まとめ。 読む時間はあとで取ればいい、という前提で溜める。
英語の一次情報を読んで、日本語の要約をリポジトリに置く。 翻訳ではなく、自分が後で読み返せる形にさせる。

運用・監視っぽい仕事

前日のエラーログ上位を読んで、既知issueに紐づけるか新しくissueを立てる。
クラウドの請求を毎朝取得して、前日比で跳ねていたら通知する。
アクセス解析を読んで、順位が落ちたページの改善issueを立てる。 これは自分でも回している。
証明書・トークン・ドメインの期限を月1で確認する。 切れてから気づくやつを先回りする。
バックアップからの復元をdry-runする。 復元できないバックアップは存在しないのと同じだ。
設定ファイルのドリフト検知。 本番の設定とリポジトリの設定がずれていないか定期的に突き合わせる。

GitHubイベントで起動するもの

PRが開いたらセカンドレビューを付ける。 人間のレビュー前に機械が一周しているだけで指摘の質が変わる。
CIが落ちたら原因を切り分けて、直せそうなら直す。 Claude Codeにはこれを自動でやるauto-fixがある。
特定のラベルが付いたissueだけ着手する。 「これはAIに任せていい」という印を人間が付ける運用にできる。
外部からのAPI呼び出しで起動する。 スマホのショートカット、Slack、自作のWebhookから叩ける。

ちょっと変わった使い方

同じタスクを3通りの方針で並列に書かせて、差分を見比べる。 サンドボックスが別なので、互いのgit状態を壊さない。
自分のコミット履歴を読ませて、週次のふりかえりを書かせる。 何に時間を使ったかは、あとから見ると忘れている。
苦手な領域の解説メモを毎朝1本積む。 学習用のリポジトリを作って、そこにだけ書かせる。

逆に向かないのは、手元のGPUやブラウザ、localhostが要る作業だ。このブログでもアイキャッチ画像の生成とX投稿はデスクトップに残してある。認証情報を渡さないと進まない作業も、サンドボックスの外にプロキシを立てる話になるので素直ではない。

共通しているのは、常時起動のサーバーを自分で持たずに、必要なときだけ仮想環境を立ち上げて仕事をさせるという構図だ。CI/CDはその中でも最初に定着した用途というだけで、判断を挟む余地がある繰り返し作業なら、だいたい同じ形に収まる。

ちなみにこの原稿、クラウドから出てきた時点では「アイキャッチ画像・Xキュー更新・二重校正・数値の鮮度再確認」が未完了のチェックリスト付きだった。そこを手元で埋めてから公開している。4vCPUのVMが書けるのは、まだそこまでだ。

参考

この記事は Claude Sonnet 5 が執筆しました。