📖

re:Invent 2024: 米軍のデータ活用戦略 - AIとZero Trustの実践

2024/01/01に公開

はじめに

海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら!

📖 AWS re:Invent 2024 - Armed Forces unite: Connecting data across domains (WPS212)

この動画では、Department of Defenseにおけるデータ活用とデジタル変革について、Army、Air Force、Navy、DLAの各組織のCIOやCTOが議論を展開しています。データを戦略的資産として捉え、Decision Advantageを実現するための取り組みや課題が語られ、特にMission Partner環境での連合国との情報共有やZero Trustアプローチの重要性が強調されています。また、Large Language ModelやGenerative AIの実践的な活用事例として、DLAでの1日10,000件の自動発注システムや、Armyでの契約データ分析、Air Forceでの画像解析などが紹介され、AIの適切な活用領域の見極めと、組織文化の変革の必要性についても具体的に言及されています。
https://www.youtube.com/watch?v=GLITiw4ni_s
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。

re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください!

本編

Re:Inventパネルディスカッション:DoD部門のクラウド変革

Thumbnail 20

Re:Inventへようこそ。私はRob Nolenと申します。AWSのDepartment of Defense部門のSenior Enterprise Technologist Directorを務めています。このようなパネルディスカッションを主催するのは今年で3年目になりますが、Department of Defenseのお客様がクラウドによって実現している変革の旅についてお話しいただく場となっています。本日は皆様にお越しいただき、ありがとうございます。素晴らしいパネリストの方々をお迎えしています。

それでは、distinguished panelのメンバーをご紹介させていただきます。Leo GarcigaはArmy Chief Information Officerです。Michael MedgyessyはAir Force Intelligence Chief Information Officerです。Defense Logistics Agency(DLA)のAdarryl Robertsは、同機関のCIOを務めています。DLAは戦闘支援機関として、修理部品や食料品から衣服、制服、その他関連品目まで、戦闘員が必要とするあらゆる物資を提供しています。Justin FanelliはDepartment of NavyのCTOとして海軍と海兵隊の両方に従事し、さらにPEO DigitalのTechnical Directorも務めています。本日ご参加の皆様も、まさにこの戦いの渦中にいらっしゃるわけです。

データの戦略的重要性:Decision Advantageの実現

本日は、軍がどのようにしてドメイン間でデータを連携させようとしているのかについてお話しします。DoDのデジタル近代化について語る際によく使われる言葉があります。それは「Decision Advantage」あるいは「Decision Superiority」です。これは本質的に、軍に優位性をもたらし、成功につながる意思決定を行う能力を与えることを意味します。テクノロジーやサイバーテクノロジーの進歩、そして世界の進化に伴い、情報は米国だけでなく世界中の軍事力が戦争を抑止するための重要な資産となっています。

データが人工知能にどのような影響を与え、軍がデジタル変革の過程でこれらをどのように活用しているのかについて議論していきます。では、Leoから始めて、パネリストの方々に順番にお聞きしていきましょう。カンファレンスやマーケティングでよく耳にする「データは戦略的資産である」という言葉について、あなたにとってそれはどのような意味を持ちますか?Armyはデータの戦略的重要性をどのように捉えているのでしょうか?

Armyの観点から申し上げますと、私たちは基本を正しく押さえることに重点を置いてきました。これまでは分散型のアプローチで、各機能部門やビジネスユニットが独自の取り組みを行う形でしたが、そこから急速に現在の状況へと移行してきました。Armyは過去3年間、保有するデータの運用化に焦点を当ててきました。多くの人が規模を忘れがちですが、Armyはウォルマート規模の事業を展開し、独自の病院や物流部門を持ち、考えられるあらゆる機能分野が130万人の大規模な組織に統合されているのです。

私たちは、ガバナンスの基盤レベルの構築、適切な担当者の配置、そして戦闘機能や機能領域全体でデータセットを最適に運用する方法の決定に重点的に取り組んできました。契約の整備を進め、関係者全員が同じようにデータを考えるようにしています。もう一つの重要な要素は、組織全体でデータリテラシーを持つ人材の核を作ることです。私たちは大学や民間企業と協力して、Army内にこの核を確立しようとしています。データが戦略的資産であることには同意しますが、私たちは少し異なる視点で見ています。データを製品として資産を測定しようとすると、その類推は限界に達し始めます。

データを戦略的資産として考える場合、重要なのは量ではなく、そのデータを持っていることをどれだけの人が重要視しているか、使いやすさ、そしてどれだけ需要があるかということです。洗練されたインテリジェンス製品としてではなく、価値をもたらす製品として考えると、そのデータが実際にアクセスされた回数で成功を測ることができます。私が持っているデータをどれだけの人が重要だと考えているでしょうか?必要な時に、必要な場所で使用できる、セキュアでアクセス可能な形式で提供できているでしょうか?

技術ソリューションとマインドセットの変化により、このデータを扱う様々なプログラムは、単にデータを保持しているだけでなく、どれだけ共有しているかによって評価されるようになってきています。契約やマインドセットを変更する必要があります。それは契約している人々だけでなく、私たちが想像もしていない用途でこのデータを使用する可能性のある他の人々のためでもあるのです。データを製品として捉えることで、成功の測定方法やデータの意味のある扱い方について、より適切な類推が可能となり、そのデータからより多くの価値を得られる分野をサポートし、注力することができます。

DoDにおけるデータ活用の課題と進化

