そのため、ファイルごとのパッチは、圧縮されていないデータで検出された差分に基づきます。パッチの生成にあたって、まず古いファイルと新しいファイルの両方を解凍し、差分を計算します(ここでは、まだ bsdiff を利用しています)。次に、パッチを適用するため、古いファイルを解凍して圧縮されていないコンテンツに差分を適用し、新しいファイルを再圧縮します。その際に、端末上の APK が Play Store 上の APK とバイト単位で完全に一致していることを確認する必要があります(この理由については、
APK 署名スキーマ v2 をご覧ください)。
新しいファイルの再圧縮には、2 つの問題があります。1 つ目の問題は、Deflate の設定によって Deflate の出力が色々と変わることです。そもそも、圧縮の際にどのような設定が使われたのかはわかりません。2 つ目は、Deflate には多くのバージョンが存在しており、ユーザーの端末上にある Deflate が適切なバージョンか確認する必要があります。
幸運にも、Play Store のアプリを分析したところ、Play Store のほぼすべての Deflate コンテンツで、zlib(もっとも普及している Deflate ライブラリ)に基づいた、互換性がある最近のバージョンの Deflate が使われていることがわかりました。さらに、実質的に使われている設定は、デフォルト(level=6)と最大(level=9)の圧縮設定だけでした。
以上のことを踏まえると、元々の Deflate 設定を検出して再現できると言えます。つまり、データを解凍し、パッチを適用してデータを再圧縮し、元々アップロードされたものと
まったく同じバイト列 を作ることができます。
ただしこの方式には、端末側で必要な処理能力が高くなるという欠点もあります。最近(たとえば、2015 年以降)の端末では、再圧縮には 1 メガバイトあたり 1 秒少しかかり、古い端末や能力が低い端末はさらに時間がかかります。現時点の分析によると、平均で、パッチのサイズが半分になるとパッチの適用(再圧縮を含めたファイルごとのパッチ適用)にかかる時間は倍になります。
今のところ、この新しいパッチ テクノロジーの利用は自動アップデートのみに制限しています。これは通常、夜間にスマートフォンが電源に接続され、ユーザーが使用していない可能性が高いときにバックグラウンドで行われるアップデートです。これによって、ユーザーが手動でアプリをアップデートする際に、いつもより長く待たなければならないという事態を回避しています。
ファイルごとのパッチ適用の効率性
以下に、すでにファイルごとのパッチ適用を使っているアプリのアップデートの例を示します。
アプリ
元のサイズ
以前の(bsdiff)パッチサイズ
(元のサイズに対する割合)
ファイルごとのパッチによるサイズ(元のサイズに対する割合)
71.1 MB
13.4 MB(-81%)
8.0 MB(-89%)
32.7 MB
17.5 MB(-46%)
9.6 MB(-71%)
17.8 MB
7.6 MB(-57%)
7.3 MB(-59%)
18.9 MB
17.2 MB(-9%)
13.1 MB(-31%)
52.4 MB
19.1 MB(-64%)
8.4 MB(-84%)
16.2 MB
7.7 MB(-52%)
1.2 MB(-92%)
免責事項: 現在、ファイルごとのパッチはバックグラウンドでのみ利用されており、インタラクティブなアップデートには利用されていないため、手動で「アップデート」を押した際に表示されるパッチサイズとは異なる場合があります。
データを節約してユーザー(そしてデベロッパー)をハッピーに
以上の変更は、10 億人以上の Android ユーザー コミュニティが、最小限のデータ量でアプリの定期アップデートを行えるように設計されています。一番の長所は、デベロッパーは何もする必要がないことです。このアップデートのサイズ削減は、無償で行われます。
技術的な詳細など、ファイルごとのパッチ適用についてさらに詳しく知りたい方は、
Archive Patcher GitHub プロジェクト をご覧ください。ソースコードを含む情報を閲覧できます。ファイルごとのパッチ適用は、完全なオープンソースです。
APK サイズをさらに削減したいデベロッパーの方は、
APK サイズ削減のための一般的な推奨事項 もご覧ください。
Posted by
Khanh LeViet - Developer Relations Team
[この記事は Andrew Hayden、Google Play ソフトウェア エンジニアによる Android Developers Blog の記事 "Saving Data: Reducing the size of App Updates by 65% " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
Android ユーザーは、Google Play で数百億のアプリやゲームをダウンロードしています。また、デベロッパーは頻繁にアプリをアップデートして、ユーザーにすばらしいコンテンツを提供したり、セキュリティを改善したり、ユーザー エクスペリエンス全般を向上させたりしています。こういったアップデートでは、多くのデータをダウンロードする必要があります。しかしユーザーは、端末で消費したデータ量を気にしています。Google は今年、bsdiff アルゴリズム (Colin Percival 氏が開発) の利用開始を発表しました。bsdiff の利用によって、アプリの完全な APK のサイズと比べると、アップデートのサイズを平均 47% 減らすことができました。
本日(*原文公開当時)は、さらにアップデートのサイズを削減する新たなアプローチをお知らせします。それは、ファイルごとのパッチ適用 です。 ファイルごとのパッチ適用によるアプリのアップデートでは、完全なアプリよりも平均 65% 小さくなり、場合によっては 90% 以上小さくなることもあります。
以前のアプローチと比較すると、なんと 1 日あたり最大 6 ペタバイトのユーザーデータを節約できることになります。
この方法では、アプリの新しいバージョンを入手する際に、Google Play から端末にアプリの旧版と新版との 差分 を記述したパッチが送信されます。
たとえば、まもなく出版される本の著者が 1 文だけ変更したいとします。全文を送り直すよりも、編集者にその変更内容を伝える方がはるかに簡単です。同じように、パッチを使うと APK 全体をダウンロードするよりもはるかにサイズが小さくなり、ダウンロード時間も短縮されます。
ファイルごとのパッチ適用で使われるテクニック
Android アプリは APK としてパッケージ化されています。APK は、特殊なルールに基づいた ZIP ファイルです。ZIP ファイル(と APK)の中にあるほとんどのコンテンツは、Deflate と呼ばれるテクノロジーを使って圧縮されています。Deflate はデータの圧縮には優れていますが、元の(圧縮されていない)コンテンツの変更点を特定するのが非常に難しくなるという欠点もあります。元のコンテンツをわずかに変更しただけでも(本の中の 1 語だけ変更するように)、Deflate が出力する圧縮データは まったく異なる ものに見える場合があります。 元の コンテンツの差分を作るのは簡単でも、 圧縮された コンテンツの差分を作るのはとても難しいため、パッチは非効率になってしまいます。
左側の圧縮されていないテキストを 1 文字変更しただけで、右側の圧縮されたテキストがどのくらい変わるかをご覧ください。
そのため、ファイルごとのパッチは、圧縮されていないデータで検出された差分に基づきます。パッチの生成にあたって、まず古いファイルと新しいファイルの両方を解凍し、差分を計算します(ここでは、まだ bsdiff を利用しています)。次に、パッチを適用するため、古いファイルを解凍して圧縮されていないコンテンツに差分を適用し、新しいファイルを再圧縮します。その際に、端末上の APK が Play Store 上の APK とバイト単位で完全に一致していることを確認する必要があります(この理由については、APK 署名スキーマ v2 をご覧ください)。
新しいファイルの再圧縮には、2 つの問題があります。1 つ目の問題は、Deflate の設定によって Deflate の出力が色々と変わることです。そもそも、圧縮の際にどのような設定が使われたのかはわかりません。2 つ目は、Deflate には多くのバージョンが存在しており、ユーザーの端末上にある Deflate が適切なバージョンか確認する必要があります。
幸運にも、Play Store のアプリを分析したところ、Play Store のほぼすべての Deflate コンテンツで、zlib(もっとも普及している Deflate ライブラリ)に基づいた、互換性がある最近のバージョンの Deflate が使われていることがわかりました。さらに、実質的に使われている設定は、デフォルト(level=6)と最大(level=9)の圧縮設定だけでした。
以上のことを踏まえると、元々の Deflate 設定を検出して再現できると言えます。つまり、データを解凍し、パッチを適用してデータを再圧縮し、元々アップロードされたものと まったく同じバイト列 を作ることができます。
ただしこの方式には、端末側で必要な処理能力が高くなるという欠点もあります。最近(たとえば、2015 年以降)の端末では、再圧縮には 1 メガバイトあたり 1 秒少しかかり、古い端末や能力が低い端末はさらに時間がかかります。現時点の分析によると、平均で、パッチのサイズが半分になるとパッチの適用(再圧縮を含めたファイルごとのパッチ適用)にかかる時間は倍になります。
今のところ、この新しいパッチ テクノロジーの利用は自動アップデートのみに制限しています。これは通常、夜間にスマートフォンが電源に接続され、ユーザーが使用していない可能性が高いときにバックグラウンドで行われるアップデートです。これによって、ユーザーが手動でアプリをアップデートする際に、いつもより長く待たなければならないという事態を回避しています。
ファイルごとのパッチ適用の効率性
以下に、すでにファイルごとのパッチ適用を使っているアプリのアップデートの例を示します。
アプリ
元のサイズ
以前の(bsdiff)パッチサイズ
(元のサイズに対する割合)
ファイルごとのパッチによるサイズ(元のサイズに対する割合)
71.1 MB
13.4 MB(-81%)
8.0 MB(-89%)
32.7 MB
17.5 MB(-46%)
9.6 MB(-71%)
17.8 MB
7.6 MB(-57%)
7.3 MB(-59%)
18.9 MB
17.2 MB(-9%)
13.1 MB(-31%)
52.4 MB
19.1 MB(-64%)
8.4 MB(-84%)
16.2 MB
7.7 MB(-52%)
1.2 MB(-92%)
免責事項: 現在、ファイルごとのパッチはバックグラウンドでのみ利用されており、インタラクティブなアップデートには利用されていないため、手動で「アップデート」を押した際に表示されるパッチサイズとは異なる場合があります。
データを節約してユーザー(そしてデベロッパー)をハッピーに
以上の変更は、10 億人以上の Android ユーザー コミュニティが、最小限のデータ量でアプリの定期アップデートを行えるように設計されています。一番の長所は、デベロッパーは何もする必要がないことです。このアップデートのサイズ削減は、無償で行われます。
技術的な詳細など、ファイルごとのパッチ適用についてさらに詳しく知りたい方は、Archive Patcher GitHub プロジェクト をご覧ください。ソースコードを含む情報を閲覧できます。ファイルごとのパッチ適用は、完全なオープンソースです。
APK サイズをさらに削減したいデベロッパーの方は、APK サイズ削減のための一般的な推奨事項 もご覧ください。
Posted by Khanh LeViet - Developer Relations Team
var requests = [
{"createTable": {
"elementProperties":
{"pageObjectId": slideID },
"rows":8,
"columns":4
}},
{"createSheetsChart": {
"spreadsheetId": sheetID ,
"chartId": chartID ,
"linkingMode":"LINKED",
"elementProperties": {
"pageObjectId": slideID ,
"size": {
"height": { ... },
"width": { ... }
},
"transform": { ... }
}
}}
];
少なくとも 1 つのリクエストを格納した変数(ここでは、上の例に合わせて
requests
とします)があり、その中にスプレッドシートの
sheetID
と
chartID
、さらにプレゼンテーション ページの
slideID
が含まれているものとします。これを API に渡し、
presentations().batchUpdate()
コマンドを 1 回呼び出します。この処理は、API のサービス エンドポイントが
SLIDES
である場合、Python で次のように書くことができます。
SLIDES .presentations().batchUpdate(presentationId= slideID ,
body= requests ).execute()
表の作成はとても単純です。グラフの作成では、魔法のような機能を使うことができます。その 1 つが、
linkingMode
です。これに「LINKED」という値を設定しておくと、スプレッドシートのデータが変更された際に(スプレッドシート内のグラフが変わる場合)プレゼンテーションのスライドでもグラフが更新され、最新のイメージが表示されます。この更新は、API またはスライドのユーザー インターフェースによって行われます。
linkingMode
の値に「NOT_LINKED_IMAGE」を選択すると、データに応じて変更されることのない、旧来の静的なイメージになります。この機能の詳細については、グラフの作成に関する
ドキュメント や、両方の値を使った API リクエストの動作を紹介した動画をご覧ください。
動画で取り上げたコードサンプルの
全容 については、
さらに詳しく取り上げている投稿 をご覧ください。両方の API を駆使したアプリの登場を楽しみにしています。
Posted by
Eiji Kitamura - Developer Relations Team
[この記事は Wesley Chun (@wescpy )、G Suite デベロッパー アドボケートによる G Suite Developers Blog の記事 "Generating slides from spreadsheet data " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
先日、G Suite チームは Google Slides API を初めて発表 し、新たな可能性を打ち出しました。たとえば、スプレッドシートやデータベース内に すでに存在する データを 元に プログラムでプレゼンテーションやスライド コンテンツを生成できるようになります。この API のどこがすばらしいのかというと、プレゼンテーションにおけるメリットの 1 つは、データベースやスプレッドシートのデータを取り出して、視覚的にわかりやすいスライドを作成できることです。そのようなデータを反映した情報を、経営陣や潜在顧客に伝えたい場合に便利です。
本日ご紹介する DevByte 動画では、Sheets API と Slides API の両方を使った簡単なアプリケーションで、各 API の使い方を説明しています。サンプルアプリでは、まず Sheets API を使って、必要なすべてのデータをスプレッドシートから読み込んでいます。次に、Slides API で新しいスライドを作成し、そのスライドにスプレッドシートのデータを 設定 しています。
VIDEO
スライドは、API リクエストを送信して操作できます。Google Sheets API と同じく、リクエストは JSON ペイロード形式で送信します。次に示すのは、スライドに表を作り、スプレッドシートからグラフをインポートする擬似 JavaScript コードです。リクエストを行う際は、このような配列を作成します。
var requests = [
{"createTable": {
"elementProperties":
{"pageObjectId": slideID },
"rows":8,
"columns":4
}},
{"createSheetsChart": {
"spreadsheetId": sheetID ,
"chartId": chartID ,
"linkingMode":"LINKED",
"elementProperties": {
"pageObjectId": slideID ,
"size": {
"height": { ... },
"width": { ... }
},
"transform": { ... }
}
}}
];
少なくとも 1 つのリクエストを格納した変数(ここでは、上の例に合わせてrequests
とします)があり、その中にスプレッドシートのsheetID
と chartID
、さらにプレゼンテーション ページのslideID
が含まれているものとします。これを API に渡し、presentations().batchUpdate()
コマンドを 1 回呼び出します。この処理は、API のサービス エンドポイントが SLIDES
である場合、Python で次のように書くことができます。
SLIDES .presentations().batchUpdate(presentationId= slideID ,
body= requests ).execute()
表の作成はとても単純です。グラフの作成では、魔法のような機能を使うことができます。その 1 つが、linkingMode
です。これに「LINKED」という値を設定しておくと、スプレッドシートのデータが変更された際に(スプレッドシート内のグラフが変わる場合)プレゼンテーションのスライドでもグラフが更新され、最新のイメージが表示されます。この更新は、API またはスライドのユーザー インターフェースによって行われます。linkingMode
の値に「NOT_LINKED_IMAGE」を選択すると、データに応じて変更されることのない、旧来の静的なイメージになります。この機能の詳細については、グラフの作成に関するドキュメント や、両方の値を使った API リクエストの動作を紹介した動画をご覧ください。
動画で取り上げたコードサンプルの 全容 については、さらに詳しく取り上げている投稿 をご覧ください。両方の API を駆使したアプリの登場を楽しみにしています。
Posted by Eiji Kitamura - Developer Relations Team
先週、Nougat のアップデートを公開しました。Pixel および Pixel XL 端末と、サポート対象となるすべての Nexus 端末向けの Android 7.1.1 です。また、端末メーカーが最新版の Android を入手できるように、Android 7.1.1 のソースコードが
Android Open Source Project (AOSP)に登録されます。
Android 7.1.1 がユーザーに向けて公式にリリースされるこのタイミングで、ぜひアプリの対応を行ってください。
Android 7.1.1 の機能
Android 7.1.1 は、Pixel および Pixel XL 端末ですでに利用できるようになっている機能を土台として、
ユーザー向けのさまざまな新機能 の追加や、基盤となる Android 7.1 プラットフォーム(API レベル 25)に対する最適化やバグの修正が行われている増分リリースです。
デベロッパー機能の詳細については、
アプリ ショートカット 、
円形アイコン リソース、
イメージ キーボードのサポート などをご覧ください。
デベロッパー機能の完全なリストは、こちら で確認できます。API レベル 25 の詳細については、
API の差分 と
API リファレンス をご覧ください。
Android 7.0 Nougat の主な動作変更の詳細やデベロッパー機能など、すべての
Nougat デベロッパー リソースの概要はこちら から参照できます。
ユーザー端末にも順次展開
Android 7.1.1 は本日より公開され、今後数週間ですべての対象端末で利用できるようになる予定です。Pixel および Pixel XL 端末に加え、Nexus 5X、Nexus 6P、Nexus 6、Nexus 9、Nexus Player、Pixel C、General Mobile 4G(Android One)の各端末に、Over-the-air(OTA)アップデートが配信されます。
Android ベータ版プログラム に登録している端末にも、この最終版が配信されます。通常どおり、
このアップデートを手動でダウンロードして端末に書き込む こともできます。
また、数か月後にパートナーの端末メーカーが自社の端末を Android 7.1.1 にアップデートできるよう、その準備も進めています。
アプリを確実に対応させる
この機会にアプリの互換性をテストし、
円形アイコン や
アプリ ショートカット などを追加して Android 7.1.1 でのアプリの外観を最適化してください。アプリは API 25 でコンパイルすることをお勧めします。できれば、ターゲットも API 25 に設定します。詳細については、
最近の投稿 をご覧ください。
最終版プラットフォームでは、Android Studio のプラットフォーム ツールやビルドツール、API レベル 25 エミュレータ システム イメージもアップデートされています。最新版のサポート ライブラリ(
25.0.1 )もリリースされ、API レベル 25 以前を実行している端末に、
イメージ キーボードのサポート 、
ボトム ナビゲーション などの機能を追加できます。
Pixel および Nexus 端末の最終テストをサポートするため、
Nexus Images ページでダウンロード可能なファクトリー イメージや OTA イメージも提供しています。テスト対象端末を拡大するため、ぜひ
Firebase Test Lab for Android を活用し、クラウドでテストを実行してください。12 月末までテストが無料になります。
最終テストの終了後には、
Google Play Developer Console でアプリをアルファ版、
ベータ版 、さらに製品版のチャンネルに公開できます。
次のステップ
Developer Preview ビルドに対して報告されたバグのうち、未対応のものについてはまもなく対応が完了する予定ですが、フィードバックは今後も大歓迎です。Preview Tracker に記録した問題がまだ解消されていないという方は、AOSP Issue Tracker で Android 7.1 に対して
新しく問題を送信 してください。
デベロッパー コミュニティ でも、引き続きフィードバックや質問をお寄せいただけます。
8 月にお知らせしたように Android Nougat は定期メンテナンス サイクルに移っており、次の増分アップデートに向けた微調整やバグの修正作業もすでに始まっています。現在、対象端末をお持ちで
Android ベータ版プログラム に登録している場合、その端末は次の Android Nougat リリースのプレビュー アップデートが利用可能になり次第、自動的に受信します。アップデートを自動で受信したくない場合は、
ベータ版サイト で端末を登録解除してください。
デベロッパー プレビューに参加いただき、どうもありがとうございます。
アンケートに回答 し、今年のプレビューが皆さんのニーズをどの程度満たしていたかをお知らせください。いただいたフィードバックは、将来のリリース計画に反映いたします。
Posted by
Yuichi Araki - Developer Relations Team
[この記事は Dave Burke、エンジニアリング担当 VP による Android Developers Blog の記事 "Welcoming Android 7.1.1 Nougat " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
Android 7.1.1 Nougat!
先週、Nougat のアップデートを公開しました。Pixel および Pixel XL 端末と、サポート対象となるすべての Nexus 端末向けの Android 7.1.1 です。また、端末メーカーが最新版の Android を入手できるように、Android 7.1.1 のソースコードが Android Open Source Project (AOSP)に登録されます。
Android 7.1.1 がユーザーに向けて公式にリリースされるこのタイミングで、ぜひアプリの対応を行ってください。
Android 7.1.1 の機能
Android 7.1.1 は、Pixel および Pixel XL 端末ですでに利用できるようになっている機能を土台として、ユーザー向けのさまざまな新機能 の追加や、基盤となる Android 7.1 プラットフォーム(API レベル 25)に対する最適化やバグの修正が行われている増分リリースです。
デベロッパー機能の詳細については、アプリ ショートカット 、円形アイコン リソース、イメージ キーボードのサポート などをご覧ください。デベロッパー機能の完全なリストは、こちら で確認できます。API レベル 25 の詳細については、API の差分 と API リファレンス をご覧ください。
Android 7.0 Nougat の主な動作変更の詳細やデベロッパー機能など、すべての Nougat デベロッパー リソースの概要はこちら から参照できます。
ユーザー端末にも順次展開
Android 7.1.1 は本日より公開され、今後数週間ですべての対象端末で利用できるようになる予定です。Pixel および Pixel XL 端末に加え、Nexus 5X、Nexus 6P、Nexus 6、Nexus 9、Nexus Player、Pixel C、General Mobile 4G(Android One)の各端末に、Over-the-air(OTA)アップデートが配信されます。Android ベータ版プログラム に登録している端末にも、この最終版が配信されます。通常どおり、このアップデートを手動でダウンロードして端末に書き込む こともできます。
また、数か月後にパートナーの端末メーカーが自社の端末を Android 7.1.1 にアップデートできるよう、その準備も進めています。
アプリを確実に対応させる
この機会にアプリの互換性をテストし、円形アイコン やアプリ ショートカット などを追加して Android 7.1.1 でのアプリの外観を最適化してください。アプリは API 25 でコンパイルすることをお勧めします。できれば、ターゲットも API 25 に設定します。詳細については、最近の投稿 をご覧ください。
最終版プラットフォームでは、Android Studio のプラットフォーム ツールやビルドツール、API レベル 25 エミュレータ システム イメージもアップデートされています。最新版のサポート ライブラリ(25.0.1 )もリリースされ、API レベル 25 以前を実行している端末に、イメージ キーボードのサポート 、ボトム ナビゲーション などの機能を追加できます。
Pixel および Nexus 端末の最終テストをサポートするため、Nexus Images ページでダウンロード可能なファクトリー イメージや OTA イメージも提供しています。テスト対象端末を拡大するため、ぜひ Firebase Test Lab for Android を活用し、クラウドでテストを実行してください。12 月末までテストが無料になります。
最終テストの終了後には、Google Play Developer Console でアプリをアルファ版、ベータ版 、さらに製品版のチャンネルに公開できます。
次のステップ
Developer Preview ビルドに対して報告されたバグのうち、未対応のものについてはまもなく対応が完了する予定ですが、フィードバックは今後も大歓迎です。Preview Tracker に記録した問題がまだ解消されていないという方は、AOSP Issue Tracker で Android 7.1 に対して新しく問題を送信 してください。デベロッパー コミュニティ でも、引き続きフィードバックや質問をお寄せいただけます。
8 月にお知らせしたように Android Nougat は定期メンテナンス サイクルに移っており、次の増分アップデートに向けた微調整やバグの修正作業もすでに始まっています。現在、対象端末をお持ちで Android ベータ版プログラム に登録している場合、その端末は次の Android Nougat リリースのプレビュー アップデートが利用可能になり次第、自動的に受信します。アップデートを自動で受信したくない場合は、ベータ版サイト で端末を登録解除してください。
デベロッパー プレビューに参加いただき、どうもありがとうございます。アンケートに回答 し、今年のプレビューが皆さんのニーズをどの程度満たしていたかをお知らせください。いただいたフィードバックは、将来のリリース計画に反映いたします。
Posted by Yuichi Araki - Developer Relations Team
Windows での TensorFlow のネイティブ サポートは、TensorFlow をオープンソース化した後、最初に
寄せられたリクエスト の 1 つでした。Windows ユーザーの中には、Docker コンテナで TensorFlow を実行している方もいます。しかし私たちはそれよりもっと完全に近い、たとえば GPU のサポートも含む機能を提供したいと考えていました。
今回の TensorFlow r0.12 のリリースに合わせて、Windows 7、10、Server 2016 向けのネイティブ TensorFlow パッケージを提供いたします。このリリースでは、CUDA 8 対応の GPU で TensorFlow トレーニングを高速化できます。
この最新リリースは、
PyPI の pip パッケージ として公開されていますので、次のコマンド 1 つで TensorFlow をインストールできます。
C:\> pip install tensorflow
GPU サポートは、次のコマンドでインストールできます。
C:\> pip install tensorflow-gpu
Windows サポートの詳細を含む r0.12 の新機能の詳細については、
リリースノート をご覧ください。
多くの方に TF を最高速でご利用いただけるようになりました。今後のリリース情報をいち早く受け取れるように、ぜひ Twitter で
@tensorflow をフォローしてください。
謝辞
このリリースは、たくさんの方の貢献によって実現できました。とりわけ、Windows のサポートに大きく貢献してくださった Microsoft の Guenther Schmuelling 氏と Vit Stepanovs 氏に感謝いたします。
Posted by
Kazunori Sato - Google Cloud Platform
[この記事は Derek Murray 、ソフトウェア エンジニアによる Google Developers Blog の記事 "TensorFlow 0.12 adds support for Windows " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
本日(*原文公開当時)、TensorFlow の Windows 暫定サポートをリリースしました。
Windows での TensorFlow のネイティブ サポートは、TensorFlow をオープンソース化した後、最初に寄せられたリクエスト の 1 つでした。Windows ユーザーの中には、Docker コンテナで TensorFlow を実行している方もいます。しかし私たちはそれよりもっと完全に近い、たとえば GPU のサポートも含む機能を提供したいと考えていました。
今回の TensorFlow r0.12 のリリースに合わせて、Windows 7、10、Server 2016 向けのネイティブ TensorFlow パッケージを提供いたします。このリリースでは、CUDA 8 対応の GPU で TensorFlow トレーニングを高速化できます。
この最新リリースは、PyPI の pip パッケージ として公開されていますので、次のコマンド 1 つで TensorFlow をインストールできます。
C:\> pip install tensorflow
GPU サポートは、次のコマンドでインストールできます。
C:\> pip install tensorflow-gpu
Windows サポートの詳細を含む r0.12 の新機能の詳細については、リリースノート をご覧ください。
多くの方に TF を最高速でご利用いただけるようになりました。今後のリリース情報をいち早く受け取れるように、ぜひ Twitter で @tensorflow をフォローしてください。
謝辞
このリリースは、たくさんの方の貢献によって実現できました。とりわけ、Windows のサポートに大きく貢献してくださった Microsoft の Guenther Schmuelling 氏と Vit Stepanovs 氏に感謝いたします。
Posted by Kazunori Sato - Google Cloud Platform