※本記事は、Hart Rossman氏(AWS Security担当VP)とNiamh Gallagher氏(AWS Ireland Country Lead、EMEA Director, Infrastructure Public Policy)による対談「Building Security at Speed」の内容を基に作成されています。本セッションは、2026年3月12日にアイルランド・キルケニーのLyrath Convention Centreで開催された第5回AWS AI and Data Conference 2026において収録されました。AWSのイベントに関する詳細情報は https://go.aws/events でご覧いただけます。本記事では、対談の内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。
1. オープニング:ファッションとセキュリティ文化への導入
1.1 グリーンのスパンコールジャケットのエピソードと「誰も取り残さない」文化づくりの発想
モデレーター： 本日はまばゆいライトのせいで会場がほとんど見えないほどで、まるでセレブリティになった気分です。ただ、この明るさは本日最初のファイヤーサイドにふさわしいものだと思います。今朝の基調講演を拝見して、そこで触れていただいたテーマについてもう少し深掘りできる素晴らしい機会だと感じていますし、より非公式でファイヤーサイドらしい対話ができればと思っています。始める前に、本日の対話でどのような話題を扱うかを会場の皆さんと共有しておきます。まずセキュリティの文化と文化としてのセキュリティについて、そしてガーディアンを通じたスケーリングについて取り上げます。もちろんファイヤーサイドである以上、AIについての議論も欠かせませんので、AIに関する質問もいくつか用意しています。そして最後に、最新のテクノロジーにどうキャッチアップしていくかについても話したいと思います。ただ、その前に会場の皆さんが私と同じように気になっているであろう質問からお聞きしたいのですが、そのジャケットです。スパンコールとグリーンという組み合わせがとても素敵なのですが、なぜこの装いを選ばれたのか教えていただけますか。
Hart： 実はこの話には少し背景があります。私がAmazonに入社したのは個人貢献者としてで、初期の頃にAWSでグローバルなセキュリティ組織を立ち上げるためのビジネスケース、いわゆる「ワーキングバックワーズ」ドキュメントを作成する機会がありました。人を採用し始めた際に、どうすれば正しいカルチャーを築けるか、正しいエスプリ・ド・コーを築けるかを考えていました。そこで気づいたのは、私たちが企業の中で関係構築のために行うことの多くが、実は人を疎外してしまうことがあるということです。例えば食事に行っても食事制限がある人がいたり、スポーツをしようとしても自分の体型に自信が持てない人がいたりします。しかし私たちの業界では、誰もが仕事に来るときに服を着なければなりません。そこで私は、人々にファッション上のリスクを取ってもらえるのではないかと考えました。普段ショートパンツとTシャツを着ている人にはスーツとネクタイを着せることができるでしょうし、逆にスーツとネクタイに慣れている人にはショートパンツとTシャツを着せることができるはずだと。
1.2 「セキュリティの文化」と「文化としてのセキュリティ」の違い、顧客中心主義との結びつき
Hart： そうしてセキュリティチームをAWSで最もファッションフォワードなチームにしようと決意し、今日に至ります。今日はアイルランドにちなんで少しグリーンを取り入れてみました。
モデレーター： 素晴らしいですね。それで実際に効果はあったのでしょうか。もし皆さんのフロアにお邪魔したら、そうした雰囲気が感じられるのでしょうか。
Hart： はい、感じていただけると思います。セキュリティ専門家によくある伝統的なユニフォーム、つまり黒いジーンズや黒いパーカーといった格好はそこでは見られません。代わりに、自分自身を表現し、そこにいることにワクワクしていて、セキュリティという観点からも親しみやすい人たちを見つけていただけるはずです。正しいセキュリティの成果を得る最善の方法は、ビジネス側とパートナーシップを組むことです。だからこそ私たちは親しみやすく、積極的に関わる存在でありたいと考えています。
モデレーター： それは素敵なお話をありがとうございます。そして私たちの国旗の色を少し取り入れてくださったことにも感謝します。それでは、セキュリティの文化と文化としてのセキュリティという、微妙でありながら力強い区別についての話に移りたいと思います。この区別がどういうものか、そして実際にはどのように現れるのかを少しほどいていただけますか。
Hart： 組織で行うあらゆることは、その文化を築く核となる信条から始まると考えています。Amazonおよびawsにいて非常にわくわくするのは、書籍をインターネットで販売する事業であれ、コンピューターを時間単位でレンタルするオンライン事業であれ、あらゆる事業の最前線に顧客からの信頼が置かれてきたという点です。そのAmazonの運営の核となる考え方、すなわちカスタマーオブセッションという発想をそのまま持ってきて、それがセキュリティの観点から何を意味するのかを考えることができます。つまり、恐怖ではなく信頼を中心にセキュリティの文化をどう築くか、そして煩雑で時間のかかる体験ではなく、低摩擦かつ高い価値を持つセキュリティ体験をどう実現するために使いやすさを中心に据えるか、ということです。そしてそれらはすべて、事業の根幹から逆算して考えられているのです。
2. 顧客体験起点のセキュリティとブレームフリーな組織
2.1 顧客体験を「エンドツーエンドで所有する」ことでセキュリティが機能要件になる仕組み
モデレーター： 実際に、日々の業務の中でその考え方がどのように現れているのか、具体例を教えていただけますか。
Hart： そうですね、いくつかお話しできる例があります。一つはガーディアンプログラムの登場です。これはAmazonおよびAWS全体に広がっている考え方で、セキュリティは全員の仕事であり、誰もがセキュリティのアドボケートになれるというものです。セキュリティエンジニアである必要はありません。私たちの組織には数千人のセキュリティガーディアンがいて、テクニカルプログラムマネージャーであったりソフトウェア開発者であったりしますが、自分が構築し運用しているものに対してセキュリティ体験に個人的なオーナーシップを感じており、セキュリティチームと密接に連携しながら、私たちが全員に求める高い基準を、それぞれが作っているものに適切に合わせて調整していく作業をしています。
モデレーター： なるほど、その点について少しお聞きしたかったのですが、セキュリティに対する考え方の転換についてです。私はもっと伝統的な感覚を持っていて、セキュリティはゲートのようなものだと捉えがちでした。今朝の基調講演でも、もっとラップアラウンド的な捉え方をされていましたが、それはAWSにとって文化的により重要な部分だと理解しています。では、人々がセキュリティを通過しなければならないゲートだという考えから、本当に自分のものとして所有したいと思える何かへと、実際にどう移行させているのでしょうか。
Hart： それぞれの組織や政府によってアプローチは異なりますが、私たちにとっては顧客体験というレンズが非常に重要です。個人やチームが顧客体験をエンドツーエンドで深く所有している場合、彼らがすぐに気づくことの一つが、セキュリティは機能要件であるということです。これこそが、セキュリティが「後付け」ではなく「作り込まれる」ようになる仕組みです。セキュリティは専門家だけに頼るものであってはならず、チームの外にある依存関係として扱うものであってもいけません。顧客体験をエンドツーエンドで深く所有するということは、私たちのチームが常に、どのようなセキュリティ体験を提供すべきか、どうすれば顧客の信頼を得られるか、顧客のデータの守護者としてふさわしい行動を取れているか、を考えているということです。そうすることで、セキュリティの立場から関わるときには、チームに対して助言したりコーチングしたりする必要がなくなり、私たちは専門知識を提供し、開発者が抱える負担を軽減するために存在することになります。
2.2 セキュリティ組織の役割:個別対応ではなく再利用可能な基盤(暗号化など)の提供
Hart： 例えば、チームは独自に顧客データを暗号化する必要があるという結論に至ります。しかし、千のチームがそれぞれ千通りの方法でデータを暗号化する必要はありません。そこでセキュリティ組織の出番となり、耐久性があり、信頼性が高く、スケーラブルで安全な暗号化の方法を構築し、誰もが正しい答えにたどり着きやすくします。
モデレーター： おっしゃっていることを聞くと非常に当たり前のように思えるのですが、私が最初にセキュリティについて考えていたのはゲートという捉え方で、二番目の捉え方は、良くも悪くも恐怖や非難でした。何か問題が起きたときに、チーム内で非難の連鎖を生み出さずに、むしろ人々が積極的に報告したり手を挙げたりできる環境をどう作り出しているのでしょうか。
2.3 組織構造(セキュリティ責任者が事業責任者に直属)とCOE(Correction of Errors)による非難のない根本原因分析
Hart： こうした点について、私はある意味とても恵まれていると感じています。私たちはセキュリティを支持する視点を持つ会社でこれを実践できているからです。一つの例として、私たちのセキュリティリーダーシップは常にビジネスラインのリーダーに直接レポートするという構造があります。つまり、セキュリティのエグゼクティブがCIOやCTOにレポートするようなことはなく、それぞれのビジネス機能に相当するCEOに直接レポートしています。そして、これをブレームフリーな文化に結びつけて考えると、Amazonの根底にある考え方の一つがまさにそれです。私たちには社内でCOE、つまりCorrection of Errorsと呼ばれる仕組みがあります。これは私たちが発明したものではなく、実は日本のアプローチから採用した根本原因分析の手法です。しかし、その根本にある要素は、何が問題だったのかをブレームフリーに分析することです。そして最も重要な部分は、組織内の他の誰もが同じ欠陥に二度と悩まされることのないよう、耐久性がありスケーラブルな解決策をどう開発するかということです。これが基本のケースとしてすでに存在していれば、セキュリティ上の問題がエスカレートするような事態が起きたときにも、私たちにはすでにブレームフリーという土台があるので、あとは夜中の緊急事態からできるだけ早く「すべて問題ない」状態へと戻ることに集中できるのです。
モデレーター： なるほど、そう伺うと、もし一つの問題を解決すれば、次に起こることについても解決したことになる、という貢献的な側面があるのだと想像できます。
3. セキュリティガーディアンズプログラムの全体像
3.1 セキュリティチームと同じツール・チケットシステムを共有する重要性
モデレーター： ガーディアンについては先ほど少し触れていただきましたが、私たちも今まさにこのテーマについて考え、多く議論しているところなので、もう少し掘り下げさせてください。エンジニアをセキュリティのアドボケートに変えるというこのモデルの考え方について、文化的にどう機能させるかという点は理解できたのですが、インセンティブやツールといった、より実践的な仕組みはあるのでしょうか。
Hart： そうしたプログラムから発展していくインセンティブは確かに存在します。実践的な取り組みの一つとして、もし人々に自分が構築しているものと顧客のためのセキュリティ体験を深く所有してもらいたいのであれば、そのためのツールを与える必要があります。私がこれまで話をしてきた多くの組織では、セキュリティチームだけが特別なツールを持っていて、開発者に対して「あなたたちにこういうことをしました」というレポートを送るという構造になっており、それが緊張関係を生み、対応に時間がかかる原因にもなっています。私たちのガーディアンプログラムの核となる要素の一つは、サービスチームに所属するセキュリティガーディアンたちが、セキュリティオペレーションチームと全く同じツールを使っているということです。PDFで送られてきたレポートに対応するのではなく、同じチケットシステム、同じテレメトリ、同じダッシュボードを使っています。これは非常に基本的なことですが、一緒に取り組まなければ、そもそも成立しないのです。
3.2 ガーディアン経験がもたらすインセンティブとキャリアへの効果(昇進・ストレッチアサインメント)
Hart： そしてインセンティブという状況に話を移すと、私たちが観察していることの一つに、ガーディアンである人々はまず自分たちの仕事に非常に誇りを持っているということがあります。彼らは同僚からの尊敬を得ています。そして、ガーディアンという役割は、昇進やストレッチアサインメントといったものに強く貢献する要因になることが多いのです。
モデレーター： それは興味深いですね。
Hart： そうです。彼らは信頼できる人たちであり、頼りになる人たちです。バックボーンを持ち、意見が異なっても最終的にはコミットする姿勢を持っています。深いオーナーシップを持ち、強いバイアス・フォー・アクションを持っています。これらはすべて私たちがAmazonで大切にしていることであり、彼らはやらなければならないからではなく、やりたいからそれをしているのです。そしてそれは、他のリーダーシップの機会へとつながる、まさに素晴らしい足がかりになっています。
モデレーター： それは本当に興味深いです。私自身、そこまで考えたことがありませんでした。おっしゃる通り、キャリア開発という側面がそこにあるのですね。肩書きもその助けになるとは思いますが、もう一つお聞きしたいのは、彼らの権限についてです。実質的な力を持っているのか、それともある種の演出的な役割にとどまっているのでしょうか。
3.3 ガーディアンの「権限」は肩書きではなく実践から生まれるという考え方、独立した第三者評価の活用
Hart： 彼らは確かに実質的な力を持っていますが、それはプログラムそのものから来るものではありません。実践から生まれるものです。ガーディアンでなくても、これを行うことはできます。例えば、あるチームが顧客の要件から逆算して仕事を進めている場合、「このデータをどう守るか」と問いかけ、脅威モデルを構築し、ユースケースを開発し、バックログの中で優先順位をつけ、それに向かってスプリントを回していく、これは誰にでもできることです。ガーディアンは、それが見過ごされないようにする役割を担っており、緊張が生じている部分や解決すべき優先順位などを指摘する手助けをしています。実践的な部分として重要なのは、彼らがすでにそのチームの一員だったということです。すでにそのチームと一緒に構築し、デプロイし、運用してきた人たちであり、今はその延長として、顧客の信頼が最優先であること、セキュリティが最も重要な優先事項であることを皆に思い出させ、チームがそれを実現する手助けをするという追加の機会を得ているにすぎません。これは永続的なポジションである必要はなく、状況に応じて動くこともできます。時にはセキュリティガーディアン、あるいは単なる開発者にとって、最善の行動は独立した評価を得ることです。つまり、ガーディアンの役割の一部は、「私たちは素晴らしい仕事をしているが、組織の中で賢いのは私たちだけではない」と言うことでもあります。他のセキュリティガーディアンや別のサービスチームの開発者の視点を取り入れることで、最初から正しい結果にたどり着き、ロールバックや再プロビジョニングを避けることができるのです。
モデレーター： ガーディアンがチームに組み込まれているという性質は、完全に理にかなっていると感じます。ただ、AWSの規模では当然すべてを中央集権化することは不可能ですが、ガーディアンと、当然ながら全体に責任を負う中央のセキュリティチームとの関係をどのように管理しているのでしょうか。
3.4 中央セキュリティチームとの関係構築:Epic Leadershipトレーニング、事前の1on1、感情の自己調整(box breathingなど)
Hart： その一部は、正直なところ本当にコーチングです。私たちはもちろんテクノロジーを愛していますが、この多くは人間関係、対人スキル、リーダーシップ、効果的にコミュニケーションする能力に関わるものです。そのため、私たちはこれまで何年にもわたってトレーニングを実施してきました。アプリケーションセキュリティやバックログの整理方法といった内容だけでなく、私たちが「エピックリーダーシップ」と呼ぶプログラムも運営してきました。これは、逆境や変化を通じてどうリードするかについて、共感的な視点を持つことを重視するものです。私たちはこれを多くのガーディアンに提供し、多くの人が実際に受講してきました。そこで強調される基本的な事柄の一つが、重要なステークホルダーと1on1を行う必要が生じる前に、あらかじめ1on1を行っておくべきだということです。相手のことを知り、家族や趣味、仕事での優先事項について学ぶ。それを本当に自然な形で行うことが大切で、チェックリスト的にこなすものではありません。しかし、そうした1on1をいくつか行っておけば、ロードマップの会議で、ある機能と別の機能の間で厳しいトレードオフを判断しなければならないときに、共通の理解があり、善意から来ているという確信があり、すでに高い判断力を伴うやり取りをしてきた実績があるという状態になります。これは単純なことのように聞こえますが、必要になる前に1on1をしておくという行動を実際に取る人は多くありません。もう一つ良い例は、感情をどう調整するかということです。特に、これをうまくやらなければ顧客や会社にとって悪い結果になりかねないと感じる緊迫した瞬間には、人は非常に興奮してしまいがちです。ボックス・ブリージングのような手法を使って自分を落ち着かせ、中心を取り戻す人も多いですし、必要であれば外に出て息抜きをすることも大切です。正しい判断をするということは、最も声が大きいことや最も多くのデータを持っていることではなく、最も確信を持ち、説得力があり、協調的であることなのだと理解することが重要です。そして、そのためには正しい状態で臨まなければなりません。落ち着いていて、思慮深くあり、そして人の話を聞く準備ができていなければならないのです。ロードマップの中でセキュリティのことをきちんと進めるために、そこまでする必要があるのかと思うかもしれませんが、これを大規模かつ確実に実行するためには、そこまでのことが必要なのです。私は、深いテクノロジーの部分ではない組織の外側から来た人間として、時に人間同士が力を合わせる場面では、こうしたよりソフトで一般的なリーダーシップのスキルはそれほど必要ないと思い込んでしまうことがありますが、実際には非常に重要であり、結局のところエンジニアも人間なのだということに気づかされます。
4. AIツール(Kiro/Quick)を活用したセキュリティ実務の変化
4.1 Kiroによる仕様駆動開発(Spec-driven Development)と脅威モデリングの高速化(アイデアから「安全なアイデア」へ数分で到達する事例)
モデレーター： 次のトピックに移りたいと思います。これは先ほどの話ともつながりがあるのですが、AIについてです。基調講演でもKiroとQuickについて少し触れられていましたが、質問に入る前に、それぞれについて一言ずつ説明していただけますか。会場の皆さんの理解を揃えておきたいので。
Hart： はい。Kiroは私たちのエージェンティックIDE、つまり統合開発環境です。アイデアを持って、プロンプトから始めて、対話的に仕様書とタスクリストを構築していくことができ、そのままIDEで対話的に実装するか、自動的に実装させることもできます。この根底にある考え方は、スペックドリブン・デベロップメント、つまり仕様駆動開発と呼ばれるものです。セキュリティ実務者にとって、これは信じられないほど素晴らしいものです。なぜなら、アイデアを一つ持ってくると、それがフォーマルな仕様書として生成され、しかもそれをビジュアル化するボタンもあって、Mermaidのダイアグラムなども生成してくれるからです。ホワイトボードに描いたものやメールのようなものではなく、対話可能な仕様書として扱えることで、例えば「この仕様に対して脅威モデルを生成して」と言えば、いくつかの項目を生成してくれます。そして「この三つが最優先事項です。特定された脅威に対する対策を提供するように仕様を更新してください」と言えば、これまで何度もホワイトボードを使い、根本原因分析や攻撃ツリーのモデリングを行い、セキュリティエンジニアリングと二、三週間かけて行き来していたようなプロセスが、文字通り一分半でアイデアから安全なアイデアへと変わります。そしてタスクリストを生成し、セキュリティの観点からも同様のことを行い、そこから実行に移ることができます。これは私がエグゼクティブとして最も興奮するサービスの一つです。というのも、私自身は今、AWSで実際のプロダクションビルドをそれほど多くは行っていません。過去にはサービスをローンチしたこともありますし、そうした格好良い仕事もしてきましたが、今週について言えば、私が実際に何をしているかというと、技術チームとのミーティングに向かう前に、五分から十分ほどかけて、話し合う予定のアイデアをモデリングしてみるのです。例えば、脅威インテリジェンスチームと一緒に、彼らが運用している脅威インテリジェンスシステムの一部を更新しようとしている場合、Kiroに入って「こういう特性や機能を持った脅威インテルシステムがあったらどうなるか」というプロンプトを打ち込みます。すると仕様書が生成され、その仕様書についていくつか質問をし、「タスクリストを生成して」と言います。そうして五分ほどで、モレスキンの日記に質問リストを書き出していた時と同じ時間しかかけていないのに、サービスチームとの会話にはるかに準備が整った状態で臨めるようになります。しかも、「なぜこうした質問をしているかというと、実はこういう仕様を生成したからなんです。私は何を間違えていますか。何を誤解していますか。あるいは、私が非常に重要だと考えているこの部分を、実装に含めることを検討してもらえますか」と話すことができます。手書きの準備メモだけでは、そこまでたどり着くことはできません。
4.2 Quickの日常的な活用:リサーチ、エージェント構築、コンテンツ生成、クローズドループメカニズム構築支援エージェントの事例
モデレーター： それは素晴らしいですね。Kiroについては伺いましたが、Quickの方はどうですか。実際にご自身で使われているのでしょうか。
Hart： そうですね、Quickについてですが、正直に言うと、私はもうMicrosoft Officeをほとんど使わなくなりました。Outlookはメールのために使わざるを得ませんが、実際には一日の大半をQuickで過ごしています。リサーチを行ったり、特定のタスクをこなすエージェントを構築したり、ドキュメントやプレゼンテーションなど、さまざまなコンテンツを生成したりしています。良い例を一つ挙げると、Amazonでは「クローズドループ」の仕組みをとても大切にしています。これは単なるプロセスやプレイブックよりも少し堅牢なもので、その考え方の核心は、コントロール可能な入力があり、その入力に対して何らかのプロセスやソフトウェアが作用し、出力を生成し、その出力を検証できることで、入力を変更したり、途中のエンジンに調整を加えたりできるというものです。チームに良いメカニズムを設計することを教えるのは、実は手間のかかる作業で、計画も必要です。私たちにはトレーニングやベストプラクティスもありますが、つい数週間前に行ったことの一つとして、Quickの中に、しっかりとしたセキュリティメカニズムを構築する手順を案内してくれる小さなエージェントを作りました。そのため今では、チームとの会話の中で「Xを行うための仕組みが本当に必要だ」となった際には、Quickを開いて、その小さなエージェントと数分やり取りするだけで済みます。エージェントはメカニズム構築の八つのステップすべてを案内してくれて、私たちがセキュリティや品質の面で懸念していることの一部もすでに理解した上で、計画や戦略、検討すべき提案事項などを生成してくれます。すべてがすぐに使える状態で用意されるのです。以前であればホワイトボードから始めて、ドキュメントを書き、ミーティングを行い、またホワイトボードに戻るという、何週間もかかっていた作業が、今では約十五分で済むようになっています。
5. AIがもたらす脅威モデリングとセキュリティ提供価値の変化
5.1 各チームが自律的に脅威モデルを生成する文化(セキュリティチームが代行しない原則)とSecurity Frontier Agentの活用
モデレーター： 私も、こうした事例を一日中聞いていられるくらい好きです。皆さんそれぞれのやり方でこれらのツールを使いこなしていて、私たちのチームも私たちなりのやり方で活用していますが、どれほどのスケールと範囲でこれらが使われているのかを知るのはとても興味深いことです。それでは、AIと脅威モデリングについて少し考えてみたいと思います。何百万もの顧客が機密性の高いワークロードを託すAIシステムを構築しているわけですが、そうした文脈で脅威モデリングをどのように捉えていますか。
Hart： 私たちはこの点についてかなり多くのことを考えています。一般論として、もちろん多少のニュアンスはありますが、事前に時間をかければかけるほど、その後の物事はうまく進みます。そして最後のテスト体制が優れているほど、クローズドループを実現でき、素早く動き、素早く反復することができます。ですから私たちは、前半と後半に少し多めの時間をかける傾向があります。つまり、実行しようとしていることが、実際に得られた結果と一致しているかを検証するということです。私がAmazonに在籍しているのはもう14年近くになりますが、その間ずっと、脅威モデリングはソフトウェア開発ライフサイクルに入る際の主要な考え方であり続けています。すべてのチームが自分たち自身の脅威モデルを生成します。これは非常に重要なことだと考えていて、繰り返しになりますが、自分たちのセキュリティ体験を自分たちで所有するということに通じます。セキュリティチームがチームの代わりに脅威モデルを生成することはありません。それぞれのサービスチームやプロダクトチームが自分たちでそれを行うのです。そして今では、脅威モデリングとテストを行う私たちのセキュリティフロンティアエージェントを使う場合でも、QuickやKiroを使う場合でも、脅威モデルを生成し、それに対して問いかけ、対話し、仕様やコードベースのリアルタイムな変化を確認できるという考え方は、物事を素早く正しく進めるための素晴らしい機会となっています。ビルドの段階に進む頃には、想定していたことがすべて対応されているだけでなく、普段は考えないようなことまで浮かび上がってきているという、非常に高い確信を持てる状態になっています。つまりその多くは、最初の一巡りのチェック、すなわち、あるものを構想し、構築し、デプロイし、最初から正しく運用できる状態に持っていけるかどうか、という点に関わっています。
5.2 AIがもたらす3つの価値:大規模検査の実現、オートメイテッド・リーズニング(自動推論)による正しさの証明(Bedrock Guardrails、S3 Block Public Access、IAMの実例)、シングルスレッド型からマルチエージェント型への開発ワークフローの進化
モデレーター： おっしゃる説明の仕方から、そのプロセスをある程度思い描くことができます。今、AIを活用したセキュリティツールに関する期待が非常に大きく高まっていると理解していますが、正直なところ、今はどんなものにでもAIを組み込むことができてしまう状況で、多くの試みがなされている一方で、実際に成果を大きく動かしている部分はどこなのか、それともまだデモの段階にとどまっているものが多いのでしょうか。
Hart： そうですね、いくつかの点で役立っていると思いますが、大きく分けて三つのことが挙げられます。一つ目は、これまでコスト面で現実的でなかった規模での検査が可能になったということです。ここで言うコストとは金銭的な意味だけでなく、時間という意味でもあります。大規模なフリートをスキャンするにも時間がかかりますし、大量のデータに目を通すにも時間がかかります。ですから、AIを使って一部のことを自動的に、より効率的に行えるようになったことは非常に大きな成果です。二つ目は、AIによってサイエンスが非常に刺激的な形で戻ってきたということです。私たちがよく話すことの一つに、テクノロジーがどこで価値を加えるのか、そして人がどこで価値を加えるのかという点があります。特にセキュリティにおいては、サイエンスの部分こそ人が非常に大きな価値を加えられる領域だということが分かってきました。その一つの表れが、オートメイテッド・リーズニング、つまり自動推論やニューロシンボリックロジックを私たちの業務に適用する能力です。これは少し格好つけた数学的な言い方をすれば、アルゴリズムの正しさを検証し、それが意図した通りに動作し、かつ意図した通りのことしか行わないということを証明できる、ということです。もはや、あらゆるシナリオをシミュレーションしてみるものの、本当にすべてのシナリオを網羅できたか確信が持てない、あるいは環境をスキャンしてみるものの、環境内のすべてのノードを本当にスキャンしきれたか確信が持てない、という時代は終わりつつあります。私たちは自動推論やシンボリックロジックを使ってそれを実現できます。つまり、これはタスクを自動化しているというだけでなく、人が数学を使ってフォーマルメソッドを開発し、それをシステムの中に迅速に実装しているということでもあります。そしてサプライチェーン全体を通じて、テクノロジーがどんどん進化していく中で、その将来の進化を推し進めるサイエンスに、ますます多くの人が集中する必要が出てきていると感じています。では、顧客が今日これをどのように体験しているかというと、Bedrock Guardrailsはすべて自動推論を用いて構築されています。S3のブロックパブリックアクセスも自動推論を用いて構築されていますし、IAMのアクセス制御も自動推論を用いて構築されています。これらはシミュレーションの中でモデリングされているものではなく、単なるテストランでもありません。そこには多くの可能性があると思っています。そして三つ目はワークフローです。非常に興味深いことの一つに、コンピューティングにおける多くのものは、本来は並列化したいと思っているにもかかわらず、実際にはシングルスレッドで動いているという事実があります。ビデオゲームに例えるなら、パンチカードの時代から文字通りつい一年前まで、ほとんどの開発者は「スーパーマリオブラザーズ」のような横スクロール型のゲームのような働き方をしていました。一つの小さなスプライトがいて、それが左から右へ移動し、何かを飛び越えたり、頭で何かを叩いたりしながら、特定の機能やコインを獲得していくという具合です。しかし、ビデオゲームにはもう一つの遊び方があります。シヴィライゼーションやシムシティ、スタークラフトのように、何百、何千もの小さなユニットやスプライトが存在し、あるものは採掘をし、あるものは農業をし、あるものは図書館をアップグレードしている、というものです。物事が進行していく中で、画面上のすべてを見ることすらできず、十分、十五分の間、見ていなかったユニットが存在するということも起こります。まさにこれが、今日の開発者たちの働き方なのです。エージェントを使っている人たちと話をすると、一年足らずのうちに、彼らのワークフロー全体が、あの一つの小さな横スクロール型のアプローチから、今では何百ものエージェントを操り、複数のワークフローを扱い、複数の人間のチームともやり取りしながら、それを一人の開発者としてこなすという状態へと、劇的に進化しています。私たちは非常に多くの実験が行われているのを目にしていますし、新しいベストプラクティスもどんどん生まれています。これは、開発者たちがこれまで一度も求められたことのない、まったく新しいスキルセットだからです。
6. 敵対的AIへの対応と変化への適応、クロージング
6.1 エージェンティックAIが防御側に有利に働くという見方とAnthropicによるFirefox脆弱性レポートの事例、様子見のリスクへの警鐘
モデレーター： こうした話は本当に興味深く、こんな話ばかりでもほとんど私たちの仕事を代わりにやってくれているような気さえします。若い世代がこの機会を目にできるということ自体が、セキュリティにとってすべて良い方向に働いていると思います。ただ、話をもう一方の側に戻しますと、いわゆる敵対的AI、ジェイルブレイクといった話題についてはどう向き合っているのでしょうか。
Hart： セキュリティというのは、昔から一種の猫とネズミのゲームのようなものでした。残念ながら、セキュリティがこれほど重要である理由は、実際に決意を持った敵対者がオンライン上に存在するからです。特定の相手を狙っている場合もあれば、単に問題を引き起こそうとしていたり、お金を稼ごうとしていたりする場合もあります。犯罪的な企業活動には「企業」という言葉が含まれているように、彼らはお金を稼ごうとしているのです。これは昔からずっとそうでした。ただ、私が強く信じていることの一つは、エージェンティックAIの台頭が、天秤を防御側に有利な方向へ傾けているということです。私たちは、決意を持った敵対者にとってコストや時間、リソースの面でより実行しにくい状況を作り出すことができますし、私たちが守ろうとしている組織や人々をより均一に武装させることができます。そして、その先駆けとなるような素晴らしい実例がいくつかあります。例えば、つい先週、Anthropicが Firefoxに関する脆弱性レポートを公開しました。これについて良いことなのかどうか問われれば、間違いなく良いことだと言えます。誰かに悪用される前に、私たち自身がそうした問題を見つけたいと思っているからです。興味深いのは、Firefoxはおそらく世界で最も精査され、レビューされているコードベースの一つであるということです。それでも、良い側の人たちがそこにたどり着き、しかも他の誰かより先にパッチを当てて解決することができたのです。ですから、私たちはこの流れをうまく取り込んでいけると思っています。逆に、傍観者的な立場に留まり続けている組織については懸念しています。彼らはAIの力を信じていなかったり、複雑さやワークフローの変更を強いられることを心配していたりしますが、そうした懸念の多くは実際に使った経験がないことから来ています。一度使い始めれば、その価値を目にするだけでなく、実際に体感することになるからです。ですから、私が最も心配しているのは、行動を起こさないことによって、いつの間にか脆弱な状態になってしまうまで様子見を続けてしまう組織です。そうなる理由はどこにもありません。今日という日が、まさにその未来を先取りして生きる日であり、そうしたセキュリティの恩恵をすべて活用していく日なのです。
6.2 変化の激しい時代にシャープであり続けるための工夫(年間目標の四半期化、リリースサイクルの短縮、失敗を受け入れる文化)
モデレーター： その点について、あなた自身について伺いたいのですが、最も複雑な領域の一つと言えるこの組織を率いる中で、この激しい変化の時代にどうシャープであり続けているのでしょうか。
Hart： いくつか要素があります。まず、私はもともとセキュリティの専門家として教育を受けたり訓練を積んだりしてきたわけではありません。私は学部でスピーチコミュニケーション、つまり論証やディベート、レトリック、スピーチライティングを専攻し、その後MBAを取得しています。セキュリティは、たまたま私が興奮を覚え、長く携わってきた分野だったというだけです。ですから私は常に、イノベーションへの情熱や新しいことを試したいという気持ちを持ち込んできました。私がセキュリティの世界に入ったとき、それは周囲を不安にさせたかというと、確かにそうでした。人々は自分の知っているものを好みますし、信頼できて、何度も繰り返しやってきたことを好みます。新しいことは未検証で不確実だからやりたがらないものです。しかし今日では、組織はセキュリティのイノベーションに対して飽くなき欲求を持っていて、セキュリティが停滞していることに対してすぐにフラストレーションを感じるようになっています。ですから、もし三年前と同じやり方でアプリケーションを作り続けているなら、おそらく四年目にはそのやり方を続けていないでしょう。むしろ、変化するタイミングを三年も逃してしまったと言えるかもしれません。この感覚は私の性分にも合っているのですが、業界全体としてより広く見れば、特にこの十八か月間の急速な変化を踏まえると、リーダーとして、最新のリリースに常に振り回されることなく変化をマネジメントするためのメンタルモデルを構築していく必要があります。そのための方法はいくつかあります。一つは、目標の期間を圧縮することです。これは本当に真剣な話なのですが、もし年間目標を立てる習慣があるなら、年間目標は立てたままにして、それを一つの四半期で達成する計画を立てるのです。四半期の目標を新たに作るのではなく、年間目標を「これを一つの四半期でやる」と決めて、それをどう実現するかチームに考えさせるのです。同様に、月次のリリースサイクルがあるなら、それを日次にする、あるいは週次にするのです。金曜日ごとのデモデーだけでなく、金曜日ごとのリリースを持つようにする。そうして、フロンティアモデルのプロバイダー、たとえばAmazon NovaやClaudeなどが二週間から四週間ごとに新しいモデルをリリースするようになったとき、それが自分たちにとって当たり前のルーティンになっているようにするのです。それがプレッシャーにならず、不安を引き起こすこともなく、「そういうものだ」と受け止められる状態にする。ただし、そこには自然にたどり着けるわけではありません。リーダーシップが、スピードを持って動くことの価値を見出し、そこに踏み込み、コーチングし、支援し、ある種の足場を築いていく必要があります。そして何よりも、物事がうまくいかないこともあると受け入れる覚悟が必要です。非難のない文化を持つだけでなく、失敗を受け入れる文化を持つという考え方に、本気で確信を持たなければなりません。多くの組織は、自分たちはそうした文化を持っていると言いますが、いざCEOのところへ行って「実験をしたためにこれが遅れます」と伝えなければならない場面になると、そうはいかなくなります。「なんてことだ、元のやり方に戻して、今夜中に何とか仕上げよう」ではなく、そうした事態を受け入れられなければならないのです。長期的な学びの価値が見えているからこそ、多少の失敗があっても納得できる、ということが本当に大切です。
6.3 クロージング:10年前の自分へのアドバイス(Andy Jassy氏とのエピソードとリーダーシップへの気づき)
モデレーター： よく分かります。もうお時間になってしまいましたので、最後に一つだけ伺わせてください。もし十年前に戻れるとしたら、自分にどんなアドバイスをしますか。一言でお願いします。
Hart： 十年前ですか。おそらく私が言うとしたら、「リーダーとして、そしてオーナーとして振る舞い始めなさい」ということだと思います。すぐに思い浮かぶ例をお話しすると、これはおそらく九年か十年ほど前のことですが、当時AWSのCEOだったAndy Jassy氏との会議に出席していました。その場にはCISOのSteve Schmidt氏、法務部門の責任者、そして私の上司をはじめとする重要なリーダーたちが揃っていました。会議の最後に、Andy氏が「もしリーダーシップがこれが正しいことだと考えるなら、私たちはそれをやるべきだ」と言ったのです。会場は文字通り水を打ったように静まり返りました。それはとても長く感じられ、体感では何時間にも思えましたが、実際にはおそらく三十秒ほどだったでしょう。私は、上司が何か言うだろうか、あるいはCISOのSteveが何か言うだろうかと待っていました。そしてついに、当時コンプライアンス部門の責任者だったChad Wolf氏が、「Hartがやると言うなら、私もやります」と言いました。その瞬間、初めて誰かが私のことを組織の中のリーダーだと考えてくれているのだと気づいたのです。ですから、誰かに許可を与えてもらうのを待つ必要はない、ということだと思います。オーナーシップを持ち、自分から前に出ていけばいいのです。
モデレーター： それは本当に素晴らしいお話です。実は先ほどのWorkhumanからの登壇者の方も、ある方がまだその肩書きになる前からVPのように振る舞っていた、という話をされていました。本当にありがとうございました。長々とお引き止めしてしまい、一分か二分オーバーしてしまいましたが、それだけあなたのお話が興味深かったということです。ここにお越しくださり、貴重なお時間を割いていただき、ありがとうございました。会場の皆さんにとっても興味深い時間になっていれば幸いです。どうぞお気をつけてお帰りください。
Hart： 素晴らしい進行役をありがとうございました。ありがとうございます。