Claude APIを未成年向けサービスに組み込む — 実装する安全対策

学習アプリや子ども向けの相談サービスにClaude APIを組み込むなら、Anthropicが事業者側に求める安全対策を、設計の段階で実装項目に落としておく必要があります。求められるのは大きく3つです。追加の技術的措置、法令遵守の明示、AIと話していることの開示です。

この記事では、この3つを「何を作れば満たせるか」の単位に分け、Claude API側で使える部品と組み合わせて示します。まず、子どもがClaude自体を使えるのかを確認しておきます。

未成年はClaudeを使えるのか

消費者向けのClaudeは18歳以上専用です。アカウントを作るときに、18歳以上であることを確認します。

未成年の兆候を検知すると、利用を止めて年齢確認を求めます。確認に通ればアカウントは復旧します。詳しい流れはClaudeの年齢制限にあります。

子どもに使わせるなら、事業者がAPIで作った製品を通す形になります。その事業者には追加の安全対策が求められます。

対象になるのは「未成年が直接やり取りする製品」

Anthropicのガイドラインが対象にしているのは、未成年がAPIを組み込んだ製品と直接やり取りできる組織です。Usage Policyでは、消費者向けチャットボット、未成年向け製品、エージェント用途、MCPサーバーが「追加の利用ガイドライン」の対象として並んでいます。未成年向け製品はその中で、ヘルプセンターの記事に書かれた追加ガイドラインに従うことが求められます。

ここでいう未成年は、管轄にかかわらず18歳未満です。日本の成年年齢とは関係なく、この定義で扱われます。

一方、事業者が教員や保護者で、生成結果を大人が確認してから子どもに見せる設計なら、「直接やり取り」には当たらないと読める余地があります。ただ、Usage Policyとガイドラインのページには、大人を経由する構成の扱いは書かれていません。子どもの入力がそのままモデルに届く設計かどうかを、自社の構成図で確認するところから始めます。

判断の目安として、構成ごとに子どもの入力がどこでモデルに届くかを並べると次のようになります。この表は入力の経路に着目した整理で、公式の線引きではありません。

迷う構成は、当たるものとして安全対策を入れておくほうが、後から作り直すより手戻りが小さくなります。

Anthropicの児童保護の考え方はClaudeの児童保護方針にあります。ここから先は、APIで作る側の実装を扱います。年齢を問わない共通の土台はClaude APIの安全対策にあります。

求められる3つの義務を実装項目に置き換える

ガイドラインが並べる項目を、実装のチケットに近い粒度に分けると次の表になります。

追加の技術的措置は「次のようなものを含みうるが、これに限らない」という書き方です。決まったチェックリストがあるわけではなく、自分の製品で子どもがどう使うかを一番よく知っているのは事業者だから、その用途に合わせて作るという前提です。

同じ要求でも、文書によって書き方が違う

2つの文書で動詞の強さが違います。実装の優先順位をつけるときの手がかりになります。

措置の中身は設計判断に委ねられる一方、従うこと自体は利用規約上の条件です。AI開示だけは、どちらの文書でも言い切りの要求になっています。

追加の技術的措置を4つに分けて作る

年齢確認 — 意図した利用者だけが入れるようにする

年齢確認の目的は、想定した年齢層の利用者だけを製品に入れることです。小学生向けの学習アプリなら、保護者アカウントを起点にして子どもの利用枠を発行する形が、設計の一例です。

実装としては、次の3点を最初に決めます。

• 誰がアカウントを作るか(保護者か本人か)
• 想定外の年齢層が入ったときに止める手段があるか
• 確認の結果をどこに記録するか

年齢確認の方式そのものはガイドラインに指定がありません。方式の選択は事業者の設計判断です。

参考になるのは、冒頭で触れた消費者向けClaudeの年齢確認です。

確認は第三者のYotiを通し、顔写真からの年齢推定、身分証の撮影、Yotiの「18歳以上」属性の共有から選べます。Anthropicが受け取るのは合否の結果だけで、顔や身分証の画像はYotiが確認後すぐに削除するとされています。APIの事業者に同じ方式が求められるわけではありませんが、確認手段を複数用意し、個人情報を自社で持たない設計にする際の参照になります。

モデレーションとフィルタリング — 入力と出力の両側に置く

