ヘイ、みなさん！👋
Function CallingとMCPを実際に使ってみて、両者の実践的な比較検討について共有したいと思います。
多くの読者はすでにMCPとFunction Callingについて理解していると思うので、技術的な詳細は省略します：
シナリオ：認証とセッション管理
例えば、AI駆動のニュースレターツールQuailyを開発しています。AIを使ってquaily.comに記事を投稿したいのですが、もちろん認証が必要です：
MCPを使用する場合：
ローカルプログラム（quail-cli）で認証とセッション管理を処理できます。ログイン状態はMCPサーバー（quail-cli）に自然に存在し、ログイン認証情報がLLMに漏洩することはありません。
認証情報が期限切れになった場合、MCPサーバーは簡単にquail-cliでユーザーに再ログインを強制できます。
認証とLLM処理の間に明確な境界があり、鍵と錠を別々に保管するようなものです。
Function Callingを使用する場合：
明らかにトークンやその他のログイン認証情報をLLMに送信することはできません：セッション識別子がLLMに記憶されるリスクがあるからです。これらのLLMが密かに鍵をコピーしないとは限りません。
可能な解決策：
- 超短期トークンの使用：例えば10秒間だけ有効なトークンを生成する
- さらに、再利用を防ぐために各リクエストで新しいトークンの使用を強制する
しかし、これらの方法はすべて複雑さを増し、それでもMCPアーキテクチャと同レベルのセキュリティ保証を提供できません。根本的な問題は変わりません：Function Callingを使用すると、制御できないシステムを通じて機密情報を渡すことになります。
ビジネスモデルへの影響
セキュリティの問題だけでなく、ビジネスモデルにも関わります。ビジネスモデルは基本的に、顧客やユーザーに一連の有料ゲートを持つ高速道路を提供し、そのゲートからお金を稼ぐことです。
例えば、Quailyでは、ゲートは有料コンテンツへのアクセスであり、ビジネスモデルはサブスクリプション制です。
前述の通り、Function CallingはMCPアーキテクチャと同レベルのセキュリティ保証を提供するのが難しいため、製品の迅速な構築には適しているかもしれませんが、サービスの境界を作るのは困難です。このようなビジネスモデルの実施は、厄介というよりもむしろ苦痛です。
一方、MCPはアクセス制御の構築に本質的に適しています - 特に、OpenAIのようなインフラを構築する能力がないがAIアプリケーションを作りたい開発者にとってはそうです。
決定：MCPの選択
今日、両方のアプローチが実際の問題を解決していますが、両方の方法を深く使用した後、私はMCPが多くのシナリオにより適していると感じています。以下が私の見解です：
- セキュリティ設計：MCPのアーキテクチャは、Function Callingが対処困難な認証情報の露出問題を根本的に解決します
- 将来性：アプリケーションの成長に伴い、MCPのモジュラーアーキテクチャはより優雅にスケールします
- 明確な境界：データアクセスとLLM処理の分離により、より保守しやすいシステムが作成されます
- エコシステム構築：MCPはアプリケーション間で共有可能な能力ネットワークを構築でき、商業化に有利です
どう思いますか？考えを共有してください。