knqyf263's blog

自分のためのメモとして残しておくためのブログ。

AIエージェントで前から欲しかったツールを作ってみた

はじめに

コンテナ関連の開発において、コンテナイメージの中身を確認する必要性はしばしば発生します。 特にシェルが含まれていないイメージの場合、ファイルの確認が面倒になりがちです。 また、私の開発するOSSではレイヤーのマージをコンテナランタイムに頼らず自前で行っている関係で、レイヤー単位でファイルを確認したいケースも多くあります。 さっとファイルの中身を確認したい場合もあれば、ファイルを手元にエクスポートしたい場合もあります。

diveというツールもありますが、どうやらファイルを見たりはできないようでした。

view / download files from UI · Issue #224 · wagoodman/dive · GitHub

既存のツールではこれらの要件を満たすものが見当たらなかったため、新しいツールの開発を考えていました。

プロジェクト背景

ファイルの中身を見るための、TUIを使ったインタラクティブなツールを作りたいと考えていましたが、フロントエンドなど含めUI関連の実装はどうしても好きになれない自分はなかなか実装に踏み切れずにいました。 子育てをしていると細切れの時間しかないため腰を据えて新しいプロジェクトを始めるのが難しくなる、という情けない言い訳もしておきます。

最近、CursorやClineなどのAIエージェントを試していく中で、新規プロジェクトの開発における可能性を感じていました。 既存プロジェクトでも使えますが、コーディングルールやテストの整備などをしっかり行う必要があるので時間がかかります。 一方で新規プロジェクトであれば、とりあえず好きにやらせることができます。 特に、TODOアプリなどの簡単なアプリケーションを0から作るのが容易なのはわかりましたが、より実用的なツールでの評価が必要だと感じていました。

そこで、面倒に感じていたTUIツールの開発をAIエージェントに任せてみることにしました。開発のルールは、

  • 一切自分でコードを書かないこと
  • AIの生成したコードはほぼレビューせずに受け入れること
  • 動作確認は人間が行うこと

としました。 かなり極端なルールですが、一旦どのぐらいやれるのか知りたかったので自分では一切書かない縛りを課しました。 AIエージェントとしてはCursorのComposerエージェントモード（Claude Sonnet 3.5）を使用し、開発言語はGoを選択しました。 今回はBubble TeaというTUI用のライブラリを使ったのですが、自分はこのライブラリの使い方を知りません。 あまりAIの手助けができないように、あえて調べないようにしました。

プロジェクト概要

結果ですが、一行もコードを書かずに動くものが完成しました。 GitHub ActionsのワークフローやREADME含め自分では何も書いていません。 普段ならOSSを作ったらRedditなどで宣伝するところですが、今回は自分で何も書いてないしな...となって宣伝していません。

github.com

動画を見てもらえば分かりますが、それっぽく動きます。 デモ動画は以下のリンクから見られます。 はてなブログにアップロードしようとしたらサイズを10MB以下にしてもエラーが出たので諦めました（調べたら他の人も最近同じエラーに遭遇しているようでした）。

github.com

名前の由来は日本語の「層」（そう/sō）から来ています（レイヤーに関するツールなので）が、これもAIに提案してもらいました。 以前Trivyというツールを作ったのですが、名前に何の意味もなかったのをずっと後悔していたので今回はそれっぽくしました。

主な機能

READMEにあるデモを見てもらったほうが早いですが、特徴的な機能としては以下です。

  • 🔍 各レイヤー内のファイルをTUIで探索
  • 👀 レイヤー内のファイル内容をプレビュー
  • 💾 レイヤーからローカルファイルシステムへの簡単なファイルエクスポート
  • 📄 イメージのマニフェストと設定の表示
  • 📦 ローカルとリモートの両方のコンテナイメージに対応

基本的な使い方

# ローカルイメージの確認
sou nginx:latest

# リモートイメージの確認
sou ghcr.io/knqyf263/my-image:latest

あまりこういうニーズがある人は多くないかもしれませんが、もし試してくれた人がいたら是非フィードバックをください。 ただソースコードの中身をあまり知らないのでバグ報告されても直せません。

開発プロセスと学び

