社内ダッシュボードを自作して社員だけに見せる守り方｜難読URL・Basic認証・1人1端末の三重ガードを実測【2026年】

ダッシュボードを自作して社員に見せるとき、僕に必要だったのは「本人の端末でしか開かない」守りでした。僕の会社では、推測されにくいURL、Basic認証、1人1端末の登録を重ねた三重のガードで、社外秘の会社の状況を社員2名に見せています。

2026年8月30日に、主力メンバー2人向けの経営ダッシュボードのv1を公開しました。守りの層ごとに、返る応答が401・403・200のどれになるかを全パターンで実測し、2台目の端末が弾かれることも確かめています。

この記事では、三重にした理由、端末の登録の仕組み、実測の結果、毎月の更新の決まりを順に書きます。「社員に会社の数字を見せたいけれど、URLが外に漏れたらどうするの？」と迷っているあなたに向けた記録です。

ダッシュボードを自作して社員に見せるなら、守りは三重にした

社外秘のダッシュボードを自作して社員に見せるなら、1つの守りに頼らず、性質の違う3つを重ねるのが僕の答えです。URLを難しくする、パスワードをかける、端末を登録する、の3つです。

3つは、それぞれ破られ方が違います。URLはメールの転送で漏れます。パスワードは人に教えれば誰でも使えます。端末の登録は、その端末を持っている本人でないと通れません。

1枚目と2枚目は、入口に来る人を減らすための層です。最後の3枚目で、開ける人を「招待した本人の、最初に開いた1台」に絞り込みます。僕が一番効いていると考えているのは3枚目です。

僕の会社の経営ダッシュボード：社員2名に会社の状況を見せる

僕の会社の経営ダッシュボードは、主力メンバー2人に会社の状況を見せるための社外秘のページです。自社のサーバー（お名前.comのレンタルサーバー）に置き、検索には出さない設定にしています。

v1を公開したのは2026年8月30日です。載せる範囲は、僕が「2人とも主幹メンバーなので全て見えてよい」と決め、損益の詳細や貸借の要約、融資の動きまで出しました。その代わり、ログインは1人1端末だけにすると決めています。

全部を見せると決めても、載せないものは決めました。個人別の給与（合算だけを出す）、会社の数字ではないもの、口座ごとの残高の3つです。口座ごとの残高を外したのは、リアルタイムではないので誤解を生むと考えたからです。

作業は、僕が指示を出してAI（Claude）に進めさせました。画面の作り込みから、サーバーへの配置、応答の確認までを任せ、僕は載せる範囲と守り方を決める側に回っています。

v3で見た目を刷新した：黄色はいちばん上の1枚だけ

2026年9月1日にはv3を出し、見た目を作り直しました。僕の指示は「もっとビジュアライズして、見てて楽しく。ロゴを入れて、黄色ベースに」でした。

テーマは「裏側を照らす」にしました。地は暗いインクの色で、会社の色の黄色は最上部のスコアボード1枚だけに集めています。黄色の面積は画面の12〜18%に収めました。白地に黄色のコーポレートサイトと、暗いダッシュボードをつなぐためです。

構成はスコアボードと15のセクションです。ロゴの「キラッ」とした3本線をCSSで描き直し、15セクションすべての見出しの目印にしました。横にスクロールできる目次を付け、今どのセクションを読んでいるかが分かるようにしています。

ゲージには、割合だけでなく実数と満点を並べて書いています。%だけを見せない決まりです。動きを減らす設定の端末では動きを止め、印刷したときは全要素を表示する作りにしました。

1枚目と2枚目：難読URLとBasic認証は「入口」を絞るだけ

難読URLとBasic認証は、どちらも入口に来る人を絞る守りです。2つだけでは、URLとパスワードを知った人なら誰の端末でも開けてしまいます。だから僕は、この2枚を「最後の守り」として扱っていません。

難読URLは、推測されにくい文字列をフォルダ名にしただけです。リンクが転送されれば、そのまま相手の手に渡ります。

検索に出さないためのnoindexも入れました。ただGoogleの説明では、noindexは検索結果から外すための指示です。ページを開けなくする仕組みではないので、守りの層には数えていません。

検索に載らないことと見られないことの違いは、Claudeの共有リンク・公開Artifactが検索に出る時の対処でも書きました。社外秘のものは、URLを知られても開けない形にしておく必要があります。

Basic認証は、ブラウザがIDとパスワードを聞いてくるWebサーバーの仕組みです。ApacheではAuthType Basicと書き、AuthUserFileでパスワードのファイルの場所を指定します。

# 一般化した例（実際の場所・名前ではありません）
AuthType Basic
AuthName "Restricted"
AuthUserFile "<サーバー上のパスワードファイルの絶対パス>"
Require valid-user

Apacheの公式文書は、Basic認証はパスワードを暗号化せずに送るので、通信の暗号化と組み合わせるよう勧めています。パスワードのファイルはWebから見えない場所に置くように、とも書いています。

僕のダッシュボードは、HTTPSで開く形にしています。

お名前.comのレンタルサーバーでは、設定ファイルに書いたある命令が500エラーの原因になりました。そのためnoindexは、ページの中のmetaタグで入れています。サーバーごとの癖は、公開前に1つずつ応答を見て確かめるしかありません。

AuthUserFileのパスの書き方で500になった件は、Basic認証を.htaccessで掛けたら500エラーになる原因に分けて書きました。

3枚目：招待リンクで1人1端末に結びつける端末の登録

3枚目の守りは、招待リンクを最初に開いた端末にだけ、閲覧の許可を結びつける仕組みです。Basic認証の内側にPHPで作りました。社員2名は1人1端末、代表の僕は9端末までと上限を決めています。

流れは次のとおりです。

