9
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@GeneLab_999

AIがOpenSSLのゼロデイを12個見つけた話〜20年以上見つからなかった脆弱性をAIが暴く〜

9
Posted at

この記事の対象読者

  • OpenSSLを利用するシステムの開発・運用に携わるエンジニアの方
  • AIによるセキュリティ研究の最前線に関心がある方
  • LLMやAIのサイバーセキュリティへの応用に興味がある方

この記事で得られること

  • AISLE社のAIシステムがOpenSSLで12個のゼロデイを発見した経緯と技術的背景の全貌が把握できる
  • CVE-2025-15467（CVSS 9.8）の攻撃原理: 認証不要でリモートコード実行が可能なスタックバッファオーバーフローの仕組みを理解できる
  • 「AIが人間を超えたのか」問題への冷静な見解: 攻撃者・防御者双方にとっての含意と、今すぐ実施すべきパッチ対応がわかる

この記事で扱わないこと

  • OpenSSL自体のセットアップや基本的な使い方
  • AISLE社のAIシステムの内部実装やアルゴリズムの詳細
  • AI脆弱性発見ツールの構築方法

1. この発見との出会い

「OpenSSLに新しいゼロデイ？ まあ、1〜2個でしょ」

2026年1月27日のOpenSSLセキュリティリリースのニュースを見た時の、正直な第一印象がこれだった。OpenSSLは世界のHTTPS通信の大半を支えるライブラリで、Google含む数千人のセキュリティ研究者が20年以上にわたって監査し続けている。数百万CPU時間のファジングも行われてきた。新しい脆弱性が出ても、せいぜい低リスクが1〜2個——そう思っていた。

ところが実態は全く違った。

12個のゼロデイ。すべてがAIによる発見。うち1個はCVSS 9.8のCritical。3個は1998年から25年以上潜伏していたバグ。

しかもこのAIシステムは、5件の脆弱性についてパッチまで提案し、OpenSSL公式リリースにそのまま採用されている。

Bruce Schneier氏（暗号学の権威）は自身のブログでこう述べている——「AI脆弱性発見は、予想より早くサイバーセキュリティを変えつつある。この能力は攻撃と防御の両方に使われるだろう」

ここまでで、この発見がなぜ歴史的なインパクトを持つのか、イメージが湧いたと思う。次は、この記事で使う用語を整理しておこう。

2. 前提知識の確認

本題に入る前に、この記事で登場する用語を確認する。

2.1 OpenSSLとは

SSL/TLS暗号化通信を実装するオープンソースライブラリ。Webサイト、VPN、メールサーバー、IoTデバイスなど、世界中のほぼすべての暗号化通信の基盤として使われている。料理で例えれば「世界中のレストランで使われている塩」——あまりに当たり前に存在するが、それが汚染されたら全員が被害を受ける。

2.2 ゼロデイ脆弱性とは

開発者やメンテナーが把握する前に存在する脆弱性のこと。「Day 0（0日目）」、つまり開発者が認知してから対処するまでの猶予がゼロであることに由来する。今回の12件は、すべてOpenSSLチームが把握していなかった「未知の脆弱性」だった。

2.3 CMS（Cryptographic Message Syntax）とは

暗号化メッセージの標準フォーマット。S/MIME電子メールの暗号化・電子署名、PKI（公開鍵基盤）のワークフロー、ドキュメント署名などに使われる。Outlook、Apple Mail、Thunderbirdなどのメールクライアントが日常的に処理している。

2.4 AISLE（AI Security Lab and Engineering）とは

AIを活用した脆弱性発見を専門とするセキュリティ研究組織。2025年秋から冬にかけてOpenSSLの調査を行い、12件のゼロデイを発見・責任ある開示を行った。OpenSSLだけでなく、curl、Linuxカーネル、Chromium、Firefoxなど30以上のプロジェクトで100件以上のCVEを獲得している。

これらの用語が押さえられたら、この発見が生まれた背景を見ていこう。

3. AIによる脆弱性発見が注目される背景

3.1 OpenSSLの「鉄壁」が崩れた意味

OpenSSLは、オープンソースプロジェクトの中でも最も徹底的にセキュリティ監査が行われてきたコードベースの一つだ。

