CAPTCHAとは

CAPTCHAとは

CAPTCHAとは、「コンピューターと人間を区別するための完全に自動化された公開チューリング・テスト*」の略です。これは、人間にとっては簡単でも機械にとっては難しい課題を提示することにより、ユーザーがボットではなく人間であることを検証するさまざまな認証方法を指します。

CAPTCHAは、詐欺師やスパムの発信者がボットを使用して悪意ある目的でWebフォームを完成させるのを防ぎます。

従来のCAPTCHAでは、光学式文字認識(OCR)技術では解釈できない歪んだ文字をユーザーに読ませ、それを正しく再入力する必要がありました。現在の新バージョンでは、AI駆動型の行動分析とリスク分析を使用して、単一のタスクではなく、アクティビティー・パターンに基づいて人間のユーザーを認証します。

多くのWebサイトでは、ハッカーがボットを使って実行する可能性があるアクション、例えばアカウント・プロファイルへのログイン、登録フォームの送信、またコメントの投稿や、その他のアクションを実行する前に、ユーザーがCAPTCHA提示する課題を完了する必要があります。この課題を完了することで、ユーザーは自分が人間であることを証明し、Webサイト上でのアクティビティーを続けることが許可されます。

* チューリング・テストとは作成者のアラン・チューリングにちなんで名付けられたものであり、人間の知性を発揮できるかどうか、機械の能力をテストするものです。

あなたのチームは時間内に次のゼロデイを受け入れますか?

AI、サイバーセキュリティ、データ、自動化に関する厳選されたニュースをThinkニュースレターで購読しているセキュリティリーダーに加わりましょう。専門家によるチュートリアルと解説をメールで直接配信することで、手軽に学ぶことができます。IBMプライバシー・ステートメントをご覧ください。

サブスクリプションは英語で配信されます。すべてのニュースレターに登録解除リンクがあります。サブスクリプションの管理や解除はこちらから。詳しくはIBMプライバシー・ステートメントをご覧ください。

https://www.ibm.com/jp-ja/privacy

CAPTCHAの進化

1990年代後半から2000年初頭にかけて、複数のさまざまなグループが初期の形態のCAPTCHAテクノロジーを並行して開発しました。各グループは、インターネット上の悪質なアクティビティーにボットを使用するハッカーが蔓延している問題への対処に取り組みました。例えば、検索エンジン、AltaVistaのコンピューター・サイエンティストは、ボットが会社のリンク・データベースに悪意あるWebアドレスが追加されないようにしたいと考えていました。

IT企業、Sanctumの研究者は、1997年に初のCAPTCHA方式システムを送り出しましたが、初めて2003年にCAPTCHAという用語を導入したのは、Luis von AhnとManuel Blumが率いる、カーネギー・メロン大学のコンピューター・サイエンス研究者グループでした。同グループは、何百万もの偽のEメール・アカウントに登録するスパムボットの問題に関するYahoo幹部の講演に触発されて、このテクノロジーに取り組むことにしました。

Yahooの問題を解決するため、von AhnとBlumが開発したコンピューター・プログラムは次のものです。

  1. ランダムな文字列を生成する
  2. テキストの歪んだ画像(「CAPTCHA コード」と呼ばれる)を生成する
  3. ユーザーにその画像を提示する
  4. フォーム・フィールドにテキストを入力し、「私はロボットではありません」という言葉の横にあるチェックボックスをクリックして入力内容を送信するようユーザーに求める

当時のOCRテクノロジーは、このような歪んだテキストの解読に苦労したため、ボットはCAPTCHAのテストに合格できませんでした。ユーザーが正しい文字列を入力した場合、そのユーザーは人間であると確実に想定でき、アカウント登録またはWebフォームの送信を完了することが許可されます。

Yahooはカーネギー・メロン大学のテクノロジーを導入し、Eメール・アドレスに登録する前にCAPTCHAのテストに合格することを全ユーザーに求めました。これにより、スパムボットの活動が大幅に減少し、他の企業はWebフォームを保護するためにCAPTCHAの採用を進めました。しかし、時間が経つにつれて、ハッカーは完了したCAPTCHAのテストからのデータを使用して、CAPTCHAテストに確実に合格できるアルゴリズムを開発したのです。これをきっかけに、 CAPTCHA開発者とサイバー犯罪者との間で絶え間ない激しい競争が始まり、CAPTCHA機能の進化に拍車をかけました。

