概要

2014年に、私はProsperというサイトを通じてP2Pレンディングへの投資を始めました。P2Pレンディングは面白い仕組みだと思いましたし、高いリターンが得られる可能性もあると感じていました。

当初はローン投資を一つひとつ手作業で選んでいましたが、やがてこのプロセスを自動化し、自動で投資を行うレンディングBot「ProsperBot」を自作しました。

このブログ記事では、P2Pレンディングについて簡単に概要を説明し、ProsperBotを構築した過程を紹介します。

P2Pレンディングとは？

例えば、アリスが今後5年かけて返済する3,000ドルの借入を希望しているとします。従来であれば、アリスの最善の選択肢は銀行にローンを申し込むことでした。銀行はアリスに3,000ドルを貸し付け、アリスが予定通りに返済すれば、銀行は利息や手数料で利益を得ます。もしアリスが返済できなければ、その損失は銀行が被ることになります。

P2Pレンディングでは、アリスはP2P仲介業者（Lending ClubやProsperなど）を訪れます。仲介業者は自らの資金を貸し付けるのではなく、そのローンを投資家に提供します。投資家であるボブ、チャーリー、ダニカは、アリスのローンをそれぞれ1,000ドルずつ分割して購入できます。アリスは毎月レンディングサイトに返済し、サイトはその返済額の3分の1ずつを毎月ボブ、チャーリー、ダニカに分配します。

理論上は、銀行という中間業者を介さないことで、借り手は従来の金融機関よりも良い条件で借り入れでき、投資家（貸し手）は銀行の普通預金や定期預金に預けるよりも高い利息を得られるということになります。P2Pレンディングについてより詳しく知りたい場合は、Lend Academyのようなサイトが優れた情報源になります。

ProsperBotとは

ProsperでP2Pローンに投資する場合、投資家はProsperのウェブサイトで手動でローンを選ぶことができますが、Prosperは開発者が自動で投資できるように公開APIも提供しています。

私はAPIを利用する方法を選び、Prosper上で新しいローンを継続的に検索し、特定の条件を満たした場合に投資を行うレンディングBot「ProsperBot」を開発しました。さらに、ProsperBotの現在のステータスやProsperアカウントの推移を確認できるウェブダッシュボードも用意しています。

グラフからわかるように、ProsperBotがローンの返済を受け取り、その現金を新しいローンに再投資することで、4月以降、私のアカウントの価値は着実に増加しています。10月から総資産額が減少し始めていますが、これはProsperアカウントから資金を引き出し始めたためです。

構成要素

ProsperBotはいくつかの異なるパーツで構成されており、以下に図で示しています。

gofn-prosper (Go Forth ’n Prosper)

gofn-prosperは、Prosperの公開API用のGoバインディング集です。Prosper APIの詳細をアプリケーションの他の部分から隠蔽しているため、例えばProsperのノートを購入するような処理を、アプリケーション側では次のように記述できます。

client.PlaceBid(prosper.BidRequest{
  ListingID: 5492410,
  BidAmount: 25.0,
})

このライブラリはProsperBotから完全に独立しているため、このプロジェクトの中でも他の人にとって最も興味深い部分かもしれません。Prosper APIと連携するGoアプリケーションを書きたい人なら、誰でもこのライブラリを自分のアプリケーションで再利用できます。

ProsperBot

ProsperBotは、gofn-prosperの上に構築され、実際にProsper上でアクションを実行するアプリケーションです。ProsperBotはProsperのサーバーを継続的にポーリングして、以下の処理を行います。

• 新たに利用可能になったローンを検索する
• 投資基準を満たすローンに投資する
• Prosperアカウントのステータスの変化を検知する（例：現金残高の変化、総資産額の変化）
• ノートの更新を検知する（返済の受領、ノートのステータス変更）

ProsperBotはすべての状態をRedisデータベースに保存します。

この部分は理想ほど洗練されていません（コードには場当たり的な部分があり、ドキュメントも十分ではありません）が、主にgofn-prosperの使用例として公開しています。

