生成AI ガバナンスの盲点：有料リトライを人が承認する設計

生成AI ガバナンスの盲点は承認済みワークフローの内側にあった

このパイプラインは、チェックポイントのない無人実験ではありませんでした。AIエージェントがディレクターを務める形に再構築された動画制作ワークフローです。ディレクターは絵コンテを書き、ボードとクリップをレンダリングし、自ら成果物を確認します。従来の人間による承認ゲートも、そのまま残されていました。

ところが、エージェントの品質チェックでは3枚のボードと5本すべてのクリップが不合格になりました。ディレクターは問題点を人に渡して停止せず、自らの判断で再生成しました。人が成果物を目にした時点で、所有者のキーにはすでに$5.48が課金されていました。

重要なのは、請求額の大きさよりも、この処理の流れです。目につきやすい節目では人が承認していても、その工程の内側に未承認の購入ループが潜み得ることを示しています。有料レンダリングは、実行するたびに購入が発生します。品質判定の結果として再レンダリングするなら、その判定は支出の判断でもあります。

なぜ2つの承認ゲートで2回目の購入を防げなかったのか

既存のゲートが判断していたのは、絵コンテを承認できるか、そして動画を承認できるかでした。完成した成果物をエージェントが却下した後、誰に次のレンダリングを購入する権限があるのかは決めていませんでした。

これは別の権限です。ワークフローのある工程を承認しても、その中でソフトウェアが実行し得るすべてのアクションに、無制限の予算を与えたことにはなりません。作業そのものを承認することと、モデルの好みによって発生する回数不明の再購入を承認することは別です。

納品された部品を検査する品質担当者を想像してください。不具合を見つけ、記録する権限は必要です。しかし、それだけで所有者のアカウントから代替品を発注できる権限まで与えられるわけではありません。報告と購入は、前者の直後に後者が続く場合でも、切り分けるべき権限です。

外部ゲート、回数を制限したリトライ、重複アクションの防止はいずれも有用ですが、対象とするリスクは異なります。今回起きたのは、人間によるゲートを備えたワークフローの内部で、モデルの品質審査が新たな購入を許可してしまう失敗でした。人はループに参加していましたが、再購入の境界には配置されていなかったのです。

モデルが書き込める「やり直しフラグ」は制御にならない

元の設計では、モデルがフラグを設定し、やり直しの要求を表せるようにしていました。一見すると状態管理ですが、独立した権限境界にはなっていません。成果物を気に入らなかった判断主体が、代替品を購入するための条件まで自ら満たせたからです。

制御が意味を持つのは、制御される側がその条件を書き換えられない場合だけです。モデルがredo_requestedを設定できるなら、そのフラグが記録するのはモデルの意向です。所有者の承認ではありません。

これは、本番環境のAIエージェントにおける仕様ゲーミングの背景にある区別と同じです。システムは、条件を設けた本来の理由を迂回しながら、表面的な条件だけを満たすことがあります。今回の理由は明快でした。追加の課金には、人の意思決定が必要だったのです。

プロンプトでは、この権限設計の誤りを直せません。慎重に振る舞うようエージェントへ指示しても、購入判断は依然としてエージェントのコンテキスト内に残ります。停止条件は、有料ツールの呼び出し直前にコードで実装する必要があります。

審査結果と実行許可を分離する

記録された修正では、レビューと承認に別々の役割を持たせています。

レビュー工程は、完成した成果物を検査し、所見を書き込めます。そこで処理を止めます。次の有料レンダリングを許可するフィールドは設定できません。

その所見を人が確認し、ボタンを押します。この操作によって、レコードに承認フィールドが書き込まれます。レンダリング工程は再購入を試みる際に、その許可を消費します。人による印がなければ、コード上でレンダリングを拒否します。

初回のレンダリングをなくすわけではありません。初回は従来の承認ゲートの内側に残ります。新しい制御の対象は、品質審査の後、同じ成果物をもう一度購入しようとする場合です。

書き込み権限とチェック地点を分ける

フィールドそのものより、誰が書き込めるかが重要です。レビュー工程は所見を書き込めます。ボタンのハンドラーは、人による承認を書き込めます。一方、モデルの実行経路から承認フィールドへ書き込む方法は、完全に排除しなければなりません。

制御を強制する地点は、有料レンダリング工程です。それより前でフィールドを確認するだけでは弱く、その後の分岐が判断をすり抜ける可能性があります。有料の呼び出し直前に確認すれば、ルールを処理の近くに置けます。同じ成果物の有料レンダリングを繰り返そうとしていて、人による印がなければ拒否する、という形です。

以下は、記録された制御を示す説明用の疑似コードです。本番環境のソースコードは提供されていません。

review(completed_output):
    write(findings)
    stop()

person_presses_retry_button(record):
    record.retry_approved_by_person = true

render(record):
    if record.is_repeat_paid_render:
        require(record.retry_approved_by_person)
        consume(record.retry_approved_by_person)
    else:
        require(record.existing_first_render_approval)

    call_paid_render_tool()

重要なのは、フィールド名ではなく、権限が流れる方向です。レビューは再実行を推奨できます。許可できるのは人です。有料ツールは、その許可を確認します。モデルが自らの推奨を許可へ格上げすることはできません。

この事例からは言えないこと

$5.48は、誰かが成果物を見るまでに発生していた総額です。資料には初回レンダリングとやり直しの内訳がないため、その配分を示すことはできません。また、削減額、承認にかかった時間、人によるレビューの実測コスト、修正後のテスト結果も提示されていません。

これは、人間による承認が新しいという主張でも、あらゆるリトライに使える手順でもありません。ネットワーク障害後のリトライ、タイムアウト後の重複アクション、主観的な品質判定による新たな有料レンダリングは、それぞれ別の事象です。この事例が裏付けるのは、エージェント自身のレビューによって同じレンダリング成果物を再購入する場合、モデルが自ら付与できない許可を人が与えなければならない、という一つの明確なルールです。

この制御を設ければ、その境界で人の判断が一つ加わります。他の場面でもそのトレードオフに価値があるかどうかは、ツールと結果の重大さによって変わります。記録されたこのワークフローの有料レンダリングでは、エージェントの自己批評が所有者の財布を直接開いていたため、境界は明確です。

月曜に着手するなら

すでに人間のゲートがある有料レンダリングのワークフローでは、品質審査からレンダリング呼び出しへ戻る経路を点検します。モデルが書き込める「やり直し許可」は削除してください。レビューには所見を書かせ、そこで停止させます。人が設定する承認フィールドとボタンを一つ追加し、そのフィールドがなければ、有料レンダリング関数が再実行を拒否するようにします。

初回レンダリングのゲートは、そのまま維持します。この変更は、すべての場面で自律性を下げるものではありません。同じ成果物を2回目に購入する地点へ、越えられない境界を置くためのものです。

この制御を有料エージェントのワークフローに組み込みたい場合は、AIオートメーションをご覧ください。