【OSS】HKUDS/DeepTutorについて

リポジトリ概要

DeepTutorは「個別最適化された学習アシスタント」を、エージェント前提（Agent-Native）で組み立てるためのPython製OSSです。単に質問へ答えるだけでなく、学習者の状況に応じて「次に何を聞くべきか」「どこでつまずいていそうか」「どの順序で説明すべきか」といった進行を、複数の役割（エージェント）に分けて協調させる発想が中心にあります。エージェントは“担当者”のようなもので、たとえば解説担当、要約担当、追加質問担当などに分担すると、学習の体験を作り込みやすくなります。

リポジトリ構造を見ると、学習体験の種類ごとにエージェント群が用意されています。たとえばdeeptutor/agents/配下には、チャット、文章編集支援（co-writer）、学習ガイド、調査（research）、解法（solve）、可視化（visualize）、画像を含む解法（vision_solver）、数学アニメーション生成（math_animator）などが並び、それぞれが「プロンプト（指示文のテンプレート）」と実装コードを持っています。プロンプトはprompts/enやprompts/zhのように言語別に整理されており、同じ機能でも言い回しを差し替えながら動作を調整できる設計です。

アプリとしての入口はdeeptutor/api/に集約されています。api/routers/にはチャット、ガイド、知識ベース、メモリ、ノートブック、セッション管理などのルーターが用意されており、「学習アシスタントの機能をAPIとして提供する」ための骨組みが見えます。加えてdeeptutor/services/には、LLM（大規模言語モデル）や埋め込み（文章を検索しやすい数値に変換する仕組み）、RAG（資料検索を組み合わせた回答）、検索プロバイダ、設定、セッションといった土台が揃っています。つまりDeepTutorは、学習用UIを作る前に必要な“裏側のレール”が一通り揃っていて、用途に応じてモード（capabilities）を組み合わせられるのが強みです。

また、知識ベース周りはdeeptutor/knowledge/やドキュメント側の「Knowledge Base Management Module」で補足されています。教材や資料を入れ替えたときに、再処理（リフレッシュ）と完全再構築（リビルド）をどう使い分けるか、といった運用面の考え方も示されており、継続的に教材を育てる前提が置かれています。

どんなときに便利か

DeepTutorが便利なのは、「学びの過程を、会話だけで終わらせたくない」ときです。たとえば、学習者が質問して終わりではなく、理解度の確認→補足説明→例題→類題→要点整理、という流れを自然に回したい場面があります。人がチューターとしてやると、相手の反応を見て手順を変えますが、DeepTutorはその“手順の組み立て”をエージェントの協調として実装しやすくします。

もう一つは、教材や社内ドキュメントのような「手元の資料」を学習に混ぜたいときです。RAGの部品としてMarkdown/PDF/Textのパーサや、検索・埋め込み・インデックス作成の構成要素が整理されているため、資料に沿った説明や、資料のどこを読めばよいかの案内に繋げやすくなります。専門用語が多い教材でも、要点の要約や段階的な言い換えを“役割ごと”に任せることで、初心者向けの読みやすい導線を作れます。

さらに、学習体験をアプリにしたい開発者にも向いています。api/routers/が揃っているため、フロントエンド（Webやモバイル）から呼べる形に組み込みやすく、セッション管理や進捗の扱いも考慮された作りです。「学習チャットを作りたい」だけでなく、「学習ダッシュボード」や「ノートブック連携」など、複数機能を同居させたいときに、ゼロから設計する負担を減らせます。

使い方

導入はREADMEに沿って、まずリポジトリを取得して作業ディレクトリへ移動するところから始めます。セットアップの細部（依存関係の導入や環境変数など）はプロジェクトのREADME手順に従ってください。

git clone https://github.com/HKUDS/DeepTutor.git
cd DeepTutor

最初の利用手順としては、「どの学習モードを使うか」を決めるのが分かりやすいです。たとえば、

• まずはチャットで質問に答える（chat）
• 文章を添削・書き換えしながら学ぶ（co-writer）
• 学習計画や段階的な説明をガイドする（guide）
• 問題を解く手順を組み立てて提示する（solve）
• 資料を読み込んで調べ学習する（research / RAG） のように、目的に応じて入口が変わります。DeepTutorはこの入口を「capabilities」として束ね、内部で複数エージェントを動かす設計なので、まずは一つのモードに絞って体験を作り、その後に資料検索や要約、復習問題生成などを足していく流れが取り組みやすいです。

よくある利用フローの具体例としては、次のような“学習の往復”が作れます。

1. 学習者がテーマを入力（例：微分の基本、英語要約、社内SDKの使い方）
2. ガイド役が前提を確認し、短い説明を提示
3. 追加質問役が理解度チェックの質問を出す
4. 間違いがあれば、別の言い方や例で再説明
5. 最後に要約役が「今日のポイント」と「次にやること」をまとめる この流れを、単一の巨大なプロンプトで無理に実現するのではなく、役割分担として整理できるのがDeepTutorの価値です。

知識ベースを併用する場合は、教材や資料を追加した後に「差分更新でよいのか」「一度作り直したほうがよいのか」を判断します。パース方法（読み取り方）やモデルを変えた場合、あるいは以前の処理の誤りを正したい場合など、更新の理由に応じてリフレッシュと再構築を使い分ける考え方が示されています。これにより、資料が増えていく運用でも、学習アシスタントの回答品質を保ちやすくなります。

具体的なユースケース

1つ目は、社内ドキュメントや講義資料を使った“伴走型”学習です。RAGの構成要素（Markdown/PDF/Textのパーサ、埋め込み、インデックス、検索）が整理されているため、資料に沿って「該当箇所の要点→噛み砕いた説明→確認問題」という流れを作れます。今までだと、資料の読み込み・検索・回答の整形を個別に組み上げる必要がありましたが、DeepTutorは学習体験としてまとめる発想があるので、実装の迷子になりにくいです。

2つ目は、文章作成を通じた学習（co-writer）です。レポートや説明文を“直して学ぶ”と、理解が深まりやすい一方で、何をどう直すべきかのフィードバック設計が難しくなりがちです。DeepTutorでは編集担当やナレーション担当などの役割が分かれており、たとえば「まず意図を保ったまま読みやすく」「次に用語を簡単に」「最後に要点を箇条書きに」と段階を分けた支援が組み立てやすくなります。

3つ目は、問題解決型の学習（solve / question）です。解答だけを出すのではなく、途中式や考え方を“学習者の反応に合わせて”出し分けたいとき、計画役（planner）と解答役（solver）と記述役（writer）のように責務を分けて実装できるのは大きな利点です。専門用語も、短い言い換えや一文補足を挟む設計にしやすく、初心者が置いていかれにくい体験を作れます。

4つ目は、学習アプリへの組み込みです。APIルーターが揃っているため、フロントエンド側では「セッションを開始→モードを選択→応答を表示→履歴を保存」のような実装に集中しやすくなります。加えて、最近のリリースでは依存関係の見直し（例：LiteLLM依存の削除など）も進んでおり、運用や拡張をしやすい方向に更新されている点も、プロダクトに組み込む際の安心材料になります。