event-comms-channels

イベントコミュニケーションチャネル

技術イベントが、参加者が存在するようになった時点から最後のチャネルを閉鎖する時点まで、1回の開催において参加者に連絡するためのチャネル構成を設計します。出力するのは、ほかの誰かが実行するためのアーキテクチャです。

• それぞれの役割を明記したチャネル一覧。
• どのメッセージをどこに送るかを定めるルール。
• 複数の執筆者が、イベント全体で一貫した話し方を保つためのプロセス。
• 開設したすべてのチャネルについて、日付を定めた終了計画。

このスキルは文章を作成しません。イベントのレジスター（イベントの話し方）は、samber/dev-event-organizer-skills@event-cultural-identity によって確定されます。このスキルは「レジスター（ハッカー、企業、デザイン、ビジネス）と、すべてのタッチポイントを通じて一貫して表現する方法」を担います（同スキルの説明文からの引用）。

複数のチャネルにわたってレジスターをぶらさずにチームで 実行する 方法を決めます。新たに作り出すことはありません。

兄弟スキルがこの一部を担うため、再定義してはいけません

兄弟スキル	担当範囲
event-run-of-show	主催者専用の調整チャネルを担当し、参加者向けのチャネルとはすべて分離します。スタッフの調整を参加者向けチャネルに流してはいけません。
event-code-of-conduct	匿名での報告経路を含め、インシデント報告全般を担当します。一覧から除外してください。また、インシデント発生時の公式発表に関するルールも担当します（§ メッセージ種別ごとの振り分けで適用）。
event-attendee-email-sequences	メーリングリストの文章、配信頻度、同意、運用上の整備を担当します。ある種のメッセージにメールが適切なチャネルかどうかだけを判断してください。
event-social-media	公開配信プラットフォームの選定とソーシャルメディア向けの文章を担当します。必要に応じて「これは公開配信されます」と述べてください。プラットフォームを選んだり、投稿文を書いたりしてはいけません。
event-marketing-plan	参加者が存在するようになる前の獲得チャネルの比重を担当します。このアーキテクチャの対象は、誰かが登録した後からです。

さらに、境界が一方向からのみ定められている箇所が2つあるため、それに依拠する場合はその旨を明記してください。

• event-attendee-experience は静的な案内表示（印刷された看板）を担当します。動的な現地アナウンス（場内放送、スケジュール変更を表示するライブ画面）はここで扱います。
• event-community-building は開催期間外の継続的なコミュニティを担当します。同じチャットスペースを今回の開催のチャネルと翌年のコミュニティの両方にできます。引き継ぎはメニュー4の最上位の段階で行います。

インタビュー

一度に質問は1つずつ行い、可能な場合は選択式にします。質問6〜8があるのは、以下のメニューが効果の現れ方、持続性、労力の面で大きく異なるため、デフォルトをユーザーに代わって選べないからです。

1. どの段階ですか：イベント前、現地で過ごす数日間、終了後の片付け期間、またはそのすべてですか？
2. どのような規模ですか：1つの部屋・1日、複数の部屋、複数日、または徹夜のハッカソンですか？リモート開催、ライブ配信、録画、報道対応はありますか？参加者同士が連絡を取る必要はありますか？
3. 参加者に連絡する人は何人いますか？また、そのうち今回のイベントで初めて文章を書く人は何人いますか？
4. 参加者がすでに利用しているチャンネルはどれですか？また、契約上、特定のチャンネルが必須になっているものはありますか（スポンサーへの納品物、会場のシステム、包括プラットフォームなど）？
5. レジスター（event-cultural-identity）はありますか？なければ、まずそちらへ案内し、ここでの内容には暫定とラベルを付けてください。このスキルはレジスターを実行するものであり、設定するものではありません。
6. 公開期限は決まっていますか？
7. 今回限りの開催ですか、それとも次回開催も予定している継続シリーズですか？（メニュー4が根本から変わり、メニュー1のアプリの段階も変わります。）
8. 労力の上限はどのくらいですか：イベント前に主催者が使える時間、開催中にチャンネルを見守れる人、終了後の週に対応する人はそれぞれどのくらいですか？
9. 参加者が自分では把握できない形で、何が失敗すると困りますか（ライブ配信、シャトルバス、唯一の入口、会場変更、ケータリングの不備など）？
10. これらのデフォルトの順位を変えるべき既存のものはありますか。たとえば、参加者がすでに利用しているコミュニティチャット、前回の参加者リスト、社内ライター、すでに使われているアプリなどですか？

