ソフトウェアの弱点が続いた1週間、AI に任せたことと任せなかったこと

2026 年 10 月下旬の約 1 週間に、ソフトウェアの脆弱性（ソフトウェアの弱点）の知らせが立て続けに届きました。当方は個人事業主です。自分のサイトや、自分で運営しているサービスのサーバー（サービスを動かしているコンピューター）を、自分で管理しています。今回の対応は、AI のアシスタントと会話しながら進めました。結論を先に書きます。調べる・確かめる・作業する・記録することは AI に任せました。決めること、お金のかかること、最後の公開のボタン、パスワードの扱いは当方に残しました。この記事では、その中から 3 つの話と、線の引き方をご紹介します。

弱点を直すのを待たずに、弱点の元をなくした

はじまりは、PHP（Web サイトを動かすプログラムの言語）の緊急の弱点でした。外から好きな操作をされるおそれがある、重いものです。当方のサイトのブログ（WordPress で作っていました）が当てはまりました。修正版は、同じ日の夜に出る予定でした。

修正版が出るまで何もしなければ、そのあいだ入口が開いたままになります。会社に置き換えると、問い合わせフォームや会員ページが、修正を待つあいだ無防備になる状態です。少しのあいだなら大丈夫だろう、と考えたくなるところです。

AI は、まず影響する範囲を確かめました。そのうえで、ブログの部分だけを「メンテナンス中」の表示に切り替える仕組みを用意しました。トップページなど、ほかのページは表示を続けられます。

当方は、ブログを止めると決めました。さらに、修正版を当てて再開するのはやめました。ブログの仕組みごと作り替えることにしたのです。WordPress をやめて、データベースを持たない形にしました。データベースは、記事などを保存して、その都度ページを組み立てる仕組みです。新しい形では、できあがったページをそのまま見せます。置き場も移しました。

切り替えが終わると、WordPress も PHP もデータベースも使わなくなりました。それらの弱点の知らせが届いても、対応そのものが要りません。もちろん、弱点がゼロになったわけではありません。切り替えの直後にも、公開に使う道具が使っている部品に、重い弱点の修正が出ました。このときは AI が中身を確かめ、当方が取り込みました。

ここから言えるのは、「直す」のほかに「やめる」という選び方もある、ということです。使っている仕組みが大きいほど、直す先も増えます。直すか、やめるかを決めるのは人です。AI は、その判断に要る材料を速くそろえてくれました。

「更新した」と「直った」は別だった

翌日には、3 つの発表が重なりました。AI は 1 つずつ、当方が使っているものかを確かめました。1 つは、そもそも使っていない製品でした。もう 1 つは、すでに直った版を使っていました。古い版で動いていた補助のプログラムは、もう仕事がなかったので止めました。

残る 1 つは、通信をつなぐ道具の更新でした。この道具は、自動で更新される設定にしてあります。ところが AI が確かめると、ファイルは新しくなっていたのに、動いているプログラムは古いままでした。再起動されていなかったのです。スマートフォンの更新を入れたのに、再起動しないまま使い続けている状態に似ています。

これを放っておくと、「自動で更新しているから大丈夫」と思い込んだまま、古い弱点を抱え続けることになります。記録の上では更新済みなので、誰も気づきません。

再起動して直しました。止まったのは数秒でした。

更新を入れたあとに、本当に新しいものが動いているかを確かめる。この作業は地味で、つい省きがちです。AI は、こうした確かめを面倒がらずに一つずつ行います。直したあとの確認を AI に任せると、抜けが減ると感じました。

AI も間違える

一方で、AI は間違えもしました。

1 つめは、ブログの置き場を移したときのことです。古いページの住所（URL）に来た人を、新しい住所へ案内する設定が必要でした。AI は、この設定を「手元で確認済み」と報告しました。しかし実際には、日本語を含む住所の行が、正しくない行として読み飛ばされていました。このままだと、検索結果やほかのサイトから来た人が、行き止まりのページに着いてしまいます。お客さまが見ている実際のサイトを切り替える前に、もう一度確かめる場面を作っていたので、そこで見つかり、直せました。

2 つめは、引き継ぎの話です。AI との会話は、途中で切れることがあります。そのため、作業の記録と引き継ぎのメモを残し、次の AI がそれを読んで続けられるようにしています。ところが、メモを受け取ったという記録を、AI が 2 回続けて付け忘れました。そこで、作業の手順の最初に、その記録を付ける段取りを組み込みました。

ここから言えるのは、AI の「確認済み」をうのみにしない、ということです。大事な切り替えの前には、人が確かめる場面を用意しておきます。また、同じ失敗が繰り返されたら、「次は気をつけて」と頼むのではなく、手順そのものを変えます。これは人の仕事でも同じだと思います。

任せたこと、任せなかったこと

ほかにも、サイトへの機械的な不審なアクセスが急に増えたり、OS（サーバーの土台のソフトウェア）の更新があったりしました。どの場面でも、役割の分け方は同じでした。

AI に任せたこと	当方に残したこと
当てはまるかどうかを調べる	止める・作り替える・急がない、などの方針
直ったかを確かめる	お金がかかること
準備や作業の手を動かす	再起動など、実際のサイトに影響する操作の承認
すべてを記録に残す	最後の公開のボタン
	パスワードなどを作ること、権限を変えること
	公開してよいかどうか（この記事も、AI の下書きを当方が読んでから公開しています）

分けた理由は、AI の能力ではありません。責任を誰が負うかと、取り返しがつくかどうかです。

この線は、できるところは仕組みで引いています。AI は AI 専用のアカウントで作業します。AI の仕事は、変更を作業用の場所に置いて、当方に確認を頼むところまでです。お客さまが見ているサイトの元になる大事な場所には、AI は直接書き込めません。これは、使っているサービスの側の設定で止まっています。パスワードなどの秘密は AI に見せません。AI に渡す許可証は、必要なことだけができて、期限が切れるものにしています。さらに、AI が作った変更には、別の会社の AI が 2 つ、自動で意見を付けます。セカンドオピニオンのようなものです。

一方で、仕組みだけでは止めきれず、約束で守っているところもあります。そこは、約束が守られているかを、記録で確かめられるようにしています。仕組みで止められる範囲は、これからも広げていく予定です。

大事なのは、どこが仕組みで止まっていて、どこが約束にすぎないのかを、自分で把握しておくことです。会社で AI や外部の業者に作業を頼むときも、「何を任せて、何を自分で決めるか」を考えると思います。そこに、「それは仕組みで止まっているか、約束だけか」も加えて、一度書き出してみることをおすすめします。

まとめ

弱点への対応は「直す」だけではありません。使わない仕組みを「やめる」ことで、対応そのものを減らせます。どちらを選ぶかは人が決めます
「更新した」と「直った」は別です。直ったかを確かめる地味な作業は、AI に任せると抜けが減ります
AI も間違えます。「確認済み」をうのみにせず、大事な場面の前に人が確かめる場を作り、繰り返す失敗は手順で防ぎます