Rust × WASM ゼロコスト文章診断 — 推敲チェッカーの設計思想

はじめに — なぜサーバーが要らないのか

多くのオンライン文章診断ツールは、テキストをサーバーに送信し、解析結果を受け取るしくみになっています。シンプルに見えますが、これには3つの問題があります。

プライバシー: 書きかけの小説がサーバーに送信される
速度: ネットワーク往復が加わるため、リアルタイム性が損なわれる
コスト: サーバー側でリクエストを処理するたびに費用が発生する

hakadoru.ai の推敲チェッカーは、この3つの問題をすべて根本から解消する設計を採っています。解析処理をブラウザ内で実行する ことで、テキストはネットワークに出ません。サーバーへの接続は発生しません。処理コストはゼロです。

この設計を可能にしているのが、Rust で書かれた解析エンジンと WebAssembly（WASM）のコンパイルパスです。

アーキテクチャの概要

推敲チェッカーは以下の3コンポーネントで構成されています。

ProofreadingEngine（Rust crate）
  ├── Vibrato         — 形態素解析（IPAdic 辞書）
  ├── Daachorse       — 多パターン照合（Aho-Corasick）
  └── CheckOrchestrator — PC-01〜PC-12 の並列実行

このクレートは2つのターゲットにコンパイルされます。

ターゲット	用途
`wasm32-unknown-unknown`	ブラウザ内の Web Worker で実行
`x86_64-unknown-linux-gnu`	サーバーサイドのバッチ処理（将来対応）

ブラウザ側では、wasm-pack build --target no-modules でビルドした WASM モジュール（292KB）を Web Worker 内でロードし、チェック処理を UI スレッドとは分離して実行します。

Vibrato を選んだ理由

形態素解析器として Vibrato（ヴィブラート）を採用しています。MeCab 互換の辞書形式（IPAdic）を使いながら、Rust ネイティブで動作します。

WASM 環境で日本語形態素解析を実現する上で重要なのは、辞書のサイズ管理です。IPAdic の辞書は非圧縮だと 41MB になりますが、zstd 圧縮（ruzstd による純 Rust デコンプレッサ）を使うと 6.5MB まで圧縮できます。これを public/wasm/system.dic として配信し、ブラウザの gzip 転送エンコーディングと組み合わせることで、実際の転送サイズを約 7MB に抑えています。

辞書は初回ロード後にブラウザの Service Worker キャッシュに保存されるため、2回目以降の診断は即座に開始されます。

Daachorse によるパターン照合

NG語辞書の照合には Daachorse（ダーコース）を使用しています。Daachorse は Aho-Corasick 法を実装した高速なマルチパターンマッチングライブラリです。

NG語辞書は次の構造を持ちます。

pub struct NgEntry {
    pattern: String,           // 照合するパターン
    is_regex: bool,            // 正規表現フラグ
    description: String,       // UI 表示用の説明
    severity: Severity,        // error / warning / info
    category: Option<String>,  // 分類タグ（任意）
}

Daachorse オートマトンは辞書の内容から動的に構築されます。ユーザーがカスタム辞書を追加・更新したとき、オートマトンをミリ秒単位で再構築できるのが特徴です。

12のチェック項目（PC-01〜PC-12）

推敲チェッカーは 12 項目のチェックを実行します。Vibrato による形態素解析を1回だけ実行し、その結果をすべてのチェッカーで共有することで、処理効率を最大化しています。

ID	チェック内容	手法
PC-01	語尾パターンの連続（だ・だった・ますの連続）	TokenStream
PC-02	文長の分布（一文あたりの文字数）	句点区切り
PC-03	会話文と地の文の比率	括弧対応
PC-04	記号の過多（三点リーダ、感嘆符）	Daachorse
PC-05	同語の近接反復（近い位置での単語の繰り返し）	TokenStream
PC-06	表記ゆれ（同じ語の異なる漢字/かな表記）	読み仮名比較
PC-07	文字種の比率（漢字率・ひらがな率）	Unicode ブロック
PC-08	会話文と地の文のバランス	PC-03 共有
PC-09	投稿先プリセットのフォーマット規則	ルール照合
PC-10	文字数制限との照合	カウント
PC-11	禁則文字（JIS X 4051）	行頭行末判定
PC-12	改行パターン（不統一・過多）	正規表現

投稿先プリセット

Web 小説の主要投稿先に特化したフォーマットチェックを内蔵しています。

プリセット	主要チェック内容
小説家になろう	ルビ記法 `｜漢字《かんじ》`、挿絵タグの有無
カクヨム	ルビ記法 `《》`、太字 `**`、章タイトル文字数
pixiv 小説	`[newpage]` タグ、ルビ記法 `[[rb:漢字 > かんじ]]`
アルファポリス	ルビ記法（なろう互換）、章文字数の推奨範囲

ブラウザ完結の利点

プライバシー

テキストはブラウザ外に出ません。診断処理は完全にローカルで完結します。API ログにもサーバーログにも残りません。

即応性

ネットワーク往復がないため、診断ボタンを押してから結果が返るまでの時間は、テキストの長さに依存します。1万文字のテキストでも通常1秒以内に診断が完了します。

コストゼロ

サーバーへの接続がないため、チェックを何回実行してもサーバーコストは発生しません。

オフライン動作

初回ロード後は、インターネット接続がなくても診断を実行できます（Service Worker キャッシュが有効な場合）。

指標推移 — 作品全体の俯瞰

単一シーンの診断に加えて、作品全体の指標推移を可視化する機能があります。

全シーンを WASM エンジンで逐次解析し、4つの指標の推移を棒グラフで表示します。

指標	意味
漢字率	テキスト中の漢字の割合
ひらがな率	テキスト中のひらがなの割合
会話文率	テキスト全体に占める会話文の割合
平均文長	1文あたりの平均文字数

全シーンの平均から 1.5σ 以上外れたシーンを赤色でハイライトし、文体の逸脱を一目で確認できます。

設計思想 — LLM を使わない選択

推敲チェッカーは、LLM（大規模言語モデル）を一切使用しません。

LLM は柔軟で創造的な応答が可能ですが、「語尾が3文連続している」「文字数が2万字を超えている」といった 機械的・決定論的な検査 には向いていません。

毎回異なる応答が返ってくる（非決定論的）
処理コストが高い（トークン消費）
根拠の説明が必要な場合、プロンプト設計が複雑になる

hakadoru.ai では、こうした機械的な品質チェックを決定論的なルールベースエンジンで処理し、LLM は「創造的な支援」にのみ使うという役割分担を採っています。

推敲チェッカーで機械的な問題を取り除いた後、LLM を使った熟考モードや変換エンジンで表現を磨く——この2段階のパイプラインが、コストと品質の最適なバランスを実現しています。

まとめ

hakadoru.ai の推敲チェッカーは次の設計原則で構築されています。

ブラウザ完結 — テキストをサーバーに送らない
Rust ネイティブ — 高速・決定論的・安全なメモリ管理
役割分担 — 機械的チェックは決定論的エンジン、創造的支援は LLM
コストゼロ — サーバーコストをユーザーに転嫁しない

推敲チェッカーは /tools/proofreading から無料でご利用いただけます。ログインも登録も不要です。

ぜひ、書いたシーンを貼り付けてみてください。