【本番環境のデバッグ革命】AIエージェントが「その場」でデータ抽出！HyperProbe (YC S26) を公開

皆さん、こんにちは！ShailendraとKaranです。私たちは今、AIコーディングエージェントが本番環境でライブデバッグを行うための、高速かつ安全な仕組み「HyperProbe」を開発しています。本番環境で障害が発生した際、CursorやClaudeといったAIエージェントが、実行中のコードに安全な仮想ブレークポイントやプローブを設置し、ログには残らない詳細な変数値をリアルタイムで抽出できるようにします。これにより、エンジニアがログを掘り返したり、console.logやprintデバッグのために再デプロイを繰り返したりする苦痛な作業から解放されます。詳細はこちらの解説動画をご覧ください: https://www.youtube.com/watch?v=ivV7I--ta5c 現在、コードの多くはAIが書いていますが、デバッグに必要なコンテキストが不足しがちです。従来の「ログを確認→原因を推測→追記して再デプロイ」というループは、トークン消費が激しく、時間もかかるため、オンコール担当者のストレス源となっていました。HyperProbeのアプローチは、障害発生の瞬間に必要なテレメトリをオンデマンドで取得することで、この「再デプロイ地獄」を終わらせ、最小限のトークン消費で正確な根本原因分析（RCA）を可能にします。仕組みは、SDKとMCPサーバーの2階層です。SDKはサービス内で動作し、本番環境のトラフィックを止めずに実行状態を読み取ります。Node.jsやPythonではインプロセスで、JavaではJVMエージェントとしてバイトコードレベルでインストゥルメンテーションを行います。エージェントがMCP経由で特定の行を指定すると、プローブが設置され、その瞬間のコールスタックと変数値を取得します。もちろん、パスワードやクレジット情報などはインプロセスで自動的に検閲（Redact）され、外部に漏れることはありません。さらに、すべてのコンポーネントを自社インフラ内で完結させるセルフホストにも対応しています。オーバーヘッドは無視できるほど小さく、アイドリング時はほぼゼロ。アクティブ時も厳格に管理されており、パフォーマンスに影響が出る前にプローブが自動解除される安全設計です。現在、Node.js、Java、Pythonをサポートしています。ぜひ皆さんの環境でお試しいただき、AIエージェントと対話しながらデバッグする体験を試してみてください！

インプロセスでのRedaction（編集・検閲）設計は、真っ先に評価したい部分だね。どの値がキャプチャされて、各プローブのヒットに対してどのRedactionルールが適用されたかを監査する方法はあるの？

ローンチおめでとう！本番環境のサービスに読み取り専用のプローブを仕込めるおかげで、面倒な再デプロイをせずに済むのはかなりの時短になるね。私のワークフローはクラウドベースの開発に大きく依存しているから興味があるんだけど、コンテナのライフサイクルが極端に短いサーバーレス環境では、SDKはどう対応しているの？すごく素晴らしいコンセプトだね！

本番環境でのデバッグって昔から興味深いテーマだよね。Rookoutとかもあるし。

仕組みはどうなっているの？Node.jsのinspector APIや、他の言語で同等のものを使ってブレークポイントを挿入しているのかな？その手のAPIは多くのサーバーレス環境では使えないし、バンドラーと併用するのも難しいからね。

ローンチおめでとう。プローブは設計上読み取り専用とのことだけど、デバッグには理にかなっているね。逆の側面について気になったんだけど、エージェントが書き込みを行って、それが間違っていた場合のことだよ。書き込み前の状態をキャプチャして、実際に「取り消し可能」にするアプローチを検討したことはある？同じようなインストゥルメンテーション（インプロセスで再デプロイ不要）が適用できそうだけど、この「取り消し可能」という部分は今のところほとんど未解決な気がする。

あなたはインシデントを「修正」した。しかし、どうやって修正したのかは理解していない。

何が壊れたのかも分からず、どうやって直したのかも分からないなら、あなたは一体何について「理解している」と思っているんだ？

ローンチおめでとう！すごく良さそうだね。

こういう優れた可観測性ツールを持っていない人（私のような人）のために、https://shellshare.net (免責事項: 私が作りました) を紹介させて。

これはコマンド一つで、エンドツーエンド暗号化されたターミナルをライブ共有できるツールだよ。元は授業や同僚へのサポート用だったんだけど、エージェントにもすごく便利なんだ。本番環境にSSHしてこう実行する：

npx shellshare exec --json -- tail /var/log/my-app.log

これでURLが生成されるから、エージェントにこう伝える：

monitor <URL>, instructions in https://shellshare.net/llms.txt

するとリアルタイムで出力が見えるというわけ。エージェント側のマシンに何もインストールする必要はないよ。次のshellshareのバージョンでは「monitor <URL>」と打つだけで、エージェントの指示もそのURL内に含められるようにする予定。

君たちが作ったものには遠く及ばないけど、自分には役立っているよ。スタートアップ頑張って！

面白い技術だけど、ランディングページが「デザインに手間をかけていない」ことを主張しすぎているかな。Claudeのデフォルトデザインっぽいオレンジと茶色の配色からは変えたほうがいいかも。

こういう本番インメモリデバッグの有益な補助ツールとしては、AWS等での読み取り専用の権限でロックダウンされたエージェントロールがあるよ。確かAmazonが最近、そういうロールを設定するためのウィザードを用意したはず。これを使えば、Terraformなどで機密情報を露出したり変更を加えたりすることなく、エージェントが安全に本番環境の状態を確認できるようになるよ。

ここには2つの要素がある。サービス内で動くSDKと、コーディングエージェントが通信するMCPサーバーだ。SDKのおかげで、再デプロイなしでプローブ（仮想ブレークポイント、ログ、メトリクス）を設定できる。NodeとPythonではインプロセスでフックし、JavaではJVMエージェントとしてアタッチしてバイトコードレベルでインストゥルメンテーションを行う。どちらにせよサービスは停止せず、トラフィックを処理し続ける。何も一時停止しないよ。

この説明を、ピッチの2/3あたりではなく、冒頭の近くに持ってきたほうがいいよ。ドラマチックな1〜2文の段落がテレビCMみたいで嫌気がさして、読むのをやめるところだった。ターゲット層はCTOやその部下ではなくエンジニア自身だと思うし、もっと時間をかけずに本題に入るような構成が必要じゃないかな。

ともかく、MCP管理のパッシブデバッガーは便利なツールになりそうだね。応援してるよ。

ローンチおめでとう。「読み取り専用」という保証は、私にとってセキュリティレビューを通すための鍵になる部分だね。その約束が実際にはどこまで適用されるのか気になるよ。「読み取り専用」はSDKレベルで強制されているのか（つまり、プローブが副作用のある関数を呼び出すことが物理的に不可能か）、それとも設計上のコンベンションに過ぎず、理論上は悪意のある、あるいはバグのあるプローブ定義で破られる可能性があるのか。コンプライアンス要件が絡むデータに触れる場合、その保証が構造的なものなのか、それとも現在の挙動に過ぎないのかを知っておきたいな。