セキュリティチェックをするなら

公開する前の Web アプリに弱点が残っていないか、自社のサイトの設定に抜けがないかは、AI に点検を頼めます。この記事では、わざと弱点を入れた見本の Web アプリと、当メディアのサイト(media.yobitsugi.ai)を、YOBITSUGI AI に実際に点検してもらいました(2026 年 10 月時点)。見本アプリの点検と修正は約 5 分で、コードの弱点 16 件と、依存ライブラリの既知の脆弱性 16 件が見つかりました。見本づくりやサイトの確認を合わせた費用は、約 318 クレジットです。

点検の対象は、自分が管理しているサイトと、自分で用意したコードだけにします。他人のサイトやサービスを、許可なく調べてはいけません。

向いている AI・道具

YOBITSUGI AI では、Claude(メインのエージェント)が、セッションごとのワークスペースの中でコマンドを動かしながら作業します。コードを読むだけでなく、アプリを動かして、直ったかどうかまで確かめられます。今回使われたものは次のとおりです。

Anthropic は Claude Opus 5.5 について、大きなコードベースでの機能の追加・デバッグ・リファクタリング・コードレビューといった長い作業を扱えると説明しています。

頼み方の例

コードの点検を頼む

コードを zip にまとめて添付し、次のように頼みます。今回、実際に送った依頼文です。

添付の vuln-sample.zip は、公開する前の Web アプリ(Node.js・Express・SQLite)です。セキュリティの点検をお願いします。

1. コードを読んで、弱点を探してください。見つけたものは、重大な順に表にまとめてください(場所・何が起きるか・直し方)
2. 依存ライブラリに、知られている脆弱性がないか調べてください
3. 見つけた弱点を直してください。直す前のコードは残したいので、直したものは vuln-sample-fixed という別のフォルダに作ってください
4. 直したあと、同じ弱点が残っていないかと、アプリがふつうに動くことを確かめてください
5. 最後に、点検の結果を report.md にまとめて、vuln-sample-fixed と一緒にファイル置き場に保存してください(見つけた弱点・直した内容・確かめた方法・直せなかったことや、人が判断したほうがよいこと)

確かめるのはワークスペースの中だけにして、外には公開しないでください。

ポイントは 2 つです。

• 直して確かめる所まで頼む: 「同じ弱点が残っていないか」まで書くと、AI は確認用のスクリプトを作り、直す前と直したあとの両方で動かして結果を残します。
• 「人が判断したほうがよいこと」を書いてもらう: AI が直さなかった点や、運用の決めごとが要る点が、報告に分けて書かれます。

自社のサイトの設定の確認を頼む

当社が運営しているサイト https://media.yobitsugi.ai/ の、公開されている設定を確認してください。

• トップページを 1 回だけ取得して、応答ヘッダーと、そのときの HTTPS の接続(TLS のバージョン・証明書の有効期限)を見てください。ふつうにブラウザで開くのと同じ程度にとどめ、何度もアクセスしたり、ほかの URL を探したりしないでください
• セキュリティに関わる応答ヘッダーを、設定されているもの・設定されていないものに分けて表にしてください
• 足したほうがよいものがあれば、優先度と、設定の例(nginx)を教えてください

結果は、サイトの担当者にそのまま渡せる短い報告にまとめてください。今日は日本時間で 2026 年 10 月 14 日です。

自分が管理しているサイトであることと、どこまで調べてよいかを、依頼文に書いておきます。

実際にやってみた

1. 見本の Web アプリを用意する

点検の対象として、ログイン・商品の検索・コメントの 3 画面がある小さな Web アプリを、YOBITSUGI AI に作ってもらいました。教材として、初心者が書きがちな弱点を 6〜8 個と、古い版の依存ライブラリを入れるよう頼み、1 分 37 秒でできました。

できたコードを読むと、弱点は 8 か所ありました。入力をそのまま SQL 文につないでいる所が 2 つ、入力をそのまま画面に出している所が 2 つ、パスワードをそのまま保存・セッションの秘密の値が固定・他人のコメントも消せる・エラーの詳しい内容が画面に出る、が 1 つずつです。

2. 別の会話で点検を頼む

見本を作った会話は弱点の場所を知っているので、点検は新しい会話で頼みました。

5 分 5 秒で、次の報告が届きました。

• コードの弱点は 16 件: 見本にあった 8 か所は、すべて指摘されました。ほかに、CSRF(別のサイトから、本人の知らないうちに操作をさせる攻撃)への対策がない・ログインの試行の回数に制限がない、などの 8 件が挙がりました。
• 依存ライブラリの既知の脆弱性は 8 パッケージ・16 件: express と ejs を新しい版に上げて、0 件になりました。受け取ったファイルで、手元でも npm audit を動かし、同じ件数になることを確かめています。
• 1 件は直さずに残した: セッションの保存先は、運用の形で選び方が変わるため、人が判断することとして報告に書かれていました。

直し方は、IPA の「安全なウェブサイトの作り方」が根本的解決として挙げている方法と同じで、SQL 文はすべてプレースホルダで組み立て、画面に出す値にはエスケープ処理をしていました。

3. 直ったかを確かめる

Claude は確認用のスクリプトを作り、33 項目を確かめていました。直した版は 33 項目すべてが OK で、同じスクリプトを直す前のアプリにかけると 22 項目が NG になります。受け取ったファイルを手元で動かしても、33 項目すべてが OK でした。

続けて、同じ会話で「直す前と直したあとの違いが分かる画面を、PC の幅で撮って見せてください」と頼むと、1 分 23 秒で 4 枚の画像が届きました。

4. 自社のサイトの設定を確かめる

新しい会話で当メディアのサイトの確認を頼むと、43 秒で報告が届きました。

