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導入に関わるビジネス側の方はもちろん、エンジニアが「導入の前後」を体系的に整理するのにも良い資格だと思います。

参考