このブログもWordPressを利用して作られています。
最近ではブログエンジンのみならず、CMSとして利用される例も多くなってきました。
私自身、案件でもよく利用しているわけですが、近頃ではその限界点を感じるようになり、案件では採用しないことが多くなってきました。
企業のWeb担当者や、システムを知らないがWordPressなら構築が出来ると謳う方には、是非一度考えてもらいたいと思い、ここに記します。

※この文章は私自身の個人的な意見であり、WordPressで構築されたサイトを批判、中傷するものではありません。

WordPressに問題を感じる理由はいくつかあります。
もちろんその問題をある程度解消する方法も存在することは承知の上で、挙げてみます。

１．DBの問題

WordPressを案件で採用しない一番の理由がDBの問題です。
CMSエンジンとしても使われるようになったためか、汎用性を意識した作りをしており、DB構造が非常にややこしいです。

その上、HTML吐き出し型では無く、アクセスの度にDBにクエリを投げる形を取っています。
これによりサーバへの負荷が増え、多量のアクセスを捌くことが困難になります。

ApacheやMysqlのチューニングである程度は負荷を下げることが出来ますが、根本的な解決にはなりません。

２．プラグインの問題

ここまでWordPressが広く普及した理由は、プラグインの存在無しには語れないでしょう。
「手軽に導入出来るプラグインによるカスタマイズ」こそがWordPressの魅力と言っても過言では無いと思います。

しかし、それこそが致命的な欠点を作り出しているとも言えます。

まず、その手軽さ。
ほとんどのプラグインがボタン一つで簡単に導入できるわけですが、あなたはその中身の動作を知っていますか？
中でどういう処理が行われていて、どのような脆弱性を持っているのか。

先日、導入したが有効化していないプラグインの脆弱性を突かれて、サイトの中身を改ざんされたという記事を目にしました。
何故こんな事件が発生してしまったのか。

ここからは推測の域を出ませんが、可能性のお話です。
WordPressの管理画面やプラグインのURLは設定を変更しない限り、デフォルトのものが使用されます。
つまり、そのサイトがWordPressを使っていて、かつ、そのプラグインをインストールしていれば、有効化しているかどうかに関わらず、そのプラグインの脆弱性を突くことが可能になってくるわけです。

こうした被害も、個人のブログであれば、たいして問題無いかもしれませんが、企業のホームページに導入していた場合、どうなるでしょうか？
誰が責任をとってくれますか？

WordPressはオープンソースのプログラムですから、作った人が何かを担保してくれるわけではありません。
導入を決定した人が、あくまで責任を負う必要が出てくるわけです。

そのリスクを理解した上で導入を決定しているかどうか。

WordPressの導入を決定した担当者は、そこまでの判断をした上で利用を決定しているのでしょうか。

３．直接のカスタマイズの問題

WordPressはPHPで作られており、PHPの読み書きが出来ればある程度のカスタマイズが可能になっています。
テンプレートを作りたければ、最小限のPHPの知識と、WordPress独自関数の知識があれば良いのです。

しかし、中途半端な知識は脆弱性の温床です。
言うまでもありませんが、「知らなかった」なんて言い訳には出来ません。

また、WordPress本体の問題も多くあります。
歴史的な理由もあり、WordPress独自関数は整備状況が甘く、命名ルールや挙動すらも統一されていないという惨状です。
当然そこで出来上がるコードは、非常に可読性が低く、今後の再利用に適さないものになります。
あとから機能を追加したくとも、まずは解読から、という状況も珍しくありません。
しっかりしたドキュメントを作れば解決…たしかにそうですが、それってスクラッチ開発とどう違うんでしょうね？

WordPress自体は、オープンソースそのものの発展に大きく寄与した面もあり、高く評価しています。
しかし、だからといって盲目的にそれを信頼し、下駄を預けられるか、というとそれは別の問題です。

考えなくなることは楽ですが、そこに潜む危険について知らないことは、思わぬときに悲劇を生む地雷のような存在だと思います。

よく、「プログラミング出来るなんてすごいねー！」と言われますが、言われるたびに「全然すごくないですよ」と言ってしまい、「すごいって言ってるんだから余計な謙遜しなきゃいいのに…」みたいな微妙な空気になることがあります。

まぁそもそも僕がプログラマとしてそんなにすごくないというのはありますが、気にしない方向で…

なんで「すごい」「すごくない」の感覚はこんなにも違うのか。

プログラミングは魔法ではない

これを言われるのって、勉強出来る人が「勉強出来てすごいねー！」と言われるのと同じ構造です。

勉強が出来る人は何故すごくないと思うか？　勉強したからです。

やったんだから出来るのは当たり前です。

それなのに「すごい」と言われるのは、マニュアルに書いてある通りに刺身にタンポポを乗せてたら「君はタンポポ乗せの才能があるね！どう？うちにこない？」って突然言われるくらいの違和感があるわけです。

嘘です。言い過ぎました。

しかし、ここで強く言っておきますがプログラミングのコードは呪文ではありません。

あるルールに従って書かれた文字の羅列です。

分かってる人にはそりゃそうだろ、っていうことですが…

ではなぜ、「プログラミングはすごい」という感覚が生まれるのか。

辞書があれば英語を読める？

僕は、英語の勉強が好きでした。

そこまで成績が良いわけではなかったですが、長文を読むことにも抵抗はあまりありませんでした。

長文と言っても、和英辞書があれば、正確じゃなくても何とか読めます。

もしかしたら、大事なのはこの感覚なのかもしれないと思います。

英語もPHPも、ルールに従って書かれた文章です。

基本的ないくつかのルールを覚えてしまえば、あとは単語を調べるだけで済みます。

英語なら辞書があればいいですし、PHPならほとんどの場合関数リファレンスを見れば良いだけです。

