ゲーム

技術ブログ

2026年10月19日

本記事は 2026 年 10 月 7 日に公開された “ Introducing AWS Physical AI Toolchain ” を翻訳したものです。フィジカル AI ポリシーのトレーニングとデプロイを AWS 上で大規模に行うための、エンドツーエンドのソリューションフィジカル AI はロボット、自動運転車、スマートファクトリーなどを通して現実世界で稼働する人工知能です。 Capgemini Research Institute の調査によると、79% の組織がすでにフィジカル AI を活用しており、経営幹部の 60% が、フィジカル AI により、これまでロボットの採用が不可能または現実的ではなかった分野での活用が可能になると考えています。テクノロジーはまさに転換期を迎えています。しかし、ロボットを実用可能な実験用プロトタイプから信頼性の高い生産システムへと発展させるには、単一のモデルだけでは不十分です。これには、データ収集、合成データ生成、モデルトレーニング、シミュレーションに基づく検証、エッジデプロイを統合するパイプラインが必要です。各段階では、それぞれ異なる計算リソース、異なるツールが求められ、運用上の制約も異なります。このような工程間の引き継ぎにおいて、多くのチームが何か月分ものエンジニアリングの時間を浪費しています。本日、発表する Physical AI Toolchain on AWS は、AWS 上でフィジカル AI の開発ライフサイクル全体を運用するためのリファレンスアーキテクチャ、Infrastructure as Code、デプロイの自動化機能を 1 つにまとめ、NVIDIA Physical AI スタックと統合したものです。このツールチェーンは特定のロボットやタスクの種類に依存しません。自身の URDF、テレオペレーションデータ、タスク定義を用意するだけで、残りの処理はインフラストラクチャが行います。フィジカル AI 開発ライフサイクルフィジカル AI は、閉ループで稼働し、現実世界に対し、感知、判断、実行を継続的なサイクルで行います。これは、モデルがデータを処理し、予測値を画面に返す、従来の ML-Ops とは根本的に異なります。オフラインの評価では高い精度を出せるモデルも、雑然とした倉庫で 6 軸アームを 200 Hz で制御しなければならないとなると、うまく機能しないかもしれません。開発プロセスでは、物理的な力学特性、リアルタイムの制約、センサーノイズ、安全上の境界、遅延、そして現実世界でのテストではハードウェアの破損の可能性がありコストがかかるという現実を考慮する必要があります。図 1：フィジカル AI 開発ライフサイクルフィジカル AI のライフサイクルは、直線的なパイプラインではなく、フライホイール（循環構造）です。デプロイされたロボットが新たなデータを生成し、エッジケースを明らかにします。このようなエッジケースは、新たなシミュレーションシナリオの手がかりとなります。シミュレーションにより合成トレーニングデータが生成されます。より向上したモデルは、徐々に難易度を上げたテストによって検証されます。このサイクルを繰り返し、反復のたびにシミュレーションと現実世界のギャップを縮めていきます。フィジカル AI に専用のツールチェーンが必要な理由フィジカル AI には汎用的な ML-Ops の前提が通用しません。目的特化型のインフラストラクチャが必要となる 5 つの課題を以下に示します。様々な計算資源の混在：1 つのフィジカル AI のワークフローの中で、基盤モデルトレーニングのための高帯域の GPU クラスター、物理シミュレーションのための柔軟な中位クラスの GPU 容量、ロボット上のリアルタイム推論のためのエッジ GPU が使われます。1 つの計算サービスですべてをカバーすることはできません。アーティファクトの乱立：各ロボットリリースには、データセット、シミュレーションシーン、ロボット URDF 記述、キャリブレーションデータ、トレーニングコンテナ、チェックポイント、評価結果、デプロイ可能なエッジパッケージが含まれます。それぞれのステップを横断し、アーティファクトの昇格が制御されていないと、数週間のうちに再現性が失われます。検証の深さ：故障したロボットが再起動した時には、物理世界はすでに変化しています。フィジカル AI は、シミュレーション、監督下での実機テスト、管理された実環境での展開を経て、段階的に昇格させる必要があります。ロボットアームにはシンプルなブルーグリーンデプロイメントに相当するものはありません。データの経済性：実機ロボットのデータの収集にはコストがかかります。実環境グレードのポリシーは何百もの異なる環境への対応が求められます。チームには、デモンストレーションデータを、合成データによる拡張や強化学習によって増幅していくループが必要です。制御経路の配置：物理的な動きを決定する推論は、ロボット上の遅延、電力の予算、熱の制約に縛られます。クラウドはトレーニングやロボット群の管理を担いますが、安全に関わる物理タスクの制御ループとなることはできません。 5 つの課題はすべて相関しています。ツールチェーンの価値は、トレーニングスクリプトが 1 つ増えることではありません。データの取り込みからシミュレーション、エッジデプロイに至る整合性のある検証済みのプロセスであり、多くのチームが時間を費やす引き継ぎの部分を担うものです。 Physical AI Toolchain on AWS の発表 Physical AI Toolchain on AWS は、AWS 上でのフィジカル AI 開発ライフサイクル専用に設計された、リファレンスアーキテクチャ、Infrastructure as Code、デプロイ自動化機能を組み合わせた、一般公開されているコレクションです。NVIDIA のロボティクスソフトウェアスタック―視覚・言語・行動（VLA）トレーニング用「GR00T」、物理シミュレーション用「Isaac Sim」、大規模強化学習用「Isaac Lab」、合成データ生成用「Cosmos」、およびワークフローオーケストレーション用「OSMO」―を再現性のある単一のパイプラインに統合し、AWS マネージドサービス上で展開します。このツールチェーンはフィジカル AI の複雑さを捨象するものではありません。これにより、チームは引継ぎのたびに基盤を構築し直すことなく、再現性のある方法で、データ、モデル、シミュレーションジョブ、デプロイメントアーティファクトをステージ間で移行することができます。オープンスタンダードに基づく構築ツールチェーンは NVIDIA のコンポーネントに加えて、ロボティクスチームがすでに利用している公開ツールの上に構築されています。Zarr 形式の生データを読み込んでコミュニティ標準の LeRobot 形式に標準化し、PyTorch と Hugging Face で学習を行い、Gymnasium で強化学習タスクを定義し、URDF でロボットを記述し、移植性の高いエッジ推論のために ONNX 形式でエクスポートします。ロボット上の制御は、モデルから ROS 2 に引き継がれます。こうすることで、データやモデルを移植性の高いオープンなフォーマットで保持できます。設計原則ツールチェーンは 3 つの設計原則に基づいています。モノリシックでなくモジュラー型：各コンポーネント（基盤、Isaac Sim、Isaac Lab、GR00T、OSMO）は独立した Terraform モジュールになっており、1 つずつ段階的に導入することも、パイプライン全体に展開することもできます。モジュールは SSM パラメータを通じてコンフィギュレーションを共有しますが、厳密な依存関係はありません。 AWS インフラストラクチャ上の NVIDIA ネイティブ：ツールチェーンは AWS のコンピュート、ストレージ、ネットワーキング、セキュリティサービス上で NVIDIA Physical AI スタックを実行します。直接 NVIDIA のドキュメンテーションをフォローしても、クラウドネイティブなデプロイ自動化のメリットを享受できます。リニアなパイプラインではなくフライホイール・アウェア：基盤によってフィジカル AI 開発の持つ反復的な特性をサポートします。デプロイからフィードバックされたデータが新たなシミュレーションシナリオに活用されます。生成された合成データが学習に活用されます。学習済みモデルが検証に活用されます。ツールチェーンは決まった順序を強制するのではなく、フライホイール内のあらゆる移行に対応する基盤を提供します。アーキテクチャ Physical AI Toolchain on AWS は基盤にある複雑さを抽象化し、開発のフライホイールを AWS ソリューションに当てはめます。このアーキテクチャは意図的に垂直構造にして、各ピラーが独自に AWS のマネージドの基盤上で NVIDIA ドメインレイヤーを備える形になっています。アーキテクチャ全体のボトムレイヤーは Strands エージェントレイヤーで、インテリジェントなコーディネーションを可能にする Strands Agents SDK をもとに構築された AI ドリブンなオーケストレーションレイヤーです。チームは、個別に 1 つのピラーを採用することも、エージェントオーケストレーションで移行を管理し、ピラーを連携させてエンドツーエンドの完全なパイプライン全体を構築することも可能です。図 2：Physical AI Toolchain on AWS のコンポーネントデータは各ピラーを左から右へと流れます。遠隔操作装置の生データが Amazon Simple Storage Service (Amazon S3) に届き、 Amazon Elastic Kubernetes Service (Amazon EKS) や AWS Batch と NVIDIA Cosmos で合成世界の生成が行われ、AWS Batch と Amazon SageMaker で NVIDIA Isaac Lab および Isaac GR00T を使ってポリシー学習、 Amazon Elastic Compute Cloud (Amazon EC2) 上の NVIDIA Isaac Sim で検証を実行し、最終デプロイで、 AWS IoT Greengrass を使用して、最適化されたモデルを NVIDIA Jetson ハードウェアにプッシュします。Amazon SageMaker や AWS Batch で学習や微調整ジョブを実行することで、実装コストを最適化します。 Strands エージェントレイヤーは一般に公開されている Strands Agents SDK を基に構築され、ツールチェーン全体に AI ネイティブなインターフェースを提供します。チームは各パイプラインのバリエーション向けにカスタムのオーケストレーションスクリプトを書く代わりに、自然言語や構造化されたプロンプトで意図を記述するだけで済みます。あとはエージェントレイヤーが、呼び出すべきコンポーネントを判断し、必要なコンピューティングリソースを割り当て、データの受け渡しを管理し、結果を報告します。 NVIDIA Physical AI スタックの統合ツールチェーンは NVIDIA Physical AI ソフトウェアスタックと緊密に統合し、AWS の基盤上で展開・運用されます。 NVIDIA はドメイン特化型レイヤーを提供します。 Isaac Sim ：シーン構成、物理的に正確なレンダリング、リアルタイムシミュレーション Isaac Lab ：数千の並列環境での大規模強化学習 Isaac GR00T ：デモンストレーションに基づく視覚・言語・行動（VLA）モデルの微調整 Cosmos ：世界生成と合成データセットの規模拡大のための視覚データの拡張 OSMO ：異種コンピューティング環境（クラウド、オンプレミス、エッジ）にわたるワークフローのオーケストレーション Jetson / RTX ：リアルタイム制約下におけるエッジ推論向けのターゲット実行環境ハードウェア AWS は実行環境を提供します。 Amazon EC2 （NVIDIA GPU インスタンス）：シミュレーションおよび合成データ生成 Amazon SageMaker / AWS Batch ：自動プロビジョニング機能を備え、アイドル時コストがゼロのマネージド型トレーニング Amazon EKS ：GPU スケジューリングを活用した、スケーラブルかつ分散型の OSMO およびクラスターワークロード向け Amazon S3、 Amazon Elastic Container Registry (Amazon ECR) 、 Amazon FSx for Lustre ：データセット、コンテナ、高スループットなトレーニングデータの配信 Amazon CloudWatch 、 AWS Secrets Manager 、 AWS Key Management Service (AWS KMS) 、AWS IoT Greengrass ：オブザーバビリティ、セキュリティ、エッジデプロイメントこのツールチェーンはこれら 2 つのスタック間の境界における摩擦を軽減します。AWS はインフラストラクチャのプロビジョニング、デプロイの自動化、セキュリティ・プリミティブ、マネージドサービスの統合に対応します。NVIDIA は、フィジカル AI 担当チームがすでに使用しているシミュレーションエンジン、基盤モデル、オーケストレーションレイヤーを扱います。対象ユーザーこのツールチェーンは、スケーラブルなトレーニングやロボットポリシーの展開のためにクラウドベースのインフラストラクチャを必要とするロボティクスエンジニア、ML エンジニア、プラットフォームチーム、ソリューションアーキテクトなどを対象に開発されています。直接的にメリットが得られる業界としては、製造・産業オートメーション、倉庫・物流、エネルギー・公益事業、医療・ライフサイエンス、鉱業・建設、農業、航空宇宙・防衛などが挙げられます。ロボットが適応的行動を学習し、導入前にシミュレーションで検証を行い、エッジ環境のリアルタイム制約下で運用しなければならないあらゆるドメインに対応します。ツールチェーンが提供するのは完成したロボットの動作ではなく、インフラストラクチャのパターンやアーキテクチャに関する指針です。利用について利用開始を支援するため、AWS は以下のリポジトリでワークショップを提供しています。ご利用には以下が必要になります。 SageMaker と EC2 の両方で GPU クォータが承認されている AWS アカウントコンテナイメージ取得用 NVIDIA NGC API キーモデルの重みファイルダウンロードのための Hugging Face トークン費用が発生しないよう、以下のリソース削除手順に従ってください。ワークショップでは、段階ごとに順を追って、どのようなロボットデータにも対応可能な実例を用いて説明します。設定についての詳細な指示は、リポジトリ内の README ガイドを参照してください。 https://github.com/aws-samples/sample-the-physical-ai-toolchain-on-aws 各段階における実践例ツールチェーンのあらゆる段階に順を追った指示が付いており、具体的なコマンド、設定、予想されるアウトプットが示されています。各モジュールには、そのまま使える独自の実践例が付属しています。例えば GR00T トレーニングの場合、27 の UR3 ピック・アンド・プレイス遠隔操作シナリオが付属しており、モジュールを実行して正常に動作することを確認してから別のユースケースやデータセットに置き換えることができます。モジュールは単独でデプロイすることも、パイプライン全体をエンドツーエンドで構成することも可能です。チームは検証済みの Terraform Infrastructure as Code を基盤として、数時間で評価段階から移行して独自データ上でツールチェーンを実行できるようになり、カスタム統合に数週間もかかることはありません。AWS についてある程度の知識があることを想定していますが、フィジカル AI の専門知識は必須ではありません。指示書には段階が進むごとに関連用語や概念の解説がついており、参考資料としてフィジカル AI 用語集も添付されています。まとめ Physical AI Toolchain on AWS は、フィジカル AI を単一のトレーニングジョブとしてではなく、ライフサイクル全体にわたる課題として捉えています。本ツールチェーンは、データの取り込み、模倣学習、強化学習、合成データ生成、シミュレーション、オーケストレーション、そしてエッジへのデプロイに至るまで、AWS におけるリファレンスアーキテクチャのパターンを提供し、NVIDIA のロボティクススタックと初日から統合されています。推奨されるアプローチは、現在のボトルネックを解消する一つのコンポーネントから着手することです。ゼロから始める場合は、まず Foundation と OSMO をデプロイすることで、フライホイール全体を一元管理するコントロールプレーンを構築できます。ぜひツールチェーンをお試しいただき、issue の登録やコメント欄でのフィードバックをお寄せください。本プロジェクトにご貢献いただいたすべてのビルダーの皆さんに感謝いたします。  Abhishek Srivastav Abhishek Srivastav は Amazon Web Services のプリンシパルソリューションアーキテクトで、クラウド導入の加速戦略を通じてお客様の成功を推進しています。AI/ML テクノロジー、ハイパフォーマンスコンピューティング、シミュレーション、フィジカル AI にわたる深い技術的専門知識を持ち、複雑なエンタープライズ課題に対するソリューションの設計を専門としています。現在の役割では、CIO、CTO をはじめとするテクノロジー担当役員と協働し、デジタルトランスフォーメーションおよび生成 AI の取り組みに向けた包括的なロードマップを策定しています。 Adam Weber Adam Weber は AWS のシニアソリューションアーキテクトで、AWS の専門知識と自動車業界に関する深い知見を組み合わせ、お客様の AI トランスフォーメーションの取り組みを支援しています。今日の自動車業界が直面する独自の課題に対応する、革新的でコスト効率が高く、スケーラブルなソリューションの開発に注力しています。 Ali Shahrokni Ali Shahrokni は NVIDIA のシニアデベロッパーリレーションズマネージャーで、Amazon および AWS チームとの戦略的な技術連携をリードし、高度なロボティクス、AI、コンピュータービジョンのソリューションを構築しています。スイスの EPFL でコンピュータービジョンの博士号を取得し、Amazon、eBay、Magic Leap、オックスフォード大学で主要なリーダーシップおよび技術的役割を歴任。AI、3D 再構成、シーン理解、拡張現実（AR）の分野で、最先端の研究をスケーラブルな産業用途へと展開する取り組みを推進してきました。 Steven DeVries Steven は AWS のプリンシパルソリューションアーキテクトで、自動車・製造業のお客様向けにデータおよび AI の取り組みをリードしています。エージェント型ワークフローのデプロイ、ML パイプラインの構築、生成 AI アプリケーションの設計を手がけ、新興テクノロジーをビジネス価値へと変えています。 Ignacio Sánchez Ignacio Sánchez は AWS のフィジカル AI 担当ワールドワイドスペシャリストソリューションアーキテクトで、スペイン・マドリードを拠点としています。世界中のお客様やパートナーと協働し、空間コンピューティング、ロボティクス、AWS 上のエッジ推論ワークロードにわたって、デジタル世界と物理世界をつなぐ AI ソリューションの設計・デプロイを行っています。新興テクノロジーとその実世界への応用に情熱を注いでおり、余暇には読書、ビデオゲーム、スポーツで体を動かすことを楽しんでいます。 Jathavan Sriram Jathavan Sriram は NVIDIA のシニアソリューションアーキテクトで、AI およびロボティクスソリューションを専門としています。クラウドインフラストラクチャ、Kubernetes、AI テクノロジーにわたる専門知識を持ち、World Foundation Model とフィジカル AI アプリケーションに注力しています。クラウドネイティブなプラットフォーム上で生成 AI を大規模にデプロイできるよう、お客様を支援することに情熱を注いでいます。

