AIF-3.1基盤モデルを使用するアプリケーションの設計上の考慮事項を説明する。

ヒントボタン

画像検索とテキスト検索を統合的に実装するには、Amazon Bedrock Titan Multimodal Embeddings で両入力を同じベクトル空間へ射影し、KNN に対応したストアへ保存する発想が近道です。単一の埋め込みを使えば入力形式ごとに推論コードを分岐させる必要がなく、学習済みモデルを呼び出すだけで済むためデータ前処理や追加学習の工程を省略できます。1 か月という短納期でも API 連携とインデックス作成に集中でき、PoC から本番までスムーズに進められる点に注目してください。

平均 50 ms、同時 200 rps のリアルタイム要件は、Amazon OpenSearch Service のベクトル KNN インデックスのようにインメモリ近傍探索を行うエンジンが強みを発揮します。Amazon Athena はバッチ寄りの分散 SQL 解析で、数百ミリ秒～秒オーダーを想定したアーキテクチャであることを思い出しましょう。OpenSearch は Auto-Tune とマネージドスケールアウトでシャード数やレプリカ配置を自動調整できるため、急なアクセス増にもノーコードで対応でき、要件の運用負荷最小化にも合致します。

長期的な多言語展開を含めて運用負荷を抑えるには、Bedrock の埋め込み API と OpenSearch Service のフルマネージド機能を組み合わせる案が有力です。Embeddings は英語・日本語・その他言語を同じベクトル空間に格納できるため、言語追加時もインデックス再構築が不要ですし、サービス側でパッチ適用やスケール操作が自動化されます。要件①～④を俯瞰すると、マルチモーダル対応、低レイテンシ、高 QPS、短期開発を一度に満たせる構成が自然と浮かび上がってくるはずです。

ヒントボタン

マスク言語モデリングは BERT 系 Transformer が標準で備えるタスクで、入力の [MASK] を最適語で埋める仕組みです。SageMaker JumpStart には日本語の事前学習済み BERT が公開されており、学習済みモデルをそのまま呼び出して Batch Transform を実行できます。S3 に格納した記事ファイルを一括で推論し、ジョブ終了後にインスタンスが自動解放されるためランニングコストを抑制しながら専門用語の穴埋めを高精度で行えます。

1 日 100 万文を数秒以内で返せれば良いという条件は単文レイテンシーより総スループットが重要です。SageMaker バッチ変換は ml.p4d など GPU インスタンス台数を指定し並列推論することで短時間のジョブ完了が可能で、従量課金は実行時間のみです。Bedrock や SageMaker リアルタイムエンドポイントは常時稼働分の料金やトークン課金がかさみやすいので、バッチワークロードでは Batch Transform の方がコスト最適化に寄与します。S3 入出力と IAM ロール設定だけでパイプラインを構成でき運用も簡潔です。

Amazon EMR や Amazon ECS で自己管理コンテナを動かす方法は、AMI パッチ適用、Spot 中断ハンドリング、スケール設定などの管理タスクが残ります。SageMaker JumpStart ならモデルアーティファクトと推論コンテナのライフサイクルを AWS が管理し、コンソールや SDK でジョブを起動するだけで済むため「最小運用」という非機能要件を満たしやすいです。Comprehend カスタム分類はあくまでクラス分け用で単語生成機能がない点も判断材料になります。

要件を総合的に眺めると、日本語対応した MLM の即時利用、100 万文を安価にバッチ処理できる課金形態、そして運用負荷を最小化できるマネージドサービスという三つの観点を同時に充足する選択肢が最適です。

ヒントボタン

1分あたり2万リクエストを150ms以内で処理し、かつ1USD/100万トークン以内に抑えるには、Amazon Bedrock の価格表とモデル仕様を眺めるだけで大枠が決まります。パラメータ数の大きい Meta Llama や Mistral Large はトークン単価が約10倍、推論時間も長いことが CloudWatch メトリクスの試算で顕著に表れます。Haiku クラスの軽量モデルなら同じ70トークン生成で約0.00007USD、レイテンシーも100ms前後と公表されており、非機能要件を余裕で満たせる計算になります。

チャット審査は創造性より判定の再現性が重要な分類タスクです。Amazon Bedrock では temperature を0、top_p を0.2程度に絞ると確率分布が固定化され、同一入力に対しほぼ同じ応答が返ります。max_tokens を20に抑えれば50トークンの入力と合わせても70トークンで済み、ネットワーク転送量も小さいため API Gateway や Lambda 経由でも150msの枠内に収まりやすいです。ストリーミングを使わなくても20トークンなら待機時間はわずかで済みます。

ファインチューニングを行わず長いポリシー全文を system プロンプトに埋め込む前提では、入力50＋出力20トークンで高い日本語・英語理解を示す軽量高速モデルを選び、temperature と top_p で再現性を高めることが鍵です。これによりレイテンシー、コスト、多言語精度という複数要件を俯瞰したときに最適な構成が自然に導き出せます。

ヒントボタン

