AXプロジェクト実践ガイド 第2回 — 既存システム向けオープンソースAI統合パターン

「AXプロジェクト実践ガイド」シリーズは、エンタープライズシステムへのAI機能統合に向けた構造的なアプローチを提供します。全5回（1 企画、2 開発、3 ツール・MCP、4 ガードレール、5 セキュリティ・ガバナンス・運用）で構成される本シリーズは、AI導入の複雑性を乗り越えるシステムインテグレーター（SIer）向けの包括的なフレームワークを提供します。第2回となる今回は、既存システムにオープンソースコンポーネントを用いてAIを追加する際の開発フェーズ、特に設計と構築の側面に焦点を当てます。このフェーズの主要な成果物には、詳細なアーキテクチャ設計、定義済みエンドポイント権限を含むAPI仕様書、関連権限を含むページ仕様書、最終化されたソースコード、および堅牢な評価パイプラインが含まれます。

AXプロジェクト実践ガイド 連載目次

1. AXプロジェクト実践ガイド 第1回 — 戦略的なAIユースケースの選定と要件定義
2. AXプロジェクト実践ガイド 第2回 — 既存システム向けオープンソースAI統合パターン (この記事)
3. AXプロジェクト実践ガイド 第3回 — AIエージェントの安全な接続：MCPツール設計、OAuth、防御策のプレイブック
4. AXプロジェクト実践ガイド 第4回 — LLMガードレール：セキュアなAI導入のための必須設計とレッドチームテスト
5. AXプロジェクト実践ガイド 第5回 — AIセキュリティガバナンスの要：LLMOps、脅威モデリング、本番稼働のための規制遵守

連載のハブを見る →

アーキテクチャパターン比較表

既存システムへAIを効果的に統合するには、適切なアーキテクチャパターンを選択することが重要です。その選択は、タスクの複雑さ、外部データの必要性、およびモデルに求められる自律性のレベルによって異なります。以下の表は、一般的なパターンを比較したものです。

既存システムへのAI統合、特にドメイン固有の回答提供やデータ解釈支援においては、Retrieval Augmented Generation (RAG) パターンが複雑さとパフォーマンスの最適なバランスを提供します。これにより、ハルシネーションのリスクを大幅に軽減し、LLMの回答を検証可能な企業データに基づいて根拠づけることができます。以降で提示するアーキテクチャでは、主にRAGパターンを活用します。

モデル選択と提供

モデル選択

オープンソースのLLMエコシステムには、多様な選択肢があります。主な考慮事項には、モデルサイズ、パフォーマンス、ライセンス、およびコミュニティサポートが含まれます。主要な選択肢は以下の通りです。

• Mistral-7B/Mixtral-8x7B: 優れたパフォーマンス、効率性、および寛容なライセンス（Apache 2.0または特定のMistralライセンス）で知られています。
• Llama 2/3: Metaのモデルは高品質ですが、非常に大規模な企業向けに利用制限があります。Llamaモデルの具体的なライセンスは、展開前に慎重に確認することが不可欠です。
• Qwen: Alibaba Cloudのシリーズは、様々なタスクで競争力のあるパフォーマンスを提供しますが、検証が必要な独自のオープンソースライセンスを持っています。

初期開発およびテストには、Mistral-7Bのようなより小さく効率的なモデルがしばしば適しています。本番環境に展開する前に、選択したオープンソースモデルに関連する具体的なライセンスを必ず確認し、遵守することが重要です。

LLM提供

• 開発: Ollama: ローカル開発および迅速なプロトタイピングにおいて、Ollamaは様々なオープンソースモデルを民生用ハードウェアで実行するための簡単な方法を提供します。モデルのダウンロードとローカルAPIの公開を簡素化します。pgvectorについては、ベクトルストレージにおける役割としてRAGセクションで後述しますが、OllamaのようなローカルLLMと並行して初期設定を行うことは、開発環境構築の一部となることがよくあります。

• # Download and install Ollama from ollama.com
  # Pull a model, e.g., Mistral
  ollama pull mistral
  # Run a local PostgreSQL instance with pgvector (example using Docker)
  docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -p 5432:5432 -d pgvector/pgvector
  

