🚀

AI Agent 開発 (Cline) で TODO アプリを作ってみたログ

2025/03/07に公開

そろそろイノベーター・アーリーアダプターの方々のナレッジが放流されてきた気がするので、セカンドペンギンを狙っていく

Goal

キャッチアップ

Cline is 何

Roo Cline などの亜種もあるが、初心者はまず Cline かな

Cline はどういう仕組みなのか

.clinerules, .clineignore, Memory Bank 辺りが重要そう

Cline の基本的な使い方

基本的に依頼して Cline のやりたいことを許可 (Approve) していくだけ

どこの API 使うか

Anthropic Claude 一択かな

OpenRouter

  • サクッと一瞬でアカウント & token 作れた
    • クレカ入力も不要
    • とりあえず Credit limit に $10 制限入れておく

Cline 実行!(失敗)

  • 当然コケる。金払えと。それはそう。
  • OpenRouter へ Google Pay でとりあえず $20 突っ込む
    • 請求書の発行には約 $0.1 (¥15) 掛かるっぽい
      • Stripe 決済だった
      • 初回だし invoice 買ってみたが、請求書 (invoice) は有料で、領収書 (receipt) は無料だったのかも
    • Crypto 支払いもできるらしい
      • 日本政府に半額税金でぶん盗られるくらいならここに突っ込んだ方が遥かにいいかも

今度こそ Cline 実行!成功!

  • 動いた!
  • とりあえず Auto approve なしで動かしてみる
  • README.md を読む前に確認される。Approve!
  • Run command にも Approve!
    • が、asdf で最新 nodejs 入ってなくてコケる
    • initialized じゃないんだけど、terminal の結果をうまく読めてないのか?
    • そこまで zsh カスタマイズしてないと思うが
    • とりあえず手動で touch .tool-versions して、pnpm create ... を command history から自分で実行する
  • pnpm install も Approve
    • ここで一旦 git commit したくなるが、それは何も言われないのな
      • クセで git commit してしまった
      • 実験なのだし、この後はなるべく Cline のやりたいようにやらせてみる
  • 🤖「コードを再帰的に読みたい」
  • 🤖「〜を読むよ」
    • 早くも 1 file 読むたび Approve するのがダルくなってきたので、 Read files and directories だけ Auto-approve してみる
      • これ自動で読んでいい file/dir とそうでない file/dir もの分けられたらいいのに・・・ってそれが .clineignore か?
    • 全部読むのかと思ったら、以下の重要そうなファイルだけ読んで、次の行動を提示してきた。ファイル名だけで優先順位判断できるのすごい
      • package.json
      • src/App.css
      • src/App.tsx
      • src/index.css
      • src/main.tsx
      • vite.config.ts
  • 🤖 「vitest 入れるよ」
    • Edit の Approve も面倒になってきたので、Edit も Auto-approve にする
    • Auto-approve の魔力ヤバいな
  • 🤖 「vite.config.ts 書いてみたけどエラーになってるから直すよ」
    • ちゃんと TS error 読んで直してくれる
    • そうセットアップすることないコードで、こういうエラーを公式も見ずに直せるのマジですごい
  • 🤖 「Todo object の型定義するよ」
    • 残念ながら interface で書いてきたので指導する
      • Use Type Aliases (`type`) instead of Interfaces (`interface`)
    • Auto-approve 中に途中でツッコミ入れたくなった場合はどうすべきなんだろう?
    • ペアプロ的に Auto-approve 止めて都度コメント入れるのがいいのかな
    • PR review 相当の時点まで待つと手戻り大きいしな
  • 🤖 「let's create, let's update, let's create, let's update ...」
    • ゴリゴリ書いてくれる!すっごい!(語彙力)
    • この感動、やっぱ百聞は一見にしかずだ
  • 🙎‍♂️「uuid じゃなくて uuidv7 使って」🤖「りょ」
    • 途中で横槍入れてもちゃんと対応してから元の作業に戻ってくれる
    • uuid の uninstall までやってくれたら完璧だったけど、まぁ新人相当と考えると優秀
  • 🤖「起動してテストするよ」
    • E2E 相当のことやってくれると知ってはいたが、実際見ると戦慄する
  • 🤖「TODO item 追加できんかったから pnpm test 確認するよ」
    • 実際ブラウザで見ると動いてるけどね。すっごい左寄りだけど
  • 🤖「test もコードも問題ないからもう一回試すよ」
    • ブラウザ操作は 3 回に 1 回くらいしか成功しなかった
    • どうも input 欄を見つけられず、「キー入力して Add ボタン押してみたけど TODO item 追加できないバグがある・・・」とループしてしまった
    • まだかわいいところあるな
  • 🤖「TODO の追加に問題あるけど、要求された技術スタックで実装できたよ」
    • そのまま trial and error のループに入るかと思ったら、途中でトライを打ち切って、できたこと・できなかったこと報告してきた
    • 期限いっぱいまでトライして「何の成果も!!得られませんでした!!」ってなる人多い中、これはかなり優秀だろう
    • そして See new changes で成果物をざっと見られる
    • 最後は Copilot 君に commit message 書いてもらって git commit しておわり
  • おわり
    • ちゃんと「終わりだよ」と言うまでは終わらないのかも
    • まぁ評価する前に勝手に終わりにされても困るしな

