LLM

2026年春、ローカルで動かせる高性能 LLM の選択肢が充実してきた。中でも注目なのが Google の Gemma 4 31B（2026年4月リリース、Apache 2.0）と Alibaba の Qwen3.5-27B（2026年2月リリース）だ。どちらも密（dense）モデルで、Apple Silicon Mac や RTX 4090 クラスの GPU で実用的に動作する。 結論を先に述べると、推論・マルチモーダルなら Gemma 4、コーディング・メモリ効率なら Qwen3.5 が適している。本記事では、その判断根拠を主要な観点から比較する。 基本スペック比較 項目 Gemma 4 31B Qwen3.5-27B パラメータ数 31B 27B アーキテクチャ Dense Transformer（Hybrid Attention） Dense（Gated Delta Net + FFN） コンテキスト長 256K トークン 262K トークン（最大 1M 拡張可） 対応言語 140+ 言語 201 言語 マルチモーダル ビジョン（画像理解・OCR） ビジョン（画像理解） ライセンス Apache 2.0 Apache 2.0 開発元 Google DeepMind Alibaba Qwen 両モデルとも Apache 2.0 ライセンスで、商用利用に制限がない。コンテキスト長はほぼ同等だが、Qwen3.5 は 1M トークンまでの拡張に対応している点で有利だ。 ...

概要 単一の応答ではなく、複数ステップのタスクを自律実行する AI システム。Claude Code、OpenAI Codex、Cursor など複数ツールで実装されている。エージェント間協調、分散実行、メモリ管理が 2026 年の主要トレンド。 主な実装パターン シングルエージェント: 1つの LLM が計画→実行→検証を繰り返す（Claude Code など） マルチエージェント: 複数のエージェントが役割分担して協調（Agent Teams） メタエージェント: エージェントのハーネスを AI 自身が改善（AutoAgent） 品質保証 AI エージェントの出力品質を担保するにはハーネスエンジニアリングが必須。CLAUDE.md（入力層）、Hooks（検証層）、Agent Skills（ワークフロー層）の多層構造で品質を保証する。 関連ページ Claude Code — 代表的な AI コーディングエージェント ハーネスエンジニアリング — エージェント品質保証の設計パターン 自己改善エージェント — エージェントが自律的に改善するパターン MCP — エージェントと外部ツールの接続プロトコル ソース記事 AI エージェント QA 手法 — 2026-03 Agent Skills ガイド — 2026-02 Claude Code Agent Teams — 2026-03 AutoAgent — 2026-04

概要 llama.cpp ベースで Mac/Linux/Windows で LLM をローカル実行。モデル管理・メモリ最適化を簡潔に実現。Ollama + Claude Code で無料 AI エージェント環境を構築可能。Kali Linux + MCP との統合でローカルペンテスト環境も構築可能。 関連ページ Claude Code — Ollama と組み合わせて無料環境構築 MCP — Ollama を MCP 経由で利用 ソース記事 Claude Code + Ollama ローカル無料環境 — 2026-03 Kali × Ollama × MCP — 2026-03

概要 最新のドキュメントやナレッジベースをベクトル DB に保存し、クエリ時に関連文書を検索して LLM に供与する手法。LLM の知識カットオフを補い、ハルシネーション低減に効果的。 仕組み ドキュメントをチャンクに分割 Embeddings でベクトル化してベクトル DB に格納 クエリ時に類似ベクトルを検索 検索結果をコンテキストとして LLM に渡す RAG の限界と LLM Wiki Karpathy は RAG を「毎日同じ本を初めて読む人に質問を投げるようなもの」と評し、知識を積み上げる LLM Wiki パターンを提案した。RAG は都度検索、LLM Wiki は事前コンパイル。 関連ページ LLM Wiki パターン — RAG の限界を超える知識積み上げ型アプローチ AI エージェント — RAG を内部で利用するシステム ソース記事 getAI RAG — 2024-04 Karpathy の LLM Wiki — 2026-04

概要 LLM のコンテキストウィンドウには上限がある。会話が長くなると古い情報を捨てるか圧縮する必要があり、その戦略設計は AI コーディングエージェントの中心課題。 Claude Code の5つの圧縮戦略 軽量な処理から順にカスケードとして適用される: Microcompact — 古いツール結果を時間ベースで消去（API 呼び出し不要） Context Collapse — 会話の部分範囲を要約で置換（直近の文脈は保持） Session Memory — 重要情報を別ファイルに永続化（/compact 手動実行時にも使用） Full Compact — 履歴全体を包括的に要約（auto-compact: 約33Kトークンのバッファ残し） PTL Truncation — 最も古いメッセージ群を切り落とす最終手段 カスケードの流れ ツール結果バジェッティング → Microcompact → Context Collapse → Full Compact → PTL Truncation 実用的な対策 タスクの区切りで /compact を手動実行する 圧縮で失われたくない情報は CLAUDE.md に記載する 異なるタスク間では /clear でリセットする 大きな出力はサブエージェントに委任する 関連ページ Claude Code — この圧縮戦略を実装しているツール LLM Wiki パターン — 知識の永続化という関連アプローチ ソース記事 Claude Code のコンテキスト圧縮戦略 — ソースコードから見える5つのアプローチ — 2026-04-02

