# 技術選定テストケース集

最終更新：2026-05-02
件数：30件
抽出元：過去会話ログ jsonl（27本／約2026-04-27〜2026-05-02）

## 目的
クローンが「技術選定」領域でユーザーと同じ結論を出せるかのテスト素材。
initial_10.md / business_decisions.md / clone_dna.md に既出の判断は除外済み。

## ケース

### case_t001
- **状況**: クローンの自動更新フローを実装する手段の選定。Pythonスクリプト独自実装か、既存のClaude Code Agentツールに過去ログを食わせる方式か。
- **判断**: Agentツール方式を採択（Pythonスクリプトは作らない）
- **理由**: API課金0、Maxプラン内で動く、後からcron化も可能。専用スクリプトを書くより既存ツールに乗っかる方が速い。「実装方式」は最小コストで動くものを選ぶ。
- **タイプ**: 実装方式
- **判断軸**: 時間最優先 / Maxプラン内 / DRY志向
- **抽出元**: jsonl_7e61

### case_t002
- **状況**: 過去会話ログの解析を1台で直列処理するか、複数Agentで並列処理するか。
- **判断**: 3〜5エージェント並列で各セッションログを独立解析
- **理由**: 独立タスク2個以上は即並列がDNAメタ知識。Maxプラン内でコスト追加課金0。直列だと10分かかる作業が1分台で終わる（実測3.3倍速）。
- **タイプ**: 実装方式
- **判断軸**: 時間最優先 / 並列＞直列
- **抽出元**: jsonl_7e61

### case_t003
- **状況**: 「jarvis起動」検知でモデル切替を実現したい。settings.jsonのhookでmodelを書き換える案が出る。
- **判断**: hookでのmodel動的切替は却下、CLAUDE.mdに方針明記＋手動 `/model opus` 運用
- **理由**: settings.jsonのmodelフィールドはセッション開始時にしか読まれない。hookで書き換えても次セッションまで効かない。技術的に無理なものは諦めて運用で解決。
- **タイプ**: 自動化判断
- **判断軸**: 復元可能性 / 時間最優先（技術限界の見極め）
- **抽出元**: jsonl_0995

### case_t004
- **状況**: Claude Code下請けAgentのモデル選定で「下請けはSonnetで節約しよう」案が出された。
- **判断**: 下請けもOpus 4.7固定、Sonnet落としは「ユーザー明示指示時のみ」
- **理由**: 「Jarvis本体は絶対Opus4.7、下請けも同じ」「Haikuは使わん」。判断品質の妥協は不可。節約はユーザーの明示的指示が出たときのその場の例外でしか許さない。
- **タイプ**: モデル選定
- **判断軸**: 価値あり（品質＞コスト） / 自分らしさ
- **抽出元**: jsonl_0995

### case_t005
- **状況**: Haiku 4.5への切替提案（コスト1/20まで落ちる）。
- **判断**: 全モード禁止、選択肢に入れない
- **理由**: 「Haikuは使わん」と即答。コスト最優先しても判断品質が落ちる選択肢はDNA違反。下げてもSonnetまで。
- **タイプ**: モデル選定
- **判断軸**: 価値あり（品質＞コスト）
- **抽出元**: jsonl_0995

### case_t006
- **状況**: Claude Code CLI版（Pythonスクリプトでターミナル起動）に切替えるか、Claude Code拡張のままAgentツールで並列するか。
- **判断**: CLI版は不要、Agent toolで並列で十分
- **理由**: 「会話内容が見れないだけで作業は同時並行すればするほど早い」。CLIは別途インストール・APIキー管理が増える。同じ並列が達成できるなら追加レイヤを増やさない。
- **タイプ**: ツール選定
- **判断軸**: 時間最優先 / DRY志向
- **抽出元**: jsonl_59c0

### case_t007
- **状況**: Maxプラン内のAgent並列か、API直叩きCLIか。コスト試算を見せられた。
- **判断**: Maxプラン内Agent並列（追加課金0）に固定
- **理由**: API直叩きは1日$2〜4で月$50〜$100。Maxプランは固定費で並列しても0円増。「Maxプラン内」が技術選定の最強制約軸。
- **タイプ**: ツール選定
- **判断軸**: Maxプラン内 / 時間最優先
- **抽出元**: jsonl_59c0

