AWS最小構成で始める社内資料検索RAGチャット

はじめに

はじめまして。株式会社ポーラ・オルビスホールディングス（以下PO社）にて3ヶ月インターンをさせていただいた42tokyoの矢吹と申します。今回はPO社の初めての試みとして実施された42tokyo限定のインターンに参加させていただきました。

インターンの受け入れ自体が初めてとのことだったので、貴重な機会に参加させていただいた感謝を胸に、インターン体験記として記事に残しておこうと思います。42tokyoの後輩への宣伝はもちろん、その他の方にもPO社の魅力をお伝えできればと思います。

ご厚意でPO社のorganization紐付け記事として掲載しても良いという許可をいただきましたので本記事が公開されています。社内の調整に動いていただいた皆様、改めてありがとうございました。

開発したプロダクトの前に、インターンを受け入れていただいたITプロダクト開発チームと自身が所属している42tokyoについて紹介させていただければと思います。

GDSC ITプロダクト開発チーム

PO社は以下のように複数の化粧品ブランドを抱えるホールディングス企業になります。

（公式HP「ブランドポートフォリオ」より）

そんなPO社の中でも、今回お世話になったのはITプロダクト開発チームになります。チームリーダーのチーム立ち上げ記や社内ブログでもチーム立ち上げの背景が述べられていますが、これまで外部ベンダに頼っていたシステム開発を内製化していく目的で2023年に立ち上がった若いチームになります。そのため、歴史が長い企業にも関わらず数多のルールやしがらみが渦巻いておらず、非常に風通しの良いチームという印象を受けました。

また、ITプロダクトチームが所属しているGDSC（グループデジタルソリューションセンター）も2022年4月発足という若い部署になっており、これまでグループで分散していたデジタル関連の部署を統合し、グループ全体での無駄の削減・DXの推進と攻め守りを同時に担う組織となっています。（GDSCの紹介はこちら）

42tokyoについて

次に、42tokyoという組織についても紹介させてください。

42はフランスパリ発祥のエンジニア養成機関であり、

• 学費完全無料
• 24時間365日、校舎とPC利用し放題
• 1ヶ月間通い詰めの入学試験を突破する必要がある
• 教師はおらず、ピアツーピアという学生間で教え合いながら課題を進めていく

という特徴を持つ学校です。

日本では学校法人として認可されているわけではないのですが、フランスやシンガポールなどでは修士号相当の学位が取れるコンピュータサイエンス専門学校として世界各地に54の校舎があります（2025年11月30日現在）

主にCとC++を用いて低レイヤーからコンピュータサイエンスの基礎を固めることを目的とした学校であり、本科ではC言語の標準ライブラリを再実装したり、bashライクなshellやHTTP1.1準拠のwebサーバを開発したりします。

少しでも興味を持った方は、見学会へ申し込んでみてください。

42tokyo 公式サイト

プロダクト概要

ここからは（ようやく？）開発したプロダクトに触れていけたらと思います。ざっくりと概要をまとめると、社内業務規程を自然言語で対話的に検索することが可能なRAGチャットボットをAWS上で構築しました。PO社のwikipediaのようになんでも情報を聞ける場所になってほしい、との想いから「PO Pedia」と名付けたので以下PO Pediaと呼ばせていただきます。

開発目的・背景

PO Pedia開発の目的としては、社内の業務効率化、その中でも特に業務規程関連周りの情報取得に関する業務の効率化が挙げられます。

きっかけとしてはホールディングス（以下HD）のHR室の方から要望をいただいたことにあり、HD傘下の各社の業務規程を比較したい際に各社サイトにぶら下がっている資料を収集し、該当箇所を比較する作業に時間がかかっているという課題を伺っていました。そこで、HR室の社員を優先度の高いペルソナとして設定し、PO Pedia開発を進めていきました。

開発手法

開発はスクラムというアジャイル開発の手法に基づいて進めました。スクラムはウォータフォール開発のように事前に要件を全て洗い出し、WBSで分解したタスクをひたすらこなしていく手法と対比して紹介されることが多いです。数週間のスプリント単位で開発を区切り、そのスプリント内で

• 計画（スプリントプランニング）
• 評価（スプリントレビュー）
• 振り返り（スプリントレトロスペクティブ）

を完結させます。単純にウォーターフォールの期間を区切ったバージョンとみることもできますが、機能を開発すると追加で必要なタスクが見えてきたり、逆に不要な機能を認識できたり、大きな手戻りが防げたりと、アジャイル開発のメリットを肌で感じることができました。

主要技術スタックとアーキテクチャ図

