1GBの机が燃えそうなら、2GBの机を10個生やせ:Railway Sandbox×OpenCodeで作る「使い捨て作業台」節約術

読書機能の使い方

聴く:本文を読み上げます。速読:語句を順に表示し、速さを調整できます。語学練習:別の言語版と対訳を読み比べます。保存:このブラウザーにブックマークし、プレイヤーの保存済み一覧から開けます。

この記事をシェア
広告
広告

小さいクラウドコンテナでAIコーディングエージェントを動かしていると、だいたい一度は「なんでこいつ、コードを書く前に机を食い尽くしてるんだ」という瞬間が来る。

Gitを開く。Node.jsがいる。依存関係を読む。ログを抱える。テストを走らせる。AIエージェント本体も動く。すると1GBのメモリは、六畳一間に冷蔵庫、洗濯機、ベッド、デスク、サーバーラックを全部入れた部屋みたいになる。まだ住める。だが椅子を引いた瞬間に冷蔵庫が開く。

ここでありがちな対策は「ログを減らそう」「キャッシュを消そう」「もっと節約しよう」だ。もちろん有効だが、限界がある。机が狭いなら、整理術だけではなく机そのものを増やすという発想がある。

RailwayのSandboxは、この発想と妙に相性がいい。2026年9月24日時点で、TrialとFreeは1環境あたり同時10個までSandboxを起動でき、1個あたり2 vCPU・2GBメモリが上限だ。[1] つまり、1台の巨大マシンを買うのではなく、2GBの使い捨て作業台を必要なときだけ並べられる。

1. メモリは「机」、ストレージは「倉庫」

最初にここを混ぜると設計が崩れる。

メモリは、いま開いている作業の置き場だ。ストレージやVolume、オブジェクトストレージは、使っていない資料をしまう倉庫である。

500MBのログを外部ストレージへ逃がしても、実行中のプログラムが700MBのメモリを食えば700MBは必要だ。逆に、巨大なファイルを全部メモリへ読み込まず必要な部分だけ処理すれば、狭い机でも延命できる。

だから役割は分ける。

  • メモリ:作業中の机
  • Sandbox:机そのもの
  • GitHub:コードと正式な成果物の保管庫
  • オブジェクトストレージ:重い資料や中間生成物の倉庫
  • dispatcher:空いている机へ仕事を配る受付

「倉庫を増やせば机が広がる」は違う。しかし「倉庫へ余計な物を片づけつつ、机の数も増やす」なら強い。

2. Trial/FreeでもSandboxは1個2GB、同時10個

Railwayの公式仕様では、TrialとFreeのSandboxはデフォルトも最大も2 vCPU・2GB。1環境につき同時10個までで、CREATINGまたはRUNNING状態のSandboxが上限へ数えられる。[1]

数字だけ見るとかなり景気がいい。

2GB × 10台 = 合計上限20GB。

ただし、20GBの1台として使えるわけではない。 2GBの独立した机が10枚あるだけだ。4GB必要な単一プロセスを2台へ魔法のように分割する機能ではない。

それでもAIエージェントの仕事は、「調査」「実装」「テスト」「静的検査」「ログ解析」「公開確認」などへ分けやすい。独立できる工程なら、10枚の机はかなり効く。

3. 「5分で消える」は、5分以内に仕事を終えろという意味ではない

TrialとFreeのSandboxは、デフォルトのアイドルタイムアウトが5分で、1〜5分の範囲から選ぶ。[1]

ここだけ読むと「5分以内の小仕事しかできないのか」と思いやすい。違う。

Railwayはexecコマンドが実行中ならアイドル破棄を延期する。detachedで走っているexecも対象だ。SDKでは明示的なコマンドタイムアウトを設定しない限り、コマンドは終了まで走る。[1]

つまり、

  • 20分のテスト実行中 → 生きる
  • 30分のビルド中 → 生きる
  • コマンド終了後、何もしない状態が5分継続 → 破棄

という理解が近い。

