腾讯 Omega：次世代 AI BI の可能性を検証

腾讯 Omega：次世代「AI BI」の答えはここにあるか？

AI によるデータダッシュボードで最も難しいのは、生成そのものではない。

著者：jiaxingjin

Excel ファイルをアップロードし、一言入力して数十秒待てば、KPI やトレンドグラフ、ランキングが表示されたページが画面に現れる。鮮やかな色彩で滑らかなアニメーション、それをグループチャットに共有すれば「すごいね」という声が返ってくるのは容易い。

しかし、実際に使い始めると、問題は翌日から始まるのだ。

時間範囲を「今月」から「先月」に変えても数字は止まったまま。地域フィルターをクリックすると、3 つのグラフがそれぞれバラバラに計算される。データテーブルに新しいフィールドが追加されただけで、ページ全体が真っ白になる。棒グラフを折れ線グラフに変えようとしても、AI は最初から生成し直し、すでに確認済みのレイアウトまで勝手に変更してしまう。

その時になって初めて気づく。昨日見たのはデータ製品ではなく、AI が描いた「データ製品に似せた一枚の画像」だったのだ。

2024 年、DataTalk では ChatBI を試みた。ユーザーがサイドバーで質問し、AI が SQL を生成して結果をグラフ化する仕組みだ。方向性は間違ってはいないが、実際に使ってみると非常に使いにくいものとなった。SQL は結局人間が手直しする必要があり、グラフの品質も不安定だった。何より重要なのは、AI と既存の BI システムが常に別々の存在として扱われていたことだ。一つの質問には答えられるが、その後の分析作業までは引き継げない。

そこで私たちは、このアプローチを根本から見直したのだ。

チャットボックスに別のモデルを搭載するだけではないし、ボタンの配置を並べ替えるわけでもない。ゼロからデータ分析製品を設計し直すなら、AI はどこに位置すべきか——そう改めて問い直した。

チャットボックスが BI の次世代ではない

従来の BI ツールの使い方は明確だ。データの選定、フィールドの選択、コンポーネントのドラッグ＆ドロップ、フィルターの設定、スタイルの調整。これらは非常に強力かつ専門的だが、ユーザー自身が「何を分析したいか」をすでに把握しており、その問いを一連の操作に翻訳できることが前提となる。

ChatBI はこの壁を越えたように見える。ユーザーはドラッグ＆ドロップをする必要なく、「先月の各カテゴリの販売状況はどうだった？」と自然言語で質問するだけでよい。AI がそれを SQL に変換し、結果としてグラフが返ってくる。

しかし、分析は最初の一枚のグラフでは終わらない。

「なぜ南地区の売上がこれほど急落したのか？」「注文数が減ったのか、それとも客単価が下がったのか？」「大企業と中小企業のトレンドは同じなのか？」

「最も異常な値を示す 3 つの都市だけを抽出して見てほしい」

最後に、結果をまとめてチームに共有し、来週のデータ更新時に再度確認する必要があるかもしれない。

AI が「質問から SQL へ」というステップしか担えないなら、それは単なるクエリの短縮に過ぎず、一連の分析作業全体を代行したわけではない。

Omega は、後者の実現を目指している。

「上季度各品类的销售情况を分析して」と一言頼むと、Omega はまずデータソースやフィールドを理解し、次にこの分析で見るべき指標を自ら計画します。総売上高、前月比、トレンド推移、カテゴリ構成、地域差などです。その後、データを直接照会し、適切なチャートを選択してページを構成し、完成したダッシュボードを生成します。

「2 枚目の図が直感的でない」と言うと、Omega はその 1 枚だけを柱状図に変更します。「地域別のフィルターを追加したい」と言えば、コントロールを追加し、関連するチャートも連動させます。配色が濃すぎる場合は、「薄くして」と指示すれば色を調整できますし、必要であれば可視化エディタを開いて自分でドラッグ＆ドロップすることも可能です。

ページを保存して共有すると、データは自動的に更新され続けます。次回もまた、この分析結果をベースにさらに深掘りした分析が可能です。

Omega のコア開発チームは長らく 3〜4 名のみです。製品、デザイン、テストの役割が明確に分かれているわけではなく、多くの決定は数人がコードを書きながら、「製品はこうあるべきだ」と議論しながら進めています。2026 年 1 月中旬に着手し、最初の 2 ヶ月で主要なフローを完成させました。

しかし振り返れば、2 ヶ月で作られたのは「デモとして動く」Omega に過ぎません。その後の数ヶ月間、私たちが取り組んできたのは別の課題でした。つまり、デモ環境から離れても、本物の製品として機能するようにすることです。

看板が「生きている」とは何か