• フロントエンド: Next.js, TypeScript, Material-UI
• バックエンド: AWS Lambda (Python 3.x)
• AI/ML: Amazon Bedrock, Knowledge Base
• データベース:
  • Amazon Aurora (ベクトル検索用)
  • Amazon S3（ベクトル検索元ファイル）
  • Amazon DynamoDB (チャット履歴保存用)
• APIゲートウェイ: Amazon API Gateway

チャット応答フロー

1. ユーザーが質問（プロンプト）を入力
2. フロントエンドで選択されたフィルタ情報（会社、雇用形態、キーワード）を付加
3. プロンプトが生成され、Amazon API Gateway経由でLambdaに送信
4. Knowledge Base で関連ドキュメント検索
5. LLM（現在はClaude 3.5 Sonnet）で回答生成
6. 回答とソース情報をフロントエンドに返却
7. DynamoDB に履歴保存

主要機能

• 法人・雇用形態・ジャンルを選択した検索
• 過去チャット一覧の参照とチャットの再開
• 社内EntraIDでのシームレスなログインとロール管理
• 社内規定資料に加え、過去の社内問い合わせ資料の参照
• 参照資料と参照箇所の明示
• 参照資料から自社サイトの資料リソースにワンクリックでアクセス可能
• 適切な参照資料がない場合のハルシネーション防止
• アプリ立ち上げ時のDynamoDBの起動による待ち時間短縮
• CORS設定を回避するためのaxiosを用いたAPIアクセス
• GSIを用いたDynamoDBの適切なインデックス設計

各種サービスの選定理由

AWS Amplify

ホスティング先としてはAWS Amplifyを選定しました。

React/Next.jsを使ったフロントエンド主導のアプリケーションをAWS上で素早く立ち上げるには最適な選択肢だと思います。
Gen2になってかなり使いやすくなった印象で、レポジトリ認識で自動デプロイはもちろん、ブランチごとにホスティングできる機能も開発時にかなりありがたいです。

AWS Lambda + Amazon API Gateway

SSR（Server-Side Rendering）やAPI Routesなどのサーバサイド処理はNext.jsのサーバサイドが担当し、Knowledge Baseへのアクセスや履歴保存など、AWS関連サービスの入り口として完全サーバレスのLambdaを採用し、インターフェースとしてAmazon API Gatewayを設定しました。

Amazon Bedrock Knowledge Base

資料検索とLLM関連のサービスとしては、RAGを非常に簡便に構築できるサービスであるKnowledge Baseを採用しました。
Knowledge Baseでは文書のOCRやらチャンキングやら、ベクトル化、検索までまるっと任せられるサービスになっており、極端にいうと社内資料をS3にアップロードするだけでRAGシステムが構築できます。具体的には、S3にアップロードしたPDFがチャンキングなどの前処理後にベクトル化され、Auroraに保存されます。ユーザのプロンプトに応じてベクトル検索され、結果がLLM（Amazon Bedrock）のコンテキストとして回答に利用されます。ちなみにAuroraには埋め込み（Embedding）だけでなく、チャンキングされた文と、元のPDFリンクなどのメタデータの3種類が保存されており、どの資料を参照した回答なのか、ユーザに表示する機能も容易に実装出来ました。

DynamoDB

チャット履歴保存用としては、key-value型の非常に高速かつ安価なアクセスが特徴的なDynamoDBを採用しました。

今回は登録と参照の大きく2パターンのクエリしか存在せず、どちらもkeyを介してのアクセスになります。

• 登録：ユーザやAIのメッセージを保存
• 参照：チャット一覧・チャットメッセージ一覧の取得

複雑なSQL操作は不要だったため、速度と料金が選定基準でした。スキーマレスでJSONを投入できる柔軟性、TTL（Time to Live）機能もチャットサービスにとって魅力的に映りました。

DynamoDBに関しては初めて使うサービスであり、かなり特徴的なDBなので設計のためいろいろ調査しました。NoSQLの中でもキーバリューストアとドキュメントストアの要素を持ち合わせており、パーティションキーとソートキーを組み合わせてプライマリキーとし、特定のクエリには迅速かつ安価に対応できるという特徴を持ちます。DynamoDBだけでかなり以下Qiita記事にもまとめたので、興味のある方はぜひ読んで見てください。

DynamoDBのGSI（疎なインデックス）を活用した社内RAGチャット履歴参照機能 - ryabuki

インターン中のイベント

AWS 質問会

AWSのソリューションアーキテクトの方に目黒から（はるばる隣の駅まで）お越しいただき、AWS関連の質問や相談をぶつける機会を作っていただきました。今の自分たちの構成とその選定理由を発表し、そこに対してFBをいただくという形だったのですが、個人的な学びとしては以下2点がありました。

