RSS Amplifier

Bay Area Newsletter / シリコンバレー・ニュース · Jul 30, 2026

Weekly Newsletter #275 Opus 5、GPT-Live、Kimi K3 — コーディングは終わるのか

0
Sign in to vote or save

Yuto Tanabe · Bay Area Newsletter / シリコンバレー・ニュース

先日、カリフォルニア州の運転免許を取ってきました。試験は試験官が助手席に座り、指示されたとおりに運転するというもので、合格率は思ったより低いそうです。無事に一度で通ったので、正直かなり嬉しかったです。ハンドルを握りながら、自分の判断が横から常に見られている状態というのは、なかなか独特の緊張感がありました。(下の写真はWaymoに乗った時に撮影、運転も終わるのでしょうか)

Photography by Yuto

今回のテーマは、私自身の足元が揺れている話です。vibe codingという言葉が普通に通じるようになり、私が学生時代に学んだプログラミングという作業は、ずいぶん形を変えつつあるように見えます。フロンティアモデルの発表が続いたこの2週間の動きを追いながら、コーディングという仕事がこれからどこへ向かうのかを考えてみました。
先週のニュースレターを見逃した方はこちら

Weekly Newsletter #274
Weekly Newsletter #273【モビリティ×巨大インフラ】発電所を自給するデータセンターと、Waymoの都市適応戦争
Photography by UnsplashIlya Pavlovが撮影した写真のIlya Pavlovが撮影したイラスト素材
🌏【今週のトピック:3行まとめ】
  1. 7月24日にAnthropicがClaude Opus 5を公開し、その前日にはOpenAIが音声モデルGPT-Liveをコーディング環境に接続した。7月16日にはMoonshot AIがKimi K3を発表している

  2. 実際に使ってみると、そろそろ人間がコードを書く時代は終わるのかもしれないと思えてくる。ただし、下の層の作業の多くが別の層へ移るという現象は、FORTRANの時代から見られたらしい

  3. 今回が過去と違うかどうかは、まだ判定できない。鍵は、形式化と検証の役割がどこへ配分されるかだと考えている

7月24日、AnthropicがClaude Opus 5を公開しました。同社の説明では、Claude Fable 5のフロンティア知能に半額で近づくモデルだそうです。6月にはFable 5、Sonnet 5が出ています。このうちFable 5はMythos 5と同じ基盤モデルでセーフガードの設定が異なるもの、とAnthropicは説明しています。

その前日の7月23日には、OpenAIが音声モデルGPT-LiveをmacOSとWindowsのChatGPTデスクトップアプリに統合し、Codexと接続しました。GPT-Live自体は7月8日に出たもので、こちらの発話と相手の発話が重なっても処理できる全二重方式のモデルです。音声でコーディングジョブを指示し、プルリクエストをレビューし、デバッグまでできるようになっています。

そして7月16日には、Moonshot AIが2.8兆パラメータのKimi K3を発表しました。

実際に触ってみると、これがなかなかよくできていて、特にGPT-Liveは、こちらが言い終わる前に相槌が返ってくるので、本当に人と話しているのとあまり変わりません。画面を見ないまま、歩きながら実装の方針を相談するといったことが、普通にできてしまう。

そこで一つ、疑問が浮かびました。

コーディングを人間がやる時代は、もう終わったのだろうか。

Googleが公表している新規コードのうちAIが生成した割合は、2024年10月の決算発表で25%超、2025年秋の時点で約50%、そして2026年4月には75%とされています。

ただ、この数字は慎重に扱う必要があります。内訳が公表されていないんです。行数なのか、コミットなのか、マージされた変更なのか。全コードベースではなく新規コードに限った数字でもあります。三つの時点で同じ測り方をしているのかどうかも、公開情報からは分かりません。

言えるのは、少なくともGoogle社内では、AI生成コードの利用が急速に増えているということまでです。これが業界全体の姿なのかどうかは、この数字だけでは分かりません。

それでも、そろそろ人がコーディングをする時代の終わりが近いのだろうかと考えたくなります。ただ、念のため過去にも似た話がなかったか調べてみたところ、これがなかなか面白いことになっていました。

1957年、IBMがFORTRANを出荷しています。Backusらが同年に発表した論文の題は「The FORTRAN Automatic Coding System」で自動コーディングシステム、という名前です。

IBM自身の説明によれば、FORTRANは科学者や数学者や技術者が、自分の問題を機械語に翻訳してくれるプログラマに頼らず、直接コンピュータへ入力できるようにするものでした。1000行近い命令を手で打っていた作業が、47行になったとのことです。Backusらの論文にも、コーディングとデバッグの作業量を5分の1以下に減らせると期待していた、と書かれています。

ここは正確に読んでおきたいところです。FORTRANは「プログラマがいなくなる」とは言っていません。 目指していたのは、専門のプログラマへの依存を減らすことと、作業量そのものを減らすことでした。

