【2026年】Kubitでエージェントを分析｜記録を自社の基盤に置く

「エージェントの実行記録は開発チームの観測ツールの中にあって、マーケやCSの担当者からは見えない」「記録を外部のサービスに送ってよいのか、そのたびに情報システム部門との調整で止まる」——社内でAIエージェントを動かし始めた企業で、2026年に入ってから増えてきた声です。製品分析基盤の Kubit は2026年10月、エージェントの実行記録を、自社のデータウェアハウスの中で、事業の数字と同じ場所で分析する機能の早期提供を告知しました。記録をどこで見るかは、道具の好みの問題ではありません。誰が失敗に気づき、誰が直す判断をするかを決める、体制の問題です。この記事では、Kubit のエージェント分析を例に、記録を事業部門の分析と同じ場所に置く意味、データを社外に出さない構成、AIによる判定を誰が検証するか、早期提供の段階で入れるかどうかの判断を整理します。

Kubit は何をする製品か：データウェアハウスの上で動く製品分析

Kubit は、アプリやウェブサービスの利用者の行動を分析する製品分析の基盤です。特徴は、分析するデータを自社の基盤に写さず、利用企業のデータウェアハウスにあるデータをその場で問い合わせる点にあります。公式の案内では、Snowflake、Databricks、BigQuery、ClickHouse、Redshift を対応先として挙げています。行動データを別の分析サービスに送り直す必要がないため、データの二重管理を避けられるというのが同社の説明です。

AIの機能としては、2025年3月に自然言語での問い合わせや報告の要約、データ品質の警告を担うAIの基盤機能を発表し、同年8月にはそれを会話の形に広げた Ask Kubit を発表しています。Ask Kubit は、自然な文で質問すると報告を組み立て、作られた報告の中身はすべて見えて編集できる、と説明されています。AIが組み立てた報告を、人が中身まで開いて確かめられるという設計の考え方は、エージェント分析を評価するときにも同じ物差しとして使えます。ただし、エージェントの記録の分析の画面で Ask Kubit が使えるかどうかは、公開ページでは確かめられませんでした。2026年3月には Snowflake との連携の発表も報じられています。

つまり Kubit は、もともとマーケティングや製品企画の担当者が、利用者の行動を自社の倉庫の上で分析するための道具でした。今回のエージェント分析は、その同じ場所に、エージェントの実行記録という新しい種類のデータを持ち込むものです。エージェントの記録の取り方や、観測の考え方そのものは別の記事で扱っているため、この記事では、記録を事業部門の分析と同じ場所に置くことの意味に絞ります。

2026年の動き：エージェント分析の早期提供

Kubit の公式サイトは、2026年10月の時点で、エージェントの観測と行動分析を組み合わせた機能を前面に出しています。公表されている仕組みは、自社の小型言語モデル Polaris が、エージェントの各処理について「何をしたか」と「うまくいったか」を判定して付けることから始まります。判定は失敗した処理だけでなく、正常に終わった処理も含めて全件に付けると説明しています。

判定が付いた実行は、同じ道具を同じ順番で呼んだもの同士でまとめられ、経路として図示されます。利用者、エージェントの版、利用者の層で絞り込み、失敗の多い経路を見つけると、その経路ごとに直前に出した変更と、失敗した実行に多い属性（モデルの版や利用者の層など）が示されます。さらに、エージェントの動きを利用者の行動、A/Bテスト、キャンペーンと結び付け、どの経路が成果につながったかを見られるとしています。

提供は早期提供の段階で、公式サイトでは第1期の受け入れを7社とし、応募の締め切りを10月30日と告知していました。今後の予定として、失敗の経路を原因になった変更と結び付ける機能、直した経路が再び失敗したら知らせる監視の機能、業界標準の記録形式で集めた記録を自社の倉庫に書き戻す方式が、第4四半期にかけて挙げられています。予定は予定であり、契約の前に提供状態を確かめる必要があります。

導入の手間について、公式サイトは、記録を集めるための開発キットや、データを受け渡す仕組みを新たに組み込む必要はないと説明しています。倉庫に記録がすでにあれば、それを読むだけで分析を始められる、という位置づけです。倉庫につながない場合でも、記録のファイルを読み込ませて同じ分析を試せるとしています。開発部門の手を大きく借りずに試せることは、事業部門が主導して検討しやすい理由の一つです。

