マーケター・デザイナーのための Claude Code プロンプトテンプレート集(資料制作・コピー・LP・企画書・競合分析)

監修者_SD以外

監修者プロフィール

森下浩志

日本最大級のAI情報プラットフォーム「romptn ai」編集長。著書に「0からはじめるStable Diffusion」「0からはじめるStable Diffusion モデル・拡張機能集編」など、AmazonベストセラーのAI関連書籍を多数執筆。AIにおける情報の非対称性を解消するための社内研修や出張講義も行う。

非エンジニアにも Claude Code が効く理由

ここから本記事の最初のテーマである「Claude Code が非エンジニアの業務にも刺さる理由」を整理します。

Claude Code に短い指示を貼り付けるだけで、LP のキャッチコピーを30案、SEO 用の構成案、1 枚企画書、競合 5 社のサマリ表まで、マーケターやデザイナーの定番業務をひと続きで下書きまで持っていけます。背景にあるのは、Claude Code の中身が文章生成に強い言語モデルであり、開発支援ツールであると同時に 長文・構成・推敲を任せられる文章エンジン だという事実です。

そのため、技術記事で見るような「コードレビュー」「リファクタリング」「テスト生成」の用途は本記事では扱いません。本記事で扱うのは、記事ライティング下書き・SEO コンテンツ構成・キャッチコピー・LP 文言・企画書・競合分析サマリという、マーケター/デザイナー/編集者が日常的に手を動かす 業務文書系の6タスク に絞ったプロンプトテンプレート集です。ターミナル操作や CLI フラグの解説は前面に出しません。

「自分には関係ない」と感じていた方ほど、本記事のテンプレートはそのままコピペで使い始められます。次の章で、まず必要最小限の前提だけを揃えていきます。

この記事で使う Claude Code の最低限の前提

ここからは、本記事のテンプレートを使うために必要な「最低限の前提」だけを揃えます。詳細な導入手順や設定項目には踏み込みません。

テンプレートはどれも、Claude Code のチャット欄(プロンプト入力欄)にそのまま貼り付ける形で動きます。お手元の環境で Claude Code が起動できる状態であれば、その先のテンプレートは 全て同じ手順で「貼って→必要箇所を書き換えて→送る」だけ です。

本記事ではあえてターミナルでのコマンド操作や細かな設定オプションには触れません。Claude Code をはじめて触る場合や、まだインストールが終わっていない場合は、社内エンジニア・情シスに「文章作業で使いたい」と伝えて初期設定を済ませてから戻ってきていただくのがスムーズです。導入手順だけを丁寧に扱う別記事は、編集者が後から内部リンクとして本記事に追加します。

もう一点だけ補足します。テンプレートは ChatGPT や Gemini にもほぼそのまま転用できますが、本記事は Claude Code 向けに最適化した文体・指示の置き方で組み立てています。他ツールに移植する際は、トーンや表現の制約だけ書き換えてご利用ください。

次の章から、すべてのテンプレートが共通で従う「前提・制約・出力形式の三分割フレーム」を整理します。

業務プロンプトの共通フレーム

ここからは、本記事の全テンプレートが共通で従う「前提・制約・出力形式」という3分割の設計フレームを整理します。

プロンプトの品質がばらつく主な理由は、依頼文に 何を書き、何を書かないか の置き場所が決まっていないことです。長文の依頼文を一発で投げる書き方では、AI 側が「どこが守るべき制約で、どこが背景情報か」を解釈で埋めるため、出力が毎回ぶれます。

このぶれを抑える最短ルートが、依頼文を「前提・制約・出力形式」の3ブロックに分けて書くことです。本記事のテンプレートは全てこの3ブロックを最初から区切った状態で並んでいるので、読者が自分の業務に合わせて書き換えるべき位置を迷わずに見つけられます。

次の3つの観点で、それぞれのブロックに何を書くかを順に整理します。

① 前提に書くこと

「前提」は、依頼の 背景情報 を置くブロックです。AI が出力を組み立てる前に知っておくべき固定条件を、ここにまとめます。

具体的には、次のような情報を書きます。

