【製造×AI活用】kintoneのAIエージェントで不具合報告の原因調査・対策案作成を自動化

「この割れ、前にも同じ工程で出なかったかな」

「最近、何か変えたことがあったかどうか、すぐには思い出せない」

「原因の欄、『調査中』のまま何日も空いている」

不具合報告を書くとき、こんなふうに手が止まった経験はないでしょうか。

ベテランなら、品名と工程を聞いただけで「それ、6月にも出たな。あのときは型を研磨した」と思い出せます。

でも、その記憶は担当者の頭の中にしかありません。

製造現場における不具合の究明や対策の記録は、単なる事務処理ではありません。「同じ失敗で現場の仲間を困らせたくない」「お客様に安心できる製品を届けたい」という、ものづくりに携わる人の“おもいやり”や責任感の表れです。
私たちがお届けしたいのは、単に報告書を埋める手間を省くだけの効率化ではなく、現場が大切にしてきたそうした知恵や配慮の心をテクノロジーで形にする「おもいやりDX」です。

過去のトラブルから学んだ先輩たちの知恵や気配りを、次の現場へ確実につなぐ仕組み。kintoneのAIエージェントに任せると、不具合を登録するだけで、過去の不具合報告・4M変更・設備の点検記録をたどり、判定・推定原因・対策案の下書きを根拠つきで出してくれます。ただし、過去の報告や点検の記録が kintone に残っていることが前提で、原因を見極めるのは人です。

この記事では、kintone の不具合報告で、原因と対策の下書きを AIエージェントに任せたところを、実際の画面と動画で紹介します。

この記事でわかること

• 不具合を登録したあと、AIエージェントが kintone の過去の報告・4M変更・工程マスタ・設備の点検記録をどう調べるのか

• 同じエージェントでも、記録しだいで判定が「再発」と「要確認」に分かれる理由

• 人が承認するまで不具合報告を書き換えない、下書きと承認の流れ

1. 不具合の原因調べで起きていること

不具合の原因に当たりを付けるには、本来こんな手順が必要です。

1. 不具合を見つけて、kintone に報告を登録する

2. 同じ品名・同じ工程の過去の不具合報告を探す

3. そのとき、原因を何と見て、どう手を打ったかを読む

4. 4M変更管理で、最近その品名に変更がなかったか確かめる

5. 工程で使う設備を調べ、直前の点検記録を見る

6. 判定・推定原因・対策案を書く

過去の不具合報告、4M変更履歴、工程マスタ、設備点検記録。
原因を特定するためには、複数のシステムや台帳を個別に開き、日付やロットを手作業で突合し続けなければなりません。

しかし、顧客への初動対応やラインの維持に追われる中で不具合のたびにここまでの調査を行うことは、現場にとって非常に負担です。

その結果、再発を防ぐための根本原因の追究に十分な時間を割けないという切実なジレンマが生まれています。

2. 原因と対策の下書きをAIエージェントに任せると

担当者がするのは、いつもどおり不具合報告アプリにレコードを登録することだけです。

1. 担当者が、不具合報告を登録する

2. エージェントが動き出し、4つのアプリを調べる

3. 判定・推定原因・対策案の下書きをまとめて、提案する

4. 人が中身を確かめて、承認する

5. kintone のレコードに書き込まれる

ここからは、実際の画面で順に見ていきます。

① 登録をきっかけに動き出す

※以下すべての画像はダミーデータです。

工程名、発生日、数量、不具合の内容、ロット番号、品名を入れて保存します。

メモ欄には、現場で見たことを一言書いておきます。

ここまでは、エージェントがいなくても毎日している作業です。

② 過去の報告・4M変更・設備の点検を自分で調べる

エージェントはまず、各アプリにどんな項目があるかを確かめます。

それから、同じ品名の過去の不具合報告、4M変更、工程マスタを検索します。

工程マスタでその工程に使う設備がわかると、続けて、発生日の前60日以内の点検記録を調べ足します。

