はじめに 10年以上前、単語を単なる記号ではなく、意味の近さを「距離」で表現する高次元ベクトルへと数値化する技術「Word2Vec」が登場しました。これが、AIの重要技術の1つである「埋め込み（Embedding）技術」が研究界で大きな注目を集める契機となりました。 その後、この技術は単語から文章、さらには画像へと適用の幅を広げ、AIは次第にそれらの「意味」を理解し始めます。類似する文章や画像を検索する精度は飛躍的に向上しましたが、当時はまだ、文章と画像を同じ尺度（共通のベクトル空間）で扱うことは困難でした。 その壁を打破したのが、2021年にOpenAIが発表した「CLIP」です。CLIPは文章と画像で共通の埋め込みを作成することに成功し、いわば両者の意味を繋ぐ「共通言語」を誕生させました。このマルチモーダル埋め込みの成功を皮切りに、現在は音声や3Dデータなど、あらゆる情報を共通の埋め込み空間で扱う研究が加速しています。 現在、製造業においてもこれらの技術は浸透しつつあります。画像埋め込みを用いた「図面類似検索」や、テキスト埋め込みを応用した「RAG（検索拡張生成）」などがその代表例です。しかし、現状では単一モーダルの活用が主流であり、マルチモーダル埋め込みの真の社会実装はまだ始まったばかりと言えるでしょう。 マルチモーダル埋め込みの研究分野での盛り上がりを鑑みれば、今後この領域が製造現場に社会実装されていくのは間違いありません。本記事では、マルチモーダル埋め込みの概要から最新の研究事例、そして製造業における活用の未来について詳しく解説します。 「埋め込み」とは？ この節では、そもそも「埋め込み」「マルチモーダル埋め込み」とは何かを説明します。 「埋め込み」とは、一言で言えば「現実世界のあらゆる情報を、AIが計算しやすい『多次元空間上の座標（ベクトル）』に変換する技術」のことです。人間が言葉の意味を理解するように、コンピュータに「概念の近さ」を数値として教え込むプロセスだと考えると分かりやすいでしょう。 埋め込みを使うことで、次の3つのことを実現します。 1. 「記号」を「座標」に変える コンピュータは本来、数字しか扱えません。かつて、AIに「リンゴ」という言葉を教える際は、単に「101番」という背番号（ID）を割り振るだけでした。しかし、これでは「リンゴ」と「ナシ」が似ているという意味のつながりを計算できません。 埋め込み技術は、エンコーダーを使い、例えば「リンゴ」を [0.12, -0.54, 0.88, ...] という数百次元の数値の並び（ベクトル）に変換します。この数値は、その対象が持つ「甘み」「赤い」「果物」といった無数の特徴を凝縮した地図上の座標のようなものです。 2. 「近さ」で意味を測る データが座標（ベクトル）になると、データ同士の「距離」を計算できるようになります。 意味が似ているもの： 空間上で近くに配置される（例：「犬」と「猫」） 意味が異なるもの： 空間上で遠くに配置される（例：「犬」と「数学」） 3. 多様なデータを一箇所に集める（マルチモーダル） 最新の埋め込み技術の凄さは、テキストだけでなく、画像、音声、センサーデータまでも同じ空間に並べられる点にあります。 例えば図1のように、「犬が走っている」というテキスト、ゴールデンレトリバーの画像、「ワンワン！」という鳴き声、そして走る犬の動画。これらは入り口こそバラバラですが、それぞれの専用エンコーダーによって「ベクトル（数値の並び）」へと変換されます。 変換されたデータは、多次元の「埋め込み空間」の中に配置されます。この空間の最大の特徴は、「意味が似ているものほど、近くに配置される」という性質です。この例では、データ形式が違っていてもすべて「犬」という同一のコンセプトに関連しているため、AIの頭の中（空間）では同じエリアにギュッと集まります。 これにより、AIはデータ形式の壁を越えて、「これは『犬』という本質的な概念だ」と一貫して捉えることが可能になるのです。 図1 マルチモーダル組み込み　犬の例 埋め込みの歴史 埋め込み技術は、わずか10年余りの間に驚くべき進化を遂げてきました。ここでは、その進化の道筋を象徴する3つのマイルストーンを紹介します。「単語だけ」から始まった技術が、「画像と言葉の融合」を経て、「3Dシーンの丸ごとアライメント」へと到達する物語です。 Word2Vec ── 言葉に「座標」を与えた原点 Mikolov et al., 2013 2013年、Googleの研究チームが発表したWord2Vecは、「言葉の意味を計算できるようにした」という点で、自然言語処理の歴史を塗り替えました。 それまでの限界：One-hotベクトル Word2Vec以前、コンピュータに単語を教える方法は非常に素朴でした。「One-hotベクトル」と呼ばれる方式では、語彙数と同じ長さのベクトルを用意し、該当する単語の位置だけを「1」、残りをすべて「0」にします。 例えば語彙が5万語あれば、「リンゴ」は5万次元のベクトルの中で、たった1箇所だけ「1」が立っている状態です。この方式には2つの致命的な欠陥がありました。 次元の呪い： 語彙が増えるほどベクトルが膨大かつ疎（スカスカ）になり、計算効率が極めて悪い。 意味の不在： 「リンゴ」と「ナシ」のベクトルは完全に直交しており、距離を測っても「近い」とも「遠い」とも言えない。つまり、意味の類似度が一切計算できない。 Word2Vecの発想の転換 Word2Vecは、この問題をシンプルかつ強力なアイデアで解決しました。「ある単語の意味は、その周囲に出現する単語によって決まる」という言語学の仮説（分布仮説）に基づき、大量のテキストから単語の「使われ方のパターン」を学習したのです。 具体的には、ニューラルネットワークに以下の2つのタスクのいずれかを解かせます。 CBOW： 「昨日 ___ を食べた」→ 空欄に入る単語を、周囲の文脈から予測する。 Skip-gram： 「リンゴ」という単語から、その周囲に出現しやすい単語（「食べた」「赤い」「果物」など）を予測する。 このタスクを何億もの文章で繰り返すことで、各単語は数百次元の密なベクトル（分散表現）へと圧縮されます。「リンゴ」と「ナシ」は似た文脈で使われるため、自然と空間上で近くに配置されるのです。 なぜ衝撃的だったのか Word2Vecが世界を驚かせたのは、学習されたベクトルが「意味の足し算・引き算」を可能にしたことです。 「王様」−「男」+「女」＝「女王」 この計算が成立するということは、ベクトル空間の中に「性別」「階層」といった意味の軸が自然に形成されていることを意味します。人間が明示的に教えたわけではなく、AIが大量のテキストから自ら意味構造を発見した ── この事実は、後の埋め込み技術すべての出発点となりました。 CLIP ── 画像と言葉の壁を壊した転換点 Radford et al., 2021 Word2Vecが「単語同士の距離」を測れるようにしたのに対し、2021年にOpenAIが発表したCLIP（Contrastive Language-Image Pre-training）は、さらに大胆な問いに挑みました。「画像と言葉の距離を測ることはできないか？」── CLIPの答えは、驚くほどシンプルでした。 4億枚の「画像＋キャプション」で学ぶ CLIPは、画像用とテキスト用の2つの独立したエンコーダーを備えています。学習に使ったのは、インターネットから収集した4億セットの「画像とキャプションのペア」。この膨大なデータを使い、以下のルールでベクトル空間を鍛え上げます。 正しいペアは近づける： 犬の画像と「走る犬」というキャプション → ベクトルを空間上で近くに配置。 無関係なペアは遠ざける： 犬の画像と「青い車」というキャプション → ベクトルを空間上で引き離す。 これが「対照学習（Contrastive Learning）」です。正解と不正解を対比させながら空間を整えていくことで、画像とテキストが同じ座標系で「意味的に比較可能」になります。 「見たことがないもの」を理解できる CLIPの最も画期的な特徴は、「Zero-shot性能」と呼ばれる能力です。従来の画像認識モデルは、「犬」「猫」「車」などのラベルを事前に教え込む必要がありました。学習していないカテゴリは認識できません。 CLIPは違います。ラベルではなく「言語の概念そのもの」を学習しているため、一度も見たことがない物体でも、テキストで説明すれば識別できます。例えば「三角形の赤い標識」と入力すれば、学習データに含まれていなくても該当する画像を見つけ出せるのです。 この「データ形式を超えた意味の理解」こそ、マルチモーダル埋め込みの幕開けでした。 CrossOver ── 3Dシーンを丸ごと対応づける最前線 Sarkar et al., 2025 (CVPR 2025 Highlight) CLIPが画像とテキストの2つのモダリティを結びつけたのに対し、2025年にコンピュータビジョンの最高峰学会CVPR 2025でハイライト論文に選ばれたCrossOverは、さらに多くのモダリティへと対象を広げました。RGB画像、点群（Point Cloud）、CADメッシュモデル、フロアプラン、テキスト── これら5種類ものデータを1つの共通空間にまとめ上げ、3Dシーン全体をモダリティ横断で対応づける（アライメントする）フレームワークです。 従来手法の限界：「完璧なデータ」がないと動かない これまでの3Dマルチモーダル学習には、大きな制約がありました。「椅子」「テーブル」といったオブジェクト単位で厳密にラベルを付けたアノテーションが必要で、しかも全てのモダリティ（画像・点群・CADなど）が揃っていなければ学習できなかったのです。 しかし現実のAR/VRやロボティクス、建設モニタリングといった現場では、そんな理想的なデータが揃うことはほとんどありません。ある部屋は3Dスキャンデータしかない、別の部屋はCAD図面と写真だけ ── こうした「歯抜け」のデータが当たり前です。 CrossOverの3つの工夫 CrossOverは、3つの工夫でこの「現実の壁」を突破しました。 1つ目は、 「シーンまるごと」で対応づける こと。従来はオブジェクト1つ1つに丁寧なラベルを貼る必要がありましたが、CrossOverは「部屋全体」「フロア全体」といったシーン単位で異なるモダリティを結びつけます。いわば、家具を1個ずつ辞書登録するのではなく、部屋全体の写真を1枚見せて「ここにあるもの全部まとめて覚えて」と教えるようなイメージです。 2つ目は、 データが歯抜けでも学習できる こと。5種類全てのデータが揃っている必要はありません。「この部屋は点群とテキストしかない」「あの部屋はRGB画像とCADだけ」── そんな不完全なデータでも、手持ちのモダリティだけで埋め込みを計算し、学習に組み込めます。 3つ目は、 段階的に賢くなる学習戦略 です。各モダリティに専用のエンコーダを用意し、最初は少ないデータの組み合わせから始めて、徐々に複雑な組み合わせへと学習を積み上げていきます。完璧なデータを待たずに、今あるデータから着実に知識を蓄積できるのです。 何ができるようになるのか CrossOverにより、データの形式を飛び越えた3D検索・解析が現実のものになります。 例えば、フロアプラン（間取り図）を検索クエリとして入力すれば、対応する3D点群データが検索結果として返ってくる。逆に、点群データから対応するフロアプランやCADモデルを見つけ出すことも可能です。さらに、明示的に学習していないモダリティの組み合わせ（例：フロアプラン ↔ テキスト）でも検索が機能する「創発的な汎化能力」が確認されています。 これはまさに、製造業や建築業が待ち望んでいた技術です。次の章では、この技術が製造現場でどのように活用されていくのかを具体的に見ていきます。 製造業における活用の未来 ここまで紹介してきたマルチモーダル埋め込み技術は、あくまで「要素技術」です。では、この技術が製造業の現場に入ると何が変わるのか？ ── ここからは、最も実用化が近い「検索」の応用領域を見ていきます。 検索 ── 「探し方」が根本から変わる 製造業には、長年にわたって蓄積された膨大な図面・3Dデータ・仕様書が眠っています。しかし、その多くはファイル名や管理番号といった「メタデータ」でしか検索できません。番号を忘れたら最後、必要なデータにたどり着けない ── そんな経験のある方も多いのではないでしょうか。 マルチモーダル埋め込み技術は、この「探し方」を根本から変えます。データの本質的な「意味（特徴）」がベクトル化されることで、メタデータに頼らない、3つの新しい検索が可能になります。 クロスモーダル検索：形状で図面を探す 「データ形式の壁」を越える検索です。 設計担当者が、過去の類似製品の仕上がりを確認したい場面を想像してください。従来は管理番号を手がかりに過去資料を探し回る必要がありましたが、マルチモーダル埋め込みを使えば、開発中の3D CADデータをそのまま検索クエリとして入力するだけで済みます。AIが埋め込み空間上で「形状的・構造的に近い」過去の製品図面（画像）を瞬時に見つけ出してくれるのです。 管理番号が不明な古い部品でも、形状さえあれば「過去の類似品」を紐付けられる。これだけでも、設計の初期段階で過去の知見を活かしやすくなります。 マルチモーダル検索：「画像＋テキスト」で絞り込む 1つのモダリティでは足りない場面に効く検索です。 例えば、「このフランジ（画像）と同じ形状で、かつ材質がステンレス（テキスト）のもの」を探したいとします。画像だけでは材質まで判別できませんし、テキストだけでは形状の微妙な違いを表現しきれません。 マルチモーダル検索では、画像の「視覚的な特徴ベクトル」とテキストの「仕様的な特徴ベクトル」を掛け合わせることで（ベクトル加算など）、両方の条件を満たすデータをピンポイントで特定できます。材質、硬度、耐熱性── 画像では見えない情報を言葉で補足することで、検索精度が格段に上がるのです。 AIチャット検索：現場の言葉でデータを引き出す 対話型インターフェースを介した検索です。 現場の作業員がタブレットに向かって「先週のライン停止時に、ベアリング付近を撮影した写真を見せて」と話しかける。あるいは「この3Dモデルの、取付穴が5つあるバリエーションをリストアップして」と指示を出す。── ユーザーの発話がテキストベクトルに変換され、データベース内の画像・3Dデータのベクトルと直接照合されることで、こうした自然な対話での検索が実現します。 複雑な検索コマンドを覚える必要はありません。専門知識がなくても「現場の言葉」で必要な技術資産にアクセスできるようになる点が、現場への浸透を考えると最大の強みです。 おわりに 本記事では、埋め込み技術の進化を「単語だけ」のWord2Vecから、「画像と言葉」を結んだCLIP、そして「3Dシーンを丸ごと対応づける」CrossOverへとたどりました。この10年余りで、AIが「意味」を捉える範囲は劇的に広がっています。 製造業にとって、この技術が意味するのは「データの探し方の根本的な変化」です。ファイル名や管理番号に頼っていた検索は、形状やテキストの「意味」で直接つながるようになります。ベテラン設計者の頭の中にしかなかった「あの時似たようなものを作った」という経験知は、埋め込み空間を通じて組織全体で共有できるデジタル資産へと変わります。 現時点では、製造業でのマルチモーダル埋め込みの社会実装はまだ始まったばかりです。しかし、研究の進展を見れば、この技術が現場に届くのは時間の問題でしょう。「形」と「言葉」の境界が消えたとき、製造業のデータ活用は新しいステージに入ります。 仲間を募集しています！ キャディ株式会社では、本記事で紹介したマルチモーダル埋め込み技術をはじめ、AIモデル開発に全力で取り組み、ミッション「モノづくり産業のポテンシャルを解放する」の実現を目指しています。 この記事を読んで「自分ならこう解決する」「この技術、面白そう」と感じたエンジニアの方、ぜひご応募お待ちしております！ 詳細は以下の採用ページからご覧いただけます！ Data & Machine Learning / CADDi Tech Careers

