AIエージェント
AIエージェントとは何か？従来のAIとの根本的な違い
公開日 ：
生成AIとAIエージェントの違いは、性能ではなく「実行するかどうか」にあります。AIの出力が情報から行為に変わったとき、企業が確認すべきことは何か。導入前に押さえておきたい基本を解説します。
リード
生成AIとAIエージェントは、どこがどう違うのか。性能の差ではありません。決定的なのは実行するかどうかの一点で、そして実行するようになった瞬間から、企業が考えなければならないことが変わります。
「AIが仕事をする」の意味が変わった
数年前まで、業務でAIを使うといえば、文章を要約させる、下書きを作らせる、調べ物の相談相手にする、といった使い方でした。AIは答えを返し、それをどう使うかは人が決める。この関係自体は、これまでのソフトウェアとさほど変わりません。
AIエージェントと呼ばれているものは違います。目的を伝えると、そこに至る手順を自分で組み立て、社内システムを操作し、外部に照会をかけ、必要ならデータを登録する。人が画面の前に座っていなくても処理が進んでいきます。助言者というより、実務担当者に近い存在です。
違いは、実行するかどうか
| 従来の生成AI | AIエージェント |
|---|---|
| 質問に答える | 目的に沿って手順を進める |
| 人が画面を操作する | AIがシステムを操作する |
| 人がファイルやメールを操作する | AIがファイルの読み書きや送信を行う |
| 判断も実行も人が担う | 実行の一部をAIに委ねる |
| 出力は文章や画像 | 出力は業務上の行為 |
最後の行が、両者を分けています。従来のAIの出力は情報でした。AIエージェントの出力は行為です。
失敗の質が変わる
要約を間違えたAIは、間違った文章を返すだけです。読んだ人がおかしいと気づけば、そこで終わります。損害は出ません。
資料の整理を任せたAIが、まだ使う予定の資料まで削除したらどうでしょうか。共有フォルダから消えたことに誰かが気づくのは、たいていそれが必要になったときです。バックアップがあれば戻せますが、なければ作り直すしかありません。
問い合わせへの回答を任せたAIが、社内限りの資料を添付して社外に送ってしまった場合は、もっと厄介です。送信を取り消すことはできません。相手の受信箱に届いた時点で、こちらの手を離れています。
実際に懸念されているのは、たとえばこんなことです。
- 資料の整理を任せたら、必要なファイルまで消えていた
- 問い合わせ対応を任せたら、社内限りの情報が社外に出ていた
- 社内の検索を任せたら、閲覧権限のない人事情報まで読み出してきた
- メールの下書きを任せたら、まだ公表していない内容が本文に入っていた
どれも、悪意のある攻撃を受けた話ではありません。AIが指示を素直に受け取って、こちらの想定より広く動いた結果として起こります。
同じ「AIが間違えた」でも、後始末がまったく違う。AIエージェントの導入で最初に押さえるべきなのは、この点です。
そして厄介なことに、この種の間違いを完全になくす方法はありません。AIは指示を自然言語として解釈します。解釈である以上、こちらの意図と違う読み方をする余地が残ります。処理の途中で読み込んだ資料やメールの中に、AIが指示と受け取ってしまう文言が混ざり込むこともあります。絶対に間違えないAIを前提にした設計は、成り立たないと考えたほうがいい。
なぜ、いま実用段階に入ったのか
AIが外部のツールや他のシステムを呼び出す仕組みが整い、複数のAIが役割を分担する構成が実用に耐えるようになり、システムへの接続方法が業界横断で標準化されはじめた。ここ数年で、こうした要素が重なりました。
おかげで、AIを既存の業務システムにつなぐハードルは大きく下がっています。試しに動かしてみるまでの距離が、以前とは比べものになりません。
ただ、その手軽さには副作用があります。部門ごとに独自のツールを導入し、それぞれが外部サービスと接続した結果、情報システム部門が全体像を把握できなくなっている企業が出はじめています。気づいたら社内のあちこちで誰かの作ったAIが動いている、という状態です。
実行するAIに、企業が問うべきこと
AIエージェントを業務に組み込むとき、確認すべきことは従来のシステム導入と少し違います。
- このAIは、誰の指示で動いているのか
- 何を、どこまで実行してよいことになっているのか
- その権限は、いつまで有効なのか
- 想定と違う動きをしたとき、どこで止められるのか
- 事故が起きたあと、何を根拠に実行されたのかを説明できるか
どれもモデルの性能とは関係のない問いです。AIが賢くなれば解決する種類の問題ではなく、仕組みで担保するしかありません。
導入前に決めておきたいこと
AIエージェントの導入で最初に決めるべきなのは、どのモデルを使うかではありません。間違えたときに、被害がどこで止まるかです。
実行できる範囲を区切り、期限を切り、何を根拠に実行したのかを記録に残す。この3点を最初から設計に入れておけば、誤作動が起きても損害は限定されます。逆にここを後回しにすると、事故が起きてから「なぜそれが実行されたのか」を誰も説明できない、という事態になります。
その具体的な手段のひとつが、VC（Verifiable Credentials）と呼ばれる仕組みです。改ざんされたことが分かるデジタルの証明書で、社員証や委任状にあたるものをデータとして持たせる、と考えると近いと思います。「このAIは営業部の共有フォルダを読むことはできるが、削除や社外への送信はできない」といった内容を証明として持たせておき、実行のたびにシステム側がそれを確認する。そういう使い方をします。
