Copilot-Cliはそんなに悪くないよ。https://github.com/features/copilot/cli

そうそう、なんでみんなGeminiの選択肢を忘れちゃったのか理解できない。Antigravity、Jules、Gemini CLIは代替品と同じくらい良いのに、コストパフォーマンスが全然違う。月20ドルのGoogle AIプランで何も困ってないよ。

自分（や多くの人）の想定とは逆に、長文のエージェントコーディングタスクでは、モデルは思ったほど簡単に入れ替えられないことが分かったよ。CodexやClaude、Cursor（そのサブバリアント）、Composerなどが、スピードや正確さ、アーキテクチャの好みの異なる軸でどんな問題に対してうまく機能するかについて、かなりの直感ができてきた。Geminiをまだ使っていない理由を考えると、彼らが出遅れたからで、また新しい直感を学ぶために時間をかける必要があると思うと、ちょっと面倒なんだよね。

たぶん自分がやってるプロジェクトの種類のせいかもしれないけど、Geminiは基本的に使えない。実際の作業にはClaude Codeを使って、Claudeの作業をチェックするためにCodexを使ってる。Geminiを混ぜると、存在しない問題を高確率で幻覚みたいに出してくるんだよね。ClaudeとCodexは、実際に存在する問題を見つけるのがずっと正確だよ。

私にとっては逆の体験だな。Geminiはほとんど作り話や古い情報を生み出すだけ。

変なことに、Gemini 3がどれだけ印象的でも、あまり使うことがないんだ。Gemini 2.5が他のモデルより優れていたのは長いコンテキストに強かったからだけど、今はGPT5.2-codex-maxやOpus 4.5 Thinkingも長いコンテキストに decent になってきて、私が気にしている使い方では全体的に彼らの方が良いんだよね。

Geminiについての盛り上がりはすごいけど、私たちの製品（AIエージェント）に統合したら、ユーザーの「いいね/よくないね」の投票に基づいて、Claude SonnetやOpus、ChatGPT 5.2よりも一貫してパフォーマンスが悪かったよ。

使おうとしたけど、最大容量に達してるってずっと言われて、何も起こらなかった。諦めるまでに一日頑張ったけどね。

マイクロソフトとアップルがコードベースをジェミニよりもクロードに入れたがる理由が一つあると思う。

このコメントはちょっと混乱するし驚いたな。3週間前にAntigravityを試したけど、全然ダメだったから。Claudeはバグを特定してプロジェクト全体を把握できてたけど、AntigravityのGemini 3は重要じゃない細かいところにばかりこだわってた。普段使ってるのはAIスタジオのGemini 3で、プログラミングの問題でもそれを使ってる。でも、エージェント的な作業ではAntigravityはまだベータ版の初期段階って感じだったな。少なくともGemini 3は数回の反復で正しい解決策にたどり着くことが多いけど、Grokを中程度の複雑なタスクで試したら、細かい変更にこだわりすぎて動けなくなっちゃった。Antigravityをもっと効果的に使うアドバイスある？もう一度試してみたいと思ってる。

Gemini CLIも結構使ってるよ—仕事のサブスクリプションに含まれてるから。まあまあ好きだけど、ちょっと「嘘」を作りすぎる傾向があるかな。問題や解決策を見つけたって自信満々に言ってくるから、確認するのに余計な手間がかかるし、それを信じちゃうと時間も余計にかかる。私の経験では、Claude Codeはこれをかなり少なくやってる。

Anthropicにはモデルがあるけど、Microsoftにはない。

Recallは実際に役立ちそうだけど、マイクロソフトが自分を監視しないって信じるのは、雪玉が地獄で生き残るくらいの可能性しかないよね。

昨夜、盗まれたんだね。Jelly Rollが勝つなんてありえないよ。

面白い事実: ずっと前、数分ごとにデスクトップのスクリーンショットを自動で撮ってたんだ。これがたまに仕事を失ったときに助けてくれた。スクリーンショットを見返して確認できたからね。やめたのは、責任が重く感じたからで、あ、あまり見たくないスクリーンショットをレビューして削除するのが気まずかったから。

