著者：副業の宮殿｜製造業に携わる現役エンジニア。技術士試験対策書籍をKindleで複数出版。技術ブログ「副業の宮殿」にて製造業DX・AI活用の情報を発信中。
https://youtu.be/HrhO-cuu2hg 2026年、Googleは「Googlebook」という新しいカテゴリのデバイスを発表した。単なるノートPCの刷新ではない。AIをOSレベルで統合した、Gemini前提の新しいコンピューティング体験だ。同じタイミングで、Claude Code・MCP（Model Context Protocol）・MulmoClaude的な世界観も急速に広がっている。これらは「AIがツールを選ぶ時代」を指向している点で本質的に似ている。だが、製造業DXという文脈で見ると、両者の違いがクリティカルに見えてくる。 本記事は技術比較記事でもなく、ニュースまとめでもない。「工場の現場」という具体的な土俵の上で、GooglebookとMulmoClaude的思想を並べ、「これからの工場DXは本当にどう変わるのか」を深く考察する記事だ。製造業エンジニアとして、AI×現場の現実を一緒に考えてほしい。

Googlebookとは何か——「AIを使うPC」ではなく「AI前提OS」

まず「Googlebook」の本質を整理しておく。ChromeOSとAndroidを統合し、Gemini Intelligence（Google Geminiを基盤としたAI機能群）をOSレベルで組み込んだデバイスだ。重要なのは、GeminiがアプリとしてインストールされたAIアシスタントではないということだ。OSそのものがAIで動いている——この違いは根本的に大きい。 従来のPCにAIを追加する場合、構造はこうなる。
  • ユーザーがアプリを起動する
  • アプリのUIを操作する
  • 別タブでChatGPTやGeminiを使って補助する
  • 結果を手動でコピー&ペーストする
人間が「橋渡し役」になっている。アプリとAIの間を人間が行き来し、情報を運ぶ。これはまだ「AIをツールとして使っている」段階だ。 Googlebookが目指す構造は全く違う。
  • ユーザーが「旅行計画して」と言う
  • GeminiがGmail・Google Maps・Flights・Calendarを横断して情報を取得する
  • 最適なプランを組み立て、カレンダーに自動入力し、予約の手続きまで進める
人間は「意図」を伝えるだけだ。アプリを開く必要もなく、UIを操作する必要もない。AIが必要なツールを判断し、適切な順序で実行する。これが「意図中心UI（Intent-Centric UI）」の世界だ。アプリ中心のUIから意図中心のUIへ——この転換がGooglebookの本質だ。

Generated UI——アプリのUIが動的に生成される

Googlebookにはもう一つ重要な概念がある。「Generated UI」だ。従来のアプリはUIが固定されている。Excelを開けば表計算UIが現れる。Gmailを開けばメールUIが現れる。ユーザーはそのUIに合わせて操作する。 Generated UIは逆だ。ユーザーの意図や状況に合わせて、AIがその瞬間に最適なUIを生成する。「今日の受注データを見たい」と言えば、受注データを可視化するためのUIが動的に生成される。固定されたメニューを探す必要がない。「どのボタンを押せばいいか」を考える必要がない。 これは工場の文脈で考えると非常に重要な話になる。後述する。

MulmoClaudeとは何か——現場専用AIエージェント基盤の世界観

MulmoClaude的な世界観を整理しよう。Mulmoはマルチモーダルコンテンツ生成フレームワークで、Claudeと組み合わせることで「テキスト・画像・音声・データを横断したAIエージェント」を構築できる。より広義には、Claude Code・MCP・Claude Agent SDKを組み合わせた「AIエージェント基盤の思想」全体を指すと考えてほしい。 MulmoClaude的思想の核心は「AIが人間の代わりにツールを選ぶ」という考えだ。 MCP（Model Context Protocol）はその技術的な実現形だ。MCPはAIが外部ツール・API・データベース・ファイルシステムを「ツール」として呼び出すための標準プロトコルだ。Claude Codeが「ターミナルコマンドを実行する」「ファイルを読む」「Webを検索する」といった操作を自律的に行えるのは、MCPがあるからだ。 重要なのは、MCP的なアーキテクチャでは「アプリ」という概念が薄れることだ。
  • 従来：人間 → アプリUI → サービスAPI
  • MCP：人間 → Claude → MCP経由でサービスAPI（直接）
GUIブリッジとしてのアプリは不要になる。AIが「受注DBを確認して」と言われたら、直接データベースに接続してSQLを実行し、結果をわかりやすく提示する。人間は「受注システムのどのメニューを開けばいいか」を知らなくていい。

Claude Codeが示すLoopyなエージェント性