5分ごとにAIへ「生きてる?」と棒でつつく必要はない。

4. 主役は「固定OpenCode+動的Sandbox」の二刀流

ここで固定のOpenCode実行環境を捨てる必要はない。むしろ残す。

理想形はこうだ。

              dispatcher
                  |
        +---------+---------+
        |                   |
 permanent OpenCode     dynamic Sandbox pool
   rescue worker       0 ... 10 workers
        |                   |
        +---------+---------+
                  |
            GitHub / storage

通常の重作業はSandboxへ流す。常設OpenCodeは、Sandbox生成に失敗したとき、上限へ達したとき、checkpointが壊れたとき、dispatcher自体を修理するときの救援班になる。

修理工場を完全無人化した結果、修理工場のドアが壊れて誰も入れない、というクラウド版コントを避けられる。

5. 自動配車は「超えてから引っ越す」ではなく「次の仕事を別机へ」

実行中のプロセスを、メモリが90%になった瞬間に別Sandboxへワープさせるのは難しい。

そこでdispatcherは、現在の仕事を途中移住させるのではなく、新しい仕事の受付を止める。

例えば設計上の運用値として、

  • 70%未満:通常受付
  • 70〜85%:小さい仕事中心
  • 85%以上:DRAINING。新規の重作業を受けない
  • 90%以上:新規受付停止、現ジョブ完了後に破棄

とする。

これはRailwayの公式しきい値ではない。自前の配車ポリシー例だ。

「机が崩壊してから隣の机へ荷物を投げる」のではなく、「この机、そろそろ書類の山が天井に届くな」と思った時点で、次の仕事を隣へ回す。

6. 仕事は時間ではなく「再実行しやすさ」で切る

5分単位に仕事を切る必要はない。

むしろ、

  • 調査
  • 実装
  • テスト
  • 品質確認
  • デプロイ
  • 本番確認

のように、失敗したときその工程だけやり直せる単位へ分ける。

例えば実装が終わったらGitへ保存し、そのcommitを入力に別Sandboxでテストする。テストだけ落ちたら、実装全体を最初からやり直さなくていい。

「巨大な一匹のAIに全部抱えさせる」から、「小さい作業員へ工程を渡す」へ変えるわけだ。

7. 10台並列で一番怖いのは、メモリより同時編集

workerを10台に増やすと、次の事故が起きる。

Sandbox A「この設定ファイル直した」 Sandbox B「俺も直した」 main「どっちやねん」

だからresource lockが必要だ。

同じrepositoryでも、触るpathが違えば並列化できる。同じファイルや同じ状態台帳へ書く仕事だけロックする。Jobごとにbranchやworktreeを分け、最後の統合を1か所へ寄せる。

最大10台という数字に興奮して、全員に同じドライバーを持たせて同じネジを回させると、速くなるどころかネジ山が消える。

8. 節約の本体は「10台使える」ではなく「0台まで戻せる」

Sandboxは無料の魔法ではない。RailwayはVMが動いている間の資源利用に課金する。公式の例では、20分のタスクで平均1GBメモリ・0.3 vCPUを使うSandboxは、計算資源だけで約3セント。50回なら約1.50ドルとしている。[1][2]

Trialは最大30日または5ドルのTrial creditを使い切るまでで、その後はFreeへ移り、Freeは月1ドルの無料creditを提供する。[3]

だから節約設計は「10台常時起動」ではない。

queue 0件  -> 0台
queue 1件  -> 1台
queue 4件  -> 必要数だけ増やす
大量処理   -> 最大10台
終了       -> destroy

強いのは10台まで増えること以上に、仕事がないとき0台へ戻せることだ。

さらに、毎回OSや依存関係を最初から作ると無駄なので、Railwayのcheckpointやforkを使い、準備済みファイルシステムから新しいSandboxを作る。[4] 「作業員を雇うたびに机をIKEAから組み立てる」のをやめる。

9. 常設OpenCodeはクビではなく、非常口になる

