Qiita Tech Festa 2026 のお題「AI時代のデータベース、何が変わる？」に、無料枠 × DB横断 × 再現可能な実測という角度から答えます。
対象: Supabase(pgvector) / Qdrant Cloud / Turso(libSQL) / Cloudflare Vectorize。データセット BEIR ArguAna(8,674文書)。ローカルCPUのみ・完全無料。
測定器の故障や自分の勘違い（Qdrantが実は総当たりだった等）も含め、訂正の過程を全部公開します（§8）。

30秒でわかる結論（専門用語なし）

無料で使えるベクトルデータベース4つに、まったく同じ「検索の仕事」をやらせて比べました。すると——どれを使っても検索の精度はほぼ同じでした。
では何が違うのか。「無料の上限に、どこが最初にぶつかるか」がDBごとにバラバラだったのです。あるDBは保存容量、別のDBはメモリ、別のDBは"検索を速くするための索引"が何十倍にも膨らんで容量を、別のDBは"保存できる量そのものの枠"を——と、最初に音を上げる場所が違いました。
だから無料枠でDBを選ぶコツは「どれが速いか・賢いか」ではなく、**「自分の使い方だと、どの上限に最初にぶつかるか」**を見ることだ、という話です。

この下は、それを実測で証明していく記事です。技術的な興味がなければ、ここまでで結論は full に伝わっています。

TL;DR（結論だけ）

観察対象＝無料枠の4製品・1データセット(ArguAna 8,674件)・無料枠スケール。以下は"一般法則"でなくこの標本・この条件での観察です（射程は本文で明示）。

検索品質はDBで変わらない（この条件では）：4製品とも nDCG@10 = 0.5017〜0.5019 / Recall@10 ≈ 0.79（同一埋め込み・同一統制条件なら、RAGの**検索段(retrieval)**の精度はDB非依存。※n=4・1タスクの観察／品質はLLM生成でなく検索段の指標）。
ANN忠実度も揃えれば厳密kNN参照にほぼ一致：実際に近似索引を動かした Supabase(HNSW)・Turso(DiskANN)・Cloudflare(Vectorize) の3エンジンが ANN Recall@10 = 0.9988〜0.9992 に収束。ローカル実HNSWでも 57,638件まで崖なし（0.65ptの漸減のみ／100k超は未検証＝外挿）。
本当の差は「無料枠の律速ユニット」がDBごとに別物：Supabase=容量 / Qdrant=RAM / Turso=索引肥大 / Cloudflare=stored次元。同じ8,674件でも「最初に枯れる単位」が違う＝"何ヶ月持つ"を1つの数字で語るのは不正確。
レイテンシ差(e2e)は最大20倍超だが、大半は地理・API経路の交絡：少なくともSupabase/Qdrantはサーバ側計算<1msで、差の正体は往復RTT（Turso/CFはサーバ側計時N/Aゆえe2e値として読む・後述）。

サマリ表（全1,406クエリ・既定設定・cosine・topK10・client=JP）

DB	リージョン	品質(nDCG/Recall)	ANN Recall@10	e2e p50	upsert	索引サイズ
厳密kNN(numpy・ANN参照)	local	0.5017 / 0.7902	1.000	—	—	—
Supabase pgvector	東京	0.5017 / 0.7909	0.9991	24.7ms	1442/s	17.7MB(HNSW)
Turso libSQL	東京	0.5017 / 0.7909	0.9992	49.7ms	9.8/s	710.8MB(DiskANN=生の53倍)
Qdrant Cloud	Oregon	0.5019 / 0.7916	0.9994※	142.9ms	716/s	非露出
Cloudflare Vectorize	global edge	0.5019 / 0.7909	0.9988	536ms	184/s	非露出

※Qdrantの0.9994はこの規模では総当たり(brute-force)由来で、HNSW近似の忠実度ではない（§6で詳述）。品質列は4DBほぼ同一＝「DBで精度は変わらない」を表で表現。
※律速ユニット・消費率（無料枠が最初に詰まる単位）は §7 の表を参照。

⚠ 再現性について：品質(nDCG/Recall/ANN Recall)と無料枠消費の列は、同じコード・同じデータ・同じ確認日の公式枠を使えば再生成できます（マネージドDB側の仕様変更・tie順序・リージョン・ライブラリ版差で微小差はあり得ます）。レイテンシ列は特にクライアントの地理に依存します（本記事は client=日本）＝絶対値でなく相対傾向で読んでください。

