Mac用ネイティブランチャーアプリの開発を題材に、GPT-5.5（CodeX）とOpus 4.8（Claude Code）のAIエージェントのコーディング能力を比較検証する。明確な手順を指定せず最終目標だけを与える/goalモードと通常の構築プロセスを用い、計4パターンの並行ビルドを実施する。デザイン案の生成過程から実装内容、そしてトークン消費量やビルド時間のコスト計算までを詳細に比較し、プロンプトの出し方による成果物の品質やアニメーションなどの完成度の違いを明らかにする。
はじめに：AIエージェント同士の開発対決
今日はこの企画をお届けできることにとてもワクワクしています。この種の企画は久しぶりですね。半年から8ヶ月ほど前はかなり流行っていましたが、最近は少し落ち着いていたので、ここでまた復活させたいと思います。とても楽しいですし、試してみる価値がある内容です。今日やることは、ある大きな条件を1つ設けています。それは後ほどすぐにお見せしますね。エージェントに作らせるには本当に面白くてクールなアプリケーションになる予定で、今回は2つのエージェントを競わせてみます。GPT-5.5とOpus 4.8のどちらがうまく構築できるかを見ていきましょう。それが本日の最大の課題です。どちらが最も優れたものを作るのでしょうか。そしてその過程で、私がどのように製品をデザインしたかや、いくつかの小ネタもお見せしつつ、このシリーズの今後の展開についても少しほのめかしていくつもりです。きっと楽しいものになるはずです。
今回構築するアプリケーションの概要
さて、これ以上進める前に、まずは今回構築するものをお見せしますね。コンセプトを掴んでもらうために少しだけここでお見せしますが、これは私のMac上のネイティブアプリケーションになります。つまり、今見ているようなWeb上の表現ではなく、ごく普通のランチャーアプリケーションになるということです。どんなものかというと、円状のダイヤルの周りにさまざまなアプリを並べ、そこから選択できるようなアプリケーションです。矢印キーを使ってさまざまなアイテムを選んだり、用意された異なるページ間を行き来したりできます。そして、それぞれの項目に入ると、それらを編集して異なる場所に別のものを配置したり、別のアプリを割り当てたりできるはずです。つまりランチャーなのですが、特定のアプリケーションでファイルを開く機能も備えているため、単なるランチャー以上の機能を持っています。Finderでこれを使えば、特定のアプリケーションでそれらのファイルを開くことができるはずですし、Webサイトを立ち上げることもできるはずです。このランチャーを使えばほぼ何でもできるようなものを目指しています。この種の表現を伴う、非常に複雑な要求のセットになっています。今ご覧いただいているこの図は、今回これらの非常に高度なモデルに与えるリクエストの一部であり、彼らがこれをどのように構築するかを見るためのものです。それが今回の目的なのです。特にSwiftで構築するのはかなり難しいはずなので、どうなるか見てみたいと思います。しかしそれ以上に、モデル同士を競わせてみたいのです。では、さっそくそれを始めましょう。まずは実行を開始して、それが動いているのを見ながら、このデザインをどのように作成したかをお話ししますね。とても簡単で、すごくクールな方法です。
エージェントの起動と目標設定
さて、これは簡単に進められます。私がどうするかというと、CodeXのデスクトップアプリケーションを使います。これは実質的にCodeXのCLIですね。これを立ち上げて開始させます。同時に、Claude Codeのデスクトップアプリケーションも使用して、そちらも開始させます。これで両方とも起動して構築が始まりました。ちなみに、Claude CodeではOpus 4.8を利用し、CodeXではGPT-5.5を利用しています。ただ、今回はお楽しみとして、ゴールという項目も新しく追加してみます。そのために2つの新しいワークツリーを構築しました。CodeXでも同じようなことを行います。/goalを使って同じ作業を行い、/goalを実行するように指示します。ゴールとして送信されるのがわかると思います。Claude Code側でもまったく同じことを行います。さあ、始まりました。ダジャレではありませんが、目的はこれらの両方を/goal機能を使って実行させることです。これはより自由度の高い構築プロセスになります。私たちが構築したい製品についてこれほど完全な定義が用意されている状態で、単一のマスターエージェントに直接指示を出して必要なだけ展開させるのと比べて、ゴールモードが優れているかどうかを見るのは非常に興味深いですね。どうなるかはまだわかりませんが、さっそく確かめてみましょう。
Claude Designを活用したUIの構想プロセス
さて、ここでおまけとしてお見せしたいことの1つは、このアプリケーションをどのようにデザインしたかということです。以前にもこのシステムの構築を依頼したことがあるのですが、その時はかなりひどい出来栄えになってしまいました。そのため、システムに魅力的でエレガントで、ある程度のアニメーションを備えた円形のダイヤルやシステムを想像させるための、創造的な方法を思いつく必要がありました。それはシステムが自発的に思いつくほど明白なものではなかったからです。私が取った手順をお見せしますね。まず最初に、Claude Designを使用しました。Claude Designは素晴らしい製品です。Anthropicのサブスクリプションを持っていれば、Claude Designにアクセスできます。私の最初の要求はかなり大きなものでした。基本的には私たちが望むものを伝えました。3つの異なる層のリングがあり、そこに異なるアプリが配置されているような放射状のリングが欲しいという内容です。これの多くは元の要求のせいであり、それがかなり広がりのあるものだったからです。広がっていること自体は問題ありませんでしたが、テーマに沿った6つのバリエーションを求めました。その中から選べるかもしれないと思ったからです。そして、最初に提示されたのがこれです。同じテーマのバリエーションが見られますが、すべてのバリエーション間で非常に似通っています。その後、これが作成され、私は少し反論して、このデザインを維持してほしいと伝えました。つまり、今見ているこのドキュメントにある、すでに提示されているものをすべて維持したまま、実質的にバージョンアップさせるように指示したのです。そして、同じページにこの追加情報を含めてもう一度やり直すように言いました。すると、ここにより多くのアイテムが追加されました。最終的なデザインに見られるようなモードを作成できるセクションのようなものを作りたかったのです。これでさらに6つ提示されました。これらについて私が言えるのは、まあ悪くはないということだけです。素晴らしいとは言えず、あまりワクワクしませんでした。私はAAA級のゲームのような表現を求めていると伝えていたので、高度にグラフィカルになる機会があったはずなのですが、これは私が望んでいたよりもずっと機械的な感じがしました。
それで次にどうしたかというと、ChatGPTのところへ行って、画像モデルを使ってみようと考えました。画像モデルは非常に創造性が高いので、まずはそこから始めて、アイデアを広げられるか試してみようと思ったのです。そこで、先ほど伝えたのとほぼ同じ元々の要求に、いくつかの要素を追加して与えました。そこから出てきたものは比較的興味深いものでした。極めて魅力的というわけではありませんでしたが、先ほど見ていたものと比べるとグラフィック的に非常に面白かったです。そして、アイコンの層が1つ、現在のモードを示す層が1つ、そして中央にはモードを切り替えるために押せるボタンがあるというシンプルさがとても気に入りました。本当にきちんとしていて、非常にシンプルで、より創造的なパターンでより多くのアイコンを配置できる余地がありました。ですから、率直に言って、この一番下のものだけのスクリーンショットを撮りました。スクリーンショットユーティリティを使って、この一番下の部分だけのスクリーンショットを撮り、それを次に渡したのです。
では、Claude Designに戻りましょう。さて、ここClaude Designでは、これをどう見ていたかというと、最初のフルスクリーンショットを渡し、後で戻ってきて小さいスクリーンショットだけを渡して、これに注力してほしい、これまで考えていたよりももっと大きく、より良いものを考えてほしいと伝えました。また、このファイルをバージョン管理するようにも指示しました。このファイルを保持したまま、新しいバージョンを作成してほしかったのです。そうして出てきたのがこのようなものでした。ChatGPTの出力から求めていたものに近づいているのがわかりますが、まだ完全ではありません。そこで、今度はこれのスクリーンショットを撮って、これは非常に良い出発点だ、まったく新しいコンテキストを始めると伝えました。そこで一番上でまったく新しい会話を開始し、新しいコンテキストに移りました。その1つの画像だけを与えて、この1つの画像から、ここにあるようなずっとシンプルなデザインメッセージで押し進めていこうと伝えました。すると、このバージョンの作成が始まり、これは素晴らしいと思いました。素晴らしい第一歩です。外側のリングの周りにすでにアニメーションがあるのがわかります。文字が多すぎる部分もありましたが、素晴らしいスタートでした。その後、何度かやり取りを重ねて、先ほどお見せしたような最終的なデザインにたどり着きました。また、矢印キーを使いたいといったことも伝えました。ここで私が行ったイテレーションでは、新しい発見や探求をしながら、提供されたアセットを元に作業を進めました。私はさらに踏み込んで、中央に文字を置く代わりに、その時に選択されているアイコンを複製して中央の下のほうに配置しようと提案しました。そうすることで、ノード間を移動する際にその画像が強調されるように感じられるからです。そして、矢印キーを使って外側を回り、Enterキーを押せるようにしようと提案しました。そういった一連のやり取りを経て、ここに落ち着きました。次にこれをパッケージ化しました。Claude Designから共有する方法があります。ここから送信メッセージを使うことができます。このプロンプトをコピーしてエージェントに渡すだけです。残念ながら、これはうまくいく時といかない時があることがわかりました。彼らもまだこれに取り組んでいる最中なのだと思います。エージェントが何度も戻ってきて、OAuthか何かの理由でうまくアクセスできないから助けてくれないかと言ってくることがありました。しかしそれを解決するには、このボックスをクリックしてダウンロードすればいいのです。そして、ダウンロードしたzipファイルをエージェントに渡す際、これがエージェントに与えたいプロンプトになります。zipファイルをドロップしてそれを渡せば、必要なリソースはすべて揃います。以上が、このリングの仕組みを採用し、Claude Codeやその他の場所に持ち込んでデザインを進めるための方法論です。ここからがスタートです。これらがこの最初のビルド環境内にあるリソースです。
Open Designという新たな選択肢
しかし、もう1つだけ手短にお見せしたいことがあります。これには驚かされました。ここで新しい製品を紹介します。私にとっては新しいですが、皆さんの多くにとっては新しいものではないかもしれません。Open Designと呼ばれるものです。あるチームがClaude Designがやっていることを見て、ほぼ同じ製品をオープンな形で構築しようと決めました。ここに入って、自分のサブスクリプションや自分のAPIキーなど、必要なものを何でも入れることができます。本当に非常にオープンな作りになっています。そして私が最終的に行き着いたのは、同じビルドの別バージョンでした。Open DesignとClaude Designの比較をしたいので、これについてはまた後日共有するつもりです。今はできるだけ早くこれをお見せしたかっただけです。もしデザインツールを探していて、Claudeのサブスクリプションを持っていないか、そこから大きなメリットを見出せていない場合は、ぜひOpen Designを見てみてください。
並行ビルドの進行とゴールモードの意義
よし、始めましょう。これらが彼らが構築しているアプリです。私たちの画面にポップアップして、彼らのバージョンのビルドを見せようとしています。ちなみに、すでにめちゃくちゃ良さそうに見えますね。ちょっと見させてください。これはすでに素晴らしいです。最近のモデルは本当に驚異的ですね。おお、素晴らしい。最初の設定パネルが出ました。興味深いですね。どうなっているか見てみましょう。おお。一度にいろんなことが起こりすぎていますが、ワクワクします。あの設定パネルをもう一度見てみたいですね。素晴らしい。最高です。彼らに任せておきましょう。画面のあちこちでウィンドウがポップアップしては閉じています。基本的には同じアプリケーションの4つのビルドを、すべて同時に並行して行うというのは最善のアイデアではないかもしれませんが、最高ですね。おおっと。多くの方にとって驚くことではないでしょうが、どうやらClaudeはGPT-5.5に比べてかなり遅れをとっているようです。それは必ずしも驚くべきことではありませんね。ちなみに、GPT-5.5はゴールモードも通常モードも両方とも完了しました。そしてこちらがゴールモードではない通常のOpusのビルドです。よし、近づいてきました。Claude Codeのゴールビルダー以外はすべて完了しましたが、ネタバレしないように言っておくと、Claude Codeのゴールビルダーはかなり印象的です。また、キャプチャの実行方法が意図的に画面外で行われていたことも報告されています。それがどうなるか見てみましょう。しかし、これまで行ってきたすべての画面キャプチャやその他の処理において、システム全体ではなくレンダリングされたものの写真を撮っているというのは、本当にかなり素晴らしいことです。構築中に私のデスクトップのスクリーンショットを誤って撮ってしまうことがないわけですからね。おお、よし。今最初のヒントが得られましたし、皆さんも見たはずです。なんだかすごく良さそうに見えます。ゴールモードではないバージョンと比較するのが待ちきれません。ええ、とてもエキサイティングです。しかし、この時点で38分から40分ほど経過していることは注目に値します。他のものについては、結果がどうなったかがわかる表を後で用意しますが、CodeXの方がはるかに早く終わりました。しかし、スピードだけの問題ではありません。
待っている間に、/goalについて少しだけ手短にお話しさせてください。これについて深く掘り下げるつもりはありません。もっと詳しく話すために、いつか別の動画を作ることができますからね。私が一連のファイルを持っていると言った時、実際に何をしているのでしょうか。このリポジトリの中を見ると、15個ほどのファイルとあのスクリーンショット、そしてデザインの段階で見ていた例からのサンプルコードがいくつか入っています。ここにあるのはそれだけで、それが何をするべきかを説明しています。つまり、リクエストを表す複雑なファイルのセットだということです。理にかなっていますよね。私はそれを通常のやり方と同じようにエージェントに入力しました。そのエージェントはそれを見て、計画エージェントのようなものに通し、計画が何であるかを把握し、その計画に沿って作業を進めます。これが今起きていることであり、最近のエージェントはこれが非常に得意です。ですから、自分自身で計画モードを行う必要は本当にありません。PRDのようなものに細かく分解する必要もありません。しかし最近では、こうしたエージェントシステムやハーネスの一部に、ゴールという別の側面の作業が存在します。これは、構築してほしいものの絶対的な定義セットを持っていないという概念です。ちなみに、今回のシステムも絶対的な定義セットを持っていません。少し曖昧にしておいて、構築システム自体に他に何を構築する必要があるかを把握させるのがその意図だからです。ただし、Webサイトやアプリケーションなどを開けるようにする必要があるとは指定しています。目標へと到達するための明確なステップがわからない時にゴールが存在し、エージェントシステムやハーネスシステムが最終目標に到達するための道筋を自分で見つけ出すことを可能にします。アイデアとしては、/goalで達成してほしい目標を提示し、測定可能な要素と、完了したと判断できる測定のレベルを提示するということです。つまり、準備ができているかどうかを読み取るための何らかのメカニズムですね。ここでもお見せしたように、プロフェッショナルでリリース可能なレベルのコードにするという指示を与えました。これは達成目標としては非常に柔らかい測定基準ですが、システムはそれを利用して、その目標を満たしたと感じるまで実行し続けようとします。つまり、私がゴールを使用している本当の理由は、このようなややオープンエンドなビルドにおいて、ゴールモードの時の方がうまく構築できるのか、それとも真っ直ぐ指示を出してメインエージェントに構築の道筋を決めさせた時と同じように構築するのかを確かめるためなのです。私たちが検証しているのは本当にそれだけです。
通常モードの成果物の検証
さて、ようやく完了しました。ついに来ましたね。まずはClaude Codeの最初の通常バージョンを実行しています。とりあえず試してみます。ちょっと手早く実行して様子を見てみましょう。構築はできているようです。では、オプションとスペースでもう一度試してみましょう。よし。完璧に要件を満たしているとは言えませんが、アイデアとしては確かにそこにあり、さまざまな領域を上下に移動できます。アクションを追加しようとすると、壊れたパネルのようなアクションメニューが表示されますね。興味深いです。なるほど。これが通常バージョンです。これはClaude Codeの非ゴールバージョンだということを覚えておいてください。ではCodeXの通常バージョンを実行して、少しでも良くなっているか見てみましょう。先ほどのはダメだったと言わざるを得ませんからね。よし。よし、いきます。CodeXの通常ビルドを実行します。よし、バックグラウンドではないですね。大丈夫です。ここのホットキーは何でしたっけ。よし、いけました。ホットキーはControl + Option + Spaceです。よし、そこからクリックして離すと、そこに配置されます。カーソルの下で機能します。明らかにこちらの方がすぐに優れているとわかります。完璧に機能しています。周囲も完璧に機能しています。マウスカーソルが要素にフォーカスを与えています。おお、すごい。ええ。これは本当に素晴らしいです。これらのアイテムの1つをクリックすると、設定パネルが表示されます。ええ。あらゆる種類の素晴らしい機能があります。これらは異なる内部モードです。ワークリングはこちらで、ウェブリングはあちらです。そしてこれらは異なるリング、つまり異なるモードそのものです。とてもクールですね。現時点ですでに完全に意味のある価値があると思います。これはちゃんと動くようです。かなり使い込む必要がありますし、これは内部にあるすべての機能を完全にテストしたわけではありません。しかし私がまず最初に確認したいのは、私たちが要求していた意図に近いかどうかということです。現時点では分離されています。これらのオブジェクトのそれぞれが分離されています。外側のリングはアニメーションしていません。私たちが渡したサンプルで定義されていた興味深い細かいディテールで、見落とされている部分がたくさんあります。しかし、多くの部分を正しく理解しています。ここからスタートできるのであれば、私は非常に満足だと思います。ということで、これは合格です。よくできました。
ゴールモードの成果物の検証（CodeX編）
よし。そしてここまできました。CodeXのまま進めます。またしても複雑になってきているのは承知していますが、CodeXに留まり、CodeXのゴールバージョンを実行します。これがどのように機能するか見てみましょう。ええ、ずっと良いですね。先ほどCodeXを見ていましたが、これも再びCodeXです。右回りの動きがありますね。素晴らしい。いやあ、すごい。よし。そのあたりは本当に正しくできています。一度消して、マウスを動かして、また戻してみましょう。画面上のスペースにも注意を払っています。画面外に出ると、そこに留まります。強制的に画面上に留まろうとしています。素晴らしいですね。皆さんには見えないでしょうが、別のモニターで試してみます。別のモニターでも機能しました。これを見てみましょう。いいえ。すごくよく機能しています。常に私のカーソルのところに来ます。すごい。よし、これは良いです。ゴールモードの方が良かったでしょうか。はい。知覚できるレベルでイエスです。意味のあるレベルで100%良くなっています。どんな設定があるか見てみましょう。1つ追加して、設定メカニズムがどのようになっているか見てみます。それぞれの異なるシステムに何があるのか、それらをどのように起動するのか。おお、それぞれのシステムを起動するためのすべてのパラメータがここにあります。いやあ、これは素晴らしいと思います。当然ながらかなり複雑なソフトウェアなので、いろいろといじる必要がありますが、すでにちょっと欲しくなっています。それに、それを選択したらGoogleが読み込まれましたからね、当然ですが。Webモードにいて、天気のアイコンに行くとします。太陽のアイコンは天気のようです。よし。すみません、遊んでしまいました。
ゴールモードの成果物の検証（Claude Code編）
では最後の1つ、Claudeとそのゴールメカニズムのようなものに移りましょう。これには大きな期待を寄せています。よし。ここがClaudeのゴールバージョンですが、実行方法や起動方法に関する情報も提供してくれました。一度実行したら、そうしてくれたのはこれだけだったので、そこは本当に評価したいですね。よし。よし。メニューバーにあるリングのアイコンを探してくださいとのことです。とてもクールですね。よし。開くのを見ましたか。おお、かなり素敵です。アニメーションして出てきます。すべてのアイコンがアニメーションしながら展開します。そして繊細ですが、アイコンがパッと切り替わるのではなく、フェードしながら次のアイコンに溶け込んでいきます。かなりいっぱいになっているものを出せるかやってみます。いいえ、ループバックの動きがありますね。これは、円の中の特定の位置に何かを移動させるというものです。0度に戻すと、逆方向にスナップバックします。これは非常によくあるCSSの問題です。あらゆるところでよくある問題です。彼らがそれに気づかなかったのを見るのは興味深いですね。外側のアニメーションはありませんが、ラインが非常にタイトに作られています。すべてが本当に正しく閉じられています。これは本当にプロフェッショナルなレベルに非常に近く感じます。見てみましょう。ピッカーに入った時にリングを閉じました。これはすでにずっと良く見えます。率直に言って、これは私が今見たアプリを意味のある形で表現しているように感じます。色使いもここで引き継がれています。さまざまな色を選ぶことができます。おお、ここで起こっていることが本当に気に入りました。それに、これは明確な違いがあったでしょうか。1000%イエスです。覚えているかと思いますが、先ほどのバージョンはあちこちがカクカクしていて、まともに動きすらしていませんでした。では、ゴールは私にとっていくつかの問題を解決しているのでしょうか。軌道修正できているのでしょうか。はい、できています。
コストと消費トークンの分析
さて、皆さんにお教えしたい秘密があります。共有したいことがあるのです。実質的なコストを見てみましょう。これらはどれだけのトークンを消費したのでしょうか。後で表にまとめますが、まずはここでどのように報告されているかをお見せします。まずCodeXを見てみると、CodeXが一番速かったです。ご覧の通り、通常バージョン、つまり非ゴール版は構築に28分かかり、最終的には約40万から50万トークン、50万前後の範囲になりました。それが非ゴールバージョンでしたよね。そして約28分から30分しかかかりませんでした。こちらのゴールバージョンに行くと、ああそうです。ゴールバージョンは、ゴール版の方が早く完了したとはっきりと私に告げています。そして記憶している通り明らかに出来が良く、トークンの消費量も少なかったのです。これは非常に興味深いですね。ちょっと確信は持てません。驚くべきことですが、実際により速かったのです。とても興味深いです。ゴールを使用したこちらのベストバージョンは25分でした。ではClaude Codeを見てみましょう。通常バージョン、つまりゴールなしでそのまま使用した場合を見ると、ええと、36分かかりました。ですから、作業を終えるまでに8分から10分ほど長くかかったことになります。約30分という時間を考えると、これは無視できない差です。そして、ここには3600万トークンと書かれていますが、そのうち3500万はキャッシュの読み込みなので誤解を招きやすいです。計算してみたところ、実際には約117万トークンであることがわかりました。これが通常バージョンです。36分で117万トークンというのは、ある意味信じられない数字です。しかもそれは全く使い物にならないカクカクしたものでした。非常に驚きです。最後は、私たちが一番気に入ったものです。ゴール版を見てみましょう。さて、ゴール版の報告によると、48分で約50万トークンだったとのことです。これは群を抜いて一番長いです。さらに12〜15分ほど余計にかかっています。この作業を行うのに時間がかかるようになってきています。しかし、最も少ないトークン消費というわけではありませんでしたが、CodeXのゴール版や通常バージョンと同じくらいしか消費しませんでした。中間くらいですが、通常バージョンで見た117万トークンには遠く及びません。そして圧倒的に最高の出来でした。ですから、もしゴールモードがトークンを大量に消費してしまうから悪いものだと考えているなら、これが私の実例です。私は実際にはそうではないと思います。自分が要求しているものにある程度の変動性があり、それにチームを割り当てて、エージェントにそこに到達する方法を考えさせたいようなオープンエンドの要求がある場合、ゴールモードはあなたの助けになるかもしれないと言っておく価値があります。ぜひ一度試してみてください。ここではるかに優れた結果になることが本当にわかりました。そして今、私の手元にはクールなアプリケーションがあります。
総評と今後の展望
さて、興味を持っていただけたなら嬉しいです。この種の比較検証はしばらくやっていませんでしたからね。これは本当に楽しいです。複数のモデルを使って何かを構築するのはいつだって大好きです。4つの異なるビルドをお見せしてしまってすみません。すべてを頭に入れておくのはほぼ不可能ですからね。明らかに、どちらのケースでもゴールモードの方が測定可能なレベルで著しく優れていました。誰が見ても、少なくとも要求されたものに近いのはこちらだとか、こちらは機能するけれどあちらは全く機能しないといった違いは非常に簡単に判別できるはずです。ですから、その点は認識しておく価値があります。OSにどれくらい統合されているかなど、テストしていない他の機能もたくさんあるので、カメラを回していないところでオフラインでテストしてみます。もし他のすべてをめちゃくちゃにしてしまっていて、実はゴールモードが思っていたほど機能していなかったというようなことがあれば、必ず後で報告します。しかし同時に、私にとっては本当に価値のあることでした。疑う余地なく、Claudeの圧勝だと言えます。しかし、GPT-5.5のCodeXも本当に非常に素晴らしかったです。もし使わなければならないアプリケーションがそれだったとしても、私は満足したでしょう。設定パネルに少し手を入れて、ここを少し直してほしいと伝えたり、あと1〜2回パスを回したりすれば、Claudeがゴールモードで到達した最終ビルドのレベルまで持っていくことができたはずです。最近はどれも非常に僅差になっていますからね。さて、私がこれからやろうとしていることを皆さんに共有したいと思います。私はベンチマークを実行し、新しいモデルが出た時にそれについての動画を共有しています。実際にテストしたモデルが複数あります。ベンチマークは公開されています。説明欄にリンクを貼っておきますので、スコアを見に行くことができますよ。MiniMaxやGrok、その他のモデルがどのようなスコアを出しているかを知るために、私の動画が出るのを待つ必要はありません。まだすべてをスコアリングしたわけではありませんが、かなりの数をスコアリングしました。それらについてはまた別の動画で報告します。MiniMaxやKimiなど、皆さんが非常に興味を持っているいくつかのモデルを取り上げた動画を作る予定です。リクエストもいただいていますので。その数字をお見せしたいのですが、私の目標は、そうしたモデルのいくつかに時々このアプリケーションの構築に挑戦させて、どのように構築するかを感じ取ることでもあります。構築に30分、一番長い場合は約1時間かかったので、すべてに対してそれを行うことはできません。しかし、スポットチェックとして行うことで、それがどれほど劣ったモデルなのか、その出来の悪さはどのようなものなのかを本当に把握することができます。言っている意味はわかりますよね。それでは、今回もお付き合いいただきありがとうございました。また次回お会いしましょう。
コメント