Ollamaでファイルをアップロード・読み込む方法｜公式アプリとOpen WebUIのRAG設定【2026年10月】

Ollamaにファイルを読み込ませる方法は3つあります。公式アプリへのドラッグ＆ドロップ、CLIやAPIへのテキスト・画像の受け渡し、そしてOpen WebUIでのアップロード（RAG）です。以前は「Ollama単体ではファイルを扱えない」と言われていましたが、2025年7月30日に公開されたmacOS・Windows向けの公式アプリから、PDFやテキストを添付できるようになりました。

ただし、アプリの添付はファイルの全文をそのままプロンプトに入れる方式です。GPUメモリが24GiB未満の環境では既定のコンテキスト長が4kのため、長い文書は前半が切り捨てられます。本記事では、Ollama 0.40.3とOpen WebUI v0.12.0を2026年10月13日に動かして確かめた結果をもとに、形式ごとに読める・読めないの違いと、日本語文書でRAGの精度を上げる設定を手順つきで説明します。

まとめ

• 公式アプリならOllamaだけでファイルを読み込める。PDF・docx・txt・md・csv・コード類など37拡張子と画像4拡張子を、1ファイル10MBまで添付できる。
• アプリの添付は全文をプロンプトへ入れる方式。既定の4kコンテキストでは長文が切り詰められるため、設定の「Context length」を文書の長さに合わせて上げる。
• アプリで読めないファイルがある。docx・Shift_JISのCSV・画像だけのPDFは中身が渡らず、Chromeで印刷したPDFは文字化けした（実測）。
• 文書が多い・長いならOpen WebUIのRAGを使う。チャットに添付するか、ナレッジベースに登録して入力欄の#で呼び出す。v0.12.0はモデルが検索ツールを呼んで文書を読むため、ツール対応モデルを選ぶ。
• 日本語の文書では、埋め込みモデルを既定のall-MiniLM-L6-v2からOllamaのbge-m3に変えると、10問中6問だった正答チャンクの上位3件入りが10問すべて1位になった。変更後はインデックスを作り直す。

ファイルを読み込ませる3つの経路の比較

先に、どの経路を選ぶかを決めます。判断の分かれ目は「文書の長さ」と「同じ文書を何度も使うか」です。1本の短い資料を要約したいだけなら公式アプリで足ります。社内規程のように数十ページの文書を何度も参照するなら、必要な箇所だけを探して渡すOpen WebUIのRAGが向いています。

Linuxのサーバーで動かすOllamaには公式アプリが無いため、ブラウザから使うならOpen WebUIを組み合わせます。ローカルLLMそのものの仕組みや必要スペックはローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説にまとめています。

公式アプリのファイル添付手順と対応形式

Ollamaの公式ブログ「Ollama’s new app」（2025年7月30日）は、新しいアプリがファイルのドラッグ＆ドロップに対応し、テキストやPDFを扱えると説明しています。使い方は、チャット欄にファイルをドラッグするか、入力欄の添付ボタンから選ぶだけです。

添付できる形式と10MBの上限

v0.40.3のアプリのソース（app/ui/app/src/utils/fileValidation.ts）では、受け付ける拡張子と上限が次のように決められています。

xlsxやpptxは受け付けません。画像は、選んだモデルがビジョン（画像入力）に対応しているときだけ送られます。対応していないモデルでは添付欄で赤く表示され、送信時に外されます。

添付ファイルの全文挿入とコンテキスト消費

アプリは添付ファイルをテキストに変換し、--- File: ファイル名 ---と--- End of ファイル名 ---で囲んでメッセージ本文に足します（app/ui/ui.go）。チャンク分割も検索もしません。ファイルが長いほどコンテキストを消費し、上限を超えた分はモデルに届きません。対策は次の章で説明します。

アプリで読めないファイル（実測）

