VISIONHUB DAILY AI BRIEF / 2026.10.30
2026年10月30日 公開

AIの分類やレビューを直し続けている、PM・開発リーダーへ

AIが、仕事への反応を見て
手順の改善を提案する

GitHub Copilot Automations は、ラベルの修正やレビューへの反応を材料に、自動化の設定を見直す案を作れます。人は提案の理由と差分を読み、承認または拒否。承認した設定を、次の実行に使います。[1]

2026年10月30日版公式発表:2026年10月28日資料確認:10月30日 JSTGitHub Copilot Automations

この記事で判断すること:手順を直す手間が減るか。承認と権限の境界を保ちながら、小さく試せるか。

ONE-PAGE BRIEF

改善案を作るAIと、適用を決める人

公式仕様を基にした概念図
矢印は処理の順序です。学習量や改善効果の実測ではありません。モデルの重みの再学習と、自動化の設定変更を区別しています。[1][3]

誰の課題分類・レビューの手直しと、指示の見直しが続く人。

今回の変化実際の反応から、次回の設定変更を提案する。

判断する条件承認の手間、誤り、費用を含めて負担が減るか。

図の内容をテキストで読む

通常の自動化が分類やレビューを実行する。その結果に対する人の修正・採用を別の自動化が振り返り、指示文、使える操作、実行条件の改善を提案する。人が変更理由と差分を確認し、承認した設定を次回使う。拒否なら現状を維持する。通常実行ごとの承認とは別であり、モデルの再学習を説明する図ではない。

01

誰の、どんな課題?

自動化の後にも、同じ手直しが残る

Issue(課題票)の分類をAIに任せても、担当者が毎回ラベルを直している。コードレビューの指摘を投稿しても、開発者が採用しない。PMや開発リーダーには、結果を直す仕事に加えて「次からどう頼むか」を考える仕事が残ります。

PM・運用担当

分類の基準を更新できない

ラベルの修正履歴は残っても、何が共通の間違いかを調べ、指示文を書き直す時間が取れません。

開発リーダー

レビューの指摘を絞り込めない

有用な指摘と、チームで重視しない指摘が混ざる。レビュー担当のAIを、チームの判断に合わせて調整したい状況です。

今回の発表は、GitHub上の反応を材料に、その見直し案を作る機能です。変更案は人の確認を経てから適用します。[1]

記事の整理負担が減るかは、改善案を確認する時間と、適用後の誤りを含めて判断します。

02

仕組みと承認の境界

結果を見る自動化が、手順の変更案を作る

Copilotに「結果を見て改善案を出す自動化」を依頼すると、作業を行うものと結果を振り返るものを組み合わせたグループを作れます。公式は、PR(コード変更案)をレビューする自動化と、反応を週次で分析する自動化の組み合わせを例示しています。[1]

矢印は処理の順序です。拒否した改善案は適用しません。改善提案の通知を受け、内容と設定差分を確認できます。[3]

承認するのは「自動化の設定を変える提案」

通常の実行は、決めた時刻やGitHubのイベントをきっかけに、選んだ操作権限で動きます。すべての実行前に承認を求める、という意味ではありません。[3] AIモデル自体の重みを再学習する機能としても発表されていません。

見直す対象は、指示文(何を行うか)、ツール(使える操作)、トリガー(いつ動くか)。権限や実行回数に関わる変更もあり得るため、文面だけでなく設定全体を読みます。[1]

03

公式の例と、チームでの応用

ラベルの修正と、指摘の採用を振り返る

公式の例

Issue分類:人がラベルを変えたか

GitHubは、AIが付けたラベルを人が修正した履歴を、改善の材料に挙げています。[1]

応用する場面
記事の仮想例「ログインできない」という相談に、再現確認なしで「不具合」を付けてしまう。
変更案の例
「再現条件が不明な相談は『要確認』にする」という分類基準を指示文に追記する。
人の確認
ラベルを変えた理由は本当に誤分類か。担当替えや優先度変更を、AIの間違いと混同していないか。
公式の例

コードレビュー:開発者が指摘を採用したか

公式の構成例では、PRのレビューと、その指摘への反応を週次で分析する自動化を分けています。[1]

