LLMとAPIの協働を支えるMCPプロトコルの実装と未来

Postman API Night Osaka 2025 Fallでは、MCP（Model Context Protocol）を活用したLLMとAPIの連携機構、生成AIによる開発支援、自然言語インターフェースの実装事例、AIを活用したAPIテストの進化などが紹介された。MCPは、LLMが外部ツールとやり取りする際のインターフェースを標準化する仕組みで、Postmanが積極的にサポートしている。これにより、LLMがAPIを呼び出す処理が簡潔に記述できるようになり、エージェント型のアプリケーション構築が加速している。ただ、ツール選択の精度や認可フローの実装には注意が必要で、特にツール数が増えるとLLMが誤った選択をするリスクがある。また、生成AIは開発効率を高める反面、意思決定領域とどこで区切るかという設計上の判断が求められる。

モジュール設計と検証の統合指向

サイボウズやダイキンの事例からは、MCPサーバー設計における「1ツール1ファイル」方式やカテゴリ別ツールセットの構成、IoTプラットフォームでのプロパティベーステスト・BDDの活用が示された。こうしたモジュール化は保守性を高めるが、AIによる誤選択リスクを抑えるには、LLM側のコンテキスト理解強化が不可欠である。特にツールが増えるとAIが混乱しやすいため、選択肢を絞る設計や、高抽象度のツールを組み合わせる工夫が求められる。また、テスト自動化においても、単なるカバレッジではなく、メトリクスと検証手法の統合が重要だと指摘された。例えば、プロパティベーステストやミューテーションテストを組み合わせることで、AIが生成したテストケースの質を担保できる。

分散システムとAI評価の多層設計

イベントを通じて、オンプレミス推論環境の重要性や、政府標準APIと自治体モジュールの二層構造、生成AI評価のための定量・定性指標の併用が議論された。LLMのローカル実行は、APIコスト削減以上に、データの外部流出を防ぐというセキュリティ上のメリットがある。また、自治体のデジタル化では、国が提供する標準APIと、地域に合わせた拡張モジュールの二層構造が望ましいとされる。生成AIの評価に関しても、単純な正解不正解ではなく、人手による定性的評価（RLHF）と、BLEUやROUGEのような定量メトリクス、さらにLLM-as-a-Judgeを活用した自動評価パイプラインの組み合わせが有効である。これらは、AIの出力が決定論的でないことを前提とした品質保証の新しい枠組みといえる。