「システムリスク」タグアーカイブ

AI と家電と桜の開花予想

投稿日時: 投稿者:

AI を自社のビジネスや業務プロセスに取り込む試みを進める企業は、個人的な肌感覚としては増加の一途をたどっています。AI について統計調査をすると、認知度は高くても導入済みはあまり多くないという結果が出ているようですが、想像するに、リテラシーの高低によりかなり二極化が進んでいるのではないでしょうか。

積極的に AI を使い倒そうとしているのは概ね大手企業で、相当な数の事例がすでに出てきています。世間に公表するような事例ですから、どれも秀逸な内容で、それならウチもやりたいとインスパイアされる経営者も多いかもしれません。

以前から申し上げているように、IT は「試す」のが大変重要です。新しいものが出てきたらなるべく早く情報を捕まえ、まず「試す」。そのうえで、使えそうかどうか判断し、さらに「試す」を続けて、徐々にモノにしていく。そういう組織的態度の会社は、だいたい IT をうまく使いこなせる会社になっていきます。

ただし、「IT → 家電と同じ」と（無自覚に）勘違いしている会社は、特に AI に対しては注意が必要です。確実に頓挫します。

なぜかといえば、これもまた以前から申し上げている話ですが、家電と違って IT というのは導入すれば「運用」が発生するからです。家電は買ってきて備え付ければあとは使うだけですが、IT は違います。買ってきて導入したら、それを人間が運用し保守しなければ、当初に目論んでいたような機能を果たし続けないのです。これは、IT を自分たちに適した形でカスタマイズして使いたいと思えば思うほど、そうなります。

AI は、その最たる例といっても過言ではありません。その主な要因は、AI が「データを基に動作している」ことにあります。

AI が機能するエンジンとなっているのは、最近のケースで多いのは、機械学習によって形成された推論モデルです。機械学習は、何らかの過去のデータをインプットにして行われます。裏を返せば、データがなければ機械学習はできず、モデルは形成されず、AI は活用できないのです。

このとき問題は、糧にしているのが「過去のデータ」であることです。過去は過去であり、現在や未来とは異なる可能性が大いにあります。しかし、私たちが AI に求める成果は「いまからどうなるか」、つまり推論です。過去のデータに基づいた判断によっておよそ現在や未来を見通せるなら問題ありませんが、現在や未来ではもはや状況が変わってしまうとすれば、AI による推論は役に立ちません。

例えば、春は桜の季節ですが、桜の開花予想に「600℃の法則」というものがあるそうです。これは、2月1日以降の毎日の最高気温を積算し、その合計が約600℃に達すると桜が開花するという経験則（いわば、学習されたモデル）です。しかし近年、気温の変動が過去と変わってきてしまっていることから、この法則が外れやすくなっているといいます。これもまた、過去のデータでは現在が予測しづらくなることがあるという、ひとつのケースといえるでしょう。

そんな変異が往々にして発生するので、AI をビジネスに組み込んで使いたいのなら、機械学習による推論モデルを継続的にアップデートし続けなくてはならないわけです。データは、ほんの些細なことで変容します。例えば、Webサイトのデザインを更新しただけで、利用者の使い方が変わり、利用傾向は変化します。そのログデータを使ってモデルを作っていたとしたら、サイト更新の前後で挙動が予測できなくなる可能性があります。

また、過去のデータを学習しているので、過去にはなかったことが発生すると、当然推論はできません。極端な話で説明すれば、例えばある年の3月に開店したチョコレート店が、店の購買履歴を使って AI で販売予測モデルを作ったとしたら、2月のバレンタインデー前に売れ行きが急に上昇することをおそらく予測できません。人間からすれば当たり前のことでも、この店の場合は「過去にないこと」なので AI には予測不可能です。

さらに言えば、データは大抵、人間が入力しています。人間が入力を間違えたデータを、知らないうちに AI が学習するとなれば、間違った推論をするモデルが出来上がることになります。それに気づかずに予測を信じてしまう、ということも想定できるわけです。

ですから、AI を導入したなら、その瞬間から「運用」が始まり「保守」しなければなりません。新しいデータを次々と投入してモデルを更新し、最新を保つとともに、出力は常にモニターして、おかしな挙動があればすぐに対応し、場合によっては AI の利用を停止して人間による業務に切り戻すことまで考えておく必要があるのです。そうしなければ、AI が吐き出す間違った予測を信じて間違った判断や対応をし、結果としてビジネスに損失を与えることになります。

こうして見ていけば、「IT → 家電と同じ」と考えることがいかに危険極まりないか、ご理解いただけるのではと思うのですが、いかがでしょうか。

面倒だと思いますか？そう思うのなら、AI には手を出さないのが身のためです。そのような面倒や手間を超えたところに存在する目的を持っている企業が、AI の活用に成功するのです。そうした目的もなく流行りの IT に手を出す企業は、かけた投資に見合う効果がほとんど見えずそのうち取り組む意味を見失って頓挫するか、他人がつくった AI モデルに手持ちのデータを食べつくされて気づいたときには自分には何も残っていない、などということになるでしょう。

もしかすると大手企業にも勘違い企業がいるかもしれませんが、そういう企業はこれから頓挫していくはずです。大々的にアピールされている「秀逸な事例」を妄信せずに、その後はどうなったかまでよく観察してみましょう。

AI ブームはリアルかバブルか、先を見る

投稿日時: 投稿者:

1月末、株式市場で大幅に値を下げる事態が起こりました。日経平均は一時 1000 円以上値を下げ、ダウ平均も一時 500 ドル以上下がりました。いわゆる「DeepSeek ショック」と呼ばれる事態ですが、きっかけは中国の AI スタートアップ企業が公開した LLM（大規模言語モデル）です。その性能が ChatGPT を開発する OpenAI の最新モデルにも匹敵するとされながら圧倒的な低コストで開発されたと知れ渡り、膨大な投資を続ける AI 関連企業の株価が大幅に下落した、ということでした。

