2026年は10月20日から23日にかけてスペイン・バレンシアで開催されます。

本レポートでは、PGConf.EU 2026 Day3で発表された講演のうち、筆者が印象に残ったセッションを紹介します。

Where next for parallel query execution?

Thomas Munro 氏は、PostgreSQL の並列クエリ実行における課題と今後の改善の方向性について解説しました。

重要な課題の1つとして挙げられたのが、メモリ管理です。現在の PostgreSQL では、ソートやハッシュ結合などの処理ごとに、主に work_mem パラメータを上限値としてメモリ使用量を制御しています。
しかしながら、各処理がメモリを確保・解放するタイミングは実行計画や実行時の状況によって異なるため、単純な掛け算ではピーク時の使用量を正確に把握できず、システム全体で実際にメモリがどの程度使用されるのかを予測することは困難です。

work_mem を大きなサイズに設定すると OOM によるプロセス終了などの危険がある一方で、安全性を重視してwork_mem を小さくすると、利用可能なメモリを十分に活用できません。
特にクエリを複数プロセスで並列に実行する場合には、より多くのメモリを消費する可能性があるため、メモリ管理の重要性も高くなります。

この課題に対して、各処理ごとのメモリ管理ではなく、クエリ単位、さらにはシステム全体でメモリを管理する方向性が示されました。まず、クエリ実行時のピークメモリ使用量を計測し、EXPLAIN (ANALYZE) で表示できるようにしたり、共有メモリを通じて参照可能にすることが提案されました。さらに、プランニング時にはピークメモリ使用量を推定して EXPLAIN で表示できるようにする案も紹介されました。

また、クエリの実行開始を制御する Admission Control のアイデアも紹介されました。システム全体で利用可能なメモリ量を管理し、クエリごとに推定される使用量を事前に予約しておく仕組みです。メモリが不足する場合には、実行を待機させるか、work_mem を小さくして実行する方法が考えられています。

これらの改善は今後の検討課題ですが、もし実現すれば、並列クエリ実行において、安全性とリソース利用効率を両立した、より適切なメモリ管理につながる可能性があります。今後の動向に注目です。

The process of RPM packaging in the PostgreSQL ecosystem

Devrim Gündüz 氏は、PostgreSQL エコシステムにおける RPM パッケージの作成・保守プロセスと、その運用上の課題について解説しました。

PostgreSQL の RPM リポジトリでは、膨大な数のパッケージを管理しており、PostgreSQL 本体だけでなく、拡張機能やバックアップツールなども提供しています。

RPM パッケージの作成には、ビルド手順や依存関係、インストールするファイルなどを定義した Spec ファイルを使用します。パッケージングでは、Spec ファイルの作成に加え、依存関係の確認、セキュリティ検査、各 OS や PostgreSQL のバージョンとの互換性確認など、多くの作業が必要です。また、PostgreSQL が依存するライブラリなどのパッケージ名は Linux ディストリビューションによって異なるため、Spec ファイルには複雑な条件分岐が必要になるなど、多彩なディストリビューションにパッケージを提供しているPostgreSQLならではの苦労も語られました。

こうした作業を効率化するため、Claude などの AI を活用し、自動化ツールやテストコードの作成など、日常的なメンテナンス作業の効率化にも取り組んでいることが紹介されました。

