APIs | SEO-LPO.net

API管理サービスのApigeeもハイブリッドのバスに乗り込んできた

今年のGoogle Cloud Nextは、ハイブリッド環境のサポートが大きなテーマだった。だから、同社が2016年に2億6500万ドルで買収したAPI企業Apigeeもまさに、その機に乗ろうとしている。米国時間4月9日、Apigeeはハイブリッド環境向けのプロダクトApigee Hybridのベータを発表した。

長年Oracleにいて最近Google Cloudに来たAmit Zavery氏とNandan Sridhar氏が、共著のブログ記事でこの新製品を説明している。「それはAPI管理プラットホームであるApigeeの新たなデプロイメントオプションであり、それによりユーザーはランタイムをどこででもホストできる。自分のデータセンターでもよいし、あるいはパブリックなクラウドのどれかでもいい」。

今朝Googleが発表したハイブリッド環境管理サービス Anthosと同様に、こちらはAPIをどこで動かしても単一の方法で管理しよう、というものだ（Anthos参考記事（1 ）、（2 ））。

Zavery氏らのブログ記事は、次のように述べている。「Apigee Hybridによって、すべての環境にまたがる単一のそして完全なAPI管理ソリューションが得られる。ユーザーはAPIとそれらが露出するデータをコントロールでき、企業内のすべてのAPIに対する統一的な戦略を確保できる」。

この発表は、多様な環境から成る顧客のコンピューティングシステムをひとつの全体としてサポートしようとするGoogleの全体的な戦略の一環だ。そういう混成環境のことを、昨今はハイブリッドクラウドと呼ぶことが多い。今日のクラウドネイティブの世界では、この考え方は、ユーザーのデプロイメントをそれらがある場所にとらわれずに管理するための、単一のファブリックを提供することに通ずる。

このApigee Hybridも、そんな考え方の延長であり、しかもそれは今やコンテナ化とクラウドネイティブコンピューティングの最前線に位置するオープンソースツールのKubernetes を開発したGoogleにふさわしいやり方だ。ハイブリッドだから純粋にクラウドネイティブではないが、その精神は引き継いでおり、コンピューティング全般に対するGoogle Cloudのアプローチの視界にはしっかりと含まれている。だからこそ、それは、今年このカンファレンスで定義されようとしているのだ。

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

メールAPIのMailgunが過半数株をThoma Bravoに売却して再びオーナーチェンジ

メールのAPIを提供しているMailgunが、株式の過半数をプライベート・エクイティ企業Thoma Bravoに売却すると発表した。同社はその条件を公表していないが、これは同社の8年の歴史の中で二度目のオーナーチェンジになる。

Mailgunは、デベロッパーが自分のアプリケーションにメールの機能を組み込むためのAPIを提供している。同社のデータによると、そのAPIを使っている顧客は15万社あまりいる。

投資を発表するブログ記事の中でCEOのWilliam Conwayは、これにより同社はその能力を拡大し、製品開発のスケジュールを早めることができる、と言っている。買収される企業がよく言う言葉だ。

そのブログ記事でConwayはこう述べている。「数百万ドルを製品開発に投じてユーザーの能力を高め、メールに関する多くの知見が得られるようにし、顧客に他に類のない体験を提供できるようにする。またユーザーがアプリケーションに組み込んだメール機能のスケーラビリティを高め、強力で安定的な通信機能をアプリケーションに賦与する」。

同社は2010年に操業し、2011年のY Combinator冬季を受講したが、その後の履歴が複雑だ。2012年にはRackspace に買収され、2017年には単独の非上場企業に戻った。そのときは、別のプライベート・エクイティ企業Turn/Riverが同社に5000 万ドルを投資した。今日の株式売却で、Turn/RiverはMailgunの少数株主として残ることになる。

Mailgunの主な競合他社はMailchimpやSendGridなどだ。Thoma Bravoには、これまで主にエンタープライズソフトウェアの企業を買ってきた履歴がある。いちばん最近では、同社はApttus の過半数株を買った。そのほか同社は、SolarWinds、SailPoint、Blue Point Systemsなどにも投資している。

Thoma Bravoは現時点でコメントの求めに応じていない。

関連記事: Email delivery service Mailgun spins out of Rackspace and raises $50M…MailgunがRackspaceからスピンアウトし5000万ドルを調達（未訳）

[原文へ]

（翻訳：iwatani、a.k.a. hiwa）

APIの提供企業がAPIの使われ方を知るツールMoesifがシードで$3.5Mを調達

