macOSのSQLiteを3.54.1へ更新する方法｜Homebrew終了の壁とRust静的リンク実証録
Mac のターミナルで sqlite3 --version を叩いたり、Rust や C 言語から標準の libsqlite3 を呼び出して「最新の SQLite が動いているはず」と思い込んでいませんか。実は macOS 標準の SQLite は 約 3 年前の 3.43.2（2023 年 10 月版） で止まっており、さらに Intel 世代の Mac では 2026 年 9 月をもって Homebrew の公式サポートが打ち切られたため、brew upgrade sqlite すら権限エラーと依存パッチ地獄で止まる という二重の罠が待ち受けています。
.dylib）に頼るのをやめ、SQLite 公式の単一 C ソース（Amalgamation 3.54.1）を SHA3-256 検証の上で AVX2 最適化ビルドし、静的ライブラリ（libsqlite3.a）として Pure Rust バイナリへ直接埋め込む方式 が最も安全で高速な正解です。本記事では、稼働中の AI エディタ連携（Hooks）を 1 秒も止めずに無停止で 3.43.2 から最新の 3.54.1 へ移行し、クエリ総所要時間を 5.96ms → 2.92ms（約 2 倍高速化）、会話履歴 DB を 988.1MB → 662.2MB（-325.9MB 圧縮） へ引き締めた全手順と、3.54 新機能 .diskused による DB 内訳の解剖結果を公開します。
-
SQLite自前ビルドを自動更新する方法｜公式CSV解析とSHA3検証・自動復旧の実証録 : 本記事の続編（完結編）です。自前ビルド後の「更新忘れ・放置リスク」を防ぐため、
sqlite.org公式の機械可読 CSV 解析と SHA3-256 検証、自己テスト失敗時の自動ロールバックまで金曜朝 1.65 秒で巡回させる実装を公開しています。 -
Astro・TS・Rustコード丸読みの罠｜SQLite階層索引で読込98%減の実測録 : 外部依存ゼロのPure Rust状態機械で.astro・.ts・.rs全コードをSQLite階層シンボル化し、3ミリ秒台で読込量を最大98%削減した実装録です。
-
CLAUDE.md・GEMINI.md・TODO丸読みの罠｜SQLite階層目次で読込99%減の実測録 : 本記事で
3.54.1化したローカル SQLite 知識 DB を使い、長大なルール文書やコードの該当行だけを数ミリ秒で引き抜く階層ナビゲーション設計です。 -
Rust製CLIの起動ラッパーが遅い原因｜シェルfork税撤廃とSQLiteゼロコピーで5ms化した実証録 : 起動シェルスクリプトのサブシェル
fork税撤廃と SQLite 内部ページバッファのゼロコピー借用により、ラッパー経由の実行時間を半減させた前編です。 -
SQLite全文検索にGPUは逆効果？Rust×AVX2と短語FTS5で48ms化した検証録 : CPU 内蔵の AVX2 命令（256 ビット一括照合）と 1〜2 文字専用の
short_fts索引を組み合わせ、全文検索をミリ秒化した基盤構築の記録です。 -
Rustのアップデートは.1まで待つべき？1.99移行でunsafe撤去と週次自動更新を組んだ実証録 : コンパイラの初期バグを避ける
.1待機戦略と、毎週金曜朝に自動でツールチェーンを点検するlaunchd運用の実践録です。
-
macOS 上の Rust・C/C++・各種 CLI ツールが いつの間にか古い OS 標準 SQLite（
3.43.2）を掴んでいる問題 を根本解決したい方 -
Intel 世代の Mac（iMac 27 インチ 2020 等）で Homebrew のサポート終了や
/usr/local/Cellarの権限エラーに阻まれず、最新の SQLite3.54.1を安全に導入したい方 -
AI エディタ（Antigravity / VS Code 等）の Hooks やバックグラウンド DB 連携を動かしたまま、リンク切れや DB 破損ゼロで無停止アップデートしたい方
macOS標準SQLiteが3.43.2で止まる罠
当サイト（現在公開706本の記事と 2,670 件超の対話ログを運用）では、記事検索やルール参照、整合性チェックのすべてを手元の Mac 内の SQLite と Pure Rust 製バイナリ（kb-search および gemini-gate）で処理しています。
ところが、SQLite Release 3.54.1 公式リリースログ をきっかけに手元の稼働バージョンを実測してみたところ、意外な事実が判明しました。
Rustの標準FFIが古いOS版を掴む仕組み
Mac 内の SQLite バージョンを場所別に調べると、実は同じ 1 台の Mac の中に 3 つの異なる世代 が並存する状態になっていました。
| 確認対象 | 実測バージョン | ビルド日 | 実際の稼働状態 |
|---|---|---|---|
| macOS 標準 ＆ Pure Rust ツール群 （ /usr/lib/libsqlite3.dylib） |
3.43.2 |
2023-10-10 | 実際にリンクされて動いていた古い版（64-bit Apple ビルド） |
| Mac 内の旧 Homebrew 版 （ /usr/local/opt/sqlite） |
3.53.4 |
2026-07-24 | OS 標準との衝突回避（keg-only）で隔離され 未リンクのまま眠っていた版 |
| SQLite 公式の最新安定版 （ sqlite.org 公開版） |
3.54.1 |
2026-10-16 | 今回導入する最新安定版（3 年分のクエリ最適化＋.diskused 搭載） |
なぜ Homebrew に新しい SQLite を入れていたのに、自作の Rust バイナリは 3 年前の 3.43.2 を掴み続けていたのでしょうか。原因は Rust の FFI（他言語関数呼び出し）で定番の #[link(name = "sqlite3")] 指定にあります。
macOS では OS 自身が内部設定の管理に /usr/lib/libsqlite3.dylib を使っているため、Homebrew の sqlite パッケージはシステムを壊さないよう標準パスへシンボリックリンクを張らない「隔離配置（keg-only）」になっています。そのため、明示的にリンク先を変えない限り、rustc は常に Apple 標準の 3.43.2 を見に行ってしまうのです。
ええっ、Homebrew で入れたら勝手にそっちの新しい SQLite が使われると思ってたよ！ 確認しないままだと、ずっと 2023 年のエンジンで走ってたってことか……。
ここが macOS の一番引っかかりやすい落とし穴なんです。必ずターミナルの sqlite3 --version だけでなく、実際のアプリ側で SELECT sqlite_version(); と otool -L を叩いて裏取りするのが鉄則ですね。
SQLite 3.54.1の修正内容と64bit判定
では、最新の 3.54.1（3.54.0 公式リリースログ の 1 週間後に公開された修正パッチ版）にはどんな変更が入っているのでしょうか。冷静にファクトを切り分けると、以下の 2 点に集約されます。
-
セキュリティ修正（64-bit の現行 Mac は影響なし） :
3.54.1で修正されたヒープバッファオーバーフローの潜在的脆弱性は 32 ビットビルド限定 の問題です。現行の macOS や 64 ビットネイティブの Rust バイナリはこの脆弱性の影響を受けないため、慌ててサービスを緊急停止する必要はありません。 -
約 3 年分のクエリプランナ最適化と CPU サイクル削減 :
3.54系は直近世代比でも CPU サイクルが約 4% 削減されており、2023 年の3.43.2から見ればOR条件・UNION ... LIMIT 1・式インデックス更新時の不要な再書き込み省略 など、3 年分の最適化が一気に手に入ります。 -
待望の標準容量解剖
.diskused（diskused()拡張） : これまで別途 Tcl をリンクしてsqlite3_analyzerをビルドしないと見られなかった 「どのテーブルや FTS5 全文検索インデックスが何ページ（何 %）容量を食っているか」 が、標準 CLI の.diskusedコマンド 1 発で即座に出力できるようになりました。
Intel Macでbrew更新が止まる二重の壁
「それなら Homebrew の SQLite を 3.54.1 に上げてリンクし直そう」と考え、実際に brew upgrade sqlite を叩いたところで、Intel 最終世代の名機（iMac 27 インチ 2020：iMac20,1）ならではの 2 つのリアルな壁 に直面しました。
Homebrewのx86サポート終了と権限エラー
実際に brew upgrade sqlite を実行した際に出力された生ログの抜粋がこちらです。
Warning: You are using macOS on Intel x86_64.
We do not provide support for this platform (as-of September 2026, announced August 2025).
==> Would upgrade 1 dependency:
readline 8.3.3 -> 8.3.6
==> Would upgrade 1 requested outdated package
sqlite 3.53.4 -> 3.54.1
==> 1 homebrew/core formula that would build from source
sqlite
Error: sqlite: An exception occurred within a child process:
Errno::EACCES: Permission denied @ dir_s_mkdir - /usr/local/Cellar/readline/8.3.6Homebrew は 2026 年 9 月をもって Intel Mac（x86_64）の公式サポートと事前ビルド済みバイナリ（Bottle）の配布を終了 しています。そのため、sqlite 本体をソースからビルドしようとするだけでなく、ライブラリ利用には本来不要な対話シェル用の依存パッケージ readline までパッチ当てビルドに巻き込み、さらに複数アカウント運用環境で起きがちな /usr/local/Cellar のディレクトリ権限エラーで停止してしまいました。
ここで安易に sudo chown -R でシステム領域の所有権を書き換えたり、毎回重い依存パッケージのソースビルドに付き合うのは得策ではありません。
共有ライブラリdylibとApple ldの罠
さらに、仮に Homebrew でビルドできたとしても、共有ライブラリ（libsqlite3.dylib）への動的リンクにはもう 1 つの罠があります。
実際に事前テストで rustc -L native=/usr/local/opt/sqlite/lib -l static=sqlite3 を試したところ、同じフォルダ内に .dylib と .a が同居していると、macOS のリンカ（ld）や残存していた #[link(name = "sqlite3")] 属性が共有ライブラリ .dylib 側を引きずって動的リンクしてしまう現象 を otool -L で確認しました。
-
OS 標準は 3 年前の
3.43.2で固定される -
Homebrew 側の
.dylibを指すと、パッケージ更新やパス変更の瞬間にdyld: Library not loadedで検問や Hooks が即死するリスクがある -
同じフォルダに
.dylibがあると-l static=sqlite3でも動的リンクに吸われやすい
-
公式単一 C ソース（
sqlite3.c）を-O3 -march=nativeで母艦 CPU 専用に最適化ビルドできる -
機械語が Rust バイナリ内部へ完全に一体化するため、外部
.dylib切れクラッシュが 物理的にゼロ になる -
sudo不要・readline不要・約 20 秒で完結する
なお、通常の Cargo プロジェクト（外部クレートを使う構成）であれば、Cargo.toml で rusqlite = { version = "0.41.0", features = ["bundled"] }（内部の libsqlite3-sys 0.39.x が SQLite 3.54 系を同梱）を指定するだけで同じ静的リンクが実現できます。一方、当サイトの基盤は 「外部クレート依存ゼロ・RAM ディスク上で 0.5 秒アトミック再ビルド」 という超軽量設計を採っているため、毎回 9MB の C ソースを再コンパイルさせず、事前ビルド済みの libsqlite3.a（約 1.6MB）だけを 0.1 秒でリンクする構成がベストマッチでした。
公式AmalgamationとRust完全静的リンク
ここからは、実際に稼働中のシステムを止めずに 3.54.1 へ移行した具体的な手順と、AI エディタの統合機能（Hooks）との共存設計を解説します。
SHA3検証とAVX2最適化の単一Cビルド
SQLite が世界中のエンジニアから愛されている最大の理由の 1 つが、The SQLite Amalgamation 公式仕様 と呼ばれる配布形式です。100 本以上に分かれた内部 C ファイル群があらかじめ たった 1 本の sqlite3.c と sqlite3.h に統合されており、これによりコンパイラが関数間の境界を越えたインライン展開（最適化）を最大限に効かせられ、単体で 5〜10% 高速化すると公式文書でも明記されています。
まず公式アーカイブを取得し、公開されている SHA3-256 ハッシュ値（92281c86...）と 1 ビットの狂いもなく一致することを機械検証 してから、Apple Clang 17 で静的ライブラリ libsqlite3.a と管理用 sqlite3 CLI をビルドします。
# 1. 公式 SHA3-256 チェックサムの厳格照合（不一致なら即中止）
EXPECTED="92281c86e2957f9b9305890f9ac04204caa7b677cc868dc326d942689df28e30"
ACTUAL="$(openssl dgst -sha3-256 /tmp/sqlite-amalgamation-3540100.zip | sed 's/^.*= //')"
[ "$ACTUAL" = "$EXPECTED" ] || exit 1
# 2. 母艦CPUのAVX2命令をフル解禁し、FTS5・数学関数・DQS=0・MEMSTATUS=0で静的ライブラリ生成
clang -O3 -march=native -DNDEBUG \
-DSQLITE_THREADSAFE=1 -DSQLITE_DQS=0 -DSQLITE_DEFAULT_MEMSTATUS=0 \
-DSQLITE_DEFAULT_WAL_SYNCHRONOUS=1 -DSQLITE_OMIT_DEPRECATED \
-DSQLITE_ENABLE_FTS5 -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_RTREE \
-DSQLITE_ENABLE_MATH_FUNCTIONS -DSQLITE_ENABLE_DBSTAT_VTAB \
-c sqlite3.c -o sqlite3.o
ar rcs _local_db/sqlite-lib/libsqlite3.a sqlite3.oここで SQLite Compile-time Options 公式推奨設定 に従い、ダブルクォート文字列の誤用を防ぐ -DSQLITE_DQS=0 と、メモリ使用量カウンタの排他ロック（ミューテックス）を省略して高速化する -DSQLITE_DEFAULT_MEMSTATUS=0 を有効化しています。また、生成したバイナリは .gitignore 対象の _local_db/sqlite-lib/ に置くことで、Git リポジトリを肥大化させずに SSD 上へ永続保持できます。
動的依存ゼロ化と自動追従ラッパーの設計
アップデート前に気になったのが、「毎ターン裏で SQLite を読み書きしている AI エディタの Hooks（GEMINI.md 自動同期＆知識 DB 連携）を一度止めてから作業すべきか？」 という点です。結論として、以下の 3 層構造により ON のまま無停止（ホットスワップ）で 100% 安全に移行 できました。
3.43.2 と 3.54.1 は DB ページ構造も WAL（追記ログ）共有メモリも 100% 前方・後方互換のため、切り替え前後のプロセスが同じ DB を開いても破損しません。
稼働中のバイナリを直接上書きせず、PID 別の一時フォルダ（.build.$$）でコンパイルとリンクが完全に終わってから POSIX アトミック mv -f で入れ替えるため、ビルド途中の半端なバイナリを踏む事故が起きません。
libsqlite3.a のタイムスタンプがバイナリより新しければ自動で再ビルドし、万一別環境で .a が未配置でも自動で -l sqlite3（OS 標準）へフォールバックします。
ここで実機テスト中に見つけた 古参エンジニア好みの重要な急所 が 1 つあります。
当サイトの検問ゲート（gemini-gate）は、Rust コードの品質を保つため rustc --edition 2021 --emit=metadata -D warnings で未使用変数や警告が 0 件かを毎回検査しています。もし Rust ソース側に #[cfg_attr(..., link(name = "sqlite3"))] のような独自フラグを書くと、メタデータ単体検査時に unexpected_cfgs エラーで弾かれてしまいます。
そこで、Rust ソース側（sqlite_ffi.rs 等）からは #[link(name = "sqlite3")] 属性そのものを削除し、rustc の -C link-arg オプション を使って起動ラッパー側でリンク対象を一元制御する 方式にしました（--emit=metadata はリンカを呼ばないため、属性なしでも警告ゼロで通過します）。
# run_kb_search.sh / run_gemini_gate.sh のリンク自動切替ロジック
SQLITE_STATIC_A=""
for cand_a in \
"$PROJECT_ROOT/_local_db/sqlite-lib/libsqlite3.a" \
"/opt/homebrew/opt/sqlite/lib/libsqlite3.a" \
"/usr/local/opt/sqlite/lib/libsqlite3.a"; do
if [ -f "$cand_a" ]; then
SQLITE_STATIC_A="$cand_a"
break
fi
done
# 静的ライブラリが更新されていたら次回起動時に自動で再ビルド
if [ -n "$SQLITE_STATIC_A" ] && [ "$SQLITE_STATIC_A" -nt "$BIN" ]; then
NEED_BUILD=1
fi
# .a があれば完全静的リンク、無ければ OS 標準 -l sqlite3 へ安全フォールバック
if [ -n "$SQLITE_STATIC_A" ]; then
SQLITE_LINK_FLAGS=(-C "link-arg=$SQLITE_STATIC_A" -C link-arg=-lz)
else
SQLITE_LINK_FLAGS=(-l sqlite3)
fi切り替え後に otool -L でビルド済みバイナリ（kb-search および gemini-gate）を検査した結果がこちらです。
# 改修前：OS標準の古い libsqlite3.dylib (3.43.2) に動的依存していた状態
kb-search:
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 360.1.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.12)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)
# 改修後：libsqlite3.dylib 依存が完全消滅し、3.54.1 がバイナリ内部へ一体化！
kb-search:
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.12)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)見事に /usr/lib/libsqlite3.dylib への動的リンクが消え、純粋なシステム基本ライブラリだけになりました。
実測結果：応答半減と新機能diskusedの威力
3.54.1 静的リンクへの切り替え完了後、kb-search --self-test（全項目合格・155.39ms）およびコンパイル無警告検査を通した上で、実際の運用データベースに対するパフォーマンスと最適化効果を計測しました。
応答2.92ms化と会話DBの325MB圧縮
まず、kb-search sql "SELECT sqlite_version(), sqlite_source_id();" を叩いた際の総所要時間と、sync --optimize（FTS5 インデックス統合＋VACUUM）を実行した実測ビフォーアフターです。
| 計測項目 | 移行前（OS標準 3.43.2 動的リンク） |
移行後（公式 3.54.1 AVX2 静的リンク） |
変化・改善幅 |
|---|---|---|---|
| 稼働 SQLite バージョン | 3.43.2（2023-10-10） |
3.54.1（2026-10-16） |
約 3 年分の世代刷新 |
| バッチ SQL 総所要時間 | 5.96 ms | 2.92 ms | 約 2.04 倍高速化（-51.0%） |
| 外部 SQLite 動的依存 | /usr/lib/libsqlite3.dylib あり |
なし（完全内包） | リンク切れリスク完全ゼロ |
| 会話履歴 DB（2,673 スレッド） | 988.1 MB | 662.2 MB | -325.9 MB（33.0% 圧縮） |
すごいじゃない！ クエリの応答が 5.96 ミリ秒から 2.92 ミリ秒に半分になって、会話履歴のデータベースも一気に 325MB もダイエットできちゃったのね！
MEMSTATUS=0 で内部ロックを省いたのと、母艦の CPU に合わせた -O3 -march=native 静的リンクがしっかり効いていますね。さらに FTS5 の断片化ページを optimize と VACUUM で整理したことで、RAM ディスクや OS キャッシュの空きも一気に広がりました！
新機能diskusedで見えたFTS5容量比率
そして今回もっとも感動したのが、SQLite 3.54 系で新搭載された .diskused コマンド です。最適化後の知識 DB（knowledge.sqlite：合計 288.2MB・全 70,373 ページ・空きリスト 0.0%・ペイロード充填率 92.2%）に対して .diskused を実行すると、どのテーブルがどれだけ容量を使っているかが一瞬で丸裸になりました。
この実測データから、「1〜2 文字の短い日本語検索を高速化するために追加した専用 N-gram 索引（ARTICLE_SECTIONS_SHORT_FTS_DATA）は、実は DB 全体の わずか 3.2%（2,287 ページ＝約 9.3MB） しか食っていない」という嬉しい事実まで裏付けが取れました。感覚や推測ではなく、こうしてページ単位の正確な数字で設計の妥当性を確かめられるのが .diskused の大きな魅力です。
まとめ：64GB母艦の延命単価とAI移行手順
今回の「macOS 標準 SQLite 3.43.2 固定問題」と「Intel Mac の Homebrew サポート終了」を乗り越えたポイントをまとめます。
sqlite.org から単一 C ソースを取得し、公式 SHA3-256 ハッシュと完全一致することを機械確認します。
母艦の clang -O3 -march=native で libsqlite3.a を生成し、_local_db/sqlite-lib/ へ永続配置します。
ラッパーが .a の更新日時を検知し、一時ビルドからの mv -f 置換と OS 標準フォールバックで安全に最新化します。
なお、「一度自前ビルドに切り替えたあと、今後の SQLite のバージョンアップ確認を忘れて放置しないか心配」という課題についても、続編の SQLite自前ビルドを自動更新する方法｜公式CSV解析とSHA3検証・自動復旧の実証録 にて、毎週金曜朝に sqlite.org 公式の機械可読 CSV と SHA3-256 を照合し、失敗時自動ロールバック付きで無人更新する仕組みまで完成させています。
サポート終了期でも光る64GB母艦の快適単価
今回のように Homebrew が Intel Mac サポートを終了しても、C コンパイラ（Apple Clang）と Rust（rustc）さえ手元にあれば、主要なミドルウェアは公式ソースから むしろ汎用配布バイナリより速い母艦 CPU 専用バイナリ として 20 秒で自炊できます。さらに 64GB メモリを積んでおけば、合計約 940MB の SQLite 知識・会話 DB を OS のメモリマップ（mmap）へ丸ごとのせ、SSD やハードディスクへの書き込み摩耗ゼロで 2ms 台の応答を引き出せます。
推論（試算）になりますが、約 20万〜25 万円クラスの 64GB メモリ搭載 Mac 母艦を 5 年間（1,825 日）毎日開発や執筆の拠点として使い続けた場合、1 日あたりの快適コストは約 110〜137 円（缶コーヒー 1 本分、1 日 4 時間稼働なら 1 時間あたり約 30 円前後） です。
これから新しく Apple シリコン環境へ移行して 64GB のオンメモリ DB・RAM ディスク母艦を組むなら、後からメモリ増設ができない構造を踏まえ、最初から 64GB ユニファイドメモリを選べる Apple Mac mini（Pro系チップ・64GB構成） が長期運用の頼もしい相棒になります。
また、27 インチ 5K Retina の広大な画面と手頃な価格で 64GB 環境を組みたい方には、今回の検証母艦でもある iMac 27インチ Retina 5K（2020年モデル） に、背面パネルから工具なしで増設できる 【Intel Mac増設用】Crucial DDR4-2666 SO-DIMM メモリ の組み合わせも、公式ソースの自炊テクニックと合わせればまだまだ現役で快走してくれます（※ DDR4 メモリは Intel Mac 専用のため Apple シリコン機には使用できません）。
そして、今回のように Rust から C 言語の静的ライブラリ（.a）を FFI で安全に呼び出す仕組みや、コンパイラ・リンカの挙動を体系的に理解しておきたい方には、定番の名著 オライリー・ジャパン『プログラミングRust 第2版』 を一冊手元に置いておくのがおすすめです。
OS の古いお下がりも Homebrew の機嫌取りも卒業して、公式の一枚岩ソースをカリカリに焼いたら 2 ミリ秒で返事してくれるようになったニャ。データベースも 325MB 軽くなったし、広々したメモリの上でぐっすりお昼寝するニャ〜。
最上位AIに安全な静的リンク移行を任せる手順
最後に、ご自身の Mac や Linux 開発環境でも「うちの CLI やアプリが実は古い OS 標準 SQLite を掴んでいないか調べ、安全に最新版の静的リンクへ切り替えたい」という方へ、そのまま使えるプロンプトを用意しました。
リンカフラグの優先順位や #[link] 属性と静的解析（--emit=metadata -D warnings）の干渉、無停止アトミック置換の設計は、軽量モデルに任せるとビルド不能や動的リンク吸われを起こしやすい領域です。必ず 『Gemini 4 Argon』または同等以上の最上位推論モデル を選び、以下のプロンプトを貼り付けて現状診断から進めてみてください。
以下の記事 URL の検証手順（OS 標準 SQLite 3.43.2 混入の実測確認、公式 Amalgamation の SHA3-256 検証＆ -O3 -march=native 静的ライブラリ生成、Rust FFI での動的依存排除と -C link-arg 優先リンク＋未配置環境での自動フォールバック、.build.$$ からの mv -f 無停止アトミック置換）をすべて精読してください。
https://lab.chihouzakki.com/blog/review/sqlite-354-macos-amalgamation-rust-static-link/
【厳守してほしい手順】
- いきなりファイルを書き換えず、まず私のプロジェクト内の全バイナリ・スクリプト・Cargo 設定を調査し、「現在実際に実行時にリンクされている SQLite バージョン（
SELECT sqlite_version()およびotool -L/ldd）」を実測して日本語で報告してください。 - Cargo プロジェクトなら
rusqlite（bundled）等の最適な更新案を、外部依存ゼロの Pure Rust / C プロジェクトなら公式 Amalgamation 静的リンク＋自動フォールバック案を計画として提示してください。 - 私が計画に合意したら、事前バックアップを取得した上で無停止移行を実行し、移行後の
otool -L（動的依存消滅確認）・自己テスト・.diskused容量診断の結果まで報告してください。