ハクソク

世界を動かす技術を、日本語で。

エージェントを使ったプログラミング方法

2025年6月9日原文(crawshaw.io)

概要

  • Agents はLLMにフィードバック環境を与え、プログラミング作業を自動化する仕組み
  • シンプルなforループとLLMの組み合わせで大きな効果
  • API利用 や テスト自動化、 コード修正 が大幅に効率化
  • 時間やコストの課題はあるが、将来的な改善に期待
  • 具体例を通じて 実用性 と 課題 を解説

エージェントによるプログラミング手法

  • Agent の定義：LLMをforループで繰り返し呼び出し、外部ツールと連携する9行程度のコード
  • エージェントは 人間の介在なく コマンドを実行し、結果を取得する自律的な仕組み
  • LLM単体では仮想ホワイトボード上のコーディングと同等で フィードバック不足
  • エージェントは bash や patch、 web_nav などのツールを活用し、実際の開発環境を模倣
  • git 操作やAPIドキュメントのweb検索、テストの自動実行も可能

エージェントのメリット

  • API利用 の正確性向上：ドキュメント参照や仕様確認が自動化
  • コンパイラエラー の即時修正：構文ミスやインターフェースの誤りを検出
  • 依存関係管理 の最適化：利用中バージョンに合わせたコード生成
  • テスト駆動開発 の自動化：失敗時の修正やテストコード追加も自動
  • 大規模コードベース の効率的探索：必要な部分だけ選択的に読み込み
  • UIやAPIの最終出力 の自動検証：スクリーンショットやログ解析も可能

エージェントのデメリット

  • 処理時間の増加 ：1リクエストで数分かかる場合も
  • コスト増 ：API利用料が発生（例：1回のコミットで$1.15）
  • GPU/CPUリソース消費 ：中間作業が多く、人的コスト削減とトレードオフ

実践例1：GitHub App認証の実装

  • sketch.dev でGitHub App認証機能をエージェント主導で実装
  • 数回のフィードバックだけで認証フローを構築
  • セキュリティ脆弱性 （全ユーザーが全リポジトリにアクセスできる）を指摘し、1文で修正依頼→即修正
  • パフォーマンス問題 （APIコール数の爆発）も要件変更で対応
  • 従来1週間かかった作業 が 1日＋掃除の時間 で完了

実践例2：SQLとJSONの特殊な運用

  • Tailscale流 のSQLテーブル設計（全カラムをJSONで管理）
  • INSERT/UPDATE もJSONベースで操作
  • スキーマ変更が容易・JOINも利用可能
  • 制約や動的チェックが強化される一方、データ量増加や運用の複雑化が課題

エージェント活用の今後

  • 人間の作業を機械化 し、生産性向上
  • 制約や限界 はあるが、エンジニアリング投資に値する価値
  • 小さなタスクで実際に試すことで、 有用性を体感 可能
  • 将来的にはコスト・時間の課題も解消に向かう見込み

今後もエージェント技術の進化により、 プログラミングの自動化 と 生産性向上 が期待される。現状の課題を認識しつつ、積極的に活用することで、さらなる効率化を目指す姿勢が重要。

Hackerたちの意見

最後に、LLMについての真面目な記事があって、流行に流されずにこのツールが何に役立つか、何に役立たないかを現実的に見つめているのがいいね。すごく面白い読み物だけど、「エージェント」って言葉が、再帰的にLLMを呼び出すforループに使われるのはどうも好きじゃない。でも、この業界は名前をつけるのが得意じゃないから、仕方ないね。追記：文法

└

みんながすぐに理解できる名前だと思うけど、他に何か提案ある？LoopGPTとか？

└

OPのエージェントの定義には少し異議があるな。個人的には、エージェントは単なるループの中のLLMじゃないと思う。エージェントの定義的な特徴は、LLMの振る舞いが他の論理的なコンポーネントによって制約されたり導かれたりすることだと思う。これらの中には決定論的なものもあれば、MLを使ったもの（LLMを含む）もある。つまり、LLMは何らかの形でプログラムされているってこと。例えば、コード編集後にLLMにテストを構築して実行させるのは、より良いパフォーマンスを引き出すための素晴らしい方法だよ。でも、要するに、決定論的なレイヤー（テスト）がLLMにより有用なことをさせるように促すシステムを設計しているってこと。多くの「エージェント的推論」システムは、実行前にLLMに計画を立てさせるように意図的に強制している。時にはこれらの計画が決定論的に検証できることもあって、計画が良くない場合はLLMが再生成を強いられることもある。LLMが自分で自分をフィードしているという考えは間違ってはいないけど、これらのシステムが有用な理由を見逃していると思う。LLMの振る舞いを監視するさまざまな他のコンポーネントによって意図的に導かれているんだ。

エージェントを使ってる人たちの中で、実際に「プログラミング」が好きな人はどれくらいいるんだろう。問題の解決策を考えて、それをコードで表現することが好きな人。エージェントがやってる仕事の多くは、その部分を取り除いて、代わりに自然言語で何をしたいか説明させて、LLMがバグを出さないことを願うだけになってる気がする。

└

その通り。自然言語がプログラミングに向いてない理由にも関係してるよね。[0] [0]: https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667... まあ、確かにLLMはstackoverflowみたいなプログラミングの質問には役立つと思う。でも、SOが衰退してるから、こういう質問に関する最新のデータは減っていくと思う。

