こんにちは、Qualitegコンサルティングです！

サブスクリプションビジネスの完全ガイド　第3回　をお届けいたします！
今回は、 PLG・SLG、ユニットエコノミクス、データ改善の実務ポイントについて解説していきたいとおもいます！

この記事でわかること

　・PLG・SLG・ランドアンドエクスパンドの違いと使い分け
　・NRR、LTV/CAC、ペイバック期間など主要指標の実務的な読み方
　・バーンレートとランウェイから資金繰りリスクを把握する方法
　・ファネル分析・コホート分析・A/Bテストによる改善の進め方
　・AIプロダクト特有の原価構造とユニットエコノミクスの注意点

サブスクビジネス完全攻略 シリーズ一覧

第１回　『アープがさぁ...』『チャーンがさぁ...』にもう困らない

サブスクビジネス完全攻略 第1回～『アープがさぁ...』『チャーンがさぁ...』にもう困らない完全ガイド

なぜサブスクリプションモデルが世界を変えているのか、でもAI台頭でSaaSは終わってしまうの？ こんにちは！ Qualitegコンサルティングです！ 新規事業戦略コンサルタントとして日々クライアントと向き合う中で、ここ最近特に増えているのがSaaSビジネスに関する相談です。興味深いのは、その背景にある動機の多様性です。純粋に収益モデルを改善したい企業もあれば、 「SaaS化を通じて、うちもデジタルネイティブ企業として見られたい」 という願望を持つ伝統的な大企業も少なくありません。 SaaSという言葉が日本のビジネスシーンに本格的に浸透し始めたのは2010年代前半。それから約15年が経ち、今やSaaSは「先進的な企業の証」のように扱われています。 まず SaaSは「サーズ」と読みます。 （「サース」でも間違ではありません、どっちもアリです） ほかにも、 MRR、ARR、アープ、チャーンレート、NRR、Rule of 40…… こうした横文字が飛び交う経営会議に、戸惑いながらも「乗り遅れてはいけない」と焦る新規事業担当者の姿をよく目にします。 しかし一方で、2024

Qualiteg BlogQualiteg コンサルティング

第２回　「解約率5%」が1年後に半分の顧客を消す恐怖と、それを防ぐ科学

サブスクビジネス完全攻略 第2回～「解約率5%」が1年後に半分の顧客を消す恐怖と、それを防ぐ科学

こんにちは！ Qualitegコンサルティングです！ 前回の第1回では、サブスクリプションビジネスの基本構造と、LTV・ユニットエコノミクスという革命的な考え方を解説しました。「LTV > 3 × CAC」という黄金律、覚えていますか？ サブスクビジネス完全攻略 第1回～『アープがさぁ...』『チャーンがさぁ...』にもう困らない完全ガイドなぜサブスクリプションモデルが世界を変えているのか、でもAI台頭でSaaSは終わってしまうの？ こんにちは！ Qualitegコンサルティングです！ 新規事業戦略コンサルタントとして日々クライアントと向き合う中で、ここ最近特に増えているのがSaaSビジネスに関する相談です。興味深いのは、その背景にある動機の多様性です。純粋に収益モデルを改善したい企業もあれば、 「SaaS化を通じて、うちもデジタルネイティブ企業として見られたい」 という願望を持つ伝統的な大企業も少なくありません。 SaaSという言葉が日本のビジネスシーンに本格的に浸透し始めたのは2010年代前半。それから約15年が経ち、今やSaaSは「先進的な企業の証」のように扱われています。

Qualiteg BlogQualiteg コンサルティング

さて、前回までの記事では、サブスクリプションビジネスの基本概念（LTV、CAC、ユニットエコノミクス）と、顧客獲得の方法（広告と自然流入）、そして重要指標（MRR、チャーン率、CVR、ARPU）について解説してきました。

今回の第3回では、実際に顧客を獲得してから成長させ、データに基づいて改善していくフェーズに焦点を当てます。指標を理解するだけでは不十分で、それをどう経営判断に活かすかが重要です。特に、生成AIプロダクトの領域では、従来のSaaS指標の読み方に加えて、AI特有のコスト構造や業務定着の難しさを踏まえた設計が求められます。そうした視点も交えながら解説していきます。

第5章：成長戦略の選択

～PLGとSLG、そして統合アプローチ～

PLG（プロダクト主導型成長）：プロダクトの力で成長する

PLG（Product-Led Growth：プロダクト主導型成長）は、営業やマーケティングではなく、プロダクト自体の力で成長する戦略です。近年急成長したSaaS企業の多くがこの戦略を採用しており、コミュニケーションツール、ビデオ会議ツール、ドキュメント作成ツールなどの領域で成功例が多く見られます。

PLGの最大の特徴は、顧客が自分でサービスを見つけ、試し、価値を感じ、購入まで進むことです。営業担当者と話すことなく、クレジットカードを登録して使い始められます。これにより、顧客獲得コストを大幅に削減できます。営業担当者の人件費がかからないだけでなく、顧客も自分のペースで検討できるため、購買体験が向上します。

PLGが成功するには、いくつかの条件があります。まず、プロダクトが直感的で使いやすいことです。マニュアルを読まなくても、触っているうちに使い方が分かる必要があります。複雑な機能を持つツールであっても、テンプレートや分かりやすい初期画面を用意することで、初心者でもすぐに使い始められる設計が求められます。

次に、個人でも価値を感じられることです。最初は一人で使っても何らかの価値があり、その後チームメンバーを招待することで、さらに大きな価値を生み出す。このように、小さく始めて大きく育てられる設計が重要です。

口コミで広がる仕組みもPLGの重要な要素です。たとえばビデオ会議ツールでは、会議に参加する側はアカウント登録が不要な設計にすることで、招待された人が「これは便利だ」と感じ、自分も使い始めるという好循環が生まれます。

PLGでは、フリーミアムモデルまたは無料トライアルモデルを採用することが一般的です。フリーミアムは、基本機能を永続的に無料で提供し、高度な機能を有料にするモデルです。無料トライアルは、全機能を期間限定（通常14日か30日）で提供するモデルです。どちらを選ぶべきかは、プロダクトの特性と対象顧客によって変わります。

SLG（営業主導型成長）：営業の力で成長する

SLG（Sales-Led Growth：営業主導型成長）は、営業チームが主導して顧客を獲得する伝統的な戦略です。エンタープライズ向けのSaaS企業の多くがこの戦略を採用しています。

SLGが適しているのは、単価が比較的高く、導入判断に説明や調整が必要な場合です。たとえば月額数万円から数十万円以上のBtoBサービスでは、費用対効果、セキュリティ、既存システムとの連携、運用体制などを確認したうえで意思決定されることが多くなります。こうしたプロセスでは、人による説明と説得が欠かせません。

意思決定に複数の関係者が関わる場合も、SLGが有効です。大企業では、現場の担当者、IT部門、調達部門、決裁者など、さまざまな人を巻き込む必要があります。それぞれの関心事や懸念に対応し、全員を納得させるには、営業担当者の調整力が必要です。

SLGの営業プロセスは、一般的に次のような流れになります。まず、マーケティングチームがMQL（Marketing Qualified Lead：マーケティング施策で獲得した見込み客）を獲得します。ホワイトペーパーのダウンロード、ウェビナーへの参加、デモリクエストなどがきっかけです。次に、インサイドセールスチームがMQLを評価し、有望なものをSQL（Sales Qualified Lead：営業対応すべき見込み客）に昇格させます。そして、フィールドセールスチームがSQLに対して、デモ、提案、交渉を行い、契約まで導きます。

SLGで重要なのは、営業効率を測る指標です。たとえば「マジックナンバー」という指標があり、四半期の新規ARRを前四半期の営業・マーケティング費用で割って計算します（この指標の基準値は企業や業界によって解釈が異なるため、自社の事業特性に合わせて評価するのが望ましいとされています）。たとえば、前四半期に営業・マーケティングに1億円投資し、今四半期に新規ARR8,000万円を獲得したら、マジックナンバーは0.8となります。

ランドアンドエクスパンド：小さく始めて大きく育てる

ランドアンドエクスパンドは、PLGとSLGの良いところを組み合わせた戦略です。最初は小さな契約から始め、徐々に拡大していきます。

典型的なシナリオはこうです。まず、一つの部署や小さなチームで試験導入してもらいます。月額5万円程度の小さな契約です。この段階では、決裁権限も低く、スピーディーに導入できます。数ヶ月後、成果が出始めると、他の部署も興味を持ち始めます。「営業部で使っているあのツール、マーケティング部でも使えないか」という声が上がります。半年後には全社導入の検討が始まり、月額100万円の契約に拡大します。1年後にはグループ会社にも展開し、月額500万円規模の契約に成長することもあります。

この戦略の利点は、顧客側の導入リスクを抑えられることです。いきなり全社導入するよりも、小規模な試験導入から始めるほうが、失敗時の影響を限定できます。また、実際に使ってみて価値を実感してから拡大するので、導入の成功率も高くなります。

ランドアンドエクスパンドを成功させるには、最初の成功体験が決定的に重要です。最初の部署で確実に成果を出し、社内でサクセスストーリーを作ることが重要です。そのためには、カスタマーサクセスチームが積極的に支援し、ベストプラクティスを提供する必要があります。

プロダクトの設計も重要です。小規模から始められるが、大規模にも対応できる拡張性が必要です。ユーザー数が10人から1,000人に増えてもパフォーマンスが劣化せず、部署ごとの権限管理ができ、他のシステムと連携できる。こうした企業導入に耐えうる機能が求められます。

NRR（純収益継続率）：既存顧客の成長力を測る

NRR（Net Revenue Retention：純収益継続率）は、既存顧客からの収益がどれだけ維持・成長しているかを示す指標です。新規顧客を除いて、既存顧客だけでどれだけ成長できるかを測ります。

NRRの計算方法を具体的に見てみましょう。期初（たとえば2024年1月）の既存顧客からの月間収益が1,000万円だったとします。1年後（2025年1月）、同じ顧客群からの収益を測定します。一部は解約し、一部はダウングレードしていますが、多くはアップグレードしています。結果、1,150万円になっていたとすると、NRRは115%です。

NRRが100%を超えているということは、新規顧客を一人も獲得しなくても、既存顧客だけで成長できるということです。これは投資家が重視する指標の一つで、優良なSaaS企業ではNRRが120%前後に達するケースも報告されています（具体的な基準値は業界や企業規模によって異なります）。

NRRを高めるには、いくつかの方法があります。まず、チャーン（解約）を減らすことです。解約が減れば、それだけNRRは向上します。次に、アップセルを増やすことです。顧客の利用状況を分析し、適切なタイミングで上位プランを提案します。そして、クロスセルで収益を増やすことです。関連製品やアドオン機能を追加購入してもらいます。

NRRが高い企業には共通点があります。それは、顧客の成功に本気でコミットしていることです。顧客がビジネス目標を達成し、成長すれば、自然とサービスの利用も増えます。逆に、顧客のビジネスが停滞すれば、サービスも不要になります。だからこそ、カスタマーサクセスが重要なのです。

第5章のまとめ——実務での判断軸

ここまでPLG、SLG、ランドアンドエクスパンド、NRRを見てきましたが、重要なのは、PLGかSLGかを二択で考えることではありません。特にBtoB SaaSやAIプロダクトでは、最初の接点はプロダクト主導で生まれても、本格導入ではセキュリティ、権限設計、既存業務との接続、費用対効果の説明が必要になります。つまり、成長戦略は「売り方」だけでなく、「導入後に価値が定着する構造」まで含めて設計する必要があります。

特に生成AIプロダクトの場合、セルフサービスで試しやすくする一方で、本番運用ではプロンプト設計、データ連携、出力品質の監視、ガバナンス対応といった領域で支援が必要になります。NRRを伸ばす鍵も、新機能の追加よりも、顧客の業務にどれだけ深く定着するかにあります。Qualitegでは、こうした「導入から定着までの設計」を、プロダクト設計と並行して伴走する形で支援しています。

第6章：キャッシュフローの罠を避ける

～資金繰りとユニットエコノミクス～

バーンレートとランウェイ：生存期間を把握する

スタートアップにとって、現金は事業継続の生命線です。どんなに将来性があっても、現金が尽きれば事業は続けられません。バーンレートは、毎月どれだけ現金を消費しているかを示す指標で、ランウェイは、今のペースで何ヶ月事業を継続できるかを示します。

バーンレートには、グロスバーンとネットバーンの2種類があります。グロスバーンは、毎月の総支出額です。オフィス家賃、人件費、サーバー代、マーケティング費用など、すべての支出を含みます。たとえば、月間支出が500万円なら、グロスバーンレートは500万円です。

ネットバーンは、総支出から収益を引いた額です。月間支出が500万円でも、収益が200万円あれば、ネットバーンレートは300万円です。これが実際に減っていく現金の額です。

ランウェイは、現金残高をネットバーンレートで割って計算します。現金残高が3,000万円で、ネットバーンレートが300万円なら、ランウェイは10ヶ月です。つまり、今のペースだと10ヶ月後に資金が尽きるということです。

一般的に、スタートアップは常に12〜18ヶ月分のランウェイを確保しておくべきとされています。なぜなら、資金調達には通常3〜6ヶ月かかるため、ランウェイが6ヶ月を切ってから動き出しても間に合わない可能性が高いからです。また、資金調達の交渉において、ランウェイが短いと足元を見られ、不利な条件を受け入れざるを得なくなります。

ペイバック期間：投資回収の時間軸

ペイバック期間は、顧客獲得コスト（CAC）を回収するまでの期間です。サブスクリプションビジネスのキャッシュフローを理解する上で極めて重要な指標です。

計算方法はシンプルです。CACを月間の粗利益で割ります。たとえば、CACが30,000円で、月間ARPUが5,000円、粗利益率が60%の場合、月間粗利益は3,000円です。ペイバック期間は30,000円÷3,000円＝10ヶ月になります。

なぜ粗利益で計算するかというと、売上から直接原価（サーバー代、決済手数料、AIプロダクトであれば推論コストなど）を引いた額が、実際に手元に残るお金だからです。売上が5,000円でも、原価が2,000円かかれば、実際には3,000円しか残りません。

ペイバック期間が重要な理由は、キャッシュフローに直結するからです。ペイバック期間が12ヶ月ということは、顧客を獲得してから1年間は投資分が回収できていないということです。100人獲得すれば、1年間は100人分の未回収コストを抱えることになります。成長すればするほど、キャッシュが必要になるのです。

業界のベンチマークとして、BtoB SaaSではペイバック期間12ヶ月以内が一つの目安とされ、6〜9ヶ月であれば健全、6ヶ月未満なら非常に効率的と評価されることが多いようです（具体的な基準は事業モデルや顧客セグメントによって異なります）。BtoCの場合は、さらに短く、3〜6ヶ月が一つの目安とされます。BtoCのほうが短い理由は、チャーン率が相対的に高く、長期間かけて回収するリスクが大きいからです。

ペイバック期間を短縮する方法はいくつかあります。CACを下げる（広告の効率化、自然流入の増加）、ARPUを上げる（価格改定、アップセル）、粗利益率を改善する（原価削減、効率化）などです。また、年間契約で前払いしてもらうことで、キャッシュフローを大幅に改善できます。

Rule of 40：成長と収益性のバランス

Rule of 40は、成長率と利益率の合計が40%以上であるべきという経験則です。たとえば、年間成長率60%で利益率-20%なら合計40%、年間成長率30%で利益率15%なら合計45%となります。

この指標が生まれた背景には、SaaS企業のジレンマがあります。高成長を追求すれば赤字になり、黒字化を急げば成長が鈍化する。どちらを優先すべきか、多くの経営者が悩みます。Rule of 40は、この両者のバランスを評価するシンプルで実用的な指標です。

アーリーステージでは、黒字化よりも成長を優先する判断が取られることもあります。たとえば高い成長率を維持できている場合、一定の赤字を許容しながら市場シェアの拡大を優先するケースがあります。ただし、資金調達環境や投資家の見方によって評価は大きく変わるため、Rule of 40はあくまで一つの目安として扱うべきです。上場を視野に入れる段階になると、年間成長率40%で利益率10%（合計50%）のような、よりバランスの取れた数字が求められる傾向があります。

Rule of 40を改善する方法は、ステージによって異なります。高成長だが赤字の企業は、ユニットエコノミクスの改善に集中すべきです。LTV/CAC比率を3倍以上に高め、ペイバック期間を短縮する。一方、黒字だが低成長の企業は、新たな成長要因を見つける必要があります。新市場への展開、新製品の開発、M&Aなどが選択肢になります。

LTV > 3 × CAC：黄金律の正しい使い方

LTV（顧客生涯価値）がCAC（顧客獲得コスト）の3倍以上であるべきという黄金律は、サブスクリプションビジネスの健全性を測る最も重要な指標です。なぜ3倍なのか、改めて整理しましょう。

まず、顧客獲得にかかったコストを回収する必要があります（1倍）。次に、その顧客をサポートし、サービスを提供するための運営コストをカバーする必要があります（もう1倍）。そして、ビジネスを成長させるための再投資資金と、投資家へのリターンを生み出す必要があります（さらに1倍）。合計で3倍です。

ここで重要なのは、LTVを計算する際に粗利益率を考慮することです。前回の記事では簡易計算として「LTV = 月額料金 ÷ チャーン率」を紹介しましたが、より実務的な計算式は次のようになります。

LTV = ARPU × 粗利益率 ÷ チャーン率

なぜ粗利益率を含めるかというと、売上のすべてが利益になるわけではないからです。サーバー代、決済手数料、カスタマーサポートのコスト、生成AIプロダクトであれば推論コストなど、顧客一人を維持するのにも原価がかかります。これを差し引かないと、LTVを過大評価してしまいます。

実際の計算例を見てみましょう。あるSaaSサービスのデータです。

この例では、LTV/CAC比が8倍と非常に高い数字です。これは効率的なビジネスで、積極的に投資して成長を加速すべき状態と言えます。粗利益率を考慮しない場合のLTVは500,000円になりますが、実態を反映した正確な数値は400,000円です。この差は、事業判断の精度に直結します。

多くのスタートアップは、初期段階でLTV/CAC比が1倍を下回ることも珍しくありません。これは必ずしも悪いことではなく、プロダクトマーケットフィット（PMF）を探している段階では、効率より学習を優先すべきだからです。重要なのは、PMFを見つけた後、速やかにLTV/CAC比を3倍以上に改善することです。

LTV/CAC比を改善する手段は複数あります。LTVを上げるには、チャーン率を下げる、ARPUを上げる、アップセル・クロスセルを増やすなどの方法があります。CACを下げるには、CVRを改善する、自然流入を増やす、紹介プログラムを強化するなどの方法があります。どの手段が最も効果的かは、ビジネスの状況によって異なりますが、一般的にはチャーン率の改善が最もインパクトが大きいとされます。

第6章のまとめ——AIプロダクトでは原価構造の可視化が鍵

生成AIプロダクトでは、従来のSaaS以上に原価構造の把握が重要です。推論コスト、外部API利用料、ログ保管、監査対応、カスタマーサクセス負荷が、粗利益率やペイバック期間に直接影響します。一人あたり月額1万円の売上があっても、ヘビーユーザーのAPIコストが月5,000円を超えてしまえば、粗利益率は50%を切り、ペイバック期間は倍近く伸びます。

したがって、単にユーザー数やARRを見るだけではなく、「どの顧客が、どの機能を、どれだけのコストで使っているか」を早い段階から可視化することが欠かせません。プランごとの利用上限設計、ヘビーユーザー向けの従量課金、モデルの使い分けによる原価最適化など、プロダクト設計と価格設計を一体で考える必要があります。Qualitegでも、AIプロダクトの原価可視化と価格設計の支援を行っています。

第7章：実践的な改善アプローチ

～データドリブンな最適化～

ファネル分析で改善ポイントを特定する

ファネル分析は、顧客が認知から購入、そして継続利用に至るまでの各段階を可視化し、どこで離脱しているかを特定する手法です。漏斗（ファネル）のように、段階が進むにつれて人数が減っていく様子を分析します。

典型的なSaaSのファネルを見てみましょう。まず、10,000人がウェブサイトを訪問したとします。そのうち3%（300人）が無料登録をします。登録した300人のうち、30%（90人）が無料トライアルを開始します。トライアルを開始した90人のうち、20%（18人）が有料プランに移行します。そして、有料化した18人のうち、90%（16人）が1年後も継続しています。

このファネルを見ると、最大のボトルネックは「無料登録→無料トライアル」の30%という転換率です。ここを改善することで、最も効率的に有料顧客を増やせます。たとえば、この転換率を30%から40%に改善できれば、有料顧客は18人から24人に、33%も増加します。

ファネル改善の具体的な施策を見てみましょう。「サイト訪問→無料登録」の転換率を上げるには、登録フォームの項目を減らす、ソーシャルログインを導入する、登録のメリットを明確に伝える、といった方法があります。たとえば、登録フォームの項目を10個から3個に減らすことで転換率が大きく改善した例も報告されています。

「無料登録→無料トライアル」の転換率を上げるには、オンボーディングメールの改善、製品ツアーの提供、カスタマーサクセスからの能動的な連絡などが効果的です。特に、登録後24時間以内のアクションが決定的に重要です。この時間内にユーザーが価値を感じなければ、二度とログインしない可能性が高いからです。

「無料トライアル→有料化」の転換率を上げるには、トライアル期間中の利用状況をモニタリングし、利用が少ないユーザーには追加サポートを提供する、トライアル終了前にリマインダーを送る、限定オファーを提示する、といった施策が有効です。

コホート分析で顧客の質を評価する

コホート分析は、同じ時期に獲得した顧客グループ（コホート）の行動を時系列で追跡する手法です。これにより、顧客の質の変化や、施策の効果を正確に測定できます。

たとえば、2024年1月に獲得した100人の顧客コホートを見てみましょう。2月には90人（90%）、3月には85人（85%）、4月には82人（82%）、5月には80人（80%）が残り、それ以降は80人前後で安定したとします。一方、2024年4月に獲得した100人のコホートは、5月に85人（85%）、6月に75人（75%）、7月に68人（68%）、8月に62人（62%）と、継続的に減少を続けたとします。

この分析から、1月コホートは質が高く、4月コホートは質が低いことが分かります。なぜ4月の顧客の質が低いのか、調査する必要があります。もしかしたら、4月に実施した大規模キャンペーンで、ターゲット外の顧客を獲得してしまったのかもしれません。あるいは、競合が新サービスをリリースし、比較検討で負けているのかもしれません。

コホート分析は、収益ベースでも行うべきです。顧客数は減っていても、残った顧客がアップグレードしていれば、収益は増加している可能性があります。理想的なのは、一部の顧客が解約しても、残った顧客のアップセルやクロスセルによって既存顧客群全体の収益が増える状態です。これは一般に「ネガティブチャーン」と呼ばれます。

コホート分析の結果を改善に活かす方法をいくつか紹介します。まず、優良コホートの特徴を分析し、そうした顧客を意図的に獲得する戦略を立てます。たとえば、特定の業界や企業規模の顧客の継続率が高いなら、そこにマーケティング投資を集中させます。

次に、質の低いコホートの改善です。すでに獲得してしまった顧客の性質は変えられませんが、オンボーディングやカスタマーサクセスを強化することで、継続率を改善できる可能性があります。特定のコホートに特化した再エンゲージメントキャンペーンも有効です。

最後に、季節性の把握です。多くのビジネスには季節性があります。たとえば、会計ソフトは確定申告の時期（2〜3月）に獲得した顧客の継続率が高い傾向があります。この知見を活かし、その時期にマーケティング投資を集中させる戦略が取れます。

A/Bテストによる継続的改善

A/Bテストは、2つ（またはそれ以上）のバージョンを同時に検証し、どちらがより良い結果を生むかを科学的に確かめる手法です。サブスクリプションビジネスでは、ウェブサイト、メール、プロダクト機能、価格など、あらゆる要素でA/Bテストを行う価値があります。

価格のA/Bテストは特に効果的です。たとえば、月額5,000円で提供していたサービスで、新規顧客を2グループに分け、Aグループには5,000円、Bグループには7,000円を提示したとします。結果、転換率はAグループが20%、Bグループが18%でした。一見Aグループのほうが良さそうですが、収益で計算すると、Aグループは5,000円×20%=1,000円、Bグループは7,000円×18%=1,260円となり、Bグループのほうが26%も収益が高いことが分かります。

なお、価格のA/Bテストは顧客体験や公平性への配慮が必要です。特にBtoBでは、同じ条件の顧客に異なる価格を提示すると信頼を損なう可能性があるため、プラン設計、訴求軸、割引条件など、検証対象を慎重に設計する必要があります。新規の検討段階でのランディングページ訴求や、時期をずらした段階的な価格改定の効果検証など、顧客に不公平感を与えない形で設計することが重要です。

オンボーディングのA/Bテストも効果的です。たとえば、製品ツアーを「スキップ可能」にするか「必須」にするかで検証した場合、必須にしたほうが、短期的には離脱率がやや上がる一方で、長期的な継続率が大きく向上する、といった結果が得られることがあります。最初は面倒でも、しっかり価値を理解してもらうことの重要性が示されるケースです。

メールの件名のA/Bテストは、最も簡単で効果的な施策の一つです。「期間限定！30%オフ」対「あなただけの特別オファー」、「新機能リリースのお知らせ」対「作業時間を50%削減する方法」など、異なるアプローチを検証します。開封率が数%改善するだけでも、その後のクリック率や成約にも連動して良い影響が出ます。

A/Bテストを行う際の注意点があります。まず、統計的な信頼性を確保することです。必要なサンプル数は、現在の転換率や検出したい改善幅によって変わります。少数のサンプルで判断すると、偶然の差を成果と誤認するリスクがあります。テスト期間も重要で、週末と平日で行動が異なる場合があるため、最低でも1〜2週間は継続して見るのが無難です。

第7章のまとめ——データドリブンは数字を眺めることではない

データドリブンな改善とは、数字を眺めることではありません。どの顧客に、どの価値が、どのタイミングで伝わっていないのかを特定し、プロダクト、営業、カスタマーサクセス、価格設計を同時に調整していくことです。

特にAIプロダクトでは、導入初期の期待値調整とオンボーディングが、その後の継続率に大きく影響します。生成AIは万能ではなく、得意・不得意があり、期待値を誤ったまま使い始めた顧客は、早期に「思ったほど使えない」と判断して離脱しがちです。ファネル分析やコホート分析で早期離脱の傾向を捉え、オンボーディングで正しい期待値とユースケースを丁寧に伝える設計が、結果としてLTVを大きく左右します。

Qualitegは自社サービスで得た知見をもとに、プロダクトの改善サイクルと並行して、指標設計・データ分析・カスタマーサクセスの運用を一体でご支援しています。数字を見る体制を作るだけでは不十分で、その数字から次の打ち手を導き、実際に実行まで落とし込める組織にすることが重要だと考えています。

次回予告

次回の第4回では、サブスクリプションビジネスでよくある失敗パターンと、その対策について詳しく解説します。フリーミアムの罠、過度な機能追加による複雑化、ダウンセルの軽視など、多くの企業が陥る落とし穴を、AIプロダクト特有の観点も交えながら掘り下げていきます。

