AIエージェントは、現場の質問に答えるだけでなく、図面・手順書・履歴を探し、システムをまたいで作業案を組み立てます。本稿は工場長、製造部長、生産技術、DX責任者、情シスが、用途、構成、統制、投資判断を同じ地図で議論するための総覧です。
製造現場には、紙の手順書、設備ログ、品質記録、メール、ERP、MES、WMSなど、正しい情報が分散しています。AIエージェントは、依頼を分解し、許可された情報を検索し、ツールを呼び出し、次の作業案まで返すソフトウェアです。製造業で重要なのは、モデル単体の賢さではなく、どの情報へ、誰の権限で、何を実行できるかです。
意思決定者は、対象業務の詰まり、責任境界、既存システムとの接続、止まった場合の代替手順を先に定義する必要があります。用途の広がりは製造業のAIエージェント活用例、現場起点の候補は製造現場のユースケースで詳しく確認できます。
Microsoft Agent Frameworkは、ツールとMCPサーバーの利用、ツール承認、長い多段タスク、human-in-the-loopのワークフローを提供しています。同時に、第三者システム利用時のデータ流出確認は利用者の責任としています。
製造業では、AIエージェントをPLCや安全回路の代替ではなく、WMS・ERP・IoT・文書群の上に置く「判断と実行の接続層」として始めるのが現実的だと考えます。これは導入実績ではなく、各社で検証すべき設計仮説です。
外観検査では用途に応じてVLMと従来モデルを選ぶ必要があります。判断軸はVLMとCNNのモデル選定で整理しています。
検査装置の結果、画像、品番、基準書をまとめ、保留品について根拠付きの確認画面を作る用途です。AIが合否を確定するのではなく、一次分類と人への受け渡しを担わせます。
指示書とラベル画像、投入予定と原料ロットを照合し、差異を警告します。OCRの読み誤り、包材変更、類似品番を評価データへ含めます。
納品書、現物ラベル、発注情報を照合し、WMS登録案を生成します。登録前の人の承認、重複登録防止、通信断時の保留キューが必要です。物流全体の候補は物流・倉庫のAIエージェント活用例で確認できます。
現象、品番、設備、発生日から類似事例を探し、確認順序を提示します。作業指示では最新版の版管理、資格、設備状態を照合し、現物との不一致を止められる設計にします。詳細は作業指示と現況の不一致、技能継承は暗黙知のAI継承も参考になります。
上記の工程では、AIが「検索・照合・候補作成」、人が「例外判断・承認・責任」を担う構成から検証します。評価条件は、通常ケースだけでなく、読み取り不能、版違い、同名品、通信断、権限不足、二重実行を含めます。これは実績の表明ではなく、検証すべき仮説です。
既存システム連携の実務はAIエージェントと社内システム連携で掘り下げています。APIがない画面を操作させる場合も、専用の実行環境、許可リスト、画面変更の検知、操作前確認が要ります。
Google Cloud API Gatewayは、既存REST APIをMCPツールとして公開する機能をPublic Previewで提供しています。tools/callには元のREST操作の認証が常に適用される一方、tools/listは既定で未認証のため、本番ではJWTが必要と説明されています。1ゲートウェイの上限は1,000ツールです。
OpenAIのcomputer useは、自社が用意した環境でモデルからの操作要求を実行する方式です。GPT-6 Astraではコード実行方式が推奨されています。
「AIを使うか」ではなく、「どの操作を、どの条件で許すか」を表にします。閲覧・検索は自動、入力案は人が確認、在庫更新や作業指示発行は二者承認、設備制御は既存の安全制御から分離、といった段階が考えられます。
承認画面には、変更前後、参照根拠、対象、影響範囲、実行者権限を表示します。承認拒否やタイムアウトも正常系として設計し、全操作を追跡可能にします。
Cloudは更新性や拡張性を得やすい一方、通信、データ移転、外部障害の影響を評価します。Edgeはカメラや設備の近くで低遅延処理を担い、中央管理と組み合わせます。Localは閉域・データ所在に対応しやすい一方、計算資源、モデル配布、監視、保守を自社側で負担します。
判断軸は、①データ持ち出し可否、②許容遅延、③通信断時の継続要件、④モデルとハードの規模、⑤更新・監視を担う体制です。閉域運用の論点は工場閉域網でのAIエージェント運用で詳しく扱っています。
AWS公式ブログは、Outposts上にFM（LLM／SLM）とベクトルストアを置く完全ローカルRAGと、Bedrock Agentsがリージョンとエッジへ処理を振り分けるハイブリッド構成を分けて示しています。
Google Antigravity SDKは、ローカルモデルによる完全オフライン実行に対応しました。初期対応はGemma 4 26B A4B／LiteRTで、24GBを超えるVRAMまたは統合メモリが推奨されています。Ollama、LM Studio、vLLMなどOpenAI互換サーバーも利用できます。
検査画像や原料情報をLocal／Edgeで処理し、匿名化されたイベントや承認済み結果だけをCloudへ渡す分割が候補になります。ただしタクト、精度、障害復旧、更新作業を実機で検証し、配置を固定観念で決めないことが重要です。
モデルの正答率だけでなく、タスク完了率、根拠の正しさ、ツール選択、重複実行、承認負荷、現場受容性を別々に見ます。評価セットは本番データから分離し、変更のたびに回帰テストします。
費用はモデル利用料だけではありません。企画、データ棚卸し、接続開発、端末・GPU、認証、セキュリティ審査、教育、監視、ログ保管、評価、モデル更新、障害対応、例外処理を含めます。Cloudは従量費、Localは設備・保守、ハイブリッドは両者の統合運用が論点です。
効果は「導入後－導入前」の差で測ります。検索、転記、確認待ち、差し戻し、教育、停止、品質調査に使う時間と頻度を記録し、金額換算できる効果と、追跡性・標準化・属人性低減のような定性的効果を分けます。ROI年数や削減率を先に置かず、利用量・例外率・保守工数を変えた複数シナリオで感度分析することが妥当です。
2026年時点では、ローカルモデルのオフライン実行、REST APIのMCPツール化、承認付きワークフローが具体的な開発機能として提供されています（出典3件：Google Antigravity SDK・Google Cloud API Gateway・Microsoft Agent Framework、下記一次情報を参照）。これにより、閉域、既存資産接続、人の承認を含む構成を比較しやすくなっています。
NVIDIAのMulti-Agent Intelligent Warehouse Blueprintは、WMS／ERP／IoTの上に置くオープンソースのAIコマンドレイヤーとして、役割ベースのアクセス制御とガードレールを含む参照実装を提示しています。
入荷検品、WMS登録、過去不良検索、作業指示を役割別エージェントへ分ける構成は、責任と権限を限定しやすい可能性があります。一方で、引き継ぎ失敗、循環呼び出し、遅延、ログ分散が増えるため、単一エージェントより良いかを業務完了率と運用負荷で検証すべきです。
技術名を採用理由にせず、データ所在、タクト、障害時継続、監査可能性、変更容易性に戻して評価することが重要です。
最初の候補は、頻度があり、現行負荷を測れ、参照データが特定でき、失敗時に人へ戻せる業務から選びます。対象業務の担当者、製造・品質・情シス・セキュリティを集め、現行フロー、利用データ、操作権限、承認者、停止条件を1枚にします。
次に、読み取り専用の検索・照合から小さく検証し、評価に合格した操作だけ入力案、承認付き実行へ広げます。製品やデモから始めず、現場の未完了タスクと責任境界から設計する進め方を推奨します。
生成AIチャットが主に質問への回答を返すのに対し、AIエージェントは許可されたデータやツールを使い、検索・照合・入力案の作成など複数の手順を進めます。ただし、設備停止、品質判定の確定、在庫更新など影響の大きい操作は、人の承認や既存制御の安全機構を残す設計が基本です。
構成次第で検討できます。モデル、検索用データ、実行基盤を工場内やエッジに置くLocal構成、機密処理だけをLocalに残すハイブリッド構成があります。ただし、必要な計算資源、モデル更新、保守、停電・障害時の運用まで含めて比較する必要があります。
回答精度だけでなく、業務完了率、誤操作と見逃し、根拠提示、応答時間、停止時の復旧、権限逸脱、現場の手戻り、担当者が使い続けられるかを評価します。開始前に現行値、合格条件、中止条件、評価用シナリオを合意し、本番に近い例外ケースも含めて確認します。
補助や提案には活用余地がありますが、直ちに全面委任すべきとは限りません。法令、安全、品質、設備、出荷に影響する操作は承認対象とし、AIは根拠と候補を提示、人が確定する境界から始めるのが現実的です。自動化範囲はリスク評価と検証結果に応じて段階的に見直します。
ライセンスや計算資源だけでなく、接続開発、データ整備、セキュリティ、教育、監視、モデル更新、例外対応を総保有費用として捉えます。効果は作業時間だけでなく、待ち時間、再入力、探索、手戻り、停止リスク、教育負荷などを現行値と比較し、金額換算できる項目と定性的な便益を分けて判断します。