お二人のコメントとDLAにとっての戦略的側面には完全に同意します。以前も申し上げたように、私たちは政府全体の物流を担当しています。私たちは自社の内部データを理解する必要がありますが、相互運用性の観点から、Army、Air Force、Navy、Space Force、Marine Corpsをサポートするために、私たちは自社のデータを理解するだけでなく、DoDのデータ、そしてNATOや外国のパートナーのデータも理解する必要があります。

データを戦略的資産として語る際の共通のテーマの一つは、Department of Defenseが存在する唯一の理由は抑止力であり、必要な場合は紛争に対応することです。私たちがデータを戦略的資産として見ているのは、紛争を避けたいからです。このデータをドメインを超えて相互運用可能な方法で使用し、世界においてより強力な抑止力となるにはどうすればよいでしょうか?私たちは、私たちのようなデータを見る戦略レベルの人々、データサイエンティスト、データアナリストだけでなく、最前線の兵士、空軍、海兵隊員が、彼らの日々の活動がどのようなデータを提供し、それが「どうだったか」ではなく、「何をすべきか」「どのようにすべきか」「どのような要因を考慮すべきか」の分析に使用されることを理解することで、データリテラシーとデータ活用能力が戦略的資産となることに焦点を当てています。

戦略というものは、結果によって時間をかけて評価されるものだと私は考えています。2016年頃から、私たちはデータが戦略的資産であると言い続けてきました。私たちがそれをどれだけ真剣に受け止めているかによって評価されるべきでしょう。ループの速度が重要な問題です。私の軍事およびICでの25年の経験の中で、ウクライナ紛争や紅海での出来事により、CIOオフィス以外の最前線にいる人々がデータに関心を持つようになりました。これは私たちの活動方法における重要な転換点です。

私たちは常にデータを重視してきました - それは常に戦略的資産でした。しかし、この部屋にいるようなデータに詳しい人々や技術者以外に影響を与えていないのであれば、それは言葉以上のものにはなりません。私たちの速度をどのように測定し、その変換を行うかが、最終的に戦略的能力としての成功を決定づけることになります。Mikeが言及したように、インプットを数えることはできますが、それは最も弱い測定方法です。製品やアウトカムの観点からアウトプットを数えることもできます。データが私たちにより大きな運用の柔軟性や適応性をもたらしたことを示せる場所 - これは直線的なものではなく、べき乗則です - そこで皆さんの助けが必要です。10%の改善ではないことを示せるように。それは産業レベルの改善です。200%、700%の改善を実現できます。

データによって、私たちは本番環境でそれを示すことができます。その効果を証明し、その物語を語ることができれば、それは後戻りする必要のない永続的な変化となります。世界の変化と、すべての状況の変化は、現在の皆さんの責任領域への焦点のように、私たちのアプローチに大きな変更をもたらしました。

長期間にわたって一つの責任領域に焦点を当てることで、多くの効率性が生まれました。しかし今や、世界中のNear-Peerの状況を見なければならない中で、意思決定の優位性はさらに重要になっています。なぜなら、私たちが長い間焦点を当ててこなかった分野で、私たちと競争できる相手が出てきているからです。4、5年前には、私たちは全く異なる状況にいたことを考えてみる必要があります。workforce(人材)の訓練とその知見を構築する強い推進力は、本当に役立ちました。以前のウクライナの状況では、インテル担当者やORSA担当者に任せていたところを、今では指揮官が「私はこれを理解している。機能エキスパートのチームを編成して、作戦行動を開始する」と言えるようになりました。この数年で環境は本当に変化しました。

クラウドテクノロジーを活用したデータ戦略の実装

Thumbnail 660

Command and Controlの統合に関する概念的なアイデアであるJAC2について議論を始めた時、大きな課題の一つは、どのようにデータを活用するかでした。情報を移動させるための基盤としてのクラウドを見ると、これが情報のライフサイクルを作成する方法の一つのビジョンです。生データとアセットを収集し、カタログ処理とData Lakeを通じて処理し、認可されたユーザーにその情報へのアクセスを提供します。そして、Machine Learning、AI、アナリティクス機能を使用してアドホッククエリや意思決定のインプットを行い、その情報を消費するアプリケーションが、継続的な改善と反復のための有益なサイクルを作り出します。

Thumbnail 740

私たちはクラウドを概念的なものとして捉えており、この1週間を通じて商用のお客様や、このようなシステムを構築している方々からお話を伺うことになります。 私たちが処理する情報の種類に関して、独特の課題を抱えています。これからインフラストラクチャーとクラウドテクノロジーについて、考慮すべき特定の領域を見ていきます。商用分野の方々は当たり前のことと考えているか、あまり注意を払っていないかもしれませんが、これらはミッションの成功、ミッションのセキュリティ、そして国家安全保障にとって重要な要素なのです。

Mikeに伺いたいのですが、これらのデータ戦略をサポートし、意思決定支援としてのデータを強化するために、クラウドテクノロジーでどのような取り組みを行っているのでしょうか?Air Force ICエンタープライズがミッションオーナーの迅速な行動を支援するためにこれらのシステムをどのように構築しているのか、お話しいただけますか。インフラストラクチャーの標準化が非常に重要なのは明らかです。迅速に進めるためには、作業を一度行い、それを複製してスケールアウトする必要があります。状況に最適なデザインパターンを見極めることで、すでに完了している多くの作業を継承することができます。

