Llm

TL;DR Redis 作者の Salvatore Sanfilippo（antirez）が、DeepSeek V4 Flash 専用のローカル推論エンジン ds4 (DwarfStar 4) を公開した（公開から数日で 7,700+ stars） Apple Silicon の Metal と Linux の CUDA をターゲットにした C 実装。GGML/llama.cpp にはリンクせず、DeepSeek V4 Flash 一本に特化した「narrow bet」設計 公式ベンチで Mac Studio M3 Ultra 512GB / Q4 / 12k context で 26.62 token/sec、Q2 なら 96/128GB の MacBook でも動作 OpenAI 互換 + Anthropic 互換 API を持ち、Claude Code から ANTHROPIC_BASE_URL を差し替えるだけでローカルモデルとして使える KV キャッシュをディスクに永続化するなど、ローカル推論の常識を更新する設計思想が随所に光る 実運用報告では コンテキスト 100K → 1M、KV ディスク 8GB → 64GB に拡張して Think Max モードを Claude Code 上でアンロック した例も登場 きっかけ: 「ds4 凄すぎるな」というツイート きっかけは @m_sigepon 氏のツイートだった。 ...

JS エンジニア・CTO として活動する hiroppy (@about_hiroppy) 氏が、James Shore のブログ記事「You Need AI That Reduces Maintenance Costs」を紹介するツイートを投稿した。AI エージェントによってコード生産性が向上しても、保守コストが同率で削減されなければ長期的には逆効果になるという主張だ。 ツイートの要点 hiroppy 氏は次のようにまとめている。 agent の導入でコード生産性が2倍になっても、保守コストが半分にならないと長期的には逆効果になるとのこと。AI 生成コードの保守コストが増加すると、5ヶ月程度で生産性向上分が消滅し、最終的には AI 未導入時より低い状態に陥る可能性があり、AI 活用では「速度向上率 × 保守コスト削減率 = 1」を満たすことが不可欠。 James Shore の保守コストモデル Shore は開発者 50 人を想定した試算として、次のような保守コストの見積もりを提示している。 期間 保守作業の目安 初年度 1ヶ月の開発につき 10日間 の保守 翌年以降 毎年 5日間 の保守 このモデルでは、保守コストを削減しないまま開発を続けると約 2.5 年後にチームの生産性の 50% 以上が保守に費やされる状態に達する。 AI 導入が裏目に出るシナリオ 仮に AI によって開発速度が 2倍 になっても、AI 生成コードが読みにくく保守コストが同じく 2倍 になってしまった場合を考える。 次の月の保守コストは 4倍 になる 5ヶ月後には生産性向上分が消滅する それ以降は AI 未導入時より低い状態に陥る Shore は、短期的な速度向上が保守コストの累積的な増加を生み、長期的な開発負債につながる危険性を警告している。 成功の条件：速度向上率 = 保守コスト削減率 Shore が指摘する根本的な条件は、AI が生産性を向上させた割合と同じ率で保守コストを削減することだ。 ...

