📚 全体地図を見る
AIエージェントとLLMはどこで分かれるのか — エンジンと自動車1台の話
0. この記事をひらく前に
F シリーズ6編をくぐり抜けてこられた方なら、いまのLLMに対して「単語をベクトルに変え、ベクトルを混ぜ合わせ、次の単語を確率で選ぶ計算のかたまり」という感覚が、ある程度ついてきているはずです。P2 で私はこれをひとつの比喩にまとめました。
LLM はエンジンです。AIエージェントは、そのエンジンを載せた自動車1台まるごとです。
エンジンは燃焼の仕組みでエネルギーを取り出す精巧な部品ですが、エンジンだけを道路に置いてもどこにも行けません。ハンドルがないから方向を変えられない、タイヤがないから進めない、燃料系統がないから連続して回せない、メーターがないから今どこを走っているのかもわからない。エンジンは「車になるための1部品」でしかありません。
エージェントもまったく同じです。LLM を1回呼び出しただけでは、エンジンを1回まわしただけです。そこに、
- 目標 を受け取る窓口
- 今どこまでやったかを見る メーター (状態)
- 外に働きかける 手足 (ツール)
- 失敗したら もう一度まわすループ
- 結果を見て次の行動を変える 適応回路
これらを全部取り付けて、ようやく「自動車1台」になります。B1 でつかんでいただきたいのは、この感覚です。
最近のニュースには「agent」「エージェンティックAI」「AI employee」みたいな言葉がほぼ毎日出てきますよね。どこかの会社の記事で「AIエージェントを導入しました」という1文を見かけたとします。その会社に実際に何が入ったのか、チャットボットに少し装飾を足しただけなのか、本物の作業システムを取り付けたのか、この単語だけでは全然わかりません。ですのでこの記事の目的は、エージェントという言葉を 膨らんだバズワードから、構造のある概念へ引き下ろすこと です。
読み終わるころには、次の3つができるようになっていただきたいです。
- 「LLM とエージェントの違いはこれです」と、1文で答えられる
- Claude Code・Cursor がなぜエージェントで、ChatGPT はなぜ曖昧なのかを説明できる
- 誰かが「AIエージェントソリューションを売ります」と来たときに、それが本物のエージェントなのか、ただのAPIラッパーなのかを、5つの質問で見分けられる
では、始めます。
1. 「エージェント」という言葉がどんどん膨らんでいく理由
「agent」「AIエージェント」という言葉、最近使われすぎていますよね。私も技術ニュースをなぞっていると、1日に何十回と目にする感じです。「agentic retrieval」「agentic workflow」「AI agent employee」「autonomous agent」「agent-based AI」みたいな複合語まで入れると、ほぼマーケティング用語のレベルになりました。
流行語になった単語は 境界が崩れます。いま「エージェント」という言葉は、その段階に入っています。もともとは技術的にそこそこ具体的な意味をもっていたのに、マーケティング側が使い始めてから、「なんかAIが入っているもの」というくらいまで薄まってしまいました。
どれくらい薄まっているかというと、私が観察してきた使われ方だけでも、最低4つの層が混ざっています。
(1) 本物のエージェントを指す使い方。 LLM がツールを使い、失敗したらもう一度試し、結果を見て次の行動を変えるシステム。Claude Code で「このバグ直して」と言ったときに動いているのが、これです。いちばん厳密な使い方。
(2) チャットボットに少し機能を足しただけのものを、エージェントと呼ぶ使い方。 「AIエージェントがあなたの質問に答えます」みたいな宣伝文句。実際にはretrievalを1回くっつけただけのFAQボット、というケースが多いです。1回応答で終わるものはエージェントではないのに、言葉はもうくっついてしまっています。
(3) 自動化パイプラインの1ノードを、エージェントと呼ぶ使い方。 n8n・Zapier のようなワークフローツールで「LLM ノード」をひとつ足すと、それを「エージェント」と呼ぶケースがあります。流れ全体は人が設計しているのに、LLM が入ったノードだけ別にエージェントと呼ばれている。これは少し誇張された使い方です。
(4) SF 小説みたいなエージェント。 「自律的に働くAI employee」「人間のかわりに出勤するエージェント」みたいな言葉。現実に存在するシステムを指しているというより、将来そうであってほしい という願いに近いです。いまの基準で言うと、誇張です。
この4つの層が一つの単語の中に混ざっているので、「うちの会社にAIエージェントを導入しました」という1文だけでは、何が入ったのかまったく見えてきません。読者の方がどこかの競合記事を見て「あれ、うちも導入しないといけない?」と気になったとしても、まず 何を導入するか を特定しないと、判断が始まりません。
だからこそ、整理が必要なんですね。この記事はエージェントの いちばん狭い定義 を基準にして話します。(1) の層、つまり LLM にツールとループがついて、自分で複数ステップを実行するシステム だけをエージェントと呼ぶことにします。残りの (2)(3)(4) は、その変形か誇張として扱います。
これがなぜ大事かというと、この狭い定義があってはじめて、エージェントを ちゃんと評価する基準 ができるからです。あとで出てくる実務者向けチェックリストも、ここが土台になっています。
2. LLM 1回呼び出しは「応答マシン」・LLM をシステムに組み込むと「エージェント」
いちばん短くエージェントとLLMの境界を引く1文をお渡しします。
LLM を1回呼び出すのは応答マシンです。LLM をシステムの中に組み込むと、エージェントになります。
この1文に、ほとんどの核がつまっています。少しだけほぐしますね。
「LLM を1回呼び出す」というのは、ChatGPT のウィンドウに1回質問を書いて答えが返ってくる、あれのことです。API でいうと messages.create を1回呼んで終わり、ですね。これは応答マシンです。入力 → モデル → 出力。これで終わり。
「システムの中に組み込む」という部分が核心です。システムというのは、LLM の呼び出しの前後に別のコードがあって、LLM が出した出力を使ってさらに何かをする構造 のことです。たとえばこんな感じ。
- LLM が「search_web という関数を呼ぶべきだと思う」と出力したら、外側のコードが実際に検索を走らせ、結果を LLM に返す。
- LLM の答えが「これは失敗した、もう一度やり直したほうがよさそう」というシグナルなら、外側のコードが LLM をもう一度呼ぶ。
- LLM が「ファイルを編集すべき」と出したら、外側のコードが実際にファイルを編集し、編集結果を LLM に見せる。
この「外側のコードが挟まる」というところが、エージェントのはじまりです。外側のコードがなければ LLM はただの応答マシン。外側のコードがくっつくと、エージェントです。
比喩でもう一度いきます。LLM は とても賢いアドバイザー です。アドバイザーに「この文書を要約して」と頼めば、要約してくれます。でもアドバイザーは、自分の手でファイルを開けません。自分の手で検索を走らせません。自分の手でコードを実行できません。アドバイザーは、話すことしかできないんです。
エージェントは、そのアドバイザーの横に 実務担当の社員 がつく構造です。社員が「アドバイザーの指示どおりに」ファイルを開き、検索を走らせ、コードを実行し、結果をアドバイザーに見せる。アドバイザーは結果を見て、次の指示を出す。この往復がエージェントの動き方です。
この構図を頭に置いておくと、このあと出てくる5つの層が、全部「アドバイザーと社員のあいだの通信ルール」を決める装置として読めてきます。
3. エージェントをエージェントにする5つの層
エージェントというシステムが実際に動くためには、5つの層がかみ合っていないといけません。ひとつずつ見ていきます。
(1) 目標を受け取る層
エージェントは、人から「目標」を受け取ります。「このバグ直して」「この論文を要約して」「このデータセットを分析して」といった、1文のやつです。
この1文が大事です。普通のチャットボットはユーザーの「質問」を受け取ります。質問は、直接答えればそれで終わりです。ところがエージェントは「目標」を受け取ります。目標は答えではなく、複数ステップを経てたどり着く到達点 です。
たとえば「このバグ直して」という目標を1つ受け取ると、エージェントはこれを自分の中でこう分解します。「どのファイルを開こうか」「まずログを見たほうがいいな」「この関数があやしい気がする、確認してみよう」「修正してテストを走らせてみよう」というふうに。ユーザーはこの分解を直接指示しません。エージェントが自分でやります。
「1行の目標を、複数ステップの行動に翻訳できるか」 が、目標受け入れ層の核です。これができないと、ユーザーがステップ・バイ・ステップで全部指示しないといけなくなり、その瞬間、エージェントではなくただのチャットボットになります。
(2) 状態を見る層
エージェントは、今自分がどこまでやったのかを知っていないといけません。これが「状態」です。
状態はいろいろな要素からできています。どのファイルを読んだか、どんなコマンドを走らせたか、結果は何だったか、今何回目の試行か。これらすべてが、エージェントのワークスペースに積み上がっていきます。
F1 で話した「LLM はパラメータが固定で、記憶がない」という話が、ここでまた効いてきます。LLM 本体には記憶がありません。今回の呼び出しと次の呼び出しは、原則として切れています。ではエージェントはどうやって「これまで何をしたか」を知るのか。外側に状態を積んでおいて、毎回 LLM に見せ直している んです。
この外側の状態がないと、エージェントは毎回ゼロから考え直さないといけません。「さっきこのファイル読んだな」を忘れて、同じファイルをまた読み、また読み… これがなぜ重要かは、のちのち M3・M6 でさらに深く見ますが、いまは感覚だけでも十分です。
メーターの比喩に戻ると、状態を見る層は メーター + ブラックボックス です。今の速度・燃料・エンジン温度が全部見えていて、過去10分間どこを走ったかも記録されている。これがないと運転手 (LLM) は、目を閉じて運転していることになります。
(3) ツールを使う層 (tool use)
ここがエージェントの手足です。LLM 本体は、テキストしか出せません。でも現実で何かをするには、ファイルを開き、検索し、API を呼び、コードを走らせないといけません。この物理的な行動を LLM が直接できないので、「私はこのツールを使います」 と LLM が出力し、外側のコードがそのツールを代わりに実行する、という構造になります。
これが tool use あるいは function calling と呼ばれるものです。セクション7で詳しく扱うので、ここでは「手足の役割をする層がある」くらいで覚えておいてください。
(4) 1回で終わらなければ、もう一度やる層 (retry / loop)
現実で、エージェントが1回で成功することはほとんどありません。ファイルを開こうとしたらなかったり、コマンドを走らせたらエラーが出たり、テストを走らせたら新しい失敗が見つかったり。
そのときどうすればいいか。ここで選択肢が分かれます。
応答マシン型のシステム は「失敗しました」と出力して終わりです。ユーザーがまた指示しないといけません。
エージェント型のシステム は「失敗したな、なぜ失敗したか見よう、別のアプローチでもう一度試そう」を 自分で やります。ユーザーが割り込む必要がありません。
この「自分でもう一度まわす」構造が、loop です。loop がなければ、エージェントと呼ぶのはむずかしいです。1回まわして終わるのは、関数呼び出しであってエージェントではないので。
loop の設計は厄介です。長くまわしすぎるとお金がたくさんかかるし、短く切りすぎると解けるはずの問題も解けません。だから「何回まで試行するか」「どんな条件で諦めるか」「諦めたらユーザーに何を報告するか」みたいなルールが、エージェント設計の核のパートになります。M3・M6 で深く見ます。
(5) 結果を見て次の行動を変える層 (adaptation)
ここがエージェントの最後の層、いちばん人間っぽい部分です。
loop が「もう一度やること」だとしたら、adaptation は 「別のやり方でやること」 です。失敗したときに同じやり方でもう一度試しても、また失敗します。「あ、さっきはファイルパスがまちがっていたんだな、今回は別のパスで行こう」と、アプローチ自体を変えないといけません。
この変える判断を、誰がするのか。LLM がやります。なぜか。LLM はこれまでの状態 (ファイル、ログ、エラーメッセージ) を全部読めて、その上で「次に何を別のやり方でやるか」を判断できる唯一の部品だからです。外側のコードは一般的なルールしか書けなくて、「この状況ではこうする」という具体的な判断は LLM に任せることになります。
adaptation があってはじめて、エージェントが 未知の状況 に対応できます。既存の自動化 (Zapier・n8n のようなもの) には adaptation がありません。人があらかじめ書いたルールをそのまま回すだけです。想定外のエラーが出ると、止まります。エージェントは、想定外の状況でも自分で次の行動を選べます。これが既存の自動化とエージェントの 本格的な分岐点 です。
5つの層を1枚の絵で
人間:「このバグ直して」
· ログ確認
· テスト1回実行(失敗)
LLM:「次はファイルBを確認しよう」
read_file B 実行
→ 5. 適応(別アプローチ)
この5つの層が全部かみ合ったものが、エージェントです。1つか2つ欠けるとエージェントではありません。たとえば tool use だけあって loop がないものは「関数を呼べるチャットボット」。loop はあるのに状態追跡がずさんなものは「無限ループにはまるボット」。全部そろって、ようやく自動車1台になります。
4. 「ファイルを読んでは検索して、コードを走らせて、失敗したらまた試す」 — これがエージェントの本当の姿
抽象的な話ばかりだと感覚がつかめないので、実際のシーンをひとつ描きます。私が昨日 Claude Code に任せた作業を例にします。
「ブログ記事の発行スクリプトが、ときどき Polylang の言語連携を取りこぼす。原因を見つけて直して」という1文を投げました。そのあと私がやったことは、ありません。コーヒーを1杯入れて、窓の外を見ていました。20分後に戻ってみると、Claude がこんなことをやっていました。
publish_gate.pyをまず読みました。発行スクリプトがどう組まれているかを把握するためです。- その中から Polylang 関連の関数を見つけて、該当するモジュールを開きました。
- テストを走らせてみたけれど、いまの環境ではエラーが出ませんでした。ですので 直近のログを探して、失敗していたケースを拾いました。
- ログを読んで「言語設定のAPI呼び出しがまれにタイムアウトしている」というパターンを発見。
- 解決策として retry ロジックを入れ、失敗時に wp-admin リンクを案内する fallback を追加しました。
- 自分でテストを走らせ、通るのを確認したうえで私に報告してくれました。
私がやったことは たった1文投げただけ です。残りの6ステップは、Claude が自分で判断し、自分で実行しました。
これがエージェントです。ここに5つの層をもう一度当てはめてみましょうか。
- (1) 目標受け入れ: 「原因を見つけて直して」という1文を「複数ステップの行動」に翻訳した
- (2) 状態追跡: どのファイルを読んだか、どんなテストを走らせたか、ずっと覚えていた
- (3) ツール使用: ファイル読み、テスト実行、ログ検索、コード編集などのツールを順に呼んだ
- (4) ループ: テストが一度では再現できなかったので、ログで迂回して別アプローチ
- (5) 適応: 「再現できないなら過去ログをさらおう」という新しい作戦を LLM が自分で思いついた
このシーンがエージェントの日常の姿です。映画に出てくるような「自律AI」ではなく、1文を受け取って、複数ステップ実行して、結果を報告する社員 に近いです。いまのエージェントの現実サイズは、これくらいです。
そしてこれが ものすごく使えるサイズ なんです。過去の私がこういうバグ追跡を自分でやっていたら、30分〜1時間はかかっていたはずです。エージェントがその時間を「コーヒー1杯 + 20分」に縮めてくれた、ということですね。ここにエージェントの実務価値が出てきます。
5. あなたが使っている Claude Code・Cursor・Codex がエージェントである理由
F シリーズを読んできてくださった方の中に、Claude Code や Cursor をすでに使われている方が多いはずです。「これがエージェントだと明示的には聞いたことがない」という方もおられると思うので、お答えすると はい、この3つは全部エージェントです。それもかなり教科書的なエージェント実装です。
ひとつずつ5つの層に当てはめてみます。
Claude Code
- 目標受け入れ: ターミナルやエディタに「これ直して」のような自然言語の命令を1行
- 状態追跡: 今作業しているプロジェクトフォルダ全体を context として読めて、セッション間で対話履歴を保持
- ツール使用:
Read、Edit、Write、Bash、Grep、Globのような基本ツール + MCP で拡張される数十個の追加ツール - ループ: ひとつの作業が終わるまで LLM がまわり続けて状態を更新していく。人が止めるまで次のステップを自分で選ぶ
- 適応: エラーが出たら別のアプローチを試し、ファイルがなければ別のパスを探し、テストが失敗したらコードをもう一度直す
5つの層が全部あります。それもかなり精巧に。
Cursor
- 目標受け入れ: Composer に自然言語の指示、または Cmd+K でインライン編集のリクエスト
- 状態追跡: 開いているファイル、プロジェクトインデックス、対話履歴
- ツール使用: ファイル読み・編集・作成、ターミナル実行、ウェブ検索 (最近のバージョン)
- ループ: エージェントモードでは、複数ステップの作業を自分で実行
- 適応: 編集結果がテストで壊れたら修正、lint エラーが出たら直す
Claude Code とほぼ同じ構造です。違うのは主にUIの表層 (VS Code のフォークに埋め込んでいるのか、ターミナルで動いているのか) で、エージェント本体の原理は近いです。
Codex (OpenAI のCLIコーディングエージェント)
- 構造は Claude Code によく似ています。ターミナルで自然言語の指示を受け取り、ツールを使い、ループをまわし、適応します。細かいUXはちがいますが、5つの層は全部そろっています。
この3つの製品の共通点を一言でまとめると 「コーディングエージェント」 です。開発者の作業環境に LLM を深く埋め込んで、開発者が手作業でやっていた 「ファイルを読んで、修正して、テストして、失敗したらまたやる」 ループを LLM に委任した、ということですね。
これを実際に使われた方なら経験でわかると思うのですが、ChatGPT の画面にコードを貼りつけて質問するのとは、体感がまったく別物です。なぜ別物なのかというと、エージェントなのか応答マシンなのか、という違いが出てくるからです。
6. ChatGPT はエージェントなのか — 曖昧になるポイント
ここで少し厄介な質問が出てきます。「では、ChatGPT はエージェントなのか?」私は 曖昧です とお答えします。完全にエージェントではないけれど、一部エージェントの性質をもつハイブリッドです。なぜそうなるのか、層ごとに見ていきます。
- 目標受け入れ: ChatGPT は主に「質問」を受け取ります。1文の指示で複数ステップの作業を任せることにもだんだん慣れてきていますが、基本モードは対話型のQ&Aです。
- 状態追跡: セッション内の対話履歴は維持されます。Memory 機能 (長期記憶) がついて、ユーザー別コンテキストも一部積み上がります。ただし「ファイルシステムを見る状態」みたいなものは基本ありません。つけることはできますが、デフォルトのUXではありません。
- ツール使用: あります。ウェブ検索、Python 実行、DALL-E 画像生成、ファイル分析などのツールが、モードによって自動で入ります。
- ループ: 基本は1回答えて終わり。ユーザーが次を指示しないと次のターンが回りません。もちろん同じターン内で、モデルがツールを何度も呼ぶことはできます。Python を走らせて結果を見て、また走らせて、という具合に。だから 「1ターンの中のミニエージェント」 のような構造はあります。ただし Claude Code のように 複数ターンにわたって自律実行するエージェント は、ChatGPT のデフォルト形ではありません。
- 適応: 同じターン内でツール呼び出しが失敗すれば、別のアプローチを試すことはあります。ただ、複数ターンにわたる長期作業での適応は弱いです。
まとめると、ChatGPT は 「対話型インターフェース + 1ターン内のミニエージェント」 という構造です。本格エージェントではありません。ユーザーが1ターンで「全部」任せて、次のターンまで自動で流れてくれる、を期待すると、ChatGPT はその期待に応えにくいところがあります。
ただしこれはどんどん変わってきています。OpenAI が Operator、GPTs、Agent Mode のようなものをくっつけて、エージェント側に拡張しているので。ですから「ChatGPT はエージェントではない」と断じてしまうのも、数ヶ月後には古くなっているかもしれません。いまの基準でお答えするなら、「曖昧なハイブリッド」というのがいちばん正確です。
実務的には、こう区別されるといいです。「1ターンの答え」なら ChatGPT。「複数ステップの作業を任せる」なら Claude Code / Cursor のような専用エージェント。2つは用途が重なる部分もありますが、もともと別の製品カテゴリです。
7. Tool use — エージェントの手足
エージェントの5つの層のうち、いちばん実務に直結するのが tool use (関数呼び出し) です。ここに1セクション割いて少し詳しく見ます。
往復構造
Tool use は LLM と外の世界のあいだの往復構造です。順番で書くとこうなります。
- ユーザーが「今日の天気どう?」みたいに聞きます。
- LLM が 「これは自分が知らない情報だ、ツールが必要だ」 と判断します。
- LLM が JSON のような構造化出力を吐きます。たとえば
{"function": "get_weather", "city": "Tokyo"}みたいに。 - 外側のコード (agent harness) がその JSON を受け取って、実際に get_weather 関数を実行します。外部APIを叩いたり、DBに問い合わせたり。
- 関数の結果 (例:
{"temp": 14, "weather": "曇り"}) を LLM に返します。「あなたが呼んだ関数の結果ですよ」という文脈と一緒に。 - LLM はその結果を読んで 「東京は今14度、曇りです」 みたいな自然言語の答えを作ります。
この6ステップがひと往復です。必要ならこの往復が何回も回ることもあります。たとえば最初のツール呼び出しの結果が足りなければ、「あ、これでは足りないな、別のツールも呼ぼう」という感じで、また JSON を吐きます。
なぜこの往復が核心か
この往復構造がなければ、LLM は「自分が学習したデータ」の中でしか答えられません。外の世界に手を出せないんです。今日の天気、最新ニュース、私のファイルシステム、うちの会社のDB — どれもわかりません。
tool use が入ると、LLM は「必要な情報があればツールを呼んで取ってくる」方式で外の世界とつながります。手足がついたわけです。
2023年に OpenAI が function calling を API に正式導入してから、エージェント界隈が爆発しました。それ以前は LLM の出力を正規表現でパースしてツールを呼ぶ不安定な方式を使っていたのですが、構造化された function calling が標準になってから、エージェント構築がかなり安定しました。
ツール定義がエージェント品質を決める
どのツールを何個渡すか が、エージェント品質の大きな部分を占めます。少なすぎるとエージェントにできることがなくなり、多すぎると LLM が毎回「どのツールを使うか」で混乱します。ツールごとに 名前・説明・入力パラメータ をよく設計しないと、LLM がちゃんと選べません。
たとえば search という名前より、search_code_in_repo(query: str, file_type: str) のような具体的な名前のほうがいいです。ツールの説明には「いつ使うべきか」も書いてあげる必要があります。「このツールはプロジェクト内ファイル検索だけに使ってください。ウェブ検索は別のツールを使ってください」みたいに。
この「ツール定義」のステップが、エージェント設計でいちばん地味で、いちばん大事な部分です。モデルが良くてもツール定義がざっくりしていると、エージェントが的外れな動きをします。M4 (Harness Engineering) でもっと詳しく扱います。
毎週月曜日、AIトレンドニュースレター配信中
会員登録すると、毎週月曜日に「今週のAI・バイブコーディング最新情報」をお届けします。
バナー広告なし・本当に役立つ情報だけを厳選するクリーンなAI専門メディアです。
8. State — エージェントの記憶
5つの層のうち (2) 番が状態でした。ここをもう少し掘ります。
F1 で「LLM はパラメータが学習完了時点で固定され、それ以降は変わらない」と話しましたね。これがなぜエージェント設計で大事なのかというと、LLM そのものはセッション間の記憶がないから です。
ですのでエージェントの「記憶」は、いつも LLM の外 で管理されます。種類ごとに整理するとこうなります。
(a) セッション内コンテキスト (short-term)
いま対話中のメッセージ、さっき読んだファイル内容、さっき実行したコマンド結果。これらは、エージェントが LLM を呼び出すたびに プロンプトにまるごと貼りつけて、また送信します。100万トークンのコンテキストウィンドウ、みたいな話が出てくる理由がここです。コンテキストが大きければ、セッション内の記憶をもっと多く維持できます。
(b) セッション外の保管場所 (long-term)
ワークスペースのファイル、DB、外部メモリシステム。これは毎回呼び出しごとに全部貼りつけるのではなく、必要なときに tool で取り出して読みます。エージェントが「以前書いたメモを読むべき」と判断したら、read_file のようなツールを呼んで持ってくる、という感じです。
(c) 明示的なメモリシステム
OpenAI の Memory 機能や Claude の Memory Tool のようなもの。ユーザーごとに大事な情報を別の保管場所に積んでおき、対話の冒頭で自動的に取ってきます。「このユーザーは TypeScript でコードを書く」「このユーザーのプロジェクトは Next.js」みたいなのを覚えさせてくれるものです。
この区別がなぜ大事か
エージェントを設計したり評価したりするとき、「このエージェントはどこまで覚えるか」 が核の問いです。セッションが終わると全部忘れるエージェントなのか、次の日来ても前の対話を続けられるエージェントなのか、プロジェクトフォルダを読み続けて更新していくエージェントなのかが、UXと品質を大きく左右します。
Claude Code を例にすると、基本はセッション履歴がメモリに残り、CLAUDE.md というファイルに長期の指針を書くようになっています。別のプロジェクトで作業するときは、そのプロジェクトの CLAUDE.md を自動で読みます。このように「プロジェクト別の長期記憶」をファイルに外注した設計が、Claude Code の大きな強みです。
記憶を LLM の外に置く、という発想がなぜ大事なのかは、M シリーズ (M3・M6) で本腰を入れて掘ります。ここでは感覚だけつかんでください。「エージェントの記憶は LLM の中ではなく、外側にある」。この1文でじゅうぶんです。
9. Loop — エージェントをあきらめさせないもの
Loop は、エージェントの持久力です。1回失敗したらすぐ死んでしまうシステムは、エージェントとは呼べません。人のように 「あれ、これ通らないな、別のやり方でいってみるか」 を繰り返せないといけません。
Loop の基本サイクル
判断 → ツール実行 → 結果観察 → (成功?) → 次のステップ or 終了
↘
(失敗?) → 原因分析 → 別アプローチ → 判断に戻る
このサイクルが何回まわれるかが、エージェントの持久力です。過剰な loop はコストが爆発するので、ほとんどのエージェントは 最大反復回数 のような安全装置を置きます。たとえば「1作業につき最大50ステップまで回して、それを超えたら人に報告」みたいに。
Loop 設計のトレードオフ
loop を短くしすぎると、解けるはずの問題も解けなくなります。複雑なバグは5〜10ステップじゃ終わらないので。
loop を長くしすぎると、お金がすごい勢いでかかります。LLM API は呼び出しごとに課金なので、1作業で数百回呼ぶとすぐ数十ドルが飛びます。それに長く回るほど「見当違いの方向に脱線するリスク」も大きくなります。
だからエージェント設計で 「どれくらい回すか」 が、実務的にはいちばん頭が痛い問題のひとつです。作業の複雑度にあわせて適応的に調節するシステムもあれば、ユーザーに予算を先に設定させるシステムもあります。
Loop の途中介入
よいエージェントは、loop を 完全自律で最後までまわすのではなく、適切なポイントで人に確認をもらったり もします。「この作業を進めるにはプロダクションDBを修正する必要があります。進めますか?」のような確認ダイアログですね。
Claude Code は基本で 危険なコマンド (ファイル削除、force push 等) のときに確認をもらうように設計されています。こういう「確認ポイント」がどこに置かれているかが、エージェントの安全性を大きく決めます。完全自律エージェントは魅力的に聞こえますが、現実には「どこで止まるかをわかっているエージェント」のほうが、ずっと役に立ちます。
10. Harness — エージェントの作業環境 (次回予告)
ここまで読んでいただいて「ではエージェントの『外側のコード』は誰がつくるの?」という疑問がわいてきているかもしれません。正確な問いです。その外側のコード全体を harness と呼びます。
Harness は、エージェントが乗っかる 作業環境まるごと です。ツール定義、権限ルール、コンテキスト管理、エラー処理、状態保存、ループ制御、メモリシステム。LLM をとりまくインフラ全部が harness です。
この概念が重要な理由は、「よいエージェント = よいモデル」ではなく「よいエージェント = よいharness」 だからです。同じモデル (例: Claude Sonnet) を使っても、harness の設計しだいでエージェントの性能が何倍も変わります。Claude Code がうまく回る理由の大部分は harness 設計にあるのであって、モデルが特別に強いから、ではありません。
このテーマは M4 (Harness Engineering) 編で本腰を入れて掘ります。いまは 「エージェントはモデル + harness でできている」 くらい覚えておいてください。
11. 「よいエージェント」とは — モデルがいいのではなく、作業環境がいい
P2・P3 で似た話をしましたが、エージェントのセクションでもう一度強調したいところです。
多くの方がエージェントの話になると、「どのモデルがいちばんよいエージェントか」 を聞かれます。GPT-5 がエージェントなのか、Claude 4.7 がエージェントなのか、Gemini がエージェントなのか。この問い自体が少しずれています。
モデルはエンジンです。 エンジンはエージェントではありません。エンジン + シャシー + タイヤ + メーター + 燃料系統 = 自動車。エージェント = モデル + tools + state + loop + adaptation + harness。
だから「よいエージェント」を作ろうとしてモデルを変えても限界があります。同じモデルの上で harness をうまく設計すれば、ずっといいエージェントが出てきます。逆にどんなによいモデルを使っても、harness がずさんだとエージェントは見当違いの行動をします。
この話は実務で AI ツールを評価するときに、ものすごく大事です。同じ Claude 4.7 モデルを使っているからといって、Claude Code と「Claude 4.7 ベースの A 社ソリューション」が同じ品質、というわけではないんです。harness の設計水準がちがうかもしれません。モデルだけを見ずに、「このエージェントはどのツールを使うか、状態をどう管理するか、ループをどう制御するか」 をいっしょに見てください。
このテーマを本格的に扱うのが、M シリーズ (M1 〜 M6) です。特に M4 (Harness) と M5 (Context Management) が核です。
12. 実務者チェックリスト — エージェントの導入・購入評価5つ
ある日「うちの会社にAIエージェントを導入したい」という提案を受けたとします。あるいは新しいエージェントスタートアップの製品を評価しないといけなくなったとします。そのときに使える5つの質問をお渡しします。この記事で積み上げた5つの層を、チェックリストに変えただけのものです。
質問1: 「このエージェントは、1文の目標を受け取って複数ステップを自律で実行するか?」
→ この問いに「はい」と答えられなければ、それはエージェントではなく、ただのチャットボットです。「LLM が入ったFAQシステム」をエージェントと言って売ろうとするケースがあります。最初のフィルターです。
質問2: 「失敗したときにもう一度試すか、それともすぐ諦めるか?」
→ Loop のないシステムはエージェントではありません。デモのときに、わざと失敗するケースを入れてほしいと頼んでみてください。失敗後にどう対応するか、見てください。
質問3: 「これまで何をやってきたか、覚えているか?」
→ セッションの途中で「いま何やってた?」と聞いてみてください。とんちんかんな答えをするなら、状態追跡がずさんです。こういうエージェントには複雑な作業を任せにくいです。
質問4: 「ツールはいくつあって、それぞれどんな権限をもっているか?」
→ ツール一覧をドキュメントでくださいと頼んでみてください。3〜5個のツールだけを自慢しているエージェントは、使いみちが限られます。逆にツール50個で権限管理がざっくりしているエージェントは危険です。バランスが大事です。
質問5: 「このエージェントの harness は誰が設計したのか?」
→ 少し意地悪な質問ですが、本当に大事です。Harness 設計の経験があるチームが作ったものなら、製品品質の差がはっきり出ます。「ただ OpenAI API にプロンプトをくっつけて作りました」くらいのレベルだと、製品としての守りが弱いです。数ヶ月後に似た製品がうじゃうじゃ出てきたときに、勝てる理由がありません。
この5つを投げると、そのエージェントが 本物のエージェントなのか、ただのAPIラッパーにマーケティングだけくっつけたものなのか が、だいたい見えてきます。特に質問5がいちばん鋭いです。質問1〜4は答えやすいけれど、質問5は設計経験がないと答えられません。
閉じのひとこと
LLM はエンジン、エージェントは自動車1台です。自動車を自動車にするのはエンジン1つではなく、目標受け入れ・状態追跡・ツール使用・ループ・適応 の5つの層がかみ合って回る構造全体です。Claude Code・Cursor・Codex はこの5つの層を全部そろえた教科書的なエージェントで、ChatGPT は一部の層だけをもつハイブリッドです。次回はこの自動車が どんな燃料 (プロンプト) を食べて、どう動くのか を見ます。
FAQ
Q1. 「エージェント (agent)」と「エージェンティック (agentic)」は別の言葉ですか?
少しちがいます。「agent」は システム1つ を指す名詞です。Claude Code はエージェント、Cursor もエージェント。「agentic」は形容詞で「エージェントっぽい」という意味です。「agentic workflow」はエージェントが入り込んだワークフロー、「agentic retrieval」はエージェントっぽく検索するやり方。実務では「agentic」がもう少し広く使われていて、「agent」のほうがより厳密な定義をもつ、と考えていただくといいです。どちらも誇張して使われているので、注意は必要です。
Q2. AutoGPT・BabyAGI みたいなものは、エージェントですか?
はい。2023年に一瞬はやったあの子たちも、エージェントです。5つの層が全部そろっています。目標を受け、状態を積み、ツールを使い、ループをまわし、適応もします。ただし当時は harness 設計が未熟だったので、ループがよく脱線したりお金がたくさんかかったりしていました。いまの Claude Code・Cursor は、あの世代の教訓を受け継いで、ずっと安定的に進化した結果物です。AutoGPT を「初期の実験作」、Claude Code を「実用化された後続作」くらいに考えていただくといいかもしれません。
Q3. エージェントを自分で作ってみたいです。どこから始めればいいですか?
いちばん速い道は、OpenAI Assistants API や Anthropic Claude + function calling で、シンプルなエージェントを作ってみることです。ツールを2〜3個 (ファイル読み、ウェブ検索、計算機) だけくっつけて、シンプルなループを書いてみると、感覚がつかめます。フレームワークだと LangGraph や CrewAI のようなものがありますが、最初はフレームワークなしで「JSON のやりとり + while ループ」くらいのレベルで自分で書いてみるのをおすすめします。そうすることで、エージェントの骨組みが手になじみます。フレームワークは、そのあと複雑さが増えてから入れてください。このテーマは M3・M4 でコードレベルで扱う予定です。
- ◀ 前の編: F6. 学習とは何を学習しているのか
- 今の編: B1. AIエージェントとLLMの分かれ目 (8/20)
- ▶ 次の編: B2. プロンプトがモデルの中でやっていること
ニュースレターのご案内
こうしてひとつひとつの概念を最後まで解きほぐしていく記事を、毎週月曜日の朝にメールでお届けしています。受け取ってみたい方は ニュースレター会員登録(無料・30秒) からどうぞ。
著者: バイブコーディング テイラー(Lovable公式アンバサダー)
運営: テイラーの隠れ家(shuntailor.net)
LLMからAgentへの転換の位置にある編です。前後編のリンクは記事下部のマップ上の現在地ボックスで確認してください。
LLM(エンジン)とagent(エンジンを積んだ車)を分ける5つの層: 目標·状態·ツール·ループ·適応。Claude Codeがなぜagentで、ChatGPTがなぜ曖昧なのか。
ソースリスト
- テイラー知識百科事典 — AIのしくみ地図カテゴリ（本シリーズ20編全編）
- AIのしくみ地図 エントリーマップ — 全体構造 + 3つの読み方
- “Attention Is All You Need” (Vaswani et al., 2017)
- Anthropic · OpenAI · Google 公式ドキュメント
- mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown — 易しい解説のリファレンス
著者: バイブコーディング テイラー (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ「AIのしくみ地図」20編は、ウィキの蓄積と公式論文・公式ドキュメントを根拠に整理した体系的学習カリキュラムです。
