LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

問い合わせ対応や社内文書の検索に生成AIを組み込みたいが、AWSのどの設定から手を付ければよいか分からない。試作は動いたものの、本番で社内のデータを流してよいのか判断がつかない——。情報システム部門では、こうした迷いが起こりがちです。Amazon Bedrock（アマゾン ベッドロック）は、AWS（アマゾン ウェブ サービス）が提供する、複数のAI企業の生成AIモデルを自社のシステムから呼び出して使えるサービスです。

自社のAWS環境で権限や接続の経路を管理しながら使えます。ただし万能ではなく、権限の設計や記録の取り方を決めないまま始めると、本番に移す段階で手戻りが起きやすくなります。本記事では、社内システムへの導入を検討する情報システムの担当者に向けて、Amazon Bedrockの使い方の違い、導入の5つのステップ、そして外部に頼むときに確認したい点を整理します。

Amazon Bedrockとは

AWSの公式ドキュメントは、Amazon Bedrockを、主要なAI企業の基盤モデル（文章の作成や要約など幅広い用途に使える大規模なAIモデル）にアクセスできるフルマネージドサービスと説明しています。対応するモデルは100以上です。^*1 自社でモデルを動かすのではなく、AWSが動かすモデルを社内のシステムから呼び出す形です。

• 社内システムからAPI（ほかのシステムから機能を呼び出す窓口）経由で使い、文書の要約や問い合わせへの回答などに組み込めます
• 利用者のデータが基盤モデルの改善に使われることはなく、モデルの提供元と共有されることもないとされています^*2
• データは送る途中も保存中も暗号化され、自社で管理する鍵で暗号化することもできます
• AWS PrivateLink（インターネットを通らずにAWSのサービスへつなぐ仕組み）を使えば、自社のネットワークから閉じた経路で接続できます^*3

ただし、AWSが守るのはサービスを動かす基盤までです。公式ドキュメントのデータ保護の説明では、責任共有モデル（AWSと利用者で守る範囲を分ける考え方）に沿って、使うサービスのセキュリティ設定と管理の作業は利用者の責任になるとしています。^*4 誰にどの権限を渡すか、記録をどこに残すかは、導入する会社が決めることになります。

使い方ごとの違い

Amazon Bedrockの使い方は1つではありません。まず管理画面で試し、次に社内システムから呼び出し、必要に応じて社内文書の参照や入出力の制御を加えていく、という順で考えると整理しやすくなります。

ナレッジベースは、RAG（検索拡張生成：社内の資料を探してから回答を作る手法）をAmazon Bedrockの中で組み立てる機能です。データの取り込みから検索までAWSに任せる形と、検索用のデータベースを自社で選んで組む形の2種類があります。^*5 文書の量や、閲覧権限を回答に反映させたいかで選び方が変わります。

導入の5つのステップ

社内システムへの導入では、モデルを呼び出す作業よりも前後の決めごとに時間がかかります。次の5つのステップで進めると、試作から本番に切り替える段階で設定をやり直さずに済みます。

• ステップ1：使う業務と、モデルに渡すデータの範囲を決める（個人情報や機密情報を含むかどうか）
• ステップ2：AWSアカウントと権限を整える（利用者ごとに必要な権限だけを渡し、多要素認証を有効にする）
• ステップ3：リージョン（データを処理するAWSの地域）とモデルを選ぶ
• ステップ4：試作して社内システムとつなぐ（接続の経路とガードレールの条件を決める）
• ステップ5：記録と利用量の上限を確かめて運用に入る

ステップ3では、データを処理する場所に注意します。処理を複数のリージョンに振り分ける仕組みには、米国・欧州・APACなど決まった地域の中で処理する方式と、世界中で処理する方式があり、データの保管場所に決まりがある場合は前者を選ぶよう案内されています。^*7 また、多くのモデルは最初から使える状態ですが、一部のモデルはアカウントごとに追加の手続きが必要です。^*8

ステップ5で見落としやすいのが記録です。モデルへの入力と出力を残す設定は、初期状態では無効になっています。^*9 後から中身を確かめたいなら、保存先と期間を決めて有効にします。もう1つは利用量の上限です。モデルの利用はトークン（文章を細かく区切った単位）の量で上限が決まっており、上限の引き上げは自動では認められません。^*10 利用者が増える前に、自社に設定された値を確かめておきます。

外部に頼むときに確認しておきたい点

社内システムへの組み込みを外部に頼む場合も、守る範囲を決める責任は発注する会社に残ります。見積もりの前に、次の点を整理しておくと話がかみ合いやすくなります。

• どこまで頼むか：アカウントと権限の設計、社内システムとの接続、ナレッジベースの構築、運用の手順づくりのうち、どれを任せるか
• データの扱い：モデルに渡すデータの範囲、個人情報を伏せる条件、処理する地域を誰が決めるか
• 権限と認証：試作で使った短期のAPIキーを、本番ではIAMロール（AWSの権限をまとめた設定）に切り替える計画があるか^*11
• 記録と監査：AWS CloudTrail（AWSへの操作の記録）とモデル呼び出しの記録を、どこに、どのくらいの期間残すか^*12
• 運用後の見直し：回答の品質と利用量を定期的に確かめ、モデルやガードレールの設定を直す場を設けるか