前提ブロックは、テンプレート各章で 読者が真っ先に書き換える場所 です。同じテンプレートでも、前提を入れ替えれば全く別の案件に転用できます。

書き換えの粒度に迷ったときは「この前提を変えると、出力が変わるべきか」を基準にしてください。変わるなら前提に書き、変わらないなら制約に書きます。

② 制約に書くこと

「制約」は、出力に対する 守るべきルール を置くブロックです。前提が変わっても残る、案件横断のお作法をここに集約します。

書く内容は、次のようなものが中心です。

制約ブロックは、出力ばらつきを抑え、ブランドのトーンを保つ役割 を担います。同じ前提でも、制約を変えれば出力の表情が大きく変わります。

もう一つの使い方が、過去の失敗を制約に書き戻すことです。「以前『便利』『最高』を多用しすぎたから禁止する」のように、自分の現場で出た反省点を制約に蓄積していくと、テンプレートが自社専用に磨かれます。

③ 出力形式に書くこと

「出力形式」は、AI から戻ってくる 成果物の形 を指定するブロックです。書く内容は中身ではなく、構造とレイアウトに限定します。

指定するのは、次のような項目です。

出力形式が決まっていると、戻ってきた文章を そのまま社内資料や入稿ツールに貼り付けやすく なります。マーケター・デザイナーがプロンプトで時間を溶かしがちな「形を整え直す手間」を、最初の指示でゼロに寄せていく考え方です。

テンプレート章で出てくる出力形式は、業務ごとに「使いやすい形」をあらかじめ組み込んでいます。慣れてきたら自分のチームの提出フォーマットに合わせて書き換えてください。

記事ライティング下書きのテンプレート

ここからは業務6タスクの1つめ、記事ライティングの下書き工程を Claude Code に任せるためのテンプレートを2つ紹介します。

編集者やコンテンツ担当が最も繰り返す作業がここに集まるため、本章を最初に置きました。テンプレートは「本文をまるごとドラフトする型」と「既存記事をリライトする型」の2本立てで、どちらも前提・制約・出力形式の3ブロックで構成されています。次の章でそれぞれの中身を確認してください。

メイン:本文ドラフト生成

見出し構成と方向性を貼り付けて、各章の本文ドラフトをまとめて作るテンプレートです。

下の枠内を Claude Code にそのまま貼り、角括弧 [...] の箇所だけ自分の案件の値に書き換えてください。括弧内の「例:」は記入例なので、本番ではご自身の情報に置き換えます。

# 前提
- 媒体: [媒体名](例: 中小企業の経営者向け B2B SaaS の自社オウンドメディア)
- 想定読者: [読者像](例: 営業 DX に関心のある中堅企業の事業責任者)
- テーマ: [今回扱うテーマ](例: 営業日報の AI 活用)
- すでに決まっている方向性: [リード文の主張・ベネフィット](例: 営業日報を AI 要約に切り替えると、マネージャーの確認時間が週 3 時間減る)
- 参考にする見出し構成:
  - H2: [H2 タイトル]
    - H3: [H3 タイトル]
    - H3: [H3 タイトル]
  - H2: [H2 タイトル]
# 制約
- 文体はですます調で統一する
- 一文 80 文字以内、1 段落は 2〜3 文に区切る
- 「いかがでしたか」「〜と思われます」などの曖昧表現は使わない
- 各 H2 の本文は 400〜600 文字を目安にする
- 数字を書く時は出典の有無も併記する(出典がなければ「社内推計」と注記)
# 出力形式
- 与えた見出しの順番どおりに、H2 / H3 ごとに本文を書く
- 各 H2 の冒頭に「この章の結論」を 1〜2 文で先出しする
- 箇条書きが向いている箇所は積極的に箇条書きにする
- 章ごとの本文末尾に、編集確認用メモを 1 行(例: 「数字の出典差し込みが必要」)添える

書き換える場所は「前提」のブロックに集中しています。媒体・読者・テーマ・主張・見出し構成を入れ替えれば、別案件でもそのまま再利用できます。

派生:既存記事のリライト

既存の自社記事を貼り付け、改善版を作るためのテンプレートです。新規執筆ではなく、社内のリライト案件で使います。

