AI/LLM

DeepSeek-AI が 2026 年 4 月 24 日、100 万トークンのコンテキスト長に対応したオープンソース AI モデル「DeepSeek-V4 Preview」を公開した。コーディング競技プラットフォーム Codeforces では GPT-5.4 を上回るレーティングを記録。コーディングベンチマークでは Claude Opus 4.6 にほぼ匹敵する性能を持ちながら MIT ライセンスで無償公開されるという、衝撃的なリリースとなった。 DeepSeek-V4 の概要 DeepSeek-V4 Preview は Pro と Flash の 2 バリアントで構成される。 モデル 総パラメータ数 推論時アクティブパラメータ数 DeepSeek-V4-Pro 1 兆 6,000 億 490 億 DeepSeek-V4-Flash 2,840 億 130 億 いずれも Mixture-of-Experts（MoE）アーキテクチャを採用しており、推論時には全パラメータの一部のみを活性化することで高い効率を実現している。 アーキテクチャの革新：ハイブリッドアテンション DeepSeek-V4 の技術的な目玉は「ハイブリッドアテンション機構」だ。トークン単位の圧縮と DSA（DeepSeek Sparse Attention） を組み合わせることで、前世代と比較して： 推論演算量を約 73% 削減 KV キャッシュサイズを約 90% 削減 これにより、100 万トークンという非常に長いコンテキストをより少ないリソースで扱えるようになった。実用上は長い会話履歴・大きなコードベース・長文ドキュメントを一度のプロンプトに収められるため、エージェント系ユースケースとの相性が良い。 ベンチマーク性能 Codeforces で GPT-5.4 超え コーディング競技プラットフォーム Codeforces でのレーティングは 3,206（V4-Pro）を記録し、GPT-5.4 の 3,168 を上回るスコアを達成した。コーディング能力においてオープンソースモデルとして最先端の水準に到達した形だ。 ...

Claude に本格的な検索能力を付与する MCP サーバー「Exa for Claude」が注目を集めている。Web 検索・ドキュメント・企業/人物情報など多様なソースに対応し、標準の web_search より高速・高精度とされる。Claude Desktop や Claude Code を使う開発者向けに、導入手順と活用例をまとめる。 Exa とは Exa は「将来の検索」を構築するために設立された AI 研究ラボで、ニューラル検索エンジンを提供している。キーワードマッチングではなく意味的類似性を軸にした検索で、AI エージェントが使うことを前提に設計されている。 exa-labs/exa-mcp-server（GitHub スター 4,300 超）として OSS 公開されており、Claude・Cursor・VS Code などの MCP 対応ツールから利用できる。 提供される検索ツール Exa MCP サーバーが提供する主なツールは以下の通り。 ツール 状態 用途 web_search_exa 現行 リアルタイム Web 検索 web_search_advanced_exa 現行 高度な Web 検索（カテゴリ・日付範囲・ドメイン指定など） company_research_exa Deprecated 企業サイトをクロールして詳細情報を取得 linkedin_search_exa Deprecated LinkedIn での企業・人物検索 people_search_exa Deprecated 人物情報検索 crawling_exa Deprecated 指定 URL からコンテンツを抽出（→ web_fetch_exa へ移行） get_code_context_exa Deprecated コードコンテキストの取得（→ web_search_exa へ移行） deep_researcher_start / deep_researcher_check Deprecated 非同期ディープリサーチ web_search_advanced_exa では category パラメータで論文・ニュース・コードなど用途別に絞り込める。Deprecated ツールは現在も動作するが、将来的に web_search_advanced_exa に統合される方向で整理が進んでいる。 ...

