GitHub Agentic Workflows実践ガイド——GitHub Actionsにコーディングエージェントを組み込む

はじめに

GitHub Actionsで CI/CD パイプラインを運用していて、こんなことを感じたことはありませんか？

• Issueが起票されるたびに、ラベル付けやトリアージを手作業でやっている
• READMEやドキュメントがコードの変更に追いつかず、いつも古いまま
• テストカバレッジの穴を見つけても、テストを書く時間が取れない
• 「ルールでは表現しきれないけど、毎回やっている判断」がたくさんある

2026年2月、GitHubがAgentic Workflowsのテクニカルプレビューを開始しました。これは、GitHub Actionsの中でAIコーディングエージェントを動かし、「判断が必要な反復作業」を自動化する仕組みです。

従来のCI/CDが「テストを実行する」「ビルドする」といった決定論的な処理を担当するのに対し、Agentic Workflowsは「このIssueの内容を読んで適切にラベルを付ける」「コードの変更に合わせてドキュメントを更新する」といった推論が必要な作業を担当します。

本記事では、架空プロジェクト「TaskFlow」（チーム向けタスク管理アプリ）を題材に、Agentic Workflowsをゼロから導入するハンズオンを行います。

Agentic Workflowsとは何か

従来のCI/CDとの違い

まず、従来のCI/CDとAgentic Workflowsの守備範囲を整理しましょう。

重要なのは、Agentic WorkflowsはCI/CDを置き換えるものではなく、補完するものだということです。

アーキテクチャ

Agentic Workflowsは2つのファイルで構成されます。

1. Markdownファイル（例: triage-issues.md）: 自然言語で「何をしてほしいか」を記述
2. Lockファイル（例: triage-issues.lock.yml）: コンパイルされたGitHub Actions YAML

開発者はMarkdownファイルを編集し、CLIでコンパイルするだけ。YAMLを手書きする必要はありません。

セキュリティモデル

Agentic Workflowsには多層的なセキュリティが組み込まれています。

PRが自動マージされることはありません。 人間のレビューが必ず挟まります。

事前準備

必要なもの

• GitHubアカウント（Agentic Workflowsテクニカルプレビューへのアクセス権）
• GitHub Copilot サブスクリプション（エージェント実行に必要）
• GitHub CLI（gh）がインストール済み

CLIエクステンションのインストール

gh extension install github/gh-aw

インストールを確認します。

gh aw --help

サンプルリポジトリの準備

架空プロジェクト「TaskFlow」のリポジトリを使います。

# リポジトリをクローン（ご自身のリポジトリで試す場合はこのステップは不要）
mkdir taskflow-app && cd taskflow-app
git init
gh repo create taskflow-app --public --source=. --push

ハンズオン1：Issueの自動トリアージ

最初のワークフローとして、新しいIssueが作成されたときに内容を読み取り、適切なラベルを付ける自動トリアージを構築します。

ワークフローの作成

.github/workflows/triage-issues.md を作成します。

---
on:
  issues:
    types: [opened]

permissions:
  contents: read
  issues: read

safe-outputs:
  add-labels:
    allowed-labels: ["bug", "feature", "question", "documentation", "good-first-issue"]
  add-comment:
    max-length: 500

tools:
  github:
---

# Issue自動トリアージ

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

## ラベルの判断基準

- **bug**: エラーや不具合の報告。「動かない」「クラッシュする」「期待と違う動作」などのキーワード
- **feature**: 新機能のリクエスト。「〜がほしい」「〜できるようにしたい」などのキーワード
- **question**: 使い方の質問。「どうすれば」「方法を教えて」などのキーワード
- **documentation**: ドキュメントの修正・追加要望
- **good-first-issue**: 内容がシンプルで、初めてのコントリビューターでも対応できそうなもの

## 対応ルール

1. Issueのタイトルと本文を読み、最も適切なラベルを1〜2個付ける
2. bugラベルを付けた場合、再現手順が不足していればコメントでテンプレートを提示する
3. featureラベルを付けた場合、ユースケースが不明確ならコメントで確認する

コンパイルと配置

gh aw compile triage-issues

これにより、.github/workflows/triage-issues.lock.yml が自動生成されます。この生成されたYAMLは、通常のGitHub Actionsワークフローとして実行されます。

git add .github/workflows/triage-issues.md .github/workflows/triage-issues.lock.yml
git commit -m "feat: Issue自動トリアージワークフローを追加"
git push

動作確認

Issueを作成してテストします。

gh issue create \
  --title "ダッシュボードの読み込みが遅い" \
  --body "タスク一覧ページを開くと、表示されるまで5秒以上かかります。
タスクが100件以上ある場合に発生します。
ブラウザのコンソールにエラーは出ていません。"

数分後、エージェントがIssueを分析して bug ラベルを付け、再現環境の情報を求めるコメントが追加されます。

ハンズオン2：ドキュメントの自動同期

コードが変更されたとき、対応するドキュメントが古くなっていないかチェックし、更新PRを作成するワークフローを構築します。

ワークフローの作成

.github/workflows/sync-docs.md を作成します。

---
on:
  push:
    branches: [main]
    paths:
      - "src/**/*.ts"
      - "src/**/*.tsx"

permissions:
  contents: read
  pull-requests: read

safe-outputs:
  create-pull-request:
    draft: true
    branch-prefix: "docs-sync/"
    title-prefix: "[Docs] "

