トークンの無駄遣いはやめろ！同じローカルLLMでPIコーディングエージェントとOPENCODEを徹底比較

日本語العربيةDeutschEnglishEspañolFrançaisहिन्दीBahasa Indonesia한국어PortuguêsРусский中文
LLuigi Tech
컴퓨터/소프트웨어게임/e스포츠AI/미래기술

Transcript

00:00:00皆さん、こんにちは。今回は Agent vs Open Code のデモとして、
00:00:092つの実行環境をテストします。例として使うのは、前回の動画で
00:00:20バイブ・コーディングしたこちらのゲームです。今回の動画では、
00:00:29バグを修正する方法をテストしたいと思います。ご覧の通り、
00:00:38Xが勝利しましたが、セルがハイライトされていません。そこで、
00:00:51ローカルLLMの Qwen 2.5 3B を使って修正を試みます。これは、
00:01:04現時点でPC上で動かせる最高のモデルだと思います。まずは Pika から。
00:01:16これが Pika です。ソースファイルがバラバラに置かれている
00:01:30このディレクトリ内で実行します。index.html、game.js、style.css があり、
00:01:42両方の環境で同じプロンプトを試して結果を比較します。また、
00:01:55タスク完了までの時間をタイマーで計ります。プロンプトはこちら。
00:02:11「セルの立方体をもっと見やすくし、間隔を空けてください」
00:02:19ご覧の通り、立方体同士が非常に密着しています。そして
00:02:282つ目のタスクは「勝利判定のロジック改善。勝利したマーカーは
00:02:37緑色になるように」。これも問題で、現状ではどのマーカーで
00:02:46勝ったのか分かりません。はい、プロンプトに従って開始しました。
00:02:59Pika が現在のディレクトリの解析を始めました。ここで
00:03:09使用されたコンテキストが見えますが、修正にかかった時間のほうが
00:03:20興味深いかもしれません。作業中です。その後、同じタスクを
00:03:30Open Code で行います。リポジトリをリセットして同じ条件にします。
00:03:41しばらく動画を一時停止します。修正が終わったらまたお会いしましょう。
00:04:00はい、完了です。変更内容のレポートを作成中ですので、
00:04:20その後に結果をテストします。Qwen 2.5 で 7分44秒かかりました。
00:04:38結果を見てみましょう。これがレポートで、コードに何が起きたか
00:04:47技術的な詳細が記されています。game.js の各所を
00:04:58何度か部分的に読み込んだようです。これが diff です。ファイルを
00:05:09大幅に編集したのが分かります。送信トークンは合計 9.4K、受信は
00:05:232.8K でした。これがコンテキストの使用結果です。リロードして、
00:05:35セルの立方体に間隔が空き、それぞれ分離されました。
00:05:44プレイしてみます。中央のセルから始めます。よし、
00:06:00コンピューターを勝たせてみましょう。完璧です。コンピューターが勝ち、
00:06:11立方体の間隔も広がり、勝利マーカーもハイライトされました。
00:06:20成功です。これは Pika コーディング・エージェントでした。次は
00:06:30Open Code で、同じモデルと同じコードを使ってテストします。
00:06:50コードをバグのある状態に戻しました。Open Code で同じ
00:07:00プロンプトを試します。セルの見た目と勝利ロジックについてです。
00:07:11自作の Basico というカスタム・エージェントで同じモデルを使います。
00:07:27Basico を作ったのは、デフォルトのコーディング・エージェントより
00:07:36ずっとシンプルだからです。Basico エージェントはこれです。
00:07:56ただのシンプルな Markdown ファイルです。「最小限のエージェント」とし、
00:08:07検索エンジンツールを使った Web 取得のみを指定しています。
00:08:15今回は使いません。Open Code で似たような条件を再現するための
00:08:24非常にシンプルな構成です。すでにコンテキストを 12K 消費しています。
00:08:34index や game.js から開始しました。ここでも一時停止後に
00:08:47最終結果を確認します。あまりフィードバックがないまま動いています。
00:08:58補足ですが、Gemma 2 27B でも同じテストを試しました。
00:09:07しかし、この種のプロジェクトでのツール呼び出しができませんでした。
00:09:20Gemma 2 は 3D 三目並べの再現はできても、ファイルを編集するための
00:09:30ツール呼び出しができなかったのです。そのため、このローカル環境に
00:09:38最適と思われる Qwen 2.5 のみでテストを行っています。
00:09:48ToDo を埋めているのが興味深いです。タスクは 2つあります。
00:09:58セルの視認性向上と、ロジックの修正です。そのため Pika より
00:10:07少しオーバーヘッドが生じます。Pika は ToDo を挟まずに
00:10:17タスクをこなせました。もっと複雑な状況なら ToDo は有効かも
00:10:26しれませんが。結局、実行環境（ハーネス）よりも LLM モデル
00:10:35そのものの差が一番大きいと私は考えています。様子を見ましょう。
00:10:44ではまた。
00:10:56...
00:11:27ほぼ終わりました。両方の ToDo が完了しましたが、まだ
00:11:40読み込みとファイルへの書き込みが必要です。
00:11:52レポートを書き終えたら終了のはずです。すでに 12分経過しており、
00:12:05より時間がかかっています。はい、終わりました。見てみましょう。
00:12:15Open Code でのコンテキスト消費は約 23K です。トークンの集計方法が
00:12:26異なるかもしれませんが、Pika は半分のトークン数で済みました。
00:12:36これが技術レポートです。修正のために game.js を
00:12:46何度も開いています。では、実際に修正が機能するかテストします。
00:12:57リロードします。Pika 版と似ていますね。中央のセルを選択。
00:13:19勝ってみましょう。はい、勝ちました。ご覧の通り、Pika と
00:13:32同様の結果が得られましたが、より多くのトークンと時間を費やしました。
00:13:43今回のケースでは、ガードレールやプロンプトの調整など機能が豊富な
00:13:55Open Code も同じ解決策を出しましたが、Pika のほうが
00:14:06短時間かつ少ないトークンで済みました。結論として、先ほど言ったように
00:14:18どの LLM を使うかが最も重要です。実行環境も有用ですが、
00:14:28コンテキストに投入されるデータの質こそが重要です。
00:14:36今回の Pika コーディング・エージェントはオーバーヘッドが少なく、
00:14:47長大なプロンプトがなくても良い結果が得られました。
00:14:58お好みのオープンソース・コーディング・エージェントをコメントで教えてください。
00:15:06では、また次の動画で。さようなら。

