はじめに
2026年9月13日（日）に、JAWS-UG東京支部とAWS Japan（AWSJ）が共同で「AgentCoreハンズオン 〜マルチエージェントでフットボール対決！〜」が開催されます。AIエージェントでサッカーチームを作って対戦するイベントで、私も参加予定です。
事前にワークショップ資料とサンプルコードを読み込んでみました。本記事は、その内容を自身のサッカーのプレイ・観戦経験も交えてまとめたものです。同じイベントに参加する方の準備に使ってもらえればと思います。
この記事で書かないこと
- 筆者自身の戦術やプロンプトの中身（当日の対戦相手に読まれるので書けません...）
- AWS製リファレンスチームへの具体的な対策
- AgentCoreやStrands Agents SDKそのものの解説
記載内容はすべて2026年8月21日時点のワークショップ資料とサンプルコードをもとにしています。当日までに仕様が変わる可能性があるので、最終的には公式資料を確認してください。
AWS Agentic Football Cupとは
AWS Agentic Football Cupでは5体のAIエージェントでサッカーチームを作り、5対5で5分間の試合を行います。各エージェントは試合状況を見て自律的に動きを決めます。人間は監督の如くエージェントに指示を出すこともできます。
技術スタックはAmazon Bedrock AgentCore、Strands Agents SDKです。コーディングエージェントとしてはKiroが推奨されていますが、Claude Code等も利用可能です（手順の読み替え等が必要）。
通常のサッカーとは異なるルール
5対5・試合時間5分
11人制ではなくフットサル、ブラインドサッカー、ドローンサッカーと同じ5人制で、試合時間は5分です。1人はゴールキーパー（GK）で固定、残りの4人のポジションは自由に決められます。
スローイン、コーナーキック、ゴールキック、PKがない
ボールがラインを割るという概念がありません。つまりスローイン、コーナーキック、ゴールキックが存在せず、PKもありません。プレーは連続していて、ボールの持ち主が変わるのはタックルかインターセプト（パスカット）かゴールのときだけです。
ゴールが決まるとキックオフになり、全選手が初期配置に戻ります。この数秒間が、フォーメーションを立て直せる唯一のタイミングです。
フィールド
フィールドはxがおよそ-55〜+55、yが-35〜+35の座標で表現されます。HOMEチームは+x方向へ攻めます。エージェントに渡される状態にはこの座標が入ってくるので、敵陣や自陣をプロンプトで表現するときはこの数値が基準になります。
押さえておきたいサッカー用語
フォーメーション
GKを除く4人の並び方です。2-1-1、1-2-1、3-0-1などが考えられます。数字は後ろから順にDF、MF、FWの人数を表します。2-1-1なら守備2人・中盤1人・前線1人です。
現実のフットサルの場合GK以外の4人はポジションを区別しないFP(フィールドプレイヤー)と表現されることが多いです。
ポジション（GK / DEF / MID / FWD）
GKはゴールキーパー、DEFはディフェンダー（守備）、MIDはミッドフィールダー（中盤）、FWDはフォワード（攻撃）です。サンプルコードのエージェント名は ai-gk / ai-def / ai-mid / ai-fwd1 / ai-fwd2 になっていて、それぞれのシステムプロンプトで役割を定義しています。
パスの種類
グラウンダー（地面を転がすパス）、浮き球（相手の頭上を越すパス）、スルーパス（味方の足元ではなく、前方のスペースへ出すパス）があります。
プレス / ハイプレス
ボールを持っている相手に詰め寄って、自由にプレーさせないことです。特に相手陣内の高い位置から全員でプレスをかけることをハイプレスと呼びます。奪えれば即ゴールチャンスですが、かわされると背後ががら空きになり、スタミナも激しく消耗します。
マーク（マンマーク / ゾーン）
特定の相手選手に張り付いて自由を奪うのがマンマーク、担当エリアを守るのがゾーンディフェンスです。
マンマークは1人抜かれるとピンチになるため、現代サッカーは基本ゾーンディフェンスの印象です。
インターセプト / スライディングタックル
インターセプトは相手のパスコースに入ってボールを奪うこと（パスカット）です。スライディングタックルは滑り込んでボールを奪うプレーで、成功すれば一発で奪えますが、外すと置き去りにされ、ファウルのリスクもあります。
カウンター / ポゼッション
カウンターは、相手が攻めてきたところでボールを奪い、相手が戻る前に一気に攻め切る戦い方です。ポゼッションはボールを保持してパスを回しながら崩す戦い方です。
その他戦術面
以下のファイルに戦術的な用語説明もありますので、気になる方はご覧ください。ただし、このファイルには応答時間やアウトオブプレーの扱いなど、ワークショップ資料と異なる記述があるので、用語の参考程度に読むのがよさそうです。
パラメータやシステムプロンプト
コマンド一覧
以下のコマンドが用意されています。target_x と target_y はフィールドにおける座標を示します。
| 分類 | コマンド | パラメータ | 説明 |
|---|---|---|---|
| 移動 | MOVE_TO | target_x, target_y, sprint | 指定した座標に移動 |
| 移動 | FOLLOW_PLAYER | target_player_id, target_team, distance | 指定した選手（敵味方問わず）についていく |
| 攻撃 | SHOOT | aim_location (TL/TR/BL/BR/CENTER), power (0.0〜1.0) | シュートを行う。ボール保持時のみ |
| 攻撃 | PASS | target_player_id, type (GROUND/AERIAL/THROUGH) | パスを行う。THROUGHはスルーパス（前方のスペースに出すパス） |
| 攻撃 | GK_DISTRIBUTE | target_player_id, method (THROW/KICK) | GK専用。GKがボールを保持しているときに味方へ配球する |
| 守備 | PRESS_BALL | intensity (0.0〜1.0) | ボール保持者にプレスをかける。intensity（インテンシティ）は実際のサッカーでも使われる用語で、強度を意味する |
| 守備 | MARK | target_player_id, tightness (LOOSE/TIGHT) | 特定の相手選手をマークする。守備が目的ならMOVE_TOよりもこちらが良さそう？ |
| 守備 | INTERCEPT | aggressive (bool) | パスカットを狙ったポジショニングをとる |
| 守備 | SLIDE_TACKLE | target_player_id, sprint, distance | ワークショップページには載っていないが、コード上で確認できる |
| 戦術 | SET_STANCE | stance (0/1/2) | 0がバランス、1が攻撃的、2が守備的 |
| 戦術 | CLEAR_OVERRIDE / RESET | なし | デフォルトAIの動きに戻す |
システムプロンプト
サンプルコードでは各エージェントの役割をシステムプロンプトで定義しているので、今回はプロンプトエンジニアリングがより重要と思われます。
モデルの選択
サンプルコードではAmazon Nova LiteやAmazon Nova Microなどが使われているようですが、モデルを変更して良いかはイベント当日にならないとわかりません。
今回、賢いモデルを選ぶことが最適解にならない可能性が高いです。後述のとおり各エージェントは約2秒に1回呼び出され、5秒のタイムアウトに間に合わないと直前のコマンドと同じ行動をするようです。リアルタイムで状況が変わるサッカーの世界で、直前の動作と同じ行動をするプレイヤーはかなりのリスクになると考えます。レスポンス時間も含めて、どのモデルを選択するかが重要になりそうです。
個人的に肝になると思う箇所
エージェントは約2秒ごとに独立して呼ばれる
モデル選択の箇所でも触れましたが、各エージェントは約2秒に1回、それぞれ独立して呼び出されます。そのとき受け取るのはゲーム状態（ボールの位置と速度、全選手の位置とスタミナ、スコア、残り時間、プレーモード、チームチャット）で、返すのは自分1人分のコマンドです。
判断のタイムアウトは最大5秒で、間に合わなかった場合は直前のコマンドがそのまま維持されます。モデルの応答が遅いと、2秒前の状況に対する判断で動き続けることになります。
また、あまりにも指示が多いとレスポンスが遅くなると考えられます。
スタミナとファウル
スタミナは0〜100で、スプリントすると急激に減ります。1人がガス欠になると実質4対5なので、プロンプトで走らせ放題にすると試合終盤に響きます。ファウルとカードの概念もあり、強すぎるプレスにはリスクがあります。カードや退場の詳細な仕様はワークショップページに見当たりませんでしたが、エージェントに渡されるゲーム状態に「カード、選手数」が含まれるので、現実のサッカー同様に退場はありそうです。退場すると当然4対5となり相当不利になるので、注意が必要です。状況によりますが、プレスの強度もよく考える必要がありそうです。
ライブコーチング
試合中、観戦画面から自然言語で指示を送れます。送った指示は次の呼び出しでチームチャットとしてエージェントに渡され、試合セッション中は会話履歴として蓄積されます。ただし仕様上はあくまで提案で、従うかどうかはエージェントが判断します。指示をどう扱うかはシステムプロンプト次第です。
指示の出し方については、以下のような説明があります。
望ましい行動を具体的に指定（「相手陣内でボールを奪い返せ」＞「もっとプレスしろ」）
関連する場合はスコープを指定（「ディフェンダーはポジション保持」「フォワードはもっと高く」）
1つのメッセージで矛盾する指示を避ける
前の指示を基に構築 — エージェントはセッション会話履歴を保持
セッションコンテキストを使用して確立されたパターンを参照
このファイルも前述のとおりワークショップ資料と異なる記述を含むので、コーチングの考え方の参考として読んでください。
最後に
サッカーとプロンプト設計の両方が絡むイベントは初めてで、資料を読むだけでもかなり楽しめました。当日までにいろんな戦術を考えておこうと思います。
参考