⌨️
Coding Agentについてのまとめ (2026年1月)

2026/01/26に公開
こんにちは！逆瀬川 (@gyakuse) です。
改めてCoding Agentについて理解するために自分が見聞きしたこと、理解していることなどを全部出力してみることにしました。Coding Agentを理解するためには歴史を紐解き、OSSの実装を読み、実装してみる必要がありそうだな〜と思ったので全部やってみました。Coding Agentの使い方なども載せているので、ぜひ参考になれば嬉しい気持ちがあります。

 何を書いている記事かCoding Agentの歴史
Coding Agentの現代的テクニック
Coding Agentを使いこなす
Coding Agentの個人的な使い方
Coding Agentを実装してみる
Appendix 1: 主要OSSの詳細
Appendix 2: 関連論文紹介
ちょっと長い記事ですが、これを読めばCoding Agentを使いこなせるだけではなく、自分で作ってみることができるようになります。Filesystem + CLIから成る現在のCoding AgentはCLI環境における汎用Agentとみなすことができると考えています (ゆえに、AnthropicもCoworkなどを出してきたと考えています)。なので、Coding Agentを作りたい人だけではなく、これからの時代のAgentを作りたい人にもオススメです。

 Coding Agentの歴史さて、最初は歴史から見ていこうと思います。前日譚となるお話はetherraさんの AIがコードを書く時代になるまでの90年をまとめてみた がかなりいい記事かつ論文を大量に引用していてめちゃよいのでオススメです。ここでは、より要約的に、2021年ごろからの製品を中心に見ていこうと思います。

 年表

リリース時期
アプリケーション名
備考


2018年
Tabnine
初期はn-gram等での補完

2021年3月
GitHub Copilot
OpenAI Codexによる補完

2022年12月
ChatGPT
対話形式でのコード生成が可能に

2023年3月
Cursor
初期はCopilotのようなコード補完が中心

2023年4月
AutoGPT
AgentによるCoding

2023年7月
MetaGPT
分業化されたソフトウェアエンジニアリング

2023年7月
ChatGPT Code Interpreter
Sandboxにおける任意処理用Pythonコードの作成・実行

2023年7月
Open Interpreter
Code InterpreterのOSS版 + α

2024年3月
Devin
Coding Agentのshell利用の一般化

2024年7月
Cline


2024年11月
Windsurf


2025年2月
Claude Code


2025年5月
Codex（OpenAI）


2025年11月
Google Antigravity



 LLMによるコード補完の登場 (2021年)GitHub Copilotの登場
我々がよく知るLLMによる支援はまず GitHub Copilot から始まりました。これはGPT-3 (OpenAI Codex, 現在のCodexと名前が同じで本当にややこしい) をベースとしたコード補完システムで、タイピングをしていると自動的にその行の続きを予測してくれるものです

autocompleteとの違い
それ以前にもIntelliSenseのようなautocompleteがありましたし、より進歩したn-gramなどを用いたものはありましたが、LLMをベースとしたものはTabnine (Tabnineは初期はn-gramモデル) やCopilotからとなります


 チャットベースのコードアシストの時代 (2022-2023年)ChatGPTの登場
ChatGPT以降、チャットによる対話形式でコードを書いてもらうアプローチが一般化しました。これは現代でも使われる基本的なアイデアとなります
Coding AgentではAgentが関連ファイルの探索をしコンテキストを構築してから実装しますが、チャットベースでは人間がこれを行い、コンテキストを構築して実装したものをファイルに貼り付けるという作業をしていました


 エージェントの模索時代 (2023年)Context Windowの拡大
2023年3月にGPT-4が登場し、Context Windowは8kまで伸びましたが、複数のファイルを参照するには非常に限定された空間でした。よって、Contextに重要な情報をどのように詰め込むか、という問題探索が活発化しました。

Code Interpreter / Open Interpreterの登場
GPT-4でCoding能力が飛躍的に伸びたおかげでJupyter Notebookに書くようなスクリプトくらいは余裕で出力できるようになりました。Code InterpreterはGPT-4の出力したスクリプトをSandbox環境で実行するものです。簡単なデータ分析や処理ができるようになりました。
Open InterpreterはそれをOSSにしただけではなく、以下の試みがありました (以下は初期のOpen Interpreterについて)

python と bash の2つの環境で動く
pythonコードブロックをLLMが出力したらpythonのREPL環境にそれが流し込まれる (特定のPythonファイルを作成している訳では無い)


Open Proceduresを用いた簡易RAG
Open ProceduresとはPythonのスニペットを自然言語で検索できるサービス(Open Interpreterチームが作成)。Open Interpreterでのリクエストをここに投げスニペットを得てLLMの実装能力を改善させる試み

現代的なフレームワークの実現
ReActのように計画し実行され、結果がContextに積まれました
コンテキストの溢れ対応: REPLでの実行結果が2000文字より大きい分は削り、また特定の文字数を超える場合は先頭のメッセージを削除していました
明らかにヤバい方法ですが、「現状のプランを常に最新の返答に含めよ」というシステムプロンプトによってうまく動いていました。先頭にプラン情報があるのは現代でも同様です

終了判定: LLMの返答にコードブロックが含まれなくなったら完了という簡単な判断基準を持っていました




Cursorの登場
Cursorの進歩を見るとだいたいCoding Agentの進歩がわかります。めっちゃ頑張ってる。
2023年3月: 初期はGitHub Copilotと同様のコード補完機能がついたものでした
2023年4月: CodemirrorベースからVSCodiumのフォークへ移行
2023年6月: @symbols 対応. 特定のファイル等を参照可能に
2023年6月: コード全体をembeddingでindexにし、RAGでの回答ができるように
2023年10月: Interpreter Mode (Code Interpreterのようなもの) 対応、Bash Mode (bashコマンドを使用して簡単な処理をする機能) 対応
2024年1月: @web 対応. Web検索可能に
2024年7月: Composerの登場. 現代的なCoding Agentに
2024年12月: Agent in Composer, Yolo mode対応 (ターミナルでのAIの自動運転許可)
2025年1月: MCP対応
2025年2月: Agent Modeのデフォルト化
2025年7月: 実装前にTODOリストを作成する機能の追加
2025年9月: ブラウザを使ったテスト・デバッグ対応、プランモード(TODOモードよりより詳細な実装前の実行計画策定) 対応
2026年2月: SubAgentとAgent Skills対応

Cursorの特徴としては8k Context問題から出発したためにリポジトリ内のコード探索はRAG (semantic search) をベースとしているところがあります。ただし現在ではgrepと併用されています。

2023年10月のブログ ではコンテキストへの8kまでの圧縮についての挑戦が書かれていて面白いです。


AutoGPT
自律型なエージェントのアイデア
目標だけ与えれば、AIが自律的に思考・計画・実行・修正のループを回して達成するようになりました

