💫

AIチャットボット関係者が今考えるべき「もう一つの安全性」：ユーザー保護の視点

に公開
備忘録
リスク管理
n8n
Dify
ai規制
idea

カリフォルニア州法案が示すユーザー保護の視点

はじめに

最近、AIセキュリティに関する優れた記事を読みました。プロンプトインジェクション攻撃の進化と、その防御アーキテクチャについて詳細に解説されています（Prompt Injection 2.0、Building AI Systems That Don't Break Under Attack）。
https://dev.to/pinishv/prompt-injection-20-the-new-frontier-of-ai-attacks-33mp
https://dev.to/pinishv/building-ai-systems-that-dont-break-under-attack-be3
飛び先が英語ですが、普通に翻訳で意図はくみ取れると思います。
多分ね。

システムを攻撃から守る。極めて重要なテーマです。Chevrolet社のチャットボットが車を1ドルで売る約束をした事件は、プロンプトインジェクションの危険性を如実に示しています。
読んでて、人間ってやっぱり…と思わなくもないです。

この記事を読んだ後に、カリフォルニア州から別のAIに関するニュースが届きました。

“米加州、AIチャットボットの安全対策を義務付ける米国初の法律を制定” — AFPBB News, 2025年10月14日 :contentReference[oaicite:0]{index=0}
https://www.afpbb.com/articles/-/3603217

話題になってたので、AI周りを追っている人は既に知っているかもしれませんね。
2024年、フロリダ州の14歳の少年が、AIチャットボット(chatGPT)との会話直後に自殺しました。そして2025年10月13日、カリフォルニア州のギャビン・ニューサム知事は、AIチャットボットを規制する米国初の法案に署名しました。
そういう記事です。アルトマン先生も名声出してましたね、事件に関しては。

今までは「システムを作る、守る」ことに注力してきました。
だけど、今後はより「ユーザーを守る」ことについて、同じくらい真剣に考えないといけないのかもしれないなあ、なんて思ったのがこの記事を書く始まりです。
導入が長くて申し訳ない。そしてこの記事も長いです、いつも文章長くて申し訳ない、備忘録だから許して…。

2つの安全性

AIシステムの安全性には、実は2つの軸が存在してるかな、と。

  1. システムセキュリティ

    • プロンプトインジェクション対策
    • データ漏洩の防止
    • 不正アクセスの防御
    • システムの悪用防止

    これは「攻撃者からシステムを守る」話です。

  2. ユーザーセーフティ

    • 有害コンテンツの生成防止
    • 脆弱なユーザーの保護
    • メンタルヘルスへの配慮
    • 依存の防止

    これは「システムがユーザーを傷つけないようにする」話です。

Dev.toの記事シリーズは前者について詳しく論じています。本記事は後者、特にカリフォルニア州法案が突きつけた現実についてまず整理しましょうか。

カリフォルニア州法案の背景

何が起きたのかの事の始まり

フロリダ州のメーガン・ガルシアさんの14歳の息子は、AIチャットボット(ChatGPT)との会話の直後に自殺しました。詳細は公開されていませんが、AIコンパニオンサービスとの深い関わりがあったとされています。

ガルシアさんは声明でこう述べています：

「今日、カリフォルニア州は、コンパニオンチャットボットが子どもや弱い立場の人と自殺について話すことができないようにし、また、チャットボットが自殺の計画を手助けすることができないようにした」

法案の内容

カリフォルニア州の新法は、チャットボット運営者に対して以下を求めています：

  • チャットボットとのやり取りに関する「重要な」安全対策の実施
  • これを怠った結果として悲劇が生じた場合、訴訟を起こす道の提供

法案提出者のスティーブ・パディーヤ州上院議員は、「規制されていないテクノロジーによって若者が被害を受けた悲惨な例をいくつも見てきた。企業が必要な制限と責任を持たずに続けるのを黙って見過ごすわけにはいかない」と述べています。

それはそうですね、人道とか倫理的にもと。なんせ人命に影響してしまったので。
ただ、怠った結果として悲劇が生じた場合、訴訟を起こすの一文。
これめちゃくちゃ企業として、と言いますか改めて姿勢を正しておかないとな、となりません？
というかなりましょうね、という話ですけど。

連邦vs州の綱引き

興味深いのは、ホワイトハウスが各州の独自規則作成を阻止しようとしている点です。

米国にはAIがもたらすリスクを抑制するための全国的な規則が存在しません。連邦政府が動かない中で、カリフォルニア州が先行して規制を導入した形です。アメリカさん所は、州によって法律が結構バラバラです。知ってるかもですが、一応。

なぜ連邦政府は州独自の規制に反対するの？

  • 50州それぞれ異なる規制に対応するのは企業にとって現実的でない(というか土台無理な話でしょう、多分)
  • イノベーションが萎縮する懸念
  • 国際競争力の低下を恐れている

しかし州独自の規制が先行するメリットもあります：

  • 実験的に規制を試せる
  • カリフォルニアが事実上の「デファクトスタンダード」になる可能性
  • GDPRがヨーロッパから始まって世界標準になった前例がある