特に印象的だったのは、RHEL の OpenSSL 更新に伴う互換性問題です。(参考: https://www.postgresql.org/about/news/postgresql-rpm-repository-now-supports-multiple-rhel-minor-versions-3202/)
2025年にリリースされた RHEL 9.7 および 10.1 では、OpenSSL のバージョン更新によって、以前のマイナーバージョン向けの RPM との間で依存関係の問題が発生しました。これを受けて、PostgreSQL の RPM リポジトリでは、RHEL 9 と 10 のそれぞれについて最新 2 つのマイナーバージョンをサポートし、マイナーバージョンごとに RPM をビルドする方針に変更しました。この対応に伴う作業負担は大きく、「ストレスの多い1月を過ごした」と語られたことが印象に残っています。

講演を通じて、RPM パッケージの提供は単なるビルド作業ではなく、OS の変更への対応や、セキュリティと品質の継続的な確保など、多くの保守作業によって支えられていることが実感できました。

Can We Skip Recovery? The Architecture of On-Demand WAL Replay

Srinath Reddy Sadipiralla 氏は、PostgreSQL のクラッシュリカバリを高速化する「On-Demand WAL Replay」の実験的なアーキテクチャについて解説しました。

現在の PostgreSQL では、クラッシュ後の起動時にリカバリが実行され、チェックポイント以降の WAL をすべて再生する必要があります。これが完了するまでクライアントは接続できないため、WAL の量が多いほどサービス停止時間が長くなる問題があります。

これを解決するために提案されている「On-Demand WAL Replay」では、起動時のリカバリで WAL すべてをスキャンする一方、テーブルやインデックスなどのデータページを変更する WAL レコードの適用を遅延させます。未適用の WAL レコードはページごとに共有メモリ上で管理し、ページへの初回アクセス時や、バックグラウンド処理によって適用されます。これにより、すべてのページの復旧を待たずにクライアントからの接続を受け付けられるようになります。

性能評価では、接続可能になるまでの時間が最大 5.5 倍高速化しました。一方で、初回アクセス時の遅延や、未復旧ページが存在する間のチェックポイントの制限、共有メモリの消費などが課題として挙げられました。今後はリプレイ処理の並列化や、管理情報のディスクへの退避などが検討されています。

講演の終わりには、本機能のバグ報告など、開発への協力が呼びかけられました。このように、開発中の機能についてフィードバックを募れることも、カンファレンスを開催する重要な意義であると感じました。

まとめ

以上、PGConf.EU 3日目の講演レポートでした。
本日最後に行われたクロージングセッションによると、今回の参加者は 747 名、講演数は 101 講演だったとのことです。改めて、規模の大きいイベントであると感じました。

3日間を通して、PostgreSQL の内部構造や新機能、運用上の課題など、幅広いテーマの講演を聴くことができました。また、講演後の活発な質疑応答や参加者同士の交流からも、PostgreSQL コミュニティの活気を感じました。技術的な知見だけでなく、今後の PostgreSQL の発展に向けた取り組みを知ることができた、有意義な 3日間でした。

2026年は10月20日から23日にかけてスペイン・バレンシアで開催されます。

本レポートでは、PGConf.EU 2026 Day2で発表された講演のうち、筆者が印象に残ったセッションを紹介します。

Autovacuum Is Running. Is It Actually Working?

Teresa Lopes 氏は、PostgreSQL の autovacuum が適切に動作しているかを確認する方法と、効果的なチューニングについて解説しました。

PostgreSQL の MVCC の仕組みでは更新前の行がテーブルに残るため、不要になった行（dead tuple）を VACUUM で回収する必要があります。autovacuum はこの処理を自動化しますが、デフォルト設定が必ずしも最適とは限りません。
講演では、autovacuum の起動条件を決めるしきい値とスケールファクターの影響を実験で比較しました。小規模テーブルではautovacuum_vacuum_threshold、大規模テーブルではautovacuum_vacuum_scale_factorの調整が重要です。また、コスト上限やコスト遅延、ワーカー数を調整することで、システム負荷と処理時間のバランスを改善できることを示しました。

一方、長時間トランザクションや放置されたレプリケーションスロットなどが VACUUM の処理を妨げる場合があります。さらに、通常の VACUUM ではテーブルやインデックスの肥大化を完全には解消できず、REPACK や REINDEX などが必要になることも説明しました。

最後に、PostgreSQL 19 に向けた改善にも触れ、autovacuumが適切に動作しているかを監視可能になる機能改善が多数あることが紹介されました。
PostgreSQLを運用する上でautovacuumは重要な役割を果たしていますが、適切に動作させることは難しい印象です。弊社のサポートでもautovacuumについての問い合わせは数多くあります。講演者がautovacuumのチューニングに対する苦労を語っていた点に共感しました。

How to Contribute to the PostgreSQL Documentation

David E. Wheeler 氏は、PostgreSQL の公式ドキュメントを改善し、コミュニティに貢献する方法を紹介しました。

PostgreSQL のドキュメントは XMLベースのマークアップ言語である DocBook で管理されており、Emacs や Vim などのテキストエディタで編集できます。章や段落、リンク、表、コマンドの実行例などは専用のタグで記述されます。修正後は make check で構文を検証し、HTML や PDF を生成して内容を確認できます。
変更を提出する際は、git diff で差分を確認し、git format-patch でパッチを作成します。PostgreSQL では GitHub の Pull Request ではなく、メーリングリストにパッチを投稿する方法が基本です。投稿後は CommitFest に登録することで、レビュー状況を追跡できます。
講演者は、機能の開発者でなくても、利用者として疑問に感じた点や分かりにくい説明を改善することで、PostgreSQL の発展に貢献できると強調しました。

講演内では、ドキュメントを改善してコミュニティにパッチを投稿するまでの一連の流れが紹介されており、この講演を聞けば今にでもパッチ投稿できそうなところが良かったです。また、PostgreSQLのドキュメント内で使用されている DocBook のタグについても丁寧な解説があり、非常に参考になりました。

Security Strategies for your database backups

Priyanka Chatterjee 氏は、PostgreSQL のバックアップを安全に保護するための戦略について解説しました。

データベース本体ではロールや権限、パスワード、SSL/TLS などのセキュリティ対策が重視されますが、バックアップについては取得や復元の成否、処理時間に注目が集まり、セキュリティ対策が後回しになりがちです。

バックアップの保管先が適切に保護されていないと、攻撃者に機密データを読み取られたり、バックアップファイルを改ざんされたりする可能性があります。改ざんされたバックアップを使用すると、不正なデータや設定が復元先に持ち込まれ、復旧後のシステムに新たな問題が発生する恐れもあります。また、ランサムウェア攻撃では、データベース本体だけでなくバックアップも標的となり、復旧手段を奪われる可能性があります。そのため、バックアップをデータベース本体と同じ権限やネットワークの中だけで管理することには注意が必要です。

バックアップの保管方法として、元データを含めて 3 つのコピーを保持し、2 種類の異なる媒体に保存し、少なくとも 1 つのコピーをオフサイトに保管する「3-2-1 戦略」が紹介されました。さらに、定期的な復元テストを実施し、バックアップから正常にデータベースを復旧できることを確認することも重要です。

セキュリティ対策としては、バックアップの暗号化とアクセス制御が挙げられました。クラウドストレージでは、KMS（Key Management Service）を利用した暗号鍵の管理に加え、ストレージへのアクセス制御やパブリックアクセスの制限が有効です。また、VPC やプライベートエンドポイントなどを活用したネットワーク経由のアクセス制限や、転送時の暗号化によって、バックアップへの不正アクセスや情報漏えいのリスクを低減できます。

近年、個人情報の流出事故が相次いでおり、データベースのセキュリティ対策はますます重要になっています。今回の講演を通じて、データベース本体だけでなく、バックアップの保管方法や暗号化、アクセス制御まで含めて適切に設計することの重要性を改めて感じました。

まとめ

以上、PGConf.EU 2 日目の講演レポートでした。
PostgreSQL本体の開発に参加するための方法や、開発を行ってみての知見を発表するセッションが複数あることが、本イベントの特色のうちの1つであると感じます。PostgreSQL開発コミュニティへ貢献することへの関心の高さを感じました。

2026年は10月20日から23日にかけてスペイン・バレンシアで開催されます。

本レポートでは、PGConf.EU 2026 Day1で発表された講演のうち、筆者が印象に残ったセッションを紹介します。

オープニングセッション

オープニングセッションでは、イベントの説明がされたのち、PostgreSQLとPostgres Europeの30年にわたる歴史を振り返りました。1996年頃のPostgreSQL 6.0から始まり、2008年のPostgres Europe設立、2014年のマドリード開催、コロナ禍を経たカンファレンスの復活などの紹介がありました。一番重大なトピックとして、PostgreSQL EUのマスコットとしてSlonikというマスコットキャラクターがいるのですが、今年その着ぐるみが代替わりしたそうです。新しいSlonikマスコットのお披露目や旧着ぐるみの抽選企画も発表され、会場は笑いに包まれました。

 REPACK in Core

Robert Treat 氏による、PostgreSQL 19 に導入予定の REPACK コマンドについての解説です。
PostgreSQL では、MVCC によってテーブルやインデックスが肥大化することがあります。いったん肥大化したテーブルは通常のVACUUMでは縮小できず、強いロックが必要なVACUUM FULLを実行する必要があります。

PostgreSQL 19では、VACUUM FULLの名前がREPACKに変更されました。このことにより、通常のVACUUMとの区別がしやすくなるという利点があります。
また、REPACK CONCURRENTLY機能が追加され、通常のデータベース操作への影響を抑えながら再編成できます。

REPACK CONCURRENTLY は、論理デコードを利用して更新を追跡しながら、新しいテーブルへデータをコピーします。最後に短時間の排他ロックを取得してファイルを切り替える仕組みです。

ただし、長時間トランザクションとの競合や MVCC 安全性、REPACK実行中の更新行数の上限、メモリ消費など、運用上の制約が残っています。また、実行できないテーブルもあり、複数のREPACK CONCURRENTLYを同時に実行することも推奨されていません。

講演者は、現時点では既存の pg_repack を完全に置き換えるものではないと説明しました。特に、多数のテーブルを定期的に再編成する用途では、引き続き pg_repack が有用です。

制約が多数あり、PostgreSQL 19時点では本番環境で実行することは難しい機能だと感じました。しかし、テーブルへの更新や参照をブロックしないテーブル再編成機能はニーズの高い機能であり、PostgreSQL 本体にREPACK CONCURRENTLY機能が導入されることは大きな進歩です。今後の改善が期待されます。

pg_ivm の最近の改善と方向性

弊社の長田からは、PostgreSQL のマテリアライズドビューを高速に更新するための拡張モジュール pg_ivm の最近の改善と今後の方向性について紹介されました。

pg_ivm は、Incremental View Maintenance（増分ビューメンテナンス）を PostgreSQL 上で実現する拡張機能です。通常のマテリアライズドビューでは、基となるテーブルの更新内容を反映するために REFRESH MATERIALIZED VIEW を実行してビュー全体を再計算する必要がありますが、pg_ivm は変更差分のみを計算して適用することで、自動的かつ効率的に更新されるマテリアライズドビュー（IMMV, Incrementally Maintainable Materialized View）を作成することができます。

講演では、増分メンテナンスによってビュー更新を高速化できる一方、元テーブルの更新時には差分計算やビュー更新が発生するため、一定のオーバーヘッドや同時実行性への影響があることも説明されました。

最近の機能改善としては、Outer Join（外部結合）のサポート、pg_dump および pg_upgrade への対応強化、PostgreSQL 19 への対応などが紹介されました。特に Outer Join のサポートが大きな技術的成果として取り上げられました。Outer Join では、結合相手が存在しない場合に生成される NULL で補完された行（dangling tuple）が存在するため、単純な増分メンテナンスでは適切に対応できません。pg_ivm では、Outer Join の結果を 通常の内部結合で得られる部分と、結合相手を持たない行に影響する部分に分けて扱うことで対応しています。また、以前は pg_dump によるダンプデータのリストア時やpg_upgrade によるアップグレード後にpg_ivmのメタデータが正しく復元されない問題がありました。これらについても、メタデータを復元する関数を実装することなどにより、適切にデータ移行できるように改善されました。

今後の開発では、Deferred Maintenance（遅延メンテナンス）が大きな候補として挙げられました。テーブル差分の収集とビューの更新を分離し、後からまとめてメンテナンスできるようにすることで、テーブル更新性能への影響を軽減しながら、増分メンテナンスの利点を活用できるようになることが期待されます。

Community Moments That Shaped 30 Years of PostgreSQL

Valeria Kaplan 氏による、イベントを通じて発展してきた PostgreSQL コミュニティの歴史を振り返るセッションです。 PostgreSQL は、1990 年代の開発者同士の交流から成長し、現在では世界各地でカンファレンスやミートアップが開かれています。

PostgreSQLの開発はメーリングリスト上で行われていると思われていますが、実はこのようなコミュニティイベントによる交流の力も大きいです。メーリングリストだけでは生まれにくい信頼関係や協力関係を育むことで、新機能の開発につながっています。

コミュニティイベントの開催は主に企業、登壇者、運営者によって支えられています。企業はイベント協賛の形で資金提供を行いますが、イベントへの協賛は、人材採用や認知度向上、開発動向の把握に役立ちます。一方、登壇者は講演を準備する労力を支払う一方で、知識の共有や成長の機会を得られます。運営者は多くの時間と労力を費やしますが、コミュニティに貢献する誇りや仲間とのつながりが活動を支えています。

今後の課題として、新しい登壇者や運営ボランティアの参加を増やしていくこと、多様性を向上させること、学生や他の技術コミュニティとの交流を拡大することが挙げられました。講演者氏は、小さな貢献でも大きな変化につながる可能性があるとして、積極的な参加を呼びかけています。PostgreSQLの発展にはコミュニティへの貢献が不可欠ですので、筆者も何らかの形で貢献したいと考えています。

まとめ

以上、PGConf.EU 1 日目の講演レポートでした。
初日に参加した感想としては、多くの参加者が集まり、質疑応答も活発に行われるなど、非常に活気のあるイベントだと感じました。休憩時間や昼食時には、軽食を片手に参加者同士が交流する姿も見られました。講演内容も、PostgreSQL の内部構造に踏み込んだ技術的な話から、ユーザー視点での実践的な Tips の紹介まで多岐にわたり、様々な観点からPostgreSQLについての情報収集ができるイベントだと感じます。

はじめに

Zabbix Summit 2026 レポートの2日目では、大規模な監視環境を支える技術的な工夫から、収集したデータの活用、ビジネスサービスの信頼性管理まで、幅広いテーマの講演をいくつかピックアップして紹介します。

今回取り上げる講演では、毎秒 100 万件の新規監視値を扱うための性能面の工夫や、日々の運用を効率化する機能、製造現場の業務アプリケーションを支える監視事例が紹介されました。さらに、Zabbix が収集したデータをレポートや AI による異常検知に活用する方法や、サービス全体の状態を可視化して SLA の管理につなげる取り組みも取り上げられました。

これらの講演に共通しているのは、監視データを収集して異常を通知するだけでなく、その情報を運用の改善や業務上の判断に役立てようとしている点です。それぞれの講演から、Zabbix の機能をどのように活用し、監視の効率化やサービスの安定運用につなげているのかを見ていきます。

大規模監視と日々の運用を支える Zabbix の工夫

Aleksandrs Kalimulins 氏の講演「Achieving 1M NVPS and Other Little Things」では、毎秒 100 万件の新規監視値を扱うというテーマとともに、日常の運用に役立つ Zabbix の機能が紹介されました。エージェント設定の簡素化からプロキシの運用、マクロによる通知の改善、ブラウザー監視まで、規模の拡大と使いやすさを両立するための工夫が幅広く取り上げられました。

■ エージェントの設定を整理する

エージェントの設定では、ホスト名の取得方法や、長いアイテムキーとパラメータの扱いが話題になりました。環境ごとに異なる情報をどこで設定するかを整理することで、テンプレートの再利用と保守をしやすくできます。短い別名やユーザーパラメータの活用は、複雑な設定を扱いやすくするための手段として紹介されました。

また、単一のエージェントを複数の論理的なホストとして利用する考え方も示されました。アクティブ監視では複数のホスト名を設定する方法があり、パッシブ監視では複数のホストから同じエージェントの接続先を参照できます。同じマシン上の監視対象を分けて管理したい場合に役立ちます。ただし、監視対象をどう分けるかは、テンプレートやパラメータの管理方針と合わせて考える必要があります。

導入を支援する機能として、ホストウィザードも紹介されました。画面の案内に従って設定を進め、生成されたコマンドを実行することで、エージェントの導入を進められます。設定に不慣れな担当者でも、必要な作業を段階的に確認できることが利点です。

■ 分散監視を支えるプロキシ

プロキシについては、収集データの保存方法として、ディスク、メモリ、ハイブリッドという選択肢が説明されました。メモリを使う方式は、収集データのバッファリングに伴うデータベースへの書き込みを抑えられます。ハイブリッド方式はメモリとデータベースを組み合わせるもので、通信状況やデータ保持の要件に応じた使い分けが重要です。軽量な SQLite は、遠隔拠点での運用やデータベースの再作成の容易さという観点から取り上げられました。設定の同期頻度についても、回線帯域や接続の安定性を考慮して調整できます。必要なタイミングで手動の設定更新を行う方法も紹介され、拠点ごとの事情に合わせた運用が示されました。

さらに、対応する範囲で異なるバージョンのプロキシを利用し、サーバーとプロキシを段階的に更新する考え方が説明されました。大規模環境では、すべての拠点を一斉に更新する負担を減らせます。プロキシ側でシークレットマクロを解決する機能も取り上げられ、拠点や役割に応じた秘密情報の取り扱いが話題になりました。

■ トリガーと通知を理解しやすくする

複雑なトリガー式は、設定を読むだけでは判定の理由を把握しにくい場合があります。講演では、マクロや式の構成要素を実際の値に展開して確認し、条件を読み解くための機能が紹介されました。複数のテンプレートや条件を組み合わせた監視では、こうした確認機能が調査を助けます。

通知の内容を充実させる方法として、値や時刻を示すマクロ、式マクロ、文字列変換などのマクロ関数も説明されました。例えば、ディスク容量の問題を知らせる際、対象のファイルシステムや残り容量をメッセージに含めれば、通知を受けた時点で状況を把握しやすくなります。異常の発生だけでなく、対応に必要な情報まで伝えることがポイントです。

■ ウェブ監視と表示機能の活用

ウェブシナリオでは、応答から JSONPath や XPath で値を抽出し、後続のステップで利用する方法が紹介されました。複数のリクエストをつなぐ REST API のテストなどに活用できます。ブラウザーアイテムについては、ログイン操作だけに用途を限定せず、自動操作の仕組みをさまざまな確認に応用する考え方が示されました。Appium を利用したモバイルアプリケーションのテストや、スクリーンショットの取得も話題になりました。一方、ブラウザーポーラーは同期的に処理するため、各チェックの所要時間、実行数、タイムアウトを考慮する必要があります。操作を自動化するだけでなく、監視を継続できる処理能力を見積もることが大切です。

このほか、ダッシュボードの操作性、アイテム履歴ウィジェット、ホストやテンプレートを探すグローバル検索も紹介されました。HTTP エージェントを使った Prometheus エクスポーターからのデータ取得にも触れられ、既存の監視資産を取り込む方法が示されました。

■ 毎秒 100 万件をテーマとした性能検証

講演の終盤では、ClickHouse と連携した構成での性能検証が紹介されました。履歴同期処理やバッファー、保存先の設定を調整し、書き込み先に過剰な負荷をかけないようにする工夫が説明されました。強調されたのは、瞬間的なピークではなく、単一の Zabbix サーバーノードで継続して処理できる負荷として評価する姿勢です。実測値は安定して 毎秒 100 万件処理を続けられることが説明されました。今回の講演は、大規模な処理性能と、日常の小さな運用改善を結び付ける内容でした。データ収集、保存、通知、画面操作をそれぞれ見直すことで、扱いやすく拡張しやすい監視環境につながると実感しました。

Zabbix の監視データを活用する ― AI による異常検知と高度なレポート機能

Wolfgang Alper 氏の講演「Putting Zabbix Data to Work: AI-Based Anomaly Detection and Advanced Reporting」では、Zabbix が収集している大量の監視データを、単なる監視結果として見るだけでなく、Reporting、外部連携、AI-Based Anomaly Detection に活用する方法が紹介されました。Alper 氏は、Zabbix はデータ収集に非常に強い一方で、収集した情報をそのまま監視画面の中だけで使うのではなく、Business Insight に変換することが重要だと説明しました。

■ レポート作成と外部システム連携によるデータ活用

まず紹介されたのが、Widget ベースの Reporting Engine です。考え方は Zabbix ダッシュボードに近く、レポートを複数の Widget の組み合わせとして構成します。Availability、Problem History、Current Problem、Long Running Problem、Graph、Markdown など、用途ごとに異なる Widget を利用でき、Management 向けレポートに必要な背景説明や補足情報も追加できます。レポートの元データは Zabbix API から取得し、Trend だけでなく Alert、Problem、Audit Log など幅広い情報を利用します。

収集したデータは Render Process を通して、人が読むレポートに変換することも、外部システムが再利用できるデータに変換することもできます。人向けには PDF レポートを生成でき、Header、Logo、Title、Table of Contents、Page Number などを含む形式で出力されます。各 Widget は Card のように レポート内へ配置され、Service Availability、MTTR、Problem State、Host Graph などを視覚的に確認できます。一方、システム連携向けには JSON、XML、CSV 形式でのエクスポートに対応し、BI Tool、Spreadsheet、Database、External Dashboard、Message Bus などにデータを渡せます。

講演では、既存データから新しい KPI を作る例として、Mean Time to Interaction や Mean Time to Recovery が紹介されました。Zabbix Event API に既に存在する情報を使って、Tech Support Team が Incident に対応するまでの平均時間や、Incident が Close されるまでの時間を算出できます。つまり、新しいデータを収集しなくても、既存の監視データから Management に有用な指標を作れるという点が重要です。

また、外部システムごとに必要なデータフォーマットが異なる場合に備えて、Transformation レイヤも用意されています。JavaScript の transform Function を使い、Report Object に対してフィールドの追加、削除、値の変更、新しい KPI の生成、Flatten 処理、Schema の変更などを実行できます。例えば外部システムが Report ID を必要とする場合は新しい フィールドを追加し、SLI と SLA の条件を比較して Boolean 値を生成することもできます。さらに、レポートデータを OpenTelemetry Collector が扱える形式に変換する例も紹介されました。

こうした仕組みにより、Zabbix で収集したデータを他部門や別アプリケーションに連携し、監視システムを企業全体のデータソースとして活用できます。特に大規模組織では、監視データを Kafka などの Message Bus に流し、別 Department や Business Application が Subscriber として利用する構成も考えられます。

■ 外部 AI Model による異常検知

講演後半では AI-Based Anomaly Detection も紹介されました。考え方は、Zabbix から取得した Time Series Data を外部 AI Model に入力し、各 Value が通常の Behavior からどの程度外れているかを Score として返すものです。複数の Model を同時に利用する Ensemble 構成も可能で、例えば 5 個の Model のうち 3 個以上が Anomaly と判断した場合に、最終的に異常として扱うような Majority Vote も設定できます。利用する Model 数を増やせば判定の信頼性を高められますが、その分 AI Server の Resource も必要になります。

AI 側からは Anomaly Score や Segment Score、さらに Trigger 作成の参考になる Threshold などが Zabbix に返されます。これらの値は通常の Zabbix Item と同様に ダッシュボードで確認でき、Trigger Expression に利用できます。つまり、Zabbix 本体の Source Code を変更せず、既存の アイテム、トリガー、ダッシュボードの仕組みを活用しながら、外部 AI Model による Anomaly Detection を組み込める点が特徴です。

■ 収集したデータを新たな価値につなげる

講演の Takeaway として強調されたのは、「もっとデータを集めること」よりも「すでに集めているデータをもっと賢く使うこと」です。監視システムには Infrastructure、Application、Business Activity など大量の情報が蓄積されています。それらは単なる監視用データではなく、企業にとって価値のある Asset です。

Zabbix が収集したデータをレポートに変換し、Management が理解しやすい KPI として提示し、JSON、XML、CSV などで外部システムに渡し、必要に応じて AI Model で Anomaly Detection を行うことで、Monitoring の役割を大きく拡張できます。今回の講演は、Zabbix を「異常を通知する Tool」だけでなく、「企業データを集約し、加工し、外部へ活用するプラットフォーム」として捉える実践的な事例でした。

Zabbix のサービス監視を活用した BSM と SLA 管理

Marek Panečný 氏の講演「Improving Service Reliability With Zabbix SLA Monitoring」では、Zabbix の Service Monitoring 機能を Business Service Monitoring、いわゆる BSM の考え方で活用し、単なる障害監視からサービス全体の信頼性管理へ発展させる方法が紹介されました。Panečný 氏は Asseco CEIT で監視基盤を担当しており、長年さまざまな監視製品を扱ってきた中で、2013 年頃から Zabbix を主要な監視ソリューションとして利用していると説明しました。

■ サービス全体の状態を可視化する BSM と SLA 監視

一般的な IT 環境は、Hardware、Operating System、Network、Database など複数のレイヤで構成されています。従来の監視では、それぞれのレイヤに対して Item や Trigger を大量に設定し、「何も気付かないまま壊れる」ことを避けるようにします。この方法自体は正しいものの、監視対象が増えるほど Problem や Notification も増え、いわゆる Alert Flood が発生しやすくなります。また、個々の Component の状態は分かっても、「その障害が Business Service にどの程度影響しているか」までは分かりにくいという課題があります。

そこで BSM では、通常の監視レイヤの上に Business レイヤを追加します。その中心となるのが Service Tree です。Service Tree は、Service や Service Component を Node として表し、それらの関係性を Tree 構造として定義するものです。各 Node には Severity や Status があり、下位 Node の状態を上位 Node に伝播させることで、サービス全体への影響を可視化できます。また、この Service Tree があることで、SLA Report、Impact Analysis、Root Cause Analysis といった処理の基盤を作ることができます。

Zabbix は標準機能として、Service Tree の構築、Problem と Service Node の関連付け、伝播や相関のルール、さらに各 Service に対する SLA 設定を提供しています。Problem と Service Node の紐付けには Tag を利用できるため、特定の Problem Severity や条件を Service の状態へ反映できます。そのため、Business Service Monitoring の基本機能は標準の Zabbix だけでも構築可能です。

■ 独自の Widget と Module によるサービス監視の強化

一方で、講演では標準機能の弱点も指摘されました。最も大きな課題は Service Tree の表示方法です。Zabbix 標準では Service Tree を本当の Tree 形式ではなく Table 形式で表示するため、構造が複雑になるほど関係性を直感的に把握しづらくなります。また、Service Tree をダッシュボード上に表示する専用 Widget がなく、Service Tree 自体の自動生成機能もありません。そのため、大規模環境では構築や保守を手作業で行う必要があります。

この課題を補うため、Asseco CEIT では 2 つの Widget と 1 つの Module を独自に開発しました。

• Service Tree Widget
  これは Service Tree を実際の Tree 構造としてダッシュボード上に表示します。Node に Mouse Pointer を合わせると詳細情報を表示でき、対象 Service の Status や Severity が時間とともにどのように変化したかも確認できます。
• Service History Report Widget
  これは複数の Service Node の状態変化を時間軸で表示し、Downtime の割合や継続時間、最終状態変更時刻などを確認できます。Service の信頼性を履歴として把握できるため、SLA の評価や障害傾向の確認にも役立ちます。
• Impact Analysis Module
  これは Problem 一覧から特定の Problem を選択した際に、その Problem が Service Tree のどの Node に影響しているかを表示します。Problem から直接 Impact Analysis を開始できるため、単に「障害が発生した」という情報だけでなく、「どの Business Service に、どの範囲で影響しているか」を素早く把握できます。

これらの拡張機能を標準の Zabbix Service Monitoring と組み合わせることで、CIO、Service Owner、Manager など、技術詳細より Business Impact を重視する利用者にも分かりやすい Monitoring が可能になります。Service Tree を視覚的に確認し、Node ごとの履歴や SLA を把握し、Problem から Impact Analysis を行い、さらに Service Node の状態変化を Alert の起点として利用することもできます。

■ SLA 監視をサービスの信頼性向上につなげる

今回の講演のポイントは、Zabbix の Service Monitoring 機能は単なる補助機能ではなく、Business Service Monitoring を実現するための重要な基盤になり得るという点です。一方で、Service Tree の Visualization や自動生成にはまだ改善の余地があり、今後は Automatic Discovery や Service Tree の自動構築機能が加わることで、さらに実用性が高まることが期待されています。

ラリーカー製造を支える Teamcenter 監視―― PLM を止めないための実践

Marko Väätänen 氏の講演「Keeping PLM at Full Throttle: Teamcenter Monitoring in Rally Cars Manufacturing」では、ラリーカー製造で利用する Teamcenter を対象に、Zabbix による監視の実践が紹介されました。中心となるテーマは、サーバーの稼働状況だけでなく、アプリケーションや業務の流れまで把握し、製造を支える PLM（製品ライフサイクル管理）環境の安定運用につなげることです。講演では、本番環境のダッシュボードや通知の例を交えながら、現場で必要とされる監視の考え方が説明されました。

■ 正常な状態を定義し、監視の範囲を広げる

監視を設計する出発点は、何をもって正常と判断するのかを定義することです。Teamcenter が正常に機能しているかを判断するには、その基盤となるサーバーやデータベースに加え、関連するサービスや自動化処理にも目を向ける必要があります。講演では、一般的な基盤監視と Teamcenter 固有の監視項目を組み合わせ、必要な情報を収集する構成が紹介されました。

具体的な対象として挙げられたのは、データベースの状態、アプリケーションのプロセスごとのメモリ消費量、ファイルの欠落、Windows イベントログなどです。メモリリークの検出も監視対象に含まれており、サービスが起動しているかどうかだけでは分からない問題を捉えようとしています。メモリ使用量をグラフで確認することで、ある時点の値だけでなく、時間の経過に伴う変化を追える点も紹介されました。

■ 業務のワークフローに踏み込む

この事例で注目したいのは、Teamcenter 固有のワークフローを監視対象としている点です。基盤側の状態を確認するだけでなく、アプリケーション内部の処理が期待どおりに進んでいるかを追跡する視点が示されました。処理の連鎖の中に問題があっても、監視がなければ担当者が気付けない場合があるという説明は、業務に近い層を可視化する重要性を表しています。

一方で、ワークフローから必要な情報を取り出す作業は、簡単ではないことも語られました。どの情報を取得したいのか、どの条件で結果を抽出するのかを明確にし、Teamcenter のデータベースや処理の構造に合わせて設定する必要があります。
講演では、UserParameter を使った情報取得や、特定のイベントに対応するトリガーの設定にも触れられました。監視項目を増やすだけでなく、業務上の問題を判断できる情報に整えることが、実装上の要点として読み取れます。

■ ダッシュボードで利用状況をまとめて確認する

本番環境の監視画面では、サービスの状態とともに、ユーザー数やログインに関する情報を確認する例が示されました。複数の情報を一つの画面にまとめることで、担当者が環境全体の様子を把握しやすくしています。日常的に確認する情報を集約することは、異常が起きた際に、どこを調べるべきか判断する助けにもなります。

ライセンスも重要な可視化対象です。講演では、利用中のライセンス数や期限に関する情報を扱い、ダッシュボードで確認する仕組みが紹介されました。システムの稼働状況に加えて、利用者が実際にサービスを使うための条件まで把握している点が特徴です。監視対象となるユーザーのリストを更新する運用にも触れられ、収集対象を実態に合わせて維持する必要性がうかがえました。

■ 通知を、確認と対応につなげる

異常を迅速に知るためのアラームは欠かせませんが、通知が多くなると、その内容を確認して対応すること自体が課題になります。講演でも、多数のメール通知を受け取る状況が取り上げられました。情報を集めて通知する仕組みを整えるだけでは、運用上の負担がなくなるわけではありません。

そこで言及されたのが、事前チェックやワークフローの状態確認です。自動化を考える際にも、対象の状態を確かめる仕組みが必要であり、通知から直ちに処理を実行すればよいという単純な話ではありません。また、チームからの連絡や確認を取り入れるフィードバックの流れも紹介されました。監視で得た情報と現場で把握した状況を照らし合わせることが、問題の確認や対応を支えています。

■ 製造を支えるアプリケーション監視の価値

今回の講演が示したのは、監視対象をインフラからアプリケーション、さらに業務の流れへと広げる実践です。データベース、プロセス、ログ、ファイル、ライセンス、ワークフローをそれぞれ確認することで、単一の指標では見えない問題を捉えようとしています。その実現には、Teamcenter の内部構造と運用を理解し、必要な情報を選び取る作業が欠かせません。

ラリーカー製造という現場を支える PLM 環境において、監視は障害を知らせるだけの仕組みではありません。担当者が日々の状態を理解し、見落としやすい問題に気付き、対応へ進むための基盤です。Zabbix の収集・可視化・通知の機能を、対象アプリケーションの特性に合わせて組み合わせることの価値が伝わる事例でした。

おわりに

今回紹介した講演では、大規模なデータ収集を支える性能面の工夫から、日々の運用を効率化する機能、アプリケーションや業務サービスの状態を把握するための監視、さらには AI や外部システムとの連携まで、Zabbix の幅広い活用方法が紹介されました。

毎秒 100 万件の新規監視値を扱うための性能検証では、データの収集や保存の仕組みを適切に調整することの重要性が示されました。また、エージェントやプロキシの設定、通知メッセージの改善といった日々の運用に関わる工夫も取り上げられ、監視環境の規模を拡大することと、扱いやすさを両立するための考え方を知ることができました。

一方、Teamcenter の監視事例や SLA 監視の講演では、インフラの稼働状況だけでなく、アプリケーション内部の処理や業務サービスへの影響まで把握することの重要性が示されました。さらに、収集したデータをレポートや KPI に変換し、外部システムや AI による異常検知に活用する取り組みからは、監視データを運用改善や意思決定に役立てる可能性が見えてきます。

これらの事例から、監視環境を改善するうえでは、単に監視項目を増やしたり、より多くのデータを収集したりするだけでなく、何を把握したいのか、得られた情報を誰がどのように活用するのかを考えることが重要だと感じました。

Zabbix には、データ収集、障害検知、可視化、通知、サービス監視など、さまざまな機能が備わっています。これらを監視対象や運用上の課題に合わせて組み合わせることで、障害の早期発見にとどまらず、日々の運用の効率化やサービスの信頼性向上にもつなげることができます。

Zabbix Summit 2026 で紹介された事例や考え方を参考に、私たちもお客様の環境や課題に応じた監視のあり方を考え、より実用的な監視・運用の実現に取り組んでいきたいと思います。

はじめに

Zabbix Summit は、オープンソースの統合監視ソリューションである Zabbix に関する最新情報や活用事例、技術的な知見が共有されるイベントです。世界各国の Zabbix ユーザーやエンジニア、パートナー企業、開発者などが集まり、Zabbix の最新機能や今後の開発の方向性、実際の運用現場での取り組みについて理解を深める機会となっています。

今回開催された Zabbix Summit 2026 では、Zabbix の最新バージョンに関する情報をはじめ、監視運用の効率化や自動化、生成 AI との連携、オブザーバビリティなど、今後の監視基盤を考えるうえで興味深いテーマが取り上げられました。

本レポートでは、Zabbix Summit 2026 で発表されたセッションの中から、特に注目した内容をピックアップし、技術的なポイントや実際の Zabbix 環境への活用という観点から紹介します。

Zabbix 8.0 が切り拓く Observability の新時代 ― Alexei Vladishev 氏による基調講演

Zabbix Summit 2026 で、Zabbix の創設者である Alexei Vladishev 氏が「Zabbix 8.0: Redefining Observability」と題した講演が行われました。
講演では、Zabbix 8.0 の主要な新機能と性能改善に加え、AI、クラウド、モバイル、Marketplace を含む今後の戦略が紹介されました。
特に印象的だったのは、従来の監視ツールから、システム全体の状況と問題の背景を理解する Observability プラットフォームへ進化させようとする方向性です。

■ オープンソースと統合監視という Zabbix の強み

Alexei 氏は、Zabbix の大きな特徴として、オープンソースであること、さまざまな環境に柔軟に対応できること、監視に必要な機能を統合的に提供することを挙げました。
Zabbix は、OS やネットワーク機器の監視を中心に発展してきましたが、現在ではコンテナ、クラウド、アプリケーション、オンプレミスとクラウドが混在するハイブリッド環境まで対象を広げています。
異なるベンダーの製品を組み合わせて監視基盤を構築する方法もありますが、できるだけ多くの機能を一つの基盤で利用できることは、構成や運用の複雑さを抑えるうえで重要です。
ライセンス料金を課さない方針に加え、公開ドキュメント、公式トレーニング、各種サービスによって利用者を支援する姿勢も強調されました。
セキュリティについては、認証や製品開発・提供プロセスへの対策の組み込みに触れ、機能の豊富さだけでなく信頼性も重視していることが示されました。

■ OpenTelemetry とトレースによる可観測性の拡張

Zabbix 8.0 の重要なテーマの一つが、OpenTelemetry などを通じた新しい種類のデータの取り扱いです。
従来のインフラ監視では、CPU 使用率、メモリ、ディスク、ネットワークの状態といったメトリクスが中心でした。
しかし、複数のサービスが連携するアプリケーションでは、ある処理がどこを通り、どの部分で遅延や障害が発生したかを把握する必要があります。
そこで重要になるのが、リクエストや処理の経路を追跡するトレースデータです。
講演では、こうした情報を Zabbix で収集、保存、可視化する取り組みが説明され、AWS X-Ray にも言及されました。
メトリクス、ログ、トレースを関連付けて扱うことができれば、単に異常を検知するだけでなく、問題がインフラにあるのか、アプリケーションにあるのかを調べる手掛かりが増えます。
Zabbix をインフラ監視だけでなく、アプリケーションの動作を理解するための基盤へ広げる重要な変化と言えます。

■ MCP Server で AI と監視データを接続

もう一つの大きな進化として紹介されたのが、MCP Server への対応です。
MCP Server は Zabbix と AI の間に入る仲介役として機能し、AI から監視情報を参照・活用するための接点になります。
講演では、「今、最も重要な問題は何か」「どのホストに注目すべきか」といった問いを自然言語で投げかける利用方法が例示されました。
これまで監視担当者は、画面を切り替え、条件を指定し、複数の情報を読み解いて状況を把握する必要がありました。
AI との連携が進めば、必要な情報を対話形式で取り出し、調査の出発点を素早く見つけることが期待されます。
Alexei 氏は、特定の AI モデルに固定するのではなく、利用者が適切な AI の仕組みを選べる柔軟性も重視していました。
ただし、AI がすべての判断を自動化するという説明ではなく、監視データをより使いやすくするための新しいインターフェースとして理解することが重要です。

■ 複合イベント処理によってアラートの意味を整理

Complex Event Processing と呼ばれる複合イベント処理も、講演で強調された機能です。
大規模環境では、単一の障害が原因で多数のトリガーや問題イベントが短時間に発生することがあります。
すべてのイベントを個別に確認する運用では、本当に対処すべき問題が大量の通知に埋もれてしまいます。
新しい処理の仕組みでは、イベントの流れやパターンを扱い、関連する事象を整理して重要な情報を浮かび上がらせることを目指しています。
講演では、毎分 100 件を超えるイベントが発生する状況にも触れ、単純なイベント単位のルールを超えた複雑な処理や、プログラムによるパターンマッチングの拡張について説明されました。
監視の価値を、アラートを数多く出すことから、運用担当者が優先順位を判断しやすくすることへ変えていく機能です。

■ 毎秒数百万メトリクスを見据えた性能向上

性能面では、大量の監視データを継続的に処理する環境を想定した改善が紹介されました。
Alexei 氏は、毎秒数百万件規模のメトリクスを扱う事例を挙げ、ボトルネックの解消やストレージ処理の最適化について説明しました。
新しいストレージエンジンへの対応や、高度な圧縮技術によって、データを効率的に保持・処理する方向性が示されています。
CPU やメモリの効率についても改善が語られ、処理によっては大幅な高速化が得られることが強調されました。
ただし、講演中に示された性能値は特定の条件に基づくものと考えられるため、あらゆる環境で同じ改善率が得られると断定することはできません。
大規模な監視基盤ほど、こうした処理効率の向上はインフラコストや拡張性に直結します。

■ 使いやすさを高める UI とビューのカスタマイズ

UI の改善も、日常の運用に直接関わる重要なテーマです。
講演では、画面の一貫性やアクセシビリティの改善に加え、利用者が必要な情報を柔軟に表示するためのカスタマイズ機能が紹介されました。
表示する列の追加や並べ替え、タグやホストのインベントリ情報を利用した列の構成などにより、用途に応じた一覧画面を作成できるようになります。
例えば、データセンター名や機器に関する情報を列として表示すれば、問題の発生場所や対象機器を一覧から把握しやすくなります。
また、データのフィルタ条件と表示方法を保存し、異なる目的に応じて複数のビューを使い分ける考え方も説明されました。
監視データの量が増えるほど、情報の見せ方を利用者自身が調整できることの価値は高まります。

■ Zabbix Cloud と Mobile App による運用の変化

Zabbix Cloud については、監視基盤そのものの保守負担を減らすサービスとして紹介されました。
利用者がセキュリティパッチ、バックアップ、基盤のメンテナンスを細かく管理する必要を減らし、本来の監視業務に集中できることが狙いです。
クラウドから各拠点のインフラを監視する構成や、Zabbix のバージョン対応についても言及がありました。
一方、Mobile App では、重要な問題をプッシュ通知で素早く把握することと、外出先から問題の状態を確認することが主要な利用場面として示されました。
ユーザープロファイルとモバイル端末を関連付ける仕組みにも触れ、日常的な監視業務をデスクトップの外へ広げようとする姿勢がうかがえます。
Cloud と Mobile App は、監視の対象だけでなく、監視サービスの提供方法や利用する場所を変える取り組みです。

■ Marketplace が広げる拡張機能のエコシステム

Marketplace については、Zabbix 向けの追加機能やソリューションを見つけ、共有・入手するための場所として紹介されました。
例えば、新しいレポートや追加モジュールが必要な場合に、コミュニティやベンダーが提供する成果物を利用できるようにする構想です。
無料のものだけでなく、商用の拡張機能も想定されており、開発者が作成した機能を多くの Zabbix ユーザーへ届ける場として期待されています。
個別に作られていた便利な機能が広く流通すれば、利用者は開発の手間を減らせる一方、パートナーや開発者には新たな提供機会が生まれます。
講演では Marketplace に関する別セッションも案内され、利用者からの期待や意見を集めたいという呼びかけがありました。

■ 今後の展望 ― AI を製品と開発プロセスの両方へ

講演の最後には、Zabbix の長期的な方向性として AI のさらなる活用が語られました。
MCP Server による外部 AI との接続に加え、将来的にはテンプレート作成など、Zabbix の機能そのものに AI を組み込む方向性が示されました。
例えば、監視したいデバイスの情報を伝えることで、設定作業を支援するような使い方が考えられます。
また、AI の活用対象は製品機能に限らず、コードの作成やテスト、QA といった開発・品質保証の領域にも広がっています。
これらはすべてが Zabbix 8.0 で完成しているという意味ではなく、今後の開発に向けた戦略的な展望として説明された内容です。

Root Cause Analysis with Complex Event Processing ― CEP による根本原因分析

Kaspars Mednis 氏の講演「Root Cause Analysis with Complex Event Processing」では、Zabbix のイベント相関機能を活用し、大量の障害通知から根本原因を特定するための考え方が紹介されました。
複合イベント処理（ CEP：Complex Event Processing ）を利用した根本原因分析の目的は、単にアラート数を減らすことではなく、原因となる問題と派生的な症状を区別することです。
時間ウィンドウ、キャパシティ、グループ化、相関ルールを適切に設計すれば、複雑な依存関係の保守負担を減らし、障害対応時に注目すべき情報を絞り込めます。
一方で、設定によってイベントの扱いが変わるため、実際の監視環境に合わせて動作を検証することが重要です。

■ 従来のトリガー依存関係の課題

ひとつの障害が複数のサービスに影響すると、根本原因とは別に多数の関連アラートが発生します。

従来はトリガー間の依存関係を定義して対処できましたが、構成が複雑になるほど設定や保守が難しくなります。
講演では、既存の依存関係が機能することを認めながら、イベントの発生状況に応じて柔軟に関連付ける方法が説明されました。

■ 複合イベント処理（ CEP ）によるイベント相関

複合イベント処理（ CEP ）では、まずフィルターで対象イベントを選び、相関ルールを設定します。
ホストグループやタグなどの属性を条件にでき、関連するイベントを同じ処理の対象として扱えます。
相関ルールでは、どのイベントを照合し、一致した場合にどのような操作を行うかを定義します。
この方法により、すべての依存関係を手動で列挙することなく、一定の条件に基づいて問題同士を関連付けられます。

■ 時間ウィンドウとキャパシティ

中心となる概念が、イベントを一定期間保持して照合する時間ウィンドウです。
例えば 10 分間のウィンドウを設定すると、その期間に入ったイベントを条件に従って評価できます。
イベントがいつウィンドウに入り、いつ対象から外れるかによって相関結果が変わるため、継続時間の設定が重要です。
また、ウィンドウに保持するイベント数を制限するキャパシティも設定できます。
講演では、解決済みの問題であってもウィンドウ内に残る間はキャパシティを消費する場合があることが強調されました。
単にアラートが解決したかどうかだけでなく、ウィンドウ内の状態を理解する必要があります。

■ イベントのグループ化

タグなどを利用してイベントをグループ化すると、同じルールを複数の対象に適用しながら、ウィンドウをグループごとに分離できます。
例えばストレージごとにグループを分ければ、異なるストレージの障害を誤って関連付けずに済みます。
複数の一致条件を組み合わせることもでき、イベントの属性や発生順序に応じた処理を構成できます。
なお、相関ルールで処理対象から外すことと、元のアラートそのものを削除することは同じではありません。

■ ポートフラッピングへの適用

具体例として、ネットワークポートがダウンとアップを短時間に繰り返すポートフラッピングが紹介されました。
こうした変化をすべて独立した障害として通知すると、重要な問題が大量のアラートに埋もれてしまいます。
同じポートのイベントを時間ウィンドウで関連付ければ、繰り返し発生する変化をまとめて扱い、不要な通知を抑制できます。

■ 障害の連鎖とログイン失敗

バックアップ失敗など、ひとつの障害が後続の問題を引き起こすケースも取り上げられました。
イベントを関連付け、条件を満たした際に複数の問題をまとめて解決扱いにするなどの処理が考えられます。
また、ログイン失敗が繰り返されるケースでは、ウィンドウ内のイベント数を評価し、代表的なアラートを残して後続通知を抑制する方法が説明されました。

■ 独自ロジックによる拡張

講演では、ウィンドウ内のイベントを数える関数などを使い、条件判定の結果として true または false を返す処理にも言及がありました。
イベントのタグや数値属性を変更したり、複製や破棄などの操作を組み合わせたりすることで、用途に応じた相関ロジックを作成できます。

Zabbix の新たな APM の可能性 ― OpenTelemetry を活用した監視の進化

Zabbix の製品責任者である Martiņš Orinskis 氏は、「Unlocking New APM Power」と題した講演で、OpenTelemetry を活用したアプリケーション監視の新たな可能性を紹介しました。
クラウドネイティブ技術や分散アーキテクチャの普及により、アプリケーションの健全性を把握することは従来以上に難しくなっています。
単純な死活監視や個別の性能指標だけでなく、複数のサービスを横断して状況を理解し、問題の原因を迅速に特定する仕組みが求められています。

■ OpenTelemetry による多様なデータの活用

OpenTelemetry は、メトリクス、ログ、トレースなどのテレメトリデータを共通の仕組みで収集・転送するための技術です。
講演では、OpenTelemetry Protocol を通じて得られるデータには豊富な属性や情報が含まれる一方、そのままでは量が多く、監視に利用しにくい場合があると説明されました。
そこで重要になるのが、データを集約・計算・変換し、運用担当者にとって意味のあるメトリクスに整理することです。
例えば、特定の業務処理に対するリクエスト数や、サービス単位の応答時間などを抽出すれば、アプリケーションの状態を把握しやすくなります。

■ Zabbix Proxy を活用した収集と集約

今回の説明では、Zabbix Proxy を中心に OpenTelemetry のデータを扱う構成が紹介されました。
テレメトリデータを収集する処理と、そこから必要な値を取り出して Zabbix で監視する処理を分けることで、大量の生データをそのまま監視基盤に保存する必要を減らせます。
プロキシ側で集約やクエリを実行し、結果を Zabbix のアイテムとして扱うことで、既存の監視やアラート機能との連携が可能になります。
講演では、テレメトリストレージに対して SQL に似たクエリを実行し、その結果を JSON 形式で受け取り、Zabbix のストレージに保存する流れも説明されました。
これにより、詳細なデータの保管と、日常の監視に必要な指標の管理を役割分担できる構成が示されました。

■ 柔軟な設定と動的な情報の取得

OpenTelemetry を利用するための接続設定については、設定ファイルを使う方法に加え、ユーザーインターフェースから接続を定義する方法も紹介されました。
収集対象やリソース属性、ホストに関連する設定を組み合わせることで、環境に応じた監視を構成できます。
また、データに含まれるサービス名などの属性を利用し、動的に情報を識別することも重要なポイントです。
JSON 形式のデータから必要なフィールドを取り出す機能や、複数の値をまとめて取得する方法についても説明がありました。
こうした仕組みは、サービスや監視対象が頻繁に変化する環境で特に役立つと考えられます。

■ 集約間隔とアラートの設計

講演では、データの集約間隔とアイテムの実行間隔を適切に設定する必要性にも触れられました。
例えば、10 秒ごとにクエリを実行する場合、どの時間範囲のデータを集約するかによって、監視結果に欠落や重複が生じる可能性があります。
短時間のサンプリングで動作を確認しながら、用途に合った集約方法を選ぶことが重要です。
さらに、JSONPath を使ったフィールドの抽出や、取得したデータに基づくトリガーの設定によって、特定の状態を検出してアラートにつなげる考え方が示されました。
一方、JSON データに対する一部の高度な関数や相関処理については、今後の対応が期待される機能として言及されました。

■ APM と従来の監視をつなぐ

今回の講演で印象的だったのは、OpenTelemetry を独立した監視の仕組みとして扱うのではなく、Zabbix が持つ既存の監視機能と組み合わせようとしている点です。
データセンター全体の状態から、個々のサービスや特定のエンドポイントの応答時間まで、対象に応じて監視の粒度を変えることができます。
ログ、トレース、メトリクスを組み合わせて分析することで、単に異常を検知するだけでなく、その背景にある原因を調べるための手掛かりも得られます。
OpenTelemetry から得られる膨大な情報を、実際の運用に役立つ指標へ変換することが、今後の APM における重要なテーマだと感じました。
Zabbix の新しい取り組みは、従来のインフラ監視とアプリケーションの可観測性をつなぎ、より幅広いユースケースへの対応を目指すものといえます。

おわりに

今回の講演からは、Zabbix 8.0 が単なる機能追加版ではなく、監視基盤の役割を広げる重要な節目として位置付けられていることが伝わってきました。
OpenTelemetry やトレースによるデータの拡張、MCP Server を通じた AI 連携、複合イベント処理による情報の整理、大規模環境を支える性能改善は、いずれも現代の複雑なシステム運用に直結するテーマです。
さらに、UI の柔軟性、Cloud、Mobile App、Marketplace の取り組みは、Zabbix を利用する人や提供する企業の裾野を広げるものです。
オープンソースと柔軟性という従来の強みを維持しながら、収集したデータから問題の意味を理解し、迅速な判断につなげる Observability プラットフォームへ進化していくことが、今回の講演の中心的なメッセージだったと感じました。

はじめに

2026年3月、アジア最大級の FOSS カンファレンスである FOSSASIA Summit 2026 が開催され、その併設イベントとして PostgreSQL PGDay が開催されました。
PGDay は PostgreSQL に特化した 1 日カンファレンスで、世界各地から PostgreSQL 開発者・ユーザが集まる技術イベントです。
SRA OSS では昨年も FOSSASIA PGDay に参加しましたが、今年は参加に加え、2名がスピーカーとして登壇しました。本記事では、FOSSASIA および PGDay の概要とともに、SRA OSS からの発表内容を中心にご紹介します。

FOSSASIA Summit および PostgreSQL PGDay について

FOSSASIA Summit は、オープンソースソフトウェアやオープンテクノロジーをテーマとした国際カンファレンスです。
ソフトウェア開発だけでなく、OS、クラウド、データベース、AI、セキュリティなど、幅広い分野のセッションが用意され、アジア圏を中心に世界各国から参加者が集まります。

その中で開催される PostgreSQL PGDay は、PostgreSQL の開発や運用、拡張、エコシステムに焦点を当てたイベントです。PostgreSQL の内部構造、性能チューニング、高可用性、運用、セキュリティなど、実運用に直結するテーマが幅広く扱われました。

SRA OSS からの発表

Pgpool-II による PostgreSQL 高可用性と性能最適化

基盤技術グループのプリンシパルエンジニア でPgpool-II 開発者でもある彭 博（ペン ボ）からは、「Pgpool-II: An Introduction to High-Availability and Performance Optimization for PostgreSQL」と題し、PostgreSQL 高可用性構成における課題と、それを解決する Pgpool-II の役割について紹介しました。

PostgreSQL にはストリーミングレプリケーションなどの仕組みがありますが、自動フェイルオーバー／フェイルバックは標準では提供されておらず、読み書きの振り分けやロードバランシングはアプリケーション側で実装が必要といった課題があります。Pgpool-II はクライアントと PostgreSQL の間に配置されるミドルウェア で、アプリケーションを大きく変更することなく「自動フェイルオーバー」や「クエリのロードバランシング」といった機能を提供することで、これらの課題を解決します。また、「コネクションプーリング」「インメモリクエリキャッシュ」といったパフォーマンス向上機能も提供しています。

さらに、Pgpool-II 自体が単一障害点になることを避けるための「Watchdog 機能」についても解説されました。Watchdog 機能により「複数のPgpool-II ノード間での死活監視」「リーダー選出」「Virtual IP の自動切替」「スプリットブレイン防止」といった仕組みが提供され、Pgpool-II 自体も冗長化可能であることが紹介されました。

pg_ivm: 高速なマテリアライズドビュー更新

技術開発室の主席研究員でPostgreSQLコントリビュータでもある長田悠吾（ながたゆうご）からは、「pg_ivm: Extension for Fast Materialized View Maintenance and Recent Improvements」というタイトルで、自身が開発するPostgreSQL 拡張モジュールである pg_ivm について発表しました。

pg_ivm は増分ビューメンテナンス（Incremental View Maintenance, IVM） という、高速なマテリアライズドビューの更新を実現する機能を提供する拡張です。通常のマテリアライズドビューでは、元テーブルが更新された後には REFRESH MATERIALIZED VIEW によりビュー全体を再計算する必要がありますが、IVM では更新された差分のみを計算してビューに適用することで、更新コストを大きく削減します。

具体的には、この拡張モジュールにより、テーブル更新時に自動かつ高速に更新されるIMMV（Incrementally Maintainable Materialized View）と呼ばれるビューを作成できます。テーブル更新時のオーバーヘッドなどいくつかの考慮点はありますが、これを用いることで、ビューの更新が通常の REFRESH と比べて数百倍高速となるケースも示されました。

また、最近の改善として外部結合ビューへの対応が追加されたほか、将来の機能改善として、（テーブル更新時に自動で行うのではなく）手動によるビューの増分更新や、パーティションテーブル、論理レプリケーションへの対応などが検討されていることも紹介されました。

その他の発表

PGDay では、SRA OSS の発表以外にも、PostgreSQL の現在と将来に関わる多様なセッションが行われました。

基調講演では、PostgreSQL の30年の歴史や、PostgreSQL コミュニティとその貢献方法についての紹介が行われました。PostgreSQL の開発や内部構造に関係する発表としては、PostgreSQL 18 新機能解説や、データベースのメタ情報を格納するシステムカタログを深掘りするセッション、近年のインデックスの改善について解説するセッションがありました。

また、Pgpool-II や pg_ivm 以外にも、クエリ実行を外部の Apache DataFusion クエリエンジンで行える拡張モジュール pg_fusion や、LIKE/ILIKE を用いた文字列のマッチングを高速化するためのインデックス Biscuit といったツールを紹介するセッションもあり、PostgreSQL エコシステムの広がりを感じられるプログラムとなっていました。

おわりに

今年の FOSSASIA PGDay も、PostgreSQL の進化とコミュニティの活発さを改めて実感できるイベントでした。SRA OSS としても、PostgreSQL および Pgpool-II や pg_ivm といったツールの開発と情報発信を通じて、引き続き PostgreSQL コミュニティの発展に貢献していきます。

はじめに

Current はデータストリーミング分野の第一人者が一堂に会するコミュニティイベントです。イベントでは主に Apache Kafka® (以下 Kafka) や Apache Flink® (以下 Flink) などのストリーミング処理ソフトウェアに関する講演が行われ、世界中の人々が集まり交流、学び、そして情報共有する場です。

今年 2025 年は 3 月 19 日にインドのベンガルール、5 月 20 日にイギリスのロンドン、そして 10 月 29 日にアメリカのニューオーリンズで開催されました。今回はその中のニューオーリンズで開催されたイベントに参加してきましたので、私が聴講したセッションを中心にその様子をお伝えしたいと思います。

開催地、ニューオーリンズ

開催地であるニューオーリンズはアメリカのルイジアナ州南部にあるメキシコ湾に面した港湾都市です。ジャズの発祥地として有名で、フレンチクォータと呼ばれる地域ではフランス・スペイン植民地時代の街並みが残り、クレオール、ケイジャン料理などの美食も味わえる全米でも有数の観光都市でもあります。

イベント会場の様子

Current New Orleans 2025 はニューオーリンズの中心部、ミシシッピ川沿岸の Ernest N. Morial Convention Center (アーネスト N. モリアル コンベンションセンター) の一角で開催され、60 以上のセッションに 3,500 人以上が参加する非常に大規模なイベントとなりました。イベントホール内では 50 近いスポンサーブースが立ち並び、各社が提供するデータストリーミングに関する様々なソリューションの紹介や参加者同士の交流の場となっていました。

それ以外にもイベントホール内ではハッカソンが開催されていたり、VR の体験、ストリーミング処理ともかかわりの深い AI に関するアートの展示など、様々なイベントが開催され、大いに盛り上がっていました。

イベントで提供されるセッションは非常に多く複数のセッションが同時に行われていたため、そのすべてをレポートすることはできませんが、その中から私が聴講したものをいくつか紹介したいと思います。

一日目

Keynote (一日目): Building Intelligent Systems on Real-time Data

一日目の Keynoteでは Confluent 社の CEO 兼共同設立者、Jay Kreps 氏がプレゼンターとして壇上に立ちました。Confluent 社はカリフォルニアに本社を置き、Kafka を基盤とした企業向けのリアルタイムデータストリーミングプラットフォームやフルマネージドクラウドサービスを提供する会社で、日本法人として Confluent Japan もあります。また本イベント Current を主催する会社でもあります。

Keynote の主題は昨今の AI の台頭に対して、それを使ったシステムをどう構築し、組織内のソフトウェアそしてリアルタイムのデータとどう結び付けていくかについてです。効果的に AI を活用していくには AI が利用するデータをどのようにアップデートしていくかが重要です。例えばデータの更新をバッチ処理で行うとすればその分最新の状況との差異が生まれます。そこでリアルタイムデータを逐次的に処理できるストリーミングデータパイプラインを構築すれば、常にデータを最新に保ち続けることができます。そのシステムの構築に有効なのが Kafka や Flink といったストリーミング処理のソフトウェアです。企業にとっても日々生まれ続けるデータをリアルタイムに活用するためにはストリーム処理が必要不可欠なのだと感じました。

また Confluent Intelligence と名付けられた新しいサービスもこのセッションの中で発表されました。これはビルトインの機械学習関数、リアルタイムコンテキストエンジン、ストリーミングエージェントの 3 つの製品から構成されるサービスで、AI システムが過去のデータから継続的に学習し、リアルタイムで行動することを可能にするためのものとのことです。AI エージェントや RAG (検索強化生成)、AI 向け機械学習パイプラインの構築、または Kafka および Flink によるコンテキスト提供に活用が期待されるサービスです。

さらには、Confluent Private Cloud の発表も併せて行われました。これは Confluent Platform を基盤としており、自社インフラにクラウドサービスの効率性を備えたプライベートデータストリーミング環境を実現できるサービスとなるようです。

続いて一日目の個別セッションの内容をご紹介します。

Introduction to Apache Flink: Key Concepts and Architecture

ストリーム処理とバッチ処理の両方をサポートする分散処理フレームワークである Flink について解説する、初心者向けのワークショップセッションです。ストリーム処理とバッチ処理の概念や Flink による分散処理のコンセプトとアーキテクチャを基礎から丁寧に解説されており、ストリーム処理を一から学びたいという人にも最適なセッションだと感じました。

A Deep Dive into Kafka Consumer Rebalance Protocols: Mechanisms and Migration Process Insights

Kafka 4.0 で実装された新しい Consumer Rebalance Protocol の詳細について、既存との違いをデモを交えてわかりやすく解説されていました。また、既存のプロトコルからの移行のメカニズムについてもオンラインとオフライン両方に対応した方法を紹介されていました。

Consumer Rebalance Protocol とは、ConsumerGroup 内でどの Partition をどの Consumer に割り当てるかを調整するメカニズムです。従来のプロトコルではグループ内のメンバが変化した際に、リバランスが完了するまで一時的に Consume が停止するという制約がありましたが、新しいプロトコルではそれが軽減・削除されています。また、リバランスによる再割り当てのロジックを Broker 側に移動しており、それによる大幅な高速化や安定性の向上も見込めるという利点もあります。

The Kafka Protocol Deconstructed: A Live-Coded Deep Dive

このセッションでは Kafka が持つ様々な機能を実現する上でどのようなプロトコルを用いているのかを、かなり根本的な部分まで深掘りして解説されていました。例えば、リクエストのヘッダやボディがどういった要素から構成されていて、それぞれの要素にはどういった内容のデータが格納されているかなど、Kafka が実際にやり取りしている通信プロトコルを明らかにし、それを一から再構築するといったところまで実演していました。

プロトコルを深く知ることで Kafka の内部挙動を本質的に理解できると共に、実用上でのチューニングや問題解決にも応用できそうな、私にとっては非常に有用な内容でした。

Current party

一日目の終わりには参加者ならだれでも参加できるパーティが開かれました。時期が近いこともあり、中はハロウィン風の装飾がされていたり、ニューオーリンズらしくライブ演奏やクレオール、ケイジャン料理が味わえたりと様々な趣向が凝らされており、参加者同士の交流を深めるという意味でも非常に有意義なパーティでした。

二日目

Keynote (二日目): Be Ready for What’s Next

二日目の Keynote では Confluent 社のアドボカシーおよびデベロッパーエクスペリエンスエンジニアリング部門責任者の Adi Polak 氏が登場し、リアルタイムシステムの現在までの発展の経緯について語りました。モノリシックなシステムからマイクロサービスへの転換、マイクロサービス同士をつなぐ Kafka の登場、そしてデータレイクとして Apache Hadoop と HDFS から Apache Iceberg、Apache Hudi、Delta Lake といったテーブルフォーマットを導入したことによる信頼性の向上。これらの発展によって今現実に起こっていることをリアルタイムで処理するための準備が整いました。そして現在 AI が登場しました。真に信頼できる AI のためには優れたモデルが必要ですが、それを構築・実用するには信頼できるリアルタイムデータ、ひいてはそれを作り出す信頼できるシステムを準備しておくことが必要であると彼女は述べていました。

このセッションではその他にもテレビ番組のトークショーを模した形式でのデータストリーミング分野の第一人者へのインタビューや、コミュニティやこの分野に貢献した企業への授賞式なども行われました。

続いて二日目の個別セッションの内容をご紹介します。

What Can you do with a (Kafka) Queue?

このセッションでは Kafka をメッセージキューとして利用可能にするための新しい Consumer Group の実装である、Share Group について解説されていました。従来の Consumer Group では Partition 内でのメッセージ順序を維持するために、グループ内で重複して同じ Partition からメッセージを取得することはありませんが、Share Group ではそれを可能にすることでメッセージキューとして Kafka を使うことができるようになります。この機能はまだ完全に実装されてはいませんが、これによって Kafka の用途の可能性が広がる非常に興味深いものだと感じました。

Playing Chess by Scaling Multi-Agent LLM Play with Kafka Queues

これは上記の Kafka のキュー機能を利用して、LLM (大規模言語モデル) にチェスを並列で同時にプレイさせてみたという、中々面白い内容のセッションです。AI と Kafka の新機能を組み合わせることで、アイディアによってはこういう使い方もできるんだという一例だと思います。実際にセッション中にデモを披露していましたが、かなりスムーズに LLM がチェスを複数盤面で同時にプレイする様子も伺えました。

AI 関連のセッション

Keynote で言及もあったように、データストリーミングは AI とも関連の深い分野です。本イベントでも AI に関するセッションは数多くあり、AI Alley Theater という AI セッション専用のブースが設けられるほどでした。

その他のイベントの様子

おわりに

Current はデータストリーミングの現在を肌で感じることのできる唯一のイベントです。私も今回参加したことで、Kafka をはじめとしたストリーミング処理について、最新の動向や深い知見を大いに得ることができ、データストリーミングの分野が今いかにホットであるかということを知ることができました。

セッションの内容も幅広く、初心者向けに Kafka や Flink といったデータストリーミングプラットフォームを構成するソフトウェアの基礎を解説するものや、より深く内部動作を解説するもの、ソリューションや活用例を紹介するものなど、データストリーミングを知りたい様々な層に広く訴求するイベントだと感じました。皆さんもデータストリーミングに興味があれば、是非参加してみることをお勧めします。

また、本イベントのセッションは動画でアーカイブされており、誰でも見ることができます。非常に多くの有用なセッションがありますので、データストリーミングや Kafka、Flink などのソフトウェアについて知りたいという方は、こちらもチェックしてみてください。

はじめに

COSCUPはConference for Open Source Coders, Users, and Promotersの略で、ヨーロッパ最大のオープンソースイベントであるFOSDEMを参考に2006年から開催されている、オープンソースコミュニティが主催するカンファレンスです。

会場となったのは国立台湾科技大学で、常時20以上のトラックが並行して開催される大規模なイベントでした。講演のほかにも、BoF(Birds of a Feather, コミュニティや参加者が主催する非公式のミートアップ)や、Hacking Corner(開発者向けの交流用オープンスペース)、各OSSコミュニティのブースなどが設けられていました。

参加者人数は延べ3000人を超えており、参加していて非常に活気のあるイベントだと感じました。また、日本のOSS関連のイベントと比べると、参加者の年齢が若いと感じます。

本レポートでは、筆者が参加したセッションの中から特に印象に残ったものをいくつか紹介します。

[Prime Session] Programming Language for AI age

Rubyの開発者、まつもとゆきひろ氏による講演です。Ruby固有の話ではなく、生成AIと付き合ってプログラミングすることについて語られました。

AIを使用するのはペアプログラミングするようなもので、人間と違い、気を遣う必要がないのがメリットです。しかし、AIを使用してプログラミングするには不完全な自然言語を使う必要があります。そうすると、逆アルファ症候群(ある技術が登場すると、その技術が登場する前よりも忙しくなるにもかかわらず、それをありがたがって使用してしまう)を引き起こしてしまいます。今のところ、AIエージェントはドキュメントの生成やリファクタリングには優れている一方、大規模なプロダクトベースのプログラミングには向いていません。(使うとしても、例えばメモリ管理の部分などではAIよりもその分野に詳しくないといけないです。)

人間の言語はプログラミングに向いていないので、AIとやり取りする専用の言語が必要です。それは、簡潔で、理解しやすく、堅牢な表現力と拡張可能な語彙を持つような言語です。そして、そのような特徴を持った言語はすでに存在しています。――それはRubyである、と締めくくられました。

2025年現在のAIの能力に対する感想については、筆者が生成AIを使用した感じと似通っていました。一方で、AIとプログラミングする専用の言語が必要、という認識については思い浮かばなかった発想で、感銘を受けました。

From MongoDB to PostgreSQL

この講演では、ドキュメントデータベースのオープンソース標準を策定するプロジェクトおよびMongoDB互換のオープンソースデータベースFerretDBが紹介されました。MongoDBのライセンス変更に伴い、ドキュメントデータベースにもリレーショナルデータベースのような標準を策定必要がある、という問題意識によりプロジェクトが発足しました。

単にJSONを格納できる、という観点ではPostgreSQLも使用できますが、ドキュメントデータベースの世界ではフレームワークや開発者がMongoDBに依存しており、PostgreSQLをそのまま使用することは困難です。FerretDBは、バックエンドでPostgreSQLを動作させつつも、クライアント側ではMQLというMongoDBの問い合わせ言語を受け取ります。MQLとPostgreSQLの仲立ちをするのがFerretDBです。

また、バックエンドで動作させるデータベースはPostgreSQL互換であればよいので、例えばより高い可用性を求めるのであればバックエンドのデータベースとしてYugabyteDBを動作させることもできるようです。

Japanese Food Knowledge Graph for Taiwanese

日本でOSCを開催している、OSPN(Open Source People Network)による講演です。
日本食を例にあげて、ナレッジグラフの紹介がなされました。ナレッジグラフとは、知識を表現するグラフです。各概念を表すノードがあり、それぞれのノードはプロパティを持っています。ノード間の関係性はエッジ(線)によって示されます。例えば、カツカレーは以下のように表現されます。

Curry - CONTAINS -> Onion
Curry - CONTAINS -> Meat
Curry - IS_SERVED_WITH -> Rice
Katsu Curry - IS_COMPOSED_OF -> Curry
Katsu Curry - IS_COMPOSED_OF -> Tonkatsu

このナレッジグラフは、後述するRAG(検索拡張生成)の情報源としても使用することができます。

講演は英語で行われていましたが、日本語のできる台湾の参加者が、他の参加者の質問を日本語に通訳しやり取りするなど、和気あいあいとした雰囲気での交流がされていました。

Hot Topics in Global PGConf

この講演では、世界各地で開催されているPostgreSQLカンファレンス（PGConf）で話題のトピックについて紹介されました。PGConfで近年話題になっているものを紹介することで、最新技術トレンドや地域ごとの特色、あるいは地域に関係なく役立つ知見を共有することを目的とした講演でした。

技術トピックとしては、AI×pgvectorによるベクトル検索、pg_hint_planやVACUUMを中心としたパフォーマンス最適化、論理レプリケーションやActive-Active構成による高可用性、EDB Postgresのセキュリティ強化、RDSやAuroraなどクラウド移行の事例が紹介されました。PostgreSQL 18の新機能にも触れられていました。

台湾のPostgreSQLコミュニティに技術トレンドを紹介する目的の講演でしたが、紹介された技術トピックは日本のPostgreSQL Conferenceでもよく選ばれているトピックであり、親近感を覚えました。

Community-Driven Edge AI or Building Offline AI Agents with Open Models

この講演では、オープンモデルを活用したオフラインAIエージェントについて紹介されていました。従来のAIはネットワーク接続が前提でしたが、モバイル端末上で動作する「AI Driven Device」への進化が進んでおり、オフラインでも動作可能なAIエージェントのニーズが高まっています。

まず、生成AIが備えておくべき機能として、マルチモーダル(複数の種類の情報、例えばテキストデータのほかに画像や音声、動画を入力として受け取れる)、Function Calling(AIが外部の関数やAPIを呼び出す機能、例えばユーザから写真を受け取って位置を推測し、Google Mapを呼び出す)といった概念が紹介されました。

次に、Googleが開発したオープンモデルであるGemma 3、Gemma 3 Nanoについて紹介されました。
どちらのモデルもマルチモーダル、Function Callingといった機能を兼ね備えています。特にGemma 3 Nanoはサイズが小さく、モバイル端末にも組み込み可能なうえ、完全オフラインで動作する点が特徴的です。

生成AI分野が主題の講演も1つは参加してみようと思い聴講した講演でしたが、図や写真が多くスライドに掲載されており、事前知識が薄くともわかりやすい講演でした。

打開 AI 模型的任意門：用 PostgreSQL 撐起AI

こちらの講演では、PostgreSQLを生成AIの長期的な文脈保持に活用するための方法が紹介されました。
生成AIの既存のモデルを使用して独自チャットボットを作成する際、RAGという手法が使われます。これは、生成AIに参考にさせたい情報をあらかじめデータベースに保存しておき、問い合わせが来たら「関連がありそうな」情報をデータベースから探し出してAIに渡すことで、より求めている回答に近づける手法です。

RAGが登場した際はテキストデータを単にベクトル化し、ベクトルデータベースに保存することが考案されていましたが、このベクトルデータベースには欠点があります。それは、「関連がありそうな」情報をベクトル間の距離により算出するため、チャットの参考にさせるには望ましくないテキストが算出されてしまうという問題です。
本講演ではナレッジグラフを作成しておき活用する方法について紹介されました(Graph RAGといいます)。
ナレッジグラフは知識が構造化されていますので、場合によってはベクトルデータベースを使用するよりも望ましいテキストを抽出することができ、生成AIの精度向上に役立ちます。

筆者が参加したPostgreSQL関連の講演では一番参加者が多く、生成AIへの関心の高さが肌で感じられました。

監控與告警設計：打造適合團隊使用的 PostgreSQL 觀測儀表板

この講演では、金融業の大規模なデータベース環境におけるPostgreSQLの監視・可視化の取り組みが紹介されました。クレジットカード業務を例に、822万枚以上の流通カードを扱う高負荷なシステムにおいて、DB管理者がどのようにサービス性能を向上させているかが語られました。

DBAとデータ分析チームの視点の違いを踏まえた監視設計をしていました。DBAはCPU、メモリ、IO、WALサイズなどのリソース管理を重視し、分析チームはクエリの待機状態やブロックされたプロセスなど、ユーザーの行動に着目するためです。講演では、PrometheusとGrafanaを用いて、両者のニーズを満たす観測ダッシュボードを構築する方法が実例とともに紹介されました。

紹介された監視項目はpg_stat_activityやpg_locks、VACUUの進捗状況などで、一般的にPostgreSQLの状態を把握するのにつかわれるビューやテーブルが網羅的に紹介されていました。また、観測ダッシュボードは視覚的にわかりやすくて良いと感じました。

20 週年論壇：總召視角下的開源精神

COSCUP 開催 20周年を記念した対談です。COSCUP 歴代の代表者が参加し、オープンソースの精神についてをメインに対談が行われました。
対談中に、特に印象に残った点をいくつかあげます。

まず、ソフトウェアをオープンソースとすることのメリットは、コミュニティによる議論によってソフトウェアを改善していくことができる点です。多くの人がそのソフトウェアについて議論をすることで、単独で開発していた時には起こらなかった発想が生まれ、より洗練されたものにできます。

次に印象に残ったのは、「オープンソースに貢献することは、コミュニティに善意を共有している」という考え方です。
オープンソースコミュニティにおいては、善意で誰かに助けてもらうことがあります。ソフトウェアのエラーについて質問すると、誰かにこたえてもらった、というようなことです。この助けてくれた人は、何らかの利益を求めて貢献しているのではなく、質問者が今後コミュニティに何らかの貢献をすることを期待しているのです。

そして、オープンソースの精神を維持するには、オープンソースの考え方を発信し続けていく必要がある、という考え方にも感銘を受けました。時代は変化し続けており、オープンソースの精神を脅かすような技術が台頭してきています。例えば、ブロックチェーンはデフォルトでオープンである一方、ブロックチェーンのユーザがオープンソースの考えに関心があるかは微妙です。また、生成AIやクラウドコンピューティングは構成が複雑なため、オープンであることを要求することは難しいです。このような時代の変化の中で、COSCUPを通じてオープンソースの精神を広めていく必要がある、と述べられていました。

筆者は入社して以来PostgreSQLに関連する業務を行ってきましたが、本対談に参加することによりコミュニティへ貢献することの重要性を再認識しました。

終わりに

COSCUP 2025 へ参加し、聴講してきた講演から印象に残ったものを紹介しました。COSCUPにおいても、AIに関する関心は非常に高く感じられました。講演のタイトルにもAIという単語が含まれているものが多く、またAI関連の講演は他のものと比べ参加者が多い傾向にありました。一方で、AIが目まぐるしく進歩し、変化していく時代の中で、オープンソースコミュニティをどのように維持していくか、が重要だと感じました。今後、筆者も業務で主に使用しているPostgreSQLコミュニティについて、何らかの貢献ができればと思います。

はじめに

PGConf.dev の正式名称は PostgreSQL Development Conference で、PostgreSQL のユーザや開発者、コミュニティ関係者が集まる、PostgreSQL の開発とコミュニティの発展に焦点を当てたイベントです。 今回、株式会社SRA OSSはシルバースポンサーとして、このカンファレンスを支援しました。

今回の会場は、モントリオールのダウンタウン中心部に位置するPlaza Centre-Ville。全４日間の日程のうち、初日には 次年度のPostgreSQL 開発の優先度などを対面で議論する Developer Meeting（招待制）や、拡張モジュールについての議論をアンカンファレンス形式で行う Extension Ecosystem Summit、コミッターからパッチについてのアドバイスを受けられるAdvanced Patch Feedback Session（招待制）、コミュニティ運営に関するグループ・ディスカッションを行うPostgres Community Summitなどが行われました。

2日目の朝にはオープニングセッションと基調講演があり、その後２日間にわたり、３トラック並行でさまざまな講演が行われました。最終日はアンカンファレンスが開催され、その後クロージングセッションで締めくくられました。

本レポートでは、本カンファレンスのいくつかの講演をピックアップして紹介します。

基調講演

今回の基調講演はDavid DeWitt 博士による「From RAP to Snowflake – A Look at 50 Years of SQL DB Scalability 」でした。

1980年代中頃から1990年代初頭にかけて、ウィスコンシン大学の教授だった時代に博士が主導した並列データベースプロジェクト「Gamma」は、シェアード・ナッシング・アーキテクチャ（shared nothing architecture：複数の各ノードがCPU・メモリ・ストレージを完全に独立して持ち、互いに共有せずに性能をスケールさせる方式）の概念を初期に実装・検証したものとして、Spark、Snowflake、Redshiftといった今日の大規模分散データベースシステムの基礎となっています。

この講演は博士の50年にわたるキャリアを通して見たデータベースのスケーラビリティの発展の歴史を、RAP（Rotating Associative Processor) という初期のデータベースマシンから、安価なハードウェアの登場による独自データベースのホスティングの普及、そしてクラウドの時代へと続く流れで紹介されました。