Thought / Plan / Criticism / Command
LLMは以下のような推論を行い、作業を実行しました。
Thoughts: 現在の思考
Reasoning: その理由
Plan: 次の計画
Criticism: 自分自身への批判 (Constructive self-criticism)
Command: 実行するコマンド (Google検索、ファイル書き込み、Python実行など)

Config.continuous_modeをTrueにすると、ユーザーの許可なしに無限にこのループを回し続けることができました


MetaGPT
SOP (作業手順書) の導入
MetaGPTは人間のソフトウェア開発会社のような標準作業手順書をワークフローに組み込みました

ロールプレイによる分業
ProductManager: ユーザーの曖昧な要求からPRD (製品要求仕様書) を作成
Architect: PRDを元にシステム設計とファイル構成を決定
Engineer: 設計書に基づきコードを実装
QaEngineer: テストケースを作成し品質を担保



 CLIベースの登場 (2024年)Context Windowの拡大
2023年7月にClaude 2が登場し、Context Windowが100kまで伸びました。また、Prompt Caching (Context Caching) 技術により、コストを抑えて推論する環境も整いました。OpenAIも後を追うようにgpt-4-turboをリリースし、100k以上の時代が到来することになります
これにより、複数のファイルを参照させ、AutoGPT, Open InterpreterのようにContextを積んでいくアプローチが一般化します

Devinの登場
SandboxにShell, Code Editor, Browserという武器を与えて動かすという非常に野心的な試みとして始まりました。現在まで続くCoding Agentの構成がここで出来上がります。

Cline, Windsurf, …
Cursor, Open Interpreter, Devin等の成功によって続々とCoding Agentが増えることになりました


 CLIベースの活躍と現場での活用 (2025年)Coding Agentの民主化
このへんでCoding Agentが実践され始めました。laisoさんの ClineとAIコーディングツールの現状 やmizchiさんの Clineに全部賭けろ がインパクトの大きいものとして印象に残っています。自分はこのあたりではまだ 最近のコーディングにおけるLLMの使い方QA に書いたようにコンテキストを自分で作り込んで送るアプローチを採用していました

MCP / Skillsへの対応
MCPが前年の2024年11月に発表され、各クライアントが続々と対応し、Coding Agentの手足が増えることになります。検索やブラウザの利用、さまざまな能力が付与されました。一方で、Context Pollution / Context Confusion の問題もあり、MCPの管理は課題として残りました。
Claude Skillsは2025年10月に発表されたものでのちにAgent Skillsになりました。Skillが包含するのは手順書のようなものであったり、ツールの使い方だったりさまざまです。MCPはtool実行→結果の返却でしたが、SkillsはこれをCoding Agentの実行環境によく接地したもので、失敗しても回復しやすいものになっています。Skillsでは最大100トークン程度の洗練されたdescriptionを最初contextに挿入し、必要なタイミングで使い方をloadするという Progressive Disclosure (段階的な開示) 戦略をとっており、Contextの汚染を最小限にとどめます。とはいえ、pipのようなレジストラがまだ安定して存在しないことなどが今後の問題として残ります。

プロダクトの増加
プロダクトとしては2025年2月にClaude Codeが、5月にCodex、11月にAntigravityと続々発表されました。


 Coding Agentの現代的テクニック主要なCoding Agent (調査対象はCline, gemini-cli, Kilo, OpenCodeとしました) のテクニックを見ていきます。詳細な分析手法や結果はAppendix 1を参照してください。
Coding Agentを作る場合だけでなく、他のAgentを作る場合にも役立つ知見です。

 System Instruction（システムプロンプト）の設計思想静的なプロンプトではなく、環境やモデルに応じて動的に生成・最適化する手法が標準化しています。
モジュール構造と動的生成: プロンプトを部品として管理し、実行時に組み立てます
構成要素: 役割（Role）、機能（Capabilities）、ルール（Rules）、ツール定義、システム情報（System Info）などに分割。
動的注入:
OS、Shell、CWD（カレントディレクトリ）などの環境変数を実行時に埋め込む。
プロジェクト固有のルール（.clinerules, .cursorrules, AGENTS.md）を読み込んで追加する。
モード別生成: KiloやOpenCodeのように、「Architect（設計）」「Code（実装）」「Ask（質問）」などのモードに応じて、プロンプトの内容と許可されるツールを切り替える。


モデルごとの最適化: LLMの特性に合わせてプロンプトや形式を微調整します
バリアント管理: Clineのようにモデルファミリー（Claude, GPT, Gemini）ごとに定義ファイルを持ち、得意な形式（XMLタグ vs JSON Schema）を使い分ける。
XML vs Native:
Native Tool Calling: OpenAI/GeminiなどAPIレベルで対応しているモデル向け
XML Tool Calling: Claudeや非対応モデル向けに、システムプロンプト内でXMLタグによるツール実行を指示する（例: <tool_code>...</tool_code>）
なお、ClaudeはStructured Outputに最近対応しましたがまだバギーです
https://platform.claude.com/docs/ja/build-with-claude/structured-outputs





 Context ManagementCoding Agentにとって最大のボトルネックである「コンテキストウィンドウ（トークン制限）」を管理するための戦略です
圧縮と要約: 履歴が長くなった際、単に削除するのではなく「意味」を残して圧縮します
自動要約: トークン使用量が閾値を超えた際、過去の会話履歴をLLM自身に要約させ、中間履歴を削除して「要約メッセージ」に置換する
Reverse Token Budget: gemini-cliの戦略。最新の履歴（約30%）は完全に保持し、それより古い履歴にある「巨大なツール出力」を優先的に切り詰める
Pruning（剪定）: 過去のファイル読み込み結果など、重複または古くなった情報を削除し、「読み込んだ事実」のみを履歴に残す

出力の最適化: ツール実行結果（Observation）がコンテキストを圧迫しないよう加工します
Truncation（切り詰め）: catやgrepの結果が数千行に及ぶ場合、自動的に先頭・末尾のみを残して切り詰める、あるいは一時ファイルに保存して「出力が長すぎるためファイルに保存しました」というメッセージに置き換える
重複排除: 同じファイルを何度も読み込んだ場合、最新の結果以外をコンテキストから削除する


 ツール設計と実行戦略単なるAPI呼び出しではなく、安全性と確実性を担保する設計になっています。
標準ツールの体系: 各OSSで共通して以下のカテゴリのツールを実装しています。
File Operation: read, write, replace (sed的な置換), apply_patch (diff適用)
Exploration: list_files (ls), search (grep/ripgrep), glob
Execution: run_command (shell), browser_action (Puppeteerによるブラウザ操作)
External: MCP (Model Context Protocol) サーバーへの接続による拡張, Agent Skills対応

