はじめに こんにちは、ZOZOTOWN企画開発部 企画フロントエンド2ブロックのパクサンイです。普段はZOZOTOWNにあるCMSベースのLPページのメンテナンスや機能追加、企画LPページ環境のメンテナンスを担当しています。 ZOZOTOWNの複数のWebアプリケーション間で、プロモーション用ランディングページコンポーネントを共有するために、 Lit ベースのWeb Componentsを導入しました。本記事ではその事例を紹介します。 ZOZOTOWNでは多数のLPページが開設・更新されており、従来はiframeを使った埋め込み方式でUIを共有していました。しかし、この方式にはさまざまな課題が存在し、レガシー環境からNext.jsベースの新環境へのリプレイスを進める中で、フレームワークに依存しないUI共有アーキテクチャが必要となりました。 本記事では、iframeベースの共有方式が抱える具体的な課題と、LitベースのWeb Componentsを採用した理由と選定プロセスを解説します。さらに、フレームワーク非依存なコンポーネント共有基盤を設計・実装する中で得た経験を共有します。 対象読者 マルチWebアプリケーション環境でUI共有に課題を感じているフロントエンドエンジニア iframeを使ったUI共有方式の代替手段を探している方 Web Componentsの導入を検討している方 目次 はじめに 対象読者 目次 背景・課題 ZOZOTOWNフロントエンドのマルチWebアプリケーション構成 LPコンポーネントの共有仕様 従来のiframeベース共有方式とその課題 1. レイアウト制御の煩雑さ 2. UI制御の複雑化 3. SEOの制約 アプローチ：Web Componentsの導入 要件整理 技術選定：Lit基盤Web Components Litを選択した理由 npmパッケージ方式を除外した理由 設計・実装 全体アーキテクチャ 1. 利用側アプリケーションによるデータ取得・加工 2. Lit ContextによるProps Drilling防止 3. Scriptローディングによる独立したUI更新 4. Shadow DOMからLight DOMへの切り替え ビルド・配信 全体フロー LPコンポーネント開発側（コンテンツ共有専用リポジトリ） 利用側Webアプリケーション 効果 学んだこと 今後の課題 今後の展望 まとめ 最後に 参考資料 背景・課題 ZOZOTOWNフロントエンドのマルチWebアプリケーション構成 現在、ZOZOTOWNのフロントエンドは3つのマルチWebアプリケーションで運用されています。 リポジトリ 説明 主な役割 リポジトリA（レガシー環境） 統合リポジトリ 既存の全ページを管理 リポジトリB（リプレイス環境） コアメインページ ホーム、カート、検索結果、商品詳細ページなど リポジトリC（リプレイス環境） 企画ページ フルスクラッチLP、CMS活用LP レガシー環境では複数のサービスが単一リポジトリで管理されていたため、共通UI共有に関する課題はありませんでした。しかし、リプレイス後にマルチWebアプリケーションが増えたことで、従来の方式ではUIを再利用できなくなりました。 LPコンポーネントの共有仕様 ZOZOTOWNでは特定のLPコンポーネントを複数のページで表示しています。一部のページでは以下の2つの形態で表示されます。 単独ランディングページ — header/footerを含むフルページ モーダル表示 — 特定ページのバナークリック時に、header/footerなしでコンテンツセクションのみをモーダルで表示 つまり、ほぼ同一のUIでありながら、header/footerの有無、SEOメタタグ、計測用トラッキングスクリプトの有無などで差異がある仕様でした。 従来のiframeベース共有方式とその課題 リプレイス後は以下の方式でUIを共有していました。 環境 運用方式 リポジトリA（レガシー） LPページ配信 + iframe用LPページ（header/footerなし）配信 リポジトリB・C（リプレイス） 特定ページにバナー表示 → クリック時にモーダル内でiframeとしてリポジトリAのLPを埋め込み このiframe方式には以下の課題が存在していました。 1. レイアウト制御の煩雑さ iframeは独立したドキュメントを読み込むため、フレームサイズの調整や使用箇所ごとの非表示領域の処理は対応していたものの、煩雑な部分がありました。 2. UI制御の複雑化 各バリエーションに応じて非表示にすべき子コンポーネントもあり、クエリパラメータや postMessage で解決できるものの、ケースが増えるほど複雑化しました。 3. SEOの制約 検索エンジンはiframe内のコンテンツを src 側の所有として認識するため、SEO上の制約がありました。 アプローチ：Web Componentsの導入 要件整理 上記の課題を解決するために、以下の4つの要件を整理しました。 要件 説明 各アプリのデプロイなしにUI更新 iframe方式の利点であった各マルチWebアプリケーションのデプロイなしにUI変更が反映されることを維持 iframe脱却 各アプリケーションでネイティブにUIをレンダリング フレームワーク非依存 React、Vueなど、どのフレームワークでも使用可能であること 軽量バンドルサイズ 利用側に負担のない最小限のサイズを維持 技術選定：Lit基盤Web Components Web Componentsはブラウザのネイティブコンポーネントモデルであり、特定のフレームワーク（React、Vueなど）に依存せず、ブラウザが直接理解する標準技術です。主に以下の3つの中核技術で構成されています。 Custom Elements ：開発者が独自のHTMLタグを定義できる。タグ名にはハイフン（ - ）を含む規約がある。 Shadow DOM ：コンポーネントのスタイルとマークアップを外部ページから隔離（Encapsulation）する。 HTML Templates ： <template> と <slot> 要素により、再利用可能なマークアップ構造を定義する。 このWeb Componentsをより効率的に開発するため、 Lit ライブラリを採用しました。 Litを選択した理由 選定基準 Litの特徴 バンドルサイズ 約5KB（minified + compressed）で非常に軽量 リアクティブプロパティ Reactive Propertiesにより状態変更時に自動再レンダリング テンプレート Tagged Template Literalsベースで別途コンパイル不要 パフォーマンス Virtual DOM diffingなしに動的部分のみを直接更新 相互運用性 すべてのLitコンポーネントはネイティブWeb Componentであり、HTMLを使うあらゆる場所で動作 npmパッケージ方式を除外した理由 LPページはテキスト更新の頻度が高く、UIも不定期に変更されます。npmパッケージで運用すると、変更のたびに各環境でパッケージ更新＋デプロイが必要となり、運用負荷が大きいため除外しました。 設計・実装 全体アーキテクチャ コンテンツ共有専用リポジトリを新たに構築し、以下の設計原則を適用しました。 1. 利用側アプリケーションによるデータ取得・加工 ZOZOTOWNにはページアクセス時に初期設定すべき値やAPIフェッチのためのロジックが各アプリケーションに存在します。これらのロジックをコンテンツ共有専用リポジトリにも含めると管理が二重になりメンテナンス負荷も大きくなるため、このリポジトリでは UIレンダリングのみ を責任範囲としました。 利用側の親アプリケーションでデータを取得・加工してpropsで渡す形式を採用しています。 2. Lit ContextによるProps Drilling防止 UI内部で必須的に共有すべき情報（デバイス種別、性別など）は、 Lit Context を活用したカスタム要素を設けて処理しました。 Lit ContextはReactのContext APIと同様の概念で、Props Drillingなしに上位から下位コンポーネントへデータを渡すことができます。 3. Scriptローディングによる独立したUI更新 各Webアプリケーションで別途デプロイなしにUI変更が可能なよう、 Scriptローディング を採用しました。各アプリケーションでは <script> タグで必要なコンポーネントのJSファイルを読み込み、クライアントでWeb Componentがレンダリングされます。 4. Shadow DOMからLight DOMへの切り替え Web Componentsの代表的な特徴であるShadow DOMは、スタイルを完全に隔離し、コンポーネント内部のCSSが外部に影響せず、外部CSSも内部に影響しません。 しかし、今回のケースでは、Shadow DOMで隔離して管理するUIではなく、利用側から自由にスタイルだけでなく要素にもアクセスできることが重要でした。そのため、Shadow DOMの代わりに Light DOM を採用しました。 ビルド・配信 Viteを使用してLit基盤Web Componentをビルドし、S3にデプロイしてCDN経由で配信します。 全体フロー LPコンポーネント開発側（コンテンツ共有専用リポジトリ） Lit + Vite dev serverでローカル開発 各テスト環境にてHTML + JSで動作確認 問題なければ各環境（S3）にデプロイして確認 利用側Webアプリケーション SSR時にCMS APIでデータ取得（スケジュールに応じて変更されるテキストなどはCMSで管理） クライアントで <script> タグによるJSファイルローディング、Web Componentのレンダリング カスタムタグへCMS API仕様に合わせたデータをpropsで渡す 効果 この仕組みの導入により、以下の効果が得られました。 マルチWebアプリケーション間でiframeを使わずにUIコンポーネントを共有できるようになった 各アプリケーション側のリリース（デプロイ）なしでコンテンツ更新が可能になった 利用側からスタイルだけでなく要素へのアクセスも自由に可能になった（Light DOM採用） CMS連携により、エンジニア以外でも直接スケジュールベースのデータ管理が可能に 学んだこと Litを通じて開発する中で、Web Componentsのベースとなるウェブ標準技術をより深く理解し、関心を持つようになりました。また、CSS変数などを活用してJavaScriptなしにCSSだけでスタイルを制御する方法も知ることができました。 今後の課題 Web Components公式のSSR対応はまだ限定的ですが、Lit SSRなど複数の解決策がライブラリやコミュニティで共有されています。現在、このプロジェクトで管理しているLPページの仕様ではWeb ComponentのSSRは不要ですが、将来に備えた準備は必要だと考えています。 また、現在の運用方式では、Scriptローディング＋CMSデータ連携という構造上、テストが非常に重要であり補強が必要です。 今後の展望 移行すべきLPページが多数残っており、段階的にマイグレーションを進めていく予定です。より小さな単位の共用コンポーネントもこの基盤で管理できるよう拡張を検討しています。また、可能であれば、ネイティブアプリケーションでの活用も検討したいと考えています。 まとめ 本記事では、ZOZOTOWNのマルチWebアプリケーション環境におけるiframeベースUI共有方式の課題を解説しました。また、LitベースのWeb Componentsを活用したフレームワーク非依存のコンテンツ共有基盤の構築事例を紹介しました。 ReactベースであればReactでもUIを共有する方法はあります。しかし、今後どのフレームワークでも問題なく移植できるWeb Componentsを選択し、メインスタックと共存しながら運用するのもよいのではないでしょうか。同様の課題をお持ちの方の参考になれば幸いです。 最後に ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com 参考資料 MDN - Web Components Lit 公式ドキュメント Lit Context MDN - Using Shadow DOM MDN - iframe Vite - Building for Production