以下の順位付けはすべてデフォルトであり、絶対ではありません。質問10の回答に照らして4つのメニューすべての順位を見直し、どの回答によってどの段階が動いたのかを説明してください。

同時に起きることの数と、それについて書く人の数

以下の各メニューでは、2つの規模の間で順位を組み替えます。

• 1つの部屋、1日、1人のライター。 リストだけで、それ以外は何もありません。
• 3つの部屋、2日間、5人のボランティアライター。 別のチャンネルを増やす前に、振り分けルールを決めます。

片方の規模では有効でもう片方では有効でない場合は、推奨内容がどちらの規模を想定しているかを明記してください。

ベンダー運営のイベントでは、契約によってすでにチャンネルが必須になっていることが多く（質問4）、順位を入れ替えるのではなく、段階を1つ削除します。それ以外では、資金調達の形態によって順位が変わることはありません。会場の費用を誰が負担したかに関係なく、メッセージが携帯電話に届くまでの時間は同じです。

ワークフロー

1. インタビューを行います。質問5の回答が空なら、そこで止めてevent-cultural-identityへ案内します。
2. チャンネルを選ぶ前に、今回実際に送信するメッセージの種類を列挙します：references/message-class-matrix-and-message-bank.md。メッセージが分かる前に選ぶ名簿は、流行に合わせて選んだものです。
3. チャンネル構成を選びます（メニュー1）。各チャンネルに明記した役割と、担当者1人を割り当てます。役割が明記されていないチャンネルは、使われなくなるチャンネルです。
4. 振り分け方針を選びます（メニュー2）。一度だけ開く文書ではなく、ライターがいる場所に記載します。
5. 一貫性を保つためのプロセスを選びます（メニュー3）。メッセージバンクの段階以上では、イベント前にバンクを作成します。
6. チャンネル一覧の掲載場所を案内します。そのページの担当はevent-marketing-planです（同ページの「コミュニケーションハブ」の段階）。これは参加促進側の成果物です。別のページを新たに作るのではなく、チャンネル構成（各チャンネル、役割、境界）を渡して、そこに掲載してもらいます。
7. デジタル空間に関する義務を確認します。行動規範はすべてのチャンネルに適用されます。報告先を自分で作成せず、該当する関連項目に確認してください。
8. イベント前に終了後の対応を決め、その日付をチャンネル上で公開します（メニュー4）。
9. 項目ごとに提示し、チャンネル構成、振り分け、一貫性、終了後の対応の順に、それぞれ承認を得てからチャンネルを作成します。

使用するハーネスに永続メモリがある場合は、次の内容を記録してください。

• 各チャンネルに明記した役割と担当者を含むチャンネル構成。
• 振り分けルール。
• 実際に送信したメッセージの種類と送信先。
• 最初のチャンネルでは届かず、別のチャンネルでも再送する必要があったすべてのメッセージ。
• 終了後の対応の決定とその日付。
• 使われなくなったチャンネル。

再送したメッセージと使われなくなったチャンネルを、次回開催時のチャンネル構成の変更に反映します。

メニュー 1 - チャネル一覧

段階的に追加していきます。各段で、下の段のチャネルにひとつ追加します。価値の軸は2つあります。リーチと速度は同じではなく、どの段も両方で最上位にはなりません。

• 価値：通常のお知らせが、登録者全員に届くか：announcement list > chat space == event app > status page
• 価値：計画の変更が、イベント中に対応できるほど速く届くか：event app == chat space > status page > announcement list
• 労力（セットアップに加え、ライフサイクル全体で必要になる継続的な運用とモデレーション）：event app > chat space > status page > announcement list
• 効率：announcement list > chat space > status page > event app