スラスラ読めたらカッコイイかもしれませんが、どんくさくても辞書を片手に読み解くことは、忍耐力があれば出来ることだと思います。

それなのに、挫折する人が多いのは何故でしょうか？

覚えることが多い…ように見える

感覚値ですが、「基本的ないくつかのルール」を覚えるのに挫折する人は意外と少ないです。

ただ、「基本的ないくつかのルールを覚えること」と「単語を覚えること」を混同して挫折する人は多いです。

「こんなに覚えることがあるのか…」と思った瞬間に、やる気が失われてしまうのです。

英語もプログラミングも、同じ傾向にあると思います。

こういう理由ですから、プログラミングを覚えるのは大変なことじゃないですよ

…っていうまとめになるわけですが、何故今回、この文章を書くに至ったかを書いておきます。

端的に言えば、WebデザイナはjQueryを学んだほうが良いと感じているからです。

jQueryと一口に言っても様々なことが可能です。

学ぶなら、主に表示系のインターフェースに関わる部分を学ぶのが良いと思います。

要素の表示／非表示、アニメーションの操作、レイヤーの考え方。

インターフェースの設計については場合によってはSEの範疇かもしれませんが、Webデザイナとしてもインターフェースへの考慮は必須になっていくでしょう。
（僕はデザインと設計は同義語だと考えています）

英語は話せますか？

英語を話せますか？と誰かに聞かれたとき、基本的に僕は「話せます」と答えています。

話せる英語は中学校で習うような基本的なものばかりですが、生活に困ることは無い程度には話せます。

ほとんどの場合、「相手に何を伝えれば良いか」だけ考れば、実際伝えるべき部分は簡単な英語で済むものです。

それはプログラミングの場合、設計に当たります。

jQueryで自分が意図する動作を作り出すには、どのように書いたら良いか、少し考えてみてください。

場合によっては（というよりはほとんどの場合）、インターネット上にヒント（または答え）が転がっていますが、あえて見ないで考えてみてください。

それが実現出来たら、プログラミングの設計から構築まで一人の力で出来る、と言って良いと思いますし、Webデザイナとしてのスキルに一つのエッセンスを加えることが出来るのではないでしょうか。

T/O…というわけにもいかないので思ったことをつらつら書いてみる。

というか、オワコンって言ってみたかっただけだ。すまない。

そもそもSEOってなんだ

検索エンジン最適化 – Wikipedia

ある特定の検索エンジンを対象として検索結果でより上位に現れるようにウェブページを書き換えること。または、その技術のこと。

それ以上でもそれ以下でも無い。

所有するサイトが検索エンジンの上位結果に表示されれば、アクセス数が増えてハッピーというわけだ。

どんなハッピーなのかは人による。

何故オワコンか

Google自身が検索結果を最適化しているからに他ならない。

猪口才な技術を使って検索結果の上位に表示させるだって？

ふざけるのも大概にしたほうがいい。

本来の基準となる「良質な」コンテンツを作れ。話はそれからだ。

どんな基準を持って良質かって？

そんな質問が出る時点で、君は良質なコンテンツの制作者たり得ない。

何か別の職を探したほうがいい。

気付かないんじゃなくて、気付かないフリしてる？

SEOを商売として始めたから後に引けないのかもしれない。

もしくは、本気でSEOには未来があると信じているのかもしれない。

後に引けない人は、気付かないフリを決め込んで、無知な非IT企業に高値で売りつけるくらいしか出来ないだろう。

それだって、あと何年持つか怪しいものだ。

また、もしまだSEOという単語に希望を感じているのなら、はっきり認識しておいたほうがいい。

それは蜃気楼だ。

SEOという技術そのものに未来は無い。

今後想定されるのは「ソーシャルな」繋がりの中から導き出された基準による良質コンテンツの選別だ。

Google+を見るまでもなく、こんなことは誰でも分かることだろうけどね。

この文章の意味が分からない人へ

高円寺に来ることがあったら桃太郎寿司がうまいから、行くと良いよ。

自分用のメモです。

＜追記あり：2011/08/02＞

[sqlfairy-developers] Questions on MySQL -> SQLite translation

このページにTriggerを使った解決方法が書いてあったんだけど、このTriggerの文章だとテーブルのデータ全てに対してUPDATEがかかっちゃう。

ので、書き換えたのがこちら。
ちなみに、IDは一意であるとする前提。

CREATE TRIGGER hoge_modified AFTER UPDATE on hoge FOR EACH ROW
BEGIN
 UPDATE hoge SET modified = current_timestamp WHERE ID = old.ID;
END;

まぁ、WHERE句を足しただけなんですけどね。

＜追記：2011/08/02＞
SQLiteではデフォルトでcurrent_timestampがUTCになってしまい、ローカルの時間になってくれません。
それを解決したのが下記。
ついでに不必要なFOR EACH ROWを取り除いてます。

CREATE TRIGGER hoge_modified AFTER UPDATE on hoge
BEGIN
 UPDATE hoge SET modified = DATETIME("now","localtime") WHERE ID = old.ID;
END;

Webサイトを閲覧していると、一体どこがクリック出来るエリアなのか分からないことがあります。
このプラグインは、画面をスクロールしていって、該当の要素が画面内に登場するとハイライトしてくれるというプラグインです。

デモ
ダウンロード

仕組みとしては、指定した要素の上にdivの透明レイヤーを配置して、ハイライト時に一瞬だけ表示という方法で実現しています。
もともとはaタグにバインドして利用することを想定していましたが、他の任意の要素にもバインドできます。

基本的な使い方

html

オプションを指定した例

オプション

hlColor
ハイライトされる色を#ffffffなどで指定します。色名では指定できません。

cnt
連続してハイライトする回数を指定します。

指定された要素は、ページに登場すると一度だけハイライトされます。

