技術選定の話をしたい。

ただし、これは「流行りのフレームワークを比較してみた」という記事ではない。
解こうとしている問題の構造から逆算して、なぜこのスタックに辿り着いたのかを書く。そして正直に、今どこまでできていて、何がまだ解けていないのかも書く。

問題の構造

企業のデータは、CRM、ERP、Slack、メール、スプレッドシートに分散している。
それぞれ「事実」としては存在するが、「意味」としては繋がっていない。
KPIの定義が部門ごとに違い、意思決定のたびに「この数字、何を指してるんだっけ」という会話が繰り返される。

アルバコネクトが構築しているのは、
この「意味の断絶」を構造的に解消するインフラだ。

このインフラを設計するとき、技術スタックには3つの要件が課される。

要件1：事実・意図・因果をまたげるデータ基盤が要る

一般的なCRMやデータベースは事実を格納する。顧客名、売上額、商談ステータス。

アルバコネクトが扱うのは、事実の裏にあるレイヤーだ。「なぜその取引が発生したのか」「この意思決定は何に基づいていたのか」「過去の類似ケースでは何が起きたのか」。
事実、意図、因果、学習——これらを横断的にクエリできる基盤が要る。

RDBだけでも、ベクトルDBだけでも足りない。
類似性に基づく検索（「この会社と似た課題を持つ企業はどこか」）と、構造的なリレーション（「この判断がどの結果に繋がったか」）を同一の基盤で扱う必要がある。

要件2：単一ボットではなく、階層型エージェントを前提にする

作っているのは、1つの万能チャットボットではない。

企業データをクエリ可能な意味表現に変換し、意思決定を支援するには、役割の異なる複数のエージェントが協調して動く必要がある。

個別のツール群。文脈に応じてそれらを選択・合成するルーティング層。全体のワークフローを統合するオーケストレーション層。

後からツールやエージェントが増えても骨格が壊れない、拡張に強い階層設計が要る。

要件3：既存SaaSとの接続を前提にする

企業のデータは、すでにSalesforce、HubSpot、Slack、Gmail、Google Calendarなどに散らばっている。これらを置き換えるのではなく、接続して意味構造に変換するのが僕たちの仕事だ。

各SaaSとの接続層を抽象化し、API仕様の変更が起きても影響が局所化される構造にする。

今の技術選定

フロントエンド：Next.js + React + TypeScript

エージェントの推薦結果を、ユーザーがリアルタイムで確認し、承認・修正・却下できるインターフェースが必要だ。SSEでストリーミングしながら、複雑な状態管理を型安全に扱う。Next.jsのApp Routerで、APIルートとUIを同一プロジェクトに収め、ミドルウェアで認証・RBAC・IP制限を一元制御している。

バックエンド / エージェント基盤：Python + FastAPI + LangGraph

FastAPIを選んだ最大の理由はPython AIエコシステムとの自然な接続だ。LangChain、PyTorch、scikit-learn——エージェントとデータパイプラインの領域ではPythonが事実上の標準になっている。非同期I/O、Pydanticベースの型安全な開発体験、API設計の明快さも選定理由に入っている。MCP（Model Context Protocol）との統合性も利点の一つだが、エコシステム自体がまだ変化が速いため、補助的な位置づけだ。

エージェントの階層設計にはLangGraphを採用している。状態遷移を有向グラフとして定義でき、ワークフローの分岐・合流・条件付きルーティングを宣言的に書ける。

データベース：PostgreSQL + pgvector（Supabase）

類似性に基づく検索にはpgvectorを使い、OpenAIのtext-embedding-3-smallでベクトル化。意思決定ログや因果関係はリレーショナルに管理する。トランザクションの整合性が重要だからだ。

Pinecone、Weaviateなど専用ベクトルDBも検討したが、現フェーズでは、データ量・運用人数・マルチテナント要件を踏まえると、PostgreSQL + pgvectorが最もシンプルで可逆性が高い。データ量が桁を変えるフェーズでは再検討する。不可逆な判断ではないからこそ、今はシンプルな方を選んでいる。

Supabaseを採用した理由は、Auth・RLS（Row Level Security）・リアルタイム同期が標準装備されている点だ。

データパイプライン：Python + スクレイピング基盤

