── 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

こんにちは！

Qualitegプロダクト開発部です！

PII（個人情報）検出のデモアプリを開発していて、検出したエンティティの位置をハイライト表示する機能を実装していました。

バックエンドは Python（FastAPI）、フロントエンドは JavaScript という構成です。

ある日、テストデータにこんなメール文面を使ったところ、ハイライトの位置が途中から微妙にずれるバグに遭遇しました。

鈴木一郎 様

いつもお世話になっております。
サンプル商事の佐藤でございます。

先日の件、確認が取れましたのでご連絡いたします。

お忙しいところ恐縮ですが、ご確認のほど宜しくお願い致します。

💻 ＃オンラインでのお打ち合わせ、お気軽に声がけください！
――――――――――――――――――――――――――――――
サンプル商事株式会社
営業部 第一課
山田　太郎 （Yamada　Taro）
〒100-0001 東京都千代田区千代田1-1-1 サンプルビル 3F
tel: 03-1234-5678
https://example.com/contact

検出結果をハイライト表示してみると、前半は完璧なのに、途中からずれ始めていました。

何が起きたのか

Python バックエンドは検出結果として各エンティティの start_position と end_position を返します。フロントエンドではその位置を使って text.substring(start, end) でハイライトする部分を切り出します。

前半のハイライトは正確でした:

• 鈴木一郎 → 正しくハイライト
• サンプル商事 → 正しくハイライト
• 佐藤 → 正しくハイライト

ところが、メール署名部分に入ると全てのハイライトが1文字分左にずれていました:

• 電話番号 03-1234-5678 → 03-1234-567 とハイライト（先頭にスペース、末尾の8が漏れ）
• 人名 山田 → \n山 とハイライト（改行を含んで田が漏れ）
• URL https://example.com/contact → https://example.com/contac とハイライト（先頭にスペース、末尾のtが漏れ）

途中からずれる？なんでだろう

全部ずれているなら「オフセット計算のバグ」で話は単純です。でも前半は正しくて後半だけずれる。しかもずれ幅は一律で1文字分。

まず考えたのは「途中で位置計算がリセットされるような処理があるのか？」ということ。でもコードを読み返しても、位置はバックエンドから一括で返されていて途中で再計算はしていません。

次に、ずれ始める正確な境界を調べました。正しくハイライトされている最後のエンティティと、ずれ始める最初のエンティティの間に何があるか。

...ご確認のほど宜しくお願い致します。    ← ここまでは正常

💻 ＃オンラインでの...                   ← ここを境に

サンプル商事株式会社                     ← ここからずれ始める

...💻？この絵文字、もしかして。

ブラウザの開発者ツールで確認してみると:

"💻".length   // => 2  ...えっ？

💻 は1文字のはずなのに .length が 2 を返す。ここにバグの原因がありました。

原因: Unicode のコードポイントとコードユニットの違い

Python の文字列

Python 3 の文字列は Unicode コードポイントの列です。

text = "💻オンライン"
print(len(text))        # => 6
print(text[0])          # => "💻"
print(text[1])          # => "オ"

💻 (U+1F4BB) は1つのコードポイントなので、Python では長さ 1 です。

JavaScript の文字列

JavaScript の文字列は UTF-16 コードユニットの列です。

const text = "💻オンライン";
console.log(text.length);    // => 7
console.log(text[0]);        // => "\uD83D"  (サロゲートの片割れ。単体では表示できない)
console.log(text[1]);        // => "\uDCBB"  (サロゲートの片割れ。単体では表示できない)
console.log(text[2]);        // => "オ"

💻 (U+1F4BB) は BMP（基本多言語面, U+0000〜U+FFFF）の外にあるため、JavaScript ではサロゲートペア "\uD83D\uDCBB" として2つのコードユニットで表現されます。よって長さは 2 です。

ずれの仕組み

Python が start_position=1（= "オ"）を返しても、JavaScript の text[1] はサロゲートの後半 \uDCBB を指します。JavaScript で "オ" にアクセスするには text[2] が必要です。

つまり、BMP外の文字が1つあるごとに、それ以降の全ての位置が+1ずつずれていくのです。

解決策: Array.from() でコードポイント単位にする

JavaScript の Array.from() は文字列をイテレータで走査するため、コードポイント単位で分割されます。

const text = "💻オンライン";
const codePoints = Array.from(text);

console.log(codePoints.length);  // => 6  ← Python と一致！
console.log(codePoints[0]);      // => "💻"
console.log(codePoints[1]);      // => "オ"

これで Python の位置インデックスがそのまま使えます。

修正前（バグあり）

// NG: UTF-16コードユニット単位 → 絵文字でずれる
const entityText = text.substring(start, end);

修正後

// OK: コードポイント単位 → Python と一致
const codePoints = Array.from(text);
const entityText = codePoints.slice(start, end).join("");

実際の修正では text.length も codePoints.length に置き換えています。

他の解決策

スプレッド構文

Array.from() と同様にコードポイント単位で分割できます。

const codePoints = [...text];
console.log(codePoints.length);  // => 6

Python 側で UTF-16 オフセットを返す

バックエンド側を修正する方法もあります。Python で UTF-16 でのバイト位置を計算できます。

def to_utf16_offset(text: str, cp_offset: int) -> int:
    """コードポイントオフセットをUTF-16コードユニットオフセットに変換"""
    prefix = text[:cp_offset]
    # UTF-16エンコード後のバイト数 / 2 = コードユニット数
    # utf-16 だとBOM（2バイト）が先頭に付くため、BOMなしの utf-16-le を使用
    return len(prefix.encode('utf-16-le')) // 2

text = "💻オンライン"
print(to_utf16_offset(text, 1))  # => 2  ← JS の substring で使える

ただし、API の利用者に「この位置は UTF-16 オフセットです」と明示する必要がある点に注意です。Python のインデックスと一致しなくなるので混乱を招く可能性があります。

補足: コードポイント数 ≠ 見た目の文字数

今回のバグは Array.from() でコードポイント単位に揃えることで解決しました。Python と JavaScript の両方がコードポイント単位で数えるため、ZWJ sequence（合成絵文字）や結合文字がテキストに含まれていても両者の位置は一致します。つまり今回の実装としてはこれで問題ありません。

ただし、コードポイント数と「見た目の文字数」は必ずしも一致しないという点は知っておくと役立ちます。

// ZWJ sequence: 見た目は1文字だがコードポイントは7つ
const family = "👨‍👩‍👧‍👦";
console.log(Array.from(family).length);  // => 7  （👨 + ZWJ + 👩 + ZWJ + 👧 + ZWJ + 👦）

// NFD形式の結合文字: 見た目は1文字だがコードポイントは2つ
const ga = "か\u3099";  // "か" + 結合濁点 = "が"
console.log(Array.from(ga).length);  // => 2

「見た目の1文字」単位で正確に扱いたい場合（カーソル位置やテキストエディタの実装など）は、書記素クラスタ単位で分割する Intl.Segmenter が使えます。モダンブラウザおよび Node.js 16+ で利用可能です。

const segmenter = new Intl.Segmenter("ja", { granularity: "grapheme" });

const family = "👨‍👩‍👧‍👦";
const segments = [...segmenter.segment(family)];
console.log(segments.length);           // => 1  ← 見た目通り！

影響を受ける文字の一覧

BMP外（U+10000以降）の文字は全てサロゲートペアになります。実用上よく遭遇するのは：

逆に、以下はBMP内なのでサロゲートペアにはなりません:

• 日本語の漢字・ひらがな・カタカナ（ほぼ全て）
• 全角英数字（Ａ, １ など）
• ASCII文字

まとめ

Python と JavaScript の間で文字列の位置情報をやり取りする場合は、BMP外の文字（絵文字等）の存在を常に考慮すべきです。

JavaScript 側では Array.from() や [...str] を使ってコードポイント配列に変換してからインデックスアクセスすることで、Python との一貫性を保てます。さらに ZWJ sequence や結合文字まで考慮する必要がある場合は、Intl.Segmenter の利用を検討してください。

このバグは「テストデータに絵文字を含めていなかった」ことで見逃されていました。異なる言語間で文字列位置を共有する実装では、テストケースに必ず BMP 外の文字（絵文字、CJK拡張漢字など）を含めましょう。

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

こんにちは、今回はシリーズ第5回「ブラウザ設定と認証」について解説いたします！

さて、前回（第4回）では、プロキシサーバーをドメインに参加させることで、ChatGPTやClaudeへのアクセスを「誰が」行ったかを確実に特定する仕組みを解説しました。「信頼の連鎖」の概念や、Windows版Squidなら1時間で構築できる環境、Negotiate/NTLM/Basicという3段階の認証フォールバック機構について理解いただけたかと思います。

しかし、せっかくサーバー側で完璧な統合Windows認証環境を構築しても、ブラウザ側の設定が適切でなければ、ユーザーには毎回パスワード入力ダイアログが表示されてしまいます。

「Edgeだと自動でログインできるのに、Chromeだとパスワードを聞かれる」
「同じサーバーなのにURLの書き方で動作が違う」

これらはヘルプデスクに寄せられる典型的な問い合わせです。（ただ、業務に好きなブラウザ使っていいよ、という企業はそんなに多くはないとおもいます）

今回は、統合Windows認証がブラウザでどのように動作するのか、その仕組みから各ブラウザ（Edge/Chrome/Firefox）での具体的な設定方法、そしてグループポリシーによる一括管理まで詳しく解説します。特に「イントラネットゾーン」という概念を理解することで、なぜ認証動作が変わるのかが腑に落ちるはずです。

それでは、エンドユーザーにストレスを与えない、シームレスな認証環境の構築に挑戦していきましょう！

連載の構成

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

第5章：ブラウザ設定と認証

5.1 統合Windows認証の動作条件

5.1.1 イントラネットゾーンの概念

統合Windows認証が自動的に動作するかどうかは、アクセス先がどの「セキュリティゾーン」に属するかによって決まります。これは、多くのユーザーが混乱するポイントです。

まずは、現場でよくある「なんで？」という声から始めましょう。

同じサーバーにアクセスしているはずなのに、URLの書き方が違うだけで認証動作が変わってしまう。この不思議な現象、実は「セキュリティゾーン」という仕組みが原因なのです。

【なぜ自動認証されたりされなかったりするのか】
田中：「同じサーバーなのに、アクセス方法で動作が違う？」

ケース1：
田中：「http://fileserver/ にアクセス」
ブラウザ：「イントラネットゾーンだ。自動認証OK」
結果：パスワード入力なしでアクセス成功

ケース2：
田中：「http://192.168.1.20/ にアクセス」（同じサーバー）
ブラウザ：「IPアドレスか...インターネットゾーンとして扱う」
結果：認証ダイアログが表示される

田中：「同じサーバーなのになんで！？」

では、この「セキュリティゾーン」とは何でしょうか？Windowsには、アクセス先の信頼度に応じて4つのゾーンが定義されています。この仕組みはInternet Explorer時代に設計されましたが、現在も「インターネットオプション」としてWindowsに残っており、Edgeの動作にも影響を与えています。つまり、Windows環境でブラウザ認証を理解するには、この古くからある仕組みを避けて通れないのです。

【Windowsのセキュリティゾーン】
IT管理者：「Windowsには4つのセキュリティゾーンがあり、EdgeやChromeの認証動作に影響します」

1. インターネットゾーン（最も制限が厳しい）
   - 一般的な外部Webサイト
   - 統合Windows認証は無効

2. イントラネットゾーン（社内向け）
   - 社内サーバー
   - 統合Windows認証が有効

3. 信頼済みサイト
   - 明示的に信頼したサイト
   - カスタム設定可能

4. 制限付きサイト
   - 危険なサイト
   - 最も厳しい制限

新人：「どうやって判定してるんですか？」

では、ブラウザはどうやって「これはイントラネットだ」と判定しているのでしょうか？

実は、いくつかの明確なルールが存在します。このルールを知っておくと、「なぜこのURLだと認証ダイアログが出るのに、別のURLだと出ないのか」という疑問がスッキリ解消されます。特に、ドット（.）の有無やIPアドレスかどうかが重要な判定基準になっている点に注目してください。

【自動判定の仕組み】
ブラウザの判定ロジック：

1. ドット（.）を含まない名前
   http://server01/ → イントラネット ✓
   http://server01.jp.qualiteg.com/ → 判定が微妙

2. NetBIOS名
   http://fileserver/ → イントラネット ✓
   
3. UNCパス
   \\server01\share → イントラネット ✓

4. プロキシをバイパスするサイト
   プロキシ例外リストに含まれる → イントラネット ✓

5. IPアドレス
   http://192.168.1.20/ → インターネット ✗
   （ただし、設定で変更可能）