1. なぜ「無料枠 × DB横断 × 再現可能な実測」なのか

「AI時代のデータベース、何が変わったか」。本記事の答えは、埋め込みがストレージを"高次元の索引構造"に変えたことで、無料枠で最初に詰まる単位が『行数/バイト』から『索引そのもの』へ移った——そしてそれを無料枠だけでローカルCPUから横断実測できる時代になった、というものだ（この"律速の移動"を実データで示すのが本記事）。

日本語圏の先行記事を見ると、(a)エンタープライズ大規模の多製品比較、(b)単一DB内の手法比較、(c)機能スペック表が多い。とくに BEIR×nDCG×Qdrant を扱う先行記事には、Qdrant上で検索手法(Dense/BM25/Hybrid/Rerank)を比較するものがある。本記事は逆で、手法を固定し、DBと無料枠を変える。軸が直交するので住み分く。「無料枠を厳密な制約にして、横断で、再現可能に実測した」記事は空白だった。

売りは再現性：git clone → 無料の鍵を.envへ → python -m harness.bench。品質と消費の表はどこでも同じ（レイテンシだけは地理依存）。埋め込みはローカルCPUで約3分、GPU不要。

2. 実験設定（統制条件）

データセット = BEIR ArguAna（corpus 8,674 / queries 1,406 / qrels 1,406）。
選定理由：Cloudflare Vectorizeの無料 stored 上限が「500万次元 ÷ 384次元 ≈ 1.3万ベクトル」と市場で最も小さい。だからコーパスを小さく保てるArguAnaにした（FiQA 57,638件はこのCF無料stored上限(≈1.3万本)の約4.4倍で無料枠外。間引くと正解集合qrelsが壊れる）。
埋め込み = all-MiniLM-L6-v2（384次元・Apache-2.0・CPU）、normalize_embeddings=True（cosine=内積）。max_seq_len=256で長文は切られ、絶対nDCGはこの小型モデル相応に低い（より強い埋め込みなら上がるが、それはDB比較とは直交）。全DB共通なので横断比較は不変。
厳密kNNは"ANN忠実度の参照"：numpyブルートフォースcosine top10を基準に固定（1,406×8,674がわずか0.1秒）。各DBのANN結果はこの参照に対し採点する。※これは同一埋め込み・同一cosineでの検索順序の参照であって、qrels基準のTask品質(nDCG/Recall)の"上界"ではない（DBがtie順序の都合で微小に上回り得る）。
自己一致除外が必須：ArguAnaはクエリ自身がコーパスに入り、生top1の91%(1,281/1,406)が"自分自身"。除外しないとnDCGが壊滅的に過大評価される。規則はdoc_id == query_id（正解は常に別ID＝BEIR標準のignore_identical_idsと論理一致で安全）。
参照の nDCG@10 = 0.5017 は、HuggingFaceモデルカードのMTEB ArguAna公開値 50.17（=0.5017・2026-06-26再確認）と一致＝パイプラインが標準どおりに動いている外部証拠（Task指標ではDBが+0.0002程度上回る0.5019も出るが、これは"参照破り"でなくtie/順序の揺れ）。

3. 4つの無料枠の「事実」（公式ページ・2026-06-26 再確認／ドリフトなし）

DB	無料枠	クレカ	索引	休止ポリシー
Supabase(pgvector)	DB 500MB・2プロジェクト	不要	HNSW(調整可)	7日でpause
Qdrant Cloud	RAM 1GB / disk 4GB	不要	HNSW(ef調整可)	1週でsuspend・4週で削除
Turso(libSQL)	storage 5GB / 読5億・書1000万行/月	不要	DiskANN(ノブ無し)	常時稼働(休止なし)
Cloudflare Vectorize	stored 500万・queried 3000万 dims/月	不要	managed(black-box)	edge(従来型cold startなし)

東京リージョンの可否が地味に効く：Supabase/Turso は東京を取れたが、Qdrant無料は確認日(2026-06-26)時点でアジア不可（最寄りのOregonを選択。無料リージョンは変わり得るので日付付きで）。Cloudflareはグローバルエッジで単一リージョンの概念がない。→ レイテンシは相対傾向で読む。
4DBともクレカ不要で開始できた。

