watermint.org - Takayuki Okazaki's note

Dropbox API: ファイルのアップロード

今回はDropbox APIを使ってファイルをアップロードをする流れをご紹介します。ファイルアップロード処理は/files/uploadを使えば良いのですが、ファイルサイズが大きい場合には一つのリクエストで処理するのではなく分割してアップロードすることが求められます。

分割アップロードする場合には、次のように3つの手順をたどります。

  1. 分割した最初のチャンクをアップロード (戻り値としてセッションIDが得られます) - /files/upload_session/start
  2. セッションIDをもとに最後の一つ手前チャンクまでを追記アップロードします - /files/upload_session/append_v2
  3. セッションIDと最後のチャンクをアップロードします - /files/upload_session/finish

分割の閾値

分割するかどうかの閾値はAPIドキュメントに下記のように記載があります。

A single request should not upload more than 150 MB.

150MB以上であれば分割してアップロードすべし。とのことなのですが、気になるのはこの1MBが 1,000,000バイトなのか、1,048,576バイトなのか。です。 気になるので試してみたところ次の通りでした。

  • 150,000,000バイト … アップロード成功
  • 157,286,399バイト (150 * 1,048,576 - 1)… アップロード成功
  • 157,286,400バイト (150 * 1,048,576) … アップロード成功
  • 160,000,000バイト … アップロード成功

予想外のことですがとりあえず150MBを軽く超えてもエラーなど出ず、アップロードができるようです。 ただ、あまり一度にアップロードするサイズが大きくなりすぎると、途中で通信エラーが出た場合に再送するならばロスが大きくなるのでそこそこに分割した方が良いでしょう。

Goでの実装例

前回と同様にdropbox-sdk-go-unofficialを使った実装例です。まずはソースをご覧ください。

uploadSrc := "data.zip"
// 分割してアップロードするかどうかの閾値
var chunkedUploadThreshold, chunkSize int64
chunkedUploadThreshold = 150 * 1048576
chunkSize = chunkedUploadThreshold
config := dropbox.Config{
  Token: "トークン文字列",
}
client := files.New(config)
// ローカルファイルの情報取得
info, err := os.Lstat(uploadSrc)
if err != nil {
  return err
}
f, err := os.Open(uploadSrc)
if err != nil {
  return err
}
defer f.Close()
ci := files.NewCommitInfo("/アップロード先/data.zip")
// ファイルの日付、UTCで秒未満の単位は丸める
ci.ClientModified = info.ModTime().UTC().Round(time.Second)
if info.Size() < chunkedUploadThreshold {
  _, err = client.Upload(ci, f)
  return err
} else {
  // セッションを開始、最初のチャンクサイズ分だけアップロード
  r := io.LimitReader(f, chunkSize)
  s, err := client.UploadSessionStart(files.NewUploadSessionStartArg(), r)
  if err != nil {
    return err
  }
  // 最後から一つ手前のチャンクまで分割アップロード
  var uploaded int64 // アップロード済みサイズ
  uploaded = chunkSize
  for (info.Size() - uploaded) > chunkSize {
    cursor := files.NewUploadSessionCursor(s.SessionId, uint64(uploaded))
    arg := files.NewUploadSessionAppendArg(cursor)
    r = io.LimitReader(f, chunkSize)
    err = client.UploadSessionAppendV2(arg, r)
    if err != nil {
      return err
    }
    uploaded += chunkSize
  }
  // 最後のチャンクをアップロード
  cursor := files.NewUploadSessionCursor(s.SessionId, uint64(uploaded))
  arg := files.NewUploadSessionFinishArg(cursor, ci)
  _, err = client.UploadSessionFinish(arg, f)
  return err
}

アップロード先

CommitInfo構造体にパスやファイルの日付などを設定します。アップロード先パスですが、アップロード先ディレクトリ名だけでなく、アップロード先ファイル名も含めたパスを指定します。

autorenameというパラメータがありますが、これをtrueにすると同じパスにすでにファイルがある場合は新しくアップロードするファイルがdata (1).zipのように重複しないファイル名でアップロードされます。

ファイル更新日付

