コンピューター

ランキングだけを見ると、一番心が動くのは間違いなく 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 に切り替えています。これは一見すると前後で矛盾しているように見えますが、実はそうではありません。むしろ、このパイプラインに分業が始まったことを示しています。

トークンが十分にある場合、最も手っ取り早い方法は非常に粗暴ですが、過去の記事をそのままモデルに投入し、自分で学ばせることです。

問題は、この方法はたまに1記事書くのには適していますが、繰り返し書くのには適さないということです。もしブログ執筆を長期的なワークフローとして真剣に取り組むのであれば、「生データ（歴史的な文章）」というアプローチは、すぐに「高コストで散漫」になってしまいます。

昨年、多くの AI に関する記事を書きました。あの頃の最も手間のかかるプロセスは、まず自分でアウトラインや問題リストを整理し、大規模言語モデルに本文を出力させてもらい、その後その内容をローカルの md ドキュメントにコピー＆ペーストし、フロントマター、タグ、カテゴリ、タイトルなどを補完してから公開するというものでした。 このプロセスが使えないわけではありませんが、非常に面倒です。本当に時間がかかるのは本文ではなく、本文の外側の繰り返しの作業です。特に最近 Codex を使いすぎてからは、その不自然さがより強く感じられます。それはリポジトリを読み込めるし、ファイルを編集でき、資料を補完できるだけでなく、記事を直接ディレクトリに書き込むこともできます。もし私がまだ手動でコピー＆ペーストを繰り返していると、まるで人間がツールの足を縛っているような気分になります。

今年の春節、国内のいくつかのAI企業が資金を投じているのを見て、私の第一印象は賑やかさではなく、「見覚えがある」というものでした。

テンセントの元宝は2月1日に10億人民元の現金红包（お年玉）を配り、百度文心は1月26日から3月中旬まで継続して5億人民元の红包を出し、アリババの千問は2月6日には直接30億人民元の「ご馳走計画」を展開し、豆包は春節の晩番組とAIのインタラクションを利用して参入してきました。私の判断は非常に単純で、これは前時代のインターネットが残した慣性的な動きに過ぎません。まずは人々をアプリに引き込み、利用頻度を作ることが目的なのであり、それ以降は後回しにできると考えています。

この数日、AIプログラミングについて見てきましたが、さっきまでみんながMCPの話をしていて、次の瞬間にはまたSkillの話をしています。この言葉を初めて目にする人は、本能的にこれをまた新しいプロトコルか、あるいは高度なプロンプトだと捉えがちです。

私の判断は非常にシンプルで、SkillはMCPの座を奪いに来たものではなく、むしろエージェントに職種マニュアルのようなものを提供している感じです。MCPが解決するのは「エージェントが外部世界と接続できるか」という点であり、Skillが解決するのは「接続した後、どのような手順で確実にタスクを遂行するか」という点です。これらは代替関係ではなく、むしろ前後関係に近いです。

端的に言えば、MCPはエージェントに手足を与え、Skillはエージェントが勝手に動かないようにするためのものです。