コンテンツにスキップ

Lions Data's Blog

Lions Data, LLC.

LumeGuard AI v1.6 マルチベースモデル対応で広がる選択肢

前回の記事では、v1.4で 精度100%（60/60） を達成した4つの技術的改善を解説しました。今回は、v1.6で対応した Gemma 4 ベースモデル と、Qwen3 / Gemma 4 の横並び評価から見えた PII 検知精度のさらなる引き上げ について説明します。

何が変わったのか

v1.6では、これまで唯一の本番モデルであった Qwen3-1.7B に加え、Gemma 4 E2B（Beta） をベースとしたバリアントを新たに提供できるようになりました。さらに、両モデルを横並びで評価する過程で見つかった2つの潜在課題を解消し、複数 PII を含む数百文字テキストの一括検知でも GPU 上で精度100%（20/20） を達成しています。

指標（マルチPIIベンチマーク・GPU） v1.5（Qwen3のみ） v1.6 Qwen3 v1.6 Gemma 4
正解率 17/20 程度 20/20（100%） 20/20（100%）
平均レスポンス 2.0 秒 1.27 秒 1.25 秒
最遅ケース 11.5 秒（退化ループ） 2.74 秒 1.98 秒
Safe ケース TN 7/10 10/10 10/10

この結果は、ベースモデルの多様化 と クロスモデル評価で見つかった2点の改善 の組み合わせによって達成されました。

LumeGuard AI 誤検知ゼロ・見逃しゼロ

前回の記事では、ファインチューニングにより精度95%を達成したLumeGuard AIの3つのアドバンテージについて解説しました。今回は、v1.3からv1.4への進化で 精度100%（60/60） を達成した技術的改善を説明します。

何が変わったのか

v1.3の時点で目標の95%を達成していましたが、2件のFalse Negative（見逃し）と1件のFalse Positive（誤検知）が残っていました。v1.4では、これらすべてを解消し、60件のテストケースを 全てパス しています。

指標 v1.3 v1.4
正解率 95.0%（57/60） 100.0%（60/60）
True Positive 33件 34件
True Negative 24件 26件
False Positive 2件 0件
False Negative 1件 0件

この結果は、単一の改善ではなく、4つの技術的アプローチの組み合わせ によって達成されました。

LumeGuard AI が実現する3つのアドバンテージ

前回の記事 では、オンプレミスで完結するプロンプト監査ライブラリ - LumeGuard AI の概要をご紹介しました。本記事では、ファインチューニングによって達成した成果と、LumeGuard AI が提供する 3つのアドバンテージ について詳しく解説します。

ファインチューニングで目標精度を達成

2日間にわたるファインチューニング作業の結果、当初の目標であった 精度95%以上 を達成しました。60件のテストケース(日本語30件・英語30件)に対し、57件を正しく判定しています。今後も継続してテストを行い精度を向上させる予定です。

この成果を支える3つのアドバンテージ - 精度、パフォーマンス、SLM (軽量言語モデル) ― について説明します。

オンプレミスで完結する超高速プロンプト監査ライブラリ LumeGuard AI

企業でのLLM活用が加速する中、プロンプトを介した機密情報の漏洩リスクは、もはや無視できない経営課題です。本記事では、セキュリティと利便性を両立させるために開発されたプロンプト監査ソリューション LumeGuard AI をご紹介します。

なぜ今、プロンプト監査が「経営の要」なのか

ChatGPTなどの外部LLMサービスを利用する際、意図せず以下のような情報が送信されるリスクが常に付きまといます。

  • コンプライアンスリスク: 顧客の個人情報（PII）やマイナンバーを含むデータの入力
  • 知的財産リスク: 未発表製品のコードネームや、RAG（検索拡張生成）で外部ベクトルDBへ送信される社内知識
  • セキュリティリスク: ソースコード内のAPIキーやパスワードの混入

LumeGuard AI は、これらの情報をLLMへ送信される「直前」で検知し、インシデントを未然に防ぎます。