監査の種類 規模
ファジング 数百万CPU時間
コードレビュー Google含む多数のチームが20年以上
バグ報奨金プログラム 長期運用
セキュリティ監査 2014年のHeartbleed以降、特に強化

この鉄壁の防御をすり抜けて25年間潜伏していたバグをAIが見つけた——これが従来のセキュリティ研究の常識を覆した理由だ。

3.2 AIと人間の「探し方」の違い

Schneier氏のブログのコメント欄で、暗号学者のClive Robinson氏が興味深い分析を展開している。

アプローチ 手法 強み 弱み
従来のファジング ランダムな入力で異常動作を探す 未知の脆弱性クラスを発見できる 効率が悪い、膨大な計算資源が必要
人間のコードレビュー パターン認識と経験に基づく 設計レベルの問題を発見できる スケールしない、見落としがある
AIによる分析 既知の脆弱性パターンを学習し、類似パターンを網羅的に探索 人間とファジングの中間で「方向性のある探索」が可能 全く新しい脆弱性クラスは見つけにくい

3.3 curlプロジェクトとの対照的なエピソード

AIセキュリティの光と影を象徴するエピソードがある。curlの開発者Daniel Stenberg氏は、AIによる低品質な脆弱性報告の洪水に耐えかねて、長年運用していたバグ報奨金プログラムを打ち切った。

一方、同じ時期にAISLEのシステムは、curlで5件のCVE（curl 8.18.0リリースの6件中3件）を発見し、Daniel氏自身がAISLEを高品質なAI駆動ツールとして評価している。

つまり「AIによる脆弱性報告」の問題は、AIの能力自体ではなく、低品質なAI利用と高品質なAI利用の格差にある。

出典: AISLE - What AI Security Research Looks Like When It Works

背景がわかったところで、具体的にどんな脆弱性が見つかったのか見ていこう。

4. 基本概念と仕組み：12個の脆弱性の全体像

4.1 発見された12件のCVE一覧

CVE 深刻度 脆弱性の種類 潜伏期間
CVE-2025-15467 CVSS 9.8 (Critical) CMS AuthEnvelopedData スタックバッファオーバーフロー 不明
CVE-2025-11187 Moderate PKCS#12 PBMAC1パラメータ検証不備 不明
CVE-2025-15468 Low QUICプロトコルの暗号処理でクラッシュ 不明
CVE-2025-15469 Low ポスト量子署名（ML-DSA）のサイレント切り詰め 不明
CVE-2025-66199 Low TLS 1.3証明書圧縮によるメモリ枯渇 不明
CVE-2025-68160 Low ラインバッファリングのメモリ破壊 1998年〜（26年以上）
CVE-2025-69418 Low OCBモードのハードウェアアクセラレーション暗号化不備 不明
CVE-2025-69419 Low PKCS#12文字エンコーディングのメモリ破壊 1998-2000年〜（25年以上）
CVE-2025-69420 Low TimeStamp Response検証でクラッシュ 不明
CVE-2025-69421 Low （詳細未公開） 不明
CVE-2026-22795 Low （詳細未公開） SSLeay時代（1990年代）から
CVE-2026-22796 Low （詳細未公開） 不明

注目すべきは、CVE-2026-22795がOpenSSL以前のSSLeay（Eric Young氏が1990年代に書いた元のライブラリ）から受け継がれた脆弱性だという点だ。

4.2 CVE-2025-15467の技術的詳細

12件の中で最も深刻なCVE-2025-15467について詳しく見る。

脆弱性の概要:

CMS AuthEnvelopedData構造体でAEAD暗号（AES-GCMなど）を処理する際、ASN.1パラメータに含まれる初期化ベクトル（IV）を固定サイズ（16バイト）のスタックバッファにコピーする処理で、IVの長さを検証していなかった。

攻撃フロー:
1. 攻撃者が特別に細工したCMSメッセージ（S/MIMEメール等）を作成
2. メッセージにオーバーサイズのIVを含むASN.1構造を埋め込む
3. 被害者のアプリケーションがOpenSSLのCMS APIでメッセージを復号しようとする
4. IVがスタックバッファをオーバーフロー → 認証チェック前にバッファ破壊が発生
5. RCE（リモートコード実行）が可能に

重要: この攻撃は有効な暗号鍵を必要としない。認証前にオーバーフローが発生するため、暗号的な保護を一切バイパスする。