その中では、分散データベースにおけるハッシュ結合の重要性や、ストレージとコンピュートを分離する現在主流の構成において、Snowflakeがいかに革新的であったかなどが語られていました。

Learned Index の実装に向けた試み

Gray W Evans氏 (Fujitsu Australia) とNishchay Kothari 氏(Fujitsu Asia Pte Ltd) による講演「Exploring the benefits of learned indexes in PostgreSQL: Theory and Implementation」では、機械学習を活用したインデックスである Learned Index を PostgreSQL に実装に関する試みについて発表が行われました。

Learned Index については以前のイベントレポートでも紹介しましたが、簡単に説明すると、インデックス内部のキー探索に機械学習モデルを用いることで、高速な検索およびインデックスサイズの削減を目指す技術です。

今回の発表では、Learned IndexのPostgreSQLへの実装に向けた具体的な検討結果が紹介されました。Learned Indexの構造にもいくつか種類がありますが、今回の発表では、データ分布の変化に強く更新処理に対応できるALEX (Adaptive Learned Index) という構造を用いることが検討されていました。

しかしながら、インデックス全体をメモリ上に保持することを前提とするALEXと、インデックスページをディスクに永続化するPostgreSQLのアーキテクチャの間には非互換性があり、通常のワークロードにおいてはLearned Indexによる性能改善はあまり期待できないことがわかってきました。

