こんにちは、ソリューションアーキテクトの宇佐美です。 2026年7月15日(水) に開催された「Neuron Community – 2026 Vol.1」の様子をレポートします。このイベントは、2025年3月に立ち上げられた「Neuron Community」の協力のもと開催しました。 今回は、 AWS Summit Japan 2026 開催後ということもあり、AWS Summit Japan の振り返りや、AWS Neuron のアップデート情報が多めの内容となっています。 Neuron Community とは AWS では、機械学習のトレーニングと推論のための高性能で費用対効果の高い機械学習アクセラレータ（ AWS Trainium 、 AWS Inferentia ）、および深層学習と生成 AI ワークロードを実行するために使用される SDK の AWS Neuron を提供しています。「Neuron Community」は、ユーザー間で AWS Trainium / AWS Inferentia / AWS Neuron の知見共有を促進する場として発足しました。 「Neuron Community」は、主に Discord を使用して運営されています。興味を持っていただいた方は、下記の URL から参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq オープニング：Neuron Community の成り立ちとカラクリ社での Trainium 取り組み紹介 中山 智文 氏（カラクリ株式会社 取締役 CPO) 資料：後日公開 オープニングセッションでは、カラクリ株式会社の中山氏より発表していただきました。カラクリ株式会社は、2023年より一貫して AWS Trainium を利用し続けており、Neuron Community の立ち上げにも大きな貢献をしていただいています。この発表では、Neuron Community の始まりについて紹介していただきました。また、カラクリ株式会社の AWS Trainium に関する2つの取り組みについても紹介していただきました。1つ目の取り組みは、Amazon EKS 上に構築された 「Neuron 分散学習プラットフォーム」 です。このプラットフォームを構築することで、インフラ関連の知識が十分ではないメンバーでも分散学習を実行できる環境の整備を進めているそうです。2つ目の取り組みは、AWS Trainium の NKI カーネル開発を促進するための 「カーネル開発エージェント」 です。この AI エージェントにより、NKI カーネル開発をエージェントが自律的に進められるようになるということです。最後に、今後の Neuron Community の活動について、よりオープンな場にしていきたいという発信をしていただきました。 AWS Summit Japan 振り返り① セッションダイジェスト「⼤規模学習から AI エージェントの推論まで ~ コスト効率と性能が両⽴する AWS Trainium の全貌 ~」 澤 亮太 (Amazon Web Services Japan G.K.) 資料： “AI エージェントの推論から⼤規模学習まで” コスト効率と性能が両⽴する AI インフラ ̶ AWS Trainium の全貌 Amazon Web Services Japan G.K. の澤からは、 AWS Summit Japan 2026 の振り返りとして、「”AI エージェントの推論から大規模学習まで” コスト効率と性能が両立する AI インフラ ー AWS Trainium の全貌」のセッションを、15 分のダイジェスト版で紹介しました。このダイジェストでは、AWS Trainium の典型的な使い方として、 “A. コードはそのままで学習コストを下げたい” 、 “B. 性能を最適化したい” 、 “C. 推論コストを固定化したい” の3点に注目して説明しました。 A. では、 Native PyTorch support（ベータ版） を使い、GPU向けPyTorchコードのデバイス指定を cuda から neuron に変更して、AWS Trainium 上で学習を実行する方法を紹介しました。デモでは、GPT-2 の学習スクリプトを実行しました。B. では、 NKI (Neuron Kernel Interface) により AWS Trainium のハードウェア命令セットに直接アクセスして AI カーネルの最適化が可能であることを紹介しました。また、性能最適化とデバッグのワークフローを支援する Neuron Explorer、NKI の開発を AI エージェントで加速するためのオープンソースツールキットの “Neuron Agentic Development” についても紹介し、Neuron Agentic Development のデモを見ていただきました。C. では vLLM on Trainium を使うことで、オープンウェイトモデルをAWS Trainium 上でサービングできます。ここでは、openai/gpt-oss-20b モデルを AWS Trainium 上でサービングするデモを見ていただきました。 AWS Summit Japan 振り返り② ブース展示紹介「⽣成 AI を⽀えるインフラ技術」 赤澤 Toshinobu (Amazon Web Services Japan G.K.) Amazon Web Services Japan G.K. の赤澤からは、 AWS Summit Japan 2026 の振り返りとして、ブース展示「生成AIを支えるインフラ技術」について紹介しました。この展示は、複数のマルチモーダルモデルを Amazon EC2 trn2.48xlarge でサービングする様子を見ていただくもので、マルチモーダルモデルで画像の編集を行います。音声で画像編集の指示をすると Whisper Large v3 で音声認識を行い、Qwen3-VL-8B-Instruct で元になる画像を編集するための指示を生成します。指示は Qwen-Image-Edit-2511 に渡され、画像が編集されます。編集された画像は、Qwen3-VL-8B-Instruct を使って指示通りに編集できているかを講評し、XTTSv2 で音声出力します。この発表では、３匹の子猫のイラストを、4匹に増やすという画像編集の様子を見ていただきました。 また、このデモを実現しているアーキテクチャについての説明も行いました。4つのモデルのtrn2.48xlarge の 64 論理コアへのアロケーションや、モデルのデプロイフローなども説明しています。 AWS Trainium / Inferentia / Neuron SDK 最新アップデート 常世 大史 (Amazon Web Services Japan G.K.) 資料： Neuron Communit 2026 Vol.1 AWS Trainium / Neuron 最新アップデート Amazon Web Services Japan G.K. の常世からは、ちょうどイベント前日にテレビ東京の WBS（ワールドビジネスサテライト）で AI 向けアマゾン独自の半導体開発が特集 されたことに触れ、自身が所属するアマゾン内のチップ開発部隊「アンナプルナラボ」について紹介しました。Anthropic との共同プロジェクト Project Rainier では、これまでに 140 万個超の Trainium 2 および Trainium 3 チップが稼働中であること（WBS 内の特集にて紹介）、 OpenAI が 2GW 規模での Trainium 採用を発表 したこと、また従来のチャットボット型 AI からエージェント型 AI へとシフトする中で、AI チップに加え AWS Graviton プロセッサの重要性が増している点を紹介しました。 Meta が数千万の Graviton コアで Agentic AI をスケールしている事例 にも触れました。 次に、澤のセッションでも紹介された AWS Trainium 向けの SDK「AWS Neuron」のアップデートとして、ライブラリのネイティブ化（Native PyTorch、Native vLLM）の最新状況を紹介しました。 また、7 月 7 日にリリースされた最新の Neuron 2.31 では、性能最適化の要である NKI（Neuron Kernel Interface）と NKI Library に大きなアップデートがあった点、さらに NKI カーネル開発用のエージェントコーディング機能 Neuron Agentic Development によるカーネル自動最適化ループへの注力を紹介し、セッションを締めくくりました。 ※ イベント開催後の 2026年7月20日(月) に vLLM Neuron Beta がパブリックリリースしました！ さいごに 通算3回目の Neuron Community は、カラクリ株式会社での AWS Trainium への取り組みの発表や、AWS Summit Japan 2026 の振り返り、AWS Neuron 関連の最新アップデート情報の紹介と、充実した内容となりました。AWS Summit Japan 2026 のセッション動画は、 AWS Summit Japan の Web ページ に登録いただくことでオンデマンド視聴が可能です。ご興味のある方は、ぜひ登録してみてください。 発表後には今後の Neuron Community についてのディスカッションも行われ、約 1 年ぶりの開催となったことを踏まえ、より高い頻度で開催していこうという声が挙がりました。AWS としても積極的に支援していきます。 今後の Neuron Community も、Discord を中心に募集や告知を行っていきます。興味を持っていただいた方は、ぜひ、下記の URL から参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq 著者について 宇佐美 雅紀 (Usami Masanori) 製造業のお客様を担当するソリューションアーキテクトです。 製造業のお客様のクラウド活用を支援しています。 常世 大史 (Tokoyo Hiroshi) AWS Annapurna Labs のソリューションアーキテクトです。 Annapurna Labs が提供する AWS Trainium、Inferentia の技術支援に注力しています。  

