記事内に広告が含まれています。

小さく歪んだひらがなに2日で7回負けた。画像認証をAIが読めないとき

失敗の切り分けと、観測条件と読み手を見直すという解決

この記事でわかること

• AIの失敗を「AIができない」と一括りにせず、手順の問題と対象の状態の問題に分ける観点を整理します。
• 同じ手順を繰り返す前に、対象を観測しやすい形に変えることと、読み取りを担う主体を替えることの、2つの見直しを説明します。
• 画像認証のように小さく歪んだ文字を扱うとき、拡大とコントラスト調整が観測条件になることです。
• 複数のAIに画像認証の画像を読ませようとしたとき、断る理由、利用上限、読み取り精度の限界はそれぞれ違うことです。
• 第1回の「完了は独立した経路で観測された状態で判定する」という考え方を、入力側の観測に接続する方法を述べます。
• 失敗の所在を手順、対象の状態、AI側の理由に分け、それぞれの対処を選ぶための表を示します。

直前まで通っていたログインが、突然通らなくなった

連載「AI運用の設計」の第2回です。今回は、私が管理しているWordPressサイトの管理画面ログインで起きた失敗を扱います。2026年10月25日の夜から26日の朝にかけて、担当したAIによるログインが、SiteGuardの画像認証のある画面で2日で計7回失敗しました。内訳は、25日夜に4回、26日朝に3回です。

これは、他人のサービスの認証を突破する話ではありません。私自身のサイトで、私自身のアカウントにログインするときの出来事です。目的は、記事の公開や画像のアップロードといった本来の作業を進めることでした。その前提で、失敗をどう切り分け、どう解決したかを書きます。

私のWordPress管理画面には、SiteGuardの画像認証があります。表示されるのは、72×24ピクセルの、小さく歪んだひらがなです。人間が目で見て入力することを前提にした、短い文字列の画像です。

直前には、同じ保存済みログインと手順で2回の作業が成功していました。1回目は下書きのゴミ箱移動で、2回目は記事の公開でした。どちらもログインできていました。ところが、25日の夜から、同じ手順でログインできなくなりました。

25日の夜は、4回失敗したところで試行を止めました。失敗が重なったため、アカウントがロックされる恐れを考えたからです。一度時間を置けば状態が変わる可能性も考えました。そこで、26日の朝に再試行しました。しかし、26日の朝も3回失敗し、再び試行を止めました。合計で7回です。同じ保存済みログインと手順を使っていたのに、直前の2回の作業ではログインできていました。この違いを、私は最初の時点では説明できませんでした。

失敗したときのエラーメッセージは「入力内容を確認の上、もう一度送信してください」という汎用的なものでした。画面からは、画像認証の読み違いなのか、保存済みパスワードの不一致なのかを判別できませんでした。エラー表示だけを見ていると、疑う対象が広がりすぎます。私はまず、これ以上試行を重ねないことを優先しました。

さらに、担当したAIが画像認証から読み取った内容は、回ごとに異なっていました。記録に残っている読みの例では、「りとささ」「まみえ」「うあたゆ」「べえあ」などがあります。ただし、これは担当したAIが出力した読みの例であり、どれが正しい読みなのかは、その時点では分かりませんでした。回ごとに読みが変わり、確信を持てる読みが得られなかったことが、失敗の経緯として残っています。

この時点で私が分かっていたのは、直前には同じ手順で成功していたこと、25日夜に4回失敗して止めたこと、26日朝に3回失敗して再び止めたこと、エラーが汎用的で原因の種類を画面から判別できなかったこと、担当したAIの読み取りは回ごとに異なり確信を持てる読みが得られなかったこと、アカウントロックの恐れを考えて試行を途中で止めたことでした。原因の断定はできていませんでしたが、少なくとも、闇雲に回数を増やす方針は取らないと決めました。

手順は間違っていなかった

私は、ログインの手順を最初から見直しました。保存済みログインを使い、画像認証の文字を入力し、送信するという順番は、直前の2回と同じでした。少なくとも、同じ手順で直前に成功していた記録があります。そのため、私は最初から手順全体が壊れたとは考えませんでした。

手順が正しくても、対象の状態が違えば、結果は違います。

ここでいう対象の状態には、画像認証の画像そのものの見え方、表示サイズ、歪み方、画面の状態、保存済みログイン情報の状態などが含まれます。ただし、今回の汎用エラーだけでは、どの状態が違うのかまでは分かりませんでした。そこで、手順を何度も繰り返すのではなく、切り分けの材料を増やす方向に変えました。

第1回では、AIの「完了しました」という報告を、独立した経路で観測された状態と照らし合わせる話を書きました。今回はその入力側です。入力の失敗も、同じ画面を同じ見方で繰り返すだけでは、原因の候補を絞れません。見方を変える必要がありました。

私は、手順の確認と対象の確認を分けて考えました。手順の確認では、保存済みログインの使い方、入力する項目、送信の順番を見ます。対象の確認では、画像認証の画像がどう見えているか、読み取りに使える材料が何かを見ます。この二つを混ぜると、「同じ手順なのに失敗する」という事実だけが残り、次の行動につながりませんでした。手順は維持しつつ、対象の観測条件を変える余地を探すことにしました。

