cyber BONMEE

1. サーチエンジンのロボットを排除

robots.txtで新旧それぞれのサブドメインへのアクセスを止めます。

User-agent: *
Disallow: /

2. Googleからインデクスを削除

ウェブマスターツールから[クローラのアクセス]→[URLの削除]→[新しい削除リクエスト]で申請。数時間で完全に削除されました。

3. サーバーのサブドメイン設定を変更

新しいサブドメインをブログが置かれたディレクトリにポイントし、古いサブドメインのポイント先に新しいディレクトリを作成します。新しいディレクトリの中身は空ですから、これにより以前のURLではブログにアクセス出来なくなります。

4. 旧サブドメインのポイント先にエラーメッセージを準備

作成したディレクトリには、更に /error ディレクトリを作成して403と404のページを準備。アクセスがあった際にエラーを返すと同時に、新サブドメインへ誘導するメッセージを記載しておきます。

5. .htaccessの書き換え

新ドメインのドキュメントルートには旧ドメインで使用していた.htaccessをそのまま置きますが、エラードキュメントのURLのみ変更しておきます。

ErrorDocument 404 http://cyber.bonmee.com/error/404.html
ErrorDocument 403 http://cyber.bonmee.com/error/403.html
AddDefaultCharset utf-8
Order Allow,Deny
Allow from all

Deny from ***

旧ドメインの方にも.htaccessを置きます。

ErrorDocument 404 http://blog.bonmee.com/error/404.html
ErrorDocument 403 http://blog.bonmee.com/error/403.html
AddDefaultCharset utf-8
Order Allow,Deny
Allow from all

6. 新サブドメインのrobots.txtを書き換え

新しいサブドメインへのロボットアクセスを許可します。ただし、エラーメッセージや画像があるディレクトリへのアクセスは禁止しておきます。

User-agent: *
Allow: /
Disallow: /image/
Disallow: /error/

エラーメッセージがインデクスされても検索結果にゴミが混ざるだけですし、画像をインデクスされても困りますからね。

7. WordPressのブログURLを変更

Dashboardの[Settings]からWordPress addressとBlog addressを変更。これにより、自動生成される内部リンクのサブドメインが新しい方に書き換えられます。

8. 記事内に記述された内部リンクの変更

記事内に貼られた過去記事へのリンクを見直します。が、これは各ページをチェックしながらの手作業ですので時間を要しますね。後になって見落としが発覚しそうな気もします。

9. 外部JavaScriptファイル内の記述を変更

外部JavaScript内に旧サブドメインが記載されていますので、それを新サブドメインに書き換えます。これはEmacsで M-x replace-string を使えば一瞬ですべてが書き換わります。

10. ドメイン内の他サイトから貼られたリンクを修正

www.bonmee.comやgourmet.bonmee.comなどに記述されているブログへのリンクを書き換えます。これも手作業だと非常に面倒な作業になりますが、htmlファイルですからね。コンソールからPerlでプログラムを打ち込んで書き換えれば一瞬です。

# perl
@files= `ls -l`;
foreach $files(@files){
　　$_ = `cat $files`;
　　$_ =~ s/blog\.bonmee.\com/cyber\.bonmee\.com/g;
　　$new = $files + “.tmp”;
　　`touch $new`;
　　print $_, $new;
　　rename $new, $files;
}
C^d

各ディレクトリを `ls -l` でリスティングして cat でファイルを開き、s///でリプレースします。touch で空のファイルを作成して書き換えた内容を出力し、ファイル名に”.tmp”を付加して保存。その後、元のファイル名にリネームします。簡単ですね。

11. リンクして頂いている他サイトへ書き換えの依頼

これは他人様の問題でもありますので、私一人ではどうしようもありませんね。折にふれて、順次お願いに巡回することにします。

デフォルトでは、記事のタイトルが2行になった時にその2行目が大きく下に離されていて大変なことに。

早速エディタでstyle.cssを開いて中身を確認すると、該当する部分にどうもよく分からない記述があります。


.post_left {
　　width: 410px;
　　height: 67px;
　　float: left;
　　line-height: 55px;
　　margin-left:18px;
}


何がよく分からないって、heightが67pxでline-heightが55pxというところが分からない。

