GitHubのマーケ担当が手順書をCopilotに渡し、イベントの定型作業を自動化——属人の段取りを「動く仕組み」にする型

※ 本記事は2026年9月13日時点の公開情報に基づきます。最新情報は各社公式発表等をご参照ください。

GitHubは2026年9月11日、同社で日本・韓国のマーケティングを担当する社員が書いた記事「Marketing ops as code」を公式ブログに掲載しました。筆者は、手順書を書き出してGitHub Copilotに渡し、会話しながら自動化を育てたと説明しています。以前は手作業で数日かけて組み立てていたイベントが、今では1つのGitHub Issueから立ち上がると書いています（出典: GitHub 公式ブログ）。

定型作業を「入力・合図・記録」に分けて置く

運営責任者として注目したのは、自動化の前に手順が具体的に書き出されている点です。筆者によると、イベントの承認後は、ランディングページの複製、チャネルごとのUTM付きリンクの作成、招待メールの下書きと送信担当チームへの依頼、プロジェクトボードへの登録が続きます。イベントまで毎朝、登録者リストをダウンロードして整え、関係者に状況を共有し、イベント後はCRM取り込み用の整形とレポート作成があります。筆者は、個々の作業は難しくないものの、リンクの貼り間違いや1日の抜けが起きうると書いています（出典: GitHub 公式ブログ）。

仕組みは3つの部品です。Issueフォームは「申込書」で、イベント名、日付、地域、キャンペーン名、対象層の入力欄を持ちます。ラベルは「スイッチ」で、event-setupのようなラベルは分類ではなく起動の合図です。GitHub Actionsは「機械」で、ラベルが付くとフォームの項目を読み取って作業します。event-setupが付くと、ランディングページの作成から要約コメントの投稿まで6つの作業を、筆者の記述では数分で行います。登録者の確認は毎朝のスケジュール実行です（出典: 同上）。

私たちは、起動条件・入力・記録が別々の場所に置かれている点を、再現しやすい型と読みました。「数日」「数分」は筆者の記述で、計測値は示されていません。

人が決め、機械が動く——承認・リハーサル・監視

リポジトリ直下のAGENTS.mdは、キャンペーンの命名規則、会計四半期と日付の対応、地域ごとのタイムゾーン、良い招待メールの条件を書いたチームの手順書です。Copilotはこれを読み、似た過去のイベントを探して、命名規則に沿ったキャンペーン名を提案し、招待メールを2案下書きします。筆者の分担は「GitHub Copilotが下書きし、私が決める」で、キャンペーン名、メール件名、日付は筆者の承認を得てから先に進みます（出典: GitHub 公式ブログ）。

全ワークフローが実行前に確認するDRY_RUNスイッチがオンの間は、外部システムに触れずに動作だけを通しで行います。筆者はこれを、実験を恐れずに済んだ理由と書いています。ほかにプルリクエストごとのテストと全変更のコードレビューも挙げ、失敗も明かしています。毎朝の登録者確認が、リストの古さに誰かが気づくまで5日間、静かに失敗したことがあるといい、定期実行にはすべて失敗を大きく知らせる手段を持たせるよう勧めています（出典: 同上）。

私たちは、承認、リハーサル、失敗の検知が機能と同じ重さで語られている点に注目しました。

中小企業の定型業務への翻訳——最初の1つの選び方

筆者の助言は、週の中で最も繰り返しの多い作業を1つ選び、触るツールにAPIかCLIがあるかを確認することから始まります。次に、入力を受けるフォーム、実行の合図のラベル、1工程を行う処理という最小の形を作り、信頼できるまでドライランで動かして育てます（出典: GitHub 公式ブログ）。

GitHubを使わない職場でも、順序は借りられます。私たちは次の4点に整理しました。

1. 作業を1つだけ選ぶ。
2. 外から操作できる入口（APIかCLI）を確認する。
3. 手順書に「きっかけ・手順・終わりの記録・人が決める点」を書く。
4. リハーサル用のスイッチと、失敗の通知を最初に入れる。

削減できる時間は業務ごとに異なります。まず1つで測りましょう。

まとめ

• GitHubは2026年9月11日、日本・韓国のマーケティング担当社員が手順書をCopilotに渡して自動化した自チームの事例を公式ブログに掲載した
• 構成はIssueフォーム、ラベル、GitHub Actionsの3つ。event-setupラベルでイベント準備が動き、登録者確認は毎朝のスケジュール実行
• Copilotが下書きして筆者が決める分担で、DRY_RUNスイッチ、テスト、レビューを備える一方、登録者確認が5日間静かに失敗した事例もある
• 筆者の助言は、最も繰り返しの多い作業を1つ選び、最小の形をドライランで試して育てる順序

記事に効果を示す計測値はなく、GitHub社員1名の自チームの事例です。それでも、書き出す、リハーサルできる状態にする、失敗が聞こえる状態にする、そのうえで任せるという順番は、属人の段取りを仕組みに移すときの型になると私たちは考えます。