ツール：必要なのはコードだけ

326日前原文(lucumr.pocoo.org)

概要

MCP（Model Context Protocol） の現状と課題を論じる内容
コード生成 による自動化の優位性を主張
推論依存の問題点 とスケーラビリティの限界を指摘
実体験 を交えた自動化事例の紹介
今後の展望 として新たな抽象化やAPI設計の必要性を提案

MCP（Model Context Protocol）への批判と課題

MCP は今のところ 期待通りに機能しない という実感
2つの主な問題点 ：本当の意味での 合成性の欠如 と 過剰なコンテキスト要求
- 合成はほとんど推論に依存
- 各ツール呼び出しごとに 多くのコンテキスト が必要
GitHub MCP と gh CLIツール で同じタスクを比較すると、CLIの方が 効率的かつ迅速
コード生成 の方が 検証・再利用性 に優れるという現実

MCPの将来性に対するフィードバックと現時点の見解

エージェント的コーディング の文脈でMCPを評価
非プログラマー向けドメイン特化タスク にはMCPが有効という意見もある
しかし現状では 推論依存のため、コード生成よりも難易度が高い
多ツール化のアプローチ も本質的には フィルタリング層 の導入にとどまる
非プログラミング領域でもコード生成の方が合成性で有利

シェルスクリプトで自分を置き換えるという発想

プログラマー は問題解決にまず コード を選択
非プログラマー は自動化手段へのアクセスが難しい現状
多くの手作業タスク は本来自動化可能
LLMsの登場で「 自分をシェルスクリプトで置き換える」から「 LLMで置き換える」時代へ
しかし コスト・速度・信頼性 の課題が残る

スケールする自動化の本質

繰り返し実行されるタスク こそ自動化の本命
推論ベースの自動化 は検証コストが高く、 コード生成 の方が 検証性と再現性 で有利
LLMに 計算させる より、 Pythonコードを書かせる 方が安心
コードであれば プロセスの確認・検証 が容易

LLMを活用した実際の変換事例

ブログの reStructuredText→Markdown変換 をLLMで実施
AST（抽象構文木）変換 を指示し、中間生成物と最終結果を比較
比較スクリプト もLLMに生成させ、 変換誤差の許容範囲 も定義
少数サンプルで検証後、全記事へ拡大適用
推論コスト はイテレーション数とサンプル数に比例し、 全体量には依存しにくい

MCPで実現困難な自動化の再現性

上記の変換プロセスは コード生成→LLM検証→イテレーション という 再現性の高いパイプライン
Playwright など一部MCPは例外だが、 コード生成による自動化 の方が圧倒的に効率的
既知の環境 では Playwright Pythonスクリプト の方が推論不要で速い
一度書いたスクリプト は何度でも 再利用可能、MCPでは難しい
MCPツール の呼び出しは 抽象的かつ推論依存 でトラブルが多い

今後の展望と提言

現状のMCPはスケールしづらい ため、 新たな抽象化 や API設計 の模索が必要
サンドボックス化 や ファンアウト/ファンイン型推論 なども検討余地
コード生成＋LLMによる事後評価 という流れが有望
非プログラマー向け に、 生成コードの説明機能 をLLMで付与する可能性
MCPに固執せず、LLMのコード生成能力を活用する道を模索推奨

参考リンク・追加リソース

Agentic Coding Talk （著者による発表）
Drew Breunig 「How to fix your context」（MCPツール選択の工夫）
Manuel Odendahl 「MCPs are Boring」（AI Engineerの講演、MCPの課題を指摘）

タグ：ai

Hackerたちの意見