みなさんこんにちは！製造業のお客様を中心に技術支援をしているソリューションアーキテクトの吉川と岩根です。まもなく AWS Summit Japan 2026 が開催されます。今年も千葉の幕張メッセで開催いたしますので是非ご参加ください！今年も製造業向けの展示を出展する予定ですので、その内容をご紹介します！各展示ごとのブログも続々投稿する予定です。 AWS Summit とは AWS Summit は、共に未来を描くビルダーが一堂に会して、アマゾン ウェブ サービス (AWS) に関して学習し、ベストプラクティスの共有や情報交換ができる、クラウドでイノベーションを起こすことに興味がある全ての皆様のためのイベントです。日本最大の “AWS を学ぶイベント”、それが AWS Summit です。基調講演、260を超えるAWSセッション・事例セッション・パートナーセッションがあり、 300以上の展示でオフラインならではの体験ができます。開催期間は 6 月 25 日 (木) と 26 日 (金) の 2 日間で会場は幕張メッセです。 本ブログでは数ある展示とセッションの中から製造業に関する展示とセッションをご紹介いたします。まだ登録してない方は以下のリンクから是非ご登録ください。 登録はこちら 製造業に関する展示は Hall 7 の AWS Expo 内にある AWS Industries Zone にあります。 AWS Industries Zone では、製造、金融、自動車など 13 の業界別に特化したソリューションと、Physical AI の特設展示をご覧いただけます。各業界をリードするお客様の AWS 活用事例や、生成 AI をはじめとする最新テクノロジーの実用的なデモを通じて、業界固有の課題解決方法をご覧いただけます。また、業界に精通したエキスパートと具体的な活用シナリオについて、ご相談いただけます。 製造領域では、Smart Manufacturing を中心としたコンセプチュアルな 製造 Highlight 展示 と、お客様事例展示や、 Product Engineering や Smart Product などの最新のデモを含む 製造 Industry 展示 の2つの展示エリアを用意しています。 展示全体像 赤い枠が製造展示のエリア A WS Expo 内の Industries Zone の図。赤い枠が製造業むけ展示。上が Highlight 展示、下が Industry 展示 製造業 Highlight 展示の概要 Highlight 展示では「 AI で加速する製造業のルネッサンス」をテーマとして、製造業の未来を体感できる展示を行います。3つの展示で構成されており、以下のような配置となっています。その他に、エリア内に設置された100インチモニタを使用して、各ブースの説明をライトニングトーク形式で紹介したり、展示の概観が分かるような動画を投影する予定です。 生産ラインの未来 製造業では、需要と供給が絶えず変動する中、生産ラインの最適な稼働が求められています。本展示では、生産ライン全体のシミュレーションによりボトルネックを特定し、生産効率を最大化する仕組みをご紹介します。 技術要素として、以下の3点を取り上げます。 ソフトウェア定義型の生産ライン ― ライン構成をコードで定義し、リポジトリで管理する仕組み デジタルツインによるシミュレーション ― 現場から収集したデータを基に、仮想空間上で生産プロセスを検証・最適化する仕組み AI エージェントによる意思決定支援 ― 生産ラインを含む多様なデータを活用し、データドリブンな判断を実現する仕組み これら3つの要素を組み合わせた生産ラインの将来像を、実機デモを交えてご覧いただきます。 工場のデジタルツインとシミュレーションを活用して AI アシスタントでボトルネックの分析 ソフトウェア定義型ファクトリー これまでハードウェアとして物理的に存在していた PLC を仮想化し、ソフト PLC（仮想 PLC ）として動作させることで、生産ラインの制御ロジックをソフトウェアとして扱えるようになります。本展示では、物理 PLC からソフト PLC への移行を実際にお見せし、その可能性を体感いただきます。 ソフト PLC への移行がもたらす最大の変化は、ライン構成そのものをコードとして定義できるようになることです。これにより、 Git リポジトリを活用したバージョン管理が可能となり、誰が・いつ・どのような変更を加えたのかを完全にトレースできます。 さらに本展示では、エッジデバイスからクラウドまでを一気通貫でつなぐエンドツーエンドの制御アーキテクチャをご紹介します。工場のフロアで動作するエッジコンピューティングと、クラウド上のオーケストレーション層がシームレスに連携することで、生産ラインの柔軟性とスケーラビリティが飛躍的に向上します。 ソフトウェア PLC により制御されるミニチュア工場 サプライチェーン 本展示では、 AI がサプライチェーンの意思決定を変える瞬間を体感いただけます。 需要変動や供給遅延が発生した際に、担当者が AI エージェントに分析を依頼し、在庫枯渇の予測・生産計画への影響・代替調達の選択肢・対応方針案を迅速に導き出す一連の流れを体験いただきます。 AI が在庫や物流の状況をリアルタイムに読み解き、複数の対応策をコスト・リスクとともに提示します。 需要の急変や供給の遅延といった製造現場の日常的な課題に、 AI がどのように応えるのか。今まさに起こっている変化をご覧ください。 市 場の変化に応じて、生産計画に反映できる需要予測を行う AI エージェント 製造業 Industry 展示の概要 Industry 展示では、製造業のお客様の現場で「すぐに使える」テクノロジーを、実機デモを通じて体感いただける展示を多数ご用意しています。 Highlight 展示が「未来の製造業」をテーマにコンセプチュアルに描いたのに対し、 Industry 展示は Product Engineering （製品設計開発）と Smart Product （スマート製品開発・運用）という製造業のものづくりライフサイクルを支える 2 つの軸に加え、エッジ × AWS の選択肢を一望できる AWS 認定デバイスウォール 、そしてお客様自身による事例展示エリアで構成しています。 AWS のソリューションアーキテクトや事例企業の方々と、その場で具体的な活用シナリオをじっくり相談できる、ぐっと現場目線のエリアです。 生成 AI 時代の製品設計開発 CAE 解析や CAD 操作、過去ナレッジの活用など、製品設計開発の現場にはエンジニアの専門性に強く依存する業務が数多く存在します。本展示では、フィジカル AI 時代の到来を見据え、エンジニアの設計開発を加速する 2 つの切り口で実機デモをご覧いただきます。 Engineering and Development HUB（ EDH ）による HPC 基盤の俊敏な立ち上げ ― 大規模シミュレーション、 CAE 解析、 GPU を用いたモデル作成といった、フィジカル AI 時代の研究開発に欠かせない HPC 環境を AWS 上に短時間で構築する仕組みをご紹介します。仮想ワークステーションとスケーラブルな HPC 基盤を Web ポータルから即座に利用でき、自動スケーリングやコスト管理機能も標準で備えているため、エンジニアや研究者は使い慣れたツールに集中できます。 Engineering and Development Hub (EDH) 設計開発の現場ですぐに実践できる生成 AI ユースケース ― 自然言語による CAD/CAE 操作アシスト、過去設計ナレッジの瞬時検索、実験レポートの自動生成など、明日からでも取り入れられる「使える AI 」の活用例をご紹介します。その場でご覧いただける動作デモに加え、後日体験できるワークショップもご用意しているので、 AI が設計業務をどう変えるのかをじっくり実感いただけます。 生成AI x CAD + CAE + NVIDIA Isaac によるPhysical AI シミュレーション 「フィジカル AI 時代の研究開発をどう加速するか」を、現場のエンジニア目線で体感いただける展示です。 AI 駆動のスマート製品開発とサービス運用 スマート製品の世界では、製品そのものだけでなく、ソフトウェア開発から市場投入後の運用改善までを含むエンドツーエンドのライフサイクル全体が競争力の源泉となります。本展示では、ソフトウェア開発と運用改善の両面で AI エージェントが何を変えるのかを、 2 つのデモでお見せします。 AI エージェントが加速するスマート製品のソフトウェア開発 ― ソフトウェア開発 AI エージェント Kiro を活用し、企画から運用までのソフトウェア開発プロセスを AI と協調しながら進める世界をご紹介します。組み込みシステムやライフサイクルの長いソフトウェアを含む開発全体に AI 支援を適用できること、既存の設計文書やコーディングルールをそのまま活かせること、そしてチケットを用いた責任分担により人間と AI が役割を持ち寄って開発を進められることを、実際のデモで体感いただきます。 製品開発プロセスの調査・計画・実装・リリース・運用全て Kiro で開発を支援 AI エージェントが実現するデータ駆動のプロダクト改善サイクル ― Amazon Quick を使い、専門知識がなくても AI によるデータ分析を実現する仕組みをご紹介します。営業・保守・設計開発・品質保証といった部門ごとに分散したデータに加え、気象などの公開データも統合し、問題の発見から原因の特定、対策の立案まで、 AI がパートナーとなってプロダクト改善の意思決定を支援します。 出荷したフィールド上の製品情報からえた知見を分析し原因の究明と対策計画を Amazon Quick が立案し意思決定を支援 「製品を作って終わり」ではなく、「作りながら、運用しながらより良くしていく」これからのスマート製品開発のあり方を、ぜひその目でお確かめください。 AWS 認定デバイスウォール エッジデバイスとクラウドを連携させるニーズはここ数年で急速に高まっており、「どのデバイスを選べばよいのか」「クラウド連携の検証コストをどう下げるか」というご相談を多くいただきます。 AWS 認定デバイスプログラムは、 AWS の IoT サービスとの接続が検証された信頼性の高いデバイスをラインアップしたプログラムです。本展示では、認定済みのエッジデバイスを「ウォール」状にずらりと並べ、ハードウェアパートナー各社との協業によって広がる選択肢を一望していただけます。日本国内におけるエッジ × AWS のサービス構築を加速し、お客様のビジネスを後押しする取り組みを、実機を通じてご紹介します。 壁一面に展示された AWS 認定デバイスのラインアップ。多様なエッジデバイスをまとめて見比べいただけます。写真は AWS Summit Japan 2025より お客様事例展示 Industry 展示エリアには、 AWS をご活用いただいているお客様自身による事例展示エリアも併設しています。今回の製造業エリアでは、製造現場とエンジニアリングの両面から、特徴的な AWS 活用事例をお持ちのお客様 2 社をお迎えします。 オムロン株式会社「生成 AI を活用した知財 AI エージェント『 ALBERT 』の内製開発」 世界中で日々数千件もの特許が出願されるなか、知財業務の現場では「全特許を網羅的に把握しきれない」「技術と知的財産の双方に通じた専門人材の工数が逼迫している」「機密情報を扱うため社外の生成 AI サービスを気軽には使えない」といった課題が積み重なっていました。 本展示では、オムロンが Amazon Bedrock や Amazon OpenSearch Serverless などの AWS サービスを活用して内製開発した、知財 AI エージェント 「 ALBERT 」 の取り組みをご紹介いただきます。研究開発に特化した自社の生成 AI 活用基盤「 RD Buddy 」の上に AI エージェントを実装することで、情報漏洩リスクとコスト課題を抑えつつ、特許情報の検索・分析・要約といった知財業務を高度化・効率化。 特許調査・発明説明書作成の工数を 90% 削減 という成果を生んでいます。今後は R&D 部門での利用拡大（ 60 名 → 120 名）から全社展開まで見据えた、まさに「生成 AI による R&D の DX 」を体現する事例です。 i Smart Technologies 株式会社「 Amazon Bedrock を活用した『 AI 製造部長』」 製造現場では IoT データを集めても「データをどう読み解けばよいか分からない」という壁にぶつかることが少なくありません。 i Smart Technologies は、自社の IoT データ収集サービス iXacs に Amazon Bedrock （ Claude ）を組み込み、 多様な製造設備から集まる時系列データを自然言語で解釈する「 AI 製造部長」 を実装しました。 専門知識のない現場担当者が、異常の兆しやその原因、次に取るべきアクションを自然言語で受け取れるようになり、データ解析にかかる時間を 70% 削減という成果を生んでいます。「トヨタのカイゼン文化 × AI 」を体現するこの取り組みは、 IoT 製品そのものに生成 AI を組み込む「組込み AI 」の先行事例としても注目されています。本展示では、収集したデータを「使えるデータ」に変える AI の力を、 COO の松下様ご自身の言葉でご紹介いただきます。 会期中は、お客様ご自身による解説に加え、その場での Q&A も可能です。実装の裏側や苦労した点、運用してみての気づきなど、現場の生の声を直接お聞きいただける貴重な機会ですので、ぜひ足をお運びください！ 著者紹介 岩根 義忠 (Yoshitada Iwane) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 自動車メーカーの生産技術開発部門を経て AWS Japan に入社し、エンタープライズ事業本部でソリューションアーキテクトとして活動中。前職でソフトウェア開発のアジャイル/スクラムに出逢い、自部門での導入やスケールを主導したことにより、モダンな開発手法やクラウドに目覚める。 趣味はバイクの他にギター演奏、自分の部屋の飾り付けなど。二児の父だが二人とも実家を出ているため、現在は妻と気楽な二人暮らし。栃木県那須塩原市在住。 吉川 晃平 (Kohei Yoshikawa) アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト ソフトウェア開発者およびシステムインテグレーターとして 20 年以上従事した後、2020 年から AWS Japan で活動中。エンタープライズ事業本部で、日本の多くの製造業や SI 事業のお客様の AWS 活用を支援してきた。 スマートプロダクトのためのサービス開発に興味を持ち、最近は AI 開発エージェントを用いた製品開発ライフサイクルの加速に取り組んでおり、お客様との会話のネタが尽きない毎日を送っている。 趣味は週末のサイクリング、冬はスキー。風を切る乗り物がとにかく好き。  

