この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "日本語処理" ? ニュース ・ 書籍 ・ スカラー ・ CiNii ・ J-STAGE ・ NDL ・ dlib.jp ・ ジャパンサーチ ・ TWL（2023年8月）

日本語処理（にほんごしょり）は、自然言語処理の下位分類のひとつで、自然言語のひとつである日本語をコンピュータに処理させる技術のこと。
歴史

アルファベット中心の欧米ではタイプライターやテレタイプ端末、各種のターミナルを経てパーソナルコンピュータ上の端末エミュレータ、ワープロソフト、DTPなどが普及した。日本語はわかち書きなしの漢字仮名交じり表記が一般的なため、和文タイプライターを経て1950年代には漢字テレタイプが端末としても使用された。

1972年には日本経済新聞グループと日本IBMの共同開発で世界初のコンピュータを利用した新聞製作システム ANNECS（アネックス）が稼働し、更に1980年には朝日新聞が日本IBMと共同開発したNELSON（ネルソン）が稼働した。これらはメインフレームと専用端末を含むIBM漢字システムで、日本語の新聞紙面に必要なかな漢字文の入力、表示、禁則処理などに対応した[1]。

並行して1960年代から1970年代にかけて九州大学、沖電気、NHK、NTT、大阪大学などでかな漢字変換の技術が研究され、1978年には東芝が初の日本語ワードプロセッサのJW-10を発表した[2]。

またパーソナルコンピュータでの日本語入力システムにはインプット メソッド エディタ（IME、当時はFEPとも）が普及した。Mac以外では、日本語の高速な表示には各社独自仕様のハードウェアであるテキストVRAMが使用されたが、1990年に登場したDOS/VやMicrosoft Windowsなどのグラフィカルユーザインタフェース(GUI)環境の普及により、世界のデファクトスタンダードであるPC/AT互換機が日本でも一般的となった。
言語学・国文法学との関連

音声入出力などは音声学などの言語学的要素を含む。しかし現在のところ、日本語処理はテキストデータによる入出力が中心となっているため、やや関連は薄い。いわゆる学校文法とも（特に動詞の活用などについては）距離がある。学校文法は国学（本居春庭など）の影響もあって五十音図を基盤にしており、同時に橋本進吉は活用表を学生自身の「気づき」を促すための素材として捉えていたため、機械学習などを行わなければ、コンピュータの動作にたいして正確に反映させることは難しい。そこで、日本語処理における日本語文法は、「音素」「指標音」「形態素」「活用語尾」といった独自の用語が使われており、学校文法とはかなり異質なものになっている。

とはいえ日本語教育との相性は悪くない。具体例としては、「書く」は音素ベースで書くならば「kak-a」（「ない」「ぬ」「ん」に接続）「kak-i」（「ます」に接続。連用形）「kak-u」（体言。連体形）「kak-e」（「ば」。いわゆる仮定形。正確には已然形）「kak-o」（「う」。未然形）となり、語幹は「kak」であり、「kai-ta」「kai-te」の場合には語幹の末尾音の「k」が消失（あるいは「i」に変化）する、と説明できるが、学校文法においては「書く」の活用は五十音図に基づくため「五段活用カ行」とされており、この説明と整合させようとすると煩瑣になる。これに対して日本語教育では、日本語を母語としない学生を対象にしているため、「漢字ローマ字交じり文」を経て「かな書き」の習得を経て「漢字かな交じり文」にするというプロセスになじみやすい[注 1]。

したがって、日本語処理ではひらがなをローマ字に変換してから形態素解析を行い、その結果をひらがなに戻すと簡単になるのだが、和欧混植（一つのテキストに和文と欧文が混在するもの）などへの対応が複雑になる。そのため音素ベースの文法記述を五十音図ベースの記述に変更すると、およそ四倍程度に膨らむ。
技法

日本語処理に関しては、「長尾の法則」他いくつか知られているが[注 2]、根幹的・基幹的なものとして数学基礎論の島内剛一による「島内式ローマ字かな変換」がある。

すなわち、

[文法属性A] - {"パターンマッチング文字列X"|"変換後の文字列Y"} - [文法属性B];

といった行の並びによって、文字列に対するパターンマッチングによって文字列の変換を行うという手法である。「sa・si・su・se・so」と「shi」、「ta・ti・tu・te・to」と「chi・tsu」の両方をサポートするための記述の面倒臭さはあるが、変換精度は高い。ただし、変換結果としてのデータ構造はPERTにおける「ネットワーク図」（いわゆる、束と位相同型な半順序構造と位相同型なデータ構造）になるため、そうしたタイプのデータ構造を扱えるプログラマが稀少であるという問題がある[注 3][注 4]。
課題

マッチングパターンの記述はファイル上一行で書くことができる。その点についてはPrologに近い。ただし小規模のプログラムにおいては問題がないが、実行順序が指定されておらず、出力結果であるネットワーク構造が正しく半順序構造になっているかについての検証をどう行うかという課題がある。反面、文法記述には実行順序に対する規制がないため、複数のファイルを実行時に（動的に）切り替えることができる。このとき、「巡回参照があるかどうか」を動的にチェックする（この場所が以前通ったところであるかをチェックする）か静的にチェックする（あらかじめ、文法定義においてヌルストリングとマッチした場合に巡回参照がないかどうかをチェックする）かによって実行効率が変わってくるため、実装上の判断が必要になる。

このとき、有効なのは「文字列の何文字目か」という距離空間を持ちこむことであるが、マッチング文字列がヌルストリングであった場合に問題が起こりうるという点である。実例としては、「書いている」を「書いてる」と略した場合、「いる」の語幹「い（i）」が省略されているとして文法記述を行なうと、「動詞の連用形は用言に係る」という規則と競合し、「書いて」と「る」の間に無限個の省略された「（い）」があると解釈されてシステムが落ちるという事例があった。なお、このケースでは動詞の連用形過去または完了形の活用語尾に「いる」の省略形を追加することで回避した。同じく補助動詞である「おく」（置いとく）「ゆく」（持ってく）では、語幹にあたる「ok」「ik」「yuk」が省略されても文法記述と交絡しないので、こうした問題は発生しない。
脚注[脚注の使い方]
注釈^ 実際に インプット メソッド エディタでローマ字入力を行なっているときは、システム内部ではこれに近いことを行なっている。
^ 橋田浩一によれば、「かな漢字変換はブラックアートである」という。
^ ネットワーク型のデータの扱いに熟達していて、同時に国文法に対するプログラマというのは、かなりのレアケースであり、そうした人員が日本語処理系の開発プロジェクトに携わるというのは、さらに稀である。「盲亀の浮木」「うどんげ」などを参照のこと。
^ もっとも、初期のかな漢字変換においては「接続テーブル法」という手法が使われており、「どの品詞のあとに、どの品詞がくるか」という二次元のテーブルを使用していたのだが、品詞分類が増えると品詞の数の自乗に比例してテーブルが大きくなり、しかもテーブルがスパース（「スカスカ」）だったために扱いきれなくなった。