AI/LLM

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 ツール定義などが既に占有しているため、実質的に使える容量は限られています。 ...

dotenvx で暗号化、1Password CLI で注入 — .env 平文ゼロのローカル開発環境を構築する @higa_toshiki 氏のポストが、ローカル開発で .env の平文を排除する実践的な手法を紹介しています（いいね 217、ブックマーク 255）。 ローカルに.envの平文を置きたくないけど、ローカルで開発したいこともあるので、 dotenvxで.envを暗号化 1 password cli で key を注入する を使ってます。 （元木さんの言うように「秘密情報の平文はクラウドに置こう」に則る形） 引用元の @swarm_ai_cloud 氏のポストでは、AI CLI の .env 読み込み防止機能への疑問が呈されています。 AI のCLIには.env読まない仕様があるって？そんなん信用できるか？AI CLIはバージョンが上がればバグが混入し弾くファイル設定していても普通に読んだりするし Claude Code が .env ファイルを自動的に読み込むことが確認されている今、「deny ルールで防ぐ」だけでは不十分という指摘は的を射ています。本記事では、higa 氏が紹介する2つのツール — dotenvx と 1Password CLI — の仕組みと実践的なセットアップ手順を解説します。 2つのアプローチの組み合わせ higa 氏のワークフローは、2つの異なるアプローチを組み合わせています。 ツール アプローチ 何を守るか dotenvx .env ファイル自体を暗号化 ファイルを読まれても平文が漏れない 1Password CLI クラウド Vault からランタイム注入 そもそもファイルにシークレットを置かない [dotenvx のアプローチ] .env（暗号化済み）→ dotenvx run → 復号してプロセスに注入 → .env.keys（秘密鍵）が必要 → Git にコミット可能 [1Password CLI のアプローチ] 1Password Vault（クラウド）→ op run → プロセスに注入 → Touch ID / マスターパスワードで認証 → ディスクに平文が一切残らない 両者は排他的ではなく、用途に応じて使い分けるのが現実的です。 ...

dotenvx・lkr・aws-vault・1Password CLI — .env 代替ツール4種の選び方とベストプラクティス AI エージェントが .env ファイルを読み取るリスクが現実のものとなり、平文の .env を代替するツールが続々と登場しています。本シリーズでは aws-vault、lkr、dotenvx + 1Password CLI をそれぞれ解説してきました。 しかし「結局どれを使えばいいのか」という疑問が残ります。本記事では、4つのツールの守備範囲・強み・限界を比較し、チーム構成や開発環境に応じた選択指針を提示します。 4ツールの守備範囲 最も重要な違いは管理対象の範囲です。 ツール 管理対象 DB接続 SaaS キー LLM API キー AWS 認証 aws-vault AWS 認証情報のみ - - - 対応 lkr LLM API キー（8社） - - 対応 - dotenvx .env に書ける全て 対応 対応 対応 対応 1Password CLI 全種類 対応 対応 対応 対応 aws-vault と lkr は特定領域に特化したツールです。.env に含まれる全てのシークレットをカバーするには、dotenvx か 1Password CLI が必要になります。 各ツールの強みと弱み aws-vault 1 $ aws-vault exec dev -- python manage.py runserver 強み 弱み STS 一時認証（15分〜で自動失効） AWS 認証情報しか管理できない AssumeRole による権限分離 macOS 限定（Keychain 依存） MFA 統合 チーム共有不可 漏洩しても短時間で無効化される 最大の強みは STS による一時認証です。他のどのツールも「漏洩しても自動で失効する」認証情報は提供できません。aws-vault が発行する一時認証情報は、仮に AI エージェントに読まれても最短15分で失効します。 ...

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 に限定されないマルチエージェント監視ツールへの進化が見えます。 ...