常に例外的なケースは存在し、すべてをデザインパターンに無理に当てはめるべきではありません。しかし、ほとんどの場合、インフラストラクチャーのデザインパターンを活用することで、より迅速に機能を実現し、支援することができるはずです。例えば、LAMBDAサーバーレス関数をコンテナ化されたWebフロントエンドと連携させ、Amazon RDSマネージドサービスを呼び出し、IAM VPCとソリューションの一部を統合したいというプログラムがあります。これらすべてを私たちの環境で連携させる必要があります。エアギャップのある機密ネットワークとクラウド環境では、商用側や非機密側で利用できるすべてのオプションが必ずしも使えないという課題があります。

これらを認証するプロセスを経る必要があります。実は、私たちは意図的にお客様の選択肢を制限しています。なぜなら、お客様は多くの場合、3つの環境すべてにデプロイしたいと考えており、私たちはクロスドメインソリューションを通じてコードをシームレスに受け渡すことができるからです。意図的に制限することで、各機密レベルでコードを分岐させたり、独自のソリューションを作ったりする必要がなくなります。最新かつ最高の機能は制限されますが、推奨するデザインパターンを使用すれば、独自の例外的なアプローチよりも迅速に前進できることを、皆さんに理解していただくことが重要です。標準化されたアプローチに適合するよう努めてください。

データの観点からは、非常にシンプルなもので多くのことができます。ELKスタックは、Kafkaストリームとユースケースごとのスパイラル開発を追加すると非常に強力になります。すぐに実際に非常に有能なデータプラットフォームが構築できます。すでに認証済みで利用可能なものを使ってそれを実現することができました。そして、デプロイの速度などの指標から、採用率や成功度を測定し始めることができました。

データ共有とセキュリティの両立:Zero Trustアプローチ

クラウドにおいて、インフラストラクチャの標準化は成功の鍵となります。現在私たちは全く異なる状況にあり、これは這い歩きから歩行、そして走行へと進むような段階的な状況です。1000もの技術スタックが花開いているか、そうでないかという状態です。郊外のスプロール現状から始めるとなると、かなり異なる状況になります。私たちが目指しているのは、パフォーマンスの観点から最良のものに絞り込むことです。これらの各コンポーネントについて、私たちは測定を行い、現時点ではアプリケーションよりもICAMソリューションの方が多いという状況 - これは制御不能な状態です。では、どのように指定された企業サービスに絞り込んでいけばよいのでしょうか?現在、私たちは4つのコンポーネントからなるスタックを持っており、これは異なるクラウドブローカーと連携して、詳細な運用や切断された状態での運用を可能にしています。

各コンポーネントについて、私たちは存在する数を評価しました - 10や20ではなく、200にも及びます。そこから、それぞれのコストパフォーマンスと価値実現までの時間を評価し、順位付けを行いました。Privileged Access Management (PAM)や、さらにはユビキタスな輸送手段への aspirationに基づいて優先順位付けを行い、宇宙対地上のオプションや何が機能しているかを検討しました。これらを絞り込んでいく中で、スケール可能な投資の視野を見据えています。5つのエンタープライズサービスを指定し、300以上の基地やより多くのコマンドにわたってスケールできる成功例を求めています。

現在、私たちは異なる成熟度レベルにあり、それが非常に興味深い点です。このチャートを見ると、苦心している明確な成功例があるため、思わず笑ってしまいます。技術的な側面を超えて考えてみたいと思います。私たちが全体を通じて発見したのは、技術的な問題は全くないということです - 現時点で扱いきれないほどの技術があります。本当の課題は地道な作業にあり、特にArmyではデータに関する適切なガバナンスに多くの時間を費やしています。

これは、正しい問題を解決するための適切な要件を構築するという考えを推進しており、ICAMがすべての活動の基盤となっています。技術的には確実に機能を展開できますが、誰が機能的に運用するのでしょうか?サービス間で、あるいは外国のパートナー、連邦から州、地方に至るまでデータを共有したい場合、その技術に属性をどのように統合すればよいのでしょうか?これは間違えてはいけない一点であり、私たちが多くの時間を費やしている分野です。Justinの指摘通り - 確かに1000の花が至る所で咲いていましたが、Armyではそれをうまくコントロールできています。次の重要なステップは、参加者たちにこの journey に積極的に関わってもらうことです。

公共の関心事として、以下を考えてみてください:Freedom of Information Act(情報公開法)の要請に応じて処理し、機密解除する必要のある戦時データが約90ペタバイトあります。簡単に聞こえるかもしれませんが、現時点でこの問題に対処できる技術は存在しません。人間が - 紙や マイクロフィッシュ、ディスク、PDFを通して、これらの文書を確認し機密解除を判断しているのです。

これらの情報を共有できる段階に到達するためには、アメリカ国民に提供し、この国の政策を再構築するために、これらの要素を適切に整える必要があります。先ほど話し合ったように、これらのプロダクトは共有される必要があります。最新のCloud Nativeアーキテクチャが価値を生み出す方法は、APIの活用を中心に展開されています。

Mission Partner環境における情報共有の課題

Defense Logistics Agencyは、主にロジスティクスを事業としていますが、CIOの技術的な観点からは、OSD(国防長官室)レベルでDoDの部門全体のプログラムについて相談を受けています。その中の一つの分野として、約60年間にわたって管理してきたのが、DLA Global Exchangeという「交通整理係」と呼ばれるものです。これにより、財務、HR、調達、ロジスティクスの分野で、部門全体での統合が可能になっています。約60年間、EDIトランザクションのような古い技術を使用して、年間約90億件のトランザクションに関する技術的な統合を担当してきました。

