WordPressからDocusaurusへ - 静的サイト移行で得た執筆体験の改善とコスト削減
どうも、Shinyaです。この記事では、Amazon Lightsail上で運用していたWordPressサイトをDocusaurusベースの静的サイトへ移行した経緯と、採用した技術構成について解説します。
- WordPressの運用に課題を感じている人
- 静的サイトジェネレーターへの移行を検討している人
- Docusaurusでブログを構築したい人
- AWSサービスを活用したCI/CDパイプラインに興味がある人
- AIツールを執筆ワークフローに統合したい人
WordPressで運用する中で見えた課題
WordPressでブログをしばらく運用した結果、以下の課題が明確になりました。
執筆体験の問題
- Markdownサポートの不足: プラグインを導入してもMarkdownの執筆体験が改善されず、エディタ上での記述が制限される
- Gutenberg Editorの動作: ブロックエディタの動作が重く、執筆時のレスポンスに影響がある
- 管理画面へのログイン: 記事を書くたびにWeb管理画面にログインする必要があり、執筆開始までのステップが多い
- 記事のポータビリティ: 執筆した記事がWordPress独自の形式に依存し、他のプラットフォームへの移行が困難
開発・カスタマイズの問題
- 開発言語がPHP: 独自テーマやカスタマイズにはPHPの知識が必要で、普段TypeScriptやPythonを使用している開発者にとってはスイッチングコストが高い
- AIツールとの統合: エディタ上でのAI統合が限定的で、Claude Codeのような高性能なAIツールをシームレスに活用できない
コストの問題
- Amazon Lightsailの固定費: WordPressの運用のみを目的とした場合、Amazon Lightsailのインスタンス維持コストが過剰に感じられる
移行先に求めた要件
上記の課題を踏まえて、移行先のプラットフォームに以下の要件を設定しました。
| 要件 | 詳細 |
|---|---|
| 静的サイトベース | ブログに高機能なCMSは不要なため、パフォーマンスに優れる静的サイトを採用 |
| TypeScriptで開発可能 | Web開発で広く使用されているTypeScriptで開発・カスタマイズが可能 |
| Markdown/MDX対応 | Markdown・MDXで記事を執筆でき、リポジトリでバージョン管理が可能 |
| IDEで執筆可能 | VSCodeやKiro IDEなど任意のエディタで執筆でき、管理画面へのログインが不要 |
| AWSサービスとの統合 | Amazon BedrockやAWS CodeBuildなど各種AWSサービスとの連携が可能 |
| AIツールとの連携 | Claude Codeなどのツールを執筆ワークフローに統合可能 |
静的サイトへの移行により、ターミナル上で記事の執筆から公開までを完結できます。特定の管理画面にログインする必要がなく、普段の開発環境をそのまま執筆環境として使用できます。
Docusaurusを採用した理由
静的サイトジェネレーターの中から、Docusaurusを採用しました。
Docusaurusの特徴
- Meta社が開発・メンテナンス: Meta Open Sourceが開発元であり、継続的なメンテナンスが期待できる
- Markdown/MDXネイティブ対応: 記事をMarkdownおよびMDXで記述でき、Reactコンポーネントの埋め込みも可能
- ドキュメント機能が充実: ブログだけでなく、ドキュメントサイトに必要な機能（バージョニング、検索、多言語対応など）が標準で実装されている
- Algolia DocSearchとの統合: 高性能な全文検索をシームレスに導入可能
- IDE上で執筆可能: Markdown/MDXファイルを直接編集するため、任意のエディタやAIツールと連携可能
以前、別プロジェクト（atprotodart.com）の構築でDocusaurusを使用しており、開発体験が良好だったことも採用の決め手となりました。
システム構成
使用するAWSサービス
移行後のシステムは以下のAWSサービスで構成しています。
| サービス | 役割 |
|---|---|
| Amazon CloudFront | CDNとしてコンテンツを配信 |
| Amazon S3 | 静的サイトのオリジンストレージ |
| Amazon Bedrock | Claude Codeのバックエンドとして記事の構造化に活用 |
| AWS CodeCommit | ソースコードのリポジトリ管理 |
| AWS CodePipeline | CI/CDパイプラインのオーケストレーション |
| AWS CodeBuild | 静的サイトのビルド |
デプロイフロー
記事の執筆から公開までのフローは以下の通りです。
各ステップの詳細は以下の通りです。
- 草稿執筆: フリースタイルでメモやアイデアを記述
- MDX形式への構造化: Claude CodeやKiro IDEを使用して、草稿を構造化されたMDX形式の記事に変換
- 校正・校閲: 管理人が目視で記事の品質をチェック、必要があれば適宜修正
- リポジトリへプッシュ: 完成した記事をCodeCommitにプッシュ
- パイプライン起動: CodePipelineがCodeCommitへのプッシュを検知し、リリースパイプラインを自動実行
- ビルド: CodePipelineがCodeBuildを呼び出し、Docusaurusの静的サイトを自動ビルド
- デプロイ: ビルド成果物をS3に自動配置
- 配信: CloudFrontを経由してユーザーにコンテンツを配信
このフローでは、草稿の段階では形式にとらわれずに自由に記述し、AIツールが構造化を担当し、管理人がその結果を校正・校閲します。これにより、執筆者はコンテンツの内容に集中できます。
まとめ
この記事では、WordPressからDocusaurusへのブログ移行について、その経緯と技術構成を解説しました。
WordPressの運用で感じていた執筆体験の問題、開発言語の制約、コスト面の課題に対して、Docusaurus + AWSサービスの構成を採用することで、Markdown/MDXベースの執筆環境、TypeScriptによるカスタマイズ、CodePipelineによるCI/CDパイプラインの自動デプロイを実現しています。AIツールを執筆ワークフローに組み込むことで、草稿から公開までのプロセスを効率化しています。
参考リンク:
