ハクソク

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

GitHub Copilot コーディングエージェント

371日前原文(github.blog)

概要

  • Backlog や 技術的負債 の解消をGitHub Copilot coding agentに委任可能
  • 複数の課題 を一括でCopilotに割り当てて自動対応できる
  • Copilotは テストやリンターで検証 し、完了後にレビュー依頼を通知
  • Copilot Pro+ および Copilot Enterprise 利用者向けに提供開始
  • モバイルやCLIにも順次対応拡大、利用にはGitHub Actions分のリソース消費

GitHub Copilot coding agentで技術的負債を効率的に解消

  • Backlog や 技術的負債 が溜まった場合、Copilot coding agentへ課題を割り当てることで効率的に対応することが可能 提案
  • Copilotは 開発者と同じように GitHub.com、GitHub Mobile、GitHub CLIから課題を割り当てることができる 割り当て方法の確認

Copilot coding agentの動作概要

  • Copilotは 独自の安全なクラウド開発環境 （GitHub Actions利用）で動作する 環境構築
  • リポジトリを探索し、 コード変更・テスト・リンター検証 を自動で実施する 自動化
  • 完了後は 担当者にタグ付け してレビュー依頼を通知する 通知方法の確認
  • Pull RequestのコメントでCopilotに 追加修正を依頼 することも可能 フィードバック方法
  • ローカルでブランチをチェックアウトし、 IDEで作業継続 もできる 柔軟な運用

対応可能なタスクと活用例

  • Copilotは 低～中程度の複雑度 の課題に最適 適用範囲の明確化
    • 新機能追加
    • バグ修正
    • テスト拡充
    • リファクタリング
    • ドキュメント改善
  • 複数の課題を同時に割り当てる ことができる 並列処理の実現

利用条件と注意点

  • Copilot Pro+ および Copilot Enterprise のサブスクライバーが利用可能 利用資格の確認
  • Copilot Enterpriseの場合、 管理者によるポリシー有効化 が必要 ポリシー設定
  • 利用時は GitHub Actionsの分単位リソース および Copilotプレミアムリクエスト が消費される リソース管理
  • 2025年5月19日以降、 GitHub Mobile（iOS/Android）とCLI にも順次展開 サポート拡大
  • 2025年6月4日以降、 モデルリクエストごとに1プレミアムリクエスト消費 コスト管理

利用開始・情報収集

  • Copilot coding agent documentation で導入方法や活用Tipsを確認すること ドキュメント参照
  • プレビュー機能 のため、UIや仕様は今後変更される可能性がある 仕様変更への注意
  • フィードバックや質問は ディスカッションに参加 して意見共有すること コミュニケーション推進

まとめ

  • Copilot coding agentを活用し、 反復的・定型的な作業 を自動化することで、開発者は 創造的かつ高付加価値な業務 に集中できる 生産性向上

Hackerたちの意見

Copilotは低から中程度の複雑さのタスクが得意なんだ Oh cool! > よくテストされたコードベースでね Oh ok、気にしないで

└

すべてのテストを自動で書かせれば、しっかりテストされたコードベースができるよ。

└

自分の経験では、良いテストがなくても、少なくともグリーンフィールドプロジェクトではうまくいくよ。アップデートやパッチを作るときにすでにテストがあれば、さらに良い感じになる。

└

他のコメントでも指摘されているように、コーディングエージェントは必要なときにテストカバレッジを改善するのが得意です。でも、もう少し深い観察として、エージェント系のコーディングツールは良いテストカバレッジから大きな恩恵を受けるんですよ。テストはエージェントを「囲い込む」方法で、定期的に自分の作業をチェックできるようにします。これらのツールが機能するためにテストが必須ではありませんが、コーディングエージェントがあなたの代わりにもっと多くのことを達成するのを可能にします。（私はCopilotコーディングエージェントに関わっています）

俺の友達がGHで隣のプロジェクトに取り組んでて、ここ数日ずっとこれについて話してるんだ。月曜日の基調講演を「絶対見ておけ」って、もう8回くらい言われた気がする。3回目の認証タイムアウトの後、ストリームを見るのを諦めちゃったけど、これがそうだって知ってたら4回目に挑戦してたかも。

└

プロジェクトのラインコーダーの意見を聞くのはいつもためらっちゃうんだよね、毎日内部の盛り上がりをたっぷり受けてるから。これがカーソルを超えてほしいな。絶対見るつもりだよ。

└

具体的にどの基調講演のことを言ってるの？気になるけど、今のところ検索しても見つからないんだ。

└

