デジタル臨時行政調査会作業部会 テクノロジーベースの規制改革推進委員会（第3回）

概要

• 日時：令和4年（2022年）12月1日（木）10時00分から12時00分まで
• 場所：オンライン開催
• 議事次第：
  1. 開会
  2. 議事
     1. テクノロジーマップにおけるトラスト確保の仕組みについて（事務局からの説明）
     2. 荻野構成員からの説明
        • IoTセキュリティ対策への新たな取り組みのご紹介と一提案～認証製品へのラベリング（マーク制度）始まってます！～
     3. 国立情報学研究所 石川冬樹准教授からの説明
        • AI品質へのアプローチ紹介
     4. 意見交換
  3. 閉会

資料

• 議事次第（PDF／235KB）
• 資料1 テクノロジーマップにおけるトラスト確保の仕組みについて（PDF／1,052KB）
• 資料2 IoTセキュリティ対策への新たな取り組みのご紹介と一提案 ～認証製品へのラベリング（マーク制度）始まってます！～（PDF／2,260KB）
• 資料3 AI品質へのアプローチ紹介（PDF／2,126KB）
• 議事録等（PDF／1,543KB）

議事録等

開催日時

令和4年（2022年）12月1日（木）10時00分から12時00分まで

場所

オンライン開催

出席構成員

座長

江崎浩（デジタル庁 シニアエキスパート（アーキテクチャ））

構成員

• 岡田 有策（慶應義塾大学理工学部管理工学科 教授）
• 小川恵子（EY ストラテジー・アンド・コンサルティング株式会社 バンキングキャピタルマーケットリーダー レグテックリーダー パートナー 公認会計士）
• 荻野司（一般社団法人重要生活機器連携セキュリティ協議会代表理事）
• 川端由美（自動車ジャーナリスト）
• 島田太郎（株式会社東芝 代表執行役社長 CEO）
• 鈴木真二（公益財団法人福島イノベーション・コースト構想推進機構福島ロボットテストフィールド 所長 東京大学未来ビジョン研究センター 特任教授）
• 豊田啓介（東京大学生産技術研究所 特任教授）
• 中垣隆雄（早稲田大学理工学術院創造理工学部 教授）
• 中村修（慶應義塾大学環境情報学部 教授）
• 永井歩（アスタミューゼ株式会社 代表取締役社長）
• 根本勝則（一般社団法人日本経済団体連合会 参与）
• 登大遊（独立行政法人情報処理推進機構サイバー技術研究室 室長）

概要

須賀参事官： それでは、時間となりましたので、第3回目の「テクノロジーベースの規制改革推進委員会」を開会させていただきたいと思います。

今回も構成員の皆様は、オンラインでご参加いただいております。
また、本日は、議事進行上、前半に説明、後半に意見交換とさせていただいておりますところ、前回はSlackとWebexを併用させていただきましたが、結局、Webexのほうが使いやすいようでしたので、今回は、可能であればWebexのチャットを活用しまして、ご説明の間にもコメントがあればぜひ投稿いただければと思います。
では、これより本日の議事に入らせていただきます。

進行は江崎座長にお願いいたします。よろしくお願いいたします。

江崎座長： それでは、第3回の議事といたしましては、テクノロジーマップにおけるトラスト確保の仕組み、認証製品へのラベリング制度によるIoTセキュリティ対策、AI品質へのアプローチ紹介の件を予定しております。

そして、最後に、まとめて構成員の皆様からご自由にご発言いただく時間とさせていただければと思います。
それでは、まず、事務局の須賀参事官のほうから「テクノロジーマップにおけるトラスト確保の仕組みについて」のご説明をお願いします。

須賀参事官： ありがとうございます。
前回は、テクノロジーマップに収載すべき情報などについてご議論いただきました。今回は残る論点の中から、トラストの確保について、1つの主体で全てはカバーできないと思いますので、どういった方々にどう関与していただきながら行っていくのが適切かということをぜひご議論いただきたいと思っております。

資料のほうを参照ください。

1ページ目、2ページ目はこれまでの議論のまとめでございますので、飛ばさせていただきまして、4ページに今回の論点としまして「テクノロジーマップ掲載技術のトラストを確保する仕組み」と書かせていただいております。

まず、6ページで大きな枠組みの振り返りですけれども、テクノロジーマップや技術カタログは、規制所管省庁や規制実施団体、規制の対象事業者等によって、具体的に調達や、それができるような規制見直しまでつなげていただきたいと思ってつくっていくものですから、当然、そこに掲載される情報には一定の真正性、真実性（トラスト）の確保が求められる。

他方で、右側ですが、悩みは、技術保有企業から誤った情報、古い情報、虚偽の情報を、公募で応募いただくことも含めて、申告される可能性は常にあると想定するべきだと思いますが、そういった情報を事務局のほうで完全に事前の検証をするということは、コスト面でもスピード面でも、それから、専門性を考慮しても非現実的であると感じております。

その中で、テクノロジーマップ自体は、技術が進展しましたら、どんどん最新の情報が迅速に収集され、掲載され、更新されていくといった生きたものにしていかなければ、そもそも有用でないということでございますので、こういった右側の要請を踏まえながら、どうやってトラストを柔軟に確保していくかということが今回ご議論いただきたいポイントでございます。

次のページの左側のように、前回、まず、トラストの確保の仕組みの大きな前提として、このカタログというのは参考情報なのですよと少し引いたスタンスでご説明した上で、ただし、規制所管省庁としっかりと対話をして、一体何が遵守の必須要件なのかということについては、なるべく細かく設定していくことによって、達成していただきたい精度、水準を明確化していく。

それに加えて、各種の第三者認証のようなものについて、しっかり取っているテクノロジーだということがアピールいただけるようにする。それが全体にとって不可欠であれば調達要件に盛り込む判断もしていくことによって、この積み重ねでトラストを確保するというのを基本的な枠組みとしてご提案させていただきました。

さらに、本日、踏み込んでご検討いただきたい点が2点ございます。まず1つ目が、一番上の技術カタログは参考情報ですよということも含めて、テクノロジーマップを使ったり、つくったり、直接関与する主体それぞれが、掲載された情報の利用等に関してどういった責任を分担していくのが正しいのかということ。

それから、2つ目が、トラストとか品質保証、前回、島田構成員からクオリティーアシュアランスということでご説明いただきましたが、こういった枠組みの構築や運用を、上に挙げた責任を直接分担するテクノロジーマップに関与する主体以外の専門性の高い外部機関などから、柔軟にご支援を得ることができるのかどうか。これは各種の認証に言及していくということも含めてですけれども、そういった可能性についてご議論いただきたいと思っております。

まず、1点目です。次のページになりますけれども、まず、少なくとも私たちが現在このような考え方でマップをつくっていますということについては、テクノロジーマップやカタログを正式にお出しする際に、ある程度しっかりと言語化し、マニュアルのような形でしっかり併せて公表する必要があるのではないかと考えております。

具体的には、このマニュアルの中に書いていくことの例として、まず、現在、テクノロジーマップの運営主体と想定されているデジタル庁では、機械的に処理できる形式上の要件はしっかりとチェックします。例えば、前回ご紹介した例でいいますと、まだリリースされていない、現在は存在していないという技術、サービスについては、公表情報などを踏まえてしっかりチェックした上で公表していく。

規制所管省庁に関しては、まず、必須の性能要件を含め、規制の遵守状況についてどういったことを判断材料・判断事項として持っているか、チェックリストとして持っているかということはなるべく事前に明確になるように、規制項目の精緻化に協力をしていただく。それから、後でご説明しますが、技術利用者の責任において、ここに載っている技術をなるべく採用できるように規制を見直していただく。この2つが規制所管省庁に期待することであろうと思います。

3つ目が、技術を実際にお持ちで、ご提案いただいてカタログに掲載いただく事業者の方々ですが、掲載情報に対しては、この方々が一義的な責任を持っていただく。ただし、ニーズとのミスマッチを避けるべく、前回の議論のように、留意事項として、こういうことはできませんよとか、こういった使い方は駄目ですよということは書ける範囲で書いていただく。それから、古い内容についても、しっかりアップデートしていただくということについて、ぜひ責任を負っていただきたい。

それから、虚偽の情報を意図的に掲載するなどの不当・不正な行為に関しては、事後的に何らかの措置があるということを甘受していただく。これは間違った情報がございましたという修正のメッセージを公表させていただくとか、一定期間、テクノロジーマップ自体への掲載を、ほかのテクノロジーも含めて停止させていただくとか、いろいろありうると思いますけれども、そういったところのご議論をいただければと思います。

そして、具体的にマップやカタログを参照していただく規制対象事業者等に関しては、まず、個別の技術の採用については、技術利用者の方々の責任において行っていただく必要があるいうことは明確に書いておく必要がある。それから、マップやカタログを参照いただいて、おかしいな、ほかに書いてあることと違いました、実際に使ってみたらおかしかったですということはぜひフィードバックをしていただくということを期待したい。というのが、これまでのご議論を踏まえての現時点の事務局のスタンスでございますけれども、ここは違うのではないかというようなことは、この後、ぜひコメントいただければと思います。

本日の論点2点目でございます。前回、テクノロジーマップや技術カタログのトラスト確保に向けて、整備プロセスを4段階でご説明させていただきましたが、それぞれにおいて専門性の高い外部機関のレビューやアドバイスを受ける仕組みを、アドホックに事務局が思いついたときにご相談ということではなくて、仕組みとして関与していただくことができないかと考えております。

まず、左側で、規制の類型化とか、抽出した規制類型について技術探索を行っていくフェーズに関しては、この分野については一定程度の技術が出てきていますね、確立していますね、そろそろ使っていただけるのではないでしょうかといった領域や類型の抽出に専門的な知見がぜひとも必要だと感じております。

2つ目が、性能要件については、当然、当局と対話しながら、前回の講習でいえば、なりすましは困るとかいったことも含めて設定していくのですけれども、それをどうやって正しい性能要件の設定に落とし込んでいくかということについては、品質評価の指標を踏まえた測定基準の設定とか、準拠すべき標準規格、取得すべき第三者認証の特定などについて専門家のご意見が反映されるような形を確保したいということでございます。

プロセスが進みまして、技術検証が必要だ、つまり、技術が存在しそうだけれども、性能の確認が必要だと判断された場合に、探索された技術について、性能が十分といえるかという品質の検証と評価に進むわけですが、ここに関しても、今はそれぞれの規制当局が技研等と協力してそれぞれ確認しているということですが、なるべく横展開をして幅広く、この範囲であれば同じような検証でいけるということもマップに反映していきたいと思いますと、ここも専門性の高い第三者にご協力いただく可能性がないかということをぜひご議論いただきたいと思っています。