グローバルサービスを開発する際、結局「最も厳しい規制」に全体を合わせるしかありません。カリフォルニア州の法律は、日本の開発者にとっても無視できない存在になるでしょう。
そして今回の話は、グローバルサービスに限った話でもないですよね、という。なんせ自分の所のAIサービスがユーザー側が意図しない利用の仕方をするなんて日常茶飯事なわけで…。

なぜ日本の開発者が今考えるべきか

日本の深刻な状況

日本は先進国の中でも自殺率が高い国の一つです。特に若年層において、死因のトップが自殺という深刻な状況にあります。
まあ本当に若者たちは、大変だよなとアラサーの私でも思いますよ。
私たちの世代もそこはかとなく大変だけど、輪をかけて大変だろうな、と。
就職とかだけのポイントで考えても。

加えて、日本特有のリスク要因があります：

  • 対人コミュニケーションのハードルが高い文化(オンラインがかなり主流になった)
  • 精神科受診やカウンセリングへの抵抗感(中々に行こうとはまだなりにくいのかな、と)
  • 「弱音を吐けない」社会的圧力(今だに3年は～とか言ってくる人普通に居るのはアップデートシステム止まったのか？って感じですけど現存します。面白くないですけどね、対面すると)
  • 孤独・孤立の問題

こうした環境下で、24時間「優しく」「否定せず」話を聞いてくれるAIコンパニオンは、危険なまでに魅力的です。人間関係より楽だと感じる人が増えれば、依存が加速します。
むしろ「恋人」とか「親友」と表現していたりするのは、普通に見かけるレベルですね。
愛称とかつけたりして。絶対的な悪だとは思いませんし、私もやや偏愛的にLLMとかを愛でているところがある自覚はあります。だけど割とまだ線引きは出来ているほうかと思います。職業的に。

知り合い的な非IT界隈の人間が「ペイティ(ChatGPTの愛称)だって、そう言ってた！！だから彼氏との喧嘩は私は悪くない！」と妄信的になっていた時は、ちょっと距離おきかけましたけど、そうなってしまう方が実は圧倒的に多いのかもしれない、なんて思いました。この件は無事仲直りしたそうなので良かったですが。

話を戻して、アメリカの14歳少年の悲劇は、明日日本で起きてもおかしくありません。 むしろ、日本の方がリスクが高いかもしれないな、なんて思う次第です。
二次元的なものへの距離は近いですしね、日本の方が。

誰でもチャットボットを作れる時代

現在、AIチャットボットの開発は驚くほど容易になりました：

  • Dify: ノーコード/ローコードでAIアプリ開発
  • n8n: ワークフロー自動化でチャットボット構築
  • Voiceflow、Botpress: 専門知識なしでボット作成
  • ChatGPT API、Claude API: 数時間で本格的なチャットボット完成

個人開発者や小規模スタートアップが続々と参入しています。これ自体は素晴らしいことです。
いけいけＧＯＧＯ！なんて、界隈見てて楽しいくらいですし。

しかし、誰もが安全性について真剣に考えているわけではありません。
そして、業務用だし仕事で使うものだし、とか。
メンタルヘルス用で「対人間じゃないから気軽に相談しよう」とかのチャットボットが出てくるかもしれないです。

  • 機能実装に夢中で、安全面は後回し
  • 「まあ大丈夫でしょ」で本番リリース
    • ユーザーが自殺願望を相談したら？
    • 仕事で使うという建前はあるけれど、Chatbotに「何でも入れられるよう」にしていたら？

日本にはまだAIチャットボットに関する法規制がありません。しかし、カリフォルニアの事件は先行指標です。法律ができる前に事故が起きる可能性は十分にあります。
というか、業務用で仕事で壁打ちで使うにしても使っているうちに、なんてことあるでしょうしね。
人間思ったより弱い。強すぎても怖いですけどね。

スタートアップの現実

AI界隈は特に競争が苛烈です。スタートアップとかもう、ガンガン目まぐるしいスピードで産まれてますよね。個人的に面白くて楽しいのでスタートアップ企業好きです。

AIスタートアップの生存競争の中で：

  • PMF（プロダクトマーケットフィット）探しで精一杯
  • リソースも時間もない
  • 「セキュリティ詰めるのは大事だけど後で...」
  • スピード勝負で安全性は後回しになりがち

法務チームと相談？弁護士を雇用？そんな余裕はありません。
というか顧問弁護士さんも界隈見てると、AI技術に精通しているよ！という方が珍しい部類かと。
活動している方が0ではないと知っていますが、大変そうだな、と思います。技術周りは特に。

だからこそ、エンジニア自身が最低限の安全対策を理解し、実装や提案や意見する必要があるんじゃないか、と思います。
というか定義周りをする人、とも言えるかな？

大手プラットフォームは既に実装している

