Facebook開発者向けドキュメントの日本語訳とTips

http://developers.facebook.com/docs/ に記載されているdocumentationの和訳と、調べていて分かったノウハウを紹介します。
Life is tough, so are we.
ドキュメント全体の目次はこちら
Facebook関連情報はFacebookページで共有しています。

新ニュースフィード対応時の画像サイズ

newsfeed_games

ニュースフィードのリニューアルにより、今後はより大きなサイズでニュースフィード上に画像が表示されることになります。アプリからの画像投稿としては、ウォール投稿、アルバムへの投稿、Open Graphアクション投稿などが挙げられますが、新しいニュースフィードに最適化するため、画像投稿時の仕様が一部変わります。また、OGPが設定されたwebページのシェアでもog:imageに指定した画像が利用されるため、その画像についても新しい仕様に合わせるのがいいかもしれません。

新仕様

最低200 x 200pxで、最適なのは600 x 600px以上となります。200 x 200pxに満たない場合、新しいニュースフィード上には表示されません。長方形の画像はクロップされます。
また、以下の制限も適用されます。
画素数4メガピクセルまで
容量5MBまで
ファイル形式jpg, png, gif, bmpのみ

元記事:Platform Updates: Operation Developer Love


Auth Dialogの不具合と今後の対応

今日の昼過ぎ、FacebookのAuth Dialogでエラーが発生して、ユーザがFacebook連携アプリに対してログインできなくなるという騒ぎがありました。これは、Augh Dialogの旧URLを新しいものへとリダイレクトする処理でFacebook側にバグがあった為で、現在は復旧しています。

不具合の詳細

詳細についてはこちらのバグ報告が詳しいです。
要点としては、旧URLへユーザを誘導した場合、新しいAuth Dialog URLに対してリダイレクトされるべきところが、クエリパラメータが間違った状態でリダイレクトされるという不具合です。

旧Auth Dialog URL:
https://graph.facebook.com/oauth/authorize?client_id=147366981996453&redirect_uri=http%3A%2F%2Ffacebook.com%2F

不具合発生時のリダイレクト先:
https://www.facebook.com/dialog/oauth?app_id=147366981996453&display=page&next=http%3A%2F%2Ffacebook.com%2F&response_type=code&fbconnect=1

正しいリダイレクト先:
https://www.facebook.com/dialog/oauth?client_id=147366981996453&display=page&redirect_uri=http%3A%2F%2Ffacebook.com%2F&response_type=code&fbconnect=1
この不具合が発生している間、ログインを試みると以下のような画面が表示されていました。


843760_604764966205477_31010706_o

暫定対応

これは旧URLからのリダイレクト処理の問題だったため、移行後の新しいURLでAuth Dialogを開けば防ぐことができました。Oklahomerページで紹介した対応方法がそれです。
これを紹介した段階では、バグレポートに対する公式見解は以下のようなものでした(いまはステータスが更新されたため、右上のToggle 1 older responsesをクリックしないと表示されません)。
Please note that the graph.facebook.com/oauth/authorize endpoint is deprecated in favor of www.facebook.com/dialog/oauth and that this should always be used to avoid issues.

和訳:
graph.facebook.com/oauth/authorizeのエンドポイントは www.facebook.com/dialog/oauth への移行のため廃止予定となっていることに注意してください。
その後、Facebook側の修正が完了し、旧URLからも正しくリダイレクトされるようになり、不具合発生前の状態に戻りました。

今後の対応

先ほど暫定対応として紹介しましたが、FacebookのAuth Dialogドキュメントでは、すでに旧URLでの解説はされず、完全に新URLでのみ解説されています。リダイレクトの不具合が解消されたとは言え、今後同じような不具合を避けるためにも、早めに新しい形式に対応した方が良いでしょう。詳しくは「Open Graphに触れる 2:ユーザ認証と権限の認可」を参照してください。また、最近のAuth Dialogとパーミッション周りの仕様変更については「認可ダイアログとパーミッションの仕様変更」をご覧ください。