プロンプト1つ投げたら一気に完成したなどという甘い話ではなくて、試行錯誤しながらやったので全部作るのに16~20時間ぐらいはかかったと思います。 エージェントが勝手に暴走してわけわからない方向に進むことも少なからずあり、そのたびに軌道修正してあげる必要はありました。 しかしエージェントが頑張っている間は漫画を読むなどしてダラダラ過ごし、終わったぐらいに「どれどれ？」と見るスタイルでやっていたので、実働は半分以下だと思います。 また、今回得た知見（後半に書いたTipsなど）を使うと次回以降はもう少し早く実装出来ると思います。

とはいえ自分で開発したらもう少し早くできたと思うのでAIで生産性爆上がり！！という感じではないのですが、面倒で始められなかった週末プロジェクトがAIのおかげで完成できたことに大きな価値を感じています。 最初の「ライブラリの使い方調べないといけなくて面倒だなー」とかのハードルを乗り越えさせてくれるという点は素晴らしいです。 どうしてもAIが解決できないバグがあり必要な箇所だけライブラリのドキュメントやソースコードを読みましたが、自分で実装する場合に比べてそれらに割く時間はかなり減りました。

なお、AIの生成したコードはクオリティが現状はあまり高くないと感じていますが、趣味の小さいOSSぐらいにはちょうどいい気がしています。 生成されたソースコードの中身をほとんど見ていないので自分でメンテナンスしたくはないですが、今後もAIにメンテナンスさせるなら問題ないです。 趣味のOSSなので安定性もそこまで求められません。 自分で使う範囲で動けば十分です。 ちなみに知らないコードを公開するのセキュリティ的にどうなの？ということで最後に変なコードが紛れていないか調べるために軽く全体を眺めたりはしましたが、あまりロジックは追っていません。

Cursorの話をすると、ドキュメントのURLを事前に指定するとインデックスして参照させられるので、知らないライブラリを使って開発させるときに便利です。 Bubble Teaの使い方も結局最後までほとんど知らないままでした。

少し変わった観点として、開発が再開しやすいというのもあると思います。 趣味の開発だと急に中断されて、やっと再開できたのが数日後ということもあります。 こういう時、自分は大抵何をやっていたか忘れていて思い出すのに苦労するのですが、AIエージェントとの開発だとチャット履歴がエディタのすぐ横にあるので文脈を思い出すのにかなり助かりました。

そしてもう一つ学んだこととして、自分はプログラムを書くのが好きということです。 AIにコード生成させるのは楽ですが、雑なコードが生成されて動かない場合はこちらでデバッグする必要があります。 個人的にはこの作業は全然楽しくなかったです。 一番美味しいところを持っていかれて尻拭いだけやらされている感覚がありました。 誤解のないように断りますがデバッグは割と好きな方で、難しいバグの原因を突き止めて修正するのはプログラミングの最も楽しい作業の1つだとすら思っています。 しかし自動で生み出された初歩的なバグのデバッグはやはり苦痛でした。 この辺は個人差があると思うので、自分で体験してみるのが良いです。 自分の指示でどんどん完成していくのが楽しいと感じる人もいると思います。

ただ好きか嫌いかに関わらず、以前とは大きく異なる開発方法に世の中が動いていく気はするので、こういった開発に慣れる必要はあると思います。 個人的には「なーにがAIエージェントじゃ。まだまだ機械なんぞに負けん。」などと老害丸出しなことを思っていたりしましたが、そんなこと言っていられる時代ではなさそうなので2025年は心機一転積極的に試しています。 過去に固執して新しいツールやパラダイムを受け入れられない人がAIに取って代わられる、という発言を最近見ましたがその通りだなと思います。

Steve Yegge observes that it is not junior and mid-level programmers who will be replaced but those who cling to the past rather than embracing the new programming tools and paradigms.

www.publickey1.jp

あまりに初歩的なバグはAIエージェントが解決してくれるので、「おー優秀だなー」となっていましたが、自分から見て明らかなバグのときでもなかなか解決方法にたどり着けず、もどかしい気持ちで見ていることもありました。 最近子供に勉強を教えるときも、間違っていてもなるべく指摘しないように心がけているのでそんな感覚でした。 ただ子供は間違っていても「頑張れ」と内心応援しながら成長を見ていられますが、AIはそうではなく生産性を上げるために使っているのでその辺に差があります。 AIに名前がついて顔が表示されて話すようになり自分が育てていく感じになれば、温かい目で見守ることが出来るようになるかもしれません。

