DBもAIも、
compose ファイル1枚に載せる。

「データベースが必要になったら?」「ローカルLLMも組み合わせられる?」——答えは両方YES。鍵は Docker Compose です。アプリ・DB・LLM をひとつの設計図(compose.yaml)にまとめれば、余りPCでも、iMacでも、クラウドでも、同じコマンド1発で同じ環境が立ち上がります。

✓ 可能です。むしろ Docker 化することで「どこでも動く・機密も守れる」構成になります

A-1 / CONCEPT

Docker Compose =「1枚の組立図」

機械設計でいえば、compose.yaml は部品表つきの組立図。アプリ・DB・LLMという「部品」を並べて書けば、docker compose up の1コマンドで全部品が組み上がります。

# compose.yaml — アプリ+DB+ベクトルDB+ローカルLLM の最小構成例 services: app: # FastAPI などのアプリ本体 build: . ports: ["8000:8000"] environment: DB_URL: postgresql://user:pass@db:5432/app LLM_BASE_URL: http://ollama:11434/v1 # OpenAI互換API db: # リレーショナルDB image: postgres:16 volumes: [pgdata:/var/lib/postgresql/data] # データ永続化 qdrant: # RAG用ベクトルDB(必要なら) image: qdrant/qdrant volumes: [qdata:/qdrant/storage] ollama: # ローカルLLM(必要なら) image: ollama/ollama volumes: [models:/root/.ollama] volumes: { pgdata:, qdata:, models: }

FIG. 1 — 同じ compose が、どの置き場所でも動く

ポイント:Cloud Run のようなサーバーレスはDBやLLMを同居させにくいのに対し、「VM/PCの上にComposeで全部載せ」はデータもAIも1箇所に閉じる構成。機密データを扱うPoCと相性抜群です。

B-1 / DATABASE

データベースはどう選ぶ?

「コンテナで同居させる」か「マネージドサービスに任せる」かの2択。判断軸はデータの置き場所(機密性)と運用の手間です。

選択肢	向いている場面	費用感	メモ
SQLite ファイル1個のDB	単独ユーザーの小さなPoC、ツール類	0円	コンテナすら不要。ファイルごとバックアップできる手軽さ。まずはここから
PostgreSQL コンテナ同居	複数ユーザーの業務アプリ、機密データを社内/手元に置きたい場合	0円(電気代のみ)	volume で永続化+定期バックアップを必ずセットにcompose に1ブロック足すだけ
Supabase / Neon マネージドPostgres	Cloud Run 等サーバーレスと組む場合、運用を持ちたくない場合	無料枠〜	認証・ストレージ付き(Supabase)。バックアップも任せられる無料枠の休止条件は要確認
Firestore NoSQL	GCPで完結させたい、スキーマが流動的なPoC	無料枠〜従量	Cloud Run との組み合わせ実績が多く、スケールtoゼロ思想と好相性
Qdrant / Neo4j ベクトル / グラフ	RAG・ナレッジグラフ系のAI PoC	0円(コンテナ)〜	どちらも公式イメージでコンテナ同居OK。ローカルLLMと組めば完全閉域RAGに

迷ったら:PoC は SQLite → ユーザーが増えたら Postgres コンテナ → クラウド常用なら Supabase/Firestore、と段階的に乗り換えるのが低リスク。SQLAlchemy 等のORM経由で書いておくと、乗り換え時のコード修正が最小で済みます。

C-1 / LOCAL LLM

ローカルLLMの組み込み方

Ollama などのローカルLLMは「OpenAI互換API」として振る舞うため、アプリから見れば接続先URLがひとつ増えるだけ。クラウドAIと差し替え可能な部品として設計できます。

FIG. 2 — 完全閉域RAG構成(データが1歩も外に出ないAIアプリ)

これが効く場面:「図面・原価・顧客情報をAIに読ませたいが、クラウドには絶対出せない」というケース。製造業のDX PoCでは最強の提案カードになります。デモで「ネットを切っても動きます」と見せられるのは強い。

ローカルLLM(Ollama / LM Studio / MLX)が向く処理

機密文書のRAG・要約・分類 — データを外に出せない案件
埋め込み(Embedding)生成 — 大量処理でもAPI代ゼロ
定型的な抽出・整形 — 小さめモデルで十分な仕事
目安: 7B〜14B級ならメモリ16〜32GBのPCで実用圏
(Apple Silicon は MLX / Ollama と好相性)

クラウドAI(Claude API 等)に残す処理

複雑な推論・コード生成 — 品質がまだ段違い
長文の高度な読解・エージェント処理
機密部分をマスキング・抽象化してから渡す設計に
接続先URLの切り替えだけで両者を使い分けられるよう、OpenAI互換のインターフェースに統一しておくのがコツ

ハイブリッド戦略:「機密に触る前処理はローカル、頭脳が要る部分はクラウド」の役割分担が現実解。LangChain 等で書いておけば、base_url を変えるだけでモデルを差し替えられます。

D-1 / CAUTIONS

運用前の3つの確認

DBとLLMを自前で持つと「守るもの」が増えます。この3点だけは構築時にセットで仕込んでおきましょう。

CHK-1

バックアップは初日に自動化するコンテナのDBは volume が消えたら終わり。pg_dump の定期実行+別ストレージ(クラウド or 別ドライブ)への退避を、アプリを作るより先に仕込むのが鉄則です。復元テストまでやって初めて「バックアップあり」と言えます。

CHK-2

Ollama のポートを直接公開しないLLMやDBのポート(11434, 5432等)をインターネットに晒すのは厳禁。外部から使う場合は必ずアプリ経由にするか、Tailscale / Cloudflare Tunnel の内側に置きます。認証なしのAPIが野ざらしになる事故は実際に多発しています。

CHK-3

モデルのライセンスとスペックを先に確認ローカルモデルには商用利用条件があるもの(ライセンス確認必須)と、必要メモリの壁があります。PoC提案の前に「そのPCで、そのモデルが、その速度で動くか」を手元で必ず検証。デモ当日の初起動は事故のもとです。