【資格】AWS認定 AI Practitionerに合格した勉強法

こんにちは、大石（@se-o-chan）です。
AWS認定のうち、「AWS認定 AI Practitioner」に合格しました！この認定区分は2024年8月にベータ版が、10月に正式版がスタートしたバカリで、2025年2月15日までは「Early Adopter」のデジタルバッチがもらえます。私が合格に至った勉強法と試験範囲の内容をまとめますので、同じく資格取得に興味のある方の参考になれば幸いです。

準備期間と結果

準備期間は2024年12月27日〜2025年1月13日の約2週間でした。
AI・機械学習の実装経験はほぼ無いものの、「AWS認定 機械学習-専門知識」を直前に再取得したところでしたので、その知識は活かすことができたかなと思います。

結果は757点で、「コンピテンシーを満たしている」と判定されたのは第１、３、４分野だけだったのですが、なんとか合格できました！

合格までの勉強法

１．試験ガイド

どんな内容が試験で問われるのか、まずはしっかり試験ガイドを確認しましょう。リンクはこちらです。

AIと機械学習（ML）でアプリケーションを開発・運用するための知識を問われます。 全体通じてAWSサービスというよりは、教師あり学習・教師なし学習、RAG、ファインチューニングなどのAI・MLの基礎知識が中心です。特に生成AI周りはこれまでのAWS認定ではなかった範囲ですね。

とはいえAWSサービスに関する問題も出題されます。Amazon BedrockやSageMakerなどのAI・機械学習系のサービスはもちろん、データ収集のためのAWS Glue、RDSやDocument DBなどのデータベース、IAM・CloudTrailなどのセキュリティ・ガバナンス周りが問われます。具体的には試験ガイドに記載がありますので、しっかり確認して「このサービスってなんだっけ？」となるものが無いようにしましょう。

２．AWS Skill Builder

AWS Skill BuilderでAI Practitionerの解説コンテンツを無料で公開してくれています。リンクはこちらです。
試験ガイドに沿って試験範囲の内容を動画で説明してくれます。動画の数が多いので一通り確認するだけでも7〜8時間はかかるでしょう。試験ガイドの5分野それぞれで2問ずつ、計10問の模擬問題もありますので、AI Practitionerを受験するなら必修コンテンツだと思います。

また有料コンテンツですが、計65問のプレテストもあります。リンクはこちら。 プレテストを解くことで試験で問われる内容をより具体化できるので、こちらもおすすめコンテンツです。Skill Builderにサブスクリプション登録が必要で単月なら29USD、年間なら449USDです。約6万円という年間契約はちょっとハードルが高いので、試験前に単月契約になっちゃうかもですね。

３．Udemy

もしSkill Builderだけだと学習、模擬試験が足りないと感じる方はUdemyを使うと良いでしょう。 AI Practitioner関連のコンテンツがすでにいくつか公開されているので、好みに合うものを選ぶと良いと思います。リンクはこちらです。

今回学んだこと

では、ここからは試験ガイドで定義されている５つの分野に沿って、学んだことをまとめていきます。ここで試験範囲の概要を押さえてから、上で触れたAWS Skill Builderの解説コンテンツや模擬問題に進むと、理解が捗るかもしれません。

第１分野：AIとMLの基礎

ここではAIとMLの基本的な用語と、ML開発ライフサイクルを学びます。

AIとMLの基本的な用語

まずAIとMLの違いについてです。バズワードっぽいので定義を曖昧に捉えがちですが、下図のような関係性です。

• 人工知能（AI）は学習、画像・音声認識、コンテンツ作成などを行えるコンピュータサイエンスの一分野です。
• 機械学習（ML）はAIの一種で、大量のデータを使ってモデルと呼ばれる機械学習のアルゴリズムを学習させることでより精度の高い予測を行えるようになります。
• 深層学習（Deep Learning）は機械学習モデルの一種で、ニューラルネットワークを用いて音声や画像内の物体認識などに使用されています。
• 生成AIは深層学習を用いて画像・テキスト・音声・コードなどを生成するテクノロジーですが、生成AIは第２分野で深掘りします。

（出典）AWS Japan「生成AIの中身を覗いてみよう」

