File System Access API
Thank you for reading this post, don't forget to subscribe!AIにコードを相談し、返ってきた答えをエディタに貼り付ける。
この一連の作業をボタン一つで自動化できる技術、それが「File System Access API」です。
しかし、この便利なAPIを知ったとき、私は立ち止まりました。
AIが「無駄な手間」と呼ぶその数秒間、私は「次はどう動かそうか」と構成を練り、コードの行き先に悩んでいたからです。
一見すると非効率な「コピペ」や「ファイルを探す手間」の中にこそ、実は納得のいくものづくりに欠かせない、大切な時間が隠れていました。今回は、AI(Gemini)との対話を通じて再発見した、「あえて自動化しないことで守られる、試行錯誤の価値」についてお話しします。
ブラウザとPCの境界線に立つ技術
WebブラウザからPC内のファイルに直接アクセスし、上書き保存まで可能にする「File System Access API」。
この技術を知ったとき、私は一つの期待を抱くと同時に、大きな疑問にぶつかりました。果たしてこれは、私の今の作業を本当に豊かにしてくれるものなのだろうか?
今回は、AI(Gemini)との対話を通じて見えてきた、この技術の正体と「効率化の先にある大切な時間」についてお話しします。
対話セクション
すべては「素朴な疑問」から始まった
この記事の出発点は、私がGeminiに投げかけた、あるシンプルな質問でした。
私:
File System Access APIの
メリット、デメリット、セットアップ方法や使い方を教えて。
Gemini:
File System Access APIを使えば、ローカルファイルを直接上書きできるので、AIが生成したコードをボタン一つで手元のファイルに反映できる。コピペの手間がゼロになり、爆速で開発できる・・・
という、いかにも現代的な効率化のメリットが提示されました。しかし、その回答を読んだ私の心に浮かんだのは、ある「違和感」でした。
そして、ここから更に突っ込んだ問いかけをしたのですが、・・・・
「中略:・・・「単に便利だと言われるほど、自分の手が離れていく感覚に違和感を覚えたのです。そこで、私はこんな疑問をぶつけました。」
ここからは、Geminiとの会話に於いて、私の問いから始まる対話の一部・途中から載せています。
効率化という言葉への違和感
AIが提示した「爆速」というメリットに対し、自分の実感をぶつけてみました。
AIが「不要な手間」と呼んだものは、私にとっては「新しいアイデアを熟成させるための、かけがえのない時間」だったのです。
私:
1.「GEMINI」などのAIにコードを書いてもらう。
2.コードを「コピー」する。
3.自分のエディタ(VS Codeなど)を開く。
4.該当箇所を探して「貼り付け」して「保存」する。
・・ここまではよく利用しています。
Gemini:
なるほど、非常にクリアな作業フローですね!現在の「コピー&ペースト」というスタイルが確立されている場合、確かに「わざわざ新しいAPIを使うメリット」が見えにくいのは当然です。
結論から言うと、あなたの使い方は**「今のままでも十分に正しい」です。ただ、File System Access APIを使うと、その「動作確認・検証」までの往復回数が多い場合に、劇的なスピードアップ**を感じられるようになります。
「メリットを感じられるかどうか」の分かれ道は、以下の3つのポイントにあるかもしれません。
1. 「コピペ」の回数が10倍、20倍になったら?
今のフローでは「1回AIに聞いて、1回コピペして終わり」なら苦になりません。しかし、以下のような場面ではどうでしょうか。
- 試行錯誤(トライ&エラー): 「ここを赤くして」「やっぱり青にして」「角を丸くして」と、AIと10回やり取りする場合。
- メリット: API連携があれば、AIの回答画面にある「適用ボタン」を押すだけで、**裏側のVS Codeで開いているファイルが瞬時に書き換わり、隣のブラウザタブ(プレビュー)が自動更新(ライブリロード)**されます。
- 感覚の差: 「手動で5ステップ」かかる作業が「0ステップ」になり、思考を止めずに検証に集中できます。
2. 「特定の箇所」を探す手間がゼロになる
「Test用HTML内の特定の箇所に追記する」際、ファイルが長くなってくると、該当箇所をスクロールして探す手間が発生します。
- APIの強み: プログラム(スクリプト)側で「
からの間を書き換える」といった指定が可能です。- メリット: あなたがエディタで場所を探す必要すらなく、AIと「ここ直しておいて」と話すだけで、正確な位置にコードが差し込まれます。
3. 「Webサイトへの移行」もシームレスに
現在はローカルで検証したあと、手動でWebサイト(サーバー)へ移行されているかと思います。
- 将来的なイメージ: 検証が終わった瞬間に、ブラウザ上のボタン一つで「ローカルの修正済みファイル」を読み取り、そのまま「本番サーバー」へアップロード(デプロイ)する、といった一連の流れがブラウザ内で完結します。
「10倍、20倍の回数になったら?」や「複数ファイルの書き換え」という視点は非常に鋭いんですが、このブログを読んでくださっている あなたや、「自分はどのフェーズにいるか」の判断基準になると思います。
・・・私の場合は、これらを考慮しつつ、次の質問をぶつけてみました。
私:
……AIにプログラムを書いてもらい、
コピペして、エディタの特定の箇所に追記し、検証する。
その間、
私は『次はどうしようか』とアイディアを練る時間も取っています。
ただ組み込むだけじゃなく、常に新たな思考が伴う。
行き詰まったらまた相談し、
最終的な形になるまで試行錯誤を繰り返す。
この『悩む時間』こそが自分にとって大事な作業工程なんです。
だから、File System Access APIの機能が素晴らしくても、
便利な機能でも、使い道?・・・として、「ピン」と来ません。
これだとAPIのメリットを感じられません。私の考えは間違いでしょうか?
Gemini:
全く「間違い」ではありません。むしろ、あなたの作業スタイルは**「エンジニアとしての極めて健全で、深い思考を伴うプロセス」**です。
お話を伺って、なぜ File System Access API のメリットが響かなかったのかが完全に見えました。あなたはAIを「自動コード生成機」としてではなく、**「思考を深めるための相談パートナー(壁打ち相手)」**として使い、そのアウトプットを自分の手で組み立てるプロセスを大切にされているからですね。
そのスタイルにおいて、このAPI(自動化)がなぜ「余計なお世話」に感じるのか、そして逆に「こういう時なら役立つかも?」という視点を整理しました。
あなたのスタイルで「自動化」が不要な理由
今の作業フローには、単なる「作業」以上の意味が含まれています。
- 「思考の同期」としてのコピペ:
AIのコードを自分の手でエディタに貼り付け、場所を探すプロセスそのものが、**「コードの構造を理解し、自分の頭にインストールする時間」**になっています。ここを自動化してしまうと、自分のコントロールを離れて勝手に中身が変わる「ブラックボックス」になってしまいます。
- 「熟成」の時間:
「次はどうしようか」と練る時間は、クリエイティブな作業において最も重要なフェーズです。効率化して時間を短縮することだけが正解ではありません。
逆に「もし」このAPIを使うメリットがあるとしたら?
今の「思考中心のスタイル」を維持しつつ、もし将来的にメリットを感じるとすれば、以下のような**「思考を邪魔する雑務」**が発生した時かもしれません。
① 「1つの変更」が「10個のファイル」に影響する場合
例えば、サイト全体のデザイン(CSS)を微調整したいとき、AIから「この5つのファイルの、この部分を全部書き換えて」と言われたらどうでしょう?
- 手動: 5つのファイルを開き、場所を探し、5回コピペする。(これは「思考」ではなく「単純な移動作業」になりがちです)
- API利用: ボタン一つで5ファイルが更新され、あなたは即座にブラウザで「全体の雰囲気」を確認する思考に戻れます。
② 「画像」や「音声」などのバイナリデータを扱う場合
コード(テキスト)はコピペできますが、AIが生成した「画像」や「最適化されたアイコン」をローカルに反映させるのは面倒です。
- 手動: 右クリックで保存 > フォルダを選択 > 名前を付けて保存 > エディタでパスを確認。
- API利用: AIが生成した画像を、そのままローカルの
assets/images/フォルダに適切な名前で「ガチャン」とはめ込んでくれます。
結論:このAPIは「道具」であって「目的」ではない
File System Access API は、**「PCの中とWebを繋ぐ土管(パイプ)」**を作れるようになる技術に過ぎません。
今のあなたのように「自分の手で、考えながら一歩ずつ組み立てる」のが最もミスが少なく、理解が深まるのであれば、無理にこのAPIを使ったツールを導入する必要はありません。
この問いかけをきっかけに、議論は単なる技術解説を超え、「人間がいかにしてAIと共存し、自分の思考を守るか」という本質的なテーマへと深まっていきました。単なる技術解説を超え、「AI時代の人間らしい作業のあり方」へと発展していきました。
「File System Access API」を単なる技術解説としてではなく、「AIとの共存」や「人間の思考プロセス」という視点から捉え直せました。
AI(Gemini)と対話しながら「自分には不要かも?」と深掘りしたプロセスそのものをコンテンツにすることで、同じ悩みを持つあなたにも強く刺さる内容ではないでしょうか?
結びに:自分にとっての「最適解」を見極める
File System Access APIを巡る対話を通じて見えてきたのは、「効率」を優先してツールに任せる部分と、「納得」のために自分の手を動かす部分を自分自身で選ぶことの重要性でした。
AIがどれほど進化し、ボタン一つで全てが片付く世界になったとしても、最後に「これは私が作った」と胸を張れるかどうか。その鍵は、効率化の波に消えそうな「悩むプロセス」や「アイディアを練る時間」の中にこそ、隠されているのかも知れません。
「効率」とは、単に時間を短縮することだけではありません。
納得がいくまで悩み、アイディアを練り上げるための時間を、いかに確保するか。
AIがどれほど進化しても、この「悩むプロセス」だけは他人に、そして技術に明け渡してはいけない。今回のFile System Access APIとの出会いは、そんな大切なことに気づかせてくれるきっかけとなりました。
便利すぎる最新技術を前にして、あなたはあえて「自分の手を動かす時間」を、どこに残しておきたいですか?
最後のひとこと

