GPT-5とClaude Sonnet 4でコーディング比較。ChatGPTはツールとして使い物にならない

GPT-5が出ましたね。コーディング能力もめっちゃあがってる！みたいなことが書いてあるので、いろいろ試してみました。
開発者向け GPT-5 のご紹介 | OpenAI

結論を書いておくと、GPT-5のコーディング能力は確かにあがってSonnet 4と同等くらいになってるけど、ChatGPTというサービスがコーディングツールとして使い物にならなくなっていました。
チャットUIでコード書くならClaude。

マリオ

なんかマリオができるという話だったので、やってみました。

javaのswingでリアルなマリオのようなゲームを作って。
1ソースで完結して。
背景もかわいいほうがいい。

だいぶいいですね。背景かわいいし、スコア表示もゲームっぽい。

GPT-4oではこうだったので、かわいさが増してます。敵もコインもなくジャンプするだけのゲームだったし。

ちなみにSonnet 4。敵を踏んで潰すのもできてます。GPT-5版では自分が死ぬ。かわいさではちょっと負けてます。

ということで、GPT-5ではコーディング能力だけじゃなくかわいさも理解するようになったのか？と期待が高まったのでした。

ドラゴンゲーム

さて「ワイヤフレームのドラゴンと勇者が戦うゲームを作ってほしい」とやったらこれ。ドラゴンも勇者もない。

Claude Sonnet 4ではこうでした。ドラゴンかっこいい、勇者が剣を振るのかわいい。

プロンプトはこう

Javaのswingで、ワイヤフレームのドラゴンと勇者が戦うゲームを作ってほしい。
操作は２dで、表示は3dで。

ハルシネーションが減った代わりに創造性もなくなったという話がありますが、こういうところにも影響してるんだろうか。指示がない限りは最低限の表現にしてそう。
他のゲームでも、ちょっとそっけない感じがありました。
なんか、マリオだけちゃんとやってる感。

砂時計

「それっぽく砂が動く砂時計をjavaのswingで作って」として砂時計を作ってもらいました。

そうすると、容器からはみだして変な感じに。

これはガチのシミュレーションをやろうとして制御できてない感じで、これは仕方ない。
コーディング能力は高そう。

OpenRouterにあったHorizon betaで試したときと同じなので、このことからもHorizon betaがGPT-5のステルスモデルだったことがわかります。

手作業でコードを修正して、はみ出した判定を処理の最後にやると、容器からはみ出ることはなくなりました。

どうやら離散要素法という手法らしいので、「離散要素法を使って砂時計のシミュレーションをjavaのswingで作って」とやってみたら、一発でこんな感じに。クビレを抵抗なく通り過ぎな気がする。

Sonnetでも同じ感じになりました。

Sonnet 4で「それっぽく砂が動く砂時計をjavaのswingで作って」としたときはこれでした。

一番砂時計っぽい動きをするけど、かなり簡易な処理ですね。
なので、これは引き分けか、最初からガチシミュレーションしようとしてたGPT-5の勝ちか。

パストレーシング

光の動きをシミュレーションするCGの手法、パストレーシングもできるんでは、と試してみました。

パストレースでガラス玉となにかポリゴンを描画するJavaプログラムを作って

天地が逆だったのを調整してもらったけど、最初からオブジェクトが全部画角に入っててえらい。

ハイライトがないし、レンズの効果もないし、なんか光源の設定か処理がおかしいかな？

Sonnet 4に作ってもらったらこう。パストレースといえばこれ、というコーネルボックスになってるし。
金属マテリアルも追加してもらった。

処理過程も表示してくれてかっこいい。これはサンプリングを減らしてるけど、このザラツキがパストレーシング。

これはSonnet 4の勝ちかなぁ。

このブログのタイトルのところにも、Javaで書いたパストレーサーで出したCG使ってますが、あたたかみのある手作業で結構時間をかけて書いてます。それが、AIさんに指示あたえるだけで書けてしまうなんて、という驚き。

