24時間稼働のAI Coding Agentを構築するには？

ひとことで：2026 年、夜通し issue を拾い、コードを直し、PR を出せる AI Coding Agent を組みたい人の多くが、最初の一歩でつまずきます——Cursor を入れるか API を買えば足りると思っているからです。本当に長く回る autonomous coding agent には、常駐の実行基盤・タスクスケジューリング・客観的な検証が欠かせません。以下ではアーキテクチャのレイヤー、デプロイトポロジー、最小構成（MVP）、本番向けの堅牢化の四本柱で、そのまま手を動かせる完全ガイドを示します。

1. 24時間 AI Coding Agent とは何か？

IDE に入れる Copilot や Cursor Tab とは別の問いを解きます。24時間 AI Coding Agent が扱うのは、あなたが席を外しているとき、誰が実環境でリポジトリを変更し、コマンドを走らせ、検証シグナルを得るのかということです。

実際に回るデプロイには、次の四つの能力が揃っています。どれか一つでも欠ければ「24時間 autonomous coding agent」とは言えません：

• 常駐実行環境（L0）——停電・断線のない macOS または Linux ノード。git、npm、xcodebuild が動く。
• コーディング Agent プロセス（L3/L5）——ペアプロ層（Claude Code）または自律層（OpenHands）。コンテキストを読み、Diff を書く。
• タスク入口とキュー——GitHub issue ラベル、Webhook、定期 cron、Slack コマンドなど。「やること」を Agent に渡す。
• 客観的検証（L1）——GitHub Runner またはローカルテストスクリプト。Agent の「できました」ではなく、組織が信じられる Fact を出す。

ひとことで言えば、実行ノードは地盤とインフラ、Agent は現場の作業員、Runner は品質検査員です。多くのチームが失敗するのは、モデル API だけ買い、MacBook 上でスクリプトを走らせただけで 24/7 AI Coding Agent を期待すること——フタを閉じる、スリープ、メモリ競合、出口 IP の変化が、深夜 3 時にタスクを切ります。

2. 一枚の図：タスク入口からマージ可能な PR まで

典型的な autonomous coding agent パイプラインを因果チェーンで整理します。左がメインチェーン、右が「回る条件」と「転ぶ条件」の対照です。

3. 五層コンポーネントの分解

AI Agent インフラのレイヤーと同じ考え方です。24/7 Agent デプロイで一度に全部揃える必要はありませんが、各層が欠けると何が起きるかは把握しておきましょう：

Claude Code が Diff を、Runner が Fact を、OpenHands が Workflow を生む——AI Coding Agent デプロイ時の役割分担の覚え書きです。夜間に lint issue だけ自動処理したいなら L0 + L5 + L1 で足りることが多い。日中はペアプロでアーキテクチャを噛み砕きたいなら L3 を足す。同一マシンで併走する場合はメモリのスケジューリングに注意（並列メモリスケジューリング参照）。

4. デプロイトポロジー：ローカル Mac mini vs Cloud Mac

24時間 AI Coding Agent の実行ノードは物理機、VM、クラウドレンタルのいずれでも構いません。選定の軸はオンライン SLAであり、ブランドではありません：

純バックエンド（Go / Node / Python）なら理論上 Linux VPS でも AI Coding Agent は動きます。ただしワークフローに xcodebuild、swift test、Apple 署名が入った瞬間、実行面は macOS に戻る必要があります。2026 年のデプロイガイドが Mac を前提に書かれるのは情緒ではなく、ABI の境界のためです。

5. 最小構成（MVP）：まず夜間タスクを一本通す

初日から Kubernetes とベクトル DB を積まないでください。最速で「issue → PR → CI 緑」を通した構成は次のとおりです：

• ノード：M4 Mac mini 16GB または同等の Cloud Mac。OpenHands + Runner 併用なら 24GB 推奨。
• Agent：OpenHands（自律）または Claude Code + 簡易シェルラッパー（半自動）。
• モデル：Claude / GPT API。ローカル Ollama は任意で、24/7 必須ではない。
• 入口：issue に agent ラベルを付け、GitHub Webhook でトリガー。
• 検証：同一マシンの self-hosted Runner。runs-on: [self-hosted, macOS]。
• コンテキスト：GitHub MCP は読み取り専用 + リポジトリの AGENTS.md にレッドラインを明記。

6. 7 ステップデプロイチェックリスト

順番どおりに進め、各ステップを個別に受け入れ検証できます——本ガイドの実務の核です。「全部入れたあとで Runner が未登録だった」という事態を避けます。

Step 1 — L0 ノードを準備。 SSH、時刻同期、ディスク ≥ 256GB（Xcode + 複数 workspace は容量を食う）。Cloud Mac 利用者はインスタンス初期化と固定 IP の確認を先に。

Step 2 — 制限付き git 認証を作成。 Agent 専用の GitHub App または deploy key：feature ブランチへの書き込みのみ、デフォルトで main 書き込み不可。本番シークレット、npm token は Agent の環境変数に入れない。

