この記事はFinatextグループ Advent Calendar 2024の13日目の記事です。
はじめに
ナウキャストで取締役をしている片山です。
ナウキャストでは今年からデータ&AIソリューション事業を立ち上げています。
データ&AIソリューション事業ではこれまでナウキャストが培ってきたデータエンジニアリングの知見を活かし、エンタープライズにおける生成AI時代のデータ基盤構築を支援しています。
2022年にChatGPTが登場して以来、「エンジニアリングが自動化され、エンジニアが職を失う」と言われ続けています。
20年後の世の中でAIが自律的に開発をしていることはほぼほぼ確定だと思いますが、大切なのはAIによる自動化がいつ、どこで、どの工程から行われるかを考えることだと思います。
直近、OpenAI社のo1がリリースされ、GoogleからもGemini2.0のリリースとともにエンジニアリング自動化に関するいくつかのユースケースが発表されました。
o1の賢さとGoogleの事例を見て、言語化しきれない部分もありますが「いよいよここからAIによるエンジニアリングの自動化が始まるな」と感じ、AIによる開発の自動化がどの様に進んでいくのか考えてみようと思い立ちました。
この記事の一部はOpenAIのo1によって書かれています。
1. 生成AIによるエンジニアリング自動化
o1をはじめとした大規模言語モデルは、与えられた自然言語の指示（プロンプト）に基づいて、複雑なタスクを実行する柔軟性を持っています。プログラミングにおいては、コード補完やバグ修正、ドキュメンテーション、さらにはアプリケーションの初期設計やデータパイプライン構築の素案作成まで、これまで人間が担ってきた多くのステップを支援可能です。
今後は汎用的なモデルに加え、基盤モデルの学習コスト低下に伴いコーディングやインフラ構築に特化した特化型のモデルが続々と登場すると私は考えています。
例えば、AWSのインフラ構築、システムの障害対応、セキュリティ診断など、深いドメイン知識を持った複数のモデルが登場し、それらをo1の様な汎用モデルがオーケストレーションすることになるでしょう。
こうしたテクノロジーの進歩によって、エンジニアリングの現場は大きな転換点を迎えています。「人間が手動で行う開発」から「AIと共創する開発」へ、そして将来的には「AIによる自律的な開発・運用」へとシフトする可能性があります。
2. 自動運転のレベル分けとエンジニアリング自動化
ただし、こうしたエンジニアリング自動化は一朝一夕に実現できるものではありません。自動運転技術を例にとると、私たちはその進化が段階的であることを理解できます。完全な自動運転（いわゆる「レベル5」）に至るまでには、ドライバーが常に操作を行う「レベル0」の段階や、一部の運転タスクを車両が支援する「レベル1～2」、特定条件下でシステムが大半の運転を行う「レベル3～4」といったステップが存在します。
このアプローチは、エンジニアリング自動化の分野にも適用できると考えられます。すぐに「ビジネス要件を入力するだけで、AIが全てを自動構築する」理想的な状態に到達するわけではありません。最初はコード補完や定型的なタスク支援といった単純な段階（レベル1）から始まり、徐々にインフラ設定やテスト、モニタリング、パフォーマンス最適化など、より高度なタスクが自動化されていく（レベル2～3）ことでしょう。その後、特定条件下でエンドツーエンドの開発が自動化され（レベル4）、最終的にはどんな要件にも適応できる完全自動化（レベル5）を目指す、という段階的な進化の道筋が見えてきます。
3. 自動運転のレベル分けの概要
自動運転は、世界中の自動車メーカーやIT企業がこぞって研究開発を進める最先端領域であり、その自動化度合いは「SAE（米国自動車技術会）」によって0～5のレベルに分類されています。以下はその概要です。
-
レベル0：完全手動
ドライバーがすべての運転操作を実施。 -
レベル1：運転支援
前方車両との距離維持やステアリング補助など、限定的な自動化機能があるが、基本的に人間が操作・判断する。 -
レベル2：部分的自動運転
加速・減速と方向操作を同時に支援できるが、人間の監視と即時介入が必須。 -
レベル3：条件付自動運転
特定条件（高速道路や渋滞時など）では車両が全ての運転タスクを行うが、人間は必要時に介入する必要がある。 -
レベル4：高度自動運転
特定エリアや条件下では、ドライバー不要で走行可能。障害があってもシステムが安全停止などの対処を自動的に行う。 -
レベル5：完全自動運転
すべての環境・条件で人間を必要とせず自動運転が成立する。
これらの段階的なアプローチは、技術的課題の解消やインフラ整備、市場受容性、法規制対応など、さまざまな条件をクリアするための現実的な戦略でもあります。
そして、エンジニアリング自動化の世界でも、同じような段階的進化が求められます。特にエンタープライズにおけるエンジニアリング自動化には十分なリスクコントロールが求められます。
始めは特定のタスク支援（「レベル1～2」相当）から始まり、やがて特定条件下でのエンドツーエンド自動化（「レベル3～4」相当）、そして最終的な完全自動化（「レベル5」相当）へと至るロードマップを描くことが有効になるでしょう。
4. 一般的なシステム開発における自動化レベル分け
自動運転レベルの考え方をソフトウェア開発全般に当てはめると、私たちが現在どの段階にいるのか、そしてどの方向へ向かおうとしているのかを明確にできます。従来のシステム開発は、人間のエンジニアが要件定義、設計、実装、テスト、デプロイ、運用監視といった全行程で主体的に手を動かす必要がありました。ところが近年、CI/CD（継続的インテグレーション/継続的デリバリー）パイプラインやインフラ構成管理ツール、さらにはAIを活用したコード補完ツールなどによって、一部の工程が自動化され始めています。
ここでは、ソフトウェア開発フロー（要件定義・設計・実装・テスト・デプロイ・運用）における自動化をレベル0～5で捉えてみましょう。
-
レベル0：完全手動開発
すべてを人間が行う段階です。要件定義からコーディング、テスト、デプロイまで、全工程を手作業で実施。ドキュメンテーションも手動作成、テストは手動実行が基本です。 -
レベル1：部分的支援
IDE（統合開発環境）やエディタによるコード補完、静的解析ツールによるコーディングガイド支援、簡易的なテスト自動実行など、一部工程が補助的に自動化されています。しかし、依然としてエンジニアが中心的な判断と作業を行います。 -
レベル2：複合タスク支援
AIが要件を踏まえて機能モジュールやクラス単位でコード提案したり、自動的にテストコードを生成するなど、より広い範囲での支援が可能になります。開発者はアウトプットをレビュー・修正しつつ、基本的には人間が最終的な責任を負います。 -
レベル3：条件付き自動化
特定の条件下（特定ドメインや既知のアーキテクチャパターン）では、要件定義から実装、テスト、デプロイまで、一連の開発プロセスをAIがほぼ自律的に行えます。ただし、仕様外のケースや未知の問題が発生すると、AIは人間の介入を求めます。人間は「最終責任者」として待機し、必要に応じてハンドルを取り戻す役割です。 -
レベル4：高度自動化
限定された領域や条件下では、AIがほとんど全自動で開発から運用までを行い、人間の関与は最小限です。障害が発生しても、AIがドキュメントや既存の知識ベースに基づいて自己解決したり、安全な状態へと回復させます。人間はほとんどの場合、観測者であり、最後のセーフティネットとして存在するのみです。 -
レベル5：完全自動開発
あらゆる領域・ドメインにおいて、AIが自律的に要件を理解し、設計・実装・テスト・デプロイ・運用・保守を実行します。人間は要件やビジネスゴールを設定するだけで、技術的な実装はAIに完全に任せられます。未知の要件変更や新たなテクノロジーへの適応もAIが自動的に行い、人間は「アイデアの発信者」としての役割を担うことになります。
このような段階的モデルは、現時点での位置づけを俯瞰し、「次はどこまで自動化を推し進めるべきか」を計画する上で役立ちます。多くの組織はまだレベル1～2であり、コード補完やCI/CD、単純なテスト自動化などを導入している段階です。しかし、今後はo1をはじめとした汎用型の大規模言語モデルや特化型モデルの進化によって、より高度な自動化（レベル3～4）への道が開けてくるでしょう。これが定着すれば、エンジニアがより戦略的・創造的なタスクへ注力できるようになり、開発全体のスピードと品質が向上することが期待されます。
5. データエンジニアリング領域における自動化レベル分け
上記の一般的なシステム開発におけるレベル分けはフロント開発、インフラ構築など領域を絞ることで、更に具体的にな議論を進めることが可能です。
私は以下の理由からデータエンジニアリングは他の領域よりも速くAIによる自動化が進むと考えています。
- 求められる要件が比較的シンプル（出力データのが仕様を満たせば良い）なため、人間によるレビューが行いやすい
- バッチ処理が多く、迅速な対応が求められる要件が少ないため、人間によるリカバリーを前提とした構成を採用しやすい
一般的なシステム開発同様、データエンジニアリング（データパイプライン構築、ETL/ELT、データウェアハウス運用、品質管理、モニタリング、スケーリングなど）も同じような段階的自動化のアプローチを適用することができます。データエンジニアリングは、企業がビジネスインテリジェンスやデータ分析を行うための基盤づくりに不可欠であり、その構築・運用コストはしばしば高止まりしがちです。もしこの領域で自動化が進めば、エンジニアの手間を大幅に削減し、データ活用のスピードと柔軟性を飛躍的に高めることができます。
ナウキャストでも社内のデータエンジニアリングの自動化はもちろん、様々な企業の自動化を推進できる様な仕組みを今後作っていきたいと考えています。
以下は、データエンジニアリング固有の文脈における自動化レベル分けを考えてみました。
-
レベル0：完全手動運用
ETLスクリプトやデータウェアハウス（DWH）の構成、スキーマ変更、ジョブスケジューリング、異常値検出、テスト作成など、すべてを人間が手動で行う段階です。新たなデータソース追加や負荷変動への対応も、エンジニアがスクリプトや設定を個別に変更・適用します。 -
レベル1：部分的支援
部分的なコード補完やSQL最適化ツール、基本的なデータ品質チェックを自動化するツールが存在する段階です。人間が作ったジョブを自動でテストや実行するCI/CDパイプラインを整備できる場合もあります。ただし、データフローの全体像やアーキテクチャ設計はエンジニアが主導します。 -
レベル2：複合タスク支援
データエンジニアが要件を記述すると、AIがETLコードやパイプライン設定ファイルを自動生成し、基本的なテストデータや品質チェックルールを提案してくれる段階です。たとえば、「このAPIから取得するJSONデータを、日次でDWHにロードし、指定の集計テーブルを更新する」という要件を入力すれば、AIがある程度まとまったワークフローやSQLクエリ群を自動作成できます。ただし、最終的な承認や微修正はエンジニアが行い、依然として人間が責任者であることに変わりはありません。 -
レベル3：条件付き自動化
特定のドメインや明確なアーキテクチャパターン下では、AIが要件定義から設計、コーディング、テスト、スケーリング設定、基本的なモニタリング・アラート設定までをエンドツーエンドで実行できる段階です。問題が発生しても、AIが初歩的なトラブルシューティングを試み、解決できない場合のみ人間にエスカレーションします。このレベルでは、日々の運用で人間が細かく介入する必要が大幅に減り、エンジニアは主に異常時の対処や高度な改善策の立案に注力できるようになります。 -
レベル4：高度自動化
特定範囲や条件においては、データ基盤が自己完結的に運用・改良される段階です。AIは負荷変動に応じて自律的にリソースをスケールアップ/ダウンし、新規データソース追加時も自動的にパイプラインを最適化。異常検知や品質問題への対処もほぼ自動で行い、人間は必要とされる場面が極めて限られます。 -
レベル5：完全自動開発
あらゆるデータ領域や要件に対応でき、ビジネス要件をインプットすれば、AIが自律的に最適なデータ基盤を構築・運用・スケール・メンテナンスできる状態です。たとえば、「この新たな事業領域のKPIをモニタリングするために必要なデータを自動で収集・整形・保存し、分析者が即座に使える状態にしてほしい」と伝えるだけで、AIが必要な構成要素すべてを揃え、運用・改良していきます。
データエンジニアリングにおいても多くの企業はまだレベル1程度、すなわちツールによる部分支援の段階にとどまっています。しかし、今後は特定条件下でのエンドツーエンド自動化（レベル3～4）の実現が視野に入ってくるでしょう。これにより、エンジニアはより高付加価値な業務に集中でき、企業はデータ活用のスピードと柔軟性を格段に高めることが可能になります。
6. レベル3以降の実現における主要な論点
レベル3以降の実現にあたり、私はAIの知能がボトルネックではないと考えています。
AIの情報へのアクセス性の低さ、人間側の指示の不足、企業のルール設計などが今後のボトルネックになる可能性が高く、私自身もまだまだ考えが深まってはいませんが、今後重要になりそうな論点をいくつか挙げてみます。
Modern Data Stack 2.0
現状の最大の課題はAIが人間と同様の情報にアクセスできていない点にあります。
AIがどれだけ賢くても、仕様書、インフラ、コードベース、Slackなど、人間と同じ様なデータにシームレスにアクセスできないと力を発揮できません。
データエンジニアリングの領域ではクラウドのマネージドサービスやOSSを組み合わせた「Modern Data Stack」という技術スタックがここ数年で進化し、データエンジニアリングの高度化を下支えしました。
今後は、AIが全ての情報にアクセスすることを前提とした技術スタックが求められます。
私はこれが1社のサービスで完結する可能性は低いと思っており、複数の会社のサービスを上手く組み合わせていく必要があると考えています。
近い内にAIによる自動開発を前提とした「Modern Data Stack 2.0」の様なものが提唱されるはずです。
SIモデルへの回帰
近年のアジャイルな開発では従来のウォーターフォール開発と違い、開発の前に仕様を事細かにドキュメントに落とす重要性は相対的に下がっていました。
しかし、AI開発においては人間が仕様をドキュメントに正確に落とすほど開発品質が向上します。
この構図はオフショアと連携した日系の大手SIerの開発スタイルと似ており、今後は”コードを書かずにシステムを開発する力”が重要になり、人間には設計書作成やAIの設計書レビューのスキルが求められるでしょう。
このようなマインドチェンジが実現できたエンジニア組織が生産性を向上させることになりそうです。
ドキュメント管理のオペレーションエクセレンス
上記にも関連しますが、会社全体での徹底したドキュメント管理が求められるようになるでしょう。
人間であればドキュメントが一切ない環境に放り込まれても、人間関係を築き、情報を集め、なんとか開発を進めることは可能でしょう。
しかし、AIにその動きを期待することは難しいです。
現在のような暗黙知や属人化を許容した"努力目標”としてのドキュメント管理ではなく、徹底したガバナンスに基づいたドキュメント管理に関するオペレーションエクセレンスの実現が企業課題となると思います。
会社レベルでのルール策定
日本の自動運転開発がアメリカと中国に遅れを取ってる理由の一つに、規制緩和に出遅れたことが挙げられると思います。
※他にも色々あると思いますが
完全自動開発は一定のリスクを伴う意思決定です。導入の過程で主要なシステムが完全に停止して、業務やサービスが止まることもあるでしょう。
しかし、それを恐れていては完全自動開発による大きなリターンを得ることもできません。
アメリカや中国がいち早く国を挙げて自動運転に取り組み、世界をリードしているように、会社単位でルールの整備に取り組むことが重要になると思います。
7. まとめ：段階的アプローチで創るデータエンジニアリングの未来
本記事では、o1の登場を契機にエンジニアリング自動化が進展する状況をふまえ、自動運転になぞらえたレベル分けの概念をシステム開発やデータエンジニアリング領域へ拡張して考察しました。自動化は一足飛びには実現せず、レベル0からレベル5へと段階的に成熟していきます。これは、技術的進歩だけでなく、市場や法規制、ユーザーの受容度、そしてエンジニアリング文化そのものの変革を必要とするからです。
一般的なシステム開発では、現在多くの現場がレベル1～2に留まっています。データエンジニアリング領域も同様で、まだ「部分的な自動化」段階であるケースが大半です。しかし、汎用型大規模言語モデルのo1や、今後登場するであろう特化型モデルによって、一部条件下でエンドツーエンドの自動化（レベル3～4）を実現するハードルは着実に下がっていくはずです。
ナウキャストは、長年培ったデータ基盤構築・運用の知見と、生成AIユースケース活用の経験を融合し、データエンジニアリング自動化の最前線を切り開くことを目指しています。1年以内に小規模な範囲でレベル3を実現し、その先にはさらなる高度化、そして最終的にはレベル5である完全自動開発への到達も視野に入れています。
この段階的アプローチをとることで、私たちは現実に即しながら着実に進化を遂げることができます。今後、データエンジニアリング領域は、より迅速で柔軟なデータ活用を可能とする「自律的な基盤」によって新たな価値を創造していくでしょう。その未来は、すでに始まっています。
ナウキャストではデータエンジニアリングと生成AIを用いてデータプロダクトの開発を行うエンジニアやコンサルタントを募集しています。
Snowflake、dbt、Terraformなどのモダンな技術スタックを用いて、ARR10億円のSaaSの開発から大手企業のデータ基盤高度化まで様々な経験を積むことができます。
カジュアル面談も常時受け付けてますので、興味を持っていただけた方はぜひ以下のリンクよりご応募ください。
Discussion