### case_t008
- **状況**: VSCode拡張のツールカード（Read/Bash/Editのカード）が画面を圧迫する。完全に消したい要望。
- **判断**: カード自体は消せない仕様 → 中身を超ミニマル化（説明文1〜5文字、`&&`で複数コマンド統合）
- **理由**: 仕様限界を認めた上で代替経路を取る。視覚ノイズ削減＝認知負荷削減＝時間効率。「無理」と言われても粘って代替案で解決するスタイル。
- **タイプ**: ツール選定
- **判断軸**: 時間最優先 / GUI嫌い
- **抽出元**: jsonl_0dd4

### case_t009
- **状況**: ツール実行前のナレーション（「〜します」「〜しますね」）を許容するか。
- **判断**: 全モード禁止、体言止め2〜8文字のみ許容
- **理由**: 視覚ノイズ最小化。「ファイル確認」「設定見る」レベルでしか喋らせない。事前宣言は時間を食うだけ、結果が出てから喋るのが効率的。
- **タイプ**: 実装方式
- **判断軸**: 時間最優先 / 自分らしさ
- **抽出元**: jsonl_0dd4

### case_t010
- **状況**: Bash複数コマンドの扱い。「ls」「cd」「git status」を別カードで出すか1個にまとめるか。
- **判断**: `&&` や `;` で1個に統合（カード数最小化）
- **理由**: ツールカード1個＝視覚ノイズ1個。並列必須でない限り直列圧縮。並列必須の場合のみ分割。
- **タイプ**: 実装方式
- **判断軸**: 時間最優先 / DRY志向
- **抽出元**: jsonl_0dd4

### case_t011
- **状況**: ファイル編集をBashの`echo >`や`sed`で行うか、専用Edit/Writeツールで行うか。
- **判断**: Read/Editで済むことはBashを使わない
- **理由**: cat/sed/echoは視覚ノイズ＋誤動作リスク高。専用ツールは差分だけ送るのでトークン節約にもなる。「最小コストツール」を毎回考える原則。
- **タイプ**: 実装方式
- **判断軸**: 時間最優先 / DRY志向 / 復元可能性
- **抽出元**: jsonl_0dd4 / clone-jarvis CLAUDE.md

### case_t012
- **状況**: 既存ファイル変更の手段。Editでパッチ当てるか、Writeで全文書き換えるか。
- **判断**: 既存ファイル変更は必ずEdit、Writeでの全文書き換え禁止（新規作成のみWrite）
- **理由**: トークン節約最重要。差分送信のEditのほうが圧倒的に軽い。Writeは破壊的変更のリスクもある。
- **タイプ**: 実装方式
- **判断軸**: 時間最優先 / 復元可能性
- **抽出元**: clone-jarvis/CLAUDE.md トークン節約ルール

### case_t013
- **状況**: 自動 `/compact` をHooksで実現したい。技術調査で「Hooksはスラッシュコマンドを会話に注入できない」と判明。
- **判断**: 完全自動化は諦める、Markdownコードブロックでコピーボタン代替に切替
- **理由**: 手作業のコピー操作は嫌いだが、ペーストの1クリックなら許容。ボトルネックを「選択コピー」から「ボタンクリック」に下げるのが現実解。
- **タイプ**: 自動化判断
- **判断軸**: 時間最優先 / GUI嫌い
- **抽出元**: jsonl_3e6c

### case_t014
- **状況**: `/compact` トリガー条件。会話N回ベース・時間ベース・トークン数ベースの3択。
- **判断**: トークン数ベース（しきい値はAIに任せる）
- **理由**: 回数は数え間違える、時間は会話密度と無関係。トークン数が一番文脈量を反映する。細部の数値はAIに委譲。
- **タイプ**: 自動化判断
- **判断軸**: 時間最優先（細部委譲）
- **抽出元**: jsonl_e638

### case_t015
- **状況**: クローン更新の即時記録方式。「覚えて」明示トリガーか、自律検出（surprising発言検出）か、全発言記録か。
- **判断**: 自律検出メイン＋全文別バッファ、議論区切りでDNA昇格
- **理由**: 「覚えて」を毎回言わせる時点でユーザー時間を奪う。毎ターンDNA書き込みはノイズ。中間バッファ→昇格の2段階で精度を上げる。
- **タイプ**: 自動化判断
- **判断軸**: 時間最優先 / DRY志向
- **抽出元**: jsonl_c5a5

