AWS Bedrock × LambdaでRAGパイプラインを2日で実装してみた話 with Gemini CLI

今回、【2026年１発目】Progateハッカソン powered by AWSに初参加しました！

その時の経験を踏まえて、Gemini CLIを使用したAWS Bedrock × LambdaによるRAGパイプライン開発を2日で実装した話を記事に書きました！

読者対象

初心者ハッカソンに参加したい方
ハッカソンへ興味ある方
チーム開発をしたい方
AWSでサービス開発したい方

Progateハッカソン powered by AWSとは？

Progateが主催する2日間のハッカソンイベントです。
今回はAWSさんに協力をいただいた特別なハッカソンになっています。

このイベントは約1週間の事前開発期間（オンライン）と本番の2日間（基本オフライン）のスケジュールで進行されます。

ハッカソン当日の2日間は自由に開発ができるAWS環境を提供させていただきます。

また、当日はProgateやAWSの社員だけでなく、メンターサポートしてくれるテック企業や経験豊かなコミュニティメンバーの参加も予定しています。
学生の方は企業と知り合うチャンスにもなるのでぜひ活用してくださいね！

過去のAWSさんとのコラボハッカソンの様子は下記の開催レポートを参考にしてください！

• https://aws.amazon.com/jp/blogs/startup/progate-hackathon-powered-by-aws-2024/
• https://note.com/progate/n/ncccf5f861133

引用: https://progate.connpass.com/event/379247/

つまり、このハッカソンは実質AWSハッカソンであり、AWSの環境をコストを一切考えず、開発できる最高のハッカソンです。(Progate だけで見てはいけません)

こんなイベントは滅多にありません。特に学生なら基本、実務以外で資格取得のみでしか学べませんが、参加するだけで、すべてのAWSサービスを触れます。

はっきり言って、AWSのアウトプットとしては 最高の環境 です。

なぜ参加しようとしたのか

主に２つの理由がありました。
一つ目は、相変わらず、脆弱性診断やバグバウンティの息抜きとして、爆速開発したいなと思ったからです。しかもAWSが使えるのはかなり都合も良かったです。
二つ目は、実際にAWSでの開発で脆弱性診断だけでは見えない視点が見つかるかもしれないと思ったからです。いくら開発エンジニアの背中を預かるにしても、実際にクラウドでの開発経験がないのはちょっと診断員としてあんまり良くないかなと思い、参加しました。

作った作品: hitode Chatbot

今回は、「画像・動画」をテーマにしたAWSでの開発が必須になっていたので、当日、自分を含め組んだ5人のチームは、hitode Chatbot という画像や論文について、パフォーマンスを意識した高度な検索が可能なAIチャットボットを開発しました。

(現在はサービスを閉じています)

プロジェクト構成図です。

hitode/
├── web/                  # Next.js アプリケーション（Vercel AI Chatbot ベース）
│   ├── app/              # Next.js App Router　Appのメイン系
│   ├── artifacts/        # 早急に作成したAIチャットボットのUI系
│   ├── components/       # React コンポーネント
│   ├── hooks/            # React Hooks系
│   ├── lib/              # ユーティリティとビジネスロジック
│   ├── public/           # 静的ファイル
│   ├── package.json      # 依存関係
│   └── README.md         # アプリの詳細
│
├── infra/                # AWS CDK インフラストラクチャ
│   ├── lib/              # CDK スタック定義
│   │   ├── config/       # 環境の構成等
│   │   ├── lambda/       # ../../Lambda/copyをOCR Lambdaに置き換え（Claude Vision画像解析）
│   │   └── stacks/       # CDK スタック - インフラのスタックがある
│   ├── bin/              # CDK エントリーポイント
│   ├── lambda/           # Bedrock knowledge baseに送信するためのLambda関数
│   ├── test/             # テストファイル
│   ├── package.json      # 依存関係
│   └── README.md         # インフラの詳細
│
├── doc/                      # ドキュメント
│   └── architecture.dio.svg  # 元のシステム構成図
│
└── README.md             # システムのREADME

正直、二日でフルVibe CodingとCDKをわかってない人が多かったため、クリーンアーキテクチャとか死んでます。
また、人のOSSから引っ張ってきて、改造もしているため、ある意味これで動いているのが奇跡レベルです

作成した経緯

当初、私たちは動画をインデックスしてAIに質問できるシステムの構築を目指していた。しかし、チームが結成されたばかりの野良チームであることに加え、開発期間がわずか2日間という制約を踏まえると、動画を多段階的に前処理するパイプラインを安定的に構築・完成させることは現実的に難しいと判断した。そこで、比較的前処理がシンプルな画像をインデックスする設計へと方針を転換し、限られたリソースの中で完成度を高める戦略を選択した。
また、短期間での開発を乗り切るための方針として、サーバーレスアーキテクチャとOSSをフル活用する方針を採用した。インフラの運用管理に割くリソースを最小化しつつ、すでに実績のあるOSSを積極的に取り入れることで、限られた時間の中でも本質的な機能の実装に集中できる環境を整えた。

実際の開発では、
1、フロントエンドと検索ロジックの構築
2、CDKを使ったインフラの整備
3、アップロードされた画像ファイルのS3への保存とイベント発火
4、Bedrockによるインデックス処理
5、開発体験を整備するDevOps

