記事一覧

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 氏が提示したのは、ハーネスエンジニアリングを「ルールを書く行為」ではなく 「開発プロセスを設計する行為」 として捉え直す考え方だ。 ...

r.kagaya 氏（@ry0_kaga、AstarMinds CTO）が Zenn に公開した記事がある。「ハーネスエンジニアリングとは何で、何ではないのか 〜作る側のハーネス、使う側のハーネス〜」という記事だ。ハーネスエンジニアリングをめぐる言葉の混乱を整理し、エージェントハーネスとユーザーハーネスという2層の区分を提示している。 CLAUDE.md や Skills を書けば「ハーネスエンジニアリングをやっている」と言える。でも、それはハーネスエンジニアリングの全体ではない。この記事ではその全体像を整理する。 そもそも「ハーネス」の定義が割れている 前提として、ハーネスエンジニアリングという言葉には統一された定義がない。同じ言葉を使いながら、各社・各人が指しているものが違う。 用語の来歴 「ハーネス」の原義は馬具だ。馬を馬車に繋ぎ、方向を制御し、力を伝達する装備。ソフトウェア文脈では 2020 年の lm-eval-harness（言語モデル評価ハーネス）が初出とされる（r.kagaya 氏による整理）。2024 年に All Hands AI / OpenHands が「エージェントハーネス」に拡張。2026 年に Mitchell Hashimoto（Terraform 創業者）が「Engineer the Harness」と命名し、OpenAI の記事で広まった。 各社の定義 誰が 何と言っているか LangChain (Vivek Trivedy) 「Agent = Model + Harness。モデルでなければハーネス」 Anthropic 「LLM を呼び出し、ツールコールをルーティングする制御ループ」 OpenAI 宣言的制約 + サンドボックス + スケーリング Böckeler / Martin Fowler サイバネティクス的制御。フィードフォワード × フィードバック Phil Schmid (Hugging Face) Model = CPU, Harness = OS Bedi (Composio CEO) 「システムエンジニアリングのサブセットに新しい名前をつけているだけ」 LangChain の「モデルでなければハーネス」は極めて広い。Anthropic の「制御ループ」はエージェント実装寄り。「そもそも新しい概念ですらない」と言う人もいる。さらにベンダー（作り手）と利用者（使い手）で意味が違うという構造的な問題もある。 ...

AWS が公開した「AI 駆動の業務変革手法 AI BPR」の記事が話題になっている。単なる成功事例ではなく、「正しいアプローチが全く機能しない」という壁に正直にぶつかった失敗報告から始まる点が異色で、AI 導入に苦戦する多くの組織にとって示唆に富む内容だ。 AWS が3ヶ月間で発見した「正しいアプローチが機能しない」現実 AWS は自社で3ヶ月間、お客様に AI エージェント導入プログラムを提供してみた。最初に試みたのは、いわゆる BPR の教科書通りのアプローチだ。 ゴール設定 業務フロー分析 ボトルネック特定 AI エージェントで解決 計測 整然としたフローに見えるが、現場から返ってきた反応は想定外だった。 「AI エージェントに任せるのは BCP 上危険」 「提案の枠が狭くて大きな進歩を感じない」 一見もっともらしい抵抗なのだが、よく分解すると全然別の構造が見えてくる。 抵抗の本質：2つの根本的障壁 1. アイデンティティへの脅威 長年積み上げてきた専門性が AI に代替されることへの「存在意義の危機」だ。Stanford の研究でも、45% が AI の精度を懸念し、23% が職の代替を恐れているという。これは能力の問題ではなく存在意義の問題であり、ツール改善では解決できない。 2. 責任の所在を人間に残したい組織心理 「この業務は◯◯さんが詳しい」という言葉の裏を返せば、責任分担の合意だ。AI に委譲するということは、業務停止時の責任も IT 部門に一気に流れ込むということ。それは組織として受け入れがたい。 この2つが合わさると、「やっぱり人間でないと難しい」という一見合理的な「落としどころ」に着地してしまう。AWS はこれを Argyris の言う防衛的ルーティン（defensive routines）・熟達した無能力（skilled incompetence）と結びつけて説明しており、ここが本当に鋭い。 アプローチの転換：「課題は何ですか？」を捨てる AWS が下した判断は、AI BPR を一旦抜本的に見直してゼロから組み直すことだった。 従来の「課題は何ですか？」という問いかけをやめ、「強みは何ですか？」から入る設計に変えた。 「課題は何ですか？」という問い自体が、実は防衛反応を誘発する最悪のフレームだったという発見も重要だ。問題を分析して修正するアプローチは、当事者を「自分たちは問題を抱えた存在」として位置づけてしまう。 Appreciative Inquiry の採用 具体的に採用したのが、Cooperrider & Srivastva が提唱した Appreciative Inquiry（アプリシエイティブ・インクワイアリー、以下 AI）という手法だ。 問題を分析して修正するのではなく、組織の既存の強みと成功体験を発見して増幅することで変革を起こす。 Appreciative Inquiry とは何か AI は 1987 年に Case Western Reserve University の David Cooperrider と Suresh Srivastva が発表した組織開発手法だ。Cooperrider の博士論文（1986 年）が出発点で、以後 40 年近く理論的な拡張と実践が積み重ねられてきた。日本でも 2005 年以降、ヒューマンバリュー社が Diana Whitney を招聘して『ポジティブ・チェンジ』として翻訳・紹介したことで広まっている。 ...

