ソリューション
AIオーケストレーション
言語モデルがエージェントを管理し、そのエージェントが設備を制御する自律製造管制プラットフォーム
このページが答える質問
- 複数のAIが異なる制御命令を出した場合、どう調整しますか?
- 言語モデルが製造エージェントを管理するとはどういう意味ですか?
- 製造現場にAIエージェントをどのように適用しますか?
- AIが設備を直接制御しても安全ですか?
- 単なる自動化と自律製造は何が違いますか?
単一AIの限界
工程に孤立した単一のAIは、前後工程との因果関係を見られません。品質AIは品質だけを、エネルギーAIは電力だけを最適化しようとするため、それぞれが最善と判断した制御命令が現場でぶつかります。AIが誤って推論したときに設備の誤作動やラインの停止を防ぐ統合的な統制装置もありません。
AIオーケストレーションはこの点を扱います。個別設備の最適化と工場全体から見た最適化が衝突するとき、その調整を担う層です。
二階層の構造
AIオーケストレーションは、性格の異なる二つの階層で構成されます。
上位階層 — 言語モデルがエージェントを管理します。 要求が入ると、どのエージェントとツールを、どの順で、どこまで使うかの計画を立て、実行結果を検証したうえで人の査読に渡します。判断する主体ではなく、判断を組み立てる主体です。
下位階層 — エージェントが設備を扱います。 品質・予知保全・生産・エネルギー・安全の各エージェントが、OPC-UA/AASで標準化された設備データを読み、工程条件を変えたり保全オーダーを出したりE-Stopをかけたりします。実際に現場へ力が届く側です。
上位階層がなければエージェント同士がぶつかり、下位階層がなければ分析で終わります。二つがつながって初めて自律製造になります。
上位階層 — 計画の立案と検証
要求を受けると、Plannerがまず仕事を分けます。
- 質問の分析 — 何を問うているのか、どのツールが必要かを把握します。
- エージェントの選択 — 質問に合うエージェントを選びます。
- 実行順と終了条件の設定 — 作業を分解し、どのエージェントとツールをどの順で使うか、どこで止めるかを決めます。際限なく回り続けるのを防ぐ仕組みです。
- 最終計画の確定 — 段階ごとのエージェントとパラメータ、条件を確定して配備し、オントロジー知識基盤と食い違っていないかを確認します。
計画が立てばエージェントが実行します。RAG検索で根拠を探し、文書とDBを照会・集計し、その結果を検証段階が改めて確認します。 根拠が相反する、あるいは不十分な場合はここで止まります。
最後は人です。利用者が「この判断は誤りだ」と訂正フィードバックを上げると担当者が査読して承認または差し戻し、承認された内容がオントロジー知識基盤に反映されます。次回のオーケストレーションの整合性がその分だけ上がります。
下位階層 — エージェントの協働とスーパーバイザーの調停
設備異常、エネルギーの不均衡、生産の滞りのように、原因が複数の領域にまたがる複合的な状況で効果が大きくなります。
問題が起きるとスーパーバイザーエージェントが全体状況を統合管理し、品質・予知保全・生産・エネルギーの各専門エージェントがリアルタイムデータを分析して原因を特定します。エージェント間で制御命令が相反する場合は、安全と法令順守を最優先のルールとして調停します。その後、仮想シミュレーションで工場全体の運用に及ぼす影響を検討してアクションプランを導出し、実行を支援します。
適用されるエージェントは次のとおりです。
- 品質エージェント — 渦電流とビジョンを融合して欠陥を全数検証します。
- 設備予知保全エージェント — 振動・トルクを分析し、停止に至る前に保全作業オーダーを生成します。
- 生産最適化エージェント — 工程条件を動的に調整します。
- エネルギーエージェント — 電力負荷を分散します。
- 安全ビジョンエージェント — 衝突や火災を検知するとE-Stop信号を出します。
工程変数の自動制御
現場では熟練作業者の経験で工程変数を調整することが多くあります。担当者が替われば基準も変わり、その差が品質のばらつきにつながります。
AIが工程変数を自動制御すれば、このばらつきを抑えられます。どの条件でどの結果になったかがデータとして残るため、設備の設定値と品質データが途切れずにつながります。
承認の体系
高リスクの命令は自動では実行されません。承認待ちキューに積まれ、管理者が確認してから反映されます。すべての制御履歴は変更できない監査ログに残ります。無人の自律化工程を運用する場合でも、最後の判断は人が握る構造です。
実行トレース
Plannerが何を決めたか、どのツールを呼び出したか、根拠は何だったか、検証器がどう判定したかが、一つの実行トレースとして残ります。
設備を制御するシステムである以上、判断の経路を事後に追跡できる必要があります。承認・修正・差し戻しの履歴と、オントロジーの変更履歴も併せて保存されます。
導入要件
配備とサーバー — セキュリティ方針に応じてオンプレミスまたはプライベートクラウドに構築します。LLM・埋め込み・検索モデルを動かすGPUサーバーと、エージェント・APIサーバー、ベクトルDB・トレース保管庫のためのインフラが必要です。内部の業務システムやDB、APIに到達する網構成が必要で、閉域網ではモデル・パッケージの搬入と更新の手順を別途定めておく必要があります。 導入形態は顧客専用クラウド(VPC・Dedicated)またはオンプレミスから選択し、ISO/IEC 27001とGS認証1等級を取得しています。
データの準備 — エージェントが使う社内文書、業務DB、APIデータと検索用ナレッジベースが必要で、文書・レコードごとの識別子とメタデータが維持されている必要があります。本文・表・構造化情報が検索可能な形で抽出されていることも求められます。オントロジーを用いる場合は、中核となる用語・エンティティ・関係・業務ルールの初期定義が必要で、運用しながら人の査読を経て継続的に補完します。
連携 — 業務システム、社内DB、ベクトルDB、文書保管庫、業務APIにREST API・DBコネクタ・検索APIで接続します。外部システムにデータを作成・変更する機能は、読み取り専用の機能と権限を分けて設定する必要があります。 設備側はMES・ERP・QMS・WMS・FEMS・SCADA・PLCと連携し、レガシー・新規設備のOPC-UAデータ、ビジョン画像、振動・トルクセンサー、定型の生産・品質データを受け取ります。
権限と運用 — 一般利用者、運用管理者、ドメイン査読者で役割を分けます。照会と検索は権限の範囲内で自動的に実行しますが、外部システムの変更、重要な意思決定、根拠が相反または不十分な場合、利用者の訂正フィードバックは人の承認対象として運用します。
現在の段階
AIオーケストレーションは社内テストとPoCを進めている発売予定の製品です。自動車部品・製薬・食品・化粧品の製造企業を対象に実証を行っています。
事業の遂行過程で生産量や不良検出精度などの指標を測定していますが、まだ確定前の数値です。確定するまではこのページに掲載しません。導入をご検討の場合はお問い合わせいただければ、現在の進捗をそのままお伝えします。
構成と主な機能
- 言語モデルによる実行計画
- Plannerが質問を分析し、どのエージェントとツールをどの順で使い、どこで止めるかの計画を立てて結果を検証します。判断する主体ではなく、判断を組み立てる主体です。
- AIスーパーバイザーによる調停
- 品質・予知保全・生産・エネルギーの各エージェントが下した判断が衝突したとき、安全と法令順守を最優先のルールとして調整します。
- OPC-UA / AAS セマンティック資産化
- レガシー設備と新規設備の異種データを国際標準にマッピングし、単一の視点から統制します。
- HITLガードレールと監査ログ
- 高リスクの命令は自動実行されません。承認待ちキューに入り、管理者が承認して初めて反映され、すべての履歴が変更不可のログに残ります。
- デジタルツインによる事前検証
- 措置が工場全体に及ぼす影響を仮想環境で先に検討してからアクションプランを出します。ラインを止めて試す必要がありません。
- AutoMLOps 無停止再学習
- データドリフトを監視し、モデルが現場とずれ始めたら運用を止めずに再学習します。