「理屈は分かったけど、実際に自分のアクセス先がどのゾーンに判定されているか確認したい」という方も多いでしょう。残念ながら、現在のEdgeにはゾーンを直接表示する機能がありませんが、いくつかの方法で確認することができます。トラブルシューティングの際にも役立つので、覚えておくと便利です。

【どのゾーンか確認する方法】
方法1：インターネットオプションで確認
コントロールパネル → インターネットオプション → セキュリティタブ
→ 各ゾーンの「サイト」ボタンで登録されているサイトを確認

方法2：イントラネットゾーンの自動判定設定を確認
インターネットオプション → セキュリティ → ローカルイントラネット → サイト
□ イントラネットのネットワークを自動的に検出する
□ プロキシサーバーを使用しないサイトをすべて含める
□ すべてのネットワークパス(UNC)を含める

方法3：レジストリで確認（上級者向け）
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap
→ 各サイトがどのゾーンに属するか確認可能

5.1.2 URLの形式による認証動作の違い

同じサーバーでも、URLの書き方によって認証動作が変わります。これは、システム管理者でも見落としがちな重要なポイントです。

「同じサーバーなのになぜ？」という疑問をさらに深掘りしてみましょう。実際に、同一のファイルサーバーに対して4種類の異なるURL形式でアクセスした場合、それぞれどのような認証動作になるかを実験してみます。この違いを理解しておくと、ユーザーからの「なぜ認証を求められるのか」という問い合わせに的確に回答できるようになります。

【URL形式と認証の関係】
実験：同じファイルサーバーに異なるURLでアクセス

1. NetBIOS名でアクセス
URL: http://fs01/share
ブラウザ：「イントラネットゾーン。Kerberosで自動認証」
結果：シームレスにアクセス

2. FQDNでアクセス
URL: http://fs01.jp.qualiteg.com/share
ブラウザ：「ドットが含まれる...でもローカルドメイン」
結果：設定次第（デフォルトは認証ダイアログ）

3. IPアドレスでアクセス
URL: http://192.168.1.50/share
ブラウザ：「IPアドレスはインターネットゾーン」
結果：認証ダイアログ表示

4. 外部ドメイン名でアクセス
URL: http://fs01.external.com/share
ブラウザ：「外部ドメイン。インターネットゾーン」
結果：認証ダイアログ（統合認証は無効）

ここで、なぜIPアドレスでのアクセスだと認証がうまくいかないのか、技術的な背景を説明しておきましょう。これはKerberos認証の仕組みに起因しています。Kerberosは「サービスの名前」でチケットを発行する仕組みのため、IPアドレスという「番号」ではチケットを要求できないのです。この制約を知っておくと、「なぜ名前でアクセスしてください」とユーザーにお願いするのか、その理由を説明できるようになります。

【なぜIPアドレスではKerberosが使えないか】
IT管理者：「Kerberosにはサーバーの『名前』が必要なんです」

Kerberosの仕組み：
1. クライアント：「HTTP/fs01.jp.qualiteg.com のチケットください」
2. KDC（Key Distribution Center）：「SPN（Service Principal Name）を検索...」
3. KDC：「見つかった！チケット発行」

IPアドレスの場合：
1. クライアント：「HTTP/192.168.1.50 のチケットください」
2. KDC：「そんなSPNは登録されてない」
3. 結果：Kerberos失敗 → NTLMにフォールバック

開発者：「だからIPアドレスだと遅いんだ...」

さて、ここまででゾーンの概念とURLの関係を理解いただけたかと思います。次に、実際の各ブラウザがどのように動作するかを確認しましょう。同じ社内サイトにアクセスしても、ブラウザによって「すんなり入れる」「パスワードを聞かれる」と動作が異なります。これは各ブラウザの設計思想の違いによるもので、特にChromeとFirefoxはデフォルトで統合認証が無効になっている点に注意が必要です。

【各ブラウザでの動作】
テストシナリオ：http://intranet/ にアクセス

Microsoft Edge:
- インターネットオプションの設定を継承
- イントラネットゾーンなら統合Windows認証が自動実行
- 基本的に追加設定不要

Google Chrome:
- デフォルトでは認証ダイアログが表示
- グループポリシーまたは起動オプションで設定が必要
- --auth-server-whitelist="*.jp.qualiteg.com"

Mozilla Firefox:
- デフォルトでは認証ダイアログが表示
- about:config での設定が必要
- network.negotiate-auth.trusted-uris

Edge（IEモード）:
- レガシーな社内システム向けの互換機能
- 完全なIE互換が必要な場合のみ使用
- 通常のEdgeで問題なければ不要

5.1.3 ブラウザごとの設定方法

各ブラウザで統合Windows認証を有効にする具体的な設定方法を見ていきましょう。

まずはMicrosoft Edgeから。EdgeはMicrosoftが開発しているだけあって、Windowsとの親和性が高く、多くの場合は追加設定なしで統合Windows認証が動作します。Edgeは「インターネットオプション」の設定を継承するため、Windowsの設定が正しければそのまま使えるのが大きなメリットです。ただし、念のため設定を確認しておきたい場合や、期待通りに動作しない場合のチェックポイントを押さえておきましょう。

【Microsoft Edgeの設定】
最も簡単 - 多くの場合、デフォルトで動作

Edgeはインターネットオプションの設定を継承するため、
Windowsの設定が正しければ追加設定は不要です。

確認手順：
1. コントロールパネル → インターネットオプション
2. セキュリティタブ
3. 「ローカル イントラネット」を選択
4. 「レベルのカスタマイズ」

重要な設定項目：
- ユーザー認証
  └ログオン
    ○ イントラネット ゾーンでのみ自動的にログオンする ← デフォルト
    ○ 現在のユーザー名とパスワードで自動的にログオンする
    ○ ユーザー名とパスワードを入力してログオンする

IT管理者：「通常はデフォルトのままでOKです」

Edgeの追加設定（必要な場合）：
edge://settings/profiles/sync → 仕事用プロファイルの確認
edge://policy/ → 適用されているポリシーの確認

次はGoogle Chromeです。Chromeは社内でも利用者が多いブラウザですが、統合Windows認証についてはデフォルトで無効になっています。そのため、「Chromeだと毎回パスワードを聞かれる」という問い合わせがヘルプデスクに殺到することも珍しくありません。設定方法は複数ありますが、企業環境ではグループポリシーでの一括設定が最も効率的です。テスト目的であれば、起動オプションやレジストリ編集でも対応可能です。

【Google Chromeの設定方法】
問題：
ユーザー：「Chromeだと毎回パスワード聞かれる！」
IT管理者：「Chromeは追加設定が必要です」

方法1：グループポリシー（推奨）
場所：コンピューターの構成 → 管理用テンプレート → 
      Google → Google Chrome → 認証

設定項目：
1. 統合Windows認証を許可するサーバーのリスト
   値：*.jp.qualiteg.com, intranet

2. Kerberos委任を許可するサーバーのリスト
   値：*.jp.qualiteg.com

GPO適用後：
gpupdate /force
Chrome再起動

方法2：レジストリ直接編集
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"AuthServerAllowlist"="*.jp.qualiteg.com"
"AuthNegotiateDelegateAllowlist"="*.jp.qualiteg.com"

方法3：起動オプション（テスト用）
chrome.exe --auth-server-whitelist="*.jp.qualiteg.com" 
          --auth-negotiate-delegate-whitelist="*.jp.qualiteg.com"

Firefoxユーザーも忘れてはいけません。開発者やデザイナーを中心に、Firefoxを愛用している方は一定数いらっしゃいます。Firefoxの場合は、about:configという設定画面で直接パラメータを編集する必要があります。少し上級者向けの操作になりますが、一度設定してしまえば快適に使えるようになります。なお、企業環境では後述するグループポリシーや設定ファイルの配布で一括設定することも可能です。

【Mozilla Firefoxの設定方法】
Firefoxユーザー：「Firefoxでも統合認証使いたい」
IT管理者：「about:configで設定します」

手順：
1. アドレスバーに about:config 入力
2. 警告を承諾
3. 以下の設定を検索・編集

必要な設定：
network.negotiate-auth.trusted-uris
値：.jp.qualiteg.com, intranet

network.negotiate-auth.delegation-uris  
値：.jp.qualiteg.com

network.automatic-ntlm-auth.trusted-uris
値：.jp.qualiteg.com, intranet

補足設定：
network.negotiate-auth.allow-non-fqdn
値：true（NetBIOS名を許可）

network.automatic-ntlm-auth.allow-non-fqdn
値：true

確認：
設定後、Firefoxを再起動して http://intranet/ にアクセス
→ パスワード入力なしでアクセスできれば成功

最後に、Edgeの詳細設定とIEモードについても触れておきましょう。「基本的に追加設定不要」と説明しましたが、細かい制御が必要な場合や、レガシーな社内システムとの互換性が必要な場合は、グループポリシーやIEモードを活用することになります。特にIEモードは、古いActiveXコントロールを使用するシステムなど、最新のEdgeでは動作しないアプリケーション向けの機能です。新規システムでは使用する必要はありませんが、移行期間中は重宝する場面もあるでしょう。

【Microsoft Edgeの詳細設定とIEモード】
Edge利用者：「EdgeでもChromeと同じような設定はあるの？」
IT管理者：「はい、グループポリシーで細かく制御できます」

Edgeのポリシー設定：
edge://policy/ で確認できる設定：
- AuthServerAllowlist（認証サーバーの許可リスト）
- AuthNegotiateDelegateAllowlist（Kerberos委任の許可リスト）

グループポリシーでの設定：
コンピューターの構成 → 管理用テンプレート → 
Microsoft Edge → HTTP認証

IEモード（レガシーシステム向け）：
古い社内システムがEdgeで正常動作しない場合のみ使用

設定方法：
1. IEモードサイトリストを作成（XML形式）
   <site url="legacy.jp.qualiteg.com">
     <open-in>IE11</open-in>
   </site>

2. グループポリシーで配布
   - IEモードを有効化
   - サイトリストのURL指定

注意：IEモードは互換性のための機能です。
新しいシステムでは通常のEdgeを使用してください。

5.2 Chrome/Firefoxでの課題と対策

5.2.1 なぜChromeでは自動認証が動作しないか

ChromeやFirefoxでデフォルトで統合Windows認証が動作しない理由は、セキュリティとクロスプラットフォーム対応にあります。

「なぜEdgeだと何もしなくても自動認証できるのに、Chromeだとダメなの？」——これは非常によくある疑問です。答えは、それぞれのブラウザの設計思想と開発元の違いにあります。MicrosoftはWindowsというOSも開発しているため、EdgeとWindowsは密接に連携するよう設計されています。一方、GoogleのChromeはWindows、Mac、Linuxなど複数のOSで動作することを前提に設計されているため、Windows固有の機能はオプション扱いになっているのです。

【根本的な理由】
開発者：「なんでEdgeは自動認証できて、Chromeはできないの？」
IT管理者：「それぞれの設計思想の違いです」

Microsoft Edge：
- Microsoftが開発
- Windowsと密結合
- 企業内利用を想定
- インターネットオプションを継承
- デフォルトで統合認証ON

Google Chrome：
- Googleが開発  
- クロスプラットフォーム（Windows/Mac/Linux）
- インターネット利用を前提
- Windows固有の設定に依存しない設計
- デフォルトで統合認証OFF

セキュリティ専門家：「デフォルトOFFの方が安全ではある」

実は、Chromeがデフォルトで統合認証を無効にしているのには、セキュリティ上の理由もあります。もし無条件で自動認証が有効だったら、悪意のあるサイトに対してもユーザーの認証情報（NTLMハッシュなど）を送信してしまう可能性があるのです。「面倒だな」と感じるかもしれませんが、これは意図的なセキュリティ設計であることを理解しておきましょう。

【なぜデフォルトで無効なのか】
シナリオ：悪意のあるサイトの場合

悪意のあるサイト：「私は intranet.evil.com です」

もしデフォルトで有効だったら：
ブラウザ：「intranetという名前...自動認証します」
ブラウザ→悪意のサイト：「私は JP\tanaka です」（NTLMハッシュ付き）
悪意のあるサイト：「認証情報ゲット！」

だから：
Chrome：「明示的に信頼されたサイトのみ自動認証」
ユーザー：「面倒だけど安全なのか...」

もう少し技術的な観点から、ブラウザのアーキテクチャの違いも見ておきましょう。EdgeはWindowsのWinINet/WinHTTP APIを使用しており、Windowsの認証サブシステムと直接連携しています。一方、Chromeは独自のネットワークスタックを持っており、Windows固有の機能を使うかどうかは明示的な設定に依存しています。これがコードレベルでどのような違いになるか、イメージで示してみます。

