# HaoriBricks3:
日本語文を合成するためのドメイン特化言語

佐藤 理史 $^{\dagger}$

本論文では，日本語文を合成するためのドメイン特化言語 HaoriBricks3 (HB3) につ いて述べる。HB3では, ブリックコードと呼ぶ Rubyコードで, どのような日本語文を合成するかを記述する。このブリックコードを評価すると，ブリック構造と呼 ばれる Rubyオブジェクトが生成され，さらに，これに表層文字列化メソッド to_ss を適用すると，表層文字列が生成される。本論文では, HB3 の設計思想, 実装のた めの工夫について説明し, HB3 で何ができるのかを示す.

キーワード：文合成，ドメイン特化言語，日本語文法，テキスト生成
## HaoriBricks3: A Domain-Specific Language for Japanese Sentence Composition

\author{
SAtoshi SAtO ${ }^{\dagger}$
}

This paper describes a domain-specific language, HaoriBricks3 (HB3), for writing programs that compose Japanese sentences. In HB3, we write a Ruby code called brick code, which instructs how to compose a sentence. The evaluation of a brick code produces the Ruby object called brick structure, from which the surface sentence string is generated by the method to_ss. This paper presents the design philosophy and implementational innovations of HB3, as well as demonstrates the applications of HB3.

Key Words: Sentence Composition, Domain-specific Language, Japanese Grammar, Text Generation

## 1 はじめに

プログラムによる小説自動制作の実現を目指す過程 (佐藤 2016) で，私が直面した問題の一つは，次のような問題である。

日本語の文を合成するために，どのようなソフトウェアシステムを用意すればよいか.小説はテキストであり，テキストは文の並びである。ゆえに，文を作れなければ，小説は作


れない，小説には，ありとあらゆる文が出現しうる。任意の日本語文を作ることができるようなソフトウェアシステムを実現できるだろうか. もし，それが可能ならば，どのようなシステムとして具現化されうるだろうか.

本論文では，そのような問題意識の下で開発してきた羽織シリーズ（～$\rightarrow$ 付録 B）の最新版である HaoriBricks3 (HB3)の概要を示す。私は, HB3 を旦本語の文を合成するためのドメイン特化言語 (domain-specific langauge)」と位置づける，HB3では，ブリックコード (brick code, BC) と呼ぶ記述形式で，どのような日本語文を合成するかを記述する。そして，記述したブリックコードを実行（評価）すると，表層文字列が得られる。ブリックコードは，あくまでも文を合成するためのコードであり，文の意味表現ではない.