GitHubのMCPを使ってタスクを完了させてみて、それからgh CLIツールで同じことをやってみて。たぶん後者の方がコンテキストをずっと効率的に使えるし、目的の結果に早くたどり着けると思うよ。これ、まさにその通り。俺は「devops」フォルダにCLAUDE.mdっていうファイルを作って、よく使うbashコマンドをまとめてるんだ（例えば、このインテグレーションIDでprod/stagingのログを探すとか）。新しいタスクを終えたら（例えば、stripeからduckdbに同期された行を全部数えるとか）、Claudeにその例をCLAUDE.mdに更新するように言うんだ。次に似たような質問をしたとき、Claudeが一発で答えてくれる。これがCLAUDE.mdの最初の数行だよ。このファイルは、このリポジトリでコードを扱うときのClaude Code（claude.ai/code）へのガイダンスを提供する。## 目的このdevopsフォルダはGoogle Cloud Platform（GCP）の操作に特化していて、以下に焦点を当てている： - Google Cloud Composer（Airflow）のDAG管理と監視 - Google Cloud Loggingのクエリと分析 - Kubernetesクラスター管理（GKE） - Cloud Runサービスのデバッグ ## よく使うDevOpsコマンド ### Google Cloud Composer ```bash # Composer環境の詳細を表示 gcloud composer environments describe meltano --location us-central1 --project definite-some-id # 環境内のDAGをリスト gcloud composer environments storage dags list --environment meltano --location us-central1 --project definite-some-id # DAGの実行を表示 gcloud composer environments run meltano --location us-central1 dags list # Airflowのログを確認 gcloud logging read 'resource.type="cloud_composer_environment" AND resource.labels.environment_name="meltano"' --project definite-some-id --limit 50

└

ちなみに、下のセクションを超シンプルなstdio MCPサーバーにして、Claude Codeに接続することもできるよ。各操作をツールにして、パラメータのための明確なスキーマを持たせればいい。そうすれば、LLMにカスタムコマンドにアクセスするためのより構造化された方法を提供できる。こういう活動のために設計された既製のMCPサーバーもあると思うよ。編集：こんなMCPサーバーを探したときの最初の結果：https://github.com/inercia/MCPShell

└

たまに頭おかしくなりそうだよね。スニペットのファイルがあるのに、自分で実行するんじゃなくてAIに頼もうとするの？

└

自分用に似たようなファイルを使ってるけど、LLMの「エージェント」は使ったことないんだ。Emacsを使ってるけど、org-modeはこれだけに使ってる。セクションを折りたたんだり展開したりできるし、コードスニペットの上でC-c C-cを押せば実行できるんだ。いくつかはシェルコードで、いくつかはシェルコードを生成するEmacs Lispコードだよ。

└

私も似たようなことをやってるけど、問題はclaude.mdがどんどん大きくなっていくこと。これに対処するために、カスタムプロンプトをアプリに変換したんだけど、面白いトレードオフがある。アプリは決定論的で、未知の状況には対応できない。一方で、CCはすごく遅いけど、未知の状況に対処するための別の方法を試すことができる。結局、アプリを実行して問題があればアプリのコードを修正するようにカスタムコマンドに指示を追加したよ。自己修復ソフトウェア…誰がそんなことを考えたんだろう。

もっと適切に言うと、ターミナルだけで十分だよ。俺は数ヶ月間MCPを毎日使ってきたけど、今はMCPサーバーを一つだけに絞ってる：ターミナル（iTerm2）。必要なときに提供できるようにOpenAPIの仕様書も手元にあるけど、正直なところ、シェルコマンドとcurlがあればかなりのことができるよ。

└

bashシェルの組み込みツールでどこまでできるか、LLMがそれらを使っているのを見て初めて知ったよ。

方向性としてはこれが正しいと思う。スケールでのLLMの使用は、二つの堅牢なインターフェースの間のギャップを埋めることが多い。信頼性はLLMの推論や生成からではなく、インターフェース自体が特定の構成だけを許可することから来ている。LLMの出力は、しばしば型やDBの主キーなど、より決定論的なものに強制的に戻される。LLMの価値は、既存のコードやツールがデータ、ロジック、ドメインのアクションをどれだけうまくモデル化しているかによって決まる。ある意味、今のLLMを3Dプリンターのように見ている。 hypeとユーティリティの両方の観点からね。彼らは、3Dプリンターの部品を使った迅速なプロトタイピングのように、部品を素早く接続するのが得意だ。信頼性とスケールのためには、LLMかエンジニアが印刷された/推論されたコネクタを耐久性があり決定論的なもの（メタル/コード）に置き換える必要がある。さらに、3Dプリンターのガードナーのハイプサイクルの中で、私たちが大量の消費財を印刷することになるという考えがあったが、実際には高いユーティリティの使用ケースはもっと狭い。LLMの使用にも同じことが言える。LLMは非常に役立つけど、私たちの全ての運用現実を生成したり推論したりすることに頼ることはできないし、何らかの事前に存在するデジタルモデルがアンカーとして必要だ。