「残業は減った、納期も守れている。なのになぜか疲れている」——Claude Code をはじめとする AI コーディング支援ツールが普及した現場で、こうした状況が静かに広がっています。Zenn に投稿された ShintaroAmaike さんの記事 が、この構造的な問題を鋭く分析しています。 生産性向上の便益は誰が受け取っているか AI 駆動開発で実装速度が上がったとき、その恩恵は組織内で均等に分配されるわけではありません。 立場 受け取る便益 経営・上層部 プロジェクトが早く回る、コスト効率が改善する PM・マネジメント 仕様変更のリカバリーコストが下がり、「とりあえず作ってみる」が選択肢になる 開発者 より多くのタスクをこなすことが前提化される。やり直しの回数が増える 便益の分配が偏ること自体はどの技術革新でも起きることです。問題は、偏りに気づかないまま運用が常態化してしまうことにあります。 「時間」では測れない疲労の蓄積 従来の働き方の問題は「長時間労働」という分かりやすい指標で捕捉できました。残業時間を見れば過度な負荷が可視化できたわけです。 しかし AI 駆動開発で起きている疲労は、労働時間に現れにくい性質を持っています。 表面上は問題がなさそうに見える: 実装時間そのものは短い 残業も発生しない しかし実際には負荷が増えている: 意思決定の回数が増えている タスクの切り替え頻度が上がっている やり直しによる心理的コストが蓄積している 結果として「忙しくないはずなのに疲れている」という、従来のフレームワークでは説明しにくい状態が生まれます。 これは精神論ではなく、意思決定疲労（decision fatigue） や 文脈切り替えコスト（context switching cost） として以前から知られている現象です。AI 駆動開発はこれらを構造的に増幅する性質を持っています。 構造的に起きる「やり直し」問題 AI による実装高速化の最も見えにくい副作用は、仕様を詰めるインセンティブが失われることです。 従来は仕様変更が実装の手戻りを意味し、納期や予算に直接響いたため、上流工程で仕様を固める動機が強く働きました。AI 駆動開発では実装コストが下がるため「作ってみてから考える」が現実的な選択肢になります。その結果、上流の不備を下流が吸収する構造が生まれやすくなります。 やり直しには性質の異なる 3 種類があります: 開発者自身の理解不足によるやり直し — スキルで減らせる、経験として積み上がる 本質的な複雑性の発見によるやり直し — 避けられない、価値のある発見 上流工程の不備に起因するやり直し — 繰り返されるが、学びにつながらない 3 つ目のやり直しが増えると、開発者の疲労は「働いた時間」ではなく「報われなさ」として蓄積します。何度こなしても同じパターンの問題が繰り返される労働は、量に関係なく人を消耗させます。 評価の問題: 貢献が可視化されにくくなる もう一つ重要な課題があります。開発者の貢献が従来の指標では測りにくくなっている点です。 実装が速いため「頑張った」が時間で示しにくい AI が書いたコードの比率が上がるほど、開発者の知的貢献がぼやける 仕様変更への柔軟な対応は曖昧に評価されがち 上流の不備を吸収した労力は貢献として認識されない 「AI でやれば速いのだから、速くて当たり前」という前提が広がると、評価されるハードルだけが上がり、評価される項目は減っていきます。放置すると、割に合わないと感じた開発者から静かに離脱が起きます。しかしその原因は、労働時間のような可視化された指標には現れません。 ...

