Armature、MCPセッションをアナリティクスと段階的評価に変える

Why it matters

As customers delegate software tasks to AI agents, vendors lose visibility into intent and outcomes. Armature is linking production traces to regression tests before incumbents absorb the category.

Theodore Otzenberger (@Totzenberger) と Louis Scremin は7月22日に Armature を立ち上げ、顧客が Claude、ChatGPT、その他の AI クライアントを通じて自社製品を使用したときに何が起きるかをソフトウェア制作者に示すことを目的としています。Armature は Model Context Protocol サーバーからセッションを再構築し、それらをユーザーの意図ごとにグループ化し、最も多くのワークフローを壊す障害をランキングします。

創業者たちは同じプロダクションのギャップの反対側からこの問題に行き着きました。Otzenberger は Palantir に勤務し、その後 Tsuga でオブザーバビリティ基盤を構築しました。Scremin は Joko で AI 自動化を率い、エージェントと MCP サーバーを消費者向けプロダクト（ユーザー数 600 万）に導入する手助けをしました（Y Combinator の Armature のプロフィール による）。YC は Armature を Spring 2026 の 3 人組企業として掲載しています。

彼らの創業仮説は、Scremin が Joko で直面した運用上の問題に基づいています：内部テストでは正しく動作する MCP サーバーでも、数百万件の予測不可能なリクエストに跨って失敗する可能性があるということです。Otzenberger は、そうしたやり取りをプロダクトやエンジニアリングチームが検査できる形に変えるために必要なトレーシングの知見をもたらしました。

Otzenberger はローンチスレッドで問題を次のようにまとめました：「You get the raw tool calls, never the user intent.」

Theodore Otzenberger on X

その区別が Armature の出発点です。

From tool calls to product behavior

従来のプロダクト分析は、ソフトウェアベンダーが制御するインターフェースを計測します。ページビュー、ボタンクリック、完了したファネルといったイベントは、相互作用がベンダーのアプリケーション内で発生するため結び付けられます。

エージェントを介したセッションは別の場所で発生します。顧客が Claude や ChatGPT に請求書を作成するよう依頼したり、サブスクリプションを更新したり、支払いを照合したりするかもしれません。ソフトウェア提供者はツールへの呼び出しを受け取りますが、それらの呼び出しだけでは元のリクエスト、エージェントの計画、あるいは最終的な結果が顧客の目的を満たしたかどうかを示さない場合があります。

Armature の ローンチ発表 は、再構築されたセッション、クラスター化されたユースケース、グループ化された問題という三層を説明しています。ダッシュボードはツール呼び出しと結果をリプレイし、その後 Armature のモデルがユーザーが何を達成しようとしたかを分類し、ループ、行き止まり、サポートされていないリクエストを特定します。基礎となる API リクエストがすべて 200 ステータスコードを返していても、ワークフローは失敗としてマークされることがあります。

実装は既存の MCP サーバーの周囲に Armature SDK を追加する形です。Armature は現在 TypeScript、Python、Go、PHP の SDK を文書化しています。彼らの telemetry documentation は、SDK が各計測対象ツールの入力スキーマに任意の telemetry オブジェクトを追加し、ユーザーの意図、エージェントが報告する思考、認識されたユーザーのフラストレーションのフィールドを含むと説明しています。同じドキュメントは、それらの任意フィールドを無視するエージェントでもツール呼び出し、タイミング、結果を含むセッションを生成することを述べています。

その注意書きは重要です。Armature はすべてのモデルから完全な内部推論記録を独自に抽出しているわけではありません。より豊かなセッションコンテキストの一部は、呼び出し側のエージェントが Armature がスキーマに追加する任意の telemetry フィールドを提供することに依存します。

Armature の telemetry documentation はまた、分析対応 SDK が、既存のツールで対応できないユーザーのニーズがある場合に備えて、任意の capability-request ツールを登録することができると述べています。これらの呼び出しは、プロダクトチームに未充足の需要を構造化された形で提示し、失敗したリクエストを将来のロードマップ入力に変えるのに役立ちます。

Production evidence becomes regression tests

7月22日の発表では、テスト製品が後に続くと述べられていました。8月3日までに、Armature の evaluation documentation は、評価をワークスペースごとのロールアウトとして説明し、各ワークスペースごとにアクセスを個別に有効化すると記しています。

有効化されると、評価製品は定義されたユーザーゴールを使ってデプロイされた MCP サーバーに対して実際のエージェントを動作させます。別のジャッジモデルが、顧客が作成した基準に照らして結果のトレースを採点し、Armature の scoring documentation によれば 0 から 5 のスコアと passed、partial、failed のどれかの結果を出します。evaluation overview は、ランは手動、スケジュール、あるいは継続的インテグレーションパイプラインから開始できると述べています。

Armature のより鋭いプロダクト判断は、分析とテストの間の接続にあります。繰り返されるプロダクションユースケースは eval ケースになり得ます。ライブセッションで発見された失敗は、その後の修正が保たれていることを証明するための回帰テストになる可能性があります。Armature は、顧客がテストを保存する前に生成されたプロンプトと基準を確認すると述べています。

これにより、観測、優先順位付け、検証にまたがるフィードバックループが生まれます。また、単なるセッションリプレイダッシュボードよりも広い領域を Armature に与えます。分析製品は外部から制御されるエージェントが MCP サーバーをどのように使っているかを特定し、評価レイヤーは同じジョブがリリース後も引き続き動作するかをチェックします。

アクセスは段階的に提供されます。Armature の documentation は、評価はワークスペースごとに有効になり、アカウントに機能が表示されない場合は顧客がアクセスをリクエストできると述べています。無料ワークスペースは毎月完了したランを 100 回受け取り、スケジューリングは有料プランで開始されます。

A category built around the missing interface

Armature は PostHog、Amplitude、Mixpanel といったプロダクト分析製品と、LangSmith や Langfuse といったエージェント観測製品の間に位置付けられています。Armature の主張は、前者のグループはベンダーが所有するインターフェース内での挙動を測定するのに対し、後者は一般的にベンダーが構築するエージェントに向けられている、というものです。Armature は MCP を通じてベンダーのプロダクトを操作する外部エージェントに焦点を当てています。

その区分は Otzenberger と Scremin に具体的な切り口を与えますが、既存の分析、オブザーバビリティ、MCP インフラベンダーは重複する機能を追加する可能性があります。Armature の防衛は、セッション再構築とプロダクションから評価へのワークフローが再現困難になるかどうか、またプロダクトチームがエージェントの振る舞いを独立した分野として予算を割いて扱うかどうかにかかっています。

Armature はその分野を "Agent Experience"、または AX と呼んでいます。そのラベルは野心的で、エージェントがソフトウェアと顧客の間に立つ場合のコンバージョン、サポート、リテンションに関する将来の課題を含みます。最初のプロダクトはより狭く評価しやすいものです：開発者に人々がエージェントに何を頼んだかを伝え、ツールがどこで失敗したかを示し、コストのかかる失敗をテストに変換します。

Armature の pricing page は、最初の毎月 1,000 件の分析セッションを無料とし、追加の 1,000 件ごとに $50 を課金、無料プランの保持期間は 7 日間であると記しています。Armature は、システムがストレージ前にセッションを個人情報やシークレットの有無でスキャンすると述べています。彼らの telemetry documentation は、アクターの識別は顧客のサーバー上で導出された SHA-256 ハッシュで表現され、キャプチャされた入力と結果のプレビューはそれぞれ 8 KiB に制限されると説明しています。

Otzenberger と Scremin にとって、タイミングは単純な賭けに基づいています：MCP サーバーはほとんどのソフトウェアチームがそれを測定する方法を学ぶ前に顧客向けの接点になりつつある。Armature は、オペレーティング習慣、ツール選択、カテゴリ境界がまだ形成されているうちに、その測定レイヤーを掌握しようとしています。