• 本番: vLLM: 本番環境での高スループット、低レイテンシの推論には、vLLMが推奨されます。これは、PagedAttentionのような技術を通じてLLMの提供を最適化し、スループットを大幅に向上させ、メモリフットプリントを削減します。vLLMのデプロイは通常、コンテナ化され、Kubernetes内のGPUアクセラレーション対応インフラストラクチャ上で実行されます。

• # Example: vLLM Python serving (simplified)
  from vllm import LLM, SamplingParams
  llm = LLM(model="mistralai/Mistral-7B-Instruct-v0.2")
  sampling_params = SamplingParams(temperature=0.7, top_p=0.9, max_tokens=256)
  prompts = ["Explain the RAG architecture."]
  outputs = llm.generate(prompts, sampling_params)
  for output in outputs:
      prompt = output.prompt
      generated_text = output.outputs[0].text
      print(f"Prompt: {prompt!r}, Generated text: {generated_text!r}")
  

  このコードスニペットは、通常APIを介して公開されるvLLMサーバーとのやり取りを示しています。

RAGパイプライン

LLMの回答を企業データに根拠づけるためには、堅牢なRAGパイプラインが不可欠です。主要なコンポーネントには、埋め込み、ベクトルストレージ、検索、リランキング、およびオーケストレーションが含まれます。

埋め込みとベクトルストア

• 埋め込み: BGE-M3: BGE-M3 (BAAI General Embedding)は、複数の言語とテキスト/画像混合入力を処理できる非常に効果的な埋め込みモデルです。これは、意味的類似性検索において良好なパフォーマンスを提供します。
• ベクトルストア: pgvector: pgvectorとPostgreSQLの統合により、従来のRDBデータと並行してベクトル埋め込みを直接保存およびクエリできます。これにより、既存のデータベースを活用することでインフラストラクチャが簡素化され、強力なSQLベースのフィルタリングと結合が可能になります。

検索とリランキング

• 検索: ドキュメントがチャンク化され、pgvectorに埋め込まれると、検索はベクトルストアをクエリして、ユーザーの入力クエリに最も意味的に類似したチャンクを見つけることを含みます。
• リランキング: bge-reranker: 初期検索後、bge-rerankerのようなリランカーは、検索されたドキュメントの品質を大幅に向上させることができます。これは、上位k件の検索されたドキュメントの関連性を再評価し、最も適切な情報がLLMに渡されるようにすることで、応答の精度を高め、ノイズを削減します。

LangGraphによるオーケストレーション

LangChain上に構築されたLangGraphは、LLMを用いた堅牢でステートフルなマルチアクターアプリケーションの作成を容易にします。これは、動的な検索、条件付きロジック、反復的な洗練を可能にする、複雑なRAGフローのオーケストレーションに最適です。LangGraphベースのRAGパイプラインには、以下が含まれます。

• Ingestion: ドキュメントの読み込み、チャンク化、埋め込み、pgvectorへの保存。
• Query Processing: ユーザークエリの埋め込み、pgvectorからの初期検索。
• Reranking: 検索されたドキュメントを洗練するためのbge-rerankerの適用。
• Generation: リランキングされたドキュメントと元のクエリをLLMに渡し、回答を生成。
• Conditional Logic: 関連性の確認、ツール呼び出しの必要性の判断、明確化のためのループなどのステップの実装。

# Pseudocode for a LangGraph RAG chain (simplified)
from langgraph.graph import StateGraph, START, END
# Define graph state and node functions
workflow = StateGraph(object) # Simplified state for example
workflow.add_node("retrieve", lambda state: {"documents": ["doc"]})
workflow.add_node("generate", lambda state: {"response": "answer"})
workflow.add_edge(START, "retrieve")
workflow.add_edge("retrieve", "generate")
workflow.add_edge("generate", END)
app = workflow.compile()

JSON Schema、Confidence、Rationaleを用いた構造化出力

LLMの出力を既存システムに効果的に統合するには、構造化された出力が不可欠です。これにより、ダウンストリームシステムはAIの応答をプログラムで解析、検証、実行できます。JSON schemaは、期待される出力フォーマットを定義し、データ型を強制し、一貫性を確保するための推奨される方法です。

