アーキテクチャ

ウェアハウスがエージェント制御面を獲得する:Snowflakeのthinking_effort、stage_mountsとdbtのAgents Schema

著者：IdeaBosque最終更新：2026年10月29日

2026年10月28日、Snowflake は Cortex Agents の agent:run API に3つの新しい制御 —— thinking_effort、instructions.system、stage_mounts —— を出荷しました(Snowflake リリースノート)。新しいウェアハウスランタイムが、従来エージェントプラットフォームが自分の手元に置いておいた3つのもの —— モデルがどれだけ深く考えるか、ランタイムがどのハウスルールを強制するか、エージェントがどのバージョン付き成果物をマウントできるか —— をさらけ出します。同じ月、Fivetran と dbt Labs は「信頼できるAIエージェントのためのデータインフラを生み出す」ための合併を完了し、合併後のプラットフォームは Agents Schema を通じて、エージェントにアドホックな抽出ではなくウェアハウスネイティブなコンテキストを与えます(Fivetran プレスリリース)。

本稿では、3つの Snowflake 制御面と、その隣に到着したコンテキスト層、そして閉じられない境界 —— 承認、ツール横断のポリシー、監査ログはウェアハウスの上のオーケストレーション層に属し続けること —— を整理します。1つの Snowflake アカウント、2人の dbt 開発者、スケジュール実行を始めたエージェントというリーンチームにとって、これはウェアハウスの中で最初に自分の手で設定できるノブであり、何を束縛し何を束縛しないかを見分けることが、ガバナンスと建付けの違いを生みます。

ポイント

Snowflake は 2026年10月28日、3つのエージェント制御を出荷 —— thinking_effort(minimal から xhigh、モデルごとの値のサブセット)、instructions.system(ランタイム内にシステム指示を追加)、stage_mounts(バージョン付きステージマウント)が、Cortex の agent:run API に加わりました(Snowflake リリースノート)。
stage_mounts は成果物をブランチではなくバージョンで束縛します —— ノートブック、Streamlit アプリ、ワークスペース、エージェント自体がバージョン付きステージとしてマウントされ、書き込み可能な workspace_mounts はバージョン live のまま変わりません(Snowflake リリースノート)。
dbt と Fivetran の合併完了が Agents Schema を出荷 —— 合併プラットフォームの掲げる目的は「信頼できるAIエージェントのためのデータインフラ」であり、ガバナンスされたコンテキスト行を、エージェントがそれを消費する場所に置きます(Fivetran プレスリリース)。
dbt × Amazon Redshift のデータ共有(dbt が10月9日、AWS がビッグデータブログで文書化)は、1バイトも動かさずにマルチクラスターパイプラインを実現します —— ガバナンスされた共有と SVV_* メタデータ API と datasharing 設定が、抽出してからコピーする方式を置き換えます(dbt ブログ;AWS ビッグデータブログ)。
ノブが束縛するのは、推論の深さ・指示・マウント —— ポリシーではありません —— ウェアハウス、NetSuite、HubSpot、そしてエージェントの手が届くその他のシステムにわたる承認、取り消し、監査は、オーケストレーション層に留まります。

10月28日に何が出荷され、各制御はどこに位置するか

thinking_effort は推論の深さのノブです。minimal から xhigh までの範囲に、特定のモデルが受け付ける値を制約するモデルごとのサブセットが付きます。実務上、これはモデルの労力を API 側デフォルトから、ウェアハウスが実行ごとに記録する実行単位の設定へ移す呼び出しです。鮮度テーブルを読むスケジュール実行のエージェントに、請求明細を突き合わせるエージェントと同じ労力予算は必要ありません。10月28日まではその区別がモデルを呼び出すハーネス側に住んでいましたが、今は実行の宣言済みパラメータとしてウェアハウスが実行します。

instructions.system は、ランタイム内にシステム指示を追加します。これはハウスポリシーのスロットです。すべてのエージェント実行に付けておきたい組織のルール —— 何を要約してよいか、何を人間にフラグすべきか、欠けているコンテキストをどう扱うべきか —— は、エージェントを作った人のプロンプトテンプレートの中に置きっぱなしにするのではなく、呼び出しとともに移動します。ここは正直に言っておくべき点です:追加された指示はパーミッションシステムではありません。ランタイム内の振る舞いを形作りますが、何も剥奪しません。

stage_mounts が成果物の境界です。agent:run API はバージョン付きステージマウント —— ノートブック、Streamlit アプリ、ワークスペース、そしてエージェント自体 —— を受け付けるようになり、書き込み可能な workspace_mounts はバージョン live のままです。バージョン付きステージに束縛されたエージェントが見るのは、ブランチ上の今この瞬間ではなく、ピン留めされた成果物の集合です。これは、パイプラインピンニングやマニフェストピンニングといったエージェントスタックの別の場所にあるのと同じ直感が、成果物が実際に存在するウェアハウス境界で表現されたものです。

