AI授業・研修教材を自動生成するOSSにOpenMAICが選ばれる理由

AI で研修資料や講義資料を作る OSS は、この 1 年で一気に増えました。ところが候補を並べてみると、「プロンプトを入れるとスライドが出てくる」までは同じで、そこから先がまったく違います。出てきたスライドを誰がどう使うのか、理解度の確認まで面倒を見るのか、生成物を自社アプリに組み込めるのか。そこを見誤ると、PoC を一通り終えてから「求めていたものと違った」と気づくことになります。

厄介なのは、検索して出てくる情報の多くが機能の紹介にとどまっている点です。エンジニアが技術選定で本当に知りたいのは、機能一覧そのものではなく、依存関係の重さ、自己ホストに必要な前提、認可モデルがどこまで作り込まれているか、リリース頻度に追従できるか、といった運用側の情報のはずです。これらはリポジトリの README や公式ドキュメントに書かれていることが多いのですが、英語の長大な README を読み解く時間は、候補が複数あるときほど取りにくくなります。

本記事では、清華大学の THU-MAIC チームが公開している OpenMAIC を、機能紹介ではなく採用判断の軸の側から整理します。生成される「授業」の範囲、アーキテクチャと拡張ポイント、導入要件、README 自身が明記しているセキュリティ上の前提、そして Presenton や PPTAgent など類似 OSS との違いを順に見ていきます。

なお、本記事の記述はすべて公式リポジトリの README、公式ドキュメント、公開論文、および GitHub API から取得したリポジトリメタデータに基づくものです。インストールや実行による動作検証は行っておらず、ドキュメントに書かれている内容を採用判断の材料として整理する立場で執筆しています。数値は特記のない限り 2026 年 9 月 28 日時点の取得値です。

OpenMAICとは｜清華大学発のマルチエージェント授業生成OSS

OpenMAIC は Open Multi-Agent Interactive Classroom の略で、清華大学の THU-MAIC チームが開発するオープンソースの AI 教育プラットフォームです。README では「任意のトピックまたは文書を、リッチでインタラクティブな教室体験に変えるオープンソース AI プラットフォーム」と説明されています。

このプロジェクトの特徴は、生成の出口が「資料」ではなく「授業」である点にあります。トピックの記述または資料のアップロードを起点に、スライド・クイズ・インタラクティブな HTML シミュレーション・PBL（Project-Based Learning）を含む授業一式が生成され、それを AI 教師と AI 同級生のエージェントが音声とホワイトボードを使って進行します。学習者はその場で質問でき、エージェント同士の議論に参加することもできます。

リポジトリの基本情報は次のとおりです。

アーカイブ済みリポジトリやフォーク版は、更新が止まっていたり本家との差分が不明だったりするため採用判断に注意が必要ですが、OpenMAIC はいずれにも該当しません。前日にあたる 2026 年 9 月 27 日にプッシュがあり、開発は現在も継続しています。

背景には学術的な研究があります。THU-MAIC チームの論文「From MOOC to MAIC: Reimagine Online Teaching and Learning Through LLM-Driven Agents」は Journal of Computer Science and Technology 2026 年 1 月号（Vol.41, No.1）に掲載されており、JCST の論文ページでは、清華大学での予備的な実践に 500 名を超える学生が参加し、10 万件を超える学習行動ログが得られたと記載されています。教育現場での実証を経た設計思想が背景にある点は、単体のスライド生成ツールとの性格の違いにつながっています。

ローカル環境を構築せずに挙動を確認したい場合は、公式ライブデモ（open.maic.chat）が用意されています。README によれば、アクセスコードを取得することでホスト版をそのまま利用できます。技術選定の初期段階で「出力物のイメージを掴む」目的であれば、自己ホストの検討より先にこちらで確認する流れが現実的です。

OpenMAICが生成する「授業」の中身

採用判断で最初に確認すべきは、「どこまでが自動生成され、どこからが人の仕事として残るか」です。OpenMAIC はこの範囲が類似 OSS より明確に広く、それが選定上の最大の分岐点になります。

2 段階の生成パイプラインと入力素材

生成は Outline と Scenes の 2 段階で進みます。まず入力（トピックの記述や添付資料）を解析して構造化されたレッスンのアウトラインを生成し、次にアウトラインの各項目をシーンへ展開します。シーンはスライド・クイズ・インタラクティブモジュール・PBL のいずれかです。

