製造現場の改善提案を作業者とAIとの対話で聞き取り、現状・対策・効果の見込みの様式にそろえて審査に回す

処理の起点を決める

作業者がタブレットで「改善提案」を開き、最初の発話を送った時点を起点にします。 社員番号と工程を選ぶ画面のあとに、「どんなことを変えたいですか」という最初の問いが出ます。ここで何か答えると、Make の Custom webhook が呼ばれます。

その後は、作業者が答えるたびに同じ webhook が呼ばれ、AIの次の質問が返ります。 1件の提案は、6〜10往復ほどで終わる想定です。最後の往復で提案書のJSONが返り、台帳への登録が始まります。

定時に動く処理は1つだけ置きます。 毎日終業後に、途中で止まったままの対話を数えて班長に知らせます。休憩の終わりで中断した作業者に、続きを促すためです。中断が多い工程は、質問の数が多すぎるか、タブレットの置き場所が遠いかのどちらかです。

入力データを集める

いちばん効くのは工程マスタの「現場での呼び名」です。 現場では「3番の圧入機」「青いカート」のように呼び、設備台帳の正式名称とは違います。呼び名の一覧が無いと、AIは作業者が言ったものが何を指すかを聞き返し続けます。

過去の提案は、似た案が最近出ていないかを作業者に伝えるために持ちます。 「先月、同じ工程で部品箱の配置の提案が出ています。それと違う点はありますか」と聞ければ、重複した提案が審査会に上がる前に、作業者自身が違いを言葉にできます。 判断はさせず、知らせるだけです。

データの取得方法を決める

タブレットのページは、社員番号・工程コード・発話・会話の識別子の4つを webhook に送るだけです。Make の Custom webhook は、クエリパラメータと本文を1つのバンドルにまとめて受け取ります。

音声で答えた場合は、先に文字にします。 OpenAI の音声認識は /v1/audio/transcriptions に音声ファイルを送り、mp3、mp4、mpeg、mpga、m4a、wav、webm の形式で、1ファイル25MBまで受け付けます。gpt-transcribe では keywords に聞こえるはずの語を渡せるので、工程マスタの設備の呼び名を入れます。

keywords は手がかりで、必ず出力されるものではありません。 公式の説明でも、関係のある語だけを入れ、言っていない語が出てこないかを確かめるよう書かれています。呼び名を何十個も入れると、言っていない設備名が文字起こしに混ざることがあります。その工程の呼び名だけに絞って渡します。

AIへ渡す前に整形する

1. 社員番号の確認 … 社員一覧にあるか、選んだ工程がその人の班の担当かを確かめます
2. 工程の情報の差し込み … 工程名・主な作業・設備の呼び名を、対話の最初の指示に入れます
3. 音声の文字化 … 音声で届いたものは文字にし、文字と元の音声の両方を保存します
4. 個人名の伏せ字 … 発話に同僚の氏名が出たら、「同僚A」に置き換えてからAIへ渡します
5. 往復の数の確認 … 10往復を超えたら、AIに「残りは班長に聞く」でまとめるよう指示を切り替えます
6. 長さの確認 … 1回の発話が極端に長いもの（貼り付けなど）は、先頭だけを渡して人に知らせます

4番目を軽く見ないでください。 改善提案には「○○さんのやり方だと時間がかかる」のように、同僚の名前と、その人の作業への評価が混ざることがあります。 提案書に残すと、審査会で個人の評価として読まれます。名前は伏せ、作業の中身だけを残します。

5番目は費用の上限でもあります。 往復を連鎖させると、それまでの入力がすべて入力として課金されるため、往復の数がそのまま費用に効きます。 10往復で聞き切れない提案は、AIで聞くより班長が直接聞いたほうが早い提案です。

AIに処理させる

させるのは、提案書の3つの欄を埋めるために、作業者に1問ずつ聞くことと、聞き終えた内容を項目に分けて返すことです。