テキストへの変換はapp/ui/extract.goが行います。PDFはgithub.com/ledongthuc/pdfで文字を取り出し、それ以外はUTF-8として読めるかだけを見ています。この関数をv0.40.3のソースから取り出して同じ内容の日本語ファイルを渡すと、結果は次のとおりでした。比較のため、Open WebUI v0.12.0の既定設定で同じファイルをアップロードした結果も並べます。

docxとShift_JISのCSVは、アプリでは[Binary file - 3665 bytes - not valid UTF-8]のような一文に置き換わり、モデルには中身が届きません。docxは添付できる拡張子に入っているのに中身を変換する処理が無く、ZIP形式のためUTF-8の判定で落ちます。ExcelでCSV保存したファイルはShift_JISになることが多いので、UTF-8で保存し直すか、Open WebUIで読み込みます。

PDFは作り方で結果が変わります。LibreOfficeで書き出したPDFは読めましたが、Chromeの印刷で作ったPDFは日本語も英語も意味の無い文字列になりました。Open WebUIは同じPDFを読めたものの、「日」「行」が見た目の同じ康熙部首（U+2F47など）に置き換わりました。添付した資料の要約が支離滅裂なら、まずPDFの作り方を疑い、別のツールでPDFを作り直すかテキストに変換してから渡します。日本語PDFのテキスト化はPyMuPDF4LLMの使い方｜PDFをMarkdownに変換する手順と日本語PDFの注意点【1.28.2】で詳しく扱っています。

長文読み込み時のコンテキスト長設定

アプリの添付やCLIで長い文書を渡すときに一番効く設定がコンテキスト長です。公式ドキュメント「Context length」によると、既定値はGPUメモリ（VRAM）の量で決まります。

4kコンテキストでの文書前半の切り詰め（実測）

GPUの無い環境ではOllamaのログにmsg="vram-based default context" total_vram="0 B" default_num_ctx=4096と出て、4kが選ばれます。この状態で、16条・約1万4千字（12,601トークン）の架空の社内規程と「第1条の有給休暇は何営業日前までに申請するか」という質問をqwen2.5:0.5bに送りました。

• 既定（4k）：実際に処理されたのは2,050トークンで、回答は「30」（第7条・副業の届出期限の数字）。第1条は切り捨てられていた。
• num_ctxを16384に指定：12,601トークンすべてが処理され、回答は「5営業日前」で正解。

既定のログには切り詰めの警告が出ませんでした。文書の後半にある内容には答えられるのに前半について外す場合は、コンテキスト長が足りていない可能性が高いと考えてください。

コンテキスト長の変更方法

• 公式アプリ：設定画面の「Context length」スライダーで4k・8k・16k・32k・64k・128k・256kから選ぶ。
• サーバー全体：環境変数OLLAMA_CONTEXT_LENGTHを指定して起動する（例は下記）。
• API：リクエストのoptionsにnum_ctxを入れる。

# 既存のOllamaサーバーを停止してから実行
OLLAMA_CONTEXT_LENGTH=32768 ollama serve

# 別のターミナルでモデルを実行し、読み込み後に確認
ollama run qwen2.5:0.5b "こんにちは"
ollama ps   # CONTEXT 列で実際に割り当てられた長さを確認する

コンテキストを広げるほどメモリを使います。ollama psのPROCESSOR列が100% GPUから外れてCPUへ処理が移ると遅くなるので、上げすぎたら一段戻します。今回の文書とモデルでは、14,012字に対して12,601トークンでした。文字数とトークン数の比率は文書とモデルによって変わるため、日本語全般の換算率には使えません。この文書には16kが必要でした。

CLI・APIへのテキストと画像の受け渡し

CLIやAPIにはファイルをアップロードする専用の仕組みはありません。テキストは中身をプロンプトに入れ、画像はパスかbase64で渡します。どちらもプロンプトに入る長さは前章のコンテキスト長に縛られます。

標準入力とコマンド置換によるテキスト入力

標準入力からパイプで渡すと、ファイルの内容と引数のプロンプトがまとめてモデルに送られます。シェルのコマンド置換でプロンプトに埋め込んでも同じです。どちらもOllama 0.40.3で動作を確認しました。

