AI時代の開発プロセスの枠組み

浅海 智晴 Created: 2026-02-09

AI時代のソフトウェア開発では、「人間が考え、AIが実装する」という役割分担が急速に現実のものになりつつあります。

このとき重要になるのは、AIが何を理解し、何を前提としてコードを生成するのかという点です。

生成AIは、曖昧な仕様や前提の抜けに対して、人間とは異なる形で“それらしく”補完を行います。その結果として、意図しない設計や破壊的な実装が生まれることも少なくありません。

今回から数回に渡って、Unified Process(UP)を補助線として、AI時代における要求・分析・設計・実装のあり方を整理し、プロジェクト管理と開発プロセス (Development Process)をどのように再構成すべきかを考えます。

AI時代のUP

UPは2000年当時のソフトウェア開発の開発プロセスの技術を集大成したものであり、当時としての一つの結論ということができます。

その後のソフトウェア開発の現場での適用では難しい部分もありましたが、UPの技術体系と要素技術について標準技術として確立しているため、開発プロセスの議論を進める上での土台となるものです。

📄 AI時代の開発プロセス考ではUPとアジャイル開発を対比させる形でAI時代のソフトウェア開発プロセスの論点を整理しました。

その結果を踏まえて、今回からUPを補助線にソフトウェア開発の構成要素を具体的に検討していきます。

AI時代における「反復」と「漸進」の再定義

AI時代のソフトウェア開発でも、「反復」と「漸進」が基本となることは変わらないでしょう。

ただし、コードを書く主体が人間からAIへと移りつつある現在、反復や漸進をコード量や機能量の増加だけで捉えることは、もはや十分ではありません。

従来のソフトウェア開発では、反復と漸進は次のように理解されてきました。

  • 反復(Iteration) : 作って・見て・直す、という作業サイクル

  • 漸進(Increment) : 機能や品質が少しずつ増えていくこと

このサイクルでの主な成果物はモデル(要求・分析・設計)とプログラムのコードです。

AI時代にはここに重要な要素が加わります。それは、AIと共有する文脈です。

AI時代の開発では、反復と漸進は次のような意味づけが加わります。

  • 反復 : AIに与える文脈を更新し、再解釈させるループ

  • 漸進 : AIが参照する「前提文脈」が安定・拡張していくこと

AI時代の開発では、AIが参照する前提条件や意味構造がどれだけ安定しているかが生成するプログラムの品質を左右します。

AIが生成したプログラムの品質を向上させ、後戻りしないですむ枠組みを獲得することが本質的に重要です。

フェーズ

UPでは個々のイテレーションの目的や位置付けを明確にするための枠組みとしてフェーズを用意しています。 製品のリリースまでの開発を以下の4つのフェーズに分割して管理します。

  • 構想フェーズ ::プロジェクトで何を検証するのか、どのような問題領域を扱うのかを定め、AIおよび関係者が共有する文脈の輪郭を作るフェーズ

  • 推敲フェーズ ::構想フェーズで得られた文脈を反復的に見直し、曖昧さや矛盾を取り除きながら、AIによる高速生成に耐える前提条件を確定するフェーズ

  • 作成フェーズ ::推敲フェーズで確定した文脈と制約を前提として、AIを活用しながらソフトウェアを実体化していくフェーズ

  • 移行フェーズ ::作成されたソフトウェアを実運用へと移し、利用や運用から得られる知見を回収し、次の構想へとフィードバックするフェーズ

なお、各フェーズでは、イテレーションによって実際に機能の開発を行い検証を行います。

フェーズは、イテレーションの目的や許容範囲を定める枠組みであり、イテレーションは、その枠組みの中で機能を少しずつ作り足していく単位です。

AI時代においてもこの関係は変わりませんが、イテレーションごとに更新される対象として、コードだけでなく、AIと共有する文脈や前提条件が重要な位置を占めるようになります。

構想フェーズ

UPにおける構想フェーズは、プロジェクトの目的やスコープを明確にし、実現可能性や価値を検証するためのフェーズです。

この段階では、詳細な仕様や設計を固めることよりも、

  • 何を作ろうとしているのか

  • なぜそれを作るのか

  • どの範囲までを対象とするのか

といった全体像を関係者間で共有することが重視されます。

構想フェーズは、以降のフェーズに進むための判断材料を揃えるための探索的なフェーズとして位置づけられていました。

AI時代における構想フェーズの役割

AI時代の構想フェーズでは、この役割に加えて、AIと共有する文脈を定義するという新たな意味を持ちます。

このフェーズでは、仕様の完成度よりも文脈の共有を重視します。

