賢明なCIO：第1話 – 「あなたのLLMは監査に合格できるか？」

ラダ・プラム博士：組織全体の調整と、組織の好みを把握することが必要であり、それは各組織が自ら見極め、構築していかなければならないものです。 そのオーケストレーション層こそが、CIO が検討し始めなければならない、最初の本当に大きな新たな課題だと思います。貴社の AI オペレーティングシステムとは何でしょうか？ そのコントロールプレーンをどこに配置し、特定のニーズに合わせてどのようにカスタマイズするのでしょうか？

ブラッド・ブシック：現在お聴きいただいているのは、Park Place Technologiesがお届けする『The Savvy CIO: Modernize Wisely』です。当社は、ITインフラ管理に費やす時間とコストを削減しつつ、パフォーマンスと稼働率を向上させることで、企業のイノベーションを後押ししています。 司会のブラッド・ブシックです。

「予算が足りないのに、どうやって近代化を進めればいいのだろう？」と自問したことはありませんか？「事業全体を危険にさらすことなく、このイノベーションを成功させることができるのだろうか？」 「何一つとして十分なものが足りない」と感じながら、実際にすべてをこなしている人は、この世に存在するのでしょうか？ もしこれらの質問のどれか一つでも「はい」と答えたなら、この番組はあなたのためのものです。なぜなら、あなただけではないからです。それを証明するために、私は予算の逼迫、 AI、監査、セキュリティ、そしてすべてを台無しにすることなく事業を継続させる術について、実際に毎日これらの問題に取り組んでいる人々と共に語っていきます。

現在、すべてのCIOは「AIへの取り組みを迅速に進めなければ、取り残されてしまう」という同じプレッシャーを感じています。しかし、スピードアップを求める動きの陰には、監査という難関が待ち構えています。 ラダ・プラム博士は、その両面を誰よりも深く理解している。彼女は長年にわたり、米国防総省の最高レベルで勤務した。ペンタゴンの最高デジタル・人工知能責任者を務め、 そこで同省のAI、データ、分析技術の導入を主導し、地球上で最大かつ最も規制の厳しい組織の一つにおいて、デジタル技術の導入と拡大に向けた新たな道筋を切り開いた。 要するに、彼女はデータ、リスク、説明責任について、想像しうるほぼあらゆる角度から考察してきたのです。

現在、IBMの「AIファースト・トランスフォーメーション」担当副社長として、彼女は「クライアント・ゼロ」と呼ぶ取り組みを進めています。これは、AI技術やコンセプトを社内で実用化し、顧客への導入前にテストを行うというものです。 本質的に、IBMは自社の「料理」を試食しているわけであり、そのすべてが彼女の鋭い目と洗練された味覚の下で行われています。今日は、理論上ではなく実践において、AIの導入を実際に監査対応可能な状態にするために何が必要かについて、彼女に話を伺いました。 監査人が何を問うのか、ほとんどの組織が準備できていないこと、そしてスピードとセキュリティのトレードオフが、なぜ現在CIOたちの足を引っ張っている最大の誤解となっているのかについてです。

ラダ・プラム博士、『The Savvy CIO』へようこそ。

ラダ・プラム博士：お招きいただき、本当にありがとうございます。

ブラッド・ブシック：皆さんとお会いできて嬉しいです。今日のこの時間を本当に楽しみにしていました。 まずは、ご自身のことやIBMでの役割、そして、LLMを実際の監査を通過させる方法について、私が次々と質問を浴びせるのに、なぜあなたがまさに最適な相手なのか、少しお話しいただけますか？

