導入
「現場の要望通りに作ったはずなのに、なぜ使われないんだ？」
皆さんも、製造業の現場でこんな嘆きを耳にしたことはありませんか？ DX推進担当者が綿密にヒアリングし、分厚い要件定義書を作成して外注ベンダーに依頼した在庫管理アプリ。しかし、いざ現場に導入してみると、「ボタンが小さすぎて軍手で押せない」「入力項目が多すぎて作業のリズムが狂う」「そもそも、この工程は先月廃止された」といった厳しいフィードバックが容赦なく寄せられます。
結果としてアプリは放置され、現場は慣れ親しんだ紙とExcelに逆戻り……。経営者としてもエンジニアとしても、これほど悲しい結末はありませんよね。
製造現場のアプリ開発において、「完璧な仕様書」を目指すことは、かえってプロジェクトの課題を増やす要因になると私は考えています。変化の激しい現場、言語化されにくい暗黙知、そしてITリテラシーの格差。これらすべてを静的なドキュメントだけで埋めることは不可能です。
多くのプロジェクトで手戻りが発生し、追加のコストや期間が浪費される傾向があります。そこでビジネスへの最短距離を描くために重要なのが、「書く前に、作れ」というプロトタイプ思考です。
かつては、動く画面を作るために高度なプログラミングスキルと膨大な時間が必要でした。しかし今は違います。生成AI（Generative AI）とローコードプラットフォーム（Low-Code Platform）、さらには各種AIコーディングツールを駆使すれば、現場の雑談レベルのメモから「実際に動くプロトタイプ」を即座に生成し、仮説を検証できる時代なのです。
本稿では、長年の開発現場で培った知見をベースに、「仕様書なしで合意形成するプロトタイプ駆動開発」の具体的な方法を解説します。AIを単なる「コード生成機」としてではなく、現場と開発者を繋ぐ「翻訳機」として活用する、実践的かつ先見的なエンジニアリング・アプローチです。
仕様書の修正に時間を溶かすのはやめて、現場が本当に使いやすいアプリを最速で創り上げましょう。
なぜ製造現場のアプリ開発は「要件定義」で課題が生じやすいのか
まず、技術の本質を見極めるために現状を把握しましょう。なぜ、製造業において従来のシステム開発アプローチ、特にウォーターフォール型の要件定義が機能しないのでしょうか。多くのプロジェクトが「要件定義」というフェーズで、既に致命的な課題を抱えています。
「現場の言葉」と「システムの言葉」の翻訳ロス
製造現場には、その現場特有の「方言」が存在します。「チョコ停」「段取り替え」「歩留まり」といった一般的な用語でさえ、工場やラインによって定義が異なることは珍しくありません。さらに、「ちょっといい感じに調整しておいて」や「いつものあれで」といった、コンテキスト依存度の高いコミュニケーションも日常茶飯事です。
DX担当者やITエンジニアがヒアリングで「業務フローを教えてください」と尋ねると、現場は「標準的な（理想的な）フロー」を答えます。しかし、現場の実態は例外処理の塊です。「A部品が欠品したときは、B部品を仮置き場から持ってくるけど、その時は在庫システムには入力しない（後でまとめてやる）」といった「運用でのカバー」こそがシステム化すべき本質的な要件なのですが、これはヒアリングシートには現れにくいものです。
この「現場の暗黙知」を、エンジニアが「データベースの正規化」や「ロジック」というシステムの言葉に翻訳しようとした瞬間、情報の欠落が発生します。これが、完成後に「これじゃない」と言われる最大の原因の一つです。
紙文化からの脱却におけるUXの壁
オフィスワーカー向けの業務システムと、製造現場向けのアプリでは、求められるUX（ユーザー体験）が根本的に異なります。
- 環境要因: 油汚れ、粉塵、騒音、手袋着用、不安定な照明。
- 操作要因: 立ち仕事、歩きながらの操作、視線の移動。
- 心理要因: デジタルツールへの不慣れ、変化への抵抗感。
仕様書上の「在庫数を入力する」という一行は、現場では「汚れた手袋を外し、ポケットから端末を取り出し、小さなキーボードで数値を打ち込み、また手袋をする」という過酷な作業を意味するかもしれません。このUXの壁は、紙の画面遷移図やワイヤーフレームを見せるだけでは伝わりません。「まあ、いいんじゃない？」と同意されても、実際に触った瞬間に拒絶反応が起こるのです。
手戻りコスト
システム開発における「手戻りコスト」は、要件定義段階での修正コストを「1」とした場合、実装後の修正コストは雪だるま式に膨れ上がると言われています。
自動車部品メーカーでのシステム刷新事例では、要件定義に膨大な時間を費やしたにもかかわらず、リリース後の現場定着率が低迷したケースがあります。現場から「入力が面倒でラインが止まる」という不満が噴出し、追加改修に多大なコストと期間を要してしまいました。
もし、最初の1週間で「動くプロトタイプ」を現場に持ち込み、実際に触ってもらっていれば、この損失は防げたはずです。生成AIの活用は、この「最初の検証」にかかるコストを劇的に下げ、プロジェクトのROI（投資対効果）を最大化する鍵となります。
生成AI×ローコードが実現する「プロトタイプ駆動開発」の基本原則
課題が明確になったところで、解決策に踏み込みましょう。生成AIとローコードプラットフォームを組み合わせることで、開発プロセスはどう進化すべきか。ここでは3つの基本原則を定義します。
原則1：ドキュメントより先に「動く画面」を作る
従来の手順：
ヒアリング → 要件定義書作成 → レビュー → 設計書作成 → 実装 → テスト
新しい手順（プロトタイプ駆動）：
ヒアリング（音声/メモ） → AIによるプロトタイプ生成 → 現場レビュー（実機操作） → 修正 → 本実装
このパラダイムシフトにおいて重要なのは、「仕様書を書く時間を極限まで減らす」ことです。Power AppsやAppSheetなどのローコードツール、そしてChatGPTやClaudeのような最新のLLM（大規模言語モデル）を使えば、要件をテキストで入力するだけで、データベースのスキーマ定義から画面レイアウトまでを自動生成できます。
ドキュメントは「作るための指示書」ではなく、「作った結果の記録」として、後からAIに生成させればよいのです。
原則2：現場のフィードバックをその場で反映する
「持ち帰って検討します」という対応は今日からやめましょう。プロトタイプを見せながら、「ここの文字が小さい」「この項目はいらない」と言われたら、その場でローコードツールを開き、修正して見せる。あるいは、その場でAIに修正コードを書かせ、即座に反映する。
この「ライブコーディング」的な体験こそが、現場との強固な信頼関係を構築します。「自分たちの意見が即座に形になる」という実感を持ってもらうことで、現場は「使わされる側」から「一緒に作る側（共創パートナー）」へと意識が劇的に変化します。生成AIは、この即時対応を実現するための強力なアシスタントとなります。
原則3：捨てても良い「使い捨てプロトタイプ」を許容する
エンジニアは往々にして、最初から「拡張性」や「美しいアーキテクチャ」を追求しがちです。しかし、プロトタイプ駆動開発においては、「完成度60%で現場に出す」勇気を持つことが重要です。
最初のプロトタイプは、あくまで要件を洗い出すための「検証用ツール」であり、最終成果物ではありません。現場の反応が悪ければ、躊躇なく捨てる。AIを使えば構築コストは極小化されているため、サンクコスト（埋没費用）にとらわれず、アジャイルかつスピーディーに軌道修正が可能です。
鉄則①：現場の「音声・メモ」から初期案を自動生成する
ここからは具体的な実践手法について解説します。まずは、現場の泥臭い情報を構造化されたプロトタイプに変換するプロセスです。
非構造化データ（会議録音、手書きメモ）の構造化プロセス
現場ヒアリングの際、録音を行い、ホワイトボードに書かれた図や、現場担当者の手書きメモを写真に撮ります。
これらは「非構造化データ」です。従来は人間がこれを聞き直し、清書していましたが、今はマルチモーダル対応の生成AI（ChatGPTの最新モデルやClaudeなど）を活用できます。
具体的なステップ:
- 会議の録音データを文字起こしツールでテキスト化する。
- 手書きメモやホワイトボードの写真を撮る。
- これらをLLMに入力し、構造化データ（JSONやMarkdown）に変換する。
LLMを用いた業務フロー図とデータモデルの自動抽出
ここで重要なのは、AIに「製造業のコンテキスト」を深く理解させることです。単に「アプリを作って」ではなく、役割と制約条件を明確に伝えます。
プロンプト例（概念実証用）:
あなたは製造業DXに特化したシステムアーキテクトです。
以下の[会議録音テキスト]と[ホワイトボード画像の内容]に基づき、現場作業員が使用する「部品在庫引き当てアプリ」の要件を定義してください。制約条件:
- 現場はWi-Fiが不安定なため、オフライン動作を考慮すること。
- 作業員は厚手の軍手を着用しているため、誤操作を防ぐUIが必要です。
出力成果物:
- 業務フロー図: Mermaid記法で記述。
- データモデル: 必要なテーブル定義（カラム名、データ型）をCSV形式で。
- 画面構成案: 必要な画面リストと、各画面の主要機能を箇条書きで。
このプロンプトを実行すると、AIは見事な構造化データを出力します。曖昧だった「在庫が減るやつ」という言葉が、「Inventory_TransactionテーブルへのUpdate処理」として明確に定義されるのです。
プロンプトエンジニアリングによるUIイメージの出力
次に、このデータモデルをローコードツールに取り込みます。例えばPower Appsには「画像やFigmaからアプリを作成」する機能や、自然言語でアプリを構築できる「Copilot」機能が搭載されています。
AIが出力した画面構成案を基に、「手書き風のワイヤーフレーム」を画像生成AI（DALL-Eなど）で作成させ、それを読み込ませて画面の骨組みを作ることも可能です。
あるいは、Microsoft Dataverseのテーブル定義をCopilotに指示して作成させれば、基本的なCRUD（登録・参照・更新・削除）機能を持つアプリは数分で立ち上がります。ここまでが、検証のための「初期案」です。
鉄則②：現場作業者との「対話型修正」でUXを最適化する
初期案ができたら、息つく暇もなく現場へ持ち込みます。ここからが本番です。実際の利用シーンに合わせたUXのチューニングを情熱的に行います。
タブレット操作・軍手着用を想定したUI調整の自動化
現場でタブレットを渡すと、大抵の場合、最初の反応は「ボタンが押しにくい」です。標準的なローコードツールのボタンサイズは、マウス操作や素手のタップを想定しているからです。
ここで、AIを活用して一括修正を行います。最新の開発環境では、AIアシスタントに次のように指示することで、コードを書かずに修正が可能です。
「すべてのボタンコントロールの高さを80px以上に変更し、隣接するボタンとの間隔を20px以上空けてください。また、背景色と文字色のコントラスト比を4.5:1以上に設定し、薄暗い工場内でも視認できるようにしてください」
人間が一つ一つプロパティを変更していては日が暮れてしまいますが、AI駆動の開発環境であれば、自然言語での指示でスタイルの大規模なリファクタリングが瞬時に完了します。
現場の「使いにくい」をAIが分析して改善案を提示
現場作業員からのフィードバックは、往々にして感情的です。「なんかこの画面、イライラするんだよね」「ここの入力、面倒くさい」といった声です。
この「イライラ」の正体を論理的に突き止めるのにもAIが役立ちます。操作ログや、インタビュー音声をAIに分析させます。
「作業員Aさんは『イライラする』と言っています。この画面の入力フローにおいて、ボトルネックとなっている箇所を推測し、改善案を3つ提示してください」
AIは次のような鋭い洞察を返すかもしれません。
- 「バーコードスキャン後の『保存』ボタン押下までの動線が長く、視線移動が大きいためストレスになっています。スキャン完了時に自動保存するロジックへの変更を推奨します」
このように、感情的な不満を「機能要件」へと変換し、実装・検証するサイクルを高速で回します。
変更履歴の自動ドキュメント化
修正を繰り返すと、変更内容を管理できなくなる問題が発生します。ここでもAIの出番です。コードや設定の変更差分（Diff）をAIに読ませ、「変更履歴（Changelog）」を自動生成させます。
「YYYY/MM/DD: 現場フィードバックに基づき、在庫登録画面の保存処理を自動化。ボタンサイズを拡大」といった履歴が自動で残るため、後から「なぜこの仕様になったのか」を追跡することが容易になり、データガバナンスの観点でも非常に有効です。
鉄則③：属人化を防ぐ「AIコードレビュー」とガバナンス
ローコード開発、特に市民開発（現場主導の開発）で経営層が最も懸念するのが「野良アプリ化」です。作った本人が異動や退職をした瞬間、誰も触れないブラックボックスと化すリスクがあります。これを防ぐためのガバナンスも、AIによって自動化・最適化します。
市民開発における「野良アプリ」化のリスク管理
プロトタイプから本番運用へ移行する際、必ず「品質ゲート」を設けます。ここでAIを厳格な「コードレビューア」として活用します。
作成されたアプリの定義ファイル（Power AppsならYAMLや数式）をAIに解析させ、以下のようなチェックを行います。
- 命名規則: 変数名やコントロール名が
Button1,Label3のようなデフォルトのままになっていないか。 - ハードコーディング: 特定のIDやメールアドレスがコード内に直接書き込まれていないか。
- パフォーマンス: 非効率なデータ取得（N+1問題など）が含まれていないか。
生成されたロジックの解説ドキュメント自動生成
「コード自体がドキュメントだ」というのは理想ですが、ローコードの数式は複雑になりがちです。そこで、AIに「このアプリの設計書」を書かせます。
以下のアプリ定義ファイルを読み込み、開発者向けの詳細設計書を作成してください。特に、
OnSelectプロパティ内の複雑な分岐処理については、自然言語でロジックフローを解説してください。
これにより、引き継ぎ資料が自動的に生成されます。人間が書くドキュメントはすぐに陳腐化しますが、AIがコードから毎回生成するドキュメントは常に最新の状態を保てます。これは説明可能なAI（XAI）の考え方にも通じる、透明性の確保です。
セキュリティポリシーへの準拠チェック
製造データは機密情報の塊です。AIを用いて、アプリが組織のセキュリティポリシーに違反していないかを継続的に監査します。「外部のコネクタを使用していないか」「適切な権限設定がなされているか」を自動チェックし、リスクが高い場合はアラートを出したり、デプロイをブロックしたりする堅牢な仕組みを構築します。
陥りやすいアンチパターンと回避策
最後に、生成AIを活用したプロトタイピングにおいて、多くのプロジェクトが陥りがちな罠と、その回避策をお伝えします。
AIの出力結果を過信して検証を怠る
陥りがちな点: AIが生成したコードや数式を、中身を理解せずにそのまま本番適用してしまう。
リスク: AIはもっともらしい顔をして誤った情報を生成することがあります。存在しない関数を使ったり、論理的に破綻した条件分岐を作ったりします。最新のモデルであっても、このリスク（ハルシネーション）はゼロではありません。
回避策: AIはあくまで「優秀だが経験不足なジュニアエンジニア」として扱うこと。生成されたものは必ず人間（またはテストコード）が動作検証を行うプロセスを必須とします。特に在庫数や金額計算などのクリティカルなロジックは、専門家の目による厳重なチェックが必要です。
既存のレガシーシステムとの連携を後回しにする
陥りがちな点: スタンドアロン（単独）で動くプロトタイプで満足し、基幹システム（ERP）との連携を「後で考える」とする。
リスク: いざ連携しようとしたら、データ構造が全く合わず、根本的な作り直しが発生する。
回避策: プロトタイプの段階から、ダミーデータではなく「本番に近い構造のデータ」を使用すること。可能であれば、読み取り専用のAPI経由で実際のマスターデータを参照させることで、連携時のトラブルを早期に発見し、手戻りを防ぎます。
現場を置き去りにした機能過多なアプリ設計
陥りがちな点: AIを使えば機能追加が簡単なため、現場から言われるがままに全ての要望を盛り込んでしまう。
リスク: 機能過多で複雑怪奇なアプリは、現場の混乱と運用コストの増大を招きます。
回避策: 「引き算の美学」を持つこと。AIに「この機能を追加した場合のUXへの影響を予測して」と問いかけ、不要な機能を削ぎ落とす判断材料にします。プロトタイプは「機能を足すため」ではなく、「本当に必要な機能を見極めるため」にあるという本質を忘れないでください。
まとめ
製造現場のDXにおいて、最も貴重な資源は「現場の信頼」です。長期間待たせた挙句、使いにくいシステムを押し付けることは、この信頼を根底から損なう行為です。
生成AIとローコードを活用したプロトタイプ駆動開発は、単なる工数削減の手法ではありません。それは、現場と開発者が同じ画面を見ながら、リアルタイムに対話し、共に解決策を創り上げる「共創のプロセス」なのです。
- 仕様書を書く前に、AIで動くものを作る。
- 初期案を出し、現場のフィードバックをその場で反映する。
- AIによるガバナンスで、品質と継続性を担保する。
この実践的なアプローチを取り入れることで、プロジェクトは確実な成功へと向かい、現場が真に使いやすいアプリを生み出すことができるでしょう。皆さんの現場でも、ぜひ今日から「まず作る」一歩を踏み出してみてください。
コメント