今後のアップデート予定

登場回数指定オプション
その他要望があれば。
不具合、ご要望はこちらからどうぞ。

ライセンス

MITライセンスで公開します。ご自由に。

蛇足

このプラグインは、一般的なWebサイトに対しての提案だと思ってます。
一般的に、クリッカブルな領域であるかどうかを表現するには、デザインでの見せ方が必要と言われますが、そもそも平面でクリッカブルか否かを判断させるのは無理があります。
ならば、動作で見せてもいいんじゃないの？と思って作ったのがこちらのプラグイン。
UIに対する提案はいろいろ考えたいところですね。

Google＋、もうやってますか？

まだ正式版では無いようですが、早くもFacebookに負けず劣らずの胡散臭い動きがあった模様ですよ。

この記事を読んで知りました。

Googleプロフィールを「限定公開」していると、7月31日に削除されることが判明 – ロケットニュース24（β）

こちらの文中、

Google＋を本名で使用することを推進ために、講じた策と思われる。

これが非常にひっかかりました。

極端な発想ですが、今後本名での登録をGoogleが義務付けた場合、どうなるのか、という疑問が浮かびました。

これって、恐ろしいことですよね。

ある意味、行政機関よりも個人に詳しい情報を持った組織が出来てしまう可能性があるってことです。

Facebookは使わなければいいじゃん、で済ませることが出来ましたが、そうもいきません。

本名の登録が無いとGoogleの検索が使えません、と言われたら・・・

どうします？

＜追記：2011/0714 09:27＞
やはり怪しい動きになってきたようですね。

実名でなければGoogle+アカウント停止に【湯川】 : TechWave

今後のインターネットのあり方が大きく変容するかもしれません。

説明は適度に、駆け足でお届けします。
言っておきますが、これを覚えたからと言って「PHP出来ます！（ｷﾘｯ」とか言ったら鼻で笑われるレベルだということは認識しておいてくださいね。

大前提

HTML/CSSの基本的なところはわかってるものとします。FTPでアップロードするって意味さえわからない人はこのへんで勉強してください。つまり、出直してください。
あと、もっとちゃんと勉強したい人はこんな駄文を読まないほうがいいです。アシアルさんのコンテンツを読んでください。この文章の100倍素晴らしいコンテンツが満載です。

エディタ

Windowsユーザなら、標準で付いてるメモ帳を使うのはやめましょう。
PHPに限らず、プログラムを触るなら、あんなもん使わないでください。文字コードも変更できない、あんな見づらいエディタを使う意味など皆無です。
最低限、PHPのコードが色付けされる、文字コードが変更できるエディタがあったほうがいいです。
Windowsで無料なら例えば、

notepad++　←僕はこれ使ってます。
ＰＨＰエディタ
サクラエディタ
TeraPad

あたりでしょうか。Macは使ってないのでよく知りません。
今回、基本的に文字コードは全て「UTF-8N」（ボム無しUTF-8）という前提で進めます。

環境を確認

エディタで、下記のコードを「info.php」とか適当な名前で保存します。

<?php
 phpinfo();
?>

作ったファイルをアップロードして、ブラウザでアクセスすると、ずらずらと情報が表示されます。
もしこれが表示されない場合は、そもそもそのサーバではPHPが使えません。別のサーバを使ってください。
[2011/03/30 11:00追記]→コメントにてご指摘頂きました。サーバによってはこの関数を使えない場合があります。PHPが使えるかどうかは、利用しているレンタルサーバにお問い合わせください。

細かいことは置いといて、このページを名前をつけてローカルに保存してください。保存したら、サーバから「info.php」は必ず削除してください。

さて、ローカルに保存した「info.php」をブラウザで開いてみましょう。これにはサーバのいろんな情報が書かれています。

とりあえず「DOCUMENT_ROOT」だけ確認すればいいです。絶対パスと呼ばれるものです。
（「DOCUMENT_ROOT」で検索するといくつか引っかかりますが、同じ値だと思います。）

「え？絶対パスって知ってるのと違うよ？」と思った人はHTMLでの絶対パスを思い浮かべた人でしょう。
ここでの絶対パスとは、サーバのシステムルートからの絶対パスであり、Webサーバのルートからの絶対パスではありません。

FTPで見るより、もっと深い階層があるんだと思っておけばいいです。

準備はここまで。

基本的なこと

普通のチュートリアルだとここから丁寧に変数の説明とかするんですが、超ダッシュで一息にまとめます。
コーラでも一気飲みして勢いをつけたら、下記のコードを見てください。

<?php // ←phpを書くための約束。<html>と同じようなもの
# シャープがついたら、それより後ろはコメント。コメントは全部で3種類ある。
// スラッシュ2回。これもそれより後ろがコメント。
/* これもコメント。
これは囲まなきゃいけないけど、複数行コメントに出来る。 */

$hoge="test";
// ドルマークがついたら、「変数」。数値とか文字列とかを入れることが出来る。
// 変数は英数字とアンダーバーのみで、先頭は数字じゃだめよ。
// 値を入れるときには「=」を使う。
// 文字列は「""」（ダブルクオーテーション）か「''」（シングルクオーテーション）で囲まないとエラーになる。

echo $hoge; // ←脆弱なので、通常はこのようには書かない。
// 「echo」は出力して！って命令。
// HTMLみたいに、書けば表示されるもんじゃないので、表示してほしいものは命令しないといけない。
// ちなみに、$hogeには上で"test"って文字列を入れたのでブラウザでは「test」って表示されるはず

$arr=array();
$arr[0]=100;
$arr[1]=500;
$arr[2]=999;
// これは「配列」。変数のすごい版（嘘）で、値を複数入れることができる。
// array()っていうのが「これは配列だよ！」って宣言。
// [0]とか[1]とかが「キー」。中身が対応してる。