動的Sandboxが便利だからといって、常設OpenCodeを消すのはもったいない。

常設workerは、

  • Sandbox API側の障害
  • Sandbox上限到達
  • checkpoint不良
  • dispatcher修理
  • 小さな緊急作業

の逃げ道になる。

通常系とfallback系が完全に同じ故障モードへ乗らないようにしておくと、システム全体が止まりにくい。

「新しい自動化を入れたので古い経路を即解体しました」は、エンジニア版の「新しい橋が完成したので古い橋を今日爆破します」である。まず両方通して、十分安定してから役割を縮めればいい。

10. 結論:1GBを100MB節約する戦いから降りる

小さいコンテナを使っていると、つい「あと100MB減らせないか」という最適化ゲームへ入る。

だがAIコーディング作業では、巨大な1ジョブを無理に1台へ押し込むより、

固定OpenCodeを残す → dispatcherで仕事を分ける → 2GB Sandboxを必要時だけ0〜10台生成 → 成果物を外へ保存 → idleなら破棄

という構造の方が素直だ。

倉庫は机ではない。10枚の机は20GBの巨大机でもない。しかし、独立した仕事を並べるには十分強い。

そして節約の肝は、「全部を小さくする」ことではない。

必要な瞬間だけ机を生やし、仕事が終わったら机ごと消す。

クラウドなのに、最終的にやっていることは文化祭の会議室運営みたいである。必要な机だけ出して、終わったら片づける。それが一番安い。

参考資料(5件)

  1. Railway Docs — Sandboxes. Retrieved 2026-09-24. Trial/Free: 10 concurrent Sandboxes per environment; 2 vCPU / 2 GB each; 5-minute default idle timeout; active exec defers idle teardown; checkpoints/forks and pricing guidance docs.railway.com
  2. Railway Docs — Pricing Plans. Retrieved 2026-09-24. Resource and VM pricing; Trial/Free service resource limits docs.railway.com
  3. Railway Docs — Free Trial. Retrieved 2026-09-24. Trial provides a one-time $5 credit for up to 30 days; after 30 days or credit exhaustion it reverts to Free, which provides $1 free credit per month docs.railway.com
  4. Railway Docs — Create your first sandbox. Retrieved 2026-09-24. Sandbox create/exec/destroy lifecycle, SDK fork example, checkpoint guidance, and coding-agent use cases docs.railway.com
  5. Railway Docs — Volumes. Retrieved 2026-09-24. Free/Trial default volume size 0.5 GB and volume/replica limitations docs.railway.com

PRこのテーマの本を探す

この記事には広告(アフィリエイトリンク)が含まれます。 広告について Amazonのアソシエイトとして、mendoi-appsは適格販売により収入を得ています。

今日これ読んで

この記事を読んだ人の次の疑問に、それぞれ答える記事です。

すべての記事から探す「AI」の記事をもっと見る

広告

他の記事を探す

すべての記事

めんどいちゃん

この記事を書いた人

めんどいちゃん

仕事や日常の「めんどい」を構造化して、次に動きやすくする記事を書いています。

このサイトについて
広告

新着記事

  1. 1『氷の城壁』『氷の城壁』小雪は冷たいんじゃないの。中で味噌が発酵してるのよ――「分かるわお姉さん」と読む反芻・脳内予想・境界線
  2. 2面接で「圧が強い人がいても大丈夫?」を3回聞かれたら、もう会社説明になってない?
  3. 350年住宅ローンは「家を安くする魔法」ではない――借金ゲーム・金利上昇・金融庁の監視を小学生でも分かるように解剖する
  4. 4『ラヴ上等』『ラヴ上等2』、恋愛に24時間SLAを持ち込むな――Awichは全部知ってる、たいちゃんの耳はHPゲージ、最後はモモンガが「よこせッ!」
  5. 5『ちいかわ』装備:モモンガ、属性:六角堂帰り――人類は他人の「設定資料集」を勝手に書く
広告