AI がページを生成する自体は難しくありません。現在のモデルは HTML、CSS、JavaScript の記述にすでに熟練しており、ECharts や D3 を組み合わせれば、2 年前よりも遥かに低いハードルで視覚的に優れたダッシュボードを作成できます。

真の難しさは、そのページと実データの間を、常に信頼できるパイプで繋ぎ続けることにあります。

多くの AI 看板の実装では、クエリ結果をそのままページに書き込んでいます。

const data = [
  { month: '1 月', sales: 1280 },
  { month: '2 月', sales: 1530 }
]

このコード自体に間違いはありませんし、デモには最適です。しかし、一度生成されるとデータは固定されてしまいます。期間を変更したり、フィルターを追加したり、データを更新したりするには、毎回 AI に再生成を依頼する必要があります。見た目は生きているように見えても、中身にあるデータはすでに死んでしまっているのです。

Omega がページを生成する際、HTML の他にも構造化された「データ契約」を同時に作成します。内部ではこれを QueryRegistry と呼んでいます。各チャートがどのクエリを必要とし、どのようなパラメータを受け取り、結果をどのようにバインドするか、どのフィルターと連動するのか——これらすべてがここで明確に宣言されます。実際の処理は、DTBridge というランタイムが行います。

これは役割を分離したようなものです。「何を求めるか」は AI が担当し、「どうやって安定して取得するか」はシステムが保証します。

ユーザーが日付を変更すると、DTBridge は契約に基づいて関連するチャートを自動的に更新します。フィルター自体も宣言式で記述されるため、AI は各コントロールに対して addEventListener を手書きしたり、WHERE 条件を組み合わせたり、空値の処理を行ったりする必要はありません。

なぜ私たちは、これらのコードをモデルに丸投げしないのか？それは、個別のコード断片は単純に見えても、組み合わさった瞬間に静かにエラーが発生するリスクが高いためです。

典型的な問題として、SQL は正常にデータを返しているのにチャートが空表示になるケースがありました。データベース側でエラーが出ず、ブラウザのコンソールにも異常はありません。最終的な原因は、ページ側のコールバックが「総上报量」を参照していた一方、SQL の出力列名が total_pv だったという不一致でした。

それぞれ単独で見れば問題ない内容ですが、組み合わせると値を取得できない状態になっていたのです。

その後、フィールドバインドのチェック機能を追加しました。これは、ページから実際に読み取ったフィールドを逆手に取り、SQL の出力別名を検証するものです。これに似た検証は他にもあります。時間フィールドが秒単位なのかミリ秒単位なのか、フィルター値がクエリパラメータと対応しているか、チャート定義内のクエリ ID が実際に存在するかといった点です。これらは派手ではありませんが、ダッシュボードが「たまに成功するもの」になるのか、「多くの場合、納品可能なもの」になるのかを決定づける要素です。

データの流れが確立された後は、セキュリティと生成体験もシステムが管理します。ページ側はデータベースのアカウントやキーを取得できません。クエリと権限チェックはサーバー側に残ります。バックエンドでは、データソースの能力に応じて AST の読み取り専用検証や軽量な読み取り専用チェックを実行し、クエリサービスの権限制御と統一されたタイムアウトを適用します。ページは制限された iframe 内で動作します。ダッシュボードがストリーミング生成される際、安全に到達したスタイルと本文のみを更新し、完了後にスクリプトを一括でロードすることで、ページの繰り返し白屏を防ぎます。ユーザーが目にするのは、ページが滑らかに成長していく様子だけです。背後にある境界線は、モデルの臨場感に頼ることはできません。

AI はどのように指標を見つけ、フィルターを連動させ、データ境界を守るのか

BI の経験がある方なら、ここまで読んで自然と疑問を持つでしょう。「モデルはどうやって『売上』がどの列やどのような集計に対応するかを知るのか？」「企業が既に維持している指標の定義やセマンティックモデルはどのように連携するのか？」「なぜ一つのフィルターで五つのチャートを同時に動かせるのか？」「AI が生成した HTML 文書凭什么で生産データのクエリを許可されるのか？」

これらの問いに、「より強力なモデルを使ったから」という一言で答えることはできません。

Omega は BI の基盤を迂回していません。DataTalk に既に存在するデータソース接続、メタデータ、セマンティックモデル、クエリエンジン、権限体系は、引き続き下層を支えています。Agent が問題の理解、分析の構成、インターフェースの生成を担当しますが、データの意味や実行境界に関わる場面では、システムが検証可能な証拠に立ち返る必要があります。

業務上の質問から実行可能なページに至るまでの実際のフローは以下の通りです：

ユーザー指定データ / 既存チャートの SQL / ビジネス知識

↓

Schema とセマンティックモデルの解析

↓

