DocsGPT を導入前に読む: Agent Builder と RAG バックエンドの実像
Private AI platform for agents, assistants and enterprise search. Built-in Agent Builder, Deep research, Document analysis, Multi-model support, and API connectivity for agents.
ひと目でわかる
- これは何？
- arc53/DocsGPT は PDF や音声を取り込んでエージェントを組める MIT ライセンスの自己ホスト型プラットフォームである。Docker Compose で立ち上がる構成と、公開情報からは確認できない部分を切り分けて整理する。
- 誰に向いている？
- 社内文書を外部に出さずに検索とエージェントを組ませたいチーム、とくに PDF や Office 文書に加えて会議音声まで検索対象にしたい組織には向いている。逆に、ホスト型のマネージド検索で十分な場合や、Python と Docker の面倒を誰も見ない体制なら、この構成を維持する理由は薄い。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
DocsGPT が埋めようとしている穴は「社内文書を外に出せない」という制約
README の冒頭は「Private AI for agents, assistants and enterprise search」と宣言している。つまり対象は、ChatGPT や SaaS 型の検索サービスに社内文書を預けられない組織である。読み込む形式として PDF、DOCX、CSV、XLSX、EPUB、MD、RST、HTML、MDX、JSON、PPTX、画像、そして MP3、WAV、M4A、OGG、WebM といった音声が列挙されている。文書検索の道具は数多くあるが、音声ファイルを同じ知識ベースに流し込めると明記している点は範囲が広い。会議録音やボイスメモを検索対象にしたいという要求は、実際の社内では文書検索とは別のツールになりがちで、そこを一つのインデックスに寄せられるかどうかが採用判断の分かれ目になる。取り込み元も URL、サイトマップ、Reddit、GitHub、ウェブクローラと幅がある。ただしこれらは README の記載であり、取り込み精度やチャンク分割の挙動は公開情報からは判断できない。
バックエンドは Flask、フロントは Vite と React という分担
リポジトリの Project Structure には docsgpt という Python パッケージがバックエンドの Flask アプリケーションだと書かれている。フロントエンドは Vite と React で構成され、Extensions ディレクトリに Chatwoot や React ウィジェットといった連携物が入る。つまり DocsGPT は単一のバイナリではなく、API サーバ、ワーカー、フロントエンド、そして外部連携の集合体である。README の Roadmap を見ると、2026 年 4 月に Celery の RedBeat を使ったエージェントのスケジューリング、同じく 4 月に Postgres へのユーザーデータ移行、OpenTelemetry による可観測性が完了扱いになっている。ここから読み取れるのは、単発のチャット UI から、定期実行されるエージェントとその実行履歴を管理する運用寄りの構成へ舵を切ったということだ。6 月には OIDC / SSO と SCIM プロビジョニング、管理者ダッシュボードと RBAC、チーム単位の共有とロールが並ぶ。個人がローカルで試す用途と、組織で配る用途の両方を同じリポジトリで賄おうとしている。この二重性は、小規模に始めたチームが後で権限まわりを有効化するときに効いてくる。
起動は setup.sh が .env を書き換える方式
QuickStart は Docker のインストールを前提とし、まず git clone https://github.com/arc53/DocsGPT.git して cd DocsGPT する。macOS と Linux では ./setup.sh、Windows では PowerShell -ExecutionPolicy Bypass -File .\setup.ps1 を実行する。このスクリプトは対話形式で 5 つの選択肢を提示する。公開 API を使う、ローカルで動かす、ローカルの推論エンジンに接続する、クラウド API プロバイダを使う、Docker イメージをローカルでビルドする、の 5 つである。選択に応じて .env が自動設定され、必要なダウンロードとインストールが走る。起動後は http://localhost:5173/ を開く。停止は DocsGPT ディレクトリで docker compose -f deployment/docker-compose.yaml down を実行する。ここで注意したいのは、モデルの選択がセットアップ時の分岐に埋め込まれている点だ。後から Ollama から OpenAI へ切り替えたければ .env を直接読み書きすることになる。README はローカルモデルとして Ollama と llama_cpp、クラウドとして OpenAI、Google、Anthropic を挙げている。開発環境の手順は README ではなくドキュメント側の Development Environment Guide に分離されている。
Agent Builder とツール接続は「API キーが設定に紐づく」設計
README は API キーについて、設定、ドキュメント、モデルに紐づく形で生成され、チャットボットと連携のセットアップを単純化すると説明している。これはつまり、キーが単なる認証トークンではなく、どの知識ベースとどのモデルを使うかの文脈を運ぶということだ。エージェントに API やツール、外部サービスを接続して LLM に行動させる仕組みも用意されている。Roadmap では 2026 年 2 月に条件分岐ノード付きの Agent Workflow Builder が完了、6 月にエージェントのインポートとエクスポートが完了している。エージェント定義をファイルとして持ち出せるなら、環境間の移行やレビューがしやすい。ただしワークフローのノード種別や条件式の書き方は README には書かれておらず、ドキュメントを読む必要がある。回答には出典が付き、UI 上で確認できると記載されている。ハルシネーションを避けるという表現は README の主張であって、検証結果ではない。RAG の citation は検索結果の提示であって、その内容が正しいことの保証ではない。
公開情報からは確認できない部分を先に潰す
この記事で扱った範囲では、埋め込みモデルの既定値、ベクトルストアの種類、チャンクサイズ、リランキングの有無は一切分からない。README の Architecture は画像一枚で、本文の説明が付いていない。したがって「どのくらいの文書量まで実用的か」「日本語文書の検索精度はどうか」は、自分で環境を作って測る以外に確かめる方法がない。日本語の扱いは特に注意が必要だ。README に挙がる形式や連携先は英語圏のサービスが中心で、日本語の分かち書きや全文検索の設定についての記述はない。MIT ライセンスなので商用利用や改変の制約は緩いが、ライセンスはソフトウェアに対するもので、同梱するモデルの重みやクラウド API の利用規約は別問題である。ここは法的助言ではないので、自組織の法務や調達の確認を通すべき領域として挙げておく。
向かないケース: マネージド検索で足りるなら持ち込む理由が薄い
比較対象として素直なのは、ベクトル検索をマネージドで提供するサービスや、既存の SaaS 型チャットボットである。違いは導入の手間そのものより、責任の所在にある。マネージド側はインデックスの更新、スケーリング、モデルの差し替えをベンダーが持つ。DocsGPT はそれを自分の Docker 環境に引き取る代わりに、文書が外に出ないことと、モデルを Ollama や llama_cpp に差し替えられる自由を得る。この交換が割に合うのは、データの所在が調達条件になっている場合だ。逆に、扱う文書が数個の PDF で、外部に出しても問題ないなら、ベクトルストアと埋め込みモデルを自分で運用する理由はほとんどない。もう一つの代替は、RAG の部品を自分で組むことである。LangChain などで検索部分だけ作り、UI は自前で書く。DocsGPT を選ぶ意味は、Agent Builder、スケジューリング、RBAC、SSO、チーム共有といった周辺をゼロから書かずに済む点に集約される。逆に言えば、検索エンジン部分だけが欲しいなら、この構成は重い。
更新コストは Roadmap の速度そのもの
リリースは 0.17.3 が 2026 年 6 月 13 日、0.18.0 が 6 月 26 日、0.19.0 が 8 月 13 日と、およそ 2 か月弱の間隔で minor が上がっている。Roadmap も 2 月から 6 月にかけて毎月のように項目が完了しており、機能追加のペースは速い。これは利点であると同時に、運用側の追従コストでもある。0.x 系である以上、minor 更新で .env のキーや API の形が変わる可能性を想定しておくべきだ。Docker Compose で動かしているなら、イメージタグを固定して更新は意図的に行う形が現実的である。deployment/docker-compose.yaml を読めば、どのサービスがどのイメージを使っているかが分かるので、更新時に確認すべきファイルはこれ一つに絞れる。MIT ライセンスなので fork して自組織向けに固定する選択肢もあるが、その場合は upstream の修正を自分で取り込む作業が発生する。エージェントのインポートとエクスポートができるなら、定義だけを別管理し、実行環境は作り直すという運用も取れる。
編集部の結論
社内文書を外部に出さずに検索とエージェントを組ませたいチーム、とくに PDF や Office 文書に加えて会議音声まで検索対象にしたい組織には向いている。逆に、ホスト型のマネージド検索で十分な場合や、Python と Docker の面倒を誰も見ない体制なら、この構成を維持する理由は薄い。導入を決める前に、deployment/docker-compose.yaml を開いて実際に起動するコンテナの数と役割を数え、.env にどのモデルプロバイダのキーが必要になるかを確認しておくこと。
コミュニティノート