Agent
読み: エージェント
エージェントとは自律型AIの基本
Agentとは、人間が与えた最終目標を達成するために、自ら計画を立て、必要なAPIやツールを操作しながら自律的にタスクを実行するAIプログラムである。単なるチャットボットとは異なり、推論と行動のループを回して結果を出す。
かんたんに言うと
指示待ちの新入社員ではなく、大雑把な指示だけで自ら手順を考え、社内システムを叩いて必要なデータを集め、報告書まで仕上げてくる中堅社員のような存在である。
考えてから動くを繰り返すAgentの推論と行動のループ
LLMを頭脳とし、外部ツールを操作する手足を持たせたのがAgentである。ReActと呼ばれるプロンプト手法が有名だが、要するに「考えてから動く」を繰り返す。
ユーザーが「競合の最新決算をまとめて」と指示する。
AgentはまずWeb検索APIを叩き、PDFを見つけ、パーサーに投げてテキストを抽出し、要約する。途中でリンク切れがあれば、別の検索クエリを試す。このエラーリカバリの挙動こそがAgentの真骨頂である。
ただ、プロンプトだけでこの挙動を安定させるのは骨が折れる。Difyのようなプラットフォームを使っても、ノードの接続が複雑になりすぎるとデバッグ地獄に陥る。どこまで自律性を許容するかは、設計者の腕の見せ所だろう。
現場の泥臭い業務に組み込む
Agentの真価は、APIが整備された裏側の業務で発揮される。例えば物流現場の配車計画である。
天候データ、渋滞情報、ドライバーの稼働時間。これらをGoogle Maps APIや社内の配車システムから取得し、最適なルートを計算する。DevinのようなソフトウェアエンジニアAgentが話題だが、実務で効くのはもっと地味な領域である。
法務部門での契約書レビューでも面白い使い方ができる。
過去の契約データベースをRAGで参照しつつ、条文の抜け漏れを指摘し、修正案をWordファイルとして直接生成する。ただし、法務特有の微妙なニュアンスをどこまでAgentに任せるかは判断が分かれる。最終的な責任は人間が取るしかないからである。
APIの壁とエラーハンドリングの現実
Agentを動かし始めると、すぐに外部システムの壁にぶつかる。
SalesforceやSAPのAPIレートリミットに引っかかり、Agentが途中でフリーズする。あるいは、WebサイトのDOM構造が突然変わり、スクレイピング用のAgentがエラーを吐き続ける。
自律的に動くということは、予期せぬエラーに遭遇する確率が跳ね上がるということ。
エラーが起きたとき、Agentにどうリトライさせるか。無限ループに陥ってAPI課金が爆発するリスクをどう防ぐか。このあたりの制御は非常に悩ましい。単にLLMの性能が上がれば解決する問題ではない。システム全体としての堅牢性が問われる。
既存システムとの親和性を見極める
Agentを導入する際、まず見るべきは社内システムのAPI対応状況である。
レガシーなオンプレミス環境で画面スクレイピングしか手段がないなら、Agentの導入は諦めたほうがいい。RPAの延長線上で無理やり動かしても、メンテナンスコストで首が絞まるだけである。
逆に、SlackやNotion、各種SaaSがAPIで綺麗に繋がっている環境なら、Agentは水を得た魚のように動く。
結局のところ、Agentが活躍できるかどうかは、受け入れる側のITインフラの成熟度に依存している。最新のAIモデルを追いかける前に、自社のシステム間連携がどうなっているか棚卸ししてみてはどうだろうか。
当社の見解
当社ではClaude Code・Antigravity・Codexの3つのAIエージェントを日常業務で併用している。記憶を共有しているため、別のAIに同じ説明を繰り返す必要がない。ただし、記憶共有だけでは足りなかった。一方のAIが他方の成果物を勝手に修正して壊す事故が起きた。これを受けてファイル所有権制度を導入し、どのAIがどのファイルを所有するかを定義した。AIの自主性に頼らず、仕組みで上書きや巻き戻りを防いでいる。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。