分析計画とクエリツールの選定

↓

HTML + QueryRegistry の生成

↓

契約検証、SQL 事前検証

↓

DTBridge → 権限チェック → クエリプロキシ → チャートコールバック

まず証拠を探し、その上で「指標の理解」を語るのです。

例えばユーザーが「先月の地域別売上を確認したい」と言った場合、実際に難しいのは SUM を書くことではなく、「売上」が何を指すのかを確定させることです。税込か税抜か、返品分は控除するか、支払時刻基準か注文時刻基準か。企業内では同じ名称の指標でも、定義が全く異なる可能性があります。

Omega が指標を探す際の重要な原則は、ユーザーの現在の作業現場に近い証拠ほど優先度が高いという点です。

ユーザーが既存のチャートを編集している場合、「売上」に関する LLM の一般的な常識よりも信頼性が高いのは、そのチャートで実際に実行された SQL です。システムは、現在のチャートの datasetId、クエリ説明、データベースエンジン、そして SQL を Agent に渡します。SQL が SUM(pay_amount - refund_amount) や COUNT(DISTINCT buyer_id) と記述されていれば、それが現在ページで採用されている業務定義です。地域次元の追加やチャートタイプの変更を行う際にも、この定義を再利用すべきであり、改めて作り直す必要はありません。

新規分析の場合、ユーザーがメッセージ内で明示的に選択したデータセットが、履歴ページやシステム検索結果よりも優先されます。生成前に Agent は必ず Schema ツールを呼び出し、実際の物理フィールド、表示名、型、フィールド説明、パーティション情報、データソースエンジン、接続ルートを取得します。この動作はプロンプトに記述されるだけでなく、外側には Schema Guard が存在し、ユーザーがデータを指定しているにもかかわらずモデルが Schema を読まずにページ生成を始めた場合は、プロセスがブロックされます。

ユーザーがデータソースを明確に指定しない場合、システムは個人空間、チーム空間、およびアクセス可能なデータカタログ内を検索します。この検索は、単にすべてのテーブル名をモデルに読み込ませるのではなく、名称、説明、物理テーブル名、キーワードの網羅性、データの所有権、更新日時といった多角的な情報を照合し、重複を除いた上で候補を提示するものです。これは「数千ものデータセットから範囲を絞り込む」ための仕組みであり、欠落したビジネス定義まで理解しているかのような振る舞いはしません。

もう一つの根拠となるのは業務知識です。ユーザーが指標の定義や分析手法、あるいは関連ドキュメントを参照指示した場合、エージェントはそれらの断片を現在のコンテキストに組み込みます。これにより、「有効な取引額は全額返金分を差し引く」「新規顧客は初回支払い日をもって認定する」といったルールは、単なるチャット上の注記ではなく、フィールドのメタデータや既存のクエリと連携して計画立案に直接反映されるようになります。

これら複数の情報を統合すると、指標のエビデンスチェーンが形成されます。すなわち、「既存のクエリ定義 → ユーザー指定のデータソース → セマンティックモデルおよびフィールドメタデータ → 明確に参照された業務知識 → 検索候補」という流れです。十分な証拠があればシステムは自動生成が可能ですが、上流で指標定義が存在せず、かつユーザーからの説明もない場合、単に列名が似ているという理由だけで正確な口径を自動判定することはできません。より誠実な対応としては、候補を提示するか、あるいは確認を求めることです。LLM はデータ利用のハードルを下げることはできても、企業がこれまで行っていなかったデータガバナンスを勝手に補完するものではありません。

セマンティックモデルが存在する場合でも、物理的な JOIN をモデルに推測させるべきではありません。

多くのシステムが「セマンティック対応」と謳っていても、実際には単にフィールドのコメントをプロンプトに追加しているだけというケースが少なくありません。私たちが採用したアプローチは、より具体的なセマンティックモデルのパスを実装しています。

通常のデータセットでは物理スキーマを経由します。エージェントは実際のテーブルとフィールドを確認し、対応するデータベースの方言に合わせて SQL を生成します。一方、セマンティックモデルを利用する場合は別の処理フローを踏みます。システムはまずモデル内の論理フィールドとその役割を取得し、それらを「次元（DIM）」「指標（FACT）」「時間軸（TIME_DIM）」に分類します。同時に、表示名、説明、データタイプ、およびモデル識別子も保持されます。

例えば、「各チャネルの過去 3 ヶ月間の有料転換率」をユーザーが問い合わせた場合、エージェントは「チャネル」「有料転換率」「統計日付」といったガバナンス済みの論理オブジェクトを使用し、まず MODEL('') を用いた SemanticQL を生成します。その後、セマンティッククエリサービスによって実行用の物理 SQL へ変換されます。基盤となるファクトテーブルの結合方法や指標の数式展開、異なるストレージエンジンへの対応などは、モデルがその場で推測するのではなく、事前に定義されたルールに基づいて処理されます。