└

コードを書くのは好きだし、LLMが一発でパーサーを作っちゃうのを見るのはちょっと悔しいけど、同時に何時間もかけてパーサーを作るのは、プロジェクトのもっと大きな目標から気をそらすことでもあるんだよね。それに集中できるのはいいことだし。自分が欲しい型や関数のシグネチャをスタブで作っておいて、LLMがそれを埋めてくれたら次に進める。多分、実装にも挑戦するけど、楽しくなくなったらLLMに頼るって感じかな。逆に、LLMのおかげで何かを磨く楽しさに集中できるようになった。大きな変更をするのも「やりたいけど面倒」ってことがなくなったし、例からテストを生成するのも苦痛じゃなくなった。READMEにコードを同期させるのも面倒じゃなくなったし、リファクタリングや改善のアイデアを考えるのも簡単になった。聞いて、ケースを作ってもらえばいいだけだから。もっと野心的になれたり、週末プロジェクトを新しいレベルに引き上げられるのは楽しいよ。考え方を変えれば、ソフトウェア好きなビルダーの楽園みたいだ。もっとコードを磨けるし、プロジェクトをリリースできるし、もっと難しい課題にも挑戦できるし、目標も高く設定できる。だけど、最初はちょっとした resentment を乗り越えるのに時間がかかったな。

└

逆に聞きたいな、みんなが何を好きなのか？私はすでに何度も解決された問題に対してコードを書くのは楽しめない。辞書を使うように、毎回ハッシュテーブルをゼロから作るわけじゃないし、それは最初の時だけ楽しい。もし「この言語の動くコンパイラをくれ」とか「深さ優先探索を使ってこの問題を解決して」と言えたら、プログラミングが楽しくなくなることはないと思う。自然言語について、そして兄弟コメントへの返答として、同意するよ。自然言語は計算プロセスを説明するには非常に貧弱なツールだ。おもちゃの例にはいいけど、ある程度の洗練されたレベルになると、曖昧なことや完全に矛盾することを言うのが簡単すぎる。でも、ここで誰もLLMを「盲目的に」使えとは言ってない！生成されたかどうかに関わらず、自分の出力には責任があるからね。

└

この評価には賛成できない。今のところ、LLMが引き継いでいるのは、実装のような繰り返しの作業ばかりだ。私はまだプロジェクトのアーキテクチャを考えたり、LLMには難しい非繰り返しの部分を解決することを楽しんでいる。これが1年後にはなくなるかもしれないし、もしかしたら私は栄光あるプロダクトマネージャーになるかもしれないけど、今は楽しんでるから、実際の思考問題に集中できて、繰り返しのパターンやクズを持ち上げる手助けをしてもらえる。

著者の言う通り、コードレビューは中途半端でほとんど壊れてると思う。エージェントを使うと、ボトルネックはコードを読むことにあって、書くことじゃない。みんなが中途半端にコードをレビューしてたり、自分の好みを主張するための場にしてると、エージェントの使い方が完全に崩壊するよ。深刻なセキュリティ問題やパフォーマンスの低下を簡単に引き起こすからね。正直に言うと、そういう問題はただ「コードを読む」だけじゃ見つけられない。手を汚して手動でデバッグしたり、仮定をテストする必要があるんだ。

└

エージェントの意味ってそこだよね？もしテストカバレッジが完璧だとしたら、AIがコードを書いて、そのセキュリティやスピードについてフィードバックをもらえるってことだし。AIがテストを書く手伝いもしてくれるしね！

自分のツールのためだけにコードを書くからかもしれないけど、他の誰かや何かに頼ってコードを書いてもらって、それを読んで理解して修正するっていうのがいまだに理解できない。ただ、APIドキュメントから探してほしいものを抽出してもらうのはすごく便利で時間の節約になるけどね。将来的にLLMがどれだけ良くなるかは関係なくて、他の人のコードを読むのが好きじゃないんだ（笑）。

└

これが私に役立つケースだよ（リスト使ってるけど、AI生成じゃないからね…） - 定型的なコード。基本的にマクロやコード生成の必要がなくなる。欠点は遅くなるし、マクロを更新して再生成することができないこと。でも、少し定型的だけど実装によって微妙に違うコードには使えるから、マクロが使えない場合には助かる。 - よく知ってるけど暗記してないAPIを使うとき。Google検索してドキュメントを探す手間が省ける。私は型付き言語を使ってるから、もし間違ったことをしたら型チェッカーがキャッチしてくれるし、結局手動でテストしたり自動テストを設定したりするから、間違ったことをしてもキャッチできるステップはたくさんある。 - プランニング：これは実はLLMの中であまり評価されてない部分だと思う。10ファイル以上の変更が必要なとき、LLMに全ファイルを見てもらって、変更点をMarkdown文書にまとめてもらうのはすごく助かる。時々、そのプランが十分良くて、少し手を加えるだけで「そのままやって」と言えることもあるし、間違ったところがあっても部分的に従いながら修正するのが役立つ。追記：LLMが生成したコードの好きなところは、プロジェクト内のスタイルや命名規則を維持してくれること。疲れてるとそういうことに気を使わなくなるからね。

Hacker Newsで議論の続きを見る