キャビティ流れ

さて、パストレーシングができるなら、流体計算もできるのかなとやってみました。定番のキャビティ流れ。GPT-4oではできなかったんですよねぇ。
川の底に四角いくぼみ(=cavity)があるときに、そのくぼみの中でどんな流れになるかというシミュレーションです。

手法を明示すると出してくれやすいようなので、プロンプトに有限要素法を指定。

JavaのSwingでキャビティ流れのシミュレーションを有限要素法を使って実装して。

GPT-5ではこんな感じ。時間発展じゃなく定常状態になったところを出してるみたい。けど、なんかちょっと違うかな。
動いてるように見えるかもしれませんが、PNG画像の静止画です。

時間発展するバージョンを出してもらおうと思ったけど、爆発。

爆発対策をしてもらおうと思ったら、最後に書いた、コード出す出す詐欺にあってしまった。

そして、Sonnet 4。ちゃんと出してくれた。

Sonnet 3.7のときはこう。ちゃんと動いてそう。4になって表現とかが進化してるかな。

ところでSonnet 4にHTML+JSを出してもらった。
これまで見ないふりをしてましたが、Java+Swingで出すよりHTML+JSで出すほうが圧倒的にいいUIを作って、動きもちゃんとしてがち。。。

ちなみにGPT-oss 20B。それっぽいけどなんか違う。16GBで動くモデルでここまでできるのもすごい。

ChatGPTはコーディングツールとして使い物にならない

ということでまとめ。コーディング能力は確かにかなりあがってる。今までできなかった実装ができるようになってる。
でも、ChatGPTというサービスではコーディングできなくなっていました。

Timerの参照のエラーはGPT-5でも健在。というか、指示しなかったら必ずこれでコケる。まあ、これはプロンプトで指定すれば問題ない。

コードの修正したときに、コメントが全部消えがち。あと、バグ修正したときに関係ないところも変わってるというのもよくあった。メソッド内に3つあった処理が1つになって消えてる、とか。信用できない。

完全なコードを出してと言ってるのに省略することも多すぎ。Canvasモードで省略してしまうので、中途半端なコードが残ってしまうことも。このあたりはモデルの問題だけではなく、ツール含めたUIの問題でもありそう。

コードの問題点を指摘しても、単に問題点と解決策だけを提示して解決コードを出さないこともある。

また、更新しましたといいつつ更新されてないことも多い。

そのままコード出さずにFreeプランの制限に達したりする。

これ、もう無駄に対話を増やしてリミットを早くさせようとしてるとしか思えない。

ということで、GPT-5のモデル性能の問題とは別に、ChatGPTというサービスがコーディングのツールとして使い物にならなくなっています。

挙動には関係ないけど、コンパイルエラーのことを「Javaが怒っています」と言ってますね。こういうスラングが取り込まれてるのはちょっとおもしろい。

お気に入りの表現なんだろうか。

※ コンテキストウィンドウが無料だと8Kになったからという話があります。

でもこれは4oのときから変わってなさそう。

仕組みから学ぶ生成AI入門――基礎から応用まで徹底理解

「JavaでAIプログラミングをはじめよう」という短期連載をgihyo.jpで出しました

技評さんのサイトで「JavaでAIプログラミングをはじめよう」という短期連載をやってました。
LLMを動かして接続してRAGやMCPも組んでひととおりやってみるという連載になってます。
JavaでAIプログラミングをはじめよう 記事一覧 | gihyo.jp

● 初回は、LM Studioを使ってQwen3 1.7Bをローカルで動かしてHttpClientで呼び出すという、準備的な回。
今ならGPT-oss 20Bでもいいかもしれないけど、Qwen3 1.7Bのほうがどんな環境でも動くんじゃないかと思います。
JavaでLLMにアクセスしてみよう | gihyo.jp

● 第2回は、定番ライブラリのLangChain4jを使うという回。
LangChain4jを使ってみよう | gihyo.jp