└

これは本当にいい意見だね。

└

ドローンとVRのハイプサイクルは似てたよね。ピークの時には、ドローンが荷物配達を支配して、みんながVRの中で過ごすって言ってたけど、実際は適用範囲がもっと狭いんだよね。

└

面白い意見だけど、LLMに対してちょっと悲観的すぎると思う。LLMはすでに大規模に使われてる（深い研究や翻訳など）から、今のところ3Dプリンターよりも普及してるよ。

└

方向性としては、これが正しいと思う。仕事で「方向的に正確」という言葉を使うんだけど、完全には正確じゃないけど、正しい方向に向かっているときに使うんだ。

LLMツールの使い方について気づいたことがあって、問題をLLMがサンドボックスでツールを使ってループで解決できるものにまで減らせれば、その問題を力技で解決できるってこと。仕事は、その問題を特定して、サンドボックスをどう設定するか、どのツールを提供するか、モデルの成功基準をどう定義するかを考えることになる。それにはかなりのスキルと経験が必要だけど、手作業で試行錯誤するよりは高いレベルだよ。俺のアセンブリのマンデルブロット実験がこれを理解するきっかけになったんだ：https://simonwillison.net/2025/Jul/2/mandelbrot-in-x86-assem...

└

理解できる。コードを扱うとき、LLMを自分自身と同じように扱う。「もし__________をする必要があるなら、何を知っておくべき/見ておくべきか？」伝統的なツールは、OPの言う通り、LLMの時代にますます強力で便利になっている（特にgrepがね）。さらに、LLMはシェルツールや機能（heredoc、grep、sedなど）を扱うのが得意だよ。

└

サンドボックス用にVMを使ってるんだけど、これでファイルが消えないか確認してるんだ。ホストのデータディレクトリをVM内で読み取り専用でマウントしてるけど、ちょっと手間がかかるね。AIエージェントをVMで動かして、出力をホストにコピーするツールがあればいいのに。そうすれば、ホストでネイティブに動かしてる感じがすると思う。

└

サンドボックス内でツールをループさせてLLMを使うと、その問題を力技で解決できるよ。これって大きなモデルをAPI経由で使って、たくさんのトークンを消費する必要があるの？それとも、ローカルモデル（たぶんすごく遅い）や、Claude CodeのProみたいなサブスクリプションでできるのかな（レートや使用制限に引っかからずに）？マンデルブロ集合の実験を見たけど、すごくクールだった。でも、まだかなり小さなプロジェクトで、実際のプラットフォームで使われている複雑なコードベースと比べるのは難しいね。

└

それめっちゃクールだね、シェアしてくれてありがとう！自分もLLMを使って問題を力技で解決することを考えてたんだ。LLMはTypeScriptのジェネリクスが苦手なんだよね。意外と下手くそで、正しく見えるジェネリクスを書くのは簡単だけど、実際にはいろんなシナリオでおかしくなることが多いんだ。だから、人間にとってもジェネリクスは難しいんだよね。もしどのLLMでもTSCを使えるなら、テストを実行して、正しく推論できてるか確認できるし、うまくいくまで試し続けられると思う。理解できるジェネリクスやメンテナブルなものを生み出す方法かはわからないけど、面白いと思う。それに、これを書いてる間にCursorがTypeScriptのエラーを見れることに気づいたよ。ユーティリティテストの型があれば、Cursorにテストを書かせて、問題を力技で解決できるかも！もし実際にやったら、このコメントを更新するね（笑）。

