## 過去のシステム設計図を読み込ませたうえで、新規業務を受注したときにどの設計図が一番類似性が高くて参考になるかアドバイスをもらいたいです ### 1. 目的 新規業務要件や案件概要を入力 → 類似する過去設計図を提案 ✅ 類似度の高いシステム設計書を提示 ✅ 再利用可能な資産を早期特定し、設計・開発工数を削減 ### 2. 仕組みの全体像 ┌───────────────┐ │ 新規業務要件 │ └───────┬───────┘ │ ▼ Embedding生成 │ ▼ ベクトルDB検索（過去設計図Embedding格納済） │ ▼ 類似設計図のランキング表示 │ ▼ ChatGPT等で要約・活用アドバイス生成 ### 3. 導入ステップ詳細 #### Step 1. 過去設計図のEmbedding化 ##### 設計図をテキスト化 - PDF→テキスト抽出 (pdfplumber, PyMuPDFなど) - 画像PDFの場合OCR処理（Tesseractなど） - チャンク分割 - 設計図単位または論理設計/物理設計/画面設計/IF仕様などで分割 - Embedding生成 - OpenAI Embedding API (text-embedding-3-large など) - Instructor embeddings（類似性だけでなく用途特化も可） ベクトルDB格納 - Weaviate, Pinecone, Qdrant, Chromaなどを利用 - メタデータに「案件名」「業種」「開発言語」「基盤」などタグ付与 Step 2. 新規業務要件のEmbedding生成 受注時の要件定義書、案件概要、システム機能説明などをEmbedding化 #### Step 3. 類似度検索 - 新規Embeddingと、過去設計図Embeddingのコサイン類似度計算 - 類似スコアTOP5などを取得 #### Step 4. ChatGPTで要約・活用提案 ##### 類似設計図から - どの部分が今回参考になるか - 差分ポイントは何か - 流用時の留意点 などを生成AIに要約させる ### 4. 技術スタック例 | 項目 | 推奨例 | | ---------------- | ------------------------------------ | | **Embeddingモデル** | OpenAI Embedding, Instructor-XL | | **ベクトルDB** | Pinecone, Weaviate, Qdrant | | **フレームワーク** | LangChain, LlamaIndex | | **OCR** | Tesseract, Azure Computer Vision OCR | | **LLM応答** | GPT-4o with RAG chain | ### 5. 運用上のポイント ✅ 設計図のテキスト化品質（OCR精度、レイアウト保持） ✅ タグ付与の粒度（案件名、業務ドメイン、システム区分） ✅ 機密保持対策（EmbeddingやベクトルDBは社内環境で運用） ✅ 継続更新（新規設計図の随時Embedding登録） ### 6. 期待効果 - 過去資産流用率向上 - 設計漏れ防止 - 教育効果（類似事例学習） ### 結論 * この活用は設計標準化×AI知識活用の最先端事例です。 もし希望であれば、次回 ✅ 具体的なLangChain構成例 ✅ Pythonコードサンプル（PDF→Embedding→検索→LLM要約） ✅ PoCプロジェクト計画書草案 を一緒に作成しますので、お知らせください。 ## RAGを使用した場合、Embaddingするのは文面のことばだけで、設計図における各機能の相互関係の理解に乏しくなる危険性はありませんか とても鋭い指摘です。その通りで、RAGだけでは設計図全体の構造や相互関係の理解は不十分になりやすいです。以下で詳しく解説します。 ### 1. RAGの基本的な限界 RAG（Retrieval-Augmented Generation）は ✅ Embedding検索で類似文書を取得 ✅ 生成AIで要約や回答を生成 という仕組みですが、 - Embeddingは単純なテキスト表現の類似性しか持たない - 設計図の**構造的な意味（ER図、テーブル間リレーション、シーケンス図、クラス図の依存関係）**はベクトル化されない ### 2. 設計図活用における具体的課題 - 課題 説明 - 機能相互関係の欠如 Embeddingは文脈ベースなので、設計要素間の接続・制約・依存は理解できない。 - 設計の階層構造非保持 DB構造、画面UI、IF仕様など設計レイヤー間の対応関係が切れる。 - 抽象度変換が不得意 要件→論理設計→物理設計→コードという変換過程はEmbedding検索だけでは補えない。 ### 3. 解決アプローチ #### (A) 設計構造情報を明示的にEmbedding化 各設計文書チャンクに - 関連テーブル名 - ER図情報 - シーケンス図上の役割 - 参照IF一覧 - などのメタデータを付与し、検索結果フィルタや強化プロンプトに利用する。 #### (B) Graph-based RAG - Embedding検索だけでなく、 Knowledge Graph（設計要素間をノードとエッジで表現）を併用 - 例: Neo4jやAWS NeptuneなどのGraph DBに css コピーする 編集する 画面A --uses--> テーブルB 画面A --calls--> API-C API-C --updates--> テーブルD のような構造を保存し、 - LLMにGraph DBクエリ結果をプロンプトとして与える - ChatGPTが構造関係を含めた回答を生成 という方式が有効。 #### (C ) Multi-modal RAG - 設計図（図面）は画像の場合が多いため、 **Vision系Embeddingモデル（例: CLIP, Gemini, GPT-4 Vision）**を併用し テキスト情報と図情報を統合Embedding化 することで、より広い文脈理解が可能。 ### 4. 実装イメージ - mathematica コピーする 編集する 新規業務要件 │ ├─▶ Embedding検索（テキストベース類似） │ ├─▶ Graph DBクエリ（構造相関データ検索） │ ├─▶ Visionモデル解析結果（画面設計図など画像Embedding） │ ▼ ChatGPT （全情報統合 → 類似設計資産の提示＋差分設計アドバイス生成） 5. 結論 ✅ RAG単体では単語ベースの類似検索に留まるため構造的理解は弱い ✅ GraphDBとの統合やマルチモーダルEmbeddingで補完する ✅ 最終的には、人間設計者の構造理解を補佐するツールとして位置付けることが重要 もし希望であれば、 次回 「Graph-based RAGアーキテクチャ設計例」 を図解でまとめますのでお知らせください。業務ナレッジ資産活用の次フェーズに必ず役立つ内容です。