echo $arr[1];
// こうすると「500」が表示される。

// ちなみにこのように書くことも出来る。やってることは上と同じ。
$arr=array(100,500,999);

echo $arr[2];
// 何も書かないとキーは 0 から始まる。
// だから、上の中身は[0]=>100, [1]=>500, [2]=>999 ってなってる。
// これは999が表示される。

echo $arr[0]+$arr[1];
// これは100+500で600が表示される。計算できるんだね。だいたい察して。

$arr["aaa"] = "boke";
$arr["bbb"] = "aho";
// こんな感じで文字をキーにすることも出来る。

echo $arr["aaa"].$arr["bbb"];
// これは「bokeaho」と表示される。
// 2つ以上の文字列を連結するには「.」（ドット）を使う。ドットがないとエラーになる。

// 配列の中身を表示するのには、foreachが便利。
foreach($arr as $k=>$v){
  echo 'キー：'.$k.'　中身：'.$v;
}
// 中身とキーを表示する。

// 最初から決まってる特別な変数もある。
// とりあえず使うのは以下の２つ。
$_POST;
$_GET;
// ちなみにこんなふうにコードの中に変数が書いてあるだけだと何も起こらない。何も命令してないから当たり前だね。
// HTMLの<form>タグに<form method="post">って書いてあったら$_POST
// 何も書いてないか、<form method="get">って書いてあったら$_GET
// そこに、それぞれinputタグとかselectタグの中身が入ってくる。
// <input type="text" name="onamae" />ってタグの中身は
// $_POST['onamae']として入ってくる。
// $_GETはURLにくっついてくるので、直接アドレスバーに書いて、値を決めることも出来る。
// http://quoit.jp/hoge.php?aaa=99
// これは$_GET["aaa"]=99; として中身が入ってることになる。

if($hoge=="test"){
  echo $hoge;
}elseif($hoge=="piyo"){
  echo "(´ω`)";
}elseif($hoge!="ika"){
  echo "(　ﾟдﾟ)";
}else{
  echo "(´・ω・`)";
}
// if・・・は「もし・・・だったら」ってそのまんま。
// 「=」一個だけだと「値を入れる」って意味なので、「等しい」を表すには「==」って二個にする。
// だから、$hogeが「test」だったら、中身を表示。
// elseif・・・は「そうじゃなくてもし・・・だったら」なので、「test」じゃなくて「piyo」だったら「(´ω`)」を表示
// $hogeが「ika」以外だったら「(　ﾟдﾟ)」を表示。「!」は否定を表す。
// else「そうじゃなかったら」なので、上のどれにも当てはまらなかったら「(´・ω・`)」を表示

function foo($val){
  $ret=$val."オラオラオラオラ";
  return $ret;
}
// これは「関数」。
// 「機能をまとめておけるもの」かな。
// カッコ（）の中が「引数（ひきすう）」と呼ばれるもので、関数に渡される値。
// 今回は関数の中で引数の中身に文字列をくっつけて、値を返してるので、次のようになる。

$hoge="WRYYYY!";
$hoge2=foo($hoge);
echo $hoge2;

// 表示されるのは「WRYYYY!オラオラオラオラ」。
// 最初に入ってる値が、関数で処理されることで内容が変わるんだよ、ってことですね。

// phpを書くための約束。</html>と同じようなもの↓
?>

ちょっとがっつりだけど、これ読んでなんとなく分かればいいです。
分からない方はコメントくださいな。

メールフォームを作る

使えるものを作りましょう。プログラムを作る時は、まず最初に処理の流れを考えます。
まぁ今回はシンプルに。

1) データを入力する
　　　　↓
2) 送信する

というだけにしましょう。
確認画面は入れない。面倒だから。

言い忘れてたけど、PHPはHTMLと同居出来る。
つまり、こういう書き方が出来る。

<html>
<head><title>テスト</title></head>
<body>
<?php
echo "hoge";
?>
</body>
</html>

ただこれだと見づらくなるから、PHPでHTMLをテンプレートとして読み込んだりすることもあります。（例：Smarty）

今回は上のように同居させます。

さて、画面としては２つ必要です。

１）内容入力画面
２）送信完了画面

送信完了画面を表示する前に、送信処理をしなきゃいけない。
ただ、送信完了画面＝送信処理とすると、完了画面を更新（F5）したときに二重送信になってしまう。
それを避ける方法はいくつかあるのですが、今回は送信後に完了画面にリダイレクトさせる、という方法を使います。

ということで、処理の流れは、

1) データを入力する
　　　　↓
2) 入力内容を確認　→エラーがあったら入力画面に戻る
　　　　↓
3) エラーがなければ送信する
　　　　↓
4) 送信完了画面を表示する

という流れになります。

さて、いよいよ実際のコーディングへ。
まずは１）の内容入力画面。
入力できる項目は「お問い合わせ内容」だけにします。

<?php
// 先にHTMLを書いちゃうと、処理をする前に内容が表示されちゃうので、処理内容を先に書く。
// まずは何か変更があったら書き換えやすいように、設定を書きましょう。

// 宛先
$to="info@quoit.jp";
// From欄の中身
$from="info@quoit.jp";
// メールのタイトル
$title="【お問い合わせがありました】";
// [2011/03/30 11:00追記]完了画面のURL
$url="http://quoit.jp/finish.html";

// 次にデータが送られてきた場合の処理を書く。

