はじめに
こんにちは！デリッシュキッチンで主にバックエンドの開発を担当している秋山です。
最近GitHub公式ブログで発表された GitHub Agentic Workflows というツールを知り、使い心地が気になったので試してみました。本記事では、CI/CDパイプラインにAIエージェントを組み込んで、テスト失敗時の原因調査からIssue作成までを自動化するワークフローを試しに構築した体験を紹介します。
目次
- はじめに
- GitHub Agentic Workflowsとは
- 今回試してみたこと
- セットアップ
- 実際に作ったもの
- GitHub Agentic Workflowsのセキュリティ設計
- 豊富なデザインパターン
- まとめ
- ご参考
GitHub Agentic Workflowsとは
GitHub Agentic Workflowsは、ワークフローを自然言語で定義し、コーディングエージェントに実行させる仕組みです。従来のGitHub ActionsではYAMLでワークフローを記述していましたが、GitHub Agentic Workflowsではマークダウン形式で自然言語を使ってワークフローを定義できます。定義したマークダウンは gh aw compile コマンドでGitHub Actions用のYAMLにコンパイルされ、GitHub Actions上で実行されます。
主な特徴は以下の通りです。
- マークダウンベースのワークフロー定義: YAMLの代わりにマークダウンで自動化を記述。直感的で柔軟
- 選択可能なAIエンジン: GitHub Copilot、Claude、OpenAI Codexなど、使用するコーディングエージェントをワークフローごとに選択可能
- セキュリティ重視の設計: デフォルトで読み取り専用権限。書き込み操作には明示的な許可が必要。さらに脅威検出による自動セキュリティ分析も実行される
※Agentic Workflowsは2026年2月現在テクニカルプレビュー段階にあり、今後大きな変更が入る可能性があります。
今回試してみたこと
GitHub Agentic Workflowsを使って、CI上の自動テスト失敗時に原因を調査し、Issueを作成してくれるワークフローを構築しました。Claude Codeに手伝ってもらいつつ、初回ワークフロー実行まで約30分で完了しました。
セットアップ
まずは拡張機能をインストールし、initで初期設定を行います。
# Agentic Workflows拡張機能のインストール gh extension install github/gh-aw # Agentic Workflowsのワークフローの初期化 gh aw init
実際に作ったもの
テスト対象のGoコード
まず、検証のために意図的にデータレースのリスクがあるGoコードを用意しました。
// cache.go package main type Cache struct { data map[string]int } func NewCache() *Cache { return &Cache{data: make(map[string]int)} } func (c *Cache) Set(key string, val int) { c.data[key] = val } func (c *Cache) Get(key string) int { return c.data[key] } // Increment increments the value for key by 1. func (c *Cache) Increment(key string) { c.data[key]++ }
sync.Mutex を使わず map[string]int に直接アクセスしているため、並行アクセス時にデータレースが発生します。
また、テストでは100個のgoroutineから同時にIncrementを呼び出します。
// cache_test.go func TestCacheConcurrentIncrement(t *testing.T) { c := NewCache() c.Set("counter", 0) var wg sync.WaitGroup const workers = 100 for i := 0; i < workers; i++ { wg.Add(1) go func() { defer wg.Done() c.Increment("counter") }() } wg.Wait() got := c.Get("counter") if got != workers { t.Errorf("expected counter=%d, got %d (lost %d increments due to race)", workers, got, workers-got) } }
自動テストワークフロー（test.yml）の定義です。
# .github/workflows/test.yml name: Tests on: push: branches: ["**"] pull_request: jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-go@v5 with: go-version: "1.23" - name: Run tests (race detector + repeat) run: go test -v -race -count=5 -timeout 120s ./...
GitHub Agentic Workflowsを使ったワークフロー定義
続いてGitHub Agentic Workflowsを使ったワークフローの定義です。 定義はマークダウンで書きます。
Front Matterでワークフローの細かい設定ができます（engineなどの部分です）。 メインの内容に、自然言語でワークフローの定義をしています。今回は英語で書いてますが、日本語でも問題ないと思います。
---
engine: copilot
on:
workflow_run:
workflows: ["Tests"]
types: [completed]
branches:
- main
permissions:
contents: read
actions: read
safe-outputs:
create-issue: ~
---
# CI Doctor
Automatically investigate failures in the "Tests" workflow
and create a GitHub Issue with a diagnostic report.
## Instructions
When triggered, check if the "Tests" workflow run that just completed
has a conclusion of `failure`. If it succeeded, do nothing.
For failed runs:
1. **Fetch the workflow run logs** for the failed "Tests" run
using the GitHub Actions API.
2. **Classify the failure type** by scanning the logs:
- `DATA RACE` → **Race condition**
- `too long` or `took too long` → **Time-dependent flakiness**
- `panic:` → **Panic / crash**
- `FAIL` with a specific test name → **Assertion failure**
3. **Identify the affected tests** by extracting lines matching:
- `--- FAIL: TestXxx`
- `FAIL\tgithub.com/...`
4. **Extract the root cause evidence** — copy the relevant log lines
verbatim as a code block.
5. **Create a GitHub Issue** with the following structure:
**Title**: `CI Failure: <TestName> — <failure type>`
**Body**:
- Summary
- Failed Test(s)
- Failure Type
- Log Evidence
- Root Cause Analysis
- Suggested Fix
Add labels: `bug`, `flaky-test`.
Front Matterの設定について補足します。
engine: copilotでAIエンジンを指定。Copilot以外にもClaudeやCodexを選択でき、使用するモデルの指定も可能（エンジン設定リファレンス）workflow_runトリガーでTestsワークフローの完了を監視permissionsでcontents: readとactions: readのみに権限を限定safe-outputsにcreate-issueを設定し、Issue作成のみを許可。それ以外の書き込み操作は行えない
コンパイル
GitHub Agentic Workflowsのワークフロー（.md）は、gh aw compile コマンドで .lock.yml にコンパイルされます。
gh aw compile
検証ではci-doctorという名前でワークフローを作っていたので、.github/workflows/ci-doctor.lock.yml が生成されました。このYAMLファイルが実際にGitHub Actionsで実行されるワークフローのようです。
これでワークフローの準備は完了です。
結果
Testsワークフローが失敗すると、定義したワークフローが自動的に起動しました。
また、以下のようなIssueが作成されました。
bug と flaky-test ラベルも自動で付与されています。
また、問題の説明や具体的な修正案まで提示してくれました。
今回は簡単な例でしたが、より複雑なケースでどうなるのかは今後確認していきたいです。
GitHub Agentic Workflowsのセキュリティ設計
AIエージェントにCI/CDパイプライン上で作業させるとなると、気になるのがセキュリティです。GitHub Agentic Workflowsはこの点について手厚い設計がされています。
Safe Outputs
GitHub Agentic Workflowsのワークフローはデフォルトで読み取り専用権限で実行されます。書き込み操作（Issue作成、PR作成など）を行うには safe-outputs で明示的に許可する必要があります。
safe-outputs: create-issue: ~ # Issue作成を許可 create-pull-request: ~ # PR作成を許可
ワークフローごとに許可する操作を限定できるため、「このワークフローはIssue作成だけ」「このワークフローはPR作成まで」といった細かい権限管理が可能です。
脅威検出（Threat Detection）
safe outputsが設定されている場合、GitHub Agentic Workflowsは自動的に脅威検出を実行します。これはエージェントの出力が実際にGitHubに書き込まれる前に、セキュリティ分析を行う追加のレイヤーです。デフォルトでは有効になっています。
検出フローは以下の順序で動作します。
- エージェントジョブ（読み取り専用権限で実行）
- 脅威検出ジョブ（エージェント出力のセキュリティ分析）
- Safe Outputsジョブ（安全確認後に書き込み権限で実行）
プロンプトインジェクション、シークレットの漏洩、悪意のある変更を検出します。
脅威が検出された場合、ワークフローは失敗し、safe outputsジョブはブロックされます。
詳細は脅威検出リファレンスを参照してください。
豊富なデザインパターン
GitHub Agentic Workflowsのリファレンスには具体的なデザインパターン/使用例がいくつも載っています。
その中で僕が気になったのはMultiRepoOpsパターンという、複数リポジトリを横断した自動化パターンです。
例えば、PRD（プロダクト要求仕様書）を別リポジトリで管理しているケースでは、PRDの変更に連動して開発リポ側にIssueを作成したり、実装状況をPRDリポ側にフィードバックしたりといった連携ができるようになるのではないかと思いました。
まとめ
GitHub Agentic Workflowsを使って、ワークフローを作成しました。 リファレンスには今回紹介した他にも細かい設定やユースケースが書かれています。
気になった方はぜひ公式ドキュメントを見て、試してみてください。