マイクロソフトは本当に名前の付け方をもっとちゃんとしないとダメだよ。マイクロソフトは、物の名前を付けるのが上手くなることは絶対にないと思う。マイクロソフトが異なる製品に対して一貫性のない名前を使うのをやめた日、宇宙が割れて異形の獣が星を飲み込むって言われてるしね。そうだよね、.Net/dotnet。

GitHub Copilotはコーディングのオートコンプリートツールだよ。いや、GitHub Copilotはオートコンプリート機能とチャットUIを持つAIエージェントツールだよ。名前についての意見は分かるけど、製品が何をするのかを知るのはいつも役立つよね。

あなたが言ってることは、少なくとも90年代後半からのMicrosoftのやってきたことそのものだね。

同意しないわけじゃないけど、これは2000年代初頭の「.NET」ブームに比べたら全然大したことないよね。実際の.NET技術とは全く関係ないのに、すべての名前に「.NET」を入れなきゃいけなかったし、その前には「Active」ってのもあったけど、.NETは次元が違うくらいクレイジーだったよ…。

僕の同僚は中規模のSaaS企業（従業員1000～5000人）で機能的な役割を担ってて、銀行やファミリーオフィス、ヘッジファンドと仕事してるんだ。彼らはTeamsとCopilotを使ってるけど、みんな嫌がってる。一つ分からないのは、非構造化データとデータベースを組み合わせて新しい会話に対する洞察を得るAI製品があるかどうか。例えば、LLMがユーザーのクエリをテーブルのドメインモデルに変換して情報を抽出できるとか。そんなことをやってる会社はどこ？これは企業が管理するオンプレミスやプライベートクラウドで展開できるものだと思う。データがかなりセンシティブだからね。

これはできない。意味不明なことを吐き出すだけだ。これがどれだけひどい失敗か信じられない。もしClaudeやChatGPTをシンプルなウェブインターフェースで使ったら、彼らは遥かに進んでる。

じゃあ、なんで誰がコパイロットにお金を払うの？ マイクロソフト製品を買う経営者たちは、マイクロソフトの製品名を決める経営者たちと同じくらい無知だと思われてるよ。

マイクロソフトの文化として、外部の名前付けがひどいのは長年のことだよ。

マイクロソフトは命名規則をもっとちゃんとした方がいいよ。でも、たぶん無理だろうね。マイクロソフトはこういうことを何度も繰り返すから。昔は全部「365」って呼ばれてたし、その前は「One」、そのまた前は「Live」だった… 20年前は、インターネットに関係なくても全部「.NET」って呼ばれてたし。90年代には、何でも「Active」って呼ぶのに夢中になってたよね。

マイクロソフトは命名規則をもっとちゃんとした方がいいよ。AIは製品のアイデンティティじゃなくて、機能であるべきだよね。今のマイクロソフトはPhotoshopをPhotoshop Neural Filterに名前を変えるようなもんだ。

本当に盛り上がってたのかな？結構低評価かマイナス評価の追加と見なされてたし、正直ここでAIがコーディングに役立たないって言ってる人を見ると、GitHub Copilotに影響されてて、以前の考えを更新するのを面倒くさがってるんだろうなって思っちゃう。

マイクロソフトはやっぱりマイクロソフトだね。

デモとしてはちょっとクールだったけど、Claude CodeはAIコーディングのゲームチェンジャーだったね。

仕事でVSCodeでCopilotを使ってるけど、結構効果的だよ。モデルもいくつか選べるし、IDEベースのAI開発ツールに期待するエージェント的な編集機能もある。フロントエンドの仕事はやってないから、ブラウザ統合みたいなことができるかは分からないけど、ここ6ヶ月で確実に改善されたね。他にもCopilotブランドの色々なものがあって、使い方は様々。ウェブベースのチャットはまあまあだけど、どのモデルが使われてるかは不明。何にせよ、すごく冗長だし、画像の扱いもイマイチ。Office系のやつは今のところ全然役に立たない感じ。

