11月12日、InfoQのMark Silvesterが「GitHub Makes Agentic Workflows Generally Available with Isolation and Budget Controls」と題した記事を公開した。GitHubがコーディングエージェントをGitHub Actions上で実行するAgentic WorkflowsをGAリリースし、その分離設計とコスト制御の仕組みについて詳しく紹介されている。
GAリリースの核心：「最小権限」と「予算上限」
AIエージェントを本番のCI/CDパイプラインに組み込む際、エンジニアが最も気にするのはセキュリティとコストの暴走だ。GitHub Agentic Workflowsは、この2点に対して明確なデフォルト値を設けた状態でGAとなった。これはAIエージェントをCI/CDエコシステムに組み込む際の最大の障壁——「暴走したら何が起きるか分からない」という不安——に対して、GitHubが構造レベルで答えを出したという点で意味が大きい。
権限の分離設計
エージェントは読み取り専用の権限でスタートする。リポジトリへの変更が必要な場合、エージェント自身が直接書き込むのではなく、専用の別ジョブが独自の書き込みトークンを持って実行する構造になっている。エージェントが提案した変更内容は、適用前に脅威検知ジョブ（threat-detection job）によるスキャンを経る。
ただし、この分離には限界がある。公式FAQは「カスタムジョブや直接の書き込み権限には保護が自動で適用されない」と明記しており、安全性はワークフローの設定次第だ。書き込みジョブの実行前にレビュアーを必須にするGitHub Environmentの保護ルールを追加することもできる。
実際に試したエンジニアの声も慎重だ。ドイツのISP freenetのミドルウェアチームリードであるSascha Mirow-Stanitzokは、issueトリアージワークフローのウォークスルー記事でこう書いている：
デフォルトの予算はトリアージには大きすぎる。自分のランは100 AIC、15ターン、10分に絞った。また、エージェントへの指示の中でissueテキストの指示を無視するよう書いても、それだけでは保護にならない。コードを変更したりPRを開くワークフローには同じパターンは使わない。
コストの上限設計
AIクレジット（AIC）は1 AIC = $0.01で、デフォルトのキャップは1実行あたり1,000 AIC（$10）。企業向けにはさらに細かいデフォルト値が設定されている：
- 1日あたり5,000 AIC
- 脅威検知1回あたり400 AIC
- エージェントステップのタイムアウト: 20分
これらはすべて組織側で上書き可能だ。月次のAIクレジット消費を見積もるgh aw forecastコマンドも、今回のGAに合わせて正式版に昇格した。
ワークフローの定義方法
ワークフローの記述は自然言語のMarkdownで行い、YAML frontmatterで設定を加える形式だ。この定義ファイルをコンパイルすると標準のActionsワークフローが生成される。既存のランナーグループやポリシー制約をそのまま再利用できるため、既存インフラへの導入コストは低い。
エージェントエンジンはデフォルトでCopilotを使うが、別のコーディングエージェントを持ち込む（BYOA）こともできる。ただし、デフォルトのCopilot CLIエンジンにはCopilotライセンスが必要だ。
既存のActionsユーザーにとっては、YAMLを書き直す必要がなく、MarkdownでAIエージェントの振る舞いを記述するだけで既存のCI/CDパイプラインに組み込める点が導入ハードルを下げている。逆に言えば、自然言語による定義の曖昧さがどこまでエージェントの動作に影響するかは、実運用の中で知見が積み上がっていく段階にある。
セルフホステッドランナー（ARC）対応に潜む注意点
プレビュー期間中に追加された機能のひとつが、KubernetesオペレーターであるActions Runner Controller（ARC）とDocker-in-Docker（DinD）のサポートだ。DinDはランナーPod内でDockerデーモンを動かすことで、エージェントがサンドボックスコンテナを起動できるようにする。
ただし、公式ガイドは「ARCはDinDサイドカーをデフォルトで特権コンテナ（privileged container）として実行する」と明記している。最小権限を設計思想としたエージェントの隣に、特権コンテナが並ぶ構成は、セキュリティ要件の厳しい環境では要検討だ。オンプレ寄りの環境でAgentic Workflowsを採用する場合、ARCのセキュリティ設定は別途精査が必要になる。
GitLabとのアプローチ比較
GitLabは独自のDuo Agent Platform flowsで似たユースケースに対応している。こちらは「コンポジットID」という仕組みで、アクションを実行するサービスアカウントとリクエストを開始した人間ユーザーをペアにする。また、あるフローが別のフローをトリガーすることを禁止しており、エージェントが人間の介入なしに連鎖して処理を進めることを構造的に防ぐ設計になっている。
GitHubのアプローチが「既存のActionsエコシステムに自然言語とAIを段階的に乗せる」漸進的な統合を志向しているのに対し、GitLabは「エージェント間の連鎖を構造的に禁じる」より保守的な設計思想をとっている。すでにGitHub ActionsのCI/CDを広く使っている組織には前者が馴染みやすく、エージェントの自律性に対してより厳格なポリシーを求める組織には後者のアプローチが合うだろう。
使いどころの整理
GitHubの公式FAQは「再現性が必要なビルドやテストには従来のActionsが適切で、解釈や生成が必要なタスクにエージェントワークフローが向く」と整理している。GitHub Free・Team・Enterpriseで利用可能だ。
Accentureのシニアマネージャーは「あるリードエンジニアが開発作業だけで週29時間節約できた」とコメントしているが、元記事はその測定方法や対象業務の詳細には言及していない。インパクトの大きな数字だけに、そのまま鵜呑みにするのではなく、自社の業務内容やエンジニアのロール構成と照らし合わせた上で参考値として扱うのが妥当だろう。
詳細はGitHub Makes Agentic Workflows Generally Available with Isolation and Budget Controlsを参照していただきたい。
