Analytics

更新履歴 2026-09-12: 「優れたデータサイエンスはピボットテーブルに帰着する」という本質論を結びと論考に追記。 2026-09-12: ピボットテーブルの決定論的強靭さと粗雑なモデリング・外部AI依存の比較を追記。 2026-09-12: 外部持ち出しによるガバナンス崩壊と初歩的集計へのAI依存に関する分析を追記。 2026-09-12: 包括サブスクリプションの消化圧力とSIerの受託力学に関する分析を追記。 ChatGPT Workにおいて、自然言語で指示するだけで社内データを集計し、グラフやダッシュボードまで作成する「Data agent」が発表された。 一見するとビジネスユーザーにとって利便性の高い進化に見えるが、システムアーキテクチャの観点から見ると、その技術的価値には強い疑問が残る。 実務におけるデータ分析では、テーブルの物理スキーマだけでなく、カラムの文脈、ビジネスロジック、データリネージ、行レベルのアクセス権限といったメタデータが不可欠である。 外部のエージェントが自律的に正しい分析を行うためには、構造上、Snowflake HorizonやDatabricks Unity Catalog、あるいはMicrosoft Fabricといったメタデータ基盤からこれらの定義を取り込まねばならない。 しかし、そうしたメタデータ基盤をすでに整備している環境であれば、基盤自身が最適化されたLLMクエリ生成エンジンをすでに備えている。 確立されたメタデータ基盤の外側に、あえて別建てのLLMエージェントを被せる構成は、車輪の上に別の車輪を重ねるような過剰な二重構造にほかならない。 二重構造が生み出す4つの構造的欠陥 すでにネイティブなクエリ生成機構とオントロジーを持つメタデータ基盤に対し、外付けのLLMエージェントを仲介させる構成は、運用と性能の両面で重大な欠陥をもたらす。 第一に、レイテンシの多段化である。 ユーザーの自然言語入力を外部エージェントが解釈し、APIを介して基盤側にスキーマやデータを要求し、基盤側のエンジンがパースして実行し、その結果をエージェントが受け取って再解釈・可視化する。 通信ホップと推論のステップが無駄に多重化することで、対話型分析として許容できない待ち時間が発生する。 第二に、コンテキストの二重翻訳による情報の劣化である。 データ基盤内部であれば、Unity CatalogのオントロジーやHorizonのセマンティック定義をインメモリで直接参照してクエリを最適化できる。 外部エージェントを挟む構成では、それらの定義情報をプロンプト（テキストトークン）として切り出して注入し直さなければならない。 コンテキスト長やトークン制約による情報の脱落が生じやすく、定義の誤読やハルシネーションの温床となる。 第三に、責任境界とトレーサビリティの崩壊である。 出力された集計値に誤りや齟齬があった際、障害箇所の特定が極めて困難になる。 「外部エージェントのプロンプト解釈の誤りなのか」「API連携時のマッピングミスなのか」「基盤側のセマンティック定義の不備なのか」の切り分けに多大な調査コストを強いられる。 第四に、運用の二重化とコストの暴走である。 データプラットフォーム側のコンピュート費用に加え、外部LLMのトークン消費費用、外部エージェントのオーケストレーション保守工数がすべて上乗せされる。 エージェントが最適化されていないアドホックなSQLをDWHに乱発すれば、スキャン費用が青天井に跳ね上がるリスクも抱え込む。 車軸直結のダイレクトドライブと外付け車輪 車軸（データストレージ）とタイヤ（メタデータ・ガバナンス層）が一体化し、そこに直接駆動モーター（ネイティブAI機能）が組み込まれているプラットフォームがある。 この統合された足回りに対し、外部から別のモーター付き車輪を無理やり押し当てて走らせようとする構成は、純粋にアーキテクチャの敗北と言える。 データが存在する場所（ストレージ）、データを意味づける場所（メタデータ）、そしてクエリを処理する場所（コンピュート）が同一境界内にあれば、データ移動は不要となり、ガバナンスも一元的に維持される。 Databricks GenieやSnowflake Cortex、Microsoft Fabric Copilotといった基盤ネイティブの機能は、まさにこの垂直統合によって精度と速度を両立させている。 外部の知能にデータを吸い上げさせるのではなく、データの集積地に直接知能を配置することこそが自然な設計である。 セマンティックモデルとDirect Lakeによる二重構造の解消 この二重構造の解消を示す代表的な実例が、Microsoft Fabricにおける セマンティックモデル と Direct Lake モードの連携である。 Direct Lakeモードでは、OneLake上のDelta Parquetデータに対して、インポート処理やデータの複製を行わず、メモリ上に直接マッピングして高速な集計処理を行う。 外部エージェントがアドホックなSQLをデータウェアハウスに乱れ打ちし、コンピュートリソースを枯渇させる懸念は構造的に排除される。 さらに、ビジネスロジックの管理においてもセマンティックモデルが決定的な役割を果たす。 「粗利」「有効アクティブ顧客数」といったビジネス定義をFabricやPower BIのセマンティックモデル（DAX/メジャー）として一度定義すれば、すべての分析者が単一の真実（Single Source of Truth）を参照できる。 AIに対してプロンプト経由で計算文脈を推測させる必要そのものがなくなり、確定的かつ再現性のある結果を保証できる。 キャパシティ課金によるコストの予測可能性 アーキテクチャの統合は、運用のコスト構造にも明確な差をもたらす。 ...

