プログラミングの話
最後に、プログラミングの話も書いておきます。使っているプログラム言語はPerl、エディタは秀丸エディタです。ソースコードは240KBぐらいの分量でした。
ちなみに「全自動4コマ」は280KBぐらい、「全自動似顔絵」は80KBぐらいです。普段開発している携帯電話向けのシミュレーションゲームのソースコードが1.2～1.3MBぐらいですので、分量的には軽い部類のプログラムになります。
オートペディアの内部技術
「オートペディア」では、いくつかの技術が利用されています。それらの技術は、大別して「通信系」「キャッシュ管理系」「キーワード抽出系」「文章抽出・評価系」「文章加工系」の5種類になります。
- 「通信系」
- 「キャッシュ管理系」
- 「キーワード抽出系」
- 「文章抽出・評価系」
- 「文章加工系」
それぞれの系統でどういったことをやっているのか、簡単に触れておこうと思います。
「通信系」
「通信系」は、Perlモジュール化してまとめています。検索語をこのPerlモジュールに送ると、20種類ほどの検索エンジンの中からアクセス履歴の状態がよいものを選び、検索結果をネット上から取得します。
その後、検索結果からキーワードと文章を抽出し、検索結果と合わせてXML化して呼出元に返します。さらに、検索結果はキャッシュとして保存し、次回の検索に備えるようになっています。
この「通信系」にはもう1系統あります。それは英訳用のPerlモジュールです。こちらは少し挙動が違います。数種類の翻訳サイトからアクセス履歴の状態がよいものを選び、翻訳結果をネット上から取得します。
一度翻訳した単語はキャッシュとして保存していき、頻繁なアクセスを発生させないようにしています。
「キャッシュ管理系」
「キャッシュ管理系」は、様々な場所で使われています。ページ全体もキャッシュとして保存されますが、検索結果などの中間生成物もキャッシュとして保存しています。
これは通信状態の悪化で検索自体が失敗した場合に、キャッシュを読み込んで、その内容を加工して代用物として利用するためです。こういった仕組みを用意することで「何も表示しない」という状態を極力避けるようにしています。
「キーワード抽出系」
「キーワード抽出系」ではデータベースを使いません。文章からキーワードを自動抽出し、その価値を評価してソーティングしています。このアルゴリズムは簡易で便利なので、私が作っている他のCGIなどでもその都度バージョンアップして使っています。
「文章抽出・評価系」
「文章抽出・評価系」では、検索語についてその文章がどれだけ関連があるかを評価して抽出しています。文法上の位置など、いくつかの項目で評価をして、関連度を決定しています。
「文章加工系」
「文章加工系」は、「オートペディア」専用の部分です。雑多な文章を、なんとなくWikipedeiaっぽい文章に変換するようにしています。結構動作が重いので、そのうち改良して高速化したい部分です。文章を本気で処理していると重くなるということは、プログラムを書いた後に初めて分かりました。
TIPS的な話
以下、開発中に遭遇した問題とその時の対策です。プログラマーには、こういった情報が役に立つかもしれません。
処理速度の問題
通信結果待ちの時間など、どうしても解決できないボトルネックは存在します。処理速度の問題が発生した場合、解決方法としてはアルゴリズムの改良が一般的だと思いますが、インターフェースの工夫でも対応が可能です。
具体的には処理待ちの時間に意味を持たせます。内部的に何をしているのか表示したり、ページ遷移をアニメーションにするなど、技術的な問題はデザインで解決することもできます。プログラムとデザインそれぞれの対応コストを比較して解決方法を選択すると良いでしょう。
検索エンジンとの攻防
検索エンジンによっては、頻繁なアクセスがあるとIPバンをしてきます。例えばGoogleは、一日に一定数以上検索をするとIPバンしてきます。ですからキャッシュを持ったり、分散させたり、検索数を極力減らす必要があります。これは結構頭が痛い問題でした。
Googleアドセンスによる二重読み
これは「全自動4コマ」を作っていた時に、最初理由が分からずに解決に少し時間が取られた問題です。
Googleアドセンスの広告をCGIページに貼っていると、Webページが表示された時点でブラウザーはGoogleアドセンスのJavaScriptをGoogleのサーバーから読み込もうとします。この時Googleのサーバーは、そのページのURLにアクセスして、Webページを取得しようとします。そして、このWebページの取得が終わるまで、JavaScriptを送信しません。そのため、重いCGIを呼び出した場合、Webブラウザーから見るとWebページが止まったように見えます。
この問題は、Webブラウザーに返す情報とGoogleのサーバーに返す情報を切り分けることで解決しました。
負荷の問題
一番アクセスが多かった時点で、1時間に2万アクセスぐらいになっていました。これは、Yahoo!のトップページに記事が載った直後の数字です。この2万という数字は、1分間に333アクセス、1秒だと5.5アクセスになります。私の場合は特に問題になりませんでしたが、契約するサーバーによっては怒られるかもしれません。負荷はなるべく少なくなるように設計しておいた方がよいと思います。
「オートペディア」では、いくつか負荷への対策を施しています。1つは、「全自動4コマ」での経験から、トップページでは負荷の高い生成を行わないようにしました。ユーザーがボタンを押さない限りは、重い処理は行わないようなサイト構成にしています。
また、連続でWebページを生成しようとした場合は、連続アクセスを警告する表示とともにキャッシュを返すことで対応するようにしています。こういった方法で、負荷を軽減するようにしています。
今回得た教訓
TIPSのまとめとして、今回得た教訓についても書いておきます。
キャッシュなどのデータの持ち方は重要です。うまく持たないとサーバーの容量を食い潰してしまいます。このあたりは、Webサービスの内容に合わせて時間を掛けて知恵を絞った方が良いです。あとあと楽になりますので。
おわりに
全自動百科事典『オートペディア（Auto☆pedia）』は、実験的な要素の高い野心的なWebサービスです。
将来コンピューターの性能が格段に上がれば、既存の情報をもとに動的に知的な情報を得られるサービスや、その情報を元に思考する人工知能が次々と現れてくるはずです。しかし、現在個人のレベルで行えるコンピューターの開発では、そういった取り組みを「笑い」の形で提供するのが限度なのが実情です。
現在、ネット上の情報は情報の羅列として扱われることが多いです。しかしそこに関係性を見出し、知的な意味を持たせる取り組みも行われています。資金と環境があれば、そういった情報をもとに知性を生み出す取り組みをやってみたいところです。
たぶん、私の数世代後の時代では、そういった取り組みは当たり前のことになっているだろうと思います。とりあえず、今は遊びにしかならない取り組みですが、生物にとって「遊び」はその先の行動の練習でもあります。こういった遊びを元に、何かこれまでにない取り組みができればいいなと思います。
