AI

Snowflake CoCoとは?旧Cortex Codeからの改称・権限境界・課金の二重経路を実装目線で解説

Snowflake CoCo は、Snowflake のデータとメタデータに接地したコーディングエージェントです。2026年6月2日の Snowflake Summit 2026 で、前身の Cortex Code から現在の名称へ改称されました。名前が変わっただけの話に見えて、実装者が押さえるべき論点は権限境界とコストの two-path 構造にあります。

この記事では、CoCo の提供面ごとの提供状態、既定で全ユーザーに付いてしまうロール、そして CoCo 自身のクレジットとは別経路で発生する AI SQL のコストを、2026年7月時点の公開情報として整理します。導入を決める条件と見送る場面も、条件付きで言い切ります。

まとめ:CoCoの正体と、導入判断で先に決めるべき3点

  • 正体:CoCo は旧 Cortex Code の改称版で、スキーマ・権限・リネージを読んだうえで SQL、Python、dbt モデル、パイプラインを生成するデータ基盤特化のエージェントです。
  • 提供面:Snowsight、CLI、macOS/Windows のデスクトップアプリは一般提供、Agent SDK はプレビュー段階という整理が2026年7月時点の公式記載です。いずれもクロスリージョン推論の有効化が前提になります。
  • 権限:必要なデータベースロールは既定で PUBLIC に付与されており、何もしなければアカウント全員が使えます。絞り込みは明示的な revoke で行います。
  • コスト:CoCo の推論クレジットと、CoCo が生成した AI SQL の実行クレジットは計上経路が分かれます。日次上限パラメータは前者しか止めません。
  • 採用条件:Snowflake 内で完結する構築・運用・障害調査には入れる価値があります。逆に、アプリ側コードが主戦場のチームや、AI 関数のガードレールを敷けていない組織は先に統制を作るべきです。

Snowflake CoCoとは何か|Cortex Codeからの改称と製品の中身

CoCo(コーディング・コパイロットの略称として使われる愛称)は、Snowflake が提供する開発支援エージェントの現行名称です。前身の Cortex Code は2025年11月に公表され、2026年2月にターミナル向け CLI と Snowsight 統合が一般提供へ進みました。そこから約4か月後、2026年6月2日の Summit 2026 で CoCo へ改称され、同時に実行基盤の拡張が発表されています。

製品の性格は、汎用のコーディングエージェントとは出発点が違います。CoCo はコードを書き始める前に、対象アカウントのスキーマ定義、ロールベースアクセス制御の設定、テーブル間のリネージを参照します。つまり「このユーザーがどのデータに触れてよいか」を理解した状態から生成を始める設計です。

生成物の範囲は SQL に限りません。Python、dbt モデル、ワークフローの DAG、機械学習パイプラインまでを自然言語の指示から組み立て、実行前に計画を提示して人が承認する流れを取ります。組み込み済みの専門知識も広く、Dynamic Table、Snowpipe、Task 管理、セマンティックビュー、ウェアハウスのチューニング、権限まわりの障害切り分け、dbt 連携といった領域が60種類以上のスキルとして同社側で保守されています。

Cortex という基盤全体の中での位置づけを整理しておくと迷いません。基盤の機能一覧はCortex AI(Snowflake)とは?主要機能・導入メリット・読み方を解説にまとめており、本記事はその中の「開発体験」に相当する層を扱います。自然言語からの分析問い合わせを担う層はCortex Analystとは何か?基本概念と登場背景の解説が詳しく、CoCo は必要に応じてこうした機能へ処理を振り分けます。

提供面と提供状態|Snowsight・CLI・デスクトップ・SDKの現在地

CoCo は単一のアプリではなく、複数の入口から同じエージェントに触れる構成を取ります。2026年7月時点の公式ドキュメントおよび Summit 2026 の発表内容をもとに、提供面と状態を並べます。