Claude Codeのもう一つの重要な特性は「ループ（Loopy）」だ。コードを書く→実行する→テストが落ちる→修正する→再度テスト——このループをAI側で閉じる。人間が一々「次は何をしてください」と指示しなくても、AIが自律的にループを回して完成度を上げる。 これはGooglebookの「アプリを横断して実行する」とは異なる次元の能力だ。Googlebookは主に「一度の指示に対して複数のツールを並列実行する」のに対し、Claude Code的なエージェントは「試行錯誤のループを自律的に回す」。この違いは工場DXで決定的な意味を持つ。

GooglebookとMulmoClaudeの比較——何が同じで何が違うか

両者の共通点と相違点を整理する。

共通点：「人間が意図を伝え、AIがツールを選ぶ」という思想

GooglebookもMulmoClaude的な世界観も、根本の思想は同じだ。人間がアプリのUIを操作する時代から、人間がAIに意図を伝え、AIが最適なツールを選んで実行する時代へ。この転換を目指している点で、両者は同じベクトルを向いている。

比較表

比較項目 Googlebook（Gemini Intelligence） MulmoClaude（Claude Code + MCP）
統合レベル OSレベル統合（デバイス前提） ソフトウェアレベル（OS非依存）
自由度 Googleエコシステム内に最適化 ツール・API・環境を自由に定義可能
カスタマイズ性 低〜中（Googleが設計した枠内） 高（MCPサーバーを自分で実装）
現場適応力 汎用ユーザー向け 特定業務・現場に深く特化可能
工場DX適性 間接業務（文書作成・メール・分析） 直接業務（設備制御・品質管理・工程最適化）
Googleサービス統合 最強（Gmail・Drive・Maps等ネイティブ） MCPプラグインで可能（サードパーティ）
ロボット連携 現状弱い（汎用PC向け） ROS・制御APIとMCP連携で強い
ループ的自律性 一回の指示に対して実行 試行錯誤ループを自律的に回す
ローカル動作 クラウド依存度が高い ローカルLLM対応可能
セキュリティ・閉域網 インターネット接続前提 工場の閉域網でも動作可能
端的に言えば、Googlebookは「AIネイティブPC」であり、MulmoClaudeは「現場専用AIエージェント基盤」だ。どちらが優れているかという話ではない。適した用途が異なる。そしてこの違いは、工場DXという文脈で非常に重要になる。

工場DXの本質は何か——「システム導入」ではなく「知識構造の転換」

ここからが本記事の核心だ。 従来の工場DXとは何だったか。MES（製造実行システム）、ERP（基幹系システム）、SCADA（監視制御システム）、専用の品質管理システム——これらを導入することが「DX」と呼ばれてきた。巨額の投資が必要で、大手SIerが設計・実装し、現場に展開する。 しかし正直に言おう。多くの日本の工場では、このDXは「デジタル化はしたが、賢くはなっていない」状態になっている。データは記録されているが、使われていない。システムは動いているが、現場の判断はベテランの勘に依存している。ERPを入れても、隣の席でExcelを使い続けている。 なぜか。システムは「情報を入れる箱」を作ったが、「現場の知識・コンテキスト・判断の根拠」をデジタル化できなかったからだ。

AI時代のDXは「コンテキスト統合」だ

AIエージェント時代のDXの本質は、従来とは根本的に違う。 キーワードは「コンテキスト統合」だ。工場の現場には膨大な知識が散在している。
  • 設備の操作マニュアル（PDFで眠っている）
  • 過去の不良対策記録（手書きの作業日誌）
  • ベテランの段取り替えノウハウ（口伝）
  • 品質管理の閾値の根拠（「なんとなく昔からこの数値」）
  • 機械の異音がするときのパターン（担当者の体感）
これらは「構造化されていない」が「非常に価値のある知識」だ。従来のDXシステムはこれを扱えなかった。データベースに入れられる情報だけをデジタル化し、残りは属人化したまま放置した。 AIエージェントはこれを扱える。PDFを読み込める。手書き文書をOCRで取り込める。音声で知識を語ってもらい、構造化できる。そしてMCP的なツール連携で、センサーデータ・CADデータ・受注データ・作業記録を横断的に参照しながら、コンテキストを統合して判断できる。 つまり、AI時代の工場DXの本質はこれだ。
「高性能AIを導入すること」ではなく、「現場知識をAIが扱える構造に変えること」
この視点で見ると、GooglebookとMulmoClaudeの工場DXへの適性の違いが見えてくる。Googlebookは汎用の「AIネイティブPC」として工場の間接部門（設計・調達・営業・経営）に大きな効果を発揮する。一方、MulmoClaude的なアーキテクチャは工場の直接部門（製造・品質・保全）に深く特化できる。

日本の製造業でAIエージェントが特に強い理由

日本の製造業は、実はAIエージェントと相性が非常に良い。逆説的に聞こえるかもしれないが、説明しよう。

属人化の多さが逆に強みになる