ただし、クエリ実行中の途中経過に対する一時的なインデックスなど、ALEXインデックスが有用となり得るユースケースについての検討も進められているようです。
今後は、今までにわかってきたことを論文にまとめるとともに、ALEXインデックスが有用なケースに向けて拡張モジュールとして開発を進めるほか、静的なデータ分布を得意とする別のLearned Index構造についても、PostgreSQLにおけるユースケースを検討を行っていく予定とのことでした。

トランザクションマネージャを拡張可能に

近年、様々な分散データベースが登場しており、そこに伴い、グローバルトランザクションマネージャ（GTM）やクロックベースのアルゴリズムなど、多様な分散トランザクション手法が利用されています。 Yuya Watari 氏 (NTT) の講演「Revisiting XTM: A Practical Case Study Highlighting Its Needs」では、PostgreSQLにおいてそうした多様なトランザクション処理をサポート可能にする 拡張トランザクションマネージャ（eXtensible Transaction Manager, XTM）の有用性について議論が行われました。

XTMは2015年に開発コミュニティに提案されたアイデアですが、結局PostgreSQLには取り入れられていません。本発表では、外部データラッパ（FDW）とパーティショニングテーブルを組み合わせたシャーディング構成におけるトランザクション処理を例に、XTM の有用性が再評価されました。

