クラウドサーバー上でClaude Codeを動かす——AWS EC2/Fargate/Lambda/Bedrockの使い分けと運用パターン

「Claude Codeはローカルで使うもの」という感覚はわかる。最初は私もそうだった。ターミナルを開いて、コードに向き合って、質問しながら進める。その体験は確かに良い。

ただ、少しすると別の欲が出てくる。「夜間にPRレビューを自動で回せないか」「CI/CDのなかでコード品質チェックをClaude Codeに任せたい」「毎朝8時に定期バッチを動かしたい」——こういった自動化ニーズが積み上がってくる。ローカルのターミナルを開いていないと動かないエージェントでは、その先には進めない。

2026年に入り、Claude Codeをクラウドサーバー上でヘッドレス実行するための手段が一通り揃ってきた。この記事では、AWS環境を中心に「どのパターンで動かすか」「認証をどう設計するか」「コストとセキュリティをどう管理するか」を整理する。

既存記事で解説済みの Bedrock AgentCore や Routines / Ultraplan は対象外とし、自社のEC2/ECS/Lambdaに直接デプロイして動かすパターンに絞って書く。

ヘッドレス実行の基本：-pフラグと--bareの三点セット

クラウドで動かすには、まずClaude Codeを「非インタラクティブ」で動かす方法を理解する必要がある。

公式ドキュメントによると、-p（--print）フラグを使うと、プロンプトを1ターンで処理して終了させられる。

claude -p "Find and fix the bug in auth.py" --allowedTools "Read,Edit,Bash"

ただし-p単体では不十分で、ツール承認プロンプトが出て止まってしまう。CI/CDや定期バッチで完全に非インタラクティブで動かすには、以下の三点をセットで使う。

# CI推奨パターン
claude --bare \
  -p "Run the daily report task" \
  --allowedTools "Read,Bash" \
  --permission-mode acceptEdits

--bareはフック・スキル・プラグイン・MCPサーバー・Auto Memory・CLAUDE.mdの自動読み込みをすべて省く。再現性が高く、不要なトークン消費を抑えられる。--output-format jsonを加えるとtotal_cost_usdやsession_idを含む構造化レスポンスが返るので、サーバー運用ではこれをログ基盤に流すのが実用的だ。

バージョンについても注意が必要で、v2.1.163以前はバックグラウンドコマンドが終了しないとclaude -pがハングするバグがあった。v2.1.163で修正済みのため、サーバー環境では必ずバージョンを確認しておく。

5つのデプロイパターン比較

実用できるデプロイ構成は大きく5種類に整理できる。

EC2常駐パターン

2〜4GB RAM・2vCPUのインスタンスで十分動く。EC2 t3.smallで月$15程度（us-east-1オンデマンド、2026年6月時点）。

セットアップはシンプルだ。Node.jsとClaude Codeをインストールし、tmux new-session -s claude-mainでセッションを永続化して、systemdで起動時自動実行を設定する。認証情報は環境変数で渡すが、cron実行時は環境変数が引き継がれないので/etc/environmentに設定するか、crontabに直接exportする必要がある。

長時間稼働させているとコンテキストが膨張して週間キャップに引っかかりやすい。定期的に/clearでリセットする運用を組み込んでおく。

ECS Fargateパターン

コンテナ化してECS Fargateで動かすのが、本番運用としてバランスが良い。Dockerfileの最小構成はこうなる。

FROM node:24-alpine
RUN npm install -g @anthropic-ai/claude-code
WORKDIR /app
COPY . .
CMD ["claude", "--bare", "-p", "Run the daily report task", \
     "--allowedTools", "Read,Bash"]

コンテナへの認証情報はECSタスクロール経由で渡す（Bedrock利用時）か、AWS Secrets Managerから取得する。環境変数への平文埋め込みは禁止だ。コンテナには最低4GBメモリを割り当てる必要がある。夜間バッチ・デプロイ後の自動テスト・定期的なコードレビュー生成に向いている。

Lambdaパターン

Lambdaは最大実行時間15分という制約がある。Claudeのエージェントループが長くなるタスクには向かない。向いているのは30秒〜5分程度で完結する短時間タスクで、S3アップロードトリガーやAPI Gateway経由のイベントドリブン呼び出しが典型的な使い方だ。

同時実行数のデフォルト上限はアカウント全体で1,000。大量の並列エージェントを動かすにはクォータ申請が要る。

GitHub Actions / GitLab CIパターン

GitHub Actionsはv1.0として正式公開済みで、公式アクションanthropics/claude-code-action@v1が使える。PRやIssueに@claudeとメンションするだけで動く。

Bedrockを経由する場合はOIDC認証と組み合わせる。静的なアクセスキーを使わず、一時認証情報でアクセスするのがセキュリティ上正しい設計だ。

- name: Configure AWS Credentials (OIDC)
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}
    aws-region: us-west-2