(一言と言っておきながら、3つあります。)
- 「効率化が奪うのは『手間』だけじゃない。構成を練る『時間』も奪っているのかもしれない。」
- 「AIとのコピペ作業は、私にとっての『思考の同期』だった。」
- 「技術に従うのではなく、自分の作業リズムを守るために技術を吟味する。」
技術的な「余白」
「今回、あえて手動を選んだ私ですが、もし自動化を試してみたい人のために、最小限のコード(JavaScript)を置いておきます」
➡ Codeエリアのマウスホバーで アイコンが表示されます。
この アイコン クリックでSource Codeをクリップボードにコピーできます。
async function overWriteFile() {
try {
const [handle] = await window.showOpenFilePicker(); // ファイル選択
const writable = await handle.createWritable(); // 書き込み準備
await writable.write("/* AIが生成した新しいコード */"); // 書き込み
await writable.close(); // 完了
alert("保存しました");
} catch (err) {
console.error("キャンセルまたはエラー:", err);
}
}

ご参考
試行錯誤の実態
ここには、GEMINIでさえ見逃した(見誤った)Webサイト公開前の記録があります。
私の試行錯誤の実態については、こちらの記事もその一端です。👇
「AIが提案する『効率』に乗るのが怖いのは、かつてGeminiと一緒に解決不能なエラーの迷宮に迷い込んだ経験があるからかも知れません。その時の試行錯誤が、今の私の『考えを捨てない』スタイルを作っています。」