Graph Search発表内容の和訳

現地の2013/01/15、FacebookがGraph Searchを発表しましたので、その内容を紹介します。
以下、Introducing Graph Search Betaの和訳です。




Facebookのミッションは「世界をよりオープンでつながりのある場にする」ということで、それを達成する主な方法は、他の人々や物事との繋がりを可視化するツールを提供することです。私たちは、そのマップをグラフ(the graph)と呼んでいます。これは巨大で、新しい人々、コンテンツ、それらの持つ繋がり(コネクション)により、絶えず拡大しています。すでに10億人以上の人々、2400億枚以上の写真、1兆のコネクションが存在します。

ashx

今日、コネクションを辿り、それをより価値あるものにする新たな方法を発表します。Graph Searchと呼ばれるもので、βとして今日からスタートします。

Facebookが公開された当初の利用方法は、人々を見て回り、知り、そして新たなコネクションを作るというものでした。


ashx


Graph Searchはより大きな検索バーとして各ページの最上部に表示されます。あなたが何かを検索すると、その検索語は検索結果を表示するだけではなく、ページのタイトルとしても機能します。あなたはそのタイトルを編集することができ、あなたや友だちがFacebook上で共有したものごとの閲覧をカスタマイズできます。

ashx



Graph Searchとweb検索は全く異なるものです。web検索はキーワード(たとえばhip hop)を用いるようにデザインされていて、それらのキーワードと最も関連性の高いものを返します。Graph Searchは、語句を接続(たとえば、「ジェイ・Zが好きなニューヨークの友だち」)することで、人々、場所、写真、もしくは他のコンテンツを返します。ですので、用途が全く違うと信じています。

web検索とのもうひとつの大きな違いは、Facebook上の全てのコンテンツは独自に閲覧権限を持っていて、ほとんどのコンテンツは一般公開されていないということです。私たちはGraph Searchの実装を始める前からプライバシーについて考慮していて、プライバシーや閲覧者について配慮しています。これを使うことで新しい物事を発見するのが一層簡単になりますが、Facebook上で閲覧できたもののみが表示されます。

今現在、私たちはGraph Search開発の初期のステップに居ます。今のところ英語でのみ利用可能で、Facebook上のコンテンツのうち一部のみを検索できます。投稿やOpen Graphアクション(たとえば、音楽を聴く)はまだ未対応です。今後数ヶ月のうちにこれらに対応します。

この初期バージョンのGraph Searchは4つの領域にフォーカスしています。すなわち、人々、写真、場所、そして興味の対象です。

人々: 「わたしの町に住む人々」「私と同じ出身地で、ハイキングが好きな人」「ヨセミテ国立公園に行ったことがある、友だちの友だち」「スキーが好きでサンフランシスコに住んでいるソフトウェアエンジニア」「私が好きなものごとが好きな人々」「近所に住んでいるテニス好きな人々」

Photos:「私の好きな写真」「私の家族の写真」「1999年以前の友だちの写真」「ニューヨークで撮影された、私の友だちの写真」「エッフェルタワーの写真」

Places: 「サンフランシスコのレストラン」「私の家族が訪れた町」「私のインド人の友だちがいいね!したインド料理の店」「私の友だちが訪れたイタリアの観光地」「シェフがいいね!したニューヨークのレストラン」「私の友だちが訪れた国々」

Interests: 「友だちの好きな音楽」「私と同じ映画が好きな人の好きな映画」「私の友だちが話す言語」「友だちの友だちがプレイした戦略ゲーム」「映画監督がいいね!した映画」「CEO達が読んだ本」

ashx

Graph Search βは今日から始まります。www.facebook.com/graphsearchへ行って待機リストに登録してください。

Graph Searchがどう使われ、どう改善できるかを見るため、ローンチは遅めのペースで進めます。

あなたのフィードバックを楽しみにしています。そして、the graphの探検を楽しんでください。

__

Additional Media Resources:

Graph Searchの詳細はこちら www.facebook.com/graphsearch

