AI原稿を複数媒体へ使い回す方法｜Markdownを原本にする

ChatGPTやClaudeで記事本文を作るところまでは速くても、実際に公開する段階で手作業が残ります。

WordPressへ入稿するために見出しやリストを整える。既存のはてな記法記事へ追記するために、Markdownをはてな記法へ変える。noteやWordへ持っていくときも、公開先ごとの違いを確認する必要があります。

このとき、AIへ毎回「WordPress向けにして」「はてな記法で出して」と頼む方法もあります。ただ、形式変換だけが目的でも本文の言い回しが変わったり、リンク・表・見出しの変換漏れを確認する手間が発生します。

そこで、AIにはMarkdownまで作ってもらい、公開先固有の形式変換は別工程に分けると運用が安定します。Markdownを原本として持てば、内容修正と媒体変換も分離できます。

結論：Markdownを1つの原本にし、公開先ごとに最後だけ変換する

ただし、原本管理が必要になるのは主に同じ内容を複数の公開先・提出先へ使う場合です。1つの媒体だけなら、その媒体の標準機能を使う方が工程は少なくなります。

Yomuを使うこと自体が目的ではありません。 複数の出口を持つ原稿で、内容の正本と公開用の形式を分ける必要がある場合に使います。

基本の考え方は次の通りです。

ChatGPT / Claude
      ↓
   Markdown原稿
      ↓
   人が確認・修正
      ↓
 ┌────┬────────┬────────┬──────┬──────┐
note  WordPress  Google Docs  はてな  Word / PDF / HTML

内容の修正はMarkdown原稿へ集め、noteやWordPressなどは公開用の出力として扱います。

この方法が向くのは、同じ文章を2つ以上の媒体へ使う場合です。

noteだけで完結するならnote上で書く方が簡単なこともあります。Wordだけが最終提出物ならWordで直接仕上げても構いません。

複数媒体へ展開するときに初めて、原本を1つに保つ価値が大きくなります。

なぜAIに公開先ごとの形式まで作らせないのか

生成AIは、文章を考えたり構成を作ったりする用途では非常に便利です。

一方、WordPressのブロック形式や、はてな記法のように変換規則が決まっている処理まで毎回生成AIへ任せると、変換以外の変更が混ざることがあります。

たとえば、

Markdown原稿
  ↓ AIへ「はてな記法にして」
はてな記法版
  ↓ AIへ「WordPress向けにして」
WordPress版

という流れでは、記法だけではなく本文やリンクの表現まで変わっていないか確認する必要があります。

さらに媒体ごとに別原稿を作ると、あとで事実誤認を一つ直したときに、どの版が最新版か分かりにくくなります。

そこで、文章生成と形式変換を分けます。

実際の管理構造は次のようになります。

Markdown原本
  ├─ 内容の正本
  ├─ 見出し構造
  ├─ リンク
  └─ 表・リスト

公開時に変換
  ├─ note
  ├─ WordPress
  ├─ はてな
  ├─ Word
  └─ PDF / HTML

と分けます。

原本にMarkdownを使う理由

Markdownでなければならないわけではありません。

重要なのは、媒体固有の書式へ早い段階で固定しないことです。

Markdownが使いやすい理由は、見出し、リスト、リンク、引用、コード、表などの文章構造をテキストとして持てるからです。

## 調査結果

**結論**としてAを採用します。

### 理由

- 理由1
- 理由2

