API-firstなインフラが生き残る：LLM時代のセルフホスト戦略

概要#

REST APIがあるかどうかが、インフラツールの選定基準として重要度を増した
AIエージェントから操作できないインフラは、手動オペレーションのコストが相対的に上がる
セルフホストの世界では、API-firstなOSSが生き残る

このシリーズの最終回。第1回から第4回まで、Coolify + Cloudflare Tunnelで自宅サーバにPaaS環境を構築してきました。ここでは「なぜ今セルフホストなのか」を、LLMとAPIの文脈から考えます。

Coolifyシリーズの振り返り#

5回にわたって書いてきたことの全体像。

回	テーマ	要点
第1回	選定理由	Vercel月額$42→$0。Coolify一択だった
第2回	インストール & MCP	GUIで10分→プロンプト4分
第3回	ハンズオン	3つのビルドパックを実際に体験
第4回	ネットワーク	Cloudflare Tunnelでポート開放なし公開
第5回	戦略	API-firstがインフラ選定を変える（この記事）

個別のHowToは前の4回で書いた。ここでは「なぜ」と「これから」の話をします。

APIがインフラ選定の基準を変える#

従来の選定基準#

インフラツールを選ぶとき、これまでの判断基準はこんな感じだった。

機能が要件を満たすか
コスト（ライセンス、運用コスト）
学習コスト
コミュニティの活発さ
ベンダーロックイン

新しい基準：AI操作可能性#

2025年以降、ここに**「AIエージェントから操作できるか」**が加わった。具体的には：

REST APIがあるか？ → AIエージェントがツールを操作する大前提
操作の粒度は十分か？ → 作成・更新・削除・デプロイが一通りAPIでできるか
APIドキュメントが整備されているか？ → LLMが使い方を理解できるか

REST APIさえあれば、AIエージェントは直接APIを叩けるし、MCPのようなラッパーを介した操作も可能。本質はAPIの有無であって、特定のプロトコルへの対応ではない。

第2回で実際にやったけど、WordPressの構築（DB作成→アプリ作成→環境変数→デプロイ→テーマ設定→記事投入）がプロンプト2回で完了した。GUIだと15分、Terraformで書くなら30分はかかる作業。

この差は、サービスが1個なら大したことない。でも20個、30個のサービスを運用していると、積算の差が巨大になる。

API対応状況の現在地#

2026年3月時点で、主要なインフラツールのAPI対応状況。

ツール	REST API	AI連携	備考
Coolify	REST API完備	MCP、直接API呼び出し	コミュニティMCPあり
Cloudflare	公式API	MCP、Wrangler CLI	Workers, KV, D1等
AWS	公式API	MCP、AWS CLI、SDK	CDK, CloudWatch等
Terraform	HCL + CLI	MCP、直接CLI	plan/apply連携
GitHub	REST / GraphQL	MCP、gh CLI	Issue, PR, Actions
Vercel	REST API あり	直接API呼び出し	MCPなしでもAPI経由で操作可能
Kubernetes	kubectl / API	直接API、CLI	豊富なエコシステム

注目すべきは、REST APIがあればAIエージェントとの連携方法は複数あること。MCPはその一つに過ぎない。第2回の余談で書いたけど、MCPサーバーのソースコードを見ると、やっていることはAPIのラッパーに過ぎない。MCPはAPI設定を簡略化するレイヤーであって、本質はREST APIの存在そのもの。

逆に言えば、REST APIがないツールはAIエージェントとの連携が構造的にできない。GUIオンリーのツールは、AIエージェント時代に取り残される。

MCPの立ち位置と限界#

MCPは便利だけど、過度に持ち上げるべきではない。

MCPの利点：

API接続のセットアップが簡単（claude mcp add 一発）
ツール定義がAIに自動で渡される

MCPの限界：

コンテキストウィンドウを圧迫する。 MCPで接続したツール定義はすべてコンテキストに載る。MCPサーバーを5個、10個と追加すると、それだけでトークンを消費してしまう
REST APIを直接叩けるAIエージェントなら、MCPなしでも同等のことができる
MCPサーバーの品質はまちまち。APIドキュメントを直接読んだ方が確実なケースもある

結論：MCPはAPI-firstの恩恵を受けやすくする便利なレイヤーだが、本質はREST APIの有無。 APIがあればMCPがなくても困らない。

「手動オペレーション税」の概念#

AIエージェントが使えないインフラを運用し続けることは、毎回「手動オペレーション税」を払い続けることになる。

操作	API対応ツール（AI活用）	APIなしツール
新サービスのデプロイ	プロンプト1つ（2分）	GUIで10分
環境変数の一括設定	プロンプト1つ（1分）	1つずつ手入力（5分）
develop環境の複製	プロンプト1つ（4分）	手順書を見て再現（20分）
DB接続設定	AIが自動判定（0分）	接続文字列をコピペ（3分）
監視ツール構築	プロンプト1つ（10分）	ドキュメント読んで設定（1時間）

1回1回の差は小さくても、20サービス×月に数回のオペレーション×12ヶ月で考えると、年間で数十時間の差になる。個人開発者にとって、この時間は新しいサービスを作る時間に充てられる。

セルフホストとLLMの相性#

なぜセルフホストが有利なのか#

LLMを活用したサービスを作る場合、セルフホストには構造的な優位性がある。

