# Lutrakitはファイルをブラウザー内でどう処理するか — そして確認する方法

Lutrakitのファイル系ツールは無料で、アカウントなしで使えます。選択したファイルをブラウザーで読み込み、その端末上でJavaScriptにより処理し、新しいファイルとしてダウンロードする設計です。選択したファイルの中身やファイル名を、Lutrakitのアプリケーションサーバーへアップロードしないことが前提です。ただし、この説明は信じるための標語ではありません。ブラウザーのNetworkパネルを開き、ファイルを選んで処理している間にどの通信が発生するかを確認できます。

このガイドでは、設計上の境界、再現できる確認手順、この確認で分かること・分からないことを整理します。現在の本番版を確認するときは、下の手順を実行し、ブラウザー、OS、サンプルファイル、観察結果を記録してください。

## ここでいう「ブラウザー内」とは

ウェブページでローカルファイルを選ぶと、ブラウザーはその選択されたファイルをウェブアプリに渡します。W3Cの [File API](https://www.w3.org/TR/FileAPI/) は、選択されたファイルを表すオブジェクトと、そのデータへアクセスする仕組みを定義しています。重要なのは、ページが端末のファイルシステム全体を自由に読めるわけではなく、利用者が選んだファイルを扱う、という点です。

PDFや音声のように重い処理では、Web Workerを使うことがあります。Workerは外部サーバーではなく、ページとメッセージをやり取りするブラウザー内の別実行コンテキストです。WHATWGの [HTML Standard: workers](https://html.spec.whatwg.org/multipage/workers.html) は、この分離された実行とメッセージングの仕組みを説明しています。

混同しやすい通信は3種類あります。

- サイトの読み込み: HTML、JavaScript、CSS、アイコンなどを取得する通信。
- 処理エンジンの読み込み: 初回利用時に、ツール用のコードを取得する通信。
- 選択したファイルの処理: ファイルのバイト列がページ、Worker、メモリ、ダウンロード出力の範囲に留まるべき部分。

プライバシー上の約束は3つ目に関係します。ページを開く通信があるのは当然です。確認すべきなのは、ファイル選択や処理によって、文書の中身、ファイル名、抽出テキスト、署名画像などがリクエストに含まれていないかです。

## 自分で確認する手順

テストには機密文書ではなく、無害なサンプルを使ってください。HARログを保存・共有する場合も注意が必要です。Chromeの公式Networkリファレンスは、DevToolsを開いている間のリクエスト記録、キャッシュ無効化、HARエクスポート、機密情報を含む可能性について説明しています: [Chrome DevTools Network reference](https://developer.chrome.com/docs/devtools/network/reference)。

1. 拡張機能の影響を避けるため、テスト用プロファイル、シークレットウィンドウ、または拡張機能を無効にした環境を開きます。
2. DevToolsのNetworkパネルを開き、「Preserve log」と「Disable cache」を有効にします。
3. 確認したいLutrakitツールを開きます。PDFの例なら [PDF結合](/ja/pdf-ketsugo/) を使います。
4. ページの読み込みが終わるまで待ちます。初期のHTMLや静的アセットの通信は通常の読み込みです。
5. Networkの一覧をクリアし、ファイル選択後の通信だけを見られる状態にします。
6. ファイル名と内容に一意の文字列を入れたサンプルを使います。例: `lutrakit-local-canary-2026-08-17`。
7. ツールを実行します。
8. ファイル選択後のリクエストについて、メソッド、URL、本文、クエリ、ヘッダー、レスポンスを確認します。
9. Network内検索で、カナリア文字列やファイル名を探します。
10. そのツールが初回コード取得後にオフラインでも使える場合は、オフライン状態でも再度試します。

期待する結果は明確です。ファイルの内容、ファイル名、抽出テキスト、自分で作った画像などが、リクエスト本文、URL、ヘッダー、クエリ文字列に出てこないことです。初回利用時に同一オリジンの静的コードや処理エンジンが読み込まれる場合はありますが、その通信に選択ファイルが含まれてはいけません。

## 実例: 小さなPDFを2つ結合する

テスト用に1ページPDFを2つ作ります。

- `alpha-lutrakit-local-canary-2026-08-17.pdf`。本文は「Alpha local canary 2026-08-17」。
- `beta-lutrakit-local-canary-2026-08-17.pdf`。本文は「Beta local canary 2026-08-17」。

[PDF結合](/ja/pdf-ketsugo/) を開き、ツールの読み込み後にNetwork一覧をクリアします。2つのPDFを選び、出力名は既定のまま、または `local-canary-merged` にして結合します。端末上の期待結果は、選んだ順序どおりの2ページPDFです。Network上の期待結果は、選択後のリクエストにファイル名や本文のカナリア文字列が出ないことです。

この例はUI確認にも使えます。現在の結合ツールは、最低2個のPDFを必要とし、`application/pdf` を受け付け、現行コードでは1ファイル100 MB、合計300 MBの入力上限を持ち、出力ファイル名を指定できます。これらの値はLutrakitの現在のソースに基づき、変更される場合があります。利用時には実際の画面を確認してください。

## 結果の読み方

見るべき点は「Network一覧が空か」ではなく、「ファイルデータが通れる通信経路があったか」です。

| 観察結果 | 解釈 |
| --- | --- |
| ファイル選択前のページ資産だけ | 通常のサイト読み込み。 |
| 初回のJavaScript、Worker、WASM、ライブラリ取得 | 静的コードで、ファイルデータを含まなければ許容範囲。 |
| 選択後・処理中に新しい通信がない | その実行ではブラウザー内処理の強い証拠。 |
| ファイル名、本文、バイナリ本文を含む通信がある | 失敗。私的なファイルには使わない。 |
| 拡張機能、ウイルス対策、企業プロキシ由来の通信 | クリーンなプロファイルで再テストする。 |

Networkパネルは、DevToolsを開く前に起きた通信を完全には示しません。また、OSのクラウド同期、ブラウザーアカウント同期、拡張機能、バックアップ、企業端末の監視まで否定するものではありません。この手順が確認するのは、その環境でページが行ったブラウザー通信です。

## 保存した署名とブラウザー保存領域

多くのファイルツールは、出力を作った後に元ファイルを保存する必要がありません。一方、配色やタイマー状態、PDF署名ツールの再利用用署名など、利用者が選んだ情報がブラウザーに残る場合があります。`localStorage` は同じオリジンに紐づき、セッションをまたいで保存されるブラウザー機能です。MDNの [Window.localStorage](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) もその性質を説明しています。

共有PC、学校、職場の端末では、再利用用署名を保存しない方が安全です。その場で描くか画像を読み込み、PDFをダウンロードしたら署名を消し、必要ならサイトデータも削除してください。

## ブラウザー内処理だけでは足りない場合

ブラウザー内処理は、選択ファイルをリモート変換サービスへ渡さないという重要なリスク低減になります。しかし、すべての機密文書に十分な統制を与えるわけではありません。

次のような場合は、汎用ブラウザーツールを唯一の手段にしないでください。

- 法令、職務、契約、社内規程により厳格に管理される文書。
- 証拠保全やチェーン・オブ・カストディが必要な文書。
- 見た目の署名ではなく、証明書付きデジタル署名や適格電子署名が必要な場面。
- メタデータ、フォーム、しおり、添付、タグ、レイヤー、スクリプト、既存署名を維持する必要があるPDF。
- 破損、暗号化、大容量、または安全上重要なPDF。

その場合は、組織が承認したローカルソフト、文書管理システム、または専門的なワークフローを使うべきです。個人、学校、低リスクな事務作業では、出力を確認してから共有する限り、ブラウザー内処理で十分な場合があります。