FAQの本文は週1回ずつ増えていく動的データですから、テキストをベクトル化して Amazon OpenSearch Serverless に置き、Amazon Bedrock の Claude 3 をプロンプト内で呼び出して RAG を行う方式なら、追加分だけを再埋め込みすればよく、再学習や固定リソースを持たずに50万回/月の問い合わせをさばきながら初期費用と月次費用を同時に抑えられます。
500GBのFAQを丸ごとファインチューニングあるいは事前学習する場合、Amazon SageMaker で Spot インスタンスを使ってもGPU日数とストレージ転送料が高騰し、週次更新のたびに再度ジョブを走らせると運用負荷も増えます。対照的に Bedrock をオンデマンド推論で利用し、OpenSearch側で部分的にベクトルを再計算するだけなら、モデル重みを触らず短時間ジョブで済むため圧倒的に低コストで回せます。
必要なのは多言語生成、2秒以内の応答、50万回/月の高スループット、週次更新、そしてコスト最小化という複数要件です。マネージドLLMである Amazon Bedrock と従量課金で自動スケールする OpenSearch Serverless を組み合わせれば、プロビジョンド同時実行や固定料金を避けながら各要件のバランスを最適化できると俯瞰した総合判断ができます。

ヒントボタン

Bedrock ナレッジベースは OpenSearch Serverless のベクトル検索エンジンとネイティブ統合しており、コンソールで S3 パスを指定するだけで取り込み・インデックス作成・RAG 検索が一気通貫に自動化されます。pgvector や DynamoDB を採用すると Lambda 連携や独自 API 実装を新規に用意する必要が生じ、月 100 万件の更新試験や監視が急増します。さらに両サービスのバージョン互換も自己検証しなければならないため、公式サポートの有無を早期に確認することが運用負荷削減の近道です。

医療データでは暗号化と監査が必須ですが、Amazon OpenSearch Serverless は標準で AWS KMS を使い透過的暗号化を行い、カスタマーマネージドキーに切り替えればローテーションも CloudTrail で追跡できます。RDS for PostgreSQL に pgvector を入れたり、EC2 で OpenSearch を自己管理する構成でも SSE-KMS は設定できますが、OS パッチやノード故障時のフェイルオーバーが利用者責任となりセキュリティ運用が広がります。鍵管理だけでなくパッチ適用までマネージドに委ねられるかを比較すると、監査対応工数の差が大きく表れます。

月 100 万 PDF から生まれる数億ベクトルを追加しつつ低レイテンシを維持するには自動スケールが不可欠です。OpenSearch Serverless はワークロードに応じてキャパシティユニットを動的に増減し、シャード数やノード台数を意識せずに済みます。pgvector では VACUUM やパーティショニング設計、EC2 上のクラスターではシャーディング計画とパッチ適用が利用者の責任になり、DynamoDB は近傍検索アルゴリズム自体を持ちません。取り込み自動化・KMS 暗号化・スケールアウト・保守作業を総合的に俯瞰すると、フルマネージドで Bedrock と公式連携するサービスを選ぶ判断が最も合理的であると導けるはずです。

ヒントボタン

約15万トークンをそのまま投げ込めるかが最大の論点です。Amazon Bedrock が提供する AI21 Jurassic-2 や Titan Text Express の上限は 8k トークン前後、Cohere Command 系は 4k 程度と大幅に足りません。これに対し 20 万トークン級のコンテキストウィンドウを備えたモデルだけが「全文を一度に与えたい」という前提を崩さずにすみます。

チャンク分割を避けるなら、AWS Lambda や Step Functions で分割統合するアプローチは排除され、Bedrock API の 1 リクエストで完結させる必要があります。レイテンシ 10 秒よりも「全コンテキスト入力」が優先されるシナリオでは、日 100 回程度の呼び出しなら Anthropic 系モデルの多少高めの料金も業務上許容範囲に収まる計算になります。

複数要件を整理すると、①15 万超トークンを切らずに投入できる 20 万トークン級のコンテキスト、②Bedrock ネイティブでワンショット実行、③コストより情報量の保持を重視、の三拍子を同時に満たせる選択肢は事実上ひとつだけ、という総合的な視点で判断するのが鍵です。

ヒントボタン

店内のカメラが持つCPU2コアとRAM1GBという制約下で50ms以内に推論を終えるには、クラウドではなくデバイス内で動く軽量バイナリへモデルを変換する発想が要です。その役割を担うSageMaker Neoは学習済みモデルをハードウェア向けに自動コンパイルし、命令セット最適化でメモリ消費を抑えつつ推論エンジンを高速化します。再学習後に再コンパイルするだけで済むため開発負荷も小さく、オンプレGPUを用意する選択肢より現実的です。

配布と更新の観点ではAWS IoT Greengrass V2がコンポーネント単位の安全なデプロイを提供し、断続的な回線でも一度取得したモデルをローカルキャッシュして連続稼働できます。さらにSageMaker Edge Managerがデバイス側でバージョン管理・メトリクス収集・差分更新を自動化し、クラウド接続時だけ小さなパッケージを受け取るため帯域とメモリを最小化できます。リモートから再起動やロールバックも可能なので1,000台規模でも運用が均一化します。

ネットワーク往復を前提とするBedrock APIやクラウド推論エンドポイント、Lambda@Edgeのみの構成では回線の揺らぎと50ms制約の両立が難しいことを踏まえると、エッジでの高速推論、モデル最適化、ライフサイクル管理という複数要件を総合的に俯瞰した際に、SageMaker NeoとGreengrass V2、Edge Managerの連携が最も適合すると判断できます。