GitHub Actionsの構築「エージェンティックワークフロー（Agentic Workflows）」とは？仕組みと使い方を解説

コードを書くことなく、自然言語だけでGitHub Actionsの自動化ができるとしたら──。
GitHub Nextは2025年の時点で研究プロトタイプ「Agentic Workflows」を公開しており、その流れを汲む形で、2026年2月に「GitHub Agentic Workflows」としてテクニカルプレビュー提供が始まりました。
本記事では、Markdown（YAMLフロントマター＋自然言語の手順）でワークフローを定義し、GitHub Actionsで安全に実行する仕組み、使い方、想定ユースケース、そしてGitHub Copilotとの違いまで整理します。

GitHub Agentic Workflowsとは？

GitHub Agentic Workflowsは、自然言語で記述した手順（Markdown）をもとに、AIエージェントがGitHub Actions上でタスクを実行できるようにする自動化アプローチです。

GitHub Next、Microsoft Research、Azure Core Upstreamの共同プロジェクトとして開発されており、2025年にGitHub Nextが研究プロトタイプとして公開した「Agentic Workflows」を起点に、2026年2月にテクニカルプレビューとして提供が始まりました。

従来のGitHub Actionsではワークフローの中身をYAMLで厳密に書く必要がありましたが、Agentic Workflowsではトリガーや権限などの「枠」をYAMLフロントマターで宣言し、実行したい内容は自然言語で書くのが基本です。

そのうえで、Markdownファイルをコンパイルして生成される .lock.yml がGitHub Actionsとして実行されます。生成物をレビューできる構造に寄せることで、運用・監査に耐える形を狙っている点が大きな特徴です。

たとえば「READMEが古ければ更新してPRを作成して」といった指示をワークフローとして書き、ドキュメント更新・ブランチ作成・PR作成までを自動実行できる、というイメージです。

GitHub Actionsの概要

GitHub Actions

GitHub Actionsは、GitHub上でソースコードの変更をトリガーにして、ビルド・テスト・デプロイなどの処理を自動で実行できるCI/CD機能です。
リポジトリ内に「.github/workflows/」フォルダを作成し、YAML形式で実行内容を記述することで、開発プロセスの自動化が可能になります。

主な特徴は以下の通りです。

• GitHubに統合された自動化基盤：外部サービスなしで、コード管理と自動実行を一元化できる。
• 柔軟なトリガー設定：プルリクエスト、プッシュ、スケジュール実行など、さまざまなイベントに反応可能。
• 監査・可視化：実行ログ、履歴、成果物がGitHub上に残るため、組織運用と相性が良い。

Agentic Workflowsは、このGitHub Actionsの上に「自然言語でタスクを書く」という層を重ねる形で成立しています。既存の決定的なCI/CDパイプライン（ビルド・テスト・リリース）を置き換えるのではなく、従来のCI/CDでは表現しにくかった非決定的なタスクを補完する「Continuous AI」という位置づけです。

GitHub ActionsやGitHub Copilotとの違い

GitHub Agentic Workflowsと、従来のGitHub ActionsやGitHub Copilotは、自動化の対象領域と実行モデルが異なります。

従来のGitHub Actions

あらかじめ決められたステップを決定的に実行する仕組みです。同じ入力には常に同じ処理が走り、ビルドやテスト、デプロイといった再現性が求められる領域に適しています。一方、Agentic Workflowsは自然言語の指示をAIが解釈して実行するため、文脈に応じた判断や柔軟な対応が求められるタスク（Issueのトリアージ、ドキュメントの整合性チェックなど）に向いています。

**GitHub Copilot

開発者の作業（コード補完、レビュー、エージェント的なコード生成）を対話的に支援するツールです。個別タスクを「その場で」進めやすい反面、リポジトリ運用としての自動化を再利用可能な形に落とし込むのは得意分野ではありません。

Agentic Workflowsは、トリガー・権限・ログを前提に「繰り返す」仕組みとして定義する点が異なります。

実務では「Copilotで試す → うまく回るものをAgentic Workflowsとして定例化する」という使い分けが現実的です。

GitHub Agentic Workflowsの仕組み

Agentic Workflowsの中心は、「.github/workflows/」配下に置くMarkdownワークフローです。このセクションでは、ワークフローの構造、コンパイル方式、対応するAIエンジンを整理します。

Markdownワークフローの構造

Markdownワークフローは、以下の2つのパートで構成されます。

• YAMLフロントマター（宣言部）：トリガー（on）、権限（permissions）、利用するAIエンジン（engine）、利用可能なツール（tools）、許可する出力（safe outputs）などを宣言する。
  
  
• Markdown本文（指示部）：何をしたいか、どんな観点で判断してほしいか、どんな形式で出力してほしいかを自然言語で記述する。

