月別アーカイブ: 2025年12月

開発者向けクラウドネイティブセキュリティの基礎（ワークロードセキュリティ編）(1)

CSAジャパン関西支部では、2024年7月15日にCSA本部が公開した「クラウドコンピューティングのためのセキュリティガイダンス V5」（https://cloudsecurityalliance.org/artifacts/security-guidance-v5）と前後して、クラウドワークロードセキュリティおよびアプリケーションセキュリティの観点から、以下のようなブログを展開してきた。

・コンテナ／マイクロサービス／サーバーレスセキュリティとDevSecOps(組織編) (前編)（2024年6月25日）https://cloudsecurityalliance.jp/newblog/2024/06/25/devsecops_3/
・コンテナ／マイクロサービス／サーバーレスセキュリティとDevSecOps(組織編) (後編)（2024年7月16日）https://cloudsecurityalliance.jp/newblog/2024/07/16/devsecops_4/
・コンテナ／マイクロサービス／サーバーレスセキュリティと自動化／AI(技術編)(前編)（2024年8月13日）https://cloudsecurityalliance.jp/newblog/2024/08/13/cloud_workload/
・コンテナ／マイクロサービス／サーバーレスセキュリティと自動化／AI(技術編)(前編)（2024年9月8日）https://cloudsecurityalliance.jp/newblog/2024/09/08/ssdlc/

今回は、機械学習モデルの開発から運用・保守までを一貫して管理・自動化する「MLOps」に焦点を当てながら、AIワークロードセキュティの動向をみていく。

膨大な量の学習用データを処理するAIワークロードとリスク低減策

前述の「クラウドコンピューティングのためのセキュリティガイダンス V5」のうち、「ドメイン8: クラウドワークロードセキュリティ」の「8.6 AIワークロード」では、AIワークロードについて、AI機能の構築、提供、または利用に関わるタスク、プロセス、あるいはオペレーションを指すとしている。AIワークロードは、ユーザー行動に基づく製品の推奨から、車両の自律的な操縦に至るまで、非常に幅広い複雑性と応用分野を包含しているのが特徴である。

AIワークロードは、モデルのトレーニングに大量のデータセットを必要とし、効率化のためにGPU（グラフィックス処理ユニット）やTPU（テンソル処理ユニット）などの専用ハードウェアを活用するなど、かなりの処理能力を要求する。さらに、これらのワークロードは、需要の変動に対応するために動的にスケールする必要があり、クラウド環境によって提供される柔軟なコンピューティングリソースが重要になる。AIワークロードへの取り組みは、単に計算能力を活用することだけではなく、様々な分野でイノベーションと価値を解き放つために、データ、アルゴリズム、リアルタイム処理の複雑な要素を乗りこなすことでもあるとしている。

　CSAガイダンスV5では、AIワークロードセキュリティにおけるリスク低減策として、以下のような点を挙げている。

・データセキュリティ：データを保護するために、暗号化、差分プライバシー、セキュアなマルチパーティ計算を利用する
・モデルセキュリティ：敵対的な攻撃に対してモデルをハードニングし、堅牢なトレーニング手法を利用し、盗難防止のために固有識別子を組み込む
・インフラストラクチャセキュリティ：割当・レート制限を実装し、クラウドサービスに関するベストプラクティスをフォローする
・サプライチェーンセキュリティ：サイバーセキュリティポリシーを定義し、定期的にサードパーティの依存性を監査し、信頼されたリソースを利用する

CSA DevSecOps WG が「MLOpsの概要」を公開

CSA DevSecOps WGは、2025年8月27日に「MLOpsの概要」（https://cloudsecurityalliance.org/artifacts/machine-learning-ops-overview）を公開している。

機械学習(ML)は、ますます企業の中核的な業務機能と結びつくようになっており、それに伴いMLパイプラインのセキュリティ確保が不可欠となっている。そこで本書では、MLSecOps（Machine Learning Security Operations）の概念を紹介し、ML資産を保護する上で特有の課題や、従来のセキュリティ対策がMLシステムに対する新たな脅威に対して十分に機能しない理由について説明することを目的としている。