AWS, ワークショップ, 人工知能, インフラ, テスト, ゲーム, ロボット, Terraform, ハードウェア, 設計

AWS

2026年10月16日

社内フロントエンド勉強会で「HTML解体新書」輪読会をしてみた

はじめにこんにちは！ KINTO開発部 KINTOシステム開発G マスターメンテナンスツール開発チーム、技術広報部兼務、Osaka Tech Lab 所属の high-g（ @high_g_engineer ）です。フロントエンドエンジニアをやっています。以前、社内で開催しているフロントエンド勉強会について紹介しました。 https://blog.kinto-technologies.com/posts/2025-06-30-frontend-study-group/ あれから勉強会は続き、2026年10月で第91回を迎えました。今回はその中で、2026年8月〜9月に全5回で実施した『HTML解体新書』の輪読会について紹介します。正直なところ、書籍の輪読会はフロントエンド勉強会では前例がなく、とりわけ、分厚い技術書の輪読会となると、「途中で失速しがち」「ただ読み上げるだけの会になりがち」という印象があり、少しハードルを高く感じていました。実際、私自身も前職で同じ本の輪読会を経験したとき、内容を理解しないまま読み進めるだけの会になってしまった苦い思い出があります。ですが、今回は最後まで走り切れたうえに、参加者全員が前のめりに議論する場になりました。この記事では、その経緯と進め方、うまくいった理由などをまとめます。題材にした書籍 https://www.borndigital.co.jp/book/25999/ 『HTML解体新書 ―仕様から紐解く本格入門』は、HTMLの仕様（HTML Standard）をベースに、各要素の意味や使い方、アクセシビリティとの関係を丁寧に解説した書籍です。なぜHTMLの輪読会をすることになったのか「次に何をやるか」をみんなで話し合った輪読会を始める直前、勉強会ではTSKaigi 2026のセッション動画をみんなで視聴していました。ただ、最近のフロントエンド勉強会はTypeScriptの型の話に寄りがちな内容になっていて、動画を見るだけの会が続いていたこともあり、「もう少し現場に寄り添った勉強会にしたい」と考えていました。そこで7月に2回ほど時間を取り、参加者が所属する各チームで実際に起きているフロントエンドの課題をヒアリングしました。すると、チームは違っても次のような悩みが共通して挙がりました。デザイナーとの協業の進め方に課題がある UI / UXに関する知識をもっと伸ばしたいアクセシビリティを最終的にコードへどう落とし込むか、どう周囲を巻き込むかキーワードは「情報設計」議論を重ねるうちに見えてきたのが、「情報設計」というキーワードでした。勉強会で立てた仮説はこうです。正しく情報設計されているUI ≒ 正しくマークアップされている ≒ Webアクセシビリティを満たしているデザイナーと協業するうえでも、アクセシビリティを満たしたコンテンツを作るうえでも、土台になるのはHTMLの正しい理解です。「HTMLの知識を強化することが、情報設計の理解につながり、ひいてはフロントエンドの全チームに共通する課題の解決につながるかもしれない」と考え、まずは h1 〜 h6 を正しい順序で使うという基礎的なレベルから理解し直そう、という結論になりました。その教材としてうってつけだったのが『HTML解体新書』です。いきなり始めず「本を紹介する会」を挟んだとはいえ、この本は全352ページというなかなかの厚さです。いきなり「来週から輪読会をやります」と言うと、参加のハードルが一気に上がってしまいます。一方で「みんなの準備が整ったらやろう」では、いつまでも始まらない可能性が高いです。そこで、まずはすでに本を持っている人に持参してもらい、どんな本なのかを紹介する会を一度挟みました。この会で中身をパラパラと眺めたことで「とりあえず買って一読してみます」「今Kindleで買いました」という声が出て、その場で進め方のルールも決めることができました。また、マネージャーの承認をもらい、東京（室町）と大阪のオフィスに1冊ずつ会社で書籍を購入できました。ただ、ふたを開けてみると多くの参加者が自分で購入していて、「会社で買わなくても、みんな持っていたかもしれない」というくらいでした。輪読会の進め方ルールルールはシンプルにしました。参加者はできる限り事前に読んでくる（もちろん、読めなくても大丈夫）説明担当は担当箇所を事前に精読し、当日に説明する（説明方法はおまかせ）書籍は会社購入分を貸し出し可（個人での用意もOK）「読めなくても大丈夫」と明言しておくことで、担当以外の人も気軽に参加できるようにしています。 1回（約1時間）のタイムテーブル時間内容 10〜30分担当者が担当箇所をざっくり説明 20〜30分全員で感想や気になったことを話す 3分次回の担当決めルーレット次回の担当は、Claude Artifactsで作ったルーレットで決めました。ちょっとしたゲーム感覚があり、「誰になるかな」と盛り上がるポイントでもありました。範囲は「主要な節だけ」に絞った全章を読むと長期戦になってしまうため、CHAPTER 3の要素解説から、特に業務に関わりが深い5つの節に絞りました。回開催日範囲担当第1回 8/7 セクション花輪さん第2回 8/28 グルーピングコンテンツ三上さん第3回 9/4 テキストレベルセマンティクス齋藤さん第4回 9/11 フォームその1 high-g 第5回 9/18 フォームその2 溝口さんお盆や私の休暇で何度かスキップを挟みましたが、当初の見込みどおり5回で完走できました。アクセシビリティの有識者が参加してくれた今回の輪読会で大きかったのが、社内のアクセシビリティの有識者である辻さん、守谷さんが参加してくれたことです。本に書かれている内容に対して「実際のスクリーンリーダーではこう読み上げられる」「昔はこう使われていた」といった、本の一歩先の知見をその場で補足してもらえたことで、議論の質が大きく上がりました。各回の様子各回とも、担当者が本の内容をなぞるだけでなく、独自の切り口でテキストベースのまとめを作ってきてくれました。ここでは各回で印象に残ったトピックをいくつか紹介します。第1回：セクション section / article / aside / nav といったセクショニングコンテンツや、 header / footer がランドマークになる条件などを扱いました。印象的だったのは、書籍の刊行と同じ2022年にアウトラインアルゴリズムがHTML Standardから削除されていることです。 https://github.com/whatwg/html/pull/7829 現在は、 section で囲んでも見出しレベルは上がらず、 h1 〜 h6 の数字で決まります。また、「Reactアプリケーションでは、最終的にレンダリングされたHTML全体を目にする機会がほとんどありません。セクション構造が正しいことを日々の開発でどう検証すればよいか？」という、コンポーネント開発ならではの悩みも話題になりました。第2回：グルーピングコンテンツ p 、 ul 、 ol 、 dl 、 figure 、 main など「毎日書いている要素」がテーマでしたが、担当の三上さんは意味の深い説明よりも、個人的に「そうなんだ」と感じた部分を中心にまとめてくれました。たとえば、 p の中に ul を書くとエラーにはならず、パーサーが黙って p を閉じてしまいます。  <p> <ul> <li>項目</li> </ul> </p>  <p></p> <ul> <li>項目</li> </ul> <p></p> その結果、 p > ul を前提にしたCSSが効かなくなったり、末尾に生える空の p で余白が増えたりします。SSR環境ではサーバーで生成したHTMLとクライアントのDOMが食い違い、hydrationエラーの原因にもなります。ほかにも、次のような話題で盛り上がりました。 ol の番号はDOMに存在しないため、コピー＆ペーストすると消える main は hidden 属性を付けたものを含めれば、1ページに複数置ける hr は「線」ではなく、段落レベルのテーマの区切り。スクリーンリーダーでは「区切り」と読み上げられる dl の読み上げはブラウザとスクリーンリーダーの組み合わせによって差があるが、セマンティクスとして正しいなら使う価値があるこの回で特に印象に残ったのが、「セマンティクス＝スクリーンリーダーのため」というチャットの発言に対する、辻さんのひと言です。「スクリーンリーダーのため」ってのはたぶんちょっと違うな。スクリーンリーダーはHTMLの仕様に合わせて解釈する側なので。スクリーンリーダーで思いどおりに読ませるためにコンテンツを曲げるのではなく、仕様に沿って正しくマークアップし、スクリーンリーダー側がそれを正しく解釈する。アクセシビリティを考えるうえでの順序を、改めて確認できました。第3回：テキストレベルセマンティクス em と strong 、 small 、 s 、 time 、 ruby 、 bdi 、 br 、 wbr などを扱いました。担当の齋藤さんからは「普段はフレームワーク上でコンポーネント単位でしかHTMLを書かないので、要素そのものを意識したことがなかった」という率直な感想があり、まさにこの輪読会の狙いどおりの気づきが共有されました。書籍の刊行後に仕様側で変わった点も話題になりました。たとえば、書籍の時点では対応するARIAロールがなかった要素にも、WAI-ARIA 1.2ではロールが割り当てられています。 HTML要素 WAI-ARIA 1.2でのロール em emphasis strong strong del / ins deletion / insertion sub / sup subscript / superscript b / i / small / s / u generic ほかにも、 <p>H<sub>2</sub>O</p> をVoiceOverで読ませると「エイチ・ツー・オー」ではなく「エイチニオー」と読まれた、日本語にはイタリック体の文化がないので i 要素はマークアップと見た目が一致しにくい、といった実際に試してみたからこその話も出ました。チャットでは、昔使っていたHTMLエディタの話や、ガラケーでHTMLを書いていた思い出話で世代を超えて盛り上がる一幕もありました。第4回：フォームその1 私の担当回です。 form 、 label 、各種 input の type 、バリデーション属性、 autocomplete などを扱いました。特に強調したのは、 label の for 属性の落とし穴です。存在しない id を指定するとHTMLチェッカーでエラーとして検出できますが、別の要素の id を指定してしまった場合はHTMLチェッカーでは検出できません。ラベルをコピー＆ペーストして for を直し忘れると、コピーしたラベルまで最初の入力欄に紐づいてしまう、といった事故が起こり得ます。これは目で見ても気づきにくい一方、スクリーンリーダーで読み上げるとすぐに分かる、という話が辻さんからありました。そのほかにも、次のような話題が出ました。 type="hidden" は「秘密」にはならない（値は改ざんできる） pattern 属性はセキュリティのためのものではない placeholder はラベルの代わりにならない電話番号を「ハイフンなし」と注釈して type="number" で受け取るのは避けたい KINTOのサービスには申込フォームが多いので、そのまま業務に生かせる内容だったと思います。第5回：フォームその2 最終回は溝口さんの担当で、 button 、 select 、 datalist 、 progress / meter 、 fieldset / legend などを扱いました。溝口さんの切り口がとても面白く、「今はゼロからフォーム部品を手書きすることは少なく、UIライブラリを使うことがほとんど」という前提に立って、 MUI・Ant Design・Radix UIがそれぞれの要素をどう実装しているかを、書籍の内容と突き合わせてくれました。たとえばスイッチ（Switch）コンポーネントひとつとっても、実装方針はライブラリごとに異なります。ライブラリ Switchの実装 MUI 見た目用の span と、透明な <input type="checkbox" role="switch"> Ant Design input を使わず <button type="button" role="switch" aria-checked> Radix UI <button role="switch" aria-checked> に加え、フォーム内でのみ非表示の input を追加 select も同様で、ネイティブの select を使わずに role="combobox" と role="listbox" を組み合わせて再現していたり、フォーム互換のために見えない select を置いていたりと、各ライブラリの工夫が見えてきました。「アクセシブルな複数選択UIを自前で実装するのはかなり大変なので、ライブラリを使うのがおすすめ」という結論にも説得力がありました。また、スイッチは「押した瞬間に反映されるもの」なので、「保存」ボタンと組み合わせたり、月額／年額のような二択に使ったりするのは本来の用途とずれる、というSwitchとトグルボタンの使い分けの話も盛り上がりました。ふりかえり全5回を終えたあと、勉強会の1回分を使ってふりかえりを行いました。フレームワークには、KPTではなく Fun / Done / Learn を採用しています。KPTだと特に問題がなくてもProblemを挙げる必要があり、ネガティブな空気になりやすいと考えたためです。 Fun：楽しかったこと輪読会は負荷の高いフォーマットなのに、担当者が理解したことを積極的にシェアしてくれたただ読んでくるだけでなく、担当者が独自の解釈を織り交ぜて、より高度な内容に仕上げてくれた（UIライブラリの対応状況など）発表者ごとに本のどこに着目しているかが資料に表れていて、他の人がどう技術書を読んでいるのかを知ることができた有識者のアクセシビリティの知見を踏まえて本を読み進める体験ができた発表後のディスカッションで、全員が前のめりに建設的な意見を出す場になった辻さんからは、こんなコメントももらいました。昔のWeb制作者は、HTML解体新書に書いてあるくらいのことは普段使いしていた。今の時代は、そうした知識がなくてもプロダクトが作れてしまう。だからこそ、この輪読会を通してみなさんが知ろうとしてくれていることがうれしかった。さらに、「世の中の登壇には、画面を見ていないと置いていかれるものが意外と多いけれど、今回のみなさんの発表は、画面を見ていなくても話として理解できた」という、うれしい言葉もいただきました。辻さんがこの点について書いた記事も紹介されていたので、発表をする方にはぜひ読んでほしいです。 https://note.com/debugon/n/nae7f164bf8a7 Done：やり遂げたことフロントエンド勉強会で書籍を輪読するスタイルは初めてだったが、無事に完走できた社内に『HTML解体新書』の存在を広められた複数回にわたって1冊の技術書を読む、というスタイルを勉強会として1つ確立できた一人で読むのがつらい本でも、勉強会に持ち込んでみんなで読む、という選択肢ができたのは大きな収穫です。 Learn：学んだこと HTMLの現行仕様は常に更新され続けるHTML Standardなので、書籍の内容はすでに古くなっている部分もある。だからこそ書籍は取っかかりとして使い、怪しいと思ったら仕様を引くセクショニングコンテンツ、グルーピングコンテンツ、テキストレベルセマンティクスといったHTMLの原点を改めて思い出せた a 要素の内容モデルはTransparent（透過的）で、親がフローコンテンツなら a の中に div などを置くこともできるセマンティックなHTMLを書けばアクセシビリティを網羅できるわけではない。結局、見出しやラベルを適切に付けることが、アクセシビリティ的に一番重要見た目に頼っていたマークアップを、要素の意味から考え直すきっかけになった担当になった人は誰も発表を避けず、1週間で1時間分の議論ができる資料を作ってきてくれた。 1回あたりの適切なボリューム感もつかめたうまくいった理由をふりかえってみるふりかえりの内容も踏まえて、今回の輪読会がうまくいった理由を整理すると、次の4つだと思います。現場の課題から題材を選んだ「なんとなく良さそうな本」ではなく、各チームへのヒアリングで見えた共通課題（情報設計・アクセシビリティ）から逆算して本を選びました。そのため、参加者にとって「自分ごと」になりやすかったのだと思います。始めるハードルを徹底的に下げた紹介する会を挟む、「読めなくても大丈夫」と明言する、範囲を主要な節に絞る、書籍を会社で用意する、といった工夫で、参加の心理的なハードルを下げました。説明方法を担当者に任せた本の内容をなぞるのではなく、「そうなんだ」と感じた点に絞る、UIライブラリと突き合わせる、など担当者ごとの切り口が生まれ、毎回違った面白さがありました。有識者が一緒に読んでくれた書籍の内容を、現在の仕様や実際のスクリーンリーダーの挙動と照らし合わせて補足してもらえたことで、「読むだけの会」から「理解して議論する会」になりました。おわりに今回の輪読会を通して、HTMLの知識そのものはもちろん、「勉強会で1冊の本を読み切る」という新しい型を手に入れることができました。ふりかえりでは、次の題材としてReactの公式ドキュメントのような無料で読めるリファレンスを読むのも良さそう、という声や、書籍の内容を起点に、現在のHTMLの仕様やAI時代のマークアップについてさらに議論を深める場をつくれないか、というアイデアも出ています。少人数のふりかえりではありましたが、この輪読会を乗り越えたことで、新しいことができそうな可能性を感じています。社内で輪読会を企画しようとしている方の参考になればうれしいです。