図 1 に, ブリックコードから表層文字列を生成する過程の概略を示す. ブリックコードは Ruby コードそのものであり，これをRubyコードとして評価すると，ブリック構造 (brick structure， BS）と呼ぶ内部構造（Ruby オブジェクト）が生成される。このブリック構造に，表層文字列を生成するためのメソッド to_ss を適用すると，羽織構造 (Haori structure, HS), および，境界・ ユニット列 (boundary-unit sequence, BUS) という 2 つのデータ構造を経由して, 最終的に表層文字列が生成される。

本論文では，HB3 の設計思想，および，実現・実装のための工夫について説明し，HB3で何ができるのかを示す.

## 2 設計思想

HB3 で実現したかったことを一言で言うならば，次のようになる.

日本語文を合成するコードを，できるだけ簡潔に書けるようにしたい

研究の最終ゴールは，プログラムによる小説の自動制作である，小説は，短編小説といえども，長い，そのため，短編小説を合成するプログラムでは，文を合成するコードをたくさん書かなければならない，それゆえ，コードが簡潔に書け，かつ，共通部分をサブルーチン化できることが非常に重要になる.

HB3 をドメイン特化言語にせざるを得なかったのは，次のような現状認識による．

あらゆる文の意味を表現しうるような人工的な内部表現（意味表現）は，現時点では設計できない.

羽織シリーズの最初の版 (佐藤 2015; 緒方, 佐藤, 松崎 2015) を作る際には, 英語の surface realizer, 特に RealPro (CoGenTex Inc. 2000)を参考にした. 伝統的なテキスト生成システムは,伝えるべき内容を表す意味表現を入力として, いくつかのモジュールをパイプラインにつなげ,表層文字列を出力するという構成をとる (Reiter and Dale 2000). このパイプラインの最後に配置される surface realizer は，文の意味表現を表層文字列に変換するモジュールとして位置づけ

図 1 ブリックコードからの表層文字列生成

られる。しかし，あらゆる文が想定されうる小説の自動制作を最終ゴールとする以上，実現すベきソフトウェアの機能を「意味表現を表層文字列に変換する」と規定するのでは，ゴールには到達しえないと考えた。

その代わりに採用したのは，「部品（語）から文を合成する」アプローチである。このアプローチ下で日本語文の表層文字列を合成するために必要なことは，次の 2 点に集約される.

(1) 語をどのような順番に並べるかを決定する.

（2）語が活用する場合は，その活用形を適切に決定する.

よく, 日本語は語の順序が比較的自由であると言われる. しかし, この説明は正確ではない.順序の交換が可能なのは，語ではなく文節である，そして，文節の順序を交換するとニュアンスが変わる，たとえば，「そのワインを私は飲まなかった」と綴りたいとき，ソフトウェアが勝手に「私はそのワインを飲まなかった」のように文節を入れ替えてしまうのでは困る。あえて 「そのワインを」を文頭に置くことによって得られる効果が台無しになる。そのため, 語 (文節) の並べ方はコードで指定することとする。

文中で活用形がどのような情報を担っているかを考えると, 次の 2 種類があることに気づく.

(1) 次の語に接続するために要請されている.

たとえば，子音動詞型活用（五段活用）の動詞の直後に「ない」が接続する場合は，その動詞は「未然形」を取らなければならない。この「未然形」は，「ない」に接続するために要請されているだけで, それ以上の意味はない.

(2) 特定の文法的機能を担う.

たとえば，命令形は「命令」という意図（モダリティ）を表す.

これらのうち, 後者は, 書き手の意志の表明であるため, コードで指定するのが妥当である.一方，前者は，後続語の文法的制約によって必然的に要請されるので，自動的に決定できるはずである。そのため，前者のみ自動化することとする.

このような考え方に基づき，日本語文を合成するソフトウェアシステムを，次のような機能を持つドメイン特化言語として設計・実装する.

・コードで記述できるようにするもの

（1）文を合成する部品

(2) 部品の順序

（3）文法的機能を担う活用形
- 自動的に決定するもの

(1) 直後の語で定まる活用形

## 3 羽織文法と羽織構造

図 1 に示したブリックコードから表層文字列を生成する過程を，次のように，2 段階に大きく分ける.

(1) ブリックコードから羽織構造まで

(2)羽織構造から表層文字列まで

順番は前後するが，本章では，後者にかかわる 6 つの新機軸を説明する。前者にかかわる 5 つの新機軸は，次章で説明する。

## 3.1 羽織文法

文生成に必要な文法事項を整理・再構成し, 羽織文法 (Haori Grammar) を定義した. 羽織文法は，HB3の内部にプログラムとして（つまり，実行可能な形で）定義されている.

日本語の文法体系は, おおよそ, 次の要素から構成されるのが標準的であろう.

(1) 語の分類体系 (いわゆる品詞体系)

(2) 活用語の活用体系

(3) 構文構造の定義（文の背後にどんな構造を仮定するか）

（4）文法的機能（テンス・アスペクト・モダリティなど）とその表現形式羽織文法は，次のような特徴を持った文法である.

(1) 語の分類では, 機能語と内容語の区別, 活用する語と活用しない語の区別を重要視する.

（2）詳細な活用体系（活用型と活用形）を提供する。活用型は, 文法の中核的要素のひとつである。これに加えて，接続型 $(\rightarrow § 3.4)$ を定義する。

（3）表層文の背後に，羽織構造 $(\rightarrow \oint 3.2)$ を仮定する.

（4）文法的機能のほとんどを，機能語の働きによるものと考える機能語中心主義を採用する.

(5) 句読点や括弧などの記号を語とは明確に区別し，境界記号 $(\rightarrow \oint 3.3)$ とみなす.

4 番目の特徴は, 少し補足が必要であろう，たとえば，日本語には，「継続」を表す「テいる」 や「つつある」という形式がある。通常の文法では，アスぺクト「継続」という抽象的な文法機能を考え，その機能を担う表現形式を整理する。これに対して，羽織文法では，そのような抽象的な文法機能を前提せずに，機能語「テいる」，「つつある」の振る舞いだけ規定する.

羽織文法では，機能語が文法の中核的要素を占める。そのため, 羽織文法は, 取り扱うすべての機能語を列挙し，その振る舞いを規定する。 さらに, 取り扱う従属節の節末形式もすべて列挙する $(\rightarrow \S 5.1)$.

このような特徴を持った羽織文法の基本思想は, 次のように集約される.

日本語の文は，機能語によって組み立てられており，文法（文の成り立ちとその規則性）を明らかにすることは，機能語を列挙し，その振る舞いを記述することである.

なお，羽織文法に関する補足を付録 A に示した。

## 3.2 羽織構造

羽織文法では，表層文の背後に羽織構造を仮定する。羽織構造は木構造の形式をとり，それぞれのノードは属性値の集合を持つ。終端ノードは語を表し，非終端ノードは構造を表す。羽織構造の終端ノードを左から右へと並べれば，表層化した際の語の並びとなる。すなわち，羽織構造は語順の情報を完全に有している。

非終端ノードのタイプは，次の 4 種類のいずれかである.

(1) binary_r（2 分岐右タイプ） - 2 つの子ノードを持つ. 右の子がその構造を成立させる要素.

（2） binary_l（2 分岐左タイプ） - 2 つの子ノードを持つ. 左の子がその構造を成立させる要素.

(3) predicate (述語タイプ) - 1 つ以上子ノードを持つ. 最後の要素が述語要素.

(4) sequence (列タイプ）- 2 つ以上の子ノードを持つ. それぞれの子は同等の扱い.

文中に現れる主要な構文構造は, 次の 4 種類である。括弧内は構造のタイプを表す.

(1) 述語構造 (predicate)

(2) 修飾構造 (binary_l)

(3) (並) 列構造 (sequence)

(4) 提題構造 (binary_l)

この他に，機能語を付加する次のような構造がある。これらはすべて, binary rである.

(1) 助詞構造 (binary_r)

(2) 判定詞構造 (binary_r)

(3) 助動詞構造 (binary_r)

(4) 述語接尾辞構造 (binary_r) 一複雑な述語を作る接尾辞を付加する構造

羽織構造は依存構造ではない. どちらかというと句構造に近いが，句構造でもない. 図 1 に示した羽織構造のトップレベルは「述語接尾辞構造」である。これは, 構造の最上位（つまり，文の末尾）に「丁寧接尾辞ます」が付加されていることを表現しているだけで，文全体が「述語接尾辞構造」であることを意味しているわけではない.

## 3.3 境界記号の導入

句読点や括弧などの記号は, 実際の言語処理ではやっかいな存在である ${ }^{1}$. 形態素解析では,句読点や括弧などは形態素と同等に扱われるのが普通であるが, それらは明らかに「形態素」で


はない，句点は文の区切り記号であるし，読点は文中の比較的大きな切れを表す区切り記号である。そしてそれらは，文字列として書く場合にのみ，目に見える形で実体化される。

英語では，語と語の間にホワイトスペースを置く。これと同じように，日本語の語と語の間にも境界という実体が存在すると考える。ただし，多くの境界は空文字列（長さ０の文字列） として実体化されるため, 見えない. これに対して，句読点や括弧は目に見える境界，つまり，文字列として実体化される境界記号と考える。

境界記号は文字列化する際に実体化されるので, 羽織構造の構造部分には反映せず，ノードの属性として保持する。羽織構造のすべてのノードは, 左境界と右境界という 2 の属性を持ち，それらの属性に境界記号を格納する。たとえば，図 1 の羽織構造では，最上位の「述語接尾辞構造」ノードの右境界に句点が格納されている。 そのため, 表層化の過程で「述語接尾辞構造」の右，すなわち「丁寧接尾辞ます」の直後の境界において実体化される.

後に述べるように，境界記号には，透過性が定義される。

## 3.4 接続型の導入

接続型とは，機能語が，直前の語の活用型・活用形をどのように制約するかを記述するために導入した制約類型である。この接続型を用いて, 直前の語の活用形の自動決定を実現する. たとえば,「丁寧接尾辞ます」の接続型は「接尾辞ます接続」である。この接続型は，直前の語の活用型・活用形を次のように制約する.

（1） 活用型が「子音動詞型ラ行イ」であれば，「基本連用形 2$\rfloor$ と「基本連用形」を取りうる.

（2）活用型がそれ以外の「動詞型」であれば，「基本連用形」を取る.

（3）それ以外の活用型，および，活用しない語には接続しない.

この定義に従い，「ます」の直前の語の活用形は，次のように設定される。

b. 書く子音動詞型力行 + ます $\rightarrow$ 書き基本連用形ます

c. 長いイ形容詞型アウオ段 + ます $\rightarrow$ （接続できない）

なお，複数の活用形を取りうる場合で，デフォールト以外の活用形を選択したい場合は，活用形を明示的に記述する。「いらっしゃる」の活用形を明示的に「基本連用形」と指定すれば，「いらっしゃり基本連用形ます」という形式も生成できる.

接続型を定義する必要がある語は, 述語に付加される機能語, すなわち, 助動詞, 述語接尾辞, 接続助詞, 終助詞などであるが, 名詞の一部（節末形式に含まれる機能名詞）に対しても定義する必要がある．たとえば，「以来」は，直前の動詞にテ形を要求する.

接続型は, 直前の語に適切な活用型・活用形を要求するが, 直前の語との間に境界記号が存在する場合, その要求を透過するか否かは, 境界記号に定義される透過性の定義に従う。ここ

で，「透過する」とはその要求を順送りして伝えることを意味し，「透過しない」とはその要求をそこで棄却することを意味する，Basic パッケージ $(\rightarrow \$ 4.6)$ では，句読点は，接続要求を透過しないと定義している。括弧の類は，透過するものとしないものの両方を定義している.

$[2]$ a. 開括弧 + 書く＋閉括弧透過しない + ます $\rightarrow$ （書く）ます

b. 透過開括弧 + 書く＋透過閉括弧透過する + ます $\rightarrow$ （書き）ます

この透過性を，いわゆる取立助詞に対しても定義することによって，次のような取立表現における活用形の自動決定を実現する。

[3] a. 書く＋テいる $\rightarrow$ 書いてテ形いる

b. 書く + も透過する＋テいる $\rightarrow$ 書いてテ形もいる

ここで「テいる」は，前方にテ形を要求する助動詞である。取立助詞は，この要求を透過するように定義しているので，取立助詞がある場合は，直前の語ではなく，その前の語を制約することになる.

接続型による活用形の自動決定は, 羽織構造の終端ノードと境界記号を線形化した境界・ユニット列において実行される $(\rightarrow \oint 3.7)$.

## 3.5 テンス位置の自動決定

羽織文法は，機能語中心主義を標榜しているが，テンスだけは特別扱いする。羽織文法の活用体系は，益岡・田窪文法 (益岡，田窪 1992)，および，それに準拠する Juman² の活用体系を基本としているため, 最終的にテンスは活用形の「夕形」によって表層化される。しかしながら，羽織構造では，テンスをノードのテンス属性として保持する.

図 1 の羽織構造では, テンス属性はノード「述語構造」に付与されている。この羽織構造を境界・ユニット列に変換すると，テンス属性はその構造下の最後の語「食べる」に継承される $(\rightarrow \oint 3.7)$. しかし, 後続語の「丁寧接尾辞ます」が「食べる」に基本連用形を要求するため, テンスを実体化することができない。このような場合，テンス属性は後続語に順送りされる。この例では，「丁寧接尾辞ます」がテンスを取りうる（夕形が可能な）ため，ここで実体化され「ました夕形」が生成される。この機構をテンス順送り機構と呼ぶ。テンスは，以下に示すように，複数の語に渡って順送りされる場合もある。

[4] 食べるテンス=夕＋テいる＋ない $\rightarrow$ 食べてテ形い基本連用形なかった夕形

この機構のおかげで，テンスを付加した述語に対しても，後付けでの機能語の付与が可能となる.

このテンス順送りにも，透過性が定義できる。接続型, テンス順送り機構, 透過性の組み合わせにより，次のような複雑な場合にも，正しい位置にテンスが設定される。
^{2}$ http://nlp.ist.i.kyoto-u.ac.jp/index.php?JUMAN
}

[5] 食べるテンス=夕＋テいる＋も透過する＋取立助動詞する＋ない

$\rightarrow$ 食べてテ形い基本連用形もし基本連用形なかった夕形

なお，「取立助動詞する」は，述語を取り立てるための専用の助動詞であり，前方の述語に「基本連用形」を要求する。

## 3.6 活用型の自動推定

羽織文法では，語を機能語と内容語，活用する語と活用しない語に区分すると説明した。羽織文法では, 品詞は重要ではない $(\rightarrow \$ 5.2)$ が, わかりやすさのため品詞別で示すと, 表 1 のようになる。ここでは, 一般の接辞（接頭辞・接尾辞）は除外した.

HB3 （羽織文法）は，機能語をすべて列挙し，その振る舞いを記述するという立場に立つので, 機能語の辞書は文法に含まれる。一方, 内容語の辞書は, 原則として不要という立場に立つ.

内容語を表層文字列化するために必要な情報は，次の 3 つである.

(1) 表記

（2）活用型（活用する語のみ）

(3) 活用形（(活用する語のみ）

HB3 は, 初代の Haori (佐藤 2015; 緒方他 2015) と異なり, 表記を制御しない. つまり, どのように表記するかはコード内で記述する。このため, 活用しない内容語に関しては，表層文字列化に必要な情報はコード内に存在する。

活用する内容語では，表記に加えて活用型と活用形が必要となる。活用形の扱いについてはすでに述べたので，残された問題は活用型であるが，HB3では，活用する内容語の活用型を自動推定する.

活用型推定規則を表 2 に示す。これらの規則は，活用型を正しく推定できない場合もあるが，規則を明示的に定めているので，どのような語に対して誤るかは明確である。そこで，そのような語（表記）に対してのみ，あらかじめ活用型を定義しておく，たとえば，「さえぎる」は末尾が「イ段+る」であるが，活用型は子音動詞型ラ行（五段活用）であるため，あらかじめ活用型を定義しておく必要がある（あるいは，コード中で明示的に指定する）。なお，「遮る」と漢字表記した場合は, 正しく子音動詞型ラ行と推定されるので, この表記に対しては活用型を定義しておく必要はない.

表 1 語の分類

表 3 に，形態素解析システム Juman (juman-7.01)の基本語辞書に登録されている活用する内容語の表記数と, これらのうち, 活用型を定義しておかなけれげならない表記数（HB3 で活用型を定義した表記数）を示す。この表に示すように，動詞の場合は $3 \%$ の表記に対して，活用型を明示的に定義すればよい.

動詞と比べて，イ形容詞で定義が必要な表記の割合が多い $(8 \%)$ のは, 末尾が「ない」のイ形容詞の活用型を細分化する必要があるからである。羽織文法では, 次の 4 種類の活用型が存在する.

(1) イ形容詞型アウオ段一丁寧体の形式は「〜です」. 例：「あじけない」

(2) イ形容詞型アウオ段ない—丁寧体の形式は「ありません」. 例：「ない」

（3）イ形容詞型アウオ段ない複合一丁寧体の形式は「〜ありません」. 例：「思わしくない」

（4）イ形容詞型接尾辞ない一丁寧体の形式は「〜ません」. 例：「いたたまれない」

後者の 2 つの活用型に属するイ形容詞は，内部構造（語構成）を持つ語である。前者は末尾

表 2 活用型推定規則の一覧

表 3 活用型の定義が必要な表記数

に「イ形容詞ない」を持ち，後者は「接尾辞ない」を持つ，形態素解析辞書では，諸般の事情から，これらを一語のイ形容詞として登録するのが一般的であるが，生成の立場に立てば，「思わしくィ形容詞連用形 + イ形容詞ない」，「いたたまれ動詞未然形 + 接尾辞ない」と分解して扱えば,問題は生じない。ただし，「違いないィ形容詞型アウオ段ない複合」のように，一語化していると思われる語も存在するため, いずれにせよ, 上記のように活用型の細分化は必要である.

活用型の定義が必要な割合がナ形容詞で非常に多い $(41 \%)$ のは, 連体修飾で「ナ形」の使用が優勢な「判定詞型ナ形容詞」(Jumanではナ形容詞）と「ノ形」の使用が優勢な「判定詞型ナ形容詞ノ」(Juman ではナノ形容詞）の数が均衡しているためである。ただし，「ナ形」と「ノ形」の使い分けには微妙な場合（「当選が確実な情勢」「当選が確実の情勢」）があり，活用型のみで連体修飾の形式を一意に決定できるわけではない。つまり，どちらの形式を使うか明示的に指定しなければならない場合も多く，たとえ活用型が正しく設定できなくてもそれほど大きな問題は生じない ${ }^{3}$ 。なお，羽織文法では，Juman とは異なり，すべてのナ形容詞に「ノ形」の存在を認めている，2つの活用型の唯一の違いは，連体修飾の場合のデフォールトの活用形が 「ナ形」か「ノ形」かの違いである.

最後に，活用型と品詞の関係について補足しておく，活用する内容語は動詞と形容詞（イ形容詞，ナ形容詞）であるが，羽織文法では，活用型が品詞の細分類となっている。動詞の活用型の名称はすべて「〜動詞型〜」，イ形容詞は「イ形容詞型〜」，ナ形容詞は「判定詞型ナ形容詞〜」である。つまり，動詞・形容詞の区別は艺長である（重要ではない）.

## 3.7 羽織構造の表層文字列化

ここで，羽織構造を表層文字列化する過程について補足しておく。この過程は，次のように 3 ステップからなる.

(1) 羽織構造を境界・ユニット構造に変換する。

この変換は，終端ノードと境界記号を左から順に集めればよい，ただし，非終端ノードに付与された属性情報を，適切な終端ノードに継承する必要がある。原則として，非終端ノードの属性情報は，一番右の子に継承する。これを再帰的に行えば，終端ノードに到達する。属性情報のうち「左境界」と「右境界」は, 境界記号として実体化する。

（2）境界・ユニット構造において，活用する語の活用形を定める。

まず，右から左へ接続型を伝達し，活用する語の活用形を定める。次に，左から右へ順に，表層文字列を生成する。このとき，テンスが実体化できなかった場合は，テンスを順送りする。


（3）最後に，終端ノードと境界記号のそれぞれに対して生成された表層文字列を，一つの文字列に結合する。

## 3.8 この章のまとめ

羽織構造は，表層文字列化に必要なすべての情報を保持している。すなわち，

$\cdot$ 語の順序情報は, 羽織構造の木構造が保持している.

・ 語の表記, 活用型, 接続型は, 語を表す終端ノードが保持している.

・ テンス情報は,ノードが保持している.
- 境界記号の情報は, ノードが保持している.

それゆえ，羽織構造が与えられれば，表層文字列は一意に定まる.

## 4 ブリックコードとBasic パッケージ

前章で示したように，語から文を合成するためには，それなりの道具立てが必要である。言い換えるならば，羽織構造をそのまま記述するのでは記述量が多い。ブリックコードは，それを回避するために導入した記述形式（ラッパー）である.

## 4.1 基本的アイディア

ブリックコードの基本的アイディアは，ブロック玩具のアナロジーから来ている．レゴを代表とするブロック玩具では, 基本となるブロック（レゴでは, brick（ブリック）と呼ぶ）を多数組み合わせて, 建物, 乗物, 動物などの多様なモデルを作ることができる. これと同じように, 文の部品をブリックとして提供し, これらを組み合わせるだけで多様な文を作りだせるようにしようという発想である.

ブリックコードのもうひとつの思想的源泉は, プログラミング言語 Lisp にある．初期の Lisp (Lisp 1.5) の中核は, 限られた数の基本関数と，それらを組み合わせて新たな関数を作り出す方法である。基本関数を組み合わせて複雑な関数を新たに定義することにより，多種多様な関数を提供することが可能となる。ブリックコードでは, このような拡張性を踏襲している.

## 4.2 基本ブリック

HaoriBrick3 (HB3)の基本ブリックは， 6 種類しかない. 前者が正式名, 後者が別名である. なお，以下の本文中では，ブリックの名称を〈ブリック名〉のような記法で記述する.

(1) $\langle$ lexal $\rangle,\langle$ lex $\rangle$ 一羽織構造の終端ノードを作る。内部に語の情報を保持する.

(2) 〈structure〉,〈構造〉一羽織構造の非終端ノードを作る.

(3) $\langle$ role $\rangle$
（4）〈parameter $\rangle,\langle$ 属性〉一羽織構造のノードに，属性值を付与する.

（5）〈boundary〉,〈境界〉一境界に記号を挿入する（羽織構造のノードに, 境界情報を付与する).

（6）〈producer〉一作り手（書き手・話し手）を指定する ( $\rightarrow \S 5.3 .2$ ).

これらのうち $\langle$ role $〉$ は, 述語構造の要素を, 補足語要素 (格要素) と連用修飾要素を区別するために導入したが, 本質的にはおそらく不要なので, 次の大改訂時に削除する可能性が高い.

基本ブリックの数が限定されていることは，非常に重要である。 ブリックコードを実行するとブリック構造が作成されるが，このブリック構造は，基本ブリックのみで構成される．それぞれの基本ブリックの機能ははっきりしているため, 羽織構造 $(\rightarrow \S 3.2)$ へ変換は容易である.唯一の変換らしき処理は, 〈structure〉ではその構造を成立させる要素を第 2 引数 4 として指定するので，構造タイプが binary_r と predicateの場合に，〈structure〉の引数の順番と羽織構造の子の順番が異なる点を調整する処理である.

先に示した，図 1 に含まれる 3 つのブリックコードの一番下のコードは, 基本ブリックだけで記述されている。その記述は長くなるため, 文を合成するコードをこのような形で記述するのはまれで，主に，後に述べるマクロブリックを使用する.

## 4.3 ブリックコードは Ruby コード

次の点を強調しょう.

## ブリックコードは, Rubyコードである.

初代の Haori (佐藤 2015; 緒方他 2015; 緒方, 佐藤, 松崎 2016) から HaoriBricks (佐藤 2017, 2018) に進む時点で，ブリックコードというラッパーを導入し， これをプログラム（Rubyコー ド）として記述することにしたのだが，結果的に，この選択が非常に大きな恩恵をもたらした。 ブリックコードは, 単なる Rubyコードであるから, プログラミング言語 Ruby の機能—デー 夕構造, 変数, 制御構造 (if-then-else)—がコード内で自由に利用できる. このことは, コードを書く際の自由度の向上に，大きく寄与する。

より技術的には，それぞれのブリックは，ある Ruby モジュールに定義されたインスタンスメソッド（ブリックメソッドと呼ぶ）である。ブリックコードの実行（評価）は，次のような形式で行い，ブリックコードを中括弧の中に記述する。この中括弧は，プログラミング言語 Ruby でブロックと呼ばれるものである.

HB3.basic\{述語（:食べる，を（:りんご)）\}

このブリックコードは, 「りんごを食べる」という表層文を生成するためのコードで，内容語


使って文を組み立てる 2 つのブリック〈を〉と〈述語〉の, 計 4 つのブリックで記述されている.

Ruby のブロックの実体は, Procオブジェクトであり, 名前のない関数のようなものである. HB3.basic（Rubyのクラス HB3 のクラスメソッド basic）は，このProcオブジェクトを，いわゆるクリーンルーム (Perrotta 2015) で実行する。具体的には，まず，最低限のメソッドしか定義されていない Object クラスのオブジェクト（クリーンルーム）を作成し，そのオブジェクトに，ブリックを定義しているモジュールを extend する（モジュールに定義されているインスタンスメソッドを特異メソッドとして使えるようにする)。この操作により，クリーンルームでブリックメソッドが実行できるようになるので，先のProcオブジェクトをこのクリーンルームで評価 (instance_eval) すると, ブリックコードが実行される.

この実行により生成されるのは，ブリック構造（Ruby オブジェクト）である。表層文字列を生成するためには, このブリック構造に to_ss というメソッドを適用すればよい.

## 4.4 マクロブリック

ブリックは,（単なる）Rubyのインスタンスメソッドであるから，新たなブリックを定義するためには，Rubyメソッドを定義すればよい.

先に述べたように，基本ブリックのみで記述したブリックコードは, 記述量が多い. この記述量を削減するために，多くのマクロブリックと短い別名を定義している．文を合成する際に実際に記述するブリックのほとんどは，マクロブリックの別名である.

たとえば，ブリック〈を〉は，〈格助詞を〉の別名である，このブリックは，次のように定義されている，なお，本論文で示すブリックの定義は，わかりやすさを重視するため，実際の定義を簡略化したものを示している。

このコードは，引数がない場合は単に「格助詞を」を作り，引数がある場合は，「格助詞を」 をブリック〈助詞〉の第 1 引数として組み合わせることを意味している。

^{5}$ Ruby のシンボル（:で始まる）は, lexal ブリックの略記法である
}

