こんばんは！
いつも応援していただき、ありがとうございます。
apa（あぱ）です(^^)
今日は『いろいろなAI事情を鑑みて』について書いていきます。
またAIに悩んだ
うーん、結局どうすればいいんだろう、また悩んでしまうな。
いろいろあるからなぁ・・・
どうしたんですか？
a子さん。
何に悩んでいるんですか？
あ、apaさん。
そうなんです。
ここ最近、またAIの市場に変化が起きたみたいで。
どれを選べばいいのか、自分でもよくわからなくなっていたんです。
なるほど。
確かにここ最近、AIの変化は著しいですからね。
何がいいか悪いのかを見極めるのは結構困難ですよね。
本当にここ最近のAI市場はまた大きく揺れ動いているような感じがします。
いやもしかしたら自分の気持ち一つなのかもしれませんが。
ここ最近、terra6.1に魅力を感じて、
terra6．1を使い始めたのですが、
いきなりちょっと疑問を感じ始めました。
とにかくまぁ、自分の心持ちひとつなのか、
自分の使い方次第なのかはわかりませんが、
とにかくAIの使い方は難しいなと感じます。
結局クロードコードに戻った経緯を一つ
apaさんは、いまだと、クロードコードとCodex、どちらがおすすめなんですか？
それともkimi codeとか別の選択肢もあるんですか？
状況やその人のやっていることによって違うので一概には言えない部分はありますが、でも、個人的にはいままたクロードコードがいいのかな？と思い始めています。
どちらにしても、なにか間に、中間役に立ってもらうことが重要かもしれませんね。
Xのとある投稿で心変わり
Xの投稿で昨日の夜、この投稿を見て心変わりしました。
トークン上限の都合で丸一日6.1 Terraを試行しましたが、”Computer Useに最適化”という評判通りコーディングには適さない印象でした。 速さの定評がありますが、Sol Low の Ultrafast を知ってるとその魅力も消失。 Sol-6.1を思考停止で使ってましたが、改めて悪く無いモデルだと思いました。 なお、僕の中でOpus-5.5 Low のWorkflow最強説は揺らがない模様。Haiku-5.5は窓からブン投げました。
— 小林尚希@エックスサーバー (@xskobayashi) October 28, 2026
なぬ・・・
僕自身は結構昨日の夜までterraにハマっていたので、
ハマっていたというか結構いい感じだと思っていたので、この投稿を見て驚きました。
コーディングには適さない？
速さに定評はあるが魅力は低い？
あれ？
と思いました。
でも、確かに、
行き当たりばったり
その投稿にもコメントをしたんですけど、
確かにterraは少し行き当たりばったりの感じがあります。
返答は早いです。
驚くほど。
Xサーバーの小林さんのいう、sol low のultrafastは、プラスプランしか使っていない僕には試すことのできない高嶺の花。
そういう意味では、速度的な意味では、6.1terraで十分魅力的なんですけど、だけど行き当たりばったり。
同じ問題に遭遇して、大した対策を思いつく前に思いつきで対処して、問題解決に当たろうとしすぎている印象があります。
そうして、無駄にトークンを消費している印象があります。
うーん、「そのまま続けていたら、問題が解決せずにずっと同じことを続けるか、それか、その前にトークンが尽きるかのどちらかじゃない？」と思ってしまうような印象。
それだとちょっと良くないよなという感じです。
でも、要は、terraの思考力はそれほど深くない印象があります。
opus5.5低でワークフローを組んでみた
で、早速、その小林さんのいう、「ワークフロー」というのを組んでみることにしました。
あまり未だによくわかっています。
要は役割分担をするということだと思うのですが、
それで、精度を上げていくということだと思うのですが、
実際はどうなんでしょうかね。
とりあえずしばらく使って様子を見てみようと思います。
geminiに間に立ってもらうほうがいいかも
で、いま感じているのはgeminiに間に立ってもらうほうがいいかも、という話。
あまりないことかもしれませんが、
例えば、Codexに「この問題を解決するのにクロードコードとCodexどちらがいいですか？」と質問してもわからない。
もしくは、Codexと言いがち。
逆もまた然り。
どちらかに偏ってしまう傾向があるような気がするんですよね。
要は、いま、geminiの最大の欠点は、「コーディングができないこと」です。
で、そのコーディングができないという欠点を逆に長所と捉えると、
「自分がコーディングができない分最適なコーディングの案を出してくれる」
というのがあります。
自分がコーディングをできるAIに問い合わせると、どうも、自分の方によってしまうというか。
ご都合主義な回答が出てしまうような感じがします。
一方で、geminiに、
「このツールの修正を行うのに適しているAIはなんですか？」
と質問して返ってきた回答がこちらでした。
各ツールの強みと立ち位置
Kimi Code（Moonshot AI系）
強み：膨大なコンテキスト長（数十万?数百万トークン）の処理に非常に強く、リポジトリ丸ごとの読み込みや、長大なログ解析、深い推論（Reasoning）において非常に粘り強い出力をします。一部の開発者が「一番いい」と絶賛するのは、「長大なコードベースを一度に把握させて推論させる時の精度の高さ」によるものです。
弱点：エコシステム（VS Code統合、ローカル環境とのCLI連携、自動ターミナル実行など）の完成度や開発者体験の洗練度では、欧米の主要ツールに一歩及ばない場面があります。
Claude Code（Anthropic）
強み：ターミナルやローカルファイルとの密連携、サブエージェントによるテスト・自己修正ループ、人間が書いた仕様書（Markdown）に忠実に追従する能力が群を抜いています。エージェントとしての実用性・手離れの良さは現在トップクラスです。
Codex（OpenAI系 / GitHub Copilot等の基盤）
強み：インライン補完のレスポンス速度、IDEとの統合、一般的なコード補完の安定性とライブラリ知識の広さ。
なるほど。確かに、かなり詳しく教えてくれます。
ちなみにこれによると、kimi codeは、向かないらしいです。
ずっとkimi codeが気になっていたんですけどね。
一部、kimi code が一番という意見があったので、
それがずっと気になっていたんですけど。
どうやらいまは、
Codexやクロードコードがいいみたいです。
とにかく、しばらくクロードコードのワークフローで試してみます
とにかく、まぁ、自分自身の話で申し訳ないんですけど、しばらくクロードコードのワークフローで試してみようと思います。
クロードコードのワークフロー。
つまりクロードコードで役割分担をさせて、
適切な処理を行わせる作業。
うーん、それでこれまで抱えていた問題が解決に向かってくれればいいんですけどね。
どうなるんだろう。
とにかく早くツールの開発を終えて作業を進めたいというのがあるので、
ソレに向けて前進できるのであればいいかなと思います。
これからもgeminiを中間役に立たせようか
正直、geminiはそれほど賢いというほどではない気がします。
昨日も大喧嘩しました。
どうして、そういう回答になるのか・・・
たとえの意味がわからなかったので、
「その例えを使ってもう一度説明してください。」
といったら、
「あなたが気に入ってくれた名刺の例を使ってもう一度説明します。」
とのこと。
いつ誰がどこで「気に入った」と言ったのかがわからない。
そんなちんぷんかんぷんアンポンタンな回答をするgeminiですが、
まぁ、中間役として使う分にはいいかもしれません。
まとめ
そういうことなんですね。
terra6.1はちょっといきあたりばったりな印象
opus5.5低でワークフローを組むのがいいのかも
geminiを中間役にするのが意外と効果的？
ということですね。
そうですね。僕もまだ実証段階でハッキリとしたことは言えないものの、そういう印象はありますね。
わかりました。私も、opus5.5低でワークフローを確立してやってみたいと思います。
ありがとうございます。
最後まで読んでいただいてありがとうございます。感想、ご質問等がございましたら、お気軽にコメントをどうぞ(^^)
もしよければ、こちらから応援をお願いします。
よりお役に立てる記事を書けるようがんばれます(^^)
コチラ↓↓をクリックしてapaを応援
コメント