海外 AI 活用シーンで Obsidian × Claude Code の組み合わせが爆発的な注目を集めている。6本の主要記事だけで合計 1,240万 views、ブックマーク数は 8万件超え。元 OpenAI 創設メンバーの Andrej Karpathy 氏が提唱し、Obsidian CEO の Steph Ango 氏自らが AI 連携スキルを GitHub で公開。ここまで業界の中心人物が動いたツール組み合わせは、近年なかった。 本記事は東大 ClaudeCode 研究所（@ClaudeCode_UT）が公開した解説記事「【決定版】ゼロから始めるClaudeCode × Obsidianの完全解説」をベースに、その要点をまとめる。 そもそも Obsidian とは何か Obsidian は、個人向けのローカル Markdown ノートアプリだ。2020 年公開、個人利用は無料で、Mac / Windows / Linux / iOS / Android に対応している。同じノート系の Notion や Evernote とは設計思想が根本的に異なる。 ノート本体は Markdown ファイル — 各ノートは .md としてディスク上に実ファイルで存在する。独自データベースに閉じ込められない。 Vault は OS のただのフォルダ — ノートを束ねる「Vault」は普通のディレクトリ。Git でも Dropbox でも iCloud でも、好きな仕組みで同期・バックアップできる。 双方向リンク [[ノート名]] — ノート同士をリンクで繋ぎ、知識をグラフ構造として可視化できる。Zettelkasten など既存 PKM 手法の基本機能を標準で備える。 ローカルファースト — 規定ではすべて自分の PC 内に保存。クラウドに置くかどうかは利用者が選ぶ。 豊富なプラグイン — 2,000 以上のコミュニティプラグインで、PDF 注釈・タスク管理・グラフ可視化まで拡張できる。 なぜ「AI × 記憶設計」の目的に最適なのか Obsidian のこれらの特徴は、Claude Code のようなファイルシステムを直接操作する AI エージェントと噛み合う。理由は3点ある。 ...

Claude Code をコーディング支援以外の収益化ツールとして活用する事例が注目されている。本記事では、SNS 複数アカウントの自動運用×アフィリエイト収益化という活用パターンの仕組み・先行者優位の背景・実践上の注意点を整理する。 X（旧Twitter）でこの話題に火をつけたのが、AI 自動化を実践するインフルエンサーの「なおき」さん（@Naoki_GPT）のツイートだ（以下、原文ママ）。 Claude Code、金稼ぎに特化させれば余裕で月50万は超えるのになあ。うちは10個のSNSアカを自動運用でフル稼働させてアフィで稼いでもらってる。AI自動化アフィの収益性エグすぎ。 フォロワー約1.6万人のこのアカウントが投稿した内容は数時間で37万回超のインプレッションを記録し、Claude Code の「収益化活用」という視点から多くのエンジニア・マーケターの注目を集めた。 なぜ Claude Code が収益化ツールとして注目されるのか Claude Code はコードを書くための AI アシスタントとして設計されているが、その本質は 「複雑なタスクを自律的に実行するエージェント」 だ。コーディングに限らず、以下のようなタスクを自動化できる。 SNS への投稿コンテンツ生成・スケジューリング アフィリエイトリンクを含む記事の自動生成・公開 複数プラットフォームへのクロスポスト アナリティクスデータの収集・レポート生成 A/B テスト用のコンテンツバリエーション作成 なおきさんの場合、10個の SNS アカウントを Claude Code ベースの自動化システムでフル稼働させ、アフィリエイト収益を得ているという。これは単なる「コンテンツ自動投稿」ではなく、エンゲージメント分析・最適化・収益化まで一気通貫で自動化していると考えられる。 AI 自動化アフィリエイトの仕組み 一般的な「AI 自動化アフィリエイト」のフローは以下のようになる。 1. ネタ収集 RSS フィード・トレンドワード・競合アカウントの投稿を自動収集 Claude Code がトレンドを分析し、反応が取れそうなテーマを選定 2. コンテンツ生成 選定テーマに基づいて Claude Code が投稿文・画像プロンプト・ハッシュタグを生成 アフィリエイトリンクを自然な形で挿入 3. スケジュール投稿 各 SNS の最適投稿時間帯に合わせてスケジューリング X、Instagram、TikTok、YouTube Shorts など複数プラットフォームに対応 4. 分析・改善 エンゲージメント率・クリック率・収益データを収集 Claude Code がデータを分析し、次のコンテンツ戦略を自動改善 ASP が果たす役割 — エコシステム全体像 このフローの中で ASP（Affiliate Service Provider） は、広告主とメディア運営者を繋ぐ「仲介プラットフォーム」として機能する。広告主・メディア運営者・Claude Code・SNS・エンドユーザーの関係を図にすると以下のようになる。 ...

