AirWeb 技術資料

Copyright © 2000 by Yutaka Iizuka

開発の背景

　WWW が本格的に普及し始めてから５年以上経過し、インターネット上に蓄えられる情報は現在も加速度的に増えている。しかし、新しいサイトの発見や、決まったサイトの定点観測、コミュニティサイトへの参加、サイトの検索、必要な情報の保存など、ほとんどのユーザは手作業で行っているのが実情である。一部で自動処理（ロボットや購読機能など）が行われているケースもあるが、たくわえる情報のフォーマットがまちまちであり、操作性も統一されていない。また、とくに個人の環境の場合、情報の保管場所が一元化されていないことによる情報の再利用が困難となっているケースも多い。

　たとえば最近流行しているウェブ上でのコミュニケーションサイト（掲示板など）は、HTML の構造がまちまちで CGI のコマンドも複雑であることから、単純なミラーリング形式のオートパイロットでは情報を取得することが難しい。

　これは主としてWWWのデータが正規化されていない点に負う部分が多い。現在主流の HTML は、その簡易な書き方とブラウザ上での表現力の高さから広く利用されてきたが、文書管理という本来の SGML の持っていた意味はほとんど失われてしまった。XML や XHTML など、ドキュメントの論理構造と表現を分離する手段は現れてきてはいるが、依然として主流は HTML にとどまっている。

　アナロジーで考えればこの状況は１５年ほど前にパソコン通信が流行しはじめ、多種多様な草の根ホストが現れ、その後に大手のパソコン通信業者が現れた頃と似ている。当時のパソコン通信の操作とは難易度は異なるものの、利用者が手動でコマンドを出し出力された情報をただ眺めるだけ（あるいは単一のログファイルに記録するだけ）で終わっているという点では、現在の WWW を取り巻く状況はさして違いはない。またコマンドの体系や情報のフォーマットがサイトごとに異なっている点も似ている。

　さらに現在では、WWW の利用はデスクトップパソコンに限らず、携帯電話やカーナビゲーション、果てはインターネット冷蔵庫まで多種多様に拡散している。これら多数の機器との連携という、大きなネットワーク的な視点がソフトウェアには求められている。

　もう一点、ネットワークの負荷の分散という点からも高性能なクライアントソフトウェアの考え方は有効だと考えている。現在は、できるだけ多くの機能をサーバに持つ手法が主流となりつつあるが（たとえばMy Yahoo!など）、これはネットワークの輻輳およびサーバの過負荷を招きやすい。インタラクティブに操作することを前提としてリッチなユーザインタフェース要素もすべて転送し、個人的な情報もホストに保存しているからである。必要な情報のみ抜き取り、後の処理はユーザ側で行うようにすれば、最小限の転送に抑えることが可能となる。アクセスが楽になる分、転送量は増えるのではないかという意見があるが、必要な情報の密度は確実に高まっているはずであり、これはネットワークを利用する本来の意味ではないかと私は考えている。

　ネットワークという視点では、クライアントソフトウェア同士で通信しあう機能も考慮すべきである。すなわち、サーバは ユーザ同士を結びつけるための仲介役までとし、クライアントもサーバもユーザサイドにあるソフトウェア でまかなうような使い方も考えられる。

　つまり帯域幅が大幅に拡大し、常時接続が当たり前となるこれからの時代のネットワークモデルでは、ブロードキャスト型のクライアントだけでなく、ピアトゥピア型のコネクションも視野に入れていという点で、既存のウェブソフトウェアとは質的に異なる環境が必要となる。

　私は、学生時代の1987年に最初のロボット型通信ソフトを開発し、1990年には仮想機械上に通信環境を構築するコンセプトをたちあげ、その後の日本におけるオートパイロット環境全盛の時代のルーツを作り上げた1人である。コンピュータにとって扱いやすいという非人間的な「簡易言語」ではなく、本格的なプログラミング言語を装備しユーザレベルで通信環境を構築できるプラットホームだった。

　とくに 1990年に開発を行った Program of the air は、その後の Java の到来を予見させ、通信環境とマルチプラットホームのあり方を提示して見せたと考えている。仮想機械と言語との分離、アプレットのオペレーティングシステムからの独立（マルチプラットホーム）、通信ホストの操作性をアプレットで吸収しどのホストも同じ操作で利用できるというコンセプトを、当時の貧弱な MS-DOS 上で実現した。この air の開発には、ＯＳ、言語処理、データ処理、デバイスドライバなど、情報科学に関するオールラウンドな知識が総動員された。日本において通信環境のありかた（オートパイロット、ブラウザ、エディタの渾然一体となった環境）を多くのユーザとともに布教してまわったのも最初だったと記憶している。

