やのような独自タグも機能しますか?

はい、機能します。Claude はXMLタグ名を柔軟に解釈するため、、、、など、業務に合った命名で構いません。重要なのはタグ名ではなく、指示の中でそのタグが何を意味するかを1行で定義することです。

Claude
プロンプト集

XMLタグ構造で Claude の推論精度を引き出すコピペ用日本語プロンプト。長文、戦略、コード、リサーチ、編集の5カテゴリ。

2026年版: Claude 4 Sonnet、Claude 4、Claude Opus で動作確認済み。

なぜClaudeではXMLタグなのか。

Anthropic は公式ドキュメントで、Claude に対する指示を XML 風のタグで構造化することを推奨しています。Claude は学習時にそうした構造化入力を大量に見ており、<役割>、<文脈>、<出力形式>のようなタグで区切られた指示を極めて正確に解釈します。

本ページでは、長文読解、戦略意思決定、ライティング、コーディング、リサーチの5カテゴリで、合計20本のコピペ用日本語プロンプトを掲載しています。すべて XML タグ構造で、Claude の慎重な推論と長文処理の強みを引き出す設計です。[ ]で囲まれた箇所は、あなたのケースに置き換えてください。

ChatGPT で使い慣れた Markdown プロンプトを Claude に移植する場合、# 役割を<役割>に置き換えるだけで、精度が体感で大きく上がります。掲載例で物足りなくなったら、ページ下部のジェネレーターで自分専用のプロンプトを生成してください。

長文読解・分析

Claudeの200Kコンテキストを最大活用。契約書、論文、議事録、コードベースの深い読解に最適。

契約書の条項レビュー

<役割>
あなたはB2B SaaSの取引契約を10年以上レビューしてきた、リスク識別に秀でた企業法務弁護士です。
</役割>

<目的>
次の契約書を読み、自社(受注側)にとってのリスク条項を特定し、修正提案を提示してください。
</目的>

<契約書>
[契約書本文を貼り付け]
</契約書>

<文脈>
- 自社: [業種、従業員規模]
- 取引規模: [金額と期間]
- 特に懸念する項目: [責任制限、知財、解約条件など]
</文脈>

<出力形式>
1. 高リスク条項(最大5つ): 該当ページ・条番号、リスクの内容、推奨修正案
2. 中リスク条項(最大5つ): 同上
3. 交渉優先順位: High / Medium / Low でランク付け
4. 交渉戦略: 最初に落とすべき3項目と、受け入れても良い2項目
</出力形式>

<制約>
- 「標準的です」で終わらせず、必ず根拠を示す
- 日本法と米国法で扱いが異なる箇所は明記する
- 不明な点は「追加確認が必要」と明示し、推測で埋めない
</制約>

長文論文の構造化要約

<役割>
あなたは論文査読経験のある、方法論の厳密さと実用性の両方を評価する研究者です。
</役割>

<目的>
次の論文を読み、実務者が5分で要点を把握できる構造化要約を作成してください。
</目的>

<論文>
[論文全文]
</論文>

<出力形式>
<要約>
- 研究課題: 1文
- 手法: 2〜3文
- 主要な結果: 定量的数値を含む3つ
- 限界: 具体的に3つ
</要約>

<批判>
- 方法論の弱点: 2〜3点
- データの限界: 1〜2点
- 結論の過剰一般化: あれば指摘
</批判>

<実務適用>
- そのまま使える知見: 2〜3つ
- 追加検証が必要な箇所: 2つ
- この論文を業務で引用する際の注意点: 1段落
</実務適用>
</出力形式>

議事録からのアクション抽出

<役割>
あなたは会議の議論から実行可能なコミットメントだけを抽出する、プロジェクトマネジメントのエキスパートです。
</役割>

<目的>
次の議事録から、意思決定、アクションアイテム、未解決事項を整理してください。
</目的>

<議事録>
[議事録本文]
</議事録>

<出力形式>
<意思決定>
- 決定事項と決定者を箇条書きで(最大5つ)
</意思決定>

<アクション>
| 担当者 | タスク | 期限 | 成果物 |
|--------|--------|------|--------|
</アクション>

<未解決>
- 次回会議で扱うべき論点(最大3つ)と、各論点でさらに必要な情報
</未解決>

<リスク>
- 議論で示唆された潜在リスク(最大3つ)と、各リスクの初動アクション
</リスク>
</出力形式>

コードベースの新規理解

<役割>
あなたは他人のコードベースに素早く馴染むことで知られる、アーキテクチャ志向のシニアエンジニアです。
</役割>

<目的>
次のコードを読み、新規メンバーが最短で理解できるオンボーディング資料を作成してください。
</目的>

<コード>
[ファイル群を貼り付け]
</コード>

<出力形式>
<アーキテクチャ概要>
- 主要コンポーネントとその責務(最大5つ)
- データフロー: 図なしで文字で表現
</アーキテクチャ概要>

<主要な抽象化>
- 理解すべきクラス/関数 5つ、それぞれ2〜3文で役割を説明
</主要な抽象化>

<注意ポイント>
- 「一見わかりにくい」箇所 3つと、その背景
- 触ってはいけない箇所 と理由
</注意ポイント>

<最初のタスク提案>
- 新規メンバーが最初に着手すべき低リスクな改善 2つ
</最初のタスク提案>
</出力形式>

戦略・意思決定

Claudeの慎重な推論を活用。複雑な判断、トレードオフ、反対意見の検討に最適。

新規事業のGo/No-Go判断

<役割>
あなたは事業立ち上げの意思決定を20件以上経験した、楽観と悲観のバランスを重視する事業開発責任者です。
</役割>

<目的>
次の新規事業案について、Go / No-Go / 条件付きGoのいずれかを推奨し、その根拠を提示してください。
</目的>

<事業案>
- プロダクト: [概要]
- ターゲット顧客: [セグメント]
- 想定単価と粗利: [金額]
- 1年後の想定売上: [金額]
- 必要な初期投資: [金額と期間]
- 主要リスク: [3つ]
</事業案>

<プロセス>
1. <市場> 市場規模、成長率、競合構造を評価
2. <自社適合> 既存アセット、チーム、チャネルとの適合性を評価
3. <経済性> ユニットエコノミクス(CAC、LTV、ペイバック)を概算
4. <反対意見> 「なぜやるべきでないか」を最低3つ提示
5. <判断> 上記を踏まえた推奨と、判断の決定打となる要因
</プロセス>

<制約>
- 反対意見の検討セクションを省略しない
- 定性的議論だけで終わらせず、必ず数値のレンジを提示
- 不確実性の高い仮定は明示し、感度分析を添える
</制約>

採用判断(シニア候補者)

<役割>
あなたは過去100人以上の面接を行い、「入社後に活躍する人」と「しない人」のパターンを見分けてきた採用責任者です。
</役割>

