TYPO3 Headless CMS移行ガイド -- Social Animal

TYPO3をご存知でしたら、それがどのようなものか理解されていることでしょう。強力で、特に複雑なコンテンツ構造、多言語対応、きめ細かい権限管理を備えた大規模なヨーロッパの企業向けサイトに最適です。しかし、TYPO3をお使いの組織の間では、モノリシックなアーキテクチャが足かせになっているという認識が高まっています。フロントエンド開発者はReactやVueを使いたい。マーケティングチームはオムニチャネルのコンテンツ配信を望んでいます。DevOpsはよりシンプルなデプロイを求めています。そして、みんなが満足のいくパフォーマンスを望んでいます。

そこでHeadless CMS移行の出番です。私は何度も、TYPO3から headless アーキテクチャへと組織を移行するというプロセスを経験しています。正直に言うと、ベンダーのマーケティングページが示唆するほど単純ではありません。しかし、条件が整えば絶対にやる価値があります。このガイドでは、TYPO3からHeadless CMSへの移行に伴う実際の決定、落とし穴、戦略をカバーしています。

TYPO3から去る理由
移行が実際に意味をなす場合
Headless CMSの選択
コンテンツモデリング：難しい部分
データ移行戦略
フロントエンドアーキテクチャの決定
TYPO3固有の機能への対応
移行中のSEO保護
テストとゴーライブの戦略
実際の移行タイムラインとコスト
FAQ

TYPO3 to Headless CMS Migration: A Practical Developer Guide

TYPO3から去る理由

はっきりさせておきましょう：TYPO3は悪いソフトウェアではありません。成熟していて、よくメンテナンスされており、特にドイツ、オーストリア、スイスでは献身的なコミュニティがあります。しかし、スケール時に痛みを伴う特定のアーキテクチャ上の制約があります。

開発者体験の摩擦

TYPO3のテンプレートシステム（Fluid）は強力ですがニッチです。Fluid、TypoScript、Extbase/TYPO3の拡張フレームワークに精通した開発者を見つけることは日に日に難しくなってきています。学習曲線は急で、若い開発者は圧倒的にJavaScriptフレームワークを使うことを好みます。TYPO3に熟練した開発者を見つけることができないため、採用期間が2倍になったケースも見てきました。

パフォーマンスの制限

TYPO3はPHP経由でサーバー側でページをレンダリングします。キャッシングが役立ちますが、基本的にはモノリシックなリクエストサイクルによって制限されています。静的サイト生成とエッジレンダリング（最新フレームワークが得意とするもの）は、TYPO3のアーキテクチャにネイティブではありません。TYPO3 Headless拡張（EXT:headless）があり、TYPO3をAPIに変えますが、その時点で、実際の作業をしている部分が減りつつあるPHPバックエンドを維持しているのです。

コンテンツ再利用の課題

TYPO3のコンテンツモデルはページ中心です。コンテンツ要素はページ上に存在します。モバイルアプリ、デジタルキオスク、メールシステム、ウェブサイトに同時にコンテンツを配信する必要がある場合、TYPO3のモデルはあらゆるステップで抵抗します。Headless CMSプラットフォームは初めからコンテンツを構造化されたデータとして扱うため、マルチチャネル配信は、後付けではなく自然なものになります。

総所有コスト

TYPO3の運用は、PHPサーバーの維持、TYPO3コアの更新（メジャーバージョン間で重大なことがあります）、拡張機能の互換性保持を意味します。Headless SaaS CMSは、ほとんどのインフラストラクチャオーバーヘッドを排除します。StrapiやDirectusのような自己ホスト型のHeadless選択肢でも、通常はOperationalなEffortが少なく済みます。

移行が実際に意味をなす場合

すべてのTYPO3サイトがHeadlessに移行する必要があるわけではありません。ここが私の正直な評価です：

シナリオ	移行する？	理由
シンプルなブロシュアサイト、50ページ、1言語	おそらくしない	やりすぎ。TYPO3で問題なく動作します。
モバイルアプリがある多言語エンタープライズサイト	する	Headlessはオムニチャネル配信に優れています
複雑な商品データを持つEコマース	する	より良いフロントエンド柔軟性、APIファースト統合
重いTYPO3拡張機能（ニュース、イベント、フォーム）を持つサイト	おそらくする	拡張機能の依存関係を最初に監査します
TYPO3バックエンドワークフローを持つ内部ポータル	慎重に	ワークフロー機能を失う可能性があります。これは置き換えが難しいです
チームがTYPO3開発者を雇うことができない	する	機能よりも継続性が重要です

