なぜClaude Codeは人間向けUIを読まないのか。MCPによるAI専用データ提供の現在

人間向けUIからの脱却とAI専用データの台頭

AIアシスタントによるコーディング支援は強力だ。

しかしセッション間で記憶が持ち越されない課題がある。

先週ハマったポイントや過去の設計判断を毎回伝え直すのは非効率だ。

この課題を解決するためナレッジベースを管理するCLIツールをAIに連携させる動きがある。

Zettelkasten方式のナレッジベースを運用するzkというツールがある。

開発中に得た知見や設計判断をノートとして蓄積するものだ。

これをClaude Codeから直接参照させるアプローチが存在する。

これまでならCLIの実行結果をテキストとしてAIに読ませていた。

しかし今はRustで専用のMCPサーバーを構築する手法が主流になりつつある。

AIにはクリーンなAPIだけを見せ裏側の複雑な処理はサーバー側で吸収する。

11のツール、5つのプロンプト、7つのリソースを提供するサーバーが構築されている。

なぜ人間向けフォーマットはAIの敵なのか

人間にとって読みやすいフォーマットはAIにとってノイズになる。

CLIツールは人間が読むための装飾されたテキストを返す。

これをAIにパースさせるのは至難の業だ。

JSON形式で出力させるオプションがあっても複数のフラグを組み合わせる必要がある。

10件の制限をかけつつ特定のタグを検索する場合を考える。

出力フォーマットの指定やページャーの無効化など多数のフラグが必要になる。

AIがその組み合わせを毎回間違えずに実行できる保証はない。

出力されるデータの形式も一筋縄ではいかない。

タイトルが空だったり別のフィールドに情報が紛れ込んでいたりする。

実際に動かしてみないと分からない挙動が多すぎる。

これをAIのプロンプトだけで制御しようとするのは設計の敗北だ。

テンプレート変数を渡す際の非対話的な実行も鬼門になる。

入力を無効化するフラグが必要なことがドキュメントから読み取れずエラーになる。

ソート順を指定する際も具体的な値がヘルプに記載されていないことがある。

間違えて初めてエラーメッセージで正しい値を教えられる仕様だ。

しんたろー：
Claude CodeにCLIを操作させると、謎のエラーで止まることがある。
ヘルプにない隠し仕様に直面したAIの挙動が気になる。

MCPサーバーによる複雑性の隠蔽

そこで登場するのがMCPサーバーだ。

CLI固有の複雑な挙動やエラーハンドリングをサーバー内部で一度だけ対処する。

AIには厳密に型定義されたクリーンなAPIだけを提供する。

これによりAIの誤動作は減少し安定した自動化が実現する。

RustのSDKを使えばこの実装は簡単だ。

構造体に属性を付与するだけでパラメータのスキーマが自動生成される。

オプション型の変数は自動的にオプショナルなパラメータとして扱われる。

ドキュメントコメントがそのままAIへの説明文として機能する。

MCPはJSON-RPC上で通信を行う。

パラメータはJSON Schemaで厳密に型定義される。

これによりCLIのテキスト出力をパースする必要がなくなる。

各ツールは1つの操作だけを行い確実な結果を返す。

タグの表記揺れを防ぐ仕組みもサーバー側で実装できる。

大文字小文字の違いやスペースの有無を正規化するパイプラインを構築する。

3段階の処理を経てタグを統一する。

これによりAIが検索する際のヒット率が向上する。

開発インフラとしてのMCPの進化

開発インフラとしてのMCPの進化も見逃せない。

単一のツールをMCP化するだけでなくプロジェクト全体で統合管理するフレームワークが登場している。

Claude Codeの上に構築されたマルチエージェントフレームワークのCladeが存在する。

コーディング規約やプロジェクト固有のナレッジを複数のエージェントで共有する。

インタビュアー、アーキテクト、プランナー、開発者、テスター、レビュアー。

それぞれの役割を持ったエージェントが構造化されたワークフローの中で連携する。

設定ファイルはプロジェクトのリポジトリに保存されチーム全体で共有される。

ローカルの環境変数はGitの管理から外しセキュリティを担保する設計が標準化されている。

