Japan Azure User Group 16 周年イベント ｜ 2026.10.03 AI 時代の Azure エンジニアリング ～ 私たちは何を磨き、何を任せるのか ～ 日本マイクロソフト株式会社 Microsoft Innovation Hub Chief Architect, Evangelist 井上 章 (いのうえ あきら) @akira-inoue-chack411 @chack411 

祝！ JAZUG 16周年 ― おめでとうございます！ 16 周年の JAZUG 2010.08.26 結成 2010 JAZUG 結成。Azure を学び合う場が生まれる 2010年代 オンプレミスからクラウドへ。役割も働き方も変わった 2026 AI エージェントが設計から運用まで関わる時代へ 

Software engineering has changed faster in the last year than in the last decade ソフトウェア エンジニアリングは、過去 10 年間よりも この 1 年でより速く変化しています 

Foundry agent team How we work AI Augmented Development Code Code review Onboarding 100K+ AI-first Week 1 設計も含め、9 人のエンジニアが 3週間で 10万行以上の コードに貢献 すべての PR は AI-first でレビューされる “.github/instructions/” でチームの ナレッジをエンコード → Copilot がアーキテクチャを提案 → 新メンバーが 1 週間で プロダクションコードを出荷 (通常は 3-4 週間かかる) lines in 3 weeks code review 敵対的クロスバリデーションのマルチモデ ルアンサンブルで、人間がレビューする前 に、バグやセキュリティ問題、テストの ギャップを検出 shipping 

Azure のどの工程にも AI が入ってきた 設計から運用、ガバナンス、コストまで ― AI が関わる場面の例 設計 構築 運用 セキュリティ ガバナンス コスト 要件の整理 IaC の生成 ログの要約 構成レビュー ポリシー案 使用量の分析 構成案の比較 手順の自動化 一次切り分け 脆弱性の確認 規約チェック 最適化の提案 図の下書き 環境の試作 手順書の整備 脅威の想定 監査の準備 予算の見直し どの工程でも、最後に確かめ・判断し・責任を持つのは人 ※ 具体的な製品機能ではなく、一般的な関わり方の例 

生成 AI によって劇的に下がった「試作コスト」 「この機能を作るべきか」を会議で議論するよりも、まず試作品を作って検証してしまう方がコスト効率が良い 本番環境向け機能を実装するためのトークンコストは、 今やその機能を作るべきかどうかを話し合う会議のコスト よりも低くなっている。 言い換えよう。 その機能を作るべきかどうかについて30分の計画会議を 開くよりも、実際に作って動くかどうか試してみる方が、 文字どおり安上がりになっている。 「この機能を作るべきか」を会議で議論するよりも、まず試作品 を作って検証してしまう方がコスト効率が良い時代になった。つ まり、多くの場合は議論よりも実験・実装の方が安くて速い、 ということだ。 従来： 生成 AI 時代： • アイデア検討 • AI とアイディア検討 • 要件整理 • AI に実装させる • 計画会議 • すぐ動かす • 設計レビュー • 検証する • 実装 • ダメなら捨てる 

Software engineering is much more than knowing a programming language or framework プログラミング言語やフレームワークを知ること以上に ソフトウェア エンジニアリングはとても重要です 

どの時代にもある “パニック” 1980s 1990s 2000s 現在 C vs. Assembly IDEs Stack Overflow AI “アセンブリこそ 本物のプログラマー" "インテリセンスは 脳を腐らせる" “コピペ開発者" “コーディングの 終焉" 補足：その他にも、クラウドの登場 → インフラエンジニア不要論 … など 

エンジニアの役割は、設計と判断を担う仕事へ移る クラウドが登場したときも「インフラエンジニアは不要になる」と言われたが … クラウド登場のころ 現在 ラック・サーバーの設置 アーキテクチャ設計 配線・OS のインストール 運用設計・信頼性の確保 ハードウェアの保守・交換 ガバナンス・セキュリティ・コスト 作業はなくなったのではなく、クラウドに任せられるようになった 人の役割は、より上流の判断と成果への責任へ移る AI でも同じことが起きる/起きている 

The craft didn’t die. It moved up a level. From doing the work → to owning outcomes その技術は消えてはいない それは一段上のレベルに移ったのだ 「作業」から「成果に責任を持つこと」へ 

AI エージェントも間違える 実際に AI エージェントと作業すると、繰り返し出会うパターンがある 01 02 03 モックデータに戻る 早すぎる完了宣言 ドキュメントを根拠にする 本物のデータにつないだはずが、いつの 間にかダミーに戻る 「完了しました」と言うが、実際には動い ていない 動作を確かめず「ドキュメントにこう書い てある」を事実として扱う 04 05 06 実装忘れ・リグレッション 承認していない変更 偽のテスト 一部の実装を忘れる、 直したはずの箇所を別の変更で壊す 頼んでいない箇所まで、勝手に書き換 える テストが通るように、中身のないテストを 書く 共通点：「それらしく見える」ことと「正しい」ことは違う。確かめる責任は人に残る 