ラダ・プラム博士：ええと、 まず、私は本来、経済学を専攻した経済学者なのですが、よく「経済学者なのに、どうしてここにいるの？」と聞かれます。そこで私は冗談めかして、「私はそういう種類の経済学者じゃないんです」と答えるのが好きなんです。 実は、私は応用計量経済学を専門として育ってきました。それは、「ビッグデータ」という言葉が生まれる前から存在していた「ビッグデータ」のようなものでした。ですから、データを保有し、さまざまな用途で活用することの意味について、それが意味のあるものとなるよう、基礎的な観点から考えてきました。 そして、現在AIをめぐる議論の多くは、実際にはデータに関する議論だと考えています。ですから、ここでそのことについて、また実生活でそれがどのような形をとっているかについて話す機会を得られたことを嬉しく思います。正直なところ、 華やかさもなく、特効薬のようなものもありませんが、この分野で前進を遂げるために、コミュニティとして私たちにできることはいくつかあるのです。

ブラッド・ブシック：データに徹底的にこだわるあなたの姿勢が本当に素晴らしいと思います。学界からGoogle、Facebook、そして国防総省、IBMへとキャリアを積んできた経緯を考えると、これは実に興味深いですね。 つまり、その経歴の軌跡を見ると、あなたは同じ根本的な問題を、あらゆる異なる角度から掘り下げてきたように感じられます。大規模で複雑な組織が、責任を持ってリスクを管理しながら、データに基づいて適切な意思決定を行うようにするには、どうすればよいのでしょうか？

ラダ・プラム博士：多くの場合、そのリスクが何であるか、誰がそれを気にかけているのか、そして誰がそのリスクに対処する責任を負うべきなのかを、本当に、本当に明確にすることが重要になります。 ですから、多くの場合、人々は「これはリスクが高い。セキュリティ上のリスクがある、コンプライアンス上のリスクがある、監査可能性のリスクがある」といった理由で、行き詰まったり、立ち止まったり、何かができないと感じてしまうのです。 そこで、その問題を掘り下げ、玉ねぎの皮を剥くように核心まで突き詰めてみると、実際にはどのようなリスクが存在するのでしょうか？　それでは、そのリスクを定義してみましょう。それを軽減するために何ができるのか、あるいはできないのか？ そして、結局のところ、そのリスクの責任は誰が負うことになるのでしょうか？最高法務責任者（CLO）でしょうか？最高セキュリティ責任者（CSO）でしょうか？それとも損益責任者（P&Lオーナー）でしょうか？ そして、「そのリスクはトレードオフに見合うものなのか？」と彼らに尋ねてみてください。多くの場合、リスク軽減策を講じれば見合うものになりますが、あるいは、そのリスクに見合うだけのメリットがない場合も多く、そうして決定を下し、次の課題へと進むことができるのです。 しかし、形のないリスクというこのグレーゾーンこそが、進歩の真の敵であると思います。

ブラッド・ブシック：そして、ガバナンスなしにリスクを許容することはできません。つまり、私にとっては、これはDevOpsの進化を振り返るような感覚です。 業界全体として、スピードと安定性を対立する要素として捉え続けていた時期がありましたが、やがてそれが実際にはシステム設計上の問題であり、ソフトウェア構築に内在する特性の問題ではないと気づいたのです。 これは、現在のAIガバナンスの状況と、適切な類似点と言えるでしょうか？

ラダ・プラム博士：ええ。私はよく冗談めかしてこう言うのですが、私にとって最も適切な例えは、「ブレーキの性能が向上すれば、列車の速度も上がる」というものです。これは列車の進化に由来するもので、もちろん、 直感に反して、より優れた、信頼性の高いブレーキが導入されたことで、停車駅間の走行速度を上げることができたのです。 そして、私はその世界における AI ガバナンスについて考えています。実際、AI ガバナンスは、AI ソリューションが、あなたが望むことを実行し、望まないことは実行していないことを確認するための基本的な要素なのです。 つまり、要はそういうことです。そして実際、それが効果を発揮するためには、それが必要なのです。 つまり、何かを迅速に行うためには、そのガバナンスの手順をプロセスに組み込み、しっかりと定着させる必要があります。そうすることで、この例えをさらに進めると、より堅牢なケーキをより早く完成させることができるのです。