変換に失敗した場合でも、システムは問題のある SQL をそのままユーザーに提示することはありません。変換エラー、直前の SemanticQL バージョン、利用可能なフィールドリストをまとめてエージェントへフィードバックします。もし「不明な識別子（Unknown identifier）」が発生すれば、エージェントは既知の実際のフィールドから再選択し、制限された試行回数内で修正を試みます。このリトライは根拠に基づいたエラー修正であり、モデルが同じ答えに対して運任せで繰り返し挑戦させるものではありません。

もちろん、セマンティックモデルは既存のガバナンス価値を拡大するものであり、存在しない口径を生み出すことはできません。上流で統一された指標、論理フィールド、および関係性が定義されて初めて、Omega は安定的に消費可能です。上流に単なる命名規則が適当なワイドテーブルしか存在しない場合、システムはスキーマ検証によって存在しないフィールドをブロックできますが、各社固有の業務意味合いを自動で推測して正しく解釈することを保証することはできません。これが私たちがあえて守る境界線です。

連動するフィルタリング機能の本質は、クエリの依存関係図にあります。

指標が特定された後でも、ページ上で結果を硬直的に書き込むわけではありません。Omega は HTML 出力とは別に、構造化データ契約である QueryRegistry を生成します。以下は簡略化されたクエリ宣言の例です：

「queryId」はページとクエリを結びつける永続的な識別子です。「datasetId」は、リクエストが登録済みのデータセットへ正しくルーティングされるために使用されます。また、「params」にはパラメータの型や日付精度、デフォルト値、ペアリング関係、カスケード（連鎖）ソース、オプションクエリの情報などが保存されています。

さらに「fieldBindings」は、SQL の出力結果においてどの列が次元（ディメンション）、どの列が指標（メトリック）なのかを明確に定義します。これにより、「チャートでは『売上』を表示しているのに、SQL は『total_gmv』を返す」といった、気づきにくい静かな失敗を防ぐことができます。

ページ側で手動で一時的な連動ロジックを組み立てる必要はありません。DTBridge が読み込まれる際、各 SQL テンプレート内のプレースホルダーをスキャンし、「パラメータ名 → queryId[]」という依存関係のテーブルを構築します。例えば「region（地域）」が「販売トレンド」「カテゴリ構成」「顧客ランキング」「地図」の 4 つのクエリに共通して登場している場合、地域フィルターを更新した際、システムは即座に影響を受けるクエリ集合を特定し、該当する 4 つのグラフだけを再描画します。地域とは無関係な在庫カードなどは、一切動きません。

実際のビジネス現場では、時間フィールドのフォーマットが統一されていないことも珍しくありません。同じ日付フィルター値でも、事実テーブル（ファクト）内では「2026-07-22 00:00:00」に変換される必要がある一方、パーティションフィールドでは「20260722」という形式が求められることがあります。QueryRegistry は「valueType」を通じてフォーマット情報を記録し、「aliasOf」によって複数の SQL パラメータを共通のフィルター標準値と共有させます。実際のフォーマット変換は実行時に一元的に処理されるため、モデル側で各グラフごとに日付処理コードを記述する必要はありません。

連続したドラッグ操作や素早い切り替えが発生した場合、複数回の変動はデバウンス（遅延）によって統合され、未完了の古いリクエストは自動的にキャンセルされます。また、異なるチャートカード間のクエリは並列で実行され、それぞれが独立してローディング状態を管理します。カスケードフィルターも同じ依存グラフ上で動作します。例えば「省」を変更すると、「市」の選択肢クエリがその省パラメータに依存しているため、実行時にはまず都市の候補を更新し、その後、関連する都市のチャートを再描画します。

パラメータ注入は、日付や秒・ミリ秒といった型に応じた処理を行い、文字列リテラルに対してはエスケープを適用し、セミコロンやコメントブロックを除去します。必須項目が不足している場合は未解析マーカーを残し、呼び出し元側で実行を阻止します。「すべて」の選択肢については、条件分岐や空集合のセマンティクスによって処理されます。ただし、この層のエスケープ処理を「絶対的なインジェクション防止」として包装するつもりはありません。異なるデータベースエンジンでは、共通のプレコンパイルパラメータ機構が利用できない場合もあるため、真のセキュリティ確保にはサーバーサイドでのクエリ防御ラインが不可欠です。

安全は iframe の属性ではない

