Tsurugi DB（劔）とは？アーキテクチャや料金、導入事例を徹底解説

Tsurugi DB（劔／つるぎ）は、NECとノーチラス・テクノロジーズがNEDO支援のもとで開発した、国産オープンソースの次世代リレーショナルデータベースです。

メニーコアCPUと大容量メモリを前提に設計されており、Hybrid Concurrency Controlという独自方式でバッチ処理とオンライントランザクションを同時に高速実行できる点が最大の特徴です。

本記事では、2026年7月時点の最新情報をもとに、Tsurugiのアーキテクチャ、性能ベンチマーク、料金体系、導入方法、他RDB／HTAP潮流との違い、九州電力・千葉大学など2026年事例、そして導入判断で押さえるべき論点までを体系的に解説します。

Tsurugi DB（劔）とは？メニーコア時代の国産オープンソースRDB

Tsurugi DB（劔／つるぎ）とは、NECとノーチラス・テクノロジーズがNEDO支援のもとで開発した、国産オープンソースの次世代リレーショナルデータベース管理システムです。

情報科学的には、メニーコアCPU・大容量メモリを前提に再設計された「新世代のインメモリRDB」で、Hybrid Concurrency Controlという独自の並行性制御でバッチ処理とオンライントランザクションを同一エンジン上で高速処理できる点が伝統的なRDBとの最大の差になります。

2026年現在、Tsurugiは単なる高速RDBの枠を越え、光電融合の分散基盤や医療研究データ、電力系の地域分散インフラを支える国産データ基盤として位置づけられつつあります。

千葉大学の医療データ研究基盤や九州電力の地域分散型デジタルインフラ検証、そしてNEDOの光電融合実証といった領域で、Tsurugi関連の事例発表・検証が相次いで公表されていることが、この潮流を象徴しています。

Tsurugiという名前の意味と開発体制

「劔（Tsurugi）」は日本古来の両刃の剣を意味する言葉で、バッチ処理とオンライン処理という「両刃」を1つのDBで扱うという設計思想を体現しています。

開発はノーチラス・テクノロジーズとNECを中核に、東京工業大学・慶應義塾大学・名古屋大学・大阪大学・国立天文台などが参画するオールジャパン体制で行われました。

母体となったNEDOプロジェクトは2018〜2022年の期間に実施され、2023年10月にオープンソース版が公開、2024年9月にGA（一般提供開始）を迎えています。

ここでのポイントは、現行RDBが前提にしている「シングルコア＋メモリ制約」というハードウェア仮定が、すでに現実と乖離しているという点です。

現代のサーバは100コア超・数TBメモリを積むのが当たり前になっていますが、既存RDBはコア数を増やしても性能が頭打ちになりやすい設計のままです。

Tsurugiは「そもそもRDBをメニーコア前提で作り直す」というアプローチを取ったことで、次のセクションで見る Hybrid Concurrency Control が成立しています。

Tsurugiが「バッチとオンラインを同時に高速処理」できる仕組み

Tsurugiの技術的な独自性は、**Hybrid Concurrency Control（ハイブリッド並行性制御）**という並行性制御方式にあります。

従来のRDBは「短時間で終わる短トランザクション（OLTP）」か「長時間かかるバッチ処理（OLAP／長時間トランザクション）」のどちらかに最適化されており、両方を同じエンジンで走らせるとロック競合で性能が崩れるのが常識でした。

Tsurugiはトランザクションの性質に応じて異なる制御方式を動的に切り替えることで、この制約を解いています。

OCCとLTXを切り替える2段階の並行性制御

Tsurugiは2種類の並行性制御プロトコルを組み合わせて動作します。以下の表で、それぞれの役割を整理しました。

この2つがどちらも独立に、あるいは組み合わせでシリアライザブル（完全に順序化された実行と同じ結果）を保証する設計になっています。

つまりTsurugiは、オンラインの短い注文処理と、夜間に走らせていた集計・締めバッチを、同じデータに対して同時に走らせても壊れないという状態を作れます。

夜間バッチの実行時間を削れるだけでなく、そもそも「夜間バッチ」という運用概念そのものを再設計できる点が大きな変化です。

MVCCとインメモリ設計で読みが書きをブロックしない