COBOLも近い発想でした。こちらはIBM単独ではなく、1959年に米国防総省の呼びかけで発足したCODASYLという委員会が策定したもので、初版が出たのは1960年です。英語に近い構文で、可読性と保守しやすさを重視した言語だと説明されています。

それから70年近く経ちますが、プログラマという職業はなくなっていません。

ただ、下の層の作業は移った先があります。 一般的なアプリケーション開発では、アセンブラを手で書くことも、機械語のアドレスを人間が管理することも、その多くがコンパイラやランタイムの側に抽象化されています。低レイヤーの領域では今も必要とされている作業です。

つまり過去に起きたのは、職業の消滅ではなく、作業の移動でした。

当時、FORTRANが手書きのコードほど効率的なコードを生成できるのか疑う声もあったらしいのですが、その懸念は、実際に効率的なコードが出てきたことで薄れていったようです。今のAI生成コードをめぐる議論と、同じ形をしている気がしますね。

この繰り返しには、よく知られた説明があります。

1986年、フレデリック・ブルックスは「銀の弾丸はない」という論文で、ソフトウェア開発の作業を二つに分けました。本質的な作業、つまり抽象的なソフトウェアを構成する概念構造を組み立てること。そして偶有的な作業、つまりその概念構造をプログラミング言語で表現し、機械語へ写しとること。過去の生産性向上の大半は、後者にあった人為的な障壁を取り除くことで得られたものだ、というのが彼の主張でした。

高水準言語について、ブルックスはこう書いています。それはプログラムを偶有的複雑さの多くから解放する、と。ただし設計そのものの複雑さは本質的なものであり、そこには何の変化ももたらさない。

FORTRANもCOBOLも、概念構造を書き表すための言語を変えただけで、その概念構造を組み立てる仕事は人間に残しました。 技術的な作業分担の変化としては、これで説明がつきます。

ただし、職業が残った理由がこれで説明しきれるわけではありません。ソフトウェアの需要そのものが伸びたことや、適用される領域が広がったことも効いているはずで、そちらの寄与は別の問題です。

ちなみにブルックスの論文は、当時「これこそが決定打だ」と言われていた技術を順に取り上げて、どれも偶有的な部分にしか効かないと論じるものでした。人工知能とエキスパートシステムも、その候補の一つとして名前が挙がっています。エキスパートシステムというのは、その分野の専門家が持っている知識を「もしこうならこうする」という規則の集まりとして書き下し、機械に推論させる仕組みのことです。1980年代に大きな期待を集めました。40年前の話になります。

過去と違う点があるとすれば、形式化がどこで起きるかだと思います。

コンパイラは、開発者が形式化したソースを機械語へ変換する道具でした。何を作るかを決め、それを曖昧さの残らない形に落とす作業は、人間の側にあった。今のモデルは、自然言語で書かれた不完全な指示を受け取り、足りない部分を推測してコードを生成します。

形式化の一部が、機械の側に移りつつあるわけです。ブルックスの言う本質的な側に手が入っているのかどうかは、ここにかかっているのだと思います。

とはいえ、推測で埋められた部分が意図と合っているかどうかを確かめているのは、まだ人間の側です。その確認こそが本質的複雑性の中身だとすれば、削れたのは相変わらず偶有的な部分ということになります。

だから見るべきなのは生成の側ではなく、検証の側だろうと思っています。

Sonarが2026年に公表した調査があります。実査は2025年10月で、1000人を超える開発者が対象です。該当設問に答えた979人の回答では、コミットまたは提供したコードに占めるAI生成、またはAIによる大幅な支援を受けたコードの割合は、平均で42%でした。実測値ではなく自己申告である点は、押さえておく必要があります。

その一方で、96%はAI生成コードを完全には信頼していないと答えています。38%は、AIコードのレビューは人間の同僚のコードより手間がかかるとしています。

そして、コミット前に必ず検証すると答えたのは48%でした。

残る52%がどうしているのかは、この数字だけでは分かりません。「必ずではない」の中には、たいてい検証する人も、ときどきの人も含まれているはずです。検証の負荷が上がっていることと、必ず検証する人が半分にとどまることの間に関係があるのかどうかも、こうした横断調査からは確認できません。

ただ、二つの数字を並べてみると、気になる形をしているのは確かです。

そしてもう一つの流れがあります。GPT-Liveのアップデートでは、プルリクエストのレビュー自体が音声で指示できる機能として案内されていました。生成にAIを使い、その検証にもAIを使うという構成が、標準的な選択肢に入ってきたわけです。

ネットワークをやってきた人間としては、ここに引っかかるものがあります。監視系が被監視系から独立していないと、検証の信頼性は落ちる。同じ系列のモデルが書いて同じ系列のモデルが確認する場合、独立性が弱まり、誤りが相関する懸念があります。

