FS-ISACのポッドキャスト「FinCyber Today」へようこそ。FS-ISACのChief Corporate Affairs Officer Elizabeth Heathfieldです。生成AIは先進的な素晴らしい技術から経済上不可欠なものになりつつあります。企業や各部門は、AIについて考えるだけでなく、AIのように考えることも求められています。今回は、AkamaiのSVP兼CTOであるPatrick Sullivan氏と、非決定的―つまり「出力が一定ではない」AIツールの特性をセキュリティチームがどう活かせるかについて熱論を交わしました。お越しいただきありがとうございます。この話ができるのはとても楽しみです。お互いAIオタクですからね。今回のテーマは、非決定的リスクの管理です。その前提と基本を整理しましょうか。生成AIモデルにおける非決定性とは何でしょうか?いい質問ですね。まずは基本的な認識を持つことが大事です。我々が期待を寄せている生成AIモデルは、その中核で複雑な行列計算を大量に行い、次に来る単語として最も確率の高い候補を選びます。ただ、設定次第では最有力候補だけでなく確率がやや低い候補を選ぶこともあります。ただ、それが何を意味するのか、なぜそれを非決定的と呼ぶかというと、ある入力セットで(行列計算を)実行したとして、そのモデルが完全に静的でシステムに変更がなかったとしても、次に実行したときには、別の結果が返されます。さらにもう一度実行すると、また違う結果になります。ある意味、これは我々が従来使ってきた多くのシステムとは異なります。ですから、特にセキュリティテストのような場面では、我々が発想を転換する必要があります。プロンプトインジェクションの潜在的なペイロードが一度発動しなかったとしても、脆弱でないことが保証されるわけではありません。なぜなら、次に同じペイロードをまったく同じアプリに試すと、今度は発動してしまい、好ましくない結果になることがあるからです。だからこそ、皆がその点をしっかり理解することが大切だと思います。さらに私は、頭で理解するだけでは不十分だと考えています。実際の動作を見るべきです。自らキーボードを打ち、画面を見ながら、ペイロードが最初は発動しなくても、まったく同じ条件でもう一度試すと今度は影響が出ることを実際に確かめる必要があります。そうすることで、テストの結果の意味を自分で理解し、セキュリティへの予期せぬ影響を把握できます。
では、こうした非決定性をどう理解し、どう扱えばよいのでしょうか?特に企業レベルではいかがでしょうか。ここで大事なのは、単なるチャットボットの話ではなく、より複雑なワークフローや、エージェント型のワークフローなどを想定している点ですね。そのとおりです。よい点としては、今の(FS-ISAC)加盟組織のどのセキュリティチームにも豊富な学習機会を積極的に活用している優秀な人材がきっといるはずです。そのような方々は、この分野で先を進んでいます。ですから、リーダーの皆さんが注力すべきなのはベースラインです。どのようにそのベースラインを引き上げ、セキュリティコンプライアンスを遵守する組織全体で明確に理解できるようにするかが重要です。監査からレッドチーム、さらにAppSecチームまでのすべてが対象になります。なかには、基礎的な研修では物足りないと感じる方もいるでしょう。それでも、ベースラインを設けることは大切だと思います。ワークショップやAIワークショップ、AIハッカソンを開催するのもよいでしょう。そうすれば、皆が気軽に実際に手を動かして、何がどうなるのかを体験できます。百聞は一見に如かずを体験することが重要です。
そして、監査の担当者も次のようなことを考える必要があります。保証されているとはどういう意味か?テスト結果が問題なかったというだけで、より広い視点ではどうか?静的なシステムでも、次にもう一度試せば、今度は問題ありになるかもしれません。全員が同じ認識を持つことが大切です。なるほど。これで基本事項は確認できました。それでは次に、金融業界が活用できるチャンスについてお伺いしたいと思います。特に、生成AIのこの新たな特性がもたらすチャンスとは何でしょうか。そうですね。AI技術の導入速度は企業によって差がありますよね。経営陣の中にはこのように話す方もいます。「当社は体制の整った組織だがAIの好機を、機動力のあるスタートアップや金融テクノロジー企業に独占させるつもりはない。当社もこの機会を生かすつもりだ」そうしたリスクを取る姿勢はすばらしいことです。ただ、実際に企業がこうしたAIツールを初めて導入するとしたらCopilotの開発支援などになるでしょう。現場ではすでに成果が出始めています。開発者の生産性が上がっているのです。先週、パートナー企業Apiiroの調査結果を読みましたが、生成AIのCopilotで開発するとPR単位ではソフトウェア更新件数が4倍に増えるとのことでした。さらに、稼働している各種ASTツール全体で見ると平均で10倍に増える可能性もあります。重複が多いものの、全体として開発速度は上がります。それは企業にとって好ましいことです。ただ、セキュリティチーム、特にAppSecが自動化を進めなければ、他の企業に先を越されてしまいます。これが1つのチャンスです。もう1つのチャンスは、見落としを減らせることです。今は優れたツールが多く、大量のアラートが出力されています。実際、侵害報告を読むと重大事故の際も何らかの警告は出ています。こちらのツールでも反応があり、あちらのツールでも反応があった。ただ、それらは人間の担当者に重大と判断される水準のものではなかったのです。より広い範囲をカバーできるようになりAIシステムがその一部を実行できれば、精査にかける基準を下げられる可能性があります。それは我々にとっても1つのチャンスであると言えるでしょう。
ここまでは、チャンスについて話していただきました。次は、リスクについて伺います。生成AIの導入に伴い、企業が直面しているリスクとは、また、その結果、従来とは少し違う形でリスク管理を考える必要性が出てきているのか?また、生成AIの導入に伴うリスクとは?といったことを教えてください。はい。1つはAppSecの領域です。私自身、AppSecのリスク対応に20年ほど携わってきました。AppSecで問題が起きるときのアンチパターンの1つは、コードや命令をデータと混在させてしまうことです。本来は、データと命令を分けておくべきです。SQLの命令は、データベース側で実行されます。それが1つの問題です。さらに、OSの命令が解釈されると、また別のリスクが生じます。ほかにも、生成AIアプリケーションを使用して、命令とデータをまぜこぜにしてミックスしたカクテルのように扱っているケースも見られます。これは問題があります。このモデルでは「危険な3つの条件」が揃ってしまいます。外部データがある場合、ユーザーのクエリーでも、取り込んだ学習データでも、内部データであっても、RAGなどのシステムを使用して機密情報にアクセスするケースもあります。本来、機密情報は厳格なルールの下で管理し、アクセス権の所有者も厳しく制御されています。3つ目の条件は通信チャネルです。APIの直接接続はかなり危険なケースであると言えます。それ以外にも、メールやソフトウェアの制御機能、公開リポジトリやSlackなど、さまざまな通信チャネルがあります。「危険な3つの条件」が揃ったとき、高確率で何らかのリスクが生じると考えるべきです。その場合は、非常に強力な対策でリスクを抑える必要があります。3つの条件を2つに抑えられれば、条件がすべて揃った場合よりも大幅にリスクを減らせるでしょう。それはつまり、企業が使っている最先端モデルベースのツールの話ですか?そのツールが、ミックスした状態にあると?その可能性はあります。最先端モデルは外部データを出力します。つまり最初から、攻撃者に操作される可能性のある、さまざまな外部データを扱うことになります。内部構造を理解していれば、生成した入力によって挙動を誘導することも可能です。そこに他の要素が加われば、リスクはさらに高まります。それが今、我々が直面しているリスクの一端です。一見正しく見えるのに、実は誤っている。そのリスクをどう管理すべきでしょうか?どう制御すればよいのでしょうか?私たちはかつて、オンかオフか、白か黒かという世界にいましたよね。しかし現在、モデルの出力は一見もっともらしく、筋が通っているように見えます。複数のモデルを使うべきなのでしょうか?それをどうやって判断して検証すべきなのでしょう?難しい問題ですね。こうしたシステムは、多くの場合は正しく、ときに間違います。しかし、常に自信満々です。対策はいくつかあります。1つは、別のモデルで出力を監視する方法です。過去の回答との違いをチェックします。別の方法として、重要度の高い用途では「まだ人間が介在する必要がある」と判断する組織もあります。人間を安全装置として残すのです。もっとも、セキュリティの世界では人間が最も脆弱な部分だとよく言われます。そう考えると人間に頼るのは少し皮肉でもあります。とはいえ、それも補完的な対策です。いずれにしても、今の成熟段階では、非常に自信に満ちた明らかな誤答が返されることがあります。そこを常に念頭に置くべきです。それでは、「失敗をどう定義するか」という観点から考えてみたいと思います。評価手法はいろいろあります。AIがAIをチェックする仕組みを作ろうとする動きも広がっています。一方で、人を介在させる方法もあります。ただ場合によっては、AIを導入し、その結果を人が検証することで、かえって、最初から人がやった方が早かったとなることもあり得ます。しかも、高価な新システムを導入しているのに、です。評価や検証の方法には自動化されるものもあれば人が行うものもあります。しかし同時に、多くの規制要件もあります。GRC、つまりガバナンスやリスク管理、コンプライアンスへの対応も必要です。こうした要件を守りながら、この状況にどう対応していくべきか。すべてが整理されるまでには、時間もかかるでしょう。それらをどのように考えるべきでしょうか?おっしゃる通り、この分野の技術革新の速度は驚異的です。私のキャリアの中でもこれほど進化の速い分野は見たことがありません。一方で、規制の整備には一定の時間が必要です。このギャップに向き合うGRC担当者のご苦労はよく分かります。ただ同時に、多くの強力な規制は基本原則に基づいています。そうした原則の多くは、この分野にもそのまま適用できます。まず基本的なこととしてこれらの技術がどこで使われているのかを正確に把握し、資産管理できていますか?先ほど、決定的か非決定的かという話をしました。重要なのは、モデルを把握し、管理権限があれば、挙動を調整できる点です。たとえば、温度パラメータを0に設定すれば、出力を決定的にできます。ここはセキュリティ部門やコンプライアンス部門が、企業側に働きかけられるポイントです。非決定性を必要としない用途もありますよね。たとえば法務や経理など比較的定型的な業務では、高い創造性は不要です。むしろエージェントの挙動は予測可能である方が望ましい場合もあります。一方で、幅広い出力のばらつきがあるからこそ人間が創造的だと感じる結果が得られるという考え方もあります。しかし本当にその非決定的なふるまいが必要なのかという点はきちんと検証し、必要なら正当な根拠を示すべきです。なるほど。つまり、できるだけ決定的にしようということですね。1つの方法として聞いたことがあるのは、タスクを細分化し、サブエージェントごとに役割を限定する方法です。そうすれば、障害発生時の原因追跡が容易になります。一方で、1つのワークフローに大量の工程を詰め込むとどこで問題が生じたのか特定が難しくなります。ですからタスクをできるだけ細かく分ければ、全体は自動化されたままでも、より「決定的」に近づけるということですね。まさにその通りです。それも良い例ですね。ここでもまたセキュリティやコンプライアンスの厳しいチェックが入ることで、より良い結果が得られます。つまり職務分掌のような考え方ですが、それをここでも取り入れています。我々には、非常に強固な基本原則という基盤があり、その枠組みの中で運用できるという強みがあります。場合によってはこれらのシステムを特別なものと扱わず、従来どおりの精査を課すことが有効でしょう。
一方で、脅威アクターはこの非決定的な性質を利用して、非常に日和見的に動いています。大量に試して、いわば「数打てば当たる」で、我々が想定しない創造的な結果が出ることを期待しています。ここにはある種の加減があるのですが我々もあまり決定的にしたくはありません。制限してしまえば、脅威アクターにとって有利になる可能性もある。そう思われますか?この先を考えるのであれば、そうですね。さきほどのAppSecの例に戻りますが、これまで私たちは、人が使うことを前提にAPIやアプリケーションを設計してきました。多くは検索機能を通じて利用するものでした。しかし今後は、エージェントやチャットボットにデータを供給するために、APIやWebアプリを開発していく可能性があります。たとえば、ある条件のもとでどの金融機関が自分に最適かを判断するとします。そうした判断も、エージェントやチャットボットの中で行われるかもしれません。そのとき、学習に関わるボットへの情報提供の方法や、エージェントに対する応答の設計は、現在の一般的なWeb訪問者への対応とは異なる扱いが必要になるかもしれません。これは、その技術の背後に正当な顧客が存在するいわば望ましいケースです。当然ながら、なりすましや、これらのツールを悪意ある目的で利用する者も現れます。今後は、さらなる自動化や、より多くのボットがサイトにアクセスする状況に加え、委任されたアイデンティティにも対応する必要があります。本人は正当な利用者でありながら、エージェントに代理で操作させたい。そうした動きはすでに始まっています。ただし、まだ、ほんの初期段階です。これはIAMや認可を担当するチームにとって大きな課題になります。取り組むべき課題はたくさんあります。そうですね。これは先ほどのパネルでも話題になりましたね。サードパーティやサプライチェーンリスク、さらにはnthパーティリスクという、新しい次元の問題です。エージェントがエージェントとやり取りし、取引先のエージェントがさらに別のエージェントとつながっていく。しかも、その中身はほとんど見えません。いわば、ブラックボックスの中にまたブラックボックスがあるような状態です。この状況を、私たちはどう捉えるべきでしょうか?サプライチェーンリスクの管理は、以前からの課題でした。そこにさらに、可視性の低い新たな層が加わっているのです。この点について、どう考えるべきでしょうか?目の前の課題はクライアント側にあります。誰かがエージェントを使っている場合、それを正しく識別して、適切に扱い、認可対象となる委任されたアイデンティティであるかを検証すること。それが最初のステップです。一方で、我々のバックエンドではサードパーティを利用しています。それがさらに、別の事業者のサービスを呼び出しています。これが現在のサプライチェーンリスクの管理方法です。今年初め、(FS-ISACの)ある加盟企業が、Pat Opet氏によるSaaS事業者宛ての公開書簡で、現在のエコシステム上のいくつかのギャップを明確に指摘しました。解決策の一端は、SaaS事業者が下流プロセスに関する透明性を高めることにあるでしょう。実際、攻撃者はその必要性を浮き彫りにしています。非常に先見性のある書簡でした。
これまで主にLLMを取り上げてきました。生成AIといえば、一般的にはまずそれを思い浮かべますよね。しかし最近では、小規模言語モデルの潜在的な力もよく議題にのぼります。特に用途が非常に限定されている場合は、巨大モデルを使う必要はなく、より小さなモデルで十分かもしれません。こうしたモデルは、非決定性に伴うリスクを管理するうえでの1つの道になり得るでしょうか?そう思います。ここもまた、セキュリティが企業側に問いを投げかける場面です。本当にフル機能のLLMが必要ですか?それに伴うリスクまで、受け入れる必要がありますか?LLMに対する脅威モデリングはとてつもなく難しいものです。たとえば、金融アプリに対して「大量破壊兵器の作り方を質問できるようにするか」まで考える必要があります。学習データによっては、それも脅威モデルに含める必要があります。我々が話してきたように、セキュリティチームは企業に問いかけます。本当に非決定的なモデルが必要なのか?このケースでは、決定的なモデルで十分ではないのか?と。それは設定管理の範囲の話でもあります。本当にLLMが必要なのか?それともこの用途はSLMで十分なのではないか?そうした検討も、セキュリティが企業に働きかけ、より望ましい結果へ導く事例の1つでしょう。実際に、この問いを自らに投げかける組織が増えています。これは前向きな進化だと感じています。モデルそのものに加え、温度パラメータの話もありました。さらに、コンテキストの制御もありますね。コンテキストを延々と続ければいいというものでもありませんね。それでは出力の質が下がりますし、出力が増えれば入力も増えコストも上がります。ですから、そこを少し制限することもできます。それに、プロンプトもあります。それをもっと予測可能にする方法もありますよね。プロンプトテンプレートや、プロンプトライブラリなどの方法があります。それらをより予測可能なものにすれば入力自体がより統制されたものになります。つまり、こうした複数の側面から非決定性を管理できるのではないでしょうか?私が感じているのはこうしたさまざまな側面があることを従業員に教育する必要があるということです。ツールを理解してもらうためです。これは単一の要素による問題ではありません。どう思われますか?まったく同感です。過去を振り返ると、新しいトレンドに進むたびに、残念ながら、セキュリティ面での負の側面を経験してきました。Eコマースが始まった時にはSQLインジェクションの大きな波がありました。Webアプリケーションからデータベース全体が流出した事件もありました。そこから我々は学び、アプリケーションへの入力をより適切に検査するようになりました。その後クラウドへ移行した際も、同じようなパターンが生じました。今回の流れにおいて期待するのは、バックエンドの機密データに接続したWebアプリを導入したときの教訓やクラウド導入時に学んだ教訓を活かせないかということです。ある組織が大きな被害を受け、他社がそこから学ぶ、という形を取らずに、過去の経験から学べないものでしょうか?そうであってほしいです。深刻な侵害が起きる前に、リスクを少しでも減らせればと思います。
さて、かなり幅広く話してきました。この対談から、1つだけ要点をあげるとすれば、何でしょうか?そうですね。興味深いポイントはたくさんありました。鍵となるのは、情報セキュリティチームが基礎をしっかりと理解することだと思います。まずはAIについて、共通の基礎レベルのトレーニングを確立することです。できれば、ワークショップやハッカソンのように実践的な環境が望ましいですね。我々には、多くの基本原則があります。理解が進めば、それをどこに適用すべきかが見えてきます。これが最も重要だと思います。