安全性と承認プロセス (Human-in-the-loop)
Auto-approve vs User Confirm:
読み取り系（Read-only）は自動承認
書き込み系（Write/Execute）はユーザー承認を必須にする、または設定で「自動承認」を許可する

Policy Engine: gemini-cliのように、ツールの実行前にポリシーエンジンが介入し、Allow/Deny/AskUserを判定するレイヤーを持つ

編集の精度向上
Apply Patch / Diff: ファイル全体を書き換えるとトークンを浪費し、ミスも増えるため、search_and_replaceブロックやパッチ形式（diff）を用いて、変更箇所のみを適用する手法が主流
LSP連携: OpenCodeのようにLSP（Language Server Protocol）ツールを持ち、定義ジャンプや参照検索を正確に行う


 プランニングとワークフローいきなりコードを書かせないための制御機構です。
Plan Mode vs Act Mode
モード分離: 「計画（Plan）」と「実装（Act/Build）」を明確に分ける
Plan Mode: ファイルの書き込みを禁止（Read-only）。情報の調査、要件定義、計画の作成のみを行う
Act Mode: 承認された計画に基づいて実装を行う

Deep Planning: Clineのように、複雑なタスクに対して「調査 → 議論 → 計画書作成 → タスク化」という4段階のプロセスを経る

タスク状態の追跡: LLMに「今何をしているか」を見失わせないための工夫です
Focus Chain / Task Progress: ツール呼び出しのたびに、パラメータとしてtask_progress（現在の進捗率や次のステップ）を入力させることで、LLM自身に現状認識を強制する
TODOリスト管理: write_todosやupdate_todo_listツールを使い、コンテキスト内に常に最新のタスクリスト（Pending/In Progress/Done）を維持させる


 外部コンテキストの統合LLMが「見えないもの」を見るための情報注入技術です。
IDE/環境情報の注入
Editor State: 現在開いているタブ（Active Tabs）、カーソル位置、選択範囲のコードを自動的にプロンプトに含める
File Tree: プロジェクトのディレクトリ構造（treeコマンド結果相当）を常時、または動的にコンテキストに含め、ファイルの位置関係を把握させる
Terminal State: バックグラウンドで実行中のコマンドやその直近の出力を共有する

知識ベースの活用 (RAG/Memory)
プロジェクトルール: .clinerules や GEMINI.md などのマークダウンファイルを読み込み、プロジェクト固有のコーディング規約や慣習を遵守させる
スキル/ドキュメント: タスクに応じて必要なドキュメント（Skills）や内部ドキュメントを動的にロードする（Just-In-Time Context）


 完了判定いつタスクを終了するかを決定するメカニズムです。
明示的な完了ツール: LLMが「完了した」と判断した際に attempt_completion や complete_task ツールを呼ぶ。これによりUI上でユーザーに完了確認（承認/拒否）を求めるフローへ移行する
ユーザーフィードバックループ: ユーザーが完了を拒否した場合、そのフィードバックをコンテキストに積んで、再びAct Mode（修正作業）に戻る
while True 型エージェントで面白いのは完了ツール呼び出し型の場合、完了ツールを呼ばないでください (例: 「complete_task は絶対に呼び出さないでください」) とすると実装にもよりますが、容易に無限ループに陥ることです。めちゃくちゃたのしい。

 Coding Agentを使いこなすHackathon優勝者のClaude Code利用法から使い方を見ていきます。
https://x.com/affaanmustafa/status/2012378465664745795
https://github.com/affaan-m/everything-claude-code

 Subagentsによる分業体制MetaGPTのような分業体制をSubagentsで成立させています。
Planner (planner): 実装前に要件を整理し、リスクを評価し、手順書を作成するだけの人。コードは書かない
Architect (architect): システム設計やスケーラビリティを考える人
TDD Guide (tdd-guide): 「テストを先に書くこと」を強制し、Red-Green-Refactorのサイクルを回させる人
Security Reviewer (security-reviewer): コミット前に脆弱性やSecretの混入がないかチェックする人
例えば /orchestrate feature "認証機能の追加" のようなコマンドを叩くと、Planner → TDD Guide → Code Reviewer → Security Reviewer というバケツリレーが行われるように設計されています。

 コマンドによるベストプラクティスの強制よくやる作業をAgent Skillsとして定義し、短いコマンドで呼び出せるようにしています。
たとえば /tdd コマンドではAgentは以下の手順を強制的に守らされます。
インターフェース（型定義）を先に書く
失敗するテストを書く (Red)
最小限の実装をする (Green)
リファクタリングする (Refactor)
カバレッジが80%以上か確認する

 Hooksによる自動化Claude Code（やその他のCLIツール）には、ツールの実行前後などにスクリプトを走らせる Hooks という機能があります。
PreToolUse (実行前):

npm run dev などの長期間走るプロセスを検知したら、tmux で実行しろと命令
不必要なドキュメントファイル (temp.md とか) を作ろうとしたらブロックする

git push の前に確認を入れる

PostToolUse (実行後):

.ts ファイルを編集した後、自動的に prettier と tsc (型チェック) を走らせる

console.log が残っていたら警告を出す


 Continuous Learningセッションが終わるたびに このセッションから学んだ教訓を抽出し、次のセッションに活かす仕組みです。
Observation:
セッション終了時、うまくいかなかった点やユーザーからの修正指示を分析する

Extraction:
「このエラーが出たらこう直すべきだった」「このプロジェクトでは関数型スタイルを好む」などのようなパターンを抽出する

Evolution: 抽出したパターンを蓄積し、信頼度が高まったものは自動的にルール化する

 コンテキストの節約術MCP (Model Context Protocol) などのツールが増えると、プロンプトが肥大化し、コンテキストウィンドウ（記憶容量）を圧迫します。これを防ぐための工夫も随所に見られます。
Reverse Token Budget: 古い会話履歴のうち、巨大なツール出力結果だけを優先的に削る
Strategic Compact: 区切りの良いタイミング（設計完了時など）で、手動でコンテキストを要約・圧縮することを提案させる

 Coding Agentの個人的な使い方わたしがやっていることは以下のようなものです。
Contextを作り込む
うまく実装できない理由の9割くらいはContextを作れてないことにある
Context Packingという概念は非常によく表していて好き
https://addyosmani.com/blog/ai-coding-workflow/

とくに初期段階では雑多書きでいいので考えていることをすべて書き出す
書き出したあと設計に落とし込み、大事な部分は固める
思っていたのと違うのはたいてい設計に落とし込めていないため


元の設計からズレだしたら、もとの設計書 + 現在の実装をもとにgemini-3.0-pro-previewなどの1Mコンテキスト対応モデルで差分をタスク化する
このズレ修正は1M tokenまでしかできない