コスト

  • ここまでのトータルコストは約 $1.9 (¥281)!
  • 意外とコードを書くのは安い
    • この程度の規模だと 1 file $0.001 (¥0.1) くらいで書いてくれる
  • create より edit の方が高い
    • create: $0.01 (¥1.5) くらい
    • edit: $0.02 (¥3) くらい
    • edit は読み + 書きになるから、よりコストが掛かるのだろう
  • ブラウザの操作は意外と安い
    • 1 回 $0.015 (¥2) 前後
    • てっきりスクショ見てるのかと思っていて、それならもっと高い気がしてたけど、どうブラウザを見てるんだろう?
  • 一番高くついたのは、Reject
    • $0.2 (¥30) 掛かった
    • ユーザーがなぜ Reject したかを推測するために、いろいろ読んだり考えてるせいだろうか
    • Reject するなら、ただ Reject するのではなく、ちゃんと理由を伝えて「こうして」と頼む方がよさそう

感想

  • クオリティ
    • TODO アプリレベルなら、ちゃんと「そうなるよね」という想像通りのものができあがる
      • タイピングや音声入力を超えたスピードで入力できてる感覚で非常に爽快
        • 「趣味プログラミングだからつまらなくなる」という意見もあるが、そうはならないんじゃないか
    • コーディング規約ちゃんと書くとクオリティ上がりそう
      • linter, formatter は当然整備するとして、それで制御できない部分はコーディング規約なり ADR なりで言語化してるとよさそう
        • ・・・ってまさにソフトウェア開発の基本
      • それが .clinerules, Memory Bank 辺りになるのかな
  • コスト 💸
    • ケチなのでやはり 1 操作ごとに金が飛んでくのは気になるが、駄菓子程度の値段で TODO アプリを作れたのはすごい
  • 時間 ⏱️
    • この記事書きながら 2h くらいでできた
    • コード書くだけなら 10 分かかってないはず
      • 実際 Cline が書いてる時間は数分、それを確認する時間の方が長かった
      • 既に人間がボトルネック
    • 適度なタイミングで git commit 入れたくなった
      • そうしないと、AI が何を変更したかわからなくなりそう
        • 各 Task に Checkpoint というのがあるので、そこの Compare でも見れるが
      • ただ現実は「TODO アプリ作って」のような単純な命令で全部できあがりなんてことはないので、頼んだタスク単位で See new changes になったら git commit するくらいでもいいのかも
      • つまりは細かくタスク切って分割統治するのがいいのか?
        • これもソフトウェア開発の基本か

n番煎じだが、AI Agent でも変わらず「超優秀な新人に仕事を依頼する」イメージで扱うのがよさそう
そういう意味では、今まで良質なコードを書くために努力し続けてる人たちは(今はまだ)報われそうだ

個人的に思う、AI に最適なコード・開発とは

  • 明示的であること
    • 当然だが書いてなきゃ AI には伝わらない
    • ハルシネーションという忖度の余地が大きいほど精度は下がる
  • 仕様は Markdown で同じリポジトリに書かれていること
    • AI が最も読みやすいのは構造化された Plain text、つまり Markdown text である
      • 今度こそ Excel や PDF で仕様書書いてるところは終わりと言っていいだろう
    • そしてそれがなるべくコードの近くにあること
      • いずれ別所のドキュメントの参照もできるだろうが、今の Cline の仕組みでは同じリポジトリ内 (というか VSCode が読める範囲内) のドキュメントしか参照できないはず
  • ”良質な” 事例が多いこと
  • 1 file が小さいこと
    • 今の Cline はファイル単位で読んでいくようなので、God class のようなクソデカファイルがあると read のコストが嵩む
    • 余計な情報を読ませることで精度も落ちるかもしれない

使い道

  • PoC
    • Framework の使い方とか、新しいライブラリの実例とか、一定規模のコードを書いた時にどうなるかを見たい時
    • 技術選定の比較に非常に便利なはず
  • 機能単位での開発
    • 大規模・大局的なタスクは、それを命令する人間側も言語化に無理があるので、適切にブレークダウンした機能単位での開発がいいのではないだろうか

Next actions

  • .clinerules, Memory Bank によるチューニング
  • リファクタ
    • 生 css を shadcn/ui (Tailwind CSS) へ
  • 複雑性を上げてみる
    • フィルター
    • 期限の日時入力
    • 進捗グラフ
  • lint でガチガチに縛った時に、error を適切に直せるか
  • Backend project
  • 実プロジェクトへの投入

Discussion