内製DXは大きなシステムだけではない
内製DXというと、受発注管理や在庫管理のような業務システムを想像するかもしれない。しかし現場で本当に求められるのは、もっと小さなツールであることが多い。
ファイルのバックアップを定期的に取りたい。特定のフォルダを監視して変更があったら通知したい。CSVを決まったフォーマットに変換したい。こうした「ちょっとしたこと」は、Excelのマクロでは対応しきれないが、かといって業者に頼むほどの規模でもない。結果として、誰かが手作業で回しているか、そもそも諦めているかのどちらかになる。
以前の記事で「大半はExcel VBAで回る」と書いた。それは今も変わらない。しかしVBAでは対応しにくい領域——GUIを持ったWindowsアプリケーション、ファイルシステムの操作、ネットワーク越しの処理——になると、VBAの外に出る必要がある。
→ 中小製造業の内製DX ── Excel VBAで済む領域と、専用言語で作るべき領域
これまでは、その「外に出る」ハードルが高かった。C#やPythonを覚えて、GUIフレームワークを調べて、ビルド環境を整えて——DX担当者がこれをやるには、時間も学習コストもかかりすぎた。
AIに全部書かせて、1行もコードを書かなかった
最近、Windowsのrobocopyコマンドを操作するGUIツールを作った。robocopyはWindowsに標準で入っているファイルコピーのコマンドで、バックアップや同期に使える強力なツールだが、コマンドラインでしか動かない。オプションも多い。毎回コマンドを手打ちするのは面倒だし、実行結果も見にくい。
ほしかったのは、コピー元とコピー先をGUIで指定できて、進捗がリアルタイムで見えて、エラーがあれば一目でわかるツール。加えて、定期実行のスケジューラーと、コピー後のチェックサム検証もほしかった。
このツールをAIコーディングツール（Claude Code）で作った。自分ではコードを1行も書いていない。やったのは「何がほしいか」を言葉で伝えることだけ。
作業時間はトータルで数時間。数日に分けて、空いた時間に少しずつ進めた。できあがったのは、C#/.NET 8.0のWindows Formsアプリケーション。進捗表示、エラーログの抽出、一時停止・再開、定期実行スケジューラー、チェックサム検証——機能としては十分に実用的なものになった。ソースコードはGitHubで公開している。
「何がほしいか」を伝える力だけが問われる
以前の記事で「AIにコードを書かせるとき、最も重要なのは何を書くかの指示だ」と書いた。
→ AI時代の内製DXエンジニア ── 実装の先にある仕事が本業になる
今回のツール作成で実感したのは、まさにこれだった。C#のWindows Formsの書き方を自分が知っている必要はなかった。SplitContainerのレイアウトも、ConcurrentQueueによるバッファリングも、robocopyの出力パースも、すべてAIが書いた。
自分がやったのは、「バックアップの進捗をリアルタイムで見たい」「エラーだけ別パネルに出したい」「定期実行できるようにしたい」——こうした要求を伝えること。そして出てきたものを動かして、「ここが違う」「これも追加で」とフィードバックを返すこと。
これは7485で書いた「VBAの関数をAIに書かせる」の延長にあるが、規模がまったく違う。関数1つではなく、アプリケーション1本を丸ごとAIが書いた。
こういうツールが社内には山ほど必要になる
robocopyのGUIラッパーは自分用に作ったツールだが、中小製造業の社内にも似た状況はいくらでもある。
- 図面PDFを取引先ごとのフォルダに自動振り分けしたい
- 検査データのCSVをまとめて月報のフォーマットに変換したい
- 共有フォルダの特定ファイルが更新されたら通知がほしい
- 古い形式のデータを新しいシステムに流し込む変換ツールがほしい
どれも「あったら便利だけど、作るほどでもない」と思われてきたもの。業者に頼めば見積もりだけで数十万円になるし、自分で作るにはVBAの外に出る必要がある。結局、手作業のまま放置される。
AIコーディングツールは、この「作るほどでもない」の閾値を大きく下げる。数時間で実用的なツールが作れるなら、「作ったほうが早い」になる。
DX担当者の武器が増える
以前の記事で「1人のDX担当者がカバーできる範囲が変わる」と書いた。そのときはVBAの関数レベルの話だったが、今はアプリケーション単位の話になっている。
→ 内製DXの開発にAIを使う ── VBAでも「AIに書かせる設計」はできる
VBAで済む業務改善はVBAでやればいい。しかし「VBAでは無理」と諦めていた領域——GUIツール、ファイル処理、外部コマンドの制御——にも、AIを使えば手が届くようになった。DX担当者の道具箱に、新しい武器が加わったということになる。
→ 内製DXエンジニアの道具箱 ── Excel・テキストエディタ・SQLの組み合わせ
ただし、以前の記事で書いた注意点はそのまま当てはまる。AIが書いたコードを外部に公開するなら、セキュリティの担保が必要になる。今回のような社内ツール——社内ネットワークに閉じて、ユーザーが自分だけ、あるいは社員数人——であれば、リスクは低い。こういうツールこそ、AIコーディングの最も安全な適用先になる。
作れなかったものが作れるようになっている
以前の記事で「挑戦自体が資産になる」と書いた。
→ AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由
今回のツールは、その具体的な一例になる。C#を深く知らなくても、GUIフレームワークの経験がなくても、「何がほしいか」を言葉で伝えられれば、実用的なツールが手に入る。
内製DXの範囲は、大きなシステムだけではない。日常の手作業を1つ自動化する小さなツール。それが数時間で作れるなら、手を動かさない理由がなくなる。
このシリーズの他の記事：