AIの導入における最大の障害は、認知度ではありません。AIについて語ることと、それを使って構築することの間にあるギャップです。
主な役割がコードを書くことではないものの、日々の業務がAIソリューションにますます依存しているプロフェッショナルは、AIの能力を構築し始めるためにエンジニアリングのバックグラウンドを必要としません。彼らに必要なのは、適切なツール、構造化されたサポート、そして失敗することへの許可です。ここでは、私たちがそれを実証した方法と、あなたがそれを再現できる方法を紹介します。
組織が無視している問題
あなたのチームはすでにAIに関する会話の中にいます。顧客からの質問への対応、ベンダーソリューションの評価、あるいは日々の業務における自動化の機会の特定などを行っているでしょう。エージェント型AIツールが一般に利用可能になるまでのスピードを考えれば、そのほとんどのメンバーは、話題にしているツールを使って何かを作った経験が一度もないはずです。
営業、オペレーション、財務、プロダクトのいずれの部門に所属していても、これらのチームはデモを見て、認定資格を取得してきました。しかし、誰かに「実際にはどう動くのですか?」と聞かれたとき、自分自身で構築した経験から得られる答えを持っていないのです。
そのコストは確実に存在します。導入の遅れ、生産性向上の遅延、ユースケース特定の機会の逸失、そしてチームが(以下に続く) について知る また、それらに何ができるかについても 実装します。
ビジネスプロフェッショナル、つまり本番コードを書くわけではないもののAIツールを日常的に使う人々に、AI導入の妨げになっていたものは何かを尋ねました。答えは「学びたくない」ではありませんでした。90パーセントがAIエージェントを構築する実践的な経験を望んでいました。彼らには、安全に構築するための接続組織となる仕組みや足場が欠けていました。次のチャートは、ビジネスチームがAIを使って構築しようとする際に直面する最も一般的な障壁を示しています。
図1：AIを活用した開発における事業チームが挙げる主な障壁
高いレベルで言えば、彼らは以下のことについて話すことができます Amazon Bedrock および Amazon Bedrock AgentCore、あらゆるフレームワークやモデルでエージェントを大規模に構築、接続、最適化するプラットフォーム(80パーセントが利用を検討済み)。しかし、Strands Agents SDK に触れたり、それを使って構築したことは5人に1人未満だった。 AWS Lambda エージェントが登場する前、彼らはハッカソンやビルドイベントへの参加を見合わせていました。自分の技術知識がエンジニアと競えるほど十分ではないと信じていたからです。
これを解決するために、私たちはビジネスプロフェッショナルとメンターおよび本番レベルのツールを組み合わせ、プログラムを超えてスケールできる動作するAIプロトタイプを構築させる6週間の構造化プログラムを設計しました。目標は、概念的な知識と実践的なスキルの間のギャップを埋めることです。
あるチームが構築したもの:6週間での証明
エンジニアリングのバックグラウンドを持たない、それまで一緒に働いたことのない4人の顧客対応の専門家が、私たちのプログラムに参加しました。6週間後、彼らはプロトタイプ「WealthWise」— マルチエージェントAIによるファイナンシャルアドバイザリーツール — を発表し、第1位を獲得しました。
彼らが構築したもの:
- 5人の専門特化したAIエージェント 知的なファイナンシャルアドバイザリーの提供:ポートフォリオ分析、リスク評価、ファイナンシャルプランニング、市場インサイト、そしてパーソナライズされた投資推奨。
- デュアルサーバーアーキテクチャ (
Node.js+ Python Flask) を Amazon Nova モデルと共に使用します。 - Strands Agents SDK マルチエージェントのオーケストレーションと会話メモリーのための。
- 4つのAmazon DynamoDBテーブル リアルタイムのデータ永続化のため。
- ライブ市場データの統合 文脈に応じた金融レコメンデーションのため。
- 5秒未満の応答時間 複雑な金融推論のため。
このシステムは協調的な意思決定を特徴としています。各エージェントはどのツールを呼び出すかを独立して判断し、複数のツールを連鎖させ、ポートフォリオデータ、市場データベース、金融プランニングモデルを横断してマルチステップの推論を実行します。
彼らは初日に設定した5つの原則が成功につながったと語っています。
- 勝利よりも学び — 安全な近道ではなく困難なアプローチを選ぶことで、恐れず実験できるようになりました。
- 定期的なペース — 毎日のスタンドアップミーティングが孤立を防ぎ、問題を早期に発見しました。
- 最小実行可能製品（MVP）から始め、その後に改良する — 2日目にはエンドツーエンドの動作フローを完成させ、その後反復しました。
- オフィスアワーへの参加 — 行き詰まったときは積極的にメンターシップを求めました。
- 楽しむこと — 技術的な成果の前に、心理的安全性を確保しました。
参加者は、ハンズオン形式が学びを加速させたと振り返りました。
「ハッカソンのタイミングは最高で、ハンズオン形式はAgentCoreの理解習得に非常に価値がありました。長い学習曲線になる可能性があったものを加速させることができました。」
「素晴らしいチームビルディングとAI学習プロジェクトでした！多くのことを独学で学び、AIソリューションを初めて使うお客様への共感も深まりました。」
* Amazon Novaモデルは、一部のAWSリージョンのAmazon Bedrockで利用可能です。最新の利用可能状況については、AWS Regional Servicesのページをご覧ください。
プレイブック: プログラムをどのように設計したか
以下のセクションでは、プログラムの構造、各フェーズ、そしてプログラムを成功させた設計上の決定事項を解説します。
プログラムの構造
このプログラムは6週間にわたって実施され、参加者は週に約4時間を充てます。私たちは意図的にこのような構造にしました。プログラムデータによれば、段階的なプログラムを完遂した参加者は、集中的な2日間形式の参加者に比べて、実践的なスキルを3倍多く定着させました。日常業務でコードを書かないプロフェッショナルには、反復のサイクルが必要です。すなわち、慣れない概念に苦労し、立ち直り、自信が定着する前に再度構築するための時間です。
フェーズ 0: リクルートとプログラムのセットアップ
参加者は、マネージャーの指名、Slack、メールキャンペーンを通じてリクルートしました。対象は、AIソリューションを日常的に扱うが構築はしないプロフェッショナル、すなわちアカウントマネージャー、ソリューションコンサルタント、オペレーションアナリスト、プログラムマネージャーなどの役職です。まず経営層の承認を得ました。チームリーダーに時間的コミットメント(6週間で週4時間)を説明し、日常のデリバリーからの脱線ではなく、熟練度と会話の質への投資として位置づけました。
プログラムは、4人のコアチームメンバーと、本業と並行して運営に参加したメンターによって調整されました。これが再現性の鍵となるポイントです。専任のプログラムチームは必要ありませんが、参加者の時間を守れるだけの組織的な信頼を持つ人が少なくとも1人は必要です。
フェーズ 1: チーム結成とキックオフ
参加者の作業: 意図的に経験レベルの異なるメンバーを混ぜた3〜4人のチームを結成します。各チームは、自身の役割で遭遇した実際のシナリオに結びついた問題定義を策定します。
この成果: デモ可能な範囲が定められたプロジェクトのコンセプトと、チームの責任体制。
次に進む前にこれが重要な理由: 解決すべき具体的な問題がないと、有効化セッションは抽象的なものになります。先に対象ユースケースを定義したチームは、目的を持って技術コンテンツを吸収します。
フェーズ 2: 有効化(エネーブルメント)
参加者の作業: エージェント型AIの概念とAWSツールに関するライブトレーニングセッションに参加します。これらは講義ではありません。参加者はビルドフェーズで実際に使用するツールの中で作業し、プロジェクト作業を反映した構造化された演習を完了します。
この成果: 基礎的な技術の熟練度と、動作するローカル環境。
次に進む前にこれが重要な理由: いきなり構築に取り掛かるチームは、環境構築と基礎概念で壁にぶつかります。このフェーズは最も多い脱落ポイントを回避します。
フェーズ 3: アイデア出し、構築、開発
参加者の作業: 複数週にわたって動作するプロトタイプを設計し、反復改善します。各チームには技術的に優秀なメンターが付き、セーフティネットとして機能します。インフラの問題を解消し、アーキテクチャパターンを提案しますが、作業そのものは代わりに行いません。
この成果: ステークホルダーや顧客にデモできる機能的なプロトタイプ。
次に進む前にこれが重要な理由: 長めのスケジュールにより、2〜3回の反復サイクルが可能になります。第3週にプロトタイプを構築したチームは、新しい学びを継続的に適用し、分解して、第5週により良いものとして再構築する時間がありました。この反復こそが、本当の学びが起こる場です。
フェーズ 4: 審査とデモ
参加者の作業: 5つのカテゴリー、すなわちビジネスインパクト、技術的卓越性、再利用性とスケーラビリティ、革新性、プレゼンテーション品質にわたって評価されるライブデモを実施します。
成果物: ピア検証済みの能力の証明と、再利用可能なプロトタイプのライブラリ。
なぜこれが重要なのか: デモ形式は、参加者が顧客、経営層、そして部門横断のパートナーとの実際の会話で行うことをそのまま反映しています。審査基準は、 動くもの を作るだけでは不十分であることを裏付けています。インパクトがあり、スケーラブルで、明確に伝わるものでなければなりません。
重要な設計上の決定
ツールの選択は、エンジニアではないビルダーにとって最も重要な決定です。間違ったツールは勢いを止める摩擦を生みます。適切なツールはインフラを抽象化し、人々の現在の習熟度に合わせて提供されます。私たちが選んだのは:
- Kiro 自然言語開発のための統合開発環境(IDE):欲しいものを記述すると、アーキテクチャの雛形を生成します。
- そのリージョンで利用可能なAPIアクセス可能な基盤モデルのためのAmazon Bedrock:モデルから動作する応答を得るために機械学習(ML)の専門知識は不要です。
- 構成可能なエージェントパターンのためのStrands Agents SDK:エージェントは building blocks のように組み合わせられます。
- AWS Model Context Protocol (MCP) サーバー とAWS Lambdaエージェントにより、ローカルのノートブックだけでなく、デプロイ可能な本番グレードのアーキテクチャへとチームを導きます。
核となる原則は決して変わりませんでした:短い告知でデモできる、本物の何かを構築すること。
本業への影響の管理
週間の学習時間は意図的に週4時間とし、その時間帯については参加者の柔軟性を認めました。最も多かった意見は、参加者が最初の2週間以内に学んだことを仕事に直接応用でき、その結果、時間の投資が競合するものではなく付け足しのものだと感じられた、というものでした。
その結果
以下のチャートは、AIコンピテンシー、ツールの活用、顧客との応用への準備性を含む8つの主要指標について、プログラム前後の参加者の自己評価を比較したものです。
図2: プログラム前後の参加者自己評価
参加者は開始時に、AIを使った開発における最大の障壁として「実世界の事例の不足」を挙げていました。終了時には、実用的なユースケースにAIを適用することへの自信があると自己評価した参加者が、開始時に予想していた数より23ポイント(パーセントポイント、pp)多くなりました。参加者は、ステークホルダーにすぐにデモできる動作するプロトタイプ、コードリポジトリ、リファレンスアーキテクチャを手にしてプログラムを終えました。
彼らが構築し、顧客に提供しようとしているもの:
- 医療系独立系ソフトウェアベンダー(ISV)向けのマルチエージェントによるケア調整。
- コンテンツモデレーションおよびトリアージシステム。
- 詐欺の特定と防止。
- 顧客離脱の予測と防止。
- 自律的な意思決定のためのマルチエージェントオーケストレーション。
- 顧客ワークショップ向けのKiro + Amazon Bedrock AgentCoreデモ。
その影響:観察者から構築者へ
参加者がAIツールを実際に扱えるようになると、可能性を議論する段階から、動作するプロトタイプの構築へと移行しました。数字がその物語を物語っています。
- エージェントAIに関する自己評価「強いまたは専門家レベル」の理解度:27パーセントから82パーセントへ増加(+55ポイント)。
- AIの機会を特定する上で「十分または極めて準備が整っている」と感じる割合:41パーセントから85パーセントへ増加(+44ポイント)。
- 理論のみの経験または限られた経験しかない参加者:34パーセントから0パーセントに減少(対象外)。
これに投資することで実現できることは次のとおりです:
あなたのチームのために: 彼らはAIの観察者であることをやめ、AIの構築者になります。直接実験を通じて、何が実現可能で、何が高くつき、何が週末で作れるものなのかを理解しています。私たちのコホートでは、52％が、自分たちが構築したものから恩恵を受けられる具体的な顧客を特定していました の間に 番組（プログラム）に参加した87％が、30日以内に顧客とのやり取りで学んだ内容を活用する予定でした。このプログラムは、参加者自身が実例を作成することが求められたため、実用的なユースケースにおいて期待以上の成果を上げました。
あなたのエンジニアリング組織向けに: ビジネス側の担当者がプロトタイプを作成し、アーキテクチャのトレードオフを言語化できるようになると、エンジニアリングチームは要件の翻訳に費やす時間を減らし、構築により多くの時間を割けるようになります。技術志向のビルダーにとっては、より明確な受け入れ、整合しない要求の減少、そして1つのスプリントもコミットする前に実現可能性を検証してくれるパートナーが得られます。考えてみてください: 参加者の82パーセントが、エージェンティックAIアーキテクチャに対する深い理解を得て会場を後にしました。ツールの習熟度はスタック全体で急上昇しました: Strands Agents SDKは採用率が20パーセントから80パーセントへ(+60 pp)、AgentCoreは39パーセントから85パーセントへと上昇し、エンジニアリングの判断力のハードルが引き上げられました。
お客様のために: パートナーは、直面しているアーキテクチャ上のトレードオフを実際に自分の手で経験して乗り越えてきた相手を得ることができます。会話は「後でご連絡します」から、その場でのライブデモへと変わります。プログラム開始前は、参加者の44パーセントが、アーキテクチャパターンに関する不確実性を障壁として挙げていました。プログラム終了後は、90パーセントが、実際の顧客との会話でAIの機会を見極める準備が十分に整っている、あるいはそれ以上だと感じていました。
組織向けに: 再現可能で、複利的に拡大するモデルが手に入ります。パイロットが1チームから地域展開、そして現在はグローバル展開に拡大したことは、このパターンを物語っています。実践的な熟練度は自らスケールするのです。このプログラムは100パーセントの推薦率を達成し、参加者の95パーセントがプログラムは期待に応えた、あるいは期待を上回ったと回答しました。
あなたの組織でこれを実現するための7つの教訓
これらの7つの教訓は、このプログラムを成功に導いた要因と、自組織で再現すべきポイントをまとめたものです。
1. ツールの選択ですべてが変わる
ローコードのエージェント型エクスペリエンスは、「自分は技術力が足りない」という壁を取り払います。これは調達の後付けではなく、プログラム設計の決定事項です。ツールにPythonの習熟を要求するなら、1週目を迎える前に会場の半分を失っていることになります。
2. 構造が強度に勝る
明確なマイルストーンを持つ段階的プログラム(6週間)は、非技術者向けのオーディエンスにとって、2日間の集中的なスプリントよりも効果的です。最初の1週間は遅く感じることを想定しておいてください。複利のような効果はその後に現れます。
3. メンターシップは掛け算の要素
非技術者の参加者と技術に精通したメンターをペアにすることで、失敗への恐怖が取り除かれ、学習が加速します。メンターは本人の代わりに作るのではありません。セーフティネットを提供するのです。
4. 本物を作る
スライドではなく、コードリポジトリとリファレンスアーキテクチャを備えた動作するプロトタイプを求めることで、ツールとの深い関わりが強制されます。ライブデモでごまかすことはできません。これこそがハッカソンを研修コースから切り離すものです。
5. 実施前後の測定
実施前後でのコンピテンシー評価により、そのインパクトを可視化し、拡大に向けたビジネス上の根拠を築くことができます。自己申告による自信度も有用ですが、重要なのは「限定的」から「幅広い」実践経験への変化です。
6. 再現可能にする
よく整備されたプレイブック(参加者向けガイドライン、評価ルーブリック、メンターのペアリングフレームワーク、環境セットアップガイド)があれば、単発のイベントをスケール可能なプログラムに変えることができます。
7. まず心理的安全性を確保する
人が失敗を恐れなくなると、自分でも思いもよらないものを作り上げます。優勝チームは「勝つことより学ぶこと」を最優先の原則として挙げました。好成績を収めたすべてのチームが、コードを書く前に信頼関係を築いていました。
はじめに
このモデルを再現したいチーム向けに、プレイブック、評価ルーブリック、環境セットアップガイドが公開されています。このフレームワークを自組織に導入する方法について詳しくは、著者の一人までお問い合わせください。
詳細については、以下を参照してください: Amazon Bedrock | Kiro IDE | Strands Agents SDK