Mcp

Claude Code に「目」を与える — ローカル VLM で画像・動画をコンテキスト消費ゼロで理解させる @ShadeLurk 氏が X で公開した記事が注目を集めています。 Claude Code に「目」を作る — コンテキストを 1 トークンも使わずに動画を理解させる方法 Claude Code で画像や動画を扱うと、1 枚あたり数千トークンがコンテキストから消えます。ローカル VLM（Qwen3-VL 等）を MCP サーバー経由で接続し、画像処理をオフロードすることで、Claude Code のコンテキストを一切消費せずにビジュアル情報を扱う手法が提案されています。本記事では、この問題の構造と解決アプローチを技術的に解説します。 問題 — 画像 1 枚で数千トークンが消える Claude のビジョン処理とトークン消費 Claude API でのビジョン処理は、画像をトークンに変換してコンテキストウィンドウに載せる仕組みです。Anthropic の公式ドキュメントによると、トークン消費量は以下の式で算出されます。 tokens = (width px × height px) / 750 画像サイズ トークン数 1,000 枚あたりのコスト 200x200 px（0.04 MP） 約 54 約 $0.16 1000x1000 px（1 MP） 約 1,334 約 $4.00 1092x1092 px（1.19 MP） 約 1,590 約 $4.80 1 枚の高解像度スクリーンショットで 約 1,600 トークンが消費されます。Claude Code のコンテキストウィンドウは約 200,000 トークンですが、システムプロンプト・CLAUDE.md・会話履歴・MCP ツール定義などが既に占有しているため、実質的に使える容量は限られています。 ...

MCP サーバーを増やしてもコンテキストを食わせない — Claude Code の Tool Search でトークン消費を95%削減 @djrio_vr 氏のポストが、Claude Code の MCP Tool Search 機能を紹介し、大きな反響を呼んでいます（いいね 418、ブックマーク 522）。 Claude Codeで登録してるMCPサーバが増えてくるとコンテキストがかなり食われてたけど、Tool Searchという必要な時だけ動的ロードするオプションをONにしたらめちゃくちゃコンテキスト節約になった！ 環境変数 ENABLE_TOOL_SEARCH=true と設定するだけ MCP サーバーを複数接続していると、会話を始める前からコンテキストウィンドウの大部分が消費されてしまう問題は、多くの Claude Code ユーザーが直面していました。本記事では、この問題の構造と Tool Search による解決策を技術的に解説します。 MCP ツール定義がコンテキストを圧迫する構造 なぜ MCP サーバーを増やすとコンテキストが減るのか Claude Code に MCP サーバーを接続すると、各サーバーが提供する全てのツール定義がコンテキストウィンドウに読み込まれます。ツール定義には、ツール名、説明文、JSON スキーマ（パラメータの型・制約・説明）が含まれており、1つのツールだけでも数百トークンを消費します。 [MCP サーバー接続時のコンテキスト構造] システムプロンプト ～数千トークン ├── Claude Code の指示 ├── CLAUDE.md の内容 └── ユーザー設定 ツール定義 ★ ここが問題 ├── 組み込みツール（Read, Edit, Bash 等） ├── MCP サーバー A のツール × 10個 ├── MCP サーバー B のツール × 15個 ├── MCP サーバー C のツール × 20個 └── ... 会話履歴 ← 残りがここに使われる ├── ユーザーのメッセージ └── Claude の応答 具体的な数値 GitHub Issue #3036 では、約20個の MCP サーバーを接続した環境で、開始時点からコンテキスト使用率が8〜18%に達し、わずか5プロンプトで100%に到達する現象が報告されています。 ...

Readout — Claude Code の開発環境をリアルタイム監視する macOS ネイティブアプリと「エージェント監視」カテゴリの台頭 まさお@AI駆動開発(@AI_masaou)氏のポストが注目を集めています。168いいね、242ブックマークという反響は、Claude Code ユーザーが「セッション管理」と「コスト把握」に強い課題感を持っていることを示しています。 Claude Codeを日常的に使っているなら、これは知っておいたほうがいい。『Readout』— Claude Codeの開発環境をリアルタイム監視するmacOSネイティブアプリ。完全ローカル動作、アカウント不要、無料 — まさお@AI駆動開発(@AI_masaou) 紹介されている Readout は、開発者 Benji Taylor(@benjitaylor) が「自分のために作った道具」です。2026年2月27日の公開からわずか数日で英語圏・日本語圏・中国語圏に同時に広まり、AIエージェント監視という新しいツールカテゴリの勃興を象徴する存在になっています。 Readout の概要 Readout は macOS Tahoe 向けのネイティブアプリ（v0.0.6 Beta、19.8MB）です。Claude Code のセッションログをローカルで読み取り、開発環境の状態を一つのダッシュボードに集約します。 主要機能 機能 説明 リポジトリ状態 Git ブランチ、変更ファイル、ワークツリーの一覧 セッション履歴 過去の Claude Code セッションを一覧表示 APIコスト追跡 トークン消費量と推定コストのリアルタイム表示 依存関係 プロジェクトの依存パッケージの状態 設定ファイル CLAUDE.md、MCP 設定の一覧 ポート使用状況 開発サーバーのポート占有状態 セッションリプレイ Benji Taylor氏のアナウンスによると、セッションリプレイは Readout の最も注目される機能です。過去の Claude Code セッションをタイムラインで完全再生でき、以下の操作が可能です。 プロンプト、ツール呼び出し、ファイル変更を時系列で表示 再生速度の変更やステップ実行 ファイル編集時のリアルタイムハイライト これは「Claude Code が何をしたか」を事後検証するためのツールであり、セキュリティ監査やコードレビューの観点からも有用です。 Assistant 機能 バックグラウンドで開発環境をスキャンし、その情報をベースにインタラクティブな対話が可能です。ワークツリーのクリーンアップや衛生管理の修正といったアクションも実行できます。応答はリッチなコンテンツカードで表示されます。 Codex 対応 v0.0.7 で OpenAI Codex のセッション監視にも対応しました。Claude Code に限定されないマルチエージェント監視ツールへの進化が見えます。 ...

