ハクソク

世界を動かす技術を、日本語で。

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

2025年7月3日原文(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プリンターよりも普及してるよ。

└

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

Hacker Newsで議論の続きを見る