Claude Codeの一時ファイルでビジネスロジック検証：UI不要で要件を発見する方法

はじめに

ども！Claude Codeにべったりな龍ちゃんです。

前回の記事「Claude Code: 公式MCPを補完するSkills設計パターン」で、公式MCPを補完するSkillsパターンを紹介し、UI開発工数を大幅削減した事例を共有しました。

特に、こんな成果を報告しました：

• フロントエンド開発をスキップ
• UI設計（3-5日）をスキップ
• React開発（7-10日）をスキップ
• 開発工数を大幅削減（実測例として数時間〜1日で実装）

でも、概要しか書いていないので：

「なぜフロントエンド開発をスキップできたの？」
「UIなしでどうやってビジネスロジックを整備したの？」
「短時間で完成した秘密は何？」

前回の記事では「Claude CodeをUIとして使った」と説明しましたが、それだけでは本質的な理由になっていません。

本記事では、なぜフロントエンド開発をスキップできたのか、その核心に迫ります。

キーワードは、tmp/ディレクトリに蓄積されるスクリプトです。

結論を先に言うと、tmpスクリプトは「ゴミ」ではなく、「人間の自然言語から生まれた純粋な要件」でした。この発見が、前回の記事で紹介した4層構造（公式SDK → 自作Client → CLI → Skill）を可能にしました。

TL;DR

この記事で分かること：

• なぜUI開発をスキップできたのかの本質的理由
  • tmpスクリプトがビジネスロジックを整備してくれた
  • Claude Codeが「人間の操作UI」として機能
  • UIは後回しにできる（ロジック確定後 → 手戻りなし）
• tmpスクリプトの再定義
  • 従来: tmp/ = 一時的なゴミ
  • 新発見: tmp/ = 人間の自然言語から生まれた純粋な要件の可視化
• ロジックファースト検証のプロセス
  • CLI基本実装 → Skill定義 → tmp蓄積 → tmp観察 → ビジネスロジック抽出 → CLI拡張
  • 頻出パターンの発見（5回生成 → Skill化）
  • ビジネスルールの具現化（類似度90%、マージ優先順位等）
• 実践方法（詳細は次回の記事「Claude Code一時ファイルからSkillsへ：ビジネスロジック抽出の実践ガイド」で解説）
  • 週次レビュー、docs/research/へのログ記録
  • 3回以上生成 → Skill機能追加候補
• 開発工数削減の本質
  • AIツールによる速度向上ではない
  • UI開発というアプローチ自体を変えたこと

重要な前提条件:

• Claude Code Skillsの基本を理解している
• 前回の記事「Claude Code: 公式MCPを補完するSkills設計パターン」を読んでいる

こんな人に読んでほしい

✅ 前回の記事を読んで「なぜ短時間で完成できたのか」が気になった人
✅ フロントエンド開発なしでビジネスロジックを整備したい人
✅ application/tools/tmp/にスクリプトが溜まっている人
✅ 要件が固まっていない段階で開発を始めたい人
✅ UI設計の手戻りコストに悩んでいる人
✅ 「tmpスクリプト = ゴミ」と思って削除していた人

従来のUI先行開発の問題

まず、典型的な開発フローを見てみましょう：

要件定義 → UI設計 → フロントエンド実装 → バックエンド実装

根本的な問題: ビジネスロジックが固まっていない段階でUIに投資している

例えば、こんなシーンを想像してください：

要求:「重複カテゴリをマージできる画面が欲しい」
  ↓
UI設計開始: ボタン配置、確認ダイアログ、進捗表示...
  ↓
実装開始
  ↓
「あれ、重複の定義ってどうするんだっけ？」
「マージ時に投稿数が多い方を残す？古い方を残す？」
  ↓
仕様変更 → UI再設計 → 再実装 ← 高コスト！

要件変更 = 高コストの悪循環：

• ビジネスロジック変更 → UIも変更が必要
• 小さい単位での試行錯誤ができない
• UI完成しないと実際の操作フローが分からない
• 完成後に「やっぱりこの機能いらない」と判明…

