AI/LLM

GoogleのGemini Agentモードが、AIエージェント界隈で大きな注目を集めている。Gmail、カレンダー、Drive、スライドといったGoogle Workspaceアプリを横断し、複雑なタスクを自動処理できる機能だ。従来のチャットAIとは一線を画すその実力を、OpenClawとの比較も交えて見ていく。 Gemini Agentモードとは Gemini Agentモードは、Googleが提供するAIアシスタント「Gemini」に搭載されたエージェント機能だ。従来のチャット型AIとは異なり、ユーザーの指示に基づいて計画を立て、複数のアプリやサービスを横断して、タスクを自律的に実行する。 主な特徴は以下の通り。 マルチステップタスクの自動実行: 計画→情報収集→処理→出力を一連の流れで実行 Google Workspace連携: Gmail、Google Calendar、Google Drive、Keep、Tasks等と統合 ライブウェブブラウジング: Webサイトを開いて情報を収集・比較 ユーザーコントロール: 重要なアクション（メール送信、購入など）の前に確認を求める 具体的にできること Gemini Agentモードの強力さは、実務的なタスクを連鎖的に処理できる点にある。 Google Workspace連携の例 Gmailの未返信メールを確認して要点を整理 返信案を自動作成 カレンダーで候補日を確認してスケジュール調整 Driveの資料を参照 Googleスライドで提案資料を作成 これらを1つのプロンプトで連続処理できる。 ブラウザ操作 Webサイトを開いて情報を収集 YouTubeを情報源として調査 ToDoリストへの追加 不要メールのアーカイブ 定期実行（スケジュールドアクション） Gemini Agentモードの特筆すべき機能の1つがスケジュールドアクションだ。「毎日」「毎週」などの頻度でタスクを定期実行できる。繰り返し頻度は毎時・毎日・毎週・毎月・毎年から選択でき、実行時間もカスタマイズ可能だ。 例えば、以下のような自動化が実現できる。 毎朝のメール要約とカレンダー確認 週次のプロジェクト進捗レポート作成 定期的なDrive内ファイルの整理 AIを「使う」のではなく、AIを「働かせる」という発想の転換だ。 OpenClawとの比較 OpenClawは、2025年11月にオーストリアの開発者Peter Steinbergerが「Clawdbot」として公開したオープンソースのAIエージェントだ。Anthropicからの商標問題を受けて「Moltbot」に改名し、その後「OpenClaw」へ変更された。GitHubスターは25万を超え、開発者コミュニティで大きな注目を集めている。ファイル操作、シェルコマンド実行、ブラウザ操作など100以上のビルトインスキルを備える。 項目 Gemini Agent OpenClaw 提供形態 Googleのクラウドサービス オープンソース（セルフホスト） Google Workspace連携 ネイティブ統合 API経由で設定が必要 定期実行 標準機能 自前での設定が必要 カスタマイズ性 限定的 高い（スキル追加可能） セキュリティ Googleの管理下 スキルの安全性は自己責任 料金 Google AI Ultra（有料） 無料（LLM APIは別途） Gemini Agentの強みは、Google Workspaceとのネイティブ統合とスケジュール実行の手軽さだ。一方、OpenClawは高いカスタマイズ性とセルフホストによるデータ管理が利点となる。 ...

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 トークンまでの拡張に対応している点で有利だ。 ...

