GitHub Universe 2025レポート 2

GitHub Universe 2025からMicrosoftが語る開発からSREまでのワークフローを紹介

GitHub Universe 2025にて、Microsoftが発表した開発からSREまでのワークフローを示したセッションを紹介する。

松下 康之 - Yasuyuki Matsushita

6:00

GitHub Universe 2025から、Microsoftのエンジニアによるセッションを紹介する。これは「Build apps & agents that scale with VS Code, GitHub Copilot, and Agent Framework」と題されたセッションで、Visual Studio Codeを使ってサンプルのアプリケーションを開発しながら、Azure上に実装し、トレーシングから運用の変更までを行うという一連の流れを解説した内容だ。プレゼンテーションとデモを行ったのはMicrosoftのAmanda Silver氏、Rong Lu氏、Shayne Boyer氏の3名で、入れ替わりながら解説とデモを行った。

セッションの動画は以下のURLから視聴できる。

●動画:Build apps & agents that scale with VS Code, GitHub Copilot, and Agent Framework

プレゼンテーションの進行役を務めたSilver氏

プレゼンテーションの進行役を務めたSilver氏

Silver氏はソフトウェア開発のワークフローにおいてAIが果たしてきた役割は3段階で進化してきたと説明。最初はAIがアシストをする段階、2番目はデベロッパーが質問をしてそれにAIが答える段階、そして3番目はデベロッパーとAIが一緒に働くという段階だ。

ここからデモとして、ペットを対象にしたマッチングアプリを題材にしてクラウドネイティブなソフトウェア開発におけるAIの役割を説明する内容に移った。デモを担当したのはShane Boyer氏だ。

デモではサンフランシスコでペットを連れていけるカフェとペットシッターを探すアプリを使用

デモではサンフランシスコでペットを連れていけるカフェとペットシッターを探すアプリを使用

ここからのデモではGitHub Spec Kitという仕様駆動型のフレームワークを使って開発を行うと説明し、デモを開始した。ここで注目したいのはプロジェクトの初期化に/constitutionというコマンドを使い、AIに与える詳細な仕様をマークダウン形式のドキュメントで入力させるという部分だろう。

Spec Kitを使ってアプリケーションを開発すると説明

Spec Kitを使ってアプリケーションを開発すると説明

このデモアプリはOctopetsと名付けられているが、Boyer氏のデモではセットアップを行い、アプリケーション開発のための段取りをクリアにするレベルで説明を終えた。AIモデルにプロンプトを渡して結果を受け取るという部分はSpec Kitが仕様駆動式ツールであることが強く効いているようだ。アプリケーション全体の約束とでも呼ばれる制限や守るべき要件は、constitution.mdというファイルにマークダウンの形式で書かれた英語によって定義する。

それ以外の機能の仕様はspec.md、タスクについてはtask.mdのようにアプリケーション開発の全体の定義から個々の機能の定義、開発のプランの定義、実装する際の定義まで「それぞれのステップでやるべきことを自然な英文で記述する」ことで、AIがそれに従ってコードやプランを生成するという形になっている。

筆者はAIに対する指示をYAMLファイルではなくマークダウンで書くことに軽く驚きを覚えたが、何よりもConstitution(日本語訳をすれば憲法)という強い用語を使ってAIモデルに具体的で分かりやすい指示を作るという発想に軽く衝撃を受けたことは認めざるを得ない。ソフトウェア開発という複雑なプロセスを分解しながら、仕様駆動型に寄せることで、生成AIに対して厳密にガードレールを設定して間違いを起こさせないための工夫なのだろう。

生成AIモデルに対する指令をマークダウンでプロセス、タスクごとにきめ細かく文章化

生成AIモデルに対する指令をマークダウンでプロセス、タスクごとにきめ細かく文章化

これらは少し前であればYAMLで宣言的に定義するという発想だったろうが、すでに生成AIモデルによって自然な言語で指示でき、やってはいけないこと、期待する結果、テストの範囲、利用するライブラリーやフレームワークなどを記述することで、人間への可読性をあげることができるという判断だろう。構造が整理され用語も統一された自然言語であれば、ベクター化データを生成するLLMには極めて扱いやすい入力データということになる。

research.mdでは使用するLLMの違いを調査するというタスクを割り当ててデモを行った

research.mdでは使用するLLMの違いを調査するというタスクを割り当ててデモを行った

このデモでは使用するLLMに対してコストや品質のバランス、そのモデルがGitHubの外のサービスやAzureのサービスとの連携の実績があるのか? などもチェックしているところが、単なる検索機能ではできないこととして解説されていた。

ここまでデモしてきた後にSpec Kitを再度、紹介

ここまでデモしてきた後にSpec Kitを再度、紹介

Spec Kitの情報は以下のGitHubページから参照されたい。

●参考:https://github.com/github/spec-kit/tree/main

ここまではCopilotを使ってWebアプリケーションを仕様駆動型で開発してきた。ここからは、このアプリ自体が使うAIエージェント機能の組み込みを行う段階となった。担当するのはRong Lu氏だ。

エージェンティックAIの機能をペットアプリに追加するデモを担当

エージェンティックAIの機能をペットアプリに追加するデモを担当