「自分のPCでローカルAIを動かしたい、でもどのモデルが動くか分からない」。そんな悩みを一発で解決してくれる Web サービスが CanIRun.ai だ。インストール不要、登録不要で、サイトにアクセスするだけでハードウェアを自動検出し、数百のモデルに対して動作可否を判定してくれる。 何ができるのか CanIRun.ai は、ブラウザの WebGPU API を使って以下のハードウェア情報を自動取得する。 GPU の種類と VRAM 容量（GPU 名を WebGPU/WebGL で取得し、内部 DB から VRAM を割り出す） GPU メモリ帯域幅（内部スペックシート DB から参照） システム RAM CPU コア数 取得した情報をもとに、カタログに登録された全モデルとの適合性を即座に算出する。 6 段階の互換性評価 各モデルに対して、S〜F の 6 段階グレード が色分けで表示される。 グレード ラベル 意味 S Runs great 余裕で動作 A Runs well 快適に動作 B Decent まずまず動作 C Tight fit ギリギリ動作 D Barely runs かろうじて動作 F Too heavy 動作不可 グレードに加え、アーキテクチャの種類・コンテキストウィンドウサイズ・量子化レベル（Q2_K〜F16 といった精度とサイズのトレードオフを示すレベル）ごとのメモリ要件など、詳細な技術情報も確認できる。 対応モデルの幅広さ カタログは 1GB 未満の軽量モデルから数百 GB の巨大モデルまで 網羅している。 ...

スタートアップコミュニティで知名度の高い Greg Isenberg が、Obsidian と Claude Code を組み合わせて「24時間365日稼働するパーソナル AI オペレーティングシステム」を構築する方法を公開した。閲覧数 110 万超、ブックマーク 17,000 超と大きな反響を呼んでいる。 なぜ Obsidian × Claude Code なのか 多くの人は AI を「汎用チャットボット」として使っている。セッションを開くたびに自己紹介し、プロジェクトの背景を説明し直す——この繰り返しが生産性のボトルネックになっている。 Greg が提案するアプローチは、自分の思考・知識・文脈をすべて Obsidian ボルト（ノート群）に蓄積し、Claude Code がそれを読み込んで行動するというものだ。人間が書き、AI が読んで実行する、という明確な役割分担がポイントになる。 10 ステップで始めるパーソナル OS ステップ 1: 全てを Markdown で書く 日報・プロジェクト概要・自分の信念・人脈・議事録——あらゆる情報を Markdown ファイルとして Obsidian ボルトに記録する。フォーマットを統一することで、Claude Code が構造的に読み取れるようになる。 1 2 3 4 5 6 7 8 9 10 11 vault/ ├── daily/ │ └── 2026-04-22.md # 日報 ├── projects/ │ └── my-startup.md # プロジェクト概要 ├── people/ │ └── john-doe.md # 人脈メモ ├── beliefs/ │ └── product-philosophy.md # 信念・哲学 └── meetings/ └── 2026-04-22-kickoff.md # 議事録 ステップ 2: ノート同士を自分の思考回路のようにリンクする [[プロジェクト名]] 形式のウィキリンクでノートを繋ぎ、自分の思考の連鎖を反映させる。単なるメモの集合ではなく、考え方のグラフを構築することが目的だ。 ...

Google の NotebookLM に触発されたオープンソース実装 open-notebook が海外のテック界隈で注目を集めている。データを一切外部に送信しない完全ローカル動作を売りに、Docker で約2分で立ち上げられる手軽さも人気の理由だ。 open-notebook とは open-notebook は、NotebookLM の主要機能をすべて再実装した OSS プロジェクト。2024年10月に公開され、2026年4月時点で 22,000 スター超 を獲得している。 公式サイト: open-notebook.ai 主な機能 マルチソースの知識統合 PDF・動画・音声・ウェブページを横断で読み込ませ、AI とのチャット形式で対話できる。NotebookLM と同様の使い勝手を、完全ローカル環境で実現する。 多数の AI バックエンドに対応 OpenAI・Anthropic（Claude）・Google Gemini・Ollama・Mistral・Groq・xAI・Deepseek など主要なプロバイダーを幅広くサポートしている。 バックエンド 備考 Anthropic (Claude) クラウド OpenAI (GPT) クラウド Google Gemini クラウド Ollama ローカル・完全無料 Mistral / Groq / xAI / Deepseek など クラウド Ollama を選択すれば、外部サービスへの通信がゼロのオフライン環境でも完全無料で運用できる。 ポッドキャスト風音声の生成 複数の話者でポッドキャスト形式の音声を自動生成できる。NotebookLM が2人固定なのに対し、open-notebook は話者数をカスタマイズ可能な点が差別化ポイント。 REST API 完備 REST API が標準搭載されているため、企業内アプリへの組み込みや外部サービスとの連携が容易。n8n や LangChain などのワークフローツールからも呼び出せる。 日本語 UI 対応 インターフェースが日本語に対応しており、日本のユーザーでもすぐに使い始められる。 ...

