前回アルファベットを含む文も普通の日本語と同じように変換することを提案しましたが、アルファベットにはスペースがついて回るので入力文の解析の際には切れ目とみなされてしまいよく使われそうなタイトル名や施設名、商品名などスペースを含むものが大文字小文字の使い分けなど細かいところで思った通りに表記されないケースが考えられることに留意しなくてはなりません。
構文解析的にもひとまとまりの単語なら途切れることなくひとかたまりの単語として認識しておいた方が運用上都合が良いと思います。ペンタクラスタキーボードにはでにをは別口入力があるので区切り目の把握はこれらの助詞・助動詞などのパーツや句読点・！？・括弧あるいは改行・確定などで区別すればこれで事足りると思われますが今後検証が必要になってくるかと思います。
ローマ字入力と日本語入力の境目がなくモード切替をしないで良いのはいいのですが、英文を入力していても未確定の文字列として変換プロセスが完了していないというのはなんだか連続入力中だと少し不安になってしまいそうな感覚もあります。しかし少々面倒ですが一連の英語の入力文の後にも日本語入力と同じ手続きで[Enterキー]で確定していくのが良いだろうと吟味の結果思い至りました。
.(ピリオド)や,(カンマ)、!?(感嘆符・疑問符)などが現れた時点でいったん自動確定させるなどの措置はあり得ると思うのでその辺はユーザーの設定などで動作を指定できればいいかと思いますが、それ以前にでにをは別口入力でも逐次確定処理はしていないので(記号ではないが)日本語文の入力時と同じように最後の変換・確定が済むまで未変換文字列としてふるまうほうが統一的で良いと思います。
ではありますが例えばやたらと長い未変換文字列がずらずらと続いて適当な変換・確定のタイミングがつかめないなどの場合は処理の負荷の問題も関わってくるので句読点・ピリオド・カンマなどを目印に適宜変換させるなどというのも考慮に入れておきたいところです。
スペースだけにとどまらず、各種記号も未変換文字列の中に組み込むことが実現すれば「価格.com」や「Re：ゼロから始まる異世界生活」なども普通に通常変換からの１変換でタイプできることになり、構文解析上も「○○を見た」「きっと○○だ」などで使用し文中でも途切れなく名詞として識別されてスッキリすると思います。
ただ記号・スペースの類も単語辞書に含めるとなるとメモリ消費・処理の煩雑化などリソース負荷をどのくらいかけてしまうのか未知数で、私は技術的な事にはあまり専門的な事を言えないのでこれ以上深く言及するのは避けたいと思います。
一つだけ言えるのはペンタクラスタキーボードの利点を生かしてアルファベット混在文もマルチに使えるようにアルファベット単語の扱いも拡張して定義しなおして、でにをは別口入力となじむようなしくみにしていくことが大事だと思います。
スペースや記号類の扱いはそのための足場固めの一環であるということであり細部をよく煮詰めていくことでアルファベットまわりの利便性を高めていくことにつながるだろうという思いがあります。
これと関連してペンタクラスタキーボード配置図には[半角/全角]のキーは一応あるものの、これは日本語入力のON/OFFのためにあるものではなく、文字通りアルファベット入力の半角/全角を指定するために存在するキーとしておく方が元々の目的を果たしており収まりも良いと思います。
ただフォーム入力時や普通に英文だけを入力しておきたい用途のためには日本語入力のON/OFF切り替えも残しておかなくてはならないので例えばタッチ液晶面に「英数入力ON」、ペンタクラスタキーボード盤面上に「日本語入力ON」のキーを別途設置しておく方がいいのかもしれません。
(日本語入力ONの方はかな等を入力した時点で日本語入力が始まったと認識できるのでいらないかもしれませんが(^_^;))
この辺はApple JISキーボードなどがスペースキーの両脇に「かな」キー、「英数」キーが配置されていて半角/全角のトグル式切り替えと違って即応的に押せば切り替わるので混乱が少なくわかりやすいと思います。
この例を大いに参考にして日本語入力(アルファベット混在含む)に切り替えるキーをどこかわかりやすいところ、例えばペンタクラスタキーボード上の左側のTabキーの隣、「半/全」のところに成り代わって設置するのも一策だと思います。「半/全」はそこまで重要な機能ではないと思われるのでどこか端っこやタッチ液晶部へ転置するのも致し方ないでしょう。
なおこの記事ではスペースや記号がいかなる場合でも単語のつながりを分断し、ひとつながりの単語であることを認識できないようになっているかのように書いていますが実際のところ個別の単語の認識にどれだけ影響しているのかを正確に把握してはおりません。
完全に思い込みで書いたものでありいらんお世話となるようなものかもしれませんが一つご勘弁のほどをお願いします。どなたかアルファベット混在文まわりの構文解析に詳しいWebサイト・書籍をご存知の方がいらっしゃいましたらメッセージフォームからどうぞ知らせ下さい。
構文解析的にもひとまとまりの単語なら途切れることなくひとかたまりの単語として認識しておいた方が運用上都合が良いと思います。ペンタクラスタキーボードにはでにをは別口入力があるので区切り目の把握はこれらの助詞・助動詞などのパーツや句読点・！？・括弧あるいは改行・確定などで区別すればこれで事足りると思われますが今後検証が必要になってくるかと思います。
ローマ字入力と日本語入力の境目がなくモード切替をしないで良いのはいいのですが、英文を入力していても未確定の文字列として変換プロセスが完了していないというのはなんだか連続入力中だと少し不安になってしまいそうな感覚もあります。しかし少々面倒ですが一連の英語の入力文の後にも日本語入力と同じ手続きで[Enterキー]で確定していくのが良いだろうと吟味の結果思い至りました。
.(ピリオド)や,(カンマ)、!?(感嘆符・疑問符)などが現れた時点でいったん自動確定させるなどの措置はあり得ると思うのでその辺はユーザーの設定などで動作を指定できればいいかと思いますが、それ以前にでにをは別口入力でも逐次確定処理はしていないので(記号ではないが)日本語文の入力時と同じように最後の変換・確定が済むまで未変換文字列としてふるまうほうが統一的で良いと思います。
ではありますが例えばやたらと長い未変換文字列がずらずらと続いて適当な変換・確定のタイミングがつかめないなどの場合は処理の負荷の問題も関わってくるので句読点・ピリオド・カンマなどを目印に適宜変換させるなどというのも考慮に入れておきたいところです。
スペースだけにとどまらず、各種記号も未変換文字列の中に組み込むことが実現すれば「価格.com」や「Re：ゼロから始まる異世界生活」なども普通に通常変換からの１変換でタイプできることになり、構文解析上も「○○を見た」「きっと○○だ」などで使用し文中でも途切れなく名詞として識別されてスッキリすると思います。
ただ記号・スペースの類も単語辞書に含めるとなるとメモリ消費・処理の煩雑化などリソース負荷をどのくらいかけてしまうのか未知数で、私は技術的な事にはあまり専門的な事を言えないのでこれ以上深く言及するのは避けたいと思います。
一つだけ言えるのはペンタクラスタキーボードの利点を生かしてアルファベット混在文もマルチに使えるようにアルファベット単語の扱いも拡張して定義しなおして、でにをは別口入力となじむようなしくみにしていくことが大事だと思います。
スペースや記号類の扱いはそのための足場固めの一環であるということであり細部をよく煮詰めていくことでアルファベットまわりの利便性を高めていくことにつながるだろうという思いがあります。
これと関連してペンタクラスタキーボード配置図には[半角/全角]のキーは一応あるものの、これは日本語入力のON/OFFのためにあるものではなく、文字通りアルファベット入力の半角/全角を指定するために存在するキーとしておく方が元々の目的を果たしており収まりも良いと思います。
ただフォーム入力時や普通に英文だけを入力しておきたい用途のためには日本語入力のON/OFF切り替えも残しておかなくてはならないので例えばタッチ液晶面に「英数入力ON」、ペンタクラスタキーボード盤面上に「日本語入力ON」のキーを別途設置しておく方がいいのかもしれません。
(日本語入力ONの方はかな等を入力した時点で日本語入力が始まったと認識できるのでいらないかもしれませんが(^_^;))
この辺はApple JISキーボードなどがスペースキーの両脇に「かな」キー、「英数」キーが配置されていて半角/全角のトグル式切り替えと違って即応的に押せば切り替わるので混乱が少なくわかりやすいと思います。
この例を大いに参考にして日本語入力(アルファベット混在含む)に切り替えるキーをどこかわかりやすいところ、例えばペンタクラスタキーボード上の左側のTabキーの隣、「半/全」のところに成り代わって設置するのも一策だと思います。「半/全」はそこまで重要な機能ではないと思われるのでどこか端っこやタッチ液晶部へ転置するのも致し方ないでしょう。
なおこの記事ではスペースや記号がいかなる場合でも単語のつながりを分断し、ひとつながりの単語であることを認識できないようになっているかのように書いていますが実際のところ個別の単語の認識にどれだけ影響しているのかを正確に把握してはおりません。
完全に思い込みで書いたものでありいらんお世話となるようなものかもしれませんが一つご勘弁のほどをお願いします。どなたかアルファベット混在文まわりの構文解析に詳しいWebサイト・書籍をご存知の方がいらっしゃいましたらメッセージフォームからどうぞ知らせ下さい。
細かい話なのですがよくあるアルファベットを含む変換で、例えば「cdラジカセ」と入力したときに「cd」が大文字の「CD」になっていないのをいちいち直すのは何かトホホな感じがしますが、アルファベットと日本語の混在した単語の入力・変換にはなんだか釈然としないものも多々見かけるものです。
IMEの単語登録のとき読みにアルファベットも登録できますが、登録・学習のない段階でふらっと気軽に入力しようとしても、アルファベットまわりの変換は純日本語の文字列の変換より何だか少し物足りない傾向を感じてしまうのは私だけではないはずです。
たとえばIT革命という文字を出そうと思ってitkakumeiと入力しても「いt革命」になってしまうのはいただけません。大文字にするべく[Shiftキー]を同時押しして"IT"とやらねばいけませんがこんなのを毎回やるのは正直面倒です。
ローマ字入力時、かな入力時両方ともに時としてこのような弱点に直面させられますがせっかくペンタクラスタキーボードは日本語の字種(かな)とアルファベットとが完全に分離されているのだから[Shiftキー]同時押しなど気にせず流れのまま同列に入力していくほうがシンプルでわかりやすいと思います。
このようなトラブルは変換前のアルファベットの未変換文字列の扱いの煩雑さに原因があると思います。半角/全角の区別もありますし、ローマ字入力ならそれぞれアルファベット・かなに変換したい部分の局所的な判別も時に困難ですし、もちろん大文字・小文字の区別もあります。もう少し整理して全体の風通しを良くする必要があるかと思います。
IMEの振る舞いで日本語部分とアルファベット部分の処理が地続きでなく分離されておりちぐはぐな事はさまざまな弊害を生みます。まずこの部分をペンタクラスタキーボードの特性にあわせて統一的に入力できるようにするのが最優先事項だと思いますので、以下方策を考えていこうと思います。
例えば「pcでimeを扱ってhappyになる」と入力するとコンピュータがアルファベットを適宜大文字に変換して「PCでIMEを扱ってHappyになる」と変換されることを実現したいのですがこのとき面倒な[Shiftキー]同時押しでいちいちアルファベット大文字にさせるなどの作業をなくすような設計を念頭に置いています。
それとimeと入力したときに"いめ"にせずとも単にタッチ液晶部からimeと打ち込むだけで済むよう日本語は日本語、アルファベットはアルファベットとなるよう住み分けを明快にすれば、アルファベットとかなの交錯してしまうトラブルを避けることできペンタクラスタキーボードならそれが可能になるという点が重要です。
ペンタクラスタキーボード特徴的なところは英語の長文をあえてタッチ液晶でしこしこ入力している場面というのは想定しておらず、あくまで日本語の表現の範囲内でコラージュ的に使用していくのに向いているということです。
HTMLのタグの類などはどうするのかという問題はまた別の話ですが、アルファベットの語句も日本語とほぼ同じような感じで随所に使って、文字列変換のときも漢字が変換されていくのと同じような感覚で表記上大文字にするか小文字にするか(あるいは先頭だけ大文字にするなど)を適切に提示・選択いけるようなものをデザインしうまく一体化していくことでアルファベット語句混在の文章の変換の使い勝手が飛躍的によくなると思います。
アルファベットを含んだ未変換文字列ももはや日本語の一部です。アルファベットも日本語も一律の土俵でおこなうインターフェイスを設計することが第一方針です。
しかし、アルファベットを含む文章を日本語文章と同じような感覚で変換できるようにさせることは思ったより簡単ではなく、それなりの構えというのが必要になってきます。
例えば、システムインテグレータ(SIer)という語がありますが、どこかの誰かが造語で小文字のsierという字で表記する(シアー？)という語句をつくったというときにいつも大文字交じりのSIerと変換されるとやりにくいなどの問題がなくはないことや、
TOYですでに単語登録しているときにToysrusと変換したかったら意に反してTOYsrusみたいになってしまうこともアルファベット未変換文字列の問題として起こりうることです。
アルファベットはなまじ文字バリエーションが少ないためにかな漢字変換みたいな発想の変換規則を適用してしまうと局所的なところで数々の無駄な変換が起こる可能性が高く大文字小文字を表記上うまく使い分けたいという目的に適うというのは容易なことではありません。
そこでアルファベットの語句を余計な変換で煩わせないために入力したアルファベットをとりあえずは素直に、単語の学習や登録された表記にはあえてしないままの形で出力する[英・無変換]のキーを設置する案を提案したいと思います。
この変換においては例えばlivetuneやfm那覇のようにliveやfmの部分を大文字にはしたくないとき有効でたとえ学習語・登録語にLIVEやFMのように大文字表記のものが登録されていても影響されずに入力された文字列を出すもので、読者の方の中には「なんだlivetuneなりfm那覇なり最後まで文字列が完全一致しているときに余計な変換が起こらないようにすればいいだけの話じゃないか」
とお思いの方もおられるかもしれませんが、まず初回の変換時は登録がない状態ですし、とりあえず文字列がプレーンに出力されることが保証されているという点で間違いがない点が重要です。
この変換はかなとアルファベットが混ざっている文字列(例:Macでcheeseburgerをeatする)においてもアルファベット部分にのみ作用して変換してかな部分には影響せず、途中で[Shirtキー]を同時押しして大文字部分が指定されていた部分はそれも反映した変換にすることが求められる要件です。
私たちが普段使うような半角英数を前もって押す”モード変換的”なスタイルではなく、アルファベット部分も未変換文字列として処理し後からなんらかの変換キーを押して変換する”後決め”スタイルを意識的に用います。
使用するキーはファンクションキーのF9・F10でもいいのですが前述の要件を満たすものなので具体的なはたらきは従来のF9・F10キーとは一味違うものになることに注意が必要です。(日本語部無干渉型半角英数・全角英数)
[英・無変換キー]とは別に、これもペンタクラスタキーボードの特性上なくてはならないものが英語(アルファベット文字列)の予測変換です。
ペンタクラスタキーボードではアルファベット全般の入力が不便なので予測入力でサポートすることが望ましく、まだ方針は定まっていませんが日本語の予測変換と英語の予測変換をわけて処理するか日本語・英語ともに共通のキー操作でするかの両面を視野に入れて今後決めていこうと思っています。
いずれにせよ予測入力のスタイルは文字入力中リアルタイムにバルーン表示的に選択するようなものではなく、予測してもらいたい語句の最初の2文字(あるいはユーザーが設定した文字数)を入力したところで[Tabキー]を押すと変換候補が表示されるようなスタイルが良いかと思います。
ここの操作はよく使われそうなのでは[Tabキー]ではなくペンタクラスタキーボード盤面上に新たなキーを用意してわかりやすいところに設置するのも良いかもしれません。
あと細かいところで言えば「iPad Air 3」のような語句を予測変換させるときには大文字小文字を厳密に区別せずに最初の2文字が「ip」でも適宜変換させるようにすればよいかと思います。
ということでアルファベットを含む文字列の変換には以下の4つの場合にわけてそれぞれ機能させることが求められると思います。
・アルファベット混在文を[通常変換]する場合
・アルファベット混在文を[英・無変換キー](半角・全角)でアルファベット部だけを余計な変換が起こらないように変換する場合
・[Tabキー]もしくは別途新設した[予測変換キー]で頭の数文字から予測変換する場合
・[通常変換]あるいは[英・無変換キー]ではあるがアルファベットの大文字小文字が指定されていてその単語はそのまま手をつけずに変換する場合
以上がアルファベット混在文字列の扱いについての考察とそれに対する4つの方策のまとめでした。
IMEの単語登録のとき読みにアルファベットも登録できますが、登録・学習のない段階でふらっと気軽に入力しようとしても、アルファベットまわりの変換は純日本語の文字列の変換より何だか少し物足りない傾向を感じてしまうのは私だけではないはずです。
たとえばIT革命という文字を出そうと思ってitkakumeiと入力しても「いt革命」になってしまうのはいただけません。大文字にするべく[Shiftキー]を同時押しして"IT"とやらねばいけませんがこんなのを毎回やるのは正直面倒です。
ローマ字入力時、かな入力時両方ともに時としてこのような弱点に直面させられますがせっかくペンタクラスタキーボードは日本語の字種(かな)とアルファベットとが完全に分離されているのだから[Shiftキー]同時押しなど気にせず流れのまま同列に入力していくほうがシンプルでわかりやすいと思います。
このようなトラブルは変換前のアルファベットの未変換文字列の扱いの煩雑さに原因があると思います。半角/全角の区別もありますし、ローマ字入力ならそれぞれアルファベット・かなに変換したい部分の局所的な判別も時に困難ですし、もちろん大文字・小文字の区別もあります。もう少し整理して全体の風通しを良くする必要があるかと思います。
IMEの振る舞いで日本語部分とアルファベット部分の処理が地続きでなく分離されておりちぐはぐな事はさまざまな弊害を生みます。まずこの部分をペンタクラスタキーボードの特性にあわせて統一的に入力できるようにするのが最優先事項だと思いますので、以下方策を考えていこうと思います。
例えば「pcでimeを扱ってhappyになる」と入力するとコンピュータがアルファベットを適宜大文字に変換して「PCでIMEを扱ってHappyになる」と変換されることを実現したいのですがこのとき面倒な[Shiftキー]同時押しでいちいちアルファベット大文字にさせるなどの作業をなくすような設計を念頭に置いています。
それとimeと入力したときに"いめ"にせずとも単にタッチ液晶部からimeと打ち込むだけで済むよう日本語は日本語、アルファベットはアルファベットとなるよう住み分けを明快にすれば、アルファベットとかなの交錯してしまうトラブルを避けることできペンタクラスタキーボードならそれが可能になるという点が重要です。
ペンタクラスタキーボード特徴的なところは英語の長文をあえてタッチ液晶でしこしこ入力している場面というのは想定しておらず、あくまで日本語の表現の範囲内でコラージュ的に使用していくのに向いているということです。
HTMLのタグの類などはどうするのかという問題はまた別の話ですが、アルファベットの語句も日本語とほぼ同じような感じで随所に使って、文字列変換のときも漢字が変換されていくのと同じような感覚で表記上大文字にするか小文字にするか(あるいは先頭だけ大文字にするなど)を適切に提示・選択いけるようなものをデザインしうまく一体化していくことでアルファベット語句混在の文章の変換の使い勝手が飛躍的によくなると思います。
アルファベットを含んだ未変換文字列ももはや日本語の一部です。アルファベットも日本語も一律の土俵でおこなうインターフェイスを設計することが第一方針です。
しかし、アルファベットを含む文章を日本語文章と同じような感覚で変換できるようにさせることは思ったより簡単ではなく、それなりの構えというのが必要になってきます。
例えば、システムインテグレータ(SIer)という語がありますが、どこかの誰かが造語で小文字のsierという字で表記する(シアー？)という語句をつくったというときにいつも大文字交じりのSIerと変換されるとやりにくいなどの問題がなくはないことや、
TOYですでに単語登録しているときにToysrusと変換したかったら意に反してTOYsrusみたいになってしまうこともアルファベット未変換文字列の問題として起こりうることです。
アルファベットはなまじ文字バリエーションが少ないためにかな漢字変換みたいな発想の変換規則を適用してしまうと局所的なところで数々の無駄な変換が起こる可能性が高く大文字小文字を表記上うまく使い分けたいという目的に適うというのは容易なことではありません。
そこでアルファベットの語句を余計な変換で煩わせないために入力したアルファベットをとりあえずは素直に、単語の学習や登録された表記にはあえてしないままの形で出力する[英・無変換]のキーを設置する案を提案したいと思います。
この変換においては例えばlivetuneやfm那覇のようにliveやfmの部分を大文字にはしたくないとき有効でたとえ学習語・登録語にLIVEやFMのように大文字表記のものが登録されていても影響されずに入力された文字列を出すもので、読者の方の中には「なんだlivetuneなりfm那覇なり最後まで文字列が完全一致しているときに余計な変換が起こらないようにすればいいだけの話じゃないか」
とお思いの方もおられるかもしれませんが、まず初回の変換時は登録がない状態ですし、とりあえず文字列がプレーンに出力されることが保証されているという点で間違いがない点が重要です。
この変換はかなとアルファベットが混ざっている文字列(例:Macでcheeseburgerをeatする)においてもアルファベット部分にのみ作用して変換してかな部分には影響せず、途中で[Shirtキー]を同時押しして大文字部分が指定されていた部分はそれも反映した変換にすることが求められる要件です。
私たちが普段使うような半角英数を前もって押す”モード変換的”なスタイルではなく、アルファベット部分も未変換文字列として処理し後からなんらかの変換キーを押して変換する”後決め”スタイルを意識的に用います。
使用するキーはファンクションキーのF9・F10でもいいのですが前述の要件を満たすものなので具体的なはたらきは従来のF9・F10キーとは一味違うものになることに注意が必要です。(日本語部無干渉型半角英数・全角英数)
[英・無変換キー]とは別に、これもペンタクラスタキーボードの特性上なくてはならないものが英語(アルファベット文字列)の予測変換です。
ペンタクラスタキーボードではアルファベット全般の入力が不便なので予測入力でサポートすることが望ましく、まだ方針は定まっていませんが日本語の予測変換と英語の予測変換をわけて処理するか日本語・英語ともに共通のキー操作でするかの両面を視野に入れて今後決めていこうと思っています。
いずれにせよ予測入力のスタイルは文字入力中リアルタイムにバルーン表示的に選択するようなものではなく、予測してもらいたい語句の最初の2文字(あるいはユーザーが設定した文字数)を入力したところで[Tabキー]を押すと変換候補が表示されるようなスタイルが良いかと思います。
ここの操作はよく使われそうなのでは[Tabキー]ではなくペンタクラスタキーボード盤面上に新たなキーを用意してわかりやすいところに設置するのも良いかもしれません。
あと細かいところで言えば「iPad Air 3」のような語句を予測変換させるときには大文字小文字を厳密に区別せずに最初の2文字が「ip」でも適宜変換させるようにすればよいかと思います。
ということでアルファベットを含む文字列の変換には以下の4つの場合にわけてそれぞれ機能させることが求められると思います。
・アルファベット混在文を[通常変換]する場合
・アルファベット混在文を[英・無変換キー](半角・全角)でアルファベット部だけを余計な変換が起こらないように変換する場合
・[Tabキー]もしくは別途新設した[予測変換キー]で頭の数文字から予測変換する場合
・[通常変換]あるいは[英・無変換キー]ではあるがアルファベットの大文字小文字が指定されていてその単語はそのまま手をつけずに変換する場合
以上がアルファベット混在文字列の扱いについての考察とそれに対する4つの方策のまとめでした。
<新分野・新聞屋を三属性で使い分ける>
新分野…属性ハ(第三の属性)
新聞屋…属性イ(名詞全般)
ポイント：新は新しいことをあらわす接頭語なので第三の属性。新聞屋は[新聞]+[屋]と解釈して接尾語がつく語とも捉えられるが名詞的なはたらきが強く新分野の方がより第三の属性の趣向に沿っていると考えられます。
もう一例
<旧知・窮地・給地を三属性で使い分ける>
旧知…属性ハ(第三の属性)
窮地…本来は追い詰められて逃げ場のない苦しい状態や立場をあらわす名詞だが、様態を叙述する機能をもつためここでは属性ロと解釈します。
給地…属性イ(名詞全般)江戸時代、主君から家臣に与えられた知行地という意味の名詞。
ポイント：旧は古い物事・以前の・もとをあらわす接頭語なので第三の属性。「旧に復する」のように単独で使われた場合も急と区別しやすくするため第三の属性として変換します。
☆2例通して新⇔旧の対立概念はさまざまな語について意味を付加する接頭語として使われているので第三の属性とするのが妥当です。「しん」にはいろいろと他に同音異義パーツがありそうですが、「きゅう」は急と区別しやすく「旧姓」「旧交」などの語をすぐに浮かび上がらせることができるので便利そうです。
新分野…属性ハ(第三の属性)
新聞屋…属性イ(名詞全般)
ポイント：新は新しいことをあらわす接頭語なので第三の属性。新聞屋は[新聞]+[屋]と解釈して接尾語がつく語とも捉えられるが名詞的なはたらきが強く新分野の方がより第三の属性の趣向に沿っていると考えられます。
もう一例
<旧知・窮地・給地を三属性で使い分ける>
旧知…属性ハ(第三の属性)
窮地…本来は追い詰められて逃げ場のない苦しい状態や立場をあらわす名詞だが、様態を叙述する機能をもつためここでは属性ロと解釈します。
給地…属性イ(名詞全般)江戸時代、主君から家臣に与えられた知行地という意味の名詞。
ポイント：旧は古い物事・以前の・もとをあらわす接頭語なので第三の属性。「旧に復する」のように単独で使われた場合も急と区別しやすくするため第三の属性として変換します。
☆2例通して新⇔旧の対立概念はさまざまな語について意味を付加する接頭語として使われているので第三の属性とするのが妥当です。「しん」にはいろいろと他に同音異義パーツがありそうですが、「きゅう」は急と区別しやすく「旧姓」「旧交」などの語をすぐに浮かび上がらせることができるので便利そうです。
<未完・未刊・蜜柑を三属性で使い分ける>
未完・未刊…属性ハ(第三の属性)
蜜柑…属性イ(名詞全般)
ポイント：未は主に動詞の前につく打ち消しの接頭語なので第三の属性。打ち消しの効果に加えて今後状態が変化する含みをもたせたニュアンスがあります。
もう一例
<既知・基地・吉・機知を三属性で使い分ける>
既知…属性ハ(第三の属性)
基地…属性イ(名詞全般)
吉…本来はめでたいことをあらわす名詞であり・人名に使われるパーツでもありますが、「節約すると吉」のように用言的に使われるのでここでは属性ロ(用言全般)とします。
機知…本来はその場に応じて素早く働く知恵をあらわす名詞でありますが、「機知に富む」で定型句的に使われるものなのでここでは属性ロと解釈します。
ポイント：既は動作・状態などが終わっている・すでに済んでいることをあらわす接頭語なので第三の属性。
☆2例通して未⇔既の対立概念は動詞をはじめさまざまな語について意味を付加する接頭語として使われているので第三の属性としても最も顕著な例だと言えます。
音も一文字と短いため沢山の同音異義語の混同のもととなるのでこうして属性付けをして区別すれば選択しやすいので誤変換対策に非常に有効です。
未完・未刊…属性ハ(第三の属性)
蜜柑…属性イ(名詞全般)
ポイント：未は主に動詞の前につく打ち消しの接頭語なので第三の属性。打ち消しの効果に加えて今後状態が変化する含みをもたせたニュアンスがあります。
もう一例
<既知・基地・吉・機知を三属性で使い分ける>
既知…属性ハ(第三の属性)
基地…属性イ(名詞全般)
吉…本来はめでたいことをあらわす名詞であり・人名に使われるパーツでもありますが、「節約すると吉」のように用言的に使われるのでここでは属性ロ(用言全般)とします。
機知…本来はその場に応じて素早く働く知恵をあらわす名詞でありますが、「機知に富む」で定型句的に使われるものなのでここでは属性ロと解釈します。
ポイント：既は動作・状態などが終わっている・すでに済んでいることをあらわす接頭語なので第三の属性。
☆2例通して未⇔既の対立概念は動詞をはじめさまざまな語について意味を付加する接頭語として使われているので第三の属性としても最も顕著な例だと言えます。
音も一文字と短いため沢山の同音異義語の混同のもととなるのでこうして属性付けをして区別すれば選択しやすいので誤変換対策に非常に有効です。
反対の意味・対になる意味を組み合わせた熟語は品詞上は名詞とされる場合が多いのですが、なにぶん両極から見た抽象概念なので単純な事物の名詞概念の語とは一線を画しているありかたが特徴的なので、これらの語は第三の属性である属性ハに分類するのがいいかと思われます。
ずらずらっと挙げていきますがこれらは単に対義語ペアの語をやみくもに並べたものではなく他に名詞属性や用言の属性をもつ同じ音の語が想起される語に絞って列挙していきたいと思います。
(反対の意味・対になる意味を組み合わせた熟語の例)
栄枯・開閉・可否・緩急・寛厳・寒暑・甘酸・苦楽・経緯・軽重・慶弔・公私・高低・硬軟・攻防・興亡・山河・自他・首尾・真偽・生死・正邪・盛衰・多寡・長幼・悲喜・物心
(対照：それらの語と同音の語句列挙)
英子・海兵・歌碑・坎宮・還元/管弦/諫言・甘藷・換算/閑散・暗く・敬意・傾聴・効し/行使・肯定/工程/皇帝・江南/港南/甲南・弘法/工房・参賀・舌の濁ったときのもの・守備・審議/信義・製紙/静止/制し/精子・聖者・聖水・鷹/タカ・徴用/重用・引き/弾き・仏心
関連事項として漢字二字の熟語の配列構造のタイプは他にも以下のようなものがあるので留意したいところです。
・意味が似ている漢字の組み合わせ(例：郷里)
・主述関係になっている構造(例：人造)
・「動詞+目的語」の形または「動詞+補語」の形とみなし補足関係になっているもの(例：登庁)
・前の漢字が後ろの漢字を修飾する構造(例：厳選)
これらの構成の語の中には、属性ハに分類してもよさそうなものがあるのかどうかじっくり検討していきたいところです。
基本的に接頭語接尾語を含みそうな構成の語に適用できそうですが同音異義語でどうしても区別したいときなどには主述関係・補足関係・修飾関係にある語構成の語句でも分類上属性ハと解釈するケースがいくつか出てくるかもしれません。
ずらずらっと挙げていきますがこれらは単に対義語ペアの語をやみくもに並べたものではなく他に名詞属性や用言の属性をもつ同じ音の語が想起される語に絞って列挙していきたいと思います。
(反対の意味・対になる意味を組み合わせた熟語の例)
栄枯・開閉・可否・緩急・寛厳・寒暑・甘酸・苦楽・経緯・軽重・慶弔・公私・高低・硬軟・攻防・興亡・山河・自他・首尾・真偽・生死・正邪・盛衰・多寡・長幼・悲喜・物心
(対照：それらの語と同音の語句列挙)
英子・海兵・歌碑・坎宮・還元/管弦/諫言・甘藷・換算/閑散・暗く・敬意・傾聴・効し/行使・肯定/工程/皇帝・江南/港南/甲南・弘法/工房・参賀・舌の濁ったときのもの・守備・審議/信義・製紙/静止/制し/精子・聖者・聖水・鷹/タカ・徴用/重用・引き/弾き・仏心
関連事項として漢字二字の熟語の配列構造のタイプは他にも以下のようなものがあるので留意したいところです。
・意味が似ている漢字の組み合わせ(例：郷里)
・主述関係になっている構造(例：人造)
・「動詞+目的語」の形または「動詞+補語」の形とみなし補足関係になっているもの(例：登庁)
・前の漢字が後ろの漢字を修飾する構造(例：厳選)
これらの構成の語の中には、属性ハに分類してもよさそうなものがあるのかどうかじっくり検討していきたいところです。
基本的に接頭語接尾語を含みそうな構成の語に適用できそうですが同音異義語でどうしても区別したいときなどには主述関係・補足関係・修飾関係にある語構成の語句でも分類上属性ハと解釈するケースがいくつか出てくるかもしれません。
