フィールドオペレーションのスケジュール管理向けリモートMCPサーバー構築の舞台裏

MCPサーバーは、単なるデモにとどまらず、実際の業務フローを担うようになって初めて真価を発揮します。Crisphiveにおいて、その業務フローとはフィールドオペレーションのスケジュール管理でした。オペレーターにチャット画面へすべての情報を転記させることなく、案件、スタッフ、場所、対応可否、配車状況を把握するという、煩雑でありふれた日常業務です。この開発ノートは、CrisphiveのリモートMCPサーバー開発の原点となるストーリーです。なぜ構築したのか、どのようなアーキテクチャを選択したのか、OAuthをどのように組み込んだのか、そしてClaudeコネクターディレクトリへの掲載に向けた道のりをどのように考えたのかを解説します。

概要

フィールドオペレーションのスケジュール管理は、単一のきれいな作業ではありません。配車担当者は、案件の準備が整っているかを確認し、適切な技能を持つ担当者を特定し、前回の顧客メッセージ以降に何が変わったかを把握し、新たなスケジュールの競合を避けながら調整を行う必要があります。これこそまさに、AIアシスタントにプロンプト以上の機能が求められる業務です。スケジュール管理システムに正確な質問を投げかけ、正確な回答を受け取れるツールが必要になります。

したがって、CrisphiveのリモートMCPサーバーに対する要件はシンプルでした。スケジュール管理製品を単なる汎用チャットのおもちゃに変えることなく、AIクライアントが利用できるツールインターフェースとしてスケジュール管理機能を露出させることです。Model Context Protocol（モデル・コンテキスト・プロトコル）により、ツールの定義、予測可能な連携形状の維持、そしてアシスタント機能とバックエンドの運用システムとの分離が可能になりました。プロトコルの詳細については、プロジェクトの公式サイト modelcontextprotocol.io をご覧ください。

この考え方により、単なる「MCPサーバー 2026年チェックリスト」を追うような不必要な開発を避けることができました。本当に重要な問いは、より具体的なものでした。アシスタントがシステムに直接照会することで、どのスケジュール管理作業がより安全かつ迅速になるのか、そしてどの作業は人間が判断を下す製品UIに残すべきなのか、ということです。

また、想定する読者についても明確にしておく必要がありました。開発者やAI構築者は、MCPサーバーソフトウェアの営業トークを求めているわけではありません。彼らが知りたいのは境界線です。アシスタントが呼び出せる範囲、スケジュール管理システムが引き続き保持する領域、そしてリクエストが曖昧な場合に何が起こるかです。この境界線の定義が、開発全体を形作ることになりました。

仕組み

アーキテクチャの起点となったのは、ローカル環境のみの実験ではなく、リモートMCPサーバーの構築でした。このサーバーは、AIクライアントとCrisphiveのスケジュール管理APIの間に位置します。ツールを定義し、入力を検証し、スケジュール管理のバックエンドを呼び出し、不要な内部構造を露出させることなく有用なレスポンスを返します。言い換えれば、安易な近道ではなく、目的をしぼったAIエージェントツールAPIとして機能します。

OAuthが重要であった理由は、スケジュール管理データが運用データそのものだからです。配車の状況を読み取ったり操作したりするコネクターは、どのワークスペースで動作しており、どの権限が適用されるかを認識していなければなりません。リモートサーバーを挟むことで、認可パスの処理、適切なアカウントコンテキストの付与、ツール呼び出しが匿名バックエンドトラフィックになるのを防ぐ仕組みを一元化できます。

初期のツール設計では、フィールドオペレーションのユースケースに密接に沿った形を維持しました。これは、汎用的なCRUD操作ではなく、スケジュール管理に特化したファンクションコーディングとして考えることを意味します。有用なツールは、案件、空き状況、割り当て、時間枠、顧客情報、配車制約など、現場のオペレーターと同じ言語を扱うべきです。この目的に最適なMCPサーバーとは、最も多くのツールを備えたものではありません。検証できるほどシンプルで、実用的であるほど具体的なツールを備えたものです。

Claude側の設計手法もパッケージングに影響を与えました。製品の変更が発表される公式の Anthropicニュース などを含むAnthropicのコネクターエコシステムは、本番環境向けコネクターが斬新さだけでなく信頼性によって評価されることを示しています。Crisphiveでは、ディレクトリへの適合性を単なるリリース当日の作業ではなく、プロダクトの制約事項として扱いました。

ユーザー体験

ユーザー体験は、複雑なアーキテクチャを感じさせないシンプルなものであるべきです。配車担当者が、どのツールが呼び出されたかや、リモートMCPサーバーがどのようにアカウントコンテキストを解決したかを気にする必要はありません。スケジュールに関する質問を投げかければ、すでに管理しているフィールドオペレーションの状況を反映した回答が得られるべきです。

