AIエージェントを作ること自体は難しくありません。言語モデルをループの中に置き、いくつかのツールを渡せば、既存のフレームワークで動くデモはすぐに組み上がります。難しいのはデモの後です。クラウドで24時間動かし続け、エージェントが何をしたかを記録し、繰り返し実行できるテストで採点し、本番の仕事を任せられるまで失敗を一つずつ直していく。エンジニアリングの労力の大半が向かうのは、エージェントの中核ロジックではなく、こうした本番運用のための作業です。
人が回すループからエージェントループへ
いま多くの人が大規模言語モデルをどう使っているかを考えてみます。たとえばReactのコンポーネントが欲しいとします。プロンプトを入力し、回答を読み、十分かどうかを判断します。足りない点があれば、もう一度質問します。満足できるまで、質問と回答のサイクルを自分で回し続けることになります。
AIエージェントはこのサイクルを引き受けます。人が与えるのは最初の目標だけで、その後はエージェントが各ステップで最終回答を出すか、ツールを呼び出すかを自ら決めます。ツールを呼び出したり途中の結果を出したりすると、その出力は人を介さずにそのままループに戻り、次の判断のためのコンテキストになります。このサイクルをエージェントループと呼びます。1回で終わることも何度も回ることもあり、エージェントがタスクを終えたと判断した時点で止まります。
| 従来のLLMの使い方 | AIエージェント | |
|---|---|---|
| 繰り返しを回す主体 | 人 | エージェント |
| 次のステップ | 人が次のプロンプトを入力 | エージェントが回答かツール呼び出しかを選ぶ |
| 途中の出力 | 人が読んで判断 | 自動的にループへ戻る |
| 終わるタイミング | 人が満足したとき | エージェントがタスク完了と判断したとき |
二つの構成要素：ループとツール
エージェントを削ぎ落とすと、二つの考え方が残ります。
エージェントループ
ループとは、while文のような通常の制御コードで言語モデルを包み、停止条件を満たすまで動かし続ける仕組みです。モデルが「done」のようなあらかじめ決めた停止の合図を出すと、ホストプログラムの決定的な解析コードがそれを検出してループを抜けます。
ツール
言語モデルは単体ではテキストしか生成しません。それを変えるのが構造化出力、つまり周囲のコードが解析できる決まった形式に従った応答です。ラッパーコードはモデルの出力を関数の引数として読み取り、それを使って実際のソフトウェアの関数を呼び出せます。こうしてエージェントはAPIリクエストを送り、ウェブを検索し、データベースに問い合わせ、シェルコマンドを実行します。こうした決定的な関数を選んで呼び出せることで、テキストを予測するだけのモデルが、現実の世界に変化を起こすソフトウェアになります。
エージェントに仕事を与える：AI社員
汎用のエージェントを作れるようになったら、次は一つの役割に特化したエージェントです。これはAI社員と考えることができます。違いは、担当範囲、使えるツール、動作する環境のすべてが特定の職務に合わせて設計されている点にあります。
- ソフトウェアエンジニア：ファイルシステム、コード編集ツール、コードをプッシュしてレビューするためのGitHubへのアクセスを与え、リポジトリを移動し、ファイルを変更し、自分の作業をテストできる隔離された環境の中で動かします。
- 営業担当者：CRM（顧客関係管理システム）、Gmailのようなメールツール、ウェブ検索を与え、見込み客を調べて連絡できるようにします。
- カスタマーサポート：同じ考え方で、役割に合ったツールと環境を用意します。
実際には、AI社員を設計するとは、組織の構造を調べ、役割ごとに十分な装備を備えた別々のエージェント環境を描き出すことです。
▲ 役割ごとに装備を備えたAI社員
最初のエージェントが期待外れになる理由
あるタスクのために最初に作るエージェントは、周辺の仕組みがなければほぼ確実に性能が低くなります。出来の悪い社員のように振る舞うエージェントを、シニアエンジニア並みに働くエージェントへと引き上げるには、本格的なエンジニアリングの規律が必要です。コードを書くエージェントでも、営業やサポート対応のエージェントでも同じです。必要な支援作業は七つの領域に分かれます。
| 領域 | 解決すべきこと |
|---|---|
| デプロイ | 長時間動くエージェントは、短時間で終わるものよりクラウドで安定させるのがはるかに難しい |
| オブザーバビリティ | エージェントが割り当てられたタスクをこなしているのか、でたらめを作り出して軌道を外れているのかを把握する必要がある |
| テレメトリー | 24時間動くエージェントは膨大な実行データを出すため、有用なシグナルをノイズから切り分けなければならない |
| 評価 | 人による監督と組み合わせた定量的な評価で、エージェントが現時点で実際に何をできるかを示す |
| 人による監督 | 自動のスコアと並行して、人がエージェントの作業をレビューする |
| バージョン管理 | 本番環境でのA/Bテストで二つのバージョンを並べて動かし、改善を確認してから展開する |
| 改善ループ | エージェントが各実行とその中の各ステップの記録であるトレースとスパンを出し、評価スイートが採点し、エンジニアが失敗パターンを一つずつ直す |
ここで目を引く点が二つあります。一つは、稼働中のシステムが自身について報告する実行データであるテレメトリーは、集めるだけでは役に立たないことです。賢いフィルタリングがなければ、その量に埋もれてエージェントの改善に必要なシグナルが見えなくなります。もう一つは、改善ループに本当の終わりはないことです。本番のエージェントは、動いている限り継続的な評価、トレース、改良を必要とします。
ノートPCから信頼できるエージェントまでの6ステップ
これを身につける最も確かな方法は、実際に作ることです。道筋は6段階あります。
- ローカルで一つ作る。 自分のマシンで外部ツールを呼び出せるエージェントループを書き、簡単なタスクを与えます。
- デプロイする。 クラウドに移し、24時間動き続け、ノートPCを閉じても止まらないようにします。チームメンバーや権限を持つ人が、いつでもアクセスして監視できるようになります。
- 観察する。 エージェントが何をしたか、どんな経路をたどったか、タスクに忠実だったかという基本的な問いに答えられるオブザーバビリティを整えます。
- 評価する。 たとえば100件のテストのような決まったシナリオ群を実行し、信頼性を数値で得ます。100件中90件に合格したなら、残る10件の失敗が調べるべきケースです。
- 改善する。 見つかった失敗パターンを一つずつ直します。
- 信頼できるものにする。 観察、評価、改善のサイクルを繰り返し、本番で頼れる品質に達するまで続けます。
この道筋をたどり終えたエージェントがあれば、最初の有能なAI社員を作るための中核的なスキルが身についていることになります。
AI社員からAI企業へ
信頼できるAI社員が一つできたら、次は多数のエージェントがAI企業として協働する段階です。この時点で主なボトルネックは個々のエージェントのロジックから、エージェント間の調整と全体設計の拡張性へと移ります。
ここで重要なのは、AI社員を一つずつ孤立して作らないことです。すべてのエージェントが共通の基盤と単一のインフラ層を共有すれば、同じ作業の繰り返しを避けられ、多数のエージェントを一貫して作成、設定、運用できます。多くのテクノロジー企業が専用のAIエージェントプラットフォームに多額の投資をしている理由も、こうした調整への需要で説明できそうです。
その結果生まれる組織は、比較優位に基づいて仕事を分け合うハイブリッド型になる可能性が高いでしょう。AI社員は、大量のデータの解析、要約、統合といった大量処理のバックオフィス業務に強みを持ちます。人は創造的、戦略的で人間ならではの仕事に集中し、エージェントが会社の目標に向けてどう協働するかを監督します。
▲ 共通基盤の上に築くAI企業
こうした調整がどのような形になるかは、ある就職活動支援プラットフォームが示しています。履歴書コーチのエージェントは、アップロードされた履歴書を確認し、卒業時期や学校の情報といった抜けている項目を指摘して、該当部分を書き直します。面接用のエージェントはコーディング、システム設計、行動面接をそれぞれ担当し、コーディング試験は2問、制限時間60分、対応プログラミング言語3種類で構成されます。さらに役割を逆転させるエージェントもあります。このエージェントは初心者の学生を演じ、ユーザーは二分探索のような概念をそれに教えなければならず、エージェントはユーザーのコードの習熟度、伝え方、正確さを採点します。目標は、これらのエージェントを一つの流れにつなぎ、応募から内定まで候補者を導くことです。
次にやるべきこと
AIエージェントとは、ツールを使えるループの中に置かれた言語モデルであり、その構造は単純です。デモと頼れるシステムの本当の違いは、その周りにあるすべてのものにあります。エージェントを作っているなら、実践的な作業順序は次のようになります。
- まず自分のマシンで、ツール呼び出しができる小さなエージェントループを書く。
- 早い段階でクラウドに移して24時間動かし、すべての実行についてトレースとスパンを記録する。
- 繰り返し使える評価スイートを作り、100点満点のスコアを追跡し、見つかった失敗を直す。
- 新しいバージョンは切り替える前に、A/Bテストで前のバージョンと比較する。
- 複数のエージェントを動かす予定なら、最初から共通の基盤を設計する。
動くデモは出発点であって、ゴールではありません。観察、評価、改善の仕組みを早めに整えることが、本当に頼れるエージェントへの近道だと考えられます。