第11回 アプリに広告を出す（前編：基礎知識編）：連載：Windowsストア・アプリ開発入門（4/5 ページ）

Windowsストアアプリの機能が完成したら、実際にストアで公開する前に、アプリをお金に換えるための機能を実装しよう。今回はマネタイズの仕組みを解説する。

[山本康彦（http://www.bluewatersoft.jp/），BluewaterSoft]

使い切り型のアプリ内販売

　使い切り型のアプリ内販売（＝コンシューマブルなアプリ内購入）を利用したシステムを設計／実装することは、入門レベルをはるかに超えた困難な作業だ。そのため、概要だけを説明しておく（別途公開しているサンプルコードには、概略の実装が入れてある）。

　このアプリ内販売では、Windowsストアはエンドユーザーに課金するためのトランザクションをサポートするだけだ。有効期間などのライセンス管理はアプリ側で行わなければならない。トランザクションは、エンドユーザーによる購入UIでの購入操作をWindowsストアが受け付けたときに始まり、アプリが購入処理の完了を報告した後、Windowsストアが課金処理を終えたときに完了する（次の図）。

使い切り型のアプリ内販売（コンシューマブルなアプリ内購入）におけるトランザクション
正常にトランザクションが完了するケースの概略のみを描いた。実際には、アプリ側／Windowsストア側それぞれでトラブルが起きてトランザクションが完了しないことも起こり得る（後述）。

　上の図は正常にトランザクションが完了する場合であり、実際には、アプリ側の登録処理やストアへの報告処理、あるいは、Windowsストア側の課金処理などの途中でエラーが発生してトランザクションが未完了のままになることもあり得る。そのような状態のトランザクションは「未完了の使い切り型トランザクション」（MSDNでは「フルフィルメントが完了していないコンシューマブルトランザクション（unfulfilled consumable transactions）」）と呼ばれ、Windowsストア側で保持される。未完了のトランザクションが残っていると、エンドユーザーは購入したつもりなのに、アプリに反映されていなかったり、ストアでの課金が発生していなかったりという状態になっている。そこで、アプリは定期的に（例えば起動時などに）、未完了のトランザクションをチェックし、存在した場合は、アプリ内で購入したものを重複することなく登録し直し、完了をWindowsストアに報告しなければならない。

　未完了のトランザクションがなければ、新しい購入処理を行える。上の図のように、エンドユーザーの意志に基づいて購入UIを出し、Windowストアから返されたProductIdとTransactionIDに基づいてアプリ内で購入したものを登録し、Windowsストアに完了報告を行う。ただし、「アプリ内で購入したものを登録」と書いたが、複数のPCで利用するエンドユーザーのことを考えると、実際には独自のWebサービスを立ち上げてライセンス管理をすることになるだろう。

　なお、アプリをWindowsストアに提出する際に情報を記入する場所は次の画像のようになっている。

Windowsストアのダッシュボードで使い切り型のアプリ内販売を設定する画面（Internet Explorer）
［サービス］のページで、アプリ内販売の［製品ID］（＝ProductId）を入力し、［価格帯］／［製品の有効期間］を選択する。［製品の有効期間］で［使用できる］を選ぶと、使い切り型のアプリ内販売になる（上の画像）。 次に、［説明］のページで［アプリ内販売の説明］（＝Name）を入力するのは持続型の場合と同じだ（下の画像）。 なお、下の画像は、他のアプリのものである。

　さらに、使い切り型のアプリ内販売では、アプリ側で独自に定義した「OfferId」文字列を利用して、1つのProductIdで複数の商品を販売することも可能である。その場合には、購入UIを出すときに3引数のRequestProductPurchaseAsyncメソッドを使う。「Official Windows SDK Sample」の「Trial app and in-app purchase sample」にサンプルコードが入っている。