Andrej Karpathy が2026年4月に公開した GitHub gist「LLM Wiki」が、公開から48時間以内に5000スターを超えた。コード一行も含まない、純粋にアイデアだけを記述したドキュメントがここまで反響を呼んだ理由はシンプルだ。「RAGの次」を具体的かつ実践的に示していたからである。 RAGとの決定的な違い 多くの人がLLMとドキュメントを組み合わせるとき、最初に試みるのが RAG（Retrieval-Augmented Generation） だ。ChatGPTのファイルアップロード、NotebookLM、LangChainで構築するベクトルDB検索 — これらはすべて「質問が来たときにドキュメントから関連部分を取ってきて回答する」という設計思想に基づいている。 この方式には根本的な問題がある。知識が蓄積されない。5つのドキュメントを横断する微妙な問いに対しても、LLMは毎回ゼロから関連箇所を探し出し、推論し直す。「矛盾」も「文脈」も「先週気づいた発見」も、次の質問では消えてしまう。 LLM Wiki が提案するのは根本的に異なるアプローチだ。 LLM が incrementally に永続的な wiki を構築・維持する。新しいソースを追加するたびに、LLM はそれを読み込んで既存 wiki に統合し、エンティティページを更新し、矛盾を記録し、進化する合成の全体を強化する。知識は毎回再導出されるのではなく、一度コンパイルされてから最新に保たれる。 この「コンパイルされた知識ベース」こそが LLM Wiki の本質である。 3層アーキテクチャ LLM Wiki は3つの層で構成される。 1. Raw Sources（生ソース） 記事、論文、画像、データファイルなど自分がキュレートしたソースドキュメントの置き場。不変（immutable） — LLMはここから読むだけで決して書き換えない。これが「真実の源泉」となる。 2. The Wiki（wiki本体） LLM が生成・維持するマークダウンファイルの集合。概要、エンティティページ、概念ページ、比較、合成。この層は LLM が完全に所有 する。あなたは読む側で、LLM が書く側だ。 3. The Schema（スキーマ） CLAUDE.md（Claude Code用）や AGENTS.md（Codex用）など、LLMに wiki の構造・規約・ワークフローを伝えるドキュメント。これが LLM を「汎用チャットボット」から「規律あるwikiメンテナ」に変える鍵だ。このファイルはあなたと LLM が協力しながら進化させていく。 3つの操作 Ingest（取り込み） 新しいソースを生コレクションに追加して、LLMに処理を依頼する。LLMはソースを読み込み、重要な情報を抽出し、wikiに統合する。一つのソースが10〜15のwikiページを更新することもある。一度に大量のソースをバッチ処理することも可能だが、Karpathy 自身は「一つずつ取り込み、要約を確認しながら進める」スタイルを好むと述べている。 Query（クエリ） wikiに対して質問する。LLMは関連ページを検索・読み込み、引用付きで回答を合成する。回答の形式は問いによって変わる — マークダウンページ、比較表、Marpスライド、matplotlibグラフなど。 重要な洞察: 良い回答はwikiに新しいページとして追記できる。「あの比較をお願いした結果」「見つけた新しい接続」— これらをチャット履歴に埋もれさせるのではなく、wikiに蓄積させることで探求が複利的に積み重なる。 ...

2026 年 3 月、Anthropic は Claude Code の思考深度（thinking effort）のデフォルト値を high から medium に静かに変更した。 リリースノートには目立つ記述がなく、多くの開発者は「最近 Claude の質が落ちた気がする」と感じながら原因を見つけられずにいた。 Claude Code の開発者である Boris Cherny 氏が Hacker News でこの変更を認め、その後 AI 開発者コミュニティで 15 の重要設定がまとめられて話題になった。 本記事ではそれらを日本語で解説する。 1. 思考深度（effort level）の復元 問題： 2026 年 3 月以降、デフォルトが medium に変更された。Claude の思考回数が減り、コードの質・ツール呼び出し数・コメントの充実度すべてが低下している。 修正方法： セッション内で一時的に変更する場合は /effort high、恒久的に変更する場合はシェル設定に追記する。 1 export CLAUDE_CODE_EFFORT_LEVEL=high 本格的なコーディング作業では high または max を設定することで、2026 年 2 月以前の品質に戻せる。 2. Adaptive thinking の無効化 問題： 2026 年 2 月以降、Claude はタスクの複雑さを自己判断して推論量を動的に調整するようになった。「簡単なタスク」と判断した場合はほぼ思考せず、バグを見逃すことがある。 ...

