モデル管理と階層
モデルアクセスは、Factory 全体で使用される同じ階層設定システムによって管理されます：-
組織レベル
- 許可されたモデルとカテゴリの権威あるリストを定義します。
- モデルを明示的に禁止できるため（例：非エンタープライズ API）、プロジェクトやユーザーが再度有効にすることはできません。
- ユーザー提供の BYOK キーが全く許可されるかどうかを決定します。
-
プロジェクトレベル
- 組織承認済みセットの上に追加のモデルを追加できますが（例：プロジェクト固有のファインチューン）、禁止されたものを再有効化することはできません。
- プロジェクトデフォルトを設定できます—例：「テストには小さなモデルを使用し、リファクタリングには大きなモデルを使用する」。
-
ユーザーレベル
- 許可されたセット内で個人のデフォルトを選択できます。
- 上位レベルで許可されていないモデルは表示・選択できません。
LLM ゲートウェイ
多くの企業では、認証、ルーティング、ポリシー実施を処理する LLM ゲートウェイの背後にモデルアクセスを集約しています。 Factory は2つの方法でゲートウェイと連携します：-
直接設定されたゲートウェイエンドポイント
.factory/settings.jsonは特定のプロバイダー向けにゲートウェイベース URL を指定できます。- 環境変数で呼び出しをルーティングできます（例：
ANTHROPIC_BASE_URL、OPENAI_BASE_URL）。 - BYOK 経由で設定されたカスタムモデルは、
base_urlとプロバイダー固有の設定を使用してゲートウェイエンドポイントを指すことができるため、モデルが内蔵かカスタムかに関係なく同じゲートウェイポリシーが適用されます。
-
組織レベルのゲートウェイポリシー
- 組織管理者は、すべてのモデルトラフィックが特定のゲートウェイを経由することを要求できます。
- BYOK を制限して、一元管理されたキーとアイデンティティのみが使用されるようにできます。
~/.factory/settings.json 内の customModels 配列と、これらのモデルが /model セレクターにどのように表示されるかを説明しています。
クラウドプロバイダーと BYOK
Factory は複数のモデルデプロイメントパターンをサポートしています：- 直接クラウドプロバイダー – 企業認証情報を使用して OpenAI、Anthropic、Google などを呼び出す。
- クラウド AI プラットフォーム – AWS Bedrock、GCP Vertex、Azure OpenAI を IAM ベースの認証で使用。
- オンプレミス / セルフホスト型モデル – ネットワーク内で実行され、承認済みゲートウェイ経由で公開されるモデル。
- 組織管理者はユーザー提供 API キーを許可または禁止できます。
- BYOK が許可されている場合でも、組織はキーが対象にできるプロバイダーとエンドポイントを制限できます。
- プロジェクト設定では、セキュアストア内のチーム全体のモデル用の共有キーや認証情報を定義できます。
- ユーザー BYOK を完全に無効にします。
- データ残留性と監査ログを実施するゲートウェイ経由ですべてのトラフィックをルーティングします。
MCP サーバー
Model Context Protocol (MCP) により、Droid は外部システム—チケットキュー、ドキュメント、データベースなど—に明確に定義されたツールを通じてアクセスできます。 MCP サーバーは非常に強力で、内部システムから読み取りを行ったり、副作用のあるアクションを実行する可能性があります。Factory はこれらを制御するためのいくつかのレバーを提供します：-
組織許可リスト/禁止リスト
- 組織管理者は、どの MCP サーバーが全く許可されるかを定義します。
- 許可リストにないサーバーは、プロジェクトが設定を試みても無視されます。
-
プロジェクトレベルの設定
- プロジェクトは許可されたサーバーのサブセットを有効にし、環境変数と接続詳細を設定できます。
-
ユーザーレベルのオプトイン
- ユーザーは自分のセッション用に許可されたセットから MCP サーバーを有効または無効にできます。
Droid、コマンド、ツール
Factory の Droid、コマンド、フックのエコシステムも階層的に管理されます。組織レベルの Droid とコマンド
- 組織管理者は承認済み Droid と共有コマンドを組織レベルの
.factoryバンドルに公開できます。 - これらは多くの場合、次のようなセキュリティレビュー済みワークフローをエンコードします：
/security-review/migrate-service/refactor-module
- プロジェクトとユーザーはこれらのリソースを使用できますが、変更することはできません。
プロジェクトレベルの拡張
- プロジェクトは独自の
.factory/droids/と.factory/commands/ディレクトリに専用の Droid とコマンドを追加します。 - これらは組織リソースをプロジェクト固有のロジック—特定のサービス、スキーマ、ランブックの知識など—で拡張します。
ユーザーレベルのカスタマイゼーション
- ユーザーは
~/.factory/droids/と~/.factory/commands/に個人的な Droid とコマンドを追加できます。 - これらは個人のワークフローに有用ですが、組織とプロジェクトのポリシーを尊重する必要があります（例：許可されていないツールやモデルを呼び出すことはできません）。
統合環境
Droid は CLI ファーストであるため、開発者を特定の IDE に強制することなく、多くの環境と統合できます。 一般的なパターンには以下があります：-
ターミナルとシェル
bash、zsh、fish、または Windows シェルでの Droid の直接使用。- チーム間でワークフローを標準化するためのシェルエイリアスとスクリプト。
-
IDE とエディター統合
- VS Code、JetBrains ツールなど、Droid をバックエンドエージェントとして扱う IDE との統合。
- ポリシーとテレメトリは同じ階層設定と OTEL パイプライン経由で引き続き流れます。
-
CI/CD パイプライン
- GitHub Actions、GitLab CI、または内部パイプラインでコードレビュー、リファクタリング、移行などのタスクのために Droid を実行。
- 開発者と比較して CI には別のアイデンティティと認証情報を使用。
-
リモートおよび制限された環境
- エアギャップまたは制限された環境での Droid の実行。
- セキュアなエンタープライズ配備のためのデスクトップとブラウザベースのインターフェースのサポート。