Amazon Q Developer/Business・Bedrock Data Automation・カスタムモデル本番運用

1. この記事について

生成 AI の本番活用は「どのモデルを選ぶか」という一点突破の時代から、アプリケーション層・モデルカスタマイズ層・自動化層の三層を統合設計する時代へと移行しました。本記事はその三層を体系的に掘り下げる「生成 AI 本番運用」シリーズの第 2 弾です。

前作の Vol.1 では Amazon Bedrock のコア機能（Flows によるワークフロー自動化・Evaluations によるモデル評価・Amazon Nova・クロスリージョン推論・プロンプトキャッシング）を扱いました。本記事（Vol.2）はその上位レイヤーに位置する アプリケーション層の生成 AI として、以下の 3 つの柱を中心に解説します。

1. Amazon Q Developer / Business: IDE に統合されたエージェンティックコーディングと、エンタープライズ向けの社内情報検索・回答生成
2. Bedrock Data Automation: ドキュメント・画像・動画・音声のマルチモーダル自動抽出
3. カスタムモデル（蒸留・Fine-tuning・インポート）: 自組織データによるモデル特化と推論コスト最適化

この記事で得られること

本記事を通じて、以下のスキルと知識を習得できます。

Amazon Q Developer の本番導入ロードマップ

エージェンティックコーディングを組織に展開するための具体的なセットアップ手順・ポリシー設定・ROI 測定の方法を習得できます。Free Tier から Pro Tier への移行判断基準も含めて解説します。

Bedrock Data Automation による非構造化データの自動処理

PDF・Excel・画像・動画などの非構造化データを構造化データとして抽出する Blueprint 設計のノウハウを得られます。cross-region 推論を活用した可用性確保の実装パターンも解説します。

カスタムモデルの選定・訓練・デプロイの判断フレームワーク

蒸留（Distillation）・Fine-tuning・Continued Pre-training・Custom Model Import の 4 手法を費用対効果の視点で整理し、ユースケースごとの最適な選択肢を導き出す判断フレームワークを提供します。

コスト削減の試算モデル

Model Distillation による推論コスト最大 75% 削減・Provisioned Throughput の損益分岐点計算・Batch Inference の活用など、コスト最適化の具体的な試算方法を習得できます。

なぜ今この記事を書くか

Amazon Q Developer のエージェンティックコーディング機能（2025 年 5 月）、Bedrock Data Automation の一般提供（cross-region 対応）、Model Distillation の GA（2025 年 5 月 1 日）と、本記事が扱う 3 領域のすべてで 2025 年に重要な機能リリースが相次ぎました。本稿はこれらの最新情報を整理し、実際の本番運用に必要な設計・実装・運用のノウハウをワンストップで提供することを目的としています。

各機能を個別に追うと情報が分散しがちですが、三層統合（アプリ層 × 自動化層 × モデル特化層）の視点で体系化することで、組織全体の生成 AI 活用ロードマップを描けるようになります。特に Model Distillation は teacher モデルの知識を小型 student モデルへ転送し、最大 500% の高速化・75% のコスト削減を達成できるため、本番運用コストの試算に大きな変化をもたらします。

2025 年時点では「生成 AI をどこかで使っている」という段階から「生成 AI で業務の主要フローを動かしている」という段階への移行が加速しています。Amazon Q は IDE・エンタープライズ検索・業務自動化の 3 軸で開発者の日常業務に統合され、Data Automation はドキュメント処理の自動化基盤として機能し、カスタムモデルは組織固有のユースケースへの適応を可能にします。本記事はその移行を支援するための実践的なガイドです。

本記事の対象読者

本記事は次のような方を主な対象としています。

• AWS エンジニア・アーキテクト: Amazon Q や Bedrock を本番環境に導入・運用する立場にある方
• 開発チームリード: エージェンティックコーディングの組織導入と ROI 測定を担当する方
• ML エンジニア・データサイエンティスト: Fine-tuning・蒸留・カスタムモデルインポートで推論コストを最適化したい方
• IT アーキテクト: エンタープライズ向け社内情報検索（Amazon Q Business）の設計・実装を担当する方
• IT マネージャー: コスト・ガバナンス・監視の観点から生成 AI 展開戦略を立案する方

前提知識として、AWS の基本サービス（IAM・S3・CloudWatch）の操作経験があることを想定しています。各機能の詳細は本文中で補足するため、Bedrock 未経験者でも理解できる構成にしています。

生成 AI 本番活用の三層モデル

本記事を理解する上での基本的な整理として、生成 AI の本番活用を「三層モデル」で捉えます。

推論基盤層（Bedrock コア）

クロスリージョン推論・プロンプトキャッシング・Bedrock Evaluations・Amazon Nova など、生成 AI の推論を支える基盤機能群です。Vol.1 で詳述しています。推論速度・コスト・品質のバランスを最適化するための機能がここに集約されています。

アプリケーション層（本記事の主題）

Amazon Q Developer（IDE 統合コーディング）・Amazon Q Business（エンタープライズ検索）・Bedrock Data Automation（マルチモーダル自動処理）が該当します。エンドユーザーや開発者が直接触れる「生成 AI の使い方」のレイヤーです。本記事ではこのアプリケーション層を中心に解説します。

モデル特化層（本記事の後半）

Model Distillation・Fine-tuning・Continued Pre-training・Custom Model Import によって、汎用モデルを組織固有のユースケースに適合させる層です。精度向上・コスト削減・ドメイン特化の 3 つの目的でカスタマイズが行われます。

この三層を組み合わせることで、「モデルを選んで動かすだけ」では実現できなかった高精度・低コスト・高可用性の生成 AI システムを構築できます。

前提知識と参考リソース

本記事をより深く理解するために役立つ周辺リソースを示します。

本記事の構成

各章は独立して参照できるリファレンス形式です。実装フェーズ（計画 → 構築 → 運用）に応じて必要な章から読み始めることを推奨します。

読み進め方のガイド

• 「まず全体像を把握したい」→ §1 → §6（コスト・ガバナンス）→ 担当する機能の章 の順
• 「Amazon Q Developer をすぐ導入したい」→ §2 → §6.1（料金）の順
• 「社内文書検索（Q Business）を構築したい」→ §3 → §6.2（料金）の順
• 「推論コストを削減したい」→ §5（カスタムモデル）→ §6.4（料金）の順
• 「マルチモーダルデータを処理したい」→ §4 → §7（統合パターン）の順

それでは §2 Amazon Q Developer 本番運用から解説を始めます。

2. Amazon Q Developer 本番運用

Amazon Q Developer は、AWS が提供する IDE 統合型の AI コーディングアシスタントです。単なるコード補完ツールにとどまらず、エージェンティックコーディング・コード変換・コード品質向上の 3 つの柱で開発生産性を底上げします。2025 年 5 月にエージェンティックコーディング機能が強化され、複数ファイルにまたがる自律的なタスク実行が可能となり、本番開発ワークフローへの統合が大きく進みました。

2.1 エージェンティックコーディング — 自然言語でタスクを自律実行

エージェンティックコーディングは、開発者が自然言語でタスクを指示するだけで、Amazon Q Developer がファイルの読み取り・編集・テスト実行・エラー修正まで自律的に進める機能です。従来のコード補完が「1 行ずつ提案する」モデルだったのに対し、エージェンティックモードは「課題解決まで自律的に進む」モデルです。

2.1.1 対応 IDE とセットアップ

2025 年時点でエージェンティックコーディングに対応している IDE は次のとおりです。

セットアップ手順は次の 3 ステップです。

1. プラグインのインストール: VS Code の場合は拡張機能マーケットプレイスから「Amazon Q」を検索してインストールします。JetBrains は Plugins マーケットプレイスから同様に行います。
2. 認証: Free Tier の場合は AWS Builder ID（無料で作成可能）でサインイン。Pro Tier は組織の IAM Identity Center 経由で SSO サインインします。
3. 動作確認: IDE サイドパネルに Amazon Q のチャットウィンドウが表示されれば準備完了です。

2.1.2 エージェンティックコーディングのワークフロー

エージェンティックモードでタスクを指示すると、以下の流れで処理が進みます。

ステップ 1 — タスク指示（自然言語）

チャットウィンドウに自然言語でタスクを記述します。指示の粒度は「新機能の追加」から「バグ修正」「テストの追加」まで幅広く対応しています。

# 指示例（日本語・英語どちらも対応）
「users テーブルにメール認証フラグを追加するマイグレーションと、
 それに対応するユニットテストを作成してください」

ステップ 2 — コンテキスト収集

Amazon Q Developer はリポジトリ構造を解析し、関連ファイルを自動で特定します。プロジェクトの命名規則・フォルダ構成・既存のテストパターンを読み取り、既存コードと整合性のある実装を生成します。

ステップ 3 — マルチファイル編集

複数ファイルに分散した変更を一括で生成します。例えばマイグレーションファイル・モデルクラス・テストファイルを同時に生成・編集します。各変更はプレビューとして表示され、開発者が Accept/Reject を選択してから実際に適用されます。

ステップ 4 — テスト実行とエラー修正

生成したコードのテスト実行を自動でトリガーし、テスト失敗時はエラーメッセージを解析して修正を試みます。このサイクルを繰り返すことで、テストが通る状態まで自律的に収束します。

ステップ 5 — 変更サマリーの提示

すべての変更が完了すると、変更内容のサマリー（変更ファイル一覧・追加/削除行数・テスト結果）が表示されます。開発者はこのサマリーを元に最終レビューを行います。

2.1.3 UI の多言語対応

Amazon Q Developer の UI は 9 言語に対応しています（2025 年時点）。英語以外のユーザーも母国語で操作できるため、グローバル開発チームへの展開がスムーズに行えます。日本語 UI を含むため、国内エンジニアチームへの導入障壁が低い点も評価ポイントです。

2.1.4 エージェンティックコーディングの活用シナリオ

リファクタリングの自動化

「このモジュールの関数を単一責任原則に従ってリファクタリングしてください」と指示するだけで、ファイルをまたいだリファクタリングを自動実行します。手動でのリファクタリングと比べて大幅な時間削減が期待できます。

テストカバレッジの向上

「カバレッジが低いモジュールを特定してテストを追加してください」という指示で、カバレッジレポートを分析し優先度の高いテストケースを自動生成します。

ドキュメント生成

コードコメントや API ドキュメント（JSDoc・OpenAPI 形式など）の自動生成も得意領域です。既存コードのコンテキストを正確に把握した上でドキュメントを生成するため、手動でのドキュメント整備と比べて品質が均一になります。

2.2 リアルタイム補完と言語カスタマイズ

エージェンティックコーディングが「タスク単位の自律実行」であるのに対し、インラインコード補完は開発者がコードを書く瞬間ごとに機能するリアルタイムアシスタントです。

2.2.1 対応プログラミング言語

Amazon Q Developer のインライン補完は 25 以上のプログラミング言語に対応しています。主な対応言語は次のとおりです。

特に Terraform HCL や CloudFormation への対応は、インフラをコードで管理する IaC ワークフローにおいて大きな価値を持ちます。リソース定義の補完・変数参照の提案・モジュール呼び出しの構文補完が IDE 上でリアルタイムに機能します。

2.2.2 コードカスタマイズ機能

Pro Tier では、自組織のコードリポジトリを Amazon Q Developer に学習させる カスタマイズ（Customization）機能が利用できます。

カスタマイズに対応している言語は次のとおりです。

• 汎用言語: C#・C++・Dart・Go・Kotlin・PHP・Ruby・Rust・Scala
• スクリプト: Bash・PowerShell
• インフラ定義: AWS CloudFormation・Terraform HCL

カスタマイズの仕組みは次のように動作します。組織のプライベートリポジトリ（GitHub・GitLab・Bitbucket・AWS CodeCommit）を参照データとして指定すると、Amazon Q Developer はそのリポジトリのコーディングパターン・命名規則・ライブラリ使用パターンを学習します。以降の補完提案は、汎用知識だけでなく組織固有のスタイルに基づいた提案になります。

カスタマイズが特に効果を発揮するシナリオ

• 社内独自フレームワークを多用している環境（ライブラリ名や API 呼び出しパターンが自動補完される）
• 厳格なコーディング規約がある組織（規約準拠のコードが優先的に提案される）
• マイクロサービス間で共通パターンを使い回している環境（既存サービスと整合したボイラープレートが提案される）

カスタマイズは追加料金が発生します（§6 で詳述）。費用対効果を試算する際は、補完採用率の向上によって節約できる開発工数と比較してください。

2.2.3 補完品質を高める実践的なヒント

補完の精度は開発環境の設定によって大きく変わります。以下のポイントを実践することで補完品質を向上できます。

コンテキストファイルを開いておく

Amazon Q Developer は現在開いているファイルと、同一プロジェクト内の関連ファイルをコンテキストとして参照します。補完精度を高めるために、インターフェース定義ファイル・型定義ファイル・テストファイルを事前に開いておくと効果的です。

コメントで意図を明示する

関数の上にコメントで実装意図を書いてから関数本体を書き始めると、コメントをコンテキストとして解釈した高精度な補完が得られます。特に複雑なビジネスロジックや特殊なアルゴリズムを実装する場合に有効です。

プロジェクト設定ファイルの整備

package.json・pyproject.toml・build.gradle などの依存関係ファイルが適切に整備されていると、使用しているライブラリのバージョンに合った API の補完が優先されます。

2.3 Code Transformation — Java モダナイゼーションと SDK 移行

Code Transformation は、既存コードを新しいバージョンや別の SDK に自動移行する機能です。手動でのコード移行は工数と品質リスクが高く、大規模なコードベースでは特に困難ですが、Code Transformation を使うと移行作業を大幅に自動化できます。

2.3.1 Java バージョンアップグレード

最も実績のあるユースケースは Java のバージョンアップグレードです。例えば Java 8 から Java 17、Java 11 から Java 21 といった LTS バージョン間の移行を自動化します。

移行プロセスの流れは次のとおりです。

1. 対象プロジェクトの選択: IDE 上で変換対象のプロジェクトを選択し、移行先 Java バージョンを指定します
2. 依存関係の解析: pom.xml・build.gradle の依存関係を解析し、バージョン非互換の依存ライブラリを特定します
3. コード変換の実行: 非推奨 API の置き換え・新しい構文への書き換え・インポート文の更新を自動実行します
4. ビルドとテストの確認: 変換後にビルドを実行し、コンパイルエラーとテスト失敗がないことを確認します
5. 変換レポートの確認: 変換できなかった箇所・手動対応が必要な箇所をレポートとして出力します

Free Tier では月 5,000 行まで、Pro Tier では無制限で利用できます。100,000 行超のコードベースでも、通常数時間以内に変換が完了します（ネットワーク帯域とプロジェクト規模による）。

2.3.2 AWS SDK 移行（AWS Transform）

AWS Transform は、AWS SDK のバージョン移行を自動化する機能です。代表的なユースケースは AWS SDK for Java v1 から v2 への移行です。

v1 と v2 の間には API レベルで多数の破壊的変更があり、手動移行は単純な検索・置換では対応できません。AWS Transform は以下を自動処理します。

• クライアント初期化コードの書き換え（AmazonS3 → S3Client 形式へ）
• 同期 API から非同期 API（CompletableFuture ベース）への変換オプション
• レスポンスオブジェクトの取り出し方法の変更への対応
• リクエストビルダーパターンへの書き換え

移行の効果測定

移行完了後は、IDE 上でビフォー・アフターの差分を確認できます。変換レポートには「自動変換成功件数」「手動対応推奨箇所」「スキップされたコード（変換範囲外）」が明示されるため、残作業の見積もりが容易になります。

2.3.3 AWS SDK for Java v1 → v2 移行の変換例

Code Transformation が自動処理する変換の代表例を示します。

S3 クライアントの初期化（変換前）

// AWS SDK for Java v1（Before）
AmazonS3 s3Client = AmazonS3ClientBuilder.standard()
 .withRegion(Regions.AP_NORTHEAST_1)
 .build();

S3 クライアントの初期化（変換後）

// AWS SDK for Java v2（After）
S3Client s3Client = S3Client.builder()
 .region(Region.AP_NORTHEAST_1)
 .build();

AmazonS3 から S3Client への型変更、Regions 列挙型から Region クラスへの変更、ビルダーメソッド名の変更（withRegion → region）を Code Transformation が自動処理します。大規模なコードベースでは、このような変換が数百〜数千箇所で発生するため、自動化の効果が大きく現れます。

2.3.4 Code Transformation の注意点

Code Transformation は強力ですが、以下の制約を把握した上で活用してください。

• ビジネスロジックの意味は変えない: 構文的な移行は自動化されますが、ビジネスロジック自体の見直しは人間が行う必要があります。変換後のコードは必ずビジネス要件に照らした動作確認を行ってください
• テストカバレッジが低い場合のリスク: 変換前のコードのテストカバレッジが低いと、変換後の動作確認が困難になります。変換を実施する前に、主要機能のテストカバレッジを一定レベル（目安: ライン 70% 以上）に引き上げることを推奨します
• サードパーティライブラリの非互換: AWS SDK 移行の対象外となるサードパーティライブラリの非互換は手動対応が必要です。変換レポートで「手動対応推奨」とマークされた箇所を重点的に確認してください

2.4 コード品質向上と脆弱性検知

Amazon Q Developer はコーディング中にリアルタイムでコードを解析し、品質上の問題点・潜在的な脆弱性・改善提案を提示します。この機能を活用することで、コードレビューの前段階で問題を早期に発見し、修正コストを大幅に削減できます。

2.4.1 対応言語と検知の仕組み

脆弱性検知機能は 十数のプログラミング言語に対応し、数千のルール（detector）を内蔵しています。対応言語は以下のとおりです。

CloudFormation・CDK・Terraform HCL に対応している点は特筆すべき強みです。インフラコードの設定ミス（過剰な権限設定・暗号化なしのリソース定義・パブリックアクセス設定ミスなど）を、デプロイ前のコーディング段階で検出できます。

検知の仕組み

Amazon Q Developer の静的解析エンジンは、コードのデータフロー・制御フロー・API 利用パターンを総合的に解析します。単純なパターンマッチングではなく、コンテキストを考慮した解析を行うため、誤検知（False Positive）の発生率が低い点が特徴です。

2.4.2 スキャンモードの使い分け

スキャンのトリガー方法は Free Tier と Pro Tier で異なります。

Pro Tier の自動スキャンは、開発者が手動でスキャンを忘れた場合でも Pull Request 作成時に必ずチェックが走ります。組織の開発フローに組み込むことで、問題コードがマージされる前に必ずスキャンが実施される体制を低コストで構築できます。

2.4.3 検知カテゴリと対応方法

Amazon Q Developer が検知する主なカテゴリを以下に示します。

インジェクション系の問題

SQL インジェクション・コマンドインジェクション・パスインジェクションなど、外部入力が適切にサニタイズされていない箇所を特定します。検知時には問題のある行のハイライトと、修正方法の提案（パラメータ化クエリへの書き換えサンプルなど）が表示されます。

暗号化・認証の設定ミス

ハードコードされた認証情報・不適切な暗号化アルゴリズムの使用（弱いハッシュ関数など）・TLS 検証を無効化しているコードを検出します。

インフラ設定の誤り

CloudFormation・Terraform での S3 バケットのパブリックアクセス設定・暗号化なしのデータストア定義・過剰な権限ポリシー（* アクション・* リソース）を検出します。デプロイ前にこれらを検出することで、設定ミスによる意図しないデータ露出を防げます。

非推奨 API の使用

使用している AWS SDK や言語ランタイムの非推奨 API を検出し、推奨代替手段を提示します。長期的な保守性を高めるうえで有効です。

2.4.4 検知結果の活用と CI/CD 統合

IDE での即時修正

検知された問題は IDE のサイドパネルに一覧表示され、各問題には「クイックフィックス」オプションが提示されます。Accept を選択するだけで修正コードが自動適用されます。特に単純な修正（ハードコード認証情報の環境変数への移行・SQL クエリのパラメータ化など）はワンクリックで対応できます。

CI/CD パイプラインへの組み込み

Pro Tier では Pull Request 作成時に自動スキャンが実行されます。スキャン結果は PR のコメントとして追記されるため、コードレビュアーが変更内容と合わせて一目で確認できます。スキャンで重大度「Critical」の問題が検出された場合に PR マージをブロックするポリシーを設定することも可能です（管理コンソールで設定）。

スキャン結果のトレンド管理

Pro Tier の管理コンソールでは、チームまたは個人ユーザーごとの検知件数・重大度分布・解消件数のトレンドを確認できます。このデータを活用することで、特定のコンポーネントや開発者で問題が集中しているパターンを把握し、改善策（コードレビュー強化・トレーニング）を優先的に講じられます。

2.5 管理とガバナンス

組織規模で Amazon Q Developer を展開するには、管理コンソールによる一元管理体制が不可欠です。Pro Tier で提供される管理機能を活用し、ライセンス管理・ポリシー設定・利用状況モニタリングを統合的に運用します。

2.5.1 管理コンソールの機能

Amazon Q Developer の管理コンソール（Pro Tier）では以下の管理が可能です。

ユーザーとライセンスの一元管理

IAM Identity Center と連携してシングルサインオンを構成し、組織のユーザーディレクトリ（Active Directory・Okta 等）と紐付けます。部署・チーム単位でライセンスの割り当てポリシーを設定し、月次アクティブユーザーレポートで未使用ライセンスを特定・回収できます。

機能ポリシーの組織展開

コード補完のスコープ（ローカルコードのみ / クラウド連携あり）を組織全体のポリシーとして設定します。カスタマイズ機能の使用可否を部署レベルで制御し、自動スキャンのトリガー条件（PR 作成時 / コミット時）を標準化します。

利用状況のダッシュボード

部署別・ユーザー別のコード補完採用率・変換実行件数・脆弱性検知件数をダッシュボードで一覧確認できます。このデータは ROI 計算と継続投資判断の根拠として活用します。例えば「コード補完採用率 40%→65% へ向上 = 年間 N 時間の開発工数削減」という形で定量的な ROI を算出できます。

2.5.2 ポリシー設定のベストプラクティス

段階的なロールアウト

全社一斉導入よりも、先行チーム（10〜20 名）でパイロット運用を開始し、補完採用率・満足度・ROI を 1〜2 ヶ月かけて測定してから全社展開するアプローチを推奨します。先行チームのフィードバックをカスタマイズ設定に反映することで、全社展開後の満足度を高められます。

最小権限ポリシーの適用

管理コンソールで設定できるコード送信スコープ（IDE から Q Developer に送信するコードの範囲）は、最初は「現在開いているファイルのみ」に限定し、必要に応じて「プロジェクト全体」に拡張するアプローチを推奨します。機密コードや未公開アルゴリズムを含むリポジトリでは、送信スコープの制御が特に重要です。

定期的なライセンス棚卸し

月次でアクティブユーザー数を確認し、3 ヶ月以上未使用のアカウントを特定してライセンスを回収します。特に組織変更（異動・退職）のタイミングでの棚卸しを徹底することで、ライセンスの無駄なコストを削減できます。

カスタマイズの効果測定

カスタマイズ導入後は、コード補完採用率のベースライン（導入前）と導入後を比較します。補完採用率が 10 ポイント以上向上していれば、カスタマイズの追加料金に見合う効果が出ていると判断できます。逆に採用率が変わらない場合は、カスタマイズ設定（参照リポジトリの選定・更新頻度）を見直す必要があります。

2.5.3 利用状況モニタリングとコスト管理

管理コンソールのデータと CloudWatch のメトリクスを組み合わせることで、Q Developer の投資対効果を継続的に測定できます。主要な KPI として次の指標を追跡することを推奨します。

補完採用率が低下し続ける場合（月次で継続的に 30% 以下）は、提案品質の問題かカスタマイズ設定の見直しが必要なサインです。管理コンソールのユーザーフィードバックデータと合わせて分析し、改善策を検討してください。

2.5.4 開発チームへの展開ガイド

Amazon Q Developer を開発チームに定着させるには、ツールの提供だけでなく「使い方の定着」が必要です。以下のステップで展開することを推奨します。

Week 1〜2: ハンズオンと基本機能習得

チーム全員でハンズオンセッション（2〜3 時間）を実施し、インライン補完・チャット機能・エージェンティックモードの基本操作を体験します。実際の業務コードを使ったデモを行うことで、「自分のコードでも機能する」という実感を早期に持たせることが定着の鍵です。

Week 3〜4: 実務での試用

各開発者が日常業務の中で 1 日 30 分以上 Amazon Q Developer を意識的に使う「試用期間」を設けます。週末に短い振り返りを行い、「役に立ったケース」「役に立たなかったケース」を共有することで、チーム内のベストプラクティスが自然に形成されます。

Month 2 以降: 採用率の測定と改善

管理コンソールの補完採用率を週次でモニタリングし、採用率の低いユーザーには個別のフォローアップ（どのようなコードを書いているか・どのような提案が出ているかの確認）を行います。採用率が高いユーザーの活用事例を社内勉強会で共有する仕組みを作ると、組織全体の活用レベルが向上します。

3. Amazon Q Business エンタープライズ運用

3.1 Amazon Q Business の全体像

Amazon Q Business は、企業内のデータソースとナレッジベースを統合し、従業員が自然言語でビジネス情報にアクセスできるエンタープライズ向けの RAG チャットボットサービスです。単なる汎用 AI アシスタントとは異なり、組織固有のドキュメントや業務システムのデータを根拠として回答を生成します。ユーザーごとの権限情報に基づいてドキュメントをフィルタリングするため、機密情報の漏洩リスクを抑えながら社内ナレッジを民主化できる点が最大の強みです。

Amazon Q Developer がエンジニアのコード生成・変換・セキュリティスキャンに特化するのに対し、Q Business はマーケティング・法務・HR・カスタマーサポートなど、あらゆる業務部門のナレッジワーカーを対象とします。社内の分散した情報を一元的に検索・活用できる企業向けナレッジアシスタントとして位置付けられています。

Q Business の主要コンポーネントは「アプリケーション」「インデックス」「データソース（コネクタ）」「レトリーバー」の4層で構成されます。コネクタがデータソースからドキュメントを収集し、インデックスがベクトル化・格納、レトリーバーがクエリに応じて関連ドキュメントを検索、そして基盤モデルが回答を生成するというパイプラインです。

3.2 データソースコネクタの種類と設定

Amazon Q Business は、企業が利用する主要な業務システムとのコネクタを標準で提供しています。2025年現在、以下のカテゴリのコネクタが利用可能です。

コラボレーション・ドキュメント管理系

• Confluence: スペース・ページ・ブログ・コメントを同期します。ページの階層構造とラベルメタデータを保持し、スペースやラベルによる同期対象の絞り込みが可能です
• Microsoft SharePoint: サイトコレクション・ドキュメントライブラリ・リストを同期します。SharePoint Online（Microsoft 365）とSharePoint Server 2013/2016/2019 に対応しています
• Microsoft Teams: チャンネルメッセージおよびファイルを同期します。Microsoft Graph API を経由するため、管理者によるアプリ承認が必要です
• Box: フォルダ・ファイル・コメントを同期します。Box Skills との統合でメタデータの自動付与も可能です

プロジェクト・チケット管理系

• Jira: プロジェクト・課題・コメント・添付ファイルを同期します。課題タイプ（バグ/ストーリー/タスク等）やステータスでフィルタリングができます。Jira Cloud と Jira Server の両方に対応しています
• ServiceNow: インシデント・ナレッジベース記事・サービスカタログを同期します。ServiceNow のロール情報を自動クロールしてアクセス制御情報を引き継ぎます

ストレージ・データ系

• Amazon S3: バケット内のドキュメント（PDF / Word / Excel / HTML / Markdown / テキスト等）を同期します。フォルダプレフィックスや最終更新日時でフィルタリングが可能で、S3 オブジェクトタグをカスタムメタデータとして活用できます
• Amazon RDS / Aurora: 構造化データに対して自然言語クエリ（NL2SQL）で回答生成が可能です。Bedrock Knowledge Bases との統合により、非構造化データと構造化データの横断検索も実現できます

CRM・カスタマーサポート系

• Salesforce: ケース・ナレッジ記事・商談・取引先を同期します。Salesforce の権限セット・プロファイル・ロール階層に基づくクロールに対応しています
• Zendesk: チケット・ヘルプセンター記事・コミュニティ投稿を同期します。ブランド（マルチブランド構成）ごとに同期範囲を分けることができます

コミュニケーション系

• Slack: パブリック・プライベートチャンネルのメッセージとファイルを同期します。Slack 管理者権限でのアプリ承認が必要で、メッセージの可視性はチャンネルメンバーシップで制御されます
• Gmail・Google Drive: Google Workspace 環境の場合、OAuth 2.0 でユーザー単位の認証を行い、個人ドライブや共有ドライブのファイルを同期します

各コネクタはデータ取得スケジュール（1時間〜24時間間隔）を設定でき、増分同期（変更された分のみ取得）を標準でサポートしています。初回同期後は増分同期が自動で実行されるため、インデックスを常に最新の状態に保つことができます。

コネクタ設定の共通項目

3.3 カスタムコネクタ（Q Business SDK）

標準コネクタでカバーされていない独自の業務システムとの連携には、Q Business SDK を使ってカスタムコネクタを実装します。

import boto3

client = boto3.client('qbusiness', region_name='us-east-1')

# カスタムコネクタによるドキュメント一括登録
response = client.batch_put_document(
 applicationId='your-app-id',
 indexId='your-index-id',
 documents=[
  {
'id': 'internal-doc-001',
'title': '社内ナレッジ: 決済フロー標準手順',
'content': {
 'blob': document_bytes,
},
'contentType': 'PDF',
'attributes': [
 {
  'name': '_document_author',
  'value': {'stringValue': 'yamada@example.com'}
 },
 {
  'name': 'department',
  'value': {'stringValue': 'finance'}
 },
 {
  'name': '_last_updated_at',
  'value': {'dateValue': '2025-03-01T00:00:00Z'}
 }
],
'accessControlList': [
 {
  'name': 'finance-team',
  'type': 'GROUP',
  'access': 'ALLOW'
 },
 {
  'name': 'exec-team',
  'type': 'GROUP',
  'access': 'ALLOW'
 }
]
  }
 ]
)

batch_put_document API では、ドキュメント本文の登録と同時に accessControlList フィールドで ACL 情報を設定します。これにより、独自システムのアクセス制御情報をそのまま Q Business に引き継ぐことができます。

増分同期の実装パターン

カスタムコネクタで増分同期を実現するには、最終同期日時をパラメータストアや DynamoDB に保存し、変更されたドキュメントのみを batch_put_document で更新します。削除されたドキュメントは batch_delete_document で明示的に削除する必要があります。

# 削除されたドキュメントの処理
response = client.batch_delete_document(
 applicationId='your-app-id',
 indexId='your-index-id',
 documents=[
  {'documentId': 'internal-doc-obsolete-001'},
  {'documentId': 'internal-doc-obsolete-002'}
 ]
)

Lambda + EventBridge の組み合わせで定期実行をスケジューリングするのが標準的なパターンです。データソース同期セッションを使うことで、同期中のドキュメント数や失敗件数を監視できます。

3.4 プラグインシステム（リアルタイム連携）

プラグインは外部サービスとのリアルタイム連携を実現します。インデックス済みドキュメントを参照するコネクタと異なり、プラグインはユーザーの指示に応じて実行時に外部 API を呼び出し、最新データの取得やアクション実行を行います。

prebuilt プラグイン

Jira・ServiceNow・Salesforce など主要サービスのアクション（チケット作成・更新・検索・承認等）が事前定義されています。設定は認証情報とエンドポイント URL の登録のみで完了します。

Jira プラグイン利用例

ユーザー: 先ほど発見した認証エラーをJiraに高優先度で起票してください。
 タイトルは「本番環境: OAuth認証タイムアウトエラー多発」で。

Q Business: 承知しました。以下の内容でJiraに課題を作成しました。
  プロジェクト: OPS  /  優先度: 高  /  担当: インフラチームキュー
  課題番号: OPS-1847

チャット画面から直接 Jira チケットを作成・更新できるため、コンテキストスイッチを大幅に削減できます。

カスタムプラグイン

OpenAPI 仕様（Swagger 3.0）でエンドポイントを定義することで、任意の REST API をプラグインとして登録できます。

# カスタムプラグインのOpenAPI定義例: 在庫照会API
openapi: 3.0.0
info:
  title: 在庫照会API
  version: 1.0.0
servers:
  - url: https://api.example.com/v1
paths:
  /inventory/{productId}:
 get:
operationId: getInventoryByProduct
summary: 指定製品の現在在庫数を照会する
parameters:
  - name: productId
 in: path
 required: true
 schema:
type: string
 description: 製品コード（例: PROD-001）
responses:
  '200':
 description: 在庫情報
 content:
application/json:
  schema:
 type: object
 properties:
productId:
  type: string
stockQuantity:
  type: integer
warehouseLocation:
  type: string
lastUpdated:
  type: string
  format: date-time

この OpenAPI 定義を Q Business に登録すると、在庫 API をリアルタイムで呼び出し、最新の在庫数を回答します。認証は Secrets Manager に保存した API キーが自動で付与されます。

3.5 IAM Identity Center 連携と trusted identity propagation

エンタープライズ環境での Amazon Q Business 運用において、IAM Identity Center（旧 AWS SSO）との統合は中核をなす要素です。

trusted identity propagation の仕組み

IAM Identity Center の trusted identity propagation 機能により、エンドユーザーのアイデンティティコンテキストを Q Business まで伝播させることができます。これにより、Q Business はリクエストを送信した「実際のユーザー」を特定し、そのユーザーが閲覧権限を持つドキュメントのみを検索対象とします。

従来のサービス間連携では IAM ロールを使ってサービスアカウント的にアクセスするため、「誰がアクセスしたか」の情報が失われていました。trusted identity propagation ではユーザーの ID トークンを後続サービスまで伝播させることでこの問題を解決します。Q Business から Bedrock Knowledge Bases へのような連携でも、エンドユーザーの権限でリソースアクセスが制御されます。

4 種類のアプリケーション作成方式

Amazon Q Business のアプリケーションには、ユーザーの認証方式に応じて 4 つの作成方式があります。

IAM Identity Center 統合方式のセットアップ手順

1. IAM Identity Center でアプリケーションを作成し、Q Business アプリとして登録する
2. Identity Center のユーザー・グループを Q Business アプリの加入者として割り当てる
3. アプリケーションポリシーで trusted identity propagation を有効化する
4. Q Business 側で Identity Center の Issuer URL を設定する
5. データソースのユーザーマッピングを構成する（メールアドレス等の識別子を対応付け）

IAM federation (OIDC) 方式

Okta や Azure AD 等の外部 IdP を利用している場合、Identity Center の External Identity Provider として接続するか、Q Business アプリ側で OIDC プロバイダーとして直接設定します。

# IAM federation (OIDC) 方式でのアプリケーション作成例
response = client.create_application(
 displayName='EnterpriseKnowledgeBot-Production',
 identityType='AWS_IAM_IDP_OIDC',
 identityProviderConfiguration={
  'openIDConnectConfiguration': {
'secretsArn': (
 'arn:aws:secretsmanager:us-east-1:123456789012:'
 'secret:okta-qbusiness-client-secret'
),
'secretsRole': (
 'arn:aws:iam::123456789012:role/QBusinessOIDCRole'
)
  }
 },
 description='企業ナレッジボット本番環境'
)

3.6 ドキュメントレベルのアクセス制御

Q Business のアクセス制御は「誰が何を見られるか」をドキュメント単位で管理します。ユーザーが質問したとき、そのユーザーが閲覧権限を持つドキュメントのみを参照して回答が生成されます。

ACL クロールの流れ

1. クロール: コネクタが Jira・Confluence 等の API を呼び出し、各ドキュメントの権限情報（閲覧可能なユーザー・グループ）を取得する
2. User Store 格納: 取得した権限情報を Q Business 内部の User Store に格納する
3. 認可フィルタ: ユーザーが検索するとき、User Store のユーザー情報と照合してドキュメントをフィルタリングする
4. 回答生成: フィルタリング後の検索結果のみを根拠として基盤モデルが回答を生成する

この仕組みにより、「Aさんには見えるが Bさんには見えないドキュメント」が混在する環境でも、Q Business が自動的に適切なドキュメントのみを参照して回答を生成します。同じ質問をしても参照されるドキュメントがユーザーによって異なるため、機密情報の横断参照を防止できます。

ユーザーマッピングの設定

データソース（例: Jira）ではユーザーをメールアドレスで識別し、IAM Identity Center ではユーザーを固有の User ID で識別します。この識別子の食い違いを解消するためにユーザーマッピングを設定します。

# グループのユーザーマッピング登録例
response = client.put_group(
 applicationId='your-app-id',
 indexId='your-index-id',
 groupName='finance-team',
 dataSourceId='your-jira-datasource-id',
 type='INDEX',
 groupMembers={
  'memberUsers': [
{'userId': 'yamada@example.com'},
{'userId': 'tanaka@example.com'},
{'userId': 'suzuki@example.com'}
  ]
 }
)

グループメンバーシップをマッピングすることで、組織のグループ構造をそのまま Q Business のアクセス制御に反映できます。SCIM プロビジョニングを使うと、Identity Center のユーザー・グループ情報を自動同期できます。

グローバルフィルタとローカルフィルタ

アクセス制御はコネクタ単位（ローカル）またはアプリケーション全体（グローバル）で有効化できます。

• グローバルフィルタ（推奨）: アプリケーションレベルでアクセス制御を有効化し、全コネクタに適用します。設定の抜け漏れを防ぎ、一貫した権限管理を維持できます
• ローカルフィルタ: 特定のコネクタのみ権限フィルタを有効化します。機密データを含むコネクタには厳密な制御を適用し、社内 Wiki など誰でも閲覧可能なコネクタはフィルタ無効でパフォーマンスを優先するという使い分けが可能です

3.7 回答品質設定とハルシネーション抑制

引用・出典の自動表示

Q Business の回答には、参照したドキュメントへのリンクが自動付与されます。エンタープライズ環境では「どの資料に書いてあるか」が重要なため、デフォルトで引用表示が有効です。

Q Business の回答例:
「オンボーディング手順については以下のドキュメントを参照しました。
 [1] 新入社員ハンドブック 第3章（2024年3月改訂版）
 [2] IT環境セットアップガイド v2.1

 PC 設定手順については[2]の第2節をご確認ください。不明点がある場合は
 同資料に記載の IT ヘルプデスク（内線5000）にお問い合わせください。」

引用リンクをクリックすると、元のドキュメントの該当箇所（Confluence ページや Jira チケット）に直接ジャンプします。

回答品質の設定項目

ハルシネーション抑制のポイント

Q Business はインデックス済みドキュメントを根拠とした回答生成（RAG）を基本とするため、汎用 LLM に比べてハルシネーションリスクは低く抑えられています。それでも以下の追加対策が重要です。

① ドキュメント鮮度の維持: 同期スケジュールを短く設定し、古い情報がインデックスに残り続けないようにします。製品仕様・価格・手順書は変更頻度が高いため、週次以上の同期が推奨されます。廃止されたドキュメントは明示的に削除するか、同期対象から除外してください。

② 回答拒否の有効化: 関連ドキュメントが見つからない質問に対して「情報がありません」と回答させ、基盤モデルの訓練データのみで回答させないようにします。社外の一般情報と社内固有情報の混同を防ぐ効果があります。

③ 同期スコープの精査: 下書き・個人メモ・実験的なドキュメントがインデックスに含まれると、不確かな情報が回答に使われる可能性があります。「承認済み」ラベルや特定スペースに限定した同期範囲の設計が重要です。

④ フィードバックの収集と活用: ユーザーの「いいね/よくない」評価をログとして蓄積し、定期的にドキュメントの品質を見直します。低評価が多い回答の根拠ドキュメントは内容の更新や同期除外を検討します。

3.8 本番運用の考慮点とアンチパターン

本番運用チェックリスト

• IAM Identity Center 統合が設定され、全ユーザーが認証されている
• ACL クロールが有効で、ユーザーマッピングが正しく構成されている
• 同期スケジュールが設定され、インデックスが定期更新されている
• 回答拒否設定が有効で、根拠のない回答を排除している
• CloudWatch でインデックスサイズ・クロールエラー率を監視している
• ユーザーフィードバックの分析プロセスが整備されている
• カスタムプラグインの API 認証情報が Secrets Manager で管理されている

よくあるアンチパターンと対策

権限設定を後回しにする: PoC 段階で匿名アクセス方式で構築し、本番移行時に IAM Identity Center 統合に切り替えようとすると、ユーザーマッピングの設計からやり直しになります。最初から Identity Center 統合で設計することを推奨します。

ドキュメント鮮度管理を怠る: 同期スケジュールを設定せず初回同期のみで運用すると、廃止された手順書や古い価格情報が回答に使われます。重要ドキュメントは最低でも週次で同期スケジュールを設定しましょう。

同期対象を無計画に広げる: Confluence の全スペースをインデックスに含めると、下書き・個人メモ・実験的なドキュメントが回答に混入します。品質管理ルールを設計してから同期範囲を設定します。

ユーザーマッピングを設定しない: データソース側の識別子（メールアドレス等）と IAM Identity Center の識別子が一致しないと、権限フィルタが正常に機能せず、本来参照できるはずのドキュメントが回答に含まれないといった問題が発生します。

4. Bedrock Data Automation マルチモーダル抽出

4.1 Bedrock Data Automation の概要

Bedrock Data Automation（BDA）は、ドキュメント・画像・音声・動画のマルチモーダルコンテンツから構造化データを自動抽出するマネージドサービスです。2024年末に一般提供（GA）となり、2025年に機能強化が続いています。従来の抽出ツールとの違いは、事前に定義した「Blueprint（抽出スキーマ）」に基づいて AI が柔軟に情報を抽出する点にあります。OCR やテンプレートマッチングでは対応困難な半構造・非構造データも、自然言語による指示で抽出できます。

主要なユースケース

• 請求書・契約書・申請書などのドキュメントからの構造化データ抽出
• 医療画像・製品画像からのメタデータ・ラベル抽出
• 会議録音・コールセンター音声からのトランスクリプト・サマリ生成
• 監視カメラ・商品動画からのシーン分析・オブジェクト検出

4.2 GA 状況と cross-region inference

Bedrock Data Automation は 2025年現在、クロスリージョン推論（cross-region inference）に対応しています。クロスリージョン推論では、単一のリクエストを複数リージョン（US East 1 / US West 2）の処理キャパシティに自動分散するため、処理可能なスループットが向上します。