背景にあるのは、「スケーリング則」と呼ばれる、AI 開発の世界で信じられている経験則です。AI モデルを開発するにあたって、モデルの性能は、学習に利用する「データの量」「計算量」「モデルのパラメーター数」の3つが大きくなればなるほど向上する、という法則です。この法則に従う格好で、資金力のあるビッグテック企業を中心に数十兆円にもなる大規模な設備投資を行い、これら3要素をふんだんに扱える能力を高め、性能の高いモデルを生み出して我が物にする、という競争を続けています。かの DeepSeek はこの経験則を完全に覆すようなものを世間に出してきた、ということから、株価の大幅下落につながりました。

しかし直後から、DeepSeek のモデル開発に疑念の声が挙がり始め、その性能や品質にも各方面から問題の指摘が相次ぎ、スケーリング則の信頼が覆されたわけではないという認識が広がりました。どういう認識が正しいのかは、わたし個人はよくわかりませんが、いまのところ騒動は沈静化しているように思われます。

ただ、このような動揺がある意味で容易に広がってしまうあたり、現在起こっている AI の開発競争は一種のバブルの要素をはらんでいるというリスクを、頭の片隅には置いておいたほうがよいのかもしれません。AI に欠かせないことになっている GPU の製造の事実上一社独占、資金力にものを言わせる巨大企業による AI モデル開発の寡占、モデル開発に伴う超大規模な投資競争、等々。いびつな構造は数々思いつくわけで、バブルのニオイがしないのかと言われれば、そうなのかもしれません。

ビッグテック企業が挙って開発している AI モデルは LLM ですが、おカネをかけている開発している企業の多くは、現状ではクローズドなモデルを開発しています。つまり、技術を独占して公開しない方針ということです。それとは異なり、オープンソースで LLM を開発している企業もあり、それが米メタや、今回話題になった DeepSeek など中国系の企業です。DeepSeek も、メタが開発した LLM を利用したとされています。

もし今後、オープンソース系の LLM のほうが性能やコスト面でクローズドなモデルを凌駕し、モデルのスタンダードになるのだとしたら、AI モデルはコモディティ化し、誰でもローコストで利用できるものになるかもしれません。または、GPU 以外の選択肢が現れることでインフラコストが下がり、学習コストは議論にならなくなるかもしれません。

LLM に関しては、AI 研究の権威として著名なヤン・ルカン氏は、LLM をこのまま進化させたとしても性能は頭打ちになるだろうと予言しているようです。端的にその主張をまとめれば、次のような内容です。LLM は「言語」に基づいてモデルを生成しているが、人間世界では非言語で処理している情報も多い。現実の世界の一部しか言語は表現できないので、言語にしか基づかないモデルにはおのずと限界がある、と。他にも、言語というものは実は曖昧で厳密さに欠ける、少なくとも数学が持つような意味の厳密さはない、だから思考能力の向上には限界がある、という指摘もあります。

そうなると、いまのところ信じられているスケーリング則は、やはり将来のどこかで、再び疑念を持たれる事態が待っているのかもしれません。

仮にスケーリング則の信頼がこのまま揺らがないとしても、モデル開発への巨額な投資を前提とする AI 開発企業が、このままビジネスを続けていけるのかどうかわかりません。そうした企業で現在までに、健全な黒字経営で成長できている企業はあるのでしょうか。巨額の赤字をほぼ外部企業の出資で賄っている企業、出資金が不足して徐々に首が回らなくなり始めている企業、等々の話はたびたび聞くようになってきています。

単に AI を利用するだけの立場なら、あまり気にせず高みの見物を決め込んでおいても問題はなさそうです。もし、自前で LLM を開発して世間の先端を行こうとしているか、そういう会社に設備を提供すべくインフラ投資に勤しもうとしているか、そんな会社なら少々立ち止まって先を読んでみるのも必要かもしれません。

単なる利用者に徹するとしても、少なくとも、利用する LLM や AI モデルを簡単に入れ替えられるようにしておくことは、利便性の面だけでなくリスクヘッジの意味でも大事でしょう。案外、考えて使っていないといつの間にかベンダーロックインされているということは、よくあります。

そして当然ながら、自社のデータ、または、意識すれば自社所有のデータにできるような情報、を簡単にサービス事業者に明け渡さない、預けないことです。データがロックされるか失われて、気づいたときにはもう取り戻せない、取り消せない、という事態になるリスクは、外部サービスを利用するなら常に想定しておいた方が身のためです。なにぶん残念なことに、銀行の貸金庫に保管している大事な資産も、気づいたらなくなっているような世の中です。

「デジタル化が遅れている」と言われて、安直に急がない

投稿日時: 投稿者:

マスコミがさかんに「日本企業はデジタル化が遅れている」とはやし立てるせいか、判断に必要な情報が足りない、業務が非効率で混乱している、などといった課題に直面したとき、「システムを入れよう」という発想になる経営者や経営幹部が、最近多くなってきたように思います。

今回のコラムは、その発想は悪いことではないが安直である、というお話です。

もう多くの方にとって忘却の彼方に行ってしまったことかもしれませんが、コロナ禍が始まった時、医療現場ではコロナ患者の動向に関する情報収集をめぐって、深刻な混乱が発生していました。

国は当初、全国に感染患者がどれだけいるのかを集計するのに、電話やFAXを使っていました。しかし、それでは不正確で不確実なことはすぐに明らかになり、すぐさま「システムを入れよう」という流れになりました。

ところがこのシステムに必要なデータとして列挙された項目や内容があまりの分量となり、そのデータ入力作業は医療現場の人々にとって、押し寄せる患者の看護や治療でひっ迫している業務へのさらなる負担となりました。

