ハクソク

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

エージェンティックコーディングの推奨事項

347日前原文(lucumr.pocoo.org)

概要

  • Agentic coding の実体験とワークフローを解説
  • Claude Code のSonnetモデルと効率的なツール運用
  • Go言語推奨 の理由と言語選定のポイント
  • ツール設計・運用 の具体例と工夫
  • シンプルなコード と安定したエコシステムの重要性

Agentic Coding実践記

  • Claude Code を中心にMaxサブスクリプション（月額$100）を利用
  • Sonnetモデル のみ使用、Opusより好結果
  • トークン効率 を重視し、スクリーンショットやブラウザ操作は極力回避
  • エージェントにタスクを一任 し、基本的に完了まで介入しない
  • IDEやAI統合の役割縮小、Vimの再活用
  • 技術進化が非常に速い ため、普遍的な原則のみを重視

基本方針

  • 全権限を付与 （claude --dangerously-skip-permissions使用、エイリアスclaude-yolo）
  • リスク管理 はDocker環境で実施
  • MCP（Multi-Component Protocol） は必要時のみ利用
    • MCPはツールアクセスの標準化プロトコル
    • Playwright-MCPでのブラウザ自動化など一部用途で活用
  • 独自ツールは通常のスクリプト として運用

言語選定

  • Go言語 を新規バックエンドプロジェクトで推奨
    • 明示的なContextシステム でAIエージェントが扱いやすい
    • テストキャッシュ によりエージェントループが高速
    • シンプルな文法 でLLMとの相性抜群
    • 構造的インターフェース で型推論が容易
    • エコシステムの安定性 で古いコード生成リスク低減
  • Pythonは非推奨
    • Pytestのマジックや非同期処理でエージェントが混乱
    • プロセス起動が遅く、エージェントループが非効率
  • フロントエンド はTailwind, React, Tanstack Query/Router, Viteを選択
    • Tanstack Routerのファイル名仕様（$param.tsxなど）がエージェント混乱の原因

ツール設計・運用

  • 全てがツールになり得る
    • シェルスクリプト、MCPサーバー、ログファイル等
  • ツールは高速応答が必須
    • クラッシュは許容、ハングは致命的
  • ユーザーフレンドリーな設計
    • 誤用時は明確なエラー出力で前進を促進
  • LLMの誤操作にも耐える堅牢性
    • 未定義動作やユーザーエラーを想定しない
  • デバッグ性・可観測性の確保

    • 重要ツールはMakefileに統合し、プロセスマネージャーも二重起動を防止

    • ログは常にファイル出力し、エージェントが自己診断可能に

    • 例：メール送信フローもstdoutログで完結、エージェントが自動でログ参照

スピード重視の工夫

  • 推論コストとツール応答速度がボトルネック
  • エージェント自身が一時的にツール生成 する場合も高速実行が必須
  • 遅い処理はデーモン化やホットリロードで対策
    • 例：Sentryのリロード遅延対策でPythonモジュールの動的読み込み
  • ログの冗長度調整も重要
    • 情報量とトークン効率のバランスをAIが制御可能に

安定性・コピペ・アップグレード

  • 安定したエコシステムが最優先
    • GoやFlaskはLLMとの相性良好
  • コードベースの安定性も重要
    • ライブラリアップグレードは慎重に
    • エージェントが残すコメントや設計意図が陳腐化しやすい
  • 依存よりも自作コード重視
    • シンプルな自作コードの方がエージェント運用に有利

シンプルなコードのすすめ

  • 複雑なコードより単純な実装が圧倒的に有利
  • 冗長でも明確な関数名・クラス回避・継承回避
  • SQLもORMより素直な記述がベター
    • エージェントがSQLログと照合しやすい

Agentic Codingの課題と今後

  • 進化速度が速く、現状のノウハウもすぐ陳腐化
  • 普遍的な設計原則とシンプルな実装が長期的に有効
  • エージェントの自律性を高めるには、ツール・ログ・エコシステム全体の設計が鍵

Hackerたちの意見

エージェントコーディングを効率的にする技術が、人間のコーディングも効率的にするっていうのは素晴らしいニュースだと思う。コードがAIしか理解できない巨大な泥玉になってしまうんじゃないかって心配もあったけど、逆のようだね。クリアなコードはAIの生産性にとって重要だから、今はさらに大事になってる。生産性の違いがすぐに客観的に測れるからね。AIが登場する前は、どのコードがうまく整理されているかは主に意見の問題だったけど、今は「コードベースAとコードベースBで、クロードがどれだけうまく動くか見てみて」って数字で示せるようになった。

