【実測】Claude Codeで作って公開したツール14個を全部点検した｜非エンジニアが見落とす穴は2種類だけだった

Claude Codeで作ったツールを、GitHub Pagesで無料公開しています。今日、その全部を点検しました。外部にデータが漏れていないか、勝手に通信していないか、入力欄から変なものが入らないか。

結果は「思っていたより無事だった。ただし2種類の穴があり、そのうち1つは運が良かっただけだった」でした。

この記事では、点検に使った6つの観点、実際に出た数字、直した内容、そして非エンジニアが自分の公開物に同じことをやるための手順を全部書きます。専門知識がなくてもできる3分の自己点検も最後に置きました。

きっかけは「非エンジニアが公開したアプリは危険か」という議論

2026年8月19日から20日にかけて、X上でこの話題が動いていました。発端はkubell（旧Chatwork）CEOの山本正喜さんの投稿です。

これに対して、コードを読めない人が作ったものを使う側のリスクを指摘する声もありました。

一方で「エンジニアが作れば安全という話でもない」という指摘もあり、議論は一方向ではありませんでした。

私はこの議論の当事者です。非エンジニアで、Claude Codeで作ったツールを14個公開しています。意見を書くより、自分の公開物を実際に測ったほうが早いと思いました。

何を点検したのか｜6つの観点

セキュリティの専門家ではないので、難しい理論ではなく「起きたら困ること」から逆算して観点を決めました。

1つ目は、入力した内容が外部に送られていないか。2つ目は、APIキーやトークンがファイルの中に埋まっていないか。3つ目は、入力した内容がブラウザに保存されていないか。4つ目は、外部から読み込んでいるプログラムに改ざん検知が付いているか。5つ目は、入力欄に打った文字がHTMLとして解釈されないか。6つ目は、そもそも自分が何を公開しているか把握できているか。

この6番目が、いちばん最初につまずいた場所でした。

関門は最初にあった｜何を公開しているか分かっていなかった

点検しようとして、手元のフォルダを開きました。ツールは12個。過去に書いたまとめ記事でも12個と数えていたので、それで合っていると思っていました。

ところが、公開先のリポジトリを取り込み直したら14個ありました。手元のコピーに2つ足りなかったのです。あとから追加したツールが、手元に降りてきていませんでした。

つまり「全部点検した」と言おうとした瞬間に、対象リストが2つ欠けていた状態です。しかも欠けていた1つは、あとで分かるとおり、いちばん判断が難しいツールでした。

公開物は増えます。増えたことを自分で覚えていられる量には限りがあります。点検の第一歩は、実際に公開されている場所を見て一覧を作り直すことでした。

結果1｜外部にデータを送っているツールはゼロだった

最初は文字列検索でスキャンしました。ただ、それでは判定できないと分かったので（理由は次の章に書きます）、最終的には全部のページをブラウザで実際に開いて、発生した通信を1件残らず記録する方法に切り替えました。

15ファイル（ツール14個と一覧ページ1個）を開いて、外部に出た通信は次のとおりです。

画像変換ツールが2件、マスキングツールが1件、PDF編集ツールが2件。合計3ツール・5リクエスト。それ以外の11ツールと一覧ページは、外部への通信が1件もありませんでした。

そして出ていった5件は、すべてプログラム（ライブラリ）を取りに行く通信でした。ユーザーが入力した内容を送るものは1件もありません。

APIキーやトークンの埋め込みもゼロ。入力内容をブラウザに保存する処理もゼロでした。

ここは正直、安心しました。作ったときに「入力は端末の中だけで完結させる」と決めていたのですが、決めたつもりで守れていない、ということがよくあるからです。

落とし穴｜自動スキャンの結果をそのまま信じると誤診する

最初にやった文字列検索では、まったく違う絵が見えていました。

いちばん危なく見えたのは、Artifact公開前チェッカーというツールです。外部通信を示すキーワードが3種類ヒットし、ブラウザ保存のキーワードもヒットし、外部から読み込むプログラムも3本引っかかりました。この時点では、14個のなかで最も要注意に見えていました。

