GitHub の Agentic Workflows preview を見て、最初に思ったのは「ついに agent が CI 側に入ってきたな」でした。

今までの coding agent は、だいたい editor や issue の横にいました。人間が task を投げて、branch ができて、PR diff を見る。怖さはあるけど、まだ「人間が呼び出した作業」という感覚が残る。

でも GitHub Actions に寄ってくると、話が少し変わります。CI failure、issue triage、docs update みたいな repo event に対して agent が動ける。便利です。かなり便利。ただ、frontend repo でこれを雑に入れると、review queue が一気に濁ります。

この記事では、GitHub の新機能紹介ではなく、AI agent を GitHub Actions に入れる前に決めておきたい境界線を整理します。

まず決めるのは model ではない

agent を導入するとき、つい「どの model が賢いか」「prompt をどう書くか」から始めたくなります。

でも Actions に入れるなら、先に決めるべきなのはこっちです。

agent が読んでよいもの
agent が変更してよいもの
agent が止まる条件
人間が review で見るログ
PR を作ってよい task と、comment だけにする task

ここが曖昧なまま agent を動かすと、成功したときも失敗したときも判断しづらいです。

「なんか直してくれた」PR は気持ちいい。でも、どのログを見て、どのファイルを読んで、どこを触らなかったのかが分からない PR は、review のコストが高い。

最初は read-only の CI failure analysis がいい

いきなり commit / push まで許可しない方がいいです。

最初にやるなら、CI failure analysis が扱いやすいと思います。frontend repo なら lint、typecheck、unit test、Playwright の失敗が入り口になります。

この段階で agent にやらせることは、修正ではなく調査です。

allowed:
  - read workflow logs
  - read test output
  - inspect changed files
  - suggest reproduction commands

not_allowed:
  - commit
  - push
  - create pull request
  - update dependencies
  - change workflow permissions

出力も PR ではなく、issue comment や workflow summary で十分です。

CI failure summary:
- failed job: typecheck
- suspected files:
  - src/components/SearchPanel.tsx
  - src/hooks/useSearchParams.ts
- likely cause:
  - props の型変更に対して test helper が古い
- suggested command:
  - pnpm test SearchPanel
  - pnpm typecheck
- not inspected:
  - browser visual regression
  - production build

これだけでも結構助かります。大事なのは、agent の出力を「修正済み」として扱わないことです。まだ調査メモです。

write permission を渡すなら path を狭くする

次に write permission を渡すとしても、repo 全体に渡さない方がいいです。

たとえば frontend repo なら、最初はこのあたりが無難です。

docs / README の追従
Storybook example の軽い修正
unit test fixture の更新
component demo の copy 修正
lint / format の明確な修正

逆に、最初から触らせない方がいい場所もあります。