・謝辞
・目次
・はじめに
・目標.
・対象読者
・エグゼクティブサマリー（概要）
・MLOpsとは？
・LLMOps vs. AgentOps vs. 従来型MLOpsの融合
・MLOpsのステークホルダー
－データサイエンティスト
－機械学習エンジニア
－運用チーム
－プラットフォームチーム
―セキュリティチーム／セキュリティエンジニア.
―プライバシーチーム
―データおよびコンプライアンスチーム
―Cレベル職／経営層.
―プロジェクト／プロダクトチーム
―顧客
・MLOpsの各ステージ
―設計ステージ
―モデル開発ステージ
―運用ステージ
―継続的フィードバックステージ
・MLOpsの課題
・結論

ここ数年で、従来のMLOpsの概念は、古典的な機械学習モデルを運用化するための一連のプラクティスやワークフローとして業界内で発展してきた。しかし、近年の大規模言語モデル（LLM）およびLLMを活用したAIエージェントの進化に伴い、これらの技術を運用化する際に特有の課題に対応するための新たなプラクティスやワークフローを表す用語として、「LLMOps」や「AgentOps」といった言葉が業界で使われるようになっている。LLMは、従来の機械学習モデルと比べてはるかに高い計算複雑性を持ち、専門的なインフラや最適化技術が必要とされる。LLMOpsは、こうしたLLMモデルを本番環境で学習・デプロイ・管理するために進化してきたものである。

本書では、MLOps(機械学習運用)、LLMOps(大規模言語モデル運用)、AgentOps(エージェント運用)の特徴を以下のように整理している。

【MLOps（機械学習運用）】
・対象範囲：一般的な機械学習モデル（分類、回帰、強化学習など）
・モデルサイズ：通常は数MB〜数GBの小〜中規模モデル
・データ要件：構造化データ／表形式データ、画像、時系列、小規模なテキストデータセット
・学習プロセス：モデルはゼロから学習されるか、小規模なデータセットでファインチューニングされる
・インフラ要件：従来型のMLモデルは、スケーラビリティとクラウドネイティブ環境に重点を置いた中程度のインフラを必要とする
・モデルのデプロイ：モデルは通常コンテナ化され、DockerやKubernetesなどのプラットフォーム、および自動化されたCI/CDパイプラインを用いて継続的にデリバリーされる
・推論：予測モデルはREST APIとしてデプロイされるか、アプリケーションに組み込まれる
・モニタリングと可観測性：モニタリングはモデルの性能、レイテンシ、ドリフト検出、精度に焦点を当てる。PrometheusやGrafanaなどの可観測性ツールが一般的
・バージョン管理：モデルのバージョン、特徴量、ハイパーパラメータを追跡
・ガバナンスとコンプライアンス：ガバナンスはデータプライバシー、規制遵守（例：GDPR、CCPA）、モデルおよびデータへの安全なアクセスに重点を置く
・最適化手法：従来型のML最適化（例：ハイパーパラメータチューニング、特徴量エンジニアリング）
・ライフスパンと更新：モデルは新しいデータセットや変化するトレンドに応じて頻繁な更新と再学習が必要

【LLMOps(大規模言語モデル運用)】
・対象範囲：大規模言語モデル（LLM）に特化しており、ファインチューニング、推論、プロンプトエンジニアリングを含む
・モデルサイズ：数百億〜数千億パラメータ規模の大規模モデル
・データ要件：学習・ファインチューニング・継続学習のための膨大な非構造化テキストデータや埋め込みベクトル
・学習プロセス：事前学習済みモデル（例：OpenAIのChatGPT、MetaのLLaMA）をファインチューニングするか、プロンプトベースで適応させる手法が一般的
・インフラ要件：LLMは大規模なインフラ資源を必要とし、分散コンピューティング、高性能GPU/TPU、大規模データセットや並列学習に対応する高度なストレージソリューションが求められる
・モデルのデプロイ：推論効率を高めるために、量子化、モデル分割、知識蒸留などの最適化技術が用いられることがある。また、エッジAIやハイブリッドクラウドでの展開も行われる
・推論：プロンプトベースの推論、リアルタイムのテキスト生成、チャット型インターフェースなど
・モニタリングと可観測性：言語生成の品質、応答時間、モデルの倫理的側面（例：バイアス、不適切な応答、幻覚、攻撃的表現など）の監視が追加で求められる
・バージョン管理：プロンプト、モデルのチェックポイント、ファインチューニングされたバリアントのバージョン管理を含む
・ガバナンスとコンプライアンス：責任あるAIの実践、大規模モデルにおける知的財産の管理、生成AIシステムに対する倫理的ガイドラインの遵守に強く焦点を当てる

【AgentOps(エージェント運用)】
・対象範囲：ユーザー、ツール、環境と対話する自律型AIエージェントの管理、およびマルチステップ推論、記憶、ツール使用のオーケストレーション
・モデルタイプ：計画・推論・ツール使用が可能な動的かつ対話型のエージェント
・デプロイ： API、データベース、ユーザーとやり取りするサービスとしてエージェントをデプロイ
・推論：マルチステップ推論、反復的な意思決定、ツールの活用
・モニタリングと可観測性：エージェントの推論の正確性、ハルシネーションの検出、状態の追跡
・バージョン管理：エージェントのプロンプト、推論ログ、記憶状態、ツール統合の履歴を追跡
・最適化手法：エージェントの記憶のファインチューニング、推論ステップの改善、ツール使用の最適化

MLOpsを取り巻く多様なステークホルダーの存在

業界では現在、MLOps、LLMOps、AgentOpsといった用語を区別して使う傾向があるが、CSAとしては、これらの用語は最終的に統合されるべきであり、「MLOps」という用語が、機械学習に関連するすべての運用プラクティス、ワークフロー、技術アーキテクチャを包括するべきだと考えている。

定義上、機械学習の世界は、あらゆる学習手法とモデリングアーキテクチャを含む上位概念（スーパーセット）であり、現在LLMが使用しているトランスフォーマーのような手法、畳み込みニューラルネットワーク（CNN）、再帰型ニューラルネットワーク（RNN）、長短期記憶（LSTM）といった他の生成系AIの学習技術、さらにはサポートベクターマシン（SVM）、回帰モデル、人工ニューラルネットワーク（ANN）などのより古典的な機械学習手法もすべて含まれる。従って、本書においては、「MLOps」という用語を業界標準とは異なる意味で使用しており、LLMOpsやAgentOpsをも内包する広義の概念として扱っている。

MLOpsは、機械学習モデルの調査、データ収集、トレーニング、開発に多くの時間が費やされるため、従来のDevOpsと比べてややアジャイル性が低い傾向がある。MLOpsのプラクティスを導入することによって、機械学習モデルのライフサイクルに自動化を取り入れることが可能になる。MLOpsのパイプラインには複数の重要なステークホルダーが関与しており、それぞれが異なる役割を担いながら、機械学習と運用の橋渡しを行い、MLOpsを実現している。

　本書では、以下の通り、10の重要なステークホルダーを挙げている。

・データサイエンティスト：
データサイエンティストは、機械学習モデルを作成・学習させるためのアルゴリズムやデータを含む、モデルエンジニアリングのパイプラインを管理することが多い。彼らの役割には、モデルの作成、トレーニング、評価、テスト、パッケージ化などが含まれる。ただし、データサイエンティストは、実運用に耐えるソフトウェアサービスを構築する熟練のソフトウェアエンジニアであるとは限らない。

・機械学習エンジニア：
機械学習エンジニアは、データサイエンスチームから引き渡されたモデルを、呼び出し可能なアーティファクト（例：API統合）へと変換する役割を担うことが多い。大規模な機械学習モデルのトレーニング、モデルの保存、コードリポジトリやモデルレジストリへのアップロード、モデルのデプロイと利用可能な状態への展開、さらにスケーラブルな推論パイプラインやアプリケーションの構築などが、機械学習エンジニアの主な業務である。

・オペレーションチーム：
オペレーションチームは、継続的インテグレーション（CI）および継続的デリバリー（CD）のパイプラインを管理する。機械学習のデプロイメントにおいては、データ、モデル、トレーニング成果物といった複数のワークフローに対応する必要があるため、従来のソフトウェアのCI/CDフロー（例：開発 → QA → 本番）よりもパイプラインが複雑になる。モデルは頻繁に更新されるのではなく、全体として繰り返しリリースされる傾向があるため、データ用のパイプラインとモデル用のパイプラインが分かれて存在することが一般的である。

・プラットフォームチーム：
プラットフォームチームは、インフラの管理、自動化、スケーラビリティ、システムの監視を担当する。機械学習の文脈においては、MLモデルを迅速かつ信頼性高くスケーラブルにデプロイするためのフレームワークを設計・維持する上で、非常に重要な役割を果たす。

