1998年、プラハ：大変革をもたらしたテクノロジーの物語

Kaspersky Labの成功の秘訣は？

私はこれまで、幾度となくこの質問を受けてきた。表現は違えど、折に触れて何度も。当然ながら、この質問に一言で答えることはできないし、一言で済むような回答など存在しない。「できる限りのことをして、すべてを成功させる方法」を、簡単な公式に当てはめることはできないのだ。まあ、宝くじで多額の当選金を手に入れるだとか、突然高額の遺産が転がり込むなどという場合は話が別かもしれないが、私の場合はそうではなかった。当社の成功の要因は多々あるが、主に技術的なものだ。今日はそのうちの1つ、とある基礎的なテクノロジーについてお話ししようと思う。長年にわたりあらゆるカテゴリで画期的な製品開発の礎となり、マルウェアによる想定し得る限りのサイバー脅威に対して最大限の防御策を提供してきたテクノロジーだ。

そのテクノロジーは「Prague」（プラハ）と呼ばれている。

なぜそんな名前なのか？深い意味はない。プラハで考案されたからだ。

1998年の春、我々は、ビールを飲んでチェコの美味を堪能するために今後の製品のアーキテクチャをどうするか考えるため、少人数でプラハに集結した。この会合は大成功だった。我々は新しいテクノロジーを生み出した…Unified Component Architecture（UCA）、あらゆるプラットフォーム（OS）上で動作する多種多様な製品を結び付けるテクノロジーだ。UCAは進化を続け、当社のほぼ全製品の屋台骨となっている。

それだけではない。UCAは、「多言語」のプロジェクトおよび開発の問題を抱える他社からも注目されている。この種の問題は、多数のチームが関わる複雑なプロジェクトや、企業の合併時に発生しやすい。

プラハでの会合から、今年で20年になる。過去の資料に目を通していて「Prague Technology Documentation」という文書を偶然目にしたとき、そのことに気が付いた。文書の日付は、1998年の6月22日だった。当時の我々は「革新的な」ウイルスとの戦いに没頭していて、アンチウイルスエンジンに関するいくつかの問題（100%技術的なもの）の解決にあたっていた。我々が見いだした解決策は汎用性が高く、強力で、有益だった。Pragueはさまざまな面で、その後10年以上にわたって当社製品の中核となるテクノロジーを決定づけた。

はじまりのストーリー

当社の規模が、ガレージレベル（我々の場合はモスクワ市ストロギノ地区の幼稚園2階）とガラス張りオフィスレベルのどこか中間あたりだった頃のことだ。我々は自社エンジンを多数の外国のパートナーにライセンス提供しており、Antiviral Toolkit Pro 3.0（AVP 3.0）を市場に展開してすでに大きな成功を収めていた。しかし、技術面で将来の不安がまったくないわけではなかった。

大きな課題が、疑いなく必要かつ実装には多大な困難が伴うこと必至の課題が、2つ残されていた。第1の課題は、不審なオブジェクトを、どんな形態で格納されていても処理するという能力だった（分かりやすい例は埋め込みオブジェクトの「入れ子」だ。マルウェアの実行ファイルがアーカイブ内にあり、さらに別のアーカイブで圧縮されている状態だ）。第2の課題は、できる限り短時間でアップデートでき、別プラットフォームへ移植する際の変更が最小限度（理想としてはゼロ）で済むアンチウイルスエンジンを作成することだった。

お忘れの方もあると思うので補足すると、90年代終わりのウイルス作成者というのは実に独創性があった。そのため、まったく新しいウイルスが登場すると、アンチウイルスデータベースだけではなくアンチウイルスエンジン自体をアップデートしなければならないことがあった。一般の人々はきわめて遅いインターネット接続を使うか、まったく使わないかのどちらかであったから、数メガバイトのアップデートを配信するというのは大問題だった。また、Windows 98が普及し始めていたがDOSもまだ使われていたため、検知機能に更新があった際はWindows 98とDOSの両方へ、すぐに対応する必要があった。

アレクセイ・デ・モンデリック（Alexey De-Monderik）、アンドレイ・クルイコフ（Andrey Kryukov）、アンドレイ・ニキーシン（Andrey Nikishin）、ヴァジム・バグダーノフ（Vadim Bogdanov）、ラリーサ・グルーズジェヴァ（Larisa Gruzdeva）、そして私がブレインストーミングのためにプラハに1週間滞在したとき、考えるべきことは山積みだった。我々はホテルの会議室を借り、毎日9時から5時まで図式を書いたり議論を交わしたりし、その後はレストランやビリヤード室に移動して、チェコのビールを味わいながらアイデアをじっくり寝かせた。

我々は意欲的に取り組み、モスクワに構想を持ち帰った。デ・モンデリックが我々のアイデアを文書にまとめ、それに触発されて私が今この記事を書いている。その文書がこれだ。

クルイコフとニキーシンはPragueに関する検討を続けたが、Pragueが実際に作成されたのは1999年、アンドレイ・ドゥフヴァーロフ（Andrey Doukhvalov）がチームに加わったときだ。システム開発経験を持つドゥフヴァーロフのおかげで、Pragueのコンセプトは、アンチウイルスエンジン向けの単なるプラグインシステム以上のものになった。

