この記事は、GitHub ActionsやCopilotをすでに触ったことがある人向けに、Agentic Workflowsの設計思想の違いを整理したものです。
はじめに
2026年2月、GitHubから「Agentic Workflows」がテクニカルプレビューとして発表されました。
「AIがリポジトリの作業を自動化してくれるらしい」と聞いて早速触ってみたところ、最初に盛大に勘違いしました。この記事では、その勘違いも含めて、実際に手を動かして学んだことをまとめます。
最初の勘違い：Coding Agent = Agentic Workflows？
VS CodeのCopilot Agent Modeに「GitHub Agentic Workflowsを体験したい」と伝えたところ、こんな流れを案内されました。
- リポジトリにPythonのTodoアプリを用意
- GitHub Issueを作成
- Copilot Coding AgentをIssueにアサイン
- 自動でPRが作成される
- GitHub Actionsでテストが走る
確かに便利でした。IssueにCopilotをアサインするだけで、テストコード付きのPRが自動生成されます。
ただ、これは「Copilot Coding Agent」であって、「Agentic Workflows」ではありませんでした。
公式記事を読み直して気づきました。全然別のものです。
Copilot Coding Agent（IssueにアサインしてPR自動生成）は以前からある機能です。
2026年2月に発表されたGitHub Agentic Workflows（gh-aw）は、それとは異なる仕組みです。
本物のGitHub Agentic Workflowsとは
一言でいうと
Markdownで「やってほしいこと」を書くだけで、AIエージェントがリポジトリの作業を継続的に自動化してくれる仕組みです。
GitHub Actionsとの違い
| GitHub Actions（YAML） | Agentic Workflows（Markdown） | |
|---|---|---|
| 記述方法 | YAMLで「手順」を書く | Markdownで「意図」を書く |
| 実行者 | 定義されたステップを順番に実行 | AIが意図を解釈して自律的に実行 |
| 判断力 | なし（if/elseで分岐するだけ） | AIが文脈を読んで判断 |
| 対応力 | 想定したパターンのみ | 未知のパターンにもAIが対応 |
| 用途 | ビルド・テスト・デプロイ | 判断が必要な繰り返しタスク |
ActionsとAgentic Workflowsは置き換えではなく共存するものです。 実際のリポジトリでも test.yml（Actions）と issue-triage.md（Agentic Workflows）が並んで動いていました。
Coding Agentとの違い
| Copilot Coding Agent | Agentic Workflows | |
|---|---|---|
| トリガー | Issueに手動でアサイン | スケジュール・イベントで自動トリガー |
| 目的 | 単発のコーディングタスク | 継続的なリポジトリ自動化 |
| 出力 | PR作成 | コメント、ラベル、Issue作成、PRなど多様 |
| 定義方法 | Issue本文に指示 |
.github/workflows/*.md で定義 |
実際にやってみた
セットアップ
# gh-aw CLIをインストール
gh extension install github/gh-aw
# リポジトリを初期化
gh aw init
# ワークフローのテンプレートを作成
gh aw new issue-triage
ワークフローを書く
.github/workflows/issue-triage.md を作成しました。
---
on:
issues:
types: [opened, reopened]
permissions:
contents: read
issues: read
safe-outputs:
add-comment:
max: 1
add-labels:
tools:
github:
---
# Issue Triage
新しいIssueが作成されたとき、自動的にトリアージを行います。
## やること
1. Issueのタイトルと本文を読み、内容を理解する
2. 以下のラベルから適切なものを付与する:
- `bug` - バグ報告
- `enhancement` - 機能追加リクエスト
- `question` - 質問
- `documentation` - ドキュメント関連
3. Issueにコメントを追加する:
- Issueの内容を簡潔に要約する
- 該当しそうなソースコードのファイルがあれば言及する
- 対応の優先度（高・中・低）を提案する
## ルール
- 日本語で応答すること
- コメントは丁寧で簡潔に
- 不明な場合は `question` ラベルを付けて確認を求めること
ポイントは YAML（フロントマター）とMarkdown（意図）の2層構造 です。
- フロントマター: いつ実行するか、何を読めるか、何をしていいか
- Markdown本文: AIに何をしてほしいか（自然言語）
コンパイルしてpush
# Markdownからロックファイル（.lock.yml）を生成
gh aw compile
# リポジトリにpush
git add -A && git commit -m "feat: Issueトリアージを追加" && git push
結果
Issueを作成すると、自動で以下が実行されました。
作成したIssue： 「listコマンドの出力に日時を表示してほしい」
AIが自動でやったこと：
- ✅
enhancementラベルを付与（機能追加リクエストと正しく判別） - ✅ 日本語でコメントを自動投稿
- ✅ 関連するソースコード（
todo.py）の具体的な行番号まで特定 - ✅ 実装の方向性を提案
- ✅ 優先度を「中」と判定
自然言語で「こうしてほしい」と書いただけで、AIがリポジトリの文脈を理解して判断した結果です。
ガードレール：一番重要な設計思想
触ってみて最も印象に残ったのがガードレールの厳しさでした。
AIに曖昧な意図を渡せるからこそ、想定外の行動を防ぐ仕組みが必須になります。Agentic Workflowsは3層のガードレールでこれを実現しています。
1. permissions（入力の制限）
何を「読める」かを制限します。
permissions:
contents: read # コードは読めるが書けない
issues: read # Issueは読めるが閉じられない
2. safe-outputs（出力の制限）
何を「やれる」かを明示的に許可します。
safe-outputs:
add-comment: # コメント追加は1つまで
max: 1
add-labels: # ラベル付与はOK
# create-pull-request ← 書いてないからPRは作れない
実体験: 最初 issues: write と書いたところ、コンパイル時にエラーで弾かれました。
strict mode: write permission 'issues: write' is not allowed for security reasons.
Use 'safe-outputs.add-comment', 'safe-outputs.add-labels' to perform write operations safely.
「writeで何でもできる権限」ではなく「コメント追加だけ許可」のように、出力を個別に制限する設計になっています。
3. サンドボックス実行
- ネットワーク分離
- PRは自動マージされない（人間が必ずレビュー）
なぜガードレールが重要か
| AIがやりかねないこと | ガードレール |
|---|---|
| 全Issueを勝手に閉じる |
safe-outputs にclose-issueがない → 不可 |
| コードを直接変更 |
permissions: contents: read → 読み取りのみ |
| 外部APIにデータ送信 | ネットワーク分離 |
曖昧さを許容しつつ、被害範囲を限定する — これがCI/CDとは異なる、Agentic特有の設計思想です。
つまずいたポイント
1. Copilot Coding AgentとAgentic Workflowsの混同
最初にCopilot Agent Modeから案内された流れが「Actions + Coding Agent」の組み合わせで、本来のAgentic Workflows（gh-aw）とは別物でした。AIアシスタント自身もこの違いを正確に区別できていなかった点は、なかなか興味深いところです。
2. シークレット設定が必要
gh aw init → gh aw compile → pushしただけでは動きません。AIエンジン用のトークン設定が別途必要でした。
# Fine-grained PATを作成（個人アカウントで、Copilot Requests権限付き）
# ※ Resource ownerは個人アカウント。Orgではない
gh aw secrets set COPILOT_GITHUB_TOKEN --value "<PAT>"
3. PAT作成のUI上の罠
Fine-grained PATの作成画面で「Copilot Requests」権限を表示させるには条件があります。
- Resource owner を個人アカウントにする（Organizationでは表示されない）
- Repository access を「Public Repositories」にする（表示条件）
Copilotライセンスが個人単位で付与されるための仕様です。
6つの活用パターン
公式が示している活用例です。
- 継続的トリアージ — Issueの自動分類・ラベル付け（今回試したもの）
- 継続的ドキュメント作成 — コード変更に合わせてREADMEを自動更新
- 継続的コード簡素化 — リファクタリング改善点を特定してPR作成
- 継続的テスト改善 — テストカバレッジを評価しテストを自動追加
- 継続的品質維持 — CIの失敗を調査し修正を提案
- 継続的レポーティング — リポジトリの健全性レポートを定期作成
まとめ
| 学んだこと | 詳細 |
|---|---|
| Agentic Workflows ≠ Coding Agent | 別物。Markdownで意図を書いて継続的に自動化する仕組み |
| Actionsの置き換えではない | CI/CDはActions、判断が必要なタスクはAgentic Workflows |
| ガードレールが設計の核 | permissions + safe-outputs + サンドボックスの3層防御 |
| セットアップのハマりどころ | シークレット設定、PAT作成のUI上の制約 |
GitHub Agentic Workflowsは現在テクニカルプレビュー中です。「朝リポジトリを開いたらIssueがトリアージされていて、CIの失敗が説明されていて、ドキュメントが最新になっている」——そういう世界が見えてきます。
Enterpriseで使うなら、次の論点は「誰がAgentic Workflowを作ってよいか」「どこまで許可するか」の運用設計になりそうです。