Graph Searchとプライバシーについてはこちら www.facebook.com/graphsearch/privacy

関連動画をダウンロードするにはこちら click here.

スクリーンショットを入手するにはこちら click here.


Frequently Asked Questions

Graph Searchって何ですか?
Graph Searchとは、Facebook上のあなたと関連のある人々、写真、場所、興味の対象を探す手段です。

Graph Searchは何に便利なんですか?
他者を見つけ、彼らについて学び、より繋がりを広めたり、写真を探したり、地元のレストランなどの場所を探したり、音楽、映画、本、その他の共通の趣味を見つけることを助けます。全ての検索結果は、関係性やコネクションの強さに従って固有なものとなります。

何を検索できますか?
人々、写真、場所、興味の対象を検索できます。

どうやって検索したら良いですか?
ページ最上部の青いバーに入力してください。入力を始めると、ドロップダウンでサジェスチョンが表示されます。ページ右側のツールを用いて再検索することもできます。

例を示すと...
· 近所に住んでいるテニス好きな人
· 1990以前の写真
· ニューヨークの友だちの写真
· 私の友だちがいいね!したパロアルトの寿司屋
· 私の友だちが訪れたイタリアの観光地

リリースの計画は?
Graph Searchはβ版です。そのため、アメリカ英語を使う限られたユーザにのみ公開されています。

どうしたら利用できますか?
www.facebook.com/graphsearchで待機リストに登録してください。

これによって私のプライバシー設定が変わることはありますか?
いいえ。Graph Searchはあなたのプライバシーに従います。あなたが共有されたコンテンツのみ検索できます。

私に関連する、どのタグ、場所、写真が出るかを制御するには?
検索結果に表示される、タグ、写真、位置情報付き投稿を制御するには、アクティビティログをご覧ください。

Open Graphに触れる 3:ユーザのウォールへの投稿

Open Graphに触れる 2:ユーザ認証と権限の認可」ではAuthダイアログを用いたユーザ認証と権限認可について紹介しました。今回は、そこで許可された権限を用いて、ユーザ自身のウォールにステータス投稿や画像投稿を行う方法を紹介します。

テストユーザを作成する

Facebookは実名で1個だけアカウントを作るよう強制しているため、アプリのテスト用にサブアカウントを作成することができません。かと言って自分自身のウォールを利用して投稿を試していたりすると、連投し過ぎてスパム認定されてしまうこともあります。
そのため、アプリからユーザのウォールに投稿したり、その投稿が友だちからどう見えるかを試すには、アプリ専用のテストユーザの作成と、テストユーザ同士の友だち関係の作成が必要となります。アプリ専用のテストユーザであれば、試しに連投してしまってもスパム認定されることもありません。詳細や利用上の制限などは、Test Usersドキュメントの和訳をご覧ください。
ここでは大まかな流れとして、以下の2種類の方法を紹介します。

管理画面から作成する

まず、「Open Graphに触れる 2:ユーザ認証と権限の認可」で作成したアプリの管理画面に行きます。「設定を編集」を選択します。

app_setting

左に設定メニュー一覧が現れるので「権限」を選択します。

permissions

User & Friend PermissionsやExtended Permissionsといった入力欄が現れます。要求する権限(パーミッション)の種類によってこの項目を使い分けるのですが、今回はユーザ自身のウォールへの投稿のため、User & Friend Permissionsの欄にpublish_actionsと入力して保存します。アプリ管理画面からテストユーザを作成する場合、作成されるユーザは、ここに入力した権限を許可した状態で作成されます。
なお、権限の種類と区分の詳細は、Permissionドキュメントの和訳をご覧ください。
publish_action
保存したら、左ナビゲーションにある「開発者の役割」ページを選択します。下の方にある「テストユーザー」の項目の「作成」をクリックします。
test-user

