Claude Code: 自身のLLM能力で直接生成する（APIより先に検討）

Extracted: 2026-02-11 Context: Claude Code（Maxプラン）でデータ生成・テキスト変換・構造化が必要な場面

Problem

Claude Codeが大量データの生成・変換タスクに直面すると、以下の思考パターンに陥りやすい:

• まず正規表現やヒューリスティクスでの機械的処理を試みる

• 品質が不十分だと判明すると「外部API（Anthropic SDK等）を使いましょう」と提案する

• 自分自身がLLMであり、セッション内で直接生成できることを見落とす

これにより:

• 不要なAPI設定・コスト（従量課金）の発生

• 正規表現の限界に無駄に時間を費やす

• ユーザーが「Maxプラン内でできるのでは？」と指摘するまで気づかない

Solution

データ生成・テキスト変換タスクでは、以下の優先順位で検討する:

判断フローチャート

タスク: 大量データの生成/変換/構造化 │ ├─ 機械的処理で十分か？（フォーマット変換、フィルタリング等） │ └─ YES → 正規表現/スクリプトで処理 │ ├─ LLMの理解力が必要か？（要約、再構成、品質判断等） │ └─ YES ─┐ │ │ │ ★ Step 1: まずClaude Code自身で数十件を試作する │ │ 品質基準を確立し、プロンプトパターンを検証 │ │ │ ├─ 個人プロジェクト / 1回限り / Maxプラン │ │ └─ そのままClaude Codeでバッチ処理して完走 │ │ │ └─ チーム共有 / 再実行が必要 / CI/CD組み込み │ └─ 検証済みプロンプトをAPIスクリプトに移植 │ （プロンプトがコードとして残り、誰でも再実行可能） │ └─ いきなりAPI呼び出しを提案しない

重要: 「まず自分で試す」フェーズを飛ばさない

APIスクリプト化が最終的に正しい場合でも、先にClaude Code自身で試作することで:

• 品質基準が具体的になる（手作りサンプルが増える）

• プロンプトパターンが検証済みの状態でスクリプトに移植できる

• 「個人で完走 or API化」の判断を実データに基づいて行える

バッチ処理の実践パターン

• ヘルパースクリプト: 入力データを読みやすいバッチファイルに分割

• 品質基準: 手作りサンプルを数件用意し、それを基準として全件に展開

• バッチサイズ: 20-30件/バッチが目安（コンテキストウィンドウとの兼ね合い）

• 検証: 生成後にバリデーションスクリプトで品質チェック

Example

悪い例（このセッションで実際に起きたこと）

User: 408問の構造化解説を生成したい Claude: 方針A: 正規表現改善（無料だが品質限界） ← まずこれを提案 方針B: Claude API呼び出し（$2-5） ← 次にこれを提案 方針C: ハイブリッド ← 折衷案

→ Claude Code自身での生成を選択肢に含めていなかった

良い例

User: 408問の構造化解説を生成したい Claude: 手作りサンプル3問が高品質 → これはClaude Code自身が生成したもの → Maxプラン内で同じことを408問に拡大するのが最も合理的 → バッチ処理（20問×21バッチ）で実行可能

When to Use

以下の条件が揃ったとき、このパターンを適用する:

• テキスト生成/変換/要約/構造化のタスク（正規表現では品質不足）

• ユーザーがMaxプラン（またはClaude Codeの利用に追加コストがかからない契約）

• バッチ処理可能（各項目が独立しており、1件ずつ処理できる）

• 品質基準が明確（手作りサンプルや期待出力の例がある）

個人 vs チーム: 使い分け

Claude Code 直接生成 API スクリプト

対象 個人・1回限り・プロトタイプ チーム・再実行可能・プロダクション

再現性 低い（会話の流れに依存） 高い（プロンプトがコードとして残る）

コスト Maxプラン定額内 従量課金

自動化 不可（手動バッチ） CI/CD に組み込み可能

ただしどちらの場合も、最初にClaude Codeで試作するフェーズを挟む。

Anti-patterns

• 単純なフォーマット変換（JSON→CSV等）にLLMを使う → スクリプトで十分

• 1万件以上の大量データ → コンテキストウィンドウの限界でAPI呼び出しのほうが効率的

• リアルタイム処理が必要 → APIのほうが適切

• 品質基準なしでいきなりAPI化 → まずClaude Codeで試作し、品質基準とプロンプトを確立すべき