worms

3-5: xarm

　第三の実装が現われるまでには、すこし時間が必要だった。だが、それは現われた。名前は “xarm”、 “eXtended Yet Another worm” と、それは名乗った。

　情報処理研究所の worm チームは、それを発見したときにざわめいた。どこが、そしてどのように “eXtended” であるのか。 worm と、 yorm を守るためにも、またインターネット全体を守るためにも、それがなんなのかの確認を急ぐ必要があった。

　構成の概要は worm と似たものだった。サーバ・サイド Javascript で、 “xarm” の実行系は書かれていた。サーバ・サイド Javascript の実行系は、情報処理研究所が公開しているものを使っていた。手間だけで考えれば、一番時間がかかるだろう点は、問題から排除できた。

　ドキュメントを検討する限り、 worm との違いは、まずスタックを使っていない点だった。 yorm と同じく、探索文字列は配列に記録されていた。 worm ではスタックを暗黙のメモリの一つとし、そこに探索文字列を積んでいた。仮にそこに worm の命令が積まれたとしても、それはただの文字列として扱かわれる。FORTHを参考にし、安全性を考えた実装だった。正規表現を許してはいても、あくまで正規表現を示す文字列だった。 yorm でも配列を用いていたが、それはスタックとして機能していた。 yorm の実行系が安全である限り、その配列に入った文字列も安全だった。スタックであるため、 worm も yorm も頻繁に探索文字列をスタックに積み直す必要があった。

　xarm ではその点が異なっていた。配列はあくまで配列として扱かわれていた。頻繁に配列に入れ直す必要がない分、 worm や yorm よりも効率的ではあった。だが、その配列が操作された場合、すくなくともそのサーバにおいては操作された配列が有効になるという問題があるようにも思えた。だが、 “eXtended” に相当する部分は、そこではなかった。

　xarm における “eXtended” とは、探索文字列の指定文法だった。とくに、 “not” の導入は、 “eXtended” であるに相応わしいように思えた。 “and“、 “or” は正規表現の文法上可能であったが、 “not” はすくなくともそれらほど簡単ではなかった。 “not” も含め、 xarm における探索文字列の指定文法は、 worm においても検討したい課題となった。

　それは、確かに寄せられてはいた意見ではあった。情報処理研究所において、またβテストまでにおいては問題とはならなかった。だが、一般ユーザにおいては、単純な正規表現ではあっても複雑なもの、あるいはわかりにくいもののようだった。 worm の記述言語があり、さらに探索文字列の文法があるという状態は避けたいと思い——あるいは他の理由もあるにせよ——、正規表現を採用したのは適切な判断だったと、黒田（くろだ） も、情報処理研究所のチームのメンバーも考えていた。しかし、 xarm の例を見ると、もう一度検討してもいいように思えた。

　だが、それには問題もあった。 “and”、 “or”、 “not” に限っても、それらは演算子であり、スタックには命令を置かないという worm の方針から外れるものだった。正規表現にそれらが含まれていても、やはりただの文字列だった。 “and”、 “or”、 “not” の導入は、その原則から外れるものだった。

　その問題も含め、 xarm のコードの精査が行なわれた。同時に、 yorm の開発者と xarm の開発者との連絡も取り始めた。 yorm や xarm のコードの精査のように、情報処理研究所のチームだけでは今後対応が難しくなることが予想され、マン・パワーとスキルを連携させたいと考えたからだった。

　そうしている間に、思わぬ横槍が入った。 worm スクリプトと yorm スクリプトは、見た目では区別がつかない。実行系がどうであろうと、そのスクリプトの文法は同一だった。

　そして、ある意味、ブラウザの一つを提供している企業が worm と似た、しかし異なるものを提供しはじめたらどうなるかという問題が、 xarm という明確なものとして目の前に現われた。

　xarm を問題視したのは、黒田も、情報処理研究所も予想していなかったところからだった。ある大学の情報処理センターを管轄する事務局の部署からだった。

「xarm の仕様は worm の仕様に反する。それはつまり、仕様の主導権を誰が握るかという問題である」そういう文面が送られてきた。「xarm の開発者に圧力をかけるべきである」とも。

　「主導権を誰が握るか」という言葉は、黒田にも情報処理研究所のチームのメンバーにも意味をなさなかった。仕様が乱立することは、確かに避けたかった。だが、それは worm の仕様が変化することも含めての話だった。開発者同士が適宜連絡を取ればいい。そう考えていた。

　まして「圧力をかける」という言葉は、なおさら意味をなさなかった。 worm は、確かにこれまではそのようなサービスがなかったとしても、公開された仕様であり、その仕様は既存の技術の組合せであり、特許ではなかった。圧力をかける根拠は、どこにも存在しなかった。

　情報処理研究所は、そのように答えた。

　だが、それに対する回答は、黒田の予想も、情報処理研究所のチームのメンバーの予想も越えるものだった。

「それであれば、こちらが主導してコンソーシアムを立ち上げる」

　回答にはそのようにあった。

　言うなれば、すでにコンソーシアム立ち上げに向かって動いている。黒田も情報処理研究所のチームのメンバーも、そう認識していた。そして、 worm であれ、 yorm であれ、導入している誰もがそう認識していると認識していた。

　情報処理研究所は、チームとしてではなく情報処理研究所として、当該大学の複数の教官に連絡を取った。返って来た答えには、さらに当惑した。皆、その意見に同意したという。

「どうなっているんだ？」

　チームの誰かが言った。

　だが、確証の不在を除けば、だいたいの予想はすぐについた。省庁からの天下り教官が裏にいるようだった。

「こんなことをしている暇なんかないのに」

　確証を求める作業に入った、チームの誰かが言った。