2004-07-01
MD4 および MD5 の概要に関しては， RSA Security のウェブサイト内にある解説ページが参考になる。
http://www.rsasecurity.com/rsalabs/node.asp?id=2253
この解説によれば， MD4 に関しては同一のハッシュを生成するメッセージを発見する方法が Hans Dobbertin によって 95 年に発表されている。一方， MD5 に関しては， 91 年に開発されてから現在に至るまで，致命的な弱点は指摘されていない。 94 年に Den Boer と Bosselaers によって擬似衝突が発見されているものの，この擬似衝突がハッシュ自体の衝突を導き出すものとは考えられていない。ちなみにこの「擬似衝突」とは，ハッシュ関数の内部処理に用いられる圧縮関数に関しての衝突のことであり，異なる２つの初期値を与えた場合に衝突の発生する可能性を示すものとなっている。この辺りの話に関しては CryptBytes の記事 "The Status of MD5 After a Recent Attack" に詳しい。
ftp://ftp.rsa.com/pub/cryptobytes/crypto2n2.pdf
MD5 ハッシュの衝突に関しては，現在，独 CertainKey Cryptosystems 社によって１万ドルの懸賞がかけられている。これに対するアタックが Jean-Luc 氏らの分散コンピューティングプロジェクト "MD5CRK" によって続けられているものの，未だその目標は達成されていない。
http://www.certainkey.com/md5challenge/
van Oorschot と Wiener は，並列処理を応用したブルートフォース攻撃によって 24 日以内に衝突を見つけることが可能であるとする論文を 94 年に発表しているものの，コスト等の問題から実行には移されなかったようだ。上の MD5CRK は，この van Oorschot のアイデアを PC 分散環境によって実現したものであるとされている。
セキュリティ分野においては，将来に渡って厳密な安全性を保証する目的から，既に弱点の可能性を提示されている MD5 よりも，更に安全なアルゴリズムである SHA-1 を利用することが多いようだ。
http://en.wikipedia.org/wiki/SHA-1
ちなみに，これらの技術は全て RFC 化されており，ささやかな利用規約さえ守れば，用途にかかわらず誰でも利用することができる。サンプル実装も RFC 文書内に提示されているため，基本的にコピー＆ペーストだけで利用することが可能となっている。
http://www.faqs.org/rfcs/rfc1320.html
http://www.faqs.org/rfcs/rfc1321.html
http://www.faqs.org/rfcs/rfc3174.html
2004-07-02
MD5 に関連する事件と言えば， Netscape Browser のセキュリティ破りの話が面白い。この件に関しては， Dr.Dobb's Journal の記事 "Randomness and the Netscape Browser" が参考になる。
http://www.ddj.com/documents/s=965/ddj9601h/
とは言っても，この事件では MD5 や SSL 自体の安全性が脅かされたわけではなく，単に Netscape 側の実装に存在していた弱点を突かれたに過ぎない。ここで MD5 は乱数生成の手段として流用されていたのだけれど，そのシードとなる値が現在の時刻やプロセス ID であったため，その情報さえ得られればアタックの範囲を容易に絞り込むことができる……という原理であったようだ。
MD5 との組み合わせでよく利用される暗号化アルゴリズムとして RC4 が存在する。 RC4 は MD5 等と同じく RSA 社によって開発されたアルゴリズムであるものの，当初そのアルゴリズムは公開されることなく秘匿されていた。それが 1994 年に Cyberpunks メーリングリストにアルゴリズムの詳細がリークされたのをきっかけに，現在ではその内容はほぼ公然化されている。リークされてからは暗号解析の研究対象として用いられることが多かったようで，数年のうちに具体的な弱点を指摘されるに至っている。
http://www.acm.uiuc.edu/sigmil/talks/crypto/ch07.html
http://www.wisdom.weizmann.ac.il/~itsik/RC4/rc4.html
http://www.cebrasoft.co.uk/encryption/rc4.htm
RC4 はストリーム暗号化に用いられるアルゴリズムであり，つまり，擬似乱数列を生成するアルゴリズムとして扱うことができる（生成された乱数列と元メッセージの XOR をとることにより暗号が得られる）。暗号化アルゴリズムとしての適性を得るためには，乱数の周期性の低さや高速性などを備える必要があり，結局のところ，擬似乱数生成アルゴリズムとしての一般的な性能の高さを求められることになる。そこで，逆に RC4 のような暗号化アルゴリズムを一般的な擬似乱数生成アルゴリズムとして転用することもあるようだ。
ところで，セキュリティ的な問題はひとまず置いておくとして，あるキーの集合に対してユニークなハッシュを得るためには，どの程度の大きさのハッシュ値を用いるべきなのだろうか。この疑問に関しては Bob Jenkins 氏が "Hash Functions FAQ" において回答を提示している。
http://burtleburtle.net/bob/hash/hashfaq.html#unique
「人類の歴史が始まって以来」のくだりは面白い。２の累乗の感覚を得るには，同氏の文書 "Orders of Magnitude" が参考になる。
http://burtleburtle.net/bob/crypto/magnitude.html
余談だけれど，こういった表現を見ていると，イームズの "Powers of Ten" を思い出す。
http://micro.magnet.fsu.edu/primer/java/scienceopticsu/power...
Jenkins 氏の文書によれば， 2^96 は１立方メーターに満たされた水の中に含まれる水分子の個数に相当する。そして， 2^170 ならば地球を構成する全分子数に相当し， 2^190 ならば太陽を構成する全分子数に相当する。たった 24 バイト足らずのビット列の中に，それだけの数の組み合わせが隠されているというのも，改めて考えてみると不思議な話であると思う。
2004-07-05
利用されるキーの集合があらかじめ判明している場合は，ハッシュ値の大きさなどについて悩む必要は無い。完全ハッシュ関数を利用すれば，衝突の発生しない理想的なハッシングを行うことができる。
「完全ハッシュ関数」 (perfect hashing) とは，全てのキーから異なるハッシュ値を導き出す（つまり衝突の発生しない）ハッシュ関数のことを指す。また，完全ハッシュの中でも特に n 個のキーから 0..n-1 の値を導き出すものを「最小完全ハッシュ関数」 (minimal perfect hashing) と呼ぶ。
http://www.nist.gov/dads/HTML/perfecthash.html
http://www.nist.gov/dads/HTML/minimalPerfectHash.html
最小完全ハッシュ関数の導出を行うには，前出の "Hash Functions FAQ" の作者でもある Bob Jenkins 氏の作成したコードジェネレータを利用することができる。
http://burtleburtle.net/bob/hash/perfect.html
完全ハッシュ関数の生成には何通りかの手法が存在するようだ。 Jenkins 氏の実装は Fox, Heath, Chen, Daoud の実装を基にしている。その原理は比較的シンプルなものだ。まず，２種類の異なるハッシュ関数を利用して，ユニークな値のペア (A, B) を求める。次に， A^tab[B] が全てのペアに関してユニークとなるようなテーブル tab を求める。
特定のキー集合とハッシュ関数の組み合わせによっては， (A, B) のペアに重複が生じてしまう場合があるものの，その場合はハッシュ関数を変化させながら試行を繰り返すことによって重複の無い条件を求めるようになっている。また，テーブルの内容を求める処理に関しては，この問題が NP 完全に属することが知られているため， Spanning Tree によるヒューリスティックが利用されているとのことだ（この辺りは難しくてよく分からない）。
Jenkins 氏のコードジェネレータでは，完全ハッシュと最小完全ハッシュの２種類がサポートされている。最小完全ハッシュでは，ハッシュ値の上限が「キー数－１」となることが保証されているものの，テーブルサイズは完全ハッシュのものよりも多少大きくなってしまう。とは言っても，３万８千語の英単語に対してテーブルサイズは 16kB 程度で済むとのことだから，深刻な問題になることは無いだろうと思う。
同様に最小完全ハッシュ関数を生成するツールとしては GNU の gperf が有名であるものの， Jenkins 氏によれば， gperf はアナグラム（例えば "art" と "tar"）の扱いに難点があると指摘されている。
http://www.gnu.org/software/gperf/gperf.html
このような完全ハッシュ関数は，キー構成さえあらかじめ判明していれば，どのような場面にでも利用することができる。しかし，実際に完全ハッシュ関数を利用することによって多大な恩恵を受けることのできる場面は，それほど多くないかもしれないと思う。例えば，「データの識別名の代わりに，識別名のハッシュ値（最小完全ハッシュ関数によるもの）を格納する」などというのは，すぐに思いつく利用法であるものの，識別名の構成に変更が発生する度に完全ハッシュ関数の再生成を行わなくてはならないため，運用に問題の生じる可能性が高いと感じられる。
それでも，例えばリリース用のデータに格納される識別名や， ROM メディアのファイルアクセステーブルなどのように，絶対に構成の変化することのない情報に関しては，このような完全ハッシュ関数を上手く応用することができるだろうと思う。そうすれば，データ側では識別名を文字列として保持する必要は無くなり，要素数（高々数千個程度だろう）に対応するビット幅を持つ整数値を，ただ保持すれば良いことになる。
2004-07-06
Bob Jenkins 氏のウェブには，他にもハッシュと乱数に関連した様々な文書が置かれており，非常に面白い。
http://burtleburtle.net/bob/hash/index.html
なかでも特に参考になったのは， "Hash Functions for Hash Table Lookup" と題された文書だ。
http://burtleburtle.net/bob/hash/evahash.html
この文書において氏は，テーブルルックアップの用途に開発された自作のハッシュ関数を紹介すると同時に，ハッシュ関数として好ましい性質を得るために必要とされる要素について解説を行っている。自分は，このようにハッシュ関数の性質について解説を行った文書を他に読んだことが無かったので，非常に参考になるものがあった。
件のページからリンクによって辿ることのできるページの中にも，様々な情報が提示されている。例えば， "Examples of Hash Functions for Hash Table Lookup" では，他の代表的なハッシュ関数を挙げたうえで，それらの関数が持つ性質の比較を行っている。
http://burtleburtle.net/bob/hash/examhash.html
この比較結果を見てみれば，加算式ハッシュの性能の悪さが群を抜いていることが分かるのではないかと思う。氏の設計した "newhash" 関数は，速度に関して定数部分（文字数に関連しない部分）の負荷が比較的高いものの，１文字当たりの命令数はかなり抑えられている。実際には，テーブルを利用していないこと（他のハッシュ関数は内部でテーブルを利用していることが多い）と，並列性が若干高くなっていることから，最適化によってパフォーマンスの改善を行う余地が残されているのではないかと思う。
別のページ "Proving that a hash has no funnels" では，ハッシュ関数の性能を低下させる要因のひとつである "funnel" （漏斗）現象について解説を行っている。
http://burtleburtle.net/bob/hash/funnels.html
funnel とは，ハッシュ関数の内部ステートにおけるビットの変化が，入力された文字の中にあるビットの数よりも少なくなる現象を指す。内部演算の過程に funnel を持つハッシュ関数は，似通ったビット構成を持つキーに関して衝突の発生する可能性が高くなる。そこで氏は，あるハッシュ関数が funnel を含まないために必要とされる条件を導き出し，それらの条件を newhash 関数が満たしていることを示している。
Jenkins 氏は "Hash Function FAQ" において，「バケット数が 256 以下であれば，どのようなハッシュ関数を使っても構わない」というような内容の記述を行っている。ゲームなどの用途においては，大規模なハッシュテーブルを利用することはあまり無いだろうから，ほとんどのケースでは「どのようなハッシュ関数を使っても構わない」のだろうと思う（むしろ気になるのは，「これは B-Tree でも良いのではないか」と思うような場面においても，躊躇無くハッシュテーブルを使ってしまっていることだろうか……）。
それでも，例えば，膨大な数の設定項目を管理する場面や，テクスチャやマテリアルに対応する識別子を管理する場面などにおいては，大規模なハッシュテーブルが必要とされる場合もあるだろうと思う。そのような場合においては，やはり，衝突の少なく，かつ処理の並列性の高いハッシュ関数を用いることによって，一定の効果を得ることが可能になるのではないかと思う。
2004-07-07
Bob Jenkins のページには，ハッシュに関連した話題の他にも，乱数や数学や物理など，様々なコンテンツが置かれている。
なかでも特に興味を誘われたのが，退行テストツール "jenny" のページだ。
http://burtleburtle.net/bob/math/jenny.html
jenny は，退行テストの中でもフィーチャー間の相互干渉の検証に焦点を当てたツールだ。氏の解説には次のようにある。
例えば，あるモジュールに関して，真否を取りうる１２個のフラグが存在した場合，このモジュールの徹底的なテストを行うには， 2^12=4096 個のテストケースを適用する必要がある。
しかし，実際には１２個すべての要素が関連する複合的なバグが存在する可能性は非常に低く，多くの場合においては，バグはたった１つの要素か，あるいは２つの要素か，多くても３つ程度の要素が関連することによって発生すると考えることができる。そのような前提が成立する場合に，「徹底的なテスト」を行うのは非効率的だ。
例えば，「１２個あるフラグのうち，任意の２つのフラグに関してすべての組合せをカバーしているようなテストケース群」を求めた場合，その個数は４０９６個よりもずっと少なくなるはずだ。 jenny は，このような条件を満たすパターンを自動生成してくれるツールだ。試しに解を求めてみた結果を以下に挙げる。１０個のテストケースによって前述の条件を満たしていることが分かるはずだ。
jenny のコマンドライン引数に，テストの対象となるフィーチャーの構成と，組合せの数を指定すると，その数の組み合わせをカバーするのに必要とされるテストケース群を生成し，出力してくれる。あとは sed を適当にかますなどして，自分のモジュールに対して適用することのできる形に直してしまえば良い。
この jenny は小さなツールでありながらも，非常に面白い着眼点を持ったツールであると思う。自分は厳密な退行テストを用意した経験が無いため，このような用途のツールの真価は計りかねる。しかし，組み合わせの問題を効率的に解くことによって，テストの手間を大幅に減らすことができるという点だけを見ても，非常にクレバーな解決法であると言うことができると思う。
2004-07-08
スクリプト言語 Lua は，手軽な組み込み用の処理系として徐々に認知されつつあるように感じられる。特に， Jon Burns 氏と David Eichorn 氏の司会によって行われた GDC 2004 のラウンドテーブルセッション "Lua in the Gaming Industry" の内容は印象的だ。
http://www.cmpevents.com/GDx/a.asp?option=C&V=11&SessID=2272
アーカイブから同セッションのレポートをダウンロードすることができる。
http://www.gdconf.com/archives/2004/burns_jon.doc
両氏は，元は Gas Powered Games および Reric Entertainment のスタッフであり，現在は Microsoft Games Studios の従業員となっているようだ。
http://www.mobygames.com/developer/sheet/view/developerId,58...
http://www.mobygames.com/developer/sheet/view/developerId,10...
両氏が実際に Lua を使用したプロダクトは明らかにされていないものの，同社において開発の行われている様々なゲームタイトルが， Lua を組み込みスクリプト言語として利用していることが明かされている。
ちなみに，実際に Lua を使用しているプロダクトの一部は， Lua のウェブページに掲載されているリストの中に見つけることができる。
最近のタイトルでは "FarCry" や "Psychonauts", "Painkiller" 辺りが挙げられるのではないかと思う。また，このリストに載せられていないタイトルも多く存在すると考えられる（このリストは自己申告によって作成されているため，特に申告が無ければ載せられることはない）。
レポートを読んでみてまず驚くのは，このセッションに対する聴衆の興味の高さだ。最初のセッションには約６０人の参加者が集まり，２回目のセッションには約４５人の参加者が集まったと報告されている。
レポートには，実際に Lua を組み込んだ経験から得られた様々な情報が載せられており，非常に興味深い内容となっている。
まず始めに興味を引かれたのは， Lua 4.0 から Lua 5.0 へのバージョンアップに伴ってパフォーマンスの改善が行われているという話題だ。レポートには，この移行によって 20% ものパフォーマンスの向上が得られたという体験談が載せられている。自分の場合は，パフォーマンスの要求されるような箇所には Lua を利用していないことと，パフォーマンスが問題となるほど大規模なスクリプトを処理させていないことから，パフォーマンスに対する注目は非常に低いものとなっていた（したがって，その辺りの検証もほとんど行っていなかった）。ともかく，今敢えて Lua 4.0 を選ぶ理由は無いということが判明しただけでも，得るものがあったと思う。
次に触れられているのは Lua と Python の比較の話題だ。個人的には，この２つの言語はそれぞれ明らかに異なった性質を伴っているために，同列の存在として比較を行うこと自体に少々無理があるようにも感じられる。最も重要な違いは， Lua は組み込み用途に特化されているのに対して， Python はそうではないという事実だ。 Python を組み込みの処理系として用いるには， Python の内部構造をよく理解し，己の必要とする条件に合わせてビルドする手段を用意し，自ら運用を管理する覚悟を決めなければならない。これが Lua であれば，必要なソースをコピーしたのちに，数個の関数を呼び出してリンクするだけで，確実な導入を実現することができる。何らかの特別な意図が存在するならともかくとして，ただ単に適当な機能を備えた処理系を必要としているだけであるならば， Lua が適当な選択肢となってくれるはずだ。
2004-07-09
実際に Lua を組み込みの処理系として利用している身としては， Lua の運用にあたって発生した問題に関して触れている部分には，非常に興味をそそられるものがある。
やはり，この手の処理系ではガベッジコレクションが鬼門となるようだ。 Lua においてもそれは例外ではなく，使い方次第では苦しめられることになるのではないかと思う。自分の場合は，定期的に呼び出されるようなタスクには Lua は利用していないため，ガベッジコレクションが問題となることはなかった。これが例えば，ステートを常に保持しつつ，一定の間隔で Lua の機能を呼び出すような処理を行っている場合には，特別な注意が必要だ。ガベッジコレクションが上手くメモリを回収してくれないと，メモリが徐々に食い潰されてしまう危険性がある。まだメモリ的な制限が厳しいコンシューマゲーム機においては，総メモリ使用量が断定できないという仕様は，なかなか受け入れ難いものがあるのではないかと思う。
Lua のガベッジコレクションに関しては， lus-users wiki の方にノウハウが載せられている。実際に役に立つかどうかは分からないものの，情報源としては価値のあるものとなっているのではないかと思う。
http://lua-users.org/wiki/GarbageCollectionInRealTimeGames
http://lua-users.org/wiki/LuaInRealTimePrograms
とりあえずのところは， Lua ステートの長期的な保持は避けるというのが，確実な対処法であると思う。
他の話題としては，実際に Lua を利用した用途についての報告が載せられている。
また他にも，プログラマ以外の人員に Lua を利用してもらうことに関する話題が載せられているものの，この件に関しては，どうせならもう少し詳しく掘り下げてみて欲しいというのが個人的な感想だ。この点こそがスクリプト言語を導入する本来の目的の１つであるとともに，自分が未だに納得する解法を得ることができていないという点において，非常に興味のある話題となっている。
自分にとって Lua や XML のような技術は，「既に枯れた（安定した）技術基盤」として魅力のあるものとなっている。どちらの技術も，他に適当なソリューションを持ち合わせている人々にとっては，さほど重要なものであるとは感じられないかもしれない。しかし，そういったものを持ち合わせていない人々や，そういったものを自ら管理することによって発生するコストやリスクといったものを排除したいと考えている人々にとっては，これらの技術はやはり魅力のあるものとして映るのではないかと思う。それは，これらの技術が，大抵の用途には適合させることのできる高い汎用性を持ち合わせており，なおかつ，それらの要素において特殊性を求めることが製品にとって重要な行為ではないと考えられるためであろうと思う。
2004-07-12
近年， Microsoft の Office シリーズは，データ形式としての XML を本格的にサポートするようになってきている。現状での最新版であるところの Office 2003 においては， WordML (WordProcessingML) や XMLSS (XML Spreadsheet) などのような， MS Office 元来のネイティブフォーマットと機能的な互換性を持つ XML ファイルフォーマットへの対応が行われている。
http://msdn.microsoft.com/library/default.asp?url=/library/e...
http://rep.oio.dk/Microsoft.com/officeschemas/wordprocessing...
このような代替ファイルフォーマットへの対応は，以前は HTML をベースとして行われていた試みの再来なのだろうと思う。 90 年代の後半に行われた Word の HTML 対応は， Word によってウェブページをデザインすることが目的ではなく，ウェブサーバを経由した Word 文書のダイレクトな交換が本来の目的であったことが， Chris Pratley 氏のブログ記事 "Word Myths and Feedback" において明かされている。
http://blogs.msdn.com/chris_pratley/archive/2004/04/28/12200...
そのような事情はさておき， XML ファイルフォーマットへの対応は， MS Office における XML 対応の中でも最も分かりやすいものであると感じられる。これらのファイルフォーマットの登場によって， Word 文書や Excel シートの中身を XML データの一種として扱うことが可能となった。これは，既存の XML ツールセットの応用を可能としたという点において，大きな機能的向上であると言うことができる。
これ以前も，例えばカンマ区切り形式 (csv) などを利用することによって，簡単な読み取りを行うことは可能であったものの，これだと逆に書き込みを行うことが非常に難しかった。あるいは， COM を利用すればダイレクトにアクセスを行うことが可能であるものの，これは簡便性の面においてやや不利な選択肢であると個人的には感じられる。結果的に XML を用いたアクセス手段は，最も汎用性に優れ，かつ高い簡便性を持つ解決法であると言うことができるのではないかと思う。
このように， MS Office における XML ファイルフォーマットへの対応は，非常に分かりやすい利点を提供することができているものの， Pratley 氏をはじめとする MS サイドの技術者に言わせれば，これは数あるフィーチャーの中のひとつに過ぎない。いわく， MS Office 2003 における XML サポートの本当の目玉は，各アプリケーションにおける XML データのネイティブ対応であるとされている（ただしこれは Professional Edition にしか用意されていないフィーチャーだ）。
MSDN の "XML in Office" のページには， Office において XML を扱うための情報が集められている。
http://msdn.microsoft.com/office/understanding/xmloffice/def...
Word における XML 活用の例は，非常に分かりやすいものであると感じる。 Professional Edition の Word には XML ノードを編集するための機能が追加されており，任意のスキーマを与えることによって，そのスキーマに適合した構造を持つ XML 文書を簡単に作成することができるようになっている。
http://msdn.microsoft.com/office/understanding/xmloffice/get...
XSL スタイルシートを用意すれば，それらの文書に対して任意のスタイルを与えることもできる。
http://msdn.microsoft.com/office/understanding/xmloffice/art...
一方， Excel における XML 活用の方法には，少し分かりにくいきらいがあるように感じられる。基本的には， XML スキーマから Excel シートへのマッピングを定義しておくことによって， Excel 上で XML データを直接に編集することができるようになる，というもののようなのだけれど，使い勝手に関していまいち把握の難しい部分があり，実際に運用を試みるまでには至っていない。
http://msdn.microsoft.com/office/understanding/xmloffice/art...
2004-07-13
最近では，以前ならば Excel やテキストファイルなどを利用していたような場面において， InfoPath を利用することも多くなってきている。
http://www.microsoft.com/japan/office/infopath/prodinfo/defa...
InfoPath に関しては，発売以前から世間の注目を集めていたことから，ほどなく手頃な書籍が手に入れられるようになるだろうと予想していた。したがって，リソースが充実するまでの間は，とりあえず最低限の機能を扱うことができれば良いと，半ば割り切りを持って利用を続けてきた。しかし，発売から半年が過ぎた今となっても，満足するだけの量のリソースが揃っていないような気がする。
Amazon で検索してみても，和書洋書合わせて両手で数えられる程度の数しかヒットしない。
http://www.amazon.co.jp/exec/obidos/search-handle-url/index=...
http://www.amazon.co.jp/exec/obidos/search-handle-url/index=...
InfoPath 関連サイトにおいては， Roger Jennings 氏の "Introducing Microsoft Office Infopath 2003" が紹介されていることが多い。 Microsoft Press からの出版ということで，一応「公式入門書」的な扱いとなっているようだ。
http://www.microsoft.com/mspress/books/6511.asp
著者のウェブページ (OakLeaf Systems) からは，サンプルプロジェクト等をダウンロードすることができる。
http://www.oakleaf.ws/infopath/
書籍の解説には次のようにある。
自分には少し内容が高度過ぎるような印象を受ける。何も，これを使って IT 稼業を始めようというわけではないので，もう少し基本的な所さえ把握できれば，それで十分に満足することができるのだけれど……。
InfoPath に関する情報は， InfoPath 開発チームによって運営されているブログサイト "InfoPath Team Blog" から得られることもある。
http://blogs.msdn.com/infopath/
ちょっとした小技の紹介や，雑多な技術情報，サービスパックの予告など， InfoPath を利用するにあたって役に立つ情報が色々と載せられている。ただし残念なことに，更新頻度はそれほど高くない。最近はとみに頻度が落ちており，今月に入ってからは，まだ１件もポストが無い状態となってしまっている。インフォーマルな情報源として期待していただけに残念なことだと思う。
その他，基礎情報に関しては MSDN を参照することができる。
http://msdn.microsoft.com/office/understanding/infopath/defa...
InfoPath は，データ操作用のツールとして非常に役立つソフトウェアではあるものの，現状ではまだ Excel の方が適しているシチュエーションも多いというのが，ひとまずの結論だ。 Excel を好む理由のひとつには， InfoPath において２次元的な広がりを持つ表を扱うことが難しいという問題がある（これには，単純な操作性の問題も絡んでいる…… InfoPath の操作性は，まだ十分に洗練されていないと感じられる）。もうひとつの問題としては，スキーマとフォームによって厳密な制限を行うことが，データ入力者にとっては必ずしも都合が良いとは限らないという問題がある。とりあえず Excel にデータを格納しておけば，あとはデザイナ陣の中にいる Excel 名人が都合の良いようにやってくれる……そういう期待をすることが， InfoPath では難しくなるということだ。
2004-07-14
想定外の事態により停滞せざるをえない状況へと追い込まれていた作業が，様々な人々の努力のおかげで，ようやく回復の兆しを見せようとしている。数週間前には，これ以上無いというぐらいまで高まっていたリスクも，今では予測可能な範囲内に収まっていると感じる。ともかく，次のマイルストーンまでもう何週間も残されていない今となっては，否が応でも前進を始めなくてはならない。ひとたび動き始めればゴールはそう遠くないはずだと考えている。
「もし Guido （Python の作者）がバスに轢かれたらどうする？」という問いかけを Python のメーリングリストに投稿したのは NIST の Michael McLay 氏だった。氏の投稿は一種のユーモアのようにも見えて，その実は悲痛な訴えに満ちている。
http://www.python.org/search/hypermail/python-1994q2/1040.ht...
人は，バスに轢かれなくとも，突然居なくなってしまうことがある。風邪をひけば１日ぐらい居なくなってしまうだろうし，酷い風邪ならば２，３日は居なくなってしまうかもしれない。本格的な事故や病気にもなれば数週間や数ヶ月居なくなってしまうことだって珍しくない。他にもアクシデントの種はいくらでも日常生活の中に転がっている。もちろん，戻ってこれなくなってしまうことが，その中でも最も深刻な事態ではあるものの，実のところ時間の長さは問題の本質ではない。重要な時期に重要な人物が少しの間でも居なくなってしまえば，それだけでプロジェクトに対して深刻なダメージを与えることができる。
事態が起こってしまった場合まず行うべきことは，マンパワーを補充することだ。これは，状況によっては難しい場合があるものの，解決することは決して不可能ではない。マンパワーの補充が実現できたならば，リソースとナレッジの引渡しを行うことによって，やがて以前の状態まで復帰されるものと考えることができる。問題となるのは，引き渡されるべきリソースやナレッジといったものが，前任者の記憶の中にしか存在しなかった場合だ。
普段から自分が居なくなったときのことを考えて行動している人は，それほど多くないかもしれない。これは無理もないことだと思う。自分と組織が係わりを持つことから現状が生み出されているのだから，その係わりが途絶えたときのことまで将来の可能性として含めるということは，非常に難しく，かつ理性を必要とされることであると考えられる。
しかし，組織の側から見てみれば，個人は常に居なくなってしまう可能性を秘めている。その可能性を制御することは基本的に不可能であるから，むしろ居なくなってしまったときのことを考えて善後策を練らなくてはならない。
このことは，情報と知識の文書化を義務付ける強い動機のひとつとなっている。どんなに聡明な頭脳や確かな記憶力を備えた人でも，その頭脳が人と共にある限り，入出力のスループットは人の持つ機能的な制限に束縛される。そしてその内容は，他愛も無い理由によって一時的に使えなくなってしまったり，場合によっては一瞬にして全て失われてしまう危険性も備えている。
ゆえに，どのような種類の情報にも文書化されることに価値があると考えることができる。
もちろん，文書の作成には一定の労力が必要とされるから，余計な情報まで文書化しようとすれば，要らぬコストを抱え込んでしまう危険性も考えられる。しかし逆に言えば，だからこそ普段から効率よく情報を文書化する能力を身につけることが重要であると考えることができる。口頭でのやりとりをメモに残し，ソースには十分な量のコメントを書き加え，様々な結論に至るまでの思考を文章によって表現し，自分の中に蓄えられた暗黙知を形式知へと変換する努力を絶やさない……そうして残していったものが，自分以外の人間をどれほど助けることになるのか知ったとき，本当に行うべきことが見えてくるのかもしれないと思う。
2004-07-15
マイルストーンが目前に迫りつつある。この時期はゲーム内のフィーチャーを担当しているプログラマにとって最も楽しい時期かもしれない。普段はサマにならないプロトタイプや中身の無いシステムばかりを作成しているのが，この時期になると急に具体的なものが出来上がってくるようになる。手元には予定されているフィーチャーを完成させるのに十分なだけの素材が揃っている。これを形にするにはプログラマとゲームデザイナがもうひと踏ん張りしなければならない。労働量はどうしても増えてしまうのだけれど，結果として得られる充実感はその見返りとして相応しいものであると感じる。
こんな事を言ったら本当のＳＥ屋さんには怒られてしまうかもしれないけれど，自分の仕事はＳＥ的な側面が強まってきているように思える。職場に居る間の半分程度か，あるいはそれ以上の時間がコード書き以外の仕事に費やされている。自分が決められることを自ら決定し，決められないことについては然るべき担当者と相談を行い，様々なメールを書き，様々な文書を作成し，時には口頭での交渉を行い，ミーティングに出席し，スケジュールを確認し……平日の昼間は，おおかたそのような雑務によって埋め尽くされる。純粋なコード書きだけだったら，夜中や休日の間に一人で行うこともできる。人が揃っていなくてはできないことをするのがコアタイムの使い方であると考えるようになってきた。
理論上の話をすれば，コアタイムの無い形態や，あるいは自宅勤務などの形態によっても，ゲームを制作することは可能なのだろうと思う。実のところ，いわゆる「修羅場」に突入する前の中長期的なスケジューリングが行われる時期においては，そのような形態をとることも可能であると感じることがある。しかし，実際に各種の要素を結合させてコンテントを形作る段階へと入ると，その場の判断によって変動する要素があまりにも多くなってくるため，全員が綿密なコミュニケーションを行いながら作業を進行させることが重要であると感じるようになってくる。
この「修羅場」に見られる独特のライブ感を表現するには，映画撮影のアナロジーが上手く当てはまるのではないかと思う。映画制作においては，撮影を開始する以前から脚本やコンテや美術素材の準備が進められる。この段階では，まだそれぞれの作業は独立性が高いため，平行して別々に進めることが可能であるはずだ。しかし，撮影を行う段階においては，それら全ての要素が一点に集結される必要がある。撮影現場はリアルタイムに変動する要素に満たされており，それに立ち向かうために用意された唯一の武器は監督の決断力だ。これに関しては，以前 Bob Congdon 氏が行っていた映画監督ジョン・セイルズの著書 "Thinking in Pictures: The Making of the Movie Matewan" からの引用が参考になる。
http://www.bobcongdon.net/blog/2004/04/priorities.html
映画監督が現場において行っている決断の多さと複雑さがよく伝わってくる文章であると思う。興味深いのは，これらの決断を行うにあたって，事前に優先順位を定めておくことが重要であるという指摘だ。実際のところ，厳密に定められた優先順位の存在は，監督（ディレクター）自身が決断を行う際の材料となるという他にも，実際に作業を担当する人達にとっても重要な参考要素として働く。あるコンテントを完成させるにあたって，何が最も重要であり，何が重要でないのだろうか？ それは傍から見れば自明なようでもあり，実際のところは不明瞭になりがちな要素でもある。責任者の行う各種の決断と，担当者間のコンセンサスが重要となる所以でもある。
2004-07-16
最近また，一日あたりに送受信するメールの量が増えつつある。仕事が忙しくなったり，何か重要な出来事が起こったりすると，決まってメールの流量が増えてくる。まだそれでも，自分程度の量は大したことのない方であり，ディレクターやプロデューサーともなると，一日に恐ろしい量のメールを処理することになるというのだから，メールの持つ簡便性というものも時に難儀なものであると思う。
コミュニケーションの道具としてのメールには，幾つかの重要な利点を見出すことができる。例えば，相手の時間を拘束しないこと，文書であること（記録に残ること），複数人に対して同時発信が可能であること，等々。特に同時発信の機能はコラボレーションを行う上で重用な機能であり，情報伝達の手段として敢えてメールを利用する際の主な動機のひとつともなっている。
しかしだからといって，ＣＣをできるだけ増やして，ありったけの情報をメールで流せばよいというものでもない。各々のメンバーは，メールの読み書き以外の実務を本業としている以上，メールのような拘束力の弱いコミュニケーションに対して割くことのできる関心というものは，かなり限られているものと考えることができる。では，その限界を超えた量の情報をメールで送りつけるとどうなるのか……結果は簡単で，本人が重要でないと感じたものから順に漏れ出してしまうことになる。その判断は送信者の意図に関係無く行われるため重要な情報が伝わらなかったり，逆に大して重要でない方の情報が伝わったりというように，認識の相違が生じてしまう。
自分がメールを書く際に，最も躊躇する理由となるのが，この点だ。メールを送れば送るほど，そのメールに対して払われる関心の密度は薄まってしまう。今から送るメールは，本当に必要なことを伝えようとしているのだろうか？ 相手のキャパシティを無駄に埋めてしまってはいないだろうか？ こうしてメールを送りつけることが，他の重要な伝達事項の重要性を薄めてしまってはいないだろうか？
これまでの経験から，メールによって行われるコミュニケーションには，主に２つの役割が存在するものと考えられる。ひとつは，合意（コンセンサス）を得るために行われるコミュニケーションであり，もうひとつは，即時性の必要とされる連絡だ。後者は口頭での連絡やメモ書きの延長線上にあるものと考えられるとして，前者はメールの利点が有効に活かされる場面でもある。メールの持つ記録性は，後から合意事項の確認を行うことを可能とし，また，同時発信の機能は，複数人に対して合意を得る手段として有効なものとなる。
しかし，そうして得られた合意も，結局は非形式的なものであることを認識しなくてはならない。メールや口頭でのやりとりによって得られる合意は「狭い当事者の間での合意」であり，プロジェクトチーム全体に対しての共通認識とはなり得ない。例えば，合意の過程に参加していないメンバーが合意の内容を知るにはどうすればよいのか。あるいは，後にその要素の影響範囲が拡大した場合に，拡大した範囲に関しても合意を保つにはどうすればよいのか。「細かな合意の総和として最終的な共通認識が存在する」という状態では，これらの問題に対処することは非常に困難だ。それだけでなく，実のところ，狭い当事者の間に限定しても確実な共通認識を成立させることは難しいと感じられる。途中の合意項目が少し変化しただけでも，最終的な見解が異なってしまう危険性があるためだ。
これらの問題を解決するためには，あらゆる項目の結論を常に何らかの形式の文書によって提示することが重要であると考えられる。ある仕様に関して質問を行ったとして，その返答が「それに関しては，最初はＡであったものがＢの理由によってＣとなったものの，ＤとＥの影響によって変更せざるをえなかったため，現在はＦとなっています」というようなものでは，恐ろしく話の通りが悪いし，いつ「伝言ゲーム」が発生してしまうかも分からない。最後の「Ｆ」を簡潔に文書にまとめ，素早く参照することのできる手段によって公開することができれば，情報の伝達は随分と確実なものになるだろうと思う。
以上のような理由から，メールはあくまでも非形式的なコミュニケーション手段のひとつであり，理想的な運用にはある種のコツが必要とされるものと考えられる。メールによって伝達される情報は，できる限り簡潔に保たれる必要があり，それらのコミュニケーションによって導き出された結論は，形式的な文書の形にまとめることによって，はじめて確実な認識となりうる。現状での自分の結論は，そのようなところだ。
2004-07-20
デッドラインが間近に迫っている。結局，三連休は全て出社だった。休日にもかかわらず職場にプログラマが全員揃っているのが驚きだ。前回のマイルストーンと比較すれば楽観できる状況にあるとは思うのだけれど，それでも厳しい部分が残されていることには変わりがないようだ。
仕事ばかりでは気が滅入ってしまうので，気晴らしでもしようと，「２００１年宇宙の旅」と「天空の城ラピュタ」のＤＶＤを観る……選択にあまり意味は無くて，たまたま手元にあったＤＶＤを適当に選んだまでだ。
「ラピュタ」を観終えた後に，何気なく Wikipedia 内の "Laputa - The Castle in the Sky" のページを覗いてみると，次のような記述があった。
http://en.wikipedia.org/wiki/Laputa_-_The_Castle_in_the_Sky
ラピュタの名称がガリバー旅行記からの引用であることは知っていたのだけれど，その名に特別な由来があることは知らなかった。スウィフトは人間とその社会を風刺する意図を込めてこの物語を記している。奇妙な科学を備えた空を飛ぶ島を「ラピュタ」と名付けたのも，氏にとってみれば皮肉のうちであったのだろうと思う。
スウィフトの「ガリバー旅行記」は，原民喜氏の訳のものを青空文庫からダウンロードすることができる。
http://www.aozora.gr.jp/cards/000912/card4673.html
この物語において，ラピュタは科学に傾倒した変人たちの住む国として描かれている。その人々の理解し難い行動を批判的に描くことによって，科学を盲信することの愚かさを指摘しようとしている……と言えば聞こえが良いかもしれないけれど，実際には，まっとうな批判というよりかは，筆者自身の内にある科学に対しての嫌悪感を吐き出しているだけに過ぎないと感じられる。同作品における他の章は，人間社会の愚かな側面や，人間の本性の汚らわしさなどを主題として扱っており，氏の政治的な嗜好や生理的な感覚などが色濃く反映されたものとなっている。そしてこの章は，氏の科学全般に対する嫌悪や恐怖といったものが反映されたものなのだろうと思う。
ガリバーはラピュタを降りた先においても，同じように科学に傾倒した国の惨状を目の当たりにすることになる。
青空文庫では，スウィフトの記した他の文献も参照することができる。「アイルランドにおける～」がそれなのだけれど，中身を読んでみて，そのとんでもないブラックぶりに思わず目を疑ってしまった。
http://www.aozora.gr.jp/index_pages/person912.html
晩年は発狂したと伝えられているのも，納得することのできるところであると思う。
2004-07-21
仕事が忙しくなってくると，ブログ巡回は控えめになってくる。今はもっぱら，以前から読まずに溜め込んでいた PDF を印刷して通勤中に読むようにしている。例えば，先日読んだのは John E. Laird 氏の "It Knows What You're Going to Do: Adding Anticipation to a Quakebot" だった。
http://ai.eecs.umich.edu/people/laird/papers/Agents01.pdf
http://www.cs.ubc.ca/~coelho/cs538A/Quakebot.html
Laird 氏はミシガン大学工学部の教授であり，ＡＩと認知モデル，およびコンピュータゲームを専門分野としている。氏のウェブページにおいては，上の論文以外にもゲームＡＩに関連した様々な論文が公開されている。
http://ai.eecs.umich.edu/people/laird/gamesresearch.html
また氏は，同大学において Computer Game Design の講義を担当しており，こちらもなかなか興味深い内容となっている。非常に充実した内容の資料が印象的だ。
http://www.eecs.umich.edu/~soar/Classes/494/schedule.htm
それで，件の論文 "Adding Anticipation to a Quakebot" を読んでいたところ，前知識として足りていないものがあることが分かった。ＡＩアーキテクチャ "Soar" についての知識だ。
http://sitemaker.umich.edu/soar
http://en.wikipedia.org/wiki/SOAR
この "Soar" アーキテクチャは，上記ページの解説によれば，「知的な振る舞いを見せるシステムを開発するための一般的な認知アーキテクチャ」となっている。平たく言えば「ＡＩプログラミング言語」の一種であり，いわゆる「プロダクションルールシステム」と呼ばれる方式に分類される言語であるようだ。
http://en.wikipedia.org/wiki/SOAR
ＡＩ研究の大家であるところの Allen Newell 氏が係わった仕事としても知られている。
http://stills.nap.edu/readingroom/books/biomems/anewell.html
自分は，この手の言語には全く触れたことが無いのだけれど， "Soar Documentation" のページにおいて配布されているチュートリアルが大変分かりやすくできているため，比較的容易に習得することができそうだ。
http://sitemaker.umich.edu/soar/documentation_and_links
講義の教材や研究の道具として使われているということもあって，このように文書の類が充実している。件のチュートリアルは，基本的にプログラミング言語を習得したことのない人々を対象としており， Soar アーキテクチャにおけるプログラミングの手順を基礎から応用まで丁寧に解説している。また， "Eater" や "TankSoar" と名付けられたサンプルゲームのＡＩ構築を題材としているため，ゲームＡＩの習得が目当てである人々にとっても親しみの持ちやすい内容になっていると思う。
Soar を利用したプログラミングにおいては，「プロダクションルール」と呼ばれる推論規則（平たく言えば "if-then" の集合）を基本要素として処理の記述を行う。また，シンタクスとしては Lisp のような関数型言語を基本としている。結果として， C や C++ のような手続き型言語とはまったくかけ離れた世界となっており，このようなプログラミングの世界も存在していたのかという驚きが感じられた。これだけでも，なかなか面白い経験であると思う。
2004-07-22
Soar のチュートリアルは，とりあえず Part III まで読んでみた。 Part III では，サンプルプロジェクト "TankSoar" を題材として，サブステート (substate) の概念が解説されている。マニュアルによれば，サブステートとは，あるステートが「袋小路」 (impasse) に辿り着いてしまった場合に，それを解決するために自動的に生成される下位構造であるとされている。しかし TankSoar の例においては，もっぱらルールを階層化するための手段として用いられている。上位レベルのオペレータは "Chase" や "Attack" 等の抽象化された行動を扱い，下位レベルのオペレータは "Move", "Turn", "Fire" 等の具体的な行動を扱う。そうすることによって，異なる上位レベル行動において下位レベル行動を共用することが可能となる。また同時に，ルールの記述が抽象レベルに応じて分離されるため，各ルールの関係が把握しやすくなるという利点もある。
この辺りの仕組みに関しては，階層ステートマシンによって同じような仕組みを設計した経験がある。概念的には似たものであるものの，敢えて異なる点と挙げるとすれば， Soar の例においては，状況の判断から解決方法の候補を挙げる「オペレータの提案」 (operator proposal) と，選択されたオペレータに対応する処理を実行する「オペレータの適用」 (operator application) が，完全に分離されていることだ。この方式による明らかな利点は，ルールの評価順序に起因する問題が少なくなる点であると考えられる。 C や C++ のような手続き型言語においては，どうしてもシーケンシャルな記述になってしまうものが， Soar のようなプロダクションルールをベースとしたシステムにおいては，一定の規則に沿って「判断の基準」と「結果として生じる操作」の記述を行っておけば，あとは実行系が自動的に解決を行ってくれる。
Part IV 以降は，もう少し細かい応用の話になってくるため，詳しくは読んでいない。最後の Part VI においては，件の論文の "Soar Quakebot" が題材として取り上げられている。ただし，現在この bot は配布されていないようだ。残念……。
何か実際に作ってみるほどの暇は無いものの，もう少しこの手のシステムに関して調べてみようと考えている。
2004-07-23
ＡＩ分野の基礎知識に関しては，山梨大の大渕助教授による人工知能論の講義ノートが参考になる。
http://www.kki.yamanashi.ac.jp/~ohbuchi/courses/2004/ai2004/...
探索やエキスパートシステム，学習，パターン認識，最後にはＶＲやＡＲなど，非常に興味深い話題が揃っており面白い。ニューラルネットワーク辺りの話になると，具体的な応用がさっぱり思いつかないものの，それ以外の部分に関しては何らかの実用性の認められるものであると思う。何にせよ，概論をさらうには良い資料となるのではないかと思う。
この資料を読んでいて一つ気になったのは，探索アルゴリズムとしてお馴染みの「Ａ＊アルゴリズム」の語源についてだ。この資料によれば，Ａ＊探索アルゴリズムよりも先に「Ａ探索アルゴリズム」と呼ばれるものが存在し，その中でも特殊な条件を満たすものを「Ａ＊探索」と呼ぶとされている。
「Ａ＊」のような文字列は，検索にかけるのが難しい。「エースター」と読むので "a star algorithm" で検索すれば，なんとかヒットさせることができる。しかし， "a algorithm" を検索するのは難しい。単なる「アルゴリズム」がヒットしてしまうためだ。
Ａ＊探索はヒューリスティック探索の中でも代表的な存在であるので， "heuristic" と併せて検索すれば，なんとかそれっぽいものを見つけることができる。
http://www.ee.vt.edu/~ee4524hv/slides4.pdf
どうやらやはり，評価関数 "f(n)=g(n)+h(n)" を用いる最良優先探索 (best-first search) を一般に "A algorithm" ないしは "algorithm A" と呼ぶようだ。しかし，その "A" が何の "A" なのかは，相変わらず分からない…… "Admissible" （許容的）の "A" だろうか。 Wikipedia を参照してみても，アルゴリズムの起源に関しては触れられていない。
http://en.wikipedia.org/wiki/A-star_search_algorithm
結局のところ，Ａ＊探索の性能は，ヒューリスティック関数をどの程度正しく定義することができるかという点にかかってくる。２点間の経路探索や，８パズルの解法などは，適当なヒューリスティック関数を定義することのできる典型的な例だ。逆に，ヒューリスティック関数を曖昧にしか定義することのできないような問題に関しては，適用することが難しかったり，あるいは，適用しても適切な効果を得られないことがある。
2004-07-26
大渕氏の講義資料の中に DARPA Grand Challenge の話題が出てくる。
http://www.darpa.mil/grandchallenge/
この "Grand Challenge" は，米国防総省の研究機関 DARPA の主催によって開催されるロボットカーレースだ。ロサンゼルスからラスベガスまでの 142 マイル (227km) の道のりを，人の操作を全く介さずに自動制御のみによって踏破しなければならない。実際のコースの内容はレース開始の２時間前に初めて知らされる。そのコースを 10 時間以内に踏破することができれば 100 万ドルの賞金を獲得することができる。
レースに関連する出来事に関しては IT Media (ZDNet) の記事に詳しい。
http://www.itmedia.co.jp/news/articles/0403/13/news016.html
http://www.itmedia.co.jp/news/0307/29/ne00_robotrace.html
http://www.itmedia.co.jp/news/0310/31/ne00_robot.html
この課題は，それなりに難しい課題ではあるものの，現在の技術レベルからすれば達成可能なのではないのだろうかという印象がある。しかし実際にレースを終えてみると，各チームの成績は予想よりも悪く，最優秀成績を残したカーネギーメロン大学 Red Team の Sandstorm 号でさえ，スタート地点から 7.4 マイル地点でリタイアしてしまっている。折り返しの多い坂道を路肩走行してしまい，前輪から出火し停止せざるをえなくなったということだ。
http://www.darpa.mil/grandchallenge04/media/final_data.pdf
http://www.theregister.co.uk/2004/03/13/darpas_grand_challen...
この，カーネギーメロン大学の Red Team に関しては，専用のウェブページにおいて詳細を知ることができる。
スポンサー企業としてボーイング社やインテル社などを後ろ楯につけているのが印象的だ。インテル社の開発者向けウェブページには，この Grand Challenge プロジェクトに利用された同社の技術に関して紹介を行う記事が載せられている。
http://www.intel.com/labs/features/rs12031.htm
http://www.intel.com/labs/features/rs12032.htm
http://www.intel.com/update/contents/rs04041.htm
また，この Grand Challenge においては，各参加チームに対して出場車体に関する技術文書を提出することが義務つけられており，その文書をウェブサイトから自由にダウンロードすることができるようになっている。概要しか載せられてないものの，だいたいのスペックを知ることはできる。
http://www.darpa.mil/grandchallenge04/TeamTechPapers/RedTeam...
Sandstorm 号の動く勇姿は Red Team ウェブページのメディアギャラリーにおいて見ることができる。
http://www.redteamracing.org/gallery/videos.shtml
これらのビデオを見てみると， Sandstorm 号が非常に安定した動きを見せていることが分かる。それでも，コース全体の 142 マイルからすれば 1/20 も突破することができていないというのだから，この挑戦がいかに難しいものであるか分かるのではないかと思う。
DARPA では，来年以降も同様のレースを開催するとのことだ。ゴールまでの道のりはまだだいぶ遠いものの， Sandstorm 号の走りっぷりから想像するに，ゴールが達成されるのはそれほど遠くない未来であろうと感じられる。来年以降の展開が楽しみであると思う。
2004-07-27
先週末から Halo2 の宣伝が米国の映画館において上映されており，これがちょっとした話題となっている。
http://halo.bungie.org/oldnews.html?item=10060
映画館でゲームの宣伝を流すということだけでも十分に話題性のある出来事ではあるのだけれど，実は，それとは違ったもう１つの出来事がゲームファンの間で話題となっている。
Gamewag の記事によれば，この映像の最後に現れる xbox のロゴに添えられている www.xbox.com の URL が，一瞬だけ "www.ilovebees.com" に変化するということだ。
http://gamewag.com/archives/2004/07/bungie_and_micr.html
このことには少なくない数のゲームファンが気付いたようであり，即日に Slashdot でも話題に上げられていた。
http://games.slashdot.org/article.pl?sid=04/07/23/1912259
問題の URL "www.ilovebees.com" にアクセスしてみると，これが色々と奇妙なページであることが分かる。
ilovebees.com は，ごく普通の主婦「マーガレットおばさん」が運営するささやかなウェブサイトだ。マーガレットおばさんは，教師を辞めてから養蜂を始めており， ilovebees.com は主にその趣味を紹介するサイトとなっている。
ただし，実際に見てみれば分かるように，このサイトはハッキングされている。
このサイトには他にも幾つかのページが存在するのだけれど，現在はどのページもハッキングされてしまっている。そして，それらのハッキングされたページには，いずれも不可解なメッセージばかりが残されている。
この一連の出来事において，唯一の鍵となるのが，マーガレットおばさんの姪，ダナの存在だ。
http://ilovebees.blogspot.com/
ダナのブログへのポストによれば，マーガレットおばさんは，自身のサイトに起きた異変についてダナに相談を持ちかけている。そして，ダナ自身も徐々に異変の中へと巻き込まれようとしている。 ilovebees.com に起きた異変とは何なのか。その異変を起こした存在とは何なのか。その目的は何なのか。マーガレットおばさんとダナとはいかなる人物なのか。そして，これらのサイトと Halo2 の関係とは何なのか……この謎めいた一連の出来事が，一部のゲームファンの間で話題になっているということだ。
http://forums.unfiction.com/forums/viewforum.php?f=78
2004-07-28
件のサイト www.ilovebees.com の正体については， unfiction.com へのポスト "Letter to Halo fans and QuickStart Info for Newbies" が分かりやすい解説となっている。
http://forums.unfiction.com/forums/viewtopic.php?t=4827&sid=...
実は， Microsoft は以前にも大規模な「仮想現実ゲーム」を提供した経歴がある。スピルバーグの映画 "A.I." のプロモーションの一環として展開されたウェブゲーム ― 通称 "The Beast" がそれだ。
http://japan.internet.com/wmnews/20010502/8.html
http://yamap2001.at.infoseek.co.jp/first.html
ゲームへの入り口は，映画の予告編映像に仕込まれた他愛も無いキーワードに過ぎなかった。その手がかりを目ざとくも見つけたプレイヤー達は，各々の持つ情報や考えを共有し，協力してこのゲームを解くべく， cloudmakers.org と呼ばれるサイトを立ち上げるに至る。同ゲームの内容に関しては，この cloudmakers.org に大量の記録が残されている。
それから数ヵ月後，映画公開前の 2001 年 7 月 24 日に，このゲームは公式にエンディングを迎えることになる。ゲームマスターである「人形使い達」 (Puppetmasters) は，最後に自らの正体を明かし，数ヶ月間を共にしたプレイヤー達に向かって最大の賛辞を送った。
http://familiasalla-es.cloudmakers.org/credits/
また，このゲーム "The Beast" の脚本担当である Sean Stewart 氏は，自身のサイトにおいて，その素晴らしい体験の記憶を語っている。
http://www.seanstewart.org/beast/intro/
プロデューサ兼ディレクターである Jordan Weisman 氏は，インターネットというメディアが，かつてからの構想を実現する力を秘めていることを悟る。インターネットを介して物語の断片が大量にバラ撒かれ，プレイヤー達はそれらを繋ぎ合わせることによって謎を解いていく。それがゲームであるということは絶対明かされることがなく，現実と非現実の境界線は酷く曖昧な状態に保たれる。捏造された写真，捏造されたビデオ映像，捏造された音声，捏造された企業……それらの情報が，主にはウェブサイトを使い，ときにはメールやメッセンジャー，電話回線，ファクス，流言，プレスリリース，新聞広告，その他諸々の現実世界のメディアを用いて，現実世界の中に放たれる。プレイヤー達はインターネット上に独自のコミュニティを作り出し，協力してその謎に取り組むことになる。この点も，インターネットを利用した ARG ― 「仮想現実ゲーム」の特徴であると言える。