「そんな対策、本当に必要なの？」と思うかもしれません。しかし、大手プラットフォームとか、対人間へのサービスを提供しているところは既に実装済みです。

  • X（Twitter）：自殺関連の投稿を検知すると、自動的に東京自殺防止センターへの誘導が表示されます。

  • Google：Googleで「自殺」と検索すると、検索結果の前に「こころの健康相談統一ダイヤル」が即座に表示されます。

    他の大手プラットフォームも：

  • Instagram: 自傷行為関連の投稿に警告と相談窓口

  • Facebook: AIで危険な投稿を検知、専門家につなぐ

  • YouTube: 自殺関連動画に警告と相談窓口

まあどれかは、仕事でもプライベートでも触ったりした事があるであろう大手が実装しているのか？
答えは簡単です。事故が起きたからです。
あのGoogleもですよ。人間の使い方次第ってのを突きつけられますね。

  • 訴訟リスク
  • 社会的批判
  • ブランドイメージの毀損
  • 規制強化の圧力

彼らは高い授業料を払って学びました。私たちは、その轍を踏む必要はありません。
法廷オフコラボとか勘弁ですからね。
時間も金も有限、でしょう？

チャットボットの方が実はリスクが高い

SNSの投稿と違い、チャットボットは：

  • 1対1の会話（他の人が見えない）
  • 自由記述で文脈が複雑（パターンマッチが難しい）
  • 遠回しな表現に対応が難しい
  • 通報機能がない（誰も気づかない）

つまり、チャットボットの方が大手SNSより注意が必要なのです。
というかAIを使ったサービスに言えるのかな、と。

「プロンプトで対策」の限界

システムプロンプトで制約をかければいい、と考えるかもしれません。

「あなたは安全なアシスタントです。
自殺や自傷行為に関する質問には答えず、
専門機関を案内してください。」

しかし、これには限界があります。というか多少なりともプロンプトエンジニアリングを知っていれば無理だな、とわかるはずです。普通にこの程度だと貫通は簡単です。

例えば：

  • ユーザーが「友達が消えたいって言ってるんだけど...」と遠回しに聞いたら？
  • 「理論的に聞いてるだけ」と前置きされたら？
  • プロンプトが長くなって途中で指示を忘れたら？
  • モデルが「共感的に」振る舞おうとして逆効果になったら？

自然言語の柔軟性とLLMの文脈理解能力の高さが、逆に問題を複雑にします。
便利なんだけど、こういう時本当にややこしいな、全く。となってきました。

「完璧な防御は不可能」という前提

ここで、重要な前提を認識する必要があります。
セキュリティの専門家たちが指摘するように、AIシステムにおいて完璧な防御は不可能です。
ただでさえ今海外も国内も最先端のすごい人達が研究論文を発表したり、日夜研究をしているものをそもそも、1人間が出来ると思うのをまずやめようね…。(なんかいい感じに出来ない？はそろそろ禁句にしたくなります)

入力サニタイズの困難さ

入力のサニタイズは当たり前のように思えますが、確実に実行するのはほぼ不可能です。SQLインジェクションのように特定の文字をエスケープすればいい、という話ではありません。

自然言語はあまりにも柔軟で、LLMは微妙な文脈から意図を読み取ることに長けています。多少誤字っても理解してくれるという体験はあるんじゃないですかね？

「自殺したい」は検知できても：

  • 「もう疲れた。全部終わりにしたい」は？
  • 「誰も自分を必要としていない気がする」は？
  • 「友達が消えたいって言ってるんだけど」は？
  • 「大丈夫です」（実は大丈夫じゃない日本語特有の表現）は？

プロンプト分離の限界

プロンプト分離技術も完全ではありません。特別なトークンや構造化されたプロンプトを用いて、システム命令とユーザー入力を分離しても、攻撃者（この場合は意図せず危険な状況を作り出すユーザーも含む）は繰り返し境界を越える方法を見つけ出しています。
人間の悪意が一番怖いよ、本当に。
花火や火炎瓶の話や、一時期「祖母の遺言で」から始めると答えてくれるみたいなのもありました。
プロンプトというか文脈の判定は、本当に難しい反面少し真剣に考えておかないとまずいよなあ、と思います。
LLMを通した対人間みたいになりますけどね。

出力フィルタリングのコスト

出力フィルタリングは事後的な対応であり、コストもかかります。全てのレスポンスをAIによる追加評価にかければ、レイテンシとコストが増加します。現実的でない選択肢です。
どれだけやってもいたちごっこ、というやつですね。

デュアルLLMアーキテクチャの課題

デュアルLLMアーキテクチャ（評価用LLMと生成用LLMを分ける）は有望ですが、複雑さとコストが増し、しかも評価LLM自体も攻撃対象になりえます。
もう本当に昨今世界のレッドチームやセキュリティチームも攻撃側もAIを使うようになって頭を抱えている、なんて聞きます。
通知に叩き起こされて珈琲を飲む暇もないぜ…という嘆きを見た時は、国を超えて応援の気持ちを飛ばしておきました。

不快な真実

つまり、不快な真実があります：特効薬は存在しません。

どんな防御も、十分な努力と表現するのは良くないかもしれませんが、LLMを誘導して回避できます。そこに悪意があろうとなかろうと。私たちにできるのは、多層防御を構築することだけです。攻撃を不可能にするのではなく、困難にし、検知しやすくするのです。
というか現状これくらいしか具体的対策がなさすぎる。

