目次
1.Policy engineとは何か
2.Policy engineの仕様説明
3.ポリシールールの設定と実行結果
4.おわりに
1.Policy engineとは何か
Policy engine とは、AI によるコマンド実行や MCP のツール実行を制御できる機能です。
Policy engine のポリシーの定義内容（ルール）次第で指定コマンドや MCP のツール実行をユーザーの確認なしで実行できたり、指定コマンドの実行を拒否させたりすることができます。
本ブログでは Policy engine の仕様説明から実際に使ってみた結果を紹介します。
2.Policy engineの仕様説明について
指定ディレクトリへのポリシー定義 .toml ファイルの配置
Policy engine を使うには、まずディレクトリの用意が必要です。
.gemini フォルダに policies フォルダを作り、その配下に制御ルールを定義した .toml ファイルを配置します。
.toml ファイルの名前は任意で構いません。
ホームディレクトリ
└── .gemini/
└── policies/
└── team-policy.toml
.toml ファイルの基本構文
最小構成例はこちらです。
[[rule]] toolName = "run_shell_command" decision = "deny" priority = 500
ルールを設定します。ルール = 一つの実行制御定義となります。
toolName は対象ツール名を指定します。（ここでいうツール名とは MCP サーバのツールだけでなく ls コマンドのようなシェルコマンドも含めた広範な意味合いでのツールです）
run_shell_command とは Gemini CLI で実行されるシェルコマンドです。
decision は toolName で定義したツールを実行するときの制御方針です。
deny であればそのツールの実行を拒否、allow であれば実行許可、ask_user であればユーザーに判断を仰ぐ形になります。
priority がルールの優先順位値です。値は0〜999で設定します。
ルールが複数存在する場合、数字が大きいルールが優先されます。
このルールの優先順位付けには Tier の概念も影響するのですが、ここについては次の項目で説明します。
この3つの設定の他にオプション設定を組み合わせることで、より具体的なルールを定義できます。
オプション設定についても後続で説明します。
ポリシールールの適用順位について
Policy engine には Tier の概念があります。
これはルールの優先順位付けに影響します。
Tier は3つあり、1つ目が Default のポリシーです。これは Gemini CLI に元から組み込まれており、中身としては以下になります。（Default policies 参照）
- 読み取り専用ツール（read_file、glob など）は基本的に許可。
- エージェントの委譲（delegate_to_agent など）では、リモートエージェントに処理を任せる場合、ユーザーに確認を求める。ローカルのサブエージェントによる処理はユーザー確認なしで実行されるが、危険な操作が行われないよう実行内容ごとに個別のチェックが行われる。
- 書き込み系のツール（write_file、run_shell_command など）はユーザーに確認を求める。
- yolo モードでは高優先度のルールにより、すべてのツールが許可される。
- autoEdit モードでは一部の書き込み操作について、ユーザーへの確認なしで実行できるように設定されている。
2つ目が User のポリシーで、.gemini/policies/ で設定した .toml ファイルが該当します。
3つ目が Admin で エンタープライズ環境での管理者ポリシーです。
（この設定方法について、本ブログ執筆時点では Policy engine のドキュメントに解説がないのでスキップします。ちなみにここで定義したルールは Default、User のルールよりも優先されるようです）
この3つの Tier には Base としての値があり、Default が1、User が2、Admin が3です。
この数字と各ルール内で定義された優先度値0〜999を数式に当てはめ、数字の大きいルールが優先されます。
数式は、「最終優先ルールの値 = tier の Base 値 + (ルール内の priority 値 / 1000)」 です。
例えば、
Default 内のルールの priority 値が50であれば1.050。
User 内のルールの priority 値が100であれば2.100。
Admin 内のルールの priority 値が20であれば3.020。
となります。
Tier の Base 値より、Admin 内の値は常に Default と User より大きくなり、User は Default より大きくなります。
つまり常に優先度としては、Admin > User > Default となります。
User 内に複数のルールが存在する場合、各ルールで定義する priority の値でルールの優先順位が決まります。
ポリシールールのオプションについて
.toml ファイルで設定するポリシールールですが、以下のオプション項目を設定できます。
（以下の内容は Policy engine の Configuration の内容を参考に記載しています）
- mcpName：mcpName = “aws-knowledge-mcp-server” のように MCP サーバー名を指定し、toolName でその MCP サーバーのツールを指定することで、特定の MCP サーバーのツールをルール対象とできる。toolName を省き、mcpName 単独での使用も可能。この場合、指定 MCP サーバーの全てのツールが対象となる。
- argsPattern：ツールに渡される引数を正規表現で判定させる。例えば、run_shell_command で “command”: “git push” が実行された際、 argsPattern = ‘”command”:”(git|npm)’ の指定があれば、git または npm のパターンにマッチするため、そのコマンドがルール対象となる。
- commandPrefix：toolName = “run_shell_command”の時に使用する。例えば、commandPrefix = “git push” と指定すれば、git push で始まるすべてのコマンドがルール対象となる。
- commandRegex：toolName = “run_shell_command”の時に使用する。例えば、commandRegex = “^git (commit|push)” とすれば、複数のコマンド（git commit または git push で始まるすべてのコマンド）をルール対象とできる。※ commandPrefix と commandRegex は同一ルール内での併用が不可。
- modes：Gemini CLI の動作モードを指定する。例えば、modes = [“yolo”] とすれば、そのルールは yolo モード時のみに適用される。
.toml ファイルの基本構文にこれらのオプションを組み合わせることで柔軟なルール設定が可能となります。
仕様の説明は以上です。
次は実際にポリシールールをいくつか設定し、実行してみた結果を紹介します。
3.ポリシールールの設定と実行結果
今回の検証を行った Gemini CLI のバージョンは 0.24.0 、使用した MCP サーバーは aws-knowledge-mcp-server と github になります。
Terraform コマンドの制御
terraform apply、terraform destroy は拒否、terraform init はユーザーに確認、それ以外のコマンドは許可とします。
.toml ファイルのポリシールールは以下です。
# Terraform apply/destroy は拒否 [[rule]] toolName = "run_shell_command" commandPrefix = ["terraform apply", "terraform destroy"] decision = "deny" priority = 500 # Terraform init は実行前に確認 [[rule]] toolName = "run_shell_command" commandPrefix = "terraform init" decision = "ask_user" priority = 300 # その他の terraform コマンド（plan, validate, fmt など）は自動実行 [[rule]] toolName = "run_shell_command" commandPrefix = "terraform" decision = "allow" priority = 100
terraform-policy.toml に上記ポリシールールを記載し、.gemini/policies/ に配置しました。
ホームディレクトリ
└── .gemini/
└── policies/
└── terraform-policy.toml
では、Gemini CLI を立ち上げ、Terraform コマンドを実行してみます。
プロンプトに「terraform initを実行してください。」と入力しました。
自動実行や拒否はされず、実行確認のメッセージが出力されています。実行を許可しました。
正常に terraform init が実行されました。
続いて terraform plan を実行します。
ポリシールールが allow なので、期待通りユーザーに確認を求めず実行されました。
続いて terraform apply です。
│ x Shell {"command":"terraform apply -auto-approve","description":"Terraform プランを適用し、インフラストラクチャを構築または更新します。自動承認フラグを使用します。"} │
│ │
│ Tool execution for "Shell" denied by policy.
期待通り実行拒否されました。
MCP サーバーの制御
aws-knowledge-mcp-server の実行は全て許可、github は書き込み系ツールは拒否、その他のツールは許可とします。
.toml ファイルのポリシールールは以下です。
# AWS Knowledge MCP は全て許可（読み取り専用） [[rule]] mcpName = "aws-knowledge-mcp-server" decision = "allow" priority = 200 # GitHub MCP の書き込み系ツール（ファイル操作、リポジトリ作成、PR作成など）は拒否 [[rule]] mcpName = "github" toolName = ["create_or_update_file", "push_files", "create_repository", "fork_repository", "create_pull_request", "create_pull_request_review", "merge_pull_request"] decision = "deny" priority = 300 # GitHub MCP のその他ツール（読み取り・検索系）は許可 [[rule]] mcpName = "github" decision = "allow" priority = 100
mcp-policy.toml に上記ポリシールールを記載し、.gemini/policies/ に配置しました。
ホームディレクトリ
└── .gemini/
└── policies/
├── terraform-policy.toml
└── mcp-policy.toml
では、Gemini CLI を立ち上げ、プロンプトを実行してみます。
「aws-knowledge-mcp-serverを使ってNAT Gatewayのゾーナル型とリージョナル型の使い分け方を教えてください。」と実行しました。
aws-knowledge-mcp-server は許可としてるので、ユーザーに確認を求めず実行されました。
続いて github です。
読み込み系は許可してるので、ユーザー確認を求めず実行されます。
「GitHubのMCPサーバを使って、リモートリポジトリ aws-cost-analyzer のREADME の内容を教えてください。」と実行しました。
search_repositories (github MCP Server) が実行され、連続して get_file_contents (github MCP Server)、list_commits (github MCP Server) のツールが実行されました。
キャプチャから省いてますが、この3つのツールを実行後、リクエスト通り README の内容を提示してくれました。
次は書き込み系です。
実行拒否されることを確認します。
「GitHubのMCPを使って、リモートリポジトリ aws-cost-analyzer に対して、cost-analysis.md というファイルを作成してください。」と実行しました。
x create_or_update_file (github MCP Server) Tool execution for "create_or_update_file (github MCP Server)" denied by policy.
ポリシールール通り実行拒否されました。
YOLOモード時の制御
YOLO モードの場合、Default Tier として全ての実行が許可されますが、User Tier として拒否ルールを設定します。
.toml ファイルのポリシールールは以下です。
# yolo モード配下でも rm -rf は絶対ブロック # User Tier (優先度 2.500) > Default Tier (優先度 1.999) なので優先される [[rule]] toolName = "run_shell_command" commandPrefix = "rm -rf" decision = "deny" priority = 500 modes = ["yolo"]
yolo-policy.toml に上記ポリシールールを記載し、.gemini/policies/ に配置しました。
ホームディレクトリ
└── .gemini/
└── policies/
├── terraform-policy.toml
├── mcp-policy.toml
└── yolo-policy.toml
YOLO モードとするので、gemini --yolo コマンドで Gemini CLI を立ち上げ、「rm -rfコマンドでtest.txtファイルを削除してください。」と実行しました。
rm -rf を指定したプロンプトであったため実行拒否されました。
ls コマンドで test.txt が出力することからも、削除コマンドが実行されていない事が確認できました。
4.おわりに
Policy engine の仕様説明からいくつかポリシールールを設定し、実際に実行してみた結果を紹介しました。
しっかり設定すれば、読み取り系のツールは都度の確認なしで実行してくれる一方、危険な操作は確実にブロックしてくれるため、セキュリティと利便性の観点で有効な機能と感じました。
本ブログの内容は Policy engine のドキュメントの内容をベースに記載しています。
一部説明を省いてるところもあるので、興味のある方はぜひ公式ドキュメントを一読ください。
本ブログがセキュアな AI 活用の参考になれば幸いです。
簡単30秒