AIが実装を肩代わりする時代に、何が残るか
以前の記事で「AIはインフラになる」と書いた。また別の記事で「VBAでもAIに書かせる設計ができる」と書いた。
→ AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由
→ 内製DXの開発にAIを使う ── VBAでも「AIに書かせる設計」はできる
この2つを合わせると、1つの問いが出てくる。AIが実装を肩代わりするようになったとき、内製DXエンジニアの仕事はどう変わるのか。
答えから言えば、 実装の「先」にある仕事——業務の理解、問題の分解、指示、検証——が本業になる。 コードを書く時間が減り、コードを書く前と書いた後の仕事が増える。
これは効率が上がるという話ではない。仕事の中身が変わるという話になる。
「何を作るか」を決める力がすべてになる
AIにコードを書かせるとき、最も重要なのは「何を書くか」の指示になる。「月別の売上集計を出して」ではなく、「受注データのうちステータスが完了のものを対象に、出荷日ベースで月別に集計し、前年同月との差額を並べて返す」——ここまで分解して初めて、AIは正確なコードを出してくる。
この分解ができるのは、業務を理解している人だけになる。「出荷日ベース」なのか「受注日ベース」なのか、「完了」の定義に何が含まれるのか、前年同月と比べるべきなのか前月と比べるべきなのか。こうした判断は業務の文脈がわからなければ下せない。
以前の記事で「DX担当者の仕事はコードを書くことではなく、現場の言葉と技術の言葉の通訳だ」と書いた。AIが実装を担うようになると、この通訳の役割がさらに重要になる。現場が「こういうのが見たい」と言ったことを、AIが実行できる精度の指示に翻訳する。その翻訳精度が、アウトプットの質を決める。
「全部読んで確認する」はどこかで限界が来る
AIがコードを書くスピードは速い。しかし、出てきたコードが正しいかどうかを確認するのは人間の仕事になる。
今の段階では、AIが書いたコードを全部読んで、1行ずつ確認して、動作をテストする——これで回る。VBAの関数を1つ書かせる、Excelの集計ロジックを1つ組ませる。このレベルなら、人間がすべて目を通すことは十分可能になる。
しかし、AIがもっと大きな範囲のコードを書くようになったとき——システム全体の処理を書かせる、複数のモジュールをまとめて生成する——「全部読む」というやり方は限界が来る。量が多すぎて、読んで理解すること自体がボトルネックになる。
ではどうするか。 テストの仕組みを使って、結果で検証する。
今のExcel VBAでもすでにやっていることがある。セルにテスト用の値を入れて、関数を呼び出して、期待通りの結果が返ってくるか確認する。これをもう少し系統的にやるだけの話になる。「この入力に対してこの出力が返るはず」というテストケースを先に作っておいて、AIが書いたコードをそのテストに通す。コードを全行読まなくても、テストが通れば正しく動いていると判断できる。
これは今すぐ必要な話ではないが、AIの活用範囲が広がるにつれて必要になる考え方になる。コードを「読んで確認する」から「テストで検証する」へ。確認の方法自体が変わっていく。
「どう作るか」の設計が、AIへの指示になる
以前の記事で「VBAのロジックをFunctionに切り出すとAIに書かせやすくなる」と書いた。これは「コードの構造を整理する」という話だが、もう一段引いて見ると、 設計がAIへの作業指示になる という構造の変化を意味している。
これまで設計とは「人間が修正しやすいように構造を分けること」だった。これからは「AIに担当範囲を伝えやすいように構造を分けること」が加わる。
たとえば、1つの大きな処理をAIに丸ごと書かせると、何がどうなっているか把握しにくい。しかし「この部分は入力の整形」「この部分は計算ロジック」「この部分は出力の組み立て」と分けてあれば、それぞれを個別にAIに書かせて、個別に確認できる。
この「分け方」を決めるのが設計であり、AIに実装を任せる時代になると、設計の意味がより直接的に問われるようになる。
ドメイン知識が唯一の差別化になる
AIはプログラミングの知識を持っている。ロジックを書く力は持っている。しかし、自社の業務のことは知らない。
受注生産で見積番号がどう使われているか。アワーレートをどう計算しているか。この取引先には特殊な納品ルールがあること。検査記録のどの項目が法的に必要で、どの項目が社内管理用なのか。こうした知識はAIの中にはない。
以前の記事で「自社固有の領域は自分たちで理解すべき」と書いた。AIの時代になっても、これは変わらない。むしろ強化される。AIが汎用的な実装力を提供するようになった分、 差がつくのは業務をどれだけ深く理解しているか になる。
→ 中小製造業の内製DXと外注の線引き ──「自社固有」か「汎用」かで決める
コードを書くスキル自体の価値は相対的に下がる。代わりに、業務を理解して正しい問いを立て、AIに的確な指示を出し、出てきた結果を業務の文脈で検証する——この一連の能力が、内製DXエンジニアの中核的な価値になる。
今やるべきことは変わらない
これまで書いてきたことの延長にある。
AIが実装を担う時代に向けて、内製DXエンジニアが今やるべきことは、結局このシリーズで繰り返し書いてきたことと同じになる。
- 業務を深く理解する。 データがどこにあるか、誰がどう使っているか、何が問題なのか。この理解がAIへの指示の精度を決める
- データの持ち方を整える。 AIに読ませるにしても、整っていないデータは使えない。データの文法を正すことは、AI活用の土台でもある
- 小さく試して検証する習慣をつける。 AIが書いたコードを検証する力は、日常の業務で仕組みを試行錯誤する中で身につく
以前の記事で「改善と変化の両方が要る」と書いた。地味な改善で足元を固めること自体が、AIという変化に乗るための準備になっている。
→ AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由
このシリーズの他の記事：