Web・実験実装

利用者側では、写真や記事を普段の手順で更新するだけで、公開サイトが見やすく保たれ、あとから変更履歴も追えることが重要です。その価値を支えるために配信最適化と監査機能を組み合わせています。

このCMSでは、指導者が普段使っている Google Drive を更新元にしつつ、公開サイト側では読み込み速度と運用記録の両方に対応する必要がありました。なので、画像は配信用に変換してキャッシュし、管理画面の操作は追跡できます。

1. Sharp による画像変換とローカルキャッシュ

Google Apps Script 経由で取得した元画像は、そのまま配信せずに Sharp でリサイズとWebP変換を行っています。大きな写真を公開ページ向けのサイズへ整えたうえでキャッシュすることで、閲覧端末ごとの通信負荷を抑えました。

// imageDownloader.js: メモリ上でのストリーム最適化処理
const optimizeImage = async (buffer) => {
    return await sharp(buffer)
        .resize({ width: 1280, height: 720, fit: 'inside', withoutEnlargement: true })
        .webp({ quality: 60 })
        .toBuffer();
};

この変換をサーバー側でまとめて行うことで、公開側のHTMLは通常の画像参照だけで済みます。運用担当者に画像最適化の知識を求めず、サイト側で配信品質をそろえられる構成です。

2. 監査ログとレート制限で運用面を固める

地域団体向けの管理画面では、更新しやすさだけでなく「誰が何を変えたか」を追えることも重要でした。そこで、管理操作は audit.middleware.js を通して記録し、入口ではレート制限もかけています。

• レートリミット: ログインや管理系エンドポイントへのアクセス頻度を制限し、試行回数の多い攻撃を受けにくくしています。
• 監査ログ: 更新者、時刻、IPアドレス、対象記事を残し、公開後の問い合わせや差し戻し時に追跡できます。

利用者に見える価値は、ブラウザ再起動後もルールが安定して働き、審査要件を満たしたまま整理を自動化できることです。だから、MV3前提の制約を内部設計で吸収しました。

DownloadEx は Manifest V3 の Service Worker 上で動くため、常駐プロセスを前提にした設計が使えません。そこで、ルールは常に保存済みデータから復元し、その場で評価して結果だけを返す流れにしました。

1. Service Worker 起動前提のステートレス設計

振り分けルールは chrome.storage.local に保存し、chrome.downloads.onDeterminingFilename 発火時に読み出して評価します。メモリ上の状態を当てにしないことで、Workerが停止・再起動しても動作を変えずに保てます。

// background.js: ステートレスなダウンロードフック
chrome.downloads.onDeterminingFilename.addListener((item, suggest) => {
    // Service Workerが起動するたびにストレージから最新ルールを非同期でロード
    chrome.storage.local.get(['rules']).then((result) => {
        const rules = result.rules || [];
        const matchedRule = evaluateRules(item, rules);
        if (matchedRule) {
            // 動的変数（日付など）を展開し、OSの禁止文字をサニタイズ
            const newPath = sanitizeAndFormatPath(matchedRule.path, item);
            suggest({ filename: newPath, conflictAction: 'uniquify' });
        } else {
            suggest(); // ルールに合致しない場合は標準の挙動
        }
    });
    return true; // 非同期で suggest を呼び出すために必須
});

この構成にすると、ブラウザ側のライフサイクル制約をアプリ側で吸収できます。ルール数が増えても、評価入口が1か所にまとまっているため保守しやすい点も利点でした。

2. 正規表現ルールの安全性確保

公開拡張機能では、ユーザー定義の正規表現が重すぎるとダウンロード処理全体へ影響します。なので、ルール評価前にパターンを検証し、極端に負荷が高い条件を避ける仕組みを入れています。

PNGtoTGA では、画像変換そのものよりも、ブラウザ上で重いバイナリ処理をどう扱うかを検証しました。UIを止めないことを前提に、Worker側でTGAを組み立て、結果だけをメインスレッドへ返します。

1. DataView でTGAヘッダを直接組み立てる

変換処理は外部ライブラリに任せず、DataView を使ってTGAヘッダを書き込み、ピクセルデータも自前で並べ直しています。フォーマット仕様を直接扱うことで、どこで変換コストがかかるかを把握しやすくしました。

// converter-worker.js: TGAヘッダのバイナリ構築
const header = new DataView(new ArrayBuffer(18));
// TGA_IMAGE_TYPE_UNCOMPRESSED_TRUE_COLOR = 2
header.setUint8(2, 2);
// Width & Height (リトルエンディアンで16bit書き込み)
header.setUint16(12, width, true);
header.setUint16(14, height, true);
// Bits Per Pixel (32 bpp: RGBA)
header.setUint8(16, 32);

ヘッダ生成とピクセル配置を分けて管理できるため、画像が壊れた場合も原因を追いやすく、フォーマット変換ツールとしての見通しが良くなりました。

2. Transferable Objects でコピーを避ける

変換後のTGAバッファはサイズが大きくなりやすいため、メインスレッドへ戻す際は Transferable Objects を使って所有権ごと移しています。コピー回数を減らすことで、複数ファイル処理時のメモリ負荷を抑えました。

// WebWorker側からメインスレッドへの転送
const tgaBuffer = constructTGABinary(pixels, width, height);

// 第2引数の配列にバッファを指定することで、コピーせず所有権を移譲する（ゼロコピー）
self.postMessage({ type: 'DONE', payload: tgaBuffer }, [tgaBuffer]);

あわせて、RGBA から BGRA への並べ替えと上下反転を1パスで済ませるようにし、余分な中間バッファは持ちません。結果として、ブラウザ内処理でも複数画像をまとめて扱いやすい構成になりました。