ハクソク

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

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

2025年6月12日原文(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

Hacker Newsで議論の続きを見る