SemanticFlow は有用なリマインダーであって、プロダクトそのものではない

いまでも多くの AI プロダクトは、分析をチャットの問題として扱っています。

質問する。答えを得る。そこで終わる。

それはデモには十分です。しかし、同じ質問を何度も投げ、時間をまたいで比較し、他の人の前で説明しなければならない反復的な分析業務では、すぐに限界が見えます。

オープンソースツールとしての SemanticFlow が有用なのは、より完全な一連の流れを思い出させてくれるからです。

• まずセマンティクス上の意味を解決する
• 次にツールを呼び出す
• 最後に結論へ証拠を結びつけたままにする

この順序は当たり前に聞こえます。ですが実際には、多くのシステムがこのどれかを少なくとも一つは飛ばしています。

まずセマンティクスから始める

もしシステムが、指標、ディメンション、エンティティ、ビジネス概念が何を意味するのかを知らないなら、それは本当に分析しているのではありません。prompt と周辺コンテキストから推測しているだけです。

それで済むのは、質問が気軽なもののときだけです。

同じ質問に、週をまたいで同じ業務上の意味で答え続けなければならないなら、それでは不十分です。

セマンティクスの仕事は、ほかのすべてが始まる前に、その曖昧さを取り除くために存在します。

意味が固定されれば、システムは毎回推測し直す必要がなくなります。

• GMV が net なのか gross なのか
• channels が source ベースなのか attribution ベースなのか
• 「active user」が login、visit、transaction のどれに基づくのか

重要なのは、システムを賢く見せることではありません。

重要なのは、問いを安定させることです。

そのあとでツールに狭く明確な仕事をさせる

ツール利用は重要です。ただし、それはセマンティクス層が先に整ってからです。

セマンティクスがなければ、ツール選択は試行錯誤になります。
セマンティクスがあれば、ツール選択には境界が生まれます。

その時点で、異なるツールは異なる仕事を持ちます。

• データベースは事実を確認する
• ファイルやスプレッドシートは局所的な文脈を補う
• ウェアハウスはより大きな探索を担う
• セマンティックカタログは定義を解決する

モデルは、利用可能だからという理由でツールを選ぶべきではありません。
現在のセマンティックな問題が必要としているから選ぶべきです。

そこから、データ Agent は単に印象的なものではなく、本当に役に立つものになり始めます。

結論のそばに証拠を置いておく

AI 分析における最大の失敗は、必ずしも間違った答えそのものではありません。

どこから来たのかが見えなくなった、自信満々の答えです。

もしシステムが次を説明できないなら:

• どのデータを使ったのか
• どのデータを除外したのか
• どんな変換が行われたのか
• どんな前提がまだ未解決なのか

その答えは信頼しにくく、レビューしにくく、再利用もしにくいものになります。

だからこそ、良い分析パスは証拠を出力の一部として残すべきであり、内部実装の詳細として隠してはいけません。

証拠が不十分なら、システムはそう言うべきです。
セマンティック定義が欠けているなら、そう言うべきです。
結果が事実ではなく判断なら、そう言うべきです。

それは弱さではありません。ほかの人が頼れる分析に必要な最低限の基準です。

これが Tukun にとって意味すること

Tukun にとって大切なのは、次の方向です。

• セマンティクスは第一級資産として公開され、再利用される
• 意味が明確になったあとでツールが呼ばれる
• 結論はその証拠パスと結びついたまま保たれる
• 制約や限界は隠さず明示される

私たちは、データ Agent が人間の判断を置き換えるべきだとは考えていません。

むしろ、判断を不安定にする厄介な部分を取り除くべきだと考えています。

• 曖昧な定義
• 散らばった証拠
• 繰り返される手作業の探索
• たどり直せない結論

これは派手なデモよりも地味な考え方です。

それでも、実務の中で最後まで残るのはこちらです。