このコードは, 第 2 引数が nil の場合は nilを返し, 非 nil の場合は〈構造〉ブリックを作ることを意味している，值 nil は，值がないことを意味する。つまり，第 2 引数が nil の場合は，構造を作らない，このような定義により，次のコードは「食べる」のみを出力し，「を」を実体化しない.

## $\mathrm{x=\mathrm{nil}$}

HB3.basic\{述語（:食べる，を $(x)$ ) \}.to_ss＝> "食べる"

値 nilをどうハンドリングするかは，ブリックコードの使い勝手を大きく左右する．変数を用いて, ガ格の内容, ヨ各の内容, 述語を外から与えるコードは, 次のようになる。 ここで, ga, wo, pred は, Rubyの変数である.

このコードで，変数 ga やwo に nil を代入すれば，それぞれの格要素が格助詞达みで省略される。つまり，そのための専用のコードを書く必要がない. なお，変数 predに nil を代入した場合は, 述語構造全体が作成されない, さらに, 述語を省略した述語構造「〜が〜を」を作りたい場合は，predに空文字列を生成する特別なブリック〈empty〉を与えればよい。これらは， 4 行目のコードひとつで，すべて実現できる。

日本語の文では，格要素はしげしげ省略される。同様に，修飾要素も，存在したりしなかったりする．HB3 のブリックコードでは，それらの要素が存在しないことを nil で表現できるため，それぞれの場合に対して個別のコードを書く必要はない. このことは，コードの汎用性向上と記述量削減に大きく寄与する.