結果、どうなったか。医療機関によってはすべての項目を入力せずに報告したり、1週間分をまとめて入力して報告したり、などという行為が横行したのです。

テレビやネットで情報を見ていた我々一般人は、感染者数の動向などはリアルタイムで報道されていると思っていたわけですが、実態は「だいたいの数字」を見ていた、ということになります。

システムを導入する、デジタル化をする、ということは、要するに何をすることなのか。一度は深く考えてみる必要があると思います。

データが見たいというのなら、まず自らの手でデータを生み出さなければいけません。データは、そこに自然に置いてあるものではありません。自然に湧いて出るものでもありません。ほしいデータは、通常は自分で作り出さなければ存在しません。例えば、いま誰もが当たり前に毎日使っている「温度」や「湿度」でさえ、その昔それが知りたいと考えた学者が生み出した指標です。

そうしてデータを生み出したところで、それは多くの場合、人間の手で「入力」されて初めて実体になります。裏を返せば、それは人間の対応次第で誤ったデータにも、汚れたデータにもなる、ということです。データだから正確、という保証はないのです。では「正確なデータ」をどうやって収集するのか。何をもって「正確」だとするのか。人手を介さず自動でデータを収集できるのが理想ですが、そうしたいなら自動で収集するやり方を、また自ら編み出さなければなりません。

データを収集する、データを加工する、データを集約する、そうして処理したデータを使えるように反映する、等々、一連のデータ処理を実行する「しくみ」もまた、自ら考え出さなければなりません。

世間に売っているソフトウェアやクラウドサービスを採用すれば済むと思っている経営者や経営幹部は多くいますが、それらを導入して「帯に短し襷に長し」な状況に陥った実体験をしたことがないのでしょう。自分のやりたいことが具体的で明確であればあるほど、それに一挙に適合する出来合いのソフトもクラウドサービスも、ますます見つからないのです。逆に自分のやりたいことが曖昧で明確でないほど、今度はソフトウェアやクラウドサービスの都合に振り回されることになります。

そのような、自分がやりたいことを実現する「しくみ」を設計する源泉は、どこから来るのでしょうか。

それは、データが見たい、業務を合理化したい、という課題解決を必要とする「目的」です。なぜそれが重要なのか、それをしないと会社はどうなってしまうのか、いままでのやり方を曲げてでも新しいやり方を採用してデータ入力の仕事を負担する必要がなぜあるのか、それが説明できなければなりません。

新しいやり方を採用しようとしたとき、そのやり方の実践には、一定の「デジタルの素養」が必要な場合もよくあります。その場合は、現場に対するデジタル分野の知識強化のサポートも必要になります。勝手に覚えてシゴトしてくれ、では通用しません。

的確に説明ができなければ、また現場に対する的確な支援が提供できなければ、現場は黙って、データ入力を実行しないか、正確性を追わずいい加減な対応でお茶を濁す行動に出ます。コロナ禍で、感染者数の正確な情報提供が重要であることは十分に理解していたはずの医療現場でも、前記したようなことが発生しているのです。

的確な説明を考え、説得できるのは、その取り組みを主導する経営者や経営幹部以外にいません。デジタル化を進めるとき、全体構想を考案し、実現シナリオを設計すべきなのは、取り組みを主導する経営者や経営幹部です。「ITに詳しい人」ではありません。

よく「経営トップが主導せよ」「経営者の意識が低いのではデジタル化はできない」などと言われているのは、こうしたことが本質なのです。「デジタル化をするぞ」「データを見える化するぞ」と掛け声をかけるのがトップの役割、などと考えていたら、道を誤ります。

デジタル化を進めたい、という思いがふつふつと湧いてきた経営者の方々は、一度立ち止まって、「それ、どういう仕組みで実行するの？」ということから絵に描いてみてください。わたしに聞いていただければ、その絵にいろいろなツッコミを入れさせていただきます。

DXを語る前に、まず「ITの運用」ができるか

投稿日時: 投稿者:

2022年10月末に、大阪急性期・総合医療センターという病院でシステム障害が発生し、通常診療が全面停止する事態になりました。

その原因となったのは、ランサムウェアによる攻撃でした。電子カルテシステムを含む院内のデータが暗号化されて利用できなくなり、緊急手術以外の外来診療の一時停止を余儀なくされたのです。同病院は、攻撃者から脅迫を受けながらも、全システムを再構築により完全復旧させる方針を決断し、それに3カ月程度かけることにしました。

聞くところでは、この規模の大病院になると、医療機関としての総合的な運営コストは、1日当たり1億円程度になるのだそうです。通常診療ができないということであれば、そのコストがただ毎日出ていくだけの日々を、約3カ月の間過ごすという決定を下したことになります。それでもシステムの全面再構築の道を選んだわけですから、容易な判断ではなかったでしょう。

その攻撃被害の原因や再発防止策を検討した調査報告書が、2023年3月末に公表されました。

報告書では今回の攻撃を許した原因を整理して指摘しており、部外者の我々も対策を考えるうえで参考になる内容になっています。その中でわたしが注目したことのひとつに、攻撃者の侵入のきっかけになったとされている、外部の給食事業者の存在があります。

攻撃者は、同病院の入院患者向けの給食提供を業務委託で行っていたこの事業者が所有するファイアウォールを破って侵入し、その会社の業務サーバーを乗っ取りました。そこで、同病院のサーバーへの認証情報を得て、同病院が管理する給食サーバーへ横展開していったということです。

このファイアウォールは、給食事業者のシステム構築を担当したベンダーがリモート保守で用いるために、外部からのアクセスを可能にするように認証設定されていました。ところが、ファイアウォールの装置自体がもつ脆弱性が放置されていた状態でした。その脆弱性を突かれたため、アクセスのためのIDとパスワードが窃取されたといいます。