しんたろー：
Cladeのマルチエージェント構成を見ると、AIの役割分担が細分化されている。
承認フローを挟む設計は実務でも試してみたいと思った。

構造化されたワークフローと承認プロセス

Cladeでは開発プロセスが4つのフェーズに分かれている。

要件定義、計画、実装とテスト、そしてレビューだ。

各フェーズでエージェントがレポートを出力し人間の承認を待つ。

すべてが自動で進むわけではなく要所で人間の判断が介入する。

要件定義フェーズではインタビュアーが構造化された質問を行う。

その結果をもとにアーキテクトが設計レポートを作成する。

これらはすべてコードを書く前に行われる。

計画フェーズではプランナーがタスクリストを作成する。

実装フェーズではテスト駆動開発が採用されている。

テスターが失敗するテストを書き開発者が実装を行う。

その後テスターが検証しレポートを出力する。

レビューフェーズではコードとセキュリティの観点からチェックが行われる。

プロジェクト管理とセキュリティの基準

プロジェクトの管理手法も変化する。

MCPサーバーの設定や接続情報をプロジェクトのリポジトリ内で一元管理する。

チームに新しく参加した開発者がすぐに同じコンテキストで作業を始められる環境を作る。

AIエージェントのコンテキスト切れを防ぐための仕組みづくりが実務のコアになる。

セキュリティと透明性の確保もテーマになる。

自律型エージェントが社会インフラになるためには意図しない動作を防ぐ仕組みが求められる。

設計段階でのアクセス制御や実行ログの監視だ。

便利な道具を作るだけでなく信頼できるシステムを構築する視点が開発者には求められる。

PlaywrightのMCPサーバーではアクセス元をローカルホストに限定する設定がデフォルトになっている。

ステージング環境へのアクセスを許可する設定はローカルの設定ファイルにのみ保存される。

リポジトリにはコミットされない仕組みだ。

これによりセキュリティリスクを最小限に抑えている。

しんたろー：
AIにプロジェクトの文脈を渡す方法は常に課題になる。
MCP経由で設計ドキュメントを直接読み込ませる構成は、試してみる価値があると思った。

統合知見：AIとツールのインターフェース設計

複数の事例から見えてくる統合知見がある。

それはAIとツールのインターフェース設計におけるパラダイムシフトだ。

人間向けの出力をAIに解釈させるアプローチは限界を迎えている。

AI専用の構造化データを提供する設計が不可欠になっている。

zk-mcpの事例ではCLIの複雑さをサーバー側で隠蔽した。

Cladeの事例ではプロジェクトの文脈を構造化されたレポートとしてエージェント間で受け渡している。

どちらもAIが処理しやすい形式でデータを提供することに注力している。

このアプローチによりAIの誤動作が減り自律的なタスク遂行が可能になる。

AI連携に関するよくある質問

Q1: MCPを使って既存のCLIツールをAI連携させるメリットは何ですか？

最大のメリットはAIがCLIの人間向け出力をパースする際の不安定さを排除できる点だ。CLIの複雑なフラグの組み合わせやエラーハンドリングをMCPサーバー側で吸収する。AIには厳密に型定義されたクリーンなAPIとして提供する。これによりAIの誤動作を減らし安定した自動化が可能になる。

Q2: RustでMCPサーバーを構築する際の利点は何ですか？

RustのSDKを使用すると構造体に属性を付与するだけでパラメータのスキーマが自動生成される。オプション型の変数は自動的にオプショナルなパラメータとして扱われる。ドキュメントコメントがそのままAIへの説明文として機能する。これにより開発の手間を大幅に削減できる。

Q3: Cladeのようなマルチエージェントフレームワークの特徴は何ですか？

Claude Codeの上に構築され複数のエージェントが役割を分担して開発を進める点だ。インタビュアーやアーキテクトなどのエージェントが構造化されたワークフローの中で連携する。各フェーズでレポートを出力し人間の承認を待つ設計になっている。

まとめ

人間向けUIをAIに読ませるアプローチからMCPによる直接的なデータ提供への移行が進んでいる。

👉 ThreadPostでSNS運用を自動化する