どの関数、どのクエリ、どのデプロイか。

何を測るか

エクスポートされたすべての非同期関数

どれだけ時間がかかり、そのうちどれだけが自分自身のコードで、どれだけが呼び出した先だったか。「遅くなったのは自分のコードか、呼んだ先か」が、午後ひとつではなく数値ひとつになります。

5つのクライアントにわたる全クエリ

pg、mysql2、postgres.js、MongoDB のドライバ、Prisma — 自動で見つけて計測します。Mongoose 越しでも、負荷のかかったコネクションプール越しでも。返却行数、カラム数、レスポンスサイズ、そして MongoDB については1回の読み取りが実際に何往復のネットワークを必要としたか。

どの関数がどのクエリを出したか

残りを読む価値のあるものにしている部分です。クエリはその上にある関数に帰属するので、N+1 はループを持っている関数の上に出ます。いつも問題なく見えていたクエリの側に散らばりません。

データベースが答えるために何をしたか

Postgres には各文のプランを尋ねます — パラメータを一度も束縛せずに、なので、あなたの値は一切関わりません。MySQL は代わりに performance_schema から読みます。返却行あたりの走査行数と、そもそもインデックスが使われたかどうか。どちらも同じ検出として届きます。「これはそのテーブルをインデックスなしで読んでいる」と。

あなたの HTTP ルート、受けと出し

処理したリクエストと、他人の API を待っていた時間 — 遅いサードパーティが「あなたのコードが遅い」として報告されなくなります。

何を見つけるか

どれも1つ前のリリースと比較されます。だから検出結果は、日付ではなく変更を名指しします。

フィードに何が届くか

読むためのダッシュボードではありません。検出1件につきカード1枚。数値と、それを変えたリリースと、コーディングエージェントが修正を書くのに必要な証拠が付いています。

導入方法

すでに開いているコーディングエージェントに渡してください。リポジトリを読み、それが Next の設定なのか、Vite プラグインなのか、起動コマンドなのかを判断して組み込みます — そして同じ会話の中で、見つかったものを直します。

claude mcp add sixty \
  -e SIXTY_API_KEY=sixty_sk_… \
  -e SIXTY_ENDPOINT=https://ingest.sixty.sh \
  -- npx -y @sixty-sh/mcp

# or by hand, in your server entry:
import { init } from '@sixty-sh/node'
init()

リリース識別子は Vercel、Render、Railway、Fly、Heroku、GitHub Actions から自動で拾われます。最初の比較は次のデプロイのあとに届きます。1つのリリースには比べる相手がないからです。

できないこと

• MySQL と MongoDB はプランのツリーを返しません。MySQL の EXPLAIN には実際のパラメータ値が、MongoDB の explain には実際のフィルタが必要で、このエージェントは値を見た瞬間に捨てます — なので MySQL では代わりに performance_schema から結論を読み、MongoDB についてはまだ何もありません。
• 非同期ジェネレータはビルド時の変換が飛ばします。包んでしまうと「呼び出し側がイテレータを受け取るまでの時間」を測ることになり、それは誰も欲しくない数値だからです。
• エージェントが測るのは JavaScript から届く範囲です。ネイティブモジュールの中や別プロセスで使われた時間は、待ち時間としてしか見えません。

これが理由でここに来たのなら