もっとも、独立性の確保はモデルの系列だけで決まる話でもありません。別系列であっても学習データや推論の傾向は重なり得ますし、逆に同じモデルを使っていても、テストや静的解析、形式検証、人間のレビューを組み合わせれば、生成とは別の経路から確認できます。

だから問いはこうなります。 概念構造を組み立て、それが意図と合っているかを確かめる役割は、これからどこへ配分されるのか。モデルなのか、人間なのか、あるいは要件定義や設計、テスト、静的解析、運用監視といった仕組みの側に分散していくのか。

過去に起きたのは作業の移動でした。今回もそうなるのか、それとも移動先が用意されないまま手放されるのかは、まだ分かりません。

判定はできませんが、指標なら書けます。

Googleの次の数字:75%の次がどうなるか。頭打ちになるなら、そこで止まった理由を調べる手がかりになります。どんな作業がAI生成に向かないのか。あるいは社内規則や対象言語、リスクやコストの問題かもしれませんし、測り方の問題かもしれません。

検証を必ず行う人の割合: 今回のSonarの調査は新しく始まったシリーズなので、48%に比較できる過去の値はありません。同じ設問で継続して調べられるようになれば、その推移が重要な指標になります。

生成系から独立した検証手段が組み込まれるかどうか: 別系列のモデルを使うのはその一例にすぎません。テストや静的解析、形式検証も含めて、生成とは別の経路で確かめる仕組みが標準になるかどうか。

障害の原因分析: AI生成コードについて、所有者やレビュー責任の不明確さが原因あるいは寄与要因として挙げられた障害の割合。ポストモーテム(障害後に書かれる振り返り文書)に書かれる言葉が変わるかどうか、ということです。ここが一番わかりやすい答えになるだろうと思っています。

私は日常的にコードを書く立場ではありません。ですからコーディングが減ったという実感はあまりないです。

ただ、別の変化ははっきり感じています。以前なら誰かに頼むか、諦めていた程度の小さな道具を、自分で作って動かすようになりました。書けるようになったというより、書かなくても作れるようになったという方が近い気がします。

そのとき私がやっているのは、出てきたものが正しいかどうかを判断することです。そして正直なところ、判断できていない部分もあります。動いているから良し、としている箇所が確実にある。

FORTRANが出た年にも、コンパイラが生成したコードは人が手で書いたアセンブリほど効率的なのか、と議論していた人たちがいたようです。彼らの懸念は、効率という意味では杞憂に終わりました。今回の懸念が同じように解消されるのか、それとも別の形で残るのかは、まだわかりません。

コーディングが終わるとすれば、それはある日突然終わるのではなく、気がついたら手元に残っていない、という形になるのだろうと思います。アセンブリを手で書かなくなったときも、たぶんそうだったように。

ソースURL:
Introducing Claude Opus 5(Anthropic): https://www.anthropic.com/news/claude-opus-5
Claude Fable 5 and Mythos 5(Anthropic): https://www.anthropic.com/news/claude-fable-5-mythos-5
Introducing Claude Sonnet 5(Anthropic): https://www.anthropic.com/news/claude-sonnet-5
Anthropic’s Claude Opus 5 AI model rivals Fable 5(CNBC): https://www.cnbc.com/2026/07/24/anthropic-claude-opus-5-ai-fable-5-cost.html
GPT-Live comes to Codex(VentureBeat): https://venturebeat.com/orchestration/agentic-coding-goes-hands-free-as-openai-brings-gpt-lives-full-duplex-voice-control-to-codex-and-chatgpt-on-the-desktop
Moonshot releases 2.8T Kimi K3(Tom’s Hardware): https://www.tomshardware.com/tech-industry/artificial-intelligence/moonshot-releases-2-8-trillion-parameter-kimi-k3
Alphabet Q3 2024 earnings, message from the CEO(Google): https://blog.google/company-news/inside-google/message-ceo/alphabet-earnings-q3-2024/
Sundar Pichai shares news from Google Cloud Next 2026(Google): https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/cloud-next-2026-sundar-pichai/
State of Code Developer Survey Report 2026(Sonar): https://www.sonarsource.com/state-of-code-developer-survey-report.pdf
The AI Coding Trust Gap(Sonar): https://www.sonarsource.com/blog/ai-coding-trust-gap/
Fortran(IBM History): https://www.ibm.com/history/fortran
The FORTRAN Automatic Coding System, 1957(Backus et al., Computer History Museum): https://archive.computerhistory.org/resources/text/Fortran/102663113.05.01.acc.pdf
1957 Timeline of Computer History(Computer History Museum): https://www.computerhistory.org/timeline/1957/
What Is COBOL?(IBM): https://www.ibm.com/think/topics/cobol
No Silver Bullet — Essence and Accidents of Software Engineering, TR86-020(Frederick P. Brooks Jr., UNC): https://www.cs.unc.edu/techreports/86-020.pdf

最後までお読みいただきありがとうございます!
励みになりますので、ぜひLikeボタン (♡) をお願いします!

Read the original on net1us.substack.com

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.