> ## 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.
# アイデンティティとアクセス管理
> Droidが組織、プロジェクト、ユーザーIDを使い、誰がどこでどの権限でエージェントを実行できるかを制御する方法。
アイデンティティとアクセス管理制御は、**誰がDroidを実行できるか**、どの環境で、どのようなポリシーの下で実行するかを制御します。
このページでは、アイデンティティモデル、ロール、環境の概要を説明します。詳細なSSOとSCIM設定手順は [SSO、IdP、SCIMプロビジョニング](/jp/enterprise/identity-sso-and-scim) にあります。
***
## アイデンティティモデル
すべてのDroid実行は、3つのアイデンティティ次元に関連付けられます：
人間の開発者はSSO（SAML/OIDC）で認証し、ディレクトリグループとロールを継承します。自動化（CI/CD、スケジュールジョブ）は、長期トークンまたはワークロードIDを持つ**マシンID**で実行されます。
アクティブなリポジトリと`.factory/`フォルダが、**組織、プロジェクト、
フォルダコンテキスト**を決定します。これらのレベルのポリシーが、Droidが使用できるモデル、ツール、
連携を決定します。
DroidがノートPC、CIランナー、サンドボックス化されたVM/devcontainerのどこで実行されているかが環境属性として取得されます。ポリシーはこれらを異なる扱いにできます（例: CIやサンドボックス内でのみ高い自律性を許可）。
各Droidセッションは、セッションID、CLIバージョン、gitブランチなどのメタデータを記録し、監査とOTELテレメトリで利用できます。
***
## 組織アイデンティティとSSO（概要）
ほとんどの企業は、**Okta、Azure AD、またはGoogle Workspace**などのアイデンティティプロバイダー（IdP）とFactoryを統合します。
高レベルでは：
* **組織メンバーシップ**は、Factory組織とチームにマッピングされたIdPグループから派生します。
* **SSOサインイン**により、開発者は企業の認証情報を使用してWebプラットフォームとDroidの両方にアクセスできます。
* **ロール情報**（例：`Owner`、`Admin`、`User`）は、IdPグループからFactoryロールに流れます。
IdPアプリケーションの設定、属性のマッピング、プロビジョニングの有効化を含む、段階的なSSOとSCIM設定については、[SSO、IdP、SCIMプロビジョニング](/jp/enterprise/identity-sso-and-scim) を参照してください。
***
## ロールベースアクセス制御（RBAC）
Factoryは3つの主要なアクター分類を区別します：
* **組織管理者**
* モデルポリシー、グローバルコマンドの許可/拒否リスト、デフォルトのテレメトリターゲットを含む、組織レベルの `.factory` 設定を定義します。
* どのデプロイメントパターン（クラウド、ハイブリッド、エアギャップ）がサポートされ、Droidバイナリがどこで実行できるかを決定します。
* 最大自律性レベルやユーザー提供のBYOKキーが許可されるかどうかなどのセキュリティ機能を設定します。
* **プロジェクトオーナー/メンテナー**
* バージョン管理に存在するプロジェクトレベルの `.factory/` フォルダーを所有します。
* 組織ポリシーを弱めることなく拡張する、チーム固有のモデル、ドロイド、コマンド、フックを提供します。
* Droidを特定のリポジトリやディレクトリに制限するなど、プロジェクト固有のポリシーを設定します。
* **開発者**
* `~/.factory/` で個人設定をカスタマイズします（例：許可されたセット内でのデフォルトモデル選択）。
* ローカル、IDE、またはチーム提供のスクリプトやCIジョブを通じてDroidを実行します。
* 組織またはプロジェクトレベルで定義された設定を上書きすることはできません。
ロール割り当てはIdPからFactoryに流れ、**階層設定エンジン**が各ロールが実際に変更できる内容を強制します。正確な優先順位ルールについては [階層設定と組織管理](/jp/enterprise/hierarchical-settings-and-org-control) を参照してください。
***
## デバイス、環境、ワークスペーストラスト
DroidはCLIであるため、多くの環境で実行できます：
* 開発者のラップトップ（macOS、Linux、Windows）
* リモート開発サーバーまたはワークスペース
* CIランナーとビルドエージェント
* 強化されたVMとdevcontainer
エンタープライズ顧客は通常、Droidを**エンドポイント管理**と**ワークスペーストラスト**制御と組み合わせます：
**Jamf、Intune、その他のMDMソリューション**などのツールを使用して、Droidバイナリのインストール場所、実行できるユーザー、読み取れる設定ファイルを制御します。
一般的なパターンは次のとおりです:
* 管理対象ユーザーアカウントでのみDroidの実行を許可する。
* 設定ディレクトリを会社管理のボリュームに制限する。
* OSレベルのディスク暗号化と画面ロックポリシーを適用する。
Droidを**既知のリポジトリと環境**でのみ信頼済みとして扱います:
* 開発者のマシンでDroidを特定のパスまたはリポジトリに固定する。
* 信頼できないコードには、追加承認またはサンドボックス環境を必須にする。
* プロジェクトレベルの`.factory/`フォルダを使用し、どのリポジトリが"Droid-ready"か、どのポリシーを適用するかを示す。
同じ開発者が、ノートPC、CI、分離コンテナなど複数のコンテキストでDroidを実行する場合があります。
ポリシーはこれらの違いを考慮できます:
* devcontainerまたはCIランナー内でのみ、より高い自律性や強力なツールを許可する。
* ノートPCで実行している場合はネットワークアクセスやコマンド実行を制限する。
* 環境固有のアラートをサポートするため、OTELテレメトリに環境属性を付与する。
***
## アイデンティティがポリシーとテレメトリにどのように流れるか
アイデンティティと環境情報は主に2つの方法で使用されます：
1. **ポリシー評価** – 階層設定（組織 → プロジェクト → フォルダー → ユーザー）はアイデンティティを使用して、特定の実行にどの設定バンドルが適用されるかを決定します。
2. **テレメトリと監査** – Droidは `user.id`、`team.id`、`session.id`、環境タグなどの属性を含むOTELメトリクス、トレース、ログを出力するため、組織別およびチーム別のダッシュボードを構築できます。
これらのアイデンティティがテレメトリでどのようにエンコードされるかの詳細については、[コンプライアンス、監査、モニタリング](/jp/enterprise/compliance-audit-and-monitoring) を参照してください。