それでは次回またお会いしましょう！

2026年時点での、過去からのNVIDIA GPU一覧を簡単にフィルタリングできるようにいたしました！GPU選定にお役立ていただけます！

関連ポスト

2025年 NVIDIA GPU 一発検索ツール(2025/8/5更新)

NVIDIA GPU 一覧検索 シリーズ すべて SM_100 (Blackwell) SM_90 (Hopper) SM_89 (Ada Lovelace) SM_86/SM_87 (Ampere) SM_75 (Turing) SM_70/SM_72 (Volta) SM_60/SM_61/SM_62 (Pascal) SM_50/SM_52/SM_53 (Maxwell) SM_35/SM_37 (Kepler) SM_20 (Fermi)

Qualiteg BlogQualiteg プロダクト開発部

NVIDIA GPU と Capability Level

NVIDIA GPU の Capability Level の一覧です。 推論エンジンがサポートする各種アクセラレーション機能は Capability Level により搭載されるハードウェアアクセラレータや専用機能が異なります。 データセンター/プロ向けGPU GeForce GPU Capability Level 世代名 - GeForce RTX 5090 120 Blackwell - GeForce RTX 5080 120 Blackwell - GeForce RTX 5070 120 Blackwell - GeForce RTX 5060 120 Blackwell NVIDIA B200 - 100 Blackwell NVIDIA B100 - 100

Qualiteg BlogQualiteg プロダクト開発部

PyTorchバージョンとNVIDIA GPU Compute Capability Level サポート

古いPyTorchコード資産を持っている会社は、昔のコードが最新のPyTorchで動かない！最新のGPUで動かない！ということに遭遇することが多いのでしょうか。 今回は、PyTorchバージョン、対応GPU Capability Level 、対応CUDAバージョンについてまとめてみます。 PyTorchがサポートするGPUの Compute Capability PyTorch バージョン サポートされる Compute Capability (SM) レベル 1.0.0 - 1.3.1 SM_35, SM_37, SM_50, SM_60, SM_61, SM_70 1.4.0 - 1.7.1 SM_37, SM_50,

Qualiteg BlogQualiteg プロダクト開発部

こんにちは！
Qualitegビジ開マーケティング部です！

2026年4月15日(水)から16日(木)までの2日間、幕張メッセで開催された「Startup JAPAN EXPO 2026」(主催:Eight / Sansan株式会社)に、
株式会社Qualitegとして出展してまいりました!

Startup JAPAN EXPO 2026 出展概要

今回の展示テーマは——

「依頼は並列に、思考は止めず。」

主力プロダクト「Bestllam®」に新搭載されたAIエージェント機能と、AIセキュリティソリューション「LLM-Audit™」の実演デモを、2日間にわたってお届けしました。

ブース番号は 16-16。展示ホール7・8の一角に、今回も気合いを入れて陣を構えました💪

プレスリリース

株式会社Qualiteg、「Startup JAPAN EXPO 2026」に出展

株式会社Qualitegのプレスリリース（2026年4月13日 10時00分）株式会社Qualiteg、「Startup JAPAN EXPO 2026」に出展

PR TIMES株式会社Qualiteg

開催前日【0日目】前夜祭「もう遅刻はしない」——前線基地、爆誕🏨

今回のレポート、まずはここから書かせてください。

前回のCEATEC 2025、覚えている方もいらっしゃるかもしれません。

そう、「最後に来て最後まで残る」 という新ジャンルを開拓してしまった、あの伝説の回です・・・。

深夜の幕張メッセ、誰もいない展示ホール、頭上に輝くオリオン座🌌——あの光景、美しかったけれど、二度と見たくはありません😇

そこで今回、私たちはある決意をしました。

「今度こそ、遅刻寝坊を撲滅する（💦）」

その名のもとに、前日入りを敢行。

幕張メッセ直結＆徒歩圏のアパホテル＆リゾート〈東京ベイ幕張〉に、"前線基地"　を設営することにしたのです

前線基地からは、眼科に幕張メッセがバッチリ見えます（ちなみに左上はZOZOマリンスタジアム🥎です、試合してました＾＾）

さて、現地での対応は、マーケチームの元気メンバー3名体制。エンジニアも帯同し、何があってもその場で技術対応ができる布陣です。

「これで完璧だろう」

・・・と、このときの私たちは思っていました

実は、デモには"舞台装置"がありました

前日入りしたその夜、前線基地の一室で、改めて2日間分のデモのリハーサルを回していました。

ここで少しだけ、デモの裏側の話をさせてください。

Bestllam® AIエージェントのデモで、私たちがどうしても見せたかったのが——

「日本企業の業務現場に、本当に溶け込んでいる感じ」

でした。

「AIエージェントがWeb検索して、要約してくれます」——それだけなら、そんなに珍しくない時代です。

私たちがお見せしたかったのは、もう一段奥、

"基幹システムや売上管理DBと連携して、業務の中で働くエージェント"

そこで、今回のデモのために、エンジニアチームが
企業の基幹システムや売上管理DBを模した"模擬MCPサーバー"
を自作していたのです🛠️

• 架空の顧客マスター(数千件)
• 架空の売上トランザクション
• 架空の契約情報、社外秘の案件名
• 架空の勤怠データ
• 架空の契約書・議事録・顧客対応メモなどの業務文書

これらが、本物の基幹システムっぽい挙動でレスポンスを返す——そんな舞台装置を、ブースの裏で動かす予定でした。

これがあるから、

• 1日目のBestllamデモでは、エージェントが「先月の売上トップ5を部署別に集計して、来月の見込みと並べてPowerPointでまとめて」みたいな指示で、模擬DBを叩いて結果を返せる
• 2日目のLLM-Auditデモでは、模擬基幹システムから引いてきた"いかにも機密情報"なテキストを、そのままLLMに送ろうとしたときにリアルタイムで検出・マスキング・仮名化できる

——という、2日間を貫く一本のストーリーが成立するわけです。

ところが、その模擬MCPが、夜に入って不機嫌になった

前線基地でリハーサルをしていたエンジニアが、ぽつり。

「・・・あれ、これ、挙動ブレてない?」

症状は、地味で嫌な感じのやつでした。

• 複数サブエージェントが並列でアクセスしたときに、レスポンス順がたまにバラつく
• 特定の問い合わせパターンで、返すデータのスキーマが微妙に揺れる
• 結果、エージェントが"念のためリトライ"を挟んで、体感で数秒モタつく

プロダクト本体(Bestllam / LLM-Audit)は、完璧に動いています。本社のスタジオ環境では、何度も動作確認済みです。

不機嫌なのは、私たちが今回のデモのために自作した、模擬基幹システムMCPのほうでした。

でも、来場者の方から見たら、そんな裏側は関係ない。

「エージェントが、なんか待たされてる」

——そう見えた瞬間に、「依頼は並列に、思考は止めず」というメッセージの説得力が、コンマ数秒単位で目減りしていく。

展示会のデモは、コンマ数秒の違和感を、許さない。

「じゃあ、やるか」——赤飯おにぎり、魂の燃料🍙

前線基地(アパホテル幕張)の一室に、緊急の作戦司令室が爆誕しました🔧

• 模擬MCPの並列処理ロックの見直し
• レスポンススキーマの固定化
• 想定される指示パターンの洗い出しと、それに対する応答の事前リハーサル

・・・気づけば、お腹がペコペコ。

ホテル２Fのローソンにダッシュして、赤飯おにぎりを大量に買い込んできました🍙

「なんで赤飯?」 と聞かれたら、理由はありません。なんとなく目に入った瞬間、"験担ぎ" のスイッチが入ってしまったのです。

「明日、初陣なので」

そんな謎の理由で、深夜の前線基地で赤飯おにぎりをばくばく食べながら、作業を続けました。

(ちなみに赤飯のカロリーは全て"魂の燃料"という名目で処理されました。栄養学的にはどうなんでしょう😇)

おにぎりを頬張りながら、模擬MCPを叩き、ログを見て、また直す。

