Open Graphアプリとウォール投稿が一部規制される詳細 : Facebook開発者向けドキュメントの日本語訳とTips

以前書いた「Open Graphアプリの規制強化 & 友だちのウォールへの投稿禁止」で、ユーザの友だちのウォールへの書き込みが禁止されることや、Open Graphアクション投稿の一部が禁止されることを紹介しました。その内容で伝わりにくい部分があったので、今回補足してみます。

友だちのウォールへの書き込み

まず一点目の大きな規制は、友だちのウォールへの投稿禁止です。具体的な流れとしては以下のようなものが禁止の対象となります。

ステップ1. ユーザのアクセストークンを用いて、ユーザの友だち一覧を取得

curl -X GET https://graph.facebook.com/me/friends?access_token=USER_ACCESS_TOKEN
返り値：

{
  "data": [
    {
      "name": "Mark Zuckerberg",
      "id": "4"
    },
    {
      "name": "Chris Hughes",
      "id": "5"
    },
    {
      "name": "Dustin Moskovitz",
      "id": "6"
    },
]
}

余談ではありますが、友だち一覧を得る為だけの目的で read_friendlists パーミッションを求めるアプリがありますが、そういった目的ならば read_friendlists パーミッションは必要ありません。このパーミッションは、ユーザが作成した友だちリスト（Google+でいうサークル）を取得する為のもので、 /me/friends で友だちを取得したいだけならば、特にパーミッションを求めなくても取得することができます。

こうして友だち一覧を取得するところまでは、今後もOKです。

ステップ2. 取得した友だちのウォールに対して投稿

curl -X POST \
       -F 'access_token=USER_ACCESS_TOKEN' \
       -F 'message=abcd' \
       https://graph.facebook.com/FRIENDS_ID/feed

ここで示したように、ユーザのアクセストークンを用いて、そのユーザの友だちのウォールへ投稿を行う行為が、今後の仕様変更で禁止となります。最近のメジャーなアプリで言うと、「○○City Socialがあなたのタイムラインに投稿しました」という通知が来て、自分のタイムラインにまで投稿されて驚いた人も居るのではないでしょうか？以前は、認証時に publish_stream というパーミッションをユーザから得ると、そのユーザの友だちのウォールに対しても投稿することができましたが、今後は publish_stream パーミッションを取得していても投稿できなくなります。（「Facebook Night vol.7 発表内容まとめ 1：publish_streamとpublish_actions」で publish_stream と publish_actions の違いについて書きましたが、あえて publish_stream パーミッションを選択する利点が減ることになります。）

ただし、/me/feed でユーザ自身のウォールに対して投稿するのは引き続き可能です。

Open Graph アクションの一部禁止

去年（2011年）の流れ

去年の f8 での新 Open Graph 発表で話題となったのは、ユーザが音楽や動画を視聴すると自動的に Facebook 上で共有される機能や、ニュース記事を読むだけでそれが共有されるソーシャルリーダ機能でした。これらは frictionless share （摩擦の無い共有：手間がかからない簡単なライフログ共有）と呼ばれ、いちいちシェアボタンを押したりフォームに入力したりすることなくライフログを共有することを可能にしました。
また、これと前後して Frictionless Request という機能も公開されました。 citiville をやったことのある方なら分かるかと思いますが、何かあるたびにリクエストを送る相手を選ばされるのは面倒です。この機能を有効にすると、毎度同じプロセスを経ずともリクエストを送信できるようになるという利点があります。
このように去年の方針としては、ユーザの介入無しにライフログやリクエストが投稿されていくという、2007年当時の Beacon に近づいていく流れがありました。おそらく、スマートフォンの流通によってチェックインや写真などのライフログ共有がメジャーになり、ライフログ共有への抵抗が減った（と判断された）のがキッカケかと思います。
ところが実際のところ、勝手にライフログが共有されるのは気持ちが悪いし、スパムまがいの使われ方が多いというわけで、少なくともユーザや Facebook 自身がコントロールできる範囲に限って frictionless share を許可する流れに現在向かっているのかと思います。

今後の流れと、規制の線引き

以上のような流れがあるので、今後はユーザの意図しない形式での Open Graph アクション投稿への規制が厳しくなります。この規制を理解する上で重要なキーワードが "content consumption" で、これは、ユーザが web ページを閲覧する行為を指します。これだけがトリガーとなって Open Grpah アクションを投稿するのが今後は規制対象となります。
ただし例外として、Facebook が提供するビルトインアクション（listen, watch, readなど）を利用する場合は、ユーザが音楽や動画を視聴したり、ニュース記事を読んだだけで Open Graph アクションを投稿することが許されます。これが、前回のエントリで説明した以下の内容です。

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

現状

ここまでが、去年の Open Graph 発表と今後の流れです。で、今はどういう状態なのかというと、90日間の移行猶予期間の最中です。すでに申請通過済みの Open Grpah アクションであれば、 content consumption に該当するものでもまだ動作しますが、新規の申請は許可されません。また、すでに申請通過済みであっても、この90日の猶予期間が終われば規制の対象となります。

ただし、content consumption に該当しない用法であれば、今後もカスタムアクションの定義は許可されます。この点が前回のエントリで一番誤解を招いてしまった部分なので、気をつけてください。単純に言ってしまうと、音楽を視聴するだけで listen アクションが共有される Spotify や、ニュース記事を読むだけで read アクションが共有されるソーシャルリーダのようなものは、 listen, read などのビルトインアクションを利用しているから許可されるけど、自前で定義するカスタムアクションに関しては、そういった実装は許可されなくなるということになります。

参考までに、どこがボーダーラインになるのか、Facebookのガイドラインにあるテーブルを共有します。

シナリオ	許可される?	理由
ユーザがアプリのページを閲覧すると、ユーザのタイムラインに「閲覧した」旨が自動的に投稿され、と友だちのニューソフィードにも流れる。	No	サイト上のコンテンツを閲覧しただけで自動的に投稿される。このアクション（閲覧する）は content consumption に該当する。
ユーザがアプリ内のコンテンツを閲覧し、「閲覧した」ボタンをクリックする。ユーザのタイムラインに「閲覧した」旨が投稿され、友だちのニュースフィードにも流れる。	No	content consumption に該当するカスタム Open Graph アクション（閲覧する）は、意図せず何かを共有してしまったと感じて混乱する。
ユーザがアプリ内のコンテンツを閲覧し、「欲しい」ボタンをクリックする。ユーザのタイムラインに「欲しい」旨が投稿され、友だちのニュースフィードにも流れる。	Yes	共有することに関してユーザがコントロールできている。また、カスタムアクション（want）は、content consumption には該当しない。
ユーザがゲーム中でレベル達成し、「勝った」旨がユーザのタイムラインに投稿され、友だちのニュースフィードにも流れる。	Yes	ユーザ自身が、投稿のトリガーとなるアクションを行った。また、カスタムアクション（win）は content consumption に該当しない。

これを見ると、単に閲覧や視聴したことだけを示すカスタムアクションを定義したり、閲覧や視聴だけをトリガーとしてそれらのアクションを投稿するのが禁止されるのが分かります。

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