人間が認知できる形状にする
diff, pull-requestをnanobanana等を使ってスライドにするなど

古いライブラリで作ることの対策
Codexなどのモデルを使う (gemini系はドキュメントを与えても失敗しやすい)
実装リポジトリに外部ライブラリのdocumentを配置する


 Coding Agentを作る
 Coding Agentのコアとは何か改めて、Coding Agentの核となる部分を考えると以下のようなものが挙げられます。
自由な武器を与える
Shellツール（CLI）という最も汎用的な武器をもつこと

探索範囲の明確な限定
Planningによる方針策定

In-Context Learningの最大化
思考→アクション→観測ループをコンテキストに積むこと（コンテキストに積まれることが大事）

LLMの能力を信じる
強力なワークフローを設定せず while True をぶん回すこと
あくまで制約はユーザーのプロンプトやSkillsのコンテキストによって非決定論的にかけられる


Prompt Cachingを活用する

 仕様を考える既存のOSSを読むと、みんな頑張っています。Plan/Act, 権限, diffの適用, コンテキスト要約, LSP, ブラウザ対応, MCP/Skills対応, ...

全部やるとぼやけてしまうので、コアだけを作ることにフォーカスします。
要件
LLMにはShellツール(CLI)のみ提供する
LLMがシェルを叩いて、結果（stdout/stderr）を見て、また次のコマンドを決める
思考→実行→観測でゴリ押す戦略

やらないこと
ファイル操作ツールはつくらない
shellさえあればなんとかなるので

権限管理 (Human-in-the-loop) はしない (最小で動くことが目的なので)
コンテキスト圧縮もしない

唯一のツール (terminalツール) について
以下を受け取るツール
command: 新しいコマンドを打つ（自動で改行）
input_text: いま動いてるプロセスに文字を流し込む
keys: enter や up/down などの特殊キー
wait_seconds: どれくらい出力を待つか

処理フロー (2-4のwhileループ)
ユーザーの指示を受ける
LLMが実行方法を考え、Actionを推論する
Terminalツールが実行される
結果がコンテキストに積まれる

終了条件
Terminalツールを呼び出さなくなったとき


 実装https://github.com/nyosegawa/simple-coding-agent で公開しています。

全部で300行です。
System Instruction:
You are "Simple Coding Agent" (SCA), an expert engineer connected to a persistent local shell via PTY.
You are running on {os} in {cwd}.

**Your Core Mechanism:**
1. You interact with the shell using the `terminal` tool.
2. The shell is PERSISTENT. It remembers variables, cd, and running processes between turns.
3. You receive RAW terminal output (including ANSI escape codes like `\\x1b[36m`). Use this to detect active selections, colors, and prompts.

**Handling Long-Running Processes:**
- If you execute a command that takes time (e.g., `npm install`, `build`), set `wait_seconds` to a higher value (e.g., 10, 30).
- If the output comes back incomplete (e.g., ending with "Installing [==>...]"), simply call `terminal` again with empty input and `wait_seconds` to keep watching.
- Do NOT judge a process as "stuck" just because it is silent for a few seconds.

**Interactive CLI:**
- If you see a prompt (e.g., `?`, `[y/N]`, `Select:`), send the appropriate `input_text` or `keys` in the next turn.
- Use arrow keys (`up`, `down`) to navigate menus if you see list interfaces.
ツール定義:
TERMINAL_TOOL = {
    "name": "terminal",
    "description": "Send input to the shell and read output. Can execute commands, type text, or press special keys.",
    "input_schema": {
        "type": "object",
        "properties": {
            "command": {
                "type": "string",
                "description": "Shell command to execute (e.g. 'ls -la'). Appends newline automatically. Use this to start processes."
            },
            "input_text": {
                "type": "string",
                "description": "Text to type into the current process (e.g. 'y', 'my-project'). NO newline appended automatically unless keys=['enter'] is included."
            },
            "keys": {
                "type": "array",
                "items": {"type": "string", "enum": ["enter", "up", "down", "left", "right", "space", "tab", "esc", "backspace", "cntrl_c", "cntrl_d"]},
                "description": "Special keys to press sequence. Processed AFTER input_text."
            },
            "wait_seconds": {
                "type": "number",
                "description": "Max seconds to wait for output after sending input. Default is 1.0. Increase this for long commands (e.g. 10 or 30) to save tokens.",
                "default": 1.0
            }
        }
    }
}
ループ部分 (極小):
処理フローはめちゃくちゃ簡単です。
        while True:
            try:
                resp = self.client.beta.messages.create(
                    model=MODEL_NAME,
                    max_tokens=MAX_LLM_TOKENS,
                    betas=BETA_HEADERS,
                    system=[{
                        "type": "text",
                        "text": self.system_text,
                        "cache_control": {"type": "ephemeral"}
                    }],
                    messages=self.messages,
                    tools=[TERMINAL_TOOL],
                )
            except KeyboardInterrupt:
                print("\n[SCA] Interrupted.")
                break
            except Exception as e:
                print(f"\n[SCA] API Error: {e}")
                break

            self.messages.append({"role": "assistant", "content": resp.content})

            # Check tool use
            tool_use_block = next((b for b in resp.content if b.type == "tool_use"), None)

            # Print text content (thinking)
            for b in resp.content:
                if b.type == "text" and b.text.strip():
                    print(f"\n\033[95m[SCA]\033[0m {b.text}")

            if not tool_use_block:
                # LLM did not use a tool -> Conversation turn finished or asking user question
                break

            if tool_use_block.name == "terminal":
                args = tool_use_block.input
                cmd = args.get("command")
                inp = args.get("input_text")
                keys = args.get("keys")
                wait = float(args.get("wait_seconds", DEFAULT_READ_TIMEOUT))

                # Display action
                log_parts = []
                if cmd: log_parts.append(f"CMD: {cmd}")
                if inp: log_parts.append(f"Input: '{inp}'")
                if keys: log_parts.append(f"Keys: {keys}")
                log_parts.append(f"(Wait: {wait}s)")
                print(f"\033[90m[Action] {', '.join(log_parts)}\033[0m")

                # Execute
                if cmd:
                    self.shell.write(cmd + "\n")
                if inp:
                    self.shell.write(inp)
                if keys:
                    for k in keys:
                        self.shell.write(KEY_MAP.get(k, ""))

                # Read output
                output_text = self.shell.read(duration=wait)

                # Return result
                self.messages.append({
                    "role": "user",
                    "content": [{
                        "type": "tool_result",
                        "tool_use_id": tool_use_block.id,
                        "content": output_text if output_text else "[No output in this duration]"
                    }]
                })

 できたものsca "NextJSでCoding AgentのLPを作って"

 まとめAgentを作る (だけ) なら非常に簡単な時代になりました
