自社システムの中の AI エージェント：エージェントが単独で行ってよいこと、人が承認すべきこと、主導権を失わずに始める方法

AI エージェントとは、自社のソフトウェアに関数の実行、つまり支払いの照会、チケットの更新、返金の実行といった操作を求めることができる言語モデルである。モデルが行うのは依頼だけだ。それを実行するかどうかは自社のシステムが決め、そこで主導権を保つ。まずは一つの狭いタスクから始め、エージェントには単独でデータを読ませ、下書きを用意させる。お金を動かすもの、顧客の記録を変えるもの、社外に出るものはすべて、指名された担当者が承認する。

AI エージェントとは、平たく言えば何か

言語モデル、つまり ChatGPT の裏にあるのと同じ種類の AI は、テキストを生み出す。エージェントとは、自社のシステムの関数につながった言語モデルであり、その出力は答えだけでなく、操作にもなりうる。

Anthropic の Claude モデル向けドキュメントにはこうある：「ツール使用（関数呼び出しとも呼ばれる）により、Claude は、あなたが定義した関数や Anthropic が提供する関数を呼び出せる。」自社で定義した関数については、モデルは「アプリケーションが実行する構造化された呼び出しを返す」。モデルは依頼を書き、自社のソフトウェアがそれを実行するか拒否する。この記事の出典はすべて2026年11月2日に閲覧した。

エージェントはこれをループで繰り返す。タスクが終わるまで、関数を呼び出し、結果を読み、次のステップを選ぶ。Anthropic のエンジニアリングブログに2024年に掲載された記事は、エージェントを「たいていは、環境からのフィードバックにもとづいてループの中でツールを使う LLM にすぎない」と説明している。LLM は大規模言語モデル（large language model）の略で、ツールとは LLM が呼び出せる関数のことである。

つまり、エージェントにできるのは、その関数が許すことだけだ。関数の一覧はエージェントの職務記述書であり、最初に求めるべき文書である。

エージェントがデータを読むのか変えるのかが、なぜ重要なのか

読むことは何も変えないからだ。エージェントが顧客の直近5件の支払いを取り出して1件を間違えても、結果は誤った下書きであり、人が見つけられる。

書き込みは、モデルの外にある何かを変える。返金が支払われ、メールが顧客に届く。こうした変更の中には、取り消せないものもある。

エージェントの構築に関する OpenAI のガイドは、各関数を、「読み取り専用か書き込み可能か、取り消せるかどうか、必要なアカウント権限、金銭的な影響といった要素にもとづいて」、低・中・高のリスクに格付けすることを提案している。読み取りが低リスクのままでいられるのは、エージェントが読んだものをどこにも送れないあいだだけだ。その理由は、メールや文書に指示を仕込む手口であるプロンプトインジェクションについての節でわかる。

どの操作をエージェントが単独で行えて、どの操作に人が必要なのか

すべての関数を、三つのグループのいずれかに分ける：

• エージェントが単独で行う：データの読み取り、文書の検索、タグ付け、そして誰かが使うまで自社のシステムの中にとどまる下書きの作成
• エージェントが提案し、人が承認する：お金を動かすもの、顧客の記録や状態を変えるもの、社外にメッセージを送るもののすべて
• 決して任せない：アクセス権、上限、銀行口座情報の変更、そして規制当局が特定の担当者に下すことを求めている判断

ほとんどの関数は、次の四つの質問でグループが決まる：

• その操作は取り消せるのか。誰が取り消せるのか
• お金を動かすのか、あるいは顧客が負っている額を変えるのか
• その結果を、顧客、パートナー、規制当局が目にするか
• 法律、ライセンスの条件、あるいは自社の方針が、人が決めなければならないとしているか

OpenAI のガイドも、真ん中のグループについて同じことを勧めている：「機微な操作、取り消せない操作、重大な結果を伴う操作は、エージェントの信頼性に対する確信が高まるまで、人間による監視の対象とすべきである。」その例には、「ユーザーの注文のキャンセル、高額な返金の承認、支払いの実行」が含まれる。

