2026 年 8 月 24 日週に私が最も興味を持ったニュースは、DuckLabs の買収でした。 AWS は、Parquet、CSV、JSON などのファイルに対してインプロセスで実行され、SQL を直接実行する人気のオープンソース分析データベースである DuckDB の背後にあるアムステルダムを拠点とする企業である DuckLabs を買収する最終契約を締結しました 。DuckDB は、独立した基盤と MIT ライセンスの下でオープンソースを維持しており、時間の経過とともに、AWS は日常のクエリの速度と、Amazon S3、Amazon Redshift、Amazon Athena などのエンタープライズ規模のサービスを組み合わせる予定です。 ハネス・ミューライゼンとマーク・ラースベルトが共同設立した DuckDB は、ローカルまたは Amazon S3 上で稼働しています。そのため、現実世界の分析の大部分を占める日常のクエリ (1 テラバイト以下) の処理速度が非常に速くなります。また、AI エージェントとの相性も抜群です。AI エージェントは、人間と同じようにデータを「調べて」実験します。AWS が DuckDB のスピードと Amazon EMR、AWS Glue、Amazon SageMaker などの分析サービスを組み合わせている間、共同創設者は引き続き技術的な方向性をリードしていきます。なぜこれが重要なのかをより大局的に説明するために、バイスプレジデント兼著名なエンジニアであるアンディ・ウォーフィールドが、 ポスト DuckDB と All Things Distributed で変化する分析 の物理現象についての考えを共有しました。 それでは、8 月 31 日週の AWS ニュースを見ていきましょう… 8 月 24 日週のローンチ 8 月 24 日週のローンチのうち、私が注目したリリースをいくつかご紹介します: Amazon ECS は、エージェントとの接続を失ったコンテナインスタンスを自動的に検出して回復するようになりました。Amazon ECS は、エージェントのコントロールプレーンへの接続を継続的に監視し、新しい AGENT_CONNECTIVITY ヘルスイベントを AWS Fargate、Amazon ECS マネージドインスタンス、および EC2 上の Amazon ECS 全体にわたって検出するようになりました。Fargate とマネージドインスタンスでは、ECS が自動的にリカバリ、タスクの排出、代替インスタンスの起動、障害のあるインスタンスの登録解除を行います。EC2 では、イベントを独自のワークフローに接続できます。すべての AWS コマーシャルおよび AWS GovCloud (米国) リージョンで追加料金なしで利用できます。 AWS Lambda では、Node.js 26 と Python 3.15 からパブリックプレビューランタイムが導入されました。今後の Lambda ランタイムが一般公開される前にテストできるようになりました。プレビューランタイムは最終的な GA バージョンと同じ識別子を使用するため、関数はアクションなしで自動的に段階的に終了します。サードパーティのツールやデプロイメントフレームワークでも、GA に先立って互換性を検証できます。まだ本番環境向けではありませんが（重大な変更が可能です）、次のアップグレードに先んじるには最適な方法です。すべての AWS コマーシャル、AWS GovCloud (米国)、および中国リージョンでご利用いただけます。 AWS IoT Core にネイティブ InfluxDB ルールアクションが追加されました — カスタムコードを記述したり、中間サービスをセットアップしたりしなくても、IoT デバイスから InfluxDB (Amazon TimeStream マネージドまたはセルフホスト) に時系列データを直接ルーティングできるようになりました。IoT Core はデータを InfluxDB のラインプロトコルにフォーマットし、デバイス側とサーバー側のバッチ処理をサポートします。Amazon Timestream for InfluxDB が提供されているすべての AWS リージョンで利用できます。 Amazon GameLift Servers に DDoS 保護機能が強化されました — ゲームサーバーは、ネットワークとトランスポートレイヤー (レイヤー 3 と 4) の DDoS 攻撃 (UDP リフレクション、SYN フラッド、および同様のベクトル) から自動的に保護されるようになりました。有効にしたりオプトインしたりする必要はありません。ゲーム用に最適化されたトラフィックシェーピング機能を備えた AWS Shield Standard 上に構築されているため、追加費用なしでサーバーの稼働を開始した瞬間 (Server SDK 5) に起動します。中国 (北京) と中国 (寧夏) を除き、サポートされているすべてのGameLift Serversリージョンで利用できます。 Amazon SageMaker HyperPod が Ray のサポートを拡大する — 組み込みのオブザーバビリティ、レジリエントなトレーニング、高速推論により、SageMaker HyperPod で Ray ワークロードを実行できるようになりました。Amazon SageMaker Studio から Ray クラスターを作成および管理し、JupyterLab またはローカル IDE をアタッチしてマルチノードクラスターがローカル開発環境のように動作するようにし、Grafana ダッシュボードを自動プロビジョニングします。ノードの自動リカバリ、ハングジョブの検出、階層化されたチェックポイントにより、大規模なトレーニングを正常に実行できる一方、Ray Serve は推論用に階層化された KV キャッシュを追加します。既存のオープンソース Ray コードは変更されずに動作します。Amazon EKS によってオーケストレーションされたハイパーポッドクラスターで使用できます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS ニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: 20 歳の誕生日おめでとう、Amazon EC2! — アマゾン EC2 が 20 周年を迎えます。Channy Yun は、EC2 が 1 つのリージョンの単一の m1.small インスタンスタイプから 39 のリージョンにわたって 1,200 を超えるインスタンスタイプに成長した経緯と、最初の Graviton から Graviton5 と Trainium3 へのカスタムシリコンの移行について振り返ります。Amazon ECS、Amazon EKS、AWS Lambda、Amazon SageMaker、Amazon Bedrockなど、今でも AWS の多くを支えているこのサービスについて、楽しくて読む価値があります。 エージェントリソースディスカバリー (ARD): エージェントディスカバリーのオープン仕様 — 組織がエージェント 、ツール、MCP サーバーをスケールアップするにつれて、これらのリソースはクラウド、オンプレミスインフラストラクチャ、SaaS プラットフォームに分散し、それぞれが独自のレジストリとメタデータを持つことになります。ARD は新しいオープン仕様（Apache 2.0）で、エージェントのリソースを記述して発見する一般的な方法を定義しています。そのため、パブリッシャーは「一度説明すると」、コンシューマーは「あらゆる場所で発見する」ことができます。DNS はエージェント向けです。AWS はフィードバックを提供しましたが、この仕様は独自のものではありません。また、移行せずに複数のカタログを統合できるため、AWS Agent Registry が補完されます。 AWS CLI で Agent Toolkit for AWS を使い始めましょう – 単一の AWS CLI コマンド ( aws configure agent-toolkit ) で、Kiro、Claude Code、Codex、Cursor などの AI コーディングエージェントに、厳選された最新の AWS 知識と AWS MCP サーバーを介した何千もの AWS API への安全な接続が可能になりました。AI コーディングアシスタントを使用してビルドすると、適切なサービスを選択し、最新の API を使用し、セキュリティのベストプラクティスに従うのに役立ちます。そのため、初めてでも AWS コードを正しく理解できることが多くなります。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – 開発者が集まってクラウドと AI の最新情報を学び、交流し、探求する無料の対面イベント。開催予定: チューリッヒ (9 月 2 日)、 サンパウロ (9 月 3 日)、 テルアビブ (9 月 10 日)、 ドバイ (9 月 30 日)。直接参加できない場合 セッションは、 グローバルライブストリームとオンデマンドハブ からストリーミングできます。サンパウロサミットでは、生成 AI と Amazon Bedrock に関する2つのセッションを発表します。参加されたら、ぜひご挨拶ください。 AWS Community Days – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。今後のイベントとして、 東京（9月5日）および ポーランドのワルシャワ （9月8日）での「JAWS SONIC 2026」が予定されています。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 8 月 31 日週のニュースは以上です。9 月 7 日週の次回 Weekly Roundup もお楽しみに! – Daniel Abib この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