具体的には、当局が求めるシステムについて、それが設計どおりにできているのか、当初の目的は達成されているのか、そもそもこのサービスをリリースしたときに、世の中に出したときに、技術利用者である調達者が困らないかということを誰かが客観的に確認してくださるということがあれば、ありがたいなと思っております。

最後に、この技術検証もパスしますと規制を見直していただき、実際に規制を遵守する対象事業者の方々が技術の調達をしていくという段階になりますが、技術の採用に当たって、トラスト確保策として具体的に業界団体が作成する技術利用や運用の際の注意点などをまとめた文書を参照していただく。場合によっては新たな創設的な規制の話もしなければいけない可能性がある。ここについても、アドバイスを頂ける体制がぜひ欲しい。このあたりは、前回、島田構成員からご紹介いただいたQA4AIを中心的にまとめていらっしゃる石川先生から、このあと詳細をご紹介いただくことになっています。

それから、実際、マップを参照して技術を調達していただいて、具体的に不具合が発生したときに、フィードバックをかけていただくだけではなくて、インシデント対応も含めて、保守・運用の支援というものもどなたかから頂けるようであれば、ありがたいと考えております。

次のページは、前回、テクノロジーマップに収載するべき情報を表で幾つかご説明させていただきましたが、今回のトラスト確保という観点を加えまして、少し追記してみました。

太字が追記した部分でございますが、まず、規制遵守の必須要件は、規制所管省庁に対話の中で具体化していただいて、さらに制度運用中にフィードバックをしていただくわけですが、ここに専門性の高い外部機関等が登場していただき、さらに精緻な性能要件を設定するお手伝いをしていただけたらありがたいということになると思います。

それから、制約条件や使用上の注意点に関する情報というのも、前回のご提案では技術保有企業に留意事項を表明してほしいというところで止まっていまして、さらに、それがなかなか難しいので、規制所管省庁が使ってみてどうだったというコメントをフィードバックいただくという話になっていましたけれども、トラスト確保の観点を加味しますと、規制所管省庁が御自身で出されているガイドラインなどを参考文献としてしっかり指定するということ。

3つ目に、テクノロジーマップの運営主体が外部機関のご支援を受けまして、こういうものを参照してくれると役に立ちますよ、理解が深まりますよ、このテクノロジーの特性をよく理解して使っていただけますよというような文書を参照するなり、登構成員にご提案いただいたように、解説記事を出していくということになるのかなと考えております。

本日、事務局からご相談したいのは以上の点でございまして、この後は残る論点ということで前回のご議論を踏まえて青字で追記しておりますので、参考にご覧いただければと思います。

以上です。

江崎座長： どうもありがとうございます。ご説明ありがとうございました。

それでは、この件に関しまして、続きまして「認証製品のラベリング制度によるIoTセキュリティ対策について」、荻野構成員からご説明をお願いいたします。

荻野構成員： 聞こえていますでしょうか。

江崎座長： 大丈夫です。

荻野構成員： 画面を共有させていただきました。それでは、お時間を15分頂きまして、少しご説明させていただきます。

まず「第三者認証制度に求められる条件の比較」の話を少しさせていただきます。

ISO15408というのはコモンクライテリアで、これはよくコピー機などで使われています。

我々はこの4条件をつくりました。1つ目は、分かりやすいか。2つ目は、信頼できるか。3つ目は、普及しやすいか。メーカーがちゃんと使えるか、低コストかということです。4つ目は、新攻撃に追従しやすいか。この4点をつくりました。残念ながら、コモンクライテリアというのは高い製品には良いのですが、低価格なIoT機器には少し不向きだというのが我々の会員さん、メーカーさんの意見です。

一方、数千円から数百万円までのIoT機器というのは結構いろいろあるのですが、その中でどのような標準化が進展しているか？この図では、日本と米国と欧州を2017年からその活動概要を示しています。

米国は、特にコロナになってからの2020年頃からIoT機器に対して、できるだけハイジャックされないように、活発にいろいろなガイドラインを出しています。最近では2021年、ExecutiveOrder（14208）では、コンシューマー機器に対してセキュリティにおける品質を担保するための制度に関する大統領令が出ました。

2022年にNISTのIR8425にてファイナルドラフトとして完結しているのですが、ここで消費者向けのIoT機器の最低限の要件、日本語では「最低限」と書いたのですが、英語では「baseline」と言っています。来年4月には、ある程度、一定線の要件を合格していれば、ラベリングしていきましょうという施策を進めています。米国の記事によると、エナジースターのような省エネのレベルに応じてマークを貼っていく、星を取っていくという制度のような形に、IoT機器に対する一定基準を満たしたものについては、何らかのマークを貼っていこうという動きです。

一方、ヨーロッパは規制が中心になってくるのですが、最初はゆっくりとしていました。サイバーセキュリティ認証フレームワークの導入検討を2017年に発案してから、英国からベストプラクティスとして、コンシューマーIoT向けセキュリティ行動規範13箇条が出て、これをETSIでEN303645として一定の要件を決めています。その要件を達成するためのテストシナリオをETSIではTS103701として出しています。

あくまでも規制ではありませんでした。このような要件でこういうテストをすればいいですよという、ガイドラインとして示していました。先々月、サイバー・レジリエンス法案として、一定の基準を満たさなければ、欧州の中では売ってはいけない。という内容の施策案が出てきました。これが世界の流れです。

ヨーロッパの中では欧州電気通信標準化機構（ETSI）と欧州ネットワーク情報セキュリティ機関（ENISA）がありますが、ETSIでまとめている内容とENISAとではイコールではないのです。

さらに、ENISAでは、「CybersecurityCertification:CandidateEUCC」、コモンクライテリアをベースにIoT機器のサーティフィケーションを進めていますが、レジリエンス法案が出て、別の流れができています。これが右側です。

したがって、ヨーロッパはETSIとENISAがあり、ENISAの中でも2派があって、まだ混沌としている状況です。混沌としている状況なのですが、フィンランド、オーストラリアがこのETSIの要件を使って認証していこうという動きもあります。

米国は、先ほど言いましたように「BaselineSecurityCriteria」というのを大統領令にもとづいて策定しています。皆さんもご存じのように、もともと政府調達の基準というのはNISTで定義されているのですけが、それとは別にIoT機器に対しては、このようなベースラインという基準をつくり、消費者に対して注意を喚起しながら、マークを貼っていこうという動きがあるのです。

右側に日本がありますが、日本も頑張っていまして、総務省と経産省の両省庁でつくったIoTコンソーシアムの中で、IoTセキュリティガイドラインというのを2017年につくっています。これが先々月ぐらいに、55年かけてISO27400として標準化されました。これは、IoT機器に対してこんなことを守ったほうがいいですよという方針です。標準化で頑張っていただいた皆さんに敬服します。

ISO27400は、標準化されてようやくテイクオフしたのですが、その系列でISO27402というものが検討されています。これは米国が提案しており、具体的な施策としての要件を示す内容のようです。米国のベースライン要件がそのままスライドしている内容のようです。これはまだ標準化されていません。

この図では記載されていませんが、ISO27404としてラベリングに関する提案も検討されるとのことです。

ここで説明した欧米の要件は、ほぼ変わりません。ヨーロッパが提案してきている内容も、アメリカが提案してきている内容も、それから、我々CCDSがメーカーさんと一緒につくった要件も実はあまり変わりません。

日本案は日本のメーカーや消費者にとって最適に設定すべきであろうと我々は思っていますが、あまり要件は変わらないので、多分、技術マップで議論されている中で、日本として、このぐらいのセキュリティ要件が必要だろうということを設定してもほぼ大丈夫だろうと思っています。

ただ、ポイントは、ヨーロッパは規制しようとしています。アメリカはあくまでも要件を提示して、民間に任せようという動きなのです。重要なのは、経年変化するセキュリティなので、要件・適合基準というのは鮮度が重要だということです。ISO15408のように時間をかけながら要件を作っていくという流れよりも、毎年、セキュリティの環境は変わりますので、柔軟にアップデートできる仕組みをきちんと作るべきだと思います。

米国では、NISTから、そういう認証スキームについては、非営利組織で柔軟に動けるような体制がいいのではないかということが書かれています。もちろん、これは政府がやってもいいし、民間がやってもいいとしています。

標準化されているISO15408は、プロセスチェック重視なので、ドキュメントチェックが多く、認証にかかるコストが高いと言われています。IoT機器に関しては、軽い検査プロセスが重要です。ただ、米国が進めている内容も、ヨーロッパが進めている内容も、自国というか、自分たちの組織の中で重要な認証プロセスや適合基準をつくっています。日本としても、適合基準は我が国で作成することが重要だと思います。

次に社会実装です。標準化しても使われない標準化というのは山のようにあります。使われることに意味があって、メーカーが賛同し、消費者が受け入れるような双方のインセンティブが重要であるということです。この技術マップでもそうですが、皆さんが使いたいようなアプリケーションとか手法への認証スキームの適用は、それを提供する側と使う側の双方にメリットがなければいけないでしょう。

また、認証スキームに関しても、第三者認証が重要なのか、自分たちで検証したほうがいいのか。自己検証とか、自己認証とか、自己宣言とか、いろいろ言葉はありますが、使われることに意味があり、メーカーが賛同し、消費者が受け入れられるほうがいいだろうと思います。

これはCCDSの活動詳細なので、今日は時間の関係で飛ばしますが、各分野に応じていろいろなことを考えてきました。

この図は、我々の社会実装の流れなのでちょっと省きますが、2018年から2023年まで、適時、要件を柔軟に変更しながら活動をしてきました。という内容です。

我々は、民間で活動していますが、できればこういう案がいいのではないかという内容を策定しています。インターネットにつながるような機器は、最低限のマナーというものを設定すべきであると考えています。米国と考え方は似ています。

一方で、業種毎には、いろいろ要件が変わってくると思いますので、最低限つながる時のベースライン要件はつくるべきだけれど、業種ごとにいろいろなセキュリティ要件を積み上げるべきだろうという考え方になっています。

CCDSの制度は、最低限守るべき要件を満たした機器としてマークを取得した場合には、サイバー保険も一緒に自動付帯する制度です。車の自賠責保険のような制度設計としています。保険会社は、三井住友さん、東京海上さん、損保ジャパンさんという3つの保険会社が組んで頂き、認証マークを貼ってある全ての機器に対して保険を適用していただけます。