何ができると公表しているか：五つの仕組み

公式の説明を、社内の判断に使える形で整理すると、次の五つになります。どれも公表された内容であり、精度や処理量の数値は公開ページでは確かめられませんでした。

仕組み	公式の説明	社内で確かめること
判定の付与	Polaris が各処理に、何をしたかと成否を付ける	判定の処理がどこで動き、記録の本文がどこに渡るか
経路のまとまり	同じ道具を同じ順で呼んだ実行をまとめて図示する	自社のエージェントの分岐の多さで、まとまりが意味を持つか
失敗の手がかり	失敗の多い経路ごとに、直前の変更と多い属性を示す	手がかりを原因と取り違えない運用
成果との結合	利用者の行動、A/Bテスト、キャンペーンと結び付ける	エージェントの記録と顧客の識別子が結べるか
その場での問い合わせ	自社の倉庫の中の記録を、写さずに読む	読み取り専用の権限と、倉庫側の計算費用

このうち、他の観測ツールと比べて Kubit に固有なのは、成果との結合と、その場での問い合わせの二つです。判定の付与や経路のまとまりは、開発者向けの観測ツールにも似た機能があります。Kubit を選ぶ理由があるとすれば、記録を事業の数字と同じ倉庫で扱いたい、という一点に集約されます。

課題1：エージェントの記録が、開発者の道具の中に閉じている

社内のエージェントを開発した部署は、たいてい開発者向けの観測ツールに記録を送っています。そこには、どのモデルを呼び、どの道具を使い、何秒かかり、いくら費用がかかったかが残ります。不具合を直すには十分な情報ですが、マーケやCSの担当者が、その画面を日常的に開くことはまずありません。権限も付与されておらず、画面の言葉も開発者向けだからです。

その結果、エージェントが顧客に誤った案内をしていても、事業部門が気づくのは、顧客からの苦情や解約の理由として表に出てからになります。記録の中には兆しがあったのに、見る人がいなかった、という状態です。特に、問い合わせ対応やマーケの施策の案内など、顧客に直接触れるエージェントほど、この空白の影響は大きくなります。

記録を事業部門にも見せればよい、というのは簡単ですが、開発者向けの観測ツールの権限を事業部門に広げると、記録に含まれる顧客の発言や社内の情報が、見る必要のない人にまで見えてしまいます。見せる範囲を、事業部門がすでに使っている分析の権限の中で管理できるかが、本当の課題です。

課題2：「動いたが役に立たなかった」実行が、どの数字にも出ない

エージェントの不具合で厄介なのは、エラーにならない失敗です。処理は最後まで終わり、応答も返しているが、顧客の質問には答えていない、誤った資料を参照している、といった実行は、処理の成否や応答時間の数字には現れません。Kubit の公式サイトも、ダッシュボード上は健全に見えるのに、品質の問題に先に気づくのは顧客だ、という状況を問題として挙げています。

この種の失敗を見つけるには、実行の中身を読んで「うまくいったか」を判定する必要があります。人がすべてを読むのは現実的ではありません。公式サイトの説明でも、週に数万件の実行が起きる場面を想定しています。そこで、判定をAIに付けさせる、という発想が出てきます。Kubit が自社の小型言語モデルで全件に判定を付けるとしているのは、この課題への答えです。

ただし、判定をAIに付けさせた時点で、新しい問いが生まれます。その判定は正しいのか、誰が確かめるのか、という問いです。これは後の対策で扱います。

課題3：記録を社外の観測サービスに送ることに、承認が下りない

エージェントの記録には、顧客の問い合わせの本文、社内の資料の抜粋、モデルが生成した回答がそのまま残ります。記録は、エージェントが扱ったデータの写しそのものです。これを社外の観測サービスに送るには、個人情報の第三者提供や委託の整理、保管国の確認、保管期間の取り決めが必要になり、情報システム部門や法務の審査に時間がかかります。

審査が通らないまま開発を進めると、記録を取らない、あるいは中身を省いた記録だけを取る、という妥協が起きます。そうなると、課題2の「動いたが役に立たなかった」実行は、ますます見えなくなります。記録の置き場所が決まらないことが、品質の問題を見えなくしている、という構図です。