Azure の現場ではこう現れる AI の「それらしい答え」は、Azure ではこんな形で表に出る 現れ方 起きがちなこと（例） 確かめる手段 必要以上に広い権限 手早く動かすために、広いスコープで強いロールを割り当 ててしまう 最小権限・スコープの確認、ロール割り 当てのレビュー 意図しない公開エンドポイント パブリック アクセスが有効なままのストレージやデータベース ネットワーク構成と公開設定のレビュー 存在しない設定・API バージョン それらしいが実在しないプロパティや API バージョンを書く 公式ドキュメントとの照合、what-if・検 証環境でのデプロイ 気づかないうちに増えるコスト 過大な SKU、止め忘れたリソース、必要以上のログ収集 予算アラート、コスト分析、タグによる可 視化 どれも「一見それらしく動く」。だからこそ、デプロイの前後で確かめる仕組みが要る 

任せるための仕組みをつくる AI に渡すのは「作業」。境界線と確認の仕組みは人が設計する 1 2 3 4 5 最小権限 承認ステップ 変更前の確認 Azure Policy 監視 AI や自動化に渡す権 限は、必要な範囲だけ 本番への変更は、必ず 人の承認を通す what-if で、適用前に 何が変わるかを確かめる 越えてはいけない線をガ ードレールで強制 変更後の挙動とコスト を見続ける 動くことを証明して届ける AI に任せた結果は、「正しいことの根拠」とセットで届ける ・what-if の結果（何が変わるか） ・テスト・検証の記録 ・ポリシー準拠の確認結果 ・デプロイ後の監視状況 参考：Simon Willison’s Weblog（本資料の元になった引用） 

AI エージェントに任せる仕組み: ハーネスを設計する 人：依頼・承認・最終判断 スキル オーケストレーター：役割分担と計画 手順・ノウハウをパッケージ 化 メモリ 決定事項や経緯を保持 する MCP 外部ツールとの接続 設計 エージェント 構築 エージェント 運用 エージェント Azure・GitHub・監視・チケット 管理などに標準的な方法でつ なぐ 評価 セキュリティ ガバナンス 成果を測り、プロンプトや手順を継続的に改善 最小権限・秘密情報の保護・外部入力への 対策 ポリシー・監査ログ・コストの管理 ハーネスは「仕事ができるエージェント」に変える実行環境の型 モデルとツールの呼び出し、会話とコンテキストを管理し、承認ポリシーを適用して、複数ステップのタスクを前進させ続ける 

Judgment is scarce Verify. Diagnose. Decide. Integrate. 希少になるのは「判断する力」 確かめる・見極める・決める・全体をつなぐ 

Monolith vs. Microservices AI エージェントシステムの設計にみるクラウドネイティブな判断の必要性 選択の指針 Modular Monolith • シンプル、共有メモリ、低レイテンシ • 小〜中規模・単一チーム向け Microservices 参考: Multi-Agent Reference Architecture • 独立デプロイ、細粒度スケール、技術自由 • 大規模・複数チーム・ドメイン別 

クラウドシステムの評価軸 Two scorecards. One output. MARK’S RUBRIC SCOTT’S RUBRIC Correctness Clarity Does it actually do what it claims, under stress? Could a tired human read this and trust it? 負荷がかかっても、主張どおりに動くか 疲れた人が読んでも、理解し信頼できるか Performance Confidence How does it behave at p99 and at scale? Do I understand WHY it works, not just THAT it works? p99 やスケール時に、どう振る舞うか なぜ動くのかまで理解しているか Architecture Recoverability Will this hold up when the next person changes it? When this breaks at 2am, can I fix it? 次の人が変更しても、持ちこたえるか 深夜2時に壊れたとき、直せるか Same answer. Two scorecards. The gap between them is where engineering lives now. 同じ答えでも、評価軸は2つ。その間にこそ、いまのエンジニアリングがある 

Well-Architected Framework と評価軸 5つの柱を、AI の成果物を見極める問いに落とし込む WAF の柱 AI の成果物に問うこと 対応する評価軸 信頼性 障害が起きても動き続け、復旧できるか Correctness / Recoverability セキュリティ 最小権限・データ保護になっているか、なぜ安全か説明できるか Correctness / Confidence コスト最適化 価値に見合うコストか（トークン消費も含めて） Performance / Architecture オペレーショナル エクセレンス 疲れた人が読んでも、運用・変更できるか Clarity / Recoverability パフォーマンス効率 p99 やスケール時にも、期待どおりに動くか Performance AI の出力を「WAF の観点で説明できるか」が、判断力の一つの試金石 

判断力をどう磨くか 毎回の小さな検証が、判断の引き出しを増やす 1 3 5 自分で説明できるまで確かめる 「なぜこの構成なのか」を自分の言葉で説明できないもの は出さない 複数のモデル・視点で見比べる 別のモデルや同僚に同じ問いを投げ、食い違いを手がか りにする AI の成果物を注意深くレビューする 権限・公開範囲・コストなど、影響の大きい箇所から見る 2 4 6 小さく任せて、毎回検証する 変更は小さく。デプロイ・テスト・what-if で毎回確かめる 分析・計画は最も高度なモデルで 設計や方針づくりは推論力の高いモデルと行い、必ず人 がレビューする 障害の振り返りに参加する 何が起き、なぜ見抜けなかったのかを知ることが判断の材 料になる 