作成用のダイアログが開き、作成するテストユーザの数、権限を認可した状態で作成するか、リアルタイムフィードを有効にするか、18際未満かなどの選択肢が表示されます。ここでは「Number to Create」に2を入力し、Authorize this Appをチェックします。これで、権限を認可した状態(Authダイアログを完了した状態)のユーザを2人作成できます。
select
「作成」をクリックするとテストユーザが作成され、以下のキャプチャのようにユーザが追加されます。

created_user

右にある「変更」をクリックするとテストユーザの一覧が現れるので、両方のアカウントをチェックして「Make Friends」をクリックします。

friends
これで、テストユーザ2人と、それらテストユーザ同士の友だち関係を作成できました。
もう一度「開発者の役割」ページに戻って、「切り替える」を選択すると、作成したテストユーザでのログイン状態に切り替わります。
switch
この状態で友だち一覧を見れば、もう一方のテストユーザが友だちになっていることが分かります。

test-user-login

APIで作成する

テストユーザをGraph APIを使用して作成することも可能です。この場合、まずはアプリ管理用のアクセストークンを取得し、そのトークンを用いてアプリ専用のテストユーザを作成することになります。アプリ管理画面から作成する方が手軽な反面、Graph APIを通じて作成する方が細かにカスタマイズできます。例えば、どの権限を許可した状態のユーザを作るか細かく指定できるため、Authダイアログで要求する権限のうち一部だけを許可したユーザを作成するなどが可能です。
アプリのアクセストークンを取得する

app_setting2

アプリ設定画面のアプリIDとシークレットキーを見つつ、以下の要領で取得できます。
curl -X GET \
'https://graph.facebook.com/oauth/access_token?client_id=1234567890&client_secret=XXXXXXXXXXXXXXXXXXX&grant_type=client_credentials'
返される値は以下の通りです。
access_token=1234567890|ku1NaUQ_XXXXXDDEEEEEEEE
この値がアプリ用のアクセストークンとなります。
Graph APIでのテストユーザ作成
取得したアクセストークンを用いてユーザを作成します。エンドポイントは /APP_ID/accounts/test-users となります。このとき、installedはアプリを認可済か否か、permissionsは認可するパーミッションを指します。今回の場合、アプリを利用中のユーザなのでinstalled=true、ウォール投稿を試したいのでpublish_actions=publish_actionsを指定します。
curl -X POST \
     -F 'installed=true' \
     -F 'permissions=publish_actions' \
     -F 'access_token=1234567890|ku1NaUQ_XXXXXDDEEEEEEEE' \
     https://graph.facebook.com/1234567890/accounts/test-users
返り値は以下の形式です。
{
"id":"10000111111111",
"access_token":"YYYYYYYYYYYYYYYYYYY",
"login_url":"https://www.facebook.com/platform/test_account_login.php?user_id=10000111111111&n=JgDChysa",
"email":"khsmpyd_baowitz_22222222\u0040tfbnw.net",
"password":"516144431"
}
ここで返されたemailとpasswordを用いて、facebook.comのログイン画面からテストユーザとしてログインすることもできますし、login_urlをブラウザのアドレスバーに直接入力してログインすることもできます。
この手順を2回繰り返すことで、テストユーザを2人作成します。
Graph APIでテストユーザ同士を友だちにする
テストユーザ同士であれば、APIで友だち申請とその承諾ができます。形式は以下の通りです。
curl -X POST \
-F 'access_token=USER1_ACCESS_TOKEN' \
https://graph.facebook.com/USER1_ID/friends/USER2_ID
これで、USER1からUSER2に対して友だち申請を送ることができます。その後、USER1とUSER2を入れ替えてもう一度実行することで、申請は承諾されて友だち関係が成り立ちます。
実際には以下のようになります。申請も承諾も、成功した場合の返り値はtrueです。
curl -X POST \
-F 'access_token=YYYYYYYYYYYYYYYYYYY' \
https://graph.facebook.com/10000111111111/friends/10000111111112
curl -X POST \
-F 'access_token=ZZZZZZZZZZZZZZZZZZZ' \
https://graph.facebook.com/10000111111112/friends/10000111111111

