AI開発の「共通言語」ISO/IEC 22989とは？エンジニアとPMが知っておくべきAI用語・ライフサイクルの世界標準

「うちのAIモデル、精度は出ているのに現場から『使いものにならない』と言われてしまった……」

「クライアントと『AIの品質』について話しているのに、お互いの言葉の定義がズレていて会話が噛み合わない」

AI（人工知能）を使ったシステム開発や事業開発に携わる中で、このようなコミュニケーションの壁にぶつかった経験はないでしょうか。

Webシステムや従来のルールベース開発とは異なり、AI（特に機械学習やディープラーニング）は「入力に対して100%同じ出力を保証できない」「環境変化によって精度が落ちる」という不確実性を持っています。
そのため、開発者、ビジネス担当者、クライアント、そしてユーザーの間で「何をもってAIと呼ぶのか」「どこまでが学習で、どこからが運用なのか」という前提認識がズレやすいのです。

この「言葉の定義や概念のズレ」を解消し、世界共通のコミュニケーション基盤を作るために策定された国際標準規格が ISO/IEC 22989:2022 です。

本記事では、AI技術者やプロダクトマネージャー（PM）、IT担当者が知っておくべき「ISO/IEC 22989」のポイントを、難しい規格用語を噛み砕きながら約5,000文字で徹底的に解説します。

ISO/IEC 22989の基礎知識：なぜ今「AIの辞書」が必要なのか？

ISO/IEC 22989:2022（Information technology — Artificial intelligence — Concepts and terminology）は、ISO（国際標準化機構）とIEC（国際電気標準会議）が2022年11月に共同で発行した、AI分野における概念と用語の国際標準です。

一言で言えば、「世界共通のAI大百科事典（辞書）」です。

AIに関する技術、プロセス、ライフサイクル、信頼性、関係者の役割など、あらゆる概念の公式定義がここに集約されています。

なぜ今、国際標準の「定義」が必要なのか？

AI技術の爆発的な普及に伴い、市場にはさまざまな用語が溢れ返りました。しかし、人や企業によって言葉の意味がバラバラに使われていたことで、以下のようなトラブルが頻発したのです。

「AI」の範囲のズレ
顧客は「自動で判断してくれる夢のシステム（自律型AI）」を期待していたのに、ベンダーが納品したのは「ただのIf-Thenルールで動くプログラム」だった。

「学習」の認識の違い
「本番稼働後もAIが自動で賢くなる」とクライアントが勘違いしており、精度維持のための「再学習（Retraining）コスト」を巡って契約トラブルになった。

「説明可能性」の誤解
どこまでアルゴリズムの中身を言語化・可視化できれば「説明できた」と言えるのか、評価基準が存在しなかった。

ISO/IEC 22989は、こうした「言葉の表記ゆれ」や「概念の曖昧さ」による悲劇をなくすための標準レイヤーとして誕生しました。

ISO/IEC 22989が定義する「AIシステム」の正体

私たちは日常的に「AI」という言葉を使いますが、ISO/IEC 22989では「AIシステム」をどのように厳密に定義しているのでしょうか。

AIシステム（AI System）の公式定義

ISO/IEC 22989における「AIシステム」の定義の核心は以下の通りです。

「人間が定義した一連の目標に対して、予測、推薦、または意思決定などの出力を生成し、物理的またはデジタルな環境に影響を与える、エンジニアリングされたシステム」

ポイントは、単に「コードで動くプログラム」ではなく、「環境からのデータを取り込み、推論を行い、環境に何らかのアクションや価値を返して影響を与える仕組み全体」を指している点です。

2つのアプローチ：データ駆動型 vs 知識駆動型

本規格では、AIのアプローチを大きく2つ、そしてその融合型に分類しています。

「機械学習だけがAIではない」ということ、そして「ルールベースと機械学習を組み合わせたハイブリッド構造も明確なAIである」ということが、この標準規格によって体系化されています。

AI・機械学習・ディープラーニングの包含関係と決定的な違い

