本記事は、株式会社コーテッグ様と Amazon Web Services Japan による共同執筆です。 みなさん、こんにちは。アマゾンウェブサービスジャパンの古山です。 生成 AI の活用は、チャットボットによる応答から、自律的にタスクを進める「AI エージェント」の実用化へとステージが移りつつあります。本記事では、 Amazon Bedrock AgentCore を中核とした非同期 AI エージェント基盤により、自然言語で問いかけるだけでデータの分析・可視化・レポート生成までを完結させる AI 分析プラットフォーム「 Dotta（ドッタ） 」を構築された、株式会社コーテッグ様の事例をご紹介します。 コーテッグ様について 株式会社コーテッグ 様（以下、コーテッグ様）は、AI とクラウド技術を軸に、サービスの企画・開発・運営を行うエンジニアリングカンパニーです。生成 AI・機械学習を活用したシステム開発とデータ活用支援、Web・モバイルアプリケーション開発、要件定義から運用保守までのフルサイクル開発、技術コンサルティングを手がけられるとともに、自社プロダクトとして、本記事でご紹介する AI データ分析プラットフォーム「 Dotta 」と、医療機関向けの AI 予約・受付システム「ソトマチ」を提供されています。 コーテッグ様は以前より AWS 上で生成 AI の活用を進められており、2024 年 11 月には、 Amazon Bedrock のマルチモーダルモデルを活用した「診察券の自動読み取り機能」により、導入医療機関全体で月間 7,500 時間の業務削減を実現されました（詳細は既存の事例ブログ「 生成 AI-OCR 機能で診察券読取業務を効率化、月間 7,500 時間の削減に成功 」をご覧ください）。 この成功体験を通じて、同社は生成 AI が単なる文字認識や文章生成にとどまらず、業務プロセスそのものを変革する力を持つことを確信されました。その次の挑戦として取り組まれたのが、”自律的に分析を進める AI エージェント” による分析プラットフォーム「Dotta」です。 提供の背景 データが意思決定を左右する時代になりました。しかし多くの企業では、データ分析はいまも一部の専門人材に依存する “属人的な作業” にとどまっています。コーテッグ様は、クライアントとの対話を通じて、現場に共通する次のような課題があると考えました。 分析を依頼してから結果が出るまで時間がかかり、意思決定のスピードが上がらない SQL やデータ基盤を扱える一部のエンジニアに依存し、依頼と待ち時間が慢性化している BI ツールを導入したものの、設定や操作が難しく現場に定着しない 週次・月次の定期レポート作成に、毎回まとまった工数が奪われる 生成 AI の進化は、こうした課題の解き方を大きく変えつつあります。人手不足が続くなかでも少人数で成果を出すために、同社は “チャットボット” の先にある「自律的に分析を進める AI エージェント」に着目しました。 「すべての人に、AI で分析力を。」——このコンセプトのもと、コーテッグは専門知識の有無を問わず誰もが自然言語で分析を完結できる仕組みとして「Dotta」を開発しました。 Amazon Bedrock を活用したサービスの概要 「Dotta」は「聞くだけで分析完了」をコンセプトに、分析の専門知識がなくても “問いかけるだけ” で結果にたどり着ける体験を提供します。主要機能は次の 4 つです。 自然言語クエリ： 「先月の売上を地域別に見せて」といった問いかけだけで、データの取得・集計を実行します。 AI ビジュアライゼーション： データの内容に応じて最適なグラフ・チャートを AI が自動で選定し可視化します。 自動レポート生成： 分析結果を PDF・Markdown・Word 形式で出力します。 マルチデータソース連携： CSV ファイルや MySQL・PostgreSQL などの各種データベース、 Amazon Redshift をはじめとするクラウドデータウェアハウスなど、多様なデータソースに対応します。 対象はマーケティング・営業・プロダクト・経営企画など幅広い職種で、広告効果分析（チャネル別 ROAS・CPA 分析）、営業パイプライン管理、ユーザー行動分析、経営ダッシュボードの作成といった用途が想定されています。これらの分析を、Amazon Bedrock 上で動作する AI エージェントが自律的に進めることで実現しています。 AWS サービスの採用理由 コーテッグ様が「Dotta」の基盤に AWS を選んだ理由は、大きく 3 つあります。 1 つ目は、 Amazon Bedrock の本番運用実績と信頼 です。前述の「診察券の自動読み取り機能」を通じて、Amazon Bedrock を本番環境で運用してきた実績があり、その品質・安定性への信頼が既にありました。また、Amazon Bedrock への入出力データがモデルの学習に利用されない点は、顧客の業務データを扱う分析プラットフォームにとって必須の要件でした。 2 つ目は、 Amazon Bedrock AgentCore による AI エージェント特有の要件への対応 です。数分に及ぶ長時間実行、セッションごとの分離された実行環境といった、AI エージェントならではの実行要件をマネージドサービスとして満たせることが、採用の決め手となりました。 3 つ目は、 少人数でも運用できるサーバーレス・マネージドサービス群 です。 Amazon SQS 、 AWS Lambda 、 Amazon DynamoDB などを組み合わせることで、インフラ管理の負担を最小限に抑えながら、スケーラブルな非同期処理基盤を実現できると判断しました。ソトマチで培った AWS の知見をそのまま活かせることも、開発スピードの面で大きな利点でした。 主要機能と独自性の高い技術的特徴 「聞くだけ」という体験の裏側では、AI エージェントが自律的に考え、必要なコードを書き、データを集計しています。これを支えるのが、Amazon Bedrock AgentCore を用いた非同期 AI エージェント基盤です。分析処理は数十秒から数分に及ぶことがあるため、ユーザーの操作をブロックしない非同期ジョブとして設計されています。 フロントエンド / API 層 利用者向け画面（Next.js によるフロントエンド）と、分析を担う「Analysis API」、データ取込を担う「Ingestion API」、認証・組織管理を担う「Admin API」は、いずれも Amazon ECS （AWS Fargate）上で稼働しています。アクセスは Amazon Route 53 でドメインを管理し、Application Load Balancer でアクセス先を振り分けます。管理者向けの管理画面は Amazon CloudFront と Amazon S3 で配信されています。 非同期 AI エージェント基盤（中核） 自然言語の問いかけを受け取ってから回答を返すまでの流れは、次のように構成されています。 ジョブ登録：Analysis API がユーザーのメッセージを Amazon SQS にジョブとして登録します。 自動起動・呼び出し：SQS をトリガーに AWS Lambda（Dispatcher）が起動し、Amazon Bedrock AgentCore Runtime を呼び出します。 エージェントによる分析：AgentCore Runtime 上で DeepAgents（LangChain）による分析エージェントが動作します。推論には Amazon Bedrock の基盤モデルを用い、分析には Claude Opus 4.8 / Sonnet 4.6、軽量な処理には Claude Haiku 4.5 と、用途に応じてモデルを使い分けています。 コード実行：分析に必要なコードの実行は AWS Lambda（Executor）が担います。 回答のストリーミング：エージェントが生成した回答は Amazon ElastiCache（Valkey）に逐次書き込まれ、Analysis API がそれを読み取って SSE（Server-Sent Events）でブラウザへリアルタイムに流します。読了後は TTL により自動削除される一時領域として扱われます。 会話の永続化：確定した会話は Amazon RDS（PostgreSQL）に永続化されます。これにより、ストリーミング中（未確定）の会話は ElastiCache から、確定済みの過去会話は RDS から取得し、途切れのないチャット履歴の表示・再生を実現しています。 ジョブの進行状況、二重実行を防ぐためのロック、エージェントの生存確認（heartbeat）、そしてエージェントの記憶管理（DeepAgents の checkpointer）は Amazon DynamoDB で管理されます。処理途中の大きな一時データは Amazon S3 に退避して受け渡します。 ユーザー操作による一時停止・再開にも対応しており、キャンセル要求を受け取ると安全に中断して checkpoint とそこまでのメッセージを保存し、後から途中再開できます（Human-in-the-Loop の入力待ちも同様の仕組みで扱われます）。 データ取込・分析基盤 分析対象のデータは、Ingestion API から AWS Lambda（Loader、dlthub を利用）でデータを変換・登録し、AWS Glue Data Catalog と Amazon S3 上の Apache Iceberg テーブルに蓄積されます。蓄積したデータへのクエリには Amazon Athena が用いられています。サービス本体のデータは Amazon RDS（PostgreSQL）でマルチテナント構成として管理されています。 開発段階での苦労と、工夫したポイント 長時間実行される分析処理を UI をブロックせずに扱うことが、同社にとって大きな課題でした。Amazon SQS・AWS Lambda・Amazon Bedrock AgentCore を組み合わせた非同期ジョブとして設計することで、ユーザーは待ち時間中も操作を続けられ、処理の進行はストリーミングで確認できるようになっています。 また、ストリーミング中（未確定）の会話と確定済みの会話を、それぞれ Amazon ElastiCache と Amazon RDS という異なる保存先から取得しつつ、利用者からは 1 つの連続した会話として見えるように繋ぎ込む点にも工夫を要したといいます。 加えて、Amazon DynamoDB による二重実行ロック・heartbeat での生存監視・checkpointer による記憶管理を組み合わせることで、処理の途中停止と再開、そして信頼性を両立させています。 Well-Architected Framework に基づく設計 オペレーショナルエクセレンス 各ノードの状態を Amazon CloudWatch で監視するとともに、ジョブの進行状況やエージェントの heartbeat を Amazon DynamoDB に記録することで、非同期処理の可観測性を確保しています。これにより、長時間ジョブの停滞や異常を早期に検知できる運用フローが整えられています。 セキュリティ 永続化データ（Amazon RDS、Amazon S3）を暗号化し、機密性の高いデータを保護しています。AWS IAM による最小権限のアクセス制御を行い、マルチテナント環境ではテナント間のデータ分離を徹底しています。また、VPC 内のプライベートネットワークで内部通信を完結させ、外部への通信は NAT Gateway を経由させることで、安全な通信経路を確保しています。 信頼性 非同期ジョブは Amazon DynamoDB による二重実行ロックで重複起動を防ぎ、checkpoint による中断・再開に対応しています。SQS・Lambda・AgentCore などマネージドサービスを中心に構成することで、スケールと可用性を確保しています。 パフォーマンス効率 分析には高性能なモデル、軽量な処理には Claude Haiku 4.5 と、用途に応じて基盤モデルを使い分けることで応答性とコストのバランスを取っています。回答のストリーミングには Amazon ElastiCache（Valkey）を用いて低遅延を実現し、大量データのクエリには Apache Iceberg と Amazon Athena によるスケーラブルな分析基盤を採用しています。 コスト最適化 サーバーレス・マネージドサービスを中心に構成することで、利用量に応じたコストとしています。基盤モデルの適材適所での使い分けや、一時データを TTL で自動削除する仕組みにより、無駄なリソース消費を抑えています。 ビジネスインパクトと今後の展望 想定される効果（試算） 「Dotta」がもたらす効果は、何より “時間” として表れます。ここでは、1 名あたり 1 週間に 5 件の分析業務が発生するクライアントの事例をもとに、コーテッグ様による導入効果の試算を紹介します。 前提条件 1 件の分析業務（データ抽出 → 集計 → 可視化 → レポート化）に、従来は 1 名あたり平均 240 分を要していると仮定 「Dotta」では自然言語で問いかけることで、同じ分析を平均 10 分程度で完了できると想定 試算 1 件あたりの削減時間 ＝ 240 分 − 10 分 ＝ 230 分 1 名あたり週の削減時間 ＝ 230 分 × 5 件 ＝ 1,150 分（約 19.2 時間） 10 名のチームで月（4 週）換算すると、約 19.2 時間 × 10 名 × 4 週 ＝ 月あたり約 768 時間の削減 ※上記はあくまで前提条件を置いた試算であり、実際の効果はデータ量・分析内容・利用状況により変動します。 今後の展望 コーテッグ様は今後、以下の機能拡充を進めていく予定です。 データソース登録の AI エージェント化 対応データソースのさらなる拡充 可視化・レポート表現の高度化 「すべての人に、AI で分析力を。」——専門知識の有無にかかわらず、誰もがデータにもとづいて “その場で” 意思決定できる世界の実現に向けて、コーテッグ様の挑戦は続きます。 まとめ 本記事では、Amazon Bedrock AgentCore を中核とした非同期 AI エージェント基盤により、「聞くだけ」で分析が完結するプラットフォーム「Dotta」を実現した、コーテッグ様の事例を紹介しました。生成 AI-OCR による業務効率化（ 前回の事例 ）から、自律的な AI エージェント基盤へ——同社の取り組みは、生成 AI 活用のステージを一歩ずつ確実に進める好例といえます。 AI エージェントの本番運用に必要なランタイム・メモリ・アイデンティティ管理などをマネージドで提供する Amazon Bedrock AgentCore は、本事例のような長時間実行・非同期型のエージェント基盤の構築を強力に支援します。生成 AI や AI エージェントの活用にご興味をお持ちのお客様は、ぜひ AWS までお問い合わせください。 （左から） 大松 宏之 — アマゾン ウェブ サービス ジャパン合同会社　ソリューションアーキテクト 高石 明義 様 — 株式会社コーテッグ　代表取締役 古山 玄弥 — アマゾン ウェブ サービス ジャパン合同会社　アカウントマネージャー

