GitHub Agentic Workflows は、GitHub Actions 上で実行され、プレーンな Markdown で記述され、コーディングエージェントによって実行される、自動化された意図駆動型のリポジトリワークフローである。これは GitHub Next において、AI コーディングエージェントの時代に強力なガードレールを備えたリポジトリ自動化とはどのようなものかを探る調査として始まり、GitHub、Microsoft Research、Azure Core Upstream の共同作業と説明されている。GitHub は 2026 年 2 月にテクニカルプレビューとして発表した。GitHub のドキュメントでは、パブリックプレビュー段階であり変更される可能性があると説明されている。
設計の前提は、メンテナーが望む成果をプレーンな Markdown で記述し、それをワークフローとしてリポジトリに追加すると、コーディングエージェントが GitHub Actions の中でそれを実行するというものである。GitHub が Actions を基盤に選んだ理由として挙げているのは、権限、ロギング、監査、サンドボックス化された実行、豊富なリポジトリコンテキストに必要なインフラがすでにそこに存在するという点である。ドキュメントは同じ前提をワークフロー自体のライフサイクルにも広げている。ワークフローの作成、デバッグ、最適化そのものも、望むことをコーディングエージェントに説明して行うことを想定しており、エージェントがワークフローを作成し、改良し、トラブルシューティングする。
機能
ワークフローファイルは 2 つの部分からなる。設定（トリガー、権限、ツール、許可される出力）を持つ YAML フロントマターと、ジョブを自然言語で説明する Markdown の指示である。GitHub の位置づけでは、Markdown が意図であり、トリガー、権限、ツール、許可される出力は前もって明示される。各 Markdown ワークフローには対応する .lock.yml ロックファイルがあり、GitHub Actions が実際に実行するのはこちらである。gh-aw CLI 拡張機能が gh aw compile によって前者から後者をコンパイルする。GitHub は、実際にはワークフローは通常、対話型のコーディングエージェントの助けを借りて作成され、エージェントが Markdown ファイルを書いてその妥当性を確認し、レビューに回すと述べている。リポジトリで gh aw init を実行すると、その作成用エージェントのためのスキルと指示が追加され、ドキュメントに記された手順は、agentic-workflows スキルをプレーンな言葉による説明とともに呼び出すというものである（コーディングエージェントで GitHub Agentic Workflow を作成する を参照）。ドキュメントは、GitHub の Web インターフェースでワークフローを作成する方法やファイルを手で編集する方法、そして Actions タブや gh aw run でワークフローを実行する方法も説明している。
ドキュメントのフロントマターのリファレンスは 4 つの主要フィールドを挙げている。GitHub Actions のトリガーと同じ構文で書くイベントトリガーの on、エージェントに付与されるリポジトリ権限でデフォルトが read-all の permissions、エージェントに許可される書き込み操作の safe-outputs、使用する AI エンジンの engine である。週次の Issue アクティビティレポートの例では network と tools の設定も宣言し、エージェントに GitHub の Issue ツールセットを付与している。ワークフローを編集する際は、gh aw compile でロックファイルを再コンパイルし、両方のファイルをコミットする。
どのコーディングエージェントがワークフローを実行するかは設定可能である。発表では、設定に応じて使えるエンジンとして Copilot CLI、Claude Code、OpenAI Codex が挙げられている。ドキュメントでは Copilot CLI がデフォルトとされ、代替として Claude Code、OpenAI Codex、Gemini CLI が挙げられており、Pi という名前の実験的なエンジンなど、さらに別のエンジンもサポートされている。3 つの代替エンジンはいずれも、リポジトリシークレットとして保存された API キーで動作する。Copilot の場合、個人のリポジトリではきめ細かい個人用アクセストークンを格納した COPILOT_GITHUB_TOKEN シークレットが必要になる。一方、組織が所有するリポジトリでは代わりに GitHub Actions 組み込みの GITHUB_TOKEN を使える。ワークフローの permissions に copilot-requests: write を指定し、組織のポリシーで Copilot CLI の課金を組織に請求することを許可していれば、Copilot のリクエストは組織に直接課金され、ドキュメントはこの方法を推奨している。
GitHub はセキュリティアーキテクチャを、意図しない振る舞いとプロンプトインジェクション攻撃を対象とした多層防御と説明している。ワークフローはデフォルトで読み取り専用の権限で実行され、書き込み操作には Safe Outputs による明示的な承認が必要になる。safe outputs は、プルリクエストの作成やコメントの追加など、事前承認されたレビュー可能な GitHub 操作に対応付けられている。サンドボックス化された実行、ツールの許可リスト、ネットワーク分離が、エージェントを管理された境界の内側にとどめると説明されている。GitHub はこれを、コーディングエージェントの CLI を標準的な Actions の YAML ワークフローの中で直接実行するという代替手段と対比しており、そちらはしばしば特定のタスクに必要な以上の権限を与えてしまうと述べている。
GitHub は、プルリクエストが自動的にマージされることは決してなく、常に人間がレビューして承認しなければならないと明言している。
gh-aw リポジトリの README はプロジェクトを「Actions + Agent + Safety」と要約し、書き込みをエージェントからどう切り離しているかを詳しく説明している。サポートされているエージェントジョブの経路は、デフォルトで GitHub への読み取り専用アクセスとサンドボックス化された実行を用い、safe outputs が設定された書き込みをバッファリングし、検証したうえで、スコープを限定した権限を持つ別のジョブで適用する。README はまた、これらの制御は設定可能であるため、ワークフローの作成者はデプロイ前に権限、ツール、ネットワークアクセス、生成されたファイルをレビューしなければならないと強調している。そして、エージェント型ワークフローを使うにはセキュリティへの慎重な注意と注意深い人間による監督が必要であり、「それでもなお物事がうまくいかないことはあり得る」ため、慎重に、自己責任で使うべきだと警告している。README の組み込みエンジンの一覧は、GitHub Copilot、Claude Code、OpenAI Codex に加えて Google Gemini と Pi を挙げている。
テクニカルプレビューの変更履歴エントリは、この全体像にいくつかの具体的な点を加えている。ワークフローは .github/workflows/ 以下に Markdown ファイルとして追加され、gh aw CLI がそれを標準的な GitHub Actions ワークフローに変換する。セキュリティ設計には、サンドボックス化とネットワーク分離に加えて、SHA で固定された依存関係とサニタイズされた書き込み操作が含まれる。GitHub MCP Server はリポジトリ、Issue、プルリクエスト、Actions、セキュリティへのネイティブなアクセスを提供し、ブラウザ自動化、Web 検索、カスタム MCP サーバーのための追加ツールもある。ワークフローは、Issue やプルリクエストのイベント、スケジュール、手動ディスパッチ、コメント内のコマンドによってトリガーできる。また、実装は gh-aw リポジトリにおいて MIT ライセンスのもとで完全にオープンソースであるとも述べている。
採用とエコシステム
GitHub はこの仕組みを Continuous AI を実現する手段として位置づけている。Continuous AI は SDLC への AI の統合を指す GitHub の用語であり、継続的インテグレーションや継続的デプロイメントの実践と同様に、自動化と協働を強化するものと説明されている。新たに実用的になったとして GitHub が挙げるカテゴリは、継続的なトリアージ、継続的なドキュメント作成、継続的なコードの簡素化、継続的なテスト改善、継続的な品質衛生、継続的なレポーティングである。GitHub は、これらが CI/CD を置き換えるのではなく補強するものであると明言している。ビルド、テスト、リリースのパイプラインを置き換えるものではなく、そのユースケースは決定論的な CI/CD ワークフローとはほとんど重ならないとされる。リポジトリの README も反対側から同じ線引きをしている。決定論的なビルド、テスト、リンティング、デプロイ、再現可能なスクリプトには従来の GitHub Actions が引き続き適したツールであり、タスクに推論や解釈が必要な場合にエージェント型ワークフローを追加する。その例として挙げられているのは、Issue のトリアージ、プルリクエストのレビュー、CI の失敗の調査、ドキュメントのメンテナンス、依存関係の分析、リポジトリのレポーティングである。
公開されている設計パターンには、ChatOps、DailyOps、DataOps、IssueOps、ProjectOps、MultiRepoOps、Orchestration がある。GitHub の実践的なガイダンスは次のとおりである。プルリクエストの作成を有効にする前に、コメント、下書き、レポートのような低リスクの出力から始めること。機能開発ではなく、リファクタリング、テストカバレッジ、簡素化のような目標志向のコード改善から始めること。良いレポートとはどのようなものかを具体的に示すこと。エージェントが自律的なサブループの中で動作するとしても、より大きなループには人間を関与させ続けること。そしてワークフローの Markdown をコードとして扱い、変更をレビューし、意図的に発展させることである。
ワークフローはリポジトリ間で共有できる。gh aw add-wizard（または非対話型の gh aw add。バージョンを固定することもできる）は別のリポジトリからワークフローをインポートし（ドキュメントの例は githubnext/agentics からのもの）、そのフロントマターに source: の値を記録する。これにより、後で gh aw update がローカルの編集を保持するよう努めながら上流の変更を取り込めるようになる。private: true が指定されたワークフローはインポートできず、ドキュメントは信頼できるソースからのみインポートし、追加する前にワークフローが何をするのかをレビューするよう勧めている。
事例については、変更履歴が Peli’s Agent Factory を紹介しており、さまざまなユースケース向けの 50 以上の専門化されたエージェント型ワークフローを紹介しているとしている。
README は部分的にエージェントを読み手として想定して書かれている。「fellow agent（仲間のエージェント）」に宛てた挨拶で始まり、ワークフローの作成、ツールのインストール、ワークフローリポジトリのパッケージング、リファレンスのための生の Markdown ファイルへのリンクを示し、AI エージェントや検索ツールに対しては、公開されたプロンプトインデックス、完全なプロンプトコーパス、AI が読めるプロジェクト概要を案内している。人間向けには、エージェント型ワークフローの構築、実行、カスタマイズを段階的に教える、独立した自己完結型のワークショップリポジトリである Factory Tour Workshop を案内している。
ワークフローの実行時にはコーディングエージェントを使うため、課金コストが発生する。発表については GitHub Agentic Workflows でリポジトリのタスクを自動化する で説明されている。