\documentclass[tombow,japanese]{jnlp_2.3}
\usepackage{jnlpbbl_1.3}
\usepackage[dvipdfm]{graphicx}
\usepackage{gentombow}
\usepackage{amsmath}
\usepackage{array}
\settombowbleed{5mm}
%%%%\usepackage{hangcaption_jnlp}
%%%%\usepackage{udline}
%%%%\setulminsep{1.2ex}{0.2ex}
%%%%\let\underline=\ul

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% author's definition
\usepackage{lingmacros}
\usepackage{listings,jlisting}
%%%%\usepackage{booktabs}
%%%%% 本文中のBrick, BrickCode
\newcommand{\brick}[1]{\mbox{$\langle$#1$\rangle$}}
%%%%\newcommand{\bc}[1]{\texttt{\{ #1 \}}}
\lstset{% general command to set parameter(s) 
	  language=Ruby,%
	  numbers=left,%
	  numberstyle={\scriptsize},%
	  basicstyle=\ttfamily\small,% print whole listing small 
	  keywordstyle=\bfseries,%
	  identifierstyle=,%
	  commentstyle=,%
	  stringstyle=\ttfamily,%
	  showstringspaces=false,%
	  frame=single,framesep=5pt,%
	  columns=flexible}
\newlength{\savexkanjiskip}
\setlength{\savexkanjiskip}{\xkanjiskip}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\Volume{27}
\Number{2}
\Month{June}
\Year{2020}
%%%%\Issuetitle{「　　　　」特集号}

\received{2020}{1}{31}
%%%%\revised{2006}{3}{4}
%%%%\rerevised{2006}{5}{6}
\accepted{2020}{3}{17}

\setcounter{page}{411}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\jsubject{一般論文}
\jtitle{HaoriBricks3: \\日本語文を合成するためのドメイン特化言語}
\jauthor{佐藤　理史\affiref{NU}}
\jabstract{%
本論文では，日本語文を合成するためのドメイン特化言語HaoriBricks3 (HB3) について述べる．HB3では，ブリックコードと呼ぶRubyコードで，どのような日本語文を合成するかを記述する．このブリックコードを評価すると，ブリック構造と呼ばれるRubyオブジェクトが生成され，さらに，これに表層文字列化メソッド\texttt{to\_ss}を適用すると，表層文字列が生成される．本論文では，HB3の設計思想，実装のための工夫について説明し，HB3で何ができるのかを示す．}
\jkeywords{文合成，ドメイン特化言語，日本語文法，テキスト生成}

\etitle{HaoriBricks3: A Domain-Specific Language\\
	for Japanese Sentence Composition}
\eauthor{Satoshi Sato\affiref{NU}}
\eabstract{%
This paper describes a domain-specific language, HaoriBricks3 (HB3), for writing programs that compose Japanese sentences.  In HB3, we write a Ruby code called {\em brick code}, which instructs how to compose a sentence.  The evaluation of a brick code produces the Ruby object called {\em brick structure}, from which the surface sentence string is generated by the method \texttt{to\_ss}. This paper presents the design philosophy and implementational innovations of HB3, as well as demonstrates the applications of HB3.}

\ekeywords{Sentence Composition, Domain-specific Language, Japanese Grammar, Text Generation}

\headauthor{佐藤}
\headtitle{HaoriBricks3}

\affilabel{NU}{名古屋大学大学院工学研究科情報・通信工学専攻}{Department of Information and Communication Engineering, Graduate School of Engineering, Nagoya University}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
\maketitle


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{はじめに}

プログラムによる小説自動制作の実現を目指す過程\cite{Sato2016}で，私が
直面した問題の一つは，次のような問題である．
\begin{quote}\bf
日本語の文を合成するために，どのようなソフトウェアシステムを用意すればよいか．
\end{quote}

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

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

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% fig. 1
\begin{figure}[p]
\begin{center}
\includegraphics{27-2ia11f1.eps}
\end{center}
\caption{ブリックコードからの表層文字列生成}
\label{fig:process}
\end{figure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

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

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{設計思想}
\label{s:設計思想}

HB3で実現したかったことを一言で言うならば，次のようになる．
\begin{quote}\bf
日本語文を合成するコードを，できるだけ簡潔に書けるようにしたい
\end{quote}

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

HB3をドメイン特化言語にせざるを得なかったのは，次のような現状認識によ
る．
\begin{quote}\bf
あらゆる文の意味を表現しうるような人工的な内部表現（意味表現）は，
現時点では設計できない．
\end{quote}

羽織シリーズの最初の版\cite{Sato-NLP2015,Ogata-JSAI2015}を作る際には，
英語のsurface realizer，特にRealPro \cite{RealPro}を参考にした．伝統的
なテキスト生成システムは，伝えるべき内容を表す意味表現を入力として，い
くつかのモジュールをパイプラインにつなげ，表層文字列を出力するという構
成をとる\cite{Reiter}．このパイプラインの最後に配置されるsurface
realizerは，文の意味表現を表層文字列に変換するモジュールとして位置づけ
られる．しかし，あらゆる文が想定されうる小説の自動制作を最終ゴールとす
る以上，実現すべきソフトウェアの機能を「意味表現を表層文字列に変換する」
と規定するのでは，ゴールには到達しえないと考えた．

その代わりに採用したのは，「部品（語）から文を合成する」アプローチである．
このアプローチ下で日本語文の表層文字列を合成するために必要なことは，次
の2点に集約される．
\begin{enumerate}\bf
\item 語をどのような順番に並べるかを決定する．
\item 語が活用する場合は，その活用形を適切に決定する．
\end{enumerate}

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

文中で活用形がどのような情報を担っているかを考えると，次の2種類がある
ことに気づく．
\begin{enumerate}
\item
\textbf{次の語に接続するために要請されている}．\\
たとえば，子音動詞型活
用（五段活用）の動詞の直後に「ない」が接続する場合は，その動詞は「未然形」
を取らなければならない．この「未然形」は，「ない」に接続するために要請
されているだけで，\underline{それ以上の意味はない}．
\item 
\textbf{特定の文法的機能を担う}．\\
たとえば，命令形は「命令」という意図（モダリ
ティ）を表す．
\end{enumerate}

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

このような考え方に基づき，日本語文を合成するソフトウェアシステムを，
次のような機能を持つドメイン特化言語として設計・実装する．
\begin{itemize}
\item コードで記述できるようにするもの
\begin{enumerate}
\item 文を合成する部品
\item 部品の順序
\item 文法的機能を担う活用形
\end{enumerate}
\item 自動的に決定するもの
\begin{enumerate}
\item 直後の語で定まる活用形
\end{enumerate}
\end{itemize}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{羽織文法と羽織構造}

図\ref{fig:process}に示したブリックコードから表層文字列を生成する過程
を，次のように，2段階に大きく分ける．
\begin{enumerate}
\item ブリックコードから羽織構造まで
\item 羽織構造から表層文字列まで
\end{enumerate}

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{羽織文法}

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

日本語の文法体系は，おおよそ，次の要素から構成されるのが標準的であろう．
\begin{enumerate}
\item 語の分類体系（いわゆる品詞体系）
\item 活用語の活用体系
\item 構文構造の定義（文の背後にどんな構造を仮定するか）
\item 文法的機能（テンス・アスペクト・モダリティなど）とその表現形式
\end{enumerate}

羽織文法は，次のような特徴を持った文法である．
\begin{enumerate}
\item
語の分類では，機能語と内容語の区別，活用する語と活用しない語の区別を重要視する．
\item
詳細な活用体系（活用型と活用形）を提供する．活用型は，文法の中核的要素の
ひとつである．これに加えて，\textbf{接続型}($\rightarrow$\S\ref{s:接続型})を定
義する．
\item
表層文の背後に，\textbf{羽織構造}($\rightarrow$\S\ref{s:羽織構造})を仮定する．
\item
文法的機能のほとんどを，機能語の働きによるものと考える\textbf{機能語中
心主義}を採用する．
\item
句読点や括弧などの記号を語とは明確に区別し，\textbf{境界記号}($\rightarrow$\S\ref{s:境界})
とみなす．
\end{enumerate}

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

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

このような特徴を持った羽織文法の基本思想は，次のように集約される．
\begin{quote}\bf
日本語の文は，機能語によって組み立てられており，文法（文の成り立ちとそ
の規則性）を明らかにすることは，機能語を列挙し，その振る舞いを記述する
ことである．
\end{quote}

なお，羽織文法に関する補足を付録\ref{s:羽織文法補足}に示した．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{羽織構造}
\label{s:羽織構造}

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

非終端ノードのタイプは，次の4種類のいずれかである．
\begin{enumerate}
\item binary\_r （2分岐右タイプ） --- 2つの子ノードを持つ．右の子がその構造を成立させる要素．
\item binary\_l （2分岐左タイプ） --- 2つの子ノードを持つ．左の子がその構造を成立させる要素．
\item predicate （述語タイプ） --- 1つ以上の子ノードを持つ．最後の要素が述語要素．
\item sequence  （列タイプ） --- 2つ以上の子ノードを持つ．それぞれの子は同等の扱い．
\end{enumerate}

文中に現れる主要な構文構造は，次の4種類である．括弧内は構造のタイプを表す．
\begin{enumerate}
\item 述語構造(predicate)
\item 修飾構造(binary\_l)
\item （並）列構造(sequence)
\item 提題構造(binary\_l)
\end{enumerate}

この他に，機能語を付加する次のような構造がある．これらはすべて，binary\_rである．
\begin{enumerate}
\item 助詞構造 (binary\_r)
\item 判定詞構造 (binary\_r)
\item 助動詞構造 (binary\_r)
\item 述語接尾辞構造 (binary\_r) --- 複雑な述語を作る接尾辞を付加する構造
\end{enumerate}

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{境界記号の導入}
\label{s:境界}

句読点や括弧などの記号は，実際の言語処理ではやっかいな存在である
\footnote{これらの記号がないとうまくいかない処理と，あるとうまくいかな
い処理が混在する．さらに，同じ記号が，複数の用途で使われるので，統一的
に扱うことが難しい．}．形態素解析では，句読点や括弧などは形態素と同等
に扱われるのが普通であるが，それらは明らかに「形態素」ではない．句点は
文の区切り記号であるし，読点は文中の比較的大きな切れを表す区切り記号で
ある．そしてそれらは，文字列として書く場合にのみ，目に見える形で実体化
される．

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

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

後に述べるように，境界記号には，\textbf{透過性}が定義される．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{接続型の導入}
\label{s:接続型}

\textbf{接続型}とは，機能語が，直前の語の活用型・活用形をどのように制約するかを
記述するために導入した制約類型である．この接続型を用いて，直前の語の活
用形の自動決定を実現する．

たとえば，「丁寧接尾辞ます」の接続型は「接尾辞ます接続」である．この接
続型は，直前の語の活用型・活用形を次のように制約する．
\begin{enumerate}
\item
活用型が「子音動詞型ラ行イ」であれば，「基本連用形 2」と「基本連用形」を取りうる．
デフォールトは「基本連用形 2」である．（具体例は以下で説明する．）
\item
活用型がそれ以外の「動詞型」であれば，「基本連用形」を取る．
\item
それ以外の活用型，および，活用しない語には接続しない．
\end{enumerate}

この定義に従い，「ます」の直前の語の活用形は，次のように設定される．
\eenumsentence{
\item
いらっしゃる {\scriptsize 子音動詞型ラ行イ} + ます $\rightarrow$
いらっしゃい {\scriptsize 基本連用形 2} ます
\item
書く {\scriptsize 子音動詞型カ行} + ます $\rightarrow$
書き {\scriptsize 基本連用形} ます
\item
長い {\scriptsize イ形容詞型アウオ段} + ます $\rightarrow$
（接続できない）
}

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

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

接続型は，直前の語に適切な活用型・活用形を要求するが，直前の語との間に
境界記号が存在する場合，その要求を透過するか否かは，境界記号に定義される
\textbf{透過性}の定義に従う．ここで，「透過する」
とはその要求を順送りして伝えることを意味し，「透過しない」とはその要求
をそこで棄却することを意味する．Basicパッケージ
($\rightarrow$\S\ref{s:BasicPacakge})では，句読点は，接続要求を透過し
ないと定義している．括弧の類は，透過するものとしないものの両方を定義し
ている．
\eenumsentence{
\item
開括弧 + 書く + 閉括弧 {\scriptsize 透過しない} + ます $\rightarrow$ （書く）ます
\item 
透過開括弧 + 書く + 透過閉括弧 {\scriptsize 透過する} + ます $\rightarrow$ （書き）ます
}

この透過性を，いわゆる取立助詞に対しても定義することによって，次のよう
な取立表現における活用形の自動決定を実現する．
\eenumsentence{
\item
書く + テいる $\rightarrow$ 書いて {\scriptsize テ形} いる
\item
書く + も {\scriptsize 透過する} + テいる $\rightarrow$
書いて {\scriptsize テ形} も いる
}
ここで「テいる」は，前方にテ形を要求する助動詞である．取立助詞は，
この要求を透過するように定義しているので，取立助詞がある場合は，直
前の語ではなく，その前の語を制約することになる．

接続型による活用形の自動決定は，羽織構造の終端ノードと境界記号を線形化
した\textbf{境界・ユニット列}において実行される($\rightarrow$\S\ref{s:BUS})．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{テンス位置の自動決定}

羽織文法は，機能語中心主義を標榜しているが，テンスだけは特別扱いする．
羽織文法の活用体系は，益岡・田窪文法\cite{MTG1992}，および，それに準拠
する
Juman\footnote{\texttt{http://nlp.ist.i.kyoto-u.ac.jp/index.php?JUMAN}}
の活用体系を基本としているため，最終的にテンスは活用形の「タ形」によっ
て表層化される．しかしながら，羽織構造では，テンスをノードの\textbf{テ
ンス属性}として保持する．

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

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

このテンス順送りにも，\textbf{透過性}が定義できる．接続型，テンス順送
り機構，透過性の組み合わせにより，次のような複雑な場合にも，正しい位置
にテンスが設定される．
\enumsentence{
食べる {\scriptsize テンス=タ} + テいる + も {\scriptsize 透過する} +
取立助動詞する + ない \\
$\rightarrow$ 食べて {\scriptsize テ形} い {\scriptsize 基本連用形} も し {\scriptsize 基本連用形} なかった {\scriptsize タ形}
}
なお，「取立助動詞する」は，述語を取り立てるための
専用の助動詞であり，前方の述語に「基本連用形」を要求する．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{活用型の自動推定}
\label{s:活用型の自動推定}

羽織文法では，語を機能語と内容語，活用する語と活用しない語に区分すると
説明した．羽織文法では，品詞は重要ではない($\rightarrow$\S\ref{s:スマホ})
が，わかりやすさのため品詞別
で示すと，表\ref{table:語の分類}のようになる．ここでは，一般の接辞（接頭辞・
接尾辞）は除外した．

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% table 1
\begin{table}[b]
\caption{語の分類}
\label{table:語の分類}
\input{11table01.tex}
\end{table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

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

内容語を表層文字列化するために必要な情報は，次の3つである．
\begin{enumerate}
\item 表記
\item 活用型（活用する語のみ）
\item 活用形（(活用する語のみ）
\end{enumerate}

HB3は，初代のHaori \cite{Sato-NLP2015,Ogata-JSAI2015}と異なり，表記を
制御しない．つまり，どのように表記するかはコード内で記述する．このため，
活用しない内容語に関しては，表層文字列化に必要な情報はコード内に存在す
る．

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

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

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% table 2
\begin{table}[b]
\caption{活用型推定規則の一覧}
\label{tab:活用型推定規則}
\input{11table02.tex}
\end{table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

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

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% table 3
\begin{table}[b]
\caption{活用型の定義が必要な表記数}\label{tab:表記数}
\input{11table03.tex}
\end{table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

動詞と比べて，イ形容詞で定義が必要な表記の割合が多い(8\%)のは，末尾が
「ない」のイ形容詞の活用型を細分化する必要があるからである．羽織文法で
は，次の4種類の活用型が存在する．
\begin{enumerate}
\item イ形容詞型アウオ段 --- 丁寧体の形式は「〜です」．例：「あじけない」
\item イ形容詞型アウオ段ない --- 丁寧体の形式は「ありません」．例：「ない」
\item イ形容詞型アウオ段ない複合 --- 丁寧体の形式は「〜ありません」．例：「思わしくない」
\item イ形容詞型接尾辞ない --- 丁寧体の形式は「〜ません」．例：「いたたまれない」
\end{enumerate}

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

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

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{羽織構造の表層文字列化}
\label{s:BUS}

ここで，羽織構造を表層文字列化する過程について補足しておく．この過程は，
次のように3ステップからなる．
\begin{enumerate}
\item 羽織構造を境界・ユニット構造に変換する．\\
この変換は，終端ノードと境界記号を左から順に集めればよい．ただし，非終
端ノードに付与された属性情報を，適切な終端ノードに継承する必要がある．
原則として，非終端ノードの属性情報は，一番右の子に継承する．これを再帰
的に行えば，終端ノードに到達する．属性情報のうち「左境界」と「右境界」
は，境界記号として実体化する．
\item 境界・ユニット構造において，活用する語の活用形を定める．\\
まず，右から左へ接続型を伝達し，活用する語の活用形を定める．
次に，左から右へ順に，表層文字列を生成する．このとき，テンスが
実体化できなかった場合は，テンスを順送りする．
\item 最後に，
終端ノードと境界記号のそれぞれに対して生成された表層文字列を，一つの文字列に結合する．
\end{enumerate}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{この章のまとめ}

羽織構造は，表層文字列化に必要なすべての情報を保持している．すなわち，
\begin{itemize}
\item 
語の順序情報は，羽織構造の木構造が保持している．
\item 
語の表記，活用型，接続型は，語を表す終端ノードが保持している．
\item
テンス情報は，ノードが保持している．
\item
境界記号の情報は，ノードが保持している．
\end{itemize}
それゆえ，羽織構造が与えられれば，\underline{表層文字列は一意に定まる}．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{ブリックコードとBasicパッケージ}

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{基本的アイディア}

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

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{基本ブリック}

HaoriBrick3 (HB3)の基本ブリックは，6種類しかない．前者が正式名，後者が
別名である．なお，以下の本文中では，ブリックの名称を\brick{ブリック名}
のような記法で記述する．
\begin{enumerate}
\item \brick{lexal}, \brick{lex} --- 羽織構造の終端ノードを作る．内部に語の情報を保持する．
\item \brick{structure}, \brick{構造} --- 羽織構造の非終端ノードを作る．
\item \brick{role}
\item \brick{parameter}, \brick{属性} --- 羽織構造のノードに，属性値を付与する．
\item \brick{boundary}, \brick{境界} --- 境界に記号を挿入する（羽織構造のノードに，境界情報を付与する）．
\item \brick{producer} --- 作り手（書き手・話し手）を指定する($\rightarrow$\S\ref{s:作り手})．
\end{enumerate}

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

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

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{ブリックコードはRubyコード}

次の点を強調しよう．
\begin{quote}
\textbf{ブリックコードは，Rubyコードである}．
\end{quote}
初代のHaori \cite{Sato-NLP2015,Ogata-JSAI2015,Ogata-NLP2016}から
HaoriBricks \cite{Sato-NLP2017,Sato-NLP2018}に進む時点で，ブリックコー
ドというラッパーを導入し，これをプログラム（Rubyコード）として記述するこ
とにしたのだが，結果的に，この選択が非常に大きな恩恵をもたらした．

ブリックコードは，単なるRubyコードであるから，プログラミング言語Rubyの
機能---データ構造，変数，制御構造(if-then-else)---がコード内で自由に利
用できる．このことは，コードを書く際の自由度の向上に，大きく寄与する．

より技術的には，それぞれのブリックは，あるRubyモジュールに定義されたイ
ンスタンスメソッド（ブリックメソッドと呼ぶ）である．ブリックコードの実行
（評価）は，次のような形式で行い，ブリックコードを中括弧の中に記述する．
この中括弧は，プログラミング言語Rubyでブロックと呼ばれるものである．
\begin{lstlisting}
HB3.basic{ 述語(:食べる, を(:りんご)) }
\end{lstlisting}

このブリックコードは，「りんごを食べる」という表層文を生成するためのコードで，
内容語の「食べる」，「りんご」に対応する2つのブリック\brick{:食べる}と
\brick{:りんご}\footnote{Rubyのシンボル（\texttt{:}で始ま
る）は，lexalブリックの略記法である}，および，これらを使って文を組み立
てる2つのブリック\brick{を}と\brick{述語}の，計4つのブリックで記述され
ている．

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

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{マクロブリック}

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

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

たとえば，ブリック\brick{を}は，\brick{格助詞を}の別名である．このブリックは，次
のように定義されている．なお，本論文で示すブリックの定義は，わ
かりやすさを重視するため，実際の定義を簡略化したものを示している．
\begin{lstlisting}
def 格助詞を (*args)
  if args.length == 0 then lex(:格助詞を)
  else
    助詞(lex(:格助詞を), *args)
  end
end
\end{lstlisting}

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

ここで出てくる\brick{助詞}も，マクロブリック\brick{助詞構造}の別名である．
\begin{lstlisting}
def 助詞構造 (lex, arg)
  if !arg then nil
  else
    構造(:助詞構造, lex, arg)
  end
end
\end{lstlisting}

このコードは，第2引数がnilの場合はnilを返し，非nilの場合は\brick{構造}ブリッ
クを作ることを意味している．
値nilは，値がないことを意味する．つまり，第2引数がnilの場合は，構造を
作らない．このような定義により，次のコードは「食べる」のみを出力し，
「を」を実体化しない．
\begin{lstlisting}
x = nil
HB3.basic{ 述語(:食べる, を(x)) }.to_ss          => "食べる"
\end{lstlisting}

値nilをどうハンドリングするかは，ブリックコードの使い勝手を大きく左右
する．変数を用いて，ガ格の内容，ヲ各の内容，述語を外から与えるコードは，
次のようになる．ここで，\texttt{ga}，\texttt{wo}，\texttt{pred}は，
Rubyの変数である．
\begin{lstlisting}
ga = ...
wo = ...
pred = ...
HB3.basic{ 述語(pred, が(ga), を(wo)) }.to_ss
\end{lstlisting}

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

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{ジェネリックブリック}

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

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

次のコードでは，\texttt{pred}は変数であるから，どんな活用型の動
詞が来るかは実行時にならないと定まらない．それゆえ，どちらの接尾辞を接続させるかは，
実行時に決定しなければならい．
\begin{lstlisting}
ga = ...
wo = ...
pred = ...
HB3.basic{ 述語(使役(pred), が(ga), を(wo)) }.to_ss
\end{lstlisting}

HB3では，引数のブリック構造にアクセスする手段を提供しており，これを用
いて\brick{使役}ブリックを作ることが可能である．具体的には，引数のブリッ
ク構造の最も後ろにある語を捕まえて(\texttt{.rightmost\_lexal})，その活
用型(\texttt{.ctype})の値で分岐すればよい．その概略は，次のようになる．
\begin{lstlisting}
def 使役 (arg)
  case arg.rightmost_lexal.ctype
  when /母音動詞型/, /カ変動詞型/ then させる(arg)
  when /子音動詞型/, /ザ変動詞型/, /サ変動詞型/ then せる(arg)
  end
end
\end{lstlisting}

このような，引数のブリック構造を参照して動作を変えるブリックを
\textbf{ジェネリックブリック}と呼ぶ．上記の\brick{使役}は，
使役の接尾辞を付与するという機能を担うという意味で汎用的である
\footnote{このブリックは，動詞型活用の語に「させる・せる」のいず
れかを接続するだけで，述語構造の格助詞を書き換えること（ボイス変換）はし
ない．}．先に示した，図\ref{fig:process}のブリックコードでは，\brick{丁寧}と
\brick{ます}がジェネリックブリックである．

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Basicパッケージ}
\label{s:BasicPacakge}

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

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% table 4
\begin{table}[t]
\caption{Basicパッケージに含まれるブリック数}
\label{tab:basicPackage}
\input{11table04.tex}
\end{table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

この表において，左欄が羽織文法の骨格をサポートするためのブリック，中欄
が具体的な語や表現に対応するブリック（機能語，複合辞，慣用句のサポート），
右欄がそれ以外のマクロブリックとジェネリックブリックである．この表に示
すように，従属節をサポートするためのブリック($\rightarrow$\S\ref{s:節})が
非常に多い．

なお，Basicパッケージの編纂では，
『基礎日本語文法―改訂版―』\cite{MTG1992}に掲載されている
番号付きの全例文（1,177例文）\footnote{（ア)のように，カタカナ付き例文は対象としていない．}
を利用し，これらの例文を生成するコードを比較的容易に記述できるようにブリックを定義した．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{この章のまとめ}

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{HaoriBricks3の使用例}

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{複文を作る}
\label{s:節}

日本語の長い文の大半は，複数の節から構成される複文である．
以下に例を示す．
\eenumsentence{
\item
音楽を聴きながら論文を書く．
\item 
論文を書く．\ \ \ (主節)
\item
音楽を聴きながら \ \ \ \ \ (連用節ながら)
}

HB3のBasicパッケージに含まれている従属節を作るブリックを使えば，
単文から複数を合成するのは容易である．
\begin{lstlisting}
m = HB3.basic{ 述語(:書く, を(:論文)) }
c = HB3.basic{ 述語(:聴く, を(:音楽)) }
HB3.basic{ 連用節ながら(c, m) }.to_ss     => "音楽を聴きながら論文を書く"
c2 = HB3.basic{ 連用節ながら読点(c) }
HB3.basic{ 修飾(c2, m) }.to_ss            => "音楽を聴きながら，論文を書く"
\end{lstlisting}

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

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

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% table 5
\begin{table}[t]
\caption{従属節を作るブリックの一覧}
\label{tab:従属節一覧}
\input{11table05.tex}
\end{table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

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

一般に，節末形式が名詞を持つ場合，連体修飾を受けることができることが多
い．これを従属節と同じように記述できるように，\brick{〜句〜}というブリック
も定義されている．
\eenumsentence{
\item
小説を書く\underline{とき} \ \ \ ― \ \ \ \texttt{時間節とき(述語(:書く, を(:小説)))}
\item
小説執筆の\underline{とき} \ \ \ ― \ \ \ \texttt{時間句のとき(:小説執筆)}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% fig. 2
\begin{figure}[t]
\begin{center}
\includegraphics{27-2ia11f2.eps}
\end{center}
\caption{緒方健人『スマホが震えた』}
\label{fig:sumaho}
\end{figure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% fig. 3
\begin{figure}[p]
\setlength{\unitlength}{1pt}
\begin{picture}(420,494)
\put(-23,0){\includegraphics{27-2ia11f3.eps}}
\end{picture}
\caption{『スマホが震えた』を生成するHB3ソースコード}
\label{fig:sumaho_code}
\end{figure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{『スマホが震えた』を生成する}\label{s:スマホ}

HB3のコード記述例として，小説の自動制作を目指すプロジェクトの初期の段
階で，プロジェクトメンバーの一人が書いたサンプル小説『スマホが震えた』
の全文（図\ref{fig:sumaho}）を生成するコードを図\ref{fig:sumaho_code}に示す．
以下では，このコードを解説する．
\begin{itemize}
\item 
HB3には，単に要素を並べるだけの\brick{列構造}が存在するので，これを利用す
れば，文だけでなく，文章を組み立てることができる．ブリック\brick{テキスト}，
\brick{段落}，\brick{発話段落}は，\brick{列構造}を利用している．
\item
ブリック\brick{判定詞省略}は，いわゆる体言止めを生成するためのブリック
である．そのままでは判定詞は表層化されないが，たとえば\brick{テ節}に接
続すると，「深夜一時頃\underline{で}」のように，背後に隠れている判定詞
が出現する．
\item
地の文は，複文になることが多い．\brick{並列節が読点}，\brick{連用節ながら読点}，
\brick{条件節と読点}などは，従属節を作り，主節に結合するブリックである($\rightarrow$\S\ref{s:節})．
実際のコード作成では，従属節を簡単に作れることが非常に重要である．
\item
いわゆる提題表現は，\brick{提題}ブリックを使って述語構造の外に書いても
いいし，\brick{述語}の中に書いてもよい．前者の場合は修飾構造が作られ，
後者はいわゆる格要素と同じ扱いとなる．
\item
複合名詞は，\brick{複合語}ブリックを使って合成してもよいし，一語として
記述してもよい．前者の場合は，複合語の構成要素が部品となる（つまり，置
換可能となる）が，後者の場合は，全体が部品となる．
\item
イ形容詞「大きい」は，連体修飾用法では「大きな {\scriptsize ナ形}」が優勢である．
ブリック\brick{形容詞}は第1引数が形容詞であることを，\brick{連体修飾}
は第1引数が第2引数を連体修飾することを意味している．なお，「大きな」
は，「目が大きな少女」のように格要素を取りうるので，連体詞とみなすので
はなく，イ形容詞のナ形とみなすのがよいと考える．
\item
ブリック\brick{発話}は，発話形式のためのブリックで，発話文を鉤括弧で囲む．
\item
ブリック\brick{お〜ください}は，動詞「待つ」から丁寧な表現「お待ちくだ
さい」を作るブリックである．この「ください」は「お〜・ご〜」の形式のみに
接続する述語接尾辞（「敬語接尾辞ください」）である．
\item
「レポートが進みやしない」は，「（レポートが）進まない」という述語表現を，
「副助詞や」で取り立てた表現とみなす．この取立表現を組み立てる方法は，
このコード例にもいくつか方法がある．なお，述語の取立表現には不明な点が
多い．たとえば，イ形容詞「造作ない」の取立表現は「造作もない」だと思わ
れるが，「いたたまれない」は取り立てることができないように思われる．こ
のような現象には，まだ対応できていない．
\item
「スマホ越し\underline{に}呟く」の「に」は，何助詞とすべきかよくわから
ない．暫定的に「連用助詞に」に分類している($\rightarrow$\S\ref{s:助詞})．
\item
「それ以来」も謎である．現在は，暫定的に\brick{複合語}ブリックを使って
いるが，この解釈でよいかどうか自信がない．すでに述べたように，名詞を持
つ節末形式は，連体修飾を受けることができる場合が多い．
\eenumsentence{
\item
小説を書く\underline{とき}
\item
小説執筆の\underline{とき}
\item
その\underline{とき}
}
しかしながら，「以来」は連体修飾を受けることはできず，
代名詞は連体形ではなく名詞形が接続する．
\eenumsentence{
\item
小説を書いて\underline{以来}
\item
*小説執筆の\underline{以来}
\item
*その\underline{以来}
\item
それ\underline{以来}
\item
小説執筆\underline{以来}
}
\end{itemize}

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

さらに，次の3点を付け加える．
\begin{itemize}
\item
このコードでは，内容語はRubyのシンボル（つまり，\brick{lexal}）で記述
され，それ以外は，他のブリックで記述されていることに気づく．つまり，
\brick{lexal}以外のブリックで構成される部分が，文を成り立たせる骨格で
あり，羽織文法が規定しているのは，主に，この部分である．

\item
このコードでは，品詞ブリックがほとんど出現しない．\brick{形容詞}と\brick{接続詞}
が若干出現するだけである．その理由は，次のとおり．
\begin{itemize}
\item
活用する内容語は，裸の連体修飾の場合を除き，述語構造をもつ．ブリック
\brick{述語}は，第1引数を述語と解釈して活用型推定を行うので，動詞・形
容詞を明示的に指定する必要がない．
\item
活用しない内容語は，構造だけが問題となるが，それはほとんどの場合，「修
飾構造(binary\_l)」である．ブリック\brick{連体詞}，\brick{副詞}，\brick{接続詞}，
\brick{感動詞}は，いずれも2引数の場合はブリック\brick{修飾}と等価である\footnote{1引数の場合は，その語を生成する．}．つまり，これらの品詞の区別は，羽織文法では本質的
でない．
\end{itemize}
\item
このコードを構成するすべての部品（ブリック）は，\underline{変数化でき
る}（コードの外から指定可能である）．このコードでは，登場人物の名前だけ
を変数化して外から与えているが，すべての内容語も同じように変数化するこ
とができる．それ以外のブリックも，単なるRubyメソッドコールであるから，
sendを使えば変数化できる．これが，「ブリックコード=Rubyコード」の威力
である．
\end{itemize}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{発話を作る}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{発話文体を切り替える}

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

たとえば，「フランス語を教えてほしい」という依頼を表明する場合，
どのような文体を用いるかによって，読者が感じる発話者のイメージが異なる\cite{Kinsui2003}．
\eenumsentence{
\item
フランス語を教えろよ（命令形+終助詞よ）--- 粗野な男性
\item
フランス語を教えてくださらない？（テくださる+ない+疑問符）--- 上品な女性
\item
フランス語を教えてちょうだい（テちょうだい）--- 幼い（あるいは，甘えた）感じ
}

これらは，主に，文末表現の違いによってもたらされる．すなわち，これらの
文末表現をブリックとして定義し，それらのうちのひとつを選択して，命題的
表現（「フランス語を教える」）に結合すれば\cite{Kimura-JSAI2018}，読者が感じる発
話者のイメージを操作できる．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{発話者を切り替える}
\label{s:作り手}

さらに，HB3の基本ブリックのひとつに，文や発話の作り手を明示的に指定す
る\brick{producer}ブリックがあり，その指定に従って表現を切り替える仕組
みが組み込まれている．具体的には，ブリック構造から羽織構造を生成する際
に，個別の作り手に対して定義されたフィルタを通すことにより，表現を切り
替える．以下に，一例を示す．この例では，作り手「コナン」に対して定義し
たフィルタを使って，「〜しかない」という表現を「〜っきゃねぇ」という表
現に置き換えている．
\begin{lstlisting}
x = HB3.basic{ しかない(述語(:食べる)) }
y = HB3.basic{ producer(:コナン, x) }
x.to_ss       => "食べるしかない"
y.to_ss       => "食べるっきゃねぇ"
\end{lstlisting}

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{文末を書き換える}
\label{sec:rewrite}

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{ウィキペディア文を，話し言葉に適した形式に変換する}
\label{s:話し言葉への変換}

三宅宏実選手のウィキペディアの記事には，「趣味は足のネイルアート」とい
う文が存在する．この文を，ソフトウェアエージェントに発話させることを想
定し，話し言葉に適した文[\ref{e:話し言葉変換}]に変換する．
\eenumsentence{
\item
趣味は足の\underline{ネイルアート}．
\item
\brick{:ネイルアート} + \brick{だ} + \brick{伝聞そうだ} + \brick{丁寧}
\item \label{e:話し言葉変換}
三宅選手の趣味は足の\underline{ネイルアートだそうです}．}

この例の場合，元の文の文末として「ネイルアート（体言止め）」を同定し，そ
れに\brick{だ}，\brick{伝聞そうだ}\footnote{「そうだ」には，「（書き）そ
うだ」と「（書いた）そうだ」がある．羽織文法の機能語IDは，前者は「様相
接尾辞そうだ」，後者は「終タ助動詞そうだ」である．ブリックコードでは，
それぞれ，\brick{接尾辞そうだ}，\brick{伝聞そうだ}と記述することが多い．
どちらも動詞型活用に接続可能なので，ジェネリックブロックを定義して自動
判定することはできない．}，\brick{丁寧}という3つのブリックを付加することで，
所望の文を作り出す．ただし，文頭の「三宅選手の」は，別の方法で補完する\cite{Yanagi2020}．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{広告文の生成で，症状を問いかけ形式に変換する}
\label{s:問いかけ変形}

広告文では，読者に働きかける表現が多用されるが，そのひとつに問いかけ形
式がある．たとえば，「腰が痛い」という症状を問いかけ形式に変換すること
は，以下に示すように，述語「痛い」に，\brick{は}，\brick{取立助動詞あ
る}，\brick{か}，\brick{丁寧}という4つのブリックを付加すれば実現できる\cite{Taira2019}．
\eenumsentence{
\item
腰が\underline{痛い}
\item
\brick{述語(:痛い)} + \brick{は} + \brick{取立助動詞ある} + \brick{か} + \brick{丁寧}
\item
腰が\underline{痛くはありませんか}
}
なお，取立助動詞とは，すでに述べたように，
述語の取立形式を作るための専用の助動詞である．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{議論}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{卵が先か，にわとりが先か}

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

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

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

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{ジェネリックブリックによる文法の隠蔽と高機能化}

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

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

たとえば，羽織文法では，4種類の「ない」が存在する．
\begin{enumerate}
\item
イ形容詞の「ない」．例：暇もお金も\underline{ない}
\item
否定接尾辞の「ない」．動詞型活用に接続する．例：食べ\underline{ない}，食べさせ\underline{ない}
\item
テ助動詞の「ない」．「〜テいない」の「い」が脱落した形式．
例：論文を書いて\underline{ない}
\item
取立助動詞の「ない」．形容詞の否定取立表現を作る．
例：美しくも\underline{ない}，確実では\underline{ない}
\end{enumerate}

生成という立場に立てば，上記の4種類の「ない」の振る舞いはそれぞれ異な
るので，これらを区別することは必然である．しかし，ユーザーに，これらを
適切に使い分けることを求めることはできないであろう．

ジェネリックブリックは，このような使い分けの困難さを軽減する役割を果た
している．たとえば，ジェネリックブリック\brick{ない}には，次のような使
い分けの自動判定が組み込まれている\footnote{簡略化して記述した．実際の処理は，かなり複雑である．}．
\begin{enumerate}
\item
引数がない場合は，「イ形容詞ない」と判定する．
\item
イ形容詞型，判定詞型の活用に接続する場合は，「取立助動詞ない」と判定する．
\item
動詞型の活用に接続する場合は，「否定接尾辞ない」と判定する．
\end{enumerate}
それゆえ，この\brick{ない}と，そこではハンドリングできない\brick{テ助
動詞ない}の2つのブリックを使い分ければよい\footnote{動詞型の活用には，
「否定接尾辞ない」と「テ助動詞ない」の両方が接続可能である．}．

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

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{文合成の言語依存性}
\label{sec:language_dependency}

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

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

HB3がこのような形となったのは，対象言語が日本語であるということと，あ
らゆる文が想定されうる小説の自動制作が最終ゴールであるということによる．
HB3のアーキテクチャは，日本語以外の言語の文合成にも適用できるとは思わ
れるが，それぞれの言語の文法に即したアーキテクチャを考える方が建設的であろう
\footnote{文合成システムを突き詰めれば，文をどのようにモデル
化するか，すなわち，文法体系に行き着く．文合成システムの実装と
は，機械的に実行可能な文法体系の提案とほぼ同義である．}．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{何が達成できれば完成なのか}

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

羽織シリーズの最初の版に比べて，文を合成するために記述しなければならな
い記述量は，格段に減少した．さらに，マクロブリックとジェネリックブリッ
クを多数定義することによって，実際に記述するブリックコードも短くなり，
かつ，羽織文法をそれほど意識しなくても書けるようになってきている．それ
でも，コードを書かなければならないことには変わりはない．

試験的に実装した\textbf{羽織テンプレート}は，ブリックコードを書く代わ
りに，文字列に若干のアノテーションを付加することで，自動的にブリックコー
ドを生成する仕組みである．たとえば，以下の1行目の文字列は，2行目のコー
ドに自動変換されるので，3行目のような生成が可能である．
\begin{lstlisting}
template = "{りんご}を{食べる}"
lambda{|args| HB3.basic{ 述語((args[:食べる] || :食べる), を(args[:りんご] || :りんご)) }}
g(:タ, template, { 食べる: :買う }).to_ss    => "りんごを買った"
\end{lstlisting}

ここで，\texttt{args[:食べる]}は，\texttt{args} （Hashオブジェクト）にア
クセスするRubyコードなので，その値が定義されていれば，その値が使われる．
つまり，このテンプレートで，「〜を〜」というあらゆる表現が生成できる．
羽織テンプレートでは，中括弧で括られた部分がテンプレートのスロットで，
その中身がデフォールトのフィラーとして解釈される．こ
のテンプレートはブリックコードに変換されるので，\brick{タ}のようなブリッ
ク\footnote{メソッド\texttt{g}の第1引数の「\texttt{:タ}」は，
\brick{lexal}ではなく，1引数のブリックと解釈される．}が結合可能である．

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

記述量を究極まで減らす方法は，文字列として記述した文を，ブリックコード
に変換する方法である．しかし，その実現には，背後で形態素解析や構文解析
を動かさなければならなず，解析誤りが混入する可能性を排除できない．ただ
し，文末のみが正しく解析できればよいと割り切れば，この方法も現実的な選
択肢に入ってくる\cite{Sano2020}．\ref{sec:rewrite}節
の具体例は，この方法で実装している．

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{おわりに}
\label{sec:conclusion}
 
本稿では，日本語文を合成するためのドメイン特化言語HaoriBrick3 (HB3)の
設計思想と実現・実装のための工夫，および，HB3の利用例について述べた．

最後に，HB3に至る羽織シリーズの開発を通して明らかになったと私が考えて
いるのことを，以下に示す．
\begin{itemize}
\item
これまでの文法は，文の解析，すなわち，「実際に存在する文の構造（や意味）
をどう解釈するか」に焦点があった．日本語文の機械的合成のための文法は，
解析のための文法とは異なる様相を呈する．たとえば，品詞は重要ではなく，
活用型の方がより重要である．文節係り受け構造よりも，羽織構造のような構
造の方が適している．
\item
日本語の文合成のための文法の中核は，機能語（表現）を列挙し，それぞれの機
能語の働きを明らかにすることに帰着できる．明らかにしなければならない機
能語の数（オーダー）は，数千である．日常的に使われる書き言葉の範囲であれ
ば，2,000程度に収まるだろう．
\item
日本語文を構成する要素の中で，特に複雑な部分は，(1)述語の形式（述語接尾
辞・助動詞の付与），(2)従属節の節末形式，(3)とりたて，(4)敬語表現，であ
る．
\item
実際に文を合成する際には内容語が必要となるが，HB3では，それが内容語で
あるとわかれば十分である．つまり，内容語の辞書を用意する必要はない．こ
のことは，個別アプリケーション用の文合成コードを書く際に，非常に大きな長所（省力化）となる．
\end{itemize}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\acknowledgment

本稿の
\ref{sec:language_dependency}節と第\ref{sec:conclusion}章，付録\ref{sec:変遷}は，
査読者の提案により追加した．
有益な提案に感謝する．

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% \bibliographystyle{jnlpbbl_1.5}
\begin{thebibliography}{}

\bibitem[\protect\BCAY{Braun, Klimt, Schneider, \BBA\ Matthes}{Braun
  et~al.}{2019}]{braun-etal-2019-simplenlg}
Braun, D., Klimt, K., Schneider, D., \BBA\ Matthes, F. \BBOP 2019\BBCP.
\newblock \BBOQ SimpleNLG-DE: Adapting SimpleNLG 4 to German.\BBCQ\
\newblock In {\Bem Proceedings of the 12th International Conference on Natural
  Language Generation}, \mbox{\BPGS\ 415--420}.

\bibitem[\protect\BCAY{CoGenTex Inc.}{CoGenTex Inc.}{2000}]{RealPro}
CoGenTex Inc. \BBOP 2000\BBCP.
\newblock {\Bem {\sc RealPro} General English Grammar User Manual}.

\bibitem[\protect\BCAY{Gatt \BBA\ Reiter}{Gatt \BBA\
  Reiter}{2009}]{gatt-reiter-2009-simplenlg}
Gatt, A.\BBACOMMA\ \BBA\ Reiter, E. \BBOP 2009\BBCP.
\newblock \BBOQ SimpleNLG: A Realisation Engine for Practical
  Applications.\BBCQ\
\newblock In {\Bem Proceedings of the 12th European Workshop on Natural
  Language Generation (ENLG 2009)}, \mbox{\BPGS\ 90--93}.

\bibitem[\protect\BCAY{木村\JBA 夏目\JBA 佐藤\JBA 松崎}{木村 \Jetal
  }{2018}]{Kimura-JSAI2018}
木村遼\JBA 夏目和子\JBA 佐藤理史\JBA 松崎拓也 \BBOP 2018\BBCP.
\newblock 発話表現文型辞書を利用した多様な発話文生成機構.\
\newblock \Jem{2018 年度人工知能学会全国大会（第32回）}, \mbox{2E2--02}.

\bibitem[\protect\BCAY{金水}{金水}{2003}]{Kinsui2003}
金水敏 \BBOP 2003\BBCP.
\newblock \Jem{ヴァーチャル日本語　役割語の謎}.
\newblock 岩波書店.

\bibitem[\protect\BCAY{益岡\JBA 田窪}{益岡\JBA 田窪}{1992}]{MTG1992}
益岡隆志\JBA 田窪行則 \BBOP 1992\BBCP.
\newblock \Jem{基礎日本語文法―改訂版―}.
\newblock くろしお出版.

\bibitem[\protect\BCAY{日本語記述文法研究会}{日本語記述文法研究会}{2003--2010}]{GendaiNihongoBunpou}
日本語記述文法研究会\JED\ \BBOP 2003--2010\BBCP.
\newblock \Jem{現代日本語文法（全 7 巻）}.
\newblock くろしお出版.

\bibitem[\protect\BCAY{緒方\JBA 佐藤\JBA 松崎}{緒方 \Jetal
  }{2015}]{Ogata-JSAI2015}
緒方健人\JBA 佐藤理史\JBA 松崎拓也 \BBOP 2015\BBCP.
\newblock 文節木の段階的実体化による日本語文生成器の作成.\
\newblock \Jem{2015 年度人工知能学会全国大会論文集}, \mbox{3M3--1}.

\bibitem[\protect\BCAY{緒方\JBA 佐藤\JBA 松崎}{緒方 \Jetal
  }{2016}]{Ogata-NLP2016}
緒方健人\JBA 佐藤理史\JBA 松崎拓也 \BBOP 2016\BBCP.
\newblock 日本語文生成器 Haori における複文合成.\
\newblock \Jem{言語処理学会第 22 回年次大会発表論文集}, \mbox{\BPGS\ 334--337}.

\bibitem[\protect\BCAY{Perrotta}{Perrotta}{2015}]{metaprogramming}
Perrotta, P. （角征典 訳）\BBOP 2015\BBCP.
\newblock \Jem{メタプログラミング Ruby 第 2 版}.
\newblock オライリー・ジャパン.

\bibitem[\protect\BCAY{Reiter \BBA\ Dale}{Reiter \BBA\ Dale}{2000}]{Reiter}
Reiter, E.\BBACOMMA\ \BBA\ Dale, R. \BBOP 2000\BBCP.
\newblock {\Bem Building Natural Language Generation Systems}.
\newblock Cambridge University Press.

\bibitem[\protect\BCAY{佐野\JBA 佐藤\JBA 宮田}{佐野 \Jetal }{2020}]{Sano2020}
佐野正裕\JBA 佐藤理史\JBA 宮田玲 \BBOP 2020\BBCP.
\newblock 文末述語における機能表現検出と文間接続関係推定への応用.\
\newblock \Jem{言語処理学会第 26 回年次大会発表論文集}, \mbox{\BPGS\ 1483--1486}.

\bibitem[\protect\BCAY{佐藤}{佐藤}{2015}]{Sato-NLP2015}
佐藤理史 \BBOP 2015\BBCP.
\newblock 「文生成器を作る」とはどういうことか.\
\newblock \Jem{言語処理学会第 21 回年次大会発表論文集}, \mbox{\BPGS\ 1080--1083}.

\bibitem[\protect\BCAY{佐藤}{佐藤}{2016}]{Sato2016}
佐藤理史 \BBOP 2016\BBCP.
\newblock \Jem{コンピュータが小説を書く日}.
\newblock 日本経済新聞出版社.

\bibitem[\protect\BCAY{佐藤}{佐藤}{2017}]{Sato-NLP2017}
佐藤理史 \BBOP 2017\BBCP.
\newblock HaoriBricks: ブロック玩具に学ぶ日本語文章生成ライブラリ.\
\newblock \Jem{言語処理学会第 23 回年次大会発表論文集}, \mbox{\BPGS\ 20--23}.

\bibitem[\protect\BCAY{佐藤}{佐藤}{2018}]{Sato-NLP2018}
佐藤理史 \BBOP 2018\BBCP.
\newblock 述語取り立て形式の整理と文生成器への実装.\
\newblock \Jem{言語処理学会第 24 回年次大会発表論文集}, \mbox{\BPGS\ 53--56}.

\bibitem[\protect\BCAY{平良\JBA 佐藤\JBA 宮田\JBA 今頭}{平良 \Jetal
  }{2019}]{Taira2019}
平良裕汰朗\JBA 佐藤理史\JBA 宮田玲\JBA 今頭伸嘉 \BBOP 2019\BBCP.
\newblock ダイレクト広告コピー文の分析と自動生成.\
\newblock \Jem{言語処理学会第 25 回年次大会発表論文集}, \mbox{\BPGS\ 406--409}.

\bibitem[\protect\BCAY{柳\JBA 佐藤}{柳\JBA 佐藤}{2020}]{Yanagi2020}
柳将吾\JBA 佐藤理史 \BBOP 2020\BBCP.
\newblock ウィキペディアから抽出した人物エピソードの話し言葉への変換.\
\newblock \Jem{言語処理学会第 26 回年次大会発表論文集}, \mbox{\BPGS\ 437--440}.

\end{thebibliography}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\appendix

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{羽織文法に関する補足}
\label{s:羽織文法補足}

羽織文法の定義にあたっては多くの資料を参照したが，特に参考にしたのは，
益岡・田窪文法\cite{MTG1992}と『現代日本語文法1--7』\cite{GendaiNihongoBunpou}である．


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{活用体系}

羽織文法の活用体系は，益岡・田窪文法，および，
Jumanの活用体系に準拠している．それらからの大きな変更点は，次の2点であ
る．
\begin{enumerate}
\item 列活用を考えない（廃止する）
\item 末尾が「ない」のイ形容詞の活用型を細分化する
($\rightarrow$\S\ref{s:活用型の自動推定})
\end{enumerate}

羽織文法では，判定詞は「だ」のみを認め，「である」と「です」は，それぞ
れ，次のようにみなす．
\begin{description}
\item[である] 「判定詞だ」のテ形「で」に，「取立助動詞ある」が接続したもの
\item[です] 「判定詞だ」のダ消失形に，「丁寧接尾辞です」が接続したもの
\end{description}

「である」の形式は，「で\underline{は}ある」，「で\underline{も}ある」
のように，いわゆる取立助詞の挿入が可能である．この形式と，取立助詞の挿
入がない形式との一貫性を重視し，「デアル列」とはみなさない．

「です」の形式は，それほど強い理由がないが，列活用の存在は活用体系を複雑化するので，
これも「デス列」とみなさい．

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{機能語}

羽織文法の中核を担うのは，機能語のリストである．羽織文法では，
\underline{機能語はすべて列挙する}．
機能語の一覧を表\ref{tab:機能語1}と表\ref{tab:機能語2}に示す．機能語は，大き
く，活用しない助詞と，活用する判定詞，助動詞，述語接尾辞に分けられる．

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% table 6
\begin{table}[b]
\caption{羽織文法の機能語一覧(1)活用しない機能語}
\label{tab:機能語1}
\input{11table06.tex}
\end{table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% table7
\begin{table}[t]
\caption{羽織文法の機能語一覧(2)活用する機能語}
\label{tab:機能語2}
\input{11table07.tex}
\end{table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

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

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{助詞}
\label{s:助詞}

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

\begin{enumerate}
\item
引用助詞引用を表す助詞で，その代表格は「と」である．
\item
並列助詞 --- 並列構造を作る助詞で，その代表格は「と」や「や」である．
\item 
連体助詞 --- 連体修飾を構成する助詞で，その代表格は「の」である．
\item
疑問助詞 --- 「か」と「かどうか」を終助詞から分離したものである．
\item
連用助詞 --- よくわからない（判定詞由来と考えられる）「に」と「で」を便宜
的に収容するために設けたもの($\rightarrow$\S\ref{s:スマホ})で，この2語のみである．
\end{enumerate}

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{判定詞}

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{助動詞}

助動詞は，次のように細分類する．
\begin{enumerate}
\item 終止助動詞 --- 終止形に接続する助動詞
\item 終タ助動詞 --- 終止形・タ形に接続する助動詞．
\item 連体助動詞 --- 連体修飾の形式に接続する助動詞．
\item 丁寧助動詞 --- 丁寧体を作る助動詞．
\item テ助動詞 --- 直前の述語にテ形を要求する．直前に取立助詞の挿入を許す．
\item タリ助動詞 --- 直前の述語にタリ形を要求する．
\item 取立助動詞 --- 述語の取立形式を作る助動詞．直前に取立助詞の挿入を許す．
\item 連用助動詞 --- 「連用助動詞ござる」のみ．「〜にござる・ございます」の形式を作る．
\end{enumerate}

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{述語接尾辞}

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

述語接尾辞は，次のように細分類する．
\begin{enumerate}
\item ボイス接尾辞 --- ボイスに関わる接尾辞．「れる」，「られる」など．
\item 否定接尾辞 --- 否定に関わる接尾辞．「ない」，「ぬ」など．
\item 可能接尾辞 --- 可能に関わる接尾辞．「できる」，「うる」など．
\item テ縮約接尾辞 --- テ形が縮退した形式をとる接尾辞．「ちまう」など．
\item 意志接尾辞 --- 「（書か）ん」のみ．
\item 相接尾辞 --- アスペクトに関わる接尾辞．「（殴り）かかる」，「（書き）かける」．
\item 様相接尾辞 --- 動詞に接続し，ある種の様相を表す接尾辞．「たい」，「すぎる」など．
\item 丁寧接尾辞 --- 丁寧形に関わる接尾辞．「です」，「ます」など．
\item 敬語接尾辞 --- 敬語表現に関わる接尾辞．「くださる」，「なさる」など．
\item 特殊接尾辞 --- 「や」のみ．（判定詞・ナ形容詞のいわゆるヤ列）
\item 述語性接尾辞 --- 述語を作る接尾辞．「する」，「的だ」など．
\end{enumerate}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{接続型}

接続型の枠組みは確立されているが，具体的な接続型の定義は，いまだに発展
途上にある．現時点では，89種類の接続型が定義されているが，安定状態には
ほど遠く，問題が生じるたびに修正を繰り返している．その理由は，次の2つ
である．
\begin{itemize}
\item 接続型という概念自身が新規なため，まとまった資料が存在しない．
\item 機能語の振る舞いは，それぞれ微妙に異なることが多い．
\end{itemize}

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{羽織シリーズの変遷}
\label{sec:変遷}

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


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{biography}
\bioauthor{佐藤　理史}{%
1988年京都大学大学院工学研究科博士後期課程研究指導認定退学．京都大学工
学部助手，北陸先端科学技術大学院大学情報科学研究科助教授，京都大学情報学研究科助教授
を経て，2005年より名古屋大学大学院工学研究科教授．博士（工学）．
本学会，人工知能学会，情報処理学会，日本認知科学会，ACM各会員．}
\end{biography}

\biodate





\clearpage




\clearpage



















\end{document}