前回の記事で触れた開発工数の差（16-24日 vs 数時間〜1日）の本質的な理由がここにあります。

ロジックファースト検証の発見

私の開発環境と、ロジックファースト検証の起源

以前、AIチャットで話すだけ!X予約投稿を完全自動化するシステム構築術で紹介したX予約投稿システムは、Firestoreベースでした。

その後、データベースをSupabaseに移行することになりました。そして移行時に、ビジネスロジックの変更要求が出てきたんです。

ここで悩みました：

従来の方法: UI設計 → フロントエンド実装 → ビジネスロジック検証
  ↓
問題: ビジネスロジックが固まっていないのにUIを作る？
      検証してみたら要件変更 → UI作り直し？

「先にビジネスロジックを検証できないかな…」

そこで思いついたのが、Claude CodeをUIとして使う方法でした。UIを作らず、CLIツール + Skillsでビジネスロジックを先に検証してしまおう、と。

前回の記事で紹介したSupabase公式MCPを補完するSkillsを実装し、こんな構成になりました：

CLIツール（db コマンド）
  ↓
Skills定義（.claude/skills/*.md）
  ↓
Claude Codeから操作可能

特徴:

• 基本CRUD操作のみ実装（posts, categories, hashtags, series）
• X投稿管理システムのデータベースを操作
• UIは存在しない
• Claude Codeが「人間の操作UI」として機能

Skill運用開始後に起きた面白いこと

基本操作は順調でした：

私: 「投稿一覧を取得して」
Claude Code: uv run db posts list を実行
✅ 成功

私: 「カテゴリ一覧も見せて」
Claude Code: uv run db categories list を実行
✅ 成功

「Skill、便利だな！基本操作は完璧！」と思っていました。

しかし、組み合わせ処理を依頼すると、面白いことが起きました：

私のリクエスト: 「重複カテゴリを見つけてマージして」

Claude Codeの反応:

1. uv run db categories list を実行
2. カテゴリ一覧を取得
3. application/tools/tmp/merge_duplicate_categories.py を生成 ← ここ！
4. スクリプトを実行して重複を検出
5. uv run db categories merge を実行

観察: Skill（db）は基本操作のみ提供していました。組み合わせ処理のために、Claude Codeが中間処理のスクリプトをtmp/に生成していたんです。

「あれ、tmpにスクリプトが残ってる。これ、削除すべき？」

tmpの蓄積

1週間後、tmp/ディレクトリを覗いてみると：

tmp/
├── merge_duplicate_categories.py（3回生成）
├── validate_orphaned_posts.py（5回生成）
├── analyze_hashtag_stats.py（2回生成）
├── export_posts_csv.py（1回生成）
└── bulk_update_scheduled_posts.py（4回生成）

「これ、ゴミじゃなくて何か意味があるのでは？」

同じスクリプトが複数回生成されている…これは偶然じゃない。

発見：tmpは「自然言語から生まれた要件」だ

tmpの本質的価値

従来の認識:

• tmp/ = 一時的なゴミ
• 実行後は削除すべき
• 気にしなくて良い

新しい認識（私の発見）:

• tmp/ = 人間の自然言語から生まれた純粋な要件の可視化
• Skillの足りない機能の証拠
• ビジネスロジックの暗黙知が形になったもの
• 次の改善のヒント

なぜ「自然言語から生まれた要件」なのか？

理由1: 実際の利用パターンの記録

従来の要件定義プロセス:

人間が考える → 要件書に書く → 「こうあるべき」

→ 抽象的、実際に使われるかは不明

ロジックファースト検証のプロセス:

人間が自然言語で依頼 → Claude Codeがtmpスクリプト生成 → 「実際にこう使った」

→ 具体的、実証済み、検証済み

読者への問いかけ: あなたが書いた要件書、実際に全部使われましたか？

理由2: ビジネスルールの具現化

これが一番面白い発見でした。

要件書に書いたこと（抽象的）:

重複カテゴリを検出してマージできること

tmp/merge_duplicate_categories.py の中身（具体的）:

def find_duplicates(categories):
    """重複カテゴリを検出

    重複の定義:
    1. name完全一致
    2. name.lower()一致（大文字小文字無視）
    3. 編集距離が2以下（typo考慮）
    """
    for i, cat1 in enumerate(categories):
        for cat2 in categories[i+1:]:
            similarity = SequenceMatcher(
                None,
                cat1["name"].lower(),
                cat2["name"].lower()
            ).ratio()

            if similarity > 0.9:  # 90%以上の類似度
                duplicates.append((cat1, cat2, similarity))

    return duplicates

def merge_strategy(duplicates):
    """マージ戦略

    優先順位:
    1. 投稿数が多い方を残す
    2. created_atが古い方を残す
    3. UUIDが辞書順で小さい方を残す
    """
    # ... 実装 ...

これが「人間の純粋な要件」です:

• 重複の具体的な定義（類似度90%以上）
• マージの優先順位（投稿数 > 作成日時 > UUID）
• エッジケースの扱い（複数重複がある場合）

→ 要件書には書かれていない詳細が、tmpスクリプトには全て含まれている

私が「重複カテゴリをマージして」と自然言語で依頼した時、頭の中にあった暗黙の要件が、tmpスクリプトとして可視化されたんです。

理由3: 組み合わせパターンの発見

Skill設計時の想定:

• 基本CRUD操作のみ考えていた
• list, get, create, update, delete

tmp/が教えてくれた実際の使い方:

• list → 処理 → merge（組み合わせ）
• list → フィルタ → validate（検証）
• list → 集計 → sort（分析）

→ 実際の組み合わせパターンが自然に記録される

Skill設計時には考えていなかった使い方が、tmpに全部記録されていました。

tmpに蓄積される3種類の情報

分析してみると、tmpスクリプトには3種類の情報が含まれていました：

1. 基本操作の組み合わせパターン
   • どのコマンドをどの順序で実行するか
   • 例: db categories list → 処理 → db categories merge
2. Skillにない独自ロジック
   • 重複検索アルゴリズム（類似度計算）
   • クロスチェック（複数テーブル横断）
   • 統計・集計（Top10表示）
3. ビジネスルールの実装
   • 「重複とは何か」の具体的な定義
   • 「孤立とは何か」の判断基準
   • 「有用なハッシュタグ」の評価軸

tmpからビジネスロジックを抽出する

頻出パターンの観察

簡単な分析で、何が必要な機能かが見えてきました：

# tmp/内のスクリプトを名前でカウント
ls application/tools/tmp/*.py | xargs -n1 basename | sort | uniq -c | sort -nr

結果:

5 validate_orphaned_posts.py
4 bulk_update_scheduled_posts.py
3 merge_duplicate_categories.py
2 analyze_hashtag_stats.py
1 export_posts_csv.py

解釈:

• 5回生成 → 週1回以上使う → Skillに組み込むべき
• 3-4回 → 定期的に使う → Skill機能追加候補
• 1-2回 → tmpのままで良い（稀なケース）

データが教えてくれました。「validate_orphaned_posts.pyは必要な機能だ」と。

ビジネスロジックの抽出事例

事例1: validate orphaned → Skill機能化

tmpの内容（5回生成）:

# tmp/validate_orphaned_posts.py の処理フロー
1. uv run db posts list（全投稿取得）
2. カテゴリ未設定の投稿をフィルタ
3. 結果をリスト表示

発見:

• ✅ 孤立投稿の検証は定期的に行う作業（週1回以上）
• ✅ ロジックが毎回同じ
• ✅ ビジネスルールが固まっている

「これ、毎回tmpスクリプト生成するの無駄じゃない？Skillに組み込もう」

Skillへの追加（Phase 3実装）:

# 新しいコマンドとして実装
uv run db validate orphaned

# 出力例
Orphaned Scheduled Posts: 0
Unused Categories: 2
  ID: 106, Name: 本番環境構築
  ID: 66, Name: フロントエンド

Unused Hashtags: 1
  ID: 34, Name: #TEST

Total issues found: 3

→ tmpスクリプトがSkillの本体機能に昇格

これで、次回から「孤立投稿を検証して」と依頼すると、tmpスクリプトを生成せず、直接Skill機能が実行されるようになりました。

事例2: 段階的な拡張プロセス

tmp観察を続けることで、自然に機能が拡張されていきました：

Phase 1（初期実装）: 基本CRUDのみ

• list, get, create, update, delete

tmp観察（1週間）:

• カテゴリ・ハッシュタグでのフィルタ要求が頻出
• 統計情報の要求も多い

Phase 2（拡張）: 複雑なクエリ追加

• --category, --hashtag フィルタオプション
• stats コマンド（集計）
• 中間テーブル操作（add-categories, add-hashtags）

tmp観察（さらに1週間）:

• merge系スクリプトが頻出
• データクリーニングの需要が明確に

Phase 3（さらに拡張）: データクリーニング機能

• find-duplicates コマンド
• merge --dry-run コマンド
• validate orphaned コマンド

→ tmpの観察が、段階的な機能拡張を自然に導いた

段階的な開発により: 短期間でデータベース管理システムが完成（実測例として15時間程度）

UIなしでビジネスロジックを整備できる理由

従来のUI先行開発 vs ロジックファースト検証

従来の方法:

要件書「重複カテゴリをマージできること」
  ↓
UI設計: ボタン、ダイアログ、進捗表示
  ↓
フロントエンド実装（React等）
  ↓
実際に使ってみる
  ↓
「あれ、重複の定義が曖昧だった」
「マージ条件が足りない」
  ↓
仕様変更 → UI再設計 → 再実装 ← 高コスト！

問題: ビジネスロジックが固まっていないのにUIを作っている

ロジックファースト検証:

CLIツール（基本操作のみ）
  ↓
人間が自然言語で依頼「重複カテゴリをマージして」
  ↓
Claude Codeがtmp/merge_duplicate_categories.py を生成
  ↓
tmpスクリプトに「重複の定義」「マージ戦略」が可視化される
  ↓
頻出パターンを観察（週次レビュー）
  ↓
ビジネスロジック抽出
  ↓
CLIに機能追加（`db categories find-duplicates`）
  ↓
ビジネスロジック完成（UIはまだない）
  ↓
必要になったらUI実装（ロジック確定済み、手戻りなし）

利点:

• ✅ ビジネスロジックを先に固められる
• ✅ UIなしで検証・改善できる
• ✅ 小さく試行錯誤できる
• ✅ UI設計時には要件が確定している → 手戻りゼロ

Claude Codeが「操作UI」として機能

重要な洞察: UIがないのではなく、Claude Codeが人間の操作UIになっている

従来のUI:
  人間 → Webフロントエンド → バックエンド → データベース

ロジックファースト:
  人間 → Claude Code（自然言語UI） → CLIツール → データベース

なぜ「UI不要」が成立するのか – 概念的理解

従来のUIの役割を分解すると：

1. 視覚的フィードバック （操作結果の確認）

• 従来: ボタンを押して画面で結果を見る
• tmp駆動: tmpスクリプトを実行して、実行可能なフィードバックを得る
• 本質: UIは「見るため」ではなく「確認するため」→ 実行結果で代替可能

2. 操作の抽象化 （複雑なコマンドを簡単に）

• 従来: ボタン一つで複雑な処理を実行
• tmp駆動: 自然言語で依頼すると、Claude Codeがtmpスクリプト生成
• 本質: UIは「操作を簡単にする」→ 自然言語で代替可能

3. 操作フローのガイド （次に何をすべきか示す）

• 従来: 画面遷移やメニューで操作を誘導
• tmp駆動: tmpスクリプトの頻出パターンから次の機能を発見
• 本質: UIは「発見を助ける」→ tmp観察で代替可能

つまり、UIの役割は全て代替可能です。

Claude CodeがUIとして優れている点:

• ✅ 自然言語で操作できる（ボタン配置不要）
• ✅ 柔軟性が高い（固定画面レイアウトがない）
• ✅ 組み合わせ処理を即座に実行（カスタマイズ自在）
• ✅ tmpスクリプト生成で要件を可視化（暗黙知の顕在化）

これが、フロントエンド開発をスキップできた理由です。

UI不要が適している場面・適さない場面

適している場面:

• ✅ バックエンドロジック開発（データ処理、検証、変換）
• ✅ 自動化スクリプト（バッチ処理、CI/CD）
• ✅ インフラ管理（データベース操作、設定変更）
• ✅ 個人・小チーム利用（開発者のみが使う）

UIが必要な場面:

• ❌ ビジュアルデザインが重要（UI/UX設計が価値）
• ❌ 非エンジニアユーザー向け（自然言語UIでは不十分）
• ❌ リアルタイム性が重要（グラフ、ダッシュボード）
• ❌ 規制要件（監査証跡、操作履歴の可視化）

移行パターン:

多くの場合、こうなります：

Phase 1: tmp駆動でロジック整備（UI不要）
Phase 2: ロジック確定後、必要ならUI実装

UI実装は、ロジックが固まってから。手戻りがゼロになります。

将来的なアプリ化の価値:

ビジネスロジック検証で確定した機能は、本当に人間が欲している機能として証明されています。この段階でアプリ化すれば：

• ✅ 要件が固まっている → UI設計が明確
• ✅ ビジネスルールが検証済み → 手戻りゼロ
• ✅ 実際の利用パターンが分かっている → 最適なUX設計が可能
• ✅ tmpスクリプトの頻度から優先機能が明確 → 無駄な機能を作らない

つまり、tmpで検証したロジックをアプリ化することで、本当に価値のある機能だけを提供できるんです。

tmpがビジネスロジック整備を可能にする仕組み

1. 人間の暗黙知を可視化
   → 「重複って何？」がtmpスクリプトに具体的な定義として現れる

2. 頻出パターンの発見
   → 同じスクリプトが5回生成 → これは必要な機能だ

3. ビジネスルールの検証
   → tmpスクリプトが実際に動く → ロジックが検証済み

4. UIなしで改善サイクル
   → tmp観察 → CLI拡張 → 再びtmp観察 → さらに拡張

この4つのステップが、UIなしでビジネスロジックを整備できる仕組みです。

まとめ

tmpの再定義

従来の認識:

• tmp/ = 一時的なゴミ
• 実行後は削除すべき

新しい理解:

• tmp/ = 人間の自然言語から生まれた純粋な要件
• ビジネスロジック整備の記録
• UI設計のヒント

tmpが実現する新しい開発フロー

従来:
  要件定義 → UI設計 → 実装 → 「仕様変更...」

ロジックファースト:
  CLI基本実装 → Skill定義 → tmp蓄積 → ビジネスロジック抽出 → CLI拡張
  → ロジック確定 → （必要なら）UI実装

革新的な点:

• ✅ UIなしでビジネスロジックを整備・検証できる
• ✅ tmpが要件定義のプロセス自体を変える
• ✅ 小さく試行錯誤しながらロジックを固められる
• ✅ UI設計は後回し（ロジック確定後）→ 無駄なし

前回の記事の「短時間完成」の本当の意味

前回の記事で語ったこと: フロントエンド開発をスキップして短時間で完成（事実）

本記事で明かしたこと: tmpがビジネスロジックを整備してくれた（理由）

なぜスキップできたのか:

• ✅ tmpがビジネスロジックを整備してくれた（自然言語から要件が生まれる）
• ✅ Claude Codeが人間の操作UIとして機能（Webフロントエンドが不要）
• ✅ UIは後回しにできる（ロジック確定後 → 手戻りなし）

開発プロセスの比較:

従来: 要件定義（抽象的）→ UI設計 → フロント実装 → バックエンド
      合計: 16-24日（128-192時間、一般的な工数見積として参考）

ロジックファースト: CLI基本実装 → Skill定義 → tmp蓄積・観察 → CLI拡張
                  合計: 数時間〜1日（実測例として参考）

削減効果: UI開発をスキップすることで大幅削減

時間内訳の詳細:

削減の本質: AIツールによる速度向上ではなく、UI開発というアプローチ自体を変えたことです。

核心的な発見

tmpスクリプトを観察することで：

1. 人間の暗黙知が可視化される
   • 「重複って何？」→ 類似度90%以上という具体的な定義
2. 頻出パターンから優先順位が見える
   • 5回生成 → 必要な機能
   • 1回生成 → 稀なケース
3. ビジネスルールが検証される
   • tmpスクリプトが実際に動く → 検証済み
4. UIなしで改善サイクルが回る
   • tmp観察 → CLI拡張 → tmp観察 → さらに拡張

関連する開発手法との違い

ロジックファースト検証は、既存の開発手法と何が違うのでしょうか？

vs. 従来の仕様駆動開発

本質的な違い: ドキュメントは「こうあるべき」、tmpスクリプトは「実際にこう使った」

vs. AI駆動開発

本質的な違い: AI駆動開発は「AIを使う」手法、ロジックファースト検証は「自然言語を要件にする」手法（ツール非依存）

vs. TDD（テスト駆動開発）

本質的な違い: TDDは「正しさ」を駆動、ロジックファースト検証は「要件そのもの」を駆動

ロジックファースト検証の位置づけ

要件発見フェーズ: ロジックファースト検証 ← 本手法の焦点
      ↓
実装フェーズ: TDD, AI駆動開発など
      ↓
運用フェーズ: DevOps, SRE

ロジックファースト検証は、要件が固まっていない初期段階に特に有効です。要件が明確になれば、TDDやAI駆動開発と組み合わせて使えます。

実践方法について

tmpの具体的な観察方法、ビジネスロジックの抽出手順、環境セットアップなどの詳細は、次回の記事「Claude Code一時ファイルからSkillsへ：ビジネスロジック抽出の実践ガイド」で解説します。

次回の記事では：

• tmpディレクトリのプロジェクト内設定方法
• 週次レビューの実践
• ビジネスロジック抽出の具体例（コード付き）
• 環境セットアップ（Python/uv, TypeScript）
• tmpからCLI機能への昇格プロセス

を扱う予定です。

皆さんも、tmpスクリプトを削除せず、観察してみてください。そこには、あなたの本当の要件が隠れています。

参考リンク

公式ドキュメント

• Claude Code 公式ドキュメント
• Claude Code Skills 公式ガイド
• Supabase 公式ドキュメント
• Python 公式ドキュメント – 型ヒント、subprocess等
• uv 公式ドキュメント

前提記事

• Claude Code: 公式MCPを補完するSkills設計パターン
  • 4層構造パターン（公式SDK → 自作Client → CLI → Skill）
  • UI開発工数の大幅削減
  • なぜフロントエンド開発をスキップできたか（表面的な説明）

関連ブログ

• Claude Code Skills 実装ガイド：ローカルツールをスムーズに統合する方法
  • Skillの実装方法（詳細）
  • Progressive Disclosure、トークン効率化
  • 本記事の基盤となるSkills実装
• HTMLでブログ記事を保存してる奴、全員Markdownにしろ。AIが読みにくいでしょうが！
  • blog-scraperの実装例（tmpから進化したツール）
  • トークン削減の実測データ
• AIチャットで話すだけ!X予約投稿を完全自動化するシステム構築術
  • X投稿管理システムの全体像
  • Azure Functions + Supabaseでの予約投稿自動化

次に読むべき記事

• Claude Code一時ファイルからSkillsへ：ビジネスロジック抽出の実践ガイド: tmpの観察方法、ビジネスロジック抽出の具体例、環境セットアップを詳解

次回の記事では、本記事で説明した概念を実際にどう実装するかを、コード例を交えて解説します。

質問や感想は、コメント欄でお待ちしております！