マルチAIエージェントをクラウドで動かす — tmux × Claude Code CLIをEC2で常時稼働させるハンズオン

公開日: 2026-04-14
難易度: 中級
所要時間: 約120〜180分
タグ: AWS, EC2, Claude Code, tmux, Cloudflare, Grafana, Terraform, ハンズオン, マルチエージェント

はじめに

「AIエージェントに仕事をさせたい。でも、Macを閉じたらエージェントが止まってしまう」

Claude Code CLIを使ったマルチエージェントシステムを運用していると、必ずこの壁にぶつかります。自宅のMac Miniで動かしているシステムは、再起動・スリープ・停電のたびにtmuxセッションが消え、すべてのエージェントが止まります。復旧には手動でログインして、セッションを張り直す必要があります。

この問題を根本的に解決するのが、AWS EC2への移行です。

本記事では、tmux × Claude Code CLIで構築するマルチAIエージェントシステム「multi-agent-shogun」をAWS EC2上に移植し、以下をすべて実現するハンズオンを実践します。

• 常時稼働: systemd Restart=always + EC2 Auto Recoveryで自動復旧
• リモートアクセス: ttyd + Cloudflare Tunnelでどこからでもブラウザでtmuxセッション操作
• Zero Trust認証: Cloudflare Access（MFA対応・無料）でセキュリティを担保
• ログ可視化: Grafana + Lokiでエージェントの動作をリアルタイムに監視
• 自動バックアップ: EBSスナップショット + GitHub cronで多層バックアップ

コスト帯別に3つの構成パターン（$40〜$115/月）を用意しており、コンソール操作とTerraform IaCの両方で構築手順を解説します。

Section 1: multi-agent-shogunとは

1-1. おしお氏のmulti-agent-shogunプロジェクト紹介

multi-agent-shogunは、おしお氏（@shio_shoppaize）が公開するオープンソースのマルチAIエージェントシステムです。tmux + Claude Code CLIを組み合わせ、1台のLinuxマシン上で複数のClaudeインスタンスを並列稼働させ、役割分担しながら自律的にタスクを処理します。

このシステムの詳細は以下で公開されています：

• Zenn（解説記事）: https://zenn.dev/shio_shoppaize
• GitHub（ソースコード）: https://github.com/yohey-w/multi-agent-shogun

本記事では、このmulti-agent-shogunをAWS EC2上に移植し、常時稼働・リモートアクセス・自動復旧を実現するハンズオンを実践します。

1-2. システム構成（tmuxセッション・エージェント役割・通信方式）

tmuxセッション構成

multi-agent-shogunは2つのtmuxセッションで動作します。

multiagentセッションの内訳：

エージェント役割一覧

将軍・家老・軍師は意思決定に強いOpusを使用し、量的作業をこなす足軽はコスト効率の良いSonnetを使用します。これによりコストを抑えながら品質を維持します。

ファイルベース通信方式

各エージェントはClaude Code CLIとして動作し（claude --model opus/sonnet）、以下の3層構造でメッセージをやり取りします。

Layer 1: メッセージ書き込み（inbox_write.sh）

送信エージェントが bash scripts/inbox_write.sh <宛先> "<メッセージ>" <タイプ> <送信元> を実行します。flockによる排他制御で queue/inbox/{エージェント名}.yaml に安全に書き込みます。

Layer 2: ファイル監視（inbox_watcher.sh）

inotifywait がinboxファイルの変更を検知し、宛先エージェントのtmuxペインにNudge文字列（inbox1 等）を送信します。

Layer 3: メッセージ読み取り（エージェント本体）

エージェントはNudgeを受け取るとinboxファイルを読み込み、read: false のメッセージを処理して read: true に更新します。メッセージ本文はすべてファイル経由で伝達されるため、tmuxのペインバッファに機密情報が残りません。

この設計により、エージェント間の通信はすべてファイルシステムを通して行われ、tmuxセッションの状態（スクロールバッファ・コンソール表示）に依存しない堅牢なメッセージングを実現しています。

1-3. エージェント通信フロー図

上図は将軍から足軽へのコマンド伝達フローと、足軽から家老への報告フローを示しています。指揮系統（将軍→家老→足軽）と報告系統（足軽→軍師→家老）が明確に分離されています。