出典（2026-06-26確認）: Supabase Pricing（Free=500MB・2プロジェクト・1週でpause）／ Qdrant Pricing（Free=0.5vCPU/1GB RAM/4GB disk）／ Turso Pricing（Free=5GB・読5億/書1000万行/月・CC不要）／ Cloudflare Vectorize Pricing（Free=stored 500万/queried 3000万 dims/月）。無料枠は改定され得るため、公開直前に再取得し確認日を更新すること。

4. ハーネス設計（要点）

統一インターフェース(create/upsert/search/stats/teardown)に各DBを実装。横断で公平にするための要点だけ：全DB FETCH_K=30で取得→自己一致除外→top10に統一（除外で件数が欠けない）／scoreは全DB「類似度（大きいほど良い）」に正規化／IDはQdrantだけ整数必須（他は文字列そのまま）／レイテンシは e2e とサーバ側を分離、ウォームアップ20破棄・各クエリ3反復でp50/p95。詳細はリポジトリ参照。

5. 結果①：品質はDBで変わらない（俗説の反証）

4DBとも nDCG@10 = 0.5017〜0.5019 / Recall@10 ≈ 0.79（参照=MTEB公開値0.5017とほぼ一致）。
同じ埋め込みベクトルを入れているのだから当然ともいえるが、「どのベクトルDBを使うかでRAG検索の精度が変わる」は、本記事の統制条件（同一埋め込み・同一前処理・同一metric・フィルタなし・topK固定・ANN Recall≈1）では成立しないことを実データで示せた。差が出るとすれば埋め込みモデルや前処理であって、DBの選択ではない。

📐 この結論の射程と正直な留保（実務での差・小規模ゆえの必然性／クリックで展開）

実務では、DBごとのメタデータ・フィルタ性能／量子化／ハイブリッド検索／更新直後の整合性で差が出る余地はある。本記事が言えるのは「素の検索精度は今回の条件で横並びだった」まで。
8,674件という小規模では近似誤差が出にくく、「品質が揃う」のは設計上ある程度予定された面もある。だから§6でローカル実HNSWを57.6kまで伸ばし崖が出ないか確かめた——が、それでも実クラウドDBの大規模検証は無く外挿。よって本結論の射程は厳密には**"無料枠スケール(〜数万件)"に限る**（大規模は Part2 の宿題）。

6. 結果②：ANN忠実度は揃えれば厳密kNN参照にほぼ一致（ただし"誰が本当に近似していたか"に注意）

近似索引を実際に動かした 3エンジン(Supabase/Turso/Cloudflare)で ANN Recall@10 = 0.9988〜0.9992 に収束。揃えればどのDBも厳密kNN参照にほぼ一致する。

…のだが、ここで監査中に自分の重大な誤りを見つけた。
Qdrantは8,674件では実はHNSW索引を張っておらず、総当たり(brute-force)で検索していた（一次実測で indexed_vectors_count=0）。つまりQdrantの0.9994は、HNSW近似の忠実度ではなく、総当たり/未index検索に近い挙動で高く出た値として扱うべき（1.0でないのはtie順序・float差・FETCH_K処理の揺れ）。表では別枠の※にした。ANN忠実度を測るには、Qdrantが索引を張る規模で測る必要がある——だから本記事の規模検証はローカルfaissに委ねた。

📐 なぜ総当たりに？→閾値は"件数"でなく"kB"・しかも2段（移植可能な教訓／クリックで展開）

鍵はindexing_thresholdが**「件数」でなく「未索引ベクトルの"サイズ(kB)"」のしきい値であること（公式：未索引ベクトルのサイズがこの値(kB)を超えると索引セグメントを構築）。本コーパスは 8,674本×384次元×4B ≈ 13,000kB が segments_count=2（collection-info 実測）に分かれ各≈6,500kBで、私のクラスタの indexing_threshold=10,000kB（同じくcollection-info実測。※既定値は版により10,000/20,000kBの差があるが本機は実測10,000kB）を下回る**ため indexed_vectors_count=0 になった（強制構築すると8,674に到達）。

しかも閾値は2段ある：索引を強制構築しても、**full_scan_threshold（既定10,000kB）を下回るクエリは plannerが総当たりを選ぶ。「しきい値は件数でなくkB・しかも2段」**が移植可能な教訓——ANN忠実度を測るなら両閾値を超える規模で。（小規模では総当たりの方がHNSW構築より速く・正確なので、Qdrantが索引を作らないのは設計どおりの正しい挙動。）

