re:Invent2018 AWSの新サービス群に対する1行所感 その１

　2018年11月25日〜30日までアメリカのラスベガスでAWSの最大のイベントであるre:Inventが開催中です。発表が多すぎて訳が解らなくなってきたので、自分なりの解釈で1行所感をつけていきます。まずは、27日午前までです。
※一部、re:Invent開催前に発表されたものも含まれています。また、1行の定義はなんだという問には答えません。

その２も書きました。

AWS RoboMaker

---

ロボット向けのROS（Robotic Operating System）をベースにAWSの各種機能と強力に統合したサービス。でも、ロボットと言ってもドラえもんじゃないよ。産業用ロボを想像してください。

AWS RoboMaker-インテリジェントなロボットアプリケーションの開発、テスト、デプロイと管理 | Amazon Web Services ブログ

AWS Transfer for SFTP SFTPでS3にデータ転送

---

　SIerでAWS案件をやっていたら、一度は尋ねられた事があるだろう。「S3でFTPできないの？」と。このサービスがリリースされた事による反応で、その人の素性が解ることだろう

re:Invent 2018 Midnight Madness/ AWS Transfer for SFTP | Amazon Web Services ブログ

AWS DataSync オンプレミスとAWS間の新しいデータ転送サービス

---

　Storage Gatewayというサービスがあってのう。今は昔の話じゃ（になるのかな）。あと、オンプレ・AWS間の圧縮・高速化のソリューション出してるサードパーティが沢山あったよなぁ。合掌

re:Invent 2018 Midnight Madness/ AWS DataSync | Amazon Web Services ブログ

Firecracker 新しいマイクロVM

---

LambdaやFargateで使っているコンテナ基盤をサービスとして利用できるようにするよ。OSSとしても公開するよ

Firecracker – サーバーレスコンピューティングのための軽量な仮想化機能 | Amazon Web Services ブログ

Amazon EC2 A1 インスタンス

---

ArmベースのCPUを使ったインスタンス。いつまで経ってもArmの時代が来ないから、Amazonが自分でCPU作ったわ

Introducing Amazon EC2 A1 Instances Powered By New Arm-based AWS Graviton Processors

AWS Global Accelarator グローバルで利用できるロードバランサ

---

もうロードバランサーは、GCPの方が凄いと言わせないぞ。（本当に凄いか、まだ解らんけど）
Introducing AWS Global Accelerator

AWS Transit Gateway VPC・オンプレ・ダイレクトコネクトの接続ハブ

---

AWSは、個人でISPでも開業させたいのでしょうか？
Introducing AWS Transit Gateway

AWS Ground Station　人工衛星を時間貸しできるサービス。正確には、地上の受信の基地局を貸すサービス

---

ごめん。何言ってるのか、本当に解らない
re:Invent2018 AWS Ground Station が発表になりました。 | Amazon Web Services ブログ

S3 Batch Operations　S3内の複数のオブジェクトに一括処理が可能に

---

数億のオブジェクトにAPIで順次Get⇒処理してると時間と金が掛かるよね。それ一括で出来るよ、S3 Batch Operationsならね

Amazon S3 Introduces S3 Batch Operations (Preview) for Object Management

AWS Amplify Console Amplifyを使って簡単にフロントエンド／バックエンドサービスを作る

---

ポチッとなで、フロントエンドとバックエンドのサービス、更にGitのリポジトリまで作ってくれる。ちまちまとしたAPI Gateway+Lambdaの設定からも開放される

Introducing the AWS Amplify Console

AWS Resource Access Manager – クロスアカウントでのリソース共有

---

　アカウント間のリソース共有のコントロール。複数アカウント利用が当たり前になった証左でしょう。

新しい AWS Resource Access Manager – クロスアカウントでのリソース共有 | Amazon Web Services ブログ

Route 53 Resolver オンプレミス-VPCの相互名前解決

---