└

「コードがAIしか理解できない巨大な泥玉になってしまうんじゃないかって心配もあったけど、逆のようだ。」今のところはね…

└

コードが大きな泥玉になるのではないかという懸念があった それはプログラミングにおいて常に心配されてきたことだよ（リッチ・ヒッキーのトークを見ればわかる）、そして今も問題だね。人々は「今日速く動く」ことを好むから、「明日10トンの技術的負債を抱えたくない」とは考えない。LLMは、人々がボイラープレートを生産するのをさらに簡単にしてしまって、なぜそんなに多くのボイラープレートを生産しているのかを再考することなく、一日中それを生産し続けることを可能にしてしまう。痛みがなくなったら、なぜ修正するの？

└

これには私も驚いた。良いエラーメッセージ、速いツール、安定したエコシステム、魔法のないシンプルなコード、ストレートなSQL…これが私がいつも求めているものだよね。エージェントが開発体験のハードルを上げるかもしれない。なぜなら、彼らはすごく速く動くから、どんな遅延も重要になるから。

エージェントを使うことで、ゴーやテイルウィンドを使わざるを得なくなる（少なくとも少しはそうなる）んだよね。これらはシンプルで、AIが正しく使えるほどトレーニングデータが豊富だから。これって、みんながこの技術を使う世界では、新しい言語やフレームワーク、ライブラリが出てこなくなるってこと？既存の選択肢と競争するのは難しすぎる。スタックオーバーフローみたいなプラットフォームで本物の人間に助けを求めることもできなくなるかもしれないし、彼らはすぐにいなくなっちゃうだろう。

└

成熟した合成データパイプラインがあれば、基本のLLMを一つ取って、20の異なるニッチ向けにファインチューニングして、APIコールの文字列パラメータでユーザーがそのニッチにアクセスできるようにできるんじゃない？たとえ昨日新しいバージョンの言語がリリースされたとしても、そのニッチの新しい構文を組み込むための合成トレーニングデータをすぐに生成できるだろうし、展開もできるはず。

└

僕のベストな結果は、Ruby/RailsとバニラBootstrap、またはTabler UIみたいなもので出てる。Tailwindも悪くないけど、やっぱり冗長さがあんまり好きじゃないな。安定したボイラープレートがあれば、数時間で素晴らしい結果が出せるよ。小規模なアプリにとって、本当にプロダクションレディなものだね。

└

これって、みんながこの技術を使う世界では、新しい言語やフレームワーク、ライブラリが出てこなくなるってこと？もしエージェントAIの可能性を本当に信じているなら、論理的な結論はプログラミング言語が21世紀のアセンブリ言語になるってことだね。これが不幸な現実になるかもしれないし、ならないかもしれない。

└

人間には読めないプログラミング言語とか、少なくともLLM向けにデザインされた言語が出てくるのかなって思ってる。

└

伝統的なデジタルスタックのライフサイクルはこんな感じだよ：1. 前の世代は、あらゆるニッチなシナリオをカバーしようとして膨れ上がり、専門家たちがアーキテクチャに夢中になって複雑になっちゃった。2. その結果、新しいスタックが生まれる。シンプルで基本に戻った感じ。すべてのニッチをカバーするわけじゃないけど、新しく人気のあることを簡単にやってくれて、これがデフォルトの環境になる。3. 時間が経つにつれて、新しいスタックも古いスタックと同じ理由で劣化していく。だからこのサイクルは繰り返される。AI支援のコーディングがあっても、これは変わらないと思う。コンテキストの強化が進んで、トレーニング後にフルスタックの仕様ができるようになってるから。

└

これって、みんながこの技術を使う世界では、新しい言語やフレームワーク、ライブラリが出てこないってこと？ それはすごくいい質問だね。言い換えると、良質なトレーニングデータが減っていく中で、LLMの再生産で溢れかえっているインターネットでは、「AIに詳しい」コーダーたちが、古くて退屈な言語や技術を好むようになるのかな？ 2020年代初頭の最も人気のある言語/フレームワークの組み合わせはJavaScript/Reactだよ。これが新しいCOBOLになるけど、2100年代には高いコンサルタントを雇わなくてもLLMがやってくれるから。補足として、AIブームから逃れるために、新しい言語をどんどん作り続けよう。マクロを多用したLispやカスタムDSLは、実際のAGIが君よりもマクロ展開が上手くなるまで安全だよ。

