6つの失敗パターンの全体像
工場でAIエージェントを動かすときの失敗は、次の6つに分けられます。前の3つはエージェントの動作、後の3つは運用の仕組みに関わる失敗です。
動作の失敗：過剰権限・誤った前提・ループ暴走
1. 過剰権限：使わない操作まで許している
OWASPの「Top 10 for LLM Applications 2025」は、LLMアプリの主要リスクとして「Excessive Agency（過剰な権限・自律性）」を挙げています。工場での具体例は、保全記録を調べるためのエージェントに、CMMSの全権限を持つアカウントを使わせた結果、作業オーダーのクローズまでできてしまう状態です。誤った判断やプロンプトインジェクション（文書に仕込まれた指示でAIを操る攻撃）があれば、その権限の範囲で被害が出ます。
防ぎ方は、エージェント専用のアカウントを作り、用途に必要なトランザクションだけを許可することです。MCP仕様（2025-06-18版）も、ツールを任意のコード実行と位置づけ、呼び出し前のユーザー同意を求めています。詳しくはMES・ERPを操作させる権限設計を参照してください。
2. 誤った前提：用語と指示を取り違える
「ライン2」がMES上の「L02」なのか「第2組立ライン」なのか、「不良」が工程内不良なのか客先クレームなのか。工場の用語は部署ごとに意味が違うことが多く、エージェントはもっともらしい解釈で処理を進めます。結果として、別の設備のデータで原因を推定したり、別の定義の不良率を報告したりします。
防ぎ方は、用語とデータの対応をツール側で固定することです。エージェントにSQLを自由に書かせず、「ライン別の工程内不良率を返す」のように意味の決まったツールを用意します。曖昧な指示には、実行前に確認を返す動作を組み込みます。
3. ループ暴走：同じ処理を繰り返す
エージェントは、ツールの結果が期待どおりでないと、手順を組み直して再実行します。データが見つからない、APIがエラーを返す、といった状況で、同じ照会を繰り返したり、起票を重複して作ったりすることがあります。クラウドのLLMであれば、繰り返しの分だけ費用もかかります。
防ぎ方は、1タスクあたりのツール呼び出し回数と実行時間の上限を設け、上限に達したら人に戻すことです。書き込み系のツールは、同じ内容の重複実行を検知して止める仕組み（冪等性の確保）を組み込みます。
運用の失敗：古いデータ・責任不明・評価不在
4. 古いデータ参照：現場の「今」と違う状態で判断する
データレイクやヒストリアンには、集計バッチの都合で数時間〜1日前のデータしか入っていないことがあります。エージェントがそれを現在の状態として扱うと、すでに復旧した設備に保全依頼を出したり、すでに出荷したロットについて回答したりします。
防ぎ方は、ツールの返り値に必ずデータの時点を含め、エージェントの回答にも表示することです。リアルタイム性が必要な判断（設備状態、ロットの所在）は、MESや設備データの現在値を照会するツールを別に用意します。データの鮮度の考え方は生成AIを工場データにつなぐ前提条件で扱っています。
5. 責任不明：誰の判断か記録に残らない
エージェントが人のアカウントで操作すると、監査ログ上は人の操作と区別がつきません。品質問題が起きたとき、誰がどの根拠で判断したのかを説明できなくなります。顧客監査やトレーサビリティの観点では、これは重大な欠陥です。
防ぎ方は、承認者と実行者（エージェント）の両方を記録し、承認時に参照した根拠データも残すことです。承認ゲートの設計はHuman-in-the-loopの設計で詳しく扱います。
6. 評価不在：劣化に誰も気づかない
導入時はうまく動いていたエージェントも、品番の追加、設備の更新、不良コードの改定、LLMのバージョン更新などで、徐々に性能が落ちます。介入率や誤操作件数を測っていなければ、現場が「最近使えない」と感じて使わなくなるまで、誰も気づきません。
防ぎ方は、成功率・介入率・誤操作件数・処理時間を週次で追う仕組みを、導入時に組み込むことです。指標の設計はAIエージェントの運用評価を参照してください。
設計段階のチェックリスト
| パターン | 設計段階で決めること |
|---|---|
| 過剰権限 | エージェント専用アカウント、許可するトランザクションの一覧 |
| 誤った前提 | 業務単位のツール、用語とデータの対応表、曖昧時の確認動作 |
| ループ暴走 | ツール呼び出し回数・実行時間の上限、書き込みの重複防止 |
| 古いデータ参照 | 返り値への時点の付与、現在値照会ツールの分離 |
| 責任不明 | 承認者・実行者・根拠の記録、品質記録と同じ保存期間 |
| 評価不在 | 4つのKPI、週次レビュー、モデル更新時の再評価手順 |
国内の調査でも、OT環境のリスクは現実のものです。MONOistの「OTセキュリティ実態調査2026」（2026年3月実施、341件）では、過去3年にOT環境でセキュリティインシデントを経験した企業が8.4%ありました。AIエージェントがOTに近いシステムを操作するようになれば、6つのパターンへの備えはセキュリティ対策の一部になります。
よくある質問
6つのうち、最初に対策すべきものはどれですか
過剰権限です。他の失敗が起きても、権限が絞られていれば被害の範囲が限られます。エージェント専用アカウントと許可トランザクションの一覧を最初に作ってください。
ハルシネーションは6つに入らないのですか
ハルシネーション（もっともらしい誤り）は、2の誤った前提や4の古いデータ参照と組み合わさって被害を生みます。本記事では、エージェント特有の「誤った判断が操作につながる」経路として整理しています。
既製品のエージェントでも、これらの対策は必要ですか
必要です。製品側に権限管理やログの機能があっても、どのトランザクションを許すか、誰が承認するかは利用企業が決めることです。製品の設定項目として対応できるかを、選定時に確認してください。
この記事に出てくる用語
この記事を書いた人
DELMIA Apriso を中核とした MES / 製造DX の導入・運用・人材育成と、製造業向けAIの調査・開発・教育を手がけるITコンサルティング企業。ISO 9001:2015 / ISO 27001:2022 認証取得。 日本・中国・米国で製造業のMES・データ基盤・AI導入を手がけた実務者が、欧米・中国の一次情報にあたって書いています。
