Tukun Agent が正式に稼働開始

本日、Tukun Agent を正式に公開しました。

Tukun Agent は従来の ChatBI ではありませんし、単に大規模モデルをデータベースにつないだだけのデモ製品でもありません。私たちが重視しているのは、semantic、ontology、evidence を同じ分析パスの上に戻し、プロダクトを持続可能な data agent として機能させることです。

解こうとしている問題も具体的です。

多くの AI アナリティクス製品は最初のデモではよく見えますが、実務に入ると同じ問題を繰り返し抱えます。

• 指標定義が一貫せず、同じ言葉でもシステムとチームで意味がずれる
• 答えはもっともらしく見えるが、証拠パスが不明確
• 結論は読めても、プロセスは確認しにくく、再利用しにくい
• 有用な分析がチャットスレッドの中に閉じ込められ、カード、ダッシュボード、共有資産にならない

Tukun Agent は、まさにその問題群を中心に設計されています。

Tukun Agent とは何か

Tukun Agent は、ガバナンスされた分析のためのプロダクトであり、より正確には、実際のビジネス業務に本当に必要だと私たちが考える data agent の形です。

その中核にある問いは「答えられるか」ではなく、「明確な業務上の意味、明示的な証拠境界、再利用可能な出力を伴って答えられるか」です。ここが汎用チャット製品との違いであり、一般的な ChatBI パターンと同じではない理由でもあります。

現在のプロダクトでは、Tukun Agent は五つの主要な面で構成されています。

• Workbench: 会話、クエリ、分析、進捗、成果物、批判的レビューを一体で扱う唯一の実行ワークスペース
• Semantics: モデル、指標、ディメンション、エンティティ、リレーションシップ、review / publish フローを扱うセマンティック資産ワークスペース
• Dashboards: 結果カードを読みやすく共有しやすい資産として残す下流の面
• Skills: インストール済み・利用可能な能力を扱うランタイム拡張面
• Console: 日々の分析ではなく、共有設定とヘルス管理のための場所

ここで私たちが非常に明確にしているプロダクトルールが一つあります。Workbench が唯一の実行エントリーポイントであることです。

クエリがある場所で走り、分析が別の場所で走り、保存済み資産が第三のロジックパスを持つようにはしたくありません。そうすると、見た目は似ていても真実について食い違う複数のシステムにすぐ変わってしまいます。Tukun Agent はランタイム実行を一つのパスに集約し、その上にカード、ダッシュボード、その他の下流資産を築いています。

なぜセマンティクスから始めるのか

共有された意味がなければ、Agent は答えのように見えるものを生成できても、ビジネス上本当に妥当なものを安定して返すことはできません。

だから Tukun Agent では、semantic 構造は脇役の設定ではありません。第一級のプロダクト資産です。そして ontology は研究議論のための言葉ではなく、業務オブジェクト、関係性、意味をプロダクト内部で整理して保つための実務的な方法です。

現在のバージョンでは:

• semantic 定義は PostgreSQL のメタデータストレージにあり、プロダクトの source of truth になっている
• publish 済み manifest ファイルは実行成果物であって、定義そのものではない
• すべての Workbench 実行は、一つの明示的なデータソースにスコープされる
• semantic 定義と publish 状態はデータソースごとに分離される

これは、Agent がまず指標、ディメンション、エンティティ関係がビジネス上実際に何を意味するのかを揃えなければならないことを意味します。いきなり SQL に飛びついて運任せにする前に、semantic と ontology 層を解決する必要があるのです。

これは派手ではありません。それでも分析品質を決めるのはここです。大事なのは、モデルが綺麗な要約を書けるかではありません。data agent がそもそも正しい業務上の意味の上に立っているかどうかです。

なぜ evidence 境界が重要なのか

Tukun Agent の第二の中核原則は、evidence-first の分析です。

多くの製品にとって一番簡単な最適化は、答えをもっと滑らかに見せることです。私たちにとってより重要なのは、証拠が十分でないときに限界を認めることです。

現在のプロダクトでは、すべてのリクエストは明確に次の四つの結果のいずれかに着地すべきです。

1. 直接答える
2. ガバナンスされたクエリ結果を返す
3. 証拠ベースの分析を返す
4. まだ何が欠けているかを示す

これは単純に見えますが、実際の振る舞いを強く規定します。

• ユーザーが時間粒度を求めたなら、証拠にもその時間粒度が含まれていなければならない
• ユーザーが業務ディメンション別の内訳を求めたなら、証拠にもその内訳が含まれていなければならない
• 結果が途中で切れている、形が欠けている、不完全であるなら、システムは分析が終わったふりをしてはならない
• 証拠が高レベル集計しかないなら、それを強い結論として包装してはならない

つまり、Tukun Agent は常に何かを言うために作られているのではありません。証拠があるときに正しく言い、ないときには明確に止まるために作られています。

質問に答えるだけでなく、結果を残す

分析の価値は、一つの会話に閉じ込められたままだとすぐに減衰します。

だから Tukun Agent は、結果の保存をあと付けではなくメインパスの一部として扱います。現在のプロダクトでは、Workbench で作られた出力はカードに変換され、その後 Dashboards に保存される下流の再利用資産になります。これらは元の turn と結びついたまま、データソースのスコープと証拠コンテキストを保持し、再実行しなくても読める状態で残ります。

これは、チームが柔軟な分析と安定した再利用のどちらかを選ばされるべきではないからです。

まず Workbench で本物のクエリと分析を行い、そのうえで長く残す価値のある部分だけを保存し、報告、レビュー、追質問、将来の意思決定に使えるようにするべきです。

このローンチに含まれるもの

現時点で Tukun Agent は、次の能力を備えた状態で本番稼働しています。

• アカウント単位のプロダクトアクセスと分離
• メールサインイン、Google / GitHub OAuth、passkey サインイン
• 選択した単一データソースに対するガバナンスされたクエリと分析フロー
• クエリ、分析、証拠、成果物、診断を一つにまとめた Workbench 体験
• semantic 定義の発見、編集、review、publish フロー
• 結果をカードやダッシュボードへ保存する下流パス
• ランタイム skill カタログと可視化された能力管理

これらを合わせると、ひとつの完全な data agent ワークフローを支えられます。質問から始め、意味を揃え、クエリと分析を実行し、その結果を再利用可能な資産として残す流れです。

このローンチが意味すること

私たちにとって Tukun Agent の正式公開は、「十分な機能が積み上がった瞬間」ではありません。プロダクト境界がようやく明確になった瞬間です。

もはや単なる内部プロトタイプでも、一つの狭い問題に対する実験でもありません。いまの Tukun Agent には、定義された実行ワークスペース、実在するセマンティック資産層、明示的な証拠境界、そして有用な結果を住まわせ続けられる下流の場所があります。

だからこそ、これは寄せ集めの印象的なデモではなく、継続的に進化させられるプロダクトになりました。

次に来るもの

私たちは今後も同じ方向を押し進めます。

• semantic 層と分析層の整合性をさらに強める
• プロセスを隠すのではなく、ランタイムの可観測性を高める
• 使い捨てではなく、再利用できる出力を増やす
• 現在のパスのシンプルさを壊さずに、マルチスペースやチームワークフローへの対応を広げる

もしあなたが気にしているのが、モデルがあと一問多く答えられるかではなく、data agent が実務で信頼できる分析インターフェースになれるかどうか、そして従来の ChatBI より良い形で semantic、ontology、evidence を一緒に保てるかどうかだとしたら、Tukun Agent が私たちの答えです。

Tukun Agent は正式に稼働を開始しました。