著：素数カブトムシ

この記事は、2026 年 9 月 1 日に Ania Braszkiewicz、Yi Zhang によって執筆された「 Introducing AWS Certified AI Business Strategist: Built for the people who scale AI 」を翻訳したものです。 すべての AI の取り組みには、2 種類の仕事が同時に発生します。1 つは「構築」です。モデル、インフラストラクチャ、コードがこれにあたります。もう 1 つは「意思決定」です。どの投資に資金を充てるか、成功をどう測定するか、どのようなガバナンスを整備するか、いつスケールし、いつ止めるかを決めることです。AWS は長年にわたり技術的なビルダーを認定してきました。そして 9 月 1 日より、ビルダーと共に AI 導入を推進する方向けに特化した認定を開始します。 AWS Certified AI Business Strategist は、組織内で AI の取り組みを評価し、推進し、スケールさせるプロフェッショナルのための新しい認定です。対象となるのは、チーム全体で導入を進める事業部門のリーダー、顧客に AI の価値を伝える営業プロフェッショナル、実験段階から本番稼働まで顧客の戦略を導くコンサルタント、AI 投資をビジネス成果に結びつけるプログラムマネージャーです。この試験は、企業を舞台にしたシナリオを通じて、汎用的なビジネス判断力を検証します。AWS のサービスは実践的な文脈として登場しますが、それ自体が試験の対象ではありません。この認定が検証するフレームワークは、組織や業界を越えて適用可能です。 その点が、単一プロバイダーの製品、プラットフォーム、技術スタックに特化した知識を問う認定資格とは異なります。また、履修に数か月、数千ドルを要するアカデミックなプログラムや、より低コストでも数週間を要するオンラインプログラムとも異なります。これは厳格な試験監督付きの試験であり、業界で認知された資格として戦略的スキルを検証し、すぐに履歴書に記載できます。 あなたはすでに AI 導入を推進しています。そして今、それを認めてくれる資格があります。 この認定を作った理由 いまだに多くの組織が、AI を単なる技術的な取り組みとして捉えています。しかし AI は戦略的なビジネスの取り組みでもあり、AI をスケールさせるには、構築とは異なるスキルセットが必要です。 私たちは業界を問わず、お客様から同じ声を聞いてきました。中堅のプロフェッショナルやシニアの現場担当者が AI の成果に責任を負っているにもかかわらず、それをリードするスキルを持っていることを証明できずにいました。チームは、本質的にはビジネス価値に関する意思決定を技術スタッフに頼っていました。どのユースケースを優先するか、説得力のあるビジネスケースをどう構築するか、どのようなガバナンスを整備するか、パイロット段階の先へどうスケールさせるか、といった判断です。これらは判断を要する事柄ですが、組織にはその判断をうまく下せる人材を見極めたり育成したりする手段がありませんでした。 私たちはまた、営業、コンサルティング、オペレーション、ビジネスリーダーの各職種のプロフェッショナルからも声を聞きました。彼らは、技術的な実装ではなく戦略的な意思決定に即した認定資格を求めていました。中には、すでに AWS Certified AI Practitioner (AIF) を取得し、そこで得られた技術的な基礎を高く評価している方もいました。しかし、彼らが行っている日々の業務には異なる種類の裏付けが必要でした。AWS Certified AI Practitioner (AIF) は技術的な理解を検証します。AWS Certified AI Business Strategist (AIB) はビジネス判断力を検証します。トランスフォーメーションには、その両方が必要です。 そこで私たちはこの認定を作りました。この試験は、AI の取り組みに携わる、あるいはその周辺で働く経験を 6 か月以上持つプロフェッショナル向けに設計されています。コーディング、AWS の実装経験、他の AWS 認定は必要ありません。 この認定があなたにとって重要な理由 あなたも自分の組織で目にしたことがあるかもしれません。AI ツールは利用でき、技術者もそろっているのに、「取り組みがパイロットから抜け出せない停滞状態にはまり込んでいる」という状況です。最近の Harvard Business Review の調査によると、AI 導入による運用上の負担は中間管理職が負っているということが分かりました。彼らは、正式な支援や全社的なガイダンスなしに、AI の使用基準、品質、ガバナンスに関する重要な決定を単独で行っています ( HBR, 2026 )。このパターンは至るところで起きています。現在、88% の組織が少なくとも 1 つの業務機能で AI を利用しています ( McKinsey, 2025 )。それにもかかわらず、その取り組みが有意義なビジネス成果を生んでいると答えたのはわずか 19% でした ( ServiceNow/Oxford Economics, 2025 )。 その理由は構造的なものです。ほとんどの組織は、業務そのものを再設計することなく、既存のワークフローに AI を組み込んでいます。パイロットの停滞から抜け出すには、どのツールを使うべきかだけでなく、仕事の進め方そのものを再考できる専門家が必要です。 そのギャップを埋められるプロフェッショナルこそ、組織が最も必要とする人材です。どのユースケースが投資に値するかを評価し、現実的な期待値を設定するビジネスケースを構築し、規模拡大に必要な変革を管理できる人々です。雇用主も、それに応じた報酬を支払っています。 AI によって人間の専門知識の必要性が高まる職種では、AI によって非専門家にとって作業が容易になる職種と比べて、賃金の伸びが 42% 高くなっています ( PwC, 2026 Global AI Jobs Barometer )。AI 資格を持っている労働者は、そうでない同業者よりも 3.5 倍速く昇進しています ( Randstad, 2026 年 5 月 )。また、学位以外の資格は、キャリア中盤での停滞リスクを平均 29% 低減します ( NYU/Burning Glass Institute, 2026 )。 これらのスキルを検証する手段がなければ、プロフェッショナルは、すでに十分な実力があるにも関わらず AI リーダーシップの役割から見落とされてしまうリスクがあります。すでに AWS の技術認定を取得している場合、この資格はそれを補完します。何を、なぜ構築するのかを形づくる戦略的なレイヤーを検証するからです。技術的な実装と AI ビジネス戦略の両方で認定されたプロフェッショナルが組織にいれば、チームは機会を評価するための共通のフレームワークを共有でき、意思決定をより迅速に進めることができます。 試験で問われる内容 この試験は、現実のビジネス状況に即したシナリオベースの設問を通じて、4 つの領域を対象とします。 AI の基礎とリテラシー は、ビジネスの文脈における AI の概念、能力、制限についての実践的な理解度を問います。提案された AI ソリューションが課題に適しているかどうかを評価し、技術チームに適切な質問を投げかけるために必要な知識です。 AI 戦略とビジネス価値の創造 は出題比率が最も高い領域です。ユースケースを評価し、ビジネスケースを構築し、ROI を定量化し、AI が適切なソリューションではないケースを見極める能力を評価します。あるベンダーが 200 万ドルの AI 導入を提案してきたとします。その投資が妥当なのか、時期尚早なのか、あるいは重要な成功要因を欠いているのかを、あなたは評価できるでしょうか? AI ガバナンスと責任ある AI リーダーシップ は、ガバナンス構造を確立し、企業の AI リスクを管理し、規制要件に対応する能力を評価します。ガバナンスを省いた組織が速く進めるわけではありません。コンプライアンス、法務、レピュテーションに関する懸念が後から追いついたときに停滞します。 ビジネス準備状況、リーダーシップ、AI トランスフォーメーション は、組織の準備状況を評価し、変革を管理し、取り組みをパイロットから企業規模の展開へと進める能力を評価します。 準備の方法 AWS Skill Builder には、必要なものがすべてそろっています。この分野が初めての場合は、 AI Business Strategist ロール向けのデジタルコース から始めてください。このコースは 13 のモジュールにわたり、4 つの試験領域に直接対応しています。デジタルコースを修了したら、 認定試験の準備プラン に従って残りのギャップを特定し、 Practice Question Set で練習しましょう。すでに経験がある場合は、試験準備プランから始めてください。 ※ 訳者注: 2026 年 9 月 4 日現在、デジタルコースは英語版のみでの提供となります。 上記のコースを選択される前に、Skill Builder の上部メニュー内「アカウント」→「プロフィール」内の「AWS Training and Certification の設定」より「言語」を英語に変更してからご確認ください。 はじめましょう ベータ試験の登録は 2026 年 9 月 1 日に開始し、試験の提供は 9 月 29 日から始まります。ベータ試験は英語と日本語で受験でき、一般提供の開始時にはさらに多くの言語が利用可能になります。2027 年 2 月 15 日までにこの認定を取得した受験者には、通常の認定資格バッジに加えてアーリーアドプターバッジが付与されます。 次にあなたの組織が「これに投資すべきか ?」あるいは「うまくいっているものをどうスケールさせるか ?」と問うとき、AI の段階的な成果を大きな変革へと転換できる人材になりましょう。それを裏付ける認定資格とともに。 ベータ試験への登録はこちら → 翻訳は Technical Instructor の 室橋 弘和 が担当しました。

