ハクソク

世界を動かす技術を、日本語で。

GitHub エージェンティックワークフロー

106日前原文(github.github.io)

概要

  • GitHub Agentic Workflows は、AIによるリポジトリ自動化を実現する新機能
  • Pull Request作成、Issue管理、CI解析 などを自然言語で指示可能
  • セキュリティ重視 の設計で、安全かつ最小権限で動作
  • Copilot, Claude, Codex 等のAIエージェントを活用
  • 導入・運用は コマンドラインやWebインターフェース から簡単に開始可能

GitHub Agentic Workflowsの概要

  • GitHub Agentic Workflows は、AIエージェントによる リポジトリ運用自動化 のためのGitHub Actions拡張機能
  • 毎朝自動でPull Request が届き、レビュー待ち状態を実現
  • Issueの自動トリアージ、 CI失敗解析、 ドキュメントの自動保守、 テストカバレッジ向上、 コンプライアンス監視 をMarkdownファイルで指示
  • GitHub Copilot, Claude, OpenAI Codex などのAIが イベント駆動や定期実行 でリポジトリを改善
  • 既存CI/CD と組み合わせて Continuous AI 機能を追加

セキュリティとガードレール

  • 開発元：GitHub NextとMicrosoft Research
  • 最小権限実行 を原則とし、 書き込み操作は明示的許可 が必要
  • サンドボックス実行、 ツール許可リスト化、 ネットワーク分離 による安全性確保
  • デフォルトは読み取り専用、書き込みは 安全な出力のみ許可
  • 事前承認済みGitHub操作 のみを通じてリポジトリ変更

Daily Issues Reportワークフロー例

  • 毎日の定期実行 でチーム向け ステータスレポートIssue を自動作成
  • 手順：
    • Markdown形式で自動化指示 を書いた.mdファイルを作成
    • gh aw compileコマンド でGitHub Actions用ワークフロー（.lock.yml）に変換
    • GitHub Actionsが自動実行 し、AIエージェントがIssueを作成
  • AIエージェント はリポジトリ情報を読み込み、 可視化やレポート生成 まで自動化

主な自動化タスク例

  • コードの簡素化・リファクタリング・スタイル統一 の自動化
  • スラッシュコマンド によるオンデマンド分析や自動化
  • ドキュメントの継続的保守・一貫性維持
  • Issueの自動トリアージ・ラベリング・プロジェクト連携
  • 日次レポート・トレンド分析・ワークフロー健全性監視
  • セキュリティスキャン・アラートトリアージ・コンプライアンス監視
  • CI失敗診断・テスト改善・品質チェック
  • 機能同期・クロスリポジトリ追跡
  • DailyOps・研究・自動保守作業

導入とワークフロー作成

  • 拡張機能インストール、サンプルワークフロー追加、初回実行 まで数分で完了
  • コマンドライン から簡単に開始可能
  • GitHub Webインターフェース でも自然言語でカスタムワークフロー作成が可能

GitHub Agentic Workflows は、 AI自動化 と セキュリティ を両立した次世代リポジトリ運用基盤。 開発・保守・運用の効率化 を目指すチームに最適なソリューション。

Hackerたちの意見

フィッシーじゃないリンクはこちら: https://github.com/github/gh-aw これはGitHubの公式アカウントにあるやつだね。なんでGitHubが別のドメインなしでGitHub Pagesにこれを展開してるのか、ちょっと謎だな。

└

なんでそれがフィッシーになるの？彼らはGitHubの組織を持ってるから、github.github.ioなんだよ。深く考えなくても、面白い再帰的な感じだと思ってた。Redditが/r/reddit.comを持ってたり、Twitterが@twitterを持ってたりするのと似てるよね。

└

自分たちの製品を使うのがフィッシーなの？よくわからないな。他の誰かがこのリンクを持つことができるわけじゃないし、できたとしても。

└

これ、プレリリースの製品みたいだね。ブランドや評判のリスクを下げるためのものだろう。

└

これはGitHub Pagesの機能だね。「example」って名前のアカウントがあれば、example.github.ioに静的ページを公開できる。だから、github.github.ioからのものであれば、「github」アカウントによって公開されたことを意味してる。

└

GitHub Pagesのサイトは、デフォルトでORGNAME.github.ioだよ。最近、これをgithubnext組織からgithub組織に移したんだけど、github.com/whateverに何かルートを専用に設定しない限り、github.github.ioがgithub組織のページ用のドメインなんだ。

└

すみません、いいリンクはこっちです：https://github.github.com/gh-aw/ でも、リダイレクトが設定されてて、https://github.github.io/gh-aw/ でもアクセスできました。どちらも動くし、リダイレクトも修正したので、ありがとう！