postgres_fdw を使うと、別ノードのPostgreSQLのテーブルに格納されているデータを、自分のノードのテーブルのように参照・更新することができます。しかし、PostgreSQL標準のpostgres_fdw では分散トランザクションに対応しておらず、複数の外部サーバが参加する二相コミットを利用することができません。そこで、この発表ではpostgres_fdw を改造した postgres_fdw_plusを使用しています。

二相コミットにはコミットの「準備」と「確定」の2段階の過程があります。通常は、全ての処理が完了してコミットが確定した後に、クライアントへトランザクション完了の応答を返します。しかしこの発表では、性能を改善するために、「全ての外部サーバでコミットの準備ができた」段階でクライアントに応答を返すという最適化を採用しています。

ただし、この最適化はトランザクションの一貫性に影響を与える可能性があります。たとえば、FDW 経由のデータ更新とコミット準備が外部サーバで実行され、クライアントがトランザクション完了の応答を受け取った直後に、別のトランザクションを開始して外部サーバのデータを直接参照した場合、最初のトランザクションがまだ「コミット準備」状態にあるため、更新したはずのデータが見えないという現象が発生します。

このような状況を解決できるのがXTMです。トランザクション開始時の処理をカスタマイズし、「準備状態のコミットが確定するまで」外部サーバでのトランザクションの開始を待機させることで、更新済みのデータを正しく参照できるようになります。