Step 3 — コーディング Agent をインストール。 OpenHands の例（Docker またはネイティブは公式ドキュメントに従う）：

# L0 ノード上で OpenHands をクローンし、公式手順で LLM API Key を設定
git clone https://github.com/OpenHands/OpenHands.git
cd OpenHands
# .env を設定：MODEL、GITHUB_TOKEN（issue 読み取りのみ）、WORKSPACE_BASE
make run

Step 4 — MCP を接続（任意だが推奨）。 大規模リポジトリなら CodeGraph MCP を接続し、autonomous agent が依存関係を「見てから」手を動かせるようにする。

Step 5 — GitHub Runner を登録。 Agent と同一ノードに登録し、ラベル例は macos-agent。workflow 断片：

# .github/workflows/agent-verify.yml
name: Agent PR Verify
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  verify:
    runs-on: [self-hosted, macOS, agent]
    steps:
      - uses: actions/checkout@v4
      - run: swift test   # または npm test / go test

Step 6 — タスク入口を設定。 GitHub Webhook をサーバー上の軽量 HTTP サービスへ向けるか、OpenHands 組み込み連携を使う。ラベル agent-ready でフィルタし、すべての comment で起動しないようにする。

Step 7 — 監視とサーキットブレーカー。 各タスクのトークン使用量、所要時間、変更ファイル数を記録。単一タスクのタイムアウト（例：90 分）で自動 kill。並列は 1 に固定し、安定してから 2 に上げる。

7. 本番堅牢化：深夜に Agent が main を壊さない

Autonomous coding agent の最大リスクは「モデルが弱い」ことではなく、権限が広すぎる + 無人レビューです。本番投入前に最低限これを実施：

8. コストとスペックの見積もり

24時間 AI Coding Agent の請求はだいたい三つに分かれます：

• 算力ノード：Mac mini は初期費用 + 電気代。Cloud Mac は日額・週額（レンタル vs 購入比較参照）。
• モデル API：autonomous agent は多ラウンドループのため、1 タスクあたりのトークンはペアプロの 5〜20 倍になりがち。タスク単位の予算上限を設ける。
• 運用工数：初期は週数時間、ログ確認・プロンプト調整・スタックしたタスクの掃除。「入れたらゼロメンテ」は想定しない。

スペックの目安：OpenHands + 中規模リポジトリだけなら16GB でも動くが Swap しやすい。Agent、Runner、任意の Ollama を同機に載せるなら24GB が安心の起点（16GB vs 24GB参照）。

9. よくある失敗パターン

• ペアプロツールを autonomous agent と勘違い——Claude Code のセッションは終われば止まる。スケジューリング層を自前で包まない限り 24/7 にはならない。
• Fact 層がない——Agent は「テスト通った」と言うが、Runner は一度も走っていない（自前 Runner が価値ある理由）。
• 並列しすぎ——autonomous タスクを二つ同時に走らせ、16GB マシンが Swap 地獄に。
• コンテキスト裸走り——百万行 monorepo で CodeGraph を使わせないのは、目隠し refactor と同じ。
• タイムゾーンと通知を無視——失敗アラートなし。朝、未完成 PR がリポジトリに残っている。

10. よくある質問

Q：Cursor Background Agent は 24時間 AI Coding Agent か？
A：Cursor はホスト型の実行面を提供するため、ローカルを 24/7 起動しなくてよい——ただしリポジトリ権限、CI 検証、コンプライアンス境界は自分で設定する必要がある。自ホストデプロイの意味は、データと実行が完全に自分の管理ノード上にあること。

Q：GitHub Copilot Workspace / OpenAI Codex は使える？
A：L3/L5 のモデル・UI 層として使える。デプロイ層は依然として実行環境 + スケジューリング + 検証。Codex と ChatGPT 統合後はペアプロ寄りになり、無人運用には workflow ラッパーが必要（Codex 統合の解説参照）。

Q：Linux 上の Docker 版 OpenHands だけで足りる？
A：純 Web / バックエンドなら足りる。Apple ツールチェーンのステップは必ず macOS ノードへ。混合チームでは Linux でスケジュール、macOS Cloud Mac でビルドと Agent、という構成が一般的。

Q：一人運用で 24/7 は必要？
A：日中ペアプロだけなら不要。24/7 AI Coding Agent が向くのは issue 滞留、タイムゾーン跨ぎチーム、「技術的負債の片付け」を夜のマシン時間に回したい場合。

Q：Devin / Factory など商用 autonomous agent との違いは？
A：商用製品は Agent + 実行面 + UI をパッケージで売る。自デプロイの意味は監査可能、権限をカスタム、既存 Runner/MCP スタックと揃えられること。多くのチームは最終的に「商用 Agent で探索、自ホストノードで量産タスク」という併用に落ち着く。