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

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

Open Graphアプリの規制強化 & 友だちのウォールへの投稿禁止

今日公開された公式ブログ記事で、Open Graphアプリの大きな方針転換が発表されています。既存のアプリへの影響も大きい類のもので、おそらく一番問題となるのは「Deprecating features that lead to low quality user experiences(質の低いユーザ体験へと導く機能の廃止)」と題された項目です。ここでは、既存のアプリでは許可されている、もっと言うと、去年のf8での新Open Graph公開時に推奨された「摩擦の無い共有(frictionless share 意訳:手間がかからない簡単なライフログ共有)」を取り締まるような正反対の制約が発表されています。以下、要点をまとめてみます。

補足記事を書きました。

frictionless shareを部分的に廃止

自分が聴いている音楽を自動的に共有するようなアプリは、何をいつ共有されるか分かっている状態では優れたユーザ体験を創り出しますが、ユーザが予測のつかない形で共有してしまうと人々を混乱させてしまいます。

今日以降は、そういったアプリは申請を通らなくなります。ただし、ビルトインアクションを用いて自動的にユーザアクションを共有するアプリは例外です。つまり、現段階でFacebookによって用意されている以下のビルトインアクションを用いた自動共有アプリは今後もOKとなりますが、それ以外は今日を境に申請が通らなくなります。

  • Like - 何かをいいねする
  • Follow - ユーザのフォロー
  • Listen - 歌を聴く
  • Read - 記事を読む
  • Watch - ビデオ、動画、テレビ番組の視聴

ということは、ソーシャルリーダーはビルトインのreadアクションを用いるのでOKでも、グラビアのプロフィールを見ただけで「欲情した」というカスタムアクションを共有するアプリは、今日以降はアウトになるということです。

既にカスタムアクションでこのような実装をしているアプリに関しては、今後90日以内に何らかのビルトインアクションへ移行する必要があります。代替策として使えるビルトインアクションが見つからない場合には、今までとは異なるユーザ体験を実装することが推奨されています。

友だちのウォールへの投稿廃止

publish_streamパーミッションを取得して友だちのウォールへ投稿するのはネガティブなフィードバックが多い、という理由からこの機能は廃止されます。ユーザに対して友だちのウォールへ投稿させたい場合には、今後はfeed dialogを使うことになります。ただし、タグ付け機能を用いて友だちをタグ付けた場合には、その投稿は友だちのタイムラインにも表示されます。すでにこのような機能を実装している場合は、frictionless shareと同様、90日以内の改修が必要になります。

まとめ

新Open Graph公開時は、
  1. add to timelineプラグインでの自動タイムライン投稿
  2. recommendation pluginのソーシャルリーダー機能
  3. Requst Dialogのfrictionlessリクエスト
などで摩擦の無い共有を強調していたため、一度は撤廃したBeaconが再来したかのように見えましたが、やはりユーザや友だちのウォール/タイムラインへむやみに投稿するのは反発が多く、それらの機能が制限されるようです。それにしても、既存のアプリに対しては90日の猶予が与えられているとは言え、新規申請分に関しては記事公開当日から規制されるというのは厳しいですね。

Facebook今昔物語2006 ~ そしてみんなストーカーになった ~

Facebook今昔物語 ~あのころ僕らはリア充だった 2005夏~」に続き、今回は2006年当時のFacebookの話です。当時のユーザ目線でのエントリを書くのが目的ではありますが、APIが公開された年だということ、私自身が休学していてFacebookへのログイン頻度が落ちていたことから、ユーザ目線から逸れたところが出てきます。前エントリで紹介した通り、クラスやカフェテリアで日常的に関わる友達との伝言板としてウォールを利用するのが中心だったため、休学や長期休暇で大学を離れるとログイン率が下がるというのが、当時の特徴だったようです。Facebookの機能追加や大学追加でさえ、新学期が始まる9月を目安にしていたというところからも、当時のFacebook利用が大学生活の延長上にあったことが分かります。

199442_4351781439_9284_b

開発者プラットフォーム公開