わたしがなぜこの給食事業者に注目したかと言えば、この事業者は侵入のきっかけを作ったそのファイアウォールについて、「存在を知らなかった」と答えているというからです。

このような話、つまり、自分たちがどのような装置や機器を使っているのかを全く把握していない（特に中小）企業というのは、典型的な「あるある話」です。厳に改めるべきことなのです。

そもそも、ITを導入する企業が十分認識すべきことがあります。それは、何らかのITを導入する時点で、その企業には「運用業務」が発生するということです。

運用業務とはつまり、自社が管理すべきIT関連の資産をすべて把握し、それらの資産の適切な取り扱い方法や設定を定めて、適切な動作を継続するように業務を設計して遂行する、というようなことを指します。このとき、自社の管轄ではないが自社のシステムへの影響が避けられない外部の装置やシステムについても、管理責任は軽減されはするものの、自社管理とほぼ同等のケアが必要です。

問題になったファイアウォールが、この給食事業者の資産だったのであれば、管理責任は給食事業者にあります。「存在を知らなかった」では済まされません。

もしベンダーの所有だったとしても、給食事業者がその装置の存在を知らなかったということは、由々しき事態です。ベンダーから説明を聞いていたにもかかわらず忘れていたのだとしたら、給食事業者の責任は免れません。そもそもファイアウォールのような装置では、外部からリモート接続させるなら必要な時だけに限定すべきであり、保守作業の必要がないときでも外部から内部へつながることを許容していたことが問題だと思います。

そうではなく、もし保守ベンダーが給食事業者に許可を得ずに黙って設置していたのだとしたら、ベンダーに対する損害賠償責任が問われかねないようなことに思えますが、装置は会社の管轄区域内に設置されていたのですから、自社内に置いてあるものに何も関心を示さないというのもまた問題です。犯罪者が無断で置いた盗聴器や盗撮カメラに、何の関心も示さず放置するのと同じことです。

ベンダーの説明責任などの問題は多かれ少なかれあると考えられる一方で、装置の運用に対するユーザー企業の認識の甘さ、管理責任の欠如、利用者としての管理努力不足といった道義的な責任は、免れるものではないと、わたしは考えます。仮に、導入したシステムの運用を全面的にベンダーに委託したとしても、最低限の運用管理業務は必ずユーザー企業側に残り、それを負わなければなりません。運用を完全放棄することは、いずれにしてもできないのです。

そういう自覚がないままITを導入する企業が、特に中小レベルでは多すぎるように、個人的には感じています。

ここで経営者の方々に申し上げたいのは、このランサムウェア攻撃被害における給食事業者の責任問題のことではありません。ITを利用する企業はいずれも、ITを会社として利用する時点で、それがいかなるハードウェアやソフトウェア、またはクラウドサービスやツールであったとしても、社内には必ずなんらかの「運用業務」が発生すること、そのために何らかの体制面での措置が必ず要求されること、です。

その対応には、ITを用いたシステムの構成や設定などについて、ユーザー企業自身が少なからず勉強し理解する必要が出てきます。

それがどうしても出来ない、やりたくない、のであれば、会社でITを使ってはいけません。気安く使えば、いつか然るべき時に、この事件の給食事業者のようなことになるでしょう。

いま一度、「企業におけるIT利用は、電気屋で家電を買ってきて使うのとは違うのだ」と認識いただきたい。切に願う次第です。

ネットの間違いは許しながら、AI の間違いは許容しない人へ

投稿日時: 投稿者:

先日街を歩いていて、前にいた学生風の若い女の子のグループを追い越していったら、彼女らが ChatGPT を話題にして盛り上がっているのが聞こえてきました。人工知能（AI）も、そんなところでネタになるほど世間に浸透したんだなと実感した次第です。

学生の人たちが AI を意識するのは、もしかすると「ChatGPT を使って宿題をやるな」という文脈なのかもしれませんが、企業においてはそうした制約は特にありません。しかし、ビジネスの領域ではむしろ、AI がもつリスクのほうがより意識されやすいような気がしています。

かの ChatGPT も、回答する内容は時に不正確、誤解を招く、偏見に満ちている、という場合があると、事前に断っています。また ChatGPT に対抗して先ごろ Google が一般公開した対話型 AI「Bard」も、同様の注記を掲げています。

それを真正面から受けて、不正確であることを AI を使わない理由にする企業やビジネスパーソンをよく見かけますが、それはいささかもったいない判断です。

AI が人間から見て不正確であることは、おそらくこの先も不変であろうと思います。AI にまつわる誤認識や誤判断のリスクは、これからもずっと付きまとうでしょう。しかしながら、100点を取れなくても70点程度正解してくれれば十分な改善になるムダが、世間にはたくさんあるはずです。AI が活かせる領域とは、そうしたところではないでしょうか。

もちろん、予測するだけ無駄なことを対象にして AI の予測モデルを作ろうと努力してしまうことは、やるべきではありません。開発のコストメリットを上回るだけの効果がないのなら、予測モデルをつくるだけ無駄です。そんなこと当たり前だと思う方は多いでしょうが、現実は、そういうつもりはもちろんないのに無駄な予測モデルを作ってしまって成果が出せないでいる例がたくさんあると聞きます。そもそもその予測の精度が向上すればどのくらい「効果」が得られるのか、本格的に取り組むより早い段階で評価することが重要です。

また、許容可能な予測をするには相当高い的中精度を要求されてしまう課題に取り組んでしまうことも、やるべきではないことです。例えば、AI が行う判定が人の人生や生命に関わるような場合、適用には慎重にならざるを得ません。

