要点まとめ
- Automationsは一度書けば繰り返し実行してくれるタスクです。トリガーはManual・Hourly・Daily・Weekly・Issue createdの5種類。
- 実行時刻は仕事が始まる直前に設定します（デモは午前9:00）。クラウドかローカルかもここで決めます。
- プロンプトは自然言語で書き、プロジェクトを選んだらCreate and runで即テスト実行。スケジュールを待つ必要はありません。
- 実行結果は1枚のレポートにまとまります。PRがリスク別にグループ化され、安全なマージとベストな次の一手が示され、ワンクリックで新規セッションにできます。
Automate recurring developer tasks with the GitHub Copilot app
チャンネル:GitHub4:13
About automations
ドキュメント:docs.github.com
Automations in the GitHub Copilot app
ドキュメント:docs.github.com
スクリーンショットはGitHub公式チュートリアル動画から取得しました。トリガー一覧とクラウド実行の詳細は、上記の公式ドキュメントで照合しています。
各スクリーンショットは元動画の該当時刻にリンクしています。GitHubとCopilotはGitHub, Inc.の商標です。本ページは独立した解説記事です。
最初のAutomationsを段階的に作る
自動化を設定する
- 1
新しい自動化を作成して名前を付ける
Copilot appでAutomationsセクションを開き、New automationをクリックします。後で一覧から見分けられる名前を付けましょう（デモでは「Daily Dependabot triage」）。名前は自分のためのラベルで、Copilotが従うのはあくまでプロンプトのほうです。
名前はツールではなく、タスクの内容に合わせて付けます。1:28 に視聴 - 2
リズムに合うトリガーを選ぶ
メニューのトリガーは5種類です。自分で起動するManual、時刻表で動くHourly・Daily・Weekly、そして新しいissueが現れたときに自動実行されるIssue created。デモではDailyを午前9:00のままにしています——仕事が始まる直前です。
試行錯誤はManualで、信頼できたらスケジュールへ。1:00 に視聴 - 3
タスクを一度、自然言語で書き下す
プロンプトの書き方は通常のセッションと同じです。デモでは「DependabotのオープンPRを確認し、リスクでグループ化し、安全にマージできるものを強調し、minorとmajorのアップデートを区別し、CIの通過を確認し、ベストな次の一手を短くまとめて」と依頼しています。
セッションに貼れる要件は、そのまま自動化にできます。2:00 に視聴 - 4
対象プロジェクトを指定する
プロンプトの下で、自動化が対象とするリポジトリを選びます。デモはDependabotのPRが集まっているtailspin-toysを選択。モデルやエージェントの制御も、通常のセッションと同じようにここで調整できます。
1つの自動化に1プロジェクト。レポートが集中します。2:08 に視聴
初回実行を開始して観察する
- 5
保存して、そのまま初回を実行する
Createをクリックすれば午前9:00のスケジュールに登録されます。あるいはCreateの隣の矢印からCreate and runを選ぶと、保存と同時に手動実行が始まり、待ち時間ゼロで動きを確認できます。
プロンプト検証はCreate and runが一番速い方法です。2:20 に視聴 - 6
Your automationsに並ぶのを確認する
保存された自動化はAutomations画面にカードで表示され、トリガーバッジとライブのステータスが付きます。ここからいつでも手動実行できますし、やりたいことが見えてきたらプロンプトを編集すればOKです。
トリガー・リポジトリ・最終実行が一枚で分かります。2:26 に視聴 - 7
PRリストではなくレポートを読む
朝いっぱいかかっていた作業が、整理された1つのレポートになって返ってきます。デモの実行ではDependabot PRがリスクレベルごとにグループ化され、安全なものはPassingと表示され、ヘッダーには「Last run 1m ago」の刻印があります。
リスクグループとCIステータスで、アップデートPRの受信箱が置き換わります。3:00 に視聴
結果を活用する
- 8
安全にマージできるものと重大アップグレードを分ける
Low・Mediumの行——まとまったdev依存のbumpやminorアップデート——は、軽く目を通すだけでマージできます。Highの行にはDo not mergeの文字。majorなフレームワークや統合のアップグレードで、別途レビューに値します。
レポートの仕事は「マージ可/保留」の線引きを明確にすることです。3:08 に視聴 - 9
ベストな次の一手に従う
表に加えてCopilotは実行順序も提案します。安全なものからマージし、独立したmajor bumpは後回しにし、CIを既に壊している関連Astroアップグレードは一連の移行としてまとめて扱う、という具合です。
サマリーが何をどの順で、なぜ行うかを教えてくれます。3:20 に視聴 - 10
発見をそのままフォローアップセッションへ
レポートがAstro 6アップグレードのような実作業を浮かび上がらせたら、説明し直す必要はありません。レポート下の入力ボックスに依頼を書けば、Copilotは既に持っているコンテキストのまま新しいセッションを開始し、自動化の記録は監査証跡として残ります。
レポートがそのまま修正作業の始点になります。3:28 に視聴
クラウドかローカルか:自動化の実行場所を選ぶ
Run in the cloudトグルはエージェントの実行場所を決め、影響はプロセスの居場所だけでは済みません。公式デモではオフのままローカル実行です。両モードの実際の違いは次のとおりです。
- 1ローカル実行は自分のマシン上で動くため、電源が入っている間しか実行されません。プロンプトが実験段階の間の自然な選択です。なおドキュメントによると、カスタムCRON式を受け付けるのはローカルの自動化だけです。
- 2クラウド実行は「コンピューターの電源がオフでも実行を続けます」——トグル自身の説明文のとおりです。クラウド実行にはリポジトリでCopilot cloud agentを有効化する必要があり、作業はワークスペースではなくリポジトリ内で行われます。
- 3クラウドモードではToolsドロップダウンでCopilotにできることを制限できます。変更のpush、ラベル更新、PRオープンなど。ドキュメントはタスクに必要なツールだけを選ぶよう勧めており、無人のジョブを短いリードでつなぎ止められます。
- 4コストとアクセスも異なります。クラウド自動化にはprivateまたはinternalリポジトリが必要で、実行ごとのActions分数とAIクレジットは自動化の作成者に課金されます。書き込み権限があれば誰でも作成できます。
実用的なデフォルトはこうです。Create and runでローカルにレポートの形を整え、それからトグルを入れてスケジュールに任せる。トリガーが1つ足りなければ、アプリはトリガーの追加にも対応しています。いずれかのトリガーが発生すると自動化が実行されます。
何を自動化するか（そして実行のデバッグ方法）
GitHub公式のアドバイスは「すでに無意識にやっている退屈なタスクから始める」ことです。アイデアが要れば、Automations画面にはIssue triage・Changelog draft・Repo auditのテンプレートが用意されています。
- 1日次の雑務が最適解です。Dependabot PRの仕分け、新着issueのトリアージ、リポジトリ全体のCIがグリーンかの確認。動画の経験則は「明確な判断基準がある作業は、無人で回せる」です。
- 2テンプレートから始めて、プロンプトはセッションと同じ文体で書き直します。具体的な動詞、明示的なグループ化、定義された出力。デモのプロンプトは「PRを見て」ではなく、グループ・ラベル・サマリーを要求しています。
- 3自動化はブラックボックスではありません。実行ごとにAutomationsセクションに、何が・いつ・何をしたかが記録されます。結果がおかしいときは、プロンプトを触る前に実行記録のセッションを読みましょう。
- 4レポートが実作業を指したら、結果から直接フォローアップセッションをつなげます。デモのAstro 6アップグレードはこの方法で始まり、自動化のコンテキストをそのまま引き継ぎました。
- 5プロンプトの結果が気に入らないなら、自動化を編集して要求を引き締め、Create and runで即テスト。次のスケジュールを待つ必要はありません。
自動化は「脳みそのついたcronジョブ」と捉えましょう。大きく曖昧な月次ものより、小さく明確で頻繁に回るタスクが勝ちます。あるリズムが信頼を得たら、次のリポジトリに複製すれば十分です。