この4つの順位はいずれも、このスキル独自のものであり、実測したランキングではありません。このメニューが適切なのは、慎重に検討した結果であり、作り方によるものではありません。実際に、chat は2つの価値軸の両方で status page を上回りますが、コストも高いため、どちらも他方を支配しないという、評価が分かれる組み合わせがあります。== の同順位が成り立つ理由については、references/menu-ranking-rationale.md を参照してください。

チャネル一覧そのものは、ここでは段階のひとつではありません。このページは event-marketing-plan が管理します（「comms hub」の段階）。2つ目のページを公開するのではなく、そのページを拡張してください。ワークフローのステップ6を参照してください。

• お知らせリスト（デフォルト／最低限） - 集客時点ですでに存在し、登録者全員に確実に届きます。遅延は数時間です。メールではメッセージが遅すぎる状況になったら、すぐに次へ進んでください。つまり、当日に関するメッセージです。
• チャットスペース - 継続的に利用できる双方向の場です。実際のコストは、ライフサイクル全体にわたるモデレーションと、その場での行動規範の維持義務です。references/channel-roster-and-platform-notes.md を参照してください。Q2 の回答が「夜間」「複数日」「リモート」のいずれかである場合、または参加者同士が連絡を取り合う必要がある場合に導入してください。
• ステータスページ - 問題がまだ解決していないかを示す、唯一の正式なページです。このパターンはソフトウェアのインシデント告知を応用したものですが、引き継げない点が4つあります。references/wind-down-and-status-page.md を参照してください。誰かに知らせなくても自発的に確認されることはありません。別のチャネルからページへ誘導するプッシュ通知があって初めて機能します。Q9 で、参加者が自分では確認できないものが挙げられた場合に導入してください。
• イベントアプリ（利用が最も少ない段階） - 労力は最大で、速度はチャットと同等ですが、リーチではお知らせリストに劣り、効率を基準に選ばれることはありません。コミュニティ主催イベントの ROI を示す数値はありません。Q4 で署名済みの契約が必要になる場合、Q2 で同時進行の部屋が3つ以上あり、構成が1日に複数回変わる場合、または Q10 でコンテンツへの埋没コストを伴う既存のアプリがある場合に導入してください。
• **削除し、決して段階を下げない：**同じ役割を並行して担う2つ目のチャットプラットフォーム。モデレーションの負担が倍増し、それぞれのお知らせの対象者が半減します。
• **条件付きで削除：**Q9 の回答が空欄なのに設置されているステータスページ。「問題ありません」と報告するページは、人々に確認しなくてよいと思わせてしまいます。

メニュー 2 - メッセージクラスのルーティング

どのクラスのメッセージをどのチャンネルに流すか。

段階：

• すべてを1つのチャンネルに流す。
• 2チャンネルに分ける（誰も返信しない告知チャンネルと、参加者が会話するオープンなチャンネル）。
• 対象者セグメントごとのチャンネル。
• エスカレーション段階を設けた完全なメッセージクラスのマトリックス。

順位：

• 価値：メッセージが埋もれず、必要とする人に届くこと：マトリックス > セグメント別 > 2チャンネル分割 > 1チャンネル
• 価値：ボランティアの執筆者が、尋ねる相手がいなくても初回でメッセージを正しく振り分けられること：1チャンネル > 2チャンネル分割 > マトリックス > セグメント別
• 労力（作成して監視するチャンネル数と、ルールを最新に保つための調整）：マトリックス > セグメント別 > 2チャンネル分割 > 1チャンネル
• 効率：2チャンネル分割 > マトリックス > 1チャンネル > セグメント別

誰も実行できないルーティングポリシーでは、何もルーティングできません。そのため、執筆者にとっての運用しやすさが、このメニューの軸です。効率の順位もそれに左右されます。この軸を認めないなら、順位も成り立ちません。この軸と4つの順位はすべて、このスキル独自の構成であり、測定に基づく順位ではありません。

1チャンネルなら、構成上、曖昧さがありません。セグメント別のチャンネルは、悪い点を両方とも抱えています。メッセージごとにセグメントの所属を新たに判断する必要があり、執筆者は複数のチャンネルに投稿してその判断を解決するため、セグメント分けでなくすはずだったノイズが再び生じます。効率の順位が優劣の判定ではなく執筆者の運用しやすさに基づいている理由については、references/menu-ranking-rationale.md を参照してください。

