AIの信頼をどう確保するかをめぐる議論は、ここ数年で大きく前進した。リスクの大きさに応じて対応を変える、プロダクトの透明性とリスク管理を求める、組織にアジャイルなガバナンス体制を求める――こうした「信頼できるAI」に共通する枠組みは、国際規格やガイドライン、そしてEUをはじめとする各国・地域のAI法制を通じてかなり整理されてきた。しかし、問題は、その先にある。法令・標準・ガバナンスの枠組み（以下、これらをまとめて「ルール」と呼ぶ）が一定の義務やガイダンスを定めている場合でも、それらだけで、あらゆる分野、ユースケース、AIバリューチェーン上の立場について、実装と評価の具体的な拠り所まで提供することは困難である。いま求められているのは、こうしたルールを、現場における実装と評価につなぐ、実務的な実装・評価仕様（specifications）である。「何を対象とするか」「誰がどこまで責任をもつか」「何をどう測るか」「何を証拠として示すか」――このような拠り所がなければ、多くのステークホルダーが複雑に関わるAIのサプライチェーンにおいて、最終的な信頼を確保することが難しい。そして、そのような仕様を作るためには、現場を知る事業者自身の主体的な関与が欠かせない。本連載では、以上のような問題意識に基づいて、全5回にわたり、「『信頼できるAI』の共通基盤をどう作るか」という問いと、その実現に対する企業の関与のあり方を掘り下げていく。第1回（本稿）で全体像を示したうえで、次回以降、自動運転をはじめとするフィジカルAI、医療、金融、そしてセキュリティという、信頼の実装・評価仕様づくりがいままさに動いている現場を、順に取り上げる。1．ルールと現場の距離AIのリスクをマネジメントするために最もよく参照される標準の一つが、ISO/IEC 42001（※1）だ。そこでは、組織がAIシステムのライフサイクルを通して、そのリスクを評価し、方針と管理体制を定めることを求める。同様に参照されることが多い米国NISTのAIリスクマネジメント枠組み（※2）では、統治（Govern）・把握（Map）・測定（Measure）・管理（Manage）という四つの機能を通じて、組織がAIのリスクに継続的に向き合う枠組みを示す。法規制として最も知られるのは、EUのAI法だろう。同法は、禁止されるAI慣行や高リスクAIシステムについて規制を定めるとともに、汎用目的AIモデルについても一定の義務を課している。しかし、これらのルールには、「これさえやっておけばOK」という具体的なアクションが書かれているわけではない。期待される行動や成果、そして必要となる証拠は、分野や用途、ユースケースによって異なるからである。たとえば、EU AI法の第9条は、高リスクAIの提供者が、AIによるリスクを「特定・評価」し、「適切かつ的を絞った措置」を講じ、残存リスクを「許容可能な水準」まで下げなければならない、と要求する。しかし、その「適切かつ的を絞った措置」とは何なのか、「許容可能な水準」が具体的にどのレベルか、システムの更新のたびに、どこまで再検証すればよいのか、といったことは書かれていない（※3）。現在、世界各地においてAIに関するルールの整備が進んでいるが、共通する課題は、それを具体的に現場にどう落とし込むかという点にある。2．なぜ上位のルールは各実装の細部までは示せないのかそれでは、なぜ法律や分野横断的なガイドライン・標準といった上位のルールは、具体的なプロセスや目標値をすべて記述できないのか。その背景には、AIの性質に関する以下のような特徴がある。第一に、とりわけ生成AIでは、統計・確率に基づいて出力が生成されるため、その内容が常に一定とは限らない。同じプロンプト（入力）でも、毎回出てくる答えが異なる場合がある。そのため、ルール側であらかじめ「期待される一意の出力」を記述することは困難だ。第二に、AIシステムとその動作環境は静的ではない。モデル、学習データや参照データ、プロンプト、設定、インターフェース、周辺ソフトウェアが更新されれば、その挙動は変わり得る。その結果、あるバージョンや実装において十分だったエビデンスが、別のバージョンや実装では十分ではなくなることがある。第三に、AIのリスクは文脈に依存する。同じモデルでも、使う分野・用途・影響を受ける当事者によって、許される挙動は変わる。したがって、何を評価しなければならないか、どの水準の性能なら許容できるか、どのエビデンスが関連するかは、意図された用途、影響を受ける当事者、動作環境、そして失敗した場合の帰結によって決まる。「安全（safety）」という言葉ひとつをとっても、自動運転車にとっての「安全」が人や物に衝突しないことであるのに対し、対話型AIにとっての「安全」は、差別的・有害な発言や誤った情報を生成しないことを意味する。すなわち、単一のチェックリストでは不十分なのだ。もっとも、これは、共通の評価手法や、分野ごとの基準を作ることができないという意味ではない。このようなダイナミックなAIの特徴を踏まえると、法律・ガイドライン・分野横断的な標準等が、細部にわたる実装のすべてを記述することは現実的ではなく、必ずしも適切でもない。これらのルールの役割は、あくまで目標、義務、ガバナンス上の期待、そして場合によっては求められる成果を定めることにある。こうした考え方は、日本政府が提唱してきた「ゴールベース」の規制とも重なる（※4）。これらの要求事項を適用するために必要な手法、指標、証拠、受入基準は、特定の技術・分野・役割・用途ごとに整備していく必要があるだろう。3．実践的な共通の「実装・評価仕様」の必要性ルールが抽象的なのだとすると、各社がその要求を満たしていることを示すためには、何をすればよいか。バラバラな取組だけでは、十人十色の判断になってしまう。一貫した評価を可能にするためには、共通の実装・評価仕様（specifications）が必要だ。評価に一貫性を持たせるには、何が検証されているのか、どの主体がどの要素に責任を負うのか、どの要求事項が適用されるのか、その要求事項をどのように評価するのか、どのような証拠が生み出されるのか、等を特定するための共通のやり方が必要である。満たすべき閾値は、適用される法令、契約、あるいは分野別の枠組みが定めることになるだろう。実装・評価仕様は、その結果がどのように導かれたのかを理解するための共通の土台を提供する。これが最も重要になるのはサプライチェーンにおいてである。評価結果が企業、業界、国境を越えて同じ意味を持つなら、川下の事業者は、川上の事業者がすでに示したことをゼロから証明し直す必要がなくなる。4．「相互運用可能なアシュアランス」とは何かこれが「相互運用可能なアシュアランス（interoperable assurance）」である。共通のフォーマットをもつシステム間でデータが行き来できるのと同じように、信頼性を裏付ける評価結果や証拠もサプライチェーンに沿って移動でき、各段階で作り直すのではなく再利用できる。その証拠は、それが適用される対象・バージョン・役割・基準の範囲において再利用でき、他方で川下の各主体は、自らの統合、設定、配備、そして文脈固有の義務について引き続き責任を負う。これが相互運用可能なアシュアランスの実践的な狙いである。すなわち、単一の万能な認証ではなく、組織の境界を越えて理解され、組み合わされ、依拠され得る証拠と評価結果である。これを可能にするのが実装・評価仕様である。そして、こうした仕様を国際的に共同で作る動きは、すでに始まっている。たとえば、2026年6月に立ち上がったAppia Foundationと呼ばれる国際的な取組では、Linux FoundationのJoint Development Foundation（JDF）のもとで、試験・認証を担う事業者、産業・エネルギー・通信・決済などでAIを実装する企業、モデルやプラットフォームを開発・供給する企業が名を連ね、既存の国際標準および分野別標準を踏まえ、公に利用できるモジュール型の実装・評価仕様を策定しようとしている（※5）。5．なぜ、仕様策定プロセスへの参加が重要なのかそれでは、企業がこのような実装・評価仕様の策定に主体的に参加することは、なぜ重要なのか。それは、実践的な仕様が最も力を発揮するのは、AIシステムを設計し、供給し、統合し、評価し、調達し、利用する人々の経験が反映されているときだからである。企業は、実際の技術、分野固有の制約、既存の標準、サプライチェーン上の関係、実装コストについての知見を持ち寄ることができる。幅広い参加はまた、特定の業界・地域・ビジネスモデルが普遍的なものとして扱われてしまうことを防ぐ助けにもなる。参加する企業にとっては、早期に関与することが、技術的な実現可能性、相互運用性、既存プロセスとの整合性を高める機会となる。また参加は、これから形になっていく要求を先読みし、製品、評価プロセス、サプライヤー要件について、後の段階でコスト増となる変更を迫られるリスクを減らすことにもつながる。たとえば、自動運転車の安全仕様について考えてみたい。近年急速に広まっている、センサー入力から操舵までを一体で学習するEnd-to-EndのAIでは、人間の書いたルールではなく、膨大な走行データから機械が導き出した数百万のパラメータによってその挙動が決まる。そのため、従来のような部品ごとの安全性を測るアプローチだけでは、十分にAIシステム全体の性能を評価できない。それでは、どのように自動運転システムの安全を実装し、評価するのか。そこでは、分野横断的なAIの要求事項、自動車分野の標準、再利用可能な評価手法を適切に組み合わせる必要がある。この点については、第2回で詳しく扱う。6．おわりにAIへの信頼は、ルールだけでは生まれない。ルールは方向性を示すことはできても、各企業が自らの現場で実際に何をすべきかまでは教えてくれない。その隙間を埋められるのは、実務に根ざした共通の実装・評価仕様――何を対象とするのか、誰がどこまで責任をもつか、何をどう測るか、そして何を証拠として示すか、等についての合意――である。これがあってはじめて「相互運用可能なアシュアランス（interoperable assurance）」が可能になる。すなわち、信頼性を裏付ける評価結果や証拠を各段階でゼロから作り直すのではなく、サプライチェーン全体で理解され、再利用できる形で示すやり方だ。こうした実装・評価仕様は、誰かが与えてくれるのを待つものではない。それはまさに今書かれつつあり、その策定に参加する企業こそが、この分野の形を決める。続く連載では、こうした実装・評価仕様がいま形になりつつある領域として、自動運転をはじめとするフィジカルAI、医療、金融、セキュリティを取り上げ、何が議論されているのか、そして「実装・評価仕様」がどう機能するのかを、具体的に見ていきたい。【本連載は、スマートガバナンス株式会社が、 Microsoft Corporationと共同で研究した成果をもとに執筆したものです】（※1）ISO/IEC. ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. 2023.（※2）National Institute of Standards and Technology (NIST). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. 2023. https://doi.org/10.6028/NIST.AI.100-1. （※3）こうした法律に具体的な形を与えるため、EU AI法は、求められるプロセスや仕様の詳細を「欧州整合規格（European harmonized standards）」において定めることとしている。しかし、この整合的な仕様はまだ策定されていない。（※4）経産省・総務省「AI事業者ガイドライン」1.2版 (2026), https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/pdf/20260331_1.pdf、経済産業省 “GOVERNANCE INNOVATION Vol.3: アジャイル・ガバナンスの概要と現状” (2022),https://www.meti.go.jp/shingikai/mono_info_service/governance_model_kento/20220808_report.html（※5）Linux Foundation Launches Appia Foundation to Establish Standardized Conformity Specifications Across the AI Value Chain (2026), https://www.linuxfoundation.org/press/linux-foundation-launches-appia-foundation-to-establish-standardized-conformity-specifications-across-the-ai-value-chain 【関連記事】▶ 本稿の英語版：From Abstract AI Rules to Practical Specifications【Series: Building the Shared Infrastructure for Interoperable AI Assurance — Part1】▶「AIシステム認証制度のデザイン：製品のリスク管理策と組織のマネジメントを統合した『ジョイント認証』の試み」ホワイトペーパー（全文公開）▶ AIへの信頼性を付与する認証制度の最新動向～「Joint Certification」とは～本稿は公開情報や執筆者の専門的知見に基づいた一般的な分析・見解を提供するものです。本稿に記載の見解は執筆担当者の個人的見解であり、当社または当社のクライアントの見解ではありません。