GitHub Issue TriageをAIに任せる

GitHubリポジトリの管理は大変です。新しいIssueは、タイトルが曖昧だったり、再現手順が記載されていなかったりすることがよくあります。ラベル付け、重複の確認、詳細情報の要求といった作業に一日が費やされてしまいます。こうした作業は、本来コードを書くために使いたい時間を奪ってしまいます。

2024年の調査によると、オープンソースのメンテナーの60%が辞めることを考えたことがあると回答しています。Issueの管理は大きな負担なのです。

私は、一次対応を行うためのボットを作成しました。これはGitHub Actions上で動作し、言語モデルを使用します。次のようなタスクを実行します：

  • ルールに基づいたラベルの適用
  • 重複の可能性があるもののフラグ立て
  • 内容の薄い説明に対して、不足している詳細情報の要求

このボットは、固定されたスクリプトではなく「エージェント」です。モデルに一連のツールを与えると、どのツールをどの順番で使うかをモデル自身が判断します。整理されたIssueならツールは1つで済みますが、整理されていないIssueなら3つ必要になるかもしれません。

初期のバージョンは「おしゃべり」すぎました。すべてのIssueにコメントを投稿してしまい、それがノイズとなっていました。ノイズが増えると、人はボットを無視するようになります。

私はシステムプロンプトにたった一行加えることで、これを解決しました。「何もしないこと」をモデルに許可したのです。「沈黙こそが最善の答えである場合が多い」と伝えたところ、コードを修正するよりも劇的に挙動が改善されました。

LiteLLMを使用しているため、ボットはClaude、GPT、Geminiのいずれでも動作します。ボットはfunction callingを利用してIssueに対してアクションを実行します。

実環境でのテストにより、主に3つの課題が明らかになりました：

  • GitHubのセキュリティにより、ボットはプルリクエスト内のシークレット（機密情報）を見ることができない。
  • 信頼できないテキストをモデルに入力する場合、prompt injectionのリスクがある。
  • 権限やAPIエラーのデバッグが混乱を招く可能性がある。

また、ボットに一つのルールを設けました。それは「セキュリティリスクのみをチェックし、コードの品質は評価しない」というものです。ボットが設計を判断するようになると、コントリビューターは離れていってしまいます。そうした判断は人間に任せるべきです。

もしIssueの事務作業に疲れ果てているなら、この仕組みが役立つはずです。繰り返しの作業をボットに任せ、重要な判断はあなた自身が行うことができます。

Source: https://dev.to/jescalada/putting-an-ai-agent-in-charge-of-github-issue-triage-3085

Optional learning community: https://t.me/GyaanSetuAi