AIモデルは「どれが賢いか」⁠から「どう振り分けるか」⁠へ ― 今週のエンジニア市場、5本と市場の動き

AnthropicとOpenAIが同日に値下げ。モデル選びより「振り分け設計」⁠の時代へ

何が起きたか

9月22日、AnthropicがClaude Opus 5.5を、OpenAIがGPT-6 Sol／Lunaを発表しました。Opus 5.5は前世代より実行コストが40%減り、出力速度は30%以上上がったとされます。API価格は入力100万トークンあたり4ドル、出力が20ドルで、20%の値下げです。OpenAIのSol／LunaはAPI価格を50%下げ、日常業務向けで推論が強いSolと、安く速く大量処理に向いたLunaの2段構成で出してきました。

何が変わるか

2社とも、性能の話より「安くなった」⁠を前面に出しています。これによって、これまで「トークン代が合わないから人がやる」⁠とされていた長時間の調査や全件レビューなどが、まとめて採算に乗り始めます。

もう一つ見逃せないのはベンチマークの割れ方です。エージェント的なコーディング能力を測るTerminal-Bench 4.0ではOpus 5.5が勝ち、科学研究向けのTerminal-Bench-ScienceではGPT-6 Astraが勝っています。「どのモデルが一番いいか」⁠という問いは成り立ちにくくなり、差がつくのは「どの処理にどのモデルを当てるか」⁠という振り分け（ルーティング）⁠の設計になっていきます。

DHHが「pencils down」⁠宣言。37signalsは手書きコードをやめ、HEYはRust化でCPU99%減

何が起きたか

Ruby on Railsの生みの親で37signalsのCTOでもあるDHH（David Heinemeier Hansson）氏が、9月23〜24日のRails World 2026の基調講演で、37signalsは通常の開発で手書きのコードをやめたと述べました。手で書く必要が出たときは「なぜエージェントにできなかったのか」⁠を問う運用だといいます。

DHH氏はあわせて、メールサービスHEYのバックエンドをRustで作り直した結果、CPU使用率が99%、メモリが95%減ったと説明しました。また、Railsの「設定より規約」⁠という思想は、エージェントに渡す文脈が少なくて済むのでAIと相性がよい、⁠とも述べています。なお、SNSで「Railsの終わり」⁠と誤読されたことに対しては、終わるのは「手書きコードの時代」⁠だと補足しています。

何が変わるか

注目したいのは、AIが実装コストを下げたことで、「書き直すコストに見合わない」⁠と避けられてきた低レイヤ・高性能言語への移行が、割に合うようになってきている点です。9月にはShopifyがモバイルアプリをReact NativeからSwift／Kotlinに戻す判断を公表しており、同じ構図が続いています。

技術選定の軸にも「エージェントに渡す文脈が少なくて済むか」⁠が加わります。構造がプロジェクトごとにバラバラなスタックは、この軸では不利になるかもしれません。

ZOZO、問い合わせ対応をAIエージェント5つで自動化。回答までの日数は中央値6日→1日に

何が起きたか

ZOZOの検索基盤ブロックのXEI氏が、社内からSlackに届く問い合わせへの対応をAIエージェントで自動化した実装を、ZOZO TECH BLOGで公開しました（9月24日）⁠。以前は問い合わせ対応がチームの稼働の約5.8%（月に約10人日）⁠を占め、回答までの日数は中央値で6日かかっていました。

構成は1つの万能エージェントではなく、5つの役割に分かれています。過去事例の検索、回答案の生成、回答をコードと突き合わせる検証、解決済み事案の知識化、そして全体の起動管理です。結果、対応工数は3.4%に、回答までの日数は中央値1日に縮み、AIの回答案の74%が実質的に採用されました。

何が変わるか

この記事の価値は「何割速くなったか」⁠より、設計の割り切りが明文化されている点にあります。回答を作るエージェントと検証するエージェントを意図的に分け、検証側にはコードの読み取り権限だけを与えて、「自分の答えを自分で正しいと言ってしまう」⁠問題を防いでいます。並列実行による二重発火や、完了判定の誤りで処理が止まり続けた障害など、本番でつまずいた点まで書かれているのも貴重です。

筆者自身、「個々のAIコンポーネントはコモディティ化し、差がつくのは組み合わせ方と人間との境界線の引き方」⁠と結論づけています。

Kyash VPoE 小西裕介氏「思考の外注割合を増やし、理解は外注しない」

何が起きたか

Kyashの執行役員VP of Engineering、小西裕介氏（こにふぁー）⁠が9月22日、個人ブログ「Konifar's ZATSU」⁠でこの論考を公開し、はてなブックマークで400件近く集めました。AIについてよく言われる「思考は外注できるが、理解は外注できない」⁠という言い回しに対して、実務者の立場から補強を加えた内容です。

小西氏の主張は、思考と理解はきれいに分けられず、地続きだということです。手でコードを書く、計算を自分で追うといった「自分の頭を通す作業」⁠を省くと、特に慣れない領域では分かったつもりになりやすい。そして、AIにどこまで任せるかの調整は、プレーヤーからマネージャーになるときに誰もが通る「100%自分で考える状態から、80%を任せて20%は自分で理解しておく状態へ」⁠の配分調整と同じ構造で、AIで違うのはその変化の速さだけだ、⁠と述べています。

何が変わるか

「AIを使えますか」⁠という質問は、今やほとんど差がつきません。現役のVPoEがシニアの条件を「委ねた結果を理解した状態で受け取れているか」⁠と言葉にしたことで、評価の軸がはっきりしてきました。タスクの分け方や報告のさせ方を設計できるかは、マネジメント適性の話ともそのまま重なります。

裏返すと、AI前提の環境では「自分の手で通す」機会が構造的に減ります。成果は出ているのに理解が積み上がっていない状態が、数年後の市場価値に響くリスクもあります。

メルペイ、決済基盤を「3年で50ヵ国」対応へ。Apple Pay／Google Payの追加が約1か月に

何が起きたか

メルカリが、グローバルアプリの「3年で50ヵ国以上」⁠という展開目標に向けた決済基盤の刷新を、バックエンドエンジニア3名の登壇レポートとして公開しました（9月25日）⁠。柱は3つです。

1つ目は、決済画面のうち全サービス共通の部分と、配送やクーポンなどサービスごとに変わる部分の切り分け。2つ目は、決済事業者（PSP）ごとの違いをコアの決済サービスから専用サービスへ切り出したこと。これでApple Pay・Google Payの追加にかかる期間が約1か月に縮んだとしています。3つ目は、複式簿記の考え方を取り入れ、残高とその発生理由を1つの取引としてまとめて記録する設計に変えたことです。

何が変わるか

「グローバル決済」⁠という言葉の中身が、「PSP固有の処理をコアから外せているか」「残高と会計を後から突き合わせるのではなく、記録した時点で一致させているか」⁠という具体的な設計課題に分解されて公開されました。特に複式簿記型の設計は、決済に限らず、ポイント・ウォレット・サブスク課金を持つあらゆる事業で応用が利く考え方です。