※本記事の作成にはM365 Copilot及びGitHub Copilotを利用しています。

注意 : 本記事の内容は筆者個人の見解であり、所属企業の見解ではありません。

はじめに

この1年でソフトウェア開発のやり方が大きく変わってきています。AIにコードを書かせて人間はその確認をするやり方が広まっており、AI駆動開発やVibe Codingなどと呼ばれる手法が注目されています。本記事ではそのような開発の考え方を「AIネイティブ」と呼び、そのAIネイティブな考えに基づく開発プロセスを「AIネイティブプロセス」と呼んでいます。

一方、エンタープライズ領域では開発プロセス（※本記事では、「どの工程で」「何を入力にして」「どんな作業をして」「何を作成するのか？」をまとめたものを開発プロセスとしています）をしっかり決めて、それに沿って大人数のプロジェクト体制を整えて進めることが一般的かと思います。そのためのプロセス標準が定義されることが多くあります。
※【宣伝】下記は東芝デジタルソリューションズのプロセス標準についての記事です。よろしければこちらもご覧ください。https://www.global.toshiba/jp/company/digitalsolution/articles/tsoul/solution/s017.html

本記事では、AIネイティブな開発になった場合に、そのプロセス標準はどうなっていくのかを調査した結果とその感想をまとめました。

調査方法

調査の背景

AI技術の進化は日進月歩であり、関連する情報は膨大かつ常に更新されています。そのため、従来の手法で体系的な調査を行うことが困難になってきています。

採用したアプローチ

本調査では、Microsoft 365（M365） Copilotのリサーチツールを活用しました。

M365 Copilot リサーチツールの概要

M365 Copilotのリサーチツールは、以下の特徴を持つAI支援型の調査ツールです:

情報の自動収集: Web上の最新情報を自動的に検索・収集
要約と整理: 収集した情報を自動的に要約し、構造化されたフォーマットで提示
信頼性の確保: 情報源を明示し、引用元を追跡可能
継続的な更新: 常に最新の情報にアクセスし、トレンドの変化を把握

このツールを使用することで、情報の洪水の中から必要な知見を効率的に抽出し、AIネイティブな開発プロセスの全体像を把握することができます。
通常のCopilotと同様に対話形式で調査をお願いすると、調査の観点などを尋ねてきます。それに回答することで調査内容を具体化して、あとはリサーチツールが勝手に情報をまとめてくれます。大体10分から15分ぐらい待てば終わります。

情報ソースはWebサイトだけでなく、Sharepointやメール等のリソースを含めることもできます。今回は一般に出回っている情報のみを対象とするため、ソースはWebサイトのみとしました。

リサーチツールの詳細については以下を参照してください。
https://techcommunity.microsoft.com/blog/microsoft365copilotblog/researcher-agent-in-microsoft-365-copilot/4397186
なお、今回の調査は11月25日に実施しており、リサーチツールの機能はその時点のものとなります。

調査結果

リサーチツールへのインプット

まずは以下のプロンプトでリサーチツールに調査を依頼してみました。「AIネイティブ」はスタンダードな用語ではないので「AI中心」と表現してみました。

AI駆動開発やVibe Codingといった言葉で示されるような、AIにソフトウェア開発を任せて人間は確認のみを行う開発手法が広まっています。
私はそのような開発手法をエンタープライズのシステム開発PJに適用するための標準プロセスを検討しています。
以下の内容を調査してください。

・AI中心の開発によって、エンタープライズのシステム開発PJのプロセスがどのように変化するか？
　以下の観点で情報をまとめてください
　- 人とAIの役割分担
　- 開発工程の変化
　- 工程毎の成果物の変化
　- 工程ごとの作業内容の変化
・大規模なシステム開発にAI中心の開発が適用可能か？
・既存システムの更新に、AI中心の開発を適用可能か？

すると、リサーチツールは以下の質問を返してきました。

