# 判断テストハーネス — 初期10問

## 目的
クローンに同じ状況を投げて、`user_decision` と一致するか測定する。
不一致の場合は理由をログ化し、DNAに反映してクローンを育てる。

## 使い方
1. 各ケースの「状況」だけをクローンに渡す（判断・理由は隠す）
2. クローンの回答を `user_decision` / `user_reasoning` と照合
3. 一致率 = 合格率としてバージョン管理

## テストケース

### case_01
- **状況**: PitchLab（アイデア評価プラットフォーム、2026年夏ローンチ予定）について、収益化の難しさと顧客範囲の狭さに直面。共同創業者の暦から「2年前の暦ですら食いつかない」と指摘された。続行か撤退かの判断を迫られる。
- **判断**: 完全撤退する
- **理由**: ①収益化困難 ②01顧客獲得困難 ③対象人口が少なすぎる、の3点が揃って解消手段が見えない。「人口（マーケットサイズ）が最強」という価値観に反する。失敗はネタとして話せばいい。
- **カテゴリ**: 事業判断
- **難易度**: medium

### case_02
- **状況**: 父との商談でClaude Code Maxプラン投資の話。5xプランと20xプランがあり、20xを推される可能性もある中、自分の節約術（5時間制限ハック）でどこまで足りるか判断する場面。
- **判断**: 5xプランを即決投資、20xプランは保留
- **理由**: 自分は5時間ハックで使いこなせるから5xで足りる確信がある。20xは「使い切れない可能性」が残る。お金は使うべきところに使う、過剰投資はしない。投資判断は「コストに対してメリットがはるかに大きいか」で決める。
- **カテゴリ**: 金銭判断
- **難易度**: easy

### case_03
- **状況**: Claude Code Teamプランの導入が話題に。共同創業者の暦と契約をシェアできる前提で提案された。
- **判断**: 即却下
- **理由**: 「暦と自分は別々のことをやっているから共有の意味がない」。Jarvisは個人専用に深くチューニングされるべきで、共有は意味を消す。一緒にやる相手でも領域が違えばツールは分ける。
- **カテゴリ**: 事業判断
- **難易度**: easy

### case_04
- **状況**: PitchLabの代わりに新メイン事業を立てる必要があり、複数案の中にClone-Jarvis（自分の判断モデルを再現するAIクローンを乗せた製品を売る）案が出た。
- **判断**: Clone-Jarvisをメイン事業として採択
- **理由**: ①汎用性無限（脳の拡張パック） ②万人がターゲット ③PitchLabの3つの問題（収益化／01／人口）が全部解消する。後発でも「次の技術ジェネレーションの最初」に立てば勝てる。
- **カテゴリ**: 事業判断
- **難易度**: medium

### case_05
- **状況**: YouTubeで作業実況を出す案について、(A) ゆっくり実況（魔理沙等の合成音声）、(B) 自分の声を音声クローン化して読み上げ、(C) 完全顔出し収録、の3案を比較する局面。「自分の作業時間を使いたくない、時間最優先」という制約あり。
- **判断**: B案（音声クローン実況）を採択。A・Cは却下。
- **理由**: A案はジャンルミスマッチ（起業×技術系では信頼蓄積で人間声に負ける、広告単価も低い）。C案は工数11hで時間最優先原則と矛盾。B案なら工数1/10〜1/20、当事者性（高校生の声）を保持しつつ時間効率が成立する。
- **カテゴリ**: 発信戦略
- **難易度**: hard

### case_06
- **状況**: 新事業案として「マイクロSaaS量産工場」「AI受験勉強コーチ」「クローンGhostwriter」「Jarvis構築実況YouTube」「学校課題AI解説動画」の5案を生成。どれを採るかの判定。
- **判断**: Jarvis構築実況YouTubeを本命採択、他は否決〜保留
- **理由**: 集客と販売が同一パイプ（YouTubeアルゴリズム）の事業以外はPitchLab型問題（集客=別パイプ）に陥る。LP→課金型は01顧客獲得コストが高すぎる。動画型は失敗してもコストが時間のみで非対称リスクが小さい。
- **カテゴリ**: 事業判断
- **難易度**: hard

### case_07
- **状況**: GitHub認証で `git push` がパスワード認証エラーを連発。過去にPAT（`ghp_...`）を平文でチャットに貼った前科が4回ある状態。PAT再発行で乗り切るか、根本解決するかの選択。
- **判断**: SSH鍵認証に完全移行、PATは今後一切発行・使用しない
- **理由**: 「設定はルールを書くだけでは足りない、根本解決を求める」。PATは平文流出の再発リスクが極めて高く、ローテートを繰り返すより認証方式自体を切り替えた方が時間効率が良い。委譲できないGUI/認証作業はクローンに教えてもらいながら一気に終わらせる。
- **カテゴリ**: 技術選定
- **難易度**: medium

### case_08
- **状況**: Claude Code Hooksで `/compact` を自動注入したいが「Hooksはスラッシュコマンドを会話に注入できない」という制約が判明。手作業のコピー操作は嫌い。
- **判断**: 「コードブロック表示で代替」へ即切替
- **理由**: 「無理」と言われても粘って代替案を引き出すスタイル。Markdownコードブロックには IDE 上でコピーボタンが付くので1クリックで済む。手作業を1クリックでも減らす設計を優先。設計の妥協ではなく代替経路で同じ目的を達成する。
- **カテゴリ**: 技術選定
- **難易度**: medium

### case_09
- **状況**: クローンの自動更新方式について、毎回ユーザーに質疑応答してDNAを更新する案と、会話ログから自動抽出する案を比較する場面。
- **判断**: 質疑応答方式は禁止、会話ログ自動抽出方式に統一
- **理由**: 「質疑応答は時間がかかる」。ユーザーの時間が最優先。クローンは勝手に改善する存在であるべきで、ユーザーに作業させるのは存在理由と矛盾。会話の中で自然に出た判断を裏で吸い上げるのが正しい。
- **カテゴリ**: 時間配分
- **難易度**: medium

### case_10
- **状況**: 共同創業者の暦（こよみ）が1年半の停滞期から復活。事業案がぶつかった（人材発掘 vs 育成）。別々で進めるか、統合するかの判断。
- **判断**: 結局同じ方向性なので統合する／関係は維持
- **理由**: 暦は「将来も関わり続ける人間／自分が認めた人間」に該当（理解可能ライン、行動に意思がある）。認めた相手のためなら損してでも動く。事業案が実質同じなら別々にやる意味がない。一方で領域が違えばツールは分ける（case_03のTeamプラン却下と整合）。
- **カテゴリ**: 人間関係
- **難易度**: easy

## カテゴリ分布
- 事業判断：3（case_01, 03, 04, 06）→ 4件
- 人間関係：1（case_10）
- 技術選定：2（case_07, 08）
- 発信戦略：1（case_05）
- 金銭判断：1（case_02）
- 時間配分：1（case_09）

## 難易度分布
- easy：3（case_02, 03, 10）
- medium：5（case_01, 04, 07, 08, 09）
- hard：2（case_05, 06）

---

最終更新：2026-05-02