Excel・Power BIの次はAIコーディング？製造業DXが再びコードに戻る理由

ローコードの先で、なぜもう一度コードを選んだのか

私は製造業で、Excel、Python、BIツールを使いながら、データ分析と可視化に携わってきました。

以前の私にとって、Webアプリ開発は少し遠い領域でした。HTML、CSS、JavaScriptだけでなく、フレームワーク、サーバー、デプロイ、セキュリティ、Gitまで考える必要があります。製造技術やDXの仕事と並行して、一つずつ身につけるには技術的なハードルを感じていました。

今はCodexなどのAIコーディング支援と対話しながら、Manufacturing CompassをNext.jsで開発しています。コードはGitHubで管理し、Vercelで公開しています。Cpkや実験計画法（DOE）の学習ツールも実装し、作って終わりではなく、機能追加やUI改善を続けています。

この経験から感じたのは、「BIの次は必ずWebアプリ」という単純な置き換えではありません。コードを書ける人が限られていた時代にはGUIが大きな価値を持ちました。AIによってコードを扱う入口が広がった今、用途によってはコードベース開発の方が速く、柔軟で、変更を追いやすくなっています。

Excelで頑張って可視化していた時代

製造現場でデータを見ようとしたとき、最初の選択肢は今でもExcelであることが多いと思います。

Excelは、少量のデータを確認する、一時的な分析をする、現場の人がその場でグラフを直す、といった用途では非常に使いやすい道具です。私もまずExcelで集計し、グラフを作り、報告資料へ貼り付けるところから始めました。

ただ、同じ報告を繰り返すようになると、手作業が増えます。コピーしたファイルが複数のフォルダに残り、どれが最新版か分からない。数式やマクロが複雑になり、変更したセルを後から追えない。担当者しか更新方法を知らない状態にもなりやすい。分析そのものより、更新作業へ時間を使う場面が増えていきました。

• 手作業が多く、更新のたびに同じ操作が発生する
• ファイルが増殖し、最新版や変更箇所が分かりにくい
• 数式・マクロ・更新手順が担当者へ依存する
• データ量や利用者が増えるほど運用負荷が上がる

Power BIなどのBIツールが、可視化を自動化した

BIツールによって、データ取得、加工、集計、可視化を一つの流れとして自動化しやすくなりました。

定型的なレポートや、多数の利用者が同じKPIを見る用途では、Power BIなどのBIツールは現在も有力です。既存のMicrosoft環境と接続し、決まった指標を同じ画面で確認するなら、専用のWebアプリを一から作るより素直な場合があります。

一方、実務で使いこなすには、データモデル、リレーション、DAX、Power Query、権限、更新設定、ワークスペース、ライセンスなどを理解する必要があります。コードを書かない画面であっても、データと業務の複雑さが消えるわけではありません。

画面やロジックを作り込むほど、GUI上の処理が入り組み、作成者以外が全体を追いにくくなることもありました。どこを変更したのか、前の状態と何が違うのかをレビューする作業は、一般的なファイル中心の運用ではコードほど細かく扱いやすくありません。

ただし、「Power BIでは変更管理できない」という意味ではありません。MicrosoftはPower BI Desktop projects（PBIP）でレポートとセマンティックモデルをテキストファイルとして保存し、Gitで管理する開発者向け機能を提供しています。確認時点ではプレビューと案内されており、利用環境やチームの成熟度を含めて選ぶ必要があります。

ローコード・ノーコードでも、複雑さは消えなかった

ローコード・ノーコードは、業務担当者が自分でアプリやワークフローを作れる範囲を広げました。

コードを最初から書かずに画面と処理を組み立てられることには、大きな価値があります。小さな申請、入力フォーム、定型的な通知など、ツールが想定する範囲に要件が収まるなら、短い距離で業務改善へ到達できます。

ただ、要件が複雑になると、今度はそのツール固有の式、コンポーネント、データ接続、権限、制限を学ぶ必要が出てきます。処理の分岐が増えると中身を追いにくくなり、細かなUIや独自ロジックで制約に当たる。ライセンス、利用上限、ベンダーロックインも設計条件になります。

コードを隠せば、要件やデータ構造の複雑さまでなくなるわけではありません。ローコードで複雑な仕組みを作ると、見えないコードに近いものを別の表現で保守することになります。

AIコーディングが、コードの入口を変えた

変化したのは、プログラミング知識が不要になったことではなく、自分ですべての行を書く必要が減ったことです。

Manufacturing Compassでは、私が作りたい機能、利用者にどう見せたいか、守るべきルールを伝え、AIとの対話を通じてコードの生成、エラー調査、修正、リファクタリング、テスト、ドキュメント更新を進めています。分からないコードを説明させ、差分を確認し、必要ならやり直す。この往復があることで、以前はハードルを感じていたWebアプリ開発へ入れました。

人間の仕事がなくなったわけではありません。どの課題を解くか、どのデータを使うか、誰が使うか、何を公開しないかは人間が決めます。生成されたコードが要件を満たすか、セキュリティ上の問題がないか、テストすべき境界はどこかも確認が必要です。

AIコーディングは、設計を不要にする道具ではなく、要件と実装の距離を縮める道具だと感じています。製造技術者やDX担当者が持つ工程知識と問題意識を、試作品へ変えやすくなったことが大きな変化です。

AIコーディングで最も大きかったのは、GitHubで変更点を管理できること

開発が速いこと以上に、私がコードベース開発の価値を感じたのは、変更そのものが履歴として残る点です。

