アマゾン ウェブ サービス ジャパンのソリューションアーキテクト、齋藤です。 NHN テコラス様が主催する 「はじめてでも大丈夫 – 今からでも遅くない、Claude Code による開発体験ワークショップ」 に、AWS のソリューションアーキテクトが登壇しました。本イベントは定員に達し満員御礼での開催となりました。ご参加いただいた皆様、ありがとうございました！ 本イベントは、「AI コーディングツールは気になっているけど、まだ触ったことがない」というエンジニアの方を対象に、Claude Code を使った Agentic Coding を実際に体験いただくオフライン形式のワークショップです。 Claude Code 入門 & ハンズオン ～ Agentic Coding を一緒に体験しよう～ AWS ソリューションアーキテクト 山澤による座学セッション 座学パートでは、Agentic Coding の概要に加え、 CLAUDE.md による設定、Plan Mode を使った計画的な実装、コンテキスト管理、MCP（Model Context Protocol）といった Claude Code を使いこなすためのポイントを解説しました。 ハンズオンに取り組む参加者の様子 ハンズオンでは、 手を動かして学ぶ Claude Code 入門ワークショップ のモジュール 1 を、AWS ソリューションアーキテクトの齋藤がファシリテーターとして進行しました。オープンソースのホワイトボーディングツール Excalidraw を題材に、本物のコードベースへ Claude Code で機能追加を行う体験をしていただきました。 AWS ソリューションアーキテクト 齋藤によるハンズオンセッション 参加者は AWS 上にデプロイされた Code Editor サーバーにブラウザからアクセスするだけで、ローカル PC に何もインストールすることなく Claude Code を体験できる環境を用意しました。Claude Code は Amazon Bedrock 経由で Claude モデルを呼び出す構成です。モジュール 1 では、以下の内容を体験しました。 Claude Code の基本操作（プロンプトの書き方、ファイル操作） CLAUDE.md の作成と活用 Plan Mode を使った計画的な実装 Excalidraw への機能追加 Playwright MCP を使った視覚的な動作確認 Claude Code を AWS で始めるには ～ Amazon Bedrock 連携から組織導入まで～ NHN テコラス株式会社 AWS Ambassador 福永 悠斗 氏 2 つ目のセッションでは、NHN テコラスの福永氏より、Claude Code を AWS 環境で動かすための 2 つの選択肢を解説いただきました。 Amazon Bedrock API 連携 — セットアップ手順や必要な IAM 権限の設定方法 AWS Marketplace Enterprise Plan — 請求の一元化や管理面でのメリットなど、組織導入を見据えた選択肢 企業で Claude Code を導入する際の具体的なステップが示され、「明日から自社でも始められそう」という声が聞かれました。 参加者の声 「自然言語でコードを改修できることを体感できた」「サポートが手厚く安心して取り組めた」といった声が多く、初めて AI コーディングツールに触れる方にとって実践的な学びの場になったほか、「第二弾・第三弾も開催してほしい」というリクエストや「これから利用・提案予定」という回答も多く、本イベントが Claude Code の導入検討を後押しする機会になりました。 おわりに 本イベントでは、Claude Code on Amazon Bedrock を活用した実践的な開発体験を提供しました。AI コーディングツールの第一歩を踏み出すきっかけとなれば幸いです。 今回使用したワークショップコンテンツは公開されています。ご自身の AWS アカウントにデプロイして取り組むこともできますので、ぜひお試しください。 ワークショップ: 手を動かして学ぶ Claude Code 入門ワークショップ 解説ブログ: 手を動かして学ぶ Claude Code 入門ワークショップを公開しました〜！ AWS では今後もパートナー企業様と連携し、最新の AI 開発ツールを体験いただけるイベントを企画してまいります。 著者について 齋藤 拓巳 ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。AWS Lambda や Amazon API Gateway などのサーバレスのサービスが好きです。 森 瞭輔 ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。好きな AWS サービスは Amazon Connect で、業界問わずコンタクトセンター関連の技術支援も行っています。先日念願だったフルマラソン完走を達成することができました。 登壇者について 山澤 良介 ソリューションアーキテクトとして、業種業態を問わず様々なお客様を支援させて頂いています。前職では主にネットワーク案件を担当していました。好きなサービスは、Amazon Bedrock と AWS Transit Gateway です。休日はスノーボードが大好きなので、シーズン中は毎週スキー場に行っております。 福永 悠斗 NHN テコラスにてデータ・AI 活用を中心にお客様のクラウド活用支援に従事。2025 年には、AWS がグローバルで選出する表彰プログラムである AWS Ambassador に認定。AWS 普及・啓発活動を精力的に推進している。

