Three projects
3 件とも、
相手の現場に置いた。
対象も期間も違いますが、共通しているのは 当社ひとりで完結していないことです。3 件とも、部品をつくる会社・鋼板を加工する会社・実際に業務を回している会社と組み、 その会社の現場と、その会社のデータで確かめています。
ベアリングの
外観検査を自動化する
神奈川県 県内産業DXプロジェクト。株式会社高井精器と。搬送・撮像・判定・仕分けまでを 1 本の装置にし、検査結果を Web から見られるようにした。
詳しく見る →
流れる鋼板の
疵を検査する
神奈川県 県内産業DXプロジェクト。伊藤忠丸紅鉄鋼株式会社・東京スチールセンター株式会社と。止めた装置の中に人が入る検査を、遠隔の全長検査へ。
詳しく見る →
社内に貯まった
データに、言葉で聞く
KISTEC 生成AI活用促進事業。リカザイ株式会社と。kintone に貯まった 22 万件を、自然言語のまま集計・抽出できるようにした。
詳しく見る →
2022 ／ 令和4年度 県内産業DXプロジェクト
見えないキズを撮り、
装置に載せ、
結果を残す。
プロジェクト名は AI外観検査におけるデータ活用DXプロジェクト。 代表企業が当社、メンバーが株式会社高井精器。対象は、自動車・家電・産業機械に使われるベアリングです。
金属や光学部品のような光沢面は、光が強く返るためキズが画像に写りません。 だから人の眼に頼るしかなく、①検査員の負担が大きい ②官能検査なので結果がばらつく ③集計に手間がかかりデータが使えない、 という 3 つが同時に起きていました。
このプロジェクトでやったことは 3 つです。独自の照明と画像処理でキズを画像として撮ること、 搬送・反転・仕分けまで備えた装置にすること、そして検査画像と判定結果を残して Web から見られるようにすること。 撮るだけでも、判定するだけでもなく、現場の流れとして成立させるのが狙いでした。
実用レベルの性能が得られた
報告書の結論はこの一行です。あわせてサイクルタイムの短縮が残った課題と明記されています。 できたことだけを書くと次に入る人の役に立たないので、この課題もそのまま載せています。
200 枚
AI モデルの構築に使った学習用画像の枚数。学習時間は 20 分。多品種少量でも運用できることを狙った値です。
0.90 以上
判別性能の指標。0 から 1 の値をとり、1 に近いほど良い。KPI として設定した水準です。
※ 数値は神奈川県への成果報告書（2023-03-20 提出）に記載された KPI と結果です。 対象・撮像条件・装置構成が変われば同じ値にはなりません。 なお報告書には賃金統計にもとづく削減額の試算も載っていますが、仮定の上に立つ数字なのでここには書いていません。
2023 ／ 令和5年度 県内産業DXプロジェクト
止めた装置の中に、
人が入らなくていいように。
プロジェクト名は スチールセンターにおける目視検査の安全かつ効率向上プロジェクト。 代表企業が当社、構成員が伊藤忠丸紅鉄鋼株式会社と東京スチールセンター株式会社です。
鋼板加工ラインの疵検査は、装置を止めて、その内部に検査員が入って目視で行われていました。 危険が伴ううえ、止めているあいだしか見られないので全長は検査できません。 さらに塗油で濡れた面や、地合い模様の強い熱延鋼板では、有害な疵と無害な疵の見分けに熟練が要ります。
当社はそれまで静止した物体を対象に検査システムを提供してきました。 このプロジェクトの中身は、それを流れている鋼板でも成立させられるかの実証です。 送り速度に同期させて複数の照明とカメラを制御し、連続して撮った像から表面の凹凸を取り出す。 そのうえで AI 異常検知が、検査員が有害と判定しているものを同じく有害と判定できるかを確かめました。
長尺レベラーのシャー装置で切断したあと、搬送されていく途中に撮像機器と判定機器を置いた。
装置の中に入らない
検査員が停止した装置の内部に入る必要をなくし、遠隔で見られるようにする。これがこのプロジェクトの一番の目的でした。
一部ではなく、全長
止めているあいだしか見られないので、これまでは鋼板の一部しか検査できていませんでした。 どこで有害な疵が出ているかが分かれば、その部分を外すといった手が打てます。
可能性を示す結果
報告書の結論はこの表現です。「実用化できた」とは書いていません。 今後は量産加工ラインに適した製品化をめざし、目視検査との整合性を継続的に確かめる、としています。
※ この取り組みは 2024-02-14 に当社から公表しています。装置構成・撮像条件は対象ラインに合わせて設計したものです。
2025 ／ KISTEC 生成AI活用促進事業
データはある。
取り出せないだけだった。
KISTEC（神奈川県立産業技術総合研究所）の生成AI活用促進事業で、 リカザイ株式会社の案件に当社 CTO が技術面の専門家として入りました。 外観検査ではなく、社内に貯まった業務データの使い方のプロジェクトです。
課題は 3 つに整理できました。検索の壁（必要なときに取り出せない）、 分析の壁（アプリをまたいで読めない）、属人化の壁（特定の担当者に依存する）。 データが無いのではなく、あるのに経営判断へ結び付かないという形の問題でした。
作ったのは、kintone に貯まった実データを取り出して正規化し、 自然言語の質問をそのまま照会に変えて実行し、結果を要約して返す仕組みです。 「2025 年度に注文数が多かった取引先は」と聞けば、その場で集計が返ります。 あらかじめ用意した文書を検索して答えを作るのではなく、 AI が必要な照会を組み立てて実データに当たる点が、従来のやり方との違いです。
この事例は 2026-04-17 の KISTEC 生成AI活用促進事業報告会で発表されています。
226,374 件
取り込んだ実業務データの件数。2 つの kintone アプリ・約 2.8 年分を 1 つのデータベースに統合しました。
30–60 分
注文データを 1 回確認するのにかかっていた時間。導入後は数秒になりました。この案件での実測です。
社内で完結する
言語モデルはオープンソースのものを社内で動かしています。外部のサービスへデータを送らないので、 持ち出しの心配がなく、社内 LAN の中だけで運用できます。利用者は実行ファイルをダブルクリックするだけで、 Python の環境構築は要りません。
※ 数値は KISTEC への事業報告書（2026-03-20 提出）に記載された、この案件での実測です。 データ件数・アプリ構成・質問の内容が変われば同じにはなりません。 また報告書には残った課題も書いてあります ── 複雑な結合を伴う照会の精度、日本語の表記ゆれ、大きな表を結合したときの速度。まだ解いていません。
What we take from these
3 件を通して、
同じことを 2 つ確かめた。
見えるようにするだけでは、変わらない
3 件とも、撮る／解くところまでは早い段階で成立しました。 時間がかかったのはそのあと ── 搬送に載せる、止めずに撮る、非 IT の人が使える形にする、というところです。 技術の可否ではなく、現場の流れに置けるかどうかが毎回いちばん大きな山でした。
残った課題も、同じだけ書く
サイクルタイムの短縮、量産ラインへの製品化、複雑な照会の精度 ── 3 件とも報告書に課題が明記されています。できたことと同じ分量で、できていないことを書く。 そうしないと、次に同じ現場へ入る人の役に立ちません。
これら 3 件は、いずれも公的支援事業の枠組みで実施し、成果を報告書として提出したものです。 ここに書いた内容と数値は、その報告書と、当社が公開済みのお知らせの範囲に収めています。