「データが漏洩しない」というのは、見栄えは良くても責任の所在が曖昧な言葉になりがちです。確かに、権限を持つユーザーに結果が表示されれば、そのユーザーが見ることは当然です。システムが真に守らねばならないのは、「権限のない人間にはアクセスさせない」ことです。具体的には、すべてのクエリ実行前に、現在の訪問者および共有関係に基づく認証を通過させ、サーバー側で解析された有効なクエリ身份（アイデンティティ）をバインドする必要があります。生成されたページがソースの機密情報を取得できないようにし、クエリも許可された境界を超えられないようにします。

Omega における最初のセキュリティ境界は「身份と認証」にあります。クエリを実行する身份は、サーバー側で現在のログイン状態から解析されるものであり、ページ側が独自に userId を宣言して認めることはできません。通常のアクセスではまずファイルやデータセットの権限をチェックし、共有リンクからのアクセスではまず共有関係を検証した上で、そのクエリで使用する有効な身份を解析します。データセットの Schema（スキーマ）、クエリの実行、ファイルの開封はそれぞれ個別に権限判断を行います。一度 Agent がデータセット ID を取得したからといって、その後のすべてのリクエストが合法であるとみなしてはいけません。

2 つ目の境界は「クエリ」にあります。構文解析が可能な SQL 方言については、バックエンドで AST（抽象構文木）チェックを行い、単一の読み取り専用 SELECT ステートメントのみを許可します。複数ステートメントや危険な関数は拒否し、サブクエリや CTE を含む実際のテーブル参照を抽出した上で、一律に行上限を設定します。AST 解析器を完全に再利用できない ClickHouse などのエンジンに対しては、より軽量な読み取り専用チェックを採用しつつ、ドライバーの readonly モード、クエリのタイムアウト設定、結果行数の上限といった仕組みに依存します。セキュリティポリシーはデータソースの差異を尊重すべきであり、「正規表現」や「汎用解析器」がすべてのデータベースをカバーできるかのように振る舞ってはなりません。

3 つ目の境界こそが「ページ実行環境」です。データベースのアカウント、パスワード、アクセス鍵が生成された HTML に含まれることはありません。ページは制御されたクエリ代理を通じてのみデータにアクセスします。iframe sandbox や CSP（コンテンツセキュリティポリシー）によって生成コードの実行能力を制限し、独立したプレビューではネットワーク接続範囲もさらに厳格化されます。ただし、iframe をデータ漏洩防止の主力システムとして扱うわけではありません。ページは依然としてクエリ契約を保持しており、許可された結果を表示することは避けられません。極めて機密性の高いデータについては、上位レイヤーでの行・列レベルの権限管理、フィールドのマスク処理、そしてより厳格なネットワーク出口ポリシーが必要です。

見落としがちなのが「身份のライフサイクル」です。永続化（保存）する際、システムは一時注入されたランタイムスクリプトや閲覧者の情報を剥離します。実際にページを開くときや共有するときにのみ、唯一の QueryRegistry と DTBridge SDK、そしてその回のアクセスに固有なシステムパラメータが注入されます。データ契約自体は保存可能ですが、ランタイム上の身份を永続的なスナップショットに焼き付けることはできません。

生成完了後、システムは構造と契約層における静的チェックを行います。パラメータが SQL のプレースホルダーに対応しているか、グローバルフィルターで特定のクエリが漏れていないか、オプションクエリが存在するか、チャートの読み取りフィールドが SQL 出力のエイリアスと整合しているかなどを確認します。初回書き込み後に SQL の事前検証を行い、修正可能な問題が見つかった場合は新しいバージョンを生成します。単にビジュアルスタイルを変更する際は、すでに検証済みの QueryRegistry をできるだけ再利用し、色の変更だけで指標の定義が誤って書き換わらないようにします。

つまり、Omega におけるモデルの出力は最終製品ではなく、リンク付け、型チェック、権限確認、ランタイムスケジューリングを経る必要がある「ソースコード」のようなものです。モデルは表現力を高める役割を担い、決定論的なシステムがそれを持続可能なデータプロダクトへと制約します。

AI 生成後、人間の仕事は続く

人は一度で完璧な要件を伝えることはめったにありません。結果を見て初めて「ここが違う」と気づくものです。タイトルが長すぎる、図の選択が間違っている、特定の指標を分割すべき、フィルタリング範囲が不十分などです。真にワークフローに組み込まれた製品とは、ユーザーに対して「ページ全体を受け入れるか、すべてやり直すか」の二者択一を強いるものではなく、人間が引き続き作業を引き継げるように設計されているはずです。

小改动なら AI に指示するだけでいい。「2 枚目の図を折れ線グラフに変えて」と言えば、AI は対象領域を正確に特定し、その部分だけを修正します。レイアウトやスタイルの微調整が必要であれば、ユーザーは GUI でドラッグ＆ドロップで対応可能です。大幅な変更が必要な場合は、「Plan Mode」がまず修正予定内容をリストアップし、確認後に実行することで、曖昧な指示によってページ全体が崩れてしまうのを防ぎます。

