最高の開発者ツールは存在を忘れるもの

最高の技術には奇妙な性質がある：うまく機能すればするほど、気づかなくなる。

ウェブを閲覧するとき、TCP/IPのことは考えない。絵文字を入力するとき、UTF-8のことは考えない。ウェブサイトを訪問するとき、DNSのことは考えない。これらは数十億人が毎日、まったく意識せずに使っている壮大に複雑なシステムだ。

これが開発者ツールが目指すべき基準だ。「学びやすい」や「ドキュメントが充実している」ではない——それらは良い目標だが、本当の目的地への中間地点にすぎない：見えなくなること。

今のところ、MCPサーバーの構築と保守はあまりにも手動だ。ツールの説明を手で書く。LLMがスキーマを理解するか手動でテストする。セキュリティを目視で確認する。AIクライアント間で設定ファイルをコピペする。

これらの各ステップは、開発者が実際に解決しようとしている問題ではなく、MCPの配管について考えなければならない場所だ。HTTPリクエストを行うたびにTCP設定を手動で構成しなければならないようなものだ。

目標は：自分のサービスが何をするかを記述すれば、他のすべて——セキュリティスキャン、品質スコアリング、クライアント構成、変更監視——が自動的に行われること。

理想的なMCP開発者体験はこうだと思う。

ツールをコードベースに向ける。関数を分析し、ツール定義を生成し、セキュリティスキャンを実行し、すべての主要AIクライアント用の設定を生成する。出力を確認し、承認すれば完了。

コードが変更されると、ツールが変更を検出し、影響を分析し、アップデートを提案する。変更が安全なら自動的に適用される。人間のレビューが必要なら、何が変わったか、なぜ重要かを正確に教えてくれる。

ツールの説明を書くことは決してない。クライアントを手動で設定することもない。MCPサーバーにセキュリティ脆弱性があるか心配することもない。複雑さは消えない——それを処理するために作られたシステムに委任される。

インフラが見えすぎると、2つの悪いことが起きる。

第一に、人々はそれをスキップする。セキュリティスキャンが手動ステップを必要とするなら、一定割合の開発者はスキップする。クライアント設定が面倒なら、1つか2つしかサポートしない。

第二に、人々は間違える。手動プロセスはエラーが起きやすい。手書きのツール説明には微妙な不正確さがある。手動設定のクライアントには権限の不一致がある。

解決策はより良いドキュメントやトレーニングではない。自動化だ。正しいことを簡単なことにし、簡単なことをデフォルトにする。

開発者ツールを作っているなら——MCPでもそれ以外でも——消えるためにデザインせよ。

ワークフローのすべての手動ステップは将来の障害点だ。開発者が維持しなければならないすべての設定ファイルは、いずれドリフトするファイルだ。人間の開始を必要とするすべてのセキュリティチェックは、いずれスキップされるチェックだ。

最高のツールは開発者に新しいワークフローを教えない。既にあるワークフローに統合する。ステップを追加しない——削除する。

誰かが「MCPセキュリティはどう扱っていますか？」と聞いて、答えが「考えてません、勝手に行われます」なら——ツールが到達したことがわかる。