Gemma 4 が「すごいオープンソースモデル」として話題になっている。しかし、本当に注目すべきポイントはモデル性能だけではない。GoogleがAPI経済の構造そのものに挑戦しているという点だ。 Gemma 4のラインナップ Gemma 4は4つのサイズで提供されている。 モデル パラメータ 推論時アクティブ コンテキスト 用途 31B Dense 31B 31B 256K サーバー/ワークステーション 26B MoE 26B 約3.8B 256K サーバー/ワークステーション E4B 非公表 約4B 128K エッジデバイス E2B 非公表 約2.3B 128K スマートフォン 注目は 26B MoE だ。総パラメータ数は26Bだが、Mixture-of-Experts（MoE）アーキテクチャにより推論時にアクティブなのは約3.8Bのみ。これにより、RTX 4090のような一般的なGPUでも十分に動作する。 API課金モデルへのインパクト 従来のAI搭載SaaSは、以下のようなコスト構造を持つ。 1 2 3 ユーザーリクエスト → 自社サーバー → OpenAI/Anthropic API → レスポンス ↑ リクエストごとに課金 この構造では、ユーザーが増えるほどAPI費用が増加する。特にスタートアップにとって、スケールするほど外部API費用が利益を圧迫する「API課金の罠」に陥りやすい。 Gemma 4は、この構造を根本から変える可能性がある。 1 2 3 ユーザーリクエスト → 自社サーバー（Gemma 4稼働） → レスポンス ↑ 固定のインフラコストのみ Apache 2.0ライセンス で商用利用に制限がなく、カスタムの利用規約や解約条項もない。自社サーバーでモデルを稼働させれば、コストはインフラの固定費だけになる。 ...

Microsoftが開発した1-bit LLM推論フレームワーク「BitNet」が完全にオープンソース化されました。bitnet.cppを使えば、1000億パラメータ規模のLLMをGPUなしでCPU上で実行できます。 BitNetとは BitNetは、Microsoft Researchが開発した1-bit LLM（大規模言語モデル）専用の推論フレームワークです。従来のLLMが16bitや32bitの浮動小数点で重みを保持するのに対し、BitNetではすべての重みを -1、0、+1の3値（log2(3) ≒ 1.58bit） で表現します。 GitHub: microsoft/BitNet（37,000+スター） ライセンス: MIT License 技術レポート: BitNet b1.58 2B4T Technical Report 主な特徴 GPU不要のCPU推論 bitnet.cppは、llama.cpp（LLM向け軽量推論エンジン）をベースに1-bit推論向けに最適化されたC++フレームワークです。専用カーネルにより、ternary演算（3値演算）をCPU上で高速に実行します。 x86 CPU: 従来比 2.37〜6.17倍 の高速化 ARM CPU: 従来比 1.37〜5.07倍 の高速化 2026年1月のアップデートでさらに 1.15〜2.1倍 の追加高速化を達成 省エネルギー・省メモリ エネルギー削減: x86 CPUで 71.9%〜82.2%、ARM CPUで 55.4%〜70.0% の削減 メモリ使用量: BitNet b1.58 2B-4Tモデルはわずか 0.4GB（同規模の通常モデルは1.4〜4.8GB） BitNet b1.58 2B-4T モデル Microsoftが公開した初のオープンソースのネイティブ1-bit LLMです。 パラメータ数: 24億（2.4B） 学習データ: 4兆トークン（4T） アーキテクチャ: BitLinearレイヤーを組み込んだTransformerベース 主な技術: RoPE（回転位置埋め込み）、Squared ReLU活性化関数、subln（サブレイヤー正規化） 重み: ネイティブ1.58bit、活性化は8bit（W1.58A8） 同規模のフル精度モデルと同等の性能を達成しています。 なぜ重要なのか ローカルAI・エッジコンピューティングの民主化 これまで大規模LLMの実行には高価なGPUが必須でしたが、BitNetにより一般的なPCやエッジデバイスでも実用的な推論が可能になります。 GPU依存からの脱却 NVIDIA GPUへの依存度を大幅に下げられることで、AI開発・運用のコスト構造が変わる可能性があります。特に中小企業やスタートアップにとって、AIの導入障壁が大きく下がります。 ...