移行が最も意味をなすのは、すでにリデザインやプラットフォームアップグレードを計画している場合です。純粋に技術的な理由での移行は、ビジネストリガーなしでは、予算承認を得るのに苦労することが多いです。

Headless CMSの選択

ここでチームが立ち往生します。数十のHeadless CMS選択肢があり、正しい選択は特定の状況に大きく左右されます。

エンタープライズグレードのオプション

ContentfulはHeadless CMSのマーケットリーダーであり続けています。価格はTeamプランで月額約$300から始まり、カスタムエンタープライズ価格にスケールします（使用状況に応じて、通常月額$2,000～$10,000以上）。成熟していて、ドキュメントが充実しており、優れたSDKを備えています。コンテンツモデリングは柔軟で、Composeフィーチャーは、TYPO3エディターが慣れているページビルディングのユースケースを処理します。

Sanityは開発者体験において個人的なお気に入りです。価格設定モデルは寛容です。フリーティアは多くの小規模プロジェクトを処理します。Team プランは$15/ユーザー/月と合理的です。Sanity StudioはReactで完全にカスタマイズ可能なため、TYPO3のバックエンドが提供するもの以上にマッチするか超える編集体験を構築できます。GROQ クエリ言語にはいくつかのなれが必要ですが、いったん理解すると信じられないほど強力です。

StoryblokはTYPO3の移行に特別な注目に値します。ビジュアルエディターを提供しており、TYPO3バックエンドユーザーに親しみやすく感じられるからです。価格はEntry プランで€99/月から始まります。DACH地域で特に人気があり、これはTYPO3のユーザーベースと大きく重なっています。

オープンソースの代替案

Strapi（2024年v5リリース）はリーディングオープンソースオプションです。自分でホストするか、Strapi Cloud（シートあたり月額$29から開始）を使用できます。Node.jsベースで、PostgreSQLまたはMySQLデータベースを使用し、急速に成長しているプラグインエコシステムを提供します。

Directusは任意のSQLデータベースをAPIと管理パネルでラップします。既存のデータベース構造を保持し、徐々に移行したい場合に最適です。オープンソース版は完全に機能しています。クラウド版は月額$99から開始されます。

比較表：TYPO3移行向けのHeadless CMSオプション

フィーチャー	Contentful	Sanity	Storyblok	Strapi	Directus
ホスティングモデル	SaaS	SaaS + 自己ホスト	SaaS	自己ホスト + クラウド	自己ホスト + クラウド
ビジュアルエディター	Compose（アドオン）	カスタマイズ可能	ビルトイン	プラグイン	制限あり
多言語	優秀	良好	優秀	良好	良好
開始価格	月額$300	フリーティア	€99/月	無料（OSS）	無料（OSS）
TYPO3エディター親しみやすさ	中程度	低い	高い	中程度	中程度
コンテンツモデリング	柔軟	非常に柔軟	コンポーネントベース	柔軟	データベース駆動型
Webhooks/Workflows	あり	あり	あり	あり	あり

当社はHeadless CMS開発サービスを通じてこれらのほとんどのプラットフォームと協力しています。選択は、編集者がビジュアル編集体験を必要とするか（Storyblok、Contentful Compose）、またはそれとも開発者の柔軟性が優先事項か（Sanity、Strapi）によく左右されます。

TYPO3 to Headless CMS Migration: A Practical Developer Guide - architecture

コンテンツモデリング：難しい部分

ここで、ほとんどの移行がうまくいきません。TYPO3のコンテンツモデルはHeadless CMSのコンテンツモデルと根本的に異なり、単純にマッピングすることはできません。

TYPO3のコンテンツ構造の理解

TYPO3では、コンテンツは以下のように構成されています：

ページ（ページツリー）とプロパティおよびメタデータ
コンテンツ要素（tt_content）がページ上のカラムに配置
拡張機能がカスタムレコードタイプ（ニュース、イベントなど）を追加
カテゴリーとファイル参照（sys_file_referenceテーブル経由でリンク）
TypoScriptがレンダリングとデータフローに影響を与える設定