ハーネスエンジニアリング入門 — AIエージェントの性能はモデルではなく「周辺設計」で決まる 朱雀氏のポストが、Claude Code や Codex の仕組みを理解するうえで「ハーネス」の概念が重要だと紹介しています。2026 年に入り、AI エージェント開発の焦点は「どのモデルを使うか」から「モデルの周囲をどう設計するか」に移りました。この周辺設計を指す言葉がハーネスエンジニアリングです。 Claude CodeやCodexの仕組みを詳しく理解したい人にはこれがおすすめ。「ハーネス」について詳しく解説してくれている。 ハーネスとは何か ハーネスとは、AI モデルを囲む運用インフラのことです。Phil Schmid 氏の解説では、コンピュータに例えて次のように整理しています。 コンピュータ エージェント CPU モデル（推論エンジン） RAM コンテキストウィンドウ（作業メモリ） OS ハーネス（コンテキスト管理、ツール処理、起動シーケンス） アプリケーション エージェント（ユーザー固有のロジック） モデルが CPU なら、ハーネスは OS です。どれだけ高性能な CPU を積んでも、OS が貧弱では実用的なアプリケーションは動きません。 具体的には、ハーネスは以下の要素を管理します。 会話・コンテキスト管理: セッション間の記憶、コンテキストウィンドウの最適化 ツール呼び出し層: MCP/SDK ツールの提供と制御 権限管理: 実行可能な操作の制御 セッション・ファイルシステム状態: 作業ディレクトリ、Git 状態の管理 ループ制御・エラーハンドリング: リトライ、ガードレール、検証 観測性: ログ、メトリクス、テレメトリ モデルではなくハーネスが性能を決める 2026 年に入ってから、ハーネスの重要性を示す数値データが相次いで公開されています。 ハーネス変更だけで性能が 10 倍に ベンチマーク結果によると、ツール形式を変えただけで 15 モデルすべてのスコアが改善しました。最も劇的だったのは Grok Code Fast 1 で、6.7% から 68.3% に跳ね上がり約 10 倍でした。モデルの重みには一切手を加えていません。 同じモデルでもスキャフォールドで倍近い差 Claude Opus 4.5 は、あるスキャフォールドで 42%、別のスキャフォールドで 78% を達成しました。同じモデルでも、ハーネスの設計次第で性能が倍近く変わります。 ...

MCP のトークン消費問題 — スキーマ注入で 55,000 トークン、CLI は 35 倍効率的 Claude Code や OpenClaw で MCP（Model Context Protocol）を使っている方に知ってほしい事実があります。MCP はスキーマ注入だけで数万トークンを消費しており、同じタスクを CLI 経由で実行すると 35 倍効率的 になるケースがあるのです。 @SuguruKun_ai さんのポスト と @shinzizm2 さんのポスト でこの問題が指摘され、大きな反響を呼びました。 MCP のトークン消費問題とは スキーマ注入の仕組み MCP サーバーを接続すると、ツール定義（スキーマ）がシステムプロンプトに注入されます。これは AI が「どんなツールを使えるか」を理解するために必要な情報ですが、この定義自体が大量のトークンを消費します。 MCP サーバー接続時の処理: 1. tools/list でツール一覧を取得 2. 各ツールの名前、説明、パラメータ定義を取得 3. 全てのスキーマをプロンプトに注入 ← ここで大量消費 4. ユーザーの質問に回答 あなたが何も入力する前に、スキーマだけでトークンが消費されているのです。 具体的な数値 MCP サーバー ツール数 トークン消費量 GitHub MCP サーバー 93 ツール 約 55,000 トークン Notion サーバー 15+ ツール 約 8,000 トークン ファイルシステム 10 ツール 約 4,000 トークン 平均的なツール定義 1 ツール 300〜600 トークン GitHub MCP サーバーの場合、93 ツール分のスキーマには owner、repo、title 等のプロパティ定義、required フィールド、入出力スキーマが全て含まれます。 ...