発表では性能評価も行われ、XTM を利用したトランザクション処理をカスタマイズした場合でも、性能への影響はほとんどなかったことが示されました。一方で、トランザクション隔離性に影響があることが言及されており、ユーザがトランザクションマネージャの制限や前提を十分に理解していることの重要さも示唆されました。
最後に、様々な分散データベースが登場している中で、多様なトランザクション要望に対応するためにXTMの重要性は高まりつつありますが、「本当に必要な機能は何か」を知るには、実際に様々なトランザクション手法を実装してみる必要があるだろうという主張で発表は締めくくられました。

VACUUM の最新情報と今後

更新を繰り返されるテーブルから不要なタプルを回収し、古いトランザクションIDを持つタプルに「凍結」処理することでトランザクションIDの周回を防ぐ ― VACUUMは、PostgreSQLの状態を健全に保つために大切な役割を担っています。Masahiko Sawada氏 (AWS) の講演「The Present and Future of VACUUM in PostgreSQL」では、そんなVACUUMの最新の改善と、今後起こりうる改善が紹介されました。

講演の前半では、PostgreSQL 17 で行われたVACUUMのメモリ効率改善など、最近の改善を振り返りつつ、PostgreSQL 18 での新たな改善点として eager scanning が紹介されました。

通常のVACUUMでは、不要領域がないテーブルページについては処理をスキップして、そのため凍結処理も行われません。その結果、凍結が必要なタプルが徐々に蓄積し、最終的にトランザクションIDの周回を回避するため、大量のタプル凍結処理を行うaggressive モードのVACUUMで負荷が高まる可能性があります。