今日のデベロッパーは、各社が提供しているAPIを呼び出して自分のアプリからいろんなサービスを利用できる。しかしAPIを提供する側は、自分のAPIがどんな使われ方をしているか、知りたいだろう。そこでサンフランシスコのMoesifは、APIの提供企業がAPIの使われ方を知るためのサービスを提供する。本日（米国時間1/4）同社は、350万ドルのシードラウンドを発表した。

この投資をリードしたのはMerus Capitalで、これにHeavybit, Fresco Capital, そしてZach Coeliusらが参加した。なおCoeliusは、2016年にGMが10億ドルで買収したCruise Automationにも投資していた。

Moesifの協同ファウンダーでCEOのDerric Gillingによると、MoesifはMixpanelやGoogle Analyticsに近いが、WebやモバイルのアナリティクスではなくAPIの使われ方を見る。“APIを作って提供する企業や、それらを利用する企業がますます増えているから、API利用の顧客であるデベロッパーがどんな使い方をしているのか、彼らは何かの問題に遭遇していないか、デベロッパーチャーン(developer churn, 他社API利用への移行…浮気)をどうやって減らせばよいか、等々を知る必要性が生じている”。

APIを使った地域別ヒートマップ。スクリーンショット提供: Moesif

同社が対象とするのは、二つのタイプのユーザーだ。まず、APIに問題があったらAPIのモニタリング機能を利用できるデベロッパー。彼らは主に、Moesifの無料ティアにアクセスしている。

一方企業ユーザーの場合は、企業の各部門、プロダクト管理や営業、マーケティングなどが、Moesifのツールを使ってAPIの利用者や利用頻度などを知り、また使い方のパターンから、機械学習により、どこがプロダクトの使用をやめそうか、などを知ることができる。そのツールはMailchimpやCRMツールなどそのほかのビジネスシステムと統合できるので、自分たちのAPIの使われ方に関する、より完全な知見が得られる。

Moesifのツールがリリースされたのは昨年だが、Gillingによると、すでに2000社/名のユーザーがいて、無料または有料のティアを使っている。とくにうまくいっているのが、SaaS企業とフィンテック企業だ。どちらもAPIを多用しており、Moesifの顧客にはPowerSchoolやSchwab、DHLなどもいる。

同社は今、二人のファウンダーと社員一人だが、今度のシード資金で半年以内に約10名を雇う予定だ。エンジニアリング担当VPやデベロッパーの増員、そして営業とマーケティングも必要だ。

Moesifは2016年の晩くに創業され、ファウンダーたちは昨年Alchemist Acceleratorを卒業した。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

蜜蜂の個体数を調べて群の健康状態をチェックするRaspberry Piのプロジェクト

蜜蜂を飼うと、そのお世話がたいへんである。そこでプログラマーのMat Kelseyは、彼の羽根のある蜂蜜メーカーたちが今どれだけ巣箱にいるかを知るためのカウンターを作った。彼のシステムはRaspberry Piと機械学習のアルゴリズムを使って、巣箱に入る蜂の個体数を調べ、その時系列を見ることによって群（むれ）の状態をモニタする。

“巣箱を置いたとき最初に考えたのは、‘出入りする蜂の数をどうやって数えるか？’だった”、とKelseyは書いている。“調べてみたら、蜂にとって無害な良い方法はまだないことが分かった。でも、個体数とその変化が分かれば、コロニーの健康状態もよく分かるはずなんだ”。

そのシステムは、巣箱のドアの写真を10秒おきに撮る。そしてその背景を外挿して、その間にフレームに入ったオブジェクト…すなわち蜂…の数を数える。蜂は絶えず動き回っているし、巣箱から出て行く蜂は数えないから、難しくておもしろい問題だ。

ソースはGithubでダウンロードできるし、詳しいブログ記事もある。今は、蜜蜂のコロニーの崩壊が世界的な問題になっているから、なおさら重要なツールだろう。しかも、Raspberry Piがこんな複雑なこともできるなんて、嬉しいよね。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Twitter、サードパーティーアプリを機能不全にするAPI変更を延期

今日（米国時間4/7）午前、TwitterクライアントのTweetbot、Twitteriffic、Tweetings、およびTalonが共同で、近く実施予定で彼らのアプリを動作不能に陥らせる恐れのあるTwitter APIの変更について抗議の声を上げた。ご想像の通り、これらのアプリのユーザー基盤をあわせると、公式Twitterアプリよりも多い。これは公式アプリより高機能を望む人たちだ（あるいはTwitterが公式アプリを中止したあともネイティブアプリを使いたいMacユーザー）。

Twitterはこれに答えて、APIの変更を当分延期すると発表した。

Last year we announced our plan to retire Site Streams & User Streams, and replace them with the Account Activity API (currently in beta). We are delaying the scheduled June 19th deprecation date.

— Twitter Dev (@TwitterDev) April 6, 2018

