【2026年】Unstructuredの選定｜OSSか商用基盤か

「OSSなら無料なので、とりあえずライブラリで共有フォルダを全部読ませればいい」「前処理は最初に一度やっておけば、あとはAIが勝手に答えてくれる」——社内文書をAIに読ませる準備を任された担当者が、最初に抱きがちな見通しです。ただ、前処理は一度きりの変換作業ではありません。本当は、文書が増え、直され、権限が変わるたびに回り続ける運用であり、どこで動かすか、誰の権限で文書を読むか、何を人が確かめるかを決めないと、検索の精度より先に情報管理が崩れます。この記事では、社内文書をAIが読める形に整える前処理の道具 Unstructured を例に、OSSと商用基盤のどちらを選ぶか、文書が社外に出るか、表や図の読み落としと権限情報をどう扱うかを、2026年の公式情報をもとに整理します。

Unstructured は、社内文書をAIが読める部品に分ける前処理の道具

Unstructured は、社内に散らばる文書を、AIが検索し回答に使える形に整える前処理を担う米国の会社と製品の名前です。PDF、表計算、スライド、メール、画像として保存された書類などを読み込み、見出し・本文・表・図の説明といった部品に分け、検索に向いた大きさに区切り、検索用の数値（埋め込み）に変えて、指定した保存先に書き出すまでを受け持ちます。

2026年10月時点の公式サイトでは、製品を三つに分けて紹介しています。文書を一件ずつ変換する窓口（APIや、AIエージェントから呼び出すためのMCPの窓口）、取り込みから書き出しまでを定期的に回す処理の流れ、そして社内検索を組み立てる新しい製品（先行提供）です。対応するファイルの種類は、同じ公式サイトの中でも「65種類以上」「50種類以上」と表記が揺れていますが、少なくとも主要な業務文書は一通り扱えると説明しています。読み込み元と書き出し先には、それぞれ20以上の接続先を挙げています。

社内文書の前処理そのものの考え方（読ませる範囲の決め方、読み取れない資料の型、1件の大きさ）は、別の記事で一般論として整理しています。ここでは、Unstructured という特定の道具を社内に入れるかどうかの判断に絞ります。中心になるのは、OSS版か商用基盤か、文書の行き先、表と図、権限情報の四つです。

誤解：OSS版と商用基盤は、同じものの無料版と有料版ではない

Unstructured のOSS版は、GitHub で公開されている Python のライブラリで、Apache 2.0 のライセンスで商用にも使えます。公式は、OSS版は今後も完全に無料であり続けると明記しています。2026年10月時点で1万5千を超える星が付いており、社内文書をAIに読ませる仕組みの部品として広く使われてきました。

ただ、OSS版と商用基盤は、機能を絞っただけの関係ではありません。公式の GitHub のページでは、より高い品質を求めるなら商用の変換の窓口を使うよう案内し、自社の評価として、表の中身の正確さが2倍、元の文書にない内容を作り出す割合が58%少ない、文字の正確さが0.878対0.715、という比較を載せています（2026年9月の自社評価）。変換の仕組みそのものが違うと考えたほうが実態に近いでしょう。

この比較は、ベンダー自身が作った評価であることに注意が要ります。注記によれば、OSS版は1,000ページ超、商用版は224ページで測っており、条件もそろっていません。自社の文書で両方を試すまでは、精度の差は「商用版のほうが高いと提供元が公表している」以上には扱わないのが妥当です。一方で、変換の過程で元にない内容が作り出されうると提供元自身が認めている点は、どちらを選ぶにしても重く受け止めるべき事実です。

2026年の動き：実在と鮮度を確かめる

海外の道具を入れる前には、会社と製品が動き続けているかを確かめます。Unstructured は、2024年に大手のベンチャーキャピタルが主導し、データ基盤や半導体の大手の投資部門が加わった資金調達を発表しています。2026年に入ってからは、公式サイトの製品の構成が変換の窓口・処理の流れ・社内検索の三本立てに整理され、2026年9月付の自社評価がOSS版の公開ページに掲載されています。

接続先の側の変化にも目を配ります。公式の説明書によれば、SharePoint の読み込みは Microsoft Entra ID に登録したアプリで認証する方式に変わっており、旧来の認証方式は2026年4月2日にすべての環境で使えなくなると案内されていました。前処理の仕組みは、接続先の仕様変更で止まることがあるという前提で、誰が告知を追い、誰が設定を直すかを決めておく必要があります。

