Synthadoc v1.3.1：取り込み時にMarkdown Wikiを合成する
Synthadoc: 生のドキュメントを構造化されたローカルファーストの Wiki に変換する、オープンソースの LLM ナレッジ編集エンジンです。従来の RAG に代わる、透明で人間が判読できる代替手段であり、ツールを使用せずに自己管理および自己改善が可能です。
ひと目でわかる
- これは何？
- axoviq-ai/synthadocはPDFやWebページなどの生ソースをLLMで構造化Wikiへ変換し、引用・矛盾・孤立ページをMarkdownとしてローカル保存するPythonエンジンです。
- 誰に向いている？
- 調査資料を検索時ではなく取り込み時にWiki化し、引用付きMarkdownをgit管理したい人に向きます。クラウドRAGだけで済ませたい人や、READMEにないインストール手順を素材なしで再現したい人には向きません。
- 商用利用できる？
- 厳しい条件付きでできます。AGPL-3.0 はネットワーク型コピーレフトのライセンスで、改変版をホスティングサービスなどとしてネットワーク越しに利用させる場合、その利用者にソースコードを同じライセンスで提供する必要があります。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月19日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
クエリ時ではなく取り込み時に合成
Synthadoc Community Edition v1.3.1はREADME上「Domain-agnostic LLM wiki engine」です。多くのナレッジツールがクエリ時に検索・要約するのに対し、Synthadocはingest timeに知識をコンパイルするとREADMEは説明します。新しいソースが追加されるたびにコーパス全体へクロスリンクが張られ、チャンクを末尾追加するだけではない、という設計思想です。
Andrej KarpathyのLLM Wiki gistをREADMEが引用し、「LLMがWikiを維持できるべき」という方向性を示します。出力はローカルMarkdownファイルで、ツールを止めても読める成果物がWiki本体、というREADMEの位置づけです。
PDFから.jsonlまで読む入力形式
READMEはSynthadocがPDF、スプレッドシート、PPT、Webページ、画像、動画、Word、TXT、AIセッションtranscript（.jsonl）を読み、LLMで永続的な構造化Wikiへ合成すると述べます。クロスリファレンスは自動生成、矛盾は検出して表面化、orphan pagesはフラグ付け、各回答はソースを引用するとREADMEが列挙します。
Obsidianや既存のMarkdown Wikiへファイルとして統合できる、とREADMEは説明します。クラウドアカウント不要、ベンダーロックインなし、Markdownを任意エディタやgitで扱える点もREADMEの訴求です。具体的な変換パイプラインの内部実装はREADMEになく、synthadoc/agentsやsynthadoc/skillsディレクトリが存在することだけがリンクから分かります。
READMEは「self-managed and self-improved without the use of any tools」とdescription/metaにもあり、外部SaaSなしでWikiを維持できる方向性を示します。star1113、fork123、6 open issuesは2026年8月取得時点のGitHub値です。
CLI・Obsidian・Web UI・MCPの四界面
READMEの動画リンクは「Four Interfaces: CLI, Obsidian, Web UI & MCP」を示します。Obsidian向けプラグインはobsidian-pluginディレクトリ、MCP接続手順はdocs/user-quick-start-guide.md#appendix-i--connect-claude-via-mcpがREADMEの目次から参照されます。
Agentic Maintenance Workflowのデモ動画もREADMEが案内し、hooks/ディレクトリへのリンクからCI/CD連携を想定していることが読み取れます。各界面で同じWiki Markdownを操作する設計ですが、界面ごとの機能差や必要ポートはREADME本文だけでは確定せず、user-quick-start-guide.mdを読む必要があります。
READMEの動画「From Documents to Wiki」「Agentic Maintenance Workflow」は、取り込みから保守までの流れを視覚的に示しますが、性能数値は含みません。MCP接続はClaude向けappendixとしてREADME目次がdocs/user-quick-start-guide.mdを指します。
チーム規模別の想定ユースケース
Who Is It For?表は、1〜2人の個人研究Wiki、3〜20人の部門KB、中〜大規模のコンプライアンス重視ローカルWikiをREADMEが分けます。小規模はGemini FlashやローカルOllamaで継続コストゼロをREADMEが例示し、中規模は矛盾解消と自律スケール、大規模は部門別ポート、ingest/コスト監査、hook、OpenTelemetryをREADMEが挙げます。
これらはREADME上の典型例であり、実際のコストや精度はモデル選定とデータ品質に依存します。Medium/enterprise行の監査要件を満たすかは、生成されたaudit trailの形式をAquaFlow例などで確認する必要があります。
AquaFlow例とdocs/design.md
READMEはdocs/example/aquaflow/README.mdをEnd-to-end Exampleとしてリンクし、AquaFlow Capital M&A due diligence walkthroughを示します。Customizationはdocs/design.md#customizationへ委ねられています。
導入判断では、このAquaFlow例と同種のPDFセットを少数用意し、生成Wikiの引用が元ファイルの段落に戻れるか、矛盾フラグが意味のある差分を指すかを確認するのがREADMEが示す評価軸に近いです。design.mdにスキーマやhookの拡張点が書かれているかはREADMEだけでは分からず、リポジトリ内ドキュメントを直接開く必要があります。
インストール節がREADME素材外の理由
取得したREADME素材（7015文字）はInstallation節の直前で切れており、pip install等の具体コマンドは素材内に存在しません。README目次はInstallation、Quick-Start Guide、Creating Your Own Wiki、Configuration、Command Reference by Use Case、Administrative Reference、Understanding Logs and the Audit Trailを指します。
したがってCLI導入の一次情報はdocs/user-quick-start-guide.mdとリポジトリのCI workflow（.github/workflows/ci.yml）側です。素材不足のため、ここではコマンドを創作せず、Quick-Start Guideを読んでから隔離環境で実行する手順を推奨します。
AGPL-3.0とv1.3.1リリース
ライセンスはAGPL-3.0です。ネットワーク越しに改変版を提供する場合、ソース提供義務が発生し得るため、社内Wikiホスト形態を法務と確認する必要があります。Community Edition v1.3.1はREADMEヘッダーとReleases tag v1.3.1が一致します。
star数1113、fork123、Python言語、defaultBranch mainはGitHubメタデータです。導入後はUnderstanding Logs and the Audit Trail節（README目次）に沿ってingestログとコストイベントを保存し、引用欠落やorphanフラグが増えた版で差分レビューできる状態を作るのが、READMEが想定する運用に沿います。
OpenTelemetryとhookによるCI/CD
Medium/enterprise行はingestとコストイベントのaudit trail、hook systemによるCI/CD統合、OpenTelemetryによるops dashboardをREADMEが挙げます。hooks/ディレクトリへのリンクは、Wiki生成パイプラインをリポジトリイベントに接続する拡張点を示します。
具体的なhook名やOTel exporter設定はREADME素材になく、Administrative Reference（目次）とリポジトリ内hooks/READMEを直接確認する必要があります。導入時は少数ソースでingestし、audit trailファイルがコストとソースIDを結びつけるかを目視してください。
docs/example/aquaflow/README.mdの手順に沿って少数PDFをingestした後、生成Markdown内の引用リンクが元PDFのページ番号へ戻るか、contradictionフラグが異なる数値主張を指すかを人手でチェックしてください。Community Edition v1.3.1のtagと手元のsynthadoc --version（Quick-Start Guide記載コマンド）を対に記録します。
READMEバッジはsynthadoc/agentsとsynthadoc/skillsへのリンクを含み、エージェントとスキル定義がリポジトリ内にバンドルされていることを示します。Agentic Maintenance Workflow動画は、生成後Wikiをエージェントが保守する流れを示唆しますが、エージェント数や実行コストはREADMEに数値がありません。
Community Edition v1.3.1でAquaFlow例（docs/example/aquaflow/README.md）を再現する際、ingestログ（Understanding Logs and the Audit Trail節）にソースファイル名とトークン使用量が残るかを確認し、orphan pageフラグが増えた場合はsynthadoc/skills内の該当スキル名をメモしてください。
Who Is It For?表の1〜2人向け例はGemini FlashやローカルOllamaで運用コストを抑える想定です。部門KB（3〜20人）や監査を要する大規模Wikiはaudit trailとOpenTelemetryをREADMEが条件に挙げます。取得素材にpipコマンドが無いため、docs/user-quick-start-guide.mdのInstallation節を読んでから隔離環境で実行してください。AGPL-3.0のCommunity Edition v1.3.1を社内Web UIとして公開する場合、改変ソースの開示義務がLICENSE本文に沿うかを法務と確認します。
編集部の結論
調査資料を検索時ではなく取り込み時にWiki化し、引用付きMarkdownをgit管理したい人に向きます。クラウドRAGだけで済ませたい人や、READMEにないインストール手順を素材なしで再現したい人には向きません。docs/user-quick-start-guide.mdとdocs/example/aquaflow/README.mdを読み、少数PDFでWiki生成後に引用リンクと矛盾フラグを目視確認してください。
コミュニティノート