Claude Codeは「コーディング専用」じゃない：ビジネス文書の評価・レビューで真価を発揮する理由

AI
  1. はじめに：私が体験した「Claudeチャット版」の致命的な失敗
  2. 重要な発見：Claude Codeなら防げた（ただしCLI版限定）
  3. CLI版とWeb版、どちらを使うべきか？
    1. 結論：ビジネス文書の評価なら「CLI版」一択
  4. なぜWeb版は「ビジネス文書の評価」に向かないのか？
    1. 理由1：GitHubリポジトリが前提
    2. 理由2：クラウドサンドボックスで実行される
    3. 理由3：主にコーディングタスク向けに最適化
    4. 理由4：文書作成・議論には向かない
  5. なぜClaude Code（CLI版）なら失敗を防げたのか？
    1. 理由1：CLAUDE.mdを自動で読み込む
    2. 理由2：プロジェクトファイルを自動で理解しようとする設計
    3. 理由3：「デビルズアドボケート」のような抽象的な指示を具体化できる
  6. 実際の使い方：事業計画書を評価する場合（CLI版）
    1. Step 1: プロジェクト構造を作る
    2. Step 2: CLAUDE.mdを書く
    3. Step 3: Claude Code（CLI版）を起動
    4. Step 4: 評価を依頼
  7. 他のビジネスシーンへの応用
    1. 応用1：技術仕様書のレビュー
    2. 応用2：プレゼン資料の改善提案
    3. 応用3：契約書のチェック
    4. 応用4：市場調査レポートの評価
    5. 応用5：採用面接の評価基準作成
  8. CLI版 vs チャット版 vs Web版：使い分けの決定版
    1. チャット版が向いている場合
    2. CLI版が向いている場合
    3. Web版が向いている場合
  9. まとめ：ビジネス文書の評価なら「CLI版」一択
    1. なぜCLI版が最適なのか？
    2. Web版がビジネス文書に向かない理由（再確認）
    3. 黄金ルール
  10. おわりに

はじめに：私が体験した「Claudeチャット版」の致命的な失敗

ある日、私は重要な事業計画書をClaude（チャット版）で評価してもらおうとしました。

私がやったこと：

  1. プロジェクトに6つのMarkdownファイルを添付（事業計画書、技術仕様書など）
  2. プロジェクトの「カスタム指示」で明確にルールを設定：
    • 「プロジェクトファイルを全て読んでから評価する」
    • 「全て調査して回答しろ」
    • 「裏を取れ」
    • 「ソースのURLを付けろ」
    • 「存在しない情報について言及しない」
  3. 「デビルズアドボケートモードで事業計画書を評価して」と依頼

結果：

  • ❌ プロジェクトファイルを読まなかった
  • ❌ カスタム指示を完全に無視
  • ❌ 存在しないサービスを勝手に作り出して「このサービスには重大な欠点があります」と批判
  • ❌ 調査もせず、根拠のない指摘を列挙

私の疑問： 「なぜプロジェクト設定を無視するのか？なぜファイルを読まないのか？」

重要な発見：Claude Codeなら防げた（ただしCLI版限定）

その後、Claudeに「なぜこんなことが起きるのか」を聞いたところ、こう答えました：

「Claude Code（CLI版）を使っていたら、この失敗を防げた可能性が高い」

しかし、ここで重要な注意点があります：

⚠️ Web版のClaude Codeは、ビジネス文書の評価には向いていません。

CLI版とWeb版、どちらを使うべきか？

結論：ビジネス文書の評価なら「CLI版」一択

用途CLI版Web版理由
事業計画書の評価✅ 最適❌ 不向きWeb版はコーディング特化
技術仕様書のレビュー✅ 最適❌ 不向き議論しながら詰める必要がある
市場分析の妥当性チェック✅ 最適❌ 不向き対話的な確認が必要
財務計画の精査✅ 最適❌ 不向き細かい数値の確認が必要
プレゼン資料の改善提案✅ 最適❌ 不向き議論しながら改善したい

なぜWeb版は「ビジネス文書の評価」に向かないのか？

理由1：GitHubリポジトリが前提

Web版の制約：

  • GitHubリポジトリに接続することが前提
  • ビジネス文書をGitHubに上げるのは現実的でない（機密情報の問題）
  • Word、Excel、PowerPointなどは直接扱えない

