Back to Blog
ResearchMatch産学連携HonoQdrantOpenAlexベクトル検索技術選定

ResearchMatchを作った理由：日本の産学連携の課題とAIベクトル検索の技術選定

ResearchMatchを作った理由：日本の産学連携の課題とAIベクトル検索の技術選定

はじめに

2026年3月、産学連携支援ツール「ResearchMatch」のMVPをリリースしました。企業のニーズを自然言語で入力すると、AIがマッチする研究者を探し出すツールです。

なぜこれを作ったのか。技術的にどう設計したのか。日本の研究APIはなぜ使えなかったのか。この記事では、背景から技術選定まで詳しく書きます。

産学連携の現場で感じた課題

ある行政機関に在籍していた頃、国内の公的研究支援機関による若手研究者支援事業を担当しました。事業の委託先は大手シンクタンクで、産学連携のマッチングを支援する業務でした。

現場で繰り返し浮かんだのは、同じ問いです。

「どの研究者に声をかければよいか、誰も分からない。」

企業側の問題

中小企業や中堅企業が産学連携を検討するとき、最初の壁は「どの研究者と組めばよいか分からない」ことです。大学のホームページを見ても、研究室の紹介文は専門用語だらけで、自社の課題との接点が見えない。

キーワード検索しても、「製造品質管理 AI」と入力して「機械学習による異常検知」を研究している先生がヒットするとは限りません。言葉が違えば出会えない。

研究者側の問題

研究者側にも問題があります。企業からのニーズを知る機会が少ない。学会や論文の世界にいると、産業界の現場課題が届きにくい。「自分の研究が役立つかもしれない企業がある」という情報に出会えない。

仲介者（コーディネーター）の限界

大学にはURA（University Research Administrator）と呼ばれる産学連携コーディネーターがいます。しかし、一人のURAが数百人の研究者を把握しながら、企業ニーズとマッチングするのは現実的ではありません。

ResearchMatchが解決しようとしているのは、この「意味的な距離」を縮めることです。

日本の産学連携の構造的課題

規模感

日本の大学等の研究機関と民間企業の共同研究件数は年間約2万7000件（文部科学省「産学連携等実施状況調査」2022年度）。規模としては世界的にも決して小さくありませんが、一件あたりの受入額が低いという問題があります。

米国では産学連携1件あたりの平均額が数百万ドル規模になることもありますが、日本では多くが数十〜数百万円程度。「研究費の補助」として使われることが多く、本格的な共同開発には発展しにくい構造です。

なぜ規模が小さいのか

いくつかの理由が重なっています。

研究者側のインセンティブ設計の問題 日本の大学では、産学連携で得た収益の研究者本人への配分率が低い大学もまだ多い。「産学連携で忙しくするより、論文を書いた方が評価される」という構造が残っています。

企業側のリスク回避 大企業は産学連携をやっていますが、中小企業はリスクを取りにくい。「本当にうまくいくか分からない研究者に数百万円を投じるのは怖い」という心理は理解できます。

マッチング機能の欠如 そして最も大きな問題が、マッチング。「良い研究者がいても出会えない、良い課題を持つ企業がいても届かない」。ここにResearchMatchが切り込もうとしています。

事業機会

産学連携支援はビジネスチャンスとして有望です。

  • 政府の「知財・無形資産の投資・活用促進」政策
  • GX（グリーントランスフォーメーション）・DX推進における産学連携ニーズの増大
  • スタートアップ育成5か年計画でのディープテック企業支援
  • 大学の第4期中期目標・中期計画における産学連携強化方針

特に、AI・ロボティクス・材料科学・バイオなどの分野では、大学の基礎研究と企業の応用ニーズのギャップを埋めるプレイヤーへの需要が高まっています。

技術選定の背景

なぜベクトル検索なのか

従来のキーワード検索では、「製造品質管理」と入力しても「anomaly detection」や「異常検知」を研究している研究者はヒットしません。言葉の表層ではなく、意味の近さで検索する必要があります。

ベクトル検索（セマンティック検索）は、テキストを高次元のベクトル空間に変換し、コサイン類似度で近さを測ります。「製造品質管理 AI」というクエリが「machine learning anomaly detection in manufacturing」の研究者とマッチできるのは、意味が近いからです。

なぜHono（TypeScript）なのか

APIフレームワークとしてHonoを選びました。

Honoを選んだ理由：

観点 内容
軽量・高速 Cloudflare Workers/Denoなど多様なランタイムに対応。Node.js上でも非常に軽い
TypeScript-first 型安全なルーティングとリクエスト/レスポンス型定義
シンプルなAPI Expressライクな書き方ができ、学習コストが低い
エッジ対応 将来的にCloudflare Workersへの移行も視野に入る

Expressは枯れた技術ですが、TypeScriptとの相性は現代の標準から見るとやや古い設計です。Fastifyも候補でしたが、プラグインエコシステムの複雑さを避けたかった。Honoは必要最低限の機能を提供しつつ、型安全性が高い。

実際のエンドポイント定義はこのようになります：

const app = new Hono();

