5月・6月アップデートの概要

RAG（Retrieval-Augmented Generation）は、社内文書をAIが検索・参照しながら回答を生成する仕組みです。回答の質は、LLMの性能だけでなく、文書をどう読み取り、どう分割し、どう検索するかという前段処理の精度に大きく左右されます。
DirectCloud AIは2026年5月・6月にかけて、このRAGパイプラインの前段3工程を刷新しました。改善の対象は、文書を読み取るパーサー、検索結果を絞り込むReranker、文書を分割するチャンカーという3つの工程です。

5月アップデートの改善内容

5月のアップデートでは、検索精度を底上げするRerankerを導入しました。採用したのは生成AI基盤上で提供されるCohere Rerank 3.5です。
ベクトル検索で取得した候補30件の中から、Rerankerが質問との関連度を再評価して、最終的な参照文書を選別します。この2段階構造により、意味的には近いが質問の答えを含まない文書が上位に残る問題を解消しています。

6月アップデートの改善内容

6月のアップデートでは、以下の3点を実施しました。

1つ目は、PDFパーサーのVLM転換です。表・数式・複合レイアウトが混在するPDF文書を、VLM（Visual Language Model）で直接解析する方式へ切り替えました。

2つ目は、チャンキング基準のトークン数への移行です。文字数基準で分割していた処理をトークン数基準に変更し、エンベディングモデルの入力上限超過を防止しました。

3つ目は、多言語エンコーディング検出と多段階fallbackチェーンの導入です。文字コードの違いによる文字化けと収集失敗を防ぐ仕組みを整備しました。

これら3工程の改善が組み合わさることで、性質の異なる6種類の文書に対して220問の質問を用いた社内評価において、正答率が68%から79.1%へ改善しました。次章以降では、各改善の詳細を順に説明します。

ベクトル検索では届かない精度の壁を、2段階検索で回答を絞り込むRerankerが補完

ベクトル検索で候補を30件取得した後、Rerankerが質問との関連度で最終選別を行う2段階構造を採用しました。外部SaaSから生成AI基盤への移行によって、精度向上とデータセキュリティを同時に実現しています。

類似度評価と回答適合性は異なる指標である

RAGの検索は、質問文をベクトル化し、意味的に近いチャンクを取得する仕組みです。ただし「意味的な近さ」を基準にしているため、検索スコアが高い文書が質問の答えを含むとは限りません。
この問題を解決するのが2段階目のRerankerです。1段階目で取得した30件の候補を、類似度スコアではなく、「この文書は質問の答えとして適切か」という観点で再評価します。質問との内容的な適合度による判定をすることで、正しい答えを含む文書を上位に並べ直します。

生成AI基盤への移行でセキュリティと処理能力を同時に確保

DirectCloud AIは、より高いセキュリティ基準を満たすため、Rerankerの処理基盤を外部SaaS型から、生成AI基盤での実装へ移行しました。移行の背景には2つの判断がありました。

1つ目は、データ管理の厳格化です。社内文書を扱う企業のセキュリティ要件に応えるため、検索クエリや参照文書の処理を国内のインフラ内に限定する構成へ切り替えました。

2つ目は、処理の安定性の向上です。外部SaaSのレート制限に依存した構成では、アクセスが集中した際に応答が遅延する場合がありました。自社インフラ内での処理に切り替えることで、安定した応答速度を確保しています。

これらの改善を実現するため、生成AI基盤上で提供されているReranker（Cohere Rerank 3.5）へ移行しました。処理はすべて国内のインフラ内で完結しており、社内文書のデータが国外に転送されない設計です。

安全性を支える仕組みは以下の3点です。

処理能力についても、実測で毎分380件の安定稼働を確認しており、現在の運用量と比較して約127倍の余裕を持った状態で稼働しています。

Reranker導入で無関係文書への依存から脱却し、回答の質を高める

Reranker導入前後の変化を、実際の検索ケースで示します。

導入前の環境で、「契約期間満了後も秘密保持義務は継続しますか」という質問をした場合、ストレージ内に保存された「事業報告書のチャンク」が上位を占拠し、AIが「関連する内容が見つかりませんでした」と返答するケースが発生していました。
Reranker導入後は、Rerankerが「秘密保持契約書のチャンク」を上位に選別し、AIは該当条項を参照したうえで、「第4条および第6条の規定により、契約期間満了後も秘密保持義務は継続します」などの根拠を明示した回答を生成できるようになりました。
この改善の効果を数値で示します。Rerankerの性能評価に用いたPairwise Win Rateは、ベースライン（ベクトル検索のみ）の31.7%から約55%へ改善しました。Pairwise Win Rateとは、2つの検索結果を比較してどちらが質問により適切かを判定し、その勝率を示す評価指標です。

