GitHub Universe 2025レポート 3

GitHub Universe 2025からCOOとCopilot担当のVPのインタビューを紹介

GitHub Universe 2025からCOOとCopilot担当のVPのインタビューを紹介

松下 康之 - Yasuyuki Matsushita

6:00

GitHub Universe 2025から、GitHubのCOOであり今回のカンファレンスの顔という役割を担当したKyle Daigle氏と、MicrosoftのVP of Software EngineeringとしてCopilotの開発を統括するLuke Hoban氏のインタビューをお届けする。

最初に紹介するのはLuke Hoban氏だ。Hoban氏はVisual StudioのデベロッパーとしてMicrosoftに入社し、約12年のキャリアを積んだ。その後AWSではProduct Manager、PlumiではCTOとして仕事をした後に、Microsoftに戻ってきたという経歴を持っている。戻ってきたタイミングが2024年12月ということで、復帰してから約1年間をCopilotの開発に専念してきたということになる。

自己紹介をお願いします。

Hoban:私はMicrosoftでCopilotのエンジニアリングチームを率いています。キャリアの最初の仕事としてMicrosoftのDeveloper Divisionでデベロッパーとして仕事を始めました。その後、AWSやPlumiといった会社で仕事をした後に、もう一度Microsoftに帰ってきたという感じですね。

MicrosoftのVP of Software EngineeringのLuke Hoban氏

MicrosoftのVP of Software EngineeringのLuke Hoban氏

今回はAgent HQが大きなトピックとして提示されていましたが、コーディングアシスタントという観点で言えば、これまでのChatGPTに固定されていたCopilotが他のモデルも選択できるようになったというのが地味ではありますが、大きな訴求ポイントだった気がします。これはそういう理解で正しいですか?

Hoban:そうですね。OpenAIのGPT系のモデルだけではなく、GoogleのGeminiやAnthropicのClaudeなどのモデルも使えるようになりました。これはあくまでもデベロッパーに選択肢を与えるという意味でやっていることですが、単にモデルだけではなくAzureのインフラストラクチャーを操作するツールやデータベース、メッセージングなどにも拡がっています。これはあくまでもデベロッパーのSoftware Development Life Cycleのエコシステムを拡げることが、デベロッパーにためになるという考えから実施していることです。

昨年のGitHub UniverseではIDEとしてVisual Studio CodeだけではなくJetBrainsのIDEへの対応も大きく訴求していたと思いますが、今回はそれが一切ありませんでした。やはりMicrosoftとの融合が進んでいることが原因ですか?

Hoban:JetBrainsへの対応も進めていますよ。それもあくまでもデベロッパーへの選択肢を拡げるという発想です。今回は発表することが多かったので漏れてしまったということだと思います。

選択肢を与えるというのは良いことではあると思いますが、実際には進化のスピードが速い生成AIに関して自分たちが必要な機能を誰が持っているのか、もしくは近い将来出てくるのかをデベロッパーが判断するのは非常に難しいと思います。GitHubから「こういう使い方にはこのモデルが最適です」というガイダンスを作ろうという発想はないんでしょうか?

Hoban:すでにモデルの大雑把な特性を示したドキュメントは公開されていますが、それ以上のより詳しい情報が欲しい、ということですよね。それについてはユーザーからのニーズは確認しているので、どうやったら最適な情報を適切なタイミングで届けられるかを検討したいと思います。

注:Hoban氏のドキュメントは以下のURLから参照できる。ここでは各モデルについて非常に短い単語で解説をしているが、これだけでやりたいことを実現できるか? を想定するのは不可能だろう。GitHubは「いろいろなモデルを使えるようにしたので各自で試して欲しい」という意図があると思われる。確かにミドルウェアやデータベースの選択についてと同様に「絶対に必要な機能」と「あれば良い機能」「今はないが何かと組み合わせれば実現できる機能」などのように、デベロッパー側が要求仕様に順位を付けて選択を行うのはデベロッパーの仕事だろう。しかし生成AIのモデルはモデル自体が改善されるスピード(リリースケイデンス)が速いことから、どの時点で開発するシステムに組み込むのか? という微妙な判断を短時間で行う必要がある。これは従来のシステムとは違う困難さであると言える。

●参考:https://github.blog/ai-and-ml/github-copilot/under-the-hood-exploring-the-ai-models-powering-github-copilot/

Copilotがコーディングアシスタントから出発してプルリクエストの書き方やテスト、レビューの書き方なども支援するようになり、MicrosoftのSRE Agentのようにシステム運用にも使えるようなレベルまでになりました。しかし相変わらずペアプログラミングの相手、つまり一人のエンジニアと対話して助けるというレベルに留まっています。もっとチーム全体を包括的にサポートすることでプロジェクトの進行を助けるような機能があると良いと思うのですが、それについては?

Hoban:GitHubはデベロッパーの仕事、つまりSoftware Development Life Cycleを支援するというのが発想です。そのために他のツールとの連携も必要ですし、ガバナンスの機能も必要だと思っています。これまでのデベロッパーとCopilotというペアプログラミングの仕事から少し管理職が行うような仕事、ダッシュボードはそれに近い機能ですが、そこまで拡張しているのを認識してもらえると良いかなと思います。

次はGitHubのCOOであるKyle Daigle氏のインタビューだ。

これまでGitHubはコーディングアシスタントによって誰もがデベロッパーになれると訴えてきました。ではジュニアなデベロッパーがシニアなデベロッパーになるというこれまでの過程がCopilotによってどう変わるのか? を教えてください。