GitHub Codespacesが発表されたんだけど、VScodeとCopilotを使った無料のコンテナ化された開発環境で、もうめちゃくちゃだよ。VScode/Copilotの拡張機能は常に壊れたり変わったりしてる。GitHubのウェブインターフェースも今は使いづらくなって、もうブラウジングするのをやめちゃった。あっちの人たちはこれらが機能するかどうかなんて気にしてないみたい。（でも不思議なことに、Copilot CLIは実際にコードを書くのにCopilotのVSCode拡張より4倍も良く動くよ。）

Claude Codeはフルスタックだからね、モデルと実装、インタラクションがシームレスなんだよ。一方で、MSとGithubはChatGPTが残したかすかな手がかりを待ってる感じ。

答えはシンプルだと思う。Microsoftが「すべてにCopilotを！」って上から指示してたのは明らかだね。AIに全力投球したかったけど、解決すべき実際の問題から始めなかった。もし君がソフトウェアエンジニアやPMで、突然雇用や昇進が目に見える形で実装されたCopilotに依存することになったら、できる限り頑張って、誰も求めてないチャットボット（とか他のもの）を実装することになるよね。Anthropicのプロセスは分からないけど、特定の問題を明確に解決するツールを生み出した。要するに、コードを書くのが速くなるってこと。UIがプロダクトマネージャーが求めるものとは全然違うから、解決策は自然に成長したんじゃないかな。内部でどれだけの失敗があったか、他にどれだけの人がこの問題に対する別の解決策に取り組んでいたかは分からないけど、最終的に出てきたものはその問題を明確に解決して、他の問題にも一般化できる。つまり、Microsoftは技術のバズワードに集中してたみたい。Anthropicは人々が自分の問題を解決するのを許可して、実際に人々が求める製品につながった。違いは歴然だね。もしC-suiteがSWEsに生産的になるように指示して、特定の技術バズワードを強要するのをやめてたら、昨年の12ヶ月で何が起こったかは分からないね。

マイクロソフトは開発者を一人雇ってコーディングエージェントを作らせればいいのに、結局、みんなアンソロピックに屈してるのは、アンソロピックが経営者に夢のような状況を売りつけて、ほとんどの開発者をクビにできるからだよね。他のコーディングエージェントもCCより劣ってるわけじゃないし、ジェミニやクラッシュの方がむしろ優れてるし、コーデックスも悪くないし、オープンコードみたいなものも追いついてきてるよ。

マイクロソフトにはこういう製品を作るトップタレントがいないんじゃないかな。

大企業は、人々が実際に使いたいと思う製品を作るのが構造的に無理なんじゃないかな。顧客がロックインされてて、切り替えコストで縛られてる経験が多すぎる。Anthropicはまずは本当に使える製品を作らないと、後からダメになっていく（すでにそうなってるっていう話もあるけど）。大企業がそういう新しい技術を扱うときは、まずどこでも使えるようにして、その後にそれを成功させるスタートアップを買収するのが一番いいんだよね。マイクロソフトもそれをうまくやれなかった。

これは返信のつもりだったんだけど。

うん、全然良くなったね。Codexはプランの見直しにはいい感じ。切り替える必要はないよ。両方使えばいい。

Codexはあんまり使えないけど、GPT-5.2やその関連のモデルは、私の経験上、Opus 4.5よりもかなり良いコードを生成するよ。驚くほどの差でね。

以前はClaude CodeをOpusだけで使ってたんだけど、すごく良かったからね。そしたらAnthropicに禁止されて、OpenCodeに切り替えた。OpenCodeには勝ってほしいけど、UXの面ではまだまだ磨きが足りないし（メモリリークの問題もあるし）。Claude Codeは内部的にはハックの塊だと思うけど、見た目は結構うまく動いてる（フラッシュの問題はまだ直ってないけど）。OpenCodeに切り替えてGPT-5.2-Codexを使ってみたけど、私の経験ではかなり使えない。ずっと動いてくれないし、次に何をすべきかを教えてくれたり、特定のパズルの一部を理解したから続けるかどうか聞いてきたりする。Opusほど独立してないんだよね。今はCodex CLIでGPT-5.2を使ってるけど、ハーネスが問題かと思ったけど、これもあんまり良くない。