GitHub Copilot コーディングエージェント、パブリックプレビュー公開

 (github.blog)
11 ポイント 投稿者 GN⁺ 2025-05-20 | 2件のコメント | WhatsAppで共有
  • GitHub が Copilot コーディングエージェントを Copilot Pro+ および Enterprise ユーザー向けにプレビュー公開
  • 開発者が 反復的で技術的負債のたまりやすい作業 を Copilot に委任し、より創造的で重要な仕事に集中できるようにする
  • Issue を AI に割り当てる と、コード修正、テスト実行、PR 作成まで自動で実行
  • Copilot が作業を完了すると レビューを依頼 し、開発者は追加の変更をコメントで依頼したり、ブランチで直接作業を続けたりできる
  • 作業は GitHub Actions ベースの クラウド開発環境 で行われ、テストとリンター通過も自動で検証
  • ユーザーは PR 上のコメントで Copilot に 修正依頼 したり、ローカルブランチに取り込んで共同作業したりできる
  • 主に テストが十分に整備されたコードベースでの機能追加、バグ修正、リファクタリング など、中〜低難度の業務に強みを持つ

GitHub Copilot coding agent in public preview

コードエージェントで技術的負債を減らし、創造的な業務に集中可能

  • GitHub は Copilot コーディングエージェントを パブリックプレビュー として公開し、反復的または単純な Issue を Copilot に 委任 できるようにした
  • 開発者は通常の開発者に割り当てるのと同じように Issue を Copilot に割り当てることができ、GitHub の Web サイト、モバイルアプリ、CLI でサポートされる
  • Copilot は 独自のクラウド開発環境 でリポジトリを分析し、変更を適用し、テストと lint の検証まで行ったうえで PR を作成する
  • 完了後はユーザーにレビューを依頼し、PR 内のコメントでフィードバックを返したり、ローカルで直接ブランチを引き継いで作業したりすることもできる

どのような作業に適しているか

  • Copilot は 機能追加、バグ修正、テスト拡張、リファクタリング、ドキュメント改善 など、低〜中程度の複雑さの作業 に強みを持つ
  • テストが十分に整備されたコードベース で効果的に動作し、複数の Issue を同時に割り当てることも可能

利用条件と料金

  • この機能は Copilot Pro+ または Copilot Enterprise プランで利用可能
  • Enterprise の場合、管理者が「Copilot コーディングエージェント」ポリシーを 事前に有効化 する必要がある
  • エージェントの利用では GitHub Actions 時間 と Copilot Premium リクエスト を消費する
    • 特に、2025年6月4日からは モデルリクエスト1件ごとに Premium リクエスト1回 が課金される

プラットフォーム対応と開始方法

関連記事

2件のコメント

 
wedding 2025-05-20

VSCode Insiderで使っていますが、どんどん進化していてとても便利です。
最近は予測コーディングまでできるようになりました。
 
