編集方針・掲載基準・訂正

編集方針

• 根拠を示す。解説は公的資料・国際的な枠組み・各サービスの公式ドキュメントを根拠にし、記事の末尾に資料を載せます。数字には調査の主体と時期を添えます
• 確認日を示す。AIサービスの仕様や公的文書は改訂が多いため、記事には公開日と更新日を載せ、改訂を知った時点で更新します
• 断定しない。「この対策で漏洩は起きない」「完全に防げる」とは書きません。対策はリスクを下げるもので、組織の状況によって有効性が変わります
• 製品を推奨しない。特定の製品・サービスを推奨しません。運営会社の利害関係は運営者情報で開示しています
• 一般的な情報である。記事は一般的な情報の提供で、個別の助言ではありません。当サイトに監修者はいません。導入や規程の判断は、自社の状況に応じて専門家にご相談ください
• 生成AIの利用。記事の作成には生成AIを補助的に使っています。事実関係は出典で確認したうえで掲載します

事例集の掲載基準

対象

生成AI・AIツールに関わる、情報漏洩その他の情報セキュリティ上のインシデントです。次のような事例を含みます。

• 生成AIへの入力による機密情報・個人情報の漏洩
• AIサービス・AI開発基盤の不具合や設定ミスによる情報の露出
• プロンプトインジェクションなど、AIやAIを組み込んだ製品の脆弱性
• ディープフェイク・音声合成を使った詐欺やなりすまし
• 生成AIを悪用した攻撃・犯罪

一次発表があるものだけを載せる

次のいずれかの一次発表がある事例だけを掲載し、各事例にリンクを付けます。報道だけで、一次発表を確認できない事例は載せません。

• 当事者（企業・団体・自治体等）の公式発表
• 規制当局・警察・裁判所等の公表
• 製品ベンダーのセキュリティ勧告（CVE等）
• 脆弱性を発見した研究者・セキュリティ企業の公式な技術報告

書き方

• 概要・影響・当事者の対応は、一次発表の内容を当サイトの言葉で要約します
• 原因は、一次発表に書かれた範囲だけを載せます。書かれていなければ「公表なし」とし、推測では補いません
• 当事者の組織名は、その組織自身または当局が公表した場合に記載します。警察や当局の発表が被害を受けた組織の名前を伏せている場合は、その組織自身や別の当局の一次発表と、時期・サービスの種類・手口などが一致して同じ事件だと確認できるときに限り記載し、どの発表と一致したかを事例に明記します。報道だけを根拠には記載しません
• 公表日は、一次発表があった日（または月）です。逮捕などの事件で、当日の発表資料が公開されていない場合は、警察庁の報告書などに書かれた逮捕の時期を公表の時期としています
• 個人情報は載せません。被害を受けた個人を特定できる情報、漏洩した情報の中身、容疑者の実名は記載しません
• 各事例に公表日・掲載日・更新日を記載します。内容を改めたときは更新日を変え、訂正の内容を事例に残します

事例集の数字について

事例集と統計は、掲載基準を満たした事例だけを数えています。世の中で起きた事例のすべてではなく、件数の増減には掲載の増減も含まれます。

訂正・削除依頼の受付

掲載内容の誤り、当事者による続報・訂正、掲載基準に照らした削除のご依頼は、aisec-note@shigegegege.comまでお知らせください。該当するページのURLと、根拠となる一次発表（ある場合）を添えていただけると確認が早くなります。

• 確認のうえ誤りであれば修正し、事例ページに訂正の日付と内容を残します
• 当事者からの続報（原因の公表、影響範囲の確定など）は、一次発表を確認して反映します
• 一次発表が取り下げられた場合は、取り下げの事実を確認したうえで掲載を見直します

引用について

事例集・統計・解説の内容は、出典（AIセキュリティノート・ページのURL）を明記していただければ、記事や社内資料に引用できます。事例集のデータはJSONでも配布しています。個々の事例の事実関係は、各事例に付けた一次発表でご確認ください。

例: AIセキュリティノート「生成AI関連の情報漏洩・インシデント事例集」https://aisec-note.jp/incidents/