開発者プラットフォームがβリリースされたのが8月15日でした。この当時サポートされていたメソッド一覧は以下の通りで、今のドキュメントの膨大さを考えると、とてもシンプルです。
  • auth.createToken
  • auth.getSession
  • events.getInWindow
  • friends.get
  • friends.getAppUsers
  • friends.getTyped
  • friends.areFriends
  • messages.getCount
  • photos.getAlbums
  • photos.getCommentCount
  • photos.getFromAlbum
  • photos.getOfUser
  • pokes.getCount
  • session.ping
  • users.getInfo
friends.getTyped は social link タイプと呼ばれるものを指定することで特定の繋がりを持つ友人を取得することができたらしいのですが、COURSE を指定すると同じコースを履修した友達を取得できるなど、ここにもコースマッチの名残が見えます。
また、見ると分かる通り、ウォールへの投稿やアプリリクエスト送信などのニュースフィード配信に関する機能が提供されていません。アプリ上での行動をニュースフィードで拡散するのがアプリを広める上で効果的ですが、ニュースフィードが公開されるのはこの1ヶ月後です。当然のことながら、この段階ではAPI公開はそこまで注目されず、サードパーティのアプリを利用するユーザも限られていました。Facebook自身もAPIを利用したMoochSpot(旧FaceBank)というアプリを公開しましたが、覚えている限り、私の友達て使っているユーザはいませんでした。もしかしたら一部に使っている人もいたかもしれませんが、ニュースフィードでの配信が無かったので知る由もありません。。。
Facebookが自身の写真アプリを参考にして、ソーシャルグラフの活用やニュースフィード配信を外部アプリに対して適用するようになるのは2007年5月のf8以降です。

ニュースフィード / ミニフィード

9/5、ニュースフィードとミニフィードが同時に公開されました。ニュースフィードの役割は今私たちが見ているものと変わらず、友達の更新情報が流れるものです。それに対し、ミニフィードは1人1人のプロフィールページに表示されるもので、そのユーザの更新のみが流れるものでした。以下のキャプチャは公式ブログから持ってきたもので、右下にMini-Feedの領域が見えます。
200118_4351786439_8355_b
当初、ニュースフィードは全く受け入れられませんでした。当時のFacebookの使い方は、前回のエントリで紹介した通り、相手のプロフィールページへ行くのが基本です。寮の友達の部屋を通りかかったとき、ドアのホワイトボードに「12:00にカフェテリアでね!」と書き込むのと同じ感覚で、友達のウォールに書き込んでいました。当然、何が書かれているかを見るには友達の部屋まで行ってホワイトボードを見なくてはならないのと同様、友達のウォールに書かれたことを見るには、友達のプロフィールページへ行く必要がありました。それがいきなり、友達の行動が全部自分のホームに流れてくるようになったわけで、プライバシーが奪われたように感じたのです。
翌日にザッカーバーグが投稿した「Calm down. Breathe. We hear you.(落ち着いて。深呼吸して。ちゃんと聞いてるから。)」という、ユーザを小馬鹿にしたようなタイトルのブログエントリも火に油を注ぐ結果となり、フェイスブック 若き天才の野望によれば、ユーザの10%がニュースフィード反対グループに参加するなどの抗議行動をとったそうです。
実際、この変化は気持ち悪いと言えば悪いものでした。これまでは意識的に相手のプロフィールページに行かない限りは見えなかったものが、Facebookにログインすると一覧になって並んでいたわけです。自分自身も人の行動を追っているように思えてくるし、自分の行動も同じように追われているというのは気味が悪いものです。パーティ翌日のタグ付き写真投稿ほど怖いものはありません。

政治への関わり