［昨年当社は、Site StreamとUser Streamsを廃止し、Account Activity API（現在ベータ）で置き換えることを発表した。このたび6月19日に予定されていた終了日を延期することにした。］

当初2018年6月19日に予定されていたAPI変更で、Twitterの “streaming” APIは、新しい”Account Activity” APIで置き換えられる予定だった。

なにが問題ものか？上記デベロッパーらの指摘によると、変更のわずか2カ月前になっても、彼らを含めたサードパーティー開発者は新APIをまだ利用することができていない —— そしてこの種の変更への対応には時間がかかる。

一方、新APIが公開されたあとにも機能制限があり、プッシュ通知やタイムラインの自動更新などが使えなくなる可能性がある。デベロッパー・グループによる詳しい解説はこちら。

Twitterはstreaming APIを廃止する新たな日付を発表していないが、「少なくとも90日前」には通知すると言っている。

As always, we’re committed to providing ample time to migrate. We will provide at least 90 days notice of deprecation date from when the Account Activity API becomes generally available to all developers. More specifics on timing to come.

— Twitter Dev (@TwitterDev) April 6, 2018

［今までと同じく、移行のためには十分な猶予時間をとることを約束する。Account Activity APIが全デベロッパーに公開される少なくとも90日前には告知を行う。詳しい日程は後日発表の予定。］

[原文へ]

（翻訳：Nob Takahashi / facebook ）

Oktaがアイデンティティ管理サービスをAPI呼び出しにも適用

People on phones with social media icon chalkboard

Oktaが今日（米国時間8/29）、ラスベガスで開かれたカスタマーカンファレンスOktaneで、同社のアイデンティティサービスをAPIにも適用する、と発表した。

これまでずっとOktaは、人びとをServiceNow, Salesforce, Office 365などのクラウドアプリケーションにセキュアに接続するサービスを提供してきたが、2年前にはそれに加えて、顧客企業の社員たちがそれらのクラウドアプリケーションにアクセスするために使うデバイスをコントロールする機能の、提供を開始した。

今日の発表で同社は、そのプログラムが既存の複数のサービスを利用していることを明かした。たとえば位置に関してはGoogle Maps、通信に関してはTwilio、決済はBraintree、というように。それは単一のプログラムのようでありながら、そのユーザー体験は複数のゲートウェイを横断して提供されている。

“このことによって実は、うちの顧客はコントロールをAPIにも拡張できるんだ”、とOktaのCEO Todd McKinnonは語る。

彼によるとそれには、二つの方式がある。APIはアドミンやプログラマーがアクセスすることが多いが、Oktaにより企業はこのアクセスをポリシーで管理できる。また、APIのゲートウェイへのアクセスを試みた者のID等を、監査証跡（オーディットトレイル）に残すこともできる。

“ハッカーは弱点を見つけることが上手だから、システムがAPIをロックしていないこともきっと見つけるだろう。しかしそこに強力なアクセスポリシーがあれば、多くの場合、弱点の補強が可能だ”、とMcKinnonは述べる。

OktaのAPIシステムはOAuth 2.0によるアクセスコントロールとOktaのポリシーエンジンを併用し、アドミンにアクセスコントロールパネルを提供する。またApigeeやMuleSoftなどのAPIアクセス管理のベンダーともパートナーしている。

Oktaは今、岐路に立っている。昨年9月には12億ドルの評価額で7500万ドルという巨額なラウンドを発表して、企業のセレブたちが集まるユニコーンクラブの仲間入りをした。同社は2009年の立ち上げ以来、累計で2億3000万ドルの大金を調達し、昨年の資金調達のときの発表声明は、向こう12〜18か月以内にIPOがありそうなことを、示唆している。

しかしその後、テクノロジー企業のIPOのペースは鈍化し、今回のMcKinnonも、時期については何も言えない、と慎重な姿勢を示した。

彼はこう言う: “誰かが時期をはっきり言ったら、それはたぶん上場しない、という意味なんだ。一般的に、過去数年間を見ても、上場したからすごく良くなった、という企業はあまりないからね”。

彼によると、最近の業界の最大の変化は、市場が成長を重視しなくなり、むしろ投資効果や費用効果の悪いところがネガティブに評価されていることだ。“だから、単なる成長ではなく、投資効率の良い成長でないと市場は評価しなくなったのだ”、と彼は語る。

ではOktaは、そんな成長をどうやって達成するのか。去年McKinnonが言った12〜18か月は、まだ過ぎていないのだが。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

GoogleがAndroid NのDeveloper Preview 4をリリース、とくに目立つ新機能はなし

Googleが今日（米国時間6/15）、Android Nの四度目のプレビューをリリースした。同社のモバイルオペレーティングシステムの次のバージョンは、未だに正式名が決まっていないのだ。