こうした協働を可能にしているのは、私たちが長年維持してきた「A-MD 协议（プロトコル）」です。A-MD はファイルレベルの外部プロトコルで、1 つの AMDFile には SQL、Python コード、チャート、指標、フィルター、説明文などのブロックと、異なるビュー向けのレイアウトが含まれます。Canvas は並列する別のモデルではなく、dashboardLayout.canvas の下位にある Dashboard ビューの载荷（ロード）です。主に HTML と QueryRegistry を保存します。A-MD がファイル、バージョン、編集可能な分析プロセスを管理し、Canvas が最終ページの動的クエリを担当します。

GUI をなくすつもりはありません。自然言語は意図を伝えるのに適しており、マウスは精密な調整に、コードは複雑なロジック処理に適しています。「AI ネイティブ」だからといって、すべてのインタラクションがチャットボックスを経由しなければならないわけではありません。重要なのは、製品が AI に任せるべきタイミングと、人間に制御権を返すべきタイミングを正しく判断できることです。

見栄えは単なる飾りではない

データ製品を作る人は、往々にして審美性を過小評価しがちです。データの正確性が色よりも重要だと考えがちだからです。しかし現実には、二度と開く人がいない分析レポートがどれほど影響力を持つでしょうか。経営層が見るのは背後にある SQL ではなく、画面そのものです。現場の担当者が結果をチャットグループに共有したり、報告資料に組み込んだりするかは、数秒で決まります。

AI はこの点において「平均的な顔」を持っています。自由な発想で 10 枚のダッシュボードを作らせれば、おそらく 10 枚とも「白地に青い棒グラフ、KPI カードが横一列に並ぶ」という似たようなデザインになります。稀にダークモードに変えても、それは馴染み深い紫のグラデーションです。「高級感」「テクノロジー」「抑制されたデザイン」などプロンプトを長く書いてみたこともありますが、改善は限定的で不安定でした。

そこで Omega には、審美性を支えるインフラストラクチャを整備しました。現在までに 23 のビジュアルスタイルと 18 の可視化エンジンが蓄積されていますが、これらは単なるスキン（外見）の切り替え用テンプレートではありません。サイバーパンク風の監視用大型ディスプレイ、モバイル向けの経営日報、ミニマルな財務報告書など、違いは背景色だけではありません。情報密度、フォントの階層、余白、チャートの選択、インタラクション方式まで含めた総合的な設計が異なります。

このシステムには、社内でもよく使われる「薄配置（スリムコンフィグ）、厚エンジン」という設計思想があります。内蔵スタイルのソース設定は、数色のカラーパレット、1 つのフォント、数個のキーワード、そして簡潔なトーン説明など、約 120 字に圧縮されています。バックエンドはこの情報を展開し、チャートの色板、文字間の関係性、ボーダー、レイアウト、アニメーションの制約などを補完した、約 800 字の設計仕様書へと変換します。

審美性システムが最終的に解決しようとしているのは、派手な技術披露ではありません。2 つの現実的な課題です。同じデータでも、人間はもっと速く理解できるか。同じ結論でも、ユーザーはそれをスクリーンショットして上司に送りたいと思うか。

高コストパフォーマンスなモデルでも、複雑なダッシュボードは作れるか

最初のページで良好な結果が出た後、私たちはすぐに別の誘惑に直面しました。「より最先端のモデルを使えば、問題は解決するのではないか」という考えです。

確かに最先端のモデルには価値があります。複雑なレイアウト、コード生成、そして一度での完成率において、それらは通常優れたパフォーマンスを発揮します。しかし、データ分析製品では「最高の結果」を一度だけ目指せばよいわけではありません。毎日発生する大量のリクエストにかかるコストや、最悪の場合にシステムがどのような出力を生むかについても考慮する必要があります。

私たちは内部で固定されたサンプルテストを行いました。同じダッシュボードの生成と修正タスクにおいて、Claude 4.6 のモデル呼び出し費用は約 14.2 元でしたが、混元 Hy3 は約 0.47 元でした。これは約 30 倍の開きがあります。この数字は特定の固定タスクにおけるコストサンプルに過ぎず、両モデルの品質を一般化して比較するランキングではありませんが、「よりコストパフォーマンスの高いモデルでも、複雑な作業を安定して完了できるのではないか」という問いを真剣に考えるには十分でした。

実際に取り組み始めてみると、最も厄介なのはモデルが明確に「失敗しました」と報告することではなく、完成したように見える結果を提出してくることだと分かりました。

