local-firstなMarkdown公開を設計する理由——原本は手元、共有だけクラウドへ

AIエージェントに仕様書や設計メモを書かせると、Markdownファイルは驚くほど速く増えます。ところが、誰かに見せる段になると、別のサービスへ貼り直し、返ってきた指摘をまたAIへ渡す作業が残ります。文章を書く時間は短くなったのに、共有の往復だけが手作業のままです。

この摩擦を減らすため、個人開発中の「mdrelay」では、手元のMarkdownを原本にして、公開用のHTMLだけをクラウドへ送る構成を検討しています。大切なのはクラウドを使わないことではありません。編集の主導権を手元に残し、クラウドには共有の役割だけを任せることです。

なお、mdrelayは2026年6月19日時点の設計資料に基づく構想段階です。この記事で触れるローカルプレビュー、ワンボタン公開、コメント連携は、提供開始済みの機能や利用実績ではありません。

local-firstなMarkdown公開とは何か

local-firstなMarkdown公開とは、手元の .md ファイルを正本として扱い、公開時に共有用の成果物を生成する設計です。サーバー上の文書を唯一の原本にせず、ローカルのファイルを編集の起点にします。

「ローカルだけで完結する」という意味ではない

local-firstは、ネットワークやクラウドを全面的に排除する考え方ではありません。Ink & Switchは2019年4月の論考で、ローカル端末上のデータを主たるコピーとして扱うと定義しました。サーバーは、複数端末での利用や共同作業を助ける副次的な役割です。

この整理をMarkdown公開へ当てはめると、役割分担は明快です。執筆、履歴管理、バックアップ方法の選択は手元に残します。公開URLの発行、HTML配信、読み手からのフィードバック受付はサーバーへ任せます。

Local-first software: You own your data, in spite of the cloud

Ink & Switchが2019年に公表したlocal-first softwareの論考。オフライン利用、長期保存、共同作業、データ所有の7つの理想を整理しています。

https://www.inkandswitch.com/essay/local-first/

Markdownを原本にする理由

Markdownはプレーンテキストなので、特定の編集画面がなくても読めます。任意のエディターで修正でき、Gitで差分を確認でき、別の変換ツールへ渡すことも可能です。サービスのUIやAPIが変わっても、原稿そのものを移すための専用エクスポートを待つ必要がありません。

AIエージェントとの相性もここにあります。エージェントはファイルを読み、差分を作り、レビュー可能な変更として残せます。弊社でClaude Codeのマルチエージェントチームを組んだ記録でも、設計書やレビュー結果をMarkdownに残しました。判断の経緯を後から追える点が役立っています。

なぜ編集と公開を分けるのか

編集と公開を分ける理由は、原稿の所有権、公開範囲、レビュー手順を1つのサービスに抱え込ませないためです。公開は原本の移動ではなく、その時点の状態から共有用スナップショットを作る操作として扱います。

公開先が止まっても原稿は残る

サーバー上の文書だけを原本にすると、障害やサービス終了時に編集と閲覧の両方が影響を受けます。手元のMarkdownを正本にすれば、公開先が使えない間も執筆を続けられます。別の公開手段へ切り替えるときも、手元のファイルから再生成できます。

ただし、ローカルに置くだけで安全になるわけではありません。端末故障、誤削除、ランサムウェアへの備えは利用者側に移ります。Ink & Switchの論考も、データを所有することにはバックアップや整理の責任が伴うと指摘しています。local-firstは責任が消える設計ではなく、責任を引き受ける場所を選べる設計です。

公開範囲を成果物ごとに決められる

手元には下書き、社内メモ、公開原稿が同じフォルダーに並ぶことがあります。フォルダー全体を同期する設計では、共有してよい範囲の判断が曖昧になりがちです。

そこでmdrelayの構想では、選んだファイルだけを明示的に公開し、読み取り専用のHTMLへ変換します。公開物は原本そのものではなく、公開時点のスナップショットです。何を見せるかをファイル単位で選び、公開停止後もローカルの原本には影響を与えない境界を目指しています。

編集環境を固定しない

ブラウザ内エディターを中心にすると、サービス側は入力体験まで作り込む必要があります。しかし、Markdownを書く人はVS Code、Neovim、Obsidian、AIエージェントなど、すでに好みの道具を持っています。

公開ツールがエディターまで置き換える必要はありません。ファイル形式と公開手順の境界を安定させれば、書く道具は利用者が選べます。この分離は機能を減らす妥協ではなく、責務を小さく保つための判断です。

Markdown公開の往復をどう設計するか

公開の価値はURLを発行して終わりではありません。読み手の反応が書き手へ戻り、次の修正へつながって初めて往復になります。mdrelayでは、非同期コメントをAIエージェントへ戻せる形に整える流れを検討しています。

想定する5段階

設計資料上の流れは次の5段階です。

人またはAIエージェントが、ローカルのMarkdownを作成・更新する
公開対象を選び、読み取り専用HTMLとして共有する
読み手が公開ページへ非同期コメントを残す
書き手がコメントをローカルへ取り込む
対象箇所とコメントをAIへの修正指示に変換し、原本を更新する

