【2026年】社内文書の変換はDocling｜外に出さず回せるか

「提案書や製品資料をRAGに入れたいが、資料を外部のサービスに送るのは社内の決まりで難しい」「無料のオープンソースで前処理ができるなら、情シスで回せばよいのでは」——社内文書をAIで検索できるようにしたい会社の、情シスとAI導入の担当からよく出る二つの声です。IBM Research で始まったオープンソースの Docling は、PDF やワード、パワーポイントの資料を、AIが読める構造のデータに社内の機械だけで変換できる道具です。ただし、社外に出さずに回せることと、情シスが無理なく回し続けられることは別の問題です。この記事では、Docling を社内の文書の前処理に使うかを、商用の文書解析のサービスと比べながら、データの流れ、運用の負荷、表と図の読み違いの確認、ライセンスと保守の体制の観点で整理します。

Docling は、資料をAIが読める形に変えるオープンソースの道具

Docling は、文書を生成AIが扱いやすい構造のデータに変換するオープンソースの道具です。公式の GitHub の説明によれば、IBM Research のチューリッヒの研究所の知識処理のチームが始めたもので、現在は Linux 財団傘下のAIとデータの部会が受け入れたプロジェクトとして運営されています。本体のコードの利用の許諾は MIT です。

対応する形式は、PDF、ワード、パワーポイント、表計算、HTML、画像、電子書籍、メール、音声などと幅広く、変換の結果はマークダウン、HTML、JSON などに書き出せます。中心にあるのは PDF の読み取りで、ページのレイアウトの解析、読む順番の推定、表の構造の認識をそれぞれのモデルで行い、見出し、段落、表、図を分けたデータにします。画像化された PDF のための文字認識にも対応しています。

RAGの部品とのつなぎも用意されていて、公式の説明では LangChain などの開発の部品と組み合わせられ、MCP のサーバーを通じてAIエージェントからも呼び出せます。RAGの前処理の一般的な考え方や、同じ分野の Unstructured の選び方は別の記事で扱っているので、ここでは Docling に固有の判断に絞ります。

2026年の状態：速い更新と、保守の体制

Docling を判断するとき、まず知っておきたいのは更新の速さです。配布元の登録情報によれば、2.100.0 が2026年6月9日、2.144.0 が10月28日に公開されています。およそ四か月半で四十以上の版が出ている計算で、10月の後半だけでも、22日、23日、26日、27日、28日と版が重なっています。

中身も実務に関わるものが多く含まれます。10月23日の 2.142.1 では、ワード形式や表計算の中の圧縮された部品を展開するときの大きさの上限、画像のページを読むときの画素数の上限など、悪意のある文書への備えが足されました。26日の 2.143.0 では、ワード形式の隠し文字を、既定で書き出さないようにする変更が入っています。28日の 2.144.0 では、PDF に埋め込まれた文字の情報が壊れているときに、文字認識で置き換える機能が加わりました。

つまり、同じ資料でも版によって変換の結果が変わりうるということです。隠し文字の扱いの変更は、社内の資料に残った削除前の文言がAIの検索の対象に入るかどうかを左右します。更新の速さは保守が活発な証拠でもありますが、版を固定して、上げる前に試す手順を持たないと、ある日から検索の結果が変わった原因を追えなくなります。

• 版と公開日は GitHub の公開履歴と配布元の登録情報に基づきます（2026年10月29日時点）
• 公開の停止やプロジェクトの終了の告知は見当たりません。必要な Python の版は 3.10 以降と説明されています

比べる3つの形

社内文書をRAGに入れる前処理には、大きく三つの形があります。一つ目は、Docling のようなオープンソースを社内の機械で動かす形です。二つ目は、大手のクラウドが提供する文書解析のサービスや、前処理の専門の商用サービスに文書を送って結果を受け取る形です。三つ目は、前処理の道具を使わず、画像を読める生成AIに PDF をそのまま読ませる形です。

三つ目は手早い反面、変換の結果が毎回少しずつ変わり、表の数字の読み違いに気づきにくいという弱みがあります。また、文書を生成AIの提供元に送る点では二つ目と同じです。社外に出さないことが条件なら、選択肢は一つ目か、二つ目のうち社内に置ける商用の製品に絞られます。

