ひとことで言うと
AWS が大規模データで事前学習した FM のファミリです。そのまま使うことも、自分のデータで非公開にカスタマイズすることもできます。ただし現在の公式 overview が Bedrock 向けに列挙しているのは3モデルだけで、その内訳は埋め込み2種＋画像生成1種です。
要するに、いまの Titan は「文章を書く側」ではなく「文章を座標に変える定規」です。RAG の構成図で Titan が置かれる場所は、回答を作る箱ではなくその手前のベクトル化の箱。試験でも「どの Titan で回答を生成するか」は問われず、「どの埋め込みモデルを選ぶか」として出ます。
なぜ生まれたか
Titan は「AWS 製の汎用 FM」として置かれたファミリですが、Bedrock の Titan overview が現在列挙するモデルは、生成系がほぼ抜けて埋め込みと画像生成に寄っています。テキスト生成の Titan は overview の一覧に載っていません。新規に「テキスト生成で Titan を選ぶ」設計は、公式ドキュメントの現在の姿と合いません。
一方で埋め込み側は残り、しかも次元を選べるという後発の実務要件（ベクトルストアの容量とレイテンシ）に答える形になっています。ここが Titan が現役である理由です。
| 現在 overview に載るモデル | モデル ID | 役割 |
|---|---|---|
| Amazon Titan Text Embeddings V2 | amazon.titan-embed-text-v2:0 | テキスト → ベクトル（検索タスクに最適化） |
| Amazon Titan Multimodal Embeddings G1 | amazon.titan-embed-image-v1 | テキストと画像を同じ意味空間のベクトルに |
| Amazon Titan Image Generator G1 v2 | amazon.titan-image-generator-v2:0 | 画像生成・編集 |
「Titan は EOL になった」と断定しないこと。Bedrock の Model lifecycle ページの Legacy / EOL 一覧に Titan の行はありません（同ページに載っているのは AI21 Jamba 1.5、Amazon Nova Canvas / Reel / Premier / Sonic、Anthropic Claude、Cohere Command R などです）。overview に載っていないことと、Legacy / EOL 表に載っていることは別なので、混同しないでください。
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| RAG のインデックス作成 | チャンクを Titan Text Embeddings V2 でベクトル化し、ベクトルストアに入れる。類似度計算と検索はベクトル DB 側の仕事（モデルはしない） | D1 |
| ベクトル容量とレイテンシの調整 | 出力次元を 1,024（既定）/ 512 / 256 から選ぶ | D1・D4 |
| 大量文書の初期投入 | スループット最適化のバッチジョブでインデックスを速く作る。検索時はレイテンシ最適化のエンドポイント呼び出しを使う | D4 |
| 画像・テキストの横断検索 | Titan Multimodal Embeddings G1。テキストで画像を探す／画像で似た画像を探す／両方の組み合わせ | D1 |
| ドメイン特化の画像検索 | Multimodal Embeddings G1 を画像とキャプションの組でファインチューニング（.jsonl の image-ref / caption） | D1 |
| 画像の生成・編集 | Titan Image Generator G1 v2。テキストからの生成、インペイント／アウトペイント、背景除去、カラーパレット指定、被写体の一貫性 | D2 |
| 生成画像の来歴確認 | 透かし検出（プレビュー）または C2PA メタデータ | D3 |
試験でどう問われるか
主役では出ません。「埋め込みモデルの選定」「ベクトルストア設計」「マルチモーダル検索」のシナリオで、選択肢の中の1つとして出ます。落とせないのは次元・入力上限・言語の3点で、ここが引っかけの材料になります。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| 埋め込みモデルの選定 | テキスト検索・RAG → Titan Text Embeddings V2（最大 8,192 トークン / 50,000 文字、出力 1,024 / 512 / 256 次元） | 「次元は多いほど常に良い」前提で 1,024 を強制する選択肢（次元を下げるとストレージと検索レイテンシが下がるというトレードオフが論点） |
| 画像とテキストを横断して検索したい | 同一の意味空間が要る → Titan Multimodal Embeddings G1（出力 1,024 / 384 / 256 次元） | Titan Text Embeddings V2（テキスト専用）／Rekognition（ラベル検出であって意味空間の共有ではない） |
| 長い文書を丸ごと1ベクトルにしてよいか | 8,192 トークン入るが、公式は段落や節などの論理的な単位に分割することを推奨 | 「上限まで入るのでファイル1つ＝1ベクトル」 |
| 日本語の知識ベースを別言語で引く | V2 は英語に最適化、多言語サポートあり。ただし公式が「クロス言語クエリ（韓国語のナレッジベースにドイツ語で問い合わせる等）は最適とは言えない結果を返す」と明記 | 「多言語対応と書いてあるので言語をまたいで検索できる」 |
| 埋め込みモデルのクォータ引き上げ | 公式注記のとおり、埋め込みモデルは RPM（1分あたりリクエスト数）でスロットルされ、TPM ではありません | TPM（トークン毎分）の引き上げを申請する選択肢 |
| 埋め込みの出力を制御したい | Titan Text Embeddings V1 / V2 は maxTokenCount や topP などの推論パラメータをサポートしません | temperature や topP を調整して埋め込みの品質を上げる選択肢 |
| コスト追跡のためにアプリケーション推論プロファイルを全モデルに付けたい | 埋め込みモデルなど、推論プロファイルに対応しないモデルがあります | 「Bedrock の全モデルにアプリケーション推論プロファイルを付けられる」 |
| 生成画像かどうかを確認したい | 透かし検出（Titan Image Generator G1 と Amazon Nova Canvas の透かしを検出）または C2PA メタデータ | 「メタデータを見れば必ず判定できる」（メタデータが除去されていれば分かりません）／プレビュー機能である点と**us-east-1 / us-west-2 限定**である点を無視した選択肢 |
次元を選べることは、後から変えられることを意味しません。1,024 で作ったインデックスと 512 のベクトルは同じ空間ではないので、次元を変えると全件の再埋め込みと再インデックスが必要です。「まず 1,024 で作って、コストが問題になったら 512 に落とす」は、実質的にインデックスの作り直しになります。
実務でどう使うか
- 文字数とトークンの換算は英語で平均 4.7 文字／トークンと公式が書いています。チャンクサイズを文字数で設計しているなら、8,192 トークンの上限に対して 50,000 文字という別の上限が先に効くことがあります
- Multimodal Embeddings G1 のテキスト側は 256 トークンまでです。テキスト用の V2（8,192 トークン）と2桁違うので、「マルチモーダルにしたから長文も入る」は成立しません。画像は 25 MB・2048 × 2048 ピクセルまで、言語は英語のみ
- Multimodal のファインチューニングには検証データセットが必須で、自動キャプション生成は非対応。学習データは 1,000〜500,000 件、検証は 8〜50,000 件、キャプションは最大 128 トークンです
- Titan Image Generator の入力プロンプトは 512 文字・英語のみ。 インペイント／アウトペイント／カラーパレットはファインチューニング済みモデルでは使えません（公式の注記）。出力サイズは in/outpainting・背景除去・画像コンディショニング・カラーパレットで 1,408 × 1,408 px まで
- 生成画像には不可視の透かしと C2PA メタデータが常に付きます。 透かし検出 API はプレビューで、最新の SDK には入っていないため仮想環境を作って専用バージョンを入れるよう公式が案内しています。コンソール経由なら JPG / PNG・最大 18 MB
- 画像生成の課金は出力サイズで段が変わります。 512×512 以下と 512×512 超の2区分です
埋め込みの呼び方は1種類ではありません。公式は Titan Text Embeddings について、検索時に推奨されるのは低レイテンシのエンドポイント呼び出し、インデックス作成を速くしたいときはスループット最適化のバッチジョブ、と2つの経路を書き分けています。数十万チャンクの初期投入をリアルタイム呼び出しのループで回すと、RPM のクォータに当たって何時間も溶けます。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Titan Text Embeddings V2 と Multimodal Embeddings G1 | テキストだけなら V2（8,192 トークン）。画像とテキストを同じ空間に置くなら Multimodal（テキストは 256 トークンまで） |
| Amazon Rekognition | Rekognition はラベル・顔・モデレーションの検出。Multimodal Embeddings は意味空間へのベクトル化で、出口が検索・推薦になる |
| Amazon Comprehend | Comprehend はエンティティ抽出や感情など言語処理の結果を返す。埋め込みモデルはベクトルを返すだけで、意味の解釈はしない |
| Amazon Kendra | Kendra は検索システムそのもの。Titan 埋め込みは自分で組む検索の部品で、ベクトル DB とセットで初めて検索になる |
| Amazon Nova Canvas | 画像生成のもう一方。透かし検出は Titan Image Generator G1 と Nova Canvas の両方を対象にしているので、「透かし検出＝Titan 専用」ではない |
| ベクトル DB（OpenSearch / Aurora pgvector 等） | 公式が明記するとおり、類似度計算と検索は埋め込みモデルではなくベクトル DB の仕事。モデルを差し替えても検索アルゴリズムは変わらない |
想起チェック
Q1. Titan Text Embeddings V2 で出力次元を 1,024 から 256 に下げると、何と何が交換されますか。
ストレージ量と検索レイテンシが下がる代わりに、ベクトルが表せる情報が減ります。加えて既存インデックスとは互換がないので全件の再埋め込みが必要です。
Q2. 埋め込みモデルのスロットリング対策としてクォータ引き上げを申請します。どの単位で見ますか。
**RPM（1分あたりリクエスト数）**です。公式が「埋め込みモデルは TPM ではなく RPM でスロットルされる」と注記しています。
Q3. 「テキストで商品画像を検索する」要件に Titan Text Embeddings V2 を選べない理由は何ですか。
画像とテキストが同じ意味空間に乗らないためです。この要件は Titan Multimodal Embeddings G1（テキストと画像を同一の意味空間へ埋め込む）が担当します。
Q4. 手元の画像が Titan Image Generator で生成されたものか確認する手段と、その限界は？
透かし検出（プレビュー・us-east-1 / us-west-2）と C2PA メタデータの確認です。限界は、メタデータが除去されていると判定できないこと、および元画像から改変されていると検出精度が落ちることです。