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 対応のアプリ・フレームワークはすべて利用できる見込み。 ...

HubSpot CMS で「変更したのにページに反映されない」「自分の環境だけ古いまま見える」といった経験はないだろうか。HubSpot は CDN とサーバーサイドキャッシュが多層構造で動作しているため、保存直後にブラウザでアクセスしても古いキャッシュを掴んでしまうことがある。 そんなときに役立つのが、URL の末尾に付けるだけでキャッシュをバイパスできる ?hsCacheBuster クエリパラメータだ。ただし「キャッシュをクリアする」のではなく「自分のリクエストだけキャッシュを経由させない」挙動なので、その違いを押さえて使うのがポイントになる。 ?hsCacheBuster の基本的な使い方 確認したいページの URL の末尾に ?hsCacheBuster を付与してアクセスする。 1 2 https://www.example.com/landing-page?hsCacheBuster https://www.example.com/landing-page?hsCacheBuster=001 任意の値（数字や文字列）を渡すこともできる。値を変えながらアクセスすれば、確実に毎回キャッシュを通さずに最新コンテンツを取得できる。これは、同一 URL が CDN にキャッシュされる仕組みのため、値が変わると別 URL として扱われ、毎回オリジンから取得されるためだ。 1 2 https://www.example.com/landing-page?hsCacheBuster=20260423-1 https://www.example.com/landing-page?hsCacheBuster=20260423-2 重要 — あくまで「自分の環境」のキャッシュバイパス ?hsCacheBuster で起きるのは 自分のリクエストに対してのみ、キャッシュを経由せず最新コンテンツが返る という挙動である。 ✅ 自分の画面では最新の HTML が確認できる ❌ 他のユーザー（クライアントや訪問者）にもすぐに反映されるわけではない ❌ HubSpot 側のキャッシュ自体が無効化されるわけでもない つまり「変更が自分には見えるが、他の人にはまだ反映されていない」というケースは珍しくない。「キャッシュを消す」ボタンではなく「キャッシュをバイパスして取得する」ボタン と理解しておくのが正確だ。 公開ユーザーにも即時反映させたいとき 公開ユーザー全員にすぐ反映させたい場合は、ページエディター側で軽微な変更をかけて保存し直すのが手軽な方法だ。 ヘッダー HTML や設定欄に半角スペースを 1 つ追加して保存 そのまま再度保存（スペースを消す） これで HubSpot 側がページを再生成し、CDN キャッシュも切り替わる。実コンテンツに変更を加えなくても、保存をトリガーすれば再ビルドが走るのがポイントである（2026 年 4 月時点での挙動）。 ...

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 対応 インターフェースが日本語に対応しており、日本のユーザーでもすぐに使い始められる。 ...