日本の工場は世界的に見ても「属人化」が多い。ベテラン職人の勘・経験・暗黙知に依存する工程が多い。これは従来のDXにとってはネックだった。属人知識はシステムに入れられないからだ。 しかしAIエージェントにとっては違う。むしろ「デジタル化されていない知識」が多いということは、「AIで価値化できる宝の山が眠っている」ことを意味する。 具体例を挙げよう。ある中小鍛造工場のベテラン職人は、型から取り出したワークを一目見て「この面の圧力が足りなかった」と判断できる。その根拠は説明できないが、正確に当たる。これをAIエージェントで扱えるようにするには何が必要か。
  1. 職人に「どこを見て判断するか」を繰り返し聞き取り、テキスト化する
  2. ワークの画像データと判断結果をペアで記録する
  3. AIエージェントがこの知識を参照しながら画像を評価できるMCPツールを作る
これは大規模システム開発ではない。LLM+MCP+小さなデータセットで実現できる。中小製造業でも取り組める規模感だ。

紙・Excelが多いほど効果が大きい

日本の中小工場では、工程管理が紙やExcelで行われているケースが今も多い。「それはDXが遅れている」と批判されることが多いが、AIエージェント視点では逆の評価もできる。 デジタル化されたデータは「使えるが、硬直している」。特定のシステムに閉じており、横断利用が難しい。一方、紙やExcelは「雑然としているが、AIが読める」。Claude Codeに「この作業日誌を読んで、過去1年間の不良要因を分類して」と指示すれば、AIはPDFや画像からテキストを抽出し、分類し、レポートを作れる。 「DXしていないから、AIエージェントが最初に入りやすい」という逆説が成立する。巨大なレガシーシステムへの移行コストを考えなくていいからだ。

ロボットとの融合——未来の工場OSとしての可能性

話をさらに未来に進めよう。AIエージェントとロボットが融合したとき、何が起きるか。

SCOUT的移動ロボットとMCPの相性

工場内を自律移動する移動ロボット（例：AgileX SCOUTシリーズ）を想定しよう。現在、こうしたロボットの制御はROS（Robot Operating System）を介したservice call・action・topicで行われる。これはMCP的なTool Useと本質的に同じ構造だ。 「工場内の設備異常を巡回して確認して」とAIエージェントに指示したら：
  1. MCPツール経由でロボットのナビゲーションAPIを呼び出し、巡回経路を設定
  2. ロボットが工場内を自律移動しながら、カメラで各設備を撮影
  3. 撮影画像をAIエージェントが解析し、異常の有無を判断
  4. 異常が見つかれば、保全担当者にアラートを送り、設備DBに記録
  5. 巡回レポートを自動生成して管理者に送付
この一連のフローを「AIが自律的に実行する」。人間は「巡回して確認して」と指示するだけだ。これが「未来の工場OS」の姿だ。

VPR（Visual Place Recognition）と異常検知の統合

さらに進んだ話をしよう。VPR（画像から場所を認識する技術）を活用すると、ロボットは「いつもと違う景色」を検知できる。工場内で「この設備の前に来たら、今日は何かが置いてある。普段と違う」という判断ができる。 AIエージェントがこの情報を受け取り、「これは異常な状態か？それとも許容範囲内か？」を判断するには、現場の文脈知識が必要だ。「設備Aの前に赤いカートが置いてあるのは段取り替え中だから正常。青いカートは意図しない放置かもしれない」——こういう判断をAIエージェントが下せるようにするためには、MulmoClaude的な「現場知識の構造化」が必須だ。 Googlebookはこの用途には適していない。閉じた工場ネットワーク内でローカル動作し、工場固有の知識ベースを持ち、ROSロボットとリアルタイムで通信するアーキテクチャは、MCPベースのエージェント基盤でなければ実現できない。

GUI Chat Protocol——人とロボットの新しいインターフェース

「GUI Chat Protocol」という概念も重要だ。将来の工場UIは、「ダッシュボードを見ながらボタンを押す」ではなく「AIに話しかけながら設備を操作する」になるかもしれない。 「ライン3番機の速度を少し落として、今夜は21時まで延長稼働して」——この一言でAIエージェントが複数のシステムを横断して実行する。これはGooglebookの「旅行計画して」と本質的に同じUI思想だ。ただし対象は「工場の設備と工程」だ。

将来予測——2030年の工場DXはどうなっているか

具体的な将来予測をしよう。

予測1：アプリを「開く」概念がなくなる

ERPを開く、MESを開く、品質管理システムを開く——こうした「アプリ起動→メニュー操作→データ入力」という手順は消えていく。AIエージェントに話しかければ、バックエンドで必要なシステムが呼び出され、結果が返ってくる。Googlebookが個人PC世界で実現しようとしていることが、工場システムでも起きる。

予測2：設備がMCPツール化される