Daigle:これまでのソフトウェアエンジニアであれば、最初に本などを通じてOSを学び実際に触ってみて理解を深める、その後にアプリケーションに移行して開発をするというボトムアップの教育方法だったわけです。それがCopilotを使うようになると「やりたいことは何かを整理してAIに伝えるとAIが動くアプリケーションを作ってくれる」というトップダウンのやり方で経験を積むということになるわけです。しかし実際にはトップダウンであってもアプリケーションの下に何があるのかを知りたいということは当然起こりますし、その時にでもCopilotはアシスタントとしてちゃんと説明を行ってくれます。

出発点が違えどもシステム全体を学ぶということは変わらないと言うことですね。

Daigle:例えば私は家の中の配線を変えたいとしてケーブルを引いたりコンセントを繋げたりする程度はやるかもしれませんが、間違っても配電盤の中に手を入れようとは思いません。間違えればケガをするし、最悪死んでしまうこともありますから。だからそういう部分が残っている、そこは専門家に頼むという切り分けができるようになるというのは、エンジニアとしてシニアになったということかもしれません。

個人的にAgent HQという命名は凄く良いなと感じています。つまりさまざまな仕事をするエージェントが集まって非同期的に仕事を成し遂げる、つまり専門家(Subject Matter Expert)が一緒に働いて仕事を達成する、その専門家が集まって仕事をする場所が本部(HQ)と呼ばれているという理解です。

Daigle:それは良い例えだね。ちゃんとこれを録音しておいてくれてるかな?(笑)。

どんな質問にもちゃんと対応するKyle Daigle氏

どんな質問にもちゃんと対応するKyle Daigle氏

2日目のキーノートでレトロなおもちゃであるファービーをPythonのコードで書き直して操作するというデモがありました。アレも単に新しいアプリケーションにCopilotを使ってコード生成させるというよりも、古いコードを学習させて「これをPythonで書き直して」という命令を与えてモダナイズするということを暗示していると思います。つまり既存のシステムを新しいプラットフォームに載せたいような場合には参考になるデモだったかなと。

Daigle:実際にMicrosoftにすれば、CやC++のレガシーなコードを書き直すという人間にとっては面倒な作業を、AIを使ってやらせるというのは良いアプローチだと思う。Microsoftにはそういうコードが大量にあるのは社内の人は良く知っているので(笑)。

今回のキーノート、初日の最後でMicrosoftのSatya Nadella氏が登壇しましたが、これは2023年からの2回目ということですよね? 最初の時は参加者も驚いていましたし、GitHubとMicrosoftのシナジーがこれから出てくるという興奮感がありました。でも今年の場合は「あぁ、出てくると思った」のような反応で少しインパクトが弱かったかなと思います。本当にCopilot、つまり生成AIをソフトウェア開発に使うという意味でインパクトを求めるなら、来年はLinus Torvalds氏を招いて「カーネルデベロップメントの面倒くさい部分をCopilotにやらせてます」って語らせたら、オープンソースコミュニティには凄まじいインパクトがあると思うので、ぜひ、来年は呼んでください。個人的に今回のステージ上で再生された動画にESLintの作者が登場したことが非常に驚きを感じたんですが、もしもLinusが来たらそれどころじゃない衝撃になると思います。それ以外にはCopilotでシンプルなゲームを作るというデモが何回か行われていましたが、もっとプロフェッショナルなゲームデベロッパー、例えば任天堂のエンジニアが出てきて、マッシブなトラフィックを処理するオンラインゲームの開発にCopilotを使ってますみたいなのがあると強力なサポーターになるんじゃないかなと思いますので、来年はぜひ、そのどっちかを実現してください。

Daigle:どちらもインパクトのある人選だと私も思うので参考にします。

Daigle氏とはこのインタビューの後に通路で立ち話をしているところを捕まえて、もう一つだけ、以下の質問をしてみた。それは「Spec Kitのconstitution.mdファイルでプロジェクトのルールを決めるというデモを見た時に、このままAIがプロジェクトのアシスタントとして使われるなら、YAMLファイルでシステム構成を定義したり、変更したりという方法から、マークダウンでAIに整理した情報を与えるというのがメインになるのでは? つまりYAML依存がなくなる時代が来ると思うか?」というものだ。それに対しては「すぐにはそうはならないだろう。しかし生成AIの利用が拡がればそういう使われ方も拡がるだろう」と常識的な回答を返してきた。

エンジニアと立ち話中でも対応してくれる親切なCOO、Kyle Daigle氏

エンジニアと立ち話中でも対応してくれる親切なCOO、Kyle Daigle氏

ちなみにTaylor Swiftの大ファンであると去年のインタビューで語っていたDaigle氏に「2025年10月3日にリリースされた彼女の新譜の中ではどの曲が好き?」と質問を向けたところ「GitHub Universeの準備で忙しかったのでアルバムを聴くことを禁止していて、まだ聴いてないんだよ」という驚きの答えが返ってきた。今は「Life of a Showgirl」を十分に聴きこんでいることだろう。同じ質問は来年にとっておこう。

また去年のインタビューでは「GitHubのグッズとしてFriendship Braceletがあるといいんじゃない?」と提案をした記憶があるが、グッズとしては作られなかったが、自作コーナーであるRecess!のプログラムの中に「You belong with Mona」のブレスレットを作るプログラムが実施されており、好きな文字を組み込んだブレスレットを作る参加者でにぎわっていた。

Taylor Swiftの名曲、You belong with Meをもじったブレスレット作りのコーナー

Taylor Swiftの名曲、You belong with Meをもじったブレスレット作りのコーナー

満員ではなかったがそこそこ盛り上がっている。休憩として手を動かす作業をするのは良い選択だ

満員ではなかったがそこそこ盛り上がっている。休憩として手を動かす作業をするのは良い選択だ

この記事のキーワード

この記事をシェアしてください

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored