Claude Opus 4.5を利用したVibe CodingでGitクライアント作成
業務でClaude Opus 4.5を利用していて今までのモデルとは頭一つ抜けた性能があると感じていました。
RustでGitクライアントを作ったら早くて快適なんじゃないかなぁと思っていたので試しにClaude Opus 4.5を利用したVibe Codingで作ってみることにしました。
その時のプロンプトのコツなど整理したので共有します。
成果物
| 初回の指示 | → | 最終的なUI |
![]() |
![]() |
初回は以下のような指示を出しました。1回目から動くアプリケーションが出来上がり、そこから細かく指示を重ねていくスタイルで修正を続けました。
GUI ベースの Git クライアントを作成したいです。
対象は以下のような特徴を持つアプリケーションです。
- ローカルおよびリモートのブランチ状態を可視化できる
- コミット履歴をグラフ構造として表示できる
- 右クリックやインライン操作による Git 操作を提供する
- 初心者でも操作可能な GUI を前提とする
RustでSlintを利用してください。 できる限り自立的に作業して、AIが判断して決定したことについては作業完了時に共有してください。
環境
- 作業期間:2025/11/29-2025/12/16
- モデル:Claude Opus 4.5, Gemini 3 Pro
- ツール:Antigravity, Kiro
AIが得意なこと
Claude Opus 4.5では自然言語でほとんどの実装を行うことができた。
AIが苦手なこと
GitGraphの描画のような見た目だけ見せてもロジックの判断が難しいものについては、バイブスだけでは適切なロジックでコードを書くことはできていなかった。
- このようなケースでは仕様駆動で作った方が良さそう
- あとちょっとでそれっぽく動きそう(でもロジックがめちゃくちゃ)なケースはAIがちょっと触るだけで壊れることがあり、適切なロジックを人間が調べてそのロジックで書き直すように指示するのも有用だった
また、最新バージョンの確認はAIに任せるのは良くない。cargo update --dry-runなど最新バージョンを確認するためのコマンドを実行させて、その結果から判断させるようにした方が良い。
モデルの使い分け
ほとんどのケースでClaude Opus 4.5は有用ですが、以下2点はGemini 3 Proの方が有用でした。
UIデザイン
今回は最後にUIに関してGemini 3 Proに「リニューアルレベルで見直しを行って」と指示をしたところ、個人的にはかなり見た目が良くなったと感じました。
スクリーンショットの理解
Claude Opus 4.5はスクリーンショットを渡しても正しく理解できず、コードを見に行くような挙動が見受けられました。
そこで以下のような使い分けが有効でした:
- スクリーンショットからどういう修正をすべきかGemini 3 Proに検討させる
- 修正の方針としてはClaude Opus 4.5の方が良いケースが多いため、Claude Opus 4.5にGemini 3 Proの方針レビュー〜実装までおまかせする
指示(プロンプト)の型と粒度
1. AIに選択肢を提示させる
AIに複数の案を出させて、その中から人間が選ぶ方式は効果的だった。以下のようなケースで有効:
- 機能追加時:どのような機能を実装すべきか提案させる
- バグ修正時:なかなか解消しない問題に対して、複数の修正方法を提示させる
例(機能追加):
Localエリアで右クリックメニューからいくつかの操作をできるようにしたいと考えています。
Localで利用しているブランチとそれ以外のブランチで右クリックをしたときで利用できると便利な機能を提案してください。
2. AIに見積もりをさせる
選択肢のボリュームを把握した上で判断できて良かった。
例:
案1: ホバー時にボタン表示(VSCode風)と案3: Hunk全体を選択可能なブロック表示と案4: インラインアクション(GitHub Desktop風)について、Claude Opus 4.5に実装を頼んだとしてどの程度のトークン数となるか目安を教えてください。
3. 人間の仮説を伝える
AIだけで原因がわからないケースがあり、「人間はこの辺が怪しいと思っている」という情報を伝えるのは有効だった。restoreしたときのAIの回答が変わり、適切な修正ができていた。
4. 問題の種類を明確に伝える
以下のような画像を渡して「これらの表示のされ方は問題があると思います。Gemini 3 Proはどう考えますか」と指示しても、的外れな修正計画を立てていた。(ボタンが枠をはみ出している問題ではなく、レイアウトのスタイルを見直そうとしていた)
AI(Gemini 3 Pro)は「見た目を良くすべき」と「見た目のバグを修正すべき」の判断が難しいようで、はっきりと「バグです」と伝えることが有効だった。

5. AIが困っていることを察知する
AIは人間のように「詰まって困っている」ことを自ら伝えてこない。そのため、こちらから別のやり方のアイデアを出すなどの工夫が必要。
「想定外の問題が発生したら処理を中断して状況を説明してください」のような指示は有効なことがあった。
6. 仕様駆動の有効性(未検証)
Claude Opus 4.5は自立的に作業できる範囲がかなり増えている。
過去のモデルだと仕様駆動で作業を進めようと考えても、AIが立てた仕様をAI自身が実装できないケースがあった。しかし今回の実装力を見る限り、Claude Opus 4.5ではそのような問題が解消されている可能性が高い。
Claude Opus 4.5においては仕様駆動でアプリケーション全体の仕様を先に決めて実装することも可能と思われるので、仕様駆動が今までよりも有効に作用する可能性が高い。
人間が介入すべき判断基準
プロンプト改善のタイミング
2回の指示でうまく行かないときは、プロンプト自体を工夫しないと無限に問題が解消できない印象。
例:
〇〇してください。
↓
正しく修正できていませんでした。修正してください
↓
(これでうまく行っていないならプロンプト自体の修正が必要)
人間が直接作業した方が効率的なケース
ボタンの幅の調整の指示を多用したので、人間にそのあたりの調整スキルがあればもっと効率的に作業できたと思う。AIができないわけではないが、指示して修正してもらうより速度という面で人間の方が有利だと感じた。
チェックポイント/リストア戦略
AIに指示して主たる対応ができていない場合はrestoreして指示を書き換える。
- 100点になるまで繰り返す感じではなく、主たる対応はできていて細かいバグがあるみたいなときは継続する方が良さそう
- Antigravityはリストアのやり方がよくわからなかったので誰か教えてほしいです(Vibe Codingの1スレッドの途中の状態に戻したいのに最初に戻ってしまって、Antigravityではリストア戦略をうまく取れませんでした)
※12/26追記:Editerモードの右側に出ているAgentエリアからはGithub Copilotなどと同じように直感的な操作でリストア可能でした。
人間側に必要な前提スキル・知識
作りたいものの仕様を説明するスキルが必要。
今回はライブラリの使い方やGitの仕様を人間側が把握していないことで、以下のようなバグが動作確認するまでわからなかった。


Discussion