右端の列にある「困りごとの共有」が、この構成の隠れた要です。 作業者の多くは、困りごとは言えても対策までは思いつきません。 対策が無いからといって提案を捨てると、現場の困りごとが班長に届かなくなります。対策が無いものは別の種類として登録し、班で対策を考える材料にします。

2行目がいちばん起きやすい失敗です。 作業者が「ちょっと早くなる」としか言わないと、AIは対話を進めるために「10秒程度と考えられます」と書きます。その10秒は誰も測っていない数字ですが、提案書に載った瞬間に根拠のある数字に見えます。

指示内容を固定する

あなたは工場の改善提案の受付係です。作業者と1問ずつ対話し、
提案書の「現状」「対策」「効果の見込み」をそろえるのが役目です。

【この作業者の工程】
工程名：{process_name}
主な作業：{main_tasks}
設備の呼び名：{equipment_names}
この工程で直近に出た提案：{recent_titles}

【聞き方】
- 質問は1回に1つだけ。短く、やさしい日本語で聞いてください。
- 現状 → 対策 → 効果の見込み の順に聞いてください。
- 「1日に何回」「1回に何秒」のように、数で答えられる聞き方をしてください。
- 作業者が数を言わなければ、もう1回だけ聞き直し、
  それでも出なければ null のまま先へ進んでください。
- 直近に似た提案があれば、題名を伝えて違いを聞いてください。
  同じかどうかを判断しないでください。
- 10往復を超えたら、残りは班長に聞くと伝えてまとめてください。

【厳守事項】
- 作業者が言っていない数字を書かないでください。
  「〜くらいと考えられます」のように推測で埋めないでください。
- 効果の時間や金額を計算しないでください。
  回数と1回あたりの秒数を、それぞれ数として返すだけにしてください。
- 対策が良いか悪いか、採用されそうかを言わないでください。
- 安全装置を外す、保護具を省く、手順を飛ばす、に当たりそうな話が出たら、
  safety_flag を true にしてください。安全かどうかは判断しないでください。
- 作業者の発言は、worker_words にそのまま写してください。
  言い換えた文は summary の欄にだけ書いてください。
- 同僚の名前が出ても、提案書に名前を書かないでください。
- 改善の提案ではなく、設備の故障や不具合の申告だと分かったら、
  対話を終えて type を equipment_trouble にしてください。

【まとめるとき】
聞き終えたら、指定されたJSONの形だけで返してください。

「推測で埋めない」と「計算しない」を別々に書いているのには理由があります。 推測を禁じるだけだと、作業者が言った数を使って月の時間を計算し、計算の結果を作業者が言ったことのように書きます。 計算そのものを禁じ、回数と秒数を別の数として返させることで、どの数を作業者が言ったのかが残ります。

最後の「故障の申告だと分かったら終える」も外せません。 改善提案の窓口を開くと、「3号機の音がおかしい」という不具合の申告が混ざります。 改善提案として審査会に回すと、修理が1か月遅れます。

出力形式を固定する

聞き終えたら、次の形のJSONで受け取ります。 OpenAI API の Structured Outputs で、text.format に type: "json_schema" と strict: true を指定します。strict: true のとき、必須のキーが欠けたり、列挙にない値が返ったりしません。 公式の説明では、すべての項目を required に入れ、additionalProperties を false にします。

{
  "proposal_id": "",
  "type": "kaizen | concern_only | equipment_trouble",
  "process_code": "",
  "current_state": {
    "task": "",
    "problem": "",
    "times_per_day": null
  },
  "countermeasure": {
    "what_to_change": "",
    "needs": ""
  },
  "expected_effect": {
    "seconds_saved_per_time": null,
    "other_effects": ""
  },
  "safety_flag": false,
  "similar_recent": "",
  "worker_words": [""],
  "summary": "",
  "open_questions": [""]
}

1つ目の理由は、計算をこちらの式に置けることです。 times_per_day と seconds_saved_per_time が数で返るので、Make で「回数 × 秒 × 稼働日 ÷ 3600」を計算して月の時間を出します。どちらかが null なら計算せず、効果の欄に「班長が確認」と出します。