Lu氏はアプリケーションが備えるペットシッターを検索して条件にあったシッターを提示するという機能を、生成AIを使って実施するというゴールの次に、検索されたペットシッターとチャットで会話を行う機能を別機能として生成AIで作成するということを行っている。Copilotを使って足らないところは何か? それを実装するにはどうしたらいいのか? モデルは何が最適か? という対話をしながら、ソフトウェアに機能を追加する作業を一緒になって行っているところに新しさがあると言える。つまり一緒に考えながら指示を出すが、主導権は常に人間側が握っている、次にやるべきことはAIが提示するが、選択するのはデベロッパーであるという部分に、生成AIが人間の仕事を奪うのではなく生成AIと人間がお互いを助けながら開発を行うというスタイルが自然に見せられていたという現場となった。

ペットシッターのChat機能で「あなたが提示した予算だとペットシッターを見つけるのは難しいので予算を上げたらどう?」というやり取り

ペットシッターのChat機能で「あなたが提示した予算だとペットシッターを見つけるのは難しいので予算を上げたらどう?」というやり取り

このデモでは生成AIを組み込むことでアプリケーションの体験を改善できることを示した。単に検索結果のエラーを見せつけるのではなく「ここの変数(この場合は予算を$30から$50に増額)を変えたら、検索結果が良くなるから試して」とユーザーを誘導するのは、ECサイトだけではなく多くのビジネスの参考になるポイントだろう。その場合は「検索結果が0になったら変数を変えて再度検索を行い、それを提案する」というプロンプトがすでに組み込まれているのかもしれない。

AI Toolkit for VS Codeの紹介を行うSilver氏

AI Toolkit for VS Codeの紹介を行うSilver氏

ここではエージェンティックなAIを組み込むワークフローの実装、複数のモデルを利用できること、そしてモデルの評価などが行えると説明している。またバックエンドにはAzure AI Foundryが控えていることからもGitHubでソフトウェア開発、CI/CDもGitHub Actionsで実施、本番環境での実装というところまでが一気通貫に可能になったことを説明した。その後で再度Boyer氏が登壇し、このアプリケーションを担当するSREの仕事を、デモを通じて説明した。

Boyer氏がSREの立場でペットアプリを運用するデモを実施

Boyer氏がSREの立場でペットアプリを運用するデモを実施

このデモでは本番環境のペットアプリがコード500のエラーを多発しているという状況からスタートして、その対応から環境の修正を行うというところまでのデモとなった。

リポジトリ上にイシューが作られそれをCopilotにアサインすることで可能な対応策を生成させる

リポジトリ上にイシューが作られそれをCopilotにアサインすることで可能な対応策を生成させる

このデモでは実際にGitHub上でイシューを作り、それをCopilotにアサインすることで改善のための調査内容や調べる箇所の同定などを経て、SREのエンジニアが実行されているPodの初期数を1から3に変更し、最大15まで増加していいという設定を行うところまでを見せた。

SREのエージェントが提案してきたPod数の変更

SREのエージェントが提案してきたPod数の変更

ここの部分はGitHubではなくAzureのSRE Agentという別のソフトウェアが担当していることになるが、参加者からみれば、Copilotを使ってコードの修正、AI Toolkit for VS CodeでアプリケーションにAIを組み込み、SRE Agentを使って本番環境のトラブルを修正という一連の流れを、GitHubではなくMicrosoftのエンジニアがデモを行ったという部分がポイントだと思える。つまりGitHubはあくまでもソフトウェアの開発にフォーカスしているが、実際には本番環境でそのアプリがちゃんと動くことが一番大事であり、そのための機能強化を続けているという姿勢だ。GitHubはDay0を1にする仕事、MicrosoftはDay1から始まる終わりのない運用の仕事を担当するという発想だろう。どの段階でも生成AIがデベロッパーやOpsエンジニアを助けるということには変わりはなく、開発から運用までのワークフローにしっかり組み込むことで個人差をなくし、普遍的な価値を与えようとしていることを強く感じたセッションとなった。

Azure SRE Agentを紹介するSilver氏

Azure SRE Agentを紹介するSilver氏

さらにこのセッションのまとめとして壇上で見せてきたことを整理

さらにこのセッションのまとめとして壇上で見せてきたことを整理

ここでは自然言語によるマークダウンで生成AIに指示を与え的確な結果を得られたこと、複数の生成AIモデルを評価し、ローカルで実行することなども行った上で生成AIが複雑なタスク実行が可能になっていること、生成AI自体のモニタリングやトレーシングが可能であること、本番環境でのモニタリングや障害対応にも生成AIが使えること、などを整理して説明した。

デベロッパーの仕事のやり方にパラダイムシフトが起きている

デベロッパーの仕事のやり方にパラダイムシフトが起きている

この変化はパラダイムシフトと呼べるぐらいには大きな動きであり、マニュアルのコード生成から仕様を詳しく明確に記述することで仕様駆動型のソフトウェア開発に移行し、デベロッパーの役割が本質的に変わってしまうことに対応しようと述べてセッションを終えた。

最後に強調していたのは、「このやり方はすでにユーザーが試すことができるレベルまで開発が進んでいる」ことだった。デベロッパーに留まらずにSREまで含めた新しいワークフローの提案という意味で、Microsoftのエンジニアがこれをやった意味は大きいし、今後、さらにMicrosoftとGitHubの連携が進んでいくことを予感させる内容となった。

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

人気記事トップ10

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

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