Ai

結果はかなり

今夜、モデルのメッセージを追っていると、本当に目が点になった。

公式サイトのタイムラインを見ると、今回の集中更新は連続していることが分かります：2026-04-20 にMoonshotがKimi K2.6をトップページに掲げました。2026-04-22にはXiaomiが正式にMiMo-V2.5とMiMo-V2.5-Proをリリースし、2026-04-23にはOpenAIがGPT-5.5を公開し、API料金も同時に引き上げられました。そして2026-04-24にはDeepSeekがまたV4 Previewを推しました。ついでに言うと、グループチャットでよく話題になる「Xiaomi 2.5」というのは、厳密に言えばぼんやりとしたコードネームではなく、Xiaomi MiMo-V2.5 / V2.5-Proのことを指します。

私の現在の判断は非常に明確です。今回の波は単なるモデルのリリースブームではなく、3つの要素が同時にぶつかり合っています――すなわち、**モデル能力、API価格設定、チップスタックの支配権（または所有権）**です。これらの一つだけを語る人は、基本的に視点が偏りがちです。この三つの要素が絡み合うからこそ、大規模言語モデル（LLM）という分野はこれほどまでに過熱しているのです。

この数日、Anthropic が 2026 年 4 月 7 日にリリースする「Project Glasswing」を見かけましたが、最初に感じたのはちょっと呆れました。それはまたモデルのスコアが高くなったからではなく、最も強力な能力を最初から特定のグループ（AWS、Apple、Google、Microsoft、Linux Foundationといった守備側）にロックしてしまったからです。

私自身の判断は非常に直接的です。この件は、また別のベンチマークで記録を更新することよりも重要です。最先端のAI企業が今売っているのは、もはやモデルそのものだけではなく、「誰が能力を手に入れられるか、どれだけの能力を手に入れられるか、そして手に入れた後にどのような監査や制約を受けるか」という一連のアクセス制御システムです。モデルはますます危険なツールに近づいており、リリースペースもライセンスの発行に似てきています。

この数日、Blockが2026年2月末に1万人以上のチームから4000人を削減したのを見て、正直ショックを受けました。私はこれまでずっと金融IT、取引フロー、米英株、システム基盤といった分野に携わってきましたので、「効率化」「自動化」「コスト削減と効率向上」といった言葉には慣れていますが、お金やコンプライアンス、リスク管理にこれほど近いフィンテック企業が、AIを解雇理由として公言するのは、やはり胸が沈みます。

私の現在の判断は非常に直接的です。AIによる人員削減が最も恐ろしい点は、ある日ニュースで流れる解雇リストそのものではなく、「より小さなチームでも多くの仕事ができる」という前提が会社にデフォルトとして浸透し始めることです。これは、退職者が補充されないこと、初級職の減少、そしてheadcount（人員数）がさらに厳しく管理されることを意味します。2025年4月から2026年4月にかけて、この風はアメリカではまだ吹いています。中国国内では、あのような目立つ大規模な解雇の波は一時的に見られませんが、静かながらも圧迫はすでに始まっています。

昨日書いた《HermesをOpenClawの代替品と見なすのは危険かもしれない》を書き終えた後、私は周りのドキュメントを巡回しました。巡るほど、この二つのものの違いを見るには、機能だけを見ているだけでは不十分で、トークンがどのように消費されるかを見る方が、より直接的だと感じました。

私の判断は、まずここに置きます。

OpenClaw はデフォルトで長期的にオンラインのワークベンチのようなものであり、多くのアイデンティティ、ルール、ワークスペースファイル、メッセージ面制約などが自然に各対話フローに引き継がれるため、ベースラインは通常重くなります。一方、Hermes は明らかに抑制的で、多くのコンテキストはオンデマンドで発見され、オンデマンドで注入されます。システムプロンプトも意図的に安定したプレフィックスを維持しており、デフォルトではトークンを抑えやすいです。

もちろん、これはHermesが必ずしもより節約できるという意味ではありません。memory provider、skills、sub-agent、長いツール出力をすべて有効にすると、同じように大量のトークンを消費します。しかし、率直に言って、これら2つのアーキテクチャは、初日から異なる方法でトークンを消費しています。

この二日間、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つの空白部分――起動前のビルドとブレークポイント後の変数表示――を完璧に埋めてくれたのです。