LLM拡張の苦い教訓

 (sawyerhood.com)
23 ポイント 投稿者 GN⁺ 2025-11-28 | 1件のコメント | WhatsAppで共有
  • この3年間でLLM拡張方式の進化は、プラグイン、ユーザー指示、メモリ、プロトコル、スキルなど多様な形へと発展
  • 初期のChatGPT PluginsはAPI呼び出しによる汎用ツール利用を試みたが、モデルの限界と複雑なUXにより失敗
  • その後Custom InstructionsとCustom GPTsが登場し、シンプルなプロンプトベースのパーソナライズと共有可能なカスタムモデル構造を提供
  • Model Context Protocol(MCP) と Claude Codeは複雑だが強力なツール統合を可能にし、最近ではAgent Skillsがそれを単純化した形で復活
  • 最終的には汎用目的のツールと自然言語の指示だけで作業を実行するエージェント構造がLLM拡張の中核的な方向になる見込み

LLM拡張の歴史と変化

  • LLMの利用形態は、単純なテキスト入力からコードベース・ブラウザ制御型エージェントへと発展
    • ユーザーごとのカスタマイズをどう支援するかが中核課題として浮上
    • 単純なシステムプロンプトから複雑なクライアント・サーバープロトコルまで、多様なアプローチが試された

ChatGPT Plugins（2023年3月）

  • OpenAIがChatGPT Pluginsを発表し、OpenAPI仕様を通じてLLMがRESTエンドポイントを呼び出すよう設計
    • AGI水準の汎用ツール利用を志向
  • しかしGPT-3.5と初期GPT-4の限界により、大規模なAPI仕様探索ではエラーや文脈の喪失が発生
    • プラグインの手動有効化など不便なUXも問題だった
  • それでも**Code Interpreter（後のAdvanced Data Analysis）**プラグインは、強力なサンドボックス実行環境の可能性を示した

Custom Instructions（2023年7月）

  • プラグインの複雑さを減らしたシンプルなユーザー定義プロンプト機能
    • すべての対話に自動追加され、繰り返し文脈を設定する問題を解決
  • その後、.cursorrules、CLAUDE.mdなど開発環境内のルールファイルの前身として機能

Custom GPTs（2023年11月）

  • OpenAIはCustom GPTsを通じてプロンプトエンジニアリングを製品化
    • ペルソナ、ファイル、アクションを束ねて共有可能なカスタムGPTリンクを作成
  • プラグインのオープンなアプローチから単一目的アプリの形へ後退

ChatGPTのMemory（2024年2月）

  • 自動パーソナライズ機能へ転換した最初の事例
    • 対話中に言及された情報を記憶し、その後の文脈に自動反映
    • ユーザーが直接設定しなくても長期状態を維持する持続的エージェント構造の始まり

Cursor Rules（2024年4月）

  • Cursor IDEが.cursorrulesファイルを通じてリポジトリ単位の指示管理を導入
    • 例: 「タブを使う」「セミコロン禁止」「TypeScriptを使う」など
  • その後.cursor/rulesフォルダ構造へ拡張され、ファイル別・ディレクトリ別のルール適用が可能に
  • LLMがいつルールを適用すべきかを自ら判断する機能も追加された

Model Context Protocol（MCP、2024年11月）

  • Anthropicが導入したMCPは、モデルが実際のツールを安定して使うための構造を提供
    • クライアント・サーバー接続を維持しつつ、ツール定義、リソース、プロンプトを交換
  • 単純なコンテキスト追加ではなく、**実際の機能付与（capabilities）**を提供
    • 例: リポジトリの読み取り、DBクエリ、Vercelデプロイ
  • 複雑さと設定負担は大きいが、**ChatGPT Apps（2025年10月発表）**の基盤レイヤーとして使われている

Claude Codeと拡張メカニズム（2025年2月）

  • Claude Codeは多様な拡張方式を統合したエージェント
    • CLAUDE.mdでリポジトリ指示を管理
    • MCPでツールを統合
    • Slash Commands、Hooks、Sub-agents、**Output Styles（廃止予定）**などをサポート
  • 一部機能は維持されるか不透明だが、エージェント拡張の実験的統合モデルとして評価される

Agent Skills（2025年10月）

  • ChatGPT Pluginsの再来とも言える形で、複雑なプロトコルなしにフォルダベースのスキル構造を採用
    • skills/ディレクトリ内のSKILL.mdとスクリプト、サンプルファイルで構成
    • 必要なときだけ全内容を読み込み、**コンテキストウィンドウの肥大化（context bloat）**問題を解決
  • 例: PlaywrightベースのWebアプリテストスキル
    • SKILL.mdにメタデータと利用ガイドを含む
    • スクリプトは直接実行され、LLMはコード内容を不要に文脈へ読み込まない
  • 汎用コンピュータへのアクセス権を前提とし、特殊ツールより汎用ツールを信頼するアプローチが核心

今後の展望

  • Agent Skillsは初期プラグインの理想を現実化
    • モデルが十分に賢くなり、汎用ツールと指示だけで作業を実行可能に
  • エージェントは単なるLLMループではなく、コンピュータと結び付いた実行主体として再定義される
    • 例: Claude Code、Zo ComputerなどはLLMとコンピュータを統合した形
  • 2026年以降、LLMアプリケーションはコンピュータ内蔵型エージェント構造へ広がると予想
  • 結論として、複雑なプロトコル（MCP）より自然言語ベースの拡張が再び中心へ戻る可能性がある

関連記事

