＼MCPサーバー誕生秘話をXにシェア！／

シェアはこちら

2025年4月、LAPRASでは公式MCPサーバーをリリースしました。これによってLAPRASで新たにどんなことができるようになったのか、今後LAPRASはどんな方向性を目指していくのか、MCPサーバー誕生の背景を開発者に尋ねたインタビューの内容をお届けします！

Ryo Kawamataさんのポートフォリオはこちら：https://lapras.com/public/kawamataryo

公式MCPサーバーで高まるLAPRASの利便性

―今回開発した「LAPRAS公式MCPサーバー」について簡単に教えて下さい。

Kawamataさん
MCP（Model Context Protocol）はLLM（大規模言語モデル）とSaaSなどのサービス、またはデータと通信するためのプロトコルです。CursorやClaude DesktopなどのLLMと、LAPRASのサービス・データを繋げるために必要なもので、その橋渡しをおこなうサーバーを今回作りました。

―MCPサーバーの公開で、LAPRASで新たにどんな事ができるようになりましたか。

Kawamataさん
これまでLAPRASは、LAPRASのサービス上でしか操作をすることができませんでした。たとえば、登録ユーザーの方々が職務経歴書を作成・更新するときに「どこか別のところからコピーして貼り付ける」という作業を行うとします。これまでのLAPRASでは、サービス上で手作業で貼り付けを行うしかありませんでした。

同様に、新しく求人を検索するときも「LAPRASのサービス上で検索する」という方法しかできませんでした。MCPサーバーを使うと、たとえば「求人検索をClaude Desktop上で行う」といったこともできるようになります。「TypeScriptの、年収800万円以上の求人を探して」といったプロンプトを入力すると、LLMがLAPRASの求人を検索し、条件に当てはまるものを抽出して出力してくれます。

わざわざクエリを書く必要もありませんし、出力の形も自由に選べます。必要性に応じて表やリストなど、ユーザーにとって好ましい形で出力できます。

今お伝えした「求人検索」のほか、「求人詳細の取得」、「職歴・職務要約・やりたいことの取得・更新」などもLLMを使ってできるようになりました。

職歴や職務要約を利用した活用法だと、次のようなものが考えられます。「他のサービスに登録している職務経歴書の情報を手作業でLAPRASに移すのが面倒」という場合、まずその職務経歴書をスクリーンショットで撮影します。それをLLMに貼り付けて「これを元にLAPRASの職歴情報を更新してください」と入力すれば、構造化されていないデータでも職歴情報を更新してくれます。

LLMを窓口として「LAPRASを利用してやりたいことがさらにやりやすくなった」と考えるとわかりやすいかもしれません。

―MCPサーバーによって、ユーザーの転職体験にも変化が生じるのでしょうか。

Kawamataさん
基本的には変わりませんが、LAPRASが考える「エンジニアの方々と企業、双方にとっての良いマッチング」が生まれるきっかけや、そのための選択肢が増えると考えています。

たとえば、職歴情報の更新が手軽になったことで、これまであまり更新できていなかった人も、こまめに更新するのが容易になります。企業側の目線でみると、これまで出会えなかった魅力的な候補者と出会う機会が増えることにもつながります。

また、今までできなかったような求人の探し方もできるようになります。たとえば「自分の職歴情報を元に、自分に合う求人を探して」というプロンプトを入力すれば、LLMが自分の職歴情報を取得し、それを元にマッチする求人を探して出力してくれます。LLMに、簡易的なキャリアコンサルタントのような役割をさせる使い方ですね。自分で検索条件を指定していたときには見つからなかった求人が見つかる可能性もあります。

変化の激しい領域で意識した「開発のスピード感」

―今回の開発にはどういった経緯で取り組まれたのでしょうか？

Kawamataさん
SNSなど、ちょうどエンジニア界隈でもMCPサーバーが流行っていたのですが、「LAPRASでも、それを使ってなにか面白いことができないか」と考えたことがきっかけですね。

個人的に、職務経歴書を手で入力するのが苦手だったということも理由にありました。LLMがちょうどそうした作業を簡略化するのに適していた、というのもありますね。私自身、LAPRAS以外にもGitHubなど複数のサービスで職歴情報を管理していますが、LLMがうまく活用できれば、それらの同期もしやすくなるのではないかとも考えました。

