「DeepTutor」というリポジトリ名を GitHub Trending や技術ブログで見かけたものの、公式 README を全部読み込む前に「これは自プロジェクトに組み込むべきか」を判断したい——そんなエンジニアは少なくないはずです。
DeepTutor は 27,000 スターを超えるハイペースで成長しているオープンソースの学習ワークスペースですが、周辺には LlamaIndex・LightRAG・LangChain・AutoGen・Open-TutorAI-CE など類似・関連する OSS が数多く存在します。「汎用エージェントフレームワークとの違い」「同じ開発元(HKUDS)の LightRAG との関係」「メンテナンス体制の健全性」を短時間で見極めるには、それぞれの位置づけを整理した俯瞰情報が必要です。
しかし現状、日本語で公開されている DeepTutor の解説記事は「初心者向けの使い方紹介」に偏っており、採用判断に必要な設計思想・アーキテクチャ・類似 OSS との差分を一次情報ベースで整理した記事はほとんど見当たりません。
本記事では、公式 README・公式ドキュメント・公式サイト・論文をもとに、DeepTutor の 6 つの学習モード、マルチエンジン RAG、3 層メモリ、CLI とエージェント連携、EduHub エコシステムを整理します。あわせて Open-TutorAI-CE・AI_Tutor・LightRAG との差分と、「採用すべきかどうか」を判断するためのチェックポイントもまとめます。
なお本記事はドキュメントベースで作成しており、実行検証やスクリーンショットは含みません。動作確認はご自身の環境で公式手順に沿って実施してください。
DeepTutor とは何か
DeepTutor は、Chat・Quiz・Deep Solve・Deep Research・Visualize・Mastery Path という 6 つの学習モードを、単一のエージェントループ上で動作させるオープンソースの学習ワークスペースです。開発元は香港大学 Data Intelligence Lab(HKUDS)で、リポジトリの位置づけは「Lifelong Personalized Tutoring(生涯学習を支えるパーソナライズド・チューター)」とされています。
リポジトリの基本情報は以下のとおりです(HKUDS/DeepTutor より)。
項目 | 値 |
|---|---|
owner/name | HKUDS/DeepTutor |
主要言語 | Python |
ライセンス | Apache-2.0 |
スター数 | 27,014 |
フォーク数 | 3,623 |
最終 push | 2026-07-09 |
アーカイブ状態 | アーカイブされていない( |
フォーク状態 | 本家リポジトリ( |
公開状態 | public |
アーカイブされておらず、フォーク版でもない本家の active リポジトリです。ライセンスは Apache-2.0 のため、商用利用や改変も可能です。
公式サイトは deeptutor.info、公式ドキュメントは docs.deeptutor.info にあります。学術的な背景は論文 DeepTutor: Towards Agentic Personalized Tutoring(arXiv) で示されています。
初回リリースは 2025 年 12 月、v1.0(Agent-native architecture rewrite)は 2026 年 4 月にリリースされたと README で言及されており、直近の push が 2026 年 7 月 9 日であることから、月次以上のペースで更新が続いていることが確認できます。
DeepTutor が解決する学習ドメインの課題
汎用チャット型 AI(ChatGPT・Claude 等)を学習用途に使うと、いくつかの構造的な課題が浮かびます。
- セッション断裂: 「調べる」「クイズを解く」「まとめる」を別セッションで行うと、コンテキストが引き継がれない
- メモリの不透明さ: 何が「覚えられている」のか、何が更新されたのかがユーザーから見えない
- モード切替コスト: リサーチ用と練習問題用でプロンプトを毎回組み立て直す必要がある
- 知識源のばらつき: 参照する PDF・ノート・ウェブ記事が会話ごとにバラバラで、体系的な学習ワークスペースになりにくい
DeepTutor の設計思想は、こうした課題に対して「モードではなくエンジンを共通化する」「メモリを可視化・監査可能にする」「学習コンテキスト(ナレッジベース・ノート・問題バンク)を全ワークフローで共有する」というアプローチを採ります。論文 DeepTutor: Towards Agentic Personalized Tutoring では、生涯学習を前提とした「エージェントによる継続的パーソナライゼーション」を主張しています。
つまり DeepTutor は「学習ドメインに特化した完成品ワークスペース」を志向しており、単なる「LLM ラッパー」や「RAG ライブラリ」とは狙いが異なるプロダクトです。汎用 LLM でも「教える」「問題を出す」「調べる」はできますが、DeepTutor はそれらを 1 つのエージェントループと共有ステートで束ねる点に価値があります。
DeepTutor のアーキテクチャと主要機能
ここからは DeepTutor の主要機能を、公式 README の「Key Features」および公式ドキュメントの記述をもとに整理します。
統一エージェントループと 6 つの学習モード
DeepTutor では、Chat(デフォルト)・Quiz・Deep Solve・Deep Research・Visualize・Mastery Path の 6 つのモードが同一のエージェントループ上で動作します。モードを切り替えても学習コンテキスト(履歴・ナレッジ・ペルソナ)が保持されるため、「調べる → クイズを出す → 弱点を可視化 → 復習計画を立てる」という一連のワークフローを 1 つの会話の延長として実行できます。
- Chat: 汎用対話・質問応答の基本モード
- Quiz: ナレッジベースやチャット履歴から問題を生成
- Deep Solve: 数式・コード等を含む複雑な問題を段階的に解く
- Deep Research: 複数ソース横断のリサーチ・要約
- Visualize: 図解・タイムライン・インタラクティブ HTML 生成
- Mastery Path: 弱点分析にもとづく学習計画の生成
これら 6 つが独立アプリケーションではなく、共通のランタイム上に配置されている点が DeepTutor 特有の設計です。
マルチエンジン RAG ナレッジベース
DeepTutor のナレッジベース(KB)機能は、単一の検索アルゴリズムに縛られず、複数の検索エンジンを KB 単位で選択できます。README「Knowledge Center — Multi-Engine RAG Libraries」および公式ドキュメントによれば、以下の 6 種のエンジンから選択可能です。
- LlamaIndex(デフォルト、ローカルベクトル + BM25)
- PageIndex(ホスト型 reasoning retrieval)
- GraphRAG
- LightRAG
- LightRAG Server
- Obsidian vault リンク
ドキュメントパーサとしては Text-only / MinerU / Docling / markitdown / PyMuPDF4LLM の 5 種が利用可能で、PDF や技術ドキュメントの取り込みも柔軟に行えます。KB は version-N ディレクトリでバージョン管理されており、再インデックスも安全に実施できる設計です。
「1 つの KB は 1 つの検索アルゴリズム」に固定されないため、教材の種類(構造化ドキュメント / ノート / コードベース / 論文)ごとに最適なエンジンを選び分けられます。
3 層構造の可視化可能メモリ
学習アプリでは「AI が何を覚え、何を推論に使ったのか」の透明性が重要になります。DeepTutor は README「Memory — Inspectable Personalization」で、以下の 3 層メモリ構造を採用しています。
- L1: 追記専用イベントトレース(
trace/<surface>/<date>.jsonl) - L2: サーフェス別のキュレーション済みファクト(
L2/<surface>.md) - L3: サーフェス横断の統合サマリ(
L3/<profile|recent|scope|preferences>.md)
さらに Memory Graph によって L3 → L2 → L1 と辿ることができ、統合済みの主張が「どの L1 イベントに由来するか」を追跡可能です。人間が読める Markdown / JSONL 形式で保存されるため、監査・修正・エクスポートが容易です。
学習ドメインでは「なぜこの問題が推薦されたのか」「なぜこのペルソナだと判定されたのか」を説明できることが信頼につながるため、この設計は実運用でも重要な差別化要因になります。
Partners と Sub-agent 連携
DeepTutor は「Partner」という永続コンパニオン概念を持ち、各 Partner に SOUL.md(性格定義)・モデル・チャネル・ライブラリ・メモリを個別に割り当てられます。README「Partner — Persistent Companions on the Same Brain」によれば、以下 13 種の IM チャネルに接続可能です。
- Feishu / Telegram / Slack / Discord / DingTalk / QQ・NapCat / WeCom / WhatsApp / Zulip / Mattermost / Matrix / Mochat / Microsoft Teams
加えて、チャット中に consult_subagent ツール経由でローカル Claude Code や Codex CLI を呼び出し、その進捗を Activity パネルへリアルタイムにストリームできます(README「My Agents」)。過去の Claude Code / Codex 会話も「My Agents」として取り込み、参照可能です。
つまり DeepTutor は自身が「巨大なエージェント」であると同時に、外部エージェント(Claude Code / Codex)を呼び出したり、逆に外部から呼び出されたりする「エージェントノード」としても機能する構成になっています。
DeepTutor CLI とエージェント連携
DeepTutor は Web UI だけでなく、deeptutor バイナリによる CLI インターフェースを提供しています。README「DeepTutor CLI — Agent-Native Interface」によれば、CLI では REPL(deeptutor chat)と単発実行(deeptutor run <capability>)の 2 モードが用意されています。
主要な CLI サブコマンドは以下のとおりです(README より)。
chat: 対話型 REPLrun <capability>: 単発実行(--format jsonで NDJSON 出力)kb: ナレッジベース操作partner: Partner の管理skill: EduHub からのスキルインストール・管理memory: メモリ層の閲覧・書き出しsession: セッション管理notebook/book: ノート・書籍エンジンconfig: 設定
--format json 指定時は 1 行ごとに JSON オブジェクトを出力する NDJSON 形式となるため、LangChain・AutoGen・CrewAI 等の汎用エージェントフレームワークのループ内で「DeepTutor をツールとして呼び出す」使い方に適合します。
同梱の SKILL.md(約 150 行、README 記載)によって、Claude Code / Codex / OpenCode などの外部エージェントが DeepTutor の CLI ツール一式を自動把握できる設計になっている点も特徴です。エージェント連携の詳細は公式ドキュメントの Agent Handoff セクションにまとめられています。
「DeepTutor を自チームのエージェントスタックにどう組み込むか」という現実的な統合パスとしては、以下の 2 通りが考えられます。
- DeepTutor を UI として使い、内部で外部エージェントを呼び出す(
consult_subagent経由で Claude Code / Codex) - DeepTutor を CLI ツールとして外部フレームワークから呼び出す(
deeptutor run --format json経由で LangChain / AutoGen)
どちらの方向にも設計されているため、既存のエージェントスタックを大きく作り替えずに評価に進めやすい構成です。
DeepTutor の 4 つの導入パス
DeepTutor は「フル Web + CLI」「ソースからの開発」「Docker」「CLI のみ」の 4 通りの導入パスが公式 README「Get Started」で提示されています。以下は公式手順の要約であり、動作検証は含みません。実際のインストールは公式手順に沿って実施してください。
# | 手段 | 想定用途 | 依存 |
|---|---|---|---|
1 | PyPI( | フル Web アプリ + CLI(推奨) | Python 3.11+ / Node.js 20+ |
2 | Source( | 開発・拡張用途 | Python 3.11+ / Node.js 22 LTS |
3 | Docker( | セルフコンテナ運用 | Docker |
4 | CLI Only( | Web UI 不要のエージェント連携用途 | Python 3.11+ |
共通のワークスペースレイアウトは data/user/settings/ 配下に配置され、環境変数 DEEPTUTOR_HOME で変更可能です。起動フローとしては「ワークスペース選択 → インストール → deeptutor init → deeptutor start」となります。詳細な手順は HKUDS/DeepTutor README の Get Started セクション を参照してください。
Multi-User デプロイ
READMEの「Multi-User — Shared Deployments」セクションによれば、認証はデフォルトでオフ(シングルユーザー運用)であり、有効化すると 1 つの data/ ツリー配下に admin ユーザー・個別ユーザー・Partner ワークスペースを共存させられます。最初に登録したユーザーが admin となり、モデル・API キー・KB・Skill・Grant を一元管理する構成です。
小規模チームでの共有運用(例: 教材開発チーム内での KB 共有)を想定するなら、Multi-User モードでの data/ 管理設計を最初に検討することになります。
EduHub と拡張エコシステム
DeepTutor はコア機能だけでなく、拡張スキルを配布・導入するためのエコシステムを備えています。README「Ecosystem — EduHub & the Skills Community」によれば、Agent-Skills 形式(YAML frontmatter + Markdown の SKILL.md)を採用しており、デフォルトハブとして EduHub が用意されています。
- 公式ハブ: EduHub(
deeptutor skill install <slug>で導入) - 互換ハブ: ClawHub。
settings/skill_hubs.jsonに任意の互換 HTTP API を追加可能
スキルインポート時の安全ゲートとして、以下の仕組みが README で言及されています。
- セキュリティ判定チェック(LLM ベースの Risk 評価)
- 拡張子ホワイトリスト
always:frontmatter(自動実行フラグ)の剥奪.hub-lock.jsonによるインストール履歴の記録
コミュニティで公開されているスキル例としては、Socratic tutor(対話型指導)、flashcard builder(暗記カード生成)、essay feedback(作文添削)などが README・EduHub サイトで紹介されており、単発ツールではなく継続的にスキルが追加されるエコシステムを形成しています。
自社カスタマイズの拡張余地としても、SKILL.md フォーマットに沿ってスキルを社内配布用ハブに登録する運用が想定でき、社内独自の学習ドメイン(例: 資格試験・社内技術ドキュメント)向けの拡張が現実的です。
類似 OSS との違い
DeepTutor の位置づけを明確にするため、GitHub Topics(ai-tutor)や関連キーワードで確認できる類似 OSS との差分を整理します(各プロジェクトのスター数・言語・ライセンス・直近 push は各リポジトリの公開情報より)。
リポジトリ | スター | 言語 | ライセンス | 直近 push | 位置づけ |
|---|---|---|---|---|---|
27,014 | Python | Apache-2.0 | 2026-07-09 | 学習ワークスペース完成品 | |
79 | JavaScript | BSD-3-Clause | 2026-06-26 | 教育プラットフォーム(コミュニティ版) | |
58 | Python | MIT | 2026-06-23 | KG-RAG(Knowledge Graph 強化 RAG)研究プロトタイプ | |
37,748 | Python | MIT | 2026-07-17 | 「Simple & Fast RAG」ライブラリ(DeepTutor の上流依存) |
Open-TutorAI-CE との差分
Open-TutorAI-CE は Ollama や OpenAI 互換 API とローカル RAG を組み合わせた「教育プラットフォーム」寄りの OSS です。コミュニティ版として提供されており、教材配信の側面が強い構成です。
一方で DeepTutor は Chat・Quiz・Deep Solve・Deep Research・Visualize・Mastery Path の 6 モード、Partners による IM 統合、Sub-agent 連携、Book Engine、マルチエンジン RAG(6 種)まで含めた「学習ワークスペース」を単一プロダクトで提供する点が異なります。スター数・コミュニティ活性・エコシステム成熟度でも大きな差があります。
AI_Tutor(098765d)との差分
AI_Tutor は Knowledge Graph 強化型 RAG(KG-RAG)に特化した研究プロトタイプ的な位置づけです。KG-RAG 手法そのものの実装デモに近く、Web UI や CLI・IM 統合は含みません。「KG-RAG を手法として検証したい」ケースでは有用ですが、「学習ワークスペースを構築したい」というニーズには DeepTutor のほうが直接的な選択肢となります。
HKUDS/LightRAG との関係
同じ HKUDS 発の LightRAG は「Simple & Fast RAG」を掲げる RAG ライブラリです。DeepTutor と LightRAG は競合関係にはなく、DeepTutor は LightRAG を自身のマルチエンジン RAG の選択肢の 1 つとして統合しています(「LightRAG」「LightRAG Server」がエンジンリストに含まれる)。
したがって「純粋な RAG ライブラリだけが欲しい」なら LightRAG 単体、「学習ワークスペースとしてまとまった機能が欲しい」なら DeepTutor、という棲み分けになります。両者を混同しないよう注意が必要です。
汎用エージェントフレームワークとの棲み分け
LangChain・AutoGen・CrewAI といった汎用エージェントフレームワークとは、そもそも「解こうとしている問題のレイヤ」が異なります。DeepTutor は「学習ドメインに特化した完成品ワークスペース」であり、汎用フレームワークで「学習アプリを自作する」ケースの代替候補になり得ます。
さらに DeepTutor 自身が「LangChain / AutoGen ループ内で deeptutor run をラップして呼び出せる」設計(README「Let an agent drive it」)を持つため、既存の汎用フレームワークのループから DeepTutor をツールとして呼ぶハイブリッド構成も可能です。
DeepTutor 採用判断のためのチェックポイント
ここまでの内容を踏まえて、DeepTutor を自プロジェクトで採用検証すべきかどうかを判断するためのチェックポイントをまとめます。
向いているユースケース
- 学習・教育ドメインで、Chat + Quiz + Research + Visualize + 学習計画をひとつのワークスペースに統合したい
- RAG エンジンを教材種別ごとに切り替えたい(構造化ドキュメント / ノート / コードベース / 論文 で使い分け)
- IM チャネル経由でチューターを配信したい(Slack / Discord / Feishu 等)
- 既存の Claude Code / Codex エージェント環境と学習ワークスペースを連携させたい
- 監査可能なメモリが要件になっている(3 層メモリと Memory Graph)
慎重に検討すべきケース
- 純粋な RAG 検索基盤のみが欲しい: LightRAG 単体(または他の RAG ライブラリ)のほうが軽量
- 汎用エージェントフレームワーク自体が必要: LangChain / AutoGen / CrewAI のほうが目的に合致
- 教材配信・LMS が主目的: Open-TutorAI-CE のような教材プラットフォーム寄り OSS も検討候補になる
- KG-RAG 手法の研究・検証が目的: AI_Tutor 等の研究寄り OSS のほうが読みやすい可能性がある
メンテナンス・エコシステム健全性
採用判断の重要な観点である「メンテナンス状況」については、以下が確認できます。
- 直近 push: 2026-07-09(本記事執筆時点で 1 週間以内)
- ライセンス: Apache-2.0(商用改変可)
- 状態: アーカイブされていない(
archived=false)、フォーク版ではない本家(fork=false) - リリース頻度: 月次以上(README「Releases」セクションおよび最新 v1.5.1 の言及より)
- 貢献ガイド: リポジトリ内
CONTRIBUTING.mdに整備 - コミュニケーションチャネル: Discord / Feishu / WeChat / Mattermost 等の複数チャネルで運営
コミュニティの活性度としては、27,014 スター・3,623 フォークという規模から見て、少なくとも「関心を集めているフェーズ」であることは明らかです。ただし v1.0 リライトが 2026 年 4 月と比較的最近であり、コミュニティ主導で仕様変更のペースが速い点は留意が必要です。
現時点の限界・注意点
- 公式が有償の商用製品は「現時点で存在しない」ことを README で明言しており、商用サポートを前提とするなら別途契約や自社サポート体制の整備が必要
- 仕様変更ペースが速いため、本番導入時はバージョン固定・アップグレード時の検証プロセスが必須
- 日本語圏の運用事例・ドキュメントはまだ限定的で、社内でトラブルシュートする体制が求められる
これらを踏まえ、まずは Docker または PyPI での PoC 環境構築 → 自チームのユースケースに最も近いモード(Chat + Quiz + KB)で 1〜2 週間の評価 → 採用判断、という段取りが現実的な進め方です。公式手順は HKUDS/DeepTutor README と 公式ドキュメント にまとまっています。



