連載：DXにおけるDevSecOpsとは？「AI/機械学習のサイバー脅威と、日本流DevSecOpsの導入方法」「DevSecOps Days Tokyo」レポート③（後編）

一般講演「AI/機械学習のサイバー脅威と、日本流DevSecOpsの導入方法」

前編はこちらからお読みいただけます。

AIは簡単にハックできる

ここからは、AIのサイバーリスクについてジェネラルに考えていきます。AIに限らずあらゆるシステムや人間の情報処理は、何かを入力し、情報処理し、出力するというステップを踏みます。このどの部分を攻撃してもハックできてしまうのです。

入力をハックされた例を一つ挙げると、マイクロソフトの作ったチャットボットにユーザーがゴミのデータを学習させていった結果、差別発言をするようになり、サービス自体を停止したということがあります。あとは学習済みモデル自体もハックできます。一時停止の標識にテープを貼ると、AIはこれを一時停止ではなく、速度制限の標識だと判断してしまうという。実際に運転アシスト機能で、標識を認識する機能が最新の車には搭載されていますが、あるラーメン屋さんのチェーン店の看板ロゴが進入禁止の標識だと誤認識したという例があります。これはハックしようとしたケースというよりはバグが見つかったケースです。これを意図してやることも当然できるわけです。

上記、左と右に車の写真があり、人間にはどちらも車に見えるのですが、右の写真にはあるノイズを入れているんです。ノイズを入れた結果、右の写真をAIはダチョウだと判断しました。人間には全然ダチョウに見えないのですが、AIは人間と同じような認知の仕組みをとっているわけではないので、こういうミスが起きます。
さらに、ノイズをいっぱい加えなくとも、1ピクセルだけいじることで、認識結果が変わることがあります。鹿の写真をいじって1ピクセルだけ白にしただけで、AIが85.3%は飛行機でしょうと判断をしたのです。これを1ピクセルアタックと呼びますが、こういうこともできてしまうのです。
さらに、AIが出してきた結果そのものを書き換えてしまえるという問題もあります。このように考えると、いつどのように狙われるか分かりません。

アメリカと日本ではソフトウェア開発の仕方が大きく異なる

最後に、日本流のDevSecOpsをどう実現していくのかについても考えなければなりません。アメリカから教わった方法を日本で導入しようとしても、状況は異なります。例えば、ソフトウェア開発に従事する技術者が社内にいるのか、社外にいるのかということです。アメリカは72%と、ほとんどが社内技術者で、3割ほどが社外の技術者です。一方の日本は、社内技術者はわずか25%で、残りの75%は社外技術者なのです。

このため、日本でユーザー企業側がどのようにソフトウェア開発に関わっているかというと、ほぼペーパーワークといえます。ソフトウェア開発のプロセスにユーザーが入っているようで入っていない。ソフトウェアの中身がブラックボックス化しています。例えば、オープンソースをスキャンして脆弱性が見つかったらバージョンをアップするような便利なツールはありますが、今のままだとSIerがやりたがらない。
「あれ、なんでSIerさんはこんな脆弱性の高いコードをほったらかしていたんですか？」という責任問題になって、面倒なことになるので、SIerがやろうという意欲が湧かない状態になっています。

これが日本経済全体の脅威なのではないでしょうか。ソフトウェア開発の競争力自体が経済競争力の源泉となっているにもかかわらず、手持ちのシステムはベンダーロックインされたブラックボックス状態です。グローバル企業においては、当然グローバル競争市場で敗北し、日本経済を支える基幹産業が衰退しかねない状況なのです。

これについて私は、自前でシステムを作っていくしかないと思っています。基本的なアーキテクチャを社内でデザインし、それを作る指示やコードレベルでクオリティチェックができる人材を採用・育成すべきでしょう。
完成されたシステムに対してお金を払うのではなく、純粋にエンジニアリソースにお金を払う。そして、システム開発アーキテクチャをマイクロサービス化し、全体システムの中の重要なモジュールは内製化して、他は外部企業とコラボしながら作っていきます。これはベンダーロックインを排除し、ソフトウェアライフサイクルを早く回す上で重要なことでしょう。
結局、自分たちで責任を持って作るしかありません。

SIerには内製化支援が求められる

クライアントの経営のために、これからはSIerはクライアントの内製化支援をしていくべきではないかと私は思っていますが、事業構造を変えるのはなかなか難しいかもしれません。この点、ベンチャー企業や若手の方々に期待しています。DevSecOpsが前提となるようなクラウド・ネイティブで、コンテナを使い、コンテナオーケストレーションにKubernatesを使い、マイクロサービス・アーキテクチャを採用する…といったように新技術をフル活用し、自前でシステムを作るような会社に移って腕を磨く。これは必ず今後のスキルにも生きてくるでしょう。あるいは、内製化を支援するベンチャー企業を興してもいいと思います。

日本流のDevSecOpsの本丸というのは結局、18兆円あるITおよびシステム開発業界全体の産業構造の変革だと私は考えています。一歩目はやはりDevSecOpsについて十分な知識を浸透させ、知見を共有することです。いかにして日本企業が産業競争力を維持するかについて、現在のSIerと企業の間の付き合い方に潜んだ構造的な問題を直していくべきでしょう。

※本記事は、DevSecOps Days Tokyoの許可を得て、記事掲載しています。

連載：DXにおけるDevSecOpsとは？

「DevSecOps Days Tokyo」レポート①：「米・国防総省はどのようにしてKubernetesとIstioへの移行を果たしたか？
「DevSecOps Days Tokyo」レポート②：「DevSecOpsの導入を成功させるための5つのチャレンジ」
「DevSecOps Days Tokyo」レポート③（前編）：「AI/機械学習のサイバー脅威と、日本流DevSecOpsの導入方法」
「DevSecOps Days Tokyo」レポート③（後編）：「AI/機械学習のサイバー脅威と、日本流DevSecOpsの導入方法」
「DevSecOps Days Tokyo」レポート④：「AI/アナリティクス サービス企業でのDevSecOps：これまでとこれから」

この記事の続きはこちら
連載：DXにおけるDevSecOpsとは？「AI/アナリティクス サービス企業でのDevSecOps：これまでとこれから」 「DevSecOps Days Tokyo」レポート④