既存のOSSのテクニックを駆使すれば高度なAgentも作れます
オレオレ Coding Agent / General AI Agent を作っていきましょう

 Appendix 1: 主要OSSの詳細
 何を比較するかだいたいどれもFilesystem + CLIの構成なのであまり深堀りはしません。処理フローもだいたい同じです。Agentの実装で面白いのは、やはり以下のあたりです。ここに職人芸が出ます。
System Instructionの設計
標準ツールは何があるか
どのようにしてツールが選ばれるか—Function Callingの設計
ツール結果はどのような形状でコンテキストに積まれるか—Observationの形状
コンテキスト溢れの対策
プラン戦略
持っているコンテキスト以外のものはあるか
完了はいつ起きるか？

 1Mトークン以上のリポジトリをどうやって見るか基本的にuithub等で全部コピーしていますが、1Mトークンを超えるとその戦略が使えません。ただしデカリポジトリでも0.8Mトークンくらいを読めば全体観はわかります。個人的にはdocsを読まないほうがより内容を理解してくれる感触があります。
でかいとuithubが重くなるので、自作の gemini-tree-token-counter を使っています(PYPI対応しているので pip install gemini-tree-token-counter で使えます)。
ツリー化: gtc コマンドでリポジトリをツリー化する
gtc https://github.com/Kilo-Org/kilocode
Context Packing: ツリー+gtcのhelp情報をもとにgeminiに 0.8Mコンテキストまでコンテキストを詰め込むコマンドを作って と伝える (docsを除外してとも書く)
あくまでLLM側はツリー情報しか知りませんが、だいたいファイル名がちゃんと書いてあるのでうまくいきます
以下のようなコマンドを作ってくれます
gtc https://github.com/Kilo-Org/kilocode -c \
-d src/core/prompts \
-d src/core/tools \
-d src/core/kilocode \
-d src/core/task \
-d src/core/assistant-message \
-d src/core/diff \
-d src/core/context-management \
-d src/core/mentions
分析: コマンドを実行した結果を全部コピーし、分析させます
分析するときは、上述のように何を知りたいかをまとめておくといいですが、対話形式でもいい感じのことを知ることができます。べんり。

 Clinehttps://github.com/cline/cline
System Instructionの設計
モジュラー構造による動的生成
PromptRegistryがシングルトンとして管理し、モデルIDに基づき適切なPromptVariantを選択する
PromptBuilderがVariant設定に基づきコンポーネントを組み立てる
TemplateEngineがCWDやTOOL_USEなどのプレースホルダーを実行時の値に置換する

PromptVariantによるモデルごとの最適化
モデルファミリー（Claude, GPT, Gemini等）ごとに定義ファイルが存在する
ネイティブツール呼び出しの可否やコンポーネントの順序を定義する
特定のセクション（RULESなど）をオーバーライドしてカスタマイズする

再利用可能なコンポーネント群
AGENT_ROLE（役割定義）、CAPABILITIES（機能）、RULES（制約）、SYSTEM_INFO（環境情報）などで構成される


標準ツールは何があるか
ファイル操作系
read_file（読み取り）、write_to_file（新規作成・上書き）、replace_in_file（部分置換）、apply_patch（diff形式での編集）、list_files（一覧）、search_files（正規表現検索）

コード分析系
list_code_definition_names（Tree-sitterを用いた定義抽出）

実行環境系
execute_command（シェル実行）、browser_action（Puppeteerによるブラウザ操作）

外部情報取得系
web_search（検索）、web_fetch（コンテンツ取得）

タスク管理・MCP系
ask_followup_question（質問）、attempt_completion（完了報告）、new_task（タスク作成）、use_mcp_tool（MCPツール実行）


どのようにしてツールが選ばれるか—Function Callingの設計
Native Tool Calling（ネイティブ方式）
OpenAI、Anthropic、Geminiなどの対応モデルで使用される
ツール定義を各プロバイダーのAPIスキーマ（JSON Schema）に変換してリクエストに含める
PromptVariantのuse_native_toolsラベルで制御される

XML Tool Calling（テキスト埋め込み方式）
ネイティブ非対応モデルやGenericバリアントで使用される
システムプロンプト内にXML形式でツールの使用法とフォーマットを記述する
モデルはテキストとしてXMLタグを出力し、それをパースして実行する

Auto-approve（自動承認）
設定に基づき、特定のツールやパスに対する操作をユーザー承認なしで実行するか判定する


ツール結果はどのような形状でコンテキストに積まれるか—Observationの形状
Native Tool Callingの場合
roleがtoolまたはtool_resultのブロックとして追加される
tool_use_idでリクエストと紐付けられる

XML Tool Callingの場合
roleがuserのメッセージとして追加される
[tool_name for 'target'] Result: というヘッダー形式でテキスト化される

コンテンツの構成
テキストによる実行結果
画像（ブラウザのスクリーンショット等）
ファイル内容（read_file等の結果）

コンテキスト節約のための加工
重複したファイル読み込み結果は削除され、最新版を参照するよう注釈のみが残される


コンテキスト溢れの対策
トークン使用量の監視
APIリクエストごとに使用量を計算し、モデルの最大許容量（バッファ除去後）と比較する

ContextManagerによる履歴操作
制限に近づくとsummarize_taskツールを強制的に呼び出すフローへ誘導する

自動要約と履歴の切り捨て
モデル自身にこれまでの会話、解決済みの問題、次のステップを要約させる
最初のユーザーメッセージ（タスク定義）を残し、中間履歴を削除して要約メッセージに置き換える

ファイル読み込みの最適化
会話履歴内で同じファイルが複数回読み込まれている場合、最新以外の出力を削除する


プラン戦略
Plan ModeとAct Modeの分離
Plan Modeは情報収集と計画立案に特化し、書き込み系ツールの使用を制限する
Act Modeは実装と実行に特化する

Deep Planning
複雑なタスク向けに、調査（Silent Investigation）、議論、計画書作成、タスク作成の4段階を踏むプロセス

Focus Chain (Task Progress)
各ツール呼び出しのパラメータにtask_progress（チェックリスト）を含めることを推奨または強制する
これによりモデルに常に進捗状況と残タスクを認識させる


持っているコンテキスト以外のものはあるか
Environment Details
OS、シェル、現在時刻、タイムゾーン

エディタの状態
現在開いているタブ（Open Tabs）
表示されているファイル（Visible Files）

ターミナルの状態
バックグラウンドで実行中のコマンドとその最新出力

ルールとスキル
.clinerulesや.cursorrulesなどのプロジェクト固有ルール
SKILL.mdから読み込まれた特定のタスク向けの手順書（Skills）


完了はいつ起きるか？
モデルによる自己判断
全ての要件を満たしたと判断した時点でattempt_completionツールを呼び出す

