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

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

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

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

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

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

一方、事業者が教員や保護者で、生成結果を大人が確認してから子どもに見せる設計なら、「直接やり取り」には当たりにくくなります。ただし、その線引きが公式に示されているわけではありません。子どもの入力がそのままモデルに届く設計かどうかを、自社の構成図で確認するところから始めます。

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

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

Claudeそのものの年齢制限の話はClaudeの年齢制限、Anthropicの児童保護の考え方はClaudeの児童保護方針にあります。ここではAPIで作る側の実装に絞ります。

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

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

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

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

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

年齢確認の目的は、想定した年齢層の利用者だけを製品に入れることです。小学生向けの学習アプリなら、保護者アカウントを起点にして子どもの利用枠を発行する形が、生年月日の自己申告より確かな入口になります。

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

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

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

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

不適切または有害な内容を弾く層です。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つあります。

• 参照した公式ページには、その文面自体は載っていません。提供の有無や入手方法は、Anthropicからの案内で確認する必要があります。
• 提供されたとしても、ガイドラインは「有用だが万全ではない」と明記しています。自社の安全機能と併用する前提です。

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

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

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

実装は単純です。

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

子どもは、キャラクター化された相手を人だと受け取りやすい年齢層です。表示を文言だけで済ませず、アイコンや吹き出しの見た目でも区別できるようにすると、開示が形だけになりにくくなります。

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

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

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

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

監査と停止のリスク

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

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

実装前のチェックリスト

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

措置が万能でない前提で層を重ねる

ガイドラインは、Anthropicが提供する技術的措置も万全ではないと述べています。フィルタは抜けますし、年齢確認も回避されえます。だからこそ、入口の年齢確認、入力の事前分類、システムプロンプト、出力の検査、ログ監視を層にして重ねる設計になります。

ドキュメントも、複数の戦略を組み合わせて防御することを前提にしています。1つの仕組みの精度を上げ続けるより、別の種類の検査を足して穴を塞ぐほうが、子ども向けの製品では現実的です。

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