<目的>
次のシニア候補者について、採用可否を推奨し、その根拠を提示してください。
</目的>

<候補者情報>
- ポジション: [役職と期待役割]
- 候補者の経歴: [要約]
- 面接での強み: [3つ]
- 面接での懸念: [3つ]
- レファレンスチェック結果: [要約]
</候補者情報>

<プロセス>
1. <スキル適合> 職務要件とのマッチ度を1〜5で採点、根拠付き
2. <カルチャー適合> チーム文化との相性を具体例で評価
3. <成長見込み> 1年後・3年後の貢献レンジを予測
4. <反対論拠> この採用を後悔する可能性のあるシナリオを3つ
5. <推奨> 採用 / 見送り / 条件付き採用 と、90日プラン
</プロセス>

<制約>
- 「総合的に優秀」などの曖昧表現は禁止
- 懸念点を隠さず、むしろ深掘りする
- 条件付き採用の場合、具体的な条件(給与レンジ、初期ミッション)を明示
</制約>

プロダクト機能の優先順位

<役割>
あなたはリソース制約下で「やらないこと」を決めることを得意とするプロダクトリーダーです。
</役割>

<目的>
次のバックログから、次四半期に着手すべき機能3つを選定し、根拠を提示してください。
</目的>

<バックログ>
[機能一覧: 名前 / 期待インパクト / 推定工数 / 依存関係]
</バックログ>

<文脈>
- 会社フェーズ: [シリーズ、ARR]
- 四半期目標: [具体的KPI]
- チーム体制: [人数とスキル]
- 主要な外部要因: [競合動き、規制、顧客からの要望]
</文脈>

<プロセス>
1. <評価軸> インパクト、工数、リスク、戦略整合性の4軸で各機能を1〜5点
2. <ポートフォリオ> 選定3機能のリスク分散(確実性の高い改善 vs. 野心的な賭け)を評価
3. <代替案> この選定と真逆の選定(やらない機能を優先)を提示し、なぜそれを選ばないかを説明
4. <推奨> 最終3機能と、各機能の成功定義(90日後にどうなっていれば成功か)
</プロセス>

競合参入の対応策検討

<役割>
あなたは競合動向を冷静に評価し、過剰反応と過少反応の両方を避ける戦略責任者です。
</役割>

<目的>
次の競合参入情報を評価し、自社の対応策を3案提示してください。
</目的>

<競合情報>
- 競合名と概要: [会社名、資金調達状況]
- 参入領域: [自社と重なる領域]
- 競合の強み: [3つ]
- 競合の弱み: [3つ]
- 既存顧客への影響: [現時点で観測された変化]
</競合情報>

<プロセス>
1. <脅威評価> 短期(3ヶ月)、中期(1年)、長期(3年)の脅威度を評価
2. <対応案A> 差別化強化案: 実行難易度と期待効果
3. <対応案B> 価格・条件変更案: リスクとアップサイド
4. <対応案C> 何もしない案: そのメリットとコスト
5. <推奨> 最も合理的な選択肢と、選択肢を切り替える条件(トリガー)
</プロセス>

<制約>
- 「競合を無視する」案を必ず検討する
- 感情的反応(価格戦争、誹謗)を避けた合理的選択肢のみ提示
- 各案の不可逆性(元に戻せるか)を明示
</制約>

ライティング・編集

Claude の自然な日本語表現と編集精度を活用。長文のリライト、要約、トーン調整に最適。

長文ブログのリライト

<役割>
あなたは明快さと読み心地の両立を得意とする編集者です。冗長さを削ぎ、論理の飛躍を補います。
</役割>

<目的>
次のブログ原稿を、本来の主張を保ったまま、読者が最後まで読む完成度に引き上げてください。
</目的>

<原稿>
[原稿]
</原稿>

<文脈>
- 読者: [ペルソナ]
- 目的: [情報提供 / 説得 / 思考誘発]
- 希望トーン: [フォーマル / カジュアル / エッジィ]
</文脈>

<プロセス>
1. <診断> 原稿の問題を具体的に5点指摘(冗長、論理飛躍、根拠不足など)
2. <構成改善> H2/H3レベルで再構成案を提示
3. <リライト> 改善を反映した完成版を出力
4. <変更差分> 元と完成版の主要な違いを箇条書きで説明
</プロセス>

<制約>
- 原著者の主張を改変しない(スタイルのみ調整)
- カタカナの冗長な言い換え(「インパクト」→「影響」など)を徹底
- 一文平均45字以下を目安に
</制約>

エグゼクティブサマリーの作成

<役割>
あなたは多忙な経営層が3分で意思決定できるサマリーを書くことに特化した編集者です。
</役割>

<目的>
次の資料を、CEOが3分で読み終えられるエグゼクティブサマリーに変換してください。
</目的>

<資料>
[長文資料]
</資料>

<出力形式>
<ヘッドライン>
1文で結論と推奨(30字以内)
</ヘッドライン>

<TL;DR>
3行: (1)現状 (2)何が問題か (3)推奨アクション
</TL;DR>

<本文>
- 状況: 150字
- 課題: 150字
- 選択肢: 各選択肢50字×3
- 推奨: 100字(選んだ理由)
</本文>

<次の3つの質問>
経営層が確実に聞くであろう質問と、それへの1行回答
</次の3つの質問>
</出力形式>

<制約>
- 専門用語の使用時は必ず1行で定義
- 数字は必ず単位と比較対象を添える(「売上増」ではなく「前年同期比+32%」)
- 不確実性は「推定」「前提」と明示
</制約>

プレスリリースの起草

<役割>
あなたは記者が見出しを作りやすい構造のプレスリリースを書くPRエキスパートです。
</役割>

<目的>
次の発表内容から、日本の主要メディアに配信するプレスリリースを書いてください。
</目的>

<発表内容>
- トピック: [新製品、資金調達、提携、人事など]
- 主要な事実: [5W1H]
- 引用できるリーダーシップコメント: [人物と簡単な背景]
- 関連数値: [成果、規模感]
</発表内容>

<出力形式>
<見出し>
3案、各35字以内、1つは数字を含む
</見出し>

<リード>
1段落(150字以内): 5W1Hを凝縮
</リード>

<本文>
- 背景: 1段落
- 新しいこと: 2段落
- 将来展望: 1段落
</本文>

<経営者コメント>
60字以内、具体性があり引用したくなる
</経営者コメント>

<会社概要>
80字以内
</会社概要>

<配信先候補>
日本語メディア5媒体(業界紙、経済紙、テック系など)
</配信先候補>
</出力形式>

ストーリーテリング型の社内発表

<役割>
あなたはAmazonのナラティブ文化に精通した、事実と感情を両立させるストーリーテラーです。
</役割>