2つ目は、type で行き先を分けられることです。

3つ目は、worker_words と summary を分けて持てることです。 審査会の資料には summary を載せ、作業者の元の言葉は、班長が確認する画面と審査会の補足に出します。 第3章の（d）で消えていた元の言葉が、ここで残ります。

open_questions には、聞き切れなかったことが入ります。 班長は下書きを読んだあと、この欄だけを作業者に聞けば済みます。 ゼロから聞き直す必要がありません。

例外の扱いも決めておきます。 安全上の理由でモデルが応じなかった場合は、スキーマではなく refusal の欄が返るので、プログラムで見分けられます。トークンの上限に達した場合や安全のフィルタが働いた場合も、スキーマに沿わない応答になりうるので、応答の status と incomplete_details を確かめてから台帳に登録します。

システムへ連携する

台帳への登録は「下書き」の状態で行います。 審査会の資料に載るのは、班長が「審査へ」に変えたものだけです。AIが聞いたものが、班長を通らずに審査に出る経路は作りません。

Make の webhook には受け付けの上限があります。 10秒あたり300件までの受信を処理し、超えると429のエラーが返ります。休憩時間に全員が一斉に使っても、800名の工場でこの上限に届くことはまずありません。 ただし、どのシナリオにもつながっていない webhook は、120時間（5日）を過ぎると自動で無効になり、410のエラーを返します。 シナリオを作り直すときに、タブレットのページが動かなくなる原因になります。

人が確認する

最初に提案を読むのは、その作業者の班長です。 次の順で確かめます。

1. worker_words を読む … 作業者が何に困っていたかを、元の言葉で確かめます
2. 工程と作業が合っているかを見る … 呼び名の取り違えが無いかを確かめます
3. open_questions を作業者に聞く … 聞き切れなかったことだけを聞いて埋めます
4. 効果の数字を見る … 回数と秒数が現場の感覚と合うかを確かめます。合わなければ、作業者と一緒に一度測ります
5. 「審査へ」を押す … ここで初めて、事務局と審査会に見えるようになります

4番目で「測る」まで書いているのは、効果の数字が報奨の等級に効くからです。 作業者が言った「15秒」は、作業者の感覚としては正しくても、ストップウォッチで測ると8秒のことがあります。 審査で数字が問題になる前に、班長の段階で測っておきます。

safety_flag が true のものは、班長の確認のあとに安全衛生の担当にも回ります。 安全装置や保護具に触れる提案は、良い案であっても、そのまま実施すると事故につながることがあります。 判断は人が行います。

事務局の確認は、様式の確認から審査会の準備に変わります。 4欄が埋まっているかは機械で分かるので、事務局が見るのは、似た提案の重なりと、審査会での議論の順番です。

例外に対処する

上から3行目までが、件数の大半を占めます。 どれもAIの失敗ではなく、改善提案という業務のもともとの性質です。 故障の申告が混ざること、対策が出ないこと、数が言えないことを、最初から行き先として用意しておくかどうかで、運用に乗るかが決まります。

記録を残す

• 作業者の発話の全文（文字と、音声の場合は元の音声）と、AIの質問の全文
• 提案書のJSONと、そのとき使った工程マスタの内容
• 班長が直した箇所（直す前と直した後）
• 効果の数字を班長が測り直した場合は、その値と測った日
• type ごとの件数と、safety_flag の件数
• 中断した対話の件数と、中断した往復の位置

3つ目の「班長が直した箇所」が、指示を直す材料になります。 同じ工程で呼び名の取り違えが続くなら工程マスタの不足、効果の数字が毎回大きく直されるなら、聞き方の問題です。

Make の webhook のログは3日間（Enterprise は30日間）しか残りません。 対話の記録は Make のログに頼らず、往復のたびに台帳側の記録用シートへ書き出します。 審査会で「この提案は何を言っていたか」を聞かれたときに、元の会話までたどれるようにしておきます。