CLI版の利点：

  • ローカルの任意のディレクトリで動作
  • Markdown、Word、Excel、PowerPointなど、様々な形式を扱える
  • 機密情報をローカルに保ったまま作業可能

理由2：クラウドサンドボックスで実行される

Web版の制約：

  • Anthropicが管理するクラウド環境で実行
  • ビジネス文書をクラウドにアップロードする必要がある
  • セキュリティ・コンプライアンス上の懸念

CLI版の利点：

  • 完全にローカルで実行
  • 機密情報が外部に出ない
  • 企業のセキュリティポリシーに準拠しやすい

理由3：主にコーディングタスク向けに最適化

Web版の設計思想：

  • バグ修正のバックログ処理
  • 定型的なリファクタリング
  • 複数タスクの並列実行

→ 「作業を丸投げして結果だけ確認」する用途

ビジネス文書評価の特性：

  • 対話しながら詰める
  • 細かい確認を繰り返す
  • 議論しながら改善する

→ Web版の設計思想と合わない

理由4：文書作成・議論には向かない

Web版の制約：

  • 公式ドキュメントでも「CLI版やIDEプラグインを入れ替えるものではなく、補完する位置付け」と明記
  • 長文の文書作成、ビジネス分析、議論しながら詰める作業には不向き

CLI版の利点：

  • 対話的な作業に最適
  • ファイルを直接編集しながら議論できる
  • PDFやWordファイルも作成可能

出典: 安全なクラウド上の「Claude Code」をブラウザから利用できる「Claude Code on the web」が登場

なぜClaude Code（CLI版）なら失敗を防げたのか？

理由1：CLAUDE.mdを自動で読み込む

Claude Code（CLI版）は、プロジェクトルートに置いたCLAUDE.mdファイルを起動時に必ず読み込みます。

チャット版の問題：

  • プロジェクトのカスタム指示は「理論上は読まれる」が、実際には優先度が低い
  • 会話の途中で無視される場合がある
  • 抽象的な指示（「デビルズアドボケート」など）は誤解される

Claude Code（CLI版）の解決策：

# CLAUDE.md（プロジェクトルートに配置）

## 評価の必須条件
1. **プロジェクトファイルを全て読んでから回答する**
   - 事業計画書.md
   - 技術仕様書.md
   - 市場分析.md
   - 財務計画.md
   - （以下省略）

2. **全ての指摘にソースURLを付ける**（web_search使用時）
3. **推測の場合は「（推測）」と明記する**
4. **存在しない情報について言及しない**

## 評価の視点
1. 市場分析の妥当性
   - 市場規模の根拠は明確か？
   - 競合分析は十分か？
2. 収益計画の実現可能性
   - 売上予測は現実的か？
   - コスト構造は妥当か？
3. リスク要因の見落とし
   - 想定されるリスクは全て列挙されているか？

このファイルを置いておけば、Claude Code（CLI版）は毎回必ず読み込んで、ルールに従って評価します。

出典: Claude Code メモリ運用の教科書

理由2：プロジェクトファイルを自動で理解しようとする設計

Claude Code（CLI版）は、プロジェクト全体を理解することを前提に設計されています。

チャット版の問題：

  • ファイルが多い（6つ以上）と読まない場合がある
  • 会話の冒頭で「これらのファイルを読んでから回答して」と明示しない限り、読まない

Claude Code（CLI版）の解決策：

  • プロジェクトルートで起動すると、自動的にファイル構造を把握
  • CLAUDE.mdに「これらのファイルを読め」と書いておけば、必ず読む
  • サブディレクトリのCLAUDE.mdも自動で読み込む（Lazy-Load）

理由3：「デビルズアドボケート」のような抽象的な指示を具体化できる

チャット版の問題： 「デビルズアドボケートモードで評価して」という抽象的な指示は、AIにとって曖昧です。

Claude Code（CLI版）の解決策： CLAUDE.mdに、具体的な評価項目を列挙しておけば、誤解の余地がありません。

## 評価の視点（デビルズアドボケート）

### 1. 市場分析の妥当性
- 市場規模は信頼できるソースに基づいているか？
- 競合との差別化は明確か？
- ターゲット顧客は具体的か？
- **指摘する場合は、必ず代替案を提示する**