● 第3回はFunction CallingとRAGです。
ちなみに、技評さんのサイトでダウンロードできるサンプルコードには、このブログの10回分くらいのmdファイル入ってて、そのまま動かせば「きしだのはてなAI」が起動します。
Function Calling (Tool use)とRAGで外部情報を利用する | gihyo.jp

● 第4回はMCP。Spring Bootを使ったサーバーを作ってLM Studioからの呼び出し、LangChain4jで作るクライアントからの呼び出しをしています。
ほんとは全3回の予定だったけど、LM StudioがMCP対応したので、ついでにやってみました。作るとMCPの理解が深まるのでよい。
第2回のときLangChain4jのバージョンは1.1.0を使ってましたが、第3回の直前くらいに1.2.0が出てたので、ここでは1.2.0を使ってます。
https://gihyo.jp/article/2025/07/start-java-ai-programming-04

そして連載終わったら1.3.0が出ていました。早い。
Release 1.3.0 and 1.3.0-beta9 · langchain4j/langchain4j · GitHub

LangGraph4jでエージェントを、とか書いてたけど、LangChain4j 1.3.0にエージェント機能が入っていて、これ結構よさそう。
https://docs.langchain4j.dev/tutorials/agents/

AIエージェント開発 / 運用入門 [生成AI深掘りガイド]

OpenAIのオープンモデルGPT-oss 20Bがすごすぎる

OpenAIのオープンモデルが来ました。
120Bと20B。どちらもMoEで、アクティブパラメータはそれぞれ5.1B、3.6Bです。
そして4bit浮動小数点での量子化があるので、120Bは80GBのVRAM、20Bは16GBのVRAMで動きます。
Introducing gpt-oss | OpenAI

LM Studioで動かす。早い！速い！

LM Studioに即来ていました。早い！

最新版にしてllama.cppも更新が必要です。

追記: 0.3.22-b1で正式にgpt-ossに対応したようです。記事を書いた時点での0.3.21-b4では対応が不完全だったらしい。

起動時にgpt-oss-20bのダウンロードを勧めてきますね。

ということで、RTX4060 Ti 16GBで動かしました。71token/sec！速い！

17000トークンまでならVRAMに載りそう。

送信時にReasoningの深さを指定できるようになっています。

Qwen3 30Bを2bit量子化で動かせば80token/sec出てたのだけど、賢さはかなり犠牲にしていました。しかしGPT-ossは賢い！
もう、これを使わない理由はないですね。

口調がChatGPTだ！

「なぜ逆になっているのか」みたいな表題を書いてしまう。

『「頂点→底辺へ広がる」構造』みたいに鍵カッコでくくったり、文の途中に箇条書きが入ったり。

ちゃんと動いたことを報告すると「Happy coding!」って出してくれるのもChatGPTっぽい。

完全に、OpenAIモデルですね。

山口県について聞く

山口県についても聞いてみましょう。
LLMの日本知識を測るのに山口県について聞くのがよかった - きしだのHatena

なんかいっぱい書くけど、市名人名以外の固有名詞だいたい間違ってますね。
ただ、要所は押さえている感じなので、グローバルモデルとしては結構いいと思います。

一応難しい計算させておく

すぐ答えた。

コードを書かせる

ということでコードを書かせます。
「JavaのSwingでブロック崩しをつくって。ブロックを硝子のように表現できる？」とやってみます。
最初はコンパイルエラーが出てましたが、エラーを伝えると一発で修正。

凝った描画させるとAPIがややこしいのでコンパイルエラーは仕方ない。エラーを一発修正が偉いと思います。
その後もリスタート機能を実装したりと修正を加えたけど安定していました。

そして砂時計。
「砂の動きをそれっぽく表現した砂時計をJavaのSwingで作って」

最初は時計の三角が逆向きで、菱形になってたけど、ちゃんと砂時計のようになりました。

かなり修正してもらっていたのだけど、コンパイルエラーは一度もなかった。えらい。
一度、描画まわりで実行時例外が出ていたけど、例外メッセージ貼り付けると修正してくれました。