発表された範囲では、今回のプレビューには新しい大型機能はない。むしろ今回は、デベロッパーがAndroid　Nの新しい機能を使うためのAPIの拡張に焦点が置かれた。これらのAPI（およびAndroid N SDK）は今回がファイナルとなり、この状態で夏の最終消費者バージョンへ行く。

Googleは、Android Nの現状をベータ級、日常利用可、と見なしている。先日のGoogle I/Oではそう述べられた。たしかにAndroid Nは、かなり初期から安定していた。Googleがテスト用に最新のNexusデバイスを提供し、面倒なインストール作業などを省いたことも、これまでのプレビューにおけるバグ発見などの過程を円滑にしただろう。

Androidデベロッパーは、今のプレビューの上で、マルチウィンドウや通知のダイレクトリプライなど、新しい機能をテストできる。最近改良されたGoogle Playのベータテスト機能により、デベロッパーはユーザーからのフィードバックを早期から得やすくなったので、Googleによると、その機能がこのデベロッパープレビューでも利用されている。

今、最終消費者のための新しい大型機能をこのプレビューに探しているのだが、見つかったらこの記事を更新しよう。でも今のところの感触としては、今回の主な目的はもっぱらバグフィックスにあるようだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

OracleのCEO、Amazon PaperwhiteにJavaを97.5%割引でライセンスしたと証言

OracleとGoogleは、Googleが人気のモバイルプラットフォーム、Androidで、OracleのJavaコード使用している対価を支払うべきだというOracleの訴えを巡って、90億ドル以上の再審を戦い続けている。そしてその過程で、これまで出てこなかった会社の詳細も語られた。今日（米国時間5/17）、名前が上がったのはAmazonだ。Oracleは今日、AmazonのKindle PaperwhiteではJavaが走っているが、それにはOracleがAndroidに対抗するために、97.5%ディスカウントでライセンスすることに同意する必要があったと語った。

詳細を話したのは、Oracleの共同CEO、Safra Catzで、彼女は今日、GoogleがAndroidによってどのような競争を市場にもたらしたかを示す証言を行った。それはゼロとの競争、ということのようだ。証言は、Amazonの電書リーダー、Kindle Paperwhiteが発売された2012年以前に遡る。

「Amazonは…Javaを使って何年も前から［Kindleを］作っていた」と彼女は言った。「その後、Kindle Fireという別製品を作り、そこではAndroidを使った。当時AmazonはJavaをライセンスしていた」

「私のところを通る、顧客によって異なるディスカウント率を扱う承認手続きの中で、AmazonがKindle FireをAndroidで作ろうとしていることを知った」

「今、彼らはPapwerwhiteという新製品を検討していて、そこでJavaを使うかAndroidを使うかを考えている。」

「Googleと競争するために、われわれはPaperwhiteに97.5%のディスカウントを提供することにした。ライバルはタダなので、それまでの価格ではなく、1ドルの物を数セントで提供せざるを得なかった」

ここでよく説明されていないのは、OcracleがAmazonと交渉した際に、Googleが実際どんな役割を果たしたかだ。あるいは、Catzの証言は、Kindle Fireタブレットが出来る前、JavaがKindleを支配していたことを示唆しているのか疑問を持つべきなのだろうか。しかし、もし証言が正しければ、これはライバルたちにとってAndroidに対するさらに大きな問題を強調することになる。「無料」という値札だ。

本誌は、AmazonとGoogleの両社に問い合わせ、Catzのコメントに対する反応を求めている。

法廷では、GoogleはCatzのAmazonに関する証言に対して、反対尋問をしなかった。

Catzは昨日も証言台に立ち、OracleはGoogleを訴えるだけの目的でSun（Javaを最初に作った）を買収した、という再三繰り返される主張について答えた。

真実ではない、と彼女は自らの弁護士の質問に答えて言った。買収は、SunがIBM等のライバルの手に渡ることを防ぐためであり、それはOracle自身が既に自社ビジネスの重要な部分をSunの技術に基づいて構築していたためだった。

[原文へ]

（翻訳：Nob Takahashi / facebook）

ソフトウェアの未来はAPIが支配する

Chet KapoorCrunch Network Contributor

Chet KapoorはApigeeのCEO。以前、IBMでコンテンツ管理および検索サービス担当副社長を、BEA Systemsでは統合グループ担当副社長／ゼネラルマネージャーを務めた。

これからは、ユーザーインターフェースではなく、API ― ソフトウェアプログラム同志のやりとりを統治するルール ― がソフトウェアを支配する時代になる。

