GitHubをレコードおよびコントロールプレーンのシステムとして記述する

エージェントシステムには、ストアコード以上の機能を持つ環境が必要です。意図をキャプチャし、アクションを記録し、検証を適用し、ポリシーを適用できる環境が必要です。このラーニングパスでは、その環境GitHub。

このユニットでは学ぶことができます。

GitHubは、開発作業が提案および評価される成果物を格納するため、レコードのシステムです。

エージェントワークフローでは、これらの成果物は二重の義務を果たします。開発をサポートし、事後にエージェントの動作を検査できるようにします。

Note

このモジュールでは、一般的なGitHubガバナンスパターンに焦点を当てます。 GitHubシークレットスキャンやプッシュ保護などの高度なセキュリティ機能についてはここでは説明しませんが、運用環境では追加の検証信号として統合できます。

GitHubコントロールプレーンは、(ポリシーによって構成されている場合)、エージェントのコントリビューションが実行できる内容とできないことを形成する強制ポイントを提供するためです。

GitHub コントロール	適用される内容	エージェントにとって重要な理由
Pull Request	マージ前に変更が提案される	エージェントの作業をレビュー可能で議論可能にする
必須のレビュー	人間およびエージェントの承認ゲート	未表示のマージを防止し、アカウンタビリティをサポートします
必須の状態チェック	マージ前の CI 証拠	評価を強制可能なポリシーに変換します
CODEOWNERS	パス別のルーティングを確認する	影響の大きい変更を適切な専門家が監督できるようにします
ルールセット/ブランチ保護	一元化されたブランチポリシー	安全でないマージを防止し、一貫性のあるガードレールを適用します
Environments	デプロイ/シークレットの承認	機密性の高い実行とシークレットアクセスを制御します

Note

これらの強制動作は、構成とアクセス許可によって異なります。たとえば、必要なチェックとルールセットを有効にすることは、通常、管理者タスクです。監督モデルはどこでも動作します。強制を行うには、コントロールを有効にする必要があります。

ワークフローは実行が検証される場所ですが、アクセス許可はチェックと同じくらい重要です。重要なセキュリティ原則は、最小限の特権です。

エージェントシステムの場合、"エージェントができること" は、多くの場合、"ワークフロートークンとツールの資格情報でできること" に減ります。コントロールとアクセス許可は、それに応じて設計する必要があります。

ワークフローの実行は人間によって制御される 一部のエージェント PR ワークフローでは、実行中のワークフロー ("ワークフローの承認と実行" アクションなど) を明示的に承認する必要がある場合があります。これは組み込みのガードレールです。信頼されていない変更に対して特権ワークフローが自動的に実行されるリスクが軽減されます。
環境がシークレットとデプロイを管理する ワークフロージョブが必要なレビューアーを含む環境を対象とする場合、ジョブは承認が付与されるまで待機します。これにより、エージェントによってトリガーされるワークフローが、保護されたシークレットにアクセスしたり、人間によるレビューを行わずにデプロイしたりすることができなくなります (構成されている場合)。
CODEOWNERS は、リスクの高いパスのレビューをルーティング しますエージェントが機密性の高いパス (.github/workflows/ や infra/ など) のファイルを変更した場合、CODEOWNERS はそれらのパスの所有者にレビューを自動的に要求できます。必要なレビューと組み合わせると、適切な専門家が影響の大きい変更を確実に監督できます。

エージェントは、セキュリティ修正プログラムを使用してプル要求を開きます。 Github：

GitHubがコントロールプレーンであるというのは、ここで管理が行われるということです。

GitHubは、エージェントの作業が格納される場所だけではありません。エージェントの作業が監視され、検証され、管理される場所です。リポジトリとプル要求により、作業が表示されます。チェック、レビュー、CODEOWNERS、ルールセット、ブランチ保護、および環境により、作業が制御可能になります。

GitHubがエージェントの動作を制約して検証する方法を見てきたので、次の手順は責任を調べることです。次のユニットでは、エージェントがワークフロー内で行動するときに、誰が責任を負うのか見ていきます。

このページはお役に立ちましたか?