Tsurugiは並行性制御の上に、MVCC（Multi-Version Concurrency Control）とインメモリ処理を組み合わせています。データの読み書きは基本的にメモリ上で行い、永続化ストレージ層は「データを失わないため」に限定して使う設計です。

Tsurugi公式は、この構造を「メモリ内部にroot／node／valueのツリーを展開し、SSD上にログだけを持つ」形で図示しています。

Tsurugiのメモリ内部構造とSSDログ配置（出典：劔"Tsurugi"とは）

図の上半分（メモリ）で通常のデータ処理が完結し、下半分（SSD）は障害時のリカバリ用ログに徹する構成です。
ディスクI/Oが処理経路のクリティカルパスから外れるため、ロック競合と並んでRDBのボトルネックとされてきた「ディスクへの書き込み待ち」が実効的にゼロに近づきます。

MVCCを採用することで、同じレコードに対する複数バージョンが並存でき、読み取りは書き込みをブロックしないという状態が保てます。長時間のバッチ処理が走っている最中でも、オンラインの読み取りクエリは待たされずに応答を返せる点が、従来のロックベースRDBとの決定的な違いです。

MVCCによる読み書き非ブロッキングの仕組み（出典：劔"Tsurugi"とは）

同じレコードAに対して version_a（読み手が参照中）と version_b（書き手が更新中）が同時に存在しており、読み手は書き込み完了を待たずに古いバージョンを読み、書き手は既存の読み取りをブロックせずに新バージョンを作れる——これが「読みが書きを止めない」設計の実体です。

加えて、更新はロックフリーなアルゴリズムで実装され、コミットもグループコミットで永続化層のオーバーヘッドを最小化しています。

この設計により、次のセクションで扱う「630万TPS」という性能値が現実的に達成可能になっています。

コンポーネント分割された内部アーキテクチャ

Tsurugiは、モノリシックな1バイナリではなく、コンポーネント単位で分割されたアーキテクチャを採用しています。

GitHubリポジトリで公開されている構成を整理すると次のとおりです。

• トランザクションエンジン層
  shirakami（同時実行制御）、yakushima（メモリ内インデックス）、limestone（トランザクションログストア）、sharksfin（KVSアダプタ）
  
  

• SQL実行エンジン層
  jogasaki（スケジューラ・インタプリタ）、mizugaki（パーサを含むコンパイラ）、yugawara（意味解析・最適化）、takatori（中間表現ユーティリティ）
  
  

• データベースフレームワーク層
  tateyama（コンポーネントフレームワーク）、tateyama-bootstrap（サービス起動）

公式サイトでは、これらのコンポーネントが外部インターフェース群と接続される全体像を1枚に整理しています。

Tsurugiのコンポーネント階層と外部インターフェース（出典：劔"Tsurugi"とは）

左側「外部interface」にIceaxe（Java API）／WebAPI／JDBC・ODBCが並び、右側「Tsurugi本体」でTsubakuro → Jogasaki → Mizugaki → Shirakami（Yakushima内包）→ Limestoneのスタックが縦に積まれています。

各コンポーネントは独立したリポジトリで管理されており、たとえば「Shirakamiの並行性制御アルゴリズムだけ差し替える」「Mizugakiのパーサだけ別実装に切り替える」といった実験や拡張が現実的にできる構造になっています。

これは学術研究と商用実装を両立させるための設計でもあり、大学研究チームが新しい並行性制御プロトコルを研究成果として組み込みやすい土壌になっています。

Tsurugiの性能実測とベンチマーク

Tsurugiの性能値は、単発のベンチマーク数値だけでなく、実データを使った検証結果として複数公開されています。ここではメーカー公表値、独立ベンチマーク、実業務検証の3つの角度から整理します。

約630万TPS・158ナノ秒応答という公式公表値

Tsurugi公式が公表している代表的な性能値は、1ノードあたり約630万TPS・158ナノ秒の応答遅延です。

同じ数値は、公式ページ本文では「1ノード112コア環境で約630万TPS」、同ページ掲載のYCSB-A表では「128コア行で6,327,690 TPS／158ナノ秒」として示されています。

以下の表で、ハードウェア構成別の性能値を整理しました。

Tsurugi公式は、コア数を1から128まで段階的に増やしたYCSB-A／Cベンチマークの実測値も細かく公開しています。

YCSB-A／CでのTsurugi性能実測値（出典：劔の特徴）

