IBM Graniteが Hugging Face 上で、Granite 4.0 3B Vision を発表しました。
これはひと言でいうと、画像と文章を同時に扱える小型のAIモデルです。こういうモデルは VLM（Vision-Language Model）と呼ばれます。日本語で雑に言えば、「画像を見て、文章で理解できるAI」ですね。
ただし、今回のモデルは単なる「画像の説明がうまいAI」ではありません。
狙っているのはかなり実務寄りで、企業の書類処理です。
たとえば、
といった仕事です。
このあたり、地味に見えて実はかなり重要です。
なぜなら、企業の現場で本当に困るのは「きれいな文章を生成すること」より、PDFや画像に埋もれた情報を正確に機械で扱える形にすることだからです。ここをきっちり狙っているのが、このモデルの特徴だと思います。
元記事では、主な能力として次の3つが挙げられています。
表を、ただ「表っぽく読む」のではなく、行・列・結合セルの構造まで含めて取り出す能力です。
これは見た目以上に難しいです。
表って人間には一瞬で読めますが、AIにとっては、
を判断しないといけません。
元記事では、multi-row / multi-column の複雑な表にも対応できるとされています。
企業文書ではこういう表が普通に出てくるので、ここに力を入れているのはかなり現実的だなと思います。
グラフを見て、ただ「棒グラフですね」と言うだけではなく、
数値の関係や傾向を理解して、構造化されたデータに変換するのが狙いです。
たとえば、
といったことができるとされています。
ここはかなり面白いです。
グラフって、見た目は画像ですが、本質はデータの圧縮表現です。そこをAIが正しくほどけるなら、会議資料やレポートの価値がかなり上がります。
個人的には、VLMの中でもチャート理解はかなり「実用度が高い難所」だと思っています。
これは少し専門用語ですが、簡単に言うと「項目名」と「値」のペアを見つけることです。
たとえば請求書なら、
のように、意味のあるペアとして抜き出します。
単に文字をOCRで読むだけではなく、その文字が何の項目なのかまで理解するのがポイントです。
書類処理ではここがめちゃくちゃ重要で、実務では「読めた」だけでは足りません。使える形に整理されて初めて価値が出るんですよね。
元記事によると、このモデルの性能は主に3つの投資によって支えられています。
順番に見ていきます。
チャート理解が難しい理由は、画像を見るだけでは足りず、
視覚・数値・言語を同時に扱わないといけないからです。
たとえば線グラフなら、ただ線の形を見るだけでなく、
まで考えないといけません。
そこでIBM Graniteが作ったのが、ChartNet。
これは170万件規模のマルチモーダルデータセットで、元記事では 24種類のチャート と 6つの plotting library を含むと説明されています。
しかも面白いのは、1サンプルに以下の5つの対応する要素があることです。
つまり、ただ画像だけ集めたのではなく、
「このグラフは、元のコードとデータからどう見えて、どう説明され、どう問答できるか」をセットで学ばせているわけです。
これはかなり賢い設計だと思います。
グラフ理解って、画像単体だけで学ばせると限界があるはずで、**“正解の意味”を複数の形で結びつける**のが効いていそうです。
しかも人手で検証されたデータや実世界のデータも含め、視覚的な正確さや意味の整合性、 विविध性（多様性）が重視されているとのこと。
この手のデータセットは、量だけ多くても雑だと意味がないので、そこを意識しているのは好印象です。
次の工夫は DeepStack Injection です。
普通のVLMは、画像の情報を言語モデルに1か所でまとめて入れることが多いそうです。
でもそれだと、モデルはそこで一気に
を同時にさばかないといけません。
それに対して Granite 4.0 3B Vision は、画像特徴を層ごとに分けて入れる設計です。
要するに、「何が写っているか」と「どこにあるか」を別々に面倒を見るわけです。
これはかなり筋がいいと思います。
文書処理では、意味だけでなく位置が超重要です。たとえば「この数字はタイトルの横なのか、表の中なのか」で意味が変わることがあります。
だからこそ、この分離は地味ですが効くはずです。
Granite 4.0 3B Vision は、単独の巨大モデルではなく、Granite 4.0 Micro の上に乗る LoRA adapter として提供されています。
LoRA adapter は、ざっくり言うとベースモデルに後付けする軽量な追加学習部品のようなものです。
全部を作り直さずに、必要な能力だけ足せるのが利点です。
この設計の良いところは、画像が必要ないときはテキスト専用のベースモデルに戻せること。
つまり、
を同じ土台で扱いやすいんです。
企業システムって、実際にはかなり混在しています。
あるときはPDFの表を読み、あるときはメール本文だけを処理し、またあるときは画像付き資料を見る。
そういう現場で、1つのモデルを柔軟に使い回せるのはかなり実務的だと思います。派手ではないけれど、むしろここが本当に重要です。
元記事では、いくつかのベンチマークで強い結果が示されています。
ChartNet の human-verified benchmark で、
を記録しています。
特に Chart2Summary では、比較対象の中で最高スコアだったとされています。
Chart2CSV でも、モデルサイズが2倍以上の Qwen3.5-9B に次ぐ2位とのことです。
ここはかなりインパクトがあります。
小型モデルが大きなモデル相手にここまで戦えるなら、実運用では「とりあえず巨大モデルを使う」以外の選択肢が見えてきます。
表抽出では、いくつかのベンチマークでトップ級の結果を出しています。
評価指標は TEDS で、これは表の構造と内容の両方を見る指標です。
単に文字が合っているかではなく、表として正しく復元できているかが問われます。
この結果はかなり実務向けです。
表抽出は「見た目が似てる」ではなく、「あとで機械が使える」ことが大事なので、こういう評価で強いのは説得力があります。
VAREX というベンチマークでは、zero-shot で 85.5% EM accuracy を達成したとあります。
zero-shot は、簡単に言うとその課題に合わせた追加学習なしで試したという意味です。
EM（Exact Match）は、答えが完全一致しないと正解にならない厳しい評価です。
この条件で 85.5% はかなり立派です。
書類処理は、ちょっと違うだけで実務上は困るので、こういう厳しめの指標で結果を出しているのは信頼感があります。
元記事では、使い方を大きく2つに分けています。
画像単体を直接入力して使う方法です。
これは、
ときに便利です。
もう1つは、Docling と組み合わせる方法です。
Docling は、文書を解析してページ構造や要素を扱うための仕組みとして使われています。
この構成だと、
という流れが作れます。
要するに、「文書全体をざっくり解析する役」と「切り出した部分を賢く読む役」を分業させるわけです。
この構成はかなり現実的で、私はかなり好きです。AIに全部一気にやらせるより、役割分担したほうが、たいてい安定するからです。
元記事では、主なユースケースとして次のようなものが挙げられています。
このへんは、かなり「現場で使うAI」という感じです。
派手なデモより、こういう地味だけど毎日効く用途のほうが、実際には価値が大きいのではないかと思います。
Granite 4.0 3B Vision は、見た目だけのマルチモーダルモデルではなく、
企業文書を正確に読むための実務特化VLM という印象でした。
特に印象的だったのは、
です。
個人的には、こういうモデルは「すごいデモ」よりも「地味な業務を静かに効率化する」方向で真価を発揮すると思います。
AIの世界では巨大モデルが話題になりがちですが、実際の業務では小さくて、速くて、組み込みやすくて、そこそこではなくちゃんと当たるモデルのほうがありがたいことが多いです。
Granite 4.0 3B Vision は、まさにその路線の有力候補ではないでしょうか。
参考: Granite 4.0 3B Vision: Compact Multimodal Intelligence for Enterprise Documents
