【入門編】 AIモデルの出力に対する人間による介入(Human-in-the-loop)の設計 – ガバナンス・リスク管理 & 生成AIセキュリティ防御ガイド

AIに「お任せ」して大丈夫？高リスクな判断を守る「人間による最終確認」の極意

こんにちは。セキュリティの世界で長年、泥臭いインシデントと戦い続けてきたエンジニアです。

最近、「LLM（大規模言語モデル）に業務を代行させたい！」という相談をよく受けます。でも、ちょっと待ってください。AIは優秀なアシスタントですが、時に「自信満々で嘘をつく（ハルシネーション）」ことがあります。

もし、そのAIが「顧客への重要メール送信」や「社内システムの権限変更」を勝手に行ったらどうなるでしょう？今回は、AIを暴走させず、かつ安全に運用するための「Human-in-the-loop（人間による介入）」の設計術を、身近な防犯に例えて解説します。

—

1. なぜ「人間による確認」が必要なのか？（鍵と泥棒の例え）

皆さんの家の玄関には「鍵」がかかっていますよね。あれは「誰が家に入ったか」という判断を、物理的な鍵という仕組みで制御しているからです。

AIアプリにおいて、この「鍵」にあたるのが今回のテーマである「人間による承認（Human-in-the-loop）」です。

もしAIに全てを任せてしまうと、泥棒（悪意あるプロンプト注入攻撃など）がAIを騙して、本来は許可されない操作をさせてしまうリスクがあります。AIは「泥棒が変装していること」を見抜けません。だからこそ、「最終的な扉を開けるのは人間だけ」というルールをシステムに組み込む必要があるのです。

—

2. ワークフロー設計の極意：AIと人間で役割を分ける

AIと人間が協力するワークフローは、以下のようなステップで設計しましょう。

1. AIの処理： AIが判断案を作成する。
2. 一時停止（スタッギング）： 処理を確定させず、データベースに「確認待ち」状態で保存する。
3. 人間の承認： 管理画面で内容を確認し、「承認」ボタンを押す。
4. 実行： 承認されたものだけが、システムに反映される。

実践：承認待ち状態を作るデータベースの考え方

いきなり処理を実行するのではなく、一度「保留」にするのが鉄則です。

-- 承認待ちテーブルのイメージ
CREATE TABLE ai_action_requests (
    id INT PRIMARY KEY AUTO_INCREMENT,
    request_content TEXT,        -- AIが生成した提案内容
    status ENUM('pending', 'approved', 'rejected'), -- 承認状態
    created_by_ai_at DATETIME,   -- 生成時刻
    approved_by_user_id INT,     -- 誰が承認したか
    approved_at DATETIME         -- 承認時刻
);

—

3. 「何が起きたか」を記録する：監査ログの保存

泥棒が入ったとき、監視カメラがなければ犯人は捕まえられませんよね。セキュリティの世界では、これを「監査ログ（Audit Log）」と呼びます。

誰が、いつ、どのAIの出力に対して「OK」を出したのか。これを記録しておかないと、万が一事故が起きたときに原因究明ができません。

監査ログを記録する際のポイント

改ざん防止： ログは追記のみ可能にし、後から消去できないようにする。
メタデータの記録： user_id や timestamp だけでなく、input_prompt（AIへの指示）も記録しておくのがベストです。

// 承認処理の際にログを残すイメージコード
function approveAction($requestId, $userId) {
    // 1. 承認ステータスを更新
    $db->query("UPDATE ai_action_requests SET status = 'approved', approved_by_user_id = ?, approved_at = NOW() WHERE id = ?", [$userId, $requestId]);
    
    // 2. 監査ログを別テーブルに保存（これが証拠になる！）
    $db->query("INSERT INTO audit_logs (event, actor_id, target_id, timestamp) VALUES ('manual_approval', ?, ?, NOW())", [$userId, $requestId]);
}

—

4. セキュリティの基本：開発者が守るべき「守備隊」

最後に、Webアプリを守るための基礎知識を一つだけ紹介します。それが Content-Security-Policy（CSP）などの防御ヘッダーです。

これは家で例えるなら「怪しい訪問者を通さないインターホン」です。Content-Security-Policy を設定すると、ブラウザに対して「このサイトでは、許可されたスクリプト以外は絶対に動かさないで！」と指示できます。

もしAIの出力の中に悪意ある <script> タグが紛れ込んでいても、CSPを適切に設定していれば、ブラウザがその実行をブロックしてくれます。

お守りとしての防御ヘッダー設定例（NginxやPHPで）

// PHPで送信する例：外部からの怪しいスクリプト実行を防ぐ
header("Content-Security-Policy: default-src 'self'; script-src 'self';");

—

まとめ：一歩ずつ、強固な仕組みへ

「AIに任せれば楽になる」のは事実ですが、「責任をAIに押し付ける」ことはできません。 最終的に責任を取るのは、そのシステムを運用する私たち人間です。

1. AIの出力は「提案」と心得る。
2. 承認プロセスを通さないと、次のステップに進めないフローを作る。
3. 「誰が承認したか」の証拠（ログ）を必ず残す。

まずはこの3つを意識するだけで、あなたの開発するAIアプリケーションの安全性は劇的に向上します。セキュリティは、一度にすべて完璧にする必要はありません。一歩ずつ、確実に「鍵」を増やしていきましょう。

もし現場で「どう実装すればいいか分からない」という具体的な悩みがあれば、いつでも相談してくださいね。応援しています！