はじめに こんにちは！ 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 を閉じてしまいます。 <!-- 書いたつもりのHTML --> <p> <ul> <li>項目</li> </ul> </p> <!-- パース後のDOM --> <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時代のマークアップについてさらに議論を深める場をつくれないか、というアイデアも出ています。 少人数のふりかえりではありましたが、この輪読会を乗り越えたことで、新しいことができそうな可能性を感じています。 社内で輪読会を企画しようとしている方の参考になればうれしいです。

物流業界では、EC 市場の急拡大、販売チャネルの多様化、商品ライフサイクルの短期化が同時に進み、サプライチェーン全体の最適化が重要な経営課題になっています。欠品や過剰在庫は、売上機会の損失やコスト増加に直結します。だからこそ、リアルタイムな可視化とデータに基づく意思決定が欠かせません。 こうした課題に応えるのが、日本通運株式会社（以下「日本通運」）が開発・提供する AI 搭載型物流 Web アプリ「DCX（Digital Commerce Transformation）」です。AWS 上に構築された DCX は、在庫管理を中心にモノの流れの情報をつなぎ、データの可視化と AI による予測分析で、サプライチェーン全体の最適化を支援します。 本ブログでは、DCX の概要、AWS を活用したアーキテクチャ、そして最新の AI 機能を紹介します。内容は、2026 年 6 月に開催された AWS Summit Japan 2026 のブース展示をもとにしています。 DCX とは DCX は、日本通運が提供する SaaS 型の物流ソリューションです。在庫管理システム（WMS）として在庫や入出荷を管理し、受注から配送までの工程をリアルタイムで分析・可視化します。 高度な WMS 機能を実装 : アイテム別の入出庫履歴、日々の在庫数量、出荷先ごとの追跡番号などを一元管理。CSV や API によるデータ連携で、お客様のシステムとも簡単につなげることが可能 リアルタイム可視化と多角的な分析 : 受注から配送までの工程をつなぎ、出荷可能な在庫数量や作業進捗をリアルタイムで可視化。売上エリアの傾向や滞留在庫の推移など、さまざまな切り口で分析可能 AI による出荷予測と意思決定支援 : 時系列予測基盤モデル「Chronos-2」による出荷予測で在庫戦略の立案を支援し、Amazon Bedrock AgentCore を活用した対話型 AI で物流データからの迅速な意思決定を支援 導入しやすいサービス体系 : 物流業務を委託する「アウトソーシングサービス」と、お客様自身で在庫管理を行う「クラウドサービス」の 2 種類を提供。初期費用はかからず月額制で利用でき、契約後 2 週間で立ち上げが可能 日本通運が培ってきた「フィジカルなオペレーション」と、最新の「デジタル技術」。この 2 つを融合させ、新たなロジスティクスの価値を届けるのが DCX です。自社 EC を運営する D2C 事業者や販売チャネルの多い企業、物流センターを短期間・低コストで立ち上げたい企業に最適なサービスといえます。AWS 上に構築された DCX は、高い拡張性と安定性を備え、AI による先進的なサービスを提供しています。 DCX のアーキテクチャ — AWS 上での構築 DCX は、在庫管理や受注・出荷を担う DCX 本体と、顧客向け分析基盤「Business Insight」（以下、BI）の 2 つのアプリケーションで構成されています。オプションサービスとして提供される BI では、需要の偏りや在庫の滞留状況を可視化・分析できます。 DCX 本体 — ECS/Fargate によるコンテナ構成 図 1: DCX のアーキテクチャ。 DCX 本体は、 Amazon Elastic Container Service （Amazon ECS）と AWS Fargate 上でコンテナとして稼働しています。以前の運用基盤は Amazon EC2 でした。Fargate への移行とあわせてオートスケールを導入したことで、EC2 運用時に欠かせなかったサーバー台数（キャパシティ）の考慮が不要になりました。さらに、リクエストの増大に合わせてコンテナを増やすスケールアウトも容易になり、繁忙期でも快適なパフォーマンスを維持できています。 Business Insight — Redshift Serverless のデータを分析 図 2: Business Insight のアーキテクチャ。フロントエンドを Vercel でホストし、API を ECS/Fargate 上で提供する構成。 BI も、DCX 本体と同じく ECS/Fargate 上で稼働しています。分析では大量のデータにアクセスするため、接続先には Amazon Redshift Serverless を選びました。 パイプラインファーストの開発体制 図 3: CI/CD パイプラインの構成。GitHub へのプッシュを起点に、ビルド、ECR へのイメージ登録、ECS または Lambda へのデプロイまでを自動化し、結果を Slack に通知する。 開発効率を高めるため、DCX はパイプラインファーストの開発体制を採用し、デプロイを自動化・効率化しています。新しい機能をタイムリーにリリースできるようになり、ユーザー体験の継続的な向上につながっています。 パイプラインは AWS CodePipeline 、 AWS CodeBuild 、 AWS CodeDeploy などの AWS サービスを組み合わせて構築しました。インフラ管理には Terraform を導入し、Infrastructure as Code も実現しています。 データ統合 — Amazon Redshift Serverless と Zero-ETL 図 4: データ統合の構成。DCX と周辺アプリケーションの Aurora PostgreSQL のデータを Zero-ETL 統合で Redshift Serverless に集約し、Business Insight から参照する。 DCX では、日々の倉庫管理業務で使うデータベースと、分析で使うデータベースを分けています。そのため、BI が大規模なクエリを実行しても、ほかの業務には影響しません。 分析用データベースに採用したのは Amazon Redshift Serverless です。データ分析は負荷の変動が大きく、ピークのタイミングも予測しにくいものです。サーバーレスを採用したことで、この課題を解決しながら、コストの最適化も実現しています。 一般に、業務システムから分析システムへデータを移すには、ETL パイプラインの開発と維持が大きな負担になります。DCX は Aurora の Zero-ETL 統合 を採用し、Aurora に蓄積された業務データを Redshift Serverless へ自動で複製することで、この負担を大幅に減らしました。 AI 機能の実装 — Chronos-2 と Amazon Bedrock AgentCore DCX が提供する AI 機能は 2 つ。時系列予測モデルによる出荷予測と、自然言語による問い合わせへの自動応答です。欠品や過剰在庫を防ぐ在庫計画をすばやく立てられるうえ、複雑な操作なしに、滞留在庫の把握から改善策の検討まで進められます。 出荷予測 — Chronos-2 の活用 図 5: 個別 SKU の出荷予測画面。ロケーションと SKU ごとに、実績値と将来の予測値を下位（P30）・中位（P50）・上位（P70）の 3 つの分位点で表示する。 DCX の出荷予測を支えるのは、Amazon Science が開発・公開した時系列予測基盤モデル「 Chronos-2 」です。主な特長は次のとおりです。 ゼロショット予測 : 対象データでモデルの学習を行わなくても予測が可能 Transformer ベースのアーキテクチャ : 生成 AI と同じ Transformer 技術を時系列予測に応用 さまざまな環境で実行可能 : 仮想サーバやコンテナで実行でき、自社のアプリに組み込みやすい（ DCX では ECS で実行） 誰でも使えるオープンモデル : オープンモデルとして公開されており、誰でも無償で利用可能 Chronos-2 の導入により、1 アイテムあたり 1〜2 時間かかっていた予測の算出時間は約 5 分に短縮されました。複数アイテムの一括予測にも対応し、日別・週別・月別で最大半年先まで予測できます。実際の出荷実績と照合すれば、PDCA サイクルを回しながら予測の精度を高めていくことも可能です。 AI チャットによるデータ分析 — Amazon Bedrock AgentCore の活用 図 6: BI LLM Chat の画面。「最も滞留している商品を教えてください」という質問に対し、在庫数と在庫評価額のランキングと、在庫圧縮施策の提案を回答している。 Business Insight には、自然言語で物流データに問いかけられる「BI LLM Chat」を搭載しています。 図 7: BI LLM Chat の構成。 BI LLM Chat は、各エージェントが協調してタスクを遂行するマルチエージェント構成です。Amazon Redshift Serverless に蓄積された在庫・出荷などのデータや、S3 に格納された各種ドキュメントを参照し、ユーザーの問い合わせに回答します。ドキュメントの参照に使うのは Amazon Bedrock Managed Knowledge Base 。ユーザーとの過去の会話は、AgentCore Memory による長期記憶の機構で保持しています。 実装には AgentCore ハーネス を利用しました。AgentCore ハーネスなら、プログラムコードを書かずに AI エージェントを構築・運用できます。しかも、メモリやツール連携、オブザーバビリティなど AgentCore が提供する機能をそのまま活用できます。DCX では、こうして高品質な AI エージェントを短期間で開発し、新しい機能をすぐにユーザーへ届けられるようになりました。 今後の展望 日本通運は今後も、AI をはじめとするデジタル技術を DCX に積極的に取り入れていきます。国内外の拠点に蓄積される物流データと NX グループのグローバルな知見を活かし、お客様の物流現場の効率化と品質向上、そしてサプライチェーンにおける新たな価値の創造を支援していく方針です。 まとめ 本記事では、日本通運の DCX において、AWS の各種サービスがどのように利用されているのかを紹介しました。サーバーレスや CI/CD によって高度な開発・運用体制を確立し、AI やデータ分析技術によって付加価値の高いサービスを利用者に提供し続けています。これらは工夫次第で、どのような業種・企業規模でも取り入れられるアプローチです。みなさまのビジネスにも、ぜひ AWS の先進的なテクノロジーを積極的に活用してみてください。