event-sponsor-prospectus

スポンサー募集要項

技術イベントのスポンサー募集要項を作成します。これは、見込みスポンサーが打ち合わせの前に読む、標準的な公開文書です。成果物には、文書そのもの、セクションの順序、ティア表、特典一覧、参加者層を示す根拠、配布形式、開催回ごとの更新手順が含まれます。

このスキルは、関連スキルが作成する内容をまとめるものであり、内容を独自に作り出すことはありません。

• 価値提案と提供しないものの一覧は、samber/dev-event-organizer-skills@event-sponsor-value-proposition が作成します。
• ティアの価格と上限は、samber/dev-event-organizer-skills@event-sponsor-pricing が作成します。

価格の設定、スポンサーへのアプローチ、契約書の作成、履行状況の追跡は行いません。これらは関連スキルの役割です。

以下のランキングはすべてデフォルトであり、絶対的な規則ではありません。状況や実行する人によって変わります。ヒアリングの後、主催者について把握した内容に照らして各メニューの順位を付け直してください。チームにデザイナーがいる、過去の開催回の写真アーカイブがある、素材のない初開催である、あるいはアプローチの期限が迫っている場合などは、デフォルトの順位が変わります。

ヒアリング

一度に質問は一つにし、できるだけ選択式にします。質問6〜8があるのは、以下のメニューで効果が出るまでの速さ、持続性、労力に大きな違いがあるためです。ユーザーに代わってデフォルトの順位を決めることはできません。

1. イベントはどちらに当てはまりますか。コミュニティ主催（独立運営、CFP主導、スポンサーは費用回収のため）ですか、それともベンダー／財団主催（ベンダー所有、スポンサーはパイプライン獲得のため）ですか。この違いによって、文書に掲載できる特典の範囲が決まります。
2. 前提となる情報は揃っていますか。セグメント別の価値提案と提供しないものの一覧、価格を設定したティア構成と単品価格はありますか。どちらかが不足している場合は、まず関連スキルを利用してください。これらがないまま募集要項を作成すると、独自の価値提案や価格を作り出すことになります。このスキルでは、どちらも決して行ってはいけません。
3. 過去の開催回で、実際に使える素材は何がありますか。自然な様子が伝わる写真、スポンサーのロゴ、発言者を明記した推薦文、報道記事への掲載などです。手元にある素材を挙げてください。これから集められる素材ではありません。
4. どのような参加者データを確認済みですか。参加人数のみ、大まかな属性（年齢、「業界の専門職」など）、登録フォームから集計した役職・業界・企業規模の割合、またはアンケートで裏付けられた詳細情報のいずれですか。
5. 実際に有効な上限は何ですか。ブースの設置面積、単独で独占できるブランド掲出面（ランヤード、パーティー、コーヒーなど）、スポンサー数の厳格な上限などです。実際に存在する上限のみ掲載できます。
6. 最初のアプローチをいつまでに送る必要がありますか。（期限が近い場合は、効果が早く出る選択肢が有利です。ウェブ上のティアページなら今週中に公開できますが、イラストを使ったキットは間に合いません。）
7. この文書は今回限りのものですか。それとも毎年活用し続ける資産ですか。（毎年活用する場合は、PDF キットと、それを中心に構成する開催回ごとの更新システムが有力になります。）
8. 労力の上限はどのくらいですか。デザインに使える時間やデザイナーの有無、レイアウトツール、開催回の間に文書を管理する人について教えてください。
9. この募集要項は、特定のスポンサーまたはティア向けに準備するものですか。そのスポンサー独自のデューデリジェンスチェックリストには、影響力の購入や参加者の役職構成についての質問がありますか。

コミュニティ主催とベンダー主催

イベントの所有者によって、文書に掲載できる内容が決まります。同じ観点については、samber/dev-event-organizer-skills@event-first-edition、samber/dev-event-organizer-skills@event-format-selection、samber/dev-event-organizer-skills@event-sponsor-value-proposition でも説明されています。

