「GPT-5.2で下書き書かせて、Claude 4.5にレビューさせて、Geminiに画像作らせて…」
最近そんなワークフローをVS Codeの中で無意識に回していて、ふと気づいたんです。
「あれ、オレってもう“どのモデルが最強か”より、“誰に何をやらせるか”で悩んでない？」
同じような感覚、ありませんか？
「とりあえず一番強そうなモデルを選んで投げる」時代は終わりつつあって、
- プロンプト設計よりワークフロー設計
- モデル精度比較よりエージェントの役割分担
- 「o3が凄い」より“5.2＋4.5をどう組むか”
で頭を使わされるようになってきました。
その空気感を、今週の
「GPT‑5.2・Claude 4.5など 2025年末のLLM動向ブックマーク集」
はかなり象徴的に表しているな、と感じています。
この記事では、単なるまとめではなく、ベテラン開発者視点での「これから何が変わるのか」を、意見多めで整理してみます。
一言でいうと：LLM界の「Kubernetes 出てきた瞬間」
このブックマーク集の中身を雑に一言でたとえると、
「LLM界の Kubernetes 1.0 リリース前夜」
です。
- GPT-5.2 や Claude 4.5 Opus 自体のIQももちろん高い
- でも本当に面白いのは
「複数モデル＋ツール＋エージェントで回してナンボ」になりつつあること
かつてインフラ界隈で、
- 「この1台の物理サーバーをどう最適化するか」から
- 「コンテナをどう束ねて、どうオーケストレーションするか」
に発想がひっくり返った瞬間がありましたよね。
いま LLM で起きているのは、ほぼ同じことです。
- 1モデル最適化 → 「もっと強いモデル出るまで待つゲーム」
- マルチモデル＋エージェント → 「設計うまいチームが勝つゲーム」
にルールが変わりつつある。
そしてその象徴的な例が、今回のブックマークに出てくる
GPT‑5.2 + Claude 4.5 Opus 協調で、エルデシュ問題 #333 に反例構成・Lean4形式化
というネタです。
「IQ より Agency」時代に本当に起きていること
Karpathy の「Agency > Intelligence」は、正直キャッチーなスローガンで終わりがちなんですが、今回のブックマーク群を読むと「具体的にこういうことね」と腹に落ちます。
GPT-5.2 x Claude 4.5：もはや「どっちが強いか」論争はズレている
エルデシュ問題#333の話を要約すると：
- GPT‑5.2 が反例のアイデアを構成し
- Claude 4.5 Opus が Lean4 で形式化・検証
みたいな役割分担エージェントで数学タスクを回している、という構図です。
ここでポイントなのは、
もはや「どちらが最強のモデルか」ではなく、
「どのモデルに、どの性格の仕事をやらせるか」が重要になっている
ということ。
- GPT-5.2：
- 探索・試行錯誤・反例候補をガンガン出す「アイデアマン」
- Claude 4.5：
- 論理一貫性・構造化・長文整理に強い「地味だけどミスしない先輩」
という人間のチーム構成に近いロール設計になっている。
正直、これはかなり本質的な変化です。
これ、現場コードにもそのまま持ち込める
たとえばプロダクト開発なら：
- GPT-5.2：仕様たたき台・コードの第一次案を量産
- Claude 4.5：
- 仕様書の構造化・レビュー
- コードの説明・リファクタリング提案
みたいに分けて、
「生成エンジン」と「品質管理エンジン」を分離する
というアーキテクチャが普通にアリになってきます。
ぶっちゃけ、「1モデルで全部やろう」とする方が、
もはやアーキテクチャとして古いと言っていいレベルです。
DeNA「AI活用100本ノック」は、「LLMアプリ設計の教科書」になりつつある
ブックマークに出てくる DeNA の「AI活用100本ノック」。
これを Claude 4.5 にまとめさせてる、というメタ構造も面白いですが、本質はそこではなくて：
「LLMをどこにどう差し込むか」の“決まり手カタログ”になりつつある
という点です。
カテゴリごとに、
- 要約
- 翻訳
- コード補助
- データ分析
- 業務オペレーション
など、「この種のタスクはLLMに投げると旨味がある」というパターンが整理されている。
これが何を意味するかというと、
「どのモデルを使うか」の前に、
「このタスクをLLMに任せるべきか、どう分割するか」が
開発者の新しいコアスキルになっている
ということです。
正直、このスキルがないまま「社内にGPT-5.2導入しました！」と言っても、
高級GPUをファイルサーバーにしてた頃と同じ匂いしかしません 🤔
GitHub Copilot も「マルチモデル前提」に舵を切っている
GitHub Copilot の 2025 年末の姿も、同じ文脈に完全に乗っています。
- 背後で GPT-5.2 / Claude / Gemini を用途別に切り替え
- Raptor mini みたいな GitHub 独自モデルも間に挟む
- Agent Mode や Agent HQ でエージェントを束ねるインターフェースに進化
要するに、
「VS Code の中に、小さなマルチモデル・オーケストレーターが常駐してる」
状態です。
ここでもすでに、
- 「どのモデルを採用するか」という選択より
- 「どの状況でどのモデルを呼ぶかをどう表現するか」
に GitHub 側の開発リソースが振られている。
プレミアムリクエスト枠なんてまさに象徴で、
- GPT-5.2 や Claude 4.5 を「ここぞ」でだけ叩く
- それ以外は mini や独自モデルでローコスト運転
というマルチモデル・コスト最適化が標準機能として組み込まれつつあります。
Google / Gemini との違い：「どこにロックインしても気持ち悪い」問題
ブックマーク集でも軽く触れられていましたが、Google / Gemini との比較は避けて通れません。
OpenAI＋Anthropic 側
- GPT-5.2 / Claude 4.5 のローレベルAPIが圧倒的に扱いやすい
- Developer や OSS コミュニティが
「5.2＋4.5 を前提としたエージェント設計」をどんどん共有し始めている - LangChain などのミドルウェアも、
もはや「モデルラッパー」というよりオーケストレーションフレームワークの色が濃くなっている
Google / Gemini 側
- Docs, Sheets, Gmail, Drive, NotebookLM…
“閉じた業務ワークスペース”の中では最強クラス - でも「GPT-5.2＋Claude 4.5＋社内ツール＋自前LLM」みたいな
マルチベンダー・マルチモデル構成を組もうとすると、
途端に窮屈さを感じる場面が多い
正直なところ、両者ともロックインがエグいです。
- OpenAI / Anthropic にガッツリ寄せたワークフロー：
- LLM/エージェント界の「AWS全乗せ」みたいな安心感はある
- 料金改定・利用制限・政治的リスクで一撃死の可能性もある
- Google Workspace 前提の世界：
- 既存の業務フローとの親和性が高い
- でも「社外の強力モデルとどうブリッジするか」で常にストレス
どちら に寄せるにしても、
「モデルを抽象化するレイヤーをどこに置くか」
をかなり真面目に設計しておかないと、
3年後に盛大なレガシー沼にハマる
という懸念があります。
「Agency > Intelligence」は、開発組織にとっては「設計力 > モデル力」
ここまでの話を、エンジニア組織目線で乱暴に要約すると：
「モデル選定が差別化軸だった時代は終わり、
エージェントアーキテクチャ設計力が勝負になる」
ということです。
必要になるスキルセットはかなり変わる
ブックマーク集にもあった通り、これから現場に求められるのは：
- タスク分解・ワークフロー設計
- どこまでを LLM に任せ、どこを決定論的ツールに任せるか
- どこで人間がレビューに入るか（ヒューマン・イン・ザ・ループの設計）
- マルチモデル設計
- GPT-5.2 / Claude 4.5 / 社内 LLM / 既存API の役割分担
- 「1モデルが落ちたらどうリカバリするか」のフェイルオーバー
- 自己検証とガードレール
- self‑critique, agent debate, majority vote などの自己チェックループ
- コスト／安全性と相談しながらどこまでやるか
ここまで来ると、
“LLMプロンプトエンジニア”単体の職種は溶けていく気がしています。
代わりに、
- 「AIワークフロー・アーキテクト」
- 「エージェントSRE」（挙動監視・テスト・回帰検知）
みたいなロールが、普通の開発組織にも必要になってくるはずです。
ただし：懸念点もエグいです…
ポジティブな話ばかりしても現実逃避なので、
ブックマーク集を読みながら「これはやばいな」と思ったポイントも挙げておきます。
コスト爆死リスク：5.2→4.5→5.2 の3段ループは財布が死ぬ
マルチモデル・エージェント構成の最大の罠は、請求書が盛大に燃えることです。
よくあるパターン：
- GPT‑5.2 で設計と一次コード生成
- Claude 4.5 でレビュー・リファクタ提案
- もう一度 GPT‑5.2 で修正版を作成
これに長コンテキスト＋自己修正ループが乗ると、
- PoC：
「いやーすごいですね！1 回数十円〜数百円だし全然許容範囲！」 - 本番運用：
「チーム全員が毎日回した結果、月のクラウド費用が二桁変わった」
みたいなオチは、普通にあり得ます。
正直、今までの「API 1コールいくら」感覚のまま設計すると、
エージェントの while ループがそのままコスト爆弾になります。
複雑性と「バイブコーディング崩壊」問題
Cursor の CEO が警鐘を鳴らしていたように、
「コードを一切読まずに AI に任せるスタイル」は
規模が大きくなると確実に崩壊する
という懸念があります。
マルチエージェント構成だとそれがさらに加速して、
- どのエージェントが
- どのファイルに
- どの理由で変更を加えたのか
が人間から見て完全にブラックボックスになりやすい。
ここを放置したまま、
- Copilot coding agent
- Claude Code の Explore Agents
- 自前の GPT-5.2 エージェント
を全部突っ込んだら、
正直「誰も理解してない大規模モノリス」より始末が悪いです。
流儀としては「エージェントに任せる範囲は、
必ずテストでカバーできる粒度に切り出す」ことが前提
…くらいにしないと厳しい、というのが個人的な感触です。
研究成果・高難度タスクの「すごい話」問題
エルデシュ問題#333のような、
「LLMが未解決問題を解きました！」
系のニュースは、インパクトが大きい一方で、
- Lean4 などで形式検証が本当に終わっているのか
- 人間研究者の独立な追試が進んでいるのか
を見ないと、正直なんとも言えません。
同じ構図は、プロダクトでも起きます。
- LLM が生成したアーキテクチャ
- LLM が設計したデータモデル
- LLM が作ったセキュリティ設定
これらをどこまで人間と決定論的ツールでダブルチェックするかを決めないと、
「AIが書いたから大丈夫っしょ」という
新しい種類の技術的負債を積み上げることになります。
じゃあ、プロダクションで GPT-5.2 / Claude 4.5 のマルチエージェントをガチ導入するか？
ここまで見てきた上で、個人的な結論はこうです。
「ミッションクリティカルには、正直まだ様子見。
ただし“サンドボックスで本気で遊ぶ”のは今すぐ始めるべき。」
なぜガチ本番はまだ様子見か
- コストと複雑性のコントロールが、
まだ「ベストプラクティスが固まりきっていない」 - ベンダーロックイン前提で、
ビジネスモデルまで賭けに出るのはリスクが高い - 観測性（ログ・トレース・回帰テスト）のツールチェーンが
まだ整理されていない
正直、「Kubernetes リリース1年目にいきなり金融勘定系を全部載せるか？」
と聞かれたときと、感覚はかなり近いです。
でも本気で触り始めないと、2年後には置いていかれる
一方で、
- DeNA の「AI活用100本ノック」
- GitHub Copilot のエージェント機能
- Claude Code の Explore Agents
…こういう「LLMを組み込むための型」が、
2025 年末の段階でかなり実戦レベルになってきています。
2026〜27 年にかけては、
「LLMを使っていないシステム」が遅れているのではなく、
「エージェントとして設計されていないシステム」が遅れている
という評価軸に変わるはずです。
なので個人的におすすめしたい戦略は：
- 本番手前の“運用フェーズの考え方”で小さく回す
- プロジェクトの一部だけ GPT‑5.2 / Claude 4.5 エージェントに任せる
- ただし必ずテストとレビューを人間が握る
- ワークフローとログをとにかく残す
- どのプロンプト・どのモデル・どの手順がうまくいったかを記録
- 社内版「AI活用◯本ノック」を育てる
- モデル抽象レイヤーを最初から意識する
- 「5.2 前提のワークフロー」「4.5 前提のワークフロー」を
できるだけ薄くしておく - 将来 Gemini や自前 LLM に差し替えられるようにしておく
まとめ：今週のブックマーク集を「未来の設計図」として読む
今回の「GPT‑5.2・Claude 4.5など 2025年末のLLM動向ブックマーク集」は、
- モデル性能のランキング表ではなく
- 「次世代アーキテクチャの断片集」
として読むと、ものすごく示唆が多いです。
- GPT‑5.2 ＋ Claude 4.5 の役割分担エージェントが
数学やコードで実用ラインに入りつつある - Karpathy が言う「Agency > Intelligence」は、
具体的には 「設計力 > モデル力」 という意味だと見えてきた - DeNA や GitHub Copilot は、
LLM 組み込みのパターンカタログを先に作りにいっている
正直、
「最強モデルが出たら全部置き換えよう」
という発想のまま数年過ごすと、
“単一LLM 直叩きプロダクト”は一気にレガシー化すると思っています。
だからこそ今は、
- 「どのモデルが一番か」ではなく
- 「どんなタスク分解とエージェント設計なら、モデルを入れ替えても生き残れるか」
を考え始めるタイミングです。
このブックマーク集は、そのための未来の設計図のラフスケッチとして、
手元に置いておく価値がある、と個人的には感じています 🚀
コメント