なお、正答率68%から79.1%への改善と誤答49%削減は、Reranker単体ではなくVLMパーサー転換との同時実装による総合実測値です。詳細は6章で説明します。

PDFの表・数式が正しく読み取れない問題を解決するVLMパーサーへの転換

企業文書に多い表・数式・複合レイアウトのPDFは、従来のパーサーでは構造が崩れたままインデックスに格納されていました。VLMパーサーへの転換によって何が変わるかを、課題・改善・効果の順に説明します。

メモリ不足と文字崩壊、旧世代のアーキテクチャが招いたAI回答の空白地帯

従来のDirectCloud AIは、「YOLOX」「table-transformer」「Tesseract OCR」という3つのモデルを順次実行する方式でPDF文書を解析していました。しかしこの構造には3つの問題がありました。

1つ目は、Out Of Memory（メモリ不足）の反復発生です。3つのモデルを順番にメモリへ読み込む処理は、大容量ファイルや同時リクエストが重なった際にメモリ使用量が急増し、サーバーがダウンするケースが繰り返し発生していました。

2つ目は、文字の誤認識です。Tesseract OCRは英語を前提とした「単語の区切り方」を日本語・韓国語にそのまま適用するため、「バナナ」が「バ」「ナ」「ナ」と1文字ずつ分離されるといった誤認識が発生していました。そのため、表のヘッダー行も同様に崩れ、セルと値の対応関係が失われていました。

3つ目は、技術世代の遅れです。このアーキテクチャは旧世代の方式であり、2026年時点の業界標準はEnd-to-End方式のVLMへの移行が完了しています。旧世代の方式では、表・マトリクス・数式が混在する複合レイアウトのページを正確に処理することに本質的な限界がありました。

これら3点が重なることで、仕様表・検査基準値・数式を含む質問に対し、AIが「関連する内容が見つかりませんでした」としか返せない状態が生じていました。

VLMパーサー転換がもたらす表構造の正確な抽出と回答精度の改善

この問題を解決するため、PDFパーサーをEnd-to-End方式のVLM（GPT-5.4）へ転換しました。

従来の方式がOCRでテキストを文字単位に抽出していたのに対し、VLMはページ全体の画像をそのまま入力として受け取り、レイアウトを視覚的に解析します。表・数式・図版が混在した複合ページでも、行・列の対応関係を維持したまま、検索システムが読み取れるMarkdown table形式（構造化されたテキスト形式）で出力できます。
この結果、「型番Aの定格電流の許容範囲は」「仕様表の〇〇の数値を教えてください」といった、参照元が表ベースの質問に対して、AIが該当するセルの値を正確に参照した回答を生成できるようになりました。

複雑な文書・難しい質問ほど効果が大きいことを示す、回答精度向上の実測値

VLMパーサーへの転換効果を、文書タイプ別の正解率で示します。いずれもDirectCloud社内での実測値です。

表・マトリクス・脚注が密集した製品カタログでは、正解率が29%から59%へ改善しました。改善幅は+30ポイントで、今回の検証で最も大きな向上を示したドメインです。

数式・LaTeXインラインが含まれる技術論文では、正解率が72%から95%へ改善しました。改善幅は+23ポイントです。

多行表・子会社一覧が含まれる事業報告書では、68%から82%へ改善しました。改善幅は+14ポイントです。

テキスト中心のNDA契約書では、83%から93%へ改善しました。改善幅は+10ポイントです。

この結果が示すのは、表・数式・複合レイアウトを多く含む文書ほど改善幅が大きいという傾向です。テキスト中心の文書では改善幅が小さく、複雑な構成の文書ほど効果が顕著に現れています。文書の認識精度を底上げすることで、後段の検索・回答生成ステップ全体の精度向上にも波及しています。

VLMパーサー転換が効果を発揮する活用シーン

VLMパーサーの転換は、表・図解・複合レイアウトを多く含む業種・業務で特に高い効果を発揮します。