・セキュリティチーム／セキュリティエンジニア：
セキュリティチームは、MLOpsライフサイクル全体において、セキュリティ対策が設計段階から統合されていることを確保するという重要な役割を担う。このチームは、機械学習システムの脅威モデリングの実施、データおよびモデルにおける潜在的な脆弱性の特定、セキュリティガードレールの実装、セキュリティインシデントの監視、セキュリティポリシーや標準への準拠の確保などを担当する。

・プライバシーチーム：
MLOpsライフサイクルにおいて、プライバシーチームは、モデルの開発やトレーニングに使用されるデータが、適用されるプライバシー規制および組織の基準に準拠していることを確保する責任を担う。このチームは、データ最小化の原則の適用、個人識別可能情報（PII）の特定、そしてデータの匿名化、仮名化、差分プライバシーといった技術の導入を通じて、ユーザーデータの保護を行う。プライバシーチームは、MLOpsライフサイクル全体にわたってプライバシーの観点が組み込まれるようにし、倫理的なAIの実践と規制遵守の両方を支援する。

・データ／コンプライアンスチーム：
データ／コンプライアンスチームは、データライフサイクルの管理を担い、機械学習モデルが高品質で関連性があり、偏りのないデータでトレーニングされることを確保する責任がある。これには、さまざまなソースからの新たなデータの導入や収集、データ管理、分析、データセキュリティなどが含まれる。MLOpsパイプラインにおいては、データセキュリティが最重要事項の一つであり、コンプライアンスチームは機密情報を保護・管理するための対策を講じる必要がある。

・Cレベル職／経営層：
経営層やCレベルのチームは、社内プロセスの最適化や顧客向けビジネスの強化を目的として、機械学習の導入に関心を持っている。このチームは、MLOpsによって実現される開発期間の短縮、モデルの信頼性や最新性の確保、コストや稼働率の要件への適合、そしてビジネスの主要業績評価指標（KPI）や各種メトリクスに対する大きなインパクトに注目している。

・プロジェクト／プロダクトチーム：
プロダクトチームは、機械学習プロダクトのビジョンを導くうえで不可欠な存在であり、しばしばMLのユースケースの優先順位付けを担当する。一方、プロジェクトチームは、そのプロダクトビジョンを実現し、目標期日までに成果を届けるための推進役として重要な役割を果たす。

・顧客：
顧客は、自身のデータがMLOpsパイプラインにおいてどのように活用されているかに関心を持っている。具体的には、自分のデータがモデルのトレーニングに使用されているかどうか、機密データが適切に保護されており、マルチテナント環境で他の利用者に漏洩しないこと、退会後にデータが適切に削除され、機械学習モデルに機密情報が残らないことなどを気にしている。また、機械学習モデルの信頼性や説明可能性についても高い関心を持っている。

MLOpsパイプラインにおけるセキュリティ部門の役割とは？

次に本書では、以下の通り、MLOpsパイプラインの4つのステージを紹介し、各ステージにおける主要なステークホルダーとの関係を説明している。

1.設計ステージ：
・要求事項の収集、設計、計画策定
（ステークホルダー）経営層／リーダーシップ、製品／プロジェクトチーム、データサイエンティスト、機械学習エンジニア、セキュリティエンジニア

2.モデル開発ステージ：
・データ準備／モデルのためのデータ収集
（ステークホルダー）データ／コンプライアンスチーム、プライバシーチーム、データサイエンティスト、機械学習エンジニア
・モデル検証とテスト
（ステークホルダー）データサイエンティスト

運用ステージ：
・モデルトレーニング
（ステークホルダー）機械学習エンジニア、データサイエンティスト
・デプロイ
（ステークホルダー）機械学習エンジニア、データサイエンティスト、製品／プロジェクトチーム
・モニタリング
（ステークホルダー）機械学習エンジニア、データサイエンティスト、製品／プロジェクトチーム、サイト信頼性エンジニア

4.継続的なフィードバックステージ
・モデルの結果の利用
（ステークホルダー）下流アプリケーション、内部ステークホルダー、外部顧客
・新たなモデルのアップデート
（ステークホルダー）機械学習エンジニア、データサイエンティスト、製品／プロジェクトチーム