かなりコーディング能力も高そうです。

ただ、設定したコンテキスト長に達すると、コンテキストあふれに対応してないといわれた。LM Studioの制約かな。

エージェントを動かす

雑なコーディングエージェントを動かしてみました。thinkingで時間くってる割に、結構すぐ終わりました。

GPT-oss 20B、17000トークンくらいだと、ちゃんとVRAM16GBに載った。
そして、thinkingにコードを全部書くという無駄をやりつつ、この速さでSpring Boot TODO管理を書き終えた。すごい。
システムプロンプトに書いたことをちゃんと言うこときいてくれるのもすごい。 pic.twitter.com/hllwVrEqyj

— きしだൠ(K1S) (@kis) 2025年8月5日

というかthinkingで一旦コードを全部書き出したりしていて無駄。
「Reasoning: low」って書いておけばthinkingを減らしてくれそうなことがモデルカードに書いてあったけど、あまり効きませんでした。

https://cdn.openai.com/pdf/419b6906-9da6-406c-a19d-1bb078ac7637/oai_gpt-oss_model_card.pdf

ところで、thinkingを表すタグが<|channel|>analysis<|message|>で始まるなど特殊で、Roo Codeが対応できてませんでした。

☝の雑エージェントも、そのあたりでちょっとタグの扱いをシステムプロンプトに指示をする必要があったのだけど、すごく素直に書いたとおりに従ってくれて、安心感がありました。
指示追従性めちゃ高い。

追記：LM Studioの更新で<|channel|>などのタグに対応してくれてたりReasoningの深さが設定できるようになっていました。そのおかげで、雑コーディングエージェントも爆速で40秒でSpring BootのTODOアプリを作ってくれました。Roo Codeはやはりうまく動いてくれていないけど。

なんか、LM StudioがちゃんとGPT-ossのフォーマットに対応したおかげか、 Reasoning: low が効くようになって最低限のthinkingになったので、 雑コーディングエージェントでRTX 4060 Ti 16GBでSpring Boot TODOアプリを40秒で生成するようになった。
リアルタイム。早送りなし。 pic.twitter.com/WGLlMYCLW0

— きしだൠ(K1S) (@kis) 2025年8月6日

まとめ

速いし賢いし指示に従ってくれるし、すごすぎる。
120Bは試せてないけど、20Bでこれなら120Bどうなってるの・・・という感じします。
ただ、ClineやRoo Codeでのツール呼び出しがうまくいかないようで、<|chennel|>タグとXMLが相性わるそうです。雑エージェントでも結構対策が必要でした。

ともあれ、Qwen3が出たときは「普通のPCで動くローカルLLMにちゃんとした用途ができそう」という感想だったのが、GPT-ossは「普通のPCで動くローカルLLMでちゃんと使えそう」という感じです。
Qwen3はローカルLLMの世界を変えたかも - きしだのHatena

原論文から解き明かす生成AI

仕組みから学ぶ生成AI入門――基礎から応用まで徹底理解

Qwen3-235BやQwen3-30B、Qwen3 Coder Flashは長コンテキストでの性能劣化が激しいのでは

Qwen3のアップデートがいろいろ出ていて、ベンチマークですごい結果を出したりしています。
けど、実際に使うと全然そんな性能が出てる気しないです。

これたぶん、コンテキストが長くなったときの性能劣化が激しいんじゃないかと思います。
なので、ベンチマークや、ちょっとプロンプト一発投げて返答を見ると性能よさそうに見えるんだけど、実際に使うとダメということになるんだと思います。

Qwen3 30Bアップデートとコーディングモデル

Qwen3のアップデートは、先日の235Bに続いて、30B-A3Bのnon-thinkingモデルと、それをベースにしたコーディングモデルが出ていました。
Qwen/Qwen3-30B-A3B-Instruct-2507 · Hugging Face
Qwen/Qwen3-Coder-30B-A3B-Instruct · Hugging Face

