こんにちは、hachi8833です。前回記事の続きです。
enno.jpで「あえて」サポートしていない機能
enno.jpを構築するうえで、最初から決めていたことがいくつかあります。
1. エラーの自動修正は行わない
自動修正、夢のある響きですよね。
でも自然言語の自動修正は、きっといつか事故ります。定まった形式を持つプログラミング言語ですらlintの自動修正で事故ることがあるのですから、何でもありの自然言語の自動修正が事故らないはずがありません。
「誰がどう見ても本当はこう書きたかったのだろう」という誤りは、何が何でも修正したい欲にかられがちです。しかし自動で修正しても安全な場合は、極めてわずかだと考えています。
極端な話、文章の誤りやスペルミスそのものについて書かれた文章（「resqueではなくrescueが正しい」など）の誤りを自動修正してしまったら、文章そのものの意味がなくなってしまいます。正誤表を自動修正してしまったら目も当てられません。
厳しいことで有名なGo言語のgo fmtですら、チェックや自動修正のほとんどは（レキシカルな）表面上のスタイルにとどまっています。コードの意味に踏み込むチェックは、「関数末尾にreturnがない」など少数です。Go言語のコードはエントロピーがかなり小さい部類に入ると自分は思っていますが、それでもできることはたかだかスタイルの自動修正にとどまります。
それよりも、「入力フィールドで文章の修正を繰り返しながらハイライトを減らしていく」作業フローの方が、遥かに能率がよいと自分には思えたのです。
余談ですが、文章は、誤りを含む可能性が常にあるからこそ誤りそのものについても記述できると思っています。誤りを記述できない言語というものがもしあったとしても、そこでは完全性が損なわれてしまうと思っています。
エラーの自動修正には罠がある
エラーの自動修正には、もうひとつ罠があります。
人の心は弱いので、エラーが自動修正されていると思うと、まず間違いなく油断して目視チェックしなくなってしまうのです。皆さんは、エラーが自動修正されていると知っても、さらにみっちり目視でチェックする自信がありますか？私はありません。
自動修正しない積極的な理由
enno.jpでは、エラーをハイライトするだけに留めることで、ユーザーが目視チェックを絶対スキップできないよう間接的に配慮しています。
これは「必ず目視チェックしないと先に進めない」といったシステム的な制約ではありません。enno.jpには「目視チェックを行ってから自分で修正を反映する」以外の動線がないので、ユーザーは知らず知らずのうちにこの動線に乗ります。
つまり「自動修正がないこと自体が機能」です。これはたまたまそうなったのでもなければ、面倒だから作らなかったのでもなく、最初からそのつもりで作りました。
2. ファイルのアップロードをサポートしない
テキスト形式、docx形式、markdown形式など、ファイル形式は星の数ほどあります。チェックサービスで対象ファイルのアップロードをサポートすると、次から次へとファイル形式を増やさなければならなくなります。
しかも、さんざん苦労してファイル形式を増やしたところで、喜ばれることなどまずありません。逆に「何でこのファイル形式にまだ対応してないんだよ！」と文句を言われる可能性が圧倒的に高いのが世の常です。
そんな徒労を背負い込むつもりはないので、最初から「文章はフィールドに貼り付けて入力」という1種類のみに限定しました。
このおかげで、以下の絶大なメリットが得られました。元のテキストがShift_JISだろうと何だろうと、Webフォームのフィールドにコピペすればみんな同じエンコードになります。
- 処理のエンコードをUTF-8に統一できた
- 不要な文字化けと無縁になり、本当の文字化けを確実に検出できるようになった
- ファイル形式サポートの無間地獄と無縁になった
3. 「あからさまなエラー」だけを対象にする
他人が読む前提の文章には、多くの場合スタイルというものがあります。そしてスタイルは絶対的なものではありません。日本では主に出版社や企業ごとに独自に定めているのが普通です。
つまり、ある出版社や企業のスタイルに特化したチェックツールは、それ以外の文脈では使えない宿命を背負います。それでは利用範囲が極めて限定されてしまいます。
そこでenno.jpでは、最初から「あからさまなエラー」だけをチェック対象にすると決めました。「これはどんな文脈に置いたとしても間違いだろう」というエラーパターンだけを登録しています。
他のチェックツールと併用できる
enno.jpがあからさまなエラーだけに絞り込んだことで、他の日本語チェックツールの前処理にも使えるようになりました。むしろ、他のチェックツールと組み合わせることを前提としていると言ってもよいでしょう。
この手のチェックツールを複数かけると、ツール同士が「オレが正しい」「いやオレが正しい」とケンカしてしまうこともしばしばです。そうなるとツール同士の調整に時間を取られ、チェックどころではなくなってしまいます。
ちゃんと調べたわけではありませんが、enno.jpのあからさまなエラーチェックが他の日本語チェックツールの出力とケンカする可能性はほぼないと推測しています。
アラートが激減した
enno.jpのチェック対象をあからさまなエラーにのみ絞り込んだことで、「どうでもいいアラートが激減した」という絶大なメリットを得られました。
既存の日本語文章チェックでは、多くの場合構文解析まで導入してびしびしアラートをあげてくれますが、正直申し上げると、現実にはそうしたアラートの8割は修正不要です。
「もしかしたら問題があるかもしれないから」と親切心で増やしたアラートのほとんどは、ユーザーをうんざりさせるだけで終わってしまいます。大量のアラートの中から「本当に修正が必要なもの」と「修正不要なもの」を自分の眼力で見分けながらの修正作業は、心底苦行です。
私はenno.jpを自分で使うたびに、適切でないチェック結果が出たらその場でエラーパターンを修正しています。
量が増えてしまったので、後編に続きます。