「8,674件の偶然では？」を潰すため、ローカルでfaiss実HNSWを規模スイープした（FiQAを埋めて8.7k→57.6k）。値はscale_sweep.csvそのまま：

N	ANN Recall@10 (ef=64)	(ef=16)
8,674	0.9945	0.9195
25,000	0.9902	0.9102
50,000	0.9884	0.9020
57,638	0.9880	0.9028

ef=64なら57.6kまで単調に0.65ptだけ漸減し、崖は出ない（efで回復可能・100k超は外挿で未検証）。「収束は小規模の偶然」ではなく、実HNSWでも規模を上げて崩れないことを確認できた。

※このスイープのfaiss値(8,674で0.9945)は、本表のクラウドDB(Supabase 0.9991)とef/m設定が違うので絶対水準は直接比較しない。見たいのは「規模を上げても崖が出ない＝傾向」であって、各DBの忠実度の優劣ではない。

おまけ：e2e差の正体を実測で剥がす。 サーバ側計算p50は Supabase 0.45ms / Qdrant 0.81ms（いずれも<1ms）。同一リージョンで比べられるのは東京の Supabase 24.7ms vs Turso 49.7ms だけ（エンジン差で約2倍）。Supabase東京↔Qdrant Oregon の e2e差(24.7↔142.9ms)は、両者ともサーバ側<1msゆえ大部分が地理・API経路・RTTの交絡で、エンジンの素の速さの差ではない。Turso/CFはサーバ側計時を取得できないため、ここではe2e値としてのみ扱う（地理だけが原因とは言い切らない）。

7. 結果③（主峰）：無料枠の"持ち"は「律速ユニット」がDBごとに非対称

ここが山場。同じ8,674件を入れても、無料枠を最初に使い切らせる単位がDBごとに別物だった。

DB	律速ユニット	使用量 / 無料枠	消費率
Supabase	DB容量＋7日休止	約33MB / 500MB	6.6%
Qdrant	RAM/disk＋1週suspend	node RSS Δ≈38MB（索引バイトは非露出）	~3.8%(概算)
Turso	索引肥大(storage)＋逐次投入	729MB / 5GB（うち索引710.8MB＝生の53倍）	14.6%
Cloudflare	stored次元	3,330,816 / 5,000,000	66.6%

Supabase=容量：約33MBで余裕。むしろ7日休止が先に効く。
Qdrant=RAM：律速はRAM 1GB。面白いことにコレクションの索引バイト数はAPIに出ない（生ベクトル分13.3MBは出るが、HNSWを強制構築してもtelemetryのram/disk_usage_bytesは0＝露出されないだけで、ゼロコストではない）。実RAMは投入前後のnode RSS差で約38MB増を観測＝1GBの約3.8%（上界推定）。Supabaseの17.7MBやTursoの710.8MBと直接比較できないのが、逆に"測れない律速"の好例。
Turso=索引肥大：屈指の隠れコスト。Tursoは行数でなくstorageが律速。投入147倍遅・索引53倍肥大は"逐次索引"という同一原因の表裏だ。生ベクトル13.3MBが、DiskANN索引で710.8MB（53倍）に膨張し、投入は9.8件/秒＝Supabase(1442件/秒)の約147倍遅い（DBの絶対性能差でなく**"逐次索引 vs 一括後構築"という今回の投入パターン差**）。この2つが同根なのは、TursoがDiskANNグラフを挿入のたびに逐次更新するため、投入(約880秒)のほぼ全部がその書き直しに消えるから。同じDBでもメーターは複数あり、最初に枯れるのは1つ——という本記事の核心を体現する。
📐 Turso運用Tips・行課金の内訳（クリックで展開）
- 投入パターンの対比：Supabaseは**COPY一括(2.8秒)→HNSWを後からまとめて構築(3.2秒)**で済むのに対し、TursoはDiskANNを逐次更新するため約880秒かかる。
- 行課金はどちらも余裕：読み0.6%(3,131,435/5億)・書き5%(496,276/1000万)＝Tursoを律速するのは行数でなくstorageだけ。
- ストレージ回収：VACUUMはTurso Cloudで不可だが、DROP/作り直しで課金ストレージは回収できる（DROP後8KB）。
Cloudflare=stored次元：stored枠66.6%＝4DB最窮、Workers Freeでは月約49評価が上限（stored律速の痛みがいちばん早く来る）。queriedはCF公式の月間計算式で（月内クエリ数＋stored数）×次元として表現される（公式例 (30,000+10,000)×768＝月間式で stored が一度だけ足される形）。一般化すると 月消費 ≈ (コーパス件数＋クエリ数 × 評価回数) × 次元。同じindexを維持・stored数一定・他queryを投げない前提で本記事に代入すると、N回フル評価で (8,674＋1,406×N)×384 と近似でき、30M/月では 約49評価/月（≈1.6回/日） が上限になる（初回1評価387万dimsを30Mで単純割りした7.75回は、storedを毎評価二重計上した誤り）。

結論：無料枠の"持ち"を単一スカラーで語ることはできない。 「最初に枯れる単位」がSupabase=容量、Qdrant=RAM、Turso=索引肥大、Cloudflare=stored次元と違うからだ。埋め込みがストレージを高次元索引に変えたAI時代だからこそ、選定軸は「速い/賢い」でなく"自分のワークロードで最初に枯れる律速ユニットはどれか"に変わった——価格表でなく律速で選ぶ。

用途別・律速早見表（本文の実測値だけで構成・新事実なし）：

こう使うなら	最初に枯れる枠	無難な選択	避けたい
1万件規模を月数十回評価	queried枠（CFは月約49評価が上限）	Supabase / Turso	Cloudflare
常時稼働・即応性重視	cold start／休止	Turso(常時稼働) / CF(cold startなし)	休止ありの Supabase / Qdrant
容量・件数を多く積みたい	索引肥大・stored枠	Supabase(33MBで余裕)	Turso(索引53倍肥大) / CF(stored 66.6%)

※あくまで本記事の標本(ArguAna 8,674件・無料枠スケール)での傾向。用途と規模が変われば律速も変わる。

8. 落とし穴ログ（測ってから語る・自分の誤りも含めて）

この企画でいちばん学びがあったのは、測ってみて初めて分かった/自分が間違っていたことたち。「誤→正」で並べる。

Qdrantは8.7kで総当たりだった（§6）。誤=「天井到達はHNSW忠実度の証拠」→ 正=「indexed_vectors_count=0、近似してるつもりで総当たり」。一次実測で覆して訂正。
Tursoの肥大を測る計器自体が壊れていた。誤=pragma_page_countの約695MB → 正=それはTurso Cloudで行数に無関係な定数。dbstatで測り直して53倍を確定。
Cloudflare Vectorizeの非同期/結果整合。誤=「upsert直後にqueryできる」→ 正=upsertは非同期で反映待ち(バリア)が要る（実測上の罠であると同時に、公式Client APIにも「upsert後にquery可能になるまで通常数秒」と明記された仕様）。さらにvectorCountが結果整合で非単調にぶれる(8,674↔5,000)。これはエッジ分散×結果整合の設計上の帰結で、書込み直後のread-your-writesが保証されない＝vectorCountは課金照合のソースにできない。逆に従来型cold startが無いのはこの設計の裏返しの利点。
Vectorizeの index は delete→即再作成がレース：削除済みの名前がしばらく410 index deletedを返し初回upsertが落ちた→「再利用or作成（deleteしない）」で回避。
管理画面が母国語自動翻訳で死ぬ：TursoダッシュボードがブラウザのEN→JA翻訳とReactのDOM操作衝突でremoveChildクラッシュ→GUIを諦めREST APIで構築したら一発。「無料DBはGUIよりAPIで作れ」。
単位の混在：容量%をバイナリ(1024)と10進(1000)で混在計算し、同じ値が6.3%と6.6%に割れていた→10進SIに統一。

これらは全部、新規の上位モデル監査エージェント＋一次裏取りで公開前に潰した。「鵜呑みにしない」を自分の成果にも適用したのが効いた。

9. cold start / 休止ポリシー

「速さ」の裏で効くのが休止だ。Tursoだけが常時稼働（休止なし）で、これは地味だが大きい。Supabaseは7日、Qdrantは1週でアイドル休止し初回アクセスで復帰待ちが発生しうる（Qdrantは4週で削除）。Cloudflareはエッジで従来型cold startが無い。
※真の"休止からの復帰レイテンシ"は、休止条件(数日アイドル)の再現に時間がかかるため本記事では未測定。ここでは「常時稼働か/休止ありか」のポリシー比較に留める（測っていないものを測ったとは書かない）。
特に月数回〜数十回の低頻度評価では、Supabase/Qdrantは毎回休止明けに当たりうる→低頻度かつ即応性が要るなら Turso(常時稼働)／CF(cold startなし)が有利（これはポリシー上の含意であって、復帰レイテンシの実測ではない）。