インシデントが起こったときにそれを調査することがとても重要です。何かが起こったときのトラッキングを実施することです。これを公的資金でやるのも問題がありますし、個人で負担できるか。メーカーが負担するというのも大変です。そこを保険でカバーしようという制度設計としています。

この図では「認証スキーム（CCDS版）」を示しています。民間による認証スキームオーナーであり、経年変化するセキュリティに対応していきますとか、消費者への購入時支援やメーカーへのインセンティブとしてラベルを貼っていくという内容です。

次に、大きな会社では品質保証本部などがありますので、自己検査で実施するとか、中小企業に関しては、第三者検査できるような仕組みを作っているという内容です。

我々はIoT機器に対する認証制度を自前で実施していますが、参考として、IPv6ReadyLogoというプログラムがあります。この認証スキームは、IPv6につなげる機器に対しての認証を民活で進めています。こういうことが実際に民間でもできており、我々もIoT機器に対して民間でこのような認証スキームを進めています。

社会実装としての取得実績は、例えば、スマートハウスのような住宅のデベロッパー、住設機器メーカー、金融系のATM、コンビニで使われているPOS端末などが認証スキームを利用していただいています。

この図は積水ハウスのスマートハウスの例ですが、スマートハウスまるごと、マーク・認証スキームを使って頂いています。そこで使われる機器に対しても最低限の星1つを取って頂いています。さらに、少しレベルの高い要件は星2つを取って頂いています。

このように、セキュリティに対しては今まではコストだと思われていましたが、投資として考え、さらに、この認証スキームによるマーク取得をブランドとして扱っていくようなビジネスを進められています。マークを貼っていくことによって、消費者に対して、スマートハウスは利便性もあるけれども、しっかりとしたセキュリティも最低限担保しているということを示しながら、スマートハウスのブランディング戦略として活用して頂いています。

まとめです。セキュリティ要件の整理と情報提供に対しては、認証スキームのベストプラクティスを公開することで、日本が積極的に世界へ貢献できるのではないか。

さらに、認証スキームの運用経験の共有です。つまり社会実装を進めることです。やはり使われることに意味がある。ラベリング付与という施策を米国では進めていますが、技術マップへ認証・検証マークの掲載を進めたらどうだろうというのが提案です。

検証体制に対しては、セキュリティというのは経年変化するので、柔軟に要件・適合基準をアップデートできる仕組みが重要でしょう。

KPIからKGIへという文脈でいうと、技術適合基準は我が国として作成することが重要です。これは経済安全保障という考え方です。また、ZEH（ZeroEnergyHouse）、スマートハウスという流れの中でも、エコでかつ安全です。というのをブランディングに使っていくことができると思います。

技術マップでは、例えば、ISO27000を取っているとか、ISO9000を取っているとか、民間で我々がやっているような認証スキームによってマークをも取得しているとかを掲載することで、使う側への一つの指標として良いのではないかと思います。

以上でございます。

江崎座長： 荻野構成員、ご説明をどうもありがとうございました。

前回の委員会で議論し、製品の品質保証の関係として話題となりました件に関して、今回、ゲストとして国立情報学研究所の石川准教授をお招きさせていただいております。

それでは、続きまして、国立情報学研究所の石川准教授のほうから「AI品質へのアプローチの紹介」について、ご説明をお願いいたします。

石川先生： ありがとうございます。国立情報学研究所の石川と申します。

私は、ソフトウエア工学というか、ディペンダビリティ、頼れるソフトウエアみたいな、品質みたいな研究をしているのですけれども、この3年、5年ぐらいは産業界のほうから自動運転であるとか、AIの品質をどうするのだという問合せをたくさん頂いていまして、それに関する研究をしたりとか、産業界の方々と一緒にガイドラインを書いたりという活動をしている人間です。

今日は、いきなりなので、文脈がずれるところがあるかもしれませんが、その辺の話をご紹介させていただいて、議論のネタにしていただければと思います。よろしくお願いいたします。

私は、ざっとお話を伺ったぐらいなのですが、今回のお話だと、医療でも道路でもいいのですけれども、何とかAIというものが技術としてあるときに、今までは人を相手にしていた規制を撤廃できるかとか、見直せるかというところで技術の評価をするという必要があって、トラストが十分か評価するとか、技術全体としてはレベルが十分だと思うのだけれども、一個一個のプロダクトに対しては何かしらちゃんとしてもらわないと困るみたいなこととか、そういう2段階あると思っています。

私が今日お話しするのは、今、AIのプロダクト・サービスのそれぞれに対して、こんな評価をするといいよということとかがガイドラインでまとまっていますので、それをご紹介して、これは個別のプロダクトの話なので、技術領域全般を評価するときにはどうしていくのかというのは、また今後、議論いただければなと思います。よろしくお願いします。

そもそもソフトウエアの世界とかだと、典型的に政府とか、IPAさんみたいなところがまとめている品質の考え方というのはどんなものかというと、結局、品質というのがいろいろあって、従来のソフトウエアだと、どれだけ動き続けるのか、サービスダウンがないかという可用性、どれだけ早く返事が来るかという時間性能、測り方は応答時間とか、どれだけ多くのデータを使えるかは空間性能で、測り方は最大受容データ量みたいな形で、品質特性みたいな言い方をするのですけれども、セキュリティとか、プライバシーとか、とにかくいろいろな種類の品質があります。これをちゃんと分けましょうというのがスタート地点です。

あとは、今回考えているシステムがどれだけ大事なシステムかという話もあって、単純な分け方だと、社会的影響の大きさみたいなもので分けたりしますけれども、もっと細かに、人の生死に関わるかとか、いろいろな分け方があるかなと思います。

ガイドラインの話ですけれども、この辺を個別に判断していると大変なので、こういうものはガイドラインが決めてくれるとうれしくて、こういうシステムでの分け方と品質の分け方をガイドラインが決めて、かつ、例えば、社会的影響が多いのだったら、1年間に数分しか止まってはいけないよみたいなことはおおよそ典型的に決められるので、そういうことを決めてくれるという感じです。

ただ、ものによっては分野にすごく依存して、所要時間というのは5秒でも速いというケースと、何マイクロセカンドみたいな話もあるので、標準としてはその辺はちゃんと決めてくださいねぐらいしか言えないこともあります。

こういうものがあるからこそ、一個一個のプロダクトを評価するときに、今回はこういうシステムだからこういう評価をしなければいけないよねというのが決まってくるというのが従来のソフトウエアの話でした。これがISOの何なのかとか、非機能要求グレードというIPAさんが出しているものとか、あまり細かいことは出していないのですけれども、こういう考え方が昔からありました。

これがAIになるとどうするかということなのですが、AIと言っているのは機械学習という技術を使っているもので、今まではイートインだったら税率幾ら、テイクアウトだったら税率幾ら、では、こうやって合計金額を出しましょうという仕様書みたいなものがあって、それからプログラムをつくっていたのですけれども、そうではなくて、正解を示したデータがある。この例だとここに映っているのは歩行者とか、この例だとここに映っているのはトラックだとか、画像だったら、そういった形で正解が10万件とか、100万件とかたくさんあって、それを基に識別機能をつくれるというのが機械学習というやり方です。

これがこの5年ぐらいでいろいろな産業応用が出てきたので、ここでも話題になっていると思うのですが、つくるのは簡単なのだけれども、まさにここと同じ話で、製造業のお客さんとか、そういった方々が、とはいえ、従来みたいにちゃんと品質というのをやってくれないと使えないよという話になって、では、どうするかということで、世界に結構先駆けた感じで国内では2つのガイドラインが出ました。

ちょっとややこしいのですけれども、AIQM（クオリティーマネジメント）というものと、QA4AI（クオリティーアシュアランス）というのがあります。

AIQMは経産省系のプロジェクトで、産総研さんを中心にトヨタさん、日立さん、富士通さんなどの企業も入ってつくっています。こちらは結構標準とかを見据えて、多分、10年後もこの型で通じるだろうということをしっかり書いていく感じで書いています。

2つ目のQA4AIのほうはボランティアベースなので、今は70社ぐらいいるのですが、実際の現場の方々が書いているので、正直、ちょっとごちゃごちゃしているところはあるのですけれども、具体的にこうするみたいな事例を結構いっぱい載せているガイドラインになっていて、現時点ではマージというよりは、すみ分けてやっているという感じになっています。

ただ、それらは抽象度がすごく高いので、それぞれいろいろな応用領域ごとにサブガイドラインみたいなものを出していて、AIQMだと、プラントを見張って配管の腐食などを見つけるようなAIだと、こういう品質をチェックしなければいけないというのを書き出していますし、QA4AIだと、例えば、スマートスピーカーみたいに言葉でコマンドを与えるようなものだと、こういうチェックをしたほうがいいとか、銀行などで文字を読み取るというケースだと、こういうチェックをしたほうがいいとか、そういうことをサブガイドラインで書いています。

この辺はホットトピックなので、いろいろなものがあるのですけれども、この2つを見て、全然違うことがほかで言われているということはそんなにないのかなと思っています。

どういう内容が書いてあるのかというのを、すごく簡単にですが、まず、1つ目の産総研のAIQMですけれども、何とか性、何とか性、何とか性という形で品質特性を整理していて、AIの場合だと、基本的に予測とか推測みたいなものなので、90％当たるみたいな話がパフォーマンスとして大事ですよと。ただ、それだと、外している10％で大事故が起きるみたいな話は扱えないので、どういう間違いがまずいのかを考えましょうというのがリスク回避性であります。

AIの場合、人事とか、ローンの審査とか、そういうところだと、性別とか人種によって結果が違うという話が問題になっているので、公平性というのは一つの指標にしましょうということで上がっています。

それらを目標として、開発者側でチェックすることとして、問題をちゃんと解きほぐしたか。例えば、自動運転だったら、山道を考えなければいけないとか、逆光を考えなければいけないという話があるわけで、それをちゃんとやったか、それに対してちゃんとデータを集めているか、センサーが壊れていることがないか、つくったAIがそれに対してちゃんと正解を出せているのか、運用時に使っていくうちに傾向が変わって劣化することをちゃんと考えているか、そもそも訓練に使うプログラムは合っているか、正しいものか、バグはないかという話に分割してやっているというような感じです。

なので、これは実際のチェックリストみたいになっていて、リスクが高いケースに対してデータを十分集めましたかとか、例えば、そんな感じの質問が並んでいるような感じになります。

