みなさまこんにちは！エアークローゼットでCTOをしている辻です。 これまでに DB Graph MCP、社内MCP群の全体像、Biz Graph、Sandbox MCP と、社内向けに作っているMCPサーバーを順に紹介してきました。 DB Graph は ORM 解析からのスキーマグラフ、Biz Graph は会議スライドからの施策抽出と Week ノード設計、Sandbox MCP はそもそもアプリ公開基盤 ── 目的も実装も全部違うのですが、自分でも書きながら気づいたのは、設計の根っこにある考え方は同じだということです。 今回はその根っこの話をします。Agentic Graph RAG ── 私たちが社内のいろんな領域でグラフを作るときに、繰り返し採用している設計フレームの話です。 「Graph RAG なら聞いたことある」「Microsoft の OSS でしょ？」と思った方、ちょっ
みなさまこんにちは！エアークローゼットでCTOをしている辻です。 前回の記事で全社DBを自然言語で横断検索できるMCPサーバーを紹介し、社内MCP群の全体像もお見せしました。今回はその中で「Biz Graph」と一言で紹介していたものを深掘りします。 施策と KPI の関係をグラフ構造で表現し、「あの施策、効果あったの？」に AI が答えられるようにした話です。 なぜ Graph RAG なのか AI をより活用するために重要なのは、データの羅列ではなくデータの関係性を伝えることです。 データ量がそこまで多くなければ NotebookLM のようなツールで十分に成果が出せます。しかし、ビジネスデータすべてをコンテキストに入れることは不可能です。施策の報告資料、KPI スプレッドシート、マーケの週報、物流の日次実績 — これらを全部まとめてプロンプトに突っ込むことはできない。 そのため、現状
みなさまこんにちは！エアークローゼットでCTOをしている辻です。 前回・前々回の記事では、社内の全DBを自然言語で検索できるDB Graph MCPと、17台のMCPサーバー群で社内業務をAIに開放したMCPサーバーを紹介しました。おかげさまでどちらも多くの反響をいただきました。 今回はMCPの話ではなく、もう少し手前の 「社内の情報基盤」 について、私がまず最初に情報化したいと思っていた"会議"の情報化を実現した話です。 Google Meet の 録画・文字起こし を、Slackチャンネルに 自動共有 し、さらに過去の会議内容を 自然言語で検索 できるようにした仕組みです。 課題：対面コミュニケーションの価値と、失われるコンテキスト 対面のコミュニケーションは、速いし密度が高い。テキストで30分かかる合意形成が、会議なら5分で済むことも珍しくありません。これが会議の最大のメリットです。
これらは全て TypeScript で実装され、Pulumi で GCP にデプロイされ、Google OAuth で認証されています。 設計思想 なぜこんなに分けたのか 1つの巨大な MCP サーバーに全機能を詰め込むこともできますが、あえてサーバーを分けています。理由は： 認証スコープの分離 — GWSサーバーにはWorkspace APIのスコープが必要だが、DBクエリサーバーには不要。スコープを最小限にすることで権限の暴発を防ぐ デプロイ独立性 — Grafanaサーバーの変更がDBクエリに影響しない。障害の爆発半径を小さくする ユーザーごとの選択 — エンジニアは全部入れるが、マーケチームはGWSだけ、のように必要なものだけ .mcp.json に追加すればいい 共通基盤 全サーバーに共通するパターンがあります。 認証: 共通パッケージで Google OAuth 2.0 + P
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
