Oktaが大規模なAIエージェントのガバナンス文脈から得た知見

最終編集日時：2026年10月26日

dbt Summit 2026の分科会において、Oktaでアナリティクスエンジニアリング部門のシニアマネージャーを務めるプージャ・クレイヘン氏は、自身のキャリアを通じて気づいたあるパターンを軸に講演を展開しました。すなわち、ダッシュボードの構築、学習コンテンツの作成、そしてAIエージェントの開発――これらはいずれも、異なるインターフェースをまとう同一の仕事であり、その本質的な問いは常に変わらないということです。それは、向こう側にいる人間――あるいは今やエージェント――が、目の前に映る情報を本当に信頼できるかどうかという問題です。Comcastではダッシュボードを構築する際、常に問われたのは「その数値はそもそも正しいのか」ということでした。Pluralsightでは学習コンテンツを作成する際、課題は「果たして誰かが実際に何かを学んでいるのか、それとも単に動画を見ているだけなのか」という点へと移っていきました。

Oktaでは、インターフェースが完全に消え去り、チャートもコースもなく、ただ機械が回答を生成するだけとなりましたが、その下には依然として、エージェントが本当に自らの話している内容を理解しているのか、それとも単に自信があるように聞こえているだけなのかという、同じ信頼に関する質問が残されていました。

Crahen氏のチームは、デリバリー、ゴー・トゥ・マーケット、プロダクト、ファイナンス各部門に約13名のアナリティクスエンジニアを配置しており、レポーティングにはTableau、データウェアハウスとしてSnowflakeを活用する、より広範なテクノロジー・データ・インテリジェンス組織内に位置しています。

「数年が経った頃、エージェントの構築自体は決して難しい作業ではなかったのだと気づきました」とクレイヘン氏は語りました。「むしろ、それが何を認識し、信頼できるかという点こそが難題だったのです。」

Oktaの初期のAI実験は、SnowflakeのUI内に直接構築されたセマンティックビュー上で実行され、Snowflake Cortexエージェントに直接接続されていました。動作は問題なく、しかも高速でしたが、これらのセマンティックビューは、実際にビジネスロジックを定義しているガバナンス対象のdbtモデルとは完全に切り離されていました。

Crahenのチームは、その基盤に3つの欠陥を発見しました。Snowflakeとdbtの間でコンテキストが断片化されていること、すべてがUIのクリック履歴に保存されるため監査可能性が欠如していること、そしてエージェントの指示がすべて一元化され、エージェントが常に把握しておくべき事項と参照すべき事項との区別がなくなっていることです。

それらの3つの欠陥、すなわち断片化、監査可能性の欠如、そして一元化されていないひとつの巨大なデータブロックは、下流では具体的な3つの障害として現れました。誰も何が存在するのかを把握できませんでした。なぜなら、セマンティックビューにはSnowflake外部にそれらを公開するカタログがなかったからです。また、誰も見つけた内容を信頼できませんでした。共有される記録システムがなく、それが最新のものであることを確認する手段がなかったためです。さらに、各チームは、共有された何かを基に作業するのではなく、結局は独自に定義をゼロから再構築することになってしまいました。

修正は、dbt 内部で完全に構築され、通常のプルリクエストを通じて配信される三層構造のエージェントコンテキストフレームワークでした。モデルおよび列レベルのメタデータには、YAML に新たな「agent」サブブロックが追加され、どの用途で安全に使用できるか、どのような用途を避けるべきか、そして自動的に適用すべきフィルターが明示されます。Markdown 形式のコンテキストドキュメントでは、社内全体の事実（Okta の会計年度は2月1日始まり）やドメイン固有のルーティングルールが記述されています。

そして、SnowflakeのUIからdbt独自のセマンティックレイヤー仕様へと移行されたセマンティックビューは、ファクト、ディメンション、メトリクスの管理下に置かれた、PRでレビューされるソースとなります。セマンティックビューをdbtに取り込むには、既存のSnowflakeのセマンティックビューからDDLを取得し、それを自動的にdbtのセマンティックビュー仕様へ変換するスラッシュコマンドに紐付けられたカスタムスキルが必要でした。また、Oktaはdbt Coreに関する公開GitHubディスカッションを開設し、Cortexエージェントのようなものについて、通常のdbtモデルのマテリアライゼーションとして扱うべきなのか、それとも露出のように独自の第一級ノードタイプとするべきなのか、議論を呼びかけ、参加者からの意見を求めました。

3つすべてが、オープンでウェアハウスネイティブなメタデータ標準であるAgents Schemaに自動的に同期されるため、CortexであれClaudeであれ、SQLにアクセスできるあらゆるエージェントが、同一の信頼できる情報源から読み取ります。実際には、これは、まったく異なる2つの製品であるClaudeとSnowflake Cortexが、異なる経路を通じて全く同じ基盤となるコンテキストを読み取ることを意味します。ClaudeはMCP上でメタデータを直接クエリし、コンテキストドキュメントをMarkdownファイルとして読み込む一方で、Cortexは同様の情報を検索サービスと独自のスキル構成を通じて読み取ります。dbtでルールを一度作成すれば、両方の利用者がそれを継承し、明日新たに3つ目のエージェントを追加しても、重複なく同じルールを引き継ぎます。

クレイエン氏の説明によれば、その利点は、誤った回答を修正する際に、もはや不透明なエージェント設定を編集して複数のサイクルにわたって再デプロイする必要がなくなる点にある。アナリティクスエンジニアがdbtでコンテキスト層に対する変更をマージすると、そこからデータを読み込むすべてのエージェントが即座に賢くなる。「その結果、100番目の質問に対しても、最初の質問と同じ品質の回答が得られるのです」と彼女は述べた。

「重要なのはエージェントではなく、インフラとしての文脈です。」

チームの次のステップは、コンテキストが変化するたびにエージェントに対して検証済みのクエリを実行する自動回帰テストの導入、コンテキストを単一のドメインにとどまらない形で拡張すること、そして最終的にはエージェントの回答と正解との間のフィードバックループを閉じて、修正結果をコンテキストドキュメントへ自動的に反映できるようにすることです。これにより、Crahen氏が述べたように、「信頼するが検証する」から、測定可能な精度スコアへと進むことになります。

dbt Summit 2026の基調講演および分科会をすべてオンデマンドで視聴できます。dbt Summit 2026をオンデマンドで視聴する →

dbtの利用を開始する

実際にスケールするデータインフラを構築しているアナリティクスエンジニアの仲間に加わりましょう。

dbt Wizard CLI をインストールする

分析エンジニアリング専用に設計されたエージェントで、すぐに使い始めることができます。どのツールを呼び出すべきか、どのコンテキストを取得すべきかを把握し、あなたに結果を提示する前に自らの作業を確認します。

情報源

dbt