VLM（Vision Language Model／視覚言語モデル）とは、画像などの視覚情報と、テキストで書かれた言語情報を統合して理解するAIモデルです。画像に何が写っているかを判別する画像認識技術と、文章を理解・生成する言語モデルは、長らく別々の技術として発展してきました。VLMはこの2つを統合し、「画像を見て、その内容について言葉で説明・推論する」ことを可能にしました。

混同されやすい3つの技術を整理します。

決定的な違いは、OCRが「変換」であるのに対し、VLMは「記述」であるという点です。OCRは文字がなければ何も出力しません。VLMは文字がなくても、写っているものを言葉にします。

VLMの仕組みは、一般に「画像エンコーダーで視覚情報をベクトルに変換し、言語モデルがそれを解釈して文章を出力する」と説明されます。ただ、それだけでは何が起きているのか掴みにくいかと思います。実際の出力をご覧いただくのが早いでしょう。

以下では、クラウドストレージのAI機能である DirectCloud AI が実際に生成したデータを例に見ていきます。図1は、ある製品の設定手順を説明した、ごく普通の図版です。

これをアップロードすると、AIは図2のようなデータを生成します。これがデータチャンク——AIが質問に答えるときに参照する、画像の内容を言語化したものです。

注目していただきたいのは、その構造です。

Type は画像の種別を分類します。この図版は「スライド / 図解 / テキスト画像」と判定されました。Summary は内容を一文に要約します。Details は視覚的な構成を記述します——紫色の長方形ボックスが4つ横一列に並んでいること、その間が右向きの山形矢印で接続されていること、丸付き数字の項目、末尾の「※」で始まる注意書き。いずれも文字ではなく、レイアウトと図形の情報です。そして Text が、いわゆる文字起こしにあたります。

従来型のOCRが担えるのは、このうち Text の1層だけです。ほかの層は、文字を文字列に変換するだけでは決して生まれません。これらの記述は、AIが画像を見て解釈した結果だからです。読んでいるのではなく、見て解釈している——だからこそ、事前の設定なしに、はじめて見る図版でも内容を言語化できます。

図の構造まで読む -「Diagram」の層

最後の Diagram は、画像に図解が含まれる場合に生成される層です。この図版では、こう記述されています。

「ノード」「直列接続」という言葉が示すとおり、4つのボックスが単に並んでいるのではなく、順序を持ったフローとして把握されています。文字を拾うだけであれば「Step 1 辞書作成」から「Step 4 OCR設定」までの語が並ぶだけで、それらがどうつながっているかは残りません。図で最も伝えたかった構造こそが、失われてしまうわけです。

図4は機械部品の製図です。寸法、はめあい公差、表面粗さ、幾何公差枠、注記。設計や調達の現場では日常的に扱われる図面ですが、ファイル名で管理されている限り、中身で探すことはできません。

生成されたチャンクの Details には、こうあります。

上面図・正面図・端面図という三面の配置。台座から立ち上がる支柱が「中央がくびれた」形状であるという把握。端面図の4つの小穴が「対称に」並んでいるという読み取り。右下のタイトル欄が「2列3行の表」であるという構造の認識。いずれも図面のどこにも、文字としては書かれていません。「図面を、図面の中身で探す」という、これまで成立しなかった検索が視野に入ってきます。

もうひとつ、性質の違う例を挙げます。図6は、社内研修でホワイトボードを使って説明している場面の写真です。手書きの文字に加えて、囲み、矢印、波線、さらに人物までが写り込んでいます。文字だけを抜き出そうとすると、何が起きているのか分からなくなる種類の画像です。

Summary は、写真の状況をこう要約しています。

Details には、続けてこうあります。

「説明中の姿勢に見える」という判断は、画像のどこにも書かれていません。立ち位置、マーカーを持つ手、開いた左手、口の開き方。それらを組み合わせた解釈です。

星形の落書き、トレイのイレーサー、観葉植物の葉。それ自体に業務上の意味はありません。しかし「あの研修のときの写真」を後から探すとき、手がかりになるのは、案外こうした情報です。