cat kitei.txt | ollama run qwen2.5:0.5b "この規程で、リモートワークは週何日が上限ですか。"

ollama run qwen2.5:0.5b "次の規程を3行で要約して。 $(cat kitei.txt)"

PDFやdocxはそのままではテキストになりません。pdftotextなどで先にテキストへ変換してから渡します。

画像パスとbase64による画像入力

画像はビジョン対応モデルでだけ使えます。公式のVisionのページでは、CLIはプロンプトに画像のパスを書き、REST APIは/api/chatのメッセージにimages配列でbase64文字列を入れる方式です。

ollama run gemma4 "./receipt.png この領収書の合計金額は？"

# base64 -i はmacOSの書き方（Linuxは base64 -w0 receipt.png）
curl http://localhost:11434/api/chat -d '{
  "model": "gemma4",
  "messages": [{
    "role": "user",
    "content": "この領収書の合計金額は？",
    "images": ["'"$(base64 -i receipt.png)"'"]
  }],
  "stream": false
}'

Open WebUIのDocker導入とOllama接続

長い文書や複数の文書を扱うなら、Ollamaの前にOpen WebUIを置きます。Open WebUIはファイルを細かく分けて埋め込みベクトルにし、質問に近い部分だけをモデルに渡すRAG（検索拡張生成）を備えています。Ollamaを同じPCで動かしている場合、公式READMEのコマンドはこうです。

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

起動後にhttp://localhost:3000を開き、最初に登録したアカウントが管理者になります。Ollamaが別のマシンにあるときは-e OLLAMA_BASE_URL=http://サーバーのアドレス:11434を足します。Dockerの基本操作はDockerとは｜仮想マシンとの違い・必要スペック・インストール手順を解説【2026年版】、APIキーの発行や画面の全体像はOpen WebUIとは｜使い方・インストール・APIキー発行をv0.12.0で実測解説を参照してください。

掲載コマンドの:mainは更新されるタグです。本記事の検証版を再現する場合は、コマンド末尾のタグを:v0.12.0に変更してください。軽量版の:slimは文書の抽出機能を同梱しておらず、PDFやdocxをアップロードすると「This file type requires an external document extractor in slim.」で止まります（v0.12.0のretrieval/loaders/main.py）。

Open WebUIのファイル添付とナレッジベース登録

Open WebUIのKnowledgeのドキュメントでは、取り込み方が2つ用意されています。その場限りの資料はチャットに添付し、繰り返し使う資料はナレッジベースに登録します。

チャットへの一時的なファイル添付

入力欄の「＋」から「ファイルをアップロード」を選ぶか、ファイルを入力欄にドラッグします。アップロード後に抽出と埋め込みが進みます。処理が完了したことを確認してから質問してください。既定ではファイルサイズと個数に上限がありません（RAG_FILE_MAX_SIZEとRAG_FILE_MAX_COUNTが未設定）。社内で共有するサーバーなら、管理者パネルの「最大アップロードサイズ」（MB単位）で上限を決めておきます。

ナレッジベースへの登録と#による参照

1. 左メニューの「ワークスペース」から「ナレッジベース」を開き、「ナレッジベースを作成する」で名前と説明を入れる。
2. 作ったナレッジベースにファイルやフォルダーをアップロードする。
3. チャットの入力欄で#を打ち、候補からナレッジベースか個別のファイルを選んで質問する。

ワークスペースの「モデル」でカスタムモデルを作ってナレッジベースを紐づけると、#を打たなくてもそのモデルから文書を参照できます。部署ごとの規程集のように、使う文書が決まっている場合に向きます。ナレッジベースに入れたファイルは開くと抽出済みのテキスト（Indexed text）を表示でき、書き込み権限があれば編集して保存し直せます。

関連箇所の検索と全文参照の切り替え

添付したファイルをクリックすると、「関連する部分を検索中」（Focused Retrieval）と「ドキュメント全体を使用中」（Full Context）を切り替えられます。既定は前者です。文書はチャンクサイズ1000文字・重なり100文字で分割され、文書やナレッジベースごとに上位3件が検索されます。

