【2026年最新】VC投資DDをClaude Codeで効率化する実装ガイド

私はもともとアクセラレータでメンタリングをやっていた時期があり、その流れで何度か独立系VCのIC(Investment Committee)向け資料レビューを手伝ったことがある。シードからシリーズBくらいまで、案件にもよるが、IC1本あたりアナリスト側で必ず潰すべき論点が20〜30個あって、しかもそれが「財務」「市場」「競合」「チーム」のあいだを縦横無尽に行き来する。「市場は伸びている、しかし競合のARR成長率はうちの投資先候補の3倍、ただし創業者の前職評価は高く、財務面では足元のバーンが計画より20%重い」みたいな話を、IC前夜に1枚紙に圧縮するのが地獄だった。

当時はGoogleドキュメントとExcelとSlackを行き来して、徹夜で資料を組み直して、本番のICで「で、結局なんで投資すべきなんだっけ?」と1分で詰められて崩壊する、ということを何回もやらかしている。あの体験があるから、Claude Codeが出てきたときに最初に試したのは「コーディング」ではなく「IC資料のドラフト」だった。結論から言うと、Claude CodeはDDの結論を出すのは苦手だが、DDの論点を構造化するのは異常に得意で、ここに気づくと業務の体感が変わる。

本記事は、その「論点構造化マシン」としてのClaude Code活用を、フレームワークとプロンプトに分解して提示する。なお、この記事で扱うのはあくまで「想定シナリオ」であり、特定の投資案件や個別のファンドの実例ではない。投資先固有の情報は一切扱っておらず、登場する数字も汎用的なDDで使うレンジ感を例示しているに過ぎない。

1. なぜVCのDD業務がClaude Codeと相性が良いのか

そもそもVCのデューデリジェンスというのは、上場企業のM&A DDと違って「情報がスカスカ」なのが特徴だ。シードならピッチデック20枚と創業者のLinkedInと、頑張ってもKPIスプレッドシート1枚しか出てこない。シリーズB以降になっても、開示資料の網羅性は上場会社の有報とは比較にならない。だからこそ、限られた一次情報を、業界レポートや競合データや過去の類似案件と突き合わせる作業が分析の中核になる。

この「突き合わせる作業」が、Claude Codeの本質的に強い領域とぴったり噛み合う。Claudeはコードベースを横断して関連箇所を引っ張り出すのが得意なエージェントだが、これを「DDフォルダ」という疑似コードベースに置き換えると、ピッチデック・KPIシート・公開財務・競合分析・市場レポートを縦横に参照する一次ドラフト生成エンジンになる。Anthropic公式のClaude Codeドキュメントでも、「コードに限らない長文ドキュメント群へのナビゲーション」がエージェントモードの主要ユースケースとして整理されている(参考: Claude Docs – Claude Code overview)。

1-1. 投資業務でAIに任せていい範囲・任せてはいけない範囲

ここは強調しておきたいのだが、DDをAIに「丸投げ」する話ではない。投資判断は、最終的にはGP/パートナーの責任のもと、投資委員会で行う。Claudeが出すアウトプットは、あくまで「論点リストのドラフト」「事実関係の一次整理」「気になる矛盾の指摘」までだ。経済産業省「価値協創ガイダンス」やCFA Instituteの倫理規定でも繰り返し言及されているとおり、投資の意思決定責任は人間が引き受ける、というのが大前提になる。

使いどころとしては、私の感覚では以下のように整理している。

• 任せていい: ピッチデックや有報からの数字抽出、業界レポートと自社ノートの照合、論点リストのドラフト生成、IC資料の骨子作成、競合データの整形、用語集や略語集の作成
• レビュー付きで任せる: 市場規模の感応度分析、競合マッピングのスコアリング、財務モデルのチェック、創業者バックグラウンドのリサーチサマリ
• 任せてはいけない: 投資判断そのもの、バリュエーションの最終決定、タームシートの文言確定、リファレンスチェックの実施(対人)、IC内での議論と最終意思決定

1-2. 「DDの時間が短くなる」と「DDの質が上がる」を混同しない

VCの現場では、Claude Code導入の効果を「IC前夜の徹夜が減った」「アナリストの残業が減った」という時間軸で語ることが多い。これは事実なのだが、私はここに警鐘を鳴らしたい。時間が短くなることと、DDの質が上がることは、相関はするが同一ではない。むしろ、短くなった時間で何をするかで、ファンドの分析品質は二極化する。

悪いパターンは「短くなった時間で案件数を増やす」だ。アナリスト1人あたりが回せる案件数を倍に増やせば、ファンドのディールフロー処理能力は上がる。しかし、1案件あたりの深掘りの厚みは確実に落ちる。Claudeが出したドラフトを「ほぼそのまま」ICに持ち込むことが日常になり、誰も一次資料に当たらなくなる。これは数年単位で見ると、投資パフォーマンスを大きく毀損する。

良いパターンは「短くなった時間で、創業者との会話と一次資料の検証に時間を回す」だ。Claudeが論点の骨子を整理してくれた状態で、アナリストは創業者へのフォローアップインタビュー、顧客リファレンス、独立した業界専門家へのヒアリングに時間を割く。Claudeはあくまでデスクワークを巻き取る装置として位置づけ、人間しかできない一次情報収集に投資する。この方向で運用できれば、DDの所要時間と質を同時に改善できる。

導入時のKPI設計でも、「DD所要時間 X%削減」を単独で追ってはいけない。「一次資料への接触回数」「創業者との面談時間」「独立リファレンス取得件数」など、人間がやるべき活動の量も同時にモニタリングする。これがないと、効率化が劣化に転ぶ。

