Ignite参加おつかれさまでした！(/・ω・)/
Microsoft Ignite2025のGitHub, Azure DevOps関連のセッションを片っ端から聞いてAgentic DevOpsに関連してそうなセッションをまとめました。
※記事中の画像はセッション動画が諸元です。
AI-powered workflows with GitHub and Azure DevOps（BRK106）
- Azure DevOpsとGitHubどっちを使うべきなの？Azure DevOpsはもう使わない方がいいの？という昨今の議論に対する直接的なアンサーセッション。どちらかではなく両方を併用しましょう
- Azure Boards, Azure Pipelnes, Azure Test Plansはそのまま使いつつ、コードベースをGitHubに移すことで、Azure DevOpsのメリット（Boardsによる作業の追跡、リッチなプロジェクト管理、Azure PipelinesとTest Plansによるグラフィカルなテスト管理）を享受しつつ、GitHubの機能を最大限に活用することができる。
- 本当にAgentic AIを活用したいならReposをGitHubに移すのだ！（Coding AgentなどのAI機能、GitHub Advanced Securityのセキュリティ機能をフルに活用するために）
Azure DevOps→GitHubへのRepos移行についての参考：
- Azure BoradsからCoding Agentへの作業のdelegateができるようになった。
- これによってBoardsでのリッチなプロジェクト管理はそのままに、Agentとの協業ができるように。
Inside Microsoft's AI transformation across the software lifecycle（BRK115）
「Microsoft自身」はAIをどのようにSDLCに活用しているか？というセッション。
MicrosoftにおけるAgentic DevOps, Platform Engineeringの実践
- Microsoftにおけるコードベースは多様である。数か月前、数年前に作られたものから、Excelカーネルのように数十年単位で運用されているコードベースもある。それらは様々な言語、様々なアーキテクチャで、実験的なものからクラウドネイティブのようなモダンなもの、レガシーなものまで様々。
-
このようにDevOpsの各フェーズでエージェントを活用し始めている。この世界観は、開発者同士のコラボレーションを越えて、開発者とエージェント、エージェント同士のコラボレーションという世界観になっている。
-
「開発者がエージェントにとって代わられているのでは？」と感じる？だけどそうではない。彼らは「エージェントのボス」として、ワークフローの調整、意図のガイダンス、（エージェントの）意思決定の監督、プロダクトのビジョン、膨大な技術的負債の解消のためにorchestrateしてる
-
我々が目指すAgentic DevOpsは、SDLCのE2Eで、Inner loopからouter loopまで、同期的に、非同期的にAgentと協業できること。そしてそのためには迅速で安全で、規制要件を満たしていて、拡張性があり、開発者がイノベーションを起こす「余白」が確保できるPaved roadとしてのPlatfrom Engineeringが必要。
-
下の画像は、MicrosoftにおけるPlatform Engineeringの考え方である。
-
MSにおけるエンジニアリングにおける重要な標準を紹介しよう。１つはStart best stay right（ベストから始めて正しくあり続ける）。その１つの具体例が、中央集権的に管理され、ホストプール上で動作し、ビルドエージェントとして管理される安全なCI/CD基盤としてのPipelineテンプレート。
-
そしてES Chat。エンジニアリングのベストプラクティスや各種ナレッジを持つMS内で使われているエージェント。VSCode, Teams, Copilotから呼ぶことでChatベースでの開発支援に使われるほか、トラブルシューティングやインフラのプロビジョニングにも使用されている。
各種ツールの効果
-
MS内でのGitHub Copilot Coding Agentの効果👇
-
「適切な統制、コンプライアンスの維持」ポリシーのが重要。ベストプラクティスをポリシーとして強制すること、セキュリティの監視、SRE Agentによるインシデント調査、修正。SRE Agent配下のサブエージェント同士の協業へのAgentの適用。
-
SRE Agentは実はMS内部の社員の仮説から誕生したサービス。今では7000件以上のインシデントが自動で対応されている。
-
開発体験を大きく損なうものは何か？それは「摩擦」。例えば不安定なテスト、長すぎるビルド、etc...GitHub CopilotによるCode reviewはそれらのSDLC上における摩擦を軽減するのに大いに役立っている。どのぐらい役立っているかは下の画像参照。
課題とそこで発見したAgentとの関り方
-
AIを使っていて、むしろ不要なToil（無意味な反復作業や労力）や、期待していない振る舞いによってがっかりさせられたことは？私たちもそうだった。
-
なので、AIに「正しく」振舞ってもらうために多くの労力を払った。ドキュメントを再編し、多くのプロンプトを書いた。
-
それでもがっかりさせられるようなパフォーマンスが続いた。ある晩、M365 Copilotに「どうやったらちゃんとやってくれるのか(Work)」と聞いた。
-
答えは「自動化のツールとしてではなくチームメイトとして扱え」だった。なのでプロンプトをこのように変えた。
-
そうしたらAI Agentの振る舞いが大幅に改善された。
-
これによって得た教訓は、「Agentとのパートナーとしての関係性」Agentをツールとして扱うのではなく、パートナーとして、コラボレーターとして扱うということ。
-
例えば、インシデント調査においては、Azure SRE Agentにすべて任せるのではなく、移行、監視、各サブタスクに特化したサブエージェントを協業して、インシデントになる前に手を打てるようにする。技術は全てを変えるのではない、関係性がすべてを変えるのだ。
Secure code to cloud with AI infused DevSecOps(BRK112)
-
脆弱性はたくさん検知できるようになった、でも修正する暇がない、そしてAIの登場によって生産されるコード（検査すべき）対象はどんどん増える、というDevSecOpsの課題に真っ向から向き合う内容。
-
セキュリティのシフトレフトをGHASが、シフトライトをDefender for Cloudが担うイメージ。
-
コンテナイメージの脆弱性やランタイムアプリケーションの脆弱性検知と修正はGHASだけでは手が届かなかった領域なので、これによってDevSecOpsの完成度がかなり高くなりそう。
-
内容アプリケーションセキュリティの悲しい現実：脆弱性のトレンドは年々変化し続けるにも関わらず、脆弱性を修正する暇がない
-
セキュリティとイノベーションの速度はトレードオフと皆捉えがちだが、実際にAIによる開発の加速化に比例して、蓄積にされるセキュリティ負債はどんどん高まるという悲しい現実がある。それがアプリケーションセキュリティの崩壊(Collapase of AppSec)であり、VillainとHeroの二面性を持つAIの暗黒面である。
-
これの二律背反を克服するためには、アプリケーションセキュリティが高度なレベルで自動化されることが必要である。我々のビジョンはプラットフォームにデフォルトでセキュリティが統合されていること、それによって上記のようなアプリケーションセキュリティの崩壊を防止することができると確信している。
-
GHASとDefender for Cloudの統合攻撃パス分析：攻撃経路になる脆弱性のあるリソースと想定されるリスクを可視化してくれる
-
Coding AgentによるAI-poweredなセキュリティ脆弱性の自動修復Virtual Registryでコード→ランタイムにマッピングしてコンテナスキャンを実施。脆弱性を発見したらDefender for Cloud側からGitHub側にissueを作成し、Coding Agentで修正させる。
-
Copilot Autofixで発見したセキュリティ脆弱性をCoding Agentが一括で修正できるように。
-
GHAS × Defender for Cloudのアップデートの詳細についてはこちら
Secure, compliant, and fast with GitHub(BRK108)
- GitHub Enterpriseのガバナンスの話。GitHubの管理基盤をどのように整備するかをPlatform Foundationとして体系化している。
- GitHub Well Architectedを読んだことがある人はいる？これはGitHubをどのように構成、運用すべきかというナレッジやベストプラクティスを集約しているから、読んだことがない人は一読することをおすすめする。
- GitHub Enterpriseでは企業において安全性と開発体験の改善を両立するためのさまざまなエンターープライズの管理の機能を提供してきた。例えば以下のような機能。
- Enterprise Team: OrganizationレイヤではなくEnterpriseレイヤでユーザーの論理的グループを定義することが可能に。IdPを通じた割り当ても可能。ただしまだ制限はある。
- Enterprise Rolesのカスタムロール:Enterpriseレイヤーでカスタマイズしたロールを定義することができる。
- Organization Custom Property: Organizationにプロパティを設定することができるようになった。これによって、複数のOrganizationを特定の目的やドメインで動的に管理することができるように。
-
これらのポリシー設定はすべてルールセットの中でサポートされている。ルールセットはエンタープライズ層で全体のルールを柔軟に定義するための強力な機能である。CopilotやDependabotにルールセットの制限を適用するか、適用されないように除外するかも設定できる。
-
定義したルールセットがどのように適用されて、どのように動いているかはエンタープライズの管理画面のPolicies > Repository > Code Insightで確認することができる。
-
重要なのは、統制のポイントを分散させず、GitHubの最上位レイヤーであるEnterpriseレイヤーで可能な限り統制を一元的に管理することだ。なので、上記のようにEnterpriseレイヤーで実装できる権限やコントロールの機能を増やしてきている。
-
Codespacesを使うことで組織の開発環境に対する要件を満たす一貫した開発環境をメンバーに配布することができる。画像にあるように、データの置き場も一貫して統一することができる上に、開発者目線では自分のマシンにコードをcloneして色々設定したりしなくても、ワンクリックで開発環境をブラウザ上で立ち上げることができる。「他の人の環境では動いたけど自分の環境では動かない」というよくある問題も回避することができる。
-
ここまではPlatform Foundation、開発基盤をどのように整備するかという話だったが、開発体験の良さを損なわずにどのように安全性やコンプライアンスを取り入れるかも紹介しよう。おすすめするやり方のひとつとして、まずはブランチへのmergeの前にテストの実行とコードスキャンをデフォルトで組み込むということをおすすめしたい。
-
これによって、すべての変更がマージされる前に、セキュリティ的な脆弱性の検知、修正が可能になる。
-
さらに自動のテストやスキャンのほかに、Environmentを使用することで本番環境のような重要な環境へのデプロイの前に手動による承認ゲートを設定することもできる。
- GitHub Copilotにどのようなセキュリティのガードレールが組み込まれているか？ということを知りたい方はGitHub CopilotのTrust Centerにアクセスしてください。
Safe and scalable DevOps with AI agents on GitHub(BRK107)
-
GitHub CopilotはAIペアプログラマーとして誕生し、AgentによってPeer Programmerに進化した。そして次に目指すのは、Agent同士がチームとして協業していく世界観だ。
-
Coding Agentが自身の作業の中でCodeQLによるセキュリテスキャン、シークレットスキャン、依存関係スキャンを自律的に実行することができるようになったことで、これまでOuter loopで適用していた品質担保のためのさまざまなチェックをinner loopに内在化することができるようになった。
-
また、エージェントには下記のようなセーフガードがデフォルトで組み込まれている
-
Coding Agentをカスタマイズする場合は、Custom Instructionを使用してプロンプトでレスポンスをカスタマイズしたり、Coding Agentの実施の前に実行するべきワークフローをActions Setupで設定したり、Coding Agentの外部へのアクセスを制御することができる。
-
さらに前回のUniverseでCustme Agentを発表した。これによって、特定のタスクに特化したエージェントとしてCoding Agentをカスタマイズすることができる。これはGitHub.com内だけではなく、CLI, VSCodeにも適用可能。
-
画像のような3rd partyのMCPサーバーと連携してCoding Agentのカスタマイズすることが可能。
-
GitHub上が開発者だけでなくマルチエージェントのプラットフォームとなった今。我々はエージェントの管理についても考える必要がでてきた。
-
そのための機能が、Agent Cotrole PlaneとしてのAI Controleのページ。これによって人間の開発者、チームに対して行うのとどうようにアクセス制御を行い、そしてAgentの監査可能性を担保する。
参考：
-
GitHubのカスタムエージェントについてはこちらのdocsを
https://docs.github.com/ja/copilot/tutorials/customization-library/custom-agents -
セッション中で紹介されたAI Controleについてはこちらを
Ship faster. Stress Less. Idea to ops with Azure and GitHub Copilot(BRK109)
-
GitHub Copilot, Azure MCP Server, Coding Agent, App Modernization Agent, SRE Agentを使って設計から運用までをカバーする
-
Azure MCP ServerがGA。GHCPと統合することによってあなたのGHCPをAzureの専門家に
-
Azure MCP ServerとSpec Kitを使って、Azureのベストプラクティスに従って設計を支援してくれる
-
セッション中で紹介されたAzure Appを開発、デプロイするためのベストプラクティスをまとめたrepos
-
Azure SRE Agent: MCP Server経由でPagerDuty, Nre Relic, Datadog, dynatrace, Neubirdなどの3rd party製品と統合
-
MSのチームがSRE Agentを使った効果👇
-
Bring your own data and knowledge: Azure DevOpsのWikiなど組織のナレッジベースの情報をinputできる
-
Azure SRE Agent, PagerDuty, Datadog, Azure Monitor, GitHub Copilotを統合したModern Site Reliability Stack
- Azure SRE Agentが起票したIaCの修正提案のissueをAzure MCP Serverを設定したCoding Agentに修正させることでより精度が高い修正を適用することができる
- その他のおすすめツール
- 多様なモデルの選択、スピーディーなエージェントのbuild/testが可能
- https://marketplace.visualstudio.com/items?itemName=ms-windows-ai-studio.windows-ai-studio&ssr=false#overview
- GitHub Copilot for Azure, Azure Resource ManagerなどVSCodeでのAzure開発をサポートする機能を提供。これでVSCodeから離れずにAzure開発ができる。
- https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-node-azure-pack
Building Sustainable Software with Agentic DevOps on GitHub(BRK218)
GitHubがAgentic DevOpsの時代にSusatinabilityに対してどのように取り組んでいるか？どのような取り組みができるかお話。
- MicrosoftのSustainabilityに関する取り組み。2050までの脱炭素、1975年の創業以来から輩出してきたすべての炭素分を大気中から除去するなど
- しかしこれに対して懐疑的に思う人もいますよね？実際Microsoftでは世界でも有数のエネルギー購入者なのです。
- 自分が作るべきものに関して、環境にとってなにが最善かを考えたことはありますか？そしてそれに対してできることのひとつとして、意外に思われるかもしれませんが、「Do less（より少ないことをする）」ということがあります。
- これは消費電力、帯域幅の削減につながります。コードの環境への影響を減らすことで、コードのパフォーマンスも向上します。
- あとは、CPUサイクルではなくGPUサイクルを使い、消費電力を抑えることもできます。
- もうひとつの方法として、コンピューティングの密度を高めるということです。つまりコンテナやクラウドを利用することで、常に稼働しているパワーを共有することでCarbon footprintを削減することにもつながります。
- たとえば、GitHub上にいる1億8000人のユーザーそれぞれが努力して1ワットでも消費電力を減らすことができれば、その影響は大きなものになるだろう。
- AIとエネルギーの問題: AIの使用にあたっては多くのエネルギーを消費する。この意味において、持続可能性とAIは深く関連している。
'Measure' to Do Less
- 私がDevOpsの祖父と呼んでいる、Lord Kelvin（ヴィクトリア朝時代の科学者）の「Measure is learn（測定することは学習すること）」という格言を紹介したい。彼のこの言葉は自分にとってDevOpsの核心である。そのため、Sustainabilityについて取り組むときもまずはこれらのことを測定することが重要だ。
- そのためのツールがGitHubでOSSとして公開されている。
https://github.com/github/GreenSoftwareDirectory - これにより、どのように今のエンジニアリングが炭素を排出しているのか、技術的な意思決定の際に各オプションがどのような影響があるのかを知ることができる。
'Build Automation' to Do Less
-
ホストサーバーやコンテナに移行せよ：サーバーをより環境に配慮しており、コンピューティング密度が高いデータセンターのホストサーバーに移行しましょう。1月までにやれば100%再生可能エネルギーになります。これによって、計算密度も向上するためコストも改善します。ホストサーバーが使えない場合はホストサーバー内で構成されたコンテナを使いましょう。
-
スケジュール実行されたジョブを避ける：ほんとうにそのスケジュール実行が必要かどうかを再度確かめるべきです。意味の薄いスケジュールジョブはそのためにビジネスの電気料金を圧迫し、収益性を下げます。
-
GitHub Acions/pipelines内で積極的にキャッシュを使うことで、電力とコストを節約する
-
本当に必要なときだけビルドする
-
適切なライフサイクルでビルドする：これにより必要なチェックだけに限定され、不要なエネルギーを使わずに済むだけでなく開発者にとっても迅速なフィードバックが得られる。またCIのフェーズでsmoke testを手動実行してそれが終わってからデプロイ。。。というプロセスであれば、CIをずっと動かして待っている代わりにCDを分離するのがエネルギーのコスト節約という観点でもおすすめである。
-
適切なサイズのランナーを使うこと
-
green-coding-solutionというツールを使って現在のプロセスを評価すること
https://github.com/green-coding-solutions -
適切なモデルを使う：全部の作業に一番いいモデルを使ってませんか？たとえば、複雑な思考や推論に特化したモデルはよりコストが高く、より多くの炭素を消費してしまう。
-
このように、電力消費の削減を意識すると結果的に継続的なSLDCの効率化、コストの削減や開発体験の改善、炭素の削減につながる。それによって地球全体にとっても大きな効率化が生まれる。
※表示されている画像のContinuous AIは「コラボレーションワークフローをAIによって自動化する」という意味のコンセプトだけども、Continuous（継続的な）で今回のSustainability（持続可能性）とかけてダブルミーニングにしてるのかも）
Continuous AI:
Discussion