そしてこの記述があることで、検索の性質が変わります。「ホワイトボードを使って説明している研修の写真を探して」——画像に一度も現れない言い回しで、この一枚にたどり着けるようになります。文字を拾うだけでは、決して引っかかりません。

ここまでの内容を、導入検討の観点から整理します。

ここまで見てきたとおり、VLMは画像を「文字に変換する」のではなく「内容を記述する」技術です。この性質が、そのまま運用上の前提にもなります。詳しくは最後の章であらためて扱います。

では、これは業務の何を変えるのでしょうか。押さえておきたい前提が一つあります。

VLMは、判定するのではなく、記述します。画像の内容を言語化し、検索できるデータとして残す技術です。良否を判断したり、数値を算定したりする機能ではありません。だからこそ効くのは、「探せない画像が業務を止めている」場面です。

5つの事例に共通しているのは、AIが判断を代わりに下すのではなく、人が探せるようになるという構造です。点検の良否を決めるのは点検員であり、査定額を決めるのは査定担当者です。そこは変わりません。変わるのは、判断の材料となる過去の画像に、数秒でたどり着けるようになるという点です。

「探す」で終わらせず、書類作成まで一続きにする

製造業の設備点検を例に、もう少し具体的に見てみます。

従来のフローでは、点検員が現場で写真を撮り、事務所に戻ってから該当する写真を探し、内容を目視で確認して報告書に書き起こしていました。撮影から報告書完成までに、探す・確かめる・書くという3つの手作業が挟まります。

現在の時点で、該当する写真を探し出し、報告書の下書きを作成するところまでは一度の依頼で完了します。従来は写真を探し、目視で確認し、内容を書き起こしていた3つの工程が、依頼ひとつにまとまります。

残っているのは、その下書きをOffice文書やPDFといった文書ファイルの形に整える工程です。ここについては、回答をそのままファイルとして出力する機能を今後実装予定です。実装後は、依頼から成果物までが途切れずにつながります。

いずれにせよ重要なのは、写真を探す工程と、報告書を書く工程が、同じ場所で完結するという点です。画像を検索できるだけでは、結局そのあと人が内容を書き起こすことになります。

ここまで技術の話をしてきましたが、VLMは技術であって製品ではありません。同じVLMでも、どういう形で提供されるかによって、業務に載せるための準備がまったく変わります。大きく4つに分かれます。

汎用AIチャット・APIは、最も手軽な入口です。画像をその場でアップロードして質問すれば、すぐに答えが返ってきます。ただし対象になるのはアップロードした画像だけで、結果は残りません。同じ質問を明日また誰かがすれば、また同じ作業からやり直しです。そして社内の画像を外部サービスへ持ち出すことにもなります。

エッジ画像認識ソリューションは、カメラ映像をその場で解釈する方式です。エッジ側で物体や動作を検出し、VLMがそれらを組み合わせて状況全体を理解します。強力ですが、専用機器と個別開発、現場への設置が前提になります。すでに保存されている画像は対象になりません。

VLM開発・学習基盤は、自社データでモデルを作り込む方式です。特定業務での精度を追求できますが、アノテーション工数、開発費、期間が必要になります。

そしてストレージ統合型は、性質がまったく異なります。対象になるのは、すでに社内に保存されている画像そのものです。あらためてどこかへアップロードする必要も、機器を設置する必要も、モデルを開発する必要もありません。保存した時点で処理され、検索できるデータとして残ります。

言い換えれば、社内に蓄積してきたナレッジを、そのまま使える状態に変えるという形です。過去の点検写真、現場写真、板書、図面。長年たまっていた画像が、追加投資なしで検索対象になります。

2026年7月28日のアップデートで、DirectCloud AIが画像ファイルに対応しました。本記事でご覧いただいた図1から図7は、すべてこの機能が実際に生成したデータです。

画像対応は、単発の機能追加ではありません