GN⁺ 2025-05-20
Hacker Newsの意見
  • Copilotは、十分にテストされたコードベースにおいて、機能追加、バグ修正、テスト拡張、リファクタリング、ドキュメント改善のような低〜中難度の作業に効果的だという印象がある。ただし、人間にとって重要なのは、AIを使う際に警戒を保つことだと思う。テストがAIだけで作られているなら、実際には正しく動かないのではないかという懸念がある。Microsoft内部でどれほど成功裏に使われているのか、具体的な数値を聞いてみたい。Microsoftは実際に自社製品を実運用する（ドッグフーディング）ことで有名だが、強力なマーケティングと本当の有用性を見分けるのはとても難しいと感じる
    • GitHubとMicrosoftの各所で、Copilot coding agentを社内で実際にほぼ3か月使っている。この経験を通じて多くのフィードバックとバグ修正が行われ、今日のエージェント公開の準備が整った。これまでに約400人のGitHub社員が300以上のリポジトリでagentを使い、Copilotが貢献したPRは1,000件近くマージされた。agentが開発されているリポジトリでは、Copilot agentは5番目に多く貢献しているコントリビューターだ。つまり、Copilot coding agentを使ってCopilot coding agentを作っているということになる。（私はCopilot coding agentのGitHub内プロダクトリードです）
    • Microsoft社内では、マネジメント主導の強制的な導入という印象を受ける。Azureチームの友人の話では、社内AIコーディングアシスタントのインストールを拒否したために、PIP（業績改善プログラム）に載せられそうになった事例がある。各マネージャーが「AIを使う開発者数」をOKRにしており、多くの開発者はインストールだけして実際にはほとんど使っていない傾向がある。特にC#とPowerShellのサポートがかなり不足しており、実用性が限られているのが残念だ
    • 実際、MicrosoftはAIでコードを生成した割合などの数値を公表したことがある。コードの30%がAIによって書かれているとされている
    • Microsoftがドッグフーディングで有名だったという話は15年前までは正しかったが、今はまったくそうではない
  • Copilotを使うと、プライベートリポジトリのコードが学習に使われる可能性がある点は非常に大きな問題だと警告したい。Pro、Pro+プランはあるが、FAQにはBusinessやEnterpriseのデータは学習に使わないとしか書かれていないため、個人向け有料プランのデータは依然としてモデル学習に使われるのだと受け取っている
    • 以前はそうだったかもしれないが、今は違う。GitHub公式ドキュメントで個人プランのポリシーを確認できる
    • Windows環境でコーディングしているなら、すでに画面は数秒ごとに自動キャプチャされており、OCRで画面上のすべての文字が解析されている。これを知らなければ驚きの話だろう
  • Gemini 2.5 proとclineで、グリーンフィールドプロジェクトでvibe codingの実験をしてみた。かなり印象的で、従来のLLMチャットインターフェースよりも生産性向上に大きく役立った。しかし、アーキテクチャガイドが十分に強くないと、LLMは誤った抽象化や技術的負債を積み上げる傾向がある（例: 構造破壊）。コード品質やより良い方法についての自己反省は十分ではない印象だ。ただ、こちらが明確に指摘してプロンプトすればすぐ改善する点は長所だ。そして、LLMのトークン費用が一晩で$15もかかったのには驚いた。普段は月平均で$20程度なのに、1日でここまで出たのは初めてだ
    • 1日にLLMトークンで$15使ったというのはバグではなく仕様だと思う。今後は「AWS料金爆弾」現象がLLMにも起きるだろう
    • Aiderというツールを使って、/add、/drop、/clearでコンテキストを積極的に管理してみるのもおすすめだ
    • Clineを料金重視で使うなら、コンテキストを手動で管理する必要があると感じる。私は代わりにWindsurf（引き続きGemini 2.5 proを使用）を使っている。コンテキスト管理がずっと簡単だ
    • グリーンフィールドプロジェクトではAI活用はやや扱いづらい。選択肢が多すぎて、AIが方針を行ったり来たりする。ブラウンフィールド（既存コードベース）では参照ファイルを与えて自然にパターン学習させられるので、はるかに簡単に良い結果を引き出せる
    • LLMのアーキテクチャ汚染防止に関心がある。次の段階として、実装が設計定義に合っているかを確認してくれる（AIベースの）リンターが登場することを期待している
  • 機能追加より速度最適化が先だと思う。Copilotのオートコンプリートは速いが、100行のファイル編集に数分かかることもあり、非生産的な体験に感じる。ほぼ100%に近い的中率があるなら理解できるが、遅い上に行ったり来たりするのはつらい。むしろ新しいタブでClaudeやChatGPTに質問してコードをコピペするほうが速い。Copilotは解約したし、今後は補完や簡単な作業にはローカルモデルに切り替えるつもりだ
    • 私の経験はまったく逆だ。数百行あるファイルの編集でも数秒で終わる。以前は遅かったようだが、最近はボトルネックがなくなった。図書館のWi‑FiでCopilotを使ってもかなり快適だ
    • 数分かかるなら深刻な問題だと思う。ほとんどのモデルは数秒で処理する
  • VS CodeでChatGPTとCopilotを交互に使っている。Objective-Cの文法把握がずっと楽になったし、ライブラリ対応は弱いが、3rd partyライブラリについては自分が十分試していない面もあると思う。文法やフローの誤りは一目で分かるので、少し直してほぼそのままコードを使っている。月$10でこれなら未来は明るいと感じる。更新しなければならないiOSアプリがとても多く、どれも生産性アプリで、自分で使って自分で売っている。だから利益は二重だ
  • Copilotをかなり使い込んだ。印象的だが、同時に怖くもある。大きな問題は、小さなリポジトリから持ってきたランダムな依存関係を無差別に勧め、その多くが主要プロジェクトには不適切だという点だ。つまり、利用者側の注意が必要だ
    • 複数のAIで似たパターンを見た。Webから読んだデータを過度に信頼している。たとえばフィッシング詐欺の検証を依頼すると、AIは内容の要約をするだけで、信頼できる分析にはならない。また、スター2個の無名の中国製リポジトリを業界標準のように勧めることもあった。READMEにそう書いてあるというだけの理由だ。関係ない話だが、「Strobe」暗号プロトコルを勧めて strobe.cool を案内されたこともあり、そのサイト自体が幻覚誘導を扱う場所だった
    • この現象について言及してくれてありがとう。テスト中にはこうした挙動を経験していないので、もう少し深く調べてみたい。もしメールで共有してもらえるならありがたい（github.comでの私のHNニックネーム）。私はCopilot coding agentのプロダクトチームで働いている
    • PR実行はプライベートリポジトリではより信頼性の高いコンテキストで動くが、そのような状況でも上記のような依存関係の推薦問題が起きるのは少し気がかりだ
  • 「Copilotは低〜中複雑度の作業に強い」という言葉には好印象を持った。しかし、「十分にテストされたコードベース」に限るという点で期待はしぼんだ
    • 他のコメントにもあるように、coding agentはテストカバレッジ改善に非常に優れている。さらに一歩踏み込むと、エージェント型コーディングツールは、すでに良いテストカバレッジがある場合により大きな効果を発揮する。テストはagentを制約し、自分の作業を検証し直す機会を与えてくれる。こうしたツールに必須ではないが、あればより良い成果が出る（私はCopilot coding agentチームで働いている）
    • Copilotにすべてのテストを書かせれば、すぐに十分テストされたコードベースができあがる
    • 私の経験では、テストがなくても、特にグリーンフィールドプロジェクトではかなりうまく動く。ただし、すでにテストがある場合の更新やパッチの効果のほうが明らかに高い
  • 「技術的負債に苦しんでいる？」という広告文句に対して、もう諦めて沈めばいいと冗談交じりに反応した。Github Copilot Coding Agentによって技術的負債がさらに増え、誰が責任を負うのか分からない新たな技術的負債が積み上がり、同僚たちもすぐ同じ状況に追いつくだろうと皮肉っている
  • 友人がGitHubでその関連プロジェクトに参加していて、ここ数日ずっとこの話ばかり聞かされていた。月曜のキーノートを絶対に見ろと何度も念押しされた。3回目の認証タイムアウトのあと配信を見るのをやめたが、この話題だと分かっていたらもう一度試したと思う
    • どのキーノートなのか具体的に気になる。今のところ検索してもあまり出てこない
    • 一つアドバイスすると、MSの会員登録手順を避けて、そのままYouTubeへ行くのがいい
    • 現場のコーダーの話は、社内マーケティングが強く入っているので、いつも慎重に聞くようにしている。Cursorのような競合を圧倒してくれることを期待しており、デモはぜひ見るつもりだ
  • LLM初期のころに、github actionsとissues workflowでagentを自作して使っていた。機能は限られていたが、バグを指定するだけで自動的に動作を実行し、アーキテクチャや編集タスクを処理し、変更を検証し、最後にPRを送っていた。今では公式ツールで似たことができるので期待している（私の作業サンプル: chota)