2026年5月5日、マイアミのスタートアップ Subquadratic が、業界に衝撃を与える新LLM「SubQ」を発表した。キャッチコピーは「Claude Opus超え」。1200万トークンのコンテキスト長、競合比1,000倍のコンピュート削減、1/5以下のコスト——数字だけ見れば夢のような話だ。しかし果たして実態はどうなのか、技術的な仕組みから現時点の課題まで整理する。 SubQとは何か SubQは、Subquadratic Sparse Attention（SSA） と呼ばれる新しいアテンション機構を採用したLLMだ。開発したのはフロリダ州マイアミ拠点のスタートアップ「Subquadratic」で、CEOはJustin Dangel（5回連続起業家）、CTOはAlexander Whedon（元Meta、元TribeAI生成AI部門長）。 2017年のTransformer論文以来、すべての主要LLMはアテンション計算のコストがコンテキスト長の2乗に比例するという「二次スケーリング問題」を抱えてきた。長いコンテキストを扱おうとすると、RAGによるチャンク化・ベクトルDB検索・要約ループといった「誤魔化し」が必要になる理由がここにある。SubQはこの根本問題を解決したと主張している。 Subquadratic Sparse Attention（SSA）の仕組み 従来の密なアテンション（Dense Attention）では、あるトークンが他のすべてのトークンと比較される。コンテキスト長Nに対してコストはO(N²)となり、Nが大きくなるほど指数的に重くなる。 SSAはこれを根本から変える。各クエリトークンに対して、実際に重要な位置だけを選択し、その部分集合についてのみアテンション計算を行う仕組みだ。 標準Transformer: 全N個のトークンを全N個と比較 → コストO(N²) SSA: クエリごとに重要な位置k個を選択してアテンション計算 → O(N×k) kがNに対して十分小さければ → 実質O(N)（線形スケーリング） DeepSeekなどの既存スパースアテンション手法との違いも強調されている。DeepSeekのアプローチはアテンション計算のインデックス構築自体に二次コストが残るのに対し、SSAはその構築コストも線形に抑える設計だという。ただし詳細な技術仕様は非公開のため、この主張は現時点で独立検証できない。 主な性能指標 Subquadraticが公表している数値は以下のとおり。なお、これらはすべて同社による自社計測であり、独立検証は未実施である点に留意が必要だ。 指標 SubQ 比較対象 コンテキスト長（本番API） 100万トークン Claude Opus 4.7: 100万 コンテキスト長（研究用） 1200万トークン Opus 4.7の12倍 速度（1Mトークン時） FlashAttention比 52倍高速 — スループット 150 tokens/秒 — コスト（1Mトークン処理） 約$8 最先端モデル: 約$2,600 コンピュート削減（12Mトークン） 競合比 約1,000倍削減 — コスト面では「Claude Opusの約1/5」と説明されており、長文コンテキスト処理において経済的に圧倒的な優位性を主張している。 ベンチマーク結果 長文コンテキスト評価として注目されているのが MRCR v2（Multi-needle Retrieval and Context Reasoning）だ。複数の情報を長いコンテキストから正確に取り出す能力を測るベンチマークで、長文処理の実力差が出やすい。 ...

