LMMとは
LMMとは、テキストだけでなく画像、音声、動画など複数のデータ形式を同時に理解し処理できるAIモデル
読み: エルエムエム
かんたんに言うと
目隠しをして書類を読んでいた担当者が、目を開けて現場の写真や音声記録を同時に確認しながら判断を下せるようになった状態。
LMMがテキストと画像や音声を統合処理する次世代AIの全体像と実務の壁
LLMの限界はテキストしか読めないこと。現場のデータは文字だけで構成されていない。設計図面、製品の傷、会議の録音。これらを別々に処理するのは手間がかかる。LMMはモダリティと呼ばれる異なるデータ形式をそのまま飲み込む。テキストと画像を同時にプロンプトへ放り込めるのである。
便利に聞こえるだろうか。
ただ、実務で使うとそう単純ではない。テキストの推論能力と画像の認識精度が常に一致するわけではないからである。画像内の細かい数値を読み落としたまま、もっともらしいテキストを生成することがある。
複数のデータ形式を同時に理解する技術的仕組み
裏側で何が起きているのか。Transformerアーキテクチャをベースに、画像や音声をエンコーダでベクトル化し、テキストと同じ潜在空間にマッピングしている。要するに、写真も声もAIにとっては数字の羅列に変換される。
ここで問題になるのが計算リソースである。
画像をベクトル化する処理は重い。NVIDIAのH100を何枚積めばリアルタイム処理が追いつくのか。クラウドのAPIを叩くたびに課金メーターが跳ね上がるのを見ると、本当にすべてのデータにLMMを通すべきか判断が分かれる。テキストだけの処理と比べてレイテンシも悪化する。
製造や法務の現場における活用事例と代表的なツール
マーケティングのバナー生成の話はもういいだろう。もっと泥臭い現場の話をする。
製造業の検品ライン。カメラで撮影した基板の画像と、過去の不良品レポートのテキストをGPT-4oに食わせる。微小なクラックの判定と原因の推測を同時にやらせるのである。法務ならどうである。契約書のPDFをそのままClaude 3.5 Sonnetに投げ込み、手書きの修正指示とテキストの条文を突き合わせる。
Gemini 1.5 Proのコンテキストウィンドウの広さは動画解析で活きる。監視カメラの映像を1時間分丸ごと読み込ませて、特定の人物が映った時間帯を特定させる。
だが、現場の照明が暗いだけで認識率は急激に落ちる。結局はカメラの性能次第というオチも少なくない。
導入時に直面する技術的限界と評価基準
LMMは万能ではない。画像内の文字を読み間違えるOCR的なミスと、推論のミスが混ざって出力される。どこで間違えたのか切り分けるのが非常に悩ましい。
オンプレミスで動かそうとすればGPUの調達コストが重くのしかかる。クラウドのAPIを使えばデータ流出のリスクをどう担保するのかという議論に戻る。
何でもかんでもLMMにやらせようとするのは素人の発想である。テキストだけで済む処理は軽量なLLMに任せ、どうしても画像や音声の文脈が必要な箇所にだけLMMを挟む。このルーティングの設計こそが、実務家の腕の見せ所になる。
LMMとLLMの比較
| 比較項目 | LLM | LMM |
|---|---|---|
| 処理可能なモダリティ(テキストのみvs画像・音声込み) | テキスト文字列の入力と出力・処理モダリティのみに限定される | 画像や音声、映像など複数のモダリティを入力および処理可能 |
| 入力エンコーダーの多様性 | 文字データの文脈のみから実世界の概念を紐付けて理解を行う | 視覚情報等から環境を直感的に解釈し実世界理解の深度が深い |
| 実世界理解の深度 | 文章推論やシステムテキスト生成等テキストのタスクに最適 | 画像の内容把握や音声対話など幅広いクリエイティブな用途に最適 |
| 計算リソース・ストレージ要件 | 初期導入から実運用までの学習・運用コスト | 複雑なカスタマイズに応じた拡張的な運用コスト確保 |
| 推論コスト | シンプルなユースケースに適合し利用シナリオが限定的 | エンタープライズや複雑なビジネス要件等に適合する |
テキスト特化か、マルチモーダルかで分かれます。文章校正やシステムテキスト生成に専念するならLLM、画像や動画の内容を直感的に解釈して推論する視覚・音声能力が必要ならLMMの利用が前提となります。
当社の見解
当社はOpenAI APIを完全廃止し、EmbeddingもLLMも全てローカルで稼働させている（2026年4月時点）。これにより月額のAPI費用がゼロになっただけでなく、機密情報や顧客データを外部に送信せずにAI処理できるようになった。クライアントのログデータをマスキングなしでそのまま分析に回せるのは、ローカルLLMだからこそ実現できる。2026年4月にはOllama常駐実行（CPU 25%、GPU 30%を常時占有）を廃止し、FastEmbed（ONNX Runtime）による非常駐型推論に移行。処理が必要な瞬間だけプロセスを起動し、完了後に即座に終了する設計で、アイドル時のリソース消費をゼロにした。あえて一般的なデスクトップPC環境で複数のローカルLLMを実機検証した経験から言えることは、ベンチマークスコアと実務での使い勝手、そして常駐時のリソース消費は全て別の指標だということだ。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。