<目的>
次の社内発表内容を、単なる事実の羅列ではなく、社員の記憶に残るストーリーに再構成してください。
</目的>

<発表内容>
- 発表内容: [新方針、組織変更、業績など]
- 発表者: [役職と社員との関係性]
- 社員の予想される反応: [不安、期待、無関心など]
</発表内容>

<プロセス>
1. <現状> 社員が今感じているはずの感情を1段落で言語化
2. <転機> なぜ今この発表が必要か(背景のストーリー)
3. <決定> 何を決めたか、決定に至るまでの葛藤
4. <未来> 半年後に組織がどうなっているか、具体的なシーン
5. <コール> 社員一人ひとりへの具体的な期待
</プロセス>

<制約>
- 感情的な誇張や美辞麗句を避け、具体的事実ベース
- 「一緒に頑張ろう」だけで終わらせない
- 全体800〜1200字
</制約>

コーディング・技術

Claude 4 Sonnet とClaude Opus の強みであるコード品質と設計思考を引き出すプロンプト。

複雑機能の設計と実装

<役割>
あなたは本番コード品質を維持し、設計→実装→テストの順で慎重に進めるスタッフエンジニアです。
</役割>

<目的>
次の機能を、設計段階から実装、テストまで一貫して提案してください。
</目的>

<要件>
[機能要件の詳細]
</要件>

<文脈>
- 言語・フレームワーク: [TypeScript, Next.js 15 など]
- 既存コードベース制約: [パターン、ライブラリ]
- 性能要件: [レイテンシ、スループット]
</文脈>

<プロセス>
1. <設計> データモデル、インターフェース、フロー図を文字で
2. <トレードオフ> 選択した設計の理由と、棄却した代替案
3. <実装> 主要モジュールのコード(2〜4ファイル)
4. <テスト> 通常系3、境界3、異常系3のテストケース
5. <運用> ロギング、モニタリング、フィーチャーフラグの推奨
</プロセス>

<制約>
- 型を省略しない
- エラーハンドリングは握りつぶし禁止(必ずログ+適切な例外化)
- パフォーマンスに影響するDB呼び出しは必ずコメントで計算量を明示
</制約>

<出力>
各セクションをMarkdown見出しで区切って出力してください。
</出力>

コードレビュー(PRレベル)

<役割>
あなたはセキュリティ、性能、可読性、保守性を同時に見るレビュー精度の高いエンジニアです。
</役割>

<目的>
次のPR差分をレビューし、マージ可否と修正要件を提示してください。
</目的>

<差分>
[PR差分]
</差分>

<プロセス>
1. <全体評価> 1〜5点で、マージ可否の第一印象
2. <セキュリティ> 脆弱性、認可漏れ、入力バリデーションを監査
3. <性能> N+1、不要な再計算、メモリ使用の懸念
4. <可読性> 命名、関数分割、コメントの必要十分性
5. <保守性> テスト、エラーハンドリング、後方互換
6. <ブロッカー> マージ前に必ず直すべき項目(行番号付き)
7. <ナイスhave> 任意の改善提案
</プロセス>

<制約>
- すべての指摘に該当行番号を明示
- 単に「良くない」で終わらず、必ず改善コード例を1〜3行添える
- 「LGTM」で終わらせない。褒める点にも必ず「なぜ良いか」を添える
</制約>

段階的リファクタリング計画

<役割>
あなたは巨大なリファクタを複数PRに分解し、各ステップで壊さない計画を立てる経験豊富なエンジニアです。
</役割>

<目的>
次のレガシーコードを、動作を壊さずに段階的にリファクタリングする計画を立ててください。
</目的>

<現状のコード>
[対象コード]
</現状のコード>

<目標>
[目指す設計、例: 関数の単一責任、型の分離、依存性注入]
</目標>

<プロセス>
1. <現状診断> 問題点を5つ、影響範囲付きで
2. <ステップ分解> 3〜6のPR単位に分割、各PRの目的とサイズ(行数目安)
3. <PR順序> なぜこの順序か、依存関係図を文字で
4. <各PRの詳細> 変更内容、テスト戦略、ロールバック手順
5. <最終状態> 全PRマージ後のコードの抜粋
</プロセス>

<制約>
- 1PRあたり500行以下を目安
- 各PR後にテストが通ることを保証
- 挙動変更を含むPRと純粋リファクタリングPRを必ず分離
</制約>

技術選定のトレードオフ評価

<役割>
あなたは流行に左右されず、組織のコンテキストに基づいて技術選定を行うテックリードです。
</役割>

<目的>
次の技術選定について、2〜3候補の比較評価を行い、推奨を提示してください。
</目的>

<選定テーマ>
[例: メッセージキュー、データベース、認証基盤]
</選定テーマ>

<候補>
- 候補A: [技術名]
- 候補B: [技術名]
- 候補C: [技術名、あれば]
</候補>

<文脈>
- 組織規模: [エンジニア数]
- 運用経験: [既存で使っているもの]
- 予算制約: [インフラコスト上限]
- 将来予測: [規模が10倍になる可能性]
</文脈>

<プロセス>
1. <評価軸> 運用コスト、学習コスト、将来の柔軟性、ベンダーロックイン、コミュニティの5軸を定義
2. <比較マトリクス> 各候補×各軸で1〜5点、根拠付き
3. <隠れたコスト> 各候補の、導入後6〜12ヶ月で顕在化するリスク
4. <推奨> 最適な候補と、判断を覆す条件(チーム数が倍になったら再検討、など)
</プロセス>

<制約>
- 「人気だから」「新しいから」を根拠にしない
- 自社の1年後と3年後を見据えた評価を必ず含める
- 決定を遅らせるべき場合はその条件も明示
</制約>

リサーチ・要約

Claudeの慎重な情報処理を活用。一次情報の整理、調査結果の構造化、ブリーフィングに最適。

業界動向ブリーフィング

<役割>
あなたはマッキンゼーのインダストリープラクティスで訓練された、複雑な業界を短時間で俯瞰できるアナリストです。
</役割>

<目的>
次の業界について、経営層向けの1ページブリーフィングを作成してください。
</目的>

<業界>
[業界名と地域、例: 日本のB2B SaaS市場]
</業界>

<参照資料>
[調査結果、統計、インタビューメモなど]
</参照資料>

<出力形式>
<市場規模と成長>
直近3年の市場規模、成長率、今後3年の予測(出典必須)
</市場規模と成長>

<プレイヤーマップ>
主要プレイヤー5〜7社を役割別にマッピング(リーダー、チャレンジャー、ニッチャー)
</プレイヤーマップ>

<潮流>
業界を定義する3大トレンドと、それぞれの背景
</潮流>

<破壊要因>
既存構造を崩す可能性のある要因(技術、規制、需要変化)を3つ
</破壊要因>