Facebook::OpenGraphを使う

拙作のFacebook::OpenGraphは、既存のFacebook::Graphよりも手軽に新機能(最近だとfield extensionbatch requests)や仕様変更(各Open Graphオブジェクトの型変更など)を試せるようにしたいという考えから作ったものです。新機能や仕様変更の試しやすさに重点を置いているため、それに欠かせないテストユーザ作成の機能も実装されています。
以下のように、create_test_usersメソッドに対して各テストユーザの設定を配列で渡します。内部的にはバッチリクエストという機能を使っているので、複数テストユーザの作成であっても1度のHTTPリクエストで済ませることができます。
#!/usr/bin/env perl
use warnings;
use strict;
use lib 'lib';
use Facebook::OpenGraph;
use Data::Dumper;

my $fb = Facebook::OpenGraph->new(+{
    app_id => 111111111111111, # アプリケーションID
    secret => 'aaaaaaaaaaaaaaaaaaaaaaaa', # アプリのシークレットキー
});
$fb->set_app_token; # アプリのアクセストークンを取得、セット

my $res = $fb->create_test_users([
    +{ # ユーザ1の設定
        installed   => 'true', # アプリを認可した状態
        permissions => [qw/publish_actions/], # 認可したパーミッションはpublish_actionsのみ
        locale      => 'en_US', # ガイジン
    },
    +{ # ユーザ2の設定
        installed   => 'true', # アプリを認可した状態
        permissions => [qw/publish_actions email read_stream/], # 認可したパーミッションは3つ
        locale      => 'ja_JP',  # ちょんまげ
    }
]);
warn Dumper $res;

__END__
返り値は以下のようになります。
$VAR1 = [
          { # ユーザ1
            'email' => 'szmlpoe_shepardsen_1234123@tfbnw.net',
            'password' => '1234566',
            'login_url' => 'https://www.facebook.com/platform/test_account_login.php?user_id=10000509494567&n=Sg6K0r1zDhvG4hw',
            'access_token' => 'AAAD8v8zXn9oBAKASdfasfAFSdeSDFDgrehtrsh',
            'id' => '10000509494567'
          },
          { # ユーザ2
            'email' => 'uvjffnp_qinberg_1234123412@tfbnw.net',
            'password' => '432532452',
            'login_url' => 'https://www.facebook.com/platform/test_account_login.php?user_id=10000508033123&n=tvVBoHap3xqIxvN',
            'access_token' => 'AAAD8v8zXn9oBADFSDFcavklajdraDFDSDF',
            'id' => '10000508033123'
          }
        ];
これで、2つのテストユーザが作成されました。
その後は、それぞれのユーザIDとアクセストークンから友だち関係を設定します。

$fb->{access_token} = 'AAAD8v8zXn9oBAKASdfasfAFSdeSDFDgrehtrsh'; # ユーザ1のトークン
my $res1 = $fb->post(
    sprintf('/%s/friends/%s', 10000509494567, 10000508033123), # ユーザ1からユーザ2に友だち申請
);
warn Dumper $res1;
# $VAR1 = {
#           'success' => 'true'
#         };

$fb->{access_token} = 'AAAD8v8zXn9oBADFSDFcavklajdraDFDSDF'; # ユーザ2のトークン
my $res2 = $fb->post(
    sprintf('/%s/friends/%s', 10000508033123, 10000509494567), # ユーザ2がユーザ1の友だち申請を承諾
);
warn Dumper $res2;
# $VAR1 = {
#           'success' => 'true'
#         };
これで友だち関係の作成まで完了です。

与えられたパーミッションを確認する

ユーザがアプリに対して認可したパーミッション一覧を取得する方法は以下の2つです。
ユーザのアクセストークンで/me/permissionsにアクセス、もしくはアプリのアクセストークンで/USER_ID/permissionsにアクセスすることになります。
ユーザのアクセストークンは有効期限が定められているのに対し、アプリのアクセストークンには有効期限がないことを考えると、アプリのトークンを用いる場合の方が楽かもしれません。
curl -X GET \
      'https://graph.facebook.com/me/permissions?access_token=USER_ACCESS_TOKEN'
