Semantic SI完全ガイド 2026 — データに意味を、体験に価値を。

「仕様通りに作った。テストも通った。なのに使われない。」

システム開発に関わったことがある人なら、この感覚に覚えがあるだろう。

要件定義書に書かれた通りに実装し、テストをパスし、納品を完了した。しかし半年後、システムの利用率は低いまま。現場はExcelに戻っている。

私たちは2020年の創業以来、100社を超える企業のDX・AI・システム開発を支援してきた。その中で、この「正しく作ったのに使われない」問題に何度も直面した。

原因を突き詰めた結果、一つの結論に到達した。問題は技術ではなく、データの「前提」にある。

データの定義が組織の中で共有されていない。業務の構造がシステム設計に翻訳されていない。機能は正しいのに、前提が食い違っている。これを私たちは「意味のズレ」と呼んでいる。そして、この問題に正面から取り組むアプローチを「Semantic SI」と名付けた。

本記事では、Semantic SIの考え方と方法論を包括的にまとめる。各テーマの詳細は関連記事で深掘りしているので、あわせて参照してほしい。

Semantic SIとは何か

SIはSystem Integration（システム統合）の略だ。従来のSIerは「仕様通りにシステムを作る」ことにコミットする。Semantic SIは、その手前にある「データの定義を統合し、業務体験を改善する」ことにコミットする。

最下行が事業モデルの核心だ。要件定義を「おまけ」ではなく独立した商品として切り出した。この設計思想の詳細は「なぜ要件定義を"買う"べきなのか」で論じている。

なぜ前提がズレるのか — 3つの構造パターン

前提のズレは組織の中に静かに蓄積する。私たちの支援先で頻繁に遭遇するパターンを3つ共有する。（各パターンの詳細な分析は「DXの失敗は"意味のズレ"から始まる」で深掘りしている。）

パターン1: 同じ言葉が違う定義で運用されている

従業員400名規模のB2B SaaS企業で、「チャーンレート」が3つの定義で使われていた。CSはチケットベース、経営企画はARRベース、プロダクトはログイン頻度ベース。毎月の会議で「どの数字が正しいか」に時間が消耗する。

パターン2: データと意思決定の導線が切れている

従業員350名規模の専門商社がDWHを構築したが、経営層の見たい切り口（商品カテゴリ別粗利推移）とデータの集計単位（受注伝票）が合っていなかった。ダッシュボードを誰も見ない状態に。

パターン3: 業務の構造がシステム設計に翻訳されていない

従業員200名規模のEC企業が受注管理を刷新したが、現場の「仮受注→在庫確認→本受注」フローが新システムに反映されていなかった。二重入力が発生し、業務体験はむしろ悪化した。

3つに共通するのは、「仕様レベルでは正しいのに、前提レベルで食い違っている」ことだ。

Discoveryで何をするのか

前提のズレを解消するために、私たちはプロジェクトの最初に「Discovery」というフェーズを置く。4〜6週間、標準450万円。6つの固定成果物を納品する。

• Meaning Map — データ×意思決定×業務×体験の対応表
• KPI定義書 — 主要KPIの定義・算出式・参照元の統一
• To-be業務・体験設計 — 将来の業務フローとユーザー体験
• 価値KPI設計 — 北極星KPIとドライバーKPIの定義・計測方法
• 価値レバー順ロードマップ — 価値インパクト順の開発優先順位
• 依存条件・リスク・意思決定ログ — 前提条件と合意の履歴

これらは「資料」ではなく合意形成装置だ。Discovery後に他社へ開発を依頼しても、成果物は機能する。私たちへの発注を前提としていない。

各成果物の設計思想と詳細な解説は「なぜ要件定義を"買う"べきなのか」を参照してほしい。

実際に何が変わるのか — 2つの事例

事例1: B2B SaaS企業のKPI統合

従業員350名のB2B SaaS企業。「売上」の定義が3つ存在し、毎月の経営会議の最初の30分が数字の確認に消えていた。4週間のDiscoveryでKPI定義を統一し、3ヶ月のDeliveryでデータ基盤とダッシュボードを構築。

Delivery完了3ヶ月後の計測で、数字確認時間は83%削減（30分→5分以内）、ダッシュボード利用者は8倍に。このプロジェクトの全容は事例記事「SaaS企業のKPI統合 — 会議が"数字の正しさ"で消耗しなくなった話」で詳しく紹介している。

