社内向けにAIエージェント基盤を自前ホスティングしたいと考えているインフラ担当者やアーキテクトに向けて、公開されているデプロイ事例をもとに設計判断の勘所を整理します。
AIエージェント基盤とは、複数のAIモデルを呼び出して自動でタスクをこなすソフトウェアの実行環境のことです。オープンソースのオーケストレーション（複数コンポーネントを協調動作させる仕組み）基盤であるPaperclipを、Oracle Cloud Infrastructure（OCI、Oracleのクラウドサービス）のARM64 VPS上にCoolify（セルフホスト型のPaaS的デプロイ管理ツール）で構築する事例が公開されています。この構成は、単なる手順書としてだけでなく、非機能要件をどう積み上げているかという観点で読むと学びが多い内容です。
何が構成されていて、なぜ注目に値するか
この事例の構成要素は、Ubuntu上で動くCoolify、コンテナランタイムのDocker、リバースプロキシのTraefik、TLS証明書自動発行のLet's Encrypt、データベースのPostgreSQL 17、そしてAIモデルへのゲートウェイとなるOpenRouterという組み合わせです。
リバースプロキシとは、外部からのリクエストを受け取り、内部の適切なコンテナに振り分けるソフトウェアです。Traefikはコンテナの起動・停止を検知して自動でルーティング設定を更新する点が特徴で、Coolifyのようなデプロイ管理ツールと相性がよく設計されています。
注目すべきは、この構成が特別なマネージドサービス（クラウド事業者が運用まで請け負うサービス）に依存していない点です。データベースもTLS終端もすべて自前のVPS上で完結しています。これは低コストで始められる一方、可用性やセキュリティの責任がすべて運用者側に移る、というトレードオフを意味します。
技術的な仕組みを段階的に見る
ネットワーク境界の二重防御
構成では、OCIのVCN（Virtual Cloud Network、仮想プライベートネットワーク）のセキュリティリストと、Ubuntu上のiptables（Linuxカーネルのパケットフィルタリング機能）という2つのレイヤーで通信制御をしています。
VCNのセキュリティリストはクラウド側のファイアウォールで、80番・443番ポート（HTTPとHTTPS）への通信をソースCIDR 0.0.0.0/0（すべての送信元）から許可する設定です。一方でホストOS側のiptablesでも同じポートを明示的にACCEPTする必要があります。
これは冗長に見えますが、実際には防御の階層化（defense in depth）という考え方に沿っています。クラウド側の設定ミスがあってもホスト側で弾ける、逆にホスト側の設定が壊れてもクラウド側で境界を保てる、という二段構えです。ただしOracle標準のUbuntuイメージには元から強めのiptablesルールが入っていることがあり、既存ルールを確認せずに追記すると意図しない全面遮断や、逆に想定外の開放が起きる可能性があります。
秘密情報管理の最低ライン
アプリケーションのシークレット生成には openssl rand -hex 32 を使い、32バイトのランダムな16進文字列を作る手順が示されています。これはセッション鍵や暗号化キーとして使われる典型的な生成方法です。
重要なのは、サンプルのパスワードやAPIキー、ドメイン名をそのまま使わず必ず置き換えること、そしてGitにシークレットをコミットしないことが明示されている点です。これは基本的な注意に見えますが、自前ホスティングでは特に軽視できません。マネージドサービスならクラウド事業者がシークレット管理基盤（AWS Secrets ManagerやHashiCorp Vaultなど）を提供してくれますが、VPS上で完結する構成ではその責任も運用者が負うことになります。
SSL終端とデータベースの配置
Let's EncryptによるSSL証明書の自動発行は、HTTP-01チャレンジ（80番ポートでの検証）を使う想定です。そのため80番ポートを塞いでしまうと証明書の自動更新が止まり、気づかないうちにサイトがHTTPS警告を出す事故につながります。
PostgreSQL 17 Alpineは同じDocker Compose構成内でコンテナとして動いています。Alpineは軽量なLinuxディストリビューションで、イメージサイズを抑えられる一方、依存ライブラリの差異による互換性問題が稀に起きることもあります。データベースが同一VPS上にあるということは、VPSそのものが単一障害点（SPOF、Single Point of Failure）になっていることも意味します。
背景・関連技術との比較
Coolifyは、Herokuのような体験をセルフホストで実現しようとするOSSのPaaS（Platform as a Service）です。似た立ち位置のツールにはDokkuやCapRoverがありますが、CoolifyはTraefikとの統合やDocker Composeベースのリソース管理を前面に出している点が特徴です。
日本の開発現場でいえば、社内向けの小〜中規模ツールをAWS ECSやKubernetesでフル構築するほどではないが、単一のVPSにdocker-composeだけ置くのも心もとない、という中間規模のニーズにCoolifyははまりやすいポジションです。実際、マネージドKubernetesを使う場合と比べて学習コストは低く抑えられますが、その分オートスケーリングやゾーン冗長化のような可用性機能は自分で組み込む必要があります。
ARM64アーキテクチャを選んでいる点も見逃せません。OCIのAmpere A1インスタンスは無料枠でも一定量のARM64コンピュートを利用できることで知られており、コスト最適化の観点で選ばれることが多い構成です。ただしコンテナイメージがARM64に対応しているかどうかは事前確認が必須です。ghcr.io/paperclipai/paperclip:latest のようなマルチアーキ対応イメージであれば問題ありませんが、x86_64専用でビルドされたイメージを使うプロジェクトの場合は起動時にエラーになります。
読者への影響と、今日確認できること
自組織でこの種の構成を検討する場合、以下の点を順に確認すると判断がしやすくなります。
- VCNのセキュリティリストとホストOSのファイアウォール設定が二重に必要であることを認識し、
sudo iptables -L INPUT -n --line-numbersで現状のルールとACCEPT/REJECT/DROPの順序を確認する - DNSのAレコードがVPSのパブリックIPを指しているか
nslookupまたはdigで検証する - シークレットの生成・保管方法を確認し、
.envファイルなどがGitの管理対象外（.gitignore）に入っているか点検する - データベースを含む全コンポーネントが単一VPSに同居している場合、そのVPSが落ちたときの復旧手順（バックアップの有無・頻度）を明文化しているか確認する
- コンテナイメージがARM64・x86_64のどちらに対応しているか、利用予定のVPSアーキテクチャと一致しているかレジストリのタグ情報で確認する
特にバックアップ体制は見落とされがちです。PostgreSQLがDockerボリュームとしてローカルディスクに永続化されている場合、VPS自体の障害やディスク破損がそのままデータ消失につながります。定期的なpg_dumpの外部保管や、OCIのブロックボリュームスナップショット機能の活用を検討する価値があります。
まとめ
Coolifyを使ったAIエージェント基盤の自前ホスティングは、マネージドサービスに頼らず低コストで始められる魅力的な選択肢です。
ただしVCNとホストOSの二重ファイアウォール設定、シークレット管理の徹底、データベースを含む単一障害点の把握という3点は、導入前に必ず点検しておきたいところです。
次の一歩としては、まず自組織の既存VPSやVCN設定で iptables -L を実行し、80番・443番ポートの扱いを確認するところから始めてみてください。あわせてバックアップ方針を文書化しておくと、後々の運用が楽になります。