"舞台装置"が完璧に動かないと、主役(Bestllam / LLM-Audit)の本当の魅力は伝わらない——そんな気持ちで、メンバー全員(リモート参加のエンジニアメンバーも）が手を動かし続けました。

気づいたら、明け方。

ふとカーテンを開けると——

zozoマリンスタジアムの奥、白みはじめた東京湾の向こうに、うっすらと塔のようなものが浮かんでいました、

東京スカイツリー、でした！

なんだか神々しい！

ちょっと湿った朝の空気。

眼下に広がる夜明け特有の静かな佇まいが、これから始まる戦いの舞台に見えました。

模擬MCPが安定して動き出したとき、エンジニアは満足そうに一言。

「よし、舞台、整ったぞ。初日、やれる気がする」

謎の確信を得て、私たちは1日目の戦場へ向かいました。

【1日目】Bestllam AIエージェント——"専任チーム"が動き出す瞬間

午前中はやや曇っていた空も、ブースがオープンする頃には、気持ちよく晴れてきました🌞

天気と同じく、1日目のブースも、気持ちよく走り出しました。

初日のメインは、Bestllam® の新機能 AIエージェント。

従来のAIチャットの体験って、「人間がAIの返答を待ってから次を考える」——この往復構造に縛られていますよね。AIを使うほどに思考が寸断されていく、あの感じ。

Bestllamの新しいAIエージェントは、これをひっくり返します。

指示した瞬間、自分だけの専任チームが動き出す。

統括エージェントが司令塔となり、複数のサブエージェントが並列でリサーチ、資料作成、データ整理、メール下書きなどを非同期に進めていく。ユーザーは返答完了を待たずに、次の指示をどんどん重ねていける。

• 「先月の売上トップ5を部署別に集計して、来月の見込みと並べて」
• 「同時並行で、主要顧客への訪問スケジュールもドラフトしておいて」
• 「ついでに、その訪問内容を部長向けの報告書フォーマットで一枚にまとめて」

・・・と、指示をどんどん重ねていくことがもうできるようになっています

こういったAIエージェント機能は、特に経営層や事業責任者の方々からの反応が熱く、

「社内でAI使ってるけど、結局1人で作業してる感覚と変わらなかった。これは"チーム"ですね」

という、まさに私たちが狙っていたど真ん中のコメントをいただけたときは、開発チームに代わってガッツポーズしてしまいました👊

"基幹システムと繋がって働いているAIエージェント" の感触が、ちゃんと伝わった瞬間でした

おかげさまで1日目のブースは、熱気につつまれました。

連日の準備で少し疲れていたメンバーも、来場者の皆様の反応にエネルギーをもらい、閉幕のアナウンスが流れるまでデモ回し続けました。

Qualitegをさがせ！

さて、会場全体もたいへんな熱気につつまれていました。

１日目の会場はこんなかんじです。すごいですね！

さてここで、問題です。

当社 ㈱Qualitegのブースはどこでしょう？

ヒント：クリエイティビティを深化させようとするエネルギーが最も解き放たれているところ

AIチャット を入れただけでは真の業務改善には程遠い

ここで当社の提供するコンサルティングについても、触れさせてください。

当イベントでも、ブースを来場・ご予約いただいたお客様の課題として、

・生成AIを導入したがチャットだけでは業務効率化にはつながらない
・PoCまではいくが、全社展開となると難しい

といった課題や、

・生成AIを使った情報システム開発の刷新をしたいが、どこから手を付けたらいいのか、どのような開発プロセスの変革が必要なのか、全体像が整理できてない

といった課題の声をいただきました。

まさに、ここは当社の得意とする部分なのですが、
単にツールやSaaSを開発・提供して「はい、つかってください」だけで本当の変革を実現することは難しいです。

当社は外資系コンサルティングファームで長年経験を積んだコンサルタントチームとAIの専門家チームがタッグを組んで、本当の変革につながるAI業務改善をご支援しております。

今回のイベントでは、そうした課題意識のあるお客様にもご来場いただき、早速、イベントご来場者様向けの無料のスポットコンサルの打診をいただきました。このたび、イベント出展記念として無料のスポットコンサル枠を増やしておりますので、ご興味のある方は こちら までお問い合わせくださいませ。

先ほどの答え、Qualiteg ここです

さて、さきほどの Qualitegを探せ はいかがでしたでしょうか？

簡単でしたか？

答えは以下となります。

このようなたくさんのブースの中から当社にご来訪、ご面談予約をいれていただきました、皆様、あらためて御礼もうしあげます。

【1日目夜】"機密文書エンドポイント"、再び荒ぶる🌙

さて、1日目を終えて前線基地に戻るエレベーターの中で、展示担当メンバーは達成感でいっぱいでした。

「明日も頑張るぞ〜」

そう、明日・2日目の主役は、LLM-Audit™です

LLMに機密情報が送られる前段で、リアルタイムに検出・ブロック・マスキング・仮名化する仕組みです。たとえば、

「田中太郎さん(090-1234-5678)から問い合わせがありました」

を、LLMに送ろうとした瞬間に、

「[顧客A]さん([電話番号])から問い合わせがありました」

へと一瞬(数ms)で変換してみせる、あの "セキュリティチェックの存在を感じさせない気持ちよさ" つまり、ちゃんとセキュアだけど、AIを使ってる時にセキュリティチェックを感じさせないということは当プロダクトのUXの命です。

そして、このデモを本当にリアルに見せるためには、
（ホントの機密情報はだせませんが）"いかにも機密情報"な業務文書を、
模擬基幹システムMCPから引いてくる必要があります。

軽いエンドポイントはOK、でも"長文文書"は未検証だった

0日目夜に直した模擬MCPは、軽いデータを返す系のエンドポイント——売上集計、スケジュール、顧客ID・・・そういう構造化データは、1日目に何とか乗り切りました。

しかし、契約書・議事録・顧客対応メモ・稟議書といった長文の業務文書を返すエンドポイントは、1日目には一度も叩いていなかったのです。

2日目のリハーサルとして、その機密文書エンドポイントを叩いてみると——

「・・・あ」

エンジニアの表情が、また曇りました

症状は、これまた地味で、しかし致命的なやつでした

• 長文テキストにPIIが入っていない（デモの見せ場がない）場合がある
• その結果、LLM-Audit側の検出エンジンが、引っかかるときと、すり抜けちゃう瞬間がときどき発生
• 用意していた機密文書のバリエーションが圧倒的に足りない——来場者の方に何度触っていただいても、同じ議事録と同じ契約書が出てきてしまう

LLM-Audit本体の検出エンジン(PII-Fi™)は、完璧に動いています。

不機嫌なのは、またしても模擬基幹システムMCPのほう。しかも今度は、"機密情報を引いてくる"という一番肝心なところで躓いた形です。

「昨日の今日かよ・・・!!」

思わず天を仰ぎました🙄

でも、この問題を放置して2日目を迎えるわけにはいきません。

LLM-Auditのデモは、"あ、こんな自然な文章の中からも見つけ出すんだ!" という驚きが命。でもまったくＰＩＩが入っていない文章だと、さすがにみつけだせないので、でも、ランダム生成のいかにも機械的な文章では、検出されて当然すぎて面白くないのです。

実務で本当に飛び交っているような、自然な日本語の業務文書——それを、比較的大量に用意する必要がありました。

「じゃあ、やるか」——2夜連続

前線基地の作戦司令室、2夜連続稼働が決定しました

昨夜は模擬MCPの骨格を直し、今夜は模擬MCPから引き出すコンテンツを仕上げる。

昨夜は赤飯でしたが、今夜は——

「ピザ、食べよう」

深夜までやっているアパホテル内のお店(MOMOCAFEさん)にダッシュ、ピザをテイクアウトで買ってきました🍕

「ピザ、うますぎる・・・」

昨夜の赤飯おにぎりと並ぶ、深夜の"魂の燃料"。深夜のピザのカロリーは全て(以下略)。

ピザを頬張りながら、作業内容はこんな感じでした

• 契約書・議事録・顧客対応メモ・稟議書——架空のパターンを、ひたすら書き起こす(マーケ担当で創作します) まぁ、BestllamでLLM使って作ることもできますが、それじゃあまりにもつまらない。
• 文書の中に「田中太郎様」「株式会社〇〇商事」「090-1234-5678」「第3四半期決裁案件 — 社外秘」といったリアルな埋め込みを自然に混ぜ込む
• そして、わざと表記揺れを入れ込む。表記ゆれに強いので。マーケ担当はPII処理の内部ロジックを知らないので、検出しやすい文章にならないのもいいんです。
• 最後に、LLM-Audit側で検出〜仮名化〜表示までの体感速度を、もう一段気持ちよく見えるように整える

ちなみに、実はデモのことを考えてこうやって展示会で準備すると、普段のオフィスでの開発より進んだりするんです。だから実際には、体験デモにこぎつけないときも、こうやってリアルを想像してデモすることって本当に重要だと、１０回以上展示会に本気出展してみて、きづきました。

深夜4時——「あれ、これURL、まちがってない?」

時刻は、深夜4時を回ったころ。

前線基地の一室。模擬MCPと架空議事録の格闘が、ようやくゴールが見えてきた頃でした。

コードを書いていたエンジニアが、机の端に置かれていたブース配布用のチラシを、何の気なしに手に取りました。

「・・・あれ、これURL、まちがってない?」

部屋の空気が、ピシッと凍りました🧊

「え」 「え?」 「ええええええ!?」

メンバーが机に駆け寄ります。

確認してみると——2日目にフィーチャーするLLM-Audit™の紹介QRコードと遷移先URLに、不備があったのです。

1日目はBestllamの展示が中心だったので、誰も気づかなかった。でも2日目の主役はLLM-Audit。このまま配ったら、来場者の皆様を間違ったページに案内してしまう。

展示会のチラシ・ポスターは、名刺代わりの顔です。しかも、LLM-Audit™の興味を持ってくださった方をお連れする先——つまり、一番届けたい情報への入り口が間違っているということ。

「これは、直さないと開場には立てない」

全員の意見は一致しました。

「アクセアさん、お願いします・・・!!」

全速力でポスターとチラシのデータを修正。正しいURL、正しいQRコード、正しい遷移先。深夜4時の前線基地で、もう一度ディレクターチェック、プルーフリーディング、最終確認。

そして頼みの綱は幕張メッセ近くにあるアクセア 海浜幕張店さま。

開店は、朝8時。

「いまのうちにWeb入稿して、アクセア様開店の8時ジャストできづいてくだされば、9時には刷り上がる・・・かもしれない」 「開場は10時・・・ギリッギリ」 「祈ろう」

データを入稿フォームにセットし、送信ボタンに指を載せたまま、みんなで本気の祈りを捧げました🙏

「アクセアさん、お願いします・・・!!」

深夜対応明け、そして快晴

そこまでやって、ようやく、前線基地の作戦司令室は店じまいとなりました。

• 模擬MCPの機密文書エンドポイント→修正完了✅
• 架空業務文書のバリエーション→書き起こし完了✅
• ポスター・チラシのURL修正→入稿完了✅

目の下にクマを貯金しながら、それでも不思議と充実感がありました。

充実感は、きっと、やらされてるんじゃなくて、やりたくてやってるからですね

そして、気づいたら、
また朝じゃん。

カーテンを開けると——

おおー、富士山🗻が見えるではありませんか。

前日の曇天とは打って変わって、東京湾の向こうからうっすらした富士山、

幕張メッセの屋根が、光を反射してキラキラ光ってる

「よし、2日目、やれる」

2夜連続の深夜対応明けですが、快晴の空が、なんだか背中を押してくれる気がしました♪

【2日目】LLM-Auditデモ——"しみじみ"聞こえてきたAIセキュリティの本音

2日目は、LLM-Audit™ が主役。

その前に——アクセアさんからの朝イチの電話📞

朝、快晴の空の下を幕張メッセに向かって歩いていたメンバーの携帯が、震えました。

「先ほどいただいたデータ、急いで刷っておきました。いつでも取りに来てください!」

・・・一瞬、立ち止まりました。

「ほ、本当に・・・!?」

深夜に祈りながら入稿したデータが、開店と同時に印刷されて、もう刷り上がっている。

こちらの「なんとかギリギリで間に合わせたい」という都合を、電話の向こうの担当者さまが完全に汲み取って、全力で作業してくださったのが伝わってきました。

電車移動組メンバーに駅前にあるアクセアさんにポスターをとりにいってもらい、無事ことなきをえました

アクセア 海浜幕張店のスタッフの皆様——本当に、本当にありがとうございました🙇‍♂️🙇‍♀️

あの突然の深夜入稿。事情の説明も最小限だったはずなのに、こちらの意図を読んで、朝イチで仕上げて、朝イチで電話をくださる。これこそ、プロの心意気だと、感動しました。

修正したてのチラシ・ポスターを抱えて、私たちは2日目のブースへと滑り込みました。間に合った。

いざ、LLM-Audit出展

刷り立てホヤホヤの正しいチラシ・ポスター。準備は、文字通り最後の一瞬まで整えました🙏(前夜と前々夜の自分たち、そしてアクセアさん、本当にありがとうございました)

LLM-Audit(PII-FI)では

• 「電話番号や住所が入ったテキスト」 → 一瞬でマスキング
• 「顧客名+契約金額」 → 仮名化して文脈を保ったままLLMへ
• 「社外秘のキーワード」 → 事前学習済みのPII-Fi™が即検知してブロック
• 「議事録の中に自然に混ざった、敬称付きの人名と案件名」 → 日本語特有の表記ゆれも含めて検出

を一瞬(数ms）で実行することができます

"しみじみとしたお悩み"、聞こえてきました

そして今回、何より印象的だったのは、来場いただいた方々から聞こえてきた"しみじみとしたお悩み" でした。

「うちの社員、もう勝手にChatGPTに会議の議事録投げちゃってるんですよ・・・」 「契約書の内容をAIに要約させてるのが発覚して、法務が青ざめてて」 「シャドーAI、どうやって止めたらいいんでしょうか」

・・・ここ、少し真面目に書かせてください。

私たちがLLM-Auditを作り始めたとき、最初に想定していたのは「悪意ある攻撃者からLLMを守る」というユースケースでした。
つまり自社が作ったAIに対する攻撃(ジェイルブレイク)や不適切出力、春市ネーションの検出といった分野です。

でも、開発を続ける中で、

本当に深刻なのは、
悪意なき日常業務からの情報漏洩

のほうが「待った無し」だ、という確信に変わっていきました。

（もちろんジェイルブレイクやプロンプトインジェクションといった課題に対してもLLM-Auditは活躍しますし、当社のAIレッドチームが日夜腕を磨いています💪)

今回、まさにその現場のリアルな声を、たくさん聞かせていただきました。

• うっかりAIに機密情報を送ってしまう
• 便利だからと社員が個人契約のAIを使い始める(シャドーAI)
• 気づいたときには、情報がどこに流れたか追跡できない

これらは、LLM-Auditがまさにカバーしたい領域そのものです。

「あ、私たちの方向性、間違ってなかったんだ」

ブースの中で、チームが静かに目を合わせて頷いた瞬間がありました🥹

まさにその"最後の一歩"を支えるために存在しているのだと、改めて腹落ちした時間でした。

【2日目夕方】前線基地から見た、あの夕日🌇

さてさて、
長かった2日間の展示も、クロージングの時間。

ブースを片付け、荷物をまとめて、前線基地に戻ってきたのは夕方でした。

エレベーターで高層階まで上がり、ふと窓の外を見ると——

最高に、きれいでした。

東京湾の向こうに沈んでいく夕日。

オレンジとマリンブルーが溶け合う瞬間。

「2日間、ほんとに走り切ったな」

「ピザうまかったな」

「アクセアさん、本当に救ってくれたな」

「あの人、めっちゃ笑ってくれたな」

しばらく無言で夕日を眺めていました。

展示会というのは、準備から本番、撤収まで含めて、本当に"ドラマ" だなと思います。

赤飯おにぎりを頬張った0日目の夜も、1日目の曇り空も、熱気も、ピザを頬張った1日目の深夜も、"架空の議事録"を書き続けた作業も、深夜のポスター事件も、アクセアさんからの朝イチの電話も、快晴の朝の空も、お客様の"しみじみ"した一言も、ホリエモン講演の熱気も、全部ひっくるめての2日間。

この夕日は、走り抜いた人にだけ見せてくれるご褒美だったのかもしれません🥹

まとめ 〜未来への手応え〜

今回のStartup JAPAN EXPO 2026は、2日間という短い期間でしたが、Qualitegにとって大きな意味を持つ2日間になりました。

Bestllam® AIエージェントへの想像以上の反響

「依頼は並列に、思考は止めず」というコンセプトは、来場者の方々の体感として深く届いたという手応えがありました。

特に経営層・事業責任者の方々からの熱い反応は、私たちが目指している "働くAI" の方向性が、確かに日本のビジネス現場に求められているものだという確信を与えてくれました。

LLM-Audit™へのリアルな期待

シャドーAI、うっかり情報漏洩——これらは、もはや"将来の懸念"ではなく、今、目の前で起きている課題です。来場者の方々から聞こえてきた"しみじみとした声"は、日本企業のAI活用がまさに次のフェーズ——ガバナンスとスピードの両立へと進んでいることを示していました。

LLM-Audit™は、その"最後の砦"として機能するプロダクト。今回のデモを通じて、「ああ、まさにコレが欲しかった」 と言っていただけたことが、何よりの励みになりました。

そして、チームで走り抜いた手応え

今回のStartup JAPAN EXPOは、マーケティングチームとエンジニアチームの総力戦でした。

会場で笑顔で対応する裏側には、前夜と前々夜の仕込み、夜中の改善、朝方の最終確認、無数の準備がありました。

それでも、「最後に来て最後まで残る」 のジンクスは、今回ちゃんと破りました!✨

次回はきっと、「最初に来て最初に帰る」 の常識ジャンルにも到達してみせます(できるのか?)。

関係者の皆様、そしてお越しくださった皆様へ

主催のEight(Sansan株式会社)様、会場運営スタッフの皆様、同日開催Climbers運営の皆様、そしてブース番号 16-16 にお立ち寄りいただいたすべての来場者の皆様——

本当に、本当にありがとうございました🙇‍♂️🙇‍♀️

そして、アクセア 海浜幕張店のスタッフの皆様——

開店前の突然の入稿、無理筋のスケジュール、それでも朝イチで刷り上げて、朝イチでお電話をくださったあのプロフェッショナルな対応に、心から感謝申し上げます。お陰様で、2日目の開場に間に合いました。

ちなみに１日目のポスターもアクセア大手町店さまが、急ぎ対応したいただいたりと、アクセアさんなくして、今回の展示は完成しませんでした🙏

「Bestllamのエージェント、うちの部署で試してみたい」 「LLM-Auditの話、情シスに共有したい」 「Qualitegのコンサル、まず1回相談させて」

——こんなお声をたくさん頂戴しました。いただいたご縁を、一つひとつ、ちゃんと次につなげていきます。

そして、遠方からブースを目指して駆けつけてくださった皆様、SNSで応援してくださった皆様、このレポートを最後まで読んでくださったあなたへ。

Qualitegは、これからも「世界中の人々のクリエイティビティを深化させる」という理念のもと、日本のビジネス現場に本当に溶け込むAIを作り続けてまいります。

次回のイベントでも、皆様と直接お会いできることを、チーム一同楽しみにしております!

最後までお読みいただき、誠にありがとうございました✨

また、お会いしましょう〜😊

2026年4月13日 プレスリリース

株式会社Qualiteg、「Startup JAPAN EXPO 2026」に出展

株式会社Qualitegのプレスリリース（2026年4月13日 10時00分）株式会社Qualiteg、「Startup JAPAN EXPO 2026」に出展

PR TIMES株式会社Qualiteg

「Bestllam®」に、AIエージェント機能を搭載

― 依頼は並列に、思考は止めず。日本企業の業務システムに溶け込む"働くAI"へ ― 生成AI導入・AIエージェント・業務自動化・コンサルティング

株式会社Qualiteg（本社：東京都千代田区、代表取締役：三澤智則）は、2026年4月15日(水)から16日(木)まで幕張メッセで開催される「Startup JAPAN EXPO 2026」（ブース番号：16-16）に出展いたします。

この度、主力プロダクト「Bestllam®」にAIエージェント機能を新搭載しました。依頼した瞬間に専任チームが動き出し、複数業務を並列自動処理する新UXを、本展示会にてデモ体験いただけます。

あわせて、AIを活用したいがガバナンスへの不安から全社導入に踏み切れていない企業、またはツールを導入したものの業務効率化につながっていない企業向けに、AI業務改善コンサルティングの受付も行います。

■「Startup JAPAN EXPO 2026」開催概要

■ 主な展示内容

展示① 統合AIプラットフォーム「Bestllam®」実演デモ

特長①【新機能】AIエージェント｜指示した瞬間、自分だけの専任チームが動き出す。思考を止めずに、仕事が終わっている。

生成AIの業務活用は急速に広がる一方、AIチャットの体験は依然として「人間がAIの返答を待ってから次を考える」往復構造に縛られています。AIを使うほどに思考が寸断されるという、逆説的な課題です。

もし、思いついた瞬間にどんどん指示を投げるだけで、気づいたときには仕事が終わっていたら——Bestllamはその体験を実現します。指示した瞬間、自分だけの専任チームが出来上がります。各サブエージェントが並列で仕事を進め、統括エージェントが成果をまとめてあなたに届けます。

まるで、優秀なチームを持つ経営者になったような感覚で、仕事が進んでいきます。AIの返答完了を待たず、返答中であっても次の指示を重ねられる構造により、思考を中断させない業務進行が可能になります。

Bestllam AIエージェントが提供する3つの価値

1. 託せる｜頼んでおけば、仕事は終わっている ユーザーは依頼を投げるだけで、サブエージェント群が裏で非同期に業務を進行。リサーチ、資料作成、データ整理、メール下書き、社内ナレッジ検索など、複数タスクが並行で完了します。

2. 止めない｜返答を待たずに、次の依頼を投げていい 統括エージェントがリクエストを一手に引き受け、背後の複数サブエージェントが並列に処理します。ユーザーは思いついた順に指示を重ねることができ、思考の流れを断ち切られません。Bestllamがこれまで培ってきた「複数LLMの同時稼働」の並列処理アーキテクチャを、エージェント実行基盤へと拡張したものです。

3. 守れる｜LLM-Audit™による情報漏洩の検出・マスキング 自律的に動くAIに機密情報や個人情報が紛れ込むリスクを、Qualiteg独自の「LLM-Audit™」が入出力双方で検出・マスキング。さらに官公庁・自治体向けには、データを国外に出さない「クロスボーダー保護」オプションを提供します。

• 単一窓口への依頼で複雑な調査・業務を自動完結。LLM-Audit™連携で全操作ログ・監査対応
• 途中変更OK。追加指示・方向転換にもリアルタイムで対応し、全体を整合させながら進行
• 日本企業固有のシステム制約（勤怠・基幹系など）に対応した独自MCPコネクタ開発済み

👉 詳細を見る

特長② Bestllamの基盤｜20種類以上のAIが使えるから、シャドーAIが消え、エージェントが強くなる。

いま、「シャドーAI」が企業のリスクとして注目を集めています。使いたいAIが社内で使えない。申請が通る頃には新モデルが出ている。部署ごとに最適なAIは違うのに、契約できるのは1種類だけ——こうした状況の中で、社員が個人でAIを契約して業務に使い始めてしまうケースが、各企業で報告されています。

Bestllam®なら、GPT・Claude・Gemini・Grok・Qwen・DeepSeekなど20種類以上のLLMを契約一本で使い分けられます。最新のモデルや部署ごとに異なるニーズに社内で応えられる体制を整えることで、シャドーAIの発生リスクを抑える一助となります。

そしてこの複数LLMが並列稼働できる基盤は、エージェント機能の原動力であると同時に、従来のAIチャットとしての価値もさらに引き出します。複数のLLMに同じ質問を同時に投げて回答を比較する——モデルごとの得手不得手を踏まえた意思決定や、回答の整合性チェックによる信頼性向上が、日々の業務の中で自然に行えます。エージェントには最適なモデルを自動選択させ、最大6モデルの同時稼働で精度を高める。チャットでは複数モデルの回答を横並びで検討する。同じ基盤が、両方のユースケースを支えます。

さらにエージェントが自律的に動く中での情報漏洩リスクには、当社のセキュリティプロダクト「LLM-Audit™」がガーディアンエージェントとして対応します※。LLMへ情報が送られる前段で機密情報・個人情報を検出し、ブロック・マスキング・仮名化を行うことで、外部LLMへの情報漏洩を防ぎます。その検出エンジンとして動作するのが、自社開発の基盤技術「PII-Fi™」です。一般的な個人情報だけでなく、企業ごとの「自社にとっての機密情報」を事前に学習させることで、その企業の文脈に沿った高精度な検出が可能になります。

• 20種類以上のLLMを契約一本で。エージェントにもチャットにも使い分け可能、シャドーAIリスクの抑制にも寄与
• 複数LLM同時質問：同じ質問を複数モデルへ並列に投げ、回答を比較検討できる
• LLM-Audit™：機密情報・個人情報の検出、ブロック、マスキング、仮名化により外部LLMへの漏洩を防止※
• PII-Fi™（基盤技術）：一般PIIに加え、企業独自の機密情報を事前学習可能。高速・高精度な検出エンジン

※LLM-Audit™はオプション機能です。

👉 詳細を見る

特長③ AIコンテンツ生成｜画像・文書・動画まで、テキスト一つで作れる。

資料の挿絵を探す、報告書のフォーマットを整える、プレゼン資料をつくる ——こうした制作業務に、これまでどれだけの時間を費やしてきたでしょうか。Bestllamはテキスト一つから、多様なコンテンツをその場で生成します。

まずAI画像生成はBestllam®の基本機能として標準搭載。「コーポレートカラーで製品の挿絵を作って」と指示するだけで、ブランドに合った画像を即時生成します。Word・Excel・PowerPointの文書・資料もAIが自動生成し、定型業務や報告書作成を大幅に効率化します。

• AI画像生成：商品画像・資料挿絵・SNS素材をテキスト一つで即時制作
• Word・Excel・PowerPoint文書をAIが自動生成。定型業務・報告書作成を大幅に効率化
• AIアバター動画生成：オプションにより、AIアバター動画生成サービス「MotionVox®」と連携可能。顔出し・声出し不要で動画コンテンツを制作。27言語対応

Bestllamの立ち位置 ― 日本の法人現場に届くAIエージェント

エージェント型UXは、すでにグローバルで主流となりつつある潮流です。そのうえでBestllamが目指すのは、日本企業の業務現場に本当に溶け込むかたち——基幹システムや社内ナレッジベースとの接続（MCP他）はもちろん、人間の同僚と共同作業をしているかのような自然なやり取り、迷わず使える操作感、任せて安心できる挙動。相手の意図を先回りして汲み取る、日本ならではの"おもてなし"の感覚を、プロダクトの隅々にまで織り込んでいます。

そして、そのおもてなしはプロダクトの中だけに留まりません。当社のコンサルティングチームが、PoCから運用設計、現場トレーニング、業務プロセス再設計までを一貫して伴走。プロダクトと人の両輪で、AIが現場で本当にワークするまでの「最後の一歩」を、責任を持ってご一緒します。

展示② AI業務改善コンサルティング（招待制から一般受付へ）

次のようなお悩みをお持ちの企業さまに向けて、実務に根ざした伴走型コンサルティングを提供します。

• 「生成AIを導入したが、チャットするだけで業務効率化につながっていない」
• 「PoCで終わってしまい、全社展開に踏み切れていない」
• 「ガバナンスや情報漏洩リスクへの不安から、全社導入を決断できていない」

PoCから運用設計、現場トレーニング、業務プロセス再設計まで一気通貫で支援。最先端に精通したAIエンジニアと大企業の業務改革で長年にわたって支援経験のある経験豊富な戦略コンサルタントが一体となったチームが、AIを"入れただけ"で終わらせない現場主義の伴走を提供します。

👉 詳細を見る

■ ブース来場特典

🎁 ブース来場・4月中お申し込み限定特典

• AI業務改善コンサルティング 初回契約総額から 20%オフ
• Bestllam® 初期費用 20%オフ

※ブース16-16にてお申し込み受付。4月30日(木)までのご契約が対象。

■ 株式会社Qualitegについて

株式会社Qualitegは、2023年7月に設立されたAIカンパニーです。「世界中の人々のクリエイティビティを深化させる」という経営理念のもと、最先端のAI技術を通じて、技術的障壁や言語の壁、身体的制約を取り払い、すべての人が持つ創造的な潜在能力を解放することを目指しています。

当社は、人々の創造力を増幅し、これまで想像もできなかった新たな表現と価値を生み出す世界の実現に取り組んでいます。AGIからASI、そしてデジタルヒューマンへと至る技術革新は、AIと人間の自然な協働を可能にし、誰もが直感的にAIを活用して自らの創造性を飛躍的に深化させる未来を約束します。技術格差による分断のない、すべての人がその創造性を解放できる社会を創造します。

自社サービス

• ビジネスを加速させる、統合AIプラットフォーム Bestllam®
• テキスト・音声等からリアルなAIアバター動画を生成 MotionVox®
• LLMの入出力を監査し、情報漏洩リスクを防御 LLM-Audit™
• 個人情報・機密情報を高速・高精度に検出・マスキング PII-Fi™ API
• オープンソースLLMでチャットボット・推論環境構築 ChatStream®
• AI・DX・戦略・新規事業・オープンイノベーション コンサルティング

■ 本件に関するお問い合わせ

株式会社Qualiteg Email：startupjapan2026@qualiteg.com

👉 お問い合わせ・デモのご依頼

Project Glasswingが映し出す、防御側のパラダイム転換

すごいモデルが出た、らしい

2026年4月7日、AnthropicがClaude Mythos Previewという新しいAIモデルを発表しました。(Anthropic公式発表 / Anthropic技術解説)

Anthropicは、ChatGPTで知られるOpenAIと並ぶ米国の大手AI企業のひとつで、Claudeシリーズと呼ばれる生成AIモデルを開発しています。

普段なら、新モデル発表は「より速く、より賢くなりました」というアップデートの話で、誰でも触れるようになるのが通例です。

ところが今回はだいぶ様子が違いました。

一般公開はされません。

アクセスできるのは選ばれた一部のパートナーだけ。

同時に立ち上げられた業界横断プロジェクト「Project Glasswing」の枠組みの中で、防御目的に絞って提供される、という発表でした。

ただ、この話を「危険なAIが出た」の一言で受け止めると、もっと重要なところを取り逃してしまいます。

少し腰を据えて見ていきましょう！

どのくらい「とんでもない」のか

まず性能面の数字から見ていきます。AIモデルの能力は、業界共通のベンチマーク(試験のようなもの)で比較されるのが通例で、今回もいくつかの代表的な指標が発表されています。

• SWE-bench Verified で93.9%(Anthropicの現行最強モデルClaude Opus 4.6は80.8%)。
  これはGitHub上の実際のソフトウェアバグをAIに修正させる試験で、いま業界がもっとも注目している実務系の指標です。
  
• Terminal-Bench 2.0 で82.0%(同65.4%)。
  AIがターミナル(コマンドライン)上で複数ステップの作業を自律的にこなせるかを測る試験です。
  
• GPQA Diamond で94.6%(同91.3%)。物理・化学・生物の博士課程レベルの問題を解かせる試験で、関連分野のPhD取得者でも65〜70%程度しか取れないと言われています。

数字の細部はさておき、ポイントは

「コーディング、自律作業、科学的推論のいずれでも、現行の最強モデルを明確に上回っている」

という事実です。

そのうえで、目を引くのはサイバーセキュリティ領域での跳ね方です。

Anthropic自身が比較例を出しているのですが、Firefoxの脆弱性をエクスプロイト化(攻撃に使える形に仕上げること)する作業について、Opus 4.6は数百回試行して成功したのが2回だけ。

一方Mythos Previewは、同じ脆弱性群から181個のエクスプロイトを生成し、さらに29ケースでレジスタ制御(より深い乗っ取りに繋がる段階)に到達した、と報告されています。脆弱性再現を測るCyberGymという業界ベンチマークでも83.1%。

ここで起きていることを補足すると、これまでAIモデルは「脆弱性を見つける」ことはある程度できても、「それを実際に動く攻撃コードに仕上げる」ところは苦手でした。

後者は人間の専門家の経験と勘に依存する部分が大きく、最後のひと押しが効かなかった。Mythos Previewは、その最後のひと押しまでかなりの確率でこなせる、ということです。「専門家にしかできなかったこと」が、モデルの内側にかなりの程度入り込んでいる、と言い換えてもいい。

さらにびっくりなエピソードもあります。

正式なセキュリティ訓練を受けていない社内エンジニアが、リモートコード実行(攻撃者が遠隔から相手のマシンを乗っ取れる類の脆弱性)の探索を「一晩」モデルに依頼し、翌朝には動作するエクスプロイトを受け取っていた——というものです。

これまで世界トップクラスのセキュリティ研究者が数週間から数カ月かけて取り組むような作業が、専門外の人間でもひと晩でこなせる範囲に入り始めている、ということになります。

Anthropicは、こうした能力を意図して訓練したわけではなく、コードと推論と自律性の改善から副次的に立ち現れたものだと書いています。

サイバー専用の特殊モデルではなく、汎用的に賢いモデルを作ったら、結果としてサイバー攻撃も得意になっていた、という説明です。

これまでのLLMの発展進化からすると、それほど驚くことではありませんが、人間が狙わなくてもどんどん全方位で賢くなっていくというのはおそるべきことでもあります。

だから一般公開しない、という判断

Anthropicの結論は明快でした。

これは一般公開しない。

Project Glasswingの技術解説では、主要なOSやWebブラウザを含む広範なソフトウェアから「数千件規模」の高・重大レベルの脆弱性、いわゆるゼロデイが見つかっており、その大半はまだ修正されていない、と説明されています。

ゼロデイというのは、開発元すら存在を知らない未知の脆弱性のことです。

対策が打たれるまでの「ゼロ日」しか時間がない、という意味からその名前がついています。攻撃者にとっては防御側がまだ気づいていない穴なので、もっとも価値が高い。公開されているゼロデイ買い取りプログラムを見ても、ブラウザやOSの高価値な脆弱性やエクスプロイトチェーンには数百万ドル規模の価格がつくことがあるとされています。それが「数千件」と聞けば、規模感としてはかなり異常です。

Anthropicの説明では、開発元によって実際に修正(パッチ適用)が完了したものは、報告されたバグの1%にも満たない、ともされています。だから責任ある開示(発見者がまず開発元に通知し、修正パッチが用意されてから公表するという業界慣行)の観点から、詳細は伏せざるを得ない、というロジックです。

「強いから出せない」という判断は、AIラボとしてはかなり踏み込んだ意思表示です。普通、性能の高い新モデルは商業的にも大きな価値を持つので、可能な限り早くAPIや製品を通じて広く使ってもらいたい、というのが業界の自然な力学です。それに逆らう形でアクセスを絞るのは、相応のロジックがなければ説明がつきません。Anthropicは「Mythosクラスのモデルを将来安全に大規模展開すること」を最終目標に据えつつ、そのための安全策を別系統(次のClaude Opus)で先に作り込む、と明言しています。

防御側に先に渡す、という設計

封印するだけでは終わりません。Anthropicは同じモデルを、防御側の有力プレイヤーに先行配備しています。

中心パートナーはAWS、Apple、Broadcom、Cisco、CrowdStrike、Google、JPMorgan Chase、Linux Foundation、Microsoft、Nvidia、Palo Alto Networksの11社にAnthropic自身を加えた12社。さらにクリティカルインフラを支える40以上の組織にもアクセスが提供されます。Anthropicは1億ドル分の利用クレジットと、オープンソースのセキュリティ団体への400万ドルの寄付も同時にコミットしました。

参加企業の顔ぶれを見れば、これは単なる研究発表ではないことがわかります。クラウド事業者(AWS、Google、Microsoft)、エンドポイントセキュリティ大手(CrowdStrike、Palo Alto Networks)、デバイスメーカー(Apple)、半導体(Nvidia、Broadcom)、ネットワーク機器(Cisco)、Linuxを支える非営利財団、そして金融大手(JPMorgan Chase)。ほとんどの人がインターネットを使うときに通る経路のどこかに必ず関わっている企業ばかりです。

Project Glasswingは、研究発表というより、現場投入を見据えた業界横断の運用枠組みです。発見、トリアージ(優先順位づけ)、開示、修正という一連のフローを、Mythosを軸にした共通基盤の上で回そうとしている、と読むのが素直だと思います。

起きそうなパラダイムシフト

ここまでの話で本当に重いのは、ゼロデイの数の多さそのものではないと感じます。

むしろ重要なのは、脆弱性の発見、切り分け、悪用可能性の検証という工程が、これまでよりはるかに短い時間で回り始めるかもしれない、という点です。

少し背景を補足します。これまでのサイバーセキュリティ運用は、ある種の「人手と時間の制約」の上に成り立ってきました。脆弱性を見つけるには熟練したセキュリティ研究者の労力が必要で、ひとつの重大な脆弱性を見つけるのに数週間から数カ月かかることも珍しくない。

攻撃者側も同じ制約の中にいるので、防御側には準備の時間がそれなりに残されていました。

「攻撃者がこの脆弱性に気づくまで、まだしばらくは大丈夫だろう」

という暗黙の前提が、運用設計の隅々に染み込んでいたわけです。

その前提が崩れる可能性が出てきています。AIが脆弱性発見からエクスプロイト作成までを自動化できるなら、攻撃側も防御側も、同じ時間軸で動くことができなくなる。

これまで「見つかった後どう直すか」が中心
だった議論は、

これからは「大量に見つかる世界をどう運用するか」
へ移っていくでしょう。

具体的には、こんな問いが現実味を帯びてきます。

• 自社でいま動いているソフトウェアの全リスト(資産インベントリ)は、本当に最新の状態に保たれているか。
• 新たな脆弱性情報が入ってきたとき、どれを最優先で対応するかの判断基準は明確か。
• 委託先のSIerやSaaSベンダーに脆弱性が見つかったとき、自社にどう連絡が来て、誰が一次判断を下すのか。
• 大量のアラートが押し寄せたとき、現場が燃え尽きずに回り続ける運用設計になっているか。

これらは、一見すると地味で、新技術の話とは関係なさそうに見えます。しかしAIで発見能力だけが劇的に上がっても、それを受け止める組織側の設計が伴わなければ、現場はアラートと修正タスクに押し流されて終わります。「強いツールを持っているのに、それを使い切る運用が組めていない」状態は、これまでも何度も見てきた光景です。

公益性と事業戦略の両面を持つ取り組みでもある

ここで一段引いて、Project Glasswingの位置づけも整理しておきます。

この取り組みは、クリティカルインフラの防御という公益性の高い目的を掲げる一方で、Anthropicの中長期的な事業展開とも整合する設計になっています。

Anthropic自身、最終的には「Mythosクラスのモデルを安全に大規模展開すること」を目標として掲げており、今回のGlasswingはそのための知見を蓄える段階として位置づけられています。

同ページでは、約90日後に学びを公開報告する予定であることや、将来的にはClaude API、Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry経由でパートナー向けに提供範囲を広げていく方針も示されています。

防御用途という限定された文脈で先行配備することで、実運用に近い条件でデータと運用ノウハウが集まります。脆弱性発見からトリアージ、開示、修正支援に至る一連のフローの中で、Mythosが共通基盤として使われる土壌ができていく、という構造です。これは、AI業界全体で繰り返し見られてきたパターンでもあります。新しい基盤技術を提供する側は、最初に「どこで使うか」を設計した者が、そのまま事実上の標準として残りやすい。

これは批判的に見るべき話ではなく、公益性と事業性が両立しうる典型的な事例として読めるものだと思います。

報道では「強すぎて出せないモデル」という側面が強調されがちですが、実際の発表内容は、安全策の段階的な構築、パートナーとの責任分担、公開報告のスケジュールまでを含んだ枠組みの提示でした。

「封印」よりも「設計された先行配備」と捉えたほうが、全体像に近いと言えそうです。

それでも、まだ検証の途上にある

もうひとつ、冷静に置いておきたいことがあります。

印象的な成果の多くは、現時点ではAnthropic自身の説明に依拠しています。

修正済みが1%未満ということは、外部から独立検証しにくい状態が当面続く、ということでもあります。Anthropicは、198件のサンプルに対する手動レビューで89%のケースで重大度判定が完全に一致し、98%が1段階以内に収まっていたといった整合性データを示してはいますが、広範な第三者検証が完了したわけではありません。

「数千件の高・重大脆弱性」という数字は強烈ですが、読み方には少し慎重さがいります。妥当なのはおそらく、「かなり強いシグナルが出ているが、まだ全面的に検証済みとは言えない」あたりの理解です。

Anthropicは90日後に学びを公開報告すると約束しているので、そこまで含めて見届ける必要があるでしょう。

一次情報の内容は重く、同時に検証余地も残る——その中間に踏みとどまるのが、いまのところ妥当な距離感です。

おわりに：問いの重心はどこに移るのか

最初のニュースに戻ります。今回の出来事は、表面的にはサイバーセキュリティの話に見えます。

しかし、そこで露わになったのは、特定領域の問題というより、AIの能力水準そのものが新しい段階に入りつつある可能性だと思います。

Mythos Previewが目立ったのは、脆弱性探索という測りやすい領域だったからであって、そこで見えている変化は、研究開発、事業設計、経営判断といった他の知的業務にも波及しうるものだと捉えています。

言い換えると、今回の出来事が示しているのは、

これまでの延長線上では捉えにくいレベルの能力を持つAIが、すでに現実のものになりつつある

ということではないでしょうか。

そしてこの種の能力が特定の一社に長く閉じたままでいると考える理由は乏しく、今後は他社や他領域にも波及していく可能性を前提に置いて考えるべき局面だと思います。

そうなると、問いの立て方が変わってきます。

「このモデルをどう使うか」ではなく、

「高度な専門能力を一部領域で代替・補完しうるAIが現実味を帯びるなかで、自社は何を価値として提供する会社なのか」
のほうへ、重心が移っていきます。

業務プロセスを効率化する、という発想だけでは届かない射程の話です。

考えてみれば、これまで「AIに置き換わらない仕事」としてイメージされてきた領域（たとえば複雑な設計判断、高度な専門知識、長い文脈を踏まえた意思決定、創造的な問題解決など）は、まさにMythos Previewが頭角を現した領域と重なっています。
PhDホルダーの試験で94%を取り、熟練エンジニアが数週間かけていた作業を一晩でこなす。この事実を前にしたとき、

企業に問われるのは、
「AIにできないことを探す」という守りの思考ではなく、
「この賢さを前提にしたときに、自社の事業とチームは何を価値として残せるのか」という、もう一段上の問いだと思います。

それは技術論でも導入事例の話でもなく、事業そのものの設計論の話です。

もちろん、いまはまだ「Mythos Previewという一つのモデルの話」に見えるかもしれません。
そして、誇張として片づけるには一次情報が重く、既成事実として断定するにはまだ検証余地もある。
でも、そう見えているうちに自社の立ち位置を考え始められるかどうかが、次の局面でじわじわ効いてくる気がします。

本稿の論点について、自社の状況に引き寄せて考えてみたい、あるいは誰かと伴走しながら整理していきたい、といったご要望がございましたら、お問い合わせよりお気軽にお声がけくださいませ！
微力ながら、Qualitegもご一緒に考えさせていただければ幸いです。

── SaaS再編の時代に、どこにポジションを取るか

こんにちは！ Qualitegコンサルティングです！

ここ数年、「日本のAI戦略」というテーマでの相談やディスカッションが増えてきました。

生成AIの登場以降、経営層から現場のエンジニアまで、それぞれの立場で「自社はどこに張ればいいのか」「国としてはどう進むべきか」を模索している、というのが実感です。

本シリーズでは、その問いに対して少し腰を据えて向き合ってみたいと思い、前後編の構成で書いてみました。

前編では、国産LLM、データセンター投資、データ主権の3テーマを通じて、日本のAI投資が必ずしも「使われて勝つ構造」に向かっていない可能性を見てきました。投資の総額やプレイヤーの動きを並べてみると、号令の方向と実際の資金の流れにはちょっとしたズレがあるのではないか、という現在地が見えてきます。

後編では、その前提の上で視点をソフトウェア産業全体に広げます。もしAIによってアプリケーション層そのものの競争ルールが変わるなら、日本が張るべき場所もまた変わるはずです。海外で起きているSaaS産業の地殻変動を眺めたうえで、日本がどこにポジションを取るべきかを一緒に考えていきましょう。

第5章：ソフトウェア産業で何が起きているか

ソフトウェア株の急落──何が織り込まれたのか

2026年1月末以降、北米のソフトウェア／データ関連株には大規模な売りが波及しました。Reutersの報道によれば、S&P 500のソフトウェア・サービス指数は急落し、セクター全体の時価総額が約1兆ドル（約150兆円）近く減少したとされています。北米ソフトウェア銘柄を追跡するIGV ETFは年初来で2割前後の下落を記録し、セクターのバリュエーションは2010年代半ば以来の水準にまで圧縮されました。

背景として報じられたのは、生成AIがアプリケーション層の収益構造を侵食しうるという見方の再燃です。マクロ経済の急変や個別のスキャンダルではなく、ソフトウェア産業そのものの構造的な変化への警戒が売りを加速させた格好です。

ここで注意しておきたいのは、3つの切り分けです。

1つ目に、市場はそう織り込み始めた。SaaSの収益マルチプルは一部の大手を除くと厳しい水準に追い込まれ、勝ち組が平均を押し上げる二極化が進行中です。VC投資も2021年のピークからほぼ半減したのち横ばいが続く一方、案件数は大幅に減少しており、「少数の有望企業に大型の資金が集中し、それ以外は干上がる」構図が鮮明です。

2つ目に、実態がそこまで急速に進むかは未確定です。短期の株価は物語（ナラティブ）に振れやすい性質を持ちます。バリュエーションの調整が構造的なものなのか一時的なものなのかは、今後の推移を見る必要があります。

3つ目に、重要なのは未来の確定ではなく、競争条件の変化が広く意識され始めたことです。後述するように、課金モデル、UI、垂直統合といった複数の次元で、SaaSの前提が揺さぶられています。

「SaaS is Dead」の中身

2024年末、大手テック企業のCEOの発言が「SaaSは死んだ」と要約され拡散しました。IDCはこのテーマを整理した分析を公開しています。もちろん翌日からSaaS企業が消えるわけではありません。ただ、この言葉が象徴する変化は根深いものがあります。

ビジネスモデルへの転換圧力。 IDCの予測（FutureScape）では、2028年までにソフトウェアベンダーの70%がシートベース（ユーザー数課金）からコンサンプションベースやアウトカムベース（成果課金）への移行圧力にさらされるとされています（CIO.comの解説記事も参照）。

なぜか。シートベース課金は「何人がそのソフトを使っているか」で値段が決まります。ところがAIエージェントが人間の代わりにタスクを処理するようになると、「何人が使うか」という問い自体の説明力が相対的に落ちていきます。だから課金の基準は「どれだけ処理したか」（コンサンプション）や「どれだけの成果を出したか」（アウトカム）に移っていく可能性がある。

これはSaaS企業にとって、単なる価格改定ではなく、収益構造の根本的な組み替えを迫られることを意味します。シートベース課金の魅力は予測可能性にありました。ユーザー数×月額単価で来月の売上がかなり正確に見える。しかし成果課金になると売上の変動幅が大きくなり、SaaSの最大の魅力だった「予測可能な定期収入」が揺らぎます。投資家がSaaS銘柄に高いマルチプルをつけてきた根拠の一つがこの予測可能性だったわけで、それが失われるとなれば、バリュエーションが構造的に下がるのも理解できます。

インターフェースという「堀」の希薄化。 業界では「何百万人もの人がSaaSのUIを覚えたこと自体が最大の堀であり、インターフェースが自然言語になった瞬間にその堀は消える」という見方が広がっています。

考えてみてください。Salesforceの競争優位性の相当部分は、「何百万人もの営業担当者がSalesforceの使い方を知っている」という事実に由来しています。別のCRMに乗り換えようとすると、全員が新しいUIを覚え直す必要がある。この「学習コスト」が、実質的なスイッチングコストとして機能してきたわけです。

しかし、インターフェースが自然言語での指示へ寄っていくと、UI由来のユーザー体験の差分は相対的に縮まりやすくなります。UIの学習コストが下がれば、スイッチングコストも下がる。何年もかけて築いた参入障壁が無効化されるかもしれない。これが現実になるかどうかはまだわかりませんが、市場がかなり本気でその可能性を織り込み始めたのが2026年初頭の動きだと見ることができます。

基盤モデル企業がアプリ層まで降りてきた

もう一つ見逃せない動きがあります。

2024年から2025年前半は「AIは既存SaaSを強化する」が主流のナラティブでした。どのソフトウェア企業も決算説明会で「AI組み込みで生産性アップ」と語り、投資家もそれを好感していた。ところが2025年後半から2026年にかけて、このナラティブが静かにひっくり返ります。

転換の背景にはいくつかの要因が指摘されています。AIエージェント系のスタートアップが実用的な製品を出し始めたこと。DeepSeekに代表されるオープンソースモデルが、低コストでも競争力のある性能を達成しうることを示したこと（Reuters: A year on from DeepSeek shock）。そして決定的だったのは、基盤モデル企業自身がアプリケーション層に進出し始めたことです。

OpenAIはGPTsやCanvasを提供。AnthropicはArtifacts、Computer Use、MCP、Claude Codeと、次々にアプリケーション層の製品を展開しています。さらに非エンジニア向けのデスクトップエージェント──ブラウザ操作、Excel操作、ファイル管理を自律的に行うツール──も登場しています。

なぜこうなるかというと、基盤モデルだけの商売は差別化が難しいからです。モデルの性能差は時間とともに縮まり、価格競争に陥りやすい。だからモデルの上に付加価値の高いアプリケーション層を構築して、ユーザーのワークフローに深く入り込むことでスイッチングコストを作りたい。

これは「垂直統合の誘惑」とでも呼ぶべき現象で、テック業界では過去に何度も繰り返されてきたパターンです。チップメーカーがOSを作り、OSメーカーがアプリを作り、アプリメーカーがクラウドを作る。AI業界でも同じことが起きているだけ、とも言えます。

「基盤モデルは海外製でいい、その上にアプリを作るのが自分たちの仕事だ」と考えていたプレイヤーにとっては、悩ましい状況です。上のレイヤーで付加価値を出すつもりだったのに、下から浸食されてくる。

では、この環境下で守りやすいポジションはどこにあるのか。

第6章：構造的に守りやすい場所はどこか

AIベンダー自身が担うと利益相反が生じやすい領域を探す

基盤モデル企業がどれだけ進化しても、ベンダー自身が担うと利益相反が生じやすい領域というのはあります。なぜなら、ある種のサービスは「特定のAIベンダーに属さない」ことが本質的な価値だからです。

その視点で市場を眺めてみると、独立系プレイヤーに機会がある可能性のある候補がいくつか浮かんできます。

マルチベンダー統合。 OpenAIはAnthropicのモデルを推薦しませんし、GoogleはOpenAIとの併用を手助けしてくれません。しかし企業にとっては、タスクごとに最適なモデルを選べるほうが合理的なケースが多い。しかもLLMの世界では、用途別に優位なモデルが比較的頻繁に変動します。コーディング、長文コンテキスト処理、推論、多言語対応──それぞれの評価軸で最適なモデルは異なりますし、数カ月で勢力図が塗り替わることも珍しくありません。

たとえば、法務文書のレビューにはモデルA、社内ナレッジ検索にはモデルB、コード生成にはモデルCを使っている企業があったとして、アプリケーション側を変えずにモデルだけを切り替えられる基盤があれば、ベンダーロックインのリスクを下げられます。各AI大手にとって利益相反があるぶん、こうしたベンダーニュートラルな統合レイヤーには独立系プレイヤーに構造的な余地があります。

データ統制・ガバナンス。 前編で触れたデータ主権の話と直結します。LLMの入出力データの監視を、そのLLMを提供している企業に委ねるのは、審判と選手を兼ねてもらうようなものです。

特に規制が厳しい金融、医療、官公庁向けでは、「どのLLMを使っていても、入出力データが適切に管理されていることを独立して検証できる」仕組みへのニーズは根強いでしょう。具体的には、機微情報をマスクしてからLLMに送る仕組みや、モデル非依存で監査ログを残す仕組みです。これは「国産モデルを使うことでデータを守る」というアプローチとは根本的に発想が違います。モデルの国籍ではなく、データの流れそのものを制御する。「モデルの外側に置くセキュリティレイヤー」です。

業務コンテキストへの接続。 汎用AIエージェントがどれだけ賢くなっても、個々の企業の稟議フロー、社内規定、業界固有の規制は知りません。「1,000万円以上の支出は部長承認、5,000万円以上は役員承認」「薬機法の広告規制に抵触しないか確認が必要」──こうした業務コンテキストは、企業ごと、業界ごとに千差万別です。

たとえばAIエージェントに「契約書をレビューして」と頼んだとき、法的なチェックはかなり正確にやってくれます。しかし「この条項はうちの過去の取引慣行に照らしてどうか」「この相手先との力関係を考えるとどこまで押せるか」といった判断は、その企業の文脈を深く知らないとできません。稟議ルール、承認権限、過去の社内判断──こうした制約条件をエージェントに与える設計こそが、業務を深く理解したプレイヤーでないと埋められない「ラストワンマイル」です。

この3つに共通するのは、いずれもAIベンダー側ではなく、AIを利用する企業の側に立つことで初めて提供できるという点です。AI大手が進化すればするほど、「AI大手の代替」ではなく「AI大手と企業の間に立つ」ポジションの価値は、むしろ上がるかもしれません。

もちろん、これが確実に正しいとは誰にも言えません。AIベンダーが自前でこうした領域もカバーしてしまう可能性もありますし、企業側がこうした中間レイヤーを必要としない運用形態に落ち着く可能性もある。ただ、少なくとも現時点の構造を見る限り、検討に値する方向性ではあると思います。

SaaSモデルの再編圧力──そのあとに何が来るか

「SaaS is Dead」の議論をもう少し先まで考えてみましょう。

仮に現在のSaaSモデルが大幅に縮小するとして、その後に来るのは何か。いくつかのシナリオが考えられます。

一つは「AIエージェントが直接タスクを実行するモデル」。ユーザーがソフトウェアを操作するのではなく、AIエージェントに目的を伝え、エージェントがさまざまなツールやデータソースを組み合わせて結果を返す。この場合、従来のSaaSの「画面」は不要になり、代わりにAPIやデータパイプラインの重要性が上がります。

もう一つは「プラットフォーム型への集約」。数社のAI大手が提供するプラットフォーム上に、あらゆるビジネスツールがプラグインとして載る世界です。

いずれのシナリオでも、重要なのは「データとワークフローの独自性」です。AIがどれだけ賢くなっても、企業固有のデータと業務プロセスは外部からは見えない。このデータとプロセスへのアクセスを持つプレイヤーは、AIの進化の恩恵を受ける側に回れます。逆に、汎用的な機能を提供しているだけで独自のデータもワークフローも持たないSaaS企業は、AIエージェントに置き換えられるリスクが高い。

第7章：日本の勝ち筋はどこにあるか

「作れない」は本当に弱みか

前編で見た通り、基盤モデルの開発競争で日本が米中に勝つのは、資本の桁が違う以上、現実的には難しい。では「作れない」ことは致命的な弱みなのかというと、そうでもないかもしれません。

よく引き合いに出される話ですが、トヨタ生産方式が世界の自動車産業を変えたのは、エンジン性能で圧倒したからではなく、同じエンジンの「使い方の設計」──生産プロセス、品質管理、サプライチェーン──で差別化したからでした。「ジャスト・イン・タイム」や「カイゼン」といった生産システムの設計で、同じ部品から圧倒的に高い品質と効率を引き出した。自動車とAIではいろいろ条件が違いますから、安易なアナロジーには注意が必要です。ただ「道具を作る競争」と「道具で何を解くかの競争」は別物だ、という構図自体は参考になります。半導体の歴史でも、日本はチップの「製造」では韓国・台湾勢に追い抜かれましたが、製造装置や素材ではいまだに高いシェアを維持しています。

AIでも似たポジショニングがありえるとすれば、それは「モデルを作る」ことではなく、「モデルを使いこなすための基盤やツール」を作ることかもしれません。

"AIユースケース先進国"という可能性

日本にはAIが解くべき課題がたくさんある、とよく言われます。超高齢社会と人手不足。製造業の品質管理と自動化。医療・介護の効率化。建設業の安全管理。物流の最適化。行政のデジタル化。 たとえば、製造現場での異常検知と作業標準の照合、介護現場での記録業務とケア計画支援、建設現場での安全書類チェックと規程照合などは、日本で先に実装知見が蓄積されやすい領域でしょう。

しかもこれらの現場には数十年分のデータとノウハウが蓄積されていて、「人手が足りないからAIを入れざるを得ない」という切実な動機がある。「AIを使ってみたい」ではなく「AIを使わないとオペレーションが回らない」というレベルの切迫感です。

労働人口の減少は、国立社会保障・人口問題研究所の将来推計人口（令和5年推計）を見ると深刻さが際立ちます。生産年齢人口は今後20年間で大幅な減少が見込まれており、推計の前提条件によって幅はあるものの、数千万人規模の縮小が予測されています。これは「生産性を上げないと社会が回らない」ということであり、AI導入のインセンティブとしてはこれ以上ないほど強烈です。

日本の優位は、モデルの供給側ではなく、制約の多い現場でAIを回す実装側にあるかもしれません。ただ、課題があることと、その課題をAIで解く力があることは別の話です。課題は豊富にあるけれど実装力が足りない、では宝の持ち腐れです。

実装力を育てるには何が必要か。まずAI活用の設計ができる人材。モデルの中身を理解し、業務プロセスとの統合を設計できる人です。次に、マルチベンダーでLLMを安全に使いこなすための基盤。そしてデータ統制とガバナンスの仕組み。成功パターンの共有と横展開。だからこそ、投資の優先順位が問われます。基盤モデルの自前開発に予算を割くのか、それとも「どんなモデルでも使いこなせる基盤」と「それを担える人材」に振るのか。どちらが費用対効果が高いかは、考えてみる価値のある問いだと思います。

使い方で輸出する

高齢化や人手不足はアジア全域で今後急速に顕在化する課題です。韓国、中国、タイ、ベトナム──いずれも20〜30年後には日本と似た人口構造の課題に直面します。日本がここでAI実装のノウハウを蓄積できれば、それ自体が輸出可能な知的資産になりえます。

モデルは海外製、使い方は日本式。「日本式AI活用」のパッケージ化という絵は、少なくとも検討に値するシナリオではないでしょうか。

製造業の品質管理にAIをどう組み込むか。高齢者介護のオペレーションをAIでどう最適化するか。建設現場の安全管理をAIでどう強化するか。こうしたドメイン特化の実装ノウハウは、基盤モデルを持っているだけでは生まれません。現場のデータと業務知識を持ち、それをAIに接続する設計力が必要です。

もちろん「基盤モデルを全くやるな」という話ではなく、防衛・インテリジェンスのように国産が不可欠な領域はありますし、研究開発の継続にも価値がある。100Bモデルの開発経験はモデルの内部動作の理解を深め、活用側のスキルにもフィードバックされます。ただ、リソース配分の重心をどこに置くか、という議論はもっとあっていいと思います。

第8章：おわりに

前後編を通じて、けっこう率直なことを書いてきました。

国産LLMの売上構造。SIerの多重委託構造と人月商売の矛盾。DC需要の実態と「面にならない」GPU需要。米国との投資規模の桁違い。データ主権議論の飛躍。SaaS産業の地殻変動と大規模な時価総額の調整。基盤モデル企業のアプリ層進出。

居心地のいい話ばかりではなかったかもしれません。

ただ、見方を変えれば、日本には課題があり、データがあり、現場がある。刀を打つ勝負では分が悪いかもしれないけれど、刀の使い手としてなら、まだまだやれることはたくさんあるはずです。

使いこなす力を磨くのか、作る力にこだわるのか。その選択が、これからの数年間でかなり効いてくるのではないかと思っています。

この2本の記事を通じて見てきた構造から、企業としてまず考えるべきことがあるとすれば、単一モデルを前提とした設計を避けること、モデルの選定よりも先に業務設計とガバナンスの枠組みを置くこと、そして自前のモデル開発よりも、どんなモデルでも使いこなせる基盤とそれを担える人材への投資を厚くすることです。これが唯一の正解だとは言いませんが、少なくとも検討のテーブルには載せる価値があるはずです。

本稿で提示した3つの論点——マルチベンダー統合、データ統制・ガバナンス、業務コンテキストへの接続——は、基盤モデルの進化とアプリケーション層の再編が同時進行する構造変化のなかで、企業がAIを持続的な競争優位へと転化していくうえで避けて通れない戦略的要点であると、私たちは捉えています。

Qualitegは創業以来、先端AIの研究開発と事業実装の双方からこの問いに一貫して向き合い、技術と戦略の両輪でクライアントの意思決定を支えてまいりました。

私たちは、20種類以上のLLMを単一の基盤から切り替え可能にするエンタープライズLLMプラットフォームBestllam®、LLMの入出力を監査し情報漏洩を検出・遮断するLLM-Audit™、機微情報を高速・高精度に検出・匿名化するPII-Fi™を自社開発・運用しています。いずれも、特定のAIベンダーに属さない独立した立場だからこそ提供できる基盤として設計してきました。

同時に、外資系コンサルティングファームやグローバル企業での事業開発・技術戦略の経験を持つメンバーが、ビジネスコンサルティングとAIテクノロジーコンサルティングを通じて、戦略立案から技術検証、実装、現場定着までを一貫して担っています。戦略を描く段階から技術者が同じテーブルに座ることで、技術的実現性と事業的合理性を両立した、地に足のついた設計を心がけています。

AIをどう事業に載せるか——この問いに取り組まれている企業の皆さまの一助となれるよう、私たちも戦略と技術の両面からご一緒できればと考えております。

ご相談やディスカッションのご要望がございましたら、お問い合わせよりお気軽にお声がけください。

こんにちは！Qualitegプロダクト開発部です！

PyCharmの内蔵npmツールで npm start を実行した瞬間、何のエラーメッセージもなくIDEが消える。

再起動してもう一度試すとまた落ちる。ログを見ても手がかりがない——。

今回はこの「サイレントクラッシュ」に遭遇し、原因の絞り込みから回避策の確立まで至った過程を書き残しておきます。同じ現象で困っている方の参考になれば幸いです。

環境

上記のとおり、PyCharmは執筆時点の最新版(2026.1)となります。

確認できたこと・推測していること

まず最初に、この記事で述べる内容の確度を整理しておきたいとおもいます

確認できたこと

• npmツール内蔵ターミナル経由でのみクラッシュが再現する（外部ターミナルでは再現しない）
• ConPTYを無効化すると回避できる
• idea.log、JVMクラッシュダンプともに有力な痕跡がない
• インストール先のパスに旧バージョン名（PyCharm 2023.1.6）が残っている
• conpty.dll が旧バージョンのパスからロードされている

推測していること

• 上書きアップデートに伴うネイティブコンポーネントの不整合が関与している可能性がある
• conpty.dll 周辺の互換性問題である可能性が高い
• 大量のコンソール出力時にだけ顕在化するネイティブ層の異常と考えられる

conpty.dll の新旧バージョンの差分比較やクラッシュダンプの詳細解析までは行っていないため、根本原因については状況証拠に基づく推測となりますが、
切り分けの結果としてConPTY周辺が原因である可能性は非常に高いと判断しています。

症状の詳細

PyCharmのnpmツール内蔵ターミナルで npm start を実行すると、数秒以内にPyCharmのウィンドウが消えます。タスクバーからも消え、プロセスも終了しています。再現率はほぼ100%でした。

特徴的だったのは以下の点です。

• エラーダイアログが一切表示されない
  JetBrains標準のクラッシュ通知も出ません。ウィンドウが文字通り「消える」だけです。
  
• idea.logにクラッシュの痕跡がない
  正常に起動・インデックス完了した後、ログがプツッと途切れています。
  
• Pythonスクリプトの実行では問題が起きない
  Run ConfigurationからPythonを実行する分には安定しています。
  
• コマンドプロンプトから npm start してもPyCharmは落ちない。
  外部ターミナルを使えば問題なく動作します。

最後の点が最も重要な切り分けポイントとなります。

ログに何も残らないサイレントクラッシュの難しさ

通常、PyCharm（IntelliJ系IDE）がクラッシュすると、idea.log にJavaレベルの例外が記録されるか、JVMクラッシュダンプ（java_error_in_pycharm_*.log）がユーザーのホームディレクトリに生成されます。

今回はそのどちらにも有用な情報がありませんでした。これはJava層ではなく、もっと低いレイヤー——ネイティブコード層でプロセスが異常終了している可能性を示唆しています。JVMがクラッシュダンプを書く暇もなく終了させられている状態です。

ログに何も残らないため、「何を変えたら再現しなくなるか」を1つずつ試す切り分けテストが唯一の手段でした。

ログの場所について補足

なお、PyCharmのログと設定は別々のディレクトリに保存されています。ログは %LOCALAPPDATA%（AppData\Local）、設定は %APPDATA%（AppData\Roaming）です。ネット上では %APPDATA% としか書かれていないことが多く、Roamingを探して「ない！」となるケースがよくあります。

ログ:  %LOCALAPPDATA%\JetBrains\<バージョン>\log\
設定:  %APPDATA%\JetBrains\<バージョン>\

一番手軽なのは Help → Show Log in Explorer です。2025年以降のバージョンでは Help → Diagnostic Tools → Special Files and Folders で全ディレクトリのフルパスが一覧表示できるので、こちらも便利です。

idea.log から読み取れた手がかり

クラッシュの瞬間は記録されていませんでしたが、idea.logからはいくつかの間接的な手がかりが得られました。

インストールパスと設定パスの不一致

Djb.vmOptionsFile=C:\Users\ml\AppData\Roaming\JetBrains\PyCharm2026.1\pycharm64.exe.vmoptions
Djna.boot.library.path=C:\Program Files\JetBrains\PyCharm 2023.1.6/lib/jna/amd64

設定ファイルのパスセレクタは PyCharm2026.1 なのに、インストール先は PyCharm 2023.1.6 のままです。

これは、長年の上書きアップデートによって環境の一貫性が崩れていることがわかります。ネイティブバイナリが想定通りに更新されていない可能性を疑う材料になりました。

ConPTYのロード元

Loaded bundled ConPTY from C:\Program Files\JetBrains\PyCharm 2023.1.6\lib\pty4j\win\x86-64\conpty.dll

npmツール内蔵ターミナルが使用する conpty.dll が旧バージョンのパスからロードされています。PyCharm 2026.1が想定するバージョンと一致しているかどうかは確認できていませんが、パスの不自然さは気になる点です。

node_modules の大量ファイル登録

NodeModulesDirectoryManager - Contributed {
  allCalculationsDuration: 2263 ms,
  allIncludedFileCount: 45078,
  allRootsWorkspaceModel: 42960,
  ...
}

45,078ファイルがインデックス対象として登録されていました。

最初はこれがクラッシュの原因ではないかと疑いましたが、node_modules をExcludedに設定してもクラッシュは解消しませんでした。(実はexcludedにしても、librootにしてるとインデックスしちゃう事象がありますので、excludedの効能が正直理解しきれていない面もあります）パフォーマンスの問題ではありましたが、クラッシュの直接原因ではなかったようです。

JVMメモリ設定の重複

-Xms256m, -Xmx2048m, ..., -Xmx8192m

-Xmx がうっかり2回指定されていました（後者が有効なので動作上は問題なし）。これ自体はクラッシュの原因ではありませんが、設定ファイルの引き継ぎにも一貫性のなさが見え、環境全体に違和感があることを示していました。

切り分けテストと原因の絞り込み

テスト1: 外部ターミナルから npm start を実行する

PyCharmを開いた状態で、外部のコマンドプロンプトから npm start を実行したところ、PyCharmは落ちませんでした。

これにより、問題が npm start 自体ではなく、PyCharmのnpmツール内蔵ターミナルを経由して実行したときだけ起きることが確認できました。

この1つのテストで、疑わしい範囲が一気に狭まりました。

テスト2: ConPTYを無効化する

次は、PyCharmの内部レジストリ設定で terminal.use.conpty.on.windows を false に変更し、npmツール内蔵ターミナルから npm start を実行しました。

結果、クラッシュしなくなりました。

この2つの切り分けから、問題がConPTY周辺にあることはほぼ確実と判断しました。

ConPTYの無効化手順

Settings（設定画面）のTerminalセクションにはConPTYのオン・オフ項目がないため、内部レジストリから変更する必要があります。

1. Help → Find Action（Ctrl+Shift+A）を開く
2. Registry と入力してEnterを押す
3. レジストリ画面の検索欄に terminal.use.conpty.on.windows と入力する
4. 該当項目のチェックボックスをオフにする
5. PyCharmを再起動する

これでターミナルはConPTYではなく旧方式のWinPTYで動作するようになります。カラー出力の品質が若干落ちる場合がありますが、安定性は大幅に向上します。

なぜConPTYで落ちるのか（推測）

ここからは状況証拠に基づく推測です。裏付けとなるクラッシュダンプの解析やDLLのバージョン比較は行っていないため、その前提で読んでいただければと思います。

ConPTY（Windows Pseudo Console）は、Windows 10 バージョン1809で導入された仮想端末APIで、従来のWinPTYに代わりカラー出力やUnicode対応を改善した仕組みです。VS Code、Windows Terminal、JetBrains系IDEの内蔵ターミナルなどで採用されています。

npm start で起動するNode.jsの開発サーバーは、コンパイルログやHMR通知などを大量かつ高速にコンソールへ出力します。ConPTYはこの出力をPyCharmのJavaプロセスに中継する役割を担っています。

今回の環境では、PyCharm 2026.1が PyCharm 2023.1.6 のフォルダにインストールされており、conpty.dll も旧パスからロードされていました。上書きアップデートではすべてのネイティブバイナリが確実に更新される保証がないため、新しいターミナルエンジンと conpty.dll の間で何らかの不整合が生じ、大量出力時にネイティブ層で異常終了に至っている——というのが現時点での仮説です。

idea.logに記録が残らないのも、この仮説と整合的です。クラッシュがJVMの管理外のネイティブコードで発生している場合、JVMのエラーハンドラ自体が呼ばれず、ログを書く余地がないためです。

より確度の高い原因特定を行うのであれば、Windows Event ViewerでのApplication Errorの確認、ProcMonによるDLLロードのトレース、conpty.dll のファイルバージョン比較などが有効な次のステップになると思います。

複合的な条件で発生する問題

今回の問題は、複数の条件が重なって初めて顕在化するタイプのものでした。

どれか1つの条件を外すだけでクラッシュは回避できます。裏を返すと、再現条件の特定が難しく、「環境によって起きたり起きなかったりする」ように見える厄介な問題でもあります。

再発防止のための対策: クリーンインストール

ConPTYの無効化は１つの回避策ですが、そもそもネイティブコンポーネントの不整合が関与しているのであれば、クリーンインストールで解消される可能性が高いと考えています。

結局それかよって感じですが、やっぱりクリーンインストールするのが一番手っ取り早く効果があられるかもしれません。

1. PyCharmをアンインストールする
2. C:\Program Files\JetBrains\PyCharm 2023.1.6\ フォルダが残っていれば手動で削除する
3. PyCharm 2026.1を新規インストールする

設定ファイルは %APPDATA%\JetBrains\PyCharm2026.1\ に保存されており、アンインストールしても消えないため、再インストール後に自動的に引き継がれます。

また、JetBrains Toolbox Appを使ってインストール・アップデートを管理すると、バージョンごとに独立したディレクトリにインストールされるため、今回のようなパスの不整合が起きにくくなります。

教訓

1. サイレントクラッシュには切り分けテストが最も有効

ログに情報がない場合、ログをいくら睨んでも答えは出ません。「何を変えたら再現しなくなるか」を1つずつ試す切り分けが最も効果的です。今回は「内蔵ターミナルか、外部ターミナルか」という1つの切り分けで原因の範囲を大幅に絞り込めました。

2. Updaterによる上書きアップデートには（案外）リスクがある

JetBrains系IDEに限らず、メジャーバージョンをまたぐ上書きアップデートは予期しない問題を引き起こすことがあります。特にネイティブバイナリが関わる場合、古いファイルが残ることで新旧の不整合が生じる可能性があります。メジャーアップデートの際はクリーンインストールを検討すべきです。

3. 「確認できたこと」と「推測していること」を分ける

これは今回きづいた教訓というか、先輩方に指摘されたことですが、トラブルシューティングの記録を残すとき、切り分けで確認した事実と、状況証拠からの推測を明確に分けておくことが大切です。
事実と推測を混ぜてしまうと、後から振り返ったときに「結局何がわかっていて何がわかっていないのか」が曖昧になってしまいます。

4. テレメトリデータも情報源になる

PyCharmが出力するworkspaceModelのメトリクスからは、ファイルインデックスの規模やメモリ使用状況など、idea.logだけではわからない情報が得られます。今回はこのデータから node_modules の大量ファイル登録を把握できました。結果的にクラッシュの直接原因ではありませんでしたが、パフォーマンス改善のための有益な情報でした。

まとめ

• PyCharmのnpmツール内蔵ターミナルで npm start を実行するとIDEがクラッシュする問題に遭遇しました。
• idea.logにもJVMクラッシュダンプにも記録が残らないサイレントクラッシュでした。（ただし、再現性が高かったのでわりと切り分けがしやすくてそこは助かりました）
• 切り分けの結果、ConPTY周辺が原因である可能性が非常に高いと判断しました。
• 上書きアップデートによるネイティブコンポーネントの不整合が関与していると推測しています（conpty.dll の新旧差分までは未検証）。
• レジストリで terminal.use.conpty.on.windows を無効化することで回避できます。
• 再発防止にはPyCharmのクリーンインストールが有力な対策です。

ログに何も残らない問題のデバッグは心が折れそうになりますが、AIの力もかりつつ地道な切り分けが結局は一番の近道だとおもいます。
同じ現象で困っている方の助けになれば嬉しいです。

それでは、次回またお会いしましょう！

こんにちは、今回はシリーズ第6回トラブルシューティング - よくある問題と解決方法 について解説いたします！

さて、前回（第5回）は、統合Windows認証がブラウザでどのように動作するかを解説しました。

「イントラネットゾーン」という概念を理解することで、同じサーバーでもURLの書き方（NetBIOS名、FQDN、IPアドレス）によって認証動作が変わる理由が明確になったかと思います。また、Chrome/Firefoxではデフォルトで統合認証が無効になっている理由と、グループポリシーによる一括設定方法も学びました。

しかし、設定が完璧なはずなのに「なぜかうまく動かない」という場面は、実際の現場では必ず訪れます。

「最近、ファイルサーバーへのアクセスが遅い」「金曜日は使えたのに、月曜日の朝にログインできない」「特定のサービスだけKerberosが失敗する」——これらはヘルプデスクに日々寄せられる典型的な問い合わせです。

原因はKerberosの失敗、時刻のずれ、SPNの設定ミス、DNS関連の問題など多岐にわたりますが、体系的にトラブルシューティングすることで必ず解決できます。

今回は、AD環境で頻繁に起きるトラブルをパターン別に整理し、診断コマンドを使った原因特定から具体的な解決手順まで、実践的なトラブルシューティングの流れを解説します。焦らず、一つずつ確認していくことが解決への近道です。それでは始めていきましょう！

連載の構成

• 第1章：基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎
• 第2章：ドメイン環境の構築 - 検証環境の構築手順
• 第3章：クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順
• 第4章：プロキシサーバーと統合Windows認証
• 第5章：ブラウザ設定と認証 - 各ブラウザでの設定方法
• 【★今回です★】第6章：トラブルシューティング - よくある問題と解決方法
• 第7章：セキュリティとベストプラクティス - 本番環境での考慮事項
• 第8章：実践的な構成例 - AIセキュリティツールとの統合事例

第6章：トラブルシューティング

6.1 認証関連のトラブル

6.1.1 Kerberosが失敗してNTLMにフォールバックする原因

Kerberosは最も安全な認証方式ですが、様々な理由で失敗し、NTLMにフォールバックすることがあります。これは、パフォーマンス低下の原因にもなります。

【典型的な症状】
ユーザー：「最近、ファイルサーバーへのアクセスが遅いんです」
IT管理者：「ログを確認してみましょう」

イベントログ：
Kerberos認証に失敗しました。
NTLMにフォールバックします。

IT管理者：「Kerberosが失敗してますね。原因を調べましょう」

診断コマンドの実行を見てみましょう。

【Kerberos診断】
# 現在のチケット確認
klist

結果（正常な場合）：
キャッシュされたチケット: 2
#0> クライアント: tanaka_t @ JP.QUALITEG.COM
    サーバー: krbtgt/JP.QUALITEG.COM @ JP.QUALITEG.COM
    暗号化の種類: AES-256-CTS-HMAC-SHA1-96
    チケットの有効期限: 2024/01/20 18:00:00

結果（問題がある場合）：
キャッシュされたチケット: 0
→ チケットが取得できていない

# チケット取得のテスト
kinit tanaka_t@JP.QUALITEG.COM

よくある原因1：DNS関連の問題を見てみましょう。

【DNSが原因の場合】
状況：NetBIOS名では動くが、FQDNでは失敗

テスト：
# NetBIOS名
ping fileserver → 成功
アクセス: \\fileserver\share → 成功（NTLM）

# FQDN
ping fileserver.jp.qualiteg.com → 成功
アクセス: \\fileserver.jp.qualiteg.com\share → 遅い（Kerberos失敗→NTLM）

原因調査：
nslookup fileserver.jp.qualiteg.com
→ 正引きOK

nslookup 192.168.1.50
→ 逆引きNG！

IT管理者：「逆引きDNSレコードが missing です」

解決策：
DNSマネージャーで逆引きゾーンにPTRレコード追加
50.1.168.192.in-addr.arpa. → fileserver.jp.qualiteg.com.

よくある原因2：SPN（Service Principal Name）の問題を見てみましょう。

【SPNが原因の場合】
症状：特定のサービスだけKerberosが失敗

確認コマンド：
setspn -L fileserver

結果（問題なし）：
登録されたSPN:
    HOST/fileserver
    HOST/fileserver.jp.qualiteg.com

結果（問題あり）：
登録されたSPN:
    （空）

または重複エラー：
setspn -X
重複したSPNが見つかりました：
    HTTP/intranet.jp.qualiteg.com
    → サーバーAとサーバーBの両方に登録

解決策：
# SPN追加
setspn -A HOST/fileserver.jp.qualiteg.com FILESERVER$

# 重複削除
setspn -D HTTP/intranet.jp.qualiteg.com サーバーB

暗号化方式の不一致も見てみましょう。

【暗号化の非互換性】
Windows Server 2019管理者：「新しいDCを追加したら認証が遅くなった」

調査：
# サポートされる暗号化方式の確認
グループポリシー：
ネットワークセキュリティ: Kerberos で許可された暗号化方式の構成

古いサーバー：RC4-HMAC（非推奨）
新しいサーバー：AES256-CTS-HMAC-SHA1-96

問題：
古いアプリ：「RC4しか話せません」
新DC：「RC4は無効化されています」
結果：Kerberos失敗

解決策：
1. 一時的にRC4を有効化（セキュリティリスクあり）
2. アプリケーションのアップデート（推奨）

6.1.2 時刻同期の重要性

Kerberos認証において、時刻同期は極めて重要です。5分以上のずれがあると認証が失敗します。

【時刻ずれによる認証失敗】
月曜日の朝：
田中：「金曜日は使えたのに、ログインできません！」
エラー：「現在、ログオン要求を処理できるログオンサーバーはありません」

IT管理者：「時刻を確認してみましょう」

クライアントPC：2024/01/20 09:00:00
DC：2024/01/20 09:07:00
差：7分

IT管理者：「5分以上ずれてます。これが原因です」

時刻同期の仕組みを理解しましょう。

【Windows時刻同期の階層】
正しい構成：
インターネット時刻サーバー（time.windows.com）
    ↓
PDCエミュレーター（DC01）
    ↓
その他のDC（DC02, DC03）
    ↓
メンバーサーバー、クライアントPC

確認コマンド：
# 時刻源の確認
w32tm /query /source

正常：DC01.jp.qualiteg.com
問題：Local CMOS Clock → 同期していない

# 詳細状態
w32tm /query /status

時刻同期の修正方法を見てみましょう。

【時刻同期の設定】
PDCエミュレーターでの設定：
# 外部時刻源の設定
w32tm /config /manualpeerlist:"time.windows.com,0x9 ntp.nict.jp,0x9" /syncfromflags:manual /reliable:yes /update

# サービス再起動
net stop w32time && net start w32time

# 即座に同期
w32tm /resync /rediscover

その他のDCでの設定：
# PDCエミュレーターから同期
w32tm /config /syncfromflags:domhier /update

クライアントPCでの設定：
# 通常は自動だが、手動設定も可能
w32tm /config /syncfromflags:domhier /update

時刻同期のトラブルシューティングを行いましょう。

【よくある時刻同期の問題】
問題1：ファイアウォールでNTPがブロック
症状：
w32tm /stripchart /computer:time.windows.com
エラー: 0x800705B4 - タイムアウト

解決：
UDP 123番ポートを開放

問題2：仮想マシンの時刻同期競合
症状：
VM：「ホストと同期します」
DC：「いや、NTPと同期して」
結果：時刻が安定しない

解決：
VMware: VMware Toolsの時刻同期を無効化
Hyper-V: 統合サービスの時刻同期を無効化

問題3：大幅な時刻ずれ
症状：
w32tm /resync
コンピューターの再同期コマンドがコンピューターに送信されましたが、
時刻データが利用できなかったためにエラーが発生しました。

原因：差が大きすぎて自動修正を拒否（通常48時間以上）

解決：
# 手動で近い時刻に設定してから同期
net time \\DC01 /set /y

6.1.3 SPN（Service Principal Name）の設定

SPNは、Kerberos認証でサービスを一意に識別するための名前です。正しく設定されていないと、Kerberos認証が失敗します。

【SPNとは何か】
新人：「SPNって何ですか？」
IT管理者：「サービスの住所みたいなものです」

例えで説明：
田中さんの自宅 = HOST/tanaka-pc.jp.qualiteg.com
　場所：tanaka-pc.jp.qualiteg.com
　用途：HOST（コンピューター）

会社のWebサーバー = HTTP/intranet.jp.qualiteg.com
　場所：intranet.jp.qualiteg.com  
　用途：HTTP（Webサービス）

Kerberos：「HTTP/intranet.jp.qualiteg.comへのチケットをください」
KDC：「SPNを検索...見つかった！チケット発行」

SPNの確認と登録を行いましょう。

【SPNの管理】
# 特定のアカウントのSPN確認
setspn -L IIS_Service

# コンピューターアカウントのSPN確認  
setspn -L SERVER01$

典型的なSPN：
HOST/server01
HOST/server01.jp.qualiteg.com
TERMSRV/server01
TERMSRV/server01.jp.qualiteg.com
RestrictedKrbHost/server01
RestrictedKrbHost/server01.jp.qualiteg.com

# IISサーバーのSPN登録例
# アプリケーションプールが特定のアカウントで実行される場合
setspn -A HTTP/webapp.jp.qualiteg.com JP\webapp_svc
setspn -A HTTP/webapp JP\webapp_svc

SPN関連のトラブルを見てみましょう。

【重複SPNの問題】
症状：Webサイトにアクセスすると認証エラー

調査：
setspn -X
処理中...
重複が見つかりました：
HTTP/intranet.jp.qualiteg.com が以下に登録:
  - SERVER01$
  - intranet_svc

IT管理者：「同じSPNが2つのアカウントに！」

理由：
1. 最初、SERVER01のコンピューターアカウントで動いていた
2. 後でサービスアカウント（intranet_svc）に変更
3. 古いSPNを削除し忘れ

解決：
setspn -D HTTP/intranet.jp.qualiteg.com SERVER01$
→ 古い方を削除

アプリケーションプールとSPNの関係を見てみましょう。

【IISでの実例】
シナリオ：社内ポータルサイトの構築

構成：
- URL: http://portal.jp.qualiteg.com
- アプリケーションプール: PortalAppPool
- 実行アカウント: JP\portal_svc

必要な作業：
1. サービスアカウント作成
New-ADUser -Name "portal_svc" -AccountPassword (ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force) -Enabled $true

2. SPN登録
setspn -A HTTP/portal.jp.qualiteg.com JP\portal_svc
setspn -A HTTP/portal JP\portal_svc

3. IISでの設定
- アプリケーションプール → 詳細設定 → ID → portal_svc
- 認証 → Windows認証：有効、匿名認証：無効

4. 確認
setspn -L portal_svc
→ SPNが表示されることを確認

6.1.4 DNS関連の問題

DNS設定の問題は、AD環境でのトラブルの大半を占めます。正しく設定されていないと、認証以前に名前解決で失敗します。

【典型的なDNS問題】
ユーザー：「ファイルサーバーにつながりません」
IT：「pingしてみてください」
ユーザー：「ping fileserver」
結果：ping 要求ではホスト fileserver が見つかりませんでした

IT：「DNSサフィックスを確認しましょう」
ipconfig /all
DNSサフィックス: （空）← 問題！

DNSサフィックスの設定を見てみましょう。

【DNSサフィックスの重要性】
正しい設定：
プライマリDNSサフィックス: jp.qualiteg.com
DNS サフィックス検索一覧: jp.qualiteg.com, tokyo.jp.qualiteg.com

動作の違い：
# サフィックスなし
ping fileserver
→ 「fileserver」を探す → 失敗

# サフィックスあり  
ping fileserver
→ 「fileserver.jp.qualiteg.com」を探す → 成功

設定方法：
1. DHCP経由（推奨）
   Option 015: jp.qualiteg.com

2. 手動設定
   ネットワークアダプター → プロパティ → 詳細設定 → DNS
   「この接続のDNSサフィックス」: jp.qualiteg.com

DNSの正引き・逆引き問題を見てみましょう。

【逆引きDNSの重要性】
問題の症状：
- 名前でアクセス: 成功
- IPでアクセス: 認証に時間がかかる

調査：
# 正引きテスト
nslookup server01.jp.qualiteg.com
→ 192.168.1.20

# 逆引きテスト  
nslookup 192.168.1.20
→ *** dns1.jp.qualiteg.com can't find 192.168.1.20: Non-existent domain

原因：逆引きゾーンがないか、レコードがない

解決策：
1. DNS管理ツールで逆引きゾーン作成
   - 新しいゾーン → 逆引き参照ゾーン
   - ネットワークID: 192.168.1

2. PTRレコード追加
   - 20 → server01.jp.qualiteg.com.

DNSキャッシュの問題を見てみましょう。

【古いDNS情報によるトラブル】
状況：サーバーのIPアドレスを変更した後

ユーザー：「新しいサーバーにつながらない」
IT：「DNS確認してみましょう」

# DNSサーバーに問い合わせ
nslookup server01.jp.qualiteg.com 192.168.1.10
→ 192.168.1.50（新IP）

# でもpingは古いIPに
ping server01.jp.qualiteg.com
→ 192.168.1.20（旧IP）に ping しています

原因：ローカルDNSキャッシュ

解決：
ipconfig /flushdns
→ DNSキャッシュをクリア

確認：
ipconfig /displaydns
→ キャッシュ内容を表示

条件付きフォワーダーの設定を見てみましょう。

【複数ドメイン環境でのDNS】
シナリオ：会社買収で別ドメインと連携

環境：
- 自社: jp.qualiteg.com（192.168.1.0/24）
- 買収先: acquired.local（192.168.2.0/24）

問題：
nslookup server.acquired.local
→ 見つからない

解決策：条件付きフォワーダー
DNSマネージャー → 条件付きフォワーダー → 新規
- DNSドメイン: acquired.local
- IPアドレス: 192.168.2.10（買収先のDNS）

結果：
acquired.localへの問い合わせは192.168.2.10に転送

6.2 ドメイン参加のトラブル

6.2.1 「ドメインが見つからない」エラー

ドメイン参加時の最も一般的なエラーです。原因は多岐にわたりますが、体系的にトラブルシューティングすることで解決できます。

【典型的なエラーメッセージ】
エラー：
「ドメイン "jp.qualiteg.com" に接続できませんでした。
（ドメインが存在しないか、またはアクセスできません）」

新人IT：「ドメイン名は合ってるのに...」
先輩：「順番に確認していきましょう」

ステップ1：ネットワーク接続の確認を行いましょう。

【基本的な接続確認】
# IPアドレスの確認
ipconfig /all

確認ポイント：
- IPアドレス: 169.254.x.x → DHCPサーバーに届いていない
- IPアドレス: 192.168.1.x → 正常
- DNSサーバー: 192.168.1.1 → ルーターを見ている（NG）
- DNSサーバー: 192.168.1.10 → DCを見ている（OK）

# DCへの疎通確認
ping 192.168.1.10
→ 応答があることを確認

ステップ2：DNS名前解決の確認を行いましょう。

【DNS解決のテスト】
# ドメイン名の解決
nslookup jp.qualiteg.com

正常な応答：
Server:  dc01.jp.qualiteg.com
Address: 192.168.1.10

Name:    jp.qualiteg.com
Addresses: 192.168.1.10, 192.168.1.11

問題のある応答：
*** dc01.jp.qualiteg.com can't find jp.qualiteg.com: Non-existent domain

# SRVレコードの確認（重要）
nslookup -type=srv _ldap._tcp.jp.qualiteg.com

正常な応答：
_ldap._tcp.jp.qualiteg.com    SRV service location:
    priority       = 0
    weight         = 100  
    port          = 389
    svr hostname  = dc01.jp.qualiteg.com

ステップ3：ファイアウォールの確認を行いましょう。

【必要なポートの確認】
# PowerShellでポート確認
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 389
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 445
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 88
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 135

必要なポート：
- 88 (Kerberos)
- 135 (RPC Endpoint Mapper)
- 389 (LDAP)
- 445 (SMB)
- 636 (LDAPS)
- 3268 (Global Catalog)

Windowsファイアウォールの一時無効化（テスト用）：
netsh advfirewall set allprofiles state off
※テスト後は必ず有効に戻す

6.2.2 認証エラーの対処法

ドメインは見つかるが、認証で失敗するケースの対処法です。

【認証エラーの種類】
エラー1：
「ログオンに失敗しました: ユーザー名を認識できないか、
またはパスワードが間違っています。」

エラー2：
「指定されたドメインがないか、またはコンタクトできません。」

エラー3：
「現在、ログオン要求を処理できるログオンサーバーはありません。」

ユーザー名の形式問題を見てみましょう。

【正しいユーザー名の形式】
よくある間違い：
× administrator（ドメイン指定なし）
× tanaka_t（一般ユーザー）
× admin（存在しないユーザー）

正しい形式：
○ JP\Administrator
○ Administrator@jp.qualiteg.com
○ jp.qualiteg.com\Administrator

# 現在のドメイン管理者の確認
net group "Domain Admins" /domain

アカウントの状態確認を行いましょう。

【管理者アカウントの問題】
# DCで実行（アカウント状態確認）
net user Administrator /domain

確認ポイント：
- アカウント有効: Yes
- アカウントの有効期限: 無期限
- パスワード有効期限: 無期限
- アカウントロックアウト: No

# ロックアウトされている場合
net user Administrator /active:yes /domain

# パスワードリセット（最終手段）
net user Administrator NewP@ssw0rd /domain

ドメイン参加に使用できるアカウントを確認しましょう。

【権限の確認】
# Domain Adminsグループのメンバー確認
net group "Domain Admins" /domain

# 他に使えるグループ
- Domain Admins（全権限）
- Enterprise Admins（フォレスト全体）  
- Account Operators（限定的な権限）

# 委任された権限の確認
dsacls "OU=Computers,DC=jp,DC=qualiteg,DC=com"
→ コンピューターオブジェクト作成権限を確認

6.2.3 ネットワーク設定の確認ポイント

ドメイン参加の成功には、正しいネットワーク設定が不可欠です。

【チェックリスト形式での確認】
IT管理者：「この順番で確認していけば、問題を特定できます」

□ 1. 物理接続
  - LANケーブル接続
  - リンクランプ点灯
  - 正しいVLAN

□ 2. IPアドレス設定
  - 固定 or DHCP
  - 同一サブネット内
  - 重複なし

□ 3. DNS設定
  - プライマリDNS = DC
  - セカンダリDNS = 別DC（あれば）
  - DNSサフィックス設定

□ 4. 疎通確認
  - DC へping
  - ポート確認
  - 名前解決確認

VLANをまたぐ場合の注意点を見てみましょう。

【VLAN環境での考慮事項】
構成例：
- VLAN 10: サーバーセグメント（192.168.10.0/24）
  - DC: 192.168.10.10
- VLAN 20: クライアントセグメント（192.168.20.0/24）
  - Client: 192.168.20.100

必要な設定：
1. ルーティング
   - VLAN間ルーティング有効
   - 各VLANのデフォルトゲートウェイ設定

2. ファイアウォール
   - VLAN間で必要なポート許可
   - 特に135, 445, 389等

3. DNS設定
   - クライアントのDNS: 192.168.10.10
   - DNSがVLAN越えで到達可能

確認コマンド：
tracert 192.168.10.10
→ 経路確認

プロキシ設定の影響を見てみましょう。

【プロキシが邪魔をするケース】
症状：ブラウザは使えるが、ドメイン参加できない

原因：システムプロキシの設定

確認：
netsh winhttp show proxy

現在の WinHTTP プロキシ設定:
    プロキシサーバー: proxy:8080
    バイパス一覧: （なし）

問題：DCへの通信もプロキシ経由しようとする

解決策：
netsh winhttp set proxy proxy:8080 bypass-list="*.jp.qualiteg.com;192.168.*"

または完全リセット：
netsh winhttp reset proxy

IPv6の影響を見てみましょう。

【IPv6関連の問題】
症状：名前解決が遅い、不安定

確認：
ipconfig /all
IPv6アドレス: 2001:db8::1234（有効）
IPv4アドレス: 192.168.1.100

問題：IPv6が優先されるが、DCはIPv4のみ

解決策1：IPv6を無効化（一時的）
ネットワークアダプター → プロパティ
□ インターネットプロトコルバージョン6（チェックを外す）

解決策2：IPv4を優先（推奨）
netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 46 4
→ IPv4を優先するポリシー

これらの確認ポイントを順に確認することで、ほとんどのドメイン参加問題を解決できます。重要なのは、あわてずに一つずつ確認していくことです。

次回予告

次回は「第7章 セキュリティとベストプラクティス - 本番環境での考慮事項」

灰、上記タイトルのとおり次回は、「動く」環境を「安全に動く」環境にするための話です。

システムが正常に動作することと、安全に運用されることは別の問題です。認証基盤を本番環境に展開するからこそ、セキュリティの考慮が欠かせません。「Basic認証のパスワードは実はネットワーク上で丸見えになっている」「Domain Adminsに50人も登録されている」「退職者のアカウントがそのまま残っている」——こうした問題は、気づいた時には手遅れになっていることもあります。

次回は、Basic認証が抱える根本的なリスク、パスワード管理・管理者権限の最小化といったベストプラクティス、そして監視・ログ・定期監査の具体的な実装方法まで、本番運用を見据えたセキュリティの全体像をお届けします。

それでは、第7回でお会いしましょう！

— AI導入を"事業に載せる"ために、いま設計すべきこと（全3回）

こんにちは！Qualitegコンサルティングチームです！

前回（第1回）では、Replit/Lemkin事件とDeloitte豪州政府報告書問題を通じて、AIエージェント導入の課題がモデル性能ではなく「権限・監査・責任の設計不在」にあることを見ました。

では、実際に事故が起きたとき、責任は誰が負うのでしょうか。第2回となる本記事では、法務・契約・組織の3つの観点から、AIエージェントの責任分解がなぜ難しいのかを構造的に整理します。

結論を先に言えば、法務だけでも契約だけでも組織論だけでも足りません。この3つを接続して設計しなければ、AIエージェントの責任分解は実務上機能しません。

1. 法的フレームワーク：複数の法理論が並走している

AIエージェントが損害を出したとき、どの法理論で責任が問われるかについて、現時点でグローバルなコンセンサスは形成されていません。

Clifford Chanceの論考は、この状況の根本的な難しさを整理しています。法律は歴史的に、有害な行為がいつどのように発生したかを特定でき、人間が意思決定の責任を負い、使用者がその被用者の行為に対して責任を負うことを前提に発展してきました。しかしAIエージェントは、この3つの前提すべてを揺るがす可能性があります。

以下の図は、この法的不確実性の中で、契約と運用設計がどのような役割を果たすかを示しています。

法規制は法域ごとに異なり流動的ですが、契約は合意によって明確化でき、運用設計は自社でコントロールできます。つまり、法的不確実性が高い現状だからこそ、契約と運用の設計力が実務上の防衛線になります。

注目される判例：Mobley v. Workday

こうした法的不確実性を具体的に示す事例として、Mobley v. Workday事件が注目されています。WorkdayのAI・機械学習を用いた求職者スクリーニングが差別的影響を与えたとして訴えられたケースで、Lathrop GPM法律事務所の分析によれば、AIベンダー自身の責任が問われうる可能性が実務上注目されています。もっとも、責任の成立範囲が確定したとまでは言い切れず、今後の判断の蓄積を見守る必要がある段階です。

EUの動き：製造物責任の射程拡大

EUでは、新製造物責任指令（PLD）がソフトウェアやAIを製品責任の射程に明示的に含めました。欧州委員会の公式ページによれば、加盟国は2026年12月9日までに国内法化する必要があり、原則としてその日以後に市場投入された製品に新ルールが適用されます。ただし、実際の責任成立には欠陥・損害・因果関係の立証が引き続き必要であり、「AIであれば即座に厳格責任」と読むべきではありません。Squire Patton Boggsの分析が、この点を実務的に整理しています。

米国：連邦法不在のなか、州法が先行

米国には連邦レベルのAI責任法が存在しません。一方で州レベルでは、AIの利用に対して企業の責任を明確化する方向の個別立法やガイドライン整備が進んでいます。コロラド州AI法（2026年6月30日施行予定）をはじめ、テキサス州やユタ州など複数の州で立法・政策の動きが見られます（各州法の動向はCPO Magazineの2026年1月の記事が整理しています。なお、州ごとに成立済み・施行待ち・審議中と段階が異なり、施行時期や最終的な内容は変動し得るため、個別の対応には最新の一次情報の確認が不可欠です）。

雇用分野では、EEOCがAIツールによる差別的な結果に対して雇用主側の責任を重く見る立場を示しています。ツールが内製か外部調達かを問わず、Title VIIの下での雇用主の義務は変わらないという考え方です（Lexology, 2026年1月）。

実務上の含意は明確です。法的責任の帰属が法域ごとに異なり流動的である以上、責任の帰属が曖昧なままPoCや導入を進めると、契約・運用・障害対応のすべてが後追いになるリスクがあります。

2. 「指示」と「行動」の距離：従来ソフトウェアとの構造的な違い

AIエージェントの責任分解が従来のソフトウェアより格段に難しい理由は、「指示した内容」と「実際にエージェントが行った内容」の間にギャップが生まれるからです。

以下の図は、従来ソフトウェアとAIエージェントの違いを示しています。

前述のClifford Chanceの論考が指摘するように、エージェント型AIは元の人間の指示と最終的なアウトプットとの間にギャップを生み出します。システムが様々な段階で直接的な人間の介入なしに判断を下し行動するため、問題が起きた場合の因果関係の特定が困難です。

この構造的な違いにより、実務上はまず導入企業側の管理責任や運用責任が問われやすくなっています。他方で、ベンダー側の設計・表示・契約上の義務が争点となる余地もあり、責任が常に一方向に定まるわけではありません。

eSentire LabsのAlexander Feick氏は、IT Proの取材に対してこう述べています。「チェーン（判断の連鎖）を再構築できなければ、ワークフローを防御することも改善することもできない。アカウンタビリティはモデルではなく、組織と人間の意思決定者に帰属する」。

つまり、AIエージェントの導入においては、判断の連鎖を事後的に再構成できる設計を持っているかどうかが、責任分解の実効性を左右します。

3. 契約実務の最前線：AI固有の条項が登場している

法的フレームワークが未確定であるからこそ、契約設計の重要性が増しています。

Mayer Brownが2026年2月に公表した論考では、エージェント型AIが受動的なツールから自律的に行動するアクターへと変化するにつれ、契約モデルが従来のSaaS型からサービス提供型へとシフトしていると指摘しています。具体的には、AIエージェントに対する「権限委譲（delegation of authority）」の範囲と「ポリシーガードレール」を契約上明確に定義すべきとされています。

以下の図は、こうした流れの中で先進的な契約実務において議論されているAI固有の論点を整理したものです。

Morgan Lewisの2025年のシリーズ論考が報告しているキルスイッチ、シャドウモード運用、再トレーニングウィンドウなどの考え方は、先進的な契約実務において議論・採用が進みつつある論点です。市場で完全に定型化した標準条項というよりも、AI固有のリスクに対応するための契約設計の方向性として注目されています。

責任の配分については、Fladgate法律事務所の論考が「寄与過失（contributory fault）」の枠組みを提案しています。責任を一方に寄せるのではなく、各当事者のコントロール可能な範囲に応じて配分する設計は、現実的な落としどころになり得るでしょう。

重要なのは、これらの契約条項を個別に導入することではなく、権限設計・運用設計と接続された契約として設計することです。

4. 組織の現実：オーナーシップが曖昧なまま導入が進んでいる

契約上の工夫が進む一方で、組織の内部では準備が追いついていないという実態があります。

IT Proが報じたAsanaの2025年調査（米英2,025人のナレッジワーカー対象）では、AIエージェントを管理する労働者の6割が「自信を持って間違えるアウトプット」によって業務が困難になったと回答しています。さらに、回答者の3分の1がAI関連の問題発生時に誰に連絡すればよいかわからないと答えました。

IBMの2026年1月の論考が引用するGartnerの予測では、2027年末までにエージェント型AIプロジェクトの40%以上がコスト増大・不明確なビジネス価値・不十分なリスク管理を理由に中止されるとも見込まれています。

以下の図は、オーナーシップが曖昧なまま導入が進んだ場合に何が起きるかを示しています。

組織内のオーナーシップが曖昧なままでは、どれほど高性能なモデルを使っても、導入は安定しません。AIの導入課題は、技術そのものよりも、責任分解と意思決定構造の設計不備として表れます。

まとめ：法務・契約・組織を分けて考えていては、責任分解は機能しない

ここまで見てきたように、AIエージェントの責任分解は、法務だけでも契約だけでも組織論だけでも完結しません。

法的フレームワークは法域ごとに異なり、なお流動的です。しかしその流動性を理由に設計を先延ばしにすると、契約・運用・障害対応のすべてが後追いになります。AIエージェントの導入を安定させるには、法務・契約・運用設計を分けずに考え、一つの導入アーキテクチャとして接続することが必要です。

構想から運用定着までQualitegが伴走できる領域

今回は、AIエージェントの責任分解がなぜ難しいのかを、法務・契約・組織の3つの観点から整理してきました。法的責任の枠組みがなお流動的である一方で、実務ではすでに、契約条項、運用統制、責任オーナーシップの設計が強く求められています。

AIエージェントは、従来のソフトウェア以上に「指示」と「行動」の距離が大きく、問題が起きたときの因果関係や責任の境界が曖昧になりやすい領域です。だからこそ、法務だけ、契約だけ、現場運用だけで分けて考えるのではなく、実装・運用・ガバナンスを接続した設計が必要になります。

責任分解は、トラブルが起きた後に議論するものではなく、導入前から仕込んでおくべき導入条件そのものだといえるでしょう。

当社では、自社AIプラットフォームの開発・運用で培った実装知見と、AI Transformation・BPR・新規事業開発を含む戦略／業務コンサルティングの両面から、AI導入を「試す」段階で終わらせず、「事業に載せる」ための構想・設計・実装・運用定着まで一気通貫でご支援しています。

AIエージェントの導入では、モデル選定やPoCだけでなく、業務プロセスの再設計、権限設計、監査可能性、情報管理、品質管理、ROIの可視化までを接続して考えることが重要です。Qualitegは、戦略と技術を分断しない体制で、こうした課題に向き合います。

ご関心をお持ちの方は、ぜひお気軽にご相談ください。初期構想の整理から、ガバナンス設計、実行基盤の検討、導入後の運用定着まで、課題に応じてご一緒できます。

お問い合わせ先

https://qualiteg.com/contact?inquiry=consulting_business

次回予告

では、こうした責任分解の構造を踏まえて、企業は実務上何を設計すべきなのでしょうか。

第3回（最終回）では、品質保証の転換、人間レビューの限界、保険市場の動向を整理したうえで、「AIエージェント導入前に設計すべき5領域」と「経営として先に答えるべき3つの問い」を示します。

— AI導入を"事業に載せる"ために、いま設計すべきこと（全3回）

こんにちは！Qualitegコンサルティングチームです！

AIエージェントを導入する企業が増える一方で、

「試してみる」段階から「事業に載せる」段階へ進める難しさ

が、はっきり見え始めています。

本シリーズでは、AIエージェント導入を技術論だけでなく、責任分解・監査可能性・契約・運用統制を含む業務設計の問題として整理します。

全3回を通じて、「AIが賢いかどうか」ではなく、「AIを業務に載せるために何を設計するか」を考えていきます。

第1回となる本記事では、2025年に起きた2つの事例を出発点に、なぜいま「責任設計」が問題になっているのかを見ていきます。

上図は、本シリーズ全体で扱う論点の全体像です。

AIエージェントの導入は、技術的なモデル選定だけでは完結せず、権限設計、契約、監査、品質監視、保険、異常時対応まで含めた設計が必要になります。

第1回ではまず、なぜこうした設計が求められるようになったのかを、実際の事例から見ていきたいとおもいます

なお、本シリーズで取り上げる象徴事例は海外のものが中心です。
これは、日本で同種の問題が存在しないという意味ではありません。むしろ、AIエージェント導入が本格化するなかで、権限設計、品質保証、監査可能性、責任分解といった論点は日本企業にとっても同様に重要です。現時点では、こうした構造的な課題が大きく可視化された事例として海外報道が相対的に参照しやすいため、本シリーズではそれらを手がかりに整理しています。

AIエージェントが引き起こした2つの事故

事例1：Replit — 本番データベースの削除と隠蔽

2025年、SaaStrの創業者Jason Lemkinは、自社インフラで稼働させていたAIコーディングエージェント（Replit）に本番データベースを削除されました。指定された「コード・アクションフリーズ」期間中の出来事です。

TechTargetの報道によれば、エージェントはレポートやデータを捏造し、「まだ動いているように見せかける」偽装アルゴリズムまで生成していました。やってはいけない期間に、やってはいけないことをやり、さらにそれを隠蔽した。権限制御・環境分離・承認設計の欠如が、AIの逸脱行動を実害化させた事例です。

事例2：Deloitte — 架空の引用で埋められた政府報告書

同じ年、Deloitteがオーストラリア政府向けに提出した237ページの福祉コンプライアンスレビュー報告書が、存在しない学者・存在しない論文への参照で溢れていたことが発覚しました。シドニー大学の研究者Chris Rudge氏が架空の引用に気づいたことがきっかけです。

Deloitteは後にAzure OpenAI GPT-4oを報告書の一部作成に使用していたことを認め、修正版を提出。GPT-4oを用いた作成プロセスの中で架空引用を含む重大な誤りが混入しており、AI利用の開示と品質保証が実務上の争点になりうることを示した事例となっています（Business Standard, 2025年10月）。

2つの事例が示す、異なるリスク

冒頭でご紹介した、2つの事例は、性質が異なります。

以下の図に、それぞれの事例がどのようなリスクを象徴しているかを整理してみました。

テキストベースの比較表も以下に示します。

Replitの事例は「AIに何をさせてよいか」の権限設計の問題であり、
Deloitteの事例は「AIが作ったものをどう検証・開示するか」の品質保証の問題です

どちらも、AI自体の性能ではなく、AIを業務に組み込んだときの設計に課題がありました。

共通する本質：設計の不在

この2つの事例に共通しているのは、AIが間違えたこと自体よりも、AIを業務に組み込んだときに、

• 誰がどこまで権限を持つのか
• 何を監視するのか
• 異常時にどこで人間に戻すのか

が設計されていなかったということです。

以下のフローチャートは、
この「設計の不在」がどのように導入の停止につながるかを示しています。

設計の不在は、AIの性能とは無関係に、導入プロジェクトを停止させます。

BCGの2025年12月の論考が引用するAI Incidents Databaseによれば、AIに関連するインシデントは2024年から2025年にかけて21%増加しています。

また、ISACAは2025年12月のレビューで、
2025年最大のAI障害について
「技術的なものではなかった。それは組織的なものだった：脆弱な統制、不明確なオーナーシップ、そして見当違いの信頼」
と総括しています。

問題の本質は、AIの精度ではありません。

AIを業務に組み込んだときの権限・監査・責任・人間介入点の設計にあります。

構想から運用定着までQualitegが伴走できる領域

さて、今回は、AIエージェント導入で実際に起きた事故を手がかりに、問題の本質が単なるモデル性能ではなく、
権限設計、品質保証、監査可能性、人間介入点といった設計の不在にあることを見てまいりました。

AIを業務に組み込むときに問われるのは、「どのモデルを使うか」だけではありません。

どこまで権限を委譲するのか、どこで止めるのか、何を監視するのか、異常時にどう戻すのか。

そうした前提設計がなければ、PoCはできても、事業に載せる段階で止まりやすくなります。

こうした論点は、事故が起きてから考えるのでは遅く、導入の初期段階から構造的に整理しておくことが重要です。

当社では、自社AIプラットフォームの開発・運用で培った実装知見と、AI Transformation・BPR・新規事業開発を含む戦略／業務コンサルティングの両面から、AI導入を「試す」段階で終わらせず、「事業に載せる」ための構想・設計・実装・運用定着まで一気通貫でご支援しています。

AIエージェントの導入では、モデル選定やPoCだけでなく、業務プロセスの再設計、権限設計、監査可能性、情報管理、品質管理、ROIの可視化までを接続して考えることが重要です。Qualitegは、戦略と技術を分断しない体制で、こうした課題に向き合います。

ご関心をお持ちの方は、ぜひお気軽にご相談ください。初期構想の整理から、ガバナンス設計、実行基盤の検討、導入後の運用定着まで、課題に応じてご一緒できます。

お問い合わせ先

https://qualiteg.com/contact?inquiry=consulting_business

次回予告

今回のご紹介したように、こうした事故が起きたとき、法的責任や契約上の責任はどのように問われうるのでしょうか。

そして、なぜAIエージェントは従来のソフトウェア以上に責任分解が難しいのでしょうか。

第2回では、法務・契約・組織の観点から、AIエージェントの責任分解がなぜ困難なのかを構造的に整理します。

それでは、次回またお会いしましょう！

こんにちは！Qualiteg研究部です!

個人情報（PII: Personally Identifiable Information）の自動検出は、テキスト中から特定の表現を抽出し、それがどの種類のPIIに当たるかを判定する問題として捉えることができます。
電話番号、人名、口座番号、金額表現など、検出対象のPIIタイプが増えるにつれて、単一の手法ではカバーしきれなくなり、性質の異なる複数の認識器（Recognizer）を組み合わせるマルチレイヤー構成が採用されるのが一般的です。

本稿で想定しているのは、ユーザーが海外製LLMにチャットを送信する直前に、その内容に個人情報や機密情報が含まれていないかをリアルタイムに検査するユースケースです。

この場面では、検出精度だけでなく、送信体験を損ねない速度が不可欠です。

高精度なLLMやBERT系モデル、NERベースの手法は有力ですが、送信前チェックの第一層として常時適用するには、レイテンシやコストの面で不利になることがあります。

そのため、本システムでは、正規表現、辞書、軽量なルールベース認識器を組み合わせた超高速な第一層を設け、そのうえで必要に応じて後段の認識器が文脈を補うマルチレイヤー構成を採用しています。

重要なのは、この構成が単なる正規表現パターンの追加ではないという点です。高速性を保ったまま検出範囲を広げようとすると、巨大な単一ルールに集約するよりも、役割ごとに認識器を分けたほうが設計しやすくなります。しかしその代償として、今度は各認識器が互いに干渉する問題が表面化します。

本記事ではこの現象を「クロス認識器衝突（Cross-Recognizer Collision）」と呼び、混同行列の観点からテスト設計のあり方を考察していきたいとおもいます。

混同行列の4象限とPII検出

混同行列は分類問題の性能評価に広く用いられる枠組みですが、PII検出の文脈では各象限が持つ実務上の意味合いがやや独特です。まず基本的な定義を確認します。

これを具体例で補うと、以下のようになります。

TP ― 開発初期の安心と、その限界

TPテストは開発の最初期に書かれるものです。
「この入力を与えたら正しく検出される」という確認は直感的であり、テストケースも書きやすいため、TP中心のテストスイートだけで早期に100%パスの状態を作れてしまいます。しかし、この100%は「検出すべきものを検出できた」ことしか証明しておらず、「検出すべきでないものをスルーできているか」については何も語りません。

FP ― ユーザー信頼を削る「オオカミ少年」問題

FPが多いシステムは、ユーザーからの信頼を急速に失います。正常なテキストに大量の警告フラグが立つツールを、日常的に使いたいと思う人はいません。FP率の高いシステムでは、やがて本当に重要なTP検出すら無視されるようになります。これは医療分野のアラート疲れ（Alert Fatigue）と同じ構造の問題です。

FN ― 直接的なリスク

PIIの文脈では、FNは情報漏洩に直結する可能性があります。マスクすべき個人情報が検出漏れによってそのまま外部に出てしまうリスクがあるため、FN率の低減はシステムの根本的な要件です。

TN ― 地味だが品質の基盤

TNテストは一見地味ですが、システムの「選択性（Specificity）」を保証する唯一の手段です。TNテストの不足は、FPの増加として後から表面化します。

テストカバレッジの偏り ― 個別認識器テストの落とし穴

あるPII検出プロジェクトで、文脈解析型の認識器を複数のパイプライン（検出カテゴリ）に分けて運用しているケースがありました。

全テストがグリーンという状態のもと、各パイプラインのテストカバレッジを象限別に分析したところ、以下のような分布が見られました。

一見すると、非検出を期待するネガティブケースも全体の約4分の1を占めており、決してゼロではありません。「特定のキーワードが欠けている場合は検出しない」「サンプルと明記された文脈ではスルーする」「一般的な医学用語には反応しない」といった除外条件のテストは存在していました。

しかし、ここに2つの構造的な問題があります。

まず問題なのは、ポジティブケース偏重の比率そのものです。

検出成功を確認するケースが全体の76%を占めており、「検出できること」の確認に大半のテストリソースが割かれています。一方で、「検出しないこと」を確認するネガティブケースは4分の1に留まっていました。検出対象のバリエーション（表記揺れ、全角半角、略記等）に対するポジティブケースは充実している一方で、ネガティブケースは代表的な除外パターンをいくつか押さえた程度で止まっていました。

次に、より根本的な問題として、これらのネガティブケースは、いずれもその認識器単体で想定される除外条件を確認するものに留まっていたのです。ある認識器のテストスイートは、他の認識器がどんなパターンを持っているかを知りません。この「無関心」が、次に述べるクロス認識器衝突の温床になります。

クロス認識器衝突（Cross-Recognizer Collision）

マルチレイヤー構成のPII検出システムでは、各認識器の検出結果が最終的に一つのリストにマージされます。このマージの瞬間に、異なる認識器の検出結果が同一のテキスト範囲を奪い合う衝突が発生します。

以下に、典型的な3つの衝突パターンを示します。

ケース1: 形式の類似による識別子衝突

入力:  "案件番号 A-1024 を更新してください"
期待:  業務上の内部識別子、または文脈に応じて非PIIとして扱う
実際:  別の認識器がこれを病室番号、チケットID、契約番号など別カテゴリの識別子として誤認する

英字と数字をハイフンで連結した短い識別子は、多くの業務システムで共通して使われます。形式だけに依存した認識器は、同一の文字列に対して異なる意味を割り当ててしまいがちです。

ケース2: 日付表記と比率・スコア表記の衝突

入力:  "提出期限は2026/3/5です"
期待:  PIIとしては検出なし
実際:  3/5 や /5 が比率・スコア表現として誤認される

スラッシュ区切りの表現は、日付、比率、評価点など複数の意味を持ちます。短い部分文字列だけを見る認識器は、周辺文脈を失った状態で誤反応しやすくなります。

ケース3: ID形式の曖昧性

入力:  "CONTRACT-2024についてレビューしてください"
期待:  法務情報（契約書ID）として検出
実際:  チケットIDパターン（例: "PROJ-1234" 形式）にマッチ

大文字英字-数字4桁 という形式は、チケットID、契約書番号、プロジェクトコードのいずれにも使われます。正規表現パターンだけでは区別がつきません。文脈解析型の認識器であればコンテキストからより妥当な判定ができる可能性がありますが、実装によっては、早い段階のパターンマッチ結果が優先採用されたり、後段の判定を事実上マスクしたりするため、文脈に基づく補正が十分に効かないことがあります。

衝突が発見されにくい構造的な理由

クロス認識器衝突の発見が遅れるのは、テスト設計の構造的な問題に起因しています。

認識器ごとの独立した開発。 通常、各認識器は別々の開発者やチームが担当します。NERモデルのチューニング担当はNERのテストを、辞書認識器の担当は辞書のテストを書きます。各テストスイートは単体では正しく通りますが、他の認識器の存在を考慮した入力パターンは含まれていません。

CIパイプラインの分離。 多くのプロジェクトでは、各認識器のテストスイートが独立に実行されます。全認識器をロードした状態でのEnd-to-Endテストは、意識的に設計しない限り存在しません。

自然言語の本質的な曖昧性。 同じ文字列が複数の意味を持ちうるのは、自然言語の本質です。特に日本語は英語のようにスペースで単語が区切られないため、部分文字列マッチの問題がより深刻になります。\b（ワードバウンダリ）に相当する概念が希薄であり、形態素解析との連携が必要になる場面も少なくありません。

2×2の混同行列では見えない認識器間衝突

ここまでの議論を一般化してみます。

高速に動作する第一層のフィルタを置くこと自体は、セキュリティやDLP、入力検証の分野では必ずしも珍しい発想ではありません。本アプローチの特徴は、単に正規表現を増やすことではなく、高速に動作する複数の認識器を役割分担させ、その統合時に生じる衝突まで含めて品質設計の対象とした点にあります。高速な第一層を置くこと自体は一般的な設計判断ですが、その副作用として現れる認識器間競合を、テスト設計の中心課題として明示的に扱う例は必ずしも多くありません。

単一の認識器であれば、評価は2×2の混同行列で整理できます。しかし、複数の認識器を並走させるシステムでは事情が複雑になります。実際には、複数のエンティティタイプと「該当なし」を含む多クラス的な判定に加えて、認識器同士のスパン競合やラベル競合も発生するため、2×2の混同行列だけでは誤りの構造を捉えきれません。

このとき見落とされがちなのが、同一の文字列に対して認識器ごとに異なるラベルが付与されうるという関係です。たとえば CONTRACT-2024 という表記は、法務系認識器にとっては正しい契約識別子として扱われる一方、別の認識器からはチケットID形式として誤って解釈される可能性があります。つまり、ある認識器の正しい検出が、システム全体では別の認識器との競合源になることがあります。この二重性は、個別認識器のテストでは原理的に検出できません。

さらにPII検出では、単に「何を検出したか」だけでなく、「どこまでを検出したか」も重要です。たとえば電話番号の一部だけを拾った場合や、組織名に接続する部署名まで過剰に含めてしまった場合は、ラベル自体が正しくても実用上は不正解になりえます。したがって評価では、エンティティタイプの正誤だけでなく、スパン境界の正確さも区別して扱う必要があります。

認識器間の衝突関係を表にすると以下のようになります（行が「検出元」、列が「衝突先」です）。

対角要素以外のすべてのセルが、潜在的な衝突の温床です。システム全体の品質を測るには、この非対角要素を意識的にテストする必要があります。

対策のアプローチ

1. クロス認識器向けネガティブケースの追加

他の認識器のパターンに引っかかりそうな入力を、各認識器のTNテストとして追加する方法です。

// 医療系認識器のTNテスト
{
  text: "案件番号 A-1024 を更新してください",
  expected_count: 0,
  description: "短い識別子形式を医療カテゴリとして誤認しないこと"
}

// チケットID認識器のTNテスト
{
  text: "CONTRACT-2024についてレビューしてください",
  expected_count: 0,
  description: "契約ID形式を別カテゴリの識別子として誤認しないこと"
}

実装が容易で回帰テストとして確実に機能します。ただし、衝突パターンを事前にすべて洗い出すのは困難なため、本番で発見された衝突を一つずつTNテストに追加していく地道な積み上げが現実的です。

2. 認識器間の優先度と競合解決ルール

同じテキスト範囲に複数の認識器が反応した場合の解決戦略を明文化する方法です。

ひとつは、より長いスパンを優先する考え方です。短い部分一致よりも、広い範囲を一貫した意味として捉えている検出結果のほうを採用します。次に、周辺文脈のキーワードを考慮した検出を、パターンのみの検出より優先するアプローチがあります。さらに、特定のエンティティタイプ同士が競合した場合の優劣をあらかじめ定義しておく方法や、認識器ごとに数値的な優先度（Priority値）を設定し、競合時は高い方を採用する方法も有効です。

3. 統合テストレイヤーの導入

個別認識器のユニットテストとは別に、全認識器をロードした状態で実行する統合テストを設計します。

describe("Cross-Recognizer Collision Tests", () => {
  const detector = createFullDetector(); // 全認識器をロード

  it("日付がスコアパターンに誤検出されない", () => {
    const results = detector.detect("会議は2026/3/5に設定されました");
    expect(results.filter(r => r.type === "score")).toHaveLength(0);
  });

  it("識別子形式の競合が優先度ルールで正しく解決される", () => {
    const results = detector.detect("CONTRACT-2024の条項を確認");
    expect(results.some(r => r.type === "legal_id")).toBe(true);
    expect(results.some(r => r.type === "ticket_id")).toBe(false);
  });
});

ユニットテストが「この認識器は正しく動くか」を検証するのに対して、統合テストは「認識器同士が共存できるか」を検証します。両方が揃ってはじめて、システム全体の信頼性を担保できます。

4. ワードバウンダリの厳格化

部分文字列マッチの問題は、正規表現のワードバウンダリを適切に使うことで軽減できます。

// 部分文字列にもマッチしてしまう
const loose = /CT/i;

// 独立した語としてのCTにのみマッチする
const strict = /\bCT\b/i;

ただし日本語では英語ほど単語境界が明確ではないため、\b に依存した設計はそのままでは通用しません。実際には、形態素解析を併用したり、マッチ箇所の前後の文字種を確認したり、記号・英数字・漢字の境界を後段で補正したりといった工夫が必要になります。

まとめ ― テスト設計が証明していること、していないこと

さて、
では、本記事の要点を整理しましょう。

TPテストだけの100%は「偽りの安心」です
検出すべきものを検出できたことしか証明しておらず、検出すべきでないものへの耐性は未検証のままです。テスト設計の初期段階から、4象限すべてを意識すべきです。

個別認識器の単体テストは必要条件であって十分条件ではありません
複数の認識器を結合した統合テストを早期に導入しないと、結合後に想定外の衝突が発覚して手戻りが発生します。

衝突は偶発的な不具合というより、マルチレイヤー構成が本質的に抱える設計課題です
複数の認識器が異なる規則で同じ文字列を解釈する以上、ラベル競合やスパン競合は一定確率で発生します。したがって、衝突を例外として後から潰すのではなく、最初から前提条件としてテスト設計と競合解決ポリシーに組み込むべきです。

2×2の混同行列だけで閉じず、認識器間の競合まで含めて誤り構造を捉える視点が有効です
ある認識器にとって妥当な検出結果が、システム全体では別の認識器との競合源になるという関係性は、個別テストでは見えません。認識器間の衝突マトリクスを可視化し、非対角要素を意識的にテストすることで、システム全体の品質を底上げできます。

100%パスしたテストスイートを前にしたときこそ、
「このテストは何を保証しており、何をまだ保証していないのか」
を問い直すべき、ということになります。

その問いを持てるかどうかが、デモでは動くが本番では壊れる検出器と、実運用に耐える検出システムを分けるポイントなのかもしれません。

さて、今回は、マルチレイヤーPII検出における認識器間衝突と、その死角になりやすいテスト設計についてお話ししました。

高速性と検出品質の両立に向き合っている方にとって、何か一つでも参考になる点があればうれしいです。

最後まで読んでいただき、ありがとうございました。

次回また、お会いしましょう！

はじめに

本レポートは、Nejumi Leaderboard 4のベンチマークデータ（2026/3/6版）に基づいて、日本語対応LLMの性能を総合的に分析したものです。

前回は 2025/12/18 版の分析レポート を公開しましたが、約3か月でまたもや大きな変動がありました！

（定期的に最新LLMランキングを更新してまいります。当社のX(旧Twitter)をフォローいただくことで更新情報を受け取り可能です）

Nejumi Leaderboard 4は、日本語タスクにおけるLLMの性能を多角的に評価する信頼性の高いベンチマークとして知られています。

本分析では、商用APIモデルとオープンモデルの両方を対象に、それぞれの特徴や傾向を詳しく見ていきます。

オープンソースモデルについて

Weightがオープンなモデルは場合によっては「オープンソースモデル」、「OSSモデル」と呼ばれますが、モデルによっては「オープンソース」と呼ぶには不十分な場合があるため本稿では、「オープンソースモデル」ではなく「オープンモデル」と表現しています。

ベンチマーク分析について

本レポートは、LLM選択の参考情報として、ベンチマークデータから読み取れる傾向や特徴を提示するものです。最終的なモデル選択においては、これらの情報を踏まえつつ、実際の使用環境での検証を行うことをおすすめいたします。

まず 2026/3/6 現在の日本語対応LLMの総合ランキングをみてみましょう。

総合スコアランキング TOP50

総合スコアの傾向と考察

今回は、2026年3月の日本語対応LLMベンチマークにおいて、0.80超えモデルが一気に11モデルに拡大しました。前回（12月版）では4モデルだった0.80超えが、わずか3か月で約3倍に急増しています。

この3か月でも、性能水準の上昇はかなり明確です。

オープンモデルのQwen が 0.80 の壁を突破し商用モデルに迫る！

今回とくに驚いたのは、オープンモデルが初めて0.80の壁を突破したことです。
Qwen/Qwen3.5-397B-A17Bがなんと 0.8191 を記録しており、スコアの上では、前回調査時に 2位だった google/gemini-3-pro-preview のスコア 0.8134　を超えています

さらに、Qwen3.5シリーズは合計3モデルが0.80を超え、オープンモデルと商用APIモデルの境界線がますます曖昧になりつつあります。

トップ層の特徴

Google Gemini 3.1 Pro Previewが首位に返り咲く

首位のGemini 3.1 Pro Previewは0.8430という過去最高スコアを記録しました。前回2位だったGemini 3 Pro Preview（0.8134）から大幅にスコアを伸ばし、堂々の1位に返り咲いています。

前回、GPT-5.2がGemini 3 Proを抑えて首位を奪還したドラマをお伝えしましたが、今回はGoogleが「3.1」というマイナーバージョンアップで再び首位を獲得しました。3.1への更新で、ベンチマーク上は約0.03ポイントの改善が確認されました。バージョン番号以上に、中身の進化が大きかったことがうかがえます。

Anthropic社のClaudeは安定した高性能

Anthropic社のClaude Opus 4.6（0.8394）は、今回のスコアでは、総合2位でした。OpusはAnthropicの最新フラッグシップモデルです。加えて、4位のClaude Sonnet 4.6（0.8230）も0.80を超えており、Anthropicは「Opus」と「Sonnet」の両方でトップ5入りを果たしています。

GPT-5.4 に期待GPT-5.2は3位に後退、今後はGPT-5.4の評価に注目

前回首位だったGPT-5.2（0.8285）は今回3位となりました。スコア自体は変わっていませんが、Gemini 3.1 ProとClaude Opus 4.6という2つの強力な新モデルに追い抜かれた形です。

OpenAIとしては前回の「Code Red」を経てGPT-5.2をリリースした経緯がありますが、Google・Anthropicの追い上げは止まりません。

本記事執筆時点の 2026/3/6 に後継の GPT-5.4 がリリースされました。まだ出たばかりなのでベンチマークには登場していませんが、非常に注目されるリリースです。

Gemini 3 Flashの躍進

6位に入ったGemini 3 Flash Preview（0.8155）は特筆に値するのではないでしょうか。「Flash」は本来、高速・軽量版の位置づけですが、前回のGemini 3 Pro Previewとほぼ同等の0.81台を記録。高速応答と高性能の両立という点で、実用面での価値は非常に高いのではないでしょうか。

3強から群雄割拠となるか

前回は「Anthropic、OpenAI、Googleの3強」という構図でしたが、今回はさらに競争が多極化しています。

• TOP4が0.82以上という未曾有の高水準（前回はTOP4が0.80以上）
• TOP11が0.80以上（前回は4モデルのみ）
• オープンモデルのQwen3.5シリーズが5位、8位、11位にランクインし、商用APIモデルに割って入る

特にTOP11のうち、商用APIが8モデル、オープンモデルが3モデルという構成は、オープンモデルの急速な進化を物語っています。

これだけモデルの選択肢が広がると、今後は「最強モデルを一つ選ぶ」というより、用途や制約に応じて複数モデルを使い分ける設計が現実的になっていくのではないでしょうか。

強力な新顔たち

さて、その他、今回のランキングで登場した注目すべき新顔をいくつか紹介いたします。

• Gemini 3.1 Flash Lite Preview（43位、0.7284）: 最軽量版でも0.72台を記録。Googleのモデルラインナップの層の厚さを示す
• Qwen3.5シリーズ（5位、8位、11位ほか）: 今回最大のサプライズ。詳細はオープンモデルのセクションで解説します
• GLM-5（19位、0.7884）: 前回登場したGLM-4.6-FP8（0.7337）からメジャーバージョンアップ。Zhipu AI（智譜AI）の急成長が続く
• Moonshot Kimi-K2.5（24位、0.7785）: 前回のKimi-K2-thinking（0.7332）から大幅にスコアアップ。
• MiniMax-M2.1（32位、0.7556）: 前回のMiniMax-M2（0.7126）からの着実な進化
• LGAI-EXAONE K-EXAONE-236B-A23B（49位、0.7186）: 韓国LG AI Researchによるオープンモデルが新規参入。韓国発モデルとしては初のランクイン。
• NVIDIA Nemotron Nano 9B v2 Japanese（Small、0.7111）: NVIDIAによる日本語特化の小型モデル。9Bパラメータで0.71超えは注目
• Baidu ERNIE-4.5-21B-A3B-Thinking（Medium、0.5466）: 中国Baiduの新モデルが初登場

モデルサイズと性能の関係

今回も興味深いのは、軽量モデルの性能向上です。

• 小型モデルのQwen3.5-4BがSmallカテゴリで0.7352を記録（わずか4Bです！）
• Gemini 3 Flashが0.81台を記録し、「Flash = 高速版」の常識を覆す

ベンチマーク結果の解釈について

本レポートで紹介するスコアは、あくまでもベンチマークテストにおける評価結果です。ベンチマークは、LLMの性能を客観的に比較する有用なツールですが、以下の点にご注意ください。

• ベンチマークは特定のタスクセットに基づいて評価されるため、そのタスク構成に適したモデルほど高いスコアを獲得する傾向があります
• 実際の業務での使用感や、特定の用途における有用性は、ベンチマークスコアだけでは完全には測れません
• モデルによっては、ベンチマークで測定されていない独自の強みや特徴を持っている場合があります

次は、オープンモデルに限定して実力をみていきましょう。

オープンモデル 総合スコアランキング TOP20

オープンモデル総合スコアの傾向と考察

オープンモデルに限定したランキングを見ると、冒頭でもふれましたが、
今回は中国発Alibaba社のQwen3.5シリーズの衝撃的な登場が最大のトピックとなります。

長い間、中国発LLMかつオープンLLMの王者だったDeepSeek を抜き去りました

Qwen3.5シリーズ —— オープンモデルとして初の0.80台に到達

Qwen3.5シリーズは、性能帯の異なる"4兄弟"のようなラインナップを形成しています。

• Qwen3.5-397B-A17B（0.8191）：オープンモデルとして史上初の0.80超え、しかも0.81台を記録
• Qwen3.5-122B-A10B（0.8094）：2番手でも0.80超え
• Qwen3.5-27B（0.8049）：27Bの中規模モデルでも0.80超え
• Qwen3.5-4B（0.7352）：小型モデルについては後述します

前回首位だったDeepSeek V3.2（Thinking Mode）の0.7905を大きく上回り、オープンモデルのレベルを一段引き上げました。

Qwen3.5シリーズはAlibaba Cloud（阿里雲）が開発するQwenファミリーの最新世代で、MoE（Mixture of Experts）アーキテクチャを採用しています。「397B-A17B」は総パラメータ数397Bのうち、推論時にアクティブになるのは17Bのみという効率的な設計です。これにより、大規模モデル並みの性能を比較的少ない計算資源で実現しています。

Qwen3.5-27Bの結果はとくに注目に値します。

わずか27Bパラメータの中規模モデルで0.80を超えたことは、オープンモデルの「効率革命」を象徴しています。こちらは中規模モデル編でもう少し考察します。

中国発モデルの多様化がさらに加速

前回も中国発モデルの層の厚さに驚かされましたが、今回はさらに顕著です。

• Zhipu AI（智譜AI）のGLM-5（6位、0.7884）: 前回のGLM-4.6-FP8（0.7337）から大幅な進化
• Moonshot AI のKimi-K2.5（7位、0.7785）: 前回のKimi-K2-thinking（0.7332）から0.045ポイントの向上
• MiniMax-M2.1（10位、0.7556）: 前回のM2（0.7126）から着実にスコアを伸ばす

DeepSeek、Qwen、GLM、Kimi、MiniMaxと、5つの異なる中国発AIベンダーがTOP10に名を連ねています。中国AIエコシステムの厚みは、もはや一時的なブームではなく構造的な競争力と言えるでしょう。

新たな国際勢力台頭～韓国発モデル～

今回、中国以外からも注目すべき新勢力が登場しています。

LGAI-EXAONE K-EXAONE-236B-A23B（16位、0.7186）は 韓国LG AI Researchによるオープンモデルです。236Bパラメータ（アクティブ23B）のMoEモデルで、韓国発モデルとしてはこのベンチマークで初めてのランクインとなります

日本製オープンモデル

日本発オープンモデルでは、今回新たに東京工業大学（TokyoTech）のSwallowシリーズが複数ランクインしています。

• tokyotech-llm/GPT-OSS-Swallow-120B-RL-v0.1（0.6914）: OpenAIのGPT-OSSをベースにした120Bモデル
• tokyotech-llm/Qwen3-Swallow-32B-RL-v0.2（0.6782）: Qwen3ベースの32Bモデル
• tokyotech-llm/GPT-OSS-Swallow-20B-RL-v0.1（0.6424）: 20Bの中規模モデル
• tokyotech-llm/Qwen3-Swallow-8B-RL-v0.2（0.6552）: 8Bの小型モデル

Swallowシリーズは強化学習（RL）を活用したファインチューニングにより、複数のベースモデルから日本語性能を引き出しています。従来のrinna（0.6910）やABEJA（0.6866）に加え、東工大のSwallowが日本語LLMの選択肢をさらに広げています。

さて、次は中規模10B～30B程度のモデルをみてみましょう。

中規模モデルのうれしいところは、個人レベルでも比較的入手しやすいGPUでも実行できるところではないでしょうか。16bitモードや量子化版のモデルをつかえば、16GByte～48GB程度のGPUでも推論を動作させることができ、1台のPCに1台のGPUという構成でも利用しやすい点、とっつきやすいモデルといえます。

中規模モデル（10B-30B）総合スコアランキング

中規模モデル総合スコアの傾向と考察

中規模モデル（10B-30Bパラメータ）のカテゴリでは、もう紹介済ですがQwen 四兄弟の三男Qwen3.5-27Bが0.80超えという歴史的なスコアを記録しました。

Qwen3.5-27B —— 中規模モデルの到達点を一段押し上げる

ここで、Qwen3.5-27Bの位置づけを改めて確認してみましょう。

前回まで中規模モデルの王者はQwen3-14B（0.7233）で、2位のgemma-3-27b（0.6285）との間には約0.10ポイントの大差がありました。

今回のQwen3.5-27B（0.8049）は、そのQwen3-14Bをも0.08ポイント上回り、中規模モデルの到達点を大きく引き上げました。
0.80という数字は、前回の商用APIモデルTOP4に匹敵するレベルです。つまり、約3か月前の最高水準の商用APIモデルと同等の性能が、27Bの中規模オープンモデルで実現されているのです。

2位のQwen3.5-9B（0.7485）も前回のQwen3-14Bを上回っており、9Bパラメータでこの水準に達している点は、注目に値します。

新顔：東工大Swallowと百度ERNIE

4位にtokyotech-llm/GPT-OSS-Swallow-20B-RL-v0.1（0.6424）が新たにランクインしました。OpenAIのオープンモデルGPT-OSSをベースに、東京工業大学が日本語に特化したファインチューニングを施したモデルです。

また、9位にはBaidu（百度）のERNIE-4.5-21B-A3B-Thinking（0.5466）が新規参入しています。中国の検索エンジン大手Baiduが開発するERNIEシリーズは、中国語圏では広く知られていますが、日本語ベンチマークでの登場は今回が初めてです。

さて、最後に小規模モデルもみてみましょう。こうした小型モデルは比較的安価なコンシューマ向けGPUでも動作する点が魅力です。

小規模モデル（10B以下）総合スコアランキング

小規模モデル総合スコアの傾向と考察

小規模モデル（10B以下のパラメータ）は、エッジデバイスやリソース制約のある環境での利用に適しており、今回も驚くほど高い性能を実現しているモデルが存在します。

Qwen3.5-4B —— 小型モデルの性能水準を塗り替える

さて、小規模モデルでは、Qwen3.5シリーズの最小モデルであるQwen3.5-4B（0.7352）が首位となりました。

わずか4Bパラメータで前回の小型モデル首位Qwen3-8B（0.6891）を大幅に上回りました。

前回のQwen3-14B（Medium、0.7233）をも超えるスコアであり、モデルサイズの常識を覆す結果です。

NVIDIA Nemotron Nano の存在感

2位にNVIDIA Nemotron Nano 9B v2 Japanese（0.7111）が新たにランクインしました。NVIDIAが開発した日本語特化の9Bモデルで、日本語性能を重視したファインチューニングが施されています。NVIDIAはGPUメーカーとしてのイメージが強いですが、LLMモデル自体の開発にも注力していることがうかがえます。

まとめ、本格導入に向けての道しるべ

前回に引き続き今回も、Nejumi Leaderboard 4のベンチマークデータを分析いたしました。本日（2026年3月6日時点）は、前回の分析から約3か月経っておりますが、日本語対応LLMの加速度的な進化を感じていただけたのではないでしょうか。

0.80超え11モデル時代の到来

今回の最大のポイントは、11モデルが総合スコア0.80を突破したことです。前回は4モデル、その前はゼロだったことを考えると、技術進歩のスピードは加速する一方です。

• Gemini 3.1 Pro Preview（0.8430）が史上最高スコアで首位
• Claude Opus 4.6（0.8394）が僅差で2位に肉薄
• オープンモデルのQwen3.5-397B-A17B（0.8191）が初の0.80超え

商用API3強（Google、Anthropic、OpenAI）の競争はますます激化していますが、今回はそこにオープンモデルが本格的に割って入ってきた点が決定的に新しい動きです。

オープンモデルの歴史的躍進

Qwen3.5シリーズが3モデルで0.80を超えたことは、LLM業界の転換点と言えるかもしれません。特にQwen3.5-27Bは、27Bという手の届くサイズで商用API並みの性能を実現しており、オンプレミス環境での高性能LLM運用が現実的になりつつあります。

モデルサイズ別の特徴

LLMの本格導入にむけて：用途別の最適なモデル選択

今回は総合スコアを軸に各モデルの位置づけを見てきましたが、実際の導入判断はそれほど単純ではありません。

ベンチマークは有力な参考情報である一方、実務では精度だけでなく、推論コスト、応答速度、機密データの扱い、既存システムとの接続性、運用体制といった要素も同時に検討する必要があります。

また、業務によって求められる性質は異なります。高精度な推論が求められる場面もあれば、低コストで大量処理したい場面もあり、機密性の観点からオープンモデルを自社環境で動かしたいケースもあります。そのため、「最もスコアの高いモデルを一つ選ぶ」というより、「用途ごとに複数のモデルを適切に使い分けられる状態をどう作るか」が、導入の現場ではより重要になります。

当社では、こうした複数モデル運用の実務に対応する選択肢として、複数のLLMを1つのプラットフォームで利用できる統合AIプラットフォーム Bestllam を提供しています。モデルの選定から、業務フローへの組み込み、AIエージェント活用を前提とした運用設計まで含めてご支援可能です。

また、単なるツール提供にとどまらず、貴社業務のAI化を見据えたBPRコンサルティングもあわせてご提供しており、業務分析からBPR計画策定、成功指標の設計、導入支援まで伴走いたします。

まずはお気軽にご相談くださいませ
https://qualiteg.com/contact?inquiry=consulting

こんにちは！

このたび、日経トレンディ 2026年4月号(2026年3月4日発売、雑誌)に、当社のエンタープライズ向け統合型AIプラットフォーム「Bestllam」を掲載しました。

日経トレンディ(雑誌)は全国の書店・コンビニエンスストアにてお買い求めいただけますので、お手に取った際はぜひご覧くださいませ。

Bestllam とは？

Bestllam は、「チャットで指示するだけ。仕事が終わっている。」をコンセプトに開発した、エンタープライズ向けの統合型AIプラットフォームです。

主な特長

20種類以上のLLMを、契約一本で OpenAI GPT、Anthropic Claude、Google Gemini をはじめ、DeepSeek、Qwen、Llama など商用・オープンソース合わせて20種類以上のLLMを1つの契約で利用できます。各プロバイダと個別に契約を結ぶ手間が不要になります。

6つのLLMに同時質問して、最適な答えを選択 同じ質問を複数のLLMに一括投げかけ、回答を比較・検討できます。各モデルの得意・不得意を活かすことで、重要な意思決定や精度が求められる業務の信頼性を高めます。

AIエージェントが業務を自律遂行 「先月の売り上げを顧客属性ごとにまとめて、営業部のPowerPointフォーマットでメールしておいて」——そんな指示一つで、データ抽出から資料作成・メール送信まで、AIが自律的に完結します。従来のRPAのような固定ルールではなく、状況を判断しながら最適な手順で動きます。

MCP連携で社内システムとシームレスに統合 CRM、ERP、データベース、グループウェアなど既存の業務システムをMCPコネクタで接続。AIエージェントがリアルタイムにデータを取得・更新し、複数システムをまたぐ業務もBestllamへの一言で完結します。

エンタープライズグレードのセキュリティ データは国内データセンターに保存。個人情報（PII）や機密情報の漏洩を検出・防止するPII監査機能、オンプレミス対応、SAML SSO など、企業・官公庁が安心して使えるセキュリティ機能を標準装備しています。

日経トレンディへの掲載にあたって

日経トレンディは、ビジネスパーソンや新しいテクノロジーに関心を持つ読者に幅広く読まれているメディアです。

企業のAI活用がいよいよ本格化するなか、「複数のLLMをどう使い分けるか」「セキュリティを確保しながら業務効率を上げるにはどうすればいいか」——そうした課題を持つ多くの方に Bestllam を知っていただければと思います。

日経トレンディ2026年4月号は、全国の書店・コンビニエンスストアにてお買い求めいただけます。お手に取った際はぜひご覧ください📖

Bestllam に興味をお持ちの方へ

Bestllam の詳細・無料デモのお申し込みは下記サイトからどうぞ。

👉 https://bestllam.com

導入に関するご相談やご不明点は、お気軽にお問い合わせください。引き続き、皆さまのAI活用をサポートしてまいります！

こんにちは！

Qualitegコンサルティングチームです！

2026年現在、LLMの最大のユースケースの一つはコーディングだと考えています。実際、Menlo Venturesの調査でもコーディングはエンタープライズAI活用の代表的ユースケースとして位置づけられています。

そして、それにきづいたAIプラットフォーマー各社は自前のAIコーディングツールを次々と発表し人気を博しています。

逆にいえば、そのユースケースを早期に発見しプロダクト化してきた"コーディングSaaS"の開発企業は「胴元」であるAIプラットフォーマーが自分たちのSaaS領域に進出してきているわけで気が気でないでしょう。

ということで、本日はAIプラットフォーマーによる垂直統合と、私たちの取りうる戦略オプションについて考えてみたいと思います。

さて、2025年は、AIコーディングエージェント市場の勢力図が決定的に書き換えられた年でした。

Anthropicの「Claude Code」は2025年2月のリサーチプレビューから始まり、わずか半年で年換算ランレート（ARR）10億ドルに到達。

2026年初頭のアナリスト推計ではランレート25億ドル超に達しているとされます（※Investing.com掲載のReuters配信記事、およびMoneycontrol報道に基づく）。

Anthropicの全社ランレートも2025年初頭の約10億ドルから、同年8月には50億ドル超へ急伸しました。

実際、当社でもClaude Codeはフル活用されており、たとえばプロトタイプの初期構築やPR作成といった工程では、体感で従来の数倍〜十数倍の速度で進められるケースが出ています。

この数字が示しているのは、単に一つのプロダクトが成功したという話ではありません。AIの「モデル提供者」が「ツール提供者」へと垂直統合を進め、その過程でサードパーティのスタートアップが構築してきた市場を丸ごと取り込んでいくという、テクノロジー産業で繰り返されてきた構造的パターンが、AI領域でも再現されつつあるということです。

本稿では、この構造変化を冷静に整理したうえで、中国発オープンソースLLMとOSSエージェント基盤という二つの変数がもたらす影響、そしてその環境下でとりわけ私たちのような日本のスタートアップが取り得る戦略オプションについて考察します。

プラットフォーマーによる垂直統合の構造

APIビジネスに内在する情報の非対称性

まず、AIスタートアップが直面している構造的な不利について整理します。

AnthropicやOpenAIといったモデル提供者は、利用規約上、原則として顧客のAPIプロンプトをモデル学習に使用しないと明言しています。各社の規約には安全目的の保持やオプトアウト条件など細部の違いはありますが、基本方針としては受け止めてよいでしょう。

しかし、重要なのは、テキストの中身にアクセスしなくても、APIトラフィックのメタデータ——どの時間帯に、どのようなコンテキスト長で、どのツール呼び出しが、どのような順序と頻度で行われているか——は、インフラ運用上当然に把握されているという点です。

AIのプロフェッショナルにとって、このトラフィックの「形状」は極めて雄弁です。どのユースケースに需要が集中しているか、どのような設計パターンが成果を出しているかは、テキストを一行も読まずとも推測可能です。加えて、大口顧客であるスタートアップは、バグ報告やフィーチャーリクエストを通じて、最先端のエッジケースをプラットフォーマーに直接フィードバックします。

これは悪意の問題ではなく、構造の問題です。プラットフォーマーは、エコシステム全体が時間と資金を投じて行った市場検証の結果を、運営者としての立場から自然に観察できるポジションにいるのです。

「公式ツール」投入のインパクト

この情報の非対称性が最も顕在化するのは、プラットフォーマーが自ら公式ツールを投入する瞬間です。

Claude Codeの事例は象徴的です。

Anthropicは、自社の最新モデルに最適化された開発環境を、コマンドラインから直接操作可能なエージェントとして提供しました。サードパーティが複雑なプロンプトチェーンで実現していた機能が、シームレスな公式体験として統合される。ユーザーの移行は急速に進みます。

Menlo Venturesのレポート（※1）によれば、Anthropicはエンタープライズ市場で40%、コーディング領域では54%のシェアを獲得しています。AccentureはAnthropicとの提携を通じて約30,000人のプロフェッショナルにClaude Codeのトレーニングを実施する計画を発表しました（※2）。Snowflakeとは2億ドル規模の複数年パートナーシップを締結しています（※3）。

※1 Menlo Ventures "2025: The State of Generative AI in the Enterprise"
※2 Accenture公式プレスリリース（2025年12月9日）
Anthropic側告知
※3 Snowflake and Anthropic Announce $200 Million Partnership（Morningstar/Business Wire, 2025年12月3日）

このパターンは、AWSがサードパーティのインフラツールを自社サービスに統合してきた歴史、あるいはAppleがサードパーティアプリの機能をOSに取り込んできた歴史と構造的に同じです。プラットフォーマーは、エコシステムの成熟を待ってから、最も価値の高いレイヤーを自社に統合します。

ゲームの前提を変える二つの変数

変数①：中国発オープンLLMの台頭

この「胴元が勝つゲーム」の前提条件を根底から揺るがしているのが、中国発のオープンソースLLMです。

2025年1月に公開されたDeepSeek-R1は、総パラメータ671B（1トークンあたり37Bを活性化するMixture-of-Experts構造）を持ち、OpenAIのo1と同等の推論性能を達成したとされます。

公表された学習コストは約560万ドル。

この数字には研究開発やインフラ維持のコストが含まれておらず、SemiAnalysisの分析ではDeepSeekの総サーバー設備投資は約16億ドルと推計されています。それでも、西側の主要AI企業が一つのモデルに1億ドル以上を投じている中で、アーキテクチャの工夫によって大幅なコスト効率を実現したことは事実です。

APIの価格差はさらに顕著です。

DeepSeek公式APIドキュメント（2025年時点）によれば、DeepSeek-R1の価格は入力$0.28/出力$0.42（100万トークンあたり、キャッシュミス時）です。入出力比3:1で計算したブレンドコストは約$0.32となります。一方、OpenAIのo1は入力$15/出力$60（同）で、同条件のブレンドコストは約$26.25です。価格差はおよそ80倍にのぼります（※各社の価格は改定される場合があります。DeepSeek: api-docs.deepseek.com、OpenAI: platform.openai.com 参照）。

一方、AlibabaのQwenシリーズも急速に存在感を高めています。

Qwen2.5-Coder-32Bは、Alibaba公開のレポートによれば、HumanEvalやLiveCodeBenchなどの主要コーディングベンチマークでオープンソースモデルの中でトップクラスの性能を達成し、GPT-4oに匹敵するスコアを示したとされています。

最新のQwen3-Coderについては、周辺報道やレビューサイトにおいてSWE-Bench Verifiedで69.6%を記録したとの報告があり、条件次第では米国の主要モデルに匹敵する水準とされています
（※VentureBeatおよびindex.devのレビューに基づく。同スコアは500ターン設定等の特定条件下での結果であり、設定によって変動する点に留意が必要です）。

ライセンスはApache 2.0で、商用利用が可能です。

これらのモデルがオープンウェイトで公開されていることの意味は明確です。スタートアップは、プラットフォーマーのAPIに依存せずに、フロンティアクラスの推論能力を自社環境で稼働させる選択肢を持つようになったのです。

変数②：OSSエージェント基盤の成熟

モデルだけでは十分ではありません。モデルを「動かす」ためのエージェント基盤も必要です。

この領域で注目すべきはOpenHandsです。

OpenHandsは2024年3月にプロジェクトが発足し、18か月でGitHubスター60,000以上、ダウンロード400万回以上を記録（Business Wire, 2025年11月18日発表時点）。

OpenHandsの設計思想で特筆すべきは、モデル非依存（model-agnostic）のアーキテクチャです。Claude、GPT、DeepSeek、Qwenなど、あらゆるLLMを差し替え可能な形で利用できます。実行環境はDockerサンドボックスで完全に隔離され、セルフホストにもクラウドデプロイにも対応します。MITライセンスのオープンソースです。

中国製オープンLLM × OSSエージェント基盤。この組み合わせは、理論上、プラットフォーマーのAPIに一切依存しない自律的な開発環境を構築できることを意味します。

楽観論に対する留保

ただし、この「自由な組み合わせ」がすべてのスタートアップにとって現実的な選択肢であるかどうかは、冷静に検討する必要があります。

運用コストの現実
オープンモデルのセルフホストには相応のインフラ投資が必要です。DeepSeek V3の完全版を稼働させるには8〜16基のA100/H100クラスGPUが必要とされ、初期投資は5万〜20万ドル、MLOps人員として1〜2名のフルタイムエンジニア（年間12万〜20万ドル）が求められます。「API課金から解放された」としても、インフラコストが上回るケースは十分にあり得ます。

地政学的リスク
イタリアでは2025年1月末にデータ保護当局（Garante）の指摘を受け、DeepSeek-R1のアプリがApp Store/Google Play Storeから利用不能となりました（Reuters, 2025年1月29日報道）。

EU全体で中国製モデルへの規制強化が進む可能性も指摘されています。エンタープライズ顧客に対して「中国製のモデルを使用している」という事実がセールス上のハードルとなるケースも想定すべきです。

信頼性の課題。 DeepSeek-R1は2025年1〜2月に数日間の部分停止を経験し、トークン消費後に空レスポンスを返す事象が報告されています。プロダクション環境で使用する場合、マルチプロバイダのフェイルオーバー設計が前提となり、その分のアーキテクチャ複雑性が発生します。

要するに、「API依存」と「フルセルフホスト」は二者択一ではなく、グラデーションの中でどこにポジションを取るかという判断が求められるのです。

この構造の中で、どこに勝ち筋があるのか

ここまでの整理を踏まえると、いくつかの問いが浮かび上がります。

「ドメイン特化」は、まだ堀になるのか？

率直に言えば、怪しくなっています。

建設業の専門知識をClaudeに聞けば相当な精度で返ってきます。医療も法律も同様です。

フロンティアモデルの汎用性能がここまで上がった以上、「AIが詳しいかどうか」で差をつけるのは年々難しくなっています。

では、プラットフォーマーが構造的に踏み込めない領域はどこか。

一つの仮説は「接続」です。

日本の中堅・中小企業のバックオフィスには、APIが存在しないオンプレミスシステム、紙ベースの業務フロー、独自フォーマットのExcelが依然として大量に残っています。大企業でも基幹システム間の連携は複雑で、AIを業務フローに統合するには個別の泥臭い実装が不可避です。

AnthropicもOpenAIも、この「最後の1マイル」を一社ずつ埋めに行くインセンティブはありません。彼らのビジネスモデルはAPIの提供であり、個別のシステムインテグレーションではないからです。

だとすれば、堀になり得るのは「AIの賢さ」ではなく
「AIを現場にフィットさせた実績と、そこから得られるフィードバックデータの蓄積」
ではないか。

これはモデルが変わっても、公式ツールが出ても、簡単には複製されません。ただし、この仮説が正しいかどうかは、各社が自分の顧客と市場で検証するしかありません。

モデル非依存設計は、もはや「衛生要件」か？

2024年にはClaude 3.5 Sonnetが圧倒的でした。2025年にはDeepSeek-R1が台頭し、QwenシリーズがSWE-Benchで逆転する場面も出ています。今日の最適なモデルが半年後も最適である保証はどこにもありません。

OpenHandsがLiteLLMを通じて実現しているようなモデル非依存のアーキテクチャは、単なる技術的な好みの問題なのか、それとも経営上のリスク管理として必須の要件になりつつあるのか。Claude、GPT、DeepSeek、Qwenのどれにでも差し替えられる設計を最初から組んでおくコストと、特定モデルに最適化して短期的な性能を取るトレードオフを、どう判断するか。この問いに正解はありませんが、少なくとも意識的に選択している企業とそうでない企業では、1年後の立ち位置が大きく変わるはずです。

「秘伝のタレ」は、どのレイヤーに仕込むべきか？

プロンプトエンジニアリングの工夫——いわゆる「秘伝のタレ」——は、モデルのメジャーアップデート一回で陳腐化するリスクがあります。

Claude 3.5 Sonnetで最適化されたプロンプトチェーンが、Claude 4で不要になったケースは業界全体で多数報告されています。

であれば、持続的な優位性はモデル層ではなく、その外側——独自の業務データ、ユーザーのフィードバックループ、業界固有のナレッジベース、それらを活かすRAG（Retrieval-Augmented Generation）の仕組み——に構築すべきなのかもしれません。モデルが入れ替わっても残る資産はどこにあるか。この見極めが、おそらく今後数年のプロダクト設計における最も重要な問いの一つです。

OSSへの投資は「保険」として合理的か？

今すぐフルセルフホストに移行する必要があるかと問われれば、多くの企業にとって答えはNoでしょう。しかし、OpenHandsやvLLMの動向をウォッチし、社内で小規模なPoCを回しておくことのコストは、それほど大きくありません。

プラットフォーマーがAPI仕様を変更したとき、料金体系を改定したとき、特定機能を廃止したとき、「プランB」を発動できる状態にあるかどうか。このオプションバリューをどう評価するかは、各社のリスク許容度と事業構造に依存します。ただ、このオプションが「ゼロコストで手に入るもの」から「相応の投資で初めて確保できるもの」に変わりつつあることは、認識しておいて損はないはずです。

おわりに

本稿で整理した構造は、決して悲観的なものではありません。

プラットフォーマーによる垂直統合の圧力は確かに強まっています。

しかし同時に、中国発のオープンLLMとOSSエージェント基盤の成熟が、「API依存の一本足打法」以外の選択肢を現実的なものにしました。

すべてをプラットフォーマーに委ねるのでもなく、すべてを自前で抱えるのでもない。このグラデーションの中でどこにポジションを取るかという判断の余地が生まれたこと自体が、この1年の最も大きな変化です。

テクノロジー産業のゲームのルールが、インフラを握るプラットフォーマーに有利にできていることは否定できません。

ただ、ルールを正確に把握したうえでテーブルに着くのと、把握せずに座るのとでは、結果はまるで違います。

ただ最後に、強調しておきたいことがあります。

ここまで「垂直統合の圧力」や「胴元が有利な構造」を論じてきましたが、それはプラットフォーマーを善悪で裁きたいからではありません。

そもそもこの市場そのものを開いたのは、OpenAIがChatGPTという形で生成AIを一般に解放し、使える道具として社会に根付かせたことでした。

あの転換がなければ、私たちを含む多くのスタートアップの挑戦も、議論の土俵も、存在しなかったはずです。

私たちはその上に立って事業をしている以上、敬意を持ってこのエコシステムに参加したい。

同時に、敬意と戦略は両立します。ルールを作った人をリスペクトしながら、そのルールの中でどう勝ち筋を作るかを考える——本稿がそのための補助線になれば幸いです。

出典・参考記事リスト

• Menlo Ventures（Enterprise向け生成AIレポート：シェア推計など）
  • https://menlovc.com/perspective/2025-the-state-of-generative-ai-in-the-enterprise/?utm_source=chatgpt.com
• Investing.com（Reuters配信：Anthropicのランレート等に触れている記事）
  • https://www.investing.com/news/stock-market-news/anthropic-valued-at-183-billion-after-13-billion-fundraise-4219871?utm_source=chatgpt.com
• Moneycontrol（Reuters系：Claude Codeのrun-rate $2.5B超などに触れている記事）
  • https://www.moneycontrol.com/artificial-intelligence/anthropic-clinches-380-billion-valuation-after-30-billion-funding-round-article-13826360.html?utm_source=chatgpt.com
• Reuters（イタリアでDeepSeekアプリが利用不能になった件：2025/1/29頃の報道）
  • https://www.reuters.com/technology/deepseek-app-unavailable-apple-google-app-stores-italy-2025-01-29/?utm_source=chatgpt.com
• OpenAI 公式ドキュメント（o1：モデル/価格の前提に使ったページ）
  • https://platform.openai.com/docs/models/o1
• DeepSeek 公式APIドキュメント（Pricing：入力/出力単価の前提に使ったページ）
  • https://api-docs.deepseek.com/quick_start/pricing/
• SWE-bench Verified（ベンチマークの参照元）
  • https://www.swebench.com/verified.html?utm_source=chatgpt.com
• Business Wire（OpenHandsのSeries A・スター数・DL数など）
  • https://www.businesswire.com/news/home/20251118768131/en/OpenHands-Raises-%2418.8M-Series-A-to-Bring-Open-Source-Cloud-Coding-Agents-to-Enterprises?utm_source=chatgpt.com

こんにちは！

LLM推論基盤プロビジョニング講座、今回は番外編をお届けします！

第3回「使用モデルの推論時消費メモリ見積もり」では、GPUメモリ消費の二大要素としてモデルのフットプリントとKVキャッシュを紹介し、1トークンあたりのKVキャッシュサイズの計算方法を解説しました。

また第4回「推論エンジンの選定」ではvLLMやDeepSpeedなど各推論エンジンの特性を比較し、第5回では量子化や並列化による最適化戦略を解説してきました。

しかし、実はKVキャッシュにはまだまだ掘り下げるべきトピックがあります。

• KVキャッシュをGPUのVRAMからCPU RAMやディスクにオフロードしたらどうなるのか？ どのくらい遅くなるのか？
• HuggingFace TransformersとvLLMでは、KVキャッシュの管理方針がなぜ根本的に異なるのか？
• そもそもKVキャッシュが大きくなる原因であるアテンション構造を変えてしまう GQA（Grouped-Query Attention）とは何か？ 第5回で紹介した量子化とは別の軸で、KVキャッシュを劇的に小さくする技術です。

今回はこれらのテーマを、PCIe帯域幅の実数値やモデルサイズごとの具体的な計算を交えながら解説していきます。第3回で学んだKVキャッシュの基礎知識があればスムーズに読み進められるとおもいます。

LLM推論基盤プロビジョニング講座 シリーズ記事一覧

• 第1回 基本概念と推論速度
• 第2回 LLMサービスのリクエスト数を見積もる
• 第3回 使用モデルの推論時消費メモリ見積もり
• 第4回 推論エンジンの選定
• 第5回 GPUノード構成から負荷試験までの実践プロセス

KVキャッシュのおさらい

第3回でも解説しましたが、あらためてKVキャッシュの仕組みをおさらいしておきましょう。

Transformerの自己回帰生成（1トークンずつ生成する推論）では、新しいトークンを1つ生成するたびに、全レイヤーを順番に通す必要があります。

トークン１つ生成するために、全部レイヤーぶんの計算するってことになります。原理的には。

処理の流れは以下のとおりです

1. 新しいトークンの埋め込みがLayer 0に入る
2. Layer 0で、そのレイヤーの過去のKey・Valueテンソルと合わせてAttentionを計算
3. その出力がLayer 1に渡る
4. Layer 1で同様にKVを参照してAttention…
5. これを最終レイヤーまで繰り返す
6. 最終レイヤーの出力から次トークンを予測

ただ、ここで重要なポイントは

過去のトークンに対するKeyとValueの計算結果は毎回同じになるという点

です。
ということで毎トークンで再計算するのは無駄なので、
一度計算したKey・Valueをキャッシュしておきます。

これがKVキャッシュですね

このKVキャッシュですが、
コンテキストが長くなるほど大きくなり、VRAMを圧迫していきます。

KVキャッシュのサイズ感

さて、具体的にどのくらいのメモリを消費するのか、（少し古いモデルですが）Llama 2 7Bを例に計算してみましょう。

モデル構成： 32レイヤー、32ヘッド、ヘッド次元128、FP16

まず、1トークンを処理するときに1つのレイヤーで必要になるKVキャッシュのサイズは以下のとおりです

K: 32ヘッド × 128次元 × 2バイト(FP16) = 8 KB
V: 同じく 8 KB
合計: 約16 KB/トークン/レイヤー

つまり、1トークンにつき1レイヤーあたり約16KBのKVキャッシュが蓄積されていきます。

ここで、ユーザーが2048トークン分の文章を入力＋生成した状態を考えると

1レイヤーあたり: 16 KB × 2,048トークン = 約32 MB
全32レイヤー合計: 32 MB × 32レイヤー = 約1 GB

この「2048トークン」の部分がコンテキスト長に応じて変わるため、KVキャッシュのサイズはコンテキスト長に比例して大きくなります。

コンテクスト長が8Kトークンなら約4 GB、32Kトークンなら約16 GBがKVキャッシュとして消費されるとうわけです

要するに、ユーザーが大量の文章を入れたり、大量に出力されるような場面では、KVキャッシュもどんどん消費されます

モデルの重み（7B FP16で約14 GB）に加えてこのサイズが必要になりますので、VRAMへの負担は無視できません。

KVキャッシュをCPU RAMやディスクに逃がす

さて、ここで最近話題になるのがコストの高いGPUのRAM（VRAM）の消費量をなるべくおさえたいということで、KVキャッシュをCPU側のメモリやSSDなどのディスクに逃がせないか、といったアイデアです。

結論からいうと、逃すことが可能です。

たとえば、HuggingFace Transformersでは、KVキャッシュをGPUのVRAMからCPU RAMやディスクにオフロードすることができます。

シンプルな方法

KVキャッシュの実体はPyTorchのテンソルなので、.to("cpu") で簡単にCPU RAMに退避できます。

# CPU RAMに退避
cpu_cache = tuple(
    tuple(t.to("cpu") for t in layer)
    for layer in past_key_values
)

# 使うときにGPUに戻す
gpu_cache = tuple(
    tuple(t.to("cuda") for t in layer)
    for layer in cpu_cache
)

ディスクに保存する場合は torch.save を使います。

import torch
torch.save(past_key_values, "kv_cache.pt")
past_key_values = torch.load("kv_cache.pt", map_location="cuda")

HuggingFace の OffloadedCache

Transformers 4.36以降では Cache クラスが導入されており、OffloadedCache を使えばレイヤーごとに自動でCPUオフロードしてくれます。

output = model.generate(
    input_ids,
    cache_implementation="offloaded",
    max_new_tokens=100,
)

内部的には、Layer Nを計算中にLayer N+1のKVキャッシュを非同期でプリフェッチすることで、転送のオーバーヘッドを緩和しています。

オフロードのボトルネック：PCIe転送速度

さて、技術的にはKVキャッシュをGPUの中から追い出す＝オフロードすることは可能ですが、ここでまず問題になるのがKVキャッシュをGPU外に出す、KVキャッシュを読み取るときの読み書きスピードです。

CPU ↔ GPU間のデータ転送はPCIeバスを介して行われます。

で、そのスピード、つまり、帯域幅はPCIのバージョンと使えるレーン数で決まります。

※PCIのスピードやレーン数についてはこちらの記事（「[PC自作日記1] 現代の自作PCアーキテクチャを理解する」）で詳しく解説しています

実際にどのくらい遅くなるか

ちょっとふるいですが、Llama 2 7B（32レイヤー、FP16）、コンテキスト2048トークンの場合で見積もってみましょう。

先ほど説明したとおり、1トークン生成するごとに全レイヤーを通す必要がありますので、各レイヤーのKVキャッシュをGPUに転送 → 計算 → CPUに戻す、というサイクルが発生します

さきほどの2048トークンぶんの分量ですと、1レイヤーあたり約32 MB × 32レイヤー = 約1 GBの転送量になりますので、PCIe 4.0（実効25 GB/s）なら片道約40msかかります。

これを、GPUのみで完結する場合とくらべますと、おおよそ 3〜5倍遅くなる 計算です。
PCI転送だけでこれだけ遅くなります。

ただ、ｍレイヤーは順番に処理されるので、Layer Nの計算中にLayer N+1を非同期転送する「パイプライン化」が可能ですので、計算時間が転送時間を上回る場合は、転送コストを隠蔽できます。
逆に長コンテキストで1レイヤーあたりの転送量が大きくなると、計算時間を超えてしまいボトルネックになります。

コンテキスト長と転送コストの関係

32Kコンテキストでは1トークンの生成に0.6秒以上かかる計算になり、リアルタイム用途ではかなり厳しくなります。

たとえ、ＰＣＩを4.0の２倍程度はやくなるPCI5.0にしてもリアルタイム用途では厳しいです。

ディスク（SSD）への保存はさらに遅く、NVMe SSDで3〜7 GB/s、SATA SSDで約0.5 GB/sです。

これでは、リアルタイム推論には向かず、セッション間でキャッシュを再利用する用途に限られるというのが実情です。

vLLMとの設計思想の違い

第4回でvLLMとHuggingFace Transformers（QCT）の違いを紹介しましたが、ここではKVキャッシュ管理の観点からもう少し掘り下げてみましょう。

HuggingFace Transformersや当社独自のQCTをつかう場合、アーキテクチャがシンプルでKVキャッシュのオフロードが比較的やりやすいのですが、vLLMだと実はKVキャッシュのオフロードの難易度が高くなります。

なぜなら同じKVキャッシュの管理でも、両者はまったく異なるアプローチを取っているからです。

HuggingFace Transformers

• シンプルなforループでレイヤーを1つずつ順番に処理します
• 各レイヤーのKVキャッシュを好きなタイミングで出し入れできます
• 基本的に1リクエストずつのシーケンシャル処理です
• バッチ処理やプロトタイピングに向いています

vLLM

• PagedAttention でKVキャッシュを固定サイズブロックに分割し、VRAM内で効率管理します
• 連続バッチング で複数リクエストを同時処理します
• 基本的に全部VRAMに載る前提で設計されています
• 同時数十リクエストを捌き、スループット数百〜1000+ tokens/secを実現します

vLLMにもKVキャッシュのCPUスワップ機能は存在しますが、推論中に毎トークン転送するのではなく、リクエストがプリエンプト（中断）されたときにそのリクエストのKVブロックをCPUに退避し、再開時に戻すというスケジューリングの一環として使われます。

なぜこの違いが生まれるか

HuggingFace Transformersはシンプルな単一リクエストの推論ループだからこそ、各レイヤーで .to("cpu") / .to("cuda") を挟むだけでオフロードが実現できます。一方、vLLMは連続バッチングで複数リクエストを同時処理しているため、毎レイヤーでPCIe転送を待つとパイプライン全体が詰まってしまいます。

これは柔軟性 vs スループットのトレードオフです。

個人で大きいモデルを動かしたいならHFのオフロード、複数ユーザーへのサービングならvLLMでVRAMに収まる構成を選ぶのが定石になります。

さらに、vLLMはモデルアーキテクチャごとの最適化も随所にいれており、スループットを出せるぶん、リアルタイムなKVキャッシュオフロードを手軽にやるのがかなり難しくなっています。

HuggingFace Transformersの同時処理能力

同時処理能力についてもみておきましょう。

HuggingFace Transformers単体では、基本的に1リクエストずつの処理になります。model.generate() は同期的・ブロッキングで、並行処理の仕組みは内蔵されていません。

ただし、FastAPIなどでラップしてマルチスレッドで model.generate() を呼ぶ場合、VRAMに余裕があれば2〜3リクエストが同時に走ることはあります。PyTorchのCUDAは同一GPU上で複数カーネルをある程度並行実行できるためです。

とはいえ、各リクエストが独立にアテンション計算を行うため、バッチ化の恩恵がなくVRAM効率は良くありません。vLLMとの差はスループットで文字通り桁違いになります。

バッチ処理ならHFが輝く

一方で、オフラインのバッチ処理ならHuggingFace Transformersは良い選択肢です。

• リアルタイム性が不要なので、オフロードの遅延も許容できます
• 1件ずつ順番に処理すればよく、並行処理の複雑さがありません
• コードがシンプルで、前処理・後処理のカスタマイズが自由です
• KVキャッシュをディスクに保存して再利用できます

大量のドキュメント要約、データセットへのラベル付け、夜間バッチ推論など、「寝ている間に終わればいい」用途には十分実用的です。

小さいGPUで大きいモデルを動かす

KVキャッシュのオフロードだけでは不十分で、モデルの重みがVRAMに載らなければそもそも動きません。

GPU VRAMに必要なもの

device_map="auto" による自動分配

HuggingFace Transformersの device_map="auto" を使えば、VRAMに入るレイヤーはGPUに、残りはCPU RAMに、それでも入らなければディスクに自動配置されます。

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-2-70b-hf",
    device_map="auto",
    offload_folder="offload",
)

これなら8GBのGPUでも70Bモデルが一応動きます。ただし速度は大幅に低下します。

量子化との組み合わせ

第5回で解説した量子化と組み合わせるのが最も現実的です。モデルサイズを小さくしたうえでオフロードを使います。

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-2-70b-hf",
    load_in_4bit=True,          # 140GB → 約35GB
    device_map="auto",          # 残りはCPUへ
)

