Atos、AWS と連携し 400 名のエンジニアに実務型 AI エージェント教育を実施

Atos がアジェンティック AI の分野で 400 名のエンジニアを理論から実務へ引き上げるプロジェクトを開始した際、チームは「実践的な能力をどう築くか」というよくある課題に直面しました。単なる知識の習得ではなく、現場で使える力を養うことが求められたのです。

オンライン講座や教室での講義は基礎を固めるには役立ちますが、ビジネス課題に対して AI を効果的に活用するための自信や実践経験まで与えてくれるとは限りません。

Atos と AWS のパートナーシップを通じて、私たちはすでに「実習型学習」が AI 導入において欠けていた重要な要素であることを知っていました。2025 年には、AWS DeepRacer を通じた強化学習の実践的研修や、AI League を活用したモデルのファインチューニングなど、具体的なスキルアッププログラムを提供してきました。

そして 2026 年、Atos は AWS と連携し、400 名のエンジニアを対象にアジェンティック AI リーグを開催しました。3 日間にわたるこのイベントでは、参加者は限られた実習経験から脱却し、経路探索やガードレール機能、メモリ機構、ファインチューニング済みモデルを組み合わせたマルチエージェントシステムの構築に取り組みました。パフォーマンスと効率性の両方を評価するリアルタイムリーダーボードで競い合いました。

参加者のスキルレベルには大きなばらつきがありました。AWS の経験を持つ開発者もいれば、初めて AWS を触る人、あるいはプロダクトオーナーやプロジェクトマネージャーなど技術系ではない役割の人々も含まれていました。

• 5% はアジェンティック AI に関する知識が全くない状態でした。
• 25% はトピックの概要を把握している程度でした。
• 50% は概念は理解していても、実践経験はありませんでした。
• 20% はアジェンティック AI サービスの実務経験を持っていました。

本記事では、なぜ AI League の形式を採用したのか、エンジニアたちが何を構築し学んだのか、また関連する AWS サービスについて解説します。さらに、同様のイベントを運営する他の企業に向けた考慮点についても触れます。

なぜ AWS AI League を選んだのか

アトス（Atos）は、世界中の複数の拠点で「主権型エージェント AI スタジオ」の開発を含む、エージェント AI への戦略的コミットメントを持っています。私たちは、受動的な研修ではなく、実践的な成果物を通じてエンジニアチームのエージェント AI パターンに関するスキルを迅速に向上させる方法が必要でした。従来のワークショップでは概念を教えるにとどまりますが、AI League は実際の納品に近い条件下で実務に取り組むことで、真の能力構築を実現しました。

AI League の形式は、従来の研修と比較して以下のような利点を提供します：

• 即座の実践的応用 – エンジニアたちは単に概念を読むのではなく、実際に動作するエージェントシステムを構築しました。
• 競争による動機付け – リーダーボードが緊迫感と参加意欲を生み出し、受動的な学習では得られないような効果をもたらしました。
• 実際の AWS サービス – イベント中に構築されたすべてのものは、クライアントへの納品で直接使用可能なネイティブの AWS サービスを利用しています。具体的には Amazon Bedrock、Amazon Bedrock AgentCore、AWS Lambda、Kiro、そして Amazon SageMaker です。

測定可能な成果 – AI リーダーボードのスコアは、機能の完全性とソリューションの効率性を反映しています。

時間的コミットメントと形式

AWS AI League はターンキー型のソリューションであるため、セットアップは非常にスムーズでした。必要な作業は、AWS と物流やイベントの詳細について数回の通話を行うこと、およびイベントの周知と参加者情報の収集メカニズムを整えることのみです。

このイベントは AWS Workshop Studio を経由して実施されたため、1 日から 3 日の範囲で開催することが可能でした。エンジニアに最大の柔軟性を提供するため、私たちは 3 日間の形式を採用しました。参加者がコミットする時間は以下の通りです。

• 初回キックオフワークショップ（2 時間） – AI リーグの概要、使用される AWS サービス、および課題の形式を紹介。
• 毎日のオフィスアワー通話（1 時間） – ヘルプが必要なエンジニアやアイデアを共有したいエンジニアへのサポートを提供。
• トップ 3 のフィナーレ（1 時間） – 2026 年のチャンピオンを決める大会。

これらのスケジュールされたセッション以外では、エンジニアは既存の業務に支障がない範囲で、自分のアジェンティック AI ソリューションを自由に反復・改善することができました。

AI リーグの課題内容

エンジニアたちは、ダンジョンの迷路を探索する自律型 AI エージェントを構築しました。このエージェントは地図上の経路を見つけ、さまざまなタイル上の課題を解決し、トラップを回避して宝物に到達する必要があります。これらすべてを、時間制限と限られたライフ（命）の中で完了させることが求められました。

以下の図は、AWS AI リーグのマップ全体の概要を示しています。