ML開発ライフサイクル

次にML開発ライフサイクルを整理していきます。試験ではML・AI開発に必要なステップをまとめたML開発ライフサイクルについて多く問われます。どのようなステップが必要かはAWS Well-ArchitectedフレームワークのMachine Learningレンズがとても参考になります。

[ML開発ライフサイクル①] ビジネス目標、ML問題の定義

ML開発ライフサイクル上、まず対応するべきは「ビジネス目標の定義（Identify Business Goal）」と ML問題の枠組みの定義（Frame ML Problem）です。何を改善・解決したいかビジネス目標を定め、そのためにMLに求めることを定義します。世の中は生成AIで盛り上がっていますが、従来のMLが不要になるわけではなく、ユースケースが違います。ML・AIのユースケースは試験でも問われるので、しっかり押さえておきましょう。

従来型ML	生成AI
過去データからの分類・予測が得意。	過去データを元にした新しいコンテンツ生成を行う。
<ユースケース> ・需要予測 ・住宅の特徴・場所から住宅価格を予測 ・迷惑メールを自動フィルタ	<ユースケース> ・テキストの生成・要約 ・画像の生成 ・コードの生成

[ML開発ライフサイクル②] データ処理

ML・AIで何をさせたいかが決まったら、データの準備です。ライクサイクルでは「データ収集（Collect Data）」「データの前処理（Pre-process Data）」「特徴量エンジニアリング（Engineer Features）」の順に定義されていますが、特に重要なのが特徴量エンジニアリングです。

AIやMLでは、まず大量の学習データから特徴量と呼ばれる値を抜き出します。特徴量とは、表形式の構造化データなら列の値、JSON・XMLなどの半構造化データならキーと値のペア、画像などの非構造化データならピクセルなどが該当します。AI・MLの予測値や生成されたテキスト・画像などを推論と呼びますが、推論は学習データと入力データの特徴量をもとに出力されます。特徴量エンジニアリングでは、男性・女性のような変数を0、1などの数値データに変換するOne-Hotエンコーディングや、欠落データに対して何らかのロジックを持ってデータを埋める特徴量変換（Feature Transformation）、学習・推論のコストを軽減するために特徴量の数を減らす次元削減などの手法でデータを整えます。

[ML開発ライフサイクル③] 学習、デプロイ、評価

データから期待する値を推論するプログラムをモデルと呼び、モデルの中には膨大な数のパラメータを持っています。最近の生成AIモデルなら数千億個もの数のパラメータを持ちます。学習データの特徴量を元に、パラメータを最適値に調整することをモデルの学習と呼びます。学習にも様々な方法があり、これも試験で問われる内容です。

学習手法	概要
教師あり学習	学習データに正解を与えた状態で学習させる手法。 分類や回帰に利用。
教師なし学習	学習データに正解は含まない状態で学習させる手法。 クラスタリング、異常検知などに利用。
半教師あり学習	少量の教師ありデータと多量の教師なしデータで 学習させる手法。自然言語処理や画像認識などに利用。
強化学習	モデル（＝強化学習ではエージェントと呼びます）が ランダムに動きながら出力値に対して与えられる 報酬が最大値になるように学習させる手法。 パーソナライズや最適化問題などに利用。
転移学習	すでに学習済みのモデルを用いて、 別のモデルを作成する学習手法。 様々なユースケースがあり、画像や音声認識などに利用。

学習できたモデルを本番環境にデプロイし、ML・AIを運用します。デプロイ先としてEC2、ECS・EKSなどのコンテナ環境の他に、SageMakerにモデルをデプロイして運用させることもできます。SageMakerの場合はリアルタイム推論という常時モデルが動いているパターンと、バッチ推論という一発だけ決まったタイミングで稼働するパターンがあります。

最後にモデルに適した評価を行い、十分の精度・性能が出ていなければ学習を繰り返します。またモデルが学習しているデータや推論結果が古くなることもあるため、学習〜評価は運用後も継続的に実施していく必要があります。

第１分野に関連するAWSサービス