これ、ちょっと混乱するな。LLMがCI/CDワークフローの開発を手伝う価値はわかるけど、なんでCI/CDに継続的に関わらせたいのかがわからない。コンパイルフェーズがあるから、そこまで悪くはないかもしれないけど、付加価値があまり明確じゃないし（マークダウンと生成されたワークフローの両方をチェックする理由とか、変更が必要なときにマークダウンから常に再生成すべきかとか）。GitHub Actionsのセキュリティに関する評判が微妙な中で、追加の抽象化を重ねる前に、GHAの根本的な弱点に対処してほしいな。

└

これ、ちょっと混乱するな。LLMがCI/CDワークフローの開発を手伝う価値はわかるけど、なんでCI/CDに継続的に関わらせたいのかがわからない。これが合理的なケースなのは、人間向けのプロジェクトドキュメントを提供するためで、実際のコードではないよね。（例えば、最近のコミットを見た後にAIエージェントに自分の「コードレビュー」レポートを書かせるとか。）内部ではCI/CDソリューションを使って実装されてるけど、実際のCI/CDではないんだ。

└

自分のMCPサーバーを使って、LLMからの意味的な応答が期待通りかどうかを確認するためにLLMの行動テストを使ってる。これは正規表現テストを超えて、適切な意味的応答があるかを見るためのもの。時々、LLMが技術的には「いいえ」だけど、実質的には「はい」っていう変わった応答を返してくることもある。モデルによって意味的に異なる動作をすることもあるし。もしGitHubに組み込まれた素敵なCI/CDワークフローがあれば、ローカルで動かしてる自分のを作るよりも、ちょっと自動化されて楽になるかもしれないな。

└

でも、CI/CDに継続的に関わらせたい理由は何なの？助けることが目的じゃなくて、トークンを消費して収益を上げるのが目的なんだから、終わりのない「AI」エージェントの群れを使うのは素晴らしい方法だよね。

└

これは、非技術者がノーコード・ローコードで自分のワークフローやCIを作れるようにして、成功している企業と競争できるようにするためだと思ったんだ。でも、実装がめちゃくちゃひどい。確かに「自然言語」で指示を書いて、うまくいくことを期待することはできるけど、結局は古い問題から逃れられなくて、必要なガードレールを設定するためにYAML税を払わなきゃいけない。彼らの例を見て笑っちゃうよ: https://github.com/github/gh-aw?tab=readme-ov-file#how-it-wo... マークダウンで16語書いて、YAMLで19語。エージェントを信じられないから、結局は無意味なYAMLをたくさん書かなきゃいけない。理解しようとしてるけど、まず権限を与えて、ここでは読み取り権限しか提供してない。そして出力権限を与えるけど、実際には前の権限よりも狭い範囲での書き込み権限なんだ。明らかに、何か問題が起きても責任を逃れようとして、ユーザーに注意を促してるし、エージェントが緩すぎないように出口ファイアウォールを設定することを提案してる: https://github.com/github/gh-aw-firewall ITが管理するインフラに実際のセキュリティツールを使ってワークフローエンジンを設定する代わりに、GitHubでYAMLとマークダウンをくっつけるだけで済むのに、なんでそんなことするんだろうね？

└

私は、ジェネAIによるリファクタリングやドキュメントメンテナンスでリポジトリがスパムされるようなワークフローは全く望んでない。そんなの、ただのオーバーヘッドを生むだけだし、AIをワークフローに無理やり押し込むための言い訳に聞こえる。

└

ここに決定論に関するFAQを追加したよ： https://github.github.io/gh-aw/reference/faq/#determinism

使うべきじゃないところにエージェントを詰め込むんじゃなくて、すでに使ってるエージェントとシステムをうまく連携させるべきだよね。明らかにマーケティング主導の金儲けだ。

└

人がすでに使っているエージェントでシステムをより良くするのではなく、関係ないところにエージェントを詰め込むこと。LLMベースのエージェントコーディングにはあまり期待してないけど、エージェントを置く場所があるとしたら、CIや課題、ソースコードにアクセスできる中央集権的なプロバイダーだと思う。完璧なフィットに見えるね。

GitHubはまずコアの提供を整えることに集中すべきだと思う。これにぶつかってからGHアクションを使うのをやめたよ: https://github.com/orgs/community/discussions/151956#discuss... それがほぼ1年前で、今でも同じ問題にハマってる人のアップデートが届くんだよね。

└

