LLMとエージェントの違い

LLM(大規模言語モデル)は、テキストを入力として受け取り、テキストを出力する基盤モデルそのものです。質問応答や文章生成など、単発の対話に強みがあります。

エージェント型のAI(例:Claude Code)は、LLMを中核として、ファイル操作・コード実行・テスト・検索などのツールを自律的に組み合わせ、複数ステップのタスクを自分で計画・実行・検証するシステムです。LLMが「頭脳」、エージェントは「頭脳+手足+判断ループ」と言えます。

主な違いは次の通りです。

  • 動作範囲:LLMは1回の入出力で完結。エージェントは目標達成まで複数回のツール呼び出し・自己修正を繰り返す
  • 環境との接続:LLMはテキストのみ。エージェントはファイルシステム、ターミナル、APIなどの実環境にアクセスできる
  • 自律性:LLMは応答を生成するだけ。エージェントは計画立案→実行→確認→修正のループを自律的に回す
  • 状態管理:エージェントはタスクの進行状況やコンテキストを保持しながら作業を継続する

LLM自体はエージェントを動かす「エンジン」であり、エージェントはそのエンジンに自律的な実行能力を持たせたアプリケーションです。

複数のエージェントが動くとは

「人数」というより、同時に動く独立したLLMインスタンス(プロセス)の数の話です。それぞれが自分のコンテキスト・役割・タスクを持って並行または連携して動きます。

代表的なパターンは以下の3つです。

  • 並列分業型:大きなタスクを分割し、複数のエージェントが同時に別々の部分を担当する(例:1つはフロントエンド実装、別の1つはテスト作成を並行して進める)
  • 階層型(オーケストレーター/サブエージェント):「司令塔」エージェントが計画を立て、専門化したサブエージェントに作業を振り分けて結果を統合する
  • 役割分担型:コードを書く役、レビューする役、デバッグする役などを別エージェントに分け、互いの出力をチェックし合う

複数に分ける理由は、コンテキストウィンドウの節約、並列実行による高速化、専門化によるプロンプト・ツールの最適化、相互レビューによる品質向上などです。実態としては「複数の会話セッションが同時または連鎖的に動き、互いの出力をメッセージとして受け渡している」状態です。

ツールの使い方はどう学習したのか

LLMはテキストの学習だけでは、と思われるかもしれませんが、ツール呼び出しもテキスト生成の延長で実現されています。

1. 訓練時に学習した「ツール使用の型」

事前学習・ファインチューニングの段階で、コードやAPI呼び出しの例、ツール使用のデモンストレーション会話などを学習します。さらにツール使用に特化した強化学習(RL)も行われ、実際にツールを使ってタスクを達成する訓練を通じて、いつ・どのツールを・どう使うかの判断力が磨かれます。「ツールを呼び出す」という行為自体も、特定フォーマットのテキスト生成であり、LLMの基本能力の延長です。

例

python script.py --arg1 value

強化学習

複数の強化学習の手法が組み合わされており、人間を雇う方法と、雇わない方法の両方があります。

1. RLHF(人間のフィードバックによる強化学習)

これは実際に人間を雇っています。

  • 評価者(アノテーター)を雇用し、モデルの複数の出力を見せて「どちらが良いか」を選んでもらう
  • この選好データを使って「報酬モデル」(出力の良さをスコア化するモデル)を訓練する
  • その報酬モデルのスコアを使って、本体のLLMを強化学習で調整する

つまり人間が直接「正解」を書くわけではなく、「比較・評価」という形で関与します。専門知識が必要な分野(コーディング、医療など)では、その分野の専門家を雇うこともあります。

2. RLAIF / AIフィードバック

人間の代わりに、別のAIモデルが評価者になる手法です。

  • 既に訓練済みのモデルに「この2つの応答のどちらが良いか」を判定させる
  • これにより人間のアノテーションコストを削減し、大規模に評価データを生成できる

3. 検証可能な報酬による強化学習(RLVR)- ツール使用に特に重要

これは人間を必要としない、自動化された手法です。

  • コーディング: 「このコードはテストに通るか?」を実際に実行して自動判定
  • 数学: 「この計算結果は正解か?」を自動採点
  • ツール使用: 「このツールを呼び出した結果、タスクが成功したか?」を環境からのフィードバックで自動判定

ツール使用の学習においては、この手法が特に重要です。モデルに実際に(サンドボックス環境で)コマンドを実行させ、「目的のファイルが作成されたか」「エラーが出たか」「テストが通ったか」といった結果を自動的にスコア化し、成功する行動パターンを強化していきます。これは人間の判定を介さず、環境からの客観的なフィードバックで完結します。

ツール使用・コーディング・エージェント能力 → RLVR(自動化)が主流

  • スケールの違い: 人間の評価には限界があるが、自動採点(テストが通るか、コマンドが成功するか)は何百万回でも高速・低コストで繰り返せる
  • 客観性: 「このコードは動くか」は人間の主観に左右されない、明確な正解がある
  • 近年の能力向上の主因: 2024年以降のコーディング・エージェント性能の大幅な向上は、このRLVRによる大規模な訓練が大きく貢献していると言われている