Key Takeaway

ローカルLLMを用いたコーディングでは、実行環境によるオーバーヘッドの差が顕著であり、PikaはOpen Codeと比較して約半分のトークン量と4分以上の短縮時間で同等の修正結果を出した。

Highlights

  • ローカルLLMのQwen 2.5 3Bは、3D三目並べゲームのバグ修正タスクにおいて実用的な性能を発揮する。

  • Pikaコーディングエージェントは、7分44秒の実行時間と合計12.2Kトークンの消費でタスクを完了した。

  • Open Code環境での実行時間は12分を超え、コンテキスト消費量も約23KトークンとPikaの約2倍に達した。

  • Gemma 2 27Bはコード生成能力を持つ一方で、今回のテストにおける外部ファイルの編集ツール呼び出しには失敗した。

  • PikaはToDoリストを作成する工程を省くことで、Open Codeよりもオーバーヘッドの少ない効率的な処理を実現した。

Timeline

ローカルLLMによるコーディング環境の比較準備

  • 実行環境としてPikaとOpen Codeの2種類を同一条件でテストする。
  • モデルにはローカルPCで動作可能な最高クラスのQwen 2.5 3Bを採用する。
  • テスト対象は3D三目並べゲームの表示バグと勝利判定ロジックの修正である。

ブラウザ上で動作する3Dゲームのソースコード一式を修正対象とする。セルの視認性向上と、勝利時に該当箇所を緑色にハイライトする機能の追加が具体的な目標である。両環境の性能を測るため、完了までの時間とトークン消費量を計測する。

Pikaコーディングエージェントの実行と結果

  • Pikaは合計12.2Kトークン（送信9.4K、受信2.8K）を消費してタスクを完遂した。
  • 修正完了までの所要時間は7分44秒を記録した。
  • 出力されたdiffにより、game.jsの大幅な編集と機能実装が正常に行われたことが確認された。

ディレクトリ内のファイルを解析し、ソースコードの部分的な読み込みを繰り返すことで修正を進める。生成されたコードを実行すると、セルの間隔が適切に空き、勝利時には期待通りマーカーがハイライトされた。複雑な中間ステップを挟まずに直接タスクを遂行する効率性の高さが示された。

Open Codeとカスタムエージェントによる検証

  • Open Code上ではシンプルに構成した自作エージェント「Basico」を使用してテストを行う。
  • タスク遂行の過程でToDoリストを作成するため、処理に一定のオーバーヘッドが発生する。
  • Gemma 2 27Bなどの他モデルでは、ファイルの編集に必要なツール呼び出しができずタスクを継続できなかった。

Pikaと同じプロンプトを用いて同一のバグ修正を試みる。Open Codeの構成は標準的だが、実行中にタスクの分解やToDoの整理を行うため、Pikaに比べてステップ数が増加する傾向にある。特定のモデルではロジックの理解はできても、実際のファイル操作ツールを使いこなせない限界があることも判明した。

実行効率とトークン消費量の最終比較

  • Open Codeのコンテキスト消費量は約23Kトークンであり、Pikaの約2倍のコストがかかった。
  • 実行時間は12分を超え、Pikaよりも大幅に時間を要する結果となった。
  • 最終的なコードの品質は両環境で同等であり、出力結果に大きな差は見られなかった。

どちらの環境も正解に到達したが、リソース消費量には明確な差が出た。Open Codeはガードレールや詳細なプロンプト管理機能を持つ反面、トークン消費が激しくなる。結論として、使用するLLM自体の性能が最も重要であるが、実行環境によるデータ投入の質の管理が効率性を左右する。

Community Posts

No posts yet. Be the first to write about this video!

Write about this video