クロスリージョン推論を利用するには、通常のリージョン固有 ARN ではなく、クロスリージョン対応のプロジェクト ARN を指定します。

import boto3
import json

client = boto3.client('bedrock-data-automation-runtime', region_name='us-east-1')

# クロスリージョン推論対応のプロジェクト ARN を使用
response = client.invoke_data_automation_async(
 inputConfiguration={
  's3Uri': 's3://my-bucket/documents/invoice_001.pdf'
 },
 outputConfiguration={
  's3Uri': 's3://my-output-bucket/results/invoice_001/'
 },
 dataAutomationConfiguration={
  'dataAutomationProjectArn': (
'arn:aws:bedrock:us:aws:data-automation-project/public-default'
  ),
  'stage': 'LIVE'
 }
)
invocation_arn = response['invocationArn']

4.3 Blueprint によるマルチモーダル抽出の設計

Blueprint は、データ抽出の「設計図」です。どのモダリティ（document / image / audio / video）から何をどの形式で抽出するかを定義します。

Standard Blueprint（public-default）

最も簡単に使い始められるのが、AWS が提供する Standard Blueprint です。

• Standard Output の ARN: arn:aws:bedrock:<REGION>:aws:data-automation-project/public-default
• ドキュメントは全テキスト抽出・表・フォーム要素を自動認識
• 画像はキャプション・ラベル・テキスト（OCR）を自動抽出
• 音声は全文トランスクリプトを生成
• 動画はシーンサマリ・コンテンツタグを生成（2025年強化）

Standard Blueprint は設定不要でいきなり使えるため、PoC や一般的なドキュメント処理には最適です。抽出項目のカスタマイズが必要な場合はカスタム Blueprint を作成します。

カスタム Blueprint の作成

bda_client = boto3.client('bedrock-data-automation', region_name='us-east-1')

# 請求書用カスタム Blueprint の作成
response = bda_client.create_blueprint(
 blueprintName='invoice-extraction-v1',
 type='DOCUMENT',
 blueprintStage='LIVE',
 schema=json.dumps({
  '$schema': 'http://json-schema.org/draft-07/schema',
  'description': '請求書から主要フィールドを抽出する',
  'type': 'object',
  'properties': {
'invoiceNumber': {
 'type': 'string',
 'description': '請求書番号（INV-XXXXXX 形式）'
},
'issueDate': {
 'type': 'string',
 'format': 'date',
 'description': '発行日'
},
'totalAmount': {
 'type': 'number',
 'description': '合計金額（税込）'
},
'vendorName': {
 'type': 'string',
 'description': '請求元の企業名'
},
'lineItems': {
 'type': 'array',
 'description': '明細行のリスト',
 'items': {
  'type': 'object',
  'properties': {
'description': {'type': 'string'},
'quantity': {'type': 'number'},
'unitPrice': {'type': 'number'},
'amount': {'type': 'number'}
  }
 }
}
  },
  'required': ['invoiceNumber', 'issueDate', 'totalAmount', 'vendorName']
 })
)
blueprint_arn = response['blueprint']['blueprintArn']

Blueprint は JSON Schema 形式で抽出スキーマを定義します。description フィールドに自然言語で抽出指示を記述することで、AI がドキュメントのさまざまなフォーマットに柔軟に対応します。

4.4 対応モダリティの詳細

ドキュメント（Document）

PDF・Word・Excel・HTML・テキストファイルに対応します。表や複数カラムのレイアウトも正確に解析します。複数ページにまたがるドキュメントにも対応し、ページ番号・ヘッダー・フッターの扱いも設定できます。

主な抽出能力:
– 構造化テキスト（段落・見出し・箇条書き）
– 表（行・列・ヘッダーを保持）
– フォーム要素（キー・バリュー形式）
– 署名・スタンプ・手書きテキスト（OCR）

画像（Image）

JPEG・PNG・TIFF・WEBP 等の画像ファイルに対応します。

主な抽出能力:
– 画像内のテキスト（OCR）
– オブジェクト・シーンの説明
– カラーパレット・画像属性
– カスタムラベル（Blueprint で定義した分類）

音声（Audio）

MP3・WAV・FLAC・M4A 等の音声ファイルに対応します。

主な抽出能力:
– 全文トランスクリプト（話者分離オプション）
– タイムスタンプ付きセグメント
– 会話のサマリ（カスタム Blueprint で指定）
– キーフレーズ・エンティティ

動画（Video）

MP4・MOV 等に加え、2025年の強化で AVI・MKV・WEBM が追加されました。コーデックは AV1・MPEG-4 Visual（MPEG-4 Part 2）にも対応しています。

4.5 video Blueprint の 2025年強化

2025年の主要な強化点の一つが、video Blueprint の拡充です。

シーンサマリ（scene summary）

動画をシーン単位で自動分割し、各シーンの内容を自然言語でサマリします。会議録画の場合は議題ごとのサマリ、製品デモ動画の場合は手順ごとのサマリが生成されます。

{
  "scenes": [
 {
"startTime": "00:00:00",
"endTime": "00:03:24",
"summary": "プレゼンターが四半期の売上目標と実績を比較説明。Q3達成率94%、Q4予測108%を報告。",
"contentTags": ["meeting", "quarterly-review", "sales"]
 },
 {
"startTime": "00:03:24",
"endTime": "00:07:51",
"summary": "マーケティング部門から新規施策の提案。SNS広告予算20%増額と効果測定KPI見直しを提案。",
"contentTags": ["meeting", "marketing", "proposal"]
 }
  ]
}

コンテンツタグ（content tag）

動画全体および各シーンに対して、内容を表すタグを自動付与します。カスタム Blueprint でタグの分類体系（taxonomy）を定義することで、自社の分類ルールに合わせたタグ付けが可能です。

オブジェクト検出（object detection）

映像内に映るオブジェクトを検出し、バウンディングボックスと出現タイムスタンプを記録します。製品の品質検査・店舗の棚割り分析・製造ラインの異常検知など、工場・小売業での活用が期待されています。

{
  "detectedObjects": [
 {
"label": "product-bottle",
"confidence": 0.97,
"firstSeen": "00:01:23",
"boundingBox": {"x": 0.32, "y": 0.45, "width": 0.18, "height": 0.41}
 }
  ]
}

4.6 Blueprint instruction optimization

2025年に追加された Blueprint instruction optimization 機能は、カスタム Blueprint の抽出指示を AI が自動的に精緻化します。

ユーザーが書いた自然言語の抽出指示（description フィールド）を分析し、曖昧な表現を明確化・補完する最適化を自動適用します。例えば「金額を抽出する」という指示に対して「税込み合計金額を数値型（小数点以下2桁）で抽出し、通貨単位を JPY と明記する」といった精緻化された指示に変換します。

# Blueprint instruction optimization を適用する際は
# DEVELOPMENT ステージで作成して検証する
response = bda_client.create_blueprint(
 blueprintName='invoice-v2-optimized',
 type='DOCUMENT',
 blueprintStage='DEVELOPMENT',
 schema=json.dumps({
  '$schema': 'http://json-schema.org/draft-07/schema',
  'type': 'object',
  'properties': {
'totalAmount': {
 'type': 'number',
 'description': '合計金額'
}
  }
 })
)

最適化結果は Blueprint バージョンとして保存され、元の指示と最適化後の指示を比較しながら検証できます。精度が向上することを確認してから LIVE ステージに昇格させます。

4.7 非同期処理と結果の取得

大量ドキュメントの処理には非同期 API を使います。

import time

# 非同期ジョブの起動
invoke_response = client.invoke_data_automation_async(
 inputConfiguration={
  's3Uri': 's3://my-bucket/invoices/batch-2025-06/'
 },
 outputConfiguration={
  's3Uri': 's3://my-output-bucket/results/batch-2025-06/'
 },
 dataAutomationConfiguration={
  'dataAutomationProjectArn': blueprint_arn,
  'stage': 'LIVE'
 }
)
invocation_arn = invoke_response['invocationArn']

# ジョブ完了確認
while True:
 status_response = client.get_data_automation_status(
  invocationArn=invocation_arn
 )
 status = status_response['status']
 if status in ['SUCCESS', 'SERVICE_ERROR', 'CLIENT_ERROR']:
  break
 time.sleep(10)

if status == 'SUCCESS':
 output_config = status_response['outputConfiguration']
 print(f"出力先: {output_config['s3Uri']}")

本番環境では EventBridge + Lambda でジョブ完了を検知する構成を推奨します。ポーリングループによるコスト・レイテンシ増加を避けられます。

4.8 出力スキーマの設計と活用パターン

BDA の出力は S3 に JSON ファイルとして保存されます。Standard Output の場合は固定スキーマ、カスタム Blueprint では自分で定義したスキーマが反映されます。

下流処理との連携

BDA の出力 JSON を Lambda でパースして DynamoDB に格納するパターンは最も一般的な構成です。

# Lambda: BDA 出力 JSON を DynamoDB に格納するパターン
import boto3
import json

s3 = boto3.client('s3')
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('InvoiceData')

def lambda_handler(event, context):
 bucket = event['detail']['bucket']['name']
 key = event['detail']['object']['key']

 obj = s3.get_object(Bucket=bucket, Key=key)
 result = json.loads(obj['Body'].read())

 table.put_item(Item={
  'invoiceNumber': result['invoiceNumber'],
  'issueDate': result['issueDate'],
  'totalAmount': result['totalAmount'],
  'vendorName': result['vendorName'],
  'lineItems': result['lineItems'],
  'sourceFile': key,
  'processedAt': context.aws_request_id
 })

マルチモーダル RAG との統合

BDA で抽出した構造化データを Bedrock Knowledge Bases に取り込むことで、マルチモーダル RAG を構築できます。動画・画像・音声のコンテンツを自然言語で検索・回答するシステムです。

例えば、製品マニュアル動画を BDA で処理してシーンサマリとコンテンツタグを抽出し、Knowledge Bases にインデックスします。「製品のネジ締め手順を教えて」という質問に対して、該当するシーンのタイムスタンプと手順説明を返す仕組みが実現できます。

4.9 本番運用のベストプラクティス

① バッチサイズの最適化

エラー時の再処理を考慮すると、50〜100 ファイル単位でバッチを区切ることを推奨します。S3 イベント通知（ObjectCreated）で 1 ファイルごとに非同期ジョブを起動するパターンも、小規模〜中規模の処理に適しています。

② Blueprint バージョン管理

Blueprint の変更は既存の出力スキーマを変えるため、下流の処理システムに影響します。変更は DEVELOPMENT ステージで検証してから LIVE に昇格させ、古いバージョンの ARN は一定期間保持することを推奨します。

③ エラーハンドリングと再処理設計

CLIENT_ERROR（入力ファイルの問題）と SERVICE_ERROR（一時的な問題）を区別し、SERVICE_ERROR のみ自動リトライする設計が重要です。リトライは指数バックオフで実施し、Dead Letter Queue（DLQ）に最終的な失敗ジョブを送信して人的対応のフローを整備します。

④ コスト最適化

BDA の料金はページ数・フレーム数・音声分数ベースです。不要なモダリティ処理を省くことでコストを削減できます。ドキュメントの表紙ページや白紙ページをスキップする前処理を組み込むことで、処理対象ページ数を削減できます。動画処理ではサンプリングレートがコストに直結するため、シーン変化の少ない動画は低フレームレートで処理することが有効です。

⑤ 精度検証のゴールデンセット設計

本番運用開始前に、ラベル付きのゴールデンセット（正解データ）を用意して Blueprint の精度を定量評価します。必須フィールドの抽出成功率・フィールド値の一致率を定期的に計測し、精度劣化を早期に検知します。

5. カスタムモデル — 蒸留・Fine-tuning・インポート

Amazon Bedrock は、基盤モデルをそのまま使う「推論専用」の利用形態に加えて、自組織のデータや要件に合わせてモデルを特化させる「カスタムモデル」の仕組みを提供しています。本章では 2025 年 5 月に GA となった Model Distillation を筆頭に、Fine-tuning・Continued Pre-training・Custom Model Import の 4 つの手法を、選定基準・実装手順・運用ポイントまで一気通貫で解説します。

5.1 Model Distillation — 2025年5月 GA の最注目機能

Model Distillation（モデル蒸留）は、大規模な teacher モデルの知識を小型の student モデルへ転送することで、精度を維持しながら推論コストと遅延を大幅に削減する手法です。2025 年 5 月 1 日に一般提供（GA）となり、Bedrock コンソールから数クリックで実行できます。

5.1.1 teacher-student 方式の仕組み

蒸留ジョブは次の 3 段階で進みます。

ステップ 1 — 訓練データの準備と合成データ拡張

入力データは プロンプトファイル（JSONL/CSV）または 既存の Bedrock 呼び出しログ（S3 バケットの Invocation Logging 出力）のいずれかを指定します。teacher モデルは入力プロンプトに対して合成レスポンスを自動生成し、最大 15,000 ペアまで訓練データを拡張します。手元に大量のラベル付きデータがない場合でも、数百件のプロンプト例を用意するだけで高品質な訓練セットを得られる点が大きな強みです。

合成データ拡張のメカニズムは以下のとおりです。まず、提供されたプロンプトを teacher が解析し、類似した難易度・スタイルのバリエーションを自動生成します。次に、各バリエーションに対して teacher がレスポンスを生成し、プロンプト＋レスポンスのペアとして記録します。この段階で品質フィルタリングが自動的に行われ、矛盾したレスポンスや品質基準を満たさないペアが除外されます。

ステップ 2 — Student Fine-tuning

合成データを使って student モデルをファインチューニングします。このステップでは teacher の出力確率分布を模倣する「soft target 蒸留」と、正解ラベルを直接学習する「hard target 蒸留」を組み合わせることで、teacher の推論パターンを効率的に転写します。

soft target 蒸留の核心は、teacher の「どれくらいの確率でこの単語が次に来るか」という確率分布そのものを学習することにあります。正解・不正解の 2 値ではなく、teacher の思考プロセスのニュアンスを丸ごと継承できるため、hard target のみの学習と比べて少ないデータ量でも高い精度を達成できます。

ステップ 3 — 評価と Provisioned Throughput デプロイ

蒸留完了後は Bedrock Evaluations で性能を検証し、合格したモデルを Provisioned Throughput に昇格させます。評価レポートには teacher との精度比較が自動的に含まれており、業務要件に対する精度劣化の許容範囲を判断できます。

5.1.2 対応モデルと性能指標

