LLM

個人のファインチューニング済みモデルを 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エージェントの勝負所は「モデル性能」ではなく「ハーネス設計」にある はじめに 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 の正規の管理者権限を取得している点です。 ...

Claude Code 時代の .env 管理 — 「平文で置かない」秘密情報の新しい守り方 @yousukezan 氏のポストが、AI 駆動開発における秘密情報管理の盲点を端的に指摘しています。 Claudeが社内に広がるほど、.envが危ない。Cowork時代に必要なのは「便利さ」より秘密情報の置き場所 引用元の Qiita 記事では、Claude Code や Cowork が「チャットで質問するだけのツール」から「ローカルファイルに直接アクセスする開発エージェント」へ進化したことで、従来の .gitignore だけでは守りきれない脅威が生まれていると論じています。本記事では、この問題の技術的背景と実践的な対策を掘り下げます。 何が変わったのか — 脅威モデルの転換 従来の開発ワークフローでは、.env ファイルの脅威モデルは明確でした。 脅威 対策 Git リポジトリへの混入 .gitignore に記載 本番環境への漏洩 環境変数やシークレットマネージャで注入 他人のマシンへの流出 ローカルに置く前提なので問題なし ところが、Claude Code のような AI エージェントがローカルファイルを直接読み書きする時代になると、第三の脅威が加わります。 新しい脅威 内容 AI エージェントによる読み取り .env がツールの入力コンテキストに載る 意図しないクラウド送信 読み取った内容が LLM の API リクエストに含まれる 組織内の横展開 Cowork で複数人が同じプロジェクトを触る際の露出 IPA「情報セキュリティ 10 大脅威 2026」でも「AI の利用をめぐるサイバーリスク」が初選出で 3 位にランクインしており、この脅威モデルの転換は業界全体の認識となりつつあります。 Claude Code は .env をどう扱うのか 自動読み込み問題 セキュリティ研究者 Dor Munis 氏の調査によると、Claude Code は .env、.env.local などのファイルを自動的に読み込み、API キーやトークンをメモリに展開していることが判明しています。プロキシ認証情報が意図せず読み込まれ、HTTP 407 エラーとプロキシ料金の異常な高騰として問題が顕在化しました。 ...

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 はフィンガープリント（スタックトレース + 例外型 + メッセージの組み合わせ）でエラーを集約します。これはルールベースのアルゴリズムです。 ...

クラウド LLM の地政学リスクが顕在化 — ローカル LLM 移行を本気で考える時 クラウド LLM の地政学リスクが顕在化 — ローカル LLM 移行を本気で考える時 2026年2月末、AI 業界に衝撃が走りました。Anthropic が米国防総省からブラックリスト指定を受け、Google の Gemini がイスラエル軍に無断提供されていた疑惑が浮上。@wmoto_ai（生ビール）さんのポストは、多くのエンジニアが感じた危機感を端的に表現しています。 「イスラエルの件、Anthropicの件然り一気に物騒になってきたので本気でローカルLLMへの移行先決めとかないとな..」 この記事では、2つの事件の背景と、クラウド LLM 依存が孕むリスクを整理します。 事件1: Anthropic vs 米国防総省 — AI 安全性を巡る全面対立 何が起きたか 2026年2月、米国防長官 Pete Hegseth は Anthropic に対し、Claude の軍事利用におけるセーフガード（安全装置）の全面撤廃を要求しました。 Anthropic が拒否したかったのは、以下の2点です。 米国民に対する大量監視 への Claude の利用 人間の関与なしに発射する自律兵器 への Claude の利用 時系列 日付 出来事 2月16日 Pentagon が Anthropic との関係見直しを示唆 2月25日 ブラックリスト化の第一歩が報道 2月26日 Hegseth が 2/27 17:01 を最終期限に設定。Anthropic CEO Dario Amodei が拒否を表明 2月27日 トランプ政権が Anthropic を「サプライチェーンリスク」に指定、政府業務から排除 2月27日 OpenAI が即座に国防総省との契約を発表 2月28日 シリコンバレー全体への影響が報道される Dario Amodei の声明 “We cannot in good conscience accede to their request.” （彼らの要求に良心に従って応じることはできない） ...

