> ## Documentation Index
> Fetch the complete documentation index at: https://factory-docs-cli-sandbox-mcp-whole-process.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 使用量、コスト、生産性分析

> OpenTelemetryと任意のFactoryダッシュボードを使用して、Droidの導入状況を測定し、LLM支出を制御し、影響を把握する方法。

エンタープライズ導入には、優れた開発者体験以上のものが必要です。**誰がDroidを使用し、何に対して、どのようなコストで使用しているかを理解する**必要があります。

FactoryはOpenTelemetry (OTEL)を中心に構築されているため、既存のオブザーバビリティスタックに直接Droidを接続できます。また、ホストビューを求める組織向けのオプションのクラウド分析機能も提供します。

***

## OTEL‑ネイティブなメトリクスとトレース

Droidは、組織全体でどのように使用されているかを把握するOTELシグナルを出力します。

### 主要なメトリクスファミリー

メトリクスカテゴリの例には以下が含まれます：

* **セッションメトリクス**
  * インタラクティブセッションとヘッドレスセッションの数
  * セッション時間とアクティブなエンゲージメント時間

* **LLM使用メトリクス**
  * モデルおよびプロバイダー別のトークン入力/出力
  * リクエスト数とレイテンシ
  * エラー率とリトライ動作

* **ツール使用メトリクス**
  * ツール呼び出しと実行時間
  * 成功/失敗率
  * 提案および実行されたコマンドリスクレベル

* **コード変更メトリクス**
  * 変更、作成、削除されたファイルと行数
  * リポジトリおよびチーム間の分布

### トレースとスパン

トレースは、セッションまたは自動化実行のライフサイクルを示すことができます：

* セッション開始 → プロンプト構築 → LLM呼び出し → ツール実行 → コード編集 → 検証
* スパンは、モデル選択、呼び出されたツール、エラー条件など、各ステップのタイミングとメタデータを記録します

これらのシグナルにより、独自の分析サービスに依存することなく、**Prometheus、Grafana、Datadog、New Relic、Splunk**などのシステムでダッシュボードを構築できます。

これらのメトリクスを自社のOTLP互換コレクターに直接エクスポートする方法については、[Telemetry Export (OTEL)](/jp/enterprise/telemetry-export)を参照してください。

テレメトリスキーマとコンプライアンスおよび監査への対応について詳しくは、[コンプライアンス、監査、モニタリング](/jp/enterprise/compliance-audit-and-monitoring)を参照してください。

***

## Factoryクラウド分析（オプション）

クラウド管理されたデプロイメントでは、Factoryはプラットフォームチームとリーダーシップチーム向けの**ホスト分析ビュー**を提供できます。

典型的なビューには以下が含まれます：

* 組織、チーム、リポジトリ別の導入メトリクス
* モデル使用とパフォーマンストレンド
* LLM使用の概略コスト推定
* 頻度別のトップワークフローとドロイド

これらのダッシュボードは、DroidがOTEL経由で出力するのと同じシグナル上に構築されています。これらを有効にしても、基盤となるテレメトリモデルは変更されません。

ハイブリッドおよび完全エアギャップデプロイメントでは、通常**顧客所有のOTELパイプライン**のみに依存し、ホスト分析を完全に無効にします。

***

## コスト管理戦略

LLMコスト制御は、**モデルポリシー**、**使用パターン**、**オブザーバビリティ**の組み合わせです。

推奨される実践方法：

<AccordionGroup>
  <Accordion title="モデルカタログを制限">
    組織レベルのポリシーを使用して利用可能なモデルを制限します。

    * 日常的なタスクには小さなモデルを優先し、大きなモデルは複雑なリファクタリングや設計作業に残します。
    * 実験的または高コストなモデルはデフォルトで無効化します。
    * 環境ごとにモデル選択を強制します（例: CIでは安価なモデル）。
  </Accordion>

  <Accordion title="自律性とコンテキスト使用量を調整">
    自律性が高くコンテキストウィンドウが大きいほど、より多くのトークンを消費します。

    * 自律性レベルと推論量に妥当なデフォルトを設定します。
    * フックを使用してコンテキストサイズを制限したり、不要に大きなプロンプトをブロックします。
    * チームには、モノレポ全体ではなく特定ディレクトリなど、より狭いスコープで反復するよう促します。
  </Accordion>

  <Accordion title="コスト監視にOTELを使用">
    トークンとリクエストのメトリクスをオブザーバビリティスタックに送信します。

    * チーム別・モデル別のダッシュボードを構築します。
    * 使用量の異常な急増にアラートを設定します。
    * ポリシー変更前後のコスト曲線を比較します。
  </Accordion>
</AccordionGroup>

***

## 生産性への影響の測定

コストは結果の文脈でのみ意味を持ちます。OTELを使用することで、Droidの使用を既に追跡している**ソフトウェア配信と品質メトリクス**と関連付けることができます。

一般的なアプローチ：

* DroidセッションのOTELトレースをCIビルド、テスト実行、デプロイメントパイプラインと関連付ける
* インシデントの削減、アラートの解決、テストカバレッジの改善につながる変更にDroidがどの程度関与しているかを測定する
* コード変更メトリクスを使用して自動化の影響を推定する（例：リファクタリングまたは移行されたコード行数）

これらの分析は、既存のオブザーバビリティと分析スタックで完全に実行されます。FactoryはDroidからクリーンで構造化されたシグナルを提供する役割を担います。