競合手法との比較：なぜ LumeGuard AI なのか？

マネジメント層が最も懸念する「コスト・プライバシー・速度」の観点から、一般的なクラウド型監査APIと比較しました。

比較項目 クラウド型監査API LumeGuard AI (オンプレ/SLM)
データプライバシー 監査用のデータ自体が外部へ送信される 完全に社内ネットワーク内で完結
ランニングコスト リクエスト毎の従量課金（高コスト化） 低コスト（自社サーバー/CPU環境で動作）
レスポンス速度 通信遅延（1〜5秒以上） 超高速（非同期・並行チェック対応）
カスタマイズ性 固定された検知ルール 自由（独自の禁止ワード・モデル選定）

Key Point: 監査のためにデータを外部に送るという「本末転倒」を防げるのが、オンプレミス型であるLumeGuard AIの最大の強みです。

Microsoft Amplifier Overview

GitHub Copilotに代表されるAIコーディングアシスタントは、今や多くの開発者にとって欠かせないツールとなりました。これらのツールは、開発者とAIの「対話」を前提としたチャットボットの延長線上にあり、私たちの生産性を飛躍的に向上させてくれます。しかし、もしAIが単なる対話相手ではなく、開発ワークフロー全体を自律的に実行する存在へと進化したらどうでしょうか？

Microsoftが開発を進める新型AIエージェントシステム「Amplifier」は、AI開発のパラダイムを「チャットボットとの対話」から「AIによるワークフローの自律実行」へとシフトさせる、まさにその未来を提示しています。これはコードを生成するだけのツールではありません。

本ブログでは、Amplifierが既存のAIツールと一線を画す、5つの衝撃的な特徴を解き明かします。

⚠️ Amplifierの現状に関する注意喚起

Amplifierは現在「early preview（初期プレビュー）」段階であり、「research demonstrator（研究デモンストレーター）」として公開されています。これは、APIが将来的に変更される可能性があり、安全装置なども未整備であることを意味します。プロダクション環境での利用は想定されておらず、試用は自己責任が前提となることをご理解ください。

AIエージェント開発の到達点

AutoGenとBeadsが生み出す革命的なアーキテクチャ

AIにコーディングをお願いした時、最初は順調でも、少し複雑なタスクや長期的なプロジェクトになると、以前の指示や全体の依存関係をすっかり忘れてしまった…という経験は、多くの開発者が直面する課題です。

AIコーディングエージェントのこの「記憶」の問題は、その能力を大きく制限する根本的な弱点でした。

しかし、もしこの弱点を根本から解決するアーキテクチャが登場したとしたらどうでしょうか。

このブログでは、Microsoftの AutoGen と steveyegge/beads を組み合わせることで生まれる、AIエージェント開発の新たな到達点とも言える革命的なアーキテクチャを解き明かし、その4つの驚くべきポイントを説明します。

AIエンジニアが今知るべき設計原則 / プロンプトからコンテキストへ

結論：何が変わったのか

  • 「プロンプトエンジニアリング」から「コンテキストエンジニアリング」へ。これは単なる言葉の言い換えではありません。
  • プロンプトエンジニアリングは「完璧な呪文を探す行為」でした。コンテキストエンジニアリングは「LLMが仕事をするために必要な情報を動的に組み立てるシステム設計」です。
  • エージェントの失敗の大半は、モデルの失敗ではなくコンテキストの失敗です。

1. LLMの本質を理解する

LLMは「予測エンジン」です

LLMはデータベースから答えを検索しているのではありません。入力テキストの「最も確率的に自然な続き」を生成しています。したがって開発者の仕事は、モデルが予測する「続き」がユーザーの意図する「正解」と一致するように、確率空間を制約することにあります。

出力を制御する3つのパラメータ

パラメータ 役割 論理タスク 創造タスク
Temperature ランダム性の調整 0〜0.1 0.7以上
Top-K 候補トークン数の制限 1〜20 40以上
Top-P 累積確率による動的フィルタ 0.9 0.95
  • 重要: Temperature=0は最強の制約です。これを設定すると、Top-KやTop-Pの効果は無効化されます。
  • 論理的推論（CoT）にはTemperature=0が必須です。

