社内文書をAIに読ませて質問に答えさせる「Chat with PDF」的な仕組みを、Amazon Bedrock（AWSが提供するAIモデル活用サービス）で作る話を検討中の方に向けた内容です。
Bedrockには、RAG（検索拡張生成という手法。関連文書を検索してからAIに回答させる仕組み）を実現する「Knowledge Base」という機能があります。これをAWSコンソールの画面操作だけで構築するか、Terraform（インフラをコードで定義するIaCツールの代表格）で自動化するか、という選定に迷う場面は多いはずです。
この判断は、PoC（実現可能性を検証する試作）を1回作って終わりなのか、複数環境で繰り返し検証・運用するのかによって答えが変わります。以下、判断軸を整理します。
どんな場面でこの選定が必要になるか
典型的には、社内ナレッジ検索やサポート問い合わせ対応のRAGアプリを検討する初期フェーズです。
AWSコンソールでKnowledge Baseを作ると、S3バケット（文書格納用のストレージ）、OpenSearch Serverless（ベクトルデータベース。文書を数値化したベクトルを検索する仕組み）、Bedrock Knowledge Base本体、そして取り込み用と問い合わせ用のLambda（サーバー管理不要で動く小さな処理単位）を、それぞれ画面で手作業設定することになります。
この手作業を「ClickOps」と呼ぶことがあります。1回のPoCなら問題ありませんが、コスト比較検証や複数環境へのデプロイが必要になった時点で、手作業の限界が見えてきます。
判断軸1: 環境の再現性が必要か
最初に確認したいのは、同じ構成を複数回・複数環境で作り直す必要があるかどうかです。
たとえば、ベクトルデータベースの選択肢としてOpenSearch ServerlessとS3 Vectors（S3上でベクトル検索を行う新しい選択肢）のどちらがコスト的に有利かを検証したい場合、同じ構成を何度も立てて壊す作業が発生します。
この場合、terraform apply一発でS3バケット・OpenSearch・Knowledge Base・2つのLambdaまで一括構築できる状態にしておくと、比較検証のたびに数十クリックを繰り返す手間がなくなります。逆に一度作って動かしっぱなしにするだけなら、コンソール操作でも大きな支障はありません。
判断軸2: 既存のTerraform運用体制があるか
次の軸は、社内に既にTerraformの運用ノウハウやCI/CDパイプラインが存在するかどうかです。
Terraformを使う場合、最初に「リモートステート」の準備が必要になります。ステートとはTerraformが管理するインフラの現在状態を記録したファイルで、チームで共有するにはS3などのリモートバックエンドに置く必要があります。
この初期セットアップ（bootstrap）を面倒に感じるか、慣れた作業と感じるかで判断は変わります。すでにVPCやRDSなどをTerraformで管理している組織であれば、Bedrock関連リソースを追加するだけなので導入コストは低くなります。一方、IaCの経験がないチームがRAGのPoCのためだけにTerraformを学ぶのは、優先順位として後回しにしてよい場面もあります。
判断軸3: モジュール分割の粒度をどこまで作り込むか
Terraformを選んだ場合、次に検討するのはモジュール構成です。ストレージ、OpenSearch、Bedrock、Lambdaをそれぞれ独立したモジュールに分ける設計は、Node.jsアプリケーションでいえばMVC（Model-View-Controllerという役割分担の設計パターン）に相当する発想です。
1つのmain.tfに全リソースを書き込むと、デバッグ時にどこが原因か追いにくくなります。モジュールを分けておけば、Lambdaモジュールは「OpenSearchのエンドポイントID」だけを変数として受け取り、内部構成を知らなくて済みます。
ただしこの分割は、複数人でメンテナンスする前提でこそ効いてきます。1人で完結する小規模PoCなら、モジュール分割はオーバーエンジニアリング（過剰な設計）になる可能性もあります。
判断軸4: 将来のAPI公開・拡張を見込むか
問い合わせ用Lambdaは、CLIから直接呼び出す構成と、API Gateway（HTTP経由でLambdaを呼び出す窓口サービス）を前段に置く構成があります。
社内ツールとしてCLIやSlackボットからの利用に留まるなら、API Gatewayは後回しでも構いません。一方、Webフロントエンドやモバイルアプリからの利用を見込むなら、最初からAPI Gatewayを想定した設計にしておいた方が手戻りは少なくなります。
選択肢の比較
| 観点 | コンソール操作（ClickOps） | Terraformモジュール化 |
|---|---|---|
| 初期構築の速さ | 単発なら速い | bootstrap工程が必要で初回は遅い |
| 再現性・繰り返し検証 | 手作業が毎回発生 | terraform applyで再現可能 |
| 学習コスト | AWSコンソールの知識のみ | Terraformの構文・ステート管理の理解が必要 |
| チーム運用・レビュー | 操作履歴が残らずレビュー困難 | コードレビューとして変更履歴を追える |
ケース別の推奨
- コスト比較検証やアーキテクチャの試行を繰り返すなら、Terraformモジュール化を選びます。OpenSearch ServerlessとS3 Vectorsのコスト差を何度も検証するような用途では、構築・破棄のサイクルコストが決め手になります。
- 社内に既にTerraform運用基盤があり、他のAWSリソースと一貫した管理をしたいなら、Bedrock部分も同じ流儀に合わせるのが自然です。既存のCI/CDパイプラインにRAGパイプラインを組み込める利点があります。
- 単発のPoCを1回動かして社内デモに使うだけなら、コンソール操作で十分です。Terraformの学習コストをかける必要は薄いはずです。
- 複数人チームで長期運用するRAGアプリを構築するなら、モジュール分割まで含めたTerraform化を推奨します。デバッグ時の切り分けやすさが後々の保守コストを下げます。
あえて見送るべき条件
以下に当てはまる場合は、Terraform化を急がない方が合理的です。
- チームにTerraformもしくは同等のIaC経験者がまだいない場合。学習コストがRAG検証の本題より先に立ってしまいます。
- Bedrockのモデルや構成自体がまだ固まっておらず、頻繁に手動で試行錯誤している段階の場合。コード化は構成が安定してから着手する方が手間になりません。
- 社内のインフラ管理が別チーム・別ツール（CloudFormationなど）に統一されている場合。Terraformを新たに持ち込むと運用ツールが二重化してしまいます。
導入前に確認すること
判断に迷う場合は、まず自分たちの状況を次の3点で確認してみてください。
- 同じRAG構成を今後何度も作り直す予定があるか（再現性のニーズ）
- 社内に既にTerraformのステート管理・CI/CD運用があるか（学習コストの土台）
- Knowledge Baseの構成（チャンク分割方法、埋め込みモデル、ベクトルDB）が既に固まっているか（コード化のタイミング）
いずれも「まだ固まっていない」なら、まずAWSコンソールで小さくPoCを作り、構成が安定した段階でTerraform化を検討する順序が無理がありません。逆にすでに検証を繰り返すフェーズに入っているなら、リモートステートのbootstrapから着手して自動化に踏み出す価値があります。