• コミュニティ主催 - 参加者リストは提供も販売もされず、講演枠も購入できないため、参加者リストやバッジスキャンに関する項目を、ティア表や追加特典のどこにも載せてはいけません。DevOpsDays Graz 2026 のキットには、リードデータに関する特典が一切ありません。集計した属性情報を正直な代替情報として提示し、スポンサーが 受け取れないもの を明記してください。
• ベンダー／財団主催 - 参加者の同意を条件とするリード取得（バッジスキャン）の項目は、正確な内容として掲載できます。パイプラインの獲得を軸にした説明も可能です。

文書でどちらの前提を採用するか明記してください。コミュニティ主催イベントのティア表にスキャン済みリードを約束すれば、主催者自身が公開しているルールを読んだスポンサーにすぐ見破られます。

ワークフロー

1. インタビューを実施し、基準となる軸（Q1）を定め、関連する入力情報（Q2）を収集します。
   • ステートメント、提供対象外リスト、実績資料の一覧。
   • ティアごとの価格、上限数、追加オプションの価格。
2. 誠実性の総点検：構成に取りかかる前に、ドキュメントに記載してはならないものを列挙します。コミュニティ枠のリードデータの項目、実在しない上限数、価値提案に含まれていない特典、あらゆる保証（「失敗パターン」を参照）などです。提供対象外リストは、下書きメモだけでなくドキュメントにも記載します。
3. 以下のメニューから、ドキュメントの詳しさを選択します。
4. references/document-anatomy.md に従い、信頼性を価格より先に示す順序で各セクションを配置します。実績は必ず価格より前に提示します。
   • 表紙
   • ブランドイメージ
   • イベントの概要
   • 価値提案
   • 実績
   • ティア表
   • 追加オプション
   • ロジスティクス
   • 担当者名と連絡先
5. references/tier-table-and-perks.md に従い、ティア表を作成します。
   • 価格の行を最初に配置します。
   • 上限数が実在する場合のみ、提供可能数の最大値の行を設けます。
   • セルにはシンプルなチェックマークを使用します。
   • 数値のセルは、実際の数量を示す場合にのみ使用します。
   • 特典には名称を付けます。
6. 以下のメニューから、特典の提示方法を選択します。単独提供の特典がある場合は、名称付きの追加オプションカードに移します。
7. references/audience-evidence-and-distribution.md に従い、デモグラフィックのメニューで選ばれた詳しさで、オーディエンスの裏付けセクションを作成します。データが検証済みの範囲を超えて詳しくしてはなりません。
8. 同じリファレンスに従い、配布方法と各版の更新頻度を設定します。
   • 日付を明記したドキュメントにします。
   • お客様の声とロゴを更新します。
   • 各版で上限数を再確認します。
9. デザインやレイアウトに取りかかる前に、ユーザーと各セクションを確認します。内容の誤りは概要の段階なら修正に手間がかかりませんが、レイアウト後では修正にコストがかかります。

ハーネスに永続メモリがある場合は、各版について、印刷した上限数に達して完売したティアと追加オプション、見込み顧客から質問されたもののドキュメントに記載されていなかった特典、更新チェックリストの状況を記録します。次の版の提案書は白紙から始めず、その記録をもとに作成します。

ドキュメントの深さ

作成するドキュメントの詳細度です。優先順位（デフォルトであり、固定ではありません。Q6〜Q8 で再評価します）：

• 労力（設計＋組み立てにかかる時間）：イラスト付きの完全版PDFキット > ページ内の階層別料金表ページ == テキスト1枚資料
• 価値（慎重に検討するスポンサーへの成約シグナル：価格が見える、実績が見える、見込み客の組織内で転送しやすい）：イラスト付きの完全版PDFキット > ページ内の階層別料金表ページ > テキスト1枚資料
• 効率：ページ内の階層別料金表ページ > テキスト1枚資料 > イラスト付きの完全版PDFキット