こんにちは！エデュケーショナルサービス課の佐藤です。 AWS EventBridgeのコンソールに最近登場した「ビジュアルルールビルダー（オプトイン機能）」ですが、直感的にルールが作成できて便利な機能ですよね。 しかし、入力トランスフォーマーを設定中、正しいJSONを入力しているはずなのに、画面に赤文字で 「トランスフォーマーが無効です: 無効な構文」と表示された方はいませんか？ それはあなたの記入ミスではなく、ビジュアルルールビルダーの不具合かもしれません。 この記事では、AWSサポートから正式に不具合であるという回答をいただいたので、同様の事象で悩んでいる方向けに情報を共有したいと思います…

みなさん、こんにちは。AWS のソリューションアーキテクトの伊藤ジャッジです。 このブログでは開催予定のイベントや直近1カ月に発表された製造関連のブログ・サービスのアップデート・事例などをお届けしています。国内だけでなく海外の情報も含めていますので、リンク先には英語の記事・動画も含まれていますが、解説を加えていますのでご興味あればぜひご覧ください。 過去の月刊製造ブログはこちらです 。未読の方はあわせてご覧ください。 さて、AWS は創立二十周年を迎えました! AWS のサービスもお客様と共に成長してきました。その軌跡を こちらの二十周年記念記事 でご覧ください。これからも皆様からのフィードバックを元に、サービス改善を続けていきます。 AWS の節目の時期となりましたが、4 月は多くの企業も年度始まりですね。フレッシュな区切りの時期ですが、一方で先月末の棚卸しという重要なタスクもあったと思います。今回は、在庫管理、需要予測またサプライチェーン管理に役立つ情報をピックアップコンテンツとして特集をします。 ピックアップトピック：サプライチェーン管理 製造業において在庫管理は、経営効率の中枢を担う機能の一つです。在庫不足は生産ラインの停滞や顧客納期の遅延を招きますし、過剰在庫は保管コストやキャッシュフローを圧迫します。多品種少量生産や受注変動が常態化する現代では、単に在庫を管理するだけでなく、需要変動を先読みし供給網全体を最適化する仕組み作りが不可欠になっています。 ここで鍵を握るのが、需要予測とサプライチェーンマネジメントの活用です。販売実績や市場動向、季節要因、経済指標など多様なデータを AI で解析し、過去の傾向をつかみ将来の需要を精度高く予測し、必要量を前もって準備できます。これにより「作りすぎ」「作らなさすぎ」のムダを減らし、生産・調達・物流を連動させた全体最適が実現します。 こうしたデータドリブンな仕組みを飛躍させるのがクラウド技術です。工場や倉庫、販売拠点から収集されるさまざまな記録をクラウドに統合し、データの可視化と分析を可能にします。さらにエージェントAI を活用することにより、全体を俯瞰しながらボトルネックや需給ギャップを自律的に発見し、複数拠点をまたいだ調整のアクションまで実行できます。AI による「データ駆動の意思決定サイクル」を回しやすいのがサプライチェーンの領域といえます。 お客様事例 3 月には、サプライチェーン関連のお客様事例として、OPLOG 社 の AWS の AI サービスの活用の事例が発表されています。 1. Learn how technology-driven fulfillment company OPLOG accelerated decision-making using Amazon Bedrock AgentCore 倉庫管理企業の OPLOG 社が、AIエージェント × ロボティクスで倉庫オペレーションを変革した事例です。 Amazon Bedrock AgentCore を使って複数のAIエージェントがリアルタイムに数千の判断を下す基盤を構築しました。その結果、意思決定時間、稼働率、コスト全ての効率が上がりました。生成 AI エージェントを本番投入したい方が、構想→PoC →スケーラビリティのイメージをつかむための良い事例ですので、ぜひ元記事でご確認ください。 2. Amazon Multi-Channel Fulfillment and Buy with Prime Accelerators for SAP S/4HANA が利用可能に こちらは 1 月の発表とはなりますが、 SAP S/4HANA から Amazon MCF と Buy with Prime を直接アクセスできるようにすることで、在庫一元管理と出荷を自動化し、欠品・過剰在庫の抑制や在庫管理のコスト削減といった効果が期待できる、という機能の発表がありました。 こちらは既存 SAP への変更を最小限に抑えつつ、Prime 配送や簡単返品などの購入体験を自社 EC にも拡張できる機能となります。詳細の仕組みについては、ぜひリンク先本文をお読みください。 Amazon 社との協業 Amazon is investing AU$750 million in a robotics fulfillment center in Australia Amazon 社の倉庫におけるロボティクス技術活用がまた進化したニュースが 3 月に発表されました。オーストラリアに新しいロボット駆動のフルフィルメントセンターを建設します。ここでは人とロボットが協働し、ロボットが重量物や反復作業を担うことで、従業員は判断が必要な業務に集中できるように設計されています。安全性と効率性を両立した職場づくりの取り組みや倉庫業務を行う、ワクワクする最新ロボットの詳細につきましては、リンク先をご覧ください。 AWS が提供する ワークショップ コンテンツ AWS からはセルフペースで手を動かしながらサンプルを構築し、サービスについて学べるワークショップが提供されています。3 月には、サプライチェーンの課題にフォーカスした下記のワークショップが新しくリリースされました。 Amazon Bedrock を使用した AI 駆動型サプライチェーン管理の構築 このハンズオンワークショップでは、 Amazon Bedrock AgentCore の機能を使用して既存のサプライチェーンシステムを強化する方法を学びます。 Strands Agents SDK とインタラクティブな Jupyter ノートブックを使用して、紛争や天災によるサプライチェーンの混乱を分析し、在庫配分を最適化し、緩和戦略を自律的に実行できるサプライチェーン管理システムを構築できます。 Amazon Bedrock AgentCore で実現する Chronos-2 を用いた時系列予測エージェント 時系列予測は在庫管理の分野で活用されてきましたが、このワークショップで体験できる Chronos は、AWS が開発した時系列基盤モデルです。事前に膨大な時系列データでトレーニングされた時系列予測モデルで、大規模言語モデルで利用されている Transformer を応用することで、予測対象の実績データをトレーニングすることなく、さまざまなケースで高い精度の予測を実現します。Chronos-2 はその最新モデルで、多変量予測においても、新しいデータセットに対して追加学習なしで、即座に高精度な予測が可能になっています。AWSのソリューションアーキテクトが執筆した 紹介ブログ もあります。 上記のワークショップにご興味をもたれましたか？ぜひ貴社の技術支援担当の者か、 技術支援窓口 にお問い合わせください。 なお、 AWSからはサプライチェーン系ワークロードを AWS 上で設計・運用する際のベストプラクティスと設計指針を体系的に示す Supply Chain Lens – AWS Well-Architected Framework が提供されていますので、あわせてご参照ください。 企業競争力の源泉は、もはや製造スピードだけではなく、データに基づく俊敏なサプライチェーン運営にあります。クラウドと AI を活用した在庫・需要・供給そして AI によるアクションの統一管理が、製造業の持続的な成長を支える次のステージとなるでしょう。今回のピックアップトピックが、皆さまのより良いサプライチェーン運営のきっかけになれば幸いです。 以上、4 月のピックアップコンテンツでした。 直近で開催予定のイベント・セミナー CAE in the Cloud 2026　〜 自動車・製造業向けCAEセミナー 〜 本年 2 月（東京リージョンは 3 月）に一般提供開始した Hpc8a インスタンス をはじめとしたAWS の最新ソリューションの情報をお届けするイベントです。4 月 20 日の週に東京・大阪・名古屋 3 か所で開催します。 Hannover Messe 先月号 でも紹介しましたが、2026 年 4 月 20 日（月）～ 4 月 24 日（金）に製造業の国際展示会がドイツのハノーヴァーで開催されます。 詳細はブログ記事、「 Hannover Messe 2026 で知る AWS による産業 AI の大規模展開 」もご参照ください。AWS もブース展示しますので、ホール 15、ブース D76 の AWS ブースにご来訪ください。 AWS JumpStart 2026 「AWS を使ってみたいけれど、学習方法がわからない」という初学者を対象に、AWS JumpStart 2026 が開催されます。直近では、2026年 5 月 11 日 (月) ~ 5 月 12 日 (火)（各回 2 日間：9 – 18 時）のオンライン開催となっています。製造業に限らず、高度な専門分野の技術に長けた専門家の皆様で、今までクラウドには触れてこなかった方は多くいらっしゃると思います。１モジュールから参加できますので、この機会に触れてみてください。 AWS Summit Japan 2026 今年も日本最大の “AWS を学ぶイベント” AWS Summit Japan が 6 月 25 日（水）、26 日（木）の二日間で開催されます！ベストプラクティスの共有や情報交換のこのチャンスにぜひご来場ください。[ 動画 ] フィジカル AI、シミュレーション、サプライチェーンなどの、去年よりパワーアップした製造業向け展示もあります！ 過去 の イベント の 見逃し配信 や 動画 JAWS-Days AWS 利用者コミュニティ、JAWS のイベントが 3 月 7 日に行われました。皆様はご参加されましたか？あいにく行けなかった！という方にもアーカイブ動画が出ています。SAP、セキュリティといった製造業の皆様にも役にたつ動画が満載のアーカイブです。ぜひご覧ください。 CES 2026 – Physical AI for Adaptive Automotive Manufacturing | AWS Events 1 月に開催された CES の動画が AWS の公式チャンネルで公開されました。 AWS のデモでは、フィジカル AI が工場現場をどのように変革するかを紹介しました。こちらの動画では AWSの 5 つの要素（データ、トレーニング、シミュレーション、Sim 2 Real、Agentic なオーケストレーション）を柱に、物理の工場のモダン化から未来の工場設計まで、次世代の自動車生産を実現するデモのサマリをご覧いただけます。 製造関連の アップデート Auto & Manufacturing – Kiro for Business Users AWS が提供する AI コーディングアシスタント「 Kiro 」を活用して流体シミュレーションの構築から 3D モデリングを試行できるワークショップが3月に公開されています。製造業の設計部門の方々のご活用をお待ちしています。AWS のソリューションアーキテクトが執筆した日本語の 紹介ブログもあります 。 AWS IoT Greengrass v1 サポート終了 半年後の 2026 年 10 月 7 日に、Greengrass v1 のサポートが終了します。製造業の皆様は工場などクローズな環境や、スマートプロダクトに使っているかもしれません。まだの場合は早急な AWS IoT Greengrass v2 への移行をお願いします。 製造関連の Blackbelt Online Seminar アップデート 【AWS Black Belt Online Seminar】AWS IoT Greengrass コンポーネント開発編 エッジデバイス上でアプリケーション（コンポーネント）を動かし、クラウド側から一括デプロイ・更新・管理できる AWS IoT Greengrass の「コンポーネント開発編」の解説動画が 3 月にリリースされました。 製造業のお客様のAWS活用事例 下記は、3月に発表された製造業のお客様事例となります。製造業の皆様のもつ課題やゴールと似たお話があるかもしれません。ぜひ本文をご覧ください。 How Amazon Devices Eliminated Credential Risk to Scale AI across Engineering Tools Amazon 社には自社で開発・販売しているハードウェア製品 を取り扱う Amazon Devices という組織があります。この組織でハードウェア開発を加速するため、Creo、 Parametric、SOLIDWORKS、ANSYS など 60 以上のエンジニアリングツールに直接 AI を統合する必要がありました。10,000 人以上のエンジニアが使用しているこれらのツールは、ローカルのワークステーション上で動作しているため、セキュリティを維持しながらクラウド上の AI を活用できる仕組みが求められていました。このブログでは、Amazon Devices のエンジニアが、クレデンシャル配布をせずに認証して、ローカルの設計ツールから Amazon Bedrock にセキュアに接続した方法を寄稿しています。 The Evolution of BMW Group’s 3D Streaming Experience BMW 社は、オンプレミスで稼働していたディーラー向けの 3D 車両ストリーミングを、 AWS 上の Linux GPU（g4dn.2xlarge）でグローバル提供できる 3D ストリーミング基盤に移行しました。製造業の R&D 部門の皆様は 3D データを配信する場面があると思います。ぜひご参考にしてください。 Driving Intelligent Quality in the Software-Defined Vehicle Era Upstream 社の PQD (Proactive Quality Detection) が Ocean AI エンジンを使用して「モビリティ特化のインテリジェンス層」を AWS のスケーラブルなインフラ・ストレージ・セキュリティ・AI 基盤上で提供しています。SDV 時代の品質管理を、実環境のデータベースの継続的な予測型プロセスに変革することに成功した事例をご覧ください。 AI 時代に組織はどう変わるか — Jeff Barr が語る開発チームの未来と、三菱電機の挑戦 三菱電機はデジタル基盤「 Serendie 」による DX を進め、モノの販売中心からデジタルサービスのコト売りへ事業転換中です。この過程で、AI 時代の開発組織についてのインサイト、生産性向上事例と KPI の変化、人材育成、コミュニティと組織変革について、イベントのため来日した、AWS の Chief Evangelist である Jeff Barr との対話しました。 三菱電機が挑む製造業の商談変革 – AWS で実現した商談支援サービス「Memory Tec h」 三菱電機名古屋製作所は、製造業の商談で起きがちな「口頭コミュニケーションの認識齟齬」を解消するため、AI商談支援サービス「 Memory Tech 」をAWS上で新規開発しました。 AWS のサーバーレス構成により、ブラウザやスマホだけで商談録音から 2 分以内の議事録自動生成を実現し、少人数でスモールスタートとスケーラブルな運用を両立しました。詳細は本文をご覧ください。 電通総研、大規模 GPU 環境を約 1 ヶ月で構築 〜リアルタイム 3DCG ソリューション「UNVEIL」の戦略的アプローチ 〜 電通総研はリアルタイム 3DCG メタバース「UNVEIL」の大規模イベント利用に向け、1,000 名同時接続で低レイテンシーを満たす GPU 環境を AWS 上に約 1カ月で構築しました。東京リージョンで Amazon EC2 g4dn/g5 や Amazon EKS などを活用し、段階的な負荷試験と複数回の事前テストでボトルネックを洗い出しつつ、イベント駆動型ワークロードに適した、スケーラブルかつコスト効率の高いアーキテクチャを設計しました。どのように実装したのでしょう。ぜひ本文をチェックしてください。 キヤノン株式会社イメージング事業本部様にて生成 AI ハッカソンを開催！生成 AI をフル活用し社内課題を解決する 5 つのシステムを開発 キヤノン 株式会社 イメージング 事業本部と AWS が協力し、社内業務課題を生成 AI で解決することをテーマに約 6 カ月のハッカソンを実施した事例です。 約 20 名のエンジニアが 5 チームに分かれ、AWS の生成 AI サービスの勉強会、アイデアソン、プロトタイピングを通じて、実用レベルの 5 つのプロトタイプを開発し、いくつかのプロトタイプでは実業務での活用検討が進んでいます。 最後まで読んでいただきありがとうございました。今月は サプライチェーン管理に役立つ情報をピックアップしてお届けしました。このような形式で毎月最新の情報を製造業の皆様にお届けして参ります。 月刊 AWS 製造ブログ を今後ともよろしくお願いします。それでは、また来月お会いしましょう！   伊藤ジャッジ向子 (Ito, Judge Sakiko) 米国での開発者経験を経て、AWSのサポートに入社し、異動しエンタープライズ事業本部でソリューションアーキテクトとして製造業のお客様をご支援しています。趣味は山登り、クラッシックバレエと愛犬のお世話です。