双方向同期

RankTurn が WordPress・Webflow・GitHub・Notion と記事を双方向に同期する仕組み（取り込み・ループ防止・競合処理を含む）を解説します。

ほとんどの連携は、初期状態では一方向です。RankTurn が記事を各プラットフォームへ送り出すだけの流れになっています。双方向同期を有効にすると、その逆方向の経路が追加され、プラットフォーム側で直接行った編集が RankTurn にも戻ってくるようになります。オンにすると、WordPress・Webflow・GitHub・Notion で執筆や修正を行った変更を、手動で取り込み直さなくても RankTurn に反映できます。

考え方はどのプラットフォームでも同じです。プラットフォーム側で変更が起きると、RankTurn は最新版を取得し、対象の記事と突き合わせ、本当に変更があるかを判定したうえで反映します。その際、自分が直前に送り出した内容を誤って取り込み直さないように注意します。

各プラットフォームの設定方法は、それぞれの専用ページを参照してください。WordPress 連携、Webflow 連携、GitHub 連携、Notion 連携。接続情報の保管方法については認証情報とセキュリティをご覧ください。

対応プラットフォーム

RankTurn へ変更を戻せるプラットフォームは4つです。それぞれ仕組みは少しずつ異なりますが、突き合わせと反映のルールは共通です。

プラットフォーム	変更の戻り方	戻ってくる内容
WordPress	1時間ごとのチェック（どのサイトでも動作）＋小さなアドインによる任意のリアルタイム更新	タイトル・本文・抜粋／メタディスクリプション
Webflow	アイテムの作成・変更・削除・非公開時のリアルタイム更新	タイトル・本文・サマリー
GitHub	選んだブランチ・フォルダへ push したときのリアルタイム更新	タイトル・本文（Markdown ファイルから）・説明
Notion	ページの作成・変更・削除時のリアルタイム更新	タイトル・本文・一部の項目

WordPress は、前回チェック以降に更新された投稿を約1時間ごとにチェックします。追加設定なしでどのサイトでも動作します。小さなアドインを WordPress サイトに追加すると、リアルタイム更新が加わり、投稿が保存された瞬間に WordPress が RankTurn へ通知します。1時間ごとのチェックは、取りこぼしに備えた安全網として残ります。通知に含まれるのは「どの投稿がいつ変わったか」だけで、最新のコンテンツは RankTurn が必ず自分で取得します。

Webflow は、アイテムが作成・変更・削除・非公開になったときにリアルタイムで更新を送ります。更新が届くと、RankTurn は通知の内容を鵜呑みにせず、Webflow から最新版のアイテムを取得し直します。

GitHub は push したときにリアルタイムで更新を送ります。RankTurn は、選んだフォルダ・ブランチ内の .md および .mdoc ファイルだけを対象とし、変更された各ファイルの最新内容を取得します。

Notion は、ページが変わったときにリアルタイムで更新を送ります。まず接続の検証（Notion の画面に検証コードを貼り付ける）を行い、その後はページの変更が自動的に取り込まれます。

同期を有効にする

双方向同期は、設定 → 連携（インテグレーション） から接続ごとに管理します。

まず対象プラットフォームを接続します（各専用ページを参照）。
接続済みのカードで 双方向同期 トグルをオンにします。
RankTurn が、各プラットフォームに必要な設定を行います。
- Webflow — アイテムの作成・変更・削除・非公開時に更新が届くよう自動で設定されます。
- GitHub — push したときに更新が届くよう自動で設定されます。
- WordPress — 1時間ごとのチェックがすぐに始まります。リアルタイム更新には、提供されるアドインを WordPress サイトに追加します。
- Notion — Notion 側で更新の設定を行い、検証ステップを完了します。

トグルをオフにすると、これらの設定が解除されます。Webflow と GitHub からの更新は届かなくなり、保管していたシークレットもクリアされます。すでにプラットフォーム側で解除済みの場合でも問題ありません。RankTurn はそのまま処理を続けます。

届いた更新は、反映する前に必ず本物かどうかが確認されます。RankTurn は、プラットフォームからの正規の通知だけに反応します。同じ更新が二重に届いた場合も、処理されるのは一度だけです。

双方向同期には有効な有料プランが必要です。プランと料金を参照してください。

新規取り込み（外部アイテムから記事を作成）

初期状態では、WordPress と Webflow のインバウンド同期は RankTurn にすでに存在する記事の更新のみ を行います。これらのプラットフォーム側で直接作成され、対応する記事が存在しないアイテムは無視されます。

これを変えるのが 新規取り込み（Import New） トグルで、同期を有効にすると WordPress と Webflow のカードに表示されます。ラベルは WordPress では Import new posts、Webflow では Import new items です。（一度きりの手動一括取り込みである Import Articles ボタンとは別物なので混同しないでください。）これをオンにすると、プラットフォーム上の新規アイテムが RankTurn 内で 下書き 記事として作成されます。

WordPress — 対応する記事がない投稿が下書きになります。
Webflow — 対応する記事がないアイテムが下書きになります。タイトルもURL（ウェブアドレス）もないアイテムはスキップされます。

GitHub の挙動は異なり、新規取り込みトグルはありません。 監視対象のフォルダ・ブランチに追加された新しい .md / .mdoc ファイルは、常に下書き記事として取り込まれます。オンにするものはありません。

取り込みについて押さえておきたい点が2つあります。