こちらも先ほどあったようにレベル分けがあって、人が死ぬケースだとここまでやるべきだとか、パフォーマンスがこれだけ重要なケースだと、これをやるべきだみたいな感じで、必要なレベルがこれだけなので、下のほうで実際に開発組織がやるプロダクトのチェックもこれだけ厳しくやるべきだという形でレベル分けがされています。

この辺は付録なので、もしご質問があればということです。

では、QA4AIのほうはどうなっているかというと、ちょっとかぶる感じではあるのですけれども、こちらもチェックリストという形で出しています。

こちらはデータに対するチェックリストと、モデルと言っているのは、いわゆるAIというか、予測機能を持つような部品のチェックリスト、あとは、システム全体のチェックリスト、この3つが開発組織から出てくるプロダクトの一部というか、プロダクトをつくるための構成要素という感じですが、それと、開発組織がちゃんとしているかということと、そもそもこのプロダクトにどれだけ強い期待がかかっているかということもチェックして、なので、これは5個あるのですけれども、上の4個が開発組織というか、プロダクトを送り出す側の話で、それを受け止めるステークホルダー側の話もちゃんと分析して、4対1で照らし合わせましょうということを言っています。

チェックリストのあまり細かいところを読み上げてもしようがないのですけれども、結局、先ほどと同じような感じで、データがちゃんとしているか。自動運転だったら、山道とか逆光などのいろいろなデータをちゃんと含めているのか、男女で女性のデータだけが極端に少ないということがないかといったことを見なければいけないというのがデータの話で、それに対してちゃんと正解できるか、男女間の偏りはないか、ノイズを入れただけですぐ外すようになってしまわないかということが、AIというか、予測部品の品質となります。

ただ、これとシステム全体の品質は違っていて、遠くの歩道上にいる歩行者を見落としても、別にぶつかることはないので、システム全体の品質と、一応、機械学習技術で作った部品の品質というのは、深くつながっているのだけれども、2段階、別のものなので、ちゃんとシステム全体のことも考えましょうと。

例えば、広告とかだと、過去のデータに対して正解できるといいのだけれども、結局、それでクリックしてもらえるのか。だから、例えば、広告でKPIなのだと思います。なので、そういう分野ごとのKPIとか、使う人の納得みたいなことも含めて考えましょうというのがシステムの品質です。

基本的にAIというか、機械学習を使う場合だと、不確定要素がすごく多くて、状況が変わって当たらなくなったり、データが増えていくと、どうも今まで持っていたデータと変わってきたみたいなことがあったりするので、組織側は、どちらかというと、ドキュメントをちゃんと残すとか、そういうことも大事なのですけれども、変化に対応できることがすごく大事だということで、そういう組織にちゃんとなっていますかと。つまり、いろいろなことで人手が入っていて、一々何か月もかかっていたら、とてもAIではやっていられませんよということで、組織を評価する指標も入っています。

以上に対して、実際に利用者とか、利用者を代表する発注者とか、会社側から見ると顧客と呼ぶのですが、そこの期待の高さとか、90％しか当たらなくて、10％は外すということに対してどうやって皆さんが受け止めているかということとか、ちょっと主観的なことも入ってくるのですけれども、そういうことをしっかり聞いておいて、今のAIができないことを期待しているのだったら、できないと思ってもらうことも必要だし、あるいは失敗したときにちゃんとカバーするような仕組みを考えるとか、そういうことが必要だったり、関連する規約を洗い出しましょうみたいなことを書いてあるという感じです。

ヨーロッパのほうも幾つか出ていますが、ヨーロッパも似たような話ではあるのですけれども、入り口が全部、人権とか人の尊厳になるので、究極的にはSFみたいな感じですが、緊急停止ボタンがあるみたいなことも書いています。

なので、そういう人権みたいな観点から、結局、でも、ちゃんと当たるとか、安全であるとか、セキュリティがちゃんとしているとか、人が納得して使えるとか、AIが外すときには外すというのが分かりやすくなっているとか、そういうことを重視したり、なので、もしかしたら、ガバナンスとか倫理みたいな言葉にはなっているのですけれども、ヨーロッパのほうはそういう言い方で出しています。これも中には、軽くですけれども、チェックリストがある感じです。

あと、ヨーロッパはこの中で特に難しい領域を挙げていて、間違ったりしたときに社会的影響が大きいとか、人権にすごく関わるので、この辺はすごく注意をしなければいけないということで、高い注意を払っていろいろな観点でしっかりやってくださいよみたいなことを提言していたりします。

ということで、私から簡単にご紹介させていただいたのは、従来のソフトとか、AIになっても、結局、これだけ大事なシステムだからとか、この点がこの領域では大事みたいな話がまず整理できなければいけなくて、それに対して評価する。機械学習を使ったAIの場合だと、訓練や評価に使うデータを評価するというのと、生存が当たるか、当たらないかという評価があるのと、システム全体としてうまくいくかという、基本的には大体3つの評価が要りますよということでした。

なので、一個一個のプロダクトの話をするときには、例えば、こういう間違いは困るみたいな世界なのか、ちょびちょび間違えることがあっても、1か月使ってみて蓋を開けてすごくよくなっていればいいのかという、極端にいえば、こういう2つのケースがあって、自動運転とか工場で使う場合と、広告配信とか売上予測で使う場合では実は求められるものが違うので、その辺を整理する。

もしも前者だったら、例えば、逆光で山道というのは難しそうだなと思ったときに、それに対応するような学習データがあるのかを出すとか、そのときにちゃんと当たっているかというのを見なければいけないという話がある。

AIの場合は、基本的に不完全で不確かだということが大前提なので、決して100％を求めるという話ではなくて、リスクがある前提でリスクをカバーできるような仕組みが人間のほうでとれるのかとか、だったら、AIというのは厳しく見なくてもいいのではないかとか、そういう議論をすることが大事な領域になっています。

ちらっと聞いたぐらいであれですが、こういうプロダクトごとの品質尺度みたいなものはチェックリストとして結構行き渡ってきているので、こういうものを使って、技術全体がうまくいきそうだというか、例えば、この領域はデータを集めるのがあまりにも大変だから、今までは無理して集めたけれども、この先、データをこれ以上増やせないのではないかとか、そういう問いを投げかけるトリガーとして使っていただけるといいなと思っております。

石川からは以上になります。ありがとうございます。

江崎座長： 石川准教授、ご説明をどうもありがとうございました。
それでは、これから自由討論に入りたいと思います。本日の議論に関しまして、あるいは今後の委員会における議事の進め方、今後のプレゼンテーションの機会のリクエスト等に関しまして、構成員の皆様からご意見、ご質問等を頂ければと思います。ご発言をご希望される方は、挙手機能で挙手の上、ご指名させていただければと思います。

今、チャットのほうで中村構成員から石川准教授に、QA4AI、AIQMガイドラインに沿ってチェックリストをつくるにはどれぐらいの作業コストが必要かというご質問がありますが、石川准教授、ご回答いただけますか。

石川先生： ありがとうございます。

何のチェックリストかによるのですけれども、QA4AIとか、AIQMのガイドラインの中には既にチェックリストがあります。そのチェックリストというのは、これぐらいの抽象度なのです。重要なケースとは何かというのが、自動運転の話をしているのか、工場の配管チェックの話をしているのかで変わってくる。なので、実際に考えるときには、このガイドラインのチェックリストはすごく抽象度が高いので、今回はこういうケースに相当するというのを洗い出すことが必要になります。

例えば、工場の配管チェックだと、海から遠いと塩の影響が変わってくるので、海から遠い配管と海に近い工場の配管の両方を集めていますかみたいな問いを発するということが既にサブガイドラインで出ているのですが、そういう洗い出しをするのがプラスアルファの作業になるので、大変ではないといえば大変ではないのですけれども、その領域の専門家と、一応、AIとかデータサイエンスでどういうデータがあるといいのかということが分かる人がちゃんと議論する必要があるという感じです。

江崎座長： ありがとうございます。

中村構成員、ご発言されますか。

中村構成員： ありがとうございます。よく分かりました。
発注者側がAIをある程度分かっていて、例えば、使っているデータセットに対する質問とか、それぞれのリスクに対する知見みたいなものをしっかりディスカッションして、このチェックリストに落としていくことが必要だということですよね。

石川先生： そうですね。どういう失敗がまずいのかというのはIT側の技術では分からないことなので、今までウェブでボタンを押したら速く返事が来るとかは、完全にITベンダーにお任せでいいかもしれないのですけれども、AIの場合はドメイン知識のほうが結構強いので、発注側の専門知識をしっかり引き出していかないといけないというイメージでいます。

中村構成員： 例えば、実際に発注する側が全くの素人だと、なかなか難しいということですね。誰かアドバイザーみたいな人がいて、うまく橋渡しをしてあげるようなことが必要なイメージですか。

石川先生： それが理想といえば理想です。だから、ITベンダーに丸投げして、仕様書も細かいところを整理してもらうみたいなスタイルが難しいということはよく言われているという感じです。そういう意味では、おっしゃるとおりで、理想的には発注者側にも、ITなり、データサイエンス的なことがある程度分かる人がいると、やりやすいのかなと思います。

中村構成員： ありがとうございます。

江崎座長： 今、鈴木委員と島田委員がお手を挙げていただいています。多分、島田委員のほうはAIかと思いますので、鈴木委員の順番を後に回させていただいて、島田委員のほうからお願いできればと思います。

島田構成員： 島田です。聞こえていますでしょうか。

江崎座長： 大丈夫です。

島田構成員： AIだけではないのですけれども、今日発表いただいたセキュリティとかAIに関しても、一般に言えることは、どちらかというと、まだ規制が存在していないところに対して、どうやって規制をしていくのかという議論が中心に進んできているわけであります。

ですので、特にヨーロッパなどは人権を中心に考えて、どうやったら人が傷つかないかという観点でいろいろな問題点を指摘していっているというところでありまして、本会議の目的である、規制緩和をしたときにどうなるのかという議論とは少しずれがあることに注意しなければならないと思います。

セキュリティに関しては、全く同じ問題であります。

ですので、これは私の考えですけれども、最初に須賀さんから説明いただいたプロセスの中におきまして、規制緩和を行う際において、例えば、目視をやめますという話のときに、では、どうやったら目視なしでこの品質を担保できるのですかということを、技術を開発する側から提案させるしかないのではないかと思っております。