if(isset($_POST["send"])){// データが送信されていた場合
  if(!isset($_POST["contact"])){// 本文が空だった場合はエラー文を設定 [2011/03/30 11:00修正]empty関数→isset関数に変更
    $error="本文を入力してください。";
  }else{
    // 本文の入力内容を変数に入れる
    $contact=$_POST["contact"];
    // メール送信時の日本語設定。UTF8にします。
    mb_language("japanese");
    mb_internal_encoding("utf-8");
    // ここからメール送信処理
    // PHPに初めから用意されている関数を使う。（mb_send_mail関数について詳しくはググってください）
    // この関数は、「エラーだとFALSE（否定）を返す」。
    // こういう場合、if(!mb_send_mail()){ ??; } と書くと、「??;」はエラーだった場合に実行される。
    if(!mb_send_mail(
      $to,// 宛先。
      $title,// タイトル
      $contact,// 本文（受け取った値）
      'From: '.$from."\r\n".
      'Reply-To: '.$from."\r\n".
      'X-Mailer: PHP/' . phpversion(),
      "-f ".$from
    )){
      // エラーだった場合にエラー文を設定
      $error="メールを送信できませんでした。";
    }else{
      // 問題なければ、送信完了画面（finish.html）に飛ばす
      header("Location: ".$url);
    }
  }
}

?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>メールフォームの入力画面</title>
</head>
<body>
メールフォーム

<form method="post">

お問い合わせ内容


<p style="color:red;">
<?php echo $error; ?>
</p>
<?php echo htmlspecialchars($contact, ENT_QUOTES, 'UTF-8'); ?>



<input type="submit" name="send" value="送信する" />
</form>

</body>
</html>

このファイル以外に、「送信ありがとうございました」的な内容を書いたfinish.htmlを用意しておけば完了。

どうでしょうか？簡単でしたか？

これを読んで、何となく分かった気になったら、ちなみにそれは勘違いです！

ご質問、ツッコミなどはコメントやTwitterでください。

どうぞ素敵なプログラミングライフを。

2011/03/30 11:00追記

コメントで頂いたご指摘と、はてなブックマークでご指摘頂いた部分を追記／修正しました。

2011/03/30 12:20追記

はてなブックマークでご指摘頂いた部分をちょこっと修正。

2011/03/30 15:00修正

「メール本文に対してhtmlspecialcharsをかけるべきではない」の意味がよく分かってなかったのですが、ご指摘頂いてようやく分かりました…ご指摘頂いた皆様ありがとうございます。一部修正しました。

2011/03/30 19:00修正

はてなブックマークでご指摘頂いた部分をちょこっと修正。コメントを追加。

2011/03/31 19:30修正

コメントで頂いたご指摘を元に、一部文言を修正。

TumblrやGmail、Googleリーダーなどで実装されている、「j」や「k」で次の記事／前の記事に移動できるインターフェースが便利だなーと思って、作ってみました。

デモはこちらから。
ダウンロードはこちらから。

MITライセンスですので、どうぞご自由にいじってください。商用も可です。

※全角モードになっていると動きません。

使い方は簡単なので、デモのソースを見れば分かるとは思います。
移動したい要素に同じクラス名をつけておいて、そのクラスにkeyMoveファンクションを実行するだけ。

デフォルトでは「j」で次の位置、「k」で前の位置に移動します。

オプションで、キーコードを設定すれば、違うキーで移動できます。
（キーコードはこのサイトとかで調べてみてください）
ただ、ブラウザ／OSによってキーコードって変わるみたい。
そのへんは、よしなにやってちょうだい。

例）次の位置に「a」で移動、前の位置に「s」で移動する場合

不具合、疑問などありましたらコメントにてどうぞ。

先日、かちびと.netのシロさんがFacebookでこんな発言をされているのを見て、思わずなんで？と聞いてしまいました。

InstagramのAPIって叩かれないもんなのね・・・僕が神経質なのかな

聞いてみたらとてもなるほどー！と思ったので、メモ的に記録しておきます。
ご本人の許可は頂いておりますよ。

Instagramの現在

まずそもそもこのサービスを知らない人はググってみたらいいと思います。

InstagramのAPIは、今回の公開以前から非公開APIによるデータへのアクセスは可能だったようですね。

ようやく先日公開になったものの、現在はprivate beta版（許可制）となっており、運営に申請を出さないと利用できません。

まぁまだ発展途上である、ということは前提としてあると思います。

なんで気持ち悪いのか

シロさんの発言をお借りしつつ、考えてみます。

気持ち悪いというか・・ユーザーはどこかで自分の写真が公開されてるとは思わないだろうし、Flickrみたいに著作権を決められる仕様も無いからフィルターどうすんのかなみたいな気持ち悪さかなぁ。

つまり、公開当初に前提とされていなかったAPIが公開となるにあたり、著作権の設定など、本来必要な設定がユーザ側に提供されていない、ということが問題なのですね。

ということは、自分が知らないところで自分の写真が公開される可能性もあるわけです。

すでにこんなの出てるし。
【Instagram の popular から顔写真を抽出したinstagram face】
http://instagramfaces.tumblr.com/
これ、写真撮ってる人は晒されてるの知らないでしょ。

＜追記：2011/02/28 12:06＞
※上記サービスは非公開APIを使って組まれているようです。シロさんありがとう！

つまりこういうことですよね。っていうか仕事早すぎだろ。

TwitpicなどもAPIを公開していますが、これに関しては「Twitterのサードパーティだから」という理由で、暗黙的に用途を示唆していたという特殊な状況にあったのかもしれません。

これ、何かに似てるなーと思ったら、先日mixiで問題になったメールアドレス検索の件に似てるな、と。

開始当初に予定されていなかった機能が公開されるに当たって、ユーザ側に必要な説明がなされておらず、ユーザの権利を侵害する可能性が出てくる。

今回であれば、「デフォルトではAPIでの取得が出来ない→許可したら写真単位でOK」という流れであれば問題にはならないはずですが、その説明は一切ありませんよね。

大丈夫なんでしょうか。っていうかあんまり大丈夫じゃないと思っているからこんな記事書くわけですが。

