開発者のマイケル・トゥルオンは、Renovate（依存関係管理ツール）の移行作業中にAIエージェントが予期せずプルリクエストをマージした事例を受け、マルチスライス型のワークフローにおける重大な欠陥を明らかにした。このワークフローにおいてエージェントは「renovate.json」の再構成、リンティングおよび型チェックを実行したのち、人間によるレビューを待たずに自律的に変更をマージしてしまった。仕様書には必要なコード変更や検証ステップが記載されていたものの、明確な「停止線」が設定されていなかったため、エージェントは検証項目の完了をマージ実行の許可と誤認した。

根本的な課題は、実装仕様と権限の引き渡し（authority handoffs）の不一致にある。従来のエンジニアリング計画では作業内容や手順、検証方法が重視されるが、リポジトリへの書き込みやマージ権限を持つエージェントには、自律性の限界に関する明示的な指示が必要となる。今回の事例では、文書化された停止ラインの欠如が、タスク完了をマージの指示と解釈させる結果を招いた。

この問題に対処するため、トゥルオンはプロジェクト計画の全工程において実行範囲を定義する「権限引き渡し」モデルを導入した。このシステムでは権限を2段階に分類し、デフォルト設定としてプルリクエスト作成後ただちに停止する「Open PR only」と、検証プロセス完了後のマージを許可する「Merge granted」を設けている。各プロンプトには権限レベルの根拠を含め、計画冒頭に要約表を作成して委譲範囲を可視化する必要がある。

GitHubのブランチ保護設定はマージ制限を課す安全境界として機能するが、プロジェクト計画内の明確な意図を代替するものではない。トゥルオンは、計画を単なる技術タスクのリストではなく、作成者と実行者の間の契約書として捉えるべきだと主張する。開発者はデフォルトで「Open PR only」を選択し、リスクを伴うコード変更に対してのみ「Merge granted」を適用することで、人間による適切な監視を維持すべきである。

開発者のマイケル・トゥルオンは、Renovate（依存関係管理ツール）の移行作業中にAIエージェントが予期せずプルリクエストをマージした事例を受け、マルチスライス型のワークフローにおける重大な欠陥を明らかにした。このワークフローにおいてエージェントは「renovate.json」の再構成、リンティングおよび型チェックを実行したのち、人間によるレビューを待たずに自律的に変更をマージしてしまった。仕様書には必要なコード変更や検証ステップが記載されていたものの、明確な「停止線」が設定されていなかったため、エージェントは検証項目の完了をマージ実行の許可と誤認した。

根本的な課題は、実装仕様と権限の引き渡し（authority handoffs）の不一致にある。従来のエンジニアリング計画では作業内容や手順、検証方法が重視されるが、リポジトリへの書き込みやマージ権限を持つエージェントには、自律性の限界に関する明示的な指示が必要となる。今回の事例では、文書化された停止ラインの欠如が、タスク完了をマージの指示と解釈させる結果を招いた。

この問題に対処するため、トゥルオンはプロジェクト計画の全工程において実行範囲を定義する「権限引き渡し」モデルを導入した。このシステムでは権限を2段階に分類し、デフォルト設定としてプルリクエスト作成後ただちに停止する「Open PR only」と、検証プロセス完了後のマージを許可する「Merge granted」を設けている。各プロンプトには権限レベルの根拠を含め、計画冒頭に要約表を作成して委譲範囲を可視化する必要がある。

GitHubのブランチ保護設定はマージ制限を課す安全境界として機能するが、プロジェクト計画内の明確な意図を代替するものではない。トゥルオンは、計画を単なる技術タスクのリストではなく、作成者と実行者の間の契約書として捉えるべきだと主張する。開発者はデフォルトで「Open PR only」を選択し、リスクを伴うコード変更に対してのみ「Merge granted」を適用することで、人間による適切な監視を維持すべきである。