Gemini CLI と Claude Code の処理結果比較
Gemini CLI と Claude Code に同じプロンプトを与えた場合に、処理結果にどのような差があったのかまとめたいと思います。
プロンプト付与時点
まずあらためて与えたプロンプトはこちらです。
> 以下の機能を満たす新しいページを作ってください。
なお、ファイル名はtext_edit_page.dartで、
Riverpod+Hooks+Freezed前提で他のページとスタイルを合わせて作ってください。
1.ユーザーがテキストを入力する
2.ユーザーがボタンを押すと、入力したテキストがリッチなテキストで表示される
3.ユーザーがボタンを押すごとに、入力したテキストのスタイルがランダムに変わる
4.リッチなテキストをタップすると、その文字がシステムとしてコピーされる。(複製されるわけではなくテキストをどこかにペーストできるようになる)
5.コピーされたらコピーされたことがわかるようにトースト表示してください。> 以下の機能を満たす新しいページを作ってください。
なお、ファイル名はtext_edit_page.dartで、
Riverpod+Hooks+Freezed前提で他のページと
スタイルを合わせて作ってください。
1.ユーザーがテキストを入力する
2.ユーザーがボタンを押すと、入力したテキストがリッチなテキストで表示される
3.ユーザーがボタンを押すごとに、入力したテキストのスタイルがランダムに変わる
4.リッチなテキストをタップすると、その文字がシステムとしてコピーされる。(複製されるわけではなくテキストをどこかにペーストできるようになる)
5.コピーされたらコピーされたことがわかるようにトースト表示してください。⏺ Flutter のプロジェクトでtext_edit_page.dartを作成します。
まず既存のコードベースのスタイルを確認して、Riverpod+Hooks+Freezedの構成を理解します。
⏺ Update Todos
⎿ ☐ 既存のページのスタイルとRiverpod+Hooks+Freezedの使い方を調査
☐ text_edit_page.dartの基本構造を作成
☐ テキスト入力フィールドとボタンを実装
☐ リッチテキスト表示機能を実装
☐ ランダムスタイル変更機能を実装
☐ タップでコピー機能を実装
☐ トースト表示機能を実装どちらも同様にプロンプトを解析し、どのような手順で進めるのかタスク化していることがわかります。
ひとつひとつの手順が具体的に書かれているので、ユーザーにとってはわかりやすいですね。
また、「4. ナビゲーションの追加」ということで、指示に含まれていなかったにも関わらず、その画面を確認できる導線を用意してくれました。
「既存のページのスタイルとRiverpod+Hooks+Freezedの使い方を調査」ということで、既存コードを解析してくれるという安心感があります。
Gemini CLIほど詳しさはありませんが、簡潔にToDoを挙げています。
プロンプト実行時
まず、どちらもソースコードに手を加える際には、ユーザーの許可をとってくれます。
✦ fluttertoastパッケージが見つかりませんでした。
トースト表示には、既に追加されているflutter_easyloadingパッケージを使用します。
まず、テキストとスタイルを管理するための状態管理ファイルを作成します。
プロジェクトの構成に合わせ、lib/provider/ディレクトリにtext_edit_provider.dartとtext_edit_state_notifier.dartを作成します。
✦ Freezedで生成されるファイルを作成するため、build_runnerを実行します。
╭────────────────────────────────────────────╮
│ ✔ Shell flutter pub run build_runner build --delete-conflicting-outputs │
│ │
│ bash: flutter: command not found │
│ │
╰────────────────────────────────────────────╯
✦ flutterコマンドが見つからないようです。
FVM(Flutter Version Management)を使用しているようなので、fvm経由でコマンドを実行します。
(中略)
✦ freezedファイルが生成されたので、次にUI部分を作成します。
lib/screen/ディレクトリにtext_edit_page.dartを作成します。
(中略)
✦ 最後に、main.dartにこのページへの遷移を追加します。
既存のホームページにボタンを追加して、TextEditPageに遷移できるようにします。まずmain.dartの現在の内容を確認します。
(中略)
✦ TopPageにボタンを追加して、TextEditPageに遷移するようにします。
lib/screen/10_top/top_page.dartを読み込みます。
(中略)
✦ top_page.dartにTextEditPageへの遷移ボタンを追加します。⏺ Write(lib/screen/text_edit_page.dart)
⎿ Wrote 148 lines to lib/screen/text_edit_page.dart
import 'dart:math';
import 'package:flutter/material.dart';
import 'package:flutter/services.dart';
import 'package:flutter_easyloading/flutter_easyloading.dart';
import 'package:flutter_hooks/flutter_hooks.dart';
import 'package:freezed_annotation/freezed_annotation.dart';
import 'package:hooks_riverpod/hooks_riverpod.dart';
part 'text_edit_page.freezed.dart';
… +138 lines (ctrl+r to expand)
⏺ Bash(dart run build_runner build)
⎿ Error: (eval):1: command not found: dart
⏺ Bash(flutter packages pub run build_runner build)
⎿ Error: (eval):1: command not found: flutter
⏺ Update Todos
⎿ ☒ 既存のページのスタイルとRiverpod+Hooks+Freezedの使い方を調査
☒ text_edit_page.dartの基本構造を作成
☒ テキスト入力フィールドとボタンを実装
☒ リッチテキスト表示機能を実装
☒ ランダムスタイル変更機能を実装
☒ タップでコピー機能を実装
☒ トースト表示機能を実装
> fvm使ってね
⏺ Bash(fvm dart run build_runner build)
⎿ [INFO] Generating build script...
[INFO] Generating build script completed, took 182ms
… +16 lines (ctrl+r to expand)どちらも build_runner の実行時に一度つまづいていることがわかります。
build_runnerの実行に失敗し、自力でfvmを使用していることに気づき修正しているところは素晴らしいですね。
プロンプトからタスク化したとき同様、ひとつひとつの手順が具体的に書かれているので、ユーザーにとってはわかりやすいですね。
build_runnerの実行に失敗していますが、fvm使ってね という処理中の指示をきちんと受け取って改善できているところはさすがです。
はじめに立てたタスクに対応して処理が完了したものにチェックが付いているので見やすいですね。
プロンプト実行終了時
どちらも処理した内容を要約してくれています。
✦ これで、TextEditPageの作成と、そのページへの遷移が実装できました。
要約すると、以下のファイルを作成・変更しました。
* lib/provider/text_edit_state_notifier.dart: テキストとスタイルを管理するStateNotifierを作成しました。
* lib/provider/text_edit_provider.dart: StateNotifierProviderを定義しました。
* lib/screen/text_edit_page.dart: テキストの入力、表示、スタイル変更、コピー機能を持つUIを作成しました。
* lib/screen/10_top/top_page.dart: TextEditPageへの遷移ボタンを追加しました。
以上で実装は完了です。⏺ text_edit_page.dart が作成されました。
以下の機能を実装しました:
1. テキスト入力フィールド - TextFieldでユーザーがテキストを入力できます
2. リッチテキスト表示ボタン - 入力したテキストをリッチなスタイルで表示
3. ランダムスタイル - ボタンを押すたびに色、フォントサイズ、太さ、斜体、下線がランダムに変更
4. タップでコピー - リッチテキストをタップするとクリップボードにコピー
5. トースト表示 - コピー時にflutter_easyloadingでトースト表示
Riverpod + Hooks + Freezed の構成で、既存のコードスタイルに合わせて実装しています。完了時のメッセージについては、特に大きな差や特徴は見受けられませんでした。
違いで言えば、Gemini CLIの方は、作成したファイル単位でのまとめ方、Claude Codeの方は、最初に立てたタスクに合わせたまとめ方というところでしょうか。
完成した画面の実行結果