• セキュリティはOSIモデルに対応させながら脅威と対策を整理するとわかりやすい
• LLM出力後にガードレール設定をして個人情報露出を防ぐ方法はあるが、100%防ぐならKnowledge Base構築時にマスクしておく必要がある

また、新サービスのKiro（旧Amazon Q）なども触る機会をいただき貴重な機会となりました。会が終わった後に個人的にぶつけた質問に対してもソリューションアーキテクトの方にかなり親身に相談に乗っていただき、日本でAWSが普及している理由が垣間見えた気がしました。

フロントエンド質問会

上記のインフラ質問会とは別途、PO社内のフロントエンドのプロに開発の疑問をぶつける機会をいただきました。特にブランチ戦略やコンポーネントの分離の考え方は非常に勉強になりました。

自分自身もインターン生に説明する機会があり、コンピュータサイエンスの基本思想である「関心の分離」について理解が深まりました。これは42でもよく感じることではありますが、人に説明している時が一番の頭が整理されて良きです。

ランチ会

また、インターン期間中には社員の方とランチを食べながらお話しさせていただく交流の機会を複数会セッティングいただきました。インターンはフル出社でしたが、社員さんは出社と在宅なのでどうしても接点が少なくなってしまうところをカバーしていただきました。やはり関係性によって質問や議論のしやすさが大きく変わってくるので、接点を増やしていただいたことに感謝しています。

中間発表・最終発表

インターン期間中には中間と最終日に皆さんの前で成果・進捗を発表する機会をいただきました。人にアウトプットすることでチームの現在地を客観的に把握できたり、プロダクトに関して見落としていた観点に対してFBをいただくなど、非常に有意義な時間になりました。発表の機会があることで、他人に評価していただくためのプロダクトの見せ方や説明の仕方を洗練していく機会になりありがたかったです。

勉強会

そして、業務後には隔週ペースでインターン生同士での勉強会を開催していました。勉強会のテーマはAPIレスポンス整形やJWT認証など多岐に渡りましたが、個人的にはAIを全く使わない（AIデトックス？）コーディングの時間に一番充実感がありました。今後も定期的にAIが全く触れない状態でのコーディングの時間を作っていきたいです。

勉強会を主催し、学習コンテンツなども作成いただいたメンバーもqiita記事を書いているので、ぜひ読んでみてください。

属人性を下げてみた — ポーラ・オルビスホールディングス（POHD）インターン振り返り

3ヶ月の振り返り

ひとまずプロダクトとして動くものができたことには安心しています。AWSの各サービスの選定や法人で導入しているEntraIDを用いた認証の構築、質の高いコードレビューなどを通じて、週12時間稼働とは思えないほどの学びを得ることができました。特にいつでも相談できる対面で実施いただいたこと、すべてのPRを社員の方にレビューいただいたことが大きかったと感じています。時間を割いていただいて本当に感謝しかありません。

後半になってわかっていったことではありますが、各々のメンバーが別々の強みを持っていたことも3ヶ月が充実した要因であると感じています。良い人間性のメンバーかつ好奇心旺盛で、お互いの尊厳を尊重しつついろんな技術の議論ができたことは人生の財産になりました。メンバーとは42tokyoとTOYOTAなどが開催するミニカーを用いた自動運転のコンペに出場することになっており、今後にも繋がる関係ができたことを嬉しく思います。

1番の心残りは、最終盤で進捗を優先してしまい、チームメンバーのタスクや成果物に対する解像度が低くなってしまっていたことです。チームでの状況共有の時間はとっていたものの、レビューは社員さんに任せてしまい、チーム間でのレビューがおざなりになっていました。

まとめ

ここまで読んでいただきありがとうございました。いろいろ書いてきましたが、最後に伝えたいことは、GDSCのITプロダクト開発チームには、素敵な方々が集まっており、化粧品会社のIT化・DX推進の転換期でチャレンジできるということです。（お願いされたわけでもないのに）PO社の宣伝になりますが、エンジニアリングに限らず仕事をする上で、モチベーションや成果の質を左右するのは結局周りとの人間関係ではないでしょうか。技術を探求する想いはありつつ、お互いの尊重を忘れない、素敵な方々が集まっているチームであることを3ヶ月で確信しました。主業務以外の開発に時間を使えたり、有給に加えて会社から休暇の付与があったりと、技術の探求と働きやすさを両立できる環境です。歴史の長い企業のIT転換期チャレンジに少しでも興味を持っていただいた方は、ぜひ以下のカジュアル面談にエントリーしてみてください。改めて3ヶ月間ありがとうございました！