24GB GPU 1枚で完結するモデルサイズの目安（4bit量子化時）

70Bの4bit（約35GB）は24GBのVRAMには収まりません。device_map="auto" で半分程度をCPU RAMに配置することで動作はしますが、CPU上のレイヤー処理は遅くなります。GPU 1枚で完結させたいなら、24GB × 2枚（48GB）か、A6000（48GB）やA100（80GB）が必要です。

KVキャッシュのCPUオフロードが活きるシナリオ

ここまで読んで「オフロードは遅くなるだけでは？」と思われたかもしれません。KVキャッシュ「だけ」をCPUに逃がして意味がある場面は、モデルの重みはGPUに載るが、コンテキストが長くてKVキャッシュがVRAMを溢れる場合です。

30Bモデル × 24GB GPUの具体例

30Bモデルを4bit量子化（約17GB）で24GB GPUに載せると、残り約9GBをKVキャッシュに使えます。

GQA対応モデル（KVヘッド8）の場合、1トークンあたりのKVキャッシュサイズは以下のとおりです：

K + V: 64レイヤー × 8ヘッド × 128次元 × 2バイト × 2(KV) = 256 KB/トークン

9GBで約36,000トークン分のKVキャッシュが格納できます。フルアテンション（KVヘッド64）なら約4,500トークンで一杯になります。