Thumbnail 1400

現在の私たちのミッションは、各サービスや組織が近代化を進める中で、それをどのように維持していくかを決定することです。新しいデータ標準が登場し、APIゲートウェイへの移行が進んでいます。そこには既存のAPIライブラリがあり、誰もがゼロから始める必要がないようにしています。例えば、私がLMP向けのAPIを構築した場合、Navyが再構築する必要はありません。Armyが標準を提示し、それに基づいて全員が設計を行うことができます。これが、APIゲートウェイを確立する上での私たちの新しいミッションの一部です。これは単なる技術的な相互運用だけでなく、ライブラリの作成も含まれており、また部門全体のデータ標準の管理にも関わっています。

これは、主要なソリューション間でデータを共有する能力を制限している別の要因だと思います。以前、DoDでは多くのものをカスタマイズしていました。現在は、商用製品を使用して、よりインダストリーに近づこうとしています。私たちはOSDと協力して、業界が支援できるデータ標準を作成しようとしています。Navy、DLA、Army向けに異なるソリューションを構築する必要はありません。ソリューションをカスタマイズする必要はなく、そのソリューションが基づくデータ標準を作成しましょう。そのため、過去2-3年間は、現在のDLAのEDIとAPIの間の移行のためのAPIゲートウェイの作成と、6-7つの異なるパートナーではなく、一つのDoDとして協力できるようにするためのデータ標準の作成に時間を費やしてきました。

私たちが話している膨大な量のものについて考えると、必要な技術は全て揃っています。軍隊が機能する理由について聞くとき、私が本当に素晴らしいと思うのは、独立した人々がそれぞれのミッションを達成するために決定を下す能力を持っているということです。しかし、60-70年の間に、多くのミッションが様々なことを行うようになり、それを全て調整しなければならなくなったのです。

指揮官の視点から見ると、私たちには独自のITバジェットと活動を持つ多くの小規模ビジネスのようなものがあり、それらを統制してシナジーを生み出す必要があります。リソースには限りがあり、それらが集中管理されていない場合、各部門は大きな自律性を持っています。これを管理するためのレバーがいくつかあります。その一つが私のオフィスにある Authority to Operate(運用認可)です。インテリジェンス部門に関しては、全ての部門がこれを通して何をしているのかを報告し、運用認可を申請する必要があります。そのため、秘密でも隠されてもいないことが分かり、関連性を見出すことができます。

DoDにおけるAI活用の現状と展望

私たちは、何が基盤となるものか、そして彼らが集中すべきユニークな部分は何かを検討できます。従来、誰もが好んで構築したがる技術基盤があり、スタック全体を下から上まで構築し、他への依存を排除して、すべてをコントロールしようとします。余裕があれば再構築する - 外部ソースに依存するよりもそうしたいと考えます。しかし、Cloudはこの考えを完全に覆し、Shared Responsibility Model(共有責任モデル)を受け入れる必要があると思います。

つまり、ユーザーを増やすことが、より少ないリソースでより多くのことをするためにプログラムを薄く広げることにはならないということです。As-a-Serviceモデルでは、技術的にも、顧客の資金面でも弾力的にスケールすることができます。これらの基盤となるものが何をするのかを見ています - Identity Management、DNS、脆弱性スキャン、アンチウイルスなど、誰もが必要とするものです。これらは一度構築して多くの人が使える基盤的なもので、各部門は自分たちのユニークな部分に集中できます。

スタックを上に進むにつれて抽象化し、「新しいTop SecretのKubernetesスタックを構築する必要はない - すでにあるものを使えばいい」と言えます。そのスタックに必要なものがない場合でも、90%の解決策を捨てて再構築するのではなく、不足している10%を追加して、その90%を使えるようにしましょう。これが私たちのアプローチです。

データに関して具体的にお話ししましょう。データとは何か、どのように考えるべきかという質問は非常に良いものです。Enterprise Data(企業データ)は一般的に消えものではなく、信頼できる情報源となります。地域における弾薬の所在地など、指揮官はそれを変更することはなく、非常に正確であることを望みます。一方、戦闘における最前線のレベルでは、非常に消えものであるデータは、収集され配信された瞬間の価値しかありません。

企業データやシステムから得られるデータについて、その本質を理解するためにマインドセットを切り替える必要があります。つまり、柔軟性が低く、おそらく変更されることがなく、業務を遂行するための信頼できる情報源となるべきデータについて考える必要があります。すべてのサービスにとっての課題は、企業全体を通じて、そのデータの鮮度や柔軟性が少しずつ異なるということです。Governanceについて語る際、それは単なる会議や基準についてではなく、必要なData Productsと、何を最小限に抑える必要があるかを理解することなのです。

Cloudによって、データの民主化が全面的に可能になりました。5年前は、部隊の準備態勢に関するデータは企業レベルでは利用できませんでした - 見ることができなかったのです。現在では、大規模な意思決定が可能になり、その意思決定を支援できる人々がそのデータにアクセスできるようになりました。これが企業データです。JC2のような事例について話す際、敵の位置情報などは収集された瞬間の価値しかありません。我々は指揮官がそのデータを最大限柔軟に活用できることを望んでいます。