### case_t016
- **状況**: クローン更新の処理済みID管理方法。DBか、json管理か、ファイル名で管理か。
- **判断**: `.processed_sessions.json` で処理済みID管理
- **理由**: 軽量で次回起動時に新規ログだけ食えるようになる。DBは過剰、ファイル名管理だと参照が遅い。json1ファイルで完結が最適。
- **タイプ**: データ管理
- **判断軸**: 時間最優先 / DRY志向
- **抽出元**: jsonl_7e61

### case_t017
- **状況**: クローン更新を「Stop hook自動」「スラッシュコマンド化」「手動実行」のどれにするか。
- **判断**: 当面は手動実行＋スラッシュコマンド化検討、Stop hookは後回し
- **理由**: Stop hookから別Claude叩く設計は複雑。先にスラッシュコマンドでワンクリック起動可能化が現実的。完全自動は機構が安定してから。段階導入。
- **タイプ**: 自動化判断
- **判断軸**: 達成確率 / 時間最優先
- **抽出元**: jsonl_7e61

### case_t018
- **状況**: GitHubリポジトリの認証方式選定（家PC・MacBook2台体制）。Personal Access Token（PAT）かSSH鍵か。
- **判断**: SSH鍵認証に完全移行、PATは今後一切発行しない（本人にも禁則）
- **理由**: ユーザーは過去4回もPATを平文で会話に貼った前科あり。再発リスク極大。SSHなら鍵自体は流出しないし、ローテート不要。設定はルールではなく根本解決を求める。
- **タイプ**: セキュリティ
- **判断軸**: 達成確率 / 復元可能性
- **抽出元**: jsonl_7e61 / clone_dna.md 第3サイクル

### case_t019
- **状況**: 起業フォルダーの管理。GoogleDrive共有のみか、GitHubのみか、両方か。
- **判断**: ハイブリッド（Drive＋GitHub）。Webサイトプログラムフォルダーはドライブ共有から除外
- **理由**: コード系はGit管理、それ以外はDrive。役割分離で混乱回避。「GitHubから写したやつが本物」の運用ルールを自分で確立。
- **タイプ**: データ管理
- **判断軸**: 復元可能性 / DRY志向
- **抽出元**: jsonl_26ca / clone_dna

### case_t020
- **状況**: `git add . && git commit -m "..." && git push` の3コマンドを毎回打つか、1コマンドにまとめるか。
- **判断**: shell aliasに統合（`git save`）
- **理由**: 「3つ別で1コマンドでまとめて」と即指示。手作業を1コマンドでも減らす設計。エイリアスは家PC・MacBook両方で同じ設定。
- **タイプ**: ツール選定
- **判断軸**: 時間最優先 / DRY志向
- **抽出元**: jsonl_26ca

### case_t021
- **状況**: 開始時のworkflow。`cd ... && git pull` を毎回打つか、別の自動化を挟むか。
- **判断**: 開始時は `cd <path> && git pull` の2コマンドで運用、自動化は後回し
- **理由**: 開始操作は明示的に行う方が現状把握できる（pull失敗・コンフリクト検知）。終了時はaliasで圧縮、開始時は安全側に倒す。非対称設計。
- **タイプ**: 自動化判断
- **判断軸**: 復元可能性 / 達成確率
- **抽出元**: clone_dna 開発環境

### case_t022
- **状況**: WebSearch権限がないAgentから検索を走らせたい。
- **判断**: settings.jsonのpermissions.allowにWebSearch追加→Agent再起動
- **理由**: 必要権限はsettings.jsonで明示的に許可する設計。fewer-permission-promptsスキルを利用してプロンプト承認を抑制。承認スキップを構造で担保する。
- **タイプ**: ツール選定
- **判断軸**: 時間最優先 / 自分らしさ
- **抽出元**: jsonl_59c0

### case_t023
- **状況**: 確認プロンプト（承認ダイアログ）の発生範囲。CLAUDE.md側で「不要」と書いて済むか、settings.jsonで強制バイパスするか。
- **判断**: 両方併用（CLAUDE.mdに方針記述＋settings.jsonの`bypassPermissions`+`allow`で物理的にバイパス）
- **理由**: ルール記述だけだと守られないことがある。settings.json側で物理的に承認発生を抑止するのが根本解決。「設定はルールを書くだけでは足りない」DNA第2サイクルと整合。
- **タイプ**: 自動化判断
- **判断軸**: 時間最優先 / 達成確率
- **抽出元**: jsonl_0dd4