では第１分野の最後に、ここで関連するAWSサービスを列挙しておきます。まずAWSには特定ユースケースごとに予め学習済みのモデルが活用できるAIサービスが提供されています。モデルを学習させる手間が省けるため、ML・AI活用時にはまずこれらが使用できないかを検討するのが良いでしょう。試験においても頻出範囲です。

AWSサービス	機能概要
Rekognition	深層学習に基づいた画像、動画分析サービス。
Textract	言語の翻訳サービス。ディープラーニングモデルを使用。
Comprehend	テキストから感情分析、トピック形成、 キーフレーズ検出などを行う自然言語処理サービス。
Lex	Alexaのバックサービス。A"Lex"aで覚えやすいサービス名かと。 音声やテキストを使用して任意アプリに対話型インターフェースを提供する。
Transcribe	自動音声認識を使って音声をテキストに変換するサービス。
Polly	入力したテキストを自然な音声に変換するサービス。
Personalize	レコメンドサービス。
Transrate	テキストの翻訳サービス。
Amazon Forecast	MLベースの時系列予測サービス。
Amazon Fraud Detector	疑わしいオンライン決済などオンライン不正を検知するサービス。

またMLの中心サービスはSageMakerですが、MLライフサイクルの各ステップをカバーするように様々な派生サービスが提供されています。これも試験の頻出範囲です。

AWSサービス	機能概要
Amazon SageMaker	MLのモデル開発、学習、推論ができるマネージドサービス。
Amazon SageMaker Ground Truth	データラベル付けサービス。Amazon Mechanical Turk を使うと世界50万人の請負業によってラベリング。
Amazon SageMaker Canvas	ノーコードでMLモデルを構築できるサービス。
Amazon SageMaker Data Wrangler	データの可視化、変換処理をGUIから実行できる。
Amazon SageMaker Clarify	MLモデルの解釈可能性・公平性などを可視化してくれるサービス。
Amazon SageMaker Feature Store	特徴量を保管し、共有できるサービス。
Amazon SageMaker Experiments	MLモデルの再現性担保のために必要な情報を収集・管理する。
Amazon SageMaker Model monitor	本番デプロイしたMLモデルを監視し、 モデル学習時と推論の傾向が変わったらアラート。
Amazon SageMaker Pipeline	MLOps、LLMOpsのためのワークフローサービス。
Amazon SageMaker Model Registry	MLモデルのバージョン管理、メタデータ関連付けを行う。
Amazon SageMaker JumpStart	MLモデルのハブ。GUIで様々なMLモデルを学習、デプロイできる。

第２分野：生成AIの基礎

次に、生成AIに特化して基本的な用語を学びます。

生成AIの基本的用語

第１分野で触れたように、生成AIは深層学習を用いたコンテンツ生成に特化したAIテクノロジーです。モデルを学習させて推論するという点は通常のAIと変わりませんが、生成AIの場合はそのモデルが非常に大規模でパラメータ数が数千億個といったオーダーになります。これを一から学習させるには膨大なコストがかかるため、生成AIでは様々な企業が提供してくれている学習済みの基盤モデルをベースにして開発・利用します。大量のテキストデータを学習したLLM（大規模言語モデル）、画像・動画の生成を担うVLM（画像-言語モデル）などがあります。

生成AIにコンテンツ生成させるためには、AIモデルに実施してほしいことを文章や画像で指示します。この推論のインプットとなるデータのことをプロンプトと呼びます。すると生成AIはプロンプトをトークンに分割します。トークンとはテキストデータであれば文字、単語または数個の単語の組合せ、画像データであれば数百×数百ピクセルの固まりのことで、AIモデル内のトークナイザーがテキストや画像をトークンに分割します。

次に重要な概念が埋め込みで、トークンをベクトルという数値に変換することを指します。このベクトルは数学で学んだベクトルと同義なのですが、次元数は1〜3,000にもなります。「幸せ」「幸福」「happy」のような同義語は位置が近しいベクトルとして表現され、「王様」−「男」＋「女」＝「女王様」のような単語の意味を計算で表現できるようになります。