表の128コア行ではYCSB-Aが6,327,690 TPS／158ナノ秒、YCSB-Cが6,845,742 TPS／146ナノ秒、その一方で1コア環境では6〜7万TPSに留まる——コア数の増加に対してスループットがほぼ線形に伸びる様子が数値で確認できます。
ここでの「TPS」はトランザクション毎秒、つまり1秒間に処理できる論理的な取引の数です。

銀行系の勘定処理や証券のティック処理を想定すると、100万TPSを超える領域は「基幹系のピーク負荷を1台のRDBで受けられる」水準になります。

重要なのは、この性能値がコア数に対してほぼリニアにスケールする点です。

既存RDBでは32コアを超えると内部のロック競合で性能が伸び悩むケースが多いのに対し、Tsurugiは100コア超のメニーコア規模まで一貫して性能を出せる設計になっています。

200万件超のバッチ処理を13分39秒で完了

ノーチラス・テクノロジーズが公開した実業務データを用いた検証は、Tsurugiのバッチ処理性能を具体的に示す事例として参考になります。

• 業務内容
  BOM（部品表）を再帰的に展開しながら原価影響額を計算する、製造業で典型的な原価計算バッチ
  
  

• データ量
  209,297個のタスクから2,132,133件のレコードを生成、1レコードあたり46カラム
  
  

• 処理時間
  シングルスレッドでは1時間以上完了せず。最適なスレッド数（36〜52）では13分39秒で完了、秒あたり約2,603件のレコード処理を実現

ここで注目すべきは、シングルスレッドと多重スレッドの差が「数倍」ではなく「完走可否」の差になっている点です。Tsurugiは並列処理を前提に設計されているため、並列度を上げるほど性能が伸びる構造になっています。

同じ処理をApache Sparkで実行した際の比較検証では、**Sparkで約50分かかっていたバッチが Tsurugi では約2分（25倍高速化）**で完了したケースも報告されています。

分散処理フレームワークを持ち出すまでもなく、1台のTsurugiで完結できる領域が広い点が実務上の価値になります。

継続的なベンチマーク運用で品質を担保

Tsurugiの性能値は「一度計測した最良値」ではなく、Continuous Benchmarkingによって継続的に検証されている点も特徴です。

CIパイプラインにベンチマーク実行が組み込まれており、コミット単位で性能劣化を検出できる体制になっています。

これは実運用に耐えるRDBを目指すうえで重要な設計判断で、「新機能を追加したら性能が落ちていた」という事故を防ぐ仕組みです。

ベンチマーク実行はGitHub Actionsで定期実行され、Bencherで履歴とレポートを内部的に継続追跡する運用になっています。

Tsurugiと他RDB／HTAP潮流との違い

Tsurugiを評価するには、既存のRDBおよび2026年時点で並走しているHTAP／LTAPの潮流と比べて何が違うかを整理する必要があります。

ここでは PostgreSQL／Oracle 系との差、TiDB／SingleStore などのHTAPとの差、そして Databricks LTAPの立ち位置の3軸で見ていきます。

PostgreSQL・Oracle系との違い

まず伝統的なRDBとの比較です。以下の表で、Tsurugiと主要な既存RDBの位置づけを整理しました。

この比較で押さえておきたいのは、Tsurugiは既存RDBの「置き換え」を目指すというより、メニーコア環境で性能が頭打ちになる領域を新設計で解くというポジションを取っている点です。

既存の業務システム全体をTsurugiに移行する必然性は薄く、「メニーコアサーバを買ったのに性能を出しきれていない基幹バッチ」や「オンラインとバッチの分離運用が限界に来ている勘定処理」など、既存RDBが構造的に苦手な領域だけをTsurugiに寄せるという選定判断が現実的です。

TiDB・SingleStoreなど分散HTAPとの違い

近年注目されている HTAP（Hybrid Transactional and Analytical Processing）系DBとの比較も重要です。

TiDBやSingleStoreは、OLTPとOLAPを1つのシステムで扱うという目的はTsurugiと似ていますが、アプローチが逆方向を向いています。

• TiDB
  分散KVSであるTiKV（行指向）と列指向のTiFlashをRaftで同期する、スケールアウト前提の分散HTAP。複数ノードを並べて水平スケールする
  
  

