キユーピーが工場シミュレーション開発を78.8%削減した話——数字より「3つの壁の乗り越え方」が参考になる
78.8%削減、という数字が一人歩きしそうな記事だが、本質はそこではない。この事例が興味深いのは、「汎用LLMがそのままでは使えない専門領域に対して、どう環境ごとAI活用可能な形に再設計したか」というアーキテクチャの話だからだ。
なぜこれが「製造業のAI活用」の典型例として面白いのか
製造業でのAI活用といえば、画像検査や需要予測が先に語られることが多い。しかし実際の現場では「シミュレーション」という地味だが重要な業務がある。生産ラインや設備の設計・改善を稼働前に検証するための工場シミュレーションだ。
キユーピーはシーメンス製の「Tecnomatix Plant Simulation」（以下Plant Simulation）を使う専門チームを持っている。このソフトは業界では広く使われているが、AIと組み合わせようとすると即座に3つの壁にぶつかる。この3つの壁の性質を理解すると、「なぜ普通のChatGPT活用とは話が違うのか」がわかる。
3つの壁：ニッチさ・ローカル制約・属人化
壁1：SimTalkという独自言語
Plant SimulationのプログラミングにはSimTalkという専用言語を使う。Pythonでも JavaScriptでもない、このソフトのためだけに存在する言語だ。学習データが世の中に少ない分、汎用LLMはSimTalkのコードを「正しく生成するのが難しい」。ここが第一の障壁になった。
壁2：ローカルGUIでしか動かない
Plant SimulationはGUI操作を前提としたローカル環境上でのみ動作する。つまり、AIが生成したコードをクラウド上で自動的に実行して検証する、というサイクルが組めない。AIが書いたコードが正しいかどうかを確かめるためには、人間が手動でローカル環境を動かす必要があった。これではAIを使っても「レビューの手間」が残り続ける。
壁3：専門チームの中に知見が閉じている
工場シミュレーションはそもそも専門チームが担う業務だ。そこにAIを導入しても、ノウハウが特定のエンジニアの使い方に依存してしまうと、チーム全体への展開も、将来の「現場担当者が自分でシミュレーションを作れる」状態への道筋も描けない。
どう解決したか：クラウドとローカルの分割設計
キユーピーとDeNA AI Linkが取った手は、AI活用の「実行環境」を明示的に2層に分けることだった。
まずクラウドのDevinを起点にする。ここでAIが参照するルール集・SimTalkの専門用語辞書・作業手順（Playbook）などのドキュメントを継続的に整備する。誰が使っても同じ知識ベースを参照し、Devinがつまずいたポイントをそのままチームの学習資産として蓄積していく設計だ。ここでの発想は「AIを使い捨てにしない」こと。使うたびに基盤が育つ仕組みにする。
次に、コードの実行と検証にはローカルで動く「Devin CLI」に切り出す。エンジニアの関与は引き続き必要だが、Devin CLIがローカル環境でプログラムを実行し、エラーの検出から修正まで自走する仕組みを作った。Playbookと自動エラー検出の組み合わせで、繰り返し使える開発基盤として体系化している。
この「クラウドで知識を蓄積し、ローカルで実行する」という分割構成が、「ローカルGUIでしか動かせない」という壁への現実的な回答だった。完全自動化ではなく、人間とAIの役割分担を明確にした設計だ。
結果：8.5人日→1.8人日、78.8%削減
最初は多数の不具合修正が必要だったが、基盤の整備が進むにつれ精度が上がり、最新の取り組みでは1回の作り直しで完了するようになった。従来は手作業で8.5人日かかると想定されていた1シミュレーションモデルの開発を、1.8人日で完了。78.8%の削減を達成した。
ただしここは記事の留保をそのまま引き継ぐ必要がある。現時点では小規模な1シミュレーションモデルでの実績だ。複雑なラインや複数モデルの連携が必要な本番規模での再現性は、まだ検証中という段階だろう。数字だけ先走って「うちもすぐできる」と受け取るのは早い。
ここからは見方だが——「コードより先にドメイン知識」の意味
DeNA AI Linkはこのプロジェクトについて、「AIの価値を最大化する鍵がコードを書く技術以上に対象業務を深く理解するドメイン知識にあり、その知見を持つ担当者ほど成果に直結できる」と述べている。
この一文が、ソフトウェアエンジニアリング全体の今のフェーズをよく表していると思う。
コード生成の精度がある水準を超えたとき、「誰がより良いプロンプトを書けるか」ではなく、「誰が業務の正しい要件をAIに伝えられるか」が差になる。SimTalkの例で言えば、SimTalkの文法をAIが知らないなら、それを教え込む辞書を作れる人間が必要だ。ローカルで何が起きているかを観察してPlaybookに落とし込めるのは、その業務を知っている人間だけだ。
つまりAIを入れることで、エンジニアの仕事の重心が「実装」から「業務設計とAI基盤の整備」に移動する。これは「エンジニアが不要になる」話ではなく、「エンジニアが何を知っていれば価値を出せるか」が変わる話だ。
製造業の現場に詳しいエンジニアや、シミュレーション業務を長年担ってきたメンバーが、今後AIプロジェクトで中心的な役割を担う——このキユーピーの事例はその構図を具体的に示している。
実務的な示唆：「PoCで終わる」と「展開できる」の分かれ目
AI活用のPoCは各社で無数に走っているが、そのかなりの数が本番展開に至らない。この事例を踏まえて、分かれ目はどこにあるかを整理してみると：
「PoCで終わりやすい」パターン： 検証環境での精度は出たが、実行環境の制約（今回で言うローカルGUIの問題）を後回しにしている。あるいは、AIが使う知識ベースの整備を誰かの属人的な作業に依存したまま、組織展開の道筋が見えない。
「展開につながりやすい」パターン： 実行環境の制約を最初から設計に組み込んでいる。ノウハウをAIが参照できる形でドキュメント化する仕組みがある。そして、専門家だけでなく将来的には現場担当者が使える状態を、ゴールとして明示している。
今回のキユーピーの事例は、3つ目の「民主化」という言葉に目標が見えている点で、PoCを超えた展開を意識した設計になっている。
今後の論点：民主化の先にある「品質責任の分散」
キユーピーとDeNA AI Linkが掲げる次のゴールは「工場シミュレーションの民主化」——各工場の担当者が自然言語でシミュレーションモデルを構築できる状態だ。
これは目標として正しいし、実現すれば現場の自律性は確実に上がる。ただし、次に問題になるのは「誰が作ったシミュレーションモデルの品質を誰が保証するか」だ。
専門チームが作ったモデルなら、専門チームが責任を持てる。しかし現場担当者が自然言語で作り始めると、「動いているように見えるが、実は前提条件が間違っているモデル」が生産設備の意思決定に使われるリスクが出てくる。シミュレーション結果に基づいて設備投資や生産計画を変えた場合、その結果責任はどこに帰属するのか。
民主化は正しい方向だが、品質保証のレイヤーをどう設計するか——これが次のフェーズで本丸になる論点だと思う。「誰でも作れる」と「誰が作っても信頼できる」は別の問題だ。
まとめ
78.8%削減という数字は派手だが、この事例の骨格は「汎用ツールが通用しない環境で、ドメイン知識を基盤にAIを動かせる状態を作った」という地道なアーキテクチャ設計の話だ。SimTalkの辞書を整備した人、Playbookを書いた人、エラー検出の仕組みを作った人——そういった「AIに業務を教えた人たち」がいてはじめて成立している。
製造業でのAI活用を検討している現場が、この事例から持ち帰るべき問いは一つだ。「自社の専門業務をAIに教えられる状態に、今なっているか」。ツール選定より先に問うべきことが、そこにある。