Intel CEO Brian Krzanichが8月に同社の年次デベロッパーフォーラムで、モノのインターネットに力を入れることを宣言した時、彼は既に多くの人々が知っていることを強調した ― ソフトウェアエンジニアリング新時代の夜明け。それはAPIファースト設計と呼ばれ、これを採用したデベロッパーは途方もない機会を得る ― そして、そうでないデベロッパー（および会社）は大きなリスクを負う。

Intelは、APIの重要性を認識している唯一の大企業ではない。最近IBMは、 IBM BluemixでAPI管理の分野に参入した。これは企業が自分たちのAPIをデベロッパーがどのように使っているかを知るためのサービスで、そのフィードバックに沿って設計できる。OracleはAPI管理スイートを6月に拡張し、成長する収益機会に乗じようとしている。他のプレーヤーたちも、API中心ソフトウェア開発の準備をここ数年着々と進めている。

通常、新しい製品や機能を設計する際、デベロッパーはまずUI画面をデザインし、ユーザー体験がどうなるかを示すよう求められる。このアプローチが一般的になった理由はいくらでもある。タッチスクリーンは新しい世代のコンピューター利用を可能にし、われわれがハードウェアと対話する方法を根本から変えた。

つながったデバイス、無人走行車、および高度な医療テクノロジーは、APIファースト設計が可能にする新技術のごくわずかな例にすぎない。

AppleとGoogleは、消費者にとっても企業にとっても使いやすさが優先事項であることを証明した。さらに、拡張／仮想現実プラットフォームの台頭は、人々がコンテンツを体験する新しい方法を常に探求していることを証明した。しかしデバイスが急増するにつれ、システム－システム間の対話が、人－システム間の対話を支配し始めた。システムは美しいインターフェースを必要とせず、必要なのは確実に定義された契約だ。彼らはAPIを必要としている。

モバイルだけでも、異なるインターフェースを10種類は思いつくことができる。さらにはウェブ、クライアント－サーバー、シンクライアントと挙げればキリがない。すべてを掌握する唯一の方法はAPIレイヤーに集中することだ。離散化したインターフェースレイヤーについて考えることすら無意味だ ― 特にサービスを提供する立場では。Netflixを見てほしい。あんなにシンプルなユーザーインターフェースを持つビデオストリーミングサービスが、一体どうやって6300万人以上のユーザーが世界中から何百種類ものデバイスを通じて彼らのビデオライブラリーをアクセスする規模を維持できているのか？卓越したAPIだ。

モノのインターネット（IoT）― Business Insider Intelligenceによると近々テクノロジー世界の中心になる ― がこのパラダイムシフトを強く動かしている。このデバイスの多様性は、既に動き始めているトレンドをさらに後押しする。

デバイスが人々を数で上回るようになると、それらをつなぐシステムは驚くほど複雑化する。APIは、こうした接続の基盤を成す。デジタルハードウェア間のモルタルだ。この複雑さが、巨大エコシステムの中で既存レイヤーの上に部品を積み上げるフルスタックエンジニアリングからの、構造的移行を進める舞台を整えた。

APIファースト設計はそれを採用したデベロッパーに途方もない機会を与える ― そしてそうでないデベロッパーには大きなリスクを。

Apple、Googleを始めとする他のIT巨人たちも同じAPI中心の未来を推進している。新たな相互接続分野 ― 典型例を挙げるならApple Watch等のウェアラブルやGoogleの無人走行自動車 ― はわれわれの日常生活におけるAPIの重要性の高まり示している。部屋で一番賢い人たちが何か新しいことを始めた時は、注意を払った方が良い。それはコンピューターや画面がなくなるという意味ではなく、デベロッパーに全く新しい世界の機会が切り開かれる予兆だ。

API中心開発への移行に失敗した結末は、個人にとっても会社にとっても深刻だ。API周辺技術の習得に失敗したデベロッパーは、自身のスキル価値を急速に下げ、職の安定性は減少する。

企業にとって影響はさらに拡大されうる。この技術的革命に乗り損ったスタートアップは競争力を失う。劣った製品を作るかもしれないし、完全に撤退するスタートアップもいるだろう。革新の先端で生きられない会社は縮んでいくパイの一切れになる。

よりつながった世界に突入するにつれ、驚くような新しい可能性が出現する。デベロッパーは「一口大」のものを消費したがる。Amazonがこのアプローチを広めた ― 彼らはデベロッパーにシステムが何をするかを伝え、自らは脇へ退いた。IT企業にとって「伝える」とはAPIを渡すことだ。最善の組み合わせによるプラットフォームの繁栄を可能にするマイクロサービスに向かって、世界が動いてきたのは不思議ではない。