他のAIに読ませてみた

私は、画像認証の画像を他のAIに読ませることも試しました。結果は、AIごとに理由が違いました。

Claudeは「画像認証は人が直接入力することを前提にした仕組み」として、読み取りを断りました。これは読み取り精度の問題ではなく、方針としての判断です。私はこの判断を、Claudeの方針として尊重しました。読み取りを押し付けはせず、別の経路を探すことにしました。

ChatGPTは、無料プランのアップロード上限に達していて、画像を添付できませんでした。上限の解除には約23時間待つか、有料プランが必要でした。これは能力の限界ではなく、利用条件の制約です。

今回ログイン作業を担当したAIの場合は、画像認証の読み取り精度の限界が候補として残りました。25日夜の4回と26日朝の3回で、読み取りの内容は回ごとに異なっていました。記録に残っている例だけでも、「りとささ」「まみえ」「うあたゆ」「べえあ」などがあり、確信を持てる読みは得られていませんでした。なお、汎用エラーだけでは、保存済みパスワードの不一致なのか、画像の読み違いなのかを確定できませんでした。また、読み取りの内容が試行ごとに異なっていたことも、同じ画像への読みが安定しなかったことを示すものではありません。試行のたびに画像そのものが新しいものに差し替わっていたからです。失敗の理由を、画像の見え方の厳しさと読み取り精度の限界の、どちらか一方に決める材料もありませんでした。読み取りに確信を持てなかったという事実は残りますが、それだけで失敗の原因全体を断定することはできませんでした。

なお、進行役のAIは、この画像を元のサイズでは読み取っていません。進行役のAIが読んだのは、12倍に拡大してコントラストを強めた後の画像です。そのため、進行役のAIの読み取り精度そのものを、担当したAIと比べる材料もありません。

AIができない理由は、AIごとに違います。

同じ「読めない」という結果でも、方針で断る場合、プランの上限で試せない場合、読み取り精度の限界の場合があります。これらをまとめて「AIは画像認証ができない」と結論づけると、次の打ち手を誤ります。少なくとも、私は今回、AI一般の能力を評価する話ではなく、目の前の作業をどう観測するかの話として捉え直しました。担当したAIからは、どの試行でも確信を持てる読みが得られませんでした。一方で、Claudeの断りは方針の話であり、ChatGPTの制約はプランの話でした。同じ種類の画像を前にしても、試せない理由が違うのです。この違いを分けて記録しておくと、次に同じ場面に遭遇したときに、無駄な試行を減らせます。

拡大した画像を、進行役のAIが読んだ

解決のきっかけは、画像認証の画像ファイルそのものを、別の形で観測することでした。あわせて、画像を読む主体も、ログイン担当のAIから進行役のAIに替わりました。ログイン画面に表示されている画像認証の画像ファイル（PNG）は、アドレスから直接取得できました。

この画像の処理は、運用の進行役を担うAIが行いました。進行役のAIが画像を取得し、12倍に拡大し、コントラストを強め、歪んでいたひらがなを読み取りました。読み取った4文字を、私がログインを担当していたAIに渡して入力と送信を任せると、1回の送信でログインできました。その後は、画像のアップロードや記事の更新など、本来の作業をすべて完了できました。

拡大前の画像は、72×24ピクセルでした。小さく歪んだひらがなが数文字並んだ画像です。そこで、進行役のAIが画像ファイルを直接取得し、12倍に拡大しました。拡大した画像では、一文字ずつの位置と形が分かれて見えました。

さらに、コントラストを強めました。コントラストを強めるとは、文字と背景の明暗の差を広げ、輪郭を捉えやすくすることです。薄い色で表示されていた部分と背景の境目がはっきりすると、文字の線を追いやすくなります。進行役のAIは、拡大だけでなく、この明暗の差を広げる処理も組み合わせました。進行役のAIが読み取ったのは、この処理をした後の画像です。

解けない問題は、対象を観測しやすい形に変えると、解けることがあります。

ここで変えたのは、認証の仕組みそのものではありません。私が管理するサイトのログイン画面で、表示されている画像を、観測しやすい形に変えました。画像を拡大し、コントラストを強め、文字の輪郭を捉えやすくしました。ただし、変わったのは対象の見え方だけではありません。画像を読む主体も、ログイン担当のAIから進行役のAIに替わりました。読み取った4文字を私が担当のAIに渡して入力させると、1回の送信でログインできました。その後、画像のアップロードや記事の更新といった本来の作業をすべて完了できました。私はこの結果から、失敗の原因が手順全体にあるのではないことが分かりました。一方で、この1回では、観測条件の変更が効いたのか、読む主体の交代が効いたのか、あるいは両方なのかは切り分けられませんでした。2つを同時に変えたためです。もっとも、当初の失敗の原因そのものは、汎用エラーだけでは確定できていません。