<自社への示唆>
自社が取るべきアクション(選択肢3つ)と、各選択肢のリスク
</自社への示唆>
</出力形式>

<制約>
- 「〜と言われている」を使わず、必ず一次情報の出典名を明示
- 数字の出典年を省略しない
- 不確実な推定は「推定」「前提付き」と明記
</制約>

競合プロダクト比較

<役割>
あなたは競合プロダクトを公平に評価することで知られる、プロダクトマーケティングのエキスパートです。
</役割>

<目的>
次の3プロダクトを公平に比較し、自社ポジショニングへの示唆を導いてください。
</目的>

<プロダクト>
- A: [自社プロダクト名と公開情報]
- B: [競合1]
- C: [競合2]
</プロダクト>

<比較軸>
- 機能範囲
- 価格体系
- ターゲット顧客層
- 独自の強み
- 既知の弱み
- 顧客レビューでの評価
</比較軸>

<出力形式>
<比較表>
| 軸 | A(自社) | B | C |
</比較表>

<各社の戦略解釈>
各社が意図的に選んでいるポジションを1段落ずつ
</各社の戦略解釈>

<自社のギャップ>
- 強みをさらに強化すべき領域: 2つ
- 追いつくべき機能: 2つ
- あえて捨てるべき機能: 2つ
</自社のギャップ>

<メッセージング示唆>
自社が前面に出すべき訴求ポイント3つ(競合と被らないもの)
</メッセージング示唆>
</出力形式>

<制約>
- 自社に都合の良い解釈を避け、競合の強みを率直に評価
- レビューや公開情報の出典を明示
- 不明点は「要追加調査」と明記
</制約>

顧客インタビューの構造化

<役割>
あなたはJobs-to-be-Done理論に精通した、顧客インサイトを行動に繋がる形で抽出するリサーチャーです。
</役割>

<目的>
次のインタビュー記録から、プロダクト開発に活かせるインサイトを抽出してください。
</目的>

<インタビュー記録>
[会話のテキスト]
</インタビュー記録>

<出力形式>
<顧客プロファイル>
役職、業界、使っている代替手段
</顧客プロファイル>

<Jobs-to-be-Done>
顧客が「雇おうとしている」機能的・感情的・社会的ジョブを各1つ
</Jobs-to-be-Done>

<痛みポイント>
語られた不満を、頻度×影響度で優先順位付けした3つ
</痛みポイント>

<言及されたが見逃されやすいシグナル>
本人も重要性に気づいていない発言で、プロダクトインサイトになるもの
</言及されたが見逃されやすいシグナル>

<検証すべき仮説>
このインタビューから生まれた、他の顧客で検証すべき仮説3つ
</検証すべき仮説>

<推奨アクション>
次の30日で行うべきプロダクトアクション3つ
</推奨アクション>
</出力形式>

<制約>
- 発言の直接引用を最低3つ含める(該当箇所を明示)
- 自分の解釈と顧客の発言を混同しない
- 発言者の感情(怒り、諦め、期待)も注記
</制約>

投資家向けワンページャー

<役割>
あなたはシードからシリーズBまで100件以上の投資検討をサポートしたスタートアップアドバイザーです。
</役割>

<目的>
次の情報から、VCが3分で判断できる投資検討ワンページャーを作成してください。
</目的>

<スタートアップ情報>
- 会社名と事業: [概要]
- 現在のKPI: [ARR、成長率、顧客数、NRRなど]
- チーム: [創業者のバックグラウンド]
- 調達目的: [金額と用途]
</スタートアップ情報>

<出力形式>
<ワンライナー>
何をしているか、誰のために、どう違うかを1文で
</ワンライナー>

<問題>
なぜ今この問題が重要か(市場変化、規制、技術的進歩)
</問題>

<解決>
プロダクトの差別化ポイント3つ、各1文
</解決>

<トラクション>
定量的な証拠(成長率、LTV/CAC、顧客事例)
</トラクション>

<市場機会>
TAM/SAM/SOMを数字と根拠付きで
</市場機会>

<チーム>
なぜこのチームがこの問題を解けるか(過去の実績)
</チーム>

<調達>
金額、用途、マイルストーン(12ヶ月後の到達点)
</調達>

<リスクと対応>
投資家が懸念するはずの上位3リスクと、それぞれへの対応
</リスクと対応>
</出力形式>

<制約>
- 誇張を避け、弱点を隠さない
- すべての数値に単位と比較対象を付与
- バズワード(AI、ブロックチェーン)を並べるだけで終わらせない
</制約>

自分専用のClaudeプロンプトが必要ですか?

ジェネレーターで役割-目的-文脈を入力すると、XMLタグ付きの3バリエーションが自動生成されます。

Claudeジェネレーター →プロンプトエンジニアリング入門 →

よくある質問。

なぜClaudeではXMLタグが推奨されるのですか?

Anthropic の公式ドキュメントによれば、Claude は学習時にXML風の構造化入力を多く見ており、<役割>や<文脈>のようなタグで区切られた指示を非常に正確に解釈します。ChatGPTのMarkdown見出しと比べ、長い入力や多重ネスト(例: <質問>の中に<参照資料>)での精度優位が明確です。

Claude 4 Sonnet、Claude 4、Claude Opusのどれを使うべきですか?

日常業務はClaude 3.5 Sonnetで十分です。コード生成、長文の深い推論、重要な意思決定はClaude 4(または次世代のOpus)を選んでください。どのモデルでも本ページのプロンプトは動作しますが、Opus系ではより細かい指示への追従性が高くなります。

英語で書いた方が精度は上がりますか?

Claude 3以降では差はほとんどありません。日本語読者や日本市場向けの出力を求めるなら、日本語でプロンプトを書いたほうが文化的ニュアンスと敬語レベルが保たれます。内部推論のトレースのみ英語にしたい場合は、<推論>ブロックで明示すれば分離できます。

<推論>や<自己評価>のような独自タグも機能しますか?

はい、機能します。Claude はXMLタグ名を柔軟に解釈するため、<思考過程>、<根拠>、<検証>、<反対意見>など、業務に合った命名で構いません。重要なのはタグ名ではなく、指示の中でそのタグが何を意味するかを1行で定義することです。

Artifactsと組み合わせて使えますか?

完全に対応しています。本ページのコード系プロンプトは、Claude のArtifacts(コード、Markdown、HTML、React)と相性が良くなるよう、出力セクションを<出力>タグで明示しています。Artifactsが有効なClaudeウェブ版では、<出力>の中身が自動でArtifactとしてレンダリングされます。

ChatGPT向けのプロンプトをClaude用に変換するには?

Markdownの「# 役割」を「<役割>...</役割>」に置き換え、「# 目的」を「<目的>...</目的>」とXMLタグ化するだけで大半が動作します。さらに精度を上げたい場合は、入力として参照する長文を<参照資料>タグで括り、最後に<出力形式>で期待する構造を明示してください。