一つ目と二つ目の違いは、変換の精度よりも、誰が何を持つかです。商用のサービスは、変換の品質、版の更新、障害の対応を提供元が持ちます。Docling は、それらを全部自社で持つ代わりに、文書を外に出さず、料金を払わずに済むという交換です。どちらが得かは、文書の量、社内の決まり、情シスの人手で変わります。

6つの観点で比べる

社内での導入を判断する場面で使える観点を、六つに絞って比べます。商用のサービスの欄は一般的な傾向で、個別の製品の条件は見積で確かめてください。

観点	Docling を社内で動かす	商用の解析サービス	生成AIに直接読ませる
文書の行き先	既定では社内の機械の中	提供元の環境（社内設置の製品もある）	生成AIの提供元
費用	道具は無料、機械と人の時間	ページ数などで課金	読ませた量で課金
結果の再現性	版を固定すれば揃う	提供元の更新で変わりうる	毎回揺れる
日本語の精度	自社で測る必要がある	製品ごとに差、見積前に試す	強いが読み違いに気づきにくい
更新と障害の対応	情シスが持つ	提供元が持つ	提供元が持つ
やめやすさ	変換結果は自社の形式で残る	出力形式への依存が出る	変換の記録が残りにくい

表から分かるのは、Docling の強みが文書の行き先と結果の再現性にあり、弱みが更新と障害の対応を自社で持つことにある、という構図です。規程や契約のように、社外に出せない文書が多く、量はそれほど多くない会社には Docling が合いやすく、毎日大量の請求書や申込書を処理する会社は、商用のサービスの手厚い保守のほうが合うことがあります。

社外に出さずに回せるか：既定で外に出ないもの、出るもの

Docling が社内の決まりの厳しい会社に向くと言われる理由は、公式の説明にある「機密のデータや外部から切り離した環境のための、手元での実行」です。レイアウトの解析や表の構造の認識のモデルは、手元の機械で動きます。ただし、どの設定でも外に出ないわけではありません。

公式の資料によれば、図の説明を書かせる機能では、外部の環境で動く生成AIを呼び出す設定が用意されています。この設定を使うには、外部の呼び出しを許す項目を明示的に有効にする必要があり、資料には「多くの場合、この設定は文書のデータを外部の提供元に送る」と注意書きがあります。外部の呼び出しを許す項目を、社内の設定で有効にしないことを、運用の決まりに書いておくのが確実です。

もう一つは、モデルの取得です。レイアウトの解析などのモデルは公開の置き場所から取得する作りで、図の説明の機能で使うモデルも Hugging Face の置き場所で指定します。外部から切り離した環境で使うなら、モデルを事前に取得して社内に置き、その場所を指定して動かす手順を最初に作ります。取得したモデルの版も、本体の版と合わせて記録します。

日本語の社内文書で、先に確かめること

Docling は英語の文書を中心に開発されてきた道具で、日本語の精度は自社の文書で測る必要があります。生成AIで文書を一度に読み取る IBM の Granite Docling というモデルについて、IBM の公式の説明では、主に欧米の文字の文書に最適化されており、日本語、中国語、アラビア語は初期の対応だとしています。Granite Docling は2025年9月に公開されたモデルで、利用の許諾は Apache 2.0 です。

日本語の資料で崩れやすいのは、縦書きの部分、ルビ、段組みの多い製品案内、セルを結合した表、図の中に書かれた文字です。画像化された PDF では、文字認識の部品の日本語の精度がそのまま結果に効きます。自社の代表的な資料を二十本ほど選んで、変換の結果を人が読むのが、導入の前にやるべき最初の試験です。提案書、製品資料、規程、議事録、表の多い価格表のように、形の違う資料を混ぜて選びます。

試験では、結果を見る観点を先に決めます。見出しが見出しとして取れているか、段落の順番が正しいか、表の行と列が崩れていないか、数字が一文字も変わっていないか、図の中の文字が抜けていないか。数字の一文字の違いは、AIの答えを丸ごと誤りにするので、価格表や仕様の表は特に丁寧に見ます。