AIモデルには一度に取り込めるトークン数に上限があります。これをコンテキストウィンドウと呼びます。コンテキストウィンドウの範囲内であれば、AIモデルは過去のプロンプトや出力のトークンを保持するので、過去のやり取りを踏まえた（コンテキスト＝文脈を理解した）推論が実現できます。

第２分野に関連するAWSサービス

では第２分野に関連するAWSサービスを紹介します。生成AIに関するAWSサービスといえば、Amazon Bedrockです。幅広い基盤モデルを提供してくれており、インフラレイヤを考慮することなく生成AIを使うことができます。Amazon Bedrockは、入出力のトークン数に応じて課金されます。 （出典）AWS Blackbelt「Amazon Bedrock Overview」

第３分野：基盤モデルの応用

第３分野は基盤モデルの選択基準とチューニング方法を学びます。試験の出題配分が一番大きい分野であるため、内容が多めです。

基盤モデルの選択基準

OpenAI社が提供するGPT、AWSが開発したAmazon Titan、Anthropic社が提供するClaudeなど、Amazon Bedrockでは数十種類の基盤モデルが利用できます。さらに2024年末にはAmazon Bedrock Marketplaceという機能が提供され、さらに数百という基盤モデルが利用可能になりました。これだけの数があるとどのように基盤モデルを選択して良いか分からなくなりますが、AI Practitioner試験ではこの基盤モデルを選ぶ判断基準の理解が求められます。

判断基準	概要
コスト	入出力トークン数、出力画像数などモデルごとに料金体系・価格が異なる。
レイテンシー	推論の速度。例えば車の自動運転はリアルタイム性が重要で推論速度が必要。
モダリティ	テキスト、音声、画像、動画など扱えるデータ種別。多言語モデルの考慮も。
アーキテクチャ	画像認識はCNN、自然言語処理はRNNのように適したアーキテクチャがある。
複雑度	パラメータ、レイヤーの数など。レイテンシー、メモリ、正解率に影響する。
バイアス	学習データの偏りのため、偏見・政治的な解釈が問題になる場合も。
互換性	PyTorch Hubなど使用する環境と互換性のあるモデルかどうか。
解釈可能性	単純なモデルならなぜそのアウトプットになったか解釈できる。
コンテキストウィンドウ	一度に扱えるトークン数。大きいほど会話履歴を踏まえて推論を行う。

基盤モデルのチューニング方法

基盤モデルにはハイパーパラメータと呼ばれる、基盤モデルの挙動を制御するために事前に設定できる変数があります。例えば次のようなハイパーパラメータをチューニングすることで、要件にあった推論を得られやすくします。

ランダム性に関するハイパーパラメータ
　・温度：値が大きいほど推論のランダム性が高まる。
　・Top K：推論結果のうち、上位K個の結果だけに絞る。
　・Top P：推論結果のうち、上位P％の結果だけに絞る。

長さに関するハイパーパラメータ
　・ 応答の長さ：生成する推論結果のトークンの長さ。
　・ ペナルティ：特定の単語、フレーズを抑止したり、トークン長を調整する。
　・ ストップシーケンス：特定の文字、単語が出てきたら推論を停止する。

RAG（検索拡張生成）

基盤モデルは様々な情報がすでに学習済みではありますが、自社の社内規定や商品情報など特定のドメインや最新データに関する質問にも回答できるようにしたくなります。RAG（検索拡張生成）は、そのようなニーズに対応するために重要なアプローチです。RAGは大きく2段階のプロセスがあります。データベースや文書から情報を取得するリトリーバによる「検索フェーズ」と、その検索結果とプロンプトを合わせてモデルから回答を得るジェネレータによる「生成フェーズ」です。

（出典）野村総合研究所「用語説明 RAG」

ファインチューニング

同じくモデルに追加学習させる方法として、ファインチューニングがあります。ファインチューニングは教師あり学習の一種で、新たな学習データを使ってニューラルネットワークの最後に新たな層を追加＋既存層の重みを更新します。これによって元々のモデルでは対応できない内容も推論できるようになります。

モデルを追加学習させるという点でRAGと似ていますが、「RAGは教師なし、ファインチューニングは教師あり学習」などの違いは押さえておくと良いと思います。

（出典）@IT「ファインチューニングとは？」