curl -X GET \
      'https://graph.facebook.com/USER_ID/permissions?access_token=APP_ACCESS_TOKEN'
返り値は以下のようなJSONです。
{
   "data": [
      {
         "installed": 1,
         "publish_actions": 1
      }
   ],
   "paging": {
      "next": "https://graph.facebook.com/10000509494567/permissions?access_token=AAAD8v8zXn9oBAKASdfasfAFSdeSDFDgrehtrsh&limit=5000&offset=5000"
   }
}
Facebook Platformが提供する全部のパーミッションを許可しても5000件を越えることはないので、pagingは無視して問題ありません。 installedはアプリを認可しているか否か、他のpublish_actions:1などは、パーミッション名と認可済か否かを示します。このサン プルの場合、publish_actionsが認可されているので、このユーザの代理としてウォール投稿できることが分かります。
本番環境では、ユーザ自身がfacebook.com上の管理画面から認可を取り消してしまうこともあるので、ログイン時や、設定画面で機能のOn/Off切り替え時などに適宜チェックしましょう。

ウォール投稿する

方法

アプリからのウォール投稿で最も一般的なのは、リンク付きの投稿でしょう。その場合、投稿方法は以下のようになります。ここでは、先ほど作成したユーザ1のアクセストークンを用いています。
messageは投稿時の文言、linkは投稿するURLです。
curl -X POST \
       -F 'access_token=AAAD8v8zXn9oBAKASdfasfAFSdeSDFDgrehtrsh' \
       -F 'message=要チェック' \
       -F 'link=http://facebook-docs.oklahome.net' \
       https://graph.facebook.com/me/feed
返り値は作成されたウォール投稿のオブジェクトIDとなります。
{"id":"10000509494567_131408663691711"} # USER_ID _ 投稿ID
テストユーザ作成時に発行されたログインURL、もしくはメールアドレス+パスワードを利用してログインすれば、そのユーザのウォールに対して投稿されていることが分かります。
wall_post
また、このテストユーザと友だち登録したユーザでログインすれば、ニュースフィードに投稿が流れてくるのを確認できます。
wall_post2
ユーザ1の作成はlocale=ja_JPを指定したので日本語インターフェイスになっているのに対し、ユーザ2の作成ではlocale=en_USだったために英語インターフェイスになっています。

Facebook::OpenGraphを使う

#!/usr/bin/env perl
use warnings;
use strict;
use lib 'lib';
use Facebook::OpenGraph;
use Data::Dumper;

my $fb = Facebook::OpenGraph->new(+{
    app_id => 111111111111111, # アプリケーションID
    secret => 'aaaaaaaaaaaaaaaaaaaaaa', # アプリのシークレットキー
});

# ウォール投稿はアプリのアクセストークンでも可能
# 有効期限のチェックが不要なので、アプリのトークンをセットして使っている
$fb->set_app_token; 

my $res = $fb->publish(
    '/10000509494567/feed', # /me/feedの代わりにユーザIDを指定。
    +{
        link    => 'http://facebook-docs.oklahome.net/',
        message => '要チェック',
    }
);
warn Dumper $res;
# $VAR1 = {
#           'id' => '10000509494567_201079000035929'
#         };

__END__

画像を投稿する

方法

画像投稿の際のエンドポイントは /USER_ID/photos となります。今回の場合はユーザのアクセストークンが必須となり、アプリのトークンで投稿しようとすると、以下のようなエラーが返されます。

{"error":{"message":"A user access token is required to request this resource.","type":"OAuthException","code":102}}
sourceにはファイルのパス、messageにはウォール投稿時と同様に投稿時の文言を指定します。
curl -X POST \
       -F 'source=@/path/to/file.png' \
       -F 'access_token=AAAD8v8zXn9oBAKASdfasfAFSdeSDFDgrehtrsh' \
       -F 'message=Facebook メッセンジャー!' \
       https://graph.facebook.com/me/photos