つまり「ツールの使い方」「コマンドの組み立て方」「エージェントとしての行動パターン」を磨く部分では、人間を雇うアプローチはコスト的に非現実的で、自動化されたフィードバックが主流です。

応答の質・安全性・トーン・価値観 → RLHF(人間)が依然重要

  • 「親切さ」「丁寧さ」「有害な内容を避ける」「自然な文章として読みやすいか」といった、客観的な正解がない領域は、自動採点が困難
  • こうした領域では今でも人間の評価者(専門家含む)が関与します

2. 実行時に与えられる「ツールの説明書」

個別の具体的なツールについては、モデルが事前に記憶しているわけではなく、会話の都度システムプロンプトに「このツールはこういう名前で、こういう引数を取り、こういう動作をする」という説明(スキーマ)が渡されます。モデルはその説明を読んで、訓練で得た「ツール呼び出しの型」に当てはめて使います。

人間が「初めて触る家電でも説明書を読めば使える」のと同じで、「ツールを使うスキル」は訓練済みだが、「個々のツールの詳細」はその場で読んで対応している、という構造です。

コマンドの境界判断はテキストから学べるのか

「実行可能ファイルの起動」や「どこからどこまでがコマンドか」の判断も、テキストから学習可能です。

コマンドも結局はテキスト列

bashコマンド、ファイルパス、引数の区切りなどは、すべて文字の並びです。ls -la /home/user も python script.py --arg1 value も、見た目は普通の文章と同じ「トークンの連なり」に過ぎません。LLMにとっては、自然言語の文章を生成するのと、コマンド文字列を生成するのは、本質的に同じ「次のトークンを予測する」タスクです。

学習データには大量の実例がある

GitHubのコード、Stack Overflowのやり取り、技術ドキュメント、man page、READMEのインストール手順など、訓練データには「どういう状況でどういうコマンドを打つか」という実例が膨大に含まれています。これにより、構文構造(スペース区切り、フラグの形式、パイプの意味など)を統計的に学習できます。

「どこからどこまでがコマンドか」の処理

これは2つのレイヤーで処理されています。

  • モデルの判断:モデルは「このタスクを実行するにはこのコマンド文字列を生成すればいい」と判断し、コマンド全体をテキストとして出力する
  • システム側の処理:そのテキストをツール呼び出しの引数として構造化フォーマットで出力するよう訓練されているため、「これはコマンド文字列です」という境界はフォーマット自体が明示している

モデルが構文解析をしているわけではなく、「この形式で出力すればシステムがコマンドとして実行してくれる」というパターンを学習し、その中身は普通のテキスト生成と同じ仕組みで生成しています。実行結果(エラーメッセージなど)が返ってくると、それをテキストとして読んで次の行動を調整します。

実行可能ファイルの起動(python script.py、./my_program、npm start など)も同様で、READMEやチュートリアル、Dockerfile、CI/CD設定ファイルなどから「ファイルの種類・拡張子・言語に応じてどういうコマンドで起動するのが一般的か」という対応関係を統計的に学習しています。

UIを「見て」操作することはできるのか

通常のテキストのみのLLMは、UIを見ることも操作することもできません。

  • 通常のLLM(テキストのみ):画面のスクリーンショットを認識する能力はなく、テキストベースの情報しか扱えない
  • マルチモーダル対応モデル:画像を入力として受け取れるため、スクリーンショットを見て「このボタンはここにある」といった視覚的情報を認識できる
  • UI操作エージェント:スクリーンショットを撮影してモデルに渡し、画面上の座標を指定してクリック・ドラッグなどの操作コマンドを生成し、操作後に再度スクリーンショットを撮って結果を確認する、というループを繰り返す

つまり「見る」のはスクリーンショットという画像データを画像認識能力で処理しているのであり、操作自体は「座標やコマンドというテキスト(構造化データ)を生成する」という仕組みに帰着します。「UIを直接操作する」専用の感覚があるわけではなく、画像認識とコマンド生成という既存の能力の組み合わせで実現されています。

結局、CUIでできることしかできないのか

概ね正しいですが、補足が必要です。

エージェントが実際に何かを「行う」手段は、最終的にすべてツール呼び出し(構造化されたコマンド/関数呼び出し)に帰着します。これは広い意味でのCUI的な操作と言えます。

「CUIでできること」の範囲は思った以上に広く、xdotool(Linuxでマウス・キーボード操作をCUIから行う)やSelenium・Playwrightのようなブラウザ自動化ツールを使えば、GUI操作自体もコマンド化できます。また多くのアプリは裏側にAPIを持っており、GUI画面の操作と同じ結果をAPI呼び出しで実現できる場合もあります。

ただし重要な制約があります。

  • そのコマンド/ツールが用意されているかどうかが全て。用意されていない操作は、モデルがいくら賢くても実行できない
  • 視覚的に確認して微調整する操作(ピクセル単位のクリック位置調整など)は、画像認識+座標指定コマンドという形で間接的に対応可能だが、人間が直感的にやる「感覚的な操作」とは精度・効率が異なる