未確認だけど果てしなく不安なこと

ここからは邪推です。

InstagramのAPIドキュメントに目を通してみたところ、一つの不安が頭をよぎりました。

下記は、Instagramに写真データを要求したときに返ってくる値の例です。

{
    "data": {
        "type": "image",
        "filter": "Walden",
        "tags": [],
        "comments": {
            "data": [{
                "created_time": "1279332030",
                "text": "Love the sign here",
                "from": {
                    "username": "mikeyk",
                    "full_name": "Mikey Krieger",
                    "id": "4",
                    "profile_picture": "http://distillery.s3.amazonaws.com/profiles/profile_1242695_75sq_1293915800.jpg"
                },
                "id": "8"
            },
            {
                "created_time": "1279341004",
                "text": "Chilako taco",
                "from": {
                    "username": "kevin",
                    "full_name": "Kevin S",
                    "id": "3",
                    "profile_picture": "..."
                },
                "id": "3"
            }],
            "count": 2
        },
        "caption": null,
        "likes": {
            "count": 1,
            "data": [{
                "username": "mikeyk",
                "full_name": "Mikeyk",
                "id": "4",
                "profile_picture": "..."
            }]
        },
        "link": "http://instagr.am/p/D/",
        "user": {
            "username": "kevin",
            "full_name": "Kevin S",
            "profile_picture": "...",
            "id": "3"
        },
        "created_time": "1279340983",
        "images": {
            "low_resolution": {
                "url": "http://distillery.s3.amazonaws.com/media/2010/07/16/4de37e03aa4b4372843a7eb33fa41cad_6.jpg",
                "width": 306,
                "height": 306
            },
            "thumbnail": {
                "url": "http://distillery.s3.amazonaws.com/media/2010/07/16/4de37e03aa4b4372843a7eb33fa41cad_5.jpg",
                "width": 150,
                "height": 150
            },
            "standard_resolution": {
                "url": "http://distillery.s3.amazonaws.com/media/2010/07/16/4de37e03aa4b4372843a7eb33fa41cad_7.jpg",
                "width": 612,
                "height": 612
            }
        },
        "id": "3",
        "location": null
    }
}

あれ？Instagramって鍵付きに出来たけど、そのデータって返ってこないのかしら？

ユーザのデータに入ってるのかなーと思ってそちらも確認しましたが、それっぽいデータは返ってきませんでした。

いや、鍵付きのユーザのデータにはAPIでアクセスすら出来ない、っていうなら納得なんですけど、果たしてどうなんでしょうかねえ？

まぁ、僕はサービス開始当初のパスワード平文送信問題で嫌になって使わなくなっちゃいましたけどね。

＜追記：2011/02/28 15:00＞

ちょっと文章の書き方がまずくて話が分散しちゃったので、少々追記します。

まず、現状でもInstasramに投稿すれば、パーマリンクが生成され、Webで閲覧することが可能になります。
この時点でHTMLパースなどをすれば写真のデータを取得することは出来ますが、Instagramの「公式」として、これを認めているわけではありません。
これは「本来と違う使い方」ですね。技術的に可能かどうか、はとりあえず置いておいてください。

しかし、APIの公開はサービスの「公式」として提供されるものです。

API利用サービスの開発者は、公式からのお墨付きであるAPIを使って、Instagramのデータを利用できるにも関わらず、その利用方法や目的について、取り決めが無い。

ちなみに、Twitterならその問題は解決されているかというと、そうではありません。

Togetterにまとめられるのを嫌う方がいらっしゃいますね。
「つぶやきの所有権」についても、至る所で活発に議論されています。

上記の「Instagramから顔を集めたサービス」に許可なく写真を掲載されるのと、Togetterに許可なくつぶやきをまとめられるのは似ているなと思います。

（と、ここまで書いて、この所有権についての個々人の認識の違いで、このAPIが気持ち悪く感じるかどうかが随分変わるな、と思いました。）

利用者として自己防衛を考えるなら、どっちにしたってWeb上に公開されているデータなんですから、世界中に発信しているという意識を持っておくこと。それが怖ければWeb上に掲載なんてしないこと。

ただ、サービス提供者として、Instagramはどういう態度なのかな、と思うのです。
（先日のFacebookの件といい、最近こんなことばっか言ってますけど）

サービスを提供するだけしておいて、そこで発生する問題については放置、ってのはどうも納得いかない今日この頃です。

＜追記：2011/02/28 15:40＞

ちょっとTwitterで衝撃的な記事を見たのでご紹介。

fladdict » instagramに投稿した写真は規約上、大分権利放棄になるっぽい。

この記事を見て、ちょっとInstagramの態度がわかりました。

いいサービスかもしれないけど、僕は今後も使わないだろうな…

先日の記事がだいぶ落ち着いてきたので、そろそろ改めて僕の考えてみたいテーマについて、じっくり考えてみようと思いました。
かなり長い文章になってしまいましたので、ヒマなときにどうぞ。

テーマ – かんがえること

今回考えるのは、「インターネット上の本人確認ってなんだろう」ということにします。
インターネット上における本人確認の意義とその必要性、及び手段について考えてみたいです。

前回の議論では、結局「そんなに言うなら使わなければいいじゃない」という話にも発展しがちで、それ自体は悪いことではないのですが、自分が考えたい、問題提起したいこととは違ってしまったので、ここで改めて考えてみたいなと思った次第。

あと、僕は賢くないので、なるべくやさしい言葉で書いていきます。ご容赦を。

前提　-　「本人確認」とは

そもそも「本人確認」って言葉は何を指すのか、共通認識として持っておきたいです。
手元にある広辞苑には「本人確認」って項は無かった。ちょっと意外。（古い版だからかもしれない）
というわけで、wikipedia先生に頼ります。

本人確認 – Wikipedia

