箇条書きのすすめ
- ito017
- 2 時間前
- 読了時間: 3分
ブログ「AI翻訳に関する私見(3)」で、(誤訳を誘発しないという観点からは)明細書の文は短い方がいいと書きました。今回はその補足です。当該ブログで紹介したマクロ「色deチェック」で対訳表を作成した場合、以下のように、原稿と訳文とが文毎に左右に並べて表示されます。
【対訳例1】
日本語原稿 | 英訳 |
151.02、30.00、365.98、129.36、60.84、2789.36、336.71、4.75、5986.23、329.01 | 151.02, 30.00, 365.88, 129.36, 60.84, 2789.26, 336.71, 4.75, 5986.23, 329.01 |
対訳例1は、文とは呼べませんが、説明のために、これを一文だと考えてください。このような原稿と訳文を見比べてミスを見つけ出すのはなかなか大変です。次に、数値を個別に横に並べてみます。
【対訳例2】
日本語原稿 | 英訳 |
151.02 | 151.02 |
30.00 | 30.00 |
365.98 | 365.88 |
129.36 | 129.36 |
60.84 | 60.84 |
2789.36 | 2789.26 |
336.71 | 336.71 |
4.75 | 4.75 |
5986.23 | 5986.23 |
329.01 | 329.01 |
この対訳例2の方が対訳例1より確認作業が楽であり、ミスも発見しやすいということは、多くの方にご賛同頂けると思います。
もちろん、このような数値の羅列を全て改行した方がいいというわけではありません。人間の脳(目?)にとっては、情報を短く区切って左右に並べた方が確認が容易であるということをご理解いただくための例です。
明細書では事物を列挙する文が多く登場します。
「AがBであるC、D、及びE、並びにFがGであるHと、IやJなどのK、L及びMを含むNと、O又はP……」
これも極端な例ですが、実際、これに近い文言が明細書に登場することはあります。厄介なのは「や」「と」などの並列助詞、「及び」「並びに」などの接続詞は、書き手によって用法が異なる点です。このような列挙に複数の修飾句が絡むと、解読が更に困難になります。このようなフレーズでは、人間であれ、AIであれ、読み間違いを起こす確率が高くなります。訳が間違っていなかったとしても、それを確認する作業の負担は大きそうです。
「AI翻訳に関する私見(1)」で書いたように、AI翻訳では、存在しない語句の湧き出しや、存在する語句の消滅などの幻覚(ハルシネーション)が生じます。このハルシネーションは、いわゆるプログラムのバグとは違い、容易に修正できるものではありません。AIは精度を高めるために何度もパラメータが調整されていますが、このパラメータの調整は、いわば「あちらを立てればこちらが立たず」という試行錯誤の繰り返しです。今後、ハルシネーションが一直線に減少していくことはなく、むしろ増加することも十分にあると思います。このようなハルシネーションの被害に遭わないため、あるいは、ハルシネーションによる瑕疵を容易に検出するためには、複雑な列挙を箇条書き形式に書き直すことが推奨されます。
もちろん、箇条書きを多用すればページ数が増えますから、明細書作成料金が(不当に?)高くなるという問題もあるでしょう。従来の多くの明細書の形式から外れる箇条書きを嫌うクライアントさんもいるかもしれません。それでも、箇条書きには、修飾関係を明瞭にする、誤訳を減らす、明細書に携わるすべての人のチェック負担を軽減する……といった多くのメリットがあります。明細書の作成料をページ加算から文字数加算に変更するなど、慣習的な料金体系を変更してでも、箇条書きを明細書に取り入れることを検討する価値は十分にあると考えます。
AIは依然として多くの問題を抱えていますが、それでもなお、(人類にとって幸か不幸か分かりませんが)AIがあらゆるビジネスシーンで主要なプレーヤーとなりつつあることも事実です。特許明細書のような技術文書であっても、テキストが「AIフレンドリー」であることが差別化になり、市場価値を有するようになると考えられます。
Comments