注意したいのは、v0.12.0では関数呼び出しのNative（ネイティブ）モードが既定になっている点です。公式ドキュメントによると、このモードでは添付した文書が自動では差し込まれず、モデル自身が検索ツールを呼び出して取りにいきます。ツール呼び出しに対応したモデルを選び、モデル設定の組み込みツールで「ナレッジベース」と「ファイル」を有効にしておきます。ツールを呼ばないまま答えるモデルでは、文書を添付しても中身が回答に反映されません。

要約や「この資料の問題点を挙げて」のように文書全体を読む必要がある質問では、上位3件では足りません。ドキュメント全体に切り替えます。ただし全文がOllamaへ送られるので、前章のコンテキスト長の制約がそのまま効きます。Open WebUIのモデル設定にある「高度なパラメータ」でコンテキスト長（num_ctx）を上げてから使います。

日本語文書でRAGの精度を上げる設定

Open WebUIのRAGで日本語文書の正しい箇所を探せない場合、埋め込みモデルは確認対象の一つです。抽出結果やチャンク分割を確認したうえで、多言語モデルとの検索結果を比較します。v0.12.0の既定はsentence-transformers/all-MiniLM-L6-v2で、英語向けに学習されたモデルです。

bge-m3への変更前後の検索精度比較（実測）

前章と同じ16条の社内規程をアップロードし、本文とは言い回しを変えた10問（例：規程の「在宅勤務は1週間につき3日を上限」に対して「家で仕事できるのは週に何日まで？」）を用意しました。検索APIを直接呼び出し、答えの文を含むチャンクが検索結果の上位3件に入るかを調べています。これは検索段階の評価であり、チャット回答の正答率を測った結果ではありません。

既定のモデルは「休みを取りたいとき、何日前までに申し込めばいい？」「会社を辞めるときはいつまでに伝える？」などで答えのチャンクを1件も拾えませんでした。bge-m3は100以上の言語と最大8192トークンの入力に対応する埋め込みモデルで、Ollamaからは約1.2GBのダウンロードで使えます。今回の社内規程ではbge-m3が良好だったため、日本語文書で比較する候補にできます。採用前に、自社文書と質問セットでも検索結果を評価してください。埋め込みモデルの選び方は埋め込みモデルとは？仕組みと日本語モデルの選び方・RAG実装での判断基準【2026年版】で比較しています。

ollama pull bge-m3

Open WebUIでは、管理者パネルの「設定」→「ドキュメント」で「埋め込みモデルエンジン」をOllama、「埋め込みモデル」をbge-m3にして保存します。環境変数で初期値を指定する場合は、次の引数をDocker起動コマンドのイメージ名より前に追加します。既定では管理画面で保存した値が優先されるため、保存済みの環境では管理画面から変更してください（環境変数リファレンス）。

-e RAG_EMBEDDING_ENGINE=ollama \
-e RAG_EMBEDDING_MODEL=bge-m3 \
-e RAG_OLLAMA_BASE_URL=http://host.docker.internal:11434

埋め込みモデル変更後のインデックス再作成

埋め込みモデルを変えると、変える前に登録した文書は新しいモデルで検索できなくなります。検証では、変更前にアップロードしたファイルを検索APIで引くと、エラーも出ずに空の結果（null）が返りました。画面にも「埋め込みモデルを変更した後は、変更を反映するためにナレッジ、ナレッジ検索、メモリのベクトルのインデックスを再作成してください。」と表示されます。「埋め込みデータのインデックスを再作成」を実行するか、文書をアップロードし直します。

画像だけのPDFに対するOCR設定

スキャンした書類のように文字の層が無いPDFは、既定の設定では「The content provided is empty.」で取り込みに失敗します。管理者パネルの「ドキュメント」にある「PDF 画像抽出 (OCR)」を有効にすると、PDF内の画像をRapidOCRで文字に起こします（v0.12.0のretrieval/loaders/pdf.py）。レイアウトの複雑な帳票は、「コンテンツ抽出エンジン」でDoclingやApache Tikaなどの外部エンジンに切り替える選択肢もあります。