[参考資料](https://example.com)

この原稿なら、内容を人が読める状態のまま保存でき、必要に応じて別形式へ変換できます。

1. AIには「媒体専用形式」より先にMarkdownで原稿を作らせる

最初の段階では、note専用、WordPress専用などに寄せすぎず、一般的なMarkdownとして構造を作ります。

たとえばブログ記事なら、次の程度の指定で十分です。

記事本文をMarkdownで作成してください。
本文の主要見出しはH2、その下位をH3にしてください。
記事タイトルは本文に重複させないでください。
表や箇条書きは必要な場合だけ使ってください。

ここで重要なのは、AIの出力をそのまま公開しないことです。

事実、数字、リンク、固有名詞、文章の重複、見出し構造を人が確認し、公開先へ変換する前に内容を確定します。

2. 内容修正はMarkdown原本へ戻す

noteへ貼ったあとで誤りを見つけた場合も、noteだけ直して終わらせず、原本側へ修正を戻します。

誤りを発見
   ↓
Markdown原本を修正
   ↓
必要な媒体へ再出力

こうすると、「noteは直っているのにWordPressには古い数字が残っている」という状態を減らせます。

すべてを毎回再投稿する必要はありません。重要なのは何が正本なのかを決めることです。

公開後の修正漏れを減らす台帳の持ち方

同じ記事を3媒体へ出したあと、日付・数字・リンクを修正する場合、各媒体を個別に編集するだけでは最新版が分からなくなります。原本のファイル名と更新日を固定し、必要な派生先を簡単な表で管理すると、変更箇所を追いやすくなります。

例えば記事の統計値を直すなら、Markdown原本→各媒体の本文→表内の数値→概要文／SNS告知の順で変更対象を確認します。ただし、公開先のコメントや読者による引用まで自動的に変更されるわけではありません。

この方法はMarkdownに限らず、ひとつの原稿を複数の公開形態へ展開するときの版管理にも使えます。

公開先ごとの変換

3. noteへ出す

noteはMarkdownショートカットを利用できますが、完成済みMarkdownを貼ったときにすべての要素がそのまま変換されるとは限りません。

短い文章なら、ChatGPTやClaudeの表示済み文章を直接貼って問題なければ、それが最短です。

長文で##や**が残る、表を別表現へ変えたい、といった場合だけ変換工程を入れます。

具体的な切り分けは、ChatGPT・Claudeをnoteにコピペすると崩れる？で整理しています。

Google Docsへ出す

Google DocsだけへMarkdownを移したい場合は、まずGoogle公式の機能を使います。

PC版Google DocsではMarkdownを有効にすると、右クリックからPaste from Markdownを使えます。Markdownファイルのインポート・エクスポートやCopy as Markdownにも対応しています。

そのため、Google Docsだけが最終目的ならYomuを挟む必要はありません。

具体的な手順と通常貼り付けとの違いは、Google DocsでMarkdownを使う方法で整理しています。

一方、同じ原稿をDocsだけでなくnote・WordPress・Wordにも使うなら、Google Docsを正本にするよりMarkdown原本から各媒体へ出す方が差分を管理しやすくなります。

4. WordPressへ出す

WordPress Gutenbergはブロック単位で文章を管理します。

表示済みのAI回答を直接貼って問題なくブロック化されるなら、その方法で十分です。

一方、raw Markdownを長文で安定して移したい場合は、Gutenbergの標準ブロック形式へ変換してコードエディター経由で読み込ませる方法があります。

詳しくは、ChatGPTのMarkdownをWordPressに貼ると崩れる？で扱っています。

WordPress独自のCTA、FAQ、画像、商品ボックスなどは原本へ無理に入れず、公開先側の最終編集として追加する方が管理しやすくなります。

5. はてなブログへ出す

はてなブログにはMarkdownモードがあるため、新規記事ならそのままMarkdownを使える場合があります。

つまり、はてなブログへ出すからといって毎回はてな記法へ変換する必要はありません。

既存記事がはてな記法で作られている、運用をはてな記法へ揃えたい、といった場合だけ変換します。

判断基準は、ChatGPTのMarkdownをはてなブログに貼る方法で整理しています。

6. Wordへ出す

WordではMarkdownソースをそのまま貼るより、文書構造をDOCXへ変換した方が、見出しやリストを再編集しやすくなります。

ただし、会社指定のフォント、余白、ページ番号、ヘッダー・フッターなどはMarkdownに含まれていないため、Word側で最終調整が必要です。

MarkdownをWordに変換する方法｜コピペ・DOCX・Pandocでは、ブラウザ変換とPandocの使い分けまで整理しています。

Wordだけが最終成果物で、他媒体へ展開しないなら、最初からWordで編集した方が速い場合もあります。

7. PDF・HTMLへ出す

PDFは配布・閲覧用の固定形式、HTMLはブラウザで読む形式として使えます。

同じMarkdown原本を持っていれば、用途に応じて別の出力を作れます。

PDFについては、編集用の原本ではなく配布時点のスナップショットとして扱う方が管理しやすくなります。

Yomuを使うかの判断

Yomuを使う場合の位置づけ

Yomuは、媒体ごとのCMSそのものを置き換えるツールではありません。

主目的は、AIで作ったMarkdownを確認し、WordPress・はてな記法・note・Wordなど公開先に合わせた形式へ変換する中間地点になることです。

AIには文章生成までを任せ、Yomuには規則ベースで処理できる媒体変換を任せる、という分担を想定しています。

Yomu — ブラウザで使えるMarkdownエディタ

想定する流れは次の通りです。

AIで下書き
   ↓
YomuでMarkdownを編集・確認
   ↓
必要な出力を選ぶ
   ↓
各媒体で最終確認・公開

Yomu上で文章を直した場合は、そのMarkdownを原本として保存します。

媒体側で大きな内容修正をした場合は、必要に応じてMarkdown側へ戻します。

Yomuを使わなくてよいケース

この運用を全員に勧める必要はありません。

noteだけ使う

直接noteで書く、またはAI回答を直接貼る方が簡単です。

Wordだけ提出する

最初からWordで仕上げる方が工程が少ない場合があります。

GitHub中心で管理する

VS Code等の開発環境を使う方が自然です。

大量のノートを知識管理する

Obsidian等のナレッジ管理ツールが向いています。

Yomuの価値が出るのは、一つの原稿を複数の公開先・提出先へ運ぶ作業が繰り返し発生する場合です。

用途別に他ツールも含めて選びたい場合は、Markdownエディタおすすめ比較【2026年】を参照してください。

「原本」と「公開版」の差分をどう扱うか

媒体ごとに必要な要素は完全には同じではありません。

noteでは見出し画像を追加する。

WordPressではCTAや構造化されたブロックを追加する。

Wordではページ番号を入れる。

これらまでMarkdown原本へ無理に戻す必要はありません。

分け方は次のようにします。

原本へ戻すもの

• 本文の事実修正
• 数字
• 固有名詞
• 見出し構成
• リンク先
• 説明そのもの

公開先だけに残すもの

• CMS固有の装飾
• CTA
• 埋め込み
• ページ番号
• テーマ固有レイアウト
• 媒体固有の画像設定

内容と媒体固有UIを分けることが、原本方式を続けるポイントです。

ファイル名でも版を分かりやすくする

複雑な管理システムを作らなくても、ファイル名を決めるだけで管理しやすくなります。

article.md          ← 原本
article.docx        ← Word出力
article.pdf         ← 配布用
article.html        ← HTML出力

原本名を固定し、出力形式だけ拡張子で分けます。

日付入りバックアップを取るなら、

archive/article-2026-08-28.md

のように別フォルダへ残す方法もあります。

公開前の原稿では処理場所も確認する

複数媒体へ展開する原稿には、公開前の記事、業務資料、未発表情報が含まれることがあります。

変換ツールを使う場合は、便利さだけでなく本文をどこで処理するかも確認します。

オンラインMarkdownエディタは安全？では、ブラウザ内処理、CSP、Networkタブ、ローカル保存を分けて確認する方法を解説しています。

まとめ

ChatGPTやClaudeで文章を作れるようになっても、WordPressへの入稿や、はてな記法など媒体固有形式への変換作業は残ります。

この部分まで生成AIへ毎回任せるのではなく、AIにはMarkdownまで作らせ、Markdownを原本として内容を確定し、その後の形式変換を分離すると扱いやすくなります。

媒体が1つだけで直接貼り付けて問題がないなら、この運用は不要です。

Yomuは、AIで作ったMarkdownをWordPress・はてなブログ・note・Word・PDF・HTMLなどへ持っていく作業が繰り返し発生する人向けに、編集と変換の中間地点として設計しています。Google Docsのように公開先側に十分なMarkdown取り込み機能がある場合は、その標準機能を優先します。

最終目的はYomuを使うことではなく、AIで作った原稿を何度も生成し直さず、公開先ごとの手戻りを減らすことです。