GitHub Issues、エージェント操作に信頼度しきい値と項目別承認を導入。ただし権限境界にはならず

GitHubは、エージェントのガバナンスをIssuesの状態変更フローに組み込もうとしている。新たなパブリックプレビューでは、approvals、confidence、rationaleを提供する。エージェントは変更をまず提案パネルへ送り、サポート対象の各操作には高・中・低の信頼度と実行理由が表示される。デフォルトのロジックでは、信頼度が高い操作を即時に適用し、中・低の結果はユーザーが個別または一括で承認できる。リポジトリ管理者は自動化のしきい値も調整でき、`has:suggestions`でレビュー待ちの項目を検索できる。

第1段階では、ラベルの追加、issue typeとフィールドの変更、issueのクローズ、ユーザーまたはエージェントへの割り当てをサポートする。この機能はCopilot cloud agent、GitHub Agentic Workflows、REST API、GraphQL APIでも利用できる。既存のAgentic Workflowsは、アップグレード後にsafe outputsへissue intentを含められる。意図データを必須にする場合は、ワークフローのfrontmatterで`issue-intents: true`を設定できる。これにより、大規模な分類、メタデータの補完、スパムissueの選別において、「完全自動」と「完全手動」の二者択一を避けられる。

それでもエンジニアリングチームは、信頼度スコアを校正済みのリスク確率として扱うべきではない。GitHubは、スコアの生成方法、各しきい値でのエラー率、リポジトリ横断の評価結果を公開していない。エージェントが示す根拠も監査の手掛かりにすぎず、モデル内部の判断を忠実に表しているとは限らない。さらに重要なのは、承認がワークフロー上の利便機能であり、セキュリティコントロールではない点だ。すでにissueへの書き込み権限を持つエージェントは、提案モードを迂回して直接変更できる。導入時には最小権限を維持し、API操作と監査イベントを別途記録するとともに、実際の誤ラベル付けや誤クローズのデータを使って自動適用のしきい値を再調整する必要がある。