各AIの判断にconfidenceスコアとrationaleを含めることで、透明性と信頼性が向上します。confidenceスコア（例：0.0から1.0までの浮動小数点数）はLLMの回答に対する確実性を示し、rationaleは簡単な説明または裏付けとなる証拠を提供します。この構造は、特に判断APIにとって価値があります。

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "AI Verdict Output",
  "type": "object",
  "properties": {
    "verdict": {
      "type": "string",
      "enum": ["RULE", "AGENT", "HYBRID", "UNKNOWN"],
      "description": "The final verdict type."
    },
    "decision": {
      "type": "string",
      "description": "The AI's decision or answer."
    },
    "confidence": {
      "type": "number",
      "format": "float",
      "minimum": 0.0,
      "maximum": 1.0,
      "description": "Confidence score of the decision."
    },
    "rationale": {
      "type": "string",
      "description": "Explanation or evidence supporting the decision."
    },
    "source_documents": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "List of source documents or references used."
    }
  },
  "required": ["verdict", "decision", "confidence", "rationale"]
}

重要なアプリケーションの場合、ルールエンジン判断レイヤーはLLM出力を補強または上書きできます。これにより、決定論的なルールエンジンを統合して厳格なビジネスルールやコンプライアンスポリシーを強制し、判断をRULE（ルール駆動）、AGENT（LLM駆動）、またはHYBRID（組み合わせアプローチ）として分類できます。

人間によるレビューキュー

AIの進歩にもかかわらず、特に機密性の高い領域や影響の大きい意思決定においては、ヒューマン・イン・ザ・ループ（HITL）プロセスが依然として重要です。人間によるレビューキューは、特定の信頼度しきい値を下回るAI出力や、特定のキーワードでフラグが立てられたAI出力が手動での検査と修正のためにルーティングされるフォールバックメカニズムとして機能します。これはエラーを防ぐだけでなく、モデルのファインチューニングと評価のための貴重なフィードバックも提供します。

人間によるレビューキューの設計には、以下を含めるべきです。

• レビュー担当者がAI出力を迅速に評価し、修正を提供するためのユーザーインターフェース。
• エスカレーションと解決のための定義済みワークフロー。
• データセット改善のためにレビュー担当者のフィードバックを収集するメカニズム。

評価

AIシステムのパフォーマンスと信頼性を維持するためには、継続的な評価が不可欠です。堅牢な評価パイプラインは、CI/CDプロセスに統合され、リグレッションを検出し、品質を監視する必要があります。

• Golden Set Creation: 入力クエリとそれに対応する人間によって検証された理想的な出力からなるキュレーションされたデータセット。このセットは、AIパフォーマンスを評価するための真の基準として機能します。多様なシナリオ、エッジケース、進化するビジネスルールをカバーする必要があります。
• Ragas for RAG Evaluation: Ragasは、RAGパイプラインを評価するために特別に設計されたオープンソースフレームワークです。以下のメトリクスを測定します。
• Faithfulness: 生成された回答が、取得されたコンテキストに基づいてどれだけ事実に忠実であるかを測定します。
• Answer Relevance: 生成された回答が質問に直接対応しているかを評価します。
• Context Relevance: 取得されたコンテキストが質問に関連しているかを評価します。
• Context Recall: 回答に必要なすべての情報が取得されたコンテキストに存在するかどうかを確認します。
• Promptfoo for Regression Testing: promptfooをCIパイプラインに統合することで、LLMプロンプトと構成の自動リグレッションテストが可能になります。これにより、コード変更のたびにゴールデンセットに対して一連のテストを実行し、更新がパフォーマンスを低下させたり、新しい問題を引き起こしたりしないことを保証します。

# Example of integrating promptfoo in CI
# Assuming promptfoo is installed and a config file (promptfoocfg.yaml) exists
# This command would be part of a CI/CD pipeline script
promptfoo eval -c promptfoocfg.yaml
# Example promptfoocfg.yaml structure (simplified)
events:
  - prompt: "Explain the RAG process."
    vars:
      context: "{{ retrieve_docs(input.question) }}"
    assert:
      - type: llm-rubric
        value: "The response accurately explains RAG."
        threshold: 4 # on a scale of 1-5

APIおよびページ権限設計

既存アプリケーションにAI機能を統合するには、セキュリティを維持しアクセスを制御するために、APIエンドポイントとユーザーインターフェースの権限を慎重に設計する必要があります。最小権限の原則を遵守してください。

