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

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

要点

• Hex ワークスペース に one or many repos を接続し、エージェント が回答時に参照できる
• dbt モデル、transformation logic、product event instrumentation など、ウェアハウス外の文脈を補える
• 管理者は API 経由で リポジトリ を接続でき、エージェント は 検索 steps を Threads に表示する
• AI分析の品質を上げるには、データそのものだけでなくデータが作られたロジックも重要になる

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

この更新は、AI analytics における context の範囲を広げるものです。分析エージェントにウェアハウスのテーブルやセマンティックモデルだけを渡しても、なぜそのテーブルがそう作られているのか、どのイベントがどの画面で発火しているのか、どのdbt モデルが上流にあるのかまでは十分に分かりません。Hex は、リポジトリ を エージェント context として接続することで、dbt モデル、transformation logic、アプリ instrumentation など、データの意味を形作るコード側の情報を参照できるようにしています。

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

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

対象になりそうなチーム

• Hex をAI分析やself-サービス analyticsの基盤として使う data team
• dbt、product analytics、event tracking、ウェアハウスを横断して分析するチーム
• エージェント が参照するコード・データ文脈の権限と監査を管理する platform team

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

1. エージェント に接続する リポジトリ、branch、directory、ファイル type の範囲を決める
2. secrets、認証情報、顧客 data が context に入らないよう除外ルールを確認する
3. リポジトリ更新の反映タイミングと last-updated timestamp を運用に組み込む
4. Threads の 検索 steps を使って、回答根拠をレビューできるか確認する

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

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