研究 PoC の製品統合 — ナレッジグラフ分析をマルチテナント製品へ

課題

研究チームの PoC は、単独のサーバー上で一つのデータを相手に動いていた。製品では、複数の顧客が同じサーバーを共有し、画面体系・データモデル・権限・リリースの手順が決まっている。PoC で動くことと、製品の中で他の利用者に迷惑をかけずに動くことの間には差がある。そこを埋めるのが担当だった。

担当の線引き

• 研究チーム: 技術文書からのナレッジグラフ抽出、分析手法（コミュニティ検出、構造的空隙の分析、次元圧縮、密度マップ）、PoC の画面
• 自分: 製品への移植と、本番で使える状態にすること。画面と API、バックエンドのモデルとマイグレーション、AI チャットのモデル接続と権限の配線、検証環境での不具合の切り分けと応急処置、根本対応の切り出し

設計判断

• 最初の実装は、顧客が実際に使っている画面の系統とは別の側に向いていた。レビューで気づいた時点で作り直し、以後は移植先の前提を先に確かめてから着手した
• 表示はワークスペース単位で許可制にし、未認証と権限なしを区別して返した。キャッシュのキーにもワークスペースを含め、顧客の間でデータが混ざらないようにした
• 複数社のグラフを重ねる計算は、ノード数に対してメモリがほぼ二乗で増える。研究の環境では起きなかったメモリ枯渇が、製品の検証環境で起きた。メモリの増強だけでは足りず、重い計算に入る前の上限と直列化の応急処置を入れた
• 応急処置は巻き添えを防ぐもので、計算そのものは軽くならない。待ち行列ができるというトレードオフも含めて関係者に伝え、根本対応（重い計算を別プロセスやバックエンドへ逃がす）は前提と工数を書いた別課題にした
• AI チャットは、LLM に自由にクエリを書かせる作りを避け、許可した道具の呼び出しに限った。データを書き換える経路を持たせず、表示の設定を変える道具にもサーバー側の入力検証を置いた

進め方

• 分析手法（コミュニティ検出、構造的空隙の分析、次元圧縮、密度マップ）と PoC の画面は研究チームの成果。自分の担当は、それを製品の画面体系・データモデル・権限・運用に載せること
• 移植先は顧客が実際に使っている画面系統か、レビューで前提を確かめてから作り直した。ワークスペース単位の表示制御、利用者ごとのデータ投入、ナレッジ DB を入力元にするバックエンドのモデルとマイグレーションまで通した
• 複数社のグラフを重ねる画面で、ノード数に対しメモリがほぼ二乗で増えて処理が落ちた。重い計算に入る前にノード数で弾く上限（Fail Fast）、重い計算の直列化とイベントループの明け渡しで、他の利用者が巻き込まれないようにした
• 応急処置で直ったのは巻き添えであって計算の重さではない、と区別した。重い計算を別プロセスやバックエンドへ逃がす根本対応は、工数と前提を書いた別課題に切り出し、データ量の制約は利用部門に数字で説明した
• グラフに対する AI チャットでは、LLM にクエリを書かせず、決められた道具だけを呼ばせた。読む道具は画面に渡したグラフの複製をメモリ上で読むだけ、書く道具は表示の設定を変えるだけでサーバー側のスキーマ検証を通し、呼び出し回数と時間・トークンにも上限を置いた