一方で、現状うまく予測ができていない、予測はしてみるけれどいい加減で根拠に欠ける、予測しようにも相当な工数や労力が取られている、という領域がいろいろあるはずであり、それらは AI に適した領域かもしれません。例えば、あるスーパーでは生鮮品の需要が上手く予測できておらず、毎日相当数の商品を値引き販売し、最終的に廃棄されるものも少なくないとしたら、そこに AI による予測を適用して、値引きや廃棄を 100% なくすことはできないにしても、7 割減でも実現できれば、メリットは大きいと思われます。

また、認識精度がある程度に留まるのは承知で、間違いは後で人間がカバーする考え方でも、大幅な省力化が見込めるケースがいろいろあるでしょう。注文書などビジネス文書の文字認識などではこの考え方を応用し、AI-OCR と人間のオペレーターのハイブリッドによる文書のデジタル化サービスを提供する業者が増えています。

つまるところ、AI は「業務のムダ取り」に新しい方向性を与える選択肢だ、と考えれば、いろいろな適用領域が浮かんでくるのではないでしょうか。

「ウチはデジタル化は別に必要がない」と主張する会社の業務の現場を見ると、時々、端から見れば無駄が多い手作業にしか見えない仕事を、その労働にあまりに慣れ過ぎ、まるで職人のライフワークであるかのように一心不乱にこなしていて、終わった時にはやり切った達成感に浸っているような場面に遭遇することがあります。少なくともそんな状況には、陥りたくないものです。

どんなやり方にも「向き不向き」がある

投稿日時: 投稿者:

先日耳にした話です。某官庁でシステム基盤の統括をしているという人物が、政府の情報システムのグランドデザインやそれに伴う業務変革について語っていました。そのなかで、次のような趣旨のことを述べていたのに、いささか驚きました。

もしかするとご本人はそういう趣旨で述べたつもりはないのかもしれませんが、少なくともわたしには、次のような発言内容だったと理解されました。

いま想定している情報システムの設計方針は、マイクロサービスによる疎結合、APIドリブンで設計、開発スタイルはアジャイル。なぜならば、それが「トレンド」だから。

専門知識のない方々には上記の言葉はピンとこないでしょうが、ひとまず放置して先をお読みください。

情報システムを設計したり構想したりするにあたって、設計者が取りうる考え方はいくつか存在します。

それらのアプローチには、時節柄と言っていいのかわかりませんが、話題によく上るものが確かにあります。そうしたものを「トレンド」と呼ぶのなら、トレンドはあるのでしょう。

ただし、これまでに登場したどのような設計アプローチにも、それを採用するにあたっての前提や条件があり、結果として向き不向きが存在するのが現実です。情報システム設計における万能アプローチともいえる決定版は、個人的にいろいろ勉強してきましたが残念ながらわたしは知りません。

よって、少なくともわたしの理解では、設計アプローチは「状況に対応して適切に選択するもの」なのであって、採用する方針は「何を実現したいのか」「アプリケーションをどう動かすべきなのか」というポリシーに従って決定されるものです。トレンドで選ぶものではありません。

例えば、冒頭の引用にある「マイクロサービス」について考えてみます。簡単に言いますとこれは、他とは完全に独立した小さな機能を「サービス」という単位にしてまとめ、それらの小さな「サービス」をたくさん配置して、その「サービス」の間を通信で連携させることで一定の目的を果たそうとする、情報システム設計の考え方のことを指します。

この考え方では、ひとつの単位を占めるサービス（機能）は小さいので、入れ替えることが容易です。作り替えようとした時でも、個々のサービスは独立しているので、他への影響範囲を小さく抑制することができます。新しく追加しようとするときも、他のサービスに影響を与えずに開発して、あとから通信で連携すればいいので、柔軟にシステムを拡張したり改善したりできるのです。

ただし、難点はたくさんあります。大雑把な説明をしますと、「独立した小さな機能」というのは理想的ですが、これを実際につくるのは案外難しいのです。「独立した」とはつまり、他のサービスからは完全に切り離されていなければならないのですが、一切の相互干渉がないように完全に切り離す設計をするのが難題なのです。

それが的確にできないままにマイクロサービス化していくと、重複した機能やデータを持つ複数のサービスが知らぬ間に出来上がり、それが増殖していくことになります。次の難点は、増殖しやすい分運用管理がしにくくなりやすいこと、さらには、増殖するたびに通信のパスが増殖すること、です。無秩序に拡大してしまうことも考えられ、全体としては、品質要求が高いシステムにはあまり向いていない作りになりやすい特徴があります。

もうひとつ、冒頭の引用にある「アジャイル」についてはどうでしょうか。

これは、情報システムの開発手法の一形態です。ざっくり言えば、予め要求を決められないシステムに対して、まずは大事そうなところから小さく作ってみて、それをどんどん改善しながら大きくしていこう、というようなシステム開発のしかたのことを言います。

世の中には、どういうものが欲しいのか？と言われても、ざっくりとした要望以外に何も細かく決められないことがたくさんあります。そうした場合であっても無理やり要求を固めようとするのは、現実的ではありません。アジャイル開発は、そうした状況に対応できるシステム開発のやり方です。

ただし、ご多分に漏れず万能ではありません。要求を固めずに開発を進める以上、始めからパーフェクトな機能が揃ったシステムは、当然完成できません。アジャイルでつくるシステムは、始めはいまいちですが、だんだんと良くなっていきます。つまり、システム完成当初から一定の品質以上の動きをしてもらわないと困るようなシステムの開発には、向いていないのです。そういうシステムは、やはり設計の時点で要求を固める努力が必要になります。

2020年10月のコラムでわたしは、国のシステムは超巨大で一筋縄ではいかない旨を記しています。どの領域でどのような設計思想を採用し、どのようなアプローチで最適化していくのかは、本当に大変な作業だろうと想像します。少なくとも、そうした方針を「トレンド」で選定すれば解決するような話ではないと思います。

