ビジネスインテリジェンスでより優れたダッシュボードを構築 - 第1回 Sep 28, 2026 by Robert Gravelle

タイルレイヤーの紹介

優れたエグゼクティブダッシュボードは、ビジネスの状況、詳しく確認すべき箇所、数値の鮮度を一目で伝えます。Navicat 18のビジネスインテリジェンス（BI）ツールには、そのストーリーを構築し、最新の状態に保ちやすくする機能がいくつか追加されています。今回は、シンプルな売上概要ダッシュボードを作成し、タイルレイヤーを使用します。今後の数回の記事では、新しいパラメーター、ページナビゲーション、自動更新の各機能を取り上げます。

このチュートリアルでは、MySQLのサンプルデータベース「classicmodels」に接続したデータソースをすでに作成し、以下で取り上げるものと同様の3つのチャートと、ダッシュボード自体も作成済みであることを前提とします。以下の手順は、その状態から始まります。

SQLエディタの生産性向上：リファクタリングとリアルタイムエラー検出 Sep 21, 2026 by Robert Gravelle

シンプルなクエリを書くのは簡単です。しかし、15個のJOINや多数のエイリアスを含む複雑なクエリになった場合、その保守は非常に煩雑になります。テーブルのエイリアスを1つ変更するだけでも、関連するすべての参照箇所を手作業で探し回さなければなりません。Navicat 18のSQLエディターは、「リファクタリング」「リアルタイムエラー検出」「コードインサイト」の3つの新機能によって、こうした手間を解消します。

Navicat 18のデータマスキング：より安全な開発・テスト環境を実現 Aug 31, 2026 by Robert Gravelle

データベースを扱うチームなら、いずれ同じ問題に直面することになります。テストには実際のデータが一番役立ちますが、本番環境のデータをそのまま開発やテストに利用するのは、コンプライアンス上大きなリスクがあります。GDPR、HIPAA、PCI-DSSなどの規制では、「テストのためだった」という理由は通用しません。開発者のノートPCや本番公開前のテスト用サーバーから、実際の顧客の名前、メールアドレス、決済情報などが漏れれば、データ侵害につながります。Navicat 18では、この問題に正面から対応するため、新機能としてData Masking（データマスキング）が追加されました。機密性の高い本番データを、安全で現実的なテスト用データに変換できるため、開発チーム、テストチーム、品質保証（QA）チームもリスクを抑えて作業できます。

Navicat 18、マルチデータベースクライアントにAI機能を搭載 Aug 21, 2026 by Robert Gravelle

Navicatは、高いパフォーマンスとスピードを追求した、複数のデータベースに接続して操作できるクライアントアプリケーションです。 Navicat 17では、AIを幅広く活用した機能と直感的なユーザーインターフェースを実現し、他の製品との差別化を図りました。そして今月後半には、Navicat 18がリリースされる予定です。1つのアプリケーションから複数のデータベースに接続できるだけでなく、よりスムーズで効率的な操作が可能になります。本記事では、Navicat 18でAIツールを日々の業務にどのように活用できるのかを紹介します。

マルチクラウド・データベース戦略：メリットと注意点、管理のポイント Aug 14, 2026 by Robert Gravelle

クラウドデータベースの経済性では、AWS、Azure、Google Cloud Platform（GCP）にデータベースのワークロードを分散することで得られる経済的なメリットについて解説しました。具体的には、コスト削減につながる要因、ベンダーロックインを避けることが経済的にも重要である理由、そして、適切に管理しなければ、データ転送（エグレス）料金や運用負荷によって、コスト削減の効果が知らないうちに相殺されてしまうことを取り上げています。前回の記事では、マルチクラウドは必ずしもすべてのケースに適した方法ではなく、状況に応じて選択できる有効な戦略であることを説明しました。また、複数のクラウド環境が意図せず増えていくのを放置するのではなく、適切に管理することで初めて、そのメリットを活かせることについても解説しました。

本記事では、その続きとして、実際の運用について取り上げます。経済的なメリットがあるとして、次に問題となるのは、複数のクラウドにまたがるデータベース環境を、複雑さによってコスト削減の効果を失うことなく、日々どのように管理・運用するかという点です。現在では、複数のクラウドプロバイダーにまたがってデータベースを運用する組織が増えています。特に、AWS、Azure、Google Cloud Platform（GCP）を同時に利用するケースも珍しくありません。こうした環境が、あえて意図的に構築される場合もあります。例えば、障害が発生した場合にもサービスを継続できるよう、複数のクラウドを利用するケースです。一方で、意図的に計画したわけではなく、各チームがそれぞれ異なるクラウドを利用していくうちに、結果としてマルチクラウドになっているケースの方が多くあります。例えば、あるチームはプロジェクトでAWS RDSを標準として採用し、別のチームは新しいアプリケーションにAzure SQL Databaseを導入し、データサイエンス部門は利用しているツールとの連携を考えてBigQueryやCloud SQLを採用する、といったケースです。マルチクラウドになった経緯がどうであれ、結果として生じる問題は同じです。データベースを管理するために、3つの異なる管理画面、3つの異なる料金体系、そしてそれぞれ異なる運用方法に対応しなければならなくなります。