2025 年 5 月時点での対応モデルは以下のとおりです。

公開ベンチマークで確認されている効果：

• 推論速度: 最大 500% 向上（Nova Premier → Nova Pro 蒸留時）
• コスト: 最大 75% 削減（スループット単価比較）
• 精度劣化: RAG 用途で 2% 未満（teacher との正解率差）

Llama 3.2 1B/3B はエッジデプロイや低レイテンシ要件に適しており、Nova Pro は高品質・高スループットが求められるエンタープライズワークロードに向いています。teacher モデルを選ぶ際は、student の推論要件（言語・タスク種別）との相性を考慮してください。Claude 3.5 Sonnet v2 は日本語の高精度タスクに強く、Nova Premier はマルチモーダル・複合推論に優れます。

5.1.3 料金体系

蒸留ジョブの費用は次の 3 要素の合計です。

1. 合成データ生成費: Teacher モデルの通常推論単価 × 生成トークン数
2. Student Fine-tuning 費: Student モデルのファインチューニング単価 × トークン数
3. 蒸留済みモデルのストレージ料金: 月額 / モデル単位

合成データ拡張により訓練データが自動生成されるため、「データ準備工数」という隠れたコストを大幅に削減できます。総所有コスト（TCO）を計算する際は、推論単価の削減幅と蒸留ジョブの初期コストを比較し、損益分岐点（通常 2〜4 週間の推論で回収）を見積もることを推奨します。

5.1.4 本番運用のベストプラクティス

蒸留モデルを本番投入する前に、以下のチェックポイントを確認してください。

データ品質の確保

訓練プロンプトは実際の本番クエリ分布を反映していることを確認します。特定のトピックや難易度に偏ったデータセットは、未見ドメインでの性能低下を招きます。本番ログの分析でクエリの分布を把握し、長さ・複雑さ・トピックが均衡したプロンプトセットを準備してください。

合成データの品質検証

Teacher の合成レスポンスをサンプリングして人手でレビューし、事実誤認や指示無視がないことを確認します。特に、事実性が重要なユースケース（法律・医療・財務）では、ドメインエキスパートによるレビューを必ず実施してください。

段階的なトラフィック切替

A/B テストまたは加重ルーティング（Bedrock のインファレンスプロファイル）を使い、10% → 50% → 100% の段階で蒸留モデルへ切り替えます。各段階で評価メトリクスが目標値を満たしていることを確認してから次の段階に進んでください。

評価メトリクスの継続監視

本番投入後も ROUGE スコア・ユーザー評価・エラー率を定期的に収集し、性能劣化を早期検知します。ベースモデルの更新（新バージョン公開）に合わせて定期的に再蒸留し、最新の知識を反映させることを推奨します。

5.2 Fine-tuning — ラベル付きデータによる専門特化

Fine-tuning はラベル付きの入出力ペア（教師あり学習データ）を用いてモデルを特定タスクに最適化する手法です。蒸留と異なり、teacher モデルは不要で、自組織が保有する正解データをそのまま活用できます。

5.2.1 データフォーマット

Bedrock Fine-tuning では JSONL 形式（1 行 1 レコード）を使用します。

{"prompt": "次の顧客レビューをポジティブ/ネガティブ/中立で分類してください:\n\n配送が早く品質も良かった。", "completion": "ポジティブ"}
{"prompt": "次の顧客レビューをポジティブ/ネガティブ/中立で分類してください:\n\n説明と違う商品が届いた。", "completion": "ネガティブ"}

推奨データ量は 最低 100 件ですが、高精度が要求される分類・抽出タスクでは 1,000 件以上を目標にします。データは S3 に配置し、ジョブ作成時にバケット ARN を指定します。訓練データの 80/20 分割（訓練：検証）を設定することで、過学習を早期に検知できます。

5.2.2 対応モデルとハイパーパラメータ

2025 年時点では Amazon Nova シリーズが Bedrock Fine-tuning に対応しています。調整可能なハイパーパラメータは以下のとおりです。

ハイパーパラメータの探索は小規模ジョブ（データ 20% サンプル）で先行して行い、最良の組み合わせで本ジョブを実行することで、コストと時間を節約できます。学習率が高すぎると過学習・収束不安定が生じ、低すぎると収束が遅くなります。まず学習率 2e-5・エポック 3 回を基準として調整することを推奨します。

5.2.3 Fine-tuning が有効なユースケース

Fine-tuning は次のようなシナリオで特に効果を発揮します。

社内分類・タグ付けの自動化

製品カテゴリ分類、サポートチケットのルーティング、法的文書のリスク分類など、特定の分類体系が固定されているタスクでは Fine-tuning により高精度・低レイテンシ・低コストの三拍子を揃えられます。

構造化データ抽出

請求書・契約書からの特定フィールド抽出（日付・金額・当事者名など、フィールド名が固定されている場合）では、Few-shot プロンプトよりも Fine-tuning の方が安定した精度を発揮します。

社内スタイル・フォーマットへの適合

社内報告書フォーマット、特定の文体・語調への変換、競合他社の製品名の言い換えルールなど、「社内ルールに従った変換」は Fine-tuning が最も費用対効果の高い手法です。

ドメイン固有の回答精度向上

医療・法律・金融など専門用語が多く、汎用モデルの誤答率が高いドメインでは Fine-tuning 後のモデルが顕著な精度向上を見せます。ただし、Fine-tuning は「既知の知識を特定形式で出力する能力」を高めるものであり、「モデルが全く知らない事実を学習させる」目的には向きません。後者には Continued Pre-training が適しています。

5.2.4 運用上の注意点

Fine-tuning 済みモデルは Provisioned Throughput でのみデプロイ可能です。オンデマンド推論に比べてコストが高くなるため、推論ボリュームが一定以上（通常は月間数百万トークン以上）ある場合に採算が合います。トラフィックが少ない段階では、まず Prompt Engineering や RAG で対応し、改善が頭打ちになった段階で Fine-tuning を検討することを推奨します。

5.3 Continued Pre-training — ドメイン知識の基盤注入

Continued Pre-training（継続事前学習）は、ラベルなしのテキストデータを使ってモデルに新しい知識を追加する手法です。Fine-tuning とは異なり、入出力ペアではなく生テキスト（業界レポート・社内技術文書・規制文書・製品マニュアルなど）を学習させます。

5.3.1 適用シナリオ

• 専門用語・概念の習得: 汎用モデルが知らない業界固有用語（金融商品名、医薬品名、社内システム名）をモデルに認識させる
• 社内ナレッジの内在化: 外部に公開できない社内文書をモデルに直接学習させる（RAG では検索漏れが生じやすい密度の高い知識）
• 特定言語・方言への対応: 汎用モデルでは十分に対応できない地域言語や専門語彙

5.3.2 データ準備のポイント

Continued Pre-training では以下の形式でデータを準備します。

• フォーマット: プレーンテキスト（UTF-8）、1 ファイルあたり推奨 10MB 以下
• 品質基準: 文法的に正しい文章のみ使用し、OCR エラー・HTML タグ・記号の羅列などノイズを除去する
• 多様性: 異なる著者・文体・時期のドキュメントを混在させることで汎化性能が向上する
• 量: ドメインの広さに応じて数 MB〜数 GB が目安

5.3.3 セキュリティ: CMK 対応

Continued Pre-training ではカスタマーマネージドキー（CMK）による暗号化に対応しています。機密性の高い社内文書を学習データに使う場合でも、AWS Key Management Service（KMS）で管理するキーで訓練データおよびモデルウェイトを保護できます。CMK を使用する場合は、Bedrock サービスプリンシパルへの適切なキーポリシー付与が必要です。

{
  "Effect": "Allow",
  "Principal": {
 "Service": "bedrock.amazonaws.com"
  },
  "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
  "Resource": "*",
  "Condition": {
 "StringEquals": {
"kms:ViaService": "bedrock.ap-northeast-1.amazonaws.com"
 }
  }
}

5.3.4 Continued Pre-training と Fine-tuning の使い分け

Continued Pre-training は「モデルが知らないことを知らせる」、Fine-tuning は「モデルが知っていることを特定タスクに最適化する」と整理すると分かりやすいです。実運用では両者を組み合わせることが多く、まず Continued Pre-training で業界知識を注入してから Fine-tuning でタスク特化するパイプラインが有効です。

5.4 Custom Model Import — 既存モデルウェイトの持ち込み

Custom Model Import は、外部で訓練済みのモデルウェイトを Bedrock に取り込む機能です。Hugging Face や社内の GPU クラスターで Fine-tuning したモデルを、Bedrock のフルマネージド推論基盤で運用できます。

5.4.1 対応アーキテクチャ

2025 年時点で対応しているモデルアーキテクチャは次のとおりです。

モデルウェイトは SafeTensors または PyTorch（bin） フォーマットに対応しています。量子化（4-bit/8-bit）済みウェイトはサポート対象外であるため、フルプレシジョン（FP32）またはハーフプレシジョン（FP16/BF16）のウェイトを用意してください。

5.4.2 インポート手順

1. S3 へのウェイトアップロード: モデルウェイトファイルを指定の S3 バケットに配置する。ファイルサイズが大きい（数十 GB 以上）場合は AWS Transfer Family または S3 マルチパートアップロードを使用する
2. インポートジョブの作成: Bedrock コンソールまたは API でジョブを作成し、S3 パスとアーキテクチャを指定する
3. インポート完了の確認: ジョブが Completed になるとモデル ARN が払い出される（所要時間はモデルサイズに依存し、7B パラメータで概ね 20〜40 分）
4. Provisioned Throughput へのデプロイ: 払い出されたモデル ARN を使って推論ユニットを購入する

5.4.3 ユースケース

• 社内 GPU で Fine-tuning 済みモデルの本番化: 研究・開発段階で GPU クラスターを使って高品質な Fine-tuning を行い、本番推論は Bedrock のフルマネージド基盤に移行してインフラ管理コストを削減する
• オープンソースモデルの活用: Hugging Face 上の特定タスク向けモデル（法律文書解析 Fine-tuning 済み Llama 3 など）を Bedrock でホスティングする
• コンプライアンス要件対応: モデル訓練は自社管理環境で実施し、推論のみを AWS マネージドサービスに委ねることでデータの流通経路を限定する

5.5 評価・デプロイ — Bedrock Evaluations × Provisioned Throughput

カスタムモデルは訓練後にそのまま本番投入するのではなく、Bedrock Evaluations で品質を検証してから Provisioned Throughput でデプロイするフローが推奨されます。

5.5.1 Bedrock Evaluations の活用

Bedrock Evaluations は、モデルの品質を定量的に評価するフルマネージドサービスです。カスタムモデルの評価では次のモードが特に有効です。

LLM-as-Judge 評価

別の高品質モデル（例: Claude 3.5 Sonnet）を審判として使い、カスタムモデルの回答の「流暢さ」「正確性」「有用性」「安全性」を自動採点します。人手評価に近い品質を大規模に実現できるため、A/B テストや定期的なモデル品質監視に適しています。評価結果は CSV レポートとして出力され、統計的な比較が容易です。

カスタムメトリクス

タスク固有の評価基準（例: 抽出フィールドの完全一致率、要約の ROUGE-L スコア、コード生成の実行成功率）を定義して評価できます。ビジネス要件に直接対応したメトリクスを設定することで、「技術的には高精度だが、ビジネス要件を満たさない」という見落としを防げます。

評価セットの設計指針

評価セットは訓練データと重複しないホールドアウトデータから構成してください。また、境界ケース（曖昧な入力、長い入力、多言語混在など）を意図的に含めることで、実際の本番環境での挙動をより正確に予測できます。評価セットのサイズは最低 200 件、精度要件の高いユースケースでは 1,000 件以上を推奨します。

5.5.2 Provisioned Throughput によるデプロイ

Fine-tuning・蒸留・インポートのいずれで作成したカスタムモデルも、本番デプロイには Provisioned Throughput を使用します。

Provisioned Throughput の仕組み

Provisioned Throughput は、一定のモデルユニット（MU）数を事前予約することで、安定したスループットとレイテンシを保証する仕組みです。料金は時間単位（時間 × MU 数）で課金されます。予約期間は「なし（月単位自動更新）」「1 ヶ月」「6 ヶ月」から選択でき、長期契約ほど単価が割安になります。

容量計画の目安

1 MU あたりの処理能力はモデルサイズに依存しますが、一般的に Nova Pro 1 MU ≈ 1,000 トークン/秒程度を目安にします。ピーク時のリクエスト量とトークン長から必要 MU 数を見積もり、余裕を持ったキャパシティを確保してください。

デプロイのベストプラクティス

• 段階的スケールアップ: まず最小 MU 数でデプロイし、負荷テスト後に MU 数を調整する
• フォールバック先の確保: カスタムモデルが不安定な場合にベースモデルへ自動切り替えするロジックをアプリケーション層で実装する
• バージョン管理: 複数バージョンのカスタムモデルを Provisioned Throughput に同時デプロイし、段階的なロールアウトを行う

5.6 カスタムモデルのライフサイクル管理

本番稼働後のカスタムモデルは、静的な資産ではなく継続的にメンテナンスが必要な動的な資産です。以下のライフサイクル管理プロセスを組織標準として確立することを推奨します。

5.6.1 定期再訓練のスケジューリング

カスタムモデルの品質はデータドリフト（本番データの分布が訓練時から変化する現象）により時間と共に低下します。以下のトリガーのいずれかが発生したタイミングで再訓練を検討してください。

• 性能メトリクスの劣化: 定期評価で精度が基準値（例: teacher との差が 5%超）を下回った
• ビジネスドメインの変化: 製品ラインナップ変更・規制改定・新しい社内用語の導入
• ベースモデルの新バージョン公開: teacher モデルが更新され、より高品質な合成データが生成可能になった
• 訓練データの蓄積: 本番ログが一定量（通常 3〜6 ヶ月分）蓄積され、より本番分布に近い訓練データが得られるようになった

5.6.2 バージョン管理とロールバック

複数バージョンのカスタムモデルを並行で Provisioned Throughput にデプロイし、段階的なトラフィック切替を行います。新バージョンへの移行後に性能問題が発生した場合でも、旧バージョンの Provisioned Throughput が残っていればアプリケーション側のエンドポイント切替だけで即時ロールバックできます。完全移行を確認してから旧バージョンの Provisioned Throughput を解放することで、ロールバックリスクを排除します。