【ブラウザアーキテクチャの違い】
Edge の実装：
- WinINet/WinHTTP API を使用
- Windowsの認証サブシステムと直結
- SSPIを直接呼び出し
- インターネットオプションの設定を参照

Chromeの実装：
- 独自のネットワークスタック
- クロスプラットフォーム前提
- Windows固有機能はオプション扱い

具体例：
// Edgeの内部（イメージ）
if (IsIntranetZone(url)) {
    UseWindowsAuthentication();
}

// Chromeの内部（イメージ）  
if (IsInWhitelist(url) && IsPlatformWindows()) {
    UseWindowsAuthentication();
}

5.2.2 グループポリシーでの設定

企業環境では、グループポリシーを使用してChromeやEdgeの設定を一括管理するのが最も効率的です。

数台のPCであれば手動設定でも対応できますが、数十台、数百台となると現実的ではありません。Active Directory環境であれば、グループポリシー（GPO）を使って全社のPCに一括で設定を配布できます。一度設定してしまえば、新しいPCがドメインに参加した際も自動的に設定が適用されるため、運用負荷を大幅に削減できます。

まずは、Chromeのグループポリシー設定に必要なADMXテンプレートの準備から始めましょう。ADMXテンプレートとは、グループポリシーエディターでChrome固有の設定項目を表示するために必要なファイルです。GoogleがEnterprise Bundle として公開しているので、ダウンロードしてActive Directoryサーバーに配置します。

【GPO設定の準備】
IT管理者：「まず、Chrome用のADMXテンプレートが必要です」

手順：
1. GoogleのEnterprise Bundleをダウンロード
   https://chromeenterprise.google/browser/download/

2. ADMXファイルをコピー
   chrome.admx → C:\Windows\PolicyDefinitions\
   chrome.adml → C:\Windows\PolicyDefinitions\ja-JP\

3. グループポリシー管理エディターで確認
   コンピューターの構成 → 管理用テンプレート → Google → Google Chrome
   
IT管理者：「これで準備完了」

※Edge用のADMXテンプレートも同様に入手可能
   https://www.microsoft.com/ja-jp/edge/business/download

ADMXテンプレートの準備ができたら、実際に認証関連のポリシーを設定していきましょう。主に設定するのは「統合Windows認証を許可するサーバーのリスト」と「Kerberos委任を許可するサーバーのリスト」の2つです。ワイルドカード（*.jp.qualiteg.com）を使うことで、サブドメインも含めて一括で許可できます。

【認証関連のポリシー設定】
グループポリシー管理エディターで設定：

■ Chrome の設定
パス：Google Chrome → 認証

1. 認証サーバーの許可リスト
設定名：統合Windows認証を許可するサーバーのリスト
値：
*.jp.qualiteg.com
intranet
intranet.jp.qualiteg.com
*.internal.jp.qualiteg.com

2. Kerberos委任の許可リスト
設定名：Kerberos委任を許可するサーバーのリスト
値：*.jp.qualiteg.com

■ Edge の設定（必要な場合）
パス：Microsoft Edge → HTTP認証

同様の設定項目が用意されています。
Edgeはインターネットオプションを継承するため、
通常は追加設定不要です。

確認コマンド：
gpresult /h report.html
→ 適用されたポリシーを確認

GPOを設定したら、実際にユーザーのPCに適用されるまでの流れを確認しておきましょう。通常、グループポリシーはバックグラウンドで定期的に更新されますが、すぐに反映させたい場合はgpupdate /forceコマンドを実行します。ユーザーにとっては、「昨日までパスワードを聞かれていたのに、今日はスムーズにアクセスできる」という体験になります。

【GPO適用後の動作】
翌朝、ユーザーのPC：
田中：「いつも通りChromeを起動」
Chrome：「グループポリシーを読み込み中...」
Chrome：「*.jp.qualiteg.comは信頼済みサイトとして登録」

田中：「http://intranet/ にアクセス」
Chrome：「このサイトは許可リストに含まれる」
Chrome：「統合Windows認証を実行」
結果：パスワード入力なしでアクセス成功！

田中：「あれ？昨日まで聞かれてたのに...IT部門が何かしたな」

GPOを設定したはずなのに反映されない、というケースも時々発生します。そんな時のためのトラブルシューティング手順を押さえておきましょう。まずはブラウザのポリシー確認ページ（chrome://policy/ や edge://policy/）で、設定が実際に適用されているかを確認します。適用されていない場合は、OUの構造、GPOのリンク、セキュリティフィルタリングなどを順番にチェックしていきます。

【GPOが適用されない場合】
確認手順：

1. クライアントPCでポリシー確認
Chrome: chrome://policy/
Edge: edge://policy/
→ 設定されたポリシーが表示される

2. 未適用の場合
gpupdate /force
→ グループポリシーを強制更新

3. それでもダメなら
- OU構造の確認（PCが正しいOUに所属？）
- GPOのリンク確認
- セキュリティフィルタリング確認
- WMIフィルター確認

4. ブラウザのログ確認
Chrome: chrome://net-export/
Edge: edge://net-export/
→ ネットワークログをキャプチャ
→ 認証関連のエラーを検索

5.2.3 Basic認証の課題（パスワード保存）

統合Windows認証が使えない環境では、Basic認証にフォールバックしますが、これには独自の課題があります。

在宅勤務やBYOD（私物デバイス）の普及により、ドメインに参加していないPCから社内システムにアクセスするケースが増えています。このような環境では統合Windows認証が使えないため、Basic認証（ユーザー名とパスワードを入力する方式）にフォールバックすることになります。ここで問題になるのが、ブラウザの「パスワードを保存する」機能です。

【Basic認証の動作】
在宅勤務の山田：「自宅のPCからプロキシ経由でアクセス」
プロキシ：「認証が必要です」
Chrome：「統合認証は使えない...Basic認証のダイアログ表示」

認証ダイアログ：
┌─────────────────────────┐
│ proxy.jp.qualiteg.com:8080 でユーザー名と │
│ パスワードが必要です                      │
│                                          │
│ ユーザー名: [JP\yamada_h        ]        │
│ パスワード: [****************    ]        │
│                                          │
│ □ パスワードを保存する                    │
└─────────────────────────┘

山田：「毎回入力は面倒...保存しちゃえ」

「パスワードを保存する」は便利な機能ですが、企業のセキュリティポリシー上は大きなリスクとなります。特に、共用PCでの認証情報の漏洩、ブラウザの同期機能による意図しないクラウドへのアップロード、マルウェアによるパスワード窃取など、複数のリスクシナリオが考えられます。これらのリスクを具体的に見ていきましょう。

【保存されたパスワードの問題】
セキュリティ監査：「Basic認証のパスワード保存は危険です」

リスク1：共用PCでの漏洩
営業A：「客先のPCでパスワード保存」
営業B：「同じPCを使用...前の人のアカウントでアクセスできる！」

リスク2：ブラウザの同期機能
個人のGoogleアカウントで同期ON
→ 会社のパスワードが個人のクラウドに保存
→ 自宅のPCにも同期される

リスク3：マルウェアによる窃取
chrome://settings/passwords
edge://settings/passwords
→ 保存されたパスワードが見える
→ マルウェアが収集する標的に

では、組織としてどのような対策を講じればよいでしょうか？技術的な制限、プロキシ側の設定、代替認証方式の提供など、複数のアプローチがあります。グループポリシーでパスワード保存機能自体を無効化するのが最も確実ですが、ユーザビリティとのバランスも考慮する必要があります。

【パスワード保存を防ぐ方法】
方法1：技術的な制限（グループポリシー）
Chrome GPO：
パスワード管理ツールを有効にする → 無効

Edge GPO：
パスワードの保存を有効にする → 無効

結果：パスワード保存オプションが表示されない

方法2：プロキシ側の設定
# 短いセッションタイムアウト
auth_param basic credentialsttl 30 minutes
→ 頻繁に再認証が必要 = 保存の意味が薄い

方法3：代替認証方式の提供
- VPN + 統合認証
- クライアント証明書
- ワンタイムパスワード

5.2.4 実用的な解決策

現実的な運用では、セキュリティと利便性のバランスを取った解決策が必要です。

「すべてのアクセスを統合Windows認証で」というのが理想ですが、現実にはリモートワークの常態化、個人デバイスの利用増加、多様なブラウザ環境など、様々な制約があります。そこで重要になるのが、アクセス元の環境に応じて認証方式を使い分ける「段階的なアプローチ」です。

【段階的なアプローチ】
IT部門の方針：
「理想」と「現実」のギャップを埋める

理想：すべて統合Windows認証
現実：
- 個人デバイスの利用増加
- リモートワークの常態化  
- 多様なブラウザ利用

段階的解決策：
1. 社内ネットワーク → 統合認証（GPO強制）
2. VPN接続 → 統合認証（可能な限り）
3. 外部アクセス → 別の認証方式

具体的に、プロキシサーバー側でどのように認証方式を使い分けるかの設定例を見てみましょう。社内ネットワークからのアクセスには統合認証を、外部からのアクセスにはHTTPS必須のBasic認証を適用するという構成です。これにより、社内ユーザーの利便性を確保しつつ、外部アクセスのセキュリティも担保できます。

【認証方式の使い分け】
プロキシ設定例：
# 社内ネットワークからのアクセス
acl internal_network src 192.168.0.0/16
acl internal_network src 10.0.0.0/8

# 認証方式の定義
# 1. 統合認証（社内向け）
auth_param negotiate program /usr/lib/squid/negotiate_wrapper_auth
auth_param negotiate children 10

# 2. Basic認証（外部向け、HTTPS必須）
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic realm "External Access - HTTPS Required"

# アクセス制御
# 社内：統合認証
http_access allow internal_network authenticated

# 外部：HTTPSでのみBasic認証許可
acl HTTPS proto HTTPS
http_access allow HTTPS authenticated
http_access deny !HTTPS

技術的な対策と同様に重要なのが、ユーザーへの教育です。どんなに優れたセキュリティ対策も、ユーザーが適切に利用しなければ効果を発揮しません。IT部門からの明確なガイドラインを提示し、なぜそのルールが必要なのかを理解してもらうことが大切です。

【セキュリティ意識向上の取り組み】
IT部門からの通知：

件名：Chrome/Edge/Firefoxでの認証についてのお知らせ

1. 社内PCでの利用
   - IT部門が設定済み
   - パスワード入力不要
   - そのままご利用ください

2. 個人PC/在宅勤務での利用
   - VPN接続を推奨
   - やむを得ずBasic認証を使用する場合：
     * パスワードを保存しない
     * HTTPSのサイトのみアクセス
     * 定期的にパスワード変更

3. セキュリティのヒント
   - 共用PCでは絶対に保存しない
   - ブラウザの同期機能に注意
   - 不審な認証要求は IT部門に報告

問い合わせ：IT部門（内線: 1234）

より高度な対策として、IT部門公認のブラウザ拡張機能を活用する方法もあります。企業が開発または選定した拡張機能を使うことで、認証情報を暗号化して安全に管理できます。ただし、拡張機能自体のセキュリティ審査や、ユーザーへの展開方法など、運用面での考慮事項も多いため、導入には十分な検討が必要です。

【ブラウザ拡張機能の活用】
IT部門公認の拡張機能：

1. 認証情報管理拡張
- 企業が開発/選定
- ローカルで暗号化保存
- マスターパスワードで保護

実装例（概念）：
chrome.webRequest.onAuthRequired.addListener(
  function(details, callback) {
    // 信頼されたサイトか確認
    if (isTrustedSite(details.url)) {
      // 暗号化されたストレージから認証情報取得
      const creds = getEncryptedCredentials(details.url);
      callback({
        authCredentials: {
          username: creds.username,
          password: decrypt(creds.password)
        }
      });
    }
  },
  {urls: ["<all_urls>"]},
  ["asyncBlocking"]
);

2. SSO連携拡張
- SAMLやOAuth連携
- 別の認証基盤を利用

最後に、将来を見据えた対策についても触れておきましょう。パスワードに関する問題を根本的に解決するには、パスワードレス認証への移行が有効です。Windows Hello for Business、FIDO2/WebAuthn、証明書ベース認証など、複数の選択肢があります。すぐに全社展開するのは難しいかもしれませんが、パイロットユーザーでの検証から始めて、段階的に移行していく計画を立てておくことをお勧めします。

【パスワードレス認証への移行】
IT戦略会議：
CTO：「パスワード関連の問題を根本的に解決したい」
セキュリティ担当：「パスワードレス認証を検討しましょう」

選択肢：
1. Windows Hello for Business
   - 生体認証やPIN
   - Kerberosチケット取得
   - パスワード不要

2. FIDO2/WebAuthn
   - セキュリティキー使用
   - フィッシング耐性
   - クロスプラットフォーム