重要なのは、「自然言語で書いた指示がそのままActionsで実行される」のではなく、コンパイルして生成される「.lock.yml」が実行物になる点です。これにより、生成物をレビュー可能な形として扱え、運用・監査に耐える構造が確保されます。

Markdownワークフロー例（最小イメージ）

---
on:
  schedule:
    - cron: "0 9 * * 1"   # 毎週月曜 9:00（例）
permissions:
  contents: read
  issues: write

engine: copilot

tools:
  github:
    mode: remote
    toolsets: [repos, issues, pull_requests]
---

# Weekly Repository Status

You are a maintainer assistant.
Create a concise weekly status update for this repository.

What to include:
- Summarize notable PRs/Issues from the last 7 days.
- Highlight any CI failures or flaky tests and suggest next steps.
- Call out overdue items (stale PRs, unattended issues).

Output format:
- Create a new issue titled "Weekly Repo Report (YYYY-MM-DD)".
- Use bullet points and keep it under 400 words.

この例では、「いつ動くか」「何を触ってよいか」「誰のAIを使うか」はフロントマターで宣言し、「何をしてほしいか」は自然言語で書きます。結果として、Issue作成などの安全な出力（safe outputs）に誘導しやすいのも実務上のポイントです。

コンパイルと実行の流れ

Agentic Workflowsは、Markdownで書いたワークフローをCLIでコンパイルし、Actionsが実行する「.lock.yml」を生成します。

• .mdファイル（人間が読む/書く）：目的・判断軸・出力形式など、自然言語での設計を置く場所。
• .lock.ymlファイル（実行/監査の基準）：実際にActions Runnerで動くYAMLで、レビューや監査の対象になる。

リポジトリ画面（参考：github.com/githubnext/gh-aw）

実行の全体フローは次の通りです。

1. 「.github/workflows/」に .md ファイルを追加する
2. 「gh aw compile」コマンドで .lock.yml を生成する（フロントマター変更時）
3. .md と .lock.yml をコミットしてプッシュする
4. 通常のActionsと同様にトリガーで実行される
5. ログ・成果物（Issue/PRなど）で結果を確認する

対応するエージェントエンジン（Copilot / Claude / Codex）

GitHub Agentic Workflowsは、複数のAIエンジンを選べる設計になっています。エンジンはフロントマターの「engine」フィールドで指定し、リポジトリ内のActions Secretsに対応するトークンやAPIキーを設定することで利用可能になります。

• GitHub Copilot（Copilot CLI）
  GitHubのAI基盤に紐づくエンジンで、初期設定として選ばれやすい選択肢。「COPILOT_GITHUB_TOKEN」（Fine-grained PATにCopilot Requests権限を付与したもの）をSecretに登録して利用する。
  
  
• Claude（Anthropic）
  AnthropicのAPIキー（「ANTHROPIC_API_KEY」）をActions Secretsに設定して利用する。データ取り扱いはAnthropic側のポリシーに依存する。
  
  
• Codex（OpenAI）
  OpenAIのAPIキー（「OPENAI_API_KEY」）をActions Secretsに設定して利用する。こちらもOpenAI側のポリシーに依存する。

エンジンはMCP（Model Context Protocol）を通じてリポジトリのツールにアクセスします。利用可能なツールはフロントマターで明示的に宣言する仕組みのため、エージェントに付与する機能を常に把握できます。

GitHub Agentic Workflowsの料金

GitHub Agentic Workflowsの利用コストは、AI利用料とGitHub Actions実行時間の両面で発生します。このセクションでは、エンジンごとのコスト構造と最適化の考え方を整理します。

エンジンごとのコスト構造

AI利用料の請求先は、選択するエンジンによって異なります。

• Copilot CLI：「COPILOT_GITHUB_TOKEN」を供給したユーザーのアカウントに紐づき、Premium requestsの枠として消費される。公式FAQによると、デフォルト設定での1回のワークフロー実行あたりの目安は2 premium requests（エージェント処理に1件＋safe outputsのガードレールチェックに1件）とされている。
• Claude：「ANTHROPIC_API_KEY」に紐づくAnthropic側の従量課金。
• Codex：「OPENAI_API_KEY」に紐づくOpenAI側の従量課金。

上記に加え、GitHub Actionsの実行時間（ランナーの稼働時間）も通常のActionsと同様に課金対象になります。

コスト最適化の考え方

コストを安定させるための基本は次の3点です。

• 低頻度から始める：定期実行（cron）の頻度を週次や日次に抑え、成果物の品質を確認しながら段階的に増やす。
• 権限とツールを最小限にする：ワークフローが呼び出すツールや出力先を絞ることで、エージェントの処理量を抑えやすくなる。
• 実行ログで使用量を追う：「gh aw logs」や「gh aw audit」で実行ごとの消費量を確認し、想定外のコスト増を早期に検知する。

