KAWARI Phase8 : KIS Programming Reference

1. 華和梨とは何か？

華和梨は、生まれた当初は互換栞、現在は栞サブシステムと呼ばれる存在である。しかし、華和梨が真に目指している目標は、栞として優れていることだけではなく、 DA(Desktop Agent)記述方式として優れていること、もしくは、優れた方式を見いだすためのステップとしてあることである。

1.1. 基本概念

華和梨という概念の基本は、「何か。」用SHIORI(もしくは偽AI)としての機能には直接依存しない、極めて簡素な、一種の思想である。その骨子は以下のようなルールで説明することができる。

幾つかの文字列(単語、ネタ、KISプログラムなど)をグループ化してグループ名を付ける。グループのことを「エントリ」、グループ名のことを「エントリ名」と呼ぶ。
エントリ１ : 単語１, 単語２
エントリ２ : 華和梨の梨はgoogleで引くと３番目に引っかかる梨……"(鬱)"
文字列の中に、エントリ呼び出し機能を含めることが出来る。「${対象エントリ}」が、基本的なエントリ呼び出しの書き方である。
＜${エントリ１}＞は、単語１か単語２
エントリ呼び出しが行われると、エントリに含まれている文字列のうちのどれか一つがランダムに選ばれ、呼び出し結果として返る。
「＜${エントリ１}＞は、単語１か単語２」を評価(=実行) →
＜単語１＞は、単語１か単語２
　　or
＜単語２＞は、単語１か単語２
選ばれた文字列のなかに、再び「${対象エントリ}」などのエントリ呼び出しがあった場合、さらにもう一度エントリ呼び出しが行われ、その結果がエントリ呼び出し記述と置き換えられる。
エントリ３：＜${エントリ１}＞は、単語１か単語２

「『${エントリ３}』は常に正しい。」を評価 →
(1) 「＜${エントリ１}＞は、単語１か単語２」は常に正しい。
さらにエントリ１を呼び出し、「${エントリ１}」の部分と置き換える。
(2) 「＜単語１＞は、単語１か単語２」は常に正しい。
それ以上置き換えが行われなくなったところで、最終的な結果となる。
華和梨の機能は、任意の名前のエントリを呼び出すことでキックされる。例えば「何か。」本体からイベントリクエストが行われた場合、 System.Callback.OnEventエントリが呼び出され、その結果が本体へのレスポンスとなる。

何度も辞書を引き直す (ここではエントリ名に対応する文を探すことを、辞書を引く、と呼んでいる) ことで実現されるこの多段連想配列的機能は、最も初期の華和梨関係者の一人によって「逆yacc」と命名された。 yaccを初めとするパーサジェネレータは、ある言語で記述された文章(大抵はプログラムである)を、その言語の文法に従って分解するモジュールを、特定の(大抵はBNFライクな)表記法によって表された文法自体から生成する。言い換えれば、「様々な文章を一つの文法に落とし込むもの(を作るもの)」である。

華和梨は逆に「一つの文法から様々な文章を生成するもの」である。「文法的に正しい(この場合、文法は日本語文法を指すとは限らない)」文章を簡単に、ランダムに、大量に作り出すために逆yacc機能は存在する。

下記の例のとおり、「文法」はエントリ呼び出しによって定義される。

食べ物 : ${固有人名}が作ったアレ, きのこ, ワッフル, カレー, アイス, ジャム
地名 : 東京 , 秋葉原 , 浅草
固有人名 : ぐにゅう、うにゅう、うにゅん、ほねゅう
人名 : ${地名}に住んでる${固有人名}

# 簡易うわさ話１
sentence : \0${人名}ってさ、${食べ物}が好きなんだって。\n\1ふーん。\n\0もう少し、なんか言えよう…\e

もっとも量的な側面は現状は決して満足できるものではない。仮にDAを1日3時間起動し、1分に1度喋らせ、その文章が1ヶ月の間重複を起こさないためには、最低でも5400本もの異なる文章を生成しなければならない(一ヶ月間に！)。また文章生成ルールの単純さは語るまでもなく、これが一種の「面白さ」を演出してはいるものの、 DAをそのスタイルに画一化してしまう働きがある。質・量の不足(＝飽き)に対して、ユーザは、ゴーストを切り替えるなどの方法で対応しているが、単体のゴーストについても逆yacc以上のものが求められている。