という形でパイプライン・処理ごとに役割を明確に分担し、最終日の1日で各コンポーネントの繋ぎ込みを行うギリギリのスケジューリングで実装を進めた。各メンバーがそれぞれ異なる強みの領域を持っていたことが功を奏し、各々が自律的に自分の役割を推進できたことで、分業体制が自然かつ効果的に機能した。そして、コンポーネント同士を繋ぎ合わせる最終フェーズでは密なコミュニケーションが不可欠であり、チーム全員が同じ空間に集まってオフラインで開発していたことが、迅速な意思疎通と問題解決に大きく貢献した。

Topa'zからの引用です。

技術スタック

主要コンポーネント

• Web アプリケーション: Next.js 16 + Vercel AI SDK(OSSを流用)
• ナレッジベース: Amazon Bedrock Knowledge Bases
• データベース: PostgreSQL(開発の都合により、ローカル環境でのチャット履歴)

詳細コンポーネント

Web アプリケーション

• Next.js 16 - React フレームワーク
• React 19 - UI ライブラリ
• AI SDK - LLM統合ライブラリ
• Tailwind CSS 4 - CSS フレームワーク
• TypeScript 5- 型付き JavaScript
• Biome - Linter & Formatter
• Drizzle ORM - データベース ORM
• S3 - ファイルストレージ

インフラストラクチャ

• AWS CDK - Infrastructure as Code
• Amazon Bedrock - ナレッジベースを用いたAI/MLサービス
• AWS OpenSearch Serverless　- 検索データベース
• Amazon S3 Vector - ベクトルストア
• Amazon Aurora PostgreSQL - データベース
• AWS Lambda - サーバーレス関数
• TypeScript - CDK の実装言語
• AWS IAM - アクセス管理

主に携わったところ

全体としては約16時間で開発しました
このAIチャットボット技術的にかなり複雑なため全部を理解するのは大変でしたが、要はこれがRAGパイプラインの詳細です。

1. 画像 / PDFファイルをS3にアップロードする
2. そのアップロードされたS3のバケットとBedrock ナレッジベースのバケットを作成
3. Claude SonnetモデルによるOCRでの像認識・OCR（光学的文字認識）を実行して、画像の中からテキスト情報を全て抽出します
4. その後、テキストファイルが保存されたことを検知し、別のLambda関数により、Bedrockナレッジベースに対して新規のテキストファイルを同期させる処理が走ります
5. S3 Vectorを使用し、Bedrockナレッジベースの処理において、変換されたベクトルデータを、検索データベースである OpenSearch Serverless に保存します
6. 別のLambda関数により、S3にも同期させます
7. 結果Webアプリ上で、AIチャットボットに聞いた際、処理済みのS3から検索をして、その出力結果を示します

主に、私は、このRAGパイプラインの1,2,4,5,6を担当しました。
つまり、実質、AWSの主要パイプラインを作っていました。

(当日、無茶振りなRAGパイプラインを要求されてよくわからないまま開発し、今記事を書く時にまとめていたら、ほぼ自分がパイプライン系を開発していました。ただ3に関しては作るのを忘れていたため、別の方が開発してくださりました。)

実際、RAGパイプラインをGemini CLIでフルVibe Codingした感想

実際に、RAGパイプラインを作成してみて、割と大変でした。そもそもCDKなんて使ったことがなかったため、知らないままGemini CLIで調整して作りました。確かにCDKのおかげでVibe Codingできるのは良いのですが、それでも調整したり、チーム開発でうまく立ち回ったり、クリーンアーキテクチャを意識するならば、もう少しAWSのドメイン知識を増やすべきだと思いました。

バグハンター / Web 脆弱性診断員からみたAWSパイプライン開発をした感想

普段はバグバウンティという脆弱性を報告し、報酬金をもらったり、インターン先でWebアプリケーションの脆弱性診断に携わっています。その観点から今回に関しては、自分含め、チームメンバーその他のチームが開発する上で、AIにコードを生成させて、実装まで行うのがほぼ占めていました。自分が使っていた時に普通にXSSが起きそうな脆弱なコードや生のSQL文への挿入などによるSQLインジェクションを多くみてきたため、多分、このままだとCSPMでバージョンの依存から脆弱なライブラリがアップデートされても潜在的セキュリティリスクになるコードが今後も増えそうと思いました。

これは、セキュアなシステム開発において、非常に深刻な問題であり、改善しなければなりません。本当に自分でも恐ろしいぐらいです。

教訓

このことから、以下のことを意識した方が良いと感じました。

• AWSのドメイン知識を増やす
• 今後も触れる機会があれば参加する
• DevOpsの気持ちも考えて、自分の言語理解能力を上げる

正直、パイプライン系の実装は知識ゼロでもAIでできます。ただ、実際にスパゲティコードを避けたり、クリーンアーキテクチャを意識するなら、絶対にAWSの知識は勉強するべきだと思いました。

また、個人的に開発を通して、HacktricksのAWS RED TEAM EXPERTやAWS Certified Security - Specialtyなどの資格を取りたい気持ちも高まりました。

全体的な感想

今回はProgateハッカソンを通して、学生では触ることのないAWSでの開発に携われて、楽しかったです。これを機に診断する上でクラウドの知識も増えたため、少しでも仕事に活かせれたらなと思います。