AIを活用した
システム開発の4方式

01 / Purpose本書の目的

生成AIをシステム開発に導入する際、「どのAIツールを使うか」だけを議論しても、実際の役割、責任、品質保証、必要人材は定まりません。本書は、AI活用を主たる作業者と適用範囲の違いから4つの方式に整理し、導入判断と体制設計に使える共通言語を提供します。

対象は、経営者、事業責任者、情報システム部門、開発責任者、PM・PMO、エンジニア、AI導入支援者です。新規開発だけでなく、既存システムの解析、改修、移行、文書化、テスト、保守にも適用できます。

目的別の読み方

02 / Executive summaryエグゼクティブサマリー

結論

4方式は、AI活用の熟練度を示す「レベル」ではありません。方式1を経験していなくても方式2は可能です。実務では、対象業務、リスク、既存体制、技術審査能力に応じて複数方式を組み合わせます。

方式1から方式3は、開発作業を誰がどのように実行するかを示す作業方式です。一方、方式4は、方式1から方式3のいずれか、または複数を、個人の使い方にとどめず、チームや組織の開発体制として運用するための標準化方式です。したがって方式4は、方式1から方式3と置き換わるものではなく、それらの上に重ねて適用できます。

03 / Principles4方式を理解するための原則

「AIに任せる」と「AI任せ」は異なる

AIに任せるとは、人間が目的、参照情報、変更可能範囲、禁止事項、合格条件、確認方法を明示した上で、作業の実行をAIに委任することです。AI任せとは、それらを定義せず、出力の妥当性も確認しない状態です。本書が扱うのは前者です。

04 / Comparison4方式の比較

方式1と方式2を分ける「主たる作業者」の判定

方式1と方式2の境界は、AIの利用時間や生成したコード量ではなく、誰が仕事の進め方と成果物を組み立てているかで判断します。

09 / Selection guide方式の選び方・組み合わせ方

方式は、AIツールの機能ではなく、対象業務の性質から選びます。判断の中心となるのは次の6軸です。

影響度と検出可能性によるリスク判断

方式の選択では、誤りが起きた場合の影響だけでなく、その誤りを本番反映前に発見できるかを合わせて評価します。

たとえばテストコードや内部文書は、結果を比較・修正しやすいためAI主導にしやすい領域です。一方、金融計算ロジック、本番データ更新、認証・権限制御などは、影響度が高く、誤りが表面化しにくいため、人間による技術審査と承認を厚くする必要があります。

代表的な組み合わせ

10 / Work-unit designAIに任せられる作業単位の設計

方式2と方式3を成立させる鍵は、指示を細かくすることではありません。AIが自律的に作業でき、人間が結果を判定できる大きさへ仕事を切り分けることです。

良い作業単位が満たす条件

作業単位の大きさ

機能分解と作業分解を分ける

「システムを何の機能で分けるか」と「その機能に対して何をするか」は別の軸です。両者を掛け合わせることで、方式2・3へ渡せる作業単位を作ります。

作業パッケージの基本構造

方式3における受け渡し

複数AI役割を並べるだけでは工程分業になりません。前工程の成果物に、後工程が検証可能な根拠、未確定事項、禁止された推定、承認状態を含めます。

11 / Context designコンテキストと正本情報の設計

AIへ大量の資料を渡すことと、必要なコンテキストを設計することは同じではありません。AIが、事実、指示、作業状態、推定を区別できるように情報を構造化します。

コンテキストの5層

正本情報の優先順位

複数の資料やコードが矛盾した場合、AIが独断で一つを正しいものとして選ばないよう、優先順位と照会条件を定めます。次は一般的な例であり、案件ごとに調整します。

矛盾を発見した場合の処理

コンテキスト・パッケージ

避けるべきコンテキスト設計

12 / Diagnosis導入診断

導入診断の目的は、組織のAI活用度を点数化することではありません。対象となる仕事ごとに、作業方式、AIの権限、人間の責任、必要な検証を組み合わせて決めることです。

診断の基本フロー

診断質問

診断結果として決める5項目

13 / Governance責任分界、必要能力と品質保証

AIが成果物を生成する場合でも、AIは法的・組織的な責任主体にはなりません。したがって、少なくとも次の責任を明示する必要があります。

方式ごとに必要となる人間の能力

AIへ委任する範囲が変わると、人間に求められる能力も変わります。方式2以降では、人間の仕事がなくなるのではなく、実装から作業設計、統合、審査、責任設計へ移ります。

最低限必要な能力セット

作業主体と権限は分けて設計する

AIが主たる作業者であることと、AIが意思決定者であることは同じではありません。AIには作業を委任できますが、業務目的、仕様の確定、例外の判断、成果物の承認、本番反映の決定まで自動的に委任されるわけではありません。

AI出力を評価する二つの方法

実務では両者を併用します。テストに通ることは必要条件であっても、業務的に正しいこと、保守しやすいこと、セキュリティ上妥当であることを常に保証するわけではありません。

14 / Failure patterns代表的な失敗パターン

AI活用の失敗は、AIの性能不足だけで起きるわけではありません。方式と体制が一致していない場合にも発生します。

15 / Templates実務テンプレート

方式2以降では、プロンプトの文章力よりも、仕事の定義を欠落なく構造化することが重要です。最低限、次の項目を揃えます。

人間・AI役割分担表

AI権限設定表

品質ゲート・承認表

AI成果物レビュー表

失敗・例外記録

KPI測定表

16 / Application models適用モデル

