チームで使う自動化は、担当者だけでなく、管理する人・費用の負担先・閲覧範囲まで決めて始めましょう。
担当者が作った便利な自動処理を、チームの仕事として使い続けたい。しかし、その人が異動したら誰が直せるのか、利用料は誰にかかるのかが曖昧なままでは、安心して任せにくくなります。
GitHubは2026年10月28日、Shared Copilot Automationsの段階的な提供を発表しました。リポジトリに属する共有の自動化として、チームで設定を管理できる更新です。個人用から共有用への切り替えは、単なる公開範囲の変更ではありません。作成前に、運用の責任分担を整理しましょう。
この記事でわかること
- 共有化の意味：設定を見られる人、編集できる人、費用の負担先が変わります。
- 始める条件：対象プラン、リポジトリの種類、管理者の許可を確認します。
- 運用の決め方：担当交代・予算・外部ツールの範囲を先に整理します。
作った人が離れても、共有の自動化は続く
Copilot Automationsは、決まった時刻やGitHub上のイベントなどをきっかけに、クラウドのエージェントを動かす仕組みです。今回のSharedでは、作成した個人ではなくリポジトリに属する形で管理します。作成者がチームを離れたりアクセス権を失ったりしても、自動化は継続します。GitHubの発表
たとえば、問い合わせから登録された不具合を調べる処理を、一人の開発担当だけに任せない運用が考えられます。ただし、「止まらないこと」が常に正解とは限りません。担当交代後も不要な処理が動き続けないよう、見直す担当者と、停止を判断する人を置く必要があります。
設定の共有と、実行内容の閲覧を混同しない
| 確認すること | Personal | Shared |
|---|---|---|
| 設定の閲覧・編集 | 作成者のみ | 閲覧権限のある人が閲覧、書き込み権限のある人が編集 |
| 実行履歴の閲覧 | リポジトリの閲覧権限がある人 | リポジトリの閲覧権限がある人 |
| AI creditsの負担 | 作成者 | リポジトリの所有組織または所有ユーザー |
| GitHub上の実行名義 | 作成者 | Copilot |
特に注意したいのは、Personalでも実行内容が本人だけに見えるわけではない点です。設定が個人用でも、セッションのプロンプトやログをリポジトリの閲覧者が確認できます。個人的なメモや、閲覧者へ共有すべきでない情報を入れる場所として扱わないでください。公式の種類別比較と安全上の説明
作成前に、利用条件と運用担当をそろえる
対象はCopilot Pro・Pro+・Max・Business・Enterpriseで、Sharedは段階的な提供です。対象プランであっても、全アカウントへ同時に表示されるとは限りません。Automationsはprivateまたはinternalリポジトリが対象で、publicやmanaged userアカウント所有のリポジトリなどには利用できない条件があります。cloud agentと自動化の許可も必要です。
組織所有のリポジトリでSharedを動かす場合は、管理者が組織課金のcloud agent利用を許可します。作成時にTypeでSharedを選びますが、作成後にPersonalとSharedの種類は変更できません。先に用途を決める理由はここにあります。
「不具合の一次調査」を始める場合の整理例
以下は導入時の検討例です。実際にこの処理を設定した結果ではありません。
- 目的：不具合の再現に必要な情報と、確認できた結果をまとめる。修正の本番反映は含めない。
- きっかけ：対象のissueが作成されたときに動かし、不要な案件を含めない条件を決める。
- 確認担当：調査結果を見る人と、設定を変更できる人を決める。休暇・異動時の引き継ぎ先も残す。
- 許可する道具：調査に必要なツールだけを選び、書き込みや外部連携は必要性を別に判断する。
- 試行と停止：テスト用の対象で、意図したきっかけだけで動くか、結果がどこに見えるかを確かめる。
自動化の設定はコードとは別に保存され、GitのコミットやPRで一緒に管理されるわけではありません。変更履歴を見られることと、コードのレビューを通ったことは別です。設定を変える際の社内確認も決めておきましょう。
予算は「一回の停止」と「次回を始めない」を分ける
自動化には一回ごとのAI credits上限と、日・週・月ごとの上限があります。日・週・月の上限は、すでに動いている処理を止めません。新しい実行を始めないための制限です。一回の処理が使いすぎるのを止めたい場合は、per-runの上限も検討します。その最低値は30 AI creditsです。GitHub Actionsの実行時間は別に請求されます。自動化の利用量制限
たとえば「今月の予算を決めたから、一回の調査が長引いてもその金額で止まる」とは判断できません。費用の担当者には、月全体の利用と一回の許容範囲を別々に相談します。上限で止まった調査を、調査済みの結論として使わないことも重要です。
コードレビューの請求設定も使っている場合は、レビュー費用の請求先と利用者制限とは別の設定として確認してください。組織課金という言葉が共通でも、対象となる処理は同じではありません。
実務上の注意
GitHub用ツールの操作対象は設定したリポジトリですが、MCPで接続した外部ツールは、認証情報や接続設定によって別のシステムへ届く場合があります。「このリポジトリ用だから、外部への操作もそこに限定される」とは考えないでください。PRやワークフローの承認も省かず、必要な権限だけで試します。
本記事は公式資料の整理であり、個別組織での提供状況、実操作、請求結果を検証したものではありません。
まとめ
Shared Automationsの利点は、個人の便利な処理をチームで管理し続けられることです。導入時は、管理担当・費用の負担先・閲覧範囲・停止条件を先にそろえましょう。担当者が離れても動くからこそ、誰が見直すかを決めておくことが大切です。
よくある質問
いまあるPersonalをSharedに変更できますか？
作成後の種類変更はできません。新しい共有処理を検討する場合は、既存処理との二重実行を避ける移行方法も決めてください。
Personalの実行履歴は、自分だけが見られますか？
いいえ。実行セッションはリポジトリの閲覧権限がある人に見えます。設定の閲覧範囲と区別してください。
月の上限を設定すれば、動いている処理も止まりますか？
月の上限は新規実行を防ぐためのものです。一回の処理を上限で止めたい場合はper-runを検討し、Actionsの費用も別に確認します。
出典・参考情報
運営元について
AXメディアは、株式会社ジーズ AX事業部が運営しています。AX事業部では、AI研修・AIエージェント開発・ローカルLLM開発・補助金／助成金の活用支援を提供しています。