影響を受けるバージョン: OpenSSL 3.0, 3.3, 3.4, 3.5, 3.6

修正済みバージョン: 3.6.1, 3.5.5, 3.4.4, 3.3.6, 3.0.19

4.3 AIが提案したパッチが公式採用された事実

12件中5件で、AISLEのAIシステムが提案したパッチがOpenSSLの公式リリースにそのまま採用された。つまりAIは脆弱性を「見つけた」だけでなく、「修正した」のだ。

出典: OpenSSL Security Advisory [27 January 2026]

基本概念が理解できたところで、実際に自分の環境の影響を確認しよう。

5. 実践：今すぐ確認すべきこと

5.1 OpenSSLバージョンの確認と更新

# 現在のOpenSSLバージョンを確認
openssl version -a

# 期待される出力例（修正済みバージョン）
# OpenSSL 3.4.4 27 Jan 2026 (Library: OpenSSL 3.4.4 27 Jan 2026)

5.2 環境別の対応設定ファイル

開発環境用（チェック用スクリプト設定）

# openssl_check_config.yaml - 開発環境用
environment: development
check_targets:
  - type: system_openssl
    min_version: "3.4.4"
  - type: python_ssl
    check_module: true
  - type: node_tls
    check_module: true
alert:
  level: WARNING
  notify: stdout

本番環境用（監視設定）

# openssl_check_config.production.yaml - 本番環境用
environment: production
check_targets:
  - type: system_openssl
    min_version: "3.4.4"
    critical: true
  - type: docker_images
    scan_registry: true
  - type: kubernetes_pods
    namespace: "*"
alert:
  level: CRITICAL
  notify:
    - slack_webhook: ${SLACK_SECURITY_WEBHOOK}
    - email: ${SECURITY_TEAM_EMAIL}
  auto_ticket: true

CI/CD環境用（ゲートチェック設定）

# openssl_check_config.ci.yaml - CI/CDパイプライン用
environment: ci
check_targets:
  - type: system_openssl
    min_version: "3.4.4"
  - type: container_base_image
    fail_on_vulnerable: true
  - type: dependency_scan
    tools: ["trivy", "grype"]
gate:
  block_deployment: true
  exception_process: "security_team_approval"

5.3 よくあるエラーと対処法

症状・状況 原因 対処法
openssl versionが3.0.x系の古いバージョンを返す OS標準のOpenSSLが未更新 ディストリビューションのパッケージマネージャで更新（apt update && apt upgrade openssl）
Dockerコンテナ内のOpenSSLが古い ベースイメージが古い ベースイメージを更新（FROM ubuntu:24.04の最新版を使用）
PyTorchやPythonのssl モジュールが脆弱 Python内蔵のOpenSSLが古い python -c "import ssl; print(ssl.OPENSSL_VERSION)"で確認し、Pythonを更新
Node.jsのTLS接続で警告が出る Node.js内蔵のOpenSSLが脆弱 Node.jsを最新LTSに更新
S/MIMEメールを処理するサーバーがある CVE-2025-15467の直接的な攻撃対象 即座にOpenSSLを更新。メール処理を一時停止も検討

5.4 環境診断スクリプト

#!/usr/bin/env python3
"""
OpenSSL脆弱性（2026年1月リリース）影響診断スクリプト
実行方法: python check_openssl_vuln.py
"""

import subprocess
import sys
import re
from typing import List, Tuple


# 修正済みバージョン
PATCHED_VERSIONS = {
    "3.6": "3.6.1",
    "3.5": "3.5.5",
    "3.4": "3.4.4",
    "3.3": "3.3.6",
    "3.0": "3.0.19",
}

# CVE-2025-15467の影響を受けないバージョン
SAFE_BELOW = "3.0.0"  # 3.0未満は影響なし（ただしEOL）


def parse_version(version_str: str) -> Tuple[int, ...]:
    """バージョン文字列をタプルに変換"""
    match = re.search(r'(\d+\.\d+\.\d+)', version_str)
    if match:
        return tuple(int(x) for x in match.group(1).split('.'))
    return (0, 0, 0)