• 2チャンネル分割（デフォルト） - イベントの告知を投稿するチャンネルと、参加者が返信するチャンネルを1つずつ設けます。チャンネルが1つ増える代わりに、ほとんどのイベントにある唯一のルーティング上の疑問に答えられます。Q3が複数の執筆者を示し、Q2が複数の部屋または開催日を示す場合に、こちらへ移行します。
• エスカレーション段階付きマトリックス（最も選ばれにくい段階） - 到達範囲と労力では最高ですが、効率を比べるすべての場面で劣ります。メッセージクラスを縦軸、チャンネルを横軸にした表に、エスカレーション段階を加えます。上記の2つの条件に加え、メッセージを見逃すと取り返しがつかない録画・ライブ配信版のイベントがある場合に、こちらへ移行します。
• すべてを1つのチャンネルに流す - 執筆者が1人で、1つの部屋で1日だけ開催するイベントなら、妥当な選択肢です。効率は最下位ではなく3位です。追加コストなしで運用しやすさが最も高いためです。
• 対象者セグメントごとのチャンネル - 効率は最下位で、コストがかかり、運用しやすさは最低です。セグメントがイベント期間を通じて実際に互いに重ならず、安定している場合にのみ選んでください。
• 格下げではなく、削除する項目： オーガナイザーからのダイレクトメッセージをルーティング段階にすること。次のシフトに記録が残らず、エスカレーションもできず、送信者自身がチャンネルになってしまいます。
• 条件付きで削除： Q2が1つの部屋／1日で、Q3が執筆者1人の場合の、マトリックスとセグメント別の段階です。その部屋だけに関係するメッセージクラスはありません。

引き継ぎ、再導出してはならないルーティングルールが1つあります： インシデント後の公式声明を発表する権限を持つのは、ただ1人だけです。他の誰も、どのチャンネルにも投稿してはなりません。samber/dev-event-organizer-skills@event-code-of-conduct がこのルールを全面的に定めています。ここで言い直すと、意見が食い違うルールがチーム内に2つできてしまいます。代わりに、すべてのチャンネルでこのルールを守ってください。マトリックスにはインシデント声明の行を設け、発表者としてその権限者を指定し、迅速さを理由としたローカルな例外は設けません。

メニュー 3 - 複数の執筆者間の一貫性

複数の執筆者が、内容をぶらさずに1つのレジスターを使う方法です。レジスター自体は別の場所で定義されています。ここで新たに定義するものではありません。

• 価値、一貫性：イベント中に実際に発信されるメッセージ間の一貫性：編集承認 > 事前作成済みメッセージバンク > チャンネルごとの担当者 > 共有クイックリファレンス > その場しのぎ
• 価値、特定の人を待たずに緊急のメッセージを発信できること：事前作成済みメッセージバンク > その場しのぎ > 共有クイックリファレンス > チャンネルごとの担当者 > 編集承認
• 労力（イベント前の時間とイベント中の調整）：編集承認 > チャンネルごとの担当者 > 事前作成済みメッセージバンク > 共有クイックリファレンス > その場しのぎ
• 効率：共有クイックリファレンス > 事前作成済みメッセージバンク > チャンネルごとの担当者 > その場しのぎ > 編集承認

最初の価値軸は、意図的に イベント中に実際に発信されるメッセージ に絞っています。その大部分は予測可能な種類のメッセージです。この対象に限れば、固定テンプレートは、内容がぶれる人間より優れています。「これまでに書かれたすべてのメッセージ」に範囲を広げると、バンクと担当者の順位は逆転します。そのため、ここで何かの順序を変更する前に、どの対象について述べているのかを明示してください。

4つの順位付け、5つの段階、すべての昇格条件は、このスキル独自の構成であり、実測による順位ではありません。このスコープが維持する優越関係については、references/menu-ranking-rationale.md を参照してください。