Facebookのプロフィールには、ローンチ当初から政治観を入力する項目がありました。今では自由入力になっていますが、当時はラジオボタンになっていて、「リベラル派」などと選択するようになっていたと思います。日本の大学生からすると妙かもしれませんが、けっこう入力している人は居たように思います。また、前エントリの通り、「グループ参加=実名での署名」という意味合いが強かったため、グループは諸々の政策について自分のポジションを明確にする目的でも活用されました。Facebookも学生が政治に参加することを奨励していて、「Facebook the Vote」というエントリでは、選挙を前にして立候補者のプロフィール1600人分が追加されたことが公開されています。
200190_4351771439_1612_b
この当時のグループで一般公開されているものだと、イラク派兵に反対する「Bring the Troops Home Now(今すぐ兵士を我が家へ)」や、賛成する「Stay in Iraq Until the Job is Done(任務を全うするまではイラクに残す)」などがあります。大学にROTC(予備役将校訓練課程)が用意されていたり、コンビニで乳がん撲滅ステッカーと同じ列に「Support our troops(我々の兵を支持する)」ステッカーが売られているなど、学生には身近な話題でした。また、もっと学生らしいグループとしては、「Reduce the Drinking Age to 18!(飲酒を18歳から可能に!)」などもあります。

一般人もユーザ登録可能に

アメリカの大学生 / 高校生、それから一部の企業のみがこれまでFacebookを利用できていましたが、一般ユーザにも公開されたのが9/26でした。この後の1週間のうちにはユーザ数は1000万人を越え、一般ユーザにも浸透していきました。一般ユーザの間でも招待機能は頻繁に使われたらしく、もともと2万人だった1日あたりの登録数は5万人を越えるようになり、12月には累計1200万ユーザに達します。

シェア

今ではLike(いいね!)と並んでFacebookを象徴するシェア機能ですが、これが公開されたのは10/27でした。10/31には外部サイトに設置するシェアボタンも公開され、シェアしたものがニュースフィードによって拡散していくという流れが確立されました。この前後の流れについては、「シェア / いいね! / 送信ボタンの歴史」を参照してください。

まとめ

友達の行動や、シェアされた世の中の出来事がニュースフィードで流れてくるようになるなど、今のFacebookの形へと近づいたのが2006年でした。この改修の背景にあるのは「ユーザの友達の行動や興味の対象には、ユーザ自身も関心を持つ」という発想だと思います。
この考えは後も変わらず、外部サイトでの行動履歴が不本意に流れるBeacon(大反発で撤廃)や、そのほとぼりが冷めてライフログ系のサービスが一般的化した2011年の、新Open Graphでのアクティビティ共有に繋がっているはずです。
現状としては、新Open Graph公開時に出たAdd To Timelineプラグインが消えてしまったり、Recommendations Barからソーシャルリーダー機能が消されたり、Open Graphアプリからのアクティビティ共有が規制強化されるなど、相変わらずアクティビティの共有とプライバシーの保護はとても繊細な問題です。そういった面でも、2006年のニュースフィード公開と一連の騒動は象徴的だと思います。

Facebook今昔物語 ~あのころ僕らはリア充だった 2005夏~

いよいよ月間アクティブユーザ10億人突破ということで、Facebookのこれまでについて思っていることを書いてみます。相変わらずFacebookはリア充のものって言う人が多い中で、まぁ確かにそうなんだろうけど昔のFacebookなんて今の比じゃないよ?って思っていたこととか。ユーザとして使っていた立場から、それぞれの機能の当時の使われ方と、その変遷を紹介します。
まずは2005年当時から。



46411c8e8d540374d19820c620d56336


2005年

まず、私がFacebookに登録したのは2005年の10月で、まだまだ限られた大学の学生しか登録できませんでした。この頃はFacebookの象徴と言えるいいね!ボタンも無ければシェア機能も無く、もっと言えばニュースフィードさえありませんでした。ユーザ登録するとプロフィールページが与えられる程度のシンプルなもので、大学で配布されるフェイスブックをオンライン化したようなものという点では、まさにFacebookという名にふさわしいものでした(thefacebookがFacebookに変わったのは2005年)。

o0640047311496978462

ネットワーク

今ではほとんど意味をなさなくなってしまったネットワークがこの頃は重要でした。たしか大学の地域を元にして割り振られるもので、自分が属するネットワークを越えてユーザ検索をすることができないなどの制限があったように覚えています。また、高校生が参加できるようになったは2005年秋で、当初は高校生は大学生のプロフィールを見れず、またその逆も同様という制約がありました。
地域や年齢層によって交流できる相手が制限されていて、自分が日常的に交流を持つ相手としか交流できない環境だったと言えます。だいぶ濃い空間です。

「求める出会い」設定