工場の設備（NC工作機械・プレス機・ロボット）が、MCPサーバーを持つことが当たり前になる。「設備Aに今日の加工プログラムをロードして」とAIエージェントに言えば、MCPツール経由で設備のAPIを呼び出し、プログラムが転送される。設備がAIエージェントのツールになる世界だ。

予測3：MCP標準化が工場の共通言語になる

工場における「通信プロトコル」はOPC-UAが標準化されてきた。同様に、AIエージェントが設備や工場システムと連携するための標準プロトコルとして、MCP（またはその工場版）が普及する可能性がある。設備メーカーが「MCPサーバー対応」をスペックとして謳う時代が来るかもしれない。

予測4：ローカルAIエージェントが工場のインフラになる

工場はセキュリティ上、クラウドに繋げられない設備・データが多い。ローカルLLM（Ollama等）+MCPでオフライン動作するAIエージェント基盤が工場内に置かれる。Googlebook的なクラウド依存AIではなく、工場専用ローカルAIエージェントが普及する。

予測5：「AIが書いた設備プログラム」が普通になる

NCプログラム・PLCラダー・ロボット動作プログラムをAIエージェントが生成する。エンジニアはプログラムを「書く」のではなく、「AIが生成したプログラムを評価・承認する」役割になる。Karpathyが「最近ほとんどコードを書いていない」と言った変化が、工場の制御エンジニアにも起きる。

図解：未来の工場DXアーキテクチャ

以下に、AIエージェント時代の工場DXアーキテクチャの概念図を文章で示す。 
【従来の工場DX】

現場作業者
    ↓（操作）
各種アプリUI（MES/ERP/SCADA/Excel）
    ↓（個別API）
各種データベース・設備


【AI エージェント時代の工場DX】

現場作業者
    ↓（自然言語指示）
AIエージェント基盤（Claude + MCP）
    ↓（MCPツール呼び出し）
┌─────────────────────────────────────┐
│  設備API  │  DB  │  画像解析  │  ロボット  │
│  MES API  │ ERP  │  センサー  │  ROS       │
│  文書OCR  │ Mail │  音声記録  │  外部サービス│
└─────────────────────────────────────┘
    ↑
現場知識DB（ベテラン知識・マニュアル・過去記録）
このアーキテクチャの核心は、「AIエージェントが全てのシステムを横断してコンテキストを統合できること」だ。どのシステムも「MCPツール」として統一的に扱われる。人間はAIと自然言語で対話するだけでよい。

GooglebookとMulmoClaudeは「敵」ではなく「レイヤーが違う」

ここまで読んで、GooglebookとMulmoClaudeを比較し続けてきたが、最終的に伝えたいのはこうだ。両者は競合ではなく、レイヤーが違う。 Googlebookは「AIネイティブPC」として、工場の管理職・設計者・調達担当者が使う「知的労働のプラットフォーム」として強力だ。会議の議事録を自動作成し、調達先候補をWeb検索してまとめ、設計変更の影響を過去資料から分析する——こういう間接業務でのAI活用に圧倒的な力を発揮する。 一方MulmoClaude（Claude Code + MCP）は、工場の製造現場に直接食い込む「現場専用AIエージェント基盤」だ。設備制御、品質判断、ロボット操作、閉域ネットワーク内での動作——これらはGooglebookが苦手とする領域だ。 将来の工場では、この二つが補完的に使われる姿が想像できる。管理部門はGemini Intelligence（Googlebook）で知的作業を効率化し、製造現場はMCP基盤のローカルAIエージェントで直接業務を自動化する。そして二つの世界は、工場のデジタルツインを介して統合される。

まとめ——未来の工場DXは「システム導入」ではなく「知識戦争」だ

最後にメッセージを整理する。 GooglebookもMulmoClaudeも、「AIがツールを選ぶ時代」の到来を示している。人間がアプリのUIを操作する時代は終わりつつある。人間は「意図」を持ち、AIに伝え、AIが最適な手段で実行する。 工場DXの文脈では、この変化はより深い意味を持つ。従来のDXは「高価なシステムを買って入れる」戦いだった。これからのDXは違う。
「未来の工場DXは、高価なシステム導入ではなく、現場知識をAIが扱えるようにする戦いになる」
ベテラン職人の暗黙知を、AIエージェントが参照できる知識ベースに変換すること。紙と口頭伝承で回っている工程知識を、MCPツールが呼べる構造にすること。設備の異常判断の根拠を、AIが学べる形で記録すること。 これは技術的な問題である以前に、「現場の知識をどう扱うか」という人間的な問題だ。GooglebookもMulmoClaudeも、その問いに対する一つの答えを示している。そして日本の製造業は、長年かけて蓄積してきた「現場知識の宝の山」を、AIエージェントの力で初めて本当に活かせる時代に入ろうとしている。 AIネイティブOS時代の工場DXは、始まったばかりだ。