月130万ドルで回す
約100体のエージェント
Peter Steinberger 氏の X 投稿では、OpenAI 参加後に クラウド上で常時およそ100体の Codexを動かしていることが説明されています。直近 30 日で約 130 万ドルの API 消費という数字も、同日に投稿された CodexBar スクリーンショットで確認できます。これは「いますぐ真似すべき運用」ではなく、本人の説明では 「トークンコストが問題にならないとしたら、ソフトウェアはどう作られるのか」を探る実験です。
01.結論：月130万ドル・約100体のエージェントが示すもの
Peter Steinberger 氏（GitHub ID: steipete）は、ローカル常駐型 AI エージェント OpenClaw を公開したオーストリアのエンジニアです。2026 年 2 月に OpenAI へ参加して以降、その AI 駆動開発の運用規模はさらに一段大きくなりました。2026 年 5 月 15 日の Peter 氏の X 投稿では、クラウド上で 常時およそ 100 体の Codexを走らせていると説明されています。
本記事は、Peter 氏本人の 2 つの投稿、つまり CodexBar の利用量スクリーンショットと、約100体の Codex 運用説明を主な出典として、「何が起きているか」「組織が読み取れることはどこか」の 2 軸で整理します。なお Peter 氏のキャリアやツール選択、設定ファイル哲学といった全体像は、別記事の Peter Steinberger 氏のAI駆動開発手法 で扱っています。本記事はその続編として、OpenAI 参加後のエージェント運用体制に焦点を絞ります。
| 項目 | 値 | 補足 |
|---|---|---|
| OpenAI API 消費額 | 約 $1,305,088.81（約130万ドル） | 直近30日。CodexBar の表示値 |
| 消費トークン | 603B（6,030億トークン） | 直近30日の累計 |
| リクエスト数 | 760万件 | 直近30日。1日あたり約25万件 |
| 常時稼働 Codex | 約100体 | クラウド上の常駐インスタンス |
いずれの数字も、下に埋め込んだ Peter 氏本人の X 投稿（CodexBar スクリーンショット／約100体の運用説明）で確認できます。
ここで扱う約130万ドル・約100体という数字は、OpenAI 社内で最先端の環境へのアクセスを得た Peter 氏だからこそ成立する運用です。CodexBar のスクリーンショットは利用量の表示であり、公開情報だけでは内部の費用配賦、実請求、実コンピュートコストまでは断定できません。本記事は「コスト制約を外した先で開発がどう変わるか」という観察を主眼とし、組織への適用方法は 第6章で別途整理します。
02.数字の出どころ：Peter 氏の CodexBar 投稿
$1,305,088.81 / 603Bトークン / 760万リクエスト
直近 30 日間の消費額・トークン数・リクエスト数は、Peter 氏が 2026 年 5 月 15 日に投稿した CodexBar のスクリーンショットで確認できます。CodexBar 自体は、Peter 氏が開発した macOS のメニューバーアプリで、OpenAI Codex・Claude・Cursor など複数プロバイダの利用量・コスト・上限リセット時刻を一覧できます（GitHub リポジトリ）。
添付画像には、直近 30 日間の値として 消費額 $1,305,088.81、消費トークン 603B（6,030 億）、リクエスト 760 万件が表示されています。ただし、公開画像から確認できるのは利用量の表示までで、内部原価や実際の請求処理までは確認できません。
個人運用期の請求額との桁の違い
この規模は、OpenAI 参加前の「個人運用期」の数字と比べると桁が変わっています。個人運用期の Peter 氏は、2025 年 7 月時点で月額約 6,000 ドルの Anthropic 請求、サブスク経由の実質無制限運用で月額約 1,000 ドルという範囲でした。OpenAI 参加後の約 130 万ドルは、その個人運用期の AI 消費額のおよそ 200 倍を超える規模です。
| 時期 | 運用主体 | 月あたりのAI消費規模 |
|---|---|---|
| 2025年7月（個人運用期） | Peter 氏 個人 | Anthropic 請求 約$6,000＋サブスク 約$1,000 |
| 2026年5月（OpenAI参加後） | Peter 氏の OpenAI 参加後の運用 | OpenAI API 消費 約$1,305,088（603Bトークン、CodexBar 投稿） |
重要なのは、台数とコストが増えただけでなく、「個人が手元で並列実行する」運用から「クラウドにエージェント群を常駐させる」運用へと、形そのものが変わった点です。次章でその中身を見ます。
03.約100体のエージェントは何を分担しているか
実装・レビュー・Issue整理を分けて並走させる
約 100 体の Codex は、同じタスクを 100 並列で回しているわけではありません。Peter 氏の X 投稿では、それぞれが 役割を分担して別々の仕事を担う構成が説明されています。ある Codex はプロジェクトのビジョンに沿って新規 Issue から PR を起票し、別の Codex はその PR をレビューします。また、コミットごとのセキュリティ確認、重複 Issue の整理、ベンチマーク監視、会議内容からの PR 起票も挙げられています。
日本語訳（投稿全文）
私の AI 利用額に多くの人が驚いている。だが見えていないことがある。OpenClaw に取り組むうえで私がとても興奮しているのは、次の問いに答えようとしているからだ。
トークンのコストが問題にならないとしたら、私たちは将来どのようにソフトウェアを作るのか？
私たちはクラウド上で常時およそ100体の codex を走らせ、すべての PR、すべての Issue をレビューしている。main に修正が入れば、@clawsweeper がいずれ半年前の Issue を見つけ出し、正確な参照を添えてクローズする。
すべてのコミットに対して codex を走らせ、セキュリティ上の問題をレビューしている（見落とすのはあまりに簡単だからだ）。
codex を使って Issue を重複排除し、似たもの同士のまとまりを見つけ、最も急を要する問題のレポートを送っている。
複雑な環境を再現し、使い捨ての crabbox.sh マシンを立ち上げ、たとえば Telegram にログインし、動画を撮って修正前後を PR に投稿できるエージェントもいる。
新しい Issue を監視する codex もあり、私たちが文書化したビジョンによく合致していれば、自動でその PR を作成する（それをさらに別の codex がレビューする）。
コメントをスパム判定して投稿者をブロックする codex も走らせている。
性能ベンチマークを検証し、リグレッションを Discord に報告する codex インスタンスも走らせている。
私たちのミーティングを聞き、先回りして作業を始めるエージェントもいる。たとえば新機能について議論している最中に、その場で PR を作成する。
私たちは clawpatch.ai を作り、すべてのプロジェクトを機能単位に分割してレビューし、バグやリグレッションを見つけている。
セキュリティについても、Vercel の deepsec と Codex Security で同じ分割を行い、リグレッションや脆弱性を見つけている。
こうした自動化のすべてが、このプロジェクトを極めて少人数で回すことを可能にしている。
| エージェントの役割 | やっていること | 主な出力先 |
|---|---|---|
| 実装 | プロジェクトのビジョンに沿って自律的に PR を起票 | GitHub PR |
| コードレビュー | PR をレビューし、コミットに含まれるセキュリティホールを検出 | PR コメント |
| Issue 整理 | 重複 Issue をデデュープし、修正コードまで書く | GitHub Issue / PR |
| ベンチマーク監視 | 性能ベンチマークを継続監視し、リグレッションを検知して報告 | Discord |
| 会議連動 | チームの打ち合わせを聞き取り、議論された機能の PR を起票 | GitHub PR |
ベンチマーク監視と会議連動という常駐タスク
この役割表のうち、組織にとって示唆的なのは下の 2 行です。ベンチマーク監視のエージェントは、人間が見ていない時間帯も性能ベンチマークを回し続け、リグレッション（性能の後退）を検知すると Discord に報告します。会議連動のエージェントは、チームの打ち合わせを聞き取り、その場で議論された機能について PR を起票します。いずれも「人間が指示を出してから動く」のではなく、イベントや状態の変化をきっかけに常駐して動くタイプのエージェントです。
この働き方で重要なのは、実装エージェントだけを増やしていない点です。Peter 氏の投稿では、PR・Issue・コミット・ベンチマーク・会議といった開発イベントの周辺にも Codex を置いています。つまり、コードを書く役割だけでなく、検査・整理・監視・起票までを常駐タスクとして分けていることが、この事例の中心です。
04.「トークンコストがゼロなら」という思考実験
130 万ドルという大きな金額について、Peter 氏は浪費を擁護しているわけではありません。本人の説明は、「トークンのコストが問題にならないとしたら、ソフトウェアはどう作られるのか」を探っているというものです。つまりこの運用は、現時点の費用対効果を最適化した結果ではなく、意図的にコスト制約を外して将来の開発像を先取りする思考実験として設計されています。
この前提に立つと、約 100 体のエージェント運用は「ぜいたくな開発環境」ではなく「将来の開発像を確かめるための実験環境」と捉えられます。コストを気にせずエージェントを常駐させたとき、どの役割分担が機能し、どこで品質が崩れ、人間の仕事が何に絞られていくのか——それを先に体験して持ち帰ることに価値がある、という立て付けです。
Peter 氏の実験は、「コストが下がった未来の開発スタイル」を先に試しているものと捉えると理解しやすくなります。ただし、どの程度の速度でこの運用が一般企業にも現実的なコストに近づくかは公開情報だけでは断定できません。組織が見るべきは金額そのものではなく、コスト制約が緩んだときにどの役割分担が標準になりそうかの予兆です。
05.個人運用期（常時4〜10並列）との違い
Peter 氏は OpenAI 参加前から、すでに突出した並列度でエージェントを運用していました。Lex Fridman Podcast #491 で本人が語った個人運用期の数字は、並列で動かすエージェントは睡眠時間とタスク難度に応じて 4〜10 の間で変動し、PR トリアージのような一時的タスクでは過去に最大 50 まで広げた、というものでした。これでも一般的な開発者から見れば異例の規模です。
OpenAI 参加後の「常時約 100 体」は、その個人運用期からさらに約 10 倍の規模です。ただし重要なのは数の大きさだけではありません。下表のとおり、運用の「形」が個人技からチーム運用へ移っている点が本質的な変化です。
| 観点 | 個人運用期（〜2026年初） | OpenAI参加後（2026年5月） |
|---|---|---|
| 並列度 | 常時4〜10、ピーク時に最大50 | 常時約100体 |
| 運用主体 | Peter 氏 個人 | Peter 氏の OpenAI 参加後の運用 |
| 実行環境 | 手元のターミナル（Ghostty のタブ／ペイン） | クラウド上の常駐インスタンス |
| 起動のきっかけ | 本人がタスクを割り当てて起動 | イベント・状態変化をきっかけに常駐起動 |
| 人間の主な役割 | 並列タスクの設計と切り替え | 役割設計と結果の確認 |
つまり OpenAI 参加後の体制は、「1 人が速く書く」を突き詰めた先ではなく、「常駐するエージェント群をどう設計し統治するか」という別の問題に移っています。これは、組織が AI 駆動開発を考えるときの論点とつながっています。
06.組織がこの事例から読み取れること
この事例を組織がそのまま再現する必要はありません。約 130 万ドルの API 消費も、約 100 体の常駐エージェントも、OpenAI 社内の特殊な環境を前提とした実験です。一方で、金額や台数を取り除いたあとに残る「運用の型」には、規模を問わず参考になる要素があります。
| 読み取れる型 | Peter 氏の事例での具体例 | 組織で検討するときの論点 |
|---|---|---|
| 役割でエージェントを分ける | 実装／レビュー／Issue整理／監視／会議連動を別エージェントが担当 | 1体に全部やらせず、責務を分けて衝突や見落としを減らす |
| 常駐・イベント駆動にする | ベンチマーク監視や会議連動が人間の指示を待たずに動く | CI・Issue・会議など、どのイベントを起点にするかを先に決める |
| 開発イベント全体を監視する | PR・Issue・コミット・ベンチマーク・会議に Codex を置く | 実装だけでなく、レビュー・検査・監視・起票までのどの工程にエージェントを置くか全体像を描く |
| 検証の土台を先に作る | セキュリティ検査やベンチマーク監視を専任エージェント化 | テスト・CI・eval を整えてからエージェントの自走範囲を広げる |
Peter 氏の運用が成立しているのは、セキュリティ検査やベンチマーク監視といった検証側もエージェントとして常駐しているからです。組織がこの事例を参考にする場合、最初に増やすべきは実装エージェントの台数ではなく、テスト・CI・レビュー・ベンチマークといった検証の土台です。検証が薄いまま実装エージェントだけを並列化すると、レビューしきれない PR が滞留します。台数は、検証の土台と役割設計が固まったあとに段階的に広げるのが現実的です。
チームでエージェント運用を内製化するための設計を一緒に整理しませんか
役割分担、CI・検証の土台づくり、PR運用ルールまで、Cryptul が現場で使える型に落とし込みます。
Peter Steinberger 氏のAI駆動開発手法
本記事の前提となる、Peter 氏のキャリア・ツール選択・設定ファイル哲学・未来予測までを網羅的に整理しています。
OpenClawとは
Peter 氏が立ち上げたローカル常駐型AIエージェント OpenClaw の仕組みと使い方を整理しています。
CLIエージェント入門｜Claude Code / Codex CLI / Cursor の使い分け
本記事で扱う Codex を含む、CLIコーディングエージェントの使い分けを整理しています。
AIエージェントとは｜AIアシスタント / ワークフロー / エージェントの定義と境界
本記事で扱う『エージェント』の前提となる、定義と境界を公式ドキュメントから整理しています。
07.FAQ
月130万ドルという数字の出どころはどこですか？
Peter Steinberger 氏本人が 2026 年 5 月 15 日に投稿した CodexBar のスクリーンショットです。添付画像には、直近 30 日間で約 $1,305,088.81・603B トークン・760 万リクエストという OpenAI API 消費が表示されています。
約100体のエージェントは同じ作業を並列でやっているのですか？
いいえ。それぞれが役割を分担しています。Peter 氏の X 投稿では、PR 起票、PR レビュー、コミットごとのセキュリティ確認、重複 Issue の整理、ベンチマーク監視とリグレッション報告、会議の聞き取りからの PR 起票などが挙げられています。同じタスクを 100 並列で回しているわけではありません。
この運用を自社でそのまま再現すべきですか？
そのまま再現する必要はありません。CodexBar 投稿で示された約 130 万ドル規模も約 100 体の常駐エージェントも、OpenAI 社内の特殊な環境を前提とした実験です。組織が参考にすべきは金額や台数ではなく、役割でエージェントを分ける・常駐イベント駆動にする・開発イベント全体を監視対象にする・検証の土台を先に作る、という運用の型です。
08.まとめ
Peter Steinberger 氏の OpenAI 参加後の運用体制について、本人投稿から確認できる中心的な事実は、クラウド上で 常時およそ100体の Codexを動かし、PR・Issue・コミット・ベンチマーク・会議の周辺に役割を分けて置いていることです。直近 30 日で約 130 万ドル（603B トークン／760 万リクエスト）の API 消費も、Peter 氏本人の CodexBar 投稿に添付されたスクリーンショットで確認できます。組織が読み取るべきは、役割でエージェントを分ける／常駐・イベント駆動にする／開発イベント全体を監視対象にする／検証の土台を先に作るという運用の型です。台数を増やすのは、その土台が固まったあとで構いません。