　オートパイロットは通話料金の軽減という意味で多くのユーザの心を捉えたが、実はもっと大切な役割があった。それはネットワークを誰でも気軽に使えるようにしたという点である。それにより、ニフティのフォーラムには圧倒的に豊富な情報が集まるようになった。オートパイロットは、アクティブユーザというコミュニティのリーダーの育成に必要だったのである。また、当時ニフティ最大のフォーラムでは、大量の保守作業もオートパイロットによって自動化されていたということを忘れてはいけない。サーバサイドとクライアントサイド双方の処理能力の大幅な向上により、コミュニティが活性化されたのである。

　このような経験および考察を踏まえ、WWWにおいてサイトの違いを吸収し、必要な情報を自動で取得し、ローカルのデータベースエンジンで情報の正規化を行ない、閲覧や検索、発信、あるいは情報の自動抽出ができる統合型環境 AirWeb を考案するにいたった。要は１０年前に自分が作り上げたコンセプトの焼き直しであるが、まだ誰もやっていないのでやらない法はないというわけである。世間でのメーラーの開発ブームは一段落したが、次に来る波は WWW の情報管理だと私は考えている。そして、この技術は今後5年以上に渡って改良できるものと考えている。ネットワーク上の開発者のコラボレーションによって成長できる環境に設計してあるからである。

　AirWeb の設計は 1997 年からはじまり、本格的なプログラミングも 1998 年に開始をしている。最初のバージョンは Windows をターゲットとしている。しかし、本体だけで 25万ステップ以上の膨大なプログラムであるため、まだ完成をしていない。完成版の一般リリースは 2001 年春を目標とし、現在、詰めの作業に入っている。内蔵のデータベースエンジンの高機能化や、全体のユーザインタフェースの修正、エージェントの使用するライブラリの充実、互換性の検証、エージェントの自動更新を行うライブアップデート機構、検索エンジン、情報の自動抽出など、完成度の要求される部分はまだまだある。

　2000年内は、この AirWeb のブラッシュアップを行ない、最初のバージョンを完成させるのが目標である。それと平行して、Windows 以外のプラットホームへの移植を検討していきたい。また、AirWeb の初期のバージョンにおいては標準でサポートするエージェントの数が重要であるため、様々なサイトを分析し、早期に多くのエージェントを用意したいと考えている。いずれ、レンダリングエンジンを自前で持って Internet Explorer や Netscape Navigator のようなプラットホームに育てたい。そして、将来には個人が自分にあったエージェントを多数着用し、ネットワーク上に延長された自分の身体を自由自在にあやつることで、他者とのコミュニケーション能力や記憶能力を飛躍的に向上することを目標としている。

図．AirWeb の構造
AirWeb は、中核に Air VM があり、エージェントに様々なサービスを提供している。
AirWeb はエージェントの集合体であり、世界各地にクモの子（エージェント）を散らして、情報を取ってくる。
たとえば巡回エージェントは、Air VM の用意するサービスを利用してサーバを訪れ、提供されている情報の中から必要なものを抽出し、データベース化する。
閲覧エージェントは、データベース化された情報をブラウザやチャートなど多様なフォーマットで表現する。
編集エージェントは、ユーザによる情報の投稿を支援する。

概要

　AirWeb は、おおまかに分けて AirWeb 本体（実行環境）と ASDK（エージェント開発環境）の２つから構成される。一般ユーザレベルに配布されるのは AirWeb とエージェントで、ASDK はエージェント開発者に向けて公開される。

　

図１．AirWeb の基本構成

　AirWeb 本体の構成は図１のようなレイヤ構造となっている。オペレーティングシステムを Air Kernel と呼ばれるアプリケーション部分が包み、その外側に Air VM（仮想機械）とマネージャが接している。各種エージェントや、エディタやブラウザ（これらも実はエージェントである）などのユーザの目に直接触れる部分は、この Air VM の外側に位置し、Air VM のサービスを利用して実行される。AirWeb 本体は、メタブラウザということもできる。

　Air Kernel の用意する機能は多彩である。これは、ＯＳでサポートされていない高度な機能を集約したいわばライブラリ的なレイアであり、以下のようなものが含まれる。

　一方、Air VM は以下のような機能を持つ。

　ASDK は、AirWeb 用のエージェントを開発する環境で、以下のツールから構成されている。

　Air VM は Air VM Code とスクリプトインタープリタの両方をサポートしているため主として Air VM Code 生成系とインタープリタ系の２系統のツールを用意している。これは、できるだけ多くの開発者にエージェントを作ってもらうことを目的として、言語の壁をなくしたいとの考えから来ている。Air C Preprocessor から Air Link Editor までは Air VM Code の生成に用いるコンパイラ系ツール群である。Air VM Code は実行速度が速いのがメリットである。現在は C/C++ しか用意していないが、Air VM Code は汎用であるので、他のコンパイラを用意することは可能である。Air Designer の方は、インタープリタ系のスクリプトを生成するのに利用する。こちらはインタフェースビルダを持っているため、主としてユーザインタフェースの構築に威力を発揮する。