ファイル更新日付を指定する場合にはclient_modifiedパラメータを指定します。指定しない場合にはDropboxへファイルが保存された際のサーバ日時になります。指定はISO 8601フォーマットで、UTCとします。

Goの例ではUTCに変換した上で、下記のように秒以下を丸めています。

ci.ClientModified = info.ModTime().UTC().Round(time.Second)

分割アップロード

Goの場合には分割アップロードに便利なio.LimitReaderというクラスがありますのでこれを利用するといいでしょう。分割したいチャンクサイズを指定するとそこでEOFになってくれます。

/files/upload_session/startで最初のチャンクをアップロードしたら、セッションIDが得られます。

これを使って、以降は/files/upload_session/append_v2を呼び出してチャンクをアップロードしていきます。なお、ファイルは0バイト目から連続している必要があり、cursorで飛び飛びのオフセットを指定した場合にはincorrect_offsetエラーとなります。

このoffsetパラメータの目的はAPIドキュメントにあるとおり、通信エラーなどで重複送信や部分的なロスが発生した場合にデータの整合性を検出するためです。

We use this to make sure upload data isn’t lost or duplicated in the event of a network error.

海外旅行とSIMカード

海外旅行または海外出張に行くとき、忘れてはならないのはパスポートです。次に大事なのは財布だと思いますが、いまや財布と同じぐらいモバイルインターネット接続の重要度が上がってきていると思います。地図を見るにしても、タクシーに乗るにしてもスマホとアプリに頼り切る生活になっているからでしょう。

今年は出張と旅行で何度か海外に行きましたが、その際のSIMカード利用をレビューしたいと思います。数年前まではWifiルータを日本でレンタルしていくこともありましたが、最近はほとんどSIMフリー携帯/iPad+現地SIMです。 (注: 為替レートは執筆時点でのもの)

台湾

ここ数年、ゴールデンウィーク頃に台湾へ遊びに行っています。台湾はSIMが手に入れやすく、たとえば台北の松山空港でも荷物を受け取り、両替を済ませたらすぐ近くにSIMカードを売っているカウンターがあります。特にこだわりはありませんが、だいたいいつも中華電信の1週間500台湾ドル(約1900円)でインターネット使い放題のSIMを買っています。カウンターでパスポートとSIMフリー携帯を渡すとSIMを差し替えて設定してくれます。

速度も満足でき、特に電波状況がわるくて不便な目にあったということもありませんでした。

フィンランド、アイルランド、イギリス

今年はヨーロッパ方面に行く際にはMTX ConnectのSIMを使っています。日本からもオンラインでSIMを購入することができます。海外からの発送になるので出発の3〜4週間前ぐらいに買っておくと安心でしょう。

SIMカードは7ユーロ(約940円)程度で購入できます。7ユーロで買いますが、これはあとからパケット代金に充てることができるので実質的には無料と考えてもいいかもしれません。MTX Connectの場合はその後、クレジットカードないしPaypalなどでチャージ(top up)して従量課金または1GB〜3.5GBの定額プランなどを購入して利用します。

今年使ったのは1GB・15日(約20ユーロ)と2GB・30日(約40ユーロ)というプランです。フィンランド→アイルランド→イギリスなど複数国を回りましたがSIMを変える必要も無く、キャリアも自動検出されるもので良いのでかなり楽です。

接続は4Gではなく3Gになることが多いので、日本で利用するのと比べるとやや見劣りしますが地図を見たり、SNSを見るぐらいならさほど気にならないと思います。

アメリカとカナダ

北米には今年、アメリカ(ニューヨークとインディアナ)とカナダ(トロント)に行きました。同行者分ふくめ2台分準備しました。

T-MobileのSIM

ひとつはT-Mobileの通話とSMS、データ通信高速無制限使い放題というSIMを購入していきました。30日間有効で、カナダ・メキシコは最長15日間利用できるとのことです。価格は6,900円とヨーロッパで使っているSIMと比べるとかなり高い印象です。それでもWifiルータをレンタルするよりは安くすみます。

iPhone SEで利用していましたが、速度的にも満足のいくものでした。トロントに移動した際、うまくインターネット接続できなかったのですが日本で使っていたIIJmioの構成プロファイルを消し忘れていたというのに気づいて一件落着しました。

