Genie Oneのロールアウト方法：ステップバイステップのエンタープライズ向けプレイブック

ある地域のセールスディレクターが、今四半期の北東地域のパイプラインがなぜ低調に見えるのかを知りたいと考えています。彼女が必要としているのはダッシュボードではなく、次のミーティングの前に得られる回答です。そこで彼女は、いつもと同じ行動をとります。信頼できるデータがどこにあるかを知っている唯一のアナリストにメッセージを送るのです。しかし、そのアナリストはすでに3つの依頼を抱えて遅れています。彼女が回答を得られるのは木曜日になり、それは回答なしで意思決定を下さざるを得ないことを意味します。

Genie Oneはこのギャップを埋めるために構築されました。自然な言葉で質問を投げかけるだけで、ガバナンスが効いたデータを基に、ソースが明記された回答を受け取ることができ、それに続く複数のステップからなる作業をわずか数分で開始できます。

そのようなビジョンを描くのは簡単です。難しいのは、財務、オペレーション、営業の各部門が、日常的に頼れるAIの同僚として、デフォルトでGenieを利用するようにすることです。そして、定着するツールと失敗に終わるツールの違いは、モデルによるものではほとんどありません。ツールが自社のビジネスを理解しているか、そして展開が実際にそれを必要とする人々に届いているかどうかにあります。 

AIの展開が停滞する理由

組織が一度に多くのことをやろうとすると、AIトランスフォーメーションの取り組みは停滞してしまいます。最初の週に12ものデータドメインを対象にしたり、4つのチームが「アクティブ顧客」に対して4つの異なる定義を持っていたり、セマンティックレイヤーの責任者が決まっていなかったり、回答が正しいかどうかを検証する仕組みがなかったりする場合です。 

また、ユーザーは一度でも誤った回答を目にすると、すぐに信頼を失ってしまいます。

解決策は、展開を段階的に進める（シーケンシング）ことです。まずは限定的な質問セットから始め、一握りのアーリーアダプターから信頼を獲得し、彼らのフィードバックに対応した上で、他の業務部門へと意図的に広げていきます。これらのステップを踏むことで、ユーザーは新しいツールを使う習慣を身につけ、その価値を実感し、よりスムーズに導入できるようになります。

ビジネスユーザーにGenieを展開する方法

ビジネスユーザー向けのGenieの展開には4つのコンポーネントがあり、導入が進むにつれてそれぞれ異なる重要性を持つようになります。

Genie Oneは、主要なビジネスユーザー体験です。データをスマートに理解するAIの同僚として、ユーザーは質問を投げかけ、ソースが明記された回答を受け取り、アクションを起こすことができます。

Genie Agentsは、範囲が限定されたドメイン特化型のエージェントです。契約分析に特化したエージェントであれば、PDFから更新日を抽出し、それを売上テーブルと結合して、リスクのあるアカウントを特定するまでの一連の作業を、一度の処理ですべて実行できます。 

Genie Ontologyは、ビジネス用語、メトリクス、およびそれらの関係性を生きたグラフにマッピングし、信頼性に基づいてソースに重み付けを行います。メトリックビュー、Pages、Domainsを通じて、最も重要となる「信頼できる唯一の情報源（グランドトゥルース）」の概念を管理します。Genieは残りの部分を推論し、手動ではドキュメント化しきれない細部までカバーします。 

Unity Catalogは、ガバナンスの基盤です。クエリ実行時に権限、マスキング、リネージ、監査を強制するため、ユーザーやエージェントは許可されたデータにのみアクセスできます。また、Genie Ontologyは権限の強制をサードパーティのアプリケーションやデータにも拡張し、真に統合されたガバナンスレイヤーを実現します。

フェーズ0：パイロット前の基盤構築

目的：自社のデータやインサイトにGenieを通じてアクセスできることを証明する。

ここで1週間を投資することで、チームはGenieを長期的に成功させるための準備を整えることができます。チームが従うべき一般的な手順は以下の通りです。