医療、保険、法執行機関など、同様の課題を抱える分野がありますが、これは非常に独特な軍事的な課題であり、我々は継続的に取り組んでいます。データの階層化は非常に興味深い概念です。ロジスティシャンとして、この種の分類が統合軍全体に適用される必要があると思いますか?弾薬、食料、燃料を供給するのと同様に、データも供給しなければならないものです。特にPacificなどの戦域を見た時、企業の非腐敗性データを提供して、誰もが意思決定できるようにする必要があります。第二次世界大戦以来経験したことのない規模であり、East CoastからGuamまでの情報伝達に光速でも時間がかかることを考えると、非常に興味深い課題です。

そのため、迅速な対応ができない場合に備えて、データを利用可能な状態で配置しておく必要があります。我々にとって、データの民主化は現実のものとなっています。我々の間でのデータ共有について話している一方で、商業的なデータ共有の必要性や、商業産業界との相互のデータ共有については触れていません。それをどのように民主化するのか?どのようにセキュリティ管理を行うのか?Zero Trustなどについて話す際、それは直接Decision Advantageに関連します。

従来、我々は過去の実績と学んだことに焦点を当ててきましたが、世界情勢は、それが前進する方法でもDecision Advantageを得る方法でもないことを示しています。Decision Advantageとは、何をすべきか、いつすべきか、そしてどのような条件が影響するかということです。これらのモデルの中から1つだけを選ぶということはないでしょう。戦術レベルではDescriptiveな分析が必要になります。各階層でDiagnostic、Predictive、Prescriptiveな分析が必要になりますが、最終的に優位性を得られるのは、そのPrescriptiveな性質からです。

私たちが直面している課題、そして誰もが直面している課題について、ステージで4文字の言葉「CMMC」を使います。ここにいるすべてのベンダーがこの用語を好んでいます。しかし、これは必要な悪なのです。これは商業パートナーに対する私たちのZero Trustモデルであり、国防総省と取引をする場合は、適切なセキュリティ管理が行われていることを確認する必要があります。しかし、課題はそれがどのように維持されているかを確認し、データが侵害された時にそのフィードバックを得る方法です。

これは物流コミュニティの観点から私たちにとって重要な焦点です。なぜならDLAはその情報なしでは成功できないからです。今日では何も供給できません。私たちはグローバル経済の中にいます。米国は今この瞬間も競争の中にいます。物流コミュニティでは現在、供給を巡る争いが起きており、そのデータは戦闘員が必要とすることを、彼らが必要だと気付く前に確保するために不可欠です。COVIDはDLAにとって大きな教訓でした。誰もがトイレットペーパーを入手できなかったと思っていますが、私たちも入手できませんでした。National Defense Actsなどのバックアップがあったにもかかわらず、私たちは他国とトイレットペーパーを奪い合っていました。

データの観点から見ると、もし私たちがAnalyticsやデータの活用においてもっと予測的であれば、数ヶ月前から兆候があり、おそらくもっと上手く事態に対処できたはずでした。これこそが私たち全員が目指しているところです。つまり、サービスに対して受動的になるのではなく、何かが起こる6ヶ月前に、これが起こる可能性があるという情報を指揮官や戦闘員に提供することです。そうすれば、たった一つの選択肢しかない状況ではなく、取るべき行動の選択肢を持つことができます。

Thumbnail 2070

あなたが仕事をする中で生成するデータは一つのシグナルであり、それを安全に保つことは供給を確保するだけでなく、実際には手の内を明かさないことにもつながります。最も基本的なレベルでのデータリテラシーが重要です。私たちはよくAmazonと比較されますが、各Amazon Distribution Centerで気付いたことの一つは、荷物を持ち上げ、梱包し、保管し、出荷する現場の作業員が、CIOよりもテクノロジーに興奮していたことです。なぜなら、それが彼らの仕事をより効率的かつ効果的にするのに役立つことを理解していたからです。戦闘員が戦場に赴く様子の変遷を見てみると、最初は一人だけが通信機器を持ち、それが機能することを祈るだけでした。今では全員が背中のミニコンピュータを通じてリアルタイムの情報を伝達し、生死に関わる決断を下しています。これが戦略的なデータ資産なのです。

では、データガバナンスとセキュリティについて話を進めましょう。Zero Trustやその他の話題に触れましたが、Navyはこの分野でFlank Speedなどの興味深い取り組みを行っていると思います。Data Meshについて、そしてこれらの情報プロダクトとやり取りする能力について考えるとき、私たちはそれらを公開し、カタログ化しています。人々はどこに行けばよいか知っており、誰がプロダクトを所有しているかを知っています。プロダクトの所有者は誰がアクセスでき、何を導き出すのかを知っているので、自分たちの資産を保護することができます。Navyではこれをどのように近代化し、どのように迅速に進めていくとお考えですか?Flank Speedはその良い例だと思います。

この会場にいる皆さんは、データ共有が5年前と比べて10倍も重要かつ緊急性を増していることを認識していると思いますが、我々の組織の全員がそれを理解しているわけではありません。その波及効果や影響として、個々のコストベネフィット分析があります。これは先ほどの議論に戻りますが、データ共有とセキュリティの間でニワトリと卵の状況にある場合、Zero Trustのデータレベルのセキュリティがその状況を打開し、それを証明できれば成果を上げることができます。

数年前、国家安全保障データは非国家安全保障データから分離・隔離しなければならないという実際の方針がありました。しかし、OGDAはそれを撤回しました。なぜなら、それらはすべて競争優位性に関連していることが判明したからです。ただし、DCや全国に散らばる10万人のデスクワーカーの認識を更新するには長い時間がかかります。これまで行ってきたような100回のガバナンスに関する議論を重ねるか、あるいは他者の成果を活用できる量を加速し、それを広めていくようなデータをもたらすか、どちらかの選択肢があります。