　オンプレとクラウドを両方利用するハイブリッド。最大の悩みどころが両者の名前解決。その悩みを解決しやすくしたのがRoute 53 Resolver

New – Amazon Route 53 Resolver for Hybrid Clouds | AWS News Blog

Amazon Aurora Serverless にアクセスが可能な Data API

---

Aurora Serverlessがサーバレス（Lambda）からアクセスしやすいようにHTTPのエンドポイント作ったよ

Access your Amazon Aurora Serverless Database with the New Data API (Beta)

AutoScalingのPredictive (予測的）スケーリング

　機械学習で作成したモデルをもととする予測ベースの自動スケーリング。自動拡張の設定もAWSにお任せあれ

新機能 – Machine Learning を中核とする EC2 の予測スケーリング | Amazon Web Services ブログ

コンピューティング能力と GPU を増強した Snowball Edge

---

　内容は、そのまんま。52vCPUと208GBのメモリにGPU。そのパワーを何に使う？

近日登場 – コンピューティング能力と GPU を増強した Snowball Edge | Amazon Web Services ブログ

CloudFormationで、定義と実態の差異検知

---

　CloudFormationの最大の敵である手作業による直接変更を検知してお仕置きお知らせしちゃうぞ

新 – CloudFormation ドリフト検出 | Amazon Web Services ブログ

AWS System Manager Distributor

---

Systems Managerが更に発展統合されたサービス。出世魚かよ　EC2 Manager ⇒ Systems Manager ⇒ System Manager Distributor

Introducing AWS Systems Manager Distributor

Amazon S3 Block Public Access

---

うっかりさんの為に、S3のパブリック公開を禁止する機能。アカウントレベルで設定できるので情報システム部門、大歓喜

Amazon S3 Block Public Access – アカウントとバケットのさらなる保護 | Amazon Web Services ブログ

100Gbpsのネットワーク帯域に対応するC5nインスタンス

---

　ISUCONに対抗して、100Gbps出すためのOSチューニングコンテストをAWSが作るとみた。普通のOSイメージで100Gbps使いきれるのかな？

新機能 – 100Gbpsのネットワーク帯域に対応するC5nインスタンス | Amazon Web Services ブログ

所感

　本編のキーノート前に、怒涛のリリース。明日どうなるんだろう？

その２も書きました。

参照

re:Invent 2018に向けて 2018年11月後半アップデートのまとめ 第一弾 | Amazon Web Services ブログ
re:Invent 2018に向けて 2018年11月後半アップデートのまとめ 第二弾 | Amazon Web Services ブログ
re:Invent 2018に向けて 2018年11月後半アップデートのまとめ 第三弾 | Amazon Web Services ブログ
re:Invent 2018 11月26日 アップデートのまとめ | Amazon Web Services ブログ

「Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド」を読みました

　著者の西谷さんにAmazon Web Servicesを使ったサーバーレスアプリケーション開発ガイドを頂いたので読みました。予想以上に丁寧に書いていて、これから本格的にサーバレスアプリの開発をしようとしようという方には、非常にお勧めです。

サーバーレスアプリを取り巻く現状

---

　最近ではサーバレスという概念自体はだいぶ広まっているのですが、すぐに作れるという部分のみにフォーカスしていることが多いです。解説されている内容も、設計手法というよりサービスの紹介と使いかた、或いはコードの書き方というのが多いです。結果として、どうなっているかというと取り敢えず動くけど、何か問題が起きた時に原因が解らない、対処の方法が解らないということが多いです。また、作った人しか全容を把握していなくて、担当者の異動や転職でニッチもサッチもいかなくなる事態というのを何度か見てきました。

サーバーレスアプリをチームで開発するためには

---

　じゃぁ、どうすれば良いのか。個人的な見解としては、サーバーレスアプリも個人ではなくチームで開発するための体制を作るべきです。その為には何が必要かというと、標準的な考え方や開発手法です。実はこの部分について、AWSは色々なものを用意しています。例えば、アプリケーションを定義するモデルであるAWS Serverless Application Model (AWS SAM)であったり、フレームワークであるServerLesss Expressがあります。また継続的なビルド・デプロイを可能にするCodePiplineやCodeCommit,CodeBuild,CodeDeployなどもあります。ブラックボックスになりがちな実行状況については、CloudWatchやX-Rayで追跡可能です。
　これらをどうやって使っていけば良いのか、包括的に解説しているのが本書となります。

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイドの構成

---

　7章構成となっています。

1章　サーバーレスアプリケーションの概要
2章　Amazon Web Services(AWS)利用の準備
3章　インフラを自動化しよう
4章　Twitterのリアルタイム分析をしよう
5章　写真投稿サイトをシングルページアプリケーションで作ろう
6章　サーバーレスアプリケーションのライフサイクル管理
7章　サーバーレスアプリケーションのトラブルシューティング

　1,2章が概要説明と準備、3〜5章が実践編、6章が運用を見据えてどのように管理をしないといけないのか、7章が障害発生時にどう対処するのかといった内容です。個人的には6章の部分で、SAMや複数環境の利用、CI/CDについてしっかりと解説しているところがポイントが高いです。作ることを優先して、この辺りをおざなりにすることが多いので、少なくとも一度は読んでどうすべきなのかを把握しておくとよいと思います。

本書の特徴

---

章立ての他に、本書にはもう一つ特徴があります。画面の操作は最小限に、出来るだけコマンドラインで実行している点です。画面が少ない理由としては、AWSのUIは頻繁に変わるのでその対策だと思います。また、それを除いたとしても、実際の開発の現場ではコード固めて画面からアップしてという形ではなく、コマンドからデプロイするという方法に落ち着くと思います。そのあたりを考慮すると、かなり実践的な使いかたに即してよいのではと思います。

感想

---

　おっさん視点なので、どうしてもサーバレスアプリを継続的に開発できるチームはどう作るかという視点で読んでしまいました。ここで書かれている手法は、もちろんチームではなく個人でも有効です。むしろ、まず個人として身につける内容です。そういった意味で、非常によい本だなと思います。
　ハンズオン形式で実際に作りながら学ぶという形式なので、ここに書かれている内容を全てやりとげれば、現状のサーバレス開発の現場であれば、非常に重宝されると思います。ぜひぜひ挑戦してみてください。
※実は私も、まだ読みながら手を動かしていないので、時間見つけてやります

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

以下、目次です

目次

---

Chapter1 サーバーレスアプリケーションの概要
1-1 サーバーレスアプリケーションとは
1-2 ユースケースとアーキテクチャパターン
1-3 サーバーレスアプリケーションのライフサイクル管理概要

Chapter2 Amazon Web Services(AWS)利用の準備
2-1 AWSアカウントの取得
2-2 AWSにおける認証と認可について
2-3 リージョンの選択
2-4 AWS Command Line Interface(AWS CLI)の準備

Chapter3 インフラを自動化しよう
3-1 Amazon CloudWatchのアラームをトリガーに自動処理をする
3-2 Webサイトの状態を定期的にチェックする

Chapter4 Twitterのリアルタイム分析をしよう
4-1 Amazon Kinesisを使ってTwitterのデータを受け取る
4-2 AWS Lambdaを使ってストリーミングデータをAmazon DynamoDBへ保存する

Chapter5 写真投稿サイトをシングルページアプリケーションで作ろう
5-1 Webサイトの概要を確認する
5-2 バックエンドのAPIを実装する
5-3 フロントエンドを実装する
5-4 Amazon Cognitoを利用した認証処理を追加する
5-5 Amazon Rekognitionを使って自動タグづけを行う

Chapter6 サーバーレスアプリケーションのライフサイクル管理
6-1 AWS Serverless Application Model(AWS SAM)詳細
6-2 複数環境の管理
6-3 デリバリプロセスの自動化(CI/CD)

Chapter7 サーバーレスアプリケーションのトラブルシューティング
7-1 メトリクスのモニタリング
7-2 AWS X-Rayを利用したトラブルシューティング

まとめ

---

クラウドエンジニア養成読本を書きました

　ご報告遅くなりましたが、技術評論社から出版中のクラウドエンジニア養成読本の執筆に参加させていただきました。この本は、AWS, Azure, GCPという3大クラウドを取り扱うという意欲的な企画で、それぞれの分野の第一人者の方々が執筆されています。その中の末席に加えて頂けたこと、大変光栄です。

マルチクラウド

---

　私は、特集1の「ゼロから学ぶクラウドの世界 〜クラウドの現在、そして未来はどうなる？」という部分を担当しました。導入的な部分で、クラウドを取り巻く現状、主要ベンダーとその位置付け、最近の潮流、さらにはエンジニアはクラウドとどう向かい合うのかということをつらつらと書いています。
　その中のひとつのキーワードとして、マルチクラウド化を挙げています。マルチクラウドというと、何を持ってと宗教論争が起きるので、ここでの言葉の定義は2つ以上のクラウドを使っていたらマルチクラウドとざっくりしたものとしています。

　マルチクラウド化の必然については、後述するコンテナ・サーバレスという2つの潮流の中で、クラウド間の可搬性がより高まることが予想されます。そうなると、企業としては、サービスごとに一番良いものを使い分けていくという方向になります。そんな未来がテーマの一つにしています。

コンテナ化とサーバレスアーキテクチャ

---

　先程のマルチクラウド化の論拠は、コンテナ化とサーバレス・アーキテクチャだと言いました。この2つは、システム・アプリケーションの可搬性を高めます。どちらも上手く作れば、動くプラットフォームはなんでもよくなります。そうなると、特定のクラウドサービスに拘る理由が少なくなってきます。実際、AWSをメインで使っているものの、コンテナ部分についてはKubernetesが便利なのでGCPを使っているという話をよく聞きました。
　コンテナ・サーバレス以外にもAI・機械学習・ビッグデータに関わるようなサービスについては、既に併用しているというケースは多いのではないでしょうか？GCP使ったことないと言いつつ、Big Queryだけ使ったことある人多いですよね。

成長戦略

---

　じゃぁ、マルチクラウドが進む中で、エンジニアはどうすれば良いのでしょうか？全てのクラウドを学んでいく？私の意見として、それは現実的ではないと思っています。個人として、複数のクラウドを習熟するのは困難ですし、たとえ組織としてもかなり大規模な組織ではないと難しいのではないかと考えています。
　では、取るべき道はどうすれば良いのでしょうか？私は、T型のアーキテクトか、特定のレイヤーに特化のどちらかだと思います。

　まずT型のアーキテクトです。下の下手な字にあるとおり、特定のクラウドに習熟した上で、他のクラウドについても、ある程度抑えるという方向です。

　これに対して、特定レイヤー特化型は、ネットワークやコンテナ、サーバレスなどレイヤーを絞って、複数のクラウドサービスに習熟するという方向です。

　私自身としては、T型です。特定レイヤーについては、もう少し余裕があれば手を伸ばしたいところです。取り組むとしたら、主戦場であるコンテナ・サーバレスではなく、今までの経験が活きる認証認可の分野かなと思っています。

まとめ

---

　他の方の執筆内容については言及できませんでしたが、かなり面白いです。同僚の石川によるサーバレスで構築するシングルページアプリケーション＆バックエンドや、ソラコム松井さんのIoT、ハンズラボさんのクラウド移行話など、読み応えたっぷりです。
　余談ですが、最近だしたAWS関係本がAmazonのクラウドランキングに３つ並んで、ちょっと嬉しいです。

クラウドエンジニア養成読本[クラウドを武器にするための知識&実例満載! ] (Software Design plusシリーズ)

AWSのアクセスキー・シークレットアクセスキーをプログラムに安全に埋め込む（埋め込まない）方法

　AWSでやらかす系の事故で、もっとも恐ろしいものの一つに、アクセスキー・シークレットアクセスキーの流出があります。これは、多くの場合プログラム中にアクセスキー・シークレットアクセスキーを埋め込んだままGitHub等の公開リポジトリに登録することで起こります。GitHubを監視しているBotがカモを待ち受けているので、キーを発見するやいなや不正利用して可能な限りのインスタンスを立ち上げます。そして、BitCoin等の採掘などに利用します。気が付かないと、一晩で100万円近くの請求という話もあったようです。

AWSのアクセスキーの流出を防ぐ方法

---

　このアクセスキーの流出は、AWSの仕組みを知っていると、ほぼ被害は防げます。という事、基本的な部分をおさらいしましょう。アクセスキーではなく、IAMロールを使うというのが基本ですが、どうしても使わざるをえない場合は、下記のルールを守ってください。

 守るべきシンプルなルールは、たったの一つです。

AWSのアクセスキーは、プログラムに直接書き込まない。環境変数から読み込む

　この環境変数というところがミソで、実はAWSのSDK,CLIは特定の環境変数名を自動で読み込むようになっています。アクセスキーは、AWS_ACCESS_KEY_IDで、シークレットアクセスキーは、AWS_SECRET_ACCESS_KEYです。

Linuxの設定例

export AWS_ACCESS_KEY_ID=your_access_key_id
export AWS_SECRET_ACCESS_KEY=your_secret_access_key

Windowsの設定例

set AWS_ACCESS_KEY_ID=your_access_key_id
set AWS_SECRET_ACCESS_KEY=your_secret_access_key

 

AWSの認証情報の検索順

---

 　この辺りの情報は、AWSの認証情報の検索順等で検索すると出てきます。例えばRubyの例だと次のように定義されています。

AWS SDK for Ruby は、次の手順で認証情報を検索します。

1. クライアントオブジェクト内で認証情報を設定する

2. Aws.config を使用して認証情報を設定する

3. 環境変数を使用して認証情報を設定する

4. 共有認証情報の設定

5. IAM を使用して認証情報を設定する

　言語によっては多少違いますが、優先順位や設定可能項目は概ね同じです。つまりプログラムで設定したものが最優先で、次に環境変数系、最後にIAMロールという順です。

AWSのアクセスキー運用のベスト・プラクティス

---

　上記の最低限のルールの他に、下記のようなアクセスキーの運用を守ってください。いわゆるベストプラクティスの一部です。

- AWSサイドで利用する場合は、IAMロールを利用し、アクセスキーを利用しない

- アクセスキーを使う場合は、該当のIAMユーザには最小権限を付与する

- 可能な限りIPアドレスで絞る

- git-secretsを利用して、誤操作時に気付けるようにする

- Assume Roleを利用して、一時的なアクセスキーを利用すると、なお良い

　ただし、初めての人にこれ全部最初にやれというのも現実的ではないので、最低限守っておくべきというのが最初に説明したプログラムに埋め込まないという対応になります。

まとめ 

---

　実務的な部分では、もっと考慮しないといけない部分は沢山あります。ただ、手始めにローカルで試す場合、最低限この方法を守っていれば危険を回避します。本当は、サーバーサイドでロール使ってが良いですが、環境面の制約があり、キーを使わざるをえない場合の話です。

　こういった話も、3/23発売の改定第２版 Amazon Web Services パターン別構築・運用ガイドにまとめています。転ばぬ先の杖として、ぜひご活用ください。

Amazon Web Services パターン別構築・運用ガイド 改訂第2版

Amazon Web Services パターン別構築・運用ガイドの改訂第2版が出ました

　2015年3月に出した「Amazon Web Services パターン別構築・運用ガイド」の改訂を行い第2版として新しい本になりました。

Amazon Web Services パターン別構築・運用ガイド

---

　パターン別構築・運用ガイドはAWSの分厚い本という愛称のもと、なかなかの人気を誇ってきました。AWSの基本的なサービスであるEC2, S3, VPCを中心にアカウントの作り方から、SDK,CLIの使い方、EBSとスナップショット、AMIの作り方などを丁寧に説明しています。また、作るだけでなく、運用監視やセキュリティについても、それぞれ章を取って取り扱っています。内容的には、AWSの認定試験であるソリューションエンジニア・アソシエイトの内容をかなりカバーしているのではないでしょうか。
　なお、本書と今年1月に出したAmazon Web Services 業務システム設計・移行ガイドは、扱ってる技術的には似ています。一方で、この本はあくまで個々のエンジニアがどうAWSを使うかがテーマであり、業務システム本は組織を主題に書かれています。その為、章立て・取り扱いサービスは似ているものの、中身は随分と違うものになっています。是非、読み比べてみて下さい

改訂の箇所

---

　改訂版を出してということなので、改めて読み直しました。出版後、丸３年を迎えようとしていたのですが、EC2,S3,VPCなど基本的な機能を取り扱っている為に、そこまで大きな変更を必要としない内容でした。そこで細かいサービスのアップデートを反映すると共に、前回では機能が無くてサードパーティのツールを使っていた部分についての修正を加えました。例えば、下記のような例です。

継続的な脆弱性診断　⇒　Amazon Inspector
定期的なジョブ実行　⇒　CloudWatch Events + Lambda
サーバレスな2Tierアーキテクチャ　⇒　API Gateway + Lambda
WAF機能　⇒　AWS WAF

　これらを見ていると、足りない機能を足していってAWSのみでサービスが完結できるようになってきているのが解るのでは無いでしょうか。あとは、アクセスキー周りの事故が多いので、プログラムに安全に埋め込む（埋め込まない）方法を指南しています。ここは是非読んで欲しいです。

電子書籍版で買われた方へ

---

　たぶん前作を電子書籍版で買われた方は、アップデートすることが出来ます。書籍を一意に示すISBNは違うものになっているので、別書籍扱いになるために単純アップデートはできません。ただサポート経由等でアップデートできると思うので、発売後にやり方確認してまた案内しようと思います。

感想

---

　前作は、5刷で電子書籍を合わせて1万部を大きく超える売れ行きでした。今作も3年間くらい売れ続けてくれればなぁと思います。そして、また３年後に、また機能の差分を振り返れればなぁと思います。

Amazon Web Services パターン別構築・運用ガイド 改訂第2版

Amazon Web Services 業務システム設計・移行ガイドの増刷決定しました

2018年1月20日発売のAmazon Web Services 業務システム設計・移行ガイド ですが、発売3週間で増刷決定しました。ありがとうございます！！

本書のターゲット

---

　本書のターゲットは、企業内でAWSを構築・運用する立場の人、或いはその導入を支援するSIerで働く人を対象に書かれています。レベル的には、初心者ならびに初心者を脱して中級者を目指す人を想定しています。まぁ下のポップの金澤さんの意気込みどおりです。私は、とにかく楽したいしか頭にありません。

売れ行きの推移

---

　ネット上でのレビューなどが、まだあまり出ていないので地味です。しかし、なかなか堅調な売れ行きで、Amazonでの売り行き推移も手堅いです。

　書店巡りしていても、結構手に取ってパラパラめくってくれている人を目にするので、関心が多い分野なのかもしれません。手に取った人は、そのまま買ってくれても良くてですよ。

増刷にあたり

---

　今回の増刷にあたっては、大きな修正はしません。誤字脱字を修正するくらいです。後は巻末のプロフィールにそれぞれどこの執筆担当だったのかを書こうかなと考えています。Kindle版で購入している方は、最新化できるので是非してみてください。

感想

---

　著者にとって、増刷ほど嬉しい言葉はありません。何故なら、何もしなくても印税が入るからです。自分達が書いたものが、世の人に必要とされていたということの証左だからです。仕事しながら執筆するのは、なかなか大変なところもありますが、もう少し頑張ります。とりあえず今は、Amazon Web Services パターン別構築・運用ガイド 改訂第2版を書いています。

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

iPad Pro + Smart Keyboard + Apple Pencilを 買いました

　執筆用のMacBook Air (Early 2014)のバッテリーがへたってきました。また、元々Retina対応ではないので、原稿の校正の時にPDFを見ようとしても拡大しないと見えないという問題がありました。年末くらいから悩んでいたのですが、iPad Pro（10.5インチ） + Smart Keyboard + Apple Pencilを買いました。

iPad Proを選んだ理由

---

　Macbookの買い替えでなく、iPad Proを選んだ理由はApple Pencilの存在です。プライベートの趣味である執筆活動の関係で、PDFになった原稿に赤入れする機会が多いです。現状、Macのプレビューの編集機能を使っているのですが、正直面倒くさいです。これ手書きでやりたいなぁということでiPad Proにしました。

　それ以上に、iPad Proでどこまでパソコンの代替になるか試してみたいという気持ちが強かったのも事実です。 

iPad Proにして良かった点

 　Smart Keyboardの使い易さは、予想以上でした。過去、iPhone, iPad用のキーボードを3〜4個くらい買いましたが、まぁソフトウェアキーボードよりましかな程度でした。しかし、iPad Pro用のSmart Keyboardは、パソコンのキーボードとほぼ遜色がないレベルです。タブやコピー＆ペーストをキーボード操作で実現できるのは、やっぱり楽です。※価格は、遜色がないレベルではなく、REALFORCE/Happy Hacking Keyboardレベルですが。。。

　Apple Pencilについても、手書き用途としては全く問題ないレベルです。私の汚い字を、ちゃんと再現してくれます。また、細かいタッチを微妙に補正する機能もあるようで、ハードとソフト面でいろいろ工夫しているのだなと垣間見れます。

　あとは、持ち運びやすさもいいですね。今回の選定基準の一つに、常にカバンに入れていても負荷が小さいというのもいれていました。今のところ、全く気にならないレベルです。

iPad Proで困っているところ

---

　逆にiPad Proで困っている点、つまりはMacbookより使い難い点をあげると沢山あります。入力一つにしても、悩むところは多いです。例えば、全角の空白をどう入れるかとか、行の先頭の英単語を勝手にに大文字にされるとか。それ以上に大きいのが、各アプリ側の対応。例えば、この記事は、はてなブログアプリで書いています。最低限の機能はあるものの、PC版の機能のフルセットではありません。結局、ブラウザの方を利用に切り替えたのですが、それでもスクロールにあわせた右の補助メニューの追付いのように、PCで出来ていることが実現できないことが多々あります。

　これは、Appleの問題というより各社の対応状況の問題です。利用者数から考えると、当面は解決の見込みはないでしょう。

これから試したいこと

---

　いろいろ不便なところがあるというのは、まぁ予想の範疇です。でも折角なので、iPad Proでしか出来ない使い方をいろいろ試してみようかなと思います。もともとMacbookも併用するというのは既定路線なので。Apple Pencilの活用以外としては、例えば音声入力ですかねぇ。

感想

---

　とりあえず半年後の自分への備忘録として書いてみました。1ヶ月、2ヶ月と使っていって、どう変わっていくか乞うご期待！！

一方で、下記については依然として自分の中でも消化できていません。

この前に書いた分の印税を充当して、iPad ProとSmart Keybord, Apple Pencilを買った。そして、執筆作業している。赤入れなどの作業が、かなり快適になった。しかし、冷静に考えると、何かがおかしい。

— Takuro SASAKI (@dkfj) 2018年1月28日

MQDX2J/A ゴールド iPad Pro 10.5インチ Wi-Fi 64GB(iOS)