つながったデバイス、無人走行車、および高度医療技術は、APIファースト設計が可能にする新たなテクノロジーのごくわずかな例だ。こうした革新が起きるためには、強固な基盤の上に構築されなくてはならない。それはシステム設計を基盤レイヤー ― API ― から始めることを意味している。

[原文へ]

（翻訳：Nob Takahashi / facebook）

一枚岩的な巨大アプリケーションのITは終わり、多様なサービスを自在に組み合わせる時代に…それを手伝うMuleSoftが急成長

いろんなソフトウェアやサービス、データソースなどを統合して一本化するプラットホームMuleSoftが今日、1億2800万ドルという巨額な資金調達を行った。

そのシリーズGのラウンドを仕切ったのはSalesforce Venturesで、ServiceNowとCisco Investmentsが参加した。またそのほかに、Adage Capital Management、Brookside Capital、Sands Capital Venturesなど、主に上場企業を対象にしているファンドも加わり、さらにこれまでの投資家NEA、Lightspeed Venture Partners、Meritech Capital Partners、Bay Partners、Hummer Winblad Venture Partners、Morgenthaler、およびSapphire Venturesも加わった。

投資家の数がとても多くて、その顔ぶれもさまざまだ。これで同社の総調達額は、2億5850万ドルという途方もない額になる。これだけ大きな資金調達は、通常、IPO近しの兆候だ。

MuleSoftのCEO Greg Schottはこう語る: “公開企業向けの機関からの投資を受け入れる決定をしたのは、そういう関係を築きたかったし、公開市場の投資家たちのやり方を知りたいと思ったからだ”。

彼によると、確かに規模的には公開企業になってもおかしくないし、今回の資金調達をその方向へのステップと取られてもしょうがないが、当然ながらその日程等を今明らかにすることはできない。彼曰く、“Q1の決算からの予測では、今年の年商は1億ドルに達するだろう。うちは急成長しているし、上場してもよい規模だ。すでにその気はあるから、残る問いはそのタイミングだ”。しかし現時点では、プライベートラウンドで資金を調達して成長を継続するべき、と彼は判断したのだ。

MuleSoftは、さまざまなアプリケーションやデータやデバイスを結びつけるプラットホームを提供している。確かに、今、そういう需要は多い。今回のように多数かつ多様な投資家が、同社の継続的な成長に関心を示すのも、当然だ。

Schottによると、20年か30年ぐらい前までは、企業は一枚岩的なアプリケーションを作って、それにありとあらゆる複雑なことをさせていた。でも今では、あらゆるものが細切れになっている。そういう細片をうまく糊付けして使うのが、今のやり方だ。各細片は、どこかのSaaSのこともあれば、何かのアプリケーションのこともあり、あるいはインターネットに接続されたデバイスのこともある。非常に多様だ。

同社が急成長している理由も、いろんなものを互いに接続して使うという需要が、今はものすごく大きいからだ。MuleSoftのプラットホームを利用すると、それが簡単迅速にできる。各部を結びつけるためにいちいちコードを書かなくても、MuleSoftがすべて、面倒を見てくれる。

ServiceNowやSalesforceのようなSaaS企業がMuleSoftに関心を持つのも、そのためだ。彼らは、顧客がさまざまなサービスを縫い合わせることの重要性を、よく理解している。オープンなAPIがあるだけでは、それらを使いこなす仕事がたいへんになるが、MuleSoftのようなミドルマンがいれば、複数のサービスをまとめてくれるのだ。

“うちはAPIも提供しているから、コードを手書きする必要がない。それによってITのコストが下がり、顧客企業内の開発過程もスピードアップする”、と彼は述べる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

CiscoがコミュニケーションAPIのプロバイダ（Twilio的な）Tropoを買収

Ciscoといえば、誰もがネットワーキング機器のメーカーだと思う。でもCiscoには、WebExで知られるように、通信（コミュニケーション）やコラボレーションの側面もある。そのCiscoが今日（米国時間5/7）は、Tropoの買収を発表した。TropoはTwilioに似たコミュニケーションプラットホームで、デベロッパはここのAPIを使って、電話やメッセージングなどのコミュニケーション機能を自分のアプリケーションに加えることができる。

昨日（きのう）も書いたように、今のデベロッパはAPIを利用することによってアプリケーションにさまざまな機能を簡単迅速に加えられる。中でもデベロッパにいちばん人気があるのが、コミュニケーションの機能だ。先週行われたTechCrunch Disruptのハッカソンでも、何か重要なことが起きたらテキストメッセージを発信する、という機能をアプリケーションに持たせていたものが多かった。

