知っておくべきAIコーディングエージェント用語31選、5つの柱で整理する

毎週のように新しい用語がタイムラインに現れます。Context engineering。Harness engineering。RLM。Progressive disclosure。AIコーディングエージェントを毎日使っていると、語彙が理解を追い越す速さで増えていきました。

そこで立ち止まり、集めた31の用語をグループに分類してみました。5つの柱が浮かび上がり、それが見えた瞬間、Claude CodeやCodexのようなツールのアーキテクチャ全体が、それまでとは違う形で理解できました。

5つの柱は論理的な流れになっています。エージェントが見るものを設計し、作業を複数エージェントに分割し、実行を制御し、セッションをまたいで記憶させ、外の世界とつなぐ。

設計。分割。制御。記憶。接続。

エージェントが見るものを設計する

AIモデルが処理するのは、コンテキストウィンドウのみです。システムプロンプト、ユーザー指示、添付ファイル、会話履歴、メモリブロック、ロードされたスキル、これらすべてが一つのトークンストリームに連結されます。そのストリームがモデルの宇宙全体です。多くのチームがエージェントの挙動を設定するために使うAGENTS.mdも、そのストリームの一部に過ぎません。

Promptはモデルへの直接的な指示です。Prompt engineeringは、安定した結果を得るために、例示や出力フォーマットを含む指示を設計する実践です。この2つの用語はよく知られていますが、実際にモデルへ入力されるものの一部を表すに過ぎません。

Contextはモデルが参照できるすべてのものです。システムプロンプト、会話履歴、添付ファイル、メモリ、スキル、ツール出力の総体です。Context engineeringは、何を入れ、何を除外し、どの順序で配置するかを決める技術です。この違いは重要です。2,000行のファイルを指示の前に置くか後に置くかで、同じプロンプトから全く異なる結果が生まれるのを何度も目にしました。順序は見た目の問題ではありません。

Intentはユーザーの本当の目的であり、文字通りタイプした内容と異なる場合があります。「テストを直して」と書いたとき、intentは「CIをグリーンにする」かもしれないし、「新しいAPIに合わせてテストスイートをリファクタリングする」かもしれません。エージェントのルーティングはここから始まり、intentを読み違えると下流のすべてに影響します。

Skillは、呼び出したときにコンテキストへロードされる、再利用可能な専門的な指示のまとまりです。プロンプトのための関数のようなものです。特定の挙動が必要なたびに200行の指示を貼り付ける代わりに、/refactor-cleanを呼び出すとスキルの内容がコンテキストウィンドウにロードされます。

Progressive disclosureは、すべてのスキルを一度にコンテキストへロードしないデザインパターンです。代わりに、エージェントはその時点で必要なスキルだけをロードします。Anthropicはこのアプローチをスキルに関するブログ記事で公開しています。コンテキストウィンドウのスペースは有限なので重要なポイントです。40個のスキルを最初からロードすると、モデルが作業を始める前にトークンが消費されます。Progressive disclosureはウィンドウを軽量に保ち、モデルの集中を維持します。

最初によく犯していた失敗は、コンテキストに詰め込みすぎて、なぜモデルの出力品質が落ちるのか首をひねることでした。200Kのコンテキストウィンドウは理論上の上限です。実際には、システムプロンプト、MCPサーバーの定義、会話履歴を考慮すると、使えるスペースは70K以下になることがあります。Context engineeringはその制約を尊重することです。

作業を複数エージェントに分割する

単一エージェントがすべてを処理するのはシンプルに聞こえますが、コンテキストウィンドウが埋まって出力品質が落ちるまでの話です。マルチエージェントアーキテクチャが存在する理由がここにあります。

Subagentはメインエージェントが作業を委譲するchild processです。メインエージェントは専門的なタスクをオフロードすることで、自分のコンテキストをクリーンに保てます。Claude Codeでバックグラウンドのリサーチタスクを起動するとき、それは独自のコンテキストウィンドウで動作し、結果だけを返すsubagentです。

Swarmは複数のエージェントが同じ問題の異なる部分に並行して取り組むパターンです。5つのファイルを同時に分析する必要があるなら、swarmを使えば1つのエージェントが順番に処理する代わりに、5つのエージェントがそれぞれ1ファイルを担当できます。