1.2. 何が華和梨を難しくさせているか

こうしたシンプルな概念を基礎とするにも関わらず、華和梨が難しいSHIORIであるのは何故か。それは、「歴史的経緯による整理不足」と「中途半端な記述力」のためである。

華和梨は元々、魅力的なプラットフォームとなりうる素質を持ちながら、クローズドな状態のまま開発停止してしまった「あれ以外の何か with 偽春菜」 (後に「あれ以外の何か with "任意"」、「何か。」、「伺か。」) を生き延びさせること(だけ)を目的に開発された。華和梨のソースが、コア350行、SHIORIインターフェース250行であった古き良き時代 (ちなみに現在は総計8000行に達している)、 SHIORIに求められる機能は事実上ただ一つ、「自発トークの際の文章を生成すること」のみであった。華和梨は「sentence」エントリを呼び出すだけで良かったのである。そのためMeisterは以下のような意図をもって華和梨を作成した。

華和梨の当初の目標は「最小コストで最大効果のランダムトークエンジンを最短期間で実装する」というものでした。

Meister :KIS Programming Language Chapter-0

見通しが良くコンパクトな設計を持った華和梨は各種のプラットフォームに移植され、最も移植性の高いSHIORIともなった。

しかし、DAに当然求められる機能を追及したとき、 (偽)AI部が担うべき作業がランダムトークだけで済むはずがなく、また、済むべきではないと、本体サイドも華和梨サイドも承知していた。華和梨にとっては、イベント反応とランダムトークを、まったく同じ枠組みで扱えることが一つの強みだった。つまり、「どんなイベントが来ようとも、最初に呼び出すエントリの名前が変わるだけ」ということである。

その後、後から振り返れば史上最も混乱した一ヶ月半が訪れた。本体は、dllのメソッドを直接呼び出すSHIORI/1.x系から、 HTTPを擬したプロトコルによる粗結合RPCモデルであるSHIORI/2.0系への移行 (2001/04/22～04/24)、 SHIORI COMMUNICATE/1.1(2001/04/17)、SHIORI/2.1 COMMUNICATE(2001/04/26)、 SHIORI/2.2 イベント系リクエスト(2001/04/30)など、現在の本体の基本となる大幅な仕様変更を立て続けに行った。

一方、華和梨サイドでは、全イベント反応を統括していたpiroモジュールをSHIORIに統合すべく、 "Piroject-X"がひそかに進行を始め(2001/03/17 スタート)ていたが、本体の(正しい)仕様変更が先行したために、その動きは結果としては潰れた。それでも、華和梨内部での動作は当初構想された通りのものとなった。すなわち、呼び出しエントリ名によって動作を制御する方式である。その他の変更は全て本体とのインターフェース部に集中し、華和梨の核となる機能(=辞書と逆yacc)に変更はなかった。

ただし、イベント処理を行うことは、即ちスクリプトレベルのプログラマビリティの必要性に繋がる。特にコミュニケーション部においては内部状態変数の操作は必須と思われたし、ごくごく一部の開発者(つまりC++とSTLと華和梨の構造を理解する人間) に負担が集中しないように、誰でも修正が可能となるような簡易なスクリプトとすることも必須条件である。これは、ペルソナウェアをいじった経験があり、なおかつ本体の強烈な更新ラッシュに疲れ果てていたMeisterには初めから認識されており、この対策として2段階のスクリプト言語導入が計画された。その第1段がKISである。この辺りの経緯とKISの設計については、彼の出した文書「KIS Programming Language Chapter-0」を参考にされたい。ここではKISの特徴の一つとして、できる限り通常の辞書記述に制約を加えないために幾つかの工夫が施された点を指摘しておく。 KISは、汎用スクリプトプログラミング言語ではなく、華和梨の辞書記述と共存することを前提とした言語である。