2. コンテキストの構成要素

「コンテキスト」とは、モデルが応答を生成する前に「見る」すべての情報を指します。

Context Window 内容
System Prompt モデルの振る舞い、ルール、例示
User Prompt 直接的なタスクや質問
Conversation 会話履歴（短期記憶）
Long-term Memory 過去の会話から学んだ情報
RAG Data 外部DBやAPIからの最新情報
Tools 呼び出し可能な関数の定義
Output Schema 期待する出力形式（JSON等）

重要な認識: これは「一度書いたら終わり」のテンプレートではありません。リクエストごとに動的に組み立てるシステムの出力です。

  • in ai, llm, slm
  • このページは約15分で読めます

LLMとSLMの共存時代へ：小型言語モデル(SLM)

知っておくべき現実：ChatGPTの運用コスト

OpenAIのGPT-4を使用した場合、1日1000万リクエスト（各1000トークン）を処理すると、推論コストだけで月額約300万円に達することもあります。さらに、応答時間は平均2〜5秒、ピーク時には10秒を超えることも珍しくありません。

こうした課題が、AI業界に新たな潮流を生み出しています。それが 小型言語モデル(Small Language Models - SLMs) です。

MicrosoftのPhi-3-miniは38億パラメータながらGPT-3.5に匹敵する性能を達成し、推論コストを90%削減。応答時間も100ミリ秒以下を実現しています。

  • in ai, llm, RAG, GraphRAG
  • このページは約15分で読めます

GraphRAGでRAGの精度向上

はじめに: なぜ今GraphRAGなのか

「RAGの精度がイマイチ...」「複雑な質問になると的外れな回答が返ってくる」

こんな悩みを抱えているエンジニアの方は多いのではないでしょうか。実は、従来のベクトルRAGには構造的な限界があり、それを解決するのが Microsoft Researchが開発したGraphRAG です。

本記事では、GraphRAGの仕組みから実装方法、そして最新のLazyGraphRAGまで、実際にシステムを構築する際に必要な知識を体系的に解説します。

ベクトルRAGの限界とGraphRAGが解決する課題

従来のベクトルRAGの問題点

ベクトルRAGは「点と点を結びつける」能力が欠如しています。具体的には:

  • マルチホップ推論の苦手さ: 複数の文書に散在する情報を統合できない
  • グローバルな理解の欠如: 「このドキュメント全体の主要テーマは？」といった質問に答えられない
  • 説明可能性の低さ: 「ベクトルが近かったから」という不透明な理由付け

LLM監査AIシステムの設計と実装 (2) / LLM-as-a-Judge

はじめに

大規模言語モデル（LLM）の急速な普及により、その出力の品質評価が重要な課題となっています。従来の人間による評価は時間とコストがかかり、スケーラビリティに欠けるという問題がありました。そこで登場したのが「LLM-as-a-Judge」というパラダイムです。 今回、LLM-as-a-Judgeの仕組みから実装方法、そして実務での活用における注意点まで、エンジニアが知っておくべきことを説明します。

LLM-as-a-Judgeとは何か

基本概念

LLM-as-a-Judgeは、大規模言語モデル自体を評価者として利用し、他のLLMやAIシステムが生成したテキストの品質を評価する手法です。簡単に言えば、「AIがAIの出力を採点する」仕組みです。

なぜ今注目されているのか

従来の評価方法には以下の課題がありました：

  • 人間評価の限界: 大量のデータを評価するには膨大な時間とコストがかかる
  • 評価者間のばらつき: 複数の評価者による主観的な判断の不一致
  • 既存指標の不十分さ: BLEUやROUGEなどの従来指標では、オープンエンドな出力の品質を適切に評価できない

LLM-as-a-Judgeは、これらの課題に対する実用的な解決策として注目されています。