コミュニケーションAPIのプロバイダとしてはTwilioがいちばんよく知られているが、でもTropoを買ったことによってCiscoは、20万あまりのデベロッパのコミュニティにアクセスできるようになる（数はCiscoの発表による）。Tropoはそのプロダクトをデベロッパに無料で提供しているが、アプリケーションのユーザがそのアプリケーションのコミュニケーション機能（==TropoのAPI）を使うたびに、課金が発生する（それをユーザでなくデベロッパが払うなら‘無料’とは言えない）。Ciscoがどういう料金モデルを採るのか、それはまだ明らかでない。

Tropo workflow chart.

Tropoのチームは、CiscoのCollaboration and Communications Groupに加わる。大企業の傘下に入ったチームとその熱心なコミュニティが、独立時代の活気を失わないようにすることが、Cisco側の重要な課題だろう。大が小を買うときには、いつもこの問題がつきまとう。

今年の初めにIBMがAlchemyAPIを買収したときも、同じ問題を抱えた。ITの巨大老舗企業に買収されたこの機械学習ツールにも、大きな熱心なコミュニティが形成されていたのだ。

CiscoはTropoのチームを歓迎するブログ記事の中で、この点に触れている: “両者が協力してCiscoのプラットホームを拡張し、現代的なAPIを通してサードパーティのエンドポイントやアプリケーションに奉仕し、Ciscoがデベロッパのコミュニティにより良い貢献をできるようにしていきたい”。もちろんこれは、今の事実ではなくて、あくまでも目標だ。

一方でTropoのユーザであるデベロッパたちは今後、Ciscoのより大きなエコシステムの一員になり、その多様なリソースにアクセスできるようになる。Ciscoのような成熟企業が小企業の買収を成功させるためには、この側面を強調することが重要だろう。

なお、買収の価額等は公表されていない。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

良質なAPIドキュメンテーションと共にAPI利用者のためのデベロッパハブも提供するReadMe

Y Combinatorで孵化したReadMeは、デベロッパ向けにAPIを提供している企業が、APIの良質なドキュメンテーションを容易に作れるようにしてくれる。

今はほとんどのサービスがAPIを公開しているから、それらを利用すれば自分が作るアプリケーションやサービスに高度な機能を簡単に実装できる。でも、APIをデベロッパにぜひ使っていただきたい、と願っている企業から見ると、そこにはデベロッパたちのマインドシェアを奪い合う激しい競争がある。

デベロッパには、自分のところのマップを使ってもらいたいし、自分のところのレストランレビューデータベースを使ってほしい、というとき、どうしたらいいか？　APIの機能と特長を、デベロッパの心に強く焼き付けるしかない。誰もが、自分が最高の好印象を持ったAPIを、使おうとするだろう。

でもStripeの速い成長が示しているように、機能が比較的安定している場合でも、その技術の利用や展開が果たして容易か、ということは、また別の問題だ。Stripeのドキュメンテーションには、その決済・支払APIの使い方がとても分かりやすく書かれている（良質なAPIドキュメンテーションのお手本、と言われている）。これだけやさしく書かれていれば、有料会員制を試してみたいと思っている個人のブロガーでも、あるいはもっとスケールして売上を増加させたいと願っているスタートアップでも、容易にその望み…決済支払機能…を実装できるだろう。

ReadMeはProduct Huntでとても好評だった。ローンチがやや遅れたにもかかわらず、大きな関心が集まった。同社は早くから利益を上げるようになり、また、オープンソースの人たちも注目した。オープンソースのチームは、このサービスを無料で使える。

ローンチしたばかりのクローズドソースのプロジェクトはReadMeの上にデベロッパハブを作って、そこからドキュメンテーションを提供できる。サービスの基盤にあるAPIキーの生成機能も便利だが、デベロッパにいちばん人気があるのは月額60ドルのサービスだ。ユーザはそこでカスタムドメインとHTML/CSSによるレイアウトを利用でき、またAPIエクスプローラーがドキュメンテーションの中からAPIの機能を試行/試用させてくれる。まさに、デベロッパハブ的な機能だ。

ReadMeの協同ファウンダGabriel Dillonによると、今では50万人のデベロッパが、さまざまなオープンソースプロジェクトや、Yammer、Getaround、IndiegogoなどのAPIのドキュメンテーションに、ReadMe上でアクセスしている。

スタートアップのデザインやエンジニアリングを指導しているGregory Kobergerによると、デベロッパが自分の目的に応じて最適のAPIを検索〜発見できるようになれば、ReadMeの魅力はさらに向上する。その点に関しては、最終的には、ユーザの閲覧履歴やGitHubのプロフィールなどからReadMe自身が判断して、お役に立ちそうなAPIをリコメンデーションしてくれるようになるだろう。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

複数（20あまり）のアクセス分析サービスのAPIを簡単に呼び出せるSegment.io