Sentry を Claude Code で置き換えられるか — ランタイム計装と AI 分析の境界線 Sentry を Claude Code で置き換えられるか — ランタイム計装と AI 分析の境界線 エラー監視ツール Sentry が提供する機能の多くは、Claude Code のようなAI コーディングエージェントで代替できるのではないか — LLM の分析能力が向上した2026年、この疑問は自然なものです。 結論から言えば、分析レイヤーは Claude Code で代替可能（むしろ得意）であり、データ収集レイヤーもスタックがパターン化されていれば自前の共通ライブラリで実装可能です。この境界線を正しく理解することが、最適なエラー監視体制を組む鍵になります。 エラー監視の3層構造 エラー監視は、以下の3つのレイヤーで構成されています。 エラー監視 = データ収集（ランタイム計装） + データ蓄積（基盤） + 分析（判断） レイヤー Sentry Claude Code で代替した場合 データ収集 SDK がランタイムに計装 ??? （ここが問題） データ蓄積 Sentry のイベント基盤 CloudWatch / 自前ログ基盤 分析 Seer / ダッシュボード Claude Code（MCP / バッチ） Claude Code が強力なのは右端の「分析」レイヤーです。しかし、左端の「データ収集」が貧弱だと、分析対象のデータ自体が不足します。 Claude Code で代替できる部分 1. インテリジェントグルーピング → LLM の方が得意 Sentry はフィンガープリント（スタックトレース + 例外型 + メッセージの組み合わせ）でエラーを集約します。これはルールベースのアルゴリズムです。 ...

Agent Plugins for AWS — AI コーディングエージェントに AWS の専門知識を装着する 紹介ポスト: moritalous 公式ブログ: Introducing Agent Plugins for AWS | AWS Developer Tools Blog リポジトリ: awslabs/agent-plugins はじめに 2026年2月、AWS は Agent Plugins for AWS をオープンソースで公開した。Claude Code や Cursor といった AI コーディングエージェントに AWS の専門知識を「スキル」として装着するプラグインライブラリである。 これは単なる CLI ラッパーではない。AI エージェントがアーキテクチャ設計 → コスト見積もり → IaC 生成 → デプロイまでを一貫して実行できる「AWS ドメイン能力層」を追加するもの。 従来: 開発者が AWS ドキュメントを読み → 設計を考え → CDK/CFn を書き → デプロイ 今後: 「deploy to AWS」と言うだけ → AI が全工程を実行（人間は確認・承認のみ） Agent Plugin とは何か プラグインの構成要素 Agent Plugin は4つの部品を1つのパッケージにまとめたもの。 ...

Claude Code に重大な脆弱性 — 「リポジトリを開くだけ」で任意コード実行の恐れ セキュリティ企業 Check Point が、Anthropic の AI コーディング支援ツール Claude Code に複数の重大な脆弱性を発見したと報告しました。細工されたリポジトリを開くだけで不正なコマンドが実行される恐れがあり、AI 開発ツールの信頼モデルに一石を投じる内容です。 何が起きたのか Claude Code には Hooks（ツール実行前後にシェルコマンドを自動実行する仕組み）、MCP サーバー（外部ツール連携）、環境変数の読み込みといった設定機構があります。これらが悪用されることで、未信頼のディレクトリで Claude Code を起動した際に、任意のシェルコマンド実行や Anthropic API キーの流出が可能となることが判明しました。 つまり、攻撃者が悪意ある設定ファイルを仕込んだ Git リポジトリを用意し、開発者がそれを git clone して Claude Code を起動するだけで攻撃が成立します。 報告された脆弱性 CVE-2025-59536（CVSS 8.7 / High）— コードインジェクション ツールの初期化時に自動実行を許すコードインジェクションの脆弱性です。Hooks や MCP サーバーの設定を悪用し、Claude Code が起動した瞬間に攻撃者のコマンドが実行されます。リモートコード実行（RCE）に直結する、最も深刻な問題です。 CVE-2026-21852（CVSS 5.3 / Medium）— 情報漏えい プロジェクト読み込み時に環境変数の値が外部に漏洩する可能性がある脆弱性です。Anthropic API キーなどの機密情報が窃取されると、攻撃者がそのアカウントで API を不正利用できてしまいます。 その他の脆弱性 上記 2 件以外にも、同等の深刻度を持つ欠陥が確認されています。 なぜ危険なのか — 設定ファイルが攻撃経路になる 従来のセキュリティモデルでは「コードを実行しなければ安全」という前提がありました。しかし今回の脆弱性では、設定ファイル自体が攻撃経路となります。 設定機構 通常の用途 悪用方法 Hooks ツール実行前後にシェルコマンドを自動実行 悪意あるコマンドを起動時に自動実行 MCP サーバー 外部ツールとの連携設定 偽サーバーを指定しデータを外部送信 環境変数 API キーなどの機密情報管理 設定ファイル経由で値を外部に流出 開発者が日常的に行う「リポジトリを clone して開発環境を立ち上げる」という行為自体がリスクになるという点で、VS Code の .vscode/ 設定を悪用する攻撃と同種のパターンです。ただし AI ツールはファイルシステムへの広範なアクセス権とシェルコマンドの実行権を持つため、影響はより深刻になりえます。 ...