OWASP というセキュリティプロジェクトが公開しているリスクの一覧である OWASP Top 10 for LLM Applications 2025 には、過剰なエージェンシー（excessive agency）という項目がある。エージェントが、タスクに必要な以上の関数、権限、自由を持っているときに引き起こしうる損害を扱うものだ。そこに挙げられている対策の一つは、「影響の大きい操作については、実行される前に人間の承認を必須とする」ことである。

サポート、オンボーディング、支払い、レポーティングでは、これはどうなるのか

どの分野でも、エージェントは読んで下書きを作り、判断は人の手に残る。自社のリストは、自社のシステムと、規制当局が求めることによって決まる。

• サポート：エージェントはチケットにタグを付け、返信の下書きを作る。最初のうちはすべての返信を人が承認し、返金と手数料の免除には常に承認が必要だ。エージェントが顧客のメールアドレスや電話番号を変えることは決してない。それを握った者は、誰であれ顧客のログインをリセットできるからだ
• オンボーディング：エージェントは書類に記入漏れがないかを確認し、担当アナリストのために要約する。リスク評価の変更は承認を待ち、顧客を受け入れるかどうかは人が決める
• 支払い：エージェントは銀行取引明細の各行を請求書と突き合わせ、合わないものにフラグを立てる。保留中の支払いの解除は承認を待ち、支払先の銀行口座情報をエージェントが変えることは決してない
• レポーティング：エージェントは、それぞれの数字の出典を付けて月次レポートの下書きを作る。顧客、取締役会、規制当局に送るものは、すべて人が承認する

承認のステップはどこに置くべきか

承認は、プロンプト、つまりモデルが受け取る指示の中だけでなく、関数を実行するソフトウェアの中に置く。モデルは、プロンプトの一行を無視することもあれば、言いくるめられてそれに従わなくなることもある。承認者のクリックなしには動かない返金の関数は、何を言われても言いくるめられることはない。

OWASP のガイダンスも同じ考えだ：「ある操作が許されるかどうかの判断を LLM に頼るのではなく、下流のシステムで認可を実装する。」

役に立つ承認画面は、承認者に次のものを示す：

• 操作の内容、それが変更する記録、金額
• 変更前と変更後の記録
• チケットや明細の行など、エージェントが根拠にしたもの
• 承認者が却下するときに必ず記入する理由

どの提案も数秒以内に承認されているなら、人はもう確認をやめている。EU AI Act には、これを指す名前がある。自動化バイアスだ。同法の人間による監視についての条文は、高リスクのシステムを監視する人が、「出力に自動的に依存し、または過度に依存する傾向が生じうること」を意識し続けられなければならないとしている。承認された操作のサンプルを、毎週確認し直す。

エージェントのアカウントには、どんな権限を持たせるべきか

エージェントのアカウントは、一覧にある関数だけを許し、それ以外は何も許さないようにする。エージェントには、それが触れるシステムごとに専用のアカウントを与え、管理者アカウントや社員のログインは決して使わせない。その権限は、モデルが変えられない、システム自体の側で設定する。パスワードとキーは自社のソフトウェアの中にとどめ、モデルの目に触れないようにする。

OWASP の例は、製品を推薦するエージェントで、それは「『products』テーブルへの読み取りアクセスしか必要としないかもしれない」。OWASP はまた、サーバー上で任意のコマンドを実行するような制限のない関数を戒め、それぞれが一つのことだけを行う狭い関数を勧めている。

エージェントが一人の社員のために働く場合、OWASP の言葉を借りれば、エージェントは「その特定のユーザーのコンテキストで、必要最小限の権限で」動くべきである。そうすれば、エージェントがその人以上のものを見たり、その人以上のことをしたりすることはできない。

プロンプトインジェクションとは何か。なぜエージェントにとってより重要なのか

プロンプトインジェクションとは、メール、チケット、アップロードされた文書など、エージェントが読むテキストに指示を仕込むことである。モデルは、その指示があなたからのものであるかのように従ってしまうことがある。指示は人が読んでも気づかないように隠すことができ、エージェントの場合はそれが操作に変わりうる。OWASP は2025年版の一覧でプロンプトインジェクションを第1位に挙げ、「プロンプトインジェクションを確実に防ぐ方法があるかどうかは不明である」と述べている。

