- AIコーディングアシスタントの中核構造は複雑な魔法ではなく、約200行のシンプルなPythonコードで構成される
- システムはLLMとの対話ループをベースとしており、LLMがツール呼び出しを要求すると、ローカルコードがそれを実行して結果を再び返す
- 必要な基本ツールはファイル読み取り(read)、ファイル一覧(list)、**ファイル編集(edit)**の3つで、これによりプロジェクトの探索とコード修正が可能になる
- LLMはツールの**シグネチャと説明(docstring)**をもとに、どのツールをいつ呼び出すかを自ら判断する
- この構造はClaude Codeのような商用製品の中核と同じであり、シンプルな構造でも強力なコーディングエージェントを実装できる
コーディングエージェントの基本概念
- コーディングエージェントはLLMとの対話ベースのシステムで、ユーザーの命令を受けてツール呼び出しを通じて実際のファイル操作を行う
- ユーザーは「hello world関数を含む新しいファイルを作成」といった要求を入力する
- LLMは必要なツール呼び出しをJSON形式で応答する
- プログラムがそのツールを実行し、結果を再びLLMに渡す
- LLMはファイルシステムに直接アクセスせず、要求だけを行い、実際の作業はローカルコードが処理する
必要な3つのツール
- read_file: 指定されたファイルの全内容を読み取って返す
- list_files: ディレクトリ内のファイルとフォルダの一覧を返す
- edit_file: 既存の文字列を新しい文字列に置き換えるか、
old_strが空なら新しいファイルを作成する
- 置き換える文字列がない場合は「old_str not found」を返す
- この3つのツールだけでもファイルの作成、修正、探索が可能
ツール登録とLLM統合
- すべてのツールはTOOL_REGISTRYに名前と関数として登録され、LLMが呼び出せる
- 各ツールのdocstringとシグネチャを抽出してLLMに渡す
- システムプロンプトはLLMに「利用可能なツール一覧」と「呼び出し形式」を明確に伝える
- ツール呼び出しは
'tool: TOOL_NAME({JSON_ARGS})'形式に制限される
- ツール実行結果は
tool_result(...)の形でLLMに渡される
ツール呼び出しのパースとLLM応答処理
- LLMの応答から
tool:で始まる行を探し、**ツール名と引数(JSON)**を抽出する
- 各ツールを実行した後、結果をJSONとしてシリアライズして会話履歴に追加する
- execute_llm_call関数はLLM APIを呼び出し、応答テキストを返す
- run_coding_agent_loopはユーザー入力を受け取り、LLMとの対話ループを維持する
- 内部ループは、LLMがそれ以上ツール呼び出しを要求しなくなるまで繰り返す
実行例と拡張可能性
- 例の会話:
- 「hello.pyファイルを作成してhello worldを実装して」→
edit_file呼び出しで新しいファイルを作成
- 「hello.pyに2つの数を掛ける関数を追加」→
read_fileの後にedit_fileを呼び出し
- 約200行のコードで完全なコーディングアシスタントを実装可能
- 商用製品では、ここにエラー処理、ストリーミング応答、コンテキスト管理、追加ツール、承認手順などが加わる
- 中核構造は同じで、LLMが決定し、コードが実行するシンプルなループで構成される
実践と拡張
- 全ソースは約200行で、他のLLMプロバイダーへの切り替えやツール追加で拡張できる
- シンプルな構造でも強力なAIコーディングエージェントのプロトタイプを自分で実装できる
1件のコメント
Hacker Newsの意見
追加したいのは planning だ。
効果的なツール利用の鍵は、これらが 動的なTODOリスト の上で動作していると気づく瞬間にある。
Planモードは、そのリストがどうシードされ、各項目がいつ実行されるかをブートストラップする役割を果たす。
ユーザーとのやり取りは、そのリストを並べ替える形で機能する。
先月、Claude CodeがCTF問題をどれだけうまく解けるか実験したが、TodoListツールとplanningを切ると性能が1〜2段階落ちた。
関連動画は Breaking Bots: Cheating at Blue Team CTFs with AI Speed Runs を参照。
興味深いのは、多くの人が「planモードを使うかどうか」にばかり注目する一方で、TODOリストは常に有効だという点だ。
また、「スマートなコンテキスト管理」を単なるTODO項目として片付ける記事を見ると、少し笑ってしまう。
自分で実装しようとして、本番環境で壊れる評価結果 のせいで1年を無駄にすることも多い。
これを単純にreasoningトークンとして追加することもできるが、実際には 明示的な単一キー保存ツール として実装したほうが、はるかに予測可能で効果的だ。
言語構造を保存する他のツールのアイデアにも、こうした単純なアプローチは通用しそうだ。
Codexをテストしながら、仕様を10分ほど整理して変更リストに分け、それをファイルとして保存させたうえで、各変更後に計画を見直し・修正するよう指示した。
こうするとLLMは 短い目標指向の作業 に集中でき、継続的なプロンプト入力も不要になる。
実質的にサブエージェントを置くのに近い効果がある。
最後のtodoとして「作業全体を見直し、linterなどで品質を確認せよ」と指示することもある。
コンテキスト圧縮時には、セッションの 簡潔な表現 としても使われる。
コーディングエージェントの核心は、実際には単純な ループとツール呼び出し構造 だ。
ただし、「The Emperor Has No Clothes: How to Code Claude Code in 200 Lines of Code」のような記事を書くなら、Thorsten Ballの How to Build an Agent は必ず参照すべきだ。
あの記事が「エージェントの本質は単純だ」というアイデアを最初に示した。
もちろん実際にはTODOやさまざまな 足場作り（scaffolding） が必要で、Claude Code自体にも複雑な設定やプラグイン、UI機能が多い。
それでも最小限のループさえあれば、自分で機能拡張するようブートストラップすることもできる。
内部動作を見たければ、claude-trace でLLMとツール呼び出しの相互作用を追跡できる。
単純なループ以外にも、uuidスレッディング、メッセージキュー処理、ファイル変更スナップショット、サブエージェントのサイドチェーンなど複雑な要素が多い。
そのため「200行」は概念的には正しいが、実際のプロダクション水準ははるかに複雑だ。
Codexにはまだキューイング機能がないが、それでもなお強力だ。
私は Contextify というmacOSアプリを作り、Claude CodeとCodexのCLIトランスクリプトをリアルタイムで監視し、Total Recall 機能で会話履歴を問い合わせられるようにした。
Claudeモデルは独自の str replaceツールスキーマ で訓練されている。
ファイル全体を書き直すのは非効率なので、部分修正が鍵になる。
実際にはもっと多くの要素がある。
たとえばエージェントが early stopping を起こして作業を終えてしまうことがある。
最新のreasoningモデルでも解決しない。
Claude Codeは、各プロンプトにTODOを注入して残作業を思い出させることで対処している。
HolmesGPTの公開リポジトリにはさまざまな実験ベンチマークがある。
「LLMにツール一覧と呼び出し形式だけ教えればよい」という概念は、最初は衝撃的だった。
LLMは単にテキストを生成するだけなのに、どうやってツールを呼ぶのかと思っていたが、それがすべてだと気づいたときは魔法のようだった。
休暇中にOpusでProlog DSLベースのコーディングエージェントを作ってみたが（200行は超えた）、
驚くほどほぼすぐにうまく動いた。
最新世代のモデルは、エージェントハーネスの重要性が下がる段階 に到達したように見える。
関連実験は この投稿 を参照。
1年前ならこの記事はかなり正確だったが、今はハーネスが大きく進化していて、単純ループモデルだけでは Claude Codeの実際の動作を説明しにくい。
単純なエージェントでも同じモデルを使えば性能差はそれほど大きくない。
ちょうど「自前でDBを作る」チュートリアルが基本的なB-treeを見せるのに似ている。
SubagentやMCP、Skillsは中程度で、コンテキスト最適化は長時間実行でのみ意味を持つ。
私は企業向けの エージェントループ を自前で構築しており、月間10億トークン超を処理している。
単純なループが核心なのは確かだが、実環境では無数の細部が複雑さを爆発的に増やす。
たとえば、ユーザーが途中でメッセージを送ってきたらループをどう処理するか、Slackのような Webhook入力 をどう同期するか、
承認・ガードレール・非同期Task処理など、考えるべきことが多い。
こうした経験をブログにまとめてみようかと思っている。
参考になる記事として You Should Write An Agent と How To Build An Agent がある。
私たちのSWE-benchチームは、100行のオープンソースエージェントを公開した。
mini-swe-agent で、学界と業界の両方で人気が高い。
エージェントの世界を学ぶには良い出発点だ。
2023年には「LangChainを100行で再実装する」という記事があり、
その記事 を見て実際に実装し、いくつかのプロジェクトで活用した。