- MCP 方式のツール接続は「未来」だと主張されているが、実際には 組み合わせ可能性の不足と過剰なコンテキスト消費 という限界があり、直接コードを書く方法のほうが依然として効率的
- LLM時代でも 自動化・反復作業 では、コードを生成・活用するほうが信頼性と検証の面で優位にある
- LLMは 推論ベースの自動化より、コード生成と反復実行 に強みがあり、コードベースのプロセスは問題把握・検証・拡張性に優れる
- Playwrightのような一部のツール（MCP方式）は、「推論ベース」の各段階ごとに不確実性とデバッグの難しさが増す一方、コードでスクリプトを直接生成・修正 すれば、再現性・速度・信頼性のすべてが向上する
- LLMがコードを生成し、別のLLMがそのコードを点検・説明する 「コード-レビュー-反復」ループ が、実際には最も強力な自動化フローである
コードさえあれば十分
- もしTwitterで私をフォローしているなら、最近の私がModel Context Protocol（MCP）にあまり好意的でないことを知っているはずだ
- 理由はアイデア自体への拒否感ではなく、MCPが宣伝されているほど効果的ではないからだ
- MCPには2つの主要な欠陥がある
- 真の 組み合わせ可能性（composable） を提供できない
- 過剰なコンテキスト提供の要求 により、コードを直接書いて実行するよりも多くのコンテキストを消費する
- 簡単な実験でこれを確認できる
- たとえばGitHub MCPでタスクを実行したあと、同じ作業を
gh CLIツールでやってみると、後者のほうがはるかに効率的にコンテキストを使い、より速く望む結果にたどり着く
But MCP is the Future! : でもMCPは未来では？
- この立場（コードのほうがよいという主張）について、私が受け取ったフィードバックを話したい
- 私はMCPを エージェントベースのコーディング（agentic coding） の文脈で深く実験し、限界が最もはっきり表れる部分 で評価した
- あるフィードバックは、「MCPは汎用的なコード生成には特に必要ない。すでにモデルはコード生成に十分優れているからだ」というものだった。一方で、特定ドメイン（例：金融企業の自動化業務） のような エンドユーザー向けアプリケーション ではMCPに意味があるかもしれない、という意見もあった
- 別の意見は、将来はモデルがより多様なツールにアクセスし、より複雑な作業も処理できるようになるのだから、その可能性に注目すべきだ というものだった
- しかし、現時点での私の判断はこうだ。自分が実験したデータと実体験によれば、現在のMCPは常にコードを直接書く方法より使いづらい
- 最大の理由は MCPが推論（inference）に依存している ことだ
- 最近の「より多くのツールをLLMに接続しようとするあらゆる試み」を見ると、結局はLLMがすべてのツールを受け取り、作業に合わせてフィルタリングする 層が入る
- これまで、これより優れた構造やアプローチが提案されたことはない
- だから私はこう結論づける。非開発者向けの特定ドメイン自動化 のような特殊なケースであっても、結局は コード生成 のほうが 組み合わせ可能性と再利用性の面で常により良い選択 だ
Replace Yourself With A Shellscript
- この問題の見方として、AIがなければ、開発者にとって問題解決の道具はコードである
- 非開発者にとってコードは難しく、多くの人が手作業で行っているさまざまな作業も、実際にはソフトウェアで自動化できる
- 現実的な問題は、誰がそのコードを書くのか ということだ。特殊な環境にいて自分でプログラミングできないなら、新たに学ぶのも難しいし、誰かが自分向けのコードを書いてくれることも期待しにくい
- もちろん一部の作業では 推論（人間の判断や柔軟性） が必須かもしれないが、実際には反復的で明確な作業の多くはコードで自動化できる
- 「自分をシェルスクリプトで置き換える」という古い開発者の言い回しがあるが、実際この種の自動化は昔から続いてきた
- LLMとプログラミングの時代には、シェルスクリプトの代わりにLLMで自分を置き換えようとする が、ここで 3つの問題（コスト、速度、信頼性） が現れる
- この3つの問題を解決するまでは、ツール（MCPなど）の利用を検討する段階ですらない
- つまり、自動化が実際にスケール可能な形で正しく動作するか をまず保証することが核心だ
Automation at Scale : 大規模自動化の本質
- 自動化の核心は、反復可能で再利用できる作業をコードで処理すること だ
- 一度しかやらず二度とやらない作業を自動化する必要はない。何度も繰り返す作業、機械が本当に生産性向上をもたらす仕事 から自動化は始まる
- 実際に1〜2回手動で試し、動作方法を整理したうえで、機械にそれを何千回も繰り返させること が自動化の本質だ
- こうした反復自動化では、常に「コード」を使うのが最善 だ
- LLMに毎回「推論」でやらせると、小さな作業はそこそこできても、検証にかかる時間と労力 が結局は自動化の効果を弱めてしまう
- 例：LLMに計算を直接させるより、LLMにPythonコードを書かせ、そのコードで計算 させるほうが信頼性も拡張性も高い
- コードを使えば 数式やロジック自体をレビュー可能 で、必要なら自分で修正したり、LLMに「この方法で合っているか」を審査させたりもできる
- Pythonが計算を間違える心配はないので、コード生成方式のほうが検証と信頼性の面で優れている ことは明らかだ
- この論理は単純な計算を超えて、実際の開発実務 にも適用できる
- 例：最近、このブログ全体のフォーマットをreStructuredTextからMarkdownへ変換する作業を行った
- かなり長く先送りしていたが、面倒だっただけでなく、LLMに直接変換を任せると どこかに微妙な欠落やミス、文脈の歪みが生じるのではないかと信用できなかった
- そこで結局、LLMを「直接の変換実行」には使わず、変換用コードを生成させてコードで処理 した
LLM → コード → LLM: 反復検証自動化の実際
- 最初の段階で、私はLLMに reStructuredTextをMarkdownへ変換する中核ロジック を生成してほしいと依頼した
- 単なる変換ではなく、AST（抽象構文木）を直接活用 して
- reStructuredTextをASTにパース → Markdown ASTへ変換 → HTMLとしてレンダリング
- こうすることで 中間変換段階 が得られ、結果を直接比較・検証しやすくなる
- 次に、LLMに 既存HTMLと新しいHTMLを比較するスクリプト も書いてもらった
- 変換後のHTMLの差分（diff）を分析しつつ、比較前に些細な差異（例：空白、フッターノートの処理方法など）を自動補正するよう設計した
- 変換過程で許容できるエラーの種類をLLM自身に考慮させた
- 例：Markdown/reStructuredTextライブラリのHTML表現が異なって細かな差が出ても、本質的な損失やエラーだけをふるい分けるようスクリプトに反映 した
- 3つ目として、LLMに 数百ファイルの結果を一括分析するためのバッチスクリプト も追加で依頼した
- このスクリプトで全ファイルを回しながら、差異が減るまで 反復改善（agentic loop） を進めた
- 全体の流れは次のとおりだ
- 最初は10件ほどをサンプルとして回し、差異が大きく減るまで反復
- 納得できる状態になったら全投稿に適用し、30分前後で自動処理
- 核心は、LLMが実際に変換に「成功」したから信頼できたのではなく、私が全過程を「コード」として検証・レビューできたからこそ信頼できた という点だ
- さらに、別のLLMに生成されたコードと変更内容を点検・解説させる ことで、より高い信頼を得た
- データ損失なしに機械的に正しく変換されるという確信があり、いつでもサンプル確認や修正が容易だった
- 最悪の場合でもMarkdown構文上の軽微な誤りが起きるだけで、実際の本文内容が壊れることはなかった
- もうひとつ重要なのは、この方式では推論（inference）コストが一定 であり、全ファイル数（15件 vs 150件）による負担の差が大きくないことだ
- 最終分析段階ではすでに些細な差は自動的にスキップされるため、大量変換でも反復検証の負担は大きくない
MCP Cannot Do That
- この長い説明の要点は、変換・自動化のパイプライン全体が「コード」で動いている ということだ
- 人間の入力 → コード生成 → LLMレビュー → 反復改善、という構造を 一般的な課題にも同じように適用できる
- たとえば、MCP方式の代表例として Playwright がある
- ブラウザを遠隔操作する自動化ツールで、ページを読み、理解し、ボタンを押すといった 各段階で推論（inference）が繰り返される
- この種の課題は実際、「コードによるアプローチ」で完全に置き換えるのが難しいこともある
- しかし、ページ構造をすでに把握しているなら（例：自分が開発中のアプリのテストなど）
- LLMに PlaywrightのPythonスクリプト を生成させて、それを実行する方式のほうがはるかに速く、信頼性も高い
- この方法なら 一度スクリプトを作れば数十回、数百回と繰り返し実行でき、追加の推論は不要だ
- 毎回リアルタイムで画面を解釈したりボタン位置を探したりする必要がなく、自動化フロー全体を一度に実行できる
- MCP方式では、各段階ごとに抽象化されたツール呼び出しと推論が必要 なため、LLMが常に正しく動くようにするのは非常に難しく、デバッグも困難だ
- たとえばMCPクライアントをシェルスクリプトに埋め込んで効率的にリモートサービスを呼び出したくても、実際にはこの方法が非常に非効率で実装も難しいことを痛感した
- 結局のところ、私は人間であってMCPクライアントではない
- コードは実行もデバッグもしやすいが、MCP呼び出しは毎回不確実で、信頼できない
- 実際には、LLMがコード生成中に作ってくれる小さなツール（例：Claude Codeのスニペット）を、むしろ自分の開発プロセスにおける長期的な道具として活用している
この結論はどこへ向かうのか？
- 正直なところ、私自身もこの流れがどこへ向かうのかは分からない。ただ、今こそ「意図的なエージェントコーディング（agentic coding）」のためのコード生成手法をどう改善できるか考えるのに良い時期 だ
- 奇妙に聞こえるかもしれないが、MCPが時には本当にうまく機能することもある。しかし現在の構造は「推論」に依存しすぎており、スケーラブルな大規模自動化には向かない袋小路 のように感じられる
- だからおそらく、MCPが強みを発揮できる領域と、コード生成方式の役割をより明確に分離・抽象化する方法 を見つける必要がある
- そのためには より良いサンドボックス（安全な実行環境） を作り、エージェントがAPIに対して自由に fan out/fan in 推論できるよう、API設計を変える試みも必要だ
- 「コードでできることは可能な限りコードで処理」し、大量実行の後でLLMが全体の結果を判定・レビューする構造 が望ましいと考えている
- そして、コード生成過程で十分なコンテキスト情報を追加し、LLMが生成されたスクリプトの役割を非開発者に自然言語で説明できるようになれば、今後はこの自動化フローを非開発者でも手軽に活用できるようになるだろう
- 結論として、私は MCPではなくLLMのコード生成能力をより大胆に活用し、新しい可能性を実験することを勧める
- LLMにコードを直接書かせれば、私たちが想像している以上に多くのことを自動化できる
参考資料
2件のコメント
共感はしますが、MCPの問題というよりは、その実装側、あるいは設計方針の最適化の問題のように思います。同じ機能でも、どのMCPかによって内部的にコードを生成したりコマンドを生成したりして不要な作業を減らせるからです。GitHub mcpではなく gh cli mcp や terminal mcp を使えば、トークンは使うにしてもはるかに少なく、同じ効果を得られるのに、この点は見過ごされているようですね。
Hacker Newsの意見
おおむねこの方向性が正しいことには同意する。大規模 LLM の利用は通常、2つの堅牢なインターフェースの間の隙間を埋める用途でよく使われる。信頼性の核心は LLM の出力そのものではなく、実際にはそのインターフェース自体が特定の設定しか許可しないことから生まれる。
LLM の出力はしばしば 型や DB の primary key のような、より決定論的な値に強制変換される。LLM の価値は、既存のコードやツールが自分のドメインのデータ、ロジック、振る舞いをどれだけうまくモデル化しているかによって大きく変わる。
個人的には最近、LLM は 3D プリンターに似ていると感じている。どちらも 高速プロトタイピング では素早く部品をつなぎ合わせてくれるが、スケーラビリティと堅牢性を求めるなら、結局は エンジニアや LLM が仮の接続部を金属/コードのような決定論的な支えに置き換えなければならない。
3D プリンターに対する過去の誇張された期待と同じように、LLM もあらゆる運用上の現実を置き換えられるかのように見えるが、実際に本当に役立つのは、既存のデジタルモデリングが堅牢な基盤になっているときだけだ。
LLM ツールを使う中で気づいたことがある。問題をサンドボックスの中で反復的にツールを使って LLM が解ける形に縮約できれば、その問題は ブルートフォースで解ける。このとき重要なのは、そうした問題を見極め、適切なサンドボックスと使うツール、成功基準を定めることだ。
このプロセスにもかなりのスキルと経験が必要だが、手作業で延々と試行錯誤するよりはずっと高次元だ。
私は「アセンブリ Mandelbrot 実験」をしながらこれに気づいた。
（実験リンク: https://simonwillison.net/2025/Jul/…
理想的には連続関数の形をした評価基準、少なくとも多様な入力とそれに対する期待出力を定量的に用意してこそ、本当の自動化が可能になる。
たとえば LLM は TypeScript の ジェネリクスに弱いが、本物の TSC を回せば、テストで検証しながら正しくなるまで試行を続けられる。コードの保守性は落ちるかもしれないが、理論上とても興味深い構造だ。
しかも Cursor は TypeScript のエラーを見られるので、ユーティリティ型のテストさえ作れば、Cursor 自体がテストを書き、問題を単純反復の brute force で解くこともできる。
参考になりそうなリポート: https://github.com/davidkimai/Context-Engineering/…
まだ全部は見ていないが、かなり印象的だ。
ローカルモデルでも可能なのか、それとも Claude Code Pro のようなサブスクリプションでできるのか考えている。
Mandelbrot 実験も面白かったが、実際の複雑な商用コードベースとは難易度がやや違う。
これは MCP 自体の問題ではないと思う。現在の AI のレベルでは、人間が途中に入る構造のほうがはるかに優れている。
LLM は特定の作業には強いが、しばしば局所最適に閉じ込められる。だから Web インターフェース上で行ったり来たりしながら「プログラムを書いて → 確認とヒント提供 → テスト」というループを回すと、品質は明らかに良くなる。
10,000 行のひどいコードを 400 行の明快なコードに変えられる。今のところ、これが現実だ。
もちろん多くの企業や開発者は「プログラマーそのものを LLM で置き換える」ことを望むだろうが、現実にはまだ不可能だ。
本当の効果は、プログラマーの 作業速度を何倍にも高めることや、初心者が LLM を通じて素早く生産的な仕事をできるようにすることにある。だが「agentic coding」はまだうまく機能していない。
現状での正解は、LLM を 同僚やアシスタントとして使うことだ。今の実態は、自律的なフィードバックを持たない「AI エージェント」ではない。
型安全で関数型のコンパイル言語で作業しているので、出力も常に自分で読む必要があり、もっと緩い言語ならさらに不安だと思う。
それでも 時間節約 の効果は大きい。特に作業を分割して大きな目標を扱いやすくできるようになった点には満足している。
実際に GitHub MCP でタスクをやってみると、同じことを gh CLI でやった場合のほうが、gh CLI はコンテキストをはるかに効率的に使うのでかなり速い。
私の「devops」フォルダには CLAUDE.md ファイル（共通 bash コマンド集）がある。
新しいタスクを完了すると、Claude に例を追加させ、その後の類似クエリでは Claude が一発で解決する。
CLAUDE.md の初期内容を共有すると、
（具体的なコマンドは要約）
その結果、問題が起きたときにコマンドへアプリのテスト&修正命令を追加した 自己修復ソフトウェア になった。
これまで見た MCP の活用で最も印象的だったのは Bruce Hauman の clojure-mcp だ。
LLM に (a) bash、(b) persistent Clojure REPL、(c) 構造的編集ツール を提供する。
その結果、Clojure コードを編集する際、純粋な文字 diff ベースのアプローチよりはるかに効率的に動作する。
きちんとしたテストスイートさえあれば、ファイル編集、リロード、テストの反復が人間の作業にかなり近い形で進み、驚いた。
コードの デバッグ、個別の式の評価、関数の返り値型のドキュメント化などの主要機能をサポートしている。
強力な REPL を持つ言語はそうした機能でずっと優れていると感じたし、clojure-mcp の活用可能性を見て AI に対する印象が大きく変わった。
GitHub CLI の例は MCP の強みをすべて示しているわけではない。
gh CLI のようにドキュメントへのアクセス性が高いツールは、LLM が簡単にコード生成できるので、当然そちらのほうがうまく使える。
しかし MCP の真の利点 は、社内専用ツールやオンライン文書がほとんどない ニッチな API でこそ現れる。
すべてのドキュメントをコンテキストに入れる方法もあるが、このような場合はむしろ MCP のほうが効率的だ。
よく設計された MCP ツールを正しい入力とともに使えば、LLM が API の理解、認証、エッジケース処理などを担う負担を大幅に減らせる。
GitHub には MCP は必須ではないかもしれないが、社内 API や不完全な API のような環境では、事前に作っておいた MCP ツールのほうが強力に機能する。
たとえば sonnet4 ではツールが 15 個を超えると限界が見えてくる。公式の Playwright MCP を使っただけでもツール容量を食う。
結局 MCP の唯一の利点は、API があまりにも扱いにくいときに「単にこれが複雑すぎたのだ」と再確認することに使えるだけかもしれない。
Playwright の例に関して言うと、
私も今週 Playwright MCP サーバーベースでエージェントを作ってみたが、遅く、トークン効率が悪く、信頼性も低かったので、再び 直接 Playwright を呼ぶ形に戻した。
MCP サーバーは何が可能かを試すには良いが、実運用では API 呼び出し のほうが効率的で安定している。
私が作った個人用 LinkedIn エージェントの例とデモを共有する。
LinkedIn は 自動化が非常に難しいプラットフォームとして有名だが、個人用 LinkedIn エージェントを作る中で困難や制約はあったのだろうか。
実のところ、ターミナルさえあれば十分だと感じる。
数か月にわたって MCP を毎日使ってきたが、今では 1 つの **iTerm2 ベースの MCP サーバー（ターミナル）**しか使っていない。
必要なら OpenAPI spec もあるが、実際には shell command と curl でほぼすべてできる。
「コンテキストが多すぎる必要がある」という指摘は、実際には 初期プロンプトのデフォルト設定をきちんと整えればよい。
Claude Code や Gemini CLI を含む主要ツールはどれも対応している。
LLM に全ツール一覧を渡して自分で取捨選択させる方式が最善とは言えないが、
最新の LLM は進歩し続けており、実際 適切な MCP 関数の選択で大きく困ったことはない。
コスト、速度、信頼性の問題についても、
会話に自分の時間を直接使う必要もない。
最近の例では、Notion、Linear、git、GitHub PR/CI ログなど大量の外部ツールを LLM が自動で処理し、
私は 1 回だけ PR レビューをしただけだった。
コストも 1 ドル未満だった。
むしろツールを追加するほど最初に必要な情報が増え、深刻な制約になることがある。
まだ隠れているだけで、無料・低価格プロモーションの構造は長続きしない。
たとえば Cursor も月額 200 ドルのプランが導入され、低価格プランのサービス品質は悪化している。
無料プロモーションが終われば、本来の水準に戻るだろう。
私は Julia で仕事をしているが、長時間実行されるセッション環境から恩恵を受けている。
関数は最初の実行時にコンパイルされるので、**MCP を作って Claude Code が永続的な Julia kernel（Jupyter）**にコードを送れるようにした。
テストコードの実行がずっと速くなり、CC は bespoke な bash ではなく コードベースの既存関数をよりうまく活用するようになった。
CCUsage ベースではトークン使用量も 50% 近く減った。
必ずしも MCP である必要はなかったかもしれないが、要点は「特定機能」をコードベースに接続することのほうが、Claude 向けに毎回 custom コードを書くより簡単だということだ。