To keep refining — not becoming an audience 判断力を磨き続けるために ― 観客にならない 

魔法使いと働くことについて That suggests another risk we don't talk about enough: Every time we hand work to a wizard, we lose a chance to develop our own expertise; to build the very judgment we need to evaluate the wizard's work. We're getting something magical, but we're also becoming the audience rather than the magician, or even the magician's assistant. Source: https://www.oneusefulthing.org/p/on-working-with-wizards これは、私たちが十分に語っていない もう一つのリスクを示唆しています 魔法使いに仕事を任せるたびに、自分の専門知識を 磨くチャンスを失います。判断を立てるためには、魔法 使いの仕事を評価する必要があります。 私たちは魔法のようなものを手に入れているのですが、 同時に手品師や手品師の助手ではなく、 観客になっていくのです。 

AI は「鏡に映った自分」である System 1 / 2 / 3 思考と、AI が招く「思考の外部化」リスク 1 2 3 直感的思考 熟考的思考 思考の外部化 (AI) 素早く、無意識の判断 経験から自動化された反応 散歩しながら深く 考えるような熟考 繰り返すと ① になる AI による思考の外注 ①② を奪い、人を 「空っぽの殻」にするリスク 鏡のメタファー AI があなたのアイデアを否定したことがあるか? ない。それは鏡に映った自分自身と話しているからだ。 10 年続けると誤った自信が形成される。我々は謙虚でなければならない。 

Senior AI boost AI がブーストするシニア層 vs. Early-in-career AI drag AI で減速するジュニア層 経験に基づく判断力がないジュニアは AI を使うと逆効果。シニアは大きなブーストを得る。 データ：AI 導入企業ではジュニア層の雇用が約 7.7% 減少（SSRN 5425555）／AI の影響を受けやすい職種で 22〜25 歳の雇用が相対的に 13% 減少（Stanford Digital Economy Lab） 

生成 AI の普及以降、AI に影響を受け やすい職種に従事する若年層労働者 （22～25歳）の雇用は 13％ 相対的 に減少した。一方で、影響を受けにくい 分野の労働者や同じ職種のより経験豊 富な労働者の雇用は安定、あるいは増 加し続けている。 

「人材パイプラインの崩壊」への警鐘 Mark Russinovich と Scott Hanselman の共著論文での警告 The Talent Pipeline Will Collapse 「人材パイプラインは崩壊する」 — Redefining the Software Engineering Profession (ACM) Mark Russinovich (Azure CTO) × Scott Hanselman 共著 AI でジュニアが 減速する 企業が ジュニアを切る 次世代シニアが 育たない 競合から高給で シニアを雇うしかない 

Preceptorship Mentor を超える伴走型指導制度 

プリセプター (指導者/教師) テック リード AI 時代の 指導者制度 Plan Review Plan Assign Implement Review Plan Assign Implement Review Assign Implement AI 支援を受けたキャリア初期の開発者 

プリセプター制度 (Preceptorship) • 看護の「プリセプター (指導看護師)」に由来。全員がなるわけではない、正式に定義された職務 • 評価は「新人を一人前にできたか」で行う • 年次評価で「この人は指導役を続けるべきか／指導役としての訓練が必要か」を問う • 体制：テックリードの隣に、育成専任のプリセプターを置く 「プリセプターの仕事はコードを出荷することではなく、エンジニアを出荷すること（ship engineers）」 — Scott Hanselman, InfoQ Architects Podcast（原文より参照） 

～ 私たちは何を磨き、何を AI に任せるのか ～ 

任せる／磨く 任せる（AI と一緒に速く） 磨く（人が責任を持つ） 作る・試す（試作・検証環境の構築） 見極める（何が本当に正しいか） 下書き（設計書・手順書・IaC） 検証する（根拠を自分で確かめる） 一次レビュー（抜け漏れの指摘） 判断する（影響・リスク・コスト） 定型運用（ログの要約・一次切り分け） 全体の整合をとる（アーキテクチャ・ガバナンス） 調査・比較の材料集め 障害に向き合う（原因を突き止め、再発を防ぐ） 繰り返しの作業の自動化 次の世代を育てる AI に任せられる範囲は広がり続けている だからこそ、確かめ、見極め、判断する力がエンジニアの価値になる 

The future of software engineering isn’t who writes the most code. これからのエンジニアの価値は、どれだけ多く作るかでは決まらない It’s who learns fastest, judges best, and helps others level up. 速く学び、正しく判断し、仲間を引き上げる人が価値を生む 

Podcast: Scott & Mark Learn To... - Hosted by Scott Hanselman, Mark Russinovich Appendix Future of software engineering paper: Redefining the Software Engineering Profession for AI | Communications of the ACM 

Thank you @chack411 井上 章 ／ 日本マイクロソフト株式会社 © Copyright Microsoft Corporation. All rights reserved. Microsoft Innovation Hub