ブラッド・ブシック：ビジネスといえば、それは「人」「プロセス」「テクノロジー」で構成されています。これを枠組みとして、また「すべてのビジネスにAIが必要だ」という点を踏まえ、聴衆の皆さんに背景を説明していきましょう。 LLM（大規模言語モデル）を非常にユニークなものにしている要因の一つは、モデル開発者たちでさえ、いわば「小さなブラックボックス」の中で何が起きているのかを完全には理解していないという点です。 つまり、あなたと私がまったく同じプロンプトを入力しても、まったく異なる回答が生成される可能性があり、その予測不可能性を監査人ほど嫌う人はいないでしょう。 なぜなら、彼らの仕事のすべては、システムがなぜそのような行動をとったのかを検証することにあるからです。そして、LLMが登場したことで、彼らの仕事は信じられないほど困難なものになっています。それでは、この厄介な問題に深く掘り下げていきましょう。 つまり、LLMが、監査人が通常評価に慣れているタイプのシステムと根本的にどのように異なるのか、そしてなぜその違いを理解する必要があるのか、私と聴衆のために説明してください。

ラダ・プラム博士：この「ブラックボックス」を、その「箱」がどこにあるかという観点で細かく分割してみると、理解しやすくなると思います。つまり、その「箱」への入力として、基本的にはデータとコンテキストがあります。 ここで言うデータとは、文字通りデータを指します。これには、財務情報や数値のような構造化データ、契約書の要素のような半構造化データ、あるいは長い文書や画像のような真に非構造化データが含まれます。 そして、これらすべてが、コンテキスト（このデータがビジネスや用途とどのように関連しているか）とともにアルゴリズムに取り込まれます。

私たちは、こうした要素を組み合わせて、決定論的な結果を生み出すことに慣れています。 そこで、ある文脈を取り上げてみましょう。最も単純な例えを使います。スプレッドシートのようなフラットファイル内の大量のデータを取り出し、既知の統計式を適用します。 例えば平均値といった既知の統計式を適用し、それを入力すると平均値が算出されます。これを何度も繰り返して分布を導き出したり、経時的に観察して時系列データを取得したりすることもできます。これらはすべて決定論的な結果です。

LLMがもたらすのは、私たちが知っていることも知らないことも含めた、その膨大なデータと関連性を活用し、 その上に推論の層を重ねることで、私たちが知らない、また予測することさえできなかった情報の組み合わせを生み出し、決定論的な結果ではなく、推論に基づく結果をもたらすことです。 それが「ブラックボックス」であり、いわば「秘伝のタレ」のようなものです。その利点は、これまで実現できなかった、あるいは思いもよらなかったような多くのものを生み出すことです。 その欠点は、その結果に至った正確な要素を完全に把握できないことや、それを常に再現する方法がわからないことです。

ですから、プロセスの中で、「どこに創造的で、新しく、ユニークな要素を取り入れたいか」を真剣に考える必要があると思います。そして、その役割をLLMが担うのです。一方で、「どこに決定論的な結果を求めているか」も考える必要があります。 そこでは、従来の分析手法やMLOps、つまり従来のAI手法を活用できます。すべてをLLMに頼る必要はありません。そして、これらをどのように組み合わせて、 これらを統合して、監査担当者にとって予測可能な結果となる、私が望む出力を生成するコントロールプレーンとはどのようなものでしょうか？必要な場所では生成AIの利点を活かし、必要な場所では決定論的な予測可能性を確保するにはどうすればよいのでしょうか？

ブラッド・ブシック：その視点、とても気に入りました。そして、CIOの立場から考えてみると、この道のりをまだ経験していない人もいれば、すでに経験した人もいるでしょう。 その道のりの初期段階にあり、AI駆動型システムへの移行を目前にしているCIOが、コンプライアンス面で最初に懸念すべき障害は何だと予想されますか？ CIOはどのような点に留意すべきでしょうか？