# 前提
- 媒体: [媒体名](例: B2B マーケ向け自社オウンドメディア)
- 対象記事タイトル: [既存記事のタイトル]
- 現状の課題: [課題](例: 直帰率が高い / 構成が古い / 主訴求がぼやけている)
- リライトの狙い: [狙い](例: 検索意図のずれを解消し、CV 導線を強化する)
- 元記事の本文:
  """
  [本文をここに貼り付ける]
  """
# 制約
- 元記事の強み(独自データ・体験談・固有の言い回し)は残す
- 数値・固有名詞は元記事の表記を踏襲する
- リライトで削除する場合は必ず理由を明記する
- 文体はですます調で統一する
# 出力形式
- 各章ごとに「変更前 / 変更後 / 変更理由」の3点セットで出す
- 表形式(列: H2 タイトル / 変更前要旨 / 変更後要旨 / 変更理由)で全体を見渡せる一覧を最初に出す
- 全体構成の入れ替え提案がある場合は、その新構成を H2 / H3 一覧で先出しする
- 元記事から残す箇所には「残す」と明記する

貼り付け対象が長い場合は、章ごとに分けて投げ、戻ってきた変更案をマージすると安定します。元記事に強みがある時は、その強みを 「制約」ブロックに『残す』として明記しておく と削られにくくなります。

SEO コンテンツ構成のテンプレート

ここからは業務6タスクの2つめ、SEO コンテンツの構成案を Claude Code に出させるテンプレートを2つ紹介します。

キーワードと想定読者から構成案を作る型と、上位記事の見出しを踏まえて差別化軸を出す型に分けています。記事執筆に入る前段の「どんな H2 / H3 を並べるか」を決めるフェーズで、毎回ゼロから組み直していた工程を半自動化することが狙いです。

メイン:検索意図ベース構成案

対象キーワードと想定読者を入力し、検索意図に沿った H2 / H3 構成案を作るテンプレートです。

# 前提
- 対象キーワード: [メインキーワード](例: 営業日報 AI)
- サブキーワード: [サブキーワード](例: 営業日報 自動化 / 営業日報 ChatGPT)
- 想定読者: [読者像](例: 中堅企業の営業マネージャー、AI ツール導入の社内提案担当)
- 検索意図タイプ: [Do / Know / Compare のいずれか](例: Compare 寄りの Do)
- 既に書く方針が決まっている主張: [主訴求](例: 日報 AI は要約より「翌日アクションへの引き継ぎ」に効く)
- 既存の自社関連記事: [関連記事タイトル一覧]
# 制約
- 検索意図に対して「答えを最短で出す」順序を取る
- 同じテーマを 2 つの H2 に分けない(重複させない)
- 各 H2 の数は 6〜8 件、まとめを除く
- 「いかがでしたか」「まとめると」だけの薄い章は作らない
- 上位記事の見出しを丸ごとなぞらない(白地を 1〜2 件は入れる)
# 出力形式
- H2 / H3 のツリー形式で構成案を出す
- 各 H2 / H3 の右側に「この章で答える検索者の問い」を 1 行で添える
- 章ごとに「中心ワード(本文で必ず使うキーワード)」も列挙する
- 想定読了時間も合わせて出す(例: 8 分)
- 構成案の末尾に「上位記事との差別化ポイント」を 2〜3 行でまとめる

キーワードと検索意図タイプは前提ブロックの先頭に固定で置きました。読者層が変わったときは、ここを書き換えるだけで構成案の出方が大きく変わります。

派生:競合構成との差分

上位記事の見出しを貼り、自社が取りに行く差別化軸を出すためのテンプレートです。

# 前提
- 対象キーワード: [メインキーワード]
- 想定読者: [読者像]
- 自社の強み: [強み](例: 自社独自の導入事例データ / 担当者の現場体験)
- 競合上位の見出し一覧:
  - 競合 A:
    - H2: [見出し]
    - H2: [見出し]
  - 競合 B:
    - H2: [見出し]
    - H2: [見出し]
  - 競合 C:
    - H2: [見出し]
