RooCodeによる開発の夢と実践の現実

2025/03/18(火)
【増枠】新時代、来たる。AI Code Agentとの協働
https://rosca.connpass.com/event/346619/

Transcript

1. RooCodeによる開発の夢と実践の現実 @こたうちさんさん
2. 自己紹介 • こたうち さんさん • @kotauchisunsun • こたうち企画　主催 • 本職：サーバーサイドエンジニア • ARグラスが好き
3. RooCodeの話
4. RooCodeとはなにか Cline Meet Cline, an AI assistant that can use your CLI aNd Editor. VSCodeのプラグインとして動くAIエージェント fork RooCode(旧:RooCline) Roo Code is an AI-powered autonomous coding agent that lives in your editor. 基本的にClineが拡張されたAIエージェント
5. RooCodeでできること • 自然言語で指示 • ワークスペースでのファイルの読み書き • ターミナルでのコマンド実行 • ブラウザの操作自動化 • 任意のOpenAI互換またはカスタムAPI/モデルと統合 • カスタムモードを通して、「個性」と能力を適応させる ※公式の文章の翻訳
6. 個人的なRooCodeオススメポイント • 日本語で指示できる • NotつよつよPCでも無料で利用できる • 無料でも使いやすいようにチューニングされている
7. 日本語で指示できる 英語が出来なくても大丈夫！！
8. NotつよつよPCでも無料で利用できる • Google Geminiには無料枠がある • RooCodeはGoogle Geminiが利用可能 ◦ https://aistudio.google.com/app/apikey 強いGPUがなくても無料で利用可能！！
9. NotつよつよPCでも無料で利用できる　～その2～ • 2024年7月にVSCodeにLanguage Model APIが追加 • Github Copilotの無料枠が公開(2024年12月) • Github Copilotの無料枠でも利用可能(未検証) Copilot無料枠でも使える(カモ)
10. 無料でも使いやすいようにチューニングされている • 無料で使えるAPIは上限が厳しい →APIリクエスト失敗時に自動でリトライするオプションがある 無料でAPIの上限が厳しくて失敗しても煩わしくなく使い続けられる！
11. RooCodeを用いたサンプルプロジェクトの話
12. npmライブラリのリリース情報を収集するプログラム $ bun run npm_analyze --start-date=20240101 --end-date=20240131 sample/package.json > package_name,package_version,release_date > gatsby,5.14.1,2024-12-21 > gatsby,5.11.1-canary-less-lmdb.0,2024-12-21 > cacheable-request,13.0.3,2024-12-27 > keyv,5.2.2,2024-12-12 > keyv,5.2.3,2024-12-22 …. プロジェクトのpackage.jsonを読み込むと、 指定した期間のライブラリのリリース情報が取得できる。 実装はTypescript、実行はbun
13. なぜそんなものを作ろうと思ったか • 多くの人間が作れるものは価格が下がる ◦ AIコーディングによって TODOアプリやテトリスなんかは誰でも作れるようになった。 • 商業的なプログラマーはAIでのコーディングが難しい(＝供給量の増えない)コード を書く必要が出てくる。 • 人間は書けそうだが AIが書けなさそう と私が判断したソフトをどれだけ書けるか？ • AIが書けた場合→私の認識を更新する必要有り • AIが書けなかった場合→私の認識通り • 実験的な試み 数量 価格 需要 供給 均衡価格 価格の下落を生む 供給が 増加する
14. ライブラリのリリース情報に関する下調べ npmの情報を取得できれば 論理的には作成できそう。 人間の目線では作れそう。
15. 初期のプロンプト このソフトウェアは、「npmで利用されているパッケージの情報を解析する」プログラムです。 実行ファイル名をnpm_analyzeとしたとき、 ``` $ bun run npm_analyze sample/package-lock.json 3m ``` のように実行すると、package-lock.jsonを解析し、npmで利用されているパッケージの情報を出力します。 直接利用しているパッケージのみならず、依存関係にあるパッケージも出力対象とします。 2つ目の引数である3mは、この場合は3ヵ月を表します。その他、1y（1年）、1w（1週間）などが指定できます。 出力結果は、以下のようになります。 ``` package_name, package_version, release_date xxxx, 1.0.0, 2018-01-01 ... ```
16. うまくいかなかった初期プロンプト package-lock.json 800KB Provider Model Context Window OpenAI o1 200k OpenAI o3-mini 200k Google Gemini 2.0 Flash 1m Google Gemini 1.5 Pro 2m DeepSeek R1 128k トークン数≒英単語数の3/4 LLMには扱える文字数(トークン数)に上限があり、それ以上は解析できない。 package-lock.jsonがcontext windowを超え、解析できずclineが止まる。 package.jsonを用いて解析するように仕様変更
17. うまくいかないリリース履歴取得 pacote npm-registry-fetch リリース履歴が取得できない ライブラリの変更 リリース履歴が取得できない RooCodeが動作停止 ライブラリ ライブラリ
18. 人間による問題の切り分け npmのREST APIで リリース履歴を 取得できるか？ ライブラリで実装可能 ライブラリの使い方のミスの可能性 npmのサイトを 気合でスクレイピング？ Yes No
19. リリース履歴取得APIの調査 リリース情報あり リリース情報なし バージョン情報を指定しない場合、リリース情報が取得できる。
20. リリース情報の履歴の取得方法の改善 const response = await fetch.json(`/{packageName}/${version}`); const response = await fetch.json(`/{packageName}`); 書き換え リリース情報の履歴が取得できるようになった。 RooCodeが出力したコード
21. なぜRooCodeはコードが書けなかったか？ それほど人気がある訳ではない。 Google検索でもほとんど情報が出てこない。 学習となるサンプルコードがないから書けない？
22. なぜRooCodeはコードが書けなかったか？ レスポンスの命名規則が変だから？ - releases - history - release_history - versions timeというJSONのプロパティからリリース情報であるこ とを類推できなかった？
23. なぜRooCodeはコードが書けなかったか？ コンテキストに引きずられた？ パッケージのバージョン情報を取得するという文脈から、パッケージとバージョン情報は 必ず対となって扱う必要があると判断した？ const response = await fetch.json(`/{packageName}/${version}`); RooCodeが出力したコード
24. なぜRooCodeはコードが書けなかったか？ /** * Performs a request to a given registry URL, parses the body of the * response as JSON, and returns it as its final value. This is a utility * shorthand for `fetch(url).then(res => res.json())`. */ function json(url: string, opts?: Options): Promise<Record<string, unknown>>; jsに型定義を追加してTypescriptから利用できるようしたタイプのライブラリ const response = await fetch.json(`/{packageName}/${version}`); const response = await fetch.json(`/{packageName}`); 呼び出し方の違いで返り値が変わることを認識できなかった？ 型定義が雑
25. RooCodeがコードを書けるようにするには • 人気のある(≒サンプルコードの多い)ライブラリを利用する ◦ マイナーなライブラリは情報が少なく適切にコードが書けない場合がある • 適切な命名をする ◦ 人間が見てわかりにくい命名は LLMも分からない • 適切な型定義(≒ドキュメンテーション)を行う ◦ 返り値がany型など内容が分からないような設計は避ける。 ◦ Map,Record,Objectなど汎用的な型は避ける。 ◦ 型定義をサボらない。 人間が見て分かりにくいものはLLMも分からない。(現在の所感)
26. 追加の実装のプロンプト npm_analyzeコマンドの使用方法を変更したいです。 具体的には2パターンの利用法が出来るように変更したいです。 パターン1 ``` $ bun run npm_analyze --range=3m sample/package.json ``` パターン2 ``` $ bun run npm_analyze --start-date=20240101 --end-date=20240131 sample/package.json ``` パターン1の場合は、--rangeオプションを指定し、3mのように期間を指定します。これは、現在時刻から 3ヵ月の間を指示しています。 パターン2の場合は、--start-dateオプションと--end-dateオプションを指定し、調査する期間の開始日と終了日を指定します。 最後のpackage.jsonの引数は必須として、ない場合はエラーとしてください。 また、--start-dateと--end-dateは必ず2つで指定されるものとし、指定されていない場合はエラーとしてください。 --rangeが指定されている場合は、--start-dateと--end-dateは指定されていないものとしてください。 またオプションが指定されていない場合は、 --range=1mと同等としてください。
27. うまく書けないRooCode 仕様 コード 仕様 仕様 仕様 コード 単純な仕様はそのまま書ける 複雑な仕様は書けなくなる
28. なぜRooCodeは複雑な仕様のコードを書けないか コード index.ts 追加 仕様 index.ts コード コード 1つのソースコードで完結させる癖がある。 適切な関数分割やモジュール分割を行わない。 ソースコードの複雑さを制御できなくなり、既存部分がバグり始める。(人間と同じ)
29. RooCodeで複雑なコードを書く方法 index.ts コード 〇〇の部分を(関数|モジュール|ファイル)として分割しなさい。 そして、自動テストを書きなさい。 書いた後、自動テストを実行しなさい。 aaa.ts bbb.ts ccc.ts aaa_test.ts bbb_test.ts ccc_test.ts コードが複雑化する前にモジュール化を行う
30. RooCodeでモジュール分割を行うメリット コード 1ファイルのコードの行数が多い場合： • LLMへのファイル読み込みに時間がかかる • LLMのコードの出力に時間がかかる。 • LLMの速度がボトルネックで開発が遅くなる。 • 行数が多いと、実装がバグりやすくなる。 　　開発が遅いのにバグりやすい二重苦 1ファイルのコードの行数が少ない場合： • LLMへのファイル読み込みが短い。 • LLMのコードの出力時間が短い。 • 行数が少ないと実装がバグりにくい。 コード コード コード コードを分割し、ファイルサイズを小さくすることで 高速な開発を継続できる。
31. 実際に書いているコードのクラス図 割と複雑なものでも実装できる。
32. 機能開発の頭痛の種 既存 コード 新規 コード 既存 コード 新規 コード デグレ 新規機能を追加することで既存の機能がバグることがある。
33. RooCodeで自動テストをする 〇〇という機能を実装し、自動テストを書きなさい。 書いた後、自動テストを実行しなさい。 既存 コード 新規 コード 既存 コード 新規 コード デグレ テスト テスト テスト テスト ①新規機能とテストを実装 ②自動テストでデグレを検知 既存 コード 新規 コード テスト テスト ③テストのエラー内容から実装を修正 既存 コード テスト 新規 コード テスト ④自動テストを実施 デグレ検知から実装修正まで自動化できる(限界はある) ⑤テストが通るまで 　繰り返す。
34. RooCodeを実用するには？ • 人気のある(≒サンプルコードの多い)ライブラリを利用する ◦ マイナーなライブラリは情報が少なく適切にコードが書けない場合がある • 適切な命名をする ◦ 人間が見てわかりにくい命名は LLMも分からない • 適切な型定義(≒ドキュメンテーション)を行う ◦ 返り値がany型など内容が分からないような設計は避ける。 ◦ Map,Record,Objectなど汎用的な型は避ける。 ◦ 型定義をサボらない。 • マメにモジュール分割を指示する。 ◦ LLMへのファイル読み込み /出力時間を最小化することで開発速度が保てる。 • 自動テストの実装と実行を指示する。 ◦ 既存部分のデグレを検知し、修正まで自動化することができる。