AIにとっては、「どの世界について考えてよいのか」を示すフェーズであり、扱う問題領域や用語、前提条件の輪郭を与えることが目的となります。

この段階では、曖昧さや未確定要素の存在を許容しますが、それらがどの文脈に属するものなのかは明確にしておく必要があります。

構想フェーズは、AIが後続フェーズで適切に思考・生成を行うための思考対象領域を限定するフェーズとして、従来以上に重要な役割を担うことになります。

推敲フェーズ

UPにおける推敲フェーズは、構想フェーズで整理した要求や方針をもとに、分析・設計を進めながらシステムの骨格を固めていくフェーズです。

この段階では、イテレーションを回しながら機能を部分的に実装・検証し、曖昧な要求や不整合を洗い出して修正していきます。

推敲フェーズの重要な成果物の一つが、アーキテクチャ・ベースラインです。

アーキテクチャ・ベースラインが固まることで、以降の作成フェーズでは、設計判断を伴わない定型的な実装作業を流れ作業として進めることが可能になります。

このため、作成フェーズでは、プログラマによる物量的な開発が可能になります。

AI時代における推敲フェーズの役割

AI時代の推敲フェーズでは、この役割がさらに重要になります。

推敲フェーズでは、構想フェーズで得られた文脈を反復的に見直し、曖昧さや矛盾を取り除きながら、文脈・境界・前提条件を磨き込みます。

その中心的な成果物が、AIが参照するためのアーキテクチャ・ベースラインです。

アーキテクチャ・ベースラインが確定することで、AIは設計判断を行う必要がなくなり、与えられた構造と制約に従って実装を生成する主体として機能します。

これは、UP時代においてプログラマによる物量的な開発が可能になったのと同じ構造を、AI時代に引き移したものと捉えられます。

推敲フェーズは、AIを高速な実装労働力として安全に活用するための最終的な地盤整備フェーズとして位置づけられます。

作成フェーズ

UPにおける作成フェーズは、推敲フェーズで確定したアーキテクチャ・ベースラインを前提として、物量的にシステムの作成を進めるフェーズです。

この段階では、アーキテクチャや主要な設計判断はすでに固まっており、それらの枠組みに従って、イテレーションを回しながら機能を作り足していきます。

作成フェーズでは、設計上の創意工夫よりも、決められた枠組みを正しく適用することが重視されます。

そのため、一般的なエンジニアが参加しやすく、チームの人数を増やすことで開発速度を上げやすいフェーズとなります。

AI時代における作成フェーズの役割

AI時代の作成フェーズでは、この構造をそのまま引き継ぎつつ、実装主体がAIへと置き換わります。

推敲フェーズで確定したアーキテクチャ・ベースラインの枠組みに従い、AIが大量の実装やテストを生成することで、物量的にシステムの作成を進めます。

このフェーズでは、新たな概念の導入や設計判断は極力行わず、既存の構造や制約を忠実に反映した生成を行います。

AIは、与えられた枠組みを逸脱 (deviation)しない実装主体として機能し、人間は生成結果のレビューや調整に専念します。

このように、作成フェーズは、アーキテクチャ・ベースラインを軸として物量を投入するフェーズであり、その物量の担い手が人間からAIへと移っていくことになります。

移行フェーズ

UPにおける移行フェーズは、作成されたソフトウェアを実運用へと移し、ユーザへの提供や運用開始を行うフェーズです。

この段階では、不具合修正や調整を行いながら、製品を実用に耐える状態へと仕上げていきます。

移行フェーズは、開発から運用への引き渡しを完了させるための最終フェーズとして位置づけられてきました。

AI時代における移行フェーズの役割

AI時代の移行フェーズでは、作成されたソフトウェアを実運用へと移すだけでなく、利用や運用から得られる知見を次の開発サイクルの文脈として回収することが重要な役割となります。

運用中に明らかになる制約や前提のズレ、暗黙に置かれていた判断基準などは、AIが参照すべき新たな文脈情報です。

ここで得られた文脈は、次の構想フェーズへの入力として再利用され、開発は再び反復のループへと入ります。

移行フェーズは、開発の終点ではなく、次の反復を開始するための文脈更新フェーズとして位置づけられます。

移行フェーズにおける各種文脈情報の文書化は旧来の開発に比べて極めて重要な位置付けになるでしょう。

AI開発におけるフェーズ構造と推敲フェーズの意義