Fleetは実行中のエージェント群を運用的に見たものです。アーキテクチャの用語ではなく、管理の用語です。3つのsubagentと2つのバックグラウンドエージェントが動いているなら、その集合がfleetです。

Handoffはあるエージェント（または人）から別のエージェントへの作業の引き渡しです。逐次ワークフローでは、エージェントAが担当フェーズを完了してエージェントBへhandoffします。重要な点は何が転送されるかです。出力だけか、それともフルコンテキストか。ほとんどのhandoffはサマリーを転送するため、情報の損失が起きる可能性があり、それを考慮する必要があります。

Background agentはユーザーのインタラクションなしに非同期で動作します。GitHubのCopilot WorkspaceとAnthropicのClaude Codeはどちらもこのパターンをサポートしています。タスクを記述してラップトップを閉じると、エージェントが独立して作業します。戻ったときに結果が出ています。

はまった罠は、あまりにも早い段階で作業を多数のエージェントに分割することでした。うまく設計されたコンテキストを持つ単一エージェントの方が、連携の悪いマルチエージェント構成よりもタスクの80%をうまく処理できます。単一エージェントがコンテキスト上限や品質低下にぶつかっているという証拠がある場合にのみ分割すべきです。

エージェントの実行を制御する

正確なコードを生成するエージェントでも、危険なツールを黙って呼び出したり、触れてはいけないファイルを変更したりするなら意味がありません。制御は第3の柱であり、ほとんどのチームが投資を怠りがちな部分です。

Harnessはエージェントの実行、検証、ライフサイクルを包むoperational frameです。権限チェックから出力バリデーション、リトライロジックまでを含みます。Harness engineeringはそのframe内で制約とフィードバックループを設計することです。OpenAIはCodexが構造化されたharnessパターンで100万行以上のコードを生成した方法を公開したとき、この用語を広めました。

Traceはエージェントが行ったすべてのステップと意思決定の実行ログです。エージェントが1タスクにつきweb searchツールを14回も呼び出しているのに、情報は1回で済むと気づいてから、traceを真剣に見るようになりました。traceがなければ、エージェントが効率的に動いていると思い込んでいたでしょう。TraceはAIエージェントにとってデバッグに最も近いものです。

Diffはエージェントの変更前後のコードの比較です。traceと組み合わせることで検証の基盤になります。見えないものはレビューできません。diffはエージェントの変更をpull requestが人間の変更をレビュー可能にするのと同様に、レビュー可能にします。

Guardrailsは危険な出力を防ぐルールとバリデーションチェックです。「rm -rfを含むshellコマンドは絶対に実行しない」というシンプルなものから、機密データが出力に現れないようにするcontent classifierのような高度なものまであります。

Sandboxは制限された権限を持つ隔離された実行環境です。CodexはDockerサンドボックス内で動作し、エージェントはコードを書いてテストを実行できますが、ネットワークへのアクセスやホストシステムの変更はできません。これが「エージェントがミスを犯した」と「エージェントが本番環境に影響するミスを犯した」の違いです。

CLI（command-line interface）はエージェント時代に再び注目されています。ターミナル経由でツールを実行することは、プロトコルレイヤーを経由するよりもtoken-efficientであることがわかっています。すべてのトークンがコストになりコンテキストスペースを消費するとき、CLIの直接性が重要になります。

REPL（read-eval-print loop）はコードをその場で実行できるインタラクティブ環境です。エージェントはREPLを使って仮説を検証し、中間結果を確認し、ファイルをディスクに書く前にソリューションをイテレーションします。

セッションをまたいで記憶する

大規模言語モデルには明確な境界があります。コンテキストウィンドウです。埋まると古いコンテンツが削除されます。数時間や数日にまたがるタスクでは、これが現実の問題になります。

Memoryは単一のコンテキストウィンドウを超えて会話履歴とタスク状態を保存するシステムです。Memory hierarchyはこれらのストアを層に整理します。一般的にはshort-term（現在の会話）、medium-term（最近のセッション）、long-term（永続的な知識）です。この設計がCPUキャッシュ階層と並行しているのは同じ理由です。アクセスパターンが異なれば、異なるストレージ戦略が必要です。