プロンプトエンジニアリング

RAGやファインチューニングを使ってモデルにちゃんと必要情報を学習させていても、プロンプトの質が悪いと期待した内容・フォーマットで推論が得られません。効果的なプロンプトの工夫・テクニックをプロンプトエンジニアリングと呼びます。代表的な手法として次のようなものがあります。

プロンプトエンジニアリング手法	手法概要
フューショットプロンプティング	プロンプト内の少数の出力例を提示する方法。
ゼロショットプロンプト	プロンプト内に出力例を指定しない方法。
思考の連鎖プロンプティング	推論を複数ステップに分解して最終的な出力を得る。
プロンプトチューニング	プロンプトテキストを最適化されたベクトルに置き換える。

プロンプトエンジニアリングは推論精度を上げるだけでなく「こういうプロンプトには対応しない」「こういう推論は返さない」といったガードレールを追加する目的でも使用します。ガードレールについては第４分野でもう少し触れます。

第３分野に関連するAWSサービス

第１、２分野に登場したSageMakerの各種サービスやBedrockは第３分野でも当然重要機能ですが、ここではRAGやファインチューニングに関わるサービスを取り上げます。

まずRAGを活用するためにAmazon Bedrockのナレッジベースという機能が使えます。S3に格納したデータやWebクロールした結果をOpenSearch、Aurora / RDS PostgreSQL、DynamoDB、DocumentDBのようなベクトルデータベースにナレッジベースが埋め込み、Bedrockのモデルが推論時に参照できるようにします。

またファインチューニングは教師あり学習であるため、必要な学習データを用意するためにSageMaker Ground Truthを使ってデータセットにラベル付けしたり、SageMaker Clarifyを使ってデータを分析して潜在的なバイアスを検出します。このSageMaker Clarifyは学習後のモデルの評価にも使え、第４分野でも重要サービスの１つです。

加えてナレッジベースなどと連動するサービスとしてAmazon Bedrock Agentsも重要です。フルマネージド型のAIサービスで、事前にプロンプトとツール（外部システムへの検索・登録APIなど）、ナレッジベースを与えておけば自動でアプリケーションが生成されます。例えば旅行パッケージを予約するために、必要情報をユーザから聞き出し→飛行機を予約→ホテルを予約のようにワークフローを伴うアプリケーションが生成できます。

（出典）AWS Blackbelt「Amazon Bedrock Agents 自立型AIの実現に向けて：検討編」

第４分野：責任あるAIに関するガイドライン

第４分野では、責任あるAIの概念とそれを実現する方法を学びます。

責任あるAIとは？

学習データや統計モデルとしては最適解だったとしても、学習データが足りていなかったりデータにバイアスが含まれている場合、AIはさも合っていそうな嘘を回答すること（ハルシネーション）や倫理的に問題がある回答をすることがあります。責任あるAIとはそのような回答を防ぎ、安心で信頼できる動作をさせるためのガイドラインと原則です。

責任あるAIは主に次の６つの要素を持っています。

• 公正性：年齢、性別、民族などに関係なく、すべての人を公平・公正に扱う
• 解釈可能性・説明可能性：モデルが決定を下した理由を人間の言葉で説明できる
• 堅牢性：障害に耐え、エラーを最小限に抑える
• プライバシー・セキュリティ：プライバシーを保護し、個人情報を公開されないようにする
• ガバナンス：業界標準とベストプラクティスを遵守し、監査を行う
• 透明性：ユーザにAIを使っていることを知らせ、モデルの機能、制限、リスクの情報を提供する

責任あるAIを実現する方法

これを実現するための方法もいくつかありますが、ここでは３つ紹介します。

まず１つ目はバイアスがなく、バリアンスが十分な学習データ・モデルの準備です。例えば学習データのバイアスをなくし、プライベートデータを取り込まないようにするのはAIエンジニアの責務の１つです。生成されたモデルにバイアスがなく、公平な推論ができているかどうかを確認することも同様です。