└

その仕事は、問題を特定して、それに対してサンドボックスをどう設定するか、どんなツールを提供するか、モデルの成功基準をどう定義するかを考えることになる。あなたのテストケースは、その最後のステップが欠けている典型的な例のように見える。フラクタルやx86アセンブリの背後にある数学を理解しているとは考えにくいから（もし間違ってたらごめん）、あなたの解決策の正確性を確認する手段は、表面的な視覚検査だけだよね。例えば、「マンデルブロ集合に見える？」みたいな。理想的には、評価基準は連続関数として表現されるべきだけど、少なくとも多様で量的に定義できる離散的な入力とその期待される出力のセットの形を取るべきだよ。

└

LLMに正しいコンテキストを与えること、例えば事前定義された「認知ツール」の形で、ここでたくさんの厳密さで探求されているのが、少なくともこのカジュアルな観察者には進むべき道に見える。1. https://github.com/davidkimai/Context-Engineering/blob/main/...（このリポジトリは進行中の本で、私はほんの表面をなぞっただけだけど、かなり素晴らしいと思う）

GitHub CLIの例はMCPに対してちょっと不公平だと思う。確かにGitHubのCLIはオンラインで詳しくドキュメントされてるから、LLMが有名なツールのコード生成に優れてるのは当然。でもMCPは別のシナリオで光るんだよ。社内ツールやオンラインドキュメントがほとんどないニッチなAPIを考えてみて。もちろん、ドキュメントを全部コード生成のためにコンテキストに入れることもできるけど、それにはMCPツールとやり取りするよりも多くのコンテキストが必要になることが多い。もっと重要なのは、知らないAPIの生成されたコードはエラーが出やすいから、しっかりしたテストと再試行の仕組みが必要になるってこと。MCPを使えば、ツールが適切に設計されていて正しい入力を受け取れば、信頼性があるんだ。LLMはAPIの複雑さや認証フロー、エッジケースを考える必要がなくて、それはもうMCPサーバーが処理してくれるから。だからGitHub用のMCPは過剰かもしれないけど、事前に作られたMCPツールが、ドキュメントが不十分なシステムをLLMに逆エンジニアリングさせるよりも意味があるケースはたくさんあるよ。

└

それはMCPサーバーが処理してるんだよね。認証とかはやらないし、世界を簡略化したビューを提供してる。もしそれが欲しかったなら、最初から自分のドキュメントが不十分な社内APIを違う風に設計すればよかったんじゃない？君が説明したシナリオでは、MCPには何の利点もないよ。元々のAPIが使いにくいって人を納得させる以外にはね。

└

確かに、ドキュメントをコード生成のためにコンテキストに入れることもできるけど、それにはMCPツールとやり取りするよりも多くのコンテキストが必要になることが多い。MCPはまさにそのように機能するんだ。ドキュメントをコンテキストに入れる。それがLLMが君のツールをどう呼び出すかを知る方法なんだ。カスタムなものでも、LLMに知ってること（例えば、PythonやJavaScript、Bash）を与える方が、MCPツールを呼び出すよりも良い結果が出ることに気づいたよ。ある意味、コンテキストを無駄にしないしね。個人的には、sonnet4で使えるツールの限界が15未満だと感じた。これはすごく少ない量だよ。基本的に公式のPlaywright MCPだけで、利用可能なツールスペースを完全に使い切ることができる。