1. 僕が本人ごとの招待リンクを1回だけ渡す
2. 本人がそのリンクを端末で開くと、サーバーがその端末にCookieでトークンを発行する（有効期限は1年）
3. サーバーはトークンを、サーバー上の登録の記録用のファイルに書き込む
4. 次からは、Cookieのトークンが記録と合う端末だけがページを開ける
5. 上限に達した人が別の端末で招待リンクを開くと、403で「登録済み」と返す

ここでいうCookieとは、サーバーがブラウザに預けておき、次に開いたときに送り返してもらう小さなデータです。MDNの説明では、Max-Ageで有効期限を秒で決められ、HttpOnlyを付けるとページのスクリプトから読めなくなります。

コードの形を一般化すると、次のようになります。実物の招待キーや記録の場所はここには書かず、仕組みだけを示す例です。

// 一般化した例（実物ではありません）
$invite = $_GET['invite'] ?? '';       // <招待キー>
$token  = $_COOKIE['device'] ?? '';    // 端末に預けたトークン
// 1. Cookieのトークンが記録にあれば表示
// 2. 招待キーが正しく、その人の登録数が上限未満なら
//    新しいトークンを発行して記録し、Cookieで渡す
// 3. どちらでもなければ 403 を返す

登録の記録のファイルは、ブラウザから直接開くと403になるようにしてあります。実測でも、記録のファイルへの直接のアクセスは403で止まりました。

社員が機種変更したときは、記録のファイルからその人の行を消してサーバーに置き直します。そのうえで招待リンクを新しい端末で開き直してもらえば、新しい端末が登録されます。

401・403・200を全パターン実測した結果

三重のガードは、層ごとに返る応答を全パターンで実測してから社員に渡しました。僕の会社の運用記録では、認証なしは401、Basic認証だけは403、登録した端末は200で、2台目の拒否とリセット後の再登録まで確かめています。

MDNの説明では、401は有効な認証情報が無いときの応答で、403はサーバーが要求を理解したうえで断るときの応答です。僕の作りでは、Basic認証で止まれば401、その内側の端末の登録で止まれば403です。

2026年9月1日のv3の公開でも、401・403・200の3層と、記録のファイルの403を測り直しました。同じ日に、画面幅375pxと800pxで横スクロールが0pxになることも確かめています。

僕がこの表で一番大事だと思っているのは、2台目が403になる行です。パスワードが漏れても、招待リンクが転送されても、最初の1台以外では開けないことが、ここで確かめられます。

社内ダッシュボードの守り方を比べると、端末の登録だけが「人」に結びつく

社内ダッシュボードの守り方を比べると、URLとパスワードは「知っている人」を通し、端末の登録だけが「持っている本人」を通します。社外秘の数字を載せるなら、僕は端末の登録まで入れます。

比べるのは、自作のページでよく使う4つの守り方と、Claudeのアーティファクトの組織内共有です。アーティファクトの行は公式文書に書かれた仕組みで、僕の会社でこの用途に試したものではありません。

Claude Codeの公式文書では、アーティファクトはバックエンドの無い1枚のページで、閲覧者を自分で認証できないと書かれています。チームのプランでは、組織のメンバーとしてサインインした人に見せる形になります。

アーティファクトで社内ツールを作って配るやり方は、Claudeアーティファクトで社内ツールを作る方法と共有のしかたに書きました。僕の会社では、出稿の手順書はアーティファクト、経営のダッシュボードは自社のサーバーと使い分けています。

自社のサーバーに置くと、閲覧者ごとの表示と1人1端末の制限を、自分たちのプログラムで決められます。代わりに、サーバー側の作りと確認は自分たちの責任になります。

自作したダッシュボードを毎月19日に更新し続ける決まり

自作のダッシュボードは、作った日より、毎月正しく更新し続けることの方が手間です。僕の会社では、毎月19日に自動で更新する定期の作業を組み、月次決算の試算表が固まった翌日に数字を入れ替えています。

v3から、毎月触る場所は6か所だけに絞りました。最終更新の日付、スコアボード、今期の実績、進行中の案件、補助金と納税、警戒灯です。触る場所を決めておくと、更新のたびにページ全体を見直さずに済みます。

PHPで動かしているところもあります。1つは、見ている人に合わせて担当の名前（運用・制作・事業）を出す表示です。もう1つは補助金の締切までの残り日数で、開くたびに計算するので、更新を忘れても数字が古くなりません。

数字の決まりで一番大事にしているのは、集計中の月を推測の値で埋めないことです。確定前の月は「集計中」「請求ベース速報」「確認中」と書き、空いていることをそのまま見せます。

更新の後は、毎回応答を確かめます。認証なしの401、Basic認証だけの403、記録のファイルの403の3つです。

200まで見るときは、代表の招待キーで一時的に登録し、確認が終わったら記録からその行を消して戻します。9端末の上限を確認作業で減らさないためです。

登録の記録のファイルは、更新のときに上書きしない決まりにしています。ページのファイルだけを置き直し、端末を足したり消したりするときだけ、記録を読み込んで直して書き戻します。

まとめ

• 社外秘のダッシュボードを自作して社員に見せるなら、難読URL・Basic認証・端末の登録の3つを重ねる。破られ方がそれぞれ違うので、1つが漏れても残りで止まる
• noindexは検索に出さないための指示で、ページを開けなくする仕組みではない。守りの層には数えない
• 端末の登録は、招待リンクを最初に開いた端末にCookieでトークンを渡し、記録と照らす仕組み。2台目は403で止まり、機種変更は記録の行を消して開き直してもらう
• 公開の前に、401・403・200が層ごとに返るかを全パターンで実測する。2台目の拒否とリセット後の再登録まで確かめる
• 僕なら最初に「誰に、何台まで見せるか」と「載せないもの」を決めてから作り始めます