Statcounterのデータをもとに、米国におけるLinuxユーザーの急増を語る言説が話題を呼んでいる。 しかし、この数値を真に受けるのは早計だ。 実際に管理下のサイトを確認しても、NetlifyのObservabilityにおいてNon-Browser（非ブラウザ通信）が62.5%に達している。 アメリカでLinuxのユーザーが18％を超える Cloudflare Radarのデータも、同様の傾向を示している。 パーソナルコンピュータ市場のハードウェア出荷動向や半導体供給網に構造的な地殻変動が生じていない平時において、デスクトップOSのシェアが数カ月で倍増し、単月で8ポイント近く急伸する現象は、OS普及の歴史において類を見ない。 この数値が公表された直後から、オペレーティングシステムの物理的な実稼働台数を反映したものではなく、Webトラフィックの自動収集スクリプトが引き起こした観測ノイズ（アーティファクト）である可能性が技術コミュニティや業界アナリストによって指摘されている。 Statcounterの集計モデルが抱える構造的脆弱性 Statcounterの統計モデルは、世界100万以上のWebサイトに配置されたJavaScriptトラッキングタグに基づき、月間数十億件に及ぶページビューを集計する手法に依拠している。 この仕組みは手軽に大規模なトラフィック傾向を把握できる反面、OS市場シェアを推計する基盤としては致命的な欠陥を抱えている。 最大の問題は、同社がハードウェアの物理的実稼働台数（Installed Base）や認証されたユニークユーザー数（Unique Visitors）ではなく、単なる タグが発火したページビューの総和 を指標としている点にある。 集計結果は構成比（100％スケール）で正規化される。 そのため、特定のプラットフォームから生成されたページビューの絶対数が急激に膨張した場合、他OSの実利用動向に変化がなくても、そのプラットフォームのシェアが見かけ上跳ね上がり、競合OSの比率が機械的に押し下げられるゼロサム構造となっている。 Statcounterはボットやクローラを除外するフィルタリング処理を講じていると説明している。 しかし、その実体は既知のボットUser-Agent文字列や静的IPリストとのマッチングに過度に依存している。 現代のヘッドレスブラウザや自律型AIエージェントは、正規のデスクトップブラウザと完全に一致するフィンガープリントを偽装して動作する。 そのため、旧来のタグ型解析ロジックでこれらを人間のセッションと見分けて破棄することは事実上不可能に近い。 ログパース処理そのものにも深刻なデータ不整合が散見される。 2026年7月の米国デスクトップデータにおいて、2016年に呼称が廃止されたはずの旧称「OS X」が21.14％から21.81％を占める一方、現行の「macOS」が8.24％から8.6％と過小評価される異常値が記録されている。 過去にもWindows 7が不自然な急増を見せたり、Google検索の市場シェア推計で大きな誤認を生じさせて後に修正したりした経緯がある。 同社の分類器がブラウザのUser-Agent文字列やテレメトリノイズに対して極めて不安定である事実は、過去の事例からも裏付けられている。 外部テレメトリとの比較検証 Statcounterが提示した「Linuxシェア18％超」の妥当性を検証するにあたり、独立した別系統のテレメトリソースとの比較は決定的な材料を提供する。 ゲーミングプラットフォームSteamの統計、米国連邦政府公式ポータルのアクセスログ、ならびにグローバルCDNの通信ログを照合すると、実環境とStatcounterの数値との間に埋めがたい断絶が存在することが明らかになる。 PCゲーミング市場を網羅するSteamハードウェア＆ソフトウェア調査（Steam Hardware & Software Survey）は、クライアントソフトウェアが端末のローカル環境からOS情報を直接取得してサンプリングを行う。 そのため、Webクローラのスクリプト実行に左右されない堅牢性を保持している。 ValveによるProton互換レイヤーの成熟やSteam Deckの普及により、SteamにおけるLinuxシェアは歴史的な高水準に達している。 それでも2026年7月時点で4.01％、英語圏ユーザーを対象とした特定区分でも8.42％にとどまっており、18％という数値とは大きく乖離している。 また、米連邦政府の公式Webサイト群を統合管理する「analytics.usa.gov」のテレメトリは、全米の一般市民による公的窓口へのアクセス実態を反映した、30日間で約16億5000万セッション規模の大規模データセットである。 同統計においてLinuxが占めるシェアは、モバイルを含む全セッション換算で約6.8％である。 モバイル端末（全体の約40％）を除外してデスクトップ環境のみに補正した場合でも、実質的なシェアは約10〜11％にとどまる。 一般市民の日常的かつ実用的な利用環境において、全米のデスクトップPCの5台に1台近くがLinuxへ置き換わったとする証拠は、公的トラフィックの精査からも確認されない。 観測プラットフォーム 測定手法・データ母集団 2026年夏時点のLinuxシェア 特性およびクローラの影響 Statcounter（米国デスクトップ） 提携サイト上のJSタグ発火（ページビュー） 18.19%（前月10.65%） ヘッドレスクローラの実行による水増しリスクが極めて高い Steam Hardware Survey クライアントによる直接システム検出 4.01%（全体） ゲーム実機ベース。Webスクレイパーの影響を原理的に排除 analytics.usa.gov 連邦政府公的Webサイトの全セッション 約6.8%（デスクトップ換算約10〜11%） 一般市民の生活動線を反映。実質シェアは約1割水準 Cloudflare Radar（北米・全通信） エッジ通過の全HTTPリクエスト 平均16%（単日最大22%〜26%） 自動化通信（AIエージェント、ボット）を含む全トラフィック Cloudflare Radar（北米・人間のみ） エッジ行動分析による人間トラフィック 約4.7% 高度な振る舞い検知でボットを除外した実効シェア Cloudflare Radarが証明するボット混入の決定打 全世界のWebトラフィックの約20％を保護、中継するCloudflareのテレメトリ基盤「Cloudflare Radar」のデータは、今回の急増現象の核心を突く反証材料となっている。 ...