2. DDの4軸×3層スコアリングマトリクスを定義する

Claude Codeを業務に組み込む前に、まずDDの構造を「マトリクス」に落としておく必要がある。これがないと、Claudeは出力をどこに揃えるべきか分からず、毎回違うフォーマットの「中身は同じ」レポートを延々と作ることになる。

私が使っている標準フレームは4軸×3層の12マスだ。4軸は財務(Financial)・市場(Market)・競合(Competitive)・チーム(Team)。3層は事実抽出(Facts)・相互整合(Cross-check)・論点提示(Open Questions)。これを表にすると、案件ごとに「どの12マスがどれくらい埋まっているか」が可視化できる。

軸 \ 層	Facts(事実抽出)	Cross-check(相互整合)	Open Questions(論点)
財務	ARR/MRR/Gross Margin/Burn/Runway	ピッチデック vs 月次P/L vs 銀行残高	単位経済性は持続するか、いつ黒字化か
市場	TAM/SAM/SOM、CAGR、規制動向	創業者主張 vs 公開レポート vs 一次データ	TAM根拠の感応度、規制リスクの濃淡
競合	主要競合の調達額・ARR・従業員数	プロダクト機能 vs 価格 vs 顧客評価	真の競合は誰か、優位性の維持可能性
チーム	経歴・前職実績・株主構成	LinkedIn vs ピッチ自己紹介 vs 公開記事	CXO層は揃うか、リテンションリスク

この12マスを「Claudeに先に教える」のがコツだ。プロジェクトディレクトリ直下に DD_FRAMEWORK.md として置いておくと、後続のすべてのプロンプトでClaudeが暗黙にこの構造に揃えてくれる。

2-1. スコアリングルールの設計

マトリクスの12マスを、それぞれ4段階(Strong/Acceptable/Weak/Unknown)で評価する。私は数値スコアではなくラベルにしている。理由は2つあって、(1) 数字にすると合計値で議論される事故が起きる(平均3.4だから可、みたいな粗い意思決定になる)、(2) 「Unknown」を明示的に区別したいから。Unknownはレッドフラグではなく「これからDDで埋めるべきマス」というアクションリストになるので、ScoreではなくStatusとして扱う。

このルール設計をClaudeに渡すときも、定義をはっきり明文化する。「Strong=複数の独立した一次情報源で確認済み、Acceptable=単一の信頼できる情報源で確認、Weak=情報源が間接的・古い、Unknown=確認手段未着手」のように、判定基準そのものをドキュメント化してプロジェクトに置いておく。

2-2. ステージ別の重み付けを変える

4軸×3層のマトリクスは共通の骨格だが、案件のステージによって「どの軸をどれだけ厚く見るか」は当然変わる。プレシード〜シードはチームと市場が中心、シリーズA以降は財務とトラクションの比重が増し、シリーズB以降は競合とユニットエコノミクスが本丸になる。

これをマトリクスに反映するなら、「軸ごとの重み」を案件のステージで切り替える。私が使っている目安は以下のとおりだ。

ステージ	財務	市場	競合	チーム
プレシード/シード	15%	35%	15%	35%
シリーズA	25%	25%	25%	25%
シリーズB以降	35%	20%	30%	15%
グロースエクイティ	40%	15%	35%	10%

あくまで目安だが、これをSCORING_RUBRIC.mdに明記しておくと、Claudeが案件のステージを認識した上でアウトプットの濃淡を調整してくれる。例えばシード案件のIC資料ドラフトでバーンレートの詳細議論に5割の紙面を割く、みたいな歪みを未然に防げる。

2-3. レッドフラグの分類とエスカレーション設計

DDで出てくる「レッドフラグ」も、機械的に分類しておくとClaudeのアウトプットの質が安定する。私が使っている分類は3層構造だ。

1. Show-stopper(投資見送り直結): 過去の不正、訴訟リスク、規制違反、創業者間の信頼関係崩壊。発見時点で即パートナーにエスカレーション。
2. Material concern(タームシート条件で対応): ガバナンス未整備、株主構成の偏り、KPIの一貫性欠如、未払い債務。タームシート設計やボードシート要求で対応する論点。
3. Watch item(投資後モニタリング項目): 単位経済性の改善余地、競合動向、特定顧客への売上集中。投資後の取締役会でフォロー。

Claudeにアウトプットさせるときも、「気になる点」と書かせるのではなく、必ずこの3分類のいずれかにラベルさせる。Show-stopperを見つけたらClaude側で「即エスカレーション推奨」と明示し、Material concernならタームシート対応案を1〜2個ドラフトする。ここまでテンプレ化すると、ICでの議論が「分類×対応案」のフレームに乗るので、感情的な議論にならずに済む。

3. Claude Codeのプロジェクトセットアップ

具体的なセットアップに入る。やることは大きく3つで、(1) ファンド共通のテンプレートディレクトリを作る、(2) 案件ごとのDDフォルダを切る、(3) CLAUDE.mdに運用ルールを書く、これだけだ。

3-1. ディレクトリ構成

