AI駆動開発で、データ基盤を作り直す

古いデータ基盤を作り直したい。けれど、積み上がった処理の量を前に、何年かかるか見当もつかない。 そんな状況を変えつつあるのが、AIにコードを書かせる「AI駆動開発」です。 移行・開発・運用のそれぞれで何が速くなり、人は何に集中すべきなのか。実際の取り組みから整理します。

データ基盤の作り直しは、なぜ重いのか

長く使われてきたデータ基盤には、何年分もの処理が積み上がっています。 誰がいつ書いたのか分からない集計、同じ指標なのに部署ごとに違う計算式、担当者しか中身を知らない夜間の処理。 作り直そうとすると、まずこれらを1つずつ読み解くところから始めなければなりません。

これまでは、この読み解きと書き直しを人手でこなすしかありませんでした。 処理の量に比例して人と時間が必要になり、見積りは膨らみ、刷新は先送りされてきました。

AI駆動開発は、この「量に比例する作業」をAIに任せる考え方です。 古いコードを読んで整理する、新しい書き方に変換する、テストを用意する。 こうした作業をAIが担うことで、作り直しの重さそのものが変わり始めています。

AIが書き、人が決める：役割分担を先に決める

AI駆動開発といっても、すべてをAIに任せるわけではありません。 うまくいっている会社は、AIの仕事と人の仕事をはっきり分けています。

• AIに任せる：既存の処理の解析、新しい形への書き換え、コードや構成の生成、テストの下書き
• 人が持つ：何を作るかの設計、指標の定義、AIが書いたもののレビュー、本番に出すかどうかの承認

AIが速く書けるほど、「何を作るべきか」「それは正しいか」を判断する人の役割が重くなります。 人の時間を、書く作業から、設計と確認に振り向ける。これがAI駆動開発の基本です。

役割分担を決めるときは、AIに渡す「指示の材料」も人が用意します。 データの持ち方の方針、命名のルール、指標の定義、テストで確かめるべき数字。 これらが文書として揃っているほど、AIの出力はぶれにくくなり、レビューも楽になります。

移行：積み上がった処理資産を、AIで読み解く

ある航空会社は、統合データ基盤を段階的に刷新してきました。 2022年に初期構築、2023年に新しい基盤を導入、2025年にはオープンなデータ形式へ移行し、2026年にはAIによる開発へと進んでいます。

最後の段階では、既存の処理資産をAIで解析し、新しい開発の仕組みへ移しました。 その結果、約57万行あったコードは約6.7万行になり、約88%減りました。 分析にかかる期間は4週間から1週間に短くなっています。

もう1つ大きかったのが、数字の信頼性です。 指標の定義を整えたことで、業務データとの数値の一致率は70〜80%から100%になりました。 AIで移行を速めるだけでなく、その過程で定義を揃え直したことが、成果を確かなものにしています。

あるコンサルティング会社も、古いデータ分析の仕組みからの移行で、定義の変換や処理の移し替えにAIを使っています。 移行は、AI駆動開発の効果がもっとも出やすい場面の1つです。

AIを使った移行は、おおむね次の流れで進めると安全です。

• 棚卸し：既存の処理と、それを使っている業務・画面を洗い出す
• 解析：AIに処理を読ませ、何をしているかを文章と図に起こさせる
• 定義の整理：指標の計算式を人が確かめ、重複や食い違いを1つに揃える
• 書き換え：揃えた定義をもとに、AIに新しい形の処理を書かせる
• 突き合わせ：新旧を並行して動かし、数字が一致するまで確かめてから切り替える

開発：書き直しと試作が、数日単位になる

ある半導体メーカーでは、データを1件ずつ処理するプログラムを動かしたところ、費用が見積りの10倍以上に膨らみました。 そこで、AIにまとめて処理する書き方（集合処理のSQL）へ書き換えさせたところ、30分以上かかっていた処理が1分未満で終わるようになりました。

この会社では、プロトタイプも1週間で開発しています。 ある小売向けマーケティング企業では、チームで数か月かかっていた構築が、AIの支援で数日になりました。 ある大手電機メーカーは、AIを使った社内検索の開発で、開発工数を90%削減しています。

あるコンサルティング会社は、AIを使ったハッカソンを準備も含めて2人日弱で実施し、営業のコンプライアンス違反の予兆を検知する仕組みを作りました。 「試してみる」のに必要な時間が、週や月の単位から、日の単位に縮まっています。

試作が速くなると、作ってから業務部門に見せ、直す回数を増やせます。 完成形を最初に詰め切るより、動くものを早く見せて方向を決めるほうが、結果として手戻りも少なくなります。