あまりにも多くのコンテキストを要求する。これはデフォルトの初期プロンプトを用意することで簡単に解決できるよ。Claude CodeやGemini CLIのような主要なツールには、それを設定する方法がある。 > 君はすべてのツールをLLMに渡して、タスクに基づいてフィルタリングするように頼むんだ。今のところ、もっと良いアプローチはあまり提案されてないよ。なんで「より良い」アプローチが必要なの？現代のLLMがちゃんと理解できるなら。LLMはどんどんコンテキストの長さが増えて良くなってるんだから。LLMが適切なMCP機能を自分で使えないって問題は感じたことがないよ。 > でも、3つの問題にぶつかる：コスト、スピード、そして一般的な信頼性 - コスト：どんどん安くなってるよ。これらのツールが提供するものに対して、信じられないほど安い。 - スピード：これは非常に短絡的に見える。誰もターミナルでClaude Codeをじっと見てるわけじゃないし、無関係なトピックで複数の作業を同時に進めることもできる。それじゃ意味がないよ。どんなに時間がかかっても、かけた時間は純粋にボーナスだから。明確なタスクを頼む時にループにいる必要はない。 - 信頼性：今のところ、プロンプトにかなり依存してるように見える。多くの人が何を聞けばいいのか分からないのが主な問題だと思う。LLMが多くの外部ツールを同時に使って面倒なタスクを完了できるのは、MCPのおかげで本当に素晴らしいよ。ちょっとした話だけど、今日もNotionページ、Linear Ticket、git、GitHub PR、GitHub CIログを使ったタスクを完璧にこなしてくれた。ループにいるのはPRのレビューを1つ提出するだけだったし、その間に他のことをしてたんだ。で、費用は約1ドル？

└

これはデフォルトの初期プロンプトを用意することで簡単に解決できるよ。Claude CodeやGemini CLIみたいな主要なツールには、そういう設定方法があるし。でも、それだけじゃ逆効果だよ。MCPツールは初期コンテキストにどんどん追加されるから、ツールが増えれば増えるほど、MCPツールの定義でコンテキストが埋まっちゃうんだ。

└

コスト：どんどん安くなってるけど、実際には隠れてるだけだよ。無料のサービスもMoviePassや安いUberみたいに終わるからね。https://bsky.app/profile/edzitron.com/post/3lsw4vatg3k2b 「Cursorは月200ドルのサブスクリプションを出したけど、20ドルのプランを悪化させた（出力が悪くなって遅くなった） - それでもMaxでは人々を制限してるみたいだ！」 https://bsky.app/profile/edzitron.com/post/3lsw3zwgw4c2h

それはMCPが特に他の方法と比べてどうこうって話じゃなくて、単純に今のAIの状態では人間がループにいる方がずっと良いってことだと思う。LLMは特定のタスクに優れてるけど、しばしば局所的な最適解にハマっちゃうんだ。LLMのウェブインターフェースを通じてやり取りして、プログラムを書かせて、それを見て、改善のためのヒントを与えて、テストして…ってやってると、もっと良い結果が得られるし、10,000行のコードの混乱を見つけるために自分を切り離す必要もない。今のところそんな感じだけど、もちろん多くの人がプログラマーを置き換えようと必死になるだろうけど、今はそれは不可能だよ。できるのは、プログラマーの仕事を数倍早めること（でも、プログラミングとLLMの使い方に熟練してる必要がある）か、ある技術にあまりスキルがない賢い人を、LLMのおかげでその分野で生産的にすることだね。長い訓練が必要なくなる。あと、他にもいろいろあるよ。でも「エージェント的なコーディング」は今はうまくいってない。これは変わるだろうけど、今はLLMを同僚として使うのが本当の利点だよ。それはMCPじゃなくて、賢い人間からフィードバックを受けない自律エージェントだね。

└

自分でビジネスやってるんだけど、全部自分でコーディングしてるし、claude-codeも使ってる。いろんな役割をこなしてるから、Claudeにコーディングを任せられるなら任せたいな。まだそこまでには達してないけど、確かに役立ってる。ただ、全部読む必要があるんだ。自分は型安全な関数型コンパイル言語でも作業してるから、あまり「正しさが強制されない」言語でこのフローを試すのは怖いな。それでも、うまく機能してるのは確か。期待には応えてないけど、その期待の多くは明らかにナンセンスだったしね。概念の理解力には驚かされるし、時間も節約できてる。もっと大きなタスクも取り組みやすくなってるから、時間をうまく分けられるのが大事だね。