早期からDevSecOpsの導入に取り組んできたユーザー企業をみると、既存のオンプレミス環境をベースとするレガシーなエンタープライズシステム体制の改革からスタートし、クラウド環境への移行を図ってきたケースが多い。これに対してMLOpsの場合、DevOpsやDevSecOpsの原則やプラクティスを拡張し、機械学習（ML）のライフサイクルに適用することを目指すが、前述のステークホルダーの顔ぶれを見てもわかるように、組織の開発部門（Dev）や運用部門（Ops）、情報セキュリティ部門（Sec）だけでなく、社内のCレベル職／経営層やユーザー部門、組織外にある外部委託先／パートナー、顧客など、多様なステークホルダーとのコミュニケーションを行いながら、プロジェクトを進めることが必要になる。

その一方でMLOpsは、人間による操作を最小限に抑え、エンドツーエンドの自動化を実現するために、AIワークロードを実行する「非人間アイデンティティ（NHI: Non-Human Identity）」を活用しており、従来とは異なる認証／認可管理やアクセス制御ポリシーの策定が不可欠になってくる。参考までにCSAでは、2024年9月11日に「ノンヒューマンアイデンティティ・セキュリティの状況」（https://cloudsecurityalliance.org/artifacts/state-of-non-human-identity-security-survey-report）を公開している。

このようなMLOps固有のセキュリティ対策が設計段階から組み込まれるよう確保することが、今後、セキュリティチーム／セキュリティエンジニアの重要な役割となってくる。

CSAジャパン関西支部メンバー
DevSecOps／サーバーレスWGリーダー
笹原英司

SaaSセキュリティの設定問題と、SaaSセキュリティ能力フレームワーク(SSCF)の有効性

コメントをどうぞ

第２回SaaSセキュリティリーグ会議

「SaaSセキュリティリーグ」は、SaaSユーザー企業の実務者同士で情報交換を行う取り組みである。SaaS管理者やセキュリティ担当者を横串でつなぎ、知見交換を行うことで、セキュリティレベル向上に貢献していくことを目的としている。ここでは、「SaaSセキュリティリーグ」が行った第2回会議の内容をまとめて公開する。

2025年11月10日　18:30-20:00　開催

テーマ：SaaSセキュリティの設定問題と、SaaSセキュリティ能力フレームワーク(SSCF)の有効性

ディスカッション内容

SaaS利用者が実際に手を動かさなければならないこと（アイデンティティとアクセス管理、インシデント対応、ログ管理、データ保護等）の現状。どこまでできている/できていない点、課題。
- 全社的に設定管理するものに関してはIT部門が管理している。SaaSが提供しているセキュリティ機能についても確認できていて、それに基づいて管理している。一方、個別部門が設定管理を行っているものについては、SaaSのバリエーションの問題がありあまり管理できていない。また、小さいSaaSについては統一的な管理ができていない。
- 最初に、SaaS側のセキュリティ機能（ログを取っているか、ID/アクセス管理など）の確認を行っている。それに基づいて、設定管理を行っている。
- 利用の申請、また、どのように使っているか、SaaSサービスがどうなっているかを確認している。その上で、実装をどうするかを決めていく。利用者側の設定はバリエーションが出てしまう。難しいガイドラインを作っても部門が対応できない（知識がない）ケースもある。
- SaaSはロングテールになる傾向がある。O365のような主要なSaaSは情シスが面倒を見ている。それに対して、ロングテールとなる小さいところは、仕様変更に対して追従できているかも不明なところがある。また、SaaSそのものがそもそもセキュリティ機能を満たしていないところも多い。したがって、SaaSのセキュリティ管理を一律に制限することはできない。
- リスクの大きくないサービスに対してはあまり関わらないし、関わる時間もない。CASBの評価で一定の基準を満たしていれば設定はあまり気にしていない。
  
  まとめると、SaaS側が提供するセキュリティ機能のバリエーションの問題、部門のセキュリティ管理者へのSaaSセキュリティの徹底はなかなか難しい問題であることが分かる。
SaaSプロバイダはどこまで支援してくれているか。あるいは、機能提供しているか？
- SaaS利用前に、SaaSプロバイダにチェックリストに回答してもらう。セキュリティチェックシートを満たさないと契約できないようにしている。Webフィルタリング機能で、契約していないSaaSは使えないようにしている。
- チェックシートに回答がもらえないSaaSがある。また、チェックシートだけでは管理しきれないSaaSもある。
  
  SaaSプロバイダが提供しているセキュリティ機能がなかなか把握できず、SaaS利用者にはチェックリスト等による対応が求められているのが分かる。