GitHubでは、どのファイルのどの行を変更したかを差分で確認できます。変更前後を並べ、なぜ変えたかをコミットメッセージへ残せます。問題が起きたときは、どの変更から挙動が変わったかを追い、以前の状態へ戻す判断もしやすくなります。

Pull Requestを使えば、公開前の変更をまとめ、人やAIへレビューを依頼できます。複数人ならコメントを残し、修正を提案し、承認してから統合できる。一人で開発していても、変更をひとまとまりにして見直すだけで、意図しない修正へ気づきやすくなります。

AIへレビューを依頼できることも利点ですが、AIの指摘をそのまま採用するわけではありません。差分、要件、テスト結果を合わせて人が判断します。AIレビューは責任者の代わりではなく、見落としを減らすための二つ目の視点です。

Excel、BI、ローコードにも履歴や開発者向け機能はあります。ただ、一般的な運用では「完成したファイル」や「現在の画面」を共有することが多く、細かな変更理由まで資産として残しにくい場合があります。コードベース開発では、完成物だけでなく、改善の過程も管理対象にできます。

GitHubとVercelをつなぐと、公開までの距離が短くなる

従来のWeb公開では、サーバー、実行環境、ドメイン、SSL、更新手順を個別に準備するイメージがありました。

VercelへGitリポジトリを接続すると、ブランチへの変更からビルドとデプロイを自動化できます。Pull Requestには確認用のPreview URLを作り、本番ブランチへ統合した変更をProductionへ反映する運用もできます。Manufacturing Compassも、GitHubで管理したNext.jsのコードをVercelへデプロイしています。

私にとっては、ローカルで作ったものをどのサーバーへ置くか考える状態から、GitHubへ変更を反映し、ビルド結果を確認してURLで共有する状態へ変わりました。試作品を見てもらい、フィードバックを受け、次の差分を出す循環が作りやすくなります。

ただし、デプロイが簡単であることと、企業データを安全に扱えることは別です。製造データ、設備ログ、品質情報、顧客情報を外部クラウドへ出してよいとは限りません。情報セキュリティ、社内ネットワーク、認証、権限、データ保存場所、利用規約、監視、障害対応、退職・異動時の運用まで確認する必要があります。

BIツールとAIコーディングは、目的で使い分ける

選択肢が増えたのであって、すべてをコードへ置き換える必要はありません。

定型的な経営レポートや、組織内の多数の利用者が同じKPIを見るなら、BIツールの管理機能や既存環境との接続が生きます。分析者が一時的に仮説を確かめるなら、ExcelやPythonの方が早いこともあります。

一方、独自UI、細かな操作、複雑な業務ロジック、外部公開する学習体験、コード単位の変更管理が必要なら、AIコーディングを使ったWebアプリ開発を検討できます。最初から全社システムを作るのではなく、機密性の低いデータで小さな試作品を作り、運用条件を確かめるのが現実的です。

AI生成コードを、動いたという理由だけで公開しない

AIが試作品を作れる速度が上がるほど、確認を省かないことが重要になります。

見た目が動いていても、入力値の境界、エラー時の挙動、認証、権限、依存ライブラリ、ログ、バックアップが適切とは限りません。AIは存在しない仕様を前提にしたり、古い書き方や不要な権限を提案したりすることがあります。

特に製造現場では、設備停止、品質判定、作業指示へつながる画面を、試作品と同じ感覚で運用できません。利用者、承認者、データの責任者、障害時の代替手段を決め、必要に応じて情報システムやセキュリティ部門の確認を受けます。外部クラウドを使えない環境なら、社内基盤や既存BIを選ぶ方が適切です。

• AIへ機密情報、顧客情報、未公開の製造条件をそのまま入力しない
• 生成されたコードと依存ライブラリを人が確認する
• 認証、権限、入力検証、ログ、バックアップを要件に含める
• 単体テストだけでなく、実データに近い条件と異常系を確認する
• 公開・更新・障害対応・廃止までの運用責任を決める

AI時代の製造業DX担当者は、何を学ぶべきか

自分ですべてのコードを書く必要は減っても、生成されたものを評価する知識は残ります。

最初に学ぶなら、GitとGitHubの基本、データ構造、SQL、API、Webアプリの構造を優先します。そこへセキュリティ、テスト、要件定義を加えると、AIの提案を採用してよいか判断しやすくなります。

AIへの指示方法も必要ですが、長いプロンプトを暗記することが中心ではありません。目的、利用者、入力、期待する出力、制約、完了条件を説明する力が重要です。製造現場で「何を改善したいか」「どのデータなら判断できるか」を考えてきた経験は、そのまま要件定義に生かせます。

コードを一から書けなくても、差分を読んで、怪しい箇所を質問し、テスト結果を確認するところから始められます。AIを使うほど、分からないものを分からないまま公開しない判断力が必要になります。

戻ってきたのは、手書きコーディングの時代ではない

BIツールやローコードが不要になったのではなく、コードベース開発を選べる範囲が広がりました。

Excelは一時的な分析に強く、BIは定型レポートと共通KPIに強い。ローコードは想定された範囲の業務アプリを素早く作れます。AIコーディングは、独自の画面や処理を作り、GitHubで差分を管理し、継続的に改善したい用途で新しい選択肢になります。

人間の役割は、コードを一行ずつ書くことから、課題を定義し、設計し、生成されたものを確認し、公開するか判断することへ移っています。私はManufacturing Compassを作るなかで、その変化を実感しました。

AIコーディングと製造業DXのよくある質問