応用する場面
記事の仮想例命名への細かい指摘が多く、チームが必要とする不具合やテスト不足の確認が埋もれる。
変更案の例
「自動整形で扱える指摘は省き、動作の誤りやテスト不足を優先する」と指示を調整する。
人の確認
採用されない重要なセキュリティ指摘まで減らさないか。採用率だけを成功指標にしない。

公式は、性能改善の自動化についても、作成したPRが採用されたかを材料に挙げています。[1] 反応は判断の手がかりであり、技術的な正しさを保証する採点ではありません。

上の具体的な相談文・分類基準・レビュー方針は、記事の応用提案です。GitHubがそのまま提供するテンプレートや、実運用で得た結果ではありません。

04

通常の自動化、前回の記事との違い

今回変わるのは、次回に向けた運用の見直し

対象何を扱うか人が決めること
通常の自動化設定した指示と条件で、繰り返し作業する結果を見て、自分で設定を直す
今回の自己改善実行後の反応から、設定変更を提案する改善案を承認・拒否し、次回の設定を決める
10/29版
Copilot Fusion
1回のタスクの中で、モデルと処理方式を選ぶ依頼条件と努力量を指定し、結果を確認する

スマホでは表を横に動かして読めます。通常の自動化との比較は本機能の新規性を整理したものです。Fusionとの比較根拠:公式発表。[1][8]

自動化の管理画面では変更履歴を追えます。一方、設定はリポジトリのコードとは別に保存され、GitのコミットやPRで自動的に管理されるわけではありません。承認した理由と設定の記録を、チームの運用に合わせて残すと比較しやすくなります。[2][3]

05

利用前に確かめる条件

プランだけでなく、リポジトリの設定も必要

対象プランCopilot Pro / Pro+ / Max / Business / Enterprise。この機能の提供一覧にFreeは含まれていません。[2]
リポジトリprivate または internalのみ。publicリポジトリは対象外です。作成には書き込み権限が必要です。[2][3]
管理者の許可Copilot cloud agentとAutomationsの両方を許可している必要があります。Business / Enterpriseでは管理者ポリシーも確認します。組織所有リポジトリの共有自動化は、組織への課金を許可するポリシーも必要です。[2][3][6]
対象外の条件管理者が無効にしたリポジトリ、cloud agentが無効な場所、managed user accountが所有するリポジトリでは利用できません。[2]
作成・管理GitHubのリポジトリにある Agents → Automations などから利用します。Create with agentで、作業と振り返りを行うグループの作成を相談できます。[2]

日本向けの別料金や、すべての契約・画面で同じ選択肢が出ることは、本記事では確認していません。導入時は自分の契約、管理者設定、実際の画面で確認します。

06

費用と実行上限

作業と振り返り、両方の利用量を見る

モデルの利用

AIクレジットを消費

自動化の実行はcloud agentのセッションを開始します。モデルの種類と入出力などの量に応じて利用量が変わり、複雑な処理や高い推論設定は消費を増やす場合があります。[3][4][9]

実行基盤の利用

Actionsの実行時間も別に確認

AutomationsはGitHub Actionsの実行時間も使い、その料金はリポジトリ所有者に帰属します。利用枠や追加料金は契約・実行環境で確認します。[3][5]

個人用AIクレジットは作成したユーザーに課金。GitHub上の操作もその人の名義です。
共有用AIクレジットはリポジトリ所有組織、または個人所有者のCopilot契約に課金。操作はCopilot名義です。

個人用/共有用は作成後に種類を変更できません。[2][3]

「プランに含まれる」だけで、無料・無制限とは判断しない

改善を考える自動化も別の実行です。通常作業に加えて、振り返りの回数と利用量も記録します。人の確認時間まで含めて、手直しの削減に見合うかを評価します。

上限の働きは2種類あります。1回ごとのAIクレジット上限は実行を止めます。日・週・月の上限は新しい実行の開始を止め、すでに動いている実行は止めません。1回上限の設定最小値は30 AIクレジットです。上限未設定のまま使い始めない運用を検討します。[2]

本記事では定額の追加料金や実際の請求額を示していません。個別契約での実行・課金の検証は未実施です。

07

承認と、通常実行の安全策

権限の追加と、実行条件の変更を見落とさない

改善案の承認があっても、すでに許可した自動化は動きます。権限・入力・費用を、作成時と改善案の確認時の両方で点検します。

