ハクソク

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

コーディングエージェントの構築方法

275日前原文(ghuntley.com)

概要

  • AIコーディングエージェント の構築は 非常に簡単 で、約300行のコードで実現可能
  • エージェントの仕組み と 内部動作 の基本理解が、AI利用者から生産者への転換点
  • エージェント化LLM選定 や コンテキストウィンドウ管理 が成功の鍵
  • AI自動化スキル は2025年以降のIT業界で 必須知識
  • 過剰なMCPツール導入 や コンテキストウィンドウの使い過ぎ に注意

AIコーディングエージェント構築ワークショップ概要

  • GitHubリポジトリ （ghuntley/how-to-build-a-coding-agent）にて 教材・ソースコード を公開
  • Roo code、Cline、Amp、Cursor、Windsurf、OpenCodeなどの 類似エージェント の基本構造を解説
  • 約300行のコード でエージェントを構築可能
  • エージェントは LLMトークンをループ処理 で投げ続けるシンプルな仕組み
  • ライブコーディング形式 で、基本から実践までを丁寧に解説

エージェントの重要性と業界動向

  • 2025年には AI支援による同時並行作業 が業界標準
  • 会議中や離席時でもエージェントによる自動作業 が可能
  • AI活用できない人材 は、今後の雇用市場で不利
  • AI自動化スキル は、SQLのプライマリキー知識と同等レベルの 必須スキル
  • CanvaやSourcegraph など先進企業では、 AI活用経験者 を積極採用

エージェントの仕組みとLLMの選定

  • Cursor, Windsurf, Claude Code, GitHub Copilot, Amp などは LLMトークンループ の実装例
  • エージェント化LLM には「高安全型」「低安全型」「オラクル型」「エージェント型」の 4象限 が存在
    • 低安全型（例：Grok）はリスク許容度が高く、研究用途向き
    • 高安全型（例：Anthropic, OpenAI）は倫理重視
    • オラクル型は要約や高次推論向き
    • エージェント型（例：Claude Sonnet, Kimi K2） は行動重視
  • 複数LLMの連携 （例：Claude Sonnet＋GPTによるオラクル機能）はAmpで実装済み

コンテキストウィンドウとMCPの注意点

  • コンテキストウィンドウ は実質176kトークン程度（Sonnetの場合）、システムプロンプトやツール用に一部消費
  • セッションごとに コンテキストをクリア する運用が重要
  • MCP（Model Context Protocol） は関数呼び出しの説明をウィンドウに割り当てる仕組み
    • MCPツールやサーバーの 過剰導入は逆効果
    • 割り当て量が多いほど パフォーマンス低下・精度劣化
  • 「Less is more」 を意識した設計・運用が推奨

まとめとキャリアへの示唆

  • AIエージェント構築スキル は今後の エンジニア必須能力
  • 業界変化のスピード に対応するため、 自己投資・学習継続 が不可欠
  • エージェント未活用層 は、今後ますます「ngmi（not gonna make it）」化
  • AIによる自動化 は、 個人と組織の生産性向上 の鍵
  • 詳細解説やワークショップ希望 はGeoffrey Huntleyまで連絡推奨

LLMとエージェントの選び方・使い方

  • LLMには特性がある ため、目的に応じた選定が不可欠
    • 研究・探索なら Grok
    • 倫理重視や安全性なら Anthropic/Claude Sonnet
    • 行動重視・自動化なら Claude Sonnet, Kimi K2
  • 複数LLMの組み合わせ で、 高次推論と自動化 の両立が可能
  • MCPツールの数や割り当てトークン量 を適切に管理することが重要

今後のアクション

  • GitHubリポジトリ で 教材・サンプルコード を確認
  • 自分自身でエージェントを構築・運用 してみる実践
  • AIエージェントの基礎知識 を深め、 業務自動化 のアイディア創出
  • 業界変化に敏感 になり、 学習・適応 を継続
  • ワークショップ・追加情報 はGeoffrey Huntleyへ問い合わせ推奨

Hackerたちの意見

私たち（プリンストンのSWE-benchチーム）は、約100行のコードでSWE-benchでうまく動くエージェントを作ったよ。きっと楽しめると思う！: https://github.com/SWE-agent/mini-swe-agent

└

ありがとう、追加しておくね。

└

なるほど、確かにシンプルだね。共有してくれてありがとう。全体はこれらのプロンプトで動いてるよ: https://github.com/SWE-agent/mini-swe-agent/blob/7e125e5dd49... あなたのタスク: {{task}}。三重バックティックで囲んだ一つのシェルコマンドで返答してね。最後に、シェルコマンドの出力の最初の行は「COMPLETE_TASK_AND_SUBMIT_FINAL_OUTPUT」でなきゃいけないよ。

└

問題がファイル内に完全に自己完結している場合、LLMで編集するのはすごく簡単だよね。でも、コードベースだと、開発者が考えていた特定の組織モデルに合わせて、いろんなところに散らばってるから、そうはいかないんだ。

└
  1. コードベースを分析して関連ファイルを見つけて読む 2. 問題を再現するスクリプトを作成する 3. 問題を解決するためにソースコードを編集する 4. スクリプトを再実行して修正が機能するか確認する 5. 修正が堅牢であることを確認するためにエッジケースをテストする このプロンプトのスニペットはすごく役立つよ。デバッグループから抜け出すためにこんな感じのを使ってる: > コードベースを分析して、問題の潜在的な根本原因のリストをブレインストーミングし、最も可能性の高いものから低いものへとランク付けする。その後、スクリプトを作成するか、仮説が正しいか確認するためにデバッグログを追加する。スクリプトを実行して出力を観察しながら、最も可能性の高いものから低いものへと根本原因を排除していく。