小規模事業者にとって、この違いは実用上の大きな意味を持ちます。作業員の到着が遅れている。顧客から早めの時間帯への変更を求められた。管理者が明日のルートにあと1件追加できるか知りたい。このような場面で、アシスタントがスケジュール情報を安全に参照できなければ役立ちません。だからこそ、中小企業向けのMCPサーバーは適用範囲を厳格に限定する必要があります。バックエンドで処理可能だからという理由だけで、あらゆる機能を露出させるべきではありません。

また、コネクターが不確実性を明確に示すことも重視しました。人間の判断が必要なリクエストであれば、ツールのレスポンスでその旨を伝えるべきです。ツールの参照できないポリシーに依存するスケジュール変更であれば、処理を中断する必要があります。これは開発中に得られた貴重なMCPサーバー構築のノウハウの1つです。呼び出しの成功と同じくらい慎重に、責任ある拒否を設計することです。

優れたドキュメントもユーザー体験の一部です。Claudeとの連携に関する実装の詳細は、運用担当者向けのワークフロー内ではなく、docs.claude.com に近い場所に配置されます。これらを分離しておくことで、開発者は配車管理製品をエンジニアリングコンソールのようにな we させることなくデバッグできるようになります。

得られた教訓

最初の教訓は、Model Context Protocolはプロダクトにおける決定の半分に過ぎないということです。残り半分はツール設計です。MCPサーバーの実例を見ればプロトコル自体は簡単に思えるかもしれませんが、フィールドオペレーションのスケジュール管理ではより厳しい問いに直面します。何を読み取り可能にし、何を操作可能にするか、そして安全性が証明できるまでアシスタントの実行から外しておくべきアクションは何か、という問いです。

2つ目の教訓は、オブザーバビリティ（可観測性）から着手することでした。ツールの呼び出しには、アシスタントのリクエスト、認証されたワークスペース、バックエンド呼び出し、増して実行結果を紐付けるログが必要です。この一連のトレースがなければ、不適切な回答の原因がプロンプト、ツールの説明文、スケジュール管理API、あるいはユーザーの言い回しのどこにあるのかを特定することが困難になります。MCPサーバーの品質を向上させる方法は、多くの場合、高度なプロンプトよりも着実なトレースの整備に帰着します。

3つ目の教訓は、抑制することです。コネクターは高機能になると同時に脆くなる可能性があります。有用に思えるアイデアをすべて詰め込むことは避けました。代わりに、スケジュール管理のワークフローを起点として外側に向け設計し、各ツールが実際の配車担当者によるより良い意思決定に役立つかどうかを問いかけました。これにより、すべてのAPIを薄くラップしただけのシステムになるのを防ぐことができました。

最後の教訓は、商業的でありながら技術的でもある側面です。MCPサーバーのコストはホスティング費用だけではありません。レビューの時間、権限モデルの設計、メンテナンス、そしてアシスタントが実際の現場運用に触れる際のサポート負担も含まれます。これらのコストをアーキテクチャの一部として捉えることで、より実用的な構築が可能になりました。

今後の展望

次のステップは、コネクターの機能をやみくもに拡張することではありません。信頼性をさらに高めることです。つまり、スケジュール管理のワークフローに明確なメリットがある部分のみツールの対象範囲を広げ、曖昧なリクエストに対する検証を強化し、ツールの結果とオペレーターの次のアクションとのフィードバックループを改善することです。

今後の改善は段階的なものを想定しています。より明確なツールの説明文、エラーメッセージの改善、各ツールに許可される戻り値の厳格な見直しなどです。こうしたブラッシュアップはリリース時のスクリーンショットでは目立ちませんが、運用開始後もコネクターが信頼され続けるために不可欠な要素です。

また、プロダクト開発プロセスにおける社内実例の充実も目指しています。公の宣伝や演出されたデモではなく、配車担当者が実際にどのように助けを求め、アシスタントがどこで一時停止すべきかを示す内部的なMCPサーバーの実例です。こうした実例を重ねることで、リモートMCPサーバーは単なるプロトコル連携から、フィールドオペレーションのワークフローにおける有用なツールへと進化していきます。

全体的な方向性は明確です。AI構築者は今後もアシスタントを運用システムへと接続し続けるでしょう。私たちの考えでは、フィールドオペレーションにはスケジュール管理ツール自体と同じ規律をもって構築されたコネクターが必要です。小さなツール、明示的な権限、慎重なログ記録、そしてチャットインターフェースによって人間の判断が不要になるという幻想を持たないことです。このMCPサーバーが開発ノートから本番環境の運用ツールへと移行する中で、私たちが満たそうとしている基準はまさにここにあります。