とりあえず端的な説明としては

（略）行政庁等に対して公文書の申請や公的機関などで手続きをする際（略）に、当該行政庁等、公的機関及び特定事業者が、相手方が本人であることに間違いがないことを確認することをいう。

ということらしいです。まぁ、政府機関とか特定事業者のための言葉ですね。

「本人であること」っていうのは、政府機関を対象と考えるなら「戸籍で証明された人格」と考えて差し支えないでしょう。

つまり一般的な意味での「本人確認」とは、「戸籍」＝「国民であることを証明された公文書」で、政府機関などに「私は国民の一人です。ここに登録されたこういう国民です。」と認めてもらう行為である、と言えるかと思います。

一般的な本人確認

政府機関以外にも本人確認が必要なシーンはたくさんありますね。
携帯電話を買うときだって、スポーツクラブに入会するときだって本人確認書類の提出を求められます。
それぞれ、携帯電話を買うときなら犯罪抑止、スポーツクラブなら健康上の万が一に備えて、という理由が想像できます。

認められる書類も様々ですが、免許証や保険証、住民票、パスポートなどが代表的かと思います。
共通するのは、これらの書類が、戸籍という公文書に紐づいた書類であることです。

このあたりまでは、割と共通認識として持っておいていいのかな、と考えてます。

仮に、現在一般的なこの本人確認、つまり戸籍という公文書に紐づいた書類（またはその写し）の提出によって確認を行なうことを「国民確認」と名付けます。いいですか。ダメですか。いやでも今だけなんでそう言わせてくださいおねがいします。

というわけで次にいきます。

インターネット上の本人確認の現在

さて、ここで話はインターネットに移ります。

現在、インターネット上のサービスで国民確認を実施しているのは、既にインターネット以外でサービス展開されているケースがほとんどではないでしょうか。
例を挙げるなら、インターネットバンキング、携帯電話のマイページなど。
インターネットサービスのみだと、国民確認というほどではないですが、Yahooオークションの利用時には、現住所が有効である確認が必要です。
少し特殊な例としては、「co.jp」ドメインの取得の時に必要な書類ですね。会社の登記簿とかが求められたはずです。
国民確認を厳密に実施しているサービスは、ぱっと思いつきませんでした。
もしご存知でしたらコメントにてお知らせ頂けると幸いです。

その他の多くのサービスにおいて、そのサービスを利用するときに必要とされるのは、ほとんどが「メールアドレス」ではないかと思います。
少なくとも契約しているインターネットプロバイダからメールアドレスが貸与される場合が多いですから、メールアドレスなんか持ってないよ！という人は（おそらく）いないのでしょう。

つまり、インターネットを利用する人なら、その「起点」となるメールアドレスは誰しもが持っている、という前提の元に、メールアドレスを連絡先として必須にしているところが多いようです。

（ドメインを持っている人はそちらを利用すればいいですが、そのドメインの契約にもメールアドレスは必須です。）
（僕もドメインを持ってますが、既にその起点はどこだか分からない状態…まぁどこかにあったはずです。）

その中でも、少し限定された例を挙げるなら、mixiの登録には「携帯電話の」メールアドレスが必須です。
おそらく、「携帯電話」は国民確認を経て購入されたという前提にたって、信用を高めたいのでしょう。
（初期はどこのアドレスでもよかった気がするけど、うろ覚えです。）
しかし、国民確認を実際に行なっているわけではありませんので、戸籍に紐づいた書類によって実際に確認されたわけではありませんし、書類の写しを持っているわけでもないので、直接的な信頼の根拠には成り得ないと思われます。

閑話休題。
メールアドレスを起点にした本人確認は非常に脆いものです。国民確認とは全く趣旨が違います。
むしろ方向としては、全く逆の発想であるはずです。
つまり、

　　国民確認が出来る書類を持ってきたよ　→　サービスを利用していいよ

ではなくて、

　　サービスを利用していいけど、連絡手段どうしよう　→　メールアドレスならみんな持ってるよね

という方向性の違いがあります。

さらに、「出発点」になるメールアドレスさえあれば、フリーメールアドレスなどを経由することで、非常に不透明なメールアドレスを作り出すことは難しいことではありません。

サービスによってはフリーメールアドレスでの登録を禁止しているサービスもありますが、それがどうしてフリーメールアドレスを経由していないアドレスだと証明することが出来るでしょうか？

フリーメールアドレスでもドメインは取得できます。

そう考えると、メールアドレスという存在は、本人確認の手段には成り得ない、非常に不確実な情報であることが想像できます。

メールアドレスって何の証明？

ここで、ちょっとおかしいな、と思うことがあります。

それは、多くのインターネット上のサービスがメールアドレスの存在と価値を過信していないだろうか？ということです。

メールアドレスが必須とされる理由は上記の通り「インターネットのサービスを利用する人なら必ず持っているはずだから連絡手段として使う」…のはずですが、何故メールアドレスが必要なのか、その意味が変容してきていると思うのです。

「サービスを利用する上で、本人確認の一種として、メールアドレスが必須になっています」という方向に、暗黙的に。

つまり、どこでどうなっちゃったかわからないけども、方向性が逆転してきてないか？ということです。

メールアドレスは直接的な本人確認の手段には成り得ないはずなのに、あたかも本人確認の一種であるかのように扱われていることが多いな、と思ったのです。

Twitterもメールアドレスが必須ですが、一回使ったメールアドレスは二度と使えません。

これは、そのメールアドレスに一つの「人格」を見ているからではないでしょうか？

いつの間にか出来る「人格」

さて、「人格」というキーワードが出てきましたが、このキーワードこそ、今回の記事で最も考えてみたいことなのです。
（前置きが長くてすいません）

僕はTwitterをやっていますが、目的によって使い分けるため、メインのアカウントとは別に複数のアカウントを所有しています。