Segment.ioは、Y Combinatorが育てたアクセス分析系のスタートアップだ。その売りは、デベロッパが複数のアクセス分析サービスのAPIを自分のアプリケーションに統合できること。今サポートしているのは、20のアクセス分析プロバイダで、その中にはもちろんGoogle Analytics、KISSmetrics、Mixpanel、Chartbeatなどの有名どころもある。またHubSpotやSalesforceのような、アクセス分析専業というより、企業向けの経営〜マーケティングサービスも含まれる。

クライアントサイドとサーバサイド両方の分析をサポートするが、近くモバイルにも対応する予定だ。

ファウンダPeter Reinhardt、Ilya Volodarsky、Calvin French-Owenの三名はMITのルームメイト、四人目のIan Storm Taylorandはロードアイランドのデザイン学校出身だ。四人とも大学〜学校をドロップアウトしてY Combinatorの2011年夏の育成事業に参加した。最初はGoogle AnalyticsやKISSmetricsに対抗するプロダクトを作るつもりだったが、自分たちのプロダクトに乗り換えてくれる人はそう簡単にいない。しかし彼らが作っていた、分析サービスとAPI呼び出しを合わせたようなライブラリAnalytics.jsは好評だったので、それをオープンソース化してGitHubに載せた。

“そのオープンソースバージョンは、坂を転がり落ちる雪だるまのように勝手に成長していった”、とReinhardtは回顧する。“そこで、われわれも悟った。デベロッパたちが欲しているのは、ビューティフルでシンプルな分析APIなんだ、と”。方向転換は12月に行われた。そのときオープンソースバージョンのユーザは1800名いたが、それはそのまま引き継いだ。そして12月からは、有料バージョンの開発を開始した。今日（米国時間1/25）現在では数千の登録会員がおり、300あまりの現在進行中のプロジェクトが、このサービスを利用している。

難しいのは、アクセス分析に関してはAPIに標準性がなくて、各社ばらばらであることだ。リンク連鎖追跡が得意なのがあれば、カスタムイベントの追跡が得意なのや、メールのターゲティング専門みたいのもある。“デベロッパは、これらのAPIを全部ながめ渡して、自分の目的にどれとどれを使えるか判断しなければならない。それは彼らにとって未知の世界だから、悪夢のような作業になる”、とReinhardtは言う。

そこでSegment.ioでは、単一のシンプルなAPIがすべてのアクセス分析プロバイダをカバーするようにしている。APIの加除も簡単にできるので、デベロッパの時間を大いに節約する。Reinhardtによると、Segment.ioを使えば、自分のアプリケーションにアクセス分析の部分を盛り込む作業が2時間以内で終わる。SalesforceやMarketoのようなエンタプライズサービスのAPIによる統合は、もっと大きな時間の節約量になる。“連中のAPIを直接使おうとしたら、それは黴の生えたようなSOAP XMLだからね。今のデベロッパはRESTしか使わないのに”。Segment.ioのユーザの中には、以前は統合に数か月を要したが、今では数時間で済む、という人たちもいる。

Segmentio-example

火曜日（米国時間1/22）に同社は、これまでのブラウザ直接のJavaScriptライブラリに加えて、RubyやNode.js、Python、Java、それに.NETから呼び出せるライブラリをローンチした。今は、ユーザからのリクエストの多いPHP用を制作中だ。また、サポートするアクセス分析プロバイダも、週に2〜3ずつ増やしていく。来週は、Pardotが加わる。

同社からホストされるクライアントサイドのライブラリ（主にAnalytics.js）は無料だが、サーバサイドのライブラリは有料だ。最低料金の月額30ドルではサーバサイドのAPI呼び出し100万回まで、150ドルでは1000万回までだ。HubSpot、Marketo、Omniture、Salesforceなどエンタプライズ向けの統合は150ドルの方の有料サービスに含まれる。なお、メールのサポートは30ドルでも150ドルでもどちらにもある。

integrations_small

Segment.ioが提供する価値は、開発時間の節約だ。しかしもっと広い意味では、アプリケーションがよりデータ駆動型になるというメリットがある。Reinhardtはそう主張するが、それは、シンプルなAPIをちょっと使っていろんなアクセス分析を呼び出すだけで実現するのだ。“これまでは、デベロッパが自分のアプリケーションの中で複数のアクセス分析の結果を利用しようとすると、たいへんな作業になった。たいへんすぎて、やらないデベロッパも多かった。でも、これからは違う”、とReinhardtは自負を述べる。

Analytics.jsのユーザ登録はここで。

Segment.ioは、NEA、General Catalyst、およびそのほかのエンジェル投資家たちから計60万ドルのシード資金を調達している。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）