reCAPTCHA v1

2007年にvon Ahnによって発表されたreCAPTCHA v1には2つの目的がありました。それは、ボットによるテキストベースのCAPTCHAテストの解読をより困難にすること、そして印刷されたテキストをデジタル化するため、当時使用されていたOCRの精度を向上させることです。

reCAPTCHAは、ユーザーに表示されるテキストの歪みを強め、最終的にテキストに線を追加することで最初の目標を達成しました。

2番目の目標は、ランダムに生成された歪んだテキストの1つの画像を、2つの異なるOCRプログラムによって実際のテキストからスキャンされた、2つの単語を歪んだテキスト画像に置き換えることで達成されました。最初の単語(制御語)は、両方のOCRプログラムによって正しく識別された単語で、2つ目の単語は、両方のOCRプログラムが識別できなかった単語です。ユーザーが制御語を正しく識別した場合、reCAPTCHAはユーザーが人間であるとみなし、次のタスクの続行を許可し、さらにユーザーが2番目の単語を正しく識別したと仮定し、その応答を将来のOCR結果を検証するために使用します。

reCAPTCHAはこのようにボット対策のセキュリティーを向上させ、Internet ArchiveやNew York Timesでデジタル化されているテキストの精度を向上させました。皮肉なことに、この技術は時間の経過とともに人工知能機械学習アルゴリズムの改善にも役立ち、2014年までには、彼らは最も歪んだテキストCAPTCHAを99.8%の確率で識別できるようになりました。

2009年、GoogleはreCAPTCHAを買収し、Googleブックスのテキストをデジタル化するために使用するとともに、他の組織にもサービスとして提供を開始しました。しかし、OCR技術がreCAPTCHAの助けを借りて進歩するにつれて、テキストベースのreCAPTCHAを効果的に解決できる人工知能プログラムも進歩しました。これを受けて、Googleは2012年に画像認識reCAPTCHAを導入し、歪んだテキスト認証をGoogleストリート・ビューから取得した画像認証に置き換えました。ユーザーは、街灯やタクシーなどの現実世界の物を識別することで、人間であることを証明しました。これらの画像ベースのreCAPTCHAは、ボットによって現在展開されている高度なOCRを回避するだけでなく、モバイル・アプリケーションのユーザーにとって、より便利であると考えられていました。

Google reCAPTCHA v2:No CAPTCHA reCAPTCHA

2014年、Google社はreCAPTCHA v2をリリースし、テキストおよび画像ベースのテストを「私はロボットではありません」という単純なチェックボックスに置き換えました。ユーザーがボックスをオンにすると、reCAPTCHA v2はユーザーのWebページとのやり取りを分析し、入力速度、Cookie、デバイス履歴、IPアドレスなどの要素を評価して、ユーザーが人間である可能性が高いかどうかを判断します。このチェックボックスはCAPTCHAの仕組みの一部でもあります。no CAPTCHA reCAPTCHAは、ユーザーがボックスをクリックする際のマウスの動きを追跡します。人間の動きはより無秩序になる傾向にありますが、ボットの動きはより正確です。ユーザーがボットである可能性が疑われる場合、画像ベースのCAPTCHAテストをユーザーに提示します。

reCAPTCHA v3

2018年にデビューしたreCAPTCHA v3は、チェックボックスを廃止し、no CAPTCHA reCAPTCHAのAI駆動型リスク分析を拡張しました。ReCAPTCHA v3は、JavaScript APIを介してWebページと統合され、バックグラウンドで実行し、ユーザーの行動を0.0(ボットの可能性が高い)~1.0(人間の可能性が高い)の尺度で採点します。Webサイトの所有者は、ユーザーのスコアがボットである可能性を示唆する特定の瞬間にトリガーされる自動アクションを設定できます。例えば、スコアの低いユーザーからブログ・コメントが「送信」されると、モデレート・キューに送信されたり、スコアの低いユーザーがアカウントにログインしようとするときに多要素認証プロセスを完了するよう求められたりする場合があります。

