Analytics

更新履歴 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モデルのアプローチを試みてきました。 ...

2023年にリリースされた書籍「実践Julia入門」は、科学技術計算の領域で注目を集めるプログラミング言語 Julia の包括的な解説書です。本記事では、この書籍のレビューを通じて、Juliaがなぜ「 貪欲な言語 」と称されるのか、その魅力と強力な機能について探っていきます。 なぜ今、Juliaなのか？ Pythonの 手軽さ とC言語のような 実行速度 を両立させることを目指して開発されたJuliaは、特にデータサイエンス、機械学習、数値計算の分野でその真価を発揮します。動的言語でありながら、JIT (Just-In-Time) コンパイラによって高いパフォーマンスを実現。それでいて、数学的な記法に近い直感的な構文は、研究者やエンジニアがアイデアを素早くコードに落とし込むことを可能にします。 本書は、そんなJuliaのポテンシャルを最大限に引き出すための知識が凝縮された一冊です。 書籍「実践Julia入門」の概要 本書は「入門編」「基本編」「実践編」の3部構成となっており、初学者から実務でJuliaを活用したい中〜上級者まで、幅広い層を対象としています。以下にその広範な内容を示す目次を掲載します。 【入門編】 第1章 Juliaのインストールと開発: Juliaの基本的な特徴から、REPL、JupyterLab、各種エディタでの開発環境構築までをカバーします。 第2章 Juliaの基本文法: 変数、演算子、関数、制御構文といったプログラミングの基礎を学びます。 【基本編】 第3章 Juliaの標準ライブラリ関数: 豊富な標準関数やライブラリの使い方を解説します。 第4章 型システム: Juliaの柔軟かつ強力な型システムの概要、パラメトリック型、ユーザ定義型などを掘り下げます。 第5章 多重ディスパッチ: Juliaの最たる特徴である多重ディスパッチの概念と、ポリモーフィズムや演算子オーバーロードといった実用例を詳解します。 第6章 イテレーション: Juliaにおけるイテレーションの仕組みと、カスタムイテレータの実装方法を学びます。 第7章 ブロードキャスティング: . 構文を用いた効率的な要素ごとの演算（ブロードキャスティング）の仕組みと応用を解説します。 第8章 メタプログラミング: マクロや生成関数など、コードを生成するコードを書くための高度なテクニックを紹介します。 第9章 並行・並列処理: タスク、スレッド、マルチプロセスを活用したハイパフォーマンスコンピューティングへの道筋を示します。 第10章 パッケージマネージャ: 依存関係の管理や環境の再現性を保つためのパッケージマネージャの利用法を解説します。 【実践編】 第11章 数値計算: NLsolve.jl や DifferentialEquations.jl を用いた、非線形方程式や常微分方程式の解法を実践します。 第12章 データ解析: CSVやDataFrames.jlを使ったデータの読み込みから、基本的な統計処理までの一連の流れを追体験します。 第13章 機械学習: MLJ.jl や Flux.jl といったフレームワークを使い、Juliaでの機械学習パイプライン構築を学びます。 Juliaの”貪欲さ”を支える核心機能 本書の白眉は、単なる文法解説に留まらず、Juliaを特徴づける核心的な概念に深く踏み込んでいる点です。特に「基本編」で解説される以下の機能は、Juliaの”貪欲さ”、すなわち 表現力とパフォーマンスの両立 を理解する上で欠かせません。 ...