製造業での品質・設計文書活用

導入前は、仕様表・検査基準値が含まれるPDF文書は表構造が崩れてインデックスに格納されていました。仕様確認の質問にAIが回答できず、担当者がPDFを目視確認するフローが残っていました。日韓の両言語混在の仕様書では文字化けにより取り込み自体が失敗するケースもありました。

導入後は、VLMパーサー転換と5章で解説するエンコーディング処理の多段階化が組み合わさることで、表構造を維持したまま情報を抽出できるようになりました。仕様確認の質問にAIが該当行を参照して正確な数値を回答でき、海外拠点に保存された日韓混在の文書も文字化けなく検索対象に加わります。

医療・介護業での業務手順研修補助

導入前は、業務手順書が写真・図解・テキストの混在した構成のため、図解が必要な質問にAIが回答できず、新人スタッフが手順書を目視で確認するフローが残っていました。指導者不在の時間帯では対応が遅れるケースもありました。

導入後は、手順書の写真・図解もRAGインデックスに統合され、AIが図の内容を踏まえた手順説明を返せるようになります。都度の目視確認にかかる時間が削減され、指導者不在の場面でも自己解決できる環境が整います。

チャンキングをトークン数基準へ移行し、共通基盤の標準化で収集安定性を向上

文書をRAGで活用するには、適切なサイズに分割するチャンキングの精度が重要です。分割方法が不適切だと、意味のある情報が途中で切れたり、エンベディングモデルの処理限界を超えたりする問題が生じます。この章では、チャンキング基準の刷新によって何が変わるかを説明します。

文字数基準の一律チャンク化が招いた構造情報と文脈の欠落

従来のチャンキングは文字数を基準としており、2つの問題がありました。

1つ目は、処理上限の超過です。日本語・韓国語は1文字が複数の処理単位（トークン）に相当するため、文字数基準で区切ったチャンクがAIモデルの処理上限を超えるケースがありました。上限を超えた部分は欠落し、その情報は検索対象から外れます。

2つ目は、構造情報と文脈の欠落です。文書の種類に関係なく同一の方式でチャンク化していたため、見出し・表・リストなどの構造情報が失われていました。日本語・韓国語の長文段落では文脈の途中で分割されるケースも多く、意味のまとまりが維持されないまま格納されていました。

チャンキング基準を文字数からトークン数へ変え、エンベディングモデルに最適化した分割へ移行

チャンキングの基準を文字数からトークン数へ移行しました。これにより、AIモデルの処理上限をチャンク生成の段階で管理できるようになり、処理の欠落が発生しなくなります。

PDFのチャンク化では、ページ位置・トークン数・言語・ハッシュをチャンクの付属情報として記録する形に標準化しました。検索時にページ単位での参照が可能になり、回答の根拠箇所を特定しやすくなります。

日本語・韓国語の長文段落については、意味のまとまりを維持したまま分割できるよう、言語に応じた「区切りルール」を組み込みました。

フォーマット別の最適処理で多様な文書を安定収集し、RAGの精度と信頼性を底上げ

トークン数基準への移行と日本語・韓国語対応により、長文文書でのチャンク欠落が減少し、RAGの回答精度と収集安定性の向上につながります。

チャンキングの方針・前処理・付属情報を共通標準化したことで、2026年2月から4月に導入済みの各パーサーにも横断的に改善が適用されます。将来的な新規フォーマットの追加も、この共通基盤に則って実装できるため、保守性が高まります。

次章では、文書を取り込む段階で発生する文字化けと、収集失敗への対処について説明します。

文字コードの違いによる文字化けと収集漏れを防ぐ、多言語エンコーディング検出と多段階fallbackチェーン

文書をRAGで活用するには、ファイルを正しく読み込めることが前提です。文字コードの処理が不十分だと、文書を取り込む段階で文字化けや収集失敗が発生し、検索対象から文書が欠落します。この章では、多言語エンコーディング検出と多段階fallbackチェーンの導入によって何が変わるかを説明します。

多言語エンコーディングの処理不足が招くサイレント破損と収集失敗

企業の社内文書には、作成環境や作成時期の違いによってさまざまな文字コードが混在しています。代表的なものは以下のとおりです。

• ●各言語共通：UTF-8・UTF-16（BOMの有無による違いを含む）
• ●日本語環境：Shift-JIS・ISO-2022-JP
• ●韓国語環境：EUC-KR・CP949