Section 2: なぜクラウドへ移行するのか

2-1. Mac Mini現状の課題

現在、multi-agent-shogunはMac Mini（Apple Silicon）上でローカル稼働しています。24時間×365日の自律稼働を目指すうえで、以下の課題があります。

特に電源断リスクは深刻です。tmuxセッションが消失すると、実行中のタスクがすべて失われ、エージェントの復旧には手動介入が必要になります。AIエージェントによる自律処理の継続性を損なう最大の課題です。

2-2. クラウド移行で得られるもの

AWS EC2への移行により、上記の課題をすべて解消できます。

EC2の自動復旧（Restart=always）により、万が一エージェントプロセスが異常終了しても30秒以内に自動再起動します。停電後もEC2が再起動すればsystemdが自動でエージェントを起動します。

2-3. 要件一覧（A〜L）

multi-agent-shogunをクラウドで稼働させるための要件を12項目に整理します。

Section 3: アーキテクチャ概要

本記事ではスタンダード構成（$50/月）を実践します。ミニマル構成（$40/月）との差分手順はSection 8で別途解説します。

3-1. 3構成パターン比較表

目的・予算・セキュリティ要件に応じて3つの構成パターンから選択できます。

このハンズオンではスタンダード構成（$50/月）を実践します。 ミニマル構成への切替差分はSection 8で解説します。

各パターンの推奨ケース：

• ミニマル（$40/月）: 個人利用・コスト最優先・外部アクセスが少ない場合
• スタンダード（$50/月）: 本番利用・セキュリティ重視・Grafana監視が欲しい場合
• フル（$115/月）: 10エージェント同時稼働・エンタープライズグレード・チーム利用

3-2. コンピュートオプション比較

EC2インスタンスタイプ比較:

t3系はバーストクレジットを消費し切ると性能が大幅低下します。Claude Code CLIは継続的にCPUを使うため、バースト制限のないm5系を推奨します。

EC2 Savings Plans（1年コミット）を購入すると月額が約40%割引になります。m5.largeは$70→$42（月$28節約、年$336節約）。長期稼働を前提とする場合は必ず検討してください。購入手順はSection 10で解説します。

ECS Fargate / LambdaがNGな理由:

Claude Code CLIは対話型ターミナル（pty）が必須のため、サーバーレスサービスは利用できません。EC2が最適解です。

他クラウドとの比較（参考）:

AWSが東京リージョンの安定性・AWSサービス連携（CloudWatch, Budgets, DLM等）で最優位です。

3-3. セキュリティ4パターン比較（K1〜K4）

ttydによるtmux Web UIは外部公開するため、適切な認証が必要です。4つのパターンを比較します。

K1: Nginx + Basic認証 + Let’s Encrypt（ミニマル構成用）

最もシンプルな構成。Nginxリバースプロキシ + htpasswdによるBasic認証 + certbotでTLS証明書を取得します。

• 長所: セットアップが最も簡単・追加コストゼロ・全クラウド対応
• 短所: Basic認証のセキュリティは限定的（パスワード漏洩リスク）・MFA不可・DDoS対策なし
• 適用: ミニマル構成、社内限定・個人開発サーバー

K2: Cloudflare Access（Zero Trust）+ Cloudflare Tunnel（スタンダード構成★推奨）

EC2からCloudflare EdgeへのアウトバウンドTunnelを確立します。インバウンドポートの開放が不要で、Cloudflare Accessで認証（Google/GitHubアカウント + MFA）します。

• 長所: ポート開放不要（SG完全閉鎖可能）・無料枠あり（50ユーザー）・MFA対応・DDoS防御付き
• 短所: Cloudflare依存（Cloudflareが落ちるとアクセス不可）・独自ドメインが必要
• 適用: スタンダード/フル構成推奨。本番サーバーの認証はこれを推奨

K3: AWS Cognito + ALB（フル構成用）

AWSネイティブのフルマネージド認証。ALBがOAuth2フローを処理し、Cognitoユーザープールで認証管理します。

• 長所: AWSネイティブ統合・MFA対応・ユーザー管理UI付き・企業ユースに対応
• 短所: AWS限定・ALBコスト（$16/月〜）・Cognitoセットアップが複雑
• 適用: フル構成（AWS予算$115/月）・企業ユース