―LAPRASのユーザーからは「この作業を簡略化したい」といったリクエストはありましたか。

Kawamataさん
ユーザーの方々からは「職務経歴書をエクスポートしたい」という声はときどきいただいていました。「PDFなどで職歴の提出を求められた場合に、手間を掛けず速やかに出力したい」といったニーズですね。そうした、これまでの開発の中でまだ十分に拾えていなかった「ユーザーの方々の細かいニーズ」も今回のMCPサーバーの開発によってまとめて解決できるのではないかと考えて開発に着手しました。

―開発をスタートする段階で意識したことや、目標にしたことはありますか。

Kawamataさん
「スピードを優先して出す」というのは意識していました。MCPなど、AI関連の開発は非常に流行り廃りの変化が激しい領域です。モデル自体の変化も激しいですし、先週までベストプラクティスとされていたことが、今週にはもう時代遅れになってしまうこともある世界なので「MCPについてもそれが起こりうるのではないか」と考えていました。

「今、盛り上がっているタイミングでリリースしないと使ってもらえない」というリスクもあったので「機能は限定的でも良いので、まずは早くリリースする」という点を意識していました。

―スピードを優先する中でどのように開発の優先度をつけていきましたか。

Kawamataさん
最初に、3営業日程度の開発で求人検索機能のみをリリースし、その1週間後くらいに職歴情報の取得・更新機能をリリースする、という順番で進めていきました。

優先度を決めるポイントになったのは「個人を特定する必要があるか」です。職歴情報の取得・更新は、対象となる個人を特定する必要があり、API側の開発にも時間が必要でした。一方、LAPRASの求人情報は元々、サービスにログインしていない状態でもオープンに見られる状態になっています。そのため、先に求人検索機能、次に職歴情報の取得・更新、という流れになりました。

―開発の中で特に難しかったところや、苦労したポイントはありますか？

Kawamataさん
いかにLLMに「意図したところをやってもらうか」「安定した動作を実現するか」という点ですね。

たとえば、職務経歴書の取得・更新では「元々3つの職務経歴書が書いてある」という場合に、LLMが「3つのうちひとつだけを更新し、残る2つを削除する」という出力になってしまうこともありました。これはQAの段階で試行錯誤して対処できたのですが、苦労したポイントのひとつですね。

当初は「渡されたデータをそのまま使い、ひとつのAPIで削除・更新・追加をする」という設計になっていました。しかし、そのやり方ではLLMの出力が安定しなかったため、元々ひとつのAPIでやっていたことを3つにわけることで解消できました。

―ユーザーに満足してもらえるよう、工夫したポイントはありますか？

Kawamataさん
初めて知って利用する際の「とっつきやすさ」や「興味を持ってもらえるようにしよう」という点は意識していましたね。たとえば、リリース時の告知にデモ動画を貼ったり、リポジトリのREADMEに「こういうプロンプトを入れたらこういう出力が出るよ」というサンプルをセットで貼ったりしていました。使ってもらいやすいよう、ドキュメントを整備するなどの工夫はしていました。

LAPRASユーザーからは予想以上の好評をいただけた

―リリース後の反響はいかがでしたか？

Kawamataさん
予想していた以上に大きな反響がありました。私のように職務経歴書の更新が苦手な方から「こんなに簡単にできるならやってみよう」という声も届きました。リリースしてから現在（2025/06）までの段階で、100名以上の方に使っていただいています。

元々は、エンジニア業界の中に「LAPRASがAIを利用したプロダクト開発に積極的である」という認知を広げていくことが主な目的でした。そうした中で想定していたよりも多くのユーザーの方に使っていただいているのはとてもうれしいです。

―ユーザーの反応以外でも、対外的なインパクトはあったのでしょうか。

Kawamataさん
MCP関連での登壇の依頼も多くいただけるようになりました。オフラインで100～200人集まるような規模のイベントでも登壇の依頼が来ているので十分な効果があったと考えています。

当初の目的であった業界内でのプレゼンス拡大も達成できましたし、その上で予想以上にユーザーの皆さんから好評をいただいたという点もありがたいですね。

リモートMCPサーバーやさらなる他機能への挑戦

―MCPサーバーに限らず、今後のAI活用でチャレンジしていきたいことはありますか。