ラダ・プラム博士：IBMの観点から説明させてください。これは、参考になる例だと思うからです。 データ層があり、データガバナンスと管理が必要です。多くの場合、CIOにとっては、これは最高データ責任者（CDO）の管轄であり、ご存じのデータガバナンスと管理が行われます。 そこで、最初に尋ねられる質問は、「取り込むことができるデータについて、誰がどのデータにアクセスできるかをどのように決定するのか？」「役割ベースのアクセス制御はどのように行われているのか？」「ID および認証情報の管理はどのように行われているのか？」といったものになるでしょう。

そこで、まず第一段階として、例えばIBMの場合、多くの大企業と同様に、ユーザーのIDをその役割やアクセス権と紐付けるシステムがあります。 次に、そのデータをアルゴリズムシステムに取り込む必要があります。それが完了したら、そのデータを調整する何かが必要になります。そのデータは LLM による会話に送られるのでしょうか？ そのデータは、決定論的なポーリングに送られるのでしょうか？ 単にダッシュボードに表示されるだけでしょうか？ それともレポートにまとめられるのでしょうか？ そのコントロールプレーンでは、オーケストレーションと組織の好みを把握しておく必要があります。これは、組織ごとに把握し、構築しなければならないものです。 この点に関しては、企業ごとに状況が異なり、アプリケーションによっても状況は異なります。

例えば、当社は、財務データの調整について、コンテンツに盛り込む必要のあるブランドカラーやブランドグラフィックに関するルールの調整とは、まったく異なる方法で扱っています。どちらも規定によって管理されていますが。 IBM において、87 種類の青色を使用することは不可能です。 しかし、財務システムにおける収益や収益認識の処理とは、その扱いを異にする必要があります。そして、この 2 つの間には多くの要素が存在します。 ですから、このオーケストレーション層こそが、CIO が検討し始めなければならない最初の、そして非常に重要な新たな課題だと思います。貴社の AI オペレーティング・システムとは何でしょうか？ その制御プレーンをどこに配置し、自社の特定のニーズに合わせてどのようにカスタマイズするのでしょうか？

ブラッド・ブシック：そうですね。その表現は実に的を射ていると思います。 そして、監査人の視点から「監査可能性」が実際にどのようなものかを考えると、ご指摘の通り、ロールベースのアクセス制御について明確に説明できること、つまり「この個人がアクセスできるもの、できないものはこれだ」と示すこと、 「この入力があり、この出力があった」といったことを、リズムと順序、そして規律を備えた調整された制御プレーンの中で明確に説明できること――これは、私たち二人が本当によく知っているように、言うは易く行うは難しです。 さまざまな業界で、こうした導入事例を数多く見てこられたわけですが、ほとんどの企業にとって、最大の問題はどこにあるとお考えですか？データでしょうか？モデルでしょうか？それともその中間にあるのでしょうか？ その点について、もう少し詳しく教えてください。

ラダ・プラム博士：おそらく、テクノロジーとプロセスの交差点にあるものだと思います。データとモデルの両方の要素が少し含まれてはいますが、実際には…… 現在、おそらく複雑すぎる、あるいは仕様が不十分なプロセスに、AI の「魔法」を少し加えるだけで、測定可能なビジネス成果が得られるという風潮があると思いますが、実際にはそうではありません。 CIO だけでこの問題を解決することは不可能です。 ですから、真の解決策は、プロセスがどうあるべきか、テクノロジーをどこに統合すべきか、テクノロジーに何をさせるべきか、そしてプロセスをどこで適切に変更すべきかについて、厳しい議論を強制的に行うことだと思います。