ところが実際にブラウザで開いたら、外部への通信は1件もありませんでした。

理由は単純でした。このツールは「Artifactとして公開するHTMLが外部通信していないか検査する」ためのツールです。ヒットしたのは、検査に使う正規表現そのものと、画面に表示するサンプルコードの中の文字列でした。

// 検査ルールの定義（実際に通信しているわけではない）
re: /\bfetch\s*\(|XMLHttpRequest|new\s+WebSocket|navigator\.sendBeacon|EventSource\s*\(/,

// 画面に出すサンプルコードの一行
'    fetch("https://api.example.com/sales")',

文字列検索は「疑わしい場所」を教えてくれるだけで、「実際に何が起きるか」は教えてくれません。ここを取り違えると、安全なものを危険と判定し、逆に見落としも起きます。

これはAIに点検させたときにも同じことが起こります。指摘が出たら、まず「本当にその通りに動くのか」を自分の目で確かめる。この順番を飛ばすと、直さなくていいものを直して、直すべきものを見逃します。

穴①｜外から読むプログラム4本に、改ざん検知が1つも付いていなかった

外部通信が発生していた3ツールは、いずれも外部のCDNからJavaScriptのライブラリを読み込んでいました。画像変換のHEIC対応、ZIP圧縮、PDFの生成と表示に使っているものです。

問題は、この4本すべてに改ざん検知が付いていなかったことです。

改ざん検知（SRI）とは何か

SRI（Subresource Integrity）は、外部から読み込むファイルに「このファイルの中身はこれで合っているはず」という指紋を書いておく仕組みです。中身が1文字でも違えば、ブラウザが読み込みを拒否します。

付けていない状態は、配達された荷物の封印を確かめずに開けているのと同じです。荷物の中身が途中ですり替えられていても気づけません。

起きたら何が困るのか

CDN側が改ざんされた場合、私のページの中で他人の書いたコードが動きます。しかも今回該当した3ツールは、画像やPDFをユーザーが読み込ませるツールです。ブラウザの中だけで完結させているつもりでも、そのコード自体が入れ替わっていたら、中身を外に送られる余地が生まれます。

起きる確率は高くありません。ただ、起きたときの影響は大きく、そして対策はタグに1行足すだけです。やらない理由がありませんでした。

穴②｜名前欄に入れたタグが、そのままHTMLとして解釈されていた

相性診断メーカーの名前欄に、太字を意味するHTMLタグを打ち込んで診断してみました。結果画面には、太字になった文字が表示されました。

これは、入力した文字が「ただの文字」ではなく「画面の部品」として扱われている状態です。名前を入れる欄に入れたものが、そのままページの構造の一部になっています。

では乗っ取られたのか｜実際に試したら不発だった

気になったので、画像タグを使ってスクリプトを動かす形の文字列を3パターン入れてみました。

結果は、3パターンとも不発でした。画像の要素自体はページの中に作られましたが、スクリプトを起動する部分が壊れていて動きませんでした。

理由は、入力の後ろに続く元々のテンプレートの引用符と噛み合って、属性の名前が途中で切れていたためです。

つまり、運が良かっただけだった

これは設計で守れていたのではありません。たまたま噛み合わなかっただけです。テンプレートの書き方が少し違っていれば、素直に動いていた可能性があります。

自分1人で使うぶんには、実害は「自分の画面が崩れる」程度です。ただ、これらのツールは診断結果をシェアする使い方を想定して作っています。入力がそのまま画面の部品になる状態を放置する理由はありませんでした。

同じ問題は、写真を使うペット擬人化メーカーにもう1か所ありました。合計2か所です。

直した｜ビフォーアフター

1. 改ざん検知を4本すべてに付けた

各ライブラリの中身から指紋を計算して、タグに書き足しました。

<!-- Before -->
<script src="https://cdn.jsdelivr.net/npm/jszip@3.10.1/dist/jszip.min.js"></script>

<!-- After -->
<script src="https://cdn.jsdelivr.net/npm/jszip@3.10.1/dist/jszip.min.js"
        integrity="sha384-+mbV2IY1Zk/X1p/nWllGySJSUN8uMs+gUAN10Or95UBH0fpj6GfKgPmgC5EXieXG"
        crossorigin="anonymous"
        referrerpolicy="no-referrer"></script>

付けたあとに全ツールを開き直して、ライブラリが正常に読み込めているかを確認しました。4本とも問題なく読み込まれ、エラーは1件も出ませんでした。指紋を間違えると機能が丸ごと止まるので、ここの確認は必須です。

2. 入力をHTMLとして扱わないようにした

文字列を組み立ててから画面に流し込むのをやめ、部品を作ってから文字を入れる形に変えました。この書き方だと、入力に何が入っていても「文字」として扱われます。

// Before：入力がHTMLとして解釈される
pairEl.innerHTML = `${a} <span class="rel">${rel}</span> ${b}`;

// After：入力は文字として扱われる
pairEl.textContent = '';
const relEl = document.createElement('span');
relEl.className = 'rel';
relEl.textContent = rel;
pairEl.append(a + ' ', relEl, ' ' + b);

修正後、もう一度同じ太字タグを名前欄に入れてみました。今度は画面に「そのままの文字列」として表示され、ページの中に作られた余計な要素は0個になりました。

残った課題も書いておきます

PDF編集ツールが使っているPDF表示ライブラリは、本体とは別に補助ファイルを外部から読み込む作りになっています。この読み込みには、今回のやり方では改ざん検知を付けられません。ライブラリを手元に置く形に変えれば解決しますが、今日はそこまで手を入れていません。1本だけ課題が残っている状態です。

直したものを隠すつもりはないので、残ったものも書いておきます。

非エンジニアのための「公開前3分の自己点検」

専門知識がなくてもできる形に落としました。ブラウザだけで完結します。

Step 1｜何を公開しているか一覧にする

記憶ではなく、公開している場所を実際に開いて数えます。私はここで2個ずれていました。フォルダの中身ではなく、公開先を見るのがポイントです。

Step 2｜外部への通信を目で見る

Chromeで自分のページを開き、右クリックから「検証」を選び、Networkタブを開いてからページを再読み込みします。並んだ一覧のうち、自分のドメイン以外のものが外部との通信です。

ここに、自分が意図していない送信先が並んでいないかを見ます。ライブラリの取得なら通常はファイル名で分かります。もし入力したあとに新しい通信が増えるなら、それは入力内容が送られている可能性があります。

Step 3｜入力欄に太字タグを打ってみる

名前や文章を入れる欄に、太字を意味するHTMLタグで囲んだ短い文字列を入れて、結果を表示させます。太字になったらHTMLとして解釈されています。そのままの文字列で表示されたら問題ありません。

この1手で、今回見つけた穴②と同じ種類の問題が分かります。

Step 4｜外部から読んでいるものに指紋が付いているか見る

ページ上で右クリックして「ページのソースを表示」を選び、外部のURLを読み込んでいるタグを探します。そこにintegrityという記述があるかどうかを見ます。無ければ、改ざん検知が付いていません。

Claude Codeの安全な初期設定については、Claude Codeの安全な初期設定でも触れています。今回の話は「作ったあと」の点検ですが、「作る前」の設定も合わせて確認しておくと事故が減ります。

Claude Codeに点検させるプロンプト

自分で見るのが難しい部分は、Claude Codeに投げてしまうのが早いです。実際に使ったものを置いておきます。

このフォルダにある公開用のHTMLを全部点検してください。
判定は推測ではなく、必ず該当箇所の行番号と実際のコードを示してください。

観点は次の6つです。
1. 外部にデータを送信する処理があるか（fetch / XMLHttpRequest / WebSocket / sendBeacon）
2. APIキー・トークン・パスワードがファイル内に書かれていないか
3. localStorage / sessionStorage / Cookie に入力内容を保存していないか
4. 外部から読み込むスクリプトに integrity 属性が付いているか
5. ユーザーの入力を innerHTML に未エスケープで入れている箇所はないか
6. 上記のうち、正規表現の定義やサンプルコードの中の文字列にすぎないものは
   「検出したが実害なし」として区別してください

最後に、実際に直すべき箇所だけを優先度順に並べ、
それぞれの修正案をBefore/Afterで示してください。

最後の6番目が重要です。これを書かないと、検査ツールのようにキーワードを含むだけのファイルが赤く出ます。私は実際にそれで一度読み違えました。

そして、返ってきた指摘は必ず実測で裏を取ってください。ブラウザで開いて通信を見る、入力欄に文字を打ってみる。この2つで大半は判定できます。

それでも公開したほうがいいと思う理由

今回の点検で穴が2種類見つかりましたが、公開をやめようとは思いませんでした。公開しなければ使われず、使われなければ問題も見つからないからです。今回の点検も、議論を見たから動いただけで、閉じたまま持っていたら気づかないままでした。

ただし、公開してはいけないものはあります

個人情報を入力させるもの、お金や決済に関わるもの、社内のデータを貼り付けさせるもの、ログインさせるもの。この4つに当てはまるなら、公開の前に詳しい人のレビューを入れるべきだと思います。責任の重さが変わります。

逆に、ブラウザの中だけで完結して、入力が外に出ない作りなら、公開のハードルはかなり低くなります。今回の14個は全部そちらでした。

会社のデータを扱う場合の考え方については、Claude Codeは会社で使っていい？で別途まとめています。作ったものを配る手段の選び方は、Claude Artifactsの使い方のほうが詳しいです。

よくある質問

セキュリティの知識がなくても点検できますか

今回書いた4ステップは全部ブラウザだけでできます。専門知識が要るのは「見つかった問題をどう直すか」の部分で、そこはClaude Codeに投げれば具体的なコードが返ってきます。見つける側は、知識より手を動かす回数のほうが効きます。

AIに「安全ですか」と聞けば済みますか

済みません。今回、文字列検索で最も危険に見えたツールは、実際には外部通信が1件もありませんでした。逆に、危険そうに見えなかったツールに穴が2か所ありました。AIの指摘は出発点で、判定は実測です。

GitHub Pagesで公開するのは安全ですか

置き場所の安全性と、置いたものの安全性は別の話です。今回見つかった2つの穴は、どちらも置き場所ではなく中身の問題でした。冒頭の議論でも「Vercel自体が危険なわけではない」と言われていたのは、同じ構造だと思います。

社内で使うだけなら公開しなくていいのでは

社内向けほど、扱うデータが具体的になります。今回のような遊びのツールより慎重にすべきです。少なくとも、誰でもURLを知れば開ける状態にはしないほうがいいと思います。

まとめ

14個のツールを点検して分かったことを、数字で並べます。

外部にデータを送っているツールはゼロ。APIキーの埋め込みもゼロ。入力内容の保存もゼロ。実際に発生した外部通信は3ツール・5件で、すべてライブラリの取得でした。

見つかった穴は2種類。1つ目は、外部から読む4本に改ざん検知が付いていなかったこと。2つ目は、入力欄の文字がHTMLとして解釈される箇所が2か所あったことです。どちらも今日直して、直ったことを実際に確認しました。残った課題は1本です。

いちばんの学びは、技術的なことではありませんでした。1つ目は、点検の前に「何を公開しているか」を数え直すこと。手元の記憶は2個ずれていました。2つ目は、検索でヒットした結果をそのまま信じないこと。いちばん危なく見えたツールが、実際にはいちばん綺麗でした。

非エンジニアが作ったものが危ないかどうかは、作った人の肩書きでは決まりません。測ったかどうかで決まります。測るのは、思っていたより簡単でした。

AIの最新情報をリアルタイムで受け取りたい方へ

Xでは、Claude Codeの新機能や実際に試した結果を、記事にする前の段階から毎日投稿しています。今回のような点検の途中経過もそちらに流しています。よろしければフォローしてください。

とし｜Claude Code実践ノート（@ai_hack_dx）

あわせて読みたい関連記事：