何か裏でもあるのだろうと思って調べてみると確かに裏はありましたが、まぁその辺の話は置いといて、とにかく記事のタイトルが2行になった時に困りますね。ですから、下記のようにline-heightの行をコメントアウトしました。


.post_left {
　　width: 410px;
　　height: 67px;
　　float: left;
　　/*line-height: 55px;*/
　　margin-left:18px;
}


記事タイトルはデフォルトでh3だったのですが、それだと大き過ぎるため変更することに。

index.php、page.php、archive.php、single.phpの4ファイルに記述がありますので、それぞれを開いてh4～h6で試してみます。が、どれもしっくり来ません。

それで、とりあえずタグはh4に決めて、サイズはcssで130%に調整することにしました。上記の4ファイルでタイトル部分の記述が微妙に違っているため、下記のように分けて追加。


#contentleft h4{
　　font-size: 130%;
}
.post_left h4{
　　font-size: 130%;
}


次に、個別記事のページ。ここだけページタイトルが背景の枠を上に突き抜けていましたので、paddingで調整しよう・・・としたところ、左右のラインが切れてしまってまたまた困ったことに。

ちゃんとコードを読んでから手をつければいいのにとりあえず動くのは私の悪いクセなんですが、これは少々困りました。


.single_title {
　　width: 530px;
　　height: 67px;
　　background: url(images/single_title.jpg) no-repeat;
　　margin: 0;
　　/*padding: 0 0 0 15px;*/
　　padding: 1px 0 0 15px;
　　/*line-height: 67px;*/
}


結局、ここにも登場する大きな値のline-heightをコメントアウトし、上にpaddingを1pxだけ取ってラインの切れ目を目立たないようにすることでとりあえず。

後のことは明日以降にでもまたゆっくり考えるかも知れませんし、考えないかも知れません。

フォントサイズがデフォルトで12pxと固定でしたので、それを.85emの相対指定に。


body {
　　background: #332610 url(images/bg.jpg) repeat-x;
　　color: #FFF;
　　/*font-size: 12px;*/
　　font-size: .85em;
　　font-family: "MS P Gothic", "Hiragino Kaku Gothic","VL Gothic",Tahoma, Verdana, Arial;
　　margin: 0px auto 0px;
　　padding: 0px;
}


他の部分は同じくpx値による絶対指定のところを%による相対指定に変更。ブラウザのデフォルトフォントサイズは人それぞれですし、目がいい方ばかりでもありませんからね。

後は例によってJavaScriptの積み替えですが、今はほとんどの関数を外部ファイルに格納してありますので遅滞なく終了。


<script src=./xxx.js>//</script>
<script language=javascript><!--
var loadFlag = 0;
//--></script>
<script language=javascript><!--
checkCookie();
kickAccess();
checkStaySeconds();
//--></script>


これで大丈夫と思ったのですが・・・。

記事を展開する▼ Click here to read More… の行に設定してあるpaddingが地雷でして、そこでまた左右のラインが切れてしまうことに。

これ、cssファイルではなく各記事にstyle指定してあるため、修正しようとするとすべての記事を開いて書き換えなければなりません。面倒がってコピー＆ペーストで対応して来たツケが回って来た格好です。


<div style="margin:24px 0px 24px 0px";><a href=javascript:expand('google')>▼ Click Here to Read More...</a></div>
<div id=google style=display:none;>


しばらく迷っていましたが、もう一度各記事を見直してみるチャンスとも受け取れますので、該当部分のstyleを消してdivにclassを割り振る作業を始めることに。今後の修正も楽になりますしね。

ただ・・・エントリーの数が合計で403あります。全部手作業で書き換えですか？　ああ、やっぱりそうですか。

横着するものじゃないなぁ・・・。

■ スパム対策プラグインのAkismet

WordPressにはスパムを検知して隔離するAkismetというプラグインがあります。

1年ほど前に書いたエントリーと重複しますが、このAkismetも単にスパムを隔離するだけで、実は根本的な解決にはなりません。何故ならば、「隔離する」ことと「ブロックする」ことは別だからです。

ほとんどのスパマーは同じコメントをスクリプトで大量に送信しますので、書き込めたかどうかを人が目で見て確認することはありません。あくまでサーバーが返すステータスコードだけを見ており、そこで301や302、あるいは403や404が返れば「失敗」、200が返れば「成功」となります。

Akismetはブロックではなく隔離ですから、サーバーはステータスコード200を返しています。