２つ目はガードレールの設定です。ハルシネーションはトレーニングデータにない情報をAIが埋め合わせようとした結果発生します。他にも著作権侵害、有害コンテンツ生成、プライバシー侵害などが発生する可能性もあります。様々な企業が提供する基盤モデル自体にも、有害・危険・悪意あるプロンプトには応答しないという防護策は含まれていますが、それはあくまで一般的な概念に基づくものであるため、機密情報・個人情報・特定業務に関する内容はその防護対象にはなりません。ガードレールを用いることによって、より綿密に受け付けるプロンプト、推論結果を制御することができます。

３つ目はモデルの解釈可能性と説明可能性を高める方法です。例えば住宅ローン審査にAIを活用した場合、「なぜかはわからないけど、AIがNGと回答したので貴方は住宅ローンを受けられません」というのはあまりに不誠実ですし、ユーザは納得できません。このような問題にモデルの解釈可能性と説明可能性を高めることで対応します。
線形回帰などシンプルなアルゴリズムの場合、推論結果がなぜそうなったかを人間も理解できます。決定木のようなアルゴリズムでも「この条件に該当し、この閾値を下回るから」という風に比較的に推論結果がわかりやすいです。このようなモデルを解釈可能性が高いモデルといいます。
一方ニューラルネットワークのようなアルゴリズムは、内部はブラックボックスで解釈可能性をどうしても低くなります。しかし推論結果を観察してなぜそう判定したかを説明することは可能です。これが説明可能性が高いモデルです。 解釈可能性を高くする方法は線型回帰・決定木のようなシンプルなモデルを選択することです。ただこの場合、機能は制限されますし、攻撃者が内部構造を理解しやすくなるため、セキュリティもトレードオフとなります。 説明可能性を高めることはSageMaker Clarifyなどのサービスを使うことで実現しますが、その後の内容で説明します。

第４分野に関連するAWSサービス

この分野で最も重要なサービスがSageMaker Clarifyです。上の「責任あるAIを実現する方法」の１つ目である学習データやモデルのバイアスがないかを確認することができます。例えば人の属性から年収を推論するようなモデルだった場合、学習データに対して「男性が７割を占めていて女性のサンプル数が少ない」や、モデルの推論結果に対して「男性の方が年収が高いと予想されやすい」などのバイアスを有無を可視化してくれます。
また推論結果をモニタリングすることで「どの特徴量が寄与した結果、こういう結果の推論が得られたのか」という３つ目の説明可能性にも対応できます。

また２つ目の観点に対応するためにAmazon Bedrockガードレールを活用できます。一般的な有害コンテンツをブロックする「コンテンツフィルター」、定義したトピックをブロックする「拒否トピック」、定義した単語・フレーズをブロックする「単語フィルター」、個人情報や機密情報などをブロックする「機密情報フィルター」などのポリシーをサポートしています。

モデルの透明性を高めるためにAWSはAI Service Cardというドキュメントを公開しています。これはAWSがホストする基盤モデルやRekognitionのようなAIサービスがどのようなユースケースに対応でき、どのような制限があるかを提示するものです。独自でカスタマイズしたモデルに対してはSageMaker Model Cardを使うことで、そのモデルに対して実施した設計〜評価などの情報を可視化してくれます。

第５分野：AIソリューションのセキュリティ、コンプライアンス、ガバナンス

最後の分野ではAIソリューションを運用する際に意識しなければならないセキュリティ、コンプライアンス、ガバナンスについて学びます。

AIソリューションのセキュリティ

まずはAWSではよく目にする責任共有モデルについてです。AWSはクラウド”の”セキュリティ・コンプライアンスを担当し、利用者である私たちはクラウド”における”セキュリティ・コンプライアンスに対する責任を負うという考え方です。下図はEC2やRDSなどのサービスに対するものですが、同じ考えがAIにも適用できます。右のManaged Serviceに当たるのはRekognitionやTextractなどのAIサービス、真ん中が既存の基盤モデルを使いながらもアプリケーション自体は利用者が構築するBedrock、左がモデルから利用者が構築するSageMakerです。左に行くほど柔軟性や自由度は上がりますが、その分利用者が担う責任が広くなります。

（出典）Amazon Web Servicesブログ「AWS責任共有モデルをGxPソリューションに適用する」

