diff --git a/.gitignore b/.gitignore
index 6220480..f72c8ea 100644
--- a/.gitignore
+++ b/.gitignore
@@ -133,3 +133,5 @@ model/
notebooks/environment.yml
yourwork/product
yourwork/construction
+
+.DS_Store
diff --git a/yourwork_1shot/README.md b/yourwork_1shot/README.md
new file mode 100644
index 0000000..1732eed
--- /dev/null
+++ b/yourwork_1shot/README.md
@@ -0,0 +1,109 @@
+# Working Backwards 1-Shot Generator
+
+このフォルダーは、AmazonのWorking Backwards手法に基づいて、生成AIが顧客起点のプロダクト開発を支援するツールセットです。
+
+## 概要
+
+Working Backwardsは、Amazonが実践する「顧客から逆算する」プロダクト開発手法です。このツールセットでは、顧客情報と既存ソリューションを入力するだけで、AIが以下を自動生成します：
+
+- 📊 **カスタマージャーニー分析** (Phase 1)
+- ❓ **問いの抽出** (Phase 2)
+- 🎯 **課題の優先順位付け** (Phase 3)
+- 🔧 **実装難易度評価** (Phase 4)
+- 💡 **ブレイクスルーアイデア発明** (Phase 5)
+- 📰 **PR/FAQ作成** (Phase 6)
+- ✅ **モックアップ検証計画** (Phase 7)
+
+## ファイル構成
+
+```
+yourwork_1shot/
+├── discovery/
+│ ├── customer.md # ターゲット顧客の定義（目的・背景・属性）
+│ ├── solutions.md # 既存ソリューションの分析（4つ以上推奨）
+│ └── output.md # 生成されたPR/FAQ（AIが自動作成）
+├── prompt/
+│ ├── workingbackwards-prompt.md # PR/FAQ生成用プロンプト
+│ └── v0-mock-builder-prompt.md # モックアップ生成用プロンプト
+└── sample/ # 生成例（参考用）
+ ├── ai_development_tool/
+ ├── invoice_SaaS/
+ └── security/
+```
+
+## 使い方
+
+### ステップ1: 顧客を定義する
+
+`discovery/customer.md` に以下を記載：
+- **目的**: 顧客が達成したいこと
+- **背景**: 顧客が直面している状況（具体的に）
+- **属性**: 企業規模、フェーズ、意思決定権限など
+
+### ステップ2: 既存ソリューションを調査する
+
+`discovery/solutions.md` に以下を記載：
+- いつ使う？（どんな状況で選ばれるか）
+- どう課題を解決した？（解決のアプローチ）
+- どんな効果が出た？（定量的な成果）
+- どう実現している？（技術的な実装方法）
+
+**最低4つ以上のソリューションを調査してください**
+
+### ステップ3: AIにPR/FAQを生成させる
+
+生成AIに以下を入力：
+
+```
+@discovery/customer.md と @discovery/solutions.md を読み込んで、
+@prompt/workingbackwards-prompt.md の指示に従って
+PR/FAQを生成してください。
+```
+
+AIが `discovery/README.md` に以下を順次生成します：
+- Phase 1: カスタマージャーニー（Listen）
+- Phase 2: 問いの抽出（Define）
+- Phase 3: 課題の優先順位付け（Top 3）
+- Phase 4: 実装難易度評価（solutions.mdに追記）
+- Phase 5: ブレイクスルーアイデア（Invent）
+- Phase 6: PR/FAQ（Refine）
+- Phase 7: モックアップ検証計画（Validate）
+
+### ステップ4: モックアップを作成する（オプション）
+
+Phase 7の検証計画が完成したら、`v0-mock-builder-prompt.md` を使用してモックアップを生成できます。
+
+## 出力例
+
+生成されるPR/FAQには以下が含まれます：
+
+✅ **プレスリリース本文**（Amazonスタイル）
+✅ **顧客向けFAQ**（15個以上）
+✅ **社内向けFAQ**（指針、運用指標、コスト削減戦略）
+✅ **モックアップ検証計画**（画面定義、仮説、成功基準）
+
+## サンプル
+
+`sample/` フォルダーに以下の生成例があります：
+
+- **ai_development_tool**: AI開発支援ツールの事例
+- **invoice_SaaS**: 請求書SaaSの事例
+- **security**: セキュリティ製品の事例
+
+これらを参考に、自分のプロダクトのPR/FAQを作成できます。
+
+## Tips
+
+💡 **品質を高めるコツ**
+- `customer.md` の「背景」をできるだけ具体的に（実際の会話、数値を含める）
+- `solutions.md` で「どんな効果が出た？」に定量データを入れる（○○%向上、○○時間削減など）
+- Phase完了ごとに、AIが生成した内容をレビューし、必要に応じて修正を依頼する
+
+## 開発期間
+
+通常、Phase 1-7の完了までに**1-2時間**程度です。
+
+---
+
+**作成者向けメモ**: このツールセットは、aws-ml-enablement-workshopの一部として、プロダクト開発の初期段階（Day 0）でアイデアを言語化するために設計されています。
+
diff --git a/yourwork_1shot/discovery/customer.md b/yourwork_1shot/discovery/customer.md
new file mode 100644
index 0000000..15d69fc
--- /dev/null
+++ b/yourwork_1shot/discovery/customer.md
@@ -0,0 +1,14 @@
+## ターゲットの目的、背景、属性
+
+### **目的**
+スタートアップから成長期のSaaS企業のCTOが、エンタープライズ市場へのアップマーケットを実現し、**契約単価の向上とビジネスの安定化**を図ること。中小企業向けから脱却し、大手企業との契約を獲得することで、ARRの成長加速とチャーンレートの低下を両立させる。
+
+### **背景（社内的状況）**
+先月の営業会議で、セールスVPから「3社連続で最終段階で失注した。全て理由は『セキュリティ要件を満たさない』」という報告があった。その夜、大手製薬会社との商談を進めていたエンタープライズセールス担当から「200ページのセキュリティ質問票が届いた。半分以上答えられない」とSlackが届く。CFOからは「現在のACVは50万円。エンタープライズなら500万円取れる。売上を10倍にするには新規獲得100社か、エンタープライズ10社か」と迫られる。プロダクトマネージャーからは「シングルサインオン、監査ログ、RBAC、データレジデンシー。機能要求が毎週5件以上来る」と悲鳴が上がる。取締役会では「競合のSlackはエンタープライズで成功している。うちはいつ追いつくのか」と質問され、明確な回答ができなかった。
+
+### **属性**
+- **規模**: 開発チーム20～50名のSaaS企業
+- **フェーズ**: シリーズA～Bの成長期企業
+- **課題**: エンタープライズ要件への対応不足、セキュリティ認証未取得、営業サイクルの長期化
+- **意思決定権限**: 技術戦略とプロダクトロードマップの決定権を持つCTO
+- **予算制約**: ROIを示しながら段階的な投資が必要な環境
diff --git a/yourwork_1shot/discovery/solutions.md b/yourwork_1shot/discovery/solutions.md
new file mode 100644
index 0000000..12aeb3b
--- /dev/null
+++ b/yourwork_1shot/discovery/solutions.md
@@ -0,0 +1,79 @@
+# 顧客の課題に対する解決策候補一覧
+
+### **1. コンプライアンス認証優先アプローチ**
+
+**いつ使う？**
+エンタープライズ顧客との商談で、セキュリティ質問票への回答に膨大な時間がかかり、営業リソースが枯渇している状況で選択すべきアプローチだ。特に、複数の大手企業から同じような質問を繰り返し受けており、「認証があれば質問票の8割をスキップできる」という状況において最大の効果を発揮する。金融、医療、公共機関など規制の厳しい業界をターゲットとする場合、認証なしでは商談のテーブルにすら着けない。
+
+**どう課題を解決した？**
+SOC 2 Type IIとISO 27001の認証を6ヶ月で取得することで、セキュリティ質問票への回答時間が従来の80時間から15時間に短縮された。営業チームは「認証があるので詳細は報告書をご覧ください」と回答でき、商談の進行速度が3倍に向上した。大手製薬会社との商談では、情報システム部門からの承認が従来3ヶ月かかっていたところ、認証提示により2週間で完了した。セキュリティチームの工数削減により、新機能開発に注力できる環境が生まれた。
+
+**どんな効果が出た？**
+認証取得後の6ヶ月で、エンタープライズ顧客との成約率が15%から45%に向上し、平均契約金額が50万円から450万円に増加した。失注理由から「セキュリティ不足」が完全に消失し、競合との差別化ポイントとなった。認証マークをWebサイトに掲載した結果、インバウンドリードの質が向上し、問い合わせ段階でのスクリーニングが効率化された。監査プロセスを通じて社内のセキュリティ体制が整備され、インシデント発生率が60%減少した。
+
+**どう実現している？**
+まずSOC 2 Type IIを優先取得し、エンタープライズ顧客の基本要件をクリアする。並行してISO 27001の準備を進め、グローバル展開に備える。監査法人と契約し、ギャップ分析から始め、ポリシー策定、技術的統制の実装、従業員トレーニングを段階的に実施する。Vanta、Drata、Sprintoなどのコンプライアンス自動化ツールを活用し、継続的なモニタリング体制を構築する。認証取得後も定期的な監査に対応できるよう、証拠収集とレポーティングを自動化する。
+
+**参考リソース**:
+- SOC 2: https://us.aicpa.org/interestareas/frc/assuranceadvisoryservices/aicpasoc2report
+- ISO 27001: https://www.iso.org/isoiec-27001-information-security.html
+
+---
+
+### **2. アクセス制御強化アプローチ（SSO・RBAC・監査ログ）**
+
+**いつ使う？**
+エンタープライズ顧客から「あなたのシステムに50人がアクセスする。全員に個別のID/パスワード管理は不可能」「退職者のアカウント削除漏れが怖い」「誰が何をしたか追跡できないと内部統制上問題」という要求が繰り返し出ている状況で選択すべきだ。特に、現在の製品が基本的な認証しか持たず、エンタープライズ顧客のIDプロバイダー（Okta、Azure AD、Google Workspace）との統合ができていない場合に必須となる。
+
+**どう課題を解決した？**
+SAML/OIDCベースのシングルサインオン（SSO）を実装することで、大手企業の情報システム部門から「既存のIDプロバイダーと統合できるなら検討する」という前向きな反応を得られるようになった。ロールベースアクセス制御（RBAC）により、「一般ユーザー」「マネージャー」「管理者」など役割に応じた権限付与が可能になり、最小権限の原則を満たせた。包括的な監査ログにより、「いつ、誰が、何をしたか」の完全な追跡が可能となり、コンプライアンス監査への対応が劇的に改善された。
+
+**どんな効果が出た？**
+SSO実装後、エンタープライズ顧客のオンボーディング時間が従来の2週間から2日に短縮され、導入障壁が大幅に低下した。IT部門からの「セキュリティ承認」取得時間が平均60日から15日に短縮され、営業サイクルが加速した。監査ログ機能により、金融機関からの引き合いが増加し、年間契約額が平均300万円から800万円に向上した。退職者アカウントの自動無効化により、セキュリティリスクが軽減され、顧客の信頼が向上した。
+
+**どう実現している？**
+認証基盤として、Auth0、Okta、AWS Cognito、またはOSSのKeycloakを選定し、SAML 2.0とOpenID Connect (OIDC)の両方に対応する。RBACは、リソース単位で細かく権限を定義できる設計とし、将来的なカスタマイズ要求に対応可能な柔軟性を持たせる。監査ログは、改ざん防止のため外部ストレージ（S3、CloudWatch Logs）に即座に転送し、保存期間を最低1年、理想的には3年以上確保する。ログ検索・可視化のため、Elasticsearch、Splunk、DatadogなどのSIEMツールと統合する。
+
+**参考リソース**:
+- SAML実装ガイド: https://auth0.com/docs/authenticate/protocols/saml
+- RBAC設計パターン: https://auth.wiki/ja/rbac
+
+---
+
+### **3. データ主権・レジデンシー対応アプローチ**
+
+**いつ使う？**
+グローバル展開を目指す中で、欧州顧客から「GDPRに準拠するため、データをEU域内に保存する必要がある」、日本の大手企業から「データを国外に出せない」、金融機関から「データセンターの物理的所在地の証明が必要」という要求が出ている場合に選択すべきだ。特に、顧客データのプライバシーとコンプライアンスが最優先される業界（金融、医療、公共）において、データレジデンシー対応は商談の前提条件となる。
+
+**どう課題を解決した？**
+マルチリージョン対応アーキテクチャを構築し、顧客が契約時に「米国」「EU」「日本」などデータ保存リージョンを選択できるようにした。欧州顧客に対しては、フランクフルトまたはアイルランドのAWSリージョンでデータを完結させ、GDPR第45条の適切性決定要件を満たした。日本の大手金融機関に対しては、東京リージョンでの完全なデータ隔離を提供し、金融庁のガイドラインに準拠した。データの物理的な所在地、バックアップ先、ディザスタリカバリ先を文書化し、監査対応を容易にした。
+
+**どんな効果が出た？**
+欧州市場での契約獲得が可能になり、新規ARRが年間5,000万円増加した。日本の大手金融機関3社と契約でき、1社あたり年間1,200万円の契約を獲得した。データレジデンシー対応を差別化ポイントとして打ち出すことで、競合との価格競争を避け、プレミアム価格を維持できた。GDPRコンプライアンスを明示することで、欧州顧客からの信頼が向上し、紹介による新規顧客が増加した。
+
+**どう実現している？**
+クラウドプロバイダー（AWS、Azure、GCP）の複数リージョンを活用し、顧客ごとにデータを論理的・物理的に分離するマルチテナントアーキテクチャを構築する。データベース、ストレージ、バックアップ、ログなど全てのデータコンポーネントを指定リージョン内に配置し、クロスリージョンレプリケーションを禁止する設定を実装する。GDPRの「データ処理者」としての義務を果たすため、DPA（Data Processing Agreement）を標準契約に含める。データマッピングとフローダイアグラムを作成し、監査時に即座に提示できる体制を整える。
+
+**参考リソース**:
+- GDPR準拠ガイド: https://gdpr.eu/
+- AWS データレジデンシー: https://aws.amazon.com/compliance/data-privacy/
+
+---
+
+### **4. セキュリティ透明性・信頼構築アプローチ**
+
+**いつ使う？**
+エンタープライズ顧客との商談で、「セキュリティチームの承認が下りない」「質問票に回答しても追加質問が止まらない」「情報システム部門が製品を信頼してくれない」という信頼の壁に直面している場合に選択すべきだ。特に、競合他社がセキュリティ情報を積極的に開示し、自社が「情報が不透明」と見なされている状況において、ビジネス機会の損失を防ぐために必須となる。
+
+**どう課題を解決した？**
+専用のセキュリティポータル（Trust Center）をWebサイトに設置し、認証レポート、セキュリティホワイトペーパー、コンプライアンスマトリックス、アップタイムステータス、インシデント履歴を一元的に公開した。SOC 2レポートを商談段階で即座に提供できる体制を整え、NDAなしで基本情報を閲覧可能にした。セキュリティロードマップを四半期ごとに更新し、「現在対応中の機能」「今後6ヶ月の計画」を明示することで、顧客の不安を解消した。セキュリティチームの連絡先を明示し、顧客のCISOとの直接対話を促進した。
+
+**どんな効果が出た？**
+Trust Center公開後、営業チームへの「セキュリティに関する問い合わせ」が70%減少し、セールスエンジニアの工数が大幅に削減された。商談初期段階での脱落率が40%から15%に低下し、パイプラインの質が向上した。セキュリティ情報の透明性が評価され、Gartner Peer Insightsでのセキュリティ評価が3.5から4.5に向上した。顧客のセキュリティチームから「信頼できるベンダー」として推奨される機会が増え、リファレンス顧客の獲得が容易になった。
+
+**どう実現している？**
+Trust Centerの構築には、SafeBase、Vanta Trust Center、Drata Trust Centerなどの専用ツールを活用し、リアルタイムでのコンプライアンスステータス表示を実現する。認証レポート、ペネトレーションテスト結果、脆弱性管理ポリシーなどのドキュメントを定期的に更新し、常に最新情報を提供する。Status PageやUptimeRobotを統合し、システムの可用性を透明化する。セキュリティFAQ、ユースケース別のセキュリティガイド、統合APIのセキュリティドキュメントを充実させ、顧客の自己解決を促進する。
+
+**参考リソース**:
+- SafeBase Trust Center: https://safebase.io/
+- セキュリティ透明性ベストプラクティス: https://www.cisecurity.org/
diff --git a/yourwork_1shot/prompt/v0-mock-builder-prompt.md b/yourwork_1shot/prompt/v0-mock-builder-prompt.md
new file mode 100644
index 0000000..ba36a68
--- /dev/null
+++ b/yourwork_1shot/prompt/v0-mock-builder-prompt.md
@@ -0,0 +1,654 @@
+
+このプロンプトは、仮説検証型のMVP（Minimum Viable Product）を自動生成します。
+
+**コンセプト**: 単なる「便利なアプリ」ではなく、特定の仮説を検証するための最小限の機能を持つプロトタイプ
+**実行方法**: Phase1→Phase2→Phase3→Phase4→Phase5を自動連続実行（ユーザー入力待ちなし）
+**所要時間**: 約10〜20分（アプリの複雑さによる）
+**成果物**: 即座に動作可能なNext.js + TypeScript + Tailwind CSSアプリケーション
+
+**特徴**:
+- 🎯 仮説検証を目的とした機能設計（「あると便利」な機能は排除）
+- 💎 既存ツールとの明確な差別化ポイント
+- 📊 成功指標を測定可能なデータ構造
+- 🚀 検証に必要な最小限の実装（スピード優先）
+
+
+
+
+🚨 重要: このプロンプトは自動継続実行型です 🚨
+
+- **ユーザーの入力を待たずに、Phase1からPhase5まで連続して実行してください**
+- 各フェーズ完了時に「Phase X 完了。Phase Y を開始します。」と宣言し、即座に次のフェーズを実行
+- 途中で止まらず、必ず Phase5 まで完走してください
+- completion_criteriaは確認のみで、すべて満たされていると想定して次に進んでください
+- **Phase5完了後のみ「全フェーズ完了」と宣言してください**
+
+実行フロー:
+Phase1(分析) → 即座に → Phase2(セットアップ) → 即座に → Phase3(基本ページ) → 即座に → Phase4(コア機能) → 即座に → Phase5(最終調整)
+
+
+
+あなたは経験豊富なフルスタックエンジニアです。
+ユーザーが指定するアプリケーション要件に基づいて、完全に動作するモックWebサイトをNext.jsで構築してください。
+
+🚨 **重要**: このタスクはPhase1からPhase5まで自動で連続実行してください。途中で止まらないでください。🚨
+
+
+
+{ここに作成したいアプリケーションの詳細を入力してください}
+
+💡 推奨記載内容：
+1. **解決したい課題**: ターゲットユーザーが抱えている具体的な問題
+2. **提案する解決策**: この課題をどのように解決するか（仮説）
+3. **既存の方法との違い**: 現在ユーザーがどう対処しており、なぜそれが不十分か
+4. **検証したいこと**: このアプリで何を確認/測定したいか
+5. **ターゲットユーザー**: 誰がこのアプリを使うか
+
+例：
+「フリーランスデザイナーは、プロジェクトの見積もり作成に時間がかかりすぎる。
+現在はExcelやGoogleスプレッドシートで計算しているが、過去の案件データを参照したり、
+類似案件から推定するのが面倒。このアプリは、過去の案件データから自動で見積もりを
+生成することで、見積もり時間を80%削減できるという仮説を検証したい。」
+
+**注**: 単に「タスク管理アプリを作りたい」ではなく、「なぜ既存のツールでは不十分なのか」を明確にしてください。
+
+
+
+以下の技術スタックを使用してください：
+- Next.js 14+ (App Router構成)
+- TypeScript（厳格な型定義）
+- Tailwind CSS（スタイリング）
+- shadcn/ui（UIコンポーネントライブラリ）
+- Framer Motion（アニメーション）
+- Lucide React（アイコン）
+
+
+
+外部依存を排除したシンプルな構成：
+1. **データベース不使用**: すべてのデータ永続化はLocalStorageで実装
+2. **API不使用**: サーバーサイドAPIコールは不要
+3. **認証システム**: ダミーログイン（コード内にユーザー情報を定義）
+4. **即時動作**: npm installとnpm run devで即座に動作すること
+
+
+
+- **モダンでプロフェッショナルなデザイン**: 2025年のトレンドを反映
+- **完全レスポンシブ**: モバイル、タブレット、デスクトップすべてに対応
+- **マイクロインタラクション**: ボタンホバー、ローディング状態、トランジション
+- **アニメーション**: Framer Motionで滑らかなページ遷移とフェードイン効果
+- **日本語コンテンツ**: すべてのテキストは日本語で記述
+- **アクセシビリティ**: セマンティックHTML、適切なARIA属性、キーボード操作対応
+- **カラースキーム**: 統一感のある配色（Tailwindのカラーパレットを活用）
+
+
+
+- **TypeScript厳格モード**: すべての型を明示的に定義
+- **エラーハンドリング**: try-catch、エラーバウンダリーの実装
+- **ローディング状態**: データ取得中の適切なUI表示
+- **コメント**: 複雑なロジックには日本語コメントを追加
+- **フォーマット**: Prettier準拠のコード整形
+- **命名規則**: 一貫性のある変数名、関数名（日本語コメントで意図を明示）
+
+
+
+- 画像はプレースホルダーサービスを使用（https://placehold.co/ 推奨）
+- アイコンはLucide Reactから選択
+- 必要に応じてUnsplash APIの無料画像を参照可能
+
+
+
+
+
+
+
+あなたはプロダクトストラテジストとして、アプリケーション要件を分析し、「検証すべき仮説」と「それを検証するための最小限の機能」を特定します。
+
+
+
+を精査し、以下を段階的に分析してください：
+
+## ステップ1: 課題と仮説の抽出
+
+要件から以下を特定：
+1. **解決したい課題**: ユーザーが直面している具体的な問題
+2. **ターゲットユーザー**: 誰がこの課題を抱えているか
+3. **提案する解決策（仮説）**: この課題をどう解決するか
+4. **仮説の核心**: なぜこの解決策が有効だと考えるか
+
+**重要**: 「タスク管理アプリ」のような既存カテゴリに当てはめるのではなく、要件固有の価値提案を見つけてください。
+
+## ステップ2: 仮説検証のための検証ポイント特定
+
+仮説を検証するために、以下の問いに答えてください：
+- **検証したいこと1**: ユーザーはこの課題を本当に重要だと感じるか？
+ - 検証方法: [どの機能/データで確認するか]
+
+- **検証したいこと2**: 提案する解決策は実際に使われるか？
+ - 検証方法: [どの機能/データで確認するか]
+
+- **検証したいこと3**: この解決策は既存の方法より優れているか？
+ - 検証方法: [どの機能/データで確認するか]
+
+## ステップ3: MVP機能の特定（2〜3つに絞る）
+
+検証ポイントから逆算し、**検証に必要な最小限の機能**のみを選定：
+
+各機能について：
+- **機能名**: [検証のための機能名]
+- **検証する仮説**: [この機能で何を検証するか]
+- **成功の指標**: [何が測定できれば仮説が検証されたとわかるか]
+- **必要な要素**: [この機能を実現するための具体的な要素]
+
+**重要**: 「あると便利」ではなく「検証に必須」の機能だけを選んでください。
+
+## ステップ4: ユニークな価値の明確化
+
+このアプリケーションが既存の解決策（Excel、メモ、既存ツール等）と比べて優れている点：
+1. [ユニークポイント1]
+2. [ユニークポイント2]
+
+分析結果を `/product/construction/analysis.md` に記載してください。
+
+
+
+# 仮説検証型アプリケーション設計書
+
+## 1. 課題と仮説
+
+### 解決したい課題
+[ユーザーが直面している具体的な問題を記述]
+
+### ターゲットユーザー
+- **プライマリユーザー**: [主要ユーザーの詳細]
+- **セカンダリユーザー**: [該当する場合]
+- **ユーザーの現在の解決方法**: [現在どのように課題に対処しているか]
+
+### 提案する解決策（仮説）
+**仮説文**: 「[ターゲットユーザー]は、[課題]に対して、[提案する解決策]を使うことで、[期待される成果]を得られる」
+
+**仮説の核心**:
+[なぜこの解決策が既存の方法より優れていると考えるか]
+
+### ユニークバリュー
+このアプリが既存の解決策と比べて優れている点：
+1. **[ユニークポイント1]**: [説明]
+2. **[ユニークポイント2]**: [説明]
+
+---
+
+## 2. 仮説検証ポイント
+
+### 検証ポイント1: 課題の重要性
+**検証したいこと**: ユーザーはこの課題を本当に重要だと感じるか？
+**検証方法**: [どの機能/データでこれを確認するか]
+**成功の指標**: [何が測定できれば検証されたか]
+
+### 検証ポイント2: 解決策の有効性
+**検証したいこと**: 提案する解決策は実際に使われるか？
+**検証方法**: [どの機能/データでこれを確認するか]
+**成功の指標**: [何が測定できれば検証されたか]
+
+### 検証ポイント3: 既存方法との比較
+**検証したいこと**: この解決策は既存の方法より優れているか？
+**検証方法**: [どの機能/データでこれを確認するか]
+**成功の指標**: [何が測定できれば検証されたか]
+
+---
+
+## 3. MVP機能（優先度順）
+
+### 機能1: [機能名] 🎯 最優先
+**検証する仮説**: [この機能で何の仮説を検証するか]
+**成功の指標**: [この機能で何が測定できれば成功か]
+**必要な要素**:
+- [ ] [要素1: 具体的なUI/機能要素]
+- [ ] [要素2: 具体的なUI/機能要素]
+- [ ] [要素3: 具体的なUI/機能要素]
+
+**ユーザーフロー**:
+[ユーザーがこの機能をどう使うか、ステップバイステップで記述]
+
+**データモデル**:
+```
+{
+ // この機能に必要なデータ構造
+}
+```
+
+### 機能2: [機能名]
+[同様の形式で記載]
+
+### 機能3: [機能名]（該当する場合）
+[同様の形式で記載]
+
+---
+
+## 4. 意図的に含めない機能
+
+以下の機能は検証に不要なため実装しません：
+- [含めない機能1]: [理由]
+- [含めない機能2]: [理由]
+
+---
+
+## 5. 技術実装の方針
+
+### ページ構成
+- `/`: ランディングページ（価値提案とCTA）
+- `/login`: シンプルなログイン（デモユーザー）
+- `/[メイン機能]`: [機能1のメインページ]
+- `/[サブ機能]`: [必要に応じて]
+
+**注**: ダッシュボードは仮説検証に必要な場合のみ実装
+
+### データモデル
+```typescript
+// Phase2で実装する型定義の概要
+```
+
+### 認証方式
+- [単一ユーザー/複数ユーザー種別]
+- デモユーザー: [ユーザー情報]
+
+### 主要なカスタムフック
+- useLocalStorage
+- useAuth
+- [機能特有のフック]
+
+
+
+✅ Phase1完了条件（簡潔版）:
+- `/product/construction/analysis.md` が作成されている
+- 仮説文が明確に記載されている
+- 3つの検証ポイントが定義されている
+- MVP機能が2〜3つ特定され、各機能が「検証する仮説」と紐づいている
+- 既存の解決策との差別化ポイントが明確
+
+**品質チェック**:
+- [ ] 「タスク管理」「顧客管理」などの汎用的なカテゴリに収まっていない
+- [ ] 各機能が「あると便利」ではなく「検証に必須」として選定されている
+- [ ] ユニークバリューが具体的で、既存ツール（Excel、メモ等）との違いが明確
+
+**完了宣言**: 「✅ Phase1完了。Phase2を開始します。」と宣言し、即座にPhase2に進んでください。
+
+
+
+
+
+あなたはシニアエンジニアとして、プロジェクトのセットアップと基盤実装を行います。
+
+
+
+以下の手順でプロジェクトをセットアップしてください：
+
+1. **Next.jsプロジェクトの作成**
+ ```bash
+ cd /Users/yutaokos/src/aws-samples/aws-ml-enablement-workshop/yourwork_20251016/
+ npx create-next-app@latest product --typescript --tailwind --app --src-dir --import-alias "@/*"
+ ```
+
+2. **依存関係のインストール**
+ ```bash
+ cd product
+ npm install framer-motion lucide-react
+ ```
+
+3. **shadcn/uiのセットアップ**
+ 必要なコンポーネントをインストール（Button, Card, Input, Form, Dialog, Toast等）
+
+4. **プロジェクト構造の構築**
+ ```
+ /product/
+ ├── src/
+ │ ├── app/
+ │ │ ├── page.tsx
+ │ │ ├── login/page.tsx
+ │ │ ├── dashboard/page.tsx
+ │ │ └── layout.tsx
+ │ ├── components/
+ │ │ ├── ui/ # shadcn/ui
+ │ │ ├── auth/
+ │ │ ├── layout/
+ │ │ └── features/
+ │ ├── lib/
+ │ │ ├── hooks/
+ │ │ ├── utils.ts
+ │ │ └── constants.ts
+ │ ├── types/
+ │ │ └── index.ts
+ │ └── context/
+ │ └── AuthContext.tsx
+ ├── construction/
+ │ └── analysis.md # Phase1で作成
+ └── README.md
+ ```
+
+5. **基盤機能の実装**
+ - TypeScript型定義（`types/index.ts`）
+ - Phase1の`analysis.md`で定義したデータモデルを実装
+ - LocalStorage管理フック（`lib/hooks/useLocalStorage.ts`）
+ - 認証Context（`context/AuthContext.tsx`）
+ - Phase1で特定したユーザー種別に対応
+ - 認証フック（`lib/hooks/useAuth.ts`）
+ - サンプルデータ生成関数（`lib/data/seed.ts`）
+ - Phase1で特定したコア機能に必要なダミーデータを生成
+
+
+
+✅ Phase2完了条件（簡潔版）:
+- Next.jsプロジェクトが作成され、基盤ファイル（型定義、hooks、Context）が実装されている
+- `npm run dev`で起動可能な状態
+
+**完了宣言**: 「✅ Phase2完了。Phase3を開始します。」と宣言し、即座にPhase3に進んでください。
+
+
+
+
+
+あなたはフロントエンドエンジニアとして、基本ページを実装します。
+
+
+
+以下の基本ページを実装してください：
+
+1. **ランディングページ (`app/page.tsx`)**
+ - **Phase1で定義した課題と解決策（仮説）を伝えるヒーローセクション**
+ - **ユニークバリューの説明**（既存の方法との違いを明確に）
+ - 主要機能の説明（2〜3セクション、Phase1で定義したMVP機能）
+ - CTAボタン（「今すぐ試す」→ログインページへ）
+ - スムーズなスクロールアニメーション（Framer Motion）
+
+ **重要**: 単なる機能紹介ではなく、「なぜこのアプリが必要か」を訴求してください。
+
+2. **ログインページ (`app/login/page.tsx`)** - ダミー実装で十分
+ - シンプルなログインフォーム（メールアドレスのみでOK）
+ - **デモユーザー情報を画面上に見やすく表示**（クリックで入力できると親切）
+ - ボタンをクリックするだけでログイン完了（パスワード不要でも可）
+ - ログイン後はメイン機能ページへリダイレクト
+ - Phase1で特定したユーザー種別がある場合は、各種別のデモアカウントをリスト表示
+
+ **重要**: バリデーションやエラーハンドリングは最小限で構いません。
+ デモ体験を素早くスムーズにすることを優先してください。
+
+3. **メインページ（ダッシュボードまたはコア機能ページ）**
+ - ログイン必須（RouteGuard実装）
+ - ナビゲーションバー
+ - **Phase1で定義したMVP機能へのアクセス**
+
+ **重要**:
+ - 伝統的な「ダッシュボード」にこだわる必要はありません
+ - Phase1の分析で、ダッシュボードが仮説検証に不要と判断された場合は、コア機能ページを直接表示してください
+ - 統計情報は、仮説検証に必要な場合のみ実装してください
+
+4. **共通レイアウト (`app/layout.tsx`)**
+ - ルートレイアウトの実装
+ - 認証Providerの設定
+ - ToastProviderの設定
+ - グローバルスタイルの適用
+
+5. **共通コンポーネント**
+ - Header / Navigation
+ - Sidebar（該当する場合）
+ - RouteGuard（認証チェック）
+ - RoleGuard（ユーザー種別チェック、必要な場合）
+
+
+
+✅ Phase3完了条件（簡潔版）:
+- ランディング、ログイン、ダッシュボードページが実装され、ページ遷移が動作する
+- レスポンシブデザインが適用されている
+
+**完了宣言**: 「✅ Phase3完了。Phase4を開始します。」と宣言し、即座にPhase4に進んでください。
+
+
+
+
+
+あなたはフルスタックエンジニアとして、Phase1で特定したMVP機能を完全に実装します。
+
+
+
+Phase1の `analysis.md` で特定した2〜3つのMVP機能を、優先度順に実装してください。
+
+**重要な原則**:
+1. **仮説検証が目的**: 各機能は「検証する仮説」を明確に意識して実装
+2. **データ収集を意識**: 成功の指標を測定できるようなデータ構造にする
+3. **ユニークバリューを体現**: 既存ツールとの差別化ポイントを機能に反映
+4. **シンプルさ優先**: 検証に不要な機能は実装しない
+
+**実装前の確認**:
+- [ ] 各機能が「あると便利」ではなく「検証に必須」である
+- [ ] 各機能がPhase1で定義した「検証する仮説」と紐づいている
+- [ ] 各機能で「成功の指標」が測定可能である
+
+## 実装手順
+
+### 各コア機能について：
+
+1. **データモデルの実装**
+ - TypeScript型定義
+ - LocalStorageのキー定義
+ - 初期サンプルデータの準備
+
+2. **必要な要素の実装**
+ Phase1で定義したチェックリストの各要素を実装：
+
+ 例（データ管理型の場合）:
+ - [ ] データ一覧表示ページ/コンポーネント
+ - [ ] 詳細表示ページ/コンポーネント
+ - [ ] 作成・編集フォーム
+ - [ ] 削除機能と確認ダイアログ
+ - [ ] 検索・フィルタリング機能
+ - [ ] ソート機能
+ - [ ] ページネーション
+
+ 例（ツール型の場合）:
+ - [ ] 入力フォームコンポーネント
+ - [ ] 処理ロジックの実装
+ - [ ] 結果表示コンポーネント
+ - [ ] 履歴表示機能
+ - [ ] 設定保存機能
+
+3. **カスタムフックの実装**
+ 機能に特化したカスタムフック：
+ - データ取得・更新フック
+ - 検索・フィルタフック
+ - その他必要なロジック
+
+4. **完全なユーザーフローの実装**
+ Phase1で定義したユーザーフローが実際に動作することを確認：
+ - 入力から出力まで完結する
+ - LocalStorageへの保存・読み込みが機能する
+ - ページリロード後もデータが保持される
+ - 適切なフィードバック（トースト通知等）
+ - バリデーションとエラーハンドリング
+
+5. **ダッシュボードとの統合**
+ - ダッシュボードからコア機能へのナビゲーション追加
+ - ダッシュボードでのサマリー表示（該当する場合）
+
+## 実装の柔軟性
+
+アプリケーションの種別に応じて、最適な実装方法を選択してください：
+
+**ルーティング**:
+- `/feature-name` （一覧）
+- `/feature-name/[id]` （詳細）
+- `/feature-name/new` （新規作成）
+- モーダルで作成・編集する場合は、動的ルートは不要
+
+**データ表示**:
+- テーブル形式（データ量が多い場合）
+- カード形式（視覚的な情報が重要な場合）
+- リスト形式（シンプルな項目の場合）
+
+**フォーム実装**:
+- 専用ページ（複雑なフォームの場合）
+- モーダル/ダイアログ（シンプルなフォームの場合）
+- サイドパネル（コンテキストを保持したい場合）
+
+
+
+✅ Phase4完了条件（簡潔版）:
+- Phase1で特定したMVP機能（2〜3つ）が実装され、実際に動作する
+- 各機能で「成功の指標」が測定できるデータが保存される
+- Phase1で定義した「ユニークバリュー」が機能に反映されている
+- LocalStorageでデータが永続化され、必要な操作が可能
+
+**品質チェック**:
+- [ ] 各機能が仮説検証に必要十分な実装になっている（過不足ない）
+- [ ] 既存ツール（Excel、メモ等）との差別化ポイントが明確に体現されている
+- [ ] データ構造が「成功の指標」の測定を可能にしている
+
+**完了宣言**: 「✅ Phase4完了。Phase5を開始します。」と宣言し、即座にPhase5に進んでください。
+
+
+
+
+
+あなたはQAエンジニアとして、アプリケーション全体の動作確認と最終調整を行います。
+
+
+
+以下の最終調整とテストを実施してください：
+
+1. **統合テスト**
+ - 全てのユーザーフローを実際に操作して確認
+ - ログイン → 各機能の使用 → ログアウト
+ - データの作成 → 表示 → 編集 → 削除（該当する場合）
+ - ページリロード後のデータ永続化確認
+
+2. **レスポンシブデザインの確認**
+ - モバイル（375px、414px）
+ - タブレット（768px、1024px）
+ - デスクトップ（1280px、1920px）
+ - すべてのページとコンポーネントで確認
+
+3. **エラーハンドリングの確認**
+ - コア機能での不正な入力値のバリデーション
+ - 存在しないIDへのアクセス
+ - LocalStorageが無効な場合の動作
+
+ **注**: ログインページのバリデーションは最小限で構いません（ダミー実装のため）
+
+4. **パフォーマンス最適化**
+ - 不要な再レンダリングの防止
+ - 画像の最適化
+ - コンポーネントの遅延読み込み（必要な場合）
+
+5. **ユーザビリティ改善**
+ - ローディング状態の追加
+ - エラーメッセージの改善
+ - トースト通知のタイミング調整
+ - アニメーションの微調整
+
+6. **ドキュメント作成**
+ `/product/README.md` に以下を記載：
+ - **プロジェクト概要**（解決する課題と仮説を明記）
+ - **ユニークバリュー**（既存ツールとの違い）
+ - **検証したい仮説**（3つの検証ポイント）
+ - **セットアップ手順**
+ - **デモユーザー情報**（全ユーザー種別）
+ - **実装済みMVP機能**（各機能が検証する仮説を明記）
+ - **成功指標の確認方法**（どのデータを見れば仮説が検証できるか）
+ - **技術スタック**
+ - **ディレクトリ構造**
+
+7. **ビルド確認**
+ ```bash
+ npm run build
+ ```
+ エラーなくビルドが成功することを確認
+
+
+
+✅ Phase5完了条件（簡潔版）:
+- `npm run build`が成功する
+- README.mdが作成され、セットアップ手順とデモユーザー情報が記載されている
+- 全コア機能が動作し、レスポンシブデザインが適用されている
+
+**最終宣言**: 「🎉 Phase5完了。全フェーズが正常に完了しました！」と宣言してください。
+
+
+
+
+
+
+🚨 **実行モード: 自動継続型** 🚨
+
+- **ユーザーの入力を待たずに、Phase1→Phase2→Phase3→Phase4→Phase5を連続実行してください**
+- 各フェーズ完了時は即座に次のフェーズに進み、Phase5完了まで止まらないでください
+- completion_criteriaは参考情報であり、厳密に全項目をチェックする必要はありません
+- Phase1の分析結果に基づいて、Phase4の実装内容が変わります
+- 各機能が「実際に動作する」ことを最優先してください
+
+**🎯 仮説検証ファーストの原則**:
+1. **目的は仮説検証**: 単なる「便利なアプリ」ではなく、特定の仮説を検証するためのMVP
+2. **ユニークバリュー優先**: 既存ツールでできることは避け、差別化ポイントを明確に
+3. **測定可能性**: 成功の指標を測定できるデータ構造とUI
+4. **最小限の機能**: 検証に不要な機能は勇気を持って削る
+
+**実装の優先順位**:
+1. **仮説検証に貢献すること** > あると便利な機能
+2. **ユニークバリューの体現** > 一般的な機能の網羅
+3. **動作すること** > 完璧なコード
+4. **シンプルさ** > 複雑な設計
+5. **速度** > 詳細な最適化
+
+**❌ 避けるべきパターン**:
+- 「タスク管理アプリ」「顧客管理アプリ」などの汎用カテゴリへの収束
+- 伝統的な「ダッシュボード」へのこだわり（検証に不要なら不要）
+- CRUD操作の完全な実装（検証に必要な操作のみ実装）
+- 既存ツール（Excel、Notion等）で代替できる機能
+- 「あると便利」な補助機能の追加
+
+**ログイン機能について**:
+- ログインは完全なダミー実装で構いません
+- デモユーザー情報を見やすく表示し、ワンクリックでログインできるようにしてください
+- 複雑なバリデーションやエラーハンドリングは不要です
+- 重要なのはコア機能の実装であり、ログインはあくまで認証状態を作るための簡易的な手段です
+
+**プログレス表示**:
+各フェーズ開始時に以下を表示してください：
+- Phase1開始: 「📋 Phase1: 要件分析を開始します」
+- Phase2開始: 「🛠️ Phase2: プロジェクトセットアップを開始します」
+- Phase3開始: 「🎨 Phase3: 基本ページ実装を開始します」
+- Phase4開始: 「⚡ Phase4: コア機能実装を開始します」
+- Phase5開始: 「✨ Phase5: 最終調整を開始します」
+- Phase5完了: 「🎉 全フェーズ完了！アプリケーションが使用可能です」
+
+**v0での使用について**:
+このプロンプトをv0で使用する場合：
+1. ``にアプリケーションの詳細を記入してから送信
+2. プロンプト送信後、AIが自動的にPhase1〜Phase5を実行するまで待つ
+3. もしPhase3やPhase4で止まった場合は、「Phase5まで続けてください」と入力
+4. 長いレスポンスになる可能性があるため、タイムアウトが発生する場合があります
+
+**トラブルシューティング**:
+- Phase1で止まる場合: 「Phase2からPhase5まで実行してください」
+- Phase4で止まる場合: 「Phase5を実行してください」
+- ファイルが生成されない場合: 「全ファイルを生成してください」
+
+**🌟 良い要件の例**:
+```
+要件: エンジニア向けの技術記事執筆支援アプリ
+
+課題: エンジニアはブログ記事を書く際、コードスニペットの管理とプレビューを
+何度も行き来する必要がある。現在はMarkdownエディタとブラウザを行き来しているが、
+リアルタイムでのコード実行結果を確認しながら記事を書けない。
+
+仮説: コードの実行結果をリアルタイムでプレビューしながら記事を書けるエディタを
+使うことで、記事執筆時間を50%削減し、コードの正確性を向上できる。
+
+検証したいこと:
+1. エンジニアはコード実行機能付きエディタを実際に使うか
+2. リアルタイムプレビューは記事品質を向上させるか
+3. 既存のMarkdown + ブラウザより効率的か
+```
+
+**❌ 避けるべき要件の例**:
+```
+要件: タスク管理アプリを作りたい
+（汎用的すぎる、課題や仮説が不明確、既存ツールとの違いが不明）
+```
+
diff --git a/yourwork_1shot/prompt/workingbackwards-prompt.md b/yourwork_1shot/prompt/workingbackwards-prompt.md
new file mode 100644
index 0000000..5c18a53
--- /dev/null
+++ b/yourwork_1shot/prompt/workingbackwards-prompt.md
@@ -0,0 +1,899 @@
+
+
+このプロンプトは順次実行型です。各フェーズを完了後、次のフェーズに進んでください。
+各フェーズ完了時には、完了確認と品質チェックを行ってください。
+
+
+
+
+1. チーム規模と役割構成: エンジニア1名
+2. 技術スタック経験: Next.js、Vercelの実装経験あり
+3. プロダクト開発経験: 0->1,1->10のプロダクト開発経験あり
+4. 学習・適応能力: 新技術習得は可能だが、既存技術を優先
+5. 開発期間・リソース: 1ヶ月、1名
+6. 予算制約: 月額コスト1万円以内
+
+
+
+
+
+
+
+
+
+あなたはユーザーリサーチの専門家です。
+
+
+discovery/customer.md に定義された顧客のうち、目的を達成できた顧客のインタビュー結果をまとめています。目的を達成できた顧客のインタビュー結果をまとめています。1)目的達成のために取った行動、2)行動に要したリソース(金額や時間など)、3)その時の感情の3点を時系列かつ定量的に表にまとめカスタマージャーニーを discovery/output.md の Listen セクションに記載してください。
+加えて、各行動ステップで顧客が実際に口にしそうな言葉（ペインポイント）を引用形式で追記してください。
+例：「Slackのメッセージが多すぎて、重要な情報を見逃してしまう」
+
+
+| 行動ステップ | 所要時間 | 費用 | 使用ツール | 感情（1-5） | 課題 | 顧客の声 |
+|------------|---------|------|-----------|-----------|------|---------|
+| 1. チームコミュニケーションツール検討 | 2週間 | 0円 | - | 😟 3 | 選択肢が多すぎて決められない | 「Slackのメッセージが多すぎて...」 |
+| 2. Slack導入 | 1日 | 10万円/年 | Slack | 😊 4 | 導入は簡単 | 「導入は簡単だったが...」 |
+...
+
+
+
+このフェーズは以下の条件を全て満たした場合に完了とします：
+
+【必須条件】
+[] カスタマージャーニーが最低5ステップ以上定義されている
+[] 全てのステップに定量的データ（所要時間・費用）が記載されている
+[] 全てのステップに感情スコア（1-5）が付与されている
+[] 全てのステップに「顧客の声」が引用形式で記載されている
+[] 合計費用が年間10万円以上である（課題の重要性の指標）
+[] 感情スコアが3以下の「ペインポイント」が3つ以上存在する
+
+【品質基準】
+[] 各ステップが時系列で論理的につながっている
+[] 顧客の声が具体的で、実際のユーザーが言いそうな表現になっている
+[] customer.md で定義された顧客の「目的」達成までの道のりが描かれている
+[] 使用ツールが具体的な製品名・サービス名で記載されている
+
+【次フェーズへの準備】
+[] Phase2で問いを立てるのに十分な「非効率な行動」が3つ以上特定されている
+[] 各行動の前後関係が明確で、Phase2での「同時にできない理由」分析が可能
+
+このチェックリストを確認し、全ての項目にチェックが入ったことを宣言してから Phase2 に進んでください。
+
+
+
+
+
+あなたは貪欲な研究者として、顧客が常識と思う行動に対しても常に問いを投げかけます。
+
+
+discovery/output.md の Listen セクションに記載されているユーザーの行動一つ一つについて、必要なリソースと前後の行動をもとに 2 種類の常識を疑う問いを立ててください。各行動に対し立てた問いを Define セクションに表にまとめてください。
+* 「なぜ〇〇せずに□□ができないのか? 」
+* 「なぜ○○と○○は同時にできないのか?」
+
+
+
+| 行動ステップ | 問いの種類 | 問い | 現在の制約 |
+|------------|-----------|------|-----------|
+| 1. ツール検討 | 省略型 | なぜ事前調査せずにツールを決定できないのか? | 情報が散在している |
+| 1. ツール検討 | 統合型 | なぜツール検討と試用は同時にできないのか? | 検討に時間がかかる |
+...
+
+
+
+このフェーズは以下の条件を全て満たした場合に完了とします：
+
+【必須条件】
+[] Phase1で定義した全ての行動ステップに対して、最低2つの問い（省略型・統合型）が立てられている
+[] 各問いに「現在の制約」が明記されている
+[] 合計で最低10個以上の問いが生成されている
+[] 全ての問いが「なぜ〇〇せずに□□ができないのか?」または「なぜ○○と○○は同時にできないのか?」の形式に従っている
+
+【品質基準】
+[] 問いが「当たり前を疑う」視点で立てられている（単なる機能改善要望ではない）
+[] 各問いが具体的で、解決策をイメージできる
+[] 「現在の制約」が技術的、組織的、心理的な障壁を明確に示している
+[] 問いが顧客の実際のペインポイントに根ざしている（Phase1の「顧客の声」との関連が明確）
+
+【次フェーズへの準備】
+[] Phase3で優先順位付けするための「削減/獲得できるリソース」が推測可能
+[] 各問いが独立していて、重複や包含関係がない
+
+このチェックリストを確認し、全ての項目にチェックが入ったことを宣言してから Phase3 に進んでください。
+
+
+
+
+
+Define セクションでまとめた全ての問いについて、以下の評価軸で点数化し Top3 を選定してください：
+- 削減/獲得できるリソース（時間・金額）：1-5点
+- 顧客が直面する頻度（日次=5点/週次=3点/月次=1点）：1-5点
+- 合計点の高い順に Top3 をランキングし、選定理由とともに Define セクションに追記してください。
+
+
+
+### Top 3 重要課題
+
+| 順位 | 問い | リソース削減効果 | 頻度 | 合計スコア | 選定理由 |
+|------|------|----------------|------|-----------|---------|
+| 1位 | なぜ... | 5点（週10時間削減） | 5点（毎日） | 10点 | CTOが最も頻繁に直面し、週10時間の削減が見込める |
+| 2位 | なぜ... | 4点（月50万円削減） | 4点（週3回） | 8点 | ツールコスト削減効果が大きい |
+| 3位 | なぜ... | 3点（週5時間削減） | 5点（毎日） | 8点 | 全メンバーが毎日直面する課題 |
+
+
+
+このフェーズは以下の条件を全て満たした場合に完了とします：
+
+【必須条件】
+[] Phase2で抽出した全ての問いに対してスコアリングが実施されている
+[] 「リソース削減効果」と「頻度」の両方が定量的に評価されている
+[] Top3が明確にランキングされ、合計スコアが記載されている
+[] 各問いに選定理由が具体的に記載されている
+[] 1位の問いの解決により、最低でも週5時間以上または月10万円以上の削減効果が見込まれる
+
+【品質基準】
+[] スコアリングが customer.md で定義された顧客の目的と整合している
+[] 削減効果が具体的な数値で示されている（「大きい」などの曖昧表現ではない）
+[] Top3の選定理由が、ビジネスインパクトと顧客価値の両面から説明されている
+[] 頻度の評価が Phase1 のカスタマージャーニーの実態に基づいている
+
+【次フェーズへの準備】
+[] Top3の問いに対して、solutions.md の既存ソリューションで解決可能かが判断できる
+[] 各問いの「現在の制約」が Phase5 での発明の方向性を示唆している
+
+このチェックリストを確認し、全ての項目にチェックが入ったことを宣言してから Phase4 に進んでください。
+
+
+
+
+
+熟練の開発チームリーダーとして、discovery/solutions.md に並べられた機能を自社で実装する際の難易度を評価します。
+
+
+難易度は 1, 3, 5, 10 の 4 段階とし、の情報を元に評価を行ってください。結果は、難易度と理由を箇条書きに追加する形で discovery/solutions.md に記載してください。
+
+難易度の基準：
+- 1: で定義された既存技術で1-2週間で実装可能
+- 3: 既存技術で1-2ヶ月の実装期間が必要
+- 5: 新規学習または複雑な統合が必要（2-4ヶ月）
+- 10: 大規模な設計変更またはチーム拡大が必要（4ヶ月以上）
+
+
+
+solutions.md の各ソリューションに以下を追記：
+
+**自社実装難易度**: 5/10
+**理由**:
+- で定義された技術スタックでリアルタイム共同編集を実現するには、深い理解が必要
+- ドキュメント構造化には独自のデータモデル設計が必要（2ヶ月）
+- API連携機能の実装に1ヶ月
+- 合計3ヶ月の実装期間を想定（の開発期間内に収まるか確認）
+
+
+
+このフェーズは以下の条件を全て満たした場合に完了とします：
+
+【必須条件】
+[] solutions.md の全てのソリューション（最低3つ）に難易度が付与されている
+[] 各難易度に具体的な理由が3つ以上記載されている
+[] 難易度が 1, 3, 5, 10 のいずれかである
+[] 実装期間の見積もりが含まれている
+[] の開発期間を超えるものが明確に識別されている
+
+【品質基準】
+[] 評価が で定義された技術スタックに基づいている
+[] で禁止されている新技術の学習が必要な場合、明確に指摘されている
+[] で定義されたチーム規模を前提とした現実的な見積もりになっている
+[] 難易度の理由に、フロントエンド・バックエンド・インフラの各側面が考慮されている
+[] 外部サービス連携の複雑さが評価に含まれている
+
+【次フェーズへの準備】
+[] 難易度の合計から、実現可能なソリューション組み合わせの上限が見積もれる
+[] の開発期間内に実装可能なソリューションが最低2つ以上存在する
+
+このチェックリストを確認し、全ての項目にチェックが入ったことを宣言してから Phase5 に進んでください。
+
+
+
+
+
+
+Phase3で選定した Top3 の問いそれぞれに対して、discovery/solutions.md に記載したソリューションを2-3個組み合わせた解決策を考案し、discovery/output.md の Invent セクションに追記してください。
+
+**重要**: 提案する発明のうち、最低3つは以下の「ブレイクスルーアイデアフレームワーク」を適用した、あっと驚くような独自のアイデアを含めてください。
+
+
+以下のいずれか（または複数）のアプローチを使用して、常識を覆すアイデアを生成してください：
+
+1. **逆転の発想**: 常識とされる行動の「逆」をあえて行うことで価値を生む
+ 例: 「情報を整理する」→「情報を意図的に混在させて、セレンディピティを生む」
+
+2. **異業種転用**: 全く異なる業界の成功パターンを適用する
+ 例: ゲーム業界のガチャ要素をB2B SaaSに適用、Netflix の推薦アルゴリズムをチーム編成に適用
+
+3. **時間軸の操作**: 通常「後で」行うことを「先に」、「同時に」行うことを「分離」する
+ 例: 会議の議事録を会議「前」にAIが予測生成、意思決定と実行を完全分離
+
+4. **制約の武器化**: 制約を「解決すべき問題」ではなく「差別化の源泉」として活用
+ 例: あえて機能を減らすことで使いやすさを実現、低予算を逆手に取った口コミ戦略
+
+5. **感情の逆流**: ネガティブな感情をポジティブな体験に、ポジティブな体験にスパイスを
+ 例: エラー画面を楽しいゲームに変える、順調な時にあえて警告を出して緊張感を保つ
+
+6. **AI/自動化の創造的活用**: 単なる効率化ではなく、人間にはできない新しい価値を創造
+ 例: AIが「人間らしくない」提案をあえてすることで、思考の幅を広げる
+
+
+各発明には以下を含めてください：
+- 対象となる問い（Phase3のTop3から）
+- 組み合わせるソリューション名
+- 新しい価値提案（既存ソリューションの単純な組み合わせを超えた独自性）
+- **ブレイクスルー要素**（該当する場合：どのフレームワークを適用したか、なぜそれが驚きを生むか）
+- 実装難易度（Phase4の難易度の合計）
+- 実装期間の見積もり
+
+
+
+## Invent: 発明
+
+### 発明1: [サービス名] （通常の発明）
+
+**解決する問い**: Phase3-2位「なぜ...」
+
+**組み合わせるソリューション**:
+- Notion の構造化ドキュメント機能（難易度: 5）
+- Linear の高速インターフェース（難易度: 3）
+
+**新しい価値提案**:
+既存のNotionは構造化に優れるが遅く、Linearは高速だがドキュメント管理が弱い。本サービスは、で定義された技術スタックの特性を活かし、「構造化されたドキュメントを高速に編集・検索できる」体験を実現する。
+
+**合計難易度**: 8/10
+**実装期間**: 4ヶ月（の開発期間内に収まることを確認）
+**実現方法**:
+- で定義された技術スタックの機能を組み合わせて実現
+- 具体的な実装方法と使用する機能を記載
+
+**独自の差別化要素**:
+- customer.md で定義されたペルソナに特化した機能
+- 競合と比較した価格優位性や独自機能
+
+---
+
+### 発明2: [サービス名] 🎯**ブレイクスルーアイデア**
+
+**解決する問い**: Phase3-1位「なぜ...」
+
+**組み合わせるソリューション**:
+- [ソリューションA]（難易度: X）
+- [ソリューションB]（難易度: Y）
+
+**新しい価値提案**:
+[通常の価値提案]
+
+**🚀 ブレイクスルー要素**:
+- **適用フレームワーク**: [逆転の発想/異業種転用/時間軸の操作/制約の武器化/感情の逆流/AI創造的活用]
+- **なぜ驚くか**: [このアイデアが常識を覆す理由。具体的にどの「当たり前」を疑い、どんな新しい体験を生むか]
+- **実例**: [類似のブレイクスルーアイデアの成功事例があれば記載]
+
+**合計難易度**: X/10
+**実装期間**: Xヶ月
+**実現方法**:
+- [具体的な実装方法]
+
+**独自の差別化要素**:
+- [従来にない体験価値]
+- [競合が真似できない理由]
+
+
+
+このフェーズは以下の条件を全て満たした場合に完了とします：
+
+【必須条件】
+[] Phase3のTop3の問い全てに対して発明が提案されている（最低3つ）
+[] 各発明に「新しい価値提案」が明確に記載されている
+[] 各発明に実装難易度と実装期間が記載されている
+[] 最低1つの発明が の開発期間内に実装可能である
+[] **最低3つの発明に「ブレイクスルー要素」が含まれている（🎯マーク付き）**
+
+【品質基準】
+[] 新しい価値提案が「既存ソリューションの単純な足し算」ではなく、独自の洞察に基づいている
+[] customer.md で定義されたペルソナに特化した差別化要素がある
+[] 実現方法が で定義された技術スタックで具体的に説明されている
+[] 価格や提供形態など、ビジネスモデルの要素が含まれている
+[] 競合との差別化ポイントが明確に説明されている
+
+【ブレイクスルーアイデアの品質基準】
+[] ブレイクスルーアイデアが6つのフレームワークのうち最低1つを明確に適用している
+[] 「なぜ驚くか」の説明が、具体的な「常識の覆し方」を示している
+[] ブレイクスルー要素が実装可能な範囲内に収まっている（実現不可能な空想ではない）
+[] 既存の競合が「思いつかなかった」または「実行できなかった」理由が説明されている
+[] 読んだ人が「なるほど、その手があったか！」と感じられる内容になっている
+
+【次フェーズへの準備】
+[] Phase6でプレスリリースを書くのに十分な情報（顧客、課題、解決策、効果）が揃っている
+[] 各発明が Phase1 のカスタマージャーニーのどのステップを改善するかが明確
+[] 定量的な効果（Phase3のリソース削減効果）との紐付けが可能
+
+このチェックリストを確認し、全ての項目にチェックが入ったことを宣言してから Phase6 に進んでください。
+
+
+
+
+
+あなたはAmazon の広報担当です。
+
+
+discovery/output.md の Invent セクションにある発明について誠実なプレスリリースを執筆します。
+
+**優先順位**: ブレイクスルーアイデア（🎯マーク付き）が存在する場合は、それを優先的にプレスリリースの対象として選択してください。ブレイクスルーアイデアの「驚き」を前面に押し出した内容にすることで、メディアやユーザーの注目を集めやすくします。
+
+次のテンプレートにあるプレースフォルダを置き換える形で Refine のパートにプレスリリースの土台を執筆してください。
+
+
+
+# [会社名]が[サービス名]をローンチ
+
+### [Phase3-Top1の問いを解決する、1行の価値提案]
+
+**[場所] – ([リリース日時])** – [会社名]は本日、[サービス名]を発表しました。[サービス名]は、[Phase3-Top1の問いに対する答えを、1-2文で簡潔に]。これまで、[Phase2のDefineで定義した「常識」]でしたが、[サービス名]はその常識を変え、[Phase5のInventで定義した新しい価値]を実現します。[サービス名]は、[技術的な独自性を1文で]により、[Phase3で算出した定量的な効果（削減時間・コスト）]を可能にします。[価格設定を簡潔に]。詳細は [URL] をご覧ください。
+
+**参考：AWS Lambdaの実例**
+> SEATTLE – (Nov XX, 2014) – Amazon Web Services LLC (AWS), an Amazon.com company (NASDAQ:AMZN), today announced the introduction of AWS Lambda, the simplest way to run code in the cloud. Previously, running code in the cloud meant creating a cloud service to host the application logic, and then operating the service, requiring developers to be experts in everything from automating failover to security to service reliability. Lambda eliminates the operational costs and learning curve for developers by turning any code into a secure, reliable and highly available cloud service with a web accessible end point within seconds.
+
+---
+
+_"[サービス名]によって、[Phase1のペインポイント]が解決されました"と、[顧客企業名]の[役職]は語ります。"私たちは[Phase1の具体的な状況]に苦しんでいました。[サービス名]を使うことで、[Phase3の定量的な効果]を達成でき、[Phase5の新しい価値提案による副次的効果]も得られました。これまで[Phase1の所要時間・コスト]を費やしていましたが、今では[削減後の時間・コスト]で済んでいます。"_
+
+**参考：AWS Lambdaの実例**
+> "Lambda has enabled us to deliver a world class cross device photo sharing app." says CTO of XXX. "We had great success with our app on iOS, hitting 1M downloads in 3 weeks, which led to a huge demand for the Android version. As we considered ways to leverage the cloud to make our app cross platform, we chose Lambda as the cost-effective choice to host our critical image processing logic. The support for JavaScript and Git made it easy for us to get our backend up and running within a few days. Previously, we would have incurred a huge management and operational overhead to maintain our user promise of fast and reliable response time for our customers as they access their pictures. With Lambda and AWS, we know we have the scale, stability and performance to support our customers even in periods of unpredictable demand."
+
+---
+
+[サービス名]の使い方はシンプルです。[Phase1のカスタマージャーニーを逆にたどる形で、3-5ステップで簡潔に記載]。[サービス名]は、[Phase5で組み合わせたソリューション]により、[customer.mdのペルソナ]が[Phase3-Top1の問いを解決する方法]を実現します。[サービス名]を使えば、[Phase1で要していた時間・コスト]から[削減後の時間・コスト]に削減でき、[Phase2のDefineで定義した「常識」を覆す新しい体験]が可能になります。
+
+**参考：AWS Lambdaの実例**
+> Using Lambda is simple. Developers express their application logic as they choose – as a one-line Python script, a Java application using native JNI libraries, or even a binary executable compiled from C or C++. When ready, developers can upload their code as a ZIP file, point Lambda to their Git repository, or author code directly from any browser using the AWS Console. Lambda makes it easy to write code that securely integrates other AWS services, with built in support for AWS SDKs and automatic integration with AWS Identity management (IAM) and Cognito Identity Broker. Lambda turns the code into a secure, highly available service within seconds that can be called from any connected device or app and requires no code or configuration changes to handle additional traffic.
+
+---
+
+_"[サービス名]は、私たちのチームが[Phase1の課題]を克服する加速剤となりました"と、[顧客企業名]の[役職]は語ります。"これまで[Phase1の具体的な非効率な行動]に時間を取られていましたが、[サービス名]によって[Phase3の定量的な効果]を実現できました。[Phase5のブレイクスルー要素がある場合は、その驚きを強調]。私たちの開発者は、[Phase1の運用負荷]から解放され、[Phase5の新しい価値提案による変化]に集中できるようになりました。[定量的な効果の具体例：時間削減、コスト削減、生産性向上など]を達成しています。"_
+
+**参考：AWS Lambdaの実例**
+> "Lambda has been an accelerator for my team to port and launch multiple services as we embrace the cloud." says Head of Corporate Development at XXX. "We have been using Lambda for everything from automating instant account balance updates based on customer trade notifications, to running nightly backups and scrubbing of transaction data to S3. Handling a mix of internal and external users typically presents security challenges, but Lambda incorporates a lot of AWS best practices and controls that makes it just as easy for us to securely connect to our data stored in AWS as well as our internal services."
+
+---
+
+## 顧客向けFAQ
+
+### 一般（General）
+
+**1. [サービス名]とは何ですか？**
+[Phase5のInventで定義したサービスの概要を2-3文で]
+
+**2. [サービス名]を使うメリットは何ですか？**
+[Phase3で算出した定量的な効果と、Phase5の新しい価値提案を箇条書きで]
+
+**3. [サービス名]はどのような顧客に向いていますか？**
+[customer.mdで定義されたペルソナと、Phase1のカスタマージャーニーに基づいて]
+
+**参考：AWS Lambdaの実例**
+> **1. What is AWS Lambda?**
+> AWS Lambda is a zero-administration compute platform for back-end web developers that runs your code for you in the AWS cloud, and provides you with a fine-grained pricing structure. AWS Lambda runs your back-end code on its own AWS compute fleet of Amazon EC2 instances across multiple Availability Zones in a region, which provides the high availability, security, performance, and scalability of the AWS infrastructure.
+
+---
+
+### 価格（Pricing）
+
+**4. [サービス名]の価格はいくらですか？**
+[具体的な価格プランを表形式で。Phase3のリソース削減効果と比較して投資回収期間を明示]
+
+**5. 無料トライアルはありますか？**
+[無料トライアルの有無、期間、制限事項]
+
+**6. 既存の[競合製品]と比べてコストはどうですか？**
+[Phase3で算出した既存ソリューションのコストと比較]
+
+**参考：AWS Lambdaの実例**
+> **5. How much does Lambda cost?**
+> Lambda charges $0.20 per 1 million requests thereafter ($0.0000002 per request) and $0.00001667 for every GB-second used.
+
+---
+
+### はじめ方（Getting Started）
+
+**7. [サービス名]を始めるにはどうすれば良いですか？**
+[Phase1のカスタマージャーニーを逆にたどる形で、導入手順を3-5ステップで]
+
+**8. 導入にどのくらい時間がかかりますか？**
+[具体的な導入時間。Phase1の「導入前」と比較]
+
+**9. 既存の[ツール名]との連携は可能ですか？**
+[Phase5で組み合わせたソリューションとの連携方法]
+
+**参考：AWS Lambdaの実例**
+> **10. How do I get started with Lambda?**
+> To use Lambda, you simply upload your code, and Lambda will be used to run your code on AWS infrastructure. You can invoke your application code manually, or you can configure an AWS event source to automatically trigger your code.
+
+---
+
+### [サービス名]の使用（Using [Service Name]）
+
+**10. [サービス名]で何ができますか？**
+[Phase5のInventで定義した機能を具体的に。customer.mdのペルソナのユースケースに基づいて]
+
+**11. [Phase1の具体的な行動]を[サービス名]でどう改善できますか？**
+[Phase2のDefineで立てた問いに対する答えを具体的に]
+
+**12. [Phase5で組み合わせたソリューションA]との違いは何ですか？**
+[競合比較を表形式で。Phase5の「独自の差別化要素」を強調]
+
+**13. どのような[ツール/プラットフォーム]と連携できますか？**
+[Phase5で組み合わせたソリューションを具体的に列挙]
+
+**14. [サービス名]のセキュリティはどうなっていますか？**
+[Phase5の実現方法で記載したセキュリティ対策を具体的に]
+
+**参考：AWS Lambdaの実例**
+> **11. What can I build with Lambda?**
+> Lambda is designed to run many types of applications and back end services - all with zero administration. Lambda can execute code in response to events, such as changes to Amazon S3 buckets, updates to Amazon DynamoDB tables, or custom events generated by your applications or devices. This allows you to easily build data processing triggers for AWS services like Amazon S3 and Amazon DynamoDB, stream processing use cases (e.g. clickstream analysis), and mobile back ends that retrieve and transform data from DynamoDB.
+
+---
+
+### 制限と制約（Limits and Restrictions）
+
+**15. [サービス名]には何か制限がありますか？**
+[Phase5の実現方法で記載した技術的制約を正直に]
+
+**16. [Phase1の具体的な行動]に対応していますか？**
+[現時点での対応状況と、将来の対応予定]
+
+**17. [具体的な規模：ユーザー数、データ量など]まで拡張できますか？**
+[Phase5の実現方法で記載したスケーラビリティを具体的に]
+
+**参考：AWS Lambdaの実例**
+> **26. Are there restrictions on my application code?**
+> Lambda is designed to run standard, common code from popular languages and libraries. Most code and language features are supported; a small number of system activities have restrictions. Lambda currently supports Java, Node.js, Python and Ruby; other language support will follow. AWS SDKs are pre-installed and available for each of these languages.
+
+---
+
+### パフォーマンス（Performance）
+
+**18. [Phase1の具体的な行動]にかかる時間はどのくらいですか？**
+[Phase3で算出した削減時間を具体的に。Phase1の「導入前」と比較]
+
+**19. [Phase1の具体的な課題]はどのくらい改善されますか？**
+[Phase3で算出した定量的な効果を%で]
+
+**20. 応答速度はどのくらいですか？**
+[Phase5の実現方法で記載したパフォーマンス指標を具体的に]
+
+**参考：AWS Lambdaの実例**
+> **29. What is the latency of invoking an application using the Lambda API?**
+> Applications in steady use have typical latencies in the range of 20-50ms, determined by timing a simple "echo" application from a client hosted in Amazon EC2. Latency will be higher the first time an application is deployed and when an application has not been used recently.
+
+---
+
+## 社内向けFAQ（Internal FAQs）
+
+### 1. いつ顧客に[サービス名]を勧める/勧めないべきですか？
+
+**[サービス名]を勧めるべき顧客**:
+- [customer.mdで定義されたペルソナ]
+- [Phase1のカスタマージャーニーで特定された課題を持つ顧客]
+- [Phase3-Top3の問いに該当する顧客]
+- [Phase5の実現方法で定義された技術スタックを使用している顧客]
+
+**[サービス名]を勧めるべきでない顧客**:
+- [customer.mdで定義されたペルソナ以外]
+- [Phase2のDefineで定義した「常識」に疑問を持たない顧客]
+- [Phase5の実現方法で定義された技術的制約に引っかかる顧客]
+- [で定義された制約条件を超える要求を持つ顧客]
+
+**参考：AWS Lambdaの実例**
+> Mobile backends and any AWS service-embedded scripting uses (such as custom CloudWatch actions or custom video transcoder rules) will use Lambda "under the hood." Customers with these use cases will implicitly select this service.
+>
+> AWS event handlers and batch/cron jobs where the job is readily expressed as an application are good targets for Lambda. Customers with existing applications ("lift and shift"), those who want access to the underlying EC2 instances, who wish to write in languages other than those supported by the service, or who need "stateful" code cannot use Lambda and should target Beanstalk/EC2.
+
+---
+
+### 2. [サービス名]の指針（Tenets）は何ですか？
+
+私たちの指針は、より良いものを知らない限り、以下の通りです：
+
+* **[Phase5のInventで定義した最重要の価値提案]** – [その価値を実現するための指針を1-2文で]
+
+* **[Phase3-Top1の問いに関連する指針]** – [Phase2のDefineで定義した「常識」を覆すための指針を1-2文で]
+
+* **[Phase5の「ブレイクスルー要素」がある場合、そのフレームワークに関連する指針]** – [そのブレイクスルーを実現するための指針を1-2文で]
+
+* **[customer.mdのペルソナに関連する指針]** – [Phase1のカスタマージャーニーで特定された課題を解決するための指針を1-2文で]
+
+* **[とに関連する指針]** – [実装可能性と拡張性を担保するための指針を1-2文で]
+
+**参考：AWS Lambdaの実例**
+> Our tenets, unless you know better ones, are:
+> * **Security without complexity** – Our service will protect customer data from unauthorized access and will be resilient to attack.
+> * **Simple and easy** – We will deliver a "NoOps" service that makes developers' lives easier by handling undifferentiated management and operational overhead for them.
+> * **Scales up and down (to zero)** – Our service will scale customer applications without changes to their code or configuration.
+> * **Cost effective at any scale** – Our service will target fine-grained pay-for-use; developers will not pay for idle time.
+> * **AWS integration** – Our service will benefit from other AWS services by making them easy for application developers to access from within applications.
+> * **Reliable** – Both our service and the applications running on it will provide predictable and reliable operational performance.
+
+---
+
+### 3. 顧客体験を改善するために測定・最適化する運用指標は何ですか？
+
+私たちは、[サービス名]の顧客体験を以下の3つの重要な次元で最適化します：_[Phase3-Top1の問いに関連する指標1]_、_[Phase1のカスタマージャーニーで特定された課題に関連する指標2]_、_[Phase5の新しい価値提案に関連する指標3]_。また、4つ目の指標として[顧客満足度に関連する指標]を監視し、顧客体験を保護します。
+
+**[指標1の名前]**
+[Phase3で算出した定量的な効果を測定する方法。内部指標と顧客に公開する指標を区別]
+
+**[指標2の名前]**
+[Phase1のカスタマージャーニーで特定された課題の解決度合いを測定する方法]
+
+**[指標3の名前]**
+[Phase5の新しい価値提案の実現度合いを測定する方法]
+
+**参考：AWS Lambdaの実例**
+> We will seek to optimize three key dimensions of the customer experience for applications and applications running on Lambda: _latency_, _throughput_, and _availability_, and we will monitor a fourth, jitter, to protect customer experience.
+>
+> **Latency**: We plan to offer a _publicly_ visible measure of latency through a canary client running in EC2 that repeatedly invokes a Lambda-hosted 'echo' application. Monitoring and graphing the resulting latency from the client perspective offers a way to convey to developers the type of latency they will experience when using the service.
+
+---
+
+### 4. [サービス名]はどのようにして顧客のコストを削減できますか？
+
+[サービス名]は、fine-grained（きめ細かい）な[Phase3の価格設定の単位]ベースの価格設定を提供します。[Phase3で算出した削減効果]により、顧客は[Phase1で費やしていた時間・コスト]から[削減後の時間・コスト]に削減できます。
+
+**小〜中規模の顧客**は、[Phase5の「スケールダウン（ゼロまで）」に関する説明]の恩恵を受けます。[Phase1の具体的な状況：利用頻度が低い場合など]でも、[Phase5の新しい価値提案]を犠牲にすることなく、[Phase3の価格設定]で済みます。
+
+**大規模顧客**は、[Phase5の実現方法で記載したスケーラビリティ]の恩恵を受けます。[Phase1のカスタマージャーニーで特定された課題：スパイキーなワークロード、異種混在のワークロードなど]も、[Phase5の新しい価値提案]により効率的に処理でき、[Phase3で算出した削減効果]を実現できます。
+
+[サービス名]はまた、[Phase5で組み合わせたソリューション]を統合することで、[Phase1で要していた運用負荷]を削減し、TCO（総所有コスト）を下げることができます。[customer.mdのペルソナ]にとって、[Phase1の課題：予測不可能な需要、急速な変化など]は大きな課題でしたが、[サービス名]は[Phase5の新しい価値提案]により、[Phase3で算出した定量的な効果]を実現します。
+
+**参考：AWS Lambdaの実例**
+> Lambda offers fine-grained duration-based pricing. Like Amazon S3, it charges customers only for what they actually do with the service. Our pricing approach ensures that customers cannot overprovision or underutilize by design: customers utilize 100% of the computing power they're paying for when they run an application. Small and medium customers will benefit from the "scales to zero" aspect of the service, paying nothing at all for applications that are able to receive requests but not actually executing.
+>
+> Large customers benefit from Lambda's placement engine, which effectively compacts their workloads: Each new request is placed with respect to minimizing the number of instances dedicated to that account (subject to maintaining latency, throughput, and availability goals). Spiky workloads, heterogeneous workloads, and short-lived jobs such as cron or batch applications all use capacity efficiently without any additional IT oversight on the customer's behalf, potentially saving them money through higher utilization as well as reduced IT staffing needs.
+
+---
+
+
+
+
+このフェーズは以下の条件を全て満たした場合に完了とします：
+
+【必須条件：プレスリリース本文（AWS Lambda PR/FAQ形式）】
+[] Phase5で選定した1つの発明についてプレスリリースが執筆されている
+[] 見出し（会社名+サービス名+ローンチ）が明確
+[] サブ見出し（1行の価値提案）が Phase3-Top1 の問いを解決する内容になっている
+[] 第1段落（導入パラグラフ）に以下が含まれている
+ - Phase3-Top1の問いに対する答え（1-2文で簡潔に）
+ - Phase2のDefineで定義した「常識」
+ - Phase5のInventで定義した新しい価値
+ - 技術的な独自性（1文で）
+ - Phase3で算出した定量的な効果
+ - 価格設定（簡潔に）
+ - URLまたは開始方法
+[] 顧客の声が2つ含まれている
+[] 各顧客の声に以下が含まれている
+ - Phase1のペインポイント
+ - Phase3の定量的な効果
+ - Phase5の新しい価値提案による副次的効果
+ - 削減前後の時間・コスト
+[] 「使い方はシンプル」段落に以下が含まれている
+ - Phase1のカスタマージャーニーを逆にたどる形の3-5ステップ（簡潔に）
+ - Phase5で組み合わせたソリューション
+ - customer.mdのペルソナ
+ - Phase3-Top1の問いを解決する方法
+ - 削減前後の時間・コスト
+
+【必須条件：顧客向けFAQ】
+[] 顧客向けFAQが最低15個以上含まれている
+[] FAQが以下の6つのカテゴリに分類されている
+ - 一般（General）：3個
+ - 価格（Pricing）：3個
+ - はじめ方（Getting Started）：3個
+ - [サービス名]の使用（Using [Service Name]）：5個
+ - 制限と制約（Limits and Restrictions）：3個
+ - パフォーマンス（Performance）：3個
+[] 各FAQの回答が具体的で、数値や具体例が含まれている
+[] 「何ができますか？」に対する回答が customer.mdのペルソナのユースケースに基づいている
+[] 価格に関する回答に Phase3のリソース削減効果との比較が含まれている
+[] セキュリティに関する回答が Phase5の実現方法で記載したセキュリティ対策を反映している
+[] 制限に関する回答が Phase5の実現方法で記載した技術的制約を正直に記載している
+
+【必須条件：社内向けFAQ（Internal FAQs）】
+[] 社内向けFAQが最低4つ含まれている
+[] FAQ 1「いつ顧客に[サービス名]を勧める/勧めないべきですか？」に以下が含まれている
+ - 勧めるべき顧客：customer.mdのペルソナ、Phase1の課題、Phase3-Top3の問い
+ - 勧めるべきでない顧客：ペルソナ以外、Phase5の技術的制約、を超える要求
+[] FAQ 2「[サービス名]の指針（Tenets）は何ですか？」に以下が含まれている
+ - Phase5のInventで定義した最重要の価値提案
+ - Phase3-Top1の問いに関連する指針
+ - customer.mdのペルソナに関連する指針
+ - とに関連する指針
+ - 各指針に「より良いものを知らない限り」という前提
+[] FAQ 3「顧客体験を改善するために測定・最適化する運用指標は何ですか？」に以下が含まれている
+ - Phase3-Top1の問いに関連する指標
+ - Phase1のカスタマージャーニーで特定された課題に関連する指標
+ - Phase5の新しい価値提案に関連する指標
+ - 各指標の測定方法（内部指標と顧客に公開する指標の区別）
+[] FAQ 4「[サービス名]はどのようにして顧客のコストを削減できますか？」に以下が含まれている
+ - Phase3の価格設定の単位
+ - Phase3で算出した削減効果
+ - 小〜中規模の顧客への恩恵
+ - 大規模顧客への恩恵
+ - TCO削減の説明
+
+【品質基準：Amazon PR/FAQ形式の遵守】
+[] AWS LambdaのPR/FAQと同様の構造になっている（プレスリリース→顧客向けFAQ→社内向けFAQ）
+[] プレスリリース本文が簡潔で、3-4段落にまとまっている（詳細はFAQに）
+[] 顧客の声が実際のユーザーが言いそうな具体的な表現になっている
+[] FAQが「顧客が実際に持つであろう疑問」に答えている
+[] 社内向けFAQが「チームの意思決定に必要な情報」を提供している
+[] テンプレートの各所に「AWS Lambdaの実例」が参考として記載されている
+
+【品質基準：具体性と定量性】
+[] プレスリリース全体が customer.md で定義されたペルソナに向けて書かれている
+[] 定量的な効果が以下の形で具体的に示されている
+ - 削減時間（週X時間、年間Y時間）
+ - 削減費用（年間Z万円）
+ - 削減率（X%削減）
+ - 投資回収期間（Xヶ月）
+[] 全ての数値が Phase1 と Phase3 のデータに基づいている
+[] 「誰が読んでも同じ認識を持てる」レベルの具体性がある（曖昧な表現が0個）
+
+【品質基準：顧客視点の徹底】
+[] 技術的詳細より、顧客の得られる価値が強調されている
+[] 「なぜこのサービスが必要か」が Phase2 の問いと紐付いて説明されている
+[] 読んだ人が「これは自分のための製品だ」と感じられる内容になっている
+[] ブレイクスルーアイデアの場合、「常識の覆し方」が前面に押し出されている
+
+【品質基準：実装可能性の担保】
+[] サービスの説明が と で実装可能な内容である
+[] 価格設定が Phase3 のリソース削減効果と整合している（投資回収期間が合理的）
+[] セキュリティ・制限の説明が現実的である
+[] 社内向けFAQ「勧めるべきでない顧客」が の制約を反映している
+
+【次フェーズへの準備】
+[] Phase7で事業計画を立てるのに必要な「提供価値」が明確
+[] ターゲット市場規模を推定するための情報が含まれている（顧客向けFAQ「どのような顧客に向いていますか？」）
+[] 成功指標（North Star Metric）につながる行動指標が社内向けFAQ「測定する運用指標」に含まれている
+
+このチェックリストを確認し、全ての項目にチェックが入ったことを宣言してから Phase7 に進んでください。
+
+
+
+
+
+あなたはプロダクトマネージャー兼UXデザイナーです。Phase6で作成したPR/FAQから最も重要な顧客体験を抽出し、モックアップで検証可能な形に落とし込みます。
+
+
+Phase6で作成したPR/FAQの内容を基に、モックアップで仮説検証するべき顧客体験を1つ定義してください。
+
+**選定の優先順位**:
+1. Phase5でブレイクスルーアイデア（🎯マーク付き）を採用した場合は、それを優先的に選択
+2. Phase3-Top1の問いを解決する体験
+3. Phase1のカスタマージャーニーで最も感情スコアが低かった（ペインが大きかった）ステップの改善体験
+
+定義した内容を discovery/output.md の Validate セクションに記載してください。
+
+
+
+## Validate: 検証
+
+### 検証対象の顧客体験
+
+**体験名**: [具体的な体験の名前]
+
+**対象ペルソナ**: [customer.md で定義されたペルソナ名]
+
+**解決する課題**: [Phase3-Top1の問いまたはPhase1の最大ペインポイント]
+
+**Before（現在の体験）**:
+[Phase1のカスタマージャーニーから該当ステップを引用]
+- 所要時間: X時間/Y日
+- 費用: Z円
+- 感情スコア: 😟 2/5
+- 顧客の声: 「[Phase1で記載した実際の声]」
+
+**After（提案する体験）**:
+[Phase6のPR/FAQで説明した新しい体験を3-5ステップで]
+1. [ステップ1] - 所要時間: X分
+2. [ステップ2] - 所要時間: Y分
+3. [ステップ3] - 所要時間: Z分
+...
+
+- 合計所要時間: X分（現在比Y%削減）
+- 費用: Z円（現在比Y%削減）
+- 期待感情スコア: 😊 4-5/5
+
+---
+
+### 検証する仮説
+
+**価値仮説**:
+[customer.mdのペルソナ]は、[Phase3-Top1の問いに関連する課題]に対して、[Phase5の新しい価値提案]を提供すれば、[Phase3で算出した定量的な効果]を達成でき、[Phase6で定義した指標1]が改善されると考える。
+
+**使いやすさ仮説**:
+[customer.mdのペルソナ]は、[提案する体験のステップ数]ステップで[Phase3-Top1の問いを解決する行動]を完了でき、[Phase6のFAQ「導入にどのくらい時間がかかりますか？」の回答]で使い始められると考える。
+
+**魅力度仮説**:
+[customer.mdのペルソナ]は、[Phase5のブレイクスルー要素またはPhase6のPR見出し]を見て、[感情的な反応：驚き、共感、期待など]を示し、[Phase6の顧客の声に近い反応]をすると考える。
+
+---
+
+### モックアップの定義
+
+**モックアップの種類**: [静的画面モック/クリック可能プロトタイプ/ビデオモック]
+
+**モックアップの範囲**:
+[Afterで定義した3-5ステップを以下の形式で]
+
+| 画面番号 | 画面名 | 目的 | 主要UI要素 | ユーザーアクション |
+|---------|--------|------|-----------|------------------|
+| 1 | [画面名] | [この画面で達成すること] | - [要素1]
- [要素2]
- [要素3] | [ユーザーが行う操作] |
+| 2 | [画面名] | [この画面で達成すること] | - [要素1]
- [要素2]
- [要素3] | [ユーザーが行う操作] |
+| 3 | [画面名] | [この画面で達成すること] | - [要素1]
- [要素2]
- [要素3] | [ユーザーが行う操作] |
+
+**デザイン要件**:
+- フィデリティ: [Hi-Fi（高忠実度）/Mid-Fi（中忠実度）/Lo-Fi（低忠実度）]
+- デザインシステム: [使用するUIライブラリやデザインシステム（該当する場合）]
+- 実装しないが見せる機能: [Phase5の全機能のうち、MVP外だがモックで見せる必要があるもの]
+- 強調するブレイクスルー要素: [Phase5でブレイクスルーアイデアを採用した場合、どの要素を視覚的に強調するか]
+
+**モックアップ作成に必要な情報**:
+- ブランドカラー: [メイン色、アクセント色]
+- ターゲットデバイス: [デスクトップ/モバイル/両方]
+- 参考にするデザイン: [Phase4のsolutions.mdで評価した既存ソリューションのうち、UIの参考にするもの]
+
+---
+
+### 検証方法
+
+**検証手法**: [ユーザーインタビュー/アンケート/ユーザビリティテスト/A/Bテスト]
+
+**参加者**:
+- ターゲット人数: X名
+- リクルート条件: [customer.mdのペルソナの特徴を具体的に。例：役職、業界、チーム規模、Phase1の課題を持っているか]
+- 除外条件: [Phase6の社内向けFAQ「勧めるべきでない顧客」に該当する人]
+
+**検証シナリオ**:
+1. **コンテキスト設定**: 「あなたは[customer.mdのペルソナの状況]で、[Phase1の課題]に直面しています」
+2. **モックアップ提示**: [モックアップをどのように見せるか：順番、説明の有無]
+3. **観察ポイント**:
+ - [価値仮説の検証項目]
+ - [使いやすさ仮説の検証項目]
+ - [魅力度仮説の検証項目]
+4. **質問リスト**:
+ - 「この体験のどの部分が最も価値があると感じましたか？」
+ - 「[Phase5のブレイクスルー要素]について、どう思いましたか？」
+ - 「[Phase3で算出した削減時間・費用]のために、[Phase6の価格]を支払いますか？」
+ - 「どのステップが分かりにくかったですか？」
+ - 「[Phase1で記載した顧客の声]と比べて、この体験は改善されていますか？」
+
+---
+
+### 成功基準
+
+**定量基準**:
+- [ ] 価値仮説: X%以上の参加者が「[Phase3の定量的な効果]が達成できそう」と回答
+- [ ] 使いやすさ仮説: X%以上の参加者が「[Afterのステップ数]ステップで完了できる」と感じる
+- [ ] 魅力度仮説: X%以上の参加者が「試してみたい」または「導入を検討したい」と回答
+- [ ] WTP（支払意思額）: X%以上の参加者が[Phase6の価格]以上の支払意思を示す
+
+**定性基準**:
+- [ ] 参加者が[Phase5のブレイクスルー要素]に「驚き」または「なるほど」という反応を示す
+- [ ] Phase1の「顧客の声」と同様のペインが、Afterで解決されていることを参加者が認識する
+- [ ] 「既存の[Phase4のsolutions.md記載のソリューション]と何が違うのか」を参加者が言語化できる
+- [ ] Phase6のPRの見出し（1行の価値提案）を聞いて、参加者が興味を示す
+
+**撤退基準（Pivot判断）**:
+以下の場合、Phase2に戻り問いの再定義、またはPhase5に戻り発明の再検討を行う：
+- [ ] 50%以上の参加者が「[Phase3-Top1の問いに関連する課題]は重要でない」と回答
+- [ ] 70%以上の参加者が「使い方が分からない」と回答
+- [ ] 80%以上の参加者が[Phase6の価格]に対してWTPを示さない
+- [ ] Phase5のブレイクスルーアイデアが「意味が分からない」「不要」と評価される
+
+---
+
+### 次のアクション
+
+検証完了後、以下の情報を discovery/output.md の Validate セクションに追記してください：
+
+**検証結果サマリー**:
+- 実施日: YYYY/MM/DD
+- 参加者数: X名
+- 成功基準達成率: X/Y項目
+- 主要インサイト（箇条書き3-5個）
+- 学習した内容（仮説と異なった点）
+- 次のステップ（実装Go/Pivot/追加検証）
+
+
+
+
+このフェーズは以下の条件を全て満たした場合に完了とします：
+
+【必須条件：検証対象の定義】
+[] 検証対象の顧客体験が1つ明確に定義されている
+[] Phase6のPR/FAQから論理的に導出された体験が選ばれている
+[] ブレイクスルーアイデアが存在する場合は優先的に選定されている
+[] Before（現在の体験）がPhase1のカスタマージャーニーから具体的に引用されている
+[] After（提案する体験）がPhase6のPR/FAQの「使い方はシンプル」段落と整合している
+[] Before→Afterの改善が定量的に示されている（時間、費用、感情スコア）
+
+【必須条件：仮説の定義】
+[] 価値仮説が明確に記載されている（Phase3の定量効果と紐付いている）
+[] 使いやすさ仮説が明確に記載されている（ステップ数、導入時間が具体的）
+[] 魅力度仮説が明確に記載されている（Phase5のブレイクスルー要素またはPR見出しと紐付いている）
+[] 各仮説が「検証可能」である（Yes/Noまたは数値で判断できる）
+[] 仮説がcustomer.mdのペルソナに紐付いている
+
+【必須条件：モックアップの定義】
+[] モックアップの範囲が画面単位で定義されている（最低3画面）
+[] 各画面に「目的」「主要UI要素」「ユーザーアクション」が記載されている
+[] デザイン要件（フィデリティ、デザインシステム、デバイス）が明確
+[] Phase5で定義した機能のうち、モックアップで見せる範囲が明確
+[] モックアップ作成に必要な情報（色、デバイス、参考デザイン）が揃っている
+[] ブレイクスルーアイデアがある場合、どの画面・要素で強調するかが明記されている
+
+【必須条件：検証方法】
+[] 検証手法が明確（インタビュー/テスト/アンケートなど）
+[] 参加者のリクルート条件がcustomer.mdのペルソナに基づいて具体的
+[] 検証シナリオが4つの要素（コンテキスト設定、提示方法、観察ポイント、質問）で構成されている
+[] 質問リストが5つ以上あり、3つの仮説を検証できる内容になっている
+[] Phase1の顧客の声、Phase3の削減効果、Phase5のブレイクスルー要素に関する質問が含まれている
+
+【必須条件：成功基準】
+[] 定量基準が4つ以上定義されている（価値、使いやすさ、魅力度、WTP）
+[] 各定量基準に具体的な%目標が設定されている
+[] 定性基準が4つ以上定義されている
+[] 撤退基準（Pivot判断）が3つ以上定義されている
+[] Phase6の価格設定とWTP基準が整合している
+
+【品質基準：Phase1-6との一貫性】
+[] 検証対象がPhase3-Top1の問いまたはPhase1の最大ペインポイントに対応している
+[] Before→Afterの改善がPhase3で算出した削減効果と一致している
+[] モックアップの画面がPhase6の「使い方はシンプル」の3-5ステップと対応している
+[] 検証シナリオがPhase1のカスタマージャーニーの文脈を反映している
+[] 成功基準がPhase6の社内向けFAQ「測定する運用指標」と整合している
+
+【品質基準：実行可能性】
+[] モックアップの範囲がで実装可能
+[] デザイン要件がで定義された技術スタックで実現可能
+[] リクルート条件が現実的で、参加者を見つけられる
+[] 検証シナリオが1名あたり30-60分で完了できる内容
+[] 質問が誘導的でなく、客観的なフィードバックが得られる内容
+
+【品質基準：仮説検証の明確さ】
+[] 各仮説が「何を学びたいか」が明確（機能の有無、価格、使いやすさなど）
+[] 成功基準が達成された場合の「次のステップ」が明確（実装Go）
+[] 撤退基準に該当した場合の「次のステップ」が明確（Phase2/5に戻る）
+[] 定量基準と定性基準が補完的で、両面から仮説を検証できる
+[] ブレイクスルーアイデアの場合、「驚き」が伝わるかを検証する項目がある
+
+【品質基準：モックアップの品質】
+[] 画面遷移の流れが論理的で、ユーザーが迷わない設計
+[] 各画面の「主要UI要素」が具体的で、モックアップ作成者が理解できる
+[] Phase5のブレイクスルー要素が視覚的に強調される設計
+[] 「実装しないが見せる機能」が明記され、期待値調整ができる
+[] 参考デザインがPhase4で評価した既存ソリューションから選ばれている
+
+【次フェーズへの準備（オプション）】
+[] 検証後にPhase8（実装計画）に進むための情報が揃っている
+[] モックアップの画面定義が開発チームに渡せるレベルで具体的
+[] 成功基準がPhase6の社内向けFAQ「指針（Tenets）」と整合している
+[] 検証結果を記録するテンプレート（検証結果サマリー）が用意されている
+
+このチェックリストを確認し、全ての項目にチェックが入ったことを宣言してから、モックアップ作成または検証実施に進んでください。
+
+**モックアップ作成の推奨ツール**:
+- v0.dev: React/Next.jsベースのモダンUIを素早く生成
+- Figma: 詳細なデザインとプロトタイピング
+- PowerPoint/Keynote: Lo-Fiモックやビデオモック
+- Loom: 画面操作を説明するビデオモック
+
+**注**: Phase7で定義したモックアップ定義を、v0-mock-builder-prompt.md に渡すことで、AI支援でモックアップを構築できます。
+
+
+
\ No newline at end of file
diff --git a/yourwork_1shot/sample/ai_development_tool/customer.md b/yourwork_1shot/sample/ai_development_tool/customer.md
new file mode 100644
index 0000000..dd71861
--- /dev/null
+++ b/yourwork_1shot/sample/ai_development_tool/customer.md
@@ -0,0 +1,14 @@
+## ターゲットの目的、背景、属性
+
+### **目的**
+スタートアップから急成長企業のCTOが、限られた開発リソースの中で**持続可能な開発生産性向上**と**競争優位性の確立**を実現すること。単なる効率化ではなく、品質を損なうことなく市場投入速度を加速し、PMFの実現とスケーラブルな技術基盤の構築を両立させる。
+
+### **背景（社内的状況）**
+先週の経営会議で、CEOから「競合が2週間でリリースした機能を、うちは1ヶ月かかっている」と指摘された。その夜、エンジニアリングマネージャーから「3名のシニア開発者が転職を検討している。理由は単純作業の多さと、技術にチャレンジできないこと」というSlackが届いた。採用チームからは「年収1,200万円でも内定辞退が3件連続」、CFOからは「増員は難しい。今いるメンバーでなんとかならないか」とプレッシャーがかかる。開発チーム内では、シニア2名、ミドル5名、ジュニア8名という構成で、コードレビューの待ち時間が平均2日かかっており、シニアがボトルネックになっている。スプリント振り返りでは見積もりの30%オーバーが常態化し、プロダクトマネージャーから「いつリリースできるか読めない」という声が噴出している。競合がAI開発ツールを導入している噂を聞き、取締役会で「なぜうちは導入しないのか」と質問されたが、セキュリティチームからは「外部サービスにコードを送信するリスク」、法務からは「知的財産の保護」という懸念が寄せられ、判断できずにいる。
+
+### **属性**
+- **規模**: 開発チーム10～100名のスタートアップ・急成長企業
+- **フェーズ**: シード～シリーズAの成長期企業
+- **課題**: 人材確保困難、開発速度とコード品質のバランス、技術的負債の蓄積懸念
+- **意思決定権限**: 技術投資に関する最終決定権を持つCTO・VPE
+- **予算制約**: コスト効果を明確に示す必要がある環境
diff --git a/yourwork_1shot/sample/ai_development_tool/output.md b/yourwork_1shot/sample/ai_development_tool/output.md
new file mode 100644
index 0000000..0cb03ff
--- /dev/null
+++ b/yourwork_1shot/sample/ai_development_tool/output.md
@@ -0,0 +1,779 @@
+# Working Backwards Document
+
+## Listen: カスタマージャーニー
+
+目的を達成できた顧客（スタートアップから急成長企業のCTO）が、AI開発支援ツールを導入して持続可能な開発生産性向上を実現するまでの道のり。
+
+| 行動ステップ | 所要時間 | 費用 | 使用ツール | 感情（1-5） | 課題 | 顧客の声 |
+|------------|---------|------|-----------|-----------|------|---------|
+| 1. 課題認識と情報収集 | 2週間 | 0円 | Google検索、Tech記事、Slack/Discord | 😟 2 | 競合に後れを取り、社内からもプレッシャー。選択肢が多すぎて何が自社に合うのか分からない | 「競合が2週間でリリースした機能を、うちは1ヶ月かかっている。取締役会でなぜAI開発ツールを導入しないのかと質問されたが、どれを選べばいいのか...」 |
+| 2. 複数ツールのトライアル検証 | 3週間 | 各ツール約2万円/月 × 3ツール = 6万円 | GitHub Copilot、Cursor、Amazon Q Developer | 😰 3 | 各ツールを並行検証する工数が取れない。シニアメンバーはレビューで忙しく、ジュニアに任せると判断軸が曖昧 | 「どのツールも良さそうだが、3つ同時に試す余裕がない。シニアは『レビュー待ちが2日もあるのに、さらにツール検証しろと?』と不満を言っている」 |
+| 3. セキュリティ・法務レビュー | 4週間 | 0円 | 社内レビュー会議、ベンダー資料確認 | 😓 2 | セキュリティチームから「外部サービスにコードを送信するリスク」、法務から「知的財産の保護」の懸念。判断材料が不足 | 「法務が『コードが外部に漏れたらどうするんだ』と言ってきて、導入が止まってしまった。AWS系なら信頼できるのか?それとも全部ダメなのか?」 |
+| 4. 予算承認と社内説得 | 2週間 | 0円 | 財務資料作成、経営会議 | 😟 3 | CFOから「増員は難しい。今いるメンバーでなんとかならないか」とプレッシャー。ROIを定量的に示せない | 「年間200-300万円の投資をCFOに説明するために、投資回収期間を計算したが、前例がないから承認してもらえるか不安だ」 |
+| 5. 段階的ロールアウト | 4週間 | 選定ツール 月額40万円 × 1ヶ月 = 40万円 | Cursor（選定したツール） | 😐 4 | まずシニア2名で試験導入したが、全員への展開タイミングが難しい。ジュニアへの教育方法も不明確 | 「シニアは生産性が上がったと言うが、ジュニアは使い方が分からず混乱している。全員が使いこなせるまでどれくらいかかるのか?」 |
+| 6. 効果測定と改善 | 8週間 | 月額40万円 × 2ヶ月 = 80万円 | Cursor、GitHub Analytics、Jira | 😊 4 | 効果は出始めているが、定量的な測定方法が確立していない。スプリント見積もりの精度向上に時間がかかる | 「コードレビュー時間が25%減ったのは実感できるが、CEOに報告するためのデータが揃わない。開発速度が何%向上したのか明確に言えない」 |
+| 7. 全社展開と文化定着 | 12週間 | 月額40万円 × 3ヶ月 = 120万円 | Cursor、社内ベストプラクティス共有 | 😀 5 | ツール依存による基礎スキル低下の懸念。AIが生成したコードの品質管理方法の確立が必要 | 「開発速度は40-50%向上し、転職を検討していたシニア3名も残ってくれた。でも、ジュニアがAIに頼りすぎて基礎を学ばないのでは?という新たな懸念が...」 |
+
+**合計費用**: 年間約480万円（月額40万円 × 12ヶ月）
+**合計所要時間**: 約33週間（約8ヶ月）
+
+### 非効率な行動の特定
+
+1. **複数ツールの逐次的トライアル検証**（3週間）：各ツールを順番に試すため、比較判断に時間がかかる
+2. **セキュリティ・法務レビューの長期化**（4週間）：判断材料が不足し、承認プロセスが停滞
+3. **段階的ロールアウトと効果測定の分離**（12週間）：導入と効果測定が別フェーズで、迅速なフィードバックループが回らない
+4. **ツール選定と組織文化変革の分離**：技術的な導入と、チーム全体の働き方改革が連動していない
+
+---
+
+## Define: 問いの定義
+
+顧客の行動を分析し、「当たり前」を疑う問いを立てる。
+
+| 行動ステップ | 問いの種類 | 問い | 現在の制約 |
+|------------|-----------|------|-----------|
+| 1. 課題認識と情報収集 | 省略型 | なぜ事前調査せずにツール導入を決定できないのか? | 各ツールの情報が散在し、自社の状況に合うかの判断材料が不足している |
+| 1. 課題認識と情報収集 | 統合型 | なぜ情報収集と競合比較は同時にできないのか? | 比較軸が明確でなく、各ツールの特性を理解するのに時間がかかる |
+| 2. 複数ツールのトライアル検証 | 省略型 | なぜトライアルせずに最適なツールを選定できないのか? | 実際に使ってみないと自社の開発フローに合うか分からない。ドキュメントだけでは判断できない |
+| 2. 複数ツールのトライアル検証 | 統合型 | なぜ複数ツールのトライアルと比較評価は同時にできないのか? | 3つのツールを並行検証する工数が取れず、シニアメンバーは既存業務で手一杯 |
+| 3. セキュリティ・法務レビュー | 省略型 | なぜ事前のセキュリティ基準定義なしにツール導入を進められないのか? | セキュリティチームと法務の懸念点が事前に明確になっておらず、都度判断が必要 |
+| 3. セキュリティ・法務レビュー | 統合型 | なぜツール選定とセキュリティレビューは同時にできないのか? | ツール選定後にセキュリティ懸念が発覚し、最初から選び直しになるリスクがある |
+| 4. 予算承認と社内説得 | 省略型 | なぜ定量的なROI試算なしに予算承認を得られないのか? | 前例がなく、投資対効果を数値で示せないため、CFOが承認をためらう |
+| 4. 予算承認と社内説得 | 統合型 | なぜツール選定と予算承認プロセスは同時にできないのか? | ツールを決めてから予算を取りに行くため、承認が下りなければ最初からやり直し |
+| 5. 段階的ロールアウト | 省略型 | なぜ段階的導入せずに全員同時に展開できないのか? | ジュニアへの教育方法が確立しておらず、全員が混乱するリスクがある |
+| 5. 段階的ロールアウト | 統合型 | なぜロールアウトと教育プログラムは同時にできないのか? | まず使ってみてから教え方を考えるため、ジュニアが使い方を理解するまで時間がかかる |
+| 6. 効果測定と改善 | 省略型 | なぜ効果測定の仕組みなしにツール導入を開始できないのか? | 何を測定すべきか事前に定義されておらず、後から「データが取れていない」と気づく |
+| 6. 効果測定と改善 | 統合型 | なぜ導入と効果測定は同時にできないのか? | まず使ってから効果を測る形なので、リアルタイムでの改善サイクルが回らない |
+| 7. 全社展開と文化定着 | 省略型 | なぜ文化変革の計画なしにツール展開を完了できないのか? | ツール依存による基礎スキル低下など、組織文化への影響が見過ごされがち |
+| 7. 全社展開と文化定着 | 統合型 | なぜツール導入と組織文化の変革は同時にできないのか? | 技術的な導入が先行し、チームの働き方や価値観の変化は後から考えることになる |
+
+### 追加の深掘り問い
+
+| 行動の組み合わせ | 問いの種類 | 問い | 現在の制約 |
+|----------------|-----------|------|-----------|
+| 2→3（トライアル→レビュー） | 統合型 | なぜツールのトライアルとセキュリティ評価は同時にできないのか? | トライアル後にセキュリティ問題が発覚すると、選定がやり直しになる |
+| 4→5（予算承認→導入） | 省略型 | なぜ予算承認を待たずにパイロット導入を開始できないのか? | 承認前に勝手に導入すると、ガバナンス違反になる可能性がある |
+| 5→6→7（導入→測定→定着） | 統合型 | なぜ導入・効果測定・文化変革は同時に進行できないのか? | 各フェーズが独立しており、前のフェーズが完了しないと次に進めない直列的なプロセス |
+
+---
+
+### Top 3 重要課題
+
+全17個の問いを評価した結果、以下のTop3を選定：
+
+| 順位 | 問い | リソース削減効果 | 頻度 | 合計スコア | 選定理由 |
+|------|------|----------------|------|-----------|---------|
+| **1位** | なぜ複数ツールのトライアルと比較評価は同時にできないのか? | **5点**（週15時間削減 = 年間780時間）| **5点**（ツール選定時は毎日直面） | **10点** | CTOとシニアメンバーが最も頻繁に直面する課題。3週間 × 3名 = 約180時間を、リアルタイム比較により1週間 × 3名 = 60時間に短縮可能。年間複数回のツール評価を考慮すると、年間780時間（約100営業日）の削減が見込める。シニア時給5,000円換算で約390万円の削減効果。 |
+| **2位** | なぜ導入・効果測定・文化変革は同時に進行できないのか? | **5点**（12週間→4週間 = 8週間削減 = 年間320時間）| **4点**（ツール導入時に必ず発生、年3-4回） | **9点** | ツール導入プロジェクト全体（ステップ5-7）の期間を67%削減可能。現状12週間かかるプロセスを、統合的アプローチで4週間に短縮。チーム全体（10名）が関与するため、10名 × 8週間 = 800時間の削減。さらに、早期の効果確認により投資判断が迅速化し、失敗時の損失を最小化できる。 |
+| **3位** | なぜツール選定とセキュリティレビューは同時にできないのか? | **4点**（4週間削減 = 月160万円の機会損失回避）| **4点**（新ツール導入時に毎回発生、年3-4回） | **8点** | セキュリティレビューの4週間（ステップ3）を並行化することで、市場投入の遅れ（月160万円の機会損失）を回避。さらに、選定後にセキュリティ問題で選び直すリスク（2週間 × 3名 = 120時間の無駄）を排除。年間3-4回の新ツール評価で、合計480-640万円の機会損失回避が可能。 |
+
+#### スコアリング詳細
+
+**リソース削減効果の評価基準**
+- 5点: 週10時間以上削減 または 月100万円以上の削減/機会損失回避
+- 4点: 週5-10時間削減 または 月50-100万円の削減
+- 3点: 週3-5時間削減 または 月20-50万円の削減
+- 2点: 週1-3時間削減 または 月10-20万円の削減
+- 1点: 週1時間未満削減 または 月10万円未満の削減
+
+**頻度の評価基準**
+- 5点: 毎日直面する課題（日次）
+- 4点: 週に3回以上直面（週次頻繁）
+- 3点: 週に1回程度直面（週次）
+- 2点: 月に2-3回直面（月次頻繁）
+- 1点: 月に1回程度直面（月次）
+
+**その他の高スコア問い（4位以下）**
+- 4位: 「なぜトライアルせずに最適なツールを選定できないのか?」（リソース4点 × 頻度4点 = 8点）
+- 5位: 「なぜ効果測定の仕組みなしにツール導入を開始できないのか?」（リソース4点 × 頻度3点 = 7点）
+
+---
+
+## Invent: 発明
+
+Phase 3で選定したTop 3の問いに対して、既存ソリューションの組み合わせと独自の価値を加えた発明を提案する。
+
+---
+
+### 発明1: **DevMatch** - AI開発ツール即時比較プラットフォーム（ブレイクスルーアイデア）
+
+**解決する問い**: Phase3-1位「なぜ複数ツールのトライアルと比較評価は同時にできないのか?」
+
+**組み合わせるソリューション**:
+- **Cursor のマルチモデルUI**（難易度: 5）: Claude、GPT-4など複数のAIモデルを1つのインターフェースで切り替えられる仕組み
+- **GitHub Copilot のIDE統合**（難易度: 10 → 簡易版で3に削減）: VS Code拡張機能として実装し、既存のワークフローに統合
+- **Amazon Q の比較評価機能**（難易度: 10 → コンセプトのみ採用で1）: セキュリティスコア、コード品質スコアなどの定量評価
+
+**新しい価値提案**:
+従来、CTOは「3週間かけて3つのツールを順番に試す」という非効率なプロセスを強いられていた。DevMatchは、**1つのVS Code拡張機能の中で、複数のAI開発ツール（GitHub Copilot風、Cursor風、Amazon Q風）を同じコードベースで同時に試せる**体験を提供する。タブを切り替えるだけで「このツールならどう提案するか?」を瞬時に比較でき、**3週間のプロセスを3日に短縮**する。
+
+**ブレイクスルー要素**:
+- **時間軸の操作**: 通常「順番に試す→比較する→決める」という直列プロセスを、「同時に試しながら比較し、リアルタイムで決める」という並列プロセスに変換
+- **異業種転用**: ECサイトの「商品比較機能」のUXをB2B開発ツール選定に適用。Amazon.comで3つの商品を並べて比較するように、3つのAIツールの提案を並べて比較できる
+
+**合計難易度**: 9/10（Cursor風UI: 5 + GitHub Copilot風統合の簡易版: 3 + 比較評価UI: 1）
+
+**実装期間**: 5.5ヶ月（6ヶ月制約内に収まる）
+
+**実現方法**:
+1. **VS Code拡張機能の開発**（1.5ヶ月）: TypeScript/JavaScript、VS Code Extension APIを使用。既存技術で実装可能
+2. **マルチLLM統合レイヤー**（1ヶ月）: Claude API、OpenAI API、AWS Bedrockを統合し、統一インターフェースで呼び出せるバックエンドAPI（Node.js + AWS Lambda）
+3. **サイドバイサイド比較UI**（1.5ヶ月）: 3カラムレイアウトで、同じプロンプトに対する3つのAIの提案を並列表示。ユーザーは各提案に「👍/👎」で評価でき、スコアが蓄積される
+4. **定量評価ダッシュボード**（1ヶ月）: コード品質（cyclomatic complexity）、セキュリティスコア（既存のlinterを活用）、レスポンス速度を自動計測し、グラフ表示
+5. **テスト・デバッグ**（0.5ヶ月）
+
+**価格設定**: 月額$50/ユーザー（3つの AI APIコストを含む）
+
+**制約・トレードオフ**:
+- 各AIツールの「完全な再現」ではなく、「コア機能の比較可能な実装」に留まる
+- 3つ以上のツールを同時比較すると認知負荷が高まるため、最大3つに制限
+- リアルタイム比較のため、各AIのレスポンス速度がUXに直結する
+
+---
+
+### 発明2: **FlowSync** - ツール導入と効果測定の統合プラットフォーム（ブレイクスルーアイデア）
+
+**解決する問い**: Phase3-2位「なぜ導入・効果測定・文化変革は同時に進行できないのか?」
+
+**組み合わせるソリューション**:
+- **Cursor のチーム機能**（難易度: 5）: チーム全体でのツール利用状況を可視化
+- **Devin のSlack連携**（難易度: 10 → コンセプトのみ採用で2）: 進捗報告、効果のリアルタイム通知をSlackに送信
+- **GitHub Copilot の効果測定ロジック**（難易度: 10 → 簡易版で3）: GitHub Analyticsと連携し、コード生成速度やレビュー時間を測定
+
+**新しい価値提案**:
+従来、ツール導入（ステップ5: 4週間）→効果測定（ステップ6: 8週間）→文化定着（ステップ7: 12週間）という**24週間の直列プロセス**が必要だった。FlowSyncは、これらを**4週間の並列プロセス**に変換する。ツールを使い始めた瞬間から、開発速度、コードレビュー時間、エンジニア満足度がリアルタイムでダッシュボードに表示され、毎週Slackに「今週は先週比で開発速度が12%向上しました🎉」と自動報告される。これにより、**投資判断を早期化し、失敗時の損失を最小化**できる。
+
+**ブレイクスルー要素**:
+- **時間軸の操作**: 通常「導入完了後に測定を開始」するプロセスを、「導入と同時に測定も開始」に変更。さらに「文化変革を後から考える」のではなく、「効果の可視化により自然に文化が変わる」設計
+- **感情の逆流**: ネガティブな「監視されている」感覚をポジティブな「成長が可視化される」体験に変換。ゲーミフィケーション要素（週間MVPエンジニア発表など）で楽しさを追加
+
+**合計難易度**: 10/10（ギリギリ実装可能）
+
+**実装期間**: 6ヶ月（制約の上限）
+
+**実現方法**:
+1. **データ収集エージェント**（2ヶ月）: GitHub API、Jira API、VS Code Telemetryから開発メトリクスを収集。AWS Lambda + DynamoDBでデータ蓄積
+2. **リアルタイム分析エンジン**（2ヶ月）: 収集したデータを分析し、開発速度の変化率、コードレビュー時間の短縮率を計算。AWS Kinesis + Lambda for Streamingを使用
+3. **Slack通知・ダッシュボード**（1.5ヶ月）: Slack Webhookで週次レポートを自動送信。React + AWS Amplifyでダッシュボード構築
+4. **チーム文化スコア算出**（0.5ヶ月）: エンジニアのSlack投稿の感情分析（AWS Comprehend）により、満足度を自動推定
+
+**価格設定**: 月額$30/ユーザー
+
+**制約・トレードオフ**:
+- GitHub、Jira、Slackなど既存ツールとの統合が前提。これらを使っていない企業には不向き
+- 感情分析の精度は完璧ではなく、あくまで「参考指標」として扱う必要がある
+- プライバシー懸念: エンジニアの活動を測定することへの抵抗感に配慮が必要
+
+---
+
+### 発明3: **SecureSelect** - セキュリティ評価を統合したツール選定支援サービス（通常の発明）
+
+**解決する問い**: Phase3-3位「なぜツール選定とセキュリティレビューは同時にできないのか?」
+
+**組み合わせるソリューション**:
+- **Amazon Q のセキュリティ評価機能**（難易度: 10 → 簡易版で5）: ツールのセキュリティスコアを自動評価
+- **GitHub Copilot のコンプライアンスチェック**（難易度: 10 → コンセプトのみ採用で2）: SOC2、GDPR等のコンプライアンス要件との適合性を評価
+- **Cursor のコード分析機能**（難易度: 5 → 簡易版で3）: ツールが生成したコードのセキュリティ脆弱性を静的解析
+
+**新しい価値提案**:
+従来、CTOは「ツールを選んでから→セキュリティチームにレビュー依頼→問題発覚で選び直し」という**6週間の無駄なループ**に陥っていた。SecureSelectは、AIツール選定の最初から、各ツールの**セキュリティスコア、コンプライアンス適合度、データ保護レベル**を一覧表示し、「セキュリティチームの承認が得やすいツール」を優先的に推薦する。さらに、トライアル期間中に生成されたコードを自動的にセキュリティスキャンし、「このツールは脆弱なコードを生成しやすい」という警告をリアルタイムで出す。これにより、**4週間のセキュリティレビュー期間を1週間に短縮**できる。
+
+**合計難易度**: 10/10（ギリギリ実装可能だが、優先度を検討すべき）
+
+**実装期間**: 6ヶ月
+
+**実現方法**:
+1. **セキュリティ評価データベース構築**（2ヶ月）: 主要AI開発ツールのセキュリティ認証（SOC2、ISO27001等）、データ保護ポリシー、過去のインシデント履歴を収集・構造化
+2. **自動スキャンエンジン**（2.5ヶ月）: Snyk、SonarQube等の既存セキュリティツールと統合し、AIが生成したコードを自動スキャン。AWS Lambda + Step Functionsで実装
+3. **レポート生成・推薦システム**（1ヶ月）: セキュリティチーム向けのレポートを自動生成。「このツールはSOC2認証済み、過去12ヶ月でインシデント0件、あなたの組織のセキュリティ基準を満たしています」という形で説得材料を提供
+4. **テスト・デバッグ**（0.5ヶ月）
+
+**価格設定**: 初期評価$5,000 + 月額$100/ユーザー（セキュリティスキャンコストを含む）
+
+**制約・トレードオフ**:
+- セキュリティ評価データの鮮度維持にコストがかかる（各ツールの最新情報を追跡する必要がある）
+- 企業ごとにセキュリティ要件が異なるため、カスタマイズが必要
+- 「セキュリティスコアが高い=100%安全」ではないため、過信を防ぐ注意喚起が必要
+
+---
+
+### 発明4: **CodeSwitch** - マルチツール切り替え型AI開発環境（ブレイクスルーアイデア）
+
+**解決する問い**: Phase3-1位「なぜ複数ツールのトライアルと比較評価は同時にできないのか?」（発明1の別アプローチ）
+
+**組み合わせるソリューション**:
+- **Cursor のマルチモデルUI**（難易度: 5）
+- **Devin のタスク理解・実行エンジン**（難易度: 10 → コンセプトのみ採用で3）: 「このタスクにはどのツールが最適か?」をAIが自動判断
+- **GitHub Copilot のコンテキスト理解**（難易度: 10 → 簡易版で2）
+
+**新しい価値提案**:
+DevMatch（発明1）が「人間が3つのツールを比較する」アプローチだったのに対し、CodeSwitchは**AIが自動的にタスクに最適なツールを選択し、シームレスに切り替える**。例えば、「CRUD実装→GitHub Copilot風」「AWS SDK統合→Amazon Q風」「複雑なリファクタリング→Cursor風」と、タスクの性質に応じて最適なAIモデルが自動選択される。開発者は「どのツールを使うか?」を考える必要がなく、**常に最高のAI支援を自動的に受けられる**。
+
+**ブレイクスルー要素**:
+- **AI/自動化の創造的活用**: 単なる「ツール比較」を超えて、「AIがAIツールを選ぶ」というメタレベルの自動化。人間にはできない「瞬時に最適なツールを判断する」能力を実現
+- **制約の武器化**: 「1つのツールを選ばなければならない」という制約を逆手に取り、「全てのツールの良いとこ取りをする」という価値に変換
+
+**合計難易度**: 10/10
+
+**実装期間**: 6ヶ月
+
+**実現方法**:
+1. **タスク分類エンジン**（2ヶ月）: 開発者が書いているコードのコンテキスト（ファイル名、コメント、既存コード）から、「CRUD実装」「インフラ構築」「リファクタリング」などのタスク種別を推定。Claude/GPT-4を使用した分類器を構築
+2. **ツール選択ルールエンジン**（1.5ヶ月）: タスク種別ごとに最適なAIモデル/プロンプトを定義。例: CRUD→GitHub Copilot風のシンプルな提案、AWS→Amazon Q風の詳細な説明付き提案
+3. **シームレス切り替えUI**（2ヶ月）: ユーザーは単一のインターフェースを使うが、裏側では異なるAIモデル/プロンプトが切り替わる。VS Code拡張機能として実装
+4. **学習・改善機能**（0.5ヶ月）: ユーザーが選択した提案を学習し、「このユーザーは複雑なタスクでもシンプルな提案を好む」などの傾向を把握
+
+**価格設定**: 月額$60/ユーザー（複数のAI APIコストを含む、DevMatchより高価格だが自動化の価値を反映）
+
+**制約・トレードオフ**:
+- AIによる自動選択が100%正確ではないため、ユーザーが手動で切り替えられるオプションも必要
+- 複数のAI APIを常時利用するため、コストが高くなる（価格設定に反映）
+- 「AIがAIを選ぶ」というコンセプトが理解されにくい可能性あり（マーケティングが重要）
+
+---
+
+### 発明5: **PairPilot** - ペアプログラミング型AI開発支援（ブレイクスルーアイデア）
+
+**解決する問い**: Phase3-2位「なぜ導入・効果測定・文化変革は同時に進行できないのか?」（発明2の別アプローチ）
+
+**組み合わせるソリューション**:
+- **Cursor のチャット・対話機能**（難易度: 5）
+- **Devin の進捗報告・Slack連携**（難易度: 10 → 簡易版で2）
+- **GitHub Copilot のリアルタイム提案**（難易度: 10 → コンセプトのみ採用で2）
+
+**新しい価値提案**:
+従来のAI開発ツールは「コードを提案する道具」だったが、PairPilotは**AIを「チームメンバー」として扱う**体験を提供する。開発者がコードを書くと、AIが「これはXXのパターンですね。YYの方法もありますが、どちらにしますか?」と質問し、対話しながらコードを共同で作り上げる。さらに、AIが「今日は3つの機能を実装しましたね。明日は残りのテストを書きましょうか?」と振り返りと計画を提案することで、**ツール導入と同時に文化変革（ペアプロの習慣化）が自然に起こる**。
+
+**ブレイクスルー要素**:
+- **異業種転用**: 教育現場の「対話型学習（ソクラテス・メソッド）」をAI開発ツールに適用。AIが一方的に答えを与えるのではなく、質問を通じて開発者の思考を促す
+- **感情の逆流**: 「AIに仕事を奪われる」というネガティブな感情を、「AIと協働する楽しさ」というポジティブな体験に変換
+
+**合計難易度**: 9/10
+
+**実装期間**: 5.5ヶ月
+
+**実現方法**:
+1. **対話エンジン**（2.5ヶ月）: Claude/GPT-4を使用し、「質問する→開発者の回答を理解→次の質問/提案を生成」という対話フローを実装。Chain-of-Thoughtプロンプトを活用
+2. **コンテキスト記憶機能**（1.5ヶ月）: 過去の対話履歴、実装したコード、開発者の好みを記憶し、パーソナライズされた対話を実現。Vector DB（Pinecone）を使用
+3. **振り返り・計画提案機能**（1ヶ月）: 1日の終わりに「今日の成果」をサマリーし、翌日のタスクを提案。GitHub Issuesとの統合
+4. **VS Code統合・UI開発**（0.5ヶ月）
+
+**価格設定**: 月額$40/ユーザー
+
+**制約・トレードオフ**:
+- 対話型のため、「すぐに答えが欲しい」という急いでいる開発者には不向き
+- AIとの対話が冗長になりすぎないよう、バランス調整が重要
+- チーム全体が「AIとペアプロする」文化に適応する必要がある（変化への抵抗が予想される）
+
+---
+
+## 発明の比較と推奨
+
+| 発明 | 解決する問い | 合計難易度 | 実装期間 | ブレイクスルー度 | 市場適合性 | 推奨度 |
+|------|------------|-----------|---------|----------------|-----------|--------|
+| 1. DevMatch | 1位（トライアル統合） | 9/10 | 5.5ヶ月 | ★★★ 高 | ★★★ 高 | ⭐⭐⭐ |
+| 2. FlowSync | 2位（導入・測定統合） | 10/10 | 6ヶ月 | ★★★ 高 | ★★ 中 | ⭐⭐ |
+| 3. SecureSelect | 3位（セキュリティ統合） | 10/10 | 6ヶ月 | ★ 低 | ★★ 中 | ⭐ |
+| 4. CodeSwitch | 1位（自動切り替え） | 10/10 | 6ヶ月 | ★★★ 高 | ★★ 中 | ⭐⭐ |
+| 5. PairPilot | 2位（ペアプロ型） | 9/10 | 5.5ヶ月 | ★★★ 高 | ★★★ 高 | ⭐⭐⭐ |
+
+**Phase 6で選択する発明の推奨**:
+1. **DevMatch**（第一推奨）: 最もクリアな価値提案、実装期間が短い、市場適合性が高い
+2. **PairPilot**（第二推奨）: ブレイクスルー度が高く差別化できるが、文化変革が必要でリスクあり
+
+**Phase 6では「DevMatch」を選択してプレスリリースを作成することを推奨**します。
+
+---
+
+## Refine: プレスリリース・FAQ
+
+### DevMatch - AI開発ツール即時比較プラットフォーム
+**プレスリリース（Amazon PR/FAQ形式）**
+
+---
+
+## プレスリリース本文
+
+### 株式会社○○、AI開発ツールを3週間から3日で選べる「DevMatch」をリリース
+
+**複数のAI開発ツールを同時に試せる VS Code 拡張機能で、ツール選定の時間を90%削減**
+
+**東京、2025年XX月XX日** – 株式会社○○は本日、スタートアップから急成長企業のCTO向けに、AI開発ツール選定プロセスを劇的に効率化する「DevMatch」をリリースしました。
+
+従来、CTOは「GitHub Copilotを2週間試す→Cursorを1週間試す→Amazon Qを評価する」という3週間の逐次的プロセスを強いられ、その間シニアメンバーは既存業務と並行して検証を行うため、年間780時間（約390万円相当）の貴重な開発時間を費やしていました。DevMatchは、この「常識」を覆します。
+
+DevMatchは、1つのVS Code拡張機能の中で、複数のAI開発ツール（GitHub Copilot風、Cursor風、Amazon Q風）を同じコードベースで同時に試せる体験を提供します。タブを切り替えるだけで「このツールならどう提案するか?」を瞬時に比較でき、開発者は3日間で最適なツールを決定できます。サイドバイサイドの比較UIにより、各AIの提案をリアルタイムで評価し、定量的なスコア（コード品質、セキュリティ、レスポンス速度）が自動的に蓄積されます。これは、Amazon.comで商品を比較するように、AIツールを比較できる世界初の体験です。
+
+DevMatchの独自技術は、複数のLLM API（Claude、GPT-4、AWS Bedrock）を統一インターフェースで呼び出すマルチLLM統合レイヤーにあります。開発者は単一のプロンプトを入力するだけで、3つのAIエンジンが並列に処理を行い、結果を比較可能な形式で表示します。
+
+実証実験では、開発チーム10名規模のスタートアップで、**ツール選定期間を3週間から3日に短縮（90%削減）、年間780時間の開発時間を節約**しました。さらに、選定後の「後悔」も大幅に減少しました。従来は「選んだ後に別のツールの方が良かったかも」という不安が残りましたが、DevMatchでは実際に全てのツールを試した上で決定できるため、確信を持ってツール導入を進められます。
+
+DevMatchは月額$50/ユーザー（3つのAI APIコストを含む）で、今すぐ VS Code Marketplace からダウンロードできます。詳細は https://devmatch.example.com をご覧ください。
+
+---
+
+**顧客の声1：株式会社TechStartup CTO 田中氏**
+
+「『競合が2週間でリリースした機能を、うちは1ヶ月かかっている』とCEOから指摘されて以来、AI開発ツールの導入が急務でした。でも、3つのツールを順番に試すのに3週間もかかり、その間シニアメンバーは既存業務と並行して評価を行うため、全員が疲弊していました。DevMatchを使ったところ、たった3日で最適なツールを決定できました。何より素晴らしいのは、3つのツールの提案を並べて比較できること。『このツールはシンプルだけど速い』『このツールは詳しいけど遅い』という違いが一目瞭然で、チーム全員が納得して決定できました。年間390万円相当の時間を節約できただけでなく、『選んだ後に後悔する』リスクもなくなりました。もう、逐次的にツールを試す時代じゃない。DevMatchは、ツール選定の常識を変えました。」
+
+**顧客の声2：株式会社GrowthCo エンジニアリングマネージャー 佐藤氏**
+
+「うちのチームはシニア2名、ミドル5名、ジュニア8名という構成で、AI開発ツールの選定に誰を巻き込むべきか悩んでいました。シニアだけで決めるとジュニアが使いこなせない、ジュニアに任せると判断軸が曖昧。DevMatchのサイドバイサイド比較UIは、この問題を解決しました。チーム全員が同じコードで3つのツールを試し、各自が『👍/👎』で評価することで、民主的にツールを選べました。定量評価ダッシュボードも素晴らしい。『セキュリティスコアが高いツール』『コード品質が良いツール』といった客観的な指標で比較できるため、セキュリティチームへの説明も簡単でした。従来4週間かかっていたセキュリティレビューが1週間で完了し、CFOへのROI説明も『3日で選定、390万円/年のコスト削減』と明確に示せました。投資回収期間は2ヶ月です。」
+
+---
+
+**使い方はシンプル**
+
+DevMatchは、スタートアップから急成長企業のCTOが、以下の3ステップで最適なAI開発ツールを選定できるようにします：
+
+1. **VS Code拡張機能をインストール**: VS Code Marketplaceから「DevMatch」を検索し、ワンクリックでインストール。既存のプロジェクトを開くだけで、すぐに使い始められます。
+
+2. **3つのAIを同時に試す**: サイドバーから「比較モード」を起動し、プロンプトを入力。3つのAI（GitHub Copilot風、Cursor風、Amazon Q風）が並列に提案を生成し、サイドバイサイドで表示されます。各提案に「👍/👎」で評価すると、スコアが自動的に蓄積されます。
+
+3. **定量評価で決定**: 3日間の試用後、定量評価ダッシュボードで各ツールのコード品質スコア、セキュリティスコア、レスポンス速度、チームメンバーの評価を確認。データに基づいて最適なツールを決定し、そのまま本番導入へ進めます。
+
+DevMatchは、従来のカスタマージャーニーを逆転させます。「情報収集（2週間）→トライアル（3週間）→セキュリティレビュー（4週間）」という9週間のプロセスを、「同時トライアル（3日）→定量評価に基づく決定（即座）→セキュリティレビュー（1週間、定量データを使って説明）」という10日間のプロセスに短縮します。これにより、**年間780時間の開発時間と、月160万円の機会損失**を回避できます。
+
+---
+
+## 顧客向けFAQ（Customer FAQs）
+
+### 一般（General）
+
+**Q1: DevMatchとは何ですか？**
+
+A: DevMatchは、スタートアップから急成長企業のCTO向けに、複数のAI開発ツールを同時に試して比較できるVS Code拡張機能です。従来3週間かかっていたツール選定プロセスを3日に短縮し、年間780時間（約390万円相当）の開発時間を節約できます。GitHub Copilot風、Cursor風、Amazon Q風の3つのAIエンジンを1つのインターフェースで同時に試せる、世界初のツール比較プラットフォームです。
+
+**Q2: DevMatchで何ができますか？**
+
+A: DevMatchでは以下のことができます：
+- **同時トライアル**: 3つのAI開発ツール（GitHub Copilot風、Cursor風、Amazon Q風）を同じコードベースで並列に試用
+- **サイドバイサイド比較**: 同じプロンプトに対する3つのAIの提案をリアルタイムで並べて表示
+- **定量評価**: コード品質スコア、セキュリティスコア、レスポンス速度を自動計測し、グラフ表示
+- **チーム評価**: チームメンバー全員が各提案に「👍/👎」で評価し、民主的にツールを選定
+- **セキュリティレポート生成**: セキュリティチーム向けのレポートを自動生成し、承認プロセスを加速
+
+**Q3: なぜDevMatchが必要なのですか？**
+
+A: 従来、CTOは「ツールAを2週間試す→ツールBを1週間試す→評価会議→選定」という逐次的プロセスを強いられ、3週間を費やしていました。さらに、「選んだ後に別のツールの方が良かったかも」という後悔が残ることも多々ありました。DevMatchは、この「常識」を覆します。3つのツールを同時に試せるため、直接比較が可能になり、データに基づいた確信を持った意思決定ができます。開発チーム10名のスタートアップでは、年間780時間の削減が実現され、シニアメンバーを本来の価値創造に集中させることができます。
+
+### 価格（Pricing）
+
+**Q4: DevMatchの価格は？**
+
+A: DevMatchは月額$50/ユーザーです。この価格には、3つのAI API（Claude、GPT-4、AWS Bedrock）の利用コストが含まれています。従来のツール選定プロセスで年間780時間（約390万円相当）を費やしていたことを考えると、10名チームで月額$500（約7.5万円）の投資により、**投資回収期間は約2ヶ月**です。年間契約の場合は10%割引が適用されます。
+
+**Q5: 無料トライアルはありますか？**
+
+A: はい、14日間の無料トライアルを提供しています。クレジットカード登録不要で、すぐにVS Code Marketplaceからダウンロードして試せます。トライアル期間中は全機能を制限なく利用でき、3つのAI比較、定量評価ダッシュボード、チーム評価機能が使えます。従来3週間かかっていたツール選定が3日で完了するため、トライアル期間内に十分な価値を実感できます。
+
+**Q6: 既存のAI開発ツールと比較して、コストパフォーマンスは？**
+
+A: 既存のツール（GitHub Copilot: $10-20/月、Cursor: $20-40/月、Amazon Q: 無料-有料）を個別に契約して順番に試す場合、3つのツールで月額$50-100/月 × 3ヶ月（評価期間）= $150-300の費用がかかります。DevMatchは月額$50/ユーザーで、3日間で評価を完了できるため、最初の月だけで済みます。さらに、シニアメンバーの評価工数（3週間 × 時給$62.5 = 約$7,500）を考慮すると、1回の選定で$7,500以上の削減効果があります。
+
+### はじめ方（Getting Started）
+
+**Q7: DevMatchを始めるには？**
+
+A: 以下の3ステップで今すぐ始められます：
+1. **VS Code Marketplaceからインストール**: 「DevMatch」を検索し、「Install」をクリック（1分）
+2. **アカウント作成**: メールアドレスで無料アカウントを作成し、14日間トライアルを開始（2分）
+3. **比較モード起動**: VS Codeでプロジェクトを開き、サイドバーから「比較モード」を起動し、プロンプトを入力（30秒）
+
+技術的な前提条件は、VS Code 1.80以上のみです。プログラミング言語は、JavaScript/TypeScript、Python、Go、Rustなど主要言語をサポートしています。
+
+**Q8: チームで使い始めるには？**
+
+A: チームでの導入も簡単です：
+1. **管理者がチームアカウント作成**: DevMatchのウェブサイトでチームプランに登録（月額$50/ユーザー）
+2. **メンバーを招待**: 管理ダッシュボードからメンバーのメールアドレスを入力し、招待リンクを送信
+3. **チーム評価機能を有効化**: チーム全員が同じプロジェクトで比較評価を行い、各自の「👍/👎」が集約されてダッシュボードに表示される
+4. **3日間の評価期間**: チーム全員で3日間使用した後、定量評価ダッシュボードでデータに基づいて意思決定
+
+チーム規模は3名から無制限まで対応しています。
+
+**Q9: 既存のプロジェクトにすぐに適用できますか？**
+
+A: はい、既存のVS Codeプロジェクトをそのまま開くだけで使えます。DevMatchは、プロジェクトの構造を自動的に理解し、3つのAIエンジンがそれぞれコンテキストを把握した上で提案を行います。特別な設定やコード変更は不要で、インストール後すぐに比較モードを起動できます。初回起動時にプロジェクトのインデックス化（数分）が行われますが、その後はシームレスに動作します。
+
+### DevMatchの使用（Using DevMatch）
+
+**Q10: 3つのAIエンジンはどのように選ばれているのですか？**
+
+A: DevMatchが提供する3つのAIエンジンは、市場で最も人気のあるAI開発ツールの特性を代表しています：
+- **GitHub Copilot風**: シンプルで高速なコード補完に特化。ボイラープレートコードの生成に最適
+- **Cursor風**: 対話的で詳細な説明付きの提案。複雑なリファクタリングや新しい技術の学習に最適
+- **Amazon Q風**: AWS/クラウドに特化した提案。セキュリティベストプラクティスに準拠したコード生成に最適
+
+これらは、Phase 1のカスタマージャーニーで特定された「CTOが最も頻繁に比較検討するツール」に基づいて選定されています。
+
+**Q11: 定量評価ダッシュボードでは何が測定されますか？**
+
+A: 定量評価ダッシュボードでは、以下の3つの重要な指標を自動的に測定します：
+- **コード品質スコア**（0-100点）: Cyclomatic complexity（複雑度）、コードの可読性、ベストプラクティスへの準拠度を評価
+- **セキュリティスコア**（0-100点）: 既存のlinter（ESLint、Pylintなど）と統合し、脆弱性や危険なパターンを検出
+- **レスポンス速度**（ミリ秒）: 各AIエンジンがプロンプトに応答するまでの時間を計測
+
+さらに、チームメンバーの「👍/👎」評価が集約され、「チーム満足度スコア」も表示されます。
+
+**Q12: サイドバイサイド比較UIは具体的にどのように動作しますか？**
+
+A: サイドバイサイド比較UIは、Amazon.comで商品を比較するような直感的な体験を提供します：
+1. **プロンプト入力**: 「CRUDエンドポイントを作成」などの自然言語で要求を入力
+2. **並列生成**: 3つのAIエンジンが同時に処理を開始し、リアルタイムで結果が表示される
+3. **3カラム表示**: 画面が3分割され、各AIの提案が並んで表示される。スクロールは同期される
+4. **評価ボタン**: 各提案の下に「👍/👎」ボタンがあり、クリックするとスコアが蓄積される
+5. **差分ハイライト**: 3つの提案の「違い」が色分けされ、一目で比較できる
+
+この体験により、「このツールはシンプルだけど速い」「このツールは詳しいけど遅い」という違いが直感的に理解できます。
+
+**Q13: プライバシーは保護されますか？コードは外部に送信されますか？**
+
+A: DevMatchは、プライバシーとセキュリティを最優先事項としています：
+- **コード送信**: プロンプトと関連するコードコンテキストのみが、Claude API、OpenAI API、AWS Bedrockに送信されます。プロジェクト全体が送信されることはありません
+- **データ保存**: 送信されたコードは、各APIプロバイダーのポリシーに従って処理されます（Claude: 保存されない、OpenAI: 保存されない（API経由）、AWS Bedrock: 保存されない）
+- **オンプレミス対応**: エンタープライズプランでは、自社のLLMエンドポイント（Azure OpenAI、AWS Bedrock等）に接続可能
+- **監査ログ**: 何が送信されたかのログを管理ダッシュボードで確認できる
+
+Phase 3で特定された「セキュリティチームの懸念」に対応するため、透明性を重視しています。
+
+**Q14: どのプログラミング言語をサポートしていますか？**
+
+A: DevMatchは、主要なプログラミング言語を幅広くサポートしています：
+- **フロントエンド**: JavaScript、TypeScript、React、Vue、Angular
+- **バックエンド**: Python、Go、Rust、Java、C#、Ruby、PHP
+- **モバイル**: Swift、Kotlin、Dart（Flutter）
+- **インフラ**: Terraform、CloudFormation、Kubernetes YAML
+- **その他**: SQL、Shell Script、HTML/CSS
+
+各AIエンジンは、言語ごとに最適化されたプロンプトを使用し、高品質な提案を提供します。新しい言語のサポートもコミュニティフィードバックに基づいて随時追加されます。
+
+### 制限と制約（Limits and Restrictions）
+
+**Q15: DevMatchの技術的制限は何ですか？**
+
+A: 現時点での主な制限は以下の通りです（Phase 5の実現方法に基づく）：
+- **同時比較数**: 最大3つのAIエンジンまで（認知負荷を考慮した設計）。4つ以上を同時比較すると、意思決定が逆に難しくなるため
+- **プロジェクトサイズ**: 100万行以下のコードベースを推奨。それ以上の場合、インデックス化に時間がかかる可能性
+- **API レート制限**: 各AIプロバイダーのレート制限に依存。通常の使用では問題ありませんが、大量のリクエストを短時間に送信すると制限される可能性
+- **オフライン使用**: インターネット接続が必要。AIエンジンがクラウドAPIを使用するため
+
+エンタープライズプランでは、これらの制限の一部を緩和できます。
+
+**Q16: DevMatchが向いていない場合は？**
+
+A: 以下の場合、DevMatchは最適な選択ではない可能性があります（Phase 6社内FAQ「いつ勧めないべきか」に基づく）：
+- **すでにツールを決定済み**: 特定のAI開発ツールに満足しており、比較の必要がない場合
+- **極めて特殊なドメイン**: 医療、金融など、高度にカスタマイズされたLLMが必要な場合
+- **完全オフライン環境**: インターネット接続が一切できない環境
+- **超大規模コードベース**: 数百万行以上の巨大なモノリスで、インデックス化が困難な場合
+
+このような場合は、個別のツールの長期契約や、カスタムLLMの構築を検討することをお勧めします。
+
+**Q17: セキュリティとコンプライアンスの認証は？**
+
+A: DevMatchは、以下のセキュリティ対策とコンプライアンス認証を取得しています：
+- **SOC 2 Type II**: 情報セキュリティ管理の国際基準に準拠
+- **GDPR準拠**: 欧州のデータ保護規則に完全準拠
+- **データ暗号化**: 通信はTLS 1.3、保存データはAES-256で暗号化
+- **定期的なセキュリティ監査**: 四半期ごとに第三者機関による監査を実施
+
+また、各AIプロバイダー（Claude、OpenAI、AWS Bedrock）も独自のセキュリティ認証を持っています。Phase 3で特定された「法務の懸念」に対応するため、透明性の高いセキュリティ情報を提供しています。
+
+### パフォーマンス（Performance）
+
+**Q18: DevMatchのレスポンス速度は？**
+
+A: DevMatchのパフォーマンスは、以下の通りです：
+- **初回インデックス化**: プロジェクトサイズに依存（1万行で約30秒、10万行で約5分）
+- **比較モード起動**: 約1秒
+- **3つのAI並列生成**: 平均3-8秒（各AIエンジンのレスポンス速度に依存）
+- **定量評価計算**: リアルタイム（AIの提案が生成されると同時にスコア計算）
+
+Phase 6社内FAQで定義された「レスポンス速度」指標により、常に5秒以内の応答を目標としていますが、複雑なプロンプトの場合は最大15秒かかることがあります。
+
+**Q19: チーム規模が大きくなってもパフォーマンスは維持されますか？**
+
+A: はい、DevMatchはスケーラブルなアーキテクチャを採用しています：
+- **AWS Lambda + API Gateway**: オートスケーリングにより、同時アクセス数が増えても安定したパフォーマンスを維持
+- **DynamoDB**: 評価データやメトリクスの保存に使用し、低レイテンシを実現
+- **CDN配信**: VS Code拡張機能の配信にCloudFrontを使用し、世界中どこからでも高速ダウンロード
+
+10名から100名規模のチームで検証済みです。1000名を超える場合は、エンタープライズプランでの専用インフラ構築を推奨します。
+
+**Q20: 他のVS Code拡張機能と競合しませんか？**
+
+A: DevMatchは、既存のVS Code拡張機能との互換性を重視して設計されています：
+- **他のAIツールとの共存**: GitHub Copilot、Cursor、Tabnineなどの拡張機能と同時にインストール可能。ただし、比較モード使用中は、他のAIツールを一時的に無効化することを推奨
+- **Linterとの統合**: ESLint、Pylintなど既存のlinterと統合し、定量評価に活用
+- **Git拡張機能**: GitLens、Git Graphなどと問題なく共存
+
+競合が発生する場合は、設定画面で優先度を調整できます。
+
+---
+
+## 社内向けFAQ（Internal FAQs）
+
+### 1. いつ顧客にDevMatchを勧める/勧めないべきですか？
+
+**勧めるべき顧客**:
+- **ペルソナ**: 開発チーム10～100名のスタートアップ・急成長企業のCTO/VPE（customer.mdで定義）
+- **課題**: Phase 1で特定された以下の課題を抱えている顧客
+ - 複数のAI開発ツールを比較検討したいが、時間がない（3週間の評価期間を確保できない）
+ - シニアメンバーがコードレビューやツール評価で手一杯で、ボトルネックになっている
+ - セキュリティチームや法務部門の承認を得るために、定量的なデータが必要
+ - CFOに投資対効果を説明する必要がある（ROIを数値で示せない）
+- **Phase 3-Top3の問い**:
+ - 「なぜ複数ツールのトライアルと比較評価は同時にできないのか?」に悩んでいる顧客
+ - 年間780時間（約390万円相当）の削減効果に魅力を感じる顧客
+ - ツール選定後の「後悔」を避けたい慎重な意思決定者
+
+**勧めるべきでない顧客**:
+- **すでに特定のツールに満足している顧客**: 比較の必要性がない場合、DevMatchは過剰
+- **極めて特殊なドメイン要件**: 医療、金融など、高度にカスタマイズされたLLMが必要で、汎用的な3つのAIエンジンでは不十分な場合
+- **超大規模エンタープライズ**: 数千名規模の開発組織で、独自のAI開発ツールを内製している場合
+- **完全オフライン環境**: インターネット接続が一切できない環境（Phase 5の技術的制約）
+- **チーム規模が3名未満**: 個人開発者や極小チームでは、チーム評価機能の価値が限定的
+
+### 2. DevMatchの指針（Tenets）は何ですか？
+
+私たちの指針は、より良いものを知らない限り、以下の通りです：
+
+* **比較の民主化により意思決定を加速する** – 従来「CTOとシニアメンバーだけが評価できた」AI開発ツール選定を、チーム全員が参加できるプロセスに変革する。サイドバイサイド比較とチーム評価機能により、民主的かつデータドリブンな意思決定を実現する（Phase 5の最重要の価値提案）
+
+* **3週間を3日に短縮し、創造的な時間を取り戻す** – Phase 3-1位の問い「なぜ複数ツールのトライアルと比較評価は同時にできないのか?」を解決し、年間780時間の削減を実現する。シニアメンバーをツール評価の負担から解放し、本来の価値創造に集中させる
+
+* **時間軸の操作とECのUXを開発ツール選定に適用する** – Phase 5の「ブレイクスルー要素」として、「順番に試す→比較する→決める」という直列プロセスを、「同時に試しながらリアルタイムで比較する」という並列プロセスに変換。Amazon.comの商品比較UIを開発ツール選定に適用し、直感的な体験を提供する
+
+* **透明性により、セキュリティチームと法務の信頼を獲得する** – customer.mdで特定された「外部サービスにコードを送信するリスク」「知的財産の保護」という懸念に対応。何が送信されたかの監査ログ、定量的なセキュリティスコア、SOC 2認証により、説得力のある説明を可能にする
+
+* **既存技術を活用し、6ヶ月で実装可能な設計** – team_capabilitiesで定義された「AWSの実装経験あり」「新技術習得は可能だが、既存技術を優先」という制約を遵守。VS Code Extension API、既存のLLM API（Claude、GPT-4、AWS Bedrock）、AWS Lambda/DynamoDBなど、チームが既に習得している技術スタックで実装する
+
+### 3. 顧客体験を改善するために測定・最適化する運用指標は何ですか？
+
+私たちは、DevMatchの顧客体験を以下の3つの重要な次元で最適化します：_ツール選定期間の短縮率_、_意思決定の確信度_、_年間削減時間_。また、4つ目の指標として_顧客満足度（NPS）_を監視し、顧客体験を保護します。
+
+**ツール選定期間の短縮率**
+- **内部指標**: 「情報収集開始」から「ツール決定」までの日数を測定。目標: 従来21日（3週間）→3日に短縮（86%削減）
+- **顧客に公開する指標**: VS Code拡張機能の使用開始から、顧客が「このツールに決めた」ボタンをクリックするまでの時間を公開。カナリアクライアントで継続的に測定し、ウェブサイトに平均値を掲載（目標: 中央値3日以内）
+
+Phase 3-1位の問い「なぜ複数ツールのトライアルと比較評価は同時にできないのか?」の解決度合いを直接測定する指標。この指標により、年間780時間の削減効果が実現されているかを追跡できる。
+
+**意思決定の確信度**
+- **内部指標**: 顧客がツールを選定した後、30日以内に「別のツールを試したい」という問い合わせをする割合（目標: 5%以下）
+- **測定方法**: 選定後30日後に「選定したツールに満足していますか?」というアンケートを送信。5段階評価で平均4.5以上を目標
+
+Phase 1のカスタマージャーニーで特定された「選んだ後に後悔する」という課題の解決度合いを測定。サイドバイサイド比較により、全てのツールを実際に試した上で決定できるため、後悔を最小化する。
+
+**年間削減時間**
+- **内部指標**: 顧客が実際に削減できた時間を、アンケートとツール使用ログから推定（目標: 平均600時間以上/年）
+- **測定方法**: 「DevMatch導入前の評価期間」と「導入後の評価期間」を比較し、差分を計算。さらに、「従来は年に何回ツール評価をしていたか」を掛け合わせて年間削減時間を算出
+- **顧客に公開する指標**: ダッシュボードに「あなたのチームは累計XXX時間を節約しました」と表示
+
+Phase 5の新しい価値提案「年間780時間の削減」の実現度合いを測定。この指標により、投資対効果（ROI）が達成されているかを追跡できる。
+
+**顧客満足度（NPS）**
+- **測定方法**: 90日ごとに「DevMatchを同僚に勧める可能性は?」（0-10点）を質問。NPS = （推奨者% - 批判者%）を計算
+- **目標**: NPS 50以上（業界平均を大きく上回る水準）
+- **改善アクション**: NPS 6以下の批判者には、個別にヒアリングを実施し、課題を特定
+
+この指標により、ツール選定期間の短縮だけでなく、全体的な顧客体験が優れているかを監視する。
+
+### 4. DevMatchはどのようにして顧客のコストを削減できますか？
+
+DevMatchは、fine-grained（きめ細かい）な**ユーザー単位**ベースの価格設定を提供します。Phase 3で算出した「年間780時間の削減効果」により、顧客は**従来年間390万円相当の評価工数から、月額$50/ユーザー（約7.5万円/月、年間90万円）に削減**できます。つまり、年間300万円のコスト削減を実現します。
+
+**小〜中規模の顧客**（10-30名のチーム）は、**ツール評価の頻度が少ない場合でも無駄がない料金体系**の恩恵を受けます。Phase 1で特定された「年に3-4回のツール評価」という状況でも、月額$50/ユーザーで常に最新のAIツールを比較できる環境を維持できます。従来のように「評価のたびに3週間を確保する」必要がなく、**必要な時に即座に3日で評価完了**できるため、機会損失を最小化します。
+
+**大規模顧客**（50-100名のチーム）は、**スケールメリット**の恩恵を受けます。Phase 1のカスタマージャーニーで特定された「チーム規模が倍になっても、生産性は維持できる」というニーズに対応し、DevMatchの並列処理アーキテクチャ（AWS Lambda + DynamoDB）により、100名が同時に使用してもパフォーマンスが劣化しません。さらに、Phase 5の「チーム評価機能」により、全員の評価を集約して民主的に意思決定できるため、**「シニアだけで決めて、ジュニアが使いこなせない」というリスクを排除**できます。
+
+DevMatchはまた、Phase 5で組み合わせた**3つのAI API（Claude、GPT-4、AWS Bedrock）を統合**することで、Phase 1で要していた「各ツールを個別に契約・管理する運用負荷」を削減し、TCO（総所有コスト）を下げることができます。customer.mdのペルソナである「開発チーム10～100名のスタートアップ・急成長企業のCTO」にとって、Phase 1の課題である「予測不可能な需要（いつツール評価が必要になるか分からない）、急速な変化（新しいAIツールが次々に登場）」は大きな課題でしたが、DevMatchは**常に最新の3つのAIエンジンを比較できる環境を提供**することで、Phase 3で算出した「年間780時間の削減、投資回収期間2ヶ月」を実現します。
+
+---
+
+## Phase 7: 事業計画
+
+### 提供者メッセージ
+
+これまで、**複数のAI開発ツールを逐次的にトライアルすることによる時間の浪費**は見過ごされていました。スタートアップから急成長企業のCTOは、「GitHub Copilotを2週間試す→Cursorを1週間試す→評価会議」という3週間の非効率なプロセスを強いられ、年間780時間（約390万円相当）の貴重なシニアメンバーの時間を費やしていました。
+
+**市場規模の推計**：
+- 日本国内のスタートアップ・急成長企業（開発チーム10-100名）: 約3,000社
+- そのうち、AI開発ツール導入を検討している割合: 70%（約2,100社）
+- AI開発ツール予算を持つCTO/VPE: 約2,100名
+
+つまり、**約2,100社/名のお客様がこの課題を抱えている**と推計しています。
+
+私達株式会社○○は、**10名のエンジニアチーム、AWSの実装経験、0→1および1→10のプロダクト開発経験**を活かし、今後**3年で500社のお客様での導入**を目指します。これは市場の約24%のシェアに相当し、第1フェーズとして現実的な目標です。
+
+**独自の強み**：
+- **AWS実装経験とスケーラブルなアーキテクチャ**: AWS Lambda、DynamoDB、API Gatewayを活用した低レイテンシ・高可用性のインフラ構築能力
+- **0→1プロダクト開発の実績**: 市場に存在しない「AI開発ツールの比較プラットフォーム」という新カテゴリーを創造する経験とノウハウ
+- **開発者コミュニティとのつながり**: VS Code Marketplace、技術ブログ、カンファレンス登壇などを通じた開発者への直接リーチ
+- **6ヶ月での実装可能性**: team_capabilitiesで定義された制約の中で、Phase 5の発明を実現できる技術力
+
+### 社内向けFAQ（事業計画）
+
+**Q: リリース後、いつ開発の継続を検討しますか?**
+
+A: リリース後**6ヶ月**で継続判断を行います。この期間は、Phase 1のカスタマージャーニーで特定された「効果測定と継続的な改善サイクル確立」に要する期間と整合しています。
+
+**Q: 継続の意思決定に使用する目標値と指標は?**
+
+A: 以下の3つの指標で判断します：
+- **導入顧客数**: 50社（市場の約2.4%、3年目標500社の10%）
+- **アクティブ利用率**: 導入企業のうち、月1回以上DevMatchを使用している割合が70%以上
+- **顧客維持率（リテンション）**: 初回契約から6ヶ月後も継続利用している割合が80%以上
+
+この目標は、Phase 6で定義した価格設定（月額$50/ユーザー × 平均15名/社 = $750/社/月）に基づくと、**月間売上$37,500（約560万円）、年間売上約6,700万円**に相当します。
+
+**Q: 競争優位性をどのように評価しますか?**
+
+A: 導入後**3ヶ月で週1回以上DevMatchを使用している**ことを評価します。この指標は、Phase 3-1位の問い「なぜ複数ツールのトライアルと比較評価は同時にできないのか?」の解決が継続的な価値を生んでいるかを測定します。
+
+**具体的な評価基準**：
+- 優秀（競争優位性あり）: 週1回以上利用する企業が70%以上
+- 良好（継続価値あり）: 週1回以上利用する企業が50-70%
+- 要改善（価値が不足）: 週1回以上利用する企業が50%未満
+
+Phase 1のカスタマージャーニーでは「年に3-4回のツール評価」が想定されていましたが、実際には新しいAIツールが月次で登場するため、週1回の利用は現実的な指標です。
+
+**Q: 成功指標（North Star Metric）は何ですか？**
+
+A: **「AI開発ツール選定にかかる時間の累計削減量」**（単位: 時間）
+
+この指標は、Phase 3-1位の問い「なぜ複数ツールのトライアルと比較評価は同時にできないのか?」に直結し、DevMatchの本質的な価値を測定します。
+
+**計算方法**：
+- 各顧客の「従来の選定期間（21日 = 504時間）」- 「DevMatch使用後の選定期間（3日 = 72時間）」= 432時間/回
+- 全顧客の累計削減時間 = 432時間 × 導入企業数 × 年間評価回数（平均3回）
+
+**目標**：
+- リリース後1ヶ月: 5,000時間削減（導入企業10社 × 1回評価の想定）
+- リリース後3ヶ月: 30,000時間削減（導入企業30社 × 2回評価の想定）
+- リリース後6ヶ月: 100,000時間削減（導入企業50社 × 3回評価の想定）
+
+この指標により、「顧客に実際に価値を提供できているか」が明確に分かり、マーケティングメッセージ（「累計10万時間以上の削減を実現」）にも活用できます。
+
+**Q: 各フェーズでモニタリングする指標は？**
+
+A:
+**リリース後1ヶ月（アクティベーション指標）**：
+- VS Code Marketplaceからのインストール数: 目標500件
+- 無料トライアル開始数: 目標200社
+- 「比較モード」を1回以上使用したユーザー数: 目標150社（トライアル開始の75%）
+- 平均使用開始時間: インストールから初回使用まで平均10分以内
+
+Phase 1のカスタマージャーニーで特定された「導入のしやすさ」が実現されているかを測定。
+
+**リリース後3ヶ月（エンゲージメント指標）**：
+- 週1回以上使用しているアクティブユーザー数: 目標100社（導入企業の60%以上）
+- 1社あたりの平均使用回数: 目標8回/月（週2回）
+- 定量評価ダッシュボードの閲覧率: 目標80%（使用者のうち）
+- チーム評価機能の利用率: 目標50%（複数名で評価している企業の割合）
+
+Phase 6社内FAQ「測定する運用指標」で定義された「ツール選定期間の短縮率」「意思決定の確信度」が実現されているかを測定。
+
+**リリース後6ヶ月（リテンション指標）**：
+- 6ヶ月継続利用率: 目標80%
+- トライアルから有料転換率: 目標25%（200社トライアル → 50社有料）
+- NPS（Net Promoter Score）: 目標50以上
+- 顧客生涯価値（LTV）: 目標$9,000/社（18ヶ月 × $50/ユーザー × 平均10名）
+
+Phase 1のカスタマージャーニーで特定された「投資対効果の明確化」が実現され、継続利用につながっているかを測定。
+
+**Q: 主要なリスクと対応策は？**
+
+A: 以下のリスクを特定し、対応策を準備しています：
+
+**リスク1: AI開発ツール市場の急速な変化**
+- **内容**: GitHub Copilot、Cursorなど既存ツールが大幅に進化し、DevMatchの比較対象が陳腐化するリスク
+- **対応策**: 四半期ごとに比較対象のAIエンジンを見直し、最新のツールを追加。モジュール設計により、新しいAIエンジンの追加を1ヶ月以内に実装可能な体制を維持
+
+**リスク2: 大手プレイヤーの参入**
+- **内容**: Microsoft（GitHub Copilot）、Anthropic（Claude）、OpenAI（ChatGPT）が同様の比較機能を提供するリスク
+- **対応策**: First Mover Advantageを活かし、早期に顧客基盤を構築。さらに、「VS Code拡張機能」という軽量な形態により、大手が提供できない「中立性」と「柔軟性」を差別化ポイントとする
+
+**リスク3: セキュリティインシデント**
+- **内容**: コードが外部に漏洩する、または誤った提案により脆弱性が混入するリスク
+- **対応策**: SOC 2認証取得、定期的なセキュリティ監査、インシデント対応プランの策定。Phase 6社内FAQで定義された透明性の高い運用により、顧客の信頼を獲得
+
+**リスク4: 開発リソースの不足**
+- **内容**: 6ヶ月の開発期間で予定通り完成しない、または品質が低下するリスク
+- **対応策**: Phase 4で評価した実装難易度（9/10）を考慮し、Composerモードなどの高度な機能は後回しにし、MVP（最小限の価値ある製品）を優先。アジャイル開発により、2週間ごとに進捗を確認し、軌道修正
+
+**Q: 収益モデルの詳細は？**
+
+A: 以下の収益モデルを採用します：
+
+**価格設定**（Phase 6で定義）：
+- 月額$50/ユーザー（年間契約で10%割引 → $45/ユーザー）
+- 平均チーム規模: 15名（customer.mdのペルソナに基づく）
+- 1社あたりの月間売上: $750（約11万円）
+
+**収益予測**：
+- **1年目**: 50社 × $750/月 × 12ヶ月 = $450,000（約6,700万円）
+- **2年目**: 200社 × $750/月 × 12ヶ月 = $1,800,000（約2.7億円）
+- **3年目**: 500社 × $750/月 × 12ヶ月 = $4,500,000（約6.7億円）
+
+**コスト構造**：
+- AI API コスト: 約$15/ユーザー/月（Claude、GPT-4、AWS Bedrockの合計）
+- インフラコスト（AWS）: 約$5/ユーザー/月
+- 粗利率: 約60%（$30/ユーザー/月）
+- 1社あたりの粗利: $450/月（約6.7万円）
+
+**投資回収**：
+- 初期開発コスト: 約3,000万円（エンジニア10名 × 6ヶ月 × 平均月給50万円）
+- 投資回収期間: 約9ヶ月（初期開発6ヶ月 + リリース後3ヶ月で黒字化）
+
+Phase 6で定義した「投資回収期間2ヶ月」は顧客視点の指標であり、事業全体の投資回収は9ヶ月と想定しています。
+
+---
+
+## 最終確認
+
+### 全フェーズ完了チェック
+
+✅ **Phase 1 (Listen)**: カスタマージャーニーマップが8ステップで完成、定量データ・感情スコア・顧客の声を含む
+
+✅ **Phase 2 (Define)**: 全7行動ステップに対して2種類の問い（省略型・統合型）を立て、合計17個の問いを生成
+
+✅ **Phase 3 (Top 3選定)**: 17個の問いをスコアリングし、リソース削減効果と頻度に基づいてTop 3を選定
+
+✅ **Phase 4 (実装難易度評価)**: solutions.mdの4つのソリューションに対して、team_capabilitiesに基づいた難易度評価を追記
+
+✅ **Phase 5 (Invent)**: Top 3の問いに対して5つの発明を提案し、うち3つにブレイクスルーアイデアフレームワークを適用
+
+✅ **Phase 6 (Refine)**: DevMatchのプレスリリース・FAQ（顧客向け20個、社内向け4個）をAmazon PR/FAQ形式で作成
+
+✅ **Phase 7 (事業計画)**: 提供者メッセージ、市場規模推計、社内向けFAQ（継続判断、成功指標、モニタリング指標、リスク対応、収益モデル）を完成
+
+### 一貫性の確認
+
+✅ **Listen → Define → Invent → Refine の一貫性**:
+- Phase 1で特定された「3週間のツール評価期間」という課題
+- Phase 2で問いとして定式化された「なぜ複数ツールのトライアルと比較評価は同時にできないのか?」
+- Phase 5で発明された「DevMatch」（3つのツールを同時に試せるプラットフォーム）
+- Phase 6で具体化された「3週間→3日、年間780時間削減」という価値提案
+- Phase 7で数値化された「50社導入、累計10万時間削減」という事業目標
+
+全てが論理的につながっています。
+
+✅ **定量的データの整合性**:
+- Phase 1: 年間総費用360万円
+- Phase 3: 年間780時間（約390万円相当）の削減効果
+- Phase 6: 月額$50/ユーザー（約7.5万円/月）で年間300万円の削減
+- Phase 7: 1社あたり月間売上$750、粗利$450
+
+全ての数値がPhase 1とPhase 3のデータに基づいており、整合性があります。
+
+✅ **制約条件の遵守**:
+- team_capabilities: エンジニア10名、AWS実装経験、開発期間6ヶ月
+- Phase 4: DevMatch（Cursor風UIベース）の実装難易度9/10、実装期間5.5ヶ月
+- Phase 6: 既存技術（VS Code Extension API、AWS Lambda、既存LLM API）で実装可能
+
+制約条件が全体のロードマップに反映されています。
+
+---
+
+**全7フェーズ完了しました。discovery/README.mdに、Listen/Define/Invent/Refineの各セクションが完成し、顧客の課題から事業計画まで一貫した論理でつながっています。**
\ No newline at end of file
diff --git a/yourwork_1shot/sample/ai_development_tool/solutions.md b/yourwork_1shot/sample/ai_development_tool/solutions.md
new file mode 100644
index 0000000..416913e
--- /dev/null
+++ b/yourwork_1shot/sample/ai_development_tool/solutions.md
@@ -0,0 +1,71 @@
+## 考えうる既存ソリューション分析
+
+### **1. GitHub Copilot**
+
+**いつ使う？**
+チームが既にGitHubエコシステムを中心とした開発フローを確立しており、幅広いプログラミング言語でのコード生成支援を求める場面で威力を発揮する。特に、オープンソースライブラリの活用が多く、標準的な開発パターンでの生産性向上を重視する企業において最適解となる。
+
+**どう課題を解決した？**
+従来4時間かかっていたCRUD操作の実装が30分で完了するようになり、ボイラープレートコードの生産が劇的に効率化された。開発者は創造的な問題解決により多くの時間を割けるようになり、**技術的負債を生まない品質の高いコード**を素早く実装できるようになった。コードレビューの時間も、AIが生成した標準的なコードパターンにより25%短縮された。シニア開発者のレビュー待ちというボトルネックが解消され、ジュニアメンバーも自信を持ってコミットできるようになった。
+
+**どんな効果が出た？**
+実際の企業調査では**開発速度が平均26-55%向上**し、開発者満足度が大幅に改善された。特に注目すべきは、経験の浅い開発者でも**シニア開発者並みのコード品質を実現**できるようになり、チーム全体のスキル底上げが図られた点だ。これにより「3名のシニア開発者転職検討」という危機的状況を回避し、むしろジュニアの成長実感が高まった。一方で、学習曲線の停滞や、AIに依存しすぎることによる基礎スキル低下の懸念も報告されている。
+
+**どう実現している？**
+OpenAIのCodexをベースにした大規模言語モデルが、GitHub上の数十億行のパブリックコードから学習し、リアルタイムでコンテキストに応じた提案を行う。VS Code、JetBrains、Neovimなど主要IDEとの深い統合により、開発者のワークフローを中断することなくシームレスな支援を提供している。
+
+**サービスURL**: https://github.com/features/copilot
+
+---
+
+### **2. Amazon Q Developer（旧CodeWhisperer）**
+
+**いつ使う？**
+AWSインフラストラクチャを中心としたクラウドネイティブ開発において、インフラとアプリケーションコードの一体化した生産性向上を求める場面で真価を発揮する。特に、セキュリティとコンプライアンスが重視されるエンタープライズ環境での導入において、他の選択肢を上回る価値を提供する。
+
+**どう課題を解決した？**
+AWS SDKやクラウドサービスとの統合コードの実装時間が**従来の70%削減**され、セキュリティベストプラクティスに準拠したコードが自動的に生成されるようになった。さらに、既存のレガシーコードのモダナイゼーション作業において、**自動的なコード変換機能**により大幅な工数削減を実現した。IAMポリシーやセキュリティ設定の実装ミスが98%減少し、セキュリティチームからの「外部サービスにコードを送信するのはリスク」という懸念に対しても、AWSの信頼性とコンプライアンス体制で説得力のある回答を提供できた。
+
+**どんな効果が出た？**
+AWSを主軸とする開発チームでは**開発生産性が45%向上**し、クラウドネイティブなアーキテクチャの実装品質が劇的に改善された。**セキュリティインシデントの発生率が60%削減**され、コンプライアンス要件への対応時間も大幅に短縮された。法務部門の「知的財産の保護」という懸念に対しても、Amazon独自のモデル学習手法により外部漏洩リスクを最小化していることを示せた。コードレビューにおいても、AWSベストプラクティスの知識格差によるレビュー時間のばらつきが解消された。
+
+**どう実現している？**
+AWSの豊富なクラウドサービス知識と、Amazon内部での大規模システム開発経験を学習したモデルが、クラウドファーストな開発パターンを提案する。VSCode、IntelliJ、AWS Cloud9との統合に加え、**AWS CLIやCDKとの連携**により、インフラとアプリケーションの境界を越えた包括的な開発支援を実現している。
+
+**サービスURL**: https://aws.amazon.com/q/developer/
+
+---
+
+### **3. Cursor**
+
+**いつ使う？**
+開発者がIDEに深く没入しながら、**対話的かつ流れるようなコーディング体験**を求める場面で圧倒的な価値を発揮する。特に、既存コードベースの理解とリファクタリング、複数ファイルにまたがる大規模な変更、新しい技術スタックへの挑戦など、「AIとペアプログラミングする感覚」が必要な場面において最適解となる。VS Codeの操作性に慣れたチームであれば、学習コストゼロで即日生産性向上を実感できる。
+
+**どう課題を解決した？**
+従来「新しい技術にチャレンジできない」という不満を抱えていたシニア開発者が、Cursorの**Cmd+K（インラインコード編集）**や**チャット機能による自然言語での要求**により、未経験の技術領域でも自信を持って実装できるようになった。コードベース全体を理解した上での提案により、「見積もりの30%オーバー」という課題も、より正確な工数見積もりが可能になり改善された。複数ファイルにまたがるリファクタリング作業が、**従来3日かかっていたものが半日で完了**するようになり、技術的負債の返済スピードが劇的に向上した。
+
+**どんな効果が出た？**
+実際の導入企業では**開発速度が40-50%向上**し、特に「複雑なロジック変更」や「新規フレームワーク導入」における学習時間が大幅に短縮された。State of Web Dev AI 2025の調査では、**約59%の開発者が「生産性が大幅に向上した」**と回答している。最も重要な効果は、エンジニアの満足度向上だ。「単純作業から解放され、設計や課題解決に集中できる」という声が社内アンケートで上位を占め、転職を検討していたシニア開発者の定着にも成功した。
+
+**どう実現している？**
+VS Codeをベースにした親しみやすいUIに、**Claude 3.5 Sonnet、GPT-4など複数の最先端AIモデル**を統合している。コードベース全体をインデックス化し、プロジェクトコンテキストを理解した上での提案を行う。**Composerモード**では複数ファイルの同時編集が可能で、**Tab補完、Cmd+K、チャット**という3つの異なるインタラクション方法により、開発者の意図を柔軟に汲み取る。月額$20のProプラン、チーム向け$40のBusinessプランと、スタートアップにも手が届く価格設定も魅力だ。
+
+**サービスURL**: https://cursor.com/
+
+---
+
+### **4. Devin**
+
+**いつ使う？**
+単なるコード補完を超えて、**タスク全体を自律的に完遂するAIエージェント**が必要な場面で革命的な価値を提供する。特に、時間のかかるレガシーシステムのマイグレーション、単調だが膨大な量のリファクタリング作業、複数のツールやドキュメントを横断する調査が必要な実装など、「エンジニアの時間を別の価値創造に振り向けたい」という状況で最大の効果を発揮する。「人がやらなくても良い作業」を完全に委任できる唯一の選択肢だ。
+
+**どう課題を解決した？**
+ブラジルのフィンテック企業Nubankでは、**8年間で肥大化した数百万行規模のETLシステム移行**という悪夢のようなプロジェクトに直面していた。人間が行えば18ヶ月以上かかる見積もりだったこの作業を、Devinに委任した結果**わずか数週間で完了**し、**エンジニアリング時間を12倍節約、コストを20倍以上削減**した。Devinは要件の理解、既存コードの解析、新しいコードの実装、テスト、デバッグまでを自律的に実行し、人間のエンジニアは最終レビューと戦略的判断に集中できた。これにより「バグ修正に時間を取られる」状況から脱却し、新機能開発に注力できる環境が生まれた。
+
+**どんな効果が出た？**
+導入企業では**作業速度が8-12倍**に達し、特に大規模リファクタリングやマイグレーション作業において圧倒的な効率化を実現した。重要なのは、単なる速度向上だけでなく、**エンジニアの創造性を解放**できた点だ。GMOインターネットグループの検証では、「PRのマージ割合は半分」という課題もあるが、「指示がはっきりした内容」では極めて高い成功率を示している。時給換算で約1,200円というコストパフォーマンスの高さから、「年収1,200万円でも採れない」シニア人材不足の解決策として、経営陣への説得材料にもなった。
+
+**どう実現している？**
+Devinは**ブラウザ、ターミナル、コードエディタを統合した専用環境**で動作し、人間のエンジニアと同様のワークフローを再現する。Slackとの連携により、進捗報告や質問を自然に行い、チームメンバーとして振る舞う。従量課金モデル（ACU: Agent Compute Unit）により、月額$20から利用可能で、必要な時に必要なだけ使える柔軟性がある。Teamプランでは月額$500で250ACU＋無制限ユーザー数という本格運用に適した選択肢も用意されている。
+
+**サービスURL**: https://devin.ai/
diff --git a/yourwork_1shot/sample/invoice_SaaS/customer.md b/yourwork_1shot/sample/invoice_SaaS/customer.md
new file mode 100644
index 0000000..41de113
--- /dev/null
+++ b/yourwork_1shot/sample/invoice_SaaS/customer.md
@@ -0,0 +1,14 @@
+## ターゲットの目的、背景、属性
+
+### **目的**
+従業員20〜50名の成長期スタートアップのCFO・経理責任者が、**バックオフィス業務の効率化とコスト削減**を実現し、月次決算の早期化と経営判断の迅速化を図ること。属人化した経費精算・請求書処理から脱却し、IPOや次回ラウンドの資金調達に向けた内部統制の基盤を整備する。
+
+### **背景（社内的状況）**
+先週の経営会議で、CEOから「月次決算の確定が毎月15日までかかっている。競合は5営業日で出している。なぜこんなに遅いのか」と指摘された。その夜、経理担当から「今月も経費精算が300件たまっています。領収書の写真が不鮮明で確認に時間がかかり、月末は毎日3時間残業です」とSlackが届く。翌日、営業マネージャーから「取引先から『請求書を送ったのにまだ支払われていない』とクレームが来た。確認したらメールが埋もれていた」と報告を受ける。CFOは「シリーズBの資金調達に向けて、VCから内部統制の整備を求められている。今の経費精算フローでは監査に耐えられない」と焦りを感じている。さらに、従業員から「経費申請が面倒すぎる。会計ソフトに二重入力するのはなぜ?」という不満の声が上がり、プロダクト開発に集中すべきエンジニアの時間が経理作業に奪われている現状に危機感を抱いている。
+
+### **属性**
+- **規模**: 従業員20〜50名の成長期スタートアップ（IT/SaaS、デザインエージェンシー、コンサルティング等）
+- **フェーズ**: シリーズA〜B調達済み、次ラウンド準備中またはIPO準備を見据えた段階
+- **課題**: 経費精算・請求書処理の属人化、月次決算の遅延、内部統制の未整備、バックオフィス業務への過剰な時間投下
+- **意思決定権限**: 財務・経理プロセスとツール選定の決定権を持つCFO、または経理・バックオフィス責任者
+- **予算制約**: 月額1〜5万円程度の予算枠、初期費用は極力抑えたい、ROIが3〜6ヶ月で見込めることが必須
\ No newline at end of file
diff --git a/yourwork_1shot/sample/invoice_SaaS/output.md b/yourwork_1shot/sample/invoice_SaaS/output.md
new file mode 100644
index 0000000..da0573f
--- /dev/null
+++ b/yourwork_1shot/sample/invoice_SaaS/output.md
@@ -0,0 +1,646 @@
+# バックオフィス効率化プロダクト - Discovery
+
+## Listen: カスタマージャーニー
+
+従業員20〜50名の成長期スタートアップのCFO・経理責任者が、バックオフィス業務の効率化とコスト削減を実現するまでの道のり。
+
+| 行動ステップ | 所要時間 | 費用 | 使用ツール | 感情（1-5） | 課題 | 顧客の声 |
+|------------|---------|------|-----------|-----------|------|---------|
+| 1. 経営会議で課題を突きつけられる | 1週間 | 0円 | Excel、Slack | 😰 2 | 月次決算が毎月15日までかかり、経営判断が遅れている。競合は5営業日で完了している。 | 「CEOから『なぜこんなに遅いのか』と指摘された。毎月300件の経費精算が溜まっていて、領収書が不鮮明で確認に3時間残業している。請求書の支払漏れでクレームも来た。もう限界だ」 |
+| 2. 現状の工数とコストを可視化する | 2週間 | 0円 | Excel、Google スプレッドシート | 😟 3 | 経費精算1件あたり15分、月300件で75時間。請求書処理1件10分、月150件で25時間。月次決算準備に2日。経理担当の残業月40時間。全て属人化している。 | 「工数を計算してみたら、経理担当が月100時間以上を単純作業に費やしていた。しかもExcelとメールと会計ソフトに同じデータを3回入力している。なんでこんな無駄な作業をしているんだろう」 |
+| 3. バックオフィスツールの情報収集 | 3週間 | 0円 | Google検索、比較サイト、知人紹介 | 😰 2 | 選択肢が多すぎて何を基準に選べばいいか分からない。マネーフォワード、freee、楽楽精算、ジョブカン...どれも似たような機能。価格帯もバラバラ。 | 「経費精算ツールだけで20個以上ある。競合比較表を見ても『○』ばかりで差が分からない。導入事例を読んでも『効率化された』という抽象的な話ばかり。結局どれが自社に合うのか判断できない」 |
+| 4. 3社のツールをトライアル | 4週間 | 0円 | マネーフォワード クラウド経費、楽楽精算、Concur | 😟 3 | トライアル設定だけで丸2日かかる。社内の協力者を募るのも一苦労。結局、経理担当と自分だけで試すことに。実際の運用イメージが掴めない。 | 「トライアルを始めたが、設定項目が多すぎて本業が進まない。承認フローの設定、勘定科目のマッピング、ユーザー登録...マニュアルを読んでも分からない用語ばかり。これ、本当に使いこなせるのか不安」 |
+| 5. マネーフォワード クラウド経費を導入 | 2週間 | 初期費用0円 + 年間50万円 | マネーフォワード クラウド経費 | 😊 4 | 既にマネーフォワード クラウド会計を使っているので連携は楽。ただし、初期設定と従業員向け説明会の準備に2週間かかった。 | 「導入は決めたものの、全従業員に使い方を教えるのが大変。説明資料を作って、オンボーディング会を3回開催。『なんで今更新しいツールを覚えないといけないんだ』という声も。でも、長期的には絶対に必要だと信じている」 |
+| 6. 社内展開とルール整備 | 1ヶ月 | 5万円（説明会の準備、マニュアル作成） | マネーフォワード クラウド経費、Slack、Notion | 😟 3 | 従業員の半分が新しいツールに抵抗感を示す。「面倒」「今まで通りでいい」という声。ルールを明文化しないと使ってもらえない。Slackで何度もリマインド。 | 「導入から1ヶ月経っても、まだ紙の領収書を持ってくる人がいる。『スマホで撮影して申請してください』と言っても『よく分からない』と。結局、経理担当が代わりに入力している。これじゃ効率化にならない」 |
+| 7. 運用定着と改善 | 2ヶ月 | 3万円（追加トレーニング、改善施策） | マネーフォワード クラウド経費、Slack、Google フォーム（フィードバック収集） | 😐 3 | 使い始めて2ヶ月で、ようやく8割の従業員が使うようになった。でも、まだ勘定科目の選択ミスや領収書の添付漏れが多い。月次決算は10日に短縮されたが、目標の5日にはまだ遠い。 | 「やっと軌道に乗ってきた感じ。経理担当の残業は月40時間から15時間に減った。でも、『なんでこの経費が却下されたのか分からない』という問い合わせが毎週来る。承認ルールをもっと明確にしないと」 |
+| 8. 継続的な改善とROI確認 | 3ヶ月 | 5万円（データ分析、改善施策） | マネーフォワード クラウド経費、Excel、BIツール | 😊 4 | 導入から半年。経費精算の処理時間が月75時間から20時間に73%削減。請求書処理も月25時間から10時間に60%削減。月次決算は7日に短縮。経理担当の残業はほぼゼロ。年間ROIは約200%。 | 「数字で見ると、明らかに効率化された。経理担当が『やっと経営分析に時間を使える』と喜んでいる。でも、正直に言うとツール費用が年間50万円かかっているので、従業員が100名になったら価格がさらに上がる。もっとコスパの良い選択肢があったかもしれない」 |
+
+**合計費用**: 年間63万円（ツール費用50万円 + 導入・運用費用13万円）
+**合計所要時間**: 約6ヶ月（調査・導入・定着まで）
+**ペインポイント数**: 5箇所（感情スコア3以下）
+
+---
+
+## Define: 常識を疑う問いの抽出
+
+Phase 1で特定した各行動ステップに対して、「なぜ〇〇せずに□□ができないのか?」「なぜ○○と○○は同時にできないのか?」の2種類の問いを立てる。
+
+| 行動ステップ | 問いの種類 | 問い | 現在の制約 |
+|------------|-----------|------|-----------|
+| 1. 経営会議で課題を突きつけられる | 省略型 | なぜ経営会議で指摘されてから初めて課題に気づくのか? 日常的にボトルネックを検知できないのか? | 経費精算・請求書処理の工数や遅延が可視化されていない。リアルタイムでの業務状況モニタリング機能がない |
+| 1. 経営会議で課題を突きつけられる | 統合型 | なぜ課題の認識と解決策の探索は同時にできないのか? | 課題が顕在化してから対策を考え始めるため、対応が後手に回る。予防的な改善提案がない |
+| 2. 現状の工数とコストを可視化する | 省略型 | なぜExcelで手作業集計せずに、自動で工数を可視化できないのか? | 各作業の時間を自動トラッキングする仕組みがない。経費精算システムと工数管理が分離している |
+| 2. 現状の工数とコストを可視化する | 統合型 | なぜ工数の可視化とツール選定は同時にできないのか? | 現状分析に2週間かかり、その後でツール探しを始めるため、意思決定が遅れる |
+| 3. バックオフィスツールの情報収集 | 省略型 | なぜ3週間もかけて情報収集せずに、自社に最適なツールを即座に推薦してもらえないのか? | 自社の業務フロー、規模、予算、技術スタックに基づいたパーソナライズされた推薦システムがない |
+| 3. バックオフィスツールの情報収集 | 統合型 | なぜツールの情報収集とトライアルは同時にできないのか? | ツールを選定してからトライアルを申し込むため、検証に時間がかかる。並行トライアルの仕組みがない |
+| 4. 3社のツールをトライアル | 省略型 | なぜ4週間もかけてトライアルせずに、1週間で比較評価できないのか? | トライアルごとに初期設定が必要。社内の協力者を募るのに時間がかかる。評価基準が曖昧 |
+| 4. 3社のツールをトライアル | 統合型 | なぜトライアルと社内教育は同時にできないのか? | トライアルを終えてから社内展開を考えるため、導入までの期間が長くなる |
+| 5. マネーフォワード クラウド経費を導入 | 省略型 | なぜ2週間かけて初期設定せずに、1日で使い始められないのか? | 承認フロー、勘定科目マッピング、ユーザー登録などの設定が複雑。テンプレートや自動設定がない |
+| 5. マネーフォワード クラウド経費を導入 | 統合型 | なぜツール導入と既存業務の並行運用は同時にできないのか? | 新ツールへの完全移行が前提。段階的移行や並行運用の設計がない |
+| 6. 社内展開とルール整備 | 省略型 | なぜ1ヶ月かけて社内展開せずに、全従業員が初日から直感的に使えないのか? | 説明会、マニュアル、繰り返しのリマインドが必要。UI/UXが複雑で学習コストが高い |
+| 6. 社内展開とルール整備 | 統合型 | なぜルール整備とツール導入は同時にできないのか? | ツールを触ってから問題点が分かり、ルールを後付けで作る。事前にルールを組み込んだ設定ができない |
+| 7. 運用定着と改善 | 省略型 | なぜ2ヶ月かけて定着させずに、初日から8割の従業員が活用できないのか? | 従業員の抵抗感、操作ミス、問い合わせ対応に時間がかかる。行動変容を促す仕組みがない |
+| 7. 運用定着と改善 | 統合型 | なぜ運用定着と効果測定は同時にできないのか? | 定着してから効果を測り始めるため、改善サイクルが遅い。リアルタイムKPI測定がない |
+| 8. 継続的な改善とROI確認 | 省略型 | なぜ3ヶ月かけてROI確認せずに、毎週自動でROIレポートを受け取れないのか? | データ分析とレポート作成が手作業。ROI計算ロジックが標準化されていない |
+| 8. 継続的な改善とROI確認 | 統合型 | なぜROI確認と次の改善施策の立案は同時にできないのか? | ROIを確認してから改善案を考え始めるため、改善サイクルが遅い。AIによる改善提案がない |
+
+**問いの総数**: 16個（各ステップ2問 × 8ステップ）
+
+---
+
+### Top 3 重要課題
+
+全16個の問いを「リソース削減効果（1-5点）」と「頻度（日次=5点/週次=3点/月次=1点）」で評価し、合計スコアの高い順にランキング。
+
+| 順位 | 問い | リソース削減効果 | 頻度 | 合計スコア | 選定理由 |
+|------|------|----------------|------|-----------|---------|
+| 1位 | なぜExcelで手作業集計せずに、自動で工数を可視化できないのか? | 5点（週10時間削減 = 年間520時間、約200万円相当） | 5点（毎日） | **10点** | 経理担当が毎日行う工数集計を自動化することで、最大のリソース削減効果が見込める。現状、経費精算1件15分×月300件=75時間、請求書処理10分×月150件=25時間を、自動トラッキングにより90%削減可能。年間約520時間（＝月40時間×13ヶ月相当）の削減は、経理担当1名の半分以上の工数に相当し、空いた時間を経営分析や予算管理に充てられる |
+| 2位 | なぜ3週間もかけて情報収集せずに、自社に最適なツールを即座に推薦してもらえないのか? | 5点（3週間 = 約120時間削減 + 意思決定の早期化により機会損失を回避） | 3点（ツール選定時 = 年1-2回だが、影響度大） | **8点** | ツール選定に3週間（約120時間）かかる現状を、AIパーソナライズ推薦により1日（8時間）に短縮できる。削減時間は約112時間。さらに、早期に最適なツールを導入できることで、6ヶ月の導入期間を3ヶ月に短縮でき、3ヶ月分の非効率な業務（月100時間×3ヶ月=300時間）を回避できる。合計約400時間の削減効果 |
+| 3位 | なぜ2週間かけて初期設定せずに、1日で使い始められないのか? | 4点（2週間 = 約80時間削減 + 導入スピード向上） | 3点（ツール導入時 = 年1-2回だが、全社展開に影響） | **7点** | 初期設定に2週間（約80時間）かかる現状を、自動設定とテンプレートにより1日（8時間）に短縮できる。削減時間は約72時間。さらに、導入期間が短縮されることで、社内展開がスムーズになり、全従業員の学習コストも削減される（50名×2時間=100時間の削減）。合計約170時間の削減効果 |
+
+**選定されなかった主な問いと理由**:
+- 「なぜ課題の認識と解決策の探索は同時にできないのか?」(スコア6点): リソース削減効果は大きいが、頻度が低い（月次）ため3位に届かず
+- 「なぜ1ヶ月かけて社内展開せずに、全従業員が初日から直感的に使えないのか?」(スコア7点): 3位と同スコアだが、初期設定の効率化の方が根本的な課題解決につながるため、優先度を下げた
+- 「なぜ4週間もかけてトライアルせずに、1週間で比較評価できないのか?」(スコア6点): トライアル期間の短縮は有効だが、Top3の問いと比較して削減効果が限定的
+
+**Top 3の合計削減効果**: 年間約1,090時間（≒ 月90時間）、金額換算で約400万円相当
+
+---
+
+## Invent: 解決策の考案
+
+Phase 3で選定したTop 3の問いに対して、solutions.mdのソリューションを組み合わせた解決策を考案。最低3つのブレイクスルーアイデアを含む。
+
+### 発明1: リアルタイム業務トラッキング・ダッシュボード（Top 1問いへの解決策）
+
+**対象となる問い**: なぜExcelで手作業集計せずに、自動で工数を可視化できないのか?
+
+**組み合わせるソリューション**:
+- ソリューション1: AI-OCR自動化アプローチ
+- ソリューション4: リアルタイム・ダッシュボード可視化アプローチ
+
+**新しい価値提案**:
+経費精算・請求書処理の一件一件に対して、AI-OCRが処理時間を自動トラッキングし、リアルタイムダッシュボードで「今この瞬間、どの業務にどれだけの時間がかかっているか」を可視化する。従来は月末にExcelで集計していた工数が、リアルタイムで把握できるようになり、ボトルネックを即座に検知して改善できる。
+
+具体的には:
+- OCR処理の開始〜完了までの時間を自動記録
+- 承認待ち時間、差し戻しによる再処理時間も可視化
+- 「経費精算1件あたりの平均処理時間」「今月の累計工数」「前月比」をリアルタイム表示
+- 「今週、経費精算に40時間使っています。先月より10時間増えています」といったAIインサイトを自動生成
+- 経理担当者だけでなく、CFOも経営ダッシュボードで業務効率をモニタリング可能
+
+**ブレイクスルー要素（該当フレームワーク: 時間軸の操作）**:
+従来は「月末に振り返って工数を集計する」という**後追い型**の管理だったが、これを「リアルタイムで業務を可視化する」**先回り型**に転換。問題が顕在化する前にボトルネックを発見し、予防的な改善ができる。
+
+さらに、**AI/自動化の創造的活用**として、単なる時間記録ではなく「なぜこの経費精算に15分もかかったのか?」を分析し、「領収書が不鮮明だったため」「勘定科目の選択ミスで差し戻しされたため」といった原因を自動特定して改善提案を行う。人間には気づきにくいパターンをAIが発見し、継続的な業務改善サイクルを実現する。
+
+**実装難易度**: 5 + 5 = 10/20（難易度スコアの合計）
+
+**実装期間の見積もり**: 約5ヶ月
+- AI-OCR基盤構築: 3.5ヶ月（ソリューション1）
+- ダッシュボード可視化: 5ヶ月（ソリューション4）
+- ただし、両者を並行開発し、OCR処理ログをダッシュボードに流し込む統合部分に1ヶ月追加
+- 合計: 5ヶ月（並行開発により短縮）
+
+**実現方法**:
+- フロントエンド: React + Recharts（データビジュアライゼーション）
+- バックエンド: AWS Lambda + API Gateway + DynamoDB（リアルタイムデータ処理）
+- OCR: Amazon Textract + 独自の処理時間トラッキングロジック
+- AIインサイト: Claude API（Anthropic）または OpenAI APIを活用した異常検知と解説文生成
+- 認証: Amazon Cognito
+
+**定量的な効果**:
+- 工数可視化の自動化により、月末の集計作業（2日間 = 16時間）がゼロに
+- ボトルネック早期発見により、経費精算処理時間が月75時間から20時間に73%削減（年間660時間削減）
+- 請求書処理時間も月25時間から10時間に60%削減（年間180時間削減）
+- 合計: 年間約856時間（≒ 月71時間）削減、金額換算で約320万円相当
+
+---
+
+### 発明2: AIパーソナライズド・ツール推薦エンジン（Top 2問いへの解決策）
+
+**対象となる問い**: なぜ3週間もかけて情報収集せずに、自社に最適なツールを即座に推薦してもらえないのか?
+
+**組み合わせるソリューション**:
+- ソリューション4: リアルタイム・ダッシュボード可視化アプローチ（データ分析基盤）
+- 新規要素: AIエージェントによるパーソナライズド推薦システム
+
+**新しい価値提案**:
+「従業員規模」「業種」「現在の会計ソフト」「予算」「技術スタック」「課題の優先順位」などの情報を入力すると、AIが自社に最適なバックオフィスツールを即座に推薦する。単なる機能比較ではなく、「なぜこのツールがあなたの会社に最適なのか」を具体的な数値（削減時間、ROI、導入期間）とともに説明する。
+
+具体的には:
+- 5分間の質問に答えるだけで、AIが最適なツールを3つ推薦
+- 推薦理由を「あなたの会社は従業員30名で、マネーフォワード クラウド会計を使っているため、マネーフォワード クラウド経費が最もシームレスに連携できます。導入期間は2週間、年間ROIは約200%見込めます」といった具体的な説明で提示
+- 競合ツールとの比較表を自動生成（価格、機能、導入期間、サポート体制）
+- ユーザーレビューから、同じような規模・業種の企業の実際の声を抽出して表示
+- トライアル申し込みリンクを自動生成し、即座に試せる
+
+**ブレイクスルー要素（該当フレームワーク: AI/自動化の創造的活用 + 時間軸の操作）**:
+従来は「ツールを調べて→比較して→トライアルして→決定する」という**順次実行**だったが、AIが「調査・比較・推薦」を**同時実行**することで、3週間を5分に圧縮。
+
+さらに、**異業種転用**として、Netflix の推薦アルゴリズムをB2B SaaSツール選定に適用。「このツールを選んだ企業は、こんな組み合わせで使っています」といった協調フィルタリングにより、最適な組み合わせも提案する。
+
+**実装難易度**: 5 + 3（新規要素）= 8/20
+
+**実装期間の見積もり**: 約4ヶ月
+- データ分析基盤: ソリューション4の一部を流用（1ヶ月）
+- AIエージェント開発: Claude API（Anthropic）を活用した質問生成・推薦ロジック構築（2ヶ月）
+- ツール情報データベース構築: 主要バックオフィスツール50社の情報収集とデータ構造化（1ヶ月）
+- 合計: 4ヶ月
+
+**実現方法**:
+- フロントエンド: React + 対話型UI（チャットボット形式）
+- バックエンド: AWS Lambda + API Gateway + DynamoDB
+- AI推薦エンジン: Claude API（Anthropic）を活用したパーソナライズド推薦
+- ツール情報データベース: DynamoDB + 定期的なスクレイピングによる情報更新
+- 認証: Amazon Cognito
+
+**定量的な効果**:
+- ツール選定期間が3週間（約120時間）から5分（0.08時間）に99.9%削減
+- 最適なツールを早期に導入できることで、導入期間が6ヶ月から3ヶ月に短縮
+- 非効率な業務の継続期間が3ヶ月短縮されることで、約300時間（月100時間×3ヶ月）の機会損失を回避
+- 合計: 約420時間削減、金額換算で約160万円相当
+
+---
+
+### 発明3: ゼロコンフィグ・インスタント導入システム（Top 3問いへの解決策）
+
+**対象となる問い**: なぜ2週間かけて初期設定せずに、1日で使い始められないのか?
+
+**組み合わせるソリューション**:
+- ソリューション1: AI-OCR自動化アプローチ
+- ソリューション3: 会計ソフト連携・自動仕訳アプローチ
+- ソリューション5: モバイルファースト・承認フローアプローチ
+
+**新しい価値提案**:
+既存の会計ソフトに接続するだけで、AIが過去の取引データを分析し、承認フロー・勘定科目マッピング・ユーザー権限を自動設定する「ゼロコンフィグ」を実現。従来は2週間かかっていた初期設定が、1時間で完了する。
+
+具体的には:
+- 会計ソフトのOAuth連携を行うと、AIが過去6ヶ月の取引データを分析
+- 「交通費の承認者は○○さん、会議費の承認者は△△さん」といった暗黙のルールをAIが発見し、承認フロー を自動生成
+- 過去の仕訳データから「この経費は○○の勘定科目に分類されている」というパターンを学習し、勘定科目マッピングを自動設定
+- 従業員リストを会計ソフトまたはSlackから自動インポートし、ユーザー登録とメール招待を一括実行
+- 設定完了後、従業員向けのオンボーディング動画と説明資料を自動生成（「あなたの会社の設定内容」をパーソナライズ）
+
+**ブレイクスルー要素（該当フレームワーク: 時間軸の操作 + 制約の武器化）**:
+従来は「ツールを導入してから設定を考える」という順序だったが、これを**逆転**させ、「既存の業務フローをAIが学習して、ツールを既存フローに合わせる」ことで、設定作業をゼロにする。
+
+さらに、**制約の武器化**として、「設定項目が多い」という従来のツールの弱点を、「AIが自動設定するため、ユーザーは何も考えなくていい」という差別化の源泉に転換。「設定の柔軟性」ではなく「設定の不要性」で勝負する。
+
+**実装難易度**: 5 + 3 + 3 = 11/20
+
+**実装期間の見積もり**: 約6ヶ月（ギリギリ開発期間内）
+- AI-OCR基盤: 3.5ヶ月（ソリューション1）
+- 会計ソフト連携: 2.5ヶ月（ソリューション3）
+- モバイルファースト・承認フロー: 4.5ヶ月（ソリューション5）
+- AI自動設定ロジック: 2ヶ月（既存の取引データ分析、パターン抽出、設定自動生成）
+- ただし、3つのソリューションを並行開発し、統合テストに1ヶ月追加
+- 合計: 6ヶ月（並行開発により短縮、ギリギリ期間内に収まる）
+
+**実現方法**:
+- フロントエンド: React（PWA）
+- バックエンド: AWS Lambda + API Gateway + DynamoDB
+- AI自動設定エンジン: Claude API（Anthropic）を活用した取引データ分析とパターン抽出
+- OCR: Amazon Textract
+- 会計ソフト連携: freee、マネーフォワード、弥生会計のAPI
+- Slack連携: Slack API
+- 認証: Amazon Cognito
+
+**定量的な効果**:
+- 初期設定期間が2週間（約80時間）から1時間に98.8%削減
+- 社内展開がスムーズになり、全従業員の学習コストが削減（50名×2時間=100時間）
+- 導入期間が短縮されることで、早期にROIを実現（3ヶ月早く効果が出ることで、経費精算・請求書処理の効率化効果が3ヶ月分前倒し = 約210時間の追加削減）
+- 合計: 約390時間削減、金額換算で約150万円相当
+
+---
+
+### 発明4: 🎲 ガチャ式経費精算ゲーミフィケーション（ブレイクスルーアイデア）
+
+**対象となる問い**: Phase 1の課題「なぜ従業員は経費申請を『面倒』と感じるのか?」
+
+**組み合わせるソリューション**:
+- ソリューション1: AI-OCR自動化アプローチ
+- ソリューション5: モバイルファースト・承認フローアプローチ
+- 新規要素: ゲーミフィケーション
+
+**新しい価値提案**:
+経費精算を「面倒な作業」から「楽しいゲーム」に変える。領収書を撮影して申請すると、ガチャが回り、ランダムで「即時承認チケット」「ポイント」「バッジ」などの報酬が当たる。月間で最も多く申請した従業員は「経費マスター」として表彰され、社内Slackで発表される。
+
+具体的には:
+- 経費申請を行うたびに、ガチャが1回回せる
+- ガチャで当たる報酬: 「即時承認チケット」（通常の承認フローをスキップ）、「早期振込チケット」（通常月末振込が翌週に早まる）、「社内ポイント」（社内の自販機やカフェで使える）、「レアバッジ」（プロフィールに表示される称号）
+- 月間ランキング: 申請件数、承認スピード、勘定科目の正確性などを競う
+- チーム対抗戦: 部門ごとに「経費精算完了率」を競い、優勝部門には「部門ランチ補助」などの特典
+
+**ブレイクスルー要素（該当フレームワーク: 異業種転用 + 感情の逆流）**:
+ゲーム業界の**ガチャ要素**をB2B SaaSに適用し、「面倒な作業」というネガティブな感情を「楽しい体験」に転換。経費精算が「やらなければいけないタスク」から「やりたくなるゲーム」に変わる。
+
+さらに、**心理的報酬**により、行動変容を促進。従業員が「早く申請したい」と思うようになり、経理担当者の「リマインド業務」が不要になる。
+
+**実装難易度**: 5 + 3 + 2（ゲーミフィケーション機能）= 10/20
+
+**実装期間の見積もり**: 約5ヶ月
+- AI-OCR基盤: 3.5ヶ月（ソリューション1）
+- モバイルファースト・承認フロー: 4.5ヶ月（ソリューション5）
+- ゲーミフィケーション機能: 1.5ヶ月（ガチャシステム、ランキング、バッジ管理、Slack通知）
+- ただし、並行開発により、合計5ヶ月に短縮
+
+**実現方法**:
+- フロントエンド: React（PWA）+ ガチャアニメーション（Lottie）
+- バックエンド: AWS Lambda + API Gateway + DynamoDB
+- ガチャシステム: ランダム報酬生成ロジック（確率調整可能）
+- ランキング: リアルタイム集計とリーダーボード表示
+- Slack連携: ランキング発表、バッジ取得通知
+- 認証: Amazon Cognito
+
+**定量的な効果**:
+- 従業員の経費申請率が60%から95%に向上（申請漏れの削減）
+- 申請〜承認までの時間が平均2日から半日に短縮（従業員が早く申請するようになるため）
+- 経理担当者のリマインド業務がゼロに（月5時間削減 = 年間60時間削減）
+- 従業員満足度の向上により、離職率が低下（定量化は困難だが、副次的効果として大きい）
+- 合計: 約60時間削減、金額換算で約20万円相当（ただし、従業員満足度の向上は金額換算困難）
+
+**注意点**: ガチャ要素は「ギャンブル性」を連想させるため、企業文化によっては受け入れられない可能性がある。トライアルで反応を見て、導入可否を判断する必要がある。
+
+---
+
+### 発明5: 🔮 AIが先読みする「未来の経費レポート」（ブレイクスルーアイデア）
+
+**対象となる問い**: Phase 1の課題「なぜ経営会議で指摘されてから初めて課題に気づくのか?」
+
+**組み合わせるソリューション**:
+- ソリューション4: リアルタイム・ダッシュボード可視化アプローチ
+- 新規要素: 予測分析とAI警告システム
+
+**新しい価値提案**:
+過去の経費データと現在のトレンドから、AIが「来月の経費は今月より30万円増えそうです」「このペースだと、年度末に予算を50万円オーバーします」といった**未来予測**を行い、問題が顕在化する前に警告する。経営会議で指摘される前に、CFOが先手を打って対策できる。
+
+具体的には:
+- 毎月1日に、「今月の経費予測レポート」を自動生成してCFOに送信
+- 「今月は出張が多いため、交通費が通常より20万円増える見込みです」「先月と同じペースだと、会議費が予算を10万円オーバーします」といった予測と警告
+- 予算オーバーのリスクがある場合、「会議費を削減するには、カフェでの打ち合わせをオンライン会議に切り替えることで月5万円削減可能です」といった具体的な改善提案
+- シナリオ分析: 「もし新規採用を5名増やしたら、経費はどのくらい増えるか?」といったシミュレーションが可能
+- AIが「人間らしくない提案」をあえてすることで、思考の幅を広げる（例: 「交通費を削減するために、全員に自転車を配布してはどうか?」といった大胆な提案）
+
+**ブレイクスルー要素（該当フレームワーク: 時間軸の操作 + AI/自動化の創造的活用）**:
+従来は「経営会議で指摘されてから対応する」という**後追い型**だったが、AIが**未来を予測**することで**先回り型**の経営判断が可能になる。
+
+さらに、**AI/自動化の創造的活用**として、AIが「人間には思いつかない提案」をあえてすることで、思考の幅を広げる。単なる効率化ではなく、「新しい視点」を提供する。
+
+**実装難易度**: 5 + 3（予測分析機能）= 8/20
+
+**実装期間の見積もり**: 約5ヶ月
+- ダッシュボード基盤: 5ヶ月（ソリューション4）
+- 予測分析機能: 2ヶ月（時系列予測モデル、シナリオ分析、改善提案生成）
+- ただし、並行開発により、合計5ヶ月に短縮
+
+**実現方法**:
+- フロントエンド: React + Recharts
+- バックエンド: AWS Lambda + API Gateway + DynamoDB
+- 予測分析: AWS Forecast（時系列予測）または独自の機械学習モデル
+- AIインサイト: Claude API（Anthropic）を活用した改善提案生成
+- レポート自動送信: AWS SES（メール）+ Slack API
+- 認証: Amazon Cognito
+
+**定量的な効果**:
+- 予算オーバーの早期検知により、年間約50万円のコスト削減
+- 経営会議での準備時間が1日（8時間）から30分に削減（月1回 = 年間約85時間削減）
+- シナリオ分析により、新規採用や事業拡大の意思決定がスピーディーに（定量化困難だが、戦略的価値大）
+- 合計: 約85時間削減 + 約50万円のコスト削減
+
+---
+
+### 発明の選定と優先順位
+
+**実装可能性と効果の総合評価**:
+
+| 発明 | 実装難易度 | 実装期間 | 削減効果（時間） | 削減効果（金額） | 優先度 |
+|------|-----------|---------|---------------|---------------|-------|
+| 1. リアルタイム業務トラッキング・ダッシュボード | 10/20 | 5ヶ月 | 年間856時間 | 約320万円 | ⭐️⭐️⭐️ 最優先 |
+| 2. AIパーソナライズド・ツール推薦エンジン | 8/20 | 4ヶ月 | 約420時間 | 約160万円 | ⭐️⭐️ 高優先度 |
+| 3. ゼロコンフィグ・インスタント導入システム | 11/20 | 6ヶ月 | 約390時間 | 約150万円 | ⭐️⭐️ 高優先度 |
+| 4. ガチャ式経費精算ゲーミフィケーション | 10/20 | 5ヶ月 | 約60時間 | 約20万円 | ⭐️ 中優先度 |
+| 5. AIが先読みする「未来の経費レポート」 | 8/20 | 5ヶ月 | 約85時間 | 約50万円コスト削減 | ⭐️⭐️ 高優先度 |
+
+**Phase 6のPR/FAQ作成対象**: 発明1「リアルタイム業務トラッキング・ダッシュボード」を選定
+
+**選定理由**:
+- Top 1の問いに対する解決策であり、最大のリソース削減効果（年間856時間、約320万円）が見込める
+- customer.mdで定義された顧客の最大の課題「月次決算の遅延」「経理担当者の過剰な残業」を直接解決する
+- 実装期間が5ヶ月で、6ヶ月の開発期間内に収まる
+- 他の発明（発明2、5）と組み合わせることで、さらに価値を高められる拡張性がある
+
+# プレスリリース: BackOffice Insight - バックオフィス業務の「見えない時間」を可視化する、リアルタイム業務トラッキング・ダッシュボード
+
+**スタートアップの月次決算を10日から5日に短縮し、経理担当者の残業をゼロにする**
+
+---
+
+## プレスリリース本文
+
+**東京、2025年XX月XX日** - 本日、BackOffice Insightは、従業員20〜50名の成長期スタートアップ向けに、バックオフィス業務のリアルタイム可視化ダッシュボードをローンチします。「なぜExcelで手作業集計せずに、自動で工数を可視化できないのか?」という問いに答え、経費精算・請求書処理の一件一件にかかる時間を自動トラッキングし、ボトルネックを即座に発見・改善できるようにします。
+
+従来、バックオフィス業務の工数は「月末にExcelで振り返って集計する」という後追い型の管理が常識でした。しかし、BackOffice Insightは、AI-OCRと機械学習を活用し、処理の開始〜完了までの時間をリアルタイムで記録・可視化することで、問題が顕在化する前にボトルネックを発見する「先回り型」の管理を実現します。AIが「なぜこの経費精算に15分もかかったのか?」を自動分析し、「領収書が不鮮明」「勘定科目の選択ミス」といった原因を特定して改善提案を行うため、人間には気づきにくいパターンを発見できます。
+
+BackOffice Insightの導入により、経費精算処理時間が月75時間から20時間に73%削減（年間660時間削減）、請求書処理時間が月25時間から10時間に60%削減（年間180時間削減）され、合計年間約856時間（≒ 月71時間）、金額換算で約320万円相当のリソース削減を実現します。月次決算の確定日数が15日から7日に短縮され、経営判断のスピードが飛躍的に向上します。
+
+BackOffice Insightは、月額2.9万円（従業員50名まで）からご利用いただけます。今すぐ https://backoffice-insight.example.com から無料トライアルを開始できます。
+
+---
+
+### 顧客の声
+
+**「経営会議で『なぜこんなに遅いのか』と指摘されていた私たちが、今では5営業日で月次決算を完了しています」**
+
+従業員35名のSaaS企業のCFO、田中太郎氏は次のように語ります。「先週の経営会議で、CEOから『月次決算の確定が毎月15日までかかっている。競合は5営業日で出している。なぜこんなに遅いのか』と指摘されました。その夜、経理担当から『今月も経費精算が300件たまっています。領収書の写真が不鮮明で確認に時間がかかり、月末は毎日3時間残業です』とSlackが届きました。何か手を打たないと、と思っていた矢先にBackOffice Insightに出会いました。」
+
+「導入後3ヶ月で、経費精算処理時間が月75時間から20時間に73%削減されました。経理担当の残業がほぼゼロになり、『やっと経営分析に時間を使える』と喜んでいます。リアルタイムダッシュボードで『今、どの業務にどれだけ時間がかかっているか』が見えるようになったことで、ボトルネックを即座に発見して改善できるようになりました。月次決算は7日に短縮され、CEOからも『経営判断が早くなった』と評価されています。年間約320万円相当のコスト削減は、シリーズBの資金調達に向けた内部統制の整備にも貢献しています。」
+
+**「工数集計に丸2日かけていた私たちが、今ではリアルタイムでダッシュボードを見るだけになりました」**
+
+従業員28名のデザインエージェンシーの経理責任者、佐藤花子氏は次のように語ります。「以前は、月末になるとExcelで経費精算と請求書処理の工数を手作業で集計していました。1件ずつ処理時間を記録し、集計するだけで丸2日（16時間）かかっていました。しかも、集計が終わった頃には月末は過ぎており、ボトルネックに気づいても後の祭りでした。」
+
+「BackOffice Insightを導入してからは、AI-OCRが処理時間を自動トラッキングしてくれるため、工数集計作業がゼロになりました。ダッシュボードを見れば、『経費精算1件あたりの平均処理時間』『今月の累計工数』『前月比』がリアルタイムで分かります。『今週、経費精算に40時間使っています。先月より10時間増えています』といったAIインサイトが自動生成されるため、問題が大きくなる前に対策を打てます。請求書の支払漏れもゼロになり、取引先からのクレームが完全に消失しました。空いた時間をプロジェクト別のコスト分析に充てられるようになり、CFOから『経営に貢献している』と評価されています。」
+
+---
+
+### 使い方はシンプル
+
+BackOffice Insightの導入は、わずか3ステップで完了します。
+
+**1. 会計ソフトに接続（5分）**
+既にご利用中のマネーフォワード クラウド会計、freee、または弥生会計オンラインにOAuth連携で接続するだけ。過去の取引データを分析し、勘定科目マッピングを自動設定します。
+
+**2. 従業員を招待（5分）**
+Slackまたはメールで従業員を一括招待。スマホアプリまたはPWAで、いつでもどこでも経費精算・請求書処理が可能になります。
+
+**3. 領収書を撮影（3秒）**
+スマホで領収書を撮影すると、AI-OCRが3秒以内に金額・日付・店舗名・品目を自動抽出。過去の申請履歴から最適な勘定科目を自動提案します。処理時間は自動トラッキングされ、リアルタイムダッシュボードで可視化されます。
+
+従業員20〜50名の成長期スタートアップのCFO・経理責任者であれば、「月次決算の早期化」「経理担当者の残業削減」「内部統制の整備」という3つの課題を同時に解決できます。従来は経費精算処理に月75時間、請求書処理に月25時間かかっていたのが、BackOffice Insightの導入により、それぞれ20時間、10時間に削減されます。年間約856時間（≒ 月71時間）、金額換算で約320万円相当のリソース削減を実現できます。
+
+---
+
+## 顧客向けFAQ（Customer FAQs）
+
+### 一般（General）
+
+**1. BackOffice Insightとは何ですか?**
+BackOffice Insightは、従業員20〜50名の成長期スタートアップ向けに、経費精算・請求書処理のリアルタイム可視化ダッシュボードを提供するSaaSプロダクトです。AI-OCRと機械学習を活用し、バックオフィス業務の一件一件にかかる時間を自動トラッキングし、ボトルネックを即座に発見・改善できるようにします。
+
+**2. BackOffice Insightで何ができますか?**
+BackOffice Insightを使うと、以下のことが可能になります:
+- 経費精算・請求書処理の時間を自動トラッキングし、リアルタイムダッシュボードで可視化
+- 「経費精算1件あたりの平均処理時間」「今月の累計工数」「前月比」をリアルタイム表示
+- AIが「なぜこの経費精算に15分もかかったのか?」を分析し、「領収書が不鮮明」「勘定科目の選択ミス」といった原因を特定
+- 経費精算処理時間を月75時間から20時間に73%削減、請求書処理時間を月25時間から10時間に60%削減
+- 月次決算の確定日数を15日から7日に短縮
+- ボトルネックを早期発見し、予防的な改善ができる
+
+典型的なユースケース:
+- シリーズA〜B調達済みの成長期スタートアップのCFOが、月次決算の早期化と経営判断のスピード向上を実現
+- 経理担当者が、月40時間の残業をゼロにし、経営分析や予算管理といった戦略的業務に時間を充てられるようになる
+- IPO準備中の企業が、VCから求められる内部統制の整備を進め、次回ラウンドの資金調達に向けた準備を加速
+
+**3. 他のバックオフィスツールとの違いは何ですか?**
+BackOffice Insightは、「リアルタイム業務トラッキング」という独自の価値提案を持っています。マネーフォワード クラウド経費や楽楽精算は、経費精算・請求書処理の「入力」と「承認」を効率化しますが、「どの業務にどれだけ時間がかかっているか」を可視化する機能はありません。BackOffice Insightは、AI-OCRで処理時間を自動トラッキングし、ボトルネックを即座に発見できるため、継続的な業務改善サイクルを実現できます。
+
+また、BackOffice Insightは以下の点でも差別化されています:
+- **AIインサイト**: 「今週、経費精算に40時間使っています。先月より10時間増えています」といった異常検知と解説文を自動生成
+- **ゼロコンフィグ導入**: 会計ソフトに接続するだけで、過去の取引データを分析し、勘定科目マッピングを自動設定。初期設定が1時間で完了
+- **シンプルな価格設定**: 月額2.9万円（従業員50名まで）の定額制。従業員数が増えても価格が跳ね上がらない
+
+---
+
+### 価格（Pricing）
+
+**4. BackOffice Insightの価格はいくらですか?**
+BackOffice Insightは、以下の価格体系で提供されます:
+- **スタータープラン**: 月額2.9万円（従業員50名まで、年間契約の場合は月額2.5万円）
+- **グロースプラン**: 月額5.9万円（従業員100名まで、年間契約の場合は月額5.0万円）
+- **初期費用**: 0円
+- **無料トライアル**: 14日間（クレジットカード登録不要）
+
+すべてのプランに以下が含まれます:
+- AI-OCR自動化（経費精算・請求書処理）
+- リアルタイム業務トラッキング・ダッシュボード
+- 会計ソフト連携（freee、マネーフォワード、弥生会計）
+- モバイルアプリ（PWA）
+- AIインサイト自動生成
+- メール・チャットサポート
+
+**5. 他のツールと比べて、BackOffice Insightのコストメリットは何ですか?**
+従来のバックオフィスツール（例: マネーフォワード クラウド経費）は、月額3,980円〜ですが、従業員数が増えると従量課金で価格が上昇します。従業員50名の場合、月額約5万円〜6万円になることもあります。
+
+一方、BackOffice Insightは従業員50名まで月額2.9万円の定額制です。さらに、以下の削減効果により、実質的なコストメリットは非常に大きくなります:
+- 経費精算処理時間: 月75時間 → 20時間（55時間削減）
+- 請求書処理時間: 月25時間 → 10時間（15時間削減）
+- 月次決算準備: 2日（16時間）→ ゼロ（16時間削減）
+- 合計: 月86時間削減、年間約1,032時間削減
+
+時給3,000円で計算すると、年間約310万円のコスト削減です。BackOffice Insightの年間コスト（月額2.9万円×12ヶ月=34.8万円）を差し引いても、約275万円の純削減効果があります。投資回収期間は約1.3ヶ月です。
+
+**6. 無料トライアル期間中に何ができますか?**
+14日間の無料トライアル期間中、すべての機能を制限なくご利用いただけます:
+- 最大50名の従業員を招待可能
+- 会計ソフト連携（freee、マネーフォワード、弥生会計）
+- AI-OCR自動化（経費精算・請求書処理）
+- リアルタイムダッシュボード
+- AIインサイト自動生成
+- メール・チャットサポート
+
+トライアル期間中にクレジットカードの登録は不要です。トライアル終了後、自動的に課金されることはありません。
+
+---
+
+### はじめ方（Getting Started）
+
+**7. BackOffice Insightを使い始めるには何が必要ですか?**
+BackOffice Insightを始めるために必要なものは、以下の3つだけです:
+1. **会計ソフト**: freee、マネーフォワード クラウド会計、または弥生会計オンラインのアカウント
+2. **メールアドレス**: 従業員を招待するためのメールアドレス
+3. **スマホまたはPC**: 経費精算・請求書処理を行うデバイス
+
+特別なハードウェアやソフトウェアのインストールは不要です。Webブラウザまたはスマホアプリ（PWA）で、いつでもどこでも利用できます。
+
+**8. 導入にはどのくらいの時間がかかりますか?**
+BackOffice Insightの導入は、わずか10分で完了します:
+1. 会計ソフトに接続（5分）: OAuth連携で会計ソフトに接続するだけ。過去の取引データを分析し、勘定科目マッピングを自動設定します。
+2. 従業員を招待（5分）: Slackまたはメールで従業員を一括招待。
+
+従来のツール（例: マネーフォワード クラウド経費）では、初期設定に2週間（約80時間）かかることもありますが、BackOffice Insightは「ゼロコンフィグ」設計により、AIが自動設定するため、設定作業がほぼゼロです。
+
+**9. 既存の会計ソフトから移行する必要がありますか?**
+いいえ、既存の会計ソフトから移行する必要はありません。BackOffice Insightは、freee、マネーフォワード クラウド会計、弥生会計オンラインと連携するため、既存の会計ソフトをそのまま使い続けられます。経費精算・請求書処理のデータは、自動的に会計ソフトに仕訳として送信されます。
+
+---
+
+### BackOffice Insightの使用（Using BackOffice Insight）
+
+**10. AI-OCRはどのくらい正確ですか?**
+BackOffice InsightのAI-OCRは、Amazon Textractを活用し、金額・日付・店舗名・品目の認識精度が平均98%以上です。画像補正機能により、斜めや暗い写真でも高精度で読み取りが可能です。
+
+認識ミスがあった場合でも、経理担当者が手動で修正できます。修正データは機械学習モデルにフィードバックされ、使えば使うほど精度が向上します。
+
+**11. オフラインでも使えますか?**
+はい、BackOffice InsightのモバイルアプリはPWA（Progressive Web App）として提供されており、オフラインでも経費精算・請求書処理が可能です。オフライン時に撮影・入力したデータは、ローカルストレージに一時保存され、オンラインに戻ると自動的に同期されます。
+
+これにより、飛行機や新幹線の移動中でも経費申請が可能になり、月末の申請集中が緩和されます。
+
+**12. 複数の会計ソフトを同時に連携できますか?**
+いいえ、現時点では1つの会計ソフトのみ連携可能です。将来的には、複数の会計ソフトに対応する予定です。
+
+**13. 承認フローをカスタマイズできますか?**
+はい、BackOffice Insightは柔軟な承認フロー設定が可能です:
+- 金額に応じた承認ルート（例: 1万円未満は上長承認のみ、1万円以上は部長承認が必要）
+- 部門に応じた承認ルート（例: 営業部は営業マネージャー承認、エンジニア部はCTO承認）
+- 複数承認者の設定（例: 5万円以上はCFOの最終承認が必要）
+
+ただし、現時点では「ゼロコンフィグ」設計のため、AIが過去の取引データから暗黙のルールを発見し、承認フローを自動生成します。カスタマイズが必要な場合は、管理画面から手動で設定できます。
+
+**14. Slack以外のチャットツールと連携できますか?**
+現時点では、Slackのみ連携可能です。Microsoft Teamsやその他のチャットツールへの対応は、今後のロードマップに含まれています。
+
+---
+
+### 制限と制約（Limits and Restrictions）
+
+**15. BackOffice Insightには何か制限がありますか?**
+BackOffice Insightには、以下の制限があります:
+- **対応する会計ソフト**: freee、マネーフォワード クラウド会計、弥生会計オンラインのみ。勘定奉行などのオンプレミス会計ソフトには対応していません。
+- **対応言語**: 日本語のみ。英語や他の言語には対応していません。
+- **電子帳簿保存法対応**: 対応していますが、タイムスタンプ機能は外部サービス（クラウドタイムスタンプ）を利用します。
+- **スケーラビリティ**: 従業員100名までは快適に動作しますが、それを超える場合はグロースプラン以上への移行が必要です。
+
+**16. 請求書の自動取り込みに対応していますか?**
+はい、BackOffice Insightは請求書の自動取り込みに対応しています。専用メールアドレスに請求書PDFを転送、またはGoogle Drive / Dropboxの特定フォルダに保存すると、AI-OCRが請求書番号・請求元・金額・支払期限・振込先を自動抽出します。
+
+ただし、現時点では日本語の請求書フォーマットのみ対応しています。英語の請求書や海外の請求書には対応していません。
+
+**17. 従業員100名以上の企業でも使えますか?**
+はい、グロースプラン（月額5.9万円、従業員100名まで）をご利用いただけます。それを超える規模の企業には、エンタープライズプランをご用意しています。詳細はお問い合わせください。
+
+---
+
+### パフォーマンス（Performance）
+
+**18. 経費精算1件あたりの処理時間はどのくらいですか?**
+BackOffice Insight導入前は、経費精算1件あたり平均15分かかっていましたが、導入後は平均4分に短縮されます（73%削減）。内訳は以下の通りです:
+- 領収書撮影〜AI-OCR認識: 3秒
+- 勘定科目の自動提案: 1秒
+- 従業員による確認・送信: 2分
+- 経理担当者による承認: 2分
+
+従来は、領収書の手入力（5分）、勘定科目の選択（3分）、会計ソフトへの二重入力（5分）、差し戻し対応（2分）で合計15分かかっていましたが、AI-OCRと会計ソフト連携により、これらが大幅に短縮されます。
+
+**19. 月次決算はどのくらい改善されますか?**
+BackOffice Insight導入前は、月次決算の確定に平均15日かかっていましたが、導入後は7日に短縮されます（53%改善）。これにより、経営判断のスピードが飛躍的に向上します。
+
+改善の内訳:
+- 経費精算の締め処理: 3日 → 1日（経理担当者の確認作業が自動化されるため）
+- 請求書の支払処理: 2日 → 0.5日（支払期限の自動リマインダーにより、支払漏れがゼロに）
+- データ集計と確認: 2日 → ゼロ（リアルタイムダッシュボードで常に最新の状況が把握できるため）
+- 会計ソフトへの仕訳入力: 3日 → ゼロ（自動連携により二重入力が撤廃）
+- その他調整: 5日 → 5.5日（若干増えるが、全体としては大幅短縮）
+
+**20. 応答速度はどのくらいですか?**
+BackOffice Insightは、AWS Lambdaベースのサーバーレスアーキテクチャを採用しているため、高速な応答を実現しています:
+- 経費精算の申請: 平均200ms以内
+- AI-OCR処理: 平均3秒以内
+- ダッシュボードの読み込み: 平均500ms以内
+- 会計ソフトへの仕訳送信: 平均1秒以内
+
+初回アクセス時やサービス未使用時の起動時（コールドスタート）は、若干遅延する場合がありますが、通常使用時は非常に高速です。
+
+---
+
+## 社内向けFAQ（Internal FAQs）
+
+### 1. いつ顧客にBackOffice Insightを勧める/勧めないべきですか?
+
+**BackOffice Insightを勧めるべき顧客**:
+- **従業員20〜50名の成長期スタートアップのCFO・経理責任者**: シリーズA〜B調達済み、次ラウンド準備中またはIPO準備を見据えた段階
+- **月次決算の遅延に悩んでいる顧客**: 月次決算が毎月15日までかかり、経営判断が遅れている
+- **経理担当者の残業が多い顧客**: 経費精算・請求書処理で毎月40時間以上の残業が発生している
+- **内部統制の整備が必要な顧客**: VCから内部統制の整備を求められている
+- **既にfreee、マネーフォワード、弥生会計を使っている顧客**: 会計ソフト連携がスムーズ
+- **バックオフィス業務の効率化とコスト削減を実現したい顧客**: 年間約320万円相当のコスト削減を見込める
+
+**BackOffice Insightを勧めるべきでない顧客**:
+- **従業員10名未満の超小規模企業**: 経費精算・請求書処理の件数が少なく、ROIが見込めない
+- **従業員100名以上の大企業**: 楽楽精算などの大規模カスタマイズ対応ツールの方が適している
+- **オンプレミス会計ソフト（勘定奉行等）を使っている顧客**: BackOffice Insightはクラウド会計ソフトのみ対応
+- **複雑な承認フローや組織構造を持つ顧客**: 現時点でのカスタマイズ性は限定的（ゼロコンフィグ設計のため）
+- **英語や他の言語での利用を希望する顧客**: 現時点では日本語のみ対応
+- **「設定の柔軟性」を重視する顧客**: BackOffice Insightは「設定の不要性」で差別化しているため、細かい設定を求める顧客には不向き
+
+---
+
+### 2. BackOffice Insightの指針（Tenets）は何ですか?
+
+私たちの指針は、より良いものを知らない限り、以下の通りです：
+
+* **リアルタイム可視化で、問題が顕在化する前に改善する** – 従来の「月末に振り返って工数を集計する」という後追い型の管理から、「リアルタイムで業務を可視化する」先回り型の管理に転換します。ボトルネックを即座に発見し、予防的な改善ができる環境を提供します。
+
+* **設定の不要性で、導入初日から価値を提供する** – 「設定項目が多い」という従来のツールの弱点を、「AIが自動設定するため、ユーザーは何も考えなくていい」という差別化の源泉に転換します。ゼロコンフィグ設計により、会計ソフトに接続するだけで1時間で使い始められます。
+
+* **AIが人間には気づきにくいパターンを発見する** – 単なる時間記録ではなく、「なぜこの経費精算に15分もかかったのか?」を分析し、原因を自動特定して改善提案を行います。AIの力で、継続的な業務改善サイクルを実現します。
+
+* **CFOと経理担当者の両方に価値を提供する** – CFOには経営判断のための早期データ提供、経理担当者には単純作業からの解放を提供します。バックオフィス業務を「コストセンター」から「戦略的パートナー」に変革します。
+
+* **実装可能性とスケーラビリティを両立する** – AWS既存技術を活用し、3名体制・6ヶ月で実装可能な設計を維持します。サーバーレスアーキテクチャにより、従業員10名から100名まで、同じ品質のサービスを提供します。
+
+---
+
+### 3. 顧客体験を改善するために測定・最適化する運用指標は何ですか?
+
+私たちは、BackOffice Insightの顧客体験を以下の3つの重要な次元で最適化します：_処理時間削減率_、_月次決算早期化日数_、_ボトルネック検知速度_。また、4つ目の指標として_顧客満足度（NPS）_を監視し、顧客体験を保護します。
+
+**処理時間削減率**
+- 内部指標: 経費精算1件あたりの処理時間（目標: 4分以内）、請求書処理1件あたりの処理時間（目標: 2分以内）
+- 顧客に公開する指標: 「導入前と比較して処理時間XX%削減」をダッシュボードで表示
+- 測定方法: AI-OCRの処理開始〜完了までの時間を自動記録し、日次・週次・月次で集計
+- Phase 1のカスタマージャーニーで特定された「経費精算1件15分、月300件で75時間」という課題の解決度合いを測定
+
+**月次決算早期化日数**
+- 内部指標: 月末から月次決算確定までの日数（目標: 7日以内）
+- 顧客に公開する指標: 「導入前と比較して月次決算がXX日早まりました」をダッシュボードで表示
+- 測定方法: 会計ソフトへの仕訳送信完了日を基準に、月次決算確定日までの日数を測定
+- Phase 3-Top 1の問い「なぜExcelで手作業集計せずに、自動で工数を可視化できないのか?」の解決効果を測定
+
+**ボトルネック検知速度**
+- 内部指標: ボトルネック発生から検知までの時間（目標: リアルタイム、つまり0秒）
+- 顧客に公開する指標: 「今週のボトルネック: 経費精算の承認待ち時間が平均2時間増加」をダッシュボードで表示
+- 測定方法: AIが処理時間の異常値を検知し、アラートを発するまでの時間を測定
+- Phase 5の新しい価値提案「リアルタイム業務トラッキング」の実現度合いを測定
+
+**顧客満足度（NPS）**
+- 内部指標: Net Promoter Score（目標: 50以上）
+- 測定方法: 四半期ごとにNPSアンケートを実施し、「BackOffice Insightを友人や同僚に勧める可能性は?」を10点満点で評価
+- 顧客の声を収集し、プロダクト改善に反映
+
+---
+
+### 4. BackOffice Insightはどのようにして顧客のコストを削減できますか?
+
+BackOffice Insightは、fine-grained（きめ細かい）な従業員数ベースの価格設定を提供します。年間約856時間（≒ 月71時間）、金額換算で約320万円相当のリソース削減により、顧客は月次決算準備に2日（16時間）かかっていた工数をゼロに、経費精算処理時間を月75時間から20時間に、請求書処理時間を月25時間から10時間に削減できます。
+
+**小〜中規模の顧客**（従業員20〜50名）は、月額2.9万円の定額制の恩恵を受けます。従業員数が増えても価格が跳ね上がらないため、成長期のスタートアップにとって予算管理がしやすくなります。経費精算・請求書処理の件数が少ない時期でも、リアルタイム可視化機能を犠牲にすることなく、定額で利用できます。
+
+**大規模顧客**（従業員50〜100名）は、グロースプラン（月額5.9万円）の恩恵を受けます。サーバーレスアーキテクチャにより、従業員数が増えてもパフォーマンスが劣化しません。スパイキーなワークロード（月末の経費精算集中）や異種混在のワークロード（経費精算と請求書処理）も、AWS Lambdaの自動スケーリングにより効率的に処理でき、年間約320万円相当のリソース削減を実現できます。
+
+BackOffice Insightはまた、AI-OCR、会計ソフト連携、リアルタイムダッシュボードを統合することで、Phase 1で要していた「複数ツールの使い分け」（Excel、会計ソフト、メール、Slack）を撤廃し、TCO（総所有コスト）を下げることができます。従業員20〜50名の成長期スタートアップのCFO・経理責任者にとって、「月次決算の遅延」「経理担当者の過剰な残業」「内部統制の未整備」は大きな課題でしたが、BackOffice Insightはリアルタイム業務トラッキングにより、年間約320万円相当のリソース削減を実現します。
+
+投資回収期間は約1.3ヶ月で、初月からROIを実感できます。
+
+---
+
+## 終わりに
+
+BackOffice Insightは、従業員20〜50名の成長期スタートアップのCFO・経理責任者が、バックオフィス業務の効率化とコスト削減を実現し、月次決算の早期化と経営判断の迅速化を図るための、リアルタイム業務トラッキング・ダッシュボードです。
+
+「なぜExcelで手作業集計せずに、自動で工数を可視化できないのか?」という問いに答え、AI-OCRと機械学習を活用し、問題が顕在化する前にボトルネックを発見する「先回り型」の管理を実現します。
+
+年間約856時間（≒ 月71時間）、金額換算で約320万円相当のリソース削減を実現し、投資回収期間は約1.3ヶ月です。
+
+今すぐ https://backoffice-insight.example.com から無料トライアルを開始できます。
\ No newline at end of file
diff --git a/yourwork_1shot/sample/invoice_SaaS/solutions.md b/yourwork_1shot/sample/invoice_SaaS/solutions.md
new file mode 100644
index 0000000..5d289bd
--- /dev/null
+++ b/yourwork_1shot/sample/invoice_SaaS/solutions.md
@@ -0,0 +1,153 @@
+# 顧客の課題に対する解決策候補一覧
+
+### **1. AI-OCR自動化アプローチ**
+
+**いつ使う？**
+経理担当者が月に200〜500件の経費申請を手作業で処理し、1件あたり15〜20分かかっている状況で選択すべきアプローチだ。特に、領収書の写真が不鮮明で確認に時間がかかり、月末月初に経理担当者が毎日2〜3時間の残業を強いられている場合に最大の効果を発揮する。従業員からの「経費申請が面倒すぎる」という不満が上がり、差し戻し率が20%を超えている状況において、業務効率化の第一歩となる。
+
+**どう課題を解決した？**
+スマホで領収書を撮影すると、AI-OCRが3秒以内に金額・日付・店舗名・品目を自動抽出し、経費申請データを作成する。過去の申請履歴と店舗・品目情報から最適な勘定科目を自動提案する機械学習モデルを実装し、選択ミスを90%削減した。画像補正機能により、斜めや暗い写真でも高精度で読み取りが可能になり、再提出依頼が80%減少した。経理担当者は自動抽出されたデータを確認するだけで済むため、1件あたりの処理時間が15分から3分に短縮された。
+
+**どんな効果が出た？**
+導入後3ヶ月で、経費精算処理時間が月40時間から12時間に70%削減され、経理担当者の残業がほぼゼロになった。差し戻し率が20%から4%に低下し、従業員と経理担当者双方のストレスが大幅に軽減された。従業員からの「経費申請が楽になった」という声が増え、申請〜承認までの時間が平均2日から半日に短縮された。空いた時間を月次決算準備や経営分析に充てられるようになり、CFOから高く評価された。
+
+**どう実現している？**
+Amazon Textract、Google Cloud Vision API、またはAzure Form RecognizerなどのクラウドベースのOCRサービスを活用し、高精度な文字認識を実現する。独自の機械学習モデルを構築し、過去の申請データから勘定科目推論エンジンを学習させ、使えば使うほど精度が向上する仕組みを実装する。プログレッシブWebアプリ（PWA）またはネイティブアプリでモバイルファースト体験を提供し、オフラインでも撮影・入力が可能な設計とする。電子帳簿保存法に対応するため、タイムスタンプ自動付与と法令要件を満たした原本管理機能を実装する。
+
+**参考リソース**:
+- Amazon Textract: https://aws.amazon.com/jp/textract/
+- 電子帳簿保存法ガイドライン: https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/02.htm
+
+---
+
+### **2. 請求書自動管理・支払アラートアプローチ**
+
+**いつ使う？**
+月に50〜150件の請求書をPDFやメールで受け取り、手動でスプレッドシートに記録している状況で選択すべきだ。特に、請求書の支払漏れが年に数回発生し、取引先からのクレームで信頼を損ねているケースや、支払期限の管理が属人化し、経営者が「今月の支払予定額はいくら?」と聞かれても即答できない場合に必須となる。電子帳簿保存法対応の準備が不十分で、何から始めればいいか分からない企業にとって、最優先で取り組むべきアプローチだ。
+
+**どう課題を解決した？**
+受け取った請求書を専用メールアドレスに転送、またはPDF/画像をアップロードすると、AI-OCRが請求書番号・請求元・金額・支払期限・振込先を自動抽出し、支払管理台帳に登録される。過去の取引実績と比較し、金額の異常や重複を自動検知してアラートを発する。支払期限の7日前、3日前、当日にメールとSlackで自動リマインダーを送信し、支払漏れをゼロにした。支払予定額の月次・週次サマリーをダッシュボードで可視化し、キャッシュフロー予測が可能になった。
+
+**どんな効果が出た？**
+導入後、請求書の支払漏れがゼロになり、取引先からのクレームが完全に消失した。請求書処理時間が1件あたり10分から2分に80%削減され、月に約20時間の工数削減を実現した。経営者が「今月の支払予定は?」と質問された際、ダッシュボードを見せて即座に回答できるようになり、経営判断のスピードが向上した。電子帳簿保存法に完全対応し、監査時の証憑提示が容易になり、IPO準備の基盤が整った。
+
+**どう実現している？**
+メール自動取り込み機能として、専用メールアドレス宛に送信された請求書PDFを自動で取り込むAPIを構築する。クラウドストレージ（Google Drive、Dropbox）と連携し、特定フォルダに保存された請求書を自動同期する機能を実装する。多様な請求書フォーマットに対応するため、ディープラーニングモデルを活用し、学習データを増やすことで精度を継続的に向上させる。支払スケジュール管理には、カレンダー統合とリマインダー機能を実装し、Slack、メール、プッシュ通知で期限前にアラートを送信する。
+
+**参考リソース**:
+- 請求書管理のベストプラクティス: https://www.freee.co.jp/kb/kb-invoice/
+- 電子帳簿保存法対応ガイド: https://www.soumu.go.jp/main_sosiki/joho_tsusin/denshichoubo/
+
+---
+
+### **3. 会計ソフト連携・自動仕訳アプローチ**
+
+**いつ使う？**
+経費精算システムと会計ソフトが連携しておらず、同じデータを複数のシステムに手入力している状況で選択すべきだ。特に、月次決算のためのデータ集計に2〜3日かかり、CSVエクスポート・インポートを毎月手作業で行っている場合に最大の効果を発揮する。転記ミスによる会計データの不整合が頻発し、経理担当者が「なぜ二重入力が必要なのか」と疑問を感じている状況において、業務の根本的な効率化を実現するアプローチだ。
+
+**どう課題を解決した？**
+主要な会計ソフト（freee、マネーフォワード クラウド会計、弥生会計オンライン等）とAPIで双方向連携し、経費・請求書データを自動で会計ソフトに仕訳として送信する機能を実装した。勘定科目マッピングは初回設定時に行い、その後は機械学習により自動で最適な勘定科目を選択する。補助科目・部門・プロジェクトの同期により、プロジェクト別のコスト管理が可能になった。リアルタイム連携またはスケジュール連携を選択でき、企業の運用フローに合わせた柔軟な設定が可能だ。
+
+**どんな効果が出た？**
+導入後、会計ソフトへの二重入力が完全に撤廃され、月次決算完了までの日数が10日から5日に短縮された。転記ミスがゼロになり、会計データの整合性が劇的に向上した。経理担当者が「データ転記」という単純作業から解放され、経営分析や予算管理といった戦略的業務に時間を割けるようになった。VCから求められていた内部統制の整備が進み、次回ラウンドの資金調達に向けた準備が加速した。
+
+**どう実現している？**
+各会計ソフトの公式APIを活用し、OAuth 2.0による安全な認証を実装する。エラーハンドリングと自動リトライ機能を組み込み、API通信の失敗時にも確実にデータを同期できる仕組みを構築する。連携ログを完全記録し、どのデータがいつ連携されたかを可視化することで、トラブルシューティングを容易にする。勘定科目マッピングのUI/UXを工夫し、経理の専門知識がなくても直感的に設定できるインターフェースを提供する。
+
+**参考リソース**:
+- freee API: https://developer.freee.co.jp/
+- マネーフォワード クラウド API: https://developer.moneyforward.com/
+
+---
+
+### **4. リアルタイム・ダッシュボード可視化アプローチ**
+
+**いつ使う？**
+経営会議で「各部門の経費状況を報告して」と言われても、集計に丸一日かかり、即座に答えられない状況で選択すべきだ。特に、経費や仕入れの傾向分析ができておらず、部門別・プロジェクト別のコスト把握が困難で、予算管理が感覚的になっている場合に最大の効果を発揮する。経営者が「どの経費項目が増えているのか」をすぐに把握したいと考えており、データドリブンな経営判断を実現したいニーズがある企業に最適だ。
+
+**どう課題を解決した？**
+今月の経費・請求書の支払総額、部門別・プロジェクト別の経費推移、前年同月比・予算比を自動計算し、リアルタイムダッシュボードで可視化した。「今月は交通費が先月比で30%増加しています」「来月の支払予定額が通常より50万円多くなります」といったAIインサイトを自動生成し、異常の早期検知が可能になった。ドラッグ&ドロップで簡単にカスタムレポートを作成でき、PDF/Excel出力で経営会議資料として即座に活用できる機能を提供した。
+
+**どんな効果が出た？**
+導入後、経営会議での財務報告準備時間が1日から30分に短縮され、経営判断のスピードが飛躍的に向上した。部門別の経費状況をリアルタイムで把握できるようになり、予算超過の部門に対して即座にアラートを出し、コスト管理が強化された。「会議費の80%がカフェでの打ち合わせ」といったインサイトから、オンライン会議の推奨により月10万円のコスト削減を実現した。CFOがダッシュボードを投資家に見せることで、財務状況の透明性が評価され、資金調達が円滑に進んだ。
+
+**どう実現している？**
+BIツール並みの分析機能を、シンプルなUI/UXで提供する設計を採用する。自然言語での質問に対応し、「先月の交通費は?」と入力すると結果を表示するチャットボット機能を実装する。グラフの種類（棒グラフ、折れ線グラフ、円グラフ等）を自動提案し、データの特性に応じた最適な可視化を提供する。モバイルでも快適に閲覧可能なレスポンシブデザインを採用し、経営者が外出先でもダッシュボードを確認できる環境を整える。
+
+**参考リソース**:
+- ダッシュボードデザインのベストプラクティス: https://www.tableau.com/ja-jp/learn/articles/dashboard-design-best-practices
+- データ可視化ガイド: https://www.interaction-design.org/literature/article/data-visualization
+
+---
+
+### **5. モバイルファースト・承認フローアプローチ**
+
+**いつ使う？**
+リモートワーク・ハイブリッドワークを導入しており、従業員が外出先や移動中に経費申請を行いたいというニーズが高まっている状況で選択すべきだ。特に、承認者が出張中で承認が遅延し、申請から承認まで平均2日以上かかっている場合に最大の効果を発揮する。従業員から「スマホで完結したい」「わざわざPCを開くのが面倒」という声が上がっており、ユーザー体験の向上が急務となっている企業に最適だ。
+
+**どう課題を解決した？**
+スマホアプリで、いつでもどこでも経費精算・承認が完結する体験を提供した。オフライン対応により、ネット環境がなくても撮影・入力でき、接続時に自動同期される。事前に設定した金額・部門に応じた承認ルートを自動判定し、Slackと連携して承認依頼通知を送信する。承認者はSlack上またはアプリ内でワンクリック承認でき、承認状況をリアルタイムで可視化した。音声入力機能により、「1,200円、タクシー代」と話すだけで申請が作成される。
+
+**どんな効果が出た？**
+導入後、申請から承認までの時間が平均2日から半日に短縮され、従業員満足度が大幅に向上した。承認者が出張中でも、スマホでワンクリック承認できるため、承認待ちによる業務停滞がなくなった。オフライン対応により、飛行機や新幹線の移動中でも経費申請が可能になり、月末の申請集中が緩和された。音声入力機能が好評で、特に営業職から「移動中にすぐ申請できて助かる」という声が多数寄せられた。
+
+**どう実現している？**
+プログレッシブWebアプリ（PWA）またはネイティブアプリ（iOS/Android）を開発し、ネイティブアプリのような操作感を提供する。オフライン対応には、Service WorkerとIndexedDBを活用し、ローカルストレージにデータを一時保存する仕組みを実装する。プッシュ通知機能により、承認依頼、支払期限、異常検知をリアルタイムで通知する。ウィジェット機能により、ホーム画面から経費申請や承認がワンタップで起動できるUXを実現する。
+
+**参考リソース**:
+- PWA開発ガイド: https://web.dev/progressive-web-apps/
+- モバイルUXベストプラクティス: https://www.nngroup.com/articles/mobile-ux/
+
+---
+
+### **6. マネーフォワード クラウド経費アプローチ（競合A）**
+
+**いつ使う？**
+既にマネーフォワード クラウド会計を導入しており、バックオフィス業務を統合的に効率化したい企業が選択すべきアプローチだ。特に、従業員50名以上の中堅企業で、会計・給与・請求書などの関連業務を一つのプラットフォームで管理したいニーズがある場合に最適となる。ブランド力と導入実績を重視し、「安心感」「信頼性」を最優先する企業にとって第一選択肢となる。多機能で複雑な業務フローにも対応できるため、将来的な事業拡大を見据えて「しっかりしたシステム」を導入したい場合に有効だ。
+
+**どう課題を解決した？**
+レシート撮影によるOCR入力、交通系ICカード連携、クレジットカード明細自動取り込みにより、経費精算の入力工数を削減した。マネーフォワード クラウド会計との自動仕訳連携により、会計ソフトへの二重入力を撤廃し、月次決算の効率化を実現した。柔軟な承認ルート設定により、複雑な組織構造にも対応可能となった。電子帳簿保存法に完全対応し、タイムスタンプ機能により法令要件を満たした。関連製品（給与計算、請求書発行等）とのシームレス連携により、バックオフィス業務を一気通貫で効率化できる環境を提供した。
+
+**どんな効果が出た？**
+13万事業所という圧倒的な導入実績により、顧客からの信頼が厚く、「安心して導入できる」という評価を得ている。マネーフォワードのエコシステムに参加することで、バックオフィス業務全体の効率化が進み、複数のツールを使い分ける手間が削減された。充実したカスタマーサポートと豊富なヘルプドキュメントにより、導入後の問い合わせ対応がスムーズになった。定期的なウェビナー開催により、製品の活用度が向上し、顧客満足度が高まった。継続的な機能改善により、ユーザーフィードバックが製品に反映され、使い勝手が向上し続けている。
+
+**どう実現している？**
+OCR技術により、レシートや領収書の画像から金額・日付・店舗名を自動抽出する。交通系ICカード（Suica、PASMO等）との連携により、交通費の自動取り込みを実現する。マネーフォワード クラウド会計のAPIを活用し、経費データを自動で仕訳として会計ソフトに送信する仕組みを構築する。承認ワークフロー機能により、部門・金額に応じた柔軟な承認ルート設定を可能にする。電子帳簿保存法対応のため、タイムスタンプ自動付与と法令要件を満たしたデータ保存を実装する。関連製品との統合プラットフォームにより、データの一元管理とシームレスな連携を実現する。
+
+**参考リソース**:
+- 公式サイト: https://biz.moneyforward.com/expense
+- 導入事例: https://biz.moneyforward.com/case
+
+**価格と導入ハードル**:
+- **月額3,980円〜**: 小規模スタートアップには手頃だが、従業員数が増えると従量課金で価格が上昇
+- **多機能ゆえの複雑さ**: 初期設定が煩雑で、「オーバースペック」と感じる小規模企業もある
+- **会計ソフトの制約**: マネーフォワード以外の会計ソフト（freee、弥生等）との連携が限定的
+- **UI/UX**: 画面遷移が多く、初めてのユーザーには分かりにくいという声がある
+
+---
+
+### **7. 楽楽精算アプローチ（競合B）**
+
+**いつ使う？**
+従業員100名以上の中堅・大企業で、複雑な承認フローや組織構造に対応する必要がある場合に選択すべきアプローチだ。特に、企業ごとの業務フローに合わせた高度なカスタマイズが必要で、導入時の手厚いサポートを重視する企業に最適となる。「しっかりしたシステムを導入したい」「専任の導入コンサルタントに支援してほしい」というニーズがある企業にとって第一選択肢となる。長期的に安定した運用を目指し、初期投資を惜しまない姿勢がある場合に有効だ。
+
+**どう課題を解決した？**
+レシート・領収書の自動読み取り、交通費自動計算、クレジットカード連携により、経費精算の入力工数を削減した。乗換案内連携と定期区間自動控除により、交通費精算の正確性が向上した。高度なカスタマイズが可能な承認ルート設定により、複雑な組織構造にも柔軟に対応できるようになった。主要会計ソフト（freee、マネーフォワード、勘定奉行等）との連携により、会計データの二重入力を削減した。専任の導入コンサルタントによる設定から運用開始までのサポートにより、導入後の定着率が高まった。
+
+**どんな効果が出た？**
+15,000社以上という豊富な導入実績により、中堅・大企業からの信頼が厚く、「安定したシステム」として評価されている。カスタマイズ性の高さにより、企業固有の業務フローにフィットし、業務効率化が実現された。専任の導入コンサルタントによるサポートにより、導入時のトラブルが最小化され、スムーズな運用開始が可能になった。1,000名以上の大規模企業での導入実績により、スケーラビリティが証明され、将来的な組織拡大にも対応可能だという安心感を提供した。電話サポート（平日9:00〜18:00）により、緊急時の対応が迅速になり、顧客満足度が向上した。
+
+**どう実現している？**
+OCR技術により、レシートや領収書の画像から金額・日付・店舗名を自動抽出する。乗換案内APIと連携し、出発地と目的地を入力すると交通費を自動計算する仕組みを構築する。ICカード読み取り機能により、交通系ICカードの利用履歴を直接取り込む。承認フロー、入力項目、勘定科目など、企業ごとの業務フローに合わせた柔軟なカスタマイズ機能を提供する。主要会計ソフトのAPIを活用し、経費データを会計ソフトに自動連携する。専任の導入コンサルタントによる初期設定支援、従業員向けトレーニング、運用定着支援を実施する。
+
+**参考リソース**:
+- 公式サイト: https://www.rakurakuseisan.jp/
+- 導入事例: https://www.rakurakuseisan.jp/case/
+
+**価格と導入ハードル**:
+- **初期費用10万円〜、月額3万円〜**: スタートアップには高額で、導入ハードルが高い
+- **小規模企業向けプランなし**: 20〜50名規模の企業には不向き
+- **モバイル対応の弱さ**: スマホアプリの機能が限定的で、モバイルでの使い勝手が劣る
+- **AI機能の弱さ**: OCRの精度や勘定科目の自動提案が競合と比べて見劣りする
+- **請求書管理は別製品**: 経費精算に特化しており、ワンストップ性に欠ける
+- **UI/UXの古さ**: デザインがやや古臭く、若手従業員からは「使いにくい」という声も
\ No newline at end of file
diff --git a/yourwork_1shot/sample/security/customer.md b/yourwork_1shot/sample/security/customer.md
new file mode 100644
index 0000000..15d69fc
--- /dev/null
+++ b/yourwork_1shot/sample/security/customer.md
@@ -0,0 +1,14 @@
+## ターゲットの目的、背景、属性
+
+### **目的**
+スタートアップから成長期のSaaS企業のCTOが、エンタープライズ市場へのアップマーケットを実現し、**契約単価の向上とビジネスの安定化**を図ること。中小企業向けから脱却し、大手企業との契約を獲得することで、ARRの成長加速とチャーンレートの低下を両立させる。
+
+### **背景（社内的状況）**
+先月の営業会議で、セールスVPから「3社連続で最終段階で失注した。全て理由は『セキュリティ要件を満たさない』」という報告があった。その夜、大手製薬会社との商談を進めていたエンタープライズセールス担当から「200ページのセキュリティ質問票が届いた。半分以上答えられない」とSlackが届く。CFOからは「現在のACVは50万円。エンタープライズなら500万円取れる。売上を10倍にするには新規獲得100社か、エンタープライズ10社か」と迫られる。プロダクトマネージャーからは「シングルサインオン、監査ログ、RBAC、データレジデンシー。機能要求が毎週5件以上来る」と悲鳴が上がる。取締役会では「競合のSlackはエンタープライズで成功している。うちはいつ追いつくのか」と質問され、明確な回答ができなかった。
+
+### **属性**
+- **規模**: 開発チーム20～50名のSaaS企業
+- **フェーズ**: シリーズA～Bの成長期企業
+- **課題**: エンタープライズ要件への対応不足、セキュリティ認証未取得、営業サイクルの長期化
+- **意思決定権限**: 技術戦略とプロダクトロードマップの決定権を持つCTO
+- **予算制約**: ROIを示しながら段階的な投資が必要な環境
diff --git a/yourwork_1shot/sample/security/output.md b/yourwork_1shot/sample/security/output.md
new file mode 100644
index 0000000..d9c3370
--- /dev/null
+++ b/yourwork_1shot/sample/security/output.md
@@ -0,0 +1,399 @@
+# discovery/README.md - エンタープライズSaaSセキュリティ自動化プラットフォーム
+
+## Phase 1: カスタマージャーニー作成（Listen）
+
+### エンタープライズ市場参入カスタマージャーニー
+
+| # | 行動ステップ | 所要時間 | 費用（円） | 使用ツール | 感情スコア | 主要課題 | 顧客の声 |
+|---|------------|---------|-----------|-----------|-----------|---------|---------|
+| 1 | **認識・戦略立案**
エンタープライズ商談での失注を経験し、セキュリティ要件の壁を認識。経営陣への投資提案と予算確保を行う。 | 1-2ヶ月 | 75万-225万円 | G2、Capterra、競合分析ツール、ROI計算機 | **2/5** | ・経営陣の理解不足（「今の顧客で十分」）
・投資額と期間への驚愕
・どこから始めればよいか不明確 | 「エンタープライズ取引が毎回'SOC 2レポートはありますか?'で止まる。この壁を越えないと成長できない」 |
+| 2 | **ギャップ分析・スコープ定義**
現状セキュリティ体制の棚卸しとフレームワーク選定。70-150統制項目のギャップアセスメントを実施。 | 1-3ヶ月 | 150万-450万円 | Vanta/Drata無料アセスメント、スプレッドシート、Jira/Asana | **2/5** | ・70-150統制項目の多さに圧倒
・既存セキュリティの不十分さ判明
・エンジニアからの抵抗
・技術的負債がコンプライアンス阻害 | 「ギャップ分析で判明した問題の多さに愕然。パスワード管理、アクセス制御、ログ監視...全て不十分だった」 |
+| 3 | **統制・ポリシー実装**
情報セキュリティポリシー策定（40+文書）、MFA全社導入、データ暗号化、RBAC構築、ログ監視・SIEM導入、DR計画整備等を実施。 | 3-6ヶ月 | 750万-1,500万円 | Vanta/Drata ($2-5K/月)、Okta/Auth0、1Password、Splunk/Datadog、KnowBe4 | **2.5/5** | ・複数ツール統合の複雑さ
・開発速度15-25%低下
・継続的エビデンス収集の負担
・「セキュリティ vs 速度」トレードオフ
・警告疲れ（誤検知） | 「統制実装の最大課題は開発速度を犠牲にせずセキュリティ強化すること。'Move fast and break things'は通用しない」 |
+| 4 | **外部監査・認証取得**
監査法人選定、レディネスアセスメント（模擬監査）、本監査実施、不適合是正、最終報告書受領。 | Type I: 2-4ヶ月
Type II: 6-12ヶ月 | 150万-825万円 | 監査管理プラットフォーム、自動エビデンス収集ツール、監査法人（CPA認定） | **3/5** | ・エビデンス収集の煩雑さ（複数システムから手動）
・予期せぬ追加質問
・ログの不完全さ
・エンジニア業務の中断
・監査法人の解釈の違い | 「最も困難なのは監査でなく準備。複数システムから何週間もエビデンス収集する」 |
+| 5 | **運用・継続的維持管理**
継続的統制モニタリング（24/7）、四半期アクセスレビュー、年次リスクアセスメント、インシデント対応、年次更新監査。 | 継続的（年間） | 750万-2,250万円/年 | 継続的コンプライアンス監視ツール、SIEM、脆弱性スキャナー | **3.5/5** | ・日々の統制運用負担
・統制失敗時の是正対応
・新脅威への対応（ゼロデイ脆弱性）
・コンプライアンス疲れ | 「コンプライアンスは一度達成して終わりでない。継続的監視、更新、テストが日常業務の一部に」 |
+| 6 | **スケールアップ・複数フレームワーク**
追加フレームワーク取得（ISO 27001、GDPR、HIPAA）、グローバル市場対応。 | 3-12ヶ月 | 1,200万-3,000万円 | マルチフレームワーク管理ツール、データレジデンシー管理ツール | **3.5/5** | ・フレームワーク間の要件差異
・データレジデンシー要件
・管理コスト上昇 | 「SOC 2とISO 27001は80-96%統制重複。残り10-20%対応が意外と大変」 |
+| 7 | **エンタープライズ営業加速・ROI実現**
Trust Center公開、セキュリティ質問票自動化、ABM実施、大型案件獲得。 | 継続的 | 変動 | Trust Center、セキュリティ質問票自動化ツール、ABMプラットフォーム | **4/5** | ・エンタープライズセールスサイクルの長さ
・質問票対応の継続的負担 | 「Recruit CRMはコンプライアンス対応後30-45日で2社のエンタープライズ顧客獲得」 |
+
+**合計費用**: 年間**3,075万円〜8,250万円**（初年度）
+**合計期間**: **12-24ヶ月**
+**感情スコア3以下のペインポイント**: **4つ**（ステップ1, 2, 3, 4）
+
+---
+
+## Phase 2: 問いの立案（Define）
+
+### 各行動ステップに対する問いの立案
+
+#### ステップ1: 認識・戦略立案
+**問い1-A（省略型）**: なぜ「失注を経験してから」でなく「失注する前に」エンタープライズ要件を満たせないのか？
+**現在の制約**: エンタープライズセキュリティ要件の可視性不足、予算承認プロセスの遅さ
+
+**問い1-B（統合型）**: なぜ「経営陣への説得」と「技術的実現可能性の検証」は同時にできないのか？
+**現在の制約**: ROI計算に必要なデータ不足、技術的複雑性の見積もり困難
+
+#### ステップ2: ギャップ分析・スコープ定義
+**問い2-A（省略型）**: なぜ「手動でスプレッドシート管理」せずに「自動的にギャップを可視化」できないのか？
+**現在の制約**: 複数システムへの分散、統一的な評価基準の欠如
+
+**問い2-B（統合型）**: なぜ「現状分析」と「統制の優先順位付け」は同時にできないのか？
+**現在の制約**: 統制間の依存関係が不明確、ビジネスインパクトの定量化困難
+
+#### ステップ3: 統制・ポリシー実装
+**問い3-A（省略型）**: なぜ「開発速度を15-25%犠牲にして」でなく「速度を維持しながら」セキュリティを強化できないのか？
+**現在の制約**: セキュリティプロセスの手動実行、開発ワークフローへの統合不足
+
+**問い3-B（統合型）**: なぜ「複数ツールの個別導入」と「統合されたセキュリティ基盤構築」は同時にできないのか？
+**現在の制約**: ツール間の連携不足、統一的なデータモデルの欠如
+
+**問い3-C（省略型）**: なぜ「40+のポリシー文書を手動作成」せずに「テンプレートから自動生成」できないのか？
+**現在の制約**: カスタマイズ要件の多様性、業界標準テンプレートの不足
+
+#### ステップ4: 外部監査・認証取得
+**問い4-A（省略型）**: なぜ「何週間もかけて手動でエビデンス収集」せずに「自動的にエビデンスを集約」できないのか？
+**現在の制約**: 複数システムへのログ分散、監査要件とログ構造の不一致
+
+**問い4-B（統合型）**: なぜ「監査準備」と「日常業務」は同時にできないのか？
+**現在の制約**: エビデンス収集の一時的集中作業、エンジニアの業務中断
+
+**問い4-C（省略型）**: なぜ「監査法人の解釈を待って」でなく「事前に要件を明確化」できないのか？
+**現在の制約**: 監査基準の曖昧性、監査法人との情報非対称性
+
+#### ステップ5: 運用・継続的維持管理
+**問い5-A（統合型）**: なぜ「継続的モニタリング」と「自動修復」は同時にできないのか？
+**現在の制約**: 統制失敗の検知遅延、自動修復ロジックの複雑性
+
+**問い5-B（省略型）**: なぜ「コンプライアンス疲れ」に陥らずに「持続可能な運用」を実現できないのか？
+**現在の制約**: 手動プロセスの多さ、誤検知による警告疲れ
+
+#### ステップ6: スケールアップ・複数フレームワーク
+**問い6-A（統合型）**: なぜ「SOC 2対応」と「ISO 27001対応」を別々でなく「統合的に」実施できないのか？
+**現在の制約**: フレームワーク間のマッピング不在、80%重複部分の重複作業
+
+**問い6-B（省略型）**: なぜ「追加フレームワーク毎に1,200-3,000万円」かけずに「増分コストで」対応できないのか？
+**現在の制約**: 共通統制基盤の欠如、再利用可能な実装の不足
+
+#### ステップ7: エンタープライズ営業加速
+**問い7-A（省略型）**: なぜ「セキュリティ質問票に個別対応」せずに「自動的に回答」できないのか？
+**現在の制約**: 質問票の標準化不足、統制情報の分散
+
+**問い7-B（統合型）**: なぜ「Trust Center公開」と「リアルタイムセキュリティ状況の共有」は同時にできないのか？
+**現在の制約**: 静的ドキュメントベースの情報共有、リアルタイムデータ連携不足
+
+---
+
+## Phase 3: Top3課題の選定（Define）
+
+### 全問いのスコアリング
+
+| 問いID | 問いの内容 | 削減/獲得リソース
(1-5点) | 頻度
(1-5点) | 合計点 |
+|-------|----------|----------------------|------------|--------|
+| 3-A | 速度を維持しながらセキュリティ強化 | 5 | 5 | **10** |
+| 4-A | エビデンスを自動的に集約 | 5 | 5 | **10** |
+| 5-A | 継続的モニタリングと自動修復を同時実行 | 4 | 5 | **9** |
+| 2-A | ギャップを自動的に可視化 | 5 | 3 | 8 |
+| 7-A | セキュリティ質問票に自動回答 | 4 | 4 | 8 |
+| 1-A | 失注する前にエンタープライズ要件を満たす | 5 | 3 | 8 |
+
+### Top3課題
+
+#### 🥇 第1位（同点）: 問い3-A & 問い4-A（スコア10点）
+
+**問い3-A**: なぜ「開発速度を15-25%犠牲にして」でなく「速度を維持しながら」セキュリティを強化できないのか？
+**選定理由**: 開発生産性15-25%維持により年間約4,500万円の価値創出、日次の開発活動に影響
+
+**問い4-A**: なぜ「何週間もかけて手動でエビデンス収集」せずに「自動的にエビデンスを集約」できないのか？
+**選定理由**: エビデンス収集時間90%削減（約400万円/年）、年4回の監査対応、感情スコア3/5の最大ペインポイント
+
+#### 🥈 第2位: 問い5-A（スコア9点）
+
+**問い5-A**: なぜ「継続的モニタリング」と「自動修復」は同時にできないのか？
+**選定理由**: インシデント対応時間70%削減、24/7継続的モニタリング、コンプライアンス疲れの軽減
+
+#### 🥉 第3位: 問い2-A（スコア8点）
+
+**問い2-A**: なぜ「手動でスプレッドシート管理」せずに「自動的にギャップを可視化」できないのか？
+**選定理由**: ギャップ分析期間70%削減（1-3ヶ月→2週間）、コスト約300万円削減、早期の正確な計画立案
+
+---
+
+## Phase 4: 実装難易度評価（solutions.md）
+
+### チーム条件
+- **チーム規模**: エンジニア10名
+- **技術スタック**: AWSの実装経験あり
+- **開発期間**: 6ヶ月、3名専任
+
+### ソリューション1: コンプライアンス認証
+**難易度スコア**: **10（4ヶ月以上）**
+**理由**: 50-100以上のポリシー文書作成、第三者監査機関との調整、組織全体のプロセス変更、継続的コンプライアンス維持体制の構築
+
+### ソリューション2: アクセス制御強化
+**難易度スコア**: **5（2-4ヶ月）**
+**理由**: AWS Identity Centerにより簡略化、SAML統合は標準的、既存IAMからの移行作業、全社員のオンボーディング
+
+### ソリューション3: データ主権対応
+**難易度スコア**: **5-7（2-4ヶ月）**
+**理由**: リージョン制限は簡単、KMS実装は中程度、CloudHSMは高難度、データ配置戦略の見直し
+
+### ソリューション4: セキュリティ透明性
+**難易度スコア**: **3（1-2ヶ月）**
+**理由**: GuardDuty、Security Hubはワンクリック有効化、基本ダッシュボードは簡単、アラートチューニングが必要
+
+---
+
+## Phase 5: 発明の提案（Invent）
+
+### 発明1: 🚀 DevSecOps自動化プラットフォーム（問い3-A対応）
+
+**対象問い**: 速度を維持しながらセキュリティを強化
+**組み合わせソリューション**: アクセス制御強化(40%) + セキュリティ透明性(40%) + データ主権対応(20%)
+
+**新しい価値提案**: 開発ワークフローに透明に統合されるセキュリティレイヤー。CI/CDパイプラインが自動的にセキュリティ統制を実行・検証・エビデンス収集。
+
+**ブレイクスルー要素**: 🔄 逆転の発想 + 🤖 AI/自動化
+- 従来: セキュリティは開発の「後」で実施
+- 革新: セキュリティは開発の「最中」に自動実行
+
+**実装難易度**: 7（3-4ヶ月）
+**期待効果**: 開発速度低下15-25% → 2-5%、セキュリティ統制自動実行率85%
+
+---
+
+### 発明2: 🎯 インテリジェント監査エビデンス自動収集システム（問い4-A対応）
+
+**対象問い**: エビデンスを自動的に集約
+**組み合わせソリューション**: セキュリティ透明性(50%) + アクセス制御強化(30%) + コンプライアンス認証(20%)
+
+**新しい価値提案**: 監査人の質問を理解し、該当エビデンスを自動収集・整理・提出するAIアシスタント。70-150統制項目のエビデンスを24時間以内に提出可能。
+
+**ブレイクスルー要素**: 🤖 AI/自動化 + ⏰ 時間軸の操作
+- 従来: 監査の「タイミング」で「回顧的」に収集
+- 革新: 監査の「前」から「継続的」に「予測的」に収集
+
+**実装難易度**: 6（2.5-3ヶ月）
+**期待効果**: エビデンス収集時間200時間 → 20時間（90%削減）、年間約400万円削減
+
+---
+
+### 発明3: ⚡ セルフヒーリングセキュリティオーケストレーター（問い5-A対応）
+
+**対象問い**: 継続的モニタリングと自動修復を同時実行
+**組み合わせソリューション**: セキュリティ透明性(40%) + アクセス制御強化(40%) + データ主権対応(20%)
+
+**新しい価値提案**: セキュリティインシデントを検知した瞬間に、人間の介入なしで自動修復するAIオーケストレーター。統制失敗、設定ドリフト、脅威検出に対して事前定義プレイブックを自動実行。
+
+**ブレイクスルー要素**: 🤖 AI/自動化 + 🔧 制約の武器化
+- 従来: 「検知」と「対応」を分離（検知→アラート→人間判断→修復）
+- 革新: 「検知」と「対応」を統合（検知 == 自動修復）
+
+**実装難易度**: 8（3.5-4ヶ月）
+**期待効果**: インシデント対応時間2時間 → 15秒（99.8%削減）、統制失敗自動修復率85%
+
+---
+
+### 発明4: 🧩 ユニバーサルコンプライアンスハブ（問い2-A + 問い6-A対応）
+
+**対象問い**: ギャップ自動可視化 + SOC 2とISO 27001を統合的に実施
+**組み合わせソリューション**: コンプライアンス認証(50%) + セキュリティ透明性(30%) + アクセス制御強化(20%)
+
+**新しい価値提案**: 複数のコンプライアンスフレームワークを単一の統合ビューで管理し、80-96%の重複統制を一度の実装で満たすインテリジェントプラットフォーム。
+
+**ブレイクスルー要素**: 🔀 異業種転用 + 🔄 逆転の発想
+- 異業種転用: ソフトウェア開発の「依存性管理」概念をコンプライアンスに転用
+- 逆転: 「各フレームワークに個別対応」→「共通統制基盤から各フレームワークを導出」
+
+**実装難易度**: 9（4-5ヶ月）
+**期待効果**: ギャップ分析期間1-3ヶ月 → 2週間（85%削減）、追加フレームワークコスト60%削減
+
+---
+
+## Phase 6: プレスリリース作成（Refine）
+
+# ComplianceFlow、AI搭載「インテリジェント監査エビデンス自動収集システム」を発表
+
+## エンタープライズ市場を目指すSaaS企業のCTOが、監査準備の負担から解放され、プロダクト開発に集中できる革新的ソリューション
+
+**東京、2026年1月** - ComplianceFlowは本日、AI搭載「インテリジェント監査エビデンス自動収集システム」を発表しました。本システムは、SOC 2、ISO 27001等のコンプライアンス監査準備に必要なエビデンス収集時間を、従来の200時間から20時間に90%削減します。
+
+スタートアップから成長期のSaaS企業がエンタープライズ市場にアップマーケットする際、SOC 2やISO 27001などのセキュリティ認証取得が不可欠です。しかし、70-150の統制項目それぞれに対する監査エビデンスの収集は、複数のシステム（AWS、GitHub、Slack、Google Workspace等）から手動で行う必要があり、エンジニアチームに大きな負担をかけてきました。
+
+### 解決する課題
+
+**エビデンス収集の煩雑さ**: 監査準備に平均200時間を要し、エンジニアが本来の開発業務から離脱。ある CTO は「最も困難なのは監査でなく準備。複数システムから何週間もエビデンス収集する」と語っています。
+
+**監査法人の要件理解の難しさ**: 監査法人から「MFAが全ユーザーで有効化されている証拠」と言われても、どのログをどの形式で提出すべきか不明確。
+
+**エンジニア業務の中断**: 四半期毎の監査対応でエンジニアが平均50時間業務から離脱。開発スプリントが遅延し、プロダクトロードマップに影響。
+
+**証跡の不完全さ**: 監査時点で「過去6ヶ月のアクセスレビュー記録」を求められても、継続的に記録していないため提出不可。
+
+### ソリューション
+
+**24/7継続的エビデンス収集**: 監査の「前」から「継続的」にエビデンスを自動収集。AWS CloudTrail、Config、IAM、Slack、GitHub、Okta等の15+システムと統合し、15分毎に増分収集。
+
+**AI搭載エビデンス解釈エンジン**: 監査人の自然言語質問を理解し、該当する統制項目を自動特定。関連するログを自動抽出し、監査法人が好む形式で整形。24時間以内に自動回答。
+
+**統制-エビデンスマッピング**: SOC 2、ISO 27001、NIST等の200+統制項目それぞれに必要なエビデンスタイプを事前定義。統制項目毎のエビデンス完全性スコアをリアルタイム表示。
+
+**エビデンスギャップ予測アラート**: 監査の2週間前に不足エビデンスを自動検知し、担当者にアラート。監査当日の「証跡不足」による統制失敗を防ぎます。
+
+**監査人ポータル**: 監査人専用のセキュアなWebポータルを提供。統制項目別にエビデンスを整理して表示し、監査人は必要な証跡をワンクリックでダウンロード。
+
+### 体験手順
+
+1. **セットアップ（2週間）**: AWS、GitHub、Slack等のシステムをOAuth認証で統合。SOC 2、ISO 27001等のフレームワークを選択。
+
+2. **自動収集開始**: システムが24時間365日、自動的にエビデンスを収集。統制項目毎の完全性スコアをダッシュボードで確認。
+
+3. **監査準備**: 監査の2週間前、不足エビデンスをアラート通知。ワンクリックで不足部分を補完。
+
+4. **監査実施**: 監査人に専用ポータルへのアクセスを提供。監査人は統制項目別に整理されたエビデンスを確認、追加質問もポータルで受付。
+
+5. **継続的維持**: 初回監査後も継続的にエビデンス収集。次回監査はさらにスムーズに。
+
+### お客様の声
+
+「監査準備は毎回悪夢でした。ComplianceFlow導入後、監査準備が20時間に短縮され、エビデンスの完全性が大幅に向上しました。監査人からも『これまでで最も整理されたエビデンス提出』と評価されました」- SaaS企業CTO（匿名）
+
+### FAQ
+
+**Q1: どのコンプライアンスフレームワークに対応していますか？**
+A1: SOC 2 Type I/II、ISO 27001、NIST CSF、CIS AWS Foundations、GDPR、HIPAAに対応しています。
+
+**Q2: Vanta、Drataと何が違いますか？**
+A2: Vanta、Drataは統制の「実装」と「監視」に優れていますが、監査エビデンスの「収集」は手動作業が多く残ります。ComplianceFlowは、監査人の質問を理解し、複数システムから自動的にエビデンスを収集・整形・提出する点で差別化されています。多くのお客様はVanta/Drataと併用しています。
+
+**Q3: セットアップにどのくらい時間がかかりますか？**
+A3: 標準的な環境で約2週間です。システム統合（Day 1-3）、フレームワーク選択（Day 4-7）、初回スキャン（Day 8-10）、トレーニング（Day 11-14）。
+
+**Q4: データセキュリティはどのように担保されますか？**
+A4: ComplianceFlow自体がSOC 2 Type II、ISO 27001認証を取得しています。転送時暗号化（TLS 1.3）、保管時暗号化（AWS KMS）、最小権限原則、MFA必須、全アクセスをCloudTrailで記録。
+
+**Q5: 年間のコスト削減効果はどのくらいですか？**
+A5: 平均的なSaaS企業（50-100名）の場合、エビデンス収集時間削減により年間約400万円のコスト削減。加えて、監査遅延回避によるエンタープライズ案件獲得加速。
+
+---
+
+## Phase 7: 事業計画（Refine）
+
+### 提供者メッセージ
+
+**ミッション**: 世界中のSaaS企業が、コンプライアンスの負担なくエンタープライズ市場に挑戦できる世界を実現する。
+
+エンタープライズSaaS市場は年率16.1%で成長し、2030年には$552.1Bに達します。しかし、この成長市場に参入するための「入場券」であるSOC 2、ISO 27001取得は、スタートアップにとって大きな障壁です。初期投資3,000万円以上、期間12-24ヶ月、そしてエビデンス収集に年間200時間。
+
+私たちは、この問題を自分たちも経験しました。前職でSaaS企業のCTOとして、SOC 2取得のために6ヶ月間、開発チームがエビデンス収集に追われ、プロダクトロードマップが大幅に遅延しました。「なぜこれを自動化できないのか？」という疑問から、ComplianceFlowは生まれました。
+
+2026年、私たちは1,000社のSaaS企業がエンタープライズ市場に参入する支援をします。そして、コンプライアンスが「負担」ではなく「競争優位性」になる世界を実現します。
+
+### 社内向けFAQ
+
+**Q1: ターゲット顧客は現在どのような製品を使用していますか？**
+A1: Vanta、Drata、Secureframe（統制実装・監視）、Googleスプレッドシート（エビデンス管理）、外部コンサルタント（エビデンス収集支援）。これらのツールは統制実装に優れていますが、監査エビデンスの自動収集機能は限定的です。
+
+**Q2: この製品はどの問題を解決しますか？**
+A2: エビデンス収集の煩雑さ（200時間）、監査要件の不明確さ、証跡の不完全さ、エンジニア業務中断（50時間）を解決します。より速い（90%削減）、より良い（完全性向上）、より安い（年間400万円削減）を実現します。
+
+**Q3: 現在の競合は？**
+A3: 直接競合はVanta Autopilot、Drata、Secureframe。競争優位性は、AI搭載エビデンス解釈（独自）、継続的予測的収集（時間軸の革新）、監査人ポータル（UX優位性）、20+システム統合（統合の広さ）。
+
+**Q4: 推定TAMは？**
+A4: TAM $10B+（コンプライアンス自動化市場全体）、SAM $500M（従業員50-500名のSaaS企業7,000社 × $72K）、SOM Year 3: $36M（500社、10%市場シェア）。
+
+**Q5: 必要な困難な問題は？**
+A5: 統制オントロジー構築（6ヶ月）、20+システム統合（3ヶ月）、AI/NLP自然言語理解（4ヶ月）、エビデンス形式変換（2ヶ月）、大規模ログデータの保存・検索（2ヶ月）。
+
+**Q6: ユニットエコノミクスは？**
+A6: ACV $72K、LTV $216K（3年保持）、COGS $5K（7%）、CAC $36K、LTV/CAC 6.0x（健全）、粗利率93%、貢献利益22%。
+
+**Q7: 初期投資額は？**
+A7: Year 0（プロダクト開発6ヶ月）$500K、Year 1（GTM、顧客獲得50社）$2.2M、累計初期投資$2.7M（シードラウンド想定）。
+
+**Q8: 成功のための仮定は？**
+A8: 市場需要（SOC 2新規取得年間1,000社）、ペインポイントの重大性（エビデンス収集200時間）、自動化可能性（85%以上）、監査法人の受容（検証中）、価格受容性（ROI 7-10倍）。
+
+**Q9: 成功しない上位3つの理由は？**
+A9: ①監査法人の非承認（対策：早期協議・パイロット監査）、②競合の追随（対策：AI差別化・先行者利益）、③市場規模の過大評価（対策：複数セグメント検証・隣接市場拡大）。
+
+**Q10: GTM戦略は？**
+A10: デザインパートナープログラム（5-10社）、監査法人パートナーシップ（紹介料20%）、コンテンツマーケティング（SEO、ウェビナー）、コミュニティ構築（SaaS CTO）。セールスサイクル30-45日、Year 1目標50社、MRR $200K。
+
+### ターゲット市場規模
+
+- **TAM**: $10B+（コンプライアンス自動化市場全体）
+- **SAM**: $500M（従業員50-500名のSaaS企業7,000社）
+- **SOM**: Year 1 $3.6M（50社）、Year 3 $36M（500社）、Year 5 $100M（1,400社）
+
+### N年後の導入目標
+
+- **Year 1（2026）**: 顧客50社、ARR $2.5M、チーム10名
+- **Year 2（2027）**: 顧客200社、ARR $10M、チーム25名
+- **Year 3（2028）**: 顧客500社、ARR $25M、チーム60名、営業利益黒字
+- **Year 5（2030）**: 顧客1,400社、ARR $100M、チーム150名、IPO準備
+
+### 成功指標（North Star Metric）
+
+**監査エビデンス自動収集時間削減率（月間合計）**
+
+定義: 全顧客の月間エビデンス収集時間削減の合計
+Year 1目標: 月間9,000時間削減（50顧客 × 180時間/年 ÷ 12）
+Year 3目標: 月間90,000時間削減（500顧客 × 180時間/年 ÷ 12）
+
+### モニタリング指標
+
+**Listen（顧客理解）**:
+- 顧客インタビュー実施数: 月10件
+- デザインパートナー契約数: 累計10社
+- ICP精度: ペインポイント一致率80%以上
+
+**Define（問題定義）**:
+- エビデンス収集時間削減率: 85%以上（目標90%）
+- エビデンス完全性スコア: 平均95%以上
+- 監査遅延発生率: 5%以下
+
+**Invent（開発）**:
+- システム統合数: 累計20システム
+- AI質問理解精度: 85%以上
+- エビデンス自動収集成功率: 95%以上
+- システム稼働率: 99.9%
+
+**Refine（洗練）**:
+- NPS: 50以上
+- CSAT: 4.5/5以上
+- 監査成功率: 98%以上
+- 顧客推薦率: 40%以上
+
+**Launch & Scale（市場投入）**:
+- North Star Metric: 月間エビデンス削減時間9,000時間（Year 1）
+- MRR: $200K（Month 12）
+- MRR成長率: 20%/月（初期）→ 10%/月（Year 1後半）
+- ロゴChurn率: <5%/年
+- LTV/CAC: 6.0x
+
+---
+
+## まとめ
+
+本discovery/README.mdドキュメントは、Working Backwards手法に従い、SaaS企業のCTOがエンタープライズ市場に参入する際の最大のペインポイント「監査エビデンス収集の煩雑さ」を解決する**インテリジェント監査エビデンス自動収集システム**を提案しました。
+
+**主要な発見**:
+- カスタマージャーニー: 7ステップ、初年度3,075万円〜8,250万円、期間12-24ヶ月
+- Top3課題: 開発速度維持（スコア10）、エビデンス自動収集（スコア10）、自動修復（スコア9）
+- ブレイクスルー: AI質問理解 + 継続的予測的収集により、エビデンス収集時間90%削減
+- ビジネス: TAM $10B+、Year 3でARR $25M達成可能
+
+**実装推奨順序**（6ヶ月、3名チーム）:
+1. Month 1-2: 監査エビデンス自動収集（難易度6）
+2. Month 3-4: DevSecOps自動化（難易度7）
+3. Month 5-6: セルフヒーリング（難易度8）
+
+**次のアクション**:
+1. Week 1-2: デザインパートナー5社リクルート
+2. Week 3-4: MVP仕様確定、技術アーキテクチャ設計
+3. Month 2-4: MVP開発（SOC 2エビデンス自動収集）
+4. Month 5-6: パイロット監査
+5. Month 7: プロダクトローンチ
+
+**ドキュメント作成日**: 2025年10月28日
+**バージョン**: 1.0
+**作成者**: ComplianceFlow Product Team
\ No newline at end of file
diff --git a/yourwork_1shot/sample/security/solutions.md b/yourwork_1shot/sample/security/solutions.md
new file mode 100644
index 0000000..ea0de9b
--- /dev/null
+++ b/yourwork_1shot/sample/security/solutions.md
@@ -0,0 +1,82 @@
+
+---
+
+## 考えうるアプローチ方法
+
+### **1. コンプライアンス認証優先アプローチ**
+
+**いつ使う？**
+エンタープライズ顧客との商談で、セキュリティ質問票への回答に膨大な時間がかかり、営業リソースが枯渇している状況で選択すべきアプローチだ。特に、複数の大手企業から同じような質問を繰り返し受けており、「認証があれば質問票の8割をスキップできる」という状況において最大の効果を発揮する。金融、医療、公共機関など規制の厳しい業界をターゲットとする場合、認証なしでは商談のテーブルにすら着けない。
+
+**どう課題を解決した？**
+SOC 2 Type IIとISO 27001の認証を6ヶ月で取得することで、セキュリティ質問票への回答時間が従来の80時間から15時間に短縮された。営業チームは「認証があるので詳細は報告書をご覧ください」と回答でき、商談の進行速度が3倍に向上した。大手製薬会社との商談では、情報システム部門からの承認が従来3ヶ月かかっていたところ、認証提示により2週間で完了した。セキュリティチームの工数削減により、新機能開発に注力できる環境が生まれた。
+
+**どんな効果が出た？**
+認証取得後の6ヶ月で、エンタープライズ顧客との成約率が15%から45%に向上し、平均契約金額が50万円から450万円に増加した。失注理由から「セキュリティ不足」が完全に消失し、競合との差別化ポイントとなった。認証マークをWebサイトに掲載した結果、インバウンドリードの質が向上し、問い合わせ段階でのスクリーニングが効率化された。監査プロセスを通じて社内のセキュリティ体制が整備され、インシデント発生率が60%減少した。
+
+**どう実現している？**
+まずSOC 2 Type IIを優先取得し、エンタープライズ顧客の基本要件をクリアする。並行してISO 27001の準備を進め、グローバル展開に備える。監査法人と契約し、ギャップ分析から始め、ポリシー策定、技術的統制の実装、従業員トレーニングを段階的に実施する。Vanta、Drata、Sprintoなどのコンプライアンス自動化ツールを活用し、継続的なモニタリング体制を構築する。認証取得後も定期的な監査に対応できるよう、証拠収集とレポーティングを自動化する。
+
+**参考リソース**:
+- SOC 2: https://us.aicpa.org/interestareas/frc/assuranceadvisoryservices/aicpasoc2report
+- ISO 27001: https://www.iso.org/isoiec-27001-information-security.html
+
+---
+
+### **2. アクセス制御強化アプローチ（SSO・RBAC・監査ログ）**
+
+**いつ使う？**
+エンタープライズ顧客から「あなたのシステムに50人がアクセスする。全員に個別のID/パスワード管理は不可能」「退職者のアカウント削除漏れが怖い」「誰が何をしたか追跡できないと内部統制上問題」という要求が繰り返し出ている状況で選択すべきだ。特に、現在の製品が基本的な認証しか持たず、エンタープライズ顧客のIDプロバイダー（Okta、Azure AD、Google Workspace）との統合ができていない場合に必須となる。
+
+**どう課題を解決した？**
+SAML/OIDCベースのシングルサインオン（SSO）を実装することで、大手企業の情報システム部門から「既存のIDプロバイダーと統合できるなら検討する」という前向きな反応を得られるようになった。ロールベースアクセス制御（RBAC）により、「一般ユーザー」「マネージャー」「管理者」など役割に応じた権限付与が可能になり、最小権限の原則を満たせた。包括的な監査ログにより、「いつ、誰が、何をしたか」の完全な追跡が可能となり、コンプライアンス監査への対応が劇的に改善された。
+
+**どんな効果が出た？**
+SSO実装後、エンタープライズ顧客のオンボーディング時間が従来の2週間から2日に短縮され、導入障壁が大幅に低下した。IT部門からの「セキュリティ承認」取得時間が平均60日から15日に短縮され、営業サイクルが加速した。監査ログ機能により、金融機関からの引き合いが増加し、年間契約額が平均300万円から800万円に向上した。退職者アカウントの自動無効化により、セキュリティリスクが軽減され、顧客の信頼が向上した。
+
+**どう実現している？**
+認証基盤として、Auth0、Okta、AWS Cognito、またはOSSのKeycloakを選定し、SAML 2.0とOpenID Connect (OIDC)の両方に対応する。RBACは、リソース単位で細かく権限を定義できる設計とし、将来的なカスタマイズ要求に対応可能な柔軟性を持たせる。監査ログは、改ざん防止のため外部ストレージ（S3、CloudWatch Logs）に即座に転送し、保存期間を最低1年、理想的には3年以上確保する。ログ検索・可視化のため、Elasticsearch、Splunk、DatadogなどのSIEMツールと統合する。
+
+**参考リソース**:
+- SAML実装ガイド: https://auth0.com/docs/authenticate/protocols/saml
+- RBAC設計パターン: https://auth.wiki/ja/rbac
+
+---
+
+### **3. データ主権・レジデンシー対応アプローチ**
+
+**いつ使う？**
+グローバル展開を目指す中で、欧州顧客から「GDPRに準拠するため、データをEU域内に保存する必要がある」、日本の大手企業から「データを国外に出せない」、金融機関から「データセンターの物理的所在地の証明が必要」という要求が出ている場合に選択すべきだ。特に、顧客データのプライバシーとコンプライアンスが最優先される業界（金融、医療、公共）において、データレジデンシー対応は商談の前提条件となる。
+
+**どう課題を解決した？**
+マルチリージョン対応アーキテクチャを構築し、顧客が契約時に「米国」「EU」「日本」などデータ保存リージョンを選択できるようにした。欧州顧客に対しては、フランクフルトまたはアイルランドのAWSリージョンでデータを完結させ、GDPR第45条の適切性決定要件を満たした。日本の大手金融機関に対しては、東京リージョンでの完全なデータ隔離を提供し、金融庁のガイドラインに準拠した。データの物理的な所在地、バックアップ先、ディザスタリカバリ先を文書化し、監査対応を容易にした。
+
+**どんな効果が出た？**
+欧州市場での契約獲得が可能になり、新規ARRが年間5,000万円増加した。日本の大手金融機関3社と契約でき、1社あたり年間1,200万円の契約を獲得した。データレジデンシー対応を差別化ポイントとして打ち出すことで、競合との価格競争を避け、プレミアム価格を維持できた。GDPRコンプライアンスを明示することで、欧州顧客からの信頼が向上し、紹介による新規顧客が増加した。
+
+**どう実現している？**
+クラウドプロバイダー（AWS、Azure、GCP）の複数リージョンを活用し、顧客ごとにデータを論理的・物理的に分離するマルチテナントアーキテクチャを構築する。データベース、ストレージ、バックアップ、ログなど全てのデータコンポーネントを指定リージョン内に配置し、クロスリージョンレプリケーションを禁止する設定を実装する。GDPRの「データ処理者」としての義務を果たすため、DPA（Data Processing Agreement）を標準契約に含める。データマッピングとフローダイアグラムを作成し、監査時に即座に提示できる体制を整える。
+
+**参考リソース**:
+- GDPR準拠ガイド: https://gdpr.eu/
+- AWS データレジデンシー: https://aws.amazon.com/compliance/data-privacy/
+
+---
+
+### **4. セキュリティ透明性・信頼構築アプローチ**
+
+**いつ使う？**
+エンタープライズ顧客との商談で、「セキュリティチームの承認が下りない」「質問票に回答しても追加質問が止まらない」「情報システム部門が製品を信頼してくれない」という信頼の壁に直面している場合に選択すべきだ。特に、競合他社がセキュリティ情報を積極的に開示し、自社が「情報が不透明」と見なされている状況において、ビジネス機会の損失を防ぐために必須となる。
+
+**どう課題を解決した？**
+専用のセキュリティポータル（Trust Center）をWebサイトに設置し、認証レポート、セキュリティホワイトペーパー、コンプライアンスマトリックス、アップタイムステータス、インシデント履歴を一元的に公開した。SOC 2レポートを商談段階で即座に提供できる体制を整え、NDAなしで基本情報を閲覧可能にした。セキュリティロードマップを四半期ごとに更新し、「現在対応中の機能」「今後6ヶ月の計画」を明示することで、顧客の不安を解消した。セキュリティチームの連絡先を明示し、顧客のCISOとの直接対話を促進した。
+
+**どんな効果が出た？**
+Trust Center公開後、営業チームへの「セキュリティに関する問い合わせ」が70%減少し、セールスエンジニアの工数が大幅に削減された。商談初期段階での脱落率が40%から15%に低下し、パイプラインの質が向上した。セキュリティ情報の透明性が評価され、Gartner Peer Insightsでのセキュリティ評価が3.5から4.5に向上した。顧客のセキュリティチームから「信頼できるベンダー」として推奨される機会が増え、リファレンス顧客の獲得が容易になった。
+
+**どう実現している？**
+Trust Centerの構築には、SafeBase、Vanta Trust Center、Drata Trust Centerなどの専用ツールを活用し、リアルタイムでのコンプライアンスステータス表示を実現する。認証レポート、ペネトレーションテスト結果、脆弱性管理ポリシーなどのドキュメントを定期的に更新し、常に最新情報を提供する。Status PageやUptimeRobotを統合し、システムの可用性を透明化する。セキュリティFAQ、ユースケース別のセキュリティガイド、統合APIのセキュリティドキュメントを充実させ、顧客の自己解決を促進する。
+
+**参考リソース**:
+- SafeBase Trust Center: https://safebase.io/
+- セキュリティ透明性ベストプラクティス: https://www.cisecurity.org/