3. 証明書ベース認証
   - クライアント証明書
   - スマートカード
   - 管理は複雑

移行計画：
Phase 1：パイロットユーザーで検証
Phase 2：IT部門で本格導入  
Phase 3：全社展開

CTO：「3年後にはパスワードを廃止したい」

これらの対策により、Edge/Chrome/Firefoxユーザーも安全かつ便利に認証を利用できるようになります。重要なのは、技術的な対策だけでなく、ユーザー教育と段階的な移行計画です。

今回のまとめ

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

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

次回予告：第6章 トラブルシューティング - よくある問題と解決方法

次回は、統合Windows認証環境で発生しがちなトラブルとその解決方法を詳しく解説します！

「Kerberosが失敗してNTLMにフォールバックする」「時刻が5分ずれただけで認証できない」「SPNって何？どう設定するの？」「ドメインが見つからないエラーが出る」——これらは現場で必ず遭遇する問題です。

診断コマンドの使い方から、DNS・SPN・時刻同期といった根本原因の特定方法、そして具体的な解決手順まで、実践的なトラブルシューティングガイドをお届けします。

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

こんにちは！

「このパズル、AIの教科書に載ってるらしいよ」

子供の頃に遊んだスライドパズル。いや、大人が遊んでも楽しいです。

数字のタイルをカチャカチャ動かして揃えるあれです。実はこのシンプルなパズルが、AI研究の出発点のひとつだったって知ってました？

今回は、このパズルを題材に「AIがどうやって考えているのか」を解き明かしていきます。しかも、ここで使われている手法は、Google Mapsの経路探索からChatGPTまで、現代の様々な技術のベースになっているんです。

まず遊んでみよう

理屈の前に、まずは感覚を思い出してみてください。

最初に shuffle をクリックすると、配置がシャッフルされゲームを開始できます。

ちなみに必ず解くことができるようになっていますが、慣れていないとそれなりに難しいかもしれません。

どうでしょう？

何手でクリアできましたか？

クリアできなくても大丈夫です。記事後半で、実際にAIが解いてくれる機能つきゲームも掲載しています＾＾

以下は動画です。本ブログで紹介するアルゴリズムで実際にパズルを解く様子をご覧いただけます

解いているとき、何を考えていました？おそらく「なんとなく」「端から順番に」「パターンで覚えてる」といった感じではないでしょうか。

実は、この「なんとなく」の正体を数学的に解き明かしたのが、AI研究の出発点のひとつだったんです。

人間はどう解いているのか

人間がパズルを解くとき、だいたいこんなことをしています。

これは非常に「局所的」なアプローチですよね。全体の最短経路を計算しているわけではなく、目の前の問題を一つずつ解決している。人間の脳はこういった直感的な処理が得意で、それなりにうまく解けます。

では、コンピュータはどうアプローチするのでしょうか？

AIの見方：世界を「状態」で捉える

コンピュータは15パズルをこう捉えます。

なぜ「状態」で考えるのか？

ここで重要なのは、問題を「状態の遷移」として捉え直すという発想です。

人間は「タイルを動かす」と考えますが、
コンピュータは「ある配置から別の配置に移る」と考えます。

この視点の転換がなぜ重要かというと、問題がグラフ理論の枠組みで扱えるようになるからです。

グラフ理論とは、点（ノード）と線（エッジ）の関係を研究する数学の分野です。パズルの各配置を「点」、1手で移動できる関係を「線」と見なせば、パズルを解くことは「スタート地点からゴール地点への経路を見つける」という、数学的によく研究された問題に変換できます。

つまり、過去何十年にもわたって蓄積されてきた経路探索のアルゴリズムが、そのまま使えるようになるわけです。これが「状態空間探索」というアプローチの強みです。

状態空間の構造

これを図で表すと、状態が枝分かれしていく「木」のような構造になります。

1手で約2〜4通りの状態に分岐します。2手で最大16通り、3手で最大64通り...と、可能性が指数的に広がっていきます。

この「状態の木」のどこかにゴールがあります。コンピュータの仕事は、その経路を見つけることなんです。

ここで「指数的に増える」という表現が出てきました。これは「手数が1増えるごとに、調べる状態が何倍にもなる」という意味です。たとえば毎手4倍になるとすると、10手で約100万、20手で約1兆になります。この爆発的な増加が、パズルを解く難しさの本質です。

解けない配置が存在する！？

ここで面白い事実を紹介しましょう。

15パズルには、どれだけ頑張っても絶対に解けない配置が存在します。

これは1880年代にアメリカで大流行したパズルで、

「解けたら賞金！」

という懸賞が出されたんですが、誰も解けませんでした。後に数学者が「そもそも解が存在しない」ことを証明して決着がついたという歴史があります。

なぜ解けないのか：転倒数（Inversion Count）

判定方法は「転倒数」という概念を使います。

転倒数とは、タイルを順番に見ていったとき、「後ろにあるべき数字が前にある」ペアの数のことです。

なぜ転倒数で判定できるのか？

これは少し数学的な話になりますが、直感的に説明してみましょう。

タイルを1回スライドさせると、転倒数は必ず奇数個だけ変化します（1増えるか、1減るか、あるいは±3など）。つまり、転倒数の「偶奇」（偶数か奇数か）は、1手ごとに必ず入れ替わります。

ゴール状態の転倒数は0（偶数）です。ということは、偶数回の操作でしか到達できません。もし初期状態の転倒数が奇数なら、何回操作しても偶数にはならないので、ゴールには絶対に到達できないってことになりますよね。

これは「不変量（invariant）」と呼ばれる考え方で、システムがどう変化しても保存される性質を見つけることで、到達可能性を判定できます。

今回作ったゲームも、裏側でこの判定を行い、必ず解ける配置だけを生成しています。プログラムで「解けない問題を出さない」ようにしているわけですね。

力任せ vs 賢く探す

さて、解ける配置だとわかったら、どうやって解を見つけるでしょうか。

幅優先探索（BFS: Breadth-First Search）：全部試す方法

最も単純な方法は「幅優先探索」です。

BFSのアルゴリズム

BFSの動きをもう少し詳しく説明しましょう。

BFSは「近い順に全部調べる」という戦略です。まず1手で行けるところを全部調べ、次に2手で行けるところを全部調べ...と、距離（手数）の近い順に探索を進めます。

この方法の最大の利点は、最短経路が保証されることです。なぜなら、5手で到達できる状態は、必ず4手以下の状態をすべて調べた後に見つかるからです。つまり、ゴールを最初に見つけた瞬間、それが最短経路だと確定します。

しかし、この「全部調べる」というのが曲者です。15パズルの場合、20手先まで調べようとすると、約1兆個の状態を調べる必要があります。1秒間に100万個の状態を調べられるコンピュータでも、約12日かかる計算です。

これでは実用的ではありませんよね。。

A*探索（A-star Search）：賢い勘を使う

ここで登場するのが「A*（エースター）探索」です。1968年にスタンフォード大学のPeter Hart、Nils Nilsson、Bertram Raphaelによって発明されたこのアルゴリズムは、「賢い勘」を使って探索範囲を絞り込みます。

A*の基本アイデア

BFSは「手数の少ない順」に探索しました。A*は、これを「ゴールに早く着きそうな順」に変えます。

「ゴールに早く着きそう」かどうかを判断するために、A*は2つの情報を組み合わせます。

• g(n): スタートからここまで実際に何手かかったか（確定値）
• h(n): ここからゴールまであと何手くらいかかりそうか（推定値）
• f(n): 合計すると、この経路でゴールまで何手くらいかかりそうか

A*は、この f(n) が小さい状態から優先的に探索します。つまり、「全体として手数が少なく済みそうな方向」を優先するわけです。

なぜこれが賢いのか？

BFSが「円形に広がる波」だとすると、A*は「ゴールに向かって伸びる楕円」のようなイメージです。

この例では、状態Bの f(n) が9で最小なので、Bを優先的に展開します。AやCは後回しです。もしBの先にゴールがあれば、AやCは調べずに済みます。

これがA*の「賢さ」の本質です。ゴールに近そうな方向を先に調べることで、無駄な探索を大幅にカットできるのです。

ヒューリスティック関数：「勘」を数値化する

A*の性能は、h(n) をどう計算するかにかかっています。この h(n) を計算する関数を「ヒューリスティック関数」と呼びます。

「ヒューリスティック（heuristic）」とは、「発見的な」「経験則に基づく」という意味です。

最適解を保証するわけではないが、多くの場合うまくいく「賢い推測」のことです。

良いヒューリスティックの条件

ヒューリスティック関数には、重要な条件があります。

1. 計算が速いこと: 何百万回も計算するので、1回の計算に時間がかかると台無しです
2. ゴールに近いほど小さい値を返すこと: そうでないと優先順位が正しくつけられません
3. 許容的（Admissible）であること: 実際のコストを過大評価しないこと

特に3つ目の「許容的」という性質が重要です。これについては後で詳しく説明します。

マンハッタン距離：15パズルの「勘」

15パズルでよく使われるヒューリスティック関数が「マンハッタン距離」です。

マンハッタン距離とは？

マンハッタン距離は、碁盤の目状の道を歩くときの距離です。

ニューヨークのマンハッタン島は道路が格子状になっているので、斜めには歩けません。この「縦か横にしか進めない」ときの距離がマンハッタン距離です。

通常の直線距離（ユークリッド距離）と比較してみましょう。

15パズルでは、タイルは上下左右にしか動けないので、マンハッタン距離がぴったり当てはまります。

15パズルでの計算方法

各タイルについて、「今いる場所」と「あるべき場所」のマンハッタン距離を計算し、全部足し合わせます。

なぜマンハッタン距離が優れているのか？

マンハッタン距離が15パズルに適している理由は3つあります。

1. 計算が高速: 各タイルの座標を引き算して足すだけなので、一瞬で計算できます
2. 直感的に正しい: タイル5が2マス離れていたら、最低でも2回は動かさないと正しい位置に置けません。これは当たり前ですよね
3. 許容的である: ここが重要です。マンハッタン距離は「最低でもこれだけは必要」という下限を示します。実際には他のタイルが邪魔になってもっと手数がかかることが多いですが、過大評価することは絶対にありません

許容的（Admissible）であることの重要性

ヒューリスティック関数が「許容的」であるとは、実際のコストを過大評価しないことを意味します。

なぜ過大評価してはいけないのか？

もし h(n) が実際のコストより大きい値を返すと、「この経路はコストが高そうだ」と誤解して、本当は最短の経路を後回しにしてしまう可能性があります。その結果、最短ではない経路を「最短だ」と誤って返してしまうことがあるのです。

逆に、過小評価する分には問題ありません。「この経路は短そうだ」と思って優先的に調べても、実際に長ければ後から正しい経路が見つかります。

つまり、ヒューリスティック関数は楽観的であるべきなのです。「最低でもこれくらいはかかるだろう」という下限を示すのが正しい使い方です。

マンハッタン距離は許容的

マンハッタン距離は、まさにこの「下限」を示しています。タイル5が位置(0,0)から位置(1,1)に移動するには、最低でも2回の移動が必要です。他のタイルが邪魔をして迂回が必要になることはあっても、2回より少なく移動することは物理的に不可能です。

だから、マンハッタン距離は常に「実際のコスト以下」であり、許容的なんです。

計算量の劇的な違い

実際にどれくらい違うのか見てみましょう。

この図が示すように、BFSは「全方向に均等に広がる円」のように探索しますが、A*は「ゴールに向かって伸びる楕円」のように探索します。ゴールと反対方向の無駄な探索を大幅にカットできるので、これほどの差が生まれるんです。

この手法、どんな技術に使われている？

ここからが本題です。15パズルで使った「状態空間探索」「ヒューリスティック」という手法は、現代の様々なAI技術の基盤になっています。

「AI」とひとくちに言っても、ディープラーニング、機械学習、ルールベースなど様々な技術があります。今回のパズルで使った手法は、どこに位置するのでしょうか？

探索ベース vs 学習ベース

AI技術は大きく「探索ベース」と「学習ベース」に分けられます。

探索ベースは、問題の構造が明確に定義できる場合に使います。状態、行動、ゴールが明確で、「正解への道筋を探す」という形式で問題を解きます。今回の15パズル、チェス、経路探索などがこれに当たります。

学習ベースは、大量のデータから「パターン」を学ぶアプローチです。画像認識、音声認識、推薦システムなど、ルールを明示的に書くのが難しい問題に向いています。ディープラーニングやランダムフォレストはこちらに分類されます。

そして現代の最先端のAI（AlphaGoなど）は、両者を組み合わせています。探索の「賢い推定」を、学習によって獲得します。

具体的な応用先

それぞれ詳しく見ていきましょう。