2026 年 3 月末、Alibaba は alibaba/anolisa を公開しました。これは同社が保守するサーバー向け Linux ディストリビューション Anolis OS を AI Agent 実行基盤として再構築した「Agentic OS」プロジェクトで、正式名称は ANOLISA（Agentic Nexus Operating Layer & Interface System Architecture）です。 本記事では、ANOLISA が解こうとしている問題と、公開されている 4 つのコアコンポーネント（Copilot Shell / Agent Sec Core / AgentSight / OS Skills）の役割、そして開発者が今すぐ触れられる導入手順を整理します。 ANOLISA が目指すもの ANOLISA は Anolis OS の「Agentic 進化版」と位置づけられており、AI Agent ワークロードをサーバー側で安全かつ観測可能な形で動かすためのベストプラクティス実装を狙っています。LLM / Agent がコード編集・シェル実行・ネットワークアクセス・プロセス管理といった OS レベルの操作を当たり前に行う時代において、「アプリケーション境界で守る」従来型セキュリティでは不十分になってきました。ANOLISA はその問題意識を背景に設計されています。 リポジトリ: alibaba/anolisa ホームページ: agentic-os.sh ライセンス: Apache License 2.0 主言語: TypeScript（Copilot Shell）/ Rust（AgentSight）/ C（eBPF プローブ） 公開: 2026 年 3 月 30 日（初版リポジトリ作成） 4 つのコンポーネント ANOLISA は単一のカーネルモジュールではなく、Agent 実行に必要な「シェル・セキュリティ・観測・スキル」を別々のプロダクトとして分離し、RPM で同居運用する構成を取っています。 ...

「もう 2 ヶ月以上、手でコードを書いていない」 Claude Code の生みの親であり、Anthropic でその開発を率いる Boris Cherny がそう語ったのは 2026 年 1 月のことだ。Andrej Karpathy の問いかけに応え、X への投稿でこう明かした。 “For me personally, it has been 100% for two+ months now, I don’t even make small edits by hand.” そして今、そのワークフローが広く注目を集めている。2 日間で 49 の Pull Request を出荷、コードは 100% AI 生成という実績が報告され、X では 30 分間のセッション動画が公開され 300 万回近く再生された。 Boris Cherny とは Boris Cherny は、Claude Code を 2024 年 9 月に社内の個人プロジェクトとして始めた人物だ。当初は自分のコーディングを助けるためのツールだったが、Anthropic 社内でその有効性が認められ、正式なプロダクトへと進化した。 彼は後にこう振り返っている。 “When I created Claude Code as a side project back in September 2024, I had no idea it would grow to what it is today.” ...

Claude Code の Skills を使い込むうちに「あれ、前と挙動が違う……」と感じたことはないだろうか。~/.claude/settings.json に 1 行追記するだけで解決できる。原因は auto-memory だ。 Claude Code の auto-memory が Skills の挙動を変える仕組み Claude Code は会話のたびに学習内容を Memory（~/.claude/projects/.../memory/MEMORY.md）へ自動で書き込む機能（auto-memory）を持っている。 問題はこの Memory の内容が次の会話でコンテキストウィンドウに自動挿入される点だ。これにより、Skills に記述した指示と競合し、設計どおりの挙動から少しずつずれていく。 会話を重ねるほど症状が顕著になるため、原因の特定に時間がかかりやすい。 解決策：autoMemoryEnabled: false ~/.claude/settings.json に 1 行追記するだけで解決する。ファイルが存在しない場合は新規作成し、既存の設定がある場合は {} 内に追記する。 1 2 3 { "autoMemoryEnabled": false } これで Memory への自動書き込み・読み込みが停止し、auto-memory 機能全体が無効化される。 影響範囲 機能 autoMemoryEnabled: false にしたときの変化 Memory への自動書き込み・読み込み 停止 CLAUDE.md の読み込み 変化なし（従来どおり動作） Skills に書いたルールの適用 変化なし（従来どおり動作） CLAUDE.md や Skills の設定はそのまま有効なので、プロジェクト固有のルールが失われる心配はない。 ...