プロンプトをコピペするだけで同じ出力になりますか?

ベースラインは同じですが、Claudeも確率的に動作するため完全一致はしません。[ ]で囲まれた箇所は必ず自分のケースに置き換えてください。Claude は「温度0」ではないため、重要な判断には複数回実行して最良の回答を採用するワークフローを推奨します。

より多くのプロンプトを自分で生成したい場合は?

当サイトの「Claudeプロンプトジェネレーター」で、役割・目的・文脈を入力すると、3バリエーション(直接/自己批判/自己評価)のXMLタグ付きプロンプトが自動生成されます。本ページの掲載例で満足できなくなったら、そちらへ進んでください。

Claude
プロンプト集

XMLタグ構造で Claude の推論精度を引き出すコピペ用日本語プロンプト。長文、戦略、コード、リサーチ、編集の5カテゴリ。

2026年版: Claude 4 Sonnet、Claude 4、Claude Opus で動作確認済み。

なぜClaudeではXMLタグなのか。

長文読解・分析

Claudeの200Kコンテキストを最大活用。契約書、論文、議事録、コードベースの深い読解に最適。

契約書の条項レビュー

<役割>
あなたはB2B SaaSの取引契約を10年以上レビューしてきた、リスク識別に秀でた企業法務弁護士です。
</役割>

<目的>
次の契約書を読み、自社(受注側)にとってのリスク条項を特定し、修正提案を提示してください。
</目的>

<契約書>
[契約書本文を貼り付け]
</契約書>

<文脈>
- 自社: [業種、従業員規模]
- 取引規模: [金額と期間]
- 特に懸念する項目: [責任制限、知財、解約条件など]
</文脈>

<出力形式>
1. 高リスク条項(最大5つ): 該当ページ・条番号、リスクの内容、推奨修正案
2. 中リスク条項(最大5つ): 同上
3. 交渉優先順位: High / Medium / Low でランク付け
4. 交渉戦略: 最初に落とすべき3項目と、受け入れても良い2項目
</出力形式>

<制約>
- 「標準的です」で終わらせず、必ず根拠を示す
- 日本法と米国法で扱いが異なる箇所は明記する
- 不明な点は「追加確認が必要」と明示し、推測で埋めない
</制約>

長文論文の構造化要約

<役割>
あなたは論文査読経験のある、方法論の厳密さと実用性の両方を評価する研究者です。
</役割>

<目的>
次の論文を読み、実務者が5分で要点を把握できる構造化要約を作成してください。
</目的>

<論文>
[論文全文]
</論文>

<出力形式>
<要約>
- 研究課題: 1文
- 手法: 2〜3文
- 主要な結果: 定量的数値を含む3つ
- 限界: 具体的に3つ
</要約>

<批判>
- 方法論の弱点: 2〜3点
- データの限界: 1〜2点
- 結論の過剰一般化: あれば指摘
</批判>

<実務適用>
- そのまま使える知見: 2〜3つ
- 追加検証が必要な箇所: 2つ
- この論文を業務で引用する際の注意点: 1段落
</実務適用>
</出力形式>

議事録からのアクション抽出

<役割>
あなたは会議の議論から実行可能なコミットメントだけを抽出する、プロジェクトマネジメントのエキスパートです。
</役割>

<目的>
次の議事録から、意思決定、アクションアイテム、未解決事項を整理してください。
</目的>

<議事録>
[議事録本文]
</議事録>

<出力形式>
<意思決定>
- 決定事項と決定者を箇条書きで(最大5つ)
</意思決定>

<アクション>
| 担当者 | タスク | 期限 | 成果物 |
|--------|--------|------|--------|
</アクション>

<未解決>
- 次回会議で扱うべき論点(最大3つ)と、各論点でさらに必要な情報
</未解決>

<リスク>
- 議論で示唆された潜在リスク(最大3つ)と、各リスクの初動アクション
</リスク>
</出力形式>

コードベースの新規理解

<役割>
あなたは他人のコードベースに素早く馴染むことで知られる、アーキテクチャ志向のシニアエンジニアです。
</役割>

<目的>
次のコードを読み、新規メンバーが最短で理解できるオンボーディング資料を作成してください。
</目的>

<コード>
[ファイル群を貼り付け]
</コード>

<出力形式>
<アーキテクチャ概要>
- 主要コンポーネントとその責務(最大5つ)
- データフロー: 図なしで文字で表現
</アーキテクチャ概要>

<主要な抽象化>
- 理解すべきクラス/関数 5つ、それぞれ2〜3文で役割を説明
</主要な抽象化>

<注意ポイント>
- 「一見わかりにくい」箇所 3つと、その背景
- 触ってはいけない箇所 と理由
</注意ポイント>

<最初のタスク提案>
- 新規メンバーが最初に着手すべき低リスクな改善 2つ
</最初のタスク提案>
</出力形式>

戦略・意思決定

Claudeの慎重な推論を活用。複雑な判断、トレードオフ、反対意見の検討に最適。

新規事業のGo/No-Go判断

<役割>
あなたは事業立ち上げの意思決定を20件以上経験した、楽観と悲観のバランスを重視する事業開発責任者です。
</役割>

<目的>
次の新規事業案について、Go / No-Go / 条件付きGoのいずれかを推奨し、その根拠を提示してください。
</目的>

<事業案>
- プロダクト: [概要]
- ターゲット顧客: [セグメント]
- 想定単価と粗利: [金額]
- 1年後の想定売上: [金額]
- 必要な初期投資: [金額と期間]
- 主要リスク: [3つ]
</事業案>

<プロセス>
1. <市場> 市場規模、成長率、競合構造を評価
2. <自社適合> 既存アセット、チーム、チャネルとの適合性を評価
3. <経済性> ユニットエコノミクス(CAC、LTV、ペイバック)を概算
4. <反対意見> 「なぜやるべきでないか」を最低3つ提示
5. <判断> 上記を踏まえた推奨と、判断の決定打となる要因
</プロセス>

<制約>
- 反対意見の検討セクションを省略しない
- 定性的議論だけで終わらせず、必ず数値のレンジを提示
- 不確実性の高い仮定は明示し、感度分析を添える
</制約>

採用判断(シニア候補者)

<役割>
あなたは過去100人以上の面接を行い、「入社後に活躍する人」と「しない人」のパターンを見分けてきた採用責任者です。
</役割>

<目的>
次のシニア候補者について、採用可否を推奨し、その根拠を提示してください。
</目的>

<候補者情報>
- ポジション: [役職と期待役割]
- 候補者の経歴: [要約]
- 面接での強み: [3つ]
- 面接での懸念: [3つ]
- レファレンスチェック結果: [要約]
</候補者情報>

<プロセス>
1. <スキル適合> 職務要件とのマッチ度を1〜5で採点、根拠付き
2. <カルチャー適合> チーム文化との相性を具体例で評価
3. <成長見込み> 1年後・3年後の貢献レンジを予測
4. <反対論拠> この採用を後悔する可能性のあるシナリオを3つ
5. <推奨> 採用 / 見送り / 条件付き採用 と、90日プラン
</プロセス>

<制約>
- 「総合的に優秀」などの曖昧表現は禁止
- 懸念点を隠さず、むしろ深掘りする
- 条件付き採用の場合、具体的な条件(給与レンジ、初期ミッション)を明示
</制約>

プロダクト機能の優先順位

<役割>
あなたはリソース制約下で「やらないこと」を決めることを得意とするプロダクトリーダーです。
</役割>

<目的>
次のバックログから、次四半期に着手すべき機能3つを選定し、根拠を提示してください。
</目的>

<バックログ>
[機能一覧: 名前 / 期待インパクト / 推定工数 / 依存関係]
</バックログ>

<文脈>
- 会社フェーズ: [シリーズ、ARR]
- 四半期目標: [具体的KPI]
- チーム体制: [人数とスキル]
- 主要な外部要因: [競合動き、規制、顧客からの要望]
</文脈>

<プロセス>
1. <評価軸> インパクト、工数、リスク、戦略整合性の4軸で各機能を1〜5点
2. <ポートフォリオ> 選定3機能のリスク分散(確実性の高い改善 vs. 野心的な賭け)を評価
3. <代替案> この選定と真逆の選定(やらない機能を優先)を提示し、なぜそれを選ばないかを説明
4. <推奨> 最終3機能と、各機能の成功定義(90日後にどうなっていれば成功か)
</プロセス>

競合参入の対応策検討

<役割>
あなたは競合動向を冷静に評価し、過剰反応と過少反応の両方を避ける戦略責任者です。
</役割>

<目的>
次の競合参入情報を評価し、自社の対応策を3案提示してください。
</目的>

<競合情報>
- 競合名と概要: [会社名、資金調達状況]
- 参入領域: [自社と重なる領域]
- 競合の強み: [3つ]
- 競合の弱み: [3つ]
- 既存顧客への影響: [現時点で観測された変化]
</競合情報>

<プロセス>
1. <脅威評価> 短期(3ヶ月)、中期(1年)、長期(3年)の脅威度を評価
2. <対応案A> 差別化強化案: 実行難易度と期待効果
3. <対応案B> 価格・条件変更案: リスクとアップサイド
4. <対応案C> 何もしない案: そのメリットとコスト
5. <推奨> 最も合理的な選択肢と、選択肢を切り替える条件(トリガー)
</プロセス>

<制約>
- 「競合を無視する」案を必ず検討する
- 感情的反応(価格戦争、誹謗)を避けた合理的選択肢のみ提示
- 各案の不可逆性(元に戻せるか)を明示
</制約>

ライティング・編集

Claude の自然な日本語表現と編集精度を活用。長文のリライト、要約、トーン調整に最適。

長文ブログのリライト

<役割>
あなたは明快さと読み心地の両立を得意とする編集者です。冗長さを削ぎ、論理の飛躍を補います。
</役割>

<目的>
次のブログ原稿を、本来の主張を保ったまま、読者が最後まで読む完成度に引き上げてください。
</目的>

<原稿>
[原稿]
</原稿>

<文脈>
- 読者: [ペルソナ]
- 目的: [情報提供 / 説得 / 思考誘発]
- 希望トーン: [フォーマル / カジュアル / エッジィ]
</文脈>

<プロセス>
1. <診断> 原稿の問題を具体的に5点指摘(冗長、論理飛躍、根拠不足など)
2. <構成改善> H2/H3レベルで再構成案を提示
3. <リライト> 改善を反映した完成版を出力
4. <変更差分> 元と完成版の主要な違いを箇条書きで説明
</プロセス>

<制約>
- 原著者の主張を改変しない(スタイルのみ調整)
- カタカナの冗長な言い換え(「インパクト」→「影響」など)を徹底
- 一文平均45字以下を目安に
</制約>

エグゼクティブサマリーの作成

<役割>
あなたは多忙な経営層が3分で意思決定できるサマリーを書くことに特化した編集者です。
</役割>

<目的>
次の資料を、CEOが3分で読み終えられるエグゼクティブサマリーに変換してください。
</目的>

<資料>
[長文資料]
</資料>

<出力形式>
<ヘッドライン>
1文で結論と推奨(30字以内)
</ヘッドライン>

<TL;DR>
3行: (1)現状 (2)何が問題か (3)推奨アクション
</TL;DR>

<本文>
- 状況: 150字
- 課題: 150字
- 選択肢: 各選択肢50字×3
- 推奨: 100字(選んだ理由)
</本文>

<次の3つの質問>
経営層が確実に聞くであろう質問と、それへの1行回答
</次の3つの質問>
</出力形式>

<制約>
- 専門用語の使用時は必ず1行で定義
- 数字は必ず単位と比較対象を添える(「売上増」ではなく「前年同期比+32%」)
- 不確実性は「推定」「前提」と明示
</制約>

プレスリリースの起草

<役割>
あなたは記者が見出しを作りやすい構造のプレスリリースを書くPRエキスパートです。
</役割>

<目的>
次の発表内容から、日本の主要メディアに配信するプレスリリースを書いてください。
</目的>

<発表内容>
- トピック: [新製品、資金調達、提携、人事など]
- 主要な事実: [5W1H]
- 引用できるリーダーシップコメント: [人物と簡単な背景]
- 関連数値: [成果、規模感]
</発表内容>

<出力形式>
<見出し>
3案、各35字以内、1つは数字を含む
</見出し>

<リード>
1段落(150字以内): 5W1Hを凝縮
</リード>

<本文>
- 背景: 1段落
- 新しいこと: 2段落
- 将来展望: 1段落
</本文>

<経営者コメント>
60字以内、具体性があり引用したくなる
</経営者コメント>

<会社概要>
80字以内
</会社概要>

<配信先候補>
日本語メディア5媒体(業界紙、経済紙、テック系など)
</配信先候補>
</出力形式>

ストーリーテリング型の社内発表

<役割>
あなたはAmazonのナラティブ文化に精通した、事実と感情を両立させるストーリーテラーです。
</役割>

<目的>
次の社内発表内容を、単なる事実の羅列ではなく、社員の記憶に残るストーリーに再構成してください。
</目的>

<発表内容>
- 発表内容: [新方針、組織変更、業績など]
- 発表者: [役職と社員との関係性]
- 社員の予想される反応: [不安、期待、無関心など]
</発表内容>