└

新しい言語やフレームワーク、ライブラリが出てこない？ これと同じ主張をしているYouTubeの動画があるよ。Reactは最後のJavaScriptフレームワークになるだろう、今はそれが支配的だからね。新しいフレームワークが発表されても、LLMのコーディングアシスタントは新しいフレームワークを使ったコーディングを手伝えないから、新しいフレームワークはユーザーや人気を得られないんだ。Reactに関しても、LLMは古くて確立されたReactの書き方しか知ってないから、新しい機能を追加するのは難しいよ。 https://www.youtube.com/watch?v=P1FLEnKZTAE

└

エージェントを使うと、GoやTailwindを使わざるを得ない（または少なくともそうなる）？ それは全然違うし、この記事は著者のバイアスをさらけ出してるだけだよ。例えば、彼らのClaude Code（Sonnet付き）の設定がcargo test CLIで問題を抱えているのは、AIやCargo、ましてやRust全般に関する根本的な問題じゃない。JunieもPHPのテストで内蔵のテストランナーを使えないみたいだけど、それがAIがPHPに問題を抱えているってわけじゃない。代わりにbin/test-phpスクリプトを書いて使わせたら、それを使う必要があるって理解したよ（ガイドラインでそう伝えると助かるけど、最初は内蔵ツールを使おうとする）。SOに関しては、私のAIアシスタントは質問を重複として閉じたりしない。SOがキュレーションに取り組んでいるのは評価してるけど、そのアプローチが人を遠ざけているのは確かだね。

└

これって、みんながこの技術を使うようになったら、新しい言語やフレームワーク、ライブラリが出てこなくなるってこと？ それはあまり考えられないな。こういうのは翻訳が得意だからね。トレーニングデータがなくても、独特だけどシンプルなAPIやフレームワークがあれば、コードベースを見て問題なく理解できるよ。自分の独特なC#フレームワークで経験したことだけど、LLMはそれに対してコードを書くのが得意なんだ。Rustのライフタイムみたいなものは、みんながLLMコーディングがすぐに動くことを期待する世界では、立ち上がるのが難しいかもしれない。でも、Goみたいな言語は簡単に受け入れられるだろうね。Rustの例でも、そんな新しいものの開発者は、設計やツール、ドキュメントの選択にLLMを考慮する必要があるかもしれないけど、それでも大丈夫だと思うよ。

└

昨日、Claudeにプロジェクトの概要と新しいElixir Phoenixプロジェクトを渡してみたんだけど、全く問題なかったよ。CSSにはTailwindを選んだけど、Phoenixはmix phx.newを使うときにそれをセットアップするから、たぶんそのせいだね。Goを使うように強制されるとは全然思わないな。むしろ、ランダムな質問をするときは、Pythonを使うように促されることが多い気がする。ElixirコミュニティはGoやPythonのサイズのほんの一部かもしれないけど、使うのに問題はなかったよ。

ここ一週間くらい、RustコードのためにClaude CodeをSonnet 4.0で試してるけど、あんまり期待外れだし（今はBedrock経由だから高いし）。何かをするたびに、最初に計画に時間をかけたのに半分もできてない感じ。何か見落としてるのかな？

└

全く同じ体験だ。ほかの人が何をしてるのか全然わからない。使い道を探してたけど、ずっと上手くいかなかった。理解できない。

└

高くなるべきじゃないよ - Pro（$20/月）やMax（$100または$200/月）を払えば、APIコストで>> $1000/月かかるものが手に入るから。

└

同じく。Cursor Edit/Agentモードでのワークフローはめっちゃ効率的で、頼んだ変更や機能をほぼ一発で実現してくれるんだ。CLIの中で作業するのは辛いよね。みんな、Claude Codeに10〜15分も回させてからdiffを確認してるの？コードをちゃんとレビューしてる人いるのかな？