ある程度のこの分野に精通した技術者でも、非技術者との会話になると、ついこの3つの概念を混同したまま話を進めてしまうことがあるのではないでしょうか。
ISO/IEC 22989 では、混同されやすい「AI」「機械学習」「ディープラーニング」の3つを対立概念ではなく、「大きな包み紙（包含関係）」として明確に整理・定義しています。
ざっくりと説明すると、一番大きな括りがAI、その中に機械学習があり、さらにその中にディープラーニングがあるという関係です。

各概念の決定的な技術差は以下の通りです。

• 人工知能（AI：Artificial Intelligence）
  • 定義： 人間のように推論・判断する技術全般。
  • 特徴： データによる「学習」をしないルールベース（If-Then文の組み合わせ）もAIに含まれます。
• 機械学習（ML：Machine Learning）
  • 定義： AIの中の一手法。大量のデータから統計的なルールを自動で学習する技術。
  • 特徴： データの「どこに着目すべきか（特徴量）」は、人間が指定してあげる必要があります（例：みかんとりんごを見分けるため「色と丸みに注目せよ」と人間が指示）。
• ディープラーニング（DL：Deep Learning）
  • 定義： 機械学習の中のさらに進化した一手法（多層ニューラルネットワーク）。
  • 特徴： 着目すべき「特徴量」すらも、AI自身が大量のデータから自動で抽出・発見します（例：大量画像を放り込むだけで、AI自ら皮の質感や形状の違いに気づいて識別）。

本規格（22989）を理解する上では、これらが別モノではなく「AIという大きな箱の中に、MLがあり、さらにその深部にDLがある」という構造を前提として押さえておくことが重要です。

現場で使える！「AIライフサイクルモデル」の標準化

ISO/IEC 22989のハイライトとも言えるのが、AIシステムの企画から廃棄に至る「ライフサイクルモデル」の標準化です。

従来のソフトウェア開発（ウォーターフォールやアジャイル）の工程にAI特有の「データ処理」や「モデル学習・検証」を組み込んだ、以下の標準ステップが定義されています。

各フェーズで具体的に何を行うべきか、深く見ていきましょう。

フェーズ1：企画・概念化（Inception & Conceptualization）

行うこと
「解くべき課題（ビジネスゴール）」を定義し、それがAIで解くべき問題か、データは存在するかを検証します。

重要ポイント
精度目標だけでなく、後述する「説明可能性」や「公平性」などの非機能要件もこの段階で策定します。

フェーズ2：データ準備（Data Preparation）

行うこと
データの収集、クレンジング（ノイズ除去）、アノテーション（ラベル付け）、特徴量エンジニアリング、データの偏り（バイアス）のチェック。

重要ポイント
「Garbage In, Garbage Out（ゴミを入れたらゴミが出る）」を防ぐため、ISO/IEC 22989ではこのフェーズを独立した最重要工程として位置づけています。

フェーズ3：モデル構築・学習（Model Building & Training）

行うこと
アルゴリズムの選定、ハイパーパラメータの設定、訓練データを使ったモデルの学習。

重要ポイント
学習プロセスそのものの再現性（どのようなパラメータとデータで学習したか）をログとして記録します。

フェーズ4：検証・評価・デプロイ（Verification, Validation & Deployment）

行うこと
未知のテストデータ（Test Data）を用いた精度の検証、過学習（Overfitting）のチェック、本番環境へのデプロイ。

重要ポイント
単に「正解率95%」を見るだけでなく、失敗した5%のデータが社会的・倫理的に重大な損害を出さないかを評価します。

フェーズ5：運用・監視・継続的再学習（Operation, Monitoring & Retraining）

行うこと
本番環境での推論処理のモニタリング、データドリフト（時代の変化等による入力データの質の変化）の検知、モデルの再学習。

重要ポイント
AIはデプロイして終わりではありません。環境の変化とともに精度が低下（経年劣化）するため、「再学習のループ」を運用に組み込むことが標準要件となっています。

フェーズ6：退役・廃棄（Retirement）

行うこと
モデルのアーカイブ、データの安全な消去、代替システムへの移行。

「信頼できるAI（Trustworthiness）」を構成する5つの鍵