提供面 状態(2026年7月時点) 実装上の要点
Snowsight 統合 一般提供 ブラウザで完結。トークン従量
CLI 一般提供 個人向け定額と法人向け従量
CoCo Desktop 一般提供 macOS と Windows のネイティブ
VS Code 拡張 提供 既存IDEの作業導線に同居
Claude Code 向けプラグイン 提供 Snowflake業務のみ委譲できる
Agent SDK プレビュー Python と TypeScript で構築
Cloud Agents Summit 2026 発表 長時間処理のサーバーレス実行
Automations Summit 2026 発表 定期実行やデータ到着で起動

この一覧で先に確認したいのは、商用アカウント(非 Gov・非 VPS)であること、そしてクロスリージョン推論が有効になっていることです。公式ドキュメントは可用性の条件としてこの2点を繰り返し挙げており、自社リージョンに存在しないモデルを呼ぶ経路がここで開きます。データの越境が社内規程に触れる組織では、導入検討の最初にここを潰す必要があります。

Cloud Agents と Automations は、対話の外側で処理を走らせる仕組みです。人が指示を出して待つ使い方から、スケジュールやデータ到着イベントで起動する運用へ広げる位置づけになります。エージェントをアプリケーションとして自分で組む場合は、Snowflake Cortex Agentsとは?CREATE AGENT・REST API・権限設定の実装手順で扱う CREATE AGENT と REST API のほうが直接の道具です。CoCo は「開発者が使うエージェント」、Cortex Agents は「自分が作るエージェント」と切り分けると設計を誤りません。

権限境界の設計|既定PUBLIC付与とRBACの効き方を実装で押さえる

実装者がまず確認すべきは、誰が CoCo を起動できるかです。公式ドキュメントによれば、利用には SNOWFLAKE.COPILOT_USER と、SNOWFLAKE.CORTEX_USER または SNOWFLAKE.CORTEX_AGENT_USER のいずれかが必要になります。そしてこれらは既定で PUBLIC ロールに付与されています。

結果として、管理者が何も設定しなければアカウントの全ユーザーが CoCo に到達できる状態が初期値です。検証環境ならともかく、本番アカウントで意図せず全開になっている構成は珍しくありません。利用者を絞る場合は、PUBLIC からの revoke と個別付与を先に済ませます。

-- 既定の全開状態を閉じる
REVOKE DATABASE ROLE SNOWFLAKE.CORTEX_USER FROM ROLE PUBLIC;

-- 使わせる範囲だけに付け直す
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE DATA_ENGINEER;
GRANT DATABASE ROLE SNOWFLAKE.COPILOT_USER TO ROLE DATA_ENGINEER;

次にデータ側の境界です。CoCo は実行しているユーザーのロールを超えられません。参照権限のないテーブルには到達せず、マスキングポリシーや行アクセスポリシーが効いた結果を見ることになります。ここは既存のガバナンス設計がそのまま効く部分で、CoCo のために別立ての仕組みを増やす必要はありません。

裏を返せば、既存の権限設計が粗いアカウントでは、その粗さがそのままエージェントの到達範囲になります。棚卸しの観点はSnowflake Horizonとは何か?基本的な概念と利点を紹介で扱うガバナンス機能と揃えると進めやすくなります。

セキュリティ面では、CLI にプロンプトインジェクションの脆弱性が見つかり、v1.0.25 系(2026年2月28日)で修正されたうえで同年3月16日に公開されたという経緯があります。エージェントが外部由来のテキストを読み込む以上、クライアントの版を追い続ける運用は前提条件になります。

CoCo導入の実装手順|有効化からロール設計と初週の運用設計まで

