【20260416 AI×DevOpsStudy #12】Claude Codeによる製造業向けのRAGとAI Agent開発

■AI×DevOps Study #12 の概要
2026年4月16日に開催した「AI×DevOps Study」第12回のアーカイブ動画です。

「AI×DevOps Study」は、AI駆動開発やそこに関係するマイクロサービスについて理解を深める場になります。
株式会社ScalarではAIを使ったチーム開発を進めており、参画しているメンバーや協力会社の方から、具体的なAI駆動開発を実施する方法、その中で生まれたマイクロサービスアーキテクチャを使用したAI駆動開発の事例や実際に使えるエージェントについてお話頂き、参加者の皆様と知識の共有や交換を目的としています。
（弊社製品であるScalarDBも絡んだお話も一部出てきますが、汎用的な内容となっておりますのでフラットにお楽しみいいただけます）

■今回のテーマ
「Claude Codeによる製造業向けのRAGとAI Agent開発」

製造業における設計レビュー（Design Review）工程を短縮するための RAG基盤の構築を行いました。 マイクロRAGを構成し、ベクトル検索とキーワード検索を両立し、複数のRAGを連携してエージェントがデータを取得し、物理シュミレーションを実施するためのエージェントをどのように作っているのかをお話しします。

■登壇者情報（敬称略）
深津航
株式会社Scalar Founder & CEO。日本オラクル株式会社、決済系のスタートアップを経て、株式会社Scalarを創業。

箱崎一輝
札幌の株式会社マーベリックスで、Webエンジニア兼リーダーを務めています。 これまで社内のGoogle Workspace全社導入を推進し、組織の働きやすい環境づくりに貢献しました。 今年からはAI駆動型の開発案件に本格的にジョイン。リーダーとしてチームをまとめながら、実際の現場で「AIをどうUI/UX開発に組み込むか」、日々の実践を通じて探求しています。

■関連コンテンツ
・Youtube（過去の勉強会動画も公開中！）
www.youtube.com/@scalar-labs

・Zenn ブログ
https://zenn.dev/p/scalar_sol_blog

・イベントページ（connpass）
https://scalar.connpass.com/

Transcript