ProsperBot Frontend

ProsperBot Frontendは、ProsperBotのステータスを表示するAngularJS製のウェブアプリケーションです（上記スクリーンショット参照）。静的リソース（HTMLファイルや画像など）へのリクエストはnginxで処理し、動的コンテンツへのリクエストはカスタムのGoサーバーで処理します。このGoサーバーは、ProsperBotと同じRedisデータストアを使って動的リクエストに応答します。

ProsperBotのデプロイ

ProsperBotはいくつかの異なるコンポーネントで構成されており、ホストシステムにいくつかの依存関係（Go、nginxなど）を要求します。デプロイのプロセスを簡素化するため、いくつかのAnsibleロールを作成しました。

• mtlynch.prosperbotは、コアとなる（ヘッドレスの）ProsperBotアプリケーションをインストールするロールです。
• mtlynch.prosperbot-frontendは、フロントエンドをデプロイします。

このように分割することで、ProsperBot、ProsperBot Frontend、Redisをそれぞれ別のマシンにデプロイすることも可能になります。私は個人的にすべてのコンポーネントを1台のサーバーにインストールしています（そのためのAnsible Playbookの例は、GitHubのREADMEのサンプルに示しています）。

Prosperについての所感

全体として、ProsperBotは私にとって良い学習経験になりましたが、投資戦略としてProsperをおすすめすることはありません。理由はいくつかあります。

• 小規模では採算が合わない：Prosperでの私の収益率はXIRRベースで約9%で、一見すると悪くないように思えますが、しかしP2Pレンディングによる所得は通常所得として課税されるため、株式のようなより伝統的な投資よりもリターンの大部分が税金で目減りしてしまいます。また、税務処理が複雑になるため、市販の税務ソフトでは対応できず税理士を雇う必要があり、毎年600ドルが収益から差し引かれます（16,000ドルの投資に対して約4%に相当します）。
• 使いにくいAPI：Prosper API自体の設計があまり良くありません。例えば、トークンベースの認証を採用し（良い点）、アプリ開発者にはユーザー名／パスワードの代わりにクライアントIDとシークレットを割り当てておきながら、実際の認証では結局すべての場面でユーザー名とパスワードを要求するため、クライアントIDとシークレットが無意味になっています（悪い点）。また、APIがマイナスの返済額が記録されたノートのようなナンセンスなデータを返すこともあり、本番の投資用APIとしてはあってはならないことです。
• 開発者サポートの貧弱さ：2015年にProsperはAPIを全面的に刷新しました（以前のAPIはさらにひどいものでした）が、旧システムを停止するまで、開発者にはまったく新しいAPIへ移行するのにわずか1か月しか与えませんでした。すべてのProsperクライアント開発者が手元の作業を放り出して1か月以内にコードを全面的に書き換えると期待するのは、かなり厚かましい対応でした。さらに悪いことに、新しいAPIはバグだらけで、Prosperはすべてのクライアントに1か月という期限を守るために奔走させた挙句、結局レガシーAPIの提供期間をさらに3か月延長せざるを得ませんでした。
• 個人投資家への関心の低下：Prosperは個人のリテール投資家よりも、銀行などの機関投資家に重点を置くようになっているようです。その最たる例が、2016年9月にProsperが発表した、ユーザーがセカンダリーマーケットでローンを売却できなくなるという変更でした。これは条件の大幅な変更であり、投資家がProsperでの保有資産を現金化できなくなったため、私は今後5年間、Prosper（とそれに伴う税務上の面倒）と付き合わざるを得なくなりました。

Prosperの個人投資家に対する関心の低下が、私に資金を引き揚げ始める決心をさせました（それは上のグラフでも確認できます）。Prosperの米国における唯一の主要な競合であるLending Clubについては良い評判を聞いているので、今後はそちらに資金を移し、そのサイト用の新しいレンディングBotを作成する予定です。