はじめに 前回の記事 では、Webアプリで映像を扱う際の産業用途におけるリアルタイムコミュニケーション実現のための検討ポイントと、intdashとintdash-RTC SDKという選択肢を紹介しました。 要点をおさらいすると: SFU選定時はベンダー固有の実装に依存する点も考慮が必要 センサーデータとの統合や録画・解析は追加の設計が必要になる可能性 intdashは、産業用途に適したもう一つの選択肢 前編では概要しか触れなかったため、実際の使用感について興味をお持ちいただいた方もいらっしゃると思います。 本記事では、intdash-RTC SDKの具体的な実装方法をサンプルコード付きで解説します。環境が準備できていれば、約30分で動作するビデオチャットが完成しますので、ぜひお試しください。 ライブラリの概要 intdashは映像・音声・センサーデータを統合して伝送できるプラットフォームです。intdash-RTC SDKは、intdashで扱うデータのうち映像・音声をWebアプリから簡単に扱えるようにするライブラリです。 本ライブラリは3つのインターフェースで構成されています。 ┌─────────────────────────────────────────────┐ │ MediaConnection │ 統合管理 ├─────────────────────┬───────────────────────┤ │ MediaSender │ MediaReceiver │ 送受信 └─────────────────────┴───────────────────────┘ | ^ v | ┌─────────────────────────────────────────────┐ │ intdash (iSCP) │ 伝送 └─────────────────────────────────────────────┘ MediaConnection: 送受信を統合管理。 start() / stop() で接続制御 MediaSender: ローカルメディアをintdashに送信 MediaReceiver: intdashからメディアを受信し、video要素に直接接続 本ライブラリは、TypeScript 向けのintdash通信ライブラリ iscp-ts のラッパーとしても利用できますし、今回のようなアプリケーションでは接続設定を直接指定するシンプルな使い方も可能です。 実装ステップ 以下では、基本的なビデオチャットを実装するサンプルコードを5つのステップに分けて紹介します。全量は記事末尾の「Appendix: サンプルコード全文」に再掲しています。 1. ライブラリのimportとMediaConnectionの作成 // 1. ライブラリのimport import { createMediaConnection } from "@aptpod/intdash-rtc" ; // 2. MediaConnectionの作成（intdashへの接続も内部で行います） const { mediaConnection } = await createMediaConnection( { address : "your-intdash.example.jp" , // intdash接続アドレス projectUuid : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" , // intdashプロジェクトのUUID nodeId : "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy" , // 送信元（自分側）のノードUUID enableTLS : true , apiToken : "your_token_here" , // intdash Web Consoleから作成したAPIトークン（OAuth2サインインを使う場合はapiTokenを省略） } , { sender : { // 音声に関する設定 audio : { codec : "PCM" , // PCM, OPUS, AACをサポート } , // 映像に関する設定 video : { codec : "H264" , // H264, VP9をサポート } , } , receiver : { sourceNodeIds : [ "zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz" ] , // 通信相手のノードUUID } , } , ); @aptpod/intdash-rtc が今回のintdash-RTC SDKです。これをimportするだけで、intdashを介したビデオチャットが実装できます（ @aptpod/iscp-ts は peer dependency として併せてインストールが必要です）。 createMediaConnection 関数で、intdashへの接続とMediaConnectionの作成をまとめて行います。第1引数で接続情報（アドレス・プロジェクトUUID・ノードUUID・APIトークン）を、第2引数で送受信オプションを指定します。これらの値は intdash Web Console から取得できます。APIトークンは長期間有効な固定トークンですが、より安全なワンタイムトークンやOAuth2による認証も利用可能です。送受信オプションは階層化された構造になっており、 sender.audio で音声設定、 sender.video で映像設定、 receiver で受信対象ノードを指定します。コーデックは型安全な文字列リテラル型で指定でき、設定ミスを防ぎます。 2. ローカルメディアの取得と表示 // 3. ローカルメディアストリームの取得と設定 const localStream = await navigator .mediaDevices. getUserMedia ( { video : true , audio : true , } ); await mediaConnection.sender.setLocalMediaStream(localStream); // ローカル映像をvideo要素に表示 const localVideoEl = document . getElementById ( "local-video" ) as HTMLVideoElement ; localVideoEl.srcObject = new MediaStream (localStream.getVideoTracks()); localVideoEl.muted = true ; await localVideoEl.play(); getUserMedia でカメラとマイクからストリームを取得し、 setLocalMediaStream で設定します。取得したストリームはそのままローカルのvideo要素にも表示できます。 3. 受信メディアのvideo要素への接続 // 4. 受信メディアストリームの処理 const remoteVideoEl = document . getElementById ( "remote-video" , ) as HTMLVideoElement ; mediaConnection.receiver.on( "statechange" , ( state ) => { if (state === "running" ) { // 受信が開始されたら、video要素に直接接続 mediaConnection.receiver.attach(remoteVideoEl); } else if (state === "stopped" || state === "failed" ) { // 受信が停止したら、video要素から切断 mediaConnection.receiver.detach(remoteVideoEl); } } ); 受信側の状態変化は statechange イベントで監視します。 running になったら attach() でvideo要素に直接接続できます。内部の変換処理（デコード等）はintdash-RTC SDKが処理するため、意識する必要がありません。 4. 接続開始 // 5. 接続開始（running状態まで待機） await mediaConnection.start( { waitUntil : "running" } ); console . log ( "接続が確立しました" ); start({ waitUntil: 'running' }) で接続を開始し、 running 状態になるまで待機します。これにより、接続が完全に確立してから次の処理に進めます。 5. UI操作と停止処理 // 6. UI操作（映像・音声の有効/無効切り替え） document . getElementById ( "toggle-video" )?. addEventListener ( "click" , async () => { const enabled = await mediaConnection.sender.setVideoEnabled( !mediaConnection.sender.videoEnabled, ); console .log( `映像: ${ enabled ? "有効" : "無効" } ` ); } ); document . getElementById ( "toggle-audio" )?. addEventListener ( "click" , async () => { const enabled = await mediaConnection.sender.setAudioEnabled( !mediaConnection.sender.audioEnabled, ); console .log( `音声: ${ enabled ? "有効" : "無効" } ` ); } ); // 7. 停止処理（クリーンアップ） document . getElementById ( "stop" )?. addEventListener ( "click" , async () => { await mediaConnection. stop (); await mediaConnection.iscpConn. close (); localStream.getTracks(). forEach (( track ) => track. stop ()); console .log( "接続を終了しました" ); } ); setVideoEnabled / setAudioEnabled で映像・音声を個別に制御できます。終了時は stop() でメディア処理を停止し、 iscpConn.close() でintdash接続もクローズします。内部のワークレットやバッファも自動的にクリーンアップされます。 実際の動作の確認 このように、WebRTCと遜色ない簡潔さで、intdashを使った映像・音声通信を実装できます。 実際にサンプルアプリを動作させた様子が以下の動画です。 youtu.be 画面の左側がサンプルアプリ「Easy Video Chat」、右側がintdashに付属する簡易可視化ツール「Edge Finder」です。 サンプルアプリ「Easy Video Chat」には「あなた」（左）と「相手」（右）の2つの映像表示があります。今回のデモでは送信元と受信元のノードを同一に設定しているため、左右に同じ映像が表示されています。左の「あなた」は getUserMedia で取得したローカル映像をそのまま表示したもの、右の「相手」はそのローカルメディアをintdashへ送信したあと再度受信してデコード・表示したものです。 実際に二者間で通話する場合は、相手側でも同様にintdashへの接続と受信元ノードの指定を行うことで、双方向での映像・音声通話が成立します。 同時にEdge Finder側では、送信されたH.264映像フレームとPCM音声データが、それぞれ時系列のデータポイントとしてintdashに記録されていく様子が確認できます。 さらなる拡張性 データの可視化とダッシュボードのカスタマイズ 動画で紹介した「Edge Finder」はintdashに標準で付属しており、送受信されているデータをすぐに確認できる簡易ツールです。 より高度な可視化やダッシュボードのカスタマイズが必要な場合は、弊社の可視化アプリケーション「VM2M Data Visualizer」をご利用いただけます。ノーコードで時系列データのダッシュボードを構築でき、映像とセンサーデータを時刻同期させた再生や、多彩なウィジェットを組み合わせた解析画面の作成に対応しています。 VM2M Data Visualizer: 複数の映像と時系列データを時刻同期して再生するタイムラインビュー VM2M Data Visualizer: ゲージ・グラフ・レーダーチャートなど多彩なウィジェットを組み合わせたカスタムダッシュボード Appendix: サンプルコード全文 ここまでステップごとに分割して紹介してきたサンプルコードの全量を、以下に再掲します。 // 1. ライブラリのimport import { createMediaConnection } from "@aptpod/intdash-rtc" ; // 2. MediaConnectionの作成（intdashへの接続も内部で行います） const { mediaConnection } = await createMediaConnection( { address : "your-intdash.example.jp" , // intdash接続アドレス projectUuid : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" , // intdashプロジェクトのUUID nodeId : "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy" , // 送信元（自分側）のノードUUID enableTLS : true , apiToken : "your_token_here" , // intdash Web Consoleから作成したAPIトークン（OAuth2サインインを使う場合はapiTokenを省略） } , { sender : { // 音声に関する設定 audio : { codec : "PCM" , // PCM, OPUS, AACをサポート } , // 映像に関する設定 video : { codec : "H264" , // H264, VP9をサポート } , } , receiver : { sourceNodeIds : [ "zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz" ] , // 通信相手のノードUUID } , } , ); // 3. ローカルメディアストリームの取得と設定 const localStream = await navigator .mediaDevices. getUserMedia ( { video : true , audio : true , } ); await mediaConnection.sender.setLocalMediaStream(localStream); // ローカル映像をvideo要素に表示 const localVideoEl = document . getElementById ( "local-video" ) as HTMLVideoElement ; localVideoEl.srcObject = new MediaStream (localStream.getVideoTracks()); localVideoEl.muted = true ; await localVideoEl.play(); // 4. 受信メディアストリームの処理 const remoteVideoEl = document . getElementById ( "remote-video" , ) as HTMLVideoElement ; mediaConnection.receiver.on( "statechange" , ( state ) => { if (state === "running" ) { // 受信が開始されたら、video要素に直接接続 mediaConnection.receiver.attach(remoteVideoEl); } else if (state === "stopped" || state === "failed" ) { // 受信が停止したら、video要素から切断 mediaConnection.receiver.detach(remoteVideoEl); } } ); // 5. 接続開始（running状態まで待機） await mediaConnection.start( { waitUntil : "running" } ); console . log ( "接続が確立しました" ); // 6. UI操作（映像・音声の有効/無効切り替え） document . getElementById ( "toggle-video" )?. addEventListener ( "click" , async () => { const enabled = await mediaConnection.sender.setVideoEnabled( !mediaConnection.sender.videoEnabled, ); console .log( `映像: ${ enabled ? "有効" : "無効" } ` ); } ); document . getElementById ( "toggle-audio" )?. addEventListener ( "click" , async () => { const enabled = await mediaConnection.sender.setAudioEnabled( !mediaConnection.sender.audioEnabled, ); console .log( `音声: ${ enabled ? "有効" : "無効" } ` ); } ); // 7. 停止処理（クリーンアップ） document . getElementById ( "stop" )?. addEventListener ( "click" , async () => { await mediaConnection. stop (); await mediaConnection.iscpConn. close (); localStream.getTracks(). forEach (( track ) => track. stop ()); console .log( "接続を終了しました" ); } ); おわりに 本記事では、intdash-RTC SDKを使ったビデオチャットの実装方法を見てきました。 ポイントのまとめ: WebRTCと同等の簡潔さで、intdash経由のビデオチャットを実装可能 最初はビデオチャットから始めて、将来はセンサーデータを含むマルチモーダルシステムへ拡張できるのがintdashの強みです。同じプラットフォーム、同じSDKで対応できるため、技術選定で後悔するリスクを減らせます。 「試してみたい」「もう少し詳しく知りたい」という方は、ぜひお気軽に お問い合わせ ください。本ライブラリは現在お問い合わせベースでの個別提供となっています。

