Snowflakeが、AIエージェントをスケジュール実行する「CoCo automations」を公開プレビューとして公開しました。プロンプトを1本登録しておくと、端末やブラウザを閉じていてもSnowflake側のサンドボックスで定期的にエージェントが動きます。CLIとSnowsightのどちらから作っても同じオブジェクトとして扱われ、AWS・Azure・Google Cloudの商用リージョンで利用できます。

登録するのはプロンプト1本

automationsの考え方はシンプルで、実行したい内容を自然文で書いたプロンプトと、動かす頻度を指定するだけです。毎回の実行はCortexのスレッドとして残り、エージェントがどんなメッセージをやり取りし、どのツールを呼び、最終的に何を返したのかを後から開いて確認できます。

Snowflakeが想定している使い道として挙がっているのは、日次の実績サマリー生成、指標の異常検知、ウェアハウスの使用量とコストの監視、データの鮮度チェック、データ品質やリポジトリ整備の定期作業、接続済みのMCPサーバーから定期ダイジェストを作る、といったあたりです。人が毎朝ダッシュボードを眺めて気付いていた種類の仕事が、そのまま対象になります。

Snowsightからは、テンプレートを選ぶか白紙から作るかを選び、タイトルと指示文、モデル、頻度と曜日、時刻、タイムゾーンを設定します。チャット上で「平日の朝9時に前日のパイプライン障害を確認して短くまとめて」と頼む形でも作成できます。CLIなら次のように書きます。

cortex automation create \
  --name pipeline_health \
  --prompt "Check pipeline failures from the last hour and summarize the likely causes." \
  --schedule "every 60 minutes"

スケジュールは「every 4 hours」のような間隔指定のほか、「daily at 9am」「every Tuesday at 1:15pm」といった書き方に対応します。曜日と時刻を複数並べた場合、内部では複数のタスクが作られることがあります。

動く場所はSnowflakeが用意したサンドボックス

作成したautomationは、個人データベース配下にAGENT TASKとして保存されます。スケジュールが発火すると、Snowflakeは保存済みのプロンプトを作成者として実行し、管理されたサンドボックスの中で作業ディレクトリを用意してCoCoを起動します。ウェアハウスは不要で、タスクの状態や所要時間、クエリID、エラーは実行履歴に記録されます。

CLIから作った場合は、ユーザーのワークスペースステージが作業ディレクトリにマウントされるため、そこへ書いたファイルは次回以降の実行にも残ります。別のステージを指定することも、マウント自体をやめて毎回使い捨てにすることもできます。

権限は「作った人」に紐づく

運用面でいちばん注意が要るのはここです。automationは作成者の権限で動く方式で、実行時にはその人のデフォルトロールとデフォルトのセカンダリロールが有効になります。作成したときにCoCoのセッションで使っていたロールは記録されません。対話的に試したときは通ったのに、スケジュール実行では権限不足で落ちる、あるいは中途半端な結果を返す、という食い違いが起こり得ます。

さらに、automationを使うために必要なEXECUTE AGENT TASK権限は、初期状態でPUBLICロールに付与されています。管理者が何もしなければ、アカウント内の全ユーザーがスケジュール実行を作れる状態です。対象を絞りたい場合は、いったんPUBLICから剥がしてから必要なロールに付け直します。

REVOKE EXECUTE AGENT TASK ON ACCOUNT FROM ROLE PUBLIC;
GRANT EXECUTE AGENT TASK ON ACCOUNT TO ROLE automation_user;

無人実行なので、対話時に出るツール実行の確認プロンプトは無効になります。実行に渡っているツールは承認を待たずに動く前提で、破壊的な操作や取り消しの効かない操作をスケジュールに載せるのは避けるべきだとSnowflakeも明記しています。デフォルトのセカンダリロールが「その人に付与された全ロール」になっていると、届く範囲がかなり広くなる点も頭に入れておきたいところです。

フックの失敗は成功として記録される

各実行の前後には、bashコマンドをフックとして挟めます。エージェントのターンを消費せず毎回同じ処理を行うので、リポジトリのクローンや後片付けのような固定作業に向いています。

ただし挙動には癖があります。フックが異常終了しても実行そのものは失敗扱いになりません。事前フックが失敗するとサンドボックスが使えないまま残り、エージェントは起動して「作業できない」と報告する応答を返しますが、タスク履歴上は成功と記録されます。事後フックでgit pushして結果を公開している構成なら、成果物が失われたまま成功と表示されることになります。マウントしたステージが既存ファイルへの追記に対応していないため、Gitのログ追記でつまずく点も注意が必要で、コミットが要る処理はマウント外の場所にクローンする運用が推奨されています。タスクの状態だけを見て安心せず、スレッドの記録を開いて確かめる必要があります。

プレビュー段階の制限

現時点で指定できる最短の実行間隔は1時間に1回です。CLIのパーサーはそれより短い指定も受け付けますが、プレビューでは対応外とされています。スレッドと実行履歴の保持期間は2カ月で、トリガーは時刻ベースのみ、イベント起動には対応していません。実行中のセッションに割り込んで対話を続けることもできず、確認は履歴とスレッドの読み取りに限られます。政府・FedRAMP・DoD・VPS・中国向けの各デプロイメントでは提供されません。料金は、プレビュー期間中も通常のタスク課金に加えて実行ごとのトークン消費がかかります。

まとめ

CoCo automationsは、対話しながら使うエージェントを、決まった時刻に勝手に動く仕組みへ移す機能です。データ基盤の中で完結し、実行内容がスレッドとして残る点は運用しやすい設計に見えます。一方で、権限が作成者のデフォルトロールに紐づくこと、EXECUTE AGENT TASKが初期状態でPUBLICに付いていること、フックが失敗しても成功と記録されることは、そのまま本番に載せる前に確認しておきたい項目です。無人で動くものほど、最初の1回を手で走らせて記録を読む手間が効いてきます。