AI活用

PHPでアクション実行前にAI提案を検証する

もっともらしい出力が、管理なしにデータを変更したりプロセスを実行したりしないよう、運用アクションを提案するPHPのAIフローを設計します。

AIの応答は正確に見えても、システムに対して操作を行うには不適切な場合があります。リクエストを緊急と分類したり、フィールドの補完を提案したり、フローの開始を推奨したりしても、権限、十分なコンテキスト、業務ルールへの準拠があることを意味するわけではありません。テキストまたは構造化された提案を、独立した障壁なしに実行可能な命令へ変換するときにリスクが生じます。

PHPで構造化AI出力を検証するには、モデルをレコードの変更、担当者の割り当て、通知の送信、プロセスの開始を行う権威ではなく、提案を準備するコンポーネントとして扱うべきです。アプリケーションが決定を保持し、独自のルールを適用し、提案を受け入れた、修正した、または拒否した理由を記録します。

もっともらしい出力は有効な指示ではない

モデルは構文上正しいJSONを返しても、存在しない優先度、顧客に対応しない識別子、あり得ない日付、あるいはユーザーが要求できないアクションを含むことがあります。また、入力に存在しないデータを補完したり、曖昧さを誤って解釈したり、契約変更後に古い形式に従ったりすることもあります。

運用上の境界は明示的でなければなりません。AIはアクションを提案し、使用したデータを説明できます。システムは、その提案を下書きにするか、レビューを必要とするか、非常に限定された条件下で実行できるかを決定します。この分離により、データ完全性と意思決定の責任の両方を保護できます。

適切な出発点は、各アクションを影響度で分類することです。

低影響:下書きへのタグ付け、カテゴリの提案、非クリティカルなフィールドの抽出。
中影響:保留中タスクの作成、担当者の提案、レビュー用回答の準備。
高影響:契約上の状態変更、不可逆な作業の割り当て、金額の変更、データの削除、外部への連絡、または機微なプロセスの有効化。

許容できる自律性は、AIが高い信頼度を表明したかどうかには依存しません。可逆性、誤りのコスト、検証可能なデータ品質、およびモデル外の制御の存在に依存します。

モデル統合前に提案契約を定義する

出力契約は、AIコンポーネントが提案できる内容と、その対象外となる内容を定義します。小さく、型付けされ、バージョン管理されている必要があります。「このリクエストにどう対応するか決めて」と求めるのではなく、アクションの閉じたリストと、各アクションに必要なフィールドを指定します。

{
  "version": "1",
  "action": "create_task_draft",
  "category": "billing",
  "priority": "normal",
  "summary": "請求書の不一致を確認する",
  "sourceReferences": ["message:123"],
  "confidence": 0.82
}

アクションのリストでは、たとえばcreate_task_draft、request_more_information、no_actionのような制御された値を使用する必要があります。メソッド名、クエリ、コード断片、自由入力の宛先、または「注文を更新する」のような指示を受け入れるべきではありません。アプリケーションは、許可されたアクションを具体的な内部操作に変換します。

フィールド、状態、証拠

型と許可値に加え、契約では必須フィールド、両立しない組み合わせ、提案が提示すべき証拠も示す必要があります。カテゴリは有効であっても、少なくとも元のメッセージまたは文書への参照を1件必要とする場合があります。信頼度を収集する場合、それはレビューの優先順位付けのための補助データであり、検証の代わりにはなりません。

スキーマをバージョン管理することで、廃止された契約の出力を安全に拒否できます。変更により必須フィールドが追加されたりアクションが廃止されたりした場合、アダプターはバージョンを認識し、暗黙的な解釈を回避しなければなりません。

いかなる効果の前にも4つの障壁を適用する

検証は分離された層で行う必要があります。ある層の失敗を、別の層で一見もっともらしい応答があっても補うことはできません。

形式:応答をデコードできること、期待するスキーマに従うこと、予期しないクリティカルなフィールドを含まないこと、各値の型が正しいことを確認します。無効なJSON、未知の列挙値、必須フィールドの欠落は拒否します。
ドメイン:アプリケーション固有のルールを検証します。たとえば、カテゴリが存在すること、優先度がリクエスト種別に適用可能であること、参照されたアカウントが有効であること、元情報への参照が処理対象のコンテキストに属することを確認します。
認可:フローを開始したアクターが実行できることと、操作に必要な権限を確認します。AIは無制限の権限を継承せず、アクセス範囲も決定しません。サーバーがアイデンティティ、テナント、現行ポリシーを適用します。
運用条件:並行性、現在の状態、上限、依存関係、冪等性を確認します。有効な提案であっても、案件がすでにクローズされている、別のプロセスがレコードを変更した、または負荷のしきい値を超えた場合には実行できないことがあります。