　ただし、Air VM Code で利用できるサービスと、スクリプトで利用できるサービスに若干の違いがある。将来的にはこれらを統合して、Air C++ でもインタフェースを構築でき、スクリプトでも Air C/C++ の機能が使えるようにする予定である。

AirWeb 本体

　プロトタイプ段階の AirWeb は図２のような形態となっている。一見すると、メーラーのような表示が特長である。

　上部にメニューとツールバーを持ち、左側にキャビネットと呼ばれるエージェントマネージャ（ツリー表示）、右側のクライアント領域に情報を表示する構成となる。

図２．AirWeb プロトタイプの画面

　プロトタイプは Windows 上で開発されたため、Internet Explorer 風のパーツが標準で用意されているが、これはカスタマイズできる。あまり独自の形態とするとユーザの初期の導入を遅らせることになりかねないため、あえてシェアの大きいソフトウェアに似せて作った。一種の擬態であるが、内容はInternet Explorer や Netscape Navigator と全く異なる。

　例として、キャビネットから、TRON ファンフォーラム（ニフティがインターネット上で公開しているフォーラムのひとつ）をクリックした様子が、図３である。TRONファンフォーラムという項目は、実はエージェントのインスタンスの１つで、ニフティのフォーラムを自動巡回し新規の記事を取得する機能と、取得された情報をメーラー風ブラウザで表示する機能、ならびにエディタで投稿を作成する機能を有している。ニフティのフォーラムは HTML 形式であるが、ページ解析関数を用いて記事の必要な部分だけ抜き取ることで、図３のようなメールと同等の表示を実現している。

図３．AirWeb プロトタイプにおけるフォーラム表示

　ブラウザ部分の開発は簡単である。あらかじめ mbox データベースの中身をメーラー風のツリー構造で表示するコンポーネントや、ハイパーテキストのコンポーネント、グラフ表示のコンポーネント、画像データベースのコンポーネント、エディタのコンポーネント、ウェブブラウザのコンポーネント（図４）などが用意されているので、これらを Air Designer のインタフェースビルダでペタペタと貼り付けるだけで作成できる。

図４．AirWeb プロトタイプにおけるHTML表示

　たとえば株価のチェックの場合は、ブラウザ部分にチェックする銘柄のポートフォリオを表示し、その銘柄に関して他のサイトから取り寄せた情報を同時にまとめて表示するなど、情報に応じた柔軟なカスタマイズができる。図５はチャート表示の一例である。

図５．AirWeb プロトタイプにおけるチャート表示

　また、プロトコルは HTTP や FTP に限定しないため、SMTP/POP3/IMAP4 に対応したエージェントを作成すればメーラーに、NNTP に対応すればニュースリーダにという具合に機能を拡張することも可能である。

　内蔵のデータベースエンジンは、初期版では mbox 形式（MIME対応）のテキストデータベースと、ダイジェスト機能を持った画像データベースの２種類であるが、より機能を強化した XML ローカルデータベースや、外部の SQL データベースエンジンとリンクする機能などの追加をしていきたい。ただし、情報を串刺しで検索や抽出を行うようにするため、データの入出力の部分は一定の正規化を行う必要がある。たとえば XMLの場合では、DTDの定義などである。

AirWeb のアプリケーション

　AirWeb はエージェントによってさまざまな機能をプラグインできる統合環境であるが、以下のような応用が考えられる。

　その他、アイディア次第で様々な応用が考えられるが、AirWeb というインフラを用いることでアイディアを形にしやすく（面倒な処理は AirWeb が引き受ける）、また収集したデータを無駄にしないのが特長といえる。さらに、メールへの情報転送やプロキシの設定など細かなことを、全エージェントで共有できるのもメリットである。

ASDKエージェント開発環境

　AirWeb のエージェントには大まかに分けて２種類ある（図６）。１つは Air VM Code で構成された Air VM Agent。もう１つは、DelphiScript や JavaScript など、スクリプトエンジンを利用した Script Agent である。

図６．Air Agent
Air Agent には大きく分けて Air VM Agent と Script Agent の２種類がある。
Air VM Agent は Air VM Code で構成され、Air VM 上で直接実行される。
Script Agent は、Air VM の内蔵（あるいは外部にある）スクリプトエンジンを使ってインタープリトされる。
Air VM Agent の方がコンパイラ型のため圧倒的に高速であるが、自由度は Script Agent の方が高い。

図７．Air C/C++ Compiler
Air C/C++ Compiler は、Air C/C++ ソースコードを Air VM 実行形式にコンパイルする。

図８．Air Designer
Air Designer は、Air VM のもう１つの機能であるスクリプトエンジンを使うスクリプトを生成する。
DelphiScript は Air VM に内蔵されたスクリプトエンジン。その他は、外部のエンジンを呼び出して利用。
スクリプトエンジンは、後から追加が可能。