ありがとうございます。AI駆動開発やVibe Codingのような、人間が確認のみを行いAIが主導する開発手法をエンタープライズのシステム開発プロジェクトに適用するための標準プロセスを検討されているとのことですね。
調査に入る前に、以下の点について確認させてください：

「Vibe Coding」は社内用語でしょうか？それとも一般的なAI開発手法の一種でしょうか？（社内で特定の意味がある場合は、その定義を把握したいです）
「エンタープライズのシステム開発PJ」とは、特定の業種や規模、社内の開発プロジェクトを指していますか？それとも一般的な大規模業務システム開発を想定されていますか？
「標準プロセス」としてまとめる際、社内展開を目的としたガイドラインやテンプレートのような形式を想定されていますか？それとも外部事例の調査が中心でしょうか？

ご回答いただければ、すぐに調査を開始できます。「このまま進めてください」とおっしゃっていただければ、私の判断で調査を開始します。

今回は敢えて「このまま進めて下さい」としてみます。調査の観点がはっきり決まっている場合は、このような提案に具体的に回答すると良いです。

上記の質問に回答し、Copilotから再質問が無ければ調査が始まります。

リサーチツールによる調査レポート

調査開始後10分程度でリサーチツールが「AI駆動開発（Vibe Coding）によるエンタープライズ開発プロセスの変化と適用性」というタイトルのレポートを出してくれました。pdfで8頁分ぐらいありました。
全てをここで紹介するには量が多すぎるのでM365 Copilotに要約してもらいました。最初はシンプルに「要約してください」と頼んだところあっさりしすぎていたので「倍ぐらいの文量でやり直してください」とお願いしました。その結果が以下になります。

AI駆動開発（Vibe Coding）によるエンタープライズ開発プロセスの変化と適用性

1. 人とAIの役割分担の再定義

AI中心開発では、AIがコードやテストの自動生成、ドキュメントのドラフト作成など実装作業の大部分を担います。一方、人間は要件提示、レビュー、修正指示、品質保証などの監督役に集中します。
AIは「ジュニア開発者」のように手を動かし、人間は「リードエンジニア」としてプロジェクト全体の方向性や品質を管理します¹。
この分担により、人間は創造性や意図の伝達、優先度判断、例外ケースの検討など、AIでは難しい領域に注力できます。AIは反復作業やパターン認識に長けており、コード生成やテストケース作成を高速でこなします。

2. 開発工程の変化

従来の「要件定義→設計→実装→テスト→リリース」という段階的工程は、AIと人間のペア作業による短い反復サイクルに変化します。AWSのAI-DLCでは、従来の数週間のスプリントを「ボルト」と称する数日または数時間単位の開発サイクルに置き換えています¹。
このサイクルにより、要件定義直後にプロトタイプ実装とフィードバック取得が可能になり、計画と検証を同時並行で進める開発が実現します。
さらに、チーム全員がAIとの対話にリアルタイム参加する「モブエラボレーション」「モブコンストラクション」といったコラボレーションが増え、従来のドキュメントベースの引き継ぎよりもインタラクティブな意思疎通が重視されます。

品質確保も「シフトレフト」へ移行し、要件定義や設計段階からセキュリティ・コンプライアンス・アクセシビリティのチェックをAIが自動化します。GitHubの企業向けAIでは、リポジトリ全体のセキュリティガイドラインを設定し、コードが常にポリシー準拠になるようリアルタイムチェックする機能も提供されています¹。

3. 成果物の変化

AIは要件定義書や設計書を自動生成し、コードとテストを一体で出力します。コード生成時にはテストコードやコメントも同時に生成されるため、動くコード一式と検証一式がセットで生み出されます²。
さらに、AIに望ましい成果を出させるためのプロンプト設計書やAI用ルール集（例：PROMPT_RULES.md）も新たな成果物となります。レビューや議論の履歴も重要なナレッジとして保存され、将来の保守や監査の際にAI生成コードの根拠を示す付加情報として活用されます。

