今春Dr.Webにて解析された、とあるトロイの木馬（Trojan.Dridex.49）では、P2P通信を使用してサーバーとの接続を確立していました。今回はこの「P2P」について、渋谷のスクランブル交差点を例に解説したいと思います。

インターネット経由で複数台のパソコンがデータのやり取りをする際、多くの場合「クライアント・サーバー方式」が使われてきました。電子メールでも、チャットアプリでも、以下のように2台のパソコン（クライアント）の間にサーバーが介入する方式です。

＜クライアント・サーバー方式の例＞
パソコンA　→[メッセージ送信]→　チャットサーバー　→[メッセージ送信]→　パソコンB
パソコンA　←[メッセージ送信]←　チャットサーバー　←[メッセージ送信]←　パソコンB

これに対し、サーバーを介入させずに直接データのやり取りを行う方式を、「ピアツーピア（P2P: peer to peer）方式」と言います。「peer」は英語で「対等の者」を表し、ここではパソコン同士、クライアント同士のことを指しています。

＜P2P（ピアツーピア）方式の例＞
パソコンA　→[メッセージ送信]→　パソコンB
パソコンA　←[メッセージ送信]←　パソコンB

このようにクライアント同士で直接やり取りをする最大の利点は、サーバーを介さない分為処理が高速化されることです。

こ れを渋谷のスクランブル交差点を例に考えてみましょう。この交差点では、歩行者用の信号が青になると一斉に数百人～数千人の人々が交差点を行き交います。 もし、彼らの一人一人がロボットだとすると、大量のロボットがぶつかり合わずにスムーズに交差点を渡るためには、周囲のロボットの歩くスピード、進行方 法、自分との距離を考慮して自分の歩くスピードと進行方向を調整する必要があります。

クライアント・サーバー方式により、これらのロボッ トがすべてサーバーに接続され、サーバーのコンピューターによって各ロボットの位置情報などを元に各ロボットに対する歩行指示を計算していたらどうなるで しょうか。サーバーと通信する分、歩行指示は遅延します。また、ロボットの数が増えれば増えるほど、サーバーの処理能力は追いつかなくなり、やがてはロ ボット同士がぶつかり合うことでしょう。さらに、サーバーで障害が起きてしまうと、すべてのロボットの動作が止まってしまうことになります（もちろん予備 のサーバーを用意することで、障害を回避させることもできます）。

これをP2P方式にすると、各ロボットは周囲のロボットの状況を自分で 認識し、自分で最適な歩行状況を計算できるようになります。サーバーとの間の通信ラグは発生せず、また、全体のロボット数が増えても計算対象になる周囲の ロボット数には限りがある（遠くのロボットの行動まで考える必要はない）ため、各ロボットの処理能力を超えることもありません。歩行ログを保存する目的な どでサーバーと通信をしていたとして、そのサーバーが障害により止まってしまっても、ロボット自身の歩行には何ら影響がありません。

P2P は2000年代から実用化され始めた比較的新しい技術のため、性能が技術的に追いついていない部分があるというデメリットはあります。また、かつて映画や 漫画などのファイルを違法に共有するソフトにP2Pの技術が使われていたこともあり、P2Pという言葉で悪いイメージを抱く人もいるでしょう。残念ながら 先述したトロイの木馬でもこの技術が使われていますが、近年はIP電話や、動画のオンデマンド配信サービスなどにも無くてはならない技術になっています。 P2P自体はうまく使えば非常に有用な技術ですので、ぜひとも正しい道でサービスの発展に貢献してもらいたいものです。