更新履歴 2026-03-30: 新規公開。BIの歴史的転換点と、現代における主要ツールの選定指針について詳解。 出来損ないのBI記事 をぶった切ったので、それに続ける感じで。まず、先の記事でもふれたように、Before/After TableauでBIには大きな次元断層があります。 timeline title History of BI Platform 1969 : Cognos 2003 : Tableau 2010 : Power Pivot 2015 : Power BI Desktop Tableau以前（Before Tableau） ダッシュボード（あるいは「経営ボード」）は、あくまで経営層が閲覧するためのものでした。その構築や変更は、外部のベンダーや社内の情報システム部門（情シス）が独占的に行い、現場は「与えられた数字を見るだけ」の存在でした。この記事が語る「モジュール」や「開発費用」といったERP的な発想は、まさにこの時代の遺物です。 Tableau以後（After Tableau） ダッシュボードは「現場の武器」へと変貌しました。閲覧するだけでなく、現場の担当者自身が深く関わり、自らデータを探索し、ダッシュボードを更新・改善していく セルフサービスBI が当たり前となりました。 結果として、Tableauの前と後ではBIを誰が見て、誰が作るのかは決定的に変わりました。単純に言えば、Tableauより前のBIは死亡診断書でした、もう、起きたことをどう処理するか。その意味では管理会計に近い。しかし、Tableau以降では現場自身が次の打ち手を模索するためのツールになった。 Before Tableauの世界観 Viewer：役員・ボード Creator：情シス or 外部ベンダー Explorer：存在しない データは“報告”のためのもの ダッシュボードは“提出物” After Tableau Viewer：現場 Explorer：現場 Creator：現場＋情シス データは“意思決定のためのもの” ダッシュボードは“現場の道具” この部分は重要です。まず、がらっと変わったからです。 結果として、美しさも問われるようになりました。なぜならば、打ち手を模索する思考をアクセラレートするための道具になったからです。 結果として、従来からの棒グラフや折れ線グラフなどに加えて、 ファネルチャート ヒートマップ サンキーダイアグラム などが必要になりました。 これら「高度なViz」が必要になったのは、現場が「何が起きたか」だけでなく、 「なぜ起きたか（原因の究明）」 という外科手術を自ら行うようになったからです。 ここで、SIerによる「数ヶ月待ちのカスタマイズ」などという概念は1オングストロームの価値もなくなります。現場は、今この瞬間にメスを振るいたいのです。 ツール選定の3つの軸 BI ツールを選ぶ際、機能比較以上に重要なのが以下の 3 点です。 ユーザーの技術スタック : SQL を書くのか、 GUI で操作するのか。 データの性質 : 秒単位の監視か、じっくり見る月次レポートか。 運用・接続方式 : 「On the fly (直結型) 」 か、 「Decoupled (絶縁型) 」 か。 「何ができるか」ではなく、 「誰がどう使うか」 から逆算する必要があります。 ...