今のプロフィールと同様、恋愛対象を男女から選択したり交際相手の有無を設定できる他、どんな出会いを求めているかを設定できる欄もありました。選択肢には「no strings attached(割り切った関係)」かそれに近いものが用意されていて衝撃的でした。
何に使うのか定かではない機能の「poke(挨拶する)」という単語には、受け取り方によっては性的な意味も含まれることを考えると、近隣の大学に通う学生同士の出会い系としての側面も見えてきます。

コースマッチの名残

自分が履修しているクラスを登録できる機能で、たしか同じクラスで紐づくユーザを検索することができました。クラスメイトのジェシーのラストネームを知りたかったり、何に興味があるのかを調べるにはとても重要なポイントです。プロフィールを見れば特定の交際相手がいるのかも分かりますし、もしかしたら共通の友達が見つかって、さりげなく情報収集できるチャンスがあるかもしれません。私の大学が提供するUCONNECTというシステムにも同等の機能はありましたが、Facebookを使う頻度の方が高かった気がします。
2014-02-09 追記:この機能はCoursesと呼ばれるもので、2007年8月7日に機能停止が公式発表されました。

Poke(挨拶する)

ジェシーについて多少の下調べが済み、次回の授業で上手い具合に近くの席を陣取って話をすることができたら、今度は友達申請です。が、そんなに話したことも無いのにいきなり友達申請というのでは若干敷居が高い。同じクラスで断りづらいって思われるのも嫌だし、さすがのアメリカ人だってたまには空気を読む。というわけで、まずは軽くpokeしてみて、そして(幸運にも)poke返しが来たら、好意の証と受け取って友達申請するという使い方もあります。
もともと特定の使い道がない機能で、なんとでも受け取れるし何とでも言い訳できるので、こういう時に便利ですね。

ウォール

今では人のウォールへ書き込むというのは滅多に見なくなりましたが、このころは相手のプロフィールページへ行き、その人のウォールに書き込むというのが主流でした。アメリカの大学寮だとよく自室のドアにホワイトボードを置いて伝言板にするのですが、その延長として使われていたようです。
その名残として、今でも友達の誕生日には友達のウォールに書き込みますし、友達申請が許可されると、「フレンド申請が許可されました。山田さんのウォールに書き込みましょう。」などの文言が出ます。
ジェシーが友達になってくれたのなら、まずは「今日のテストやばかったよ。ジェシーはどうだった?」など書き込んで交流を図り、クラスの外でも親睦を深めることができます。
ちなみに私のウォールを遡ってみると、「今度の休暇は何してるの?」といった書き込みや、「次のテストっていつだっけ?」といった書き込みが出てきます。今のFacebookは会社の上司や親も見てますから、そんな気軽に書き込まれてはたまりませんね。そんなプライベートなことはFacebookチャットかメッセージで聞けよ!と怒られそうですが、これも大事な仲良しアピールです。学生にとってこれ以上に大事なことはありません。

写真

写っている人をタグ付けしてアップロードするという点では今と変わらないので、特に書くこともありません。が、無理矢理ジェシーに結びつけるとしたら、週末一緒に大学のスタジアムでフットボールの試合見てる写真をあげて仲良しアピールでしょうか。これは今でもよく見ますね。可愛い女の子と乾杯してる写真とか殺意が湧きます。
2005年10月の公開当初からタグ付けはよく使われたよ うです。最初に投稿された写真は猫だったものの、続々と女子学生同士の写真がアップされ、互いにタグ付けすることで友情を確かめ合っていたようだと「フェイスブック 若き天才の野望 (5億人をつなぐソーシャルネットワークはこう生まれた)」で紹介されています。このソーシャルな機能のおかげで、より高解像度でアップロードできる写真共有サイトよりも投稿枚数が多いというのは良く語られていますね。

グループ