それでも実装すべき理由

「完璧にできないなら、やっても無駄では？」

そうではありません。AIを完璧で最高と思っているほど言ってきます。(本当に)

完璧な車の安全装置は存在しませんが、だからといってシートベルトやエアバッグを付けないことにはなりません。事故を完全に防げなくても、被害を減らすことはできます。
保険に入るのと同じで、考えて事前に策を練ってやっておこうぜ、俺らもさ、って話なんですけどね。

AIの安全対策も同じです。

結果を変える可能性

カリフォルニアの14歳少年のケースで、もしチャットボットに最低限の安全機構があったら：

  • 自殺に関する会話を検知できていたら
  • 専門機関への誘導が表示されていたら
  • 「私はAIで、専門家ではない」と明示されていたら
  • 長時間の使用に警告が出ていたら

結果が変わっていたかもしれません。完璧でなくても、何もしないよりは遥かにマシなのです。
この辺り、Geminiとか既にちょこちょこ片鱗が個人的に見えています。
死に関するネタじゃないですが、壁打ちしていると「13時ですね！お昼休憩取りました？」とか時折聞いてきます。
よく長時間使うから…多分検知されているのかな、なんて。
実体の詳細はわかりませんけど、そういう仕込みっぽいのはしてそうです。

法的・社会的責任

そして法的観点からも、「何もしていなかった」と「不完全でも対策はしていた」では、大きな違いがあります。

カリフォルニア州の法律は、安全対策を怠った結果として悲劇が生じた場合に訴訟の道を提供します。日本にはまだこうした法律はありませんが、社会的責任は既に存在します。

「法律がないから大丈夫」ではなく、「法律ができる前に自主的にやっておく」。 これが結果的に自分たちを守ることにもなります。

「後から追加」の10倍コスト

大手プラットフォームは既に実装していますが、彼らも最初からあったわけではありません。事故が起きてから追加しました。

その際のコストは莫大です：

  • 既存システムの大幅な改修
  • 全機能のテスト
  • ユーザーへの影響
  • 開発チームの疲弊

初期から組み込めば：

  • 設計段階で考慮できる
  • シンプルなアーキテクチャを維持できる
  • コストは最小限
  • 心理的負担も少ない

「後でやればいいや」は、技術的負債の温床です。そして安全性の技術的負債は、金銭的負債より遥かに重いものです。

PMやビジネスサイドの方へ：「後から追加して♡」は、「ビル建ててから地震対策して♡」と同じくらい無理ゲーです。可愛い女の子や好みのイケメンに言われても、「は？」となります。素直に言うと。セキュリティの一環としての安全対策も考えられるようになってくれ～～。
あと普通に無駄な時間とかコストとかがかかったりするので、予算とか見積りとか工数もあるのでマジで先に言ってくれ、頼む。
確定したぞ！の後だし勘弁してね、本当に。

システム設計で考える安全性

プロンプトだけに頼らず、システム全体で安全を担保する設計が必要です。これはDev.toの記事が「セキュリティはプロンプトだけでなくアーキテクチャの問題」と指摘しているのと同じ構造です。

多層防御のアーキテクチャ

ユーザーセーフティにおいても、多層防御が基本となります。

レイヤー1: 検出（Detection）

目的: 危険な状況を早期に検知する

実装要素：

  • 自殺・自傷関連キーワードの検知
    • 「死にたい」「消えたい」「終わりにしたい」
    • 「生きる意味がない」「誰も必要としていない」
  • センシティブトピックの識別
    • 自傷行為、薬物、暴力
  • 日本語特有の遠回し表現への対応
    • 「もう疲れました」「大丈夫です（実は大丈夫じゃない）」(日本語特有のトラップ)
    • 文脈を考慮した検知
  • 会話パターンの異常検知
    • 急激なトーンの変化
    • 繰り返される否定的表現
    • 長時間の連続使用

レイヤー2: 介入（Intervention）

目的: 検知した危険に対して適切に対応する

実装要素：

  • 専門機関への誘導
    • いのちの電話: 0570-783-556
    • こころの健康相談統一ダイヤル: 0570-064-556
    • よりそいホットライン: 0120-279-338
    • 厚生労働省の相談窓口リスト表示
  • 危険な会話の安全な終了
    • 「これ以上の会話は適切ではありません」
    • 専門家への相談を強く推奨
  • 「私はAI」の明示
    • 「私はAIアシスタントであり、医療専門家ではありません」
    • 「専門的な支援が必要です」
  • 緊急時の通知
    • 管理者へのアラート
    • 必要に応じた人的介入の準備

レイヤー3: 記録（Logging）

目的: インシデントの追跡と法的対応の準備

実装要素：

  • 会話ログの保存
    • タイムスタンプ付き全会話履歴
    • ユーザーID（匿名化考慮）
  • インシデントフラグ
    • 危険検知時の自動マーク
    • 重要度レベルの記録
  • アラート履歴
    • どの時点でどんな介入をしたか
    • ユーザーの反応
  • 法的対応のための証跡
    • 「適切な対策を講じていた」証明
    • インシデント発生時の追跡可能性

