コンピューター

ここ数ヶ月、ClaudeやCodexといったツールを使ってコードを書いている中で、最も強く感じているのは、「プログラマーが不要になる」ということではなくて、以前は新人に練習課題として出していたような作業まで、AIがすでに叩き台（ドラフト）を生成してくれることだ。

スキャフォールドの作成、いくつかのテストの追加、ついでに小さな機能を修正する…という操作を続けていくと、その速度があまりにも速くて、なんとも言えない「意難平」な気分になる。

私のような卒業から10年が経過した人間にとって、正直なところ、これは主に効率化の問題です。なぜなら、どこを信じてよいか、どこを信用してはいけないか、そして表面上は動作しているように見えても、実は後に罠（落とし穴）がある場所などを概ね把握しているからです。しかし、新卒者にとっては、この問題はそれほど簡単ではありません。AIは単に数時間の肉体労働を奪ってくるだけでなく、「初心者がどうやって無知から熟練へとなるか」という確立された道筋そのものを圧縮してしまっているようなものです。これが私が改めて書きたいと考えている点でもあります。

呆然とした。

ChatGPTの公式側では、トークンや費用を直接確認するのが難しいため、サードパーティのプラットフォームを利用して、CodexでGPT-5.4とGPT-5.5を用いて同種のタスクを一度実行しました。思考モードはすべてhighに設定しています。結果は非常に明快でした。簡単な問題については比較的穏やかで、GPT-5.5はGPT-5.4よりおよそ30%高価です。しかし、複雑なタスクになると、費用が直接2.6倍に跳ね上がり、リクエスト回数とトークン消費量も共に増加

私自身の判断も非常にストレートに申し上げますが、これは単に「5.5のほうが単価が高い」という一言で片付けられる問題ではありません。簡単なタスクの場合、費用は主に単価が要因となります。しかし、複雑なタスクの場合、実際にかかっているコストは、その呼び出しチェーン（処理の一連の流れ）全体です。

とはいえ、逆から見ると、5.5はあなたの手戻り（作り直し）のコストを肩代わりしてくれている側面があります。モデル側がより深く考え、より多くの工程を経て実行し、より多くチェックしてくれるため、最終的に請求されるのは単一の回答に対する費用ではなく、一連のアクション全体に基づいた費用になります。結果として、人間側も何度もやり取りをして手間取る回数が減ります。

結果はかなり

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

公式サイトのタイムラインを見ると、今回の集中更新は連続していることが分かります：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企業が今売っているのは、もはやモデルそのものだけではなく、「誰が能力を手に入れられるか、どれだけの能力を手に入れられるか、そして手に入れた後にどのような監査や制約を受けるか」という一連のアクセス制御システムです。モデルはますます危険なツールに近づいており、リリースペースもライセンスの発行に似てきています。

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

最近アルゴリズムサービスを書いていて、twap や vwap のようなモジュールをいくつか展開したところ、またこの古い問題に直面しました。

C++ でクラス名に頼ってセマンティクスを無理やり押し付けると、名前はすぐに制御不能になります。TwapOrderManager、VwapOrderManager、AlgoOrderManager のようなものは、書き進めているうちに「自分の構造が手に負えないことはわかっているけど、とりあえずプレフィックスを付け足しておこう」という感じになってしまいます。端的に言えば、フォルダで階層分けをして、さらに namespace を一つ追加するのは、コードの潔癖症なのではなく、C++ に Java のようなネイティブな package システムがないことによる空隙を埋めているのです。

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

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