成果物同士が密接にリンクした状態（要件⇔設計⇔コード⇔テストのトレーサビリティが高い状態）を実現しやすくなり、変更が発生してもAIが関連成果物を素早く更新できるため、ドキュメントと実装の乖離が減り、一貫性のあるプロジェクト管理が期待できます²。

4. 品質・セキュリティ確保のためのガバナンス

大規模開発では、ガードレール（開発規約、レビュー体制、AI利用のガバナンス等）の整備が不可欠です。コードの機密情報流出防止やライブラリ利用のライセンス制限、セキュリティポリシー遵守などをAIにも徹底させる仕組みが必要です³。
CIパイプラインに静的解析やセキュリティスキャンを組み込み、品質ゲートを設けることが推奨されています。AI生成コードは初見ではバグや逸脱に気づきにくいため、厳格な品質チェックプロセスを通す必要があります。

最終的な責任は人間にあり、特に本番影響が大きい大規模システムではシニアエンジニアのコードレビューと承認プロセスが必須です。AIは「なぜこのコードを書いたか」を説明できるため、レビューアはそれを参考に意図通りか検証します³。

5. 開発文化・用語の再構築

AWSのAI-DLCでは、スプリントを「ボルト」、エピックを「ユニット」と呼ぶなど、新しい用語やプラクティスを導入し、AI時代の高速開発に対応しています¹。
AI活用前提のツールチェーン統合やAIリテラシー教育、ナレッジ共有も重要です。AIを使いこなせるスキル（プロンプト設計やAI出力の評価能力）を持つ人材の育成や、AIによって下支えされる上級エンジニアの需要増にも対応する必要があります³。

6. 既存システム（レガシー）のモダナイズ

AIはレガシーコードのラッピングや段階的置換、コード変換・リファクタリングを支援します。古いCOBOLモジュールをそのまま呼び出せるようにREST APIを作ってと指示すれば、AIが必要なラッパーコードを出力します³。
また、テストやCI/CDパイプラインの後付けもAIで可能となり、現代的な開発環境を構築できます。AIは言語間のコード翻訳や複雑なコードのリファクタリングも得意で、古いVB6やCOBOLのコードを最新のJavaやPythonに書き換えることができます³。

ただし、AIは表面的なコード変換や生成支援しかできないため、レガシー特有の隠れた意図や業務知識は人間が補完する必要があります。人間が舵を取り、AIが手を動かす体制が推奨されます³。

7. 効果と展望

AI中心開発は、生産性20～30%向上や市場投入までの時間短縮が期待されます³。
ただし、AIが生成した新しいコードも将来のレガシーになり得るため、アーキテクチャの整合性やコード品質に関する人間のチェックは継続的に必要です。
今後、AI前提の工程再設計が標準プロセスとして確立されることが予想されます。

出典

¹ https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/
² https://qiita.com/softbase/items/a51a84cf3fa94226aa0e
³ https://www.prmworks.com/blog/vibe-coding-enterprise/

調査結果に対する考察

まずリサーチツールによる調査結果がどこまで正しいのかを気にする必要があります。ただ、出典が明記されていることと私個人の前提知識と相違が無かったことを踏まえ、内容が正しい前提で考察しました。
考察については調査結果の要約で示されている7つの観点に分けて実施しました。

1. 人とAIの役割分担の再定義について

AIが「ジュニア開発者」、人間が「リードエンジニア」と説明されていますが、個人的にはAIネイティブな開発ではAIがより「リードエンジニア」に寄るイメージを持っています。リサーチツールへの指示がちょっと悪かったかもしれません。
いずれにせよ、指示された開発作業を淡々とこなすエンジニアは淘汰されると予想されます。ただ、プロセス定義の観点においては、人間がやるべき作業がAIに置き換わっただけで検討すべきことは変わらないのかもしれません。

2. 開発工程の変化について

