オピニオン記事 第3回（全3回）。第1回「LLMに数字を作らせない」・第2回「AIエージェントは『作って終わり』にできない」の続編です。
業務システムの画面には、昔からよく知られたジレンマがあります。
現場の「この切り口で見たい」に応えるには、ビューを追加開発するしかない。しかしビジネス側のニーズは頻繁に変わるので、作った頃には要望のほうが変わっている。かといって要望のたびに画面を増やせば、UIは複雑化し、設定やコードは分岐し、誰も使わないダッシュボードが溜まっていく。逆に応えなければ、現場は画面をスクリーンショットに撮り、スプレッドシートに数字を転記して、システムの外で資料を作り始める——見覚えのある光景だと思います。
共通化を取れば個別の要望に応えられず、個別対応を取ればプロダクトが太る。この綱引きは、画面単位の改修をいくら重ねても終わりません。プロダクト設計のレベルで、ビュー要求の「置き場所」を決めるルールが要る——これが私たちの出発点でした。
その答えとして、自社の営業基盤「pickles」を設計する際に立てたのが、GLA（Generative Layered Analytics）という設計フレームワークです。picklesの初期からの中核コンセプトですが、まとまった形で社外に紹介するのは本稿が初めてです。机上の提案ではなく、実稼働しているプロダクトの背骨として毎日動いている設計です。運用してみての手応えも、後半で補助的に添えます。
GLAとは何か
一言で定義すると、こうなります。
GLAとは、SaaSに寄せられる「見たい・一覧したい・分析したい」というビュー要求を、固定実装すべきもの・業務操作として提供すべきもの・生成AIに委ねるべきものの3層に分類するための、ビュー設計フレームワークである。
先に強調しておきたいのは、GLAは新しいAI技術の名前ではない、ということです。そして「すべてのBIや画面をAIで置き換えよう」という主張でもありません——むしろ逆です。GLAの核心は、生成AIに任せない画面を先に決めることにあります。第1回に書いた「LLMに何をさせないか」の、画面設計版だと考えてください。安定して頻繁に使われる情報を固定ビューに、日常業務をシンプルな一覧に残すからこそ、生成の層は安心して自由にできる。
図にすると、この3層です。
Layer 1: GCD View（固定ダッシュボード）は、全員または大半のユーザーが、同じ粒度・同じ頻度で継続的に見る情報の層です。主要KPIのサマリー、月次の売上推移、アラートの一覧。ここは事前に設計して固定実装します。LLMは使いません。高速・高信頼で、経営と現場の「共通言語」になる数字を安定供給するのがこの層の仕事です。逆に、特定の部署だけが使う独自指標や、条件が頻繁に変わる探索的な分析は、この層に入れてはいけません。入れた瞬間から画面の肥大化が始まります。
Layer 2: LIST View（業務の一覧）は、日常業務の起点になる層です。顧客一覧、受注一覧、タスクリスト。検索して、絞り込んで、開いて、編集する。ここはシンプルさが正義です。一覧画面に分析機能を詰め込みすぎると、業務操作の道具としての切れ味が落ちていく——多くのSaaSが経験している劣化パターンです。分析はこの層の仕事ではなく、上下の層で気づいたことを「具体的なレコードの確認」につなげるのがこの層の仕事です。
Layer 3: GAI View（生成ビュー）は、顧客固有・探索的・切り口が変わりやすい分析要求を、LLMで生成して応える層です。その場で表・チャート・所見を返すアドホックな分析だけでなく、気に入った分析を定義ごと保存する「保存ビュー」、毎週・毎月自動で更新される「定期実行ビュー」まで含みます。従来なら「個別カスタマイズ」として開発工数を要していたビュー要求の受け皿が、この層です。
実際の生成ビューは、たとえばこんな画面になります。
どの層に置くか——判断のものさし
3層の分類だけなら、きれいな絵に過ぎません。GLAが実務で機能するのは、「この要望はどの層に置くべきか」を判断する共通のものさしがあるからです。私たちは要望が来るたびに、次の軸で見ています。
- 利用頻度: 日次・週次で恒常的に見るか、特定のタイミングだけか
- 共通性: 多くのユーザーに共通か、部署・役割・個社ごとに異なるか
- 安定性: 問いの形が安定しているか、条件や切り口が揺れやすいか
- 正確性の要求: 高信頼の定点か、探索の途中か
そして判断ルールは、突き詰めれば一行です。多くの人が同じ形で見るものは固定へ、業務の起点になるものは一覧へ、問いの切り口が揺れるものは生成へ。
地味に効くのは、この問いがPM・エンジニア・現場の合意形成プロトコルとして機能することです。「その画面、本当に作りますか」という角の立つ議論が、「それはどの層の要求ですか」という設計の議論に変わる。作らないという判断が、要望を断ることと同義でなくなります。
Layer 3は「自由なチャット」ではない
ここがGLAでいちばん誤解されやすく、いちばん大事なところです。
生成の層を「データにチャットを付けたもの」として作ると、業務では成立しません。もっともらしい数字のでっち上げ、権限を越えた参照、再現できない一度きりの回答——チャットの手軽さの裏側は、そのまま業務システムの禁じ手のリストです。GLAではLayer 3を「制約された生成」として設計します。
- 数値はLLMを通さない: 集計は定義済みのメトリクス（セマンティック層）を検証済みコードが実行し、LLMは「どの集計をどう呼ぶか」の選択と言語化だけを担う（第1回の主題です）
- 権限・テナント分離はコードで強制する: 誰が聞いても、その人が見てよいデータの範囲でしか答えられない
- 生成ビューは「版と評価」の上で運用する: プロンプトやモデルの変更は版として管理し、公開前に評価ゲートを通す（第2回の主題です）
そしてもうひとつ、GLAの実装で欠かせないのが、生成された分析を再利用可能な資産として保存する台帳です。私たちはこれを Generated View Registry と呼んでいます。保存するのはプロンプト文字列ではありません。ユーザーの意図、正規化された分析仕様（対象期間・集計単位・使った指標の定義）、再現のための実行仕様、実行ログ。ここまで保存して初めて、生成ビューは「一度きりのAI回答」ではなく、保存・再実行・共有・監査に耐える業務資産になります。picklesでは、保存されたビューの再実行は凍結された定義の決定論的な実行であり、LLMを1トークンも使いません。
生成ビューは「要望の観測装置」になる
Layer 3をこの形で作ると、面白い副作用が生まれます。生成ビューの利用ログが、現場が本当に欲しいビューの観測データになるのです。
同じ生成ビューが繰り返し実行され、複数のチームで使われ始めたら、それは固定ダッシュボード（GCD View）への昇格候補です。逆に一回きりの分析は、そのまま流れて消えてよい。
従来のダッシュボード開発は「要望をヒアリングし、要件を固め、開発し、使われるかどうかは出してみるまで分からない」という賭けでした。GLAではこの順序が逆になります。先に生成ビューとして使われ、使われ続けることが観測されてから、固定実装に投資する。ダッシュボードのMVP検証と言ってもいい。機能追加の判断が、要望の声の大きさではなく利用の実測に基づくようになります。
世界の潮流と、GLAに残るもの
正直に書くと、GLAを構成する要素の一つひとつは固有の発明ではありません（社内の概念調査レポートにも当初からそう明記しています）。そして業界の潮流とも、はっきり合流しつつあります。
自然言語でデータに問いかける分析——最近はagentic analyticsと呼ばれます——は、ThoughtSpot Spotter、Databricks AI/BI Genie、Snowflake Intelligence、Amazon Quick Suite、Power BI Copilotと、主要プラットフォームの標準装備になりました。ダッシュボードを生成できること自体はもう差別化要因ではなく、勝負は「生成した後」——保存・共有・ガバナンス・再利用に移っています。
足回りでは、指標定義を標準フォーマットで交換するOpen Semantic Interchange（OSI）が2025年9月に発足し、2026年1月にv1.0仕様が公開されました。Snowflake・Databricks・dbt・Google・AWSと主要ベンダーが相乗りする、セマンティックレイヤーの業界標準化です。「統制されたセマンティック層を持たないagentic analyticsプロジェクトの6割は失敗する」というGartnerの予測も、あちこちで引かれるようになりました。定義済みの指標の上でだけ生成AIを泳がせる——GLAのLayer 3が置いた前提は、業界標準の方向と同じです。
一方で、「チャットを付ければ分析UXが完成する」という素朴な期待には、研究側からも疑義が出ています。チャット窓という細い覗き穴からデータ全体を探索させることの限界を指摘する論文まで出てきました。答えのテキストだけでなく画面ごと生成するGenerative UIの流れも、この限界への応答だと理解しています。
では、これだけ汎用ツールが進化していく中で、GLAに何が残るのか。
残るのは、「そもそもどの要求を生成の層に置き、どの要求を固定実装のままにするか」というプロダクト設計の判断です。上に挙げたプラットフォームはどれも「Layer 3を作る技術」であって、あなたのSaaSのどの画面を固定し、どの画面を生成に委ねるかは教えてくれません。汎用BIの潮流をそのまま業務システムに持ち込むと、全部チャットにしてUXが壊れるか、従来どおり全部固定で作ってUIが肥大化するかの二択に戻ってしまう。3層の線引きこそが、業務SaaSにおけるGLAの実務価値だと考えています。
実稼働からの手応え
最後に、コンセプトの説明を離れて、実際にGLAを背骨にしたプロダクトを社内で使い込んでみての手応えを、短く添えます。
- 会議資料が「画面のスクショ」から「プロンプト」になった。 チーム別で見ていた数字をメンバー別に割り直す、直近の推移に変える——従来なら開発依頼だった要望が、質問の言い換えで済むようになりました
- 定期実行ビューで、会議準備が「読む時間」になった。 定例で見る分析は保存して定期実行にし、結果を社内WIKIに展開する運用にしたところ、準備は「資料を作る時間」から「所見を読んで論点を書き足す時間」に変わりました
- マニュアルの自然言語検索が、導入の摩擦を下げた。 これはGLAの3層そのものではなく副産物ですが、機能マニュアルをLLMで検索できるようにしたことで、機能数と認知負荷のトレードオフがだいぶ緩みました
- 固定ビューは「最大公約数」だけで足りる。 経営的にはこれがいちばん大きい。個別の・探索的な・一回きりの要求を生成の層が吸収してくれるので、ビュー開発の総量が構造的に減り、中長期の開発負荷が軽くなる手応えがあります
おわりに
このシリーズで書いてきたことは、結局ひとつの思想です。
第1回は実行時の役割分担——数字はコードが作り、言葉はLLMが紡ぐ。第2回は時間軸の設計——モデルは入れ替わる前提で、評価と版管理という仕組みに投資する。そして今回はプロダクト設計の役割分担——すべての画面をAIにせず、固定・一覧・生成の3層に線を引く。
どれも「AIで何ができるか」ではなく、「どの仕事をAIの層に置くか」を先に決める話です。線を引くことはAIの可能性を狭めることではなく、むしろ逆で、境界の内側では安心して自由にさせられる。実稼働するプロダクトを通じて得たいちばんの確信は、これです。
参考
- Open Semantic Interchange（新しいタブで開きます） — セマンティックレイヤー標準化のオープン仕様（2026年1月 v1.0）
- ThoughtSpot Spotter / Databricks AI/BI Genie / Snowflake Intelligence / Amazon Quick Suite / Microsoft Power BI Copilot（各社のagentic analytics製品）
スパイスファクトリー株式会社は、AI駆動開発による内製営業基盤「pickles」の開発・運用の知見をもとに、エンタープライズ領域のAIエージェント導入を支援しています。
