オンラインツールへファイルを渡す前に、内容・保存先・処理方式を確認する必要があります。APIキーや顧客情報など、原則アップロードを避けたいファイルと判断基準を整理します。
PDF変換、画像圧縮、文字起こし、Markdownプレビュー。便利なオンラインツールは増えていますが、ファイルを選ぶ前に「この内容を外部へ渡してよいか」を判断する必要があります。
問題は、オンラインツールそのものが危険ということではありません。処理方式、保存期間、運営主体、利用規約が分からないまま、重要なファイルを渡してしまうことです。
この記事では、オンラインツールへのアップロードを避けたほうがよい代表例と、判断するときの基準を整理します。
原則としてアップロードを避けたいファイル
1. APIキー・パスワード・秘密鍵が入ったファイル
最優先で避けたいのが、認証情報を含むファイルです。
例としては次のようなものがあります。
.env- APIキーを記載した設定ファイル
- データベース接続文字列
- SSH秘密鍵
- PGPやRSAの秘密鍵
- アクセストークン
- パスワード一覧
GitHubのSecret Scanningでも、秘密鍵、データベース接続文字列、各種サービスのアクセストークンなどがシークレットとして検出対象になっています。
これらは漏えいした場合、単に内容を見られるだけでなく、第三者からシステムへアクセスされる可能性があります。
変換や整形のためだけに、認証情報を含むファイルを第三者サービスへ渡す必要はありません。 必要なら機密部分を削除したコピーを作るか、完全にローカルで処理します。
2. 顧客・従業員・取引先の個人情報
次のような情報を含むファイルも、安易にアップロードしないほうが安全です。
- 氏名とメールアドレスの一覧
- 電話番号や住所
- 顧客台帳
- 履歴書
- 人事評価資料
- 給与データ
- 問い合わせ履歴
個人情報を扱う場合は、「便利だから」だけで外部サービスを選ぶべきではありません。会社や組織のルール、契約、利用目的、保存先を確認する必要があります。
特に、無料ツールへ業務データを入れる場合は、利用規約やプライバシーポリシーを確認し、業務上許可されたサービスかどうかを優先します。
3. 契約書・見積書・未公開の事業資料
個人情報が入っていなくても、公開前の情報には価値があります。
- 契約書
- 見積書
- 原価表
- 売上資料
- 事業計画
- 未公開のIR資料
- 製品仕様書
- 会議議事録
こうしたファイルは、内容そのものが企業秘密や交渉情報になり得ます。
「PDFにしたい」「要約したい」といった目的でも、まず社内で許可されているツールかを確認します。
4. 非公開のソースコードや設定ファイル
ソースコードには、仕様やアルゴリズムだけでなく、内部URL、環境名、コメント、設定値などが含まれることがあります。
特に注意したいのは、コードそのものよりも周辺ファイルです。
.env
config.yaml
settings.json
credentials.json
*.pem
*.key
見た目では「ただの設定ファイル」でも、認証情報や内部構成が含まれている可能性があります。
コードを外部ツールへ渡す場合は、リポジトリ全体ではなく必要な範囲だけに絞り、秘密情報が混ざっていないか確認したほうが安全です。
5. 「公開されたら困る」と直感的に分かるファイル
判断に迷った場合は、かなり単純な基準が使えます。
このファイルが明日インターネット上で公開されても問題ないか。
答えが「困る」であれば、少なくとも運営元も処理方式も分からないオンラインツールへ、そのままアップロードするべきではありません。
これは厳密な情報セキュリティ分類ではありませんが、個人利用での一次判断としては有効です。
「オンラインツールだから危険」ではない
ここは分けて考える必要があります。
Webページ上で動くツールでも、処理方式には違いがあります。
サーバー処理型
ファイルをサービス側のサーバーへ送信し、サーバーで変換・解析します。
高負荷な処理やAI処理には向いていますが、利用者は次の項目を確認する必要があります。
- どこへ送信されるか
- どれくらい保存されるか
- 学習や二次利用に使われるか
- 第三者サービスへ再送信されるか
- 削除方法があるか
ブラウザ内処理型
JavaScriptやWebAssemblyなどを使い、端末上のブラウザ内で処理します。
File APIの FileReader.readAsText() のように、ユーザーが選択したローカルファイルをブラウザ内で読み取る標準APIもあります。
ただし、「ブラウザ内で読み込む」だけでは外部送信しない証明にはなりません。 JavaScriptからAPIへ送る実装もできるためです。
ブラウザ完結ツールを見るときの確認ポイント
重要なファイルを扱うなら、説明文だけでなく構造も確認できると安心です。
1. Networkタブで通信を見る
ブラウザの開発者ツールにあるNetworkタブを開くと、ページがどこへ通信しているか確認できます。
ファイルを読み込んだ瞬間に未知のAPIへリクエストが出ていないかを見るだけでも判断材料になります。
2. CSPを確認する
Content-Security-Policy（CSP）は、ブラウザに対して「どの通信先やリソースを許可するか」を指定する仕組みです。
たとえば default-src 'none' を基点に必要な通信だけを許可する構成なら、ページ内JavaScriptの自由な外部通信をブラウザ側から制限できます。
oka-projectのツールでは、この考え方を使って外向き通信を制限しています。実際に外部画像の通信経路を見つけて塞いだ過程は、ブラウザ完結ツールの「送信しない」を、約束ではなく構造にする にまとめています。
ローカル処理でも万能ではない
ブラウザ内処理なら、サーバーへファイルを送るリスクは減らせます。ただし、それだけですべて安全になるわけではありません。
- 端末自体がマルウェアに感染している
- 悪意あるブラウザ拡張が入っている
- クリップボードへコピーした内容を別アプリが取得する
- 利用者自身が誤った宛先へ共有する
こうしたリスクは別に残ります。
つまり、ローカル処理は「外部サービスへデータを渡す経路を減らす」ための設計であって、情報管理全体を代替するものではありません。
アップロード前の5項目
オンラインツールを使う前に、最低限ここだけ確認します。
- このファイルには秘密情報が入っていないか
- 処理は端末内か、サーバー側か
- サーバーへ送る場合、保存期間は明記されているか
- 第三者への送信や二次利用について説明があるか
- 組織のルール上、そのサービスを使ってよいか
1つでも分からない場合は、重要なファイルをそのまま渡さないほうが安全です。
結論：便利さより先に「渡してよいファイルか」を決める
オンラインツールを安全に使ううえで一番重要なのは、サービスを細かく比較することよりも、そもそもそのファイルを外部へ渡してよいのかを先に決めることです。
APIキー、秘密鍵、個人情報、契約書、非公開コードなどは、原則として未知のサービスへそのままアップロードしない。必要なら機密部分を除去するか、ローカル処理を選ぶ。
この基準を持っておくだけで、便利なツールを使いながら不要なリスクをかなり減らせます。