1. はじめに
Copilot automations の作り方を覚えたあと、多くの人が次に詰まるのは「で、何を自動化すればいいのか」という点です。公式ドキュメントが挙げるユースケースは 3 例と簡潔で、しかも英語の要約にとどまるため、そのままプロンプト欄に貼って運用に乗せられる形にはなっていません。
この記事の目的は、その空白を埋めることです。automation の作成画面にコピー & ペーストしてすぐ試せる日本語プロンプトを 12 本、トリガーと必要なツールの組み合わせつきで提供します。分類は Issue 運用 / PR 運用 / 定期レポート / コード品質・保守の 4 つです。
前提となる概念・名称の整理（Copilot app / agent apps / Copilot automations の違い）、Local と Cloud の使い分け、作成手順、課金、セキュリティと権限設計は親記事「GitHub Copilot app で日常タスクを自動化する — Copilot automations 入門」で扱っています。本記事はサンプル集に徹します。
記載内容はすべて 2026 年 7 月時点の公式ドキュメントに基づきます。
2. サンプルの読み方と共通の前提
12 本すべてに共通する前提です。この章だけは飛ばさずに読んでください。 ここを読まずにプロンプトだけをコピーすると、権限過多や課金先の誤りにつながります。
2.1 各サンプルの表の見方
| 列 | 意味 |
|---|---|
| トリガー | automation を起動する条件。On a schedule / When an issue is created / When a pull request is opened など |
| 実行 | Local（自分の PC 上で実行、PC がオフなら動かない）か Cloud（GitHub 側で実行、PC がオフでも動く） |
| 必要なツール | 作成時の Tools ドロップダウンで許可する操作。update issue labels / comment / create an issue など |
Local と Cloud の違い、および Tools ドロップダウンの位置づけは、親記事の §3-1「Local automations と Cloud automations」を参照してください[^app-automations]。
2.2 ツールは最小権限で構成しています
各サンプルの「必要なツール」は、プロンプトが要求する操作を満たす最小限の組み合わせになるよう選んでいます。不要な破壊的ツール（close issues や push changes）は付与していません。
コメントを投稿するだけのサンプルに push changes を足す、といった「念のため」の追加はしないでください。automation に何を許すかは、承認レベルではなくリポジトリ権限とエージェントに与えるツールで制御するのが公式の指針です[^approvals-concept]。
2.3 対象リポジトリとスコープの制約
- Cloud automations は private または internal リポジトリでのみ利用できます。 public リポジトリでは使えません[^about-automations]
- スコープは単一リポジトリのみです。複数リポジトリを横断する集計は、この 12 本のいずれでもできません[^about-automations]
- 対応プランは Copilot Pro / Pro+ / Max / Business / Enterprise です[^plans]
2.4 PR トリガーのサンプルは Web の Agents タブで作る
PR をトリガーに使う 4-2 / 4-3 / 6-2 の 3 本は、Copilot app の Automations タブでは作成できません。 Copilot app 側のトリガーは Manual / スケジュール / Issue 作成時のみで、When a pull request is opened と When a pull request is synchronized は Web の Agents タブにしかありません。この 3 本は Agents タブから作成してください[^create-automations]。
Copilot app 側の Automations タブで作れるトリガーの一覧は、親記事の §3-2「トリガーの一覧」を参照してください[^app-automations]。
2.5 実行コストは作成者に課金されます
automation の実行コスト（GitHub Actions minutes + AI Credits）は、automation を作成したユーザーに課金されます[^about-automations]。チームで共有する定期レポート（5 章の 3 本など）を個人アカウントで作成すると、その個人に課金され続けます。組織で回す前提なら、課金先を組織にできる gh-aw の検討も含めて、親記事の §10「課金 — 誰にいくら請求されるか」を確認してください。
2.6 プロンプトに secret を書かない
起動されたセッションはリポジトリの閲覧権限を持つ全員に見えます。API キーやトークンをプロンプト本文に書かず、repository secrets で渡してください[^about-automations]。以下 12 本のプロンプトは、いずれも secret を必要としない設計にしています。
3. Issue 運用の自動化（3 件）
Issue はもっとも自動化の費用対効果が高い領域です。判断基準を言語化しやすく（ラベル分類、更新日での棚卸し、重複判定）、間違えてもラベルを直すだけで復旧できるためリスクが低いからです。
この 3 本はいずれも Issue のクローズを行いません。判定結果を残すところまでを自動化し、消す判断は人間に残すという方針で統一しています。
3.1 新規 Issue の自動トリアージ
| 項目 | 設定 |
|---|---|
| トリガー | When an issue is created（フィルタ: no:label） |
| 実行 | Cloud |
| 必要なツール | update issue labels / comment |
この Issue の本文とタイトルを読み、内容に応じて bug / enhancement / other の
いずれか 1 つのラベルを付けてください。
判断根拠を 2 行以内で Issue にコメントしてください。
再現手順が書かれていない bug には needs-repro ラベルも追加してください。
💡 Issue トリアージで自動操作できる対象は、公式ドキュメントによると labels, fields, issue type, closing issues, and assignees です[^approvals-concept]。
3.2 古い Issue の棚卸し
| 項目 | 設定 |
|---|---|
| トリガー | On a schedule（weekly） |
| 実行 | Cloud |
| 必要なツール | update issue labels / comment |
90 日以上更新のない open Issue を一覧し、それぞれについて
「まだ有効 / 情報不足 / 既に解決済みの可能性」を判定してください。
情報不足のものには stale ラベルを付け、必要な追加情報を尋ねるコメントを
投稿してください。Issue のクローズは行わず、判定結果だけを残してください。
3.3 新規 Issue の重複検出
| 項目 | 設定 |
|---|---|
| トリガー | When an issue is created |
| 実行 | Cloud |
| 必要なツール | comment |
この Issue と内容が重複している可能性のある既存 Issue を検索し、
候補が見つかった場合のみ、類似度が高い順に最大 3 件を
リンク付きでコメントしてください。
重複と断定せず「重複の可能性があります」という表現にとどめ、
クローズは行わないでください。
4. PR 運用の自動化（3 件）
PR 周りの自動化は「レビューを進める」ためではなく、「レビューに入る前の摩擦を減らす」ために使います。状況の可視化、CI 失敗の一次調査、説明文の下書き — いずれも人間のレビュー判断そのものは代替しません。
このうち 4-2 と 4-3 は PR イベントをトリガーにするため、Web の Agents タブから作成します（→ 本記事 2-4）。4-1 はスケジュール実行なので Copilot app からでも作れます。
4.1 毎朝の自分の open PR レビュー状況チェック
| 項目 | 設定 |
|---|---|
| トリガー | On a schedule（daily） |
| 実行 | Cloud |
| 必要なツール | create an issue |
私が作成した open な pull request を一覧し、それぞれについて
「レビュー待ち / 修正依頼あり / 承認済みでマージ待ち / CI 失敗」の
どの状態かを判定して、優先度順に表形式でまとめてください。
48 時間以上レビューが付いていない PR は先頭に「要リマインド」と明記してください。
結果は「PR レビュー状況（YYYY-MM-DD）」というタイトルの Issue 1 件にまとめて作成してください。
💡 Cloud 実行では、成果物の到達先（Issue / PR / コメント）を必ず用意します。読み取りだけのツール構成だと、結果を受け取る場所がありません。手元で読めれば十分なら、Issue を作らず Local automation として実行してください。
4.2 CI 失敗の調査と修正提案
| 項目 | 設定 |
|---|---|
| トリガー | When a pull request is synchronized（Web の Agents タブで作成） |
| 実行 | Cloud |
| 必要なツール | comment |
この pull request の CI が失敗している場合、失敗したジョブのログを確認し、
根本原因の仮説と具体的な修正方針を PR にコメントしてください。
テストコード側の問題か実装側の問題かを必ず区別してください。
flaky が疑われる場合は、その根拠（過去の同一失敗の有無）も示してください。
4.3 PR 説明文の補完
| 項目 | 設定 |
|---|---|
| トリガー | When a pull request is opened（Web の Agents タブで作成） |
| 実行 | Cloud |
| 必要なツール | comment |
この pull request の説明が空、または 3 行未満の場合のみ、
差分から推測した「変更の目的 / 主な変更点 / レビュー時の確認ポイント /
影響範囲」を PR にコメントとして提案してください。
説明が十分に書かれている場合は何もしないでください。
5. 定期レポートの自動化（3 件）
「毎週金曜に手作業で集計している」類のレポートは、automation にもっとも向いた対象です。3 本とも成果物を Issue 1 件または PR 1 本に集約し、人間が読み捨てられる形にしています。
一方で、この 3 本は課金先に注意が必要な分類でもあります。チーム共有のレポートを個人が作成すると、その個人に Actions minutes と AI Credits が課金され続けます（→ 本記事 2-5）。
5.1 週次リリースノート草案
| 項目 | 設定 |
|---|---|
| トリガー | On a schedule（weekly） |
| 実行 | Cloud |
| 必要なツール | push changes / create a pull request |
前回のリリースタグ以降にマージされた pull request を収集し、
CHANGELOG.md に追記するリリースノートの草案を作成して pull request を開いてください。
分類は「新機能 / 改善 / バグ修正 / 破壊的変更 / 内部変更」の 5 つ。
各項目は 1 行で、PR 番号へのリンクを付けてください。
破壊的変更がある場合は移行手順を必ず添えてください。
5.2 日次・週次のリポジトリ状況レポート
| 項目 | 設定 |
|---|---|
| トリガー | On a schedule（daily / weekly） |
| 実行 | Cloud |
| 必要なツール | create an issue |
過去 24 時間のリポジトリの動きを要約した Issue を 1 件作成してください。
含める内容: マージされた PR、新規 Issue、クローズされた Issue、
main への直接コミット、レビュー待ちが滞留している PR。
最後に「今日注意すべきこと」を 3 点以内で挙げてください。
5.3 週次の技術的負債レポート
| 項目 | 設定 |
|---|---|
| トリガー | On a schedule（weekly） |
| 実行 | Cloud |
| 必要なツール | create an issue |
コードベース内の TODO / FIXME / HACK コメントを収集し、
モジュール別に集計した Issue を 1 件作成してください。
新しく追加されたもの、1 年以上放置されているものを区別して記載し、
着手すべき上位 3 件を理由つきで推薦してください。
6. コード品質・保守の自動化（3 件）
この分類だけは、automation がコードそのものに手を入れます。したがって push changes / create a pull request を許可する必要があり、4 分類のなかでもっとも慎重な設計が要る領域です。
3 本ともプロンプト側で明示的にスコープを絞っています（draft PR に限定する、扱うファイルは 3 つまで、矛盾がなければ PR を作らない）。この「やらないことの指定」を削らないでください。
6.1 ナイトリーの失敗テスト修正
| 項目 | 設定 |
|---|---|
| トリガー | On a schedule（daily） |
| 実行 | Cloud |
| 必要なツール | push changes / create a pull request |
main ブランチの最新コミットに対してテストスイートを実行してください。
失敗しているテストがあれば、原因を調査して最小限の修正を試み、
draft pull request を作成してください。
PR 本文には「失敗したテスト名 / 原因の仮説 / 修正内容 / 残る懸念」を
箇条書きで記載してください。
修正できなかった失敗は、修正せずに PR 本文の「未解決」欄に列挙してください。
6.2 コード変更に追従したドキュメント更新
| 項目 | 設定 |
|---|---|
| トリガー | When a pull request is opened（変更ファイルフィルタ: src/**、Web の Agents タブで作成） |
| 実行 | Cloud |
| 必要なツール | push changes / create a pull request / comment |
この pull request のコード変更が、docs/ 配下のドキュメントや README.md の
記述と矛盾していないか確認してください。
矛盾がある場合のみ、該当箇所を更新する pull request を作成してください。
矛盾がなければ「更新不要」とだけコメントし、PR は作成しないでください。
6.3 テストカバレッジの改善
| 項目 | 設定 |
|---|---|
| トリガー | On a schedule（weekly） |
| 実行 | Cloud |
| 必要なツール | push changes / create a pull request |
カバレッジレポートを確認し、カバレッジが最も低いモジュールを 1 つ選んでください。
そのモジュールに対する単体テストを追加する draft pull request を作成してください。
既存のテスト規約（配置場所・命名・アサーションスタイル）に必ず従い、
プロダクションコードは変更しないでください。
1 回の PR で扱うファイルは 3 つまでとしてください。
注記: 依存関係の自動更新（Dependabot 相当）を Copilot automations の公式ユースケースとして明示した記述は、本調査の取得範囲では確認できませんでした（未確認）。依存関係更新は Dependabot の利用を第一候補としてください。
7. 運用の勘所と落とし穴
12 本を並べると全部作りたくなりますが、実運用に乗せる段階で効いてくるのは次の 5 点です。プロンプトの書き方そのもの（やらないことの明示、出力形式の固定、スコープ制限）は親記事の §6-2「プロンプト設計のコツ」で扱っているため、ここでは運用面に絞ります。
| 落とし穴 | 兆候 | 対策 | 参照先 |
|---|---|---|---|
| 一度に多く作りすぎる | どの automation の出力か追えない | まず 1〜2 本だけ動かす | 7-1 |
| 成果物が捨てにくい形になる | レビューを経ずに main へ入る経路がある | Draft PR / Issue / コメントに限定する | 7-2 |
| 任意 cron 前提で設計する | 「毎週月曜 9 時」が指定できない | 毎時 / 毎日 / 毎週で足りなければ gh-aw | 7-3 |
| automation が他人から見えない | 誰が何を持っているか分からない | Automations ビューで定期的に棚卸しする | 7-4 |
| 課金先が作成者個人のまま | チーム共有レポートを個人が抱える | レポート系から gh-aw へ移行する | 7-5 |
7.1 まず 1〜2 本だけ動かす
最初から 12 本を登録すると、どの automation がどの出力を出したのか追えなくなります。Issue トリアージ（3-1）と朝の PR 状況チェック（4-1）あたりを 1〜2 本だけ作り、1 週間動かして出力を見てからプロンプトを詰めるのが最短ルートです。作成時の Create and run で 1 回実行して挙動を確認できます[^app-automations]。
7.2 出力が「捨てられる形」になっているか確認する
Copilot cloud agent は仕様上、PR を Ready for review にできず、承認もマージもできません[^risks]。この設計に逆らわないことが安全側の運用です。各サンプルの成果物が Draft PR / Issue / コメントに収まっているか、レビューを経ずに main に入る経路がないかを、有効化前に必ず確認してください。
7.3 スケジュールは毎時 / 毎日 / 毎週の 3 択
Copilot automations では任意の cron 式を指定できません。粒度は毎時 / 毎日 / 毎週の 3 つだけです[^create-automations]。「毎週月曜の朝 9 時」のような指定が必要なら、5 章の定期レポート系は Copilot automations ではなく GitHub Agentic Workflows（gh-aw）側で組む判断になります。手段の選び分けは親記事の §8「手段の選定フローチャート」を参照してください。
7.4 automation は作成者にしか見えない
作成した automation は本人にしか表示されません（リポジトリ管理者にも見えません）。チームで複数人が別々にレシピを登録すると、誰がどの automation を持っているか誰も把握できない状態になります。定期的にユーザーレベルの Automations ビュー（リポジトリ横断で自分の automation を一覧できる画面）で棚卸ししてください[^create-automations]。異動・退職時の引き継ぎ手順も、運用開始前に決めておくのが安全です。
7.5 課金先は個人。組織運用なら gh-aw を検討
実行コストは automation を作成したユーザーに課金されます[^about-automations]。個人の作業効率化（3 章 / 4 章）なら問題になりませんが、チーム全体が読む定期レポート（5 章）を個人が抱えると、課金の非対称が起きます。組織課金にできる gh-aw への移行を、レポート系から検討してください。
8. まとめ
- Copilot automations 用の日本語プロンプト 12 本を、Issue 運用 / PR 運用 / 定期レポート / コード品質・保守の 4 分類で提供しました。すべてトリガーと最小権限のツール構成つきです
- PR をトリガーにする 4-2 / 4-3 / 6-2 は Copilot app では作れません。 Web の Agents タブから作成してください
- Cloud automations は private / internal 限定、単一リポジトリのみ、課金先は作成者。この 3 点は 12 本すべてに共通する制約です
- コードに手を入れる 6 章の 3 本は、プロンプト側でスコープを絞る記述（draft PR に限定 / ファイルは 3 つまで / 矛盾がなければ PR を作らない）を削らないでください
- 最初は 3-1 の Issue トリアージを 1 本だけ作り、1 週間動かしてからプロンプトを詰めるのが習熟の近道です
9. 参考情報
9.1 関連記事
- GitHub Copilot app で日常タスクを自動化する — Copilot automations 入門
- GitHub Copilot で定期実行ジョブは作れる？ 4 つのスケジュール実行を徹底整理
- GitHub Agentic Workflows（gh-aw）徹底ディープダイブ — 自然言語で書く「Continuous AI」の全貌
- GitHub Copilot を Markdown でカスタマイズする全機能マップ — instructions・AGENTS.md・Agent Skills の使い分け
- GitHub Copilot カスタマイズ応用編 — Custom Agent と Agent Skills の実践セットアップ
9.2 出典の参照方法
本記事の出典（一次情報）は、すべて本文中の脚注として付与しています。URL と確認日を含む一覧は、ページ末尾の Footnotes（脚注）を参照してください。
[^about-automations]: About Copilot automations — GitHub Docs. https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-automations （2026-07-29 確認）
[^create-automations]: Creating automations with Copilot cloud agent — GitHub Docs. https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/create-automations （2026-07-29 確認）
[^app-automations]: Using automations in the GitHub Copilot app — GitHub Docs. https://docs.github.com/en/copilot/how-tos/github-copilot-app/using-automations （2026-07-29 確認）
[^approvals-concept]: automation の rationale と approvals（概念） — GitHub Docs. https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-automation-rationale-and-approvals （2026-07-29 確認）
[^risks]: Risks and mitigations for Copilot cloud agent — GitHub Docs. https://docs.github.com/en/copilot/concepts/agents/cloud-agent/risks-and-mitigations （2026-07-29 確認）
[^plans]: Plans for GitHub Copilot — GitHub Docs. https://docs.github.com/en/copilot/get-started/plans （2026-07-29 確認）
この記事の執筆にあたり、AI の支援を受けています。掲載内容は調査日（2026-07-29）時点の公式ドキュメントに基づきます。機能仕様は更新される可能性があるため、実装前に最新の公式情報をご確認ください。