tools:
  github:
---

# ドキュメント自動同期

mainブランチにコードが変更された際、関連するドキュメントの更新が必要かチェックします。

## チェック対象

- `README.md`: プロジェクト概要、セットアップ手順
- `docs/` 配下のすべてのMarkdownファイル
- コンポーネントファイル内のJSDocコメント

## 判断基準

以下の変更があった場合、ドキュメントの更新PRを作成してください：

1. **APIの変更**: 関数のシグネチャ、引数、戻り値が変わった場合
2. **環境変数の追加・変更**: `.env.example` やセットアップ手順の更新が必要
3. **新しいコンポーネントの追加**: コンポーネントカタログへの追記
4. **設定ファイルの変更**: 設定手順の更新が必要

## 出力ルール

- PRはドラフトで作成する
- 変更点と理由をPR本文に明記する
- ドキュメントの修正箇所を具体的に示す

コンパイルとプッシュ

gh aw compile sync-docs
git add .github/workflows/sync-docs.md .github/workflows/sync-docs.lock.yml
git commit -m "feat: ドキュメント自動同期ワークフローを追加"
git push

動作の流れ

コードを変更してpushするたびに、エージェントがドキュメントの整合性を自動チェックし、必要であればドラフトPRを作成してくれます。

ハンズオン3：週次レポートの自動生成

スケジュール実行で、リポジトリの活動状況をまとめたレポートを自動生成するワークフローを構築します。

ワークフローの作成

.github/workflows/weekly-report.md を作成します。

---
on:
  schedule:
    - cron: "0 9 * * 1"

permissions:
  contents: read
  issues: read
  pull-requests: read

safe-outputs:
  create-issue:
    title-prefix: "[Weekly Report] "
    labels: ["report"]

tools:
  github:
---

# 週次リポジトリレポート

毎週月曜9:00（UTC）にリポジトリの活動状況をまとめたレポートを作成します。

## レポートに含める内容

### 1. 今週のアクティビティ
- マージされたPR数と主な変更内容
- 新規Issue数とクローズされたIssue数
- コミット数とアクティブなコントリビューター

### 2. 注意が必要な項目
- 7日以上放置されているオープンIssue
- レビュー待ちのPR（3日以上）
- CIが失敗しているブランチ

### 3. 来週の推奨アクション
- 優先的に対応すべきIssue
- マージを推奨するPR
- 改善が見込めるコード領域

## フォーマット

レポートはMarkdownの表を使い、見やすく整理してください。
数値には前週比（+5、-3など）を付けてください。

コンパイルとプッシュ

gh aw compile weekly-report
git add .github/workflows/weekly-report.md .github/workflows/weekly-report.lock.yml
git commit -m "feat: 週次レポート自動生成ワークフローを追加"
git push

これで毎週月曜日に、リポジトリの状況をまとめたIssueが自動作成されます。

既存のCI/CDパイプラインとの使い分け

モリソンでは以前から、n8n + Claude Code GitHub Actionsを使った自動実装パイプラインを運用しています。この既存パイプラインとAgentic Workflowsは、どう使い分けるべきでしょうか？

比較表

推奨する使い分け

ポイント:

• 外部ツールとの連携が必要 → n8n + Claude Codeパイプライン
• GitHub内で完結 + 判断が必要 → Agentic Workflows
• GitHub内で完結 + ルールベース → 従来のGitHub Actions

実践Tips

Tip 1: 小さく始める

最初からすべてを自動化しようとせず、リスクの低い作業から始めましょう。

Tip 2: Markdownの指示は具体的に書く

曖昧な指示は意図しない結果を招きます。

<!-- ❌ 曖昧な指示 -->
Issueを整理してください。

<!-- ✅ 具体的な指示 -->
Issueのタイトルと本文を読み、以下の基準でラベルを付けてください：
- エラーや不具合の報告 → "bug"
- 新機能のリクエスト → "feature"
- 使い方の質問 → "question"
1つのIssueに付けるラベルは最大2個までとします。

Tip 3: Safe Outputsの範囲を絞る

必要最小限の権限だけを付与します。

# ❌ 広すぎる権限
safe-outputs:
  create-pull-request: {}

# ✅ 範囲を絞った権限
safe-outputs:
  create-pull-request:
    draft: true
    branch-prefix: "agent/"
    title-prefix: "[Auto] "

Tip 4: コスト管理

Agentic WorkflowsはGitHub Copilotのプレミアムリクエストを消費します。1回のワークフロー実行で通常2リクエスト（タスク実行 + 安全性チェック）が消費されます。

高頻度のトリガー（すべてのpushなど）を設定する場合は、pathsフィルタでスコープを絞りましょう。

on:
  push:
    branches: [main]
    paths:
      - "src/**"  # srcディレクトリの変更時のみトリガー

まとめ

GitHub Agentic Workflowsは、従来のCI/CDでは自動化できなかった**「判断が必要な反復作業」**をGitHub Actions内で自動化する仕組みです。

次のアクション

1. gh extension install github/gh-aw でCLIをインストール
2. 最もシンプルなワークフロー（週次レポートなど）から試す
3. チームで運用ルールを決めてから本番導入する

現在テクニカルプレビュー段階のため、本番環境での利用は慎重に検討してください。まずは個人プロジェクトやサブリポジトリで感触を確かめるのがおすすめです。