はじめに この記事は、BASEテックブログ夏のブログリレー10日目の記事です。 こんにちは、Data Strategyチームの竹内です。 BASEでは日々数多くの多種多様な商品が新しく登録されています。それらの商品が「何のカテゴリの商品なのか」を機械学習モデルで自動的に推論する仕組みを、以前からバッチ処理基盤として運用してきました。 今回、そのモデルを 商品テキストと商品画像の両方を入力に取るマルチモーダルなモデル に置き換えたので、その経緯やモデルの中身について紹介します。 はじめに TL;DR なぜ商品カテゴリを推論するのか これまでの取り組みと、画像を使いたくなった理由 使用したモデル 1. 画像を3つのトークンに変える 2. 画像特徴を「BERTのトークン」に翻訳する 3. 1本のTransformerに流し込む 4. 分類と埋め込みの取り出し 結果 埋め込みベクトルの活用 おわりに ※ 記事内のコードはサンプルとして簡略化しています。 TL;DR 商品タイトル・説明文などのテキストと、商品画像の両方を入力とする商品カテゴリ分類モデルを作成しました モデルは MMBT（Supervised Multimodal Bitransformers）をベースに、画像側を Swin Transformer、テキスト側を日本語BERT（ tohoku-nlp/bert-base-japanese-v3 ）に置き換えたものです 学習データは約100万件の商品で、ラベル（498クラスの階層カテゴリ）はLLMによるアノテーションで付与しました なぜ商品カテゴリを推論するのか BASEには毎日さまざまな商品が登録されますが、「その商品がどのカテゴリに属するか」を横断的に把握することは困難です。ショップ側で設定されたショップカテゴリは任意項目であり、また「ショップのカテゴリ」と「そのショップが実際に売っている個々の商品のカテゴリ」は必ずしも一致しません。 そこで、商品ごとにカテゴリを機械学習で推論して付与しています。用途は大きく3つあります。 分析基盤としての提供 … カテゴリごとの流通額・登録数・不正決済の発生状況といった、商品全体像に対する解像度を上げるための分析軸 不正検知モデルの特徴量 … 不正決済の検知や不正な商品登録の検知など、各種モデルの特徴量として利用 プロダクトでの活用 … 推薦や検索など、アプリ側の機能での利用 これまでの取り組みと、画像を使いたくなった理由 商品カテゴリの推論そのものは新しい取り組みではなく、2022年にBERTを使ったモデルとその推論基盤について記事を書いています。 devblog.thebase.in このときのモデルは商品タイトルと説明文を結合したテキストのみを入力とするもので、記事でも画像の利用は今後の課題としていました。 商品によっては、説明が簡素で短いものや、購入者とのやり取りや注意事項のみを記載しているものなど、テキストだけでは何の商品か判断できない商品が一定数あります。一方で、そうした商品でも画像を見れば人間には一目で分かることが多くあります。 逆に、商品の外装やイメージだけのものなど、画像だけでは判断がつかない商品も存在します。テキストと画像は互いに補い合う関係にあり、両方をバランス良く扱えるようにしたい、というのがマルチモーダルモデルを使用する主な動機となります。 あわせて、分類先のカテゴリも見直しています。従来のモデルは100クラス程度の分類モデルであったのに対し、今回は階層構造を持つカテゴリマスタのフルパス（例: グルメ・飲料/スイーツ・お菓子/ケーキ ）を1つのクラスとみなした 498クラスのシングルラベル分類にしています。 使用したモデル マルチモーダルなモデルには様々な選択肢がありますが、今回は MMBT (MultiModal BiTransformer) を採用しました。 github.com アイデアはとてもシンプルで、画像を数個の「単語」のようなトークンに変換して、テキストトークンと一緒に同じ1本のTransformerに流し込むというものです。画像とテキストをそれぞれ別のエンコーダに通して最後にベクトルを結合するのではなく、最初から同じself-attentionの中で混ぜてしまうアプローチになります。 https://arxiv.org/abs/1909.02950 より引用 その際、attention内で個々のトークンがどのモーダルに対応するのかを、Token Type Embedding（セグメント埋め込み）によって区別しています。こちらは従来、テキスト文が質問と回答のどちらに該当するかなどのマーカーとして使用していたものですが、MMBTではそのトークンが属するモーダルによって値を変えたEmbeddingを位置埋め込みなどと同様に、それぞれのトークンに加算しています。 また、本実装では、論文のオリジナル実装から次の2点を置き換えています。 画像エンコーダ: ResNet → Swin Transformer ( swin_base_patch4_window7_224.ms_in22k ) テキストエンコーダ: 英語BERT → 日本語BERT ( tohoku-nlp/bert-base-japanese-v3 ) 実装は責務ごとに4つのクラスを積み上げる形になっています。以下、内側から順に見ていきます。 1. 画像を3つのトークンに変える ImageEncoder は、224×224 の画像を Swin Transformer に通して 7×7 の特徴マップにし、それを3つの領域に平均プーリングして3本の特徴ベクトル（各1024次元）に要約します。この3本が「画像トークンの素」になります。 class ImageEncoder (nn.Module): def __init__ (self, num_image_embeddings: int = 3 ): super ().__init__() model = timm.create_model( "swin_base_patch4_window7_224.ms_in22k" , pretrained= True , num_classes= 0 , ) # avg poolingと最後のlinear層を除外 modules = list (model.children())[:- 2 ] self.model = nn.Sequential(*modules) self.pool = nn.AdaptiveAvgPool2d((num_image_embeddings, 1 )) def forward (self, x): out = self.model(x) out = out.permute( 0 , 3 , 1 , 2 ).contiguous() out = self.pool(out) out = torch.flatten(out, start_dim= 2 ) return out.transpose( 1 , 2 ).contiguous() 画像を何トークンに要約するかはハイパーパラメータで、ここでは3としています。トークン数を増やすほど画像の情報は細かく残せますが、そのぶんテキストに使えるトークン列が短くなります。 2. 画像特徴を「BERTのトークン」に翻訳する BERTのテキストトークンの埋め込みは、実際には 単語埋め込み + 位置埋め込み + セグメント埋め込み の足し算でできています。画像トークンもまったく同じ作り方にすることで、BERTは画像をテキストトークンと同様に扱うことができます。 ImageBertEmbeddings では、 Swin の出力（1024次元）を nn.Linear(1024, 768) でBERTの隠れ次元に射影し 位置埋め込みはテキスト側と同じものを共有し 画像かテキストかを区別するセグメント埋め込み （ nn.Embedding(2, 768) ）を新たに定義して加算する という処理を行います。BERTの実装によってはそのまま使える token_type_embeddings が無いケースがあるため、こちらで定義しています。 さらに先頭に [CLS] 、末尾に [SEP] の単語埋め込みを足すので、画像トークンの個数が3の場合、常に 固定長5トークン の並びになります。 [CLS] 画像1 画像2 画像3 [SEP] テキスト1 テキスト2 ... テキストN [PAD] ... |___________________________| |_________________________________________| 画像トークン（固定5個） テキストトークン（可変長） テキスト側は日本語BERTのtokenizerでトークン化し、最大長は 512 - 画像トークン数 に切り詰めます。 3. 1本のTransformerに流し込む MultimodalBertEncoder は、画像トークン列とテキストトークン列を横に連結して1本のシーケンスにし、BERTのエンコーダに通します。 このとき attention mask は、 画像部分は常に1 （必ず全部見る）、テキスト部分は実トークンだけ1・パディングは0、という形で作っています。 attention_mask = torch.cat( [torch.ones(bsz, self.num_image_embeds + 2 ).long(), attention_mask], dim= 1 , ) extended_attention_mask = attention_mask.unsqueeze( 1 ).unsqueeze( 2 ) extended_attention_mask = extended_attention_mask.to(dtype= next (self.parameters()).dtype) # 1の部分は0に、0の部分は-10000.0に変換する extended_attention_mask = ( 1.0 - extended_attention_mask) * - 10000.0 あとは通常のBERTと同じで、全トークンが互いに attention を張り合い、最後に pooler が全体を768次元のベクトルに要約します。 4. 分類と埋め込みの取り出し 最後の MultimodalBertClf は、pooler の出力（768次元）を nn.Linear(768, クラス数) に通してカテゴリのスコアを出すだけの薄いクラスです。 class MultimodalBertClf (nn.Module): def __init__ (self, n_classes, model, vocab, hidden_size: int = 768 ): super ().__init__() self.enc = MultimodalBertEncoder(model=model, vocab=vocab) self.clf = nn.Linear(hidden_size, n_classes) def forward (self, txt, mask, segment, img): return self.clf(self.enc(txt, mask, segment, img)) def embeddings (self, txt, mask, segment, img): # 分類前の特徴量を返す return self.enc(txt, mask, segment, img) この768次元ベクトルは「商品テキストと商品画像の両方を要約したベクトル」なので、カテゴリ分類以外の下流タスクにも転用できます。推論時にはカテゴリと一緒にこの埋め込みも保存しています。 結果 学習はGeForce RTX 5090を積んだオンプレサーバーで数日程度行い、検証データ全体でのaccuracyは90%でした。推論バッチの作成後、新規登録された商品を対象に定性的な検証も実施したところ、498クラスのうち比較的少数のクラスに関しても、ある程度正確に推論できていました。 また、従来のテキストのみによる分類では判別が難しかった商品についても、適切に分類できていることが確認できました。 埋め込みベクトルの活用 先述の通り、このモデルからはカテゴリだけでなく、分類器手前の768次元の埋め込みベクトルも取り出せます。これは「テキストと画像の両方を踏まえた商品の表現」なので、カテゴリという498個の枠に丸める前の、より細かい情報を持っています。 手元で近傍探索を試すと、同じカテゴリの中でも見た目や商品の雰囲気が近いものが上位に並ぶことが確認できました。この埋め込みは、商品の推薦や検索、あるいは他の機械学習モデルの特徴量としての活用を想定しています。 おわりに 今回は、テキストと画像の双方を扱うマルチモーダルモデルによる商品カテゴリ分類の取り組みを紹介しました。 今回利用したMMBTは、それぞれのモーダルのエンコーダをある程度自由に選択できる点、クラス分類に特化しており実装がシンプルな点が魅力です。また、少し工夫を加えれば複数の画像への対応や画像以外のモーダルの利用もできそうであり、今後も活用の幅を広げられたらと思っています。 最後に、BASEでは様々な職種で一緒にプロダクトを作り上げていくメンバーを募集しています。 興味のある方は、ぜひお気軽に採用情報をご確認ください！ binc.jp 明日はoliverさんによる「顧客中心主義を開発の意思決定に組み込むために実践したこと」に関する記事です！