これに対処するための仕組みがeager scanning です。これは通常のVACUUMの最中に、たとえ不要領域が存在しないページでもスキップせずに、凍結処理のためのスキャンを実行するというものです。ただし、凍結できるタプルが少なく、ページ全体の凍結の失敗が一定以上続いた場合には、eager scan は中止されます。この失敗の割合は、新たに導入されたパラメータ vacuum_max_eager_freeze_failure_rate によって調整可能です。

後半には、PostgreSQL 19 以降に登場する可能性のある、現在開発中のVACUUMの改善がいくつか紹介されました。その一つが、Sawada氏が提案しているテーブルデータの並列VACUUMです。現在のVACUUMではインデックスは複数のワーカプロセスで並列処理可能ですが、テーブル本体は並列処理できません。それを改善しようという提案です。

その他にも、テーブルサイズを切り詰めるVACUUM FULL / CLUSTER の後継として、 CONCURRENT オプションをサポートするREPACK コマンドの提案など、今後のVACUUM改善に向けた興味深い取り組みが紹介されていました。

共有バッファサイズの動的変更

PostgreSQLの共有バッファのサイズは shared_buffers パラメータで決定されますが、現在この値を変更するためにはデータベースの再起動が必要です。このため、ワークロードに応じた動的なスケーリングや、メモリの最適利用が難しく、自動チューニングツールの活用も制限が生じるという課題があります。

Ashutosh Bapat 氏 (EnterpriseDB) の講演「Changing shared_buffers on the fly」は、この問題に取り組むもので、PostgreSQLを再起動せずにshared_buffers を動的に変更可能にする提案について議論されました。

共有バッファの管理に複数のメモリ構造が関係していますが、従来はそれらの領域を共有メモリ上に一括して獲得していたため、共有バッファのサイズが変更時に各構造のメモリアドレスが変わってしまうという問題がありました。提案されている方法では、各構造毎に独立した共有メモリセグメントを使用し、さらにメモリアドレス空間を余分に確保しておくことでこの問題を解決しています。

また発表の中ではメモリサイズ削減時の振る舞いや、サイズ変更時のバックエンドプロセスとの同期、サイズ変更の契機となるイベント（設定のリロード時、SQL関数やDDLコマンド）などについても議論されていました。

動的に切り替わる実行計画

Alena Rybakina 氏 (Postgres Professional)による講演「Switching between query plans in real time (Switch Join)」では、クエリ実行中に現在の実行計画が期待通りに動作しない場合に、別の実行計画へ自動で切り替える機能である Switch Join が紹介されました。

具体的には、２つのテーブルを結合するクエリにおいて、当初はネステッドループ結合で処理を行うものの、推定行数の誤差が一定以上大きい場合にハッシュ結合に切り替える、といった機能を提供します。

Switch Join はPostgreSQLの拡張モジュールとして、カスタムスキャンとフックを用いて実装されています。非常に興味深い機能ですが、ベンチマーク結果では、一部クエリでは性能向上が見られる一方で、オーバヘッドにより別のクエリでは性能が低下する場合もあり、使用するには注意が必要そうです。

なお、本機能はオープンソースではなく、 PostgresPro Standard の一部として提供される予定とのことでした。

適応的なVACUUMの制御

Melanie Plageman 氏 (Microsoft) による講演「Fraught Feedback: Trying and Failing to Implement Adaptive Behavior in Postgres」では、VACUUMの振る舞いを適応的に制御するという実験的な試みについて紹介されました。

ひとつの試みは、VACUUMの負荷を調整するパラメータvacuum_cost_delayの値を、タプル回収の進行具合およびデッドタプルの発生速度を考慮して自動調整するというものです。デッドタプルの発生に対して回収が追いつかなくなった場合はこのパラメータ値を小さくしてVACUUM処理の割合を増やし、逆の場合にはパラメータ値を大きくしてVACUUMを小休止の割合を増やし、負荷を減らすというアイデアです。しかし、実際には処理が安定せず、あまり良い結果は得られなかったようです。

もうひとつの試みは、しばらく変更されないであろうテーブルページを統計的に予測し、そういったページを早めに凍結処理するというものです。これにより、小規模なVACUUMが多く発生した一方、全体のVACUUMにかける時間の総量は減少したとのことでした。

アンカンファレンス

最終日に開催されたアンカンファレンスは、講演者や話す内容があらかじめ決まっている通常のセッションと異なり、参加者がその当日にその場で話題を提案し、議論する形式のイベントです。議論したいテーマがある参加者は、大きなポストイットにそのテーマを書き、順番に口頭で簡単に紹介していきます。最終的には、会場の参加者による多数決で12のテーマが選ばれ、3つのトラックに振り分けられ議論されました。

今回は選ばれたテーマには、PostgreSQLの開発をスケールする、自動VACUUMのパラレル化、PostgreSQLのマルチスレッド化、スタンバイのコミット順序とCSNスナップショット、pg_stat_statementの未来、プランナの意思決定を明確にする、などがありました。

「PostgreSQL のマルチスレッド化」は、前回の pgconf.dev 2024 に引き続き注目を集めているトピックです。今回もThomas Munro 氏　(Microsoft) による関連講演「Investigating Multithreaded PostgreSQL」があり、このテーマへの関心の高さがうかがえました。

また、「スタンバイのコミット順序とCSNスナップショット」では、プライマリとスタンバイの間でトランザクションの「可視」タイミングが異なることに起因する一貫性の問題が議論されました。スタンバイにおける可視化のタイミングはWALの書き込み順で決まりますが、それはプライマリにおける可視化タイミングと同じとは限りません。現在 PostgreSQL開発コミュニティに提案されているCSN (Commit Sequence Number) スナップショットは、この問題を解決する方法としても期待されているようです。

さらに「プランナの意思決定を明確にする」では、PostgreSQLが実行計画を作成する過程で、どのようなプラン、スキャン、インデックスが除外されたか、あるいや優先されたかを知るために有用な情報についての議論がなされていました。

ポスターセッション

今回初の試みとして、ポスターセッションが開催されました。イベント開催約１ヶ月前に、自分たちが提案するパッチやプロジェクトを紹介するポスターの作成が呼びかけられました。作成されたポスターはA2サイズで印刷され、会場内の様々な場所の壁に展示されました。

筆者もこの企画に参加し、ポスターを作成し展示させていただきました。

これらのポスターはオンラインでも閲覧可能となっています。

おわりに

今回で２回目の開催となったPGConf.dev 。昨年参加したときも感じたことですが、このカンファレンスは改めて「PostgreSQLの未来を向いているイベント」であるという印象を強く受けました。

開発コミュニティで現在議論されている提案に関する講演はもちろんのこと、実験的な取り組みを共有する発表の数々が刺激的でした。中でも、多様なワークロードや状況変化に対応するための拡張性や適応性を高めるための提案は、私自身の関心とも重なり、特に興味深く感じました。また、コミュニティそのものの改善や進化を目的とする講演もあり、カンファレンス全体を通して、「これからのPostgreSQLを自分たちで作り上げていく」、「その場に参加していく」という、コミュニティの原動力のようなものを感じることができました。

来年の PGConf.dev 2026はカナダのバンクーバでの開催が予定されています。今回得られた知見と刺激を今後のコミュニティへの貢献に活かしながら、来年もまたぜひ参加できればと思います。

はじめに

FOSSASIA は、オープンソース技術の促進と開発を目的としたアジア最大級のコミュニティであり、オープンソースソフトウェア（FOSS: Free and Open Source Software）に加え、ハードウェア、オープンデータ、AI などの分野で活動しています。FOSSASIA Summit は、このコミュニティが毎年開催するアジア最大級のオープンソース技術イベントであり、開発者、イノベーター、企業、教育者が一堂に会し、知識と技術を共有する場となっています。

今回の会場は バンコク市内の The True Digital Park West で、大小さまざまなデジタル企業や団体が入居するオフィススペース、コワーキングスペース、会議室、飲食店、イベントスペースなどを備えた巨大な複合施設です。会期中の3日間にわたり、AI & Data Science、Cloud & DevOps、Database、Hardware & Firmware、Security、Robotics など多岐にわたるテーマの合計170のセッションが、常時3〜4トラック並行して開催されていました。

FOSSASIA PGDay 2025 は PostgreSQL に焦点を当てたイベントで、FOSSASIA Summit 2025 の数あるセッションの１つとして、2日目に開催されました。
本レポートでは、FOSSASIA Summit 2025 の発表の中から、特に PGDay に関連するトピックを中心にいくつか紹介します。

FOSSASIA PGDay 2025

まずは、PGDay で行われた講演について紹介します。

AWS と PostgreSQL コミュニティ

PGDay の最初の講演は、Amazon Web Services (AWS) の Michael Paquier 氏による “AWS and the PostgreSQL community” でした。この講演では、プラチナスポンサーでもある AWS と PostgreSQL コミュニティの関わりが紹介されました。Amazon RDS や Amazon Aurora などのサービスで活用されているように、AWS にとって PostgreSQL は重要な戦略的コンポーネントと位置づけられています。こうしたサービスを顧客中心の方針で展開する中で、AWS は PostgreSQL に対し、ユーザーの課題を解決する機能の提案や実装を行っています。実際、AWS の PostgreSQL コミュニティへの貢献は大きく、コアチームメンバー 1 人、コミッター 7 人が AWS に所属しています。最新リリースである PostgreSQL 17 では、AWS のメンバーによる 162 件のパッチがコミットされており、全体の 10.2% を占めるとのことです。

講演の後半には、顧客の問題を解決するため AWS が関わった PostgreSQL 17 新機能の例が２つ紹介されました。１つは組み込みの照合順序です。照合順序（collation）とはテキストをソートするときに利用される文字の順序を規定するもので、従来は libc、ICU といった外部のライブラリに依存していました。その場合、外部ライブラリがアップグレードされた際に、照合順序の変化によりインデックスの破損などの影響がでる可能性がありました。PostgreSQL 17 では外部ライブラリに依存しない組み込みの照合順序プロバイダを持てるようになっています。また、もう1つの例として論理レプリケーションの pg_upgrade 対応が挙げられていました。

pgroll: スキーマ移行ツール

Fujitsu の Kothari Nishchay 氏による講演 “PostgreSQL pgroll – Zero-Downtime, Reversible Schema Migrations” では、テーブル定義の変更を安全に行うためのオープンソースのコマンドラインツール pgroll が紹介されました。このツールを使うと、アプリケーションの互換性を破るような破壊的変更や、データベースをロックすることなく、スキーマ移行を行うことができます。

スキーマの変更は JSON ファイル形式でコマンドに指定します。複数のスキーマバージョンを同時に保持することができるため、アプリケーションに問題が発生した場合、元のスキーマにロールバックすることも可能です。この複数のスキーマ管理は、実際のテーブルにビューを使用して「仮想的なスキーマ」を作ることで実現されています。例えば、テーブルのカラム定義を変更する場合、実際のテーブルには古い定義のカラムを残し、新しいカラムを追加します。そして、このカラムの参照は新旧それぞれのスキーマに対応したビュー経由で行われ、。新旧カラム間のデータの同期はトリガを用いて行われます。移行が完全に完了すれば、古いバージョンのスキーマは削除可能となり、最終的に実際のテーブル定義が更新されます。

PostgreSQL と Microsoft SQL Server の違い

PostgreSQL は、他の RDBMS からの移行先としても人気が高まっています。AWS の Roneel Kumar 氏と Sameer Kumar 氏による講演 “Overcoming Challenges in SQL Server to PostgreSQL Migrations: Mapping Backups, Collations, and Case Sensitivity” では、Microsoft SQL Server（以下、SQL Server）から PostgreSQL への移行時に知っておくべき両者の違いが、二人の講演者による対話形式で紹介されました。

比較の内容は、データレイアウト、メモリ、トランザクションなどのアーキテクチャから、データ型、大文字小文字の扱いといったアプリケーション開発機能に関わるもの、バックアップやレプリケーションなどの運用面に至るまで、多岐にわたりました

例えば、トランザクションに関しては、PostgreSQL と SQL Server では同時実行制御の方法に大きな違いがあります。具体的な状況として、複数のトランザクションが同時にテーブルの同じ行にアクセスし、片方が行の更新、もう片方が参照を行う場合を考えます。PostgreSQL では基本的に MVCC（MultiVersion Concurrency Control：多版型同時実行制御）を使用しており、更新前の古い行の情報はテーブルの中に残ります。そのため、更新前の行への参照は、行の更新中でもロック待ちが発生しません。一方、SQL Server ではロックを使用しており、更新と参照の間でロック待ちが発生します。SQL Server でも Snapshot Isolation モードでは MVCC を使用しますが、その場合、古い更新前の行の情報は tempdb と呼ばれる別の領域に格納されるという違いがあります。