これはページ優先モデルです。コンテンツはページのコンテキストの中に存在します。

Headlessコンテンツモデリング

Headless CMSプラットフォームはコンテンツファーストモデルを使用します。コンテンツタイプ（記事、著者、製品など）をフィールドで定義し、ページをそれらのコンテンツアイテムへの参照から構成します。ページ自体は多くの場合、別のコンテンツタイプにすぎません。

翻訳作業は次のようになります：

TYPO3ページツリー       →  スラッグ/階層フィールド付きのページコンテンツタイプ
tt_content（テキスト）   →  リッチテキストコンポーネント/ブロック
tt_content（画像）       →  アセット参照を備えたメディアコンポーネント
tx_news_domain_model_news →  記事/ニュースコンテンツタイプ
カテゴリー（sys_category） →  タグ/カテゴリーコンテンツタイプ
ファイル参照            →  アセット管理（DAM）

実践的なアドバイス

TYPO3のコンテンツモデルをHeadless CMSで複製しようとしないでください。これはコンテンツアーキテクチャを再考・改善する機会です。以下を監査することから始めてください：

どのコンテンツタイプが存在するか？ tt_content CTypesをエクスポートし、すべての拡張レコードタイプをリストアップします。
実際に使用されるフィールドはどれか？ TYPO3テーブルには数十のフィールドがあります。ほとんどのコンテンツは一握りしか使用しません。
リレーションシップは何か？ コンテンツが他のコンテンツをどのように参照するかをマッピングします。
翻訳設定は何か？ TYPO3は接続翻訳と自由翻訳モードをサポートしています。Headless CMSは使用しているモードを処理する必要があります。

-- 有用なTYPO3監査クエリ
-- コンテンツ要素をタイプ別にカウント
SELECT CType, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 AND hidden = 0 
GROUP BY CType 
ORDER BY count DESC;

-- ページをdoktypeでカウント
SELECT doktype, COUNT(*) as count 
FROM pages 
WHERE deleted = 0 AND hidden = 0 
GROUP BY doktype 
ORDER BY count DESC;

-- 使用中のすべての言語を見つける
SELECT sys_language_uid, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 
GROUP BY sys_language_uid;

データ移行戦略

ターゲットCMSでコンテンツモデルが定義されたら、実際にデータを移動する必要があります。3つの主要なアプローチがあります。

アプローチ1：スクリプトベースのエクスポート/インポート

TYPO3のデータベースに直接クエリを実行し、データを変換し、APIを経由してHeadless CMSにプッシュするスクリプトを作成します。これが最も一般的なアプローチで、最大限の制御が可能です。

// 例：TYPO3ニュースレコードをContentfulに移行
const contentful = require('contentful-management');
const mysql = require('mysql2/promise');

async function migrateNews() {
  const db = await mysql.createConnection({
    host: 'localhost',
    database: 'typo3_db',
    user: 'root',
    password: 'password'
  });

  const client = contentful.createClient({
    accessToken: 'your-management-token'
  });

  const space = await client.getSpace('your-space-id');
  const env = await space.getEnvironment('master');

  const [rows] = await db.execute(`
    SELECT n.uid, n.title, n.teaser, n.bodytext, n.datetime,
           n.path_segment, p.slug as category_slug
    FROM tx_news_domain_model_news n
    LEFT JOIN sys_category_record_mm mm ON mm.uid_foreign = n.uid
    LEFT JOIN sys_category c ON c.uid = mm.uid_local
    WHERE n.deleted = 0 AND n.hidden = 0
  `);

  for (const row of rows) {
    const entry = await env.createEntry('article', {
      fields: {
        title: { 'en-US': row.title },
        teaser: { 'en-US': row.teaser },
        body: { 'en-US': convertRteToRichText(row.bodytext) },
        publishDate: { 'en-US': new Date(row.datetime * 1000).toISOString() },
        slug: { 'en-US': row.path_segment }
      }
    });
    await entry.publish();
    console.log(`Migrated: ${row.title}`);
  }
}

convertRteToRichText関数がここで厄介になります。TYPO3のRTE出力はHTML（多くの場合、内部リンク用の<link>のようなカスタムタグを含む）です。これを構造化されたリッチテキスト形式に変換することはCMS によって異なります。Contentfulは独自のリッチテキストJSONを使用し、SanityはPortable Textを使用します。

