Novus登場：プロダクトエージェントという新しい形

ずっと引っかかっていたことがあります。

AIによって、チームはこれまでにないスピードでプロダクトをリリースできるようになりました。一方で、「何をリリースしたのかを理解する仕組み」は、まったく進化していません。いまだに誰かが手動で機能をタグ付けし、ダッシュボードを維持し、思い出したときにそれを確認しています。

しかし、その「誰か」はもう追いつけません。遅れが出ると、意思決定に使われるデータは、実際に本番で動いているプロダクトとの間で静かにズレ始めます。ルートは変更され、機能はリファクタリングされ、新しいワークフローが追加される。それでも計測は追従しない。

私たちはこれを「アナリティクスドリフト」と呼ぶようになりました。一度コードベースでそれを目にすると、もう見過ごせません。

課題解決のために生まれたNovus

この問題に向き合う開発者のために、私たちはNovusを開発・リリースしました。

Novusはコードベースに直接接続し、リリースのたびに自動で計測・分析・改善を行うプロダクトエージェントです。エンジニア、AIエージェント、そして高速に開発を進めるプロダクトチームに対して、常に最新かつ正確なプロダクトの状態を提供します。

なぜ今、Novusが必要なのか

いま、AIを活用するすべてのチームで共通の問いがあります。

「どうすれば、エージェントやモデルに“役に立つ仕事”をさせるための文脈を与えられるのか？」

プロンプトを改善することも、スキルを増やすことも有効です。しかし、本当に成果を左右するのは「プロダクトの現実に基づいた理解」です。

つまり、

• プロダクトがどう動いているのか 
• ユーザーが実際にどう使っているのか 

この“正確で最新の全体像”です。

プロダクトデザインの責任者としてClaude Codeを使ってきた経験からも明確です。AIのアウトプットが有用かどうかは、この文脈に依存します。

ユーザーの行動やフィードバック（誰が使い、どこで詰まり、何が重要なのか）を理解していれば、AIはより速く、より良い意思決定ができます。逆にそれがなければ、「動くもの」は作れても、ビジネスを成長させる判断はできません。

問題の本質：プロダクトの実態が把握できていないこと

多くのチームでは、この「現実に基づいた理解」は以下の状態にあります。

• そもそも存在しない 
• 古くなっている 
• 誰かの頭の中に閉じている 

そしてプロダクトがリリースされるたびに、その精度は劣化していきます。

この問題は、人間だけでなく、コードベースと共に動くすべてのエージェントやツールにとってのボトルネックです。

Novus設計の前提条件

Novusは、この制約を前提に設計されています。

• コードからプロダクトを理解し、手動タグ付けを不要にする 
• コードの変更に追従し続ける（劣化する計測は無意味） 
• 誰かが聞く前に重要な情報を提示する（常時観測） 
• インサイトを実行可能な形に接続する（PRやプロダクト変更） 
• 最終判断は常に人間が行う（Novusは提案、承認は人間） 

Novusの仕組み

Novusは「Cortex」という中核レイヤーの上で動作します。

Cortexは、以下を統合した“生きたプロダクトモデル”です。

• プロダクトの構造 
• コード 
• ユーザー行動 
• ビジネス成果 

これらを手動設定なしで継続的に更新し、単一の理解として保持します。

Pendoが長年構築してきた以下の基盤もここに統合されています。

• アナリティクス 
• セッションリプレイ 
• フィードバック 
• 予測 

コードベースが変われば、Cortexも自動で更新されます。つまり、常に本番環境の実態に基づいたインテリジェンスが維持されます。

リリースの流れで理解するNovus

Step 1：リポジトリ接続 → 構造マップ生成

GitHubリポジトリを接続するだけで開始できます。

Novusはコードを読み取り、「Memory」と呼ばれる構造マップを生成します。

含まれる要素：

• ルート 
• UIコンポーネント 
• ユーザー識別パターン 
• イベント候補（クライアント／サーバー） 
• ワークフロー 

AIエージェントも検出・計測されます。さらに：

• セッションリプレイのプライバシー設定 
• ガイドのUIテーマ設定 
• オンボーディング（役割・目標の取得） 

数分で、PMが数週間かけて作るレベルの理解が生成されます。そしてこれは常に更新され続けます。