具体的な例を挙げましょう。私たちは金融分野において、予算予測と実績を比較するという、非常に一般的な課題に対処するため、このエージェント型ワークフローの開発に取り組んできました。 もちろん、それは可能です。ただし、エージェントについて考え、どの程度の乖離を問題視するかという優先順位についても検討する必要があります。 しかし、無限のケースについて差異の検出を自動化することはできないため、レポートをある程度標準化する必要があります。これは技術的な問題ではありません。 任意の閾値を設定することは可能です。これはプロセスと管理上の問題です。そして、それはビジネス側から提示され、技術と結びつけられる必要があり、その変換が行われる必要があります。 そして、それを予測可能かつ検証可能な形で組み込む必要があります。そうすれば、CFO が「ねえ、なぜこの逸脱に注目して、あちらの逸脱には注目しないの？」と尋ねたときに、 という質問に対して、明確なビジネス上の答えがあり、それを裏付ける具体的な実証が可能な技術的ソリューションが存在するのです。そして、この組み合わせこそが、解決すべき大きな複雑性であると思います。

ブラッド・ブシック：ここには確かに芸術と科学の両面が少しずつあるように感じられますし、人々はデータの管理とモデルそのものの管理を混同しているように思えます。

ラダ・プラム博士：ああ、そうですね。

ブラッド・ブシック：この違いについて、また現在取り組んでいる仕事や率いている活動において、どのように考えていますか？

ラダ・プラム博士：私は、ある意味でこれを「層」として捉えるようにしています。なぜなら、データガバナンスは、ある意味で、あらゆる種類のAIやデジタルソリューションに取り組む前の「関門」となる問題だと考えているからです。 それは、AI モデルを動かす燃料のようなものなので、そのガバナンスの層を正しく構築しなければなりません。 問題は、多くの場合、そこで立ち止まってしまうことだと思います。つまり、データガバナンスも、メタデータも、ロールベースのアクセス制御も、権威あるシステムも整ったところで、「よし、これで完璧だ。 さあ、これを AI に投入しよう」という状態になるのです。そして、ここで考え抜かなければなりません。「このシステムにデータを提供したら、何が起こるのか？どのようなモデルガバナンスが必要なのか？ モデルが何を行っているか、どのデータにアクセスしているか、データの鮮度、時間の経過に伴うモデルのパフォーマンス、特定のバイアスが認められるかどうかなど、何を確認できるようにする必要があるのでしょうか？ 分析ソリューション、たとえば決定論的ソリューションで通常テストするすべての項目を、再び取り入れる必要があります。

しかし、私たちが抱えている問題は、こうした種類のモデルに対して、同様の既知のテストが存在しないことです。そこで私たちが注力しようとしているのは、透明性の側面、つまりモデルが何を行っているのか、 どのようなデータにアクセスしているのか、いつ推論を行っているのかといった点を把握し、推論プロセスの各ステップに透明性を持たせ、それを活用して、潜在的な逸脱や結果がどこから生じているのかを特定しようとしています。 うまくいけば、時間の経過とともに、より優れた評価ツールも手に入るでしょう。業界では、そうしたツールの開発が続けられています。 しかし、現在のところ、私たちが慣れ親しんでいるような、正確性や精度をテストするための、確立された既知の方法がまだ存在しないことが、まさに複雑さの要因であると思います。

ブラッド・ブシック：その指摘はまさに的を射ていると思います。つまり、規制環境がまだ策定中の状況下で、まるで飛行機を組み立てながら同時に操縦しているような感覚があるのです。 これまで関わってきたすべての組織を俯瞰してみると、もし監査人がやって来て、今日あなたが関わったCIOたちのほとんどと隣り合わせで座ったとしたら、 監査人が「では、御社のLLMには何が流入・流出しているのか、また、どのようにガバナンスが行われているのか教えてください」と尋ねたとき、組織側は実際に即座に答えられる準備ができていると思いますか？