235Bについては、なんか残念ということを書きました。
Qwen3 235Bのコーディング力は相変わらず低い。Qwen3 Coderは期待できる。 - きしだのHatena

235Bはオープンウェイトモデルでは最高みたいなベンチマークが出てますが、実際に使うとかなりダメでした。

で、また30Bベースのベンチマークもすごくいいんですね。これは眉唾だ～と試してみました。

235Bは http://chat.qwen.ai で試しましたが、今回は手元のマシンでLM StudioでQ4_K_M量子化で試しています。

30Bでブロック崩し作らせたらグダグダ

いつもどおり「ブロック崩しをJavaのSwingで作って」とお願いします。追加指示への対応力を見たいので、ここでは雑なプロンプトで。

まず感じたのが、Qwen3 235Bのときも思ったのだけど、聞いてないことを付け加えがちです。
これはnon-codingのほうだけど、フォントをSans Serifにしてもらったとき、Fontクラスに関するいらん話を付け加えてきました。

こういった感じで、聞いてもない いらんことを付け加えるのは、LLMが回答に自信を持ってないことを表します。返答は聞いたことに対して簡潔にシュッと出して欲しい。

non-codingでは、「変更しました」といって何も変わってないことがありました。 あと、なぜかブロックのサイズが変わってしまったり。いらんこと変更するのもよくない兆候。

coder 30Bでは、修正中にKeyListenerが外れて、次のような部分で本来KeyListenerが持っているkeyPressedやkeyReleasedがオーバーライドにならずエラーになるということがありました。

class Panel implements ActionListener, MouseListener {
  ...
  @Override
  void keyPressed(KeyEvent evt) {
  }
  @Override
  void keyReleased(KeyEvent evt) {
  }
  ...
}

ここで、@Overrideを消すという短絡的な解決に走ろうとします。

目の前のコンパイルエラーがなくなればいいというの、3ヵ月目入門者レベル。ジュニアにも達していない。
しかも、消すといいつつ消えてないので、同じコンパイルエラーが延々と出続けることになりました。

14Bでブロック崩し作らせると安定感あった

Qwen3 14Bでも似たエラーが出ました。

けどちゃんとMouseListenerをつけるという方向で対策。

いろいろ調整して、それっぽいブロック崩しになりました。

アクティブ3Bは考えが浅い？

MoEのアクティブパラメータ数って、思考の深さに関係すると思うのですけど、3Bはちょっとコーディングには足りないのかなぁと思いました。
それで、勉強したての素人のような、コンパイルエラー消えればええやろ的な解決をしてしまうのかと。

あと、コンテキストが長くなると、30Bだと6000トークン、235Bだと15000トークンを超えるあたりから怪しくなった気がします。
235Bの15000トークンは余裕がある気がするけど、thinkingでだらだらといらんことトークン使いまくったりするので、割とすぐでした。
いずれにしろ、システムトークン1万あるClineだとつらい気がします。

現場で活用するためのAIエージェント実践入門 (KS情報科学専門書)

Qwen3 235Bのコーディング力は相変わらず低い。Qwen3 Coderは期待できる。

アリババのQwen3 235Bがアップデートされて、reasoningとnon-reasoningが分離しました。また、Qwen3 Coderという480Bのコーディング用モデルも出ていたので、砂時計を実装させて試してみました。

Qwen3-235B-A22B-Thinking-2507はコーディングに期待できない

Qwen3 235Bのアップデートは、先にnon-reasoningなモデルが出ていましたが、reasoningモデルも出てきました。

🚀 We’re excited to introduce Qwen3-235B-A22B-Thinking-2507 — our most advanced reasoning model yet!

Over the past 3 months, we’ve significantly scaled and enhanced the thinking capability of Qwen3, achieving:
✅ Improved performance in logical reasoning, math, science & coding… pic.twitter.com/vO6UHlW7pf

— Qwen (@Alibaba_Qwen) 2025年7月25日