個人のファインチューニング済みモデルを P2P で相互利用する — 分散 MoE で「みんなの AI」は成立するか 先の記事「オープンソース AI は『無料』でも『民主化』でもない」で取り上げた Dario Amodei の指摘 — 推論には高価な計算資源が必要であり、重みの公開だけでは真の民主化にならない — に対して、興味深い反論の構想があります。 Qwen 3.5 のような軽量モデルを各個人が自分のドメインでファインチューニングし、P2P ネットワークで互いのエージェントに相互利用させれば、大規模 LLM と同等の仕組みを分散的に構築できるのではないか? この構想を技術的に検証します。 構想の全体像 — 分散 Mixture of Experts この発想は、商用 LLM の内部で使われている Mixture of Experts（MoE） アーキテクチャを、P2P ネットワーク上に展開したものと捉えることができます。 個人A: Qwen 3.5 (法律ドメインでファインチューニング) 個人B: Qwen 3.5 (医療ドメインでファインチューニング) 個人C: Qwen 3.5 (プログラミング特化) 個人D: Qwen 3.5 (会計・税務特化) 個人E: Qwen 3.5 (マーケティング特化) ↓ P2P ルーティングレイヤー（質問の性質に応じて最適なノードを選択） ↓ エージェントが複数の専門モデルを横断的に活用 商用 LLM が「1 つの巨大なモデル内でエキスパートを切り替える」のに対し、この構想は「ネットワーク上の独立した専門モデルを切り替える」アプローチです。 なぜ今この構想が現実味を帯びているのか 3 つの技術的な進歩が、この構想を「空想」から「検討に値する」レベルに引き上げています。 ...

「ブラック・スワン」著者タレブ氏がソフトウェア業界の破綻を警告 — AI 主導相場の脆弱性とテールリスクの構造的過小評価 GOROman 氏（@goroman）のポストで、Bloomberg の記事が紹介されていました。ベストセラー「ブラック・スワン」の著者ナシーム・ニコラス・タレブ氏が、AI 主導の株式相場がより脆弱な局面に入りつつあるとして、ソフトウェア分野での破綻と変動性の一段の高まりに備えるべきだと投資家に警鐘を鳴らした内容です。 ブラック・スワン著者タレブ氏、ソフト業界の破綻と変動拡大に警鐘 — @goroman タレブ氏の警告 — SeaFair での発言 タレブ氏は 2026 年 2 月、マイアミで開催された Universa Investments 主催の SeaFair イベントで発言しました。主要な論点は以下の通りです。 テールリスクの構造的過小評価 タレブ氏は「セクター全体にわたるテールリスクは構造的に過小評価されている」と指摘しました。市場が構造的リスクを過小評価する一方で、現在の AI 分野の主導企業の持続力を過大評価しているという見方です。 「リスクは小幅な調整ではない。大幅な下落だ」とタレブ氏は語っています。 ソフトウェア業界の破綻リスク 「AI で大きな利益を得る企業は出てくる」としながらも、それが現在の AI 相場を構成する企業である保証はないと指摘しました。技術の不安定さ、激しい競争、地政学の変化が業界構造を塗り替える中で、ソフトウェア分野の一部で破綻が起きる可能性が高いとの見方を示しています。 歴史を振り返れば、初期の先駆者が後に取って代わられる例は少なくありません。タレブ氏は「過去数年間の市場リーダーの利益の多くは、次の勝者が出現するにつれて消し去られるだろう」と予測しています。 AI 相場の集中リスク ここ数年の株高は、AI 関連の限られた銘柄群がけん引してきました。この集中は、主導銘柄が入れ替わった場合に指数全体を脆弱にします。タレブ氏の警告は、ナスダックの「マグニフィセント・セブン」への集中度合いを考えると、より現実味を帯びます。 ブラック・スワンと反脆弱性 — タレブ理論の背景 タレブ氏の警告を理解するには、彼の理論的枠組みを知ることが重要です。 ブラック・スワン理論 「ブラック・スワン」とは、事前にほとんど予想できず、発生した場合の衝撃が極めて大きい事象を指します。タレブ氏が 2006 年に刊行した同名の著書で提唱した概念です。特徴は以下の 3 つです。 予測困難性: 通常の予測の範囲外にある 甚大な影響: 発生した場合の衝撃が計り知れない 事後的な説明可能性: 発生後には「予測可能だった」と後付けで説明される 反脆弱性（アンチフラジャイル） タレブ氏の後続作品『反脆弱性』で提唱された概念です。「頑健」が衝撃に耐えることを意味するのに対し、「反脆弱」はショックを受けることでかえって強化される性質を指します。変動性やランダム性にさらされると成長・繁栄するシステムです。 これは現在のソフトウェア業界への示唆にも繋がります。AI の台頭という衝撃に対して、壊れる企業（脆弱）と適応する企業（反脆弱）に分かれるというのが、タレブ的な見方です。 テールリスク・ヘッジ タレブ氏は「常にヘッジが必要だ」と述べています。彼がアドバイザーを務める Universa Investments は、テールリスク・ヘッジ戦略を専門とするファンドです。市場危機時に不均衡に利益を得る設計になっており、昨年は投下資本に対して年平均 100% 超のリターンを達成しました。 市場データが示す兆候 タレブ氏の発言は、直近の市場データにも裏付けられています。 指標 数値 S&P 500（2 月 23 日） 約 1% 下落 金価格（2025 年 10 月〜） 約 30% 上昇 Universa のリターン（2025 年） 年平均 100% 超 金価格の上昇は、株式市場の不安定さと地政学的緊張の高まりに対する逃避先として金が選好されていることを示しています。 ...