2026年10月時点で、日本法人や国内の販売代理店、日本語の窓口は公式の資料では確かめられませんでした。商用基盤を契約する場合、契約・請求・問い合わせは英語で進む前提になります。OSS版だけを使う場合は契約は不要ですが、不具合は GitHub の公開の場で報告するしかなく、社内文書の中身を含む不具合の再現情報を公開の場に貼らないという線も、最初に決めておきます。

OSS版か商用基盤か：五つの観点で比べる

どちらを選ぶかは、変換の精度だけでは決まりません。動かす場所、文書の行き先、日本語の準備、運用の手間、費用の増え方の五つで並べると、判断の分かれ目が見えてきます。

観点	OSS版（自社で動かす）	商用基盤（共用のクラウド）	商用基盤（専用環境・自社のクラウドの専用区画）
動かす場所	自社のサーバーや端末	提供元のクラウド	専用の環境、または自社のクラウドの専用区画
文書の行き先	社外に出ない（外部のAIで画像を読ませる設定を除く）	提供元に送られる	自社の管理する区画の中で処理できる
日本語の準備	読み取りエンジンと日本語の辞書を自社で入れる	提供元の設定に依存。自社の文書で確かめる	同左
運用の手間	更新・不具合対応・監視を自社で担う	提供元が担う。接続と設定は自社	提供元と分担。契約で範囲を決める
費用の増え方	サーバー費と人手	ページ数に比例	個別見積もり

表から分かるのは、OSS版は「文書を社外に出さない」代わりに「精度と運用の責任を自社で持つ」選択だということです。社内に Python の仕組みを保守できる担当がいて、扱う文書がテキスト中心なら、OSS版で十分なこともあります。スキャンした書類や複雑な表が多く、保守の人手が足りないなら、商用基盤の専用環境を候補にするのが現実的です。共用のクラウドは、社外に出してよい文書で精度と手間を確かめる段階に向いています。

文書は社外に出るのか：三つの置き方と、画像を読ませる外部のAI

商用基盤の置き方は、公式の料金のページによれば三つです。複数の顧客が共用するクラウド、顧客ごとに分けた専用の環境、自社が契約するクラウド（Amazon・Azure・グーグルのクラウド）の専用区画です。専用の環境と自社のクラウドの専用区画は、上位の契約に限られると案内されています。同じページでは、データの安全の項目に「データを保持しない」と掲げています。

ここで見落とされやすいのが、画像を読ませる外部のAIです。Unstructured は、読み取りが難しいページを画像として、文字と画像を同時に扱えるAIのモデルに読ませる方式を選べ、公式は10種類以上のモデルに対応するとしています。この方式を使うと、文書のページの画像が、そのモデルを提供する別の会社にも渡る可能性があります。OSS版を自社で動かしていても、この設定を有効にすれば文書は社外に出ます。

• 「データを保持しない」が、処理中の一時的な保存や障害対応のための記録まで含むのか、契約書と安全面の資料で確かめる
• 画像を外部のAIに読ませる方式を使う場合、どの会社のどのモデルに送られ、その会社が送られた画像をどう扱うかを確かめる
• 確かめた内容と回答者、日付を社内の台帳に残し、契約の更新時に見直す

社外に出せない文書が含まれるなら、文書を三つに分けるのが現実的です。社外に出してよい文書は共用のクラウドで、社外に出せないが重要度の高くない文書は専用の環境で、契約や人事など最も重い文書は前処理の対象から外すか、OSS版を外部につながない環境で動かす。置き方を文書の重さで分けると、全体を最も厳しい条件に合わせる費用を避けられます。

日本語の文書で、先に確かめておくこと

OSS版でスキャンした書類や画像を読む場合、公開の読み取りエンジン（OCR）と、その言語の辞書を自社で入れる必要があります。公式の説明では、追加の言語に対応するには言語の辞書を別に入れるよう案内しています。日本語の辞書を入れ忘れると、エラーにならないまま、意味のない文字列や空の部品が出力されることがあります。