## 4.5 ジェネリックブリック

マクロブリックの動作は, 引数の数, および, 值が nil かどうかに依存するが, 引数の内容 (ブリック構造) の詳細までは立ち入らない. これに対して, 引数のブリック構造に応じて, 動作を変えるブリックを定義したい場合が存在する.

その一例は, 使役を表す述語接尾辞「せる」と「させる」の選択である。接続対象が母音動詞型活用の場合は「させる（食べさせる）」を，子音動詞型活用の場合は「せる（書かせる）」を
選択する必要がある.

次のコードでは, pred は変数であるから，どんな活用型の動詞が来るかは実行時にならないと定まらない。それゆえ，どちらの接尾辞を接続させるかは，実行時に決定しなければならい。

HB3 では，引数のブリック構造にアクセスする手段を提供しており，これを用いて〈使役〉 ブリックを作ることが可能である，具体的には，引数のブリック構造の最も後ろにある語を捕まえて(.rightmost_lexal), その活用型 (.ctype)の值で分岐すればよい。その概略は, 次のようになる。

このような, 引数のブリック構造を参照して動作を変えるブリックをジェネリックブリックと呼ぶ. 上記の〈使役〉は, 使役の接尾辞を付与するという機能を担うという意味で汎用的である ${ }^{6}$. 先に示した, 図 1 のブリックコードでは, 〈丁寧〉と〈ます〉がジェネリックブリックである。

ここでは詳細は述べないが，引数のブリック構造を参照するだけでなく，書き換えるブリックを作ることも可能である。たとえば，ブリック〈ます〉はそのような一例である．具体的には，「イ形容詞ない」に「ます」を接続する場合は，「ない」を「ある」に書き換え，「ません」 を接続させる。この操作により，「ありません」を生成することが可能となる.

[6] お金 + が＋ない＋ます～小金 + が＋ある＋ません（お金がありません）

## 4.6 Basic パッケージ

HB3 では，提供するブリックの集合をパッケージと呼ぶ．HB3 の標準パッケージである Basic パッケージには, 本論文の執筆時点で， 1,715 種類（別名を含めると 2,917 種類）のブリックが定義されている。それらの内訳を表 4 に示す.

この表において, 左闌が羽織文法の骨格をサポートするためのブリック, 中欄が具体的な語

表 4 Basic パッケージに含まれるブリック数

や表現に対応するブリック（機能語, 複合辞, 慣用句のサポート）, 右欄がそれ以外のマクロブリックとジェネリックブリックである。この表に示すように，従属節をサポートするためのブリック $(\rightarrow \oint 5.1)$ が非常に多い.

なお，Basic パッケージの編纂では，『基礎日本語文法一改訂版一』(益岡，田窪 1992)に掲載されている番号付きの全例文（1,177 例文）7を利用し，これらの例文を生成するコードを比較的容易に記述できるようにブリックを定義した。

## 4.7 この章のまとめ

ブリックコードは, 所望の羽織構造を作成するためのラッパーである。その実体は Rubyコー ドであり，コードを構成するブリックは，Rubyのインスタンスメソッドである．基本ブリックは 6 種類しかなく, それ以外のブリックは, 基本ブリックの組み合わせとして定義されたマクロブリック，または，ジェネリックブリックである，Basic パッケージには，多数のマクロブリックとジェネリックブリックが定義されており，このパッケージを利用することで，日本語文を合成するコードを比較的簡潔に記述することができる。