以下は、4方式の使い分けを示すための仮想的な適用モデルです。実在案件の成果を示す成功事例ではなく、案件設計時の検討例として使用します。

通し事例：既存業務システムの更改

次は、仕様書、コード、テスト、運用実態に不一致がある既存業務システムを、限定範囲から更改する仮想事例です。方式2・3・4の併用を、工程全体で示します。

17 / Industry perspectives業界別の設計観点

4方式の基本構造は共通ですが、重視するリスクと証跡は業界によって異なります。以下は方式選択時の基本的な検討観点であり、個別法令や業界基準への適合を保証するチェックリストではありません。

18 / Pilot design限定導入と検証設計

AI活用の効果は、生成速度だけでは判断できません。現在の作業方法を基準として、品質、手戻り、人間の確認負荷、統制上の問題まで比較し、拡大してよい方式かを限定範囲で検証します。

限定導入に適した対象

検証の基本フロー

検証計画書

比較時に揃える条件

現行方法とAI活用方法を比較する際は、作業の難易度、入力情報、対象範囲、要求品質を可能な限り揃えます。AI側だけに整備された仕様を与えたり、逆に現行側だけに熟練者を配置したりすると、方式の差ではなく条件の差を測ることになります。

検証結果の証拠区分

終了時の判断

19 / Implementation roadmap導入ロードマップ

導入は、全社一括展開ではなく、対象選定、限定検証、標準化、段階展開、継続改善を分けて進めます。これは成熟度の序列ではなく、意思決定と責任を確定するための実施順序です。

展開範囲を増やす順序

対象を拡大するときは、作業量、対象機能、利用者、AI権限を同時に広げません。どの変更によって成果や問題が生じたかを判別できるよう、原則として一つずつ段階的に拡大します。

運用開始後の改善サイクル

20 / Traceability要件・設計・コード・テストのトレーサビリティ

AIが成果物を速く作れても、何を根拠に、どの判断を経て、どこへ反映し、何で確認したかを追えなければ、更改・監査・保守には使えません。要求、判断、設計、実装、テスト、承認を相互にたどれる状態を作ります。

トレーサビリティの基本構造

追跡する対象

既存システム更改での事実区分

既存システムでは、設計書、コード、実際の業務運用が一致しないことがあります。AIには、矛盾を自動的に一つへ統合させず、情報の性質を区分して報告させます。

トレーサビリティ表の基本項目

変更影響を追跡する手順

21 / Evaluation & testingAI成果物の評価・テスト戦略

AI成果物の品質は、読みやすさやAI同士の合意ではなく、要求への適合、検証可能な結果、既存動作との差、禁止事項、専門家の判断を組み合わせて評価します。

評価を多層化する

評価用データセットの設計

合否を二種類に分ける

平均点が高くても、重大な必須条件を一つ外せば採用しません。逆に、必須条件を満たしていても、費用や人間負荷が現行方法より大きければ、方式を再設計します。

複数AIによる評価の条件

評価証拠パッケージ

22 / Reference architectureAI開発の参照アーキテクチャ

4方式を実装するには、AIツールだけでなく、正本、作業定義、実行環境、検証、承認、記録を接続する必要があります。以下は特定製品に依存しない最小構成です。

基本構成

構成要素と役割

全体を横断する管理機能

4方式と構成の関係

導入時に分離する三つの領域

23 / Security & information governanceセキュリティと情報管理

AI活用では、従来の開発環境に加えて、入力情報、外部モデル、ツール実行、生成物、ログという新しい情報経路が生まれます。利用可否だけでなく、どの情報へ、どの権限で、どの環境から接続し、何を記録するかを作業単位ごとに定めます。

AI活用で追加される主な脅威と統制

方式別に変わる統制の重点

最低限のセキュリティ・パッケージ

24 / Economics費用対効果と投資判断

AIの生成時間だけを測ると、人間の仕事が指示、確認、修正、統制へ移った事実を見落とします。投資判断では、作業単位から組織運用までの総費用と、品質・再利用・リスク低減を含む効果を比較します。

効果と費用の全体像

三つの単位で判断する

投資判断シート

25 / Change managementモデル・ツール変更管理

AIを利用する開発では、対象コードを変更していなくても、モデル、ツール、プロンプト、参照情報の更新によって結果が変わります。何を同一条件とみなし、どの変更で再検証・再承認するかを定めます。

変更対象と影響

変更区分と必要な確認

再現に必要な基準パッケージ

変更時の基本フロー

26 / Incident response障害・事故対応

停止条件はAIの実行を止めるための基準です。事故対応では、その後に影響を隔離し、証拠を保全し、成果物を無効化または復旧し、安全を確認して再開するまでを定義します。

対応の基本手順

影響区分

事故記録の基本項目

27 / Glossary用語集

28 / Contract, IP & outsourcing契約・知的財産・外部委託の確認事項

AI活用の責任と情報経路は、社内ルールだけでは完結しません。利用サービス、開発委託、再委託、成果物の利用条件を、案件開始前に契約と運用の両面から確認します。

29 / Next update今後の拡張予定

本版は、4方式の定義、作業分解、コンテキスト設計、必要能力、導入診断、限定検証、標準化、本格展開、トレーサビリティ、評価・テスト、参照アーキテクチャ、セキュリティ、投資判断、変更管理、事故対応、契約確認までを一続きにした汎用実務版です。今後は、実測値、外部基準、特定ツールの機能確認を必要とする領域を拡張します。