reCAPTCHA v3のようなAIベースの認証方法は、ハッカーの問題を回避することを目指して開発されています。CAPTCHA検証プロセスからインタラクティブなテストを削除することで、ハッカーが過去に解決したテストのデータを使用して、新しいCAPTCHAを解読するようボットをトレーニングするのを防ぎます。このため、専門家は、AIベースのCAPTCHAが標準になり、今後5年から10年でテストベースのCAPTCHAに完全に取って代わる可能性があると考えています。

CAPTCHAのユースケース

CAPTCHAテクノロジーは、ボット検知・防止対策として、以下のような一般的な用途があります。

  1. 偽装登録の防止
  2. 不審な取引からの保護
  3. オンライン投票の整合性の保護
  4. コメントおよび製品レビューのスパムの阻止
  5. ブルートフォース攻撃や辞書攻撃からの防御

偽装登録の防止

Eメール・アカウント、ソーシャル・メディア・プロファイル、またはその他のオンライン・サービスにサインアップする前にユーザーにCAPTCHAテストを提示することで、企業はこれらのサービスを使用してスパムやマルウェアを拡散したり、悪意ある活動を行うボットをブロックできます。CAPTCHAを最初に採用したのはYahoo、Microsoft、AOLなどの企業で、いずれもボットによる偽のEメール・アカウントの登録を阻止することが目的でした。

不審なトランザクションからの保護

Ticketmasterのような企業は、ボットがコンサート・チケットなどの限られた商品を買い占め、それらを流通市場で転売することを阻止するためにCAPTCHAを導入しました。

オンライン投票の整合性の保護

CAPTCHAのような抑止手段がなければ、ボットはオンライン投票も侵害されるでしょう。オンライン投票結果の整合性を守る必要性から、CAPTCHAのようなテクノロジーを使った初期の実験がいくつか開始されました。例えば、1996年の米国大統領選挙中のオンライン世論調査の質を確保するために、Digital Equipment Corporationは、投票する前に、Webページ上の旗のピクセル画像を見つけてクリックするようユーザーに求めました。

コメントおよび製品レビューのスパムの阻止

詐欺師やサイバー犯罪者はよく、ブログや記事のコメント欄を利用して詐欺やマルウェアを拡散します。また、eコマースのWebサイトや検索エンジンでの製品のランキングを人為的に上げるために、偽のレビューを大量に投稿するレビュー・スパムに関与する場合もあります。ボットは、保護されていないコメント・セクションを使用して嫌がらせ活動を実行することもできます。このような悪意あるアクティビティーは、コメントやレビューを投稿する前にCAPTCHAを完了するようユーザーに求めることで軽減できます。

ブルートフォース攻撃や辞書攻撃からの防御

ブルートフォース攻撃と辞書攻撃では、ハッカーはボットを使用してアカウントに侵入し、正しいパスワードを見つけるまで数字、文字、特殊文字の組み合わせを推測します。このような攻撃は、ログイン試行が一定回数失敗した後、ユーザーにCAPTCHAの完了を要求することで阻止できます。

CAPTCHAのデメリット

CAPTCHAテクノロジーは一般にボットの停止に効果的であることが証明されていますが、次のような欠点も少なからず存在します。

  1. 不便なユーザー体験
  2. アクセシビリティーの課題
  3. コンバージョン率の低下
  4. ボットAIが新しいCAPTCHAを打ち負かす可能性
  5. プライバシーに関する懸念

不便なユーザー体験

CAPTCHAのテストは、登録、ログイン、フォーム入力のプロセスに余分な手続きが追加され、不快に感じる人もいます。さらに、より高度なボットに対抗するためにCAPTCHAの複雑さが増すにつれて、CAPTCHAを解くユーザーにとってイライラするものになっています。2010年の調査では、スタンフォード大学の研究者が3人のグループに同じCAPTCHAを解くように依頼したところ、参加者がCAPTCHAの解答に全員一致で同意したのはわずか71%でした。またこの研究では、英語を母国語としない人はネイティブスピーカーよりもCAPTCHAを解くのが難しいことが判明し、CAPTCHAは一部の人口統計グループにとって他のグループよりも難しく感じる可能性があることを示唆しています。