私の考えでは、軍事サービスはGoldwater-Nickels以来、これほど緊密になったことはありません。Air ForceがJoint Fires Networkを自分たちのPEOの1つに取り込み、全員がそれに依存することになると言った時、あるいはArmyが何かを担当する時、我々は相互依存的になるでしょう。明らかに、共通のものは共通であり、固有のものは固有です。コンポーネント実行レベルでは、我々は異なるデータ環境を持っていると言っています。Flank Speedは、もし我々がデータを非常にうまく扱えば、他の180のネットワークの一部を統合できる場所です。なぜなら、データとワークフローによって合理化とネットワーク統合が可能になるからです。

AvannaとJupiterの使用方法を見ると(Jupiterは指定されたエンタープライズサービスです)、我々はそのようなものをもっと求めています。S3からApogeeを経てAzure Blobへの変換プロセスについて、17の異なるアーティストが異なる方法で行っています。最良の方法を選んで、もう試行錯誤はやめて、それをベストプラクティスとして実行しましょう。データクレンジングの観点から、我々はBronze、Silver、Goldの区分を持っています。何かがGoldになった時、つまり実際にクリーンになった時、我々は情報ドメイン間を横断できます。それまでは、自分の目的のために使用できます。なぜなら、手作業を減らしてより多くの自動化ができる変換の際にそれを捕捉できるからです。

これはMission Partner EnvironmentsやCross-Domainのケースにとってより良いものです。もし我々が本当にAIに取り組もうとするなら、現状よりもスムーズにドメイン間でデータを移動させる必要があります。AIの話題に入る前に、外国パートナーとの情報共有についてMikeに簡単な質問を投げかけたいと思います。ジョイントデータ共有の問題について考える時、Army、Navy、Air Force、そしてDLAが代表する第4の組織がどのように共有に取り組んでいるかについて聞いてきました。我々はグローバルコミュニティに住み、グローバルコミュニティで働いており、United Statesは世界中に同盟国を持っています。

このような取り組みを行う際には情報共有が必要ですが、人々との関わり方やそれに伴う義務にはさまざまなレベルがあります。時には、共有すべきでない情報もあります。Air Forceが多くのMission Partner関連の Executive Agentを務めていることから、Mission Partner環境や多国間での情報共有について、そして今日議論した内容がそれらにどのような影響を与えるのかについてお話しいただけますか?Mission Partner環境と連合国との情報共有は、時間軸で考える必要があります。今すぐ必要な場合は、現状できることと、今後やりたいことがあります。現在は、ネットセントリックな方法で考える必要があります。つまり、特定のミッションに関与する連合国のグループを特定し、そのネットワークにアプリケーションを再展開し、それらの場所にエンドポイントを設置し、Cross-Domain Solutionを用いてデータのサブセットをその環境に送信してコミュニケーションを可能にするという流れです。

連合国の構成が動的に変化する状況では、現実的にスケーラブルな方法とは言えません。ある国が連合から離脱した場合、そのアクセスを解除して再設定する必要があります。これらの状況は突然始まることがあり、連合国を除外するわけにはいきません。日本の滑走路にF-35を置き去りにしたい人はいないでしょう。すべての国の能力を結集する必要があります。

情報ドメインレベルで目指すべき方向性は非常に重要です。ネットワークではなく、論理的な分離が可能になることです。これはZero Trustの中心的な考え方であり、セキュリティだけでなく運用面でも重要な理由です。これは初めて、セキュリティと運用が実際に一致する機会です。ネットセントリックな視点で15個のログインが必要な状況ではなく、同じセキュリティ分類レベルで1つのログインで済むようになります。これにより、Cross-Domain Solutionの一部を削除し、Identity Managementと属性によるエンタイトルメントを使用して、論理的な分離を始めることができます。

連合国のパートナーが従来のNo-Foreignネットワーク上のNo-Foreignアプリケーションにログインし、許可されたデータのみにアクセスして、それをその場で変更できるような、異なるユーザー体験を提供できるはずです。これが私たちの目指す方向であり、時間軸の問題だと言っているのです。今すぐ必要な場合は、従来通りの方法で提供する必要がありますが、これらの重要な技術を実装できれば、まったく異なる方法で実現できます。

論理的なセグメンテーションは、マルチテナンシーの観点からクラウドで長く推進してきたものです。USS Abraham Lincolnで連合国用の3つのラックを見たことがありますが、3セットのインフラストラクチャーのコストを負担しており、4つ目が必要になると、Pelicanケースを甲板に固定しなければなりません。これは南太平洋での台風救援活動のような災害対応の場合であり、実際の戦闘状況ではありません。5カ国との情報共有が必要ですが、軍事的な理由で機密扱いとなります。論理的な分離は、このような状況をスケールさせる唯一の方法です。NATOの32カ国を考えてみてください。32のネットワークを持つことは不可能です。まるで昔の電話交換手のように、誰かがケーブルを接続し直すことになってしまいます。

データが非常に重要なのは明らかですが、最終的にこの情報をどのように活用していくのでしょうか。この7、8年の間に、Machine Learning、Computer Vision、そして現在のGenerative AIの革命により、部門にAIが導入され始めています。まずLeoから、あなたが期待しているプロジェクトについて、また、ポリシー、技術的な障壁、人材、そしてこれらのツールをより効果的に活用するための推進力を得るために、まだ発展が必要な分野について話していただけますか。

各部門におけるAI実装の具体例と課題