AIを使ったソフトウェア開発が急速に普及する中、「バイブコーディング」と「エージェンティックエンジニアリング」という2つのアプローチの境界線が曖昧になりつつある。Simon Willisonがこの問題を鋭く考察した記事が話題を呼んでいる。 バイブコーディングとエージェンティックエンジニアリングとは AI開発の文脈で、2種類のアプローチが対比されることが多い。 バイブコーディング（Vibe Coding） コードを深く読み込まず、AIの出力をそのまま使う開発スタイル。主に個人プロジェクトや試作品向けとされてきた。コードの内容を理解しなくても動くものが作れる、いわば「感覚」で進める手法だ。 エージェンティックエンジニアリング（Agentic Engineering） AIを強力なツールとして活用しつつ、プロのエンジニアが責任を持ってコードをレビューし、本番環境に耐えうるシステムを構築するアプローチ。品質・セキュリティ・保守性への意識が高い。 以前は「バイブコーディング＝個人・試作」「エージェンティックエンジニアリング＝本番」と明確に区別できた。しかし、AIの性能向上により、その境界線が揺らいでいる。 「もうコードを一行ずつ読まなくなった」という告白 Simon Willisonは自身の経験として、本番向けのコードでさえ、AIが書いたものを一行ずつレビューしなくなってきていると率直に認めている。 Willisonはこう述べる。Claude Codeに「JSON APIエンドポイントを作って」と頼めば、正しく実装してくれる——それはもう分かっている、と。 これは、大企業で別チームが開発した機能を、中身をほとんど確認せずそのまま使う感覚に近い。AIをある種のブラックボックスとして扱い始めているということを意味する。 人間のチームとの違いは「責任」にある。別チームの開発物には担当者がいて、問題が起きれば責任を取る人間が存在する。しかしAIには責任を取る能力がない。この非対称性が、Willisonに居心地の悪さを感じさせる根本的な理由だ。 AIの信頼が油断を生む 問題はさらに深い。AIが問題なくコードを書き続けることで「このAIは信頼できる」という過信が生まれる。そしていつか、本当は慎重であるべき場面でAIを過信して失敗するリスクが高まっていく。 また、AIの普及でソフトウェアの品質評価基準そのものも変化している。 従来: 充実したテストスイート、丁寧なドキュメント → 高品質の証明 現在: AIを使えばテストもドキュメントも数十分で完璧に揃えられる 見た目の完成度はもはや品質の指標にならない。代わりに価値を持ち始めたのは「実際に誰かが数週間・数ヶ月にわたって日常的に使っている」という実績だ。 開発プロセスの重心がシフトする @iwashi86 の整理によれば、AIによってコーディング速度が10倍（Willlison の元記事では「1日200行→2000行」）に跳ね上がったことで、従来のソフトウェア開発プロセス全体に変化が生じている。 コードを書くコストが劇的に下がったことで、失敗を恐れずに大胆なアーキテクチャ変更や仕様変更を試せるようになった。以前は実装コストが高すぎて試せなかったアイデアを、気軽にプロトタイプできる環境が整いつつある。 これはボトルネックを「実装」から「設計・判断・文脈理解」へとシフトさせることを意味する。 ソフトウェアエンジニアという職業の未来 Willisonは、AIが自動でコードを書く時代になってもソフトウェアエンジニアという職業は脅かされないと考えている。 その理由はシンプルだ：ソフトウェア開発はそもそも非常に困難な作業だから。AIはプロのエンジニアが持つ経験・判断力・文脈理解を増幅する道具にすぎない。AIを使いこなすためにこそ、深い専門知識が必要になる。 そして最終的には、企業も個人も「素人がAIで自作したシステム」より「プロがAIを駆使して作り上げた、実績のある製品」に対してお金を払いたいはずだ、とWillisonは結論づける。 まとめ Simon Willisonの考察は、AI開発ツールの急速な進化がエンジニアの「当たり前」を静かに書き換えていることを示唆している。 バイブコーディングとエージェンティックエンジニアリングの境界は、AIの性能向上とともに溶けつつある AIへの依存は「責任の所在」という根本的な問題を内包している ソフトウェアの品質指標は「見た目の完成度」から「実績・継続使用」へ移行しつつある 開発ボトルネックは「実装」から「設計・判断」へシフトしている それでもプロのエンジニアの価値はなくならない — AIはあくまで増幅器だ 元記事: Vibe Coding and Agentic Engineering Are Getting Closer Than I’d Like ツイート: @iwashi86

MacBook Pro M4 ローカルで Llama 3.3 70B を 11 時間動かし続け、機内でクライアント仕事をすべて片付けた開発者がいる。Wi-Fi 代 25 ドルを払わず、オフラインだけで完結させた「オフライン AI ワークフロー」の実例が話題になっている。 構成：ハードウェアとソフトウェア 使用機材はシンプルだ。 項目 内容 マシン MacBook Pro M4、64 GB 統合メモリ モデル Llama 3.3 70B（bf16 精度） 推論エンジン llama.cpp（localhost:8080 で待機） 生成速度 71 トークン/秒 コンテキスト長 約 60,000 トークン メモリ使用量 48.6 GiB（ほぼ上限） 離陸時バッテリー残量 3 時間 21 分 離陸前に書いたオーケストレーション・スクリプト キモはフライト前に仕込んだシステムプロンプトとスクリプトだ。要約すると以下のとおりだった。 1 2 3 4 5 6 7 8 あなたは今、MacBook 上のオフライン・オーケストレーターです。ネットはありません。 使えるのはローカルファイルと localhost:8080 の Llama 推論サービスだけです。 バッテリーは 3 時間強。 /Users/dev/work/queue.jsonl からクライアントタスクを 1 件ずつ読み込み、 各タスクをドラフト→ローカル評価→ /Users/dev/work/done/ に出力してください。 12 タスクごとにコンテキストチェックポイントを保存し、電源交換後に復元できるようにすること。 キューが空になるか、バッテリーが 5% を切ったら停止。 制約を正直に宣言したシステムプロンプトが、エージェントに「自分の家の事情」を完全に理解させた。インターネットなし・メモリ有限・電源も有限、そして操作者は空の上にいる——何か起きても誰も介入できない状況だ。 ...

