Jay Parikh, Scott Guthrie, Charles Lamannaが昨日のDay1のKeynoteで発表されたupdateをdeep diveして解説してくれる。
ありがたいことに今日は最前列🥰
元のXのセッションレポのスレッドはこちらを（ちょいちょい動画もある、誤訳してたところはこっちの記事の方で直してます）。
Microsoft公式が出してるFull ver.のアーカイブはこちらから。
- 昨日のDay1で発表した数々のアップデートは開発者がAgentを開発しやすく、運用しやすく、そして技術的負債のバーンダウンを下げるためのものだ。なぜ我々はこれをするのか？開発者（Builder）にとって最も貴重なのは時間だ。我々はその時間をあなた方に返したい。
- GitHubによる開発体験の向上のより具体的なデモ
- GitHub上で作成されているIssueのIDをIDE上のGitHub Copilot Chatで’let’s work with Issue #
‘ で指定するとissueに記載されている実装すべき内容を参照してGitHub Copilotがそのissueに記載されていることを実現すべく動いてくれる。 - Pull Requestのコメントで’（実装した内容の）mermaid.jsでのアーキテクチャダイアグラムを描いて’とお願いするとmermaidでアーキ図を描いてくれる
- GitHub上で作成されているIssueのIDをIDE上のGitHub Copilot Chatで’let’s work with Issue #
- GitHub Copilotを最大限に活用するベストプラクティスとしては、GitHubのOrganizationに含まれるIssueなどのGitHub.com上の様々な機能とGitHub Copilotを組み合わせること。それにより開発者はよりプロダクト開発に集中することができる。
- Azure SRE Agentによるインシデント分析、レポートとトラブルシュート: SRE Agentが稼働中のアプリケーションのインシデントを検知、分析して推奨アクションを含むインシデントアラートをGitHub Issuesにチケットとして作成する。GitHub Copilot Coding Agentをアサインすることにより、Coding Agentが修正のPull Requestを作成する。これに掛かる時間は約30秒。
- GitHub Copilot App modernizationはJava, .NETで古いバージョンから新しいバージョンにアップデートする。このmodernizationの実行プロセスはPlan, Execute, Summaryの3段階で実行される。Planの段階ではどのようにアップグレードするのかをdocumentとしてユーザーに示し、Executeでアップグレードを実行、最後のsummarizeでサマリーを提供する。このようなApp modernizationの機能はMainframe modernizationにも適用する予定である。多くの企業は膨大な量のCOBOLEのコードで動いているメインフレームを持っているがそれをメンテナンスしたり内容を把握することが難しくなっている。このApp modernizationの今後の展開として、現状のコードを解析してサマリーするだけでなく、Unit Testを生成してテストをした上で移行ができるようにする予定である。この機能は今年の後半(late this year)に提供できるだろう。
- OpenAIとの協業により、CodeX AgentをダイレクトにGitHubのプラットフォームに統合するということは昨日のKeynoteでもアナウンスしたが、Anthorophicとも協業してClaude Code AgentもGitHubのプラットフォームに統合する。
- これによりGitHubは複数のAgentをオーケストレーションする開発者プラットフォームとなり、これにより開発者はSDLC（ソフトウェア開発ライフサイクル）のあらゆる面でセキュアにAgentを使用して開発を進めることができるようになるだろう。
Agent Factory
- 1975年のSoftware Factoryから現在、Agent Factoryへと発展した
- Agent Factoryの重要な要素は、Model, Knowledge, Agentの3つである
- AI Foundry上で、自然言語でのAgentとの対話によるアプリケーション作成のデモ（本当に会話しながら数分で作成、LinkedInでの投稿までいってた）
- Nasdaqの事例紹介。Foundryで作成したAgentにより25%の作業時間の削減を達成
Trust+Security
- Agentを活用していくにあたって、セキュアであるということ、Trusted(信頼できる)ということはとても重要だ。我々はEntra, Purview, Defenderなどの既存のセキュリティプロダクトをFoundryと統合することによって、安全なAgentの運用を支援する。
- 信頼できるAIのライフサイクルには、リスクの識別、計測、監視、保護、そしてそれらをガバナンスできる機構が必要である。
- Foundry×AI Studio×MS Securityによる生成AIシステムのセキュリティ担保：AIモデルに対する安全性、コンプライアンスのセキュリティのガードレール定義、AI Red Teaming Agent(Public Preview)によるDAST、AI Studio上での攻撃経路の可視化と対応（LLMアプリケーションでユーザーがプロンプトインジェクション（Jailbreak）攻撃を試みたが、Defenderがブロック、Entra上からユーザーに対して行うようにAgentの権限やアクセスを制御）
Cloud to Edge
localでのAI Foundry系の話
- Windows AI Foubdry: ローカルのWindows PC上でAI Foundryの使用、カスタマイズが可能になる
- Phi-4 Reasoning:高度な推論タスクに特化した140億のパラメータを持つファインチューニングされたAI model
- 自然言語による意味検索（Semantic Search）と、ナレッジ検索（RAG） を
より簡単に構築できるように
- 2028年までに13億のAI Agentが展開されるだろう
Copilot Stuido, Power Apps, Teams
- Teams上でのResearcher Agentによるdocs、paper（論文）の解説、サマリーレポートの生成
Researcher Agentとの対話により、学術的な知識の理解がより促進され、これらの知識を多くの人が業務に応用しやすくなる - Copilot Studio、Power Apps、Teamsの活用により業務でのAgentの作成、利用がより推進される。中でもCopilot Studioは数あるサービスの中でも最も簡単にAgentを構築することができる、200,000以上のAgentがCopilot Studioにより作成されている
- Power AppsのAgent Feedでの各エージェントのアクティビティの監視とインシデントの可視化
- Power Apps上でPlanを自然言語で記載すると複数のエージェント（Solution Architect Agent、Data modeling agent, etc.)がworkしてユーザーストーリー、データモデリングの検討を行いAgentを作成する。これによりあなた方のPowerAppsにおける体験はこれまでと全く違ったものになるだろう
- 様々なタスクを実行する。これらをセキュアに使用するために、ユーザーに対してそうするのと同様にこれらのAgentを制御するためのガバナンスが必要になる。それを実現するのが、Purview, Microsoft Entra, Microsoft Securityなどのセキュリティ製品群である。
Data center周りの話
- AI optimizationはnew levelに達した。このムーブメントを支えるために、多くのAzure data centerが必要であり、そしてこれまでよりも低いコストでの稼動を目指す必要がある
- しかしこの取り組み（データセンターの増強）はsustainableでなければならない。100%再利用可能なエネルギー、データセンター建造時の二酸化炭素の削減に取り組んでいる
- すべてのデータセンターでは閉じた循環系により、zero water wasteを実現
Closing
- 今回紹介した技術の全ては、AIとAgentによる新たな時代をエンパワメントするためのものである
Azureがこれまでどのように進化してきたか、どのようなイノベーションに取り組んできたかを概観する。
- Azure Boost:オフロードによるインフラの加速。ホストOSがネットワークI/OやストレージI/Oの処理を担う→I/O処理や管理エージェントを専用ハードウェア（オフロードカード）に分離、Translation Layerによるセキュリティとリソース境界を確保。それにより、より高度なパフォーマンスとセキュリティ、運用の柔軟性を追求。
- 顧客環境とAzure Boost間における物理,メモリ上での分離
- Azure Boostのようなインフラストラクチャの進化が必要とされた背景としては、AIのワークロードにおけるストレージ要件がある。AIのトレーニングに使用するデータの高速読み書き(I/O)、画像・動画など大規模なデータの読み込み、推論時に使用する巨大なLLMモデルの読み込みを達成するためには画像のようなストレージ要件をクリアする必要がある。
- これまでのcloud nativeのイノベーションの中で力を入れて取り組んできたことの一つがLinuxをAzure上で安全に動作させるということだ
- LinuxGuardは、信頼されたコンテナ実行環境を提供する。コンテナ環境における信頼性とは、コンテナイメージの整合性の担保、改ざんからの保護などが求められる。
- イメージごとの整合性と署名でゼロトラスト強化、Immutable OS + SELinuxで不正変更をブロック
- 従来のAKSでは、突発的なトラフィック増加時に Virtual Nodes on ACI を使ってPodをスケールアウトしていた。Standby poolによって、事前にPodをプレウォーム（待機状態で準備）することによって、トラフィック急増時に柔軟に即時スケールができる。これによりトラフィック急増への対応力を強化した。
- クラウドネイティブアプリはもはやKubernetesだけで達成できるわけではない。Podだけではなく、関連する多種多様な周辺サービスやワークフローとの統合が必須
- これまでのAzureのイノベーションの中で追求してきたことのひとつは、「信頼性のあるコンピューティング（ confidential computing）だ。
- どのようにconfidentialという状態を達成するか？それにはは各コンポーネント/ドメインで使用されるデータが適切に保護するということが求められる。
- 同様に、confidential AIを実現する際にも、model、トレーニングやファイチューニングで使用するデータ、複数partyでの共有時のデータを保護することが必要になる。このようにconfidential boundaries（どの情報が、どの領域・タイミング・責任範囲で機密性を担保されるべきか?）を意識することが重要である。
- 未来のコンピューティングは、完璧にサーバーレスになるだろう。それは基本的にはコンテナの操作のみで完結する世界。
Conversations: App Modernization Journey
Cloud Native&AKSのPartner Product ManagerのSean McKennaが、ファシリテーターのVinicius Apolinario、そして会場の参加者からの質問に答えるQ&Aセッション
Q.Appのmodernizationについて考えるとき、どのようなことを考慮する必要がある？
A.modernizeをしたいとき顧客はそれぞれ違う目標がある。新しいアーキにチャレンジしたい、セキュリティを高めたい等。App modernizeをする時に必要なのはそのdriver（クライアントをmodernizseに駆り立てるもの）を理解してゴールを定めることが重要である。
Q.Modernizeのアプローチについて教えて欲しい。様々なpro/conがあると思うが、どのように考えているか。
A.modernizeを進めるとき、速く、簡単に終わらせたいもしくはそうできますよと顧客に勧めたくなるという誘惑に駆られる事があるだろう。しかしmodernizeの旅路をデザインする際には、小さな改善を確実に重ねるとうことが重要だ。
そのような小さなmodernizeを確実に重ねて、長期的な目線でmodernizationが達成できるように支援する必要がある。
Q.AKS(Azure Kubernetes Services)、ACA(Azure Container Apps)、(Azure)Functions、色々なサービスがあるが、どのように技術選定をすべきか。
A.Functionsの場合は比較的小さな業務の効率化や実行を行うのに適している。一方で、ACAやAKSはコンテナ利用を前提としたサーバーレスのサービスである。サーバーレス、柔軟性やレバレッジを求めるのであればACAやAKSが候補になる。しかし大抵の場合、特定のサービスによって問題解決が達成できる場合はあまりない。サービスのメリットというものはスペクトラムである。ユーザーの要求に基づいて関心の境界を分離すること、それを基にしてどのようにサービスで解決するかを考える必要がある。
Q.レガシーなアプリケーションをモダナイズすることの正当性（justification)をどのように説得すればいい？
A.レガシーなアプリケーションがあるということはそれだけリファクタやインフラストラクチャの運用コストが高くなるということだ。ビジネスがその状況に足を引っ張られてしまうリスク、つまりそれによる競争力の低下などについて語る。
Q.日本の市場においては多くの企業がレガシー化したメインフレームに苦しんでいて、モダナイズを望んでいる。しかしそれらのメインフレームはCOBOLや古いバージョンのJavaで書かれている。これらの言語のスキルがあってメンテできる開発者の数は減り続けている。その結果として、既存のシステムの構成を理解することも困難になっている。このような状況に対してどのようにモダナイズの旅を支援すべきか。
A.レガシーになるということの定義は2つある。1つはその使われている技術がすでに古くなっている、サポートされていないなど。もう1つはメンテナンスできるスキルを持つリソースがいなくなることによって実質的に運用できなくなること。このような状況にあって、COBOLの場合はどちらにも該当していると思う。そしてそのような状況にあって、ただでさえ少ないCOBOLのエンジニアをアサインするとかはあまり現実的でない。この質問に対する答えは、AIの支援を受けること。GitHub CopilotのようなAI assisted toolを使って、まずは現状のシステムを動かしているコードを理解し、よりメンテナンスがしやすい言語にtranslateするなどの計画を立てる等が必要。コードが理解できる状態になるということがモダナイズの旅を始めるための1st stepだ。
Q. App modernizeの実行とプロセスをどのようにデザインするべきか。DevOpsのようなフィードバックループを回すアプローチはこのような場合でも有効か。
A. Yes。App modernizeの場合、多くのユーザーはまだmodernize前のプロダクトを一定期間使い続ける必要があるというシチュエーションがほとんどになる。つまり一気に変更できるものではない。App Innovationのプロセスは大きく分けてPlanning, Implementing, Operationの3つである。ゴールを定義してmodernizeの旅路を計画し、実装し、運用していく。段階的に適用してフィードバックを受けるというフィードバックループは確かに重要だが、App modernizeの場合は年単位でフィードバックすることになるだろう。
※参考：
Views: 0