10. 再現手順

git clone https://github.com/axiom-pro/free-tier-vectordb-bench && cd free-tier-vectordb-bench
python -m venv .venv && ./.venv/Scripts/python.exe -m pip install -r requirements.txt
# ↑ Windowsパス。macOS/Linuxは ./.venv/bin/python（以降の python も同様にvenvのものを使う）
# 無料の鍵を .env に設定（変数名は .env.sample 参照）：
#   SUPABASE_DB_URL=postgresql://...                         # Supabase接続文字列
#   QDRANT_URL=...   QDRANT_API_KEY=...                       # Qdrant Cloud
#   TURSO_DATABASE_URL=libsql://...   TURSO_AUTH_TOKEN=...    # Turso
#   CF_ACCOUNT_ID=...   CF_API_TOKEN=...   CF_VECTORIZE_INDEX=arguana-minilm   # Cloudflare
python -m harness.download_data && python -m harness.embed   # ArguAna取得＋CPU埋め込み(約3分)
python -m harness.exact_knn                                   # 厳密kNN（ANN忠実度の参照）
python -m harness.bench --db all                              # 3DB実測 → results/summary.csv
python -m harness.bench --db cf --no-teardown                 # Cloudflare(4本目)。反映待ち(非同期)があるので分離・--no-teardownでindex保持(§8参照)
python -m scripts.consumption_report                          # §7 消費メーター表

CPUのみ・GPU不要。Cloudflareはwrangler login(ワンクリックOAuth)→wrangler vectorize createで無料作成できる。

検証環境（再現性のため）：Python 3.12 / sentence-transformers 5.6.0 / numpy 2.5.0 / qdrant-client 1.18.0 / psycopg 3.x / libsql-client 0.3.1 / faiss-cpu 1.14.3（規模スイープ用）。全ピンは requirements.lock.txt。データセット＝BEIR ArguAna（TU Darmstadt公式zip）、モデル＝sentence-transformers/all-MiniLM-L6-v2。実行OS/CPU等の詳細は results/metadata.json（本記事は Windows 11・CPU・client=日本）。

まとめ：AI時代のDB選定で「何が変わったか」

無料枠だけで、ローカルCPU3分の埋め込みから、4つのベクトルDBに同一RAG検索ワークロードを流して横断実測できた。分かったのは：

品質はDBで変わらない（同一埋め込みなら）。
ANN忠実度も揃えれば厳密kNN参照にほぼ一致（実HNSWで57.6kまで崖なし・100k超は外挿）。
本当の差は"無料枠の律速ユニット"の非対称（容量/RAM/索引肥大/stored次元）。

埋め込みがストレージを高次元索引に変えたことで、無料枠の限界は「行/バイト」から「索引そのもの（Turso 53倍肥大・CF stored枠）」へ移った。だから選定の軸は「どれが速い/賢い」でなく、「自分のワークロードで最初に枯れる単位はどれか」——価格表でなく律速で選ぶ、それが無料枠時代のDB選定だと思う。

計測コード・全CSV・落とし穴ログはリポジトリに同梱（再現可能）。数値はすべて実測値で、検証できなかったもの（休止復帰レイテンシ・100k超の規模）は「測っていない」と明記した。

リポジトリ：github.com/axiom-pro/free-tier-vectordb-bench

筆者について

tauridev（ソフトウェア開発／AIコード監査）。Rust/Tauri＋React/TypeScript でローカルファーストのWindowsデスクトップアプリを開発しつつ、**「AIに本番品質のコードを出させ、AIが間違っているときに気づく検証規律」**を専門にしています。本記事の §8（自分の測定器の故障や "Qdrantが実は総当たりだった" という思い込みを、一次データで突き止めて訂正した過程）は、その検証規律をそのまま実演したものです。

「AIで一気に作ったが本番に出せず詰まった」「測ってみたら想定と違った」——そういうコードやデータの監査・修正・本番化を、テキスト完結・固定価格で承っています。

🔍 AIで作ったアプリの不具合を監査・修正します（テスト/CI整備・実装と表示のズレ検出・本番化）— ココナラで見る
💻 ローカル完結のWindowsアプリ作ります（データを外に出さない買い切り型・通話なし・テキスト完結）— ココナラで見る
プロフィール：coconala.com/users/6153961 ／公式サイト：getaxiom.dev