AIシステムを世の中に送り出す際、単に「動く」「精度が高い」だけでは不十分です。ISO/IEC 22989では、社会から信用されるAIに必要な「信頼性（Trustworthiness）」の構成要素を明確に言語化しています。

① 説明可能性（Explainability）と透明性（Transparency）

説明可能性は、AIが出した出力（判定結果）について、なぜその結論に至ったのかを人間が理解・追跡できるようにする度合い。

透明性は、システムの仕組み、使われているデータ、限界やリスクに関する情報がステークホルダーに開示されている状態。

② 堅牢性（Robustness）

入力データに多少のノイズ（例：カメラ映像のノイズや誤字）が入ったり、悪意あるデータ攻撃（敵対的サンプル攻撃）を受けたりしても、システムが崩壊せず正しく機能し続ける耐久性のこと。

③ 偏り（Bias）と公平性（Fairness）

学習データに含まれる人種・性別・地域・歴史的偏見などの「バイアス」が、推論結果において特定のグループに対する不当な差別や不利益（アンフェアな判定）に繋がらないように配慮されていること。

④ 安全性（Safety）

AIシステムの動作や誤判定が、人間の生命・身体、あるいは物理的な財産に物理的な危害を与えないこと（ロボット制御や自動運転、医療AIなどで特に重視されます）。

⑤ プライバシーとデータ保護（Privacy & Data Protection）

学習データや推論時に入力されるデータにおいて、個人のプライバシーが侵害されず、適切に匿名化・保護されていること。

誰が何をする？ステークホルダー（関係者）の定義

AIプロジェクトに関わる人々の「役割（Role）」が曖昧だと、「事故が起きた時に誰の責任か」で揉めることになります。ISO/IEC 22989では、関係者を明確に4つの分類で定義しています。

1. AI Provider（提供者）
   AIシステムやモデルを設計・開発・構築・提供する組織（例：AIベンダー、システム開発会社、社内AI開発チーム）。
2. AI Customer（顧客）
   AIシステムを購入・導入し、自社の事業やサービスに組み込む組織（例：AIツールを導入する企業、クライアント）。
3. AI User（利用者）
   導入されたAIシステムを直接操作し、アウトプットを利用するオペレーターやエンドユーザー。
4. AI Subject（対象者）
   AIシステムの判定結果によって直接的な影響を受ける人々（例：AI融資審査を受ける顧客、AI採用ツールで合否を判定される求職者）。

この分類の画期的な点は、「AI Subject（対象者）」という視点を明確に盛り込んだことです。システムを使う人間だけでなく、「システムによって判定される第三者」の人権や不利益まで考慮してAIを設計すべきであるという思想が、国際標準の中に組み込まれているのです。

まとめ：ISO/IEC 22989を現場でどう活かすべきか？

ここまで ISO/IEC 22989 の中身を深掘りしてきました。

本規格は、エンジニアやPMが「暗記しなければいけないルール」ではありません。「AIプロジェクトを円滑に進めるための共通コミュニケーションツール」です。

現場で今すぐ使える3つのアクション

プロジェクト初期の「用語のすり合わせ」に使う
「AI」という言葉を曖昧に使わず、「今回はデータ駆動型の画像認識モデルを構築します」「本番稼働後の再学習フェーズは今回の工数に含まれますか？」といった会話にISOのライフサイクル概念を適用しましょう。

要件定義に「信頼性（Trustworthiness）」の項目を入れる
仕様書を作る際、機能要件（精度など）だけでなく、「説明可能性はどこまで求めるか」「データドリフトの監視方法はどうするか」という非機能要件を22989の要素からピックアップして項目化しましょう。

ステークホルダーごとの責任範囲をクリアにする
自社が「Provider」なのか「Customer」なのかを意識し、データの準備責任はどちらにあるのか、AI Subject（影響を受けるユーザー）への透明性をどう確保するかを契約や運用ガイドラインに反映させましょう。

AI技術がどれだけ進歩しても、人間の間で「言葉の定義」や「開発プロセスの認識」がズレていては、良いプロダクトは作れません。ISO/IEC 22989 という世界標準の「辞書」を手元に置き、より確実で信頼されるAI開発を目指していきましょう。