AIエージェントと従来型SaaSアプリケーションの違い

従来型SaaSは、プロダクトチームが事前に定義したワークフローを実行します。AIエージェントは目標の達成に向け、実行時に手順の一部を選びます。この違いによって、権限、テスト、インターフェース、障害処理、単位コストが変わります。

多くのプロダクトには両方が含まれます。サポートアプリケーションでは、通常のコードで顧客を認証して請求書を取得し、曖昧な請求内容の調査だけをエージェントに任せられます。プロダクト全体をエージェント型と呼ぶと、エンジニアが制御すべき境界が見えなくなります。

ワークフローはどこで決まるか

SaaSでは、プロダクトが許可された経路をコードに組み込みます。ユーザーが請求書を選び、返金をクリックし、金額を確認して結果を受け取るまで、インターフェースとバックエンドはリクエスト開始前から起こり得る状態を把握しています。

エージェントは目標から始め、与えられたコンテキストに基づいてツールを選びます。検索結果、ツールエラー、モデルの選択が異なれば、2回の実行が別の経路をたどることもあります。それでもアプリケーションは、どの経路を許可するかについて厳格なルールを設ける必要があります。

OpenAIのエージェント構築実践ガイドは、複雑な判断、壊れやすいルール、大量の非構造化データを伴うワークフローにエージェントを推奨しています。通常のコードで判断を表現できるなら、固定ワークフローの方が明快な設計です。

エンジニアリング上の違い

メモリ、ツール、状態、永続実行を含むアプリケーションアーキテクチャは、これらの違いから直接導かれます。

最初に変わるのは権限設計

SaaSのボタンは、範囲の狭い一つのアクションとして一つのエンドポイントを呼び出せます。エージェントは20個のツールから選び、プロダクトチームが記述していない順序で組み合わせる可能性があります。バックエンドは呼び出しごとに、現在のユーザー、テナント、リソースに対して認可しなければなりません。システムプロンプトに書かれた一文では、アクセス権を付与したり取り消したりできません。

OWASPのExcessive Agencyガイダンスは、過剰な機能、権限、自律性を分けて扱っています。これはレビューに役立つ分類です。ワークフローに不要なツールを削除し、残した各ツールの認証情報を狭め、影響の大きいアクションの前に承認を求めます。

テストは振る舞いを対象にする

単体テストでは、返金関数が負の金額を拒否することを証明できます。しかし、ユーザーが返金を求めたときだけエージェントが返金ツールを必ず選ぶことまでは証明できません。そのためエージェント評価には、代表的なタスク、期待するツール選択、禁止アクション、反復実行が必要です。

出力だけでは不十分です。別テナントの記録を読んで生成した正しい回答も、重大な失敗です。本番投入前のAIエージェント評価ガイドでは、タスクとトレースのアサーションを併せて解説しています。

インターフェースは不確実性を表現する必要がある

従来型SaaSは通常、支払い済み、失敗、保留中など既知の状態を表示します。エージェントには証拠が不足していたり、情報源が矛盾していたりする場合があります。プロダクトには、エージェントが何を使い、どこが不確実で、次にどのアクションを提案しているかを示す方法が必要です。

承認には正確な効果を含めるべきです。「続行」では曖昧です。「請求書1842に$42.00を返金」のように示せば、レビュー担当者は具体的な対象を承認できます。

エージェントが適さない場面

ルールが安定し、入力が構造化され、正しいアクションを直接コードにできる場合は、ワークフローを決定論的に保ちます。認証、quotaの適用、支払い確定、権限チェック、データベース制約は、エージェントが呼び出す場合でも通常のコードに置きます。

雑多なコンテキストを判断することで作業順序が変わる場面には、エージェントを使います。小さなツールセットだけを渡し、絶対に変えてはいけないルールはバックエンドで強制してください。

一つのワークフローで境界を描く

ワークフローを一つ選び、各手順を決定論的コード、モデル判断、人間の承認、外部の副作用のいずれかに分類します。モデルを使う手順に変動すべき理由がなければ、コードへ戻します。外部への効果に明示的なIDと復旧経路がなければ、本番投入前に止めてください。

以下のプロンプトは、検討中にアプリケーションをリファクタリングさせることなく、コーディングエージェントにその境界を整理させます。