Semantic Layerの先へ：ビジネス部門が担うContext Engineering
前の記事では、BIが「人がデータに聞く」ものから「データが先に語る」ものへ変わっていくと書きました。AIが先に動くなら、その前に二つのことを知る必要があります。何が正しいか。そして、今、何が重要か。
前者を支えるのがSemantic Layerです。売上とは何か。アクティブユーザーをどう数えるか。どのテーブルを正とするか。こうした定義は、全社で共有され、誰が分析してもAIが分析しても同じである必要があります。
でも、正しい売上の定義を知っているだけでは、売上が7％落ちたときに「今すぐ見るべきか」は分かりません。広告の獲得単価が10％悪化しても、財務チームから見れば月初によくある振れかもしれない。昨日キャンペーンを始めたマーケティングチームから見れば、すぐに止めるべき異常かもしれません。
この問題はすでに顕在化しています。VentureBeatは2026年8月、調査対象企業の68％が、AIエージェントの自信ありげな誤答を「不足または不整合なビジネスコンテキスト」に起因すると特定したと報じました。前回調査の57％から増えています。
Semantic Layerを弱くすべきだという話ではありません。むしろ逆です。「何が正しいか」はデータチームが強く統治する。その上で、「今、何が重要か」はKPIを持つビジネス部門が更新する。 この記事で考えたいのは、その役割分担です。
二つのコンテキスト、二つのオーナー
AIが会社の数字を正しく理解するための情報と、AIが「今、何を重要と見るか」を判断するための情報は、性質が違います。
ひとつは、全社で共有するデータの定義です。売上とは何か、アクティブユーザーをどう数えるか、どのテーブルを正とするか、誰がどのデータを見られるか。会社全体で同じ数字を使えるように、データチームが整えます。
もうひとつは、各チームがAIに伝える判断基準、Decision Contextです。今期の目標、注力中のセグメント、許容するしきい値、進行中の施策、例外として無視してよい変化などが含まれます。これは、そのKPIに責任を持つマーケティング、営業、カスタマーサクセスなどの各チームが更新します。
Context Engineeringという考え方自体も、単なるプロンプト設計より広いものとして整理され始めています。Anthropicは、Context EngineeringをPrompt Engineeringの自然な発展と位置づけています。System Instruction、Tools、External Data、Message Historyなど、AIエージェントが判断するときに利用できる文脈全体を設計し、維持する考え方です。データエージェントにとって重要なのは、その文脈にはデータの意味だけでなく、「今、何を重要と見るか」という事業側の判断も含まれることです。そして、その判断を最も速く更新できるのは、KPIに責任を持つチームです。
全社で共有するデータの定義は、部署ごとに変わってはいけません。一方、Decision Contextは事業の優先順位に合わせて変わります。だから、決める人も更新する速さも同じにはできません。
ここが「Semantic Layerの先へ」という意味です。Semantic Layerは、AIが何を正しい数字として扱うかを揃えるために必要です。ただし、各チームの優先順位まで中央で固定することはできません。「今、何が重要か」をAIに伝えるContext Engineeringは、KPIに最も近いビジネス部門側で更新される必要があります。
図：全社で共有するデータの定義と、各チームが更新するDecision Contextは、決める人も更新する速さも異なります。
Semantic Layerは「何が正しいか」を統治する
AIが自動で動くほど、データチームが全社の指標定義とアクセス制御を整える役割は重要になります。
AIが自動で監視し、レポートを送り、経営判断に影響するなら、売上やアクティブユーザーの定義は部署をまたいで一致していなければなりません。数字の意味が揃っていないままAIだけを能動的にしても、混乱が速くなるだけです。
売上やアクティブユーザーの計算方法、正とするデータ、誰が何を見られるかは、データチームが全社で整える。
一方で、「今月は新規獲得より既存顧客の利用低下を重く見る」「このキャンペーン期間だけは通常より厳しいしきい値で見る」といった判断は、そのKPIに責任を持つチームが決める。
各チームが、担当するKPIについてAIが使う判断基準も更新する。私は、この分担が自然だと思っています。
コンテキストの受け渡しが、次のボトルネックになる
マーケティングや営業などの各チームが優先順位を持っているだけでは、AIは動けません。その判断を、具体的な監視条件や分析の手順へ変える必要があります。
これまでなら、事業チームがデータチームに依頼します。データチームが要件を聞き、SQLやダッシュボードに落とし込み、確認して公開する。数週間後に優先順位が変われば、もう一度依頼する。
この分業には意味があります。ただ、四半期の途中で注力顧客が変わるたび、施策が始まるたび、しきい値を調整するたびに同じ往復をするのは現実的ではありません。
この往復は、AIで実装が速くなるほど目立つようになります。クエリやダッシュボード、監視を作るコスト自体が下がるほど、「何を重要と考えているか」を伝え、実装できる形に翻訳する受け渡しの比重が大きくなるからです。次のボトルネックは、コンテキストの受け渡しです。
では、依頼をやめて、すべてを自由なプロンプトにすればよいのでしょうか。それも違います。誰が何を変えたのか分からず、同じ指標に別の定義が混ざり、監視の根拠も追えなくなります。速くはなりますが、信頼できません。
「今、何が重要か」のContext Engineeringはビジネス部門に近づける
必要なのは、役割を分け直すことです。売上やアクティブユーザーの計算方法、正とするデータ、閲覧権限といった全社で共有するデータの定義は、これまで通りデータチームが整えます。その上で、「今月はどの顧客を優先するか」「どんな変化が起きたら確認するか」といった判断基準（Decision Context）は、KPIを持つチームが自分たちの言葉で更新します。
チームが判断基準を更新すると、AIがそれを共通のデータ定義に基づく監視や調査へ変換し、根拠付きのシグナルとして人へ届けます。毎回データチームへ実装を依頼する往復を減らしながら、共通の定義とガバナンスは維持できます。
変わるのはデータの保存場所ではありません。共通の数字と意味は全社で揃えたまま、「今、何を重要と見るか」だけを、そのKPIに最も近いチームが更新する。 この役割分担によって、AI-native BIを事業の変化に合わせて更新し続けられます。
図：信頼できるデータ基盤と、チームがAIに伝える判断基準が結びつき、AIの監視と調査を通じて、根拠付きのシグナルとして人に届きます。
人が増やすべき仕事は、データ作業ではない
各チームがDecision Contextを持つことは、データ作業まで自分たちで引き受けることではありません。
AIが先に変化を知らせる仕組みを使うために、現場の人が設定画面を増やし、SQLを覚え、監視ルールを細かく実装するようになったら、本末転倒です。
人がAIに伝えるべきなのは、判断です。
「更新90日前の顧客を重く見る」「利用量が30％以上落ちたら確認する」「この施策の間は東日本の新規顧客を優先する」。事業の言葉で書かれた意図を、AIがクエリ、フィルタ、ダッシュボード、監視、調査、レポートへ変換する。
チームは判断を更新する。データ作業はシステムが引き受ける。
この関係になって初めて、Decision Contextを各部署が持つ意味が出てきます。
判断を、実際の監視と調査につなげる
AIが先に重要な変化を知らせるBIでは、ダッシュボードを作る仕事と、その後に監視する仕事を分けない方がいい。大事なのは、同じAIエージェントが、成果物を作ったときの目的を引き継いだまま、継続的な監視と報告まで担うことです。
まず、チームが伝えた判断基準をもとに、AIエージェントがデータを調べ、クエリやダッシュボード、レポートを作る。次に、同じエージェントがその分析を定期的に監視し、重要な変化があったときは、必要な形式のレポートにまとめてメールやSlackなど普段使う場所へ届ける。成果物を作った目的と、変化を知らせた理由が同じ文脈に残るので、監視だけが独り歩きしません。
たとえば、契約更新が90日以内に迫り、利用量が30％以上落ち、サポートでの反応も悪化している顧客を見つけたいとします。AIエージェントは、顧客、利用量、サポート履歴のデータを使って分析とダッシュボードを作り、その後も同じ条件で監視を続けます。該当する顧客が見つかれば、誰に注意が必要なのか、どの変化が根拠になったのかをレポートにして担当者へ届けます。
ただし、届けて終わりではありません。受け手はレポートや作業スレッドから、そのまま追加の質問ができます。さらに、裏側のダッシュボード、クエリ、元のデータまで遡れる。通知が多すぎればしきい値を直し、重要ではなくなった顧客層は外し、見落としていた兆候があれば加える。最初の依頼から深掘りまで、同じ調査の流れが続きます。
こうしておけば、経験のある担当者が異動しても、何を見ていたかだけでなく、なぜ見ていたのかも組織に残ります。
図：同じAIエージェントが、成果物の作成から継続監視、配信、その後の深掘りまで文脈を引き継ぎます。
この仕組みは、一度作って終わりではない
一度書いた判断基準も、事業の状況が変わればすぐ古くなります。
先月は重要だった顧客層が、今月は違う。厳しすぎるしきい値で通知が増えた。重要だと思っていた兆候が、実際には解約につながらなかった。逆に、見ていなかった変化が大きな問題につながった。
知らせを受け取ったチームが結果を振り返り、AIに伝えた判断基準を直す。その変更が次の監視に反映される。
この流れが最も速く回るのは、知らせを受け取るチームと判断基準を更新するチームが同じときです。自分たちが責任を持つ数字だから、古くなった判断にもすぐ気づけます。
Squadbaseでは、どう実現するか
複数の製品を組み合わせれば、似た仕組みを作ることはできます。ただ、技術的に作れることと、ユーザー部門が日々使い続けられることは別です。
データを専門に扱うチームなら、指標、アラート、分析、定期実行、配信を別々の製品で管理し、それらの接続を保守できるかもしれません。マーケティング、営業、カスタマーサクセスなどのユーザー部門は、それ自体が仕事ではありません。監視条件はどこで直すのか、レポートはどこで変更するのか、通知の根拠はどこにあるのかを、複数の製品にまたがって覚える余裕はありません。
もし優先順位が変わるたびに複数の設定を更新したり、データチームへ修正を依頼したりする必要があれば、各チームが自分で判断基準を更新するという考えは成り立たなくなります。結局、データチームとの往復がまたボトルネックになります。
Squadbaseは、この一連の仕事をシンプルな一つの体験にしています。同じプロジェクトの中で、同じAIエージェントが会話からクエリやダッシュボード、レポートを作り、その分析を定期的に監視し、結果をメールやSlackへ届ける。エージェントの作業はスレッドに残るので、受け手は届いたレポートから追加の質問をし、ダッシュボード、クエリ、根拠となるデータへ進めます。
図：届いたレポートから同じSquadbaseプロジェクトを開き、エージェントのスレッドで質問を続けながら、ダッシュボード、クエリ、元データまで確認できます。
違いは、たくさんのツールを一つの画面に集めたことではありません。成果物を作るときの目的と根拠を、同じAIエージェントが監視、配信、その後の深掘りまで引き継ぐことです。
ユーザー部門がやることは、「今、何が重要か」を伝え、できた分析を確認し、必要な形式で届いたインサイトを読み、気になった点をさらに調べることです。そのために、複雑なデータツールの組み合わせを自分たちで運用する必要はありません。
Squadbaseは、この役割分担を一つの体験としてつなぐために設計しています。全社で共通に使う数字の定義や信頼できるデータは、データチームが整える。今、どのKPIや顧客を重視するかは、その成果に責任を持つチームが決める。その判断から分析の作成、継続的な監視、インサイトの配信、根拠の確認と深掘りまでを、一つの流れとしてつなぎます。