Web上の企業情報、ニュース、求人動向、SNS活動を取得し、エンティティとリレーションに分解してデータ基盤に格納する。派手ではないが、上位レイヤーの品質をほぼ決めるレイヤーだ。

選ばなかったもの

TiDB — 分散SQLでベクトル検索もサポートする。水平スケーリングは魅力だが、現フェーズではSupabaseのエコシステムの充実度と立ち上がり速度を優先した。

Node.js / Denoバックエンド — TypeScript統一の魅力は理解しているが、AIエージェント・データパイプライン領域のPythonエコシステムの厚みには代えられない。二言語の運用コストを受け入れてでも、ここはPythonを選ぶべきだと結論した。

CrewAI / AutoGen/ Mastra— 上位抽象を提供するフレームワークは有力な選択肢だと思っている。特に初期開発の速度や運用機能の揃い方には強みがある。
ただ、現フェーズでは、意味レイヤーとオーケストレーション境界を自分たちで明示的に設計したかったため、より制御しやすい構成を採用した。
ここは固定ではなく、今後も見直す前提だ。

今いちばん難しい技術課題

ここからが、エンジニアに一番伝えたい部分だ。
僕たちが実際に頭を抱えている問題を書く。

1. 意味スキーマの進化と後方互換性

企業データを意味構造に変換するとき、スキーマが要る。だが最初の定義が正しいとは限らない。顧客業務の理解が深まるにつれてスキーマは進化する。
過去に格納したデータとの互換性をどう保つか。まだきれいな解がない。

2. 非構造データの抽出品質をどう測るか

Slackのメッセージやメールから意図を抽出する精度を、どう定量評価するか。
human evaluationはコストが高く、自動評価だけでは信頼できない。
この評価パイプラインの設計が今のボトルネックの一つだ。

3. ルールベース層とLLM推論層の境界設計

ワークフローの中で「LLMに任せていい判断」と「ルールベースで確定させるべき判断」の線をどこに引くか。リードスコアリングは今ルールベースで書いている。
LLMに推論させた方が精度は上がるかもしれないが、説明責任と再現性が失われる。
この二つの共存パターンがまだ確立されていない。

4. ツール爆発を防ぐルーティング設計

エージェントに使わせるツールが増えると選択精度が下がる。
10個から最適解を選ぶのと50個から選ぶのでは難易度が全く違う。
ルーティング層で事前にフィルタする設計にしているが、カテゴリの粒度設計に明確な指針がない。

5. human feedbackの学習ループ

エージェントの推薦をユーザーが承認・修正・却下した判断を、どうシステムに反映するか。現状はログとして記録しているが、改善に繋げるループがまだ弱い。
将来的には強化学習ベースのアプローチも視野に入れているが、現時点では評価データの蓄積とスコアリングモデルの改善に集中している。

6. SaaS間のデータモデル差分

SalesforceとHubSpotでは、商談のステータス遷移一つとっても表現方法が異なる。接続層で差分を吸収しつつ、意味レイヤーでは統一的に扱う。
言うのは簡単だが、実装するとエッジケースの山になる。

今できていること / これから解くこと

すでに稼働しているもの：

• Next.js / FastAPI / PostgreSQL + pgvectorの基盤
• スクレイピング → 意味構造化 → 格納のパイプライン
• エージェントオーケストレーションの初期版
• 受託プロジェクトの中での、実企業データに対する検証

これから解くもの：

• スキーマ進化戦略と移行パス
• 抽出品質の評価パイプライン
• エージェント階層の拡張とルーティング最適化
• human feedbackを使った推薦精度の改善ループ
• データ量増加に伴う基盤のスケール再設計

こういうエンジニアを探している

• 企業データの構造的な断絶を、システム設計の問題として捉えられる人
• LLMに何を任せて何を任せないか、その境界設計に関心がある人
• スクレイピングから意味構造化、ベクトル化、エージェント設計まで、パイプライン全体を見渡せる人
• 「動くものを作る」だけでなく「正しく評価する」仕組みにも関心がある人

問題はまだ初期段階にあり、アーキテクチャは進化の途上にある。だからこそ、このポジションで関われる設計判断の幅は広い。

単にLLMを組み込むのではなく、企業データが知的システムにとって"読める"状態を設計する。その仕事に興味があれば、ぜひ話したい。

株式会社アルバコネクト 代表取締役 作田マルコ聡