この記事の要点
- agent appsは、パートナー企業が作るAIをGitHubの作業に入れる仕組みです。
- GitHub公式ブログは、Amplitude、Endor Labs、LaunchDarkly、PagerDutyの利用例を示しました。
- public previewで、有料Copilotプラン向けです。
開発の厨房に専門AIが入る
GitHubは、agent appsを使う開発の流れを公式ブログで紹介しました。agent appsは、パートナー企業が作るAIエージェントをGitHub内で使う仕組みです。
たとえるなら、開発チームの厨房に専門スタッフが入るようなものです。AIが別室で答えるのではなく、作業台の横で動くようになります。
料理人が持ち場を離れて倉庫、会計、品質管理へ走ると、手元の料理は止まります。ソフトウェア開発でも同じです。情報が分かれるほど、判断が遅れます。
担当が違うAIを呼び分ける
公式ブログの例では、ひとつの機能変更に複数のagent appsが関わります。無料トライアルの登録導線を変えるという、小さく見える作業です。
でも実際には、顧客行動、安全性、公開範囲、障害リスクが絡みます。そこで、それぞれの専門AIをGitHub上で呼び出します。
・Amplitudeのagentは、ユーザー行動の分析を助けます。
・Endor Labsのagentは、依存関係のリスクを調べます。
・LaunchDarklyのagentは、feature flagを作ります。
・PagerDutyのagentは、公開前の稼働リスクを見ます。
AIが動く場所が変わる
これまでのAI利用は、チャット欄に質問して答えを受け取る形が中心でした。agent appsでは、作業の入口がGitHubのissue（作業課題）やpull request（コード変更の提案）にあります。
Docsでは、Issue assignment、pull request comment、Agents UI（AIへの依頼画面）から開始できると説明されています。AIへの依頼口が、普段の仕事の場所に重なります。
初回利用時にはOAuth flow（外部アプリに権限を渡す認可方式）で認可します。agent appsはMCP servers（外部ツールとAIをつなぐ仕組み）を通じて、パートナー側のシステムにも接続します。
便利さの裏に残る管理
便利さだけで見ると、AIが何でもやってくれる話に見えます。けれど、GitHubの説明はもう少し現実的です。
LaunchDarklyの例では、agentが設定やコード変更を作ります。ただし、承認が必要な環境では、適用ではなく承認依頼を作ります。
企業で使う場合も条件があります。組織がenterpriseに属する場合は、管理者側でAgent appsのCopilot policyを有効にする必要があります。
公開状態と料金の見え方
| 項目 | 公式情報にある内容 |
|---|---|
| 提供状態 | public preview（正式版前のお試し公開） |
| 対象 | すべての有料Copilotプラン |
| 利用条件 | GitHub Appの導入とagent機能の有効化 |
| 企業利用 | enterpriseではCopilot policyの有効化が必要 |
| 料金額 | 発表に書かれていない |
| 課金の扱い | AI creditsをCopilot cloud agentと同じように消費 |
GitHub Docsは、agent appsがpublic previewだとしています。提供は始まっていますが、正式版前の段階です。
料金額そのものは、今回の発表に書かれていません。一方で、AI使用量はCopilot subscriptionに紐づき、AI creditsを消費すると説明されています。
仕事の中心がひとつに寄る
このニュースの見どころは、GitHubだけが便利になることではありません。いろいろなSaaSのAIが、仕事の中心画面へ集まる動きです。
非エンジニアの仕事でも、同じことが起きます。営業ならCRM、経理なら会計ソフト、採用なら応募管理ツールが仕事の中心です。
そこへ専門AIが入ると、画面を移る時間が減ります。人は、集まってきた結果を見て、進めるか止めるかを決めます。
AIエージェントの主戦場は、単独アプリから業務の中心画面へ移っています。GitHubのagent appsは、その変化を開発の世界で見せたニュースです。