app.post('/search', async (c) => {
  const { query, limit = 5 } = await c.req.json();
  // ...
  return c.json({ matches });
});

シンプルさが際立ちます。

なぜQdrantなのか

ベクトルDBの選択肢は複数ありました。

ベクトルDB 特徴
Pinecone マネージドサービス。使いやすいが料金体系がやや高め
Weaviate 多機能。学習コストが高い
Chroma ローカル開発向け。本番運用にはやや不安
pgvector PostgreSQL拡張。既存DBと統合しやすい
Qdrant Rust製で高速。REST API完備。クラウド版の無料枠が十分

Qdrantを選んだ決め手は3点です。

  1. Rust製の高速処理: メモリ安全かつ高スループット
  2. REST APIの完備: TypeScriptからのアクセスが容易
  3. Qdrant Cloud無料枠: MVP段階では無料で十分な容量

ローカル開発はDockerで動かし、本番はQdrant Cloudに接続するという構成がスムーズでした。

# docker-compose.yml
services:
  qdrant:
    image: qdrant/qdrant
    ports:
      - "6333:6333"
    volumes:
      - ./qdrant_storage:/qdrant/storage

なぜOpenAI Embeddingなのか

Embeddingモデルの選択肢：

モデル 特徴
text-embedding-3-small OpenAI。安価（$0.02/1M tokens）、1536次元
text-embedding-3-large OpenAI。高精度、3072次元、やや高価
Cohere embed 多言語対応が良い
sentence-transformers ローカル実行可能。日本語モデルあり

text-embedding-3-smallを選んだ理由：

  • 日英混在テキストへの対応: 研究者の情報は英語論文abstractが多いが、クエリは日本語。多言語対応が重要
  • コスト: MVP段階では安価なモデルで十分
  • OpenAIのエコシステム: GPT-4o miniと同じAPIキーで管理できる

将来的に精度を上げたい場合はtext-embedding-3-largeへの切り替えや、日本語特化モデル（例：multilingual-e5）の検討も視野に入ります。

マッチング分析にGPT-4o miniを使った理由と、Claudeへの移行検討

MVPのマッチング分析（「なぜこの研究者があなたのニーズに合うのか」を自然言語で説明する機能）には、現在GPT-4o miniを採用しています。コストが低く、レスポンスが速いためです。

ただし、自然言語処理の品質という観点では、Claude（Anthropic）に優位性があると考えています。

観点 GPT-4o mini Claude (Haiku/Sonnet)
コスト 非常に安価 Haikuは同等、Sonnetはやや高め
レスポンス速度 速い Haikuは同等に速い
指示追従性 良好 非常に高い（プロンプト通りに出力しやすい）
日本語の自然さ 良好 非常に自然で読みやすい
長文の論理構造 良好 より一貫した構造を維持しやすい
ハルシネーション やや発生 比較的抑制されている

産学連携のマッチング分析は、「なぜこの研究者なのか」を説得力ある言葉で説明することが核心です。企業担当者がその理由を読んで「確かに、声をかけてみよう」と思えるかどうか。ここでは出力の自然さと説得力が直接ユーザー体験を左右します。

本番環境への移行・スケールアップのタイミングで、マッチング分析モデルをClaude Haiku（コストを抑えつつ品質向上）またはClaude Sonnet（より高品質な分析）に切り替えることを検討しています。

// 現在: GPT-4o mini
const completion = await openai.chat.completions.create({
  model: 'gpt-4o-mini',
  messages: [{ role: 'user', content: prompt }],
});

// 検討中: Claude Haiku
import Anthropic from '@anthropic-ai/sdk';
const anthropic = new Anthropic();
const message = await anthropic.messages.create({
  model: 'claude-haiku-4-5-20251001',
  max_tokens: 1024,
  messages: [{ role: 'user', content: prompt }],
});

このツール自体がClaude Code（Anthropic社のAI）を使って開発されており、Anthropicとの親和性は高い。APIの移行コストは低く、A/Bテストで比較検証しながら段階的に移行できます。

日本の研究APIはなぜ使えなかったか

これが開発の中で最も苦労した部分です。当初は日本の公的研究データベースを使う計画でした。

KAKEN（科学研究費助成事業データベース）

文部科学省・JSPSが管理する、科研費採択研究のデータベース。

問題点：

  • APIが存在するが、安定性が低くHTTP 500エラーが頻発
  • データ構造が古く、JSONの取り扱いが複雑
  • 研究者個人のプロフィールではなく「研究課題」単位のデータ構造

実際に試みたところ、エンドポイントへのリクエストが軒並みサーバーエラーで返ってきました。

GET https://kaken.nii.ac.jp/api/opensearch/?...
→ HTTP 500 Internal Server Error

researchmap

国内最大級の研究者データベース。文科省・JST管轄。

問題点：

  • API仕様が変更されており、ドキュメントが古い
  • 認証トークンの取得フローが複雑化
  • 個人情報保護の観点から、外部APIからのアクセス制限が強化されている

CiNii Research

国立情報学研究所が運営する学術論文・研究データのデータベース。

