脆弱性が、毎週のように見つかる
AIの進化で、脆弱性は特定のサイトやプログラミング言語だけの話ではなくなりました。OSのシステムまで含めて、見つかる速度が上がっています。2026年6月のMicrosoftの月例更新は、過去最多の206件の脆弱性を修正しました（ *Dark Reading ）。米国の脆弱性データベースには、1月から7月27日までに4万5千件を超える登録があり（ *Bloomberg集計、Let's Data Science ）、年間では6万6千件前後になるという予測も出ています（ *Help Net Security ）。6月にAIモデルのFableが公開された時期を境に、この流れが止まる気配はなく（ *Box ）、ITが関わるシステムはどこも更新と対策に追われています。
ただし、脆弱性の数が増えたことと、被害が同じ割合で増えたことは別と見ています。実際に悪用されている数は、同じ勢いでは増えていないという報告もあります（*FIRST中間更新の指摘）。もちろん、セキュリティ対応、テスト、頻繁な検査は前提として日常的に行っています。破られてもよいと考えているわけではありません。そのうえで、弊社が選んだのは、守りを突破されることもあるという前提でのサービス作りです。守り切れると言い切るのではなく、守り切れなかったときに何が起きて、どう気づくか。そこまで設計しています。
専門家は、なぜ記事にコメントを付けるのか
現状のサービスサイトでは、なぜ専門家が記事にコメントを入れるのか。AIが文章を書くようになって、記事は増えました。読みやすく、もっともらしい文章も増えましたが、読みやすいことと正しいことは別です。そこで、その分野を知っている人が、気になった段落に一言添えます。ここは正しい、ここは言い切りすぎ、ここは前提が抜けている、といった具合です。記事全体への評価ではなく、特定の段落に付くところが大事で、読者は専門家がどの文を見て何と言ったかを、記事を読みながら確かめられます。専門家のメリットですが、専門分野について誤った説明が広まるのは見過ごしにくく、記事の該当箇所に意見を残せば、その記事を読む人に直接届きます。
弊社は、この記事へのコメントを載せる仕組みを作っています。ただ、コメントの価値は、専門家が見た記事と、読者が読む記事が同じであることに支えられています。そこが崩れると、仕組みごと信用を失います。だから、守るものは次の三つを基礎としています。
- コメントそのもの。専門家が書いた内容が、書いたとおりに残っていること。
- 記事とコメントの対応。コメントが、専門家の見た段落に付いていること。
- 記事と仕組みをつなぐ通信。やり取りされる内容が、本物であること。
想定している攻撃は大きく四つあります。承認後の本文の書き換え、見えている言葉はそのままで行き先だけを変えるリンクの差し替え、見る人や見る側によって中身を出し分ける表示、そして、確認している場所と読者が開いているページが別になることです。以降の三つの節で、これらへの考え方を順に書きます。
コメントは公開状態に
専門家のコメントは、画面上であとから差し込まれる飾りにはしません。公開された記事の一部として、読者が読めて、検索エンジンや外部のツールからも読める形で出します。記事を表示する時点でコメントを入れておく作りにしているので、JavaScriptが動かない環境でも読めますし、検索エンジンのクローラーにも見えます。検索順位が上がるとお約束するものではありませんが、記事とコメントを検索の側からも一緒に読んでもらえる土台になります。
公開のメリットは、見える場所にあるものは、誰でも見比べられることです。コメントが書き換えられたり、消されたり、偽物が混ざったりしたとき、公開されていれば第三者も気づけます。
その前提として、守りを突破されることがある以上、「機密情報はそもそも置かない」というのが鉄則です。公開して困らないものだけを公開側に置き、困るものは最初から載せません。公開すれば攻撃者も同じ画面を見ているので、これだけで安全にはなりません。だから次の仕組みが必要になります。
書き換えは止められない。だから気づく
記事の書き換えを、完全に止められるとは考えていません。媒体のCMSに脆弱性が見つかり、攻撃者が管理者の鍵を手に入れれば、本文は変わります。2026年にも実例があります。ブログ用CMSのGhostで、SQLインジェクションの脆弱性が使われました。2月に修正版が出ていたものの、多くのサイトで更新が間に合わず、5月までに700を超えるサイトが書き換えられています（ *QiAnXin XLab ）。投稿の末尾に不正なスクリプトが足され、訪問者の環境を見て、転送するか偽の確認画面を出すかを選んでいました。検査ツールから隠れるために、見る人によって表示が変わる作りでした。
承認が済んだ記事も、同じ立場にあります。専門家が見たあとで本文が入れ替わっても、承認の記録は残ります。見ていない文に、専門家の信用が付いてしまいます。しかも専門家はコメントを書く人であって、記事を見張る人ではありません。媒体の側も、書き換えに気づくまでに時間がかかることがあります。
そこで、コメントを入れる専門家と媒体だけでなく、第三者として弊社の仕組みが、登録された記事を一緒に巡回する作りにしています。公開された記事を定期的に取り直して、前回との違いを見ます。見るのは、タイトル、見出し、本文、段落の順序、リンクの文字と行き先です。変わっていれば、運用の担当者が変更箇所と、そこに付いているコメントを並べて確認します。コメントが指していた説明が変わっていれば、コメントの掲載を止める判断ができますし、変更箇所を示して媒体の担当者に伝えることもできます。専門家のコメントを守ることと、媒体に書き換えに気づいてもらうことを、同じ確認でつなぎます。変更のすべてが攻撃というわけではありません。正当な改稿も多く、内容の違いだけでは改稿と改ざんは区別できないため、区別するのは人です。記事が取れなかったときも、変更なしとは扱わず、確認できていない状態として残します。大事なのは、見つけたあとにすぐ動けることです。コメントを止めるか、元に戻してもらうか、改稿を受け入れて基準を取り直すか。早く気づければ、見ていない文に信用が付いている時間を短くできます。
通信は常に疑う姿勢
媒体サイトと弊社の仕組みの間では、記事とコメントの情報がやり取りされます。ここが偽装されると、確認している内容そのものが怪しくなります。そもそも、いま確認している内容が本物なのか、というところから疑うのが出発点です。具体的な方式はここでは割愛しますが、考え方はいくつかあります。
まず、媒体側が行うのは、公開されているコメントを取得することだけです。書き込みの権限も、管理用の認証情報も、媒体には渡しません。接続先は管理者が決めた一か所に固定し、訪問者の入力で変わることはありません。取得するときは時間とサイズに上限を設け、転送にはついていきません。返ってきた中身が想定した形かを確かめ、違っていれば表示せず、記事本文は元のまま守ります。取れなかったことを問題なしとは扱わず、古い結果で代わりに表示することもしません。
弊社の側から媒体へ更新を知らせる場合は、署名をつけ、中身は記事のIDなど最小限にする作りを用意しています。通知を受けた側は、通知の内容を信じるのではなく、現在の公開内容を取り直して確かめる作りにしています。また、同じアドレスでも、確認する側にだけ別のページを返すことは起こりえます。そのため、確認で取得した結果が読者の画面と同じだとは決めつけずに見ています。通信を守っても、媒体サイトそのものが破られれば、本文は変わってしまいます。だから通信の守りだけには頼らず、前の節の巡回と組み合わせて、通信と記事の両方から確かめるようにしています。
今できていることと、これから
セキュリティ対応、テスト、頻繁な検査を続けたうえで、弊社が気にしているのは、専門家が見た内容と、いま読者が見ている内容がずれることです。このずれを、最優先で向き合うべき課題と位置づけています。現在は、登録した記事を取り直して変更を見る機能を作り、検証を進めています。管理画面で、変更箇所と関連するコメントを並べて確認できます。コメントを記事の初期表示に入れて公開する作りと、媒体側が公開されたコメントを取得するだけの仕組みも用意しています。
これで記事やサイトが完全に安全になるわけではありません。書き換えは起こりえますし、巡回の間隔があるので、気づくまでの時間がゼロになることもありません。言えるのは、起きたときに気づいて、直せる側に立つために作っている、というところまでです。
脆弱性の発見は、これからも速くなります。更新が追いつかない場所も残ります。守りが破られる前提で、何を守り、何を公開し、どう気づくか。弊社の対応は、時代の流れに歯向かうのではなく、変化し続けることを止めないことです。