Qwen3 235BをRoo Codeで試したときに、ちょっと性能低いなぁと思ってたら、やっぱベンチの値も低くて、それを改善した2507モデルではLiveCodeBenchでGemini2.5 Proを越えたりしてますね。

Qwen Chatで試せます。
https://chat.qwen.ai/

で、期待していたので、試してみました。
今回は「砂っぽい挙動を再現しつつ砂時計をjavaとswingで実装して」とお願いしてみました。

結果・・・

砂が動かないとか形状が逆とかは置いておいて、問題は、修正をお願いしたときに単純なコンパイルエラーや無限ループや実行時例外が出ていたことです。
特に、30行程度のメソッドで変数の宣言が抜けてコンパイルエラーというのは、基本的な実装力の不足を表してると思います。

それが、Thinkingでめちゃくちゃ時間がかかってる割に改善されない。なので、これ以上の改善はあきらめました。

ということで、コーディング力に関しては期待外れで、本質的な能力はあまり変わってないなという印象。

Qwen3 Coderは良さそう

Qwen3 Coderというコーディングモデルも出ていました。480Bでアクティブ35Bという大き目のモデルです。

>>> Qwen3-Coder is here! ✅

We’re releasing Qwen3-Coder-480B-A35B-Instruct, our most powerful open agentic code model to date. This 480B-parameter Mixture-of-Experts model (35B active) natively supports 256K context and scales to 1M context with extrapolation. It achieves… pic.twitter.com/Z8HfyrVScE

— Qwen (@Alibaba_Qwen) 2025年7月22日

ブログはこちら
Qwen3-Coder: Agentic Coding in the World | Qwen

そして結果・・・

Qwen3 235Bのときと同様、円錐の向きが逆だったりしたのだけど、なんとか形は整えれました。
砂の動きも、よくみると境界判定に問題があるけど基本的にはよさそう。

コードが出るまでの反応が速いのもいいです。
また、ここに至るまでにいろいろな修正をしてもらってるのだけど、コンパイルエラーや実行時例外などは一度も出なかったので、基本的なコーディング能力は高そうです。

安定のClaude Sonnet 4

そしてClaude Sonnet 4。 砂の初期配置や砂時計の形状などの調整は しましたが、最初から砂の動きがちゃんとしていました。
やっぱりすごい。

現場で活用するためのAIエージェント実践入門 (KS情報科学専門書)

Jakarta EEは、なぜJakartaなのにApache財団ではなくEclipse財団管理なのか

Java EEはOracleの元を離れてEclipse財団に寄贈されJakarta EEになりました。

このJakartaという名前は、Apache財団でのJava系プロジェクトを管理するプロジェクトの名前で、TomcatやMavenなども最初はJakartaの下にありました。
略称がJEEになるような名前でJavaに親和性が高いということで最終候補に残り、もうひとつの候補であるEnterprise Profileに対して、65%の支持をえて決まったのだと思います。

であれば、Apache財団に寄贈しないのはなぜってなりますが、スポンサーみたらわかりますね。

Eclipse財団のトップレベルスポンサー。Javaでよく目にする企業が並んでます。
https://www.eclipse.org/membership/explore-membership/

Apache財団のトップレベルスポンサー。業務システムやってなさそう。

基幹系業務システムのJava標準を持っていくならEclipse財団ってなります。

じゃあなんで最初からEclipse財団のほうでJakartaやってなかったのかって話になりますね。
それは、Eclipse財団は名前のとおりEclipse IDEから始まっていて、Eclipse IDEはIBMが主導していて、つまりIBMの組織だったわけです。

一方で、Apache財団にはSun Microsystemsがスポンサーしていました。
Java標準に近いのはApache財団ってことで、Tomcatも寄贈され、JavaのオープンソースならApache Jakartaってなっていきます。

IBMは、JVMのJ9も含め「標準じゃないほうのJava」みたいになっていました。