　Air VM Agent は Air VM 上で直接実行されるが、Script Agent は Air VM がインタフェースとなって、インタープリタのスクリプトエンジンで実行される。スクリプトエンジンとしてAirWeb が標準で内蔵しているのは DelphiScript Engine のみである。VBScript Engine や JavaScript Engine などはOSが用意している機能であるため、Windows 以外のほかのプラットホームへ移植する際には注意が必要である。移植性を考える場合は、DelphiScript Engine や Perl, Ruby  などを考慮した方がよい。

　Air VM Agent は、Air C/C++ ツール群（Air Preprocessor, Air C/C++ Compiler, Air Assembler, Air Link Editor）を用いて開発する（図７）。一方、Script Agent は Air Designer を用いる（図８）。Air Designer は Windows 上の開発環境 Delphi とよく似ている。ただし、使用できる言語が DelphiScript や JavaScript, Perl などプラグインできる点が異なる。また、インタープリト機能は持つがコンパイル機能は持っていない（インタープリト機能は AirWeb 本体のサブセット）。

Air VM のサポートする関数群

　Air VM は、大量の標準関数を持っているが、大別すると表１のようになる。

Air VM Code 系 Script Engine 系
ANSI C 標準関数のサブセット ユーザインタフェースコンポーネント
データベース操作関数群 データベース操作コンポーネント(*)
TCP/IP ソケット関数群 TCP/IP ソケット操作コンポーネント(*)
HTTP/FTP 関数群 HTTP/FTP 操作コンポーネント(*)
ページ解析関数群 ページ解析コンポーネント(*)
エージェント間通信関数群(*) エージェント間通信コンポーネント(*)
設定値データベース操作関数群  設定値データベース操作コンポーネント 

表１．AirWeb のサポートする関数群
将来的には、Air VM Code 系と Script Engine 系は関数を対称となるように用意する予定である。
(*) は準備中の機能。

Air C の string 型

　Air C はエージェントの開発を促進するために string 型がサポートされている。

　string 型は、文字列の結合や正規表現のマッチングなど、C で弱いとされていた文字列処理を大幅に強化する。string 型の特長は以下のとおりである。

  1. string 型の文字列は ANSI C の char* 型と互換性のあるものとして扱うことができる
  2. string 型の文字列の破棄ガーベージコレクションで自動管理される
  3. string 型の文字列は、+ 演算子により結合することができる
  4. string 型と char* 型の演算(+)で、新しい string 型の文字列を生成することができる

　次に例をあげる。 

void test(void) 
{ 
  string s; 
  char buf[80]; 

  s = "Hello, "; 
  gets(buf); 
  puts((char*)(s + buf)); 
}

　この例では、　string 型の文字列（"Hello, "）と gets 関数で得られた文字列（従来の char[] 型）を結合し、新しい string 型の文字列を生成し、それを char* 型として扱って puts 関数で出力している。

　string 型の文字列のガーベージコレクションは、参照カウントによる方法がとられる。すなわち、どこからも参照されなくなった時点で、その文字列は破棄される（実際には、破棄されるタイミングはその string 型の文字列が属する関数スコープを抜ける段階である）。ただし、定数文字列は破棄されない。上の例では、s + buf によって新しい string 型の文字列が生成されているが、puts 関数でしか参照されていないため、test 関数の最後でこの文字列は破棄される。一方で、最初に s に代入された "Hello, " は定数であるため破棄はされない。

　ガーベージコレクションが関数の末尾で行われるため、次のような処理は可能である。 

void test(void) 
{ 
  string s; 
  char buf[80];
  char *p;

  s = "Hello, "; 
  gets(buf); 
  p = (char*)(s + buf);
  puts(p); 
}

　s + buf によって生成された新しい文字列は、他の string 型の変数に代入されていないため参照カウントがゼロとなる。一方で p は char* 型なので、string 型の文字列のバッファのみを参照している。しかしこの文字列は test 関数の末尾で破棄されるため、p への代入や puts 関数を呼び出す段階では有効である。

　一方、次のような処理はエラーとなる。 

void sub(char** pp) 
{ 
  string s; 
  char buf[80];
  char *p;

  s = "Hello, "; 
  gets(buf); 
  *pp = (char*)(s + buf);
}

void test(void)
{
  char** pp;
  
  sub(pp);
  puts(*pp);
}

　sub 関数の中で s + buf によって生成された文字列のバッファ部分へのポインタが *pp へ代入されているが、この文字列は sub 関数を抜けるときに破棄されるため、test 関数で puts(*pp) を呼び出す段階でエラーとなる。

　string 型については、上のように char* 型へのキャストを使用する場合のみ注意が必要であるが、それ以外では特に難しいことを考えずに、Basic や Delphi のように考えてよい。

　string 型の実体は、ゼロからのオフセット部分には C 言語と互換性のある null terminated string が配置され、マイナスのオフセット部分に参照カウントや文字列長が置かれている。そのため、(char*) のキャストという単純な処理で、通常の char* 型を期待している関数への引数に利用できる。

