発注書が届いた瞬間に、設計からNC出力まで走る。フライス盤とAIエージェントを接続した事例

相談時の状況

最初にうかがったのは「受注が増えると、加工より前で詰まる」という話でした。機械の稼働率が上限なのではなく、機械に流すデータを用意する工程が上限になっている、という状態です。

工程を分解すると、受注から加工開始までにこれだけの手作業が挟まっていました。

1. 1発注書がメール添付のPDFやFAXで届く
2. 2担当者が読み取り、品番・材質・寸法・数量・納期を基幹側へ転記する
3. 3図面がない、あるいは寸法だけの指示の場合はCADで形状を起こす
4. 4CAMで加工パスを設定し、切削条件を決める
5. 5NCコードを出力し、フライス盤へ転送する

問題は工程の多さそのものより、2〜5をひととおり回せる人が限られていたことでした。受注が重なるとその人の前に列ができ、逆にその人が休むと工場全体が止まりかねない。作業自体は毎回ほとんど同じなのに、属人的なまま残っていました。

つくったもの

発注書の受信をトリガーに、AIエージェントが次の順で処理を進め、最後に人が承認するとフライス盤へデータが渡る仕組みです。

見た目には「発注書が来たら勝手に加工データができている」ですが、実装として重要なのは②③と⑥です。

② 仕様の構造化 — 文章ではなく項目で受け取る

発注書の様式は取引先ごとに違い、同じ取引先でも担当者によって書き方が揺れます。ここをAIエージェントに任せるにあたって、出力を自由な文章にせず、あらかじめ決めた項目の集合として返させる設計にしました。値が読み取れない項目は推測させず、空のまま「未確定」として返します。

AIが最も危険なのは、分からない値をそれらしく埋めてしまうことです。材質や公差を推測で埋められると、そのまま金属を削ってしまいます。「埋めない」ことを正解として設計しました。

③ 照合 — 過去実績を正解データとして使う

工場には、その工場でしか通用しない暗黙のルールがあります。この材質ならこの工具、この寸法帯ならこの取り代、この取引先の図面はこの解釈。これらを仕様書に書き起こすのは現実的ではないので、過去の受注と実際に流したNCデータを引き当て元にしました。

その結果、抽出した仕様が過去実績のどれにも当てはまらない、あるいは寸法が過去の範囲から外れている場合は、自動的に処理を止めて設計者に回るようになっています。判断できないときに止まることが、この仕組みの品質そのものです。

⑥ 承認 — 人が止める場所を1箇所だけ残す

工程ごとに人が確認する設計にすると、結局これまでと同じだけ時間がかかります。かといって全自動にすると、誰も内容を見ないまま主軸が回ることになる。切削は物理的に取り返しがつかない加工なので、そこは避けました。

そこで、確認を最後の1箇所に集約しました。承認画面には、生成された3Dモデル、加工パス、切削条件、そして「過去のどの実績を引き当てたか」「過去NCコードとの差分」が並びます。担当者は一から図面を起こすのではなく、出てきたものが妥当かを見る側に回ります。

作業の性質が「作る」から「見る」に変わるため、確認の負荷そのものも下がります。ゼロから図面を起こす判断と、出てきたものが過去実績と整合しているかを見る判断では、必要な集中の度合いが違います。

安全側に倒すために決めたこと

• 承認のないNCコードは機械に届かない。 転送はシステムが行いますが、承認フラグのないデータは物理的に転送対象にしていません。
• 新規形状には適用しない。 形状テンプレートに当てられない受注は最初から対象外にし、設計者へ回します。
• ドライランを前提にする。 初回ロットは必ず空運転と初品検査を通す運用のまま変えていません。自動化したのはデータを作るところまでです。
• すべての生成物に履歴を残す。 どの発注書から、どの実績を引き当てて、誰がいつ承認したかを追えるようにしました。不具合が出たときに原因を戻せることを優先しています。
• 社内ネットワーク内で完結させる。 図面・加工条件は工場の競争力そのものなので、扱う範囲と保存先を最初に線引きしました。

結果

繰り返し性の高い部品について、受注から加工開始までの間にあった「人が発注書を読み、図面に起こし、加工パスを作る」という工程がなくなりました。担当者の作業は、出てきたものを承認する操作に変わっています。

副次的な変化として、これまで一人に集中していた工程が画面上で共有されるようになり、その人が不在でも受注処理が止まらなくなりました。設計者は、自動化の対象外にした非定型品や新規形状に時間を使えるようになっています。

同じ構成が向いている工場

• 受注の多くが、過去にも作ったことのある形状の寸法違い・数量違いである
• 発注書からNCデータまでを回せる人が1〜2人に限られている
• 機械の稼働率より、機械に流すデータの準備が先に詰まっている
• 過去のNCデータと受注履歴が、探せば出てくる状態で残っている

逆に、毎回まったく異なる一品ものが中心の工場では、引き当て元になる実績が貯まらないため、この構成の効果は限定的です。その場合は、発注書の読み取りと基幹への転記までを切り出す方が現実的です。詳しくはシステム・ソフトウェア開発をご覧ください。