労力が同等という点には異論もあります。下位の2つは、どちらも関連スキルですでに作成されたコンテンツを1〜2時間で組み立てるだけで、写真撮影もレイアウトツールも必要ありません。文章の要約とHTMLテーブルの違いは書式であり、新たな作業ではありません。

• ページ内の階層別料金表ページ - デフォルトの選択肢です。全階層の料金表、価格、問い合わせ用メールアドレスを掲載したウェブページです。デザインに割ける時間がなくても1〜2日で公開でき、実際に採用されている形式です。DevOpsDays Graz はPDFキットに移行する前に、まさにこの表を作成しました。写真素材がなく、告知期限が厳しい初回開催に適しています（Q6）。
• 階層別料金を記載したテキスト1枚資料 - 表さえ維持できない場合の最低限の選択肢です。料金の概要と、スポンサーが必ず尋ねる3つの情報（対象者、スポンサーになる理由、各階層で得られるもの）を記載します。
• ウェブ上の簡易ページからリンクする、イラスト付きの完全版PDFキット - 手間がかかる選択肢です。価値と労力の両面で最上位にあるため、効率を基準にすると選ばれません。それでも、2回目以降のコミュニティカンファレンスでは主流の形式です。公開中のスポンサー向けページは短い概要だけで、実際の案内資料はダウンロード可能な日付入りPDFです。上位の選択肢にする条件は、前回開催時の写真や推薦コメントがあること（Q3）、デザインに割ける時間があること（Q8）、または毎年価値が積み重なる資産を作ることが目的であることです（Q7）。
• 価格のない資料は、格下げではなく削除です - 価格が一切記載されていない案内資料では、見込み客に問い合わせを促す必要があり、成約率が下がります。例外は、samber/dev-event-organizer-skills@event-sponsor-pricing のように、料金表を意図的に見積もり依頼制にしている場合です（ネットワーク／ポートフォリオ規模でのパターン）。この場合、問い合わせ制は資料の記載漏れではなく、この資料が引き継ぐ料金設定上の判断です。

人口統計データの根拠の深さ

オーディエンスのセクションをどこまで掘り下げるかです。順位（デフォルトであり、絶対的なルールではありません。Q4で検証済みのデータが上限であり、そこまで水増しすることを目指すものではありません）：

• 労力（収集＋検証）：アンケートに基づく内訳 > 集計した構成内訳 > 検証済みの一文
• 価値（入念に検討するスポンサーの「誰が参加するのか」という問いに答えるもの）：アンケートに基づく内訳 > 集計した構成内訳 > 検証済みの一文
• 効率：集計した構成内訳 > 検証済みの一文 > アンケートに基づく内訳

優越性チェック：3組を比較し、厳密な優越関係はゼロです。これは構成上そうなっているだけであり、構成上の結果は決して合格を意味しません。 価値と労力のリストは同じなので、あらゆる組み合わせに同じ仕組みが働きます。より詳細な内訳はより多くの問いに答えられますが、収集と検証のコストも厳密に増え、第三の軸は示されていません。このチェックでは順序の誤りは検出されません。順序の根拠は以下の説明にあります。

• デフォルトの段階：実在し、検証済みの範囲で最も深い段階を掲載します。登録フォームのデータがある場合、それは集計した構成内訳です。役割の構成比、業界の構成比、企業規模の区分を、それぞれラベル付きの割合として示します。PyCon US が掲載している形式です（参加者 2,500 人以上、開発者 53.9％、ソフトウェア 43％／金融 13％／…）。samber/dev-event-organizer-skills@event-sponsor-value-proposition のデフォルトの調査手段で、まさにこのデータを作成できます。
• 検証済みの一文――小規模イベントや初開催のイベントにおける誠実な最低ラインです。DevOpsDays Graz は「業界の専門家が最大300人参加し、年齢は25～40歳です」という一文を掲載しています。事実に基づく簡潔な一文は、捏造された詳細な表より優れています。
• アンケートに基づく内訳（購買への影響力、詳細な役職、ツールの導入状況）――最も不足しがちな選択肢であり、価値と労力の両方で最上位です。Q9に基づく掲載条件は、アンカーまたはプレゼンテーション枠のスポンサー候補に働きかけていて、その審査で購買への影響力について尋ねられる場合、または構成に関する主張が価格を左右する、ベンダーが主役のイベントである場合です。収集方法とそれに伴うコンプライアンス上の負荷は、samber/dev-event-organizer-skills@event-sponsor-value-proposition の調査手段メニューに記載されています。
• すべての段階に適用される厳格なルール：カテゴリーと数値の対応関係を検証できない内訳は、決して公開しません。PyCon の PDF 自体、企業規模の内訳を掲載していますが、レイアウトのため区分の対応関係が曖昧です。そこから学ぶべきことは、数値を引用しないことです。判読しづらい表は、正しく示されたカテゴリーが少ない場合より、信頼性を損なうシグナルになります。大規模イベントの表の形式に合わせるために、割合を捏造してはいけません。

