GitHub Actionsの次の形 — YAMLの代わりにMarkdownで書く「Agentic Workflows」の全貌

GitHub Actionsを使ったことがある人なら、YAMLのインデントと格闘した経験があるはずだ。

2026年2月13日、GitHubはその体験を根本から変えようとする機能をテクニカルプレビューとして公開した。Agentic Workflows。ワークフローをYAMLではなくMarkdownで書き、AIエージェントに実行させる。

「issueが開かれたらラベルを付けて」と自然言語で書けば、エージェントがissueの内容を読み、適切なラベルを判断して付ける。ステップバイステップの手続きを書く必要がない。意図を書けばいい。

Markdownでワークフローを書くとはどういうことか

Agentic Workflowsのファイルは.github/workflows/に置く。通常のActionsと同じ場所だ。ファイルの構造は2つのパートに分かれる。

YAMLフロントマター（トリガー、権限、制約の設定）と、Markdown本文（エージェントへの指示）。フロントマターで「いつ動くか」と「何が許されるか」を定義し、本文で「何をしてほしいか」を書く。

---
on:
  issues:
    types: [opened]
permissions:
  issues: read
  contents: read
safe-outputs:
  add-comment:
    max: 1
engine: copilot
timeout-minutes: 10
---

# Issue Triage

新しいissueを分析し、タイトルと本文から
`bug`、`feature`、`enhancement`、`documentation`
のいずれかのラベルを付ける。

engineフィールドでAIエージェントを選べる。copilot（デフォルト）、claude（Anthropic）、codex（OpenAI）の3つが現時点で対応している。

書いたMarkdownはgh aw compileコマンドで標準のActions YAMLに変換される。つまり実行基盤はGitHub Actionsそのままだ。Markdown本文を変更してもフロントマターが変わらなければ再コンパイル不要という設計も実用的だ。

safe-outputs — エージェントに「書き込ませない」設計

ここがAgentic Workflowsで最も重要な部分だと思う。

エージェントはリポジトリに直接書き込めない。代わりに「こういう操作をしたい」という構造化されたアーティファクトを出力する。それを別のジョブが読み取り、宣言された制約に従って実行する。

たとえばadd-comment: max: 1と書けば、1回のワークフロー実行でコメントは最大1件しか追加できない。create-issueにはタイトルの接頭辞やラベルの制約も付けられる。エージェントが暴走してissueを100件作る、といった事態を構造的に防いでいる。

この設計の背景にはセキュリティアーキテクチャがある。エージェントはサンドボックスコンテナ内で動き、ネットワークはファイアウォール（Squidプロキシ）で制御され、LLMのAPIトークンはエージェントから隔離された別コンテナに置かれる。GitHub Next、Microsoft Research、Azure Core Upstreamの3チーム共同で設計されたもので、「エージェントが侵害されても被害を限定する」という脅威モデルに基づいている。

何に使えるか

githubnext/agenticsにサンプルパックが公開されている。実用的な例をいくつか挙げる。

issueのトリアージ。開かれたissueを分析してラベルを自動付与し、重複を検出する。CIの障害調査。失敗したActionsのログを読み、原因を分析して修正案をPRコメントに書く。ドキュメントのメンテナンス。壊れたリンクの検出と修正、変更に追従したドキュメント更新。

ある開発者はカスタマーサポートのトリアージに使い、「手作業のオーバーヘッドが即座に大幅に減った」と報告している。日次のリポジトリレポート生成や、Dependabotの複数PRをまとめるワークフローも公開されている。

gh skillとの関係

2026年4月16日に公開されたgh skillコマンド（GitHub CLI v2.90.0+）は、Agentic Workflowsとは別だが補完的な機能だ。

Agent Skillsは「AIエージェントに特定のタスクを教える命令セット」で、GitHub Copilot、Claude Code、Cursor、Codex、Gemini CLIなど複数のエージェントホストで使える。Agentic Workflowsが「CI上の自動化タスク」を定義するのに対し、Skillsは「エージェントの再利用可能な能力」を定義する。Skillsをワークフロー内のツールとして使うことも可能だ。

現時点の制約

テクニカルプレビューゆえの課題がある。Windowsランナー非対応。フィルタリングで実行がスキップされた場合、Actions履歴上は「失敗」と表示されてしまう。PRの作成者が個人名ではなく汎用の「Copilot」と表示される。コストの可視化ダッシュボードが不十分で、高頻度ワークフローでのプレミアムリクエスト消費を心配する声もある。

MITライセンスのオープンソースプロジェクトとしてgithub/gh-awで公開されており、4,300スターを集めている。v0.68.3まで341リリースを重ねている段階で、まだ荒削りだが進化は速い。

「意図を書く」時代のCI/CD

YAMLで手続きを書く従来のGitHub Actionsは消えない。だが、issueのトリアージやドキュメントの更新のように「やりたいことは明確だが手順を書くのが面倒」なタスクには、Markdownで意図を書くほうが圧倒的に速い。

safe-outputsによるガードレール設計は、「AIに任せたいが暴走は困る」という企業の現実的な懸念に正面から応えている。Enterprise AI Controlsも2月にGAになり、エージェントセッションのフィルタリングや専用の管理者ロールが整備された。テクニカルプレビューではあるが、エンタープライズ向けの準備は着々と進んでいる。

GitHub Actionsユーザーなら、まずサンプルパックのissueトリアージを1つ試してみることを勧める。YAMLを1行も書かずにワークフローが動く体験は、一度味わうと戻れなくなる可能性がある。