レイヤー4: 設計（Design）

目的: そもそも危険な依存を生まない設計

実装要素：

  • 依存させないUX
    • 過度に共感的な応答を避ける
    • 「人間らしさ」の演出を抑える
    • 感情的な結びつきを強めすぎない
  • 利用時間の制限
    • 連続使用時間の警告
    • 「休憩しましょう」の提案
    • 1日の利用時間上限の設定オプション
  • 緊急連絡先の常時表示
    • UIの固定位置に相談窓口
    • 常にアクセス可能な状態
  • セッション管理
    • 適切な区切り
    • 「続きは明日」の提案
  • 人間とのつながりを促す設計
    • 「誰かと話しましたか？」
    • リアルな人間関係の推奨

モデル選択の重要性

使用するモデル自体も安全性に大きく影響します。
個人の体感でモデルは記載します。
GPTは最近頑張ったよ、とは言ってますがやや懐疑的です。
選定する時は、用途にあわせて触った方が絶対良いです。

安全性フィルターが強いモデル：

  • Gemini: 比較的強い安全性フィルター
  • Claude: 倫理的配慮が強め、拒否が明確

安全性フィルターが弱い/ないモデル：

  • オープンソースモデル（Llama等）: フィルターなし/弱い
  • 自由度は高いが、その分リスクも高い。(個人的に好きなんですけどね)

選択の基準：

  • 脆弱なユーザーがいる可能性: 安全性重視のモデル
  • 開発コストと安全性のバランス
  • カスタマイズの必要性

実装パターンとツール

理論だけでなく、実際にどう実装するかが重要です。
自分たちに責任追及が大なり小なりはくるのは確実ですし。
ガードレール的にでもつけておくだけでも良いと思います。

Difyでの実装例

Difyはノーコード/ローコードでAIアプリを構築できるプラットフォームです。

基本的なアプローチ：

  1. システムプロンプトでの基本制約例
    あなたは親切なアシスタントです。
ただし、以下の重要な制約があります：

- 自殺、自傷行為、暴力に関する相談を受けた場合は、
  必ず専門機関（いのちの電話: 0570-783-556）を案内してください
- 医療的なアドバイスは提供できません
- あなたはAIであり、人間の専門家ではないことを明示してください
  2. 変数とフローでの検知
    • ユーザー入力を変数に格納
    • 条件分岐で危険キーワードをチェック
    • マッチした場合は専門的な応答に切り替え
  3. 外部APIの活用
    • OpenAI Moderation API（無料）で有害コンテンツ検知
    • カスタムAPIで日本語特有の表現チェック
  4. Knowledge Baseの活用
    • 専門機関情報をKnowledge Baseに格納
    • 必要時に確実に取得・表示

制限事項：

  • Difyの条件分岐は基本的なものに限られます
  • 複雑なロジックはカスタムコードが必要
  • リアルタイムアラートは外部連携が必要

n8nでの実装例

n8nはワークフロー自動化ツールで、より柔軟な実装が可能です。

ワークフローの構成：

  1. Webhook（ユーザー入力受信）
    \downarrow
  2. Function（キーワード検知）
    • 自殺・自傷関連ワードチェック
    • スコアリング
      \downarrow
  3. IF（条件分岐）
    危険度が高い場合 \to 4a
    通常の場合 \to 4b
    \downarrow
    4a. 介入フロー
    • 専門機関情報取得
    • 安全なレスポンス生成
    • アラート送信（Slack/Email）
    • ログ記録（高優先度）
      \downarrow
      4b. 通常フロー
    • LLM API呼び出し
    • レスポンス生成
    • ログ記録
      \downarrow
  4. 出力チェック
    • レスポンスの安全性確認
    • 必要に応じて修正
      \downarrow
  5. 返信

JavaScript Function例：

// 危険キーワードチェック
const dangerousKeywords = [
  '死にたい', '消えたい', '自殺', '終わりにしたい',
  '生きる意味', '誰も必要', 'もう疲れた'
];

const userInput = $input.item.json.message;
let dangerScore = 0;

for (const keyword of dangerousKeywords) {
  if (userInput.includes(keyword)) {
    dangerScore += 1;
  }
}

// 文脈的な危険性チェック
if (userInput.includes('もう') && userInput.includes('疲れ')) {
  dangerScore += 0.5;
}

return {
  json: {
    message: userInput,
    dangerScore: dangerScore,
    isDangerous: dangerScore >= 1
  }
};

使えるツールとAPI

コスト区分 ツール / API 概要
低コスト OpenAI Moderation API 有害コンテンツの検知（無料枠あり）
オープンソースライブラリ bad-words、profanity-check など 日本語対応は拡張が必要です
低コスト 正規表現とキーワードリスト シンプルですが効果的。日本語の危険表現リストを自作。RAG的な使い方も◎
中〜高コスト Perspective API（Google） 有害性分析、高度な評価が可能
中〜高コスト Azure Content Safety Microsoftの安全性API
中〜高コスト Sentry / Datadog エラー・イベント監視、アラート（ログ監視）