不適切または有害な内容を弾く層です。Claude APIのドキュメントには、脱獄(jailbreak)対策の一つとして、軽量なモデルで入力を事前に分類する「無害性スクリーン」が載っています。ドキュメントの例はClaude Haiku 4.5で、構造化出力を使って分類結果を真偽値だけに絞ります。

次の断片は、その考え方を子ども向けに寄せた例です。判定の文言は、ドキュメントの例を子ども向け製品の文脈に合わせて書き換えた形になっています。

import json
import anthropic
 
client = anthropic.Anthropic()
 
SCREEN_SCHEMA = {
    "type": "object",
    "properties": {"is_harmful": {"type": "boolean"}},
    "required": ["is_harmful"],
    "additionalProperties": False,
}
 
def is_harmful(user_text: str) -> bool:
    resp = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=50,
        messages=[{
            "role": "user",
            "content": (
                "A user submitted this content:\n"
                f"<content>\n{user_text}\n</content>\n\n"
                "Classify whether this content refers to harmful, "
                "illegal, or explicit activities."
            ),
        }],
        output_config={
            "format": {"type": "json_schema", "schema": SCREEN_SCHEMA}
        },
    )
    return json.loads(resp.content[0].text)["is_harmful"]

is_harmful が真なら、本体の会話モデルには渡さず、固定の案内文を返します。この前段はあくまで例で、自社の子ども向けポリシーに合わせて分類の基準を書き直す前提です。

ドキュメントが勧めるのは入力の事前分類ですが、同じ発想を応答文にも当てはめると、入力を通り抜けた内容を拾えます。入力だけ、出力だけ、どちらか片側では穴が残ります。

応答文への適用は記事側の設計例で、会話モデルの応答文を同じ分類にかけ、真なら差し替え文を返す形です。次の断片は、上の is_harmful を使い回しています(分類の文言は入力側と同じく自社ポリシーに合わせて書き直します)。

FALLBACK = "この質問には答えられません。おうちの人か先生に相談してみてね。"
 
def reply_to_child(user_text: str) -> str:
    if is_harmful(user_text):
        log_event("input_blocked")
        return FALLBACK
    answer = generate_answer(user_text)  # 会話モデルの呼び出し
    if is_harmful(answer):
        log_event("output_replaced")
        return FALLBACK
    return answer

差し替え文は短くやさしい言葉にし、相談先へ誘導する一文を入れておきます。log_event で残した件数は、次の監視の節で使います。

監視と通報 — 見つけて対処する回路を作る

監視と通報は、問題を検知して人が対処するまでの流れです。ドキュメントは、出力を継続的に分析して、うまくいった攻撃の兆候を探し、プロンプトや検証、フィルタを改善することを勧めています。

同じ種類の拒否を何度も引き起こす利用者への対応も書かれています。応答を調整し、繰り返し回避を試みる利用者には制限や停止を検討し、利用規約に反する行為だと本人に伝えます。子ども向けの製品では、停止の前に保護者へ通知する段階を挟むかどうかが設計上の論点になります。

段階は、たとえば次のように分けられます。閾値は自社で決める設計例です。

児童の安全に関するガイダンスには、透明性レポートのためにログ記録を組み込むことを検討するよう書かれています。実装するなら、最低限次の記録が要ります。

• 入力が弾かれた回数(利用者単位)
• 出力側で差し替えた応答の件数
• 保護者・運営者に上げる基準と連絡先

未成年向けの利用ガイド — 使い方を子どもに伝える

4つ目は、安全で責任ある使い方を未成年に伝える教材や案内です。ガイドラインの記述は「教育的なリソースとガイダンス」で、形式は指定されていません。初回起動時の短い説明や、保護者向けの使い方ページが該当します。

子ども向け安全システムプロンプトは自社の安全策を置き換えない

ガイドラインには、Anthropicが未成年を含む特定の利用者向けに体験を調整する技術的措置を提供する場合があり、その例として子ども向けの安全システムプロンプトが挙がっています。未成年向けの事業者は、これを包括的な安全対策の一部として実装するよう求められます。

ここで注意したい点が2つあります。