MTX Connect

アメリカの後、すぐにヨーロッパ出張の予定があったのでMTX Connectを使うことにしました。ニューヨークでは実際にMTX Connectを使って特に不自由なく空港でUberを呼んだりするところから、街歩きの際にも利用しました。

MTX ConnectのSIMでカバレッジをみるとアメリカやカナダもカバーしているように見えるので、これだけで済ませるつもりでしたが少し誤算がありました。

MTX Connectのカバレッジ

よくみると注があり、ケベック州のみとのこと。。結局トロントでは利用できず、後述のGigSkyを使うことにしました。

Apple SIMでGigSky

現地でSIMを調達するのも意外とタイムロスになるのでiPad Pro内蔵のApple SIMを使うことにしました。Apple SIMで契約するデータプランは、何かの記事で読んだからか、ものすごく高いという印象があったのですが、北米プラン2GB・30日で4,200円と意外にリーズナブルでした。

通信速度、接続状態も良く都市部だけでなく郊外でもストレス無く利用できました。

GigSkyのページをみると北米2GB・15日で30ドル(約3,400円)とApple SIMプランよりも若干リーズナブル。日数は減りますが旅程によってはGigSkyのSIMをあらかじめ日本で買っておいてもいいかもしれません。

総評

複数国を移動するような旅行の場合、カバレッジの広いGigSkyが圧倒的に便利ですが、旅程によってはMTX Connectも便利です。EU圏内では今年データローミング料金が撤廃されたというような動きもあったので、今後ますます便利なSIMが出てくるかと思います。

対応LTEバンドなど携帯電話側の対応も考えなければいけないですが、iPhoneなどカバレッジが広いSIMフリー端末があると、その点でもあまり悩まずすみます。

Dropbox API: 認証・認可について

今回はDropbox APIの認証・認可についてかいつまんでご紹介します。Dropbox APIの認証・認可はOAuth2を利用しています。公式SDKの実装サンプルなどを参考にJavaとGoでの実装例をもとに紹介していきます。

Dropbox APIの概要でもご紹介したとおり、実装前にはアプリケーションの登録が登録が必要です。登録がすんだらApp keyとApp Secretが得られますのでこれらを使いましょう。

Java

SDKにauthorizeというサンプルがありますのでこれを参考にすると良いでしょう。 一般的なOAuthの流れと比べて変わったところは特にありません。Dropbox SDK JavaのJavadocに簡単な流れがのっているのでこちらを引用してご紹介します。

// No Redirect Example
DbxRequestConfig requestConfig = new DbxRequestConfig("text-edit/0.1");
DbxAppInfo appInfo = DbxAppInfo.Reader.readFromFile("api.app");
DbxWebAuth auth = new DbxWebAuth(requestConfig, appInfo);
DbxWebAuth.Request authRequest = DbxWebAuth.newRequestBuilder()
    .withNoRedirect()
    .build();
String authorizeUrl = auth.authorize(authRequest);
System.out.println("1. Go to " + authorizeUrl);
System.out.println("2. Click \"Allow\" (you might have to log in first).");
System.out.println("3. Copy the authorization code.");
System.out.print("Enter the authorization code here: ");
String code = System.console().readLine();
if (code != null) {
    code = code.trim();
    DbxAuthFinish authFinish = webAuth.finishFromCode(code);
    DbxClientV2 client = new DbxClientV2(requestConfig, authFinish.getAccessToken());
    // APIを使った処理
}

この例ではApp Key・App Secretをファイルから読み込んでいます。api.appという名前で次のようなJSON形式ファイルを準備しておいてください。

{
  "key"    : "App keyと置き換え",
  "secret" : "App secretと置き換え"
}

大まかな流れとしては次の通りです。

  1. 設定情報などを準備 (DbxRequestConfig, DbxAppInfo)
  2. リクエストを準備
  3. 認証URLを生成し、ユーザーに認可をもとめる
  4. コードを受け取りトークンを生成
  5. DbxClientV2インスタンスを作成して各種APIコール

設定できるオプションとしては、DbxRequestConfigにはエラー時の再試行回数などがあります。

Go