アクセシビリティーの課題

テキストと画像のCAPTCHAは、視覚障害のあるユーザーにとって非常に困難、また解決が不可能なこともわかっています。これらのテストはマシンでは読み取れないように設計されているため、スクリーン・リーダーではほとんどのCAPTCHAのテストを読み取れないという事実が、この状況をさらに悪化させます。

代替のCAPTCHAがこの問題に対処しようと試みられていますが、それらには独自の限界があります。音声CAPTCHAは、文字化けした音声の解読をユーザーに要求するもので、解読が難しいことで知られています。前述のスタンフォード大学の研究によると、音声CAPTCHAの解決策にユーザーが全員一致で同意する割合は、わずか31%でした。

MAPTCHAは、ユーザーが簡単な数学の問題を解くことを要求するCAPTCHAの一種で、アルゴリズムによって解読される可能性が非常に高くなります。

アクセスできないCAPTCHAを使用すると、法的な影響も生じる可能性があります。1998年に導入された1973年リハビリテーション法の第508条改正は、米国連邦政府機関とその民間部門のパートナーに対し、障害者がデジタル情報にアクセスできるようにすることを義務付けています。利用可能なCAPTCHAオプションがない場合、企業はこの要件に違反する恐れも出てきます。

コンバージョン率の低下

ユーザーが不便さを感じ、CAPTCHAを利用できないと、コンバージョン率に悪影響が生じかねません。2009年に50のWebサイトを対象に実施されたケーススタディでは、ユーザーにCAPTCHAの入力を求めることで、正当なコンバージョンが3.2%減少しました。音声CAPTCHAは特に弊害をもたらす可能性があります。前述のスタンフォード大学の調査では、ユーザーは音声ベースのCAPTCHAの解決を50%の確率で諦めていることがわかりました。

ボットAIが新しいCAPTCHAを凌駕する可能性

CAPTCHA方式は、そのテクノロジーの誕生以来、何度も変更されてきました。これは、新しいCAPTCHAのテストを打ち負かすためにボットが常に進化し続けてきたためです。CAPTCHAはボットを阻止するために未解決のAI問題に依存しているため、CAPTCHAテクノロジーの構造自体がこの問題の原因となっています。人間がCAPTCHAのテストを解決すると、これまで不可能だったAIの問題を克服するために、機械学習アルゴリズムをトレーニングできるデータセットが生成されます。例えば、2016年にコンピューター・サイエンスの研究者であるJason Polakis氏は、Googleの逆画像検索を使用して、Googleの画像ベースのCAPTCHAを70%解決しました。

プライバシーに関する懸念

新しい形式のCAPTCHAは、インタラクティブなテストを完全に取り除くことでアクセシビリティーの問題を解決し、ボットの競争を阻止しようとしていますが、一部のユーザーや研究者は、AI駆動型のCAPTCHAは侵略的であると感じています。また、reCAPTCHA v3がコードとCookieを使用して複数のWebサイトでユーザーを追跡する方法について懸念の声が上がっています。この追跡データが検証以外の目的でどのように使用されるかについて、十分な透明性がないと感じている人もいるようです。

関連ソリューション
IBM Verify

IAMをモダナイズし、既存のツールと統合し、複雑さを増すことなくシームレスなハイブリッドアクセスを可能にする、安全でベンダーに依存しないIDフレームワークを構築します。

IBM Verifyの詳細はこちら
セキュリティー・ソリューション

データ、ID、脅威に対するインテリジェントな自動保護により、ハイブリッドクラウドと AI 環境を保護します。

セキュリティー・ソリューションの詳細はこちら
IDおよびアクセス管理サービス

ハイブリッドクラウド環境全体にわたる自動ID制御とリスクベースのガバナンスにより、ユーザーアクセスを保護および管理します。

    IAMservicesはこちら
    次のステップ

    Verifyを使用してIAMを強化してシームレスなハイブリッド・アクセスを実現し、隠れたIDベースのリスクをAIで明らかにすることで、ID保護を強化します。

    IBM Verifyの詳細はこちら IBM VerifyのID保護の詳細はこちら