1. リソースの制約がない

クラウドPaaSでは、LLM推論に必要なメモリやCPUがプランの上限に引っかかる。第3回でOllama + Rails + PostgreSQL + Redisの4コンテナをDocker Composeでデプロイしたけど、これをVercelやfly.ioでやると従量課金が跳ねる。自宅サーバなら、32GBのRAMを好きなだけ使える。

2. プロトタイプの公開が即座にできる

LLMを使った新しいアイデアを思いついたら、Claude Codeに「このアプリをCoolifyにデプロイして」と言うだけで外部公開できる。Cloudflare TunnelでSSLもCDNも自動。友人やチームメンバーにURLを共有してフィードバックをもらえる。

クラウドPaaSだと「まず料金を確認して」「プランを選んで」「クレカ情報を入れて」。。。プロトタイプの段階でこの摩擦は致命的。

3. データが手元にある

LLMアプリは大量のユーザーデータを扱うことが多い。トレーニングデータ、会話履歴、生成結果。これを外部のクラウドに置くと、プライバシーの問題が出てくる。セルフホストなら全部自分のSSDの中。

AIエージェントが加速するセルフホスト#

AIエージェント（Claude Code等）の登場で、セルフホストの最大の弱点だった**「運用の面倒さ」が大幅に軽減**された。

従来のセルフホストは「自分で全部やる」が前提で、DevOpsの知識が必要だった。でも今は「AIに頼む」でほとんどの運用タスクが完結する。REST APIがあるツールなら、AIが直接APIを叩いて操作してくれる。

従来: ドキュメントを読む → 設定ファイルを書く → テスト → 本番適用 → 監視
AI:  「〜を設定して」→ AIがAPIで全部やる → 結果を確認

第2回でZabbixの構築に10分、MariaDBのチューニングに5分かかった程度。手動だったら各1時間以上かかる作業。この効率化が、セルフホストのハードルを劇的に下げている。

「GUIの良さ」は残る#

ここまでMCPとCLIの話をしてきたけど、GUIが不要になるわけではない。

GUIが向いている場面：

現在の状態を俯瞰的に把握する（ダッシュボード、メトリクス）
視覚的な確認が必要な操作（ログのスクロール、グラフの確認）
初めて触るツールの学習（何ができるかを探索する）

AIエージェント（API経由）が向いている場面：

繰り返しの操作（デプロイ、環境変数設定、DB作成）
複数ステップの自動化（プロジェクト作成→DB→アプリ→環境変数→デプロイ）
既知のタスクの実行（やりたいことが明確で、手順がわかっている）

CoolifyにはGUIもREST APIもある。状況に応じて使い分けられるのが理想で、「API対応だからGUIは不要」ではない。両方あるツールが強い。

これからのインフラ選定#

個人開発者として、今後インフラツールを選ぶときの基準をまとめておきます。

必須条件#

REST APIが充実している（AI連携の土台）
セルフホスト可能（コスト制御とデータ主権）
Dockerベース（ポータビリティ、ベンダーロックインなし）
OSSである（透明性、コミュニティ、将来性）

強い加点#

APIドキュメントが充実している（AIが使い方を理解しやすい）
GitHub App連携（Push to Deploy）
CDN/Tunnel対応の容易さ（Cloudflare Tunnel等）

これから淘汰されるもの#

GUIオンリーでAPIがないツール
SaaS専用でセルフホストできないツール
独自プロトコルでDockerと相性が悪いツール

厳しい言い方だけど、REST APIがないインフラツールは今後AIエージェントと連携できない。APIを後付けするのはアーキテクチャレベルの改修になる。API-firstで設計されていないツールは、構造的にAIエージェント時代に適応できない。

まとめ#

5回にわたって、Coolify + Cloudflare Tunnel + Claude Codeの組み合わせで自宅サーバにPaaS環境を構築する話を書きました。

シリーズで得たもの	コスト
Vercel相当のデプロイ体験	$0
CDN + WAF + DDoS対策	$0
AIエージェントによるインフラ操作	$0
無制限のサービスデプロイ	$0
PRプレビュー環境	$0
LLMプロトタイプの即時公開基盤	$0

全部タダ。必要なのは、Dockerが動くサーバ1台と、Cloudflareの無料アカウントと、Claude Codeだけ。

LLMの時代に「インフラをどう管理するか」の答えは、**「AIに頼む」**だと思っています。そのためには、AIが操作できるインフラを選ぶ必要がある。Coolifyはその条件を満たしている数少ないOSSの一つ。

自宅にサーバがあるなら、Coolifyを入れない理由がない。

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

シリーズ記事#

Vercel月額$42→自宅サーバ月額$0。Coolifyで個人サービス基盤を作った話
Coolifyインストールから「プロンプトでデプロイ」まで：Claude Code MCP実践
Coolifyハンズオン：Hono・Go・Railsを実際にデプロイしてみる
Cloudflare Tunnel×Coolify：自宅サーバを安全に外部公開する
API-firstなインフラが生き残る：LLM時代のセルフホスト戦略（この記事）
ZabbixでDockerコンテナをリソース監視する：Coolify環境の可視化
Coolify環境のバックアップ戦略：6つのDBを自動ダンプ+復旧手順
Coolify環境のログ管理と障害対応：Docker + Zabbix + Discordで運用を回す