VS Code Nightlysでコパイロットを使ってAgentic Codingに出会ったら、めちゃくちゃ生産的になったよ。半日が会議でも、Gitの履歴を見れば全然わからない。今は詳細から離れて、もう一歩上の視点で考えられるようになった。変更がうまくいってるかどうかをどうやって確認する？ このコードを理解できる？ どう構造を整えればもっと理解しやすくなる？ エージェントが間違った仮定を少なくするために、リポジトリのAI規約のマークダウンにもっと何か追加できる？ 昨夜は38個のmypyエラーがあるファイルをエージェントに渡して、15分間妻と話してた。戻ったら、エージェントが変更内容をまとめてくれて、なぜそうしたのかを説明してくれた。変更の一つについては議論したけど、最終的にはそれが正しいと判断した。mypyも通ったし、これでいける。今、チームにこの力を本当に理解してもらおうとしてる。懐疑的な人が多いし、AIはまだ完璧じゃないから、AI時代に反対する人たちはそれを根拠にするけど、正しい反応とは真逆なんだ。友達が言うように、「今日がこの技術で経験する最悪の日だよ」。

└

正直、Rustの方がPythonより信頼してる。Pythonは静的解析がclippyやrust-analyzerほど良くないから、全てのコードパスが実行されるように気をつけないといけないんだ。

└

リポジトリのAI慣習マークダウンに、エージェントが誤った仮定を少なくするために何か追加できることはありますか？無知をお許しください、これはエージェントの各ターンのコンテキストに追加するファイルですか？それともVS Codeのコパイロットエージェントの正式な慣習ですか？そのドキュメントの構造を決めるために使ったリソースがあれば教えてほしいし、AIが繰り返していたミスに基づいて時間をかけて洗練されたものなのかも気になる。

└

私のgit履歴からはわからないだろうね。どのコミットがAIによって生成されたかは、git履歴を見れば簡単にわかるよ。

└

昨夜、38のmypyエラーがあるファイルを持ってた。型チェッカーのエラーを修正するのは、やるべきことの中で最も時間がかからないはずだよ。これまでずっと時間を取られてたの？AIに関する議論は、みんなが実際にやってる作業を見えるようにできればもっと効果的になると思う（cloudflareの投稿みたいに）。

└

あなたのワークフローはどうなってるの？個人的にClaude Codeを使って遊んでるんだけど。主に実験用の新しいプロジェクトを作ってるよ。仕事を通じてCopilotのライセンスがあるから、先週はVS Codeのエージェントモードで遊んでた。普段は3.5、3.7 Sonnetか04-miniを使ってる。これは大きなGoプロジェクトの中での話なんだけど、テスト以外は全然ダメだった。ツールの使い方が間違ってるのかと思って、今までの「ベストプラクティス」は全部試した気がする。コンテキスト、プランニングとコーディングのためにモデルを切り替えること、ルール、より良いプロンプト。今のところ何も効果がなかったな。

コンテナの利用について言及されてるのを見るのは嬉しいね（https://github.com/dagger/container-use）。私はそれを作ったチームで働いてるんだ（元Dockerの人たちがたくさんいて、Dockerの創設者もいるよ）。エージェントを並行して動かすのは大きなポイントになると思う。エージェントが一つだけで信頼性を持って動く方法を学ぶまで、もう少し時間がかかるかもしれないけど。それ以前でも、エージェントが自分のことをやってる間に作業を進めたいなら、あるいはエージェントが勝手に何かを変えるんじゃないかと不安で「肩越し」に見てるなら、コンテナ化された開発環境で動かすのは便利だよ。コンテナの利用はまだ初期段階だけど、急速に進化してるし、この投稿が公開された時よりも改善されてると思う。今は安定性、gitの混乱を減らすこと、より良い人間とエージェントのインタラクション、環境のコントロールに集中してる。

https://github.com/dagger/container-use (cu) は日々改善中だよ。何か問題があれば手伝うから、気軽に声をかけてね（みんなdagger.ioのDiscordにいるよ）。昨夜、Amazon Q Developer CLIチャット（claude-3.7-sonnetを使って）で試してみたんだけど、前に触ったことがなかったんだ（今日はREADMEに使い方をPRする予定）。MCPの統合もうまくいったよ。Q用のエージェントルールをどこに置くか、cuのツールだけに制限する方法もわかったし、同じプロンプトでフラスクアプリプロジェクトを並行して3つのQインスタンスで修正したんだ（ローカルのソースに干渉しないように）で、短時間で3つのバリエーションをレビューできたよ。気に入ったものをリポジトリにマージして、残りは捨てた。