~/vc-dd/
├── _templates/
│   ├── DD_FRAMEWORK.md         # 4×3マトリクス定義
│   ├── IC_MEMO_TEMPLATE.md     # 投資委員会用メモ雛形
│   ├── COMPETITOR_MAP.md       # 競合マッピング雛形
│   ├── FOUNDER_REFCHECK.md     # チーム評価チェックリスト
│   └── SCORING_RUBRIC.md       # スコアリング判定基準
├── _knowledge/
│   ├── market_reports/         # 業界レポートPDF
│   ├── past_ic_memos/          # 過去案件IC資料(匿名化済)
│   └── thesis/                 # ファンドの投資テーゼ
├── CLAUDE.md                   # 共通運用ルール
└── deals/
    └── 2026Q2-projectX/        # 案件ごとに切る
        ├── 01_pitchdeck/
        ├── 02_financials/
        ├── 03_market/
        ├── 04_competitor/
        ├── 05_team/
        ├── 99_drafts/          # Claudeが書くドラフト
        └── DEAL_NOTE.md        # 案件の現時点メモ

ポイントは_templates/と_knowledge/を案件横断で持つことだ。Claude Codeはプロジェクトのルート(~/vc-dd/)から起動すると、案件固有のファイルと、ファンド共通のフレームワーク・過去IC・投資テーゼをすべて視野に入れた状態で読み込んでくれる。これが「過去案件と比較してどう?」というICで頻出する質問への速度を劇的に上げる。

3-2. CLAUDE.mdの最小構成

プロジェクトルートに置くCLAUDE.mdは、エージェントに渡す「振る舞いガイド」だ。VC業務に特化させるなら、以下の要素を入れておく。

# VC DDプロジェクト 運用ルール

## 役割
あなたはVCアナリストの作業を補助するアシスタント。
最終的な投資判断は人間が行うので、あなたは
「事実の抽出」「相互整合チェック」「論点の構造化」までを担当する。

## 重要な前提
- 投資判断・バリュエーション決定・タームシートの確定はあなたの責任範囲外
- 不確実な情報は必ず「Unknown」「要確認」と明示する
- ピッチデックの主張をそのまま事実として転記しない。
  必ず「ピッチデック主張: X」「公開データ: Y」のように出所を分ける

## 出力フォーマット
- DD_FRAMEWORKの4軸×3層マトリクスに揃える
- スコアはSCORING_RUBRIC.mdの定義に従う(Strong/Acceptable/Weak/Unknown)
- 数値は出典(ファイル名+ページ番号)を必ず付ける
- 解釈・推測は「[分析者所見]」として本文と区別する

## 守秘
- このプロジェクト配下の情報を外部APIに送信する操作を提案しない
- 案件名・創業者名は伏字(ProjectX, Founder-A)で取り扱う前提

このCLAUDE.mdを書いておくと、案件ごとに毎回「あなたはVCアナリストの…」とプロンプトの冒頭に書く必要がなくなる。何より、複数人のチームで運用する場合に「振る舞いをコードレビューできる」のが大きい。

4. コピペで使えるDDプロンプト5本

ここからは実戦で使うプロンプトを5本紹介する。すべて、上記のディレクトリ構成とCLAUDE.mdがある前提で動く。Claude Codeをプロジェクトルートで起動し、案件フォルダに資料を配置してから実行する流れだ。

4-1. プロンプト1: ピッチデックの構造化抽出

ピッチデック(PDF)を1枚ずつ読ませて、DDフレームに沿った構造化データを吐かせる。シード〜シリーズBで一番最初にやる作業。

deals/2026Q2-projectX/01_pitchdeck/ にあるPDF全てを読み込み、
DD_FRAMEWORK.mdの4軸(財務/市場/競合/チーム)に従って事実を抽出してください。

出力は以下の形式で deals/2026Q2-projectX/99_drafts/01_deck_facts.md に書き出す:

# ピッチデック事実抽出

## 財務(Facts層)
- ARR: [数値] (出典: deck p.[N], 主張ベース)
- 成長率: [数値] (出典: deck p.[N])
- バーン: ...

## 市場(Facts層)
- TAM: [数値] (出典: deck p.[N], 引用元レポート名)
- SAM: ...

## 競合(Facts層)
- 主要競合: [社名リスト] (出典: deck p.[N])

## チーム(Facts層)
- CEO: [氏名] [前職] (出典: deck p.[N])

注意:
- ピッチデックは創業者の主張なので「事実」ではなく「主張」として扱う
- 数字には必ず出典のページ番号を付ける
- 推測・解釈は[分析者所見]として明示的にラベルする
- TAM/SAMの引用元レポート名は省略せず必ず記載

これで 01_deck_facts.md が生成される。重要なのは、Claudeに「主張」と「事実」を明示的に分けさせている点だ。デック上のARR成長率は創業者の主張であって監査済みの事実ではない、という当たり前を、機械的に守らせる。

4-2. プロンプト2: 市場規模(TAM/SAM/SOM)の感応度分析

ピッチデックのTAMはほぼ確実に膨らんでいる。これに対して、別の独立ソース(業界レポート、政府統計、Statista的データ)から再構成したTAMを並べて、感応度を見るのが定番だ。

deals/2026Q2-projectX/03_market/ にある業界レポートPDFと、
99_drafts/01_deck_facts.md のTAM/SAM/SOM主張を突き合わせてください。

タスク:
1. ピッチデックのTAM/SAM/SOM算出ロジックを抽出
2. _knowledge/market_reports/ と 03_market/ にあるレポートから、
   独立して算出できるTAMの上限・下限ケースを2-3パターン作る
3. 算出根拠の感応度パラメータ(価格×顧客数×浸透率)を1つずつ動かし、
   TAMがどのレンジで動くかをまとめる

出力は 99_drafts/02_market_sensitivity.md に書く。形式:

# 市場規模 感応度分析

## ピッチデック主張(Base)
- TAM: [数値], 算出: 価格X × 顧客Y × 浸透率Z
- 出典: deck p.[N]