K4: OAuth2 Proxy + GitHub/Google OAuth（K2代替）

oauth2-proxy（Go製）をNginxと組み合わせます。GitHub OrganizationやGoogle WorkspaceのIdPで認証制限が可能です。

• 長所: GitHub/Googleアカウントで認証・GitHub Org制限可・MFA対応（IdP側）
• 短所: セットアップやや複雑・外部IdP依存
• 適用: K2の代替（独自ドメインなし等の場合）

3-4. コスト試算表

インフラコスト一覧:

Claude API利用コスト試算（重要）:

インフラコストの見積もりだけでなく、Claude APIの利用コストを必ず計算してください。インフラより API費用が大幅に上回る場合があります。

Max plan（$200/月固定）との比較：

3-5. 全体アーキテクチャ図（スタンダード構成）

スタンダード構成の主要コンポーネントと役割：

通信フロー（ブラウザ → tmux）：

ブラウザ → Cloudflare Access（認証・MFA）→ Cloudflare Tunnel → EC2 Nginx（127.0.0.1:8080）→ ttyd（:7681）→ tmux multiagent

EC2のセキュリティグループはインバウンドを完全に閉鎖できます（Cloudflare Tunnelはアウトバウンド接続のみ使用）。

Section 4: スタンダード構成ハンズオン — Phase 1〜3（EC2起動〜環境構築〜multi-agent-shogunセットアップ）

4-0. ハンズオン全体フロー

本ハンズオンでは7つのPhaseに分けてスタンダード構成を構築します。各Phaseの内容と目安時間を以下に示します。

合計所要時間の目安は約85分です。AWS初心者の方は余裕を持って2〜3時間を確保することをおすすめします。

Section 4ではPhase 1〜3、Section 5ではPhase 4〜7を扱います。

4-1. Phase 1: EC2インスタンス起動

AWSコンソールからEC2インスタンスを起動します。

コンソール操作手順

1. AWSマネジメントコンソールにサインインし、リージョンを アジアパシフィック（東京）ap-northeast-1 に切り替えます
2. 検索バーに「EC2」と入力し、EC2コンソールを開きます
3. 左メニューの「インスタンス」→「インスタンスを起動」をクリックします

名前とタグ:
– Name: multi-agent-shogun

AMI（Amazonマシンイメージ）の選択:
– クイックスタートの「Amazon Linux」を選択
– AMI: Amazon Linux 2023 AMI（al2023-ami-2023.*-x86_64）を選択します
– アーキテクチャ: x86_64（Arm版ではなく通常版を選択）

インスタンスタイプの選択:
– インスタンスタイプ: m5.large（2vCPU, 8GB RAM）

キーペアの設定:
1. 「新しいキーペアの作成」をクリック
2. キーペア名: multi-agent-key
3. キーペアのタイプ: RSA
4. プライベートキーファイルの形式: .pem（Mac/Linux向け）
5. 「キーペアを作成」をクリック → .pemファイルが自動でダウンロードされます

ネットワーク設定:
1. 「編集」をクリックしてネットワーク設定を展開します
2. VPC: デフォルトVPC（vpc-xxxxxxxx）を選択
3. サブネット: 任意のアベイラビリティーゾーンを選択
4. パブリックIPの自動割り当て: 有効化
5. ファイアウォール（セキュリティグループ）: 「セキュリティグループを作成する」を選択
– セキュリティグループ名: multi-agent-sg
– 説明: Security group for multi-agent-shogun
6. インバウンドセキュリティグループのルール:
– タイプ: SSH、プロトコル: TCP、ポート: 22
– ソース: マイIP（自分のIPアドレスのみを許可）

ストレージ（ボリューム）の設定:
1. 「1x」ボリュームを展開します
2. ストレージのサイズ: 50 GiB
3. ボリュームタイプ: gp3

インスタンスの起動:
– 「インスタンスを起動」ボタンをクリックします
– 起動成功のメッセージが表示されたら「すべてのインスタンスを表示」をクリックします
– インスタンスのステータスが「実行中」になるまで待ちます（1〜2分程度）

SSH接続の確認

インスタンスが起動したら、SSH接続を確認します。

