営業支援システムとAIをつなぐMCPサーバーをつくる

MCPサーバーとは何をするものか

MCP（Model Context Protocol）は、AIと外部のリソースの連携を統合し、データの取得や操作を標準的な形で行えるようにするプロトコルです。ざっくり言えば、AIが社内システムを「決められた入口からだけ」触れるようにする仕組みです。

今回のねらいは、社内のSFA（営業支援システム）に入っている案件・売上・原価といった情報を、AIから安全に読み書きできるようにすることでした。

土台をつくる

最初に手を付けたのは、機能そのものではなくその手前の基盤でした。

• リポジトリの構築 ─ MCPサーバーの土台となる構成づくり
• Google OAuthクライアントの発行と Secret Manager での保管 ─ 認証情報をコードに書かずに扱う
• OAuth・Secret Manager のブリッジ ─ 認証まわりを一箇所に集約する
• Cloud Run へのデプロイとカスタムコネクタ接続、デプロイ時のトリガー設定

ここで扱ったのは、OAuth・OIDC・JWT・JWKSといった認証の仕組みそのものでした。「アクセストークンとIDトークンは何が違うのか」「署名はどの公開鍵で検証されるのか」といったところを、実際に動かしながら一つずつ確認していきました。呼び出したのが誰なのかをトークンの中身から特定する部分の実装は、そのまま権限設計に直結します。

ツールとスキルを実装する

土台ができてから、実際にAIが呼ぶ機能を実装しました。

• MVPツール6本 ─ 読み取り5本と、案件を作成する create_project 1本
• Excel取り込みテンプレートの作成 ─ 売上・原価をシステムに取り込む形を決める
• 通常系スキル3本 ─ 活動ログ、週報、簡易クエリ
• Excel取り込みスキル2本 ─ 売上取り込み、原価取り込み
• プラグイン構造の設計とスキル定義の執筆

ここでいう「スキル」は、AIエージェントに特定の業務手順やルールを教えるための定義ファイルです。ツールが「できること」を提供し、スキルが「どういう手順で使うか」を教えるという関係になります。週報や活動ログのように、営業担当者が毎週手で書いていたものを対象にしました。

進め方

開発はフェーズを分けて進めました（P1〜P5）。各タスクには完了条件があり、実装してPRを出し、レビューを受けて修正し、完了条件を満たしているかを確認してから次に進みます。

PRのレビュー対応やコンフリクトの解消も含めて、チームで開発するときの一通りの流れを経験できた案件でした。認証のバグを見つけて直したり、完了条件を読み直して実装が足りていない箇所を補ったりと、地味な往復が多い仕事でもあります。

社内システムのため、コードや画面は掲載していません。
設計の考え方についてはお話しできますので、必要であればお問い合わせください。

この案件で得たもの

それまで自分が触ってきたのは、画面があって動きが見えるものが中心でした。この案件は「見えないところを正しく作る」仕事です。認証が通ること、秘密情報が漏れないこと、誰がどこまで触れるかが決まっていること。どれも、動いているときは誰も気づかない部分です。

AIに何かをさせようとすると、結局この土台がないと安全に任せられません。AIエージェント開発で「AIに実装を指示する側に回りたい」と書きましたが、そのためにはAIに渡してよい範囲を設計できることが前提になる、というのがこの案件での実感です。