Upgrade to Pro — share decks privately, control downloads, hide ads and more …

生成AIを活用したソフトウェア開発ライフサイクル変革の現在値

 生成AIを活用したソフトウェア開発ライフサイクル変革の現在値

多くの現場で生成AIを活用したソフトウェア開発への利用が始まっています。
さまざまな開発現場の変革の状況、それらを受けて私個人の現時点での考えをまとめてみました。
本スライドは、Microsoft AI Co-innovation Labが主宰したイベント「AI駆動開発最前線」の登壇資料です。
https://kobelab.connpass.com/event/379337/

Avatar for Hiroyuki Mori

Hiroyuki Mori PRO

February 01, 2026
Tweet

Other Decks in Programming

Transcript

  1. ©2026 Avanade Inc. All Rights Reserved. 1 ©2026 Avanade Inc.

    All Rights Reserved. 生成AIを活用した ソフトウェア開発ライフサイクル変革の現在地 アバナード株式会社 Client Solutions - Cloud & AI GenAI with SDLC & AO Team Lead – Director 森 博之 (Microsoft MVP – Developer Technologies, AI Services) ©2026 Avanade Inc. All Rights Reserved. <Highly Confidential>
  2. ©2026 Avanade Inc. All Rights Reserved. 2 Client Solutions –

    Cloud & AI GenAI with SDLC & AO Lead Director 職務要約 経歴 主要プロジェクトの経験 • Microsoft技術、特に.NET/C#の開発支援、アークテクト、プロジェクト リード、セミナースピーカーなどの業務に従事。 • 書籍、雑誌、Web記事などの執筆を行う。 • Visual Studio Code – Japanese Extension Contributor もり ひろゆき 森 博之 .NETが登場した2000年よりC#, .NET Frameworkを専門にクライアントアプリ、 Webアプリ、クラウドアプリとさまざまなアプリケーション開発技術を取り扱っておりま した。 Azureに関しても2007年よりトレーニング開発を担当し、その後Azure PaaS を利用したIoT SaaS, LMS SaaS, GenAI Chat SaaSといったプロダクトのマネー ジャーとして開発・運用チームをリードしておりました。 アピールポイント 専門分野 • .NETアプリケーション開発 • Azureマイグレーション支援 • SaaSプロダクトマネージメント • DevOpsプロジェクトリード • トレーニングコンテンツ作成 ▪保有資格(Certifications) • Azure Fundamentals(AZ-900) • Azure Administrator Associate(AZ-103) • Azure Developer Associate(AZ-200) • Azure DevOps Engineer Expert(AZ-400) • Azure Solution Architect Expert(AZ-303,304) • Azure IoT Developer Specialty(AZ-220) • Azure Data Fundamentals(DP-900) • Azure Data Engineer Associate(DP-201) • Azure AI Fundamentals(AI-900) • Azure AI Engineer Associate(AI-100) • Microsoft MVP – Developer Technologies, Azure AI Services(2007-2026) アプリケーション開発コンサルティング ✓ECパッケージのアーキテクチャ設計、基盤設計、開発 ✓Azure DevOps 導入支援 ✓GitHub Enterprise / GitHub Copilot 導入支援 ✓医療パッケージアーキテクチャ設計、チームリード ✓オンラインLMSサービス プロダクトマネージ クラウドサービス プロダクトマネージメント ✓IoT Platform Cloud Service ✓Learning Management System Cloud Service ✓生成AI Chat Cloud Service Azure マイグレーションコンサルティング ✓PaaSベースアプリケーション開発支援 ✓生成AIを利用したRAGチャット開発支援 ✓Azure Cloud Adoption Frameworkトレーニング ✓Azure PaaS開発入門トレーニング Microsoft主催イベント・トレーニング登壇 ✓Microsoft Innovation Center主催トレーニング ✓Microsoft Insider Dev Tour 2018 ✓.NET Conf 2019 ✓AWS Dev Day 2019 ✓Insider Dev Tour 2019 ✓Microsoft AI Tour 2024 ✓.NET Conf 2020, 2022, 2023, 2024, 2025 自己紹介
  3. ©2026 Avanade Inc. All Rights Reserved. 3 Event name and

    date 生成AIによるSDLCの変化 SDLCの構造変革 フェーズ別ユースケース AI適用のポイント Today’s agenda 生成AIを活用したSDLC変革の現在地 01 02 Autonomous Operations 自立化した開発・運用 AI開発のKPI AI時代の評価基準 03 04
  4. ©2026 Avanade Inc. All Rights Reserved. 4 Key Insight: 生産性向上は「結果」であって「目的」にすると本質を見誤る。構造変化への適応が先決。

    よくある誤解 AIを「賢いアシスタント」として矮小化 「生産性が◯倍になるツール」 既存の書き方をそのままに、速度だけ上げようとする 「優秀なアシスタントが増えた」 人が主体で、AIを下請けとして使う発想 「人の置き換え」 コスト削減の文脈だけで語られる導入 この前提では、投資対効果はすぐに頭打ちになる 本質的な現実 開発プロセスの「構造」そのものが変化 「開発の単位」の変化 関数単位から、機能・ワークフロー単位の生成へ 「意思決定速度」の変化 作ってから考えるループの超高速回転 「Agentic Coding」 AIが提案・実行・修正を自律的に行うループ構造 変わったのは「効率」ではなく ソフトウェアの作り方そのもの よくある誤解:生成AI=生産性ツール?
  5. ©2026 Avanade Inc. All Rights Reserved. 5 生成AIは「どこまで」SDLCを変えたのか プログラミングの姿の変化 •

    Tim O‘Reilly › 「The end of programming as we know it」 • Karpathy › 「Vibe Coding」 本質的な変化 変わったのは効率ではなく • 開発の単位 • 意思決定の速度
  6. ©2026 Avanade Inc. All Rights Reserved. 6 SDLC全体で起きている構造変化 従来SDLCの前提 •

    人間中心のプロセス • 人が考え、人がコードを書き、人がテストを行い、人が最終的な品質を保証する。 • 直線的なフェーズの流れ • 各フェーズは原則として順番に実行。 • ドキュメント重視 • 各フェーズの成果物として、詳細なドキュメントが作成される。 • 専門性の高い人材 • 各フェーズには、それぞれの専門知識を持つ人材が配置される。 • 変更への抵抗 • 一度決定された要件や設計は、原則として変更されにくいという前提がある。
  7. ©2026 Avanade Inc. All Rights Reserved. 7 生成AI前提のソフトウェア開発ライフサイクルの特徴 AIによる提案・生成・レ ビュー

    生成AIは、要件定義から テストまでの各フェーズで、 提案・生成・レビューを同 時並行に実行し、開発プロ セス全体を加速させる。 高速なプロトタイピング AIによるコード生成により、 短時間で試作と検証を繰 り返せるようになり、早期 フィードバックを前提とした 開発が可能になる。 継続的な学習と改善 開発中に得られるデータを AIが学習し、次の開発に 知見を還元することで、効 率と品質が継続的に向上 する。 人間の役割の変化 人は「実装者」からビュー・ 判断・設計に責任を持つ 役割へシフトし、創造的・ 高度な課題解決に集中で きる。 ドキュメントの自動生成 コードや設計情報からAIが ドキュメントを生成し、作成 コストを削減しつつ常に最 新状態を維持できる。
  8. ©2026 Avanade Inc. All Rights Reserved. 8 上流(企画・要件定義) 上流でのAI活用は、「意思決定の質」を高めるための前処理に特化させる 効く領域

    High Impact 効きにくい領域 Limitations 要件の言語化・構造化 曖昧なメモから仕様書形式への変換 抜け漏れ・矛盾の検知 「Aの場合はどうなる?」の異常系指摘 想定外ケースの洗い出し 人間がバイアスで見落とすエッジケース 事業判断そのもの 「何を作るべきか」の価値判断 トレードオフの最終決断 納期 vs 品質などの責任を伴う選択 文脈のないゼロイチ 前提情報ゼロからの「いい感じの企画」 活用のポイント Strategic Focus AIは「思考」を代替しない AIは壁打ち相手であり、決定者ではない。 問いを投げかけ、思考の解像度を上げるための「ブース ター」として配置する。 思考の粒度を揃える装置 バラバラな要件メモを、開発可能な 「構造化データ」へ変換させる役割が最も効果的。
  9. ©2026 Avanade Inc. All Rights Reserved. 9 設計・実装 実装フェーズでは、非決定性を許容し、自動化ガードレールの中でAIを遊ばせる設計にする 効く領域

    High Impact 効きにくい領域 Limitations アーキテクチャ選択肢の提示 「松・竹・梅」案を比較し、トレードオフを可視化 既存コードの理解・要約 ブラックボックス化したレガシーコードの解析 ボイラープレート生成 設定ファイルや定型テストコードの爆速作成 文脈のない丸投げ生成 依存関係を無視した「いい感じに作って」は破綻する 「正解が一つ」の思考停止 AIの出力コードを理解せずコピペする実装姿勢 超巨大コンテキストの保持 プロジェクト全体の隠れた仕様を全て記憶しきれない 活用のポイント Strategic Focus 非決定性は「バグ」ではなく「仕様」 LLMのハルシネーション(揺らぎ)は、多様な解決策を探 索する源泉。 これを消し去ると、AIの創造的良さも失われる。 ガードレールで制御する 「間違えないAI」を作るのではなく、「間違ってもテストやLint で即検知できる」環境を用意し、その中で自由に書かせる。
  10. ©2026 Avanade Inc. All Rights Reserved. 10 テスト・運用 テスト・運用フェーズは、コストセンターから「品質と知見の発生源」へと役割を変える 効く領域

    High Impact 効きにくい領域 Limitations テスト観点の網羅 異常系・境界値・セキュリティ観点の自動生成 障害対応の初動支援 膨大なログからの原因切り分けと仮説提示 インシデント要約・報告 時系列での事象整理とドキュメント化 最終責任の判断 「サービスを停止すべきか」の経営的決断 未知の事象への完全対応 学習データにない新規パターンの推論限界 倫理・法的リスクの判定 コンテキストに依存する微妙な判断 活用のポイント Strategic Focus 運用知を「開発」へ還流させる 障害対応で得た知見を、単なる報告書で終わらせず、 次回のテストケースや設計ガードレールへ即座に反映するルー プを作る。 AI自身を監視する仕組み AIによる自動対応(AO)には、必ず別の監視AIまたは人 間による評価プロセスを噛ませる。
  11. ©2026 Avanade Inc. All Rights Reserved. 11 アーキテクチャと品質保証 これまで以上に品質管理・テスト自動化の重要性が増する 適応度関数(進化的アーキテクチャ)

    • アーキテクチャが意図した特性・制約を満たしていくかを自動かつ継続的に評価するための仕組み • 以下のような問題を解決 • アーキテクチャ決定が暗黙知になりがち • 時間の経過とともに意図せず劣化(アーキテクチャ侵食) • 「守られているかどうか」がレビュー頼み ADL (Architecture Definition Language) • Architecture as a Code • コードによるアーキテクチャ表現 • アーキテクチャ違反の自動検出が容易になる未来が予想される メトリックスハック対策 • AIだけでは単一指標をハックしやすい(グッドハートの法則) • 複数のメトリクスを牽制しやすいよう配置する 例)カバレッジとコード行数比率
  12. ©2026 Avanade Inc. All Rights Reserved. 12 顕在化した課題 The 70%

    Problem 「ほぼ完成」に見えるが、実用化までの残り3割が指数関数的に 難しい。 Last 30% Review, Fix, Integration High Cost & Time First 70% Draft Generation Instant (Seconds) Easy 「動くけど本番に出せないコード」が量産される構造 The "AI Slop" Bottleneck 粗い生成物(AI Slop)が後工程に流れ込み、レビューコストが爆発する Flood of Code Rework Cost AI Slop (AIスロップ) のリスク Hard AI Generation Mass Production Draft Draft Draft Draft Human Review 認知負荷の限界 幻覚(Hallucination)チェック Release Slow Output Final 品質の低い生成物が大量に流れることで、レビュー担当者が疲弊し、結果として全体の開発生産性が下がる現象。 「後工程へのコスト転嫁」が起きている。 生成速度ではなく「検証・修正プロセスの自律化」に投資しないと破綻する
  13. ©2026 Avanade Inc. All Rights Reserved. 13 人は「作業者」か「意思決定者」か 自動化が進むほど、人の仕事は「作業」から「判断」へ進化されなければならない GenAI

    Adoption 導入初期 意思決定者・設計者へシフト AIを「部下」として扱い、成果物の定義と評価基準の設計に注力する。 プロセス設計:どう作るかをAIに指示 評価基準策定:何が正解かを定義 リスク判断:最終的な責任を負う RECOMMENDE D Fixing Architecting
  14. ©2026 Avanade Inc. All Rights Reserved. 14 Autonomous Operations 単なる自動化ではなく、「自立化の度合い」を設計し、運用知を開発へ環流させる構造を作る

    Development 設計・実装・修正 Operations 監視・評価・実行 REAL-TIME FEEDBACK Step 1 Monitoring Step 2 Evaluation Core Guardrails Goal Auto-fix
  15. ©2026 Avanade Inc. All Rights Reserved. 15 組織設計へ:人・プロセス・技術の再配線 組織の形が、AIのパフォーマンスの上限を決める(逆コンウェイの法則) 「ツール導入」ではなく

    「ワークフローの再配線」が主目的 逆引き設計のアプローチ 推奨(逆引き) 1. AI前提の理想プロセスを描く 2. それに必要な技術を導入する 3. それを回せる人・評価を定義する People & Organization 人材・役割・評価制度 Role Shift 作業者 設計・レビュアー Incentive コード量 ビジネスインパクト AI-Native Process 開発フロー・意思決定ループ Workflow Vibe Coding / Agentic Coding Spec Driven Development Gate Check Auto-Review First START HERE Technology & Platform 開発基盤・評価環境・データ Tools IDE/Editor Agentic IDE Foundation CI/CD Eval Platform
  16. ©2026 Avanade Inc. All Rights Reserved. 16 ガバナンスと人材育成:スピードとリスクの両立 ガードレールは「止めるため」ではなく、「最高速度で走るため」にある ガバナンスの転換

    「止めるための審査」から、「走り続けるためのガードレール(自動チェ ック・モニタリング)」へ役割を変える。 人材育成の3本柱 1. AIリテラシーとリスク理解 2. プロンプトエンジニアリング 要件を「指示」に落とし込む言語化能力の強化 3. レビュー・評価能力 書く力より「間違いを見抜く力」を最優先で評価する Gatekeeper Guardrails Governance / Risk Control Development Speed 過剰管理 従来型プロセス 承認待ちでAIの速度が死ぬ IDEAL 高速なガードレール 自動化されたポリシー 事後監査・監視の強化 停滞・旧式 AI未導入 リスクも低いが価値もない Shadow IT / Chaos 野良AIの乱立 情報漏洩・著作権侵害リスク 「何が危ないか」を肌感覚で理解させる(ハルシネーション・データ漏洩)
  17. ©2026 Avanade Inc. All Rights Reserved. 17 PoCを超える条件 業務フロー再配線の有無 TRAP

    1 Tool Fatigue ツール疲れ 高機能なAIツールは導入したが、使い方が現場任せ。 「また新しいツールか」と現場が疲弊し定着しない。 GOAL Production Ready 本番展開・スケール 評価基盤による品質保証 AI前提のワークフロー START PoC Loop 検証止まり 「すごいね」で終わる段階。 個人のデスクトップ芸の域を出ていない。 TRAP 2 Risk / Chaos 品質担保不能 プロセスだけ変えたが、AIの品質を測る物差しがない。 事故やハルシネーションを見逃すリスク。 PoCの壁を超えるには 評価基盤 (Evaluation) プロセス再配線 (Redesign) KEY TAKEAWAY 「なんとなく良さそう」を脱却する。 Unit Test for AI, LLM-as-a-Judge等の導入 人の役割を変える意思決定をする。 「作る」から「設計・レビュー」へのシフト 片方だけでは「疲れ」か「事故」を招く。 技術とプロセスの同時更新が不可欠。
  18. ©2026 Avanade Inc. All Rights Reserved. 18 分水嶺:超えた企業/超えられない企業 成功の鍵は技術力そのものよりも、「評価設計」「ガバナンス」「役割再定義」の3点セットにある。 PoC止まりの企業

    「部分最適の積み上げ」に終始 ツールの個別導入 IDEに入れるだけ、チャットボットを置くだけ 属人的プロンプト技術 一部のエースエンジニアだけが使いこなす状態 レビュー渋滞 AIの出力過多に対して、人が目視確認で詰まる PoC乱立 評価基準がなく「なんとなく便利」で終わる 壁を超えた企業 「全体再配線の決断」を実行 定量的評価基盤の確立 生成コードの質と速度を計測し、モデルを継続改善 テンプレートとガードレール 誰が使っても一定品質になる仕組みを実装 役割定義のシフト 「書く人」から「設計・判断する人」へ評価を変更 運用知の還流ループ 本番のログやエラーが、次の開発の文脈になる
  19. ©2026 Avanade Inc. All Rights Reserved. 19 最初に再設計すべき指標 1. 意思決定リードタイム

    2. フィードバックループ回転数 3. 再作業率 4. AI介在率 × 人の判断介在率 5. 初動検知率 AI時代のSDLCにおける評価指標(KPI) 優先度を下げるべき指標 1. 単純な生産性(ステップ数・チケット消化 数) 2. 個人ベロシティ 3. AI生成コード量
  20. ©2026 Avanade Inc. All Rights Reserved. <Restricted> 20 意思決定リードタイム(Decision Lead

    Time) 定義 課題・要求が発生してから、 「方針が決まり、次の行動に移るまで」 にかかる時 間 なぜ? • AI導入で「作る速さ」はほぼ自動的に縮む • それでも詰まるのは • 要件の確定 • 設計判断 • Go / No-Go ボトルネックは人の判断速度
  21. ©2026 Avanade Inc. All Rights Reserved. <Restricted> 21 フィードバックループの回転数 定義

    仮説 → 生成 → 検証 → 修正 この1サイクルがどれだけ短時間・高頻度で回って いるか なぜ? • AI時代の価値は「正解を早く作る」ことではな い • 間違いに早く気づける構造を持っているか 失敗回数が増えるのは、むしろ健全
  22. ©2026 Avanade Inc. All Rights Reserved. <Restricted> 22 再作業率(Rework Ratio)

    定義 AI生成・人手実装を問わず、 後工程で「やり直し」になった割合か なぜ? • AI導入初期はアウトプット量が急増する • 問題は: • どれだけ捨てられているか • なぜ捨てられているか 再作業が多い工程 = 設計・判断が曖昧 AIの問題ではなくSDLC設計の問題
  23. ©2026 Avanade Inc. All Rights Reserved. <Restricted> 23 AI介在率 ×

    人の判断介在率 定義 • AIが関与した成果物の割合 • 人が最終判断したポイントの数・位置 なぜ? • 「AIを使っているか」では意味がない • どこで人が責任を持っているかを可視化するた め
  24. ©2026 Avanade Inc. All Rights Reserved. <Restricted> 24 初動検知率 定義

    • 不具合・問題がどれだけ早いフェーズで検知さ れたか なぜ? • AI時代は「欠陥ゼロ」は現実的でも意味も薄 い • 重要なのは早期発見: • 設計段階で気づけたか • 実装前に潰せたか
  25. ©2026 Avanade Inc. All Rights Reserved. 25 生成AIを利用したSDLCで変わったのは 効率ではなく •

    開発の単位 • 意思決定の速度 まとめ 導入時の提言 Avoid ツール導入による部分最適 Action SDLC再配線の決断 「どこにAIを入れるか」ではなく、「AI前提でプロセス全体をどう組 み直すか」という構造変革への投資を決断する。 現場への提言 Avoid 100%の正解生成を期待 Action 検知・修正前提の設計 AIの出力は不完全であることを前提に、それを高速に評価・修 正・統合できるガードレールとパイプラインを構築する。 組織の提言 Avoid 経験則への固執 Action 運用知のループ化と評価 AOにより運用の学びを開発へ即座に戻す。このループを回すた めの「評価設計」こそが、これからのエンジニアの中核スキルとなる 。