これ、ちょっとコパイロットのクソみたいな話を思い出すな。コパイロットは使ってないんだけど、数日おきにGitHubのホームページに行くと、コパイロットのチャット入力（そもそもホームページに欲しくないやつ）が、月の使用限度を超えたから無効になってるって言ってくるんだ。マジで使ってないし、アカウントもハッキングされてないよ。人を騙してお金を払わせようとしてるの？なんか漫画みたいにバカバカしいけど…

└

まあ、この行動には理由があるね。彼らは成長株のふりをして、ちょっとだけその幻想を維持しようとしてるブルーチップだから。

└

ああ、重要な問題のジレンマだね。無料ユーザーの一部が有料ユーザーになるけど、無料ユーザーは不合理なほど多くの時間やエネルギー、サポートを取っていく。解決策はシンプルそうだね。彼らの製品を買えばいい。

└

「"In shape"ってどういう意味？これはただの無料アカウントの限界に達してるだけで、メッセージにもはっきり書いてあるよね。> 同じ問題に陥ってる人がいる。無料プランを持つSaaSプロバイダーはみんなこの問題を抱えてる。どうやって解決すべきだと思う？」

└

何年もGithubの有料ユーザーなんだけど、Github Actionsを使っているオープンソースのメンテナーとして、俺のお金がAIのクソみたいなものに使われて、コアの改善や修正に使われてないのがイライラする。

これはgh cliの拡張機能で、マークダウンファイルを入力として受け取り、GitHub Actionsのワークフローファイルを作成するんだ。普通のワークフローファイルじゃなくて、1000行の化け物みたいなやつで、何をするのか説明するにはLLMが必要になる。gh aw initを試して、間違ったプロンプトでYを押しちゃった。そしたら、たまたまいたGitHubリポジトリにCOPILOT_GITHUB_TOKENが作成されたみたいで、たぶん自分のアカウントのトークンを使ったんだ。これは本当に追加の確認が必要だと思う。

└

ありがとう、これが変更されました（ローカルトークンの使用なし）し、今は追加の確認もあります。

ランディングページが、これが自分にどんな価値を提供してるのか全然わからない。理論的にはできることは見えるけど、(1) その具体的な例が見えないし、(2) この特定のエージェントのワークフローがどう役立つのかもわからない。

└

https://github.github.io/gh-aw/#gallery ページの下の方に具体的なアプリケーションのリストがあるよ。例えば、https://github.github.io/gh-aw/blog/2026-01-13-meet-the-work... には、問題やPRを管理するためのエージェンティックなワークフローのいくつかの例があって、それらの例は実際のエージェンティックワークフローファイルにリンクしてるから、自分のワークフローの出発点として読んだり使ったりできる。価値は「ヒューリスティックでは処理できない雑用を委任する」ことだよ。ストーリーをどう伝えるかを考えながら進めてるから、指摘してくれてありがとう！

go.modに変な行を見つけて、なんでこれにreplaceを使ってるのか気になったんだ。普通はgo get github.com/Masterminds/semver/v3@v3.4.0ってやるよね。 replace github.com/Masterminds/semver/v3 => github.com/Masterminds/semver/v3 v3.4.0 これ、すごく疑わしいPRを見つけたんだ[0]。どうやらdependabotがバージョンアップのためのイシューを作ったのがきっかけみたいで、そもそも必要なかったんじゃないかな。で、コパイロットエージェントがreplace文を追加して実装したんだけど、これが正しいやり方じゃないんだよね。それに、なんか関係ない変更も含まれてた。コパイロットのレビュアーはその関係ない変更を指摘したけど、人間のメンテナーは気づかなかったみたいで、そのままマージしちゃった。ここには本当にいろいろと問題があるよね。

└

これ、私が使ったすべてのエージェントとnpmのpackage.jsonファイルで起こることだよ。npm i fooを使う代わりに、エージェントがpackage.jsonを文字列編集して、インストールするバージョンを幻覚で決めちゃう。だいたいはまあまあなバージョンなんだけど、これが私が望む動作じゃないんだ。コード内の名前変更なんかはもっとひどい。エージェントがリファクタリングツールを使えるのを見たことがない（VS Codeにそんなものがあればだけど）、文字列置換やsedで強引に名前を変えるだけなんだ。エージェントは編集→ビルド→エラーを読む→繰り返すって感じで、信頼できるツールを使わずにやってるから、もっとGPUを消費するんだよね…。

└

彼らはこのコメントを使って修正しようとしてたけど、途中でキャンセルしちゃった。理由はわからない。 https://github.com/github/gh-aw/pull/14548

└