ラダ・プラム博士：面白いことに、ちょうど先日、ある大手銀行の最高投資責任者（CIO）と話をしていたのですが、その方は「基本的に、この理由から、投資判断の多くにAIを導入していない」と言っていました。 「入ってくるデータや出ていくデータを裏付けできないような意思決定は、行うことはできない」と。

私たちにできることとできないことがあります。これは、監査人や規制当局と協力して、合理的な妥協点を見出さなければならない良い例だと思います。 私たちにできること、そして誰もがすべきことは、規制の厳しい意思決定については、「この意思決定を行うためにモデルが使用できるデータは、この限定されたセットのみである」と明言することです。 そして、それが規制当局にとって素晴らしい出発点になると思います。 次にすべきことは、ツールを活用することだと思います。IBM には「Watsonx Governance」というツールがありますが、モデルの動作状況を実際に把握できるガバナンス・ツールは他にも数多くあります。 つまり、モデルはどこで推論を行っているのか？ どのように動作しているのか？ こうした透明性は、規制当局にとって非常に重要になるでしょう。

そして、最後のポイントは、エージェント型ソリューションを重ねて導入したときです…… エージェントとは何かを考えると、それは、基本的に自然言語処理を用いて処理される膨大なデータセットから得られる一連のシグナルに接続されたRPAです。 したがって、その一連のアクションはデータと結びつけられる必要があります。「これが実行されるアクションの一連の流れです。これが、それらのアクションがトリガーされる閾値です」と、透明性を持って説明できるべきです。 そうすれば、監査人にとっては、モデルがそれらの閾値に達するようにデータを変換する極めて詳細な方法以外のすべての情報が提供されることになります。そして、すべてではありませんが、ほとんどの 規制対象業界のほとんど（すべてではありませんが）において、監査人との話し合いを乗り切ることができるでしょう。

ただ、現時点では、これらのLLMシステムにうまく組み込む方法がないものがいくつかあるという点には留意しておく価値があります。その一部は、変えられないことを受け入れることでもあります。 つまり、実現可能なこともあれば、業務の効率化に役立てることもできるでしょうが、最終的には人間が関与し、が、法的要件に基づいて内容を確認し、決定を下す必要があり、これもまた、現時点ではテクノロジーだけで解決しようとすべきではない課題の一つです。

ブラッド・ブシック：現時点では、セキュリティとスピードは、ほとんどの組織においてシーソーの両端のように扱われているというのが、おおむね定説となっています。スピードが上がればセキュリティは下がり、セキュリティが上がればプロセスの速度が低下してしまうというわけです。 この「スピードとセキュリティ」に関する考え方は、AIにも実際に当てはまると思いますか？それとも、実際には両立させることができるのでしょうか？

ラダ・プラム博士：私は、その両方が必要だと考えています。ですから、セキュリティが議論のどの段階で取り上げられるかという観点から、考え方を一変させる必要があるのです。 そのため、IBM 社内では（国防総省でも同様でしたが）、セキュリティ・バイ・デザインを実践することに重点を置いています。 私が新しい AI ツールについて最初に話し合う相手は、当社の CISO です。私は 1 日に何度も彼と話をしており、彼のチームのメンバーのほぼ全員の名前を知っています。これは偶然ではありません。 なぜなら、彼らが必要とするセキュリティルールや知見を正しく把握できなければ、導入はできないからです。

そして、早い段階からそうした話し合いを始めることで、自社開発か外部調達かの判断、彼らが尋ねるべき質問、テストしたい連携機能などが分かるようになります。 私はフロントエンドでそれを把握しており、迅速な回答を得て、このプロジェクトが成功するか失敗するかを素早く見極めることができます。 つまり、最終的には、コンプライアンスを満たし、拡張性もあるとわかっている結果にたどり着くのです。そして、その「セキュリティ・バイ・デザイン」こそが、スピードとセキュリティのバランスを保つことを可能にしているのだと思います。 いや、「バランスをとる」という表現は適切ではないかもしれません。「セキュリティ・バイ・デザイン」というフライホイールが生まれ、それがコンプライアンスに準拠した成果を生み、迅速な導入を可能にし、さらに「セキュリティ・バイ・デザイン」を推進できる、という好循環が生まれるのです。そのフライホイールによって、はるかに速いスピードで前進できるのです。