# 制約
- 競合の H2 を丸ごとなぞらない
- 競合に無い角度(白地)を 2〜3 件は必ず提案する
- 自社の強みを活かせる章を最低 1 件は組み込む
- 同じテーマを別の言い回しで再掲しない
# 出力形式
- 表形式で出す(列: 自社で採用する H2 / 競合に同じ章があるか / 採用理由 / 自社の強みとの紐付け)
- 表の前に「全体構成の骨子」を 5 行以内のサマリで示す
- 競合になく自社で取りに行く H2 には「白地候補」と注記を付ける
- 採用しなかった競合 H2 がある場合は「不採用理由」を箇条書きで出す

「自社の強み」を前提ブロックにきちんと書くと、差別化軸の精度が大きく変わります。漠然とした強みではなく、具体的な事例・データ・体験 を 1〜2 行で書き入れるのがコツです。

キャッチコピー作成のテンプレート

ここからは業務6タスクの3つめ、商品・サービス・キャンペーン向けのキャッチコピー作成のテンプレートを2つ紹介します。

誰に・何を・どう響かせるかをコピーで表現するためには、ターゲット設定とベネフィットの整理が前提として必要です。次の章では、ゼロからコピーを量産する型と、確定済のコピーから A/B テスト用のバリエーションを派生させる型を順に提示します。

メイン:キャッチコピー量産

商品・サービスのキャッチコピーを一気に量産するためのテンプレートです。

# 前提
- 商品 / サービス名: [商品名]
- 主な機能: [機能の要約]
- 想定読者: [読者像](例: 中小企業の総務担当 / 子育て中の働く女性)
- 想定シーン: [どんな場面で目にするコピーか](例: SNS 広告 / LP の FV / 営業資料の表紙)
- ベネフィット候補:
  - [ベネフィット 1](例: 月末締めの工数が 30% 減る)
  - [ベネフィット 2](例: 上司への報告が「ボタン 1 つ」で終わる)
  - [ベネフィット 3](例: 残業を増やさず正確な数字を出せる)
- 主訴求: [どのベネフィットを軸にするか](例: ベネフィット 2)
# 制約
- 文体は親しみ寄りのですます調(ただし語尾は柔らかすぎない)
- 1 案の文字数は 13〜25 文字
- 「最高」「No.1」「絶対」など根拠の取りにくい強表現は使わない
- 否定形より肯定形を優先する
- 30 案を出し、似ているものを重複として落とす
# 出力形式
- 表形式で出す(列: 案番号 / コピー本文 / 訴求軸 / ターゲット感情 / 想定シーン)
- 30 案を「事実訴求 / 感情訴求 / 質問形 / 比喩形 / 数字訴求 / 体験談形」の 6 パターンに分けて 5 案ずつ並べる
- 末尾に「自分なら採用するベスト 3」を理由付きで出す

コピーは ベネフィット候補の解像度 で 8 割が決まります。漠然と「便利になる」ではなく、「いつ・誰の・どんな手間が・どれだけ減るか」を 3 件以上挙げてから前提に流し込んでください。

派生:A/B テスト用バリエーション

確定済の主コピーから、A/B テスト用のバリエーションを派生させるテンプレートです。

# 前提
- 商品 / サービス名: [商品名]
- 主コピー: [主コピーの本文](例: 営業日報、もう書かない。)
- 主コピーの訴求軸: [何を訴求しているか](例: 作業の削減)
- 想定読者: [読者像]
- 想定掲載面: [どこで使うか](例: 広告 / LP / 営業資料)
- 伝えたい価値の優先順位:
  1. [優先 1](例: 工数削減)
  2. [優先 2](例: ミス削減)
  3. [優先 3](例: チーム共有のしやすさ)
# 制約
- 主コピーは絶対に変更しない(あくまで派生案を出す)
- 派生案は訴求軸を変えるのが目的(語尾だけ変えるのは NG)
- 1 案の文字数は主コピー ±5 文字以内に収める
- 価格・煽り表現は使わない
# 出力形式
- 表形式で出す(列: 案番号 / 訴求軸 / コピー本文 / 主コピーとの差分要約 / おすすめ掲載面)
- 訴求軸ごとに 3 案ずつ、合計 9 案を出す
- 末尾に「主コピーと組ませた時に最も訴求差が大きい案」を 2 案ピックして理由を添える