## 独立算出ケース
### ケースA: 保守的(Statista [年版])
- TAM: [数値]
- 算出: ...
- 出典: _knowledge/market_reports/[ファイル名] p.[N]

### ケースB: 楽観的(矢野経済研究所 [年版])
- TAM: [数値]

## 感応度マトリクス
| パラメータ | -20% | Base | +20% |
| 価格 | ... | ... | ... |
| 顧客数 | ... | ... | ... |
| 浸透率 | ... | ... | ... |

## [分析者所見] Open Questions
- ピッチデック主張と独立算出ケースの乖離原因(要IC論点)
- 浸透率の前提が現実的かをチェックする方法
- 規制変更でTAMがブレるシナリオ

感応度分析を機械的にやると、創業者主張の「都合のいいTAM」と独立算出ケースの差分が明確になる。IC席上で「TAMがピッチの2倍盛られている」と発見するより、事前に資料として並んでいる方が遥かに健全だ。

4-3. プロンプト3: 競合マッピングとスコアリング

競合マッピングは「散布図を作る作業」ではなく「比較軸を選ぶ作業」だ。Claudeに比較軸の候補を出させて、自分が重要だと思う軸を選んでから定量を埋めていく。

deals/2026Q2-projectX/04_competitor/ にある競合情報(Crunchbase的データ、
LinkedIn、各社プレスリリース、自社ノート)から、競合マッピングをドラフトしてください。

タスク:
1. ピッチデックで創業者が挙げた競合と、独立に発見した競合を区別
2. 比較軸の候補を10個ほど提案(プロダクト機能/価格/調達額/顧客規模/従業員数/
   創業時期/地域/ターゲットセグメント/技術スタック/Go-to-Market戦略 等)
3. 主要な比較軸3-4個を選んで、競合7-8社のマトリクスを埋める
4. 各社の「真の競合度」をHigh/Medium/Lowでラベル(同じ顧客を取り合うか)

出力は 99_drafts/03_competitor_map.md に書く。

注意:
- 公開情報のみを使う(LinkedInのスクレイピング等は提案しない)
- 数値が古い場合は「[2024年X月時点]」と明示
- 自社主張ベースの情報は「[主張]」とラベル
- 「真の競合度」の判定根拠を1行ずつ書く

このプロンプトでよくあるアウトプットの罠は、Claudeが「比較軸として技術スタック」を入れたがる点だ。投資判断において技術スタックそのものはほぼ意味がない。私は「比較軸として優先するのは、顧客の購買意思決定に直接影響するもの(価格・機能の充実度・実績顧客の業界)」とCLAUDE.mdに追記して防いでいる。

4-4. プロンプト4: チーム評価とリファレンスチェック準備

チーム評価は対人取材が本丸だが、その前に「何を聞くべきか」を準備する作業が大事だ。Claudeに既存情報から論点を抽出させて、リファレンスチェックの質問票を作らせる。

deals/2026Q2-projectX/05_team/ にあるLinkedInスクリーンショット、
過去インタビュー記事、ピッチデックp.[創業者紹介ページ] から、
チーム評価のドラフトと、リファレンスチェック準備資料を作ってください。

タスク:
1. 各創業者・主要メンバーの経歴を時系列で整理
2. ピッチデックの自己紹介と、独立した公開情報の整合性をチェック
3. 「強み仮説」と「不安仮説」をそれぞれ3-5個ずつ抽出
4. リファレンスチェックで聞くべき質問を10-15問ドラフト
5. 質問は「事実確認(yes/noで返ってくる)」と「行動評価(具体エピソードを引き出す)」に分類

出力は 99_drafts/04_team_assessment.md に書く。

注意:
- 公開情報の解釈に留め、人格評価・断定は避ける
- 「不安仮説」は事実ではなく検証すべき仮説として明記
- 質問票は「これまでの○○における困難な意思決定の具体例」のように、
  STAR形式(Situation/Task/Action/Result)を引き出せる形にする
- 個人情報の取り扱いは公開情報の範囲内に限定

このアウトプットを持ってリファレンスチェックの電話に臨むと、聞き漏らしが減る。Claudeが洗い出した「不安仮説」は、検証されれば消える/されなければICで論点として残す、という二択でクリアに扱える。

4-5. プロンプト5: 投資委員会(IC)用メモのドラフト生成

4本のプロンプトで作った中間ドラフトを統合して、IC用メモのドラフトを書かせる。これがClaude Code活用の本丸だ。

deals/2026Q2-projectX/99_drafts/ にある4つの中間ドラフト
(01_deck_facts.md / 02_market_sensitivity.md /
 03_competitor_map.md / 04_team_assessment.md)を統合し、
_templates/IC_MEMO_TEMPLATE.md のフォーマットに従って、
投資委員会用メモのドラフトを書いてください。

セクション構成:
1. Executive Summary (200字以内・3行)
2. 投資テーゼ(_knowledge/thesis/ と整合するか)
3. ビジネス概要・トラクション
4. 市場機会(感応度マトリクス込み)
5. 競合環境(マッピング込み)
6. チーム評価(強み仮説・不安仮説)
7. 財務状況・バリュエーション論点
8. リスクファクター上位5つ
9. Open Questions for IC(議論してほしい論点5-7個)
10. 次のステップ(追加DDアイテム)

出力は deals/2026Q2-projectX/99_drafts/05_ic_memo_draft.md に。

注意:
- 「投資推奨/見送り」の結論は書かない(=これはIC席上での議論)
- 数値は必ず中間ドラフトの出典をたどれる形で記載
- 「Open Questions for IC」は明確に質問形式
- 不確実性は隠さず、Unknown/要確認/Weak は明示
- 過去類似案件(past_ic_memos/)があれば差分を1段落で言及