KISは一旦は成功を収めた。ランダムトーク記述のしやすさとプログラマビリティとのバランスの良さが、ゴーストベンダに受け入れられたと考えられる。その後、インタプリタ設計の見直しと共に華和梨はPhase0.5αからPhase5.x系へ移行し、「辞書＋逆yacc＋KIS」の構図は完全に安定した。「プログラマブル準AI 華和梨」の誕生である。心配されていたテンプレーティング問題 (誰がどう作るべきか、開発チーム内でも戸惑いがあった)も、こやま☆あきら氏による「KEEPS」の登場により解決し、華和梨本体に対するパッチも少しずつ供出されるようになり、限定的ながらバザールモデルが機能し始めたかに思えた。

だが、ここで二つ想定外の事態が起きた。

一つは第2段として計画していたFIS (Fabricated Intelligence Script: いんちき知能スクリプト。仮称である)言語が、いつまで経っても導入できる目処が立たなかったことである (モジュール自体は完成したが、その頃には華和梨が普及しすぎてしまったため、推論DB(DataBase)付き超重量級AIエンジンであるFISに華和梨の名前を名乗らせるのは無理があった、というのが実情に近い)。 FISが持つ推論DBには要素の順序が保証されないという特性があり、 KISにも『将来を睨んで』その制約を課した結果、不自由なコマンドセットを長く引きずることとなった。また、開発チーム内では、 FISが待っている以上KISを拡張しても無駄である、あるいは、移植性を落とすことになる、との意識が強く、KISの充実と強化に対しては一貫して否定的であった (実際にはFISを他言語に移植することの方が遙かに非現実的である)。これらの結果、KISは長い間、「クリーンな華和梨コア」に寄生する不格好な害虫という不遇の扱いを受け続け、さらなる洗練を受けないまま放置されることとなる。複雑さを増す要求に対し、KISは次第に使いにくいものとなっていった。

もう一つは、KISがイベント処理以外の場所で使えてしまうこと、あるいは、イベント処理以外の場所に「滲み出して」いること、もしくは、イベント処理という概念の実装が明確でないことである。ペルソナウェアでは、 AI記述の全てを綾織と呼ばれるC言語ライクなプログラムで行っていたことが、ペルソナ制作の敷居を著しく引き上げていた。ゴースト制作者にとって、通常のトークを記述する上ではプログラム的詳細を可能な限り排し、演出面に集中できることが望ましいのは、優れたSHIORIシステムである里々などを見ても明らかである。そもそも"さくらスクリプト"(タグによる抽象化)が一つの例であるし、逆yacc構造はプログラム性を排したトーク記述力強化を目指していた。トーク記述とそれ以下のミドルウェアは可能な限り分離されなければならない。にもかかわらず、現状ではゴーストベンダがKISに全く手を触れずにいることは難しい。 KISの設計目標の一つである「辞書記述との親和性」は、この点では裏目に出たと言える。 KISの記述力の貧弱さ自体がミドルウェア層とトーク記述層の完全分離を困難にし、あげく、ミドルウェアを解析しなければならなくなったゴーストベンダに対して、読みにくいスクリプトを見せつける結果になっているのである。

1.3. Phase 8における変革

Phase 8は、過去、および、未来との訣別である。 FISの華和梨搭載予定はキャンセルされた。華和梨は、Meisterを始め開発チーム全員の予想を遙かに超えた所へ行き、もはや修正不可能な軌道に乗ってしまった。華和梨については、後はこの道を出来る限り先へ進む以外にない、と開発チームは判断した。面白いことに、その結果、「未来ある」華和梨に課せられていたあらゆる制約が消滅し、華和梨は自由に拡張可能となった。これを押し進めることで、次世代華和梨像が徐々に明らかとなった。 Phase 8の精神は以下である。

