pilot-and-evaluation-design

パイロットと評価の設計

業界の研究開発ソリューションを前に進めるべきか判断できる、信頼性のある最小限のパイロットを設計します。

目的は、ソリューションが完璧だと証明することではありません。責任ある構築、中止、または反復の判断に十分なまで、不確実性を減らすことです。

このスキルを使う場面

次の場合にこのスキルを使います：

• ソリューション候補があり、検証が必要な場合；
• ユーザーが PoC、MVP、パイロット、または実験計画を必要としている場合；
• 技術指標をビジネス価値に結び付ける必要がある場合；
• オフライン評価、バックテスト、人によるレビュー、または A/B テストが必要な場合；
• コンプライアンス、公平性、説明可能性、レイテンシー、または導入などのリスクを測定する必要がある場合。

純粋な学術実験には、experiment-design を使ってください。ビジネス上の課題が不明確な場合は、まず industry-problem-framing を使ってください。

ワークフロー

1. パイロットの判断事項を明確にする

パイロットで判断できるようにする事項を定義します：

After this pilot, we will decide whether to [scale / redesign / stop / collect more data] based on [criteria].

デモを作るだけのパイロットは避けてください。有用なパイロットは、意思決定を変えます。

2. 範囲と導入境界を定義する

次の項目を明確にします：

• 対象となるユーザーグループまたはプロセス；
• データの期間；
• 製品またはワークフロー上の接点；
• パイロットがオフライン、シャドーモード、人による支援付き、または本番環境での実施のいずれか；
• 出力をレビューする担当者；
• 許可されるアクション；
• 明示的に対象外とするもの。

中核となる仕組みを検証できる範囲で、最もリスクの低い設計を優先してください。

一般的なパイロットの実施形態：

実施形態	使用する場面	主な制約
オフラインリプレイ	過去の判断と結果がある	行動の変化を測定できない
バックテスト	時間に依存する判断が重要	データリークやポリシー変更の影響を受けやすい
シャドーモード	ユーザーに影響を与えず、本番環境に近い入力が必要	ビジネスへの直接的な影響がない
人による支援付きパイロット	導入状況や判断に関するシグナルが必要	人の行動によってばらつきが生じる
A/B テスト	安全な本番介入が可能	トラフィック、ガバナンス、モニタリングが必要

3. ベースラインを定義する

必ず次と比較します：

• 現行のプロセス；
• 単純なヒューリスティック；
• 該当する場合は、単純な統計または ML のベースライン；
• 実現可能であれば、公開済みまたは標準的な手法；
• 意思決定支援が関わる場合は、人のみの場合、または人がツールを使う場合の条件。

ベースラインを実装できない場合は、その理由と、結論の確かさがどう弱まるかを説明してください。

4. 判断上の役割に応じて指標を選ぶ

次の 4 つの指標グループを使います：

1. 主要な成功指標：実施可否を決める指標。
2. 診断指標：システムが機能する、または失敗する理由を説明する指標。
3. ビジネス指標：コスト、収益、リスク、時間、満足度、またはコンプライアンスに結び付く指標。
4. ガードレール指標：パイロットが許容できない害をもたらさないようにする指標。

例：

• 不正・リスク：レビュー対応可能件数を考慮した precision@、偽陽性率を固定した場合の再現率、捕捉した損失額、調査担当者の作業負荷；
• ドキュメント AI：抽出 F1、項目単位の精度、人による修正時間、ハルシネーション率；
• レコメンデーション：リフト、コンバージョン、解約、オプトアウト、セグメント別の公平性；
• LLM サポート：回答の根拠性、エスカレーション率、対応時間、人による受容率、ポリシー違反率。

パイロットで指標と定性的なシグナル（インタビュー、導入に関するフィードバック、人によるレビュー）を組み合わせる場合は、2 つの調査を別々に実施して後からつなぎ合わせるのではなく、その組み合わせ自体を意図的に設計してください。references/mixed-methods-integration.md では、混合する価値がある場面（方法論上の根拠、新たな統合的知見）、適切な設計タイプ（探索的／説明的な順次型、収束並行型、埋め込み型）、避けるべきアンチパターン（サンプルの汚染、機会の逸失、統合の失敗）について、Storey et al. (2025)、arXiv:2404.06011 に基づいて解説しています。

5. 妥当でない結論を防ぐ

次の点を確認します：

• 目的変数のリーク；
• 特徴量に含まれる未来の情報；
• 既存のポリシーによるラベルの偏り；
• レビュー対象事例における選択バイアス；
• 季節性やキャンペーンの影響；
• ビジネスルールの変更；
• ランダムでないパイロットの割り当て；
• 指標のゲーム化；
• 人によるレビューの一貫性の欠如；
• データドリフト。

重要なリスクがある場合は、統制策または留保事項を加えてください。

6. アブレーションとストレステストを追加する

アブレーションは、意思決定に関わる問いに答えられる場合にのみ実施します。

例：

• ネットワーク構造が重要かどうかを検証するため、グラフ特徴量を除外する；
• LLM システムで、検索のみの場合と検索を使った生成の場合を比較する；
• 人間による採用において、モデルのスコアと、モデルのスコアに説明を加えた場合を比較する；
• 顧客セグメント、支店、チャネル、期間ごとにパフォーマンスを検証する；
• 分布外の月やまれなケースでストレステストを実施する。

7. 実施可否の基準を設定する

結果を見る前にしきい値を定義します。

Go: improves primary metric by X while guardrails remain within Y.
Iterate: improves diagnostics but misses business threshold.
Stop: does not beat current process or violates guardrails.
Collect data: uncertainty dominated by label/data gaps.

サンプルサイズが許す場合は、信頼区間を使用するか、期間を繰り返し分割して検証します。

出力形式

# Pilot and evaluation design: [solution]

## Pilot decision

## Pilot scope
- Mode:
- Users/process:
- Data window:
- Deployment boundary:
- Out of scope:

## Hypothesis
If we ..., then ..., because ..., compared with ...

## Baselines

## Metrics
| Metric | Type | Why it matters | Decision threshold |
|---|---|---|---|

## Evaluation protocol
- Data split/replay design:
- Human evaluation design:
- Statistical analysis:
- Leakage controls:
- Monitoring:

## Ablations and stress tests

## Risks and guardrails

## Go/no-go criteria

## Pilot deliverables

品質基準

優れたパイロット設計は、小規模で、安全性が高く、意思決定に関わる内容を扱い、証明できないことについて誠実であるべきです。