特典の提示方法

特典カタログをページ上でどのように見せるか。順位付け（デフォルトであり、絶対的な決まりではありません。Q5で順位を再評価します）：

• 労力：段階別のグリッド＋名称付き追加特典カード > チェックマークのみの単一グリッド
• 価値：段階別のグリッド＋名称付き追加特典カード > チェックマークのみの単一グリッド
• 効率：チェックマークのみの単一グリッド > 段階別のグリッド＋名称付き追加特典カード

優越性チェック：2段階、1組、厳密な優越関係はゼロ。構造上のみ問題がない状態であり、合格ではありません。 価値と労力は同じ順序なので、この1組はコスト面で不合格です。追加特典カードは、より多くのものを提供し、コストも高くなります。2段階のメニューでは、ほかに確認するものがなく、3つ目の軸も示されていません。また、効率に関する判断は以下で論じるだけで、検証されていません。

• チェックマークのみの単一グリッド - デフォルトです。行には特典項目、列にはティアを配置し、含まれる特典にはシンプルなマークを付け、数値は実際の数量（チケット枚数、割引率）に限ります。表が読みにくくなる前に、各ティアの名称付き特典項目を3～7個に抑えてください（実際のGrazの表では、5ティアに約10項目が並び、多くのセルが空欄です）。
• グリッド＋名称付き追加特典カード - 特典が足りない場合の選択肢です。これに切り替える条件：単一ティア限定の特典や体験型の特典がある場合です（Q5）。
  • グリッドから外して、1枚につきアイコン＋名称＋価格＋1行の説明からなる個別販売カードにします。これは出典のあるパターンです（「Photo Booth Sponsor」、「Party Sponsor」）。
  • すべての特典に名称を付け、説明文で表現しないでください。形式を示す「Track」、「Fair」、「Lounge」、「Corner」といった容器的な言葉で内容を伝えます。
• スポンサーごとの個別提案は格下げせず、削除します - プロスペクタスは、多数の見込み客に送る標準公開オファーです。1社の購入者が示した要件に合わせた提案書は、別の文書です。読者の役職に応じて強調するセクションを調整すること（DevRel → 製品へのフィードバック、Marketing → ブランド、HR → 採用特典）は、samber/dev-event-organizer-skills@event-sponsor-outreachの担当であり、この文書の範囲外です。

各ティアの特典構成では、スポンサーが実際に気にかける点に答えていることが一目で分かるようにしてください。参加者にとっての価値、ほかのスポンサー、パッケージの価値など、ハッカソン主催者向けガイダンスが挙げる3項目に応えるものであり、ロゴ掲載をただ積み重ねるだけではいけません。ハッカソンに特化した特典（スポンサー提供の賞金トラック、スポンサーとのチャットチャンネル、ワークショップ、採用向けの形式）を含む特典カタログ全体については、references/tier-table-and-perks.mdをご覧ください。

ハッカソンに関する注記