入力として扱える素材は、PDF・Word・PowerPoint・表計算・テキスト・画像・音声・動画と幅広く用意されています。音声や動画は、設定した抽出プロバイダを経由してタイムスタンプ付きの文字起こしやキーフレームに変換されます。既存の研修資料や録画を資産として持っている組織にとっては、この入力の広さが移行コストに直結します。

4 種類の教室コンポーネント

生成される授業は、次の 4 種類の要素で構成されます。

• スライド: AI 教師がナレーションを付けて講義し、スポットライトやレーザーポインタの演出を伴います
• クイズ: 単一選択・複数選択・記述式に対応し、AI がリアルタイムで採点とフィードバックを行います
• インタラクティブシミュレーション: 物理シミュレータやフローチャートなど、HTML ベースの実験的なコンテンツです
• PBL: 学習者が役割を選び、マイルストーンと成果物を伴うプロジェクトに AI エージェントと取り組みます

スライドだけが欲しいのであれば、この後段の機能は使わない資産になります。逆に「理解度の確認」や「手を動かす演習」までを自動化したいのであれば、この範囲の広さが採用理由になります。

Deep Interactive Mode

v0.2.0 以降で追加された Deep Interactive Mode では、3D 可視化・シミュレーション・ゲーム・マインドマップ・オンラインプログラミングの 5 類型のインタラクティブ UI が生成されます。特徴的なのは、生成された UI を AI 教師が能動的に操作して学習者を誘導する点です。要素をハイライトしたり、条件を設定したり、ヒントを提示したりといった動作が説明と連動します。生成された UI はデスクトップ・タブレット・モバイルにレスポンシブ対応しています。

マルチエージェント対話とホワイトボード

授業中の対話は複数の形式が用意されています。エージェント側から議論を開始する Classroom Discussion、異なるペルソナのエージェントがホワイトボードの図解を伴って討論する Roundtable Debate、自由質問に AI 教師がスライドや図で応答する Q&A Mode などです。ホワイトボードは SVG ベースで、数式の段階的な解法やフローチャートの描画に対応しています。

これらの挙動は、内部的には 21 種類のアクション（発話、ホワイトボードへの描画・テキスト・図形・チャート、スポットライト、レーザーなど）を実行するエンジンによって表現されています。

エクスポートとオフライン再生

生成物は PowerPoint（.pptx）、Interactive HTML、教室全体をまとめた ZIP の 3 形式で書き出せます。.pptx には画像・チャート・LaTeX 数式が含まれ、編集可能な状態で出力されます。

イントラネットや閉域環境での利用を想定する場合に重要なのが、オフライン対応です。教室 ZIP やリソースパックのエクスポート時に、インタラクティブシーンが参照する外部アセット（KaTeX、Three.js とそのアドオン、Tailwind の CDN、Google Fonts、画像）が data: URI としてインライン化されます。インポート後は公開 CDN に接続せずに完全オフラインで再生できる設計です。ただし README には、この機能が追加される前にエクスポートされた教室は CDN を参照したままであり、再エクスポートが必要であると明記されています。過去の生成物を資産として抱えている場合は、この点を移行計画に織り込む必要があります。

OpenMAICのアーキテクチャと拡張ポイント

「アプリ全体を丸ごと採用するのか、一部だけ自社プロダクトに組み込むのか」は、採用形態を左右する論点です。OpenMAIC はこの選択肢が比較的はっきりしています。

技術スタックと中核モジュール

README のバッジおよび Key Architecture 節によれば、技術スタックは Next.js 16 / React 19 / TypeScript 5 / LangGraph 1.1 / Tailwind CSS 4 です。中核となるモジュールは次のように整理されています。

• lib/orchestration/ — LangGraph のステートマシンによるマルチエージェント統括（director graph）。エージェントのターンや議論を管理します
• lib/playback/ — 再生のステートマシン（idle → playing → live）
• lib/action/ — 前述の 21 種類のアクションを実行します
• lib/server/agent-runtime/ — PostgreSQL をバックエンドとするセッション管理（リース実行、resume / steer、スキル、素材、検証済みのコース操作ツール）

Next.js と TypeScript で構成されているため、同じスタックを採用しているチームであればコードリーディングの敷居は比較的低いと考えられます。

