# 主張・担当者・指標をすべて確認できるGTMブリーフの作り方 提供開始の事実、ポジショニング、承認済みのキーメッセージから、各主張に出典、各リスクに担当者、判断の指標を一つ、未決事項を明示した日付付きのGTMブリーフを作る手順です。 URL: https://www.hiresteve.ai/ja/blog/launch-brief 最終更新: 2026-10-12 新製品や新機能の提供開始、あるいは価格や提供プランの変更を発表するとき、何がいつから誰に変わるのか、営業が使うキーメッセージ、各チームに先に必要なもの、担当者付きのリスク、成果を測る指標、まだ決まっていないことを、短い一枚の文書にまとめます。この記事ではその文書をGTMブリーフと呼びます（ローンチブリーフと呼ぶチームもあります）。承認済みの資料にIDを付けた小さな資料一式から、Claudeに6項目を下書きしてもらい、各主張にIDを引用させ、資料で確認できないことに印を付けさせ、担当者それぞれに自分の行を確認してもらいます。ブリーフは提供開始の判断を支える資料であり、判断そのものではありません。 ## 提供開始の事実と、支えるべき判断から始める 最初に、何が変わるのか、誰が対象か、いつから使えるのか、このブリーフがどの判断のためのものか（たとえば何日の準備状況の確認会議か）を書きます。ベータ提供や限定提供と、一般提供は分けて書きます。提供プラン、価格、提供範囲の変更も、新しい機能がなくても一つの発表であり、同じブリーフが必要です。 [ポジショニングの整理資料](/ja/blog/positioning-brief)には、対象顧客、比較される代替手段、根拠のある違い、裏付け、対象外の状況が書かれています。それは戦略の文脈であって、今回何を提供するかの記録ではありません。今回の提供範囲、セグメントやプラン別の提供時期、価格や提供プランの変更、それぞれの裏付けとなる準備状況の記録は、提供開始の責任者から受け取ります。加えて、[メッセージ階層](/ja/blog/messaging-template)の承認済みの文言、利用が認められた顧客や競合の根拠、担当を引き受けている人の実際の記録をそろえます。各資料に短いID、リンク、確認日、承認状態を付けます。利用が認められていない作業環境に、買い手や社員の非公開の記録を貼り付けないでください。 作業は、この製品用にすでに使っているClaudeのプロジェクト内のチャットで行います。指示と参照用ファイルの準備は[プロジェクトの設定方法](/ja/blog/claude-project-setup)で一度だけ扱っています。Anthropicの[プロジェクトの作成と管理のガイド](https://support.claude.com/ja/articles/9519177-プロジェクトを作成-管理するにはどうすればよいですか)は、無料アカウントでも最大5つまでプロジェクトを作成できると説明しているので、有料プランは前提ではありません。一回限りなら、同じ資料を添付した通常のチャットでも足ります。この下書き作業に、リサーチ機能、コード実行、外部連携は必須ではありません。 ブリーフは、互いにつながった6項目で構成します。 - 対象：買い手または利用者、影響を受ける既存顧客と取引先、この発表に関わる社内チームと、それぞれに知らせること。 - 変わること：今回の実際の提供範囲、セグメントやプラン別の提供時期、日付、価格や提供プランの変更。各項目に資料ID。 - キーメッセージ：承認済みの文言をそのまま載せるか、候補の一文に「提案中」と明記する。 - 営業・サポートへの引き継ぎ：資料と連絡ごとに、対象、担当者、準備できていることを示す根拠、順序の中での位置。 - リスクと未決事項：根拠、起こりうる影響、責任を持つ担当者、次の行動、その期限。 - 指標：判断に使う主要指標、その定義、出典、対象母数と期間、担当者、確認日。 ## 対象、変わること、キーメッセージをつなぐ 今回の提供が実際に関わる対象だけを書きます。最初はポジショニングの整理資料で定めた買い手または利用者です。作業手順が変わる既存顧客、販売や連携を担う取引先、設定を切り替える管理者は、変更が及ぶ場合に影響を受ける対象になります。営業、サポート、カスタマーサクセスは、問い合わせを受ける場合に社内の対象になります。 「変わること」には、何が、誰に、いつから使えるようになるかを書きます。出典は提供開始の責任者の記録であり、ポジショニング資料にある「違い」の説明ではありません。ロードマップ上の機能は「変わること」には入りません。キーメッセージがその機能に依存しているなら、未決事項に回します。 キーメッセージには、メッセージ階層の承認済みの文言を編集せずに載せます。承認済みの一文がまだなければ、ポジショニング資料から候補を下書きし、「提案中」と明記して、候補と承認済みの文を読み分けられるようにします。説明のために作った例です。提供開始の記録には「エクスポート機能は一つのプランの限定ベータでのみ利用可能」とあり、下書きの見出しには「すべてのお客様にご利用いただけます」とある。適切な確認では、この食い違いに印を付け、「変わること」にはベータの範囲を残し、一般提供の表現は記録が変わるまで保留にします。 ## 営業とサポートに使える形で引き継ぐ 引き継ぎの項目には、資料と連絡ごとに、対象、担当者、準備できていることを示す根拠、順序の中での位置を書きます。社内への連絡は社外への発表より先です。一覧は短くて足ります。キーメッセージの一文、最初の商談で出やすい反論への回答、価格や提供プランの変更とその適用日、デモの手順、発表後一週間の相談窓口、営業向けの説明会です。バトルカードなどの営業向け資料を変更するなら、変更する行と担当者を書きます。その行がどれほど短くてよいかは、[営業が実際に使うバトルカードの作り方](/ja/blog/battlecards-sales-actually-uses)で説明しています。 各行は、担当者が示せる確認の記録につなげます。「営業支援：完了」は行になりません。誰も確認できないからです。ブリーフは引き継ぎを記録する文書で、チームのタスク管理表ではありません。 ## リスクと未決事項を見える状態に保つ 各リスクは5項目で書きます。リスクがあることを示す根拠、起こりうる影響、責任を持つ担当者、次の行動、その期限です。よくある行は、遅れる可能性のある依存先、キーメッセージに含まれるまだ裏付けのない主張、機能をまだ見ていないサポートチーム、伝える内容を弱める競合ページの変更です。担当者の欄には個人名を書くことを勧めます。個人は自分の行を確認できるからです。これは私たちの推奨であり、出典が定めるルールではありません。 未決事項も同じ形で扱います。GTM Playbookの[GTMブリーフの雛形（英語）](https://discover.gtmplaybook.co/go-to-market-brief-template)は、未決の質問とはまだ下されていない決定であり、書き出して担当者を割り当て、解決の期限を決めるものだと説明しています。Pendoの[発表ブリーフの雛形（英語）](https://www.pendo.io/product-led/artifacts/product-launch-brief-template/)の公開されている説明には、発表の要約、時期とマイルストーン、ベータ提供の役割分担、一般提供のチェックリストが含まれています。雛形そのものはフォームの先にあるため、この公開説明を超えた判断はしません。Goodpatchの[GTM戦略の解説](https://goodpatch.com/blog/gtm-strategy)も、実行の段階で目標設定、スケジュール管理、担当者の決定を行うと説明しています。いずれも実務家の書式や解説です。この記事が加えるのは、一つの発表に絞った短い文書で、各主張に資料IDを付け、提供開始の記録と照合することです。 **下書きに書かれた約束は、確認済みの約束ではない** リスクの隣に名前を書いたブリーフは、その人がチームの通常の手続きで確認するまでは提案の記録です。日付を書いたブリーフは、提供開始の責任者がその日付がまだ有効だと確認するまでは計画の記録です。この二つの状態をファイル上で読み分けられるようにし、文書をきれいに見せるために未決の印を消さないでください。提供開始を左右する事項には、チームの実際の決定が必要です。整った空欄では代わりになりません。 ## 成果の指標を、他の人が読める形にする 主要指標は、読んだ人が出典を開いて同じ数え方を再現できるように書きます。対象となる出来事、対象母数の条件、分母、期間、数値を読む場所、読む人、読む日です。基準値や目標は、チームが実際に合意した場合にだけ書きます。「利用率」とだけ書いても、どこを見ればよいのか誰にも分かりません。「対象プランのアカウントのうち、提供開始から30日以内にエクスポート機能を一度以上使ったアカウント数。プロダクト分析のダッシュボードで、確認日に読む」なら確認できます。 主要指標を一つに絞ると確認の焦点が定まります。補助の指標や下限を守るための指標を置くのが適切な場合もあります。一つに絞るのは私たちの推奨です。発表期間中の数値は、その発表が原因だという証明にはなりません。StartLinkの[GTM戦略の設計ガイド](https://start-link.jp/hubspot-ai/btob-marketing/b2b-strategy/gtm-go-to-market-strategy-design-guide)は、GTM戦略の実行状況を経営チームが常に確認できるダッシュボードを構築することを勧めています。指標を読む場所を名指しするという点では同じ方向ですが、そのダッシュボードがすでにあるとは限りません。数値がまだ計測されていないなら、それは指標になりません。担当者と期限を付けた未決事項として扱います。 ## Claudeで下書きし、確認し、保存する **下書きの前に、各項目に必要な入力を挙げてもらう** IDを付けた資料一式を渡し、6項目それぞれに必要な入力と、資料一式に欠けているものを挙げてもらいます。確認点：担当者の未承諾、裏付けのない成果、ロードマップに依存する表現が、一般知識で埋められた既定値ではなく、不足として表示されていること。 **各主張に資料IDを付けて6項目を下書きしてもらう** 下のプロンプトを使います。確認点：重要な文にはすべて開けるIDが付いていること、承認済みの文言が変わっていないこと、日付の食い違いが解消されずに印付きで残っていること。 **引用箇所を開き、各約束を担当者に確認する** 各主張の裏にある箇所を読み、同じ範囲で同じことが書かれているか確かめます。名前を書いた担当者それぞれに、チームの通常の手続きで自分の行を確認してもらいます。確認点：計画に書かれていたという理由で一般提供とされている記述がないこと、引き受けられていない割り当てがそれと分かる形で残っていること。 **確認済みのブリーフと資料の索引を、日付付きのファイルとして保存する** 承認済みの作業版をプロジェクトナレッジとチームの共有の保管場所に追加します。確認点：ファイルに日付、未決事項、資料の索引があり、あなたに聞かなくても確認者が主張を出典までたどれること。 文言をそのまま残す価値があるプロンプトは次の一つです。根拠が足りないことと、決定がまだ下されていないことを分けて出させるからで、確認の作業はこの区別に依存します。 ```prompt 次の資料IDをもとに、GTMブリーフの6項目を下書きしてください。承認済みの文言はそのまま使ってください。重要な主張ごとに資料IDを引用してください。裏付けのない事実や未確認の約束には「[未決：必要な根拠または決定]」と印を付けてください。日付の食い違いを解消したり、提供予定を提供済みに書き換えたりしないでください。ブリーフと未決事項の一覧を返してください。 ``` このプロンプトは下書きを確認しやすくするだけで、事実であることを保証はしません。Anthropicの[チャット検索とメモリの案内](https://support.claude.com/ja/articles/11817273-claudeのチャット検索とメモリを使用して以前のコンテキストに基づいて構築する)は、プロジェクトごとに独立したメモリがあると説明しているので、チャットが以前の作業の文脈を引き継ぐことがあります。それでも重要な主張は渡した資料一式に基づかせるよう指示し、日付付きの承認済みファイルを記録として保ちます。ファイルには、確認者が開ける版と日付があるからです。Anthropicの[Google Workspaceコネクタの案内](https://support.claude.com/ja/articles/10166901-google-workspaceコネクタを使用する)には、DriveやGmailなどのGoogleサービスを扱うコネクタを説明していますが、この記事の方法は手動でそろえた資料一式を使うので、そこにないものは追加するまで不足のままです。連携先で見つかった記録があっても、人の約束や提供開始の判断ができたことにはなりません。 ## 競合の根拠を最新に保つ 提供範囲、価格、引用した箇所、日付のいずれかが変わったら、古い資料と新しい資料を比べ、それに依存するブリーフの記述と資料を挙げ、古くなった主張を修正または削除し、影響を受ける担当者に変わった約束を再確認してもらいます。見出しと確認点は次の発表でも使い回し、日付、目標、担当者は毎回ゼロから入れます。 リスク欄の競合の根拠については、キーメッセージが依存する競合ページの日付付きのコピーを保存し、次の準備状況の確認までに見直すのが手作業の方法です。頻度は、変更を見落としたときの損失の大きさと、そのページがどのくらい動くかで決めます。競合1、2社から始めるのは妥当な出発点ですが、手作業で足りる証明ではありません。 Steveが隣接する範囲は狭いものです。追跡中の競合ウェブサイトの変更を検知してSlackに投稿し、PMMはその投稿をリスク欄の材料として読めます。SteveにGTMブリーフ、担当者の割り当て、準備状況の確認の機能はなく、ブリーフを自動で更新する仕組みもありません。多くの競合ページの根拠を最新に保つことが滞る部分なら、[Steveの競合リサーチ](/ja/products/research)は評価する価値のある隣接した選択肢です。どちらを選んでも、ブリーフとその判断はチームに残ります。 ## よくある質問 ### GTMブリーフとは何ですか？ 一つの提供開始や発表について、誰に向けたものか、何がいつから変わるのか、営業が使うキーメッセージ、各チームに必要な資料と連絡、担当者付きのリスク、成果を測る指標を、各主張の出典とともに短くまとめた日付付きの文書です。この記事ではこの文書をGTMブリーフと呼びます。 ### 新機能がない場合もGTMブリーフは必要ですか？ 必要です。提供プラン、価格、提供範囲の変更は、顧客から見て新しい機能がなくても一つの発表です。今回の提供範囲、対象と時期、価格の変更、それぞれの裏付けとなる準備状況の記録は同じように必要です。 ### ClaudeにGTMブリーフを書いてもらえますか？ 渡した資料から6項目を下書きし、各主張に資料IDを付け、資料で確認できないことに印を付けてもらえます。担当者の確認と提供開始の判断は人が行います。下書きに名前が書かれていても、その人が引き受けたことにはなりません。 ### 判断の会議までに未決事項はすべて消すべきですか？ いいえ。確認を終えたブリーフにも、担当者と期限を付けた未決事項は残してかまいません。文書をきれいに見せるために印を消すと、チームがまだ決めていない事項が隠れます。 ### SteveでGTMブリーフを作成・管理できますか？ SteveにGTMブリーフ、担当者の割り当て、準備状況の確認の機能はありません。追跡中の競合ウェブサイトの変更を検知してSlackに投稿するので、それをリスク欄の材料として自分で読むことはできます。