日本語の PDF で見落としやすいのが、埋め込まれた文字の情報の壊れです。見た目は正しく表示されていても、文字を抜き出すと別の文字や記号に化ける PDF は、古い作成ソフトや特殊な書体で作った資料に混じっています。10月28日の 2.144.0 で、壊れた文字の情報を文字認識で置き換える機能が加わったのは、こうした資料への対策です。ただし、どの資料で壊れているかを道具が完全に見分けられるとは限らないので、試験の二十本の中に、古い資料や外部から受け取った PDF を必ず混ぜておきます。化けた文字が検索の対象に入ると、その資料は何を聞いても引かれない資料になり、誰も気づかないまま残ります。

表と図の読み違いを、誰が確かめるか

表の構造の認識は Docling の強みとして公式が挙げる機能ですが、どの道具にも読み違いはあります。結合したセル、ページをまたぐ表、罫線のない表は、行と列の対応がずれやすい典型です。読み違いがあっても変換は成功として終わるので、変換の道具は、自分の読み違いを教えてくれないと考えておきます。

確かめる役は、情シスではなく、資料の中身を知る業務の担当です。価格表なら営業企画、仕様の表なら製品の担当、規程の表なら総務や法務が、変換の結果と元の資料を見比べます。全件を見るのは無理なので、表を含む資料から抜き取り、数字の多い表を優先します。見つけた読み違いは、資料の側を直すか、表だけ別の方法で取り込むかを決めて記録します。

図は、もっと扱いが難しい部分です。図の種類を分類する機能や、図に説明文を付ける機能は既定では無効になっています。説明文を付ける機能を社内の機械で動かすなら、画像を読めるモデルを手元に置く必要があり、機械の負荷も上がります。製品の構成図のような図が答えの根拠になる資料は、図の内容を担当が文章で書き添えるほうが、確実なことが多いです。

提案書と製品資料：マーケの資料で崩れやすいところ

マーケと営業の資料は、社内文書の中でも変換が崩れやすい部類です。パワーポイントの提案書は、一枚に図形、吹き出し、表、写真が混じり、読む順番が見た目の配置でしか決まっていません。Docling はパワーポイント形式を直接読めますが、図形の中の短い文言が、どの見出しに属するかを正しく推定できるとは限りません。

もう一つの落とし穴は、資料の古さと重複です。提案書は案件ごとに少しずつ書き換えた版が大量にあり、同じ製品の古い価格が残った資料も混じります。変換の道具は、どの版が正しいかを判断しないので、取り込む前に、取り込む資料の範囲と最新版の持ち主を決めます。営業の共有の場所を丸ごと取り込むのは避け、マーケが管理する公式の資料の置き場所から始めます。

隠し文字やノートの欄にも注意します。10月の更新でワード形式の隠し文字が既定で書き出されなくなったように、資料には画面に出ない文言が残っていることがあります。パワーポイントの発表者のノートには、社内向けの値引きの方針や、顧客の事情が書かれていることもあります。ノートの欄を検索の対象に入れるかは、取り込みの設定を決める段階で、マーケの責任者が判断します。

規程と契約：版と閲覧の権限を落とさない

規程や契約書をRAGに入れる場合は、変換の精度に加えて、版と権限の扱いが問題になります。規程は改定のたびに版が変わり、古い版の条文に基づく答えは誤りになります。Docling は文書の変換をする道具で、どの版が有効かという情報は、元の文書の管理の仕組みから持ってくる必要があります。変換の結果に、文書の版、改定日、持ち主を付けて保存する作りにしておきます。

閲覧の権限も同じです。契約書や人事の規程は、見られる人が限られます。変換した結果を一つの検索の仕組みにまとめると、元の文書で掛かっていた閲覧の制限が外れてしまいます。変換の段階で元の文書の権限の情報を付け、検索の段階でその権限で絞り込む作りにするのが基本です。権限の付け方の詳細は検索の仕組みの側の設計ですが、変換の道具を通すと権限の情報が落ちることは、Docling を選んでも変わりません。

契約書では、表や条番号の読み違いが特に重い意味を持ちます。条番号の階層が崩れると、AIは別の条の内容を引いて答えます。2.144.0 で見出しの階層を推定する設定が加わったように、階層の扱いは改善が続いている部分ですが、法務の担当が代表的な契約書で結果を確かめるまでは、契約書の取り込みは見送る判断もありえます。

情シスの運用負荷：動かす機械と、版の追従

