5 ポイント 投稿者 GN⁺ 2026-02-10 | 1件のコメント | WhatsAppで共有
  • コード改善、ドキュメント保守、テスト強化などが GitHub Actions 内で自動的に実行される 自動化リポジトリエージェントシステム
  • 毎朝、自動的に改善されたコードが Pull Request 形式で提出される
  • Issue分類、CI失敗分析、ドキュメント保守、テストカバレッジ改善、コンプライアンス監視 などを自動実行
  • すべての自動化は シンプルなMarkdownファイル で定義され、複雑なコードを書かずに自然言語で指示可能
  • Copilot, Claude, Codex など多様なAIエンジンを活用して、イベント駆動・定期的な作業を実行
  • サンドボックス実行と最小権限の原則 により、セキュリティと安全性を強化
  • GitHub Next と Microsoft Research が共同開発し、セキュリティ中心設計と強力なガードレール を内蔵

主な機能 (Key Features)

  • Automated Markdown Workflows
    • 複雑なYAMLの代わりにMarkdownで自動化を作成
    • 自然言語ベースの命令をGitHub Actionsワークフローへ変換
  • AI-Powered Decision Making
    • ワークフローが 文脈を理解し、状況に適応
    • AIがコードとリポジトリの状態を分析し、適切な措置を実行
  • GitHub Integration
    • Actions, Issues, PRs, Discussions などと深く統合
    • リポジトリ管理全般を自動化
  • Safety First
    • サンドボックス実行最小権限の原則安全な出力処理 によりセキュリティを強化
  • Multiple AI Engines
    • Copilot, Claude, Codex およびユーザー定義AIプロセッサーをサポート
  • Continuous AI
    • 継続的AI適用 (Continuous AI) により、コラボレーションとコード品質を自動改善

Guardrails Built-In

  • ワークフローはデフォルトで 読み取り専用権限 で実行
  • 書き込み操作は 事前承認済みの安全な出力 (safe outputs) を通じてのみ許可
  • サンドボックス実行、ツールホワイトリスト、ネットワーク分離 により、AIエージェントの動作範囲を制御

例: Daily Issues Report

  • 自動化作成手順
    • Write: 自然言語で書かれた .md ファイルを作成
    • Compile: gh aw compile コマンドで .lock.yml 形式のGitHub Actionsワークフローへ変換
    • Run: トリガーに応じて GitHub Actions が自動実行
  • AIエージェントはリポジトリコンテキストを読み取り、Issue分析、可視化生成、レポート作成 を実行
  • すべてのプロセスは コンテナ環境 で実行され、安全性と再現性を確保

Gallery

  • Issue & PR Management: 自動分類、ラベリング、プロジェクト調整
  • Continuous Documentation: ドキュメント保守と一貫性の確保
  • Continuous Improvement: コード簡素化、リファクタリング、スタイル改善
  • Metrics & Analytics: 日次レポート、トレンド分析、ワークフロー状態監視
  • Quality & Testing: CI失敗診断、テスト改善、品質チェック
  • Multi-Repository: 複数リポジトリ間の機能同期と追跡
  • Continuous Refactoring: スラッシュコマンドによる分析と自動化
  • Continuous Scanning & Compliance: セキュリティスキャン、警告分類、コンプライアンス監視
  • Scheduled Workflows: 日次運用、研究、自動保守タスク

CLIで始める (Getting Started)

  • 拡張機能のインストール後、サンプルワークフローの追加と初回実行を コマンドラインから数分で実行可能
  • gh extension install github/gh-aw でインストール
  • 自分のRepoで gh aw add-wizard githubnext/agentics/daily-repo-status を追加すると、対話形式でインストールされ自動実行される

Webでワークフローを作成 (Creating Workflows)

  • GitHub Webインターフェースの "Agents" タブから 自然言語で直接カスタムAgentic Workflowを作成可能