更新履歴 2026-03-30: PPUの価格改定（2025年4月より24ドル）と、CopilotのF2容量での利用開始（実用上はF64推奨）について情報を更新。さらに、BIにおける「Tableau以前/以後」のパラダイムシフトに関する考察を追記。 中止になったイベントですが BIツール徹底比較〜現場で失敗しないツール選定のチェックポイント〜というイベントが予定されていました。 BIツールの比較系イベントは内容の良し悪しが分かれることが多いですが、スピーカーの所属企業の資料を基に、その内容を考察してみます。 BIツールの完全ガイドという記事が、おそらく講演のベースとなっているものと思われますが、その内容にはいくつか疑問が残ります。 特に、Microsoft Power BIの導入・開発・構築費用は？コストと予算の目安を解説 という記事の記述を見てみましょう。 Microsoft Power BI의ライセンス費用は、Microsoft Power BI導入費用の中で大きな割合を占めることが多い費用です。ライセンス費用は、ユーザー数、導入するモジュール、Microsoft Power BIの バージョンによって異なります。一般的に、ユーザー数が多いほど、導入するモジュールが多いほど、ライセンス費用は高くなります。 現在のPower BIには、機能単位で追加購入する「モジュール」という概念はほぼ存在しません。また、バージョンによって価格が異なるということもありません。 次に、Tableauの導入・開発・構築費用は？コストと予算の目安を解説 も確認してみます。 ライセンス費用は、ユーザー数、導入するモジュール、Tableauのバージョンによって異なります。 Tableauの標準機能で要件を満たせない場合、カスタマイズが必要となり、開発費用が発生します。 これらの記述から推測されるのは、BIツールの導入モデルを ERP（Enterprise Resource Planning） のそれと混同しているのではないか、という点です。 「モジュール選択」「バージョン別の価格設定」「標準機能外のカスタマイズ（アドオン開発）」といった概念は、SAPやOracle EBSなどのオンプレミス型大型ERPの導入作法そのものです。しかし、現代のクラウドSaaS型BIにおいて、これらは全く別の論理で動いています。 根本的な誤解：BIの「Tableau以前」と「以後」 この記事が露呈している最大の欠陥は、BIにおける Tableau登場の前と後 という歴史的なパラダイムシフトを峻別できていない点にあります。 Tableau以前（Before Tableau） ダッシュボード（あるいは「経営ボード」）は、あくまで経営層が閲覧するためのものでした。その構築や変更は、外部のベンダーや社内の情報システム部門（情シス）が独占的に行い、現場は「与えられた数字を見るだけ」の存在でした。この記事が語る「モジュール」や「開発費用」といったERP的な発想は、まさにこの時代の遺物です。 Tableau以後（After Tableau） ダッシュボードは「現場の武器」へと変貌しました。閲覧するだけでなく、現場の担当者自身が深く関わり、自らデータを探索し、ダッシュボードを更新・改善していく セルフサービスBI が当たり前となりました。 現代のBIツール選定において、かつてのERP導入のような「重厚長大で硬直的な開発モデル」を前提に語ることは、現場の機動力と意思決定のスピードを奪うことに他なりません。 特にPower BIにおいては、現在 Microsoft Fabric へのリブランディングが進んでおり、Premium機能の利用はFabricキャパシティに統合される流れにあります。2024年に発表されたロードマップに沿って、従来の「 Power BI Premium 」という枠組みはFabricに収束しつつあります。PPU（Power BI Premium Per User）は現在も購入可能ですが、2025年4月より月額24ドルへと値上げされ、機能追加もFabric容量優先となっているため、新規導入のメリットは薄れています。既存のPPUユーザーは、今後 F-SKU（Fabric容量） へ移行するか、あるいは Pro ライセンスで運用するかという戦略的な判断を迫られています。 現場での選定における真の課題は、以下の3点に集約されると言えるでしょう。 「小規模Premium」の受け皿問題 PPUは少人数でのPremium機能利用に適していましたが、価格改定と機能追加の停滞に伴い、最小構成のFabric容量（F2など）への移行コストとメリットの精緻なシミュレーションが不可欠です。 オートスケールの管理 Fabric容量（F-SKU）への移行は、単なるライセンス管理から、Azureリソースとしての運用設計（一時停止やスケーリング）へと、コスト削減の焦点が移ることを意味します。 Copilotの利用条件 BIにおけるAI活用（Copilot for Power BI）は、現在 F2以上の有償Fabric容量 で利用可能となりました。ただし、実務上で快適に動作させるためには、依然として F64以上 の容量が推奨されることが多く、予算計画においては「最低ライン（F2）」と「実用ライン（F64）」の乖離を考慮する必要があります。 以上のように、参照した記事には現在の市場実態と乖離した、ERP的思考に基づく記述が散見されます。 ...

