この記事で分かること

  • GitHub Agentic Workflowsとは何か
  • 従来のGitHub Actionsとの違い
  • Claude Codeユーザーにとっての導入メリット
  • 20万行SaaSプロジェクトで何を自動化できそうか
  • 導入判断のポイント

GitHub Agentic Workflowsとは

2026年2月13日、GitHubがtechnical previewとして公開した新機能。GitHub Next、Microsoft Research、Azure Core Upstreamの共同開発で、MITライセンスのオープンソース。

一言で言うと、GitHub Actions上でAIコーディングエージェントを自動実行する仕組み。

従来のGitHub Actionsは「こうなったら、こうしろ」をYAMLで厳密に定義する。Agentic Workflowsは「こうなったら、こういう判断をしてほしい」をMarkdownで書く。判断はAIが行う。

従来のGitHub Actions:
  イベント → YAML定義の手順 → 決定的な実行

Agentic Workflows:
  イベント → Markdown記述の目的 → AIが判断して実行

仕組み

ワークフローの定義

.github/workflows/ にMarkdownファイルを置く。YAMLではなくMarkdown。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

---
on:
  issues: opened
permissions:
  contents: read
  issues: write
safe-outputs:
  add-comment: true
  add-labels: true
engine: claude
---

## Issue Triage

新しいIssueが作成されたら、内容を分析して適切なラベルを付ける。

## 判断基準

- バグ報告 → `bug` ラベル
- 機能要望 → `enhancement` ラベル
- 質問 → `question` ラベル
- セキュリティ関連 → `security` ラベル + 優先度を上げる

## コメント

トリアージ結果をコメントとして残す。

フロントマターでトリガー、権限、使用するAIエンジンを指定し、本文に自然言語で「何をしてほしいか」を書く。

コンパイルと実行

1
2
3
4
5

# CLIでコンパイル（Markdownからlock.ymlを生成）
gh aw compile

# 手動トリガー
gh aw run

gh aw compile がMarkdownを解析し、GitHub Actions用の .lock.yml を生成する。このlock fileが実際に実行されるワークフロー。Markdownは人間が読む仕様書、lock.ymlは機械が実行する手順書という関係になっている。

選べるAIエンジン

エンジン認証方法備考
Copilot CLICopilotライセンスに紐づくアカウント認証デフォルト
Claude CodeANTHROPIC_API_KEYAnthropic APIキーが必要
OpenAI CodexOPENAI_API_KEYOpenAI APIキーが必要

Claude Codeをエンジンに選べる点は、既にClaude Codeを使っている開発者にとって自然な選択肢になる。

従来のGitHub Actionsとの違い

項目GitHub Actions（YAML）Agentic Workflows（Markdown）
定義方法YAML（厳密な構文）Markdown（自然言語）
実行の性質決定的（同じ入力→同じ出力）非決定的（AIが判断）
向いている処理ビルド、テスト、デプロイトリアージ、レビュー、レポート
権限ワークフロー定義で指定デフォルトread-only + safe outputs
エラーハンドリング明示的に定義AIが判断

重要なのは、Agentic WorkflowsはCI/CDの置き換えではないこと。GitHubの公式ブログでも明言されている：

Don’t use agentic workflows as a replacement for GitHub Actions YAML workflows for CI/CD.

ビルド・テスト・デプロイは従来のYAMLワークフロー。AIの判断が必要な「曖昧なタスク」をAgentic Workflowsが担当する。「Continuous AI」という概念で、既存のCI/CDを補完する位置づけ。

Saruプロジェクトへの適用を考える

現状の自動化

Saruでは既に以下がGitHub Actionsで自動化されている：

ワークフロー内容種類
build-apis.ymlGoのlint、ユニットテスト、統合テストCI（YAML）
build-portals.ymlフロントエンドのtype-check、lint、ビルドCI（YAML）
e2e-tests.yml全ポータルのE2EテストCI（YAML）
security-scan.ymlgosec、npm auditCI（YAML）
cross-post.ymlブログの各プラットフォームへのクロスポストCD（YAML）

これらはすべて決定的な処理なので、Agentic Workflowsに置き換える理由はない。

Agentic Workflowsで自動化できそうなもの

では何が自動化できるか。現在「手動でやっている判断を伴う作業」を洗い出す。

1. Issue自動トリアージ

現状: Issueを作成したら自分でラベルを付けて優先度を決める。ソロ開発なので自分しかいない。

Agentic Workflows適用: Issue作成をトリガーに、内容を分析してラベル付け・優先度設定・関連ファイルの特定を自動で行う。

