> ## Documentation Index
> Fetch the complete documentation index at: https://factory-docs-auto-sync-jp-docs.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# LLMの安全性とエージェント制御
> Droidがリスクを分類し、許可/拒否ポリシーを適用し、Droid Shieldを使用し、フックやサンドボックスと連携してエージェントを安全に保つ方法。
Factory は LLM を強力であるが信頼できないコンポーネントとして扱います。Droid のセーフティモデルは**決定論的制御、プログラマブルフック、およびサンドボックスランタイム**を組み合わせることで、最先端のモデルでも高セキュリティ環境で安全に動作できるようにします。
***
## 2層のセーフティ
我々は以下を区別しています：
1. **決定論的制御** – モデルの動作に依存しない厳格な境界。
2. **LLM ステアリング** – 保証を提供することなく、モデルをより良い動作へと導くプロンプトとコンテキスト。
エンタープライズセキュリティは主に決定論的制御上に構築されるべきです。ステアリングは利便性向上のためのものです。
* コマンドリスク分類
* グローバルおよびプロジェクトレベルの許可/拒否リスト
* ファイルとリポジトリの保護
* Droid Shieldのシークレットスキャン
* 適用とログ記録のためのフック
* サンドボックス化されたVMとコンテナ
* プロジェクトおよび組織レベルのルールと指示
* 標準化されたコマンドとワークフロー
* MCPによるコンテキスト選択と拡充
* モデル選択と推論量のデフォルト
***
## コマンドリスク分類
Droid が提案するすべてのシェルコマンドは、パターンとコンテキストに基づいて（例：ファイル削除、ネットワークアクセス、パッケージインストール、データベースアクセス）**リスクレベル**に分類されます。
典型的なレベルには以下が含まれます：
* **低リスク** – 読み取り専用コマンドとローカル診断（例：`ls`、`cat`、`git status`）。
* **中リスク** – コードを変更したり依存関係をインストールするコマンド（例：`npm install`、`go test ./...`）。
* **高リスク** – データを削除したり、システム設定を変更したり、機密リソースとやり取りするコマンド（例：`rm -rf`、`kubectl delete`、本番環境に対する `psql`）。
組織およびプロジェクトポリシーは、リスクレベルを動作にマッピングできます：
* 低リスクコマンドを常に許可する。
* 中リスクコマンドにはユーザー承認を要求する。
* 高リスクコマンドを完全にブロックするか、特定の環境（例：隔離されたdevcontainer）でのみ許可する。
リスク情報はOTEL経由でも出力されるため、セキュリティチームは高リスクコマンドが提案または実行される頻度を監視できます。
***
## コマンドの許可リストと拒否リスト
管理者は階層設定で**グローバルおよびプロジェクト固有の許可/拒否リスト**を定義できます：
* **拒否リスト** – 決して許可されないコマンドのパターン（例：`rm -rf`、`sudo *`、`curl *://sensitive-endpoint`）。
* **許可リスト** – 特定の環境で追加の承認なしに実行できる特定のコマンドまたはパターン。
設定は拡張のみであるため：
* 組織レベルの拒否と許可はプロジェクトやユーザーによって**削除することはできません**。
* プロジェクトはリポジトリ内で追加の許可や拒否を加えることができます。
* ユーザーはポリシーを弱めることはできません。より厳格な個人デフォルトを選択するのみです。
これにより、数千台のマシン間でコマンドポリシーの一貫性を保ちながら、ローカルな特殊化も可能になります。
***
## Droid Shield：シークレットスキャンとDLP
**Droid Shield** はシークレットと機密コンテンツのための専用保護層を追加します。
有効にした場合、Droid Shield は以下ができます：
* ファイルが読み取りまたは編集される前に**ファイル**をスキャンする。
* モデルに送信される前に**プロンプト**をスキャンする。
* 実行される前に**コマンド**をスキャンする。
以下のようなパターンを検出します：
* API トークンとアクセスキー。
* パスワードとデータベース接続文字列。
* 秘密鍵と証明書。
* 組織固有の識別子（設定可能なパターン）。
ポリシーに基づいて、Droid Shield は以下ができます：
* 操作を完全にブロックする。
* 継続する前に機密部分を編集する。
* セキュリティレビューのためにOTELイベントとログを出力する。
* より深い分析のためにフック経由で**顧客DLPサービス**を呼び出す。
組織管理者は組織およびプロジェクトレベルでDroid Shieldを設定します。ユーザーは強制される場所でそれを無効にできません。
***
## 強制とログのためのフック
フックは Droid の**プログラマブルなセーフティと可観測性インターフェース**です。エージェントループの重要なポイントで独自のコードを実行できます。
一般的なフックポイントには以下があります：
* **プロンプト送信前** – シークレット、PII、またはポリシー違反についてプロンプトを検査。
* **ファイル読み取りまたは書き込み前** – 機密ファイルへのアクセスをブロックまたは編集。
* **コマンド実行前** – 承認ワークフローを強制または危険なコマンドをブロック。
* **git操作前** – 未承認の `git push` または制限されたブランチとのやり取りを防止。
* **コード生成または編集後** – リンター、セキュリティスキャナー、または内部コンプライアンスチェックを実行。
典型的なエンタープライズユースケース：
Droidセッションで`git push`をブロックし、代わりに社内CL/PRツールを使用するよう開発者に指示することで、すべてのコード変更が既存ツールを通るようにします。
プロンプトやファイルスニペットがLLMに到達する前にDLPまたはCASB APIへ転送し、ポリシーに違反する操作を拒否または編集します。
Droidが出力する環境タグに基づき、特定のツールとコマンドをCIまたはサンドボックス環境でのみ許可します。
実装詳細と例については [Hooks Guide](/jp/cli/configuration/hooks-guide) と [Hooks Reference](/jp/reference/hooks-reference) をご覧ください。
***
## コンテナとVMによるサンドボックス化
**サンドボックス化されたdevcontainerとVM**でDroidを実行することで、本番システムを公開することなく、有用な場所でより多くの自律性を安全に付与できます。
推奨パターン：
* 制限されたファイルシステムマウントとネットワーク出力を持つDocker/PodmanのdevcontainerOSを使用する。
* **本番データベースやシークレットに直接アクセスできない**コンテナやVM内でのみ、より高い自律性でDroidを実行する。
* サンドボックス環境と本番隣接環境で別々の認証情報と環境変数を使用する。
OTELテレメトリでは、環境別のダッシュボードとアラートを構築するために、環境でセッションにタグ付けできます（例：`environment.type=local|ci|sandbox`）。
***
## モデルを安全な動作に向けてステアリング
決定論的制御が基盤である一方、**LLM ステアリング**は品質を向上させ、危険なアクションが提案される頻度を減らします。
組織およびプロジェクト設定では以下を定義できます：
* **ルールと指示** – すべてのリクエストに適用されるセキュリティガイドライン、コーディング標準、および組織固有の指示。
* **標準化されたコマンドとワークフロー** – 安全なパターンを組み込んだ共有コマンド（例：`/security-review`、`/migrate-service`）。
* **コンテキストエンリッチメント** – モデルが推測ではなく正確な情報を持てるように、ドキュメント、ランブック、内部APIを公開するMCPサーバー。
これらは指示であって強制ではないため、上述の厳格な境界を置き換えるのではなく補完します。