Google の Gemma 4 31B モデルをベースに、安全性制限を除去した「Gemma-4-31B-JANG_4M-CRACK」が Hugging Face で公開された。開発元の dealignai は、Abliteration（アブリテレーション）と呼ばれる手法でモデルの拒否行動を除去した。知識性能の劣化は MMLU で -2.0% にとどまる。 Abliteration とは何か Abliteration は、LLM の学習済み拒否メカニズムを再学習なしで除去する手法だ。2024年頃から研究が進み、現在では複数のバリエーションが存在する。 基本的な仕組みは以下の通り: 拒否方向の特定: 有害なプロンプトと無害なプロンプトをモデルに入力し、残差ストリーム（Transformer 内部の中間表現が流れる経路）の活性化を記録する。両者の平均差分ベクトルが「拒否方向」（refusal direction）となる 重み直交化: 特定した拒否方向に対してモデルの重み行列を直交化（orthogonalization）する。直感的には、拒否方向の成分を重みから差し引く操作にあたる。これにより、モデルはその方向への活性化を生成できなくなる 性能保持: 拒否方向のみをターゲットにするため、モデルの汎用的な知識や推論能力への影響は最小限に抑えられる 最近の改良版である Norm-Preserving Biprojected Abliteration では、ベクトルのノルムを保持しながら除去を行うことで、さらに性能劣化を抑えている。 CRACK モデルのスペック 項目 値 ベースモデル google/gemma-4-31b-it アーキテクチャ Dense Transformer + Hybrid Sliding/Global Attention 量子化プロファイル JANG_4M（CRITICAL=8-bit, COMPRESS=4-bit） 平均ビット数 5.1 bits モデルサイズ 18 GB ビジョン マルチモーダル対応（ビジョンエンコーダは量子化せず float16 を維持） フォーマット JANG v2（MLX ネイティブ safetensors） JANG_4M のビット割り当て JANG プロファイルの特徴は、アテンション層とMLP層で異なるビット精度を割り当てる点にある: CRITICAL（8-bit）: Attention の Q/K/V/O 重み、エンベディング COMPRESS（4-bit）: MLP の gate/up/down projection、その他の重み Dense モデルは MLP 部分の量子化耐性が高いため、この戦略により 18GB という実用的なサイズを実現している。 ...

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 タスクエージェントの組み合わせよりも高い性能を示しました。 ...

Claude Code ライクなターミナル AI コーディングエージェントを、Anthropic API なしでローカル LLM で動かせる「claw-code-local」が登場しました。Rust で実装された軽量・高速なツールで、Ollama や LM Studio など好みの LLM バックエンドを自由に選べます。 claw-code-local とは claw-code-local は、Claude Code のアーキテクチャをクリーンルーム方式（既存コードを参照せず仕様から独自に再実装する手法）で作られた「Claw Code」のフォークです。ローカル LLM や任意の OpenAI 互換エンドポイントに接続できるよう拡張されています。 オリジナルの Claw Code は Rust で書かれたマルチプロバイダー API レイヤーを持っていましたが、実際のバイナリにはその機能が組み込まれていませんでした。claw-code-local はこの部分を修正し、Ollama、LM Studio、OpenAI、xAI など様々なプロバイダーに接続できるようにしています。 主な特徴 ローカル LLM 対応: Ollama、LM Studio、その他 OpenAI 互換エンドポイントで動作 Rust 実装: 軽量・高速なバイナリ マルチプラットフォーム: Windows、Linux、macOS に対応 コストゼロ: ローカル LLM を使えば API 費用が不要 プライバシー保護: コードが外部サーバーに送信されないため、機密情報の漏洩リスクを低減 セットアップ手順 1. リポジトリのクローンとビルド 1 2 3 git clone https://github.com/codetwentyfive/claw-code-local.git cd claw-code-local/rust cargo build -p rusty-claude-cli --release ビルド後のバイナリは以下に生成されます: ...

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 自身がこう述べている： ...