このプロンプトの肝は、最後の注意事項にある「投資推奨/見送りの結論は書かない」だ。ICドラフトに「Recommend: Invest」と書いてしまうと、その瞬間にClaudeは「結論を補強する論拠」を選びにいく。それはDDの作業として失格だ。結論を保留したまま、論点と材料だけを並べるのが正解。

4-6. 中間ドラフトのレビューサイクル

プロンプト1〜4で4つの中間ドラフトを作り、5でICメモにまとめる、というのが基本フローだが、現場では中間ドラフトの段階で必ず人間レビューを挟む。私のおすすめは「中間ドラフトを1本作ったら、その都度パートナー or シニアアソシエイトと10分ミーティング」というサイクルだ。30分の生成と10分のレビューを1セットにする。

レビューで見るのは、(1) 出典が一次資料を指しているか、(2) 主張と事実の区別ができているか、(3) 「Unknown」がアクションリスト化されているか、の3点だけ。中身の正しさを全部チェックするのではなく、フォーマットと信頼性レベルだけを確認する。Claudeが書いた数字の妥当性は、別途、財務モデルでクロスチェックすればよい。

このサイクルを組むと、Claudeのアウトプットを「ICの直前にまとめて見て、まとめて修正する」という事故が起きない。1本ずつ短いサイクルでレビューする方が、結果として総所要時間は短くなる。

5. ポートフォリオ管理・継続モニタリングへの応用

DDが終わって投資実行された後も、Claude Codeはポートフォリオモニタリングで使える。むしろ投資後のほうが、定型レポートのテンプレ化メリットが大きい。

5-1. 月次/四半期レポートのテンプレ化

VCの場合、ポートフォリオ各社から月次/四半期KPIをもらって、ファンドのLP向けレポートに集約する作業がある。これがエクセル手作業だと地獄なのだが、各社のKPIをマークダウンの定型フォーマットで提出してもらうように合意しておき、Claudeに「全社分を読んで、トラクション・バーンレート・主要マイルストーンの観点でサマリ」と指示するだけで、LP向けレポートの90%骨子が揃う。

portfolio/ 配下のすべての企業フォルダから、最新月のKPIファイル
(KPI_YYYYMM.md)を読み込み、ファンド全体のポートフォリオサマリを
出力してください。

タスク:
1. 各社のARR/MRR、QoQ成長率、Burn Multiple、Runwayをテーブル化
2. 投資後の進捗をRed/Amber/Greenでラベル(SCORING_RUBRIC.mdに従う)
3. Red/Amberの企業について、Action Itemをドラフト
4. ポートフォリオ全体のIRR/MOIC試算(評価額は最新ラウンドベース)

出力は portfolio/_reports/YYYYMM_portfolio_summary.md に。

注意:
- 個別企業の評価額は最新有効ラウンドの優先株価格を使う
- 評価額の前提を必ず注記
- Red/Amberの判定根拠を企業ごとに1行で書く
- 創業者個人の評価・推測は書かない

5-1-2. ボードシート(取締役会資料)準備の効率化

投資先の取締役会では、投資先側が出す資料と、ファンド側で別途用意する論点メモが必要になる。論点メモは「前回ボードからの差分」「業界動向に照らした懸念」「次回までに議論したい3つのトピック」あたりで構成するが、これもClaudeに前回議事録と最新KPIを読ませると、ドラフトが10分で揃う。

気をつける点は、ボードシートに書く「懸念」はClaudeの推測ではなく、投資先のKPIや前回コミットメントとの差分に基づく事実ベースの懸念であること。Claudeに「将来こうなるかもしれない」と推測させると、根拠の薄い不安を投資先にぶつけることになり、関係が悪化する。あくまで「前回○○とコミットしていたが、今回の数字を見ると差分が大きい。原因を聞きたい」という事実起点のフレーミングをClaudeに徹底させる。

5-2. ピッチイベント・ディールフローの初期スクリーニング

シードVCだと、月に100〜300件のディールフローが入ってくる。これを全て深掘りするのは不可能なので、初期スクリーニングが必須だ。Claudeにピッチデック10枚を一気に読ませて、ファンドのテーゼと照合する形でスクリーニングする使い方が便利。

ただし注意点として、初期スクリーニングでClaudeが「投資価値なし」と判断したものを機械的に切り捨てるのは危険だ。Claudeは過去のパターンに引きずられがちで、本当に新規性のある案件ほど「既存パターンに当てはまらない=低スコア」になりやすい。スクリーニングは「全件深掘りする時間が無いので優先順位を付ける」装置として使い、シードでアウトライヤーを狙うファンドほど人間レビューの厚みを保つこと。

5-3. LP向け四半期レターのドラフト生成

VC・グロースエクイティのファンド運営で大きな負荷になるのが、LP(Limited Partner)向け四半期レターだ。ポートフォリオ各社のハイライト、ファンド全体のIRR/MOICの試算、市場環境のコメント、新規投資・追加投資の説明、これらを毎四半期書くのは骨が折れる。

Claude Codeで効率化する場合の使い方は2段階だ。第1段階で「直近四半期にファンド内で起きたイベント(投資実行、追加ラウンド、エグジット、ボード変更、KPIの大きな変化)」のタイムラインを生成させる。第2段階で、そのタイムラインとファンドの投資テーゼを照合させ、LP向けに「ファンドが今この市場でどう動いているか」を語る文章のドラフトを書かせる。