日本語の業務文書には、海外の文書では少ない特徴があります。縦書きの社内報や契約書、印影や手書きの書き込み、表の中に改行を多用した仕様書、欄外に小さく書かれた注記などです。公式は手書きを含む読み取りに対応するとしていますが、日本語のこうした文書での精度は公式の資料では確かめられません。自社の典型的な文書を20〜30件選び、OSS版と商用基盤の両方に通して、人が目で比べるのが、最も確かな確かめ方です。

比べるときは、読み取れた文字の量ではなく、業務で必要な情報が正しく取れているかを見ます。たとえば、価格表なら品番と価格の対応、規程なら条文の番号と本文の対応、仕様書なら単位の付いた数値です。文字はすべて読めているのに、表の行と列の対応が崩れているという失敗は、一見すると成功に見えるので、意識して確かめないと見落とします。

表と図の読み落としは、変換のあとに人が見つける

社内文書をAIに読ませて最も困るのは、表と図です。公式サイトでは、複数ページにまたがる複雑な表でも、行・列・見出しとその関係を保つと説明しています。それでも、結合したセル、ページをまたぐ表の見出しの繰り返し、表の中の注記の番号などは、変換の仕組みにとって難しい箇所です。

図はさらに扱いが難しくなります。グラフや構成図を、画像を読めるAIに説明させる方式では、AIが図から読み取った内容を文章にするため、図にない数字や関係を、もっともらしく書き足すことがあります。提供元の比較で「元の文書にない内容を作り出す割合」が指標になっていること自体が、この危険が現実にあることを示しています。

• 変換結果を確かめずに、全文書をそのまま検索の対象に入れる
• 図の説明文をAIに書かせ、元の図と見比べないまま回答の根拠に使う
• 表の変換が崩れた文書を、文字が取れているという理由で合格にする
• 読み取りに失敗した文書を一覧にせず、どの文書が検索から漏れているか分からない状態にする
• 画像を外部のAIに読ませる設定を、文書の重さを確かめずに全体に有効にする

対策は、AIに変換結果の良し悪しを判定させないことです。人が確かめる範囲を先に決め、変換の仕組みには、元の文書のどのページのどの部分から取ったかを必ず残させる。部品ごとにページ番号と元の位置が付いていれば、回答の根拠を人が元の文書でたどれます。表と図を多く含む文書は、変換後の部品を人が抜き取りで確かめてから検索の対象に入れる、という段階を設けます。

権限の情報を落とさない：取り込めるのは取り込んだ時点の写し

社内文書をAIに読ませるとき、最も重い問題は、本来見られない人に文書の中身が回答として出てしまうことです。Unstructured の SharePoint の接続では、文書の閲覧・更新・削除ができるユーザーやグループの情報を、部品の付帯情報として書き出せます。検索のときにこの情報を使えば、質問した人が見られる文書だけを回答の根拠にする仕組みを作れます。

ただし、公式の説明書には重要な注意が書かれています。この権限の情報は取り込んだ時点でのみ正しく、実行時の認可やアクセス制御の判断に使うべきではないと明記されています。さらに、権限の情報が更新されるのは文書の中身が変わったときだけで、差分だけを処理する設定では、権限だけが変わっても新しい情報は出力されません。サイトの所有者・メンバー・閲覧者という標準のグループの権限も出力されないと書かれています。

つまり、人事異動で閲覧権限を外しても、文書の中身が変わらない限り、前処理側の権限の情報は古いまま残るということです。これを防ぐには、取り込んだ権限の情報は検索の絞り込みの目安にとどめ、回答を返す直前に、元の SharePoint に問い合わせて質問した人の権限を確かめる設計にします。手間はかかりますが、前処理の道具に権限の判断を預けないことが、社内向けAIの情報管理の要になります。

接続に渡す権限：前処理の仕組みは、強い鍵を持つ

前処理の仕組みが文書を読むには、文書の置き場への鍵を渡す必要があります。SharePoint の場合、公式の説明書では Microsoft Entra ID にアプリを登録し、その識別子と秘密の鍵を設定するよう案内しています。必要な権限として、サイトの読み書き（読み込みと書き出しの両方を使う場合）と、全ユーザーの情報の読み取りが挙げられています。いずれも組織全体に及ぶ強い権限です。