今のところ、MCPの一番のお気に入りはBruce Haumanのclojure-mcpだね。要するに、LLMに(a) bashツール、(b) 永続的なClojure REPL、(c) 構造編集ツールを提供してくれる。これのおかげで、Clojureコードの編集が文字列差分ベースのアプローチよりもずっと効率的になるんだ。いいテストスイートを書けば、ファイルを編集してリロードしてテストスイートをREPLで再実行するのを素早く繰り返せる。まるで自分がやってるみたいで、見ててすごく面白いよ。

└

ちょうどclojure-mcpについてコメントしようと思ってた！今まで見た中で、MCPの使い方としてはダントツでクールだよ。コードをデバッグしたり、個別の式を評価したり、関数の戻り値の型をドキュメント化したりできるんだ。すごいよね。強力なREPLを持つ言語の方が、持たない言語よりも良いと思わせるくらいだよ。clojure-mcpが動いてるのを見るのは、GPT-3を初めて見た時以来の最も印象的なAIの成果だね。

Playwrightの例についてだけど、今週、Playwright MCPサーバーを使ってエージェントを作ろうとしたら、遅くてトークン効率が悪くて不安定だって気づいて、直接Playwrightの呼び出しに書き直した経験がある。MCPサーバーは可能性を知るためには面白いかもしれないし、一回限りのマッシュアップには良いけど、API呼び出しの方が一般的には効率的で安定してるよ。自分が書いたエージェントはこちらだよ: https://github.com/pamelafox/personal-linkedin-agent デモ: https://www.youtube.com/live/ue8D7Hi4nGs

└

これ、めっちゃクールだね！それに、PlaywrightのMCP実装はやりすぎだと思ってて、Playwright APIの意見が強いサブセットの参考として考えてるよ。LinkedInって、オートメーションを構築するのが難しいことで有名だけど、個人のLinkedInエージェントを作る時に何か障害にぶつかった？

MCPの問題はすごくシンプルだと思う。フォーマットにJSONを使ってるけど、プログラミング言語ほど表現力がないから。例えば、Pythonの関数シグネチャを考えてみて。list_containers(show_stopped: bool = False, name_pattern: Optional[str] = None, sort: Literal["size", "name", "started_at"] = "name）。これにはドキュメントすら必要ない。これをJSONスキーマに変換すると、もう4倍大きくなる。出力を生成する時も、LLMはほぼ2倍のトークンを生成するから、JSONだと混乱しやすい。Python関数を呼び出して、その出力を使って他のツールを呼ぶ流れは、ファインチューニングデータの中で1000倍多く見られるけど、JSONツール呼び出しの流れはほとんど存在しないし、実際には指示チューニングの段階でしか見られない。だから、指示チューニングにはもっと複雑なコード例も含まれていて、モデルが複雑なロジックを実行しなきゃいけないんだ。さらに、構成の問題もある。私の知る限り、LLMがこれを一回のレスポンスで実行する方法はないよ。vehicle = call_func_1() if vehicle.type == "car": details = lookup_car(vehicle.reg_no) else if vehicle.type == "motorcycle": details = lookup_motorcycle(vehicle.reg_no) JSONツール呼び出しはこれをどう解決するの？

└

いい指摘だね。でも、MCPの「問題」って何だろう？私の意見では（すごく謙虚な非専門家だけど）、半端なセキュリティ面や欠けている部分がもっと根本的な問題だと思う。詳しい人からそのあたりのアップデートを聞きたいな。

└

LLMを使う理由は、車のタイプが車かバイクだけだと事前に分からないからなんだ。LLMは自転車やボート、飛行機の詳細を考えたり、左右の靴を別々に考える方法も見つける。LLMにこの機能を与えるだけじゃなくて、単に二つの選択肢に特化してるから。実行後にPythonスクリプトを書き直すフィードバックループを持たせることもできるけど、その時のコストは何だろう？スキーだって分かってるのに、Pythonで車について話してトークンを無駄にしてる。LLMはスキーの詳細を直接聞くことができるのに、間にスクリプトを書く必要はないよね。

ハクソク