注意点は、LPレターは将来の運用方針や投資先の見通しを書く文書なので、規制上の制約が大きい。米国であればSECの広告ルール、日本であれば金融商品取引法の私募ファンド規制が絡む。Claudeのドラフトを公開前にコンプライアンス部門でレビューする運用は絶対だ。Claudeに「LP向けに将来予測を書け」と指示すると、規制上の制約を知らずに踏み込んだ表現を書いてしまうリスクがある。プロンプトに「将来の業績・リターン予測を断定的に書かない」「個別投資先の評価額は最新ラウンドの優先株価格に依拠する」というルールを明記しておく。

6. 【要注意】Claude Code × DD業務でハマる失敗パターン4選

導入支援の現場で実際に見たり、自分でやらかしたりした失敗パターンを整理する。

失敗1: 「Claudeが出した結論をICにそのまま持ち込んでしまう」

❌ ダメな例: 「Claudeが分析した結果、TAMは過大評価ですがチームが強いので投資推奨」とIC席上で説明してしまう。Claudeが書いたまま、出典を確認せずに数字を引用してしまう。

⭕ 正しい例: ICには必ず人間が一次資料に当たって検証した数字のみを持ち込む。Claudeのアウトプットは「ドラフト」「論点整理」と明示し、結論部分は人間が責任を持って書く。「Claudeのアウトプット」とラベルされたまま投資委員会に上げない。

これは私が初期に何度かやらかした。「アウトプットが綺麗に揃っているから、つい中身を信じてしまう」のがエージェントの最大の罠だ。アウトプットが綺麗であることと、内容が正しいことは独立した属性だと言い聞かせる。

失敗2: 「ピッチデックの主張を事実として転記してしまう」

❌ ダメな例: 創業者がピッチデックで「ARR 5億円」と書いている数字を、Claudeがそのまま「ARR: 5億円」とIC資料に転記。月次P/Lで実際のARRが2.8億円だったことに、IC前夜に気づく。

⭕ 正しい例: CLAUDE.mdに「ピッチデックは創業者の主張であり、事実ではない。必ず『主張』『公開データ』『監査済み』の3層で出典を分けること」を明記。アウトプットでは必ず[主張][公開][監査]のいずれかをラベルする。

失敗3: 「過去類似案件のドラフトをそのまま流用してしまう」

❌ ダメな例: _knowledge/past_ic_memos/に置いた過去案件をClaudeが学習・参照して、新案件のIC資料の語り口が過去案件のコピーになる。投資テーゼの言い回しまで全部似てしまい、ICで「これ、前のあの案件と同じ書き方じゃない?」と指摘される。

⭕ 正しい例: 過去案件は「比較対象」として使い、語り口・フレーミング・結論部分は新案件固有のものとして書き直す。CLAUDE.mdに「過去類似案件は事実比較にのみ使い、文章表現・フレーミングを流用しないこと」を明示。

失敗4: 「機密情報の取り扱いを曖昧にしてしまう」

❌ ダメな例: NDA下のピッチデックや、創業者からの口頭情報を、注意せずプロジェクトディレクトリに置く。Claudeのアウトプットをそのまま社外メーリングリストやSlackに転送してしまう。

⭕ 正しい例: NDA情報は明確に分離(_confidential/のような専用フォルダ)、CLAUDE.mdに「_confidential/配下の情報は要約・サマリ生成は可能だが、原文の引用は外部共有用ドラフトに含めない」とルール化する。ICドラフト生成時にも「外部共有用」「内部限定」を明示的に区別する。ファンド全体のセキュリティポリシーと整合させる。

7. 導入ロードマップ: 3ヶ月でVCチームに定着させる

「Claude CodeをDDで使う」と決めても、チームに定着しないと意味がない。私が支援する場合の標準ロードマップは3ヶ月だ。

Month 1: 個人運用フェーズ

• パートナー1人 or アソシエイト1人がパイロットで使う
• _templates/とCLAUDE.mdの初版を作る
• 進行中の1案件で、プロンプト1〜5を1サイクル回す
• 「人間が書いたIC資料」と「Claudeドラフト」を並べて差分を可視化

Month 2: チーム共有フェーズ

• テンプレート群をチームに展開、コードレビューと同じ要領で改善
• パートナーを巻き込んで「Open Questions for IC」のフォーマットを統一
• 過去IC資料を5本ほど匿名化して_knowledge/past_ic_memos/に蓄積

Month 3: 標準化フェーズ

• 全案件でClaude Code経由のドラフト生成を標準化
• ポートフォリオ管理(月次レポート)にも展開
• ファンド全体のセキュリティポリシー・データガバナンスとの整合確認
• 運用ルールを社内Wikiに正式化

3ヶ月後の到達点は、「IC前夜の徹夜が無くなる」というよりも、「IC前夜にやる作業が、ドラフト作成ではなくドラフトレビューと一次資料の再確認になる」という質の変化だ。所要時間は半分以下になるが、それより重要なのは「論点の抜け漏れが減ること」だと感じている。

7-1. ファンド規模別の現実的な投資配分

Claude Code導入はライセンス費用と運用工数が発生する。ファンド規模ごとに、現実的なリソース配分の目安を共有しておく。あくまで私の感覚値だが、参考になれば幸いだ。