ユーザーによる確認
ツール呼び出しによりUI上に完了確認が表示される
ユーザーがその結果を確認し、承認ボタンを押した時点でタスク終了となる

フィードバックループ
ユーザーが完了を拒否してコメントした場合、タスクは継続しAct Modeに戻る



 gemini-clihttps://github.com/google-gemini/gemini-cli
System Instructionの設計
インタラクティブなCLIエージェントとしてのペルソナ定義
Core Mandatesとしてプロジェクトの慣習の遵守、ライブラリ使用の慎重な判断、既存コードのスタイル維持、最小限のコメント、積極的なテスト追加を規定
主要なワークフローの定義
ソフトウェアエンジニアリングタスクでは理解、計画、実装、検証（テスト）、検証（標準準拠）、完了の順序を強制
新規アプリケーション作成では要件理解、計画提案、ユーザー承認、実装、検証、フィードバックの順序を強制

セキュリティと安全性としてファイル変更やシステム状態を変更するコマンドの事前説明義務
環境に応じた動的なコンテキスト注入（Gitリポジトリの状態、サンドボックス環境の有無、利用可能なスキル一覧）
プランモード時は読み取り専用ツールのみを許可し、探索と計画のフェーズを厳格化する指示への切り替え

標準ツールは何があるか
ファイル操作系
read_file（ファイル読み込み、行指定可能）
write_file（ファイル書き込み、新規作成）
replace（ファイル内の文字列置換）
read_many_files（globパターンによる複数ファイル読み込み）
list_directory（ディレクトリ一覧）

検索系
glob（ファイル検索）
search_file_content（正規表現によるgrep検索、ripgrep使用）

実行系
run_shell_command（シェルコマンド実行、バックグラウンド実行対応）

外部アクセス系
google_web_search（Google検索）
web_fetch（URLからのコンテンツ取得）

記憶・管理系
save_memory（長期記憶への保存）
write_todos（タスクのサブタスク管理）
activate_skill（専門スキルの有効化）
ask_user（ユーザーへの質問）
get_internal_docs（内部ドキュメント参照）


どのようにしてツールが選ばれるか—Function Callingの設計
Gemini APIのネイティブなFunction Calling機能を使用
ToolRegistryが利用可能なツール定義（スキーマ）を収集しモデルに提示
モデルが生成したfunctionCallパートをクライアントが解析
実行前にPolicyEngineが介入し、ツールの実行可否を判定
ALLOWなら即実行
DENYならエラーを返す
ASK_USERならユーザーに確認ダイアログを表示（CLIまたはMessageBus経由）

承認された場合、ToolExecutorが実際の処理を実行

ツール結果はどのような形状でコンテキストに積まれるか—Observationの形状
Gemini APIのfunctionResponse形式で履歴に追加
構造はfunctionResponseオブジェクト内にname（ツール名）とresponse（出力内容）を含む
responseの中身は通常outputプロパティを持つJSONオブジェクトまたは文字列
画像やPDFなどのバイナリデータはinlineDataとして埋め込まれる
出力が非常に長い場合（Shellコマンド結果など）は自動的に切り詰められ、一時ファイルへのパスと「出力が切り詰められた」旨のメッセージに置換される
LLM向けのコンテンツ（llmContent）とユーザー表示用のコンテンツ（returnDisplay）が区別して管理される

コンテキスト溢れの対策
ChatCompressionServiceによる履歴の圧縮
トークン数がモデル制限の一定割合（デフォルト50%）を超えた場合にトリガー
Reverse Token Budget戦略
最新の履歴（約30%）は完全な状態で保持
それ以前の履歴にある大きなツール出力（functionResponse）を優先的に切り詰め（末尾30行のみ残すなど）

要約による圧縮
古い履歴をLLMに送り、構造化されたXML形式（state_snapshot）に要約させる
スナップショットには全体のゴール、制約条件、重要な知識、変更の履歴、ファイルシステムの状態、タスクの進行状況が含まれる

コンテキストウィンドウが溢れそうな場合の警告イベント発行

プラン戦略
System Instructionによる明示的な思考プロセス（Understand -> Plan -> Implement）の強制
write_todosツールを使用したタスクの細分化と状態管理（pending, in_progress, completed, cancelled）
ApprovalMode.PLAN（プランモード）
読み取り専用ツールのみ使用可能な状態で、要件定義、探索、設計のフェーズを強制的に経る
ユーザーが計画を承認するまで実装（書き込み）フェーズに移行しない


持っているコンテキスト以外のものはあるか
IDEコンテキスト
現在開いているファイル、カーソル位置、選択範囲の情報をJSONまたは差分として注入

グローバルおよび環境メモリ
ホームディレクトリやプロジェクトルートのGEMINI.mdから読み込まれた永続的な記憶

JIT（Just-In-Time）コンテキスト
アクセスされたファイルパスに基づいて、ディレクトリ階層を遡り関連するコンテキストファイル（GEMINI.md）を動的にロード

Hookコンテキスト
外部拡張やスクリプトがフックを通じて注入する追加情報（hook_contextタグでラップされる）


完了はいつ起きるか
サブエージェントの場合
complete_taskツールを呼び出した時点

メインエージェントの場合
モデルがツール呼び出しを含まない自然言語のテキスト応答を生成し、かつfinishReasonがSTOPとなった時点

異常終了
最大ターン数（MaxSessionTurns）を超過した場合
ユーザーによる中断（AbortSignal）が発生した場合
回復不能なエラーが発生した場合



 Kilohttps://github.com/Kilo-Org/kilocode
System Instructionの設計
モジュール構成
vscode.ExtensionContextや現在の作業ディレクトリ、設定、モードなどを受け取るSYSTEM_PROMPT関数によって動的に生成される
役割定義（Role Definition）、ツール定義、能力（Capabilities）、ルール（Rules）、システム情報（System Info）、目的（Objective）の各セクションで構成される

モードシステム
Code、Architect、Askなどのモードごとに異なる役割定義と許可されるツールグループが割り当てられる
ユーザー定義のカスタムモードやプロンプトのオーバーライドが可能

カスタム指示の注入
グローバルな指示（Global Instructions）とモード固有の指示（Mode-specific Instructions）を統合する

.clinerulesや.kilocode/rules/ディレクトリ内のルールファイルを読み込んでプロンプトに追加する

動的なコンテキスト挿入
OS、シェル、ホームディレクトリなどのシステム情報を自動挿入する
プロジェクトのファイル構造（environment_details）をユーザーメッセージの末尾に自動的に付与する


標準ツールは何があるか
ファイル操作
read_file: ファイル内容の読み取り（行番号付き）、画像やPDFの読み取りもサポート
write_to_file: 新規ファイルの作成やファイルの完全な書き換え
delete_file: ファイルやディレクトリの削除（Kilo固有機能）
list_files: ディレクトリ内のファイル一覧表示（再帰可）