こんにちは。タイミーでプロダクトエンジニアをしている津守です。 普段は、エンジニアとして機能の開発をメインの仕事としていますが、最近は営業チームの商談に同行する機会が増えてきました。そこで突きつけられたのが、タイトルの問いです。 自分が作った機能を、自分で売れるか。 機能は作れる。仕様も説明できる。でも、顧客を前にして「これはあなたの課題をこう解決します」と語り、納得してもらえるか。やってみると想像以上に難しく、同時に開発者として得るものが大きい体験でした。 この記事では、商談同行を重ねる中で見えてきたことと、そこから営業メンバーとの間に育っていったコミュニケーションパスについてまとめます。9月5日開催の Product Engineering Conference 2026 （以下、PdEConf 2026）が掲げる「職能の壁を越え、プロダクト価値を最大化させる」というテーマの、ひとつの実践記録として読んでもらえると嬉しいです。 なぜ「自分で売ってみよう」と思ったのか きっかけは、チームで開発した機能がなかなか顧客に活用されない、という課題感でした。 タイミーでは、営業が顧客にしっかり伴走しながらプロダクト導入後もサポートするコンサルティングに近い構造です。機能案内なども都度丁寧に行う体制ではありますが、新しく作った機能の導入は思うように広がりませんでした。チームとしては必要とされる機能を開発している認識でしたが、それがなかなか使われない。なぜ使われないのかという疑問に加え、使われなければ当初予定していた検証も進みません。 どうすれば営業メンバーの理解を得て、機能を届けられるのか。スプリントレビューの運用を見直して情報伝達を改善し、営業行動ログから提案状況も追いました。しかし、解消には至りませんでした。 チーム内に閉じた取り組みでは答えが出ないので、まずは「自分が作った機能は本当に顧客に売れるのか」を現場で感じ取りたい。そう考えて営業メンバーに相談し、商談への同行を始めました。 売ろうとすると、機能の強みと弱みがわかる 実際に商談の場で機能を説明して真っ先に気づいたのは、価値を感じてもらえる点と解決できていない点が同時に見えることでした。概要の説明だけで納得してもらえる部分がある一方で、答えに詰まる指摘や、対応しきれていない側面が容赦なく浮き彫りになります。 素朴な質問に十分答えきれず「将来的には対応していきます」としか言えない——。 答えに詰まる箇所は、そのまま営業メンバーが提案しづらい箇所です。 逆に、その場で納得してもらえた説明の切り口は、そのまま営業が使える強みになります。 ユーザーインタビューと違い、商談では自分が価値を証明する側に立ち、顧客も「使うか、使わないか」を判断します。そのため、「使うけれど、ここは不満」という改善要望と、「ここが解決されなければ使わない」という利用の障壁を切り分けられます。既存の運用や他の選択肢との比較も含め、機能がまだ使われていない理由を直接受け取れるのが、商談ならではです。 ユーザーインタビューと商談同行の違い ただし、注意しなければいけない点もあります。商談で聞いた一社・一人の意見は実在する課題ですが、優先すべき課題かは別問題です。 セールス主導開発の滑りやすい坂道 が指摘するように、商談同行は使い方を誤れば、一社の要望を過度に優先した開発の入り口にもなります。複数のユーザーに聞いて「重なる課題感」に手をつけながら、個別事例には深く踏み込む。この具体と抽象の行き来と、 定常的に顧客接点を持ち続ける ことが必要です。 「自分が売れた」で終わらせない ― プロダクトを売れる形で提供する 自分が同行した商談での提案がきっかけで売上に貢献できると、素直に嬉しいです。「自分で作った機能を自分で売れるんだ」という手応えは、ものづくりをする人間にとって強烈な体験ではないでしょうか。ただ、この体験は感動が大きい分、意識しないと「自分で売ること」自体を目指してしまい本来の役割を見失ってしまいます。 エンジニアが商談に同行する意義は、自分が売れるようになることではないと考えています。自分の中で売り方の検証を回し、そこでの学びをプロダクト開発に反映することが本筋です。そのうえで、刺さった提案の仕方や文脈を型化し、営業資料のひな形として渡していく。つまり、 プロダクトを「売れる形」にして提供すること です。改善した機能と、それを説明するための型をセットで渡せば、組織全体で価値を届ける力になります。 営業とともに開発する体制を築く 商談同行は、一度きりで終わらせず継続することで真価を発揮します。同行を重ね、商談後にはその場で営業メンバーと振り返り、機能の強みと弱みを一緒に整理して目線を揃えていく。これを繰り返すことで、営業メンバーとの間に「機能を届ける」ためのコミュニケーションパスができていきました。 一番大きな変化は、商談に関する相談をされるようになったことです。機能説明の商談を控えたメンバーから「この機能はどう勧めるのがいいか」と事前に相談が入る。商談を終えたメンバーから「この質問に上手く答えられなかった」と持ち込まれる。以前はプロダクトへのフィードバックの機会がほぼスプリントレビューだけでしたが、Slack で非同期にこうしたやり取りが行われるようになりました。これらは営業の困りごとであると同時に、機能に対するフィードバックそのものです。相談で出た論点は開発に反映されたり、営業資料のひな形に反映し共有知として残したりしています。 変化は開発チーム側にも起きました。チーム内で商談の内容を共有していくうちに、機能をどう売るかを主題として会話する機会が増え、メンバーの関心が自然と営業の動きへ向いていきました。営業メンバーの日報に開発メンバーがリアクションする光景は、今では当たり前です。 この双方向の関心が重なった結果としてスプリントレビューにも変化がありました。開発チームからの共有会に近かった場が、お互いが「この機能をどう提供するか」の視点で意見を交換し合い、どんなプロダクトにしていくべきかを議論する場になりました。 商談同行で生まれたコミュニケーションパスの変化 この関係性が当たり前になると、 作る前から「これは本当に届けられるのか」という問いに対して、解像度の高い状態で開発を進める環境 が生まれます。一度の商談で得られるのは顧客の課題ですが、続けることで得られるのは、課題が自然に集まってくる関係そのものです。 おわりに 「そのプロダクト、自分で売れるか？」 自分で売ろうとすれば機能の強みと弱みが同時に見え、その学びをプロダクトの価値に還元する。売れるかという問いへの答えを探す過程で、営業メンバーと「作る前から『届けられるか』を検証できる土壌」が育っていきました。 この取り組みは、自分の役職に囚われない動きも必要でしたが、それ以上に営業メンバーが日頃から築いてきた顧客との関係性があったから起こせた行動でもあります。良いことも悪いこともはっきりフィードバックしてもらえる顧客が多いのは、営業メンバーの日々の取り組みのおかげなので本当に感謝しています。 PdEConf 2026 に参加される方で、同じような取り組みをされている方、これから始めようとしている方がいれば、ぜひ会場でお話しできると嬉しいです。