派生案で迷ったときは 主コピーから訴求軸だけを 1 つだけ動かす のがコツです。語尾や言い回しだけを変えても A/B テストの差分が見えにくくなります。

LP 文言ドラフトのテンプレート

ここからは業務6タスクの4つめ、LP(ランディングページ)に並べる文言をドラフトするテンプレートを2つ紹介します。

ワイヤーは引けても文言を埋める段階で手が止まる、というデザイナー側の詰まりを解くことが狙いです。次の章では、ファーストビューから CTA まで LP のセクション別文言をまとめてドラフトする型と、すでに公開済の LP を読み込ませて改善提案を出させる型を順に提示します。

メイン:LP セクション別文言

FV(ファーストビュー)から CTA まで、LP のセクション別文言を一気にドラフトするテンプレートです。

# 前提
- 商品 / サービス名: [商品名]
- 主な機能: [機能の要約]
- 想定読者: [読者像](例: 月50時間以上の手作業集計に追われる中小企業の経理担当)
- 主訴求(LP 全体で一番伝えたい価値): [主訴求](例: 月末締めの集計時間を 1/3 にする)
- 比較対象 / 代替案: [読者が今やっていること](例: Excel での手入力集計 / 旧来の会計ソフト)
- 想定アクション: [読者に取ってほしい行動](例: 14 日間の無料トライアル申し込み)
- 価格 / 提供条件: [プラン名と金額・主要条件](例: スターター 9,800 円 / 月、年間契約)
# 制約
- 文体は親しみ寄りのですます調(ただし語尾は柔らかすぎない)
- 「業界最高水準」「絶対に」など根拠の取りにくい強表現は使わない
- 否定形より肯定形を優先する
- 同じベネフィットを 2 つ以上のセクションで重複させない
- FV のキャッチコピーは 13〜25 文字、サブコピーは 40〜60 文字に収める
- ボディコピー段落は 80 文字以内・2〜3 文に区切る
# 出力形式
- 以下のセクション順に、それぞれの文言案を出す
  1. ファーストビュー(キャッチコピー / サブコピー / CTA ボタンラベル)
  2. 課題提起(読者の現状の困りごとを 3 点)
  3. 解決の提示(主訴求を 1 文 + その根拠 2〜3 行)
  4. 機能紹介(主要機能 3 つ × 1 機能あたり 見出し + 説明 60 文字)
  5. 導入効果(数字で言える効果 2〜3 件、出典がなければ「自社調べ」と注記)
  6. お客様の声(想定ペルソナ 2 件 × 短いコメント 50 文字)
  7. 料金プラン(プラン名 / 金額 / 含まれる機能を表形式で)
  8. よくある質問(代表質問 3 件 + 回答 60 文字)
  9. クロージング(主訴求の再提示 + 最終 CTA ボタンラベル)
- 各セクションの先頭にセクション名をラベル表記する
- 案が複数浮かぶ場合は、各セクションで 2 案ずつ並べる
- 末尾に「FV と クロージングの整合チェック」を 2〜3 行で添える

前提ブロックの「主訴求」と「想定アクション」が LP 全体の軸になります。ここを 1 つに絞り切ってから流し込むと、FV からクロージングまで主張がぶれずに揃った文言が返ってきます。

派生:既存 LP の改善提案

既に公開している LP を読み込ませ、セクション別の改善提案を出させるテンプレートです。新規制作ではなく、運用中 LP の改善案件で使います。

# 前提
- 商品 / サービス名: [商品名]
- 想定読者: [読者像]
- 主訴求(変えたくない場合は明記する): [主訴求]
- 現状の課題: [課題](例: 直帰率が高い / FV のクリック率が低い / 申し込みフォームまで読まれていない)
- 改善で達成したいゴール: [ゴール](例: CTA クリック率を 1.5 倍 / フォーム到達率を 1.2 倍)
- 既存 LP の本文:
  """
  [LP の文言を上から下まで貼り付ける]
  """