• 共有クイックリファレンス（デフォルト） - レジスターを「すること／しないこと」の項目と具体例にまとめた1ページです。考える作業は済んでいるため、労力はほぼゼロです。Q3で、ある執筆者がこのイベント向けに書いたことが一度もないとわかった場合は、上の段階に移します。
• 事前作成済みメッセージバンク - 遅延、部屋の変更、会場の変更、遺失物、ラストコール、閉場、キャンセルなど、発生が予想される種類のメッセージ用テンプレートです。時間に追われている状況でも送信できるよう、レジスターをそのまま正確なメッセージに固定します。開催回ごとに予測可能な時刻に繰り返す案内、たとえば会場閉鎖の警告、食事の準備完了通知、「3分後に開始します」という呼びかけについては、テンプレートを用意するだけでなく、さらに一歩進め、実際のタイムスタンプに合わせて当日のスクリプト全体を事前に作成してください。そうすれば、イベントの運営をしながら、決まった時刻にメッセージを作成して送ることを誰かが覚えておく必要はありません。イベント後も同様です。主催者はイベント後の満足度アンケートを自動送信します。イベント前に、終了時刻と送信時刻を記録したうえで、終了時のチャンネルにアンケートのメッセージを予約してください。アンケートの質問は samber/dev-event-organizer-skills@event-feedback が担当し、このスキルはリンクを含むメッセージの送信経路とスケジュールのみを扱います。
• チャンネルごとの担当者 - 各チャンネルの発信内容に責任を持つ担当者を1人ずつ置きます。バンクではカバーできない一貫性を確保できますが、担当者が不在の場合はメッセージの発信が遅くなります。公開ソーシャルアカウントは event-social-media が担当します。
• その場しのぎ - 共有リファレンスはありません。効率では4位で、最下位ではありません。労力をかけずに実際の速さを得られますが、比率はよくありません。その唯一の長所は、メッセージバンクを使えばより効果的に得られます。
• 公開前の編集承認（不利な段階） - 一貫性と労力では最上位、速度では最下位であり、ライブイベントでは速度の低さが最も問題になります。開催回が録画、ライブ配信、または報道の対象になる場合、スポンサー契約で逐語的な文言が定められている場合、あるいはQ3で、ほとんどの執筆者がレジスターを見たことがないとわかった場合に昇格させます。その場合でも、緊急のメッセージはバンクで対応できるようにしてください。
• 削除し、決して降格させない： チャンネルごとに、そこで書く人が独自に作ったレジスター。event-cultural-identity で定められているとおり、アイデンティティは固定され、調整できるのは表現だけです。

メニュー 4 - イベント終了後の整理

このメニューは、Q7の「一度限り／積み重ね型」の回答で決まるため、順位付けの前に質問してください。

選択肢：

• すべて開いたままにする。
• 読み取り専用のアーカイブ。
• エクスポートし、指定した保存期間の経過後に削除する。
• 継続的なコミュニティスペースに引き継ぐ。

順位：

• 価値：次回開催にも参加する人と引き続きつながれる：引き継ぎ > 開いたままにする > 読み取り専用のアーカイブ > エクスポート + 予定削除
• 価値：イベントが管理を続けないものが、イベントの名義で発言し続けない：エクスポート + 予定削除 > 読み取り専用のアーカイブ > 引き継ぎ > 開いたままにする
• 労力（終了時の作業時間、調整、終了後も監視し続ける必要がある人）：引き継ぎ > エクスポート + 予定削除 > 読み取り専用のアーカイブ > 開いたままにする
• コンプライアンスコスト（発生するレビューと、元に戻す際のコスト）：エクスポート + 予定削除 > 開いたままにする > 引き継ぎ > 読み取り専用のアーカイブ
• 効率性：読み取り専用のアーカイブ > エクスポート + 予定削除 > 引き継ぎ > 開いたままにする

到達可能性と責任回避は、6組中5組で相反するため、どちらも他方を支配しません。効率性の順位は、以下の各選択肢で説明する比率の議論とQ7に基づくものであり、支配関係の確認によるものではありません。詳しい説明はreferences/menu-ranking-rationale.mdを参照してください。

5つの順位、4つの選択肢、コンプライアンスコストの軸は、このスキル独自の構成であり、測定された順位ではありません。ただし、コンプライアンスコストを軽視してよいわけではありません。決して簡略化しないでください。