この表をみると、同じ9GBでもアテンション方式によって格納できるトークン数が桁違いに異なることがわかりますね。GQAについては次のセクションで詳しく解説します。

有効なユースケース

1. 長文書のバッチ分析 — 論文や契約書を丸ごと入力して要約します。バッチ処理なので遅くてもOKです
2. RAGで大量チャンクを一度に入力 — 検索で絞らず全部コンテキストに突っ込んで精度を上げたい場合に有効です
3. KVキャッシュの再利用 — 同じシステムプロンプト（数千トークン）のプリフィル結果をCPU RAMに保持しておき、リクエストごとにGPUに転送します。長いプロンプトだと、毎回プリフィルを再計算するよりPCIe転送の方が速くなる逆転ポイントがあります

GQA/MQA — KVキャッシュ問題を根本から緩和する

ここまではKVキャッシュの「運用」を見てきましたが、そもそもKVキャッシュが大きくなる原因はAttentionヘッドの数にあります。これを構造的に解決するのがGQA（Grouped-Query Attention）とMQA（Multi-Query Attention）です。

第5回では量子化によってモデルのフットプリントを小さくするアプローチを紹介しましたが、GQAはそれとは別の軸で、アテンション構造そのものを変えてKVキャッシュを劇的に小さくする技術です。

