【ITニュース解説】Building an AI bug-fixing agent that runs inside your GitHub Actions runner

システム開発において、プログラムのバグは避けられない問題であり、特に本番環境で発生するエラーは迅速な対応が求められる。この記事では、AIを活用してこれらのバグを自動で修正し、プルリクエストとして提案する画期的なシステムについて解説する。このシステムの最大の特徴は、AIによる自動修正の便利さと、コードの機密性を守るセキュリティの両立を追求している点にある。

現在、多くのAIを活用した開発ツールが登場しているが、それらの多くは、あなたのコードリポジトリへの読み取り権限や、AIサービスを利用するためのAPIキーを、ツールを提供する外部サービスに預ける必要がある。これは、機密性の高いコードや重要な認証情報を外部に渡すことになり、セキュリティ上の大きな懸念となる場合がある。そこで、この記事の著者は「エージェントを調整・管理するサービス（コントロールプレーン）は、決してあなたのコードを読み取れないようにする」という厳格なルールを設けてシステムを設計した。このルールが、システムのあらゆる側面に影響を与えている。

このシステムは大きく二つの部分から構成される。一つは「コントロールプレーン」と呼ばれるサービスで、エラーの発生状況、システムの設定、これまでの実行履歴などを管理する役割を担う。しかし、このコントロールプレーンはあなたの実際のプログラムコードには一切アクセスできない。もう一つは「GitHub Actions Runner」と呼ばれる部分で、これはあなたの管理するGitHubリポジトリ上で動作する、まさに「あなたのインフラ」と言える環境だ。このRunner上で実際のコードがチェックアウトされ、AIのAPIキーもここに保管される。そして、このRunnerの内部でバグ修正を行うAIエージェントが動作する。

具体的なバグ修正のプロセスは次のように進む。まず、SentryやPostHogといったエラー監視ツールが本番環境で発生した新しいエラーを検知すると、その情報がコントロールプレーンに通知される。コントロールプレーンは、そのエラーに関連するリポジトリを特定し、GitHub Actionsのワークフローを起動するよう指示を出す。この起動はworkflow_dispatchという機能を通じて行われ、コントロールプレーンがあなたのリポジトリに直接アクセスしてコードを操作するわけではない。

指示を受けたあなたのGitHub Actions Runnerは、指定されたリポジトリのコードを自分の環境にチェックアウトする。そして、そこに展開されたAIエージェントが、チェックアウトされたコードを分析し、エラーを修正するためのコードの変更案を作成する。この修正案は、自動的に新しいブランチとして作成され、そのブランチをもとにGitHub上でプルリクエストがオープンされる。これにより、人間が最終的な修正内容をレビューし、承認・マージするプロセスに繋がる。修正作業が完了すると、Runnerは修正結果のステータス、作成されたプルリクエストへのリンク、修正の概要、そしてAIモデルが使用したトークン数（AIサービスの利用料計算に使われる単位）といった情報をコントロールプレーンに報告する。

このシステムにおいて、セキュリティは徹底的に考慮されている。コントロールプレーンはGitHub Appとして実装されており、「メタデータの読み取り」と「Actionsの読み書き」という最小限の権限しか持たない。特に「Contents」（コード内容）の権限は持たないため、あなたのリポジトリをクローンしたり、ファイルを直接読み取ったりすることは不可能だ。AIサービスを利用するためのAPIキーも、あなたのリポジトリのGitHub Secretsとして安全にRunner内に保管され、コントロールプレーンがこのキーを参照することはない。

また、Runnerがコントロールプレーンと連携するために使用するトークンも、セキュリティを重視した設計になっている。これは「パーランントークン」と呼ばれ、その名の通り一度の実行（ワンラン）のみ有効で、30分という短時間で期限切れになる。このトークンは、その実行に必要なエラーコンテキストの読み取りと、結果の報告にのみ限定された権限しか持たない。さらに、GitHub Actionsのログにはマスク処理が施され、意図せず公開されるリスクも低減される。