• SingleStore
  1つの汎用ストレージフォーマットで両ワークロードを扱う分散型HTAP。クラスタ構成での運用が前提
  
  

• Tsurugi
  1台のメニーコアサーバの性能を極限まで引き出すスケールアップ型。分散DB機能はまだ2026年ロードマップに載っている段階

つまりTsurugiは「1台で完結する日本国内の基幹業務」を主戦場に置いており、グローバル規模の分散トランザクションを想定するTiDB／SingleStoreとは想定シナリオがそもそも違います。

自社のトランザクション量が1台で捌ける規模であれば、分散DB特有の運用複雑性を持ち込まずに済むTsurugiの方が扱いやすい選択肢になります。

Databricks LTAPとの位置関係

2026年6月にDatabricksが発表したLTAP（Lake Transactional/Analytical Processing）は、OLTPとOLAPを「1つのレイクストレージ上」で統合するアプローチです。

TsurugiやTiDBが「エンジンレベルで両ワークロードを統合する」のに対し、LTAPは「ストレージレイヤーで統合し、コンピュートは分離する」という思想を取ります。

• Tsurugi（エンジン統合型）
  1つのRDBエンジンでOLTPとバッチを同時に扱う
  
  

• Databricks LTAP（ストレージ統合型）
  Delta Lake上に単一データコピーを置き、トランザクションはサーバレス、分析は既存の分散コンピュートで実行
  
  

• 従来型（分離アーキ）
  OLTPは専用RDB、OLAPはDWH／レイクハウスに分離し、CDC／zero-ETLで同期

2026年時点の実務では、分離アーキ＋CDC／zero-ETLも依然として有力な選択肢として広く使われており、Tsurugi・TiDB・LTAPのいずれも単独で市場を支配してはいません。

CDC（変更データキャプチャ）のレイテンシが分単位まで下がり、Aurora zero-ETL・Fabric Mirroring・ClickPipesなどのマネージドサービスがパイプライン運用の負荷を下げたことで、「無理して1エンジンに統合しなくてもよい」という選択肢が現実的になっているためです。

そのなかでTsurugiが有利になるのは、低レイテンシの同一データ更新・読み取りが業務要件で、かつ分散運用のコストを避けたいシナリオです。

国内の基幹系・準基幹系で「メニーコアサーバ1台で完結させたい」という要件があれば、LTAPや分散HTAPよりTsurugiの方が扱いやすくなります。

Tsurugiの導入方法と対応インターフェース

Tsurugiは開発初期から「試しやすさ」に配慮されており、DockerイメージとJava/JDBCクライアントが公式提供されています。

ここでは導入手順の全体像と、利用可能な接続インターフェースを整理します。

Dockerイメージで即座に起動

Tsurugiは公式Dockerイメージが用意されており、1コマンドで起動できます。

公式ドキュメントの基本コマンドは次のとおりです。

docker container run -d -p 12345:12345 --name tsurugi ghcr.io/project-tsurugi/tsurugidb

このコマンドで、Tsurugiサーバがコンテナとして起動し、ホストの12345番ポートでリスンする状態になります。コンテナの状態確認は docker container ls、ログ確認は docker container logs の標準的なDocker運用と同じ流れで扱えます。

外部のクライアントから接続する場合は、TCPポート12345経由でセッションを構築します。ローカル検証だけでなく、リモートホストにデプロイしたTsurugiサーバに対しても、JavaクライアントAPIでホストとポートを指定して接続できます。

本番運用向けには、Dockerイメージだけでなくソースからのビルド・パッケージインストールも用意されており、Supported Platformsで対応環境が公開されています。

主なクライアントとツール群

Tsurugiは公式リポジトリで複数言語・複数プロトコルのクライアントを提供しており、業務側の言語や既存資産に合わせて選択できます。

公式READMEで案内されているクライアント／ツールを整理すると以下のとおりです。

実務では、既存のJavaアプリケーションからJDBC経由で繋いで検証を始め、性能が要求される本番系ではTsubakuro／Iceaxeネイティブクライアントに切り替えるパターンが自然です。

BIやデータ分析はODBC／Python DB-APIで拾い、AIエージェントとの連携は後述のTsurugi MCP Serverを経由させる、といった役割分担が可能です。

特にIceaxeは、Tsurugi固有のHybrid Concurrency Control（OCC／LTX）を明示的に指定できるAPIになっており、トランザクションの性質に応じた最適な制御方式を選択できる点がJDBC経由の呼び出しに対する優位性になります。