• API Specification: AIサービス用の新しいAPIエンドポイント（例: /api/v1/ai/query、/api/v1/ai/verdict）を定義します。各エンドポイントは、認証メカニズム（例: OAuth 2.0、APIキー）と認可ポリシー（例: ロールベースアクセス制御 - RBAC）を指定する必要があります。AIモデルからの構造化JSON出力を含む、入力および出力スキーマを明確に文書化します。
• Endpoint Permissions: 各AI搭載APIエンドポイントにきめ細かな権限を実装します。例えば、ユーザーロールはAIへのクエリを許可されるかもしれませんが、管理者ロールは評価メトリクスや構成エンドポイントへのアクセス権を持つ場合があります。
• Page Specification with Permissions: AIサービスと連携する新しいUIコンポーネントやページ（例: チャットボットインターフェース、判断レビューキュー）については、対応するページレベルの権限を定義します。承認されたユーザーのみがAI生成コンテンツや構成を表示、操作、または変更できることを確認します。

次のステップ

AI統合の基礎的な設計と実装を基盤として、次のフェーズでは、開発ライフサイクルの最適化、適切なツールの選択、および堅牢な機械学習運用（MLOps）フレームワークの確立に焦点を当てます。これには、モデルのデプロイ、監視、反復的な改善に関する詳細な計画が含まれます。

この回の成果物サンプル

以下は、オープンソースのAXラボを基にしたこのフェーズの成果物サンプルです。組織の環境に合わせて調整してご利用ください。要件定義書の全体(Excel)はAXプロジェクト実践ガイドのハブからダウンロードできます。

FAQ

1. オープンソースLLMを使用する主な利点は何ですか？
   オープンソースLLMは、透明性、ベンダーロックインを回避することによるコスト効率、およびデータプライバシーに対するより優れた制御を提供します。また、コミュニティ主導のイノベーションを促進し、外部にデータを共有することなく独自のデータセットでファインチューニングすることを可能にします。
2. RAGはLLMのハルシネーションをどのように軽減しますか？
   RAGは、LLMの回答を信頼できるナレッジベースから取得された特定の事実に根拠づけることで、ハルシネーションを軽減します。LLMは事前学習された一般的な知識のみに依存するのではなく、提供されたコンテキストを使用することで、回答をより正確で検証可能なものにします。
3. AI統合にとって評価パイプラインが不可欠なのはなぜですか？
   評価パイプラインは、AIのパフォーマンスを客観的に測定し、リグレッションを特定し、継続的な改善のためのデータ駆動型インサイトを提供するため、AI統合にとって不可欠です。これにより、AIシステムが時間とともに品質、精度、関連性の基準を一貫して満たすことが保証されます。
4. ヒューマン・イン・ザ・ループ（HITL）はAIシステムでどのような役割を果たしますか？
   HITLプロセスは、特にリスクの高いシナリオや曖昧なシナリオにおいて、AIの意思決定における人間の監視と介入を可能にします。これにより、精度が向上し、信頼が構築され、モデルのトレーニングと洗練のための貴重なフィードバックが提供され、倫理的で信頼性の高いAI運用が保証されます。
5. RAGにpgvectorを使用する利点は何ですか？
   pgvectorを使用すると、使い慣れたPostgreSQLデータベース内にベクトル埋め込みを直接保存およびクエリできます。これにより、個別のベクトルデータベースを回避することでインフラストラクチャが簡素化され、既存のPostgreSQLツールを活用し、セマンティック検索とリレーショナルフィルタを組み合わせた強力なハイブリッドクエリが可能になります。

「AXプロジェクト実践ガイド」の第3回では、ツール・MCPフェーズを深く掘り下げ、堅牢なMLOpsフレームワークの確立、AI向けCI/CDパイプライン、およびモデルのガバナンスとライフサイクル管理戦略に焦点を当てます。

← 前の記事: AXプロジェクト実践ガイド 第1回 — 戦略的なAIユースケースの選定と要件定義
次の記事: AXプロジェクト実践ガイド 第3回 — AIエージェントの安全な接続：MCPツール設計、OAuth、防御策のプレイブック →

AXプロジェクトのご相談

既存システムにAIを加えるAXプロジェクトを、ユースケースの選定・要件定義から構築まで、SeekersLabがSI方式でご支援します。導入をご検討中の方はお気軽にお問い合わせください。

• メール: contact@seekerslab.com
• 電話: +82-2-2039-8160(平日 09:00〜18:00、韓国時間)

お問い合わせ →