Hex、repository を agent context として接続可能に

Hex は 2026年5月14日の changelog で、repository を agent context として接続できるようにしたと発表しました。warehouse のテーブルだけでなく、dbt model、変換ロジック、アプリ計測コードを agent が参照できるようにする更新です。

要点

• Hex workspace に one or many repos を接続し、agent が回答時に参照できる
• dbt model、transformation logic、product event instrumentation など、warehouse外の文脈を補える
• 管理者は API 経由で repo を接続でき、agent は retrieval steps を Threads に表示する
• AI分析の品質を上げるには、データそのものだけでなくデータが作られたロジックも重要になる

今回のリリースノートで語られていること

この更新は、AI analytics における context の範囲を広げるものです。分析agentにwarehouseのテーブルやsemantic modelだけを渡しても、なぜそのテーブルがそう作られているのか、どのイベントがどの画面で発火しているのか、どのdbt modelが上流にあるのかまでは十分に分かりません。Hex は、repository を agent context として接続することで、dbt models、transformation logic、app instrumentation など、データの意味を形作るコード側の情報を参照できるようにしています。

これは、AIがSQLを書く、グラフを作る、ダッシュボードを説明するだけでなく、「そのデータがどこから来たのか」「どのロジックで作られたのか」「イベントの意味は何か」を踏まえて回答するための土台です。データチームにとっては、これまで人間がコードリポジトリ、dbt docs、warehouse、BI定義を横断して確認していた作業の一部を、agent が支援できる可能性があります。

一方で、repository を context に入れることは、便利さと同時にガバナンスの論点も増やします。agent が参照できる repo の範囲、秘密情報やcredentialの除外、branchやcommitの鮮度、private repoへのアクセス権、回答時にどのファイルを根拠にしたかの表示が重要です。Hex が retrieval steps を Threads に表示すると説明している点は、AIの回答を後から検証するうえで意味があります。分析結果の信頼性は、答えの自然さではなく、どの文脈を根拠にしたかで判断する必要があります。

対象になりそうなチーム

• Hex をAI分析やself-service analyticsの基盤として使う data team
• dbt、product analytics、event tracking、warehouseを横断して分析するチーム
• agent が参照するコード・データ文脈の権限と監査を管理する platform team

実務で確認したいポイント

1. agent に接続する repo、branch、directory、file type の範囲を決める
2. secrets、credentials、customer data が context に入らないよう除外ルールを確認する
3. repo更新の反映タイミングと last-updated timestamp を運用に組み込む
4. Threads の retrieval steps を使って、回答根拠をレビューできるか確認する

結局、この更新をどう見るべきか

repository context は、AI分析を「データを見る」だけから「データが作られた理由も読む」方向へ進める更新です。Hexを使うチームでは、agentに見せるコード文脈を整備することが、回答品質とガバナンスの両方に効いてきます。