Claude Code を Anthropic の API ではなく、手元のマシンで動かすローカル LLM サーバーに接続することで、API コストをゼロにしながら最強のコーディングエージェントを使い倒せる。本記事では vLLM + MiniMax-M2.7 を組み合わせた構成を紹介する。 なぜローカル LLM で Claude Code を動かすのか 課題 解決策 API 費用が嵩む ローカル推論でコストゼロ 機密コードをクラウドに送りたくない データがマシン外に出ない レスポンスが遅い vLLM の高速推論エンジン 開発コストを抑えつつ、機密性の高いコードのデバッグや大規模リファクタリングにも安心して使える環境が手に入る。 技術スタック vLLM — OpenAI 互換 / Anthropic 互換の高速推論サーバー MiniMax-M2.7 — Claude Code との相性が高いオープンモデル（コーディング・エージェント特化） Prefix Caching — 繰り返し送信されるシステムプロンプトをキャッシュしてレイテンシをほぼゼロに vLLM で MiniMax-M2.7 を起動する 必要なハードウェア 構成 GPU メモリ KV Cache 4× GPU 96 GB × 4 400K トークン 8× GPU 144 GB × 8 3M トークン サーバー起動コマンド 4× GPU 構成（推奨）: ...

X（旧 Twitter）で話題になった Claude Code のコスト削減テクニックを紹介する。やることはシンプルで、CLAUDE.md にたった1行を追加するだけ。それだけでトークン消費が約 1/3 に減り、エラーもゼロになったという報告が注目を集めている。 plan モード強制でトークン 64% 削減の実測データ @ClaudeCode_love が2026年4月に共有したデータによれば、以下の改善が得られたとのこと。 指標 変更前 変更後 改善率 トークン消費 10.4M 3.7M 64% 削減 エラー数 10 個 0 個 100% 削減 コスト $9.21 $2.81 69% 削減 単純計算で約 3 分の 1 のコストになる。これを知っているかどうかだけで月額の Claude Code 利用コストに大きな差が出る。 CLAUDE.md への1行追加方法 CLAUDE.md に以下の1行を追加するだけ。 1 実装前に必ず plan モードで設計を出してから書け これだけで Claude Code は実装前に設計フェーズを経るようになる。 より確実に全セッションへ適用する方法 CLAUDE.md へのテキスト指示は Claude へのヒントとして機能するが、確実に plan モードをデフォルト化するには .claude/settings.json に以下を追記する方が確実。 1 2 3 { "defaultMode": "plan" } 両方を組み合わせることで、より安定した動作が期待できる。 ...

Google Cloud Next 2026 で、Google Workspace の公式 MCP サーバーがデベロッパープレビューとして発表された。Gmail・Drive・Calendar・Chat などの Workspace データを、Claude・Gemini CLI・IDE などの AI アプリから Model Context Protocol（MCP）経由で直接操作できるようになる。 これまでの課題 Workspace のデータを AI エージェントと連携させたい場合、これまでは以下の障壁があった。 公式のサポートがなく、サードパーティ製コネクターに頼るしかなかった OAuth フローの実装が複雑で、開発コストが高かった エージェントからのアクセス権限管理が整備されていなかった 公式 MCP サーバーはこれらの壁をまとめて解消する。 対応サービスと提供ツール数 サービス ツール数 主な操作 Gmail 10 メール検索・下書き作成・送信 Drive 7 ファイル取得・アップロード・検索 Calendar 8 予定作成・一覧取得・更新 People 3 連絡先の参照 Chat 2 メッセージ確認・送信 対応 AI アプリ Claude (Enterprise / Pro / Max / Team プラン) Gemini CLI VS Code などの対応 IDE MCP 標準に準拠しているため、今後 MCP 対応のアプリ・フレームワークはすべて利用できる見込み。 ...