問題点：

  • 論文データは取得できるが、研究者プロフィールの直接取得が難しい
  • APIキーの申請が必要で、即座に利用開始できない

根本的な問題

日本の研究データベースが「使いにくい」理由には構造的な背景があります。

サイロ化の問題 KAKEN・researchmap・CiNiiはそれぞれ別の省庁・機関が管理しており、データが統合されていません。同じ研究者でも、データベースによって登録状況が異なります。

オープンデータへの消極性 欧米では研究データのオープン化が進んでいますが、日本では「個人情報保護」の名目でアクセス制限が強い傾向があります。研究者のプロフィール情報が公開情報であるにもかかわらず、API経由での一括取得が制限されています。

保守的なシステム運用 政府系システムのAPIは、更新頻度が低く、エラー時の対応が遅い。開発者向けのドキュメントや問い合わせ窓口も整備が不十分です。

なぜOpenAlexを採用したか

日本APIの壁にぶつかった末に辿り着いたのがOpenAlexです。

OpenAlexとは

OpenAlexは、2022年にMAG（Microsoft Academic Graph）の後継として設立された、完全無料・オープンな学術データベースです。

  • 規模: 約2億5000万件の研究論文、約3000万人の研究者
  • 無料: APIキー不要で利用可能（一定レート制限あり）
  • オープンライセンス: CC0（パブリックドメイン）
  • 更新頻度: 週次更新

日本の研究者データの質

OpenAlexには日本の大学・研究機関に所属する研究者が大量に収録されています。特に国際論文を多数持つ研究者は網羅性が高い。

// 東京大学の研究者をOpenAlexから取得
const res = await fetch(
  'https://api.openalex.org/authors?' +
  'filter=last_known_institutions.country_code:JP,' +
  'last_known_institutions.type:education&' +
  'sort=cited_by_count:desc&' +
  'per-page=200'
);

制約と将来的な補完

ただし、OpenAlexには課題もあります。

  • 国内論文の網羅性: 日本語論文（CiNii収録）は収録率が低い
  • 研究者の自己更新なし: 研究者自身がプロフィールを更新する仕組みではない
  • 特定分野への偏り: 国際誌への投稿が多い分野（工学・医学）は充実しているが、人文社会系は弱い

将来的には、researchmapやJ-GLOBALとのデータ統合も検討の余地があります。

アーキテクチャ全体像

企業担当者
    ↓ 自然言語でニーズ入力
[Next.js フロントエンド]
    ↓ POST /search
[Hono API on Railway]
    ↓ text-embedding-3-small
[OpenAI Embedding API]
    ↓ 1536次元ベクトル
[Qdrant Cloud]
    ↑ Top-K コサイン類似度検索
[GPT-4o mini]
    ↓ マッチング理由を自然言語生成
[フロントエンドに返却]
    ↓
研究者カード表示（スコア + マッチング分析）

データ投入フロー：

OpenAlex API → fetch-openalex.ts → 研究者データJSON
    ↓
ingest.ts → OpenAI Embedding → Qdrant に upsert

今後の展望

データ拡充

現在のMVPデータは機械学習・ロボティクス・材料科学を中心とした数百件のサンプルです。今後：

  • 分野を医学・バイオ・農業・社会科学に拡大
  • researchmapとのデータ統合検討
  • 研究者の更新情報を定期的に再取得

機能拡張

  • 研究者の詳細プロフィールページ
  • 企業側の課題登録とマッチング履歴管理
  • 大学URAや産学連携コーディネーター向け管理画面

ビジネスモデルの可能性

ResearchMatchは現在無料のMVPですが、事業化するとすれば：

  • SaaS型: 企業向けの産学連携CRM。月額課金
  • 成果報酬型: マッチング成立時に手数料
  • 大学・TLO向けB2B: 大学の産学連携担当部署に対してホワイトラベル提供

産学連携のマッチング市場は、TLO（技術移転機関）やJ-Innovation HUBなどの既存プレイヤーが存在しますが、AIによるセマンティック検索を本格活用しているプレイヤーはまだ少ない。

まとめ

ResearchMatchは、行政機関での産学連携業務で感じた「意味の距離を縮められない」という問題意識から生まれました。

技術選定の核心は「日本語と英語の混在を意味レベルで扱えるか」という問いです。キーワードではなくEmbeddingで、Qdrantのベクトル検索で、LLMのマッチング分析で——それに答えようとしています。

マッチング分析のLLMはMVPではGPT-4o miniを採用していますが、自然言語処理の品質・説得力という観点でClaudeが優位であると評価しており、本番スケールへの移行タイミングでClaude Haikuまたはclaude-sonnet-4-6への切り替えを検討しています。

日本の研究APIの閉鎖性は課題ですが、OpenAlexというグローバルな代替手段が存在することは救いです。むしろ、国際的なデータベースを使うことで、日本の研究者の国際的な発信力も可視化できます。

産学連携のデジタル化・AI化は、政策的にも事業的にも、これから加速する領域だと考えています。ResearchMatchはその一つの実験です。

→ ResearchMatch を試す

Share:
View all posts