LLM API を日本語で使っていると、英語ユーザーと比べて知らないうちに多くのコストを支払っている。この「言語税」とも言える現象を、6社・9言語の比較データで整理した投稿が話題になった。 「言語税」とは何か 日本語ユーザーは無自覚に「言語税」を払い続けている。同じ処理内容であっても、日本語で問い合わせる分だけ余計にトークンを消費し、API コストが積み上がる構造だ。 特に以下のような用途では影響が大きい。 大量のテキスト処理: 文書要約、翻訳、レビューなどを日本語で大量に行う場合 チャットボット・カスタマーサポート: 日本語ユーザーとの会話が続くアプリケーション RAG（Retrieval-Augmented Generation）: 日本語ドキュメントをコンテキストに含める場合 日本語は英語の約 1.48 倍のトークンを消費する 同じ内容を日本語で LLM に投げると、英語に比べて平均 1.48 倍 のトークンを消費するという計算がある。これは 6 社の LLM プロバイダーの平均値だ。 日本語はトークン効率が低くなる理由はトークナイザーの設計にある。英語は複数の文字が 1 トークンに対応するケースが多いが、日本語はひらがな・カタカナ・漢字が混在しており、1 文字が 1 トークンに対応するケースが多い。そのため同じ情報量でも消費トークン数が増えやすい。 プロバイダー別の日本語トークン比率 プロバイダーによって日本語処理のトークン効率には大きな差がある。 プロバイダー 日本語トークン比率（英語比） Anthropic（Claude） 1.94x Gemini 3.1 1.14x 平均（6社） 1.48x ※ 全6社の内訳は元ツイートのスレッドを参照。 Anthropic の Claude は日本語で英語の約 2 倍のトークンを消費する一方、Gemini 3.1 はほぼ英語並みのトークン効率を実現している。Claude（1.94x）と Gemini（1.14x）を比べると 1.94 ÷ 1.14 ≈ 1.7 倍 の差があり、モデル選びだけでコストが最大 1.7 倍変わるという計算になる。 コスト削減のアプローチ この「言語税」を意識した場合、以下のアプローチが有効だ。 1. プロバイダーの使い分け 日本語処理が多い用途では Gemini 3.1 など日本語トークン効率の高いモデルを選択する。Anthropic の Claude は能力が高い一方、日本語コストが割高になるため、用途に応じた使い分けが重要だ。 ...

