AIにコードを書かせる時代は、もう来ている
以前の記事で、AIの具体的な未来予測を追いかけるより構えを取ることが大事だと書いた。その中で「コード生成は予想以上に早く実用化した領域」とも触れた。
→ AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由
Claude Code、GitHub Copilot、Cursor——こうしたAIコーディングツールを使えば、「こういう処理がほしい」と自然言語で説明するだけで、動くコードが出てくる。完璧ではないが、ゼロから書くより格段に速い。
内製DXの開発にこれを使わない手はない。
1人のDX担当者がカバーできる範囲が変わる
中小製造業の内製DXは、たいてい1人か2人の担当者で回している。以前の記事で「大半はExcel VBAで回る」と書いたが、それでも1人が書けるコードの量には限界がある。
→ 中小製造業の内製DX ── Excel VBAで済む領域と、専用言語で作るべき領域
AIコーディングツールを使うと、この限界が緩和される。ロジックの実装速度が上がる。調べ物の時間が減る。「この関数、どう書くんだっけ」という停滞がなくなる。結果として、1人のDX担当者がカバーできる業務の幅が広がる。
以前の記事で「内製と外注の線引き」を書いたが、AIによって「1人で内製できる範囲」が広がることで、これまで外注に出していた開発の一部を内製に引き戻せるケースも出てくる。
ただし、VBAとAIの相性には偏りがある
ここからが本題になる。
AIコーディングツールは万能ではない。特にExcel VBAの領域では、AIに書かせやすい処理と書かせにくい処理がはっきり分かれる。
AIが苦手なのは、シートを直接操作するコード。 セルの位置、シートの名前、レイアウトの構造——こういった「そのExcelファイル固有の文脈」に依存する処理は、AIに正確に伝えるのが難しい。「A列の3行目から始まるデータを、B列のヘッダーが"数量"の列と照合して……」という指示は、人間が口頭で説明するのと同じくらい曖昧になりやすい。結果として、出てくるコードはセルの参照位置がずれていたり、想定と違うシートを操作したりする。
AIが得意なのは、入力と出力が明確な純粋なロジック。 「日付と数量のリストを受け取って、月別の合計を返す」「単価と数量と割引率から金額を計算する」「2つの配列を共通キーで突合して差分を返す」——こうした処理は、入力と出力の仕様さえ伝えれば、AIはかなり正確なコードを書いてくる。
この差は、AIの能力不足ではなく、問題の構造に起因する。シート操作は「文脈依存」、ロジックは「文脈非依存」。AIは文脈非依存の問題が得意になる。
Excelでやりたいことを実現する手段は1つではない
Excelで何かをやりたいとき、実はいくつかの手段を重ねて使える。
まず、ワークシートの操作だけでできることが意外と多い。 A列とB列の文字列を結合する、オートフィルで連番を振る、並べ替えやフィルターでデータを整理する。これはコードを一切書かない操作だが、データの下ごしらえとして重要な層になる。
その上に、ワークシート関数で計算を加える。 VLOOKUP、SUMIFS、INDEX/MATCHなど。以前の記事で書いた「見る」の範囲はこれで対応できる。
→ 中小製造業のExcel業務が「1シート」で止まる理由 ── 関数の限界と次の一歩
さらに、VBAでシートを操作する。 セルを読み書きする、シートを追加する、ファイルを開いて処理する。以前の記事で書いた「処理する」の領域はここから始まる。
そして、VBAでオリジナルのワークシート関数を作る。 VBAでFunctionプロシージャを書くと、ワークシート上で標準の関数と同じように使える。自社の業務に特化した計算——独自の原価計算ロジック、特殊な納期の算出、自社ルールに基づく割引計算——を関数化できる。
これらは排他的ではない。ワークシートの操作でデータを整え、標準関数で基本的な計算を行い、足りない部分をVBAで補い、複雑なロジックはオリジナル関数に切り出す。層を重ねて使うのが現実的なやり方になる。
ここにAIとの相性を重ねると、こうなる。
| 手段 | AIとの相性 | 理由 |
|---|---|---|
| ワークシート操作 | — | 手作業なのでAIの出番がない |
| ワークシート関数 | 中 | 関数自体は定型だが、シートのレイアウトに依存 |
| VBAでシート操作 | 低 | セル位置・シート構造への依存が大きい |
| VBAでオリジナル関数 | 高 | 入力→処理→出力が明確。純粋なロジック |
AIと最も相性がいいのは、オリジナルのワークシート関数。 入力と出力が明確で、AIにとって「仕様どおりの関数を書く」という得意な形に収まる。しかも、VBAの中だけで使う内部的なFunctionとしてではなく、ワークシート関数として作ると、シート上でそのままテストできる。セルにテスト用の値を入れて、関数を呼び出して、期待通りの結果が返ってくるか確認する。VBAのデバッガを使うより直感的で、動作確認が速い。
AIの登場によって、この層の重ね方に新しい判断基準が加わった。AIに書かせやすい部分を意識的にオリジナル関数として切り出すという設計判断になる。
ロジックをFunctionに切り出す
VBAで何かの処理を書くとき、以前なら1つのSubプロシージャにまとめることが多かった。シートからデータを読んで、計算して、結果を書き込む。全部が一つの塊になっている。
これからは、意識的に分けたほうがいい。
シートを触る部分（入出力） と ロジックの部分（計算・判断） を分離する。ロジックはFunctionとして切り出す。Functionは引数でデータを受け取り、戻り値で結果を返す。シートのことは知らない。
こうすると、Functionの部分はAIに書かせられる。「こういう入力を受け取って、こういう処理をして、こういう出力を返すFunctionを書いて」——これはAIが最も得意とする指示の形になる。
シートを触る部分——どのセルから読んで、どのセルに書くか——は、そのファイルの構造を知っている自分が書く。ロジックはAIに任せる。この役割分担が、VBAでAIを活かすための設計方針になる。
コードの品質も上がる
「AIに書かせやすい構造にする」ことが、そのままコードの品質向上にもつながる。
ロジックをFunctionに切り出すということは、処理の責任を明確に分離するということ。以前の記事で、VBAが大きくなるとコードの見通しが悪くなり、「一部を変えたら別の場所が壊れる」問題が起きると書いた。Functionへの分離は、この問題の緩和になる。AIのために構造を整えたら、結果として保守しやすいコードになった——という副産物がある。
まずは1つの関数をAIに書かせてみる
やることは単純になる。
今作っているVBAの中で、計算や判断のロジックが入っている部分を見つける。その部分をFunctionとして切り出せないか考える。引数と戻り値を決める。そして、AIに「こういう関数をVBAで書いて」と頼んでみる。
出てきたコードが完璧かどうかはわからない。テストは必要になる。しかし、ゼロから自分で書くよりは速い。そして何度かやっていると、AIにどう指示すれば精度が上がるかの肌感覚がついてくる。
以前の記事で「挑戦自体が資産になる」と書いた。コーディングにAIを使うことは、その最も具体的で、効果の見えやすい入口になる。
→ AIの具体的な未来予測はどうでもいい ── それでも中小製造業が今から触るべき理由
このシリーズの他の記事：