事例2: EC企業の受注管理刷新

年商80億円規模のEC企業。受注管理システムを刷新したが、現場の業務フローが新システムに反映されておらず、二重入力が発生していた。Discoveryで業務の構造を可視化し、「仮受注」ステータスを含む再設計を実施。Delivery後、受注処理の手作業は従来の40%に削減され、出荷リードタイムが1営業日短縮された。

2つの事例に共通するのは、技術的な問題ではなく「前提の食い違い」がボトルネックだったことだ。

技術がどう支えているか

Semantic SIは思想だけでなく、技術的な裏付けがある。

私たちはLangChain / LangGraphをベースにしたRAG（Retrieval-Augmented Generation）システムや、AIエージェントの構築を受託開発の中で行っている。これらの技術は「データから意味を取り出し、業務判断を支援する」ためのツールだ。

例えば、社内ドキュメントからの情報検索を自動化する場合、単にベクトル検索を実装するだけでは「検索精度の問題」として片付けられがちだ。しかし実際には、ドキュメント内のデータ定義が統一されていなければ、どれだけ高精度な検索アルゴリズムを使っても的外れな結果が返る。定義の統一が先、技術の実装が後。この順序がSemantic SIの核心だ。

RAGの具体的な実装パターンや技術選定の詳細は「LangChain × RAGの実装パターン比較 — 2026年版」を参照してほしい。

なぜ他のアプローチではダメなのか

課題を解く方法はSemantic SIだけではない。それぞれの限界を書く。

クライアント自力での要件定義。 実装可能性やデータの実態を踏まえない要件は、結局やり直しになることが多い。

コンサルティングファームへの戦略依頼。 戦略は描けるが、実装への責任を持たない。戦略書と実行の間に落ちるものが多い。

アジャイルで走りながら固める。 反復自体は有効だが、「何の価値を出すか」が未定義のまま反復しても収束しない。

BIコンサルによるダッシュボード構築。 KPIの定義が統一されていない状態でダッシュボードを作っても、数ヶ月後にExcelに戻る。

Semantic SIは、これらの隙間を埋める。戦略と実装を繋ぐ合意形成装置であり、データの定義統一を起点にプロジェクト全体の方向を定める。

Semantic SIの限界

万能ではない。以下のケースでは十分に機能しない。

意思決定者が参加できない場合。 定義の統一は経営判断だ。権限者が4〜6週間のDiscoveryに関与できない組織では成立しない。

仕様が完全に固まっている場合。 やるべきことが明確で、データの定義も統一されているなら、Discoveryは過剰だ。従来型のSIの方が効率的だと私たちは考えている。

部門間の政治的対立が深刻な場合。 定義の統一は一部の部門に変化を求める。協力関係が前提として必要だ。

データ整備がゼロの場合。 収集・クレンジングから始めるなら、期間とコストは大幅に膨らむ。

私たちがこのアプローチを取る理由

顧客にとっての合理性だけでなく、提供する私たちにとっての合理性も書く。

「作ったものが使われない」経験を繰り返したくない。前提の食い違いを先に解消すれば、この事故を構造的に減らせる。手戻りが減り、作ったものが使われる確率が上がる。

そしてもう一つ。データの定義を扱う仕事は、まだ誰も体系化していない。要件定義書には「仕様」が書かれるが「定義」は書かれない。この見えない領域に名前を付け、方法論を作り、商品化する。それ自体が、私たちがやる理由だ。

あなたの組織に、Semantic SIは必要か

以下の条件に当てはまる企業に、最も高い効果を発揮する。

• 複数のシステムが混在している。 基幹、会計、SFA、CS、BI、そしてExcel。データが散在し、統合が手作業
• KPIの定義が部門で割れている。 会議が「数字の正しさ」の議論で消耗している
• 意思決定が遅い。 月次の確定、承認、レポートのリードタイムが長い
• 意思決定者がプロジェクトに参加できる。 権限者が4〜6週間のDiscoveryに関与可能

4つのうち3つ以上に該当するなら、まず60分の無料相談で「自社に前提のズレがあるかどうか」の初期診断をお勧めする。診断後、Discoveryに進むかどうかは御社の判断だ。

仕様通りに作っても使われないシステムに数千万円を投じるか、まず450万円で前提を揃えるか。答えは構造が教えてくれる。