HTML が途中で切れていても、タイトルと最初の 3 つの画像は残っています。SQL はデータを取得していましたが、ページにバインドされているのは別のフィールド名でした。時間フィルターにはミリ秒が渡されていましたが、データベースのフィールドには秒で保存されています。モデルは記憶に基づいて存在しない SDK API を書き出しました。データには明らかに 3 つのテーブルしかないのに、あたかも本物かのように見える第 4 のテーブルを勝手に作り上げています。

これらの問題に共通するのは、明確な警告（レッドフラグ）がないことです。ユーザーがページを開き、フィルターをクリックし、あるいは数週間後にデータの変化に気づいて初めて、「これは機能していない」と発見します。

その後、私たちはモデルの「自己判断」だけに安定性を頼るのをやめ、その外側に Harness という仕組みを追加しました。これを Agent の作業環境と理解してください。モデルがどのようなコンテキストを受け取り、どのツールを呼び出せるか、タスクをどのように分割するか、出力はどのような検証プロセスを経るか、失敗した場合はどうフィードバックして修復するか——これらを統括する仕組みです。

ツール層も特定の Agent フレームワークに縛り付けられていません。ランタイム時には、現在の Canvas やファイルタイプ、ユーザーの選択、計画段階に応じて、信頼度の高いツールを自動的に事前アクティブ化します。残りの機能は、モデルが select_tools を通じて段階的に選択する形をとります。これにより、数十個ものツールのスキーマが同時にコンテキストに読み込まれるのを防ぎます。ビジネス用ツールはフレームワークに依存しない統一された契約に従っており、基盤となる Agent フレームワークを変更する場合でも、主に適応層の調整だけで済みます。

現在、ダッシュボードの生成はモデルからの出力が直接ユーザーに表示されるわけではありません。システムがまず構造の完全性、クエリ声明の有無、チャートが実際のクエリにバインドされているかを確認します。途中で HTML が切れている場合は、不完全な部分を切り捨てて必要な閉じタグを補完し、生成を続行します。フィールドの別名や時間フォーマット、フィルターオプションといった明確な問題はルールで処理し、テーブル名は可能な限り実際のメタデータから選択して実行前に検証します。

ルールで修正できることはモデルに任せず、ルールでは判断できない意味的な問題のみを、エラーコンテキストを持った Agent に有目的の修復として委ねます。

「生成したばかりの長いコードをチェックしてすべて修正してほしい」とモデルに指示するのは一見賢明に見えますが、実際にはコストが高くつき、テストも困難です。また、一处を直しても別の箇所を壊してしまうリスクさえあります。エラーを種類ごとに分類することで、システムは個々のケースに対する確実な解決策を一つずつ蓄積できます。Omega は結果を書き込む前に、現在のユーザーの権限を再検証します。Agent がファイル ID を取得したからといって、自動的にそのファイルを上書きする権限があるとはみなしません。

遅い SQL によって露呈したランタイムの問題

Omega の運用初期に、非常に典型的な事故が発生しました。

あるユーザーが分析を依頼した際、高基盤数フィールドの COUNT(DISTINCT) を計算する SQL がありましたが、クエリ自体にデッドロックやエラーは発生していませんでした。問題は、実行中に中間データが返されない点です。この現象は複数回再現され、同様のクエリでは通常 110〜130 秒を要することが判明しました。

当時、システムには 120 秒のアイドル・タイムアウト（空のウォッチドッグ）が存在していました。これにより、データが 120 秒以上受け取れないと接続がフリーズしたと判断され、強制的に切断されます。結果として、正常に動作していた慢性的なクエリが「ゾンビ」と見なされて殺害されてしまいました。

ユーザー側には明確なエラーメッセージは表示されず、回答が途中まで書かれていたかと思いきや、突然停止してしまいます。さらに深刻なのは、フロントエンド側の接続は切断されたものの、停止信号が最下層の処理エンジンに伝わっていなかった点です。すでに不要になったはずの SQL がバックエンドで実行され続け、30 分後にようやくタイムアウトするまで放置されていました。

今回の事故を機に、Agent の実行環境では単なる散発的な timeout（時間切れ）設定に頼るだけでは不十分だと痛感しました。少なくとも以下の 4 つの問いに答えられる必要があります。「各ステップの最大実行時間はどれくらいか？」「ユーザーが停止指示を出した際、リソースは本当に解放されるのか？」「どのような終了方法であっても、フロントエンド側にはその理由が明確に伝わるか？」「一部の処理で失敗した場合でも、モデルは別の経路を試す余地があるか？」

その後、これらを 4 つの「実行時契約」へと整理しました。それは「有界（時間制限付き）」「取消可能」「観測可能」「自己修復可能」という原則です。