デジタル庁は発足当初から、ITスキルの高い外部人材を大々的に募集し、働き方も柔軟に対応できるようにしたことで、多様なスキルを持つ優秀な人材が多く集まってきていると聞きます。それは大変喜ばしいことですが、昔の某プロ野球チームのように4番バッターばかり集まってきてはいないでしょうか。みんなトップ人材、みんなリーダー格、みんなその筋ではスゴイ人、では、船頭多くして船山に上る、ということになります。まあ、わたしにとっては要らぬ心配なのですが。

「クラウドがやられる可能性」を考えているか

投稿日時: 投稿者:

「クラウドファースト」などとして、日本のマスコミはクラウド事業者に情報システムを「すべて」預けることが今の常識だという論調でしきりに語りたがると思っているのは、わたしだけでしょうか。

もちろん、リスクを取ってでもクラウドに完全移行したほうがその企業にとって価値が高いと判断して、そのようにした事例も認められます。納得感のある判断です。ただ個人的な見解ではありますが、そんな目利きをしたようには思えないクラウドシフト事例ははるかに多数あると思っています。マスコミが生み出したそんな後者の企業を、マスコミが多数取り上げる結果、ますます拍車がかかっているように思えてなりません。

実際のところ、目が利くITユーザー企業は、自社管理であるオンプレミスとパブリッククラウドサービスを、うまく使い分けて利用しています。

両方を使い分けるのには、いろいろな理由があります。単にパブリッククラウドに移すのは都合が悪いという理由もあります。個別の都合は様々でしょうが、総合的に考えれば、選択肢がいろいろあるにもかかわらず「クラウド一択」というのは賢い選択とは言えないはずです。だから使い分けるのだろうと思います。

クラウド事業者やベンダーが示す事例はもとより、マスコミが紹介する事例も、有名企業が自社のシステムをすべてクラウドシフトしたなどと大々的に取り扱っていますが、その企業が考え抜いた末にそういう判断をしたのだとしたら、そのリスクについてどう考えたのか詳しく聞いてみたくなります。

クラウドも人が運用するシステムである以上、オンプレと同様に障害は起こりますしシステム停止も発生します。問題なのは、障害が発生した後から復旧するまでのところです。オンプレミスなら自ら手を下して復旧に取り組むことができますが、パブリッククラウドの場合は復旧を待っていることしかできません。

クラウド事業者のほうが技術に長けているから自分で直すよりましだ、という論もあるでしょう。それは否定しませんが、彼らが取り扱っているのは超巨大システムですから、技術力があるエンジニアがあなたの会社の面倒を見てくれるわけではありません。年間何億円も支払っているような、よほどのお得意様企業なら別かもしれませんが、障害が発生して「あなたの会社のシステムは救えませんでした」と言われても、全く不思議ではありません。実際、過去のパブリッククラウドの障害においては、ユーザーのデータがバックアップもろとも消去された事例が複数あります。

あまり論じられることがないように思いますが、パブリッククラウドもITシステムである以上、サイバーセキュリティ攻撃に常にさらされています。いつ何時、脆弱性を突かれて顧客情報に攻撃者の手が届くともわかりません。それはオンプレミスと同じです。クラウド事業者だからリスクゼロということはありません。実際、国内のあるクラウド事業者で、内部の脆弱性を突かれて攻撃者に不正アクセスされてしまったケースが報告されています。

脆弱性を突かれる外部からの攻撃でなくても、クラウド事業者の内部で特権を悪用して利用者のデータに影響を及ぼそうとする事件が起こらないとも言い切れません。内部犯行の脅威もまた、オンプレミスと同じです。もしそのようなことが可能だとしたら、場合によっては全世界の利用者にリーチできてしまうという、前代未聞の漏えい事件になりえることも想像できます。

攻撃や犯行の脅威に限らず、そもそも外国資本の事業者に、自社のデータや資産をすべて預けてしまうのはリスクが高いのではないか、という考え方も、あって当然です。ご承知の通り、いま3大クラウドと呼ばれるクラウド事業者はすべて米国資本の企業です。欧州の企業では当初から、米国資本の企業に完全に委ねるのは危険であるという考えのもと、利用においては重要資産はパブリッククラウドに預けないなどリスク分散させる考え方が根強くあることが知られています。

日本国内でもここ最近、経済安保というキーワードのもとで、行政システムのクラウドシフトに一定の歯止めをかけ、国内の事業者に重要資産を預けるよう義務付けるべきだという意見が出始めました。冷静に考えれば当たり前のことです。これまでそのような話が出なかったのは、政府や行政もまた、トレンドセッターを自任する識者諸氏やマスコミの論調に盲目的に同調していたことの表れなのではないでしょうか。

米国の政府がパブリッククラウド事業者に行政システムをどんどん預けていると知らされて、日本の政府もクラウドシフトの動きを強めたのかもしれませんが、実際の所、米国政府はパブリッククラウド事業者に、政府専用の「物理的領域」を設けさせて、そこに行政システムを置いています。最近そうし始めたのではなく、始めからそうしているのです。要するに、（政府の手が滞りなく及ぶ専用の）データセンターにシステムを預けるという、従来のやり方と実質変わりはありません。

そして、パブリッククラウドのおひざ元ともいえる当の米国内の企業においてさえも、パブリッククラウドに預けたシステムを再びオンプレミスに戻すという揺り戻しの動きが顕著にあることが（米国内では）伝えられています。

言い出せばきりがないことです。また、だからといってクラウドサービスが有用であることを否定するつもりもまったくありません。

クラウド一択の何が結局問題なのかと言えば、パブリッククラウドは利用者自身のコントロールが（特に利用者にとって一番肝心なところで）事実上効かないこと、パブリッククラウド事業者にコントロールの主体があること、なのです。それが、およそすべてのクラウド利用にまつわる利用者側のリスクを生み出しているように思います。