5.6.3 コンプライアンスと監査ログ

カスタムモデルの訓練・評価・デプロイの各イベントは CloudTrail に記録されます。特に個人情報や機密データを訓練データに使用した場合は、データ利用の法的根拠・データ保管期間・モデル削除方針を文書化し、定期的な内部監査の対象に含めてください。Bedrock の Invocation Logging を有効化することで、カスタムモデルへの全推論リクエストと応答を S3 に記録でき、品質問題の事後調査と規制対応の両方に活用できます。

6. コスト・ガバナンス・監視

本章では、Amazon Q・Data Automation・カスタムモデルを本番運用するうえで必須となるコスト管理・ガバナンス・監視の実践方法を解説します。各サービスの料金体系を正確に把握した上で、管理コンソールと CloudWatch を活用した可視化・最適化の手順を示します。

6.1 Amazon Q Developer 料金

Amazon Q Developer は Free Tier と Pro Tier の 2 段階で提供されています。組織への導入を検討する際は、まず Free Tier で効果を検証し、利用率が高まったら Pro Tier へ移行するアプローチが一般的です。

6.1.1 Free Tier

Free Tier は AWS アカウントに紐付いており、クレジットカードの登録は不要です。個人開発・学習目的の用途に適しています。IDE プラグインをインストールし、AWS Builder ID（無料）でサインインするだけで利用を開始できます。

6.1.2 Pro Tier

Pro Tier は ユーザー 1 名あたり月額 19 ドル（年額払い時は月額 15 ドル）です。

組織導入では、全開発者への一括 Pro Tier ライセンス付与と管理者による Admin Console 管理が標準的なパターンです。Pro Tier では特に「セキュリティスキャン自動化」と「エージェンティックコーディング無制限」の価値が高く、これらを積極活用することで投資回収を早められます。

6.1.3 カスタマイズ（追加料金）

既存のコードリポジトリを Q Developer に学習させる「カスタマイズ」機能には、参照データ取り込み（データ量に応じた従量課金）とカスタマイズモデルのホスティング（月額固定費）の追加料金が発生します。カスタマイズは、社内フレームワーク・命名規則・コーディング規約が多い大規模組織で ROI が高くなります。

6.2 Amazon Q Business 料金

Amazon Q Business はエンタープライズ向けで、アクティブユーザー数に基づく月額課金です。月内に 1 回以上 Q Business にアクセスしたユーザーが「アクティブユーザー」としてカウントされます。

6.2.1 料金体系

6.2.2 データソースコネクタの追加費用

Q Business の利用コストはユーザーライセンス費だけではありません。データソースコネクタによるインデックス作成・同期にも費用が発生します。

• ドキュメントインデックス作成: ページ単位の従量課金
• 同期（差分更新）: 同期対象ドキュメント数に応じた課金
• Enterprise Edition ナレッジベース: 月額固定費 + 検索クエリ数に応じた従量課金

データソースが多く、ドキュメントが大量にある場合はインデックス作成コストが無視できない水準になるため、事前にデータ量を把握して見積もりを立ててください。

6.2.3 コスト削減のポイント

• 段階的展開: パイロット部署（50〜100 ユーザー）から開始し、利用率・ROI を測定してから全社展開する
• Lite/Pro の使い分け: 高度なワークフロー自動化が不要なユーザーは Lite プランで十分な場合が多い（管理部門など）
• アイドルユーザーの棚卸し: 月次でアクティブユーザー数を確認し、未使用アカウントのライセンスを解除する
• 同期スケジュールの最適化: 変更頻度の低いデータソースは週次同期に変更し、差分更新コストを削減する

6.3 Bedrock Data Automation 料金

Bedrock Data Automation は処理したコンテンツ量に基づく従量課金です。事前のキャパシティ予約は不要で、処理量に応じてスケールします。

6.3.1 ドキュメント・画像処理

Standard Output（事前定義済みスキーマ）とカスタムブループリント（Custom Blueprint）では単価が異なります。カスタムブループリントは Blueprint Instruction Optimization（自然言語による指示の自動精緻化）の処理分が追加コストとして発生します。

6.3.2 動画・音声処理

動画処理ではサンプリングレートがコストに直結します。シーン変化の少ないコンテンツ（会議録画など）は低フレームレートで処理することでコストを最適化できます。具体的には、1fps（1秒1フレーム）と 5fps では最大 5 倍のコスト差が生じるため、コンテンツの特性に応じてフレームレートを調整してください。

6.3.3 Data Automation コスト最適化

• ブループリントの精緻化: 必要なフィールドのみ抽出するブループリント設計でトークン消費を最小化する。使用しないフィールドを抽出対象から除外するだけで 20〜40% のコスト削減が見込める
• バッチ処理の活用: リアルタイム性が不要なワークロードは S3 バッチ処理でまとめて実行し、オフピーク時間帯に集中させる
• Standard Output の優先使用: カスタム抽出が不要なドキュメントは Standard Output を使い、カスタムブループリントの追加コストを回避する
• サンプリング検証の先行実施: 本番処理の前に 100 件程度のサンプルで精度と単価を確認し、想定外のコストが発生しないことを確認する

6.4 カスタムモデル 料金

カスタムモデルの費用は「訓練コスト」「ストレージコスト」「推論コスト（Provisioned Throughput）」の 3 層で構成されます。それぞれを正確に把握した上で、ベースモデルのオンデマンド推論との損益分岐点を計算することが重要です。

6.4.1 訓練コスト

Fine-tuning・Continued Pre-training の訓練コストは、通常の推論コストと比較して高単価（数〜数十倍）です。しかし、一度訓練すれば以後の推論を低コストで行えるため、長期的には十分な投資回収が見込めます。

6.4.2 ストレージコスト

Fine-tuning・蒸留・インポートで作成したカスタムモデルウェイトは Bedrock が管理するストレージに保存され、月額 × モデル件数で課金されます。使用していないカスタムモデルは定期的に棚卸しして削除することでストレージコストを抑制します。実験段階で作成した試行錯誤モデルが残り続けることが多いため、月次での棚卸しルーティンを設けることを推奨します。

6.4.3 推論コスト（Provisioned Throughput）

カスタムモデルの推論は Provisioned Throughput 経由のため、モデルユニット（MU）数 × 時間で課金されます。

コスト比較の考え方

蒸留後の小型モデルは、ベースモデルと比較して同等タスクで最大 75% のコスト削減が可能です。ただし Provisioned Throughput の固定コストが発生するため、推論量が少ない場合はベースモデルのオンデマンド推論の方がトータルコストが低くなります。

損益分岐点の計算式：

損益分岐点（月間トークン数）=
  蒸留ジョブ総コスト ÷ (ベースモデル単価 - カスタムモデルPT単価)

この計算で損益分岐点を超える推論量が見込める場合にのみ、カスタムモデル化を進めてください。

6.5 ガバナンス — 管理コンソールとポリシー管理

エンタープライズ規模で複数の Amazon Q・Bedrock サービスを展開する際は、管理コンソールと AWS Organizations によるガバナンス体制を整備することが重要です。

6.5.1 Amazon Q Developer 管理コンソール

Q Developer の Pro Tier では、組織管理者が管理コンソールにアクセスして以下を一元管理できます。

ユーザー・ライセンス管理

IAM Identity Center と連携してシングルサインオン（SSO）を構成し、組織のユーザーディレクトリと紐付けます。部署・チーム単位でライセンス割り当てポリシーを設定し、月次アクティブユーザーレポートで未使用ライセンスを特定します。

機能ポリシーの設定

コード補完のスコープ（ローカルコードのみ / クラウド連携 / 外部コンテキスト許可）を組織全体で統制します。カスタマイズ機能の使用可否を部署レベルで制御し、セキュリティスキャンの自動化設定（Pro Tier では PR 作成時の自動トリガーが可能）を組織標準として展開します。

利用状況の可視化

管理コンソールでは、部署別・ユーザー別のコード補完採用率・セキュリティ検出件数・コード変換実績をダッシュボードで確認できます。この利用状況データは ROI 計算と継続投資判断の根拠として活用します。

6.5.2 Amazon Q Business 管理

Q Business の管理者は以下の設定を定期的にレビューします。

データソースコネクタのポリシー設定

• 各コネクタの同期スケジュール（毎時 / 日次 / 週次）を業務要件に合わせて設定する
• ドキュメントレベルのアクセス制御（ACL）クロールが正しく動作していることを月次で確認する
• 機密データを含むデータソースは必要最小限の範囲のみ同期対象にする

ユーザーアクセス制御

IAM Identity Center の Trusted Identity Propagation を使い、Q Business へのアクセスを組織のグループ・ロールで制限します。Q Business の回答に使用するデータソースを、アクセス権を持つユーザーのみが参照できるよう ACL を継続的に同期させてください。特に、組織変更（異動・退職）のタイミングでのアクセス権棚卸しを徹底することが重要です。

6.5.3 AWS Organizations によるサービス制御

組織全体の Bedrock 利用をガバナンスするには、サービスコントロールポリシー（SCP）を使います。

よく使われる SCP パターン

• 特定リージョンのみ Bedrock 利用を許可する（例: ap-northeast-1 のみ）
• 承認済みモデル ID のみ呼び出しを許可し、未承認モデルの利用を組織レベルでブロックする
• Fine-tuning・蒸留ジョブは指定の Organizational Unit のアカウントのみ実行可能にする
• Bedrock Invocation Logging の無効化を禁止する（監査証跡の保全）

Bedrock ガードレール（Guardrails）によるコンテンツ制御

AWS Bedrock Guardrails を使うと、モデルへの入力と出力を組織ポリシーに従ってフィルタリングできます。禁止ワード・センシティブデータ（PII）の検出と除去・有害コンテンツのブロックを一元設定し、すべての Bedrock 呼び出しに自動適用することで、コンテンツポリシーの一貫した適用が可能になります。

6.6 CloudWatch による監視

Bedrock・Amazon Q・Data Automation の各サービスは CloudWatch にメトリクスを発行します。本番運用では以下のメトリクスを監視ダッシュボードに統合し、異常を早期検知します。

6.6.1 Amazon Q Developer メトリクス

管理コンソールのレポートに加えて、CloudWatch では次のメトリクスが参照可能です。

採用率の低下が継続する場合は、提案品質の問題を示している可能性があります。カスタマイズ設定やプロンプトエンジニアリングの見直しを検討してください。

6.6.2 Amazon Q Business メトリクス

DataSourceSyncErrors が連続して発生する場合は、コネクタの IAM 権限・ネットワーク接続・接続先サービスの変更（API 仕様変更など）を順に確認してください。

6.6.3 Bedrock Data Automation メトリクス

BlueprintExtractionAccuracy は組み込みメトリクスとしては提供されていないため、ゴールデンセット評価を定期的に実施してカスタムメトリクスとして CloudWatch に記録する実装を推奨します。

6.6.4 カスタムモデル / Provisioned Throughput メトリクス

ダッシュボード構成例

CloudWatch ダッシュボードに「サービス健全性」「コスト実績」「品質トレンド」の 3 タブを設けることを推奨します。

• サービス健全性タブ: レイテンシ・エラー率・スロットリングのリアルタイムグラフ
• コスト実績タブ: 日次トークン消費量・Cost Explorer との連携グラフ
• 品質トレンド タブ: Q Developer 採用率・Q Business 回答満足度・カスタムモデル評価スコアの月次推移

6.7 コスト最適化戦略

6.7.1 用途別モデル選択による最適化

「全クエリを最高性能モデルで処理する」アプローチはコスト効率が悪く、本番運用では用途に応じたモデルの使い分けが重要です。

インテリジェントなモデルルーティング（クエリの複雑さに応じてモデルを動的に切り替える）を実装することで、コストと品質のバランスを最適化できます。簡単なクエリはコストの低い小型モデルへ、複雑なクエリは大型モデルへルーティングするだけで、平均推論コストを 30〜50% 削減した実績があります。

6.7.2 蒸留によるコスト削減実例

Before（蒸留前）

社内 FAQ 回答用途（月間 500 万クエリ × 平均 500 トークン / クエリ）を Nova Premier のオンデマンド推論で処理するケースを考えます。月間約 25 億トークンの処理となり、推論コストは大きな固定費となります。

After（蒸留後）

Nova Premier から Nova Pro へ蒸留し、Provisioned Throughput でデプロイした場合：

• 推論コスト: 最大 75% 削減
• 精度劣化: RAG 評価で 1.8%（許容範囲内）
• 蒸留ジョブ回収期間: 約 3 週間

この例では蒸留の初期投資（合成データ生成 + Fine-tuning 費）を 3 週間以内に回収し、それ以降は継続的なコスト削減効果が得られます。推論量が多いユースケースほど蒸留の ROI が高くなります。

6.7.3 Batch Inference の活用

リアルタイム応答が不要なワークロード（夜間バッチ・定期レポート生成・大量ドキュメントの一括翻訳など）は Bedrock Batch Inference を使うことで、オンデマンド推論と比較して最大 50% のコスト削減が可能です。

Batch Inference は S3 の入力ファイル（JSONL 形式）を処理し、結果を S3 に書き出します。処理完了の EventBridge 通知を受け取ってから結果を参照する設計とすることで、ポーリングによるコスト・複雑性を排除できます。

6.7.4 タグベースのコスト配賦

複数の部署・プロジェクトが Bedrock を利用する場合、AWS Cost Allocation Tags を活用してコストを部署別に可視化します。Bedrock の呼び出し時に Department・Project・Environment などのタグを付与し、月次の Cost Explorer レポートで部署別コストを自動集計する運用を構築してください。

チャージバックや予算管理の精度向上に加え、「コストの大半を占めるプロジェクト」を特定して蒸留・最適化の優先候補を絞り込む際にも有効です。

7. 実戦統合パターン

前章まででカバーしてきた Amazon Q・Data Automation・カスタムモデルを「単独」で動かすことはできるようになった。本章では、それらを「組み合わせる」ときのアーキテクチャ選択と実装ポイントを解説する。本番でインパクトが大きい4パターンを取り上げる。

7-1 Q Business + Bedrock Knowledge Bases 統合

Amazon Q Business のコネクタ層（Confluence・Teams・SharePoint 等）と Bedrock Knowledge Bases のベクトル検索層を組み合わせると、社内ドキュメント全体を横断する高精度 RAG が構築できる。Q Business がユーザー認証・アクセス制御・チャット UI を担い、Knowledge Bases が検索エンジンを担う分業がポイントになる。