1. Google Maps の経路探索

カーナビやスマホの地図アプリが一瞬で経路を出せるのは、A*探索のおかげです。

地図の場合、ヒューリスティック関数は「目的地への直線距離」です。道路は曲がりくねっていますが、直線距離より短くなることはありません。だから許容的です。

実際のGoogle Mapsはさらに高度な最適化（階層的な探索、事前計算など）を行っていますが、基本的な考え方はA*と同じです。

2. ゲームAI（パスファインディング）

RPGやアクションゲームで、敵キャラクターがプレイヤーを追いかけてくる動き。障害物を避けながら最短経路で近づいてきますよね。これもA*探索です。

ゲーム開発では「パスファインディング」と呼ばれ、UnityやUnreal Engineにも標準で組み込まれています。

3. ロボットの動作計画

ロボットアームがものを掴んで別の場所に置く。この動きを計画するのにも、状態空間探索が使われます。

ロボットの場合、「状態」は関節の角度の組み合わせです。6軸のロボットアームなら、6つの角度を指定すると手先の位置が決まります。「行動」は各関節を少し動かすこと。「ゴール」は目標の位置に手先を持っていくことです。

ただし、ロボットの状態空間は連続的（角度は実数）なので、15パズルのような離散的な問題とは少し違います。RRT*（Rapidly-exploring Random Tree*）やPRM（Probabilistic Roadmap）といった、連続空間に対応したアルゴリズムが使われますが、「ゴールに近そうな方向を優先する」という基本的な考え方は同じです。

4. ChatGPTなどの言語モデル（ビームサーチ）

ここが面白いところです。ChatGPTのような大規模言語モデル（LLM）が文章を生成するとき、「次にどの単語を選ぶか」を決める過程でビームサーチという手法が使われることがあります。

top-k サンプリングとの違い

ここでLLMかいわいで有名な「top-k」という似た用語があるので、違いを整理しておきましょう。

ビームサーチがAと似ているのは、「最も良さそうな候補を優先的に探索する」という点です。Aは最も良い1つを追跡しますが、ビームサーチはk個を並列に追跡することで、「最初の選択が悪くても途中で挽回できる」という柔軟性を持たせています。

【ご参考】Top-Kについては以下 LLMサンプリング解説記事でも触れています

LLMサンプリングにおける3つのペナルティ

[付録]ペナルティの比較 ペナルティタイプ 目的 適用方法 ペナルティの例 Repetition Penalty 特定のトークンやフレーズが繰り返されるのを防ぐ。 過去に生成されたすべてのトークンのログ確率（logits）に対してペナルティを適用する。 例えば、あるトークンがすでに生成された場合、そのトークンのログ確率をペナルティ値で割る（乗算）か、ペナルティ値を引く（減算）。 Frequency Penalty 生成されたトークンの出現頻度に基づいてペナルティを適用し、頻繁に出現するトークンを抑制する。 各トークンが生成された回数に基づいてペナルティを適用する。トークンが出現するたびに、そのトークンの出現確率を低減させる。 トークンが出現するたびに、そのトークンのログ確率をペナルティ値で累積的に割る（乗算）か、ペナルティ値を累積的に引く（減算）。 Presence Penalty すでに生成されたトークンが再度出現するのを防ぐ。 トークンが一度でも生成されたかどうかに基づいてペナルティを適用する。一度生成されたトークンには再出現の際にペナルティが適用さ

Qualiteg BlogQualiteg プロダクト開発部

5. AlphaGo：探索と深層学習の融合

囲碁AI「AlphaGo」は、探索ベースと学習ベースの融合という点で画期的でした。

15パズルでは、マンハッタン距離という「人間が設計したヒューリスティック」を使いました。しかし囲碁のような複雑なゲームでは、良いヒューリスティック関数を人間が設計するのは非常に難しいです。

AlphaGoの革新は、このヒューリスティック関数をニューラルネットワークで自動的に学習したことです。大量の棋譜データと自己対戦から、「この盤面はどちらが有利か」を判断する能力を獲得しました。

つまり、「探索」の枠組みはそのままに、「賢い推定」の部分を深層学習で置き換えたのがAlphaGoなんです。

ディープラーニングやランダムフォレストとの関係は？

「ディープラーニング」や「ランダムフォレスト」は、主に学習ベースのAI技術です。

両者は「競合」ではなく「補完」の関係です。AlphaGoのように組み合わせると、それぞれの強みを活かした強力なシステムが作れます。

まとめ：シンプルなパズルが教えてくれること

AIは魔法ではありません。「状態をどう定義するか」「どう推定するか」という地道な工夫の積み重ねです。

そして、この基本的な考え方は1960年代から変わっていません。最新のAIも、こうした古典的な知恵の上に成り立っているんです。

実際にAIが解く様子を見てみよう

最後に、ここまで説明したアルゴリズムが実際に動く様子を見てください。

「SHUFFLE」でパズルを崩して、「AUTO SOLVE」を押すと、AIが1手ずつ解いていきます。

統計情報の見方

統計情報の見方

難易度を変えると、これらの数値が劇的に変わることがわかるはずです。

難易度別の探索量（目安）

難易度が上がると探索量が指数的に増えていくのがわかります。

これが「計算量の爆発」を体感できる瞬間です。

コード解説：IDA*探索の実装

興味のある人向けに、実際のコードを解説します。このゲームで使っているのは「IDA*（反復深化A*）」というアルゴリズムです。通常のA*より省メモリで、15パズルのような問題に向いています。

IDA*とは何か？

IDAは「Iterative Deepening A」の略で、日本語では「反復深化A*」と呼びます。

通常のAには一つ弱点があります。それはメモリ消費です。Aは「まだ調べていない候補」をすべてメモリに保持する必要があります。15パズルのような巨大な状態空間では、メモリが足りなくなることがあります。

IDA*はこの問題を解決するために、深さ制限付きの探索を繰り返すという戦略を取ります。

なぜこれがうまく機能するのか？

「同じところを何度も探索するのは無駄では？」と思うかもしれません。確かに無駄はあります。しかし、状態空間は指数的に増えるので、最後の反復が全体の計算時間のほとんどを占めます。

たとえば、閾値10で解が見つかるとしましょう。閾値5、6、7、8、9での探索は、閾値10での探索に比べて、合計しても数%程度に過ぎません。なぜなら、探索量は閾値が大きくなるほど指数的に増えるからです。

つまり、「少しの無駄」と引き換えに、「メモリをほとんど使わない」という大きなメリットを得ているのです。

マンハッタン距離（ヒューリスティック関数）

function manhattanDistance(state) {
  let distance = 0;
  for (let i = 0; i < state.length; i++) {
    const tile = state[i];
    if (tile !== 0) {
      // ゴール位置を計算
      const goalRow = Math.floor(tile / 4);
      const goalCol = tile % 4;
      // 現在位置を計算
      const currentRow = Math.floor(i / 4);
      const currentCol = i % 4;
      // 縦横の距離を足す
      distance += Math.abs(goalRow - currentRow) 
               + Math.abs(goalCol - currentCol);
    }
  }
  return distance;
}

各タイルについて「あるべき場所」と「今いる場所」の縦横の差を計算し、全部足し合わせます。空欄（0）は無視します。

このコードのポイントは、タイルの「値」からゴール位置を計算しているところです。たとえばタイル5は、ゴール状態ではインデックス5（2行目の2列目）にあるべきです。5 / 4 = 1（行）、5 % 4 = 1（列）で計算できます。

IDA*のメインループ

function idaStar(startState) {
  let threshold = manhattanDistance(startState); // 初期閾値
  const path = [startState];

  while (true) {
    const result = search(path, 0, threshold);
    
    if (result === 'FOUND') {
      return path; // 解が見つかった
    }
    
    if (result === Infinity) {
      return null; // 解なし
    }
    
    threshold = result; // 閾値を上げて再探索
  }
}

IDA*は「深さ制限付き深さ優先探索」を繰り返します。最初はマンハッタン距離を閾値にして探索し、見つからなければ閾値を上げて再挑戦します。

ここで重要なのは、閾値の更新方法です。search 関数は、閾値を超えた中で最小の f(n) 値を返します。これが次の閾値になります。こうすることで、「ギリギリで諦めた候補」を次の反復で調べることができます。

再帰的な探索

function search(path, g, threshold) {
  const current = path[path.length - 1];
  const f = g + manhattanDistance(current);

  // 閾値を超えたら打ち切り
  if (f > threshold) {
    return f;
  }

  // ゴール判定
  if (isGoal(current)) {
    return 'FOUND';
  }

  let min = Infinity;
  
  // 隣接状態を探索
  for (const neighbor of getNeighbors(current)) {
    path.push(neighbor);
    const result = search(path, g + 1, threshold);
    
    if (result === 'FOUND') {
      return 'FOUND';
    }
    
    if (result < min) {
      min = result;
    }
    
    path.pop(); // バックトラック
  }

  return min;
}

f = g + h が閾値を超えたら、その枝の探索を打ち切ります。これにより、ゴールから遠そうな状態を効率的に枝刈りできます。

path.pop() の部分は「バックトラック」と呼ばれる操作です。「この方向はダメだった」ときに、一歩戻って別の方向を試します。これがIDA*がメモリを節約できる理由です。探索候補をすべて保持するのではなく、「今いる経路」だけを保持すればいいです。

おまけ：3×3＋1 絵合わせパズルも解いてみよう！

さて、ここまで読んでくれた人へのおまけです。

スライドパズルには、もう一つよく見る形がありますよね。上に1マスの空欄があって、下に3×3の絵が配置されているタイプ。お土産屋さんとかでよく見かけるあれです。

たいてい子供用にディズニーなどのかわいいキャラクターが描かれています。

解法は同じ？

はい、基本的に同じIDA*探索で解けます！

違いは「隣接関係」の定義だけです。

計算量の違い

状態数の比較

3×3＋1は15パズルの約500万分の1！だから探索が圧倒的に速いんです。

3×3＋1パズルは状態数が少ないので、AIの探索がとても速く終わります。「計算量の違い」を体感するのにぴったりですね。

実際に遊んでみよう

こちらも同じくIDA*探索を実装したバージョンを作りました。

15パズルと比べて、探索ノード数や探索時間がどれくらい違うか、ぜひ比較してみてください！

コードの違い

アルゴリズムはほぼ同じで、隣接関係の定義だけが違います。

// 3×3＋1パズルの隣接関係
function getAdjacentIndices(index) {
  const adjacency = {
    0: [1],           // 上部スロット → 左上(1)のみ
    1: [0, 2, 4],     // 左上 → 上部スロット, 右, 下
    2: [1, 3, 5],
    3: [2, 6],
    4: [1, 5, 7],
    5: [2, 4, 6, 8],  // 中央 → 上下左右
    6: [3, 5, 9],
    7: [4, 8],
    8: [5, 7, 9],
    9: [6, 8]
  };
  return adjacency[index] || [];
}

15パズルでは「上下左右」を計算で求めていましたが、3×3＋1パズルでは上部スロットという特殊な位置があるので、隣接関係をテーブルで定義しています。

この「問題の構造に合わせて隣接関係を定義する」というのも、状態空間探索の重要なポイントです。問題が変わっても、アルゴリズムの骨格は同じ。変わるのは「状態の表現」と「隣接関係」だけです。

おわりに

15パズルという素朴なおもちゃが、AI研究の原点であり、現代の技術にもつながっているというお話でした。

「考える」とは何か。この問いに対する一つの答えが「状態空間を探索すること」です。そして、賢く探索するための工夫が、ヒューリスティックというアイデアでした。

次に15パズルや絵合わせパズルを見かけたら、ぜひAIの気持ちになって解いてみてください。

「今の状態からゴールまで、最低何手かかるか？」と考えながら。

それが、AIの「考え方」を体験する第一歩となるとおもいます。

それでは、今回もお読みいただきありがとうございました。

また次回お会いしましょう！

関連記事

以下の記事も今回と同様、ゲームを題材にAI基礎理論「情報理論」を解説しています。

人気ゲーム「ヒット&ブロー」で学ぶ情報理論

こんにちは！ Qualiteg研究部です！ 今日はAIにおいても非常に重要な情報理論について、Nintendo Switchの人気ゲーム「世界のアソビ大全51」にも収録されている「ヒット＆ブロー」というゲームを題材に解説いたします！ はじめに 論理的思考力を鍛える定番パズルゲームとして長年親しまれている「ヒット&ブロー」（海外では「Mastermind」として知られています）。 このゲームは一見シンプルながらも、その攻略には深い論理的アプローチが必要とされております。 本稿では、このゲームについて情報理論という数学的概念を用いてゲームの素性を分析する方法について掘り下げてみたいとおもいます。 さらに、この情報理論が現代の人工知能（AI）技術においてどのように活用されているかについても触れていきます。 ヒット&ブローのルール説明 ヒット&ブローは、相手が秘密に設定した色や数字の組み合わせを推測するゲームです。日本では主に数字を使った「数当てゲーム」として親しまれていますが、本記事では色を使ったバージョン（マスターマインド）に焦点を当てます。 Nintendo Sw