## 5 HaoriBricks3 の使用例

この章では，HB3の使用例をいくつか示し，HB3で何ができるのかを明らかにする.

## 5.1 複文を作る

日本語の長い文の大半は, 複数の節から構成される複文である。以下に例を示す.


[7] a. 音楽を聴きながら論文を書く.

b. 論文を書く。（主節)

c. 音楽を聴きながら(連用節ながら)

HB3 の Basic パッケージに含まれている従属節を作るブリックを使えば，単文から複数を合成するのは容易である。

このコードの 1 行目と 2 行目は，単文を合成するためのコードである。これらを評価したものをそれぞれ変数 $\mathrm{m}$ とに代入し，ブリック〈連用節ながら〉を用いて結合すれば，所望の複文が得られる。従属節の述語を基本連用形にすべきことは，このブリックが知っているので，明示的指定する必要はない. なお, このブリックは, 第 1 引数が nil の場合は従属節を作らないため，変数 c が nil の場合， 3 行目のコードは「論文を書く」という単文を生成する.

3 行目のコードで, 従属節の形式を固定したくないのであれば， 4 行目のように外で従属節の形式を定め，5 行目のように〈修飾〉ブリックを使って主節と結合すればよい. 従属節を作るブリックは, 1 引数の場合は従属節を作り, 2 引数の場合は, 第 1 引数で作成した従属節を第 2 引数に結合する.

Basic パッケージには，従属節を作るマクロブリックが 190 種類, 定義されている，その一覧を表 5 に示す.この表で, ブロック体以外のものは, 中分類をプレフィックス (prefix)として付与したものがブリックの名称となる（たとえば，〈並列節が〉など）。なお，従属節の作成と読点の付与を同時に行うブロック（たとえば，〈並列節が読点〉）も 170 種類, 定義されている.

一般に，節末形式が名詞を持つ場合，連体修飾を受けることができることが多い。これを従属節と同じように記述できるように，〈〜句〜〉というブリックも定義されている.

[8] a. 小説を書くとき — 時間節とき（述語 (:書く，を（:小説)))

b. 小説執筆のとき一時間句のとき (:小説執筆)

## 5.2 『スマホが震えた』を生成する

HB3 のコード記述例として，小説の自動制作を目指すプロジェクトの初期の段階で，プロジェクトメンバーの一人が書いたサンプル小説『スマホが震えた』の全文（図 2）を生成するコードを図 3 に示す。以下では，このコードを解説する。
- HB3には，単に要素を並べるだけの〈列構造〉が存在するので，これを利用すれば，文たけでなく, 文章を組み立てることができる。ブリック〈テキスト〉,〈段落 $\rangle,\langle$ 発話段落〉
表 5 従属節を作るブリックの一覧

 \\

は，〈列構造〉を利用している。

・ブリック〈判定詞省略〉は，いわゆる体言止めを生成するためのブリックである。そのままでは判定詞は表層化されないが，たとえば〈テ節〉に接続すると，「深夜一時頃で」 のように，背後に隠れている判定詞が出現する.
- 地の文は, 複文になることが多い. 〈並列節が読点 $\rangle,\langle$ 連用節ながら読点 $\rangle,\langle$ 条件節と読点〉 などは，従属節を作り，主節に結合するブリックである $(\rightarrow \$ 5.1)$. 実際のコード作成では，従属節を簡単に作れることが非常に重要である。

-いわゆる提題表現は, 〈提題〉ブリックを使って述語構造の外に書いてもいいし, 〈述語〉 の中に書いてもよい，前者の場合は修飾構造が作られ，後者はいわゆる格要素と同じ扱

スマホが震えた。

深夜一時ころ。ここは研究室の中。

鈴木邦男は、先月ここに配属されたばかりであるが、平均帰宅時間はすでに深夜零時を超えている。

邦男は大きなあくびをしながら、ポケットの中からスマホを取り出した。

「もしもし」

「鈴木邦男さんですか？」

「はい、あなたは？」

「わたしは悪魔」

「イタズラならよしてくれ。僕はいまレポートで忙しいんだ」

「なんでも一つ願いを叶えてみせましょう」

「バカバカしい、さあ、切りますよ」

「お待ちください、一度試してみてからでも損はないでしょう?」

「それなら、このひどい眠気をなんとかしてくれ。レポートが進みやしない」

「お安い御用です」

悪魔がスマホ越しに何やら呪文を呟いたと思うと、邦男の眠気はさっぱりと消え飛んだ。レポートもばっちり書けた。

しかしそれ以来、邦男は一睡もすることができなくなった。

図 2 緒方健人『スマホが震えた』

いとなる。

$\cdot$ 複合名詞は, 〈複合語〉ブリックを使って合成してもよいし, 一語として記述してもよい.前者の場合は，複合語の構成要素が部品となる（つまり，置換可能となる）が，後者の場合は，全体が部品となる。
- イ形容詞「大きい」は，連体修飾用法では「大きな形」が優勢である.ブリック〈形容詞〉 は第 1 引数が形容詞であることを，〈連体修飾〉は第 1 引数が第 2 引数を連体修飾することを意味している。なお，「大きな」は，「目が大きな少女」のように格要素を取りうるので，連体詞とみなすのではなく，イ形容詞のナ形とみなすのがよいと考える。

・ブリック〈発話〉は，発話形式のためのブリックで，発話文を鉤括弧で囲む．

$\cdot$ブリック〈お〜くたさい〉は，動詞「待つ」から丁寧な表現「お待ちください」を作るブリックである。この「ください」は「お〜・ご〜」の形式のみに接続する述語接尾辞 (「敬語接尾辞ください」) である.

-「レポートが進みやしない」は，「（レポートが）進まない」という述語表現を，「副助詞や」で取り立てた表現とみなす。この取立表現を組み立てる方法は, このコード例にもいくつか方法がある。なお，述語の取立表現には不明な点が多い。たとえば，イ形容詞「造作ない」の取立表現は「造作もない」だと思われるが，「いたたまれない」は取り立てることができないように思われる。このような現象には，まだ対応できていない．

-「スマホ越しに㕸く」の「に」は，何助詞とすべきかよくわからない。暫定的に「連用助詞に」に分類している $(\rightarrow \oint \mathrm{A} \cdot 2.1)$.

このコードが生成するテキストは、HTML にならい、段落に<p>タグを、改行に<br>タグを付与し、最後に整形する方式を採用している。HB3 は、HTML タグを透過性をもった境界記号として扱うため、テキストの任意の語境界に HTML タグを挿入可能である。

図 3 『スマホが震えた』を生成する HB3ソースコード

-「それ以来」も謎である，現在は，暫定的に〈複合語〉ブリックを使っているが，この解釈でよいかどうか自信がない。すでに述べたように，名詞を持つ節末形式は，連体修飾を受けることができる場合が多い.

[9] a. 小説を書くとき

b. 小説執筆のとき

c. そのとき

しかしながら，「以来」は連体修飾を受けることはできず，代名詞は連体形ではなく名詞形が接続する。

[10] a. 小説を書いて以来

b. *小説執筆の以来

c. *その以来

d. それ以来

e. 小説執筆以来

このように，文章をブリックコードで記述しようとすると，よくわからない言語現象が顕在化する，HB3 の実装は，このような現象をひとつひとつ潰していくという側面を併世持つ.

さらに，次の 3 点を付け加える。

-このコードでは, 内容語はRubyのシンボル（つまり，〈lexal $\rangle$ ）で記述され，それ以外は,他のブリックで記述されていることに気づく，つまり，〈lexal〉以外のブリックで構成される部分が，文を成り立たせる骨格であり，羽織文法が規定しているのは，主に，この部分である。

・このコードでは, 品詞ブリックがほとんど出現しない. 〈形容詞〉と〈接続詞〉が若干出現するだけである。その理由は，次のとおり。

－ 活用する内容語は, 裸の連体修飾の場合を除き, 述語構造をもつ. ブリック〈述語〉 は，第 1 引数を述語と解釈して活用型推定を行うので，動詞・形容詞を明示的に指定する必要がない.
- 活用しない内容語は, 構造だけが問題となるが, それはほとんどの場合, 「修飾構造 (binary_l)」である。ブリック〈連体詞〉，〈副詞〉，〈接続詞〉，〈感動詞〉は，いずれも 2 引数の場合はブリック〈修飾〉と等価である ${ }^{8}$. つまり, これらの品詞の区別は，羽織文法では本質的でない.

