Anthropic が Claude を活用したセルフサービスデータ分析を可能にする方法

- カテゴリ - 製品Claude Code - 日付2026年6月3日 - 読了時間5分 - シェアリンクをコピーhttps://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude 多くのデータサイエンスおよびデータエンジニアリングチームが証言するように、セルフサービスビジネス分析の機能強化は従来、非常に過酷な作業でした。 技術的な知識が少ない同僚のために、広範で非正規化されたテーブルを通じてデータモデルをよりアクセスしやすくすることは、事業規模が大きくなるにつれて定義が矛盾する重複したビューを生み出す結果となり（SQLを学ぶ意欲の低い従業員との間のギャップを埋める効果はほとんどなく）、あるいはユーザーに対してより厳格に隔離された環境を作成することは、長期的なビジネス質問の多くを見逃し、チームが業務をサイロ化することでメトリクスやダッシュボードが肥大化する原因となります。 大規模言語モデル（LLM）の台頭は、これらの課題を回避するセルフサービス分析のための新たな道を提供します。しかし、Claude にデータウェアハウスを指針させ、エージェントに実行させるだけでは、誤った精度の感覚を生み出す恐れがあります。 アドホックな要求からの解放による最初の喜びは、この設定がステークホルダーを、以前は慎重にキュレーションされたデータセットへと導いていた基盤インフラストラクチャ、ドキュメント、専門知識から切り離しているという現実を知ることで、恐怖へと変わります。 Anthropic では、ビジネス分析クエリの 95% が Claude を通じて自動化されており、集計すると約 95% の精度を達成しています。このしばしば単調で反復的な作業を Claude に任せることで、データサイエンスチームは因果モデリング、予測、機械学習といったより戦略的な業務に集中できるようになります。 Anthropic のトップクラスな Claude Code ユーザー数十名との面談や、分析エージェントにおける無数の設計パターンを目撃した結果、LLM を活用する他のデータチーム向けにベストプラクティスを確立しました。本稿では、Claude がセルフサービス型のビジネスインサイトを推進する能力を最大化するためのこれらのヒントとアプローチについて共有します。具体的には以下の内容を含みます: - 分析の精度はコード生成の問題ではなく、コンテキストと検証の問題である理由; - 最も多くのエラーを引き起こす 3 つの失敗モード; - これらのエラーに対処するために構築したエージェント型分析スタック; - 効果性の測定方法; - 当社のスキルの大半を作成する際の基本的なテンプレート（付録参照） ## データはソフトウェアではない LLM の生成能力は両刃の剣です。複雑な問題に対する創造的な解決策を可能にするメカニズムが、同時に誤った出力を幻覚（hallucinate）させる原因にもなり得ます。分析エージェントにおける課題を完全に理解するためには、それらをコーディングエージェントと比較することが有用です。 コーディングはモデルの創造性を評価する開かれた解決空間ですが、ドキュメントとテストはハルシネーションに対する自然なガードレールを提供します。一方、分析ユースケースでは、単一の正しいソースを用いた単一の正解が存在することが多く、その正しさを証明する決定論的な方法がありません。 ![image](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6a20480bedac32484c00d6b9_4a7645b6.png) セルフサービス・エージェント型ビジネス分析における複雑さは、主にデータの曖昧さにあります。中核的な問題は、ユーザーの質問をデータモデル内の具体的かつ最新のエントティにマッピングし、それらを正しく扱う方法を理解できるかどうかにかかっています。これができれば、生成される実行コードや SQL は単純なものになります。 我々は、不正確な回答の绝大多数を占めるこの問題の 3 つの属性を特定しました： - コンセプトとエンティティの曖昧さ：データモデルには数百もの有効な選択肢（潜在的に数百万のフィールドの中から）が存在するため、エージェントはユーザーの質問に最も適切に答える正しいフィールドを選択できません。例えば、アクティブユーザー数を測定する場合、「アクティブ」とみなす行動とは何か？不正なユーザーを含めるべきか？どの期間を遡って見るのか？ - データの鮮度低下：データソース、ビジネス定義、スキーマは絶えず変化しており、アセットやエージェントの知識が古くなり、微妙に間違った回答を返すようになります。 - 検索失敗：正しい情報がデータモデル内に存在し適切に注釈付けられていたとしても、検索空間の広大さゆえに、エージェントがそれを見つけられないことがあります。 該当する項目が見つかりませんでした。 0/5 Claude Code を入手 電子書籍 ![image](https://cdn.prod.website-files.com/6889473510b50328dbb70ae6/6889473610b50328dbb70b58_placeholder.svg)![image](https://cdn.prod.website-files.com/6889473510b50328dbb70ae6/6889473610b50328dbb70b58_placeholder.svg) ## エージェント型分析スタック Anthropic では、これら 3 つのエラーを最小限に抑える主な手段として、エージェント型データスタックを活用しています。各レイヤーは主にこれらの問題の 1 つ以上に対処するために存在します： - エンティティの曖昧性：データ基盤と真実の源は、妥当なエンティティの範囲を狭め、単一の統制された回答に至らせます。 - 鮮度の低下：ビジネスの変化に伴い、メンテナンスおよび検証プロセスがすべての要素が腐敗するのを防ぎます。 - 検索失敗：スキルにより、エージェントがその回答を確実に見つけ、正しく使用できることを保証します。 このセクションでは、各レイヤーをどのように構築したかについて議論します。 ![image](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6a2049920443016925a3ef72_74528df2.png) ## データ基盤 分析エージェントの精度を確保する上で最も重要な側面は、データモデル、変換、テスト、データウェアハウス内のテーブル、およびそれらを記述するメタデータを備えた強力なデータ基盤です。[次元モデリング](https://en.wikipedia.org/wiki/Dimensional_modeling)、シフトレフトテスト、重要パイプラインにおける鮮度と完全性のチェックなど、標準的なデータエンジニアリングおよびデータ品質のプラクティスはすべて依然として適用されます（これらについては再論しません）。 ![image](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6a2049920443016925a3ef75_98412372.png) 次元モデリングなどの標準的なデータエンジニアリングプラクティスは、これまで通り極めて重要です。変化するのは、データモデルの最終ユーザーがデータ専門家（例えばデータサイエンティスト）ではなくなり、インフラストラクチャの基礎知識やデータの専門性にはばらつきのある一般ユーザーに代わって行動するエージェントになった点です。この転換は課題をもたらします。なぜなら、最終ユーザーが基礎的な正しさを検証する方法を知らないため、結果に対してその正しさを検証することをユーザーに要求することはできないからです。 データ基盤層は主に曖昧性の解消を目指しています。例えば、「収益」が四十の妥当な候補の一つではなく、管理された単一のデータセットに解決される場合、エージェントが検索を行う前に問題はほぼ消滅します。また、これが最初の鮮度低下対策の場所でもあります。なぜなら、標準的なモデルを定義する同じリポジトリこそが、それらが最新の状態を保つよう強制するための自然な場所だからです。 いくつかのプラクティスが特に効果的であることが確認されています： - 標準化されたデータセットの作成：最も一般的な失敗は、エージェントが概念（例：製品 X の収益）を単一の正しいテーブル、列、および指標定義にマッピングできないことです。これは通常、微妙に異なる実装を持つ複数の妥当な候補が存在するためです。解決策は、より少数で厳格に管理された論理モデルを採用することです。明確に所有され、利用準備が整っており、発見可能な標準化された単一信頼源データセットの小さなセットを厳選し、ほぼ重複するデータを積極的に非推奨とします。物理的な集計やキャッシュもコストとパフォーマンスのために依然として重要ですが、それらは代替案として並存するのではなく、標準化モデルから機械的に派生させるべきです。目標は、エージェントが概念を検索した際に、単一の管理された回答に到達することです。 - 基準の厳守：標準化モデルと指標定義がツール（エージェントが構造的にまずこれらへルーティングされます。以下で詳述）、CI（これを迂回する変更はレビューで失敗する）、および命令（下流チームは管理されたレイヤー上で構築するか、その理由を説明する）によって強制される場合にのみ基盤が成立すると私たちは見出しています。強制を伴わないガバナンスは、すぐに複数の候補の問題へと後退してしまいます。 - アーティファクトの集約：常に変化するデータモデルやビジネスロジックに対する主な防御策は集約です。ほぼすべてのデータコード（つまりモデリング、セマンティックレイヤー、参照ドキュメント、標準化されたダッシュボード定義）は単一のリポジトリに収められ、層間整合性を保護する CI チェックが適用されています。モデリングの変更が下流のダッシュボードを破損させたり、文書化された指標を無効にしたりする場合、CI がそれを検知し、修正は同じ PR で展開されます（このメカニズムについては以下のスキルセクションで再考します）。 - メタデータを第一級製品として扱う：コーディングエージェントが良好な成果を出すのは、コードベースが可読性が高いことによる部分があります。README、型シグネチャ、ドキュストリングなどがそれです。データウェアハウスも同様に可読性にできるのですが、列やテーブルの説明、標準化された指標定義、粒度の文書化、有効値範囲、系譜、所有権、モデル階層化が変換処理自体と同じ厳格さで維持される場合に限り可能です。これは新しい洞察ではありませんが、優れたガバナンスはエージェントが適切なデータセットを選択するのを助ける重要なコンテキストを提供します。 ## 真実の源泉 データ基盤がデータウェアハウスそのものであるならば、真実のソース（sources of truth）とは、エージェントがそれをナビゲートする際に参照する基準面です。この層は概念とエンティティの曖昧さを解消し、ステークホルダーからの質問にある「週次アクティブユーザー」という表現を、データモデル内の特定の、管理されたエンティティへと変換します。信頼性の高い順に大まかに並べると以下のようになります： - セマンティックレイヤー：コンパイルされたメトリクスと次元の定義。質問が明確に定義されたメトリクスにマッピングされる場合、エージェントは関数を呼び出して 1 つの数値を取得します。これは社内他のすべての表面で生成される数値と同じものです。当社のエージェントはスキル指示により構造的にまずセマンティックレイヤーを活用することが義務付けられています（付録参照）。試みたが失敗したアイデアとして、LLM に生テーブルとクエリログからメトリクス定義を自動生成させることでセマンティックレイヤーをブートストラップするというものがありました。これは一見妥当に見える定義を生み出しましたが、排除しようとした曖昧さをそのままエンコードしており、評価ではより小さく人間がキュレーションしたレイヤーと比較してネガティブな結果となりました。したがって、ドキュメント生成には Claude を活用しつつ、定義の所有権は人間に持たせることを推奨します。 - 系譜と変換グラフ：セマンティックレイヤーでカバーできない質問の場合、系譜とテーブルランキング（参照数に基づく）により、エージェントがどのアップストリームモデルが概念を供給しているか、どのモデルが非推奨となっているか、どのモデルが同じ粒度を共有しているかを推論できるようになります。これにより「メトリクスがわからない」という状態から、「どの統制されたモデルから集計すべきか知っている」状態へと変換されます。また、これは以下で示すオンライン検証において鮮度と出所のシグナルを提示するバックボーンでもあります。 - クエリコーパス：ダッシュボード、ノートブック、過去の分析からの履歴 SQL。直感的には高価値であるはずです：すでに正しく回答されたすべての質問の記録だからです。しかし実際には、エージェントに数千件の過去クエリへの生レトリバルアクセスを与えるだけでは精度は 1 ポイント未満しか向上しませんでした（このアブレーションについては後述のセクションで詳しく解説します）。非構造化レトリバルでは、新しい質問を適切な先例にマッピングできませんでした。実際に機能するのは、そのコーパスをドメイン別の構造化参照ドキュメントおよびスキルで記述された再利用可能な分析パターンに要約することです。クエリ履歴はエージェントが直接読む真実の源ではなく、キュレーションのための原材料として扱うべきです。 - ビジネスコンテキスト：多くのチームが省略する層であり、私たちが最も長く過小評価していた部分です。ビジネスを理解していないエージェントは、ユーザーが何を尋ねたかには答えますが、何を意図しているかは答えません。「第 2 四半期のローンチ」が特定の製品を指すこと、2 つのチームが同じ用語を異なる定義で使っていること、あるいは木曜日に取締役会が開催されているため質問がなされていることを知りません。エージェントが周囲の参照を解決し、より良い確認質問を行うために、インデックス化されたドキュメント、ロードマップ、意思決定ログ、組織構造からなる企業知識グラフを取り込んでいます。 これら 4 つすべてに共通する失敗パターンは、データ基盤層からのものと同じです：**不十分または陳腐化したドキュメンテーション**。Claude はギャップを埋めるために非常に有用ですが（列の説明のドラフト作成、クエリパターンからのメトリクスドキュメントの提案、CI 内の未文書化モデルのフラグ付けなど）、キュレーションと所有権は人間が管理します。 次の 2 つのセクションでは、所有権を十分に低コスト化して実際に実現できるようにする方法について議論します。 ## スキル 真実の源泉がエージェントの「宣言的」知識（つまり、指標の意味）である場合、スキルは「手続的」知識です。すなわち、どのソースをどのような順序で参照するか、曖昧なデータをどのようにナビゲートするか、そして完成した分析がどのようなものかを示します。 Claude Code において [スキル](https://code.claude.com/docs/en/skills) は、エージェントが必要に応じて読み取るマークダウンのフォルダです。Anthropic で開発されたスキルは、極めて大きな付加価値をもたらします。スキルがない場合、Claude の分析質問に対する回答精度は、私たちの評価では 21% を超えることはありませんでした。スキルを追加することで、集計値では一貫して 95% 以上となり、特定のドメインでは定期的に 99% に達します。スキルの大半を作成するために使用する骨格については付録を参照してください。 いくつかのベストプラクティス： **ペアスキルを作成する**: ***知識*** スキルは、薄いトップレベルのルーティング機能として機能し、必要な場合に追加のドメイン詳細をオンデマンドで読み込みます。これは「まずセマンティック層を試すが、カバレッジがない場合は、このドメインに関連するテーブル、列、結合、および注意点を説明する約 30 の参照ファイルがある」と宣言します。このルーティング機能は、実質的に検索失敗に対する私たちの回答です。エージェントが百万フィールドの倉庫を検索させるのではなく、クエリが記述される前に空間を数十件の厳選されたファイルに絞り込みます。***アンブック*** スキルは、シニアアナリストが従うプロセスをエンコードしています：質問を明確にし、ソースを見つける（知識スキル経由）、クエリを実行し、結果を敵対的レビューサブエージェントに通してループします。また、リテンションカーブ、レート分解、ファネル分析など、12 の再利用可能な分析パターンをバンドルしており、一般的な要求が毎回再発明されることを防ぎます。 **適切な参照ドキュメントを作成する**: LLM による検索のために記述されたものです。私たちの参照ドキュメントは、テーブル（粒度、スコープ、除外事項）、注意点のメカニズム（例：「既知のフリーメールドメインを除外するが、anthropic.com などのカスタムドメインは保持する」）、および明確なルーティングトリガー（例：「質問が実験リフトに関する場合… 生のイベントカウントには使用しないこと」）を記述しています。これは古びてしまう指示付きレシピではなく、詳細については以下の参照ドキュメント作成に使用するスキャフォールドをご覧ください。 # [ドメイン] テーブル ## クイックリファレンス ### ビジネスコンテキスト — [このドメインが平語で何を意味するか] ### エンティティ粒度 — [1 行が何を表すか] ### 標準的な衛生フィルタ — [このドメインのすべてのクエリに適用されるフィルタ] ## 次元 - [主要な次元がどのように符号化され、同じ概念がテーブル間でどのように異なる名称で呼ばれているか] ## 主要テーブル ### [table_name] - **粒度**: [...] · **範囲/除外事項**: [...] - **使用法**: [いつ使用するべきか、いつ使用すべきでないか、結合キー、必須フィルタ] [... 管理対象の各テーブルにつき短いセクションを 1 つ ...] ## 注意点 - [シニアアナリストが警告する、誤った回答をもたらすモード] ## ベストプラクティス / 一般的なクエリパターン - [デフォルトの選択、標準的な切り口、正確なクエリ形式自体が難しい事例における既成のパターン] ## クロスリファレンス - [隣接する質問を所有する近傍ドキュメント]**スキルメンテナンスを第一級市民として扱う**: スキルドキュメントは毎日変化するデータモデルを記述しているため、積極的なメンテナンスを行わないと数週間で誤った情報となります。私たちは、ローンチ時のオフライン精度が約 95% から 1 ヶ月後には約 65% に低下するのを観察し、これをエンジニアリング上の問題として扱うまで待ってしまいました。その結果、スキル用のマークダウンファイルを変換モデルと同じリポジトリに配置することになりました。つまり、モデルを変更する PR（プルリクエスト）が、それに関するドキュメントを更新する PR と同じものになるようにしたのです。コードレビューフックにより、スキルファイルに触れていないレポート用モデルの変更をフラグとして検出します。現在、データモデル関連の PR の約 90% が、同じ差分内でスキルの更新を含んでいます。また、モデルが改善し以前の失敗モードがもはや適用されなくなった際にも、定期的にスキールドキュメントの骨格を整理・削除しています。 **すべての表面で一貫性がありシームレスな体験を提供する**: 同じスキルは、Slack 内、IDE 内、ダッシュボードツール内、スタンドアロンのエージェントセッション内のいずれの質問に対しても、同じ回答を提供*しなければなりません*。これを実現するために、単一の正真正銘の情報源（データリポジトリ）を確保し、スキルの更新を自動的に同期するようにしました。マージ時には、スキルはプラグインマーケットプレイス（IDE ユーザー向け）、クラウドストレージのブロブ（単一ファイルを読み取るホスト型アプリ向け）、および MCP を介して直接リソースとして提供されるように同期されます。また、ハードコードされたリポジトリパスや表面固有の名前空間を避けることで、最初から移植性を設計しました。 ## 検証 最後に、検証とは、3 つの故障モードのうちどれがまだ漏れ出しているかを特定する方法です。 ## オフライン評価 私たちがよく目にする共通のパターンは、データチームが分析エージェントの精度を理解するためのプロセスを持たずに、複雑な分析環境を構築してしまうことです。 このギャップを埋める一つの方法として、オフライン評価があります。これは単純な質問と回答のペアです。オフライン評価は、機械学習モデルのオフラインテストと同様に考えることができます。オンラインのエージェントのパフォーマンスを示すものではありませんが、重要なギャップが生じるかどうかについて良好な感覚を与えてくれます。 Anthropic では 2 種類のオフライン評価を展開しています。**ダッシュボードベースの評価**は、Claude によって自動生成され（その後人間による検証が行われ）、最も一般的なステークホルダーの質問をカバーします。**ロングテール評価**では、Claude にビジネスコンテキスト（ロードマップやテーブルドキュメント）を提供し、残りの領域全体にわたって妥当な質問を生成させます。また、スレッド上でステークホルダーがエージェントを修正するたびに、その修正内容を継続的に収集しています。この修正内容は候補となる評価データです。 その他のベストプラクティスには以下が含まれます： - 正解の基準を固定してドリフトを防ぐ：生データに対して作成された評価は、基盤となる数値が変化した瞬間に陳腐化します。すべての評価をスナップショット日付に固定するか、安定した事実テーブルに対して記述するか、またはエージェントの数値そのものではなく、エージェントのクエリをグラダーが判断するようにしてください。評価スイートを CI に接続し、依存関係に触れる PR が発生した際に影響を受ける評価を再実行できるようにします。 - 結果はテストログのようにではなく、テレメトリデータとして保存する：すべての実行結果は、スキルバージョン、Git SHA、モデル ID、各アサーションのパス/フェイル、トークン数、実行時間を記録したウェアハウステーブルに格納されます。「その変更は役立ったか？」という問いはクエリとなり、単一の CI 実行では検出できない緩やかな回帰を捉えるための時系列データが得られます。 - ドメインごとにリリースゲートを設ける：ドメインのオーナーは、評価セットの一部がある閾値（当初は約 90%）を満たすまで、ステークホルダーに対してエージェントを発表できません。これにより、ユーザーに失敗が見られる前に参照ドキュメントの修正が強制されます。 - 適切な数の評価を作成する：必要な評価数は、ビジネス領域の複雑さと基盤となるデータモデルの複雑さに依存します。オフライン精度がオンライン精度をどの程度予測できるかを追跡することで較正を行います。私たちは、トピックあたり数十件を超えると収穫逓減が見られること（例：「成長」）、そして新しいモデル世代ごとにその上限が低下することを発見しました。 - オフライン評価の精度は約 100% であるべきです；すべての正解回答は、セマンティックレイヤー（存在する場合）にもヒットしている必要があります。再度強調しますが、このレベルの精度はシステムが誤った回答を生成しないことを保証するものではなく、適切な評価カバレッジがあるという前提の下で、明白な欠落がないことを示すに過ぎません。 ## Ablation techniques スキルに関するすべての構造的決定（例えば、どのソースを公開するか、サブエージェントが待ち時間を獲得するかどうか、2 つのスキルを 1 つに統合するかどうか）は、オフライン評価セットを固定した状態で行われます。 我々は正確に 1 つのコンポーネントのみを変化させ、パス率を比較します。各実行には 1 時間しかかからず、多くの議論を置き換えることができます。重要なことは特定の単一の結果よりも、この方法論です： - null 結果を想定して設計する。最も有用だったアブレーション実験は、否定的な結果をもたらしたものでした。エージェントにダッシュボード、変換ロジック、アナリストノートブックの SQL（数千ファイル）への直接 grep アクセス権限を与えました。その後、各回答前に実際にそれらを読み込んだことをトランスクリプトで検証しました。精度はどちらの方向にも 1 ポイント未満しか変動しませんでした。次に明白な交絡因子を確認しました：間違えた質問に対して、答えが実際にはコーパスに含まれていたでしょうか？約 80% の場合、含まれていました。「答えが存在する」ことが「正解できるようになる」ことを予測できたでしょうか？いいえ、改善率は横ばいでした。情報はそこにあり、エージェントもそれを見ていたのに、それでも利用しませんでした。この単一の実験から、ボトルネックは過去の成果へのアクセスではなく、構造化（つまり、質問を適切なエンティティにマッピングすること）にあることが分かりました。この洞察が、数ヶ月にわたるロードマップの方向転換をもたらしました。 - PR 粒度でアブレーションを行う。意味のあるスキル修正のすべてについて、関連する評価スライスに対して実行前と実行後の両方のテストを行い、その差分を PR の記述に記載します。これにより、「ドキュメントを改善した」という主張が誠実なものに保たれ、意図は良いのに結果が悪化するという、意外にも頻繁に起こるケースを検出できます。 - 失敗した手法の短いリストを維持する。私たちの例として2つ挙げます：ある時点を超えてドキュメントの精緻化ラウンドを追加すること（3 回連続でネットネガティブな反復に陥り、ドキュメントは長くなるばかりで良くなりませんでした）、および遅延を削減するために敵対的レビューアーをより安価なモデルに置き換えること（精度向上のほとんどが失われ、実質的な速度向上も得られませんでした）。否定的な結果は記録するコストが安く、次の人が同じ実験を再実行することを防ぎます。 ## オンライン検証 最終ステップは、実際のオンラインシステムの性能を可能な限り正確に保証することです。私たちが実施する手順の一部には以下が含まれます： - 敵対的レビュー：Claude スキルを活用して、最終回答のすべての前提条件に積極的に異議を唱えることで、評価セット内での精度が 6% 向上することが判明しましたが、その代償としてトークン使用量が 32% 増加し、レイテンシが 72% 上昇しました。 - 出所フッター：すべての回答には、それがどのソース階層（セマンティックレイヤー › curated reference › raw table）から来たか、基盤となるデータの鮮度、およびモデルの所有者を示すフッターが付随します。これにより回答がより正確になるわけではありませんが、消費者が回答をどの程度信頼できるかを判断する助けになります。「raw table, freshness unknown」というフッターは、上位フローへ転送する前に検証すべきというシグナルであり、サイレント・フェイルures に対する数少ない緩和策の一つです。 - データ品質チェック：エージェントが適切なフィールドを正しい方法で使用していても、データ自体が誤っている可能性があります。参照されるフィールドが最新で、完全性があり、異常がないことを保証するための基本的なデータ品質チェックを追加することは、一般的な衛生管理として推奨されます。 - 受動的モニタリング：継続的に追跡している 2 つの生産環境シグナルは、セマンティックレイヤーを介して解決されたエージェントクエリの割合と、「そのテーブルが間違っています」「不正検出フィルターが抜けています」などの修正言語を使用した回答の割合です。これらは両方とも、オフラインパス率とともに週次でレビューされるダッシュボードにフィードされます。 - 能動的修正収集：これはループを閉じる部分です。スケジュールされたエージェントは数時間ごとにステークホルダーチャネルをスキャンし、類似の修正言語を検出し、関連する参照ドキュメントへの 1 行分の修正案を作成して、ドメイン所有者にタグ付けした PR を開きます。修正経路は意図的に退屈なものです（マークダウンファイルの編集、マージ、全場所での自動同期）ため、ドメイン所有者がタスクに時間をかけすぎないようにしています。同じ修正内容はオフライン評価セットにもフィードバックされます。 - これらの対策で完全に捕捉できない失敗モードは**サイレント**なものです。回答は誤りですが、もっともらしく見え、異議なく使用されてしまいます。私たちの緩和策は、出所フッターの提示、リーダーシップ関連事項に対する明示的な人間の承認、および各ドメインの主要 KPI に対する定例評価（毎日祝福されたダッシュボードと照合して健全性をチェック）ですが、まだ堅牢な解決策はありません。 ## はじめに ゼロから始める場合、いくつかの代表的なデータセットと数十件のオフライン評価、そして限定的な知識スキルがあれば、多くのメリットを享受できます。本記事でそれ以降に追加した内容は、これらが構築された後に実施したものです。 また、多くのベストプラクティスをご紹介しましたが、すべてのデータチームに適しているわけではありません。組織内でアプローチに影響を与えるいくつかの原則について合意形成を図るために、以下の問いを検討してください： - 今日と未来において、正解であることはどれほど重要でしょうか？AI モデルは急速に進化しています。現在では、モデルの欠陥を補うために多くのインフラを整備する企業をよく見かけますが、モデルが改善されればその必要性はなくなります。モデルがどこで不足しているかを知り、改善を待ってギャップを埋める方がオーバーヘッドは大幅に減りますが、これは貴社のリスク許容度に合致しない可能性があります。 - 将来にわたってビジネスの複雑性がどのように変化すると予想されますか？例えば、生成するデータ量が少なく、出力の利用者が数人だけである場合や、データモデルが今後とも単純なままであると見込まれる場合、前述のプロセスは過剰対応となるかもしれません。 - 出力の対象者はどの程度の技術的知識を持っているでしょうか？言い換えれば、誤答を検知できるデータサイエンティスト向けにこの分析システムを構築する場合は、基盤となるデータモデルに不慣れな対象者向けの場合と比較して、エラーに対してより寛容になれます。 - 精度向上のためにどれほどのコストを負担するつもりですか？敵対的検証（adversarial validation）のような特定のプロセスは精度を大幅に向上させることがありますが、その分、コストとレイテンシが高くなる傾向があります。 - アクセス制御や社内データプライバシーに対してどの程度の安心感を持っていますか？エージェントは利用可能なコンテキストが多ければ多いほどパフォーマンスが著しく向上しますが、広範なデータへのアクセス権限は、多くの企業のガバナンス方針に反します。これが、単一のエージェントを構築するか、複数のスコープ限定型エージェントを構築するかを決定づけます。 どのような道を選ばれたとしても、私たちが得た最大の成果は、3 つの失敗モードそれぞれに対処した結果です。すなわち、曖昧さを単一の管理された回答に集約すること、回答を容易に見つけられるようにすること、そしていずれかが陳腐化した際に警告を発することです。 この記事は、データサイエンスおよびデータエンジニアリングチームのメンバーである陳昌（Chen Chang）、クレメント・ペン（Clement Peng）、ジャスティン・レダー（Justin Leder）、ジョハンネ・ジアオ（Johanne Jiao）、そしてジョシュ・チェリー（Josh Cherry）によって執筆されました。著者らは、マイケル・セグナー（Michael Segner）氏の貢献に対し謝意を表します。 ## 付録 ## スキルファイルの骨子 以下は、主要なウェアハウススキルの骨格です。実際のファイル構造を示すものであり、内部の詳細部分は [角括弧で囲まれたプレースホルダー] に置き換えられています。これはそのままコピーして使用するものではなく、記述する価値のあるセクションの種類を示すためのものです。 --- name: [warehouse-skill] version: [x.y.z] description: "ユーザーが [企業名] のデータウェアハウスに対して [ビジネスドメインのリスト] に関する質問を問い合わせた場合 — このスキルを呼び出してください。[隣接するエンジニアリングタスク] や、データウェアハウスの要素を含まない質問については呼び出さないでください。" --- # [ウェアハウス] スキル指示書 ## 説明 安全かつ効果的な [ウェアハウス] クエリのための唯一の信頼できる情報源です。 クエリ実行のガイダンスのために、他のスキル（[リストされたもの]）から参照されます。 データアナリストとして行動し、戦略的洞察とデータ駆動型の推奨事項を提供しますが、その過程で指導を求めてください。 **範囲外の判断**: [製品領域など] → データのみを提示し、「判断は [担当チーム] の裁量です」と明記してください。立場を示したり、コードの修正を行ったりしないでください。 ## クエリの実行 優先順位: 1. **[管理された接続]** (利用可能な場合): [クエリツール] / [スキーマツール] 2. **[CLI フォールバック]** (インストールされている場合): [デフォルトプロジェクト、フォールバックプロジェクト] 3. **どちらも該当しない** — ユーザーに認証を求め、その後停止する --- # セマンティックレイヤー（必須の最初のステップ） ガバナンスされたセマンティックレイヤーは、すべてのデータ問い合わせに対する**必須のデフォルトパス**です。[BI ツール] と同じ数値が使用され、結合/粒度/フィルタリングが組み込まれています。以下の参照ドキュメントを介した生 SQL は**フォールバック**であり、セマンティックレイヤー経由のパスで要求を満たすことができない場合にのみ使用されます。 ## 必須ワークフロー 1. **読み込み** — [各ランタイムでのセマンティックレイヤーの読み込み方法とフォールバック手順] 2. **発見** — キーワードでメジャーやディメンションを検索する。**必ずセグメントを確認すること**（これは名前付きの正規化された人口フィルタであり、これらのための手動 WHERE 句が誤った回答の主要な原因となる） 3. **コンパイル + 実行** — 仕様を構築し、SQL にコンパイルして実行する 4. **フォールバック** — 発見で関連するメトリックが見つからない場合、またはコンパイルに失敗した場合のみ → `references/*.md` を介した生 SQL（以下の PART 3） > **早期に諦めないこと。** 次の理由で生 SQL にフォールバックしてはなりません: > - "[カスタム日付フィルタリング/コホート]" → [時間次元仕様によってカバー済み] > - "[結合が必要]" → [メトリックレイヤーはすでにその結合をカプセル化している] > - [3〜4 件の追加の、事前に反論されたエージェントがセマンティックレイヤーをスキップするために使用する言い訳] ### データウィンドウとタイムゾーン — クエリ実行前に決定する - **時点日付 vs 直近 N 日間**: [各項目ごとの規約] - **「先週/先月」**: 直近の 7 日分や 30 日分ではなく、直前の完全な暦上の一週間または一ヶ月を指す - **タイムゾーンデフォルト**: [TZ]; [特定の集計レポートについては例外あり] - **鮮度ラグ**: [一部の] テーブルは更新が遅れる傾向があるため、「昨日」ではなく MAX(date) に基づいてアンカーする --- # パート 1: 必須知識（すべてのリクエストで最初に読むこと） ## 🚀 クイックスタートワークフロー 1. **まずレッドフラグを確認**: [制限対象/個人識別情報 (PII) リクエスト、ゲートドメイン、追加検証が必要な高リスクの問い合わせ] 2. **スコープ外は推測せずエスカレート**: [アクセス権限リクエスト、パイプラインのトラブルシューティング、陳腐化したダッシュボード、根本原因の断定、製品/価格に関する推奨] → 担当チームへリダイレクトし、回答しない 3. **リクエストを明確化**: 対象期間、セグメント、その分析がどのビジネス判断に資するか 4. **既存ダッシュボードの確認**: [ドメイン別ダッシュボードカタログ] 5. **データソースの特定**: [以下のナビゲーションマップを参照; 管理された集計テーブルを優先] 6. **分析の実行**: [必須フィルタ + 敵対的レビュー] 7. **インサイトの提供**: 手法を示し、観察事実と解釈を明確に区別する ## 🏢 ビジネスコンテキスト ### エンティティの曖昧さ解消（必ず明確化すること） - **「[用語 A]」は以下を指す可能性がある**: [エンティティ 1] または [エンティティ 2] — どちらを指すか常に確認する - **「[用語 B]」は以下を指す可能性がある**: [エンティティ 1] → [エンティティ 2] → [エンティティ 3]（一つから多数への連鎖） - **「ユーザー」**: [正確なカウントに使用できる識別子はどれか、またどの識別子が数を水増しさせるか] ### ビジネス用語 - [現在の製品名と、データ層において凍結値として依然として表示される廃止された別名 — 記述には新名称を使用し、フィルタリングには旧名称を使用] - [主要な内部略語] - **[主要指標] の計算**: [月次 / デフォルト期間 / リーディングインディケーター] - **見慣れない用語** — [社内ドキュメント] で検索し、推測してはならない ### データ整合性要件 ⚠️ - **決して行わないこと**: データや列を捏造する; データが示す範囲を超えた推測的な主張を行う - **必ず行うこと**: 安全な除算を使用する; 観察結果（「データは X を示している」）と解釈（「これは Y を示唆している」）を区別する; 制限事項を明記する --- # パート 2: 実行時の手順（実行中に従うこと） ## 🔧 技術的実装ガイド - [管理接続ツールおよび CLI 呼び出しの詳細] - **PII の保護**: 制限対象データについては、ユーザー自身に実行させるための SQL を返す — 結果を直接返してはならない ## 📊 分析ベストプラクティスガイド 1. クエリを実行する前に問いを明確にする 2. 作業プロセスを示す（フィルタ、含める/除外する項目、データの鮮度など） 3. 分母を明確化する 4. サンプルバイアスを考慮する 5. ビジネスへの影響と結びつける 6. **敵対的 SQL レビュー（必須）** — 最終回答を出す前に、[sql-reviewer] サブエージェントを起動してすべてのクエリに対してレビューを行うこと。発見された問題点は修正し再レビューを受けること；自己認定は禁止する 7. **出典付きで報告する** — すべての回答の末尾には以下のフッターを追加すること: > **ソース:** [セマンティックレイヤー | 管理対象テーブル | ラウド探索] · > **信頼度:** [ティア] · **レビュー済み:** [レビュアー ✓, ラウンド N] · > **鮮度:** [データ内の最大日付] · **オーナー:** [所管チーム] --- # PART 3: データ参照・リソース ## 📚 ナレッジベースのナビゲーション ### [ドメイン A] → `references/[domain_a].md` - **用途**: [質問の種類] - **主要テーブル**: [...] - **ダッシュボード**: `references/[domain_a]_dashboards.json` ### [ドメイン B] → `references/[domain_b].md` - **用途**: [...] [... 各ビジネスドメインごとに 1 エントリ — 合計数十件 ...] ## ⚠️ トラブルシューティングガイド ### 情報が不足している場合 - [テーブルが見つからない / アクセス拒否 / 古いドキュメント / 不明な列挙値 → 対応方法] ### フィールド名に関する落とし穴 - `[field_x_v2]` を使用し、`[field_x]` は使用しないこと - [同様の名称を持つ 2 つのテーブルが異なる粒度で同じ指標を報告している場合 — どちらを使用すべきか] - [2 つの妥当なソースのうち、主要指標の標準となるのはどちらか] - [... さらに数多くの困難な経験から得られたワンライナー ...] 見つかった項目はありません。 ## クロードで組織の運用方法を変革する 開発者向けニュースレターを購読する 製品アップデート、チュートリアル、コミュニティ紹介など。毎月あなたのメールボックスにお届けします。 月次の開発者ニュースレターを受け取りたい場合は、メールアドレスをご入力ください。いつでも登録解除が可能です。 ありがとうございます！登録が完了しました。 申し訳ありませんが、送信に問題が発生しました。後ほど再度お試しください。

Anthropic が Claude を活用したセルフサービスデータ分析を可能にする方法

背景や根拠まで確認しますか？

調べる

選ぶ

サイト