特にCopilot CLIの場合、Premium requestsの月間枠はプランによって上限が異なるため、チームで複数のワークフローを動かす際は枠の消費ペースに注意が必要です。

GitHub Agentic Workflowsの利用手順

ここでは、GitHub Agentic Workflowsを利用する際のおおまかな手順を整理します。テクニカルプレビュー時点では、GitHub CLI拡張（gh-aw）を使うのが基本です。

ステップ1：拡張のインストール

gh extension install github/gh-aw

ステップ2：ウィザードでサンプルを導入

gh aw add-wizard githubnext/agentics/daily-repo-status

ウィザード内で、エンジン選択（Copilot/Claude/Codex）と、必要なSecrets（「COPILOT_GITHUB_TOKEN」など）のセットアップまで誘導されます。

ステップ3：初回実行

gh aw run daily-repo-status

ステップ4：カスタマイズ

「.github/workflows/daily-repo-status.md」を編集し、「何を見てほしいか」「出力形式」を自分の運用に合わせます。トリガーや権限などフロントマターを変更した場合は、次のコマンドで .lock.yml を再生成します。

gh aw compile

最後に、.md と .lock.yml をコミットしてプッシュすれば完了です。なお、GitHub Copilot Chatの「/agent agentic-workflows create」を使えば、対話形式でワークフローを生成することも可能です。

GitHub Agentic Workflowsの活用シーン

GitHub Agentic Workflowsは、既存のCI/CDを置き換えるものではなく、従来の決定的なパイプラインでは表現しにくかった「判断や文脈理解を伴う反復タスク」を補完する位置づけです。このセクションでは、公式で提供されているサンプルワークフロー群をもとに、代表的な活用パターンを整理します。

Issueのトリアージと分類

公式サンプルの中でも「hello world」に位置づけられているのが、Issueトリアージのワークフローです。新しいIssueが作成されると、エージェントがIssueの内容とリポジトリのコードベースを分析し、適切なラベルの付与・関連コードの特定・担当者候補の提示までを自動で行います。

Issueの分類基準はリポジトリごとに異なるため、汎用テンプレートをそのまま使うよりも、自リポジトリのラベル体系や分類ルールに合わせてMarkdownをカスタマイズすることで精度が高まります。なお、公開リポジトリで外部コントリビュータのIssueも処理したい場合は、Lockdown modeの無効化が必要になるケースがあり、セキュリティ面の考慮が求められます。

CI失敗の調査と修正提案

「CI Doctor」と呼ばれるサンプルワークフローは、CIの失敗を検知するとエージェントが失敗ログを分析し、原因の切り分け・再現条件の整理・修正候補の提案までをIssueやPRコメントとして出力します。

従来のCI/CDでは「失敗したら通知する」までが自動化の範囲でしたが、Agentic Workflowsでは「失敗の原因を調べて次のアクションを提示する」段階まで踏み込めるのが利点です。特にフレークテスト（不安定なテスト）の調査や、依存関係の変更に起因する失敗の分析など、開発者が手作業で繰り返しがちな調査を軽減できます。

ドキュメントの陳腐化チェックと更新

コードの変更に対してREADMEやAPIドキュメントが追従できていないケースは、多くのリポジトリで発生します。ドキュメント更新のワークフローでは、エージェントが最近のコード変更とドキュメントの内容を照合し、乖離が見つかった箇所について修正案をPRとして提出します。

公式ブログでは、GitHub Nextチーム自身がGo言語で構築したプロジェクトに対して「go-fan」という日次ワークフローを運用し、コード品質のフィードバックとドキュメント整合性の維持に活用していた事例が紹介されています。

定例レポートとチーム状況の可視化

日次・週次でリポジトリの活動状況をまとめるレポートワークフローも、すぐに試しやすい活用パターンです。直近のIssue・PR・ディスカッション・リリースの動向を集計し、次のアクションや注意点を添えたレポートをIssueとして自動作成します。

サンプルには「Daily Repo Status」（リポジトリ単位の日次レポート）や「Daily Team Status」（チーム横断の活動サマリー）などが用意されており、チームの規模や運用スタイルに合わせて選択できます。PR滞留、未対応Issue、フレークテストの傾向など、維持運用で見落としがちな観点を定期的に可視化する用途に向いています。

コード品質の継続的改善

「Code Simplifier」は、最近変更されたコードの中から複雑度の高い箇所を特定し、リファクタリングの提案をPRとして提出するワークフローです。テストカバレッジの評価や不足テストの追加提案を行うワークフローも用意されています。

こうした「継続的な品質改善（Continuous QA）」のタスクは、人手では優先度が下がりがちですが、エージェントに日次で回させることで、小さな改善を積み重ねる運用が可能になります。

GitHub Agentic Workflowsの利用時のポイント