Army、そして恐らくほとんどのサービスやDepartment of Defenseの当初のアプローチは、R&D担当者たちに全てを任せ、最終的に彼らが解決策を見つけ出すことを期待するというものでした。私はそれは選択肢ではないと言いました - とにかく実行するべきだと。CIOの観点から、私たちはネットワークを所有し、セキュリティ態勢を管理し、データの所在を把握しています。私たちは兵士たちや各司令部に対して、意味のある課題に取り組むためのデータを提供し、私たちが何に直面しているかを理解するための能力を実用化していきます。現在、最も取り組みやすいビジネス領域で多くのユースケースに取り組んでいます。法務部門は素晴らしい成果を上げており、特にLLMに関して契約部門や一部のミッション部門でも成果が出ています。

作戦命令の観点では、Army全体の規則を把握し、摩擦が生じている箇所や支援が必要な箇所を理解できるようにすることを考えています。現在、この分野で多くの取り組みが行われています。Latinoというプロジェクトがありますが、これは技術そのものよりも、顧客向けのLarge Language Modelを実現するための異なるアプローチを検討するという基本的な決定に重点を置いています。

一つのアプローチは「手取り足取り」バージョンと呼んでいるもので、商用製品を利用可能にし、クラウド上で生のプロンプトを使用しています。彼らは興味深い支払い方法を持っています。もう一つは純粋なCloud Nativeのアプローチです。Open AIは、CUIレベルの一部のデータに対して利用可能になっています。つまり、完全な機密情報ではありませんが、一般公開はできないものです。その他にも、システムインテグレーターを活用してカスタマイズされた機能を開発する取り組みもいくつか行っています。

これらの異なるモデル全体で機能を実用化するためにこのようなアプローチを取った理由は、ビジネスモデルを本当に理解し始めるためです。これを購入するのかどうか、それは非常に重要な問題です。全てのクラウドプロバイダーを見渡すと、それぞれが異なる課金モデルを持っていて、これは非常に興味深いことです。政府は同じものに対する異なる課金モデルの扱いが非常に苦手です。そのため、これがどのような形になるのかを理解する必要があります。

ビジネスモデルができたところで、次は実際の運用方法を決め、ユーザーが適切なガバナンスの下でシステムを利用できるようにする必要があります。技術者の私たちにとっては簡単に聞こえるかもしれませんが、初心者がこれらのプラットフォームを使おうとすると本当に難しいものです。現在、私たちが最も時間を費やしているのは、データの品質の悪さを理解することです。

モデルの構築を進める中で、Redditのデータでモデルをトレーニングすることは興味深いものの、私たちのミッションには何の価値ももたらさないことに気づきました。これは何を意味するのでしょうか?私たちは、技術の活用方法をより慎重に見直し、実際の課題に対応した、より焦点を絞ったモデルの構築に注力しています。そしてこのアプローチで、多くの成果が出ています。

データの観点から見ると、最初の大きな取り組みの一つは(これは少し面白いのですが)、Army内の5つの異なる指令部が、Armyが今まで作成したすべての契約データを取り込みたいと言ってきたことです。これは非現実的です。Armyとしてそのようなコストは負担できません。要件があるのであれば、データを一元化し、クリーンな状態で利用可能にして、私たちに適したモデルを検討しましょう。異なる技術でテストしたいのであれば、実施して比較評価すればいいのです。

重要なのは、今すぐ運用を開始することです。時間をかけて研究プロジェクト化するのではなく、組織全体で運用するための戦術、技術、手順を理解することが本当に必要なのです。産業界に対しては、このビジネスモデルについて考えるサポートが必要です。クラウドへのデプロイやSaaSの活用について基本的なことを話しましたが、現在、本当に摩擦を引き起こし始めているのは、Large Language Modelを統合したプラットフォームをSaaSとして提供することです。

いつも私を不安にさせる例を挙げましょう:採用活動にこれを使用する場合、エージェントが未成年の米国市民と会話をし、その人が不適切な質問をして問題のある回答を得た場合、その影響に対して誰が責任を負うのでしょうか?その関係性はどうあるべきでしょうか?これが、ポリシー面で次に検討しなければならない部分です。民間企業とのサービスレベル契約はどうあるべきか、誰が行動に対して責任を負うのかを考える必要があります。このスペースにいない人々や、顧客からのプロンプトを見たことがない人々にとって、これらのプロンプトは驚くべきものです。

面白い例をたくさん見てきましたが、ここでは声に出しては言えないものの、かなり笑えるものもありました。信じられないかもしれませんが、現存するソリューションのほとんどでガードレールは機能しています。この技術が最も適している領域の再定義が進んでいることがわかってきています。私は常々、そこに焦点を当てるように言っています。すべての問題がAIやML、Large Language Modelで解決できるわけではないのです。そのため、問題の振り分けと、最大の効果が得られる領域の特定に多くの労力を費やしています。

これは確実に人間の能力向上に関することです。つまり、最大の成果を得られる場所でこの能力をどう実用化するかということです。政府では常に効率性という言葉を使いますが、これは興味深い言葉だと思います。なぜなら、効果が伴わない効率性は無意味で、納税者のお金の適切な使い方とは言えないからです。私たちは、この技術によって業務の効果をどのように高められるかに重点を置いており、現在はそこに力を入れて取り組んでいます。

