Ai

この二日間、HermesとOpenClawのドキュメントを何度も読み返しましたが、読むほどに、多くの人がこれら2つのプロジェクトを一緒にして比較していますが、実は最初から比較の軸がずれていると感じました。

もちろん、これらはすべて「パーソナルAIアシスタント」を構築しています。メッセージの受信、モデルの呼び出し、ツールの実行、そしてある程度のコンテキスト保持が可能です。Hermesはさらにはhermes claw migrateという専用コマンドまで用意しており、OpenClawユーザーの一団を受け入れることを明白に知っているようです。

しかし、端的に言えば、Hermes は OpenClaw のスキン変更版ではなく、OpenClaw もメッセージ入力口がいくつか増えたエージェントフレームワークではありません。一方は Gateway から外側へ伸びていき、もう一方は AIAgent から外側へ伸びています。この違いを先に理解しないと、後でアーキテクチャや設計思想、エコシステムについて話しても、どんどん話が混乱していきます。

最近AIを使ってC++の小規模なプロジェクトを立ち上げたんだけど、一番「やられる」瞬間は、それがコードを書いてくれないことじゃなくて、たった3分でそれっぽくディレクトリツリーを組み立ててくれて、ついでにサードパーティライブラリをいくつか突っ込んで、デモが本当に動く時なんだよね。問題もそこにある。新しく導入したライブラリが具体的に何に対応しているのか、コンパイルのパスはどうなるのか、どこに境界線があるのか、まだ把握できていないのに、後で手戻りが発生するのはほぼ避けられない。

最近、AIプログラミングで最も怖いのはモデルの賢さではなく、最初からやりすぎなところだと感じています。特にC++のような、しっかりしたフレームワーク（脚手架）に頼れない言語の場合、手順を一つ間違えるだけで、コンパイル、リンク、ライブラリのバージョン、ディレクトリ構造など、後でいくつもの手間が増えてしまいます。

以前VS CodeでC++をデバッグするとき、設定は基本的にlaunch.jsonに留まっていて、せいぜいGDBの行を追加する程度でした。 programを埋めて、gdbを埋めて、ブレークポイントを設定する。それで終わり？毎回デバッグ前にターミナルで手動でcmake --buildしないといけませんでした。 さらに面倒なのは、カスタム価格、契約、注文タイプなどでブレークポイントを打った後、VS Codeのデバッグウィンドウには内部フィールドが大量に表示されるだけで、データ自体は正しいのですが、人間が理解できる言葉になっていない点です。 この件がおかしいと思う点は、以前見たチュートリアルもlaunch.jsonまでしか触れていなかったことです。最近AIに新しいプロジェクトの設定を依頼したところ、なんと自動でpreLaunchTaskとgdb_printers.pyを追加してくれたので、「VS CodeでC++をデバッグするって、ただGDBを起動させるだけじゃないんだな」と気づきました。デバッグ前にCMakeのコンパイルを自動実行できるし、ブレークポイントで停止した後に、GDBにPythonスクリプトをロードさせて、ビジネスロジックの型を自分が見やすい形に整形させられるんです。 正直なところ、これは何かの「裏ワザ」というわけではありません。 しかし、C++の日常的なデバッグにおける非常に面倒な2つの空白部分――起動前のビルドとブレークポイント後の変数表示――を完璧に埋めてくれたのです。

今回フォーラムを巡回していて、一番印象に残ったのは、「またランキングを出した」というところではなく、「VRAMが足りないから、パラメータがどれだけ大きくても無駄だ」という、かなり生易しい（陳腐な）一言でした。

以前は「モデルが遅い」ことを計算能力の問題だと捉えがちでした。しかし、後になってよく気づいたのは、多くのケースでGPUの計算能力が足りないのではなく、データが適切な場所に留まらないことが原因だということです。メモリのパスが少し変わるだけで、トークン速度は少し落ちるというレベルではなく、直接落ちてしまいます。

ランキングだけを見ると、一番心が動くのは間違いなく 31B です。 しかし、実際にマシンを前にすると、やはりアップグレードされていない RTX 3060 12GB の方が、判断はすぐに変わります。どう言えばいいか、ローカルにデプロイするということは、最後に一番派手なものが勝つのではなく、長く一緒にいられそうなものを選ぶことなんです。私にとっては、今回まず試す価値があるのは 31B ではなく、26B A4B です。

初日に私がやりたかったことはとてもシンプルでした。Gemma 3 に対応するアップグレード版を見つけて、まずダウンロードして動かしてみることです。 しかし、全体をざっと見ていくと、少し戸惑いを覚えました。以前慣れていた 4B / 12B / 27B という命名規則がなくなり、代わりに E4B、26B A4B、31B といったものが現れたのです。どう言えばいいか、今回Googleが真に変わったのは、単にモデルのサイズだけではなく、「この一連のモデルをどう理解すべきか」という部分まで変わってしまったからです。

Codex を使っている期間、ずっと気になっている問題があります。デフォルトの思考レベルが medium なのですが、ネットで話題になっている GPT-5.4 のような話を聞くと、皆とてもすごい口ぶりをします。実際に自分で試してみると、medium、high、xhigh は一体どれくらい違うのか、公式からも特に分かりやすい表が出ていません。

私なりの結論はかなり明確になりました。普段のコーディングでは、私は迷わず high を使う方がいいと思っています。medium が使えないわけではありません。ちょっとした作業や、細かい修正、方向性を試す程度なら問題ありませんが、複数のファイルを変更したり、要求に曖昧さがあったりして、コードを見ながら判断を求められるような状況だと、medium では計算能力の配分を間違えやすい気がします。逆に xhigh はあまり頻繁には使いません。行き詰まった大きなタスクのために取っておくのが良いと思います。

倉庫の構成を一周確認した結果、逆に確信したことがあります。このシステムは、単体のモデルがどれだけ強力かではなく、どのレイヤーにコストを負わせるべきか、という点にかかっているということです。

最も明白なシグナルは、現在有効な published.runtime.json が依然として 2026年4月2日に生成された minimax-m2 であることです。しかし、2026年4月3日16:38の 5f17088 は、blog-style-suite のデフォルトプロバイダーをローカルの LM Studio 内の gemma-4-26b-a4b に切り替えています。これは一見すると前後で矛盾しているように見えますが、実はそうではありません。むしろ、このパイプラインに分業が始まったことを示しています。