社内文書をAIに探させたい、という要望はよくあります。このとき「最上位のモデルでなければ話にならない」と考えがちですが、2026年7月16日公開の研究は、17億パラメータの小さなモデルをスマートフォン上で動かし、最大18倍の規模のモデルと競合したと報告しました。ただし条件があります。モデルを小さくできた分、事前の下ごしらえが増えています。
何が測られたのか
「SmartRAG」という仕組みを提案した論文です（出典：arXiv:2607.14661、2026年7月16日、https://arxiv.org/abs/2607.14661v1）。
前提として RAG（Retrieval-Augmented Generation）とは、社内文書などをAIに参照させてから答えさせる仕組みです。AIに社内のことを覚えさせるのではなく、質問のたびに関係しそうな文書を探して渡す方式で、社内文書検索の標準的な作り方になっています。
この研究が扱ったのは、それを手元の端末だけで完結させることです。論文は目的をこう書いています。個人向けの助手としてAIを端末に載せるには、プライバシー・低遅延・オフライン利用が求められる。しかし大きなモデルの計算コストは、端末の性能とぶつかる、と。
提案されている仕組みは、知覚・記憶・注目・思考の4つの部品で構成されます。中核は2つです。
- EvoNER — 文章から人名・組織名・製品名などの固有名詞を学習しながら抜き出す仕組み
- MRGraph — 抜き出した情報を格納する3層の知識グラフ
つまり、文書をただ丸ごと検索するのではなく、あらかじめ中身を構造化して整理しておくという方針です。
| 項目 | 内容 |
|---|---|
| 中核モデル | 17億パラメータ（量子化済み） |
| 比較対象 | 最大 18倍 の規模のモデルと競合 |
| 評価データ | TriviaQA／Natural Questions／HotpotQA／MultiHopQA の4種類 |
| 動作環境 | 市販のスマートフォン |
論文は、複数の情報をたどって答えを出す多段の推論を、市販のスマートフォン上で実用的な制約の中で実現したとしています。
正答率と、見落とせない「遅さ」
本文には、データセットごとの正答率が出ています。
| データセット | Qwen3-1.7B での正答率 | Ministral3-3B での正答率 |
|---|---|---|
| TriviaQA | 50.00 | 59.74 |
| Natural Questions | 66.68 | 63.86 |
| HotpotQA | 63.93 | 66.74 |
| MultiHopQA | 50.17 | 57.60 |
5〜6割台です。「18倍の規模と競合」は事実ですが、絶対値としては、そのまま業務判断に使える水準ではありません。人間が確認する前提の道具として見る必要があります。
そして、記事の見出しでは伝わりにくい、実務上いちばん重要な数字がこれです。
| 指標 | 実測値 |
|---|---|
| 使用メモリ（1.7B構成） | 4,149.72 MB |
| 使用メモリ（4B構成） | 6,803.68 MB |
| 最初の応答までの時間（中央値） | 36.9秒 |
| 生成にかかる時間（中央値） | 8.55秒 |
質問してから最初の反応まで、中央値で36.9秒かかります。社内文書検索としては、率直に言って遅すぎます。論文自身も、遅さの主因が検索を踏まえた前処理にあると限界として認めています。
「スマートフォンで動く」は事実ですが、「業務で使える速さで動く」とは書かれていません。ここを混同すると、導入してから「使われないシステム」になります。
論文が挙げているその他の限界も率直です。
- 計画を立てる部分が、まだ経験則ベース
- AI・政治といった分野で、固有名詞の抽出精度が低い
- 評価は英語のベンチマークに限定されている（日本語での性能は未検証）
最後の点は、日本の中小企業にとって決定的です。この数字がそのまま日本語の社内文書に当てはまる保証はありません。
数字の読み方 — 「小さくて済む」ではない
18分の1の規模で戦えるという結果は魅力的ですが、読み違えると失敗します。
- モデルが小さくなった分、仕組みが増えている。 固有名詞の抽出器と3層の知識グラフを、事前に作って維持する必要があります
- この構造化は自動では終わらない。 どの語を固有名詞として扱うか、どう関連付けるかは、対象文書の性質に依存します
- 評価データは一般的なQAデータセット。 自社の社内文書で同じ成績が出る保証はありません
つまりこれは「安く済む」話ではなく、コストの置き場所が変わる話です。大きなモデルを使う費用を、事前の整備の手間に付け替えている、と読むのが正確です。
中小企業にとって何を意味するか
それでも、この方向性は中小企業に向いています。理由は費用ではなく条件です。
- 社外に出せない文書がある — 見積書、図面、人事関係、顧客との契約。これらをクラウドに投げられない会社は多い
- 社内文書は量が限られている — 世界中の知識に答える必要はなく、自社の数千件に正確に答えられればよい。この用途なら巨大なモデルは要りません
- オフラインで動く — 現場や工場など、通信が不安定な場所でも使えます
とくに2つ目が本質です。社内文書検索は「広く浅く」ではなく「狭く正確に」の仕事です。求められる性質が違うので、汎用の最上位モデルが最適とは限りません。
導入前に確認すること
- 文書が整理されているか。 同じ内容の版が何個もある、最新版がどれか分からない状態では、AIを入れても間違いを高速に返すだけです
- 誰がその整備を続けるのか。 知識グラフのような構造は、作った後に維持が要ります
- 答えの根拠を示せるか。 どの文書のどこを見て答えたかが出ないなら、業務では使えません
3つ目は必須です。根拠が出ない社内検索は、確認のために結局人が全文を読むことになり、時間が減りません。
TOEではどうか
SmartRAG の検証は、TOEでは実施していません。社内文書検索の仕組みを自社向けに構築してもいません。
ローカルでAIを動かすこと全般についてはローカルLLMという選択肢に、GPUなしでの実行可能性については高価なGPUなしでAIは動くかに整理しています。
一点だけ実感として言えるのは、文書が整理されていない状態でAIを入れると、たいてい失敗するということです。これはAIの性能の問題ではありません。人間が探せない資料は、AIにも探せません。
まとめ
- 17億パラメータのモデルをスマートフォン上で動かし、最大 18倍の規模のモデルと競合したという報告（arXiv:2607.14661、2026年7月16日）
- 手法は、固有名詞の抽出器（EvoNER）と3層の知識グラフ（MRGraph）で、文書を事前に構造化しておくこと
- モデルが小さくなった分、事前整備の手間が増えている。費用が消えたのではなく、置き場所が変わっただけ
- 正答率は 5〜6割台。人間が確認する前提の道具であり、そのまま判断には使えない
- 最初の応答まで中央値36.9秒。「動く」ことと「業務で使える速さで動く」ことは別
- 評価は英語のベンチマークのみ。日本語の社内文書で同じ性能が出る保証はない
- 社内文書検索は「広く浅く」ではなく 「狭く正確に」 の仕事なので、巨大なモデルが最適とは限らない
- TOEでは同検証も社内文書検索の構築も未実施
社内文書のAI活用でいちばん効くのは、モデル選びではありません。その前に、文書を人間が探せる状態にすることです。