ネットワークポリシーは、Treasure AI Studio のエージェントがサンドボックスからどの外部ドメインに到達できるかを決める、アカウント単位のルールセットです。サンドボックスから出るリクエスト（Treasure Data CDP への tdx 呼び出し、git clone、パッケージのインストール、大半のコネクタのリクエスト）は、プラットフォームの外へ出る前にポリシーで評価され、ブロックされたリクエストが宛先に届くことはありません。エージェントのアクティビティをレビュー済みの宛先に限定する必要がある場合、またはスキルやコネクタが必要とするホストがまだ許可されていないために失敗する場合に設定します。
「すべて」ではなく「大半」なのは、境界がサンドボックスだからです。サンドボックスの外でリクエストを実行するコネクタは、このポリシーの管理対象になりません。ポリシーの管理対象外となるコネクタを参照してください。
Treasure AI Studio のエージェントが外向き通信を送信できる範囲を統制する、順序付きの egress ルールを確認・編集し、どのルールにも一致しないリクエストの扱いを選択します。
- Treasure AI Studio にサインイン済み（はじめに）
- アカウント管理者ロール（一般ユーザーはネットワークポリシーを閲覧・変更できません）
- 組織のスキルとコネクタが到達する必要のある外部ホストのリスト
Treasure AI Studio はネットワークポリシーを順序付きの「最初に一致したものを採用する」ルールリストとして評価し、一致がなければデフォルトアクションにフォールバックします。エージェントのサンドボックスからの各外向きリクエストについて、次のように処理します。
- ルールをリストの上から順に確認します。
- リクエストのホストにドメインパターンが一致した最初のルールが結果（許可またはブロック）を決定します。それ以降のルールは参照されません。
- どのルールにも一致しない場合、一致しないリクエスト向けのデフォルトアクションが適用されます。
最初に一致したものが採用されるため、ルールの順序には意味があります。範囲の広い許可を狭いブロックより上に置くと、そのブロックには到達しません。より限定的なルールを先に配置してください。
ネットワークポリシーは、エージェントのサンドボックスの外側にあるプラットフォームのネットワーク境界で Treasure AI Studio が適用します。エージェントはポリシーを読み取ることも、無効化することも、迂回することもできません。プロンプトの内容やカスタムスキルが自らに例外を与えることもできません。
各ルールは 1 つのドメインパターンで一致判定を行います。次の 2 つの形式を使用できます。
| パターン | 一致する対象 |
|---|---|
example.com | そのホストのみ。サブドメインには一致しません。 |
*.example.com | example.com 配下の任意のホスト。a.b.example.com のような多段のサブドメインも含みます。ホスト単体の example.com には一致しません。 |
パターンは小文字で保存され、エディタは通常のホスト名または先頭に *. を 1 つ付けた形式以外を受け付けません。それ以外の位置のワイルドカード、IP レンジ、ポート、URL パスはサポートされていません。ネットワークポリシーはホスト名のみで一致判定を行います。
*.github.com は api.github.com や raw.github.com を許可しますが、github.com 自体は許可しません。ホスト単体に接続する操作（git clone https://github.com/... やマーケットプレイスの登録など）には、github.com 用のルールが別途必要です。デフォルトのルールセットが両方のエントリを含んでいるのはこのためです。
Treasure AI Studio のすべてのアカウントは、デフォルトアクションがブロックに設定された状態で始まり、製品自体が必要とするホストを網羅した許可リストがあらかじめ登録されています。Treasure AI と Treasure Data CDP のエンドポイント、GitHub（スキルとプラグインマーケットプレイス用）、そしてサンドボックスがインストールに使用する Debian、npm、Node.js、PyPI、Bun のパッケージレジストリです。
つまり新規アカウントは、動作可能な最小限の許可を伴うデフォルトブロックです。エージェントは tdx を実行し、スキルを読み込み、パッケージをインストールできますが、それ以外は管理者が許可するまでブロックされます。あらかじめ登録されたルールも、他のルールと同様に削除や並べ替えができます。
あらかじめ登録されたルールは飾りではありません。Treasure AI または Treasure Data CDP のエントリを削除するとエージェントは CDP へのクエリを実行できなくなり、GitHub のエントリを削除するとスキルとプラグインマーケットプレイスが読み込めなくなり、パッケージレジストリのエントリを削除するとスキルが必要とするライブラリをエージェントがインストールできなくなります。登録済みルールを削除するのは、それが支えている機能を無効化する意図がある場合のみにしてください。
- 設定を開きます（サイドバーのフッターにあるユーザーアバターをクリック）。
- 左側のナビゲーションで、組織配下のネットワークポリシーをクリックします。
- [ルールを追加] をクリックします。ルールリストの末尾に空の行が追加されます。
- ドメインにホスト名またはワイルドカードパターンを入力します。
- アクションを許可またはブロックに設定します。
- [コメント (任意)] にそのルールが存在する理由を記録します。
- [保存] をクリックします。ステータスバーが「未保存の変更があります」から「保存しました。」に変わり、行のハイライトが消えます。
保存したルールは、Studio やチャットを再起動せずに、新しいエージェントのリクエストへ適用されます。保存前に編集を取り消したい場合は [破棄] をクリックすると、すべての未保存の変更が元に戻ります。
コメント欄は、そのルールがなぜ存在するのかを記録できる唯一の場所です（「Snowflake コネクタの egress」「週次レポートスキルが使うベンダー API」など）。半年後に、不要になったルールを自信を持って削除できるか、用途を思い出せずに残し続けるかの分かれ目になります。
ページ上部の [ルールに一致しない場合:] トグルが、どのルールにも該当しないリクエストの扱いを決めます。許可またはブロックを選択し、[保存] をクリックしてください。トグルの隣のヘルプテキストが選択内容を示します（「— 一致しないリクエストはブロックされます」）。
デフォルトが許可の場合、エージェントは明示的にブロックされていないすべてのホストに到達できます。レビューしていないスキルが追加したホストも含まれます。特別な理由がない限り、デフォルトはブロックのままにし、許可ルールでアクセスを付与してください。
最初に一致したルールが採用されるため、順序はポリシーの一部です。
- 並べ替えるには、ルールのハンドルをドラッグして位置を移動します。1 列目の数字がそのルールの評価順序です。
- 削除するには、そのルールの削除（ゴミ箱）アイコンをクリックします。
いずれの操作も、[保存] をクリックしないと反映されません。
コネクタは必要とする外部の egress ドメインを宣言し、設定 → コネクタ設定の設定済みコネクタの隣に表示されます。コネクタを追加してもそれらのドメインがネットワークポリシーに自動追加されることはありません。ご自身で許可しないと、エージェントが初めてそのサービスを呼び出した時点でコネクションが失敗します。コネクタの全体的な手順はコネクションを参照してください。
スキルにも同じ要件があります。ベンダー API を取得するスキルはそのベンダーのホストを許可する必要があり、プラグインマーケットプレイスは *.github.com に加えてホスト単体の github.com を必要とします。プラグインマーケットプレイスを参照してください。
ネットワークポリシーが管理するのはエージェントのサンドボックスです。エージェント自身ではなく Treasure AI のコネクタサービスがリクエストを実行するコネクタは、その管理範囲の外にあります。現時点でこの動作をするのは Treasure AI Voice コネクタです。
このようなコネクタでは、次のようになります。
- egress ドメインを宣言しません。 コネクタ設定にも「このドメインを許可してください」というリマインダーは表示されず、追加すべきものはありません。
- リクエストはネットワーク監査ログに記録されます。 宛先は API ホスト、アクションは
allowで、実行のきっかけとなったユーザーとチャットに紐づきます。可視性は失われません。 - Block ルールでは止まりません。 この通信に対してポリシーは評価されないため、ホストをブロックしても効果はありません。
この種のコネクタは、ポリシーではなく設定した場所で制御してください。コネクタを無効化すれば新規の認可が止まり、削除すれば既存のコネクションがすべて解除されます。コネクションを参照してください。
- ネットワークポリシーページに、想定した許可またはブロックのアクションとともにルールが評価順に表示される
- [ルールに一致しない場合:] のトグルが意図したデフォルトアクションになっている
- 保存後にステータスバーに「保存しました。」と表示され、ハイライトされた行が残っていない
- 新たに許可したホストを使うテストチャットが成功し、ネットワーク監査ログにそのリクエストが
allowアクションで表示される
| 問題 | 解決策 |
|---|---|
| エージェントの操作が外部サービスに到達できない | ネットワーク監査ログを開き、宛先ドメインでフィルタリングしてください。block のエントリがあれば、そのホストを許可するルールが存在しません。許可ルールを追加してください。エントリが全く無い場合、原因はネットワークポリシーではないことが多いです（コネクタの認可状態を確認してください）。 |
| ルールは正しいのに効果がない | その上にある範囲の広いルールが先に一致しています。評価は最初の一致で止まるため、限定的なルールを広範なルールより上に移動してください。 |
| サブドメインへのリクエストは通るがホスト単体がブロックされる | *.example.com は example.com に一致しません。ホスト単体用のルールを別途追加してください。 |
| ドメイン欄に「Must be a domain (example.com) or wildcard (*.example.com)」と表示される | パターンにサポート外の形式（ポート、パス、IP レンジ、先頭の *. 以外のワイルドカード）が含まれています。ホスト名のみを入力してください。 |
| 設定にネットワークポリシーが見つからない | このページはアカウント管理者にのみ表示されます。組織の管理者にロールを確認してください。 |
- ネットワーク監査ログ — ポリシーが何を許可し、何をブロックしたかを確認する
- セキュリティ概要 — サンドボックスの分離、暗号化、データレジデンシー
- コネクション — コネクタの egress ドメインとユーザーごとの認可
- アクセス制御 — 権限、IP Allowlist、ユーザーごとの Studio アクセス