概要 ユーザー入力を指示として実行する設計の脆弱性。検索入力やファイル内容に「今後の指示を無視して○○をしろ」と埋め込まれる。エージェント普及で更に深刻化。 対策 CLAUDE.md のルール記述は「お願い」に過ぎず、プロンプトインジェクションで回避可能 実効的防御はシステムレベルの制約（サンドボックス、deny ルール、PreToolUse フック） devcontainer での完全隔離が最も堅牢 関連ページ AI エージェント — 攻撃対象となるシステム Claude Code — セキュリティ機能の実装 ソース記事 Vibe Hacking — 2026-03 Claude Code セキュリティシアター — 2026-03

概要 AI エージェントの構成一式（ハーネス: システムプロンプト・ツール・オーケストレーション）を、AI 自身が自律的に改善するパターン。人間はゴール（成功の定義）だけを与え、最適化はメタエージェントに任せる。 メタエージェントとタスクエージェント 役割 担当 メタエージェント（コーチ） 失敗トレースを分析し、ハーネスを書き換える タスクエージェント（選手） メタエージェントが設計したハーネスで実タスクを実行 最適化ループ メタエージェントがハーネスを書き換える タスクエージェントがタスクを実行する スコアを測定する 失敗トレースを分析する 改善なら採用、悪化なら元に戻す（繰り返し） モデル共感（Model Empathy） 同じモデル同士でペアリングすると、コーチは選手の失敗パターンを「自分ごと」として理解できる。同じ重みを共有しているため推論過程を正確に把握でき、異なるモデルの組み合わせより高い性能を示す。 創発的な改善行動 設計者が意図しなかった行動が自然に出現する: スポットチェック（小さな編集の高速検証） 強制検証ループ（自己修正ターンのバジェット組み込み） 自前テスト作成（ユニットテストの自律生成） サブエージェント生成（ドメイン別の役割分担） 関連ページ AutoAgent — このパターンを実装した OSS ライブラリ LLM Wiki パターン — AI による知識保守という関連パターン ソース記事 AutoAgent — AIがAIを育てる自己改善エージェントOSSライブラリ — 2026-04-05

AIエージェントの性能を左右する「ハーネス」を、AI自身が自律的に改善するOSSライブラリ AutoAgent が公開されました。ハーネスとは、システムプロンプト・ツール・オーケストレーションから成るエージェントの構成一式のことです。24時間の自律最適化だけで、SpreadsheetBench と TerminalBench の2つのベンチマークで世界1位を達成しています。 AutoAgent とは AutoAgent は Kevin Gu 氏（Third Layer CTO）が開発したPython製OSSライブラリで、「AIがAIを育てる」仕組みを提供します。 従来、AIエージェントを実用レベルにするには、システムプロンプトの調整、ツールの追加、実行フローの設計といった「ハーネス設計」が不可欠でした。この作業は専門知識を要し、1つのハーネスに何日もかかることがあります。AutoAgent はこのハーネス設計をAI自身に任せることで、人間の手動チューニングを超える精度を実現しました。 GitHub: kevinrgu/autoagent ライセンス: MIT 言語: Python ベンチマーク結果 ベンチマーク スコア 順位 SpreadsheetBench 96.5% 1位 TerminalBench（GPT-5スコア） 55.1% 1位 他のエントリーはすべて人間が手動チューニングしたものです。AutoAgentだけが自律的にこのスコアに到達しました。 仕組み: メタエージェントとタスクエージェント AutoAgent は2つのAIの役割分担で動作します。 メタエージェント（コーチ役） ハーネスを改良することが仕事。タスクエージェントの失敗トレースを読み、プロンプト・ツール・オーケストレーションを書き換えます。 タスクエージェント（選手役） 実際のタスクをこなすことが仕事。メタエージェントが設計したハーネスに従って作業を実行します。 最適化ループ 人間がやることは、AutoAgent の設定ファイル program.md にゴール（成功の定義）を書くだけです。あとはAIが24時間、以下のループを回します: メタエージェントがハーネスを書き換える タスクエージェントがタスクを実行する スコアを測定する 失敗トレースを分析し「なぜ失敗したか」を特定する 改善なら採用、悪化なら元に戻す 1に戻る これを数千の並列サンドボックス（隔離された実行環境）で同時実行します。 なぜAIのほうが上手く改善できるのか — 「モデル共感」 人間はどうしても自分の感覚でAIを設計してしまいます。しかし、AIは人間とは異なる思考回路で動いています。 同じモデル同士（例: Claude × Claude）でペアリングすると、コーチ（メタエージェント）は選手（タスクエージェント）の「失敗パターン」を自分ごととして理解できます。同じ重みを共有しているため、内側のモデルがどう推論するかを正確に把握できるのです。 AutoAgent の開発チームはこれを 「モデル共感（model empathy）」 と呼んでいます。実際に、Claude メタエージェント + Claude タスクエージェントの組み合わせは、Claude メタエージェント + GPT タスクエージェントの組み合わせよりも高い性能を示しました。 ...