市役所からのお知らせです。 ＿人人人人人人人人人人人人人人人人人人人人人人人人人人＿ ＞　 この記事では IEEE754 偶数丸めを仮定しています！　＜ ￣ＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹＹ￣ 述語によっては丸め方向が大事なものがあるのですが、いちいちお断りするの大変ですからね。世は大省エネ時代です。 こんなみなさまに読んでいただきたい！ ところでみなさま！ 初めて算術回路を学んだときの感動を憶えていらっしゃいますか？ みなさま「足し算なんて私の知っている筆算を回路に落とすだけでしょう、私は天才！人生楽勝！」 みなさま「……高さ (= 回路の最長路長) O(log w) ！？」（w はワード長） ご存知なかった方はこの機会にそちらもチェックしていただきつつ、まずは私の一勝ということでね。 そういえば算術回路についての名著『アルゴリズムイントロダクション』の第2版 第3巻（今手に入るのですかねこれ）に書いてありました。第3版で廃止されたのですが、時代ですね🙃 ともあれこういうのまだまだやりたいではありませんか！ 浮動小数点数 & 計算幾何 𝐼𝑠 𝐴𝑙𝑙 𝑌𝑜𝑢 𝑁𝑒𝑒𝑑（文法ミス）です。やっていきましょう！ Section 1: 適応的精度 (Adaptive Precision) の概要 適応的精度 (Adaptive Precision) は、状況に応じて計算精度を徐々に上げていくことで、最小限のコストで厳密な不等式判定を可能にする手法で、丸め誤差をうまく再利用するのがポイントです。 Adaptive Precision の詳細については Shewchuk (1997) に詳しいです。みなさまもぜひです。 適応的精度（Adaptive Precision）を知ったきっかけ 3D CAD といえば B-Rep (Boundary Representation) です。要はトポロジー（面などの接続関係）と、ジオメトリー（それらの方程式）を別で管理するということですね。 これがまた大変です。決まった形をしていませんから、機械学習がとても大変です。（実はここ最近 B-Rep 向けの機械学習もアツいのですがそれはまた別のお話🖐️） というわけでみんな大好きルールベースになるわけですが、これアルゴリズムをある程度頑健にしておかないとデバッグが難しいのですよね。そのへんでいろいろ調べていたら知ってしまった†深淵†のひとつです。私の右目が疼く前に次のセクションへ GO! です。 適応的精度（Adaptive Precision）の動機は？ 計算幾何あるあるをご紹介しましょう。 たとえば、2 次元の与えられた 3 点 A, B, C の配置がこの順に反時計回り、時計回り、共線（同一直線上）のどれであるかを判定する問題を考えてみましょう。 みなさま「こういうのは行列式を使えばよいのですよね。数学に詳しすぎて照れてしまいますね」 みなさま「あれ、こ〜れ境界値周りの挙動が一貫していなかったらぶっ壊れますでございますわ〜☀️☀️☀️」 共感していただけましたでしょうかね。要は別に微妙な結果がどちらに転ぶのかをすごく気にしている訳ではなくて、大事なのは ズレるのはよいとしてどちらに転ぶかが一貫していなかったら全体がぐちゃぐちゃになってしまう ということです。 反時計回りであるかどうかなど、Yes/No が定まるものを 述語(predicate) といい（例：反時計回りか？円の内側か？など）、これを厳密に判定する手法は 厳密幾何計算 (Exact Geometric Computation, EGC) と呼ばれていて、数値そのものを正確に計算する厳密算術計算 (Exact Arithmetic Computation) とは区別されます。符号などの判定だけを厳密にするので、数値全体を厳密化するより軽いのがポイントです。 せっかくですから、 Kettner, Lutz, et al. (2008) から印象的な図表をいくつか引用しましょう。 印象的な図表 1 まずは反時計回り・時計回り・共線判定がいかに数値的に不安定であるのかを見ていきましょう。 キャプションにある 3 点 A, B, C を、ほんのちょっとだけ動かした点 A', B', C' が、どちら向きに並んでいるかを浮動小数点数演算で判定した結果です。 反時計回りになっている 👉 青色 時計回りになっている 👉 赤色 共線になっている 👉 黄色 ちなみに黒色の細い対角線は、真に共線になるべきところです。え！？！？ もはや絨毯として販売できそうなカオスっぷりです。 印象的な図表 2 次は、反時計回り・時計回り・共線判定が不安定なせいで、いかに派手に幾何アルゴリズムが \ﾄﾞﾝｶﾞﾗｶﾞｯｼｬｰﾝ💥/ するのかを見ていきましょう！ むかしむかしある座標平面に、点 p₁ さんと、点 p₂ さんと、点 p₃ さんと、点 p₄ さんが、この順に反時計回りの凸四角形を構成しながら暮らしていました。 おばあさんが川で洗濯をしていると、大きな桃🍑が流れてきました。 その桃🍑を切ると、なんと点 p₁ のすぐ右に点 p₅ がおぎゃあ、おぎゃあと……… ってこれいつまでやればよいでしょうかね。止めないと私無限に続けますよ！？！？ そんなことより凸性です！ 点 p₅ を追加した結果は (a) の通りです。 点 p₁ と点 p₅ の差が丸め誤差に吸収されて、ちょっと凹んでしまっていまね。ウーンム…… みなさま「こんなん誤差やん。うおｗ」 私「1εを笑うものは1εに泣きますよ。」 ここで (b) の拡大図をご覧ください！ 点 p₆ を追加するとあらふしぎ。前提が壊れているのでぐ〜〜〜〜っちゃぐちゃです。 (c) は細かい実装バリエーションの結果です。わかる人にだけわかるご説明をすると、点 p₆ から「見える」edge は p₄p₅ と p₁p₂ (のみ)で、どちらを先に発見するかで結果が変わるというわけですね。 これでもう「うおｗ」とは言わせませんよ。 いたるところで大活躍する基本的な述語 4 選！ Orient2d みなさまの記憶力は素晴らしいため、問題を憶えていらっしゃいます。 2 次元において、点 c が直線 ab のどちら側にあるかは次の行列式で決まります。 ところでこれ命名の流派たくさんあって毎回ウーンムとなります。厳密計算の分野における古典的な呼び方はおそらく Orient2d, Orientation2d なのですけれども、たとえば nalgebra では perp (perpendicular product の略？) と呼ばれていたり、私はじめ競プロ経験のある方は ccw (counter-clockwise の略）を使うことが多かったり、単に det と書く方もいらっしゃったりなどです。 Orient3d 3 次元バージョンです。萌え萌えでなくて申し訳ないです。 3 次元において、点 d が平面 abc のどちら側にあるかは次の行列式で決まります。 InCircle 2 次元において、点 d が円 abc の内外どちらにあるかは次の行列式で決まります。 InSphere 3 次元において、点 e が球 abcd の内外どちらにあるかは次の行列式で決まります。 これらの主な用途を挙げておきますね。聞いたことのない方には先着で読み上げ音声をプレゼントです。 アルゴリズム 活躍する述語 凸包構築 Orient2d 線分交差判定・線分群の交差列挙 ( Bentley–Ottmann algorithm ) Orient2d ドロネー三角形分割 Orient2d, InCircle ボロノイ図 の構築 ( Fortune’s Algorithm ) InCircle メッシュの refinement ( Delaunay Refinement ) Orient2d, InCircle 3 次元でも基本的には同様の問題があって、対応する述語が活躍することが多いです。 Adaptive Precision のアプローチ お話がそれましたわ。これらの述語をどういうアプローチで「必要なときだけ厳密に」「お爆速に」行うのかをみていきましょうですわ〜〜〜 大事なことは、 近似計算でも結果が 0 から大きく離れていたら信じて OK （= 推定誤差上界より十分大きい）ということです。 ある精度で近似計算を行います。 誤差上界を評価します。 0 から大きく離れている場合 👉 return 結果 0 に近い場合 👉 精度を上げて 1 行目にもどる or どこかの段階で任意精度計算で厳密な判定を行います。 アッ、まだ帰らないでいただいて…… わかります。 みなさま「ハイハイ、どうせ任意精度(= 多倍長)小数でしょ。┐(´д｀)┌」 私「面白いのはここからです！！！（☝ ՞ਊ ՞）☝」 これでうまくいくのは当たり前ではありませんかと、ええ、うんうんそれは彼氏さんが悪いです。 なんと Adaptive Precision の方法は 動的メモリ確保なし・ほとんど条件分岐なし で行うことができます。しかも 精度を上げて再計算するときには前回の計算の途中結果を使いまわすことができます 。その裏にあるのは、丸め誤差をキレイに分類するための、まるで回路図のような洗練されたアルゴリズムです。 たとえば Orient2d は下図のようになります。 アッ、まだ帰らないでいただいて…… 大丈夫です、私もわかりませんでした。 目標まとめ やりたいのはこちらでしたね。 Orient2d, Orient3d, InCircle, InSphere などの述語を厳密に判定したいです。 境界値に近くない場合は計算が早く終わっていただきたいです。 動的メモリ確保なしです。（従って 普通の任意精度小数は使えません！ ） 条件分岐は必要最低限です。（従って 算術計算なんかで場合分けは使えません！ ） 全部は大変ですから、みなさまがご興味を持っていただけそうなところまでご招待したいと思います。 Section 2: 足し算・掛け算の実装 2 つの浮動小数点数の和や差を、どうやって表しましょうか 2 つの浮動小数点数 a, b の和 a + b や積 ab の正確な値は、1 つの浮動小数点数では表現できません。 しかし！ ここで軽率に普通の任意精度小数を使ってしまうと、たとえば 2¹⁰²³ と 2⁻¹⁰²² の和などはと〜〜〜んでもない長さになってしまいますね。長いものがお好きな方以外は悲しくなってしまいます。 そこで、 和による表現 です。a + b や ab を 2 つの浮動小数点数 x, y の和で表してしまいましょう。といっても何でもアリにしてしまうと後で困るので、上手い条件を課します。a + b や ab の場合は実は x が丸めた値、y が丸め誤差に一致するようにするのがツウなのですが、一旦もう少し一般のお話をいたしましょうか。 a + b と等しい expression 任意精度小数の一般的な表現 有限小数 x に対し、それを浮動小数点数 x₁, x₂, ..., xₙ の総和 x = x₁ + x₂ + ⋯ + xₙ で表したものを x の表現 (Expression) と呼ぶことにしましょう。 そしてしばしば次のような条件を課します。 nonoverlapping 表現 x = x₁ + x₂ + ⋯ + xₙ が nonoverlapping であるという用語を定義していきましょう。 まずは準備です。浮動小数点数 a, b が次のいずれかの条件を満たすとき、a と b は nonoverlapping であるといいます: a の最下位ビットが、b の最上位ビットよりも真に大きい b の最下位ビットが、a の最上位ビットよりも真に大きい a = 0 b = 0 表現 x = x₁ + x₂ + ⋯ + xₙ は、そのどの相異なる 2 項も nonoverlapping であるときに nonoverlapping であるといいます。 「ビットの範囲が重なっていない」と言い換えるとわかりやすいかもでしょうかね。 nonoverlapping の概念図 nonadjacent 次は、表現 x = x₁ + x₂ + ⋯ + xₙ が nonadjacent であるという用語を定義していきましょう。 まずは準備です。浮動小数点数 a, b が次のいずれかの条件を満たすとき、a と b は nonadjacent であるといいます a の最下位ビットが、2b の最上位ビットよりも真に大きい b の最下位ビットが、2a の最上位ビットよりも真に大きい a = 0 b = 0 表現 x = x₁ + x₂ + ⋯ + xₙ は、そのどの相異なる 2 項も nonadjacent であるときに nonadjacent であるといいます。 「ビットの範囲の間に 1 bit 以上隙間が空いている」と言い換えるとわかりやすいかもでしょうかね。 nonadjacent の概念図 みなさま「わざわざ隙間を 1 開ける理由はなんですか？」 わかります。浮動小数点数演算 a + b や ab の結果を丸めた値 x と丸め誤差 y の関係を思い出してみましょう。 計算機イプシロン ε を用いて |y| ≤ (x の最上位ビット) · ε / 2 が成り立ちますね？ はい、一つ隙間が空いているため 𝑣𝑖𝑐𝑡𝑜𝑟𝑦 です。逆にこれ以上開けるのを保証するのは不可能です。 誤差をバッチリ管理して算術演算をする方法 記法 浮動小数点数 a, b に対して、a + b, a - b, ab を丸めた値をそれぞれ a ⊕ b, a ⊖ b, a ⊗ b と表します。 浮動小数点数の和 a + b 簡単のため |a| ≥ |b| を仮定しましょう。すると筆算の様子はだいたいこういう感じですね。実際には a, b, x, y のどれか負になったりもしますけれども、そのあたりはご愛嬌です。 x は浮動小数点数演算でそのままGO!です。y は真の値 x の差 (a + b) - x を丁寧に計算すれば良いですね。具体的には y = b - (x - a) と表すと途中どこにも丸め誤差が生じなくて 𝑤𝑖𝑛 です。👇 疑似コード みなさま「え、あの、 |a| ≥ |b| ってつまりそれを保証するために条件分岐が入りますよね？？？」 ウーンム、痛いところを突かれましたね。しかし実は y = (a - (x - (x - a))) + (b - (x - a)) がそれを解決するのですよ。証明は難しくはありませんが場合わけが多いですから、みなさまのご担当ということでよろしくお願いさせていただいてですね。そのかわり明日の給食当番は私にお任せください🖐️ Expression e と浮動小数点数 b の和 結果となる expression は長さが 1 長くなります。この世界では演算をしても項の個数が減らないという地獄みたいな設定ですからね🫠 e = e₁ + e₂ + ⋯ + eₙ が nonadjacent かつ、「一部に 0 があるかもしれないことを除いて絶対値が単調増加」という前提条件を課して、次の回路で計算すると、実はその性質が保たれます。 Expression 同士の和 e + f ドーーン！Go Bold の精神です。 浮動小数点数同士の積 ab これまた賢いですよね。実は入力 a, b をともに上位ビットと下位ビットに分解するとうまくいきます。というかよく考えたらそうでもしないと精度が足りないのは明らかですよね。（p 桁の正整数と q 桁の正整数の積が常に p + q - 1 桁であるという事実に注意です。） それに注意した上で、足し算のとき同様に、丸め誤差が出ないように少しずつ差を計算していく方針です。疑似コードを追っていただいてもわかるかもしれませんし、難しければぜひとも原典をです。 Expression e と浮動小数点数 b の積 次のような回路で計算できて、項の個数は 2 倍になりますね。 とはいえ論文中のどの述語の実装でも掛け算は浮動小数点数同士でしか行っていませんから、今回必要はないみたいですね。 これで一通り回路のパーツが揃いました！ あとは各述語 Orient2d, Orient3d, InCircle, InSphere を実装していくだけです！ ……というのがまあ地獄みたいな作業なのですよね。 あと念の為注意なのですが、出力される expression の項は 0 を含むことがあります。例えば a + b を浮動小数点数で計算しても全く誤差の出ない場合は y = 0 になりますよね。これをハンドルしようと思うと当然場合分けが出てくるため、意図的に放置して、固定演算だけで済むようにしております。賢いですね。 Section 3: 各種幾何述語の adaptive precision 実装（の方針） 目標の下方修正 Orient2d のみを実装しましょう。 えいやだっていやじゃないですか。—— みつを Orient2d の展開 定義を展開しましょう。 これをそのまま回路に起こした結果がこちらです。 アッ、まだ帰らないでいただいて…… いまから理解できますから、たぶん、4 割くらいは。（あの？） 最初の引き算 まずは入力を引き算して、主要項と誤差項にわかれますね。このとき、 主要項はオーダー O(1)を、誤差項はオーダー O(ε) を持つ とみなしましょう。実際には誤差項は主要項のε倍よりもずっと小さいこともありますが、小さい分にはよいのでこのまま形式的に突っ走っていきましょう！ 次の掛け算 さらに図の左半分と右半分それぞれについて {主要項, 誤差項} と {主要項, 誤差項} の 4 種類の掛け算をして、8 つずつ、16 個の項を導出しましょう。これは図の左から順にオーダー O(1), O(ε), O(ε), O(ε²), O(ε), O(ε²), O(ε²), O(ε³) （左半分だけ記述）を持ちます。あとはこれらを全て足し引きしたものが厳密な答えです。 厳密な答え D 実際に Expression の足し引きを行なったものが D です。いかにこれを計算しないかが大事ですね。以降、さまざまな近似をみていきましょう！ 最も粗い近似 A 浮動小数点数でそのまま計算した結果に相当します。 A の誤差範囲 慣れている方ならおかわり🍚いただけると思いますけれども、Orient2d 唯一の危険ポイントは減算 x₅ − x₆ による桁落ちです。そこで |x₅| + |x₆| の定数倍により評価していきましょう。 こちらが温めておいた誤差限界です🍳（料理番組風） |A| がこの値以上でしたら、sign(A) = sign(D) が保証されます。 え、私は証明を追ったのかですって？ さて、次は A と D の中間の精度の値です。 第2の近似: B' これは正直なところ A とほとんど変わらないので、私はあまり存在意義がわからなかったのですが、なにかご存知の方いらしたら教えていただきたいです。 B’ というのは Expression B の浮動小数点数近似です。 みなさま「そんなの B の O(1) 項を取れば良いだけでしょうそんな、またまたぁ〜〜」 わかります。私もそう勘違いしたせいで無限にお時間が溶けました。ここで扱っている expression というのは、主要ビットから貪欲になるべく長くとったものとは限らないということに注意です。ここで躓かなかった方は 𝑌𝑜𝑢 𝑘𝑛𝑜𝑤 𝑡𝑜𝑜 𝑚𝑢𝑐ℎ、バッドエンドです。 実は論文中（Theorem 23）に、主要項を抽出するのに使えるアルゴリズムが記載されています。詳細はさておき、条件分岐が出てきているのはちょっと悲しいところですね。（ちなみにループは今回固定長なので消せます。） 誤差上界をはこちらです。A とあまり変わらなくて悲しいですね。 第3の近似: C O(ε) のオーダーを持つ項を片っ端から集めていることがわかりますね。 誤差限界はこちらです: これでもどうしようもなければ D を計算するということですね。賢いです。 Section 4: 現代の厳密計算 結局私個人が厳密幾何計算を実装する（ハメになる）機会はなかったのですが、では現代ではもう使われていない技術なのでしょうかね。だとしたら、とても寂しいですね。 最後に、この手の厳密述語 (exact predicate) が現代のライブラリでどう扱われているかを軽く見ます。 CGAL にありましたよ！！ こちら、どなたが使っているのですか！？ CGAL (Computational Geometry Algorithms Library) というライブラリがあります。計算幾何のあらゆる叡智の詰まった老舗の C++ ライブラリなのですが、そこを探してみると、 Predefined Kernels というクラス群が見つかります。これは幾何計算をしたり、幾何的オブジェクトを構築したりするときのカーネルです。 命名規則を見ると、exact predicate と exact construction が見えますね。Exact predicate というのは今回ご説明したように、「述語の yes/no を厳密に判定する」ことで、比較的簡単かつあまり大きなコストがかからないと言われています。（簡単ですか？？？？？？） 一方 exact construction は非常に難しいです。というのも predicate のときのように「誤差を評価してフィルタリング」のようなテクは通用せず、すべてを厳密計算する必要があります。そのうえ 複雑な制約条件により与えられる点は長大な有理数や複雑な方程式で表される からです。「構築した点を基準に構築する」とかにも対応しないといけませんからね。 OCCT にはなさそうですね？？？ CAD の超有名 OSS であるところの OCCT (Open Cascade Technology) もチェックです！ 一応探してみましたが、なさそうな気がします。 根拠列挙ターイム！ OCCT は他の CAD カーネル同様、tolerance ベースで管理を行っていますね。 CAD カーネルは点の構築が大前提のソフトですから、exact predicate もうまく活躍できなそうです。 Tolerance によるヒーリングの技術も発達しているので、それで実は実用上困らないのかもしれません。 実際、非常に繊細で複雑な計算である Boolean 演算でも tolerance ベースで計算していることが、 Boolean Operations の Guide を参照するとわかります。 BTW: 機械学習ってなんぼのもんなんですかね さて、ここまで読んでくださったアルゴ系エンジニアのみなさま、機械学習はお好きですか？ みなさま「機械学習がなんぼのもんじゃい✊💥」 みなさま「私たちの憧れたヒューリ🥒スティックプログラミングいずくにかです！」 え、今日日そんなこと思いませんよって、ぐぬぬぅ…… というか私が☝️でしたというだけなのですけれども、最近は変わりました。 機械学習は、やや矮小化かもしれませんけれども「書かなくていい部分が増えただけ」で、古典的手法のエッセンスは残っている気がするのですよね、少なくとも現時点では。 良いヒューリスティックは大抵「天才的な気づき」から始まるものの、その後はつらいモグラ叩きになりがちです。機械学習は、そのモグラ叩きを「最適化問題」として正面から殴れるのが最高に気持ち良いです！ Transformerのような汎用手法が全盛の今でも、何が本質かを見極めてベクトルを練り上げる工程は、極めて domain-specific です。そこには間違いなく、古典の英知が息づいています。 現実世界には「理論上解けるはずなのに、放置されている面白い最適化問題」が山積みです。その山を、古典の英知と最新の技術で一緒に崩しませんか？ そんな仲間を、我々キャディのチームは待っています😉 speakerdeck.com まとめ 何かをするのに遅すぎるということはありません。 おととい 4/11 は私のお誕生日でした。プレゼント🎁を送れなかったよという方、あとはわかりますね。