調べる先と順番は、あらかじめエージェントへの指示に書いておきます。不具合のたびに「この設備の点検記録も見て」と人が教えるわけではありません。

記録に足りないところは、指示に沿って別のアプリで補います。洗浄のシミの件では、こう言って点検記録を見に行きました。

切替時期は変更内容の詳細に明記がないため、設備点検記録の異常内容を確認します。

③ 書き込む内容を提案して承認を待つ

このデモの設定では、調べ終わっても、エージェントはいきなりレコードを書き換えません。

何を調べて何がわかったか、どの欄に何を書き込むかをまとめて、承認待ちになります。

人が中身を見て「承認」を押すと、はじめて書き込まれます。納得できなければ「却下」もできます。

④ 判定・推定原因・対策案がレコードに入る

承認すると、不具合報告に判定、推定原因、対策案が書き込まれます。

コメント欄には、参照した件数が1行で残ります。

このデモでは、エージェントへの指示で書き込む欄を「判定」「推定原因」「対策案」とコメントに絞っています。

判定・推定原因・対策案に下書きを入れました。判定：再発。参照した件数：過去の報告2件、4M変更0件、点検記録1件。

3. 不具合の判定はこう分かれた

同じエージェントに、性質の違う2つの不具合を登録してみました。

※動画と画面に出てくる会社名などは、サイボウズ社が提供する kintone のサンプルアプリのデータと、デモ用に作った架空のデータです。実在の企業・団体とは関係ありません。

曲げR部に割れ。4個とも同じ位置

洗浄・乾燥のあと表面に白いシミ

どちらも、現場で見つけた不具合をそのまま登録しただけです。

それでも、記録をたどると、判定ははっきり分かれました。

4. 不具合の原因に当たりを付ける4つのポイント

結果だけでなく、判定の中身にも見どころがあります。

① 理由の出どころまで書く

曲げの割れの件では、推定原因の欄に、6月の報告に何が書いてあったかが添えられていました。

型の使用ショット数が交換の目安を超えていたとの記録あり。今回の症状（曲げR部・同じ位置の割れ）と酷似している。

気になれば、その報告を開いて確かめられます。

同じ工程の古い報告には、原因も対策も書かれていませんでした。エージェントはそれもそのまま書いています。

（…）も同じ曲げ工程で折れが発生しているが、推定原因・対策案の記入なし。

書かれていないことを、それらしく埋めてはいません。

② 「無い」も調べた結果として書く

曲げの割れの件では、4M変更も設備の点検も、原因の候補にはなりませんでした。

エージェントは、それを省かずに書いています。

4M変更: なし（品名OLEOの4M変更管理レコードは0件）。

洗浄のシミの件でも、最初に「同じ工程での過去例はありません」と書いたうえで、別の方向を調べに行きました。

これらを総合すると、判定は「要確認」（同じ工程での過去例は無いが、4M変更と設備の両方に候補がある）が適切です。

何を調べて、何が無かったかがわかるので、読む人は同じことを調べ直さずに済みます。

③ 別々の記録をつないで時期を割り出す

洗浄のシミの件では、4M変更の記録に「いつ切り替えたか」が書かれていませんでした。

エージェントは、10月1日の点検記録に「濃度計を新設」とあるのを見つけ、切替は10月1日ごろと推定しています。

そのうえで、直前の点検で見つかった濃度計のずれと、今回のシミを結びつけました。

校正はメーカーに依頼中（11/5来訪予定）で、不具合発生日2026-10-29の時点では未校正のまま稼働していたとみられる。

洗浄・乾燥後の白いシミ（メモ記載）は濃度過不足による薬液残留・乾燥不良でも起こり得る。

4M変更と設備の点検は、別のアプリの記録です。 人が並べて読まないと、つながりには気づきにくいところです。

④ 前回の対策を引き継ぎ今回の事情を足す