・このコードを構成するすべての部品（ブリック）は, 変数化できる（コードの外から指定可能である).このコードでは，登場人物の名前だけを変数化して外から与えているが， すべての内容語も同じように変数化することができる。それ以外のブリックも，単なる


Ruby メソッドコールであるから, send を使えば変数化できる。これが,「ブリックコー ド=Ruby コード」の威力である.

## 5.3 発話を作る

## 5.3.1発話文体を切り替える

前述の『スマホが震えた』の例にもあるように, 小説には登場人物の会話が含まれるのが普通である。日本語の小説では，発話者の情報は明示的に示されない場合が多い，それぞれの登場人物に対して，発話の文体を変えることなどの表現上の工夫によって，発話者が誰なのかわかるようにすることが，一般的に行われている。

たとえば，「フランス語を教えてほしい」という依頼を表明する場合，どのような文体を用いるかによって，読者が感じる発話者のイメージが異なる (金水 2003).

[11] a. フランス語を教えろよ（命令形十終助詞よ）一粗野な男性

b. フランス語を教えてくださらない？（テくださる十ない+疑問符）一上品な女性

c. フランス語を教えてちょうだい（テちょうだい）一幼い（あるいは，甘えた）感じ

これらは, 主に, 文末表現の違いによってもたらされる。すなわち, これらの文末表現をブリックとして定義し, それらのうちのひとつを選択して, 命題的表現（「フランス語を教える」） に結合すれば (木村，夏目，佐藤，松崎 2018)，読者が感じる発話者のイメージを操作できる.

## 5.3.2 発話者を切り替える

さらに，HB3の基本ブリックのひとつに，文や発話の作り手を明示的に指定する〈producer〉 ブリックがあり，その指定に従って表現を切り替える仕組みが組み达まれている，具体的には， ブリック構造から羽織構造を生成する際に，個別の作り手に対して定義されたフィルタを通すことにより，表現を切り替える。以下に，一例を示す。この例では，作り手「コナン」に対して定義したフィルタを使って，「〜しかない」という表現を「〜っきゃねえ」という表現に置き換えている。

ただし，上記のような切り替えを実現するためには，それぞれの作り手に対して，どのような変換を行うかを, 詳細に定義する必要がある。 そのため, この機能は, 現時点では, 実験的な位置付けとなっている.

## 5.4 文末を書き換える

表層文をブリックコードに変換できれば，ブリックコードを操作して，文を書き換えることができる。以下に示す 2 つ例は，企業との共同研究を進める過程で実際に必要となった具体例で，いずれも HB3 を使って実現された。なお, これらの例は, 文末を操作するだけなので,文全体をブリックコードに変換するのではなく，文末の述語部分をブリックコードに変換する方法で実現している.

## 5.4.1 ウィキペディア文を，話し言葉に適した形式に変換する

三宅宏実選手のウィキペディアの記事には，「趣味は足のネイルアート」という文が存在する. この文を，ソフトウェアエージェントに発話させることを想定し，話し言葉に適した文 $[12 \mathrm{c}]$ に変換する。

[12] a. 趣味は足のネイルアート.

b. 〈:ネイルアート $\rangle+\langle$ だ $\rangle+\langle$ 伝聞そうだ $\rangle+\langle$ 丁寧 $\rangle$

c. 三宅選手の趣味は足のネイルアートだそうです.

この例の場合, 元の文の文末として「ネイルアート（体言止め）」を同定し，それに〈だ，〈伝聞そうだ $\rangle^{9}$, 〈丁寧〉という 3 つのブリックを付加することで, 所望の文を作り出す. ただし，文頭の「三宅選手の」は，別の方法で補完する (柳，佐藤 2020).

## 5.4.2広告文の生成で，症状を問いかけ形式に変換する

広告文では，読者に働きかける表現が多用されるが，そのひとつに問いかけ形式がある。たとえば，「腰が痛い」という症状を問いかけ形式に変換することは，以下に示すように，述語「痛い」に，〈は〉，〈取立助動詞ある〉，〈か〉，〈丁寧〉という４つのブリックを付加すれば実現できる (平良, 佐藤, 宮田, 今頭 2019).

[13] a. 腰が痛い

b. 〈述語 $($ 痛い $)\rangle+\langle は\rangle+\langle$ 取立助動詞ある $\rangle+\langle$ か $\rangle+\langle$ 丁寧 $\rangle$

c. 腰が痛くはありませんか

なお, 取立助動詞とは, すでに述べたように, 述語の取立形式を作るための専用の助動詞である.


## 6 議論

## 6.1 卵が先か, にわとりが先か

これまで，日本語において，文生成用の専用ソフトウェアはほとんど存在しなかったと認識している。そのようなソフトウェアが作られなかった理由は, おそらく, ニーズがなかったからであろう。というのも，
- 生成すべき文が完全に確定しているのであれば，文字列として記述すればよい。それがもつとも合理的かつ簡便な方法である.
- 確定していない部分があったとしても, それが活用しない表現ならば，その部分を変数化した文字列テンプレートを用いればよい.

上記に該当しない場合，つまり，確定していない部分に活用する表現が含まれていたり，一旦生成した文を加工したりする必要が生じる場合に, HB3のようなソフトウェアが必要となる. エラーメッセージ生成のようなアプリケーションでは, HB3のようなソフトウェアは不要であり, 小説の自動制作のような自由度の高いテキストの生成を志すことで, はじめて必要性が顕在化したともいえる.

しかし，この見方は本当だろうか. 我々は，プログラムによって自動制作した小説を『日経星新一賞』に応募することによって, テキストの自動生成の可能性を広く知らしめたわけだが, その後に寄せられた問い合わせにより，テキスト自動生成のニーズは，それなりに存在するという認識に至っている。前章の文末の書き換えは，その具体例の二例である。この他にも，パラフレーズ，文体変換，発話に対するキャラクタ性付与など，文変換のニーズが存在する.

「文生成は意味表現（内部表現）を表層表現に変換すること」という思い込みが，文生成へ足を踏み入れることを躊躇させていたのではないだろうか. その思い込みを破棄し，文生成を部品からの合成とみなせば，文生成実現のハードルは大きく下がる，さらに，それを実現するソフトウェアがあれば，個別アプリケーション用の文生成プログラムは，比較的容易に実現できる。潜在的なニーズが，顕在化する可能性もある。

## 6.2 ジェネリックブリックによる文法の隠蔽と高機能化

現在の HB3 が満足のいくものに仕上がっているかといえば，そのレべルには達していない. その理由のひとつは，文法の隠蔽が不十分であることにある.

HB3 は，羽織文法に従っている。この文法を熟知していれば，ブリックコードを書くことはたやすい。しかしながら, HB3のユーザーに, 羽織文法の熟知を求めるのは酷であろう.

たとえば，羽織文法では， 4 種類の「ない」が存在する.

(1) イ形容詞の「ない」. 例：暇もお金もない

（2）否定接尾辞の「ない」．動詞型活用に接続する，例：食べない，食べさせない

（3）テ助動詞の「ない」.「〜テいない」の「い」が脱落した形式. 例：論文を書いてない

（4）取立助動詞の「ない」．形容詞の否定取立表現を作る．例：美しくもない，確実ではない生成という立場に立てば，上記の 4 種類の「ない」の振る舞いはそれぞれ異なるので，これらを区別することは必然である。しかし，ユーザーに，これらを適切に使い分けることを求めることはできないであろう。

ジェネリックブリックは，このような使い分けの困難さを軽減する役割を果たしている．たとえば，ジェネリックブリック〈ない〉には，次のような使い分けの自動判定が組み込まれている 10 。

(1) 引数がない場合は,「イ形容詞ない」と判定する.

（2）イ形容詞型，判定詞型の活用に接続する場合は，「取立助動詞ない」と判定する.

（3）動詞型の活用に接続する場合は，「否定接尾辞ない」と判定する.

それゆえ, この〈ない〉と，そこではハンドリングできない〈テ助動詞ない〉の 2 つのブリックを使い分ければよい 11.

このように，ジェネリックブロックを巧みに定義することによって，文法の隠蔽はある程度可能であるが，まだまだ不完全である。 さらに多くの，そして強力なジェネリックブロックを定義する必要があると考えている.

ジェネリックブロックは，ある意味において，文法的機能の抽象化とみなすこともできる。 たとえば，「です・ます」の使い分けを自動的に行う〈丁寧〉ブロックは，その典型例である.羽織構造には抽象的な文法的機能が入る余地はないが，ジェネリックブロックを定義することよって, ブリックコードでは文法的機能による記述が可能となる，今のところ，Basic パッケー ジでは文法的機能の抽象化を強く推進する予定はないが，それを推進したパッケージを作成するのも, 一つの可能性としてはありえる。