# 制約
- ブランドトーン・商品名・主訴求は変更しない
- 数値・固有名詞は元 LP の表記を踏襲する
- 削除提案には必ず理由を明記する
- 文体はですます調で統一する
- 「もっと魅力的に」のような曖昧な改善提案は出さない(必ず仮説と狙いを書く)
# 出力形式
- 全体サマリを表形式で先出しする(列: セクション名 / 現状の弱み / 主な改善方針)
- 各セクションごとに「変更前(原文の要点) / 変更後(具体的な文言案) / 変更理由」の3点セットで出す
- ファーストビュー・CTA まわりは優先度を「高」と注記する
- ゴールに対して効きそうな順に並べる
- 末尾に「現状のままで残すべき箇所」を 2〜3 点ピックして理由を添える

貼り付ける LP が長い場合は、FV から CTA までセクション単位で分割して投げると精度が安定します。「変えたくない要素」と「ゴール」を前提ブロックに明記しておくと、ブランドトーンを保ったまま狙った数値を動かす提案が出やすくなります。

企画書ドラフトのテンプレート

ここからは業務6タスクの5つめ、社内会議や上司への提案で使う企画書のドラフトを Claude Code に任せるテンプレートを2つ紹介します。

アイデアはあるのに体裁の整った企画書にする工数で止まってしまう、というマーケターや編集者の詰まりを解くことが狙いです。次の章では、目的・背景・施策・効果までを 1 枚にまとめる定番フォーマットの型と、すでに書いた企画書を読み込ませて穴を埋める型を順に提示します。

メイン:1枚企画書

社内会議で配る A4 1 枚の企画書を、定番フォーマットでドラフトするためのテンプレートです。

# 前提
- 企画タイトル(仮): [タイトル]
- 企画の目的: [目的](例: 新規リードを四半期で 1.3 倍にする)
- 背景 / 課題: [課題](例: 既存メディアの直帰率が高く、見込み客の名刺獲得が頭打ち)
- 提案する施策: [施策の概要](例: 業務テンプレ集を軸にしたゲート付きホワイトペーパー導入)
- 想定読者(企画書を読む人): [読み手](例: マーケ部長 / 経営会議メンバー)
- 既知の制約: [予算・期間・人員などの制約](例: 予算 100 万円以内 / 制作期間 6 週間)
- 想定スケジュール: [大まかな期間](例: 立ち上げ 2 週間 + 運用 8 週間)
# 制約
- A4 1 枚に収まるボリュームに圧縮する(全体 800〜1,000 文字を目安)
- 文体は「です・ます」混在を避け、体言止め + 簡潔な文を中心にする
- 「絶対」「必ず」など根拠の取りにくい強表現は使わない
- 数字を書く時は出典の有無も併記する(出典がなければ「社内推計」と注記)
- 主張に対しては必ず根拠を 1 行添える
# 出力形式
- 以下のセクション順に出す
  1. 企画タイトル(15 文字以内)
  2. エグゼクティブサマリー(80 文字以内、結論を 1 文で)
  3. 背景・課題(箇条書き 3 点)
  4. 提案する施策(主施策 + 補助施策の 2 段構え)
  5. 期待効果(数値目標 2〜3 件、出典を明記)
  6. 必要リソース(予算 / 期間 / 体制)
  7. リスクと対応(主要リスク 2 件 + それぞれの対応策)
- 各セクションの右側に想定の本文文字数(目安)を併記する
- 末尾に「会議で最初に聞かれそうな質問」を 3 件、想定回答付きで添える

「期待効果」のセクションが企画書の説得力を決めます。前提ブロックで 目的を 1 行で言い切り、数値目標まで書き入れて から流し込むと、施策とのつながりが明瞭な企画書が返ってきます。

派生:既存企画のブラッシュアップ

既に書き上がった企画書を貼り、論理の穴や抜けている要素を指摘させ、改善案を出させるテンプレートです。会議直前の磨き込みや、上司に上げる前のセルフレビューで使います。

# 前提
- 企画タイトル: [タイトル]
- 企画の目的: [目的]
- 読み手: [読み手](例: 経営会議 / 営業部長 / 取引先)
- 重視する観点: [観点](例: 投資対効果 / 競合優位性 / 実行可能性)
- 変えたくない要素: [変えない要素](例: 主施策 / 想定予算)
- 既存の企画書本文:
  """
  [企画書をそのまま貼り付ける]
  """