その他にも、データ型の違いに関して、SQL Server の bit データ型を移行するには PostgreSQL の boolean 型を使用するのが良いという情報や、SQL Server 向けに書かれたアプリケーションを PostgreSQL で動作させるためのツール Babelfish for PostgreSQL の紹介もありました。

PostgreSQL のベクトル検索

Postgres Professional (PostgresPro) の Vladlen Popolitov 氏による講演 “PostgreSQL for AI – Real Vector Search in PostgreSQL –” では、生成AIの普及により注目度が高まっているベクトル検索に関する解説が行われました。

ベクトルは、テキスト、画像、音声などのさまざまなデータを変換して生成することが可能で、これによりベクトル間の距離、つまり類似性に基づいた検索が可能になります。

このような検索機能を PostgreSQL に提供するのが、拡張モジュールの pgvector です。オープンソースであることによるコストの低さに加え、最近のパフォーマンス向上もあり、PostgreSQL + pgvector の組み合わせは、Pinecone など他のベクトル検索専用データベースと並ぶ人気の選択肢となりつつあります。

講演の前半では、pgvector がサポートするベクトルインデックスアルゴリズム HNSW（Hierarchical Navigable Small World） の概要や、パラメータ調整による検索レイテンシ・精度への影響、またベクトルサイズの削減がもたらす効果について説明がありました。

後半では、類似性検索とフィルタリング条件を併用する場合の課題について取り上げられました。たとえば、「あるテキストに似ていて、かつ著者が特定の人物で、言語が日本語であるテキストを10件抽出する」といった検索を行う場合、まずベクトルによる類似検索が行われた後に、追加のフィルタリングが実行されます。このため、初期の類似検索で十分な候補が得られなかった場合、指定件数（10件）に満たない結果しか得られないことがあります。

この課題への対応策としては、検索範囲を広げるようパラメータ設定を調整する方法がありますが、これは検索のレイテンシ（応答時間）の増加というトレードオフを伴います。別の対策として、部分インデックスを利用する方法も紹介されました。

さらに、pgvector v0.8.0 以降では新たに「反復スキャン（iterative scan）」という機能が導入されており、必要な件数が得られるまで自動で類似検索を繰り返すことが可能になっています。

最後に、フィルタリング検索用の他カラムを指定してベクトルインデックスを構築できる、マルチカラムベクトルインデックスについても言及がありました。現時点ではオープンソース実装は存在していませんが、PostgresPro が提供する商用パッケージでは既に対応しているとのことです。

Learned Index

Fujitsu Australia Limited の Gary Evans 氏による講演 “Exploring the benefits of learned indexes in PostgreSQL: Theory and Implementation” では、機械学習を活用したインデックス構造である Learned Index の理論と PostgreSQL への実装に関するアイデアが紹介されました。

インデックスは、データベースの検索性能を向上させるために広く利用されている構造で、抽象的には「キー値から対応するレコード位置を特定するマッピング」を提供するものです。たとえば、代表的なインデックス構造である B-tree は、木構造を使ってキーの探索を行います。

Learned Index は、このキー探索に機械学習モデルを応用する新しいアプローチです。まず、データの分布を学習させたモデルを使って、特定のキーが存在するおおよその位置を予測し、その周辺を効率的に探索することで、従来よりも高速な検索を実現します。また、インデックスのサイズを小さく抑えられるという利点もあります。

講演ではこの概念の解説に続き、2017年から現在に至るまでの Learned Index に関する研究の流れが紹介されました。学術界でも注目を集めるトピックであり、トップレベルのデータベース国際会議「VLDB 2023」で採択された論文のうち、11件が Learned Index に関するものであったことも紹介されました。

PostgreSQL で Learned Index の実装に取り組む理由としては、PostgreSQL の高い拡張性、pgvector などの進化する AI エコシステムの存在、Learned Index と相性の良いとされるパーティショニングや BRIN インデックス のサポート、充実したインデックスフレームワークなどが挙げられていました。また、実装アプローチとして、Learned Index の学習が進むまでは従来のインデックスと併用し、安定して動作するようになった段階で切り替えるとなどのアイデアも紹介されました。

最後に、想定される課題として、プランナによるコスト推定の精度や、複数トランザクションの同時実行時における安全性の確保などが挙げられていました。

アジアの多言語に対応した全文検索

地元タイのソフトウェアエンジニアである Vee Satayamas 氏による講演 “PostgreSQL extension that enables full-text searching on almost every known human language” は、PostgreSQL の全文検索を多言語に対応させる拡張モジュールの開発について紹介されました。

PostgreSQL には組み込みで全文検索機能が備わっていますが、デフォルトではタイ語や日本語など、主にアジアの言語には対応していないという課題が提示されました。これは、アジア開催の FOSSASIA PGDay らしい視点でもあります。

これまでにも、タイ語の全文検索に対応する拡張モジュールとして pg-search-thai が存在していましたが、長らくメンテナンスが行われていませんでした。そこで、Vee 氏はこのモジュールを Rust で再実装し、タイ語だけでなく、日本語、中国語、ミャンマー語などにも対応した chamkho-PG を開発したとのことです。

Injection Points: PostgreSQL の新しいテスト基盤

ASW の Michael Paquier 氏によるもう１つの講演 “Advanced testing with Injection Points” では PostgreSQL 17 で導入された新しいテスト機能について解説が行われました。この機能は、複数のプロセスが相互に関与するような状況のテストを容易にする、主に PostgreSQL の開発者を対象としています。

PostgreSQL コードの中には injection point と呼ばれるコードが数カ所埋め込まれており、テストコードはその箇所で特定のメッセージを出力させたり、プロセスを待機させたり、逆に待機しているプロセスを起こしたりといった様々な動作をさせることが可能となります。実際にこの機能は TAP テスト、Isolation テストと呼ばれる PostgreSQL のテストコードの中で使用されており、PostgreSQL の品質の向上に一役買っています。

実際にこの機能は、PostgreSQL のテストスイートに含まれる TAP テストや Isolation テストといった仕組みの中で活用されており、複雑な並行動作の検証や、エッジケースの再現性の向上に貢献しています。こうした Injection Points の導入により、PostgreSQL の品質はさらに高められています。

その他の発表

FOSSASIA PGDay 2025 ではこの他にも、拡張統計情報を自動生成するツール pg_stat_advisor の紹介、マルチマスタ論理レプリケーションクラスタを構築する pgEdge による DDL レプリケーションの自動化、PostgreSQL を使った メッセージキューの実装に関する議論、さらに Kafka で収集した膨大なログデータを PostgreSQL で効率的に管理するツール Bagger の紹介など、さまざまな興味深い講演が行われました。

FOSSASIA のその他の発表

続いて、FOSSASIA 2025 で行われた PGDay 以外の講演をいくつか紹介します。

ThaiLLM：タイにおけるオープンソースAIの取り組み

ビッグデータ研究所（Big Data Institute, BDI）の Tiranee Achalakul 博士による講演 “Empowering Thailand with Open Source AI: The Vision and Impact of ThaiLLMs” では、BDI の取り組みと、タイ独自の言語モデルである ThaiLLM プロジェクトについて紹介されました。

BDI はタイの公的機関であり、「医療・観光などに関するビッグデータの統合と解析」、「データの提供者と消費者を結びつけるエコシステムの構築」、「マイクロクレデンシャルを活用した人材育成」の3つがミッションとして紹介されました。

ThaiLLM は、2つ目のミッションである「ビッグデータエコシステムの構築」の一環として、国内の複数機関と連携して進められているプロジェクトです。このプロジェクトでは、タイ固有の言語や文化に適した AI モデルの開発を目指しており、生成されたモデルは 一部のデータやツール等も含めてオープンソースとして公開される予定とのことです。

Eval-Driven による生成AI開発

Mercari の Teofilo Narboneta Zosa氏と Jehandad Kamal氏による講演 “LLMOps for Eval-Driven Development at Scale” では、生成AIアプリケーションの開発における「評価」の重要性と、その方法論について解説されました。

冒頭では、生成AIアプリケーションを構成する基本要素として (1) 言語モデルそのもの、(2) 入力となるプロンプト、RAG (Retrieval Augumented Generation) により与えられるコンテキストなどのデータ、(3) モデルが生成する結果の評価の3つが挙げられ、この中でも、とくに 評価（3つ目の要素） を重視する「Eval-Centric」なアプローチが、生成AIアプリケーションの開発・運用において重要であると強調されました。

具体例として紹介されたのが、メルカリが提供する生成AI機能「AI出品サポート」です。これは、フリマに出品する商品の写真とカテゴリを入力するだけで、商品名や説明文を自動生成するというサービスです。

講演ではこのアプリケーションを例に、プロンプトの評価方法についてもいくつかの実践例が紹介されました。たとえば、最初は「タイトルの長さ」や「説明文が日本語で書かれているか」といった単純なヒューリスティック評価からスタートし、人間からその後は生成モデル自身を用いた評価、いわゆる LLM-as-a-Judge の手法を導入。また、トレーディングカードなどのニッチな商品に関しては、生成された説明文の事実性を検証するための工夫も必要であったことが語られました

後半では、評価を素早く反復できるようにするための具体的な実践として、モデルの入力や出力を可視化する可観測性の確保、プロンプトやデータセットのバージョン管理による再現性の確保、そして評価の自動化を支えるツールの導入といった、評価基盤の整備が重要であることが強調されました。

さまざまなデータベース

FOSSASIA Summit 2025 では、PostgreSQL 以外にもさまざまなデータベースに関する講演が行われました。

例えば、YDB の Evgenii Ivanov 氏の講演 “Designing YDB: Constructing a Distributed DBMS for OLTP and OLAP from the Ground Up” では、オープンソースの分散データベース管理システムである YDB が紹介されました。YDB は OLTP と OLAP の両方に対応したリレーショナルデータベースであり、コンピュートとストレージを分離し、数千台のサーバ上で動作可能な分散アーキテクチャを採用しています。また、分散トランザクションによって ACID 特性を満たす強い一貫性を提供するとのことでした。

講演の冒頭では、名前が似ている分散データベース管理システムである「YugabyteDB」とは別物であることが軽く触れられ、その後、主に分散ストレージのアーキテクチャについて詳しく説明されました。

さらに、WebStoating Pte. Ltd. の Ilya Verbitskiy 氏による講演 “Unlocking the Power of Graph Databases with Neo4j” では、グラフデータベース Neo4j の概要と、その問い合わせ言語である Cypher クエリの紹介がありました。また、MySQL の Phasupong 氏による講演 “MySQL Document Store” では、MySQL における JSON 型のサポートとその活用方法について解説が行われました。

特定のデータベースソフトウェアに特化していない講演として、Grab の Chin Hwee Ong 氏による “Your Data is Late Again! Handling Late-Arriving Data in the Modern Data Stack” では、データ処理基盤における遅れて到着するデータへの対応方法について解説されました。

講演の冒頭では、遅れたデータを正しく捉えるために重要な「時間」の概念として、(1) 現実世界でイベントが発生した時刻である Valid Time（有効時間）、(2) システムにデータが記録された時刻である System Time（システム時間）の2つが紹介されました。

その後、遅れて到着するデータが下流システムに与える影響を防ぐための方法として、遅延データの検出やデータ整合性を確認する手法が解説されました。また、遅れて到着したデータを差分的に処理する際の注意点についても触れられました。特に、遅れをどの程度まで遡って処理するかを決めることで、精度とパフォーマンスのトレードオフを調整する方法が紹介されました。

生成AI関連

上で述べたメルカリの講演以外にも、生成AIに関する講演も多数ありました。

例えば、Fleek Network の Mohit Bhat 氏による講演 “All About AI Agents: Building Your Own Open Source AI Agent to Post on Your Behalf” では、AI エージェント作成に必要となる基本概念として、LLM (言語モデル)、Embeddings (埋め込み)、RAG (Retrieval-Augmented Generation) について解説され、さらに ElizaOS などのフレームワークを用いた実践的なアプローチが紹介されました

また、Michael Christen 氏による講演 “The Complete Anatomy of ChatGPT: A Precise Breakdown of LLMs and Transformers” では、生成AIの発展を歴史的に振り返る内容が紹介されました。具体的には、マルコフ連鎖（1906年）から始まり、シャノンの情報理論（1948年）、パーセプトロン（1957年）、中国人の部屋（1980年）といった思考実験、リカレントニューラルネットワーク (RNNs)（1996年）、Convolutional Networks (CNNs)（1998年）、Embeddings（2002年）、アテンションメカニズム（2014年）、GPT-1（2018年）に至るまでの重要な理論や技術をエポックメイキングな論文を引用しながら、2022年に登場した ChatGPT へと至る過程を解説する大変興味深い内容でした。

データベースに関する講演として先に紹介した YDB と、生成AIに関する講演として YDB の Alexander Zevaykin 氏と Elena Kalinina 氏による “YDB: How to implement streaming RAG in a distributed database” では、YDB の非構造データのメッセージング機能「トピック」とベクトル検索機能を用いて、継続的に流入するデータに基づく RAG である「Streaming RAG」を実装する方法が解説されました。

Tor が支える匿名性と自由

セキュリティの分野では、The Tor Project の Roger Dingledine 氏による講演 “Tor: privacy for everyone” では、プライバシー保持のための技術である Tor について、その考え方と仕組みが紹介されました。「匿名性」という概念の捉え方は人によって異なり、例えば市民にとってはプライバシー、ビジネスにとってはセキュリティ、政府にとっては通信解析の障害となり得る一方、人権活動家にとっては情報への到達可能性を意味します。例えば、ある国では、BBC のニュースを政府によって阻止されずに読むために Tor が使用されている例が紹介されました。このように、社会的に弱い立場にいる人々にとってこそ、技術は特に有用であるという主張がなされました。

おわりに

今回の FOSSASIA Summit 2025 に参加して、まず感じたことは、タイおよびアジアにおけるオープンソースコミュニティの活力でした。特にタイ国内では、独自の言語モデル「ThaiLLM」のプロジェクトに代表されるように、オープンソース技術を活用したデジタル経済の普及・発展に力を入れていることが伺えました。

講演内容は、やはり全体的に AI 関連の話題が多く、オープンソースにおいてもこの分野がこれからさらに発展していくであろうことが感じられました。筆者は業務で主に PostgreSQL やデータベースの分野に関わっていますが、AI と関連する領域についての理解を深める必要性を改めて実感しました。

また、FOSSASIA はオープンソース技術全般の普及や発展を目的とする組織であるため、特定のオープンソース製品だけではなく、関連する概念や理論、アイデアについての発表も多かったことが印象的でした。まさに、オープンに知識や技術を共有する場として非常に刺激的なイベントでした。