アプローチ2：TYPO3 Headless拡張をブリッジとして

既存のTYPO3インスタンスにEXT:headless拡張をインストールします。これはTYPO3をJSON APIに変え、移行スクリプトから使用するか、新しいフロントエンドを構築している間、Headlessバックエンドとして一時的に使用することもできます。

このアプローチの良い点は、新しいフロントエンドを最初にTYPO3のHeadless APIに対して実行し、後で新しいバックエンドをHeadless CMSに切り替えることができることです。移行を2つのフェーズに分割します。

アプローチ3：手動再作成

小規模なサイト（100ページ未満）では、新しいCMSでコンテンツを手動で再作成する方が速いことがあります。特にコンテンツも再構成・再執筆している場合（おそらくすべきです）。

フロントエンドアーキテクチャの決定

Headless CMSがあれば、独立したフロントエンドが必要です。ここが本当のパフォーマンスゲインが起こるところです。

Next.js

最も人気のある選択肢です。サーバーサイドレンダリング、静的生成、増分静的再生成。Next.jsはあなたが必要とするかもしれないすべてのレンダリング戦略を処理します。App Router（Next.js 13.4以降は安定）とReact Server Componentsは、特にコンテンツ量の多いサイトに適しています。当社はNext.js開発プラクティスを通じて多くのこの作業を行っています。

Astro

それほど多くのインタラクティビティが必要ないコンテンツ量の多いサイトに対して、Astroは驚くほどです。デフォルトではゼロJavaScriptを出荷し、Islands Architecture を通じた部分的なハイドレーションをサポートします。Astroビルドで一貫して95以上のLighthouse スコアが得られるのを見ました。これは一般的なTYPO3フロントエンドパフォーマンスに対する劇的な改善です。これがあなたの関心事であれば、Astro開発サービスをチェックしてください。

Nuxt

チームがReactよりVueを好む場合、Nuxt 3はNext.jsと同等です。堅実な選択肢で、素晴らしいDX、良好なエコシステム。

フレームワーク	最適用途	出荷JS	学習曲線	CMS統合
Next.js	動的アプリ、Eコマース、ダッシュボード	中～高	中	優秀
Astro	コンテンツサイト、ブログ、マーケティング	最小	低	優秀
Nuxt 3	Vueチーム、コンテンツ + アプリ	中	中	良好
SvelteKit	シンプルさを望む小規模チーム	低	低～中	成長中

TYPO3固有の機能への対応

TYPO3の一部の機能は、Headlessの世界で直接的な等価物を持ちません。一般的なものへの対応方法は以下の通りです。

ワークスペースとバージョニング

TYPO3のワークスペースシステムにより、編集者は複数のページの変更をパブリッシング前にステージングできます。ほとんどのHeadless CMSプラットフォームは、これを部分的に複製する環境またはリリーススケジューリングを提供します。Contentfulは環境とスケジュール化されたパブリッシングを備えています。Sanityは最近リリースされたリリース機能を備えています。どれも箱から出した時点では、TYPO3 Workspacesと同じくらい洗練されていないため、編集者がワークスペースに大きく依存している場合、ワークフローの調整を計画してください。

バックエンドユーザー権限

TYPO3の権限システムは非常にきめ細かいです。ページレベル、コンテンツ要素レベル、フィールドレベルのアクセス制御があります。Headless CMSプラットフォームはここではさまざまです。Contentfulのロールシステムは良好ですが、それほどきめ細かくありません。Sanityはより柔軟ですが、カスタム設定が必要です。Strapiのロールベースアクセスは良好です。現在の権限マトリックスを監査し、ターゲットCMSがそれを処理できることをコミット前に検証してください。

フォーム処理

TYPO3のForm Framework（EXT:form）はYAML設定からフォームを生成します。Headlessセットアップでは、フォームサービスが必要になります。オプションにはFormspree、Basin、またはサーバーレス関数を使用した自分自身の構築が含まれます。Next.jsを使用する場合、Server Actionsはフォーム処理を単純にします。

多言語とローカライズ

これは重要で、しばしば過小評価されています。TYPO3の翻訳処理（言語オーバーレイの概念、接続/自由モード、フォールバックチェーン付き）は洗練されています。Headless CMSを選択する前に、正確な翻訳要件をマッピングしてください。StoryblokとContentfulはロケール管理をよく処理しています。Sanityは複雑なマルチ言語シナリオのためにより多くのカスタム設定が必要です。

