まずデータ基盤を、
自分の手元に立てる。

自立編で最初に据えるのは、すべてが乗るデータ基盤である。分析も、AI の RAG も、講座の予約も、基幹システムも、データはこの上に乗る。

2-01: Microsoft と Google から自立する ── 全体像と対応表 で地図を引いた。この編では、その地図にある OSS を一つずつ実際に立てていく。立てる先は、 2-02: AI に PC を一台渡すで AI に渡した一台だ。

ビルダーの仕事は、コードを書くことから始まらない。実績ある OSS を立てることから始まる(1-05)。汎用的な機能は、もう世界で共有されている。だから「書く」のではなく「立てる」。

データから先に据える

順番には理由がある。後の章で立てるものの多くが、データベースに依存する。

• 分析(DuckDB)は、ここのテーブルと Parquet を読む
• AI の RAG(2-16)は、pgvector で類似検索する
• 予約の受付(2-12)と基幹システムは、ここに読み書きする

土台が先にあれば、上に立つものは、すでにある DB に乗せるだけになる。先に据えるほど、後が軽い。

そして、その土台は最初から重くしなくてよい。

一人で、一つのアプリで、たいていの用途なら、まず SQLite から始める。据える順番もこれに従う。

単一ファイルで持つ

データベースの既定は SQLite だ。サーバを立てず、一つのファイルに収まる。Python に最初から入っていて、追加のインストールも要らない。スマホにもブラウザにも入っていて、世界で最も多く配られているデータベースだと SQLite 自身が述べている (sqlite.org「Most Widely Deployed」)。

# ライブラリも不要 ── 標準で入っている
sqlite3 app.db 'CREATE TABLE memo(id integer primary key, body text)'

一人で持つ設定も、端末の手元の小さなデータも、これで足りる。2-05 で立てる門番 (PocketBase)も、この SQLite の上で動く。一つのアプリが手元で持つだけなら、まず SQLite だ。標準 SQL なので、AI がそのまま書く。

足りなくなるのは、共有して複数人が同時に書くときだ。そのときだけ、倉庫を一段上げる。

共有して複数人で書くなら PostgreSQL に上げる

複数のアプリや人が同時に読み書きする共有の倉庫が要るなら、PostgreSQL に上げる。オープンソースで、無料で、商用に使える。SQLite と同じ標準 SQL だから、上げても書き方は変わらない。手帳(SQLite)から倉庫(PostgreSQL)へ、用途で持ち替える。

立て方の決めは四つだ。

• Debian 13 の apt で入れ、systemd で動かす(2-02)。PostgreSQL 17 と pgvector が公式のパッケージにある
• データの置き場は、Debian の既定のまま(/var/lib/postgresql)
• 待ち受けは localhost だけ。外の口は開けない
• アプリ用の利用者を一つ作る。管理者(postgres)ではアプリを動かさない

sudo apt install postgresql postgresql-17-pgvector   # 入れる。systemd で起動する
sudo -u postgres createdb app                        # データベースを作る
sudo -u postgres psql -d app -c 'CREATE EXTENSION vector'   # 拡張を有効にする

アプリ用の利用者の名前とパスワードは、人が決める。

pgvector をいま有効にする

AI の RAG(2-16)で使うベクトル検索を、いま有効にしておく。前節の三行目が、その一行だ。

-- 埋め込みを持つテーブルの例。次元数は 2-16 で選ぶ埋め込みモデルで決まる
CREATE TABLE docs (
  id    bigserial PRIMARY KEY,
  body  text,
  embedding vector(1024)
);

これで、文書を「意味」で検索する土台ができた。embedding に埋め込みを入れ、 ORDER BY embedding <=> :query で近いものを引く。実際の RAG パイプラインは 2-16 で組む。いまは器だけ用意しておく。

Azure SQL から移す

既存の Azure SQL / SQL Server がある場合は、pgloader がスキーマもデータも一括で運ぶ。

pgloader mssql://user:pass@azure-host/db \
         postgresql://app:pass@localhost/app

標準 SQL(SELECT・JOIN・ウィンドウ関数)はそのまま動く。捨てるのはベンダー方言の T-SQL だけだ。ストアドに埋まった業務ロジックは、AI が抽出して Python に翻訳する (1-05)。あとは旧 DB と並行稼働で出力を突き合わせ、差分が消えたら旧を止める (2-12)。

DuckDB で分析する ── 手元の一台で、追加料金なしに

集計・分析は、PostgreSQL の上に DuckDB を重ねる。列指向(カラムナ)の分析エンジンで、 1 ファイル、サーバー不要だ。Excel の 1,048,576 行という上限(Microsoft の仕様)が無く、手元の一台で、ファイルの大きさまで集計する。