その上で、本当に規制緩和しても大丈夫であるかということを検証する仕組みを第三者機関に設けるということをしなければ、恐らく規制緩和は進まないと思いますし、それぞれのシステムを認証していくというのはかなり高度な作業であり、それをまず規制として政府なり、そういうものが網羅的に作成するというのは無理なのではないかと思っております。

江崎座長： ありがとうございます。
どの辺りに着地点をつくるかというのは非常に難しいけれども、これがないと社会的には受容されないというご意見かと思います。

それでは、鈴木委員、お願いします。

鈴木構成員： 鈴木です。

前回は参加できなかったものですから、ずれているかもしれないのですが、これは新技術で規制緩和をという趣旨で進んでいると思うのですけれども、マッピングをするときに、完成された技術だけではなくて、今開発中の技術とか、研究中の技術とか、そういったものも俯瞰できると、それはそれで非常に助かる人もいるのではないかというところがあります。

それにはTechnology readiness levelという指標をつけていたりするのですが、これはもともとNASAが宇宙開発のために導入してきたものですけれども、今はいろいろなところでも耳にすると思うのですが、例えば、研究室レベルでできたようなものは4とか5とかで、それが実フィールドで実験できたというともう少し上がっていって、本当に実際に使われ出すと9とか、最終的な製品に近いものになるということで、成熟度がどのレベルにあるかという指標がきちんと示されていないと、すぐ使える技術なのか、まだ研究中の技術なのかというところを明確にしていただいた上でマッピングするというところの取組も必要なのかなとちょっと感じたので、これは全般的な話です。

それから、もう一つは、多分、今はドローンをどう使っていくかというところも一つのテーマになっているのではないかと思うのですけれども、ご承知のように、来週の月曜日からドローンの新しい制度が始まりまして、機体については機体認証制度というものがスタートします。

これまではそういうものは厳密にはなかったのですけれども、国が行うものは非常にリスクの高いもの、民間の検査機関が行うものはリスクがそれほど高くない中程度といったレベルで、検査を行って飛行安全を保障するという制度が始まりますので、飛行安全性を確保するという意味では、こういうものを皆さんに取っていただくというのが一番効果的なのかなというところがあるのです。

一方で、例えば、ドローンを使って点検したり、物を運んだり、農薬をまいたり、いろいろなユースケースがあるわけでありますので、それぞれについて、どのようなパフォーマンスを持っているのか、どこまでできるのかというところは、先ほどのお話もそうですけれども、業界ごとにそれぞれ信頼性のある確認ができているといいのではないかなということです。

既に行われているものもありまして、今日も参加されているかと思うのですが、国交省さんではインフラの点検のときのガイドブックみたいなことで幾つかの製品を出されていたりしますし、農薬散布に関しては、農林水産協会さんがガイドラインを出されていたりして、いろいろな業種ごとに違っているところがあるのですけれども、どこか第三者的なところできちんとデータを取って、それを公表してもらうという仕組みをとっていくと、安心して使えるのかなということがあります。

私は福島ロボットテストフィールドというところの所長も非常勤でやっていますけれども、ドローンだけではなくて、フィールドで使うロボット等の性能評価ができるような試験フィールドを持っていますので、そういうところを使っていただけると、客観的なデータを比較できることにもなるのではないかなと思いますので、ちょっとご紹介ということです。

先ほどの機体の認証制度ですが、これも国によってちょっと違いがあって、欧州ですとCEマークという欧州の法律に適合しているというマークを、これが自己申告なのか、第三者機関の認証なのかというのは、まだスタートしていないのではっきり把握していないのですけれども、そういうものをつけるものと、それから、リスクの高い飛行をするものは、国の当局の認証を受けなければいけないという2本立てでやっています。

アメリカは、リスクの低い小さなドローンに関しては自己申告でいいということになっていますが、リスクの高い飛行をするものは国の認証を受けなければいけないということになっています。

我が国の場合は、全てのドローンに関して、飛行する際には国土交通省のほうで機体認証を受けられるようになっていますので、ある意味、一つの形でやっているということで、ちょっとやり方の違いもありますけれども、そういったものがスタートするというのをご紹介させていただきました。

私のほうからは以上です。

江崎座長： どうもありがとうございます。

今動いているものの事例として、特にドローンがどうされているかというのをご説明いただきました。ありがとうございます。

それでは、永井委員、お願いできますか。

永井構成員： 私も前回の途中から参加させていただいたので、議論の部分でのポイントがずれているところもあるかもしれませんが、トラストの仕組みのところに関してですが、やはり新しい技術は、常に蓋然性というか、第三者がそれを評価するのが新しければ新しいほど難しいというところがトレードオフとしてあるかと思います。

その中で、私たちは、スタートアップなどの新しい技術を取り込むときに評価してほしいという依頼を頂くことが多いのですが、基本的にはそれが幅広ければ幅広いほど、どうしてもコストになってしまう。プロジェクト自体が非常に広範な技術を扱っていこうとするときに、範囲が広ければ広いほど、技術が大きければ大きいほど、そこの評価コストとか、トラストの部分の第三者のところのコストがかかるというのもかなり厳しいのかなと思っている中で、本人が出せるものとして、ある程度第三者としての確認ができるものとしては、特許とか論文というものがあるかと思います。

もちろん、AIのジャンルとかに関しては、非常に適用しづらいところがあるというのは十分理解しているのですが、技術分野によっては、そういった特許の中の実施例のところがある種の担保になっていたりとか、論文によって何かのエビデンスが取れていることが確認できたりするということ自体が、本人が出せるものとしては幅広くあるのかなと思います。

もう一点は、レファレンスの仕組みを活用するというのが少しあるのではないかなと思っています。例えば、その人がどういう方なのかということを評価することによって、最先端の技術に対するある程度の信頼を見るというやり方もあるかと思うのですが、さらに、その人がネットワークの中でほかの人からどう評価されているのか、サービス・技術自体を第三者が確認した上で、信頼できる方からのコメントがあるかどうかということも、ある程度このトラストの部分のコストを落としながら全体に適用させていくという仕組みとしては、検討の余地もあるのではないかなと思っています。

オープンソースの世界では、基本的にレファレンスの中にいろいろなテクノロジーが存在することによって、それの確からしさということを確認した上で取り組めているところがあるかと思うのですが、技術そのものを全部理解して規制や認証をやっていこうとすると、コスト的にはどこかで合わなくなるのだろうなと思っていますので、そういった形もご検討いただくのがいいのかなと思いました。

ありがとうございます。

江崎座長： ありがとうございます。
特にこれから出てくる新しい技術等に関しての方向性、方法論をご提示いただいたと思いますので、どのように参照するのかというところの議論かと思います。

では、小川委員、お願いします。

小川構成員： 小川です。
今のコストに限界があるといったところで、少し参考でお話しします。本当にこれは参考ですが、お話ししたいと思います。

いろいろな分野で、信頼性に対する検証というのは限界がある、あるいは常に不正とイタチごっことなっている、またコストの問題、もしくは検証先からのネガティブ情報の積極的な提供というのはなかなか難しい、という課題が見受けられてきました。

昨今、こういった課題も踏まえ、コンプライアンス分野では、経営者のAttestation programというのが一つの潮流になっています。先ほど言いましたように、技術革新が非常に速かったり、外部環境変化が速いという中で、第三者の検証が限界に達している点を踏まえ、経営者自らが、目的を達成するための検証などの統制が、有効に整備運用されていることを自ら評価し、その有効性について対外的に宣誓責任を負う、といった枠組みです。

例えば、私どもの専門分野でいいますと、決算書情報の作成プロセスに対する統制の有効性に関し、宣誓責任を経営者に求めるといったSOXコンプライアンスというルールがあります。また、税務のFATCA、アンチマネーロンダリングといった各種コンプライアンス分野でも、類似の枠組みが取り入れられており、一つの潮流になっています。

第三者は、経営者が宣誓した統制の有効性評価に対して客観的な立場で再評価するという手法で、直接検証以外に、こういった枠組みもトラスト確保のフレームワークとして、一つ参考となるのではないかと考えています。

同時に今回、技術提供者には、ベンチャー等々の参加が期待されますので、ベネフィットといったところと、こうした責任のバランスは、慎重に考えていく必要があるでしょう。

あと、先ほどのパワポの最初のページについて、2点だけコメントさせていただければと思います。

最初に、疑義が生じた場合のフィードバックについてです。実際にいきなりテクノロジーマップに掲載されている技術を利用するというよりも、幾つかの技術を比較する形でPOCを実施し、その中から最終的に1つを選ぶことも想定されます。各省庁は、こうした実証実験の過程で、まさに多くの示唆を得るものと考えられます。

実際に使ってみると、もう少しこういった技術があったらいいのにとか、実際のデータ量では稼働に時間がかかり過ぎるとか、記録が十分保存できないとか、最終的に目的適合性に対して、いろいろな課題がここで初めて明確に見えてくると考えています。

我々の経験からも、1つずつの機能の実証検証では問題がない場合でも、実際、実データでEndtoEndで、一定のワークフロー含めての実証実験の中で、技術的問題だけではなくて、関連するオペレーションにおいても、かなり多く影響が見えてきます。なので、一度テクノロジーマップに掲載して終わりではなくて、こういった情報を有効に還元していくことで、技術の高度化、技術革新への貢献というのが、より期待できるのではないかと思っています。

ただ、一方で、こういった情報が技術提供者に過度に不利にならないような形で、うまく今後の発展にも寄与するような掲載、データの蓄積、オープン化が重要ではないかなと思っています。それが1点目です。

あと、もう1点は、先ほどインシデントの話も須賀さんから少しあったかと思います。これもきっちりと議論すべき点だと思っています。先ほど各構成員の皆様から、リスクはゼロにならないとのコメントいただいていますが、こうしたことを踏まえて、万が一、実装した後にインシデントが顕在化したとき、これも小さなインシデントではなくて、社会的影響が大きいインシデント、例えば、ある内容によっては、数秒間もしくは何分間かシステムが止まることによる影響がかなり大きい場合もあり得るというお話がありましたが、そういったインシデントの大きさに合わせたコンティンジェンシープランの設計も非常に重要だと考えています。

多分、既に今までも各省庁でも、様々なコンティンジェンシープランがあると想定されますが、今回推奨される行政のデジタル化に関し、一定のコンティンジェンシープランの基本方針を明確にしていくことで、国民への説明責任、信頼性に、一定程度寄与するのではないかと考えています。

