はじめに
こんにちは、入社３年目のKFです！
２年目まではインフラチームに所属、今年からはプロダクト開発チームにて、バックエンドに挑戦中です。
昨年、AWSの資格を複数取得し、AWSにより興味を持ったため、AWS Summitに初めて参加することにしました！
個人的に、AWS業界の最先端の技術をじっくり深掘りする機会が不足していると感じていたため、そうした貴重な情報が集まる場でしっかり学び、得た知見を社内に持ち帰って自社システムの開発体験向上に貢献したいという思いも大きかったです。
そんな中参加したAWS Summitについて、具体的なセッションに関する学びや感想を述べていきます。
AWS Summitで、まさに今の私たちの関心のど真ん中にあるセッションに出会いました。
生成AI活用で見えてきた3つの課題 ～精度・セキュリティ・推進体制～
セッション概要
スピーカー：株式会社サーバーワークス カスタマーサクセス部 CS４課 課長 村上 博哉 氏
生成 AI 活用による業務の効率化、生産性向上が叫ばれていますが「ノウハウがなく、どのように活用を進めれば良いかわからない」「具体的な活用のアイデアやユースケースを知りたい」という課題を持っている企業は少なくありません。本セッションでは、具体的な活用のイメージを持っていただけるように Amazon Bedrock の活用例を紹介し、RAG の精度向上のコツやセキュリティにおいて気をつけたいポイントについて具体的に解説します。
生成AIの業務導入を支援する立場から、実際に多くの現場で感じている課題と解決アプローチについて、非常に実践的な視点でお話しいただきました。
生成AI活用に立ちはだかる「3つの課題」
セッション冒頭、こう問われました。
「生成AIを活用していくうえで、今何が課題になっていますか？」
弊社では、社内全体で生成AIの活用を推進する動きが活発化し、現在、社内の各所でさまざまな課題が生じていると実感しています。ただ、何が課題かと問われると、うまく言語化できませんでした。
そんな中、村上さんが提示された答えは、とてもシンプルで本質的なものでした。
精度、セキュリティ、推進体制
——生成AIの課題は、この3つに集約される。
この記事ではこれら3つの課題についてそれぞれまとめていきます。
課題①：精度
生成AIにおいて「正しい出力」を100%求めることはできません。村上さんも明言されていましたが、「ハルシネーションは完全には避けられない」という前提に立つことが重要です。
特に印象的だったのは、定量的に評価できないものは改善もできないというメッセージでした。
これは「何が良くなったのか、悪くなったのかを測れないと、良し悪しの判断ができず、次の改善に繋げられない」と解釈できます。
改善とは「現状より良くなった」と示すことなので、その良さを数値で示す指標が必要です。
こうした定量的な評価指標があって初めて、対策の効果や改善の方向性が見えてきます。
では、その改善をどう実現していくか。
生成AIをシステムに組み込み、業務の一部として活用していくためには、精度を高めるための具体的な工夫が欠かせません。
そこで村上さんは、以下の対策をご提案されていました。
- 用途に合わせてパラメータを最適化する。
- 精度向上のための機能を活用する。
1つ目のパラメータの最適化について、Amazon Bedrockを例に説明します。
Amazon Bedrockを利用する際、プロンプトだけではなく「Temperature」なども調整できます。
Temperatureとは、出力されるテキストのランダム性や創造性を制御するパラメータのことです。 Temperatureを大きくすると回答の多様性が向上し、小さくすると回答の一貫性が向上します。
精度を上げたい場合はこの「Temperature」を調整することで改善に繋がります。
続いて2つ目の精度向上のための機能についてです。
村上さんは、RAG（Retrieval-Augmented Generation：検索拡張生成）という手法の活用に触れながら、出力の精度は、モデル単体の性能だけで決まるものではないという点を強調されていました。
RAGは、AIモデルが外部情報を参照しながら回答を生成する仕組みで、事前に用意したドキュメントを小さなチャンクに分割し、ベクトル化してデータベースに格納します。ユーザーの質問（クエリ）を同様にベクトル化し、意味的に近いチャンクを検索。それをプロンプトとしてモデルに渡すことで、より文脈に沿った回答を得られるようになります。
このように、「精度を上げる」といっても、モデル自体のチューニング（Temperatureなど）だけでなく、
- ドキュメントの分割（チャンク化）方法
- ベクトル検索の精度
- 埋め込みモデルの選定
- プロンプトへの埋め込み方
など、RAG全体の設計と調整が必要になります。
実際、Amazon BedrockではこのRAGフローを実現するための「Knowledge Bases」機能が提供されており、ベクトルDB（OpenSearch ServerlessやPineconeなど）と連携して、精度向上を支援する仕組みが整えられています。
こうしたアーキテクチャの最適化は、生成AIを「ツールとして使うだけ」の立場ではあまり意識されにくい部分かもしれません。
ですが、生成AIを業務システムに組み込んで本格運用していく場合には、プロンプト設計やパラメータ調整だけでなく、RAG全体の設計思想まで踏み込んで考えることが、精度や再現性を高めるうえで欠かせない視点だと感じました。
課題②：セキュリティ
続いての課題はセキュリティです。
村上さんはこのテーマについて、「AWS Well-Architected フレームワークのセキュリティの柱に沿ってレビューする」という観点から整理されていました。生成AIだからといって特別な構成に頼るのではなく、既存のセキュリティ設計原則をベースに再構成していくことが大切だと強調されていたのが印象的でした。
セキュリティ対策は3段階で考える
生成AIアプリのタイプを特定する
SaaS型を使うのか、自社開発か、チャットUIかバッチ処理か。アプリの構成によって想定すべきリスクが異なります。
リスクを整理する
「OWASP Top 10 for LLM Applications」などを活用し、プロンプトインジェクション、情報漏洩、過剰な権限付与などの観点で洗い出しを行います。
対策を実施する
AWSが提供するマネージドなセキュリティ機能を活用し、リスク低減に取り組みます。
具体的に想定されるリスクと対策例
生成AIにおけるセキュリティリスクとしては以下のようなものを挙げ、それぞれに対して現実的な対策を提示されていました。
| リスク | 対策例 |
|---|---|
| プロンプトインジェクション | ガードレール設定、システムプロンプトの厳格な管理 |
| 機密情報の漏洩 | データのクレンジング、アクセス制御、LLMが出力する情報の制限 |
| 過剰なエージェント権限 | エージェント権限の最小化、すべての操作に対する人間による承認 |
| システムプロンプトの流出 | 禁止事項の明記、機密情報をプロンプトに含めない設計 |
| 無制限なリソース消費 | ユーザー単位での利用制限、利用クォータ設定、AWS Cost Anomaly Detectionの活用 |
このように、セキュリティリスクは単に「外部からの攻撃を防ぐ」だけではなく、LLM（大規模言語モデル）という新しい構成要素が加わることで内部設計や振る舞いへの新たな配慮が必要になることがよく分かりました。
課題③：推進体制
最後の課題は「推進体制」です。これは、生成AIを組織内に定着させ、成果につなげていくうえで最も地道で、かつ最も重要なテーマかもしれません。
セッション内では、「情報と経験の両輪での蓄積が必要」と繰り返し強調されていました。
情報の収集と、現場での実践の“両方”が必要
生成AIの技術動向は日々進化しています。そのため、情報収集や事例の把握はもちろん重要です。しかし、それだけでは不十分で、「実際に社内で使ってみる」「自分たちの業務に当てはめて評価する」——この“試行錯誤の実践”がなければ、本質的なナレッジは蓄積されません。
村上さんの表現を借りれば、「情報の収集だけでも、使ってみるだけでも、どちらか一方では意味がない」ということです。
推進に必要なのは、「小さく、素早く回す」サイクル
セッションでは、生成AI導入における推進フローとして、以下の5ステップが紹介されていました。
- ゴール設定（目的と評価指標を明確化）
- プロトタイピング（試作開発）
- 評価（ビジネス面／技術面の両軸で）
- デプロイ（業務への組み込み）
- モニタリング（継続的な改善）
この流れを1〜3ヶ月の短いスパンで何度も回すことで、仮説検証と改善のサイクルが自然と組織に根づき、使えるAIが育っていくという考え方です。
“完璧な構想”を練るのではなく、“実際に動かしながら検証する”という文化をつくることが、組織としての学習の加速につながると解釈しました。
こうしたサイクルを意識しながら、情報収集と経験をバランスよく積み重ねていくことが、生成AIの社内活用を持続可能な取り組みにしていく鍵になりそうです。
セッションのまとめ
生成AIの業務活用にあたり見えてきた3つの課題として、「精度」「セキュリティ」「推進体制」が挙げられました。それぞれに対して、以下のようなポイントと対策が示されました。
① 精度
- ハルシネーションは完全には防げないという前提に立つ
- 定量評価を通じて改善の方向性を定める
- RAGやパラメータ調整、AWSの機能活用など多面的な精度向上策が有効
② セキュリティ
- 通常のWebアプリと同様に、原則的なセキュリティ対策が前提
- リスク特定→整理→対策実行の3ステップを基本に、LLM特有の課題にも備える
- ガードレールやIAM制御、アクセス制限などを段階的に導入
③ 推進体制
- 成功の鍵は「情報」と「経験」の両輪による積み上げ
- ゴール設定→プロトタイピング→評価→デプロイ→モニタリングのサイクルを小さく早く回すことが重要
感想と今後の展望
現在、社内ではさまざまなAIツールの導入が進み、「AIで生産性を上げていこう！」という機運が高まっています。
そうした中で今回のセッションは、「AIを活用する」だけでなく、「AIを意図をもって導入・組み込む」ために必要な視点——精度、セキュリティ、推進体制——について体系的に学べる非常に良い機会でした。
私自身、まだ生成AIをシステムに組み込むような実装経験はありませんが、その設計思想やリスク設計を考えるうえでのヒントを得ることができ、とても新鮮でした。
今回得た知見を、今後の社内施策や技術選定、体制づくりの場で活かしていければと感じています。
おわりに
AWS Summitは初めての参加でしたが、非常に有意義で、何より楽しく参加できました。年に1度のイベントで、なかなかタイミングを合わせるのも難しいとは思いますが、またいつか参加したいです！
最後まで読んでいただきありがとうございました！
スタイル・エッジでは、一緒に働く仲間を絶賛大募集しています。
もし興味を持っていただけましたら、以下の採用サイトも一度覗いてみてください！
