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で運用を回す