いかに速く、いかにオープンにプロセスを踏んでいくかというところが鍵になりますので、詳細なところは各省庁に任せたとしても、ある程度、トップダウンで一定の基本方針を明確にすることも重要なのではないかなと感じました。

以上です。よろしくお願いします。

江崎座長： 後半のほうは非常に重たいというか、難しい課題だと認識しておりますが、どうやってコンティンジェンシープラン、それから、そういう意味でいうと、技術を提供しているベンダーとそれを受けている人に対してどういう着地点をとっておくかというところは非常に難しいポイントですけれども、重要なところをご指摘いただいたのではないかなと思います。ありがとうございます。

チャットで岡田委員のほうから書き込みがありますが、岡田委員、ご発言されますか。

岡田構成員： 岡田です。よろしくお願いします。

今、皆さん方からお話がありましたけれども、特に私はSIPの土木のほうでやっていた経験でいうならば、先ほども出ましたように、特にAIなどで目視を直していきましょうみたいなことになってきたときに、使われている教師データが非常に特殊になってしまっているのです。

ところが、使われている方々はそれが一般的だと思って使われているので、例えば、写真などでいうと、光の加減でもともと白いものが灰色になったり、黒っぽくなったりもするので、結局、それを教師データに使ってしまうと、判定が大分悪くなったりも、よくなったりもするわけなのです。実証のときには同じようなものでやりますから、うまくいくわけですけれども、ということになると、実際に持っていった場所が違うと、うまく使えないという現象が非常に多かったのです。

結局、やり直そうと思ったら、もう一回教師データからやり直しということにもなってくると、今お話があったように、実際に途中でもありましたが、結局、AIが不完全だというところをしっかりと理解してもらった上で、どういう教師データでどうやったかというところを見た上で、実際には、だから、今言いましたように、新たなデータを使ってやっていけばいいですよということも含めて、一緒に成長していきましょうみたいな感覚になると大分うまくいくのですけれども、とにかく買ってきたものをすぐ使えると思われ過ぎてしまっているし、チャットにも少し書きましたが、いろいろなところで、AIを使えば全部済むのでしょうとか、何もしなくていいのでしょうみたいに、ここで皆さん方がお話しになっているようなリテラシーとは現場は大分違う。

だから、やはりその辺りの本質的な話を教えていかないと、ここでトラストや何かということを言っても、現場のほうは、リスクということよりも、AIが全部をしてくれるだろうと思っている人がやたら多いのは事実なので、その辺りを含めて、現場の方々のAIの基本常識というか、今、リテラシーと言いましたけれども、そういうところも踏まえて持っていかないとまずいのかなという感じがします。

また、先ほどの鈴木先生のドローンもそうですが、ドローンもいいのですけれども、例えば、橋脚でいうと、橋の下に行くと、風が乱流なので落ちてしまうのです。ということになってくると、実際に実験で風速何メートルで飛んでいますといっても、あれは大体一定量の風中で飛ばしているので、実際に乱流や何かになってくると、どのぐらいまで飛べるかというのは行ってみないと分からないし、また、橋の下に行くとGPSが飛んでこないので、結局、位置を失いますみたいな話も出てくるので、やはりいろいろな現場の中で実験をしてもらわないと、単にデータがそろっていて、ちゃんと取れていますよという実証があっても、第三者認証があったとしても、どの状態で認証しているのかが見えないと、正直に言って、現場の人たちは怖くて使えないというのが、いろいろなところで思ったところだったのです。

ここでの議論は非常に大事だと思うのですけれども、やはりその辺りのロバスト性みたいなものをどこまで見せていくのかというのは必要だし、また、ロバスト性が分かっていないと駄目なのだというところも含めて、AIの限界も含めて、島田さんがずっとおっしゃっているようなことも含めて、その辺りのAIの常識みたいなものをどう広めていくかがすごく大事なのではないかと思っています。

江崎座長： ありがとうございます。

やはり我々のところから、そういう意味でいうと、例えば、AIに関してのアンダースタンディングとはこういうものだよというのをしっかりと皆さんに周知した上で、トラストの枠組みというのを動かさなければいけないというお話になりますかね。これはなかなか難しいところですね。

岡田構成員： 例えば、写真などでも、昔のものがたくさんあるからどうぞお使いくださいとデータを出されるのですけれども、はっきり言って、古い写真ではどうしようもなかったということが現実的にあって、橋梁のデータなども、結局、2016年ぐらいのときに全部取り直したというところもありますので、実際にデータがあるから提供します、これで教師にしてくださいと言われても、使えないことがやたら多いなと思いました。やはりそれらも含めてどのように見ていくのかというのは、いろいろな意味で、専門家の方々の常識と現場の常識のずれをどう直していくのかが非常に大事かなと思いました。

江崎座長： それぞれそういうポイントを、省庁、あるいは民間でつくるガイドラインをつくるときに、注意事項としてちゃんと記述してもらうように気をつけなければいけないということですよね。

岡田構成員： そうですね。特に省庁に聞いたから大丈夫というよりも、土木の分野でいうと、やはり地方の市とか県とか、こういったところの人たちの意見が本当の意味でもう少し上がってこないと、国交省が言ったから大丈夫でしょうというところでいうと、国交省のニッタさんとかもいらっしゃるから、よくお分かりでしょうけれども、多分、国交省もそこまで担保できないというのが現実的な答えではないかと思います。

江崎座長： ありがとうございます。

中村委員のほうから、関連して、実際に導入する前のPOCをやることのインセンティブが必要ですよねというお話がありましたが、中村委員、ちょっとお話しになりますか。

中村構成員： ありがとうございます。

ちょうど国のSIPの枠組みで防災の評価委員を10年間させていただき、ちょうど終わったところなのですが、今までなかったシステムをつくりましょうというときに、数十億円の予算をつけて、実際にPOCとして、各省庁、内閣府をはじめ地方自治体、市町村を含めて実証実験を行い、これだったらいけるよねということを現場の人たちも実感し、同時に、担当省庁の方々も、これだったら具現化できると認識できた。そして、評価結果やアウトプットが公表されて、ほかでも利用できるということになっていくのだと思うのです。

何が言いたいかというと、POCというのはすごく金がかかるし、時間もかかります。今まで各省庁が使っていた既存のシステムを、アナログからデジタルに変えるということのインセンティブをどうやってつくって、実際にPOCをやっていけるのか。そのサポートをどのようにやれるのか。

テクノロジーマップがあって、皆さん、この技術は使えそうだと思い、具体的にやってみましょうと考え、POCをやることが必要だと思います。そして、小川先生も言われたように、このPOCがすごく大事で、この結果をみんなで共有していくような仕組みをどうやったらできるのかを考える必要があります。

今回はテクノロジーマップの話なので、先ほど小川先生が言われたように、本当に私もPOCの結果とか、そこで得られた知見をどうやって皆さんで、関係各位や各省庁で横断的に共有できていくか。その仕組みをうまく盛り込むことがすごく大事だなと思いました。

江崎座長： ありがとうございます。

ほかにご意見はございますでしょうか。まだ発言されていない方、ぜひご発言いただければと思いますが。

中垣委員、根本委員、登委員、川端委員、豊田委員、荻野委員、もしあれば挙手をお願いできればと思います。
では、豊田委員、お願いします。

豊田構成員： 今回の話題ではあまり提供できることはないのですが、話題提供的な話でいきますと、今、共有させていただくと、これは別の資料を流用しているので、あまり細かいところは見ていただかなくていいと思うのですが、例えばスマートシティ開発に関しての主導でいくと、米中型、欧州型、日本型というのはまだないのですが、仮に大きく傾向を分けるとすると、企業主導の米中型に対して、ルールベースで、先ほどもちょっとありましたけれども、Social goodであるとか、ecoであるとかということを主導していく、規格規制構築をリードしているのがEU型です。

この辺はすごく参考になるところがあると思うのですが、最近、スマートシティに関しても、スマートシティではなくて、これはメタバースという、あるバズワード的界隈なのですけれども、この辺だとAutodesk、AWS、NVIDIAとか、この辺のパワーハウスが全部集まっていわゆる委員会をつくる的なこともやっているのですが、スプレッドシートを公開して、クリエイターから何から玉石混交も覚悟の上で、とにかく規制緩和のこういう項目をやったらいいのではないかというのを挙げてくれと。これがもう本当に毎分どんどん挙がってきているような状態で、これを各領域で勝手に議論して、まず本当にアジャイルに玉石混交とかリスクも覚悟の上で一気にやっていこうということで求心力を高めていたりします。

先ほどからの話で、規制としてのリスクの話とかは当然あるのですけれども、新しい領域に関してのスピード感ということでいくと、こういうやり方はやはり大事だよなと。それができてきたものに対して、どう利用していくかというところで今日の議論の話がいろいろ出てくるのだと思うのですが、その辺、うまくフェーズごとの設計というものが要るのかなと。

私も今、建築都市とかメタバースという領域に関わっていると、メタバースは本当にまだ規制も何もルールがない状況の世界なのと、建設というのはむしろ世界で一番古い職能の一つの領域なので、物すごくサチュレーションが進んでいて、この領域だと、今度、規制みたいなものがスパゲッティになっているものに、姉歯事件みたいなものがあると、さらに規制がかかって、どんどんクリエイティビティが死んでいくという状態になっていくので、フェーズごとのつくり方のシステムというのがすごく大事になっていくだろうなというのをあくまで参考にということでご提示しました。

江崎座長： やはりテクノロジーが社会実装される上でのフェーズが非常に重要だと。それとともにPOCに関しても、技術開発の部分から、少し実際に使われているところ、それから、最終的に社会で本当に一般的に利用されるというところの段階をしっかり把握しなければいけないというお話ですね。

豊田構成員： ワークグループ的なものをつくってドメインごとに委員会的に緩くやるというのと、先ほどみたいな自由参加みたいなものをやるのと、さらに、そのユースケースを発信していくというので、登さんからあったようなメディア的なものをつくっていく。その三つどもえがあると、うまく機能する可能性があるのではないかなと思いました。

江崎座長： ありがとうございます。
では、中垣委員、お願いできますか。

中垣構成員： 聞こえますでしょうか。

江崎座長： 大丈夫です。

中垣構成員： 機器を携帯からつなげるので、音声が悪いかもしれません。その場合はちょっとご了承願います。

今、NITEさんとやっているスマートプロモーションの中で、例えばなのですけれども、需要設備の保安管理ということをカタログ化しています。既にある技術として、それは使えるよねというものについては、一応、スマート保安としてカタログ化しているのですけれども、それに至るまでのデータの品質がまだ十分でないと判断しているものについては、基礎要素技術ということで、2段階のカタログ化をしています。これが今やっている事例の紹介です。

