製造業の申請フォームを生成AIで設計｜入力項目を確かめる4手順

フォーム設計は、受付ルールを入力条件にする仕事

申請フォームを電子化しても、必要な情報が欠ければ担当者の確認は残ります。最初に「何を受け付けるか」「どの条件で何を記入してもらうか」を会社で決めます。生成AIへはそのルールを渡し、項目名、入力形式、必須条件、説明文の案を依頼します。

今回作るのはフォームの仕様と、入力を確かめる紙の資料です。フォームを実装したり、申請を実際に受け付けたりする演習ではありません。受付に必要な情報がそろうことと、会社が申請を承認することも別です。見学先の安全条件や受入可否を、生成AIの入力判定で決めないようにします。

以下は会社が承認したと設定する架空ルールです。実際の来訪者、個人情報、申請記録、当社研修の提供仕様を示しません。実務では業務責任者にルールの現在の版を確認し、会社が許可した情報と利用環境で設計します。名前を置き換えただけで入力可能と判断しないでください。

受付条件を見る4手順で、ルールと項目を対応させる

AIの案に「あると便利そうな項目」があっても、原ルールにない必須項目はそのまま追加しません。何のために必要かを確認し、追加するなら会社でルールを更新してから仕様へ反映します。設計中の思いつきを正式な受付条件に変えない手順です。

架空の来訪受付ルールを、原資料にする

教材の原資料は「来訪受付ルールV1」です。対象は、社員が社内窓口として申し込む工場見学または打合せです。以下の6条件だけを使用します。

連絡先、外部の氏名、車両情報などは今回の原ルールにありません。必要性を検討することはできますが、教材の完成案には追加しません。この例の人数や区分は説明用の条件であり、一般の製造業が採用すべき受入規則ではありません。

指示文と、条件付き項目仕様の完成見本

F07は、会議室での打合せを選んだときは対象外とする設計案です。実装時に表示を切り替えるか、記入不要と示すかは、採用するツールと担当者に確認します。本記事から特定のフォーム製品がその動作を提供すると判断しないでください。

正常・欠落・分岐の入力を、期待値で照合する

次は実ツールのテスト結果ではなく、設計を確かめるために作った入力と期待結果です。共通の入力は、社内窓口「総務A」、希望日2026年10月14日、開始10:00、終了11:00、来訪3人とします。異なる条件を各ケースに記載します。

確認者は、期待値に対応する原ルールを指して説明できるかを見ます。「打合せでも見学工程が必須」「6人は申請禁止」「項目がそろえば来訪承認済み」は、原資料と違う設計です。条件を修正したら、影響するケースも一緒に更新します。

経営者は、ルールの確認と実装の担当を分けて用意する

研修の成果物は、原ルール、指示文、項目仕様、入力と期待値、差分の確認記録です。社員が必須と条件付きの違いを説明し、正常例以外でも判断できるかを確認します。実装できる人がいても、業務の条件を説明できる確認者がいなければ、先に原ルールを整理する必要があります。

フォーム化へ進む場合は、保存先、閲覧する人、実際の入力判定、差戻し方法を担当者と確認し、採用環境でテストします。この紙資料だけで実装済みと扱わず、実際に表示・入力した記録を残してください。受付後の確認や受入承認も、会社が決めた業務として別に運用します。

まとめ

申請フォームの項目設計は、原ルールを固定し、項目仕様を作り、ケースと期待値を用意し、原ルールへ照合する4手順で進めます。必須と条件付きの項目を分け、人数や時刻の境界も確認しましょう。入力情報がそろうこと、フォームが実装できること、申請が承認されることをそれぞれ確かめます。