Tsurugi UDFでユーザー関数をgRPCサービス化

拡張性の観点で押さえておくべきなのが、Tsurugi UDF（ユーザー定義関数）です。

UDFといえば通常はDBサーバ内部に組み込む関数を指しますが、Tsurugi UDFはgRPCサービスとして外部プロセスに実装した関数を、SQL文の中で呼び出せる仕組みになっています。

この設計により、たとえば「機械学習モデルの推論を別プロセスで動かし、SQLの WHERE句や SELECT句からその結果を使う」といった構成が、DBサーバのプロセス空間を汚さずに実現できます。

Tsurugi公式は、この延長線上でLLMアプリケーションとMCP経由でTsurugiを組み合わせるパターンも提示しています。

LLMアプリケーション・MCPツールキットとTsurugiの連携構成（出典：劔"Tsurugi"とは）

フロントエンドからの問い合わせがDifyやLangGraph等のワークフローフレームワークに渡り、そこでvLLMやOllamaといったローカルLLMプラットフォームを呼び出す一方、業務データへのアクセスはMCPツールキット→Tsurugi mcp-server→Tsurugi client（iceaxe）経由でSQL実行に落ちる構成です。

AIエージェントや推論サービスと業務データを組み合わせるユースケースで、レイテンシ低く柔軟に呼び出せる拡張手段として2026年時点で注目されているポイントです。

Tsurugiのサポート料金と提供形態

Tsurugiは Apache License 2.0 のオープンソースとして公開されているため、ソフトウェア本体のダウンロードと利用は無料です。

ただし本番運用を想定する場合、ノーチラス・テクノロジーズが提供する商用サポートを契約するのが現実的な選択になります。

OSS版とサポートプランの構成

以下の表で、Tsurugiの提供形態と価格帯を整理しました。

2026年7月時点のノーチラス・テクノロジーズ公式によれば、両プランともに開始価格は200万円／年〜となっており、具体的な差額はサーバ規模・運用体制に応じた個別見積もりです。

スタンダードは「製品仕様に即した回答」に留まる一方、エンタープライズは業務要件に踏み込んだアーキテクチャレビュー、コードレビュー、障害時の暫定パッチまで含まれる違いがあります。

開発初期・PoC段階ではスタンダードで足り、本番投入・大規模運用に踏み出す段階でエンタープライズに切り替えるのが自然な流れです。

商用サポートを取るかどうかの判断軸

OSS版だけで運用するか、商用サポートを契約するかは、以下の3つの観点で判断すると迷いが減ります。

• 本番SLAの要求水準
  基幹系・準基幹系に載せるならエンタープライズサポートが現実的な選択肢になる。データベースの障害時にベンダー側で暫定パッチを提供してもらえるかは、SLA担保の核心になる
  
  

• 社内DBA／エンジニアの練度
  Tsurugiは新世代DBのためコミュニティ知見の蓄積がまだ薄く、独力での問題切り分けは負荷が高い。既存OSS RDB運用に慣れたチームでも、Tsurugi固有の Hybrid CC 挙動の解釈には時間がかかる
  
  

• 業務要件のクリティカリティ
  検証・開発用途ならOSS版で十分。ミッションクリティカル領域ではベンダーサポートを取っておいた方が、経営層への説明責任も担保しやすい

商用サポートを取らずにOSS版だけで運用する選択肢もありますが、その場合は自社DBA／SREチームがTsurugiの内部構造・並行性制御アルゴリズムを深く理解している必要があります。準拠先の少ない新世代DBを本番系で使う判断はハードルが高いため、まずはPoCをOSS版で回し、本番投入と同時にエンタープライズサポートに切り替える流れが実務的です。

Tsurugiの導入事例と2026年ロードマップ

Tsurugiは2024年9月のGA以降、公式検証・PoC・関連事例の公表が順次進んでいます。

2026年に入ってからは、電力・医療・光電融合という異なる領域でTsurugi関連の発表・検証が公開されている点が特徴的です。ここでは代表的な事例と、2026年のロードマップ公表状況を整理します。

2026年7月15日には、ノーチラス・テクノロジーズ主催で事例紹介セミナーが開催され、後述の千葉大学と九州電力がゲスト登壇する予定です。