### 2. 収益計画の実現可能性
- 売上予測は楽観的すぎないか？
- コスト構造は現実的か？
- 利益率は業界平均と比較してどうか？
- **指摘する場合は、具体的な数値の根拠を示す**

### 3. リスク要因の見落とし
- 市場リスクは十分に考慮されているか？
- 技術的リスクは？
- 競合の反応は？
- **指摘する場合は、対策案も提示する**

## 出力形式
### 問題点
- ○○が不足している（根拠：ソースURL）

### 改善案
- ○○すべき（理由：△△）

実際の使い方：事業計画書を評価する場合（CLI版）

Step 1: プロジェクト構造を作る

project-root/
├── CLAUDE.md           ← ルールを定義
├── 事業計画書.md
├── 技術仕様書.md
├── 市場分析.md
├── 財務計画.md
└── その他の資料/

Step 2: CLAUDE.mdを書く

# プロジェクトルール

## 評価の必須条件
1. **プロジェクトファイルを全て読んでから回答する**
   - 事業計画書.md
   - 技術仕様書.md
   - 市場分析.md
   - 財務計画.md

2. **全ての指摘にソースURLを付ける**（web_search使用時）
3. **推測の場合は「（推測）」と明記する**
4. **存在しない情報について言及しない**
5. **指摘する場合は、必ず改善案も提示する**

## 評価の視点
1. 市場分析の妥当性
   - 市場規模の根拠は明確か？
   - 競合分析は十分か？
   - ターゲット顧客は具体的か？

2. 収益計画の実現可能性
   - 売上予測は現実的か？
   - コスト構造は妥当か？
   - 利益率は業界平均と比較してどうか？

3. リスク要因の見落とし
   - 想定されるリスクは全て列挙されているか？
   - 対策は具体的か？

## 出力形式
各視点ごとに以下の形式で評価してください：

### 1. 市場分析の妥当性
#### 問題点
- ○○が不足している（根拠：ソースURL）

#### 改善案
- ○○すべき（理由：△△）

Step 3: Claude Code（CLI版）を起動

# プロジェクトルートで起動
cd /path/to/project-root
claude

# または
code .  # VS Codeで開いてから、Claude Code拡張を使う

Step 4: 評価を依頼

【プロンプト例】
CLAUDE.mdに記載されたルールに従って、
事業計画書を評価してください。

全てのファイルを読んでから評価を開始してください。

結果：

  • ✅ CLAUDE.mdを自動で読み込む
  • ✅ プロジェクトファイルを全て読む
  • ✅ ルールに従って評価
  • ✅ 存在しない情報については言及しない
  • ✅ 改善案も提示

他のビジネスシーンへの応用

応用1：技術仕様書のレビュー

CLAUDE.mdの例：

## 評価の視点
1. 技術選定の妥当性
   - 選定理由は明確か？
   - 他の選択肢との比較は？
   - 最新の技術動向を反映しているか？

2. セキュリティ対策
   - 一般的な脆弱性への対策は？
   - 認証・認可の仕組みは適切か？
   - データ暗号化は考慮されているか？

3. スケーラビリティ
   - 負荷増加時の対応は？
   - ボトルネックになる箇所はないか？

応用2：プレゼン資料の改善提案

CLAUDE.mdの例：

## 評価の視点
1. ストーリーの流れ
   - 論理の流れは自然か？
   - 結論が明確か？
   - 聞き手の疑問に答えているか？

2. スライドのデザイン
   - 1スライド1メッセージか？
   - 文字が多すぎないか？
   - グラフ・図は効果的か？

3. データの根拠
   - 数値の出典は明記されているか？
   - グラフの軸は適切か？

応用3：契約書のチェック

CLAUDE.mdの例：

## 評価の視点
1. 契約条件の妥当性
   - 一方的に不利な条項はないか？
   - 解約条件は明確か？
   - 損害賠償の範囲は適切か？

2. 曖昧な表現のチェック
   - 解釈が分かれる表現はないか？
   - 具体的な数値・期限が明記されているか？

3. リスク要因
   - 想定されるトラブルへの対策は？
   - 紛争解決の方法は明記されているか？

応用4：市場調査レポートの評価

CLAUDE.mdの例：

## 評価の視点
1. データの信頼性
   - 出典は信頼できるか？
   - サンプル数は十分か？
   - 調査時期は適切か？

2. 分析の妥当性
   - 結論は データに基づいているか？
   - 他の解釈の可能性は？
   - バイアスはないか？