• エクスポートと削除は最も高コストです。元に戻せない唯一の選択肢であり、実行する_前に_、適法な根拠と保存期間を検討する必要がある唯一の選択肢です。
• 開いたままにするは正反対の理由で2番目です。レビューがまったく発生しないことが問題です。そのスペースに関する行動規範上の義務は、担当者がいないまま有効であり続けます。
• 引き継ぎには、同意に関する問題が伴います。参加者を新しいスペースに移すことは、新たな目的が生じることを意味するからです。
• 読み取り専用のアーカイブは最も低コストです。コンテンツはすでに承諾済みの条件のもと、投稿された場所に残り、新たに蓄積されるものはありません。

管轄区域を特定せず、保存期間を挙げず、実際の保存に関する判断は主催者自身の顧問弁護士に委ねてください。この判断は管轄区域、プラットフォームの利用規約、開催年によって変わります。

選択肢ごと：

• 読み取り専用のアーカイブ - デフォルト：投稿を停止し、コンテンツは閲覧可能なままにして、スペースが閉鎖されたことと移動先を告知します。何も破棄せずに継続的な義務を終わらせられる、最も低コストな選択肢です。
• エクスポート + 予定削除 - Q7が一度限りを示す場合の、デフォルトの_昇格先_：エクスポートし、削除日を事前にチャンネルで告知してから削除します。一度限りのイベントでは、次回開催に活用する予定のない参加者リストは負債になります。
• 継続的なコミュニティスペースへの引き継ぎ - 選ばれにくい選択肢です。到達可能性が最も高く、労力も最大です。昇格の条件は、次の両方を満たすことです。Q7が積み重ね型を示すこと、_かつ_継続的なスペースがすでに存在するか、運営を引き受けると名指しで約束した人がいることです。誰も管理しないスペースへの引き継ぎは、余計な手順を加えた「開いたままにする」にすぎません。次回開催の準備が始まった際に、現行の参加者リストを引き継ぎ先に戻すsamber/dev-event-organizer-skills@event-community-buildingと連携してください。このスキルが引き継ぎ先を管理します。
• すべて開いたままにする - 効率性では最下位です。終了時のコストはほぼゼロですが、継続的な義務が終わらない唯一の選択肢です。
• 削除し、段階を下げない - 告知なしの終了処理です。 参加者に知らせずチャンネルを閉鎖または空にすることです。そこに投稿された告知が本物だという信頼を損ない、次回開催のチャンネルはマイナスの状態から始まります。
• 条件付き削除 - Q8が、終了日以降に担当者がいないことを示す場合は、すべて開いたままにすること。 イベント名義の、モデレーションされていないスペースは、対応する人がいないまま行動規範上の義務を負うことになります。デジタルハラスメントに関する警告は、イベント開催中とまったく同じように適用されます。

失敗パターン

• 役割が明確でないチャンネル。 類似イベントにチャンネルがあるからという理由で作られ、2週目には静かになり、その後、重要なメッセージをひとつだけ伝えます。すべてのチャンネルに役割と担当者を明記し、そうでなければ作成しません。
• 投稿を担当する人員がいないチャンネルを開設する。 人々に情報を届けるのは、チャンネルの 存在 ではなく、チャンネルへの 投稿体制 です。これは、references/channel-roster-and-platform-notes.md に記載されている、実際に起きたハイブリッドイベントの失敗例に基づいています。
• 最も声の大きい人を基準に振り分ける。 スマートフォンを持っている人が、いつもの場所に投稿します。投稿者がいる場所に振り分けルールがなければ、そのルールは存在しないも同然です。
• チャットスペースを無料だと考える。 設定には1時間かかります。モデレーションはライフサイクル全体を通じて継続的に必要な役割であり、会場内と同じ行動規範の遵守義務があります。
• すでに参加している人にしか混乱を知らせない。 会場変更の連絡を必要とする人は、まだ会場におらず、チャットも見ていません。混乱の種類に応じて、都合のよいチャンネルではなく、情報を確実に届けるチャンネルへエスカレーションします。
• イベント後に終了方法を決める。 その頃には運営担当者が帰宅しており、意図的な判断ではなく、成り行きでチャンネルが開いたままになります。
• チャンネルごとに異なる話し方を作る。 メニュー3の削除ルールで扱います。イベント全体が4つの別々のイベントのように聞こえる状態として表れます。

