CSJ の検索 - 国立国語研究所

527
第9章
CSJ の検索
前川喜久雄
本章では CSJ を検索する手法をいくつか紹介する。CSJ には 1 章および 8 章で言及した XML ブラウザ
（CSJ XML Browser）のほか，音声再生分析機能付きの転記テキストブラウザ (MonoForC) が付属している。
これらは CSJ の開発メンバー（前者は塚原渉，後者は籠宮隆之）によって開発されたソフトであり，それなり
の使い勝手を実現しているが，いずれも単一のファイルを検索対象とした設計であり，コーパス全体の検索に
はむいていない。
1.7 節に紹介したようなコーパス全体を対象とした統計情報をえるための検索方法はユーザーの工夫にまか
されている。そのため折角 CSJ を入手しても，検索方法がわからないために CSJ を十分に利用できないでい
るユーザーもいるようである。
以下では CSJ 全体を検索するためにどのような手段があるかを大まかに理解してもらうことを目的として，
代表的な検索手法を紹介する。
9.1 GREP と正規表現
GREP は正規表現が使える文字列検索コマンドである。もともとは Unix の世界で生まれたが，現在では
Windows 環境でも広く利用されている。ただし Windows の標準コマンドではないので，ユーザーはソフトを
インストールする必要がある (http://www.vector.co.jp/などでフリーウェアを入手できる)。
いま，すべての転記テキストがディレクトリ Trn に格納されているとしよう。Windows のコマンドプロン
プトを起動して，ディレクトリ Trn に移動し，以下のコマンドを入力すると，転記ファイル中の文字列「中国
語」を含むすべての行が表示される。記号「>」はコマンドプロンプト画面に表示されるプロンプトである。
> grep 中国語 *.trn
実際に実行してみると，以下のような出力がコンソールに表示されるはずである。各行の先頭には，文字列
を含むファイル名が示され，その後に検索文字列を含む転記ファイル中の行が表示されている。
528
第9章
CSJ の検索
A01F0132.trn:中国語の & チューゴクゴノ
A01M0097.trn:中国語においては & チューゴクゴニオイテワ
A01M0097.trn:標準中国語の & ヒョージュンチューゴクゴノ
A01M0097.trn:中国語におきまして & チューゴクゴニオキマシテ
A01M0097.trn:標準中国語の & ヒョージュンチューゴクゴノ
A01M0097.trn:標準中国語の & ヒョージュンチューゴクゴノ
A01M0097.trn:中国語において & チューゴクゴニオイテ
A01M0286.trn:標準中国語について & ヒョージュンチューゴクゴニツイテ
A01M0286.trn:中国語では & チューゴ (? ク) ゴデワ
A01M0286.trn:標準中国語の & ヒョー (? ジュ) ンチューゴ (? ク) ゴノ
A01M0286.trn:標準中国語の & ヒョージュンチュー (? ゴ) クゴノ
（以下省略）
図 9.1
GREP の出力例
これが一番単純な GREP の用法であるが，検索文字列に正規表現を利用できるのが GREP の特徴である。
次の例は「中国人」または「中国語」を含む列を表示する。
> grep 中国 [人語] *.trn
A01F0132.trn:中国語の & チューゴクゴノ
A01M0077.trn:中国人は & チューゴクジンワ
A01M0097.trn:中国語においては & チューゴクゴニオイテワ
A01M0097.trn:標準中国語の & ヒョージュンチューゴクゴノ
A01M0097.trn:中国語におきまして & チューゴクゴニオキマシテ
A01M0097.trn:標準中国語の & ヒョージュンチューゴクゴノ
A01M0097.trn:標準中国語の & ヒョージュンチューゴクゴノ
A01M0097.trn:中国語において & チューゴクゴニオイテ
A01M0104.trn:中国人男性留学生 & チューゴクジンダンセーリューガクセー
A01M0258.trn:中国人留学生 & チューゴクジンリューガクセー
A01M0258.trn:中国人留学生と & チューゴクジンリューガクセート
（以下省略）
図 9.2 GREP による正規表現を利用した検索の出力例
正規表現にはいろいろな規格がある。GREP に実装されているのは比較的単純な正規表現であるが，それで
も工夫次第で巧妙な検索を実施できる。コーパスを分析しようとするユーザーは是非学んでおくべき知識のひ
とつである。
9.2 スクリプト言語
GREP は便利なツールだが，やはり限界がある。コーパスの分析では，複雑な条件判断をともなう検索条件
を指定したり，検索結果のテキストを加工したり，あるいはデータに与えられている構造を利用した検索をお
こなう必要が生じることがある。そのような場合に重宝するのが，AWK, Perl, Ruby などのスクリプト言語
である。
ここでは AWK の例を示すことにする。AWK は元祖スクリプト言語というべき存在である。機能は限定さ
れているが，簡単に覚えられる。AWK も Windows の標準コマンドではないので（その点は Perl も Ruby も
529
9.2 スクリプト言語
同様）
，やはりインストールが必要である。筆者は mawk と呼ばれるバージョンを利用している。
最初の例は，転記ファイル中の基本形だけを抽出するスクリプトである。図 9.1，9.2 からわかるように，
CSJ の転記ファイルでは，漢字かな混じりで表記された基本形と片仮名表記された発音形を記号「&」で分離
して記録する形式を採用している。
下記の例中，
「mawk32」は筆者が利用している AWK のコマンド名であり，利用する AWK の版により gawk,
jgawk, nawk などと変化する。「-F"&"」は起動オプションであり，入力行をフィールドに分割するための区切
り記号として記号「&」を指定している。最後にシングルクオートで囲まれた「NF==2{print FILENAME, $1}」
がスクリプト本体であり，
「1 行が 2 フィールドから構成されているレコードを読んだならば，入力ファイル名
と第 1 番目のフィールドを印刷せよ」という指示が記述されている。「1 行が 2 フィールドからなる」という条
件が必要なのは，転記テキストファイルには，基本形の情報をふくまない行も存在するので，それを除外する
ためである。実行結果は図 9.3 のようになる。スクリプト中の「$1」を「$2」に書き換えると，今度は転記テ
キストの発音形が表示される。
> mawk32 -F"&" ’NF==2{print FILENAME, $1}’ *.trn
a01f0001.trn
a01f0001.trn
a01f0001.trn
a01f0001.trn
a01f0001.trn
a01f0001.trn
a01f0001.trn
a01f0001.trn
a01f0001.trn
a01f0001.trn
まず
発表は
最初に
簡単に
エコーロケーション機能について
説明いたします
その後
これまで
行なってきました
コウモリの
（以下省略）
図 9.3 AWK スクリプトの実行結果（基本形の抽出）
この出力は以下の方法でテキストファイルに保存することができる。以下のコマンドの場合，出力は
result.txt というファイルに保存される。AWK スクリプトの直後におかれている記号「>」はコマンドやス
クリプトの出力先を変更するための命令で，リダイレクトと呼ばれている。
> mawk32 -F"&" ’NF==2{print FILENAME, $1}’ *.trn > result.txt
ところで，図 9.3 では最初に処理されたファイル A01F0001.trn の基本形が冒頭から順に表示されているだ
けである。これではあまり面白くないのでスクリプトを少し変更しよう。
> mawk32 -F"&" ’NF==2{if($1~/中国 [人語]/)print FILENAME, $1}’ *.trn
このスクリプトは，1 番目のフィールドに「中国人」または「中国語」という文字列が含まれている場合だ
け印刷をおこなうように修正されている。先に GREP で利用したのと同じ正規表現が利用されていることに
注目してもらいたい。出力は以下のようになる。いろいろなファイルから「中国人」ないし「中国語」を含む
基本形だけが選択されている。
パイプを用いた処理にも触れておく。パイプとは複数のコマンドやスクリプトを記号「|」でつないで，一
530
第9章
CSJ の検索
a01f0132.trn
a01m0077.trn
a01m0097.trn
a01m0097.trn
a01m0097.trn
a01m0097.trn
a01m0097.trn
a01m0097.trn
a01m0104.trn
a01m0258.trn
a01m0258.trn
中国語の
中国人は
中国語においては
標準中国語の
中国語におきまして
標準中国語の
標準中国語の
中国語において
中国人男性留学生
中国人留学生
中国人留学生と
（以下省略）
図 9.4 AWK スクリプトの実行結果（正規表現による検索）
連の処理としてまとめて記述する方法であり，ひとつひとつは単純な処理を積み重ねて最終的に複雑な処理を
実現する方法である。
以下の例では，GREP による正規表現を用いた検索結果（図 9.2 に該当）がパイプによって AWK スクリプ
トにわたされている。GREP と AWK は並行して稼動しており，GREP によって発見された文字列は発見さ
れ次第，次々と AWK にわたされる。
AWK スクリプトは区切り記号「&」によって入力データをフィールドに分解した後，第 1 フィールド ($1)
を印刷しているだけである。つまり，このスクリプトにはデータ検索の条件が何も記述されていない。データ
の検索は GREP にまかせ，その出力を整形する機能だけを AWK で記述しているのである。GREP が得意な
ことは GREP にまかせ（GREP の検索速度は AWK よりもはるかに速い），GREP では不可能な処理だけを
AWK にまかせ，両者をパイプで連結しているわけである。
図 9.5 にこのパイプ処理の結果を示す。図 9.4 とほぼ同じ結果が得られていることがわかる（ファイル名の
。
直後にコロン「:」が出力されているのは，GREP の仕様である）
> grep 中国 [人語] *.trn | mawk32 -F"&" ’{print $1}’
A01F0132.trn:中国語の
A01M0077.trn:中国人は
A01M0097.trn:中国語においては
A01M0097.trn:標準中国語の
A01M0097.trn:中国語におきまして
A01M0097.trn:標準中国語の
A01M0097.trn:標準中国語の
A01M0097.trn:中国語において
A01M0104.trn:中国人男性留学生
A01M0258.trn:中国人留学生
A01M0258.trn:中国人留学生と
（以下省略）
図 9.5
パイプによる GREP と AWK スクリプトの実行結果
最後にいかにも AWK らしいスクリプトの例を示す。図 9.6 のスクリプトは SDB ファイルの第 10 フィー
ルドである短単位代表表記と，第 9 フィールドである代表形，そして第 12 フィールドである品詞を，半角コ
531
9.2 スクリプト言語
ロンを介して結合した文字列の生起頻度を計算する。要するに語彙頻度調査用プログラムであるが，AWK の
特徴である連想配列（ハッシュ）を利用しているために，きわめてコンパクトなプログラムになっている。変
数 word[] が連想配列であり，その添字として調査対象文字列 temp が用いられている。連想配列とは，この
ように任意の文字列を添字として利用することのできる配列である。
{
temp=$10":"$9":"$12
word[temp]++
}
END{
for (name in word) {print name, word[name]}
}
図 9.6
短単位の頻度を集計するスクリプト
図 9.6 のスクリプトをテキストファイル suw_count.awk として保存し，コマンドプロンプトで以下
=t"」はデータファイルがタブ区切りであることを指定するオプション，
のコマンドを実行する。「-F"Y
「-f suw_count.awk」は実行すべきスクリプトが保存されているファイルを指定している。「S01*.sdb」は
処理対象とするファイル群の指定であり，S01 で始まるファイル（模擬講演のテーマ 01 番）だけを集計してい
る。パイプ「|」で結合された「sort」は Windows の標準コマンドであり，名前どおりに文字列を整列する。
> mawk32 -F"Y
=t" -f suw_count.awk S01*.sdb | sort
処理結果の末尾を図 9.7 にしめす。文字列のコード順に整列されているので，日本語文字コード表の終わり
近くに位置する文字ではじまる語が示されている。数字が生起頻度である。
（省略）
辟易:ヘキエキ:名詞 1
迚も:トテモ:副詞 273
逞しい:タクマシイ:形容詞 6
鄙びる:ヒナビル:動詞 1
鉗子:カンシ:名詞 3
鏝:コテ:名詞 1
靄:モヤ:名詞 3
餞別:センベツ:名詞 1
饂飩:ウドン:名詞 2
饅頭:マンジュウ:名詞 5
饐え臭い:スエクサイ:形容詞 1
騙す:ダマス:動詞 4
鬘:カツラ:名詞 1
齧り付く:カジリツク:動詞 1
図 9.7
整列後に出力された短単位頻度表
スクリプト言語については，いくらでも解説すべきことがあるが，紙幅の関係でこれ以上の解説はひかえる。
スクリプト言語を用いると簡単にテキスト処理をおこなえること，またパイプを用いれば単純なコマンドやス
クリプトを組み合わせて複雑な処理を実施できることを理解していただきたい。
532
第9章
CSJ の検索
筆者は，CSJ の解析に必要なスクリプトはほとんど AWK で書いており，高度な正規表現を利用したり，
ネットワーク上のファイルを利用しなければならない場合だけ Ruby を使うことにしている（Perl と Ruby の
正規表現は GREP ないし AWK よりもはるかに強力である）
。ただし，これは世間一般に比べると偏った選択
である。一般には Perl のユーザーが圧倒的に多い。参考書類もそれだけ充実しているので，これからスクリプ
ト言語を何かひとつ学習しようという方には Perl を薦める。
9.3 RDB と SQL
CSJ について興味があるのは形態論情報だけということもあるだろう。そうであれば，CSJ の短単位，長単
位データ（4 章参照）は，タブ区切りのテキストファイルとして提供されているから，これを使い慣れた市販
のソフトで処理しようと考えるのは自然な発想である。
しかし，実際には，CSJ 全体を処理しようとすると，データ量が膨大なために，表計算ソフトでは処理が不
可能になる。マイクロソフト社の Excel は，あつかえるレコード（行）数が最大で 65,536 行までとなってい
る。短単位データの総数は 752 万語であるから，その 1% も読みこめない。
それではデータベース管理ソフトと銘打たれている同社の Access はどうか。Access の場合，扱えるデータ
数に上限はない。しかし，処理できる（外部からインポートできる）データの総量には限界があるようだ。筆
者の経験では，CSJ のうち形態論情報が手作業で処理された 100 万短単位のデータならば，問題なく Access
にインポートすることができ，検索にも問題は生じなかった。学会講演全体をインポートすることもできたし，
模擬講演全体でも大丈夫であった。しかし，学会講演と模擬講演の全体をインポートしようとすると失敗した。
Access のオンラインマニュアルによると，およそ 1GB がインポート可能なテキストデータの上限らしい。
結局，CSJ の形態論データ全体を難なくインポートすることができたのは，RDB（関係データベース）ソフ
トの MySQL と Oracle であった。筆者はこれら以外の RDB ソフトを試していないが，PostgreSQL でも問
題なく読みこめることが報告されている（4 章参照）。要するに業務レベルの RDB ならば処理できるわけであ
るから，おそらくマイクロソフト社の SQLServer も問題ないと思われる。
一旦，RDB へのインポートに成功すれば，RDB は強力な検索ツールになる。スクリプト言語による検索に
比べればはるかに高速な検索が可能であり，また，次節で説明するように検索条件の指定も一層容易である。
従来，RDB ソフトは大変高価であったが，MySQL と PostgreSQL はフリーソフトである。無料ではあって
も，RDB の基本機能は有償ソフトと比較して全く遜色がない。前者はより高速で安定しているが機能が少な
く，後者はより多機能であるが，安定性にはやや欠けるというのが世間の評判である。Oracle と SQLServer
は有償の商品であり，価格も安くないが，分析機能が豊富であり，開発元のサポートが受けられる。
RDB の検索条件は SQL という言語を用いて記述する。RDB の専用言語であるから，スクリプト言語にく
らべても一層簡便である。以下，SQL による検索の例をいくつか示すことにする。すべて MySQL の SQL 文
法に従っている（SQL には ANSI 標準仕様が定まっているが，実際には開発元ごとの方言が存在する）。
最初に示す SQL 文は短単位データを格納した sdb テーブルから長単位代表表記 (llemma) が「NHK」であ
るレコードだけを選択し，発音形 (pron) ごとの頻度を集計して，頻度の降順で表示する。
1 行目が表示する情報の指定，2 行目がテーブルの指定，3 行目がレコード選択条件の指定，4 行目が集計
キーの指定，5 行目が整列方法の指定である。SQL は自由書式なので「select pron, count(*) from sdb
where llemma=’ ＮＨＫ’ group by pron order by 2 desc;」のように全体を 1 行に続けてしまっても
533
9.3 RDB と SQL
よい。
この SQL 文の実行結果を図 9.8 に示す。レコードの選択条件として長単位の代表表記が「NHK」であるこ
とを指定しているから，単純語として用いられた「NHK」だけが選択される。先に 1 章の表 1.8 として示した
データはこのような SQL で集計したものである。出力中のタグ (W) については転記テキストに関する説明（2
章）参照。
select pron, count(*)
from sdb
where llemma=’ ＮＨＫ’
group by pron
order by 2 desc;
(W エヌエチケー;エヌエイチケー)
(W エネーチケー;エヌエイチケー)
(W エヌエッチケー;エヌエイチケー)
エヌエイチケー
(W エヌエチケ;エヌエイチケー)
(W エネーチケ;エヌエイチケー)
(W エ(? ヌ) エチケー;エヌエイチケー)
エ<H>ヌエイチケー
(W エヌエスケー;エヌエイチケー)
(W エヌチケー;エヌエイチケー)
(W エネーシケー;エヌエイチケー)
(W エネエチケー;エヌエイチケー)
(W エヌ(? エチ) ケー;エヌエイチケー)
図 9.8
95
19
9
4
3
2
2
1
1
1
1
1
1
上記 SQL 文の出力（単純語「NHK」の頻度）
SQL の利便性がスクリプト言語を圧倒するのは，複数のテーブルを関連づけた検索が必要となった場合であ
る。例えば CSJ の短単位を各話者が何語ずつ発音しているかを調べるとしよう。
この目的を達成するためには，各講演の話者を知る必要がある。短単位データには講演 ID（A01F0001 な
ど）が付与されており，講演のユニークな ID となっている。しかし，講演 ID は話者の ID ではない。CSJ に
は複数の講演をおこなっている話者が多数存在しているからである。
CSJ の話者 1,417 名には話者 ID が付与されているが，話者 ID は短単位データには含まれていない。これ
が記録されているのは，記録票データ (talk_data.dat) というテキストファイルである（詳しくは CSJ 付属
。記録票データには単独評定印象評定値をはじめとする多くの情報が
マニュアル data_attribute.pdf 参照）
講演ごとに記録されているが，各講演には講演 ID のほかに話者 ID も付与されている。
短単位データと記録票データ中の話者 ID とを関係づけるには両者が共有している講演 ID を利用する。す
なわち，短単位データの講演 ID と等しい講演 ID をもつ記録票データのレコードを参照すれば，そのレコード
に記録されている話者 ID がもとめる情報である。図 9.9 にそのような処理の模式図を示した（図中の ID はい
ずれも架空のものである）
。講演 A01M001 と S09M072 とは同一話者によっておこなわれている。
SQL には結合 (JOIN) という機能があり，このようなテーブル間の参照を比較的簡単に実現することができ
る。記録票データが talk_partial というテーブルにインポートされており，話者 ID は spkid というフィー
ルドに記録されているとしよう。以下の SQL 文は，講演 ID (talkid) をキーとして短単位データテーブル
(sdb) と記録票データテーブルを結合 (left join) したうえで，talk_partial の spkid を集計のキーとして，
534
第9章
⍴න૏䊂䊷䉺㩷
㩷
㩷
㩷
⸥㍳␿䊂䊷䉺㩷
⍴න૏㩷 㩷
㩷
㩷
⻠Ṷ 㪠㪛㩷 㩷
⹤⠪ 㪠㪛㩷
㪘㪇㪈㪤㪇㪇㪈㩷 䈖䈱㩷
㩷
㪘㪇㪈㪤㪇㪇㪈㩷 ⊒⴫㩷
㩷
㪘㪇㪈㪤㪇㪇㪈㩷 䈪㩷
㩷
㪘㪇㪈㪤㪇㪇㪈㩷 䈲㩷
㩷
㩿ਛ⇛㪀㩷
㩷
㪘㪇㪈㪤㪇㪇㪐㩷 㬍㬍㩷
㩷
㪘㪇㪈㪤㪇㪇㪐㩷 ᄢቇ㩷
㩷
㪘㪇㪈㪤㪇㪇㪐㩷 䈱㩷
㩷
㪘㪇㪈㪤㪇㪇㪐㩷 㬍㬍㬍㬍㩷
㩷 㩿ਛ⇛㪀㩷
㩷
㪪㪇㪐㪤㪇㪎㪉㩷 ੹ᣣ㩷
㩷
㪪㪇㪐㪤㪇㪎㪉㩷 䈲㩷
㩷
㪪㪇㪐㪤㪇㪎㪉㩷 ⑳㩷
㩷
㪪㪇㪐㪤㪇㪎㪉㩷 䈱㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㩷
㪘㪇㪈㪤㪇㪇㪈㩷 㩷
㪘㪇㪈㪤㪇㪇㪉㩷 㩷
㪘㪇㪈㪤㪇㪇㪌㩷 㩷
㪘㪇㪈㪤㪇㪇㪎㩷 㩷
㪘㪇㪈㪤㪇㪇㪐㩷 㩷
㪘㪇㪈㪤㪇㪈㪈㩷 㩷
㪘㪇㪈㪤㪇㪈㪉㩷 㩷
㩿ਛ⇛㪀㩷
㪪㪇㪈㪤㪇㪌㪐㩷 㩷
㪪㪇㪈㪤㪇㪍㪇㩷 㩷
㪪㪇㪈㪤㪇㪍㪏㩷 㩷
㪪㪇㪈㪤㪇㪍㪐㩷 㩷
㪪㪇㪈㪤㪇㪎㪉㩷 㩷
㪪㪇㪈㪤㪇㪎㪊㩷 㩷
㪌㪍㩷
㪌㪎㩷
㪍㪉㩷
㪈㪉㪊㩷
㪈㪉㪐㩷
㪈㪋㪌㩷
㪈㪋㪍㩷
⻠Ṷ 㪠㪛㩷
㩷
㩷
CSJ の検索
㪌㪏㩷
㪈㪉㪌㪈㩷
㪉㪊㪋㩷
㪋㪌㪉㩷
㪌㪍㩷
㪋㪌㪍㩷
⚿วಣℂ
⻠Ṷ 㪠㪛㩷
㪘㪇㪈㪤㪇㪇㪈㩷
㪘㪇㪈㪤㪇㪇㪈㩷
㪘㪇㪈㪤㪇㪇㪈㩷
㪘㪇㪈㪤㪇㪇㪈㩷
㪘㪇㪈㪤㪇㪇㪐㩷
㪘㪇㪈㪤㪇㪇㪐㩷
㪘㪇㪈㪤㪇㪇㪐㩷
㪘㪇㪈㪤㪇㪇㪐㩷
㪪㪇㪈㪤㪇㪇㪎㩷
㪪㪇㪈㪤㪇㪇㪎㩷
㪪㪇㪈㪤㪇㪇㪎㩷
㪪㪇㪈㪤㪇㪇㪎㩷
図 9.9
⍴න૏㩷 ⹤⠪ 㪠㪛㩷
䈖䈱㩷
⊒⴫㩷
䈪㩷
䈲㩷
㩿ਛ⇛㪀㩷
㬍㬍㩷
ᄢቇ㩷
䈱㩷
㬍㬍㬍㩷
㩿ਛ⇛㪀㩷
੹ᣣ㩷
䈲㩷
⑳㩷
䈱㩷
㪌㪍㩷
㪌㪍㩷
㪌㪍㩷
㪌㪍㩷
㪈㪉㪐㩷
㪈㪉㪐㩷
㪈㪉㪐㩷
㪈㪉㪐㩷
㪌㪍㩷
㪌㪍㩷
㪌㪍㩷
㪌㪍㩷
講演 ID をキーとした結合処理の模式図
短単位数を集計する。その出力の冒頭部分を図 9.10 に示す。左側の数字が spkid，右側がその話者の発した
短単位の総数である。
select talk_partial.spkid, count(sdb.lemma)
from sdb left join talk_partial
on (sdb.talkid = talk_partial.talkid)
group by talk_partial.spkid
order by 2 desc;
9.3 RDB と SQL
535
spkid
610
8
373
631
790
1391
19
1107
1268
1185
563
1083
count(xsdb_var.lemma)
63118
55686
40351
33270
28188
27821
26359
25839
25512
25342
24892
24073
（以下省略）
図 9.10
上記 SQL 文の出力（話者別総短単位数の降順表示）
最後に CSJ を用いた言語変異研究で多用する印象評定値を利用した集計例を示す。言語現象としては「私」
における「アタクシ」と「アタシ」の変異をとりあげる。問題を単純化するために「ワタシ」「ワタクシ」や
種々のタグを含んだ変異形はとりあげない。印象評定値は，CSJ の記録票データに記録されているので，前例
と同様 RDB の talk_partial テーブルにインポートされているものとする。
以下の SQL 文では結合するふたつのテーブルに「t1」「t2」という別名 (alias) をつけている。別名の宣言
「as t1」と「as t2」
）。別名を用いるのは，プログラムの書き換えが楽になるか
は 2 行目でおこなっている（
らである。例えば，この SQL に含まれる短単位データテーブル「sdb」を別のテーブルに変更する場合，2 行
目の「sdb」を一回書き換えれば済む。
4 行目から 6 行目にかけてはレコードの選択条件が記述されており，全体でひとつの where 句をなしてい
る。4 行目は単純語としての「私」を選択するための指定，5 行目は「アタクシ」ないし「アタシ」だけを選択
するための指定である。6 行目は学会講演と模擬講演だけを対象とするために，講演 ID の左端 1 バイトを切
り出して，それが「A」ないし「S」であるものだけを選択するよう指定している。SQL ではこのように文字列
関数なども使える。最後に 7 行目では印象評定値（自発性評定値）について欠損値を意味する「-1」と「999」
を除外するための指定である。自発性評定値は「1」が自発性最低，「5」が最高を意味する。
select t2.spont, t1.pron, count(t1.pron)
from sdb as t1 left join talk_partial as t2
on (t1.talkid=t2.talkid)
where t1.llemma=’ 私’
and (t1.pron=’ アタクシ’ or t1.pron=’ アタシ’)
and (left(t1.talkid,1)=’S’ or left(t1.talkid,1)=’A’)
and (t2.spont>0 and t2.spont<6)
group by t2.spont, t1.pron;
この SQL の実行結果を図 9.11 に示す。自発性の高低にかかわらず，
「アタクシ」よりも「アタシ」の頻度が
高いが，両者の比率に注目すると，自発性評定値が低いほど「アタクシ」の比率が高いことがわかる（図 9.12
参照）
。
ところで MySQL を含む多くの RDB ソフトにはグラフ作成機能がないので，図 9.12 は Excel を利用して
作成した。このような場合には検索結果をテキストファイルに出力して，それを Excel にインポートする。こ
536
第9章
CSJ の検索
のような操作も基本的にはすべて SQL で記述する。
RDB ソフトの多くは GUI をそなえていないが，最近では MySQL などを対象にサードパーティー製の
GUI が市販されている（例えば http://www.navicat.jp/）。これを利用すれば多くの操作がマウスでおこ
なえるようになり，検索結果を Excel シートへ copy and paste することも可能になる。
上記とは別に Excel や Access 自体を RDB の GUI として利用する方法もある。この方法を利用すると，
Excel から RDB に対して SQL を発行し，処理結果をまた Excel で受けとることができる。
この方法を利用するためには ODBC ドライバと呼ばれるツールが必要であるが，主要な RDB ソフトの
ODBC ドライバは無償で公開されていることが多い。
spont 1
1
2
2
3
3
4
4
5
5
pron アタクシ
アタシ
アタクシ
アタシ
アタクシ
アタシ
アタクシ
アタシ
アタクシ
アタシ
count(t1.pron) 10
15
18
35
31
154
53
437
76
768
図 9.11
上記 SQL 文の出力（「アタクシ」と「アタシ」の自発性評定値ごとの集計）
㪌
⥄⊒
୯㪋
ቯ
⹏
ᕈ㪊
㪉
㪈
㪇㩼
㪉㪇㩼
㪋㪇㩼
䉝䉺䉪䉲
図 9.12
㪍㪇㩼
㪏㪇㩼
㪈㪇㪇㩼
䉝䉺䉲
自発性評定値と「アタクシ」および「アタシ」の比率
SQL についても解説すべきことはいくらでもあるが，やはり紙幅の関係でこれ以上の解説はひかえる。
RDB は 1970 年代に開発された技術であり，ながい利用実績があるので，比較的安心して利用できる。先に指
摘したように細部に方言が多いのが難点だが，解説書も数多く出版されているのでその点が学習上大きな困難
となることはない。
9.4 XSLT プロセッサ
537
9.4 XSLT プロセッサ
先に 1 章で XSLT という XML 文書処理用言語を紹介した。この言語で書かれたスクリプトを実行するた
めには，XSLT の処理系が必要である。従来，XSLT の処理系として世界中で広く利用されているものに，
Apache Project の一部として提供されている Xalan がある (http://xml.apache.org/xalan-j/)。
し か し ，CSJ の XML 文 書 の 処 理 に か ぎ っ て は ，Xalan で は な く xsltproc と い う 処 理 系 を 薦 め る
(http://xmlsoft.org/XSLT/xsltproc2.html)。XSLT 言語で検索条件を指定するには XPath 式という規
格を利用するが，XPath 規格が許容している様々な条件指定の一部（preceding と following）を利用した
場合に，Xalan では極端に速度が低下するのに対して，xsltproc ではそのような低下が生じないことがその理
由である。preceding と following は 1 章図 1.6 のスクリプトでも利用されているように，CSJ の検索には
欠かせない条件指定である。
XSLT 処理系は最近では Windows に標準搭載されており，それをコマンドプロンプトから利用するた
めのツール (msxsl.exe) もマイクロソフト社のウェブサイトからダウンロードできるようになっている
(http://www.microsoft.com/downloads/)。しかし筆者はこの処理系を試した経験がないので評言をひか
える。世評ではかなり高性能な処理系であるらしい。
図 9.13 に 1 章図 1.6 のスクリプトを再掲する。1 章に述べたとおり「節境界ラベルを保有するすべての短単
位を検索し，講演 ID，転記基本単位 ID，先行する四つの短単位代表形，当該短単位の代表形，後続する一つ
の短単位代表形とともに，当該短単位に付与された節境界ラベル，当該短単位の時間区間内に存在する韻律情
報中のトーンラベルと BI ラベルを出力する」スクリプトである。
最初の 3 行は XML および XSLT 規格を宣言し，出力コードとしてシフト JIS を指定している。空白をと
ばして続く 8 行が検索条件の指定であり，「self::SUW[@ClauseBoundaryLabel]」の部分が XPath 式であ
る。「<!-- output starts here -->」以下は出力する要素と書式の指定である。
xsltproc を利用できる環境で XSLT スクリプトを用いて XML 文書全体を処理するためには，Windows の
バッチファイル（Linux ならばシェルスクリプト）を利用する。バッチ処理のために図 9.13 のスクリプトを
xsltsample.xsl という名前で保存する。次に以下のテキストファイルを作成して，testxslt1.bat という
名前で保存する。
@echo off
for %%I in (%1) do xsltproc xsltsample.xsl %%I
処理対象の XML 文書を保存したディレクトリに xsltsample.xsl と xslt1.bat をコピーし，コマンドプ
ロンプトで以下のコマンドを実行すると，ディレクトリ内のすべての XML 文書が xsltsample.xsl によっ
て順次処理されてゆく。このスクリプトの場合，全 XML 文書を処理対象とすることができるし，韻律情報が
重要ならばコアに含まれる XML 文書だけを対象としてもよい。出力に対してはリダイレクトやパイプ処理が
可能である。図 9.14 に処理結果の一部を示す。
> testxslt1 *.xml
538
第9章
!""####$
"%%%"&'"(
)
*!*"
!))"
)!! +!) "",-"
"!)
!)),-
+),-./0)*1*)
')23
)+!) ))2"
"
+)
"!)
4++*!*)
++
!)))2
"
4++ ()5 ⷐ⚛䈱ዻᕈ ()56 䈱⴫␜ ++
)*+ )
()5"/()56"
7"
4++ 8, ⷐ⚛䈱ዻᕈ 8,6 䈱⴫␜ ++
)*+ )
+
+8,"/8,6"
7"
4++ ',- ⷐ⚛䈱ዻᕈ ',-6 䈱⴫␜ ++
)*+ )
+
+',-"/',-6"
7"
4++ ,- ⷐ⚛䈱ዻᕈ ,-6 䈱⴫␜ ++
)*+ )
+
+,-"/,-6"
7"
4++ ,- ⷐ⚛䈱ዻᕈ ,-') 䈱⴫␜䋨⋥೨䋴ⷐ⚛⥄り⋥ᓟ䋱ⷐ⚛䋩 ++
)*+ !
,-.93"/,-')"
7"
)*+ !
,-.$3"/,-')"
7"
)*+ !
,-.:3"/,-')"
7"
)*+ !
,-.3"/,-')"
7"
)*+ ,-"/,-')"
7"
)*+ #,-.3"/,-')"
7"
4++ ,- ⷐ⚛䈱ዻᕈ 0)*1*)
')2 䈱⴫␜ ++
)*+ )
+
+,-"/0)*1*)
')2"
7"
4++&(1')2( ⷐ⚛䈱ዻᕈ ;<䈱⴫␜ ++
)*+ )&(1')2(";<"
7"
4++&(1')21
)5 ⷐ⚛䈱ዻᕈ ;<䈱⴫␜ ++
)*+ )&(1')21
)5";<"
"!)
" 図 9.13 XSLT スクリプト（1 章図 1.6 を再掲）
CSJ の検索
9.5 検索に関わる注意
539
A01F0132,0237,25,1, と, 考える, て, 居る, ます, えー,[文末],A,3
A01F0132,0240,6,1, 今後, の, 課題, です, が, あの,/並列節ガ/,L%,3
A01F0132,0240,16,2, 実験, 段階, です, の, だ, えー,<理由節ノデ>,pH,3
A01F0132,0241,14,1, を,, あー, 使う, て, 更に,<テ節>,H%,2+b
A01F0132,0245,7,1, 進める, て, 行く, 予定, です, 以上,[文末],L%,3
A01F0132,0246,2,1, 行く, 予定, です, 以上, です,,[文末],L%,1
A01F0143,0001,1,4,, 御, 早い, 御座る, ます, あの,[文末],A,3
A01F0143,0001,6,1, 義塾, 大学, の, ××, です, えーと,[文末],A,3
A01F0143,0003,11,3, ×, ××, に, 就く, て, あの,<テ節>,H%,2+bp
A01F0143,0003,14,1, て, あの, 発表, 致す, ます, あー,[文末],L%,3
A01F0143,0006,1,3, 一寸, 此れ, 済む, ます, ず, あー,[文末],A,3
図 9.14
図 9.13 に示した XSLT スクリプトの実行結果
9.5 検索に関わる注意
以上，筆者が実際に利用している CSJ の検索手法を手短に紹介した。少なくとも現在のところ，CSJ の検
索手法として万能のものはなく，各手法の特徴を理解したうえで目的に応じて使いわけるのがコツである。
しかし，それ以上に重要なのがデータそのものに対する正確な理解である。これは当然すぎるほど当然のこ
となのだが，CSJ 規模のコーパスになると，理解すべき事項もまた膨大なものになる。
以下では，CSJ を検索するうえでの落とし穴にどのようなものがあるかを読者に体感していただくために，
筆者が CSJ を解析する過程で実際に経験してきた困難を紹介する。筆者はこの 1 年ばかり語形のゆれの研究
に従事してきており，形態論情報を多用してきた。そのため以下の諸例も形態論情報に偏った内容となってい
ることをお断りしておく。
9.5.1 代表表記
形態論情報を使って「語」を検索するときは，その語をどう指定すればよいかに注意する必要がある。CSJ
では代表表記と代表形の間に一対多の対応を許容しているから，語をその代表表記だけで指定できると考える
のは明らかに間違いである。例えば「日」という代表表記には「カ」
「ジツ」
「ニチ」
「ヒ」という 4 種類の代表
形が対応する。これらを同じ語とみなす立場もありうるが，音形が異なれば別の語と認定するという立場があ
りうるし，それが普通の立場だろう。これらの語形を区別して検索したり集計したりするためには，代表表記
と代表形の両方を指定する必要がある。
なお CSJ の代表表記では意味的に全く関係のない語が同一の代表表記を共有していることがある。例えば
「辛い」は「ツライ」と「カライ」に対応し，「甘い」は「アマイ」と「ウマイ」に対応する。
CSJ の代表表記のなかには普通といえない表記を採用しているものがあるので注意を要する。先に図 9.7 と
して示した例には「迚も」
「逞しい」
「鄙びる」
「鏝」
「饂飩」
「饐え臭い」のような，現代語としては頻度がきわ
めて低いと思われる表記が多数含まれていた。
540
第9章
CSJ の検索
9.5.2 短単位
日本語を斉一的な語に分割することはなかなか難しい。語彙調査ではこれが大問題となるので，従来から
種々の調査用単位が提案されてきた。CSJ が採用した短単位，長単位もそのような単位である。
これらの単位では語を操作的に規定するので（3 章参照）
，ときに直感に反するような語が得られることがあ
る。特に外来語および外来語を含む混種語においても，2 最小単位＝ 1 短単位という原則をまもったために，
意外な結果を多く生じている。例えば「ピンク」に関連する「ピンク色」
「ピンク寄り」
「ピンクレディー」
「ピ
ンクノイズ」「ピンクヘルメット」「ピンクダイヤモンド」などはすべて 1 短単位である。短単位＝単純語，長
単位＝複合語と単純に理解していると，解析条件の指定に齟齬をきたすことがある。
数詞にも注意が必要で，例えば「二」
「二十」
「二百」
「二千」は 1 短単位だが，
「二十一」
「二十二」…，
「二百
一」「二百二」…は 2 短単位（1 長単位）である。
こうした例は少なからず存在するので，短単位に慣れるまでは，本書の関連部分を熟読するとともに，形態
論データ自体をよく眺めながら検索条件を考える必要がある。こういう目的のためには先に紹介した RDB が
有効である。
9.5.3 活用形
活用語には活用の種類と活用形の情報が付与されているが（3 章参照）
，活用形の分類が，手動で形態素解析
したファイル（約 100 万語）と自動形態素解析したファイル（約 650 万語）とで異なっている。
自動解析分では，形容詞に「連用形」に対する「連用形 1」「連用形 2」の区別があり，同じく助動詞に「未
「未然形 2」と「連用形 1」
「連用形 2」の区別が，接尾辞に「未然形 1」
「未然形 2」
「未然形 3」と「連
然形 1」
用形 1」
「連用形 2」の区別が，そして動詞に「未然形 1」
「未然形 2」
「未然形 3」
「未然形 4」と「連用形 1」
「連
用形 2」の区別が導入されている。これらが何を表しているかは 4 章参照。
スクリプト言語や RDB で活用形全般を検索したいときに，ただ「連用形」という文字列を指定すると，自
動解析分については必要な情報の一部が欠落する。これを避けるためには，正規表現を用いて条件を指定する
か，あらかじめ自動解析分の分類を手動解析分にあわせておくなどの工夫が必要である。
9.5.4 形態論情報の誤解析
CSJ の規模のコーパスになると，関係者の努力にもかかわらず，転記や研究用付加情報中に種々のエラーが
生じることは避けがたい。そのうち量的にもっとも顕著なのは自動解析された形態論情報における誤解析であ
る。短単位の自動解析精度を 98% と仮定すると，自動解析された短単位は約 650 万語であるから，CSJ には
およそ 13 万件の誤解析が含まれているはずである。
誤解析はいくつかに類型化することができるが，重要な類型は，短単位境界を切り誤っているかいないかで
ある。境界を切り誤っていない誤解析の大部分は，読み（代表形）の付与に失敗したものである。
「ヒラケル」
と読むべき「開ける」を「アケル」と読んだりする類である。これらの誤りはその語の属性だけを修正すれば
よいから修正が容易である。
一方短単位境界を切り誤っていると，その影響は隣接する短単位にも及ぶので，修正は困難になる。
「どこで
地震が起こんのか」における動詞の一部「コン」を連体詞「この」と分析したり，
「小麦粉なんですが」の「ナ
9.6 まとめ
541
ン」を助詞の「など」と分析したりするようなケースである。
9.5.5 トーンラベルの時間情報
X-JToBI ラベル位置は，音声学的なイベントの生起時刻であり，音韻論的な所属を示すものではない。例え
ば「あなた」という語のアクセント位置は音韻論的には 2 モーラ目（すなわち「ナ」
）であるが，パラ言語的意
味がくわわると，ピッチのピークが「タ」の時間区分内にずれこむことがある。その場合，X-JToBI ではアク
セントラベル「A」はピーク時刻に付与されている。
一方，XML 文書についての解説で説明されているように（7 章参照），CSJ の韻律情報（X-JToBI ラベル）
とテキスト情報とは，分節音情報のもつ時間情報を介してリンクされている。
その結果，XML の階層構造を利用して検索すると，上の例では，アクセントをもつモーラは「タ」であっ
て「ナ」ではなくなることに注意が必要である。先に 1 章の図 1.6 として示した XSLT スクリプトによる検索
でも，トーンラベルは，その生起時刻を持続時間中に含む分節音を支配するモーラに所属するものとして検索
される。
この問題が生じるのは X-JToBI ラベルのうち特にトーン層のラベルである。もしユーザーがアクセントの
音韻論的所属に興味があるのであれば，トーン層のアクセントラベルを検索するのではなく，単語層に含まれ
るアクセント記号「’」を検索すべきである。
なお X-JToBI にはラベリングの不安定性を示す AYOR ラベルがある（7 章参照）。このラベル区間に付与
された韻律ラベルの処理には当然注意が必要である。
9.6 まとめ
本章では筆者の体験に基づいて CSJ の検索手法と検索にあたって留意すべき事項について述べた。本書全
体の主題からすればやや異質な章となったが，本章冒頭で述べたように，この種の情報に対するユーザーの強
い要望があると判断した。
なお，本章ではとりあげなかったが，CSJ の形態論情報は国立国語研究所の山口昌也氏が開発した言語研究
用全文検索システム「ひまわり」を用いて検索することもできる。「ひまわり」による検索は RDB と SQL に
よる検索に比べると検索条件指定の自由度が低いが，その反面，GUI を用いて検索条件を容易に指定できるこ
と，また（全文検索をおこなうかぎり）短単位等に関する知識を必要としないことなどの利点がある。
「ひまわ
り」についての詳しい情報は，http://www.kokken.go.jp/lrc/ を参照されたい*1 。
情報処理技術の常として本章の内容はすぐに陳腐化するものと予想される。そのため本章では一部に URL
を掲載したのを除いて，あえて参考文献の類を掲載しなかった。本章で紹介した検索技術については多くの教
科書類が出版されているし，インターネット上にも有益な情報が掲載されているので，最新の情報が容易に入
手できる。
また以下の URL には CSJ の開発メンバーでもある菊池英明氏による「CSJ の利用ガイド」が掲載されてい
る。本章よりも丁寧な解説となっているので，本章を読み終えて，実際に CSJ の検索環境を構築しようとする
読者には是非一読を薦める。http://www.f.waseda.jp/kikuchi/tips/csj_use.html
*1
「全文検索システム『ひまわり』」→「『日本語話し言葉コーパス』を『ひまわり』で利用する方法」とリンクをたどることで，「ひ
まわり」での CSJ 利用に関する詳細な情報を得ることができる。