RetrieveAndGenerate API

Knowledge Bases が提供する RetrieveAndGenerate API は、クエリの埋め込み→チャンク検索→LLM 応答生成を 1 回の API 呼び出しで完結させる end-to-end のエンドポイント。個別に実装すると 3 ステップ必要な処理を 1 コールで済ませられるため、まず試すべき出発点になる。

import boto3

client = boto3.client('bedrock-agent-runtime', region_name='us-east-1')

response = client.retrieve_and_generate(
 input={
  'text': '社内の製品仕様書から最新のAPIレート制限を教えてください'
 },
 retrieveAndGenerateConfiguration={
  'type': 'KNOWLEDGE_BASE',
  'knowledgeBaseConfiguration': {
'knowledgeBaseId': 'XXXXXXXXXXXX',
'modelArn': (
 'arn:aws:bedrock:us-east-1::foundation-model/'
 'anthropic.claude-3-5-sonnet-20241022-v2:0'
),
'retrievalConfiguration': {
 'vectorSearchConfiguration': {
  'numberOfResults': 10
 }
}
  }
 }
)

print(response['output']['text'])
for citation in response.get('citations', []):
 refs = citation.get('retrievedReferences', [])
 if refs:
  uri = refs[0]['location']['s3Location']['uri']
  print(f"  参照元: {uri}")

アプリケーションで「どのドキュメントに基づいて回答したか」を表示するには citations フィールドを使う。S3 URI だけでなくページ番号や抜粋テキストも返るので、エンドユーザーが出典を確認できる UI を実装しやすい。

マルチモーダル検索

Knowledge Bases のマルチモーダル検索では、テキストだけでなく画像・図表を含むドキュメントを横断検索できる。Data Automation で前処理した画像キャプションや OCR 結果をベクトルストアに格納することで、「アーキテクチャ図に含まれる VPC 構成を探す」といったクエリにも対応する。

# ハイブリッド検索（ベクトル + キーワード）を指定
response = client.retrieve(
 knowledgeBaseId='XXXXXXXXXXXX',
 retrievalQuery={
  'text': '技術アーキテクチャ図に含まれるVPC構成を探す'
 },
 retrievalConfiguration={
  'vectorSearchConfiguration': {
'numberOfResults': 5,
'overrideSearchType': 'HYBRID'
  }
 }
)

for result in response['retrievalResults']:
 score = result.get('score', 0)
 uri = result['location']['s3Location']['uri']
 print(f"  スコア: {score:.3f} | {uri}")

S3 Vectors: 最大 90% コスト削減

2025 年に一般提供 (GA) となった S3 Vectors は、S3 に直接ベクトルを格納する新しいオプション。従来の OpenSearch Serverless と比較すると、スループット課金モデルが不要で大幅にコストを削減できる。

Knowledge Base 作成時に S3_VECTORS を指定するだけで切り替えられる。

bedrock_agent = boto3.client('bedrock-agent')

response = bedrock_agent.create_knowledge_base(
 name='my-kb-s3vectors',
 roleArn='arn:aws:iam::123456789012:role/BedrockKBRole',
 knowledgeBaseConfiguration={
  'type': 'VECTOR',
  'vectorKnowledgeBaseConfiguration': {
'embeddingModelArn': (
 'arn:aws:bedrock:us-east-1::foundation-model/'
 'amazon.titan-embed-text-v2:0'
)
  }
 },
 storageConfiguration={
  'type': 'S3_VECTORS',
  's3VectorsConfiguration': {
'vectorBucketArn': (
 'arn:aws:s3express:us-east-1::bucket/'
 'my-vectors--use1-az6--x-s3'
)
  }
 }
)

構造化データ NL2SQL

Q Business の構造化データコネクタを使うと、ユーザーが「先月の売上トップ10製品を教えて」と入力するだけで内部的に SQL が生成・実行される。BI ツールの操作方法を覚えなくても、自然言語でデータベースを照会できる環境が整う。

ベクトルストア選択の判断指針:

• Aurora (pgvector): 既存 RDS を活用したい / PostgreSQL 運用チームが管理
• OpenSearch Serverless: 全文検索とベクトル検索を組み合わせる
• Neptune Analytics: グラフ関係（組織図・知識グラフ）を活用する RAG
• MongoDB Atlas: MongoDB 運用チームが引き続き管理したい場合
• Pinecone: マネージドベクトル DB を社外で使う場合
• Redis Enterprise Cloud: レイテンシが最優先（ミリ秒以下が必要）
• Kendra: ドキュメント検索の精度・再現率を特に重視する場合

7-2 Q Developer + Bedrock 組み合わせ

Amazon Q Developer と Bedrock の役割分担は明確だ。Q Developer は「開発者がコードを書く作業」を加速し、Bedrock は「アプリが実行時に呼び出す AI バックエンド」を担う。この二層構造を意識すると、プロジェクト全体の生産性が大きく変わる。

IDE 内コード生成 → Bedrock バックエンド処理パターン

開発フェーズ (VS Code / JetBrains)
  ↓ Q Developer
  - インラインコード補完
  - チャットでのアーキテクチャ相談
  - エージェンティックコーディング（ファイル生成・テスト実行）
  - セキュリティスキャン（コミット前に自動検出）

本番実行フェーズ
  ↓ 生成されたアプリケーションコード
  - Bedrock Converse API → チャット / 対話処理
  - Bedrock Agents → 複数ステップのタスク自動化
  - Knowledge Bases → RAG 検索
  - Data Automation → ドキュメント解析パイプライン

エージェンティックコーディング × Bedrock Agents

Q Developer のエージェンティックモードは、ターミナルコマンド実行・ファイル生成・テスト実行まで自律的に行う。この動作モデルは Bedrock Agents の設計思想（計画→アクション→観察→再計画）と相性がよく、「Q Developer に Bedrock Agents のコードを書かせ、そのエージェントが本番で別の Bedrock タスクを実行する」という二層構造が自然に組み立てられる。

# Q Developer が生成するサンプルコード: Lambda から Bedrock Agent を非同期呼び出し
import boto3

def invoke_bedrock_agent(session_id: str, input_text: str) -> str:
 client = boto3.client('bedrock-agent-runtime', region_name='us-east-1')

 full_response = ""
 response = client.invoke_agent(
  agentId='XXXXXXXXXX',
  agentAliasId='XXXXXXXXXX',
  sessionId=session_id,
  inputText=input_text
 )

 for event in response['completion']:
  if 'chunk' in event:
full_response += event['chunk']['bytes'].decode('utf-8')

 return full_response

Q Developer セキュリティスキャン + Bedrock コードレビュー二段構成

Q Developer の組み込みセキュリティスキャン（十数言語・数千の detector）で脆弱性を検出した後、Bedrock でリファクタリング提案を生成する二段構成が効果的だ。セキュリティチームが Q Developer レポートをレビューし、開発者は Bedrock から生成された修正コードをそのまま適用できるワークフローになる。

Pro Tier では、コミット時に自動スキャンが走り、問題があればプルリクエストにインラインコメントが付く。Free Tier では手動トリガーが必要なため、CI パイプラインへの組み込みを検討するとよい。

7-3 Data Automation + Knowledge Bases マルチモーダル RAG

非構造化データの宝庫である PDF・画像・動画・音声を統合して自然言語検索するパターン。Data Automation が前処理（構造化・テキスト化）を担い、Knowledge Bases が検索を担う役割分担になる。

全体フロー

非構造化データ (S3)
 │
 ▼
Bedrock Data Automation
 ├── ドキュメント: テキスト/表/図を Markdown + JSON に変換
 ├── 画像: キャプション生成 + オブジェクト検出 → テキスト化
 ├── 音声: 文字起こし + 章分け → テキスト化
 └── 動画: シーンサマリー + コンテンツタグ → テキスト化
 │
 ▼
S3 (構造化出力バケット)
 │
 ▼
Bedrock Knowledge Bases (ingestion job)
 ├── チャンキング（固定/セマンティック/ヒエラルキー）
 ├── 埋め込み生成 (Titan Embed Text v2)
 └── ベクトルストア格納
 │
 ▼
RetrieveAndGenerate API
 ◀── ユーザーの自然言語クエリ
 ──▶ 回答 + 出典 (S3 URI / ページ番号)

実装: Data Automation 出力を Knowledge Bases に連携

import boto3
import time

da_client = boto3.client('bedrock-data-automation-runtime', region_name='us-east-1')
agent_client = boto3.client('bedrock-agent', region_name='us-east-1')

# Step 1: Data Automation で文書を処理
da_response = da_client.invoke_data_automation_async(
 inputConfiguration={
  's3Uri': 's3://my-source-bucket/docs/technical-spec.pdf'
 },
 outputConfiguration={
  's3Uri': 's3://my-kb-input-bucket/processed/'
 },
 dataAutomationConfiguration={
  'dataAutomationProjectArn': (
'arn:aws:bedrock:us-east-1:123456789012:'
'data-automation-project/my-project'
  )
 }
)
invocation_arn = da_response['invocationArn']

# Step 2: 完了を待機（本番では EventBridge + Lambda でイベント駆動化）
while True:
 status_resp = da_client.get_data_automation_status(
  invocationArn=invocation_arn
 )
 status = status_resp['status']
 if status == 'SUCCESS':
  break
 if status in ('FAILED', 'SERVICE_ERROR'):
  raise RuntimeError(f"Data Automation failed: {status}")
 time.sleep(10)

# Step 3: Knowledge Bases の ingestion job をトリガー
sync_response = agent_client.start_ingestion_job(
 knowledgeBaseId='XXXXXXXXXXXX',
 dataSourceId='XXXXXXXXXXXX'
)
print(f"Ingestion job: {sync_response['ingestionJob']['ingestionJobId']}")

Blueprint カスタマイズで抽出精度を上げる

標準の Blueprint は汎用的な出力に留まるが、業務特有のフィールド構造を定義したカスタム Blueprint を使うと、請求書・契約書・仕様書それぞれに最適化した抽出ができる。

# カスタム Blueprint: 請求書から必要フィールドだけを抽出
blueprint_schema = {
 "blueprintSchema": {
  "type": "object",
  "properties": {
"invoice_number": {
 "type": "string",
 "description": "請求書番号。例: INV-2025-001234。ページ上部の番号欄から取得"
},
"total_amount": {
 "type": "number",
 "description": "税込の合計請求金額（円）。例: 110000。ページ右下の「ご請求金額」欄"
},
"invoice_date": {
 "type": "string",
 "description": "発行日。YYYY-MM-DD 形式。例: 2025-01-31"
},
"line_items": {
 "type": "array",
 "description": "明細行のリスト",
 "items": {
  "type": "object",
  "properties": {
"item_name": {"type": "string", "description": "品名"},
"quantity": {"type": "number", "description": "数量"},
"unit_price": {"type": "number", "description": "単価（税抜、円）"}
  }
 }
}
  },
  "required": ["invoice_number", "total_amount", "invoice_date"]
 }
}

フィールド説明には「例」と「どこを見るか」を含めると、モデルが迷わずに正しいフィールドを特定できる。フィールド数は 10〜15 項目以内に絞ることが精度を保つ上で重要だ。

7-4 AgentCore ガバナンス（2025 re:Invent）

2025 re:Invent で発表された AgentCore は、Bedrock エージェントにエンタープライズグレードのガバナンスを組み込むための機能群。従来は開発者がカスタムのガードレールを手書きしていた部分を、宣言的な設定と評価器で置き換えられる。

13 の品質評価器 (Quality Evaluators)

AgentCore は応答の品質を 13 の評価軸で自動採点する。

これらの評価スコアは CloudWatch にエクスポートでき、品質劣化のアラートをトリガーできる。モデルの入れ替えや fine-tuning 後の品質変化を継続的にモニタリングする用途に使う。

自然言語ポリシー設定

Guardrails と組み合わせることで、ビジネス担当者が自然言語でポリシーを定義できる。

bedrock_client = boto3.client('bedrock', region_name='us-east-1')

guardrail_response = bedrock_client.create_guardrail(
 name='enterprise-policy-v1',
 description='エンタープライズ向けポリシー',
 contentPolicyConfig={
  'filtersConfig': [
{'type': 'HATE', 'inputStrength': 'HIGH', 'outputStrength': 'HIGH'},
{'type': 'VIOLENCE', 'inputStrength': 'MEDIUM', 'outputStrength': 'HIGH'}
  ]
 },
 sensitiveInformationPolicyConfig={
  'piiEntitiesConfig': [
{'type': 'EMAIL', 'action': 'ANONYMIZE'},
{'type': 'CREDIT_DEBIT_CARD_NUMBER', 'action': 'BLOCK'},
{'type': 'PHONE', 'action': 'ANONYMIZE'}
  ]
 },
 topicPolicyConfig={
  'topicsConfig': [
{
 'name': '競合他社への詳細比較禁止',
 'definition': '競合製品やサービスについての詳細な比較・推薦を行うこと',
 'examples': [
  '競合製品の方が優れている',
  '他社サービスをお勧めします'
 ],
 'type': 'DENY'
}
  ]
 }
)

AgentCore の特筆点は、コンプライアンス部門がエンジニアを介さずにガードレールを直接設定・変更できること。従来は「新しいポリシーを反映するまで 2 スプリント」という状況が、自然言語定義により即日反映できるようになった。エンタープライズ展開の意思決定サイクルが大幅に短縮される。

8. 詰まりポイント・アンチパターン・まとめ

実案件で繰り返し発生するハマりパターンを凝縮した。Amazon Q・Data Automation・カスタムモデルを本番に持ち込む前に、以下の 7 つの詰まりポイントと 5 つのアンチパターンを頭に入れておくと、同じ轍を踏まずに済む。

8-1 詰まりポイント 7 選

詰まり① Q Developer 提案の品質ばらつき（コードベース未連携時の文脈不足）

Q Developer を導入したものの「同じ質問でも回答品質がまちまち」という声をよく聞く。根本原因はコンテキスト不足。Q Developer は現在開いているファイルとワークスペースの一部を参照するが、大規模リポジトリ全体の設計方針までは把握していない。

原因チェックリスト:
□ 対象ファイルがワークスペースに含まれていない
□ プロジェクト固有の命名規則・アーキテクチャ方針が未記述
□ Free Tier の月次コード行数上限に到達している