その他のセキュリティ観点として「IAMでユーザに与える権限は必要最小限にする」「CloudTrailで監査ログを取得する」「S3はパブリックに公開しないようにする」「AWS KMSを活用して保存データを暗号化する」「VPCエンドポイントを使って通信がプライベートネットワークのみ通過するようにする」というAIに限らず一般的な内容も引き続き意識しましょう。

また、AIソリューションに対する攻撃手法としてどのようなものがあるかを知っておくのも重要です。

攻撃手法	攻撃概要
プロンプトインジェクション	悪意あるプロンプトによって意図しない情報を引き出す。
ジェイルブレイク	ガードレールを回避しようとする行為。
ハイジャック	元のプロンプトを新しい命令で変更する。
ポイズニング	学習データであるメールやウェブなどに有害なデータを混入させる。
モデルインバージョン	モデルの出力からトレーニングデータを推測。

これらに対する対策としてデータ・モデルのアクセス制限、データ・アーティファクトの暗号化などはもちろん、定期的にモデルの推論傾向が変化していないか確認することが必要で、SageMaker Model Monitorは運用中のモデルの品質を常時モニタリングすることができます。

AIソリューションのコンプライアンス

AIに対するコンプライアンス基準はまだ登場し始めたばかりで、2023年にISO 42001とISO 23894がAIシステムのリスク評価、管理するためのメカニズムを定義しています。ここで触れられている内容はざっくり言えば第４分野の「責任あるAI」を実践するための取り組みです。
またEU AI Act（AI法）ではAIのリスクを3分類し、最上位の「容認できないリスクをもたらす」アプリは完全に禁止。「ハイリスク」アプリは法的要件が適用され、それ以外は規制なしとしています（大半のアプリがハイリスクアプリに分類されます）。
米国国立標準技術研究所（NIST）が発表したAI Risk Management Framework（RMF）でもAIサービスの開発、利用のフレームワークを提唱しています。AIソリューションを構築・運用する場合は、この辺りのコンプライアンス基準を遵守するよう意識しておくべきです。

AIソリューションのガバナンス

ここでは特に学習データに対するガバナンスを整理します。データガバナンスは主にキュレーション、検出・理解、保護の３分野に分けることができます。
データの「キュレーション」は、膨大なデータを常に正確で最新な情報に保ち続け、機密情報は含まれないようデータを整えることです。次にどのようなデータがあるのかを「検出・理解」するには、データカタログが重要な要素になります。最後の要素である「保護」は、データに対する適切なアクセス制御がポイントです。一般にデータスチュワードと呼ばれる人がこの辺りのガバナンスを意識し、データ利活用に対する維持・管理責任を負います。　

第５分野に関連するAWSサービス

セキュリティにおいて、AI・MLに特化したサービスとしてSageMaker Role Managerがあります。これを使うとあらかじめ用意されたペルソナに応じて、SageMaker用のIAMロール・ポリシーを自動で生成してくれます。また上でも触れましたがSageMaker Model Monitorで運用中のモデルをモニタリングすることができます。

コンプライアンスにおいては、AWS ConfigにはAL/ML運用とSageMaker運用のベストプラクティスに則したルールを用意してくれていて、AWSサービスの各種設定値がそれに則っているかをチェックできます。またAWS Audit Managerはより正式な監査向けのサービスで、コンプライアンス監査に必要な継続的チェックと監査人に提示できるレポートを作成することができます。生成AI用のフレームワークも用意されています。

最後にガバナンスでは、AWS Glueによりキュレーションを実現し、自動で生成されるデータカタログをでデータの検出・理解を促進することができます。さらにAWS Glue DataBrewを使えば、ノーコードでデータのクリーニングと正規化を実現できます。保護の観点では、AWS Lake FormationによりS3内のデータカタログ化されたデータに対してアクセス制御を提供してくれます。

まとめ

少し長かったですが、試験範囲を一通り整理することができました。これまでAI・MLに触れてこなかったエンジニアも、利用者・開発者・運用者いずれかの立場となってAI・MLに関わることは今の時代避けられないと思います。まずはこのAWS認定AI Practitionerの資格取得を通じて、基礎知識を学習していきましょう。