- uses: anthropics/claude-code-action@v1
  with:
    github_token: ${{ steps.app-token.outputs.token }}
    use_bedrock: "true"
    claude_args: '--model us.anthropic.claude-sonnet-4-6 --max-turns 10'

GitLab CIはbeta扱いだが本番利用の報告もある。公式の GitLab CI/CD ドキュメントに従って設定できる。

認証設計：APIキー・Bedrock・Subscriptionの使い分け

クラウド運用で最初に決めるべきが認証方式だ。公式の認証ドキュメントによると、Claude Codeは複数の認証情報を検出した場合に優先順位に従って選択する。クラウドプロバイダー認証（CLAUDE_CODE_USE_BEDROCK=1等）が最上位で、以下 Bearer トークン → Anthropic APIキー直接 → apiKeyHelperスクリプト → OAuthトークンの順だ。

サーバー運用での選択肢はほぼ3択になる。

Anthropic APIキー直接は最もシンプルで、プロトタイプや小規模自動化に向く。新モデルは他の方式より先に利用できる利点があり、レイテンシも低い。ただしVPCネイティブな統合がないため、閉域ネットワーク要件がある環境では使えない。

AWS BedrockはAWS環境の本番運用に適している。Anthropic APIと同一のトークン単価であり、IAM・CloudTrail・CloudWatchとシームレスに統合できる。VPC PrivateLink経由で完全クローズドネットワークを構成できる点が、コンプライアンス要件の厳しい組織では重要になる。欠点は新モデルの対応が数週間〜数ヶ月遅延する場合がある点と、WebSearchツールが利用不可な点だ。

Claude ProやMaxサブスクリプションをサーバー常駐に使うのは、設計として成立しなくなりつつある。2026年6月15日にAnthropicがAgent SDKおよびclaude -pヘッドレス実行をサブスクリプション枠から分離する課金変更を発表した（同日に一時停止。Anthropicはプランの更新を検討中とし、詳細は未定）。サブスクリプションのみに依存したサーバー常駐設計はリスクが高いため、本番のサーバー用途にはAnthropicAPIキーまたはBedrockを使う設計にしておくのが無難だ。

コスト試算と最適化

Sonnet 4.6の料金は入力$3/MTok・出力$15/MTokだ（Anthropic API直接。Bedrockのオンデマンドも同価格）。コードレビューを1回実施したとき、入力20,000トークン・出力5,000トークン程度が一般的なトークン消費量として想定できる。

この試算をすると、1回あたり約$0.135。1日100回実施した場合は$13.5/日、月換算で約$400になる。

この金額を削減する手段がいくつかある。

夜間や週末のレビューバッチなど、24時間以内に結果を得てよいタスクはBatch APIを使う。Sonnet 4.6では入力$1.50・出力$7.50と50%割引になるので、先ほどの試算が月約$200まで下がる。

プロンプトキャッシュも効果が大きい。システムプロンプトやコードベースの共通部分にキャッシュを設定すると、キャッシュヒット後は通常価格の10%（$0.30/MTok）になる。--bareモードも地味に効く。不要なMCPやCLAUDE.mdの読み込みを省くことでトークンを節約できる。

環境変数でBedrockを設定する最小構成はこうなる。

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1

# モデルを固定する（本番必須）
export ANTHROPIC_DEFAULT_SONNET_MODEL='us.anthropic.claude-sonnet-4-6'
export ANTHROPIC_DEFAULT_HAIKU_MODEL='us.anthropic.claude-haiku-4-5-20251001-v1:0'

# オプション：1時間TTLのプロンプトキャッシュ
export ENABLE_PROMPT_CACHING_1H=1

セキュリティ設計：IAM最小権限・PrivateLink・Secrets Manager

セキュリティ設計はIAM・ネットワーク・シークレット管理の3つの層で考える。

IAM最小権限

ECSタスクロールやLambda実行ロールに付与するIAMポリシーは、必要最小限に絞る。Bedrock利用時に必要なのは以下の4アクションだけで、iam:*やs3:*などの広すぎる権限は絶対に付けない。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:ListInferenceProfiles",
        "bedrock:GetInferenceProfile"
      ],
      "Resource": [
        "arn:aws:bedrock:*:*:inference-profile/*",
        "arn:aws:bedrock:*:*:foundation-model/*"
      ]
    }
  ]
}

VPC PrivateLinkでの閉域接続

BedrocktのAPIコールをインターネットに出さずに済む構成が、AWS Builder Centerのドキュメントで紹介されている。

EC2/ECS → VPC Interface Endpoint (bedrock-runtime) → Bedrock API
（インターネット不使用）

必要なPrivateLinkエンドポイントはbedrock・bedrock-runtime・bedrock-agent-runtimeの3つ。インターネットゲートウェイへのルートを削除することでAPIコールの閉域化を保証できる。CISOポリシーで「外部APIコール禁止」が要件の組織では、この構成が前提になる。

Secrets ManagerとapiKeyHelper

