メインコンテンツへスキップ
高セキュリティ組織には、どのデータがどこに、いつ、誰の管理下で移動するかについて正確な回答が必要です。 Factoryの回答はシンプルです:データ境界は、選択するモデル、ゲートウェイ、およびデプロイメントパターンによって決定されます。そしてDroidは、これらの境界を尊重するよう設定可能です。

概要:3つの主要なデータフロー

Droidを実行する際、データが移動する主な経路は3つあります:
  1. コードとファイル – ファイルシステムとgitリポジトリでのローカル読み書き。
  2. LLMトラフィック – モデルプロバイダーやLLMゲートウェイに送信されるプロンプトとコンテキスト。
  3. テレメトリ – OpenTelemetryを介して出力されるメトリクス、トレース、ログ。
各フローがどこまで到達するかは、クラウド管理ハイブリッド、または完全エアギャップデプロイメントのどれを使用しているかによって決まります。

Cloud‑managed

Droid runs on laptops and CI, talking to Factory’s cloud for orchestration and (optionally) analytics. LLM requests go to your chosen model providers or LLM gateways.

Hybrid

Droid runs entirely inside your infra. LLM and OTEL traffic terminate in your network; Factory cloud may only see minimal metadata if you enable it.

Fully airgapped

Droid, models, and collectors all live inside an isolated network. No runtime dependency on Factory cloud; no traffic leaves the environment.

コードとファイルアクセス

Droidはファイルシステムネイティブなエージェントです:
  • 必要な時点で、コード、設定、テストファイルをローカルファイルシステムから直接読み取ります。
  • LLMを使用して既存のコードを分析し、新しいコードを生成してから、ディスク上でパッチを適用します。利用可能な場合はgitが情報源となります。
  • コードベースをリモートデータストアにアップロードやインデックス化することはありません。Factoryクラウドには、リポジトリの静的または「コールド」コピーは保存されません。
すべてのデプロイメントパターンにおいて:
  • エージェントループとランタイムは、Droidが動作するマシン(開発者ワークステーション、CIランナー、VM、またはコンテナ)で完全に実行されます。
  • ファイル内容はコンテキストとしてLLMリクエストに含まれる可能性があるため、コードのデータパスは常に以下で説明するLLMリクエストパイプラインと同じ経路をたどります。
  • ファイルの読み書きはその環境内でローカルに留まります。プロンプトに含めることを選択した部分のみがマシンから出て、設定したモデルエンドポイントにのみ送信されます。
  • HooksとDroid Shieldはそのエージェントループ内でローカルに実行されます。デフォルトでは、ローカルSAST/ポリシーチェックのように動作します。外部サービスを呼び出すようにhookを明示的に設定した場合のみ、マシンの外部にデータを送信します。
標準のOS権限とリポジトリレイアウトを通じて、Droidがアクセスできるファイルとディレクトリを制御できます。追加のファイルレベル保護についてはLLM Safety & Agent Controlsを参照してください。

LLMリクエストとモデル固有の保証

Droidがモデル出力を必要とする場合、設定されたモデルとLLMゲートウェイにプロンプトとコンテキストを送信します。 デフォルトでは、DroidはAzure OpenAI、AWS Bedrock、Google Vertex AI、OpenAI、Anthropic、Geminiなどのプロバイダーのエンタープライズグレードエンドポイントをターゲットにでき、これらはデータ保持ゼロとエンタープライズプライバシー制御をサポートする契約を使用しています。これらの設定では、Factoryはトラフィックをプロバイダーの公式APIに直接ルーティングします。サードパーティサービス経由でこのトラフィックをプロキシしたり、プロンプトとレスポンスをFactoryクラウドに保存したりすることはありません。 代わりに独自のエンドポイント(LLMゲートウェイ、セルフホストモデル、汎用HTTP API)を設定する場合、プライバシー保証は完全にそれらのシステムとの合意によって決定されます。Factoryがその上に追加の保護を加えることはありません。