評価: ソロ開発では効果が薄い。自分で書いたIssueを自分でトリアージする必要性が低い。OSSとして公開後、外部からのIssueが増えた段階では有効。

2. CI失敗の自動調査

現状: CIが失敗したらログを読んで原因を調査し、修正する。第7回で書いた通り、CI安定化には多大な労力がかかった。

Agentic Workflows適用: CI失敗をトリガーに、ログを分析して原因を特定し、修正PRを自動作成する。

評価: 最も魅力的なユースケース。特にE2Eテストのflaky failureは原因特定に時間がかかる。AIが一次調査してくれるだけでも大幅な時間短縮になる。

3. Dependabot PRの自動トリアージ

現状: Dependabot PRが溜まると、1つずつ変更内容を確認してマージする。

Agentic Workflows適用: Dependabot PRをトリガーに、変更内容をレビューして「パッチバージョン＋テスト通過→自動マージ」「メジャーバージョン→要手動確認のラベル付け」を判断する。

評価: 効果的。Dependabot PRの処理は単調だが判断が必要な作業で、Agentic Workflowsの得意領域。

4. Daily Status Report

現状: なし。開発状況は頭の中にある。

Agentic Workflows適用: 毎日のIssue/PR状況、CIの健全性、未対応の項目をレポートとして自動生成。

評価: ソロ開発では過剰。チーム開発や、OSSとしてコントリビューターがいる場合に有効。

適用判断まとめ

ユースケース効果優先度
CI失敗の自動調査高◎
Dependabot PRトリアージ中○
Issue自動トリアージ低（ソロ段階）△
Daily Status Report低（ソロ段階）△

導入にあたっての懸念点

1. コスト

Agentic Workflowsの実行にはAIエンジンのAPI呼び出しが発生する。

  • Copilot: 1回の実行で約2 premium requests（エージェント実行 + safe outputs）
  • Claude Code: ANTHROPIC_API_KEY 経由でAPI課金
  • Codex: OPENAI_API_KEY 経由でAPI課金

CI失敗のたびにAIが動くとなると、月間コストが読みにくい。特にE2Eテストはジョブ数が多いので、失敗頻度 × APIコストを見積もる必要がある。

2. Technical Previewの不安定さ

2026年2月時点でまだtechnical preview。GitHubの公式ドキュメントにも「at your own risk」と明記されている。本番CI/CDパイプラインに組み込むには時期尚早。

ドキュメントもまだ発展途上で、Markdown frontmatterの仕様やエンジン設定の詳細など、手探りで確認する部分が残っている。

3. 非決定的な実行への信頼

CI/CDの世界では「同じ入力なら同じ出力」が大原則。Agentic Workflowsは本質的に非決定的で、AIの判断が毎回異なる可能性がある。

safe outputsやread-onlyデフォルトで安全側に倒してはいるが、「AIが勝手にラベルを間違えた」「的外れな修正PRを作った」といったケースへの対処が必要になる。

4. セルフホストランナーとの相性

Saruは15台のセルフホストランナーで並列E2Eテストを実行している。Agentic Workflowsがセルフホストランナー上で正しく動くかは未検証。公式ドキュメントではGitHub-hostedランナー前提の説明が多い。

5. Claude Code CLIとの棲み分け

ここが最も考えるべき点。Saruでは既にClaude Code CLIをローカルで使って開発している。GitHub上でもClaude Codeが自動で動くようになると、以下の棲み分けが必要になる：

ローカル開発:
  人間 + Claude Code CLI → コード実装、テスト作成

GitHub上:
  Copilot → PRレビュー（既に導入済み）
  Agentic Workflows → CI失敗調査、トリアージ（検討中）

同じリポジトリに対して複数のAIが異なるコンテキストで動くことになる。それぞれの役割を明確にしないと混乱する。

次のステップ

この記事では調査と検討にとどめた。次回、実際にSaruのリポジトリでAgentic Workflowsを導入し、以下を検証する予定：

  • CI失敗の自動調査ワークフローの構築
  • Claude Codeエンジンでの実行
  • セルフホストランナーでの動作確認
  • コストの実測

まとめ

項目内容
GitHub Agentic WorkflowsとはGitHub Actions上でAIエージェントを自動実行する仕組み
定義方法YAMLではなくMarkdownで自然言語記述
AIエンジンCopilot CLI / Claude Code / OpenAI Codex
CI/CDとの関係置き換えではなく補完（Continuous AI）
ソロ開発での有効ユースケースCI失敗調査、Dependabot PRトリアージ
現時点の判断検証の価値あり。ただしtechnical previewのため本格導入は時期尚早

シリーズ記事