Reactのフォームで「送信に失敗したあと、エラーが残って再送信できない」というissueが立ったとする。担当者のチャットでAIに調べてもらうだけなら、結果をその人が読み直せば済む。チームでissue起動の自動化にすると、話が変わる。誰の権限でコードを読み、どこに調査結果を残し、誰が費用と設定変更を引き受けるのか。
ここを個人のpromptに閉じ込めると、次の担当者には引き継げない。僕ならまず「調査だけして人に返す」作業票をリポジトリの運用設定として決める。以下は導入前の設計例で、GitHub上で動作確認した記録ではない。
似た発表でも、同じ設定ファイルではない
2026年10月28日、GitHubはAgentic Workflowsの一般提供を発表した。Markdownでワークフローを定義し、GitHub ActionsのYAMLへ変換して実行する仕組みだ。エージェントの既定権限はread-onlyで、コンテナ内のsandboxやsafe outputsなどの保護も説明されている。ただし「既定で読み取り専用」は、追加で許可した出力や設定まで無条件に安全という意味ではない。
同日に発表された共有Copilot Automationsは別の仕組みだ。repoが所有するprompt、trigger、許可するtoolsをチームで扱う。活動はCopilot名義になり、AIクレジットはrepo所有者に請求される。こちらは順次提供で、組織所有repoでは管理者ポリシーの確認も要る。Agentic WorkflowsのMarkdown定義をAutomationsへそのまま持ち込める、と考えないほうがいい。
製品を選ぶ前でも、フロントエンドのissueをどこまで調べるかは先に書ける。
作業票は「実行設定」ではなく、レビューする契約
次は架空のReact/TypeScriptリポジトリ向けの作業票。GitHubの正式なYAMLやAutomationsの設定文法ではない。そのまま貼っても動かない。
仕事: フォームの再送信不具合について一次調査する（修正PRは作らない）
起動: issueが作られ、保守担当が調査対象と判断したとき
所有: リポジトリの保守担当。設定変更をレビューする人を別途決める
入力: 匿名化したissue本文、関連するフォームとテスト、公開してよいCI結果
許可: まずコードと既存の検査設定の読み取りだけ
提出: 再現条件、参照ファイル、実行した検査と結果、未確認事項、担当者への質問
停止: 秘密情報を含む、権限追加や書き込みが要る、再現条件を絞れない
確認: 担当者が匿名テストデータで再現し、報告と実際の画面を照合する
運用: repo所有者への請求、利用上限の設定可否、設定変更履歴を確認する
「起動」は単純なissue openedだけにしないほうがいい。外部から作られたissueに顧客データが紛れたら、エージェントに渡す前に止めたいからだ。具体的なフィルタや承認方法は、選んだ製品の実際のトリガーと組織の権限設定で確かめる。作業票に「秘密を読まない」と書くだけではアクセス制御にならない。
提出物も「原因を特定しました」だけでは困る。たとえば次のように、観察と推測を分ける。
対象issue: #123（架空の例）
観察: エラー表示の状態管理はフォーム側、再送信ボタンは共通部品側
実行済み: なし（CIの結果を閲覧しただけ）
再現: 匿名の失敗応答を使った画面確認は未実施
仮説: 失敗後に送信中フラグが戻らない可能性
次に人が見る点: 失敗応答時に入力値とボタン状態がどう変わるか
これなら「コードを読んだ」と「ブラウザで再現した」が混ざらない。サンプルは検査結果の実録ではないので、実際の報告には見た事実だけを書かせる。
最初の一件を通す前の確認
まず保守担当がissue templateを見直す。再現手順、期待する表示、ブラウザ、匿名化した入力を要求できるか。次に、エージェントから参照できるリポジトリと外部ツールの範囲、既存CIに実在する検査、コメントなど書き込み先の権限を確認する。読み取り中心の一次調査と、issueへの投稿やPR変更は分けて扱う。
小さな一件で報告を受け取り、人が「未実施」と書かれた操作を誤って実施済みと扱っていないか、提示された条件でフォームの失敗状態を作れるかを見る。合わなければ作業票の入力・提出条件を直す。いきなりtoolsの権限を増やす理由にはならない。
共有設定の編集権限、変更履歴、AIクレジットの請求先、上限を設定できるかもオーナーと確認しておく。個人のチャットなら曖昧にできた部分が、チームの自動化では運用負債になる。
Atlassianの2026年の開発者体験調査では、AIで出荷が速くなったと答えた人が87%だった一方、日々の摩擦が減ったと答えた人は28%だった。これは回答者の自己申告であって、この作業票やGitHub製品の導入効果を示す数字ではない。調査をそのままチーム改善の根拠にするより、次のissueでも同じ証拠を引き継げるかを見たい。
最初の自動化は修正PRまで広げなくていい。保守担当が、同じ停止条件と提出形式で別のissueも読めるか。まずそこまで動かしてから、書き込みを伴う次の仕事を設計する。
参考
- GitHub Agentic Workflows generally available：Markdown定義、Actionsでの実行と保護策。
- Build shared workflows for your team with Copilot Automations：共有設定の所有、順次提供、請求先。
- State of Developer Experience Report 2026：開発者の自己申告調査。自社の導入結果ではない。