def get_system_openssl_version() -> str:
    """システムのOpenSSLバージョンを取得"""
    try:
        result = subprocess.run(
            ["openssl", "version"],
            capture_output=True, text=True, timeout=5
        )
        return result.stdout.strip()
    except (FileNotFoundError, subprocess.TimeoutExpired):
        return "OpenSSL not found"


def get_python_openssl_version() -> str:
    """PythonのOpenSSLバージョンを取得"""
    try:
        import ssl
        return ssl.OPENSSL_VERSION
    except ImportError:
        return "ssl module not available"


def check_version_vulnerable(version_str: str) -> Tuple[bool, str]:
    """バージョンが脆弱かどうかを判定"""
    version = parse_version(version_str)
    if version == (0, 0, 0):
        return False, "バージョンを解析できません"

    major_minor = f"{version[0]}.{version[1]}"

    if major_minor not in PATCHED_VERSIONS:
        if version < parse_version(SAFE_BELOW):
            return False, "影響範囲外（ただしEOLの可能性）"
        return False, "不明なバージョン系列"

    patched = parse_version(PATCHED_VERSIONS[major_minor])
    if version < patched:
        return True, f"{PATCHED_VERSIONS[major_minor]}に更新してください"
    return False, "修正済みバージョンです"


def check_smime_exposure() -> List[str]:
    """S/MIME関連サービスの存在チェック"""
    issues = []
    services_to_check = [
        ("postfix", "メールサーバー（Postfix）"),
        ("dovecot", "メールサーバー（Dovecot）"),
        ("sendmail", "メールサーバー（Sendmail）"),
        ("exim", "メールサーバー（Exim）"),
    ]

    for process_name, description in services_to_check:
        try:
            result = subprocess.run(
                ["pgrep", "-x", process_name],
                capture_output=True, timeout=3
            )
            if result.returncode == 0:
                issues.append(
                    f"CRITICAL: {description}が稼働中 — "
                    f"CVE-2025-15467の直接的な攻撃対象です"
                )
        except (FileNotFoundError, subprocess.TimeoutExpired):
            continue

    return issues


def main():
    """メイン診断処理"""
    print("=" * 60)
    print("  OpenSSL 脆弱性診断ツール v1.0")
    print("  対象: 2026年1月27日リリース（12件のCVE）")
    print("=" * 60)

    all_issues = []

    # 1. システムOpenSSL
    print("\n[1] システムOpenSSL")
    sys_version = get_system_openssl_version()
    print(f"  バージョン: {sys_version}")
    is_vuln, msg = check_version_vulnerable(sys_version)
    if is_vuln:
        issue = f"CRITICAL: システムOpenSSLが脆弱です — {msg}"
        all_issues.append(issue)
        print(f"  [!] {issue}")
    else:
        print(f"  [OK] {msg}")

    # 2. Python OpenSSL
    print("\n[2] Python OpenSSL")
    py_version = get_python_openssl_version()
    print(f"  バージョン: {py_version}")
    is_vuln, msg = check_version_vulnerable(py_version)
    if is_vuln:
        issue = f"WARNING: Python内蔵OpenSSLが脆弱です — {msg}"
        all_issues.append(issue)
        print(f"  [!] {issue}")
    else:
        print(f"  [OK] {msg}")

    # 3. S/MIMEサービスチェック
    print("\n[3] S/MIME関連サービス")
    smime_issues = check_smime_exposure()
    if smime_issues:
        all_issues.extend(smime_issues)
        for issue in smime_issues:
            print(f"  [!] {issue}")
    else:
        print("  [OK] S/MIME関連サービスは検出されませんでした")

    # サマリー
    print("\n" + "=" * 60)
    print("  診断結果サマリー")
    print("=" * 60)

    critical = [i for i in all_issues if "CRITICAL" in i]
    warnings = [i for i in all_issues if "WARNING" in i]

    if critical:
        print(f"\n  CRITICAL: {len(critical)}件")
        for c in critical:
            print(f"    [!] {c}")
    if warnings:
        print(f"\n  WARNING: {len(warnings)}件")
        for w in warnings:
            print(f"    [!] {w}")
    if not all_issues:
        print("\n  [OK] 重大な問題は検出されませんでした")

    return 1 if critical else 0


if __name__ == "__main__":
    sys.exit(main())

5.5 Docker設定（更新済みOpenSSLを含むベースイメージ）

