動機
LLMはシステム内の環境とどのように相互作用するのでしょうか？そうではありません。呼び出しと応答のAPIです。エージェントという言葉はよく耳にしますが、環境を監視または操作できるツールにアクセスできないエージェントは、私たちが重視するような有意義なタスクの実行に根本的に限界があるように思います。
新しい流行語を目にする最初の10回は、できるだけその雑音を無視しようと努めますが、 **Model Context Protocol（MCP）**が何度も現れてからは、その意味を深く理解するようになりました。ツールやリソースの存在とその使い方を宣伝するための一貫したフォーマットを提供することで、MCPは問題を巧みに解決します。LLMからツールやデータベースへの新しいコネクタを構築する必要がある場合、構築済みのオープンソースのMCPサーバーを見つけて、それを導入するだけで済みます。MCPには、業界の主要企業であるAnthropicという企業スポンサーがメンテナンスを担当しており、初日からドッグフード（ドッグフェッド？）され、長く使い続けられるように構築されています。
Related MCP server: Zaturn
計画
実際の問題を解決することで新しいことを独学で学ぶのが好きです。そうすることで、結果がより記憶に残りやすくなります。検索拡張生成（RAG）に関する研究を数多く行っており、その多くはオープンソース化に向けて準備を進めています。MCPはRAGアーキテクチャの次の進化形だと考えています。近い将来、RAGをうまく活用する人は、MCPをベースにしていると思います。
今後1、2年の間に市場の調整局面が訪れると予想し、最近は不動産投資について学んでいます。Zillowの無料データをデータベースに読み込み、MCPサーバーを稼働させようと考えています。そして、MCPサーバーに接続し、HTML UIからのリクエストを処理するFastAPIサーバーを稼働させようと考えています。最終的な目標は、この不動産データを分析し、どの市場で取引を探すべきかを判断するのに役立つチャットボットを開発することです。
ロードするデータには次のものが含まれます。
Zillow 住宅価値指数 (ZHVI) –特定の地域および住宅タイプにおける、65 ～ 95 パーセンタイル以内の典型的な住宅価値の尺度。
Zillow 住宅価値予測 (ZHVF) –現在および過去の市場データに基づいた住宅価値の動向の将来予測。
Zillow 観測賃料指数 (ZORI) –現在および市場外の賃貸物件リスト全体で観測された典型的な市場賃料の平滑化された尺度。
Zillow 観測賃料予測 (ZORF) – ZORI と市場指標の傾向に基づいて予測される賃料価格の変化。
私が ZHVI データを除外していることにお気づきかもしれませんが、これはデータ不足によるもので、ZHVI の追跡は最近になって始まったばかりです。
これは非常にドメイン固有のデータです。定義を読まずにデータについて推測することは望ましくありません。そのため、LLM では単純な問題セットを直感的に理解することはできないため、これは素晴らしい例になると思います。
法学修士（LLM）に、手頃な価格の住宅とキャッシュフローのある家賃のバランスが取れていて、将来の成長率が高いと予測される市場を見つける手伝いをお願いしたいと思っています。これらの予測成長率を鵜呑みにするつもりはありません。少しプログラミングをして、どのくらいの頻度で、どの地域で予測が正しい傾向があるかを確認しましょう。様々なクエリを作成するには、かなりのプロンプトエンジニアリングが必要になると予想しています。そうすれば、これらのプロンプトをMCPプロンプトとして保存し、チャットボットに提案してデータベースに実行できるようになります。
データベースにはSQLiteを選択しました。メモリをローカルファイルに保存するため、データベースの再読み込みや起動・停止の手間がかからないからです。移植性を考慮してデータベースはコンテナ内で実行します。データベースの状態をファイルに保持しておくことで、必要に応じて「キャッシュされた」データロードとして扱うことができます。こうすることで、ローカルボリュームにマウントすれば、コンテナを再起動するたびにZillowデータをデータベースに再読み込みする必要がなくなります。
このデータと通信できるようにするには、先ほど作成したテーブルに対してクエリを実行できるようなMCPサーバーを作成する必要があることは分かっています。これまで読んだ内容から判断すると、MCPクライアントの背後にあるLLMに提示するMCPプロンプトまたはツールとして、有用なクエリをエンコードしたいと思っていますが、実際にはまだ具体的にどのようなものになるのかは分かりません。まずは、langchainのドキュメントと、私が読んできた他の資料をいくつか組み合わせて、構築用のスターターサーバーを構築しています。その後、MCPクライアントの初期段階では、 Anthropicのドキュメントをほぼ参考にしましたが、Anthropicのコードの大部分をlanggraph ReActエージェントに置き換えました。その後、クライアントとサーバーを相互に通信させる方法が分からなかったので、MCPに組み込まれている様々なトランスポート方法について説明している、非常に優れたMCPドキュメントを見つけました。私はデフォルトの方法、つまりstdioを使用してクライアントとサーバー間でインプロセスでメッセージを渡す方法を採用することにしました。これはローカルデータベースとアプリのバックエンドを内蔵する単一のコンテナなので、理にかなっていると言えるでしょう。しかし、本番環境ではMCPサーバーとバックエンドが分離されることになるので、より複雑なHTTPストリーミング設定が必要になるでしょう。この点については、仕事でこのようなものを構築する必要があるときに検討することにします。
今のところ、これは単一のメッセージ生成のために実行している単一のスクリプトです。これを実用的なものにするには、ユーザーからのクエリを受け取り、これらの関数に渡すWebサーバーを接続する必要があります。Webサーバーを実用的なものにするには、サーバーにリクエストを送信するためのチャットインターフェースのようなフロントエンドが必要です。Streamlitは最近、このようなAIプロジェクトで大流行しており、以前のプロジェクトや社内ツールでも試してみましたが、遅いReactコードを遅いPythonコードで実行し、Python用に別途サーバーコードをデプロイする必要があるのは、軽量なフロントエンドを構築する最良の方法ではないという結論に達しました。概念実証が承認された後に、それを本格的な本番環境レベルのものに書き直したい人はいないので、多くの場合、そうはいかないようです。私はReactをかなり書いてきたので、ここでPythonの仲介者を排除できるのですが、やり過ぎな気がします。フルスタックの何かを作るたびに、本来学ぼうと思っていたよりも多くのフロントエンド開発をしてしまうことになります。 HTMXはしばらく前から気になっていたのですが、今回のプロジェクトで試してみることにしました。驚くほど軽量で、チャットアプリのようなロジックの少ないフロントエンドに必要な最小限の機能しか提供してくれません。それに、ミームも素晴らしいです。サーバーの選択に影響するのは、テンプレート化されたHTMLを返す必要があることだけです。そこで、Jinjaを使ってWebページをテンプレート化し、HTMXスクリプトタグを付けて送信することにしました。本当にこれだけで実行できるんです。素晴らしいです。
Echoサーバー自体はそれほど面白いものではないので、LLMエージェントをプラグインしてみましょう。MCPクライアントをFastAPIサーバーのライフスパンに追加し、アプリの状態にバインドすることで、スレッドセーフな方法でワーカーに渡せるようにしました。クライアント/サーバーがプーリングで構築されているわけではありません。エージェントにメッセージを渡し、出力を短いHTMLにフォーマットして、UIに返すだけです。