Qualiteg BlogQualiteg 研究部

参考資料

• A* search algorithm - Wikipedia
• 15 puzzle - Wikipedia
• IDA* - Iterative deepening A*
• AlphaGo - DeepMind

こんにちは！

Qualitegプロダクト開発部です！

「楽観的ロックを実装したのに、まだ競合エラーが出るんですけど...」

これは私たちが実際に経験したことです。

本記事では、楽観的ロックと悲観的ロックの違いを、実際に発生したトラブルを通じて解説します。

抽象的な説明ではなく、
「なぜそれが必要なのか」「どんな問題を解決できるのか」
を実感できる内容を目指します。

目次

1. 問題の背景：並列処理で謎のエラー
2. ロックなしの世界：なぜ競合が起きるのか
3. 楽観的ロックの導入：期待と現実
4. 楽観的ロックの限界：解決できなかった問題
5. 悲観的ロックによる解決
6. 実装時のハマりポイント
7. どちらを選ぶべきか：判断基準
8. まとめ

1. 問題の背景：並列処理で謎のエラー

1.1 システムの概要

私たちが開発していたのは、
複数のワークスペースを切り替えて使用するAPIサーバー
でした。

当社AI関係のプロダクトの一部だったのですが、結合テスト兼負荷テストを実行すると、まれに発生してしまっていました。

ユーザーは複数のワーキングセット（設定セット）を作成でき、その中から1つを「アクティブ」として選択できる機能があります。

1.2 発生したエラー

並列でリクエストを処理すると、以下のエラーがランダムに発生しました。

Error: HTTP Error 500: Cannot modify protected workspace 'default'

単独で実行すると成功するのに、複数クライアントが大量同時にアクセスすると失敗します。

しかも、失敗するリクエストは毎回違うという現象です

これは典型的な競合状態（Race Condition）の症状ですね。いちばんいやな感じのやつです。

2. ロックなしの世界：なぜ競合が起きるのか

2.1 用語の定義

さて、本題に入る前に、この記事で使う用語を定義しておきます。

グローバル状態とは、複数のクライアントから共有され、かつ暗黙的に参照される状態のことです。本記事の例では「現在アクティブなワークスペースがどれか」という情報がこれに該当します。

2.2 問題の原因

調査の結果、以下のシナリオで問題が発生していることがわかりました。

クライアントAの視点で見てみますと、

1. 自分のワークスペース workspace_A をアクティブ化した
2. そのワークスペースに設定を追加しようとした
3. なぜか default への変更エラーが返ってきた

何が起きたかというと、クライアントAがリクエストを送信してからサーバーに到達するまでの間に、クライアントBがアクティブワークスペース（グローバル状態）を切り替えてしまったのです。

2.3 問題の本質

問題の本質はなんだったのでしょう。そう、この問題の本質は、
複数のAPI呼び出しにまたがる操作
にあります。

await client.switch("workspace_A");   // 操作1: 切り替え
await client.addSettings(data);       // 操作2: 設定追加 ← ここで問題
await client.process(input);          // 操作3: 処理実行

操作1と操作2の間には時間差があり、その間に他のクライアントがグローバル状態を変更できてしまいます。

これは

TOCTOU（Time Of Check To Time Of Use）問題

と呼ばれる典型的な競合状態です。

DBでいうと、「トランザクション」操作に近いですね。

3. 楽観的ロックの導入：期待と現実

3.1 楽観的ロックとは

さて、ここで考え付くのは楽観的ロックです。

「楽観的ロック（Optimistic Locking）」は、競合はめったに起きないという前提に基づく方式です。

基本的な仕組みは以下のとおりです。

1. データ取得時にバージョン情報（ETag等）を受け取る
2. 更新リクエストにバージョン情報を含める
3. サーバーはバージョンが一致する場合のみ更新を許可
4. 不一致の場合は「409 Conflict」を返す

そして、競合が発生した場合はこうなります。

3.2 楽観的ロックが解決できること

楽観的ロックに解決できることはなんでしょうか。

はい、楽観的ロックはLost Update（更新の消失）問題を解決することができます。

4. 楽観的ロックの限界：解決できなかった問題

4.1 期待した動作

そして、排他制御なら楽観的ロックと短絡して、さっそくその実装してみました。

競合問題が解決されると信じて

4.2 現実

しっかし、、、同じエラーが発生し続けました。。

4.3 なぜ解決できなかったか

なぜうまくいかなかったか、いろいろ分析デバッグするなかで、３つの理由にきづきました。（まなびました）

1. 競合しているのはワークスペースの「内容」ではない

競合しているのは「アクティブなワークスペースが何か」というグローバル状態です。

2. ETagを付けても意味がない

ETagは「データの内容が変わっていないか」のチェックです。「アクティブなワークスペースが変わっていないか」はチェックできません。

3. そもそもリソースが違う

クライアントAは workspace_A を操作したいのに、サーバーは default を操作しようとしています。これはどのリソースを操作するかの競合なのです。

4.4 楽観的ロックの本質的な限界

✅ 楽観的ロックが対応できる:
   - 単一リソースへの同時書き込み
   - 同じファイルを2人が同時に編集

❌ 楽観的ロックが対応できない:
   - 複数API呼び出しにまたがる操作の保護
   - グローバル状態の保護

楽観的ロックは「変更の検出」はできるが、「操作の排他」はできないのです。

より厳密に言えば、楽観的ロックは「単一リソースの状態遷移」に対してのみ排他性を持ち、「複数リソースや複数操作の整合性」は保証しません。

これは、さっきちょっとふれたデータベースのトランザクション境界の議論と本質的に同じ問題です。

そうした本質を忘れていた私は見事に失敗してしまいました

4.5 補足：API設計を変えれば解決できた？

さて、百戦錬磨のエンジニアなら、ここまで読んで
「API設計を変えれば楽観的ロックでも解決できるのでは？」
と思った方もいるかもしれません。

その通りです！

改善案の設計なら、リクエスト自体に操作対象が含まれるため、グローバルな「アクティブ状態」に依存しません。各ワークスペースに対して楽観的ロック（ETag）を適用すれば、競合を検出できます。

では、なぜ悲観的ロックを選んだのでしょうか？

ひとえに私の見識が足りなかった、、んですが、もう少し言い訳をしてみると、

1. 既存APIの後方互換性

多くのクライアントが現在のAPIを使用しており、API変更は全クライアントの修正が必要になる予感があった

2. 「アクティブ状態」パターンは珍しくない

実は、このパターンは様々なツールで採用されており、現行設計がそうなっていた

• Git: git commit は「現在のブランチ」に対して動作
• シェル: コマンドは「現在のディレクトリ」で実行
• エディタ: 「現在のファイル」に保存

3. 設計変更のコストと時間

問題は「今」発生しており、API再設計には時間がかかりそうだった

教訓をまとめると、以下のようになります。

• 楽観的ロックの限界というより、
  「グローバル状態に依存する設計」と楽観的ロックの相性が悪い
  
• 新規設計なら、リソースを明示するRESTfulなAPIを検討すべき
• 既存システムでは、（なんとかするために）悲観的ロックが現実的な解決策になることも多い

5. 悲観的ロックによる解決

5.1 悲観的ロックとは

そこで、既存API設計を壊さず、競合状態の問題を解決するため悲観的ロックを導入することにしました。

「悲観的ロック（Pessimistic Locking）」は、競合は頻繁に起きるという前提に基づく方式です。

基本的な仕組みは以下のとおりです。

1. 操作開始前に明示的にロックを取得
2. ロック保持中は他のクライアントをブロック（または拒否）
3. 操作完了後にロックを解放

ロック中に別のクライアントがアクセスした場合はこうなります。

※なお、423 Locked はWebDAV拡張（RFC 4918）で定義されたステータスコードです。一般的なREST APIでは 409 Conflict や 429 Too Many Requests を使うケースもあります。どれを使うかはAPI設計のポリシー次第ですが、「ロックされている」という意味を明確に伝えたい場合は 423 が適切です。

5.2 問題への適用

悲観的ロックを使うと、競合は以下のように解決できます。

5.3 実装のポイント

悲観的ロックを実装する際の重要なポイントを3つ紹介します。

1. デッドロック対策

2. ロック解放忘れ対策

// try-finallyで確実に解放
const lock = await acquireLock(resource);
try {
    await doSomething();
} finally {
    await releaseLock(lock);
}

3. タイムアウト設定

ロックには有効期限を設定し、クライアントが異常終了した場合でも自動的に解放されるようにします。

6. 実装時のハマりポイント

ここまでいかがでしたでしょうか。

実はロックうんぬんのまえに、いろいろハマったので、後学のため、少しここに残しておきたいと思います。

悲観的ロックを実装・運用する中で、私たちが実際にハマった問題とその対処法を紹介します。

6.1 ロック以前の問題：前提ロジックのバグ

問題：ロック検証は成功しているのに、操作が失敗する

クライアント: LOCK("workspace_A") → 成功
クライアント: switch("workspace_A") → 成功
クライアント: addSettings(data) → 423 Locked ??

なぜ？ロックを持っているはずなのに...

原因：サーバー側でアクティブなワークスペースを取得するロジックにバグがありました。

サーバーの getActiveWorkspaceName() が返す値:
  期待: "workspace_A"（クライアントがアクティブ化したもの）
  実際: "default"（バグにより常にdefaultを返していた）

→ サーバーは "default" のロックをチェック
→ クライアントは "workspace_A" のロックしか持っていない
→ 423 Locked

教訓：ロック機構自体は正しくても、ロック対象を特定するロジックにバグがあると全てが崩壊します。これは泣けました。

ロック関連のデバッグでは「何のロックをチェックしているか」を必ずログ出力するようにしましょう。

6.2 プロキシ/ゲートウェイの透過性問題

問題：ロック解放のDELETEリクエストがタイムアウトする

クライアント: DELETE /lock/workspace_A
             X-Lock-Id: abc123
             Body: { "resource": "workspace_A" }

→ リクエストが120秒後にタイムアウト

原因：nginxのリバースプロキシ設定で、DELETEリクエストのボディが（ある条件だと）転送されない設定になっていました。

# nginx.conf（問題のある設定）
location /api/ {
    proxy_pass http://backend;
    
    # POST/PUT/PATCHのみボディを転送する設定になっていた
    # DELETEにボディがあることを想定していなかった
}

HTTPの仕様上、DELETEリクエストにボディを含めることは許可されています。しかし、
多くのプロキシやフレームワークはDELETEにボディがあることを想定していない
んです。nginxのデフォルト設定では問題ありませんが、カスタム設定を入れている場合は注意が必要です。

教訓：

• ロック操作にはボディが必要になることがある
• プロキシ層での通信を確認する（リクエスト/レスポンスの完全なログ）
• 可能であれば、DELETEのボディではなくクエリパラメータやヘッダーを使う

6.3 ロックの設計を間違える

問題：並列テストが動かないので「複数ロックIDを同時に送れる」ように拡張した

// 誤った解決策
クライアント: X-Lock-Id: lock_A, lock_B, lock_C  // 複数ロックを送信
サーバー: いずれかのロックが有効なら許可  // ロックの意味がなくなる！

結果：並列実行できるようになりましたが、ロックの意味が完全に失われました。後で元に戻すことになりました。これはAIコーディングがミスをした例です。目のまえの問題を解決しようとして、無理くりこのとんでも実装をいれてしまいました。

正しい解決策：並列テストを諦め、テストを直列実行するように変更しました。