• 独立系シードファンド(運用総額20〜50億円): パートナー2〜3名 + アソシエイト1〜2名。Claude Codeは全員が使う前提。月次コストは数万円〜十万円のレンジ。テンプレ整備はアソシエイトが主担当、パートナーがレビュー。
• シリーズA中心の独立系VC(運用総額100〜300億円): パートナー3〜5名 + アソシエイト/アナリスト3〜5名。テンプレ整備に専任の「Operations」担当を置くと運用が安定する。月次コストは十万円〜数十万円。
• グロースエクイティ/PE(運用総額500億円〜): 案件規模が大きく、外部DDファーム(法務・財務・税務・コマーシャル)との並走が必須。Claude Codeはファンド内アナリストの作業効率化が中心で、外部DDファームへの依頼内容の整理・受領レポートのサマリ化にも使える。月次コストは数十万円〜。
• CVC(コーポレートベンチャーキャピタル): 親会社の事業シナジーを評価する独自の軸が入る。CLAUDE.mdに親会社事業との接点を評価する軸を追加し、専用テンプレを作るのが効果的。コンプライアンスは親会社の社内規定に従う必要があり、より厳格な運用設計になることが多い。

どの規模でも共通するのは、「導入初期に投資すべきはツールではなくテンプレートとルール」だ。Claude Code自体は誰でも数分で使い始められるが、ファンドの分析品質を担保するテンプレートと運用ルールは、3ヶ月かけて作り込む価値がある。

8. セキュリティ・コンプライアンス・倫理上の注意

VC業務は、NDA下の機密情報・未公開財務情報・人物評価情報を大量に扱う。Claude Code導入時に必ず押さえるべき論点を3つに絞ると、以下のとおりだ。

(1) データ送信ポリシーの明確化: Claude Codeのデフォルト設定では、コードベースの一部がAnthropic APIに送信される。これがファンドの守秘義務とどう整合するかを、必ず法務とリーガル(顧問弁護士)に確認する。Anthropic公式のUsage PolicyとPrivacy Policyを参照しつつ、Enterprise契約でのデータ取り扱いオプション(モデル学習からの除外、リテンション設定など)を確認する。

(2) 投資判断責任の所在: Claudeのアウトプットを根拠に投資判断を行ったとしても、投資判断の責任はファンドのGP/パートナーに残る。ファンドのLPA(Limited Partnership Agreement)上のFiduciary Duty(受託者責任)、米国・日本それぞれの規制(投資運用業の規制等)との整合は、必ず確認する。CFA Instituteの倫理基準も参考になる。

(3) インサイダー情報の取り扱い: 上場会社や上場会社のグループ会社が関係する案件では、インサイダー情報がClaudeのコンテキストに入り込む可能性がある。これは金融商品取引法上の重大なリスクなので、上場会社が絡む案件はそもそもClaudeに読ませない、というポリシーを最初に決めておくのが安全だ。

8-1. 利益相反(コンフリクト)管理

VCは同一業界で複数社に投資することは少ない(ポートフォリオ・コンフリクト)が、投資先候補が既存ポートフォリオの顧客や仕入先である場合のコンフリクトは頻繁に発生する。これをClaudeに見落とされないように、_knowledge/portfolio_list.mdに既存投資先と主要関係性を整理しておき、新規案件のDD開始時にClaudeに「既存ポートフォリオとのコンフリクトはないか」を必ずチェックさせる。

具体的なプロンプトとしては「deals/2026Q2-projectX/の投資先候補について、_knowledge/portfolio_list.mdと照合し、顧客関係・取引関係・人的関係でコンフリクトの可能性がある相手を全てリストアップしてください」と書く。Claudeが見つけたコンフリクトは、必ずパートナーとコンプライアンスにエスカレーションする。

8-2. データレジデンシーと国際規制

クロスボーダー投資の場合、投資先候補のデータが特定の国・地域に居住していることが規制上の前提となるケースがある。EUのGDPR、中国の個人情報保護法(PIPL)、米国のCCPA、日本の個人情報保護法、それぞれが異なる要件を持つ。投資先候補のデータをClaudeのコンテキストに渡す時点で、これらの規制との整合を確認する必要がある。

実務的には、投資先候補からの情報受領段階で「Claude等の外部AIサービスでの分析利用を前提とする旨」をNDAに織り込むか、別途同意を取る運用を推奨する。これがないと、後からデータの取り扱いを巡って摩擦が生じる。

8-3. 監査証跡(Audit Trail)の確保

規制対象の運用業者(投資運用業者、適格機関投資家等特例業務者など)では、投資判断プロセスの監査証跡が必須になる。「いつ、誰が、何を根拠に、どう判断したか」をログとして残す必要がある。Claudeのアウトプットを使った場合、そのプロンプト・アウトプット・人間レビューの記録もまた監査証跡の一部となりうる。

実務的には、各案件のClaudeアウトプット(中間ドラフトとICメモのドラフト)を、最終確定版のICメモと一緒にバージョン管理(Git)に入れておく。「Claudeのドラフトが最終ICメモにどう反映されたか」「人間レビューでどの数字を修正したか」が時系列で追えるようにしておくと、後から監査・内部統制レビューが入っても説明できる。

逆に、Claudeのアウトプットを使い捨てにして履歴を残さない運用は、規制対応の観点から推奨できない。「効率化したから記録が雑になった」と評価されると、ファンド全体のガバナンス評価が下がる。LP向けのファンド運営報告でも、AI活用と監査証跡の両立は重要な論点になりつつある。

9. よくある質問(FAQ)

Q1: Claude Codeのコスト感は?

A: 利用量によるが、1案件のDDで生成するトークン量はだいたい数百万〜千万トークン程度。Anthropicの公式価格表を参照しつつ、案件あたりのコストを試算しておくとよい。チーム全体だと月数万円〜十数万円のレンジに収まることが多い。アナリスト1人の時給と比較すれば、十分にペイする計算になる。

