オンラインMarkdownエディタへ未公開原稿を入れてよいか判断するために、処理場所・実際の通信・ブラウザ保存・CSPの4点を順に確認します。Networkタブを使った確認方法も整理します。
Markdownをブラウザで編集できるツールは、インストール不要で便利です。ただ、未公開の記事や社内メモを貼る場合、「入力した本文がどこかへ送られないか」は確認しておきたいポイントです。
ここで「ブラウザ内処理です」「データを送信しません」と書いてあるだけで判断する必要はありません。Webページが許可している通信経路と、実際に発生した通信を利用者側から確認できます。
一方で、Content Security Policy（CSP）が設定されていれば何でも安全、という説明も正確ではありません。CSPには制御できる通信経路と、別のディレクティブを明示しなければ制御できない経路があります。
結論・前提・この記事でいう「安全」
ブラウザだけでMarkdownを扱うときは、①本文を端末内で処理する実装、②CSPで不要な通信経路を狭める設定、③Networkタブで実際の通信を確認する実測、の3つを分けて確認するのが実用的です。
この記事でいう「安全」は、主に編集・プレビュー・形式変換のためにMarkdown本文を不要に外部送信しないことを指します。端末全体、ブラウザ本体、インストール済み拡張機能、OSのマルウェアまでCSPが保証するという意味ではありません。
また、default-src 'none'だけを見て「送信経路がすべて塞がっている」と判断するのも不十分です。connect-srcはdefault-srcへフォールバックしますが、フォーム送信を制御するform-actionはフォールバックしません。
この違いまで確認すると、「送信しない」という宣言を、どこまでブラウザ側の制約で裏付けられるかが見えてきます。
まず「ブラウザで動く」と「ブラウザ内で処理する」を分ける
Webブラウザで使うツールには、処理場所が異なるものがあります。
サーバーへ送って処理する方式
入力したMarkdownやファイルをサーバーへ送り、サーバー側でPDF・DOCX等へ変換して結果を返します。
サーバー用ライブラリや高負荷な処理を使いやすい一方、変換対象の本文は端末の外へ出ます。
ブラウザ内で処理する方式
ページ表示に必要なHTML・CSS・JavaScript等を読み込んだ後、Markdownの解析、プレビュー、形式変換、ファイル生成をJavaScript等で端末内処理します。
この構成なら、編集や変換のためにMarkdown本文をサーバーへ送る必要はありません。
ただし、ローカル処理という実装方針と、ページが外部へ通信できるかどうかは別問題です。ページ内処理でも、別のJavaScriptが外部APIへアクセスできる構成は作れます。
そこでCSPとNetworkタブを確認します。
Word（DOCX）への変換を例に、ブラウザ内処理とサーバー変換の違いを見たい場合は、MarkdownをWordに変換する方法で具体的に整理しています。
CSPは「Webページに許す通信・読み込み」をブラウザが強制する仕組み
Content Security Policyは、スクリプト、画像、フォント、フレーム、ネットワーク接続などについて、Webページが利用できる送信先・取得元を制限する仕組みです。
たとえば、ブラウザ完結ツールの強い出発点としては次のような考え方があります。
Content-Security-Policy:
default-src 'none';
script-src 'self';
style-src 'self';
font-src 'self';
img-src 'self' data:;
connect-src 'none';
form-action 'none';
base-uri 'none';
これは推奨構成の一例です。実際のサイトでは必要な機能だけを許可し、配信されているレスポンスヘッダーそのものを確認する必要があります。
default-src 'none'から始めるのは強い設計ですが、各ディレクティブが何を制御しているかを理解した方が誤解がありません。
connect-srcが止めるのは、JavaScriptからの代表的な接続
MDNの2026年版ドキュメントでは、connect-srcはスクリプトインターフェイスからの接続先を制限し、次のようなAPIが対象とされています。
fetch()fetchLater()XMLHttpRequestWebSocketEventSourceNavigator.sendBeacon()<a>要素のping
connect-srcを明示していない場合はdefault-srcがフォールバックします。
そのため、
Content-Security-Policy: default-src 'none'
だけでも、別途connect-srcを許可していなければ、これらの接続は'none'の制約を受けます。
ただし、ここから「外部送信はすべて不可能」と結論づけることはできません。
重要：form-actionはdefault-srcへフォールバックしない
HTMLフォームの送信先を制御するのがform-actionです。
Content-Security-Policy: form-action 'none'
とすれば、その文書からのフォーム送信を許可しない方針を示せます。
ここがconnect-srcとの重要な違いです。
MDNはform-actionについて、default-srcによるフォールバックはなく、未設定なら送信先を制限しないと明記しています。W3CのCSP仕様でも、default-src 'none'を設定していてもform-actionがなければフォーム送信は許可され得ると説明されています。
したがって、
Content-Security-Policy: default-src 'none'
だけを見て「本文を送る手段が構造的にゼロ」と説明するのは過剰です。
CSPで“送れない範囲”を説明するときは、どのディレクティブでどの経路を閉じているかまで示す必要があります。
外部画像も通信経路になる
Markdownには外部画像を埋め込めます。
プレビュー時にこのURLをそのまま画像として読み込めば、ブラウザはexample.comへHTTPリクエストを送ります。
本文そのものをPOSTしていなくても、接続先には通常のWebリクエストに伴うIPアドレス等の情報が伝わります。また、画像URLに原稿由来の情報を埋め込むような悪意ある入力を無制限に許す設計なら、データ流出経路として悪用される余地があります。
この経路をCSPで制限するのがimg-srcです。
img-src 'self' data:;
とすれば、同一オリジンとData URL以外の画像取得を許可しない構成にできます。
oka-projectでは、ブラウザ完結ツールの監査中に外部画像への経路が残っていたことを確認し、img-srcを締める方針へ変更した経緯があります。
ブラウザ完結ツールの「送信しない」を、約束ではなく構造にする
base-uriもdefault-srcとは別に見る
base-uriは、文書内の<base>要素で使えるURLを制限します。
MDNでは、base-uriにもdefault-srcのフォールバックはないと説明されています。未設定なら任意のURIを指定できます。
Markdownエディタの本文変換そのものとは直接関係しない場合もありますが、厳しいCSPを組むなら、
base-uri 'none';
のように不要な機能を明示的に閉じる方が、ポリシーの意図が明確になります。
「default-src none」は強い出発点だが、証明書ではない
CSP Level 3では、default-srcは他のfetchディレクティブのフォールバックとして機能します。
たとえば未指定のconnect-src、img-src、font-src、media-src、frame-srcなどはdefault-srcを参照します。
一方、form-actionやbase-uri、frame-ancestorsのようにフォールバックしないディレクティブもあります。
そのため、CSPを見るときは次のように考える方が正確です。
default-src 'none'：まず広く閉じる出発点script-src：実行できるスクリプトの取得元connect-src：fetch/XHR/WebSocket等の接続先img-src：画像取得先form-action：フォーム送信先base-uri：<base>で指定できるURL
「CSPあり / なし」ではなく、許可リストの中身を見ることが重要です。
Yomuでは「本文処理」と「通信制約」を別々に確認する
ブラウザMarkdownエディタ「Yomu」は、ChatGPTやClaudeで作ったMarkdownを端末内で編集・変換することを前提にしています。
Yomuは2026年9月1日に公開しました。本文のプレビューやnote・WordPress・はてな記法・Word等への変換では、Markdown本文を外部の変換APIへ送らず、ブラウザ内で処理する設計を採っています。
さらに、不要な通信先をCSPで狭めることで、「ローカル処理です」という説明だけに頼らず、ブラウザ側の制約でも通信経路を限定する考え方を取っています。
ただし、設計方針と実際に配信されている設定は分けて確認するのが重要です。利用者側でも、以下の方法でCSPヘッダーとNetwork通信を確認できます。
Yomuをnote向け原稿変換に使う具体例は、ChatGPT・Claudeをnoteにコピペすると崩れる？で確認できます。
WordPress向けの変換例は、ChatGPTのMarkdownをWordPressに貼ると崩れる？で確認できます。
自分で確認する方法1：ページのCSPヘッダーを見る
ChromeやEdgeなら開発者ツールで確認できます。
1. 開発者ツールを開く
WindowsではF12またはCtrl + Shift + I、MacではCommand + Option + Iなどで開けます。
2. Networkタブを開いてページを再読み込みする
ページ本体のDocumentリクエストを選択します。
3. Response HeadersからContent-Security-Policyを探す
ここで実際にブラウザへ配信されたポリシーを確認します。
見るべきなのはdefault-srcだけではありません。
connect-srcがどこを許可しているかimg-srcに外部ドメインやhttps:全体が入っていないかform-actionが必要以上に開いていないかbase-uriがどう設定されているか- 外部スクリプトを許可している場合、その必要性は何か
を確認します。
自分で確認する方法2：入力・変換時の通信をNetworkタブで見る
CSPの設定だけでなく、実際に編集操作を行って通信を観察します。
1. Networkログをクリアする
ページ表示に必要だった通信と、編集操作で発生する通信を分けるため、読み込み後にログを消します。
2. 架空の検証用文字列を入力する
実際の機密情報をテストに使う必要はありません。
YOMU-NETWORK-TEST-2026-09-06
3. プレビュー・変換・ファイル書き出しを操作する
普段使う予定の操作を一通り行います。
4. 新しいリクエストを確認する
新規通信が出た場合は、送信先、HTTP Method、Request Payload、Query String等を確認します。
Markdown本文を変換サーバーへ送る構成なら、POSTやfetch等の通信として確認できる場合があります。
追加通信が見つからなければ、そのブラウザ・その操作・その時点の実装ではNetworkタブ上に本文送信を確認できなかったと言えます。
「一度見えなかったからサービスの全動作が数学的に証明された」とまでは言いません。
Networkタブで見るときの落とし穴
ページ読み込みの通信は普通にある
ブラウザツールはWebページなので、最初にHTML、JavaScript、CSS等を取得します。
「通信が1件でもあればローカル処理ではない」わけではありません。確認したいのは、Markdownを入力・変換した際に原稿データを伴う追加通信が発生するかです。
操作ごとに見る
編集時は通信しなくても、AI校正、クラウド保存、共有、画像取得等の別機能で通信する可能性があります。
通常編集、DOCX出力、画像処理、AI機能など、機能単位で確認します。
DevToolsは実測であって、コード監査の代わりではない
Networkタブは非常に有用ですが、テストしていない条件や将来の実装まで保証するものではありません。
可能ならCSP、実装、Network実測を組み合わせます。
localStorageへの保存は「サーバー送信」と別の論点
ブラウザエディタは、入力内容をlocalStorageやIndexedDBへ保存して再読み込み後に復元することがあります。
これは通常、ブラウザプロファイル内の端末側ストレージであり、サーバーへ送信することとは別です。
ただし共有PCでは、次に同じブラウザプロファイルを使う人から見える可能性があります。
重要な原稿なら、
- 共有端末を避ける
- 作業後に本文を消す
- ローカル保存の有無を確認する
- 必要なら仕事用ブラウザプロファイルを分ける
といった運用も必要です。
ブラウザ拡張機能はページのCSPだけでは管理できない
CSPはWebページに対するブラウザのセキュリティ制約です。
ユーザーがインストールしたブラウザ拡張機能は、その権限によってページ内容を読み取れる場合があります。ページ側のCSPだけで、端末に入った全拡張機能の挙動を保証することはできません。
機密性の高い原稿を扱う場合は、「すべてのサイトのデータの読み取りと変更」等の強い権限を持つ拡張を確認し、不要なものを減らす方が安全です。
AI機能は通常編集と分けて考える
「AIで続きを書く」「文章を校正する」といった機能は、外部AI APIを使う構成なら本文の一部または全部を送る必要があります。
これはMarkdownのローカルプレビューとは別の処理です。
AI機能付きエディタを見るときは、
- 通常編集でも外部送信するのか
- AI操作を実行したときだけ送るのか
- どの範囲を送るのか
- 送信先はどこか
- 利用者が送信前に認識できるか
を分けて確認します。
「エディタ本体はブラウザ内処理、AI機能だけ明示的に外部送信」という設計も可能です。
機密性に応じて、確認レベルを変える
公開済みREADMEと、公開前の契約資料では必要な確認レベルが違います。
公開情報を編集するだけなら
利便性を優先し、通常のプライバシー説明を確認するだけでも十分な場合があります。
未公開記事・業務原稿なら
処理場所、Networkタブ、保存先、外部画像取得まで確認すると判断しやすくなります。
高機密文書なら
Webツールを使うこと自体が組織ポリシーに適合するか、端末・ブラウザ・拡張機能を含めて確認する必要があります。ブラウザ完結という理由だけで利用可とは限りません。
ブラウザMarkdownエディタを見るときのチェックリスト
確認項目をまとめると次のようになります。
- Markdown本文の処理はブラウザ内か、サーバー変換か
connect-srcはどこを許可しているかimg-srcで外部画像取得をどこまで許可しているかform-actionは明示されているかbase-uri等、default-srcへフォールバックしない項目はどうなっているか- Networkタブで編集・変換時の追加通信があるか
- localStorage / IndexedDB等へ本文を保存するか
- ブラウザ拡張機能に強い権限がないか
- AI機能を使う場合、どの本文をどこへ送るか
- 自分が扱う文書の機密性に、その運用が合っているか
まとめ
ブラウザだけでMarkdownを安全に編集できるかを判断するとき、「オンラインだから危険」「CSPがあるから安全」のどちらかで決める必要はありません。
確認すべきなのは、本文をどこで処理するか、Webページにどの通信経路を許しているか、実際の操作で何が通信されたかです。
default-src 'none'は強い出発点ですが、それだけですべての送信経路が閉じるわけではありません。connect-srcはdefault-srcへフォールバックする一方、form-actionはフォールバックしないため、フォーム送信を閉じたいなら別途設定が必要です。外部画像はimg-src、<base>はbase-uriというように、経路ごとに見る必要があります。
Yomuでは、Markdown本文の編集・変換をブラウザ内で行い、CSPで不要な通信経路を狭める設計を採っています。ただし、どのWebツールでも設計上の宣言だけでなく、実際のレスポンスヘッダーとNetworkタブの挙動を見るという考え方を持っておくと、利用者側でも判断しやすくなります。
ブラウザ内でMarkdownを編集し、公開先ごとに変換する用途では、Yomuを使えます。