AIエージェントの勝負所は「モデル性能」ではなく「ハーネス設計」にある はじめに 2026年に入り、AIエージェント開発の世界で急速に広まっている概念がある。「Agent Harness（エージェント・ハーネス）」 だ。 LLMの性能は日々向上し、Claude Opus 4.6、GPT-5、Gemini 2.5 Pro といったモデルが次々とリリースされている。しかし、現場のエンジニアたちは気づき始めている——同じモデルを使っていても、エージェントの体感品質はまるで別物になるということに。その差を生むのがモデルの「外側」にある仕組み、すなわちAgent Harnessである。 この記事では、Philipp SchmidのAgent Harness論、Lance MartinのContext Engineering解説、そしてManusの実装例を手がかりに、エージェント開発の新しいパラダイムを整理する。 Agent Harness・AIエージェント・LLM の関係 まず、3つの概念の関係を整理する。混乱しやすいのは、これらが入れ子構造になっているからだ。 レイヤー構造 graph TB subgraph UserLayer["ユーザー"] U["指示を出す / 結果を受け取る"] end subgraph AgentLayer["AIエージェント = アプリケーション層"] A1["ユーザー固有のロジック・目的"] A2["例: コードアシスタント、リサーチエージェント、カスタマーサポートBot"] end subgraph HarnessLayer["Agent Harness = OS層"] H1["コンテキスト管理 / ツール実行 / 権限制御"] H2["メモリ管理 / 再試行 / フォールバック / 承認ポイント"] end subgraph LLMLayer["LLM = CPU層"] L1["言語理解・推論・生成"] L2["例: Claude Opus 4.6, GPT-5, Gemini"] end UserLayer --> AgentLayer AgentLayer --> HarnessLayer HarnessLayer --> LLMLayer Philipp Schmidのコンピュータの比喩を使うと： ...

