枠が 1 つ空いていたので、急遽翌日 6/24 の PostgreSQL アンカンファレンスで話す予定だった内容から一部を切り出して話すことにしました。
（参加者一覧を確認したら、アスキーの大谷イビサさんが何らかの都合でキャンセルされて空いた枠だったんですね）
とはいえ
10 分（質問タイムを少し圧縮したとしても 11 〜 12 分）で GraphRAG の説明まで内容に含める余裕はなく…と思っていたら LT トップバッターの方（とすりさん）が予定されている内容が GraphRAG の仕組みの説明で、「それなら GraphRAG 自体の説明を省けるからなんとかなる！」と思って（翌日 6/24 の PostgreSQL アンカンファレンスで話す資料すら未着手だったのですが）即参加申し込み。
会のレギュレーションで「前日中に資料を所定の場所にアップロード」が決まっていたので急いで資料を作って（うっかり Typo をいくつか残したまま）なんとか準備を完了しました。
当日
オフィス出勤日だったので開始に遅れる予定だったのですが運良く定時退勤 RTA に成功して、開始前ギリギリに配信用の StreamYard に入室することができました。
（入室用の URL、一度確認していたにもかかわらずいざ入室しようとなったときになかなか見つからず焦る）
AWS SUMMIT JAPAN 2025 AI/ML ブース特集（AWSJ 佐藤さん）
ちょうどこれを書いている 26 日に会期が終わりましたが、AWS Summit Japan 2025 のブース展示の事前説明でした。
今回、残念ながら
今年は現地に行けないけどオンラインで応援
— hmatsu47(まつ) (@hmatsu47) 2025年6月23日
（AWS Summit）#jawsug_aiml#jawsug
AWS Summit Japan 2025 には現地参加できませんでしたが、X の TL で様子を見ながら配信を視聴していました。
AWS Summit 2025 注目の初出展ブース！
— Kazuki_Adachi (@k_adachi_01) 2025年6月23日
・Amazon Nova
・Formula 1
F1シミュレーションをAIで作れる！自分で作ったコースを自分で走れるそうhttps://t.co/jRSVschZaX#jawsug, #jawsug_aiml
そういえば F1 ではないのですが X の TL ではホンダのクルマが話題になっていましたね。
GraphRAG の仕組みまるわかり（とすりさん）
GraphRAG の仕組みについての分かりやすい解説でした。
すごく丁寧に説明していただいているので助かる
— hmatsu47(まつ) (@hmatsu47) 2025年6月23日
（わたしの話の中では何も説明してないので）#jawsug_aiml#jawsug
（便乗させていただいてすみません）
GraphRAG
— ますの＠おさとう (@masno_soy) 2025年6月23日
→従来のRAGで発生する断片的な情報しか取得できないという課題を緩和することができる。
#jawsug_aiml
目的としてはこれ以外にも「LLM に正確な文脈を把握させる」（重要情報の取りこぼし防止やハルシネーションの軽減）などがありますね。
ほんとGraphRAGかどうかに関わらずRAGは突っ込む文章やデータ次第な面が大きい#jawsug_aiml#jawsug
— hmatsu47(まつ) (@hmatsu47) 2025年6月23日
いわゆる Naive RAG（純粋な RAG）ではこれが結構大事という認識です。
（Advanced RAG（事前＋事後検証などで精度を高める RAG）はコストがかかるのとレスポンスが遅くなる問題が…といいつつ GraphRAG も Advanced RAG 側ですが）
生成 AI で web アプリケーションを作ってみた（たじもんさん）
最近流行りの AI コーディングエージェントを使って Web アプリケーションを作る（残念ながら完成しなかった）話でした。
コーヒーを飲み比べた記録を残すためのアプリケーションの開発でしたが、個人的に
会社のチームの同僚に愛知から北海道とか全国各地に豆の買い付けに行くメンバーがいる#jawsug_aiml#jawsug
— hmatsu47(まつ) (@hmatsu47) 2025年6月23日
ということで意外と身近なテーマ（？）でした。
生成AIが一気にたくさんコードを書いてくるとたぶん慣れてる人でもレビューは大変#jawsug_aiml#jawsug
— hmatsu47(まつ) (@hmatsu47) 2025年6月23日
AI エージェントがたくさん書いてくれるのは良いけどレビューが大変、というのはよく聞く話です。
個人開発は大変。「僅差」で楽しいが勝ちそう。
— ますの＠おさとう (@masno_soy) 2025年6月23日
やはり僅差,,,（インフラ勢の大きな壁）#jawsug, #jawsug_aiml
楽しむのは大事ですね。
（特に AI エージェントにやってもらった内容のチェックとダメ出しばかり繰り返しているとき、楽しくないと「なんで自分はこんなことをしているんだろう…」となりますからね）
分かる
— Kazuki_Adachi (@k_adachi_01) 2025年6月23日
生成AI使って個人開発してると楽しくなって知らない技術を使ってしまいがち...#jawsug, #jawsug_aiml pic.twitter.com/7YzNL0Nbl3
LlamaIndex の Property Graph Index を PostgreSQL 上に構築してデータ構造を見てみる
わたしのネタでした。
GraphRAG でグラフ構造のデータをデータストアに格納する際、通常はグラフ DB などネイティブでグラフ構造をサポートするグラフストアを使うのですが、性能を度外視すればリレーショナルな DB にも格納することができます。
実際、SQL 標準（SQL:2023）にもプロパティグラフ向けの SQL 構文は存在し、これを使う形で Oracle Database 23c ではプロパティグラフをサポートしています。
一方で PostgreSQL は通常のグラフ DB 向けのクエリ言語（Cypher など）も SQL:2003 のプロパティグラフ向け構文もサポートしていないのですが、通常の JOIN や再帰共通テーブル式を使ってグラフを探索する実装が TiDB（PingCAP）から提供されていたので、これを PostgreSQL+pgvector の環境に移植してデータを投入して見てみた、という話をしました。
やはり時間が足りず 12 分ほど早口で話したので正直理解はしづらかったと思います（反省）。
#jawsug_aiml
— とすり (@tosuri13) 2025年6月23日
LlamaIndexだと結構GraphRAGのカスタマイズが柔軟にできるんだなぁ🤔
GraphRAGの検索構造初めてちゃんと知れた！検証だけしておいて全然理解できてない…w
— ふくち (@har1101mony) 2025年6月23日
#jawsug_aiml
反応ありがとうございました。
