AIエージェントに必要なのは、より良いプロンプトではなく権限システムだ：創業者のためのガイド

AIエージェントの失敗の多くは、モデルの弱さから始まるわけではありません。有能なモデルに、広い権限を持つAPIキーと、曖昧な指示と、行動する許可を与えたときに始まります。エージェントはデモでは完璧に動きますが、本番環境に出ると、間違った顧客にメールを送ったり、読み取るだけのはずだったレコードを書き換えたり、責任を持つ人間がはっきりしないまま高くつく変更を加えたりしかねません。

より良いプロンプトは、エージェントが次の一手を選ぶ助けになります。しかし、エージェントが何をしてよいかを決めるものではありません。それはプロダクトとシステム設計の問題です。エージェントを安全に実際のワークフローへ組み込めている創業者は、権限を第一級のレイヤーとして扱っています。ID、最小権限、承認ゲート、そして影響のあるすべてのアクションに対する監査証跡です。

根本的な転換：指示から権限へ

システムプロンプトには「$100未満の返金だけを行うこと」と書けます。しかしプロンプトは、認可の境界でもなければ、意図を記録として残すものでもありません。返金を実行するツール自体が、金額、アカウントの範囲、承認ポリシーを独立して強制しなければなりません。エージェントは文章を誤解するかもしれないし、信頼できない文書に従うかもしれないし、予想外のことを頼まれるかもしれない。そう想定してください。それでも、ツールは「ノー」と言えなければなりません。

• エージェントごとに固有のIDを与える。 カスタマーサポート、財務、エンジニアリングのワークフローを、共有の1つのサービス認証情報で動かしてはいけません。IDがあってはじめて、ポリシーの適用、権限の取り消し、調査が可能になります。
• 権限はモデルではなく仕事に結びつける。 モデルを変えたことで、アクセス範囲が知らないうちに広がってはなりません。「サポートの振り分け」を担うエージェントが何を読み書きできるかを定義し、そのポリシーを、タスクを実行するモデルがどれであっても適用します。
• ツールのレイヤーを最終的な判断者にする。 アクションを実行するAPIや関数が、何かを変更する前に、範囲、リソースの所有者、上限、承認を確認します。

MVPで機能する権限モデル

始めるのに巨大なガバナンス基盤は必要ありません。コンパクトなケイパビリティモデルを使いましょう。ツールの呼び出しのたびに、エージェントのID、限定されたアクション、定義されたリソースの範囲、有効期限を持たせます。認可サービスは、下流のシステムがリクエストを受け取る前にこれらを評価します。

1. 読み取り、下書き、実行を分ける。 送信、公開、削除、課金の能力を得る前に、まずはレコードの検索と下書きの作成をエージェントに任せます。価値のあるワークフローの多くは、直接の書き込み権限をまったく必要としません。
2. アクセスを1つのテナントと1つのタスクに絞る。 1つのアカウントに対応しているサポートエージェントが、すべての顧客を閲覧できてはいけません。デプロイ用のアシスタントは1つの環境だけで動作し、既定で本番環境を対象にしてはいけません。
3. 短命な認証情報を使う。 実行の開始時に範囲を絞ったトークンを発行し、タスクが終わったら失効させます。これにより、うっかりした再利用と、認証情報が漏えいしたときの被害範囲の両方を抑えられます。
4. ツールとパラメーターの範囲を許可リストで管理する。 エージェントが呼び出せるのは create_draft であって、汎用のデータベース実行機能ではありません。返金ツールは、エージェントが上限を覚えていることに頼るのではなく、$0〜$100だけを許可するようにできます。

影響の大きさに合わせて承認ゲートを設計する

人によるレビューは、自動化の失敗ではありません。境界をどこに置くべきかを学びながら、安全に自動化するための方法です。肝心なのは、取り消せない、金銭的に重大、外部から見える、あるいは修正が難しいアクションにレビューを絞ることです。無害なステップの一つひとつを人に承認させることではありません。

• 影響の小さいアクションは自動承認する。 受信したチケットの分類、CRMレコードの情報補完、返信の下書きは、範囲が制限され元に戻せるのであれば、人の監視なしで実行できます。
• 外部に向けたアクションにはワンクリックの判断を求める。 顧客へのメール送信、コンテンツの公開、価格の変更、支払いの開始では、エージェントが提案するアクションとその根拠を、指名された承認者に提示すべきです。
• しきい値でエスカレーションする。 明確なルールを決めます。一定額を超える返金、一定件数を超えるエクスポート、本番環境への変更には、いずれもより厳格な承認が必要です。ポリシーは運用担当者が読んで理解できるものでなければなりません。

監査証跡はプロダクトの機能である

チャットの記録だけでなく、もっと多くを記録してください。アクションごとに、エージェントのID、起点となったユーザー、ツール名、無害化した入力、ポリシーの判定、承認の状態、結果、そして実行の相関IDを残します。なぜその変更が起きたのかと顧客に尋ねられたとき、これが説明できるプロダクトとブラックボックスの違いになります。

これらの記録は、運用のためのデータにもなります。拒否された呼び出し、覆された承認、繰り返し起きるエッジケースを毎週確認してください。エージェントをどこで改善すべきか、ポリシーをどこで厳しくすべきか、どの承認ゲートが自動化できるほど成熟しているかが見えてきます。

創業者のための4週間の導入計画

1. 第1週： 範囲の狭いワークフローを1つ選び、そのワークフローが行える読み取りと書き込みのアクションをすべて洗い出す。不要なツールはすべて外す。
2. 第2週： 固有のエージェントID、テナント単位の認証情報、ツールの許可リスト、構造化されたアクションログを追加する。
3. 第3週： ワークフローを下書きモードで動かす。承認率、修正、失敗、ポリシーが拒否したリクエストを計測する。
4. 第4週： 低リスクで確信度の高い経路だけを自動承認にする。影響の大きいアクションは、データがより大きな自律性を正当化するまで、素早い人間による承認の後ろに置いておく。

結論

本番環境のエージェントには、2つの別々の問いへの明確な答えが必要です。このエージェントは何をすべきか、そして何をしてよいのか。前者に答えるのはプロンプトです。後者に答えるのは権限システムです。境界を早いうちに作り、チームと顧客に見えるようにしておけば、エージェントは信頼性を損なうことなく、より自律的になっていけます。

本番環境に安全に届くエージェントのワークフローを設計したいとお考えですか。無料のディスカバリーコールを予約する：AIのデモを頼れるプロダクトに変えるお手伝いをしています。

Related Posts

なぜAIは難しいのか：デモが動いた後に創業者がぶつかる本当の問題2026年7月1日

Claude Codeの/loopコマンド：2026年、より賢いコーディングワークフローのための使い方2026年7月3日

マルチモデル構成：スタートアップは2026年、AIコーディングのコストをどう85%削減しているのか2026年7月8日