こんにちは、関根です。
新しく登場したAWS認定「AWS Certified AI Business Strategist（AIB-C01）」のベータ試験を受けてきました。結果は771点（合格基準700点）で、無事合格できました。
「AI」と付く試験なので、Amazon BedrockやAmazon SageMaker AIといったサービスの知識が問われるのだろうと思って臨みました。ところが、受けてみて印象に残ったのは、個別のサービスではなく、AIへの投資をどう判断し、どう組織に導入していくかという視点でした。
もちろん、AIや機械学習の基本的な理解は必要です。ただ、技術を知っていることと、事業として適切に使えることは別物です。今回は、その違いを考えさせられる試験でした。
この記事では、試験の概要とAWS公式リソースを使った学び方を整理します。併せて、試験ガイドの範囲と学習を通じて整理した内容をもとに、AI導入を段階的に進めるフェーズの考え方と5つの視点をまとめています。
1. どんな試験か
受ける前に知っておきたい3つのこと
1. AWS認定だが、サービスの実装知識が中心ではない
AWSの認定ページには、AWSサービスの知識そのものを評価する試験ではないと明記されています。重視されるのは、AIへの投資評価、ビジネスケースの構築、ガバナンス、組織への導入・拡大といった判断です。ただし、試験ガイドではAIの基礎知識や、AWSの主なAIサービスをビジネスレベルで理解することも求められています。
2. FoundationalやAssociateとは異なる「Business」カテゴリー
主な対象は、技術チームと連携しながらAI施策を進めるビジネス担当者です。コーディングやAWSの構築経験は必須ではありません。試験ガイドでは、AIを導入するチームに関わった経験が6か月程度あることを推奨しています。
3. 試験の基本情報はベータ版と標準版で一部異なる
| 項目 | ベータ版 | 標準版 |
|---|---|---|
| 問題数 | 85問 | 正式公開後に確認 |
| 試験時間 | 170分または180分 | 130分（試験ガイド記載） |
| 受験料 | 50 USD | 100 USD |
| 出題形式 | 択一選択問題・複数選択問題 | |
| 言語 | 英語・日本語 | |
| 受験方式 | ピアソンVUEテストセンター／オンライン監督付き試験 | |
| スコアと合格基準 | 100〜1,000点の換算スコアで、700点以上が合格 | |
| 採点方式 | 試験全体で合否を判定（ドメインごとの足切りなし） | |
※試験仕様は2026年10月10日時点で確認したAWS公式情報に基づきます。受験前には最新情報を確認してください。
4つのドメインを、ひとことで言い換えると
試験ガイドの4つのドメインを、自分なりに「何を判断できる必要があるか」という観点で言い換えてみました。
| ドメイン（比重） | 自分なりの言い換え | 内容のイメージ |
|---|---|---|
| 1. AI Fundamentals and Literacy（24%） | AIを正しく説明できるか | AI・ML・生成AIの違い、RAGやエージェント、プロンプトやコンテキストの制約、適切なツール利用 |
| 2. AI Strategy and Business Value Creation（28%） | AIの投資価値を判断できるか | ユースケースの優先順位、構築・購入・パートナー活用の比較、KPI・ROI、継続・一時停止・中止の判断 |
| 3. AI Governance and Responsible AI Leadership（24%） | リスクに応じた統制を設計できるか | 責任あるAI、人による監督、リスクと便益のバランス、規制・コンプライアンス |
| 4. Business Readiness, Leadership, and AI Transformation（24%） | AIを組織に定着させられるか | 成熟度評価、データ基盤、部門横断の体制、人材育成、パイロットから全社展開への移行 |
最も比重が高いのはドメイン2（28%）です。また、残るドメインもAIの実装手順そのものより、組織・戦略・ガバナンスとの接続に重点が置かれています。
他のAWS/AI系認定とざっくり比較すると、次のような違いがあると感じました。
- AI Practitioner：AIの基礎を理解する
- Generative AI Developer – Professional：生成AIを実装する
- AI Business Strategist：AIをどこに、なぜ、どう導入するかを判断する
2. 学び方――AWS公式リソースで組み立てる
学習は、「公式の準備ルートで進める」「押さえる資料を絞る」「試験ガイドを問いに読み替える」の3つで組み立てるのがおすすめです。
公式の準備ルート
AWSの認定ページでは、AWS Skill Builderの試験対策プラン（Exam Prep Plan）を中心に、次の4ステップが案内されています。
| ステップ | やること | 使うリソース |
|---|---|---|
| 1. 全体像をつかむ | 出題範囲と問題形式を確認する | 試験ガイド、AWS Certification Official Practice Question Set |
| 2. 知識の穴を埋める | 手薄な分野を補う | Skill Builderのデジタルコース |
| 3. 演習して振り返る | ドメインごとの論点を見直し、弱点を洗い出す | 試験形式の練習問題 |
| 4. 仕上がりを確認する | 本番に近い形式で準備状況を確かめる | AWS Certification Official Practice Exam（ベータ期間中は提供なし） |
目を通しておきたい公式資料と考え方
試験ガイドで推奨されている知識のうち、押さえておきたいのは次の領域です。具体的な操作手順を暗記するよりも、各サービスやフレームワークの目的・特徴と、ビジネス上の使い分けを説明できるようにしておくことが重要です。
| 分類 | 対象 | 押さえるポイント |
|---|---|---|
| フレームワーク | AWS Cloud Adoption Framework for AI（CAF-AI） | 組織として導入を計画し、段階的に拡大する考え方 |
| AWS Well-Architected Framework の Responsible AI Lens | 責任あるAIを設計・運用するときの観点 | |
| AIワークロードの責任共有モデル | AWSと利用者がそれぞれ担う責任の範囲 | |
| コスト | 課金方式（使用量・インスタンス・シート）、AWS Cost Explorerなど | 費用の見積もりと最適化の考え方 |
| 調達 | AWS Marketplace | 構築・購入・パートナー活用を比較するときの選択肢 |
| サービス | Amazon Bedrock、Amazon SageMaker AI、Amazon Quickなど | 想定される用途と、ビジネス上の使い分け |
※試験ガイドの記載範囲に基づく整理です。個々のサービスの出題頻度を示すものではありません。
試験ガイドは「判断の問いリスト」として読む
この試験の対策は、画面操作の暗記よりも、状況から適切な判断を考える練習が中心になります。個人的に役立ったのは、試験ガイドのスキルを「自分ならどう判断するか」という問いに読み替える方法です。
| 試験ガイドのスキル（要約） | 自分への問い |
|---|---|
| AIが適切な解決策ではない場合を判断する（2.1.4） | その課題は、本当にAIを使うべきか？ |
| 導入前にベースライン指標を確立する（2.2.2） | 効果を測るための比較基準はあるか？ |
| 施策の拡大・一時停止・中止を判断する（2.1.3） | 続ける基準だけでなく、止める基準もあるか？ |
| 人による監督が必要な場面と安全策を見極める（3.1.4） | どのリスクに、どの程度の人による確認が必要か？ |
| 部門横断チームをつくり責任を明確にする（4.3.2） | 誰が推進し、誰が説明責任を負うか？ |
| 反復的な変革アプローチを適用する（4.4.1） | 今はどの段階にあり、次に進む条件は何か？ |
※原文は各ドメインのページで確認できます：ドメイン2／ドメイン3／ドメイン4
こうして読むと、試験ガイド自体がAI導入プロジェクトのチェックリストにも見えてきます。
3. 学習のポイント――AI導入を考える5つの視点
試験ガイドを読み込む中で特に大事だと感じたのは、技術の選び方そのものより、AIを使う目的を明確にし、組織として価値を出し続けるための考え方です。ここでは学習のポイントとして整理します。
前提：AI導入を進める4つのフェーズ
5つの視点の前提として押さえておきたいのが、AI導入を段階的に進めるフェーズの考え方です。試験ガイドのスキル4.4.1では、反復的な変革アプローチのフェーズとして
「構想（Envision）→ 実験（Experiment）→ 起動（Launch）→ スケーリング（Scale）」
が挙げられています。一度に全部やろうとせず、小さく試して確かめながら、このサイクルを繰り返して広げていくのが基本です。
AI導入を考える5つの視点
以下の5つの視点は、試験ガイドとCAF-AIをもとに、学習を通じて整理したものです。実際の試験問題・選択肢の内容や正答パターンを示すものではありません。
| 視点 | 考え方 | 主なフェーズ |
|---|---|---|
| 1. 小さく始めて、測ってから広げる | 最初に成果と測定方法を決める | 構想・実験 |
| 2. 揃えるけど、縛りすぎない | 方針は共有し、統制はリスクに応じて調整する | 起動・スケーリング |
| 3. 任せきらない、抱え込まない | AIと人の役割をリスクに応じて設計する | 起動・スケーリング |
| 4. 善意に頼らず、仕組みにする | 体制・責任・評価・育成を整える | 構想・スケーリング |
| 5. 使えるところに、適切な技術を使う | 課題に合う最小限の手段を選ぶ | 構想・実験 |
視点1｜小さく始めて、測ってから広げる
出発点は「AIで何ができるか」ではなく、「どの課題を解決したいか」です。対象を絞って始め、導入前の状況と比較して効果を確認し、拡大するかどうかを判断します。
比較する指標がなければ、先に測定方法を整える必要があります。必要なデータが不足している場合も、追加で収集するのか、検証範囲を狭めるのか、それとも取り組みを保留するのかを判断しなくてはいけません。
なお、探索的なPoCのように、最初から成果を数字にしにくい取り組みもあります。その場合でも、何を確かめたいのか（仮説）と、どうなったら続ける・やめるのかの観点だけは先に決めておくと、「やってみたけれど判断できない」状態を避けられます。
視点2｜揃えるけど、縛りすぎない
ガバナンスは必要ですが、あらゆる用途を一律に禁止したり、重い承認手続きを課したりすると、現場の利用を妨げる可能性があります。一方で、無制限な利用は情報漏えいや不適切な判断を招きかねません。
組織全体で共有すべき方針を定めたうえで、扱う情報の機密性、業務への影響、誤回答時のリスクなどに応じて統制を変える。これが現実的だと思います。誰のデータを、誰が、どこまで参照できるのかを先に決めておかないと、利用範囲を広げる段階で統制が追いつかなくなります。
視点3｜任せきらない、抱え込まない
AIの出力を人がまったく確認せずに重要な判断へ使うことにはリスクがあります。一方で、用途にかかわらずすべての出力を人が確認すれば、期待した業務効率化が得られないかもしれません。
大切なのは、人が確認する条件をリスクに応じて設計することです。影響が大きい業務では承認やエスカレーションを設け、低リスクな用途では自動処理と事後監視を組み合わせるなど、用途に応じて判断します。
視点4｜善意に頼らず、仕組みにする
外部パートナーの技術やノウハウを活用することと、判断や説明責任まで外部へ委ねることは別です。組織内に意思決定の責任者を置き、技術・業務・法務・コンプライアンスなどが連携できる体制を整える必要があります。
CoE（Center of Excellence）のような横断組織も選択肢ですが、大切なのは名称よりも役割と機能です。よくあるのが、「詳しい人が善意で兼務している」状態のまま取り組みが広がっていくケースです。これでは本業との兼ね合いで活動が止まったり、その人が異動した途端にノウハウが失われたりと、施策が特定の個人に依存してしまいます。
視点5｜使えるところに、適切な技術を使う
AIを導入すると決めても、すべてを生成AIで実現する必要はありません。ルールベースの処理や従来の機械学習（ML）が適している業務もあります。生成AIを使う場合も、既存の基盤モデルをそのまま使うのか、社内情報をRAGで参照するのか、モデルをカスタマイズするのかは、課題によって異なります。
たとえば、最新の社内資料を参照させたいならRAGが候補になります。一方で、出力形式や特定タスクへの適応が主な課題なら、プロンプトだけで対応できる場合もあります。ファインチューニングにはデータ整備、評価、運用コストが伴うため、必要性を確かめて選ぶべきです。
まとめ
AIB-C01を受けて感じたのは、AIを「作る」ことと「事業にする」ことの間には、もう一段の判断があるということです。
AIを使うべき課題を見極め、効果を測り、関係者の足並みを揃え、責任と統制を設計する。そして小さな実証を、組織として続けられる取り組みに育てていく。試験ガイドに示される4つのフェーズは、この流れを整理するのに役立ちます。
こうした考え方自体は、業務改革やシステム導入にも通じるものです。そこに出力の不確実性やデータ利用のリスクといったAI固有の論点が重なるところに、この認定ならではの面白さがあります。
エンジニアにとっても、技術的に実現できることと、事業として実行すべきことの違いを考える良い機会になります。AI導入を進める立場の方は、自分の判断基準を棚卸しするつもりで受けてみてはいかがでしょうか。