1件のコメント

 
GN⁺ 2025-11-28
Hacker Newsの意見

  • 自然言語は曖昧すぎるので、これをプログラミング言語として拡張するのは非効率だと思う
    数学が独自のドメイン特化言語を持っているのは、まさに明確さを確保するためだ

    • 以前テクニカルコミュニケーションの仕事をしていたが、自然言語も反復的な読み取り–修正–再確認ループを経ればかなり精密に磨き上げられる
      英語では面倒だが、慣れれば曖昧さを減らせる
    • だから、仕様を段階的に強化していくprogressive hardeningが必要だと思う
      関連する概念はこの文書によく整理されている

  • SkillsはChatGPT Pluginsの夢を現実にした概念だと思う
    いまやモデルが十分賢くなり、実際に機能しうる段階に来たように思える
    Simon Willisonもこの記事で、SkillsはMCPより大きな変化だと主張していたが、まだMCPの慣性のせいで注目は薄いようだ

    • Skillsがあまり面白く見えないのは、実質的には選択的にロードされるドキュメントに近いからだ
      しかし、MCPが要求する複雑な足場組みを取り除くという点では、はるかに大きな意味がある
      たとえばFathomアカウントの文字起こしを処理するときは、CLIスクリプトを作ってSKILL.mdを書くだけで済んだ
      クライアントAPIのテストも同じやり方で解決した
      ただ、このアプローチは派手さに欠け、大規模なツーリングを作る余地も少ないので、あまり注目されないのだと思う
    • 最近はLLM疲れが強く、人々がSkillsにあまり興奮しないのだと思う
      しかもSkillsは任意コードを実行できるエージェントを前提としているので、参入障壁が高い
    • Skillsディレクトリの何が特別なのか、まだよく分からない
      以前からClaude Codeに「Xを読んでYをして」と頼んでいたが、それがSkillsと何が違うのか気になる
    • Claude Skillsのサンドボックス実行は非効率すぎる
      I/Oやprint文に頼って作業を追跡しなければならず、もどかしい
    • SkillsはMCPのエンドユーザー版のように見える
      MCPはシステム構築用で、SkillsはClaude専用だからロックインが強い
      スキル間の参照や組み合わせができないのも大きな制約だ
      結局、拡張性・再利用性・リモート利用といった問題を解こうとすると、またMCPに戻ってきそうだ
      ただ、SkillsがMCPの別の見方として定着するなら、将来的にはSkill→MCP変換器のようなものが出てくるかもしれない

  • モデルが改善されたことがBitter Lessonとどう関係するのか分からない
    依然として人間の専門性を注入してモデルの限界を補っている構図だ
    本当のBitter Lessonなら、人間の介入なしに計算資源だけを増やしてより良い結果を出す場合だろう

    • 自分もそれが記事のテーマだと思ってクリックした

  • Custom GPTsは古い概念だが、最近実用的な使い道を見つけた
    妻の会議記録とToDo管理用にNotion APIをつないだCustom GPTを作ったところ、数時間でかなり有用に動いた
    Remindersアプリとも連携しようとしたが、APIの制約とUI権限の問題で、結局MCPサーバーを自作しなければならなかった
    古いMacBook ProでAmphetamineを有効にし、TailnetとCloudflareトンネルでつないで、ChatGPTからアクセスできるようにした
    複雑ではあるが、AIエージェントを1つの中心ハブにするのはかなり価値があった
    関連実装はこのブログにまとめられている

  • ChatGPT 5.1も相変わらず存在しないAPIを幻覚するが、それでも少しずつ良くなっている
    人類が情報処理能力を改善するたびに世界が変わってきたように、LLMが正答確率を上げるだけでも世界はまた変わるだろう

  • 「MCPを空売りしたい」という言葉には共感する
    MCPは扱いづらいが、世の中には安全なインターフェースが必要な作業が多い
    初期設計が複雑だったのは、ストリーミングトークン処理の現実をそのまま露出していたからだ
    複雑ではあるが、依然として動作可能な単純システムの境界線にあると思う
    完全に置き換えられることはなく、モデルがエージェント環境をきちんと扱うには、MCPのような構造はしばらく必要だろう

    • MCPは結局もう1つの自己記述型APIフォーマットにすぎない
      最近のモデルは単純なAPI説明だけでも十分に相互作用できる
      すでにAPIがあるなら、わざわざMCPサーバーを作る理由は薄れる
    • MCPが難しいという話は理解できない
      実装は単純なJSON-RPC + APIレベルだ
      Python FastMCPのhello-world例はFlask版とほとんど同じだ
    • MCPは時期尚早だったように思う
      Skillsはその反動として登場し、今後はLLM空間とコード空間が自己組立てされる構造へ発展していくのではないか
    • MCPはまた1つのミドルウェア物語にすぎず、こういうものはいつも失敗してきた

  • Skills.mdも結局、MCPのようにコンテキスト肥大化の問題を抱えそうだ
    むしろ説明なしでスクリプトだけ置いて、LLMがフォルダ内で必要なものを検索するよう学習させたほうがよい

    • これは解決可能なエンジニアリング問題だと思う
      たとえば、スキルを読んで選択する軽量サブエージェントを置けばよい

  • 今月発表されたChatGPT Appsは、3年前のChatGPT Pluginとほとんど同じに感じる
    違いはプラグインの呼び出し方だけだ——以前はドロップダウンで選んでいたが、今はプロンプトに名前を入れるだけでいい
    ユーザーの立場からすると大きな違いはないように見える

  • プロンプトを確率的プログラムとして捉え、それを呼び出す専用シェルが必要だと思う
    Claude CodeやCodexのようなコーディングエージェントがその例だ
    こうした機能をIDEから切り離し、llm-doのような独立シェルへ発展させることを研究している

  • LLM拡張の本当の核心はシェル統合だ
    シェルとつながったLLMは、実質的に何でもできる

    • スプーンでもプールを掘ることはできるが、私はバックホー(backhoe) を使うほうがよいと思う