Docling を社内で回すとき、情シスが持つ仕事は大きく三つです。一つ目は動かす機械です。レイアウトの解析のモデルは一般的な機械でも動きますが、文書の量が多い場合や、画像を読めるモデルを使う場合は、画像処理用の演算装置のある機械が必要になります。公式は Docling を API のサーバーとして動かす別の部品も用意しており、演算装置の有無に応じたコンテナの像を公開しています。

二つ目は、版の追従です。前述のとおり更新が速く、悪意のある文書への備えのような安全に関わる修正も含まれます。上げないと危険が残り、上げると結果が変わる。この板挟みに対しては、四半期ごとなど上げる周期を決め、代表的な資料の変換の結果を前の版と比べてから上げるのが現実的です。安全に関わる修正は、周期を待たずに上げる例外として扱います。

三つ目は、利用の窓口の管理です。API のサーバーの部品の公開ページでは、利用者の認証についての説明は確認できませんでした。社内の他の仕組みから呼び出す形にするなら、前段に社内の認証と通信の暗号化を置き、誰が呼べるかを絞る必要があります。変換に失敗した文書の記録と、再処理の手順も、情シスの運用の範囲に入ります。

失敗の扱いも、版によって変わってきました。公開履歴によれば、10月22日の 2.142.0 から、文書の変換に失敗したときに命令の実行が失敗として終わるようになりました。26日の 2.143.0 では、形式の混ざった圧縮ファイルをまとめて入力できるようになっています。まとめて流す運用では、一部の文書だけが失敗しても全体が成功に見える作りになりがちなので、失敗の一覧を毎回出し、件数が増えたら担当に知らせる仕組みを置きます。

• 社内で動くことだけを理由に、外部の呼び出しを許す設定の有無を確かめずに運用を始める
• 最新版を自動で取り込み、ある日から変換の結果が変わった原因を追えない
• 変換の成功の件数だけを見て、表と数字の読み違いを誰も抜き取っていない
• 営業の共有の場所を丸ごと取り込み、古い価格の資料や発表者のノートまで検索の対象に入っている
• 構築した担当が一人だけで、異動後に版を上げられる人がいない

ライセンスと保守の体制

Docling の本体は MIT の許諾で、商用の利用にも制限は少ない部類です。ただし公式の説明にあるとおり、個々のモデルはそれぞれの許諾に従います。レイアウトの解析や表の構造の認識のモデル、Granite Docling のようなモデル、文字認識の部品は、本体とは別に許諾を確かめる必要があります。社内で配布する手順書を作るときは、使うモデルと部品の許諾の一覧を付けておくと、後から確認する手間が省けます。

保守の体制については、IBM Research で始まり、Linux 財団傘下の部会が受け入れたという経緯が、一社の都合だけで止まりにくい材料になります。一方で、オープンソースである以上、障害の対応や個別の不具合の修正を約束する窓口はありません。社内で使う上で困る不具合が出たときに、自社で直すか、公開の場で報告して待つか、商用の支援を探すかを、あらかじめ決めておきます。

公式の GitHub の説明からは、Docling 本体について有償の支援を受け付ける窓口は確かめられませんでした。IBM の製品や外部の会社の支援を前提にする場合も、その支援がオープンソース版の Docling にどこまで及ぶかは公開資料からは読み取れないので、支援の契約を前提にするなら、どの版のどの部品が支援の対象かを書面で確かめることが必要です。

商用の解析サービスを選ぶ場面

Docling が合わない場面もはっきりあります。一つ目は、処理する文書の量が多く、締め切りのある業務の流れに組み込む場合です。請求書や申込書を毎日大量に処理するなら、障害時の対応を提供元が持つ商用のサービスのほうが、情シスの負荷を抑えられます。

二つ目は、情シスに Python の部品を保守できる人がいない場合です。Docling は画面から使う製品ではなく、Python 3.10 以降の環境で動かす部品です。作った人が異動した後に誰も版を上げられない状態になるなら、無料の道具がいちばん高くつくことになります。三つ目は、手書きの書類や特殊な帳票のように、特定の書類に強い商用の製品が既にある場合です。

商用のサービスを選ぶ場合でも、Docling で確かめた観点はそのまま使えます。代表的な資料での試験、表と数字の抜き取り、版の記録は、提供元が変換の仕組みを更新したときにも必要です。違いは、更新の時期を自社で選べないことで、提供元の更新の告知を誰が読み、いつ試験を回し直すかを決めておく必要があります。社内に置ける商用の製品なら、置き場所の条件と、外部へ送る機能の有無を Docling と同じ観点で確かめます。

