- Agentic coding に関する実運用の事例共有
- 主に Claude Code Sonnet モデル を使用しており、IDE 統合よりも作業全体を AI に委ねる方式を好む
- Go 言語 はエージェント向きの構造とエコシステムの安定性により、新しいバックエンドプロジェクトに特に推奨される
- 速度と単純さ がエージェンティック・コーディングの核心であり、テストキャッシュやシンプルなツール体系が重要
- コードは単純で並列処理可能に構成 すべきであり、エージェントの性能を最大化するにはリファクタリングのタイミング選定が非常に重要
Preface
- 最近、エージェンティック・コーディングの経験を共有する開発者が急増している
- 私は現在、Claude Code Sonnet モデルを Max プラン（$100/月）で使用している
- IDE の比重は下がり、その代わりに Vim を再び使うようになり、Claude に作業を任せて結果だけを確認する流れを使っている
- 革新の速度が非常に速く、投稿内容はすぐに古くなり得るため、長く通用する概念に焦点を当てる
The Basics
claude --dangerously-skip-permissions コマンドを claude-yolo に alias 設定して すべての権限制限を解除 している
- これは dev 環境を Docker で安全に分離して管理できるため
- Claude はほとんどの基本ツールをうまく扱えるため、MCP(Multi Capability Protocol) は 特殊な場合にのみ使用 する
- 例: playwright-mcp によるブラウザ自動化
- 自作ツールは一般的なスクリプトで構成し、可能な限り シンプルなツール構成を維持 する
Choice Of Language
- さまざまな言語でエージェンティック・コーディングを試した結果、新しいバックエンドプロジェクトには Go が最も理想的 だった
- Context システム: コード全体を通じて明確に流れるデータ構造を提供し、エージェントへの明示的な受け渡しが容易
- テストキャッシュ: Rust など他言語に比べてテスト実行とキャッシュが単純で、エージェントのコード-テストループが効率的
- 単純さ: Go 自体の単純さがエージェントにも有利に働く
- 構造的インターフェース: 型にメソッドが合っていればインターフェースとして認識され、LLM が容易に扱える
- 低いエコシステム変化率: 長く使われるバージョンと明示的な変更により、古いコードの自動生成を減らせる
- Python は多くの問題点 を引き起こす
- fixture や async 処理、遅い実行などにより、agentic loop での効率が落ちる
- フロントエンドは Tailwind + React + Tanstack Query/Router + Vite
- Tanstack Router のファイル名に含まれる
$ 記号がエージェントを混乱させ、問題を引き起こす
Tools, Tools, Tools
- ツールの基準は次の通り
- 速いこと
- 親切なエラーメッセージを提供すること
- LLM が誤って使っても安定して動作すること
- 可観測性がありデバッグしやすいこと
- Makefile ベースで
make dev、make tail-log などのコマンドを提供
- 実行状態の重複防止のため shoreman の fork 版で pid 管理
- ログは stdout とファイルの両方に記録し、エージェントがログから直接情報を抽出可能 にする
- 例: メール認証リンクもログに記録されるよう設定し、ブラウザ自動化でメール認証手順を実行可能 にする
It's All About Speed
- エージェンティック・コーディングにおける最大の非効率は推論コストと非効率なツール利用
- 高速なツール応答速度 が生産性の核心
- エージェントが自ら一時的なツールを作成して使う場合、実行/コンパイルの高速さが業務効率を大きく向上させる
- 遅い環境では動的モジュール読み込みなどの代替策（例: Sentry 向けのファイルモジュール監視と自動実行）の活用が有利
- ログは簡潔かつ明確に 調整してトークン消費と速度を最適化すべきであり、必要に応じて LLM がログレベルを調整できるインターフェースが役立つ
- コード生成段階から意味のあるログ/オブザーバビリティが得られるよう設計することが重要
Stability and Copy/Paste
- エコシステムの安定性は コード再利用性とエージェントの混乱防止 に非常に重要
- Go や Flask のように変動幅が小さく予測可能な言語/フレームワークの使用を推奨
- ライブラリの自動アップグレードに注意。エージェントが残したコメントやコードフローが壊れる可能性がある
- 可能であれば 自分でコードを書く → 依存関係を最小化 の戦略を推奨
Write Simple Code
- エージェントは 単純で明示的なコード によりうまく対応できる
- 推奨方針
- 説明的で長い関数名 の関数を好み、クラスより関数中心で書く
- 継承や複雑なトリックを避ける
- 生の SQL の使用を推奨。エージェントは SQL に強く、ログとの比較や追跡がしやすい
- 明確な権限チェック はコード上で直感的に見えるように構成する（別ファイル/設定への分離は禁止）
Make It Parallelizable
- 個々のエージェントの処理速度は速くないが、並列処理 によって全体効率を高められる
- 例: ファイルシステムを基準にしたチェックアウトのコピー
- Redis や DB など共有リソースの分離方法を考える必要がある
- 例示ツール: container-use を使った Docker ベースのセッション分離
- CI ベースの並列作業、Cursor の background agent なども注目すべきツール
Learn To Refactor
- agentic なやり方では 適切なタイミングでのリファクタリング が重要
- 複雑性が高まるとエージェントはコードを適切に扱えなくなる
- 例: Tailwind class が 50 個のファイルに散らばる前に コンポーネントライブラリ化 する
- 早すぎても遅すぎても非効率なので、適切なタイミングで構造改善を指示する必要がある
What Next?
- agentic coding は急速に進化しており、中核原則は「単純さ、安定性、可視性、並列性」 である
- 生産性向上だけでなく、より良いコード品質の追求 が目標
- エージェントが書くコードの品質は数か月前より著しく改善している
- 柔軟に変化へ対応しながらコーディング体験を拡張していくこと
2件のコメント
私もまだ、AIには簡単なテストコードや例文を尋ねる程度ですが、今では全般的に適用しようとする人たちが次々に出てきています。
まだ時期尚早かもしれませんが、あと数年もすれば当たり前になるのでしょう。
Hacker Newsの意見
私はVS Code NightlysでCopilotとClaude Sonnet 4を併用してAgentic Codingを体験している。1日の半分が会議で埋まっていても、git履歴だけを見れば気づかれないほど生産性が上がったと感じている。今では細かな実装よりも、変更が正しく動くか、このコードを理解できるか、より理解しやすくするには構造をどう設計するとよいか、AI convention Markdownに何を追加すればAgentの誤解を減らせるか、といったことを考える段階に来ている。昨夜はmypyエラーが38個もあるファイルをAgentに任せて、15分ほど家族と話して戻ってきたら、Agentが修正内容とその理由を要約してくれていた。変更点の1つについて議論もしたが、結局はAgentの判断が正しいと考えた。mypyチェックも通った。今はチームにもこの技術の本当の可能性を理解してもらおうと努めているが、懐疑的な見方や、AIは完璧ではないという理由で反対する人もいる。だが友人の言葉を借りれば、「今日が、これから先あなたとこの技術が経験する中で最悪の日だ」という点こそが、まさに革新の証拠だと思う
type checkerエラーは、実際の開発業務の中ではほとんど時間をかけるべきでない部分のはずなので、その部分にそんなに長い時間が取られていたのか気になる。AI活用の議論について、各自が実際にどんな作業に使っているのかをみんなで見られれば（Cloudflareの投稿のように）、効果はずっと大きくなると思う
個人的にはPythonよりRustのコードのほうがAgentを信頼している。Pythonは静的解析のレベルがclippyやrust-analyzerほど高くないので、毎回すべてのコードパスを自分で実行して確認しなければならない
1日の半分が会議でもgit履歴だけでは分からないほどだと言っていたが、もし私があなたの会社の従業員なら、近いうちにその程度のアウトプットを継続的に期待するようになる点は覚えておく
ワークフローが気になる。Claude Codeを個人プロジェクトの実験用に使っていて、会社のアカウントではCopilotもVS Codeのagentモードで3.5、3.7 Sonnet、04-miniまでいろいろ混ぜて使ってみた。Goの大規模プロジェクトで活用したが、テスト周りを除けば結果は最悪だった。ツールの使い方が悪いのかと思って「最新のベストプラクティス」を一通り試し、コンテキストの調整、モデルの切り替え、ルール指定、プロンプト改善まで全部試したが、それでも改善はなかった
AI convention Markdownに、Agentのミスを減らす内容をさらに追加できると言っていたが、それは各作業ごとにコンテキストとして添付するファイルなのか、それともVS Code Copilot Agentの公式conventionなのか気になる。あと、文書構造を決める際に参考にした資料があったのか、それともAIが繰り返すミスをもとに時間をかけて自分で改善してきた成果物なのかも聞いてみたい
Agentic codingを効率的にする技術の多くが、人間のコーディング効率も高めてくれる点は本当に心強い。以前はAIだけが理解できる「巨大な泥団子」のようなコードになることが懸念されていたが、実際には逆だった。明確なコードはAIの生産性にとってもはるかに重要になり、そのおかげで生産性の差が数値としてはっきり現れるようになった。Claudeがコードベースごとにどれだけうまく動くかを数値で示せるので、コードがよく構造化されているかどうかという議論も、もはや意見の違いではなく客観的な根拠に基づいて話せる
コードが「泥団子」になるという心配は、実のところプログラミングでは昔から続いてきた悩みだ（Rich Hickeyの講演を見るとよい）。人は「今は楽に行こう」を選んで、翌日に莫大な技術的負債を抱えることになる。LLMのおかげで、意味もなくボイラープレートを量産することもさらに容易になる。痛みが減れば、そもそも直そうという発想自体が消えてしまうかもしれない
「AIだけが理解できるコードになる心配は、今はそうでなくても、今後どうなるかは分からない」という点もぜひ残しておきたかった
この部分には本当に共感する。優れたエラーメッセージ、高速なツール、安定したエコシステム、単純で「マジック」のないコード、直感的なSQLまで、もともと私が夢見ていた開発環境そのものだ。エージェントの仕事があまりにも速いので、小さな遅延ひとつひとつが体感できるほどで、こうした技術によって開発体験全体の水準が上がりうると思う
Agentを使っているとGoやTailwindへ自然に誘導される、という話を聞く。学習データが豊富なのでAIがきちんと扱えるからだという。では、誰もがこのツールを使う未来では、新しい言語やフレームワーク、ライブラリが登場しにくくなる現象が起きないだろうかとも心配になる。既存ソリューションと競争しにくくなり、StackOverflowのような人間コミュニティも消えてしまうかもしれない
新しい言語やフレームワークがまったく出てこなくなるという心配には同意しない。LLMは翻訳が非常に得意なので、学習データがなくても、独特でも構造が明快なフレームワークならコードベースを見てすぐに学習する力がある。実際、私のidiosyncraticなC#フレームワーク（誰も見たことがない）でも、LLMが非常にうまく扱うのを経験した。もちろんRustのライフタイムのような独特の特性はすぐには適応できないかもしれないが、Goのように単純なものならすぐ順応する。今後は新しい言語を作る際に、最初からLLM互換性（設計、ツーリング、ドキュメントなど）を考慮して作る必要があるのかもしれない
本当に重要な問いだ。言い換えると、LLM生成データでインターネットが覆われるにつれて質の高い学習データが減っていくわけで、LLMフレンドリーな開発者は昔の「放射能の少ない」古い技術（JS/Reactなど）により引かれるかもしれない。今後JavaScript/Reactが未来のCOBOLになっても高価なコンサルタントが不要な時代が来て、保守はすべてLLMができるようになるかもしれない。AIブームを避けたいなら、新言語開発、特にLisp+DSLのようなLLMがすぐには学習できない特異な言語は、AGI時代以前まではかなり安全かもしれない
ソフトウェアスタックの伝統的な循環構造は次のようなものだ。(1) 既存スタックがあらゆるニッチ分野まで抱え込んで複雑化すると、専門家が不要な「アトーテクチャ」を乱立させる (2) その結果、はるかに簡単で明快に新しいトレンドを解決する新しいシンプルなスタックが登場して人気を得る (3) 時間がたつと結局その新スタックも同じ問題で重くなり、この悪循環が繰り返される。AIコーディングでもコンテキスト拡張は急速に進んでいるので、このサイクルが簡単に壊れることはないと思う
GoやTailwindに強制されるという主張は、実際には書き手の個人的な傾向がかなり反映された見方だ。Sonnetがcargo test CLIで問題を起こしたからといって、Rustやcargo、もっと大きく言えばAI全体が問題だとは言えない。実際、PHPのテストでもJunieはbuilt-in runnerをうまく使えないが、bin/test-phpスクリプトを作ってやると、ちゃんと自分で使うようになる。要件をガイドラインに明示的に書いておくことは助けになるが、違いは標準提供ツールに固執する性質を持つという点だ。Stack Overflowの体験についても、私のAIアシスタントには質問を重複としてクローズしないという利点がある。SOのキュレーションの試みは良かったが、そのせいで多くのユーザーを遠ざけたのも事実だ
昨日もClaude（Zedを使用）にelixir phoenixの新規プロジェクトを、条件だけ渡して任せたが、問題なくきちんとやってくれた。CSSでtailwindを使っていたが、それはphoenixがデフォルトでそう設定してくれるからだと思う。AIがGoへ誘導するという主張には共感できない。むしろ文脈なしで聞くとPython寄りの提案があふれるし、コミュニティ規模の小さいelixirでも問題なく活用できている
Claude Code Sonnet 4.0でRustコードを1週間ほど試してみたが、期待以下だった（しかもBedrock経由なのでコストも高い）。最初の計画に時間をかける割に、実際には半分しか完了しないことが多い。自分が何か見落としているのか気になる
私もほぼ同じ感想だ。CursorのEdit/Agentモードでは、一度でほぼ望みどおりの修正が出てきて非常に効率的なのに、CLI環境ではあまりにも不便だ。Claude Codeに10〜15分の作業を任せてdiffだけをレビューする形で使っているのか、それともコードレビューもきちんとしているのか気になる
私もまったく同じ経験をした。使えるユースケースをわざわざ探し回って使ってみても、きちんと動かなくて本当に不思議だった
高いと感じるべきではない。Proプランは月20ドル、Maxは100〜200ドルで、APIで使ったときに月1000ドル以上かかるより安い構造だ
コンテナ利用への言及があったのはかなりうれしい。私はdagger/container-useに関わっていて、チームにはex-DockerのメンバーやDocker創業者もいる。Agentを並列実行することが、大きな技術進歩の分岐点になると思っている（信頼性高く活用できるようになれば）。それまでも、Agentの作業を走らせている間に自分が別の仕事をしたり、Agentが関係ない部分を触るのではと心配なら、開発環境をコンテナ化するのは非常に有用だ。コンテナ活用技術もまだ初期段階だが、非常に速い速度で進化しており、現在は安定性、git競合の削減、人間とAgentの相互作用の強化を重点的に改善している
言語選択についての私の考えはこうだ。1) Javaは、LLMが参照できる膨大な規模と長年にわたるデータセットのおかげで最も包括的だ（必ずしも最も正確という意味ではない）。2) 何より、自分が最もよく知っている言語で進めるべきだ。そうすれば、LLMの誤った推論、エラー、幻覚といったミスを素早く見抜ける
Javaが最も大きく、古く、明確なデータセットを持つという意見は、LLMがAPIやドキュメント、3rd partyのソースコードを探しに行くツールを使えない場合に限った助言のように思える。ツールが自動的に何を使うべきか見つけられるなら、どの言語を選んでも結局はAgentがソースを読めさえすればよい。だが2つ目の意見、つまり知っている言語を使うべきだという点には全面的に同意する。結局のところ人間による丁寧なレビューは必須であり、知っている言語ならエラーの判断もしやすい
なぜJavaが最大のデータセットなのだろうか。オープンソースプロジェクトではJavaが最も多いのか（Apache suite全体の影響？）、それともJavaのオープンソースライブラリは文書が非常に充実しているからなのか気になる
私はむしろ、Pythonコードのほうが最も多いデータセットなのではと思っていた。特に指定がないと、LLMはたいていPythonから提案し始める傾向がある
Goのcontext system（明示的なデータバッグで、コード実行経路に沿って流れるように設計されたもの）がAI agentに単純さを与えるという主張に対し、「tracing dataを除くデータをcontext.Contextに入れるのは実際にはよくない慣習だ」という批判がある
同意する。chromedp（Go向けのchrome headless driver）ではcontext.Contextを第1引数に使うが、単なるcontext.Background()ではなく、特別なfactoryから得たcontextだけを使わなければならない構造だ。timeout設定だけはcontext.WithTimeoutで別途処理し、ほとんどvoid*ポインタのように使っている
Goの専門家というほどではないが、実際にはライブラリがcontextにデータベース接続、設定、レートリミッタ、キャッシュバックエンドのようなデータを入れていることも多く、少なくとも今のところ自分にはそこまで問題には感じない
「AIが理解できるほど単純なコードを書く」というのは、私が期待していた革新ポイントではない。以前のugly codeに関する記事とどう衝突するのかも気になる
Claude Codeについて、書き手が述べていたように、さまざまな代替手段（OpenCode、goose、Codex、Devin、Cursor background agentなど）が実際に存在する。Claude Codeに似たオープンソース＋ローカルLLMソリューションが気になるという質問がある
現時点で強く勧められるオープンソース＋ローカルLLMソリューションは特にない。ただ、SSTのOpenCodeはUX面で急速に進化していて、今後より良いローカルモデルが出てくれば適用もしやすいと思う。最大の問題は、実際の「ツール使用」に優れた良いモデルがほとんどないことだ。Sonnetが驚くほど優秀なのも、ツール使用に特化した訓練のおかげだ。Geminiもまだかなり及ばず、結局は良いモデルさえ出れば解決する問題だと思う
Aiderは、ほぼそこまで来ているが、意図的に完全なagenticにはしていない。テストや静的解析の自動実行、自動エラー修正などはすべて可能で、to-doリストベースのプロジェクト全体の仕様も扱える。今はハードコードされたリフレクション反復回数（3回）の制限があるが、ハックすればいくらでも増やせるし、self promptingさえ追加されれば完全自動化agentにもなりうる
近くリリースする私のアプリも良い代替になると思う。単一ファイルのダウンロードで、インストール不要の構成によりMac、Windows、Linux、Dockerですべて使える。OpenAI API互換のあらゆるモデルが利用可能で（自前実行も含む）、ブラウザベースなのでClaude Codeに劣らないほど使いやすく、コマンドベースのコンソールアプリも作れる。さらにターミナルを直接開いてサービスに接続することもできる。今はクローズドアルファだが、使いたければメールをくれればよい
ほぼ毎日のように新しい代替手段（あるいは試作品）が出ているので、近いうちに「ぴったり合う」代替を使えるようになると期待している。たとえば app.build はNeon（現Databricks）チームが立ち上げたばかりで、かなり有望に見える
NeovimプラグインのCodeCompanionも最近はよりagenticな方向へ進化している。すでにauto-submit loop、組み込みツール、MCP統合機能をサポートしている。CLI独立ツールではないが、フルエディタ環境をそのまま使えるという利点のほうが大きい（特にハッキング、カスタム、軽量エディタ志向なら）
月100〜200ドルは、検証されていないコード作成AIとしては高すぎる。個人的な体験もそれほど満足できるものではなかったうえ、倫理的な論争まであるので、導入のハードルになっている
Claude CodeはAPIキーで使うか、月20ドルのProサブスクリプションに入ればよい
AiderをAPI課金体系で使ってみることを勧める。contextサイズの制御（
/clear,/add,/drop）で25K程度に制限できる。使いたいモデル（例: Sonnet 4, Gemini 2.5 Pro）を使える。簡単なスクリプトなら普通は1ドル未満で完成でき、大規模なツールを作る場合でも、プロンプト＋コード＋100件ほどのテストまで含めて6ドル未満で済んだ。AIでコードを書くことに慣れてきたら、そのときにClaude Code（より強力だが、頻繁に使わないとむしろ高くつく）へ移行するとよい20ドルの1か月サブスクリプションがあれば、小規模プロジェクトをいくつか試すには十分で、100ドルプランを検討するべきか判断できる。あるいは今後数か月待って、他の人の実運用レビューを参考にしてもよいと思う