• 審査待ちの間、記録を開発者の手元のファイルに残し、担当者の異動とともに失われた
• 社外への送信を避けるために、記録から本文を削り、処理時間とエラーだけを残した結果、品質の問題を追えなくなった
• 事業部門に見せるために記録を表計算ファイルに書き出して共有し、顧客の発言が社内に広く出回った

原因1：記録と事業の数字が、別々の場所にある

三つの課題に共通する原因の一つは、エージェントの記録と、顧客の行動や売上の数字が、別々の場所にあることです。行動データや売上はデータウェアハウスにあり、事業部門はそこで分析しています。一方、エージェントの記録は観測ツールの中にあり、同じ顧客についてのデータなのに、突き合わせるには毎回書き出しと結合の作業が要る状態になっています。

突き合わせにひと手間かかると、分析は特別な調査のときにしか行われません。エージェントの版を更新した週に、問い合わせの再発率や商談化率がどう変わったかを、毎週の定例で見ることができないのです。Kubit が成果との結合を前面に出しているのは、この断絶を埋めるためだと読めます。

近年は、データウェアハウスの側にもエージェントの記録を残す仕組みが整ってきました。Kubit の説明では、Databricks では Unity Catalog にある記録と評価を、Snowflake では自社のAI観測の記録と評価データを、そのまま読むとしています。Snowflake については、同社が提供するエージェント機能の実行記録も、評価データと並べて読めると説明しています。記録がすでに倉庫にあるなら、それを事業の分析と同じ場所で読むのは自然な流れです。

原因2：成功か失敗かの判定を、誰も持っていない

もう一つの原因は、エージェントの実行が「うまくいった」とは何かを、誰も決めていないことです。開発者にとっての成功は、エラーなく最後まで処理が終わることです。CSにとっての成功は、顧客が同じ質問で再び問い合わせてこないことです。マーケにとっての成功は、案内を受けた顧客が次の行動に進むことです。

判定の基準が決まっていないまま、AIに成否の判定を付けさせると、AIの判定の基準が、そのまま会社の基準になってしまうおそれがあります。Polaris がどのような基準で「うまくいったか」を判定するのか、利用企業が基準を調整できるのかは、公開ページでは詳しく確かめられませんでした。公式サイトのよくある質問には、判定の費用や判定を信頼できるかという問いが並んでいましたが、公開されている範囲では具体的な答えまでは確かめられませんでした。

判定の持ち主がいないことは、道具を入れても解決しません。むしろ、判定が自動で付くようになると、基準を議論しないまま数字だけが流通し始めます。道具を入れる前に、エージェントごとに成功の定義を事業部門が書くことが、対策の前提になります。

対策1：記録は自社の倉庫に置き、読み取り専用で読ませる

Kubit の案内によると、自社の倉庫に置いた記録を読む方式では、利用企業が読み取り専用のアカウントを用意し、記録のあるスキーマに範囲を絞って Kubit に渡します。倉庫の防火壁では Kubit の通信元のアドレスを許可します。記録や派生した指標は倉庫に残り、別の保管場所への書き出しは起きない、と説明されています。行単位の閲覧制限、項目の伏せ字、監査の記録は、倉庫の側の仕組みがそのまま効くとしています。

この構成の意味は、記録の管理を、すでに審査を通っている倉庫の管理の中に収められることです。顧客の行動データと同じ規程、同じ権限、同じ保管期間で記録を扱えるため、新しい保管先の審査を一から行う必要がありません。事業部門に見せる範囲も、倉庫で設定している閲覧制限の中で管理できます。

• 自社の倉庫に置く方式は、公式の案内では一部の契約の種類でのみ提供とされている。契約の種類と方式の対応を見積もりの段階で確かめる
• 業界標準の記録形式で Kubit に記録を送る方式では、処理と保管を Kubit の側が担うと説明されている。この方式を選ぶと、社外に記録が出る
• 記録のファイルを読み込ませて分析する方式もある。試すときに本番の記録をそのまま渡さないよう、伏せ字にした記録を使う