3. 提言の実現可能性
   - 提言は具体的か？
   - 実行可能か？
   - コスト・期間は現実的か？

応用5：採用面接の評価基準作成

CLAUDE.mdの例：

## 評価の視点
1. 評価基準の明確性
   - 各項目の評価基準は具体的か？
   - 主観的な評価になっていないか？
   - スコアリングの基準は明確か？

2. 公平性
   - バイアスがかかる項目はないか？
   - 多様性を考慮しているか？
   - 法的な問題はないか？

3. 実効性
   - 短時間で評価可能か？
   - 面接官による差が出にくいか？

CLI版 vs チャット版 vs Web版：使い分けの決定版

チャット版が向いている場合

✅ カジュアルな相談・雑談

  • 「このアイデアどう思う？」
  • 「こんな感じの文章を書いて」
  • ファイルが1〜2個で、ルールも単純

❌ 向かない場合

  • プロジェクトファイルが多い（6個以上）
  • 厳密なルールに従ってほしい
  • 「デビルズアドボケート」などの抽象的な指示

CLI版が向いている場合

✅ ビジネス文書の評価・レビュー

  • 事業計画書、技術仕様書、契約書など
  • 厳密なルール（CLAUDE.md）に従ってほしい
  • 対話しながら詰めたい
  • 機密情報を扱う

✅ コードレビュー、デバッグ

  • 細かい確認を繰り返す
  • ローカル環境でのテスト

❌ 向かない場合

  • 複数タスクを並行実行したい
  • 環境構築が面倒

Web版が向いている場合

✅ コーディングの丸投げタスク

  • バグ修正のバックログ処理
  • 定型的なリファクタリング
  • 複数タスクの並列実行

❌ 向かない場合

  • ビジネス文書の評価・レビュー
  • 機密情報を扱う
  • 対話しながら詰めたい
  • GitHubを使わない

まとめ：ビジネス文書の評価なら「CLI版」一択

なぜCLI版が最適なのか？

  1. CLAUDE.mdを自動で読み込む
    • ルールを毎回守ってくれる
    • 抽象的な指示を具体化できる
  2. プロジェクトファイルを全て読む
    • 6つ以上のファイルでも対応
    • サブディレクトリのCLAUDE.mdも読む
  3. ローカルで完結
    • 機密情報が外部に出ない
    • セキュリティ・コンプライアンスに準拠
  4. 対話的な作業に最適
    • 議論しながら詰められる
    • 細かい確認を繰り返せる
  5. 様々な形式に対応
    • Markdown、Word、Excel、PowerPointなど

Web版がビジネス文書に向かない理由（再確認）

  1. GitHubリポジトリが前提
    • ビジネス文書をGitHubに上げるのは現実的でない
  2. クラウドサンドボックスで実行
    • 機密情報の取り扱いに懸念
  3. コーディングタスク向けに最適化
    • 「丸投げ」用途に特化
    • 対話的な作業には不向き
  4. 文書作成・議論には向かない
    • 公式ドキュメントでも「補完する位置付け」と明記

黄金ルール

ビジネス文書の評価・レビューは、必ずCLI版を使う。

  • 事業計画書、技術仕様書、契約書、プレゼン資料…
  • 厳密なルールに従ってほしい場合
  • 機密情報を扱う場合
  • 対話しながら詰めたい場合

→ CLI版 + CLAUDE.mdが最強

おわりに

私が体験した「Claudeチャット版の失敗」は、Claude Code（CLI版）+ CLAUDE.mdで完全に防げた可能性が高いです。

なぜなら：

  1. CLAUDE.mdを自動で読み込むから、ルールを守る
  2. プロジェクトファイルを全て読んでから評価するから、見落としがない
  3. 抽象的な指示を具体化できるから、誤解が生まれない
  4. 存在しない情報について言及しないから、ハルシネーションを防げる

重要なのは：

  • Web版は「コーディングの丸投げ」専用
  • ビジネス文書の評価には、CLI版を使う

この使い分けを間違えると、私のような失敗を繰り返すことになります。

ぜひ、あなたのビジネスシーンでも、Claude Code（CLI版）+ CLAUDE.mdを活用してください。

執筆日: 2025年11月9日
最終更新: 2025年11月9日

出典：

コメント

タイトルとURLをコピーしました