従来のDirectCloud AIは、これらの文字コードを適切に処理できない場合がありました。特に深刻だったのは、エラーとして検知されずに処理が進む「サイレント破損」の発生です。文字化けしたまま収集された文書は、検索インデックスに格納されても正しく機能せず、担当者がファイルをアップロードしたにもかかわらずAIが「関連する内容が見つかりませんでした」と返答する原因の一つとなっていました。

日本語・韓国語が混在する海外拠点を持つ企業では、この問題がより頻繁に発生していました。

エンコーディング自動検出と多段階fallbackチェーンによる収集の安定化

この問題に対し、エンコーディングの自動検出と多段階fallback（検出失敗時の代替処理）の仕組みを構成しました。

処理は以下の順で動作します。

日韓同時運用でも文字化けしない収集を実現し、取りこぼし減少が検索品質を支える

この改善により、日本語・韓国語が混在する環境での収集失敗と、サイレント破損が減少します。
たとえば日本の本社と韓国の製造拠点が共同で社内文書を管理する運用環境では、言語環境の違いを意識せずに文書を収集・検索できる状態が整います。収集の取りこぼしが減ることで検索インデックスの網羅性が高まり、RAG全体の回答品質の安定につながります。

積み重なるRAG施策の効果と、データを国内で完結させる安全設計

2章から5章で説明した複数の改善施策は、それぞれが独立した効果を持ちながら、組み合わさることでRAGパイプライン全工程の精度を底上げします。この章では、改善前後の数値による効果の可視化と、データが国外に出ない閉域設計の仕組みを合わせて示します。

改善前後の数値で見るRAG全体の精度変化

DirectCloud社内での評価概要は以下となっています。

• ●評価規模：性質の異なる6種類の文書 × 220問
• ●評価指標：正答率・完全正解件数・誤答件数・検索成功率の4つ

結果は以下のとおりです。

この数値はReranker導入とVLMパーサー転換の同時実装による総合的な実測値です。個々の施策が互いを補完することで、単独では得られない複合的な効果が現れています。

なお、現在も改善は継続しており、2026年6月末時点でRAG評価スコアが社内基準の300点を超える見込みです。

データが国外に出ない閉域処理の仕組み

今回の改善施策はすべて、データが国外に転送されない閉域設計のもとで実装されています。
Rerankerの処理はAWS東京リージョン内のみで実行されます。検索クエリや参照文書の内容が国外のサーバーへ送信されることはありません。この設計を支える仕組みは以下の3点です。

• ●アクセス権限の管理（IAM）：処理を呼び出せるリソースを国内インフラに限定
• ●専用ネットワークの分離（VPC）：処理環境をインターネットから切り離し
• ●プライベート接続経路（PrivateLink）：インターネットを経由しないアクセス経路を確保

顧客情報・技術仕様・契約内容など機密性の高い社内文書を安心してRAGで活用できるよう、データセキュリティを具体的な仕組みで担保しています。

(※) 本表は2026年6月時点の各社公式サイト掲載情報に基づきます。料金・仕様は変更される場合があります。最新情報は各社公式サイトでご確認ください。

まとめ

DirectCloud AIは2026年5月・6月にかけて、RAGパイプラインの前段3工程を刷新しました。
VLMパーサーへの転換により、表・数式が混在する複雑なPDF文書でも構造を維持した情報抽出が可能となり、仕様表や数値表に関する質問への回答精度が大幅に向上しました。製品カタログのような表密集型の文書では正解率が29%から59%へ改善しており、複雑な文書ほど効果が顕著に現れています。
RerankerとVLMパーサー転換の同時実装により、正答率が68%から79.1%へ改善し、的外れな回答を49%削減(※)しました。

（※）本数値はDirectCloud社内での実測値

また、チャンキングのトークン数基準への移行と多言語エンコーディング対応により、日本語・韓国語を含む長文文書での情報欠落と文字化けを防ぎ、収集の安定性が向上しました。
今回の改善施策はすべて国内インフラで完結しており、社内文書データが国外に転送されない閉域設計のもと、精度向上とデータセキュリティの確保を同時に実現しています。

DirectCloud AIは、精度・安全・信頼性の3軸で継続的な改善を重ね、企業の社内文書AI活用を支援してまいります。

よくある質問（Q&A）