返り値は以下のようになります。
{"id":"104219756424742","post_id":"10000509494567_104219509758100"}
テストユーザのタイムラインを開くと、画像が投稿されているのが分かります。

post_photo


この際、特に投稿先のアルバムを指定していないため、アプリ名+Photosという名前のアルバムが作成され、そこに画像は投稿されます。

album

Facebook::OpenGraphを使う

Facebook::OpenGraphの場合、sourceパラメータが指定されていれば、画像もしくは動画の投稿と判断してcontent-typeを適切に変更します。また、動画の投稿( /OBJECT_ID/videos )であれば、自動的に投稿先ドメインをgraph-video.facebook.comへ置き換えます。
my $fb = Facebook::OpenGraph->new(+{
access_token => 'AAAD8v8zXn9oBAKASdfasfAFSdeSDFDgrehtrsh', # ユーザのアクセストークン
});
my $response = $fb->publish(
'/me/photos',
+{
source => './t/resource/sample.png', # ファイルのパス
message => 'Facebook メッセンジャー!' # 投稿メッセージ
}
);

まとめ

今回は、「Open Graphに触れる 2:ユーザ認証と権限の認可」で取得した権限を使って、ユーザ自身のウォールに投稿したり、画像を投稿する方法を紹介しました。その過程で、テストユーザの作成方法や、与えられた権限の確認方法なども紹介しましたが、これらはFacebookアプリを開発する上でとても重要なものです。
テストユーザの利用は、アプリをスパムアカウント認定されないためにも重要ですし、面倒くさがって自分の本アカウントを使っているうちに誤投稿するのを防げます。また、与えられた権限の確認は、必要な権限を与えられていない場合は「FBに投稿」のボタンを隠すなど、ユーザの混乱をなくす上でも重要ですので、これらの機能も是非活用してみてください。

認可ダイアログとパーミッションの仕様変更

概要

このエントリでは、「Providing People Greater Clarity and Control」で紹介されている仕様変更を紹介します。
今回の変更は、パーミッションの煩雑さを解消し、ユーザ体験の向上を狙うものです。認可ダイアログやパーミッションを簡略化する為の仕様変更が伴うため、既存のアプリの開発者は早めに対応する必要があります。ややこしい変更ですが、認可ダイアログは潜在ユーザを実際のユーザへと変える大事なステップです。この仕様変更に適切に対応することで、アプリ開発者にとっても利益があります。

1. 文言が適切なものに

no_scope

これまで認可ダイアログで表示されていた「Basic Info(基本データ)」という項目は「public profile and friend list(一般公開された情報と友だちリスト)」という名称に変わり、より適切に実態を表すようになります。これはユーザがアプリ利用を開始する段階で必ず提供される情報である為、開発者が特に対応する必要はありません。「へー、分かり易くなったね、というか今まで曖昧だったよね」と受け流して大丈夫です。

2. 投稿系のパーミッションが1つに

今まで

アプリがユーザの代理としてFacebookに投稿を行う場合、ユーザから投稿用の権限を認可してもらう必要がありました。認可してもらう権限はパーミッションと呼ばれ、どのパーミッションをユーザから認可されるかによって、アプリにできることは変わってきます。たとえば、ユーザのウォールやタイムラインに投稿するならばpublish_actions、友だちのウォールなどに投稿するならばpublish_stream、チェックインするにはpublish_checkins、という具合にです。

以下のキャプチャは、publish_checkinsパーミッションを要求したときの認可ダイアログです。
with_publish_checkins

また、以下のキャプチャはpublish_actionsとpublish_checkinsパーミッションの両方を要求した場合です。
with_publish_actions_and_checkins
要求した2つのパーミッションがそれぞれ表示されているのが分かります。それぞれの項目右に「X」があるのを見ると分かる通り、ユーザは1つ1つの投稿系パーミッションを拒否することができました。

変更後