MLH自体は、問い合わせフォームを通じてのみスポンサーシップを受け付けており、公開しているのは到達人数であってプロスペクタスではありません。また、主催者向けガイダンスでは、会員ハッカソンのプロスペクタスを2～3ページに収めるよう伝えています。「スポンサーには、長いスポンサーシップ資料を読む時間がないのが一般的」だからです。これが、MLHと提携するキャンパスイベント（HackMIT、PennApps、TreeHacks）がPDFではなくメールでの連絡に誘導する理由である可能性が高いです。一方、独立運営のハッカソンでは、より充実した資料を公開しています。Cal Hacks 13.0の5ページの資料は、会議の構成とほぼ完全に一致しますが、ティア表を実績や推薦文より先に配置しており、会議資料でデフォルトとされる「実績を価格より先に示す」順序を逆にしています（references/document-anatomy.mdをご覧ください）。どちらの場合も、ハッカソン特典は同じティア表と追加特典の構成に組み込めます。どちらかのパターンを前提にせず、ページ順と内容の詳しさは主催者に確認してください。MLHの簡潔な資料に関する助言も、Cal Hacksの充実した資料も、どちらも出典のある実例であり、同じ推奨ではありません。

失敗パターン

• 保証を記載すること――どのような保証であっても。 DevOpsDays Graz、PyCon US、DjangoCon US、Cal Hacks 13.0は、カンファレンスとハッカソンの両方の資料を通じて、種類を問わず保証条項を一切記載していません。これは記載漏れではなく、明確なアンチパターンです。「有望なリードを50件保証します」といった成果保証は、誠実さの制約に真っ向から反します。コミュニティ運営のイベントはリードの価値を一切保証できず、ベンダー運営のイベントであっても、販売するのはアクセス権と掲載枠であり、成果を約束することはありません。見つかった最も近い実例は、GoatHacks 2023の採用関連セクションです。すべてのスポンサーランクに対し、「参加学生全員の履歴書と連絡先情報」を上限や留保条件なしで提供すると約束しています。保証とは表現していませんが、実質的には保証であり、この失敗パターンがまさに検出しようとしている形です。一般的なオファー構成のアドバイスでは保証が強く推奨されますが、このスキルでは明確に否定します。
• 人為的な希少性の演出。 「最大提供数」の欄を記載できるのは、上限が実際に存在する場合（会場の床面積、単一のストラップなど）に限られます。誠実なやり方は、実際の上限を公開することです（Goldは3、Silverは6、Bronzeは20に限定）。上限を捏造してはいけません。また、「残り2枠」というカウンターが事実でなくなった後も放置してはいけません。
• 古いスポンサー向け資料の再利用。 日付のない汎用資料、昨年の推薦コメントを現在のものとして掲載すること、再参加しなかったスポンサーのロゴ、在庫と一致しなくなった上限などが該当します。開催回ごとに新しい日付入り資料（「Sponsor Information 2026」など）を作成し、推薦コメントも開催回ごとに更新します。
• 参加者属性の誇張。 数値の捏造、検証できない対応付け、初開催なのに大規模イベントの表形式をそのまま使うことなどが該当します。属性情報のメニューにある厳格なルールを参照してください。
• 価格を目立たない場所に記載すること。 公開するスポンサー向け資料では、ランク表の先頭に価格を記載します。価格に関する回答がないたびに、問い合わせと返信のやり取りが発生します。価格を見積もり制にすることが意図的な価格設定の判断である場合を除き、資料に価格を記載してください。
• 参加者体験よりもスポンサー特典の売り込みに力を入れること。 これは、注意深いスポンサーが警戒すべき兆候として伝えられているものです。上記の資料構成では、パッケージを提示する前に、まずイベント自体の信頼性（ブランド、事実、コミュニティ）に半分を費やしています。
• コミュニティ寄りのイベントでリードデータの項目を設けること。 構造上、提供できません。イベントの方向性に関するセクションを参照してください。
• 理由の説明がない特典一覧。 上流の価値提案の内容がないままブースの大きさやロゴの掲載位置だけを並べても、予算承認者が社内で回覧できない資料になります。表を水増しするのではなく、samber/dev-event-organizer-skills@event-sponsor-value-propositionに戻してください。

