---
title: なぜ Chromium 系だけがディスクに直接書き込めるのか
nav: ブラウザとファイルアクセス
order: 5
description: File System Access API とは何か、なぜ Firefox と Safari はダウンロードしかできないのか、そしてなぜ再読み込みのたびに許可を求められるのか。
updated: 2026-08-12
---

## 一言でいうと

「ディスク上のそのファイルを上書きする」には **File System Access API** が必要で、
現時点でその完全版を実装しているのは Chromium 系ブラウザ（Chrome、Edge、Brave、Arc、Opera）だけです。

## そもそも Web ページはファイルに触れない

従来の `<input type="file">` がページに渡すのは**スナップショット**です。ファイルを選ぶとページは内容を読めますが、
そこから戻り道はありません。編集結果を返すにはダウンロードを発生させ、あなた自身が元のファイルを置き換えるしかない —— つまり
「ダウンロード → ファイルマネージャーを開く → 元の場所へ戻す → 上書きを確認」という 4 段階の儀式です。

File System Access API が変えたのはこの点です。ユーザーが明示的に選んだあとは、ページが
**書き込み可能なハンドル**を保持でき、保存は本当に同じ場所へ書き戻されます。

| このエディターが使っているもの | 用途 |
| --- | --- |
| `showDirectoryPicker()` | フォルダを開き、中の `.md` を一覧する |
| `showSaveFilePicker()` | 名前を付けて保存 |
| `createWritable()` | 同じファイルに新しい内容を書き戻す |

## Firefox と Safari の状況

どちらも仕様のうちサンドボックス側（OPFS、ページ専用の非公開ストレージ）は実装していますが、
**ユーザーが自分で選んだフォルダ**に届く側は実装していません。後回しになっているのではなく、
プライバシー上のトレードオフをより慎重に評価しているためです。
ユーザーのディレクトリに書き込み続けられる Web API は、悪用されたときに取り返しがつきにくいからです。

そのため Firefox と Safari では、このエディターは編集・プレビュー・コピーはでき、
保存は新しいファイルのダウンロードに切り替わります。壊れているのではなく、ブラウザがその鍵を渡していないだけです。

## なぜ再読み込み後にまた許可が必要なのか

許可は**今回のブラウジングセッション**に紐づいています。再読み込みしても、ページは「どのフォルダだったか」は覚えています
（ハンドルは IndexedDB にあるので、サイドバーに **📂 再度開く: フォルダ名** を出せます）。
しかし実際に読み書きするには、もう一度あなたの同意が必要で、その同意はあなたのクリックから始まらなければなりません。
ページが黙って求めることはできない仕組みです。

だからこそ流れは「再度開くを押す → ブラウザが尋ねる → 許可する」であって、自動復元ではありません。
ひと手間増えるのは確かに面倒ですが、それは「知らないうちに Web ページがディスクに書き込むことはない」という保証そのものです。

## その他の前提

- **HTTPS が必要です。** この API は安全なコンテキストでのみ利用できます（`localhost` は例外）。
- **ユーザー操作が必要です。** フォルダの選択も名前を付けて保存も、実際のクリックから始まる必要があります。
- **書き込めないファイルもあります。** ドロップして読み込んだファイルは通常読み取り専用です。その場合ステータスバーに
  「上書き不可 — 名前を付けて保存」と表示されるので、**名前を付けて保存** を使ってください。

## ファイルは本当に端末から出ないのか

出ません。このエディターにはファイルを受け取れるバックエンドがありません。
サイトの役目は HTML を 1 つ渡すことだけで、読み込み・解析・プレビュー・書き戻しはすべてブラウザ内で起こります。
データの取り扱いの詳細は[プライバシーポリシー](/ja/privacy)をご覧ください。