検証を始める前に、順序を間違えると後戻りが発生する工程がある点には注意が必要です。とくにロールの締め直しは、使い始めてからでは利用者への周知コストが跳ね上がります。次の順で進めると手戻りを抑えられます。

  1. 可用性の確認:契約エディションが商用アカウント(非 Gov・非 VPS)に該当するかを確認し、クロスリージョン推論の有効化がデータ所在の社内規程に反しないかを法務・情報システム部門と合意します。
  2. ロールの締め直し:既定の PUBLIC 付与を revoke し、検証に参加するロールへ個別付与します。ここを先に済ませることで、全社に開いたまま検証が始まる事故を防げます。
  3. 支出上限の設定:提供面ごとの日次クレジット上限パラメータを検証用の小さい値に設定します。使わせない面は 0 にしておけば経路自体を塞げます。
  4. 利用状況の観測点を用意:CoCo 側の利用状況ビューに加え、AI 関数の利用履歴ビューも同時に日次で見る仕組みを作ります。観測点が片方だけだと後述の見落としが起きます。
  5. 入口を1つに絞って検証:初週は Snowsight かデスクトップのどちらかに絞り、既存の運用課題を題材にします。パイプラインの新規作成より、権限エラーの切り分けや遅いクエリの調査のほうが効果を測りやすい題材です。
  6. 効果の測り方を決める:削減額ではなく、同じ作業の総所要時間で比べます。往復回数が減ったかどうかが、継続判断の材料になります。

検証題材の選び方には理由があります。CoCo の差が出るのは、スキーマ・権限・リネージという既存文脈を読んだうえで答える場面で、汎用エージェントが同じ精度を出しにくい領域だからです。逆に、ゼロからの新規実装は文脈が薄く、差が見えにくくなります。

クライアント側の版管理も初期に決めておきます。CLI やデスクトップは更新が続いており、脆弱性修正が版に紐づく以上、更新手順を運用に組み込んでおかないと後から追いつけません。

課金の二重経路|CoCoのクレジットとAI SQLコストが分かれる理由

CoCo の課金はトークン従量で、AI サービスのクレジットとして計上されます。ここまでは分かりやすいのですが、実務で効いてくるのは「CoCo の請求だけを見ていても捕捉できない支出」がある点です。

CoCo側の日次クレジット上限パラメータでは止まらない支出の範囲

管理者は CORTEX_CODE_DESKTOP_DAILY_EST_CREDIT_LIMIT_PER_USER や Snowsight 側の同種パラメータで、ユーザーあたりの日次上限を設定できます。値を 0 にすれば経路そのものを塞げます。ただしこの上限が抑えるのは、CoCo が推論に使うクレジットまでです。

CoCo が生成した SQL の中に AI_COMPLETE のような AI 関数が含まれていた場合、その実行分は別経路で計上されます。計上先は CORTEX_AI_FUNCTIONS_USAGE_HISTORY 側であり、CoCo 専用の利用状況ビューには現れません。サーバーレスの AI サービスはウェアハウス計算として扱われないため、リソースモニターの監視網からも外れます。

数十人規模のチームで月次予算を組んでいるとき、ひとりが分類処理を依頼して数百件の AI 関数呼び出しが走れば、翌朝に二桁パーセントの予算を消費している事態が起こり得ます。CoCo のダッシュボードは平常値のままなので、気づくのは請求側を突き合わせたときです。

統制のために先に決めるロール設計とAI Budgetの併用手順

短期の打ち手は権限側で締めることです。前章の revoke で SNOWFLAKE.CORTEX_USER を限定付与にすれば、AI 関数を実行できる主体自体が絞られます。中期では、2026年4月に一般提供へ進んだ AI Budget のカスタムアクションで月次上限としきい値到達時の自動処理を組みます。Summit 2026 ではユーザー単位のクォータやチーム別のコスト追跡も発表されており、粒度はさらに細かくなる見通しです。

コスト設計の考え方自体は、Snowflake 上で動く他のワークロードと共通です。ウェアハウスとサービス層で課金の見え方が変わる構造はStreamlit in Snowflakeとは?料金・課金体系と使い方を徹底解説で整理した論点と重なるため、併せて読むと自社の見積もり精度が上がります。SQL から呼ぶ ML 関数の課金感覚はSnowflake AutoMLとは|ML関数で予測・異常検知・分類をSQLだけで実装が参考になります。

Cursorなど汎用コーディングエージェントとの役割分担と採用条件

同社公表のベンチマークでは、分析データエンジニアリング向けの ADE-Bench で CoCo が72.1%、比較対象として挙げられた Claude Code と OpenAI Codex が65.1%という値が示されています。トークン消費が51%少なく、実行が8%速いという計測も併せて公開されました。いずれもベンダー自身の計測値である点は割り引いて読むべきですが、傾向としては「Snowflake 固有のタスクでは接地の差が出る」と解釈できます。