ブラッド・ブシック：セキュリティチーム全員の名前を把握しているというあなたの説明、とても素晴らしいと思います。リスナーの皆さんにとっては、これは本当に馴染みのない概念だと思います。場合によっては、CISOはチームと「協力する」のではなく、「対立する」存在として扱われてしまうこともあります。 それにもかかわらず、あなたの話から私が感じ取るのは、イニシアチブや機能の導入の「最後」ではなく「最初」の段階でセキュリティチームやリスク管理チームを巻き込むことの、極めて重要な意義、そしておそらくは競争上の優位性についてです。 私たちが直面しているこの新しい状況を踏まえると、なぜそれが今日ではそれほど稀なことになっているとお考えですか？

ラダ・プラム博士：多くの場合、人々はソリューションを迅速に導入したいと考えており、その活用によって十分なビジネス価値を証明できれば、セキュリティチームも納得してくれるだろうと考えています。 そして、多くの場合、それは冒頭で話していたリスクに関する議論を余儀なくさせ、「 「この大きなリスクを軽減するには多額のコストがかかりますが、一方でこれだけの大きなビジネス価値もあります。P&L責任者とCISOの皆さん、どちらのリスクを引き受けたいですか？」 というものです。その方法も確かにあり、これで問題を解決することもできますが、時間がかかり、リスクや拒否反応を招くことになります。

私たちは、むしろ最初の段階で、「これをどこで活用できるか？」「どのように活用したいか？」「どのようなデータを使うのか？」「どのようなリスクが生じるのか？」といった、より小規模な議論を意図的に促す方がはるかに効果的だと気づきました。 また、CISOとは、MVPの構築や初期テスト、統合テストを進める中で行われる、数多くの段階的なリスク軽減策や調整について協議します。 「自社開発か外部調達か」という判断に応じて、その過程でこれらすべてを行うことができます。つまり、最終的な決定は、「ねえ、ここには軽減できないリスクがいくつかあるね。 しかし、ビジネス上の価値を考えると、それほど大きなリスクではないと考えています。進めましょう。」というものです。誰もがその決定に非常に満足しています。 しかし、そのためにはチームとの事前の作業がはるかに多く必要となり、人々は、そのプロセス全体を「左側」に移すという決断をまだ頭の中で下していないのです。これは設計上の機能であり、コンプライアンスチェックではありません。

ブラッド・ブシック：うん。 その考え、大好きです。それが設計上の特徴であるという見方はまさにその通りです。これは新しい考え方だと思いますし、特に、私たちが実際にどのように計画を立てたいかについてこれまで深く考えたことがない人にとっては、馴染みのない概念だと思います。 ちなみに、AI プラットフォームがあるなら、それをどう活用するかという議論に、いきなり突き落とされてしまったケースもあるのです。 つまり、10年前にはAIを備えていなかったプラットフォームを現在運用している世界中のCIOたちを想像してみてください。 ビッグデータはあったものの、10年前にはAIはなかったプラットフォームを運用しており、今では毎晩起動するエージェント機能を備えたプラットフォームを実際に運用している状況を考えれば、彼らに対して、明日から何を変えるべきだと伝えますか？