# テストの実行方法を変更
node --test --test-concurrency=1 tests/*.test.js

教訓：

• AIコーディングはこういう「本質をぶち壊す、目先の対処」をしてしまうので、AIを信じ切ってはいけず、かならずアーキテクチャを理解してる人の目でレビューをしないととんでもないことになります。
• ロック機構を「緩める」方向の変更は、ほぼ間違いです
• 「ロックがあるのに動かない」は、ロックではなく使い方が間違っている
• テストのために本番コードを壊さない

6.4 テスト設計との相性問題

問題：テストを並列実行すると競合エラーが発生

テストA: LOCK("default") → 成功
テストB: LOCK("default") → 待機...
テストC: LOCK("default") → 待機...
テストD: LOCK("default") → タイムアウト！

原因：全てのテストが同じリソース（default）のロックを取ろうとしていました。当然、この手の並列操作は待たされる（待たされることで破綻を回避するので）ので、テストはタイムアウトしてしまいました。

解決策：テストを2種類に分離しました。

tests_for_functions/    ← ロック不要、並列実行OK
  - 読み取り専用の機能テスト
  - 状態を変更しないテスト

tests_for_policy_edit/  ← ロック必要、直列実行必須
  - ワークスペースを作成・変更するテスト
  - グローバル状態を変更するテスト

教訓：

• 悲観的ロックを導入したら、テスト戦略も見直す
• 「並列実行できないテスト」は品質が低いわけではない
• グローバル状態を変更するテストは、そもそも並列実行すべきでない

6.5 ロック漏れの検出の難しさ

問題：時々423エラーが出るが、再現性がない

// 問題のあるコード
await acquireLock("resource");
await doSomething();  // ここで例外が発生すると...
await releaseLock("resource");  // 実行されない！

困難な点：

• 例外が発生しないと問題が顕在化しない
• 本番環境でのみ発生する（テストでは通る）
• ログを見ても原因が特定しにくい

対策：

// 1. withLockパターンを強制
async function withLock(resource, operation) {
    const lock = await acquireLock(resource);
    try {
        return await operation();
    } finally {
        await releaseLock(resource, lock);
    }
}

// 2. 直接のacquire/releaseを禁止（コードレビューで検出）
// 3. ロックのタイムアウトを適切に設定（漏れても自動解放）
// 4. ロックの保持時間を監視（異常に長いロックをアラート）

教訓：ロック漏れは必ず起きる前提で設計しましょう。システム全体がとまるという絶望的状況がおこらないようタイムアウトによる自動解放は必須です。完璧なシステムはありませんので。

7. どちらを選ぶべきか：判断基準

7.1 楽観的ロックが適しているケース

例：ユーザープロフィール編集、記事の更新、設定ファイルの変更

7.2 悲観的ロックが適しているケース

例：在庫管理、銀行口座の残高更新、複数ステップの業務フロー

7.3 比較表

7.4 併用のパターン

実際のシステムでは、両方を併用することも多いです。

[楽観的ロック]                    [悲観的ロック]
・個別リソースの更新              ・複数リソースにまたがる操作
・低競合の操作                    ・高競合の操作
・読み取り中心の処理              ・複数ステップのトランザクション

8. まとめ

8.1 学んだこと

1. 楽観的ロックは万能ではない

「変更の検出」はできますが「操作の排他」はできません。複数API呼び出しにまたがる操作は本質的に保護できないです

2. 問題の本質を理解することが重要

「何と何が競合しているか」を明確にするのが大事ですね。単一リソースの競合か、グローバル状態の競合かを区別することが大切です。

3. 適切な方式を選択する

競合の頻度、操作の性質、システム要件を考慮し、必要に応じて併用しましょう。

4. 悲観的ロックは「古い設計」ではない

競合が設計上必然である場合、悲観的ロックは最も正直な解決策です。「楽観的ロック＝モダン、悲観的ロック＝レガシー」という図式は誤りです。

8.2 AIコーディングエージェントを使う際の注意

最近はClaude CodeのようなAIコーディングエージェントを活用する機会が増えていますが、並列処理やロックの実装においては注意が必要です。

AIエージェントの傾向

私たちの経験では、AIコーディングエージェントには以下のような傾向があります。

• 並列処理のコーディングに不慣れ：競合状態やデッドロックなど、非決定的な問題の考慮が抜けがち
• 目の前の問題を直接解決しようとする：「このエラーを解消するには？」という質問に対して、局所的な修正を提案しがち
• 設計レベルの視点に気づきにくい：より根本的な解決策があっても、提示されたコードの範囲内で解決しようとする

今回の例で言えば

本記事の問題も、視点を一段上げれば別の解決策がありました。

目の前の問題:
  「グローバル状態への競合をどう防ぐか？」
  → 悲観的ロックで排他制御

一段上の視点:
  「そもそもグローバル状態に依存しない設計にできないか？」
  → RESTfulにリソースを明示するAPI設計
  → リソース単位の楽観的ロックで対応可能

AIエージェントに「このエラーを直して」と依頼すると、悲観的ロックの実装を提案してくるかもしれません。それ自体は間違いではありませんが、API設計を見直せば楽観的ロックでシンプルに解決できたという選択肢には気づきにくいのです。

AIをコントロールするために

AIコーディングエージェントを効果的に活用するには、人間側がアーキテクチャレベルの視点を持つことが重要です。

• 「この問題を解決して」ではなく「この問題の原因は何か？設計レベルで解決できないか？」と問いかける
• AIの提案をそのまま受け入れず、「もっとシンプルな方法はないか？」と深掘りする
• 並列処理に関わる実装は特に注意深くレビューする

AIは強力なツールですが、設計判断は人間が主導する必要があります。特に並行処理のような複雑な領域では、AIの提案を鵜呑みにせず、一段上の視点からコントロールすることを心がけましょう。

最後に

並行処理の問題は、一度動いたからといって安心できないという厄介な性質があります。開発環境では動いても、本番の高負荷時に問題が顕在化することも珍しくありません。

「楽観的ロックを入れたから大丈夫」と思い込まず、本当に解決したい問題を楽観的ロックで解決できるのかを冷静に分析することが重要です。

そして、並行処理の設計で最も危険なのは、「どこに状態があるかを、設計者自身が曖昧にしてしまうこと」ではないでしょうか。

本記事の例でも、「アクティブなワークスペース」というグローバル状態の存在を明確に認識していれば、最初から適切な対策を選べたかもしれません。

状態がどこにあり、誰がそれを変更でき、どのように保護するか——この問いに明確に答えられることが、並行処理設計の第一歩です。

同様の問題でお悩みの方の参考になれば幸いです！

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

参考資料

• Optimistic vs Pessimistic Locking
• RFC 7232 - Conditional Requests
• RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
• TOCTOU Race Condition
• Distributed Locks

こんにちは！

ChatGPTやClaudeといった生成AIサービスが業務に浸透し始めた今、

「AIに機密情報を送ってしまうリスク」

が新たなセキュリティ課題として浮上しています。

この課題に向き合う中で、私たちは改めて「企業のセキュリティアーキテクチャはどう変遷してきたのか」を振り返る機会がありました。

すると、ある疑問が浮かんできます。

「なんでこんなに複雑になってるんだっけ？」

企業のセキュリティ担当者なら、一度は思ったことがあるのではないでしょうか。

アルファベット3〜4文字の製品が乱立し、それぞれが微妙に重複した機能を持ち、設定は複雑化し、コストは膨らみ続けています。

当社ではAIセキュリティ関連プロダクトをご提供しておりますが、AI時代のセキュリティを考える上でも、この歴史を理解することは重要ではないかと考えました。

本記事では、企業ネットワークセキュリティの変遷を振り返りながら、「なぜこうなったのか」を整理してみたいと思います。

第1章：観測点を集約できた時代 ― オンプレAD + Proxy（〜2010年代前半）

統制しやすかったモデル

かつて、企業ネットワークにおける「インターネット出口の統制」は比較的シンプルでした。

もちろん、当時も境界ファイアウォール、IDS/IPS、メールゲートウェイ、アンチウイルスなど、様々なセキュリティ製品は存在していました。

しかし、
インターネットへの出口をProxyに集約できた
ことで、Web通信の統制という観点では非常に筋の良い構成が実現できていました。

上図のようにWindows系のPCを活用している企業の場合、Active Directory(以後AD)がユーザーの認証の仕組みや証明書の配布、Proxyサーバーの設定などを一元管理します。

なぜこのモデルが統制しやすかったのか

このモデルがうまく機能していた理由は、以下の3点に集約されます。

通信経路の一本化について

社内ネットワークは「閉域網」として設計されていました。

インターネットへの出口はProxyサーバーだけであり、社員がProxyを経由せずに外部と通信することは、そもそも不可能、という仕組みです。

認証の統合について

さらに、ユーザー認証についても考えてみましょう。

すべてのユーザーが（論理的に）１つのProxyを通ってインターネットにでていくということは、会社側がその気になれば、従業員がどんな通信をしているかわかります。

そのとき、Windows系のPCを導入している会社には統合Windows認証という仕組みがありました。それを使うと、Proxyサーバーが、それを使ってるのは誰か、という「ユーザー特定」ができるようになります。

といってもProxyがユーザーを特定できるのは、Proxy側が認証（Proxy-Auth）を要求し、Kerberos/NTLM（統合Windows認証）でユーザーを確定できた場合です。

ただADがあれば自動的に特定できるわけではなく、Proxy側・ブラウザ側の統合認証設定が正しく噛み合って初めて成立します。

実運用では、この統合認証の設定が地味にハマりどころでもありました。

しかし、一度正しく構成できれば、ユーザーが意識的に何かをする必要なく認証をすることができました。

尚、ADは今でもセキュリティを重視する大企業では現役で、ADとAI時代のセキュリティはこちらのシリーズにて連載中です

観測点の集約について

そして、上記の2つが組み合わさることで、企業は
「誰が」「いつ」「何を」したかを把握できました。

そして、Web通信に関するDLP（Data Loss Prevention：情報漏洩対策）を実装するなら、Proxyで実施するのが効率的でした。Proxyを通って外の世界とインタラクションするからです。

ただ、データの出口はWebだけではありません。メール、ファイルサーバー、USBデバイスなど、当時も複数の経路が存在していましたので、DLP製品ではそういった部分の監視、追跡もやっています。Proxyは強力でしたが、万能ではなかったという点は認識しておく必要があります。

情報漏洩対策としてのMITM

さて、現代ではほとんどの通信がHTTPSで暗号化されています。

では、暗号化された通信の中身をどうやって検査していたのでしょうか？

答えは「SSL/TLSインスペクション」、実質的にはMITM（Man-in-the-Middle） という仕掛けをつかいます。

つまり、Proxyの中でいったん暗号通信を復号化して検査します。問題がなければ、そのままインターネット側につなぐ、という方式です。

この仕組みを実現するためには、まずユーザーが使うブラウザがProxyを信頼しないといけないため、ブラウザに企業独自のルートCA証明書（会社内のProxyはあやしくないですよ、っていうことを証明できる）を全社員のPCにインストールする必要があります。

「全社員のPCに証明書インストールする？面倒そう？」と思われるかもしれませんが、そういうときのためのADです。

ADドメイン環境では、グループポリシー（GPO）を使ってルート証明書を自動配布できたため、この点でも統制が取りやすかったのです。

ADが配布していたもの

ADは単なる認証基盤ではなく、様々な設定を一括配布する役割も担っていました。

社員は何も意識する必要がありません。ドメインにログインするだけで、必要な設定はすべて自動的に適用されていたのです。

つまり、Proxy設定も配布できるので、ふつうのProxyからDLP用のProxyに社員のPCの設定をかえたいときもADを経由して全社員のPCに自動的に反映することができます。従業委員を管理する側としてはＡＤはとっても楽でした。

この時代の特徴まとめ

「セキュリティと利便性はトレードオフ」とよく言われますが、この時代は
社内にいる限り、観測点を集約できるので統制が取りやすかった時代
だったと言えます。

第2章：変化の始まり ― クラウドとモバイルの台頭（2010年代中盤〜）

ビジネス環境の変化

さて、2010年代中盤から、企業を取り巻く環境に大きな変化が起きました。

大きく２つあります

まずクラウドコンピューティングの時代となりＳａａＳが普及し、いろいろなアプリがクラウド化されていきました。Ｗｅｂから使う感じですね。

もう１つは、iPhoneの登場によりガラケーからスマホの時代になり、スマホで外出先でも仕事をしたい！という需要がでてきました。

これらの変化により、「社内ネットワークに物理的にいないと仕事ができない」という前提が崩れ始めました。

閉域網モデルの限界

従来のモデルで社外から仕事をするには、VPN（Virtual Private Network） を使って社内ネットワークに接続する必要がありました。

この方式にも課題がありました。

こうした社内ネットワークへのリモートアクセスは現代でも一般的ではありますが、特にクラウドサービスの利用が増えると、
「社内にいないのに社内を経由してクラウドにアクセスする」
という非効率さもめだってきました

この非効率もスマートに解消できないか、という思いから
企業は新しいアプローチを模索し始めました。

第3章：クラウド認証基盤の登場（2010年代後半〜）

オンプレADは今も現役、しかし選択肢が増えた

さて、クラウド時代にＳａａＳが普及しスマホで外出先から仕事をするのはわりと当たり前になってきましたが、ここで重要なのは、オンプレミスのActive Directoryが「古くなった」わけではないという点です。

現在でも多くの大企業では、オンプレADが認証基盤の中核として稼働していますし。

特に、社内にファイルサーバーやレガシーアプリケーションが残っている環境、厳格なセキュリティ要件がある環境では、オンプレADは引き続き重要な役割を果たしています。

クラウドサービスの普及に伴い、認証基盤もクラウドに移行する流れが生まれました。 従来のオンプレミスADに加えて、クラウド型の認証基盤（IDaaS） を導入する企業が 増えていきました。

代表的なのが Microsoft Entra ID（旧 Azure AD） です。オンプレミスのActive Directory と同期させてハイブリッド構成にしたり、クラウド単独で運用したりと、柔軟な構成が 可能になりました。

クラウド認証基盤が選ばれる理由

Microsoft Entra ID（旧 Azure AD） のようなクラウド型の認証基盤（IDaaS）を導入・併用する企業が増えている背景には、以下のような理由があります。

これにより、社内ネットワークを経由せずにクラウドサービスにアクセスできるようになりました。

得たものと新たな課題

クラウド認証基盤の導入・併用により、利便性は確かに向上しました。

しかし、セキュリティの観点では新たな課題が生まれています

なぜ「誰が」の特定が難しくなったのか

さて、ADをつかってProxyをうまく連動させると、統合Ｗｉｎｄｏｗｓ認証をつかって「誰が」「どんな通信をしてるか」は観測可能です、という話を冒頭でしましたが、昨今はなぜ「誰が」の特定が難しくなってるのでしょうか。

重要なポイントは
「認証方式が変わったから」というより、「経路と観測点が分散したから」
です

クラウド認証（SAML/OIDC/OAuth）とは「アプリ（SaaS）側で認証が完結」する仕組みです。

そして端末が社内網を経由せず直接SaaSへ出るようになると、従来の「出口Proxyで一括観測」というモデルが崩れてきます

とはいえ
「クラウド認証だからProxyが絶対に誰か分からない」わけではありません。

端末の通信を依然としてSWG/Proxyに強制し、Proxy側でユーザー認証（IdP連携や端末証明書、Kerberos/NTLM等）をさせれば、Proxyはユーザーを把握できます。現代のSWG/SSE製品がまさにそれをやっており、後述するSASEが「identity/contextベース」を含むとされるのもこの方向性です。

ただし、そのためには端末の通信を確実にProxy/SWGに向ける仕組みが別途必要になります。

なんだかまどろっこしいですが、がんばればProxyに通信をもってこさせることはできるんだけど、そのためには「追加のソリューションが必要」ということになります。

第4章：観測点を再集約するための様々なアプローチ

クラウド直行で分散した観測点を、もういちど何らかの形で再集約しようとする動きが生まれました。

そうして様々な「補完ソリューション」が登場しました。その背景には、この「分散した観測点をどう束ねるか」という課題があります。

時代が進化していろいろ複雑になってしまったけど、なんとかして「誰が何をしてるのか」を観測したい、ということでいろいろ考えてみた、という感じでしょうか。

アプローチ1：エンドポイントにエージェントを導入

まず１つめあ、「境界で観測できないなら、端末側で観測すればいい」という発想です。

この方式は要するにPCに監視用アプリをインストールしましょう、という発想です。PCにインストールされたエージェント（実態はただのPCアプリ）が「今このPCにログインしているのは誰か」を把握し、通信情報と紐付けて監視サーバーに送信します。

この方式の考慮点

アプローチ2：デバイス管理基盤（MDM）との連携

エージェントを確実に配布するために、MDM（Mobile Device Management） と呼ばれるデバイス管理基盤を導入する企業が増えました。

会社支給のPCであれば、初回起動時に自動でMDMに登録され、必要なエージェントも自動インストールされる仕組みを構築できます。

この方式の考慮点

アプローチ3：クラウドアクセス監視基盤（CASB）の導入

「通信経路で観測できないなら、クラウドサービス側で観測すればいい」という発想から生まれたのが、CASB（Cloud Access Security Broker） です。

CASBには主にAPI連携型とProxy型、そしてそれらを組み合わせたハイブリッド型があります。

CASBは一般に「可視化（Visibility）」「データセキュリティ」「脅威防御」「コンプライアンス」の4つの柱で語られることが多く、クラウド利用の統制において重要な役割を果たしています。

この方式の考慮点

アプローチ4：ネットワーク全体のクラウド化（SASE/SSE/ZTNA）

「分散した観測点を、クラウドサービスとして再集約しよう」という思想から生まれたのが、SASE（Secure Access Service Edge） です。

SASEは、ネットワーク機能（SD-WANなど）とセキュリティ機能（SWG/CASB/ZTNA/DLPなど）を統合したクラウドサービスです。セキュリティ機能側だけを指す場合は SSE（Security Service Edge） と呼ばれることもあります。HTTPのプッシュ送信のSSEとちょっと紛らわしいですが。

また、ZTNA（Zero Trust Network Access） は、「社内ネットワーク」という概念を前提とせず、アプリ単位でアイデンティティとコンテキストに基づいてアクセスを仲介するアプローチです。

このアプローチでは、すべてのアクセスがクラウド上のセキュリティ基盤を経由します。「社内」「社外」という区別をなくし、どこからのアクセスも同じように検証するという考え方です。

この方式の考慮点

第6章：振り返り ― シンプルさの価値

2つのアプローチの比較

さていろいろみてきましたが、

ここで改めて、ＡＤをつかったアプローチと、ＡＤを使わないクラウド時代でいろいろがんばるアプローチ、2つのアプローチを比較してみましょう。

重要な前提として、これは「古い vs 新しい」という対比ではありません。

閉域網中心のアプローチは今も多くの企業で現役であり、特にセキュリティ要件が厳格な環境では引き続き協力で有効な選択肢です。

クラウド対応のために構成を拡張するかどうかは、あくまで各企業のビジネス要件次第です。

複雑になればなるほど、運用の難易度は上がります。シンプルな構成の価値は、今も変わっていません。

なぜ構成が拡張されてきたのか

多くの企業で構成が拡張されてきた背景には、繰り返しこの記事でふれていますが、ビジネス要件の変化があります。

仕事のやり方がテクノロジーとともに進化すると、効率化の観点、もっと楽にやりたいという観点などで、いろんな現場の要求があがってきます

そうなると、セキュリティ側としてもそうした現場要求に最大限応えつつもセキュリティもしっかり、というジレンマが発生し、その結果として今の複雑な状況につながっているのかもしれません。

結論：シンプルさという価値を忘れずに

どちらのアプローチを選ぶにせよ、以下のことは認識しておくべきではないでしょうか。

セキュリティの世界では、シンプルさは価値です。

複雑なものは運用が難しく、設定ミスも起きやすく、コストも高くつきます。

閉域網 + AD + Proxyという構成が示す「観測点を集約できる筋の良さ」は、今も有効なアプローチです。

クラウド対応で構成を拡張する場合でも、この「筋の良さ」を参照点として、必要最小限の複雑さに留める意識を忘れないようにしたいと思います。

おわりに：LLM時代のセキュリティを考える

さて、ここまで企業セキュリティの歴史を振り返ってきましたが、実は私たちQualitegも、まさにこの「シンプルさ」と「観測点の集約」を大切にしながらLLM時代のセキュリティに取り組んでいます。

そうした中で、ChatGPTやClaudeといった生成AIサービスへの情報漏洩対策として、私たちは LLM-Audit というソリューションを開発・提供しています。このLLM-Auditは、まさにこの記事で紹介したAD+ MITM方式（Proxy型） を選択することが可能です。（ほかの連携方法もあります）

AD+Proxy型は導入がシンプル

AD + Proxyという「観測点を集約できる」アーキテクチャの場合、こうしたAIセキュリティの実装がもっともシンプルになり、かつモレが少なくて強力です。エージェントを全端末に配布する複雑さを避け、Proxy経由で通信を監視することで、「誰が」「何を」AIに送信したかを把握できます。

Proxy型が有効な条件と、そうでない領域

この記事にあるとおりProxy型（MITM方式）にも適用条件があります。本記事内容の復習を兼ねてまとめますと、以下のようになります。

だからこそ、優先順位の設計が重要になります。「すべてを監視する」のではなく、「業務で使う管理端末からのLLMアクセスを確実に統制する」という形で、現実的なスコープを定めることが大切です。

さて、この記事で解説したActive DirectoryとProxyの統合については、私たちの技術ブログでより詳しく解説していますので、そちらもご参照いただけますと、Proxy方式の理解が深まると思います

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第1回 基本概念の理解

こんにちは！ 今回から数回にわたり Active Directory について解説してまいります。 Active Directory（AD:アクティブディレクトリー）は、Microsoft が開発したディレクトリサービスであり、今日の大企業における IT インフラストラクチャーにおいて、もはやデファクトスタンダードと言っても過言ではない存在となっており、組織内のユーザー、コンピューター、その他のリソースを一元的に管理するための基盤として広く採用されています。 AIセキュリティの現実：単独では機能しない ChatGPTやClaudeなどの生成AIが企業に急速に普及する中、「AIセキュリティ」という言葉が注目を集めています。情報漏洩の防止、不適切な利用の検知、コンプライアンスの確保など、企業が取り組むべき課題は山積みです。 しかし、ここで注意しなければいけない事実があります。それは、 AIセキュリティソリューションは、それ単体では企業環境で限定的な効果しか期待できない ということです。 企業が直面する本質的な課題 AIセキュリティツールを導入する際、企業のIT部門

Qualiteg BlogQualiteg コンサルティング

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第2回 ドメイン環境の構築

こんにちは、今回はシリーズ第２回ドメイン環境の構築 - 検証環境の構築手順について解説いたします！ 連載の構成 第1章：基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎 【★今回です★】第2章：ドメイン環境の構築 - 検証環境の構築手順 第3章：クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順 第4章：プロキシサーバーと統合Windows認証 第5章：ブラウザ設定と認証 - 各ブラウザでの設定方法 第6章：トラブルシューティング - よくある問題と解決方法 第7章：セキュリティとベストプラクティス - 本番環境での考慮事項 第8章：実践的な構成例 - AIセキュリティツールとの統合事例 第2章：ドメイン環境の構築 2.1 ドメイン名の設計 2.1.1 ドメイン名の命名規則 Active Directoryを構築する際、

Qualiteg BlogQualiteg AIセキュリティチーム

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第3回 クライアントとサーバーのドメイン参加

こんにちは、今回はシリーズ第３回クライアントとサーバーのドメイン参加について解説いたします！ はじめに こんにちは！シリーズ第3回「クライアントとサーバーのドメイン参加」へようこそ。 前回（第2回）では、Active Directoryドメイン環境の構築手順について、ドメインコントローラーのセットアップからDNS設定まで詳しく解説しました。ドメイン環境の「土台」が整ったところで、今回はいよいよ実際にコンピューターをドメインに参加させる手順に進みます。 「ドメインユーザーアカウントを作ったのに、なぜかログインできない」「新しいPCを追加したけど、ドメイン認証が使えない」といった経験はありませんか？実は、Active Directoryの世界では、ユーザーアカウントを作成しただけでは不十分で、そのユーザーが使用するコンピューター自体もドメインに「参加」させる必要があるのです。 本記事では、このドメイン参加について、単なる手順の説明にとどまらず、「なぜドメイン参加が必要なのか」「裏側で何が起きているのか」という本質的な仕組みまで、初心者の方にも分かりやすく解説していきます。Win

Qualiteg BlogQualiteg AIセキュリティチーム

大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第4回 プロキシサーバーと統合Windows認証

11月に入り、朝晩の冷え込みが本格的になってきましたね。オフィスでも暖房を入れ始めた方も多いのではないでしょうか。 温かいコーヒーを片手に、シリーズ第4回「プロキシサーバーと統合Windows認証」をお届けします。 さて、前回（第3回）は、クライアントPCやサーバーをドメインに参加させる際の「信頼関係」の確立について深掘りしました。コンピューターアカウントが120文字のパスワードで自動認証される仕組みを理解いただけたことで、今回のプロキシサーバーの話もスムーズに入っていけるはずです。 ChatGPTやClaudeへのアクセスを監視する中間プロキシを構築する際、最も重要なのが「確実なユーザー特定」です。せっかくHTTPS通信をインターセプトして入出力内容を記録できても、アクセス元が「tanaka_t」なのか「yamada_h」なのかが分からなければ、監査ログとしての価値は半減してしまいます。 今回は、プロキシサーバー自体をドメインメンバーとして動作させることで、Kerberosチケットの検証を可能にし、透過的なユーザー認証を実現する方法を詳しく解説します。Windows版Squid

Qualiteg BlogQualiteg AIセキュリティチーム

さて、最後に、
複雑さと戦い続ける、すべてのセキュリティ担当者の皆さまにエールを送りつつ、この記事を終わりたいと思います。本記事がご参考になりますと幸いです。