対策:
1. @workspace コマンドで関連ファイルを明示指定
2. プロジェクトルートに .qdeveloper/guidelines.md を作成
3. 品質が安定しない場合は Pro Tier への移行を検討

.qdeveloper/guidelines.md の記述例:

## コーディング規約
- エラーハンドリングは Result 型を使用すること
- ログは structured logging（JSON 形式）で出力すること
- DynamoDB アクセスは必ず DynamoDBWrapper クラスを経由すること

## 禁止事項
- 認証情報のハードコード
- グローバル変数の使用
- print デバッグのコミット

詰まり② Q Business コネクタ同期遅延（初回インデックス・差分更新タイムラグ）

Q Business で Confluence や SharePoint のコネクタを設定すると、初回インデックス作成に数時間〜数日かかる。その後の差分更新にも最短 5〜15 分のタイムラグが生じるため、「さっき更新した文書が検索に出てこない」という問い合わせが発生する。

# 手動で強制同期をトリガーする（急ぎの文書追加時）
client = boto3.client('qbusiness', region_name='us-east-1')

response = client.start_data_source_sync_job(
 applicationId='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx',
 indexId='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx',
 dataSourceId='xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
)
print(f"Sync job started: {response['executionId']}")

UI 上に「情報は最大 N 分遅延する場合があります」と明示してユーザーの期待値を管理することが、運用上の問い合わせを大幅に減らす。

詰まり③ Data Automation Blueprint 設計ミス（フィールド定義過多・抽出精度低下）

カスタム Blueprint に「取れるものは全部取ろう」とフィールドを詰め込みすぎると、抽出精度が大幅に低下する。

悪い例:
"cost": {"type": "number", "description": "金額"}

良い例:
"total_cost": {
 "type": "number",
 "description": "税込の合計請求金額（円）。例: 110000。"
 "ページ右下の「ご請求金額」欄から取得。"
 "単位は必ず円で返すこと"
}

設計ルール:

• Blueprint 1 つにつきフィールドは 10〜15 項目以内に絞る
• フィールド説明には 具体例 + 取得箇所 を含める
• ドキュメント種別（請求書・契約書・仕様書）ごとに Blueprint を分割する
• 初回は 50 件程度のサンプルで精度を測ってから本番投入する

詰まり④ fine-tuning の過学習・データ品質問題（学習データの偏りと early stopping）

fine-tuning したモデルが特定の回答パターンに過剰適合し、汎化性能が下がる。学習データが特定のフォーマット・トピックに偏っていると、本番クエリの 30〜40% でベースモデルより悪い回答を返すことがある。

# 過学習対策: 少ないエポック数 + 検証セット必須
training_job_config = {
 'trainingDataConfig': {
  's3Uri': 's3://my-bucket/training-data/'
 },
 'validationDataConfig': {
  'validators': [
{'s3Uri': 's3://my-bucket/validation-data/'}
  ]
 },
 'hyperParameters': {
  'epochCount': '3',  # 少なめから開始
  'batchSize': '8',
  'learningRate': '0.00001',# 小さめで安定学習
  'earlyStoppingThreshold': '0.01',
  'earlyStoppingPatience': '3' # 3 エポック改善なし → 停止
 }
}

検証損失を CloudWatch でモニタリングし、連続 3 エポック改善がなければ停止するのが基本パターン。fine-tuned モデルは必ず Bedrock Evaluations でベースモデルと比較してからデプロイする。

詰まり⑤ distillation の精度劣化（teacher-student モデル不一致・データ量不足）

Model Distillation を実施したが、student モデルの精度がベースラインを下回ったという報告がある。主因は teacher と student の能力差が大きすぎること、または合成データが本番クエリの分布から乖離していること。

teacher-student 相性ガイド:
┌──────────────────┬──────────────────────┬────────────────┐
│ タスク難易度│ Teacher  │ Student  │
├──────────────────┼──────────────────────┼────────────────┤
│ 高（複雑 RAG） │ Nova Premier│ Nova Pro │
│ 中（FAQ 応答） │ Claude 3.5 Sonnet v2 │ Llama 3.3 70B  │
│ 低（分類・抽出） │ Llama 3.3 70B  │ Llama 3.2 3B│
└──────────────────┴──────────────────────┴────────────────┘

合成データは 本番クエリをそのまま流用することが最重要。テスト用に作成したサンプルクエリを使うと分布が乖離する。RAG タスクでの精度劣化許容値は <2% が目安。これを超えるようであれば teacher モデルのランクを上げるか、合成データ量を増やす。

詰まり⑥ IAM Identity Center 連携の落とし穴（trusted identity propagation 設定漏れ）

Q Business で IAM Identity Center を使ったユーザー認証を設定したが、特定のユーザーが検索しても自分に権限のある文書が返ってこないという問題が発生する。

原因チェック順序:
1. Q Business アプリ設定で「Trusted Identity Propagation」が有効か確認
→ Q Business コンソール > アプリケーション > 認証設定

2. データソースコネクタの「ACL Crawling」が有効か確認
→ コネクタ設定 > 詳細設定 > アクセス制御リストのクロール

3. IAM Identity Center のユーザー属性（部署・グループ）と
コネクタ側の ACL マッピングが一致しているか確認

4. 初回 ACL クロールが完了しているか確認
→ Sync History で「Completed」になるまで最大数時間かかる

よくある見落としは、アプリ設定で Trusted Identity Propagation を有効化したが、コネクタ側の ACL クロールを有効化し忘れているケース。どちらも設定しないと権限フィルタが機能しない。

詰まり⑦ カスタムモデルのコスト・スループット爆発（PT コミット過大・利用率低下）

Provisioned Throughput (PT) を過大にコミットしてしまい、月額コストが想定の 2〜3 倍になるケースがある。PT は 1〜6 ヶ月のコミットが必要で、途中解約ができないため、設計ミスが長期間にわたってコストを圧迫する。

コスト最適化フロー:
① On-Demand でプロトタイプ（2〜4 週間 TPS をモニタリング）
② CloudWatch でピーク TPS・平均 TPS を確認
③ PT コミット量 = 平均 TPS × 0.8（ピーク 20% は On-Demand で吸収）
④ 1 ヶ月コミットから開始（6 ヶ月は利用率確認後）
⑤ 四半期ごとに利用率レビュー → 過剰なら次コミット時に削減

コスト比較例（仮）:
  On-Demand 100%  → 月 $1,000
  PT(80%) + On-Demand(20%) → 月 $650（約 35% 削減）
  PT(100%)・利用率 40%→ 月 $800（利用率低く損）

8-2 アンチパターン → 正解パターン 5 選

① ❌ Q Developer を個人ツールとして導入（ガバナンスなし）

個人の判断で Q Developer Free Tier を使い始め、会社の機密コードが学習に使われていないか不安になる。企業ポリシーが決まらないまま利用が広がり、後から「誰がどのデータにアクセスしたか」が追えない状態になる。

✅ 正解: Admin Console + ポリシー + 監査ログから先に整備

導入前チェックリスト:
□ Q Developer Pro Tier の admin console を設定
□ 許可するファイル拡張子・リポジトリをポリシーで制限
□ CloudTrail + CloudWatch でセキュリティスキャン実行をログ記録
□ IAM Identity Center でユーザー/グループ別のアクセス制御
□ 四半期ごとのアクセスレビューをカレンダーに設定

コード補完がどのデータを参照しているかを管理者が可視化できる状態を作ってから、利用者へ開放するのが正しい順序。

② ❌ Data Automation 出力をそのまま信頼

Data Automation で抽出したデータをバリデーションなしで下流システムに流し込み、誤った金額や日付が基幹システムに入ってしまった。

✅ 正解: 出力スキーマ検証 + 信頼度スコア確認

def validate_da_output(output: dict) -> bool:
 # 必須フィールドの存在確認
 required = ['invoice_number', 'total_amount', 'invoice_date']
 if not all(f in output for f in required):
  return False

 # 型・範囲チェック
 if not isinstance(output['total_amount'], (int, float)):
  return False
 if output['total_amount'] <= 0:
  return False

 # 信頼度スコアの確認（Data Automation の metadata）
 confidence = output.get('_metadata', {}).get('confidence', 0)
 if confidence < 0.85:
  send_to_human_review(output)  # 人間レビューキューへ
  return False

 return True

信頼度スコアが 0.85 未満の場合は自動処理を止め、人間のレビューキューに送る設計が損失を最小化する。

③ ❌ fine-tuning / distillation を未評価のまま PT 投入

fine-tuned モデルや distilled モデルを評価なしで Provisioned Throughput に乗せ、本番ユーザーから「回答が変になった」と報告を受けてから問題に気づく。

✅ 正解: Bedrock Evaluations で精度確認後にデプロイ

bedrock = boto3.client('bedrock', region_name='us-east-1')

eval_response = bedrock.create_evaluation_job(
 jobName='distilled-vs-base-comparison',
 roleArn='arn:aws:iam::123456789012:role/BedrockEvaluationsRole',
 evaluationConfig={
  'automated': {
'datasetMetricConfigs': [
 {
  'taskType': 'QuestionAndAnswer',
  'dataset': {
'name': 'prod-eval-dataset',
's3Uri': 's3://my-bucket/eval/'
  },
  'metricNames': ['Correctness', 'Completeness', 'Coherence']
 }
]
  }
 },
 inferenceConfig={
  'models': [
{
 'bedrockModel': {
  'modelIdentifier': (
'arn:aws:bedrock:us-east-1:123456789012:'
'custom-model/my-distilled-model'
  )
 }
}
  ]
 }
)

デプロイ基準の例: 正確性 -2% 以内・完全性 -3% 以内。どちらか超えた場合はデータを見直してから再トライ。

④ ❌ Q Business で全社員に全文書アクセスを許可

「手軽に使えるように」と全社員に全社文書へのアクセスを許可した結果、M&A 情報・役員報酬データ・未発表の製品ロードマップが一般社員に閲覧されてしまった。

✅ 正解: ドキュメントレベル ACL + ユーザー権限フィルタ

# S3 コネクタでドキュメントレベル ACL を有効化する設定例
data_source_config = {
 'type': 'S3',
 's3Configuration': {
  'bucketName': 'company-docs',
  'inclusionPrefixes': ['public/', 'internal/'],
 },
 'documentEnrichmentConfiguration': {
  'inlineConfigurations': [
{
 'condition': {
  'key': '_document_group',
  'operator': 'EQUALS',
  'value': {'stringValue': 'confidential'}
 },
 'target': {
  'key': '_access_control_list',
  'value': {
'stringListValue': ['executives', 'legal-team']
  }
 }
}
  ]
 }
}

「最小権限の原則」は Q Business でも変わらない。最初はパブリックドキュメントのみで運用を開始し、ACL 設計が固まってから段階的に対象を広げる。

⑤ ❌ カスタムモデルを On-Demand のまま PT 未使用（高負荷時）

月末・月初などのピーク時に大量リクエストが集中し、On-Demand のスロットリングで応答が遅延した。SLA を達成できず顧客クレームにつながった。

✅ 正解: 利用パターン分析 → PT コミット最適化

import boto3
from datetime import datetime, timedelta

cloudwatch = boto3.client('cloudwatch', region_name='us-east-1')

# 過去 4 週間のトークン使用量を取得
response = cloudwatch.get_metric_statistics(
 Namespace='AWS/Bedrock',
 MetricName='OutputTokenCount',
 Dimensions=[
  {'Name': 'ModelId', 'Value': 'my-custom-model'}
 ],
 StartTime=datetime.utcnow() - timedelta(weeks=4),
 EndTime=datetime.utcnow(),
 Period=3600,
 Statistics=['Maximum', 'Average']
)

for point in sorted(response['Datapoints'], key=lambda x: x['Timestamp']):
 ts = point['Timestamp'].strftime('%Y-%m-%d %H')
 print(f"{ts}: avg={point['Average']:.1f} / max={point['Maximum']:.1f}")

2〜4 週間の実利用データを取得してからコミットすることが、コストと SLA の両立に不可欠。

8-3 まとめ — 生成 AI 本番運用 Vol2 完結

Vol1 × Vol2 二部作で何ができるようになったか

Vol1 では、Bedrock Flows による LLM パイプライン構築・Evaluations による品質定量化・Nova モデル・推論オプション（クロスリージョン推論・バッチ推論）という「基盤インフラ層」を扱った。

Vol2 では、その基盤の上に乗る「応用サービス層」をカバーした。Amazon Q Developer が開発者の生産性を加速し、Amazon Q Business が社内知識をエンタープライズ検索に変え、Data Automation が非構造化データを構造化し、カスタムモデル（蒸留・fine-tuning・インポート）が特定業務の精度を底上げする。

生成 AI 実戦軸の全体像

Layer 4: アプリケーション層
  Amazon Q Developer  ── 開発者の生産性向上・コーディング自動化
  Amazon Q Business── 社内知識のエンタープライズ検索・Q&A

Layer 3: RAG / エージェント層
  Bedrock Knowledge Bases ── マルチモーダル RAG・NL2SQL・S3 Vectors
  Bedrock Agents ── 複数ステップのタスク自動化
  Bedrock Data Automation ── 非構造化データの構造化・テキスト化

Layer 2: モデル層
  Foundation Models  ── Claude / Nova / Llama 等
  カスタムモデル── Distillation / Fine-tuning / Import
  Model Evaluation── 精度・安全性の定量評価

Layer 1: 推論・インフラ層
  Cross-Region Inference── レイテンシ最適化・可用性向上
  Provisioned Throughput── 安定スループットと SLA 確保
  Bedrock Flows── LLMOps パイプライン・繰り返し処理

次のステップ

本シリーズを読んだ後のロードマップとして以下を推奨する。

1. まず Q Developer Free Tier を IDE に入れて 1 週間使う。コード補完・セキュリティスキャンを体感してから Pro Tier の投資判断をする。
2. 次に Q Business の PoC 環境を社内 1 部署に限定して構築。コネクタ 1 種類・文書 100 件程度から始め、ユーザーフィードバックを得る。
3. 精度向上が必要になったら Knowledge Bases + Data Automation のマルチモーダル RAG を追加する。
4. スループット・コストが課題になったら カスタムモデル（蒸留 → fine-tuning） に着手する。

生成 AI の本番運用は一度に全部を揃える必要はない。ユーザーの痛みから逆算して、最も効果の高いレイヤーを一つずつ強化していくのが持続可能な進め方だ。