Agent アプリでソフトウェアデリバリーワークフローを GitHub に取り込む方法

Pull Request を開くとき、皆さんはいくつタブを開いているだろうか。製品の無料トライアルのオンボーディングで「チームメイトを招待する」ステップを省略可能にしてほしい、という issue を例に考えよう。サインアップ増加に伴い、このステップが摩擦になっているとサポートから指摘されている。スコープの決定からデプロイまで、次の4つの問いに答える必要がある: 本当に正しい変更か、触ろうとしている依存関係はクリーンか、安全にロールアウトできるか、今すぐデプロイしてもよいか。それぞれの答えは別々のツールにあるため、PR を進めるには同じコンテキストを4箇所に持ち運ばなければならない。

GitHub Agent Apps は、それらの質問に答えるために必要なツールを、開発者がすでに作業している GitHub 上に直接もたらす。GitHub 自身の Copilot クラウドエージェントと同じ基盤と仕組みを使っており、以下の例では Amplitude、Endor Labs、LaunchDarkly、PagerDuty という既存のサービスを GitHub から離れずに組み合わせる。

最初に、製品データで仮説を確認する。Amplitude のエージェントを Agents タブから呼び出し、「チーム招待ステップの完了は、後のファネルの成功と相関しているか」をセグメント別に尋ねる。結果は明確で、チームユーザーはこのステップを完了すると後のリテンションが高く、ソロユーザーには相関が見られない。そこで、ソロのサインアップではステップを後回しにし、チームでは維持する、という再スコープが正当化される。コードを書く前に方向修正できるのが利点だ。

次に、Copilot がドラフト PR を開き、オンボーディングフローが使う依存関係も更新される。従来のように CI の失敗を待つ代わりに、開発者はコメントで Endor Labs エージェントに「この PR で触れる依存関係に注意点はないか」と質問する。エージェントは変更された依存関係を特定し、既知の脆弱性とパッケージリスクを調べて PR 内に回答する。今回は問題ないと分かり、対応は不要だった。依存関係レビューが先手に変わる。

実装には、その結果を反映して、ソロのサインアップではオプションのパス、チームでは従来のパスを維持する。サインアップ時にセグメントが決まるため、機能フラグで直接ターゲットを指定できる。LaunchDarkly エージェントに、キー名、型、デフォルト値、ターゲット、ロールアウト計画を指定してフラグの作成とコードへの組み込みを依頼すると、エージェントはフラグを作成し、コード実装をコミットとして追加する。承認が必要な環境では、直接適用せずに承認リクエストを生成し、人間が判断する仕組みだ。

マージ前に、PagerDuty エージェントがデプロイリスクを評価する。リポジトリを対応する PagerDuty サービスにマッピングし、アクティブなインシデントの有無、過去90日間の履歴、PR の変更ファイルと過去のインシデント領域との関連を確認する。今回はアクティブなインシデントも強い相関もなく、推奨は「進めてよい」だった。派手なことは起きないが、それこそが狙いだ。デプロイリスクの確認が、リリースが危険に感じられたときだけのものではなく、日常的なルーチンになる。

使っているツールは従来どおりだが、コンテキストをツール間で持ち運ぶ必要はなくなる。Agent Apps は GitHub Marketplace からインストールでき、issue に割り当てたり、PR コメントで @メンションしたり、リポジトリの Agents タブから選んだりして使える。あなたのツールは依然としてあなたのツールであり、それらが GitHub という作業場所に現れるようになる。