測定

以下のしきい値はすべて自己設定であり、測定済みのベンチマークではありません。各しきい値はイベント前に決め、データが届いてから決めることは避けてください。

• 再送率（自己設定）：最初のチャンネルで届かなかったため、別のチャンネルにも再送する必要があったメッセージの割合です。再送があるたびに、振り分けルールが誤っていたか、チャンネルに投稿担当者がいなかったことを示します。上限を事前に決めてください。
• 振り分けられなかった質問（自己設定）：担当者のいない場所に届いた質問です。個人宛てのDM、SNSの返信、登壇者の受信箱などが該当します。件数を数え、どこに届いたかを記録してください。それが不足しているチャンネル、またはディレクトリに不足している項目です。
• チャンネルの沈黙（自己設定）：事前に定めた期間、運営からの投稿がないチャンネルです。沈黙しているチャンネルは、次回開催に向けた削除候補であり、モデレーションの問題ではありません。
• アンケートメッセージの予定どおりの送信（二値）：イベント後アンケートのリンクが、事前に設定した時刻に、振り分けルールで指定したチャンネルへ自動送信されました。回答率は samber/dev-event-organizer-skills@event-feedback で扱います。
• 終了処理の完了（二値）：開設したすべてのチャンネルに、終了状態と日付が設定され、終了予定日に実施されています。ここにある項目のうち、明確に合否を判定できる唯一のゲートです。
• 参加者満足度と再参加率は、チャンネル単位ではなくイベント全体で評価します。これらは samber/dev-event-organizer-skills@event-feedback と samber/dev-event-organizer-skills@event-market-fit で扱います。

呼び出し例

• 「登録者は400人で、2トラックのイベントを1日開催します。グループチャットは必要でしょうか。それともメールで十分でしょうか？」
• 「イベント中に3人で更新情報を投稿するのですが、それぞれ別人のような書き方になってしまいます。承認待ちで投稿が滞らないように、どうすればよいでしょうか？」
• 「会場が開催2週間前に変更になり、半数の参加者に伝わりませんでした。どこで知らせるべきだったのでしょうか？」
• 「会議は1か月前に終わりましたが、チャットが開いたままで、誰も見ていません。どうすればよいでしょうか？」

期待される出力：以下を含むチャンネル構成です。

1. 各チャンネルの役割、担当者、開設日を明記した一覧。
2. メッセージ種別の一覧と、選択した詳細度に応じた振り分けルール。
3. マトリックスで選択した段階に応じたエスカレーション段階。
4. 一貫性を保つプロセスと、バンク段階以上では文書化されたテンプレート。
5. 2つ目の競合するページを作らず、event-marketing-plan のチャンネルディレクトリに引き継ぐ一覧。
6. デジタルスペースの行動規範チェックと、CoC の関連スキルへの誘導。
7. イベント前に決定した、各チャンネルの終了方法と日付。

自己設定の項目にはすべてその旨を明記します。承認を得るため、セクションごとに提示します。

参照資料

• references/channel-roster-and-platform-notes.md — 公開済みのチャンネル一覧、チャンネルごとの役割、ハッカソンからカンファレンスには引き継げない要素、デジタル空間における行動規範ルール、プラットフォームカテゴリーに関する注記です。
• references/message-class-matrix-and-message-bank.md — メッセージクラスの分類、エスカレーション段階を含むルーティングマトリクスの例、望ましくない例、メッセージバンクの8つのテンプレートです。
• references/wind-down-and-status-page.md — 段階ごとの撤収チェックリスト4件、弁護士に渡す確認リスト、引き継げない要素を含むステータスページのパターンです。

本文全体で参照している関連スキルについては、「§ ここは兄弟スキルが担当」を参照してください。また、samber/dev-event-organizer-skills@event-cultural-identity（すべてのチャンネルが表現するレジスターを設定します。最初に実行してください）も参照してください。