モデルとゲートウェイのオプション

  • クラウドモデルプロバイダー – OpenAI、Anthropic、Googleなどのエンタープライズ提供。
  • クラウドAIプラットフォーム – AWS Bedrock、GCP Vertex、Azure OpenAI(お客様のクラウドアカウントを使用)。
  • オンプレミス/セルフホストモデル – HTTP/gRPCゲートウェイ経由でネットワーク内またはエアギャップ環境で提供されるモデル。
  • LLMゲートウェイ – トラフィックの正規化、認証の追加、レート制限の実行、使用量のログ記録を行う中央ゲートウェイ。

Droidのモデル連携方法

  • 組織とプロジェクトのポリシーが許可されるモデルとゲートウェイ、およびユーザーが独自のキーを持ち込めるかどうかを決定します。
  • 高セキュリティ設定では、組織は一般的に:
    • 直接エンタープライズエンドポイント(例:Azure OpenAI、AWS Bedrock、Google Vertex AI、OpenAI Enterprise、Anthropic/Claude Enterprise、Gemini Enterprise)を優先して、ファーストパーティのデータ保持ゼロ保証を取得します。
    • アドホックなユーザー提供キーと汎用インターネットエンドポイントを無効にします。
    • LLMゲートウェイやセルフホストモデルを、他の重要なサービスと同様のレビューと監視の対象となるスコープ内セキュリティシステムとして扱います。
設定の詳細についてはModels, LLM Gateways & Integrationsを参照してください。

テレメトリと分析

テレメトリは、Droidが_何を_しているか、_どこで_しているかを理解する方法です。FactoryはOpenTelemetryをこのための主要なインターフェースとして扱っています。

情報源としてのOTEL

  • Droidは、環境変数または.factory設定を介して設定したエンドポイントにOTLP信号(メトリクス、トレース、ログ)を出力します。
  • 典型的な送信先には、Prometheus、Datadog、New Relic、Splunk、Loki、Jaeger、Tempoなどのシステムに供給するOTELコレクターが含まれます。
  • 高セキュリティ顧客は一般的に、自社ネットワーク内にOTELコレクターを配備し、Factoryにテレメトリを送信することはありません。

オプションのFactoryクラウド分析

クラウド管理デプロイメントでは、Factoryの独自分析ダッシュボードにオプトインできます。これらは以下を行う可能性があります:
  • 匿名化された使用メトリクスを集約して、採用状況、モデル使用量、コスト傾向を表示。
  • プラットフォームチームとリーダーシップチーム向けの組織別・チーム別インサイトの提供。
これらの分析はオプションです。組織管理者がそれらを有効にするかどうかを決定します。 信号とスキーマの詳細については、Usage, Cost & Productivity AnalyticsCompliance, Audit & Monitoringを参照してください。

データ保持と保存場所

Factoryホスト型コンポーネント

クラウド管理モードでは、Factoryは以下の目的で限定的な運用ログとメトリクスを保存する場合があります:
  • 認証と管理アクション(例:組織設定変更)。
  • サービスヘルスとデバッグ。
これらのログの保持と保存場所はTrust Centerに文書化されており、顧客エンゲージメントごとに調整可能です。

顧客ホスト型コンポーネント

ハイブリッドとエアギャップデプロイメントの場合:
  • LLMトラフィックは完全にお客様のプロバイダーとゲートウェイによって処理されます。Factoryがこれを見ることはありません。
  • テレメトリはお客様の可観測性スタックに保存され、保持はお客様独自のポリシーによって管理されます。
  • コード、設定、シークレットは、hooksやゲートウェイ経由で明示的に外部サービスに送信しない限り、お客様の環境を離れることはありません。
完全にエアギャップされた環境では、Factoryはランタイムデータを一切受信しません。すべての保持と保存場所の決定はお客様の責任となります。

実践におけるガバナンス制御

これらの保証を願望的ではなく実行可能なものにするため、Factoryは組織とプロジェクトレベルでガバナンスレバーを公開しています:
  • モデルとゲートウェイの許可/拒否リスト。
  • ユーザー提供のBYOKキーが許可されるかどうかのポリシー。
  • DLP、秘匿化、承認ワークフローのためのグローバルおよびプロジェクト固有のhooks。
  • OTELエンドポイント設定(オンプレミスコレクターの必須化を含む)。
  • 最大自律レベルとその他の安全制御、特に信頼度の低い環境での制御。
これらのレバーは、Hierarchical Settings & Org Controlで説明されている階層設定システムを通じて実装されています。