Tsurugi事例紹介セミナー2026の登壇者と開催概要（出典：PR TIMES）

登壇者に千葉大学データサイエンスコアCTO・特任講師の根津智幸氏、九州電力 情報通信本部 ICT事業推進グループ チーフアーキテクトの矢野恒氏が並び、ノーチラス側は代表取締役会長・Tsurugi開発責任者の神林飛志氏が登壇する構成です。会場はTKP東京駅カンファレンスセンター、時間は14時〜17時です。

千葉大学の医療データ研究基盤

2026年7月15日開催のTsurugi事例セミナー2026では、千葉大学データサイエンスコアCTO・特任講師の根津智幸氏が「医療データを扱う研究基盤を超高速RDBと光ネットワークで支える」というテーマで登壇する予定と告知されています。

本番採用の詳細はセミナー当日の発表に委ねられていますが、演題自体が「医療データ研究基盤におけるTsurugi関連の取り組み」として公表されている点は、記事執筆時点で追える一次情報の範囲です。

医療データは個人情報を含むため外部クラウドに預けにくく、閉じたドメイン内で大規模データを高速に扱える基盤が求められる領域です。

Tsurugiのメニーコア×インメモリ設計は、閉域環境で1台の高性能サーバに集約できる特性が、こうした研究基盤側の要件と噛み合いやすい構図と言えます。

九州電力主導の地域分散型デジタルインフラ

2025年9月に発表された九州電力主導の地域分散型デジタルインフラ実証プロジェクトでは、九州電力・IIJ・QTnet・1FINITY・ノーチラス・テクノロジーズが参画し、分散データベース技術を含む検証が行われています。

九州電力の公表資料自体にTsurugi名は明記されておらず、Tsurugi側の関与はノーチラスの参画と、後述のセミナー登壇テーマから確認できる範囲です。

矢野恒氏（九州電力 情報通信本部 ICT事業推進グループ チーフアーキテクト）が、2026年7月15日のTsurugi事例セミナー2026で「九州版ワットビット連携について」および「分散デジタルインフラ検証事業の検証結果報告」を発表する予定と告知されており、この場でTsurugiとの連携内容が共有される見込みです。

電力インフラは「地理的分散」「災害耐性」「低レイテンシ」の3点を同時に満たす必要があり、既存のクラウドDBには扱いにくい要件です。

国産RDBかつメニーコア環境で完結できるTsurugiが、こうした地域分散型インフラ検証の中でどの層を担うかがセミナー当日の焦点になります。

NEDO光電融合技術との分散計算基盤実証

2026年5月21日には、NEDO委託事業として光電融合技術×分散データベースの実証が成功したことが公表されました。

光チップ・光トランシーバ・光ネットワークで低遅延にデータを運び、離れた場所にある計算資源を1つのシステムのように使う「次世代分散コンピューティング基盤」の中で、Tsurugiが分散データベースとして採用されています。

このプロジェクトが解こうとしているのは、データ処理量の拡大・電力消費量の低減・耐障害性の向上という3課題の同時解決です。光電融合による低遅延通信を活かし、Tsurugiが分散拠点のデータを一貫性を保ったまま束ねる、という構成になります。

日本の先端研究インフラで実証採用が進んでいる点は、Tsurugiが「研究用途の実験DB」ではなく、実インフラに乗せられる成熟度に達しつつあることを示す状況証拠として重要です。

2026年ロードマップの公表状況

2026年7月15日の事例セミナー2026では、ノーチラス・テクノロジーズが「Tsurugi 2026〜ロードマップ：分散DB／圧縮／其の他もろもろ」というタイトルで開発方針を発表する予定と告知されています。

演題以上の具体内容は現時点で公表されていませんが、演題から読み取れる論点は以下のとおりです。

• 分散DB
  現状の1台完結のスケールアップ設計に対し、複数ノードへの拡張が論点として挙がっている
  
  

• 圧縮
  大容量データの取り扱いに関わるストレージ効率化が論点として挙がっている
  
  

• 其の他もろもろ
  具体項目は演題外で、詳細はセミナー当日の発表待ち

スケールアウトの実装方式（TiDBやSingleStoreに近い構成になるのかどうか）、UDF拡張や運用ツール整備が含まれるのか、といった細部はいずれも記事執筆時点では未公表です。導入検討側としては、7月15日以降に公開されるセミナー資料と続報を追いかけるのが確実です。

