はじめに
GitHubが2026年8月14日、外部サービスのAIエージェントをIssueやPull Requestから呼び出す「agent apps」の活用例を公開しました。本稿では、企画判断から依存関係の確認、段階公開、デプロイ判断までをGitHub上でつなぐ仕組みを解説します。
参考記事
- タイトル: How to bring your software delivery workflow into GitHub with agent apps
- 著者: Sam Zhang
- 発行元: The GitHub Blog
- 発行日: 2026年8月14日
- URL: https://github.blog/ai-and-ml/github-copilot/how-to-bring-your-software-delivery-workflow-into-github-with-agent-apps/
関連記事
要点
- GitHub agent appsは、外部サービスの分析や操作をIssue、Pull Request、Agentsタブから利用できる仕組みである
- Amplitude agentは製品データを分析し、実装前に変更対象と利用者区分を絞り込める
- Endor Labs agentは変更対象の依存関係をPull Request上で検査し、脆弱性やパッケージリスクを確認できる
- LaunchDarkly agentは機能フラグと段階公開を設定し、承認が必要な環境では申請へ切り替える
- PagerDuty agentはインシデント履歴と変更内容を照合し、デプロイ時の運用リスクを評価する
詳細解説
実装前の問いを製品データへつなぐ
GitHubの記事では、オンボーディング中の「チームメンバーを招待する」工程を任意化する変更が例に使われています。サポート部門から不満が報告されていても、誰が困っているのか、その工程が継続利用とどう関係するのかが分からなければ、変更範囲を決められません。そこでAmplitude agentへ、招待工程の完了と後工程の成功に相関があるか、計測中の利用者区分ごとに分析するよう依頼します。
分析の結果、チーム利用者では工程完了と継続率に関係があり、個人利用者では同じ関係が見られないという想定が示されました。この場合、工程全体を削除するのではなく、個人利用者だけ後回しにする変更へ絞れます。AIを実装速度のためだけに使わず、変更前の仮説検証へ接続している点が重要です。実務では、分析対象のイベント名、対象期間、利用者区分を明示し、人が結果の妥当性を確認する運用が必要だと思います。
Pull Requestの最中に依存関係を確認する
Copilotが下書きのPull Requestを作ると、変更された依存関係をEndor Labs agentへ問い合わせます。エージェントは変更対象を特定し、既知の脆弱性だけでなく、パッケージ全体のリスクも確認してPull Requestへ回答します。CIが失敗してから修正するのではなく、レビュー中の変更文脈を保ったまま早い段階で確認できる流れです。
ただし、エージェントの「問題なし」という回答だけでマージ可否を決めるのは適切ではありません。利用する脆弱性データベースの更新時刻、検査対象、許容するリスク、例外の承認者をあらかじめ定める必要があります。agent appsは判断材料を集約する仕組みであり、組織のセキュリティ基準そのものを自動で決めるものではありません。
機能フラグで公開範囲と承認を管理する
次にLaunchDarkly agentへ、個人利用者だけ招待工程を後回しにする機能フラグを作るよう依頼します。GitHubの例では、初期値を無効にし、社内、5％、25％、100％の順で広げる設定を指定しています。エージェントはLaunchDarkly上にフラグを作成し、コード変更をコミットとして追加します。対象環境に承認ルールがある場合は、直接反映せず承認申請を作成します。
この構成では、依頼、設定変更、コード差分、承認の履歴がPull Requestを中心に残ります。段階公開を自動化しても、各段階で確認する指標、停止条件、切り戻し担当者が曖昧なら安全性は高まりません。エラー率や離脱率などの指標と、閾値を超えた場合の停止手順を機能フラグの設計に含めることが大切だと考えられます。
デプロイ直前に運用状況を確認する
コードレビューが通っていても、サービスがデプロイに適した状態とは限りません。PagerDuty agentは対象リポジトリとサービスを対応付け、稼働中のインシデント、過去90日間の履歴、今回変更するファイルと過去の障害領域の関係を確認します。例では有効なインシデントがなく、変更との強い関連もないため、低リスクとして進行を提案しています。
この確認を定型化すると、障害が起きそうなときだけ運用部門へ問い合わせるのではなく、すべてのPull Requestで同じ観点を確認できます。一方、履歴に現れない新しい障害や、サービス間依存は残ります。最終判断では、リリース時間帯、監視担当者、ロールバック手順なども合わせて確認する必要があります。
GitHubを判断の記録場所として使う
agent apps導入後も、Amplitude、Endor Labs、LaunchDarkly、PagerDuty自体は引き続き使われます。変わるのは、開発者が複数の画面へ同じ背景を持ち運ぶ作業です。IssueとPull Requestを共通の文脈にし、必要な時点で各サービスのデータや操作を呼び出せます。
導入時は、アプリごとの権限を最小限にし、読み取りと変更操作を分け、変更系の操作には人の承認を残す設計が必要です。開発速度だけでなく、誰がどの情報を根拠に何を変更したかを追跡できることが、組織で使う際の価値になると思います。
まとめ
GitHub agent appsは、企画、セキュリティ、段階公開、運用判断をPull Requestの文脈へ接続します。外部サービスを置き換えるのではなく、判断材料と操作履歴を集約する仕組みです。導入時は権限、承認、停止条件を決め、人の判断が残る形で試すことが重要だと思います。