コード編集
apply_diff: 検索と置換ブロックを使用した既存ファイルの外科的な編集
search_and_replace: 文字列の検索と置換
fast_edit_file: Morphモデルなどを使用した高速な適用に特化した編集ツール（Kilo固有機能）
apply_patch: 独自のパッチ形式を使用したファイル更新

実行と探索
execute_command: システムシェルでのコマンド実行
search_files: 正規表現によるファイル検索
codebase_search: ベクトルデータベース等を使用したセマンティック検索（RAG）
browser_action: Puppeteerを使用したブラウザ操作（クリック、タイプ、スクロール、スクリーンショットなど）

タスク管理・メタ操作
ask_followup_question: ユーザーへの質問や確認
attempt_completion: タスク完了の報告と結果の提示
update_todo_list: タスク進捗状況（TODOリスト）の管理
switch_mode: 現在のモード（Code, Architect等）の切り替え
new_task: 新しいタスクセッションの開始

外部拡張
use_mcp_tool: MCP（Model Context Protocol）サーバーが提供するツールの実行
access_mcp_resource: MCPリソースへのアクセス


どのようにしてツールが選ばれるか—Function Callingの設計
プロトコルの選択
設定やモデルの能力に応じてXMLスタイル（Claude等向け）またはNativeスタイル（OpenAI互換のtool_calls）のいずれかを使用する

フィルタリングプロセス
現在のモード設定（例：Architectモードなら編集ツールは除外）に基づいて利用可能なツールをフィルタリングする

.kilocodeignoreによるアクセス制限や読み取り専用ファイルのチェックを行う

プロンプトへの提示
許可されたツールのみがSystem Instruction内のツール定義セクションに含まれる
Nativeモードの場合はAPIパラメータのtools配列として渡される


ツール結果はどのような形状でコンテキストに積まれるか—Observationの形状
プロトコルによる分岐
Nativeプロトコル: role: "user" のメッセージ内に type: "tool_result" ブロックとして格納され、tool_use_idで紐付けられる
XMLプロトコル: ユーザーメッセージ内のテキストブロックとして、特定のXMLタグ形式で結果が記述される

結果の内容
成功時: コマンドの出力、ファイルの内容、操作の完了メッセージなどが含まれる
失敗時: エラーメッセージや例外の詳細が含まれ、モデルが自己修正できるようにする
画像: スクリーンショットなどは画像ブロックとしてメッセージに含まれる

ユーザーフィードバック
ツール実行に対するユーザーの承認または拒否コメントもツール結果の一部として統合される


コンテキスト溢れの対策
トークン監視

manageContext関数がトークン使用量を監視し、設定された閾値（デフォルトではウィンドウの数%を残す）を超えそうになると対策を発動する

要約（Condensation）
過去の会話履歴をLLMを使用して要約し、古いメッセージを単一の要約メッセージに置き換える

autoCondenseContext設定により自動化される

スライディングウィンドウ（Truncation）
要約が失敗または無効な場合のフォールバックとして、最初のメッセージを保持しつつ、中間部分のメッセージを非破壊的に非表示（truncate）にする
必要に応じて巻き戻しが可能な設計になっている

読み取り制限

maxConcurrentFileReadsやmaxReadFileLineにより、一度に読み込むファイル数や行数を制限し、コンテキストの急激な消費を防ぐ


プラン戦略
目的セクション（Objective）
タスクを明確なステップに分解し、順序立てて実行することを指示する
必要な情報を事前に収集し、推測ではなく事実に基づいてパラメータを決定するよう求める

TODOリストの活用

update_todo_listツールを使用し、進捗状況（pending, in_progress, completed）を常に最新の状態に保つことで、長期的なコンテキストを維持する

反復的なプロセス
ツール実行、結果の確認、次のアクションの決定というループを回す
一度に複数のツールを使用する場合と、ステップバイステップで確認する場合の指針がガイドラインに含まれる


持っているコンテキスト以外のものはあるか
MCP（Model Context Protocol）
外部のMCPサーバーに接続することで、ローカル環境以外のリソースやカスタムツールにアクセスする能力を持つ

環境詳細（Environment Details）
ユーザーが明示的に提供しなくても、現在の作業ディレクトリ以下のファイルツリー構造が自動的にコンテキストに含まれる

スキル（Skills）
モードに応じて特定の専門知識や手順書（SKILL.mdなど）を動的に読み込む仕組みがある


完了はいつ起きるか？
完了のトリガー
モデルがタスクの要件を満たしたと判断し、attempt_completionツールを呼び出した時

制約事項
現在のターンでツール実行エラーが発生していないこと
設定されている場合、未完了のTODOアイテムが残っていないこと

ユーザー承認

attempt_completionの結果に対してユーザーが確認を行い、満足した場合にタスクが正式に終了する
ユーザーが追加のフィードバックを行った場合は、タスクは継続される



 OpenCodehttps://github.com/anomalyco/opencode
System Instructionの設計
モデルごとの最適化
anthropic.txt, gemini.txt, codex_header.txtなどの専用テンプレートを使用

実行環境情報の注入
OS
プラットフォーム
現在の日付
ワーキングディレクトリ
Gitリポジトリの状態

プロジェクト情報の統合

AGENTS.md, CLAUDE.mdなどのルールファイルの読み込み
treeコマンド結果によるディレクトリ構造の挿入

エージェントの振る舞い定義
モード（build, planなど）に応じた役割の規定
セキュリティ制約の明示（悪意あるコードの拒否）
ツール使用ポリシー（並列実行推奨など）の記述


標準ツール
ファイル操作
read（読み込み）
write（新規作成・上書き）
edit（文字列置換）
apply_patch（パッチ適用）

探索・検索
glob（ファイル名検索）
grep（正規表現検索）
list（ファイル一覧）
lsp（コード解析）

シェル・実行
bash（コマンド実行）

外部アクセス
webfetch（URLコンテンツ取得）
websearch（ウェブ検索）
codesearch（コードライブラリ検索）

タスク管理・計画
task（サブエージェント委譲）
todowrite（タスク作成・更新）
todoread（タスク確認）
plan_enter（計画モード開始）
plan_exit（計画モード終了）

その他
question（ユーザーへの質問）
skill（専門スキルの読み込み）


ツール選択の設計（Function Calling）
実装基盤
Vercel AI SDKのstreamTextおよびconvertToModelMessagesを利用

フィルタリング
エージェント設定に基づく利用可能ツールの選定
ユーザー権限（PermissionNext）による許可・拒否・確認の判定

プロンプト戦略
許可されたツールのみを定義として提示
依存関係のないツールの並列実行を推奨
実験的なbatchツールによる同時実行