パッケージのアップグレードには具体的なプロンプトを使うのがめっちゃ重要だよ。開発者が何をするか考えてみて：- 最新バージョンをオンラインでチェックする；- チェンジログを見る；- アップグレードする価値があるか、コードの更新が必要な場合は中間バージョンで大丈夫か評価する。もちろん、これらの操作は人間がやるべきだけど、本当にこの部分を自動化したいなら（その結果を受け入れる覚悟があるなら）、同じワークフローを模倣する必要がある。私はGeminiとCodexを使ってオンラインでパッケージのバージョン情報を探してる。自分が使ってるバージョンからアップグレードしたいバージョンまでのチェンジログをチェックして、Claude Opusのサブエージェントを使ってコード内で何かアップグレードが必要か確認する。メジャーリリースの場合は、2つのパッケージをgit cloneして、別のサブエージェントが自分が使ってるインターフェースが変わったかどうかをチェックする。最後に、全てのテストを実行して、問題がないか確認する。そう、まだ完璧じゃないかもしれないけど、私も完璧じゃないし。

└

これは私のAIに対する核心的な不満のさらなる証拠だよ（そして、なぜ今の時点でAGIではないのか）。AIは何が起こっているのか理解していなくて、代わりに文字列のパターンをマッチさせて、そのパターンを使って新しい文字列を作り出してる。見た目は正しいけど、検査すると失敗する。（関わっている人間も私のチューリングテストに失敗してる…）

MSFTとGitHubがやってることに、なんとなく近い気がする。主に、これは素晴らしいアイデアだと思って、自分でも実験してるから。特に、自動的・継続的な改善の観点からね（https://github.github.io/gh-aw/blog/2026-01-13-meet-the-work...）。よくコードはアーティファクトとして見られて、そのまま価値があると考えられるけど、これは以前の不完全な見方で、今は完全に間違った見方だと思う。価値があるのは、コードがそれを作る組織の知識をどう表現しているかなんだ。でも、もっと価値があるのはその知識自体。組織の人々に埋め込まれているからね。だから、コードベースの継続的かつ自動的な改善がすごく重要なんだ。コードは時間や機能要求で腐っていくのはみんな知ってるけど、一方で、全体のコードベースのアーキテクチャを急に変えると、組織の人々のメンタルモデルが壊れちゃう。私がうまくいくと思うのは、小さな改善のゆっくりとした流れだね。それは組織の人々が消化できるものなんだ。この文脈では、決定論的な実行を混ぜて、上にちょっとしたインテリジェンスを加えるのがより有用だと思う。だから、何が間違っているのかを見つけ出す決定論的なシステムがあって、必要なときに問題を実際に修正するためにLLMを使う感じ。

└

私たちはいくつかの基本要素が欠けてると思う。プロジェクトの構造における不変量を定義して、それをエージェントに伝えるための良い抽象化が必要だよ。たとえそれがあっても、プロジェクトがそのパターンを一貫して適用していない場合、エージェントは混乱したり、何かを誤って適用したりすることがある（もしかしたら「言うことを聞け、やることは見ないで」って怒ってるのかも）。私はエージェントをこのように誘導するために多くの努力を費やしてるから、実際に面倒くさい。Deep Wikiスタイルで物事の動き方を列挙する感じ、エージェント用のC4ダイアグラムみたいな。

└

そうですね、いいポイントですね。エージェントワークフローは、アルゴリズミックなステップとエージェントのステップを組み合わせることができます。「DataOps」と呼ばれるデザインパターンがあって、これがまさにそのことを指しています。アルゴリズミックな抽出の後に、エージェントのステップで安全な出力を提供する感じです。

いいタイミングだね。週末を使って、CIエージェントのワークフローを作ってたんだ。そこでCCを隔離されたVMでスキップ権限を持たせて、非同期でgiteaリポジトリで作業できるようにしてる。CCインスタンスにそこそこ大きなミッションを与えておけば、CIがグリーンになるまで繰り返してくれて、PRを作ってくれるんだ。今は、同期的に一つのClade Codeを話すのから、小さなグループの協力するClaudesを管理する方向に移ってる。

└

クレイジーな時代だね。

└

それ、いくらかかるの？

GitHubエージェンティックワークフローはこれを提供する：リポジトリの自動化、あなたが知っていて愛しているコーディングエージェントをGitHub Actionsで動かすこと、強力なガードレールとセキュリティファーストの設計原則を持って。GitHub Actionsは、セキュリティファーストの設計原則を認識するのに信頼できる最後の組織だとは思えない。

└

確かに、ページの最後の文は「注意して、自分の責任で使ってください。」だね。