publication-grounded-solution-design

文献に基づくソリューション設計

曖昧な業界課題を、文献、過去の導入事例、評価計画に裏付けられた、根拠のある複数のソリューションの方向性へと具体化します。

目的は、一般的な AI アイデアのリストを作ることではありません。信頼できる先例がある手法を特定し、それらが応用できる可能性がある理由を説明するとともに、ユーザーの環境で何を検証する必要があるかを明らかにすることです。

このスキルを使用する場面

次のような要望がある場合に、このスキルを使用します。

• 曖昧な業界課題や研究開発の課題に対するソリューションをブレインストーミングする。
• 社内提案書の手法のセクションを作成する。
• 提案するソリューションを論文、事例研究、技術レポートに基づいて説明する。
• ML、最適化、LLM、ルールベース、ワークフロー、データプロダクトのアプローチを比較する。
• パイロットを正当化するのに十分な根拠を特定する。

ユーザーが広範な研究マップだけを求めている場合は、まず literature-triangulation を使用します。ユーザーがすでに具体的な手法を決めており、実験を必要としている場合は、experiment-design または pilot-and-evaluation-design を使用します。

ワークフロー

1. 業界課題を正確に定義する

次の情報を抽出するか、ユーザーに確認します。

• 改善対象となる業務プロセスまたは意思決定。
• 対象ユーザーとステークホルダー。
• 現在の課題。
• 利用可能なデータまたは想定されるシグナル。
• レイテンシー、説明可能性、コンプライアンス、コスト、人間によるレビュー、統合などの運用上の制約。
• 成功した場合、実際の業務で何が変わるか。

次の形式で課題を記述します。

For [stakeholder/process], improve [decision/workflow/outcome] by using [available signals/interventions], subject to [constraints], measured by [business and technical metrics].

課題がまだ曖昧な場合は、情報をでっち上げるのではなく、不足している情報を明示します。

2. 課題の形状に基づいて先例を検索する

ドメインのラベルだけでなく、根底にある課題の種類で検索します。

例：

• 「手動レビューの負担を軽減する」→トリアージ、ヒューマン・イン・ザ・ループによる優先順位付け、アクティブラーニング、意思決定支援。
• 「不審な行動を検出する」→異常検知、グラフによる不正検知、弱教師あり学習、系列パターンマイニング。
• 「顧客の意図を理解する」→表現学習、検索、セグメンテーション、ネクストベストアクション、因果アップリフト。
• 「文書業務を自動化する」→文書 AI、情報抽出、検索拡張生成、検証ワークフロー。

優先順位：

1. 査読済み論文と、実験を含む arXiv 論文。
2. ベンチマークまたはデータセットに関する論文。
3. 公式のシステム論文と技術レポート。
4. 具体的な指標を示す、信頼できる業界事例。
5. サーベイはマップとしてのみ使用し、最終的な根拠とはしない。

3. 先例の表を作成する

関連する各情報源について、次の項目を記録します。

情報源	一致する課題	手法	根拠	環境	応用可能性	注意点

応用可能性には、その結果をユーザーの環境に適用するために何が必要かを記載します。

例：

• データの粒度が類似している。
• ラベルの品質が類似している。
• 規制上の制約が類似している。
• 取引、顧客、文書の分布が同程度である。
• 人間からのフィードバックループが実現可能である。

4. ソリューション候補を作成する

各候補に、次の内容を含めます。

• 手法の分類。
• 中核となる仕組み。
• 根拠となる情報源。
• 必要なデータ。
• 期待される効果。
• 運用上のリスク。
• 評価戦略。
• 最も簡単なパイロット版。

候補は3～5件を目安にします。内容の薄いアイデアを長々と列挙しないでください。

候補を次のように分類します。

• 短期パイロット：現在のデータでテストでき、統合の負担が少ない。
• 戦略的な研究開発への投資：有望だが、データ、インフラ、ガバナンス、研究作業が必要。
• 現時点では非推奨：魅力的ではあるものの、根拠がない、実現不可能、またはリスクが高すぎる。

5. 手法のコンセプトを作成する

最有力候補について、簡潔な手法のセクションを作成します。

Method concept:
We propose [approach] for [problem]. The method uses [inputs] to produce [outputs/interventions]. It is motivated by [paper/case evidence], where similar mechanisms improved [metric/outcome]. In our setting, the key adaptation is [domain-specific change].

続けて、次の項目を明記します。

• モデルまたはアルゴリズムの構成要素。
• 学習またはフィッティングの手順。
• 判定しきい値の設定、またはヒューマン・イン・ザ・ループのワークフロー。
• 説明可能性または監査のレイヤー。
• パイロットのデプロイ境界。

6. 実装前に評価方法を定義する

提案するソリューションには、すべて検証方法が必要です。

• 過去データを用いたオフライン評価；
• 意思決定が時間に依存する場合は、バックテストまたはリプレイ；
• 現行プロセスとのベースライン比較；
• 出力が判断や文章作成に影響する場合は、人による評価；
• 主張する仕組みに対するアブレーション；
• 関連する場合は、公平性、堅牢性、プライバシー、コンプライアンスのチェック。

各指標がどの意思決定を支えるのかを明記してください。見栄えのためだけの指標は含めないでください。

7. 確信度を調整する

確信度を明示してください。

• 高：独立した複数の情報源、類似した設定、明確な評価方法、実現可能なデータがある。
• 中：適切な手法の先例があるものの、適用には未検証の前提が影響する。
• 低：妥当なアイデアではあるものの、根拠が限られているか、実現可能性に重大な不確実性がある。

文献に裏付けられたアイデアを、ユーザーの環境で実証済みであるかのように決して提示しないでください。文献はパイロット実施の根拠となり、適用可能性はパイロットで検証します。

出力形式

次の構成を使用してください。

# Publication-grounded solution design: [problem]

## Problem framing
- Stakeholders:
- Current pain:
- Decision/workflow:
- Constraints:
- Success criteria:
- Missing information:

## Prior successful cases and literature
| Source | Problem matched | Method | Evidence | Transferability | Caveats |
|---|---|---|---|---|---|

## Solution candidates
### Candidate 1: [name]
- Method family:
- Core idea:
- Supporting publications/cases:
- Required data:
- Expected benefit:
- Risks:
- Evaluation:
- Pilot version:
- Confidence:

## Recommended direction

## Draft method concept

## Evaluation plan

## Open questions before pilot

## Sources to read next

品質基準

良い回答では、次の点を満たしてください。

• 具体的な情報源を引用するか、情報源の調査がまだ必要であることを明確に示す；
• 実証済みの先例と、適用にあたっての前提を区別する；
• 各手法をユーザーの運用上の制約に結び付ける；
• ベースラインと評価基準を含める；
• ボトルネックがデータ、ワークフロー、インセンティブ、ガバナンスにある場合に、モデルが解決策であるかのように装わない。