あと開発にかかった時間とは別の軸として、あまり頭を使わずに済んだ感覚もあります。 生成されたコードにケチを付けたりするだけで、どのようなデザインで開発するかを考えて実際に手を動かして試行錯誤するプロセスがなければ大分楽だなとは思いました。 ただ今回の趣味プロジェクトを通して技術的には特に成長がなく、AIへの命令の仕方だけうまくなりました。 趣味の開発は普段業務で触れないところを学べて勉強になる側面がありますが、それは完全にありません。 ただ口を出すだけの人間に成り下がりました。 これがやりたかったことなんだっけ...？という気持ちは少なからずあります。

難しいことは考えずみんなピザを焼いていきましょう。

バグ修正のTips

いくつかやってみてバグ修正に効果的だったことを書いておきます。 AIエージェントを使い込んでいる人達と違って最近使い始めたばかりなのでほぼ素人ですが、色々試行錯誤してみたのでメモがてら残しておきます。 AI関連は変化が目まぐるしいので、ちょっとしたら改善されて不要になる可能性はあります。

デバッグメッセージを出力させる

バグを見つけたとき、バグの内容だけ説明しても解決にたどり着けないことが多かったです。 ですが、AIにデバッグ出力を挿入させ、そのデバッグメッセージを渡すと解決できるバグもそこそこあったので、積極的に出力させると良いと思います。 将来的にデバッガとかも動かせるようになったら不要になるとは思います。

いくつか自分が思いついたことも伝える

「表示が崩れている」だけだと直せませんが、「indexの処理が1つずれているかも」とか少し思いつくことを伝えると解決できる可能性がかなり上がります。 仮にその推測が外れていても闇雲に直すより前進できます。 その点でやはり人間はまだ必要な気がします。

命令を与え直す

バグ修正を依頼したあと、明後日の方向に走り出すときがあります。 その場合、追加でコンテキストを渡しても軌道修正するのが難しかったりします。 そういうときは新たなセッションを作って、そのコンテキストも含めた新しいプロンプトを渡すとあっさり修正できたりします。

変更範囲を限定する

ざっくりバグ修正を依頼すると全然関係ないファイルを編集し始めたりします。 そうなると収拾がつかなくなるので、ざっくりこの辺のファイルを修正して、などと伝えるだけでマシになります。

うまくいった箇所までコミットしておく

これはよく言われていることだと思いますが、せっかくうまくいったと思ってもその後おかしな修正をして動かなくなったりします。 Cursorはチェックポイントを作って戻れるようにしてくれますが、チャット履歴が長すぎていつの時点まで正常に動いていたか分からなくなって何度か作り直したりしました。

数回試して解決できなければ諦める

これはとても大事です。 今回はAIにやらせることに固執していたため、何としても自分で調べずにバグを直させようと10回ぐらいプロンプトを与え直したりしました。 しかし結局解決できませんでした。 最終的には諦めて、自分でライブラリのソースコードを読んで間違いを丁寧に説明したらAIがコードを修正しました。 その他にも何度か意地になってAIに頑張らせましたが、結局解決できませんでした。 無理なものは無理ということが多いので、数回工夫して試して無理なら大人しく自分でデバッグしたほうがいいと思います。

型のある言語のほうが良さそう

Cursorのエージェントモードだと修正後に勝手にLinterを走らせて問題があればさらなる修正を行います。 つまり一旦AIによる実装が終わって通知されたタイミングでは少なくともビルドできる状態になっています（どう頑張ってもAIがエラーを直せないときはその限りではありませんが）。 型のない言語だとその辺りは逐一テストを実行したりなど少し大変そうな印象なので、AI時代だとLinterで多くのことがチェックできる言語のほうが迅速にループを回せる気がします。

その他

チャットが長くなってきたら新しいチャットにするとか、Rules for AIで細かくルールを定義しておくとか、プラクティスがいくつか調べると出てくるので、そのへんは当然やっておいたほうが良いです。

おわりに

AIエージェントは自分の欲しいちょっとしたツールを作るのに向いていると思いました。 実際に一行もコードを書かずに動くものができたのは驚きました。 このように生み出されるソフトウェアが確実に増えていくと思います。 ただ趣味のOSSは楽しくてやっていることもあると思うので、その場合は使わないほうが幸せな気がします。

ピザだけでなくたい焼きも焼いていきましょう。 20個以上焼いたらだんだん上手くなりました。