観点 CoCo が向く領域 汎用エージェントが向く領域
対象 Snowflake の構築と運用 アプリ本体のコード
文脈 スキーマ・権限・リネージ リポジトリ全体の構造
強み 権限障害やクエリの調査 言語横断のリファクタ
弱み Snowflake 外の文脈が薄い データ基盤の内部事情に疎い
課金 トークン従量と AI 関数 ツール側の契約に準拠

実務では二者択一にせず、ターミナルのタブを分けて併用する運用が現実的です。Claude Code 向けプラグインが提供されているため、Snowflake に閉じたタスクだけを CoCo へ渡す構成も取れます。

ここから判断を言い切ります。採用すべき条件は3つです。第一に、Snowflake がデータ基盤の中心にあり、パイプライン構築や権限まわりの障害調査に週次で時間を取られていること。第二に、クロスリージョン推論を有効にしてもデータ所在の要件に抵触しないこと。第三に、AI 関数のクレジットを追跡する仕組み、つまり利用状況ビューの定点観測か AI Budget のいずれかを先に用意できることです。この3点が揃うなら、往復回数の削減で投じたクレジットは回収できる見込みが立ちます。

見送るべき場面も明確です。主戦場が Snowflake 外のアプリケーション実装であるチームでは、接地の利点が効かず汎用エージェントの守備範囲と重なります。ソブリン要件やクロスリージョン推論の制約で可用性の前提を満たせないアカウントも対象外です。そして、権限が PUBLIC 全開のまま運用されている組織は、導入より先にロール設計の棚卸しを済ませるべきで、順序を逆にすると統制不能な支出とデータ到達範囲を同時に抱え込みます。

基盤側の年次発表の流れを踏まえて計画を立てたい場合は、Snowflake Summitの概要と注目ポイント総まとめが発表サイクルの型を掴む助けになります。大量件数の処理を前提とした設計判断は数千件規模の検索を一括処理する仕組みの全体像と基本設計で扱っています。

自社のデータ基盤に合わせてエージェントの権限設計やコスト統制まで含めて組み立てるなら、生成AI開発・AI受託開発で要件定義から実装までを引き受けています。

よくある質問

CoCo と Cortex Code は別の製品ですか?

同一の製品です。2026年6月2日の Snowflake Summit 2026 で Cortex Code から Snowflake CoCo へ改称されました。公式ドキュメントの URL や一部の設定パラメータ名には現在も cortex_code の表記が残っているため、設定値を探すときは旧名で検索したほうが早い場面があります。

導入にあたって追加のロール付与は必要ですか?

既定では不要です。必要なデータベースロールが PUBLIC に付与済みのため、アカウントのユーザーはそのまま利用できます。むしろ運用上の作業は逆方向で、使わせる範囲を絞るために PUBLIC から revoke して個別に付け直す設計が現実的な出発点になります。

CoCo は権限のないデータを勝手に読みますか?

読みません。実行しているユーザーのロールに従うため、参照権限のないテーブルへは到達せず、マスキングポリシーや行アクセスポリシーも通常どおり効きます。ただし既存の権限設計が粗ければ、その範囲がそのままエージェントの到達範囲になる点は意識してください。

日次のクレジット上限を設定すれば費用は固定できますか?

固定はできません。上限パラメータが抑えるのは CoCo の推論クレジットで、生成された SQL に含まれる AI 関数の実行分は別経路で計上されます。費用を面で押さえるには、AI 関数を実行できるロールの限定と AI Budget の併用が要ります。

オンプレミスや政府向けアカウントでも使えますか?

2026年7月時点の公式記載では、商用アカウント(非 Gov・非 VPS)でクロスリージョン推論が有効であることが可用性の条件です。ソブリンアカウントについては提供面ごとに条件が異なるため、契約中のエディションとリージョンで個別に確認する必要があります。

関連記事

資料請求

RELATED POSTS 関連記事