Figure 1: Overview of an AWS AI League map

採点モデルでは、以下のような要素が評価されました：

課題の完了は成功として評価され、正解にはポイントが加算されます。一方、不正解の場合はライフ（挑戦回数）が減点されます。

コイン収集では、課題とは異なりリスクがなく、追加時間をかけずに収集できます。

マップのクリアでは、指定された時間内に宝物に到達するとボーナスが得られます。

残存ライフの活用も重要で、課題終了時に残っているライフ1つにつき追加ポイントが付与されます。

効率性においては、簡潔なエージェントの回答の方が冗長な回答よりも高評価となります。

ファインチューニングでは、専門特化型の小規模言語モデルを開発するとボーナスポイントが得られます。

これらの課題タイプは、それぞれ異なる AI エンジニアリングのスキルをテストするものです。

以下の図は、ソリューションのアーキテクチャを示しています。

Figure 2: AWS AI League のアーキテクチャ概要

Amazon Bedrock

Amazon Bedrock を利用することで、エンジニアたちはエージェントの推論を担うモデルにアクセスできました。リージョン別のモデル利用状況については、Amazon Bedrock の AWS リージョン別サポートモデル一覧をご参照ください。

• 異なるタスクに適したモデルを選択します。まずは一般的なモデルから始め、その後、独自にファインチューニングを施したモデルに対して推論を実行します。
• 効率的な回答や、サブエージェント・ツールへの委任を実現するための効果的なシステムプロンプトを設計します。
• トークンの使用量とコストを管理します。

Amazon Bedrock AgentCore

Amazon Bedrock AgentCore は、あらゆるフレームワークやモデルに対応して、大規模にエージェントの構築・接続・最適化を行うプラットフォームです。エンジニアたちはこれを利用してマルチエージェントシステムをオーケストレーションしました。AI League では、以下の AgentCore の機能を活用しています。

• AgentCore runtime（Amazon Bedrock AgentCore の機能）: エンジニアたちはここでエージェントコンテナをホスティングし、課題タイルの処理を行い、制限時間内に採点された回答を返却します。
• AgentCore Gateway（Amazon Bedrock AgentCore の機能）: エンジニアたちは、モデルコンテキストプロトコル（MCP）を経由して、エージェントからのツール呼び出しを Lambda 関数にルーティングしました。これにより、経路探索、ウェブスクレイピング、コード実行が可能になります。

AgentCore Memory は Amazon Bedrock AgentCore の機能の一つで、エンジニアはこれにより対話間でコンテキストを保持し、エージェントが収集した鍵や解決済みの課題などの過去のイベントを記憶できるようにしました。

AgentCore Code Interpreter も Amazon Bedrock AgentCore の機能であり、計算上の課題に対して安全な隔離サンドボックス内でコードを実行できます。

Amazon Bedrock Guardrails

Amazon Bedrock Guardrails を使えば、有害な入力や出力から守るためにコンテンツをフィルタリングできます。エンジニアは以下を設定しました。

• 拒否トピック – ブロック必須の特定コンテンツ
• コンテンツフィルター – ヘイトスピーチ、暴力行為、不正行為に対する閾値
• カスタムメッセージによる入力・出力ブロック

AWS Lambda

AWS Lambda を使えば、モデル単独では信頼性を持って処理できないタスク用のカスタムツール関数を構築できます。

• 経路探索 – Breadth-First Search (BFS) などのアルゴリズムを用いたマップ上の移動
• コードインタプリター – 計算課題のためのコード実行
• ウェブスクレイピング – 情報取得のためのウェブページの取得と解析

Amazon SageMaker

Amazon SageMaker を使えば、開発環境を構築しモデルのファインチューニングが可能です。エンジニアは Verifiable Rewards からの強化学習（RLVR）を活用しました。

• Amazon SageMaker Studio は、組み込み AI 開発ツールを備えた統合開発環境（IDE）を含む開発環境を提供しました。
• サーバーレスファインチューニングにより、参加者が作成したデータセット上でカスタムモデルの訓練を行いました。

微調整されたモデルは、その後推論エンドポイントにデプロイされ、トラフィックの処理を開始しました。

以下の図は、ファインチューニングモデルのワークフローを示しています。

Figure 3: Fine-tuning model overview

エンジニアたちが学んだこと

AWS AI Leagueでは、本番環境でのアジェンティックAI（Agentic AI）に直接応用できる実践的なエンジニアリングの教訓がいくつか浮き彫りになりました。

制約下におけるプロンプトエンジニアリング

最も明確な教訓の一つは、成功が単にプロンプトを書くことによるものではなく、現実の制約の中で機能するプロンプトを設計することにあるという点でした。トークンが一つ増えるごとにポイントが失われ、不要なツール呼び出しは時間とコストポイントを消費します。エンジニアたちはすぐに、解決策を動作させることが最初のステップに過ぎないことに気づきました。重要なのは効率化であり、そここそが本番の顧客シナリオにおいて最も競争力のある要素となるのです。

