【AIに向けた意味駆動型モデル #1】「AIツール利用」と「AI駆動開発」の境界線を設計する
AI駆動って、どこから名乗っていいんだろう？
前回は、組織の方針と現場のギャップについて考察した。
（前回の記事：ベンダー丸投げ文化の会社員が、「AI駆動開発」の正体を突き止めるまでの思考記録）
現状を一言で言えば、**「スローガンと実態の乖離」**があるような気がしてならない。
「AI駆動開発でいくぞ！」
と掲げてはいるものの、実際にやっていることは
個人の生産性向上ツールの導入に留まり、
肝心の「開発プロセスそのもの」は従来のベンダー依存型から変わっていないように見える。
このままでは、新しいツールが増えるだけで、
本質的な変革（内製化・脱属人化）は起きないんじゃないか。
そんな予感がしている。
だからこそ、曖昧な言葉でごまかさず、まずは自分の中で定義を固めておきたいと思った。
- 単にツールを使うことと、システムを「AI駆動」させることの違いは何か？
- どこから先なら、胸を張って「AI駆動している」と言っていいのか？
今回は、その「境界線」を明確にし、
具体的なモデル（仕組み）として検討した思考のプロセスを書いていこうと思う。
変更管理の自動化を「AI駆動ライン」として仮置きしてみる
まず、「どこから先なら AI 駆動と言えるか」のライン引きについてだが、
「コードが自動で書ける」「設計書が作れる」といった機能面については、
便利なのは分かっていても、それが AI 駆動の本質だとは最初から思っていなかった。
そこで、機能ではなく
「開発プロセスのどこを AI に任せるか」 という視点で検討を進め、
暫定的なラインとして、次の状態を仮置きしてみることにした。
変更管理プロセスを、一定レベルまで AI に任せられている状態
ここで言う変更管理とは、
- 変更要求の整理
- 影響範囲の調査
- 必要な開発工数（テスト範囲等）の算出
- 内容の承認
といった、開発の入り口にあたる一連のプロセスを指す。
なぜこの領域を最初のターゲット（境界線）に選んだのか。
理由は大きく 3 つ。
1. 後続プロセスによるリカバリーが可能であること
変更管理は開発プロセスの入り口（最上流）であり、
このあとには必ず詳細設計・実装・テストといった後続プロセスが控えている。
AI の最大の懸念点である「ハルシネーション」が発生したとしても、
後続の工程で人間やテストが検証することで、ある程度のリカバリーが効く。
いきなり本番コードを触らせるのではなく、
セーフティネットがある状態で AI を組み込めるレイヤだと判断した。
2. 運用しながら改善を回しやすいこと
1 点目と関連するが、運用リスクが比較的低い領域であるため、
まずは AI を動かしながら、
- どこで精度が足りていないか
- どの情報が不足しているか
といったポイントを観測しつつ、改善サイクルを回しやすい。
トライアル＆エラーを前提とした適用領域として、
変更管理はちょうどよいポジションに見えた。
3. 「雑に扱われがちだが重要」なプロセスであること
ここが一番の理由かもしれない。
変更管理はリスクが低いプロセスと見なされがちで、
実施者のスキル差が表面化しにくい。
多少の甘さがあっても、後工程のエンジニアが頑張れば
なんとかなってしまうケースも多く、どうしても雑に扱われやすい傾向がある。
しかし、実際のプロジェクト遅延や品質問題の原因を辿ると、
多くの場合、この「入り口（変更管理）」の見積もりや調査の甘さに起因していることが多い。
- 調査の深さ
- 影響範囲の取り方
- テスト観点の厚み
が担当者ごとにバラつきやすく、属人化しやすいのにプロジェクトの命運を握っているボトルネックでもある。
だからこそ、最初に AI によって標準化を狙うポイントとして、
変更管理が妥当だと考えた。
これらを総合して、
変更管理という上流工程において、
AI が妥当な判断材料を提示できている状態
これを、自分たちにとっての「AI駆動開発」の定義として、
いったん置いてみることにした。
言い換えると、
として、その境界線をここに引いておく、という整理になる。
…と、ここまでは机上で定義できる。
問題は、今ここにある 現実のドキュメント だ。
- 担当者ごとに記述粒度が異なる仕様書
- 「背景」を知らないと正しく解釈できないテーブル定義
- 歴史的経緯で命名された物理名
これらはすべて、「人間が脳内でコンテキストを補完して読む」 ことを前提に作られている。
このままの非構造化データを AI に渡しても、「変更管理を任せられる水準」には到達しない。
整理すると、課題が明確になった。
AI を主役（ドライバ）にするなら、
渡す情報も「AI が解釈可能な構造」でなければならない。
AI に渡す「入力の構造」そのものをリファクタリングしない限り、
この構想は実現できないということだ。
次回は、この課題を越えるために考えた
- AI に渡す前提としての 「軽量化された設計」
- その裏側にある 「意味の構造化」
について、順番に整理していこうと思う。
次回：【AIに向けた意味駆動型モデル #2】AI主体に作り替えるための「軽量化された設計」とは何か
前回：ベンダー丸投げ文化の会社員が、「AI駆動開発」の正体を突き止めるまでの思考記録
Discussion