アドバイス：YouTubeに行って、MSの登録料をスキップしちゃいなよ。

グリーンフィールドプロジェクトでちょっと雰囲気コーディングを試してみたんだけど（gemini 2.5 pro + clineを使って）。一方では、めっちゃ印象的で、生産性が大幅に向上する（統合されてないLLMチャットインターフェースと比べても）。LLMはアーキテクチャを導くのにかなり強い手が必要だって気づいたよ、そうしないとアーキテクチャの技術的負債が増えちゃう。簡単な例として、抽象化を壊すことがあるのに気づいた（物を適切でない場所に置く）。残念ながら、コードの質やより良い方法があるかどうかについては、あんまり自己反省がないみたい。もちろん、何かが間違った場所にあるって気づいて、より良い指示を出せば、すぐに反応してくれるけどね。結局、一晩で$15分のLLMトークンを使い切っちゃった。（以前は、コーディングタスクを含む重度のLLMユーザーとして、月平均$20くらいだった。）

└

LLMはアーキテクチャを導くのにかなり強い手が必要だって もしかして次のフェーズは、実装がアーキテクチャ定義に合ってるかチェックする（AI駆動の？）「リンター」の台頭かな。

└

結局、一晩で$15分のLLMトークンを使い切っちゃった。これはバグじゃなくて機能だよ。LLMは次の「OMG、俺のAWS請求書」現象になるだろうね。

└

Clineを使いたいなら、価格に敏感な人は手動でコンテキスト管理をしなきゃいけないよね。俺はそれが面倒くさくて、Windsurf（今はGemini 2.5 pro使ってる）を使ってる。

└

一晩で$15のLLMトークンを使い切っちゃった。Aiderを使って、コンテキストを積極的に管理するのを考えてみて（/add、/drop、/clearを使って）。https://aider.chat/

└

グリーンフィールドプロジェクトでは注目されてるけど、スタックをブートストラップするのにはかなり失敗が多い気がする。例えば、Gemini 2.5はSQLAlchemyやPytest、Python-playwrightなどのライブラリを組み合わせるときに、新しいエコシステム（Fastapiとか）で本当に苦労してる。自分でブートストラップする方が価値があると思ってるし、効果的な安全ハーネスが整ったら、その後でボイラープレートを手伝ってもらうのがいいかな。

└

グリーンフィールドプロジェクトでAIを使うのは大嫌いです。可能なパスが多すぎて、アプローチがランダムに切り替わるように見えます。ブラウンフィールドのコードベースでは、パターンマッチ用の参照ファイルを提供することができるので、他のコードベースに基づいて自分を固定できると、素晴らしい結果を得るのがずっと簡単です。

└

夜に15ドルというのは、高給取りのソフトウェアエンジニアのコストを考えると素晴らしいお得感ですね。

└

よく分からないんだけど？月額固定のサブスクリプションじゃないの？

└

小さなプロジェクトでClaude Codeを使って vibe コーディングしたこともあるよ。会社の訪問者登録についてのシンプルなプロジェクトで、フォームが一つ、チェックボックスがいくつか、すべてsqliteに保存されていて、.xlsxを取得するためのエンドポイントもある。最初のコストは約20ドルだったけど、後で（主に仕上げで）40ドルに増えた。シンプルなスタックを意図的に選んだ: html+js+php。いくつかのこと: * プロダクトの観点から結果には満足してる * コードベースはもっと良くできたかもしれないけど、今回はあまり気にしてない * デフォルトでは、AIはセキュリティを気にしない、特に言わない限り * Claudeは古いライブラリを使いたがった。最新のものを使うように言ったら、アップグレードはしたけど、古いバージョンでしか動かないコードを残した。さらに、最新のDaisyUIを古いバージョンのtailwindcssと混ぜちゃった :) 一方ではすごく簡単で楽しかったけど、もし俺がジュニアエンジニアだったら、もっとコストがかかっただろうな。

└

たぶん、アーキテクチャに対してエンドツーエンドでトレーニングされてないからだと思う。視野が短すぎて、良いデザインについて私たちが学ぶ教訓を学ぶためのコンテキストの長さが足りてないんだよね。

Copilotは低から中程度の複雑さのタスクが得意なんだ、よくテストされたコードベースで、機能追加やバグ修正、テストの拡張、リファクタリング、ドキュメントの改善まで。境界、境界、境界、境界。人間にとって重要なのはAIのための境界を維持することみたいだね。もし君のよくテストされたコードベースがAIを通じてテストが作られてるなら、多分うまくいかないだろうね。内部での使い方について数字を共有できないっていうのは、ちょっと示唆的だと思う。マイクロソフトが、日々これを使って成功してるって知りたいな。そこには本物のものがあって、俺の頭はそのトリリオンドルの盛り上がりと有用性を分けるのがすごく難しいんだ。