AIは今や野火のように広がっています。あらゆるアプリケーションが何らかの形でAIを統合しようとしているようです。私たちが自ら導入する場合でも、すでに所有しているアプリケーションのアップデートでも、AIが至る所に組み込まれることが私たちの生活の標準になりつつあります。私たちにはStar Warsをテーマにした「Red Force」というAIの卓越した組織があり、政府のリーダーシップの下、契約業者や優れたSMEたちによってサポートされています。Amazon SageMakerを使用して、DevOpsプラットフォーム上で非機密、機密、最高機密レベルでこれを組み込むことができました。

このチームは、誰かがAIを何かに振りかけてほしいと言ってきた時の振り分けを行います。時には単なる自動化が必要なだけで、自動化から得られる大きな利点もあります。しかし、AIが解決策になり得る場合、この中央グループには、私たちがすでに構築・購入したものすべてを集約したマーケットプレイスがあり、そこでユースケースを試すことができます。自分のデータを持ち込んで性能を確認し、うまくいけば、新しく何かを構築する必要はありません。それを一回限りのものではなく、通常のプロセスの一部として、ワークフローにどう統合するかを検討します。

新しいものを導入する必要がある場合、責任を持って安全に実施する方法と、Air Forceでの適用可能なユースケースの制限を検討します。私たちは多くのセンサーがある領域、つまり上空からの画像やフルモーションビデオなど、Computer Visionに注目しています。これらの活動ではNGAと密接に連携しており、私はGEOとDataとAIサブコミッティのコリーダーを務めています。私たちは、誰もが同意できる標準的な方法で信頼性を測定することに取り組んでおり、メタデータを渡す際には、単なる点ではなく楕円を取得して、エラーと重複する楕円を理解し、より良い信頼性の基準を確保しています。

Thumbnail 3300

Generative LLMのユースケースに関して言えば、インテリジェンスの分野では情報の捏造は避けたいので、非常にユースケース依存になります。最近私が携わった素晴らしい例として、ある上級幹部が、在任中に受け取ったすべてのブリーフィングやメモを後任者がアクセスできるようにしたいというケースがありました。要約や分析が可能な、インタラクティブな引継ぎ書を作成したいということでした。これは私たちが実現できる素晴らしいユースケースです。 私たちの場合、Generative AIの主要なユースケースは、需要計画、予測、サプライチェーンの混乱の分析です。AIに関しては、比較的標準化されたデータセットである調達分野に焦点を当てました。

DLAでは1日約10,000件の自動発注を行っています。これをサポートするため、入札不調の可能性を判断するAIモデルを作成しました。これにより調達時間やリードタイムの改善につながります。また、サプライチェーンの観点から潜在的な不正行為者を特定するためのAIモデリングも実装しています。

Leoが指摘したように重要なのは、すべてのケースがAIに適しているわけではなく、すべてのケースがGenerative AIに適しているわけでもないということです。多くの場合、人々は単に自動化を望んでいるだけなのに、誰かにGenerative AIが必要だと言われたからという理由で検討してきます。私たちは、解決すべき問題と求める答えは何かをモデル化し、それに基づいてデータの活用方法を決定しています。それがAIになるかもしれませんし、Generative AIかもしれませんし、あるいは別のソリューションかもしれません。

部門としてCenter of Excellenceを持つことで、AIユースケースの focal pointを持つことができます。DLAにとって難しい部分は、組織的にAIを受け入れる文化を作ることです。技術系でない人々は、AIという言葉を聞いた最初の反応として「何人の人員削減を考えているのか」と言います。私たちはDLAではAIを戦力増強の手段として捉えています。人員を削減するのではなく - ここにいる誰もが仕事を探しているわけではありません。むしろ、ミッションにとって重要でありながら、過去5年から10年の間に手をつけられなかった課題に取り組めるようになるのです。

AIプロジェクトが成果を重視していなければ、予算は枯渇してしまいます。私たちは基本的に予算を3年前に確定するので、何かを手放すか、予算の流れを変更するか、あるいはAIが注目される前に予算要求をしておく必要があります。これまでの成功事例は、主にMLを使用したHorizon oneのケースです。Harbingerは複数の車両の音響分析を行い、工数を削減し、レジリエンスを向上させ、作業方法を変革しています。Cyberに関しては、現在1桁の監視要員で8桁のイベントを処理できるようになっています。これは、そもそも採用が難しかったであろうポジションに対応できているということです。

現在、私たちは251のAIプロジェクトを抱えています。Death Valleyを乗り越えられるプロジェクトは、インパクトに基づいて優先順位付けされることになります。人材の観点からすると、データエキスパートとしてではなく、データドリブンな意思決定者として私たちを教育・訓練する方が容易だと考えています。政府機関と協力している企業の方々は、ぜひ無料の研修コースを提供してください。何十万人もの規模で考えた時、より良いデータドリブンな意思決定ができるようサポートしていただければ、私たちはより良い判断を下すことができます。

まとめ:政府機関のデジタル変革への貢献

本日はご参加いただき、ありがとうございました。これは非常に重要なトピックです。会場の中で部門と協力している方々には、私たちはミッションをサポートする立場にあります。興味本位で参加された方々は、オープンソースプロジェクトへの貢献やボランティア活動を通じて、連邦政府や国防省だけでなく、あらゆるレベルの政府機関に関わることができます。これこそが、私たちの国をより効率的で効果的にし、より良い市民サービスを提供することにつながります。モバイルアップでアンケートにご協力いただき、Public Sector Pavilionでは、チームが話し合った内容を元にしたAIとデータのデモをご覧ください。本日はご参加いただき、誠にありがとうございました。


※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。

Discussion