Ramp・Underdog・Hoverに学ぶAI分析の文脈管理

Hexは、Ramp、Underdog、Hoverが既存のdbt、文書、コード、分析成果物をAIエージェントの文脈として整備する方法を紹介しました。

要点

• 完璧な意味層を先に作るのではなく、既にある文書やモデルから始めます。
• 実際の質問で不足した文脈をContext Studioから見つけ、元の管理場所へ修正を戻します。
• 業務部門の知識とデータチームの品質基準を、変更履歴のある文書でつなぎます。

今回のブログ記事で語られていること

記事の主張は、AI分析の正確性をモデルだけで解決せず、新人分析者へ教えるのと同じ指標定義、業務用語、表の関係、信頼できる資産をエージェントへ渡すことです。三社とも、文脈を新しく一から作るのではなく、dbt、Notion、Slack、問い合わせ、コード、既存ダッシュボードに散らばる知識を有効化し、実際の利用から不足箇所を更新しています。

Rampは、dbtのモデル説明と、領域ごとの概念・主要指標・関係する表を記したMarkdown文書を使います。GitHub Actionで変更のたびにHexへ同期し、信頼度の高いモデルにはdbt側で推奨印を付け、API経由でHexにも反映します。Context Studioで質問と失敗箇所を確認し、提案された修正をdbtの管理場所へ戻します。これにより、製品マーケティング担当が公開後の報告画面を作ったり、リスク担当がSlackから質問したりできます。

Underdogは、分析者の問い合わせ、Slackで繰り返される質問、Notionの文書、倉庫のモデルを棚卸しし、dbtリポジトリ内の文書へ集約しました。コード自体も参照リポジトリとして読み取り、指標、結合、列説明はdbtの意味モデルを通じて渡します。毎週の会話をContext Studioで分類し、提案をHex CLIで取得し、Claudeがリポジトリを参照して修正案のプルリクエストを作り、人が通常のコード変更と同じように確認します。

Hoverは、全指標を先に定義するのではなく、主要な表・列と関係を説明するところから始めました。利用の多い部門を優先し、業務責任者がGoogleドキュメントなどから知識を提供し、レビュー後にHexへ同期します。Hexで承認されたアプリやダッシュボードも文脈になり、検証済みの計算を再利用できます。三社に共通するのは、利用開始を完全な文書整備まで待たず、失敗を更新の優先順位へ変える点です。

今回のブログ記事が関係する人

会話型分析を導入するデータチーム、dbtや意味モデルの管理者、指標定義を持つ業務部門の責任者に関係します。

結局、今回のブログ記事をどう読むべきか

AI分析の文脈を一度作って終える資料ではなく、質問、警告、修正、レビューを循環させる運用品質として扱う記事です。まず信頼する表と主要指標を明示し、誤答を元の管理場所へ戻す流れを作ることが重要です。