# ダウンロードしたキーファイルの権限を変更（Mac/Linux）chmod 400 ~/Downloads/multi-agent-key.pem# EC2インスタンスのパブリックIPアドレスを確認（コンソールで確認）# 以下のコマンドでSSH接続ssh -i ~/Downloads/multi-agent-key.pem ec2-user@<PUBLIC_IP>

接続成功すると以下のようなプロンプトが表示されます。

,  #_~\_  ####_  Amazon Linux 2023  ~~  \_#####\  ~~  \###| AL2023  ~~ \#/ ___~~ V~' '-> ~~~/~~._._/_/ _/ _/m/'[ec2-user@ip-xxx-xxx-xxx-xxx ~]$

4-2. Phase 2: 環境セットアップ

EC2インスタンスに必要なパッケージをすべてインストールします。

全パッケージの一括インストール

以下のコマンドをSSH接続したEC2インスタンスで実行します。

# システム更新（最初に必ず実行）sudo dnf update -y# 基本ツール一括インストールsudo dnf install -y git tmux jq curl wget unzip# inotify-tools（エージェント間通信の要）sudo dnf install -y inotify-tools

# Node.js 20.x（Claude Code CLI の依存）curl -fsSL https://rpm.nodesource.com/setup_20.x | sudo bash -sudo dnf install -y nodejs# Claude Code CLI（公式パッケージ）sudo npm install -g @anthropic-ai/claude-code# Docker（Grafana + Loki用）sudo dnf install -y dockersudo systemctl enable dockersudo systemctl start dockersudo usermod -aG docker ec2-user# ※ グループ変更を反映するにはSSH再接続が必要# docker-compose v2（プラグイン方式）sudo mkdir -p /usr/local/lib/docker/cli-pluginssudo curl -SL https://github.com/docker/compose/releases/latest/download/docker-compose-linux-x86_64 \  -o /usr/local/lib/docker/cli-plugins/docker-composesudo chmod +x /usr/local/lib/docker/cli-plugins/docker-compose# Nginx（リバースプロキシ）sudo dnf install -y nginx# ttyd（tmux Web UI）— GitHub Releasesからバイナリ取得TTYD_VERSION=$(curl -s https://api.github.com/repos/tsl0922/ttyd/releases/latest \  | python3 -c "import sys,json; print(json.load(sys.stdin)['tag_name'])")sudo curl -L "https://github.com/tsl0922/ttyd/releases/download/${TTYD_VERSION}/ttyd.x86_64" \  -o /usr/local/bin/ttydsudo chmod +x /usr/local/bin/ttyd

バージョン確認

インストールが完了したら、各コンポーネントのバージョンを確認します。

node --version  # v20.x.xclaude --version# Claude Code x.x.xttyd --version  # ttyd/x.x.xdocker --version# Docker version 25.x.xdocker compose version  # Docker Compose version v2.x.xtmux -V# tmux 3.xinotifywait --help # inotify-tools のバージョン確認（--help でエラーなければOK）git --version# git version 2.x.x

4-3. Phase 3: multi-agent-shogunセットアップ

GitHubからリポジトリをcloneし、multi-agent-shogunを設定します。

GitHub SSH鍵の設定

# SSH鍵を生成（パスフレーズなし）ssh-keygen -t ed25519 -C "ec2-multi-agent" -f ~/.ssh/id_ed25519 -N ""# 公開鍵を表示cat ~/.ssh/id_ed25519.pub

表示された公開鍵（ssh-ed25519 AAAA...で始まる文字列）をコピーし、GitHubに登録します。

GitHubへの登録手順:
1. GitHub.com → 右上のアバター → Settings
2. 左サイドバー → SSH and GPG keys → 「New SSH key」
3. Title: ec2-multi-agent、Key type: Authentication Key
4. Key: コピーした公開鍵を貼り付け → 「Add SSH key」

SSH接続の確認:

ssh -T git@github.com# "Hi username! You've successfully authenticated." が表示されれば成功

リポジトリのcloneと設定

# multi-agent-shogunリポジトリをclonegit clone git@github.com:yohey-w/multi-agent-shogun.git ~/multi-agent-shoguncd ~/multi-agent-shogun# ディレクトリ構造を確認ls -la

設定ファイルの確認・編集:

# 設定ファイルを開くvi config/settings.yaml

主な設定項目:

# config/settings.yaml の主要設定（例）agents:  ashigaru_count: 7 # 足軽エージェント数（環境に応じて調整）notification:  ntfy_url: "https://ntfy.sh/your-topic"  # ntfy通知先URLscreenshot:  path: "/home/ec2-user/screenshots"

動作テスト（手動起動）

systemdに登録する前に、手動でtmuxセッションを起動してClaude Code CLIが動作するか確認します。

# Claudeのバージョン確認claude --version# tmuxセッション手動起動テストtmux new-session -d -s test -x 220 -y 50tmux send-keys -t test "echo 'multi-agent-shogun OK'" Entersleep 2tmux capture-pane -t test -p# "multi-agent-shogun OK" が出力されれば成功tmux kill-session -t test

Claude Code CLIの認証確認:

# Claude Code CLIの認証状態を確認# （初回はブラウザ認証またはAPIキー設定が必要）claude --dangerously-skip-permissions --version

Section 5: スタンダード構成ハンズオン — Phase 4〜7（systemd・ttyd/Nginx・Cloudflare Tunnel・Grafana/Loki）

5-1. Phase 4: systemdサービス登録

EC2インスタンスの起動時にmulti-agent-shogunが自動起動するよう、systemdサービスとして登録します。

multi-agent.serviceの作成

# systemdユニットファイルを作成sudo vi /etc/systemd/system/multi-agent.service

以下の内容を入力します:

[Unit]Description=Multi-Agent Shogun SystemAfter=network.targetWants=network.target[Service]Type=forkingUser=ec2-userWorkingDirectory=/home/ec2-user/multi-agent-shogunEnvironment=ANTHROPIC_API_KEY=sk-ant-xxxxxEnvironment=HOME=/home/ec2-userEnvironment=PATH=/usr/local/bin:/usr/bin:/binExecStart=/home/ec2-user/multi-agent-shogun/scripts/start_agents.shExecStop=/usr/bin/tmux kill-session -t multiagentRestart=alwaysRestartSec=30TimeoutStartSec=60[Install]WantedBy=multi-user.target

ttyd.serviceの作成

ttydをsystemdサービスとして登録し、multi-agent.service起動後に自動起動させます。

sudo vi /etc/systemd/system/ttyd.service

[Unit]Description=ttyd Web Terminal for tmuxAfter=network.target multi-agent.serviceWants=multi-agent.service[Service]Type=simpleUser=ec2-userEnvironment=HOME=/home/ec2-userExecStartPre=/bin/sleep 5ExecStart=/usr/local/bin/ttyd -W -p 7681 tmux attach -t multiagentRestart=alwaysRestartSec=10[Install]WantedBy=multi-user.target

サービスの有効化と起動

# systemdの設定をリロードsudo systemctl daemon-reload# 両サービスを自動起動に設定sudo systemctl enable multi-agent.service ttyd.service# multi-agent.serviceを先に起動sudo systemctl start multi-agent.service# tmuxセッション生成を待つ（30秒）sleep 30# ttyd.serviceを起動sudo systemctl start ttyd.service# 状態確認sudo systemctl status multi-agent.servicesudo systemctl status ttyd.service# ログ確認journalctl -u multi-agent.service -n 50journalctl -u ttyd.service -n 20

5-2. Phase 5: ttyd + Nginx設定

ttydをNginxのリバースプロキシ経由で公開します。この段階では内部（localhost）への接続のみ許可し、外部アクセスはPhase 6のCloudflare Tunnel経由に限定します。

Nginx設定ファイルの作成

sudo vi /etc/nginx/conf.d/ttyd.conf