Anthropic APIキーを使う場合、Secrets Managerに格納して動的取得するのが安全だ。apiKeyHelper設定でこれが実現できる。

{
  "apiKeyHelper": "aws secretsmanager get-secret-value --secret-id claude-api-key --query SecretString --output text"
}

デフォルトで5分ごと、またはHTTP 401レスポンス時に自動リフレッシュされる。キーのローテーションにも自動追従できる。

Bedrock Guardrails

コンテンツフィルタリングが必要な場合、Guardrailsを有効化できる。環境変数でカスタムヘッダーを設定するだけで適用される。

{
  "env": {
    "ANTHROPIC_CUSTOM_HEADERS": "X-Amzn-Bedrock-GuardrailIdentifier: your-guardrail-id\nX-Amzn-Bedrock-GuardrailVersion: 1"
  }
}

運用で踏みやすい落とし穴6種

実際に動かすと必ず遭遇するハマりどころがある。

1. レートリミットの二層構造

Claude Codeの利用量は2つの独立した上限で管理される。ひとつは5時間ローリングウィンドウ（短時間バースト制御）、もうひとつは週間キャップ（総コンピュート時間制限）だ。2026年5月6日にAnthropicは5時間制限を恒久的に2倍に引き上げ、Pro・Maxに対してはピーク時間帯（太平洋時間5〜11時）のスロットルも廃止した。ただし週間キャップは据え置きのため、EC2に常駐させて大量処理する場合は夜間・週末へのスケジューリングが実践的な対策になる。

API直接利用（Tier 2〜4）はRPM/TPMベースの制限で、サブスクリプションより予測しやすい。

2. コンテキスト肥大問題

エージェントループは多ターンにわたってコンテキストが累積する。「単純なファイル編集」でも50,000〜150,000トークンを消費することがある。ツール結果やファイル内容の反復読み込みが原因だ。--max-turnsでループ上限を設定する、タスクを細かく分割してセッションを分ける、この2点が基本の対策になる。

3. Bedrockでモデルを固定しないと動かない

ANTHROPIC_DEFAULT_SONNET_MODEL等を設定しないと、Claude Codeのデフォルト値がリージョンで利用不可のモデルを指すことがある。「on-demand throughputエラー」が出た場合は、モデルIDを推論プロファイルID（例：claude-sonnet-4-6 → us.anthropic.claude-sonnet-4-6）に変更すると解決する。本番デプロイ前にモデルを固定するのは必須だ。

4. Lambdaの15分タイムアウト

Lambdaのデフォルト最大実行時間は15分。Claudeのエージェントループが長いタスクでは普通に超える。長い出力は非同期呼び出し + S3経由にする、コールドスタート対策でProvisioned Concurrencyを設定する、といった工夫が要る。

5. OAuthフローとSSH環境の相性

ProやMaxサブスクリプションをサーバー上で使おうとすると、初回ログインにブラウザが要る。SSH環境ではURLをコピーしてローカルブラウザで認証する手順を踏む。CI環境ではclaude setup-tokenで生成する1年有効のOAuthトークン（CLAUDE_CODE_OAUTH_TOKEN）が回避策になるが、--bareモードでは読み込まれないという制約がある。

6. GitLab CI はまだbeta

GitLab CIのサポートは本番利用の報告はあるものの、公式にはbeta扱いだ。本番ワークフローに組み込む場合は、--bareと--allowedToolsを明示的に指定し、再現性と安全性を担保した形で使う。

最初の一手

実際に動かすための出発点を順に示しておく。

まずEC2 t3.small（月$15程度）にANTHROPIC_API_KEYを設定して、claude --bare -p "What files are in this directory?" --allowedTools "Bash"を叩いてみるのが早い。10分もあれば動作確認まで進める。

そこから本番化するなら、BedrockのIAMロール設定とECS Fargateへのデプロイが次の段だ。AWSのSolutions Libraryにguidance-for-claude-code-with-amazon-bedrockというリファレンス実装が公開されている。CloudFormationによるIAMロール・OIDCプロバイダー自動構築から、ECS Fargate上のOpenTelemetryコレクターによるコスト分析パイプラインまでセットになっているので、これを土台にするのが早い。初期デプロイの目安は5〜15分だ。

CI連携から入るというルートもある。既存のGitHubリポジトリにanthropics/claude-code-action@v1を設定すれば、PRに@claudeとメンションするだけでレビューが走る。導入コストが最も低く、チームへの価値訴求もしやすい。

ローカルで使っているClaude Codeがクラウドに常駐し始めると、仕事の時間の使い方が変わる感覚がある。夜間に終わっていたPRレビューが朝のSlackに届いている、定期バッチが走った結果がログに残っている。そういう「動いていた形跡」が積み上がっていくと、次は何を自動化できるかを自然に考え始める。

本記事の料金・API仕様は2026年6月時点の情報をもとにしています。Anthropicの課金変更（Agent SDKクレジット分離）は2026年6月15日に一時停止されており、最新状況は公式ドキュメントを確認してください。