Google の最新 MoE モデル Gemma 4 26B-A4B を、個人 PC のローカル環境で最高効率で動かせるようになりました。Unsloth が公開した GGUF 量子化版は、精度を維持しながら劇的な軽量化を実現し、2026 年 4 月時点でローカル LLM の最前線に立っています。 Gemma 4 26B-A4B とは Gemma 4 は Google が 2026 年に公開したモデルファミリーで、E2B・E4B・26B-A4B・31B の 4 サイズが提供されています。 26B-A4B の「A4B」は Active 4B（推論時に活性化するパラメータ数の目安）を意味します。Mixture-of-Experts（MoE）アーキテクチャを採用しており、モデル全体のパラメータ数は 25.2B です。しかし 1 トークン生成ごとに動かすパラメータは 3.8B 相当に絞られるため、推論速度は 4B クラスと同等になります。 指標 26B-A4B (MoE) 31B (Dense) 総パラメータ数 25.2B（モデル名は 26B） 31B 推論時アクティブパラメータ 3.8B 31B LMArena スコア (テキスト) 1441 1452 必要 VRAM (4-bit) 16〜18GB — 26B と名乗りながら推論速度は 4B クラスという驚異的な効率を実現しています。 ...

2026 年 4 月、Findy が主催したオンラインイベント「Harness Engineering 入門 〜 AI エージェントを制御するアプローチ〜」が開催された。r.kagaya 氏の登壇「エージェントの開発環境を内製して気づいた『これもハーネス』」は参加者から「レベル高すぎた」と評されるほど反響を呼んだ。本記事では、r.kagaya 氏が公開した SpeakerDeck 資料「ハーネスエンジニアリングにどう向き合うか 〜ルールファイルを超えて開発プロセスを設計する〜」をもとに、ルールファイルを超えたハーネスエンジニアリングの考え方を整理する。 イベント概要 【Harness Engineering 入門】AIエージェントを制御するアプローチ（connpass #388471）は、AI エージェントによる開発が広まる中でハーネス設計がどのような意味を持つかを掘り下げるイベント。対象は AI エージェントを積極的に使っているエンジニア、チーム開発に AI を取り込もうとしているエンジニア層だ。 複数の登壇の中で r.kagaya 氏のセッションは、自社でエージェントの開発環境を内製する過程で見えてきた「これもハーネスだ」という気づきを軸に、ルールファイル設定で終わらないハーネスエンジニアリングの本質を語った。 ルールファイルから始まるハーネスエンジニアリング 多くのエンジニアがハーネスエンジニアリングを始める入り口は CLAUDE.md などのルールファイル だ。「こういうコードを書いてほしい」「このコマンドは使わないで」といった制約を自然言語で記述し、AI の振る舞いをコントロールする。 1 2 3 4 # CLAUDE.md の例 ## Bash コマンドの必須ルール - `&&` でコマンドを繋がない - `/tmp` を使わない（`.claude/temp/` を使う） この段階では「うまく動くルールを育てる」フェーズであり、試行錯誤でルールを追加・削除していく。しかし、ここで止まってしまうと 本当の意味でのハーネスエンジニアリング には到達できない。 ルールファイルの限界 ルールファイルだけに依存したアプローチには構造的な限界がある。 課題 内容 変更の影響が不透明 あるルールを変えたとき、どの程度・どの方向に結果が変わるか測定できない 劣化の検知が困難 モデルのアップデートや使い方の変化でルールの有効性が静かに落ちる 再現性の欠如 同じルールで試しても毎回違う結果が出る場合の原因特定が難しい スケールしない チームが大きくなるほど「誰がどのルールを管理しているか」が曖昧になる ルールファイルを超えた視点：開発プロセスとして設計する r.kagaya 氏が提示したのは、ハーネスエンジニアリングを「ルールを書く行為」ではなく 「開発プロセスを設計する行為」 として捉え直す考え方だ。 ...