生成クォータを一切消費しません。 取り込みは既存コンテンツのコピーであり AI 生成ではないため、月間の記事生成枠にはカウントされません。使用量クォータを参照してください。
WordPress／Webflow のトグルがオフの場合、既存記事のみが更新されます。 新規の投稿・アイテムは、オンにするまでスキップされます（ログには「スキップ」として記録されます）。このトグルは GitHub には影響せず、GitHub は常に新規ファイルを取り込みます。

WordPress または Webflow で 新規取り込み がオフで、対応する記事がないアイテムが来た場合、何も作成されません。RankTurn は「取り込みがオフ」である旨をログに記録します。

ループ防止

双方向同期で最も難しいのは、自分自身の変更を取り込み直さないことです。RankTurn が記事を公開すると、プラットフォームはその変更をすぐに返してくることがあります。対策がなければ、RankTurn は自分の公開を外部からの編集と誤認し、無限ループに陥ってしまいます。RankTurn は2つの方法でこれを防ぎます。

内容の比較。 RankTurn は記事を公開する際、タイトル・本文・サマリーから「内容の指紋」を覚えておきます。この指紋は、プラットフォームが内部の書式を少し変えても（コンテンツ管理システムが保存時に加える見た目だけの書き換えのように）同じになるよう設計されています。変更が戻ってくると、RankTurn は届いた内容の指紋を、直前に公開したものと比べます。

指紋が一致 → スキップ。 実質的な変更はなく、RankTurn 自身の公開のエコー（反響）です（Webflow・WordPress）。
指紋が異なる → 本物の編集として反映されます。

プラットフォームごとの簡易チェック。 一部のプラットフォームでは、その前にさらに高速なチェックを行います。

WordPress は、変更時刻が RankTurn の最後の公開と同時刻かそれ以前の投稿もスキップします。RankTurn 自身の公開が戻ってきた確実な証拠だからです。
GitHub は、RankTurn 自身が行った変更（RankTurn は自分の変更に印を付けます）をスキップし、前回同期から実際には変わっていないファイルもスキップします。
Notion は、すべて RankTurn の接続によって行われた変更をスキップします。

自分が公開したはずのコンテンツがインバウンドの「変更」として現れた場合、ほぼ確実に、プラットフォームが通常以上にコンテンツを整形し直したことが原因です。実際にはまれなケースです。

競合の処理

競合は、最後の同期より後に RankTurn 側で 記事を編集し、さらにプラットフォームから別の編集が届いたときに発生します。解決の仕方はプラットフォームによって異なるため、覚えておくべきルールは2つあります。

WordPress・Webflow・GitHub — プラットフォーム側の版が優先されます。 RankTurn は自分のコピーを、届いたプラットフォームの内容で上書きし、プラットフォームが優先された旨を同期ログに記録します。変更自体は反映されますが、通常の成功ではなく 競合（conflict） として記録されるため、RankTurn 側で行った編集が上書きされたことを確認できます。

この3つのプラットフォームでは、RankTurn は編集時刻を比べて競合かどうかを判断します。RankTurn 内での記事の最終更新時刻が、そのプラットフォームの最後の成功同期より新しい場合、届いた変更は競合として扱われます。なお、届いた内容が RankTurn の最後の公開と一致する場合は、競合ルールが適用される前にループ防止のチェックがスキップします。

Notion — RankTurn 側の版が保持されます。 Notion では、より新しく編集された版が優先され、同時刻のときは RankTurn が優先されます。RankTurn 側の記事が Notion ページよりも新しく編集されている場合、届いた変更は スキップ されます（上書きはせず、ログには「スキップ」として記録されます）。これは上記3つのプラットフォームとは逆の挙動です。Notion の変更が反映されるのは、Notion ページのほうが新しく編集されている場合のみです。したがって Notion が、より新しい RankTurn の編集を上書きすることはありません。

これに加えて、プラットフォームごとの個別挙動があります。

Webflow — アイテムが 削除または非公開 になった場合、対応する記事は削除されず、RankTurn 内で 下書き に戻されます。
WordPress — 投稿が削除または非表示になった場合、失敗にせず対応記事を下書きへ戻します。記事が最初にどう作成されたかという記録は、インバウンド編集で上書きされることはありません。
GitHub — ファイルがリポジトリから削除された場合、リンクされた記事は削除されません。削除はログに記録され、スキップされます。
Notion — 記事の ステータス は RankTurn が唯一の正本です。RankTurn が Notion 上に表示するステータスは表示専用であり、読み戻されることはありません。承認のシグナルとして戻ってくるのは、Notion 上でチェックできる Auto Publish チェックボックスです。

同期ログ

届いた変更はすべて記録され、何が起きたかを正確に確認できます。各ログエントリには、プラットフォーム、方向（インバウンド／アウトバウンド）、結果、リンクされた記事とプラットフォーム側のアイテム、プラットフォームの最終更新日時、短い理由やメモが残ります。

結果は次の4種類です。

ステータス	意味
成功（Success）	変更が反映された（記事を更新、または新規下書きとして取り込み）。
スキップ（Skipped）	何も行わなかった。RankTurn 自身の変更のエコー、実質的に変わっていない、ファイル削除、または新規取り込みがオフのときの新規アイテムなど。
競合（Conflict）	変更は反映されたが、RankTurn 側で行った編集を上書きした（プラットフォームが優先）。
失敗（Failed）	変更を取り込めなかった（例: アイテムを取得できないなど）。エラー内容が記録される。

各エントリには、スキップや競合の理由がわかりやすい言葉でも記録されます。プラットフォームの編集が RankTurn に届いたかの確認、想定した変更がなぜスキップされたかの把握、プラットフォームの編集が自分の編集を置き換えた競合の発見に、このログを活用してください。