マルチエージェントアーキテクチャの判断

エンジニアたちは、専門ツールを持つ単一目的のエージェントから、多機能なエージェントまで、自らのアーキテクチャにいくつのエージェントを含めるかを決断する必要がありました。それぞれのアプローチには、トークン使用量、レイテンシ、信頼性におけるトレードオフが伴います。これは、本番環境でのエージェント設計に関する意思決定と密接に一致しています。

以下の図は、ファイナールにおいて異なるアジェンティックシステムがいかに課題に対応したかを示しています。

Figure 4: Overview of different agentic systems answering challenges

ガードレールの設定

「暴走する紫（Violent Violet）の挑戦」が浮き彫りにした教訓は、ガールレール（安全装置）が望ましくないコンテンツをブロックするには十分厳格である一方で、正当なクエリまで過剰に遮断しないよう精密に設計されている必要があるという点です。もしガールレールが強すぎればエンジニアは他の課題で失敗し、逆に甘すぎればガールレール自体の課題で失敗します。これは、実運用における AI セーフティにおいて極めて実践的な教訓として直結しています。

パスファインディングアルゴリズムの設計

パスファインディングツールの構築には、エンジニアが以下のような視点で考える必要がありました。

• シナリオに応じた複数の戦略（速度優先かスコア最大化かの選択）
• リスク評価（スパイクは命を奪い、壁はゲーム終了を意味する）
• 時間配分（すべての課題に立ち寄るべきか、それとも宝へ直行すべきか）
• 依存関係の順序付け（例えば、扉を開く前に鍵を集める必要があるなど）

次の図では、同じマップ上での複数のパスファインディング戦略の例を示しています。

Figure 5: Example of multiple different pathfinding strategies

可観測性の価値

実行の合間に Amazon CloudWatch Logs を確認していたエンジニアは、より速く改善を遂げているように見えました。一方、何が間違っていたかを推測して進めていた人々は、進捗がゆっくりでした。これは「解決策に適切な計装を行い、行動する前に観察せよ」というエンジニアリングの核心原則を再認識させる結果となりました。

次の図では、Amazon CloudWatch Logs を用いて Lambda 関数のトラブルシューティングを行う方法を解説しています。

Figure 6: Troubleshooting a Lambda function with Amazon CloudWatch Logs

AI を活用してエージェント型 AI ソリューションを構築する

Kiro などの AI 開発ツールを活用したエンジニアたちは、短期間で大きな進歩を遂げました。課題の全体像を AI ツールに共有するエンジニアほど、より迅速かつ優れた成果を出しています。これは重要な教訓を示しています。AI ツールは、解決すべき具体的な問題に基づいて活用されることで、最大の価値を発揮します。

結果と成果

今回のイベントでは以下の成果が得られました：

• イベントの登録データによると、400 名のエンジニアがアジェンティック AI の実践的な経験を積みました。
• エンジニアたちは、Amazon Bedrock、Amazon Bedrock AgentCore、AWS Lambda、Amazon Bedrock Guardrails、Kiro、そして Amazon SageMaker における実用的なスキルを習得しました。
• クライアント案件でアジェンティック AI を応用する自信を深めた社内リーダーが生まれました。
• 競争形式のイベントは知識共有を促し、チーム間の壁を取り払う効果がありました。

上位に入ったソリューションは、熟考に裏打ちされたエンジニアリングの賜物です。カスタム経路探索戦略、慎重に調整されたガードレール、メモリを意識したエージェント、トークン使用量を削減するために微調整されたモデルなどが含まれていました。上位 3 位の受賞者である James Ponter 氏、Adam Różewicki 氏、Eduard-Cosmin Socol 氏にお祝い申し上げます。今回の優勝者である James Ponter 氏（UKI クラウド・インフラストラクチャ部門長）は、このイベントについてこう総括しています：

「学問的な学習は基礎を築きますが、AWS AI League はそれを実戦のプレッシャーの下に置くことで、思考そのものを根本から変える効果があります。玩具のようなプロジェクトではなく、実際の AWS インフラ上で本番レベルのマルチエージェントアーキテクチャを構築し、パフォーマンスと効率性の両方で評価される環境は、単なる知識の理解を超えて概念を体得させることになります。時計が進む中で答えを検索することはできません。この時間的プレッシャーに加え、リーダーボードでの判断が現実の結果に直結するという事実が、他の学習環境では再現できないほどの深い没入感を生み出します。これは『知っている』ことと『実行する』ことの間のギャップを、長く記憶に残る形で埋めるのです。」

以下の図は最終戦のリーダーボードを示しています。

Figure 7: Our finale leaderboard

Atos の AWS アライアンス担当グローバル責任者である Chris Byrne 氏による、ゲーム化された学習のメリットに関する結びのコメント。