「日本企業が、わずか32個のパラメータで大規模言語モデル（LLM）に匹敵する性能を持つ生成AIを開発。GPUは不要で、汎用CPUで動作する」――。先日、I.Y.P Consulting社から発表されたこのニュースは、多くのAI関係者に衝撃を与えました。 これまでAI業界では、モデルの性能はパラメータ数と計算資源に比例するという「スケール則」が常識とされてきました。しかし、そのスケール則も実用上の壁に突き当たりつつあります。一説には、かつて存在した超巨大モデル「GPT-4.5」は、そのあまりのサイズと高額な利用価格から、ごく短期間でサービス終了に追い込まれたとも言われています。実際、その価格は入力が100万トークンあたり75ドル、出力が150ドル以上と、従来のモデルとは比較にならないほど高コストなものでした。また、GPT-5をはじめとする最新モデルが、単純な巨大化ではなく、複数の専門モデルを連携させる効率的なMoE（Mixture-of-Experts）アーキテクチャを採用していることも、この流れを裏付けていると言えるでしょう。 このような「巨大化路線の限界」が見え始めた今、SVGの登場はどのような意味を持つのでしょうか。本稿では、プレスリリースの見出しの先にある学術論文の真実に迫り、話題のAI「SVG」の驚くべき真相と、ビジネスにおける本当の価値を解き明かしていきます。 衝撃の発表：GPU不要の「LLM」が日本から登場？ I.Y.P Consulting社のプレスリリースや各種ニュース記事で報じられた「SVG（Support Vector Generation）」の性能は、まさに革命的でした。その主張の要点は以下の通りです。 パラメータ数はわずか32個 でありながら、LLMに匹敵する性能を持つ。 高価な GPUを一切必要とせず 、一般的なCPUでリアルタイムに稼働する。 応答速度は 1ミリ秒 と非常に高速。 言語理解能力の国際的な指標であるGLUEベンチマークにおいて、GPTを上回る精度を達成。 これらの特徴は、AI導入の障壁となっていた高コストなインフラ問題を解決する可能性を示唆し、大きな注目を集めました。しかし、この発表の根拠として提示された、国際会議へ投稿された論文を精査すると、話はより複雑で、ある意味ではさらに興味深いものになります。 まず、SVGの主なターゲットタスクは、ChatGPTのような自由な文章を生成することではなく、与えられた文章を特定のカテゴリに分類する テキスト分類 (text classification) です。例えば、「この映画は素晴らしかった」というレビューを「ポジティブ」に分類するのがテキスト分類であり、「この映画のレビューを書いてください」という指示に応えて新しい文章を作成するのがテキスト生成です。両者は根本的に異なるタスクなのです。 次に、最もセンセーショナルな「パラメータ数はわずか32個」という主張。これは従来のニューラルネットワークにおけるパラメータとは意味が異なります。論文を読み解くと、この数字はLLMのモデルサイズを示す「重み」の数ではなく、分類の境界線を定義するために使われる最も重要なサンプル文（ サポートベクトル (support vectors) ）の数を指している可能性が極めて高いです。これはモデルの規模ではなく、特定の分類問題の「複雑さ」を示す指標と言えます。 そして、「GPTを上回る精度」という点も、より正確な理解が必要です。論文の実験結果（Table 2）によれば、SVGが上回ったのは、ファインチューニングされた最新のGPTモデルではなく、特定のゼロショット学習手法（ プロンプティング (prompting) ）というベースラインです。これは大きな成果ですが、あらゆる面でGPTを超えたと解釈するのは早計です。 SVGの核心技術：「言語をカーネルとして使う」という新発想 では、SVGはどのようにしてこれほど軽量でありながら高い分類性能を実現しているのでしょうか。その核心は、論文タイトルでもある「Language as Kernels（カーネルとしての言語）」という革新的なアプローチにあります。SVGはLLMを代替するのではなく、いわば巨大なLLMの『脳』の一部を借りてくる、共生関係にも似た新しいアプローチなのです。 この仕組みを具体的に見てみましょう。まず、SVGに「ポジティブなレビュー」と「ネガティブなレビュー」の例を少数与えます。するとSVGは、GPT-4.1のような強力なLLMを、新しいレビューを書かせるためではなく、「類似性判定の審判」として利用します。新しい文章が入力されると、LLMに「この文章は、私が知っているポジティブな例とどれくらい似ていますか？ネガティブな例とはどうですか？」と問いかけ、その類似度スコアを テキスト埋め込み (text embeddings)という形で受け取ります。最後に、この類似度マップを、古くから知られる超高効率なアルゴリズムであるサポートベクターマシン (Support Vector Machine) に入力し、最も効果的な分類の境界線を引かせるのです。 しかし、SVGの真の独創性はここからさらに一歩進みます。その名の「Generation（生成）」が示す通り、SVGは単に既存のサンプルを使うだけではありません。論文で述べられているように、マルコフ連鎖モンテカルロ（MCMC）法という手法を用いて、分類の境界線をより明確にするための新しい、高品質なサンプル文（サポートベクトル）を 自動的に生成 するのです。これは、選挙の情勢調査員が、既存の有権者の意見を使うだけでなく、両党の支持を分ける境界線を正確に見つけるために、絶妙な特徴を持つ「仮想の有権者プロフィール」を巧みに作り出すようなものです。SVGはこれを言語で行い、わずかな初期データから極めて精度の高い分類器を構築することを可能にしています。 論文では、このアプローチの理論的正当性について次のように述べられています。 本研究では、このパラドックスを解決すべく、カーネルマシンという機敏で洗練されたパラダイムを導入します。本稿では、ゼロショット学習とカーネルマシンが数学的に等価であることを示す、説得力のある証明を提示します。 査読プロセスで明らかになった課題 この有望に見えるSVGですが、その根拠となった論文「Language as Kernels」は、トップレベルのAI国際会議であるICLR 2024において 不採択（Reject） となっています。査読プロセスにおいて、複数の専門家からいくつかの重要な懸念が示されました。 新規性と貢献の不明確さ: 既存研究との比較が不十分で、このアプローチが持つ独自の貢献が何であるかが明確ではない。 実験評価の限定性: 実験が小規模なデータセットに限定されており、より大規模で多様なタスクにおいてその有効性が実証されていない。 主張の妥当性への疑問: 「CPUで動作する」と主張しながら、実験ではOpenAIのAPI（外部のGPUリソースを多用する）が利用されており、主張と実態に乖離がある。 これらの指摘は、SVGがまだ研究開発の途上にある技術であり、その性能や実用性については、プレスリリースが示唆するほど確立されたものではないことを意味します。 SVGが持つ「本当の強み」：速度、コスト、そして説明可能性 では、SVGは単なる誇大広告なのでしょうか。論文が発展途上であるという事実は、その価値を損なうものではありません。むしろ、SVGが「ChatGPTの代替ではない」からこそ、特定のビジネス用途においてLLMを凌駕する強力なメリットをもたらす可能性を秘めています。 圧倒的なスピードと低コスト (Overwhelming Speed and Low Cost) 最終的な意思決定を担うSVMのアーキテクチャが非常にシンプルであるため、CPU上でも驚異的な速度で動作します。これにより、高価なGPUインフラへの投資が不要となり、運用コストを劇的に削減できます。 ...