意味的検証では、内部の信頼できる情報源を参照する必要があります。モデルが形式の整った識別子を返すだけでは不十分です。リポジトリまたはドメインサービスが、その存在、帰属、状態を検証しなければなりません。アプリケーション自身で解決できる認可データを、モデル応答に持たせないでください。

PHPアーキテクチャ:提案、決定、実行を分離する

保守しやすいアーキテクチャは責務を分離します。AIアダプターはリクエストを準備し、サイズ制限を適用して出力を取得しますが、業務データベースには書き込みません。DTOはパース済みの提案を表します。ドメインバリデーターはその提案を明示的なエラーを含む決定に変換します。最後に、認可された実行者が承認済みの決定のみを適用します。

final class ActionProposal {
    public function __construct(
        public string $action,
        public string $category,
        public string $priority,
        public array $sourceReferences,
    ) {}
}

$proposal = $aiAdapter->propose($input);
$validation = $domainValidator->validate($proposal, $context);

if (!$validation->isApproved()) {
    $auditLog->recordRejected($proposal, $validation->reasons());
    return $validation;
}

return $decisionService->route($validation->approvedProposal(), $context);

決定サービスは、下書きを作成したり、レビューキューに入れたり、人による承認を要求したりできます。最終実行者が受け取るべきなのは内部の決定オブジェクトであり、生の応答やAIのJSONではありません。これにより、契約の偶発的な拡張が新たな運用能力になることを防ぎます。

関連する変更にはトランザクションを、再試行には冪等性キーを、複数の人またはプロセスが同じ案件に作用し得る場合には並行性制御を使用します。また、デプロイと有効化を区別してください。コードはデプロイ済みでも、実際のユーザーにはフローを公開していない状態にできます。段階的な有効化により、範囲を広げる前に拒否、所要時間、修正を観察できます。

人手レビュー、限定的自動化、拒否を選ぶ

重大な曖昧さ、機微なデータ、外部への影響、ポリシー例外、または修正コストが高い場合には、人手レビューが適しています。レビュー画面では、提案、許可された元情報の証拠、通過したルール、警告理由を表示すべきであり、推奨を事実として提示してはなりません。

可逆的かつ限定的な操作では、限定的自動化が妥当な場合があります。たとえば、未割り当ての下書き作成、暫定タグの適用、リクエストの一般キューへのルーティングです。頻度制限、取り消し可能性、事後監視が必要です。データが不足している、ルール間に競合がある、またはアクションが許可リスト外である場合、安全な挙動は即興で対応することではなく、拒否またはエスカレーションです。

AIを使用する前に、決定論的な代替手段を評価してください。入力が安定したパターンに従うなら、ルール、ガイド付きフォーム、選択リスト、または従来型分類器のほうが、より低コストで監査可能かつ予測可能な場合があります。AIを使用する場合は、ユースケース、代表的な評価セット、運用上のしきい値、ボリューム当たりのコスト、プロバイダーが障害を起こした場合または想定時間を超えた場合の縮退モードを定義してください。

例:リクエストをタスクの下書きに変換する

請求書の差異に言及する受信リクエストを想定します。AIは、billingカテゴリ、通常優先度、タスクの要約を提案できます。バリデーターは、メッセージが現在のテナントに属すること、カテゴリが有効化されていること、同じ参照を持つ未解決案件がすでに存在しないことを確認します。すべて正しければ、システムは担当者を割り当てず、請求書の状態も変更しない下書きを作成します。

オペレーターは下書きをレビューし、カテゴリを確認または修正し、現在の負荷と権限に従って割り当てを決定します。この区別により、担当者や金額に関するもっともらしい推論が誤った変更になることを防ぎます。契約で請求書番号を必須とし、それがメッセージにない場合、提案は追加情報を要求すべきであり、捏造してはなりません。

フロー拡大前のトレーサビリティ、プライバシー、テスト

相関ID、契約バージョン、最小化された入力のフィンガープリントまたは参照、正規化された提案、各検証の結果、最終決定、存在する場合は承認アクター、拒否理由を記録します。ログは、不必要に個人データや機微なコンテンツを複製することなく、インシデント調査に役立つものでなければなりません。プロセスのリスクに応じた保持、アクセス制限、最小化技法を適用してください。

不完全な入力、矛盾する指示、捏造された値、別テナントの参照、並行した状態変更、古い形式の応答、レイテンシ、AIサービスの不在といった代表的および敵対的なケースでフローをテストします。受け入れ基準では、未認可の操作がブロックされるか、下書きを回復できるか、拒否が理解可能か、障害時にもシステムが機能する代替手段を維持するかを測定する必要があります。

安全な運用とは、モデルが常に応答するようにすることではありません。誤った応答をした場合、応答に時間がかかりすぎる場合、または応答しない場合でも、PHPアプリケーションが制御を維持し、正当化できない効果を生じさせないことです。

これらのアイデアをあなたのプロジェクトに活用してみませんか？あなたのPHPプラットフォームについて話し合いましょう。