効果測定

スポンサー向け資料の品質には成約率の数値による裏付けがないため、決してそのような数値を引用しないでください。観測できるのは、資料作成者自身が設定する下流の指標です。2〜3個選び、それぞれがどの改訂につながるかを書き留めてください。

• 問い合わせ返信率（独自設定）： 資料に記載すべき情報（価格、日程、参加者の構成、各ランクに含まれる内容）を尋ねるための返信があった場合、それは営業上の問題ではなく、資料の不備を示しています。samber/dev-event-organizer-skills@event-sponsor-outreachで、該当セクションごとに記録してください。
• 転送しやすさ（独自設定）： 主催者がやり取りに加わっていなくても、予算承認者に転送して通用する資料にしてください。社内の担当者が最初から説明し直す必要があるなら、セクションが不足しているサインです。
• 開催回ごとの鮮度チェック（独自設定）： 各開催回で最初に資料を送る前に確認します。日付入りタイトルが該当の開催回と一致していること、推薦コメントとロゴが最新の開催回のものであること、記載した上限がすべて実際の在庫と照合されていることを確認してください。

呼び出し例

• 「DevOps カンファレンスの価値提案と各ティアの価格が決まっています。スポンサーシップキットの PDF にまとめてください。」
• 「初開催のミートアップ向けにスポンサー向けパッケージのページを作成してください。写真はまだなく、2 週間後にスポンサーへのアプローチを始めます。」
• 「ティア表を作り直してください。5 つのティアのうち 2 つは『ストラップにロゴを掲載』のような独占特典だけで、スポンサーから価格についての問い合わせメールが続いています。」
• 「昨年の募集要項を 2027 年版に更新してください。」

期待される出力は、信頼性を価格より先に示し、検証しやすいようセクションごとに提示します。

• セクションごとの文書構成案、または完成稿。
• 価格と上限の行を含むティア表。
• 掲載を勧める追加オプションのカード。
• 検証済みの詳しさで示すオーディエンスの根拠セクション。
• 配布形式の選択。
• エディションごとの更新チェックリスト。

参考資料

• references/document-anatomy.md - 9 ページの作成例を含むページごとの汎用的な構成、ピッチデッキとの比較、スポンサー向けロジスティクス FAQ のチェックリスト、そして実際の募集要項で意図的に省かれる内容。
• references/tier-table-and-perks.md - ティア表の作成例（行、価格、上限）、スポンサーの動機別の特典カタログ（ハッカソンの特典を含む）、命名のガイダンス、希少性を演出するために絶対にしてはいけないことのリスト。
• references/audience-evidence-and-distribution.md - オーディエンスの根拠を示す 2 つのモデル（構成の内訳と最低限の一文）、検証ルール、配布形式、エディションごとの更新頻度。

同じコレクションの関連項目：

• samber/dev-event-organizer-skills@event-sponsor-value-proposition - 「なぜ」を提示します。セグメント別の説明、提供しないものの一覧、この文書で示す根拠のインベントリを用意します。
• samber/dev-event-organizer-skills@event-sponsor-pricing - 数値を提示します。ティア価格、上限、個別オプションの料金を用意します。このスキルは価格の段階を示しますが、価格そのものは設定しません。
• samber/dev-event-organizer-skills@event-sponsor-outreach - 文書を送付し、読者ごとに強調点を調整します。返信で寄せられた質問の記録をこのスキルにフィードバックし、測定に活用します。
• samber/dev-event-organizer-skills@event-sponsor-fulfillment - 文書で約束した内容を提供します。イベント後のレポートには、次のエディションで使う推薦コメントと実績が記載されます。
• samber/dev-event-organizer-skills@event-sponsor-agreement - 見込みスポンサーが承諾した内容を契約にします。募集要項は営業資料であり、契約条件ではありません。
• samber/dev-event-organizer-skills@event-first-edition - 素材も開催実績もない場合に、このスキルで使う簡易な文書構成を選びます。