Scribe と Word：docx を橋渡しにした往復レビュー・ワークフロー
編集者、共同作業者、出版社の多くは Word（あるいは同等品）しか受け付けません。本稿では Scribe と Word の間の docx ブリッジ、レビュー周回をまたいだ版管理、そしていつ Word 側を離れ Markdown 側へ戻るべきかを扱います。
Scribe と Word：docx を橋渡しにした往復レビュー・ワークフロー
著者がどのツールで書いていても、2026年現在、Microsoft Word は出版・編集ワークフローで最も一般的な「中間形式」のままです。受諾編集者、ライン編集者、文芸エージェント、共同著者、伝統出版社の社内レビュー過程――その大半が依然として .docx を共通語として扱っています。何年も Markdown で書いてきても、伝統出版を飛ばしてセルフ出版する予定でも、パイプラインに他人が一人入った瞬間、docx は避けがたいものになります。本稿でいう「Word」は、docx を読み書きできる同等のツール――LibreOffice Writer、Apple Pages、Google Docs、WPS――も含みます。共同編集モデルと docx の限界は共通です。
Catalpas Atelier Scribe は Word の代替を目指しませんし、Word の共同編集機能と真正面から戦うつもりもありません。このパイプラインでは Scribe が「著者側――原稿と完成本」を担い、編集者側の Word が「コメント、修正、過程を歩むこと」を担います。両者は原稿を docx で交換します。問いは「どのツールか」ではなく、「いつ docx に原稿を渡し、いつ手元に戻すか」です。
現実：共同作業者は docx しか受け付けない
インディー著者にとって、この現実を受け入れるほうが抗うより安く済みます。組む編集者が技術的に熟達していて、原理上は Markdown を読めたとしても、いざレビュー段階に入ると、彼らに必要なのは「読む能力」ではなく、Word を中心に組まれた変更履歴＋コメントという共同編集の儀式一式です。Markdown には同等に成熟したビジュアルなレビュー体系がありません。CriticMarkup 風の記法は小さな輪の中なら機能しますが、「受諾編集者に本の改稿を二時間で通読してもらう」を成立させることはできません。
ですから現実的なワークフローは大抵こうなります。あなたは Scribe で本文を書き、章を整理し、ローカルで改稿する。レビュー周が必要になったら docx を書き出し、相手は Word（または LibreOffice、Pages、Google Docs）で変更履歴とコメントを付けて返してくる。あなたは Scribe に戻り、相手の修正を本文に「翻訳」して反映する。各往復に書式変換が付随するので、問いは「その変換をどれだけ安く済ませるか」になります。
docx ブリッジ：何が渡り、何が失われるか
Scribe が docx を書き出すとき（そして他者から返ってきた docx を Scribe に取り込むとき）、いくつかの内容の運命を事前に知っておく価値があります。
構造と章見出しは比較的忠実に残ります――見出し1／見出し2のマッピングは双方向で安定しています。つまり Word 側で誰かが章順を入れ替えたり見出し名を変えたりすると、Scribe は戻し時にそれを拾えます。
本文段落と基本書式（太字、斜体、ブロック引用）も往復を耐えます。ただし段落間隔、行間、フォントサイズは Scribe のプロジェクトレベル組版が制御するプロパティで、docx 内で手で弄るべきではありません。弄った瞬間、戻し時に Scribe の組版で上書きされるか、局所的な不整合を生みます。docx を渡すとき、編集者には明示的に伝えてください。「テキストと構造だけ変えてください――組版はこちらで統一します」。
変更履歴 はこのパイプラインで最も価値あるものです――どの段落が編集され、何が追加・削除され、誰が、いつ、を正確に教えてくれます。Scribe 側では、返ってきた docx を「参照ファイル」として保持し、修正を一つずつ確認し、受諾／却下を判断し、Scribe 内で手作業で適用していきます。自動マージは試みないこと――現状、Markdown ↔ docx の往復で変更履歴を無損失で保持できるツールはなく、最初に節約できる数分は後のトラブル対応で帳消しになります。
コメント も同様です。docx のコメントを Scribe 側の「やることリスト」として扱い、一つずつ処理し、Scribe で本文を編集し、終わったら元の docx をアーカイブします。コメントを本文と並べて Scribe プロジェクトに置く必要はなく、そうすべきでもありません。
失われるもの：複雑な表、埋め込みオブジェクト（数式、図表、SmartArt）、テキストボックス、カスタムスタイル。小説原稿の大半はこれらを使いません。図表の多いノンフィクションを書いているなら、事前に編集者と合意します。「図はそのままで、本文だけ見てください」――各周ごとに図を入れ直す手間を避けるために。
レビュー周回をまたいだ版管理
二、三周の往復レビューをするときには、ファイル名と保管が見た目以上に効きます。一つの信頼できるやり方：
- Scribe から編集者へ書き出すとき：
booktitle_v0.3_to-editor_20XX-MM-DD.docx - 編集者から返ってきたとき：
booktitle_v0.3_from-editor_20XX-MM-DD.docx - 処理が終わったら、Scribe プロジェクト側の版番号を
v0.4に上げ、次の周に入る
きれいなファイル名のためではなく、いつでも「いま編集者が持っているのはどの版か」「自分との間に版のずれはないか」に即答できるようにするためです。本文の最新版は常に Scribe プロジェクトに住む――書き出した docx はスナップショット、戻ってきた docx はフィードバック付きスナップショット、どちらも「真実の源」ではありません。
第二のルール：編集者の返しが届いたら、すぐ Scribe に飛び込まない。まず返ってきた docx を通読し、すべての修正とコメントに対して判断（受諾／却下／議論）を下し、それから決定を一括で Scribe に反映します。「docx を読みながら Scribe を編集する」よりずっと速く、版のずれも減らせます。
いつ Word 側を離れるか：知見は Markdown 側に沈める
最後の判断点：いつ docx ブリッジを経由するのをやめるか。
セルフ出版で、いまはまだ個人ドラフト段階なら、第一周はそもそも要りません――Scribe で書き切り、自分で再読し、改稿し、EPUB と印刷 PDF を出荷する。docx が見合うコストになるのは、「もう一人に原稿を見てもらい、その修正を受け入れる必要がある」ときだけです。
二、三周の実質的な編集と校正レビューが終わっているなら、最終ロックダウン段階は Scribe 側に完全に戻すべきです。ここから先、あらゆる変更は Scribe プロジェクト内でだけ起こす――「もう一通 docx を送ってサインオフをもらう」はしません。各往復は組版と書式のリスクを少しずつ持ち込みますし、印刷直前段階でそれを取り続ける理由はありません。
Word を完全に飛ばすべきなのは？ 共同作業者本人が Markdown 共同編集を受け入れ（少数の技術寄り編集者、密な共同執筆グループ）、変更履歴の儀式に頼らない場合――そのときは変更を git の差分や Scribe 内蔵の版比較で伝えられ、docx 往復より軽くなります。ただし相手の実際の習慣を誠実に見積もってください。「彼らが Markdown を使ってくれたら」を「実際に彼らがどう働くか」より優先させないこと。
こちらも合わせて
- Scribe のコラボレーション・ハブ ―― 他の執筆・ノート・レビューツールとのワークフローへの入り口
- Scribe と Microsoft Word の対比 ―― ツール比較から入りたい方へ