Box AIの制限はなぜ必要か？RAGとLLMで理解する生成AIの仕組みと設計

AI機能を説明するとき、仕様上の上限だけを見ると、「それでは実務で使えないのではないか」と受け取られやすいのではないでしょうか。とりわけ生成AIはどこまで処理できるかに関心が集まりやすく、制限が弱点と捉えられやすい領域でもあります。

しかし、企業内文書を扱う生成AIにおいて重要なのは、全文・全件を無制限に扱えることではありません。むしろ、膨大な情報の中からどの範囲を対象とし、どの情報を取り出して回答生成に利用するかが精度と実用性を左右します。

こうした観点は、実際のサービス仕様にどのように現れているのでしょうか。本記事では、具体例として企業内文書の活用を前提に設計されたBox AIを取り上げ、その公開仕様から読み解いていきます。まず生成AIの基本構造を整理したうえで、制限の有無そのものではなく、なぜ対象範囲や対象単位の設計が必要になるのかを踏まえながら、Box AIの仕様をどう理解すべきかを考えます。

生成AIの基本構造

企業内文書を生成AIで扱う場合には、LLM（Large Language Model：大規模言語モデル）単体の性質だけでなく、外部データをどのように参照し、回答生成に利用するかという構造を理解する必要があります。ここでは、まずLLMと外部データ参照の基本を整理し、そのうえで一般にRAG（Retrieval-Augmented Generation：検索拡張生成）と呼ばれる構造を見ていきます。これにより、なぜ対象範囲や入力内容の設計が重要になるのかを理解しやすくなります。

LLMと外部データ参照の基本

LLMは、文章生成、要約、言い換え、文案作成などに強みを持ちます。一方で、企業内の個別文書や最新の業務資料そのものを、最初から内部に保持しているわけではありません。

そのため、外部文書を使って回答させるには、それらを別途参照させる仕組みが必要です。さらに、LLMには一度に扱える入力情報量にも制約があります。このため、外部文書を扱う場合には、単に文書をそのまま渡すのではなく、何を参照し、どの情報を入力に使うかを整理する構造が重要です。

RAGの基本プロセス

企業内の文書やコンテンツを生成AIで扱う場合、対象となるデータを検索し、その結果をLLMの入力として利用する構成が一般的に用いられます。この仕組みはRAGと呼ばれています。

RAGでは、対象となるコンテンツをあらかじめ分割し、それぞれを検索可能な形に変換して保持します。ユーザーから質問が入力されると、その質問に近い内容を検索し、取得した結果をLLMの入力（コンテキスト）として渡します。LLMは、その検索結果を踏まえて回答や要約を生成します。一般的な処理フローの一例は、次のように整理できます。

データ準備

• ①テキストの分割（chunking）
• ②各チャンクのベクトル化（embedding）
• ③検索用インデックスへの格納（indexing）

検索

• ④ユーザーの質問のベクトル化（query embedding）
• ⑤類似度検索による関連箇所の取得（retrieval）
• ⑥関連性の高い結果の絞り込み（ranking）

生成

• ⑦検索結果を含めたプロンプトの構成（prompt construction）
• ⑧LLMによる回答・要約の生成（generation）

この流れから分かるのは、RAGにおいてLLMが見ているのは知識ベース全体ではなく、検索によって絞り込まれた一部の情報だという点です。

LLMの入力制約（コンテキストウィンドウ）

LLMには、一度のリクエストで処理できる入力トークン量に上限があります。この制約により、外部データを扱うシステムでは、入力データの扱い方に設計上の制約が生じます。具体的には、次のような点が検討対象になります。

• 長文や大容量ドキュメントを、そのまま一括で入力できるとは限らない
• 複数ドキュメントを同時に扱う場合、どの情報を優先して入力するかの設計が必要になる
• 入力量が増えるほど、処理時間や計算コストへの影響が大きくなる

そのため、外部データを扱う生成AIシステムでは、処理対象の範囲や単位をどのように設計するかが重要になります。

複数ドキュメント参照と情報選別の設計

複数の文書を同時にAIに渡す場合、参照できる情報量は増えますが、入力内容の選択や整理を適切に行わないと、次のような課題が生じる可能性があります。

• 質問に直接関係のない情報が含まれると、回答の精度が低下する可能性がある
• 大量のテキストの中で、関連する情報が埋もれてしまう場合がある
• 矛盾する情報が含まれると、回答の一貫性が低下する可能性がある

多くのRAG系システムでは、「すべての情報をそのまま渡す」のではなく、検索結果から関連性の高い情報を絞り込んでLLMに渡すという設計が採用されています。これは、限られたコンテキスト内で関連情報を優先し、回答の精度と安定性を保つためです。そのため、検索で取得した候補に対しては、生成に使う情報を選別・整理する処理が前提となります。

インデックス化による検索処理の最適化

大量の文書を検索対象として扱う場合、すべての文書をそのまま毎回処理するのは非効率になりやすいです。そのため、複数文書を検索対象として継続的に扱う構成では、あらかじめ検索用のインデックスを作成し、必要な情報を効率的に取得できるようにする設計が一般的です。

インデックスを利用することで、次のような効果が期待できます。

• 処理対象データの効率的な絞り込み
• 関連情報の検索・抽出の高速化
• レスポンス時間の短縮
• 不要な計算処理の削減

このような「インデックス＋検索＋生成」の構造は、複数文書を対象とする生成AIシステムで広く見られる設計パターンです。

なぜ検索結果の絞り込みが必要になるのか

生成AIは、検索によって関連情報を広く取得できることが強みです。しかし、取得した情報をそのまま無制限に回答生成へ使えるわけではありません。ここでは、AI検索が従来型検索よりも広く関連情報を取得しやすい理由を確認したうえで、なぜ生成段階では検索結果の絞り込みが必要になるのかを整理します。

