AIエージェントのタスク管理にクラウドデータベースのTursoを使おうとしたところ、同じSQLなのに接続方法によって応答時間が大きく違うことが分かりました。AIエージェントからMCP経由で呼ぶと平均10.03秒。別のChatGPTセッションでは平均1.20秒。一方、GitHub Actionsから公式libSQLドライバーで直接接続すると平均0.266秒でした。
約37.6倍という差を見て、データベースを乗り換える前に「何の時間を測っているのか」を切り分ける必要があると感じました。さらに、直接接続を定期実行へ導入しようとすると、今度はSecrets管理が障害になりました。ここでは、確認できた数値と、まだ分からないことを分けて整理します。
同じTursoへの件数取得が10秒かかった
実行したのは、テーブルの件数を返すだけの単純なSQLです。
SELECT COUNT(*) AS task_count FROM tasks;AIエージェント側のMCP呼び出しは10回とも成功しましたが、平均10.03秒、中央値8.13秒でした。同じTursoの公式MCPをChatGPTから使った場合は、5回の平均が約1.20秒でした。MCP側はツール呼び出しから結果返却までを計測しており、AIの文章生成時間は含めていません。
接続方式別の平均応答時間
- AIエージェント → Turso MCP：10.03秒（10回成功）
- ChatGPT → Turso MCP：1.20秒（5回成功）
- GitHub Actions → libSQL直接接続：0.266秒（10回成功）
この比較では、AIエージェント側のMCP経由がChatGPT側より約8.4倍遅くなりました。ただし、MCPサーバーが同じでも、認証セッション、通信経路、内部の待機処理まで同一とは限りません。
ほかのMCPは速かった
AIエージェント全体が遅いのかを調べるため、同じ実行環境から別のMCPサービスも計測しました。GitHub MCPは平均0.455秒、別のツール連携は平均0.823秒。Turso MCPだけが大きく遅い結果でした。
追加のTurso計測では23.268秒と6.451秒を記録しました。続く呼び出しはキャンセルされ、追加の10回連続計測は完了していません。これを成功した10回の追加検証として扱うことはできません。
この時点で、すべてのツール呼び出しに共通する遅延という説明は弱まりました。ただし、Turso固有のOAuth処理、MCPサーバー内部のキュー、ネットワーク、再試行のどこが原因かは特定できていません。
公式ドライバーで直接接続すると平均0.266秒
次に、MCPを経由せず、公式のNode.js用libSQLドライバー（@libsql/client 0.18.0）から同じSQLを10回実行しました。認証情報を安全に扱えるGitHub Actionsを一時的なベンチマーク環境として利用しました。こちらの応答時間はSQL実行要求から結果を受け取るまでで、Actionsのジョブ起動待ちやパッケージ導入時間は含んでいません。
libSQL直接接続の10回計測結果
- 平均：0.266秒
- 中央値：0.143秒
- 最速：0.137秒
- 最遅：1.075秒
- 10回合計：2.666秒
AIエージェント側のMCP平均10.03秒と比べると約37.6倍の差です。初回が最も遅く、2回目以降は比較的短時間で応答しました。
ただし、GitHub ActionsとAIエージェントのクラウド環境は異なります。この結果だけで「同じエージェントから直接接続しても37.6倍速くなる」とは言えません。それでも、TursoのSQL処理自体が常に数秒かかるという仮説はかなり弱まりました。
次の障害はSecretsの受け渡しだった
直接ドライバーを通常運用で使うには、Tursoの接続URLと認証トークンが必要です。MCP連携ならプラットフォーム側がOAuth認証を管理してくれますが、独立したNode.jsプログラムは、その認証情報を自動的には引き継げません。
そこで、GitHub Actions Secrets、Codex CloudのSecrets管理、外部のSecrets保管サービス、ローカルのKeychainなどを検討しました。
- GitHub Actions Secrets：Actions内での利用は実証できました。ただし、AIエージェント自身の定期実行に値が自動で渡されるわけではありません。
- Codex CloudのSecrets管理：機能は存在しますが、別の定期実行基盤でも利用できるかは確認が必要です。
- 外部Secrets管理：安全に保存できても、取得側を認証する方法が別途必要です。
- ローカルKeychain：ローカル実行には使えますが、クラウド側から直接参照できるわけではありません。
GitHub Actionsから毎回SQLを代行する方法も考えられますが、ジョブ起動の待ち時間や運用の複雑さが増えます。今回は速度検証のみに使い、通常のDB操作の中継には採用しない方針です。
高速なDBを選ぶだけでは自律運用にならない
今回の調査で、少なくとも三つの課題を区別する必要があると分かりました。データベース自体の性能、MCPを含む接続経路の性能、そして定期実行環境への認証情報の安全な供給です。
現時点では、直接ドライバーの性能を別環境で確認できた一方、AIエージェント自身の定期実行でSecretsを永続的に利用する正式な経路は確認できていません。また、実際のタスク更新には読み取りだけでなく、トランザクションと排他制御の検証も必要です。
したがって、Tursoを別のDBへ置き換える判断は保留しています。まずは、認可された直接接続と安全なタスク更新を実行できる環境を整えることが次の課題です。
AIエージェントの自律化では、モデルの性能だけでなく、認証、通信、状態管理、実行環境の設計が実用性を左右します。今回の「遅いDB」という疑いは、調べるほど「接続経路とSecrets管理」の問題へと変わっていきました。