彼らにとっては通ったコメントが表示されていようがいるまいが関係ないので、これはスパム送信成功を意味し、その該当記事は「今後も送り続ける」対象のリストに残ってしまいます。根本的な解決にならないというのはこの部分です。

じゃあ、どうすればいいか。

■ 根本的な解決策を探る

スパマーは各記事に配置されているコメントフォームから送信しているのではなく、コメントフォームに書き込んだ時と同じクエリをwp-comments-post.phpに直接送って来ます。ですから「それを止めてしまえ」というのもひとつの考え方ですね。

一口に「止める」と言っても、考えられる方法はいくつかあります。

とりあえず効果がありそうに思えるのは「HTTP_REFERERにブログ本体のドメインを含む場合にポストを許可する」ようphpコードを書き換えること。スパマーが自動送信して来るコメントは大抵referrerを持ちませんから、この方法はかなり有効かと思われます。

ただ、これには大きな問題点がひとつあります。それは「非常に面倒くさい」ことです。

phpコードを書き換える訳ですから、いくつものファイルに分かれているプログラムのすべてに目を通し、矛盾が生じないよう書き換えなければなりません。これだけ考えても余裕で眠くなります。

加えて、WordPressのアップデートを行うたびにその作業が待っています。

自分が書いたプログラムならば全体のブロックダイアグラムはおおむね把握していますが、それでもかなりの面倒な作業になるでしょう。ましてWordPressは他人様が書いたプログラムです。改造したものを売る気ならともかく、ただの日記趣味にそこまでの労力は費やせません。

■ 古典的な手法

昔からある古典的な方法としては「wp-comments-post.phpをリネームする」というものがありますね。スパマーはそこへ直接actionしてクエリを送って来るのですから、確かにこれも有効だと思われます。

ただ、この方法にも大きな問題点があります。それは「人の目でソースコードを見られたら一瞬でバレてしまう」ことです。

昔、Perlで書いたCGIにスパムがよく来ていた頃、投稿フォーム部分のコードを外部の.jsファイルに格納してdocument.writeで書き出していたことがあります。

action先をソースコードから消せるため当初は効果がありましたが、そのうち誰かが外部の.jsファイルを見たんでしょうね。一度バレたら後はもうザル状態になり、私はまたコードを書き換えてと、結局は無限ループのいたちごっこになってしまいました。

当然、この方法にも限界はあるということです。

■ 一番マシな方法はどれ？

ただ、action先をリネームする方法は、一度ざっと全体のコードを見通せばいいだけ（読む必要はない）ですから比較的簡単ですね。現時点でのデフォルトのアクション先はwp-comments-post.phpですから、そのファイル名が登場する部分がどことどこにあって、という情報だけを掴んでおけば簡単に対処出来そうです。

どのファイルにwp-comments-post.phpという記述があるかを調べるには、コンソールから$ perlを実行して下記のプログラムを打ち込みます。


$ cd wordpress/wp-content/themes/bible-scholar
$ perl
@_ = `ls | grep php`;
foreach $_(@_){
　$cat = `cat $_ `;
　if($cat =~ /wp-comments-post/){
　　print;
　}
}
C^d


テーマディレクトリにあるファイル名からphpが付くものだけを抽出して配列に格納し、foreachで回しながら`cat`でファイルの中身を吐き出させて$catに格納、wp-comments-postにヒットしたファイル名だけを出力させます。簡単ですね。

これを実行すると、なんとcomments.phpだけがヒットします。あれ？

そういうことなら、この方法が一番お手軽ですね。これにしましょう。かなりベタなやり方ではありますが。

■ 必要なファイルの書き換えとリネーム

wp-comments-post.phpをリネームするだけでは、action先がnot foundになってコメントポストが出来ません。ですから、まずはそこを書き換えます。

Dashboardから[Appearance]→[Editor]→[Comments.php]で開き、下にスクロールして真ん中付近にありますね。そこのwp-comments.post.phpを、何か適当なファイル名に変更します。hana-mogera.phpでもqawsedrftgyhujiko.phpでも何でも構いません。

次に、ローカルでwp-comments-post.phpを同じ名前にリネームしてからftpで送ります。これでコメントポストを試したところ、問題なく投稿出来ました。

ただ、これで終了という訳ではありません。上に書いた通り、場合によってはスパマーとの「いたちごっこ」が起こり得るからです。

