従来型とAI開発の「4つの根本的なズレ」と成功を導く「共創」マインドセット

従来の開発（コードベースのソフトウェア開発）とAI開発（データ駆動のAI開発）の間には、主に「知能の源泉」「開発プロセス」「完成の定義」「導入後のライフサイクル」の4点において決定的な違いがあります。

以下に、それぞれの決定的な違いについて詳しく説明します。

1. 知能の源泉：コードベースのロジック vs データ駆動のモデル

知能の源泉が根本的に異なります。

従来の開発

• 知能の源泉は人間が書いたコードです。

• エンジニアが業務ルールやロジックをコードとして明示的に書き下し、システムの振る舞いを決定します。

• 出力は、人間が定めた条件分岐によって定まり、挙動は常に**決定論的（deterministic）**です。たとえば、金融取引システムのように「同じ入力に対して常に同じ出力」が保証される仕組みが骨格でした。

• 開発者はコードの一行一行を通じてシステムの振る舞いを完全に制御できます。バグが見つかれば、原因となるコード行を特定し、ロジックを修正することで解決できます。

AI開発

• 知能の源泉はデータにあります。

• ロジックそのものを書く代わりに、大量のデータをアルゴリズムに学習させてモデルを作り、そのモデルがデータ中のパターンから判断を下します。

• プログラム自体（モデルの重み）は人間が書くのではなく、機械がデータから自動生成するイメージです。

• リスクとして、AIモデルが特定の判断を下した理由が人間には直接分からないケースが多く、これは「ブラックボックス」問題と呼ばれます。この不透明さは、特に金融や保険の分野において、説明責任や統制、法令遵守に新たな課題をもたらします。

• この違いにより、プロジェクト体制にも影響が出ており、AI開発ではデータサイエンティストや機械学習エンジニア、データエンジニアといった新たな専門職が不可欠になります。

2. 開発プロセス：線形計画 vs 実験的・反復型アプローチ

開発の進め方と計画性が大きく異なります。

従来の開発

• 開発プロセスは比較的予測可能で線形的です。

• 「要件定義 → 設計 → コーディング → テスト → デプロイ」という基本的な段階を踏襲し、プロジェクト開始時点でゴールや完成基準がはっきりしていることが多いです。

• 賢明なプロジェクトマネージャーであれば、遅延を見越したスケジュール調整が可能で、進捗は機能実装数などで可視化しやすいです。

AI開発

• 開発プロセスは一転して探索的・実験的になります。

• プロジェクト開始時点で、そもそも「手持ちのデータと機械学習で解決可能か？」というフィージビリティ（実現可能性）の検証から始まることがあり、試行錯誤を通じてゴールそのものを再定義することも珍しくありません。

• AI開発は、要求を満たす構造物を組み立てる作業というよりも、解の存在を探り当てる研究的プロセスに近いです。

• 小規模なPoC（概念実証）から構築を始め、期待通りの性能が出るかを検証する実験と検証が優先されます。

• 初期のマイルストーンは「動く機能」ではなく「有望な知見」になります。

• 予期せぬデータの問題（欠損や偏りなど）が発覚し、方針転換を迫られることも頻繁にあり、開発の進行方向がジグザグになりがちで、時間予測やタスク管理の難易度が上がります。

• 従来の進捗管理手法（完了した機能数など）は当てはまりにくく、期間内にモデル精度向上を保証できない場合もあり、「何も成果が出ないスプリント」もあり得るため、失敗を織り込み済みの柔軟な計画修正が求められます。

3. 完成の定義：「機能完備」 vs 「性能しきい値」の達成

プロジェクトの成功や完成の判断基準が異なります。

従来の開発

• プロジェクトの「完成」は比較的明確に定義でき、要件で定められた全ての機能が実装され、仕様通りに動作すればひとまず完成です。

• 「機能が出揃った状態（feature complete）」が一つのマイルストーンとなります。

AI開発

• 実装すべき機能はシンプルであることが多く、難しいのはモデルの性能です。

• 完成は、モデルの予測精度や再現率といった評価指標が、事前に期待する性能しきい値（閾値）に達したかどうかで決まります。これは従来の「機能さえ実装できればOK」とは本質的に異なります。

• 「動くもの」は早期にできても、それが「十分使えるか」どうかは最後まで分からないのがAI開発の難しさです。

• 達成すべき性能目標はプロジェクト途中で修正される可能性もあり、柔軟性が必要です。

• さらに重要なのは、完成はあくまで一時点の合格であって永続的ではないことです。モデルの性能はデプロイ後もデータの変化に伴い劣化し得るため、「一度基準を満たしたから終わり」ではありません。

• このため、経営層と現場で成功基準（例：「人間の判断精度と同等（90%以上）になれば商用化する」など）を明確に合意しておくことが肝要です。

4. 導入後のライフサイクル：保守 vs 継続学習・MLOps

システム導入後の運用に対する考え方が異なります。

従来の開発

• 導入後は主に「保守運用」フェーズになります。

• 一度本番稼働すれば、基本的には「一度作れば、後は壊れない限りそのまま動き続ける」のが通常で、勘定計算ロジックなどが勝手に性能劣化するようなことはありません。

• 開発チームから運用・保守チームへシステムを引き継ぐ、といった役割分担が確立されています。

AI開発

• 導入後は、「継続的な学習と改善」が前提となります。

• AIモデルは、ユーザー行動の変化や市場トレンドの変化など、データ分布や環境の変化に伴い、時間の経過とともに精度が落ちる可能性があります（モデル劣化やドリフト）。

• この現象に対応するため、AI開発では最初から「本番運用込み」でライフサイクルを設計する必要があります。

• 具体的には、**MLOps（機械学習オペレーション）**と呼ばれる手法・体制を整備し、モデルの監視・再訓練・再デプロイを継続的かつ自動的に回せるようにします。

• MLOpsでは、モデルの開発フェーズと運用フェーズを切り離さず、一体のサイクルとして滑らかに繰り返します。

• 特に金融業界では、AIモデルに対しても定期的なバリデーション（精度検証）やパラメータ見直しが義務化されつつあり、継続運用を怠ると誤った判断を下し続けるリスクが生じます。

• 継続運用には、データサイエンティストとIT運用担当者が一体となる組織横断的なガバナンス（例：モデルオーナーやモデル委員会の設置）が求められます。

これらの違いから、AIプロジェクトを成功させるためには、「人がルールを書く開発」から「データを育てる開発」への転換、「線形的な計画志向」から「実験を前提とした計画」への転換、「機能完備」から「性能基準でのゴール設定」への転換、そして「リリース後も継続運用・改善にコミットする」体制 への、組織文化とプロセス全体におけるマインドセットの変革が不可欠であると、ソースは指摘しています。