Logstash の転送先や Python 等のアプリケーションから指定する Elasticsearch の接続先 URL（endpoint URL）は、運用形態（Self-Managed、Elastic Cloud Hosted、Elastic Cloud Serverless）ごとに取得方法や基本形式が異なります。 この記事では、それぞれの運用形態における接続先 URL の取得・確認手順をまとめて解説します。 目次 Self-Managed の場合 URLの基本形式 取得・確認手順 Elastic Cloud Hosted の場合 URLの基本形式 取得手順 Elastic Cloud Serverless の場合 URLの基本形式 取得手順 Self-Managed の場合 オンプレミスや VM（AWS EC2 など）、Docker 等の独自環境で構築した Elasticsearch へ接続する場合は、サーバーの IP アドレス（またはホスト名）とポート番号を組み合わせて接続先を指定します。 URLの基本形式 https://<ホスト名またはIPアドレス>:9200 （※ Elasticsearch 8.0 以降はデフォルトで TLS/HTTPS が有効です。セキュリティの観点から HTTP 接続は推奨されません。） 取得・確認手順 Elasticsearch が稼働しているサーバーの IP アドレスまたは FQDN（ドメイン名）を確認します（ローカル開発環境の場合は  localhost  や  127.0.0.1 ）。 設定ファイル（ elasticsearch.yml ）内の  network.host  および  http.port （標準は  9200 ）を確認し、接続可能ポートとして開放されているか確認します。 Elastic Cloud Hosted の場合 Elastic Cloud Hosted の場合は、管理コンソール画面からエンドポイント URL を直接取得できます。 URLの基本形式 https://**.<region>.<cloud-provider>.**.io:443 （ ※ ポート番号は構成により、443や  9243  などが利用されます。） 取得手順 Elastic Cloud コンソール  にログインします。 接続したい  Deployment（デプロイメント）  を選択します。 左のメニューの  Getting started  アイコンをクリックします。 Get started with Elasticsearch. 画面の Elasticsearch endpoint: の右下にあるコピーアイコンをクリックします。 ※別ルートとして、Kibana 画面右上のヘルプアイコン（ ? ）＞  Connection details  からコピーすることも可能です。 Elastic Cloud Serverless の場合 Elastic Cloud Serverless を使用している場合も、プロジェクトごとに固有のエンドポイントが割り当てられます。 URLの基本形式 https://<project-id>.es.<region>.<cloud-provider>.elastic.cloud:443 （※標準ポート:443） 取得手順 Elastic Cloud コンソールから対象の  Serverless Project  にアクセスします。 Home 画面が表示されていることを確認します（表示されていない場合、左メニューの Home アイコンをクリックします）。 3. Home 画面の右上の Elasticsearch: の接続先URL の横にあるコピーアイコンをクリックします。 ※別ルートとして、Kibana 画面右上のヘルプアイコン（ ? ）＞  Connection details  からコピーすることも可能です。 運用形態によってポート番号（ 9200 ,  9243 ,  443 ）やプロトコル（HTTP / HTTPS）の設定ルールが微妙に異なるため、Logstash やアプリケーションのクライアント設定（ hosts  プロパティなど）に記述する際は指定する形式に注意してください。 The post Elasticsearch の 3形態ごとの接続先URLの取得方法をまとめてみた。 first appeared on Elastic Portal .