曲げの割れの件では、対策案の1番目に、6月に効いた対策（型のR部の研磨とR寸法の測り直し）を挙げていました。

2番目は今回のロットの全数検査です。6月にもロットを全数検査して、割れ品を廃却した実績があることを添えています。

3番目には、点検が「正常」だったことをふまえた一手が書かれていました。

次回点検時に曲げ型R部の摩耗を重点的に確認する。

洗浄のシミの件では、メーカーの校正を待つ間の手当てまで書かれていました。

校正完了（11/5予定）を待たず暫定校正または手計測併用に切り替える。

今回不具合ロットL1028の洗浄時の実際の薬液濃度（手計測値）を記録と照合し、濃度過不足と白いシミの相関を確認する。

前例があれば前例に沿い、無ければ確かめる順番を示しています。

5. 品質管理の現場はこう変わる

• 原因の欄が空いたままにならない：このデモでは、登録して1分もしないうちに、判定・推定原因・対策案の下書きが届きます。

• ベテランの記憶だけに頼らずに済む：「6月にも同じ割れが出て、型を研磨した」を、記録から拾ってくれます。

• アプリをまたいだつながりに気づける：4M変更と設備の点検のように、別々の記録に書かれたことを並べて読んでくれます。

• 原因の見極めは品質の担当者に残る：下書きは承認待ちで届くので、推定原因と対策案に納得できるかを見てから、承認するか却下するかを決められます。

6. あなたの不具合報告は当てはまる？

次のうち、当てはまるものはありますか。

• 不具合報告を、kintone に記録している

• 原因の欄の書き方や深さが、書く人によってばらつく

• 「前にも同じ不具合があった」を、記憶に頼って探している

• 4M変更や設備の点検の記録が、別のアプリに残っている

2つ以上当てはまるなら、AIエージェントに任せられる余地があります。

よくある質問

Q. AIエージェントが勝手に原因や対策を書き換えることはありますか？

承認されるまで書き込みません。エージェントは判定・推定原因・対策案の下書きを提案としてまとめ、承認待ちになります。納得できなければ「却下」もできます。承認したあとも、書き込むのは「判定」「推定原因」「対策案」とコメントだけの設定にしています。どのアプリに何を書けるか、承認を挟むかは、エージェントの設定で決めます。

Q. 同じ工程に過去の不具合がなくても使えますか？

動画2の洗浄のシミの件では、同じ工程の過去例がありませんでした。エージェントは「同じ工程での過去例はありません」と書いたうえで、4M変更と設備の点検記録を調べ、濃度計のずれという候補を見つけています。判定は「再発」ではなく「要確認」でした。

Q. 過去の報告に原因が書かれていないとどうなりますか？

書かれていないことは埋めずにそのまま記載しています。動画1の曲げの割れの件では、同じ工程の古い報告に推定原因・対策案の記入がないと書いたうえで、原因と対策が残っていた6月の報告をもとに下書きしていました。

まとめ：不具合の原因探しは過去の報告の読み返しから

このエージェントが使っているのは、どれもすでに kintone にたまっていた記録です。

過去の不具合報告、4M変更、工程マスタ、設備の点検記録。

「書いておしまい」になりがちな記録が、次の不具合の原因を探す手がかりとして生きてきます。

過去の報告に原因と対策が書いてあるほど、エージェントが引き継げる前例は増えていきます。

まずは、過去の不具合報告に原因と対策がどこまで書かれているか、何件か開いて確かめるところから始めてみませんか。

製造のもう一つの記事はこちら

製造見積の見立て見積を登録するだけで、AIエージェントが工数と納期の目安を見立ててくれる

この業務、あなたの会社でも実現できるかもしれません。

同じ業務でも、会社によって進め方や判断のルールは異なります。

ノベルワークスは、kintoneの開発経験を活かし、それぞれの業務に合ったAIエージェントの活用を支援します。

👉 自社の業務について相談する