実際にPragueは、独立して作成された、オブジェクト指向のモジュール型システムとなった。このシステムでは、アプリケーションを発売した後であっても、オブジェクト階層が観察された後でも、メモリ管理やプログラム間の通信といった機能がカーネルによって有効になった後でも、オブジェクトの作成と管理ができる。オブジェクトはすべて、ごく薄いレイヤーを通じてOSおよびユーザーインターフェイスと通信するため、アンチウイルスのカーネルのほぼ全体を「Pragueプラグイン」の形態で記述することが可能だ。

ドゥフヴァーロフが最初のバージョンを開発し、Antiviral Toolkit Pro （AVP 4.0）の製品で使用できるところまで持っていった。Pragueを完全に具現したものとはまだ言えなかったが、このアーキテクチャの強みはすでに明らかだった。

• 複雑な入れ子のオブジェクトを処理するという課題が完全に解決された。Pragueに基づいたアンチウイルスは、たとえばアーカイブ内の感染ファイルの治癒、もしくはマルチボリュームのアーカイブで複数ファイルに分割されて格納されたウイルスの検知を容易に実行可能であり、このようなものが市場に展開されたのは初めてだった。また、検知モジュールと処理モジュールは、感染したオブジェクトの元の場所（どのアーカイブか、どのファイルシステムかなど）にかかわらず機能した。
• このアンチウイルスエンジンのロジックは、データベースによって簡単にアップデートできた。また、新しいロジックを有効にするのに再起動は不要だった。
• モジュールのサイズはとても小さく、さまざまなプラットフォームに簡単に適応できた。その結果、たとえばKaspersky Anti-Virus バージョン6はMacにも簡単に移植できた。
• 全体的に動作が非常に速く、メモリの消費量も最低限で済んだ。当時、Pragueが消費するリソース量は、既存のどのオブジェクトフレームワークよりも少なかった。

Pragueを採用したおかげで、我々はIT業界の最先端となった。ソフトウェア開発におけるモジュラーアプローチは、当時は今ほど進んでいなかったのだ。その後、我々はPragueで4つの米国特許（7386885、7730535、7418710、8234656）を取得した（リンク先はいずれも英語記事）。

Pragueはまた、動作原理の異なるコードとの統合も容易だった。そのためまずはバージョン4.0に組み込まれたのだが、当時は狭い範囲の問題を解決することだけが目的だった。後に、バージョン5.0の開発中に大きな問題が見つかったとき、Pragueがそれらに対応する能力を十分に備えていることが判明し、ドゥフヴァーロフはPragueをベースとしたまったく新しいバージョンを作成しようと思いついた。これが革新的な製品「Kaspersky Anti-Virusバージョン6」誕生へとつながるのだが、これについては以前、詳しく触れている。

「アンチウイルスプラグイン」を、製品全体を構築するためのフレームワークへと拡張するには、いくつかのアプローチを一般化して考え直す必要があった。ここで牽引力となったのは、アンドレイ・ドゥフヴァーロフとパーヴェル・メジューエフ（Pavel Mezhuev）だった。この2人がいなければ、これほど複雑なタスクにPragueを適合させていくことはできなかっただろう。

当然ながら、開発の世界で完ぺきなものは一つとしてなく、Pragueも2つの大きな問題を抱えていた。

第1に、デバッグが難しかった。第2に、開発者を適応させるのが難しかった。Pragueはどこからどう見ても新たに開発されたオブジェクトシステムであり、コード設計には厳格な要件が課された。さらに、その頃のモジュールはCのみで記述しなければならなかった。短時間で人々をトレーニングするのは困難だったが、会社が成長し、製品が複雑化していく中、ますます多くの開発者が必要になった。

IT業界の例に漏れず、開発スピードが重要視されるようになり、当社ももっと一般的で標準的なオブジェクトフレームワークへと次第に移行せざるを得なかった。ただし、Pragueをベースとした断片は、現在でも当社製品の中に健在だ。

当時の問題は言うまでもなく、純粋にプロセスとリソースを原因とするものだった。それらは必ず解決できるはずだったし、解決しなければならなかった。というのもPragueの実装はメリットのほうがかなり大きく、リソースを注ぎ込むのは理にかなっていたからだ。Pragueは最も困難な、そして最もコストの掛かる問題のうちの1つを解決した。さまざまなプラットフォームへのテクノロジーの移植性（バイナリの移植性も含む）という問題だ。これが解決されたことは、過去10年の活動にとりわけ大きな影響を与えた。

各種OS向け、各種プロセッサー向けに新製品をゼロから作り出す代わりに、我々はデバッグ済みの既存フレームワークを活用した。この長期にわたる研究開発への投資は、大いに成功を収めただけではなく、現在に至るまで当社が技術的リーダーシップを維持する原動力でもある。Pragueの後継であるUnified Component Architectureは大いに活用されているし、UCAで解決できない問題はいまだに見ない。優れたアーキテクチャは何十年もの試練に耐えることができる、とPragueは証明している。

アレクセイ・デ・モンデリックがよく言うように、Pragueは当社で非常に重要な役割を果たしてきたし、それは技術的な意味合いにとどまらない。Pragueの周りには情熱を持った人々が自然と集まり、後に「Six」という有名なチームを形成するに至った。このチームに乾杯しよう！

そして、当社にとって大きな力であり、すべてを変えたテクノロジーの、ささやかな記念日（偶然気付いたが）にも！