1. 1つのチームと1つの明確な質問セットから始める。現在、繰り返し発生している課題を抱えるチームを選びます。例えばセールスオペレーションチームとし、質問セットを「パイプラインの健全性（ファネルにあるもの、変動したもの、リスクがあるもの）」とします。 
2. セマンティックレイヤーを定義する。Genieはこれらを信頼できる情報として扱うため、ここでの正確さが後続のプロセスの正確さにつながります。セールスオペレーションの場合、以下のような順序で進めることができます。
   1. Domainsは、ビジネスの目的に応じてアセットを整理する方法です。「Sales Ops」ドメインを設定すると、商談テーブル、パイプラインダッシュボード、Genie Agentsがすべて同じ場所に配置され、ユーザーが探しやすくなります。Pagesはドメインに属する必要があるため、まずはこの設定から始めてください。そうしないと先に進めなくなります。
   2. Metric viewsは、議論の的になりやすい10〜20個の数値をカバーします。成約額、パイプラインカバレッジ、勝率、ステージ転換率などです。メジャーを一度作成しておけば、ユーザーがクエリを実行する際に、担当者、地域、四半期ごとにデータを絞り込むことができます。これにより、ダッシュボードにハードコードされた定義ではなく、全員が同じ定義からデータを取得できるようになります。
   3. Pagesは、それらの数値の背景にある概念を説明する場所です。例えば「適格な商談（qualified opportunity）」のPageには、その定義、別名、および参照元のアセットが含まれます。Genie Oneは推測する前にこの情報を参照し、回答の中でそのPageを引用するため、誰でも内容を確認できます。 
3. 所有者を割り当てる。すべてのカタログアセット、オントロジーの断片、エージェントは、個人であれ、実際の受付ルートを持つチームであれ、責任を追跡できるようにする必要があります。中央のセマンティクスチームはこれをうまく機能させます。問題が発生するのは、所有権が書類上だけに存在し、定義がずれたときに修正する手段がない場合です。
4. ガバナンスとオブザーバビリティを確立する。アカウントレベルでパイロットユーザーをプロビジョニングします。ワークスペースレベルでユーザーにConsumerアクセス権限を付与し、グループを通じてメトリックビューの背景にあるUnity Catalogオブジェクトへの`SELECT`などのアセット権限を付与し、さらに1つのSQLウェアハウスへの`CAN USE`を付与します。列マスキングを確認します。監査ログを有効にします。Ontology Snippetsをオンにし、使用状況とコストを可視化するためにUnity Gatewayコントロールをオンにします。これは、利用者が500人ではなく、5人の段階で行うのが最適です。
5. 「良好」の定義を決める。チームが実際に尋ねる25〜50個の質問と、その既知の正しい回答をドキュメント化します。セールスオペレーションの場合、「Q3のカバレッジ率はいくつか」、「今四半期から外れた案件はどれか」、「EMEAの勝率は前年と比べてどうか」などです。自分で答えられない質問は、Genieの回答を評価することもできません。

パイロットの開始前、およびセマンティクスを変更した後に、質問セットに対してGenieを評価します。ここでの不一致（ミス）は、定義されたセマンティクスにギャップがある可能性を示すため、非常に有用です。Genieが返してきたカバレッジ率が不自然に見える場合、その原因は通常モデルではありません。誰もパイプラインカバレッジをメトリックビューとして定義していなかったため、Genieがもっともらしくて誤った内容でそのギャップを埋めてしまったのです。それぞれの不一致は、次に管理すべき対象を示す道標となります。

フェーズ1：最初のチームでのパイロット

目的：Genie Agentsが、1つのドメインにおいて、関心の高い少人数のグループに対して信頼できる回答を提供できることを証明する。

• 率直なフィードバックを提供してくれる5〜10人のパイロットユーザーを募集する。 
• 毎週評価を実施する。すべての誤った回答と「わかりません」という回答を記録し、その根本原因（通常は定義の欠落、曖昧な列、またはオントロジーのギャップ）に対処します。
• 終了基準を事前に設定する。パイロットを開始する前に、どのような状態になれば「準備完了」とするかを決定します。注目すべき3つのポイントは以下の通りです。
  • 実際の意思決定を委ねられるレベルで精度が安定していること。
  • パイロットユーザーが指示されることなく、従来のワークフローよりもGenieを優先して使用していること。
  • 定義修正のバックログが増加するのではなく、減少していること。