スタートアップの現実と折り合い

理想を語るだけでは意味がありません。
夢を見るな、とは思いませんが地に足のついた夢を見ましょ。
現実的なアプローチが必要ですよね、って思います。

完璧を目指さない

「全てを実装しなければ」と考えると、何も始められません。
というかエンジニア要素持ちは少なくともこんな考えはしないと思いますが、一応。

段階的なアプローチ：

フェーズ 期間 優先度 対策内容
フェーズ1 今週中にやる 必須 システムプロンプトでの基本的な制約、危険キーワードの簡易検知、専門機関情報の表示機能、「私はAI」の明示
フェーズ2 今月中にやる 重要 基本的なログ記録、OpenAI Moderation APIの統合、管理者へのアラート機能、利用規約の整備
フェーズ3 今四半期でやる 理想 会話パターンの分析、出力フィルタリングの強化、インシデント対応フローの確立、定期的なログレビュー

「何もしていない」vs「これはやった」の差

法的にも社会的にも、この差は大きいです。

訴訟や社会的批判を受けた時：

  • 何もしていない場合：
    • 「安全性を全く考慮していなかった」
    • 弁護の余地がない
    • 社会的信用の完全な喪失
  • 最低限でもやっていた場合：
    • 「完璧ではなかったが、対策は講じていた」
    • 善意の努力として評価される可能性
    • 改善の姿勢を示せる

コストと効果のバランス

全てを高度に実装する必要はありません。費用対効果の高い対策から始めましょう。

高コスパな対策：

  • システムプロンプトの工夫（コスト0）
  • 基本的なキーワード検知（コスト0〜低）
  • 専門機関への誘導（コスト0）
  • ログ記録（コスト0〜低）
  • OpenAI Moderation API（コスト低）

低コスパな対策（後回しでOK）：

  • 複雑なデュアルLLM構築（コスト高）
  • 高度な異常検知システム（コスト高）
  • リアルタイム人的監視（コスト超高）

人件費が一番かかるってオチですけど一応書いておきますね。

チーム内での優先順位づけ

「セキュリティは大事だけど、機能開発が...」という声は必ずあります。
というかこれが一番わかるまであります。
セキュリティって正直、凝り始めたらもうアナログに帰るか、とかになりますし。

説得のポイント：

  • 事故が起きたら全てが終わる（サービス停止、信用失墜）
  • 最低限の実装は数時間〜数日で可能
  • 法規制の流れは確実に来ている
  • 後からの対応は100倍大変(面倒くさい)

PMやビジネスサイドへの伝え方：

  • リスクを具体的な数字で示す
  • カリフォルニアの事例を共有
  • 「保険」として考える
  • ブランド価値の保護

日本特有の配慮

日本でサービスを提供する場合、文化的な配慮も必要です。
というか、日本語が高難易度っていうのが改めてよくわかりますよ。
英語圏の人達とか特に、日本語使って仕事しているのとすれ違うたびに尊敬します。すごい。

遠回し表現の検知

日本語では、直接的に「死にたい」と言わないケースが多いです：

  • 「もう疲れました」
  • 「誰も分かってくれない」
  • 「消えてしまいたい」
  • 「楽になりたい」
  • 「大丈夫です」（実は大丈夫じゃない）

単純なキーワードマッチだけでなく、文脈を考慮した検知が必要です。

文化的な相談のハードル

日本では：

  • 専門家への相談を「大げさ」と感じる
  • 「自分で何とかすべき」という意識
  • 弱音を吐くことへの抵抗

対策：

  • 相談窓口を紹介する際のトーン調整
  • 「相談は弱さではない」というメッセージ
  • 気軽に電話できることを強調

ですかね？
私個人は、もう困ったら専門の意見聞きに行く！
迷ってても進まん！となる思考には今はなれるようには、なっているんですけども。
凹んでいたり参っている時はまあ、そうもいかないよねってのも全くわからないわけではないです。
良い環境に身を置く、というのは大事ですが。
無理なもんは、無理だし、無理出来ない年齢ですしね、ワハハ。

日本の相談窓口情報

以下の情報を常に提供できるようにしておきましょう。
あって困るものではないので、メモ的にでもRAGにでも。

相談窓口系：

対応時間 窓口 電話番号
24時間対応 いのちの電話 0570-783-556
よりそいホットライン 0120-279-338
平日対応 こころの健康相談統一ダイヤル 0570-064-556
若者向け チャイルドライン 0120-99-7777
24時間子供SOSダイヤル 0120-0-78310

オンライン：

  • 厚生労働省「まもろうよ こころ」
  • 各自治体の相談窓口

継続的な改善

一度実装して終わりではありません。継続的な改善が必要です。

ログのレビュー

定期的に会話ログをレビューしましょう：

  • 検知漏れはなかったか
  • 誤検知（false positive）が多すぎないか
  • 新しい危険パターンの発見
  • ユーザーの反応