Anthropic が開発中の常駐型AIエージェント「Conway」のリーク情報が話題になっています。従来のチャットベースのやり取りとは異なり、24時間バックグラウンドで稼働し続けます。いわば「AI従業員」として機能する次世代エージェント環境です。 Conway の概要 Conway は、Anthropic が内部テスト中の常駐型（Always-On）AIエージェント環境です。TestingCatalog が 2026年4月にスクープし、その存在が明らかになりました。ユーザーのシステムやブラウザ上にサイドバーとして常駐し、ユーザーが操作していなくても裏側で継続的にタスクを実行できます。 Claude がこれまで提供してきた「対話型アシスタント」から、「自律的に業務を遂行するエージェント」への進化を示すプロダクトと位置づけられています。 主な特徴 Always-On（常時稼働） Conway の最大の特徴は、ユーザーが待機していなくてもバックグラウンドで常に稼働し続ける点です。従来の Claude のようにプロンプトを送って応答を待つワンショット型ではなく、永続的なプロセスとして動作します。 Webhook 連携 外部アプリケーションからの通知をトリガーに自動実行が可能です。Webhook セクションでは、外部サービスがインスタンスを起動するためのパブリック URL が提供されます。サービスレベルのトグルでトリガーのオン・オフを制御できます。例えば以下のようなユースケースが考えられます: メール受信時に自動で要約・分類 GitHub の Issue 作成をトリガーに調査を開始 Slack のメンション通知をきっかけに対応を自動化 ブラウザ操作と Claude Code 連携 Conway は Chrome ブラウザの操作が可能で、Web上のマルチステップタスクを自律的に処理できます。また、Claude Code（リーク情報では「Epitaxy」というコードネームも言及）との連携も備えており、コーディングタスクも自動化の範囲に含まれます。 独自拡張規格「.cnw」 Anthropic は Extensions エリアを準備しており、ユーザーがカスタムツール、UIタブ、コンテキストハンドラをインストールできるようになります。.cnw.zip ファイルのドロップに対応した独自の拡張パッケージ規格が用意されており、サードパーティのアドオンフレームワークとしての展開が見込まれます。 技術的なアーキテクチャ リーク情報から判明している Conway の構成要素は以下の通りです: コンポーネント 説明 独立 UI インスタンス サイドバー形式で常駐 Webhook エンドポイント 外部サービスからのイベント受信 ブラウザ操作 Chrome を通じた Web 操作 Claude Code 連携 コーディングタスクの自動実行 通知システム タスク完了等の通知送信 Extensions .cnw 形式のプラグイン機構 既存ツールとの違い 現在の Claude Desktop や Claude Code は、いずれもユーザーの入力をトリガーとして動作する対話型ツールです。Conway はこれらとは異なり、外部からのイベント（通知やスケジュール）をトリガーに自律的に動くエージェントとして位置づけられます。 ...

Claude Code でリファクタリングや新機能追加を行うと、既存機能の出力品質が意図せず劣化することがある。機能は正しく動いておりテストも通るが、ユーザーが期待する情報が出力から消えている。この記事では、実際に遭遇した「静かなデグレード」の事例と、出力仕様テストによる対策を紹介する。 何が起きたか 日本株・BTC のトレーディングシステムで、日次の投資提案を GitHub Issues に自動投稿している。このシステムにポートフォリオ統合最適化機能を追加した際、以下の流れで問題が発生した。 統合最適化機能を追加。成功時は 1 つの統合 Issue に「市場概要」「総評」を含む詳細な分析を出力する設計 失敗時のフォールバックとして、銘柄別 Issue + サマリー Issue を作成するパスも実装 テスト全パス、PR マージ ある日、ポートフォリオ最適化が失敗しフォールバックが発動 サマリー Issue を見るとポートフォリオ一覧とリンクテーブルだけ — 「結局ホールドすべき？買うべき？」がわからない 統合パスには存在する「銘柄横断の総評」が、フォールバックパスでは最初から実装されていなかった。しかしテストは両方とも通っていた。 サマリー Issue の Before / After デグレード状態（修正前）: 1 2 3 4 5 6 7 # 2026-04-03 総合投資評価 ## 現在のポートフォリオ （ポジション一覧テーブル） ## 銘柄別計画 （リンクテーブル） ## 子課題チェックリスト （チェックボックス一覧） 修正後: ...