それと、過去にもそういった技術を導入する上で、どのようなところに、例えば、点検される方の心理的なバリアがあるかというところも、NTTデータ経営研究所さんにそういったアンケート調査をしてもらっているので、今度、機会があれば、そういったことも紹介してもらえるといいかなと思いました。

その中で、私が独自に見た中でそうだなと思っているのは、例えば、保安規定というものを需要設備の点検をする側での電気主任技術者側で届け出るのですが、その監督部となるのは経産省の産業保安監督部なのですけれども、今度、新しい技術を導入しました、点検の回数を変えますみたいなことをやろうとすると、そちらのほうに保安規定を届け出て、受理して変更の確認をしていただかないといけないというところがあって、例えば、事前相談をしてから受理するまでということで、半年とか、それぐらいはかかるということなので、その辺りが、面倒と言うと失礼なのですが、それをやるぐらいだったら現状のままでいいということで進んでいるのかなと思います。

これまでスマート保安の中では、新しい技術、もしくは新しい設備ができましたというのと同時に導入されているものについては、スマート保安のカタログに載りやすいのですけれども、既存のもので数年たっています、もしくはかなり古い設備ですというものに対して適用するというのはなかなか進んでいないかなというところでございます。

そんなところで、手続の規制緩和というところは、説明するときのデータの新規特許のお話がいろいろあったので、その辺りを規制側も同時に勉強していかないと、そういったところの理解にもつながらないのかなと思いました。

以上です。

江崎座長： ありがとうございます。
やはり共通していることは、どの段階にあるかということを規制当局のほうもそれを一緒にしっかり認識しなければいけないというお話かと思います。ありがとうございます。

ほかにご意見はございますでしょうか。

もしよければ、須賀さん、ここまででちょっと反応されますか。

須賀参事官： 本当にありがとうございます。本日伺いたかったところについて、まず、プレゼンをしていただいた皆様も含めて、第三者に頼るべきという結論に至ったと思いますので、具体的にどういうプロセスをお任せしたらいいかという設計をしっかりやっていきたいというのが1つです。

それから、小川構成員や中村構成員からPOCの話を頂きました。まさにそのために、今、デジタル庁、デジタル臨調としては技術検証の予算をまとめて獲得しようと動いております。次回の検討会でぜひご検討いただけたらと思うのですが、お金だけがあってもインセンティブとして十分ではないと私たちも感じており、検証結果をしっかり横展開するとか、規制側、自治体も含めて、様々な教師データをしっかり提供し、より有用性の高いPOCを行っていくことがポイントになると思っていますので、そこについて、ぜひ次回はご議論いただきたいと思いました。

それから、幾つか今後のプレゼンテーションのアイデアなども頂きまして、ありがとうございます。

江崎座長： ありがとうございます。
引き続き、まだ発言されていない委員、もちろん既に発言された委員もいらっしゃいますが、ご発言をお願いできればと思いますが、いかがでしょうか。

荻野委員はプレゼンされましたけれども、いかがですか。

荻野構成員： 荻野でございます。
先ほどの鈴木先生の意見が非常に良いなと私も思いました。要は、やはり成熟度ですよね。新しい技術というのは、なかなかアセスメントするのは難しい。ただ、どのぐらいの成熟度かという指標は確かに出したほうがいいかなと思います。

同様にインシデントとかセキュリティに関しても、使う側に対して提供する側が、ある程度、このレベルですよぐらいの指標はお出しするほうがいいかなと。そういう意味で、私は、米国が進めているラベリングというのはなかなかいい制度だなと思いまして、ぜひ今回の内容にも、技術の成熟度と、それから、セキュリティでこのぐらいはできているよという指標は提示するほうが、使う側にとってメリットがあるのではないかなと思いました。

以上でございます。

江崎座長： どのぐらいの成熟度かというのと、何をどこまでやっているかというのをしっかり提示しつつ、その上で、これからどのようにそれが発展していくかというところが分かるように提示するべきだというお話かもしれないですね。ありがとうございます。
あと、根本委員、登委員、川端委員、ご発言いただけますか。

では、川端委員、お願いします。

川端構成員： 今日は、私、逆に自分の分野と近くないところなので、非常に勉強になって、特にAI分野の品質保証というのは、私は自動車を中心にテクノロジーを書いているのもあって、すごくシビアな品質保証が求められる業界にこういったものを導入するときのハードルは非常に高いなと思って、ふだん思っていたことの回答になるというか、方向性になるというお話を今日聞いて、なるほどなと思って非常に勉強になりました。

また、豊田委員がおっしゃっていた、ある程度リスクを取りながらもアジャイルにやっていくといったこと、分科会のように公式性を持ってやっていくところのすみ分けというのは非常に重要だなと思って伺っていて、特にそこを両方でやっていかないと、3つあるとは思いますが、そのうちの2つの部分でお話しすると、その両面をやっていかないと、新しく発生したもので、別の議論とも非常に関わるのですけれども、技術の成熟度は低いが、ここで語っておくことが重要だよねとか、共有しておくことが重要だよねというものが市場にある程度ある。

玉石混交というお話をされていましたが、腐りというのではないのですけれども、いろいろな状態のもの、成熟度が低いものではあるが、語られているという場があるのと、ある程度の成熟度になって、社会に実装とか利活用できそうだなという段階のものに規制を敷いていくという、その2つのステップは実はあまり一緒にできないなと思っていて、同じ場で語れないなと思っているので、そういった2つ、これはマーケットになると思うのですが、技術が流通するマーケットプレースみたいな考え方をした場合に、2つのマーケットをちゃんと構成していくというのが重要だなと思いました。

それと、こういったものをある程度つくっていく段階で、参加してくれる人と使ってくれる人にそういったものを伝えるという機能がないと参加者は増えないので、エコシステムをつくっていくというのが次に大事なのかなと思って、これは多分、議論としてはちょっと先になるとは思うのですけれども、どういう人たちが参加していけばいいか。リスクをとりながらも新しい技術を出していくというのは、多分、民間企業であったり、スタートアップに小さくても入ってもらったりがあると思うのですが、そういったところに参加させるインセンティブだったりとか、伝えていくというのをやらないと参加者は増えないのかなというか、増やしていくべきだと思いました。

あと、リスクがあるような技術だけれども、そこで語られているということで、場合によっては、大きな活用とか、工業系の活用が出てくるよということが事例としてつくっていける。そこは、新しい技術ですけれども、恣意的に面白いなとか、工業利用がありそうだなというところに、新しい技術というのはコンサルテーションが効いていない場合があるので、そこは予算をかけて、新しい技術を事業化するというところは、例えば、補助金を使ってとか、POCの形で予算を組んで、こういった事業ができないかなというのを枠組みのほうで考えてあげるみたいなものが入るといいのかなと思って聞いていました。

ちょっと散漫で私の感想みたいになってしまって申し訳ないのですが、その2点をお伝えします。

江崎座長： ありがとうございます。

POC等のインセンティブをどのように持たせるかというところの工夫をしなければいけないというところもご指摘いただきました。
それでは、根本委員、お願いします。

根本構成員： ありがとうございます。

あえてコメントするほどの話ではないかなと思って控えていたのですが、須賀さんからお話しいただいたパワーポイントの中で、最初に規制の類型化という言葉が出てきたときに、うっと詰まりました。その後の説明の中で性能要件の精緻な設定というご説明を承りましたので、安堵しました。その部分は極めて重要ですよというお話を前回させていただいたと思ったので、入れていただいてありがとうございましたということが1点でございます。

ただ「類型化」という言葉で精緻な設定を読み解くのは、私の日本語の能力の問題かもしれませんが、なかなか厳しくて、何かもう一工夫していただけるとうれしいなというのが1点ありました。

もう一点は、前回の議論でも出ていたと思うのですけれども、要素技術の部分がどこに出ていたかなというのがちょっと気になったところでございます。どこをどうしてほしいというアイデアがないので発言は控えていたのですけれども、基盤となる要素技術の話はどうしましょう、カタログにどこまでどういう形で載せましょうというお話があったと思います。

あと、性能要件等が精緻に設定されると、技術を公開したくないという企業さんも出てくる可能性があって、そちらはどうしましょうかねと。規制対応にはそういう技術を使えませんということになりかねない弊害が出てくる可能性があって、少し心配しています。これも後々の話なので、今の段階の話ではないかもしれませんけれども、頭の片隅に置きながら議論していければなと思っております。

以上3点です。

江崎座長： ありがとうございます。
では、須賀さん、お願いします。

須賀参事官： 簡潔にお答えさせていただきます。
まず、規制の類型化はアイコンの中に入り切る文字しか入れられていないのですが、おっしゃった趣旨を踏まえて、文言を検討できないか引き取らせていただきます。

それから、要素技術は、掲載する情報の中身の話は前回していただきましたので、今回は議題から省いているだけでして、引き続き載せてまいりたいと思っておりますし、それが一つの技術探索の固まりとして、カテゴリーとして、領域として認識していくということだと理解しております。

それから、最後の点は、事務局としても論点としては認識しておりまして、全てを公開して、我が国ではこういうテクノロジーがこの分野にあります、成熟度はこうですと見せるのがいいのかどうかというのは、経済安全保障の文脈も踏まえた配慮がどこかで必要になる可能性があると思っています。まず、なるべく精緻なものをつくりつつ、それをどこまで公開していくのかというのは、実は後半に少し検討していかなければいけない論点だと認識しております。ありがとうございます。

江崎座長： 情報公開の部分は、経済安全保障、知識財産権のポイントからどこまで書くかという今後の具体的な運用に近い話になってくると思いますけれども、その点があるということですね。

では、登委員、もしあればお願いします。

登構成員： 掲載される技術内容の正確性の担保や、偏った情報の投稿があったときに、どうやってそれを直すかという問題は、多分、多くの人々の目によって監視されているという空気をつくることが重要だと思います。

オープンソースコミュニティにおいては、昔はメーリングリストのようなもの、その後は掲示板のようなもの、最近では、例えば、GitHubのようなもの、また、技術記事においては、日本だと幾つかあるのですけれども、Qiitaですとか、そのような技術サイトもあります。

これらは、情報を誰かが載せたときに、また、誰かが変更・コミットしたときに、それはおかしいのではないか、間違っている、偏っている、また、投稿者の利益、ほかの人の不利益になる、また、あえて脆弱性があるものを入れて悪さをしようとしているのではないか、このようなことを多くの人が見張っております。