強い鍵を持つ仕組みを社外の基盤に置く場合、その基盤が侵害されたときの影響は、前処理の対象の文書にとどまりません。読み込みに使う鍵と書き出しに使う鍵を分け、読み込みの鍵には書き込みの権限を与えない、対象のサイトを最小限に絞る、秘密の鍵に有効期限を設けて定期的に替える、といった基本を、情報システムの担当と最初に取り決めます。

認証の方式にも選択肢があります。公式の説明書では、アプリの識別子と秘密の鍵で認証する方式のほかに、利用者の名前とパスワードを使う方式も挙げています。後者を選ぶと、特定の社員のアカウントで文書を読みに行くことになり、その社員が異動や退職をしたときに処理が止まるうえ、その社員が見られる範囲がそのまま前処理の対象になります。個人のアカウントではなく、用途を限ったアプリの登録で認証する方式を選び、登録したアプリの持ち主と、鍵を替える担当を、情報システムの台帳に記録しておきます。また、権限の情報は利用者やグループの識別番号で書き出されるため、名前と照らし合わせるには別の問い合わせが必要になる点も、設計の段階で織り込んでおきます。

また、公式の説明書では、自社のサーバーで動かす形の SharePoint には対応していないと明記されています。社内の文書がファイルサーバーや自社運用の文書管理に残っている場合は、別の接続方法を検討するか、対象を整理してからクラウドの置き場に移すかを決める必要があります。

マーケ部門での使いどころ：営業資料と過去の企画書

情報システムの話に見えがちですが、前処理の道具はマーケ部門の資産にも効きます。ホワイトペーパー、導入事例、セミナーの投影資料、展示会の配布物、過去の企画書は、多くがPDFやスライドで、表や図に重要な数字が入っています。これらを社内向けのAIで検索できるようにすれば、営業が提案の根拠になる事例や数字を探す時間を減らせます。

ただしマーケの資料は、版の管理が甘くなりがちです。同じ事例の古い版と新しい版、社外に出した版と社内向けの下書きが同じフォルダに並んでいることがよくあります。前処理の対象には、社外に公開した最終版だけを入れ、下書きや未承認の数字を含む版は外すと決めておかないと、AIが未承認の数字を根拠に提案文を作ってしまいます。

もう一つの注意は、資料の中の数字の出どころです。導入事例の効果の数字や市場規模の推計は、図表の中にだけ書かれていることが多く、前処理で読み落とすか、図の説明を作る過程で数字が変わる危険があります。図表に入った数字は、変換後の部品と元の資料を人が見比べてから検索の対象に入れるという手順を、マーケの資料に限っては必須にしておくと安全です。

定着の手順：最初の30日で決めること

前処理の仕組みは、最初に全部の文書を流すほど失敗が見えにくくなります。小さく始めて、確かめる習慣を作ってから広げるのが定着の近道です。

30日の終わりに残すべきなのは、変換の精度の数字ではなく、どの種類の文書がどう失敗し、誰がどう補うかの一覧です。これがあれば、対象の業務を広げるときに、同じ確かめ方を繰り返せます。

更新と削除に、前処理を追従させる

社内文書は毎日のように直され、消され、置き場を移されます。前処理の仕組みは、変わった文書だけを処理し直す設定で回すのが一般的ですが、ここに落とし穴があります。前述のとおり、権限だけの変更は再処理のきっかけにならないことがあり、文書の削除が検索の保存先に反映されるかも、接続先と設定によって変わります。

削除が反映されないと、廃止した規程や撤回した価格表が、検索の保存先に残り続けます。AIはそれを根拠に、資料どおりの、しかし古い回答を作ります。元の置き場から消した文書が、検索の保存先からも消えたかを定期的に照らし合わせる手順を決めておきます。月に一度、元の置き場の文書の一覧と、保存先にある文書の一覧を突き合わせるだけでも、多くの事故を防げます。

前処理の設定を変えたときの扱いも決めておきます。区切りの大きさや読み取りの方式を変えると、同じ文書から違う部品が作られ、検索の結果が変わります。設定を変えたら対象の文書を全件処理し直し、変更前後で代表的な問いの回答を比べるという手順を、変更の承認とセットにします。

費用の増え方と、比べるときの物差し

商用基盤の料金は、公式の料金のページによれば、最初の1万ページまで無料で、その後は従量課金で1ページあたり0.015ドルとされています。複数の利用者の管理や専用の環境、自社のクラウドの専用区画を含む上位の契約は個別見積もりです。料金のページでは、従量課金でもすべての機能を使えると説明しています。