これら3つのパーミッションは今後は1つに統合され、ユーザとしては「Facebookに対して投稿するか否か」のみを気にすれば良いことになります。3つが統合されるため、3つのうちどれを要求しても、「Example App would like to post to your friends on your behalf.(Example Appがあなたにかわって友だちのウォールに書き込むことを許可します。)」という文言で表示されることになります。

まだ移行中のため、本家開発ブログで公開されていたキャプチャを紹介します。
latest

統合後はpublish_actionsパーミッションのみをユーザに対して要求することが推奨されています。

注意点

「Example App would like to post to your friends on your behalf.(Example Appがあなたにかわって友だちのウォールに書き込むことを許可します。)」という文言に変わると本家ブログでは紹介されていますが、友だちのウォールへの投稿に関して理解しておかなくてはならない点が1つあります。
それは、2013年2月13以降、ユーザの友だちのウォールに対しての投稿が禁止される点です。
今現在は移行期間のため、まだ友だちのウォールへも投稿できます。そのため、3つのパーミッション統合により、ユーザ自身のウォールにも投稿できる(publish_actions)し、ユーザ自身としてチェックインもできる(publish_checkins)、さらにユーザの友だちのウォールへも投稿できる(publish_stream)ということで、3つの権限のうちで一番影響力の強い権限に文言を合わせていると理解しています。2/13に友だちのウォールへの投稿が禁止されれば、この文言も変更されるのでしょう。

友だちのウォールへの投稿禁止については、「Open Graphアプリの規制強化 & 友だちのウォールへの投稿禁止」と「Open Graphアプリとウォール投稿が一部規制される詳細」を参照してください。
また、publish_actionsやpublish_streamの違いについては、「Facebook Night vol.7 発表内容まとめ 1:publish_streamとpublish_actions」を参照してください。

3. 認可ダイアログが2段構成に

さらに本家ブログ記事では、パーミッションの種類によって認可ダイアログが2段構成に分けられることが紹介されています。以下の通り、読み込み系のパーミッションと書き込み系のパーミッションで二段構成になるようです。
read write final
見て分かる通り、左側の1ページ目では読み込み系のパーミッション(一般公開されたプロフィール情報、友だちリスト、メールアドレスの取得)、右側の2ページ目では書き込み系のパーミッション(友だちのウォールへの投稿)に別れています。
ただし、認可ダイアログの2段構成はこれまでも同様に存在していました。詳しくは「Facebook Night vol.7 発表内容まとめ 2」をご覧ください。このエントリでは、kloutのケースを例に、必要なときに必要なパーミッションのみを要求する方針も紹介しています。ユーザ登録時にはサービス利用上の最小限のパーミッションのみを要求し、ユーザが利用したい機能によって都度パーミッションを追加要求するという方法です。これにより、利用しない機能の為のパーミッションまで要求し、ユーザに不信感を抱かれてしまうという事態を避けられます。
また、関連エントリとして「Open Graphに触れる 2:ユーザ認証と権限の認可」もオススメです。
さらに次のステップとして、認可ダイアログの完了時にユーザがどのパーミッションを許可したのかを把握したり、ユーザがfacebook.comの管理画面からパーミッションを剥奪してしまった場合にアプリ側で把握する手段を「Facebook Night vol.7 発表内容まとめ 3:Batch RequestとReal-time Update API」で紹介しています。

まとめ

以上が、「Providing People Greater Clarity and Control」で紹介されている内容です。パーミッションの項目や認可ダイアログの構成など諸々の仕様変更がありますが、どれも私がFacebook Night vol.7で発表した内容の延長だと感じています。つまり、認可ダイアログ自体の仕様やパーミッションの仕様を理解し、ユーザ登録ステップを簡潔にすることで、認可ダイアログのコンバージョンを底上げすることができるというものです。
認可ダイアログに関しては、ユーザ登録部分の実装後は振り返るキッカケがなかなかありませんが、この仕様変更はユーザ登録のステップを見直す良い機会だと思います。
記事検索