StegTool について

LSB エンコード／デコードパイプライン

エンコード時、ツールはまずテキストを UTF-8 でバイト列に変換し、それを 1 ビットずつ画像ピクセルの最下位ビット（Least Significant Bit）へ書き込みます。「A」を例にすると、文字コード化で得られた一連のビットが、あるピクセルの R・G・B 各チャンネルの最下位ビットへ順に入り、続いて次のピクセルが処理されます —— 最下位ビットしか変えないため、各チャンネルの値の変化は最大でも 1/255 で、肉眼では判別できません。

デコード側に「どこで終わるか」を知らせるため、パイプラインは末尾に固定の終端マーカーを書き込みます。デコード時はピクセルの最下位ビットを走査し直してバイト列を組み立て、マーカーに達したら停止し、UTF-8 でテキストへ復元します。TextEncoder / TextDecoder により、多言語テキストや絵文字も失われることなく往復できます。

ピクセルの読み書きはブラウザ標準の Canvas API で行います：drawImage() で画像をオフスクリーンキャンバスに描画し、getImageData() / putImageData() でピクセル単位の読み書きを行い、最後に canvas.toBlob() で書き出します。この過程でサードパーティの描画ライブラリは一切使わず、AI モデルも関与しません。

プライバシー優先のゼロサーバー設計

StegTool は意図的に「バックエンドなし」で作られています：アップロード用の API も、オブジェクトストレージも、データベースも、マイクロサービスもありません。画像はローカルディスクからブラウザのメモリへ読み込まれ、処理が終わればそのままローカルディスクへダウンロードされます —— 途中のどの工程も同じ端末上で完結します。

この設計には直接的な利点が二つあります。一つは、機密性の高い素材（契約書のスクリーンショット、身分証明、未公開の作品など）が端末の外へ出る必要がないこと。もう一つは、サーバー側の遅延がなく、処理速度が端末の性能だけに依存することです。

ご自身で確認できます：ブラウザの開発者ツール（F12）→ Network パネルを開き、「書き込み + ダウンロード」の流れを一通り実行したあとでリクエスト一覧を見てください。画像の中身や隠しテキストを含むリクエストは一件も現れません。

デジタル著作権とアセット保護

写真家、イラストレーター、デザインスタジオは、著作者名・作品番号・ライセンス範囲・顧客情報などを画像に書き込めます。見た目はクリーンなまま、証拠はファイルとともに存在し続けます。EC 事業者であれば、注文番号や SKU を商品画像に書き込み、画像の無断転載元を辿る手がかりにもできます。

企業でのバッチ処理ワークフロー

StegTool は一度に最大 20 枚までの画像へまとめて書き込めます。すべての画像に同じテキスト（統一の著作権表示など）を入れてもよく、1 枚ずつ異なる内容を設定することもできます。素材ライブラリへの登録、キャンペーン素材の配布、納品前の一括マーキングなど、規模が必要な場面に適しており、しかも処理中にアップロードが発生しないため、社内資料を外部に出さないというコンプライアンス要件にも合致します。

秘匿通信チャネル

暗号化チャネルが制限されたり監視されたりする環境では、ステガノグラフィーは別のアプローチを提供します：まったく普通に見える画像の中に情報を隠し、通常の経路で送るのです。ジャーナリスト、研究者、セキュリティ従事者はこれを暗号化と組み合わせて使うことがよくあります —— 先にテキストを暗号化し、その暗号文を画像へ書き込むことで、二重の保護になります。