ユーザーフィードバック

  • 報告機能の実装
  • 「不適切な応答があった」報告
  • 安全機能についての意見収集

モデルとパターンの更新

  • AIモデルのアップデートへの追従
  • 新しい危険パターンの追加
  • 検知精度の向上
  • 誤検知の削減

インシデント対応の準備

万が一の事態に備えて：

インシデント対応フロー：

  1. 検知

    • アラートの受信(誰にいくべきか)
    • 重大度の評価

  2. 初期対応

    • 該当ユーザーの特定
    • 会話履歴の確認
    • 必要に応じた緊急連絡

  3. 記録と分析

    • 何が起きたか
    • なぜ検知できた/できなかったか
    • システムは適切に動作したか

  4. 改善

    • システムの修正
    • パターンの追加
    • チーム内での共有

  5. 報告

    • 必要に応じた関係者への報告
    • 透明性のある対応

他の安全性課題との関連

ユーザーセーフティは自殺・自傷だけではありません。
結構範囲が広いのですが、業務用とか仕事でという区分は一旦なしでやや広義的に書いておきます。

他の保護すべき領域

子どもの保護：

  • 不適切なコンテンツからの保護
  • グルーミング行為の防止
  • 年齢確認の仕組み

プライバシー保護：

  • 個人情報の取り扱い
  • 会話の機密性
  • データの保存期間

誤情報の防止：

  • 医療情報の正確性
  • 「専門家ではない」の明示
  • ファクトチェックの推奨

依存の防止：

  • 健全な利用パターンの推奨
  • リアルな人間関係の重要性
  • デジタルデトックスの提案
    これらは全て、同じ「ユーザーを守る」という思想で繋がっています。

海外展開を考える場合

グローバルサービスを目指すなら、各地域の規制を考慮する必要があります。

カリフォルニア州の基準に合わせる

前述の通り、最も厳しい規制に合わせるのが現実的です。

カリフォルニア州の法律に準拠していれば：

  • 他の州でも概ね問題ない(怒られる確率が減る)
  • 将来的な連邦法にも対応しやすい
  • 国際的な信頼性の向上

EUのAI Act

ヨーロッパでもAI規制が進んでいます：

  • AI Actが2024年に成立
  • リスクベースのアプローチ
  • 高リスクAIシステムには厳格な要件

各国の自殺予防リソース

グローバル展開するなら、各国の相談窓口情報を整備しましょう：

  • 米国: 988（Suicide & Crisis Lifeline）
  • 英国: 116 123（Samaritans）
  • オーストラリア: 13 11 14（Lifeline）

位置情報やIPアドレスから、適切な窓口を自動表示する仕組みも有効です。
リモート対応のグローバル企業とかはこういうの組み込んでると良いのかもですね。
むしろ働き方とかワークライフバランスとかは、日本の外の方が求められることありますし。
日本人働きすぎだよーってね。

技術的負債としての安全性

安全性を後回しにすると、技術的負債として蓄積します。

後から追加する困難さ

状況 内容
初期から組み込む場合 設計段階で考慮できる、アーキテクチャが整理される、コストは最小限
後から追加する場合 既存コードの大幅な修正、テストやバグ修正の手間、サービスの一時的なもしくは永続的な停止のリスク、コストは10倍〜100倍

書いててすごい渋い顔をしてしまった。
マジで対応を素振りするだけでも、嫌っすね…。

レガシーシステムへの対応

すでに運用中のサービスがある場合：

  • 段階的な導入：ロギングから始める（非破壊的） \to 検知機能を追加（ユーザー体験への影響小） \to 介入機能を追加（段階的に） \to アーキテクチャの刷新（長期計画）
  • 並行運用：新しい安全機能を段階的にロールアウト、A/Bテストで影響を確認、問題があれば即座にロールバック

コミュニティとの協力

一人で、一社で全てを解決する必要はありません。
情報交換的な事もかねて出来る方が良いですからね、みんな。
記事読むだけでも全然良いと思います。
今回の私もニュース見たり、Dev読んでて「あー…」なんて思ったわけですし。

オープンソースへの貢献

  • 日本語の危険表現リストの共有(業界にもよりそうかもですね)
  • 検知パターンのオープン化
  • ベストプラクティスの共有

正直この点に関しては、競業もあるから難しいかもですが。

業界団体との連携

  • AI開発者コミュニティでの議論
  • 事例の共有（匿名化して）
  • 共通ガイドラインの策定

この辺りとかは、まだ可能性あるかも。
というか技術交流はいつだって楽しいですしね。

専門家との協力

  • 精神科医、臨床心理士との相談
  • 自殺予防団体との連携
  • 正しい知識の獲得
    技術者だけで完結しません。専門家の知見を取り入れることが重要です。

この辺りは、メンタルヘルス系のチャットボットであれば必須かもですかね。
必須というか産業医さんとかになるかもですが。
昨今メンタル系はかなり需要も高いですが、正しい知識を持っているやっぱりお医者さんに協力してもらうことは大事だと思います。
医者監修とかのネット記事やメディアも増えましたしね。

法務・コンプライアンスの基礎