個人的にGoで実装する際には非公式SDKのdropbox-sdk-go-unofficialを使っています。処理の流れは基本的にJavaでの実装と同じです。OAuth認証・認可処理自体はSDKとは関係なくgolang.org/x/oauth2を利用しています。

authCfg := &oauth2.Config{
	ClientID:     "App keyと置き換え",
	ClientSecret: "App Secretと置き換え",
	Scopes:       []string{},
	Endpoint: oauth2.Endpoint{
		AuthURL:  "https://www.dropbox.com/oauth2/authorize",
		TokenURL: "https://api.dropboxapi.com/oauth2/token",
	},
}
authorizeUrl := authCfg.AuthCodeURL(
	"csrf-stateの文字列",
	oauth2.SetAuthURLParam("response_type", "code"),
)
fmt.Println("1. Go to " + authorizeUrl);
fmt.Println("2. Click \"Allow\" (you might have to log in first).");
fmt.Println("3. Copy the authorization code.");
fmt.Print("Enter the authorization code here: ");
var code string
fmt.Scan(&code)
token, err := authCfg.Exchange(context.Background(), code)
if err == nil {
	dropboxCfg := dropbox.Config{
		Token: token.AccessToken,
	}
	client := files.New(dropboxCfg)
	// ...
}

認証時のロール

ちょっと変わったところとしてはリクエストを準備する際のロールについて紹介しておこうと思います。OAuthではscopesというパラメータを使ってアプリケーションに対し、認可する範囲を設定します。DropboxではDropbox APIの概要にてご紹介したとおり、アプリケーション登録時にアクセス権限を設定します。

このため、scopesパラメータを使わない場合も多いのですが一つだけ指定できるものがあります。

Dropboxでは個人向けDropbox (Dropbox Basic、Plus、Professional)アカウントと、Dropbox Businessアカウントをリンクすることでパソコン、スマートフォン、タブレットなどのアプリケーションで同時に二つのアカウントを利用できる機能があります。

このときに、アプリケーションの接続を会社のアカウントのみに限定したいとか、逆に個人向けのみに限定したいといった指定にscopesパラメータを利用します。

Javaの場合はDbxWebAuth.Request.BuilderwithRequireRole()メソッドへROLE_PERSONALまたはROLE_WORKを指定します。

トークンの無効化

一定の処理が終わって、ログアウトに相当するトークンの無効化処理をしたい場合の処理です。これは、User EndpointsとBusiness Endpointsで若干変わります。

User Endpointsの場合

User Endpointsの場合はauth/token/revokeにAccess Tokenを渡すだけです。

Business Endpointsの場合

Business Endpointsではauth/token/revokeに直接相当するAPIがありません。このためチーム管理者が管理者コンソールよりチーム向けアプリケーションを無効化する必要があります

Dropbox APIの概要

DropboxのAPIについて説明している日本語情報が少ないようなので、個人的にメンテナンスしているtoolboxというプロジェクトの経験をもとに説明していこうと思います。APIを網羅的に解説するよりは、勘所をつかむための解説にしようと思いますので詳細は英語版とはなりますが公式ドキュメントをご参照ください。またOAuthやJSON、curlコマンドなどWeb APIにて一般的な概念やツールなどについては説明を省略します。

なお、本記事は個人の見解であり、執筆時点での情報を元としています。記事の正確性などについて保証するものではない点ご容赦ください。最新情報については公式ドキュメントをご参照ください。

前置きが長くなりましたが今回は概要です。


Dropbox APIの種類

Dropboxより提供されているAPIには大きく分けて下記二種類があります。

  • Dropbox API または User Endpoints … ユーザー毎のファイル管理など
  • Dropbox Business API または Business Endpoints … Dropbox Businessチームの管理

なおドキュメントによって文脈によって単に「Dropbox API」とだけいったときに両方を含む場合もあれば、ユーザー毎のファイル管理だけを指す場合もあります。一部厳密性に欠ける部分もありますが、本記事では両方を指す場合にDropbox API、個別に種類を言い分けるためにはUser EndpointsとBusiness Endpointsという呼称を使うことにします。

API Explorer

ドキュメントを読み込むなどある程度準備してから取りかかるのもいいですが、まずは簡単に試してみるのが手っ取り早いでしょう。API Explorerというツールが公開されていますのでこちらを利用します。