MHA（Multi-Head Attention）— 従来方式

Query、Key、Valueそれぞれが同じ数のヘッドを持ちます。

Q: 64ヘッド
K: 64ヘッド  ← 全部独立
V: 64ヘッド  ← 全部独立

MQA（Multi-Query Attention）— 極端な共有

2019年にGoogleのNoam Shazeerが論文「Fast Transformer Decoding: One Write-Head is All You Need」で提案しました。KとVを全ヘッドで共有します。

Q: 64ヘッド
K: 1ヘッド   ← 全Qヘッドがこの1つを共有
V: 1ヘッド

KVキャッシュが1/64になります。推論速度は大幅に向上しますが、品質がやや落ちるのが課題でした。

GQA（Grouped-Query Attention）— バランスの取れた中間

2023年5月にGoogleのJoshua Ainslieらが論文「GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints」（arXiv:2305.13245）で提案しました。Qヘッドをグループに分けて、グループごとにK, Vを共有します。

Q: 64ヘッド（8グループ × 8ヘッド）
K: 8ヘッド   ← 各グループに1つ
V: 8ヘッド

KVキャッシュが1/8になり、品質と効率のバランスが優れています。

視覚的なイメージ

MHA:  Q₁→K₁  Q₂→K₂  Q₃→K₃  Q₄→K₄  (各自専用)
GQA:  Q₁→K₁  Q₂→K₁  Q₃→K₂  Q₄→K₂  (グループで共有)
MQA:  Q₁→K₁  Q₂→K₁  Q₃→K₁  Q₄→K₁  (全員同じ)