# Dockerfile - OpenSSL修正済みベースイメージ
FROM ubuntu:24.04

# OpenSSLを最新に更新
RUN apt-get update && \
    apt-get upgrade -y openssl libssl3t64 && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

# バージョン確認を含むヘルスチェック
HEALTHCHECK --interval=30s --timeout=3s \
  CMD openssl version | grep -E '3\.(0\.19|3\.6|4\.4|5\.5|6\.1)' || exit 1

WORKDIR /app

# docker-compose.yml - セキュリティスキャン付きビルド
version: '3.8'
services:
  app:
    build: .
    ports:
      - "8443:8443"
    environment:
      - SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt
    deploy:
      resources:
        limits:
          cpus: '2'
          memory: 2G

  # Trivyによる脆弱性スキャン（CI用）
  vuln-scan:
    image: aquasec/trivy:latest
    command: image --severity CRITICAL,HIGH app:latest
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

実装方法がわかったので、次は利用シーン別の対応を見ていく。

6. ユースケース別ガイド

6.1 ユースケース1: S/MIMEメールを処理するサーバーを運用している管理者

想定読者: 企業のメールサーバーやS/MIME暗号化メールの処理基盤を管理している方

リスクレベル: ★★★★★（極めて高い — CVE-2025-15467の直接攻撃対象）

サンプルコード（即座にバージョンを確認）:

#!/bin/bash
# mail_server_openssl_check.sh
# メールサーバーのOpenSSLバージョンを緊急確認するスクリプト

echo "=== メールサーバー OpenSSL 緊急チェック ==="

# システムOpenSSL
OPENSSL_VER=$(openssl version 2>/dev/null)
echo "システムOpenSSL: $OPENSSL_VER"

# Postfix
if command -v postconf &>/dev/null; then
  POSTFIX_TLS=$(postconf -h tls_ssl_options 2>/dev/null)
  echo "Postfix TLS設定: $POSTFIX_TLS"
  echo "[ACTION] Postfixが稼働中 — OpenSSLを即座に更新してください"
fi

# Dovecot
if command -v dovecot &>/dev/null; then
  DOVECOT_VER=$(dovecot --version 2>/dev/null)
  echo "Dovecot: $DOVECOT_VER"
  echo "[ACTION] Dovecotが稼働中 — OpenSSLを即座に更新してください"
fi

echo ""
echo "修正済みバージョン: 3.6.1, 3.5.5, 3.4.4, 3.3.6, 3.0.19"
echo "詳細: https://openssl-library.org/news/secadv/20260127.txt"

6.2 ユースケース2: Webアプリケーション開発者

想定読者: HTTPS通信を行うWebサービスを開発・運用している方

リスクレベル: ★★★☆☆（中程度 — TLS通信自体は直接の攻撃対象ではないが、依存ライブラリ経由で影響する可能性）

サンプルコード（依存関係チェック）:

#!/usr/bin/env python3
"""
WebアプリケーションのOpenSSL依存関係チェック
"""

import ssl
import subprocess
import json


def check_web_app_openssl():
    """Webアプリの依存ライブラリ経由のOpenSSLをチェック"""

    print("=== Webアプリ OpenSSL依存チェック ===\n")

    # Python SSL
    print(f"Python ssl: {ssl.OPENSSL_VERSION}")

    # pip依存関係のOpenSSLバインディング
    try:
        result = subprocess.run(
            ["pip", "list", "--format=json"],
            capture_output=True, text=True, timeout=10
        )
        packages = json.loads(result.stdout)
        ssl_related = [
            p for p in packages
            if any(k in p['name'].lower()
                   for k in ['cryptography', 'pyopenssl', 'ssl', 'tls'])
        ]
        if ssl_related:
            print("\nSSL関連パッケージ:")
            for p in ssl_related:
                print(f"  {p['name']} == {p['version']}")
    except Exception:
        pass

    # Node.js（存在する場合）
    try:
        result = subprocess.run(
            ["node", "-e", "console.log(process.versions.openssl)"],
            capture_output=True, text=True, timeout=5
        )
        if result.stdout.strip():
            print(f"\nNode.js OpenSSL: {result.stdout.strip()}")
    except FileNotFoundError:
        pass

    print("\n[推奨] cryptographyパッケージを最新版に更新してください")
    print("  pip install --upgrade cryptography pyopenssl")