目が利くITユーザー企業はそのことを理解し、何があっても決して自分のコントロールを失ってはならない情報資産を、自分の支配が及ぶ領域に置いておこうとしている、ということです。

マスコミが記事として出すクラウドシフト事例の企業も、実はよくよく聞いてみると、ちゃんとオンプレミスをうまく使って資産保護しているケースが多数あります。要するに、記者が見たい事実にだけ着目して報道しているだけであることが多いのだと、わたしは理解しています。少なくとも、記事の見出しだけ見て鵜呑みにするのはリスクが高いと、心得ておきたいものです。

恐れていた攻撃の手口から考える、経営とクラウド

投稿日時: 投稿者:

昨年のことになりますが、ある大手小売業のECサイトで発覚したクレジットカードの不正利用をきっかけに、その企業を含む11社の小売業者が運営するECサイトから顧客情報が漏えいした可能性が発覚、それぞれ公表されるに至りました。

これらの小売業に共通していたのは、同じITベンダーが提供するECサイト構築SaaS、つまりクラウド事業者のサービスを利用していたことでした。問い合わせを受けて同ITベンダーが調査をした結果、SaaSのサーバーに対する不正アクセスの痕跡、およびサーバーに不正なプログラムが置かれていたことなどを発見したということです。

その後の分析によれば、攻撃者は、SaaSのテナントであったある小売業のECサイトを通じて不正な注文を送り、そのなかに埋め込んだ不正な命令を実行させて、SaaS内部のサーバーを乗っ取ることに成功したようです。それによって、直接攻撃されたその小売業のサイトのみならず、同SaaSを利用していた他のテナントの領域にも不正に侵入する足掛かりを獲得しました。結果、複数の企業の顧客データに不正にアクセスできたといいます。

この攻撃事例を聞いて、これまで恐れてきた事象がとうとう現実になったなと感じました。

パブリッククラウドのサービスは、巨大なシステム基盤上にサービスが構築され、それを多くの顧客が同じ条件のもとに利用する、という形態になっています。優れた機能が使い勝手の良いかたちで準備され、また初期コストのハードルがかなり低いということで、大小問わず多くの企業が利用しています。当然ながら、相乗り型のサービスとはいえ、各テナントの使い方には一定以上の自由度が確保されていますし、データも個別に蓄積できることになっています。

ただし、そうした区分けは、ソフトウェアの制御によって「論理的」に行われています。「論理的」とは「物理的」の反対です。つまり、テナントごとの区画は、戸建て住宅のように物理的に分かれているわけではなく、ソフトウェアに施された「設定」で区分けされている、ということです。

一方で、ソフトウェアには、プログラムの不具合であるバグや脆弱性が「必ず」あります。あらゆる情報システムは、バグや脆弱性は必ずあるけれど見つかってはいない、という状態で運用されているわけです。

クラウドベンダーは、顧客が利用する領域はセキュリティを確保した形で保護されていると謳っています。もし顧客にセキュリティ上の問題が発生するとしたら、それは顧客が行った設定に問題があるのだ、というのが共通した認識になっています。

そこにウソはもちろんないのですが、それはあくまで「ソフトウェアによって」成立していることです。そのソフトウェアに万が一脆弱性やバグがあれば、その保証は崩壊するかもしれません。

それが今回、実際に起こってしまったということだと思います。

注目すべきことは、顧客情報が漏えいしたことよりも、攻撃者がテナントを横断して不正を行うことができた点です。つまり、自社がどれだけ気を付けて対策を実行していたとしても、自分は知らない他の利用者を経由してサービスの大本が乗っ取られ、自社の対策は水泡と化す、というシナリオが成立してしまうということです。

今回攻撃を受けたSaaSベンダーは、決してセキュリティ対策が緩かったわけではなかったといいます。定期的なセキュリティチェックの実践、脆弱性の定期検査の受診、侵入検知サービスの利用など、一定の対策は行っていたようです。それでも今回の攻撃は防御できなかったと主張しています。

また、近年の攻撃は、アプリケーションへの攻撃から基盤ソフトウェアに対する攻撃がより増加している傾向にもあるようです。先にも記した通り、クラウドサービスは複数の利用者が共通の基盤上に構築された機能を、相乗りする形で利用します。その構造上、システム基盤で利用されるソフトウェアは利用者共通です。もし基盤ソフトウェアの脆弱性が攻撃されれば、容易に今回と同様の事象が起こりうることになるわけです。

クラウドサービスを利用するメリットは、その価値によっては非常に大きく、リスクを上回ることもあると思います。避けるよりも、うまく使うほうが賢い選択です。時代もまた、クラウドが使える前提でITを考える時代になっています。

ただし、上記のような攻撃が現実に成功していることを、経営リスクとしてよく理解しておきたいところです。預けているクラウドサービスから自社の情報が漏えいした時に、顧客に謝罪するのは、クラウドベンダーではなくてみなさん自身です。何を預けるのか。どの業務領域を依存するのか。経営にとって重要な選択です。よくわからないからIT専門の人に任せるという話ではないのです。

高度になるIT、問われる組織の能力

投稿日時: 投稿者:

ここ最近は、クラウドにまつわるセキュリティ事故の話が目立っていたように感じました。

例えば、セールスフォース・ドットコム（以下、SFDC）が提供するクラウドサービスを使う複数の企業において、第三者が非公開情報にアクセスできてしまう状態になっていた問題。この問題では、名のとおった大企業、情報セキュリティに関しては高い管理知識を有するはずのIT企業などが、挙って同じ問題に陥ったことを公表しました。