移行中のSEO保護

このセクションは最も重要なセクションかもしれません。ボッチされた移行はあなたのオーガニックトラフィックをクラッシュさせることができます。

URLマッピング

TYPO3サイトからすべてのURLをエクスポートします。すべて。単独で。Screaming FrogやWget --spiderのようなクローラーを使用して、完全なURLリストを構築します。その後、リダイレクトマップを作成します：

/old-typo3-path/page.html → /new-clean-path
/index.php?id=42 → /about-us
/fileadmin/documents/report.pdf → /assets/report.pdf

変更されるすべてのURLの301リダイレクトを実装します。Next.jsでは、これはnext.config.jsに含まれます：

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-path/:slug*',
        destination: '/new-path/:slug*',
        permanent: true,
      },
      // ... 数百個以上、理想的にはJSONファイルから読み込まれます
    ];
  },
};

大きなリダイレクトリスト（500以上）については、アプリケーション設定ではなくエッジ（Vercel Edge Middleware、Cloudflare Workers、またはnginx）でリダイレクトを処理することを検討してください。

メタデータの移行

TYPO3はSEOメタデータをpagesテーブル（seo_title、description、og_image など）に保存し、潜在的にEXT:cs_seoまたはEXT:seo_basicsのような拡張機能に保存しています。このすべてを抽出し、Headless CMSコンテンツモデルに移行します。以下を忘れないでください：

ページタイトルとメタディスクリプション
Open GraphとTwitter Cardデータ
正規URL
多言語サイト用のhreflangタグ
構造化データ/ JSON-LDスキーマ
XMLサイトマップ生成

監視

移行前に、新しいドメイン/サブドメインのGoogle Search Consoleをセットアップします。ゴーライブ後、最初の2週間は毎日カバレッジレポートを監視します。クロールエラー、ドロップされたページ、インデックス問題を監視します。ロールバック計画を用意してください。

テストとゴーライブの戦略

段階的なアプローチを推奨します。ビッグバン方式のカットオーバーよりもです。

フェーズ1：並行実行（2～4週間）

ステージングドメインで新しいHeadlessサイトを実行します。TYPO3サイトとのコンテンツのパリティを比較します。編集者にコンテンツワークフローをテストしてもらいます。Percy または Playwright のようなツールを使用して、自動化されたビジュアルリグレッションテストを実行します。

フェーズ2：ソフトローンチ

CDNレベルの機能フラグまたはA/Bテストを使用して、トラフィックの小さな割合を新しいサイトにルーティングします。Core Web Vitals、エラー率、ユーザー動作を監視します。

フェーズ3：完全なカットオーバー

DNSまたはリバースプロキシ構成を切り替えます。すべてのリダイレクトをアクティブにします。48時間をリーディングして積極的に監視します。TYPO3インスタンスを少なくとも30日間実行状態のまま保ってください（参照用）。

フェーズ4：廃止

新しい移行に確信が持てたら、TYPO3インフラストラクチャを閉じます。データベースとfileadminディレクトリをアーカイブします。後で誰かが古いコンテンツについて尋ねたとき、感謝するでしょう。

実際の移行タイムラインとコスト

正直に言いましょう。このコストはどのようなものか。多くのチームが移行プロジェクトを過小評価しているのを見てきました。

プロジェクトサイズ	ページ	タイムライン	推定コスト
小	50～200	6～10週間	$15,000～$35,000
中	200～1,000	12～20週間	$40,000～$90,000
大	1,000～5,000	20～36週間	$80,000～$200,000
エンタープライズ	5,000以上	6～12ヶ月	$150,000～$500,000以上

これらの数値には、コンテンツモデリング、移行スクリプティング、フロントエンド開発、テスト、ローンチサポートが含まれています。CMS ライセンスコストは含まれていません。プラットフォームによって異なります。

最大のコスト削減は以下のとおりです：

コンテンツタイプの数と複雑さ — 実際のページ数ではなく
カスタムTYPO3拡張 — 同等の機能を構築する必要があります
マルチ言語セットアップ の複雑さ
統合要件（検索、Eコマース、認証）
編集トレーニング と変更管理

特定のセットアップの移行がどのようになるかについて議論したい場合は、当社に連絡するか、エンゲージメントモデル用に当社の価格ページをチェックしてください。