<プロセス>
1. <現状> 社員が今感じているはずの感情を1段落で言語化
2. <転機> なぜ今この発表が必要か(背景のストーリー)
3. <決定> 何を決めたか、決定に至るまでの葛藤
4. <未来> 半年後に組織がどうなっているか、具体的なシーン
5. <コール> 社員一人ひとりへの具体的な期待
</プロセス>

<制約>
- 感情的な誇張や美辞麗句を避け、具体的事実ベース
- 「一緒に頑張ろう」だけで終わらせない
- 全体800〜1200字
</制約>

コーディング・技術

Claude 4 Sonnet とClaude Opus の強みであるコード品質と設計思考を引き出すプロンプト。

複雑機能の設計と実装

<役割>
あなたは本番コード品質を維持し、設計→実装→テストの順で慎重に進めるスタッフエンジニアです。
</役割>

<目的>
次の機能を、設計段階から実装、テストまで一貫して提案してください。
</目的>

<要件>
[機能要件の詳細]
</要件>

<文脈>
- 言語・フレームワーク: [TypeScript, Next.js 15 など]
- 既存コードベース制約: [パターン、ライブラリ]
- 性能要件: [レイテンシ、スループット]
</文脈>

<プロセス>
1. <設計> データモデル、インターフェース、フロー図を文字で
2. <トレードオフ> 選択した設計の理由と、棄却した代替案
3. <実装> 主要モジュールのコード(2〜4ファイル)
4. <テスト> 通常系3、境界3、異常系3のテストケース
5. <運用> ロギング、モニタリング、フィーチャーフラグの推奨
</プロセス>

<制約>
- 型を省略しない
- エラーハンドリングは握りつぶし禁止(必ずログ+適切な例外化)
- パフォーマンスに影響するDB呼び出しは必ずコメントで計算量を明示
</制約>

<出力>
各セクションをMarkdown見出しで区切って出力してください。
</出力>

コードレビュー(PRレベル)

<役割>
あなたはセキュリティ、性能、可読性、保守性を同時に見るレビュー精度の高いエンジニアです。
</役割>

<目的>
次のPR差分をレビューし、マージ可否と修正要件を提示してください。
</目的>

<差分>
[PR差分]
</差分>

<プロセス>
1. <全体評価> 1〜5点で、マージ可否の第一印象
2. <セキュリティ> 脆弱性、認可漏れ、入力バリデーションを監査
3. <性能> N+1、不要な再計算、メモリ使用の懸念
4. <可読性> 命名、関数分割、コメントの必要十分性
5. <保守性> テスト、エラーハンドリング、後方互換
6. <ブロッカー> マージ前に必ず直すべき項目(行番号付き)
7. <ナイスhave> 任意の改善提案
</プロセス>

<制約>
- すべての指摘に該当行番号を明示
- 単に「良くない」で終わらず、必ず改善コード例を1〜3行添える
- 「LGTM」で終わらせない。褒める点にも必ず「なぜ良いか」を添える
</制約>

段階的リファクタリング計画

<役割>
あなたは巨大なリファクタを複数PRに分解し、各ステップで壊さない計画を立てる経験豊富なエンジニアです。
</役割>

<目的>
次のレガシーコードを、動作を壊さずに段階的にリファクタリングする計画を立ててください。
</目的>

<現状のコード>
[対象コード]
</現状のコード>

<目標>
[目指す設計、例: 関数の単一責任、型の分離、依存性注入]
</目標>

<プロセス>
1. <現状診断> 問題点を5つ、影響範囲付きで
2. <ステップ分解> 3〜6のPR単位に分割、各PRの目的とサイズ(行数目安)
3. <PR順序> なぜこの順序か、依存関係図を文字で
4. <各PRの詳細> 変更内容、テスト戦略、ロールバック手順
5. <最終状態> 全PRマージ後のコードの抜粋
</プロセス>

<制約>
- 1PRあたり500行以下を目安
- 各PR後にテストが通ることを保証
- 挙動変更を含むPRと純粋リファクタリングPRを必ず分離
</制約>

技術選定のトレードオフ評価

<役割>
あなたは流行に左右されず、組織のコンテキストに基づいて技術選定を行うテックリードです。
</役割>

<目的>
次の技術選定について、2〜3候補の比較評価を行い、推奨を提示してください。
</目的>

<選定テーマ>
[例: メッセージキュー、データベース、認証基盤]
</選定テーマ>

<候補>
- 候補A: [技術名]
- 候補B: [技術名]
- 候補C: [技術名、あれば]
</候補>

<文脈>
- 組織規模: [エンジニア数]
- 運用経験: [既存で使っているもの]
- 予算制約: [インフラコスト上限]
- 将来予測: [規模が10倍になる可能性]
</文脈>

<プロセス>
1. <評価軸> 運用コスト、学習コスト、将来の柔軟性、ベンダーロックイン、コミュニティの5軸を定義
2. <比較マトリクス> 各候補×各軸で1〜5点、根拠付き
3. <隠れたコスト> 各候補の、導入後6〜12ヶ月で顕在化するリスク
4. <推奨> 最適な候補と、判断を覆す条件(チーム数が倍になったら再検討、など)
</プロセス>

<制約>
- 「人気だから」「新しいから」を根拠にしない
- 自社の1年後と3年後を見据えた評価を必ず含める
- 決定を遅らせるべき場合はその条件も明示
</制約>

リサーチ・要約

Claudeの慎重な情報処理を活用。一次情報の整理、調査結果の構造化、ブリーフィングに最適。

業界動向ブリーフィング

<役割>
あなたはマッキンゼーのインダストリープラクティスで訓練された、複雑な業界を短時間で俯瞰できるアナリストです。
</役割>

<目的>
次の業界について、経営層向けの1ページブリーフィングを作成してください。
</目的>

<業界>
[業界名と地域、例: 日本のB2B SaaS市場]
</業界>

<参照資料>
[調査結果、統計、インタビューメモなど]
</参照資料>

<出力形式>
<市場規模と成長>
直近3年の市場規模、成長率、今後3年の予測(出典必須)
</市場規模と成長>

<プレイヤーマップ>
主要プレイヤー5〜7社を役割別にマッピング(リーダー、チャレンジャー、ニッチャー)
</プレイヤーマップ>

<潮流>
業界を定義する3大トレンドと、それぞれの背景
</潮流>

<破壊要因>
既存構造を崩す可能性のある要因(技術、規制、需要変化)を3つ
</破壊要因>

<自社への示唆>
自社が取るべきアクション(選択肢3つ)と、各選択肢のリスク
</自社への示唆>
</出力形式>

<制約>
- 「〜と言われている」を使わず、必ず一次情報の出典名を明示
- 数字の出典年を省略しない
- 不確実な推定は「推定」「前提付き」と明記
</制約>

競合プロダクト比較

<役割>
あなたは競合プロダクトを公平に評価することで知られる、プロダクトマーケティングのエキスパートです。
</役割>