AIコーディングツール導入でMCC乗っ取り被害 — Antigravity・Claude Codeの脆弱性とシャドーAI対策 広告運用の現場に衝撃が走っています。広告の裏側(@hassii_ad)氏のポストによると、ある代理店がAIコンサルの支援で Claude Code と Google Antigravity を導入した結果、Google Ads の MCC（マネージャークライアントセンター）アカウントが乗っ取られ、被害額は8桁後半に達したとのことです。 知り合いの代理店がとあるAI導入したらMCCが乗っ取られて桁違いの損害でてて震えた。こういうのこれから増えそうですね。 — 広告の裏側(@hassii_ad) 2026年2月17日 この事態を受けて、まな(@ADHDHSP249834)氏は「AIコンサルがClaude CodeとAntigravityの導入を進めたんですかね？その時点で大問題です」と指摘しています。 基本は3大LLMとCopilot程度に止めるべきです。またシャドーAI対策を進めていなかったことも想定されますね。セキュリティ対策をせずに、ローカルファイルにアクセスできるAIツールを導入するのはNGです！ — まな(@ADHDHSP249834) MCC乗っ取りの推定原因 @hassii_ad 氏は乗っ取りの原因として4つの可能性を挙げています。 原因 概要 悪意あるWebサイト指示 プロンプトインジェクションによりAIの動作を乗っ取る 配布プロンプトへの悪意ある指示混入 AIコンサルまたは社員が使用したプロンプトに仕込まれた攻撃 MCPツールの悪用 Model Context Protocol ツールを経由した不正操作 トークン流出 自動化過程でAPIトークンや認証情報が漏洩 特に深刻なのは、MCCが正規の権限で操作された場合、通常の操作と区別がつかず「補償は絶望的」という点です。Google Ads の MCC アカウントは複数の広告アカウントを一元管理する仕組みのため、一度乗っ取られると被害が連鎖的に広がります。 Google Ads のセーフガードはなぜ機能しなかったのか Google Ads には予算制限やセキュリティ機能が存在しますが、正規権限で操作された場合にはほとんど機能しません。 既存のセーフガード一覧 機能 内容 乗っ取り時に有効か 日予算の上限 1日の費用は日予算の2倍まで 攻撃者が日予算自体を変更可能 月間費用上限 月間費用は日予算 x 30.4 まで 同上 アカウント予算 アカウント全体の費用上限を設定可能。上限到達で全広告停止 攻撃者が上限を変更・解除可能 異常な予算変更の確認 大幅な予算変更時（例: $100→$1,000）に確認ダイアログ表示 UI操作のみ。API経由なら確認なし 不審なアクティビティの検知 Google が異常を検知すると一時的な日次支出制限を適用 「正規権限」の操作は異常と判定されにくい 自動ルール 一定額到達でキャンペーンを一時停止するルール設定が可能 攻撃者がルール自体を削除可能 セーフガードが無力化される理由 今回の事件の核心は、攻撃者が MCC の正規の管理者権限を取得している点です。 ...

Backlog 問い合わせ課題を Claude で自動分析してコメント投稿する構成 Backlog を問い合わせ管理に使っていると、課題が登録されるたびに内容を確認し、分類や初期対応を行う作業が発生します。この作業を Claude に任せ、課題が追加された瞬間に自動で分析コメントを投稿する仕組みを構築します。 全体構成 ┌──────────┐ Webhook ┌─────────────┐ invoke ┌──────────┐ │ Backlog │ ──── JSON ────→ │ API Gateway │ ────────────→ │ Lambda │ │ (課題追加) │ │ │ │ (受信) │ └──────────┘ └─────────────┘ └────┬─────┘ │ SQS enqueue │ ▼ ┌──────────┐ コメント投稿 ┌─────────────┐ Claude API ┌──────────┐ │ Backlog │ ◀── POST ────── │ Lambda │ ◀──────────── │ Amazon │ │ (課題) │ │ (処理) │ │ Bedrock │ └──────────┘ └─────────────┘ └──────────┘ なぜ 2 段構成（Lambda + SQS）なのか Backlog の Webhook は 10 秒以内に HTTP 200 を返さないとタイムアウトし、失敗として再送を繰り返します。Claude の分析には数十秒かかるため、受信 Lambda は即座に 200 を返し、SQS を介して処理 Lambda に非同期で委譲します。 ...