あと、これは私が使用しているBible Scolarというテーマの場合に限った話かも知れません。他のテーマの場合は分かりませんので、上記のperlスクリプトなり他の方法なりで事前に丁寧に調べておく必要はあるでしょう。

あまり手の内を晒すのもアレなんですが、ちゃんとコンテンツをお読みになる方はこのコンテンツもお読みになるでしょうから、こちらには手法を公開しておきます。

var lh = location.href;
splh1 = new Array;
if(lh.match(/\&/)){
　　splh1 = lh.split(’&');
　　lh = splh1[0];
}
splh2 = new Array;
splh2 = lh.split(’=');
lh = splh2[1];
dsln = new Array(”1234″,”5678″,”9012″,”3456″,”7890″,”11234″);
var dsflag = 0;
for(i=0;i 　　if(dsln[i] == lh){
　　　　dsflag = 1;
　　　　cbmds = dsln[i];
　　　　break;
　　}
}
if(dsflag == 1){ setCookie("__cbmds", cbmds); }
if((cbmds == lh) && (iflag == 0) && (cbmsd == 1) && (dsflag == 1)){
　　alert("このコンテンツは表示出来ません。\n\n問題解決のための情報は他のサイトでお探し下さい。");
　　cbmr = getCookie("__cbmr");
　　clearCookie("__cbm");
　　location.href = cbmr;
}

ページにアクセスがあった時点でそのページのURLを取得し、”&”が含まれる場合は”&”で分割して配列 splh1 に収め、URLの前半部分を変数 lh に代入します。

例：
http://blog.bonmee.com/?p=1234″&”Comment
　↓
http://blog.bonmee.com/?p=1234　←ここが変数 lh に格納される

次に、lh に代入された文字列を “=” で分割し、今度は後半部分を変数 lh に代入します。この時点で変数 lh にはパーマリンクの数字部分のみが格納されています。

例：
http://blog.bonmee.com/?p”=”1234
　↓
1234　　　　　　　　　　　　　　←ここが変数 lh に格納される

配列 dsln に該当ページの数字部分だけを格納しておき、forで回しながら lh と照合、マッチした時点でフラグを立て、マッチした数字をcookieで送ります。

初めてのアクセスだった場合はその下の行は実行されず、以下のスクリプトへ飛びます。

if(dsflag == 1){
　　alert(”このコンテンツは表示出来ません。\n\nサーチエンジンからこのページへの訪問者は概ね直帰率が高く滞在時間も短いため\t\n先に表示した「何らかの問題を解決するための情報をお探しの方」に該当すると認めます。\n\n情報目的の閲覧をお断りする旨については既にご同意頂いておりますので\n問題解決の参考になる情報は他のサイトでお探し下さい。”);
　　clearCookie(”__cbm”);
　　cbmsd = 1;
　　setCookie(”__cbmsd”, cbmsd);
　　location.href = cbmr;
}else{
　　location.reload();
}

サーチエンジンからのアクセスを判定してサイトポリシーを表示し、OKがクリックされた時点でフラグが立っていた場合、該当ページを表示する前に弾きます。

そのままでは、弾かれたユーザーがブラウザのアドレスバーにURLを直接入力すれば表示されてしまいますね。それを回避するために “__cbmsd” というcookieを食わせて識別します。このcookieを食った状態では、配列dslnに登録されたページは何をやっても表示されません。

これを回避するには一旦トップページを表示させ（cookieが消去される）、サイト内のリンクをたどって該当ページへ行き着く必要があります。

しかし、そこで先を急いで次から次へとリンクを辿ると、今度は1ページ10秒の制限に引っかかることになります。このブログは、10秒未満のページ移動を3回繰り返せば警告メッセージが表示され、更に3回繰り返せば403に飛んで以後のアクセスは拒否される仕組みになっているからです。

要するに、「情報が欲しいだけでコンテンツに興味がない人は来ないでくれ」と言ってるのと同じことですね。

何度も書きますけれども、確かにサイト内でユーザーがどのように振る舞おうがユーザーの自由ですが、一方では管理者が誰にサイトを公開するかを決めるのもまた自由ですので。

それから、アクセス制限にcookieを利用しますので、cookieを拒否されていればこの手法は通用しませんね。ですから、最初の部分に以下のスクリプトを埋め込んでおきます。

var cbmt = 1;
setCookie(”__cbmt”, cbmt);
　
（中略）
　
cbmt = getCookie(”__cbmt”);
if(cbmt == “”){
　　alert(”cookieを有効にして下さい。”);
　　history.back();
}
clearCookie(”__cbmt”);

“__cbmt” というテスト用のcookieを送り、その後で受信して中身を確認します。もしも受け取ったcookieの中身が空だったらブラウザはcookieを食っていないことになりますので、その場合は history.back() で元のページに戻って頂くことに。

後はJavaScriptを切って来られた場合ですが、noscriptで無理やり403へ飛ばしてもいいのですけれども、今のところはそこまでは考えていません。JavaScriptを切ってある場合、私のブログ記事は半分以上が読めない作りになっているからです。

これでまた少し様子を見てみます。

今回追加したのは下記のコードです。

function checkStaySeconds(){
　　if(cbme == 1){
　　　　stSec = new Date;
　　　　stc = stSec.getTime();
　　　　cbms = getCookie(”__cbms”);
　　　　if(cbms == “”){ cbms = 0; }
　　　　if(navigator.userAgent.match(/MSIE/)){ sflag = 3; }else{ sflag = 3; }
　　　　if(cbms == sflag){
　　　　　　cbms = sflag + 1;
　　　　　　setCookie(”__cbms”, cbms);
　　　　　　lgflag = confirm(”10秒未満でのページ移動が一定の回数を超えました。\n\nあと3回でアクセス禁止が設定されます。\n\nお帰りになりますか？”);
　　　　　　if(lgflag == true){
　　　　　　　　cbmr = getCookie(”__cbmr”);
　　　　　　　　location.href = cbmr;
　　　　　　}else{
　　　　　　　　location.reload();
　　　　　　}
　　　　}
　　　　if(cbms > sflag + 3){
　　　　　　deny = 1;
　　　　　　setCookie(”__deny”, deny);
　　　　　　clearCookie(”__cbm”);
　　　　　　clearCookie(”__cbms”);
　　　　　　alert(”10秒未満でのページ移動が制限回数を超えました。\n\nコンテンツをお読みになる意志はないものと認め、\n\n以後のアクセスはお断りします。”);
　　　　　　location.href=”http://blog.bonmee.com/error/403.html”;
　　　　}
　　}
}
function checkSecondsUntilLeave(){
　　if(cbme == 1){
　　　　lvSec = new Date;
　　　　lvc = lvSec.getTime();
　　　　lvc2 = lvc – stc;
　　　　if(lvc2 < 10000){
　　　　　　cbms++;
　　　　　　setCookie("__cbms", cbms);
　　　　}else if(lvc2 > 30000){
　　　　　　clearCookie(”__cbms”);
　　　　}
　　}
}

サーチエンジンのURLをリファーラーに持つアクセスに cbme=1 というフラグを立て、該当する場合にのみ上記のfunctionを実行します。

stc = stSec.getTime(); でアクセスがあった日時を秒まで取得して変数に格納し、そのページを去る時に lvc = lvSec.getTime(); でも時刻を取得、stc と比較して10秒が経過していない場合に cbms という変数の値に1を設定してcookieを送り込みます。

次にまた10秒以内に去った場合、cbms の値はひとつインクリメントされてcookieで送られます。この cbms の値は10秒以上の滞在があった場合でも保持されますが、30秒を超える滞在があった時点で一旦ゼロにリセットされます。コンテンツをお読み頂いた方を簡単に排除しないためです。

そして、cbmsの値が3になった時、つまり10秒以下でのページ遷移が3回目に達した時点でconfirmによるメッセージを表示。あと3回でアクセス禁止が設定される旨を警告して、閲覧を続けるかどうかを尋ねます。

[キャンセル]がクリックされた場合（お帰りになる場合）は、最初のアクセスがあった時点で cbmr というcookieに保持されたリファーラー宛に location.href で送り返します。このリファーラーは、最初のアクセスのトリガーとなったサーチエンジンの検索ページです。

[OK]がクリックされた場合（滞在を続ける場合）は、変数 cbms に4が代入されてcookieで送られます。

その後も10秒未満でのページ移動があった場合は cbms がインクリメントされ、その値が6を超えた時点で deny というフラグが立ち、cookieが送られます。この deny に値を持つ状態でアクセスがあった場合は、どのような形であれ（たとえブラウザのアドレスバーにURLが入力されたとしても）403エラーを返します。

cookieを削除すればまたアクセス出来るようになりますが、それで頻繁に同じことを繰り返されるようであれば、今度は該当するIPアドレスを.htaccessに登録してdenyすることになりますね。

この処理は、あくまでサーチエンジンから来られた単発のアクセスにのみ実行されます。ブックマークや他サイトのリンクからのアクセスについては、ある程度ページをご覧頂けていますのでね。今のところは必要ないと見ています。

以前の仕込みで、検索エンジンにヒットした私のブログへのリンクをクリックした際に、

サーチエンジンから来られた方へ。
　
このブログは個人のサイトで、主に日記やエッセイのようなものを掲載しています。
大した情報はなく、きっと検索のお役には立てないでしょう。
　
このまま読み込みを続けますか？

というconfirmを表示させ、それでも良ければ”OK”をクリックしてページを表示させるようにしてありました。

しかし、どうもその文章すらお読みにならない方が多いようですね。そういう方は、なおさら私の記事などお読みになる筈がありません。

それでは意味がないので、どうしようかと考えました。OKとキャンセルを入れ替えて「盲目的なOKクリック」を排除しようともしましたが、今度は盲目的に「キャンセル」する人が流れ込んで来ます。難しいですね。

そこで、ちょっとコードをいじってみました。

if((cb == 1) && (rflag == 3) && (dn == 0)){
　　cfTime = new Date();
　　scs = cfTime.getTime();　　　　　　// 時刻を取得
　　var flag = confirm(”メッセージ”);　　// 確認メッセージを表示
　　if(flag == false){
　　　　clearCookie(”__cbm”);　　　　// キャンセルをクリックでcookie消去
　　　　history.back();　　　　　　　　// 前のページに戻る
　　}else{
　　　　cfTime1 = new Date();
　　　　scs1 = cfTime1.getTime();　　　// OKクリックの時刻を取得
　　　　scs2 = cfTime1 – cfTime;　　　// 確認メッセージ表示とOKクリックの時間差
　　　　if(scs2 > 10000){
　　　　　　clearCookie(”__cfcnt”);
　　　　　　location.reload();
　　　　}else{　　　　　　　　// 10秒以内のOKクリックはメッセージ未読と判断
　　　　　　alert(”文章をよくお読みになった上でクリックして下さい。” + scs2);
　　　　　　clearCookie(”__cbm”);　　　　// cookie消去
　　　　　　cfcnt = getCookie(”__cfcnt”);　　// フライング回数を取得
　　　　　　if(cfcnt == “”){ cfcnt = 0; }
　　　　　　cfcnt++;
　　　　　　if(cfcnt > 2){
　　　　　　　　deny = 1;　　　// フライング3回でdenyフラグを立てる
　　　　　　　　setCookie(”__deny”, deny);　// 以後のアクセス禁止を決定
　　　　　　}
　　　　　　setCookie(”__cfcnt”, cfcnt);
　　　　　　history.back();　　　　　// 前のページに戻る
　　　　　　}
　　　　}
　　}
　　loadFlag = 1;
}

confirm表示の時刻とOKがクリックされた時刻を比較して、10秒以内にOKがクリックされた場合は「メッセージを読んでいない」と判断。フライングとして扱い、もう一度メッセージをよくお読み頂くよう確認します。

フライング回数は”__cfcnt”というcookieに記録され、ブラウザに送られます。もう一度アクセスして来た時にその回数を読み取り、またフライングがあれば”__cfcnt”の値が1つインクリメントされます。

“__cfcnt”の値が3になった時点で”__deny”というcookieが書き込まれ、それ以降のアクセスは強制的に403エラーを返します。事実上のアクセス拒否ですね。

少々意地悪な仕込みではありますが、アクセス拒否を決めるcookieはおおむね24時間でexpireしますので、まぁちょっと驚かせる程度のものですね。cookieを消去して来られたらまた最初からになりますので、「読まない人は来なくていいよ」という意志表示をしたというだけのことで。

ユーザーがどこでどのように振る舞おうがユーザーの自由ですが、同時にブログアーサーがどのようなターゲットにエントリーを公開するか決めるのもまた自由です。

これで少し様子を見てみます。