相次ぐ情報漏えいと攻撃準備の高速化
はい、こんにちは。バグキャストです。この番組は音楽家の鈴木とプログラマーの伊藤が、社会や文化について気になったことを調べたり、
面白がったりしながら話すポッドキャストです。今回は第38回です。
いやいや、伊藤さん。
何ですか、大河さん。
伊藤さん、忘れそうになりましたけどね。止まったね。
そういうこともある。
はい、今回は第38回なんですけども、時事問題を取り上げたいと思います。最近、企業の大規模な情報漏えいが相次いでるじゃないですか。
そこに、Webサイトを動かすPHPというソフトウェアに重大な脆弱性が見つかり、運営者が緊急対応を迫られる、みたいな話題もあった。
大きなニュースになってましたね。
そうですね。
それぞれの経緯を整理した上で、攻撃の速さが変わることは、ネット上で自分たちの場所を持つ自由や、
それを支える仕事にどんな影響を与えるのかを考える、みたいな。
真面目になりそうな雰囲気が出てますけどね。
社会問題ですからね。
まあ、そうですね。今回のテーマは「ネットの安全は大企業に任せるしかないのか」みたいな。
セキュリティ問題について考えるという回になっていきたいと思います。
まず、昨今のセキュリティインシデントについて整理してみたいんですけども、相次ぐ情報漏えいの概要ですね。
2026年9月から10月にかけて、国内の企業などで不正アクセスによる個人情報の漏えいが相次いで公表されていますね。
一部を紹介します。
第一は、タイムズカーの事例ですね。ここでは約660万アカウントの情報が第三者に取得され、氏名や住所、
連絡先などが漏えいしたとのことですね。そのうち約160万アカウントでは、運転免許証などの本人確認書類の画像も漏えいしていると。
対象には既に退会した会員も含まれているみたいですね。
第二は、焼肉きんぐの公式アプリの事例ですね。会員管理システムが不正アクセスを受け、約1,079万件の会員情報が漏えいしたと。
登録情報のほぼ全件にあたり、登録名、メールアドレス、電話番号などが発表されているということですね。
被害を受け、両社は侵入を防ぐ対策に加え、保有する個人情報を減らす見直しも発表しています。
タイムズカーは、会員期間中と退会後7年間保有していた本人確認書類の画像を、会員登録完了後は保有しないルールに変更したと。
既存の画像も10月末までに削除する予定とのことですね。
焼肉きんぐの運営会社は、グループの公式アプリで氏名と電話番号を保持しない仕組みへの変更を2027年上半期に予定しているとのことで
すね。情報を守る体制と、そもそもどこまで情報を持つ必要があるのかという設計の両方が、見直しの対象になっているということですね。
この情報漏えいが相次ぐ背景っていうのを、ちょっと見ていきたいんですけども。
まず第一は、攻撃に必要な時間や手間が減っているっていうのがあるみたいです。
スマホアプリを解析して接続先のサーバーを調べたり、その弱点を探したりする作業に、解析ツールやAIが使われているとのことですね。
不正アクセスへの対応や調査を行う専門機関のJPCERT/CCも、一部の攻撃でAIの利用を確認しているみたいです。
攻撃の準備にかかる負担が下がり、より多くのサービスを調べて狙えるようになることが懸念されていると。
第二は、サービス側に以前からの弱点が残っていること。
JPCERT/CCによると、既知の脆弱性や管理の不備を狙う攻撃、
アプリとサーバーが通信する窓口への不正な操作などを報告しています。
利用者に許された操作や見せてよい情報の範囲を、サーバー側で適切に制限することが求められている。
JPCERT/CCの注意喚起っていうのがあるので、これ、概要欄に載せておいたらいいかなと思います。
こうした点検や更新を続けるには、人員、予算、責任を持って判断できる体制が必要になってくる。
IPAの中小企業調査でも、組織的な対策や投資が十分に進んでいない実態が示されていました。
攻撃の準備が効率化する一方、弱点を把握して直し続ける体制をどう確保するのかが課題になっているということですね。
PHP脆弱性「PHP2Shell」と緊急対応
これらの一連の情報漏えいとは別に、この次にはPHPの脆弱性をめぐる緊急対応も起きた。
今、これを録っているのが10月23日なんですけども、つい数日前のことですけどね。ここで明らかになった。
21日に大きな話題になったかな。
そうでしたね。
PHPは、Webサイトの表示やデータ処理に使われるプログラミング言語のことですね。
今回、PHPを実行するソフトウェアに、ログインしていない攻撃者が条件によってはサーバー上で不正なプログラムを実行できる重大な欠陥
が見つかったと。こうした安全上の弱点を脆弱性と呼ぶんですけれども、
悪用されれば情報漏えいやサイトの改ざんなどにつながるということです。
これ、ちょっと詳しく経緯を説明したいんですけど、その脆弱性については、8月に開発側へ危険性が報告されていたみたいです。
なぜ10月に入って緊急対応が必要になったのかっていう経緯を、四つの段階に分けてちょっとお話しさせてもらうとですね。
第一は、開発側への非公開の報告があったと。8月11日、研究者が実際に攻撃できることを開発側へ報告し、修正が最優先になった。
一般の運営者が問題の詳細や修正版を入手できる段階では、この段階ではないと。
第二は、修正と配布の準備が行われた。既存のソフトが動かなくなる恐れや、限られた専門人材での判断が修正を難しくしていたと。
開発側と配布元は、攻撃方法だけが先に広まることを避け、問題の公表と修正版の提供をそろえる調整を進めていたということですね。
第三は、公表直前に予定外の公開が重なったことですね。脆弱性の識別番号などが出回り、開発側は公開を1日前倒ししたと。
当初、攻撃の技術的な詳細は漏れていませんでしたが、その後、研究会社のCalifが攻撃の実証映像を先行公開し、
配布元のChainguardも修正済みソフトを正式公開の6時間以上前に提供することになった。
修正箇所も欠陥を探る手がかりになると。多くの運営者が修正版を待つ間に、攻撃側が解析に使える情報が増えたということなんですね。
第四は、一般運営者による緊急対応。修正版の正式公開は日本時間の10月21日午後11時でした。
AWSは公開後数時間で新たな攻撃用プログラムが現れ、ほぼ即座に攻撃観測用のシステムで使われたってことを報告しています。
運営者は公開前から準備を進め、修正版の提供後に更新して、正常に動くかを確認する必要がありますよね。
なので、安全を確保できなければ、一時的なアクセス制限やサービスの停止が必要になったっていうことですね。
このアクセス制限やサービス停止の段階に至って、ユーザーが結構広くこの件について知ることになったんじゃないかと思うんですけども。
8月の段階で開発側は非公開で修正を進めていたと。
10月の公開前後には、広範囲の運営者が自分のシステムを守る対応を迫られたっていう違いがあるんですけども、
公開前の脆弱性情報の流出や修正版の先行公開が、その準備をさらに難しくしてしまったってことがあるみたいですね。
ちなみに、AWSはそれ以前の10月17日にも攻撃の試みを観測しているみたいですね。
その情報の入手経路は不明となっているということなんですけども。どうでしょうかね。
ここで僕はちょっと、今回はPHPの脆弱性をめぐる緊急対応の件についてまとめてみたんです。何か補足したいこととかあったりします？
そうだね。この件でなるほどなって、たぶん聞いてる人が思うのは、問題があったので修正します、
修正箇所を公開したので皆さん修正してください、って言うと、「ここ修正しないと危ないんだ」って気づいた悪いやつが、
「じゃあ修正する前のそこを攻撃しちゃおう」っていう、すごく大きなヒントになるってことだね。
そうだね。
それ自体はセキュリティ関連のコミュニティでは常識なので、何かセキュリティの問題を発表するときにはお互いに調整して、
このタイミングでみんなで一斉に守ろうね、悪いやつらにばれてそれが使われる前にうまいこと修正しよう、っていうことがあったんだけど。
特に今回はそれが早めに出ちゃった。あと、修正箇所が分かれば攻撃箇所が分かるっていう解析が、
AIによってかなり迅速に行われるっていう状況が重なって、今回の大混乱っていうのが一つのトピックかなと思いますね。
ここまでの事例から考えたいのは、システムの安全性をめぐる環境の変化ですね。
情報漏えいの被害と、被害を防ぐための停止はそれぞれ異なるんだけども、
どちらも安全を保つ仕事が私たちの生活や仕事に直結しているってことを示してますよね。
特に重要なのは、脆弱性の手がかりを得てから、攻撃方法を作るまでの速さなんだと思うんです。
AWSは、AIによる解析で修正内容などから攻撃方法を作る負担が下がり、より多くの攻撃者が数時間、
場合によっては数分で動けるようになっていると分析しています。これ、AWSの分析っていうのがあるので、概要欄に載せておきますね。
運営側にも自動化や効率化の余地はあるんですけど、影響の確認とか、正常動作の検証、停止の判断を省けるわけじゃないので、
攻撃までの時間が短くなる中で、その仕事を誰がどのような体制で担うのかが問われるということですね。
すげえ分かりやすく言うと、攻撃が来る可能性があるってなった段階で、サービス止めないといけないじゃん。
そうだね。
でもサービス止めるためには、エンジニアが一人で判断できないじゃないですか。
つまり、そのサービスを止めてる間に生じるだろう経済的な損失を考えないといけないから、上に報告するんだよね。
そうだね。
上が会議とかするわけだよね。でも、その間に攻撃が来るわけじゃん。
そういうことなんですね。
っていう、この問題をどう捉えたらいいのかってことなんだと思うんですけど。
っていうことですね。
自前運営を難しくするセキュリティ負担
そこから二つの論点を今日、バグキャスト的に考えてみたい。まず第一は、自分でサービスを作り運営する自由への影響。
第二は、その安全を支えるエンジニアの仕事をどう理解して評価するか、みたいな。これはちょっと今日、考えてみたいんですよね。
まず第一の論点。ネットの分散性と自立性は、今後どうなっていくのか。
これを僕は、このバグキャストでずっと言ってることでもあるんですけど、今日、改めて話してみたいんですよ、この機会に。
インターネットが一般に広がり始めた頃について、ちょっと思いをはせたい。
おお。
まず、ちょうど我々、インターネットが一般に広がっていくさまを見てましたよね。
この頃って、分散性とか自立性への期待がすごくあったと思うんですよ。
しかし現実には、巨大プラットフォームへの集中が現在進んでるじゃないですか。
安全を維持する負担の増大が、その集中をさらに強めるんではないかっていうのが、僕の論点です。
なるほど。
その意味を考えるために、当時どのような期待があったのかっていうのを、ちょっと振り返ってみたいんですけど。
インターネットは、別々の組織が運営するネットワークを相互につなぐ通信の基盤ですよね。
Webはその上で文章や画像をページとして公開し、リンクで行き来する仕組みですよね。
1990年代には、Webの普及とともに、個人や小さな組織も自分で情報を発信し、
人とつながる機会が広がっていったっていう流れがありましてね。
当時の期待を三つの側面から見ていきたい。第一は、共通の技術でさまざまな人が仕組みを作れるっていう開放性です。
Webでは、ページの記述方法や情報を送受信する約束事が公開されてきた。
その約束に従えば、別々の人が作ったブラウザーとサーバーでも情報のやり取りができると。
一社の製品に統一しなくても参加できる仕組みのことですよね。
これ、要するに、1993年には開発元の研究機関CERNが、Webの基本ソフトウェアを誰でも利用、改変、
配布できるように公開してますね。こういった開放性っていうのが、当時すごく新しいものとして受け取られてた。
これに期待がかなりあったはずですよね。
第二は、それぞれが独立した場所を持ってつながれるっていう分散性。
インターネット全体を一つの会社が運営し、所有しているわけではない。
自分でサーバーを動かし、サイトを公開して、別の人のサイトへリンクを貼れる。
それぞれが自分の場所を管理しながら、共通の仕組みでつながっていくって構造を持てる。
第三は、情報を受け取る人が発信する側や仕組みを作る側にも回れるっていう自立性。
例えば音楽家なら、自分のサイトに作品や活動について書き、聞き手との関係を築いていける。
技術を身につければ、そのためのプログラムやサーバーも用意できると。
発信する内容だけでなく、場所や仕組みまで自分たちの判断で作り、運営できるっていう期待ですよね。
そこには技術への期待と、社会を変えるっていう思想が重なってたんだと思うんです。
知識を交流すること、既存の組織や国境を超えて交流すること、自分たちの場を自分たちで運営するっていうことですよね。
ここで言うその思想って、その強い現れの一つが、ジョン・ペリー・バーロウが1996年に発表した「サイバースペース独立宣言」ですね。
国家による支配から独立し、ネット上の人々が自ら関係や秩序を作るっていう主張がここで示されてるんですよ。
この「サイバースペース独立宣言」って僕、すごく重要な思想だと思うので、これも概要欄に貼っておきますけど。
当時も機器や回線には費用がかかり、自分で運営するには当然技術が必要だったと。
それでも、学び、作り、つなげるっていうことを自分でできた。その可能性に、分散性とか自立性への夢があったんだと思うんですよ。
だからこう、思想にもなったってことだよね、同時に。
しかし現在では、配信や交流の場、情報の管理は巨大なプラットフォームに集まっていると。
サービスを動かすクラウド基盤も、大手に集中してきている。
多くの人が発信できるようになった一方、その活動は大きな事業者の仕組みや規約に依存してきている。
Webの開発者であるティム・バーナーズ＝リーも、プラットフォームへの依存や利用者の自立性について論じてはりますね。
中央集権化について議論されてるんですけども、サービスの運営や情報の管理、利用条件をも決める力が、
少数の事業者に集まっちゃってるよねってことですね。
インターネットをつなぐ技術に分散性があっても、その上での活動を大きな事業者に依存することっていうのが起きちゃってる。
安全を維持する負担が、この集中をさらに強めていくんじゃないのかっていうことですね。
バグキャストの会員サービスと個人情報
僕が考えてみたいのは、例えばバグキャストのメンバーシップも、会員管理のプログラムを自分たちで開発し、
サーバーの構築と運用も自分たちで行うことを考えるじゃないですか。
登録やコンテンツ提供を実装できても、会員の情報を預かる以上、更新や監視、不正アクセスへの対応を続ける必要が出てくる。
攻撃への対応時間が短くなるってことは、その責任を少人数で引き受け続けることはどこまで現実的なのか。「無理じゃね？」みたいな。
正直、思いますね。
その負担が大きくなれば、自前での運営は諦め、専門の体制を持つ大きな事業者のサービスを利用する判断へ向かいやすくなりますよね。
個々には合理的な選択でも、それが積み重なれば全体では集中が進む可能性がある。
これは既に進んでいる中央集権化に、セキュリティの負担がさらに圧力を加えるのではないかっていう、これ、僕の仮説ですね。
自前の運営が禁止されなくても、安全を維持する費用や責任が大きくなれば、独立して活動することは難しくなってくる。
技術的には作れても、運営を続ける体制を持てなければ、その自由を実際には選べなくなるんじゃないか。
初期に期待された、自分で作り、自分で運営し、人とつながるっていう自由を、今も現実的に選べるものとして保つには何が必要なのか、
みたいなテーマ設定ですね。これ、まずどうですか、伊藤君。どう思います？
うーんと、その、セキュリティのコストが増えると、小さな事業者とか小さな団体では賄いきれなくなっていくっていうのは、
確かにそうだなと思います。僕がプログラマー、エンジニアとして活動していく中で、やっぱり強く思うのは、さっきも話に出てた、
経営者はエンジニアではないので、セキュリティとか保守みたいなものをエンジニアがやるんだけど、エンジニアの権限がありませんので、
何かあったときには一度お伺いを立てなければいけないっていう構造がかなりある。
本当は現場に裁量権が与えられてて、いざとなったら止めていいよとか言われてればいいけど、割と古い会社とか古い業態だと、
そういうエンジニア部門というのがないがしろにされてるというか、軽視されてる節っていうのはあって。
そこに予算とか権限が投入されてないから、じゃあ大手の、誰もが安心できるとされてるところに頼んじゃえばいいじゃんっていうふうに、
圧力がかかっていくっていうのは、とてもあり得る話だなと。
そう思いましたね。
例えば、バグキャストのメンバーシップをやります。メンバーの人はカード情報とかから登録してます。
個人情報をつまり握っちゃってるわけだよね。こういったプログラミング言語の脆弱性が見つかりました。
伊藤がどうにかしなきゃいけなくなるわけじゃないですか。
そのときに、伊藤一人の判断じゃどうしようもないから、俺に聞かなきゃいけなくなる。でも俺は寝てたりするよね。
そうだね。
［聞き取り不明］だからね。連絡がつかなかったり、俺が電話して「セキュリティが」って言ってもね、「どういうこと？」ってなっちゃう。
わけ分かんない。そういうことが起きるわけでね。
その間に攻撃されて、個人情報が流出してしまいました、っていう問題が起きることを考えると、
だったらもう自分たちで管理するのをやめて、大きいところに頼めばいいじゃないかってことだよね。
それはそうなってくんだと思うんだよね、俺は正直。
でもそのときに、「いやいや、インターネットって初期の思想はそうじゃなかったよね。
そこにこそ本当に魅力があったのに」っていうのは、やっぱり言いたい。
例えばさ、これもう完全な素人の、夢みたいなことを言うけど、AIによって、つまり攻撃側がめっちゃ強くなってるわけじゃん。
でもこれ、守備側が強くなるってことはできないのか、みたいな。
守備側ももちろん、AIを使って強くしていくってことは行われてる。
例えば今回でも、脆弱性を守備側も見つけていて、それを何とかしようという動きももちろんあったっていうことですよね。
そうそう。つまりさ、攻撃側の方が意思決定が早いって問題なんだと思うんだよね、これ。
守備側は、エンジニアはいろんな人に聞かなきゃいけないから。
同じ技術を使ってるんだけど、意思決定にかかるコストが守備側の方が大きくなる。
つまり、守るものが大きいからっていうことなんだと思うんだよね。
それはあるね。たぶんこれ、いろんな場所で言えるんだろうけど、やっぱり攻撃する方が守るよりも有利なんですよね。
いつでも自分のタイミングでできるし、かつ、攻撃側って違法じゃないですか。防御側は合法側じゃないですか。
なので、これ結構言われるけど、攻撃されたらやり返しちゃうのが一番強いわけよ。
攻撃された経路をたどって、向こうのサーバーをぶっ壊すとかね。でも、そんなことはできない。サイバー攻撃になっちゃうから。
防御側は無限に防御力を上げ続けなきゃいけないってコストを背負ってて。
なるほどね。
攻撃側はたまたま見つかった弱点を突けばいいっていう。かなり有利不利はあるかなとは思いますね。
うん、なるほどね。
今の話はかなり防衛の話になってきちゃってるよね。つまり、軍事的な話なの。
たぶん軍事的な話。
敵基地攻撃能力みたいな話になっちゃってるじゃん。それの違法性みたいなことについて考えるってことでしょ。
伊藤のさ、直感でいいんだけど、もうこれは無理と考えた方がいい？
つまり、メンバーシップ独自運営路線、もう基本的にはやめた方がいい？
えっと、仮にネット上でのセキュリティリスクっていうのを高めに見積もって、もう見られてもしょうがないっていうことであれば、
難しいよね。難しいんだけど、例えば今回みたいに緊急性がある脆弱性が見つかった、攻撃されるかもしれない、
みたいな短い期間の話で言うと、一番最初にもあったけど、個人情報をどうやって保持するかって話があって。
つまり、個人情報をサーバー上に置いといて、いつでも我々は見れます、もちろんユーザーは見れないよ、っていう形にしたときに、
そこを突破されると困るんだけど、個人情報を別のところ、ネットと切り離された空間に置いとくっていうのは全然できる。
それも分散するということですね。
極端な話、印刷して取っておくとかね。デジタルデータとしては残さないとかやれば、絶対にハッキングでは見つからないから。
でもさ、それどういうこと？ その月額を徴収するときには、俺が何、銀行とかに行って？
そう、口座振替とかやったりとか。向こう側に何かやるときは、我々がいちいちメールアドレスを手打ちして、それで連絡するっていう。
極端な話ね。これはまあ、究極のセキュリティです。デジタルからの脱却。
確かにね。
まあ、それも銀行のセキュリティがどうのこうのって話になるかもしれないけど。
でも、どこまで持つかっていう話は同時に扱われるだろうね。
現実的な世界で言うと、完全な自立は難しくて。例えばメンバーシップでクレジットカード情報を登録してもらう。
普通のWebサイトだったら、クレジットカード情報をサイトに保存するってことは絶対しないわけです。
それは、クレジットカードの決済会社のサービスが間に入ってて、そこが全部やってくれるっていうことになってるから、
クレジットカード情報が流出しちゃうみたいなことは自分の責任では起こらないっていうのが前提で。
大事な部分もやっぱり、巨大なプラットフォームとか大きな企業に任せてっていう。
この一部を外していって、どれぐらい自分の好き勝手できる場所を確保するかって話になるのかな。
でも他方でさ、そう考えるとPHPに見つかった脆弱性って、結構やばいよね。
そうですね。今回、本当にやばかったのは、プログラマーがサイトとかを作るときに一生懸命やってたセキュリティとかとは全く別の次元で、
PHPを使ってる人たちは好き放題されちゃう可能性がある、どんなに頑張ってても、っていう穴が見つかっちゃったので。
今回で怖いのは、個人情報を抜かれちゃうってこともそうなんだけど、
Webサイトの一部に勝手なコードを入れられちゃうってことがあって。
それに気づかないと、ずっとWebサイトで行われてきたあらゆる情報を取られちゃう可能性があって。
そうすると、「クレジットカード情報、うち持ってませんよ」って言っても、お客さんが入力したその画面を、
攻撃者が盗み見ちゃうみたいなことが十分あり得るので、そこもかなり難しい。
Webサイトから情報を抜かれるだけじゃなくて、Webサイトを改ざんされちゃうっていう問題点がかなり指摘されて、
大きな話題になったっていうことですね。今回は本当に大きい穴だったってことですね。
これじゃやっぱり、基本的に個人はやめた方がいい？ これ、何度もここに戻ってきてるけど。
ネットの居場所と自律的な文化
実際にはたぶん、この問題で考えなきゃいけないのは、人がインターネットに何を求めてきたのかって話と、
今何が求められてるのかっていう話。それについてみんながどう思ってる、っていう話だと思う。
そうだね。だから俺は、人はそもそもインターネットにこれを求めてたじゃんってことが忘れられてる、
っていう問題設定を立てたいってことだよね。
そうだね。
これがどう？ これについてどう思う？
人が何を求めて。
だから伊藤はそれに対して常に、「まあ、それは別にできることはできるよ」って返してるじゃん。
そうだね。
でもそれは分かってるんだけど、っていうことだよ。でも、そうじゃなくなってきているっていうことについてですよね。
まあそれは別に、例えば立場によっては、それ、インターネットの良さじゃないんだよってことも言えるよね。
そもそも軍事技術として開発されたものを読み替えて、分散的なものにしてる、自立的なものにしてるにすぎないわけだから。
これはそもそもそういうものじゃないんだから、違う方向に向かって、中央集権化に向かって収斂していくしかない、
っていうような考え方もあるんだと思うんでね。
そうだね。
つまり、僕、ほら、夢みたいなこと言ってるじゃん。
そもそもインターネットってこういうところに魅力があったから、ずっと僕はそれに興味を持ってきた。
でも、にもかかわらず、現実問題としては中央集権化に向かっていってる。
それを便利なものだからしょうがないよねってみんなは思ってるけど、でもみんなは間違ってるって言いたいわけだよね、俺は。
だからこれは個人的には、昔の居心地のよかったインターネットが失われてるような気は確かにしていて。
これを考えるときに今思いつくものとしては、ちょっと前に話してたジェントリフィケーションの話題と絡められる気はする。
便利になり、安全になる過程で、居心地のよかった場所やそこにいた人たちが、居場所がなくなっていってるんじゃないかっていうのは、
これ、問題の視点としてあるってことだよね。
それに気づかないまま行くっていうことはどうなの、って話があって。
これはやっぱり、デジタルっていうことのスピード感っていうのはかなり影響してると思うな。
街が変わっていくっていう話と、インターネット空間が変わっていくって話だと、スピード感が結構違うと思ってて。
より速いスピード感だと、そういう問題点が置いてきぼりになりがちだっていうことなのかな、と思うね。
そうね。だから僕、実はさ、いろんなことを、話題を変えてるんだけど、ずっと言ってることはかなりシンプルで、一緒なんだよね、実はね。
本当にそうで、ジェントリフィケーションの話とこれ、重なってるんだよね。
だから実は、居場所論みたいなことで、バグキャストのかなりの回は統一できるんだよね。
これもさ、インターネットの空間の中に、ちゃんと自分たちがいられる場所を作りたいと思ってるんだよね、僕は。
もう話が結構抽象的になってきてるじゃん。だからちょっと落とすけどさ。
オタク文化とすごい密接な接点を持ってる、この自立性とか分散性については、インターネットはね。
だから、独自の即売会みたいなものを作るって話と似てるんだと思うんですよ。
つまり、自治体とか国とかに依存せずに、勝手にコミュニティを作って、そこで即売会やるみたいな。
お金のやり取りも発生して、作品のやり取りをするみたいな。これこそが本当に重要な文化を生み出すってことね。
国がやる文化政策みたいなものの外に自立して、わけ分からない絵とかを描いて、
あと本当に意味の分からない叫びとかを書いた詩とかを売って、交換してる。100人いたら99人が気持ち悪いって言うようなものも。
でもこれが本当に、僕は文化の根源的な力だと思ってるわけ。だからこそ、自立性とか開放性ってすごく重要だと思ってる。
そういう場所だったよね。
そうそうそう。
日本のオタクも、インターネットのこういった面にすごく魅力を感じてた。
けど今起きてるのは、そうじゃない方向に向かっていっているわけじゃん。
ネット上で交換をするんだとしたら、大きなプラットフォームに依存するって、ここに行くしかなくなっちゃってる。
大きなプラットフォームに依存すると、公序良俗に反するような表現を売ったりすることができなくなっていくってことは、
普通に起き得るわけじゃないですか、現実にね。
そう。
っていうことを僕は問題にしたいんですよ。それでどうなのってことはね。
もっともっと話のレベルを落とすとさ、つまりさ、僕とか伊藤はさ、野良犬みたいなやつなわけじゃん。つまり先生にも嫌われてきました。
親にも見放されてきました。
公序良俗に反する。
そうそう。大人となんか話は合わなかった。分かってほしいとも思ってない。「俺らになんで関わってくるんだよ。俺ら勝手にやってんだよ。
わけの分かんない番組を作って叫んでるんだよ、俺ら。いちいち俺らに干渉してくんな」って思ってるわけだよ。
この精神とインターネットの初期の思想って、ものすごい相性がいいんですよ。
俺はこれが本当に文化を作ると思ってるわけ。新しいクリエイターたちは、こういう精神だったはずだと思ってるのね、常に。
誰からも守られてないやつらが、叫び散らかして、情熱だけで何かを作る。それが作品として、文化を形作ってくっていうものね。
で、これをさ、忘れないでほしい、と言って。
メッセージ。
いや、もうこれ、ちょっと議論の方向性、結論ちょっと出ないじゃん。ちょっとあまりにも。
結論は難しいけど、まあ、その問題の視点としてある。
そうそうそう。だからこれをちょっとね、僕、今回の件を受けて、これが言いたかったんですよ。
インターネットで、そもそも自立とか分散性ってものに対する志向性があって、それはすごく魅力的なものだったし、
文化を本当の意味で支える技術とか基盤になるはずだったんじゃないの、っていうこの問題提起ね。
それは大きなプラットフォーム、大規模な事業者に依存していく過程で、絶対に失われていくことだよっていうことは言っておきたい、
ってことでございます。
なるほど。
保守・障害対応を担うエンジニア
これが第一の論点で、第二の論点。エンジニアっていう言葉が、仕事の実態を伝えなくなってるんじゃないかって気がします。
つまり、エンジニアっていうと、ものを作る、ソフトウェアの分野ならアプリ、新しい機能を開発する人ってイメージがあるじゃないですか。
開発者。
そう。しかし、特に運用やセキュリティを担う現場では、医療や災害対応になぞらえる仕事の方も大きいんじゃないのって思うわけ。
なるほどね。
例えば脆弱性の情報が出ると、自分たちのシステムへの影響を調べて、危険の大きさや対応の優先順位を見極めるよね。
修正によって別の問題が起きないかも考え、更新や一時停止の判断も支えるじゃないですか。
被害が起きれば、拡大を防ぎ、復旧を進め、原因や再発防止策も検討しなきゃいけなくなってくると。
この仕事では、状態を見ること、先に手を打つこと、限られた情報と時間の中で判断することが重要になってくる。
これって一種の診断とか予防とか、災害時の被害抑制や復旧みたいなこと。
そういった仕事の組み立てに共通する部分がすごいあるんじゃないかって気がする。
実際、Googleの障害対応は、山火事や地震などの緊急事態に使われる指揮系統を基にしているとのことですね。
Googleのインシデント対応の説明っていうのがあるんですけども、これを読んでそう思いました。
そう考えると、アプリを作る人っていうイメージでは捉えきれない専門性が、明らかにエンジニアにはあるじゃないですか。
出来上がった機能は見えやすくても、問題を早く見つけたことや、被害を起こさずに運用を続けられるっていうことが、
成果として見えにくくなっちゃってる。だからさ、これ、エンジニアっていう言葉じゃない語を作らないといけないんじゃないかと思った。
保守とかを専門にやってる人たちには、それなりの特徴的な名前があっていいんじゃないかと。
例えば、もうこれそのままだけど、「パッチワーカー」みたいな。問題が来たときに修繕していくっていうこと。
あるいは、セキュリティマネジメント。つまりさ、例えば、このサービスを止めたら経済的な損失はあるんだけど、
でもこれ明らかにリスクの方が大きいから、エンジニアの判断で止めるってなったときに、その人はもはやエンジニアじゃないじゃん、
って思うわけ。マネージャーじゃんって思うの。だから「セキュリティマネージャー」みたいなふうに思うんですよね。
だから、エンジニアっていう言葉じゃもう表せない領域に、社会の期待があるはずだから、違う言葉を作ってった方がいいんじゃないか、
みたいなこと。伊藤がやってる仕事もさ、この部分が大きいんじゃないかなって思うの。
ああ、そうだね。実際、エンジニアっていうふうに世間で捉えられてる仕事の中では、実際に手を動かす人、プログラマーっぽい人もいれば、
タスク全体を管理する、ほとんどコードを書かないようなマネージャー、マネジメント業をやってる人もいるし。
大きなプロジェクトになれば、セキュリティマネージャーって呼ばれる人はいるよね、立場としては。
なので内部では確かに、お互い呼び合うときにそれなりに名前があって、一般にどれくらい普及してるかって話と、現実問題として、
一つのサービスには、そのサービスを作るにあたる工程を考える人、設計をする人、実際に手を動かす人、
保守する人っていういろんな段階があるんだけど、一人でやってるとか二人でやってるとか、そんなのざらなわけで。
そこをちゃんと切り分けられるほどの規模感を持ってないっていうこともあって、
「お前はエンジニアだから全部できるよな」ってなってるっていうパターンは。
そうだね。
「インターネットのことは全部お前がやるんだろう」ってなってるってパターンがあるかな。
それはちょっと浮き彫りになってるかもね。
エンジニアって言葉で片付けようとする節はある。
あとほら、「ネットにつながないことが大事だよね」みたいな普通の話もあるよね。
例えば防衛とかさ、それこそ医療とかの機器をネットにつないでることもあるかもしれないけど、「それ、もうつながない」みたいな。
そうだね。完全につながないっていうのは、一つのセキュリティの形としてあるから。
そう。だから、病院の内部のサーバーだけで運営しているネット空間があった、みたいな。
それを差配したり、システムを作ったりするのも、セキュリティマネージャーの仕事な気がするんだよね。
うん、そうだね。そういうのが大事だってことを、専門的な知識を持ってないと知らないってことは結構あるから。
大きな企業だと、確かに会社の中に一個だけスタンドアロン機っていう、完全に独立したサーバーがあって、
現地に行って手を動かさないと操作できない。そこに真の情報がためられているみたいなことは割とあるから。
そういうのは部門としてはエンジニアの領域なんだけど、ちゃんと分けて考えると、専門性で言うと結構違うかもしんない。
「パッチワーカー」って言葉はたぶんあんまり使ってないかもしんないけど、面白いね。そういう専門性のある言葉っていうこと。
まあ、みたいな感じのことを思って、今日、時事問題を切り口にしながら、ちょっと論点を出してみたっていう回だったわけです。
AI時代の技術者の倫理と役割
そうだね。ちょうどほんと、この二、三日前にPHPの脆弱性っていうのが話題になってて、SNS上でみんなが混乱しているわけだ。
「エンジニアの人、頑張って」っていう人もいれば、「何が起きてるの、携帯をつけない方がいいの」とか、
「家のパソコンの電源を落とした方がいい？」って混乱している人もいて。
だから、どこまでみんながそういうものを常識として持っておくべきかっていうのは、結構難しいなと思うけど、ある程度、
現代においては公教育の中で話されるっていうのもいい気はするし。
やっぱ「脆弱性が見つかりました、危険です」っていう情報がバーンって出たときの、この世の中の混乱ぶり。
それだけみんなインターネットに依存してたし、その依存してたインターネットが何かやばそうだって雰囲気だけでパニクっちゃうっていうの
は、何かこう。
そうね。社会を普通にマクロに運営する視点として考えても、情報の流通がうまくいってないってことだよね、それってね。
もちろんさ、かなりこのリスクについて理解した上で、ネットを切るっていう感性があってもいいわけじゃん。
子どもが利用することがあるかもしれないから、そういうふうに思って。
だから、それを分かった上でそれをするならいいんだと思うんだよね。あんまりうまくいってない気は現状しますよね、社会に対して。
この起きている事態について、正確にどれぐらい伝わっているかという観点から見たときに。
マクロな視点で言えば、法整備とか文化とかが、高速化するデジタル社会にどれぐらい追いついていけているのか、みたいな話も思ったし、
個人レベルで言うと、インターネットとどう向き合うのかみたいな話は出てきている。
それを突きつけられてるね。
それはAIがでかいと思うけど、やっぱりスピード感がえぐい。
じわりと熟成されていくような感じじゃなくて、「どうするかを決めろよ」って言われてるような感じはするので、
ちょっと改めて考えるきっかけになったなと思いますね。
今回、AIの話をほとんどしてないんですけど、本当はそこ、重要な論点のはずなんですよね。
これは本当に個人的な印象だけど、やっぱ今年、ここ数か月、サイバーセキュリティの問題がすごくニュースにもなる。情報流出の話が出る。
それと僕の中でリンクするのは、ついここ一年ぐらいで、AIの計算能力がちょっと人間を超え始めてるなと。
数学の未解決問題を解決していったり、みたいな。
我々が捉えられる範囲を超えた能力をAIが持ち始めてる時期と、ちょっとやっぱりリンクする気がするんですよ。
だからそれこそ、将棋とかでAIが勝ち始めたときがあったわけじゃん。
そうだね。
そのときには何か牧歌的だったよね、あの頃はね。もっとね、AI対人間を戦わせてとか、楽しんでたけど。
楽しんでたよね。
でもさ、数学の未解決問題を解決し始めちゃってるじゃん。これ、もう明らかに違うフェーズに入ってることを認識しないと。
あるいは、技術の面白かった面を、とりあえず僕たちは味わってきた。
AIが来て、それがAIにスライドを作らせたりして、「業務効率化できた」みたいな話だったのが、
そうじゃないバックラッシュが今バーンと来てる。当たり前だけど。
そうだね。
来てるっていうフェーズですよね。
そうだね。それは本当によくよく分かっておかないと、ということですね。
ただ、AI怖いって言ってもしょうがないし、いや便利だって言っててもしょうがないので、やっぱ技術っていうのは、
使いどころと関わり方っていうのを考えなきゃいけないし。
まあ、インパクトが大きいですからね。
そうですね。
なるほどね。俺、思うけど、やっぱりエンジニアって人に期待されること、それは仕事以上のこと、
つまり意見を言うみたいなことが求められてくると思うよ、っていう。
そうだね。
俺、だから伊藤君、さっきさ、「それはそういうこともできるんじゃないですか」っていうことを、エンジニア的に言ってたけど。
まあ、そうだね。エンジニアは可能、不可能の話をしがちで。
そうそうそう。でもさ、それ以上のことを俺は聞いちゃってるじゃん。「俺はこういう夢を見てたんだよ」みたいなさ。
「どうなんだ」っていうね、胸ぐらつかまれてるわけだから。
そうそうそう。「それもできるんじゃないですか」じゃなくて、コミュニケーションの側面が求められているなと思いますけどね。
技術を作る人が結構、社会を変えるっていうことがすごく言われてるわけじゃないですか、世の中的には。
ここ数年ずっと、新しいサービスが社会を変えるんだ、みたいな。でもエンジニアの人って、そこから先あんまり語らないんだよね。
つまり「こういうことはできますよ」って言うんだよね。そこで終わっちゃうんだよね。でもそれじゃ、済まなくなってきてると思う。
つまり、「いや、望ましい社会はこうなんだ」って言えないといけないと思うよ。
これは何かこう、父親みたいなエンジニア。
でもそれさ、誰かがそのポジションを取らないといけないと思う。エンジニアの人の誰か、影響力のある人が。
現状、それについて言ってるのはイーロン・マスクとかになっちゃってるじゃん。
彼のすごい感性で、社会はこうあるべきだみたいなことを語っちゃってる。そのポジションって、でも実はすごい重要なんだと思うんだよね。
イーロン・マスクが言ってることで、良くないこともすごく言ってるから感心できないんだけど、あれは違う立場の人が誰か、
そのポジションを取らないといけないんだよね、本当は。
ただ単に技術を作ってるだけじゃ、もう済まないレベルになってきちゃってるんじゃないかな。
そう。だからつまりさ、世の中に「こういうサービスできますよ」っていうことと、「世の中はこうあるべきだ」って規範で語るのって、
全然別じゃないですか。それは、その人が社会の中でどういう役割を担っているかによって変わってくるはずだよね、
どこまでをしゃべらなきゃいけないかっていうのは。
エンジニアっていうのは、もう、こういうことができるっていうようなことを技術についてテクニカルに語ってればいい領域を、
もはや超えてると思う。たぶんさっき言ったような、セキュリティマネージャーみたいな領域に行かないといけない段階に来てるよね。
つまり、エンジニアの独自判断で、損害が生じることが分かってたとしても、
ある企業のサービスを止めなきゃいけない領域に来ちゃってるじゃん。
そのような領域に今、進出してるんだとしたら、その人は、
じゃあサービスはどうあるべきかってことについても考えなくてはいけないはずで。
システムを設計するだけじゃなくて、っていうことですよ、僕が言いたいのは。
いや、それはね、ちょうどこの話題の中でも、ちょっとトピックとして語られたけど。
僕はね、特別な資格とか持ってないんですけど、エンジニア系の資格を取るときに必ず聞かれる質問に、その倫理観、
エンジニアとしての倫理観を問う問題っていうのは必ずある。
それはもう、免許を取るときの適性検査みたいな感じで、「当たり前だろ」みたいな問題なんだけど。
人を傷つけてはいけないとか、公序良俗についてしっかり考えるべきか、それとも便利なツールを作るべきか、
それとも会社の利益を優先するべきか、みたいな中から、人間として当たり前の感覚をちゃんと持ってますかって聞かれたりするんだよね。
なるほどね。
つまり、何かものを作るってときには、ただ作り続けるだけじゃなく、
それがどう影響するかまで考えなきゃいけないよという思想自体はあって。
それが改めて今回、話題にもなってたんだけど、まさに考えるべきポイントの一つってことですね。
なるほどね。そんな感じで、いろいろ今回は話していったわけですけど。どうですか？ 感想は？
やっぱり、こういう専門的な分野とされちゃってる部分。
本当はもうみんなに関わりのある、インターネットとかセキュリティが関わりない人はほぼいないのに、
みんながよく分からないものとして扱っちゃってる現状を、ちょっとでもみんながちゃんと考えて、
「向き合い方はちょっと思い直さなきゃな」とかってなればいいなという印象でしたね、今回の出来事は。
なるほど。
まさにこのポッドキャストを聞いてくれる人たちは、インターネットを介して、我々は情報を発信し、受け取ってくれているということで、
全く興味のない人はいないんじゃないかなと思ってます。
今回は、インターネットとの関わりっていう話と、あと、エンジニア、セキュリティ、
保守をしてる人たちってどういう存在なのかっていう話と、二つありましたけど。
身の回りでね、もしエンジニア、「私、エンジニアです」みたいな人とかがいて、「こういう苦労話あるんですよ」。
エンジニアの苦労話って本当に絶えないんで、そういうのがあったら、ぜひ聞いてみたいですね。
いや、面白いですよ。社内政治に巻き込まれたりとかね。
はいはいはい。
いろいろありますので、そういうのがありましたら、ぜひ概要欄のフォームからお便りをお願いいたします。
あと、番組のフォローもよろしくお願いします。それでは、また次回。
はい、また次回。
