FastAPIでちょっとした業務効率化！MCPも少し勉強中。

はじめに

本記事は全然大したことない記事です苦笑、もっと良い方法あるじゃんって意見が聞こえてきても当たり前の記事ですが残しておきます。いわゆる雑魚DXの部類です。
また、私はいわゆる生粋のITエンジニアではありません。ただし、MLコンペや社内AWS DeepRacerコンペの優勝経験、AI系資格の取得、各松尾研リスキル修了、RAG/AIエージェント構築とチューニング歴が3年目、プロマネ、とアプリケーション寄りの部分は比較的経験豊富です。特に現場でリアルに使えるRAGシステムの構築経験は10件程度はあり、過去にも様々なITエンジニアやビッグテックとの協業も経験しましたが、ココの技術だけは彼らと比べてもそこそこ自信があります。とカッコいいことを書いてきた一方で、インフラやバッグエンドの流行には残念ながら大変疎いです。特に最近AIエージェントが注目される中、MCPという技術が有名になってきたと思います。MCPを構築する上ではやはりその手前のFastAPIを理解しようということと、今回とある問題の解決に向けて着手しました。

現場で起きた問題

まず前提として、クラウド移行する前の事前検証として、ローカルでとあるAIエージェントの動作確認や精度検証を行っていました。私のチームではクラウド移行時に社内ゲートを通すために、ローカルで事前検証することが多いです。そこで、とある問題が起きました。
AIエージェントがRAG検索をするときに検索モデルを実行します。私のチームで開発した検索モデル(=Retriever)はNVIDIAのGPUリソースを使う（※いわゆるCUDA）のですが、ほとんどのエンジニアがGPUレスのノートパソコンしか持っていないため、エージェントがRAG検索するときにE2Eでかなり時間を要してしまう、という問題がありました。IT業界であれば、リテラシーのある方が高性能なノートパソコンを配るのですが、いわゆるIT業界以外ではRAM 8GB程度の冗談みたいな低スペックPCが配られることもしばしば。。残念ながら、開発エンジニアがストレスなく動作させるには課題だらけでした。ただし、私だけはノートパソコン以外にNVIDIA GPU付のデスクトップPCを持っていたのです。

FastAPIでやりたいこと

ローカルでGPUリソースを共有しつつ、RAG検索モデルAPIをたたいて、みんなでストレスなく開発したい。つまり、下記のように私が持っているデスクトップPCをサーバー化し、カスタムされたAPIを開発エンジニアに叩いてもらうという構成です。

初めてFastAPIを組んでみた

最小限の構成を下記に示します。

サーバーサイド

from fastapi import FastAPI

app = FastAPI(title="My API", version="1.0.0")

@app.get("/") # Getリクエストでアクセスしたときの処理を記述
async def root():
    """ルートエンドポイント"""
    return {"message": "Hello World"}　# 実際にはRAGのメソッドをここに入れています

# サーバー起動
if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

実際にクライアントからの動作が成功するとサーバーログが残ります。

クライアントサイド

import requests

# エンドポイント
url = "http://localhost:8000/"

response = requests.get(url)

# レスポンス内容を表示
print("Status Code:", response.status_code)
print("Response Body:", response.json())

サーバーへのアクセスが成功すると、下記のように戻り値が返ってきます。

業務効率化の達成度！

実際にほかのPCからGPUリソースをもつPCへアクセスしてもらいましたが、やはりGPU性能がすばらしく時間はなんと50％削減。エージェント等では何回もAPIをたたくだけでなく、デバッグ中は下手すると100回以上叩くのでリアルな数字として効率化できることを見出しました（笑）FastAPIの活用方法として計算リソース共有面でも活用できそうだ、ということを今回理解しました。
約4秒→約8秒。実際はローカルで動作すると10秒以上かかることが多いのでかなりの時短です。

FastAPIを使ってわかったこと

良いポイント

Pythonコードとの相性が抜群によく、元々クラス化されていれば非常に簡単に組むことができ、スピード重視でのAPI導入が可能。ローカルでないと動かせないようなシミュレーションソフトなどのCICDなどでも使えそうだなと感じました。やはりAPIの場合、APIの完成度が高ければ、開発者はAPIサイドの機能を気にせずに開発できるので、改めて非常に良い使い勝手だと感じました。

課題になりそうなポイント

そのままだと通信がhttpであることや、認証機能が今の作りだともちろんないので、URL知っていればアクセスできてしまう＆のぞき見できてしまうので、実装が今後必要だなと思いました。APIキーの実装などはかなり容易にできるので、そこは良いポイントですね。実際の本番運用等では、FastAPIはhttp通信が推奨？のようなので、フロントエンドなどで認証等を行い、その認証キーをFastAPIに引数として渡して～のような仕組みになるのでしょうか。

今後の発展とMCPに向けて

FastAPI→MCPサーバーへマウントしてくれるライブラリがあるようなので、ぜひ使っていきたいと思っています。一方で、AIエージェントについてはMCPは結構一般的だと思いますが、ほとんどのサービスはMCPが別に標準的ではないので、FastAPI等で基本は準備しておき、必要に応じてMCP等にマウントするのもかなりアリな仕様だなと思いました。

まとめ

素人ながらFastAPIをたくさん触り、APIを作り、実際にたたいてみる、と遊んでみました。
そこで得られた知見は想像より多く、MCPにもつながる話であったため、だんだんとMCPの有用性も理解してきました。今後は実際にローカルで動いているもうちょっとすごいマシンをFastAPIやMCPサーバーとして起動させ、エージェント等でどこまで動かせるか試していきたいと思います。
※ローカルに少しこだわっているのは製造業等では、ローカルでしか動かないソフトウェアやスタンドアロンの実機が多いためです

最後に

最近私がいる製造業だと本当にITリテラシーがないと感じています。そのため業務改善ネタもその効果もあまり理解されない、価値もわからない、結果的に普及しないなんてことが多いと思っています。私は最近そこが非常に問題だと思っており、私や周りのチームメンバーをハブとしてうまく社内で広められないか？とうことに挑戦しています。うまくいった人や応援いただける方がいればぜひコメントください。皆さんからもベストプラクティスを0ベースで学ばさせていただきます🔥