本記事は 2026 年 5 月 28 日 に公開された「 The next generation of Amazon OpenSearch Serverless: Built from the ground up for agents 」を翻訳したものです。 対象読者向けの注記: 本記事は技術的な詳細を掘り下げたローンチ記事です。変更点とその理由を簡潔にまとめた概要は、関連する AWS News Blog の記事をご覧ください。 本日、Amazon OpenSearch Serverless のアーキテクチャをゼロから刷新したことを発表します。新しいアーキテクチャでは、オートスケーリングが従来比で最大 20 倍に高速化し、コンピューティングをゼロまでスケールできるようになりました。ピーク負荷に合わせてクラスターをプロビジョニングする場合と比べてコストは最大 60% 削減できます。Amazon OpenSearch Service は、ベクトル、レキシカル、ハイブリッド、エージェント検索を統合したフルマネージドのオープンソース検索エンジンで、低レイテンシーかつ正確で関連性の高い結果を提供します。Amazon OpenSearch Serverless は、その自動スケーリング型のデプロイオプションです。 最近のワークロードはますます動的で予測しにくくなっています。E コマースプラットフォームでは、フラッシュセール時にトラフィックが 10 倍に急増します。人工知能 (AI) エージェントは、複数ステップのタスクを推論する過程で数百もの同時ベクトルクエリをトリガーし、その後アイドル状態になります。マルチテナント SaaS アプリケーションでは、活動パターンが大きく異なる数十のテナントを処理します。こうしたワークロードには、需要に合わせてスケールアップし、需要が下がればリソースを解放できるインフラが必要です。 そこで、 Amazon OpenSearch Serverless のアーキテクチャをゼロから再構築しました。新しいアーキテクチャでは、コンピューティングとストレージを分離しています。インフラのプロビジョニングは分単位ではなく秒単位で完了し、アプリケーションがアイドル状態のときにはコンピューティングをゼロまでスケールダウンします。本記事では、新しいアーキテクチャの内容、アプリケーションへの影響、ハンズオンチュートリアルでの使い始め方を解説します。 新しいローンチに伴い、Amazon OpenSearch Serverless では 2 つのアーキテクチャに名前が付きました。既存のコレクションは Classic コレクションと呼びます。新しいアーキテクチャは NextGen と呼び、AWS コンソールから新しいコレクションを作成するときのデフォルトになります。API で NextGen アーキテクチャを使用するには、CLI で --generation NEXTGEN を指定します。Classic アーキテクチャを引き続き使用する場合は、CLI で --generation CLASSIC を指定するか、オプションの --generation パラメータを省略します。 アプリケーションへの影響 新しいアーキテクチャは、パフォーマンス、コスト、シンプルなユーザー体験という 3 つの柱で改善をもたらします。 パフォーマンス: 秒単位のオートスケーリング OpenSearch Compute Unit (OCU) は、インデックス作成と検索のワークロードを支えるコンピューティング容量の単位です。Amazon OpenSearch Serverless は、追加の OCU を秒単位でプロビジョニングできるようになりました。トラフィックが到着したときには、ワーカーがすでに高負荷に陥ってから対応するのではなく、需要に合わせて事前にリソースを追加します。同じ仕組みで、トラフィックが下がるとインフラを素早くスケールダウンします。新しいアーキテクチャは、容量のスケール速度が以前のアーキテクチャの 最大 20 倍 に達するため、トラフィックの急増時にも一貫したパフォーマンスをユーザーに提供でき、容量が不要になれば支払いも止まります。 コスト効率: 使った分だけ支払う インデックス作成、検索、ストレージ、ベクトルインデックスの GPU アクセラレーションは、それぞれ独立して計測・課金されるため、ワークロードの各次元を個別に把握し、最適化できます。 コンピューティングとストレージの分離: OpenSearch Serverless ではコンピューティングとストレージが完全に分離されており、コレクションに保存されているデータ量とは無関係に OCU をスケールアップ・スケールダウンできます。これは、インデックス作成 OCU と検索 OCU の両方からアクセスできる新しいストレージ層によって実現されています。複数のインデックスにデータを格納していても、データのインデックス作成や検索を実際に行っていなければ、コンピューティングコストは発生しません。アイドル時間が長いワークロードでは、ピーク容量に合わせて OpenSearch Service ドメインをプロビジョニングする場合と比べて、新しいアーキテクチャによりインフラコストを最大 60% 削減できます。 ゼロまでのスケール: アイドルタイムアウト期間 (10 分) の間にリクエストが到着しないと、サービスはコンピューティングリソースを解放し、OCU の使用量はゼロまでスケールダウンします。トラフィックが再開すると、約 10 秒で容量が復活します。スケールダウン中も、サービスは到着したリクエストをキューに入れ、容量が利用可能になり次第処理するため、リクエストを破棄することはありません。スケジュールされたバッチジョブやマーケティングキャンペーンの前など、トラフィックの急増が予想される場合は、本番トラフィックを送信する前に軽量なクエリ (例: size=1 の match_all ) を送信してコレクションをウォームアップしておけます。これにより、最初の実リクエストでユーザーが体感するレイテンシーを抑えられます。インデックス作成と検索は独立してスケールします。検索リクエストがなければ、検索 OCU はゼロまでスケールしますが、インデックス作成リクエストがあれば OpenSearch Serverless はインデックス作成 OCU を維持します。逆向きでも同じです。 ベクトルワークロード向けの GPU アクセラレーション: 新しいアーキテクチャで作成したベクトルコレクションでは、OpenSearch Serverless が GPU バックエンドのコンピューティングを自動的に使用して、Hierarchical Navigable Small World (HNSW) ベクトルインデックスの構築を加速し、CPU のみで構築する場合と比べてインデックス作成時間を大幅に短縮します。GPU アクセラレーションは、全体のインデックス作成時間とコストを削減できる機会があれば自動的に有効になります。Classic アーキテクチャでは、API を介してコレクションレベルで GPU アクセラレーションのオプトイン・オプトアウトが必要でした。NextGen コレクションで特定のインデックスの GPU アクセラレーションを無効にしたい場合は、 インデックスレベルでリモートインデックスビルド設定をオフ にできます。GPU の使用量は請求書に別の項目として表示されるため、いつアクセラレーションが有効で、いくらかかったかを完全に把握できます。GPU アクセラレーションの仕組みやパフォーマンスベンチマークの詳細は、 Amazon OpenSearch Service の GPU アクセラレーションで 10 億スケールのベクトルデータベースを 1 時間以内に構築する を参照してください。 シンプルな体験: 本番環境までのステップ削減 OpenSearch Serverless を日々運用する体験もシンプルになりました。 新しいアーキテクチャでは、コレクションをプロビジョニングして数秒でリクエストを送信し始められます。容量計画もサイジングの判断もインフラのウォームアップ待ちも不要です。これにより、AI エージェントがオンデマンドでベクトル検索や検索ステップを起動し、遅延なくレスポンスを期待できる、エージェントワークロードに Amazon OpenSearch Serverless が自然と適合します。 使い始めをさらに高速化するため、コンソールに Express Create を導入しました。コレクション名とコレクションタイプを指定し、Express Create を選ぶと、ネットワーク、暗号化、アクセスポリシーの事前設定なしで、コレクションが数秒でアクティブになります。ワークロードに必要であれば、後から追加できます。 コレクショングループとコレクションは、AWS Command Line Interface (AWS CLI) や AWS SDK を使ってプログラムから作成することもできます。AWS CloudFormation のサポートも近日提供予定です。 新しいアーキテクチャでは、 on.aws ドメイン上に 2 つのエンドポイント形式が導入されました。コレクション単位のエンドポイント ( <collectionId>.aoss.<region>.on.aws ) は、コレクション 1 つにつきエンドポイント 1 つという、これまでと同じ動作です。アカウント単位のリージョナルエンドポイント ( <accountId>.aoss.<region>.on.aws ) は新しく、1 つのホスト名で全コレクションを処理し、対象のコレクションは各リクエストで x-amz-aoss-collection-name または x-amz-aoss-collection-id ヘッダーで指定します。コレクション数に関係なく、コネクションプール 1 つ、Transport Layer Security (TLS) セッション 1 つ、管理するエンドポイント 1 つで済みます。テナントごとに独自のコレクションを割り当てるマルチテナントワークロードでは、大きな改善になります。両方のエンドポイントは標準の AWS PrivateLink を使用するため、他の AWS サービスと同様に、VPC コンソールや EC2 API から Virtual Private Cloud (VPC) エンドポイントを作成できます。Private Domain Name System (DNS) は自動で構成されるため、元のアーキテクチャで必要だった Amazon Route 53 プライベートホストゾーン、転送ルール、カスタム DNS インフラが不要になります。クロス VPC、クロスアカウント、オンプレミスからのアクセスは、追加のセットアップなしに標準の vpce-* DNS 名で動作します。 コレクショングループは、コレクションを整理する新しい単位 です。 コレクショングループ を使うと、複数のコレクション間でコンピューティング容量を共有でき、トラフィックパターンが補完的な小規模コレクションのコストを削減できます。同じグループ内のコレクションに異なる AWS Key Management Service (AWS KMS) キーを割り当てることもでき、コスト効率とコレクション単位の暗号化分離の両方を得られます。新しいアーキテクチャでコレクションを作成する場合、コレクショングループは必須です。 バージョンとアップグレードを管理する手間なく、OpenSearch オープンソースリリースの利点も得られます。サービスはアップストリームのリリースを自動的に追跡します。 Amazon OpenSearch Serverless は Vercel Marketplace でも利用可能になっており、開発者は Vercel プロジェクトから検索インフラを直接追加できます。委任アクセスを通じて既存の AWS アカウントをリンクするか、AWS が初めての場合は USD $100 の AWS クレジット付きの Limited Scope Account を通じて使い始められます。 この統合では、適切なデフォルト、ゼロまでのスケール課金、パブリックエンドポイント、AWS マネージド暗号化を備えたコレクションが作成され、接続情報が Vercel プロジェクトの環境変数として自動的に設定されます。フルテキスト検索でも、セマンティックや AI を活用した検索でも、ユースケースに応じて Search または Vector Search のコレクションタイプを選べます。 アーキテクチャの仕組み 新しい Amazon OpenSearch Serverless アーキテクチャは、コンピューティングとストレージを完全に分離します。OCU はステートレスで、インデックス作成 OCU と検索 OCU の両方からアクセス可能な分散共有ストレージ層から読み書きします。ストレージ層は高い耐久性を念頭に設計されており、データを処理するコンピューティングノードとは独立してデータを利用可能に保ちます。 この設計は、実用上 2 つの効果をもたらします。 高速なプロビジョニング。 ブートストラップするローカルディスクがないため、新しい OCU は数秒でリクエストの処理を開始します。OCU は共有ストレージ層をマウントし、すぐに処理を開始します。 効率的なスケールダウン。 データが OCU 上に存在したことがないため、保存されたデータに影響を与えずにアイドル容量を解放できます。トラフィックが下がるとコンピューティングリソースが解放され、それに応じてコストも下がります。 アーキテクチャの比較 次の表で、元のアーキテクチャと新しいアーキテクチャの主な違いをまとめます。 機能 Classic アーキテクチャ NextGen アーキテクチャ 最小容量 2 OCU (常時稼働) 0 OCU (ゼロまでのスケール) スケーリング速度 分単位 秒単位 ストレージ コンピューティングノードごとのローカルストレージ 分散共有ストレージ (分離) コレクションの整理 個別コレクション (デフォルト) コレクショングループ (オプション) コレクショングループ (必須) ゼロからのコールドスタート 該当なし (常時稼働) 約 10 秒 エンドポイント コレクション単位のエンドポイント リージョナルエンドポイント (アカウントごとに静的) OpenSearch Service ドメインに対するコスト ベースライン 最大 60% 低コスト スケーリング速度 (Classic 比) ベースライン ベースラインの最大 20 倍 ウォークスルー: ベクトルコレクションの作成とゼロまでのスケールの観察 このウォークスルーでは、Express Create でベクトル検索コレクションを作成し、埋め込みを持ついくつかのサンプルドキュメントをインデックスし、k-nearest neighbor (k-NN) クエリを実行し、Amazon CloudWatch でコレクションがゼロまでスケールする様子を観察します。全体で約 10 分かかります。 前提条件 Amazon OpenSearch Serverless コレクションを作成する権限を持つ AWS アカウント。 適切な認証情報で構成された AWS Command Line Interface (AWS CLI)。 curl 7.75 以降 (組み込みの --aws-sigv4 サポート用)。 ステップ 1: セキュリティポリシーを構成する 暗号化、ネットワーク、データアクセスポリシーを作成します。コレクションを作成する前にこれらが存在している必要があります。 # Create an encryption policy aws opensearchserverless create-security-policy \ --name product-vectors-encryption \ --type encryption \ --policy '{"Rules":[{"ResourceType":"collection","Resource":["collection/product-vectors"]}],"AWSOwnedKey":true}' \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Create a network policy (public access for this tutorial) aws opensearchserverless create-security-policy \ --name product-vectors-network \ --type network \ --policy '[{"Rules":[{"ResourceType":"collection","Resource":["collection/product-vectors"]},{"ResourceType":"dashboard","Resource":["collection/product-vectors"]}],"AllowFromPublic":true}]' \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Get your principal ARN PRINCIPAL_ARN=$(aws sts get-caller-identity --query 'Arn' --output text) # Create a data access policy aws opensearchserverless create-access-policy \ --name product-vectors-data \ --type data \ --policy "[{\"Rules\":[{\"ResourceType\":\"index\",\"Resource\":[\"index/product-vectors/*\"],\"Permission\":[\"aoss:CreateIndex\",\"aoss:DescribeIndex\",\"aoss:UpdateIndex\",\"aoss:DeleteIndex\",\"aoss:ReadDocument\",\"aoss:WriteDocument\"]}],\"Principal\":[\"\${PRINCIPAL_ARN}\"]}]" \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" 注: AWS コンソールの Express Create ワークフローを使用すると、これらのポリシーは自動的に作成されます。 重要: データアクセスポリシーを作成した後、コレクションへの API 呼び出しを行う前に、ポリシーが伝播するまで約 30〜60 秒待ちます。403 Forbidden エラーが発生した場合は、待ってから再試行してください。 ステップ 2: コレクショングループとコレクションを作成する ゼロまでのスケール容量制限を持つコレクショングループを作成し、その中にベクトル検索コレクションを作成します。 # Create a collection group with scale-to-zero enabled (min OCU = 0) aws opensearchserverless create-collection-group \ --name product-search-cg \ --generation NEXTGEN \ --standby-replicas ENABLED \ --capacity-limits "minIndexingCapacityInOCU=0,maxIndexingCapacityInOCU=4,minSearchCapacityInOCU=0,maxSearchCapacityInOCU=4" \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Create a vector search collection in the group aws opensearchserverless create-collection \ --name product-vectors \ --type VECTORSEARCH \ --collection-group-name product-search-cg \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" コレクションのステータスは数秒で ACTIVE に遷移します。 ステップ 3: ベクトルインデックスを作成する コレクションエンドポイントを取得し、3 次元ベクトルを使った k-NN インデックスを作成します。 ENDPOINT=$(aws opensearchserverless batch-get-collection \ --names product-vectors \ --query 'collectionDetails[0].collectionEndpoint' \ --output text \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2") awscurl --service aoss --region us-east-2 \ -XPUT "${ENDPOINT}/items" \ -H "Content-Type: application/json" \ -d '{ "settings": {"index.knn": true}, "mappings": { "properties": { "description": {"type": "text"}, "embedding": {"type": "knn_vector", "dimension": 3, "method": {"name": "hnsw", "space_type": "cosinesimil", "engine": "faiss"}} } } }' 注: コレクションがゼロまでスケールしている場合、容量がスケールアップする間、最初のリクエストには数秒かかる可能性があります。リクエストがタイムアウトした場合は、10〜15 秒待ってから再試行してください。 ステップ 4: 埋め込みを持つサンプルドキュメントをインデックスする awscurl --service aoss --region us-east-2 \ -XPOST "${ENDPOINT}/items/_bulk" \ -H "Content-Type: application/json" \ -d ' { "index": { "_id": "1" } } { "description": "Wireless noise-cancelling headphones", "embedding": [0.8, 0.2, 0.1] } { "index": { "_id": "2" } } { "description": "Portable Bluetooth speaker", "embedding": [0.7, 0.3, 0.2] } { "index": { "_id": "3" } } { "description": "Over-ear studio monitor headphones", "embedding": [0.9, 0.1, 0.05] } ' ステップ 5: k-NN クエリを実行する クエリベクトルに最も近い 2 つの近傍を検索します。クエリを実行する前に、ベクトルインデックスのビルドのため、インデックス作成後 30 秒待ちます。 awscurl --service aoss --region us-east-2 \ -XGET "${ENDPOINT}/items/_search" \ -H "Content-Type: application/json" \ -d '{ "query": { "knn": { "embedding": { "vector": [0.85, 0.15, 0.08], "k": 2 } } } }' レスポンスでは、最も類似する 2 つのアイテム、つまりクエリベクトルに最も近い埋め込みを持つヘッドフォンのドキュメントが返されます。 このクエリは OpenSearch UI でも実行できます。Amazon OpenSearch Service コンソールでコレクションに移動し、OpenSearch UI Application URL を選択します。次に こちらのブログ の手順に従ってワークスペースを作成します。その後、Dev Tools に移動して、次のクエリを貼り付けて実行します。 GET items/_search { "query": { "knn": { "embedding": { "vector": [0.85, 0.15, 0.08], "k": 2 } } } } ステップ 6: ゼロまでのスケールを観察する 一定期間活動がない (インデックス作成や検索のトラフィックがない) と、コレクショングループは 0 OCU までスケールダウンします。次のコマンドで確認します。 aws opensearchserverless batch-get-collection-group \ --names product-search-cg \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" レスポンスで、コレクションがスケールダウンした後、 currentCapacity.search.capacityInOcu と currentCapacity.indexing.capacityInOcu が 0 と表示されます。 Amazon OpenSearch Service コンソールの コレクショングループ ページに移動することもできます。コレクショングループを選択し、 モニタリング セクションまでスクロールします。 インデックス作成容量 (OCU) と 検索容量 (OCU) という 2 つのチャートを確認できます。10 分間アイドル状態 (インデックス作成や検索リクエストがない状態) が続くと、両方のメトリクスがゼロまで下がり、サービスがコレクションのコンピューティングリソースをすべて解放したことが確認できます。 クリーンアップ 継続的な課金を避けるため、このウォークスルーで作成したリソースは終わったら削除します。最初にコレクションを削除してコレクショングループを空にし、次にグループを削除し、最後にセキュリティポリシーとアクセスポリシーを削除します。 # Look up the collection ID, then delete the collection COLLECTION_ID=$(aws opensearchserverless batch-get-collection \ --names product-vectors \ --query 'collectionDetails[0].id' \ --output text \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2") aws opensearchserverless delete-collection \ --id "${COLLECTION_ID}" \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Look up the collection group ID, then delete the collection group GROUP_ID=$(aws opensearchserverless batch-get-collection-group \ --names product-search-cg \ --query 'collectionGroupDetails[0].id' \ --output text \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2") aws opensearchserverless delete-collection-group \ --id "${GROUP_ID}" \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Delete the security and access policies aws opensearchserverless delete-security-policy \ --name product-vectors-encryption \ --type encryption \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" aws opensearchserverless delete-security-policy \ --name product-vectors-network \ --type network \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" aws opensearchserverless delete-access-policy \ --name product-vectors-data \ --type data \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" 既存のコレクションのアップグレード 新しいアーキテクチャに移行するには、新しいコレクショングループとコレクションを作成し、データを再インデックスします。再インデックスの手順は Amazon OpenSearch Ingestion を使った Amazon OpenSearch Serverless での再インデックスの実行 に詳しく解説しています。クエリとインデックスマッピングは同じままで、変わるのはコレクションエンドポイントだけです。新しい静的リージョナルエンドポイントなら、これは 1 回限りの更新で済みます。 新しいアーキテクチャは SEARCH と VECTORSEARCH のコレクションタイプをサポートします。TIMESERIES はローンチ時にはサポートされません。 まとめ 新しい Amazon OpenSearch Serverless アーキテクチャは本日から利用可能です。Express Create を使えば最初の OpenSearch Serverless コレクションを数秒で作成し、本番トラフィックに対応するようスケールでき、アイドル状態になれば OpenSearch Serverless のコンピューティングコストはゼロまで下がります。 詳細は次を参照してください。 Amazon OpenSearch Service ドキュメント 。 Amazon OpenSearch Service コンソール 。 Amazon OpenSearch Service 料金ページ 。 質問やフィードバックがあれば、サポートケースを開くか、AWS アカウントチームを通じて連絡してください。皆さんが構築するものを楽しみにしています。 著者について Sohaib Katariwala Sohaib は AWS の Senior Specialist Solutions Architect で、イリノイ州シカゴを拠点に Amazon OpenSearch Service を担当しています。データと分析に関するあらゆる事柄に関心があります。特に、お客様がデータ戦略の中で AI を活用し、現代的な課題を解決できるよう支援することを楽しみにしています。 Raj Ramasubbu Raj は AWS の Senior Analytics and AI Specialist Solutions Architect で、ビッグデータ、分析、AI/ML に注力しています。お客様と協力して、高いスケーラビリティ、パフォーマンス、セキュリティを備えたクラウドベースのソリューションを設計・構築しています。 Arjun Nambiar Arjun は Amazon OpenSearch Service の Product Manager です。多種多様なソースから Amazon OpenSearch Service へ大規模にデータを取り込めるようにする取り込み技術に注力しています。Arjun は大規模分散システムやクラウド中心の技術に関心があり、ワシントン州シアトルを拠点としています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。