ここで重要なのは、読み手が原本を直接編集しないことです。コメントは変更要求であり、採用するかどうかは原本を持つ側が判断します。公開ページと原本の間に承認の境界を置けば、AIが受け取った指摘を無条件に反映する事故も避けやすくなります。

コメントをそのまま命令として実行しない

公開ページへの入力は、信頼できる指示とは限りません。誤解、矛盾した要望、悪意ある文面も入り得ます。そのため、コメントをAIへ渡す機能を作る場合も、「外部から受け取った参考情報」として区別する必要があります。

設計上は、対象の見出しや位置、コメント本文、投稿時刻などを構造化して取り込みます。そのうえで、人が内容を確認し、修正方針を決めてからエージェントへ渡します。コメント受信から原本更新までを自動で直結させないことが、便利さと安全性の境目です。

公開ページのコメントは外部入力です。AIエージェントへの指示へ変換するときも、内容を信頼済みデータとして扱わず、人による採否判断と差分レビューを残す必要があります。

MVPでは何を作らないのか

最初のMVPでは、リアルタイム共同編集や多機能なオンラインエディターを主役にしない方針です。検証したいのは、「手元で書く、軽く公開する、反応を手元へ戻す」という一本道に需要があるかどうかだからです。

リアルタイム共同編集を外す

同じ文書を複数人で同時編集する機能は便利ですが、同期、競合解決、接続維持、権限管理などの設計範囲が一気に広がります。今回の用途は、書き手が原本を管理し、読み手は非同期でレビューする形です。ここにリアルタイム共同編集を加えると、確認したい価値よりも同期基盤の実装が先行します。

local-firstの理想には共同作業も含まれますが、すべてを最初から満たす必要はありません。ファイルを原本にすること、オフラインで執筆できること、別の道具へ持ち出せることから始められます。どの理想を満たし、どこを後回しにするかを明示するほうが、製品の現在地を正確に伝えられます。

課金や高度な連携を先に約束しない

2026年6月19日の設計資料には、有料プランやMCP連携の案もあります。しかし、価格、転換率、利用者数は未実測です。この記事では構想の存在だけを示し、提供予定日や成果を断定しません。

先に検証すべきなのは、ローカルプレビューが使われるか、公開URLが繰り返し作られるか、コメントが次の修正へ役立つかです。高度な連携や課金は、この往復が実際に使われることを確認した後の話になります。

実装順は価値の順にする

最小構成は、ローカルプレビュー、明示的な公開、読み取り専用ページ、非同期コメント、コメントの取り込みです。この順番なら、各段階で前の価値を確認できます。

技術選定は重要ですが、local-firstである理由は特定の言語やフレームワークでは決まりません。「どこに正本があるか」「ネットワークなしで何ができるか」「サービス停止後に何が残るか」という振る舞いで判断します。

local-first設計で見落としやすい点は何か

local-firstを掲げるだけでは、データ所有や長期保存は実現しません。ファイル形式、公開時の複製、削除、バックアップ、外部入力の扱いまで、一貫した境界が必要です。

公開した複製は別に管理する

原本がローカルにあっても、公開先には本文の複製が残ります。公開停止時に何を削除するか、キャッシュやバックアップへどの程度残るか、共有URLを失効させられるかを決めなければなりません。

また、原稿に秘密情報が含まれていないかは公開前に確認する必要があります。「ローカルにあるから安全」なのは公開する前までです。公開操作は明示的にし、対象ファイルと生成物をプレビューできるようにするのが妥当です。

Markdownだけでは表示の再現性が決まらない

Markdownは持ち運びやすい一方、方言や拡張記法によって表示が変わります。ローカルプレビューと公開ページで変換設定が違えば、手元で確認した内容と共有結果がずれます。

設計資料では、ローカルと公開側で同じ変換設定とテンプレートを使う案にしています。正本が同じでもレンダリングが違えば、レビュー対象は一致しません。原稿の可搬性と、公開結果の再現性は分けて確認する必要があります。

FAQ：クラウドを使った時点でlocal-firstではないのか

クラウドを使うこと自体は矛盾しません。ローカルのコピーが主であり、クラウドが同期や共有を補助する設計なら、local-firstの考え方と両立します。反対に、ローカルファイルが単なる一時キャッシュで、サーバーがなければ編集も持ち出しもできないなら、local-firstとは呼びにくくなります。

FAQ：Markdownにすれば自動的にlocal-firstになるのか

ファイル形式だけでは決まりません。サーバー上のMarkdownだけを正本にして、利用者が自由に取得・編集できなければ、拡張子が .md でも主導権はサーバー側にあります。保存場所、編集権限、エクスポート、オフライン動作を合わせて評価する必要があります。

まとめ

local-firstなMarkdown公開で守りたいのは、特定ツールへのこだわりではなく、原本を手元に残したまま共有の便利さを足すことです。編集と公開を分離すれば、書く道具を固定せず、公開先が変わっても原稿を持ち続けられます。

一方で、バックアップ、公開先に残る複製、外部コメントの安全な扱いは別途設計が必要です。Markdownを選ぶだけで問題が解けるわけではありません。

mdrelayは、ローカルで書き、選んだものだけを公開し、返ってきた声を次のAI指示へつなぐ一本道を検討しています。現時点では未実装の構想です。まずは「手元の原本を失わず、共有の往復を短くできるか」を小さく検証していきます。