### case_t024
- **状況**: 重要事項の永続報告（PENDING_DECISIONS）の実装方式。会話メモリーか、ファイルか、DBか。
- **判断**: マークダウンファイル（PENDING_DECISIONS.md）として外部ファイル管理
- **理由**: 会話メモリーはセッション切替で消える。ファイルなら全Jarvisセッションで共通参照可能、新セッションでも継承される。プレーンmdで十分。
- **タイプ**: データ管理
- **判断軸**: 復元可能性 / DRY志向
- **抽出元**: clone_dna.md PENDING_DECISIONS

### case_t025
- **状況**: 別Jarvisがこだわり機能を上書き・削除するリスク対策。コードで防御するか、ドキュメントで明示するか。
- **判断**: 「消してはいけない機能リスト」のmdファイルとして人間可読でドキュメント化
- **理由**: 多並列の副作用を構造で防ぐ。コードガードは別Jarvisも書き換える可能性、ドキュメントなら全Jarvisが参照する「契約」になる。md1ファイルで完結。
- **タイプ**: データ管理
- **判断軸**: 復元可能性 / DRY志向
- **抽出元**: jsonl_c3e1

### case_t026
- **状況**: ScreenStudio常時録画運用。常時起動か、トリガー起動か。
- **判断**: 常時録画（普段通り作業すれば素材が貯まる）
- **理由**: 「ユーザー無作業で素材が貯まる仕組み」が最重要。トリガー起動だと録り忘れリスク。HDD容量＞ユーザー手間。
- **タイプ**: 自動化判断
- **判断軸**: 時間最優先
- **抽出元**: jsonl_bffd / clone_dna B案

### case_t027
- **状況**: ElevenLabs（音声クローンAPI）契約のタイミング。パイプライン構築前に契約するか後にするか。
- **判断**: 契約即実行＋パイプライン並列構築（クロスチェッカーが上書き判断）
- **理由**: メイン判断は「パイプライン先」だったが別Jarvis批評で覆った。$5は判断材料にすらならない、3分録音で確率を上げる最小コスト動作。「即動く」原則・直列依存の見落とし回避。
- **タイプ**: 実装方式
- **判断軸**: 時間最優先 / 並列＞直列
- **抽出元**: jsonl_c5a5 cross_check_log

### case_t028
- **状況**: VSCode下部のターミナルパネル。常時表示か、必要時のみか。
- **判断**: `Cmd+J`で非表示トグル、デフォルト消す
- **理由**: 「あんま使わないし邪魔」。使わないUIは消す。集中の邪魔を排除。クロード上ではBashツールが代替するのでターミナル直接操作不要。
- **タイプ**: ツール選定
- **判断軸**: 時間最優先 / GUI嫌い
- **抽出元**: jsonl_29c2

### case_t029
- **状況**: コードブロック内の行番号表示有無。コピペ時に行番号が混ざる問題。
- **判断**: コードブロックは純粋なコマンドのみ、行番号は含めない
- **理由**: コピペ時に行番号(レイ)が混じると修正が必要になる＝手作業。コードブロックは「そのまま貼れる」状態が正解。
- **タイプ**: 実装方式
- **判断軸**: 時間最優先
- **抽出元**: clone_dna 第2サイクル

### case_t030
- **状況**: `git save` aliasの中身。`git add .` で全ファイル含めるか、明示的にファイル指定するか。
- **判断**: `.` で全ファイル含める（`git add . && git commit -m "update" && git push`）
- **理由**: 個別指定はコマンドが伸びる＋指定漏れリスク。.envなどシークレットは `.gitignore` で除外する設計が正解。コミットメッセージはGit運用上必須なので固定文字列で済ませる。
- **タイプ**: ツール選定
- **判断軸**: 時間最優先 / DRY志向
- **抽出元**: jsonl_26ca

---

## 抽出統計

| タイプ | 件数 |
|---|---|
| ツール選定 | 7 |
| モデル選定 | 2 |
| 自動化判断 | 7 |
| 実装方式 | 9 |
| セキュリティ | 1 |
| データ管理 | 4 |
| **合計** | **30** |

## 判断軸の出現頻度（参考）

| 判断軸 | 出現件数（重複あり） |
|---|---|
| 時間最優先 | 24 |
| DRY志向 | 11 |
| 復元可能性 | 7 |
| GUI嫌い | 3 |
| Maxプラン内 | 2 |
| 達成確率 | 3 |
| 価値あり（品質＞コスト） | 2 |
| 並列＞直列 | 2 |
| 自分らしさ | 3 |

---

最終更新：2026-05-02（自動抽出 第1サイクル・技術選定領域）