AIモデルの性能評価や、新しいアルゴリズム（例えば以前取り上げたSVG: Support Vector Generationなど）の実験において、適切なデータセットの選定は極めて重要です。今回は、私がソフトウェアエンジニアリング領域の自然言語処理（NLP）タスクでベンチマークとして愛用している「PROMISE Dataset」について、その構造とAIモデルでの活用実験の経験を交えて紹介します。 PROMISE Datasetとは 私がよく利用しているのは、Software-Requirements-Classification リポジトリに含まれている PROMISE.CSV です。 元々は PROMISE Software Engineering Repository で公開されていたもので、ソフトウェア要件定義書のテキストデータと、それが「機能要件」か「非機能要件」か、さらに細かい分類ラベルが付与されたデータセットです。 データの構造とクラス定義 このデータセットは主に以下の構成になっています。 Project ID: プロジェクトの識別子 Requirement Text: 要件のテキスト（例: “The system shall refresh the display every 60 seconds."） Class: 要件の分類クラス クラス分類は以下の4つが主要なラベルとして使用されています。これらは要件エンジニアリングにおける古典的な分類に基づいています。 F (Functional Requirement): 機能要件。システムが「何を」するか。 PE (Performance): 性能要件。非機能要件の一種。 LF (Look-and-Feel): 外観・操作感。UI/UXに関わる非機能要件。 US (Usability): 使用性。使いやすさに関わる非機能要件。 graph TD Req[Software Requirement] Req --> F[Functional (F)] Req --> NF[Non-Functional] NF --> PE[Performance (PE)] NF --> LF[Look-and-Feel (LF)] NF --> US[Usability (US)] NF --> Other[Other NFRs...] AIモデルによる実験：LLM vs SVG 私はこのデータセットを用いて、いくつかのAIモデルのアプローチを試みてきました。 ...