設定ファイル検証

機能

• package.json：JSON 構文、パッケージ名の規則（大文字と空白は npm が拒否）、バージョンの形式、依存のバージョン範囲、license / description / repository の欠落
• `.env`：キーの重複（現れる行をすべて列挙 —— 3 回書けば 3 行）、キー名のドットとハイフン、空の値、値についた余分な引用符
• ⚠️ `.env` のキー名の大文字・小文字：すべて大文字でない名前は提案のみ。一方「大文字・小文字だけが違う 2 つのキー」（DATABASE_URL と database_url）は警告に上げ、Windows では互いを上書きし、Linux / macOS では独立した 2 変数になるというプラットフォーム差を説明します
• robots.txt：`Disallow: /` によるサイト全体の遮断、逆向きの意味になる空の `Disallow:`、絶対 URL でない Sitemap、`User-agent` の欠落
• ⚠️ robots.txt はパスへのアクセスを試せます：パスと複数のクローラー名（1 行に 1 つ、カンマ区切りも可）を入れると、それぞれについて「許可／拒否」を判定し、一致した規則とその理由を示します（最も具体的なグループが優先、同グループ内は最長一致、同長なら Allow、`*` と `$` に対応）
• sitemap.xml：名前空間の宣言、絶対 URL でない `<loc>`、重複した URL、5 万件・50 MB の上限
• ⚠️ sitemap は2 種類のルート要素に対応：`<urlset>`（ページを列挙）と `<sitemapindex>`（他のサイトマップを列挙）。ルートと子要素の取り違え（インデックスに `<url>`、またはその逆）はクローラーが 1 件も読めなくなるため、別項目として報告します
• ⚠️ `.env` は参照されていないキーを探せます：読む側のコードを貼り付けると、一度も現れないキーを一覧します。これはテキスト検索です（単語境界で照合するので、`DATABASE_PORT` があっても `PORT` が使用済みとは判定しません）：`process.env.X`、`process.env['X']`、分割代入 `const { X } = process.env` は検出できますが、動的な読み方（`process.env[name]`、連結したキー名）は検出できません —— したがって一覧に出たからといって不要とは限らず、出なかったからといって使用中とも限りません
• HTTP ヘッダー：廃止された X-XSS-Protection / Expect-CT / HPKP と、欠けている CSP・HSTS・nosniff など
• ⚠️ 結論はエラー（壊れる）/ 警告（動くが意図と違う可能性）/ 提案（改善できる）の 3 段階で、この順に並びます
• ⚠️ `Access-Control-Allow-Origin: *` と `Allow-Credentials: true` の併用はブラウザーが拒否する組み合わせで、エラーとして報告します
• ⚠️ 各項目が理由を説明します —— 「規約違反」ではなく、直さないと何が起きるかを書きます
• 貼り付けた内容の種別を自動判定し、手動でも指定できます
• すべてブラウザー内で完結し、送信も保存も行いません

使い方

1. 設定内容を貼り付けます。種別は自動判定されます
2. 判定が違う場合はオプションで指定します
3. エラー → 警告 → 提案の順に確認します。各項目に理由が付きます

よくある質問

なぜ合否の 2 値ではなく 3 段階なのですか？

合否だけでは、赤い印の山を前にしてどれから直すべきか分からず、結局すべて無視されるからです —— それこそが検証ツールが役に立たなくなる瞬間です。3 段階にすると、「エラー」はファイルが拒否されるもの（JSON の構文エラー、絶対 URL でない `<loc>`、あの CORS の組み合わせ、同じキーを 2 回書いたもの）、「警告」は動くが意図と違う可能性が高いもの（`Disallow: /` による全遮断、大文字・小文字だけが違う 2 つのキー）、「提案」は動作に影響しない改善（license、セキュリティヘッダー、すべて大文字でないキー名）です。この順に並ぶので、最初に手を付ける場所が一目で分かります。

空の `Disallow:` も問題なのですか？

空の値とスラッシュは 1 文字しか違いませんが、意味は正反対です：`Disallow:` は何も禁止しない、`Disallow: /` はサイト全体を禁止します。robots.txt で最も書き間違えやすい箇所であり、しかもどちらに転んでも無言です —— 片方では検索エンジンが静かに来なくなり、もう片方ではステージング用の記述を消し忘れて公開後に自然流入がゼロになります。

環境変数のキー重複がエラー扱いなのはなぜですか？

多くのローダー（dotenv、Docker、systemd）が後の値を採用する一方、2 回書くのは普通その値を効かせたいからです。つまり編集したほうが無視されており、しかも調査中は見えません：ファイルには望む値がはっきり書いてあるのに、プログラムは別の値を読みます。実際の障害の上位に入る原因なので、エラーとして報告し、そのキーが現れる行をすべて列挙します（3 回書けば 3 行）。「重複している」だけでは足りず、どの記述を消すべきかが分かる必要があるからです。

DATABASE_URL と database_url は別のキーなのに、なぜ指摘されるのですか？

Windows では別のキーではないからです。Windows は環境変数名の大文字・小文字を区別しないため、大小文字だけが違う 2 つのキーは互いを上書きします（どちらが有効かは読み込み順によります）。一方 Linux / macOS ではそれぞれ独立した変数です。つまり同じ `.env` が環境によって動作が変わり —— 手元の Mac では正しくても Windows の CI では別の値を読みます —— これが最も追いにくい不具合のひとつです。そこで独立した警告とし、両方のキーとそれぞれの行番号を示します。「名前がすべて大文字でない」（単独ならどちらの環境でも動くので提案のみ）とは別項目にしています。

「参照されていないキー」は見落としたり過剰に指摘したりしませんか？

どちらも起こります。これは構文解析ではなくテキスト検索だからです。`process.env.X`、`process.env['X']`、分割代入 `const { X } = process.env` は検出できます（キー名がテキストとして現れるため）が、`process.env[name]` のような動的な読み方や連結したキー名は検出できず、そのキーは「参照されていない」として一覧されます（過剰な指摘）。逆に、キー名がコメントや無関係な文字列に現れると使用済みと見なされます（見落とし）。したがって「出ていない」は削除してよい根拠にならず、「出た」も不要とは限りません。手掛かりとして扱い、削除前にリポジトリ全体を検索してください。

依存のバージョン範囲の判定が緩いのはなぜですか？

`dependencies` の値には `workspace:*`、`file:../x`、git URL、`npm:` エイリアス、あるいは `>=1.0.0 <2.0.0` のように空白で並べた比較子も書けるからです。文法を完全に判定するには semver ライブラリが必要ですが、ここでの目的は意味の検証ではなく明らかな書き間違い（空文字列、`^abc`、`1.0.0.0`）を止めることです —— どの指摘も利用者に設定を直させるものなので、誤検出はこのツールの信頼を失わせます。

秘密鍵なども読み取られますか？

いいえ。すべてブラウザー内で完結し、送信も保存もしません。さらに構文と構造しか見ません：`API_KEY=` の後ろの値が何であれ、キー名が妥当か、キーが重複していないかとは無関係なので、値の中身は一切判定に使われません。