社内文書を対象にしたRAGを、権限管理や検索精度の評価まで含めて業務に載せたい場合は、RAG構築支援で設計から相談を受けています。

アップロードした文書が回答に反映されないときの確認順

次の順で確かめると、原因を早く絞り込めます。

1. 抽出結果を見る：Open WebUIのナレッジベースでファイルを開き、Indexed textを確認する。空や文字化けならPDFの作り方か文字コードが原因。
2. 形式を見る：Ollamaアプリでdocx・Shift_JISのファイルを添付していないか。UTF-8のテキストやLibreOfficeで書き出したPDFに変える。
3. コンテキスト長を見る：ollama psのCONTEXT列が文書の長さより短くないか。
4. 参照の指定を見る：Open WebUIで#からナレッジベースを選び忘れていないか。
5. モデルのツール対応を見る：Nativeモード（v0.12.0の既定）では、ツールを呼び出せないモデルは添付文書を検索しない。ツール対応モデルに替えるか、組み込みツールの「ナレッジベース」「ファイル」が有効かを確かめる。
6. 埋め込みモデルを見る：日本語なのに既定のall-MiniLM-L6-v2のままになっていないか。変更後に再インデックスしたか。

よくある質問

Ollama単体でPDFは読み込めますか？

macOSとWindowsの公式アプリなら、文字の層があるPDFを添付して読み込めます。CLIやAPIにはファイルを受け取る仕組みが無いため、PDFをテキストに変換してからプロンプトに入れます。画像だけのPDFはアプリでは読めません。

Ollamaの設定ファイルはどこにありますか？

Ollamaの設定は基本的に環境変数で行います。macOSのアプリはlaunchctl setenv OLLAMA_HOST "0.0.0.0:11434"のように設定して再起動し、Linuxはsystemctl edit ollama.serviceでEnvironment行を足します（公式FAQ）。クラウド機能を止めるdisable_ollama_cloudだけは~/.ollama/server.jsonにも書けます。

アップロードしたファイルは外部に送信されますか？

Ollamaのローカルモデルによる推論はローカルで行われます。ただし、Open WebUIの文書抽出・埋め込み・再ランキングに外部サービスを指定している場合は、文書の内容がそのサービスへ送られます。gemma4:cloudのようなクラウドモデルを選ぶと、プロンプトと応答はOllamaのクラウドで処理されます。公式FAQは、その内容を保存・記録せず学習にも使わないと説明しています。OllamaのクラウドモデルとWeb検索を無効にするには、OLLAMA_NO_CLOUD=1を設定してOllamaを再起動します。Open WebUIで選択した外部サービスの通信は、この設定では停止しません。

Open WebUIでアップロードできるファイルサイズの上限は？

v0.12.0の既定では上限がありません。RAG_FILE_MAX_SIZE（MB単位）とRAG_FILE_MAX_COUNT、または管理者パネルの「最大アップロードサイズ」「最大アップロード数」で決めます。Ollamaの公式アプリは1ファイル10MBまでです。

画像ファイルを読み込ませるにはどうすればいいですか？

gemma4などビジョン対応モデルを選びます。アプリはpng・jpg・jpeg・webpを添付でき、CLIはプロンプトに画像のパスを書き、APIはimagesにbase64で入れます。ビジョン非対応モデルを選んでいると、アプリは画像を送信から外します。

関連記事

• Open WebUIとは｜使い方・インストール・APIキー発行をv0.12.0で実測解説
• ローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説
• 埋め込みモデルとは？仕組みと日本語モデルの選び方・RAG実装での判断基準【2026年版】
• PyMuPDF4LLMの使い方｜PDFをMarkdownに変換する手順と日本語PDFの注意点【1.28.2】
• Ollama Web Searchの使い方｜APIキー設定・料金・Python実装【2026年9月】