今は旧グループのアーカイブ化など新グループへの移行が進んでいる最中ですが、この頃のグループ参加は今とは意味合いが違った気がします。今ではグループ内でイベントを立てることもできますが、この頃は交流目的よりもステータスとして参加するものが多かったです。
私がよく覚えているのは「このグループが10000人になったらアフリカへボランティアに行く」といった類の、pledge系とでも言えるようなグループでした。また、学生生活レベルでの過激な政治的グループも多く、「ジョシュアをプレジデント(生徒会長)に!」とか「週末も寮に掃除夫を来させろ」とかも見た覚えがあります。私自身、「UCO(私の大学)には立体駐車場が必要だ」というグループに属していましたが、いずれの場合も「グループへの参加=実名での署名」と言った意味合いが強く、それ以上に交流した覚えはありません。ときどき誰かが「この駐車場はマジで糞!」と書き込んでいた程度です。交流は関係ないのでジェシーは出てきません。

2005年まとめ

ここで紹介したような、友達同士の仲良しアピールや、学生同士のリアルな関係を深める用途という点では、今の学生の使い方とも近いのかもしれません。が、これはいいね!やシェアが実装される前の話です。今のように外部の情報が流れてくることも無く、診断アプリの結果画像が貼付けられることも無く、全ての投稿が友達同士の書き込みに終始していたと言っても過言ではないと思います。そうして見ると、この頃の方がだいぶ「Facebookはリア充のもの」感が強かった気がします。

ただし、ここで紹介したことは、記憶を頼りに私の周りでの使われ方を書いたものです。「そこ違うよ」という指摘や、「うちの大学ではこんな感じだったよ」などのコメントいただければ幸いです。次は2006年編。ミニフィード、ニュースフィード、シェアなど親しみのある機能が出てきます。

Debugging access tokens

Debugging access tokensの和訳です。これを使うとアクセストークンに紐づく情報(どのユーザに紐づくか、期限はいつまでかなど)を取得できるので、10月3日のoffline_access対応のデバッグ作業時、トークンの期限を確かめる場合などに便利そうです。

以下、2012年9月19日 11:46更新分までの本文です。

アクセストークンを利用するとき、期限や紐づくユーザなど、トークンに紐づく情報が何であるのかチェックしたい場合があります。これを取得するにはdebug toolを用いるか、APIを用いることができます。

APIを使う場合は、graph.facebook.com/debug_tokenに対してinput_tokenとaccess_tokenパラメータを付けてHTTP GETリクエストを送ります。

https://graph.facebook.com/debug_token?input_token=INPUT_TOKEN&access_token=ACCESS_TOKEN
  • input_token: デバッグ対象のアクセストークン
  • access_token: アプリの開発者のユーザアクセストークン、もしくはアプリのアクセストークン

access token toolを使うことでアプリもしくはユーザのアクセストークンを取得できます。アプリのアクセストークンには期限が無いので、このAPIを常用する場合はアプリのトークンを使ってください。

注意:App Dashboardのadvanced settingsでアプリがNative/Desktopに指定されている場合は、App Secret in Clientの設定をNOにしない限りはこのAPIは機能しません。この設定が見当たらない場合は、App TypeがNative/Desktopになっていることを確認し、ページ下部のsaveボタンで保存してください。タイプがWebになっているアプリに対しては影響ありません。

APIの返り値はdataと各フィールド値を含むJSONオブジェクトで、以下のサンプルのようになります。

{
    "data": {
        "app_id": 138483919580948, 
        "application": "Social Cafe", 
        "expires_at": 1352419328, 
        "is_valid": true, 
        "issued_at": 1347235328, 
        "metadata": {
            "sso": "iphone-safari"
        }, 
        "scopes": [
            "email", 
            "publish_actions"
        ], 
        "user_id": 1207059
    }
}

Field Expansion

Field Expansionの和訳です。これを使うと、Batch Requestよりも手軽に複数のクエリを1つにまとめることができます。

実装例については、Graph APIを多用するときに便利な機能のFields Expansionを参照してください。

graph_api_explorer

以下、2012年9月4日 18:00更新部分までの本文です。

Graph APIの一機能であるField Expansionを使うと、複数のクエリを一度のリクエストにまとめることが可能になります。

つまりGraph API呼び出し時に、繋がりを持つオブジェクトをネストしてリクエストすることができるようになります。たとえば、一個目のKアルバムに紐づく最初のN枚の画像を一度に取得するなどです。レスポンスは階層構造を保っているので、開発者はFQLのマルチクエリやバッチリクエストのようにデータを組み直す必要がありません。基本的なGraph API利用のシンプルさを失わない機能拡張であるということです。