パッと見はどちらも近いUIで、それぞれ要件を満たしてくれそうな素材は揃っています。
リッチテキストが想定以上に動きがあり、思った以上にリッチだったことに驚きます。
またこの画面へ続く導線を用意してくれるところも、やや強引ではあるもののアドリブが効いています。
ただ残念ながら、ボタンを押すたびにランダムにリッチテキストを変更することや、クリップボードへのコピー、トースト表示は確認できなかったため、要件を十分に満たすことができませんでした。
ほぼほぼ想定どおりの結果を出してくれました。
要件もすべてきちんと満たしており、テキストエディタの有無によってボタンの活性状態も変えるあたりはさすがというところです。
ただしソースコードレベルで見ると、Gemini CLIではきちんと、pageとproviderとstate_notifierのファイルが分かれていたのに対し、Claude Codeではそれらが一つのファイルにまとめられていたため、他の例からファイル構成をもう少し参考にして分けてくれると最高でした。
まとめ
今回のサンプルでは、要件をきちんと満たした Claude Code に軍配が上がりました。
もちろんGemini CLIは無料、Claude Codeは有料という違いがありますし、単純に比較できるものではありませんが、現時点でのそれぞれの条件においては、Claude Codeの方がよりイメージしたものを作成してくれました。
とは言え、Gemini CLIにおいては、初期の画面作成の叩き台としては十分ですし、Claude Codeでは実現されなかった、fvmでの再実行や、リッチテキストのリッチ具合、画面への導線作成といったアドリブも効いていたところは見逃せません。
また、どちらも既に使用しているパッケージを活用することも含めて計画を立てているところは、開発者としてもありがたいところです。
今回のサンプルでは確認できませんでしたが、まだ導入していないパッケージの提案などもできるのであればかなり有能ですね。
コードを生成するのにかかった時間については、きちんと計測したわけではありませんが、感覚値として Claude Code の方が速かった印象です。
Gemini CLIの方は、正直 Claude Code の登場で急いでリリースされた印象ですので、今後きちんと確立された状態でのリリース、成長が期待できるのではないかと感じました。
また、AIの特性上、世の中にコード事例が蓄積されればされるほど有効だと思いますが、Flutterの開発元のGoogleであるということから、Flutterの新機能など世の中に実績が少ない状態でもコード生成ができる強みが出てくれると嬉しいところです。
実際に生成されたコードは次のページに掲載しています。