確かめておきたいのは、Polaris による判定がどこで動くかです。倉庫の中の記録を読むだけなら社外への持ち出しはありませんが、判定を付けるために記録の本文がモデルに渡るなら、その処理の場所が社外かどうかで審査の扱いが変わります。公開ページでは判定の処理場所は確かめられなかったため、契約前に書面で確かめる項目に入れます。

対策2：AIによる判定は、人の抜き取り検査で確かめてから使う

Polaris の判定を使い始める前に、人による抜き取り検査で判定の確からしさを測ります。やり方は単純で、判定が付いた実行から、成功と判定されたもの、失敗と判定されたものをそれぞれ一定数ずつ無作為に選び、事業部門の担当者が中身を読んで、自社の成功の定義に照らして判定し直します。

ここで大事なのは、人が判定するときにAIの判定を先に見ないことです。先に見ると、人の判定がAIに引っ張られ、食い違いが実際より少なく見えます。また、成功と判定された実行の抜き取りを省かないことも大切です。失敗の見落としは、成功と判定された実行の中に隠れているからです。

対策3：経路の分析を、マーケ・CSの指標と同じ表で見る

記録を倉庫に置き、判定の確からしさを確かめたら、ようやく事業部門の分析と結び付けられます。たとえば問い合わせ対応のエージェントなら、経路ごとに、その後7日以内の再問い合わせ率、人への引き継ぎ率、解約率を並べます。マーケの案内を担うエージェントなら、経路ごとに、案内を受けた顧客の資料請求や商談化の割合を並べます。

こうして並べると、処理の上では成功しているのに、事業の成果が悪い経路が見えてきます。たとえば、社内資料の検索を2回繰り返してから回答する経路は、処理としては正常でも、回答が長くなり、顧客が読まずに人の窓口に流れている、といった具合です。こうした発見は、開発者の観測ツールだけでは得られません。

結合するには、エージェントの記録と顧客の行動データを結ぶ識別子が要ります。会員番号や問い合わせの番号を記録に残す設計になっていないと、結合はできません。道具を選ぶ前に、自社のエージェントの記録に、顧客の識別子が残っているかを確かめるのが先です。識別子を残すこと自体が個人情報の取り扱いになるため、利用目的の範囲も確認します。

対策4：失敗の経路と直前の変更の結び付きを、因果と取り違えない

Kubit は、失敗の多い経路ごとに、直前に出した変更と、失敗した実行に多い属性を示すとしています。便利な手がかりですが、「変更の直後に失敗が増えた」ことは、「変更が失敗の原因だ」ことを意味しません。同じ時期に顧客の問い合わせの中身が変わった、季節の要因で特定の質問が増えた、ということもあります。

手がかりを原因と認めるには、変更を戻したときに失敗が減るか、あるいは変更前と変更後の版を同時に動かして比べたときに差が出るかを確かめる必要があります。Kubit がA/Bテストとの結合を挙げているのは、この確かめに使えるからです。原因の候補を絞るところまでは道具に任せ、原因の断定は比較の結果を見て人が行う、という分担にします。

エージェントの失敗箇所を手順として突き止める方法は別の記事で扱っていますが、Kubit の場合に固有の注意は、属性の偏りが事業部門の目に触れやすいことです。「ある利用者の層で失敗が多い」という表示は、その層の顧客への対応を変える議論にすぐつながります。表示を見た段階で施策を変えず、まず開発部門と原因を確かめる、という手順を決めておきます。

早期提供の段階で入れるか：判断の基準

Kubit のエージェント分析は、2026年10月の時点で早期提供の段階です。第1期の受け入れは7社と告知され、主要な機能の一部は第4四半期の予定とされています。早期提供で入れることの利点は、自社の要望を製品に反映させやすいことと、事業部門が記録を見る体制を早く作れることです。欠点は、機能や価格、提供条件が変わりうること、判定の精度が公開されていないことです。

判断の基準は、すでに社内のエージェントの記録が自社の倉庫に入っているか、そして Kubit をすでに製品分析で使っているかの二つです。両方を満たすなら、追加の審査は小さく、試す価値は大きいでしょう。どちらも満たさないなら、まず記録を自社の倉庫に残す設計を整えることが先で、道具を選ぶのはその後です。