コンテキストシステム：Goは、Pythonや.NETの実行コンテキストのcontextvarsに似た、コード実行パスを明示的に流れるコピーオンライトのデータバッグを提供してる。その明示的な性質がAIエージェントにとって大きく簡素化されるんだ。エージェントが呼び出し先に何かを渡す必要がある場合、それをどうやってやるかを知ってる。これは悪いプラクティスと見なされていると思う。一般的には、context.Contextの値の唯一の健全な使用ケースはトレースデータであり、他のすべてのデータは引数を通じて明示的に渡すべきだというのが一般的な考え方だよ。

└

Goについてはあんまり詳しくないけど、今のところコンテキストを通して渡してるデータは、使ってるライブラリがよく使うタイプのデータだよ。データベース接続とか、設定、レートリミッター、キャッシュバックエンドとかね。少なくとも、特に悪いとは思わないな。

└

すべてのポイントに同意するよ。私がこのパターンに出会ったのは、chromedp、つまりChromeのヘッドレスブラウザドライバー用のGoラッパーだけだね。そのAPI…あんまり良くないよ。使うメソッドのほとんどはパッケージのグローバルで、最初のパラメータにcontext.Contextを取るんだけど、そのコンテキストは特別なものなんだ。context.Background()みたいな普通のコンテキストは渡せないから、ファクトリーメソッドのどれかから取得したコンテキストを渡さないといけない。タイムアウトを指定したいなら、context.WithTimeoutを使うんだ。賢いとは思うけど、それが機能する設定はそれだけだよ。基本的にはvoid*みたいなものだね。

言語の選び方についての私の意見: 1) JavaはLLMが参照するためのデータセットが一番大きくて古くて明確だから、最も徹底してる可能性が高いし、正確でもあるかもしれない。2) 自分が一番得意な言語を使うべきだよ。そうすれば、LLMが間違ってるときや、推論に欠陥があるとき、幻覚を見てるときに気づきやすいからね。

└

LLMが参照するのは一番Pythonのコードが多いと思ってた。指定しないと、ほとんどPythonがデフォルトになるしね。

└

JavaはLLMが参照するためのデータセットが一番大きくて古くて明確だよ。 それって、APIやドキュメント、サードパーティのソースコードを調べるツールにアクセスできないLLMでコーディングすることを勧めてるように見えるね。「エージェント的コーディング」のために選ぶものではない気がする。ツールが自動的に正しいものを見つけられるようになったら、どの言語を使うかはあまり重要じゃなくなるよ。エージェントが必要なときにソースコードをどこかで読める限りはね。ただ、あなたの2番目のポイントには同意するよ。すべての出力は慎重にレビューする必要があるし、自分がよく知ってる言語を使うのが一番いいよね。

└

なんでだろう？オープンソースのJavaプロジェクトって、すごく大きなコードベースがあるのかな（思いつくのはApacheの全体かな）？それとも、特定のOSSライブラリのドキュメントがめちゃくちゃ詳しくて表現力豊かだから？

最近、Pythonコミュニティの別のメンバーと話をしたんだけど（OAはPython界の有名な人が書いてる）。彼は「AIを使ってコーディングを学ぶのは、メニューから注文して料理を学ぶようなものだ」と言い始めたんだ。彼が言いたかったのは「AIがコーディングを学ぶ手段になる」ということなんだけど、もう一つの意味について考えてることがあるんだ。16歳の息子がコーディングにハマってて、彼がプロとしてやっていくためにどうサポートできるか考えてるから。「AIと一緒にコーディングを学ぶ」というのは本当に面白い問いだと思う。2〜6年後の世界はかなり変わるだろうし。問題のスレッドはこちら: https://bsky.app/profile/alsweigart.bsky.social/post/3lr6guv...

└

この議論は、新しい学生を最初から平凡なカテゴリーに押し込んでる気がする。ファブリス・ベラールに「あなたは十分に生産的じゃない」って言いたいの？もし、彼らを使い捨ての工場労働者に育てたいなら、ベルトコンベアで働くように教えればいいんじゃない？

ダークモードはページの一番下じゃなくて、上の方にあった方がいいんじゃないかな。個人的にはそれが好きだし、自分のHTMLブログでもそうしてる。好みの問題かもしれないけど、ゴーランは結構クールだと思う。でも、Pythonの知識ベースの方が充実してる気がする。たまに、ブラウザ内でPythonとAI Gemini Proを使って、クールなスクリプトを一発作ったりしてるよ。すごくいいね！