.github/workflows/**
package.json
lockfile
auth / payment / permission 周り
release / deploy script
migration script

「frontend だから安全」とは限りません。CSS の修正でも広がると画面全体に影響します。copy の変更でも product の意味が変わることがあります。

なので、workflow contract を明示します。

Task contract:
- CI failure の原因が lint / unit test / typecheck の範囲なら修正してよい
- 触ってよい path:
  - src/components/**
  - src/hooks/**
  - tests/**
  - stories/**
- 触らない path:
  - .github/**
  - src/auth/**
  - src/billing/**
  - package.json
  - pnpm-lock.yaml
- PR には必ず書く:
  - 実行した command
  - 確認できた範囲
  - 確認していない範囲

この contract があると、人間の review がだいぶ楽になります。

diff だけを見て「まあ動きそう」と判断するのではなく、「そもそも agent が触っていい範囲だったか」を先に見られるからです。

review surface は diff だけでは足りない

agent の PR は、人間の PR より review surface を広く取った方がいいです。

最低限見るものはこの 5 つ。

PR diff
GitHub Actions log
agent session log または chat context
実行した command
agent が触らなかった範囲

特に大事なのは、最後の 2 つです。

「テスト通りました」だけでは弱い。どの command を実行したのか。pnpm test なのか、対象 test だけなのか、typecheck は見たのか、build は見ていないのか。

agent はそれっぽく説明できます。だから説明の自然さではなく、作業の跡を見る方がいい。

PR template に入れるなら、こういう形にします。

## Agent work log

- Trigger:
- Allowed scope:
- Changed paths:
- Commands run:
- Logs inspected:
- Not inspected:
- Human approval required before merge:

人間が書く PR でも使えますが、agent PR ではほぼ必須に近いと思っています。

frontend repo で最初に向く workflow

個人的には、最初の 4 つはこのあたりです。

CI failure analysis

read-only で始められます。

失敗 job、怪しい file、再現 command、関連 PR の差分をまとめるだけでも価値があります。修正までやらせるのは、そのあとでいい。

docs / README update

API 名や command が変わったときの追従です。

失敗しても rollback しやすいし、review もしやすい。ただし product claim を勝手に書き換えないように、触ってよい section は絞った方がいいです。

Storybook / example repair

component の props 変更に story が追従していない、みたいな修正です。

frontend ではけっこう地味に効きます。PR diff と画面確認が結びつくので、agent の作業を評価しやすい。

issue triage

label 付け、duplicate 候補の提示、再現情報不足の指摘くらいまで。

いきなり issue を close させるのは強すぎます。最初は suggestion に留める方がいい。

逆に、最初から任せない方がいいもの

ここは慎重でいいです。

dependency update の自動 merge

依存更新は、lockfile、build output、runtime 挙動まで波及します。

特に frontend は plugin、bundler、CSS、SSR、test runner の相性で壊れます。agent が PR を作るのはありでも、自動 merge は別問題です。

release / deploy

release note の下書きくらいならいいです。

でも tag 作成、publish、deploy trigger は最初の対象にしない方がいい。失敗したときの戻し方が repo 内の diff だけで済まないからです。

auth / payment / permission 周り

ここは agent の賢さより、review の責任が重いです。

「小さい修正に見える」ものほど危ない。guard 条件を 1 行変えるだけで挙動が変わります。

visual redesign の丸投げ

これは単純に review がつらいです。

agent は大量の CSS を触れます。動くかもしれない。でも、意図した UI か、既存の design system に合っているか、mobile で崩れていないかを見るのは人間です。

最初は Storybook example の小さい修正くらいにしておく方が現実的です。

workflow file に境界線を書く

口約束では忘れます。

agent 用の workflow には、少なくとも以下を置きたいです。

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

agent_scope:
  mode: suggest-first
  allowed_paths:
    - "src/components/**"
    - "src/hooks/**"
    - "tests/**"
    - "stories/**"
  blocked_paths:
    - ".github/**"
    - "src/auth/**"
    - "src/billing/**"
    - "package.json"
    - "pnpm-lock.yaml"
  allowed_tasks:
    - ci_failure_analysis
    - docs_update
    - storybook_example_repair
  exit_conditions:
    - touches_blocked_path
    - requires_dependency_update
    - changes_release_or_deploy_behavior

実際の YAML がこのまま動く、という話ではありません。大事なのは、こういう contract を workflow の近くに置くことです。

agent に「良い感じに直して」と言うのではなく、「この範囲なら直してよい。ここを超えるなら止まれ」と書く。

PR を作る条件と comment で止める条件を分ける

全部 PR にすると、review queue が荒れます。

たとえば、こう分けます。

Create PR when:
- changed paths are inside allowed scope
- no dependency update is required
- local command succeeds
- confidence is high enough to explain the fix in 5 lines

Comment only when:
- root cause is unclear
- blocked path may be involved
- dependency or workflow change is needed
- reproduction command fails locally
- visual confirmation is required but unavailable

この線引きがないと、agent は「何かできそう」なときに PR を作りがちです。

でも本当に欲しいのは、PR 数を増やすことではありません。人間が安心して見られる作業単位にすることです。

まとめ

Actions に入った agent は、もう editor extension ではありません。repo automation です。

だから最初に見るべきなのは、model の性能表ではなく workflow の境界線です。

読めるログ。触れる path。止まる条件。PR に書くべき確認範囲。comment で止める判断。

このあたりを先に決めると、agent はかなり使いやすくなります。逆にここを決めないまま自動化すると、便利そうな PR が増えて、review の負債も増えます。

最初の一歩としては、read-only の CI failure analysis で十分です。そこから docs、Storybook、狭い test 修正へ広げる。release や dependency update は、運用が見えてからでいい。

agent を repo に入れるなら、最初に作るべきものは prompt 集ではなく、読めるログと戻せる PR だと思います。

Source notes

GitHub Agentic Workflows public preview: https://github.blog/changelog/2026-06-11-github-agentic-workflows-is-now-in-public-preview/
Agent tasks REST API: https://github.blog/changelog/2026-06-04-agent-tasks-rest-api-now-available-for-copilot-pro-pro-and-max/
Copilot Chat now sees your agent sessions: https://github.blog/changelog/2026-06-10-copilot-chat-now-sees-your-agent-sessions/