if __name__ == "__main__":
    check_web_app_openssl()

6.3 ユースケース3: GPU計算環境やAI/ML基盤の管理者

想定読者: PyTorch、CUDA環境でモデルのダウンロードやAPI通信を行っている方

リスクレベル: ★★☆☆☆（低〜中 — 直接攻撃は受けにくいが、SSL通信で脆弱なOpenSSLを使用している可能性）

サンプルコード（AI環境チェック）:

#!/bin/bash
# ai_env_openssl_check.sh
echo "=== AI/ML環境 OpenSSLチェック ==="

# conda環境のOpenSSL
if command -v conda &>/dev/null; then
  echo "Conda OpenSSL:"
  conda list openssl 2>/dev/null | grep openssl
  echo "[推奨] conda update openssl"
fi

# Python環境（venv/pip）
python3 -c "import ssl; print(f'Python SSL: {ssl.OPENSSL_VERSION}')" 2>/dev/null

# PyTorchのSSL利用
python3 -c "
try:
    import torch
    import ssl
    print(f'PyTorch {torch.__version__} uses {ssl.OPENSSL_VERSION}')
except ImportError:
    print('PyTorch not installed')
" 2>/dev/null

echo ""
echo "AI環境でのリスク: モデルダウンロード時のMITM攻撃の可能性"
echo "[推奨] pip install --upgrade certifi urllib3"

ユースケースを把握できたところで、この先の学習パスを確認しよう。

7. 学習ロードマップ

この記事を読んだ後、次のステップとして以下をおすすめする。

初級者向け（まずはここから）

  1. 上記の診断スクリプトを自分の環境で実行する
  2. OpenSSL公式セキュリティアドバイザリで修正済みバージョンを確認する
  3. 使用しているLinuxディストリビューションのセキュリティアップデートを適用する

中級者向け（実践に進む）

  1. AISLEのCVE-2025-15467技術的Deep Diveでスタックオーバーフローの詳細を理解する
  2. CI/CDパイプラインにOpenSSLバージョンチェックのゲートを導入する
  3. TrivyやGrypeなどのコンテナ脆弱性スキャンツールを導入する

上級者向け（さらに深く）

  1. AISLEのフルレポートでAIセキュリティ研究の方法論を学ぶ
  2. Schneier on Security - AI Found Twelve New Vulnerabilities in OpenSSLのコメント欄で暗号学者の議論を読む
  3. OpenSSLのソースコードレビューに参加し、オープンソースセキュリティに貢献する

8. まとめ

この記事では、AIがOpenSSLで12個のゼロデイ脆弱性を発見した歴史的事例について解説した。

  1. AISLE社のAIが12件中12件すべてを発見 — 世界で最も監査されたコードベースで、20年以上見つからなかったバグをAIが暴いた
  2. CVE-2025-15467はCVSS 9.8のCritical — 認証不要でリモートコード実行が可能な、S/MIMEメール処理経由の攻撃
  3. AIはパッチも提案し、5件が公式採用 — 「見つける」だけでなく「直す」段階までAIが到達

私の所感

この事例で最も考えさせられたのは、**「AIによる脆弱性発見は攻撃者にも防御者にも使える」**というデュアルユース（二重用途）の問題だ。

今回はAISLEが責任ある開示を行い、OpenSSLチームと協力してパッチを作成した。これは防御側のベストケースだ。しかし同じ能力を持つAIが攻撃者の手に渡れば、ゼロデイの大量生産が可能になる。

Schneier氏は「AI脆弱性発見は予想より早くサイバーセキュリティを変えつつある」と述べたが、私はもう一歩踏み込んで言いたい——AI脆弱性発見の「質」の格差が、今後のサイバーセキュリティの勝敗を決める。curlのバグ報奨金プログラムを殺した低品質AI報告と、OpenSSLの12件を発見した高品質AI分析。この差こそが、私たちが注視すべきポイントだ。

参考文献

この記事が役に立ったら、いいね・ストックしていただけると励みになります。
AI×セキュリティのトピックで気になることがあれば、コメントで教えてください。

他にもAI/セキュリティ関連の記事を書いています:

X（Twitter）でもAI/ML系の情報を発信中 → @geneLab_999

9
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
9
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?