Cursor（AIペアプログラミングを支援するコードエディタ）を日常的に使っていて、月末の請求額を見て「結局どのセッションがコストを押し上げたのか分からない」という状態になっていないでしょうか。個人開発者でも小規模チームでも、Cursorの使用量メーターは上がる一方で、内訳を追う手段が標準では限られています。この記事では、Cursorの利用状況を外部から可視化・分析する仕組みを自分で持つべきかどうかを、アーキテクチャ上の判断軸で整理します。
具体的には、MCP（Model Context Protocol、AIエージェントが外部ツールやデータソースと通信するための標準プロトコル）対応のログ収集基盤「ZizkaDB」を例に、導入の是非を考えます。ZizkaDBはCursor用のMCPサーバーを提供しており、接続すればモデル別・セッション別・ステップ別のトークンコスト内訳を取得できる、という触れ込みです。ただしこれは「導入すれば自動的に節約できる」類のものではなく、データ基盤を一つ追加する意思決定だという点を押さえておく必要があります。
どんな場面でこの判断が必要になるか
判断が必要になるのは、Cursorの請求額や使用量メーターの上昇に対して、原因の切り分けができていない場面です。
たとえば複数プロジェクトでCursorを使っていて、どのプロジェクトがClaudeやGPT系の重いモデルを多用しているか分からない、というケースです。あるいはチームでCursorを共有していて、個人ごとの消費量を可視化したいが、Cursor標準のダッシュボードでは粒度が粗い、という場面もあります。
こうした状況で「外部にログ基盤を足すべきか」「標準機能で我慢できるか」を決めるのが、この記事で扱う判断です。
判断軸1: データの所在とプライバシー境界
ZizkaDBにはセルフホスト版（OSSとしてGitHubで公開、Dockerで自前運用）と、マネージドクラウド版（db.zizka.aiにホストされるSaaS）の2種類があります。
セルフホストならプロンプトやコードのコンテキストは自分のPostgresに残ります。マネージドクラウドを使う場合は、その情報がdb.zizka.aiという外部サービスに送られます。
ここで見落としがちなのは、ログに残る内容そのもののリスクです。APIキーや認証情報をプロンプトやCursorのルールファイルに書いていると、それもログとして保存される可能性があります。どちらの構成を選んでも、機密情報をプロンプトに含めない運用ルールは別途必要です。
判断軸2: 運用コストと可観測性のトレードオフ
セルフホスト版の導入にはuv（Pythonパッケージ管理ツール）経由のuvxコマンドと、Dockerが必要です。クイックスタートスクリプトを使えば起動できますが、初回のイメージ取得だけで5〜10分かかるとされています。
curl -fsSL https://raw.githubusercontent.com/Zizka-ai/ZizkaDB/main/scripts/quickstart-remote.sh | bash起動後はAPIがhttp://localhost:8000、ダッシュボードがhttp://localhost:3001/loginで立ち上がります。これは言い換えると、常時稼働させるコンテナが1つ増え、監視・アップデート・バックアップという運用負荷が発生するということです。
個人開発であればDocker Desktopで動かす程度で済みますが、チームで使うとなると「誰がこのコンテナを維持するのか」という運用の所有者を決めておく必要があります。これはSRE（サイト信頼性エンジニアリング）の文脈でよく出てくる「監視対象を増やすこと自体のコスト」と同じ構造です。
判断軸3: 可視化の粒度と観測できる範囲の限界
ここが最も見落とされやすいポイントです。MCPサーバーは受動的な記録装置ではなく、Cursorのエージェントが能動的にlog_eventを呼び出したときだけイベントが記録されます。
つまりセッションが空っぽに見える場合、ZizkaDB側の不具合ではなく、エージェントがそもそもログ呼び出しをしていない可能性が高いということです。対策として、.cursorフォルダやAGENTS.mdにログを促すルールを明記する運用が案内されています。
さらに、トークン数やコストはモデル名とトークン数が実際にイベントデータに含まれていて初めて算出されます。ダッシュボードで実際のイベントを1件開き、モデル名とトークン数の両方が入っているか確認する作業が欠かせません。欠けていたり推定値だったりする場合、コスト数値はあくまで参考値として扱い、Cursor標準の使用量ページと突き合わせる必要があります。
判断軸4: 導入のオーバーヘッドと得られる粒度の見合い
MCPサーバーへの接続自体は~/.cursor/mcp.json（または プロジェクト単位の.cursor/mcp.json）に数行追加するだけで完了します。
{
"mcpServers": {
"zizkadb": {
"command": "uvx",
"args": ["zizkadb-mcp"],
"env": {
"ZIZKADB_HOST": "http://localhost:8000"
}
}
}
}接続作業は数十秒で終わります。問題はその先で、1週間ほど普段通り使ってベースラインを取り、合計トークン数・推定コスト・モデル別内訳・入力トークンと出力トークンの比率・セッションあたりの平均コストを記録する、という運用ステップが必要になる点です。
ここで初めて「どのモデルが高コストの主因か」「どのセッションパターンが無駄が多いか」が見えてきます。導入の手軽さと、実際にインサイトを得るまでの手間は別物だと捉えておくべきです。
選択肢の比較
| 選択肢 | データの所在 | 運用負荷 | 向いているケース |
|---|---|---|---|
| Cursor標準の使用量ページのみ | Cursor社のサーバー | ほぼゼロ | 大まかな月次トレンドだけ分かれば十分 |
| ZizkaDBセルフホスト | 自分のPostgres | Docker運用・監視が必要 | コード・プロンプトを社外に出せないチーム |
| ZizkaDBマネージドクラウド | db.zizka.ai | 低い（APIキー管理のみ） | 個人開発者・小規模チームで早く試したい場合 |
ケース別の推奨
個人開発でCursorの請求額がなんとなく気になる程度なら、まずCursor標準の使用量ページで十分です。モデル別・プロジェクト別の内訳が本当に必要になった段階で、マネージドクラウド版を試すのが手堅い順序です。
社内規定でコードやプロンプトを外部SaaSに送れない条件があるチームは、セルフホスト版一択になります。この場合はDockerとPostgresの運用体制がすでにあることが前提で、なければ先にその整備から着手することになります。
複数人でCursorを使い、個人やプロジェクト単位でコスト配分をしたいチームには、エージェント名を分けて管理できる仕組みが向いています。マネージドクラウド版ではテナント単位のキーも発行できるため、複数のエージェント名を使い分けたい場合はこちらが扱いやすい構成です。
あえて見送るべき条件
以下のいずれかに当てはまる場合は、導入を急がない方が無難です。
- Cursorの月額請求が組織の予算に対して誤差程度で、最適化の投資対効果が小さい
.cursorフォルダやAGENTS.mdにルールを書き足す運用を、チームとして継続できる体制がない- Dockerコンテナを1つ追加で保守する余力がなく、代わりに監視対象が増えるだけになる
- プロンプトに認証情報や機密コードを含める習慣があり、それを先に是正できていない
特に最後の項目は、ログ基盤の種類に関わらず優先して対処すべき事項です。外部に記録が残る仕組みを導入する前に、ログされて困るものがプロンプトに混在していないか、棚卸しをしておく価値があります。
まとめ
Cursorのコスト可視化を自前で持つかどうかは、「データの所在」「運用コスト」「可視化の粒度」「導入オーバーヘッド」の4軸で判断できます。
導入前に試せる具体的な一歩としては、まずpip install zizkadb-sdk && zizkadb demoでログの仕組みだけを単体で試し、Cursorを巻き込む前に動作を確認するのがおすすめです。
そのうえでMCP接続を追加し、1週間は最適化せずにベースラインのトークン数とコストを記録してみてください。ダッシュボード上の1件のイベントを開いて、モデル名とトークン数が実際に記録されているかを確認する作業も忘れずに行っておくと、後々のコスト分析が数字遊びで終わらずに済みます。