フェーズ1が成功したことを示す最も明確な兆候は、行動の変化です。パイロットユーザーが、依頼を出す代わりにGenieの回答を転送することで同僚の質問に答えるようになることです。

フェーズ 2：隣接するチームへの拡大

目的：エージェントが最初のパイロットを超えて拡張できることを証明する。

• 2〜3個の隣接するドメインを追加する。それぞれに独自のセマンティクス、オーナー、評価セットを設定します。フェーズ 1 のテンプレートを再利用してください。 
• 共有定義をオントロジーに昇格させることで、「収益」や「アクティブカスタマー」がすべてのエージェントで同じ意味になるようにします。チーム固有の定義は、それぞれのドメイン内に保持します。
• 軽量なレビューワークフローを追加する。新しいチームへの拡大は、オーナーが評価基準をクリアし、権限、マスキング、機密性の高い列をカバーするガバナンスチェックに合格した後にのみ行います。プロセスは軽量に保ちましょう。
• ドリフト（乖離）に注意する。各ページにオーナーとレビュー頻度を設定し、後から気づくのではなく、メトリックビューの変更をレビューします。ソースクエリから乖離した定義は、1つの誤った答えを生むだけでなく、その定義が参照されるすべての場所で誤った答えを伝播させてしまいます。
• コミュニティを構築する。専用の Slack チャンネル、月1回のオフィスアワー、効果的な質問方法に関する簡単なガイドを用意します。導入は「うまくいった」という同僚の報告を通じて広がるため、公開チャンネルはそれを可視化する最も効率的な方法です。

フェーズ 3：組織全体での AI 同僚

目的：Genie One をチーム全体のデフォルトの AI 同僚にする。

• アカウントレベルの Genie One アクセスを展開することで、ユーザーがドメインをまたいで1つの AI 同僚を利用できるようにし、必要に応じてクロスワークスペースへのアクセスも可能にします。 自動アイデンティティ管理を有効にし、アイデンティティプロバイダーで既に管理しているグループに対して権限を付与することで、ユーザーが最初のログイン時に表示されるようにします。
• ワークスペースの指示を追加することで、各チャットの会話に、チャットがどのように応答すべきかのガイドラインを設定します。
• 所有権を分散（フェデレーション）させる。中央のプラットフォームチームがオントロジー、標準、ガードレールを所有し、ドメインチームがそれぞれのエージェントと定義を所有します。すべてを中央集権化するとボトルネック（キュー）が生じ、何も標準化しないと矛盾するエージェントが生まれて信頼が損なわれます。
• Genie One がアクセスできる範囲を管理する。 Unity Gateway は、ガバナンスをデータだけでなく、Genie One が使用するツールにまで拡張します。MCP サーバーは権限付与の対象となる保護可能オブジェクトになり、ツールフィルタリングによって Genie が呼び出せるものを絞り込み、サービスポリシーによって入力と出力を検査します。
• ユーザーが普段使っている場所で対応する。ユーザーが外出先でも Genie とチャットできるように、iOS および Android アプリを有効にします。また、ユーザーが Slack、Teams、Excel、または Google スプレッドシートでの作業を好む場合は、それらのツールに Genie を埋め込んで、コンテキスト内で質問できるようにします。あるいは、完全に別のエージェントで標準化している場合は、Genie MCP アプリ を使用して、引き続き Genie オントロジーのメリットを享受できるようにします。

現実的なタイムライン

• フェーズ 0：1〜2週間
• フェーズ 1 パイロット：4〜6週間
• フェーズ 2 拡大：次の四半期
• フェーズ 3 組織全体：その後1〜2四半期

準備が整ったという確証が得られたら、次のフェーズに進んでください。定義の整理にパイロット期間がさらに必要な場合は、その追加時間を使ってよりスムーズな展開を確実にするのが賢明です。

まずは1つのチームから始める

これをうまく進められるチームは、必ずしも最もクリーンなデータを持っているチームや、最大のプラットフォーム組織を擁するチームではありません。彼らは、1つのチーム、1つの管理されたドメイン、そして評価基準となる一連の質問からスタートし、それを機能させ、そこから拡大するための足がかりを得たのです。

Genie のドキュメントを確認して、今すぐ最初の Genie エージェントのセットアップを開始しましょう。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事