この記事は every Tech Blog Advent Calendar 2025 の 4 日目の記事です。
開発1部でデリッシュキッチンのバックエンドをメインに担当している塚田です。
はじめに
弊社ではデリッシュリサーチというサービスのビジュアライズにAWSが提供するQuickSightを活用していました。
AWSが先日発表した「QuickSuite」は、生成AIで開発・業務・運用の作業をまとめて手助けし、仕事の効率を上げるためのツール集です。
本記事では、従来の関連サービスからの変更点、実運用での活用を想定したパターンを検討したのでその内容を記事にさせていただきます。
QuickSuiteの位置づけと構成の全体像
主なできること
- 開発を楽にする: コード提案、リファクタ、テスト作成、PR作成/説明
- 調べ物を速くする: 社内ドキュメントやデータを安全に検索・要約
- 定型作業を自動化する: チケット対応や運用手順を手順どおり支援
セキュリティと管理
- 社内データについては権限に合わせて検索・利用
QuickSightのからの主な変更点
開発体験の統合や企業内ナレッジ活用
- 既存のファイルストア、ナレッジベース、データウェアハウス(DWH)に対するRAGの組込み
- 検索・回答のガードレール、出典提示、ポリシー準拠/監査性の強化
代表ユースケース
- データ分析のセルフサービス化
- 例: 自然言語から各種データソース向けSQL生成、ダッシュボード雛形まで自動作成。データガバナンスに沿ったアクセス制御
- 異常値が発生した際の対応の高速化
- 例: アラートから発火→メトリクス/ログ/トレースを収集→暫定原因と影響範囲を生成→対応策の検討
- サポート対応の効率化
- 例: 顧客問い合わせをチケット化、類似事例/FAQ/手順を提案、回答案と影響範囲の注意点を自動添付
アーキテクチャ・パターン
セキュアRAG基盤
- 企業データソース（DWHやオブジェクトストレージなど）→ インデクシング/埋め込み → ポリシー付き検索 → 生成
- ポイント: VPCエンドポイント、KMS暗号化、監査（CloudTrail/CloudWatch）、PIIマスキング
開発ワークフロー統合
- GitHub/Jira/CI/CD と連携した「チケット駆動の自動修正→PR→レビュー補助」
- 変更影響分析（関数/モジュール依存、テストカバレッジ）を組み込み
導入ステップ
新規で導入する場合を考えた時に以下のようなフローや対応が必要に感じました。
- 対象業務の選定
- 「効果が定量化しやすい/安全に実験できる」ユースケースを検討（例: ドキュメントQA、テスト生成、自動要約）
- データ基盤の整備
- データカタログ、スキーマ管理、アクセス境界、メタデータの整備
- セキュリティ/ガバナンス設計
- IAMロール/ポリシー、監査ログ、プロンプトや出力内容の検討
- PoC設計と評価指標
- 品質（正答率/再現性）、効率、安全性
- 段階的ロールアウト
- 先行チーム→横展開。トレーニングとプロンプトスタイルガイドの整備
- 運用・継続改善
- フィードバックループ（曖昧質問の定義、ナレッジの鮮度管理）、コスト監視
コスト
- ユーザー課金という部分は変わらずユーザー単価の変更
- コスト予想が行いやすく導入後のイメージが見通せる
リスク
- 生成AIを活用しているため必ずしも正しい内容を提示できるわけではない
- ガードレールをプロダクトとして提示する必要あり
- データ漏洩や必要以上の回答をする可能性がある
- /越権参照: 厳格なIAM・ネットワーク分離・プロンプト抑止語（秘密、顧客情報）・DLP
- バージョン差異の発生で想定していない出力が発生する可能性
以前のAWS関連サービスとの比較
- 従来
- 社内で開発・運用しているQuickSightなどのBIツールのみでの分析や評価を実施
- 生成AIのRAGやエージェント構築は設計と統合作業が重く、運用ガードレールを自作
- QuickSuite
- 開発/検索/自動化を「業務フロー」として束ね、エンドツーエンドに管理・監査
- エージェントの実行制御をあらかじめ検討可能
まとめ
弊社ではデータ基盤としてDatabricksを活用しており、社内へ展開するメリットはあまり感じられませんでした。
ただ、すでにプロダクトでQuickSightを利用している場合、QuickSightからあったBIの導入のしやすさに加え、AI(エージェント)の導入・統合がしやすくなったと感じています。
今までBIとAI関連のプロダクトをシームレスに提供することに課題を感じていたためこのような機能を活用しながらユーザーが活用しやすいプロダクトとして活用していきたいと感じました。