Air C の正規表現

　Air C は正規表現への対応の拡張も行われている。

  1. re_compile, re_search, re_free 関数による従来の正規表現処理
  2. =~, !~ オペレータによるマッチ
  3. $1, $2, ...$9 によるマッチしたテキストの取り出し
  4. 正規表現の m/.../ オペレータ記法への対応

　1 は従来からある正規表現関数による処理である。以下に例を示す。 

void test(void) 
{ 
  REGEX* re;
  char buf[80];

  gets(buf);
  re = re_compile("My name is ([^.]+)\\.");
  if(re_search(re, buf))
    puts("Hello, " + re_get_group(re, 1) + ".");
  re_free(re);
}

　re_get_group 関数は、　マッチしたテキストを取り出すための関数である。たとえば、"My name is Yutaka Iizuka." という文字列が入力された場合、re_get_group(re, 1) は "Yutaka Iizuka" を返す。

　正規表現オペレータを使った場合は、同じ処理を次のように書くことができる。 

void test(void) 
{ 
  char buf[80];

  gets(buf);
  if(buf ~= "My name is ([^.]+)\\.")
    puts("Hello, " + $1 + ".");
}

　REGEX 変数や関数の処理が自動化されるため、大幅に短縮した記述ができる。

　さらに、C の文字列型のエスケープシーケンスを回避するために m/.../ 記法が用意されている（本来はそれだけの意味のものではないが、現状では、この目的で実装されている）。これを使うと \\ のようなＣのエスケープシーケンスを回避する書き方が不要となるため、次のようになる。 

void test(void) 
{ 
  char buf[80];

  gets(buf);
  if(buf ~= m/My name is ([^.]+)\./)
    puts("Hello, " + $1 + ".");
}

　ただし、m|...| のような書き方は、まだサポートされていない。また、s/.../ など別のオペレータは今後の予定である。　

　現在、Air C でサポートされている正規表現メタキャラクタは以下の通り。

