GitHubは2026年10月28日（米国時間）、年次イベント「GitHub Universe 2026」にあわせて、GitHub Copilotの機能「Copilot Automations」の更新を発表した。Copilot Automationsは、指示文と、許可した道具（ツール）と、起動の条件（トリガー）を組み合わせて、AIにリポジトリの作業をクラウドで自動実行させる機能だ。今回の更新は3つある。1つ目はコストの管理で、1回の実行、1日、1週間、1か月のそれぞれに、AIの利用量（AI Credits）の上限を設定できるようになった（GitHub Changelog）。2つ目は学習で、自動化が自分の成果を振り返り、改善案を出す（GitHub Changelog）。3つ目はチームで共有できる自動化だ。同じ日に、GitHub Actionsの中でAIエージェントを動かす「GitHub Agentic Workflows」が一般提供になった（GitHub Changelog）。
注意したいのは、一般提供になったのはAgentic Workflowsで、Copilot Automationsではない点だ。Copilot Automationsは6月2日に有料のCopilotの利用者向けに提供が始まったが、プレビューか一般提供かは公式の資料に書かれていない。学習の機能も、自動化が勝手に書き換わる仕組みではない。改善案が出るたびに人に通知が届き、人が1件ずつ受け入れるか断るかを決める。対象のプランは、Copilot Pro、Pro+、Max、Business、Enterpriseだ。changelogに提供地域の制限は書かれていないが、日本語での案内は本稿では確認できなかった（10月30日時点）。
GitHubはエンジニア向けの道具だが、今回の更新で示された設計は、エンジニアでない読者にも参考になる。支出の上限、起動の条件、変更の承認、課金の行き先をどう決めるかは、マーケティングや事務所の定型業務を自動化するときにも同じように問題になるからだ。本稿では、10月28日のchangelog 4本と6月の提供開始時の資料を読み比べ、AI Creditsの単価で上限の数字を計算し直す。そのうえで、月次レポート、投稿予約、問い合わせ振り分けを自動化に任せる前に確かめることを判断表にまとめる。
何が発表されたか──changelog 4本を項目ごとに読む
Universeの発表は、1本の告知ではなく、複数のchangelogに分かれている。Microsoftでエンジニアリング部門を率いるJay Parikh氏の全体の記事は、Copilot Automationsを「リポジトリの中でAIが動くワークフローを作れる機能」と紹介し、成果から学んで改善を提案するようになったと書くだけだ。細かい仕様は、それぞれのchangelogに書かれている。以下の表は、Copilot Automationsに関わる3本と、Agentic Workflowsの1本の要点を並べたものだ。
| changelog | 主な内容 | 対象 |
|---|---|---|
| 新しいツール、トリガー、コスト管理 | REST APIからの起動。課題（Issue）、プルリクエスト、ディスカッション、セキュリティ警告にかかわる24のイベントへの対応。自動化をつないで順に動かす機能。新しいGitHubのツール20種。独自のMCPサーバーのツール。AI Creditsの上限設定 | Copilot Pro／Pro+／Max／Business／Enterprise |
| 成果から学び、自分を改善する | 成果のシグナルを分析する「改善用の自動化」が、元の自動化の指示文、ツール、トリガーの変更を提案する。人が1件ずつ受け入れるか断るかを決める | 同上 |
| チームで共有するワークフロー | 共有の自動化は、作った人ではなくリポジトリに属する。AI Creditsはリポジトリの持ち主に請求される。GitHub上の操作はCopilotの名前で記録される | 同上（順次提供） |
| Agentic Workflowsの一般提供 | Markdownで書いた自動化を、GitHub Actionsの設定ファイル（YAML）に変換して動かす。読み取り専用の権限が初期設定で、隔離された環境で動く | GitHub Free／Team／Enterprise（Copilotのエンジンを使う場合はCopilotのライセンスが必要） |
トリガーは、6月の提供開始時から大きく増えた。6月の時点では、1時間ごと、毎日、毎週の定期実行と、課題の作成、プルリクエストの作成・更新だけだった。8月にはコメントでの起動が加わり、今回はREST APIからの起動が加わった。GitHubは例として、Jiraのチケットの仕分け、Sentryに上がった不具合の修正、PagerDutyの障害対応の調査を挙げている。外部のサービスで何か起きたら、自動化を動かせるということだ。ツールの面では、MCP（Model Context Protocol）のサーバーをリポジトリの設定で追加し、使うツールを選べるようになった。GitHubの外のサービスにも手が届くようになった分、何を許可するかの判断は重くなる。
支出上限の仕組み──「止まる」と「待つ」の違い
コストの管理は、今回の更新で読者にとって最も実務に関わる部分だ。上限は、AI Creditsという単位で、1回の実行、1日、1週間、1か月ごとに設定でき、自由に組み合わせられる。ただし、上限に届いたときの動き方は単位によって違う。1回の実行の上限に届くと、その実行はその場で止まる。1日、1週間、1か月の上限に届くと、新しい実行は期間が切り替わるまで待たされる。上限を設定しない自動化は、これまでどおり動く。つまり、上限は自分で設定しない限りかからない。
AI Creditsは、6月1日の従量課金への移行で始まった単位だ。GitHubのドキュメントによれば、1 AI Creditは0.01ドルである。消費量は、入力、出力、キャッシュのトークン数をもとに、各モデルの公開APIレートで計算される。各プランの料金と、毎月含まれるクレジットの金額は同じに設定されている。この単価を使うと、上限の数字はドルに直して考えられる。
| プラン | 月額 | 毎月含まれる利用量 | AI Creditsに直すと |
|---|---|---|---|
| Pro | 10ドル | 基本10ドル＋変動分5ドル＝15ドル | 1,500 |
| Pro+ | 39ドル | 基本39ドル＋変動分31ドル＝70ドル | 7,000 |
| Max | 100ドル | 基本100ドル＋変動分100ドル＝200ドル | 20,000 |
| Business | 1ユーザー19ドル | 1ユーザー19ドル（組織で合算できる） | 1ユーザー1,900 |
| Enterprise | 1ユーザー39ドル | 1ユーザー39ドル（組織で合算できる） | 1ユーザー3,900 |
個人のプランの変動分は、5月12日のGitHubの発表によるもので、GitHubは「時期によって変わる」としている。上限の目安を立てる例を挙げる。毎週1回、月4〜5回動く週次レポートの自動化に、1回の実行あたり100クレジット（1ドル）の上限を設ければ、月の最大は500クレジット（5ドル）前後になる。Proの1,500クレジットのうち3分の1ほどだ。ただし、1回あたり実際に何クレジット使うかは、モデルや作業の量で変わり、公式の資料に目安は示されていない。最初の数週間は上限を低めにして実績を記録し、そのうえで上限を決め直すのが安全だ。この数字は単価から計算した例で、実際に動かして確かめた結果ではない。
もう1つ、「待つ」という動きには注意が要る。1日の上限に届いたあとに起動の条件が満たされても、その実行は翌日まで始まらない。問い合わせの仕分けのように、すぐに処理したい作業では、上限に届いたことが処理の遅れになって表に出る。費用を抑える設定が、対応の速さとぶつかる場面があるということだ。上限の設定は、費用だけでなく、どれだけ遅れてもよいかとあわせて決める必要がある。支出の上限の考え方は、Walmartの「AIエージェントに買わせる」の記事でも、購買の場面について整理した。
「学習する自動化」の正体──変わるのは指示文・ツール・トリガー
「自分を改善する自動化」と聞くと、AIが知らないうちに動き方を変えていく姿を思い浮かべるかもしれない。しかし、changelogを読むと、仕組みはもっと地味で、人の承認が前提になっている。自動化は、GitHubの上に成果のシグナルを残す。GitHubが挙げる例は、課題の仕分けの自動化が付けたラベルを人が付け直したか、AIのコードレビューの指摘を開発者が受け入れたか、性能改善の自動化が出したプルリクエストを管理者がマージしたか、の3つだ。
学習させたい場合は、Copilotに「自分を改善する自動化」を作るよう頼む。するとCopilotは、自動化を組で作ることがある。GitHubの例では、プルリクエストが開かれるたびに動くレビュー用の自動化と、毎週1回、開発者の反応を分析して改善案を出す改善用の自動化の組だ。改善用の自動化が、元の自動化の指示文、ツール、トリガーの変更を提案すると、人に通知が届く。人は変更を1件ずつ受け入れるか断るかを決め、受け入れたものだけが反映される。共有の自動化には変更の履歴が残り、指示文、ツール、トリガーがどう変わってきたかを後から確かめられる。
ここから分かるのは、学習の機能で変わるのは「設定」であり、モデルそのものではないという点だ。それでも、承認するのは重い判断になる。たとえば、改善案に「ツールを足す」や「トリガーを増やす」が含まれていれば、承認した時点で自動化ができることと動く回数が増える。そうなれば、費用も権限も広がる。改善案は文章の手直しと同じ感覚で受け入れるのではなく、権限と費用が変わる変更として確かめる必要がある。もう1つの論点は、シグナルが「人が直したかどうか」で測られることだ。担当者が忙しくてAIの誤りを直さずに放っておけば、その誤りは「受け入れられた」と読まれかねない。学習の質は、人がどれだけ丁寧に直したかに左右される。
共有の自動化と連鎖──課金の行き先と「誰の操作か」
6月の提供開始時、自動化は作った人のものだった。トークンの利用は、作った人に通常の従量課金で請求された。今回の共有の自動化では、自動化はリポジトリに属し、作った人がチームを離れても動き続ける。リポジトリを読める人は誰でも共有の自動化を見られ、書き込める人は誰でも編集できる。AI Creditsは、自動化を作った人ではなく、リポジトリを持つ組織または個人に請求される。GitHub上の操作は、特定の人ではなくCopilotの名前で記録される。
この変更は、担当者が辞めたら自動化も止まるという、属人化の問題を解く。一方で、新しい確認点も生む。BusinessやEnterpriseでは、クレジットを組織全体で合算できる。上限のない共有の自動化が1つ動き続ければ、ほかのメンバーが使う分まで減っていく。組織のリポジトリで共有の自動化を動かすには、管理者がポリシー「Allow use of Copilot cloud agent billed to the organization」を有効にする必要がある。つまり、組織の財布をAIに開けるかどうかを、管理者が最初に決める仕組みだ。自動化の種類（個人か共有か）は、作った後に変えられない点にも注意したい。
連鎖の機能も同じ視点で見ておきたい。各トリガーには「Can be triggered by（誰が起動できるか）」の設定がある。初期設定では人だけだが、Copilotも含めるように変えられる。新しく加わった「Automation run succeeded」「Automation run failed」のトリガーを使えば、ある自動化が終わったら次の自動化を動かす、という多段の流れが組める。便利な一方で、失敗したら別の自動化が動き、それがまた失敗する、という連鎖も仕組みのうえでは起こりうる。連鎖を組むときこそ、1日や1か月の上限を設定しておく意味がある。エージェントに身元を持たせて権限を管理する考え方は、Gemini agentの記事で整理した。
Agentic Workflowsは「守り」を先に組む
同じ日に一般提供になったAgentic Workflowsは、Copilot Automationsとは別の製品だ。GitHubの研究開発部門のGitHub Nextが始めたオープンソースの取り組みで、課題の仕分け、CI（自動テスト）の失敗の分析、ドキュメントの更新、テストの作成といった、判断が要る作業を自動化する。自動化はMarkdownの文章で書き、それが通常のGitHub Actionsの設定ファイルに変換される。エージェントは、GitHub Copilotでも、ほかのコーディングエージェントでもよい。
読み比べて目立つのは、安全のための仕組みが最初から組み込まれている点だ。エージェントは初期設定では読み取り専用の権限で動き、「Agent Workflow Firewall」の内側にある隔離されたコンテナで実行される。エージェントの出力は「safe outputs」という手順を通り、変更が反映される前に、専用の脅威検知の処理が内容を調べる。費用の面では、見積もりのコマンド「gh aw forecast」が試験版を卒業し、脅威検知の分のクレジットと、月ごとの費用の幅を出せるようになった。Copilot Automationsは「上限を決めて止める」、Agentic Workflowsは「動かす前に見積もる」と、費用の管理の仕方が違う。提供の対象はGitHub Free、Team、Enterpriseで、初期設定のCopilot CLIのエンジンを使う場合はCopilotのライセンスが要る。
定型業務に置き換えた判断表──月次レポート・投稿予約・問い合わせ振り分け
ここからは、GitHubの設計を、マーケティングや事務所の定型業務に当てはめる。サイトやLP、ECストアのコードをGitHubで管理している企業なら、Copilot Automationsをそのまま使う場面もありうる。そうでなくても、ほかの自動化ツールやAIエージェントを選ぶときに、同じ項目を確かめられる。以下は、本稿がchangelogの仕様をもとに整理した目安で、実際に運用して確かめた結果ではない。
| 確認する項目 | GitHubの仕様 | 月次レポート | 投稿予約 | 問い合わせ振り分け |
|---|---|---|---|---|
| トリガー | 定期実行、イベント、コメント、REST API、ほかの自動化の成功・失敗 | 毎月の定期実行。締め日のずれに注意 | 人の承認をトリガーにし、AIの判断だけで公開しない | 受付のたびに起動。件数が急に増えた日の回数を見積もる |
| 支出上限 | 実行・日・週・月。実行の上限は「止まる」、期間の上限は「待つ」 | 1回の実行の上限を中心にする。待たされても実害は小さい | 1日の上限に届くと予約が遅れるので、余裕を持たせる | 1日の上限に届くと仕分けが翌日まで止まる。上限に届いたら人に知らせる |
| 学習（改善案） | 指示文・ツール・トリガーの変更を提案し、人が1件ずつ承認 | 指標の定義が変わる改善案は、クライアントとの合意なしに受け入れない | 文面の改善案は、PR表記や禁止表現の確認を通してから受け入れる | 仕分け先の追加は権限の拡大なので、責任者が承認する |
| 学習のシグナル | 人が直したか、受け入れたか、マージしたか | 数字の修正を記録に残す運用にする | 差し戻しの理由を残す | 振り分け直しを必ずシステム上で行い、口頭で済ませない |
| 共有と課金先 | 共有はリポジトリの持ち主に請求。操作はCopilot名義 | 担当者が替わっても続くよう共有にする。費用の部門を決める | 誰の承認で公開したかを、Copilot名義とは別に記録する | 個人情報を扱うので、見られる人の範囲を先に絞る |
| 連鎖・外部ツール | 成功・失敗で次を起動。MCPで外部ツールを追加 | 集計→資料作成の連鎖は、途中で人が確認する段を入れる | SNSに投稿するツールは最後に足す | 失敗のときは人に回す流れを先に作る |
3つの業務で差が出るのは、上限に届いたときに「待つ」ことの影響と、外に出るかどうかだ。月次レポートは待たされても実害が小さく、学習の効果も出やすい。月次レポートをAIに任せる範囲は、ClaudeのDashboards・Motionの記事で扱った。投稿予約は、クライアントやファンの目に直接触れるので、学習で文面が変わる余地を小さくし、公開の前に必ず人を通したい。問い合わせ振り分けは、遅れがそのまま顧客対応の質に響くうえ、個人情報を扱う。上限を低く設定するより、上限に届いたときに人に回す流れを先に設計しておくほうが大事になる。
導入前に決めておくこと
自動化の機能は、更新のたびに「できること」が増えていく。だからこそ、導入する側は、できることの一覧よりも、止め方、変え方、払い方を先に決めておきたい。GitHubを使うかどうかに関係なく、自動化ツールやAIエージェントを導入する前に、次の点を社内で決めておくとよい。
- 上限の単位：1回の実行の上限と、期間の上限の両方を設定する。期間の上限に届いたら、処理が止まるのか、待つのか、人に回るのかを確かめる
- 誰の財布か：共有の自動化の費用がどこに請求されるか、組織で合算した枠をどこまで使ってよいかを決める
- 改善案の承認者：指示文の手直しは担当者、ツールとトリガーの追加は責任者、と承認する人を分ける
- シグナルの残し方：AIの誤りを人が直したことが、システム上の記録に残る運用にする
- 連鎖の範囲：自動化がほかの自動化を起動してよいかを決め、初期設定（人だけが起動できる）を変えるときは理由を残す
- 操作の名義：AIの名前で記録された操作について、どの人の承認によるものかを追えるようにする
今回の更新で、GitHubは自動化を「作って終わり」から「育てる」ものに変えようとしている。ただし、育て方の主導権は、改善案を承認する人の側に残されている。AIに任せる仕事と、人が持つ仕事の線引きは、Claude Duet・Meta Muse・OpenAI dotsの比較記事でも整理した。自動化が学ぶほど、人の承認の質が成果の質を決めるようになる。事務所・D2Cがいま決めておくべきなのは、どのツールを使うかより、誰が、何を、いくらまで承認するかだ。
本記事は、株式会社TORIHADAが運営するクリエイターエコノミー専門メディア「CREATORS POST」がお届けしました。最新のマーケティング・クリエイター動向を、実務目線で発信しています。
この記事はAIを活用して書いています。
