エージェントの実行制限と保護
エージェントはリポジトリでアクションを実行できますが、これらのアクションはプラットフォームの制限と保護内で実行されます。 GitHubでは、Copilotクラウド エージェントは、GitHub Actionsを利用した環境で動作し、ブランチに変更を作成し、それらの変更をレビュー用に準備します。
変更はそれ自体で最終処理されません。 これらの変更をプル要求にするかどうかを決定します。
このユニットでは、次の内容について説明します。
- エージェント アクションに課される制限
- ブランチとリポジトリの制限がコードベースを保護する方法
- ワークフローと環境の制御がエージェント主導の変更に与える影響
- 人間によるレビューがプロセスの一部であるしくみ
リポジトリとブランチの制限
Copilotクラウド エージェントは、それが動作しているリポジトリにのみアクセスできます。 他のリポジトリにはアクセスできません。
その変更は、main などの既定のブランチではなく、別のブランチで行われます。 これにより、レビューの前にすべての変更が確実に分離されます。
プルリクエスト制御
クラウド エージェントCopilot作業が完了すると、レビューのために変更が準備されますが、プル要求は自動的に作成またはマージされません。
次の選択肢から決定してください。
- pull request を作成する
- 生成された変更を確認する
- 更新プログラムを要求するか、作業を破棄する
これにより、人間のコントロールにおける最終的な決定が維持されます。
ワークフロー コントロール
エージェントの作業は、GitHub Actionsを利用したワークフロー内で実行されます。
リポジトリと組織の設定では、以下を制御できます。
- 許可されるワークフロー
- 実行できるアクション
- GITHUB_TOKENの実行が許可されていること
これらのコントロールは、エージェントがワークフローを通じて実行できる内容を制限します。
実行セーフガードと回復性パターン。
エージェント駆動型ワークフローには、プラットフォーム レベルの制限に加えて、障害を処理し、繰り返しエラーを防ぎ、アカウンタビリティを確保するためのセーフガードを含める必要があります。
エラー処理
ワークフローでは、エージェントの実行中にエラーを明示的に処理する必要があります。
これには、次のものが挙げられます。
- ステップがエラーに直面した場合に速やかに中断する
- 意味のあるエラー メッセージのログ記録
- 部分的または不整合な変更の防止
例:
```
- run: |
npx @github/copilot-cli -p "Run task"
continue-on-error: false
```
これにより、エラーが警告なしで続行されるのではなく、実行が停止されます。
再試行の回数
再試行は、ネットワークの問題や一時的なエラーなどの一時的なエラーの処理に役立ちます。
再試行は次の方法で実装できます。
- 失敗したステップの再実行
- スクリプトでの再試行ロジックの使用
- 安全な再実行を可能にするワークフローの構築
パターンの例:
```
- name: Run agent task with retry
run: |
for i in 1 2 3;
do npx @github/copilot-cli -p "Run task" && break
sleep 5
done
```
これにより、ワークフローは手動で介入することなく、一時的な問題から復旧できます。
ロールバック
エージェントが間違った変更または安全でない変更を生成した場合、ロールバック メカニズムによって、それらの変更がメイン コードベースに影響を与えないようにします。
ロールバックは当然、次の方法でサポートされます。
- ブランチ ベースの分離
- マージ前のプルリクエストレビュー
追加のロールバック戦略は次のとおりです。
- pull request を閉じるか破棄する
- 変更がマージされた場合にコミットを元に戻す
エスカレーション経路
エージェントがタスクを完了できない場合や、不確実性が発生した場合、エスカレーションによって人間がステップインできるようになります。
これは、次の方法で実装できます。
- プルリクエストのレビューを要求する
- レビュー担当者を自動的に割り当てる
- ワークフロー ステップを使用してメンテナーに通知する
エスカレーションにより、重要な決定は常に人間によって処理されます。
追跡性と説明責任
すべてのエージェント アクションは、追跡可能で監査可能である必要があります。
GitHubでは、次の方法でこれを提供します。
- ワークフロー ログ
- コミットの履歴
- Pull request ディスカッション
追跡可能性を向上させるには:
- 明確なコミットメッセージを使用する
- 変更をブランチの範囲内に限定する
- pull request を使用してすべてのアクションを確認する
これにより、すべてのエージェント アクションを検査、理解、および属性付けできるようになります。
議論したこれらのセーフガードは、エージェントの実行を確保することです。
- 回復性: エラーと再試行を処理できます
- 制御: 安全でない変更を防ぎます
- 監査可能: すべてのアクションが表示され、トレース可能です
- 人間が管理する: エスカレーションによって監視が保証される
環境保護
エージェントによって生成された変更がデプロイで使用される場合、環境は追加のセーフガードを提供します。
環境では、次のことができます。
- ジョブを続行する前に承認を要求する
- シークレットへのアクセスを制限する
- デプロイ ターゲットを制御する
これにより、機密性の高い操作が自動的に実行されないようにします。
セッションの可視性
エージェントの実行は、実行中に表示されます。
次のようにすることができます。
- ログを使用して進行状況を監視する
- エージェントのアクションを検査する
- 動作を調整するためのフォローアップ プロンプトを提供する
この可視性により、プロセス全体を制御できます。
トリガーの動作とワークフローの制限
GITHUB_TOKENを使用してトリガーされるワークフローには制限があります。
このトークンで実行されるほとんどのアクションでは、追加のワークフロー実行はトリガーされないため、意図しないループや繰り返しの実行を防ぐことができます。
GitHubアプリ トークンや個人用アクセス トークン (AT) などの他の認証方法では、構成に応じて追加のワークフロー実行をトリガーできます。 これにより、より柔軟なオートメーション パターンが可能になりますが、再帰的な実行や意図しないオートメーション ループを回避するための慎重な設計も必要です。
エージェントアクションを安全に有効にする
エージェントは、次のようなアクションを実行できます。
- ブランチの作成
- コードの更新
- レビューのための変更の準備
- リポジトリ イベントによるワークフローのトリガー
これらのアクションは、次の方法で制御されます。
- ブランチ ベースの分離
- ワークフローの検証
- プルリクエストレビュー
- ワークフローのアクセス許可
これらのコントロールを組み合わせることで、リポジトリまたは実行環境への無制限のアクセスを許可することなく、エージェント アクションを有効にすることができます。
重要なポイント
GitHubでのエージェントの実行は、リポジトリ スコープ、ブランチの分離、ワークフローのアクセス許可、環境保護、および人間の意思決定ポイントによって制御されます。 エージェントは変更を準備しますが、変更の確認と最終処理は引き続き担当します。