コードとしてのドキュメントとマネージドプラットフォーム
"コードとしてのドキュメント" — あなたのドキュメントはGitにあり、プルリクエストを通じてレビューされ、CIを通じてデプロイされる — はエンジニア主導の企業での支配的なパターンです。"マネージドプラットフォーム" — あなたはログインし、設定し、出荷する — はデザイン主導およびインディ企業での支配的なパターンです。どちらも機能します。どちらも異なる方法で失敗します。
これが2026年の正直なトレードオフです。
要点#
| コードとしてのドキュメント | 管理されたプラットフォーム | |
|---|---|---|
| ドキュメントの所在 | Git | プラットフォームのDBまたはGit |
| 編集 | IDEでのMarkdown、PRレビュー | ウェブエディタまたはMarkdown |
| デプロイメント | CI/CDパイプライン | プッシュして忘れる |
| ホスティング | あなたのもの | 彼らのもの |
| メンテナンス | あなたのエンジニアリング時間 | ベンダーの時間 |
| AI機能 | あなたが構築または統合する | 組み込み |
| コスト形状 | エンジニアリング時間 | サブスクリプション |
| 最適な用途 | エンジニア主導、OSS、深いカスタマイズ | スタートアップ、インディー、「今すぐ出荷」 |
Docsbookは、Git（あなたのリポジトリ）にソースファイルがあり、その他はすべて管理されているため、興味深いです。
「コードとしてのドキュメント」が勝つとき#
ドキュメントをコードとして扱うことが依然として正しいパターンである三つの理由：
1. エンジニアリングはすでにGitに存在する#
ドキュメント作成者がエンジニアであれば、ドキュメントのためにGitを使用する際の認知的負担はゼロです。プルリクエスト、コードレビュー、ブランチプレビュー — すべての既存のエンジニアリングワークフローは自然に拡張されます。
2. バージョニングはコードリリースと一致します#
コード変更と共に出荷されるドキュメントの変更は、同じPRに含めるべきです。レビュアーはAPIの変更とドキュメントの変更を一緒に確認します。CIは両方をテストします。
3. 大規模なカスタマイズが必要#
ドキュメントにReactコンポーネント、カスタムMarkdown拡張、またはOpenAPI仕様からページを生成するビルドパイプラインが必要な場合、Docusaurus、Nextra、またはVitePressを使用したドキュメント・アズ・コードが適切なパターンです。
「マネージドプラットフォーム」が勝つとき#
マネージドが勝つ三つの理由：
1. ドキュメント作成者はエンジニアではない#
プロダクトマーケター、サポートチームのメンバー、CSリードはしばしばドキュメントを更新する必要があります。彼らにGitリポジトリにマークダウンをPRするように頼むことは、更新を妨げる摩擦を生み出します。ウェブエディタの方が速いです。
2. AI機能が必要であり、あなたのチームはそれらを構築しません#
AIチャット、AI翻訳、MCP、llms.txt、分析を含む管理されたプラットフォームは、機能ごとに3〜6人週のエンジニア作業を節約します。ほとんどのチームは、その作業をドキュメントのために正当化できません。
3. デプロイメントの所有権はオーバーヘッドであり、価値ではない#
Docusaurusのデプロイメントを維持するには、平均して四半期ごとに1〜2日のエンジニアリング作業が必要です。これは、年間で5〜10日の作業であり、ユーザーに価値を提供しません。管理されたプラットフォームでは、この数値はゼロになります。
ハイブリッド: Docsbook#
Docsbookは、どちらのカテゴリにもきれいに収まらないため、特異です。
- 真実の源はあなたのGitHubリポジトリです (docs-as-codeプロパティ)
- ホスティング、AI、検索、翻訳、分析、MCPは管理されています (managed-platformプロパティ)
- CI/CDパイプラインはありません、
docusaurus.config.js、スウィズルはありません (managed-platformプロパティ) - PRとレビューは同じように機能します (docs-as-codeプロパティ)
- ベンダーロックインはありません — あなたが去るとき、あなたのファイルはGitHubに残ります (docs-as-codeプロパティ)
このパターンは重要です。なぜなら、純粋なdocs-as-code（デプロイメントの負担）と純粋な管理（ベンダーロックイン）の失敗モードが相殺されるからです。
コスト計算#
典型的な5人のエンジニアのスタートアップの24ヶ月の総所有コストを比較してみましょう。
純粋なドキュメントとしてのコード（Vercel上のDocusaurus）#
| 項目 | 24ヶ月のコスト |
|---|---|
| Vercel Pro | $480 |
| 初期設定 | 16時間 × $100/時 = $1,600 |
| メジャーバージョンの移行（24ヶ月で2回） | 40時間 × $100/時 = $4,000 |
| 四半期ごとのメンテナンス | 16時間 × $100/時 = $1,600 |
| AIチャットの追加（構築） | 80時間 × $100/時 = $8,000 |
| AIチャットの追加（運用、24ヶ月） | $200/月 × 24 = $4,800 |
| Algolia DocSearchの追加 | $0–60/月 × 24 = $0–1,440 |
| 翻訳パイプラインの追加 | $0（スキップ、費用が高すぎる） |
| 合計 | $20,920 + 翻訳なし |
Docsbook PRO+（すべて含む）#
| 項目 | 24ヶ月のコスト |
|---|---|
| PRO+ サブスクリプション | $59/月 × 24 = $1,416 |
| 初期設定 | 0.5時間 × $100/時間 = $50 |
| メンテナンス | $0 |
| 合計 | $1,466 + AIチャット、翻訳、MCP、分析 |
コストの差は大きいです。エンジニアリング時間が主要な項目です。
Docsbook PRO (生涯)#
| 項目 | 24ヶ月のコスト |
|---|---|
| PRO生涯 | $150 一度 |
| 初期設定 | 0.5時間 × $100/時 = $50 |
| 合計 | $200 + AIチャット (200 q/月)、翻訳 (50/月)、カスタムドメイン |
これはインディーハッカーの数学です。
コストの計算が逆転する時#
ドキュメントをコードとして扱うことが安価になる3つのシナリオ：
- エンジニアの時間が無料 — ドキュメントプラットフォーム専任のエンジニアがいる; 彼らの給与は関係なく支払われる
- コミュニティの貢献者によるOSS — コミュニティのPRがメンテナンスの負担を吸収する
- ドキュメント内のカスタムReactコンポーネント — 管理されたプラットフォームではこれを行うことはできない
これらのケースでは、DocusaurusまたはVitePressが正しい答えです。そうでなければ、計算は管理された方に有利です。
ベンダーロックイン：評価方法#
管理されたプラットフォームに尋ねるべき3つの質問：
- 今すぐコンテンツをプレーンマークダウンとしてエクスポートできますか？ はいの場合、ロックインは低いです。
- 移動した場合、URLは維持されますか？ ほとんどはURLの保持を許可しますが、一部はそうではありません。
- キャンセルした場合、カスタムドメインはどうなりますか？ 取得可能であるべきです。
Docsbookはすべての項目で高評価です：ファイルはあなたのGitHubリポジトリにあります（エクスポート = git clone）、URLはファイルパスと一致します（保持 = リダイレクト）、カスタムドメインはあなたが管理するDNSレコードです。
GitBookは最初の項目で評価が低く（コンテンツは彼らのDBにあります）、他の項目では良好です。Mintlifyはすべての項目で高評価です。
意思決定ルール#
- エンジニア主導、OSS、カスタマイズ重視 → コードとしてのドキュメント (Docusaurus, VitePress, Nextra)
- インディー、スタートアップ、「今すぐ出荷」 → マネージドプラットフォーム (Docsbook, Mintlify)
- 30人以上の編集者を持つエンタープライズ → マネージドエンタープライズ (GitBook)
- ハイブリッドを望む → Docsbook (Gitソース、その他はすべて管理)
関連文献#
Docsbookはハイブリッドです：Gitソース、管理されたAI/SEO/翻訳/MCP。PROは$150の生涯プランです。あなたのリポジトリで見る →