使える操作を必要な範囲に

Issue分類なら、最初はラベル操作などに絞ります。対応するイベントでは「Only this issue」で書き込み対象を限定できます。ただし、外部連携用のMCPツールはこの制限の外で、設定と認証が許す範囲にアクセスできます。[2][7]

実行の連鎖を確認

Copilot自身の操作が別の自動化を起動する設定もあります。誰のイベントを受け付けるか、対象ファイルや回数を点検します。書き込み権限のないユーザーのイベントは、初期設定では無視します。[2][7]

実行ログを共有する前提で

個人用の自動化でも、実行セッションはリポジトリの閲覧者に見えます。指示文に秘密情報を直接書かず、組織の情報管理ルールに従います。[2]

採用率だけで評価しない

記事の提案重要な指摘ほど採用に時間がかかる場合もあります。誤り、見逃し、権限外の変更、人の確認時間も記録します。

改善案を読むときの確認

どの反応が根拠か。重要な確認を省いていないか。使える操作が増えないか。実行頻度や費用が増えないか。判断できない提案は適用を保留し、設定を変えずに調べます。

08

小さく試す方法

1つの非公開リポジトリで、分類から確かめる

記事の提案承認済みのテスト用privateリポジトリに、機密を含まない架空のIssueを用意します。最初から本番のコード変更や外部ツールへの操作を任せず、分類基準の見直しに絞る試し方です。

STEP 1

正解と判断理由を用意

たとえば10件の課題票と、期待するラベル・迷う条件を準備。件数は記事の試行例で、公式の推奨値ではありません。

STEP 2

修正理由と利用量を記録

実行結果を人が確認し、直したラベルと理由を残します。作業・振り返りの利用量と、確認にかかった時間も分けて記録します。

STEP 3

1つの改善案を比較

根拠と設定差分を確認してから承認。別の確認用Issueで再評価し、誤りや手間が増えたら停止・設定の見直しを行います。

GitHubは、イベントを模擬して自動化をテスト実行する操作、変更履歴の確認、無効化を用意しています。テストでも選択したツールは実際に動くため、対象と権限を先に限定します。[2]

導入判断:改善案の確認まで含めて、同じ手直しが減るか

数件の採用で全体に広げず、重要な例外や難しい課題でも確認します。この記事は機能紹介と試行案です。自動化の作成・実行・設定変更は行っていません。

SOURCES & NOTES

出典と、確認した範囲

公式発表:2026年10月28日。資料確認:2026年10月30日 JST。本ページは10月30日版の記事です。

  1. Copilot Automations now learn from outcomes and self-improve ↗10/28発表。反応の公式例、週次の改善役、適用前の承認。
  2. Creating automations with Copilot cloud agent ↗対象プラン、リポジトリ条件、作成、実行上限、テストと管理。
  3. Copilot automations ↗個人用/共有用、改善案、別保存の設定、AIクレジットとActions課金。
  4. Usage-based billing for individuals ↗モデルとトークン量によるAIクレジット消費。個人契約向けの説明。
  5. GitHub Actions billing ↗実行基盤の利用枠と追加利用、リポジトリ所有者への課金。
  6. Managing GitHub Copilot in the cloud for your organization ↗組織・企業のポリシーと、リポジトリへの許可。
  7. Risks and mitigations for GitHub Copilot cloud agent ↗権限、信頼しない入力、実行・レビューの境界。
  8. Route and orchestrate models with GitHub Copilot Fusion ↗前回記事との比較用。1タスク内のモデル選択・処理方式。
  9. Changing the AI model for GitHub Copilot cloud agent ↗モデル選択と推論設定による時間・AIクレジットへの影響。

公式仕様と記事の提案を区別しています。図は編集部による概念図です。個別アカウントでの提供・課金、実際の改善精度や時間削減は未検証です。自動化の作成・実行は行っていません。仕様や料金は変更される場合があります。

このHTMLは images フォルダーと一緒に保存してください。画像フォルダーも保存すれば、本文と図を通信なしで読めます。出典の閲覧には通信が必要です。

ONE-PAGE BRIEF
Copilot Automationsの改善提案と人の承認の要点図

原寸表示では図を上下左右に動かせます。閉じるボタン、Esc、図の外側のクリックで閉じます。