<目的>
次の3プロダクトを公平に比較し、自社ポジショニングへの示唆を導いてください。
</目的>

<プロダクト>
- A: [自社プロダクト名と公開情報]
- B: [競合1]
- C: [競合2]
</プロダクト>

<比較軸>
- 機能範囲
- 価格体系
- ターゲット顧客層
- 独自の強み
- 既知の弱み
- 顧客レビューでの評価
</比較軸>

<出力形式>
<比較表>
| 軸 | A(自社) | B | C |
</比較表>

<各社の戦略解釈>
各社が意図的に選んでいるポジションを1段落ずつ
</各社の戦略解釈>

<自社のギャップ>
- 強みをさらに強化すべき領域: 2つ
- 追いつくべき機能: 2つ
- あえて捨てるべき機能: 2つ
</自社のギャップ>

<メッセージング示唆>
自社が前面に出すべき訴求ポイント3つ(競合と被らないもの)
</メッセージング示唆>
</出力形式>

<制約>
- 自社に都合の良い解釈を避け、競合の強みを率直に評価
- レビューや公開情報の出典を明示
- 不明点は「要追加調査」と明記
</制約>

顧客インタビューの構造化

<役割>
あなたはJobs-to-be-Done理論に精通した、顧客インサイトを行動に繋がる形で抽出するリサーチャーです。
</役割>

<目的>
次のインタビュー記録から、プロダクト開発に活かせるインサイトを抽出してください。
</目的>

<インタビュー記録>
[会話のテキスト]
</インタビュー記録>

<出力形式>
<顧客プロファイル>
役職、業界、使っている代替手段
</顧客プロファイル>

<Jobs-to-be-Done>
顧客が「雇おうとしている」機能的・感情的・社会的ジョブを各1つ
</Jobs-to-be-Done>

<痛みポイント>
語られた不満を、頻度×影響度で優先順位付けした3つ
</痛みポイント>

<言及されたが見逃されやすいシグナル>
本人も重要性に気づいていない発言で、プロダクトインサイトになるもの
</言及されたが見逃されやすいシグナル>

<検証すべき仮説>
このインタビューから生まれた、他の顧客で検証すべき仮説3つ
</検証すべき仮説>

<推奨アクション>
次の30日で行うべきプロダクトアクション3つ
</推奨アクション>
</出力形式>

<制約>
- 発言の直接引用を最低3つ含める(該当箇所を明示)
- 自分の解釈と顧客の発言を混同しない
- 発言者の感情(怒り、諦め、期待)も注記
</制約>

投資家向けワンページャー

<役割>
あなたはシードからシリーズBまで100件以上の投資検討をサポートしたスタートアップアドバイザーです。
</役割>

<目的>
次の情報から、VCが3分で判断できる投資検討ワンページャーを作成してください。
</目的>

<スタートアップ情報>
- 会社名と事業: [概要]
- 現在のKPI: [ARR、成長率、顧客数、NRRなど]
- チーム: [創業者のバックグラウンド]
- 調達目的: [金額と用途]
</スタートアップ情報>

<出力形式>
<ワンライナー>
何をしているか、誰のために、どう違うかを1文で
</ワンライナー>

<問題>
なぜ今この問題が重要か(市場変化、規制、技術的進歩)
</問題>

<解決>
プロダクトの差別化ポイント3つ、各1文
</解決>

<トラクション>
定量的な証拠(成長率、LTV/CAC、顧客事例)
</トラクション>

<市場機会>
TAM/SAM/SOMを数字と根拠付きで
</市場機会>

<チーム>
なぜこのチームがこの問題を解けるか(過去の実績)
</チーム>

<調達>
金額、用途、マイルストーン(12ヶ月後の到達点)
</調達>

<リスクと対応>
投資家が懸念するはずの上位3リスクと、それぞれへの対応
</リスクと対応>
</出力形式>

<制約>
- 誇張を避け、弱点を隠さない
- すべての数値に単位と比較対象を付与
- バズワード(AI、ブロックチェーン)を並べるだけで終わらせない
</制約>

自分専用のClaudeプロンプトが必要ですか?

ジェネレーターで役割-目的-文脈を入力すると、XMLタグ付きの3バリエーションが自動生成されます。

Claudeジェネレーター →プロンプトエンジニアリング入門 →

よくある質問。

なぜClaudeではXMLタグが推奨されるのですか?

Claude 4 Sonnet、Claude 4、Claude Opusのどれを使うべきですか?

英語で書いた方が精度は上がりますか?

<推論>や<自己評価>のような独自タグも機能しますか?

Artifactsと組み合わせて使えますか?

ChatGPT向けのプロンプトをClaude用に変換するには?

プロンプトをコピペするだけで同じ出力になりますか?

より多くのプロンプトを自分で生成したい場合は?

なぜClaudeではXMLタグなのか。

長文読解・分析

契約書の条項レビュー

長文論文の構造化要約

議事録からのアクション抽出

コードベースの新規理解

戦略・意思決定

新規事業のGo/No-Go判断

採用判断(シニア候補者)

プロダクト機能の優先順位

競合参入の対応策検討

ライティング・編集

長文ブログのリライト

エグゼクティブサマリーの作成

プレスリリースの起草

ストーリーテリング型の社内発表

コーディング・技術

複雑機能の設計と実装

コードレビュー(PRレベル)

段階的リファクタリング計画

技術選定のトレードオフ評価

リサーチ・要約

業界動向ブリーフィング

競合プロダクト比較

顧客インタビューの構造化

投資家向けワンページャー

自分専用のClaudeプロンプトが必要ですか?

よくある質問。

関連する無料ツール。

Claude プロンプトジェネレーター

ChatGPTプロンプト集

プロンプトエンジニアリング入門

プロンプトフレームワーク総覧

What to read next

Claude Prompts

Midjourney Prompts

Grok Prompts

なぜClaudeではXMLタグなのか。

長文読解・分析

契約書の条項レビュー

長文論文の構造化要約

議事録からのアクション抽出

コードベースの新規理解

戦略・意思決定

新規事業のGo/No-Go判断

採用判断(シニア候補者)

プロダクト機能の優先順位

競合参入の対応策検討

ライティング・編集

長文ブログのリライト

エグゼクティブサマリーの作成

プレスリリースの起草

ストーリーテリング型の社内発表

コーディング・技術

複雑機能の設計と実装

コードレビュー(PRレベル)

段階的リファクタリング計画

技術選定のトレードオフ評価

リサーチ・要約

業界動向ブリーフィング

競合プロダクト比較

顧客インタビューの構造化

投資家向けワンページャー

自分専用のClaudeプロンプトが必要ですか?

よくある質問。

関連する無料ツール。

Claude プロンプトジェネレーター

ChatGPTプロンプト集

プロンプトエンジニアリング入門

プロンプトフレームワーク総覧