Q2: 投資先候補がClaudeでDDされていることを開示すべき?

A: 個人的にはYesだと考えている。創業者にとっても「ファンド側がDD作業をどう組み立てているか」は知っておきたい情報だ。ただし、Claudeへの情報入力範囲・出力の取り扱いを明確に説明する必要がある。

Q3: Claude以外のLLMやエージェントツールとどう違う?

A: ChatGPTやGeminiでも同様の作業は可能だが、Claude Codeの優位性は「プロジェクトディレクトリ全体を視野に入れた長文ドキュメント横断」と「CLAUDE.mdによる振る舞いのコード管理」にある。VCのように「複数の長文資料を横断する」業務との相性が良い。詳細はAnthropic公式のClaude Code overviewを参照。

Q4: 「投資推奨/見送り」をClaudeに出させてはいけない、というのは絶対?

A: 絶対と言ってよい。Claudeのアウトプットを「参考意見」として聞きたい場合でも、それは別途プロンプトで「あなたが投資家だったらどう判断するか、ただし最終判断ではなくICで議論する論点として」と聞く形にする。ICドラフトそのものに結論を書かせると、書き方が結論補強型に歪む。

Q5: ピッチデック以外の動画・音声(IRミーティング録画など)も使える?

A: 文字起こしされたものはテキストとして食わせられる。音声・動画そのものを直接扱う場合は、別途文字起こしツール(Whisper等)で前処理してからClaude Codeに渡すのが現状ベスト。

10. 関連事例・内部リンク

金融業界のClaude Code活用事例として、以下も合わせて読むと体系的に理解しやすい。

• 金融リスク計算(VaR算出)をClaude Codeで実装した事例 — 市場リスク管理におけるClaude Code活用
• 監査調書レビューをClaude Codeで7ステップ自動化した事例 — 監査業務とDD業務の共通点が多い
• 信用スコアリングモデル開発をClaude Codeで自動化した事例 — DDのスコアリング設計の参考

11. まとめ: VC DDにおけるClaude Codeの本当の価値

VCのデューデリジェンス業務をClaude Codeで効率化する話を、4軸×3層フレームワーク、ディレクトリ構成、コピペ可能なプロンプト5本、失敗パターン4個、3ヶ月導入ロードマップ、セキュリティ論点という順序で整理した。

個人的に重要だと思うポイントを3つだけ繰り返しておく。

1. DDの構造をマトリクスに落とす作業を最初にやる。4軸×3層の12マスを明示しないと、Claudeの出力はどんどん発散する。フォーマットを揃えるのは生産性のためでなく、論点漏れを防ぐためだ。
2. 「主張」と「事実」を機械的に分離する。ピッチデックは創業者の主張であり、事実ではない。CLAUDE.mdでこのルールをコード化しておくと、案件横断で一貫した品質が出る。
3. 結論を出すのは人間。Claudeに「Recommend: Invest/Pass」を書かせると、その瞬間にClaudeは結論補強型になる。結論は投資委員会で議論することで、Claudeはあくまで論点整理装置として使う。

DDは「Yes/Noを出す機械」ではなく「論点を漏らさず構造化する作業」だ。Claude Codeは前者には向かないが、後者には異常に強い。この区別さえつけば、徹夜のIC前夜は確実に減る。減った時間は、創業者との会話と、本当に重要な意思決定の検討に振り向けたい。それがVCの本業のはずなので。

著者プロフィール

佐藤傑(さとう・すぐる)。株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。100社以上の企業向けAI研修・導入支援を実施。著書『AIエージェント仕事術』(SBクリエイティブ)。SoftBank IT連載7回執筆。VC・PEファンドのDD支援、CVCの投資業務効率化、金融機関の生成AI導入アドバイザリーも対応。

次の一歩(3つのアクション)

1. ファンド内パイロット案件を1つ選ぶ: 進行中の案件で1つ、Claude Codeを並走させる。既存ワークフローを止める必要はない。
2. テンプレート群を最初の1案件で作り切る: _templates/とCLAUDE.mdを作るのは1案件目だけ。2案件目以降は流用で済む。
3. 無料相談で導入相談する: VC/PE向けのClaude Code導入支援を行っている。Uravation相談窓口から。

参考出典

1. Anthropic – Claude Code overview: https://docs.claude.com/
2. Anthropic – Usage Policy: https://www.anthropic.com/legal/aup
3. Anthropic – Privacy Policy: https://www.anthropic.com/privacy
4. Anthropic – Pricing: https://www.anthropic.com/pricing
5. CFA Institute – Code of Ethics and Standards of Professional Conduct: https://www.cfainstitute.org/
6. 経済産業省 – 価値協創ガイダンス: https://www.meti.go.jp/

本記事中の数字・事例は、VC実務で一般的に使われるDD作業のレンジを例示したものであり、特定の投資案件・投資先・ファンドの実例ではない。実際のDD・投資判断にあたっては、必ずファンド内のGP・パートナー・投資委員会・法務・リーガル・コンプライアンス部門の確認のうえで行うこと。

関連記事（自動）

• ▸ 【2026年最新】地銀・信金の融資審査補助AI完全活用
• ▸ 【2026年最新】商社の市況レポートをClaude Codeで効率化
• ▸ 監査法人の内部統制調書レビューをClaude Codeで自動化｜実装7手順
• ▸ 【2026年最新】AML調査をClaude Codeで自動化｜金融5実装手順
• ▸ 保険金請求書類チェックをClaude Codeで自動化｜不備検知と確認リスト