• HTTPS の接続: TLS 1.3。証明書の期限は 2027 年 1 月 6 日
• 設定されていたヘッダー: Strict-Transport-Security・X-Content-Type-Options(同じヘッダーが 2 回出ている)・X-Frame-Options・Referrer-Policy・Permissions-Policy
• 設定されていなかったヘッダー: Content-Security-Policy(優先度は高)
• 気になる点: Server のヘッダーに nginx のバージョンまで出ている(優先度は中)

手元でもトップページを 1 回取得して、報告のとおりであることを確かめました。報告には nginx の設定の例も付いていて、Content-Security-Policy は、まず Content-Security-Policy-Report-Only で様子を見てから切り替える手順でした。MDN も、このヘッダーを、ポリシーを強制せずに違反を監視するためのものと説明しています。nginx のバージョンは、server_tokens の設定で出さないようにできます。当メディアでは、この指摘を受けて nginx のバージョンを出さないように直しました(2026 年 10 月 14 日)。

Claude は「接続は 1 回だけなので、TLS 1.0 と 1.1 が無効になっているかどうかは確かめていません」と、確かめていない範囲も書いていました。

うまくいかないとき

今回、実際に起きたことです。

• 見本づくりが、弱点の一覧を書く所で止まった: 見本を頼むとき、入れた弱点の一覧(答え合わせ)もファイルにまとめるよう頼みましたが、書き出すコマンドが失敗し、Claude は「この続きは書けないので、ここで作業を止めました」と報告しました。理由は画面からは分かりませんでした。コードはできていたので、一覧は頼まずにコードだけを受け取っています。今回の停止との関係は確かめられていませんが、Anthropic は、Claude Opus 5.5 にサイバーセキュリティなどの分野の安全対策を入れていると説明しています。

• AI が直したコードにも、気になる所が残る: 読み直すと 2 点ありました。直した版は、パスワードの保存に Node.js の scrypt を既定の設定(コスト 16384)で使っていましたが、OWASP の手引きは、コストを 2 の 17 乗(131072)以上にするよう勧めています。また、フォームの合言葉(CSRF トークン)に全角の文字を送ると、403 ではなく 500 のエラーになりました。投稿は断られるので弱点ではありませんが、33 項目の確認には入っていませんでした。
• アプリの画面で、表が記号のまま出ることがある: サイトの確認の報告では、一部の表が「| ヘッダー | 値 |」のような記号のまま表示されました。ファイル置き場に保存された報告では、表として読めました。
• 直すと、そのままでは動かなくなるものがある: 直した版はパスワードの照合の方法が変わるため、元のデータベースのままではログインできません。動いているアプリを直すときは、報告の「人が判断したほうがよいこと」を先に読みます。

YOBITSUGI AI でできること・できないこと

今回試した範囲で分かったことです。

• できたこと: 添付したコードの弱点を挙げる・依存ライブラリの既知の脆弱性を調べて更新する・直した版を作り、ワークスペースの中で動かして確かめる・公開されているサイトの応答ヘッダーと証明書を見る。
• この点検に含まれないこと: 本番のサーバーやネットワークの構成の点検と、専門家による侵入テストです(Claude の報告にも書かれていました)。IPA は「ウェブ健康診断仕様」について、検査パターンを絞り込んだ診断のため、脆弱性が検出されなくても安全宣言にはつながらないと説明しています。AI に頼む点検も、弱点が見つからなかったことが安全の証明にはなりません。
• 試していないこと: 大きなコード(今回の見本はファイル 12 個)・Node.js 以外の言語・ログインが要るページの確認。

料金の目安

YOBITSUGI AI は月額の費用がなく、使った分だけクレジットが減る仕組みです。モデルごとの金額は 料金とシミュレーション で確認できます。今回は、合わせて約 318 クレジットでした(2026 年 10 月時点)。

表は、アプリの画面に出た依頼ごとの値です。このほかに、依頼が終わってからワークスペースが自動で止まるまで(最後の依頼から 15 分)の分が、3 つの会話で合わせて約 9.5 クレジットかかりました。「見本を作る」には、できたアプリを zip にまとめる分を含みます。自分のコードを点検するときは、この分は要りません。

関連する記事

• Web サイトを作るなら
• Claude(Anthropic)とは: できることと使い方
• AI コーディングの道具を安全に使う(権限・秘密情報・学習の設定)(ハック！でAI)
• AIが脆弱性を見つける時代の更新運用 OSS・SBOM・OT対策の進め方(情シスのミカタ)
• AWS、コードセキュリティAIの評価公開、修正成功率の適用範囲を確認(情シスのミカタ)

出典

• Claude Opus(Anthropic・2026-10-14 確認)
• 安全なウェブサイトの作り方(IPA・2026-10-14 確認)
• 安全なウェブサイトの作り方 - 1.1 SQLインジェクション(IPA・2026-10-14 確認)
• 安全なウェブサイトの作り方 - 1.5 クロスサイト・スクリプティング(IPA・2026-10-14 確認)
• Password Storage - OWASP Cheat Sheet Series(OWASP・2026-10-14 確認)
• Crypto | Node.js v24 Documentation(Node.js・2026-10-14 確認)
• npm-audit | npm Docs(npm・2026-10-14 確認)
• Content-Security-Policy-Report-Only ヘッダー - HTTP | MDN(Mozilla・2026-10-14 確認)
• Module ngx_http_core_module(nginx・2026-10-14 確認)
• YOBITSUGI AI(呼継AI)(株式会社Game・2026-10-14 確認)
• 料金とシミュレーション | YOBITSUGI AI(呼継AI)(株式会社Game・2026-10-14 確認)