1. Claude Codeによる製造業向けのRAG 2026/04/16 株式会社マーベリックス 箱崎 ⼀輝 株式会社Scalar 深津 航
2. ⾃⼰紹介 名前：深津航 所属：株式会社Scalar CEO, Co-Founder 主な関⼼事項 • ⽇本のIT強化 • アーキテクチャ/設計 • DevSecOps, FinOps • AIが与える各種業界へのインパクト ◦ 個⼈的には、Moltbookが⾯⽩い LinkedIn: https://www.linkedin.com/in/wataru-fukatsu-1692655/ 2 ▪ IPAの専⾨委員としての活動 DADCの専⾨委員としても活動しています。 ▪ 株式会社 Scalar としての活動 株式会社Scalarは、分散トランザクションマネー ジャーのScalarDBと改ざん検知ソフトウェアの ScalarDLを展開中。マイクロサービス化におけるシ ステムの課題やAIなどのデータ基盤の信頼性を担保 するソリューションを展開しています。 ソフトウェア開発、システム開発、マーケティン グ、営業、経営など様々な役割で活動中。
3. 本RAGが解決する 具体的なシチュエーション 3 前提となるペルソナと課題の説明
4. デモを紹介する上での前提となるペルソナと課題例 • ペルソナ ◦ 製造業の設計部⾨のエンジニア • 抱えている課題 ◦ 新規プロジェクトのDRに向けて、 過去の類似製品の試験報告書や市場不具合情報を調べたい！ ◦ しかし、クラウドストレージサービスや複数の社内ポータルに情報が散在しており、 必要な情報を探し出すだけで膨⼤な時間がかかっている... • 実現したいこと ◦ 散在する情報を統合的に素早く検索したい ◦ 様々な分野での企業内の開発ツールとしての提供
5. 要求定義でのAIの活⽤ 要求獲得 （分析） /要件定義 仕様構築 開発プロセス 3D作成 エビデンス 構築 DR 作図 出図 実機 検証 実機に合わせて、作図にアドバイス DRの指摘事項を前工程に反映し、事前に チェックできるようにする AIに推定させるべき出力 「工程時間短縮」のためには 行動に直結させる必要がある NG確率とその理由 「熱NG 0.62 / EMC NG 0.41」のような予測 遅延日数予測 「この要求通以下は+18日の手戻り見込み」 前工程での“打ち手”提案（生成＋根拠） どの設計パラメータが危険因子か（寄与度） 何を追加検証すべきか（試験・シミュレーション） どの過去案件に似ているか（類似検索） 規格の根拠（RAGで条文/標準を引用して要約）
6. 製造業の Design Review：光学機器の場合 DR1：基本設計レビュー システム構成確定 DR2：詳細設計レビュー 図面凍結前審査 DR3：試作評価レビュー 実機評価 DR4：量産準備レビュー 工程設計妥当性 DR5：量産移行承認 SOP承認/監査対応/PPAP提出 DR（Design Review）で行われるレビュー項目（想定） • 光学設計 • LED配置 • ドライバ回路構成 • EMC設計方針 • 防水防塵構造 • 3D CAD • 公差解析 • FEMA（設計） • 熱シミュレーション結果 • 信頼性設計 • 光度測定 • 振動試験 • 高温高湿 • EMC試験 • DFMEA⇒PFMEA連携 • 金型妥当性 • 工程能力（Cp/Cpk） • 自動検査装置 • トレーサビリティ DR0：構想審査（受注前後） • OEM要求仕様の理解 • コスト目標/QCD整合 • 技術成立性 （光学・熱・電気） • 法規（ECE/SAE等） • 光学シミュレーション • 放熱構造成立性 • 原価目標 DR議事録（非構造） • 指摘内容 • 修正内容 • 指摘カテゴリ • 発生フェーズ • 製品タイプ • 担当部門 • 結果（量産後問題発生有無） 設計データ（構造化） • CAD属性（部品点数、接合部 数、材質） • 回路構成情報 • 熱シミュレーション値 • 光学シミュレーション値 • 公差スタックアップ結果 FMEAデータ • 故障モード • 発生頻度 • 重大度 • 検出難易度 • RPN • 実際の市場不具合有無 市場データ • 不具合種別 • 発生ロット • 設計バージョン • 原因分類 • コスト影響 法規・規格データ • ECE/SAE条文 • OEM設計基準 • 社内設計基準 蓄積すべきデータ 「DR指摘 - 設計変更 - 市場結果」を同一IDで紐付ける
7. システム全体像 DR議事録 設計データ FMEAデータ 市場データ 法規・企画 データ 差分 検知 & 抽出 データ分析 ScalarDB メタデータ マスター ペイロード 索引 &ベクトル グラフ メタデータ ＆マスター参照 分類・加工 データ保存 索引化 指示 指示 Graph Work Memory Skills AI Agent Agent Memory Personal Memory
8. RAGを活⽤した分析結果
9. RAGで利⽤している技術 • マイクロ RAG ◦ テーマごとに、RAGを分割し、各テーマごとに検索することで、埋もれがちな情報を取得する ことができるようになる。 ◦ 複数の RAG を同時検索することで、様々な観点から⽂書を抽出することができる。 • RRF Fusion（Reciprocal Rank Fusion） ◦ ベクトル検索、キーワード検索、複数のマイクロRAGの検索を⾏い結果を統合する。 ◦ • ReRank ◦ RRF Fusion でランキングした結果をさらに精度⾼くリランクする。 • その他：Contextual Embedding、セマンティックグラフなどを順次対応中
10. ⾃⼰紹介 箱崎 ⼀輝 • 株式会社マーベリックス（札幌の会社） • Zenn（https://zenn.dev/hako_hako） • AI活⽤歴：約3年 ◦ 業務：Claude Code ◦ 個⼈：Google AI Pro（Gemini, Antigravity）、Rork ※ iOSアプリ開発 10
12. RAGを実現するための技術 12 技術スタック
13. システム構成図
14. • マイクロRAG … ⽂書テーマごとに独⽴した索引（インデックス）に分割し、並列で 同時検索する ◦ 並列検索でレイテンシを削減 ◦ ⽂書を分離することで、検索精度が上がる ▪ ⽂書の種類が異なれば重要なフィールドも検索戦略も異なるため、 インデックスを分離することで各ドメインに最適な設定を適⽤できる • シングルRAG … 全ての⽂書を 1 つの索引（インデックス）に混在させて検索する ◦ ⽂書の種類（設計書 / 不具合情報 / 製品マスタ）が混在 ▪ 的外れな結果が混じりやすい ◦ インデックス設定（フィールド‧フィルター属性）を 全⽂書共通にせざるを得ない なぜマイクロRAG化するのか
15. インジェクション（取り込み）のパイプラインフロー
16. リトリーバル（検索）のパイプラインフロー
17. 技術スタック レイヤー 技術情報 役割 バックエンド Spring Boot v3 REST API提供、ビジネスロジック制御、トランザクション境界管理 トランザクションDB PostgreSQL + ScalarDB Cluster メタデータ永続化、ACID保証、異なるDB間のトランザクション抽象化 検索エンジン MeiliSearch 埋め込みベクトルの保存とセマンティック検索（Hybrid検索） 埋め込みモデル AWS Bedrock Cohere Embed Multilingual v3 テキストを1024次元ベクトルに変換し、意味的類似度計算を可能化 LLM AWS Bedrock Claude Haiku 検索結果を元にした回答⽣成、⽂書要約、コンテンツ分類 認証 Keycloak （PKCE OAuth 2.1） ユーザー認証、JWT発⾏、マルチテナント制御 MCP TypeScript（Node.js） AIエージェント（Claude）からのRAG API呼び出しを仲介
18. 機能 解決する課題 効果 Spring DI （依存性の注⼊） Box、SharePoint、S3など、ス トレージを切り替えたい クラウドストレージ、埋め込みモデル、ベクト ルストレージの切り替えがコードを変更せずに 切り替え可能 プロファイル 開発‧検証‧本番で異なる設定 を使いたい 1つのプログラムで複数環境に対応 ⾮同期処理 ⼤量のドキュメント取り込み 重い処理を待たせず、即座にレスポンス Spring Security 誰がアクセスしているか、どの データにアクセス可能かを制御 したい JWT検証とテナント分離を標準機能で実現 Spring AOP 全APIの実⾏時間やエラーをログ に記録したい 1箇所にログ処理を書くだけで、全APIに⾃動適 ⽤ 本RAGでのSpring機能の活⽤
19. MeiliSearchについて • ⼤量のドキュメントから、質問に関連する箇所を⾼速に⾒つける検索エンジン • RAGでの役割 1. ユーザーの質問 2. MeiliSearchで検索 3. 関連する⽂章（チャンク）を発⾒ 4. LLMに渡して回答⽣成 • 特徴 ◦ Hybrid検索（固有名詞に強いキーワード検索 + 意味に強いベクトル検索） ◦ 数百万件から数⼗ミリ秒で検索が可能
20. MeiliSearchで管理するインデックスの種類 • 検索エンジンに、検索⽤に最適化したデータを別途登録 ◦ 製造業に特化した構成で、⾼速な全⽂検索やベクトル検索を⾏うため インデックス 何を⼊れる場所か chunks ドキュメント本⽂を分割した断⽚（チャンク） → 最も基本的な検索対象 products 製品 /部品マスタ情報 dr_findings LLMが抽出したDR指摘の構造化データ market_defects 市場不具合情報 doc_summaries LLM が⽣成したドキュメント要約
21. ユーザーの利⽤⽅法 21
22. 利⽤⽅法 • ブラウザ（クライアントアプリケーション）から検索 • REST API経由でシステム間連携 • Claude Codeから MCPツール経由で利⽤できる ※なぜCUIでの利⽤を想定しているのか • 本RAGは単なる検索システムとしてではなく、 様々な分野での企業内のAIエージェントのための開発ツールを想定している 製造業の場合... • Claude CodeなどのAIツールを通して、シミュレーターの実装を⾏いつつ、 検索した過去の不具合情報などを統合して、最終的なDR向けレポート作成までを シームレスに⾏いたい
23. Claude CodeからMCPツール経由でクエリ検索 Keycloakによる認証
24. デモ：Claude Code MCPサーバー 疎通確認
25. Claude CodeからMCPツール経由でRAG検索 • 単⼀⽂書検索ではなく、 複数フェーズの⽂書を関連付けて時系列の因 果関係を答えている（= 縦断検索可能） • 「DR2-RCL-202506-008」のような⽂書番号 （= キーワード）を知らなくても、「はんだ剥 離」「リスク」「フェーズ」という⾃然⾔語 で正確に辿り着けている（= セマンティック 検索の優位性） ある架空の製品のリスクに対し、フェーズをまたいだ横断的な問いで検証
26. 本RAGにおける ⽂書取り込み時の⼯夫 26
27. デモ：⽂書取り込み
28. • クラウドストレージと連携し、 サービスにファイルを追加‧更新するだけで検索に反映される • コネクタを抽象化しているため、SharePointやGoogle Driveなども統⼀APIで扱う ことができる [仕組み] • MCPへの明⽰的な取り込み指⽰や、Webhook連携フォルダ監視による検出 ◦ Box API でフォルダを⾛査 → ファイル⼀覧‧コンテンツハッシュを⾃動取得 ◦ 差分検出：ハッシュが前回と同じならスキップ（変更ファイルだけ処理） • 処理は⾮同期（HTTP 202即時返却 → ジョブ IDで進捗確認） ◦ ※進捗確認についてもMCPツール化 クラウドストレージ連携（Box）
29. • 担当者が取り込み時に⽂書カテゴリを⼿⼊⼒せずに分類することができる [仕組み] • ファイル名によるルールベース分類 → LLM による⾃動分類 • ファイル名で分類できない場合、LLMが⽂書の内容をもとに判定 テキスト解析‧分類の仕組み化
30. ストレージへの書き込み • ScalarDBトランザクションで1つのTXにまとめて書き込み ◦ ACID保証‧失敗時は全体ロールバック • 書き込む内容 ◦ 重複チェック⽤のファイル識別情報 ◦ ⽂書のヘッダー情報（タイトル‧カテゴリ‧取り込み⽇時など） ◦ チャンク本⽂とベクトルデータ ◦ 検索エンジンへの反映待ちキュー（次フェーズで使⽤） ※ ⼀部でも失敗した場合は全体を取り消し、     中途半端な状態が残らないようにする
31. 製造業データ構造化抽出 • DR議事録から「どのフェーズで何件の熱系 NG があったか」を定量的に把握できる • 市場不具合とDR指摘を関連付けて過去の類似事例を検索できる [仕組み] 分類結果がDR内の不具合報告の場合、 検索エンジンへの反映とは別処理として構造化処理を実施 • LLM がドキュメントの全⽂を読み、以下の情報をJSON形式で抽出する ◦ どのDRフェーズで発⽣した指摘か、不具合の種類、具体的な内容 • 抽出した構造化データをデータベースへ保存し、 検索エンジンの dr_findings インデックスにも反映する ◦ 構造化データで絞り込みが可能 ◦ 検索精度が上がる
32. • 全⽂取得の判断材料になる（詳しくは回答⽣成時の⼯夫で解説） • チャンクとサマリーを並⾏して検索するので、 ⽂書の概要を問う質問にヒットしやすい ◦ チャンク断⽚だけでは難しかった、”DR3 の議事録を要約して”のような俯瞰的な質問に 答えられる [仕組み] • ドキュメント全体から約500トークンのサマリーを⽣成し、 ScalarDBに保存 → MeiliSearch（サマリー専⽤インデックス）に同期 • コスト対策として、SHA-256（テナントID + docID + 先頭500⽂字）を キーにキャッシュする。 ドキュメントサマリーの⾃動⽣成
33. 取り込みフローまとめ
34. 本RAGにおける 検索→回答時の⼯夫 34
35. デモ：検索→回答
36. • クエリ例：「LED-X300 の熱問題」 ◦ キーワード："LED-X300" という型番でヒット ← "熱暴⾛" は⾒逃す可能性 ◦ ベクトル："熱設計不良" "温度超過" も意味的に近いのでヒット ← マイナー型番は⾒逃 す可能性 ハイブリッド検索 • キーワード検索、ベクトル検索を実⾏する ◦ どちらか⼀⽅では必ず取りこぼしが起きるため、 両⽅を同時に実⾏して結果をブレンドする キーワード検索（BM25） ベクトル検索 得意 型番‧製品コードの完全⼀致 「熱問題」→「温度超過」「熱設計不良」 苦⼿ ⾔い換え‧同義語 マイナー型番‧略語
37. 5インデックス並列検索 × RRF 統合 • ハイブリッド検索（BM25 × ベクトル）を 1つのchunksインデックスだけでなく、5つのインデックスに対して同時に実⾏ ◦ インデックス：本⽂断⽚, DR指摘, 不具合, 製品マスタ, 要約 • インデックスごとに構造‧設定が最適化されているため、 チャンクには出てこないが構造化データとしては存在する情報も拾うことが可能 RRF統合 … Reciprocal Rank Fusion • 各インデックスはスコアの計算⽅法が異なるため、数値を直接⽐較できない • RRF は「スコアの値」を捨て、「順位」だけで統合する考え⽅ ◦ 「複数のインデックスで安定して上位」の⽂書が最終的に上に来るしくみ
38. アクセス権限の検証 ABAC（属性ベースアクセス制御）フィルタにすることで、ユーザーにとって アクセス権限のないチャンクを検索結果から⾃動的に除外する [仕組み] • Layer1：検索前に絞り込む ◦ JWT からテナントIDとユーザーラベルを取り出し、 検索エンジンのクエリに直接フィルターを埋め込む • Layer2：検索エンジンの結果後に検証 ◦ 検索エンジンの結果を、ScalarDBのDOC_LABELSテーブルで再照合 • Layer3：データ検証後、再度検証 ◦ ScalarDBからデータ取得後、再検証
39. リランキング（候補リストの順番を並べ替える処理） • ハイブリッド検索 → RRFで統合した候補を再計算 • リランカーの導⼊（リランキングを実⾏するモデル） ◦ 少数の候補を精緻に評価するのが得意 ◦ クエリと⽂書を⼀緒に読む [仕組み] • リランカーは「クエリ＋⽂書」をセットでモデルに渡し、 2つを並べ読みして関連度を直接採点する • 全⽂書に適⽤すると重いため、 RRF で絞った上位20件だけに適⽤して Top-10 を返す
40. ロングコンテキスト • ”要約”や”全体を教えて”などのクエリに対し、 必要に応じて元のドキュメント全⽂を取得する仕組み ◦ 断⽚的なチャンクだけでは回答が難しい • 2層構造（ヒューリスティック → LLM フォールバック） で ロングコンテキストを判断 ◦ クラウドストレージ側にリクエストを⾏い、 取得結果をチャンクの先頭に配置し通常通りLLMへ渡す
41. ロングコンテキスト - ヒューリスティック層 ヒューリスティック … 経験や直感に基づいて “そこそこ正しい答え”を迅速に導き出す思考法（対義語：アルゴリズム） [仕組み] • クエリ内のキーワードマッチ ◦ 以下含まれている場合、ロングコンテキストが必要と判断 ◦ "要約|⽐較|全体|詳しく|概要|まとめ|すべて|全部 |background|summary|overview|compare|overall" • リランクスコア閾値での判断 ◦ チャンクの関連度が⾼い場合、ロングコンテキストが不要と判断
42. ロングコンテキスト - LLM判断 • ヒューリスティックでは判断できなかった場合 ◦ スコアが低く、かつキーワードもない曖昧なクエリ [仕組み] • 上位 3 件のdoc_summaryをコンテキストに渡し、LLMに判断させる • あなたは検索クエリの判断器です。 以下のドキュメントサマリーとユーザークエリを⾒て、より深い回答のためにドキュメント全⽂の参照が必要 かどうかを判断してください。 全⽂参照が必要な場合は <use_long_context>true</use_long_context> を、不要な場合は <use_long_context>false</use_long_context> を出⼒してください。それ以外のテキストは出⼒しないでくだ さい。
43. ロングコンテキスト導⼊後 • ⽂書全体の⽂脈を把握できるようになった • 具体的な情報が提⽰されるようになった
44. 監査ログの付与 • 記録する内容 ◦ テナントID、セッションID、ユーザーが⼊⼒したクエリ、 返したチャンクと検索スコア、適⽤されたABACフィルタ、 ロングコンテキスト有りかどうか、記録時間 [何のために記録するのか] • いつ誰が何を検索し、何が返却されたのかを追跡する • 品質改善のための分析材料（どのチャンクが多く使われているのかなど）
45. 監査ログの付与 ⽇付による絞り込み テキストによる絞り込み
46. 監査ログの活⽤
47. 検索フローまとめ
48. 発表まとめ 48
49. まとめ • 過去の設計知⾒や不具合情報を統合し、情報を引き出せる環境を実現 ◦ ⽤途別のインデックス分割とハイブリッド検索で、情報の取りこぼしを防ぐ仕組み ◦ ⾃動で⽂書全⽂を読み込む仕組みにより、広い質問にも的確に回答 ◦ クラウドストレージ連携やABACフィルタ、監査ログ導⼊により、 企業導⼊可能なセキュリティを実現 • Claude Code連携にすることで、強⼒な開発ツールを開発 • 今回は製造業に特化してインデックスの分割などを⾏いましたが、 様々な業界に応⽤可能