• ガイドラインのページには「提供する場合がある」(may provide)とあるだけで、文面は載っていません。提供の有無や入手方法は、Anthropicからの案内で確かめることになります。
• 提供されたとしても、ガイドラインは「有用だが万全ではない」と明記しています。自社の安全機能と併用する前提です。

自前のシステムプロンプトを書く場合は、倫理・法令上の境界を明示し、断るときの言い方まで指示に含めるのがドキュメントの推奨です。子ども向けなら、断るときの文面を短くやさしい言葉にし、相談先(保護者や学校)へ誘導する一文を入れるといった調整が考えられます。

AI開示は「最初のチャットの冒頭」で行う

ガイドラインは、利用者がAIと話していることを開示するよう求めています。消費者向けのチャットボットは、少なくとも各チャットセッションの冒頭でAIであることを開示する、というのがUsage Policyの書き方です。

実装は単純です。

• 会話画面の最初に、AIが答えていることを示す表示を固定で置く
• キャラクターや愛称を付ける場合でも、AIであることは別途示す
• 新しいセッションを始めるたびに、同じ表示が出るようにする

表示を文言だけで済ませず、アイコンや吹き出しの見た目でも区別できるようにしておくと、キャラクターを付けた画面でも開示が埋もれにくくなります。

法令遵守は「守る」だけでなく「書く」

ガイドラインが求めるのは、児童の安全とデータ保護に関する法令に従うことと、その遵守を自社サイトなど公開されている文書に明記することです。例として挙がっているのは、米国の児童オンラインプライバシー保護法(COPPA)です。

COPPAは米国の法律なので、日本の利用者だけを対象にするサービスにそのまま当てはまるとは限りません。日本向けなら、国内で適用される個人情報や児童保護の法令を、事業者自身が確認して公開文書に反映します。米国の利用者が使える構成なら、COPPAも確認の対象です。

書く場所の候補は次のとおりです。

子ども向け製品でなくても負う児童安全の責任

未成年向けの追加措置とは別に、Anthropicの開発者向けガイダンスは、APIで製品を作るすべての事業者に児童の安全の責任があると書いています。規模や用途は問われません。

理由は、利用者や顧客が、児童の性的搾取に当たる画像をアップロードしたり、未成年を性的に描く出力を引き出したり、出力を子どもへの働きかけ(グルーミング)や性的脅迫(sextortion)に利用したりしうるからです。対策を実装する責任は、デプロイする事業者側にあります。Anthropicは、API利用の違反を監視し、方針と法的義務に沿って執行すると述べています。

この責任は規模や用途を問わないとされているので、未成年向けでない製品でも、画像のアップロードや利用者同士のやり取りがあるなら検討の対象です。

通報と検知については、同じページが出発点になる外部の資源を挙げています。

構成の正解は1つではなく、プラットフォームの規模、利用者が投稿・生成できる面、管轄によって変わると明記されています。米国以外で運営する場合は、各国の通報要件を確認するよう書かれています。なお同ページは情報提供であり、法的助言ではないと断っています。

監査と停止のリスク

Anthropicは、これらの安全策について組織を定期的に監査するとしています。違反率が高いのに対策を実装していない組織には、実装を求めることがあります。求められても実装しない場合や、違反が続く場合は、アカウントの停止や終了につながりえます。

Usage Policyにも、違反を把握した場合はアクセスを絞る(throttle)・停止・終了することがあると書かれています。入力がポリシーに反するときは、モデルの出力をブロックまたは修正することもあります。子ども向けサービスは、アカウントが止まると利用者への影響が大きいため、対策の実装と記録の保管を、監査を受ける前提で整えておく価値があります。

実装前のチェックリスト

ここまでを、着手前に確認する項目にまとめます。

1つの仕組みに頼らず層を重ねる

フィルタは抜けますし、年齢確認も回避されえます。入口の年齢確認、入力の事前分類、システムプロンプト、出力の検査、ログ監視を層にして重ね、1つが破られても次で止める設計にします。ドキュメントも、複数の戦略を組み合わせて防御することを前提にしています。

外部の文書や検索結果をモデルに読ませる機能を子ども向けに付けるなら、間接的なプロンプトインジェクションも別の穴になります。詳しくはClaudeが間接プロンプトインジェクションを拒否する理由と対策を参照してください。禁止用途の全体像はAnthropicのAcceptable Use Policyにまとめています。