1. はじめに こんにちは。プラットフォームエンジニアリングチームに所属する小泉（ @naotoko_ ）です。 本記事は、同チームの徳富（ @yannKazu1 ）が執筆した「 消えるランナーの観測基盤をどう選んだか — Datadog・マネージド・OSS を料金体系で比べて Loki + Prometheus に決めた話 」の本番環境への導入編です。EKS Auto Mode でホストしている Self-hosted Runner の監視基盤に Grafana・Prometheus・Loki・Alloy を導入した際にハマったポイントと解決策を、各コンポーネントごとにお伝えします。 Grafana・Prometheus・Loki・Alloy をどのような構成で実装したかは、上記ブログの「 実装：どう組んだか 」をご覧ください。 2. Alloy - メトリクスが重複する・取れない 2-1. DaemonSet の重複 scrape 問題 Alloy は DaemonSet でデプロイしており、全ノードに1つずつ Pod が立ち上がる構成となっています。 デフォルトのまま使用すると、Alloy はメトリクス収集時にクラスター全体から scrape 対象の一覧を取得し、そのリストに対して定期的に HTTP リクエストを送ります。DaemonSet の各 Pod がそれぞれ独立してこれを実行するため、全 Pod が同じターゲット一覧を取得してしまいます。 たとえば kube-state-metrics や ARC controller のようにクラスターに1つしかないエンドポイントは、全ての Alloy Pod が同じエンドポイントを scrape しに行くためノード数分重複します。さらに、node-exporter や kubelet のようにノードごとに存在するエンドポイントでも、各 Alloy Pod がクラスター全ノード分のエンドポイントを発見して全て scrape するため、同様にノード数分重複します。その結果、全ての scrape 対象で同一のメトリクスが重複して Prometheus に送られてしまいます。 各 Alloy Pod がそれぞれ独立にクラスター全体のターゲット一覧を取得するため、クラスターに1つしかない kube-state-metrics も、ノードごとに存在する kubelet も、全 Pod から scrape される。 なぜログ収集では同じ問題が起きないか ログ収集は各 Alloy Pod がノードのローカルファイル（ /var/log/pods/ ）を読む方式です。ノードAの Alloy はノードAのログだけ、ノードBの Alloy はノードBのログだけを読むため、Pod 間でデータが重複しません。読む対象がノード単位で自然に分割されているため、メトリクスのような重複の問題が起きませんでした。 解決策：Alloy のクラスタリングを有効化する Alloy にはクラスタリング機能があり、Pod 同士がクラスターを形成して scrape 対象を自動的に分担します。（詳しい仕組みは割愛） Alloy Pod 同士がクラスターを組み、各ターゲットの担当をいずれか1つの Pod に決める。担当はハッシュで決まるため、図のように自分と同じノード上のターゲットを担当するとは限らない。 設定は2段階必要です。まず Helm chart の values でクラスタリングを有効化し、DaemonSet の全 Pod がクラスターを形成するようにします。 alloy : clustering : enabled : true そのうえで、分担させたい各 prometheus.scrape ブロックに clustering { enabled = true } を付けます。 prometheus.scrape "kube_state_metrics" { targets = [...] clustering { enabled = true } forward_to = [prometheus.remote_write.default.receiver] } 注意点として、この2つはセットで初めて機能します。Helm values 側を有効化せずに prometheus.scrape 側だけ書いても no-op（何もしない）になり、逆に Helm values 側だけ有効化しても clustering ブロックを付けていない scrape コンポーネントは従来どおり全 Pod が独立に scrape し続けます。 2-2. kubelet scrape の InternalIP 対応 Grafana でメトリクスを確認すると Pod の CPU・メモリが No data になっていました。調べると kubelet の scrape が全ノードで失敗していました。 原因は Alloy が __meta_kubernetes_node_name （ノード名）を scrape 先のアドレスとして使っていたためです。EKS Auto Mode ではノード名がインスタンス ID になるため名前解決できず、全ノードでタイムアウトしてしまっていました。 通常の EKS ではノード名は ip-xxx-xxx-xxx-xxx.ap-northeast-1.compute.internal のようなプライベート DNS 名になるため、 __meta_kubernetes_node_name でも名前解決できます。一方 EKS Auto Mode では i-xxxxxxxxxxxxxxxxx のような EC2 インスタンス ID がノード名になるため、名前解決できないという状況でした。 解決策：InternalIP を使う __meta_kubernetes_node_address_InternalIP に切り替えることで、ノード名ではなく IP アドレスで直接アクセスするようにしました。 rule { source_labels = ["__meta_kubernetes_node_address_InternalIP"] regex = "(.+)" replacement = "${1}:10250" target_label = "__address__" } 3. Prometheus - OOM と欠損との戦い 3-1. OOM 問題 導入後、Prometheus サーバーが OOMKilled → 再起動を繰り返すようになりました。原因は1つではなく、複数が重なっていました。 原因1：Alloy と Prometheus の二重取り込み Prometheus の Helm chart はデフォルトでいくつかの scrape job（ kubernetes-nodes-cadvisor ・ kubernetes-pods 等）が有効になっています。今回の構成では Alloy が一元的に scrape して Prometheus に remote_write する設計のため、Prometheus 自身の scrape job と Alloy の remote_write で同じメトリクスが2経路で入っていました。 これは Alloy が scrape するターゲットと重複している chart デフォルトの scrape job を無効化することで解決することができます。 scrapeConfigs : kubernetes-nodes : false kubernetes-nodes-cadvisor : false kubernetes-pods : false # ... 原因2：cAdvisor の高 cardinality ラベル cAdvisor は kubelet に組み込まれており、コンテナのリソース使用量を収集するコンポーネントです。Alloy は kubelet の /metrics/cadvisor エンドポイントを scrape することでこのメトリクスを取得しています。cAdvisor のメトリクスには image ・ name などのラベルが付いており、同時稼働するランナー数が多いほど cardinality（系列数）が爆発的に増えてしまいます。 そこで、Prometheus に送る前の段階で Alloy 側でメトリクスやログ調査に不要なラベルを drop することで、Prometheus に送られる系列数を極力減らすようにしました。 ちなみに、 image はコンテナイメージ名、 name はコンテナランタイム上のコンテナ ID（containerd では 64 桁の 16 進文字列）が入ります。 name はコンテナが起動するたびに異なる値になるためほぼユニークであり、集計や絞り込みには使わないと判断し、この2つのラベルを drop しました。一方で、メトリクスのクエリで実際に使う namespace ・ pod ・ container といったラベルは残しています。環境に応じて、調査に使わないラベルは可能な範囲で drop するようにするのが無難です。 rule { regex = "image|name" action = "labeldrop" } ただし、 id ラベルだけは残す必要があります。cAdvisor は同じメトリクス名で複数のコンテナの情報を収集しており、それぞれを区別するために id ラベルが使われています。 id を drop すると異なるコンテナのメトリクスがラベルセット上で同一系列として扱われていしまいます。その結果、同じタイムスタンプに複数のサンプルが届き、 Prometheus が duplicate sample for timestamp エラーを返してしまうため注意が必要です。 原因3：Head Block のメモリ常駐 Prometheus はメトリクスを受け取ると、書き込み効率のためにまずメモリ上に一時的に貯めます。これが Head Block です。 一定時間が経つとメモリから EBS 上のファイルに書き出されます。デフォルトでは Head Block が3時間分（min-block-duration の1.5倍）に達した時点で古い2時間分がブロックとして書き出されます。つまり常に1〜3時間分のデータがメモリに残り続けるため、メトリクスの量が多いほどメモリ使用量が増えます。 storage.tsdb.min-block-duration を 2h から 30m に短縮することでこの「一時的に貯める時間」を短くし、より頻繁に EBS に書き出すことでメモリ常駐量を削減しました。その代わり、以前はメモリから取得できていたデータが EBS から取得されるためクエリが遅くなるトレードオフがあります。Self-hosted Runner の監視という性質上、確認したいのは基本的に直近の状況であるため、30分より古いデータの取得が多少遅くなっても問題ないと判断しています。 なお、 storage.tsdb.min-block-duration は --help にも表示されない hidden フラグで、公式には「テスト用途」とされています。挙動を理解したうえで利用してください。 extraArgs : storage.tsdb.min-block-duration : 30m 3-2. out-of-order サンプル問題 Alloy クラスタリングを有効化してから、Prometheus に out of order sample エラーが大量に出るようになりました。 Alloy のクラスタリングは Pod の増減をトリガーにターゲットの再配分を行います。Self-hosted Runner はジョブの増減に応じてノードが頻繁にスケールするため、Alloy の Pod も増減し、再配分が頻繁に起きます。Alloy のクラスタリングによるターゲットの分担は eventually consistent なモデルであるため、再配分の引き継ぎのタイミングによっては同じターゲットが一時的に2つの Pod から scrape されることがあります（grafana/alloy の issue #1611・#2348 でも報告されている既知の挙動です）。この状態で同じ時系列のサンプルが2つ届くと、後着のサンプルのタイムスタンプが先着より古い場合があります。すると Prometheus はこれを out-of-order として拒否し、該当のサンプルを捨ててしまいます。その結果、 Grafana で確認できるメトリクスに欠損が生じてしまいます。 解決策：out-of-order time window を設定する out_of_order_time_window を設定することで、指定した時間内の過去のタイムスタンプを受け入れるようになります。弊社の環境では、最終的に 10m に落ち着きました。out-of-order のサンプルを保持するためのメモリが若干増えますが、 storage.tsdb.min-block-duration を 30m に短縮して Head Block のメモリを節約できているため、特に問題ないと判断し、10m に設定しています。 tsdb : out_of_order_time_window : 10m 4. Loki - chart 移管の罠と起動しない Pod 4-1. Helm chart リポジトリ移管の罠 Loki の Helm chart はもともと grafana/helm-charts （ https://grafana.github.io/helm-charts ）で配布されていました。 しかし chart v6.55.0 を最後に OSS Loki 向けの chart は grafana-community/helm-charts （ https://grafana-community.github.io/helm-charts ）へフォークされ、v7.0.0 以降は community 側からリリースされています。従来のリポジトリに残った loki chart は Grafana Enterprise Logs（GEL）向けのメンテナンス専用になりました。 そのため、 grafana/helm-charts を使い続けると、気づかないうちに GEL 向けの chart を引いてしまいます。 合わせて以下の変更もあるので、注意が必要です。 フォーク後はメジャーバージョンの上がるペースが非常に速い（v7.0.0 から数ヶ月で v17.x、執筆時点の最新は v18.x） deploymentMode の値が SingleBinary → Monolithic にリネーム（chart v12.0.0）。なお values のキーは singleBinary のまま変わっていません resource "helm_release" "loki" { repository = "<https://grafana-community.github.io/helm-charts>" # ここが変わった chart = "loki" version = "17.1.6" ... } # chart v12.0.0 以降 deploymentMode : Monolithic # SingleBinary から変更 4-2. StorageClass が自動作成されない Loki の Pod がスケジュールされず、以下のエラーが出ていました。 eks-auto-mode/compute Failed to schedule pod, unbound pvc must define a storage class 通常の EKS では EBS CSI driver addon がデフォルトの StorageClass を自動作成しますが、EKS Auto Mode では作成されません。StorageClass が作成されていないと、PVC がバインドできず Pod が起動しません。 そのため、StorageClass を手動で作成し、Loki の PVC に指定することで解決しました。 # StorageClass の手動作成 apiVersion : storage.k8s.io/v1 kind : StorageClass metadata : name : auto-ebs-sc provisioner : ebs.csi.eks.amazonaws.com volumeBindingMode : WaitForFirstConsumer parameters : type : gp3 encrypted : "true" # loki.yaml singleBinary : persistence : storageClass : auto-ebs-sc 5. Grafana - デプロイ戦略とコード管理 5-1. EBS（RWO）と RollingUpdate の相性問題 Grafana を helm upgrade したとき、Pod が新しくなるはずが延々と Pending のまま膠着しました。原因は EBS の制約です。 EBS は RWO（ReadWriteOnce）のため、1つの Node にしか同時にアタッチできません。デフォルトの RollingUpdate は新しい Pod を起動してから古い Pod を落とす順番なので、新旧の Pod が同じ PVC を取り合って Multi-Attach error が発生します。 解決策：Recreate 戦略に変更する Recreate にすると「旧 Pod 終了 → EBS detach → 新 Pod 起動」という順番になります。replicas=1 の構成なので更新時に短時間のダウンタイムが発生しますが、監視基盤という特性を踏まえて瞬断は許容し、 Recreate に設定しています。 deploymentStrategy : type : Recreate 5-2. Dashboard・Alerting のコード管理 なぜ Terraform provider ではなく Helm values で管理するか Grafana のダッシュボードとアラートルールをコード管理する方法として、 grafana Terraform provider を使う方法もあります。しかし今回は Helm values（YAML/JSON）での管理を選びました。 理由はシンプルで、Grafana の UI でダッシュボードやアラートルールを作り込んだあと、そのまま JSON/YAML でエクスポートして Helm values に貼り付けるだけでコード管理できるからです。Terraform のリソース定義に落とし込む手間が不要で、UI で確認しながら作ったものをそのまま反映できます。 Grafana の Helm chart は provisioning の仕組みを持っており、values に書いたダッシュボード定義やアラートルールを起動時に自動で読み込みます。 YAML 管理による制約：削除は deleteRules に明示が必要 アラートルールを YAML から削除しても、Grafana 上のルールは消えません。アラートルールの provisioning は追加・更新してくれますが、削除は行いません。 これは Grafana の設計上の安全策です。file-based provisioning はステートレスで、Grafana は「この YAML がルールの全量である」という保証を持てません。複数ファイルから同時にプロビジョニングできる設計上、「ファイル A にないルール」がファイル B で管理されているかもしれず、Grafana にはどのファイルが何を管理しているか判断できません。また設定ファイルのバグやマウント失敗で一時的にファイルが読めなくなったとき、自動削除だとアラートルールが全消えするリスクもあります。Terraform が管理対象を state ファイルで追跡しているから自動削除できるのと対照的で、file-based provisioning にはその state 概念がないため、削除の意図を明示する仕組みとして deleteRules が用意されています。 ルールを削除するには以下のように UID を指定します。 alerting : rules.yaml : groups : - ... deleteRules : - orgId : 1 uid : hoge-alert # 削除したいルールの UID を明示 6. 専用 NodePool への分離 Prometheus・Loki・Grafana・Alloy といった観測性コンポーネントを、Runner と同じ NodePool に混在させていると2つのリスクがあります。 1つ目は、Prometheus の OOM のような観測性コンポーネントのリソースプレッシャーが同じノード上のランナーの動作に悪影響を与えるリスクです。 2つ目は、Karpenter の consolidation に巻き込まれるリスクです。runner が使う NodePool は業務時間帯の consolidation を無効にしており、早朝の限られた時間帯のみ有効になる設定にしています。この時間帯に consolidation が走ったとき、同じ NodePool にいる観測性コンポーネントの Pod が別ノードに移動させられ、メトリクスやログが欠損するリスクがあります。 専用 NodePool に分離することで、これらの問題をランナーから切り離せます。 Karpenter で dedicated=observability:NoSchedule の taint を付けた専用 NodePool を用意し、Prometheus・Loki・Grafana などの Deployment / StatefulSet 系コンポーネントに対応する toleration と nodeSelector を設定しました。なお、DaemonSet である Alloy と node-exporter は全ノードで動かす必要があるため toleration のみ付与しています。 # NodePool taints : - key : dedicated value : observability effect : NoSchedule # 各コンポーネント tolerations : - key : dedicated value : observability effect : NoSchedule nodeSelector : karpenter.sh/nodepool : observability 監視用コンポーネントについてもランナーと同じく、arm64 on-demand インスタンスを使用するようにしています。 ただし、インスタンスタイプの指定が甘いと Karpenter がコンピュート最適化インスタンス（c6g.large / 4GB RAM）を選んでしまい、Loki や Grafana が OOMKill されるという問題が起きてしまいます。observability スタックのメモリ使用量を実際に確認したうえで、NodePool の requirements に 8GB 以上のインスタンスを指定するなど、きちんとメモリ要件に合ったインスタンスが選ばれるように注意が必要です。 requirements : - key : eks.amazonaws.com/instance-memory operator : Gt values : [ "7168" ] # 8GB 以上 7. まとめ Grafana・Prometheus・Loki・Alloy を Self-hosted Runner の監視基盤として導入するにあたり、各コンポーネントで様々なハマりポイントがありました。特に Prometheus の OOM は複数の原因が重なっており、1つ解決しても次の問題が出てくる形で対応に時間がかかりました。また EKS Auto Mode には通常の EKS（マネージドノードグループ等）と設定において異なる部分があるため、EKS Auto Mode に初めて触る方や移行を考えている方は特に注意してください。 同じ構成を検討している方の参考になれば幸いです。

1. はじめに 以前、以下の記事でAWS AI Leagueについて紹介しました。 https://zenn.dev/nttdata_tech/articles/a907eb00cbbe4b AWS AI Leagueは、競技形式で生成AIの技術を学ぶプログラムです。主に、次の2つのテーマが用意されています。 Amazon SageMaker AIを利用したモデルのファインチューニング Amazon Bedrock AgentCoreを利用したAgentic AI Agentic AIチャレンジでは、AIエージェントがマップ上を移動し、コインの取得や質問への回答などを行いながら、