逆に、社外に出せない文書が多い、文書の量は中程度、Python を扱える人が社内か委託先にいる、という条件がそろうなら、Docling は有力な選択肢です。両方を併用する形もありえます。社外に出せない文書は Docling、出してよい大量の定型の書類は商用のサービスと、文書の区分で分ければ、それぞれの強みを使えます。

費用の比べ方

Docling の費用は、道具の料金ではなく、機械と人の時間です。機械は、社内の既存の環境で動かすなら追加の費用は小さく、画像処理用の演算装置を新たに用意するなら大きくなります。人の時間は、最初の構築、版の追従、変換の結果の確認、失敗した文書の再処理に分かれます。

商用のサービスは、多くがページ数などで課金されます。比べるときは、月の処理ページ数の見込みにページの単価を掛けた額と、Docling を回す情シスの時間を人件費に直した額を並べます。どちらの場合も、変換の結果を業務の担当が確かめる時間は同じだけかかるので、比べる対象から外しておくと判断がぶれません。試算は、試験の期間に実際に流した資料の件数と、かかった時間を記録してから行うと、見込みの数字が現実から離れにくくなります。

見落としやすい費用は、やり直しです。版を上げたら結果が変わり、すべての文書を変換し直す必要が出ることがあります。変換し直しの手間を抑えるには、元の文書と、変換に使った版とモデルの記録を必ず残すことです。これは商用のサービスから Docling へ、またはその逆に乗り換えるときにも、同じように役に立ちます。

導入の順番と、AIに判断させないところ

Docling を社内に入れるなら、小さく始めて範囲を広げる順番が安全です。

AIに判断させないところも決めておきます。一つ目は、どの資料を取り込むかと、どの版が有効かです。これは資料の持ち主が決めます。二つ目は、表と数字の読み違いの判定で、これは業務の担当が元の資料と見比べて決めます。三つ目は、外部の生成AIを呼ぶ設定を許すかで、これは情報管理の責任者が承認します。Docling の画像を読めるモデルや図の説明の機能は便利ですが、変換の結果が正しいかを、別の生成AIに判定させて済ませないことを、運用の決まりに書いておきます。

導入前のチェックリスト

最後に、Docling を社内の文書の前処理に使う前に確かめる項目をまとめます。

• 取り込む資料の範囲、最新版の持ち主、閲覧の権限の扱いが決まっている
• 外部の生成AIを呼ぶ設定を有効にしないことが、運用の決まりに書かれている
• モデルを事前に取得して社内に置き、本体とモデルの版を記録している
• 自社の代表的な資料二十本ほどで、日本語の変換の結果を業務の担当が確かめた
• 表の読み違いを抜き取りで確かめる担当と、見つけたときの対応が決まっている
• 版を上げる周期と、上げる前に結果を比べる手順がある
• API のサーバーとして動かす場合、前段に社内の認証と通信の暗号化を置いている
• 本体以外のモデルと部品の許諾を一覧にしている
• 保守する人が異動しても版を上げられる体制か、商用の支援の当てがある

このうち一つでも決まらない項目があるなら、その項目が、Docling を選ぶか商用のサービスを選ぶかの分かれ目になります。決まらない理由が人手なら商用のサービス、社内の決まりなら Docling、という読み方をすると判断しやすくなります。

まとめ

Docling は、IBM Research で始まり Linux 財団傘下で運営されるオープンソースの文書変換の道具で、2026年10月28日の 2.144.0 まで速い更新が続いています。既定の処理は社内の機械で完結するので、社外に出せない提案書や規程をRAGに入れる前処理の有力な選択肢です。ただし、図の説明を外部の生成AIに頼む設定を有効にすると文書は外に出ますし、日本語の精度は自社の資料で測るしかありません。商用の解析サービスと比べる軸は、精度より、動かす機械と版の追従と読み違いの確認を誰が持つかです。資料の範囲と持ち主を決め、版を固定し、表と数字を業務の担当が確かめる。この線を引いてから始めれば、文書を外に出さずに、社内のAI検索を育てていけます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。