このセクションでは、Agentic Workflowsを運用する際に押さえておきたい設計上のポイントを整理します。

Secretsの分離とコスト管理

リポジトリごとにトークンやAPIキーを分けると、利用量とコストの切り分けがしやすくなります。チーム導入では、Copilotの個人アカウント課金に寄せるのか、ClaudeやCodexの外部プロバイダ課金に寄せるのかも、コスト管理の観点で方針を決めておく必要があります。

また、複数のワークフローを同一リポジトリで運用する場合、Secretsを共有するとどのワークフローがどれだけ消費したかの追跡が難しくなるため、運用規模が大きくなる前に分離設計を検討しておくと安全です。

権限設計とHuman-in-the-loop

Agentic Workflowsは、デフォルトで読み取り専用（read-only）の権限で動作します。書き込み操作はsafe outputs（事前に承認されたGitHub操作）を通じてのみ許可される仕組みです。

とはいえ、権限を広げすぎると誤操作の影響範囲が大きくなるため、最初は「contents: read」や「issues: write」のような最小限の権限から始め、実績とレビュー体制が整ってから段階的に広げるのが現実的です。成果物（Issue/PR）を人がレビューして初めて完了、という「Human-in-the-loop」の運用を前提にしておくと、特に権限が広いワークフローでの事故を防ぎやすくなります。

GitHub Agentic Workflowsの利用時の注意点

最後に、Agentic Workflowsを利用するうえで注意しておきたいセキュリティ・統合面のポイントを整理します。

Lockdown modeとプロンプトインジェクション対策

IssueやPRなど外部入力に近いテキストをAIが読む場合、悪意ある指示が混入するリスク（プロンプトインジェクション）が存在します。GitHub Agentic Workflowsでは、こうしたリスクを前提にLockdown modeが用意されており、デフォルトではpush権限を持つメンバーの入力のみをエージェントが処理する設計になっています。

加えて、サンドボックス実行、ツールの許可リスト制御、ネットワーク分離、依存関係のSHAピン留めといった複数の防御層が組み込まれています。公開リポジトリや外部協力者がいる運用では、これらの設定を運用ポリシーと合わせて確認しておくことが重要です。

PR作成ポリシーとフォールバック

組織設定によっては、GitHub ActionsからのPR作成が制限されている場合があります。その場合でも、ワークフローの出力先をIssueやコメントに切り替えるフォールバック設計が用意されているため、組織ポリシーと合わせて出力先を設計しておくと実行失敗を減らせます。

PRの自動作成を許可する場合は、GitHub Appやサービスアカウント経由でのトークン発行が推奨されており、再帰的なワークフロー実行を防ぐ設計も併せて検討する必要があります。

MCP連携と拡張性

GitHub Agentic Workflowsでは、エージェントがリポジトリのツールにアクセスする際にMCP（Model Context Protocol）を利用しています。公式ドキュメントには、MCPサーバーとしての利用やカスタムツールの追加に関するガイドも用意されています。

日常運用では「まずはActions上の自動実行」に寄せ、VS Codeなどの開発環境連携やカスタムツールの追加は必要が出た段階で検討するほうが混乱が少なくなります。

ワークフロー自動化にGitHub Copilotを組み合わせるなら

Agentic Workflowsで開発タスクの自動化を実現したチームにとって、GitHub Copilotは日常のコーディング作業をさらに加速するツールです。ワークフローの定義はAgentに任せ、実装コードの生成はCopilotが支援——GitHub AIツール群を組み合わせた開発体制が実現します。

AI総合研究所のGitHub Copilot導入支援では、チーム全体のCopilot活用設計から効果測定までをサポートしています。まずは無料の活用ガイドで基本を押さえてください。

ワークフロー自動化をCopilotで加速

GitHub Copilot利用ガイド：2026年版

Agentic WorkflowsでCI/CDを自動化したら、コーディング自体もGitHub Copilotで効率化。基本操作から料金体系、Enterprise設定まで一冊で網羅します。

▶ 無料でダウンロード

まとめ

本記事では、GitHub Agentic Workflowsについて、仕組み・料金・利用手順・活用シーン・設計のポイント・注意点を横断的に整理しました。Markdown（YAMLフロントマター＋自然言語の手順）でワークフローを定義し、GitHub Actions上でAIエージェントにタスクを実行させるアプローチであり、従来の決定的なCI/CDでは表現しにくかった「判断を伴う反復タスク」を補完できる点が大きな強みです。

一方で、権限設計・プロンプトインジェクション対策・コスト管理（Premium requests等）など、AI自動化特有の設計ポイントも少なくありません。最初は小さな権限と低頻度の定期実行から始め、成果物を人がレビューする前提で設計すると、現場に無理なく馴染ませやすくなります。

AI総合研究所は企業のAIワークフロー構築を支援しています。ご興味のある方はこちらからお問い合わせください。