OWASP の過剰なエージェンシーの項目は、受信したメールを要約するためにメールボックスを読むアシスタントを例に挙げている。そのアシスタントが使うアドオンは、メールを送ることもできる。細工されたメールにだまされたアシスタントは、受信箱から機密情報を探し出し、攻撃者に転送してしまう。

OWASP の対策は、メールを読むことしかできない関数と、メールボックスへの読み取り専用のアクセスから始まる。さらに、人が「LLM 拡張機能が下書きしたすべてのメールを手作業で確認し、『送信』を押す」必要がある。プロンプトインジェクションの可能性は排除できないので、エージェントがだまされた場合を想定して計画し、エージェントが与えうる損害を小さく抑えておく。

何をログに記録し、間違いはどう取り消すのか

すべての関数呼び出しをログに記録する。各エントリーには、エージェント、関数とその入力、結果、その呼び出しにつながったテキスト、モデルとプロンプトのバージョン、そして誰がいつ承認したかを残す。構築チームの外にいる人がログを読んで、特定の顧客に何が起きたのかがわかるようにしておくべきだ。

OWASP は、ログ記録とレート制限で過剰なエージェンシーを防ぐことはできない「が、引き起こされる損害の程度を抑えることはできる」と指摘している。レート制限とは、エージェントが一定の時間内に同じ種類の操作を何回行えるかに上限を設けるもので、誤った操作が続いても早い段階で止まる。

ローンチの前に、データを変える関数ごとに、その操作をどう取り消し、誰が行うのかを書き出しておく。キューで待機する返金のように、保留中のものを作る関数を優先する。保留中のものは削除できるが、送ってしまった支払いを取り戻すのは難しい。ソフトウェアのリリースなしでエージェントの関数を一度に停止できるスイッチを用意し、本番稼働の前にテストしておく。

法律は、人が承認しなければならないとしているか

EU では、AI Act が、高リスクに分類する AI システムについて、人間による監視のルールを定めている。そのルールは第14条にあり、附属書 III が高リスクの用途を列挙している。その一覧には、個人の信用力の評価や信用スコアの設定が含まれるが、金融詐欺を検出するシステムは除かれる。生命保険と健康保険における個人のリスク評価と価格設定も含まれる。欧州委員会の AI Act Service Desk は、附属書 III の高リスクシステムに関するルールの適用開始日を2027年12月2日としている。この日付は、Digital Omnibus on AI による変更を反映したものだ。こうした日付は動くことがあるので、それを前提に計画を立てる前に、最新のスケジュールを確認する。

第14条は、監視の措置はシステムの「リスク、自律性の水準、利用の文脈に見合ったものでなければならない」としている。システムを監視する人は、「いかなる状況においても、高リスク AI システムを使用しないこと、またはその出力を無視し、覆し、もしくは取り消すことを決定」できなければならない。また、「『停止』ボタンまたは同様の手続き」によってシステムを止められなければならない。

これらのルールが適用されるのは同法が列挙する高リスクのシステムだけであり、サポートや業務運営で使われる多くのエージェントはそこに含まれない。それでも、同じ管理策はそうしたエージェントにも理にかなっている。自社のシステムがこのルールの対象になるかどうかは、弁護士が判断する問題である。この記事は法的助言ではなく、扱っているのは EU のルールだけである。

主導権を失わずに始めるにはどうすればよいか

まず、そのタスクにそもそもエージェントが必要なのかを問う。Anthropic のエンジニアリングの記事は、「可能な限り単純な解決策を見つけ、必要なときにだけ複雑さを増す」ことを勧め、こう付け加えている：「これは、エージェント型のシステムをまったく作らないことを意味するかもしれない。」多くのタスクは、モデルへの1回の依頼か、決まった順序のステップで片づく。決まった順序のステップは、自らステップを選ぶエージェントより、ふるまいも予測しやすい。

週に多くの件数があり、ルールが明確で、間違いを安く直せるワークフローを一つ選ぶ。たとえば、サポートチケットの振り分けと返信の下書きだ。そのうえで、段階を踏んで進める：