よくあるアジャイル開発だと1週間から1か月の反復サイクルが一般的かと思いますが、この期間が大きく短縮される印象です。
また、コラボレーション手法も提案されています。ドキュメントよりもインタラクティブな意思疎通というとペアプロ、モブプロが連想されますが、人間と違っていつも近くにいてくれるのでそのようなコミュニケーションが効果的になるのだと感じました。
品質確保をAIが自動化するというのも重要な観点です。なるべく人の目で確認したいところですがそれがボトルネックになってもいけません。人が最低限確認しなければならないラインを定めることがプロセス定義の観点では重要になりそうです。

3. 成果物の変化について

AIを安全かつ効果的に活用するための新たな成果物が発生する点は留意したいです。AIは作業能力がとんでもなく高いので指示やルールを細かくしないとあっという間に暴走してしまうわけですね。

4. 品質・セキュリティ確保のためのガバナンスについて

前半は3. 成果物の変化と共通の内容かと思いました。より細かい内容が書かれているので必要な成果物を検討する際に参考にすべき内容と感じました。
コードレビューと承認プロセスはシニアエンジニアの確認が必須とありますが、コードレビューは何かしらの手段で効率化しないとボトルネックになりそうです。「AIに説明させる」というのは一つのヒントになりそうですね。

5. 開発文化・用語の再構築について

AIネイティブな開発でなくても開発プロセスや利用ツールの教育は必要ですが、AIネイティブな開発は既存の開発とのギャップが大きいのでより重要ということかと思います。
ウォーターフォールに慣れた技術者がアジャイルを実践すると意識の面でギャップが生じることがあります。AIネイティブな開発に移行していく際にも同様のことが起こりそうですね。

6. 既存システム（レガシー）のモダナイズについて

冒頭でAI中心の開発手法が有効とされつつも、末尾にAIは表面的な支援のみでありレガシー特有の部分は人間が補完する必要ありとの記述があります。ブラックボックス化されたレガシーシステムの内部を理解するのはAIの力をもってしても容易ではないようですね。レガシーなシステムこそ我々の様な旧来のメーカー・SIerの力が生かせるところであるといえそうです。
非AIでのモダナイゼーションプロセスを、AIを効果的に活用できるような形に作り替えていくことが求められそうです。

7. 効果と展望について

「AIが生成したコードや構造自体も将来のレガシーになり得る」は強く留意したいポイントですね。AIネイティブな開発プロセスにおいてもレガシーにならないような仕組みが必要になりそうです。そのための詳細な仕様・ルールの定義、AIとの議論の記録、効率的なレビューの仕組みなどを具体的に定義する必要があると感じました。

感想

調査結果全体への感想

AIネイティブな開発になることでAIに任せられることが増えて人の作業は省力化される印象ですが、プロセスに関してはむしろ定義すべき内容が多く細かくなりそうな印象です。
人の作業であればその場の判断で何とかなるであろう部分がAIの場合は簡単に暴走してしまうので、AIに対して正確かつ詳細な指示が必要になりますね。
さらに気になる部分として、今回の調査では触れられていませんがAI自体も継続的に進化していく点があります。現時点の調査結果を基にプロセスを定義したとしても半年後には陳腐化してしまう可能性もあります。実際、現在のようにAIエージェントがソフトウェア開発を席捲している状況を1年前は想像できていなかったわけでして。
そういう意味ではプロセスもある地点の標準を作るのではなく、進化する前提で定義する必要があるのかもしれません。

リサーチツールへの感想

ちょっとした会話だけで非常に多くの有益な情報をまとめてくれるので、技術動向などを調べるにはとても便利だと思います。

学び続けないとあっという間に置いて行かれる昨今ですが、学び方もどんどんブラッシュアップする必要があると感じます。今回はリサーチツールに調べてほしい情報を与えてまとめてもらいましたが、上手く工夫すれば自分のタスクを読み取って自動的に欲しい情報を先回りでまとめてくれるようになるのではないかと思います。
今後の発展に期待です。