運用：変更は「仕様書」から始め、承認は人が行う

作ったあとの運用にも、AI駆動開発の考え方は広がっています。 ある通信会社では、仕様書の変更を起点にAIが構成を生成し、人が承認してから本番に反映する仕組みを整えました。 変更の提案（プルリクエスト）の形で残るため、何が、なぜ変わったのかを後から追えます。

この会社では、AI開発ツールの利用者は1,500人以上にのぼります。 一次分析にかかる時間は、約260時間から約0.3時間になりました。

AIが書き、人が承認し、すべての変更が記録に残る。 この流れを仕組みにしておけば、作業が速くなっても、統制が緩むことはありません。

逆に、AIが本番の環境を直接書き換えられる状態は避けるべきです。 AIの出力は必ず提案として受け取り、人が差分を見て承認する。 この一手間が、速さと安全を両立させます。

非エンジニアも、開発に加われるようになる

ある資産運用会社（運用資産約28兆円）では、非エンジニアがAIを使って基幹データベースの統合を検証しました。 分析ロジックの誤差は9.5bpから0.8bpに縮まり、統合の作業は約6時間で終わっています。 開発チームには「手作業のコーディング禁止」という方針を出しています。

コードを書く部分をAIが担えば、業務と数字の意味を知る人が、直接開発に関われるようになります。 要件を技術者に伝えて待つのではなく、自分で作って確かめる。 データ基盤の作り直しは、もはや技術部門だけの仕事ではありません。

ただし、非エンジニアが作ったものほど、確認の仕組みが大切になります。 誤差のような「正しさの物差し」を先に決めておき、その基準を満たしたものだけを本番に進める。 物差しがあれば、作り手が誰であっても品質を同じように判断できます。

組織に広げる：業務の棚卸しと推進担当

別の資産運用会社は、全業務を棚卸しして約650件をリスト化し、各部署に最低1名、計70名の推進担当を置きました。 AI開発ツールの利用率は、3月の10%から7月には60%に上がり、1人あたりのクエリ数は7倍になりました。

この会社は、AIを通した実行がすべて記録に残るため、「誰が何をしているか分からない業務（野良業務）」がなくなると考えています。 そして、次のようにも述べています。

データ・ロジック・意味の定義を自社で握ることが、本当のロックイン回避になる。

特定の道具や外注先に依存しない状態とは、道具を選ばないことではなく、 自社のデータと、その計算の仕方と、言葉の意味を、自分たちで持っておくことです。

推進担当を各部署に置くのは、AIの使い方を広めるためだけではありません。 棚卸しした業務のうち、どれをAIで作り直すと効果が大きいかを、業務を知る人が判断するためです。

気をつけたいこと

設計・レビュー・承認は、人が持ち続ける
AIは速く、それらしいコードを書きます。だからこそ、何を作るかを決め、出てきたものを確かめ、本番に出すかを判断する役割は、人が手放してはいけません。 AIに任せる範囲を広げるほど、人の確認の質が全体の品質を決めます。

データは1か所に集めておく
AIが外部の複数の仕組みを経由してデータを集めると、精度もコストも悪化しやすくなります。 渡るたびに意味がずれたり、同じデータを何度も取りに行ったりするためです。 AIに仕事をさせる前に、データを1か所に集約し、定義を揃えておくことが近道です。

速さだけを成果にしない
先の航空会社の例でも、成果の柱の1つは数値の一致率でした。 コードの量や開発期間だけでなく、「数字が業務と合っているか」を一緒に測ることが大切です。

まとめ：AI駆動開発でデータ基盤を作り直す前のチェックリスト

• AIに任せる作業と、人が持つ設計・レビュー・承認を分けているか
• 既存の処理資産を、AIで解析して整理する計画があるか
• 移行に合わせて、指標の定義を揃え直す場を設けているか
• 変更は仕様書や提案の形で残し、人が承認してから本番に出す流れになっているか
• AIが参照するデータを、1か所に集約しているか
• 速さだけでなく、数字の一致や誤差も成果として測っているか
• データ・ロジック・意味の定義を、自社で持ち続けられる体制か

AI駆動開発は、人を減らすための手法ではなく、人の時間を「設計と判断」に集中させる手法です。 私たちも、データ基盤の移行や開発でAIにコードを書かせ、設計とレビューに時間を使う進め方をとっています。 開発の進め方が変わると、費用の考え方も変わります。その点は、関連記事「AI駆動開発で、受託開発の見積りはどう変わるか」で整理していますので、あわせてご覧ください。