1件のコメント

 
GN⁺ 2026-02-10
Hacker Newsのコメント
  • go.mod 内の奇妙な replace 構文を見て気になった
    通常は go get github.com/Masterminds/semver/v3@v3.4.0 を使うが、このPR(リンク)では Copilotエージェント が誤った形で replace を追加していた
    Dependabotが不要なバージョンアップのIssueを作り、Copilotがそれを処理しながら見当違いの修正まで含めてしまったようだ
    レビュアーが奇妙な点を指摘したが、結局は人間のレビュアーが見落としてマージされたように見える。いろいろな意味でまずい事例だ

    • 自分が使ったすべてのエージェントが、npmのpackage.jsonでも似た問題を起こしていた
      npm i foo の代わりに文字列編集でバージョンを**幻覚(hallucinate)**して入れてしまう
      コードのリネームもリファクタリングツールではなく文字列置換で処理するので、GPUの無駄遣いがひどい
    • これを直そうとする試みはあったが、途中で取り消されたようだ(リンク
    • 同じ replace が3回も積み重なった末に、最終的に PR 14543 で修正された
      だがその後に「unit test修正」コミットが2つ追加され、1つは Claude → Copilot への置き換え、もう1つはドキュメントのMarkdownを壊していた
      まるで エージェントワークフローの戦場 になってしまったようだ
    • パッケージアップグレードでは 正確なプロンプト設計 が本当に重要だ
      自分はGeminiとCodexでバージョン情報を確認し、Claude Opusのサブエージェントでコード変更の要否を点検している
      メジャーバージョンの場合は2つのパッケージをgit cloneしてインターフェース変更を比較し、最後にテストを回して検証する
      完璧ではないが、人間だって完璧ではないのだからそれでいい
    • この状況をGitHub Actionsの secure sleepコマンド を思い出した
  • GitHubにはまず中核機能をきちんと磨いてほしい
    以前GH Actions関連の Issue に遭遇して使うのをやめたが、1年たってもまだ同じ問題で人々が苦しんでいる

    • Gitea を強く勧める
      導入が簡単で、Microsoft LDAP/ADFSネットワークともうまく統合できる
      .gitea フォルダで定義したアクションを単純なワーカーが安定して実行する
      CIパイプラインを 完全自給自足型 にでき、UIもGitHubとほぼ同じだ
    • 無料ユーザーが増えるほどサポート負担が重くなる プレミアム転換のジレンマ がある
      結局のところ解決策は単純で、彼らの製品を 直接購入 することだ
    • 有料ユーザーとして、自分の金が中核機能の改善ではなく AI機能開発 に使われているのが不満だ
    • こうした動きは、企業がいまだに 成長株の幻想 を維持しようとしているように見える
    • Copilotを使っていないのに、GitHubのホームで「上限超過」メッセージが出続ける
      まるで課金を誘う 雑なトリック のように感じる
  • gh aw 拡張はMarkdownファイルを入力として 巨大なGitHub Actionsワークフロー を生成する
    gh aw init の実行中に誤ったプロンプトでYを押したところ、自分のアカウントトークンで COPILOT_GITHUB_TOKEN が作成された
    こういうものには追加の確認手順が必須だ

    • 今では ローカルトークンの使用は削除 され、追加の確認手順も導入されたらしい
  • 公式リンクは github.com/github/gh-aw
    GitHub Pagesで別ドメインもなく公開されていた理由が気になった

    • GitHub Pagesはアカウント名ベースで ORGNAME.github.io ドメインを提供する
      つまり github.github.io はGitHub公式アカウントが公開したものだ
    • GitHubが自社製品を自社ドメインで使うのは dogfooding の一種だと思う
    • 他人がこのリンクを取得することはできないので フィッシングの危険はない
    • 最近 githubnext 組織から github 組織に移されたそうだ
      github.github.io はGitHub組織のデフォルトのPagesドメインだ
    • 現在は github.github.com/gh-aw へのリダイレクトに修正されている
  • 週末ずっと エージェントベースのCIワークフロー を構築していた
    CCインスタンスが隔離されたVMで権限制限モードのまま作業し、CIが通ると自動でPRを作成する
    今は1人のClaudeが複数のClaudeを管理する構成を試している

    • コストがどれくらいかかるのか気になる、という質問があった
    • 「狂った時代だ」という反応もあった
  • GitHubは既存システムを改善するより エージェントを無理やりねじ込んでいる ように見える
    マーケティング主導の 現金回収戦略 のようだ

    • それでも、CI・Issue・ソースコードにアクセスできる 中央集権的プロバイダ としてエージェントを置くのは合理的かもしれない
    • AnthropicのClaudeはGitHubとうまく統合されているので、GitHub独自のエージェントは 不要に感じられる
      ひょっとするとClaudeを使いにくくして自社エージェントを強制しようとしているのでは、と疑ってしまう
  • 「セキュリティ中心設計原則」を掲げるGitHub Actionsが いちばん信頼できない

    • 実際ページの最後の一文も「注意して、自己責任で使ってほしい」だ
  • MicrosoftとGitHubのアプローチには共感する
    コードの価値はそれ自体より 組織の知識が埋め込まれた形 にある
    だから 継続的かつ自動的な改善の流れ が重要だ
    急激なリファクタリングは組織の メンタルモデル を壊すので、小さな改善の積み重ねが理想的だ
    決定論的なシステムが問題を検知し、LLMが必要な部分だけを修正する構造が望ましい

    • プロジェクトの 不変条件(invariants) を定義してエージェントに渡すためのよい抽象化が、まだ不足している
      自分はDeep Wiki風に細かな指針を作らなければならず面倒だ
      C4ダイアグラムのように構造を可視化してくれるツールが必要だ
    • DataOpsパターン のようにアルゴリズム段階とエージェント段階を混ぜるアプローチが有用だ
      関連文書: DataOpsパターン
  • 最近はどのクラウド製品も 中核機能は停滞し、周辺機能ばかり増えている
    組織が大きくなるにつれて開発者は新機能を作らなければならず、こうした現象が起きる
    終わりなき成長追求 をやめない限り、製品はこれからも enshittification していくだろう

  • ランディングページを見ても、このワークフローがユーザーにどんな 実質的価値 をもたらすのか明確ではない
    例や具体的なユースケースが不足している

    • ギャラリーセクション に実例がある
      たとえば Issue管理ワークフロー は、PRとIssueを自動管理する事例を示している
      核となる価値は ヒューリスティックでは処理できない反復作業を委任すること
      まだストーリーテリングを磨いている最中とのことだ