メインコンテンツへスキップ
セキュリティおよびコンプライアンスチームは、誰が、何を、いつ、どこで、どのデータを使って行ったかについて明確な答えを必要としています。このページでは、Droidがお客様のコンプライアンス体制にどのように適合するか、また既存の監視・監査インフラとどのように統合するかについて説明します。

認証とTrust Center

Factoryは、以下を含むエンタープライズグレードのセキュリティおよびコンプライアンスプログラムを維持しています:
  • SOC 2
  • ISO 27001
  • ISO 42001
私たちのTrust Centerでは、最新のレポート、セキュリティアーキテクチャドキュメント、およびサブプロセッサーリストを提供しています。セキュリティとコンプライアンスのレビューの主要なリファレンスとしてご利用ください。

監査証跡とイベント

監査情報には、2つの補完的なソースがあります:
  1. Factory側の監査ログ(クラウド管理機能向け)
  2. 顧客側のOTELテレメトリ(Droidが出力)

Factory側の監査ログ(クラウド管理)

Factoryのホスト型サービスを使用する場合、コントロールプレーンは以下のような重要なイベントを記録します:
  • 認証イベントおよびSSO/SCIM変更
  • 組織およびプロジェクト設定の更新
  • ポリシー変更(モデルの許可/拒否リスト、自律性制限、Droid Shield設定、フック設定)
  • Web UI内の管理者操作
これらのログは、Trust Centerまたはお客様のエンタープライズ契約で合意された統合を通じてエクスポートできます。

顧客側のOTELテレメトリ

Droidは、お客様自身のシステム内できめ細かい監査データとして機能するOTELメトリクス、トレース、およびログを出力します。これには以下が含まれます:
  • セッション開始・終了イベント(ユーザー、チーム、環境、プロジェクト情報でタグ付け)
  • ツール使用イベント(どのツールが呼び出されたか、実行時間、成功したかどうか)
  • コマンド実行メタデータ(リスク分類と結果を含む)
  • コード変更イベント(どのファイルとリポジトリが変更されたか)
これらのシグナルをどのくらい保持するか、CI/CDパイプライン、SIEM、ケース管理ツールなどの他のシステムとどのように関連付けるかは、お客様が制御できます。

OpenTelemetryスキーマとコレクター

FactoryのOTELサポートは、既存の可観測性ツールとの統合を念頭に設計されています。 高レベルでは、テレメトリには以下が含まれます:
  • リソース属性 – 環境、サービス、組織、チーム、ユーザーを記述
  • メトリクス – セッション、LLM使用、ツール、エラーのカウンターとヒストグラム
  • トレースとスパン – セッションと自動実行のライフサイクルを記述
  • ログ – 重要なアクションとエラーの構造化イベント
以下を行うOTELコレクターを展開できます:
  • DroidからOTLPデータを受信
  • 独自のポリシーに基づいて属性を豊富化または編集
  • テレメトリを複数の宛先に転送(例:Prometheus + Loki、Datadog、Splunk、またはS3)
このアーキテクチャにより、Factoryのクラウド管理機能を使用している場合でも、テレメトリの所有権はお客様の手にしっかりと保持されます。 独自のOTLPコレクターへのデュアルエクスポートの段階的な設定については、Telemetry Export (OTEL)をご参照ください。 コストと生産性分析に有用なメトリクスとトレースの詳細については、Usage, Cost & Productivity Analyticsをご参照ください。

規制および業界のユースケース

Factoryは、厳格な規制体制下で運営される組織をサポートするよう設計されています。実装の詳細は異なりますが、一般的なパターンには以下があります:
  • Use hybrid or airgapped deployments for systems subject to strict data residency and record‑keeping requirements.
  • Route all LLM traffic through gateways that implement your bank’s data policies.
  • Use OTEL telemetry and hooks to ensure Droid activity is visible in your SIEM and aligned with your control framework.
  • Deploy Droid in environments that never expose protected health information to external LLMs.
  • Use model allowlists that include only providers and gateways that meet your PHI handling requirements.
  • Use Droid Shield and DLP hooks to prevent PHI from being included in prompts or logs.
  • Rely on fully airgapped deployments with on‑prem models and collectors.
  • Treat Droid as an internal tool whose artifacts and logs never leave your network.
  • Use OTEL and hooks to integrate with mission‑specific monitoring and incident response tooling.

コンプライアンスチーム向けの展開と設定

Droidをコンプライアンスおよび監視スタックに統合するには:
  1. 展開パターンの決定 – クラウド管理、ハイブリッド、または完全エアギャップ
  2. モデルとゲートウェイポリシーの定義 – どのプロバイダーとゲートウェイが許可されるか、どこで使用されるか
  3. OTELコレクターと宛先の設定 – すべてのDroidテレメトリがSIEMと可観測性ツールに流れることを確保
  4. フックとDroid Shieldの設定 – DLP、承認ワークフロー、環境固有の制御を実施
  5. ポリシーとマッピングの文書化 – Droid制御を内部制御フレームワークおよび規制義務に接続
この設定の大部分は、Hierarchical Settings & Org Controlで説明されている階層設定システムを通じて表現されます。