## 6.3 文合成の言語依存性

それぞれの言語の文は, その言語に固有の特徴が強く現れるため, 文合成のためのソフトウェアは，必然的に，対象言語に強く依存せざるを得ない， Realization engine（文を表層化するツー ル)として提案・実装されたSimpleNLG (Gatt and Reiter 2009)は英語を対象としているが, このツールを基盤として, これまでにドイツ語, フランス語, イタリア語, スペイン語など 7 言語を対象とした版 (adaption) が作られている（たとえば， (Braun, Klimt, Schneider, and Matthes 2019)を参照のこと). しかしながら, これらの版は, その実現にあたって, 対象言語用の辞書, および，形態生成，句生成，語順決定等のルールが新たに実装されており，SimpleNLGの枠組みを借りた別システムと捉える方が適切であろう。


SimpleNLG と HB3 のアーキテクチャは，大きく異なる. SimpleNLG（とその各言語版）では，ある範囲の言語現象を属性 (feature) として抽象化し，その範囲内 (coverage) に限定した表層化をサポートする。つまり，表層化できる文の形式には制限がある。同時に，ある種の抽象表現を文（表層文字列）に変換するという伝統的な surface realizer (Reiter and Dale 2000)の考え方からは，大きくは逸脱していない，これに対して，HB3 は，この考え方から完全に逸脱し，「文を合成するコード（プログラム）を書く」ことによって文合成を自動化するという立場をとる。HB3が提供する基本ブリックは，日本語の文を組み立てるために必要な最低限の道具立てであり，原理的には，あらゆる文を合成できる。このレべルで万能性を担保しつつ，マクロブリックおよびジェネリックブリックという拡張性により，所望の文を合成するコードを簡潔に記述することを可能にしている.

HB3 がこのような形となったのは, 対象言語が日本語であるということと, あらゆる文が想定されうる小説の自動制作が最終ゴールであるということによる，HB3のアーキテクチャは，日本語以外の言語の文合成にも適用できるとは思われるが，それぞれの言語の文法に即したアー キテクチャを考える方が建設的であろう 12.

## 6.4 何が達成できれば完成なのか

HB3 はどこに向かうのか. 何が達成できれば「できた」とみなすのか. 2 章で掲げた目標は，「日本語文を合成するコードを，できるだけ簡潔に書けるようにしたい」であったが，「できるだけ」という表現は相対的であり，絶対的なゴールを規定するものではない.

羽織シリーズの最初の版に比べて，文を合成するために記述しなければならない記述量は,格段に減少した。さらに，マクロブリックとジェネリックブリックを多数定義することによって，実際に記述するブリックコードも短くなり，かつ，羽織文法をそれほど意識しなくても書けるようになってきている。それでも，コードを書かなければならないことには変わりはない。試験的に実装した羽織テンプレートは，ブリックコードを書く代わりに，文字列に若干のアノテーションを付加することで，自動的にブリックコードを生成する仕組みである。 たとえば,以下の 1 行目の文字列は，2行目のコードに自動変換されるので， 3 行目のような生成が可能である。

template = "\{りんご\}を\{食べる\}"

lambda\{|args| HB3.basic\{ 述語（(args[:食べる] || :食べる)，を（args[:りんご] ||:りんご)）＼$\} }$ g(:夕, template,\{食べる: :買う \}).to_ss => "りんごを買った"



その值が定義されていれば，その値が使われる，つまり，このテンプレートで，「〜を〜」というあらゆる表現が生成できる。羽織テンプレートでは, 中括弧で括られた部分がテンプレートのスロットで，その中身がデフォールトのフィラーとして解釈される。このテンプレートはブ

現時点で羽織テンプレートがサポートしているのは単文のみであるが, アノテーションの記法を拡張して, より複雑な文をブリックコード化することも，原理的には可能である.

記述量を究極まで減らす方法は，文字列として記述した文を，ブリックコードに変換する方法である。しかし，その実現には，背後で形態素解析や構文解析を動かさなければならなず，解析誤りが混入する可能性を排除できない。ただし，文末のみが正しく解析できればよいと割り切れば，この方法も現実的な選択肢に入ってくる (佐野, 佐藤, 宮田 2020). 5.4 節の具体例は, この方法で実装している。

いずれにせよ，何が達成できれば「できた」とみなすのかは，できてみなければわからない. この研究のゴールを見つけること自身が, この研究のゴールである.

## 7 おわりに

本稿では，日本語文を合成するためのドメイン特化言語 HaoriBrick3 (HB3)の設計思想と実現・実装のための工夫，および，HB3の利用例について述べた.

最後に, HB3 に至る羽織シリーズの開発を通して明らかになったと私が考えているのことを,以下に示す.

-これまでの文法は，文の解析，すなわち，「実際に存在する文の構造（や意味）をどう解釈するか」に焦点があった. 日本語文の機械的合成のための文法は, 解析のための文法とは異なる様相を呈する。たとえば，品詞は重要ではなく，活用型の方がより重要である。文節係り受け構造よりも，羽織構造のような構造の方が適している。
- 日本語の文合成のための文法の中核は，機能語（表現）を列挙し，それぞれの機能語の働きを明らかにすることに帰着できる。明らかにしなければならない機能語の数（オー ダー）は，数千である。日常的に使われる書き言葉の範囲であれば， 2,000 程度に収まるたろう。
- 日本語文を構成する要素の中で, 特に複雑な部分は, (1) 述語の形式（述語接尾辞・助動詞の付与), (2) 従属節の節末形式, (3)とりたて, (4) 敬語表現, である.
- 実際に文を合成する際には内容語が必要となるが, HB3では，それが内容語であるとわかれば十分である。つまり, 内容語の辞書を用意する必要はない. このことは, 個別ア


プリケーション用の文合成コードを書く際に，非常に大きな長所（省力化）となる．

## 謝 辞

本稿の 6.3 節と第 7 章, 付録 $\mathrm{B}$ は, 查読者の提案により追加した. 有益な提案に感謝する.

本研究は以下の助成を受けて実施した. JSPS 科学研究費補助金基盤研究 (B)「文章の読解と産出のための言語処理」(課題番号 15H02748), 同挑戦的萌芽研究「発話に対するキャラクタ重畳機構の実現」(課題番号 $15 \mathrm{~K} 12179)$, 同挑戦的萌芽研究「ブロック玩具をモデルとする日本語文章合成ツールキットの設計と実装」（課題番号 17K20028），同基盤研究 (B)「日本語文章の構造モデルとその段階的詳細化による文章自動生成機構」(課題番号 18H03285).

## 参考文献

Braun, D., Klimt, K., Schneider, D., and Matthes, F. (2019). "SimpleNLG-DE: Adapting SimpleNLG 4 to German." In Proceedings of the 12th International Conference on Natural Language Generation, pp. 415-420.

CoGenTex Inc. (2000). RealPro General English Grammar User Manual.

Gatt, A. and Reiter, E. (2009). "SimpleNLG: A Realisation Engine for Practical Applications."

In Proceedings of the 12th European Workshop on Natural Language Generation (ENLG 2009), pp. 90-93.

木村遼, 夏目和子, 佐藤理史, 松崎拓也 (2018). 発話表現文型辞書を利用した多様な発話文生

成機構. 2018 年度人工知能学会全国大会（第 32 回）, 2E2-02.

金水敏 (2003). ヴァーチャル日本語役割語の謎. 岩波書店.

益岡隆志，田窪行則 (1992). 基礎日本語文法一改訂版一. くろしお出版.

日本語記述文法研究会 (編) (2003-2010). 現代日本語文法（全 7 巻）. くろしお出版.

緒方健人, 佐藤理史, 松崎拓也 (2015). 文節木の段階的実体化による日本語文生成器の作成. 2015 年度人工知能学会全国大会論文集, 3M3-1.

緒方健人, 佐藤理史, 松崎拓也 (2016). 日本語文生成器 Haori における複文合成. 言語処理学会第 22 回年次大会発表論文集, pp. 334-337.

Perrotta, P. （角征典訳）(2015). メタプログラミング Ruby 第 2 版. オライリー・ジャパン.

Reiter, E. and Dale, R. (2000). Building Natural Language Generation Systems. Cambridge University Press.

佐野正裕，佐藤理史，宮田玲 (2020). 文末述語における機能表現検出と文間接続関係推定への応用. 言語処理学会第 26 回年次大会発表論文集, pp. 1483-1486.
佐藤理史 (2015).「文生成器を作る」とはどういうことか. 言語処理学会第 21 回年次大会発表論文集, pp. 1080-1083.