Embeddingsはテキストをセマンティックな意味を捉えた数値ベクトルに変換します。RAG（retrieval-augmented generation）の基盤であり、エージェントがベクトルデータベースを検索してコンテキストウィンドウに関連情報を取り込むために使われます。エージェントが以前のセッションの何かを「記憶している」とき、それは通常embeddings-basedの類似検索を実行しています。

Long-running agentは複数のコンテキストウィンドウをまたいで状態を保持し、単一セッションより長いタスクに取り組みます。モデル自体に永続的なメモリがないため、外部の状態管理が必要です。

Ralph LoopはGeoffrey Huntleyが作ったもので、メモリ問題を実用的に解決する自律型コーディングループです。各イテレーションは新しいエージェントインスタンスから始まりますが、進捗はgit commitと進捗ファイルを通じて永続化されます。新しいインスタンスはgitの履歴と進捗メモを読んで何が完了しているかを把握し、そこから続けます。繰り返しイテレーションすることでtest-time scalingを最大化し、各ループはリポジトリ自体に蓄積されたコンテキストから恩恵を受けます。

**RLM（Recursive Language Model）**は根本的に異なるアプローチを取ります。長い入力をモデルに直接流し込む（コンテキストウィンドウを超える）代わりに、元のデータをREPL変数に保存し、モデルがコードを書いてそれを探索できるようにします。モデルは再帰的な関数呼び出しを通じて保存データに対してターゲットを絞ったクエリを発行します。元のデータがコンテキストウィンドウに入らないため、情報がtruncationで失われることがありません。著者らはこのアプローチが通常のコンテキストウィンドウの100倍に相当する入力を処理できると主張しています。

どちらのアプローチも同じ制約を認識していますが、解決方法が異なります。Ralph Loopは外部永続化を使ってコンテキストウィンドウの限界に合わせて動作します。RLMはデータをウィンドウの外に置くことでコンテキストウィンドウを完全に回避します。どちらが優れているかは一概に言えません。ボトルネックがタスクの継続性（Ralph Loop）か入力サイズ（RLM）かによって適切な選択が変わります。

エージェントを外の世界とつなぐ

外部ツール、API、サービスにアクセスできないエージェントはテキスト生成に限定されます。プロトコルが統合の問題を解決します。

**MCP（Model Context Protocol）**はモデルと外部ツールの接続を標準化します。MCPがなければ、NモデルとMツールの統合にはN x Mのカスタム実装が必要です。MCPがあれば、各モデルと各ツールが一度プロトコルを実装するだけで、統合コストはN + Mに削減されます。これはUSBを成功させた原則と同じです。一つのインターフェースに合意すれば、すべてがつながります。

**ACP（Agent Communication Protocol）**はエディタとコーディングエージェント間の通信を標準化します。ZedとJetBrainsが開発をリードしています。解決しようとしている問題はMCPに似ていますが、異なる層です。model-to-toolではなく、editor-to-agentです。

**LSP（Language Server Protocol）**はエディタとコード解析サーバー間の通信の確立した標準です。プロトコル標準化が開発者ツールで機能することを最初に証明したものです。grepで30秒かかっていたリファレンス検索がLSP経由で50msで完了します。LSPは生ファイルの内容ではなく構造化された精確な結果を返すため、トークン使用量が2,000以上から約500に下がります。LSPはACPの設計の参考モデルでもあります。問題の形がほぼ同一なのでそれは理にかなっています。

この3つのプロトコルは異なる層で動作しますが、同じアーキテクチャ上の洞察を共有しています。カスタムのpoint-to-point統合はスケールしません。標準インターフェースはスケールします。

地図は現地ではない

これらの用語のほとんどは6ヶ月前には存在しませんでした。馴染みがないと感じても、それは当然のことです。語彙が増えているのは、分野が成長しているからであり、新しい概念には名前が必要です。

5つの柱の価値は定義を暗記することにあるのではありません。新しい用語に出会った瞬間にどこに属するかがわかる、メンタルフレームワークを持つことにあります。誰かが「agent memory」と言えば、それが第4の柱に属するとわかります。新しいプロトコルが登場すれば、第5の柱にあるとわかります。このフレームワークは崩れることなく新しい語彙を吸収します。

今でも定期的に用語を調べます。違うのは、今はどの棚に属するかがわかっていることです。