前回の記事
GitHub ActionをAIに書かせる
前回紹介したgithub-action-artifactbundleだが、コードのほとんどをClineを用いてAIに書かせている。この記事ではその過程について紹介したい。Actionの詳細については前回の記事をどうぞ。ちなみにこの記事は人間が書いている。
プロンプトエンジニアリングの到達点
ClineはVS CodeにAIエージェントを追加するエディタ拡張だ。プロンプトを与えるだけで、設計、実装、テストの実装、動作確認を一気通貫でやってくれる。
コードの理解と編集だけではなく、パーミッションを与えればコマンドラインの実行も可能。テストの実行をCLIから行い、出力を見て良い感じに修正を加えるという一連の流れを半自動化できる。プロンプトに応じて差分が来るので、Approveすると反映され、直してほしい場合はコメントする。良い感じに任せる場合は自動承認にもできる。
感覚としては、優秀なインターン生がステップ毎にPRを出してきてそれをレビューしてマージする感じ。
プロンプトとしては大体これぐらい具体的な指示を出していた。全体の設計や仕様はかなり固めた状態で指示することで、驚くほど意に添った実装をしてくれる。
特定ドメインに対しての類推能力も高い
今回実装したGitHub Actionはビルドシステムを扱うものでなかなか専門性の高い領域。そんな中でも、驚くほど高い洞察力を発揮していた。
特にギョッとしたのは、Swift Packageのビルドディレクトリの構造から、経験的にtriple*1を判定する処理だ。Clineがこのような実装を提案してきた。
この実装に至るには多くのドメイン知識が必要になる。通常、Swift Package Managerによるビルドではビルド成果物は.build/arm64-apple-macosxなど、tripleを表すディレクトリ以下に出力される。一方でUniversal BinaryのビルドはXcodeビルドエンジンしかサポートされていため、必ず./build/apple以下に入る。
これはハックに近い経験則だ。当然、このような込み入った事情はプロンプトでは説明していないが、これを考慮したコードを出してきて驚いた。他の指示や全体の設計からこの結論に至ったのかもしれないが、大した洞察力だと思った。全体的にドメインに対しての理解力が異次元。
人間くさいテスト工程
今回のプロダクトは外部の入出力が多く、密結合だが、テストケースの実装の精度にも舌を巻いた。網羅性や、fixtureの策定と言った部分はほぼ完璧に近かった。
まずテストケースを書き、実行、エラーを見て修正するというまさに試行錯誤の様子が見て取れた。一方で延々と同じような修正を繰り返して詰まってしまい、人間が出動する場面もしばしば。
特に今回はテストフレームワークJestの使い方という本質的ではない部分に弱く、ES ModuleとJSCommonモジュールの区別をせずにstubに失敗し続けていた。結局、人間が不慣れな領域ながら勉強して直させていただいた。ESMはAIにも早すぎる。
READMEや設定ファイルも自動生成
OSSを作る中で、この辺のドキュメンテーションは楽しくもあり、機能追加の度にドキュメントを追従するのは面倒。そんな中、READMEの自動生成は役だった。
設定ファイルなどのDSLはAI生成をするのに恰好の題材だと思う。毎回必要なときに調べて書いていたlinterの設定や、GitHub Actionのメタデータなどは「こういうことしたいから良い感じに頼む〜」と指示するだけで、大体意図通りの物が出てきた。
AIバックエンドとモデル
最初は特に考えずにOpenAIのgpt4o、部分的にo1-miniを使っていた*2が、コンテキストの肥大化と共にみるみる金が溶けていってやめた 💸 最終的には1クリック50セントを超えることもあった。OpenAIはメチャクチャ高い。
ClineをOpenAIバックエンドで動かしてたら、後半ウィンドウがデカくなりすぎて金がメチャクチャかかった。想定より高価 💸 Claudeの方が良さそうなのでそっちに切り替えた pic.twitter.com/PGU9968MjG
— giginet (@giginet) February 1, 2025
結局、最終的にはClaude 3.5 Sonnetを使っていた。こちらはとてもリーズナブルで、高くても1クエリ10セント未満に収まる。質も全く問題なし。ただしAPI Limitが結構厳しく、課金によってTier3ぐらいまでレベリングしないとエラーが頻発してストレスフルだった。どう転んでもみなさまの人件費より安くつくので安心して課金しよう。
Claudeはチャットエージェントとして使うにはクセが強いが、APIバックエンドとして使うにはとてもお値打ちだ。
あくまで「優秀なインターン」
ここまで見てもらえたとおり、素晴らしい開発者体験ではあるが、まだまだ課題はある。
例えば、コードリーダビリティには大分難がある。AIは非常に高い読解力を持ち合わせているが、その基準で書かれたコードを人間が平易に理解するのは難しく、多重ループや冗長な処理、異様に長いメソッド、型の緩さなど、自動生成っぽさが目立つ。
基本的に途中はおまかせしていたので、把握し切れていないという理由もあるが、いざ自力で読んで手を加えようとするとなかなか厳しいコードだった。今回はプロンプトの段階から具体的な設計を与えていたが、0から考えてもらうとさらにこういった面が顕在化するのだろう。
ツール自体の細かな使い心地が悪い点もあり、まだまだ荒削りだ。例えばちょっとした命名の変更などに使うには大げさ。手でやった方が早い修正でも、コンテキストの途中で下手に手動での修正を加えると、後続の指示で先祖返りが発生することもある。
また、1ファイルずつ読み込んで修正するという性質から、一括置換やまとめてデバッグログを消してくれと言ったプロジェクト横断的な修正には向いていなさそうだった。
ウィンドウサイズの限界もあり、プロダクト完成までに1つのコンテキストを維持するのが困難という点も大きい。タスク毎に新たに状況を思い出してもらわなくてはならない。
とはいえ、この辺は時間が解決する問題だろう。
早く仕事を奪ってほしい
破壊的イノベーションと断言できるほど強力なものが登場したなという印象。ドキュメンテーションやテストfixtureの準備というつまらない部分は任せ、本質的な設計や試行錯誤に時間を使えるのは素直に良いなと思った。
というか、ワンクリックで実装やテストが出てきて、目的が大体達成される楽さに脳がやられる。プロダクト1つ作りきった頃には、実装が面倒で、簡単な作業含めて、大部分をAIに丸投げするジャンキーと化してしまった。
しかし、全体的にお決まりの「AIに仕事を奪われる」状態にはならずに、まだまだ踏みとどまれると思っている。
結局、プロダクトの仕様決めや設計は熟達した経験が必要になるので、現状全部おまかせはなかなか難しいと感じる。また、UIを作るような仕事はあんまりしないので評価しづらいが、ユーザーフェイシングな部分に近いほど人手が必要になるところが増えていくだろう。
とはいえ、最近の急速な環境の変化を見ているに、1年後はどの水準まで到達しているか予想がつかない。引退の日も案外近いのかも。