佐藤理史 (2016). コンピュータが小説を書く日. 日本経済新聞出版社.

佐藤理史 (2017). HaoriBricks: ブロック玩具に学ぶ日本語文章生成ライブラリ。言語処理学会第 23 回年次大会発表論文集, pp. 20-23.

佐藤理史 (2018). 述語取り立て形式の整理と文生成器への実装. 言語処理学会第 24 回年次大会発表論文集, pp. 53-56.

平良裕汰朗，佐藤理史，宮田玲，今頭伸嘉 (2019)、ダイレクト広告コピー文の分析と自動生成.

言語処理学会第 25 回年次大会発表論文集, pp. 406-409.

柳将吾, 佐藤理史 (2020). ウィキペディアから抽出した人物エピソードの話し言葉への変換. 言語処理学会第 26 回年次大会発表論文集, pp. 437-440.

## 付録

## A 羽織文法に関する補足

羽織文法の定義にあたっては多くの資料を参照したが，特に参考にしたのは，益岡・田窪文法 (益岡, 田窪 1992) と『現代日本語文法 1-7』(日本語記述文法研究会 2003-2010) である.

## A. 1 活用体系

羽織文法の活用体系は，益岡・田窪文法，および，Jumanの活用体系に準拠している。それらからの大きな変更点は, 次の 2 点である.

(1) 列活用を考えない（廃止する）

(2) 末尾が「ない」のイ形容詞の活用型を細分化する $(\rightarrow \S 3.6)$

羽織文法では，判定詞は「だ」のみを認め，「である」と「です」は，それぞれ，次のようにみなす。

である「判定詞た」のテ形「で」に，「取立助動詞ある」が接続したもの

です「判定詞だ」のダ消失形に「丁寧接尾辞です」が接続したもの

「である」の形式は，「ではある」，「でもある」のように，いわゆる取立助詞の挿入が可能である. この形式と, 取立助詞の挿入がない形式との一貫性を重視し,「デアル列」とはみなさない.「です」の形式は，それほど強い理由がないが，列活用の存在は活用体系を複雑化するので， これも「デス列」とみなさい.

なお，ナ形容詞に関しても，同様の扱いとする.

## A. 2 機能語

羽織文法の中核を担うのは, 機能語のリストである。羽織文法では, 機能語はすべて列挙する.機能語の一覧を表 6 と表 7 に示す. 機能語は, 大きく, 活用しない助詞と, 活用する判定詞, 助動詞，述語接尾辞に分けられる。

これらの機能語（表記）には， すべて固有の名称 (ID)を付与してある. 原則として，機能語の中分類をプレフィックスとし，それに表記を組み合わせたものを ID とする。この方法で区別できない場合は，なんからの文字を付与して区別する。たとえば，羽織文法では，接続助詞「が」として, 「本を書いたが」のような一般的な「が」以外に，王族のような高貴なキャラク夕が臣下に許可を与える際に使う「書くがいい」の「が」も認める．後者は「接続助詞が終止」 として，前者の「接続助詞が」と区別する ${ }^{14}$.

機能語のリストは，Juman の基本辞書を出発点に，各種の資料を参照しながら，最終的には私の言語直感に基づいて定めた。

## A.2.1 助詞

助詞は, 格助詞, 副助詞, 接続助詞, 終助詞の通常の細分類以外に, 以下に示す引用助詞, 並列助詞, 連体助詞, 疑問助詞, 連用助詞という細分類を設ける. 取立助詞という分類は設けず,副助詞に含める（Juman の扱いを踏襲する）。

表 6 羽織文法の機能語一覧 (1) 活用しない機能語

 \\


表 7 羽織文法の機能語一覧 (2) 活用する機能語

 \\

（1）引用助詞引用を表す助詞で，その代表格は「と」である.

（2） 並列助詞一並列構造を作る助詞で，その代表格は「と」や「や」である.

（3）連体助詞 — 連体修飾を構成する助詞で，その代表格は「の」である.

(4) 疑問助詞 —「か」と「かどうか」を終助詞から分離したものである.

（5）連用助詞 —よくわからない（判定詞由来と考えられる）「に」と「で」を便宜的に収容するために設けたもの $(\rightarrow \$ 5.2)$ で, この 2 語のみである.

なお, 現時点では, 終助詞の網羅性が低い.

## A.2.2 判定詞

前述の通り，判定詞は「判定詞だ」しかない.

## A.2.3 助動詞

助動詞は，次のように細分類する。

(1) 終止助動詞 — 終止形に接続する助動詞

(2) 終夕助動詞 — 終止形・夕形に接続する助動詞.

(3) 連体助動詞 — 連体修飾の形式に接続する助動詞.

(4) 丁寧助動詞一丁寧体を作る助動詞.

（5）テ助動詞 — 直前の述語にテ形を要求する。直前に取立助詞の插入を許す.

（6）夕リ助動詞一直前の述語にタリ形を要求する。

（7）取立助動詞—述語の取立形式を作る助動詞。直前に取立助詞の挿入を許す.

（8）連用助動詞 —「連用助動詞ござる」のみ。「〜にござる・ございます」の形式を作る.

終止・終夕・連体・丁寧助動詞の 4 種類は, 益岡・田窪文法の助動詞に対応する。テ・タリ・取立・連用助動詞は独自の分類で，益岡・田窪文法とは異なる扱いである.

## A.2.4 述語接尾辞

述語接尾辞とは,（複雑な）述語を構成する接尾辞で, それ以外の接尾辞と区別して扱う。羽織文法の述語接尾辞は, Juman の述語性接尾辞に，おおよそ対応する.

述語接尾辞は, 次のように細分類する。

(1) ボイス接尾辞一ボイスに関わる接尾辞.「れる」，「られる」など.

(2) 否定接尾辞一否定に関わる接尾辞.「ない」，「ぬ」など.

(3) 可能接尾辞一可能に関わる接尾辞.「できる」,「うる」など.

(4) テ縮約接尾辞—テ形が縮退した形式をとる接尾辞.「ちまう」など.

(5) 意志接尾辞一「（書か）ん」のみ.

（6）相接尾辞一アスペクトに関わる接尾辞.「（殴り）かかる」，「（書き）かける」.

（7） 様相接尾辞一動詞に接続し，ある種の様相を表す接尾辞.「たい」，「すぎる」など.

(8) 丁寧接尾辞一丁寧形に関わる接尾辞.「です」,「ます」など.

（9）敬語接尾辞 —敬語表現に関わる接尾辞.「くださる」，「なさる」など.

(10) 特殊接尾辞一「や」のみ.（判定詞・ナ形容詞のいわゆるヤ列）

(11) 述語性接尾辞一述語を作る接尾辞.「する」,「的だ」など.

## A. 3 接続型

接続型の枠組みは確立されているが，具体的な接続型の定義は，いまだに発展途上にある。現時点では， 89 種類の接続型が定義されているが，安定状態にはほど遠く，問題が生じるたびに
修正を繰り返している。その理由は，次の 2 つである.

・ 接続型という概念自身が新規なため，まとまった資料が存在しない.

・ 機能語の振る舞いは，それぞれ微妙に異なることが多い.

接続型の安定化は, 羽織文法の大きな課題である.

# 
B羽織シリーズの変遷

羽織シリーズの出発点は, 2015 年に実装した Haori (佐藤 2015 ; 緒方他 2015, 2016) である. Haori は，文構造として文節係り受け構造（木構造）を採用し，木構造のそれぞれの文節に対して, 主要部（内容語）と機能部を記述する方式を採用した. 2016 年秋に, ブロック玩具のアナロジーを基本アイディアとする新方式を採用し，記述形式としてブリックコードを採用した。同時に，文の構造として羽織構造を採用し，文節係り受け構造と決別した。これが， HaoriBricks (佐藤 2017, 2018) である。本論文で述べた新機軸の大半は, HaoriBricks の開発過程で具現化された. HaoriBricks3 (HB3)は, 2018 年春から開発している HaoriBricks の再実装・機能強化版である。HB3では，羽織文法の体系化を推し進め，プログラムを全面的に書き直した，HB3 は，準備が整い次第，公開する予定である.

## 略厤

佐藤理史：1988 年京都大学大学院工学研究科博士後期課程研究指導認定退学.京都大学工学部助手, 北陸先端科学技術大学院大学情報科学研究科助教授,京都大学情報学研究科助教授を経て, 2005 年より名古屋大学大学院工学研究科教授. 博士 (工学). 本学会, 人工知能学会, 情報処理学会, 日本認知科学会, ACM 各会員.

\author{
(2020 年 1 月 31 日受付) \\ (2020 年 3 月 17 日採録)
}