└

最近、MSのコードの20～30%が何らかの形で生成されてるっていう引用を見た気がする。どっちにしても、プログラミングにおけるAIのベストな使い方は、開発者の力を倍増させることだと思う。AIが人間の創造性や主体性、批判的思考能力を損なわないことが、AIと人類の両方にとって最善だよね。AIはタスク指向であるべきだけど、高度な意思決定や計画は常に人間の仕事であるべきだと思う。だから、プログラミングにおけるAIの使い方は、長期的には人間主導であるべきだと思う。最終的には、利益のために機能を生み出すのではなく、人間の能力を豊かにすることに使われるべきだけど、もちろん限界はあるよね。

└

GitHub内で、そしてMicrosoft全体で、約3ヶ月間Copilotコーディングエージェントを使ってきました。この「ドッグフーディング」はすごく価値があって、たくさんの貴重なフィードバック（バグ潰しも！）があったおかげで、今日のローンチに向けてエージェントを準備するのに役立ちました。今のところ、約400人のGitHub社員が300以上のリポジトリでエージェントを使っていて、Copilotが貢献したプルリクエストはほぼ1,000件マージされています。エージェントを作っているリポジトリでは、実際にエージェント自身が5番目の貢献者になっているので、ほんとにCopilotコーディングエージェントを使ってCopilotコーディングエージェントを作ってるって感じです ;) （出典：私はGitHubでCopilotコーディングエージェントのプロダクトリードです。）

└

Microsoftの同僚と話していると、これは開発者主導ではなく、非常にマネジメント主導のプッシュだと感じます。Azureチームの友人には、内部のAIコーディングアシスタントをインストールすることを拒否したために、PIPにかけられそうになったチームメンバーがいました。すべてのマネージャーは「AIを使っている開発者の数」をOKRに設定していますが、実際にはほとんどの開発者がAIアシスタントをインストールしているものの、使っていなかったり、たまにしか使っていないという話をよく聞きます。C#やPowerShellではかなりひどいらしく、MSでの有用性が制限されています。

└

マイクロソフト、ドッグフーディングで有名な会社 これは15年前くらいまでは本当だったけど、今はそうじゃないね。

└

彼らは数字を発表したけど、それがこの特定の製品のものかどうかは分からない。どうやらAIが「30%」のコードを生成してるらしい。 https://techcrunch.com/2025/04/29/microsoft-ceo-says-up-to-3...

└

今のミスや失敗の真の統計がどうであれ、これが最悪の状態だってことを忘れないで。特に今の投資レベルを考えると、急速に良くなっていくのを止める明確な上限は見当たらないよ。

└

「マイクロソフトが、犬の餌を自分たちで食べることで有名な会社が、これを日々使って成功していることを知りたい。」彼らは最近、従業員を削減して、AI関連の人たちも解雇したから、あまり成功してないんじゃないかな。

└

「マイクロソフトが、犬の餌を自分たちで食べることで有名な会社が、これを日々使って成功していることを知りたい。」ここ数年、彼らの「有名な」犬の餌を使って、Teamsっていうクソみたいなツールを試したことあるの？それが彼らの「有名な」犬の餌の成果なら、コパイロットがどんなものになるのか、想像するだけで恐ろしいわ。

もっと遅くなるようなクソみたいなものを追加する前に、最適化してほしい。コパイロットで速いのはオートコンプリートだけで、モデルに関係なく100行のファイルを編集するのに数分かかることもある（モデルによって速いのもあるけど）。もしこれらのモデルがほぼ100%のヒット率を持っていればまあまあ良いけど、こんなに時間がかかるものを行ったり来たりするのは生産的じゃない。新しいタブでclaude/chatgptを開いて質問とコードを貼り付けて戻す方が、彼らのask/edit/agentツールを使うよりも速いよ。先週コパイロットのサブスクリプションをキャンセルしたし、2週間後に期限が切れたら、オートコンプリートや簡単なことにはローカルモデルに移行するつもり。

└

私の経験はほとんど逆で、数百行のファイルの変更は通常数秒しかかかりません。ただ、数ヶ月前にはあなたが言ったような遅いエージェントの編集時間を経験したことがあります。ボトルネックがどこにあったのかはわかりませんが、それ以来戻ってきていません。今は図書館のWiFiで「雰囲気コーディング」（この言葉はあまり好きじゃないけど）をしながら、Copilotを使って顧客のための新しいツールを作っていて、サクサク動いています。