ところが、その見張りをつけるときに重要なのは、見張りをする人たちが意見を投稿する場を、すごく投稿しやすくすると、逆に無責任な意見みたいなものがたくさん嵐的に出てきます。他方で、本人確認とか、厳格な手続を取らないと投稿できないようにすると、面倒であるから、多くの有識者はほかの仕事もあるので、投稿する意欲がなくなるという問題もあります。

こう考えると、さきに述べたGitHubの投稿機能で、例えば、イシューという問題を書くと議論ができるのですけれども、これはかなり絶妙な投稿基準といいますか、投稿に必要なユーザー登録やユーザーごとのレピュテーションの仕組みが整っていて、この投稿者はほかにもこういうコントリビューションをしている人だとか、実際に言うだけではなく、ほかの記事も書いている方だと、星みたいなものがついてレピュテーションがつくのです。このようにすれば、完全実名を要求することもなく、かといって、2ちゃんねるみたいに誰でも無責任に書けることもなく、ちょうどよいバランスが保てると思いました。

このテクノロジーマップに掲載される記事等の一部として、そのような議論が行われる機能をつけるということが必要なのではないかと思いました。

以上であります。

江崎座長： ありがとうございます。
非常に難しい問題ですね。どこに着地点をとるかということが出てきますけれども、やはり省庁で閉じないようにしつつ、かつ、責任を持って皆さんから意見を頂くようにするのは難しいところだと思います。

須賀さん、何か反応されますか。

須賀参事官： 先ほど質の高いレファレンスは非常に価値が高いというお話もございましたので、それに通じるお話でもございますし、登構成員にテクニカルなところも含めてご相談しながら、何らかそういった機能を政府としても持てないかなと思っておりますので、努力してまいりたいと思います。

江崎座長： そうですね。やはりこの委員会としては、片方向で政府がこういう基準をつくるという形ではなくて、双方向で産業界、あるいは専門家の方からのご意見を頂きながらこれをつくっていくというのをしっかりと出していかなければいけないということになりますね。

ほかに委員の皆様方からご意見等はございますでしょうか。

須賀参事官： 先生、差し支えなければ、1つよろしいでしょうか。

江崎座長： お願いします。

須賀参事官： 島田構成員からご指摘いただいた点をぜひ正確に理解したいなと思っておりまして、新しいテクノロジーがもう既に使えるのではないかということは、ご提案ベースでしか実現し得ないのではないかとおっしゃっていただいたと思います。

そのご提案をどなたから頂くといいかということなのですが、今、事務局で試行的に「講習・試験」などと領域を設定した上で公募をかけ、技術を保有されている企業から提案いただいていますが、その仕組みを拡大して技術保有企業から領域を問わず自由にご提案いただけるような仕組みが必要だということなのか、それとも、むしろそれを採用してコンプライアンスされる企業からのご提案も受け取るような形がいいというご趣旨なのか、その辺り、もし可能であれば、より詳細に教えていただけますでしょうか。

江崎座長： 島田委員、お願いします。

島田構成員： ありがとうございます。

実はちょっと手を挙げていたのでありますが、先ほど登さんが言われたことに先にコメントさせていただきたいのですが、確かにそういう仕組みはよいと思います。一方で、我々が負担しているインフラのような世界は、これを仮に面白そうだなと思って使ってしまった際には、人が死んでしまうというようなクリティカルな事故が起こるわけでありまして、だからこそ、目視とはいえ、非常に厳しい規制が敷かれているというのが重い現実としてあります。

ですので、そういったことに関しては、実際に重大な事故、クリティカルな事故につながらないような仕組みも併せて考える必要があると私は思っております。それが規制そのものであると考えているわけであります。

先ほどの須賀さんのご質問なのですけれども、我々、例えば、いろいろな提案する側の企業、テクノロジーを持っている企業側からしますと、この規制はこれで置き換えられるのではないかなということを考えることができると思っております。当然、ベンチャー企業の方も可能だと思います。

それがあったときに、それを受け取る側のほうは、でも、規制があるしと。さらに、本当に大丈夫なのか、どうやって担保したらいいのかとか、こういったところで大体詰まってしまう。技術的な情報がどこかに載っているから、誰かがやったことがあるからでは、規制業界で何かがあったときに、数千億円のような補償をしないといけない企業にとって、そこを一歩踏み出すのは極めて困難なことなわけであります。

ですので、やはり最終的にそういうところで本当に規制緩和が進んで、技術によってそれがよくなっていくためには、双方向の問題点を品質管理的観点からきっちりと検証する必要がありまして、ただ、そのきっかけは規制する側からは恐らく出てくることはないと思いますということを申し上げております。

規制する側が見ているものは、これが安全に行われるようにというだけでありまして、その同じことがこういう手段で担保できると思います。ちなみに、目視というのは外してくださいと。こういう提案があって初めて、では、それに対して検証を行いましょうと。第三者機関が見て、それも大丈夫だと思います。実際に行われている場所で検証も行い、データもちゃんとその場所で使ったデータで検証しましたというプロセスを経ることによって、初めて本当の意味での規制緩和が進むのではないかというご提案でございます。

須賀参事官： ありがとうございました。よく分かりました。

江崎座長： やはり業界、あるいは企業からの提案ベースが基本だと。規制当局側からの規制緩和というのはなかなか出にくいのではないかということですね。ただ、今、4,000、8,000ぐらいの法律を全部見直していただいているという中で、それがきっかけとなって、企業側から、業界側からそれがちゃんと出てくるというパスをつくるべきということですかね。

島田構成員： そのとおりだと思います。そういうサインがあるのだということは、企業側にとってはチャンスと考えられると思いますので、それを政府側が発表するということは極めて大きな意義があると私は思います。

企業側と申しましたが、学術でも全然構いません。それはもう全くどこからというわけではなくて、技術やアイデアのある方々、知見のある方々からの提案というのが必要になると思いますし、ユーザーの中に様々な知見を持っている極めて優秀な方々がいて、自分たちでそれを提案することも当然可能だとは思います。

江崎座長： だから、やはり我々というか、政府側としては、ご提案を公募しているし、非常に歓迎しているというメッセージをちゃんと出していかなければいけないということですね。

島田構成員： はい。そのとおりでございます。

江崎座長： それは非常に力強いというか、皆さんを元気づけるメッセージなので、非常に精力的に、上手にそういう発信をしなければいけないというご提言というか、ご提案ということですね。

島田構成員： そうですね。面白いところに人は集まりますので、面白いことになってきたぞとなったら、提案する人は増えるのではないでしょうか。

江崎座長： そういう意味では、やはり幾つかの事例が欲しいですね。成功事例をちゃんとつくらなければいけないと。

島田構成員： そのとおりですね。

江崎座長： ありがとうございます。

ほかに委員の方からございますでしょうか。お手は誰からも挙がっていないようですので、よろしいですかね。

須賀参事官： すみません。作業部会委員ですけれども、落合先生が挙手されているようです。

江崎座長： お願いします。

落合先生： ありがとうございます。作業部会でも検討しておりましたが、本委員会の検討が肝になるのではないかと思って、拝聴しておりました。

今回のお話を聞いていて、プロセス、情報がしっかり開示されることによって、一定の品質というか、クオリティーが担保される可能性があるということで取組をされる方向と認識して聞いておりました。実際、そういう設計をせずにデジタル庁側や役所側がまとめることは、リソースもということもありますが難しい部分があると思いますので、いろいろな方の民間側からの知見を結集する意味では、非常にすばらしい方向性だと思いました。

1つ気になったのが、経済安保などで見えない部分もつくらないといけないのではないかというお話があったと思います。ちょうど作業部会で議論していたところで、その内容と若干共通して整理できる部分があるかと思った点があります。

オンラインとしたときに、閲覧などをどこまでできるようにするかという話をプライバシーの観点で行っておりました。基本的には、アナログの場合と同様に見えるようにしていきましょうという方向性で議論は行いつつも、こういう情報は開示しなくていいのではないかというものは、そもそもアナログのほうも開示しないようにするという話もしておりました。

一方で、技術的なコントロールとして、ログの管理、ID管理などを行って、その認証を経た方だけがより詳しい情報を見られるようにするなど、公開の仕方も何パターンかあるとは思います。今回の件も、情報はできるだけ公開していったほうがよく、質の担保などのガバナンスにつながる部分もあると思いました。本当に隠さなければならない部分は、それこそ役所とか一部の参加者の方だけに見られるようにする部分もあるのでしょうが、できるだけ開示しつつ、プライバシーの文脈と同様に、経済安保的な視点でも利用できるように牽制措置を整理するなどはあり得ることと思います。そのあたりの対策を組み合わせつつも、できるだけ情報開示をされる形で行っていったほうが、全体の取組としてはプロモーション面も含めてよい方向なのかなと思いました。

作業部会のメンバーなので、技術そのものではなくて恐縮ですが、ただ、全体として本当にすばらしい取組だと思います。どうもありがとうございます。

江崎座長： ありがとうございます。

委員の皆様方からは、基本的にはトランスペアレンシーというか、公開していくというのが基本線だということですし、提案を受け取るというのをちゃんと出していかなければいけない。その場合に、レファレンスに関しての公開というか、どういうレファレンスがあるかというのが、グラニュラリティーをどこまで持っていくか。それから、今は出せないというインテンションプロパティの面と、安全保障の面からそれは出せないということは認識しつつ、どうやって公開していくかというポリシーをちゃんとつくることが必要だというのが皆さんのご意見かと思います。

ほかにございますでしょうか。よろしいですか。

それでは、大体今日頂きました時間になりましたので、須賀さんのほうから何かございますか。

須賀参事官： では、最後に、事務的なご報告をさせていただきます。
次回の委員会は、年が明けまして1月中旬頃に開催させていただきたいと思っておりますので、この後、日程調整をさせていただき、議題とともに事務局から改めてご連絡をさせていただきます。

本日の議事は、後日、事務局から皆様に議事録案を確認させていただいた上で、ホームページで公表させていただきたいと思います。

本日の委員会資料につきましても、特段のご意見がないようでございましたら、発表者のご確認を経まして、デジ庁のホームページで公開させていただきたいと思います。

本日は、ご参加をありがとうございました。

江崎座長： ありがとうございます。
それでは、以上をもちまして、本日の委員会を閉会とさせていただければと思います。皆様、ご参加をどうもありがとうございました。