Tsurugiの導入で押さえる判断論点

Tsurugiは技術的に尖ったRDBですが、あらゆる業務に向くわけではありません。

ここではAI総研の実務観点から、どういう場合にTsurugiが第一候補になるか、逆にどういう場合は既存RDBを維持すべきかを整理します。

Tsurugiが有力候補になる3つの条件

Tsurugiが選定候補として強く上がるのは、以下のいずれかが業務要件に含まれるケースです。

• 1台のメニーコアサーバで基幹バッチを回したい
  100コア超のサーバを購入したが、既存RDBでは並列度を上げても性能が頭打ちになるパターン。原価計算・締め処理・銀行系の勘定バッチ等が典型
  
  

• バッチとオンラインの分離運用を再設計したい
  夜間バッチが翌朝までに終わらないリスクを抱えているケース、あるいは24時間営業で夜間バッチの停止時間が確保できないケース。Hybrid Concurrency Controlで両者を同時実行できる利点が大きい
  
  

• 経済安全保障・調達要件で国産DB候補が必要
  政府調達要件、経済安全保障上の観点、あるいはグループ全体のソブリンAI方針で「海外ベンダーへの依存度を下げたい」という判断があるケース。Apache 2.0のOSSかつ国産という位置づけは、他の選択肢と明確に差別化できる

逆に言うと、上記のいずれにも当てはまらない場合、既存のPostgreSQL／Oracle／SQL Server／クラウドマネージドRDBを継続する方が運用リスクが低く、社内知見も活かせます。

「新しいから使う」ではなく「既存RDBで詰まっている領域があるから使う」という順序で検討するのが実務的です。

導入時に想定しておくべき制約

Tsurugiを本番採用する際に、事前に想定しておくべき制約も明確にあります。

• 成熟度は2024年GAで、コミュニティ知見はまだ蓄積途上
  Stack Overflow・Qiitaの記事数、公開されている運用ノウハウは既存RDBと比べて桁違いに少ない。トラブル時の一次情報はほぼベンダーサポート頼りになる
  
  

• SQL互換性はPostgreSQLを「必要に応じてサポート」する方針
  既存アプリのSQLがそのまま動く保証はなく、方言差の吸収・パフォーマンスチューニングは移行時の作業として想定する必要がある
  
  

• 分散運用は2026年ロードマップ
  現時点では1台のスケールアップ運用が基本で、水平スケールが必要な要件には対応しきれない。TiDB／CockroachDBのような分散DBを想定している場合は、Tsurugiのロードマップ確定後に再評価する
  
  

• ハードウェア要件が「メニーコア前提」
  32コア以下の環境では設計思想上の利点を活かしきれず、既存RDBに対する優位性が薄い。導入判断とハードウェア調達を一体で検討する必要がある

これらは制約ではありますが、ロードマップ上で解消される方向にある論点も多く、今すぐ全面移行するのではなく、まずは新規プロジェクト・PoC領域から段階的に採用するアプローチが現実的です。

Tsurugi推奨ケースと慎重検討ケース

支援現場での実感として、Tsurugiは以下のケースで強く推奨できます。

推奨ケース：

• 既にメニーコアサーバを保有／購入予定で、原価計算・締め処理などの基幹バッチが夜間帯に集中しているケース
• ソブリンAI・国産インフラ方針を経営レベルで打ち出しており、データ基盤も国産候補を評価対象に入れているケース
• 医療・電力・防衛など、閉域環境で大規模データを高速処理する必要があるケース

慎重に検討すべきケース：

• 既存のクラウドマネージドRDB（Aurora／Azure SQL／Cloud SQL）で性能・運用ともに満足しているケース。移行コストに見合う効果は出にくい
• グローバル規模のスケールアウト分散が必要なケース。現時点ではTiDB／CockroachDB／Spanner系の方が成熟している
• SQL Serverや Oracle 特有の機能（ストアドプロシージャ、独自機能）への依存が強いケース。互換性検証だけで数か月かかる可能性がある

いずれのケースでも、PoCをOSS版で回して自社ワークロードとの相性を確認してから本番判断する流れは変わりません。

200万円／年のサポート契約を検討する前に、Dockerで起動して社内の代表的なクエリを流してみることから始めるのが健全です。