Kawamataさん
ひとつは「リモートMCPサーバー」への切り替えです。今、LAPRASのMCPサーバーはローカル環境で動いているのですが、将来的にはこれを「リモートMCPサーバー」に切り替えていきたいと考えています。ローカルだとDockerのセットアップなど動かすまでの設定が大変なのですが、リモートに切り替えることでそうした手間を簡略化できるからです。

また、将来的にはモバイルでの利用なども視野に入れて取り組みを検討していきたいです。

もうひとつは、できることをさらに増やしていくことです。

GitHubやZennなどと連携している「LAPRASポートフォリオのデータ」もMCPサーバーで取得できるようにしていきたいです。そうすれば、Claude Desktopなどを使って「自分だけのポートフォリオサイトを作る」といった活用の仕方も考えられます。

さらに、LAPRASユーザーと企業がやり取りする「メッセージ機能」や「興味通知機能」にもMCPサーバーを活用できる領域があるのではないかと考えています。まだそこまで具体的なアイデアではありませんが、たとえば自分のGoogleカレンダーをMCPサーバーと連携し、面談日程の調整を行うとか。多くの企業とやり取りしている場合に、個々の企業とのやり取りをMCPサーバーを使って整理してもらうとか、ユーザーの皆さんが企業とのやり取りをスムーズに進められる機能を提供していきたいです。

機密性・安全性が担保された使いやすいサービスを目指して

―AIを活用したプロダクト開発に取り組む上で、意識していることや大切にしている価値観はありますか？

Kawamataさん
エンジニアなら誰でも気にする点かもしれませんが、「データの機密性」ですね。「このデータをAIに与えた場合、それがどこで使われるかわからない」といった懸念が生じるようだと安心して使うことはできません。AIを活用していく上で、そうした機密情報の取り扱いについては今後も意識していきたいです。やはり機械学習に使われてしまっては良くないデータもあるので、AI側をうまくハンドリングして「データは与えるが、安全に使えるようにする」という点が重要です。

ユーザーに提供する機能としても「安全に使えるかどうか」という点は大切なポイントです。先に述べた「入力した職歴情報が消されてしまった」といった挙動が生じるようだと、ユーザーの皆さんに安心して使ってもらうのは難しいです。ユーザーが誤った操作をしてしまったり、LLMが意図しない出力をしたとしても元のデータが守られ、安全に復旧できるようにしていく必要があります。

LLMは柔軟で、何でもできるツールです。しかし、だからこそ想定外の事態が生じる怖さもあるのでそこをどうハンドリングしていくかは考えています。

今回のMCPサーバーの開発では、最新ではない古いモデルのLLMを使った場合に出力がブレる、ということもありました。そうした場合でもちゃんと動くかどうかの検証はしっかりやっていかなければと、思いました。

また、AIに対するリテラシーも人によって様々なので、MCPサーバーを利用する人が常にAIに詳しいとは限りません。MCPサーバーを利用して出力されたデータにおかしい点があったときに、AIに詳しい人であれば「利用したLLMのモデルに原因があるかも」と考えたり、「違うモデルを選択したら結果が変わるのではないか」といった仮説も立てられます。

しかし、そうした知見がない人が使用した場合だと「MCPサーバー自体に問題があるのでは」といったイメージを持たれてしまう可能性もあります。ですので、利用者のリテラシーも考慮したうえで、どんな機能を提供するのか決めていく必要があると考えています。

―最後にLAPRASを利用されているエンジニアの方々へメッセージをお願いします。

Kawamataさん
LAPRASとしては今後もAIを活用した便利な機能や、新しい体験を提供していこうと考えています。ユーザーの皆さんからも引き続き、応援していただけると嬉しいです！

ーー ありがとうございました。

＼ぜひリポストしてください！／

LAPRASを使ってみませんか

LAPRASは、 Web上のアウトプットが自動で分析、まとまっていく ポートフォリオ&転職サービス です。
クローリング技術によって、 面倒な入力なし で 技術情報や志向性が客観的に分析 され、内容は常に最新にアップデートされていきます。
プロフィール情報をもとに、国内のスタートアップ、自社開発企業など、あなたのスキルや志向性に関心を持った企業からスカウトを受け取ることができます。また、LAPRASポートフォリオをつかって 求人に応募することも可能 です。
登録はSNS連携で簡単 に始められます。ぜひご登録ください。

LAPRASポートフォリオはこちらから