GUI操作のコマンド化に立ちはだかるデータの壁

ここで重要な限界があります。CUIコマンドはテキストとしてネット上に大量に存在しますが、「GUI上でどこをどうクリックしたか」という操作シーケンスのデータはほとんど存在しません。人がGUIを操作する様子は、テキストとしてログに残らないからです。

現状の対処法には、それぞれ限界があります。

  • 専用の訓練データを別途作る:「画面のスクリーンショット」と「次にクリックすべき座標」のペアのデータセットを、人手のデモンストレーションや合成データで作成し、追加で訓練する
  • 座標予測自体の精度問題:画面上の正確なピクセル座標を当てるのはテキスト生成とは異質なタスクで、画像内の物体検出に近い能力が必要になり、これも別途学習が必要
  • 構造化情報へのフォールバック:スクリーンショットだけでなく、HTML構造やアクセシビリティツリー(要素の名前・役割・位置情報がテキストで取得できる)も併用し、「テキストとして扱える」情報に変換する

「GUI操作をコマンド化できる」というのは可能性の話であり、実際にうまくやらせるには専用のデータセットと訓練、またはGUIをテキスト構造に変換するツールのどちらかが必要です。テキストだけ学習したLLMがそのまま自然にできることではなく、通常のLLM訓練の範囲外にある、別個の能力・データが必要な領域なのです。

まとめ

エージェント型AIの能力は、LLMが持つ「テキスト生成」という基本能力の延長線上にあります。コマンドの生成、実行可能ファイルの起動、ツールの使い方も、すべて「適切な形式のテキストを出力する」という同じ仕組みで実現されています。一方でGUI操作のように、テキストデータがそもそも存在しない領域は、別途専用のデータと訓練が必要であり、LLMの汎用的な言語能力だけでは自然に獲得できない、明確な限界が存在します。

関連記事:

  1. LLMはなぜコードが書けるのか？現状・限界・リスク
    ChatGPTやClaude、GitHub CopilotなどのLLM（大規模言語モデル）が、プログラムコードをすらすら書く姿を見て「なぜ？」と思ったことはないでしょうか。また、実際に使ってみると「意外と使えない場面もある」と感じた方も多いはず。 この記事では、LLMがコードを書ける仕組みから、現在の実用レベル、エラーを防ぐ方法、そして将来の限界までを解説いたします。 なぜLLMはプログラムが書けるのか コードも「テキスト」だからです。...
  2. 2026年版｜中国系AI APIは本当に危険なのか？DeepSeek・Qwen・GLMを価格・性能・セキュリティで徹底比較
    生成AIブームが続く中、2025〜2026年にかけて急速に存在感を高めているのが、中国系LLM（大規模言語モデル）です。 特に、 DeepSeek Qwen GLM...
  3. 【完全無料】Ollamaで“ChatGPTみたいなAI”をローカルPCで動かす方法｜VRAM 8GBでもOK・セキュリティ安心
    「ChatGPTみたいなAIを、自分のPCだけで無料＆無制限に使いたい」 そんな人におすすめなのが、ローカルAI実行ツール Ollama と、高性能モデル DeepSeek-R1...
  4. Python（embed版）でCUDA対応PyTorchを使ったGPU推論環境の作り方
    はじめに 最近のGPU環境では「CUDAは自動で入っているのか？」「PyTorchはどこまで自動でやってくれるのか？」といった疑問を持つ人が多いと思います。 この記事では、Pythonのembed版（ポータブル環境）でCUDA対応PyTorchを使ったGPU推論を行う方法を、最小構成でわかりやすく解説します。 結論（重要ポイントまとめ） RTX...
  5. PyInstallerでStable DiffusionやQwenなどAIアプリをスタンドアロン化する方法と注意
    Python製のAIアプリ（Stable Diffusion、Qwen、Wanなど）を「Python未導入のPCでもそのまま動くスタンドアロン実行ファイル」にしたい場合、よく使われるのが PyInstaller です。 pip...
  6. AIによるソフトウェア開発でコードが増えれば増えるほどAIのコーディングパフォーマンスが低下する問題
    当社ではエージェント型AI(自分でプロジェクト全体のコードを大まかに調査把握できる)も含めて使ってみてAIでどれだけソフトウェア全体を構築できるのかを制作しながら実験していますが、その際にコードが増えれば増えるほどAIのコーディングパフォーマンスが低下する問題が発生することが体感としてわかってきました。 AIを使ったソフトウェア開発は急速に普及していますが、実際に使ってみると「Aiの作業がどんどん遅くなった」「コードが大きくなればなるほどバグが増えた」という経験をする人も多いはずです。この記事では、AIとの開発でよく起きる問題とその原因、効率的な使い方のコツ、そして今後の展望まで、解説します。 1. AIでの開発で作業が遅くなる・バグが増えるのはよくあること？ 結論からいうと、よくある問題です。...