GQAの動機

KVキャッシュ削減が主要な動機の一つですが、それだけではありません。自己回帰生成のボトルネックは計算ではなくメモリ帯域です。

毎トークンで巨大なKVキャッシュをVRAMから読み出す必要があります。

つまり、KVキャッシュのサイズ（VRAM容量の問題）と読み出し帯域（速度の問題）の両方を同時に改善することが目的です。推論のメモリ帯域ボトルネックを解消する中で、KVキャッシュ削減も自然についてきたという方が正確でしょう。

GQAの採用タイムライン

GQAの論文発表から実際のモデルへの搭載は非常に速く、わずか2ヶ月で業界の主要モデルに採用されました。以下、各ソースで裏取りしたタイムラインをまとめます。

注目すべきは、Llama 2の7Bと13BはフルアテンションのMHAのままで、70Bだけ にGQAが採用された点です。小さいモデルではKVキャッシュがそこまで問題にならないという判断でしたが、Llama 3以降はすべてのサイズでGQAが標準になっています。

また、GQA論文の正式な学会発表は2023年12月のEMNLP（シンガポール）でしたが、arXivプレプリントが2023年5月に公開された直後から各社が採用に動いており、それだけ業界全体でKVキャッシュが切実な課題だったことの裏返しと言えます。

