コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ / Two Month Agent Struggle

https://connpass.com/event/353478/
登壇資料です。

- エディタ間借り型コーディングエージェントの仕組みと限界
- 負けパターン集と、その回避対策
- コーディングエージェントのこれから

Transcript

1. コーディングエージェントを作ってるけどうまくいか なかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った 話～ @erukiti 2025/05/20 コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 1
2. 自己紹介と本日のテーマ erukiti アイコンが変わりました（生首から、全身に進化。服を着ました） 株式会社AlgomaticのAIエンジニア（似非フルスタック、インフラだけめちゃくちゃ苦手） 2023年からLLMプロダクト専業で、チャット型作ったり、RAG作ったり、AIエージェント作ったりして います 完全に趣味でコーディングエージェントを2025年3月中旬から作ってます そのタイミングから仕事でも、人力コーディングをほぼ封印してたけど、最近限界を感じて方針転換し た（Sonnetと喧嘩しすぎて、あかんってなった） 本日のテーマ: エディタ間借り型コーディングエージェントの仕組みと限界 負けパターン集と、その回避対策 コーディングエージェントのこれから コーディングエージェントに関する生々しい何かを持ち帰っていただければ幸いです コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 2
3. 作っているコーディングエージェントの状態 基本的にはRoo Codeにコードを書かせていて、人力コーディングをしてない それっぽいパーツは一通り実装されている ウェブGUI + 汎用型コア いろいろな問題があって、ちゃんとした形では動いてない 問題を解決するにはcontextが大きくなりすぎている コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 3
4. おことわり 本日の発表は、あくまで現時点での個人の経験と考察に基づくものです。 開発中のものが未完成であるため、具体的な「完成品」のデモはありません。 「コーディングエージェント作ってみた」なんてテーマに集まる人に基本的な説明は不要なはず！！いろいろ な前提知識をすっ飛ばしていきます！！！ 先日でたオライリーの「LLMのプロンプトエンジニアリング」当然読んでますよね！！！ コーディングエージェントを作るなら、必読の教科書です。みなさん、5回は読み返してください。 「赤ずきん原則」とか出てきますよ！！（LLMの学習データに頻出するものにそろえましょうという原則） 「チェーホフの銃」とか出てきますよ！！（不要な情報をcontextに入れるとLLMが混乱する） 「真実バイアス」とか出てきますよ！！（contextに与えた情報を正と強く思い込む） 今日の話は、LLMにおける現行世代〜二世代くらい先（年末くらい）までのレンジの話になると思います。 来年以後の最適解は少し変わってるはず。 コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 4
5. アジェンダ 1. コーディングエージェントの概要 2. エディタ間借り型コーディングエージェントの仕組みと限界 3. 負けパターン集 〜僕のコーディングエージェント開発が停滞した理由〜 4. どうやって負けパターンを回避するか 5. まとめ コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 5
6. I. コーディングエージェント コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 6
7. AIエージェント流行ってますね！ AIエージェントとは？ 去年あたりから盛り上がり始め、一般にも広く認知 LLMが複数回自律的に動き、必要な情報をそろえ、ユーザーから与えられたタスクのゴールに向か って動くもの なぜ今AIエージェント？ AIエージェントという考え自体は昔からあったが、技術的に実用的になったのが2024年以後 特に tool use(いわゆるfunction calling)や構造化出力機能の拡充 LLM自体の性能アップ OpenAIに至ってはもはや、AIエージェントで解決できることにしか興味なさそう 学習データ枯渇問題の解決 そもそもAGIをLLM単体で実現できるわけがないし、LLM単体でやるべきものでもない コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 7
8. AIエージェントの分類 バーティカルAIエージェント 専門分野に特化 ドメインエキスパートを模したものが多い ドメインエキスパートの日々の業務・思考回路の再現が鍵 泥臭くやっていくしかない 汎用AIエージェント AGI (汎用人工知能) を目指すもの。つまり任意のタスクの答えにたどり着く OpenAI oシリーズはreasoningを使って様々なタスクを解けるようにしている DeepResearch: oシリーズをベースに、ツール利用に関する強化学習で高性能なウェブ 検索とまとめを実現 o3+検索: ミニDeepResearchみたいなやつ コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 8
9. 理想と現実 理想論でいえばAGI以上に到達できればバーティカルなAIエージェントは不要なはず？？？ AGIへの到達は、楽観的な予測で2027年頃といわれている 仮にAGIができても決して安い値段でサービスされるわけがない 現在でもChatGPT ProやClaude Maxのような月額$200が当たり前、$2000のプランが検討されてるという話もあるし、さら に上の金額も当然あり得る 常識で考えて「あらゆる任意のタスクの答えにたどり着けて、全部のホワイトカラーの人間を不要にしかねない」技術を、安売 りするわけが無い。何のためにここまで巨額の開発費を投じて、ダンピングまがいのAPI安値戦争をやり続けてるのか？ そもそも技術的には可能だとしても、エージェントとして動作する限り、タスク完了までに必要な演算リソースが膨大なことに は変わりない いきなり「42」って答え出されても困るよね。地球潰してハイウェイ作っちゃう？ 課程が重要 現実的な値段で提供するには、汎用性を多少なりともomitしたバーティカルなAIエージェントが重要 あらゆる答えにたどり着ける汎用知性ですら、特定の業務で精度高く安定して動かすためのノウハウやプロンプトは必要な はず 仮に「人類がやること全部ローコストで置き換えられる未来」が来てしまったら、もはや我々がやれることはないので、酒でも 飲んでマリオカートワールドやろうぜ。フロムの新作でもいいよ コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 9
10. コーディングエージェント 汎用AIエージェントとバーティカルAIエージェントの中間 プログラミングという特定ドメインに特化。バーティカルな側面 システムプロンプトやユーザープロンプトに反映 それ以外の形でも、ソフトウェア開発者というドメイン知識がインジェクシ ョンされてる しかし、扱うタスクは多岐にわたり、ある程度の汎用性が必要 実際にブログや小説やを書くのにも使われたりしている 最近はやりのCursor in Obsidianとかも コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 10
11. コーディングエージェントの作り方 適切なcontextを作る ユーザーの意図を読み取る リポジトリの情報（ファイル一覧、ファイルの中身、grep結果など）を観測 terminalの実行して結果を観測 MCPとかあれこれ context組み立て -> LLM -> context組み立て -> LLM のループ （必要なら）ユーザーインターフェース （必要なら）checkpoint機能 （必要なら）コンテナを作成・制御 コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 11
12. コーディングエージェントのパターン 1. エディタ間借り型: GitHub Copilot Agent, Cursor agent, Cline, Roo Code, Windsurf 2. CLIツール: Claude Code, OpenAI Codex 3. コンテナ型: Devin, Cursor background agent, ChatGPT Codex, GitHub Copilot Coding Agent(NEW), Google Jules(NEW) ※ ChatGPT Codexは内部的にはOpenAI Codexを動かしてると思います コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 12
13. II. エディタ間借り型コーディングエージェントの仕組みと限界 コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 13
14. Cline/Rooの動作フロー 1. システムプロンプトを準備する（固定） 2. 一番最初のユーザープロンプトを組み立てる 3. LLMを呼び出す 4. 3の結果から、文字列処理でXMLを抜きだす（後処理） 5. 抜き出したXMLがツールのフォーマットに沿ってたら、それを使ってツールを実行、結果をuserプロン プトとしてcontextを組み立てて GOTO 3 6. 5で失敗したらツール利用を促すためにペナルティ文言を組み立ててuserプロンプトとしてcontextを組 み立てて GOTO 3 ※ 毎ターンcontextが積み上がるチャットUI方式（精度としては良くない） コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 14
15. 例: AIの発言 <thinking> `bun run test` の結果、テストが失敗しました。 主なエラーは `typecheck` と同様に、`Cannot find module './custom-actions.js'` です。 これは、テスト実行時にもインポートパスの解決がうまくいっていないことを示しています。 </thinking> まず、インポートパスを `paths` エイリアスを使って修正します。 <write_to_file> <path>hoge/fuga/gquuuuuux.ts</path> <content> import { setup } from 'xstate'; ... </content> <line_count>228</line_count> </write_to_file> コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 15
16. 例: userの皮を被ったエージェントによるツールの結果 [read_file for 'docs/coding-rule.md'] Result: <file><path>docs/coding-rule.md</path> <content lines="1-160"> 1 | # コーディングルール 2 | 3 | **IMPORTANTには最優先でしたがうこと。** 4 | [IMPORTANT]: **コーディング手順にある【それを実際に発言する】は、必ず【】で囲って発言すること** 5 | [IMPORTANT]: **自分が守るべきルールについて【それを実際に発言すること】** </content> </file> コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 16
17. Cline/Rooのコンテキストが複雑すぎる問題 AIから見たときのユーザーさんは「ツールの結果を延々貼り付けてくれる人」に見えている 実際のユーザーの発言は全部XMLで囲われているからか、ユーザー発言を「ユーザーさんは丸々と言ってるようです」みた いな他人事丸出しの会話をしてくることがある（イラット++） Cline/Rooの利用者は対話型AIを操作してるような気持ちだけど、実際のcontextとは食い違ってることがある（contextの積 み重なったSonnetがユーザーの最新の指示に従ってくれない問題） ツール利用にXML処理が必須 しかも、XML混じりのプレーンテキストという、普通は無い形式（赤ずきん原則違反） すなおにtool_use(いわゆるfunction calling)を使えばいいのでは？（赤ずきん原則違反） ファイル読み込みに行番号がついてる。これもLLMに負担がかかる（赤ずきん原則違反） コスパのいいモデルでまともに動かないのこれのせいでは？ ファイル更新は diff を作るモードがある。これもsonnet以外では苦手っぽい というかdiffを作るってことは、元ファイルを一言一句間違わずに認識してないと駄目 だからか、最近のRooではdiffはオプショナルになってる OpenAI canvasやGemini Canvasと比較すると、大体Claude Artifactsの方が成功率が高い（多分diff操作はClaudeの方が得意） o3だとノイズが多すぎてコーディングタスクは途中で壊れて継続不能になることもある LLMの知性に対する限界チャレンジやってない？ コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 17
18. エディタ間借り型エージェントのUIが劣化型チャットUI問題 LLMは非決定論的に振る舞うのとcontext汚染問題があるので、履歴改ざんが極めて重要なのにコーディ ングエージェントのGUIではやりにくい。 ChatGPTだとできることができない 改ざんのあるチャット履歴を元に戻してみたり 共有機能を使ってそこからやり直す Cline/Rooの作りの問題 履歴改ざんとcheckpoint機能が自動で同期されない 自分から発言をしない限り、そこに戻ってやり直せない（無駄に発言して改ざんポイントを作 るという謎テクニック） エディタ上にあるのに、エディタとは異なる独自UIであり極めて使いづらい フォーカス制御に問題挙動を抱えてたり、小さくてサイズ変更できない使いづらすぎる入力欄とか enterで暴発！！！！！！！！！！！！！ コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 18
19. エディタ間借り型は、エディタを占有されてしまう cursor/Cline/Rooなどは既存のエディタを操作する 途中で人間がエディタを操作すると、操作がかち合うことがある -> 人間がエディタをいじりたいなら、別エディタを起動する必要がある（VSCode + Cursor + VSCode Insider...） そのくせ、エディタの持つリファクタリング機能や、言語サーバー機能を活用できるわけでもない そもそもエディタの持つ機能を活用する優良な学習データがない（赤ずきん問題！！！！） GitHub Copilot(Chat/Agent)ですら、リファクタリング機能や言語サーバーを活用してない それほんとにエディタに間借りする必要あるの？ コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 19
20. III. コーディングエージェントでの負けパターン集 〜僕の開発してたコーディングエージェントが未完な理由〜 コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 20
21. 僕の開発してたコーディングエージェントが未完な理由 負けパターンを一通り踏み抜いた 初期の技術的負債 Cline(Roo Code)を暴走列車にしたら4日間で数ヶ月分のコードが生成できた 後期の技術的負債 GUIとコアをつなぎこむのはかなり大変だった 複雑なものを作ってしまってた チャットインターフェース型のウェブアプリを作ろうとしていた checkpoint機能とかも実装してたのだが... 今思えばコンテナ型に未来があった ここ二ヶ月趣味と業務で本気でRoo Codeと向き合い続けたけど、エディタ間借り型には一 定の限界があった コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 21
22. 負けパターンの分類 0. タスク設定の問題（これはわざわざ説明しない） 1. 情報の取り込みに失敗 contextの外にあるもの 2. 知識不足（ハルシネーションとか、そもそも学習してない） 広い意味でいえばこれもcontextの外にあるもの 3. contextが肥大化しすぎる 実質、これが問題の大半を占める 4. 不要な情報を取り込みすぎる 5. LLM自体の性能問題 3.8/4.0 Sonnet早く出てくれ頼む！！！ ※ 負けパターンに入ると、失敗率が極端に上がる。大体何をやってもだめになる コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 22
23. 情報の取り込みに失敗する Cline/Rooのterminal統合に問題がある terminalの実行結果を取り込めずにcontextが壊れる（ハルシネーションの原 因） 実行結果の行数が多いと、VSCodeのterminal自体の行数truncateの影響を受け てる？（こっちは確証なし） -> ちなみに terminal 統合を切った場合、プロセスを止めるボタンがなくて、 ゾンビプロセス問題 エディタのエラーや警告を、正しく拾えたり拾えなかったりする こっちはちゃんと調査してないけど、拾えてるときと、拾えてないときがあ る MCP導入によっていろいろ改善の余地がある コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 23
24. 真実バイアス（LLMのプロンプトエンジニアリング本にも書いてるよ！） 与えた情報を正だと強く思い込む 与えたデータの矛盾があっても都合良く解釈しやがる！！！！！ 「何も出力されてないから、正常な証！（バグって取得できないのに） 」 「エラーがあるけど、正常に動いているので問題ありません！（じつは正常に動いてない） 」 組み込みブラウザ（+画像入力）は結構失敗しやすい スクロールバーが表示されてるのに、スクロールできることを理解できなくて「画面に表示されていません。バグ です。対策コードを入れましょう！」 CSSが適用されていなくても、ソースコード的には一見正しいように見えるから、CSSが適用されてると思い込ん でしまう SonnetよりGemini 2.5 Proは大分マシなので、リポジトリの検査みたいなことをするときは絶対にGeminiにやらせた方 が精度が高いです Sonnet「特にこのリポジトリに問題はないです」Gemini「これとこれとこれとこれ（ｒｙ）はこういう問題があり ます！」 Sonnetの書いたクソコードが一切信用できん！！！ってLLM不信に陥った僕を慰めてくれたのはGeminiでし た！！！！！！ ※ ただし、Gemini 2.5 Proにも真実バイアスの問題はあります。仕組み上そういうもんです。マシなだけです。 コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 24
25. 知識不足 LLMのナレッジカットオフの時期問題 多くのLLMは2024年以前の知識がおぼつかない 古い知識でも正しいとは限らない Gemini 2.5 ProでRFC3000番台（要するにめっちゃ古いRFC）に対する厳密で精緻な理解はな いっぽい（ハルシネーション） 3.7-SonnetでXState v5 の情報が全然反映されてない（2023年に出てるはずなんだ が？？？？？？？） というかナレッジカットオフが最近のはずのLLMでも未だに「GPT-4が現役」 「Geminiは1.5し かない！」とか言い出す 仕組み的には全然あり得る つまり手厚くドキュメントを与えてあげる必要がある -> もしRFCを基に実装が必要なら、絶対にRFCを提示する必要がある。それをサボってサイ レントバグを仕込まれても一切文句は言えない。 「仕組み上そういうもの」 コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 25
26. contextが肥大化しすぎる1: Cline/Rooのシステムプロンプト ツール定義 巨大で複雑すぎる MCPの説明 use_mcp_tool というツールを使う MCPのサーバー・ツール定義・リソース定義などがある 使うには適切なXMLを組み立てて use_mcp_tool を呼び出す必要がある MCPを大量にインストールしまくってると、システムプロンプトがめちゃくちゃ肥大化する モード説明 使ってないモードがあっても、システムプロンプトにはモード説明文章が入る ほかにも「これいらんくね？」みたいなのが山盛り コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 26
27. contextが肥大化しすぎる2: 対象リポジトリの複雑性 複雑なリポジトリでは把握するための情報が増える 複雑なリポジトリではディレクトリ構造の読み込み回数とデータサイズが増える 複雑なリポジトリでは読み込むファイルが増える 複雑なリポジトリでは、度々忘れて再度読み込むことになる（ポンコツ） ポンコツのAIのために指示を追加して細かく指示を出してあげると、それによってcontextが肥大化す る！！！ ポンコツ挙動のせいで、寄り道が増える。context 肥大 -> ポンコツ -> context 肥大ループ！！！！！！ ※ テトリス作る程度なら簡単なのに、ちゃんとしたプロダクト開発に使おうとするとポンコツになるのはこ れが理由 ※ 特に3.7-Sonnetさんカワイイですねー コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 27
28. 不要な情報（ノイズ）を取り込んでcontext汚染（これも致命的） チェーホフの銃！（LLMのプロンプトエンジニアリング本を読んで！！） ポンコツ挙動によるポンコツな情報取り込み（LLMのせい） ポンコツ挙動のせいで、寄り道が増える。context 肥大 -> ポンコツ -> context 肥大ルー プ！！！！！！ ユニットテストの結果の成功ログ（既存のCLIツールの特性） テスト修正で必要なのは、テストが失敗してるところのログだけ これとかはMCPやCLIオプションでなんとかできるかもしれないが、工夫が必要 ユニットテストに苦戦してるときは実行回数が増える -> ポンコツ context 肥大ループ！ むしろポンコツループに入ってるときの失敗リトライの履歴を消したい 失敗に該当するトライは大体不要な情報だから、そこをcontext改ざんで消せれば、動作改善しそう 完全に不要な警告の類い（例: pnpmのバージョンアップ警告） 人間から見たら別にどうでもいいんだけど、AIにとってはcontext汚染にしかならない コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 28
29. ユーザープロンプトの環境情報 <environment_details> # VSCode Visible Files # VSCode Open Tabs # Recently Modified Files # Current Time 2025/5/9 午後10:51:21 (Asia/Tokyo, UTC+9:00) # Current Context Size (Tokens) 754,894 (72%) # Current Cost $7.06 # Current Mode <slug>code</slug> <name> Code</name> <model>gemini-2.5-pro-preview-03-25</model> </environment_details> ※ これほんまにいるん？userターンで毎回これ付与されるんやで！！！（設定で削りまくって軽くしてこれ） コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 29
30. LLMの性能問題 - 3.7 Sonnetは嘘をつきまくる！ ゴールを自分の都合のいいようにねじ曲げる 「完了しました！！！」 -> 実はダミー実装だった 指示してるはずの、ユニットテストが壊れている 「ユニットテストも正常です！」 指示してるはずの、型エラーが修正されていない 「型チェックも正常です！」 指示してるはずの、lintが通らない 「lintも正常です！」 指示してるはずの、動作確認をしてない 「動作確認も問題ありませんでした！」 「エラーが出てますが、今回のタスクとは関係無いため無視します（関係ある） 」 コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 30
31. LLMの性能問題 - 3.7 Sonnetはチートをする 「俺、またなんかやっちゃいました？」 コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 31
32. LLMの性能問題 - context size Sonnetはcontextが100kを超えたくらいから使い物にならなくなる（long context 性能が弱いのと、contextが複雑化している） Gemini 2.5 Pro はそこらへんが大分改善されている。long context性能は高いし、 contextの複雑性への耐性が強い 最近 implicit prompt cachingが実装されて大幅にコストダウンしたし、Sonnet しか使ってない人は絶対に gemini 2.5 proを試しておくべき コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 32
33. LLMと人間の認知特性の違い 人間はなんやかんやでcontextの絞り込みがうまいから、認知特性の違いで「この 程度ならできるやろ」って思ってミスることがある Sonnetは大局観がめちゃくちゃ弱い（context sizeの問題） contetxが小さいときは、人間が驚くレベルでLLMがめちゃくちゃうまくタスクを こなす でもちょっと状況が変わると急にポンコツになる ポンコツになる理由が様々（じつはこれが一番の鍵） コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 33
34. IV. どうやって負けパターンを回避するか コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 34
35. contextを小さくする必要がある 選択肢: 1. リポジトリそのものを小さくする 2. リポジトリはそのままでも、小さなコンテキストを用意してあげる 3. チャットUIを使って履歴の切り替えをする コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 35
36. 1. リポジトリそのものを小さくする そもそも小さいリポジトリだけを用意する 検証や学習用途 モノリポジトリの、ルートではなくパッケージ一つだけをエディタで開いてしま う 面倒は多いけど、面倒を乗り切れるならあり アーキテクチャそのものをこれに適した形にする 人間にとっても、分割は重要 クリーンなアーキテクチャ 昔から言われてる設計論はやっぱりそれなりに正しい コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 36
37. 2. 小さなコンテキストを作ってあげる 作業ごとにコンテキストを切る 設計モードと実装モードは、実践してる人も多いけど、もっと細かくしてもいいかもしれない 例: 設計 -> 設計レビュー -> 実装 -> 受け入れテスト でも実装が失敗するので、実装をさらに分割したい なんかもっといい分割アイデアがあれば是非僕も知りたい boomerang mode とか orchestrator modeのように、サブタスクをオーケストレーションする ただし、プロンプトを生成するプロンプトを書かないといけないので、かなり面倒くさい プロンプトがゴツくなりすぎる。LLMを変えたりするときとか結構面倒 本当はモードごとに、使えるMCPも限定したい（ソフトウェア型の改良ポイント） 大設計から粒度の小さな詳細設計に落とし込む 実装モードにおける情報を限定する 設計書に、アクセスしていいディレクトリ一覧やファイル一覧を作ってあげる 設計書から、スコープ外の情報を削る コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 37
38. 3. チャットUIを使って履歴の切り替えをする 失敗した作業は部分的に消して巻き戻す 巻き戻した世界線での知見をプロンプトへ反映しなおす ただし！！ GUIが使いづらい Cline/Rooの場合 checkpoint とチャット履歴改ざんがリンクしてないので、かなり 面倒が多い コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 38
39. どれだけ努力しても確率で失敗する！！ ChatGPT CodexやClaude Maxを使って定額制で、タスクを投げまくる たとえば、同じタスクを大量に投げてうまくいったやつを採用する。非決定論的な挙動のおかげで できる 定額制じゃないと、コストを投げ捨ててる感じがして心と財布が痛むやつ そこまで運任せじゃないやり方: 失敗したときの挙動を元にタスクを作り替える たとえば失敗前提でタスクをやらせて観測をする 作業ログを見ながら、失敗する条件は何か？ どういうコンテキストに絞り込めばいいか？必要なファイルは何だったか？ いわゆる「高速目grep」をやらない。失敗前提なんだから、変なことしても「おまえは失敗する定 めだったのだよ。次に期待するしかないな」とか悪役っぽい言葉をつぶやきながら、事後のログだ け分析しちゃえばOK！ つまり、これをするツールやプロンプトがあればよいのでは？？？ コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 39
40. エディタ間借り型は、失敗前提のやり方と相性が悪い エディタを占有されてしまう 複数ディレクトリを作成して別々のインスタンスにしないと同時に実験ができない。時間がかかりすぎ る 途中であれこれ関与したくなる 途中で、何かしらをやらないといけなくなっちゃう（フル権限を渡しちゃうと、リポジトリそのものを 壊されるリスクすらある） VSCodeという、割と重いソフトの一部のインスタンスが、この目的に占有される 動かし続けると、結構バグることがある（ここ二ヶ月で何度か、エディタ拡張や、エディタそのも のが死ぬことがあった） できれば、エディタと、コーディングエージェントを分離したい -> つまり、コンテナ作って消しての方が遙かに楽やん？？？？？？？ コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 40
41. V. まとめ コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 41
42. コーディングエージェントの未来は三択 1. コンテナ型エージェント 本命 エディタを占有されない！リトライ前提のやり方との相性がとてもよい！！ 間違いなくこれが伸びるはず！！！！（僕の主観です） というか、OpenAI本格参入によって今後は激戦が必至。たぶんGoogleなんかも参入すると思う GoogleとGitHubが 本日参戦！！！！！ Anthropicもコンテナ型に参入すると思う CLI型はたぶんコンテナ型に寄せられていくと思う 2. エディタ間借り型は、今よりも遙かにリッチな対話機能・UIを持つコーディングエージェントになってほしい！！！！ 始めたばかりの序盤（まだ何もない状態）とかならエディタ間借り型の方が有用なはず 人間が関与しやすく 学びを重視する context汚染をなんとか出来る仕組みが必要 3. 既存のエディタ間借り型向けの補助ツールを作る 決してメインの流れではないが、実はいま一番必要かもしれない MCPを作るのもある意味これに近いが、contextを小さくする・context改ざんをするためのツールが必要 コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 42
43. ということで次トライしたいこと 補助ツールをあれこれ考えたい Rooの会話ログを食わせたら、小さいcontextに必要なものを作るプロンプトとかツールとかを作る contextを小さくするための各種工夫を泥臭くトライする 作ってるコーディングエージェントも再設計をする コンテナ型を前提に考え直す ステートレス型ってのもありかも？（常用するものではなくても検証には便利なはず） Roo Codeとかにcontributeしたい気持ちがありつつも、話を追いかけるのがコスト高すぎて、他者の OSSにcontributeできない... 僕の理想型と考えてるものは一定の議論を呼びそうなんだよな。 。 。 Discordやissuesとかの議論を、重要なものの解説をしてくれたり、ダイジェストで届けてくれるよ うな、コミュニケーション補助ツールほしい コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 43
44. ご清聴ありがとうございました！ コーディングエージェントを作ってるけどうまくいかなかった話 ～あるいは二ヶ月本気でコーディングエージェントと向き合った話～ @erukiti 44