イベント運営を「人が作業するもの」から「実行されるワークフロー」へ
イベントの企画には、テーマ設定や対象者の選定など、人間の判断が欠かせません。一方で、企画が承認された後には、ランディングページの複製、UTMパラメータ付きURLの生成、メール依頼、プロジェクトボードへの登録、参加者リストの整形、CRM登録用データの作成といった定型作業が続きます。
これらは一つひとつが難しいわけではありません。しかし、手作業で繰り返すほど、次のようなミスが発生しやすくなります。
- URLの貼り間違い
- キャンペーン名や日付の表記揺れ
- 定期的な参加者リスト更新の抜け
- CRMに取り込む列や形式の誤り
- 担当チームへの依頼漏れ
GitHubで紹介された事例は、こうした業務をGitHub Issues、Issue Forms、Labels、GitHub Actions、GitHub CopilotのSkillsで構成しました。ポイントは、AIにいきなりコードを書かせることではありません。既存の業務手順を文章化し、実行可能な手順として扱うことです。
中心にある考え方は「Issueを業務の起点にする」こと
この事例では、イベント1件を1つのGitHub Issueとして管理します。Issueには企画内容、議論、進捗、実行結果が集約され、イベントに関する情報を参照するURLも一つにまとまります。
Issueを単なるチケットではなく、ワークフローの入力データとして扱う点が重要です。構成要素は次のとおりです。
- Issue Form：イベント名、開催日、地域、キャンペーン名、対象者などを構造化して入力する
- Label：
event-setupのようなラベルを処理開始のトリガーにする - GitHub Actions：Issueの内容を読み取り、外部サービスとの連携や成果物の生成を実行する
- Project Board：イベントの進捗や担当タスクを可視化する
- Issue Comment：自動処理の結果やレポートを元のIssueに記録する
たとえば、イベント作成用のラベルが付与されたとき、Actionsが次の処理を順番に実行します。
- 過去のイベントを複製して新しいランディングページを作成する
- チャネルごとのUTM付きURLを生成する
- 招待メールを文書ファイルとして作成し、リポジトリに保存する
- メール配信や地域マーケティング担当向けの依頼Issueを作成する
- プロジェクトボードにイベントを登録する
- 実行結果を元のIssueにコメントする
この設計では、イベントの状態変化がGitHub上の操作として表現されます。ラベルの追加が「準備開始」、Issueへのコメントが「処理結果」、プルリクエストのマージが「手順変更の承認」に相当します。
APIやCLIがあれば、既存ツールを置き換えずに連携できる
自動化の対象はGitHubだけではありません。ニュースの事例では、イベント管理プラットフォームのAPIや、CRMの公式CLIを利用して外部サービスと接続しています。
ここから得られる実務上の示唆は、業務自動化のために最初から大規模な統合基盤を作る必要はないということです。対象ツールに、次のようなスクリプト可能な入口があれば、既存の業務フローに組み込めます。
- REST APIなどのAPI
- 公式CLI
- ファイルのインポート・エクスポート機能
- Webhookや定期実行に対応した仕組み
重要なのは、ツールの種類ではなく、入力と出力を機械的に扱えることです。イベント管理システム、CRM、フォーム、分析サービスなどが対象になります。
ただし、APIやCLIが存在するだけで安全に自動化できるわけではありません。認証方式、権限範囲、レート制限、エラー時の挙動、個人情報の取り扱いなどを設計に含める必要があります。
AIエージェントの役割は「判断の代行」ではなく「手順の実行支援」
この事例では、イベントの企画段階でGitHub Copilotを使い、過去のイベントやチームのルールを参照しながら、キャンペーン名や招待メールの案を作成します。
リポジトリにはAGENTS.mdを配置し、次のようなチーム固有の知識をMarkdownで定義しています。
- キャンペーン名の命名規則
- 会計年度と日付の対応
- 地域ごとのタイムゾーン
- 招待メールの品質基準
- 企画時に確認すべき質問
ここでの役割分担は明確です。
- Copilot：過去の例や手順に基づいて候補を作成する
- 担当者：内容を確認し、日付、対象者、文面、実行可否を決定する
- GitHub Actions：承認済みの入力に基づいて定型処理を実行する
この分離によって、完全自動化の硬直性と、完全手作業のミスを両方抑えています。例外的なイベントには人が介入でき、標準的な処理は自動化できます。
Markdownの手順書を「Skills」として管理する
事例の特徴的な点が、CopilotのSkillsをMarkdownファイルとして管理していることです。たとえば、イベント後のリード登録処理やレポート作成を、SKILL.mdに文章で定義します。
概念的には、次のような手順をファイル化します。
# Post-event lead upload
1. イベント管理ツールから参加者一覧を取得する
2. 不要な列を除外し、CRM登録用の形式に変換する
3. 会社名や対象項目を確認する
4. CRM登録依頼用のIssueを作成する
5. イベントの追跡用Issueに処理結果を記録する
6. 未完了の追跡タスクをクローズする
この方法の利点は、業務担当者が普段使っている言葉で手順を記述できることです。業務知識をコードに変換できるエンジニアが常に必要とは限りません。まずは、担当者の頭の中にある作業手順を、再現可能な形で書き出します。
また、Skillsをプルリクエストで変更し、レビュー後にマージする運用にすれば、手順書にもソフトウェア開発と同じ変更管理を適用できます。地域や部門ごとに処理が異なる場合も、共通の仕組みを維持しながら手順だけを差し替えられます。
「自動化するほどガードレールが必要」になる
外部サービスを操作し、顧客や参加者のデータを扱う自動化では、処理が動くことだけを目標にしてはいけません。ニュースの事例では、次のような安全策が紹介されています。
DRY_RUNで本番システムを触らずにリハーサルする
DRY_RUNというリポジトリ変数を用意し、オンの場合は外部システムを変更せず、処理の流れだけを確認します。
- ランディングページを実際には作成しない
- 他のリポジトリに依頼Issueを作成しない
- 参加者リストを外部へ共有しない
- 生成されるデータや処理内容だけを確認する
外部システムを操作するActionsには、最初からドライランモードを組み込むと、検証と本番実行を切り替えやすくなります。
レビューとテストを必須にする
ワークフローやSkillsの変更をプルリクエストで管理し、レビューとテストを通過したものだけを利用します。業務担当者が作成した手順でも、実行結果が外部システムに影響するなら、変更管理の対象にすべきです。
特にレビューでは、次の観点が重要です。
- 意図しない外部サービス操作が含まれていないか
- 対象イベントや対象地域を誤って広げていないか
- 個人情報をログやコメントに出力していないか
- 失敗時に再実行しても二重登録にならないか
- 認証情報に過剰な権限を与えていないか
シークレットをコードやログに残さない
APIトークンや認証情報をリポジトリに直接記述してはいけません。シークレット管理機能を利用し、プッシュ時の検知や保護も有効にします。
また、認証情報を隠すだけでなく、Actionsのログに参加者情報やアクセストークンが出力されないように設計する必要があります。自動化では、正常系の処理だけでなく、例外時のログがどこまで公開されるかも確認すべきです。
スケジュール実行には「失敗を知らせる仕組み」が欠かせない
参加者リストの取得や更新を毎朝自動実行する場合、処理が動かないこと自体が問題になります。しかし、定期ジョブは失敗しても誰も気づかない状態になりやすい領域です。
実際の事例でも、参加者スクリーニングのワークフローが5日間静かに失敗し、リストが古いままになっていたという教訓が共有されています。
定期実行するワークフローには、少なくとも次の仕組みを用意したいところです。
- 失敗時に担当者やチームへ通知する
- 最終成功時刻を記録する
- 入力件数や出力件数の異常を検出する
- 一定時間更新がない場合にアラートを出す
- 再実行時の重複処理を防ぐ
- 成功時にも最低限の監査ログを残す
自動化は、処理を人から取り上げるだけでは完成しません。処理が止まったときに、人へ戻す仕組みまで含めて完成です。
エンジニアが業務自動化に取り組むときの設計ポイント
この事例を、社内の開発・運用業務に応用するなら、次の順序が現実的です。
1. 最も繰り返しが多い作業を一つ選ぶ
最初からイベント全体や部門全体を自動化するのではなく、毎週発生する単一作業を選びます。
- 定型レポートの生成
- 問い合わせ情報の転記
- リリース後の通知作成
- 定期的なデータ整形
- 複数ツールへの同一情報の登録
2. 入力、処理、出力を分解する
手順を次の3つに分けると、Issue FormやActionsに落とし込みやすくなります。
- 入力：誰が、何を、どの形式で指定するか
- 処理：どの順番で、どのツールを操作するか
- 出力：どこに、どの形式で、何を記録するか
3. まずは1ステップだけ自動化する
最初からすべてを連携させるのではなく、Issueの作成をきっかけにファイルを一つ生成する、といった小さな単位から始めます。入力形式やエラー処理を確認しながら段階的に処理を追加します。
4. ドライランと再実行を設計する
本番システムを変更しないモードを用意し、同じ入力で何度実行しても破綻しないようにします。特にCRM登録やチケット作成では、再実行による重複を避ける仕組みが重要です。
5. 運用担当者が理解できる記録を残す
自動処理の結果は、ログだけでなく、業務を担当する人が読める形で残します。元のIssueに処理概要、対象件数、作成された成果物、エラー内容をコメントすれば、後から経緯を追いやすくなります。
自動化に向かない領域もある
「手順書を実行可能にする」アプローチは強力ですが、すべての業務を自動化すべきという意味ではありません。
次のような処理は、人間による確認をワークフローに残すべきです。
- 参加者や顧客の適格性を最終判断する処理
- 例外が多く、判断基準が頻繁に変わる処理
- 誤登録した場合の影響が大きい処理
- 法務、プライバシー、契約に関わる判断
- 入力データの品質が安定していない処理
AIには候補作成や分類を任せられても、承認や対外的な意思決定まで無条件に委ねるべきではありません。業務のどこまでを自動化し、どこで人間の承認を要求するかを明示することが、設計の中心になります。
まとめ：業務知識をリポジトリで管理する
Marketing Ops as Codeの本質は、マーケティング専用ツールをGitHubで置き換えることではありません。業務手順、入力項目、判断基準、実行結果を、レビュー可能な形でリポジトリに集約することです。
AIエージェントは、既存の手順を参照して候補を作り、定義されたSkillに沿って作業を進められます。GitHub Actionsは、承認済みのイベントを検知して、APIやCLIを通じて外部サービスを操作します。そして、レビュー、テスト、DRY_RUN、シークレット保護、監視によって、業務自動化を安全に運用します。
始めるなら、次の最小構成で十分です。
- 入力項目を定義したIssue Form
- 実行開始を示すLabel
- 一つの処理だけを行うGitHub Actions
- 手順を記述したMarkdownファイル
- 外部変更を防ぐDRY_RUN
- 失敗を知らせる通知
「コードを書ける人だけが自動化できる」のではなく、業務を再現可能な手順として説明できる人が、自動化の入口に立てる。この考え方は、マーケティングだけでなく、開発、運用、カスタマーサポート、バックオフィスにも応用できます。
出典： GitHub Blog