現在、SQL のような末端ツールのデッドラインは、各業務コードに散在するのではなく、ツール側で自ら宣言し、統一されたアダプター層がそれを管理します。ユーザーが停止ボタンを押すと、取消信号はクエリを実行している真正の場所まで確実に伝達されます。また、各ラウンドの実行結果が正常終了、タイムアウト、または取消であっても、必ずかつただ一つの型付き finish{reason, detail} を返すことが義務付けられています。異常終了した場合でも、フロントエンド側では生成済みのコンテンツは保持され、回答全体が抹消されることはありません。

継続的なストリーミング出力を行うサブエージェントについては、末端ツールのタイムアウト方式をそのまま適用することはできません。実行環境は推測に頼らず、delegate_agent_* や backend_agent とマークされたツールに対しては deadline-race の制限を豁免し、運用設定でこれを再強化することも禁止しています。これらのタスクには、ラウンド全体のライフサイクル上限、活性検知（ハートビート）、およびストリーミング・ハートビート管理を採用します。

失敗が必ずしもタスク全体の失敗を意味するわけではありません。ツールがタイムアウトした場合、モデルは明確な理由を取得し、クエリの範囲を縮小するか、別の戦略に変更するかを判断します。また、重複呼び出しに対するガードレールも導入しました。過去には、モデルが同じツールに対して 32 回連続で全く同一の要求を発行する事例がありました。現在はシステムがまず代替経路への切り替えを促し、閾値に達するまで繰り返し実行した上で、直ちにサーキットブレーカー（遮断器）を作動させます。

これらの詳細は製品デモではあまり語られません。しかし、Agent を本番環境で運用できるかどうかは、順調な時の知能の高さではなく、タイムアウト、切り捨て、重複呼び出し、取消といった困難な局面において、いかに「体面ある着地」ができるかにかかっています。

対話終了後こそ、Agent の真価が発揮される

以前は、ダッシュボードの完成度を判断する基準を「生成成功して保存されたか」としていました。しかし、使い続けるうちにこの基準が不適切だと感じるようになりました。

ビジネス現場で本当に必要とされているのは、「今日一度だけデータを見ること」ではなく、「将来も忘れずに継続的に確認し続けること」です。

現在、Omega では任意のチャートに監視ルールを設定できます。「コンバージョン率が 5% を下回り、かつ注文数が 1000 を上回る場合」にアラートを発令するといった条件設定や、複数カードを跨いだ複合条件の設定も可能です。バックエンドではスケジュールに従ってクエリを再実行し、条件を満たせば企業微信（WeCom）やメールで通知を送信します。

ダッシュボードは週次または月次の定期プッシュにも対応しています。指定時刻になるとシステムは古いキャッシュを迂回し、最新データを用いてスクリーンショットを再取得します。一部のクエリが失敗しても、全体のプッシュが完全に消失することはありません。送信可能なコンテンツは可能な限り配信され、失敗の詳細はプッシュ記録に保持されます。データ製品にとって、記録を残した上で段階的に機能を低下させる（デグレード）ことは、何も通知せずに静かに無視するよりも遥かに有用です。

編集履歴は常にバージョン管理され、ユーザーは差分（diff）を確認したり、過去の結果に戻ったりできます。コピーや公開を行う際も、バージョン履歴は成果物に付随します。また、権限設定は単に複製されるのではなく、対象空間で再認証されます。アクセス記録、チームコラボレーション機能、そして企業微信ボット連携により、この分析は個人のワークスペースから脱却し、真の協働環境へと統合されていきます。

Skills や MCP といった仕組みも、これらの機能を Omega の外側へ拡張しています。ユーザーが最終的に気にするのはプロトコルの名称ではなく、「企業微信で同じ質問ができるか」「別の Agent がこの分析を呼び出せるか」「データ異常時に自動通知を受け取れるか」といった実用的な価値です。毎回チャットウィンドウを開き直す必要がないことが重要です。

結びに

まだ Omega が「次世代 BI」の答えだと断言するには時期尚早です。実際のデータはデモ用のデータよりもはるかにノイズが多く、企業の権限管理や業務フローは単なるプロンプト（指示文）では対応しきれないほど複雑です。また、多くの機能体験はまだ急速に変化しています。

AI 時代において、ページを生成すること自体のコストは低下していきます。真に価値があるのは、生成されたページが翌日も使えるか、その分析結果が数週間後も有効かを維持できるかどうか、そして AI エージェントが誤作動を起こした際に依然として信頼に値するかどうかという点です。

現在、ベータ版「マルモス（Marmos）」をリリースしています（marmos.qq.com）。ぜひお問い合わせください。

WeChat で開くにはこちらへ