└

自分のコードベースで動かしてみた結果はどうだった？

└

いいけど、ツールが足りないのが残念。ほとんどのコードがエージェントフレームワークに関するもので、SWEに特化してないね。俺もSWEエージェントを作ったことあるよ（遊びでね）、見てみて => https://github.com/myriade-ai/autocode

プログラム合成はどこにあるの？私の考え方は、ツールとしてのプリミティブを与えられたら、モデルにプログラムを構築して実行するために返してほしいってこと。もちろん、nixの哲学に従うのも別の方法だね。

bashツールを超えるツールは本当に必要なの？ファイルのリスト表示、リポジトリの検索、ファイルの編集は全部bashでできるんじゃない？それとも、これは https://news.ycombinator.com/item?id=45001234 で示されてることなの？

└

別々のツールにする方が、全部をbash経由にするより簡単だよ。もし全部がbashを通るなら、常に安全なコマンド（例えばファイルのリスト表示）と、ユーザーの承認が必要な他の潜在的に危険なコマンドを分ける方法が必要になる。ファイルのリスト表示を別のツールにすれば、エージェントがプロジェクトディレクトリの外のファイルをリスト表示しないように強制できるよ。

└

人間はシェルで何でもできるのに、なぜIDEが必要なんだろう？インターフェースは、特定の瞬間に必要な情報や取れるアクションを提供してくれるんだよね。

└

「bashツール以外のツールが必要なのはなぜ？」って？俺の推測では、最初は限られたツールセットから始めて、後でbashを使えばいいことに気づいたんじゃないかな。

└

技術的に言えば、Bashツールだけでもやっていけるし、俺もそれで成功したことがあるよ。エージェントからツールを取り上げて、どれだけクリエイティブに使うかを見るのは結構面白い。別のツールを与えるとパフォーマンスが良くなる理由の一つは、これらのツールを使った強化学習がSonneで行われているから。モデルはこれらのツールの使い方を理解していて、トークン効率も良く、一般的にそのアクションを実行するのがずっと成功しやすいんだ。例えば、Bashツールは時々bashismsに混乱して、引数を正しくエスケープできなかったり、ホワイトスペースを正しく処理できなかったりすることがあるよ。

└

これは「3.2 良いツールをデザインするには？」で説明されてるよ。これでLLMが何度も低レベルなクリックやタイピングをしなくて済むし、ちゃんと進めるんだ。モデルを助けてあげてよ、頼むから！

エージェントの作り方について書く代わりに、そのエージェントが作ったプロジェクトを見せてほしいな。

似たような「ハウツーガイド」はここにあるよ https://ampcode.com/how-to-build-an-agent、Thorsten Ballが書いたもの。一般的にAmpは結構面白いよね。もう隠れた宝石ってわけじゃないけど、エージェントコーディングに関するツールがもっと公開されるのは嬉しいな。将来的には、似たようなエージェントアプローチが（特定の/多くの？）ソフトウェアスーツの一部になるだろうし。

└

理解できるね、著者はAmpでも働いてるって言ってるし。

└

GhuntleyはAmpでも働いてるよ。

メタコメントはしたくないけど（内容は初心者向けの良い導入だよ！）、最近見た中で一番ひどいAI混じりのプレゼンだと思う。なんで間に不要なAI生成の画像があるの？箇条書きにできたことをそれぞれ個別の画像にする必要があるの？（AI生成じゃなくても）視覚的にすごく気が散るし、読む流れが壊れるし、全ての画像に代替テキストがないからアクセスしづらい。--- カンファレンスのトークに基づいてるみたいだから、スライドをそのまま使ってるのかもね。そうなら、これじゃなくてカンファレンスの元の形式で出してほしいな。

└

同意。読めないよ。

└

うわ、そうだね。読めないわ。イライラと不満がすぐに高まって、パワーボタンに手を伸ばす前にページを閉じちゃった :)

コーディングエージェントを作るには、明確な目標を定義して、AIを活用し、フィードバックに基づいて反復することが大事。簡単なタスクから始めて、徐々にスケールアップしていこう。

一枚の画像は通常1000の言葉に値するけど、これに使われてる画像は99.6%の割引だね。何これ…？

└

これはカンファレンスのワークショップで、これがワークショップのスライドで、言葉はそのプレゼンテーションのディクテーションだよ。

現在のCLIで、インタラクティブじゃないオプションがあって、Claude Codeと同じくらいの性能で、OllamaやOpenRouterみたいな他のLLMとも連携できるのって何かある？ Aiderみたいなのも試したけど、ファイルを見つけられないし、オープンソースのGeminiもひどかった。Opusを使ったらCCと同じくらいの良いものって何かあるかな？

└

そんなに試したわけじゃないけど、LLM CLIはまあまあいい感じだと思うよ。

知識を得るために自分で作るってのが、まさに俺のアプローチだね（npx genaicode）。地元のミートアップで自分の作品を発表したときに、まさにこの質問が来たんだ。「なんでCursorを使うんじゃなくて、これを作ってるの？」って。答えはこの記事に書いてあるよ（要約すると、変革的な体験）。ただ、いくつかの部分はもう古くなってるか、すぐに古くなると思う。技術が毎日進歩してるからね。