2026年に新設された AWS Certified AI Business Strategist（AIB） を受験してきました。
AIB は、AIの技術そのものよりも、AIをどのように業務に導入し、展開・運用・評価していくか という考え方を扱う資格です。学習と受験を通じて、AI導入プロジェクトを進めるうえで大事な視点を体系的に整理できました。
この記事では、試験ガイドに記載されている知識ドメインごとに、求められている（と感じた）考え方と、資格を通じて得られた知見をまとめます。
この記事の対象読者
- AIB の受験を考えている方
- AIの業務導入に関わる方
- AI導入を「技術」以外の観点で整理したい方
前提
- 受験日：2026年9月29日
-
筆者のバックグラウンド
- エンジニア歴 約8年（インフラ）
- システムの要件定義・導入の業務経験が少しあり
- AIの基本的な概念は把握済み
記事の内容は 受験時点の情報 です。試験の内容や形式は変わる可能性があるため、最新情報は公式ページを確認してください。
試験の概要
| 項目 | 内容 |
|---|---|
| 試験時間 | 180分 |
| 問題数 | 85問 |
| 合格点 | 700点（1000点満点） |
試験時間については他の方が公開している記事で130分や170分と書かれているものもあります。私が受験したときは、受験案内のメールに180minutesと記載されていました。時期や条件によって異なる可能性があるためご自身の試験案内を確認してください。
所感
システムの要件定義や導入の経験があり、AIの基本概念を知っていれば、他の AWS 資格より取り組みやすい難易度でした。
技術的な問題はほとんどなく、AI導入前後の取り決めや、運用中の効果測定・ガバナンス に重点が置かれています。問題文には架空の会社の状況・課題・制約が書かれていて、それらを踏まえて「どう判断するか」を問われるため、実際のプロジェクトでの意思決定に近い感覚で取り組めました。
どのドメインも大きく迷うことはなく、Skill Builder の模擬試験の延長で対応できる 印象です。
知識ドメインごとの考え方と得られた知見
| ドメイン | 配分 | テーマ |
|---|---|---|
| 1. AIの基礎とリテラシー | 24% | AIの基本的な用語・概念を理解する |
| 2. AI戦略とビジネス価値の創出 | 28% | どこから始め、成果をどう測るか |
| 3. AIガバナンスと責任あるリーダーシップ | 24% | リスクとどう向き合い、仕組みで抑えるか |
| 4. ビジネス準備状況、リーダーシップ、AIトランスフォーメーション | 24% | 人・データ・組織の準備を整え、広げていく |
※ ドメイン名と配分は 公式の試験ガイド によります。「テーマ」列は筆者の要約です。
1. AIの基礎とリテラシー
扱うテーマ
- AIの基本的な用語・概念を、業務要件に当てはめる
- 業務の要件と制約に合わせて、AIの利用方法を選ぶ
- プロンプトエンジニアリング、モデルの適応などを使い分ける
求められる知識
基礎のドメインということもあり、考え方というよりは 用語とその意味を知っていること が前提になります。とはいえ高度な専門用語は不要で、AI関連の基本的な用語のレベルで問題ありませんでした。
- 予測・分類・生成などが何を指すのかを理解している
- AI・機械学習・生成 AIの違いを正しく認識している
- プロンプトエンジニアリングやモデルのトレーニングが何を指すのかを理解している
といった基礎的な内容です。
得られた知見
用語の理解は、関係者との認識齟齬をなくす
実務では、エンジニア以外の方と関わる場面も多いと思います。そのような場面で関係者全員が理解できるよう、技術用語を正しく理解し、説明することは、プロジェクトを進めるうえで避けては通れません。用語の理解は、関係者との認識齟齬をなくすための重要な要素だと思います。
2. AI戦略とビジネス価値の創出
扱うテーマ
- 組織の目標に沿って AI戦略を立て、優先順位を付ける
- KPI・ROI・ベースラインで AIのビジネス価値を測る
- AIを競争優位やビジネスモデルの変革につなげる
求められる考え方
「AIを入れること」ではなく「事業の成果を出すこと」をゴールに置く という考え方です。
エンジニアとして技術を追っていると、業務要件よりもベストな設計やスペックを求めてしまうことがあるかもしれません（私も身に覚えがあります…）。このドメインでは、業務要件にどれだけマッチしているか と、それをどのように測定するか に注目する必要があります。
得られた知見
ベースラインと比較対象は導入前に決める
当たり前ですが、比べる基準がないと、導入後に「効果があった」と示せません。導入の前段階の重要な準備であることを再認識しました。
技術指標とビジネス指標は別物
測定やモニタリングの話になると、技術者はメモリ使用量やスループットなどを測りたくなりますが、それらはシステムの健全性を示す数字であって、導入の成果を示す数字ではありません。
エンジニアとしては技術指標に目が行きがちですが、「その数字で導入の効果を説明できるか」 という視点が大切だと再認識しました。
3. AIガバナンスと責任あるリーダーシップ
扱うテーマ
- トレードオフが伴う意思決定で、責任ある AIの原則を当てはめる
- ガバナンスの体制を作り、規制やコンプライアンスに対応する
- 企業で AIを使うときのリスクを見つけ、減らし方を決める
求められる考え方
リスクは個人の注意ではなく「仕組み」で抑える という考え方です。
リスクがあるからといってAIを全面的に利用しないというのは、AWSとしても推奨していないという意図が伝わってきました。
AIの活用はスピードや効率を高めますが、機密データや個人情報の扱い、判断の偏りといったリスクも伴います。それを利用者一人ひとりの注意に任せるのではなく、ルール・権限・承認フローといった仕組みで防ぐ方法を求められます。
AIのアウトプットすべてに人間が介在する場合だと導入の効果が限定的になってしまいますのでリスクと効率の 適切なトレードオフ をどのように行うかが求められていると感じました。
得られた知見
ガバナンスはブレーキではなく、安全に加速するための土台
先にルールと体制を決めておくと、現場は安心して AIを使えます。
AIの利用をやめてしまうという極端な例もありますが、それでは競争上の優位を得られません。導入にあたっては、許容できるリスクを見極める ことが重要だと思います。
AIに任せる部分と、人が介在する部分を分ける
リスクが効率化の効果を上回る用途では、人が判断する・AIを使わないという線引きが必要です。
この「どこまで AIに判断させ、どこに人を挟むか」は、実際の業務でもよく議論になるテーマです。試験でも同じ観点が一貫して問われており、実務の議論を整理する軸として役立つと感じました。
データの扱いは導入前に決める
注意が必要なデータをAIに渡す前に何をどう扱うかを決めておくことが後からの手戻りや事故を防ぎます。
4. ビジネス準備状況、リーダーシップ、AIトランスフォーメーション
扱うテーマ
- 人・プロセス・テクノロジー・ガバナンスの面から、組織の AI準備状況と成熟度を評価する
- AIを支えるデータ基盤・インフラを評価する
- 全社規模の変革を進め、AIを使いこなせる人材を育てる
- パイロットから全社展開へ、段階的に広げる
求められる考え方
AIを使っていくには、技術だけでなく人やデータの準備も必要 という考え方です。
ツールを導入するだけですとAIは定着しません。データが統合・整理されているか、使う人のスキルや体制が整っているかを評価し、足りないものから手当てします。そのうえで、小さく試して効果を確かめながら広げていきます。
特にデータの扱いは、DX の文脈でもよく検討されるテーマです。次のような状況では、AIを正しく運用していくのは難しくなります。
- データは溜まっているが、部門ごとの縦割りで活用できていない
- モデルをトレーニングするための十分なデータが揃っていない
- データに偏り（バイアス）がある
また、人に焦点を当てると、AIで代替できた業務をこれまで担当していた人に、次に何を任せるか も考える必要があります。
得られた知見
データ基盤が AIの成否を分ける
部門ごとにデータが散らばっている状態では、AIの効果は限られます。統合・整理は地味ですが、最初に取り組む価値があります。
また、偏ったデータはモデルの精度に影響するため、データを取得し直したり、トレーニングデータに含めなかったりといった判断も必要だと考えています。
人と組織への投資を後回しにしない
教育や役割の見直しをセットで進めないと、導入したツールが使われずに終わってしまいます。
試験導入 → 検証 → 段階的に拡大
最初から全社展開するより、小さく検証して学びを反映しながら広げる方が、結果的に早く確実に定着します。
どこから始めるかも重要です。ここまでに挙げたように、人が育っていて、データが十分にある部門から導入し、横展開していく のがベターだという知見が得られました。
全体を通して得られた知見
4つのドメインを通じて、一貫していた考え方は次の3つです。
- 業務の成果を起点に考える：AIは手段であり、目的は事業の成果
- リスクは線引きをし、仕組みで抑える：人の注意だけに頼らず、ルールと体制で守る。AIに任せる部分と人が介在する部分を明確に分ける
- 準備を整え、段階的に広げる：データと人の準備をしたうえで、小さく試して広げる
業務への活かし方
AIB で整理できた考え方は、AI導入に関わるプロジェクトでも活かせると感じました。
- 要件定義の段階で ベースラインと KPI を決めておく
- データが揃っている業務から 優先順位を付けて 着手する
- リスクのある使い方には ガバナンスの仕組みを先に用意する
- 業務フローを設計するときに AIに判断させる部分と、人が介在する部分を切り分ける
- ツール導入と合わせて データ整備と人への手当て を計画に入れる
これらを意識するだけでも、「AIを入れたけど効果が分からない」「使われずに終わった」という状況を避けやすくなると思います。
学習方法
事前知識もあったため、学習は数時間程度でした。やったことは次の2つだけです。
- シラバスを確認する：各ドメインで扱うテーマを把握しました
- Skill Builder の模擬試験（20問）を解き、解説を読み込む：正解の理由だけでなく、他の選択肢がなぜ適切でないのかを読むと重視している考え方が見えてきます
システムの要件定義・導入の経験に限らず現場でITに触れている方であれば、業務上リスクのあるところはデフォルトで安全な方に倒すとか、データが整っていないといけないというのは感覚的にわかる範囲かと思いました。
AIの知識についても、プロンプトや基盤モデルといった単語の意味、トレーニングの方法、どのような利用に向いているかなどの理解があればそこまで判断に迷うことはないかと思います。
この辺りがカバーできていればSkill Builderの模擬試験の延長で十分に対応できると感じました。
どんな人におすすめか
| おすすめ |
|---|
| 組織で AIの使い方を決める人（ルール・優先順位・ガバナンスを考える立場） |
| AIを 社内に展開していく人（推進担当・PM・企画職など） |
| AI導入の「前後」を体系的に整理したいエンジニア |
AIを含んだシステムの設計・運用や、モデルのトレーニング手法といった技術的な知見を得たい場合はミスマッチです。その場合は、他のAI関連の資格の方が目的に合うと思います。
おわりに
AWSとしては、AIの活用をどんどん進めてほしいという意図が伝わってくる資格でした。ただし「とにかく AIを使えばよい」のではなく、ガバナンスとデータ・組織の準備を整えたうえで、効果を測りながら段階的に広げる 姿勢が一貫して求められます。
AI導入に関わるビジネス側の方はもちろん、エンジニアが「導入の前後」を体系的に整理するのにも良い資格だと思います。