# 制約
- 主施策・主目的・既存の主要数値は変更しない
- 削除提案には必ず理由を明記する
- 「もっと魅力的に」のような曖昧な改善提案は出さない(仮説と狙いを必ず添える)
- 文体・体裁は元の企画書に合わせる
- 出典の不明確な数値には「要出典」と注記する
# 出力形式
- 全体評価を 3 段階(問題なし / 補強が必要 / 大幅修正)で先頭に出す
- セクション別の指摘を表形式で出す(列: セクション名 / 指摘点 / 想定読み手の反応 / 改善後の文言案)
- 論理の飛躍がある箇所は「根拠不足」と注記する
- 抜けている観点があれば「追加推奨セクション」として末尾にまとめる
- 「想定質問への備え」を 3 件追加で出す(質問 + 想定回答)

読み手と重視する観点を 具体名で書き入れる と、指摘の方向性がはっきりします。例えば「経営会議 × 投資対効果」と「現場マネージャー × 実行可能性」では、同じ企画書でも指摘が変わります。前提ブロックでここを 1 つに絞り切ってから流し込んでください。

競合分析サマリのテンプレート

ここからは業務6タスクの6つめ、競合サービスや競合サイトの情報を 1 枚のサマリに整理する作業を Claude Code に任せるテンプレートを2つ紹介します。

各社のサイトを開いては別タブに行き、また戻って…という反復作業を圧縮するのが狙いです。次の章では、競合5社の特徴・強み・価格を表で並べるサマリ表の型と、そのサマリから自社のポジショニング所感を引き出す型を順に提示します。

メイン:競合 5 社サマリ表

競合 5 社の公開情報を 1 枚の比較表にまとめるためのテンプレートです。

# 前提
- 自社の商品 / サービス名: [商品名]
- 比較する競合一覧:
  - 競合 A: [社名・サービス名・公式 URL]
  - 競合 B: [社名・サービス名・公式 URL]
  - 競合 C: [社名・サービス名・公式 URL]
  - 競合 D: [社名・サービス名・公式 URL]
  - 競合 E: [社名・サービス名・公式 URL]
- 比較軸: [比較軸](例: 価格 / 主要機能 / 想定ターゲット / サポート体制)
- 整理の目的: [目的](例: 自社の差別化軸を探す / 価格改定の判断材料にする)
- 既知の前提: [前提](例: 海外サービスは円換算で揃える / 個人プランのみで比較する)
# 制約
- 公開情報のみを根拠にする(社内推測は別行で注記)
- 各セルの根拠 URL を併記する(取得日も書く)
- 不明な項目は「不明」と書き、適当な値で埋めない
- 為替・税込/税抜の扱いを揃える
- 「業界 No.1」のような自称コピーは事実として書かない
# 出力形式
- 縦軸を競合、横軸を比較軸にした表を出す
- 表の前に「比較軸 1 行サマリ」を 80 文字以内で添える
- 表の後に「自社との重なりが強い競合」「自社と方向性が異なる競合」を 1 社ずつピックして理由を 2 行で書く
- 表の最後の行に出典 URL と取得日(例: 2026年5月8日時点)をまとめる
- 不確実な情報には「要確認」と注記する

比較軸を 4〜5 件に絞り切るのが最大のコツです。10 軸並べると 1 軸あたりの解像度が下がり、結局見比べづらい表になります。前提ブロックで 比較軸を最初に確定 してから流し込んでください。

派生:ポジショニング所感

競合 5 社サマリ表をもとに、自社が取りに行くべきポジショニング所感を引き出すための派生テンプレートです。サマリ作成のあとに連続で使います。

# 前提
- 自社の商品 / サービス名: [商品名]
- 自社の強み: [強み](例: 国内サポートが平日 24 時間対応 / 業界特化のテンプレが豊富)
- 自社の弱み: [弱み](例: 海外展開がない / 上位プランの価格が高め)
- 先ほどの競合 5 社サマリ表:
  """
  [出力された比較表をそのまま貼り付ける]
  """