ラダ・プラム博士：面白いことに、これは技術的な話であるべきだと思われるかもしれませんが、私は完全にプロセスに関する話をしようと思います。 私が皆さんのCIOにアドバイスしたいのは、ワークフローと、それが社内でどのように機能しているかを理解することです。 ここでも IBM を例に挙げますが、ペンタゴンでもまったく同じことを行いました。つまり、ビジネスを 10 の大きなエンドエンド・トゥ・エンドのエンタープライズ・ワークフローに分解し、その中にアクティビティ・セットを設定しました。これが、エージェントを展開する際の私たちの考え方です。しかし、そのようなカタログがあれば、新しい機能や新しい能力が見つかるとすぐに、 それらを、適用される対象や適用方法に応じて、非常に迅速に機会セットにマッピングし、関連するチームを結集させて、部門横断的なチームを編成し、新技術の導入と展開を進めることができます。

しかし、テクノロジーに関連した、こうした初期段階の退屈なプロセス作業がなければ、「これが営業プロセスの各段階であり、これらがSales Cloudとこのように連携している」と把握することはできません。 さて、Sales Cloud に新たにリリースされた新機能や、提携して導入したばかりの新しいアプリがあるとして、 それらがどこに配置されるのか正確に把握しておくべきですし、誰に電話してこう言えばいいのかも知っておくべきです。 「ねえ、チームを組んでこれを検討し、30日間の簡易テストを行って、実際に生産性が向上するかどうかを確認し、それを繰り返していこう」 そして、それが私たちが採用してきたアプローチです。その初期投資は面倒ですが、そのおかげで迅速な導入が可能になるのです。

ブラッド・ブシック：さて、今日のリスナーの皆さんは、両手が空いていたことを願っていますね。だって、あなたは本当に貴重な情報を次々と教えてくれましたから。『The Savvy CIO』にご出演いただき、ラダさん、本当にありがとうございました。

ラダ・プラム博士：お招きいただき、ありがとうございます。

ブラッド・ブシック：今日のプランブ博士との対談は、とても素晴らしかったです。特に印象に残った点がいくつかありました。 一つは、セキュリティ対策を早期かつ頻繁に導入することが、導入の成否を分ける要因になりがちだということです。そして、彼女が「セキュリティ担当者の名前は全員、ファーストネームで知っています」と語った点も、とても印象的でした。 ペンタゴンのような大規模な組織で、これを想像してみてください。率直に言って、物事を前進させるためには、実際にそのような関係がほぼ不可欠なのです。 今日この話を聴いている多くの CIO は、問題が発生するまでは誰も気にも留めないような事柄について、CISO やセキュリティチームに依存しています。

プラム博士がワークフローの理解の重要性を指摘された点は、まさに核心を突いていると思います。ワークフローが確立されていないと、ただAIを何かに適用して、何か素晴らしいことが起こることを期待するだけになってしまいますが、ご存知の通り、ビジネスは「期待」だけで成り立つものではありません。 ですから、時間をかけて体系的なアプローチを取り、ワークフローを文書化し、それを理解しておくことで、監査の際にワークフローとテクノロジーを結びつけることができるようになることこそが、成功へのより良い道筋だと私は考えます。

今日はこれで終わりです。お聴きいただき、ありがとうございました。エピソードを見逃さないよう、ぜひフォローをお願いします。こちらは、Park Place Technologiesがお届けする『The Savvy CIO』でした。 Park Place について詳しく知りたい方は、www.parkplacetechnologies.com をご覧ください。それでは、ゲストから最後のメッセージをお届けします。 ラダさん、この番組は『The Savvy CIO』というタイトルですが、これまでのキャリアの中で、あなたが下した最も賢明な選択は何ですか？

ラダ・プラム博士：エンタープライズAIの解明に全力を注ぐと決めたことだと思います。 今後5年から10年の間、人々はそこに注力し、社会のあらゆる側面を真に変革していくことになると思います。その物語の一翼を担えることは、本当にワクワクするものです。

ブラッド・ブシック：その見解、本当に素晴らしいと思います。私も全く同感です。司会のブラッド・ブシックです。そして、いつものように、ITは単なる「一席」に留まるべきではありません。ITこそが「その席」そのものなのです。それでは、お元気で。