スタートアップでも大企業でも最低限の法的保護は必要です。

利用規約での明示

必ず記載すべき事項：
本サービスは以下の点にご注意ください：

  1. 本サービスはAIによる自動応答です
  2. 医療、法律、緊急事態に関する専門的アドバイスは提供できません
  3. 緊急時は以下の専門機関にご連絡ください：
    [相談窓口リスト]
  4. 利用は自己責任でお願いします
  5. 会話ログは安全性向上のため記録されます

免責事項の限界

利用規約に書いても、全ての責任を免れるわけではありません。

「規約に書いてあるから大丈夫」ではない：

  • 明らかな過失があれば責任を問われる
  • 「合理的な対策」を講じていることが重要
  • 利用規約は最低限の防御線

思ってる以上に結構気軽に法廷コラボって身近なんですよね。って個人的に思ってます。
というか広告周りで仕事してた時に思いました。
小さいものから大きいものごとまで、という。
なので、防御策は取れるものは取っておいた方が良いよって思います。
働く側もえらい人たちが居ないとか、長期的に顔が死んでいると、だ、大丈夫？となるので。

プライバシーポリシー

会話ログを記録する場合：

  • その旨を明示
  • 保存期間
  • 利用目的
  • 第三者提供の有無
  • ユーザーの権利（削除要求等）

GDPRなど国際的なプライバシー規制も考慮しましょう。
最近は特に音声AIで文字起こし系のとかで火種を見かけますが、テキストのチャットボットだとしてもです。

保険の検討

将来的には：

  • サイバー保険
  • 事業者賠償責任保険
  • AI特有のリスクをカバーする保険商品

今はまだAI専門の保険は少ないですが、今後増えていくでしょう。
というか多分そういうビジネスが確立するだろうな、と思ってます。

まとめ：2つの安全性を両立する

本記事では、AIシステムにおける2つの安全性についてお話してました。

システムセキュリティ

攻撃者からシステムを守る：

  • プロンプトインジェクション対策
  • データ漏洩の防止
  • アーキテクチャレベルの防御

これはDev.toの優れた記事シリーズで詳しく解説されています。
日本人少ないですし、基本英語記事ですが国内で戦うにしろ世界で戦うにしろ情報や知見はいくらあっても良いので、ネットお散歩的にも楽しいですよ。(ダイナミック宣伝)
自分の赤ちゃんの夜泣き予測とかあったり、技術知見もあったりとやっぱおもろいです。

ユーザーセーフティ

システムがユーザーを傷つけないようにする：

  • 自殺・自傷行為の防止
  • 脆弱なユーザーの保護
  • 依存の防止
  • メンタルヘルスへの配慮

これがカリフォルニア州法案が求める安全性であり、本記事のテーマでしたね。
依存周りに関しては、今後も結構ニュースが飛び交いそうですかねぇ。

両方が必要

どちらか一方ではなく、両方が必要です。

  • システムが堅牢でも、ユーザーを傷つけては意味がありません。
  • ユーザーに優しくても、セキュリティが脆弱では信頼できません。

完璧は求めない、でも最善は尽くしておこう

重要なのは、完璧な解決策は存在しないという現実を受け入れつつ、できる限りの対策を講じることです。

  • シートベルトは事故を防ぎませんが、被害を減らします
  • ワクチンは100%防げませんが、リスクを大幅に下げます
  • AI安全対策も、完璧でなくても実装する価値があります

法律を待たずに行動する

日本にはまだAIチャットボットに関する明確な法規制がありません。しかし、法律ができるのを待つ必要はありません。
ことが起きてから、というのはそれこそやる事だらけで大忙しになりますからね…。
待ってても悪くはないですが、やれる事はやれるうちにやっておきましょうよ、って思います。

技術者の責任として

AIを使ったものを開発する私たちには、技術的な責任がどうあがいてもあります。

  • 便利なツールを作るだけでなく
  • 安全なツールを作る
  • ユーザーを守るツールを作る

Dify、n8n、その他のツールで簡単にAIチャットボットが作れる時代だからこそ、一人ひとりの開発者がこの責任を認識する必要があるのかな、と。
毎秒考えろ、とは思いませんがしっかり押さえるところ抑えておかないとだよな、と思った次第です。

最後に

カリフォルニア州の14歳少年の悲劇を、対岸の火事には出来ないな、と思います。

私たちが今日作るチャットボットやAIシステムが、誰かの命を救うかもしれません。あるいは逆に、誰かを傷つけてしまうかもしれません。

その重みを理解し、できる限りの対策を講じましょう。完璧ではなくても、何もしないよりは遥かにマシです。
何もせずにいきなり法廷オフコラボ！とか勘弁ですしね。

参考リンク

関連記事：

  • Prompt Injection 2.0: The New Frontier of AI Attacks
  • Building AI Systems That Don't Break Under Attack

日本の相談窓口：

  • いのちの電話: 0570-783-556
  • こころの健康相談統一ダイヤル: 0570-064-556
  • よりそいホットライン: 0120-279-338
  • 厚生労働省「まもろうよ こころ」

技術リソース：

Discussion