小説本文が上書きされたら？バージョン履歴・ローカル下書き・競合処理
AIリライトや複数タブ、再接続のあとに本文がおかしいと気づいたら、保存を続けないで。サーバーのバージョンとローカル下書きの見分け方、バージョン履歴からの復元、競合の処理、各章直近2件・7日間・端末をまたげない下書きの制限、誤上書き時の対処順序や長期バックアップを解説します。
この記事の目次 10セクション
本文が突然古い版に戻っているのに気づいたとき、最も大切な行動は、リフレッシュすることでも、すぐにもう一段落入力して試すことでもありません。
まず手を止めて、現在のページ、サーバーのバージョン、ローカル下書きが、それぞれ何を保存しているかを確認してください。 編集を続けるとバージョンが増え、続けてリフレッシュすると、どれが原稿でどれが新稿かを判断しにくくなるかもしれません。
Maliang Writerの本文の保護は2つの層に分かれます：サーバーのバージョン履歴は、すでに保存された内容を探すのに向き、ローカル下書きボックスは、競合の判断を行う前の、まだ安全に同期されていないキャンバスの内容を保護するために使います。両者の位置づけは異なり、ローカル下書きをクラウドのバックアップと見なしてはいけません。
本文が「戻った」ように見えるとき、まず確認する3つのことは？
まず現場を記録し、それから復元を行います。
- 現在の章のタイトルと文字数を見て、章を間違えていないことを確認する。
- 失われた位置のだいたいの場所を控え、入力を続けたり、AIリライトを起動したりしない。
- バージョン履歴を開き、サーバーのバージョンとローカル下書きを、それぞれ確認する。
複数のタブ、スマホとパソコンの同時の表示、AIのバックグラウンドリライト、回線切断後の再接続は、どれも同じ章に異なる基準を生じさせる可能性があります。システムは内容のバージョンにガードをかけ、本当の食い違いを見つけると、自動保存を一時停止して選択肢を示し、古いリクエストが新しい内容を直接上書きするのを許しません。
サーバーのバージョン履歴とローカル下書きは、何が違うのか？
サーバーのバージョン履歴は、すでにバージョンとして形になった章の内容を記録し、デバイスをまたいで見られます。あるバージョンの復元は明確な内容の操作なので、復元する前に、対象のバージョンに本当に本文が含まれているかを確認してください。
ローカル下書きは、ブラウザ内の短期の紛失防止の備えです。主に次のタイミングで書き込まれます：保存の競合が出たとき、サーバーの最新内容を読み込もうとするとき、外部のリライトでキャンバスを更新しようとするとき、競合の膠着で保存を一時停止する必要があるとき。
現在の設計の境界は次のとおりです。
- 各章につき、直近2件のローカル下書きを保持する。
- 下書きは7日後に自動で期限切れになる。
- 全体で限られたブラウザのストレージ容量を使うため、古すぎる内容は淘汰される。
- クラウド同期はせず、ブラウザやデバイスを替えたり、サイトデータを消去したりすると、消える可能性がある。
- 共有のデバイスでは、本文の保持に慎重になり、不要になったら手動で消去する。
したがって、すでに保存された長期のバージョンは、まずサーバーの履歴を見て、さっき競合した内容や誤操作した内容は、ローカル下書きを見てください。
「最新を読み込む」と「自分のバージョンを残す」は、どう選ぶか？
競合のメッセージが出たら、まず2つの内容の更新時刻と重要な段落を比較します。
「最新を読み込む」は、サーバーのバージョンが本当に新しい場合に向いています。たとえば、別のデバイスですでに変更が完了している、あるいはバックグラウンドのAIタスクが新しい内容を書き込んだ場合です。クリックする前に、現在のキャンバスがまずローカル下書きに保護され、それからページがサーバーのバージョンを読み込みます。
「自分のバージョンを残す」は、現在のキャンバスこそ、残したい最新の手動編集である場合に向いています。システムは、サーバーの内容を1件下書きとして保存し、そのうえでサーバーの最新バージョンを新しい基準として、あなたの内容を提出するので、バージョンなしでの上書きを避けられます。
確信が持てないときは、推測しないでください。まず両側の重要な段落をコピーするか、ローカル下書きから完全な文字数を確認します。復元の操作の目標は、2つとも守ったうえで、どちらを本文にするかを決めることです。
ローカル下書きから、キャンバスに復元するには？
章のバージョン履歴の中の「ローカル下書き」の領域を開き、保存時刻、文字数、理由で判断します。よくある理由には、保存競合の保護、最新読み込み前の保護、復元前の保護が明記されます。
キャンバスに復元する前に、システムは現在のキャンバスをもう1件下書きとして保存し、バージョンを選び間違えたあとに戻れなくなるのを防ぎます。復元後の内容は、ユーザーの編集として改めて保存の流れに入り、引き続きバージョンガードに守られます。
確実な手順は：
- まず「内容をコピー」で、候補の下書きを一時的なドキュメントに置いて確認する。
- 冒頭、失われた位置、章の結びを比べ、文字数だけを見ない。
- 確認してから、キャンバスに復元をクリックする。
- 保存の状態が完了するのを待ってから、章を切り替えるかリフレッシュする。
AIリライトのあとで原文が見えなくなったら、どこを探すべきか？
まず差分パネルがまだあるかを見て、それからバージョン履歴を見ます。
AIの変更がまだ確認待ちの状態なら、ブロックごとに却下して、対応する原文を復元できます。すでにすべて承認したか、章全体のマージが完了している場合は、保存前後のサーバーのバージョンを確認します。競合が起きたばかりで、変更を却下するときに続けて手書きした場合は、ローカル下書きも確認してください。
今後、大きな変更をする前に、AIリライトの差分比較で段落ごとに確認することをお勧めします。章全体の置き換えは、書き直すと明確に決めたタスクにだけ向いており、通常の推敲には向きません。
なぜ複数タブでの編集は、競合が起きやすいのか？
2つのページは、どちらも同じ古いバージョンを出発点にしています。Aのタブが先に保存すると、サーバーのバージョンはすでに進んでいますが、Bのタブはまだ古い基準で提出するので、システムは、それがAを黙って上書きするのを止めなければなりません。
この種の409競合は「保存システムが壊れた」のではなく、保護の仕組みが、サーバーとローカルの両方に有効な変化があり、人が決める必要があると知らせているのです。内容は同等でバージョンだけが進んだ偽の競合は、できるだけ静かに同期されます。両側の本文が本当に異なる場合にだけ、自動保存を中断すべきです。
日常の習慣で競合を減らせます：同じ章は、できるだけ1つのタブだけで編集する、デバイスを切り替える前に保存の完了を待つ、バックグラウンドのAIタスクが完了したら、まずメッセージを見てから手書きを続ける。
ローカル下書きは、小説のバックアップですか？
違います。短期の、同じブラウザの復元の窓です。
本当のバックアップの方針には、サーバーのバージョン、定期的なエクスポート、重要な節目のオフラインのコピーが含まれるべきです。ローカル下書きは、ブラウザの消去、プライベートモード、ストレージの割り当て、デバイスの変更の影響を受け、いま起きたばかりの競合を救うのには向きますが、数か月前の章を保存するのには向きません。
巻の完結、大きな改稿、投稿の前に、それぞれ1回エクスポートしておくとよいでしょう。直し方は、まず小説の推敲ガイドを見て、公開前のその他のチェックは小説の校正チェックリストを、章をまたぐ事実のリスクは一貫性チェックで処理してください。
誤って上書きしたあとの10分間は、どう対処すべきか？
最初の2分は、現場の保護だけを行います：入力をやめ、新しいAIタスクを起動せず、章、デバイス、おおよその発生時刻を控えます。ページにまだ対象の内容が表示されているなら、まずシステムのクリップボードか一時的なドキュメントにコピーします。
次にバージョン履歴を開き、新しいものから古いものへと、サーバーのバージョンを時刻順に確認します。さらにローカル下書きの文字数と保存の理由を見ます。疑わしいバージョンを見つけても、そのまま復元せず、まずコピーして、失われた位置、冒頭、章の結びを比べます。
対象の内容を確認してから、キャンバスに復元し、保存の完了を待ちます。最後に、隣の章とタスクセンターを確認し、外部のリライトがまだ実行中で、同じ章に書き戻し続けていないことを確かめます。全過程で、一度に1つの復元の操作だけを行い、見つけたばかりの内容が、次の操作でまた上書きされるのを避けます。
目的のバージョンが見つからないとき、損失を広げてしまう操作は？
何度もリフレッシュしたり、デバイスを行き来したりしないでください。環境ごとに見えるローカル下書きが違うので、頻繁に切り替えると判断のコストが増えるだけです。また、誤ったバージョンの上で書き足しを続けて、記憶で失われた内容を再構築しようとするのもやめましょう。それが自動保存されると、タイムライン上に、新しく見えて実際には不完全なバージョンが1つ増えます。
「保存を起こす」ために、適当に1文字足して消したりしないでください。バージョンの競合は、新しいリクエストを作ることでは解決しません。さらに、ブラウザのキャッシュの消去、プライベートウィンドウの終了、クリーンアップツールの使用もしないでください。ローカル下書きは、まさにこれらのブラウザのデータの中にあるかもしれません。
バージョン履歴にもローカル下書きにも対象の内容がなければ、まず現在のすべての候補のバージョンと発生時刻を残したうえで、サポートに連絡してサーバーのログを調べてもらってください。「どの作品の、どの章で、いつ、どのデバイスで何の操作をしたか」を説明するほうが、「内容が消えた」とだけ言うより、特定しやすくなります。
復元が終わったら、引き金となった原因を別に振り返り、同じ経路でもう一度起きないようにしてください。
よくある質問
Q1：ページをリフレッシュすると、失われた内容は自動で復元されますか？
リフレッシュを復元の手段と考えないでください。リフレッシュは通常、サーバーの状態を読み込み、未同期のキャンバスの内容は、ローカル下書きなどの保護に頼るしかありません。まずバージョン履歴を確認し、それからリフレッシュするかを決めてください。
Q2：ローカル下書きは、スマホで見られますか？
下書きが書き込まれた同じブラウザの環境でだけ読み取れます。クラウド同期はしないので、パソコンのブラウザの下書きが、スマホに自動で現れることはありません。
Q3：なぜ各章で直近の2件のローカル下書きしか見えないのですか？
ローカル下書きは短期の競合保護に使うもので、ブラウザのストレージの占有を抑える必要があります。より長期のバージョンは、サーバーのバージョン履歴と、主体的なエクスポートに頼ってください。
Q4：古いバージョンを復元すると、現在の内容を上書きしませんか？
復元はキャンバスを変えるので、操作の前に対象のバージョンを確認してください。システムは、できるだけ現在のキャンバスを下書きに保護しますが、選び間違えないよう、先に重要な内容をコピーしておくことをお勧めします。
Q5：保存の競合が続けて出たら、どうすればよいですか？
入力を続けるのをやめ、同じ章を編集している他のタブを閉じ、サーバーとローカルのバージョンを比べたうえで、はっきり選んでください。保存を何度もクリックしないでください。競合の膠着は、ユーザーの選択で打ち破る必要があります。