2003年には、SunにもEclipseコンソーシアム(まだ財団ではない)に入ってもらおうとIBMからの独立へと動きます。
https://japan.cnet.com/article/20060766/:titile

で、2004年にEclipse財団として独立したものの、Sunは断っています。
Javaを巡るSunとIBMの争点「Eclipse」とは | 日経クロステック（xTECH）

ただ、2007年時点でも、IBMの依存度をさげるのに2-3年かかると言っていますね。
https://atmarkit.itmedia.co.jp/news/200703/09/eweek.html

その後、2009年にSun MicrosystemsはOracleに買収されてあまりわだかまりもなくなり、またApache財団からはSun Microsystemsの支援がなくなることで放置プロジェクトはリタイアし、活発なプロジェクトはJakartaのサブプロジェクトからトップレベルプロジェクトになり、2011年にJakartaプロジェクト自体がリタイアしています。

現場で活用するためのAIエージェント実践入門 (KS情報科学専門書)

他組織のAIエージェントをA2Aで呼び出すのは非現実的かも

エージェントとエージェントで通信するA2Aプロトコルで、さまざまなエージェントがやりとりする世界みたいなのが描かれがちだけど、組織をまたがって自分たちでコントロールできないエージェントにシステムが依存するのってあまり現実的じゃないなと思ったのでまとめてみます。

図解するとこう。他組織のエージェントで、内部でMCPやFunction Callingを呼び出しているものを、自組織のエージェントからA2Aで呼び出すという構造。

ただ、他の組織が自分の組織のためにエージェントを作ってくれているということはなくて、ユーザーが人間として使うエージェントをこちらのエージェントから呼び出してるということになると思います。

また、エージェントをなんで作ってるかというと、機能をたくさんもっていて統合的に使える手段が欲しいのでエージェントを用意という感じだと思います。自分たちが必要な機能以外にもたくさんの機能をエージェントはアクセスするはず。
そうすると、他の機能の対応が入ったときに、自分たちの欲しい機能へのアクセスの挙動が変わったりします。機能追加があればシステムプロンプトが長くなって、自分たちが使う機能のプロンプト中の存在感が相対的に減って、エージェントの動きが少し不安定になったりします。

ロジカルなシステムであれば、依存関係のない機能追加があったとき、既存機能には基本的に影響はありません。少なくとも、そのように実装します。けれど、エージェントの場合は、エージェントがアクセスする機能が変わったときの既存機能への影響は予測不能です。LLMモデルが変われば挙動も変わります。LLMプロバイダの内部的な変更で挙動が変わることもあります。

そもそもエージェントの動きが不安定で、コントロールできない中で自分のシステムが依存するのはちょっと怖い気がします。

また、LLMを露出させて機械からアクセスさせるというのは結構なリスクがあり運用コストもかかります。そうすると、比較的高い価格設定のアクセス料金と、結構厳しめな回数制限がかかってきます。

そうやって不安定さのリスクをとって高いコストをかけてエージェントを呼び出すメリットはなかなか出ないように思います。

それよりも、自組織でエージェントを作って必要な機能だけMCPなりFunction Callingなりで呼び出すとしたほうがよさそうです。

そうやってエージェントを自組織でコントロール可能にしておくほうが、運用コストも安く安定します。
元々のエージェントに組み込んでもいいけど、チャット履歴に異なる文脈を混ぜないほうがいいので、別の機能は別のエージェントにしたほうがいいですね。

他組織も、エージェントで稼いでるわけではなく、MCPで呼び出した機能の先で稼いでいると思います。それならば、エージェントがA2Aで公開されているのであれば、恐らく必要な機能はMCPやAPIで公開されるはず。

他組織のエージェントを呼び出すとしたら、分野特化Deep Researchのようなエージェントじゃないかと思います。そういったところはエージェントで稼いでいるだろうし。o3やGemini 2.5 Proとかは内部的にはエージェントですね。

現場で活用するためのAIエージェント実践入門 (KS情報科学専門書)

やさしいMCP入門