費用が膨らむのは、処理し直しです。区切りの大きさを変えた、読み取りの方式を変えた、接続の設定を直した、というたびに対象の文書を全件流し直すと、そのたびにページ数が積み上がります。最初の30日の試しを、少ない文書で回すのは、精度の確認のためだけでなく、設定が固まる前の処理し直しの費用を抑えるためでもあります。

OSS版は利用料がかからない代わりに、サーバーの費用と、保守を担う人の時間がかかります。比べるときは、1か月に処理するページ数、処理し直しの頻度、保守に割ける人の時間の三つを並べ、商用基盤の料金と、OSS版のサーバー費と人件費を同じ表で比べます。読み取りの精度の差で人が書き起こす量が変わるなら、その手間も費用に入れます。

やめ方と乗り換え：元の文書と設定の記録を手元に残す

前処理の道具は、乗り換えやすい部類に入ります。変換の結果は、部品ごとの文字と付帯情報を並べたJSONの形で出力され、検索の保存先は自社で選んだものを使えるからです。やめるときに失うのは、主に変換の仕組みそのものと、処理の流れの設定です。

乗り換えを楽にするために、三つのものを手元に残しておきます。一つめは元の文書で、前処理の結果だけを残して元の文書を消すと、別の道具で処理し直せなくなります。二つめは設定の記録で、区切りの大きさ、読み取りの方式、対象の置き場、除外した文書の条件を文書にしておきます。三つめは、定着の手順で作った失敗の一覧と確かめ方です。道具ではなく、確かめ方を資産として持つことが、ロックインを避ける最も確かな方法です。

商用基盤をやめる場合は、接続のために登録したアプリの鍵を無効にし、提供元の側に処理の記録や一時的な保存が残っていないかを確かめ、削除の確認を文書で受け取ります。鍵の無効化を忘れると、使っていない仕組みが社内の文書への強い権限を持ち続けることになります。

導入前のチェックリスト

最後に、社内に入れる前に確かめる項目をまとめます。すべてに答えが出てから、対象の業務を一つ選んで試すのが安全です。

• 対象の文書を重さで分け、社外に出してよい文書・専用の環境なら出してよい文書・前処理の対象から外す文書を決めた
• OSS版か商用基盤か、商用基盤ならどの置き方かを、文書の重さと保守の人手から決めた
• 画像を外部のAIに読ませる設定を使うか、使うならどの会社のモデルに送られるかを確かめた
• 「データを保持しない」の範囲、保存先の国、学習への利用の有無を、契約書と安全面の資料で確かめた
• 日本語の典型的な文書20〜30件で、表と図と数値の読み取りを人が確かめた
• 部品ごとに元の文書のページと位置が残ることを確かめた
• 権限の情報は絞り込みの目安にとどめ、回答の直前に元の置き場で権限を確かめる設計にした
• 接続の鍵の権限を最小にし、読み込みと書き出しで鍵を分け、有効期限と交換の担当を決めた
• 文書の改訂・削除・権限の変更が検索に反映されるかを試し、反映されない操作を手順で補った
• 設定の記録と元の文書を残し、やめるときの鍵の無効化と削除の確認の手順を決めた

このチェックリストのうち、AIや変換の仕組みに判断させてよい項目は一つもありません。前処理の道具は文書を整える作業を速くしますが、何を読ませ、誰に見せ、どこまで信じるかは人が決めるという線を、導入の最初に関係者で共有しておきます。

まとめ

Unstructured は、社内文書をAIが読める部品に整える前処理の道具で、無料のOSS版と、変換の窓口・処理の流れを提供する商用基盤があります。二つは同じものの無料版と有料版ではなく、変換の仕組みも、動かす場所も、面倒を見る人も違います。選ぶときは、精度の比較だけでなく、文書が社外に出るか、画像を外部のAIに読ませるか、日本語の文書で表と図が崩れないか、権限の情報をどう扱うかを確かめてください。とくに権限の情報は取り込んだ時点の写しにすぎず、回答のたびに元の置き場で確かめる設計が欠かせません。小さな業務から30日で試し、失敗の一覧と確かめ方を資産として残すことが、2026年の前処理を長く安全に回すための土台になります。

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