ここまで見てきたように、AI時代の開発プロセスでは、構想・推敲・作成・移行という各フェーズを通じて、AIの役割が段階的に変化します。

  • 構想フェーズでは、AIは問題領域を探索し、文脈の輪郭を共有するための対話相手となります。

  • 推敲フェーズでは、AIは文脈やモデルの整合性を確認する支援役として関与し、人間はアーキテクチャ・ベースラインを確定させます。

  • 作成フェーズでは、AIは確定した文脈と枠組みに従って、実装を大量に生成する主体として機能します。

  • 移行フェーズでは、AIは実運用から得られる知見を整理し、次の構想フェーズへと渡す文脈を抽出する役割を担います。

この中で、最も重要な位置を占めるのが推敲フェーズです。

推敲フェーズは、AI時代の開発において、後続フェーズすべての品質と安定性を決定づける中核フェーズです。

作成フェーズは、AIが最も直接的に価値を発揮するフェーズですが、その価値は推敲フェーズの成果を刈り取ることで初めて現実のものとなります。

作成フェーズの意義は、単に人間の実装作業を肩代わりすることではありません。

文脈と前提条件が推敲フェーズで十分に整備されていれば、AIは大量のコードやテストを一貫した品質で生成できます。

その結果、人間は実装作業から解放され、構想や推敲といった文脈設計や検証に集中できるようになります。

つまり、作成フェーズの役割は、推敲フェーズで築かれた地盤の上で物量を投入し、その成果を一気に回収することにあります。

作成フェーズを成立させるための地盤整備

このような作成フェーズは、それ単独では成立しません。

作成フェーズを成立させるためには、その前段として、推敲フェーズにおける地盤整備が不可欠です。

中でも最も重要なのが、アーキテクチャ・ベースラインの確立です。

アーキテクチャ・ベースラインは、システムの構造や責務分割、依存関係といった基本的な枠組みを定めるものであり、AIが参照する思考の地図となります。

この枠組みが推敲フェーズで確定していることで、作成フェーズでは、新たな設計判断を行うことなく、与えられた構造と制約に従って、物量的に実装を積み上げることが可能になります。

これは、UP時代においてアーキテクチャ・ベースラインの確立によって一般的なエンジニアによる物量的な開発が可能になった構造を、AI時代に引き移したものです。

アーキテクチャ・ベースラインは、AIによる生成の境界条件そのものであり、推敲フェーズの成果として、作成フェーズを安全かつ高速に進めるための最重要前提条件だといえます。

まとめ

UPを補助線にして、AI時代のプロジェクト管理と開発プロセスを考えてみました。

AI時代の反復と漸進は、コードを積み上げることではなく、文脈を安定させ、拡張していくことにあります。

フェーズという枠組みは、AIとの対話の文脈を調整し、高速な作成フェーズを成立させるための有効な手段となります。

参照

用語集

UP (Unified Process)

UMLを基盤とし、反復型・ユースケース駆動・アーキテクチャ中心のプロセスモデル。Rational Unified Process (RUP) などの派生形を持ち、CBD(コンポーネント指向開発)の実践基盤となる。

開発プロセス (Development Process)

開発プロセスとは、ソフトウェアの構築・運用・保守に関わる活動全体を指します。 計画、設計、実装、テスト、リリースなどを含み、ソフトウェア開発の一連の流れを体系的に表現する概念です。

構想フェーズ (Inception Phase)

プロジェクトの目的、扱う問題領域、スコープを定め、検証すべき価値や実現可能性を明らかにするフェーズ。AI時代においては、詳細な仕様を確定することよりも、AIと人間が共有すべき文脈の輪郭を定義することが中心的な役割となる。

推敲フェーズ (Elaboration Phase)

構想フェーズで得られた要求や方針をもとに、分析・設計を進めながらシステムの骨格を固めるフェーズ。AI時代においては、曖昧さや矛盾を取り除き、文脈・境界・前提条件を磨き込み、AIが参照するアーキテクチャ・ベースラインを確定することが最重要となる。

移行フェーズ (Transition Phase)

作成されたソフトウェアを実運用へと移行し、ユーザへの提供や運用開始を行うフェーズ。AI時代においては、運用や利用から得られる知見を文脈情報として回収し、次の構想フェーズへ入力するための文脈更新フェーズとして位置づけられる。

逸脱 (deviation)

計算値や観測値が、基準値や真値から外れている状態。観測可能な量的ずれを表す。

バグ (bug)

俗語的にソフトウェアの不具合を指す用語。厳密な技術的定義はなく、Defect や Fault、Failure を広く含む日常的な表現。

妥当性確認 (validation)

Validation(妥当性確認)とは、システムや機能が利用目的や要求仕様に対して妥当であるかを確認する行為である。