とくに権限と記録は、決めないまま本番に入りやすい点です。導入後の費用の抑え方はAmazon Bedrockのコスト最適化で、生成AIのAPIを社内システムにつなぐ開発の全体像はLLM API連携開発を外注する手引きで扱っています。

まとめ：Bedrock導入で確かめたい3つの点

Amazon Bedrockを社内システムに導入するうえで、確かめておきたい点は3つに整理できます。第一に、モデルに渡すデータの範囲と、データを処理する地域を最初に決めること。第二に、試作の段階から、利用者ごとの権限と認証の方式を本番と同じ考え方で設計すること。第三に、呼び出しの記録と利用量の上限を、運用に入る前に確かめておくことです。この3点を踏まえておけば、「試作は動いたのに、本番に向けた社内の確認を通らない」という事態を避けやすくなります。設計や構築の進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：Amazon Web Services「Amazon Bedrock ユーザーガイド：概要」（https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/what-is-bedrock.html）。出典：フルマネージドサービスとしての説明、対応する基盤モデルが100以上であることを参照（2026年11月確認）
2. *2　参考：Amazon Web Services「Amazon Bedrock のよくある質問」（https://aws.amazon.com/jp/bedrock/faqs/）。出典：利用者のコンテンツが基盤モデルの改善に使われずモデルの提供元と共有されないこと、転送中・保管中の暗号化、利用者が管理する鍵による暗号化、AWS PrivateLinkによる接続の記述を参照（2026年11月確認）
3. *3　参考：Amazon Web Services「インターフェイス VPC エンドポイント (AWS PrivateLink) を使用して、VPC と Amazon Bedrock 間にプライベート接続を作成します」（https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/vpc-interface-endpoints.html）。出典：インターネットゲートウェイ等を使わずにAmazon Bedrockへ接続できることを参照（2026年11月確認）
4. *4　参考：Amazon Web Services「Amazon Bedrock ユーザーガイド：データ保護」（https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/data-protection.html）。出典：責任共有モデル、セキュリティ設定と管理タスクが利用者の責任であること、IAMによる必要な権限だけの付与、多要素認証の推奨を参照（2026年11月確認）
5. *5　参考：Amazon Web Services「Amazon Bedrock ナレッジベースでデータを取得して AI レスポンスを生成する」（https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/knowledge-base.html）。出典：RAGの説明、マネージドナレッジベースとカスタマーマネージドナレッジベースの2種類を参照（2026年11月確認）
6. *6　参考：Amazon Web Services「Amazon Bedrock ガードレールを使用して有害なコンテンツを検出してフィルタリングする」（https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/guardrails.html）。出典：基盤モデルをまたいで設定できる保護、コンテンツフィルター・拒否されたトピック・機密情報フィルター（個人を特定できる情報の秘匿化）を参照（2026年11月確認）
7. *7　参考：Amazon Web Services「クロスリージョン推論」（https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/cross-region-inference.html）。出典：地理的クロスリージョン推論（米国、欧州、APACなど）とグローバルクロスリージョン推論の違い、データレジデンシー要件がある場合の選び方を参照（2026年11月確認）
8. *8　参考：Amazon Web Services「モデルへのアクセスをリクエストする」（https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/model-access.html）。出典：多くの基盤モデルへのアクセスがデフォルトで有効であること、一部のモデルで追加のアカウントレベルのアクセスが必要なことを参照（2026年11月確認）
9. *9　参考：Amazon Web Services「CloudWatch Logs と Amazon S3 を使用してモデル呼び出しをモニタリングする」（https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/model-invocation-logging.html）。出典：モデル呼び出しログ記録がデフォルトで無効であること、送信先（CloudWatch Logs・Amazon S3、同じアカウントとリージョン）を参照（2026年11月確認）
10. *10　参考：Amazon Web Services「Amazon Bedrock のクォータ」（https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/quotas.html）。出典：モデル推論がトークン使用率のクォータで制御されること、クォータの引き上げが自動的には付与されないことを参照（2026年11月確認）
11. *11　参考：Amazon Web Services「Amazon Bedrock ユーザーガイド：クイックスタート」（https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/getting-started.html）。出典：AWSアカウントへのサインアップから始まる手順、短期APIキーの生成、本稼働ではIAMロールまたは一時的な認証情報を使う旨を参照（2026年11月確認）
12. *12　参考：Amazon Web Services「Monitor Amazon Bedrock API calls using CloudTrail」（https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/logging-using-cloudtrail.html）。出典：CloudTrailがAmazon BedrockへのAPIコールをイベントとして記録し、証跡によりAmazon S3へ継続的に配信できることを参照（2026年11月確認）
13. *13　参考：Amazon Web Services「AI エージェントを使用してアプリケーションのタスクを自動化する」（https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/agents.html）。出典：Amazon Bedrock エージェント（Agents Classic）が新規のお客様に公開されなくなり、同様の機能はAmazon Bedrock AgentCoreで提供される旨を参照（2026年11月確認）

Tweet