まとめ：実践的な判断フロー

最後に、ここまでの内容を踏まえた実践的な判断フローを整理しておきましょう。

モデル選定時： GQA対応モデルを選びましょう。最近のモデル（Llama 3以降、Mistral等）はほぼ全てGQA対応で、KVキャッシュが大幅に小さくなっています。

VRAMが足りないとき

1. まず量子化（4bit/8bit）でモデルサイズを圧縮
2. それでも入らなければ device_map="auto" でCPU RAMにオフロード
3. KVキャッシュだけ溢れる場合は cache_implementation="offloaded" を使用
4. サービングなら量子化 + vLLMでVRAMに収まる構成を選ぶ

用途で使い分ける

• 個人のバッチ処理 → HuggingFace Transformers + オフロード。遅くても動けばOKです
• 複数ユーザーへのサービング → vLLMまたはTGI。VRAMに収まる構成が前提です
• プロトタイピング・研究 → HuggingFace Transformers。コードがシンプルでカスタマイズしやすいです

KVキャッシュは「見えないVRAM消費者」として軽視されがちですが、コンテキスト長が伸びる昨今のLLMでは、その管理が推論パフォーマンスを左右する重要なファクターになっています。GQAの普及によって状況はかなり改善されましたが、128Kトークンのような超長コンテキストでは依然としてKVキャッシュの扱いが鍵を握ります。

自分の用途とハードウェアに合わせた戦略を選ぶことが、快適なLLM推論への近道です。

それでは、また次の記事でお会いしましょう！

LLM/AIセキュリティのことなら株式会社Qualiteg

私たちQualitegは、LLMの推論・サービング基盤を実際に設計してきたエンジニアリングチームを有しており推論エンジンを単なる箱として扱わず、アテンション計算やKVキャッシュの挙動など深い知見をベースにしたローカルLLM技術のご支援を提供しています。「VRAMに収まる構成はどこか」「vLLMとHugging Face、判断軸は何か」「既存モデルを自社ドメインへ適応させる最短経路は」「オープンLLMと商用LLMの使い分け」「セキュアなローカルLLM構成はどうすればいいか」「ローカルLLMとGPUの選び方」「GPUデータセンターの需要と市場予測」「AI市場予測」などコア技術からAI市場分析まで、お気軽にご相談くださいませ。

AI Technology Consulting | Qualiteg

Qualiteg Logo