高速データを業務プロセスに繋ぐAgent基盤を作るなら

Tsurugiのようなメニーコア前提の高速RDBを選定するのは、"バッチとオンラインの同時実行"、"200万件超の原価計算バッチを13分39秒で完了"、"国産・閉域環境要件"といったデータベース層側の要求に応えるための投資です。

ただし選定・導入だけでは業務価値には転化せず、Tsurugiに載った基幹データを"どの承認フロー・どのTeams UI・どの基幹連携で業務プロセスに流し込むか"の業務組み込み層とセットで設計して初めて成果になります。
記事内で触れたTsurugi MCP Server経由でLLM/AIエージェントから業務データを呼び出す構成も、この業務組み込み層の設計次第で効果が大きく変わります。

このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。
AI総合研究所のAI Agent Hubは、AI-OCR Agent・自動入力Agent・フロー判定Agentなど9種類の業務特化Agentを、SAP Concur・freee会計・Dynamics 365・Salesforce・勘定奉行クラウドといった基幹システムと繋げ、Microsoft Teamsから呼び出せる形でパッケージ化しています。

Tsurugi・Oracle・PostgreSQLのどれをデータベース層に置いても、その上でMCP経由で業務データにアクセスするAI Agent実行基盤は共通レイヤーとして再利用できる設計です。

AI総合研究所の専任チームが、基幹データベース選定と業務プロセスAgent化の両輪で伴走支援します。AI Agent HubのLPで、基幹データを業務プロセスに繋ぐAI Agent実行基盤の全体像をご確認ください。

基幹データを業務プロセスに繋ぐAgent基盤

データベース層とAgent実行層を両輪運用

Tsurugiのような高速RDBは「バッチとオンライン同時実行」「国産閉域環境」等のデータベース層側の要求に応える基盤ですが、業務価値はそこに載ったデータを承認フロー・Teams UI・基幹連携で業務プロセスに流し込む実行層とセットで設計して初めて生まれます。AI Agent HubのLPで、基幹データを業務プロセスに繋ぐAgent実行基盤の全体像をご確認ください。

▶ ▶ AI Agent Hubの詳細を見る

まとめ

Tsurugi DB（劔）は、NECとノーチラス・テクノロジーズがNEDO支援のもとで開発した、メニーコア時代を前提に再設計された国産オープンソースRDBです。本記事で整理した論点を最後に振り返ります。

• アーキテクチャの独自性
  Hybrid Concurrency Control（OCC＋LTX）とMVCC・インメモリ設計で、バッチとオンラインを同一エンジン上で同時に高速処理できる
  
  

• 性能実測
  1ノードあたり約630万TPS・158ナノ秒（公式本文112コア／掲載表128コア行）、200万件超の原価計算バッチを13分39秒で完了。Sparkで50分の処理を2分に短縮した実例もある
  
  

• 他RDB／HTAP潮流との位置づけ
  PostgreSQL／Oracle系との違いは「メニーコア前提の再設計」、TiDB／SingleStoreとの違いは「スケールアップ vs スケールアウト」、Databricks LTAPとは「エンジン統合派 vs ストレージ統合派」
  
  

• 料金体系
  本体はApache 2.0で無料、商用サポートはスタンダード／エンタープライズいずれも200万円／年〜
  
  

• 導入事例と2026年ロードマップ
  千葉大の医療データ研究基盤、九州電力の地域分散インフラ検証、NEDO光電融合実証といった領域でTsurugi関連の発表・検証が公開されている。2026年7月15日のセミナーで分散DB・圧縮を論点にしたロードマップが発表予定
  
  

• 導入判断の軸
  「1台のメニーコアで基幹バッチを回したい」「バッチとオンラインの分離運用を再設計したい」「経済安全保障・国産DB要件がある」の3条件に当てはまるかで検討開始、成熟度・SQL互換性・分散運用の制約を踏まえて段階的に採用する

Tsurugiは、既存RDBを全面的に置き換える製品ではありません。メニーコア環境で既存RDBが構造的に苦手な領域を、国産OSSかつ高速で解ける選択肢として2026年に確立しつつあるRDBです。

自社の基幹バッチ運用に限界を感じているなら、まずはDockerで起動して代表的なクエリを流すところから、Tsurugiとの相性検証を始めてみてください。