この画像対応は、DirectCloud AIが継続して取り組んできたRAGパイプラインの改善の一部です。

RAGとは、社内文書を検索し、その内容にもとづいてAIが回答を生成する仕組みです。一般的な知識ではなく自社の文書にもとづいて答えられる点が最大の利点ですが、回答品質を左右するのは、実はLLMそのものよりも「どの資料を、どの順序で、どれだけ正確にLLMに渡すか」という前段の工程です。

2026年3月には、docxにMarkItDown、PDFにUnstructuredを導入し、表の行列構造や見出し・脚注を保持できるようにしました（参考：DirectCloud最新アップデートが変えるAI活用とインフラの常識）。

そして2026年6月、PDFの読み取り方式を大きく転換しています。従来のUnstructuredは、物体検出・表構造解析・OCRという複数のモデルを順に走らせる構成でした。これを、ページ画像を直接解釈するEnd-to-End方式のVLMパーサーへ切り替えています。日本語や数式の誤認識、メモリ使用量の急増といった課題への対応です。

つまり、DirectCloud AIのPDF読み取りは、6月の時点ですでにOCRベースの構成から離れていました。今回の画像対応は、文書のページに対して行っていた解釈を、独立した画像ファイルへ広げたものです。同じ考え方の延長線上にあります。

RAGパイプライン全体の改善内容——チャンキングの強化、Hybrid Search、リランキング、プロンプトガードレールの設置などについては、別記事「社内文書を安全にAI活用するために——DirectCloud AIが実現する高精度RAGの技術的基盤」で詳しく解説しています。

解釈を、読んで、直せる

ここで、VLMという技術の性質にあらためて向き合う必要があります。VLMの出力は変換結果ではなく解釈です。その解釈には、運用上おさえておくべき前提が3つあります。

• ●言語化は保存時に一度だけ行われ、その内容が以後ずっと参照され続けます。つまり、そのときの解釈がそのまま残ります。
• ●精度は画像の状態に左右されます。大きな傾き、不鮮明な文字、判別の難しい手書きなど、条件が悪いほど誤りは生じやすくなります。
• ●誤りは自然な文章の形で現れます。文字化けや空白になるOCRの誤読と違い、読んだだけでは異常だと気づきにくいという特徴があります。

この3つを合わせると、ひとつの要件が導かれます。AIが何をどう解釈したのかを人が確認でき、必要なら直せること。解釈が残り続けるからこそ、それを確かめる手段が必要になるわけです。

DirectCloud AIにはチャンクエディターが用意されています。図2、図5、図7でご覧いただいたのは、まさにその画面です。

• ●AIが画像をどう解釈したかを、そのまま読める。回答の根拠がブラックボックスにならず、監査の対象にできます。
• ●解釈を修正できる。このとき原本の画像ファイルは1バイトも変更されません。原本の完全性を保ったまま、AIの読み方だけを組織の責任で調整できます。
• ●処理はストレージの中で完結する。既存のアクセス権限体系がそのまま適用され、権限を持たないユーザーの回答にその画像が現れることはありません。

AIに任せきりにしない。AIの読み方を、組織が統制する。強力な機能だからこそ、統制とセットで提供する。DirectCloudが一貫して取ってきた姿勢は、画像対応においても変わりません。

VLMは、画像を文字に変換する技術ではなく、画像の内容を言葉で記述する技術です。だからこそ、文字のない写真も、専門的な図面も、斜めから撮った手書きの板書も、検索できる情報に変えられます。

一方で、返ってくる答えが解釈である以上、常に正しいとは限りません。その解釈を確かめられる手段を持っているかどうかが、AI活用の分かれ目になります。精度を競う段階から、精度の限界を運用でどう扱うかを競う段階へ。画像対応が示しているのは、おそらくそういう変化です。

すでに社内に蓄積されている画像を、どこまで資産に変えられるか。まずは手元のフォルダを、一度そういう目で見てみてください。DirectCloud AIの機能詳細や対応形式の一覧は、以下の資料にまとめています。