バイブコーディングでデザインを劇的に改善する方法 — UI コンポーネント名で「構造」を指示する バイブコーディングでデザインを劇的に改善する方法 — UI コンポーネント名で「構造」を指示する バイブコーディング（Vibe Coding）で AI にUIを作らせると、「動くけどダサい」「素人っぽい」という壁にぶつかる人は多いでしょう。 @7_eito_7（えいと）さんのポストは、この問題に対するシンプルかつ強力な解決策を提示しています。 「バイブコーディングでデザインを20倍よくする裏技。それはUIの種類を覚えること。2,500以上のデザイン例がまとまったThe Component Galleryでデザインの知識を増やす。そして『App Bar + Drawer + Card Grid + Tabs構成で』みたいに構造で指示するだけで一瞬でプロっぽくなる。」 核心は**「見た目」ではなく「構造」で指示する**ことです。 なぜ「きれいにして」では良いUIにならないのか バイブコーディングでよくある失敗パターンを見てみます。 ❌ 曖昧な指示: 「もっとおしゃれにして」 「プロっぽいデザインにして」 「モダンな感じで」 → AI は「統計的に平均的な」デザインを返す → 紫グラデーション、Inter フォント、角丸カードの量産（AI スロップ） ✅ 構造で指示: 「App Bar + Drawer + Card Grid + Tabs 構成で」 「Hero + 3カラム Feature Grid + Testimonial Carousel + CTA Footer で」 「Sidebar Navigation + Data Table + Filter Bar + Pagination で」 → AI はコンポーネントの「正しい組み合わせ方」を知っている → 実在のデザインシステムに基づいた構造が生成される この違いが生まれる理由は明確です。LLM の学習データには Material Design、Fluent UI、Ant Design など実在のデザインシステムのコードが大量に含まれています。コンポーネント名で指示すると、AI はそれらのデザインシステムの「正しい実装パターン」を参照して出力します。 ...

なぜ AI は同じ紫グラデーションのサイトを作るのか — 分布的収束と Skills による脱却 「AI にランディングページを作らせると、どれも同じに見える」 Inter フォント、白背景に紫グラデーション、角丸カード、3カラムのアイコン付きグリッド — いわゆる AI スロップ（AI slop） と呼ばれるこの現象には、明確な技術的原因があります。 @awakia さんのポスト では、Anthropic が公式ブログで解説した 分布的収束（Distributional Convergence） という概念と、その解決策としての Skills アプローチを紹介しています。差を生むのはモデルの性能ではなく「方向付け」だという指摘は、AI を使ったフロントエンド開発に携わる全ての人にとって重要な示唆です。 分布的収束（Distributional Convergence）とは LLM はトークンの出現確率に基づいてテキストを生成します。フロントエンドのコード生成においても同じ原理が働きます。 学習データには膨大な数の Web サイトのソースコードが含まれていますが、その中で 最も頻出する「安全な」選択肢 が統計的に支配的です。結果として、指示なしで「ランディングページを作って」と頼むと、学習データの 中央値 に収束した出力が生成されます。 なぜ「紫」なのか この疑問には具体的な答えがあります。約 5 年前、Tailwind CSS のデフォルトボタンカラーが indigo-500 に設定されました。その後、GitHub 上に大量の Tailwind チュートリアルやサンプルコードが蓄積されました。AI に制約なしで「ランディングページを作って」と指示すると、2019 年から 2024 年にかけてスクレイピングされた Tailwind CSS チュートリアルの中央値を得ることになります。そして、その中央値が紫なのです。 AI スロップの典型パターン 要素 AI スロップの典型 フォント Inter, Roboto, Arial, system fonts 配色 白背景 + 紫/インディゴグラデーション レイアウト 3カラムのカード型グリッド 角丸 控えめだが均一な rounded-lg アニメーション なし、または最小限 背景 単色（白 or 薄いグレー） これは「悪い」デザインではなく、統計的に平均的なデザインです。どのプロジェクトにも合いそうで、どのプロジェクトにも合わない — そういう出力になります。 ...