└

数分？何かが深刻におかしいです。ほとんどのモデルでは、数秒で済むはずです。

└

俺もこれ経験したことあるよ、特に最後の最後で詰まって、結局終わらないっていうのが。使用量に基づく請求が始まったら、またカーソルを試してみようと思ってる。どんなローカルモデル使ってるの？オートコンプリート用に試したローカルモデルは使い物にならなかったけど、エイダーのベンチマークに基づいて、チャット用の大きなモデルは試してないんだ。できることならローカルオンリーにしたいな。

かなり遊んでみました。印象的でありながらも怖いです。最も重要なのは、無作為な小さなリポジトリから依存関係を無差別に使う傾向があり、大きなプロジェクトには正しいものではないことが多いです。購入者は注意が必要です。

└

プライベートリポジトリでPRがより信頼されたコンテキストでアクションを実行することを考えると、ちょっと心配だね。

└

これ、俺もいろんなAIで気づいたことなんだけど、ウェブから読み取ったデータを不釣り合いに信じてる感じがする。例えば、明らかにフィッシングページが詐欺かどうかをチェックしてって頼んだら、何度も内容の要約だけ返ってきて、まるでそれが権威ある情報みたいだった。2つ星のランダムな中国のリポジトリが業界標準の解決策として紹介されたこともあったし、READMEにそう書いてあったからね。余談だけど、暗号化に「Strobe」プロトコルを使うことを勧められて、https://strobe.cool に飛ばされたんだけど、そのページは幻覚を見させることについての内容だから皮肉だよね。

└

これを指摘してくれてありがとう！テスト中に見たことのない挙動だし、何が起こっているのかもっと掘り下げてみたい。メールを送ってもらえる？俺のアドレスはHNのログイン名 @github.com だよ。（俺はCopilotコーディングエージェントのプロダクトチームで働いてる。）

└

じゃあ、典型的なジュニア開発者って感じだね。

大きな詐欺警報、これを使うとプライベートリポジトリで君のコードをトレーニングしてるよ。彼らが「Pro」や「Pro+」を宣伝してるのに、FAQにはこう書いてあるからね。 > GitHubはCopilot BusinessやEnterpriseのデータを使ってGitHubのモデルをトレーニングしてるの？ > いいえ。GitHubはCopilot BusinessやEnterpriseのデータを使ってモデルをトレーニングしていません。つまり、有料プランの人たちも脳を奪われてるってことだ。

└

そうだったかもしれないけど、今は違うね： https://docs.github.com/en/copilot/managing-copilot/managing...

└

Windowsでプログラミングしてるなら、画面は数秒ごとにスクリーンショットされてるってことだよ。OCRが画面上の文字に似たものを全部分析してないと思ってるなら、君にビッグニュースがあるよ。

ここ数日、GitHubに保存されたコードを書くのを手伝ってもらうためにCopilotを使ってみたけど、全然役に立たなかった。2回のやり取り以上にコンテキストを維持できなかったんだ。Copilot: これがそのためのCコードだよ。俺: それを$OTHER_LANGUAGEに変換して。Copilot: どのコードを変換してほしいの？俺: お前がさっき生成したコードだよ。Copilot: ファイルをアップロードするか、コードへのリンクを共有してくれれば、翻訳を手伝えるよ… 俺がコーディングしてる目標（“真北”）からは最低でも15度はズレた方向を指示されることが多くて、だいたい90度近くズレてる。コードを頼むと、API呼び出しの半分以上を幻覚で作り出すんだ。

└

もっと計画的にやれ、魔法じゃないんだから: https://taoofmac.com/space/blog/2025/05/13/2230

└

いつも最初はGrokで詳細を詰めるところから始めるよ。やりたいことを伝えて、タスクを達成するためのいろんな方法についてアドバイスを求めるんだ。だいたい何度かやり取りして、Grokが自分の意図をしっかり理解したと思ったら、その時点でCursor用の初期プロンプトを生成してもらう。必要に応じてプロンプトを洗練させてもらってから、Cursorにコピーするんだ。これで時間を大幅に節約できるし、Cursorの会話からゴミを排除できる。不要なものや関係のないものが会話に入ると、たとえそれがLLMの出力から来たものであっても、モデルがそれを完全に手放すのが難しいことがあるって気づいたよ。

「Copilotは低から中程度の複雑さのタスクに優れている」って言うけど、俺たちの中程度の複雑さのタスクの解釈は全然違うね。

└

トレーニングセットの中の中程度の複雑さのタスク*