バイナリから余計な要素を全て削除: 雑然としていた華和梨の機能を整理し、凝縮した。 SHIORIインターフェース部は、「SHIORIプロトコルをエントリ呼び出しに置き換える」単機能に集約。主にPhase5.0以降に積み重ねられた不透明な機能は、全て削除した。辞書に課せられていた「インテリジェントさ」の制約を排除した。 kawari.ini相当機能はKIS構文に一本化し、削除した。イベント処理のインターフェースを明確にし、ほぼ全ての権限をKISに与えるためである。
全てはKISが行う: KISはもはや「おまけ」ではない。従来、華和梨のバイナリが行っていた作業も含め、 SHIORIリクエストを受けてトークを呼び出すまでの動作は、全てKISミドルウェアが引き受ける。可読性が向上した文法、強化された構文、エントリ操作コマンド群が、これを助ける。華和梨Phase 8はKISなしではSHIORIとして動作しない。
レイヤリング: Phase 8はレイヤリングエンジンである。既にその流れになっているが、改めて明言しなければならない。 KEEPS, OpenKEEPS, FUDS, KLAFTなどのミドルウェアは華和梨本体と同程度に重要なパッケージであり、華和梨に匹敵するブランドとなるべきである。ミドルウェアは必ずしも「汎用」である必要はない。ゴーストベンダはゴーストの性格に合わせてミドルウェアを自由に選択することができ、その上で、華和梨システムの逆yacc機能による高い記述性と、ミドルウェアによる抽象化の恩恵を得る。理想的なケースにおいては、ベンダはゴースト記述時には生のKISを一切触らずに、トークの演出に集中できる。 「華和梨の難しさ＝ゴースト制作の難しさ」は、レイヤリングによって分散される。

1年以上（ウォッチしていた期間を含めれば、ほぼ2年間）「何か。」について研究し、ゴーストとは何か、ゴースト制作とは何か、ゴースト制作をなるべく楽に行い、しかも多様性を出すためにはどうすれば良いかを考えてきた華和梨開発チームの、現時点の結論がPhase 8である。これは、最初の実用版であるPhase 0.42、始めてKISを搭載したPhase 0.5α4 以来のインパクトを持つバージョンアップとなる。もはや自由に研究できなくなってしまった本体の今後がどうなるかは不明だが、現状の疎結合モデルを用いている限り、この華和梨はもはやバイナリ更新を必要としない(もちろん、それは甘い考えだろう)。ネイティブコードを必要とする機能追加は、最新のSHIORI拡張仕様であるSAORIを通じて行うことができる。本体の仕様が変更された場合でも、 KISで書かれたミドルウェアは充分な可読性を持つため、ある程度の技術力があれば誰でもそれを修正し、ネットワーク更新に乗せることができる。非常に近い将来、複数のネットワーク更新先が選べるようになると思われるため、ミドルウェアの自動バージョンアップが可能となることも十分考えられる。ゴーストベンダは、より容易にゴーストを制作することができ、ゴーストの(本体やSAORIのバージョンアップによる)「事故死」を、より長い間免れることができるだろう。また、必要に応じてミドルウェアまで踏み込んだカスタマイズを行う際にも、以前のような大幅なギャップを生むことなく自然な形で拡張が行えるようになるだろうし、ミドルウェアにはある程度それが要求されるだろう。

注記：

上記結論は、ゴーストベンダによるKIS記述を否定するものでは全くない。また、ゴースト独自の「複雑な」知性を実現する健全な試みを否定するものでもない。そのような不安を抱かれた方がおられたら陳謝する次第である。

この節を書いた動機を、より現実に即して言うならば、古くから開発チーム内で言われてきた言葉：「華和梨を使うな。KEEPSを使え」である。

閑馬氏は「実装記録」中で

「汎用」は使う側にとって簡単なぶんだけ作る側にとっては難しい

と書いたが、これは真実である。だが、完全に汎用なシステムから完全に個性的なゴーストに至るまでのギャップは、若干の個性を持ったミドルウェアを挟む、レイヤリングによって吸収することができると考えられる。

使い始めの状態において、ベンダはミドルウェアの中身を理解しなくてよい。ミドルウェアはブラックボックスであり、使う側からすれば、れっきとした一つのSHIORIである。

ベンダが使用中のミドルウェアに不満を感じた場合、初めてその構造と動作を解析し、変更を加えるなり、フルスクラッチで書き直すなりすればよい。 KEEPSなどのミドルウェアが他のSHIORIと唯一異なる点は、それがKISで書かれており、適度な抽象度の上にあるために、一般のゴーストベンダにも手が出せるということである。ただそのためには、 KEEPS/OpenKEEPSを初めとしたミドルウェアが「読みやすく」、また、「書きやすく」なければならない。その目的のためにPhase 8が用意された、と言っても過言ではない。

重要なことは、このようなミドルウェアを使うためのドキュメントが今現在全く不足していることである。これは現状、ミドルウェアの社会的地位がSHIORIに比べて不当に低いことと、決して無関係ではないだろう。