ツール結果とコンテキストへの積載（Observation）
データ構造
role: toolとしてメッセージ履歴に保存
content配列内にtype: tool-resultとして格納
toolCallIdによるリクエストとの紐付け

出力処理
成功時はresultオブジェクトに出力を格納
エラー時はエラーステータスを記録

特殊データの扱い
長大な出力は自動的に切り詰め（Truncate）、別ファイルへ保存し要約のみ積載
画像やバイナリはBase64エンコードして添付


コンテキスト溢れ対策
自動コンパクション
トークン数が閾値を超えた際の自動発動

要約処理
会話文脈を要約し新セッションの先頭に配置

剪定（Pruning）
古いツール実行結果の内容を削除し履歴のみ保持

監視
入出力およびキャッシュトークンの常時計測

コンテキスト分離
Taskツール利用時のサブエージェントによる別セッション実行


プラン戦略
状態管理
Todoツールによるタスク進行状況の管理

Plan Mode
ファイル編集を禁止したRead-Only状態での稼働
planエージェントへの切り替え

永続化
.opencode/plansディレクトリ下のファイルによる計画保存

調査フェーズ
Exploreエージェントの並列起動によるコードベース調査

承認フロー
plan_exitツールによるユーザー承認と実装モードへの移行


保持している外部コンテキスト
プロトコル接続
MCPサーバーリソース
LSPサーバー解析情報

システム状態
Gitブランチ情報
ワークツリー状態
環境変数

クライアントデータ
クリップボード内容
永続化ストレージデータ


完了のタイミング
正常終了
LLMがツール呼び出しを行わずテキストメッセージを返却

強制終了
最大ステップ数への到達
ユーザーによる中断操作

サブタスク完了
サブエージェントが結果を親エージェントへ返却



 Appendix 2: 関連論文紹介次はこの期間に出てきた論文をみていこうと思います。特に関連していそうな, 個人的に興味を惹かれるものをピックアップしているので偏りがあります。総合的なサーベイ論文としては From Code Foundation Models to Agents and Applications (Yang et al., 2025) をおすすめします。300ページ超えの長大な論文ですが、トレーニング手法から最新のアプリケーションまで追っていて非常に参考になります (アプリケーションについては紹介が主ですが)

 コード補完に至るまでの道Codex
https://arxiv.org/abs/2107.03374
真・OpenAI Codex論文です。GPT-3にCodeを追加学習させたら最強になったよという話


 Agent概念の導入ReAct
https://arxiv.org/abs/2210.03629
思考→行動→観測のループ大事だよねって話

Toolformer
https://arxiv.org/abs/2302.04761


 マルチエージェントによる初期の試みChatDev
https://arxiv.org/abs/2307.07924
ソフトウェア開発会社全体をシミュレーションし、ロールプレイによる分業が性能向上に効くことを示した論文

MetaGPT
https://arxiv.org/abs/2308.00352
AgentにSOP (標準作業手順書) を導入し、役割ごとに構造化された出力を強制することで品質を安定させた論文


 リアルワールド適用への模索Lost in the Middle
https://arxiv.org/abs/2307.03172
Context Windowが広くても真ん中の情報は忘れられるって話

SWE-bench
https://arxiv.org/abs/2310.06770
実際のGitHub Issueを解かせるベンチマークの導入, 一時期デファクトスタンダードだった

Agentless
https://arxiv.org/abs/2407.01489
いわゆるAgenticではなく、単純な検索と修正だけでSWE-benchの上位に行けることを示した論文


 Codebaseのよい扱い方の探索RepoCoder
https://arxiv.org/abs/2303.12570


 CLIベースのアプローチの登場SWE-agent
https://arxiv.org/abs/2405.15793


 サーベイAI Agentic Programming: A Survey of Techniques, Challenges, and Opportunities
https://arxiv.org/abs/2508.11126

From Code Foundation Models to Agents and Applications: A Comprehensive Survey and Practical Guide to Code Intelligence
https://arxiv.org/abs/2511.18538


A Survey of Vibe Coding with Large Language Models
https://arxiv.org/abs/2510.12399


 Coding Agentの影響について
AI-Driven Innovations in Software Engineering: A Review of Current Practices and Future Directions
2025/01
https://www.mdpi.com/2076-3417/15/3/1344
ソフトウェア開発の変遷について

The Rise of AI Teammates in Software Engineering (SE) 3.0: How Autonomous Coding Agents Are Reshaping Software Engineering
https://arxiv.org/abs/2507.15003
実際のプルリクをもとにした分析。AIDevデータセットとして公開している
https://huggingface.co/datasets/hao-li/AIDev
リリース時期	アプリケーション名	備考
2018年	Tabnine	初期はn-gram等での補完
2021年3月	GitHub Copilot	OpenAI Codexによる補完
2022年12月	ChatGPT	対話形式でのコード生成が可能に
2023年3月	Cursor	初期はCopilotのようなコード補完が中心
2023年4月	AutoGPT	AgentによるCoding
2023年7月	MetaGPT	分業化されたソフトウェアエンジニアリング
2023年7月	ChatGPT Code Interpreter	Sandboxにおける任意処理用Pythonコードの作成・実行
2023年7月	Open Interpreter	Code InterpreterのOSS版 + α
2024年3月	Devin	Coding Agentのshell利用の一般化
2024年7月	Cline
2024年11月	Windsurf
2025年2月	Claude Code
2025年5月	Codex（OpenAI）
2025年11月	Google Antigravity
何を書いている記事か

Coding Agentの歴史

年表

LLMによるコード補完の登場 (2021年)

チャットベースのコードアシストの時代 (2022-2023年)

エージェントの模索時代 (2023年)

CLIベースの登場 (2024年)

CLIベースの活躍と現場での活用 (2025年)

Coding Agentの現代的テクニック

System Instruction（システムプロンプト）の設計思想

Context Management

ツール設計と実行戦略

プランニングとワークフロー

外部コンテキストの統合

完了判定

Coding Agentを使いこなす

Subagentsによる分業体制

コマンドによるベストプラクティスの強制

Hooksによる自動化

Continuous Learning

コンテキストの節約術

Coding Agentの個人的な使い方

Coding Agentを作る

Coding Agentのコアとは何か

仕様を考える

実装

できたもの

まとめ

Appendix 1: 主要OSSの詳細

何を比較するか

1Mトークン以上のリポジトリをどうやって見るか

Cline

gemini-cli

Kilo

OpenCode

Appendix 2: 関連論文紹介

コード補完に至るまでの道

Agent概念の導入

マルチエージェントによる初期の試み

リアルワールド適用への模索

Codebaseのよい扱い方の探索

CLIベースのアプローチの登場

サーベイ

Coding Agentの影響について

Discussion