npm 公開されている @openmaic/* SDK

見落とされやすい拡張ポイントが、npm に公開されている SDK 群です。v0.3.0 で @openmaic/* ファミリーが npm へ公開されました。

これらが分離されているということは、「OpenMAIC のアプリをそのまま社内に立てる」以外に、「自社の既存アプリにスライドのレンダリングや生成パイプラインだけを組み込む」という採用経路が存在することを意味します。既に LMS や社内ポータルを持っていて、UI を置き換えたくないケースでは、この部分採用のほうが現実的な選択肢になります。

Agent Workbench（v1.0.0）

2026 年 8 月 27 日にリリースされた v1.0.0 では、チャット主導でカリキュラム計画からページ生成、改訂までを行う Agent Workbench が追加されました。サーバーバックの耐久セッション（PostgreSQL）に対応し、リースとハートビートによる管理、クラッシュ後の再開、キャンセル、実行中の追加指示（steering）が可能です。カリキュラム計画・ディープリサーチ・講義・ワークショップ・職業訓練といった 24 個の組み込みスキルが同梱され、ユーザー独自のスキルもオーナー単位で作成・保存できます。

設計上の特徴として、エージェントは不透明なデータの直接編集ではなく、検証済みのツール経由でのみ動作するとされています。ツールは計画・整理 / 構築・編集 / 素材利用 / メディア生成 / インポート・検査 / 教室設定の 6 カテゴリに分類されています。

運用上注意したいのは、有効化に明示的なフラグが必須である点です。NEXT_PUBLIC_PRO_WORKBENCH_ENABLED=true、OPENMAIC_AGENT_RUNTIME_ENABLED=true、DATABASE_URL の設定に加え、MODEL_ROUTES で maic-agent-driver をプロバイダ接頭辞付きのモデルへ明示的にルーティングする必要があります。README には、ここにフォールバックは意図的に設けていないと記載されています。フラグが無効の間は関連 API が 404 を返す仕様です。設定の取りこぼしが黙って別の挙動になるのではなく、明確に失敗する設計であり、運用側から見れば追いやすい方針といえます。

永続化層の差し替え

永続化はプラガブルな構成になっています。既定ではブラウザ側のストレージを使い、必要に応じて PostgreSQL や S3 に差し替えられます。小規模な検証ではデータベースを用意せずに始められる一方、複数人での利用や永続的なライブラリが必要になった段階で構成を切り替えられる設計です。

導入要件とセルフホストの選択肢

自己ホストの現実味を判断するには、最小構成で何が動き、どこから追加コンポーネントが必要になるかを切り分けておく必要があります。

最小構成

README の Quick Start では、前提条件として Node.js 22.19 以上、pnpm 10 以上が挙げられています。導入手順は次のとおりです。

git clone https://github.com/THU-MAIC/OpenMAIC.git
cd OpenMAIC
pnpm install

出典: THU-MAIC/OpenMAIC README — Quick Start

続いて cp .env.example .env.local で設定ファイルを用意し、LLM プロバイダのキーを最低 1 つ設定したうえで起動します。

pnpm dev

出典: THU-MAIC/OpenMAIC README — Quick Start

本番向けのビルドは pnpm build && pnpm start です。つまり、データベースも追加コンテナも用意せず、Node.js と pnpm と API キー 1 つだけで起動できる構成が最小ラインということになります。検証の初期コストは低い部類です。

対応プロバイダの広さ

モデルの調達先は、技術選定でしばしばボトルネックになる要素です。OpenMAIC の対応プロバイダは README に一覧されており、OpenAI、Azure OpenAI、Anthropic、Amazon Bedrock、Google Gemini、DeepSeek、Qwen、Kimi、MiniMax、Grok（xAI）、OpenRouter、TokenDance、Doubao、Tencent Hunyuan、Xiaomi MiMo、GLM（Zhipu）に加え、ローカル実行の Ollama、Lemonade、FunASR、そして任意の OpenAI 互換 API が挙げられています。

プロバイダの設定は .env.local と server-providers.yml の 2 経路があり、後者では YAML でプロバイダごとの API キーやモデルを宣言できます。Azure OpenAI と Amazon Bedrock に標準対応している点は、既存のクラウド契約に寄せたい企業利用では選定理由になりやすい要素です。データを外部に出せない要件があるなら、Lemonade（ローカルの OpenAI 互換プロバイダ。LLM・画像・TTS・ASR に対応し API キー不要）と FunASR（ローカル音声認識）を組み合わせる経路が README に示されています。

デプロイ経路

デプロイは Vercel へのワンクリックデプロイ（Deploy ボタン、またはフォークして Vercel にインポートする手順）と、Docker Compose による構成の 2 系統が案内されています。サーバーバックの永続化が必要な場合は、アプリと PostgreSQL の 2 コンテナ構成のプロファイルが用意されています。永続化用の HTTP サーバーはアプリ側に /api/persistence として組み込まれており、独立したサービスを別途立てる必要はありません。

なお Docker のビルド引数として ALPINE_MIRROR と NPM_REGISTRY が用意されていますが、README には認証情報を埋め込まないことが明記されています。社内ミラーを指定する際は注意が必要です。

オプション機能と無効時の挙動

追加コンポーネントを必要とする機能は、無効時にどう振る舞うかもあわせて README に書かれています。運用計画を立てるうえで有用な情報です。

オプションを一切使わない構成であれば、運用対象は Next.js アプリ 1 つと外部 API キーのみです。MP4 書き出しや永続化を有効にした瞬間に、コンテナとデータベースの運用が加わります。どこまで有効化するかは、運用体制の規模と直結する判断になります。

採用前に読むべきセキュリティと運用の前提

OpenMAIC の README には、認可モデルの現状について踏み込んだ記述があります。これは弱点の指摘というより、想定される配備形態を読者に正確に伝えるための情報であり、採用判断では最も重要な部分です。以下は README の記述を要約したものです。

ACCESS_CODE は未設定だと fail-open

デプロイ全体をサイトレベルのパスワードで保護する ACCESS_CODE という設定があります。README によれば、これが未設定の場合（.env.example の既定値）、middleware.ts は資格情報を検査せず、API を含むすべてのマッチ経路に到達可能です。README はこれを明示的に fail-open と表現し、二次的な強制ポイントは存在しないと記しています。

設定した場合は、署名付きトークンが HTTP-only クッキーに 7 日間保存され、有効期限はサーバー側で強制されます。ただし検証のレート制限は TRUST_PROXY_HEADERS=true が設定されている場合にのみ有効で、x-forwarded-for / x-real-ip を上書きする信頼済みリバースプロキシの配下で、クライアントごとに 60 秒あたり 10 回の制限がかかります。信頼済みプロキシが無い環境ではリクエストをクライアントに紐づけられないため、スロットルはまったく働きません。README はランダム生成された 16 文字以上のコードを使うよう推奨しています。

永続化トークンは秘密として機能しない

NEXT_PUBLIC_PERSISTENCE_TOKEN は、名前のとおり公開 JavaScript バンドルにコンパイルされ、すべての訪問者から参照可能です。README はこれについて、機密性もユーザー分離も提供しないと明記しています。さらに文書やアセットのリクエストはその認証器をスキップする実装であることも記載されています。

文書の読み取りは capability-by-id

文書のオーナーは 30 日間有効な匿名クッキーで識別されます。README によれば、ステージのメタデータが存在し tombstone されていない限り、読み取りはオーナー確認なしに許可されます。つまり、エンドポイントに到達でき、かつ stage id を知っている者はそのコースを読めるという設計です。書き込みと削除についてはクッキーに対するオーナー確認が行われます。

README はこれらを踏まえ、想定用途は localhost または信頼済みネットワークでの単一ユーザー配備であるとし、本番投入前に lib/persistence/server-auth.ts を、サーバー制御の ID から学習者パーティションを導出する実際のセッション検証に置き換え、文書・マージ・管理の認可ポリシーを見直すことを明示的に求めています。

この記述の意味するところは明快です。社内の信頼済みネットワークで限定的に使うのであれば README どおりの構成で始められますが、不特定多数の受講者に公開する用途では、認可レイヤーの追加実装が前提になります。この工数を見積もりに入れているかどうかが、採用判断の分かれ目になります。

アセットの GC とクォータ

ストレージ面では、オフラインのコレクタが既定で稼働します。収集間隔は ASSET_COLLECTION_INTERVAL_MS（既定 15 分）で、エントリの解放とバイトの削除という 2 段階に分かれ、各段階に ASSET_COLLECTION_GRACE_MS（既定 1 時間）の猶予が設けられています。最悪のケースでは猶予 2 回分が実削除までの窓になります。削除したメディアの実質的な保持期間として把握しておくべき値です。

クォータは ASSET_QUOTA_BYTES が既定 10 GiB ですが、README には現状すべての呼び出し元が単一のプリンシパルを共有するため、これはユーザー単位ではなくデプロイ全体の上限であると記載されています。複数部署での共用を想定するなら、この値の意味を取り違えないようにする必要があります。なお、不正な設定値はデフォルトで置き換えられるのではなく、プロセスの起動を停止させる設計です。

リリース速度と再ライセンスの経緯

更新の活発さは健全性の指標であると同時に、追従コストでもあります。README の News を追うと、v0.1.0 が 2026 年 3 月 26 日、v0.2.0 が 4 月 20 日、v0.3.0 が 6 月 28 日、v1.0.0 が 8 月 27 日と、約半年でメジャーリリースに到達しています。リリース履歴の詳細は公式 CHANGELOG で確認できます。機能追加は速い反面、仕様変動のリスクも相応にあると見るのが妥当です。長期運用を前提にするなら、バージョンを固定して計画的に追従する運用設計が現実的でしょう。

ライセンス面では、v0.3.0（2026 年 6 月 28 日）で AGPL-3.0 から MIT へ再ライセンスされた経緯があります。現在は MIT であり、README の Partnerships 節には MIT ライセンスのため商用利用が無償で許可される旨が記載されています。ただし、これ以前のバージョンを参照した情報や派生物を扱う際には、ライセンスが異なる時期があったことを念頭に置く必要があります。

より詳細な使い方は、公式ユーザーガイド（v1.0.0・英語版）が公開されています。

類似OSSとの違い｜Presenton・PPTAgent・open-notebookと比較する

「AI で教材を生成する OSS」というくくりでは複数の選択肢が挙がりますが、それぞれ出口が大きく異なります。以下は GitHub API で取得した 2026 年 9 月 28 日時点のメタデータです。

Presenton — スライド成果物に特化

presenton/presenton は、オープンソースの AI プレゼンテーション生成ツールおよび API です。成果物は編集可能な PPTX / PDF で、生成 API やデスクトップアプリ、クラウド版を備えています。

OpenMAIC も PPTX の書き出しを持っていますが、Presenton は「良いスライドを作って渡す」ところに最適化されており、授業の再生、AI 教師の発話、クイズの採点、PBL といった学習体験の実行環境は持ちません。必要なのが営業資料や社内共有用のスライドであれば、Presenton のほうが構成はシンプルで、運用対象も少なく済みます。ライセンスも Apache-2.0 で異なります。Presenton 単体についてはAIでプレゼンを自動生成するOSS「presenton」の仕組みと特徴で解説しています。

PPTAgent — 生成に加えて「評価」を扱う研究寄りのフレームワーク

icip-cas/PPTAgent は、リフレクティブな PowerPoint 生成のためのエージェントフレームワークです。生成だけでなく、生成物の品質評価（PPTEval）を扱う点が特徴で、参照スライドを元にした編集ベースの生成というアプローチを採ります。

Python 実装であり、Web アプリケーションとしての教室配信機能は持ちません。生成品質そのものを研究・改善したい、あるいは既存のスライドテンプレートを起点に大量生成したいといった用途に近く、OpenMAIC の DSL ベースの生成パイプラインとは設計思想が異なります。

open-notebook — 入口は似ているが出口が「理解支援」

lfnovo/open-notebook は NotebookLM のオープンソース実装です。資料を投入するという入口は OpenMAIC と似ていますが、出口は資料の要約・対話・音声化であり、理解支援に軸足があります。

「手元の資料を読み込ませて理解を深めたい」というニーズであれば、授業の生成と再生という重い仕組みを持たない open-notebook のほうが目的に直結します。逆に、資料を他者に教えるための教材へ変換したいのであれば OpenMAIC の領域です。スター数は OpenMAIC と近い水準にありますが、解く課題が異なるため、直接の代替にはなりません。

MAIC-UI — 同チームの生成 UI 特化プロジェクト

THU-MAIC/MAIC-UI は、同じ THU-MAIC チームによる生成 UI 特化のプロジェクトです。OpenMAIC の README でも、より高品質な教育用 UI の生成を求める場合の案内先として言及されています。

ただし、スター数は 168、最終プッシュは 2026 年 5 月 6 日、ライセンスは未設定という状態です。ライセンスが明示されていないリポジトリは、既定では著作権法上の制約がそのまま適用され、利用条件が不明瞭になります。企業利用を前提に検討する場合は、OpenMAIC 本体とは成熟度も利用条件も異なることを踏まえた判断が必要です。

比較のまとめ

選択肢の切り分けは、「欲しいのは資料か、学習体験か、理解支援か」という問いに集約できます。資料が欲しいなら Presenton、生成品質の研究と評価なら PPTAgent、資料の理解支援なら open-notebook、そして評価や演習まで含む学習体験そのものを組み立てたいなら OpenMAIC、という整理になります。OpenMAIC のスター数の多さは機能範囲の広さと表裏一体であり、必要のない領域まで含めて抱え込むことにもなり得ます。

OpenMAICの採用を判断するチェックポイント

ここまでの事実を、採用判断の分岐として整理します。いずれも優劣ではなく、自社の要件に照らして選び取るための軸です。

1. 必要な出力範囲はどこまでか

スライドだけで足りるのか、クイズによる理解度確認や PBL の演習まで必要か。前者であればスライド特化の OSS のほうが構成も運用も軽くなります。後者であれば、授業一式を生成し再生環境まで備える OpenMAIC の設計が要件に合致します。

2. 配備形態は信頼済みネットワーク内か、不特定多数への公開か

README が想定用途として挙げているのは、localhost または信頼済みネットワークでの単一ユーザー配備です。不特定多数の受講者に公開する場合は、lib/persistence/server-auth.ts の置き換えを含む認可の追加実装が前提になります。この工数を見積もりに含められるかどうかが最初の関門です。

3. 利用したいモデル調達先が対応リストにあるか

Azure OpenAI や Amazon Bedrock を含む主要クラウドプロバイダに対応しており、OpenAI 互換 API も扱えます。データを外部へ出せない要件がある場合は、Ollama や Lemonade、FunASR によるローカル完結の経路が用意されているかを確認ポイントにできます。

4. 追加コンポーネントを運用できる体制があるか

最小構成は Node.js アプリ 1 つで済みますが、MP4 書き出しには render-service コンテナが、サーバーバック永続化には PostgreSQL が加わります。アセットのクォータ（既定 10 GiB）がデプロイ全体の上限である点も、共用を想定するなら設計段階で織り込む必要があります。

5. アプリ全体を採用するか、SDK として部分利用するか

@openmaic/* の各パッケージが npm に公開されているため、既存の社内システムにスライドのレンダリングや生成パイプラインだけを組み込む経路があります。UI や認証を自社側で持ちたい場合は、この部分採用のほうが現実的です。

6. 高頻度のリリースに追従できるか

2026 年 3 月の v0.1.0 から約半年で v1.0.0 に到達しており、更新は活発です。最新機能を追い続けるのか、バージョンを固定して計画的に更新するのか、運用方針を先に決めておくと、後の判断がぶれません。

これらのうち 2 番目と 4 番目は、動かす前の段階で見積もりに差が出やすい項目です。まずは公式ライブデモで出力物の質を確認し、要件に合いそうであれば README のセキュリティ節を読み込んだうえで PoC の範囲を決める、という順序が手戻りの少ない進め方といえます。

関連情報

社内向けの学習基盤や AI を活用したシステムの開発をご検討中の方は、お問い合わせフォームからご相談ください。要件の整理段階からご相談いただけます。

AI・LLM 領域の開発案件に関わりたいエンジニアの方は、フリーランスエンジニア向け案件ポータル Workee で、スキルや希望条件に合致する案件をお探しいただけます。

出典・参考リンク

• THU-MAIC/OpenMAIC（GitHub リポジトリ・README）
• OpenMAIC 公式ライブデモ（open.maic.chat）
• OpenMAIC 公式ユーザーガイド（v1.0.0・英語版）
• OpenMAIC CHANGELOG
• From MOOC to MAIC: Reimagine Online Teaching and Learning T…
• presenton/presenton
• icip-cas/PPTAgent
• lfnovo/open-notebook
• THU-MAIC/MAIC-UI

※ 本記事のリポジトリメタデータ（スター数・フォーク数・ライセンス・最終プッシュ日）は、GitHub API から 2026 年 9 月 28 日時点で取得した値です。