AI検索は、従来型検索よりも広く深く関連情報を取得しやすい

AIを用いた検索は、従来型のキーワード検索よりも、意味や文脈を踏まえて関連情報を取得しやすいという特徴があります。従来の検索では、語句の一致を中心に情報を探すため、同じ意味でも別の表現が使われている場合や、質問文そのものが文書中に現れない場合には、拾いにくいことがあります。

一方、AIを用いた検索では、単語そのものの一致だけでなく、意味の近さや文脈の近さを踏まえて候補を取得しやすくなります。そのため、同じ単語が書かれていなくても意味的に近い内容を拾いやすく、複数文書をまたいで関係箇所を見つけやすいという強みがあります。

取得した情報を、そのまま全部使うわけではない

検索段階で広く候補を取得できることと、その候補をそのまま無制限に回答生成へ使えることは別です。生成段階では、検索によって取得した候補の中から、質問に対して必要な情報を絞り込んで使う必要があります。その理由は、LLMに一度に与えられる情報量に制約があることに加え、関係の薄い情報まで大量に渡すと、必要な情報が埋もれたり、回答が不安定になったりする可能性があるためです。

つまり、生成AIでは、検索段階では広く候補を探し、生成段階ではその中から必要な情報を選んで使うという整理が必要になります。AI検索によって多くの関連候補を見つけられたとしても、それらをそのまま全部回答生成に使うことはできません。この意味で、検索結果の絞り込みは、生成AIにおける回答生成の前提として重要になります。

こうした「どの範囲を対象とし、どの単位で情報を扱うか」という考え方は、実際のサービス仕様にどのように反映されているのでしょうか。

Box AIの公開仕様に見る対象単位の違い

ここからは、Box AIの公開仕様をもとに、AIがどの単位を対象として利用されるのかを見ていきます。

取り上げるのは、Documents / Notes / Hubsという3つのコンテンツ単位です。これらはBox AIの機能を網羅的に紹介するためではなく、単一ファイル、編集中のノート、複数文書の集合という対象単位の違いを具体例として見るために扱います。あわせて、それぞれの単位でAIが何を参照し、その際にどのような制限が設けられているのかも整理します。公開仕様に記載されている上限や対象範囲も、こうした対象単位の違いに沿って設計されています。

Documentsにおける参照範囲

Documentsでは、単一ファイルを基本単位としてAIを利用します。対象となるのはファイル内のテキストであり、処理対象は先頭2MBまでです。Enterprise Plus以上では、最大10ファイルを対象に質問することもできます。つまり、単一ファイル、または限定的な複数ファイルを対象として利用する設計です。

Notesにおける編集コンテキスト

Notesでは、Noteに含まれる全内容を対象としてAIを利用します。つまり、ここで対象となるのは単一文書の一部ではなく、編集中のNote全体です。このため、編集中の内容全体をコンテキストとして扱う設計です。なお、既知の制限事項として、質問は300文字以内、コンテンツのリファインは10,000文字までとされています。

Hubsにおける集合単位

Hubsでは、Hubに含まれる複数のファイルを対象としてAIを利用します。つまり、単一ファイルや編集中のノートではなく、文書群そのものを対象とする点が、DocumentsやNotesと異なります。この単位でAIを利用するため、Hubsでは追加したファイルをインデックス化し、その内容をもとに関連情報を検索します。

Hubあたりのファイル数の上限は20,000、組織内のすべてのHubにおけるファイル数の上限は1,000万です。さらに、各ファイルについてAIが参照するテキストは1ファイルあたり最大4MBです。

このように、Hubsは複数文書の集合を前提とした設計であり、インデックス化や上限もその前提に沿って定められています。

Box AIをどう使い分けるか

ここまで見てきたように、Box AIではDocuments / Notes / HubsでAIが対象とする単位が異なります。そのため、重要なのは制限の有無だけを見ることではなく、何をしたいのかに応じて、どの単位でAIを使うかを選ぶことです。

単一文書を深く確認したい場合

契約書、仕様書、会議資料など、対象となるファイルが明確な場合は、Documentsでの利用が向いています。単一ファイルを基本単位として扱うため、対象を絞った確認や要約に適しています。

作成中の内容を整理したい場合

議事録の整形、メモの整理、文章の見直しなど、編集中の内容を前提にAIを使いたい場合は、Notesでの利用が向いています。Note全体がコンテキストになるため、作成中の流れを踏まえて内容を整えやすくなります。

複数文書を横断して探したい場合

プロジェクト資料や部門ナレッジのように、複数ファイルをまとめて対象にしたい場合は、Hubsでの利用が向いています。文書群を前提に検索・参照する構造であるため、単一ファイルではなく、集合として情報を扱いたい場面に適しています。

このように、Box AIは一律に使うものではなく、利用目的に応じて対象単位を選ぶことで、各機能の特性を活かすことができます。

さいごに

AI機能に上限や制限があると、それだけで「不十分」「使えない」と感じやすいのは自然です。しかし、LLMとRAGの基本構造を踏まえると、そうした制限は単なる欠点としてではなく、生成AIの仕組みに沿った設計として捉えやすくなります。

生成AIは、全文・全件をそのまま無制限に扱う仕組みではありません。検索段階では従来型検索よりも広く関連情報を取得しやすい一方で、生成段階では必要な情報を選んで回答を生成します。そのため、対象範囲や上限があること自体は、生成AIの仕組みと矛盾するものではありません。

制限の有無だけを見るのではなく、何を対象にどの単位でAIを使いたいのかを起点に考えることで、仕様の見え方も変わります。Box AIの各機能も、「使えない理由」ではなく、どの単位を前提に利用する設計なのかを示すものとして理解しやすくなります。

プロフィール