AIエージェントの設計も、セキュリティを第一に考えている。このエージェントに与えられているツールは、「ファイルの内容を読み取る」「ディレクトリを一覧表示する」「コード内を検索する」「プルリクエストを作成する」という四つの機能に厳しく限定されている。シェルへのアクセスや、外部ネットワークへの独自のリクエストを行う能力は一切持たない。これは、エラーメッセージやスタックトレース、コードコメントといったAIへの入力情報の中に、悪意のあるテキストが含まれる可能性を考慮したものだ。もしエージェントがシェルを実行できれば、悪意のあるコマンドが実行されてしまうリスクがあるが、ファイル読み取りと差分作成に限定することで、万が一の際の被害範囲（ブラスト半径）を最小限に抑えている。ファイル読み取り時には、../のようなパスをたどってリポジトリ外のファイルにアクセスしようとする試みを防ぐ「パスガード」も実装されている。修正案は常に新しいブランチにコミットされ、プルリクエストとして提示されるため、あなたのベースブランチに直接プッシュされたり、勝手にマージされたりすることはない。

この厳格なセキュリティ設計には、いくつかのトレードオフも存在する。例えば、エージェントはコードを修正する前に、修正案が正しいことを確認するためのテストを実行できない。これは、テスト実行にシェルアクセスが必要となるため、セキュリティ上の制約によって制限されている。著者はこの点が現在のデフォルトとしては適切だと考えているが、将来的にはサンドボックス化されたテスト実行環境の可能性も検討している。

また、システムはAIエージェントの実行に時間とコストの予算を設定している。エージェントの思考ループは、最大で30回のツール呼び出し、または20分の実行時間で自動的に停止する。ワークフロー全体のタイムアウトは25分に設定されており、これによってプルリクエストの作成や結果報告のための十分な時間が確保される。特に工夫されているのは、AIモデルへの各呼び出しに「残り時間」が割り当てられる点だ。これにより、もしAIサービスからの応答が遅れても、ジョブ全体のタイムアウト時間を超過して結果が報告されないままになる事態を防いでいる。

実際の運用ではいくつかの注意点もある。GitHubリポジトリはデフォルトで「GitHub Actionsからのプルリクエストの作成を許可する」設定が無効になっている場合が多く、この設定を手動で有効にする必要がある。また、AIモデルの料金体系は頻繁に変更されるため、モデルの利用料金に関する計算はRunnerではなく、コントロールプレーンで行うように設計されている。これにより、料金体系の変更があってもRunner側のコードを更新する必要がなくなる。さらに、複数のAIプロバイダーをサポートする場合に備え、各プロバイダーからの応答を統一された形式で処理できるよう、アダプター層を設けることが推奨されている。

最後に、このシステムにおけるデータがどのように扱われるかを確認しよう。AIエージェントが読み取ったコードファイルの内容は、あなたのAI APIキーを使って、AnthropicやOpenAIといったAIプロバイダーへ送信される。AI APIキー自体はRunner内に留まり、外部には出ない。エラーのタイトル、種類、スタックトレースといった情報は、エラー監視ツールからコントロールプレーンへ、そしてRunnerによって取得され、AIプロバイダーへのプロンプトの一部として送信される。修正の結果（ステータス、PRリンク、サマリー、トークン数）はコントロールプレーンに報告される。重要なのは、あなたのソースコード本体がコントロールプレーンに渡されることは決してないという点だ。エージェントが作成する修正サマリーにはファイル名や短いコード断片が含まれる可能性はあるが、これはAIモデルが生成したテキストの一部としてであり、コードそのものが流出するわけではない。

このシステムは、自動化とセキュリティのバランスを慎重に考慮して設計されている。完全に正しい修正を保証するものではなく、常にプルリクエストとして人間のレビューを挟むことで、安全性を確保している。自動テストの実行や、さらに厳重なサンドボックス環境での実行など、今後の改善の余地についても著者は言及しており、この分野の進化はこれからも注目されるだろう。