以前は、同等の問い合わせを行う方法はFacebook Query Language(FQL)だけでした。これだけ強力な機能であっても依然と同様にFQLを使わなくてはならないケースも出てくることを覚えておいてください。


Usage

Field Expansionを理解する一番の方法は、Graph Explorerを使ってクエリを組み立ててみることです。そこで組み立てられるクエリをリアルタイムに確認することで、シンタックス、識別子、フィールド、コネクションなどをを理解できます。ビルトインアクションカスタマイズしたアクションなどのコネクションを参照する場合には、Graph Explorerに自分で入力する必要があります。


Examples

Example 1: Basic Limit Query

以下のクエリは、ユーザオブジェクトのnameとbirthdayを返し、さらに直近10個のphotoオブジェクトのid,pictureフィールドを返します。

GET https://graph.facebook.com/me?fields=name,birthday,photos.limit(10).fields(id, picture)

Example 2: Using Valid Parameters

有効なパラメータであればどれでも使うことができます。たとえばvideoオブジェクトであれば、uploadedもしくはtaggedを指定するtypeパラメータを渡すことができます。

上述したクエリを書き換え、ユーザがタグ付けされたビデオ10個も取得するようにしてみましょう。

GET https://graph.facebook.com/me?fields=name,birthday,photos.limit(10).fields(id,picture),videos.type(tagged).limit(10).fields(id, source)

Example 3: Nesting

以下のサンプルは、ユーザのアルバムを最大5件と、それぞれのアルバムに紐づく最初の写真オブジェクト2つ、その写真にタグ付けされたユーザを取得しています。

GET https://graph.facebook.com/me?fields=albums.limit(5).fields(name, photos.limit(2).fields(name, picture, tags.limit(2)))
{
   "id": "5000388",
   "albums": {
      "data": [
         {
            "name": "My Uploads",
            "id": "167343188",
            "created_time": "2009-10-31T01:16:01+0000",
            "photos": {
               "data": [
                  {
                     "name": "Raising a Plant",
                     "picture": "https://fbcdn-photos-a.akamaihd.net/hphotos-ak-ash3/5686_10150636498189_1775439_s.jpg",
                     "id": "101363649819",
                     "created_time": "2012-06-23T06:31:53+0000"
                  },
                  {
                     "name": "Dressed up",
                     "picture": "https://fbcdn-photos-a.akamaihd.net/hphotos-ak-snc6/1392_101509832589_25596_s.jpg",
                     "id": "100989593189",
                     "created_time": "2012-06-23T01:18:07+0000",
                     "tags": {
                        "data": [
                           {
                              "id": "10000002867",
                              "name": "S\u0142awek",
                              "x": 52.9363,
                              "y": 24.4722,
                              "created_time": "2012-06-23T19:11:08+0000"
                           }
                        ]
                     }
                  }
               ],
               "paging": {
                  "next": "https://graph.facebook.com/1673988/photos?limit=2&fields=name,picture,tags.limit\u0025282\u002529&after=MTAxNTA5ODMyNOTMxODk\u00253D"
               }
            }
         },
         ...
}

Example 4: Nested Identifiers

Field Expansionはコネクションに対してのみではなく、識別しに対しても同様に働きます。

GET https://graph.facebook.com/<photo_id>/comments?fields=from.fields(id, name, birthday)

Example 5: Nesting Open Graph Objects

ビルトインアクションカスタマイズしたアクションのデータを取得することも可能です。これらはGraph Explorerのドロップダウンメニューから選択することはできませんから、自分で入力しなくてはなりません。手入力されたクエリでも同様に実行できます。

以下のクエリは、友達が読んだ直近2個の記事オブジェクトと友達オブジェクト10個を一度に取得します。他のどのクエリとも同様、データを取得するには適切なパーミッションを取得している必要があります。このケースでは、Open Graph permissionsのうちfriends_actions.newsが必要です。

GET https://graph.facebook.com/me/friends?limit=10&fields=news.reads.limit(2)
記事検索