PostgreSQL用のセマンティックゲートウェイ・postgresem 1.0.0をリリースしました

postgresemの開発をスタートしたきっかけは、同僚たちとの何気ない会話でした。

データベース、RDBMSかNoSQLか、あるいは他の形式であるかを問わず、そこに格納されているデータの意味はどうやって管理しますか？ 例えば、AIエージェントはカラム名からある程度推測してくれますが、それが正解である保証はありません。YAMLで追加する？ オントロジーで追加する？ 確かにそういった実装も考えられますが、すぐに問題に気付くはずです。

以下はpostgresemのREADMEからの抜粋です。

postgresemはどういった問題を解決するのか？

PostgreSQLは、テーブル、カラム、型、キー、制約、コメント、権限、行レベルセキュリティなど、データの構造を把握しています。しかし構造だけでは、売上計上に使う日時、承認された指標の定義、集計単位を崩さずに結合できるテーブルまでは説明できません。

こうした意味は、アプリケーションコード、BIツール、プロンプト、ドキュメント、YAMLファイルなどへ重複して記述されがちです。それぞれが独立して変化すると、定義の不一致が生まれます。物理スキーマだけを参照するエージェントは、構文上は正しいSQLでも、注文を二重計上したり、業務上誤った定義を使ったり、想定したアプリケーションの公開範囲を超えてデータを取得したりする可能性があります。

postgresemは、レビュー済みのモデル、フィールド、リレーション、指標、ポリシー関連付けをデータとともにPostgreSQLへ保存します。pg_catalog、コメント、キー、制約などのメタデータはモデル化の根拠になりますが、業務上の意味についての人によるレビューを置き換えるものではありません。定義は変更不能なリビジョンとして公開され、ハッシュで検証されます。

アプリケーションはSQLではなく承認済みの意味名を使います。コンパイラーは、決定的で上限付きのパラメータ化操作を生成するか、未対応または曖昧な入力を拒否します。

利点	得られる効果
意味定義の正本を一つに集約	アプリケーションやエージェントが、それぞれ別の業務定義を維持する代わりに、PostgreSQL内の公開済み定義を共有します。
データベースによるアクセス制御	PostgreSQLのGRANTとRLSを最終的な権限として維持します。セマンティック層がデータベースの拒否を覆すことはありません。
一貫した運用	スキーマ変更、意味定義の公開、差分検出、バックアップ、復元をPostgreSQLの運用境界内で扱えます。
追跡可能性	実行を意味定義のリビジョン、コンパイラーバージョン、ポリシーコンテキスト、監査記録に関連付けます。
追加インフラの削減	コア機能に外部カタログサービス、ベクトルデータベース、ポリシーエンジン、結果キャッシュは不要です。

なぜPostgreSQLなの？

行指向のデータだけで無く、そのデータを十分に説明するメタデータを保持するために必要な、JSONやベクトル、グラフデータも扱えるから、です。PostgreSQLだけで、データ本体とメタデータを一括して扱えることは、システム管理において大きなメリットです。正本が1つにまとまっていて、ゲートウェイを介してAIエージェントがアクセスすれば、意味を確実に理解した上でデータを読み書きできる、ということに意義があります。

デモを見てください

postgresemの利点を簡単に理解してもらうために、デモを作りました。興味のある方はgit cloneして実行してみてください。

とはいえ、AIに「postgresemのレポジトリを参照して、セマンティック・ゲートウェイを介してAIエージェントがクエリーする〇〇アプリを実装して」と依頼した方が、分かりやすいかもしれません。