入れる場合も、本番の判断を任せないことを条件にします。早期提供の期間は、既存の観測ツールを止めずに並行して動かし、Polaris の判定と人の抜き取り検査の食い違いを測り、成果との結合で新しい発見があるかを確かめる期間と位置づけます。判定の数字を、経営への報告や担当者の評価に使うのは、検証が済むまで待ちます。

なお、公式サイトの告知どおりであれば、第1期の応募は10月30日で締め切られています。これから検討する企業は、第2期以降の募集や一般提供の時期を問い合わせることになります。待つ間にできることは多く、記録を自社の倉庫に残す設計、顧客の識別子の付け方、成功の定義の文章化は、どの道具を選ぶ場合にも必要な準備です。準備が整ってから道具を比べるほうが、早期提供の枠を急いで取るより失敗が少ないはずです。

費用の増え方と、止め方・やめ方

Kubit の価格は公開ページでは示されていません。費用を考えるときに見落としやすいのは、倉庫の側の計算費用です。公式の案内では、計算は利用企業の倉庫の中で行われ、抽出ではなく全件を処理すると説明されています。全件の分析は見落としを減らす一方で、実行の数が増えるほど倉庫の計算費用も増えます。試行の段階で、1週間の分析にかかった倉庫の費用を実測しておきます。

止め方は、構成の上では単純です。倉庫に置いた記録を読む方式なら、Kubit に渡した読み取り専用のアカウントを無効にすれば、Kubit からの読み取りは止まります。記録そのものは自社の倉庫に残るため、やめた後も別の道具で分析を続けられます。これは、記録を外部のサービスに送る方式と比べた、この構成の大きな利点です。

確かめておくべきは、Kubit の側に何が残るかです。報告の設定や、判定の結果をどこに保存するかによって、やめた後に消すべきものが変わります。判定の結果が自社の倉庫に書き戻されるのか、Kubit の側に保管されるのかを確かめ、解約時の削除の手順と期限を契約に書き込みます。

導入前に確かめるチェックリスト

最後に、Kubit のエージェント分析を社内で検討するときに、契約や試行の前に確かめる項目をまとめます。情報システム部門、事業部門、開発部門で分担して確かめてください。

• 社内のエージェントの記録が、すでに自社のデータウェアハウスに入っているか。入っていないなら、まずその設計を整える
• 記録に、顧客の行動データと結び付けられる識別子が残っているか。その利用目的は、個人情報の取り扱いの範囲に収まっているか
• Kubit に渡すアカウントを読み取り専用にし、記録のあるスキーマだけに範囲を絞れるか
• Polaris の判定がどこで動き、記録の本文が社外に渡るかどうか。書面で確かめたか
• 判定の結果がどこに保存され、解約時に何を消すことになるか
• エージェントごとの成功の定義を、事業部門が文章で書いたか
• 人の抜き取り検査の担当者と、毎週読む件数を決めたか
• 早期提供の期間に、既存の観測ツールを止めずに並行して動かす計画になっているか
• 倉庫の計算費用を、試行の1週間で実測する段取りがあるか
• 判定の数字を、検証が済むまで評価や経営報告に使わないことを関係者で合意したか

このうち一つでも答えられない項目があれば、それが導入前に詰めるべき論点です。道具の機能の多さよりも、記録の置き場所、判定の検証、判断の持ち主の三つが決まっているかで、入れてよいかどうかが決まります。

まとめ

Kubit は、データウェアハウスの上で動く製品分析の基盤に、エージェントの実行記録の分析を加えようとしています。2026年10月に早期提供が告知された機能は、自社の小型言語モデル Polaris で各処理に判定を付け、実行の経路をまとめ、利用者の行動やキャンペーンと結び付けるものです。その価値は、記録を開発者の道具から出して、事業部門の分析と同じ場所に置けることにあります。一方で、判定の精度や処理の場所は公開情報だけでは確かめられず、提供はまだ早期の段階です。記録は自社の倉庫に置いて読み取り専用で読ませ、成功の定義を事業部門が書き、AIの判定は人の抜き取りで確かめてから使う。失敗の手がかりは原因と取り違えず、比較で確かめる。この順番を守れば、早期提供の段階でも、事業部門がエージェントの品質に責任を持つ体制を作り始められます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。