コンテキストエンジニアリング — AI を「使う人」と「使いこなす人」の違い 紹介ポスト: えいと @7_eito_7 「AIを使っている人と、本当にAIを使いこなしている人の違いは何か。結論はコンテキストエンジニアリングができるかどうか。簡単に言えば、指示の出し方ではなくどんな文脈を渡しているか。」 はじめに 2025年半ば、Shopify CEO の Tobi Lütke が次のように発言した: 「“プロンプトエンジニアリング"より"コンテキストエンジニアリング"という言葉の方がずっと好きだ。LLM がタスクを解決できるだけの十分な文脈を与える技術 — これこそが核心的スキルだ。」 AI 研究者の Andrej Karpathy もこれに同意し、「コンテキストエンジニアリング」という概念は一気に広まった。2026年現在、プロンプトエンジニアリングの時代は終わり、コンテキストエンジニアリングが AI 活用の新しい標準になりつつある。 プロンプトエンジニアリング vs コンテキストエンジニアリング 観点 プロンプトエンジニアリング コンテキストエンジニアリング スコープ 1つの入力テキストの書き方 モデルが見る情報の全体設計 焦点 指示の言い回し・構造 情報の選択・順序・形式・量 対象 単発の質疑応答 複雑な推論、マルチターン、エージェント 複雑さ 文章レベル システムレベルのパイプライン 例え 「質問の仕方を工夫する」 「解答に必要な教科書・資料・道具を揃える」 プロンプトエンジニアリングはコンテキストエンジニアリングの一部にすぎない。質問の質ではなく、AI に渡す情報の質と構造が結果を決める。 なぜプロンプトだけでは不十分なのか よくある問題: RAG で正確な情報を取得し、プロンプトも丁寧に書いた。それでも AI がハルシネーションを起こす。 原因はプロンプトでも検索でもなく、コンテキストの構造にある。 プロンプトの 3 つの限界 情報不足: 質問は完璧でも、判断に必要な背景情報が足りない 情報過多: 関連情報を全部詰め込むと、かえって精度が落ちる（ノイズに埋もれる） 情報の無秩序: 重要な情報とそうでない情報が区別なく並んでいる コンテキストエンジニアリングは、この 3 つを体系的に解決する。 コンテキストエンジニアリングの 4 つの柱 1. 構成（Composition）— 何を渡すか タスクに必要な「材料」を選択する: ...

AI は会話が長くなるほど「迷子」になる — Microsoft × Salesforce の衝撃の研究 紹介ポスト: kosuke_agos 論文: LLMs Get Lost In Multi-Turn Conversation Microsoft Research: 公式ページ はじめに 「AI と長く会話するほど、AI の知能が劣化する」— これは体感ではなく、Microsoft Research と Salesforce Research が 20万件以上の AI 会話を分析 して科学的に証明した事実である。 論文タイトルは “LLMs Get Lost In Multi-Turn Conversation”（LLM はマルチターン会話で迷子になる）。GPT-4.1、Claude 3.7 Sonnet、Gemini 2.5 Pro を含む 15 モデル全てで、会話が長くなるほど性能が劇的に低下することが明らかになった。 衝撃の数字 指標 数値 平均性能低下 39% 不安定性（unreliability）の増大 +112% 精度の変化 90% → 約 51% テストしたモデル数 15（大小問わず全て劣化） 最も重要な発見: 高性能モデルも小型モデルも、同じように劣化する。 Claude 3.7 Sonnet、Gemini 2.5 Pro、GPT-4.1 といったトップモデルでも 30〜40% の性能低下が観測された。モデルの「賢さ」では回避できない、構造的な問題であることが判明した。 研究チームと手法 著者 名前 所属 Philippe Laban Microsoft Research Hiroaki Hayashi Salesforce Research Yingbo Zhou Salesforce Research Jennifer Neville Microsoft Research テスト対象モデル（15種） OpenAI: GPT-4o-mini, GPT-4o, o3, GPT-4.1 Anthropic: Claude 3 Haiku, Claude 3.7 Sonnet Google: Gemini 2.5 Flash, Gemini 2.5 Pro Meta: Llama 3.1-8B, Llama 3.3-70B, Llama 4 Scout その他: Microsoft Phi-4, AI2 OLMo-2-13B, Deepseek-R1, Cohere Command-A Sharding（シャーディング）— 現実の会話を再現する手法 ユーザーは通常、最初から完璧な指示を出さない。 ...