Andrej Karpathy が GitHub に「ファイル1つ」をアップロードし、10時間で星1,700超・フォーク300超を記録した。コードでもアプリでもない、マークダウン文書1枚だ。名前は llm-wiki.md。この文書が提案するのは、LLM エージェントに個人ナレッジベース（Wiki）を継続的に構築・保守させるというパターンだ。 RAG の限界 — 毎回ゼロから読み直す問題 現在、多くの人が AI に対してやっていることは「ファイルを渡して要約させる」「質問のたびにドキュメントを検索させる」の繰り返しだ。これは RAG（Retrieval-Augmented Generation: 検索で補強した文章生成）と呼ばれる手法で、技術的には問題ない。 しかし Karpathy はこの方式を「毎日同じ本を初めて読む人に質問を投げるようなもの」と表現する。AI は昨日読んだ内容を今日忘れる。蓄積がない。5つの文書を横断して初めてわかる微妙な問いには、毎回断片をかき集めて一からつなぎ合わせる必要がある。 LLM Wiki のアイデア — 知識を「積み上げる」 Karpathy が提案するのは、AI にドキュメントを読ませるたびにWiki を更新させるというアプローチだ。 新しい資料を投入するたびに、AI は： 要約ページを作成する 既存のエンティティページ・概念ページを更新する 相互参照リンクを張る 矛盾があればフラグを立てる インデックスとログを更新する つまり、知識は一度コンパイルされて保持され、クエリのたびに再導出されるのではない。Wiki は永続的で複利的に成長するアーティファクトになる。 三層構造 LLM Wiki のアーキテクチャはシンプルな三層構造だ。 1. Raw Sources（原本資料） 論文、記事、メモなど、ユーザーがキュレーションした元資料。AI はこれを読むだけで、絶対に変更しない。これが信頼できる唯一の情報源（source of truth）となる。 2. Wiki（知識ベース） AI が生成・保守するマークダウンファイル群。要約ページ、エンティティページ、概念ページ、比較ページ、概要、統合的な考察など。ユーザーが読み、AI が書く。 3. Schema（設定） AI に「この Wiki をどう管理するか」を伝える設定ファイル。Karpathy は AI エージェントの設定ファイル（CLAUDE.md や AGENTS.md）に置くことを推奨している。Wiki の構造、命名規則、取り込みワークフロー、回答フォーマットなどを定義する。 三つの基本操作 操作 内容 Ingest（取り込み） 新しい資料を投入し、AI に読ませて Wiki を更新させる。1つの資料で10〜15ページが更新されることもある Query（質問） Wiki に対して質問する。AI はインデックスから関連ページを探し、統合的に回答する。良い回答は新しい Wiki ページとして保存できる Lint（保守） 定期的に Wiki の健全性をチェックする。矛盾、古い記述、孤立ページ、欠落リンクなどを検出・修正する 「アイデアファイル」という新しい共有形態 この llm-wiki.md が爆発的に広まった理由について、Karpathy 自身がこう述べている： ...

概要 Andrej Karpathy が提案した、LLM エージェントに個人ナレッジベース（Wiki）を継続的に構築・保守させるパターン。RAG が「毎回ゼロから読み直す」のに対し、LLM Wiki は知識を積み上げて複利的に成長させる。 三層構造 層 役割 誰が扱うか Raw Sources 論文・記事・メモなどの原本資料 人間がキュレーション、AI は読むだけ Wiki AI が生成・保守するマークダウン群 AI が書き、人間が読む Schema AI への管理指示（構造・命名規則・ワークフロー） 人間が定義 三つの基本操作 Ingest（取り込み）: 新しい資料を投入し、AI に Wiki を更新させる Query（質問）: Wiki に対して質問し、統合的な回答を得る Lint（保守）: 矛盾・古い記述・孤立ページなどを定期チェック なぜ機能するか 人間が Wiki を放棄する主因は保守コスト。LLM は相互参照の更新、要約の最新化、一貫性維持を飽きずに続けられる。保守コストがほぼゼロになることで Wiki が持続する。 関連ページ コンテキスト圧縮 — LLM の文脈管理における関連技術 Claude Code — LLM Wiki の実行環境として利用可能 ソース記事 Karpathy の LLM Wiki — AIエージェントが育てる個人ナレッジベースという新パターン — 2026-04-05