普段はメインのアカウントのみ使用し、基本的に他の方とのやり取りはそこから行ないます。

さて、ここで問題です。

@yakumo_xというTwitterアカウントは、私ですか？

何アホな質問してんだこのバカと思うかもしれませんが、とても重要です。

もしこの記事を読んでいるあなたが僕と直接会ったことがある方だったら、おそらく答えは「YES」でしょう。

何故なら、僕は名刺を渡すときにアカウント名を書いて渡していますから、その人はこれは僕のアカウントである、と認識することが出来るからです。
また、Twitter上で実際に会ったときの話が出れば、ますます確信を得ることが出来るでしょう。

直接会ったことが無い方でも、Twitterでやり取りをしている人だったら、このブログを書いているのが@yakumo_xであると認識するのは難しくないと思います。

ブログを書いたときにはTwitterでも更新告知をしていますし、最近は書いた後にはてなブックマークにも登録しています。

はてなブックマークのアカウントは以前使っていたyakumo27というハンドル名ですが、このアカウント名を知っている人なら、これは@yakumo_xのブログであると、ますます確信を得ることが出来ると思います。

このように、実際に会うかどうかに関わらず、インターネット上に存在する僕は他の方から認識されています。

認識の方法はさまざまですが、これは僕ですよね？という問いを投げかけたときに「YES」と言ってくれる人は、面識があってもなくても大勢います。

これは、言い換えるなら「ネット上における人格」と言うことも出来るのではないでしょうか。

そこに国民確認は全く介在しませんし、法的な効力はおそらく無いのでしょう。
（詳しくないのでもしかしたら法的に認められているかもしれませんが）

しかし「ある人がその人の存在を認める」ことで、「その端末の向こうに人がいる」ということを認めることが出来ると思います。
少なくとも、まだ人工知能が未発達な現代においては。

インターネット上の本人確認ってなんだろう

ようやく冒頭の問題提起に戻ってきました。

メールアドレスは本人確認の手段にはなり得ず、インターネットサービスの画面から登録された情報は信用に足るものはない、という立場に立って考えます。

ならば、どういう方法で本人確認を行えば良いのでしょうか？

この問題については、各インターネットサービスの運営者が判断することであると思います。
厳密に確認を行いたいなら、当然のことですが、国民確認が必要でしょう。
それ以外の情報に、信頼できる根拠など一つもありません。

でも、少しはその信頼を持たせたい、と思うのであれば、インターネット上の人格を認めてみたらどうかな、と僕は提案します。
公私ともに親しくしているうめげんさんからの受け売りですが、「他の誰かから認識されている」ということを一つの信頼とする、という仕組みです。

障壁はもちろんあります。
一番大きな問題は、「インターネット上の人格」を認めるという発想がまだ少ないこと。

先日こんな記事を目にしました。

Business Media 誠：実名制ということは参加に責任を持つということ――ユニクロ・柳井会長がFacebookを選んだ意味

以下抜粋。

「UNIQLOOKSは、実名制のFacebookでなければできないものだ。インターネットの匿名性というものは、信用できないし、参加したと思えない。参加するということは、個人が責任を持つということ。投稿に責任を持つことによって、その情報は信用できるものになる」

なるほど、匿名は信頼できない、という主張には頷けると思いますが、「Facebookでなければ」という部分で失笑してしまいました。
実情をご存知なかったのだろうと思いますが。。
失礼ですが、正直なところ何を根拠に信頼を寄せているのか全く理解できません。

この記事の例に限らず、インターネット上の人格なんて、それこそ根拠のない、不確実な情報ではないか、と考える方は多いと思います。
実際、それは独立して存在していた場合なら、信用などあり得ないでしょう。
しかし、「他人からの承認」を前提にしていたらどうでしょうか。
悪意を持ってある人格をでっち上げる人はもちろんいるでしょうが、その情報＝他人からの承認の数が多くなったらいかがでしょうか。

少しわかりやすい例として、Twitterをあげます。

あるアカウントにフォロー／フォロワーが数千を超える単位でいたとします。
フォロー／フォロワーの比率はほぼ同じくらいで、その人は100を超えるリストに入れられています。

この人は実在すると思いますか？
僕は、実在する確率は高いと思います。

また、この人のことを自分の友人が知っていたとします。
すると、その人格の輪郭がかなり見えてきます。

しかしながら、その人がいれられているリストの名前がほぼ「bot」や「spam」だとしたらいかがでしょう。
今度は急に実在する可能性が低くなりますね。

この判断を下すことが可能なら、インターネット上の人格を認めていると考えていいと思います。
その基準になるものは、あくまで「他人からの承認」です。
先ほども書きましたが、もっと確実な情報を求めるなら、国民確認を行なうほかに解決策は存在しないと強く思います。

まとめ

かなり長々と書いてしまいましたが、僕の言いたいことは表題の通りです。

今回の記事を書くに当たって、発端となったのはFacebookのやり方でした。

「インターネットは不確実な情報しか存在しない」という前提から抜け出すなら、国民確認の実施が必須であるのは明らかです。
にも関わらず、「実名制である」とはただの主張でしかないハリボテ状態のFacebookのやり方は非常に気持ちが悪い。

それだけではなく、インターネットサービスの提供者は、利用者の存在の有無についてもう少し考えを巡らしたほうが良いのではないか。

「どうせネットだから、その情報は信用できない」という時代は確実に転換点を迎えています。

良く言われることですが、個人が情報の発信者＝メディアとなる現在、その空間で人格がどう成立するのかということを考える必要があると思います。

以上が、僕なりに考えてみたことです。

もっと高いレベルでこの問題を考えていらっしゃる方からは失笑ものかもしれませんが、もし宜しければご意見頂けますと幸いです。