powered by TechFeed
表示モード
Deep Dive

AIエージェントが実装を肩代わりするほど、人間の仕事は「計画」と「検証」に集中していく — MicrosoftがSDLCの再設計を提唱

10月27日、Microsoft Command Lineが「The new primitives of agentic software delivery」と題した記事を公開した。AIエージェントがコードを書く時代に、エンジニアの仕事はどこへ向かうのか——この問いに対し、Microsoftは「自律化が進むほど、人間の判断が問われる領域はむしろ明確になる」という構造的な見方を提示している。「エージェントに任せれば速くなる」という楽観論を超えた、SDLC再設計の考え方だ。

10月27日、Microsoft Command Lineが「The new primitives of agentic software delivery」と題した記事を公開した。AIエージェントがコードを書く時代に、エンジニアの仕事はどこへ向かうのか——この問いに対し、Microsoftは「自律化が進むほど、人間の判断が問われる領域はむしろ明確になる」という構造的な見方を提示している。「エージェントに任せれば速くなる」という楽観論を超えた、SDLC再設計の考え方だ。


「AIに任せれば速くなる」は単純すぎる

AIファーストの開発における典型的な語られ方は「インテントを入れればソフトウェアが出てくる」というものだ。だがMicrosoftは、その「間」をブラックボックスのまま扱うことへ警鐘を鳴らす。

記事が指摘する核心は、SDLCの各段階は均等には変わらないという点だ。変化の速度と深度はステージごとに異なり、ボトルネックも移動し続ける。だからこそ「SDLC全体を一気に変革しようとするチームは失敗しやすい」と述べている。何が機能して何が壊れているかを判別できなくなるためだ。

この問題へのアプローチとして記事が提示するのが、プリミティブ(基本要素)への分解だ。各ステージで「誰が何をすべきか(Job to be Done)」と「何を成果物として次へ渡すか」を明確にする。


4ステージの構造と、人間の役割の変化

SDLCの4ステージ(Plan・Build・Verify・Observe)は従来と変わらない。変わるのは、各ステージにおける人間の仕事の中身だ。

ステージ 人間のJob to be Done 成果物
Plan 取り組む問題の選択、曖昧さの解消、トレードオフの判断 ゴールと受け入れ条件
Build 重要な設計判断のガイド、人間的判断が必要な問題の解決 PR(実装候補)+選択の文脈情報
Verify 「作ったものが意図したものか」の判断 システム挙動の監査可能なエビデンス、リリース記録
Observe シグナルの解釈、インサイトの形成、変更のリリース判断 次のゴールとシステム改善に活かせる実データ

エージェントが実装作業を肩代わりするBuildステージに対し、人間の注意がより集中すべきは「検証(Verify)」と「計画(Plan)」だ、というのが記事の見立てだ。コードの正しさの確認はエージェントへ委譲し、人間は「それが本当に意図したものか」という判断に集中する。

この変化はエンジニアのスキルセットにも影響を与える。Buildステージでの実装作業が自動化されていく一方で、要件定義の精度を上げる能力・エージェントの出力を批判的に検証する能力・本番シグナルからインサイトを引き出す能力が、現場エンジニアにとってより重要になっていく。「コードを速く書く」から「正しいものを判断する」へ、求められる技能の重心が移動しつつある。


中心に置かれる「知識レイヤー」

従来のSDLCでは、プロダクトに関する知識の多くは個々の開発者の頭の中に蓄積されていた。スタートアップなら一人の人間が、顧客ニーズ・設計判断・実装・リリース・運用をつなぐ接着剤になっていた。チームとプロダクトが成長するにつれ、その知識は断片化する。

新しいSDLCでは、この役割を担うのが共有の知識レイヤーだ。ゴール、設計判断の文脈、バリデーションのエビデンス、リリース履歴、本番環境のシグナル、エージェントの行動ログ——これらをすべてつなぐ基盤として機能する。

記事はこのレイヤーを「メモリ」と表現している。重要なのは、生データの量ではなく、エージェントが特定の問いに答えられるかどうかだ。「このメモリがあるエージェントは、ないエージェントよりも仕事をうまくこなせるか?」というエンジニアリング上のテストが評価基準になる。データベースのインデックスやマテリアライズドビューに近い発想だと記事は述べている。


Microsoftが実際に構築しているもの

理論の話だけでなく、記事はMicrosoftが現時点でこれらのプリミティブをどう製品に落とし込んでいるかも示している。

  • GitHub Copilot:Issueを受け取り、セキュアなGitHub Actions環境でリポジトリを分析・コード変更・バリデーションを実行し、レビュー用のドラフトPRを生成する。GitHub、VS Code、モバイルなど複数のサーフェスから委譲できる。
  • Copilot Code Review:エージェントスキルとMCP(Model Context Protocol)をサポート。IssueトラッカーやドキュメントなどThe外部システムのコンテキストをレビューに直接持ち込める。
  • Copilotハーネス:命令・スクリプト・サポートリソースを再利用可能なスキルとしてパッケージ化。個別のエージェントセッションに埋もれていた「うまくいったやり方」を、再利用可能な資産として組織に残せる。

自律化しても構造は消えない

記事が最後に強調する点は、自動化が進んでもSDLCの構造的責任は消えないということだ。人間の介入なしにループが回り続けるシステムであっても、ゴールの定義・実装・バリデーション・ユーザーへの到達・実績からの学習——これらは必要であり続ける。

「自律性はその構造を除去しない」という一文は、エージェント開発に夢を見すぎているチームへの現実的なメッセージだ。

近い将来に人間の判断がもっとも求められるのはVerify・Observe・Planの3領域だと記事は述べている。エージェントが「ゴールを達成できるか」は問えても、「そのゴール自体が追求に値したか」は人間の判断に委ねられるためだ。


詳細はThe new primitives of agentic software deliveryを参照していただきたい。