FAQ

新しいものに移行する代わりに、TYPO3をHeadless CMSとして使用することはできますか？

はい、EXT:headless拡張（以前は"headless"）はTYPO3をJSON APIに変えます。これは良い中間ステップになります。しかし、それでもTYPO3バックエンドのすべてのOperationalなオーバーヘッドを維持しています。ブリッジ戦略としては意味がありますが、TYPO3の依存関係を減らすことが目標なら、通常は長期的な答えではありません。

典型的なTYPO3からHeadless CMSへの移行にはどのくらいかかりますか？

中程度のサイト（200～1,000ページ）の場合、キックオフからローンチまで3～5ヶ月を予想してください。コンテンツモデリングと移行スクリプティングフェーズは、チームが予想するよりも長くかかります。フロントエンド開発は、コンテンツモデルが定義されたら、多くの場合並行して実行できます。複数の言語と複雑な統合を持つエンタープライズ移行は6～12ヶ月かかる場合があります。

移行中にSEOランキングを失いますか？

正しく実行すれば、そうすべきではありません。重要な要素は、変更されたすべてのURLの適切な301リダイレクトの実装、すべてのメタデータの移行、サイト構造と内部リンクの維持、更新されたサイトマップをGoogleに提出することです。ゴーライブ後2～4週間の一時的なランキング低下は正常であり、通常は回復します。永続的な損失は通常、リダイレクトの欠落またはコンテンツの損失を示しています。

TYPO3を置き換えるのに最適なHeadless CMSはどれですか？

それはあなたの優先事項に依存しています。Storyblokは多くの場合、ビジュアル編集機能のためにTYPO3エディターにとって最も滑らかな移行です。Contentfulは最も成熟したエコシステムを備えた最も安全なエンタープライズの選択肢です。Sanityは最も開発者の柔軟性を提供します。Strapiはオープンソースと自己ホスティングが必要な場合の最良のオプションです。単一の最適な答えはありません。チーム、予算、要件によります。

移行後、TYPO3拡張はどうなりますか？

各拡張を個別に評価する必要があります。EXT:news、EXT:cal、EXT:powermailのような一般的な拡張は、新しいスタックで同等の機能が必要です。ニュース/ブログ機能は、どのHeadless CMSでも簡単に複製できます。カレンダーおよびイベント機能には、サードパーティサービスが必要な場合があります。フォームには新しいソリューション（フォームビルダー、サーバーレス関数、またはFormspreeのようなサービス）が必要です。カスタム拡張には最も分析が必要です。

移行中にTYPO3のfileadminアセットをどのように処理しますか？

すべてのアセット（画像、PDF、ビデオ）を、新しいCMSのアセット管理システムまたは別のDAM/CDNに移行する必要があります。fileadminからダウンロードし、新しいプラットフォームのAPIを経由して新しいプラットフォームにアップロードし、古いファイル参照を新しいアセットIDにマップするスクリプトを記述してください。処理/サイズ変更された画像を忘れないでください。ほとんどのHeadless CMSプラットフォームは画像の変換を自動的に処理するため、通常はオリジナルのみを移行する必要があります。

段階的に移行することはできますか？それとも一度にすべてをする必要がありますか？

段階的な移行は可能であり、場合によっては大規模なサイト向けにお勧めします。リバースプロキシを使用して、特定のURLパスを新しいHeadlessfrontendにルーティングしながら、その他をTYPO3に保ったままにすることができます。これにより、セクション単位での段階的な移行が可能になります。トレードオフは、2つのシステムを同時に管理する複雑さと、両方の間で一貫したナビゲーションとデザインを維持することです。

TYPO3バックエンドユーザーが変更に抵抗している場合はどうしますか？

変更管理は本当に戦いの半分です。設計フェーズの後ではなく、コンテンツモデリングフェーズの早い段階でエディターを関与させることから始めてください。すべてが構築された後ではなく、新しいCMSを見せます。優れた編集体験を持つCMS（StoryblokとContentfulはエディターからの最良のフィードバックを取得する傾向があります）を選択します。設定固有のドキュメントとトレーニング資料を作成します。そして、何が変わるか、なぜかについて正直に――エディターは通常、改善されたプレビュー体験とより速いパブリッシングワークフローを見たときに同意してきます。

目次