API Explorer

左側にAPI一覧があり、APIを選択すると指定できるパラメータなどがフォームとして表示されます。わかりづらいですが、右上に「Switch to Business Endpoints」というリンクがありますのでBusiness Endpointsについても試すことができます。

ためしにフォルダ内のファイル一覧を表示してみましょう。APIはカテゴリ毎にパスが区切られていて、ファイル操作であれば https://api.dropboxapi.com/2/files/ 以下のエンドポイントが該当します。 この中の、list_folderというAPIがファイル一覧取得のためのAPIです。API Explorerではこのカテゴリ毎に整理されていますのでfiles以下からlist_folderを探してみてください。

list_folder

まずは認証から。Get Tokenというボタンがあるのでこれを押してトークンを取得します。Dropboxへのログインや認可の確認などが求められますがそれらを確認のうえトークン文字列を取得してください。

早速実行してみましょう。Submit Callボタンを押します。パラメータpathに何も入れなければDropboxフォルダのルートからの一覧になります。逆に、ルートフォルダを一覧するために / は使えません。Show Codeボタンを押せばcurlでの実行例も表示されます。戻り値についてはlist_folder APIドキュメントに記載がありますが、正常ケース・異常ケースともに結果がJSON形式で返されます。

アプリケーションの登録

Dropbox APIを使って開発を進めるにはまずDropboxへアプリケーションの登録が必要となります。登録のためにはDropboxアカウントが必要となります。Dropbox開発者ページのMy appsから登録します。

Create App

APIの種別、アクセス範囲などを選択した上でアプリケーション名を登録します。アプリケーション名はDropboxサービス全体で一意になる必要があり重複した名称をつけることはできません。開発したいアプリケーションで複数のアクセス範囲を使いたい場合にはそれらアクセス範囲ごとにアプリケーションの登録が必要となるので、命名規則なども準備したうえで登録するとスムーズです。

アクセス範囲についての詳細は次の通りです。

User Endpoints

App Folder

アクセス範囲をアプリケーションのみが使用するフォルダに限定します。Dropboxフォルダ以下に「アプリ」またはユーザーの利用設定言語が英語などであれば「Apps」などのフォルダが作成され、このアプリフォルダ以下に/アプリ/アプリ名のようなフォルダが作成されます。App Folderを選択するとこのフォルダ以下しか操作することができません。

Full Dropbox

該当アカウントのすべてのファイルを操作できます。

Business Endpoints

Dropbox Business向けのAPIはチーム内のアカウント管理や監査ログを取得するなど目的に応じて範囲が分けられています。

Team information

チームに関する情報と利用統計情報などにアクセスできます。情報を取得するだけ管理など変更処理はできません。

Team auditing

Team informationの範囲に加え、チーム監査のために利用します。アクティビティ監査ログのような情報にアクセスすることができます。

Team member file access

Team informationならびにTeam auditingに加え、任意のチーム内アカウントへのファイル操作などアクションを実行することができます。たとえば、チーム内のアカウントすべての共有フォルダの共有先一覧を取得したいといった場合にはこのアクセス範囲を利用します。

Team member management

Team informationに加え、チーム管理者としての操作をするためのアクセス範囲です。チームメンバーを招待したり、アカウントの情報編集、削除などといった管理操作が可能です。たとえば、社内ワークフローと組み合わせて社内ワークフローで承認された人だけにDropbox Businessアカウントを招待するという用途にはこのアクセス範囲を利用します。

アプリケーションの設定

アプリケーションを登録すると設定画面が表示されます。OAuth2のGenerated access tokenという欄にGenerateというボタンがあります。これを押すと、既存のログイン済みアカウントで認可済みのトークンが生成されます。テストなどで利用すると良いでしょう。ちゃんとしたOAuth2シーケンスでトークンを取得する場合に必要となるApp key/secretについてもこの画面から参照することができます。

App settings

なおBusiness Endpoints向けのアプリケーションではこの操作を行うのは、そのチームのチーム管理者である必要があります。

Dropbox SDK

API Explorerで勘所がつかめ、アプリケーション設定が終わったらプログラミング開始です。REST APIなのでパラメータや戻り値を加工すれば何とでも呼び出しはできますが、やはりあらかじめ構造体/クラスなどが定義されたSDKを使った方が手軽です。

Choose your platformドキュメントを参照すると代表的なプログラミング言語用の公式SDKが一覧されています。執筆時点での対応言語は下記の通り。

GoやRuby向けなどこのなかにない場合にはコミュニティにてメンテナンスされているSDKも利用できます。

さらにコミュニティSDKもない場合、たとえばPowerShellで簡単な管理ツールを作りたいというようにこの中で対応言語がない場合にはHTTPのAPIドキュメントを参照しながら作成していくことになります。

SDKの選び方

APIはバージョン毎に互換性が保たれるよう提供されていますが、比較的頻繁に新しいAPIやパラメータ、戻り値が追加されるのでこれらに追従することを考えると公式SDKを採用した方がやや有利です。

Dropbox公式SDKはstoneというツールを使って自動生成されるようになっていますから、こういった変化への追従に強い点が特徴です。

一方で、お作法が統一されていて言語毎に特化した書き方ではないのでややなじみにくく感じる部分もあるかもしれません。

ファイルをアップロードするだけ、とかダウンロードするだけといった用途が一定または特化している場合にはコミュニティSDKのほうがなじみやすいかもしれません。

Dropbox APIの使い処

Dropbox上でできる主要操作はだいたいDropbox APIを利用すれば実現できます。また逆に、APIでなければ実現できないものもあります。少し実例を元に紹介していきましょう。

共有リンクのパスワード/有効期限を一括設定する

Dropbox ProfessionalやDropbox Business契約があるばあいには、共有リンクへパスワードや有効期限を設定することができます。ただ、共有リンク一つ一つに画面から設定するのは面倒なので一括設定したいと考えることもあります。こういったときにDropbox APIを利用すると実現できます。

たとえば拙作toolboxではこの操作を実装しました。

Business Endpointsのアクセス権「Team member file access」を使い、すべてのユーザーについて共有リンク一覧を取得します。

すべてのユーザーに対して処理を行うにはまずteams/members/listでアカウント一覧を取得します。各ユーザーについてsharing/list_shared_links APIでリンクを取得するのですがこのときに、Member file accessにあるとおり、HTTPヘッダにDropbox-API-Select-User: チームメンバーIDを追加すると、その該当アカウントとして処理が行われます。

共有リンクが取得できたら、同様にDropbox-API-Select-User: チームメンバーIDを使って、各ユーザーそれぞれの共有リンクについてsharing/modify_shared_link_settingsを使って有効期限を今日から7日後などに上書きします。

共有フォルダへの参加者一覧

監査などの目的でDropbox Businessチーム内の各利用者が参加している共有フォルダの参加者一覧を取得したい場合があるとします。 これも以前Pythonで実装したことがあります。

Business Endpointsのアクセス権「Team member file access」を使い、すべてのユーザーについて処理を行います。 共有フォルダの場合にはアクセス権限がメンバー単位だけでなくグループ単位の場合もあるのでグループ情報を取得するためにteams/groups/listなども使っています。

大量ファイルのコピー/移動/削除など

Web画面から操作する際にファイルが一定数を超えていると処理ができない旨が表示されます。Dropboxアプリケーション実行すれば大量ファイルでも処理はできるのですが、パソコン上に同期していない場合などでは処理ができないのと、パソコンにやや負荷もかかります。

このためそれぞれのファイルを逐次コピーないし、移動するようにUser EndpointsのAPIを使えば着実に処理を進めることができます。コピーであればfiles/copy_v2、移動であればfiles/move_v2といったAPIを使います。

なおAPIを使った場合でもAPIドキュメントにあるとおり10,000ファイル以上を同時に処理することはできません。

too_many_files The operation would involve more than 10,000 files and folders.

小分けにして処理する必要があります。

ログイン済みデバイス一覧や強制ログアウト

Business Endpointsのteam/devices/list_member_devices APIを使うとDropbox Businessチーム内のデスクトップ、モバイル、Webとそれぞれのセッション一覧を取得することができます。セッション情報には最終接続IPアドレスやUser Agentなども含まれるので、一定のルールを元に強制ログアウトを実施すると行った使い方もできます。たとえば、社内IP以外が検出されたら強制ログアウトなど。

強制ログアウトのためにはteam/devices/revoke_device_session APIを使います。

まとめ

Dropbox APIを使うと社内ワークフローと連携して自動処理を行ったり、運用ポリシーなどに合わせて管理する、あるいはDevOpsのように開発ワークフローと組み合わせて、Dropboxの特定フォルダにファイルがアップロードされたらビルド開始。といったことも実現可能です。

お作法はあるていどあるものの、一度覚えてしまえばやりたいことが簡潔に書けるようなAPIがそろっているかなと思います。

旅行の小物整理

海外旅行や海外出張に行く際、小物整理は意外とやっかいでした。今回はそういった海外旅行の際の小物整理で工夫していることをまとめます。旅行時の小物と行っても様々です。今回は次のように主に小さく薄っぺらいものをまとめて整理する方法について。

  • パスポートや航空券など大事な書類
  • 入国時の申請書類など
  • 予備のクレジットカードやキャッシュカード
  • 現地で受け取ったレシート (家計簿や経費精算などのために整理したい)
  • 現地でもらったレストランなどのショップカード、観光地のパンフレット
  • 現地で利用するSIMカードまたは、交換した日本のSIMカード

これまで数年はBRUNOのトラベルオーガナイザーを使っていました。パスポートや航空券、カード類が整理できるようになっていてとても便利です。それ以前は手帳に挟んだり、鞄のポケットにいれたり統一感無く管理していたので、入国管理や税関などで書類を提出する際もあたふたしていました。このトラベルオーガナイザーを使って整理したことで入出国時のストレスが少し解消されました。

トラベルオーガナイザー

革製でかっこよく、丈夫なので航空券が折れ曲がったりもせず気に入って使っていました。ただ、ここ数回の旅行では今までよりも小さな鞄を持って旅行していたのでこのわずかな厚みも気になるようになってしまいました。また、旅行先で受け取ったレシートなどもトラベルオーガナイザーに入れてしまうとかなり分厚くなってしまいます。 鞄には出張時であればノートパソコン(15インチのMacBook Pro)、iPad、携帯電話、それぞれの充電器(乗り継ぎ待ちの際利用)を入れていてこれだけでほぼ鞄がいっぱいに。この結果、トラベルオーガナイザーも出し入れがやや窮屈に。

また旅行券も以前はほとんどの場合、磁気ストライプのあるハガキぐらいのやや厚手な紙が使われていました。これが最近、バーコードを読み取るだけにかわり薄っぺらい感熱紙のような紙が使われる場合も増えてきました。あまり薄っぺらいと、トラベルオーガナイザーの収納ポケットの形によっては整理する際にやや手間取ります。

そこで直近の海外出張ではB6サイズのメッシュケースを使い始めました。よく銀行の通帳やキャッシュカードをひとまとめに整理するために使ったりするケースです。

メッシュケース

なかなか丈夫で信頼性のあるケースで、何より価格も手ごろです。B6サイズのメッシュケースは210mm x 170mmとA5サイズがきっちり入るサイズです。このシリーズではマチの部分も考慮して一回り小さめの呼称をしているのだと思います。 あまり気にしていませんでしたが、最近乗ったJALやBritish Airwaysの航空券のサイズは20cmちょっと x 8cmちょっとでぴったり入りました。

このセキセイのメッシュケースはチャック部分が色違いの赤と青のものがあります。この2種類を目的別に使い分けることにしました。 一つ目はチャックが赤色のもので重要なものを入れます。これから利用する航空券やパスポート、SIMカードなど。 二つ目はチャックが青色のものであまり重要ではないものを入れます。レシートや地図など。

このように整理すれば入出国時にもバタバタしませんし、もともと薄手なのでかさばりません。重要ではない青色チャックのメッシュケースがもし手荷物に入らなければ、預け荷物に入れることもできます。

うまくいったので、2種類だけではなく、目的別にもう少し種類を増やしてみようかとも考えましたがあまり多すぎるとまたそれはそれでゴチャゴチャしてしまうのでせいぜい2種類ぐらいが良さそうです。