- 整理の目的: [目的](例: 新プランの位置づけを決める / 来期のメッセージ刷新の方向性を決める)
# 制約
- 表に書かれていない事実は使わない(推測は「仮説」と明記する)
- 「自社が一番」のような根拠なしの結論は出さない
- 弱みの直視を避けず、必ず弱みも分析対象に含める
- ポジショニング案は 2 案以上出す(早すぎる 1 本化を避ける)
- 推奨案には必ず採用理由と想定リスクを 1 行ずつ添える
# 出力形式
- 2 軸のポジショニングマップ案を 2 通り出す(例:「価格 × 機能の広さ」/「サポートの厚さ × 価格」)
- 各マップで自社と競合の位置を点で示し、その理由を表のすぐ下に箇条書きで書く
- 「自社が取りに行く位置」を 2 案ピックし、それぞれの採用理由 / 想定リスクを 2〜3 行で書く
- 末尾に「次に検証すべき問い」を 3 件添える(例: 上位プランの価格訴求を弱めても CV は下がらないか)

ポジショニング所感は 2 軸の取り方 で結論が変わります。前提ブロックで強み・弱みを両方とも具体的に書き入れておくと、自社に都合のいい軸だけを選ぶ偏りを避けられます。

テンプレートを自分の業務に合わせて改造する

ここからは、これまで紹介したテンプレートを自分の業務に合わせて書き換える観点を整理します。テンプレはそのまま使うより、自分の現場に合わせて改造したほうが必ず精度が上がります。

まず、書き換えの効果が一番大きいのは 前提ブロック です。商品名・想定読者・主訴求・既知の制約を、社内の言葉でそのまま書き入れてください。「BtoB SaaS の経理担当向け」のような汎用語ではなく、「月末締めの 5 営業日で 200 社分を集計している経理 2 名」のように、具体度を一段上げると出力の解像度がそのまま上がります。

次に効くのが 制約ブロック の調整です。社内のトーン&マナーや、ブランドガイドで決まっている NG 表現があれば、ここに列挙しておきます。「絶対」「最高」を使わない、敬語は『です・ます』で統一する、社名のあとに『株式会社』を付ける、といったルールを書き入れておけば、戻ってきた文章にあとから手を入れる工数が大きく減ります。

最後に 出力形式 は、社内で実際に使うフォーマットに合わせて書き換えると、転記の手間が消えます。Slack で共有することが多い案件なら箇条書き中心に、上司への提出が前提なら表形式に、編集者にバトンタッチする案件なら H2 / H3 のツリー形式に、というように出力の入れ物を業務に寄せてください。

3 ブロックすべてを一度に書き換えず、まずは前提ブロックだけを自分の言葉に置き換える、というところから始めるのが現実的です。1 つ書き換えて出力の変化を見てから次に進むと、何が効いたかが追えます。

よくある質問

業務テンプレートまとめ

ここまで、マーケター・デザイナー・編集者の業務 6 タスクを Claude Code に任せるテンプレートを紹介してきました。改めて要点を整理します。

本記事で扱ったのは次の 6 業務、メイン + 派生の計 12 テンプレートです。

どのテンプレートも、前提・制約・出力形式の 3 ブロック で組み立てているという共通骨格があります。読者がやることは「前提を自分の業務の言葉で埋め、制約に社内のルールを加え、出力形式を実務のフォーマットに揃える」の 3 つです。テンプレを丸ごと使うより、3 ブロックのうち前提だけを自分の言葉で書き換えるところから始めるのが、一番効果が見えやすい入り口になります。

明日から手を動かすなら、まずは目の前にある 1 案件を 1 つだけ選んでください。記事リライト 1 本でも、LP の FV 文言案でも、競合 5 社サマリでも構いません。本記事の該当テンプレートをコピーし、前提ブロックの「想定読者」と「主訴求」を自社の言葉で 1 行ずつ書き換えてから流し込む、ここまでを 15 分でやってみてください。

テンプレートは「使い込むほど磨かれる」前提のものです。出力を見て前提や制約を書き直し、自社版として育てていけば、3 ヶ月後には業務文書の下書き工程そのものが変わっているはずです。