個人開発で MCP サーバーを作ってみての感想

はじめに

AI Agent にどハマり中の高木です。趣味で 日程調整のTogello を開発しています。
最近話題の MCP（Model Context Protocol）サーバー を深く理解したくなり、「じゃあ自分で作ろう」と思い立って、Togello 向けにミニマム実装してみました。この記事では、作ってみた感想と生活がどう変わったかをゆるっと共有します。

リポジトリはこちら → https://github.com/Toru-Takagi/togello-mcp-server

作ってみた感想

実装してみると MCP サーバーの解像度が一気に上がりました。MCP サーバー関連の記事を読んでいた頃よりも、どう実装すれば良いか、どこが便利でどこに課題があるか がはっきり見えるようになりました。
USB-C にたとえられることも多い MCP サーバーですが、僕は Twitter で見かけた「AI Agent のためのリモコン」という比喩がお気に入り。自分に合ったリモコンを作り、AI Agent に渡してあげると 効率が一気に跳ね上がります。

だからこそ、「自分専用リモコン」を作るつもりで、よく使うツール向けに MCP サーバーを自作してみるのをおすすめします。公式サーバーが公開されているケースも多く「車輪の再発明では？」と迷うかもしれませんが、自作したほうが手に馴染む感覚が段違いです。

コードはかなりシンプルなので、ぜひ参考にしてみてください。
https://github.com/Toru-Takagi/togello-mcp-server

どう生活が変わったか

Togello は日程調整サービスですが、タスク管理・工数管理・カレンダー機能も備えています。
（開発コストを下げたくて一緒にしちゃいました笑）
仕事ツールを Togello に集約したことでツール移動は減ったものの、毎回 Togello を開く操作自体が正直面倒でした。

エンジニアの僕は一日の大半をエディタで過ごします。だからこそ、エディタの延長線でタスク操作できる体験は抜群に快適です。

従来の動き

1. 仕事が発生する（MTG／Slack 依頼／本番エラーなど）
2. Togello にアクセスして行動開始やタスク追加を記録
3. エディタで実装・調査・レビュー

いまの動き

1. 仕事が発生する
2. エディタ内の AI Agent に「作業を始める」「タスク内容を教えて」とチャット
3. そのままコードを書き始める

いまや AI Agent との対話は開発フローの一部。具体的には

• 右側タブで Copilot Agent と会話してタスク管理
• 左側タブで Cline に開発指示を投げる

といった具合に、AI に任せることで多少コンテキストスイッチ疲れはあるものの、複数タスクを並行で回せるようになりました。

MCP サーバーで UI は不要になるのか？

個人的には、UI はまだまだ必要だと思っています。

一般的には文字入力のコストが高いと言われますが、僕の場合はマウスで画面を行き来するより、キーボードで直接コマンドを打つほうが速いので PC では MCP が快適です。
一方で、スマホで文字入力してまで操作したいとは思わず、アプリの UI でタップできた方が断然ラク。ちなみに Apple Intelligence などで自然に音声入力できるようになれば、また話は変わるかもしれません。

さらに言うと、MCP ツールでは「アプリの挙動」と「ツール定義」を頭に思い浮かべて指示を組み立てる必要があります。AI Agent の思考時間が長いのも地味にストレス。どのデータを取るかを毎回考えずに済む点でも、UI がある方がやはり便利だと感じています。

MCP サーバー開発の楽しいところ

まず、型パズルや UI 表示で悩まなくて済むのが最高です。
ツール定義にデータの意味やルール、関係性を書いておくだけ。あとは API のレスポンスをそのまま渡せば、AI Agent が認識してデータ操作してくれます。

たとえば Togello では TODO にカテゴリを紐づけますが、API 側は CategoryUUID を直接受け取る仕様でした。そこで

1. Category 一覧を取得する API を呼ぶ
2. 取得した中から 該当 UUID を選んで TODO を作成する

というルールをツール定義に追記したところ、AI Agent が一覧取得 →UUID 選択 →TODO 作成まで自動でやってくれるように。「関係性を宣言するだけで全部やってくれる」── この魔法感がたまりません。

微妙な点

AI Agent の待機時間問題

AI Agent に気軽に指示を出せるのは嬉しいものの、高性能モデルほど応答が遅く「待ち」が発生してしまうのが悩みです。
タスク追加のように「依頼 → すぐ別作業へ」と切り替えられる場面は許容できますが、タスク一覧やカレンダーといった結果をすぐ確認したい操作ではストレスが勝り、結局 UI を直接開きがち。登録だけ任せようにも、たまにフォーマットが崩れるなど意図しない形で保存されることもあります。

では軽量モデルにすればいいかというと、今度は MCP 操作の精度が落ち、期待と異なる結果になる確率が上昇。
結局、「即時性が欲しい場面は従来 UI、バッチ系は Agent」という住み分けに落ち着いているのが現状です。

意図した結果か分からない

タスクを「更新しておいて！」と頼むと、AI Agent からは「更新しました！」と返ってきます。ところが実際にはツールを操作しておらず、Agent の内部で完了扱いにしただけ── というケースがたまに起こります。
Client 側の問題もありますが、MCP を使う想定でも実際には呼び出されないことがあります。

出力フォーマットが安定しない

これも地味に厄介です。
同じ依頼でも セッションが変わると出力が微妙に変わり、モデルを切り替えればさらに揺れ幅が大きくなります。もちろん毎回フォーマットを細かく指定すれば安定はしますが、その手間を考えると 「やっぱり UI が最強だよね」 という気持ちに落ち着きがちです。

モデル依存の揺れが大きい

問題の根っこは モデルの選択と挙動の揺れ にあります。
新モデルが次々リリースされるぶん安定しづらく、性能が高ければ万事解決というわけでもありません。モデルを切り替えただけでレスポンスの形式や精度が変わり、ワークフローに影響が出ることもしばしば。

開発のように “高度で創造的” なタスクなら、モデル性能が高いほど頼りになるし、新しいモデルが出るたびに嬉しかったりもします。
一方、今回のように 「とにかく速く終わらせたい処理」 では、高性能モデルの待ち時間がネックになりがち。用途に合わせて モデルと UI を適切に使い分けるのが現実的だと感じています。

まとめ

MCP サーバーを自作してみたおかげで、仕組みの輪郭がぐっと鮮明になりました。どんな業務なら MCP ツールと AI Agent の組み合わせで爆速化できて、どんな場面では「思ったより待ち時間が痛い」か ── その特性もだいぶ掴めてきた感じです。とはいえ、結果をサッと確認したいときはやっぱり UI の即時性が最強。しばらくは 「登録や裏方処理は MCP、確認系は UI」 というハイブリッド運用が現実解かな、というのが今回の結論です。