uv add duckdb polars            # 2-04 で作る Python の環境に入れる

import duckdb
# Parquet も PostgreSQL も CSV も、その場で SQL で串刺し集計
duckdb.sql("INSTALL postgres; LOAD postgres;")
duckdb.sql("ATTACH 'dbname=app user=postgres host=localhost' AS pg (TYPE postgres)")
duckdb.sql("SELECT 部門, sum(売上) FROM pg.sales GROUP BY 部門 ORDER BY 2 DESC")

データを移し替えず、置いた場所のまま分析できる。SQL は AI が書く。「先月比で異常な部門は」を、手元の実データに対して、追加料金なしに何度でも問える。Power BI の人数課金から、ここで離れる。

Excel のデータは Polars で捌く

Excel は、人が数字を入れ、人が結果を読む入出力の道具だ。その役割は変わらない。格子は 2-07 のとおり、そのまま使う。変わるのは、その裏でデータを捌く側だ。

手元に積み上がった .xlsx は、Polars がそのまま読む。Rust 製の高速データフレームで、 Excel が固まる行数でも瞬時に処理し、結果を Excel・PostgreSQL・Parquet のどれにでも書き戻す。

import polars as pl
df  = pl.read_excel("売上_2025.xlsx")                # 人が作った Excel を読む
agg = df.group_by("部門").agg(pl.col("売上").sum())  # 重い集計は一行
agg.write_excel("部門集計.xlsx")                      # 人が読む Excel に書き戻す

人は Excel で入れて読み、機械は Polars と DuckDB で捌く。*人の道具と機械の道具を、役割で分ける*。SQL で書きたい処理は DuckDB、データフレームで捏ねたい処理は Polars だ。同じデータを、好きな道具で触れる。

巨大データを常時集計するなら、列指向 DB サーバーの ClickHouse に載せ替える。だが大半の社内分析は、DuckDB と Polars で足りる。

確かめ方

この章は、次の五つができていれば済みだ。

1. sqlite3 app.db で作った表が、.tables に出る
2. systemctl status postgresql が動いていて、psql でつないでデータベースの一覧が返る
3. psql で \dx を打つと、一覧に vector が出る
4. Python から DuckDB で PostgreSQL の表を集計し、部門ごとの合計が画面に出る
5. 人が作った .xlsx を Polars が読み、集計を .xlsx に書き戻し、そのファイルが表計算ソフトで開ける

sqlite3 app.db '.tables'
sudo -u postgres psql -d app -c '\dx'
uv run python -c "import duckdb, polars; print('ok')"

人が持つ物

人が渡す値

• アプリ用の利用者の名前とパスワード
• データベースの名前(例 app)
• 埋め込みの次元数(2-16 で選ぶモデルで決まる)
• Azure SQL から移す場合は、その接続先・利用者名・パスワード

AI が「やる前に言う」操作

• 旧 DB(Azure SQL / SQL Server)を止める
• PostgreSQL のデータディレクトリを消す、または作り直す
• 本番のデータに対して DROP や DELETE を実行する
• 人が作った .xlsx に上書きする

確かめた版と日付

• Debian 13(trixie)の PostgreSQL 17、postgresql-17-pgvector(pgvector 0.8)、pgloader 3.6
• SQLite(Python 同梱)、DuckDB、Polars ── 版は指定していない
• 手順を書いたのは 2026-07-01、見直したのは 2026-10-05
• 版が上がっていたら、AI に公式の手順を確かめさせてから進める

まとめ

データ基盤を、最初に自分の側へ。

• SQLite ── 既定。サーバ不要の単一ファイル、Python に同梱。一人・一アプリ・たいていの用途はこれで十分(門番もこの上)
• PostgreSQL(+ pgvector)── 共有して複数人で書くときだけ上げる、予約・基幹・RAG が乗る倉庫
• pgvector ── 意味検索の土台(RAG は AI の章で)
• pgloader ── Azure SQL からの一括移行、方言だけ捨てる
• DuckDB / Polars ── 列指向分析と高速データフレーム。Excel は人の入出力に残し、重い集計は機械側で。Power BI の人数課金から離れる

書いたコードは、ほとんど無い。汎用は、すでに OSS として在る。ビルダーは、それを立てる。次章では、この土台の上で処理を書く ── Excel と Word に埋まったマクロとグラフを Python に出し、画面が要るところには Flet を被せる。

関連記事

• 2-02: AI に PC を一台渡す ── 自立編を動かす機械
• 2-05: 門番を立てる ── PocketBase で認証を一つに
• 1-05: 顧客が AI と協働して開発する時代
• 2-01: Microsoft と Google から自立する ── 全体像と対応表
• 2-12: API を作る ── FastAPI で基幹のロジックを出す