微妙に補足説明を追加してます。

---

で、「リンクの拒否権」（http://mylog.ishinao.net/id/1129）の最後に出てきた、「パブリックなWebページとプライベートなWebページを簡単に使い分けることができるインフラ」に関する考察を進めてきた結果、「ゲストブックとRURIコードによるアクセス制御」（http://mylog.ishinao.net/id/1096）と「記事ごとに読める人の人数を制限できる仕組み」（すみません。どこで読んだのか忘れてしまいました）を組み合わせた、現在の私が考えつく、もっともバランスのいい匿名のままに認証＆アクセス制御する仕組みについてまとめてみる。

まず、アクセスしてきた閲覧者（ブラウザ）にランダムなIDを振り、Cookieに登録する。次回アクセス以降、CookieにランダムIDが存在した場合はそのIDを利用し、存在しない場合にのみ新しいIDを割り振る。IDは重複することが（論理的に実用時間内には）なく、閲覧者（ブラウザ）を一意に認識するためのIDとして利用できる。+[また十分に複雑なランダム性を持つIDなので、他人のIDを類推することは不可能である。]+そのIDのことを、この考えの元ネタであるHNS（Hyper Nikki System）での呼び方に準じて、ここではRURIコードと呼ぶ。

RURIコードを使うことによって、閲覧者を匿名のままに区別して扱うことが可能になる。閲覧者にID、パスワードの管理や入力という手間をかけさせることがない。ただし、Cookie盗難には十分注意する必要がある。

続いてゲストブック（記名帳）を用意する。ゲストブックとは、閲覧者がサイト管理者に対して、自分が読者であることを表明するための投稿フォームである。ゲストブックへの登録の際には自動的にその閲覧者のRURIコードも記録される。ゲストブックに登録した人（RURIコード）は、「GUESTグループ」に加えられることになる。

またこのゲストブック登録の段階で、メールによる自動認証（登録されたメールアドレスにシステムがワンタイムパスワード付きメールを送信し、そのパスワードによって正当なメールアドレスかを自動確認する）などをシステムに組み込むことができる。そのシステムを適用する場合は、ゲストブックに登録しただけの閲覧者を「弱いGUESTグループ」、その中でメールによる自動認証をすませた閲覧者を「強いGUESTグループ」に加えるなど、2段階のグルーピングを適用することもできる。ただしここではできるだけ話をシンプルにするため、1段階のGUESTグループを適用することにして話を進める。

ゲストブックは原則として管理者にのみ公開される。そこで、そこには管理者以外には知られたくない情報を記述することもできる。たとえば「○○高校で同級生だった○○だよ」みたいに個人情報を含んだ内容も登録でき、それによって管理者はあるRURIコードの持ち主が誰なのかをより正確に判別することができる。当人同士しか知らないはずの情報を含ませるほど、本人確認の厳密さが高まるだろう。

管理者は、ゲストブックに登録した人の中から自分が選んだ人を、「FRIENDグループ」に昇格させることができる。単純にゲストブックの書き込み1件ごとに対して、グループ昇格ボタンなどをクリックするような形だろう。

ここでも実際には、ごくごく親しい知り合い用の「強いFRIENDグループ」、それ以外の知り合い用の「弱いFRIENDグループ」のような複数の段階のグルーピングを行うこともできるが、ここでは話を単純化するために1段階のFRIENDグループを適用することにして話を進める。

以上のグループに含まれていない閲覧者は、「ANONYMOUSグループ」に含まれることとすると、閲覧者は「ANONYMOUS（見知らぬ読者）」、「GUEST（登録読者）」、「FRIEND（知り合い）」という三つのグループに分けられることになる。

ANONYMOUSに関しては完全な自動登録となるし、GUESTに関しては閲覧者のちょっとした作業のみで登録が行われる。FRIENDに関してはさらに管理者のちょっとした作業が必要になるが、規模がよほど大きくない限りはそれほどの手間ではないだろう。といった程度のコストで、閲覧者をそれなりに妥当な権限グループに振り分けることができる。また、この程度ならばそれほど技術に詳しい人でなくても、仕組みを理解することができるだろう。

続いて、このようにグルーピングした閲覧者に対して、どのように認証および制限を加えていくか。

システム自体の設定としては、まず閲覧者からのリアクション機能に関する設定がある。具体的にはコメント機能やメールフォーム機能を、どのグループのユーザーに対して公開するか。ゲストブックにURLも登録されているのならば、そのURLとのマッチングによってTrackBackに対する認証を行うことも可能になる。

比較的内輪向けのサイトならば、コメント機能はFRIENDのみ、メールフォーム機能はGUESTとFRIENDのみ、といった感じになるだろうか。オープンなサイトならば、すべての機能をANONYMOUSにも使わせればいい。

あるいは、許可したグループにのみリアクション機能を使わせるのではなく、他のグループにも投稿だけは許可するが、その内容をサイト上に掲載するかどうかは、管理者が決定できるようにすることもできるだろう。+[いわゆる、管理者がチェックしない限りはWeb上に投稿が掲載されない掲示板システムと同様の仕組みだ。]+

続いて公開範囲および規模の設定を、記事単位で行うことができる。基本的には、どのグループに対して何アクセスまで公開するかを設定することになる。

たとえば内輪向けの記事ならば、FRIENDに対してのみ無制限アクセスを許可（許可アクセス数=-1）し、GUESTやANONYMOUSに対してはアクセスを拒否（許可アクセス数=0）すればいい。その記事は知り合いのみが閲覧することができるようになる。

また、ある程度は一般に公開してもいいが、あまりリアクションが多くなることを恐れるのならば、たとえばGUESTには「許可アクセス数=100」、ANONYMOUSには「許可アクセス数=10」などと設定しておく。すると、GUESTグループに所属する人が100回アクセスすると、それ以降訪れたGUESTグループの人には「現在公開が停止されています」などのアナウンスが表示されるようになる。同じくANONYMOUSグループの人は10アクセスまでしか閲覧することはできない。

ちなみに、このような制限を施している場合は、（システム的に）その説明を明示しておいた方がいいだろう。

「この記事は友達登録を行った人にのみ公開しており、それ以外の方は閲覧できないようになっています。友達登録を行いたい方はゲストブックからご登録ください」

あるいは、

「この記事は100人にまで閲覧を許可しています。それ以上の閲覧者が訪れた場合は自動的に公開が停止されます」

などと提示しておく。それによって、その記事の公開範囲・規模が閲覧者に伝わり、その結果背景にある管理者の意図が、ある程度閲覧者（あるいは閲覧できない人）に伝わることになる。

もちろんこのように閲覧者を制限したところで、誰かがその記事の内容を引用したり転載したりすることによって、ネット上に広まっていってしまうことはある程度はさけられない。しかし、現状の管理者の公開意図がほとんど伝わらないシステムと比べると、ずいぶんとましな状況になるのではないだろうか。

以上の仕様では、特に難度・コストが高い技術は使っていないので、一般的なWeb技術者ならば比較的簡単に実装が可能だろう。また、細部に関しては様々なカスタマイズの余地もあるので、利用するサービスに応じて適切に応用してもいい。