SFDCに関連した問題のほかにも、グーグルが提供するクラウドサービスを利用する企業で内部の業務連絡のやり取りが気付かぬうちにオープンになっていた問題、某キャッシュレス決済事業者における加盟店情報約2007万件の漏えい事件、なども報道されていました。

上記で取り上げた問題に共通する要因は、「設定ミス」です。設定の不備によって、本来公開してはいけない情報が一般公開設定となり、インターネットから閲覧可能な状態となっていた、というわけです。

一般に、クラウドサービスを利用するにあたっては、さまざまな設定を利用者の責任の下で実施することになっています。従って、設定にまつわる障害や事故は利用者側の問題として扱われるのが通例です。

ただし、今回のSFDCの問題は、利用者の対応の甘さに全面的な責任があるとは必ずしも言えない面があるように、わたしは感じます。というのも、設定不備の原因となったのがSFDC側による機能のバージョンアップにあるからです。約5年前に行われた機能追加にその火種があり、その際に、新機能の導入により適切な権限設定をしなければ情報漏えいにつながる可能性が生じたといいます。その旨の情報が利用者に適切に提供されていなかったのではないか、そもそもSFDCはそのような脆弱な設定になり得ることを予測していなかったのではないか、という声が少なからずあるとのことです。

つまり、知らぬ間に外部のアクセスを許す状態になっていたという利用者が大勢いたということであり、それは利用者側の「設定ミス」として片付けられるものなのか、という認識が生まれるわけです。至って自然な考えではないかと思われます。

しかしながらこのような状況を踏まえてもなお、結局は利用者が被害や影響を受ける立場になることに変わりはないのが実情です。クラウドサービスは、提供者側の都合でアップデートや機能追加が頻繁に行われます。それが良さであるという評価も一方ではあります。クラウドを利用するということはつまり、利用者が提供者に振り回される面がある、という理解が必要なのです。

設定ミスは人為的なミスなのだから、使う側が気を付ければよいことではないか、と思うかもしれません。実際に使ってみればわかることですが、クラウドサービスは、使い込もうとするほど、または機能が豊富で高度な要求を実現できるものほど、設定は単純では無くなっていきます。利用者側にも、それなりの「ユーザーレベルの高さ」が要求されるのが実態です。それはある意味、当然のことでもあります。

先日セキュリティの専門家から話を聞きましたが、サイバー攻撃の攻撃者がどのような攻撃手法を好んで選択するのかというと、端的に言えばコストパフォーマンスが高い手法が優先されるといいます。かつては多かった、自らの技術を誇示したい攻撃者というのは近年ではほぼ皆無で、手っ取り早く価値の高い情報を搾取し、お金に変えることを目的にしているのです。そのとき、一番コスパが高い狙い目というのが、実は設定ミスや運用ミスを突くことだと指摘していました。

クラウドは利用のハードルが低く、その気になれば利用の幅をいかようにも広げられる面があります。一昔前なら何千万円と支払わなければ手に入れられなかったような技術を、月数千円程度で利用できるようになっています。技術的に出来ないことは、もはやほとんどありません。これは、ITの急速な技術進化の賜物です。

ただし、利用する側にそれを操れるだけの組織的能力があるのかどうか。利用する企業は常にこの点を、自問自答する必要があります。能力を持たざる企業に高度なITが使いこなせないのは、プリウスに乗っていたドライバーが今日からF1カーを乗りこなそうと思ってもできないのと同じです。

特に中堅中小企業は、ITにかかる組織の整備が脆弱な傾向があります。クラウドをどんどん使おうとするわりにIT担当者は兼務しかいない、でいいのか？経営者の方々には、自社で何らかのITを使おうとするなら、まずは組織能力を問い直すこと、いかに整備を進めるか考えること、をお勧めしたいと思います。そうでなければ、安易な設定ミスにより足元をすくわれるリスクを抱えることになります。

DXの前に、まずアナログからはじめよ

投稿日時: 投稿者:

業務のやり方が固まっていないのなら、DXと言う前に、まずはアナログから始めるのが無難でしょう。

デジタル化を実現するツールやソフトウェアというのは、良くも悪くも「出来上がって」います。いったん使い始めると、そのツールによって仕事のやり方は事実上規定されてしまうところがあります。場合によっては、そうしたツールによって組織に合わないやり方を強制されることもあります。

ツールやソフトウェアの選定が上手くない会社に限って、「ウチには合っていないな」と気付くのは、たいていはそれを使い始めてからです。

情報システムというのはその会社の文化をも決めてしまうもの、と言っても決して大げさではありません。そうした側面があることを念頭に置いて、ツールやソフトウェアの選定は慎重に、かつロジカルに行うべきです。経営者が理解すべきITというのは、技術知識では必ずしもなく、こうした大局的な視点での理解であると考えれば間違いはありません。

アナログとは極端な、と思われるかもしれません。もちろん、アナログのままにしてデジタル化しなくてよい、という意味ではありません。仕事のしかたを固めるために、まずはアナログベースで試行錯誤する、ということを意味しています。

アナログなやり方というのは、大規模化することや複雑な処理をこなすことには向いていません。一方で、小さく取り組むぶんには、むしろアナログのほうが、人間の裁量に任せて自由に試行錯誤ができます。最悪、全部やめて最初からやり直すことも躊躇しなくてよいのです。

どうあるべきなのかをまずアナログベースで追ってみて、自社なりの業務のあり方を固めたところで、デジタルのアイデアや能力を取り入れる。こうした順番のほうが、DXを実現していくにあたっては遠回りなようで確実だろうと思います。

最適な業務のアウトプットを出す方法論というのは、中堅中小企業だけでなく、案外大企業でも部門によっては、考え抜かれていないことがよくあるものです。DXというキーワードを契機にして、今の仕事のやり方そのものを見直すことから始めてはいかがでしょうか。