• 今のワークフローを計測する：1件あたりの時間、やり直しになった件数の割合、週ごとの未処理の件数
• 実際の案件でエージェントをシャドーモードで動かす。エージェントは提案し、人はこれまでどおりに仕事をし、その二つを比べる
• 人が操作を一つずつ承認する承認モードに切り替え、承認者がどれくらいの頻度で修正や却下をするかを記録する
• 修正が最も少ない種類の操作に限ってエージェントに単独で行わせ、週ごとのサンプルの確認を続ける

どの数字に達したらエージェントを次の段階に進めるのか、そして誰がそれを決めるのかを、事前に取り決めておく。OpenAI のガイドは、「小さく始め、実際のユーザーで検証し、時間をかけて能力を広げる」という言葉で締めくくられている。Anthropic の記事は、「サンドボックス環境での広範なテスト」を勧めている。サンドボックス環境とは、間違えても何の損害も出ない、自社システムのコピーのことだ。

エージェントを本番稼働させる前に、何を確認すべきか

• すべての関数が三つのグループのいずれかに入り、自社の側に指名された責任者がいる
• 誰かが各システムでエージェントのアカウントを使って禁止された操作を試し、それが失敗することを確かめた
• 指示を仕込んだチケットと文書をエージェントに通し、グループが許す範囲を超えることは何も起きなかった
• どの顧客についても、エージェントが何をし、誰がそれを承認したかがログでわかる
• 新しいモデルのバージョンは、同じテストをもう一度実行してからでなければ本番に出ない

コード、プロンプト、ログは誰のものか

自社が所有すべきであり、契約にもそう書いておくべきだ。コードはエージェントの一部にすぎない。エージェントがどうふるまうかは、プロンプト、関数の一覧、承認のルール、テストケースが決める。そのすべてを成果物として名指しし、自社が管理するストレージに保管させる。

ログには顧客のデータが含まれるので、ログが記述する記録と同じアクセスルールと保持期間が必要になる。モデルが外部のプロバイダーで動いているなら、エージェントが送ったものをそのプロバイダーが保存するのか、保存するならどれくらいの期間なのかを尋ねる。

構築を任せる会社に何を聞くべきか

• エージェントが呼び出すすべての関数を、それぞれが属するグループとともに見せてもらえるのか
• 承認はどこで強制されるのか。自社のシステムか、そちらのコードか、それともプロンプトの中だけか
• エージェントは各システムでどのアカウントを使い、それ以上のことができないことをどうテストしたのか
• プロンプトインジェクションをどうテストし、テストで攻撃が成功したときはどうするのか
• 自社のコンプライアンスチームは、そちらの助けなしにログを読めるのか
• それぞれの操作はどう取り消され、エージェントはどれだけ早く停止できるのか
• 最終的に、コード、プロンプト、関数の定義、テストケース、ログのうち何が自社のものになるのか

amBrain はどこに位置づけられるか

amBrain は自社のプロダクトでエージェントを使っている。そのプロダクトについての一文はこうだ:「自社プロダクトのshyash.aiは、会社の事実を集めた一つの共有メモリをもとに、調査、執筆、確認、計測を行うAIエージェントで動きます。配信されるものはすべて担当者が承認します。」

amBrain が公に説明している、言語モデルを使った顧客のプロジェクトは、次の一件だ:「私たちは、顧客の FinTech 環境の境界内で LLM の統合を本番稼働させた:ブローカーや取引施設から届く非構造化の通知 ― コーポレートアクション、銘柄や証拠金の変更 ― を抽出・正規化し、トレーディングシステムが取り込む構造化された記録にするものだ。」

この記事は事例紹介ではなく、上の一文を超えて顧客のための仕事について述べてはいない。その一文はエージェントや承認については何も述べておらず、この記事も、amBrain が顧客のためにエージェントのシステムを構築しているとは述べていない。サポート、オンボーディング、支払い、レポーティングの例は一般的なものであり、amBrain の仕事から取ったものではない。

ここで名前を挙げた企業と団体は、それぞれが公開しているページから引用したものである。この記事は、amBrain とそれらのいずれかとのあいだに何らかの関係があるとは主張せず、amBrain の価格や期間も示さない。

amBrain は2019年からソフトウェアを作っている。働き方には三つの形態がある:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。所有権についての一文はこうだ:「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」上で挙げた質問は、検討するどの会社にも当てはまる。