La Suite Docsを共同編集とセルフホスティングの境界から見る
Docs はオープンソースのテキスト エディターです。Web ネイティブで、リアルタイムのコラボレーション用に作られており、データの完全な所有権を持つ、きれいに構造化されたドキュメントとサブドキュメントです。 Django と React を使用して拡張できるように構築されています。
ひと目でわかる
- これは何？
- DjangoとReactで構成された文書エディタについて、編集機能、AI連携、API、Docker開発、GPL依存の扱いをREADMEから確認します。
- 誰に向いている？
- 向いているのは、文書を自分の環境で管理し、複数人の編集や階層化された知識共有を必要とする組織です。PDF出力などGPL依存機能のライセンスをMIT配布物に含められない場合は構成の選択が必要です。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
文書を知識へ変える共同編集器
La Suite Docsは、NotionやGoogle Docsの代替としてREADMEに位置づけられたオープンソースのテキストエディタです。リアルタイム共同編集、構造化された文書とサブ文書、知識の整理、データ所有権、セルフホスティングを中心にしています。メタデータではウェブ向けで、DjangoとReactを使うPythonプロジェクトと説明されています。
公開組織、企業、オープンなコミュニティを対象にした説明ですが、特定の規模や性能値はREADMEにありません。自分で運用する場合は、共同編集の体験だけでなく、保存先、ユーザー権限、バックアップ、外部APIの境界を導入条件として確認する必要があります。
編集、階層化、プレゼンテーション
編集機能にはリッチテキストとMarkdown、スラッシュコマンド、ブロックシステム、オフライン編集があります。共同作業ではライブカーソル、プレゼンス、コメント、共有、細かなアクセス制御が案内されています。サブページと階層で文書を整理でき、検索もできます。
プレゼンテーションは`---`区切りを基礎にし、全画面表示、PDF出力、キーボード操作、ブロックからの開始、共有用リンクを備えます。`.docx`と`.md`を取り込み、`.docx`、`.odt`、`.pdf`へ書き出せます。READMEの機能一覧を運用要件に変えるには、実際の長文、権限制御、オフライン復帰、出力後のレイアウトを個別に試す必要があります。
選択範囲から文書全体へ広がるAI
AI機能は任意で、モデルやゲートウェイに依存しない構成とREADMEは説明しています。設定に必要なのはAPIキーとURLです。V1は選択範囲を文脈と指示として扱い、AIの結果で選択箇所を置き換えます。Docsの書式に合わせる設計です。
V2はベータ版で、BlockNote AIの統合によるAIツールバーとAIカーソルを提供します。AIカーソルは別の共同編集者のように文書へ作用し、選択範囲に加えて文書全体の文脈を使います。READMEは特定のプロバイダーや初期有効状態を示していません。APIへ送る文章、権限、ログを決めてから機能を有効にするべきです。
Meet連携を支える二つのAPI
Docsにはresource server APIとserver to server APIがあり、READMEは相互運用の入口として案内しています。具体例はMeetの文字起こしです。`DJANGO_SERVER_TO_SERVER_API_TOKENS`を設定すると、Meetの文字起こしをDocsへ送り、依頼したユーザーにアクセス権を与える構成が示されています。
詳細なエンドポイントや認証方式は`documentation/resource_server.md`と環境変数ドキュメントへ分かれています。READMEにある変数名だけで接続仕様を確定してはいけません。連携を試すなら、テスト用ユーザーで文字起こしの送信、生成文書の所有者、共有範囲、トークンの失効手順を確認します。
Docker ComposeとGNU Makeの開発手順
セルフホスティングはKubernetes、Docker Compose、Nix、YunoHostなどが案内され、詳細はインストールガイドへリンクされています。開発用の前提はDocker、Docker Compose、GNU Makeです。`make bootstrap FLUSH_ARGS='--no-input'`はapp-devとfrontend-devの構築、依存関係の導入、DBマイグレーション、翻訳コンパイルを行い、`make run`でサービスを起動します。開発URLは`https://localhost:3000`です。
開発用の既定認証情報は`impress`と`impress`で、MinioをS3互換ストレージとして使います。READMEはこの構成を開発とテスト専用と明記しています。フロントエンド単独なら`make frontend-development-install`と`make run-frontend-development`、バックエンドだけなら`make run-backend`を使えます。
MIT配布物とGPL機能を分ける
Docs本体はMITライセンスです。一方、PDFエクスポートなどの高度な機能はBlockNoteのXLパッケージに依存し、それらはGPLでMIT互換ではないとREADMEが警告しています。`PUBLISH_AS_MIT=true`でビルドすると、非MIT機能を含まないイメージを作れます。
これは単なるビルドフラグではなく、配布条件と機能範囲を選ぶ設定です。PDFが必須なら依存パッケージのライセンスと配布方法を確認し、MITだけの構成が必要なら出力機能が外れることを受け入れてテストします。MITライセンスも保証やSLAを提供するものではないため、バックアップ、更新、認証、AIプロバイダーの責任分界は別途決める必要があります。
開発用Minioから本番条件を切り分ける
ローカル検証は`make bootstrap FLUSH_ARGS='--no-input'`、`make run`で起動し、`https://localhost:3000`へアクセスします。開発用の`impress`と`impress`でログインした後、二人のユーザーで同じ文書を開き、ライブカーソル、コメント、アクセス制御を順に試します。
次に`---`で区切った文書をプレゼンテーションとして開き、`.docx`、`.md`の取り込みと`.docx`、`.odt`、`.pdf`の出力を確認します。`PUBLISH_AS_MIT=true`で作ったイメージではPDF機能がどう変わるかを記録します。Minioと既定認証情報は開発用なので、本番のS3、認証、保存先へそのまま持ち込まない切り分けが必要です。フロントエンドのテストは`make frontend-test`、Lintは`make frontend-lint`で実行できます。管理者画面は`http://localhost:8071/admin`で、開発用のスーパーユーザー作成には`make superuser`を使います。
編集部の結論
向いているのは、文書を自分の環境で管理し、複数人の編集や階層化された知識共有を必要とする組織です。PDF出力などGPL依存機能のライセンスをMIT配布物に含められない場合は構成の選択が必要です。最初に開発用の`make bootstrap FLUSH_ARGS='--no-input'`と`make run`を実行し、認証情報、保存先、必要な機能のライセンスを確認してください。
コミュニティノート