マオタイ、純利益が初めて落ち込むのは、単に若者が白酒を飲まなくなったからだけではない

2026-04-17、貴州茅台が2025年の年次報告サマリーを公開しました。 年次報告の要約によれば、売上高は1688.38億元で前年同期比1.21%減少し、親会社帰属純利益は823.20億元で前年同期比4.53%減少しました。 さらに下を見ると、本当に厳しいのは第4四半期であり、四半期純利益が2024Q4254.01億元から`176.9

この件は、茅台という銘柄をどのように見るかに直接影響するため、個別に掘り下げる価値があります。かつて多くの人は、茅台を永遠に右肩上がりの消費神話だと捉えており、若者が飲むかどうかといった点は些細な問題でした。しかし、現在の状況はそうではありません。

若者が白酒に本能的に興味を持たないのは当然の事実ですが、これはむしろ「遅い変数(slow variable)」のようなものです。年次報告書に見られるような突然の転換点という動きの裏側には、古いビジネス需要全体、古い富の分配方法、そして古い「体面」消費システムといったものが縮小しているように見えます。

最強モデルを先にロックし、AI企業がゲートキーパーになり始めた

この数日、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のトークンの消費方法は違います。

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

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

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

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

Hermes を OpenClaw の代替品として見ると、最初は偏りがあるかもしれません。

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

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

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

AI はデモの作成が速く、修正作業も本当に速いです。

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

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

VS CodeでC++を扱う際は、CMakeとGDB Printerを忘れないように。

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