利用しているSaaSはセキュリティ機能を持っているが、利用者側で正しく設定できていないケースはあるのか？
- SaaS利用担当者に、以下の項目を実施することを指示。これにより、設定問題をできるだけ回避するようにしている。
  - ユーザーアカウントの登録、変更、削除、パスワード初期化
  - 利用マニュアルの整備、利用方法の指導、利用者に対するヘルプデスク
  - クラウドサービスに設定するデータの定期的なバックアップ
  - インシデント発生時の連絡調整、迂回処理等の検討・実施
  - クラウドサービスでの処理量の増減に応じたサービス利用量の調整
- 利用者側の設定については、基本的には、監査とかで対応している。
- 当初は正しい設定をしていても、今までの設定では不十分になるケースがある。
- 他社で事故が発生した場合に、自社の設定問題が表面化するケースもある。
  
  上記1,2の状況を受けて、SaaS利用者側のセキュリティ設定を徹底する方法として、定期的な監査で設定問題を回避するというのが、現状取られている方法と考えられる。
SSCFの有効性について

ここで、CSAが最近公開した「SaaSセキュリティ能力フレームワーク（SSCF）」について、実際にSaaSセキュリティを担当している管理者の意見を出していただいた。
まず、SSCFであるが、SaaSプロバイダが利用者に提供するセキュリティ機能をまとめた管理策集である。すべてのSaaSプラットフォームで利用可能な標準化されたセキュリティ機能を確立することを目的としている。
- SSCFの資料
  SSCFの解説として提供されている情報（日本語）を以下に示す。本ブログでは、SSCFの詳細は記述しないので、これらの資料を参照していただきたい。
- SSCFで提供されている管理策の有効性についての意見
  - SaaSプロバイダが、SSCFに基づいて実装してくれると助かる。たとえば、SSOしてくれるだけでもうれしいし、ログがAPIで提供されるだけでも助かる。
  - SSCFにより、共通言語化されるだけでも良い。どの機能が揃っているというのが分かるし、同じ土俵で会話できるのはありがたい。
  - ベンダー向けのチェックリストの中で、聞かなくても良い項目が出てくるので楽になる可能性がある。
  - 自動化対応とかは日本のSaaSベンダーはあまりできていない。フレームワークとしてできるようになれば良い。SIEM連携とか、メリットがある。
  - SSCFを、どのように強制できるかが課題である。SSCFの名前がインパクトがない。もっとSaaSでは絶対必要だというような名前にすべきである。「能力フレームワーク」というのが分かりにくい。SSCFをもっと知らしめてほしい。
    
    総じてSSCFについて好意的な意見をいただいた。今まで、SSCFのようなまとまった形でSaaSセキュリティ機能を記述している資料がなかったため、これがSaaSセキュリティのバリエーションを生んでおり、設定および設定管理の難しさをもたらしていた。SaaSセキュリティ機能をプロバイダと利用者で標準化できれば、双方にとって有効であることが分かった。
その他
今回の議論の内容ではなかったが、他社が使っているSaaSを利用する場合、直接そのSaaSの管理ができない（たとえば、他社がBOXを使っていて、そのBOXを共有するケース）という問題が提起された。これは、SaaSに対してチェックリストを出すことができない。このような場合に、セキュリティ対応はどうしたらよいのかが課題となる。
まとめ
- SaaS利用者設定の課題について、全社的に設定管理するものに関してはIT部門が管理できている。一方、個別部門が設定管理を行っているものについては、SaaSのバリエーションの問題がありあまり管理できていない。
- 利用者側の設定の状況については、基本的に、監査で対応している。
- SaaSプロバイダが提供しているセキュリティ機能については、セキュリティチェックリストを送付し、SaaS利用前に回答してもらう方法が取られている。また、セキュリティチェックシートを満たさないと契約できないようにしている。ただし、チェックシートに回答がもらえないSaaSもあり、課題はある。
- SSCFにより、SaaSのセキュリティ機能の標準化ができるようになると非常に有効である。しかしながら、どのように強制できるかが今後の課題となる。

以上