RAGの長年の課題である「回答の網羅性の欠如」を、ベクトルDBを使わずに解決しようとする論文が登場した。2026年4月16日にarXivに公開された論文「Don’t Retrieve, Navigate」は、Corpus2Skill という新手法を提案している。文書コーパスを階層的スキルディレクトリへ事前変換し、LLMエージェントがナビゲートして回答を構築するアプローチだ。 従来のRAGが抱える課題 RAG（Retrieval-Augmented Generation）はこの数年で大きく進化し、多くの問題が解決されてきた。しかし「AIの回答が網羅的でない」という問題は依然として未解決のままだ。 従来のベクトル検索ベースのRAGでは、クエリに類似したチャンクをいくつか取得して回答を生成する。この方式の弱点は以下の通りだ。 クエリ表現に引きずられ、関連する別の観点の文書を見落とす チャンク間の文脈的なつながりが断ち切られる 広範なトピックをカバーする質問への回答が部分的になりがち Corpus2Skillのアプローチ：「検索するな、ナビゲートせよ」 Corpus2Skillは発想を根本から変える。ベクトル検索で文書を「取ってくる」のではなく、人間が目次や索引を辿るように、エージェントがコーパスの階層構造を「ナビゲートする」。 オフラインのコンパイルパイプライン まず事前処理として、文書コーパスを階層的スキルディレクトリへ変換する。 反復クラスタリング — 全文書をk-meansなどでグループ化する LLM生成サマリー — 各クラスタの内容をLLMが要約する 階層化 — クラスタをさらに上位概念でまとめ、ピラミッド構造を構築する スキルファイルツリーの実体化 — 結果を SKILL.md / INDEX.md の形式でファイルシステムに保存する この処理はオフラインで行われるため、推論時の遅延には影響しない。 推論時のナビゲーション 質問が来たとき、LLMエージェントは次の手順で回答を構築する。 コーパス全体の俯瞰図（ルートサマリー）を受け取る 質問に関連する上位ブランチを選択し、段階的に下位サマリーへ降下する 目的のノードに到達したら、文書IDを使って完全な文書を取得する 必要に応じてバックトラックし、別のブランチも探索する この探索パスが明示的に推論されるため、なぜその文書が取得されたかを追跡できるという副次的なメリットもある。 ベクトルDBが不要になる理由 従来のRAGではベクトルDB（Pinecone, Weaviate, Chromaなど）が必須だった。Corpus2Skillでは、スキルファイルツリーがその役割を置き換える。 項目 従来のRAG Corpus2Skill インデックス形式 ベクトルDB 階層ファイルツリー 検索方式 類似度検索 エージェントによるナビゲーション インフラ依存 ベクトルDBが必要 ファイルシステムのみ スケーラビリティ O(N) O(log N) 探索パスの透明性 低い 高い（明示的に推論） 文書数が10万件でも階層深度はO(log N)に収まるため、大規模コーパスへのスケーラビリティが高い点も特長だ。 実験結果 WixQAベンチマーク Wix社の企業向け顧客サポートを対象とするWixQAベンチマークで評価した。比較対象は以下のベースラインだ。 Dense Retrieval（密集検索）: 従来のベクトル検索RAG RAPTOR: 階層的サマリーを使った検索手法 Agent RAG: エージェントが検索を制御する手法 Corpus2Skillは全品質指標でこれらすべてを上回った。 ...

本記事では、Python の AST を活用して AI による脆弱性検出を効率化する手法を紹介します。Qiita の @PythonHaru 氏が公開した記事「コードを1行も読ませずに、AIに脆弱性を100%特定させる方法（理論編）」は 530 いいね・471 ブックマークを獲得し、X（旧 Twitter）でも急速に拡散しました。 この記事のポイント AI（LLM）に生のソースコードを読ませるのは、効率の悪い「情報の暴力」（情報量が多すぎて AI が処理しきれない状態） Python の ast モジュールで生成した Deep Structure Map（コードの骨格図）こそ、AI の推論能力を最大化する データの流入から危険地帯への到達をグラフ理論で定義すれば、理論上 脆弱性は100%特定可能 AIコードレビューの限界 GitHub Copilot や ChatGPT にコードをそのまま貼り付けて「脆弱性ある？」と質問する手法は今や一般的ですが、大規模プロジェクトでは2つの致命的な欠陥が生じます。 コンテキストの霧（AI が変数の出自を追跡できなくなる状態）— 数千行のコードを前にした AI は「どの変数がどこから来たか」を見失い、ハルシネーションを起こしやすくなる トークンの浪費 — コードの「書き方」というノイズに注目してしまい、肝心の「ロジックの破綻」に辿り着く前にリソースを使い果たす そこで著者は、AI にコードを1行も読ませるのをやめました。代わりに渡したのが、自作の解析コードが抽出した「コードの設計図（Deep Structure Map）」です。 Deep Structure Map：AI に「骨格」だけを渡す ソースコードは人間が読むための「肉体」ですが、AI が論理推論に必要なのは純粋な「神経系（ロジック）」です。Python の ast モジュールを使い、コードを以下の構造データへ変換します。 DeepAnalyzer クラス（ast.NodeVisitor を継承） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 import ast class DeepAnalyzer(ast.NodeVisitor): def __init__(self): self.classes = [] self.functions = [] self.variables = [] self.scope_stack = [] self.call_graph = {} def visit_ClassDef(self, node): self.classes.append(node.name) self.generic_visit(node) def visit_Call(self, node): # 関数呼び出しをコールグラフとして記録 self.generic_visit(node) ast.NodeVisitor を継承した DeepAnalyzer がコード全体を走査し、クラス・関数・変数のスコープ情報とコールグラフを収集します。AI にはこの「関係性の結晶」だけをインプットします。 ...