正規表現の種類

  1. abc 文字そのもの

    メタキャラクタ以外の文字は通常の文字を表す。
    abc 文字列 "abc" にマッチする。

  2. \ メタキャラクタの意味打ち消し

    \ を前に置くことで、正規表現で用いられるメタキャラクタの意味を打ち消す。 
    例）\+, \|, \\ それぞれ文字'+', '|', '\' にマッチする。
    ただし、正規表現をリテラルに " で囲っている場合は、それぞれ \\+, \\|, \\\\ と表現する必要がある。 （C言語によるエスケープシーケンス処理が行われた後に正規表現エンジンが呼び出されるため）

  3. . 任意の１文字を表す

    任意の１文字（２バイト文字を含む）を表す。
    ※ただし、復帰(CR)0x0d、改行(LF)0x0a にはマッチしない。
    例）正規表現 'a.b' は、 'aab', 'azb', 'a@b', 'a全b' ... などにマッチする。

  4. ^ 文頭を表す

    検索対象テキストの文頭にマッチする。
    ※１文字目のキャラクタを表す位置以外では、通常のキャラクタ'^'として扱われる。
    例）
    ○ ^abc 文頭の"abc"にマッチする。
    ○ (xyz|^ABC) "xyz"または、文頭の"ABC"にマッチする。
    × A^BC "A^BC"にマッチする。文頭を表すメタキャラクタとしては解釈されない。

  5. $ 文尾を表す

    検索対象テキストの文尾にマッチする。
    ※最後尾のキャラクタを表す位置以外では、通常のキャラクタ'$'として扱われる。
    例）
    ○ abc$ 文尾の"abc"にマッチする。
    ○ (xyz$|^ABC) 文尾の"xyz"または、文頭の"ABC"にマッチする。
    × A$BC "A$BC"にマッチする。文尾を表すメタキャラクタとしては解釈されない。

  6. [...] キャラクタクラス

    '[' と ']'に挟まれた文字のどれか１文字にマッチする。
    例） ［abc] "a" 又は "b" 又は "c" にマッチする。
    '-'による範囲指定も可能。
    例） [0-9０−９] 半角、全角の数字１文字にマッチする。

  7. [^...] 補キャラクタクラス

    '[' と ']'に挟まれた文字以外の文字１字にマッチする。
    例） [^いろは] "い", "ろ", "は" 以外の１文字にマッチする。
    '-'による範囲指定も可能。
    例） [^a-zA-Z] 半角アルファベット以外の１文字にマッチする。

    ※ キャラクタクラスの中では、'['の次の'^', メタキャラクタ '\', 範囲指定の '-'以外の文字は文字そのものとして扱われる。
    例） [.()\\^] 文字 '.', '(', ')', '\', '^' のどれか一文字にマッチする。
    ※ キャラクタクラスの中で両側にキャラクタの無い'-'は文字そのものとして扱われる。
    例） [+-] 文字 '+', '-' のどちらか１つにマッチする。
    例） [-+] 同上。

  8. XY 連結

    XY 連続している正規表現 XY にマッチする。
    例） A+B+ A+ に続いて B+ がマッチした場合にマッチする。"AB", "AAB", "AABB",... など。

  9. X|Y 選択

    X|Y 正規表現 X 又は 正規表現 Y にマッチする。
    例） A+|B+ A+ または B+ にマッチする。"A", "B", "AA", "BB", "AAA", "BBB",... など。

  10. X* 直前の正規表現の0回以上の繰り返し（閉包）

    X* 直前の正規表現の0回以上の繰り返しにマッチする。
    例） A* A の0回以上の繰り返しにマッチする。"", "A", "AA", "AAA",... など。

  11. X+ 直前の正規表現の1回以上の繰り返し (正閉包）Positive Closure

    X+ 直前の正規表現の1回以上の繰り返しにマッチする。
    例） A+ A の1回以上の繰り返しにマッチする。"A", "AA", "AAA",... など。

  12. X? 直前の正規表現の0回か1回の表現

    X? 直前の正規表現の0回か1回にマッチする。
    例） A? A の0回または1回の表現にマッチする。すなわち "" または "A" にマッチする。

  13. (X) 括弧による解釈の優先順位指定

    (X) 正規表現 X を1つの塊として指定する。優先順位の変更に用いる。
    例） (ABC)+ "ABC", "ABCABC", "ABCABCABC",... にマッチする。
    例） (A|B)+ "A", "B", "AA", "AB","BB",... にマッチする（[AB]+と等価）。
    ※マッチしたテキストは、後で re_get_group 関数か $1, $2,... で取り出すことができる。

  14. () ヌル正規表現

    () 文字が存在しなくてもマッチする。
    例） (X|) X？と等価の意味を持つ。

Air C のページ解析関数

　ページ解析関数は、HTML/XML ページの構文解析を行ない、エレメントの抽出を自動で行う。しかし、AirWeb のページ解析関数は、一般に用いられるようなツリーウォークのような方法を取らず、集合論に基づいたエレメントの演算を特徴としている。これは、ツリーウォークよりもより汎用度の高い情報抽出手段だからである（一般のツリーウォークがファイルシステムとすれば、ページ解析関数は SQL データベースに相当する）。抽出されたエレメントを集合で管理し、集合間の演算によって必要なエレメントを特定する方法である。抽出されたエレメントからアトリビュートやテキストを取り出すこともできる。

　例として、例１に http://www.asahi.com/ のトップページから、トップニュースのみを抽出して表示するコード断片をあげる。 

           
 1   // ページを解析                                   
 2   page = page_create(buffer, len); // page オブジェクトの生成(bufferにはHTMLが入っている)                                
 3   // "A" エレメント集合を取得                                   
 4   el1 = page_find_elements(page, NULL, "A");                                   
 5   // Top 5 コメントで挟まれた領域をエレメント集合として取得                                   
 6   el2 = page_find_text(page, "Start of Top 5.*End of Top 5");                                   
 7   // Top 5 で挟まれた領域に含まれる "A" エレメントを抽出                                   
 8   el3 = page_elements_inside(page, el1, el2);                                   
 9   buffer[0] = 0;                                   
10   for(i = 0 ; i < el3->count ; ++i) { // el3 のエレメントを列挙                                   
11    // エレメントのテキストを結合                                   
12    strcat(buffer,page_element_text(page, &el3->items[i]));                                  
13    strcat(buffer, "\r\n");                                   
14   }                                  
15   puts(buffer); // ヘッドラインリストを表示                                   
16   page_free(page); // page オブジェクトの解放 

例１． http://www.asahi.com/ のトップニュースのみを抽出する処理

　例１のコードが対象とするページは、以下のような特徴部分を持っている。

     
<!-- Start of Top 5 -->
                                     
■<a href="0803/news/national03034.html">
                                     
式根島で震度５クラスの地震相次ぐ</a><br>
           
・・・中略・・・
           
■<a href="0803/news/sports03009.html">
                                     
千葉すず選手の五輪出場認められず　ＣＡＳが裁定</a><br>

<!-- End of Top 5 -->

　このページには、大量の A タグやコメントなどが含まれているが、<!-- Start of Top 5 --> と <!-- End of Top 5 --> というコメントに含まれる A タグは上記のものに限られる。

　そこで、まずコードの４行目でページエレメントの全体から、A タグの構成するエレメントを抽出する。これが el1 というエレメント集合（リスト）である。

　次に６行目で、この着目するコメントに含まれた領域を正規表現によって抽出し、擬似エレメントを生成する（擬似エレメントは、抽出されたテキスト断片の前後が <SPAN> と </SPAN> で囲まれたエレメント相当として扱うことができる）。これは el2 というエレメントの集合となる。

　８行目では、el1 のうち el2 の各エレメントの領域内に含まれているエレメントのみを抽出する処理を行う（重なった領域）。すなわちこれがトップニュースを含んだAエレメントの集合 el3 ということになる。

　９行目以降は、el3 のエレメントに含まれるテキストを結合し、最後に puts 関数でトップニュースのテキストを表示している。

　16 行目でページオブジェクトを解放する。

　この例は非常に単純であるが、ページ解析関数はエレメントの加減乗除算や包含関係・前後関係に関する演算、正規表現によるタグの検出など多彩な機能を持っている。もちろん、XML にも対応している。ページの特徴の抽出が簡単であるため、サイトに特化したエージェントを簡単に記述できるのは AirWeb の大きなメリットである。

短期的な計画（1年〜2年）

　AirWeb の開発および普及の初期段階は、以下のように考えている。最初のプレリリースは、AirWeb 環境に対するユーザの要望を集めることと、エージェント作者を発掘することを目的としている。

第１段階 - 開発 (2000年中)
    AirWeb 本体および ASDK のバージョン１の開発
    エージェントの開発
第２段階 - デバッグ (2000年中)
    プレリリース公開
    AirWeb を利用したコミュニケーションサービス（Aboard）
    エージェント作者の発掘
第３段階 - 正式公開 (2001年1月)
    http://www.airclub.org/ サイトの構築
    エージェント自動更新機能の装備
    エージェントのダウンロードサービス（自作およびユーザ作）
    AirWeb 本体のシェアウェア化
第４段階 - 普及 (2001年中)
    http://www.airclub.org/ サイトの充実
    エージェントの充実

中長期的な計画

　短期的な計画だけでは大きなソフトウェアを育てることはできないが、AirWebには中長期的な計画が用意されている。実際には、世の中の要請にしたがって動的に変化していくものであるが、全体のフレームワークとして現在のところ以下のような技術的改良を展望している。

1. 対応プロトコルの拡大

　既に述べたように AirWeb は、単に HTTP プロトコルを利用したクライアントではなく、情報交換を目的としたシステムである。したがって、標準対応するプロトコルを、現在の HTTP/HTTPS/FTP から、さらに SMTP/POP3/IMAP4/NNTP へと拡大し、また IPv6 への対応など新しい規格への対応も行っていきたいと考えている。

　もちろん、現在の AirWeb でもエージェントを工夫して作ればこれらのプロトコルへ対応することも可能であるが、より簡単に、そしてよりシステマチックに対応をしていきたいと考えている（たとえば、SMTP/POP3/IMAP4 への対応の際には、ユーザのプロファイルを AirWeb 本体で管理するなど）。

2. データベースの充実とXML

　データを保管するためのデータベース機能は中核にあってとても重要な機能である。そのためにエージェントに対してデータベースを管理するAPIを用意している。

　一方、データのネイティブな保存フォーマットはテキストにこだわりたい。最初の版で mbox 形式を採用したのも、すでに多くのユーティリティが存在しているからに他ならない。今後の XML の普及によって、AirWebがより多くのユーティリティと連携して動作するようになる可能性があるため、XMLへの対応も考えている。パーソナルなデータファイルを管理するための XML の DTD を定義し、それに基づいたデータベースエンジンを装備する。しかし、エージェントとの間に介在するデータベースレイアでの互換性は確保することが重要である。したがってDTDもいくつか用意するが、メインのものはmbox や MIMEの上位概念で設計しなければならない。また、外部のデータベースエンジンを利用する場合にも、同じデータベースレイアがプロキシの役割を果たす設計とする。エージェントは、物理的な保存フォーマットを意識せずにデータベースを利用できることが必須だからだ。

3. 情報の自動抽出機能と自然言語処理

　AirWebには初期の版から情報を自動抽出してレポートにまとめるトピックスと呼ばれる機能がついているが、最初の版ではあいまい検索や日付検索などの比較的単純な条件しか装備していない。これを、多変量分析などによる自然言語処理を取り入れ、よりユーザの意向に密着した情報のキャッチを行えるよう、精密化をはかっていきたいと考えている。

　トピックス機能の向上は、すべてのエージェントの機能向上にもつながるため、絶え間ない改良を続けたい。また、同様の自然言語処理エンジンをエージェントに解放し、エージェントのユーザインタフェースをより人に親しみのあるものにしたい。

4. Air VM の移植

　AirWeb 本体の Windows 依存部分を排除し（VMのAPIを整備し）、AirWeb を Linux や MacOS, TRON, PalmOS など他のOSへの移植を進める。つまり、Air VM の汎用化である。AirClub は、すべてのプラットホームのユーザに共通に利用できるようにする。エージェント開発言語としては Air C/C++ コンパイラ、DelphiScript、Ruby（フリーソフトウェア）、Perl（フリーソフトウェア）を推進するが、さらに新しい言語を開発することも検討している。Air VM は言語の設計と独立なので、時代とともに言語をバージョンアップさせていくことが可能である。

5. Java への移植

　サブセットを Java へ移植することも検討している。Java VM の上に Air VM を載せるのは効率が悪そうだが、プロセッサの性能向上がこれを解決してくれるものと考えている。Java へ移植することで、対応するプラットホームを増やすことが可能となる。

6. 言語の充実

　Air VM に対応した言語を増やす。C# など、他社の考案した言語であっても評判のいいものや普及しているものであれば、積極的に実装を行ない、開発者に選択肢を与える。また、VM の基本スペックの公開を行ない、他の開発者による言語の開発を可能とする。

7. セキュリティ機能の向上

　エージェントの普及とともに、セキュリティ機能のより一層の向上が求められる。本体のセキュリティ機能を向上させるほかに、認証局を用いて開発者を特定する方式で、エージェントを安全に普及させていく必要がある。

8. 啓蒙と教育

　エージェント開発の促進のために、ウェブの構造やネットワーク上で提供されている情報の特性の分析などの初歩的な事項を含めて、インターネット上に教室を開いて、底辺の拡大をはかりたい。それによる全体のネットワーク環境の向上を目指したい。たとえば自治体が各種住民手続きを行うためのエージェントを自主的に配布したり、小コミュニティが独自のエージェントを持てるようになることは1つの目標である。これはエージェントの数だけ無数にブラウザが開発されることを意味する。

　実世界の仕事を取り込むためにあらゆるアプリケーションソフトウェアが現れたように、ネットワーク上に分散するリソースを取り込むために多種多様なエージェントを育てる必要がある。そのためには、啓蒙と教育によって草の根開発者を育てていくしかない。

２０１０年に向けて

　マクルーハン(*)を引くまでもなく、人間はネットワーク上に着実に身体を拡張しつづけてきた。ネットワークは目や耳などの感覚器官・情報伝達器官の拡張だけでなく、頭脳を補完する役割も果たしつつある。それは、人間が未知の生命や文明との出会いというフロンティアを求めてきた歴史とオーバーラップする。

　ネットワークが身体であるならば、それを操作するためには、運動神経、知覚神経、自律神経などの独立した神経系統が必要である。現在主流のウェブによるネットワーク利用のスタイルは、明らかに運動神経と知覚神経に偏ったものであり、不随意に処理がなされる自律神経のような仕組みに欠けている。AirWeb のエージェントは、まさにこの自律神経の役割を果たす。一種のデーモンのような黒子である。

　2010年のインターネット環境は、個人が10Mbps超の常時接続環境を持ち歩けるものとなることは想像に難くない。つまり一昔前のLANに近い快適さで世界とコミュニケーションを取ることが可能となる。また、IPv6 の普及によりコミュニケーションの対象は人間単位ではなくあらゆる製品にまで及ぶ。携帯電話のプロセッサの処理速度が、現在の Pentium 1GHz をしのぐことも十分あり得る。

　しかし、既に述べたように膨大な世界をすべて単一の運動神経や知覚神経すなわち人間の能動的動作で処理することは難しい。AirWeb は、単に情報を見て発信するだけでなく、自律神経的な働きをする秘書的な機能を果たす。これは、現在のパソコンのみならず、携帯端末や電話、あるいは人体への埋め込みも含めて、通信環境に必要な機能であると考えている。現段階では、ウェブをメーラー風に整理する環境、あるいはロボットの集合体程度の概念で十分と思われるが、やがてインテリジェントな通信環境を持った人間同士が、さらに新しい環境をネットワーク上に構築する時代がやってくる。つまり AirWeb はプラットホームであり、エージェントおよび人間がソフトウェアということになる。

　私は、数万人以上のユーザとの対話の中でパソコン通信の環境を向上するシステムの開発を行ってきたが、それはブートストラップと同じ原理で、通信ソフトウェアの自動化の助けがあってこそのものだった。1990 年の段階で、すでに自動化された環境を持つものと持たないものとの間に、大きな情報格差が発生していた。その後、10年をかけてこのシステム AirCraft は一般ユーザにも使える環境として完成を見ることとなった。インターネットでの成長はさらに大きなものとなると考えている。ネットワークそのものがコミュニケーションを取ろうとする者すべてに開かれ、常に進化を続けているからだ。AirWeb のようなソフトウェア概念は、多くのユーザに鍛え育てられることで、10年といわず成長をしつづけることが可能だろう。

　やがてウェブサイトはハブとなり、インテリジェントな通信環境を持ったもの同士がそのハブを通して直接コミュニケーションをはかるようになると想像している。その、有意義なコミュニケーションをはかるためのソフトウェアとしてAirWebを考えている。

　VM とエージェントさえあれば、どのプラットホームでも同様の秘書を利用できる。家や会社でもつかえる。秘書を持ち歩くこともできるわけだ。そのような日が到来することを夢に見ている。

(*)Marshall McLuhan. Understanding Media: The Extensions of Man. New York: McGraw-Hill; London: Routledge and Kegan Paul, 1964.