下の図は、3つの制御面を、その上下の層 —— 上ではポリシーが留まるオーケストレーション層、下では到着しつつあるコンテキスト層とデータ移動層 —— と対置して示したものです。

コンテキスト層が先に到着していた

制御は比較対象があってこそ意味を持ちますが、その比較対象は先にコンテキスト側に到着していました。Fivetran と dbt Labs は合併の完了とともに明確なテーゼを掲げました。合併後の会社の存在目的は「信頼できるAIエージェントのためのデータインフラを生み出すこと」です(Fivetran プレスリリース)。Agents Schema はこのテーゼをウェアハウスに持ち込みます。SQL エンドポイントに手探りで向かってエージェントが組み立てるアドホックな抽出ではなく、ダッシュボードがメトリクステーブルを消費するのと同じ感覚で、エージェントが消費できるガバナンスされた、モデル化された行です。

データ移動の問いも同じ扱いを受けました。dbt は Amazon Redshift のデータ共有をサポートし、AWS のビッグデータブログがマルチクラスターパターンを文書化しています —— SVV_* メタデータ API と datasharing 設定により、1バイトもコピーせずにマルチクラスターパイプラインを構築します(dbt ブログ;AWS ビッグデータブログ)。エージェントにとって、環境がガバナンスされた共有 —— lineage とアクセスルールが保持される場所 —— から組み立てられることと、抽出 —— どのコピーも新しいアクセスの問題 —— から組み立てられることの違いです。Dagster が同じテーゼをめぐって自らを再評価する(「Data your team trusts. AI that runs on it.」)のは、フェンスのオーケストレーター側から同じことを言っています(Dagster)。

3つの面を並べて読むと、1つのパターンが立ち上がります。コンテキストはモデル化される場所でガバナンスされ、移動は共有される場所でガバナンスされ、推論の深さ・指示・マウントは実行が起きる場所でガバナンスされる。これは、エージェントプラットフォームがこれまで各自の専用コードで答えてきた問いに対する、ウェアハウスファーストの答えです。

ノブが閉じないままにしているもの

制御が束縛しないのは、システム横断のポリシーです。ウェアハウスの価格モデルを読み、BigCommerce の在庫を確認し、承認済みの見積を NetSuite に書き戻すエージェントは、3つのベンダー境界と1つのプロトコル境界を越えます。Snowflake のパラメータがガバナンスするのは、そのうちのちょうど1つの境界だけです。リリースノートのどこにも BigCommerce のトークンを剥奪するものはなく、instructions.system が NetSuite 内に監査レコードを生むこともありません。承認、取り消し、そして1本のツール横断監査ログは、オーケストレーション層 —— 各システムを、それぞれ固有の認証とロギングを持つ型付きツールとしてラップするモジュールパターン —— に住まねばなりません(MCP モジュールコード標準)。

率直に言っておくべき誠実な限界があります。リリースノートが文書化しているのはパラメータであって保証ではありません。agent:run 呼び出しの監査挙動 —— 何が記録され、何が保持され、何がクエリ可能か —— は、私たちが確認したノートでは規定されておらず、モデルごとのサブセットサポートは、あるチームの xhigh が別のチームには利用不可の設定であることを意味します。3つの制御を宣言済み入力として扱い、自分のアカウントで監査ログを検証し、キルスイッチをウェアハウスの上に置いてください(AI ガバナンスチェックリスト)。

リーンチームの読み方

ウェアハウスに対する最初のスケジュール実行エージェントを動かし始めた中堅市場のチームにとって、10月28日は立ち上げの対話を5つの点で変えます。どのエージェントがウェアハウスに触れているか棚卸しする —— スケジュール実行のものから。thinking_effort をワークロードごとに意識的に設定する。鮮度チェックは minimal、突き合わせはより高い深さで、どのタスクがどの予算を得たかを記録する —— この対応表こそが、あなたの単位コストのストーリーです。ハウスポリシーは instructions.system に一度入れておき、プロンプトテンプレートごとにバラバラに管理するのをやめる。スケジュール実行のエージェントはバージョン付きステージマウントに束縛して、エージェントが読む Streamlit ダッシュボードが、誰かがテストしたあのバージョンであることを確約する —— 今朝変わってしまったバージョンではなく。そして承認と取り消しはオーケストレーターのマニフェストに留める。ウェアハウスが制御するのは実行がどう見えるか、オーケストレーターが制御するのは実行に何が許され、何を残すかです。