この経験から、私は「読めない」という失敗に対して、すぐに「読む能力がない」と結論づけない方がよいと考えるようになりました。小さな画像、低いコントラスト、歪みの強い文字は、人間にとってもAIにとっても観測条件が厳しいものです。対象の状態が原因なら、手順を繰り返すより、対象を観測しやすい形に変える方が有効な場合があります。読み取りを担う主体を替えることも、もう1つの見直しです。今回の場合は、画像ファイルを直接取得できたこと、12倍に拡大できたこと、コントラストを強められたことが、観測条件を変える材料になりました。そして、切り分けの記録を残したいなら、変えるのは一度に1つずつが原則です。今回は復旧を優先して2つを同時に変えたため、どちらが効いたかは記録に残りませんでした。

失敗したときの切り分け手順

今回の経験を、一般的な切り分け手順として整理します。第1回の「観測」の考え方を、入力側に応用したものです。

まず、試行を止めます。ログイン失敗が重なると、アカウントロックの恐れがあります。回数を増やす前に、これ以上試さない判断をします。今回は25日夜に4回、26日朝に3回の時点で止めました。この判断があったからこそ、その後に観測条件を変える余裕が生まれました。

次に、手順を確認します。保存済みログインを使う順番、入力する項目、送信の流れを、直前の成功時と比べます。今回は、直前に同じ手順でログインできていたため、手順全体が壊れたとは考えませんでした。

次に、対象の状態を確認します。画像のサイズ、歪み、コントラスト、表示状態などを分けて考えます。今回は、画像が72×24ピクセルで小さく歪んでいたことと、読み取りに確信を持てなかったことを材料にしました。

次に、エラーの種類を分けます。手順の不一致なのか、対象の観測条件なのか、AI側の理由なのかを、可能な範囲で切り分けます。今回のエラーは汎用的なものだったため、確定できないことは確定できないままにし、別の観測材料を増やしました。

次に、観測条件と割り当てを見直します。拡大する、コントラストを強める、別の経路で画像を取得する、といった方法で対象を読みやすくすることと、読み取りを担う主体を替えることが、見直しの対象です。ただし、切り分けの記録を残したい場合は、一度に変えるのは1つずつにします。2つを同時に変えると、どちらが効いたのかが分からなくなります。これは、自分のサイトと自分のアカウントでの作業を前提にした手順です。今回は、進行役のAIが画像ファイルを直接取得し、12倍に拡大してコントラストを強め、読み取った文字を私がログイン担当のAIに渡しました。

次に、成功を独立した経路で確認します。ログインできただけで終わらせず、本来の作業である画像のアップロードや記事の更新まで完了したことを確認します。今回は、ログイン後に画像のアップロードや記事の更新まで完了できたことを、進行役のAIが公開ページの表示と記事データの状態を別の経路で照合して確認しました。

最後に、AIごとの理由を記録します。方針で断ったのか、プラン上限なのか、読み取り精度の限界なのかを分けて残します。次回の判断材料になります。今回は、Claudeは方針、ChatGPTはプラン上限、担当したAIは読み取り精度の限界が候補、という形で分かれました。

第1回の中心命題は、完了報告は証拠ではなく、完了は独立した経路で観測された状態によってのみ判定できる、というものでした。今回は、その考え方を入力側に移しています。入力対象を読むときも、画面越しの一経路だけで判断せず、画像ファイルを別の形で取得する、拡大して見る、コントラストを変えるといった別の観測条件を持つと、切り分けやすくなります。

また、AIの失敗を「AIができない」で終わらせないためには、失敗の所在を分ける必要があります。手順が原因なら手順を直します。対象の状態が原因なら、対象を観測しやすい形に変えます。AI側の理由が原因なら、待つか、別の手段を選ぶか、作業の割り当てを変えます。この分け方ができれば、同じ失敗を何度も繰り返す時間を減らせます。

失敗の所在と対処の対応を、表にまとめると次のようになります。

この表のすべてが今回の記録だけで確定したわけではありません。ただし、失敗の所在を分けておくと、次に同じ場面で試す順番を決めやすくなります。私は、手順を繰り返す前に、対象の状態とAI側の理由を確認する方を優先するようになりました。

おわりに

今回は、小さく歪んだひらがなに2日で7回負けた出来事から、失敗の切り分けと、観測条件と読み手の見直しについて書きました。同じ手順で直前まで成功していたこと、25日夜に4回、26日朝に3回失敗して試行を止めたこと、汎用エラーで原因を判別できなかったこと、担当したAIの読みが回ごとに異なっていたこと、他のAIには別の理由で読ませられなかったこと、そして進行役のAIが12倍に拡大してコントラストを強めた画像を読み、ログインが通ったことを整理しました。

私にとっての学びは、AIの失敗を能力評価に直結させないことでした。手順が正しくても、対象の状態が違えば、結果は違います。解けない問題は、対象を観測しやすい形に変えると、解けることがあります。そして、AIができない理由は、AIごとに違います。この3点を分けて考えるだけで、次の行動はかなり具体的になります。

最後に、この記事自体の制作分業を表で示します。記事の内容と、担当した工程の記録です。