server { listen 80; server_name _; location / {  proxy_pass http://127.0.0.1:7681;  proxy_http_version 1.1;  proxy_set_header Upgrade $http_upgrade;  proxy_set_header Connection "upgrade";  proxy_set_header Host $host;  proxy_set_header X-Real-IP $remote_addr;  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  proxy_read_timeout 43200s;  proxy_send_timeout 43200s; }}

Nginxの起動と確認

# デフォルト設定との競合を避けるため削除sudo rm /etc/nginx/conf.d/default.conf 2>/dev/null || true# 設定ファイルの構文チェックsudo nginx -t# nginx: configuration file /etc/nginx/nginx.conf test is successful# Nginxを自動起動に設定して起動sudo systemctl enable nginxsudo systemctl start nginx# 動作確認（ローカルからHTTPリクエスト送信）curl -s -o /dev/null -w "%{http_code}" http://localhost/# 200 または 101 が返れば成功

5-3. Phase 6: Cloudflare Tunnel + Access設定

Cloudflare TunnelでEC2からCloudflare Edgeへのアウトバウンドトンネルを確立し、Cloudflare Accessで認証を設定します。EC2のセキュリティグループにポートを開放する必要はありません。

前提条件:
– Cloudflareアカウント（無料）
– Cloudflareに登録済みのドメイン（例: yourdomain.com）

cloudflaredのインストール（Amazon Linux 2023）

# cloudflared RPMパッケージを直接インストールsudo dnf install -y https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-x86_64.rpm# バージョン確認cloudflared --version# cloudflared version 2024.x.x

Cloudflare DashboardでTunnelを作成

1. Cloudflare Dashboard（dash.cloudflare.com）にログイン
2. 左サイドバー → Zero Trust をクリック
3. Networks → Tunnels → 「Create a Tunnel」 をクリック
4. コネクタの選択: 「Cloudflared」 を選択 → 「Next」
5. Tunnel名: multi-agent-tunnel と入力 → 「Save Tunnel」
6. 「Install and run a connector」画面で 「Debian」 または 「Red Hat」 を選択し、表示されるトークン（eyJxxx...形式の長い文字列）をコピーします

EC2にTunnelサービスを登録

# コピーしたトークンを使ってsystemdサービスとしてインストールsudo cloudflared service install <TUNNEL_TOKEN># <TUNNEL_TOKEN> をコピーしたトークンに置き換え# サービスの有効化と起動sudo systemctl enable cloudflaredsudo systemctl start cloudflaredsudo systemctl status cloudflared# Active: active (running) が表示されれば成功

ホスト名の設定（Cloudflare Dashboard）

1. Tunnels一覧 → 作成したTunnel multi-agent-tunnel → 「Configure」 をクリック
2. 「Public Hostname」 タブ → 「Add a public hostname」 をクリック
3. 以下の設定を入力:
4. Subdomain: agent
5. Domain: プルダウンからあなたのドメインを選択
6. Service Type: HTTP
7. URL: localhost:80
8. 「Save hostname」 をクリック

これで https://agent.yourdomain.com がEC2のlocalhost:80（Nginx → ttyd）に転送されます。

Cloudflare Access（Zero Trust認証）の設定

1. Zero Trust → Access → Applications → 「Add an application」
2. Type: 「Self-hosted」 を選択
3. 以下を入力:
4. Application name: Multi Agent Shogun
5. Application domain: agent.yourdomain.com
6. 「Next」 をクリック
7. ポリシーの設定:
8. Policy name: Allow Owner
9. Action: Allow
10. Include: Emails → テキストボックスにあなたのメールアドレスを入力
11. 「Next」 → 「Add application」 をクリック

セキュリティグループの全閉鎖

Cloudflare Tunnelが正常に動作していることを確認したあと、EC2のセキュリティグループからSSH(22)を削除します。

1. EC2コンソール → セキュリティグループ → multi-agent-sg を選択
2. 「インバウンドルール」 タブ → 「インバウンドのルールを編集」
3. SSH(22)のルール行にある 「削除」 をクリック
4. 「ルールを保存」 をクリック

動作確認

# cloudflared接続状態の確認sudo systemctl status cloudflared# HEALTH CHECK に "healthy" が表示されれば成功# ブラウザで以下にアクセス# https://agent.yourdomain.com# → Cloudflare Accessのメールアドレス入力画面# → メールアドレス入力 → ワンタイムコードがメールに届く# → コード入力 → tmuxターミナルが表示される

5-4. Phase 7: Grafana + Loki + Promtail（Docker Compose）

Grafana + Loki + Promtailを使い、エージェントのログをリアルタイムで可視化します。

docker-compose.ymlの作成

mkdir -p ~/multi-agent-shogun/monitoringcd ~/multi-agent-shogun/monitoringvi docker-compose.yml

version: '3.8'services:  loki: image: grafana/loki:2.9.0 ports:- "127.0.0.1:3100:3100" volumes:- loki-data:/loki command: -config.file=/etc/loki/local-config.yaml restart: unless-stopped  promtail: image: grafana/promtail:2.9.0 volumes:- /home/ec2-user/multi-agent-shogun/queue:/queue:ro- /var/log:/var/log:ro- ./promtail-config.yml:/etc/promtail/config.yml:ro command: -config.file=/etc/promtail/config.yml restart: unless-stopped depends_on:- loki  grafana: image: grafana/grafana:10.2.0 ports:- "127.0.0.1:3000:3000" volumes:- grafana-data:/var/lib/grafana environment:- GF_AUTH_ANONYMOUS_ENABLED=false- GF_SECURITY_ADMIN_PASSWORD=changeme_strong_password restart: unless-stopped depends_on:- lokivolumes:  loki-data:  grafana-data:

promtail-config.ymlの作成

vi ~/multi-agent-shogun/monitoring/promtail-config.yml

server:  http_listen_port: 9080  grpc_listen_port: 0positions:  filename: /tmp/positions.yamlclients:  - url: http://loki:3100/loki/api/v1/pushscrape_configs:  - job_name: multi-agent-queue static_configs:- targets: - localhost  labels: job: multi-agent __path__: /queue/reports30 * * * * /home/ec2-user/multi-agent-shogun/scripts/auto_backup.sh# 1時間ごとにシステムメトリクス記録（オプション）0 * * * * /home/ec2-user/multi-agent-shogun/scripts/collect_metrics.sh

バックアップ設定を確認します。

crontab -l # cron設定確認tail -f /var/log/multi-agent-backup.log  # バックアップログ確認

Section 10: コスト最適化・今後の展望・まとめ

10-1. Savings Plans適用手順（EC2コスト約40%削減）

m5.largeの通常料金は約$70/月（オンデマンド）です。Compute Savings Plans（1年コミット）を適用することで約40%削減できます。

※ 実際の割引率はリージョンとインスタンスファミリーにより異なります。

AWSコンソールでの購入手順：

1. Cost Management → Savings Plans → 「Purchase Savings Plans」をクリック
2. Savings Plans type: Compute Savings Plans（インスタンスタイプ変更にも対応する柔軟なプラン）
3. Term: 1 year
4. Payment option: No upfront（前払いなし）
5. Hourly commitment: 0.096（m5.largeの1時間料金を入力）
6. 「Purchase」をクリック

10-2. Claude APIコスト最適化

インフラコスト（$50/月）より、Claude APIの利用コストのほうがはるかに大きくなります。

コスト最適化の主な施策：

• Sonnet優先使用: Opus比で1/5のコスト。意思決定が必要なshogunのみOpusを使用
• Prompt Caching: 同一システムプロンプトのキャッシュにより最大90%削減
• Max planとの比較: 月間利用量が少ない場合はMax plan（$200/月）のほうが有利な場合もある

10-3. 今後の展望

自己改善・拡張

• HedgeDoc / Outline: チーム向けナレッジベース統合。エージェントが生成したドキュメントをチームで共有
• code-server: ブラウザからVS Codeでエージェントコードを直接編集（ttydと並行運用）
• 複数EC2での分散実行: エージェント数を32→64へ拡張。shogunインスタンスとashigaruインスタンスを分離

マルチクラウド対応

• Hetzner Cloud CAX31: ARM, €14/月。最安クラウド選択肢（ただしAWSサービスは利用不可）
• GCP Cloud VM: 東京リージョンでレイテンシは優秀だが、料金はAWSとほぼ同等
• Azure VM: EntraID統合でエンタープライズ認証を実現

10-4. まとめ

このハンズオンで構築したスタンダード構成の全体像を振り返ります。

構築したもの

3構成パターンの選び方：

スタンダード構成で得られるもの：

• 常時稼働: systemd + EC2 Auto Recoveryによる自動再起動
• どこからでもアクセス: ttydでブラウザからtmux操作（Cloudflare Access認証付き）
• ログ・メトリクス可視化: Grafana + Lokiでエージェントの動作を可視化
• 自動バックアップ: GitHub自動push + EBSスナップショットの二重化
• Zero Trustセキュリティ: 全ポート閉鎖・Cloudflare Access認証

まずスタンダード構成からスタートし、必要に応じてフル構成へスケールアップすることをお勧めします。

運用開始後のチェックリスト

10-5. 参考リンク