RAID6 のディスク交換

家のサーバーのディスクの１つにバッドセクタが出てきました。SMARTで調べたら、もう5.7年も稼働しているディスクのようで、そろそろ交換していいころですね。よく頑張ってくれました。そのディスクは2.0TBのやつなのですが、確かあの頃はすごくディスクが安くて確か6000円とかで買えたような気がします。手元にある3.0TBのやつが確か半年前ぐらいに買ったのですが8000円ぐらいしてたように思うので、５年ほど経った割にほとんど価格が変わってないなぁと思ったりもします。

さて早速交換しましょう。バッドセクタがあるとは言え、現状動いているのでまずアレイから抜く作業をします。Disk Utility 等でどのディスクが交換対象なのかは押さえておきます。私の場合 /dev/sdd でした。シリアルナンバー等も控えておきます。（同じサイズのものが複数あるので）

まずは取り外しのコマンドから

# mdadm --manage /dev/md126 --fail /dev/sdd1

すると

# mdadm --detail /dev/md126

（略）

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       2       8       81        1      active sync   /dev/sdf1
       3       8       19        2      active sync   /dev/sdb3
       4       8       33        3      active sync   /dev/sdc1
       6       8       65        4      active sync   /dev/sde1
      10       0        0       10      removed

       5       8       49        -      faulty   /dev/sdd1

のように faulty としてマークされ、アレイから除去されます。そしたらシャットダウンして、物理的にディスクを交換します。

交換したら起動して、新しいディスクにパーティションを作成します。今回はOSが入っているディスクと同じサイズのディスクなので、OS部分のパーティションを切った関係で sdd1 だったものが sde3 になりました。その領域を追加します。

# mdadm --manage /dev/md126 --add /dev/sde3
mdadm: added /dev/sde3

大丈夫そうですね。もう一度上の detail で調べると

# mdadm --detail /dev/md126

（略）

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       2       8       81        1      active sync   /dev/sdf1
       3       8       19        2      active sync   /dev/sdb3
       4       8       33        3      active sync   /dev/sdc1
       6       8       49        4      active sync   /dev/sdd1
       7       8       67        5      spare rebuilding   /dev/sde3
 

となり、リビルドが開始します。なんて簡単なんだ・・・。とはいえ、作業は簡単ですが2TB領域のリビルドなんで時間だけは盛大にかかります。とりあえずリビルドが終わるまではあまり負荷をかけないようにします。まあ現状でもRAID5の正常状態と同じなので安心感はありますが。

Jar の META-INF/MANIFEST.MF に書いた Class-Path が効かない件

案外ググったりしてもぴったりの記事には遭遇しなかったので、ブログに書いておきます。

まずやりたかったことですが、Javaで書いたコードをjarにまとめて、それをjava -jar （やダブルクリック等）で開けるようにしようと思ったのですが、その際別のライブラリがjarで提供されているので、そのjarもclasspathに追加した状態で起動したい、ということでした。これ自体は META-INF/MANIFEST.MF に書けばなんら問題なくできます。できるはずでした。

まずそのまとめるjarのほうですが、mavenを使って書いていたので、pom.xmlにこのように書けば main メソッドの指定は簡単にできます。

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-jar-plugin</artifactId>
      <configuration>
        <archive>
          <manifest>
            <mainClass>jartest.Main</mainClass>
          </manifest>
        </archive>
      </configuration>
    </plugin>
  </plugins>
</build>

これでビルドして実行すると

$ java -jar jartest-0.0.1.jar 
Hello!

当然ですが、問題ありません。

次に外部 jar の呼び出しですが、その前にこちらの jar の main メソッドをこのように書いておきます。

public class Main {
    public static void main(String[] args) throws ClassNotFoundException {
        System.out.println("Loaded:" + Class.forName("jartest2.EndPoint").getName());
    }
}

呼び出される側は jartest2.EndPoint というクラスを持っています。この時点で

$ java -cp jartest-0.0.1.jar:jartest2-0.0.1.jar jartest.Main
Loaded:jartest2.EndPoint

となります。これを jartest2 のほうを classpath に指定しなくても java -jar jartest-0.0.1.jar で起動できるようにしたいというのが今回の目的なわけです。

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-jar-plugin</artifactId>
      <configuration>
        <archive>
          <manifest>
            <mainClass>jartest.Main</mainClass>
          </manifest>
          <manifestEntries>
            <Class-Path>jartest2-0.0.1.jar</Class-Path>
          </manifestEntries>
        </archive>
      </configuration>
    </plugin>
  </plugins>
</build>

このように pom.xml を変更すればいけるはずです。実際はこちらの jar は他にも依存してるライブラリがあって、ただそちらは maven で取得できるライブラリなので、dependencies に記述し、よくある方法にて maven-assembly-plugin のほうに上のような記述をします。さていざ実行。

$ java -jar jartest-0.0.1-jar-with-dependencies.jar 
Exception in thread "main" java.lang.ClassNotFoundException: jartest2.EndPoint
 at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:264)
 at jartest.Main.main(Main.java:5)

!?
とりあえず jartest.Main.main() までは来ているので MANIFEST.MF が全くダメなわけではないということはわかります。中身を見てみると、

$ tail -3 META-INF/MANIFEST.MF 
Main-Class: jartest.Main
Class-Path: jartest2-0.0.1.jar

と、正しく指定されているように見えます。

正直相当はまりました。しょうもないtypoしてるのかと思ってコピペでクラス名を書いてみたり、ファイル名もコピペしてみたり。はたまた開発環境に使っているMac特有の問題なのじゃないかと思ってWindows機でテストしてみたり・・・。

そしていろいろやった後も解決せず、jar を展開してぼーっと眺めていたら

$ ls META-INF/
INDEX.LIST    LICENSE.txt    MANIFEST.MF    maven/        services/

ん？MANIFEST.MF以外にもいろいろあるな？まさかな、と思いつつ　MANIFEST.MF だけにしてみたところ・・・

$ java -jar jartest-0.0.1-jar-with-dependencies.jar 
Loaded:jartest2.EndPoint

おおお！動きましたね！

結論から言うとこの INDEX.LIST が悪さをしていたようです。そもそもこれは何かというのを知らなかったですが、Jarファイルの仕様にしっかり書かれています。でも今までこんなファイルを作るなんて指定はどこにもしてなかったけど・・・？原因はこれでした。

    <dependency>
      <groupId>io.undertow</groupId>
      <artifactId>undertow-core</artifactId>
      <version>1.0.16.Final</version>
    </dependency>

私が作っていた java application は embedded web server を実装するのに undertow を使っていました。そしてそれを dependency にして jar-with-dependency で１つの jar にしていたわけですが、もともと undertow-core 用に書かれた INDEX.LIST が jar-with-dependency によって１つの jar に収められたことにより生じた問題だったようです。いやはやなんとも難しい・・・。

というわけで解決方法としては INDEX.LIST ファイルを jar に含めない、またはちゃんと INDEX.LIST ファイルを生成する、のどちらかだと思うのですが、undertow が使っている INDEX.LIST の内容は特になくても問題ない（ように思える）ので、含めない方法をとることにしました。maven-assembly-plugin の jar-with-dependency の指定のところを外部の assembly.xml に記述することとし、そこに以下のような記述を行います。

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
  <id>jar-with-dependencies</id>
  <formats>
    <format>jar</format>
  </formats>
  <includeBaseDirectory>false</includeBaseDirectory>
  <dependencySets>
    <dependencySet>
      <outputDirectory>/</outputDirectory>
      <useProjectArtifact>true</useProjectArtifact>
      <unpack>true</unpack>
      <scope>runtime</scope>
      <unpackOptions>
        <excludes>
          <exclude>META-INF/INDEX.LIST</exclude>
        </excludes>
      </unpackOptions>
    </dependencySet>
  </dependencySets>
</assembly>

これで無事 INDEX.LIST を含まずに dependency を含んだ jar が生成されました。めでたしめでたし。

艦これ＋航海日誌環境における猫事件についての調査

ブログ書くの相当久しぶりになりました。最近趣味では新しいことがあまりできてなかったので書くネタがなかったのですね。もっと時間を作らないと。

さて今回のネタはもともと技術的な話ではなかったのですが、結局は技術的な話になったのでここに書くことにしました。内容は艦隊これくしょん（艦これ）の通信についての話なので、興味のある方だけ読んでみてください。

私が艦これを始めたのは相当前になります。最初はただの興味本位で始めたのですが、基本運ゲーでも結構いろいろ考えることが必要なことがわかり、最初はアナログな試行錯誤をしていたところ@sanae_hirotakaさん作の航海日誌という大変便利なソフトに出会い、より楽しくプレイさせていただけるようになりました。作者さんがソースを公開してくださっているので、私の専門のJavaで書かれていることもあり、ほんの少しですがpull request等で開発に協力させていただいたりもしていました。

ところが事件が起きた（起き始めた）のは2015年の夏イベント（通称夏イベ）が開始されてからです。今まではほとんど猫った（エラーが起きた）ことのない平和な我がタウイタウイ泊地だったのですが、夏イベ開始のサーバーメンテナンス明けからちらほら猫るようになりました。最初はサーバーが混んでるのかなと思っていましたが、空いてそうな時間帯でもなることがあり、変だなと思い始めました。しかしネット上では特に騒がれている風もなく・・・。

すると艦これをやってる知り合いから「どうも航海日誌を使ってると猫るって話になってるぞ」との知らせが。そんな馬鹿なと思いツイッターで「航海日誌　猫」とかで調べてみると確かにそういう事象にあっている方もいるようで、ただ実行環境によるのか、サーバーによるのかは不明にせよ、全く起きない方もいるのも事実。 しかし調べていたら、こんなに便利に使わせてもらってるソフトをしかもタダで使わせてもらってるのに、「使えねー」とか「ふざけんな」とか言われてるのは納得いかないので調査してみようと思ったのがこの記事を書いている理由です。

するとその知り合いからさらに「特にテザリングでやってるとしょっちゅう猫る」との知らせが。それをヒントに、まずどういう環境で出やすいのかを考えました。家ではあまり出ない、テザリングで出やすい、と考えると、やはり遅い回線だと出やすいのではないかと考えました。そこで私はiijmioのSIMでiPhone4Sを運用しているのですが、このiijmioのSIMはアプリで通信速度を低くすることができます（正確には高速通信は月3Gまでとなっているので、高速通信をオンオフできます）。なので高速通信をオフにした、たしか200kbps程度の通信速度でテザリングして艦これしてみました。

すると

でました、猫。ログインしてすぐというわけではないですが、任務をクリックしたり母港に戻ったりとか通信を何度もしていると、私の環境では数分で起きます。これは何かありそうですね。そう思って航海日誌を通さずに艦これしてみると、不思議なことに全く猫は起きません。なぜでしょう。

悩んでても解決できないので、Wireshark を使ってパケットキャプチャをしてみました。そして猫が出るまで通信を繰り返します。そして猫が出た時と出なかった時を比べます。すると

うまく行った時はこんな感じです。これは任務一覧を表示した時ですね。POSTのメッセージに対して ACK が返り、その後 200 の応答が返ってきます。普通です。ところが猫が出た時は（キャプチャミスってボケてます。すみません。）

のように、[FIN, ACK] が返ってきています。FIN は通信終了なので切断するという意味なので、航海日誌が使っている jetty の ProxyServlet は EOFException を投げます。結果ブラウザから見れば通信エラーとなり、猫が出るという仕組みでした。

しかしこれだったら普通に航海日誌抜きでやっても同じなのでは？と思って試してみたところ・・・

おお、これは・・・。どういうからくりかはわかりませんが、上のようにAPIの呼び出しが切断された時はどうもリトライしにいくようですね。これは任務の受諾をやめた時に呼ばれるAPIなので、連続で来るはずはないリクエストになります。通常は stop が来た後 questlist が来るはずのところを２回 stop が来ているので明らかにリトライしているようです。

なので ProxyServlet 経由でも全く同じ状況、FIN を返すことができれば勝手にリトライしに来ると考えられます。しかしそれを ProxyServlet を使ってやるのは難しそうに思います。試しに ReverseProxyServlet を無理やり extends して EOFException が出た時にリトライするサーブレットを書いてみたところ、私の環境では猫は出なくなりました、があまりに無理やり過ぎるので pull request はしないほうがよいかなと思って保留しています。

なぜ通信が切断されるようになったか、という点については、どうもこのメンテナンスでサーバーによっては HTTP 1.1/ keep alive が使われるようになったそうです。とはいえメンテナンス前が keep alive じゃなかったかどうかは全く知らないですけどね。その実装の影響でこうなったのかもしれません。想像でしかないですが。

結論としては、
- なぜか環境によっては艦これサーバーからAPIリクエストの通信が切断されることがある
- ブラウザから直結している場合は自動的にリトライする
- 航海日誌やその他プロキシの実装によってはその切断が別のエラーとして処理されると猫る
ということのようです。なので実装系が違う他のソフトでも同様な挙動をしていれば、航海日誌と同じように猫りやすくなったソフトもあると考えられます。というわけで、この猫事件（？）の真相は「艦これの微妙な（怪しい）挙動」が根本原因であって、航海日誌その他プロキシの実装のバグと呼ぶのはフェアじゃないと思いますね。

undertow を使ってみる

ひょんなことから自分のJavaアプリケーションにWebサーバーというかサーブレットコンテナの機能が少しあったら便利だなと思って調べてみたところ、undertowというのがお手軽に使えそうに見えたので試してみました。

1. インストール

そのJavaアプリケーションはmavenを使っていたので、依存関係を追加するだけです。

  <dependency>
   <groupid>io.undertow</groupid>
   <artifactid>undertow-core</artifactid>
   <version>1.0.16.Final</version>
  </dependency>

いやぁ、この手の依存解決ツールって楽ですよねぇ。今さら ant とか書きたくないです。

2. 使う

トップページの下のほうに Show me the code というのがあるので、そのコードをそのままコピー＆ペーストします。

Undertow server = Undertow.builder()
 .addHttpListener(8080, "localhost")
 .setHandler(new HttpHandler() {
  @Override
  public void handleRequest(final HttpServerExchange exchange) throws Exception {
   exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
   exchange.getResponseSender().send("Hello World");
  }
 }).build();
server.start();

これだけです？ｗ

3. 使ってみる

では早速リクエストを投げてみます。

$ curl localhost:8080
Hello World$ 

これだけです？ｗ（再

たったこれだけですがサーブレットコンテナとして既に動いているわけですね。これはなかなか楽かも。

当然ですがこのままでは localhost からしかつながりません。 addHttpListener のところで "localhost" を "0.0.0.0" とかにすれば任意のマシンから接続できます。

#f1yosou を今シーズン限りでやめることにしました

公式アカウントから既におしらせした通り、これまで約４年半に渡って開催してきた #f1yosou ですが、今シーズンの終了を持って開催を終了することとしました。みなさん気を遣ってくださって、理由は特に聞かずに受け入れてくださっている方がほとんどですが、決定に至った理由を書いておきますね。

理由を一言で言うなれば「一定の役割を果たした」という感じでしょうか。当初の目的だった、ツイッターでゆるい感じの予想大会をして、それでＦ１好きの方々でわいわい楽しめたらいいね、という目的は果たせたかなと思います。

当初はサイトもなかったので、有志でお題を決め、予想を管理して、的中者の発表をしていました。人数も少なかったので、フォロワーさんの間でわいわいやりながら、特に強制することもなくおめツイートもしていましたね。そのうち管理が楽になるように私がサイトを作りました。私の技術不足（ウェブ周りの技術者じゃないのです）もあり、結構な時間を費やしましたが、参加していたみなさんからの暖かい言葉に助けられ、なんとか使える程度のサイトを作ることはできたのかなと思っています。

サイトが出来たことで、手作業に比べてはるかに楽になりましたし、Ｆ１の話題、しかも予想のお題が上位とは限らなかったので普段注目しない順位のドライバーの話題に一喜一憂できる楽しさがあったので、もっと多くの方と楽しめるように宣伝もし、おかげさまで2013年には最大５１名もの参加者を集めることができるようになりました。主に私の技術的興味の側面もありましたが、サイトのリニューアルなんかも行ってきました。途中でインフラとして使っている Google App Engine の課金方法が変更され、それまでの方法ではすぐにサイトが使えなくなったりする苦労もありました。以降施したさまざまな改善により、最近はサイトが使えなくなるようなことはおきないようになりました。いやぁ、Datastore Read Operations の制限は厳しかったっすよ Google 先生。。

そんな苦労もありましたが、でも多くの方、特に初期のころから参加してくださってるみなさんは、ツイートの自動検出が難しいこと（投票のフォーマットは決めていないので）や、課金されないように運営することが大変なこと、などを理解してくださっていたので、いろいろ対策した後の効果の検証を助けてくださったり、何よりねぎらいの言葉をかけてくださったのが非常にうれしく、運営のモチベーションになっていました。

***

しかし、人数が増えたことだけが問題とは思いませんが、運営を続けるにつれ初期に比べて参加者のみなさん同士の新たなつながりは少なくなったように感じていました。的中者におめでとうのツイートをするのが唯一の賞品なわけですが、それを行わない方も多くなったように思います。もともとおめツイートをすることによって、これまでフォローしていなかった方と新たにつながったりできるといいよね、という考えで参加者を広く募ってきていたので、それが行われないとなると続ける意義がどれだけあるのかがわからなくなってきました。また、おめツイートをしても１ターン（？）で会話が終わることもほとんどで、なかなか新たなつながりには結びつかなくなりましたね。

さらに、最近は運営に対する批判もいくつか頂戴しました。上記のように、「ツイッターでゆるく予想を楽しむ」がコンセプトだったので、予想のツイートには特にフォーマットを定めておらず、そのために検出漏れ、検出間違い等はどうしても避けられませんでした。そのため「予想がおかしいです、直してください」というお知らせはよく受け取りましたが、多くのケースはドライバーの名前があまり見ないカタカナ綴りやあだ名になっているか、お題の答えになっていないケース（たとえば10位のドライバーを予想してください、というお題で、「10位は可夢偉」ではなく「可夢偉は10位」とツイート（お題の抽出精度を高めるために助詞の前後の関係とかも見てるのです））だったりすることが多かったです。その都度ある程度対応していますが、参加者全員の名前の読み方を統一することは不可能ですし、一部を調整すると他に検出漏れが出るなどの問題もあり、残念ながら手作業は欠かせない状況です。ですが私はもちろんこのサイト管理で食い扶持を得ているわけではないためサイトに張り付いて管理することはできず、どうしても対応は遅れがちになります。その状況で「まだ直ってないんですが」というツイートを何度かもらうのはさすがに滅入りました。それ以外は主に私の管理者としての問題に起因するのでしょうが、他にもいくつか批判を頂戴しました。

***

ですが、これらはある意味不特定多数の参加者を募っている時点である程度しかたのないことなんだと思います。サイトの運営で利益を上げているわけではないのでそれらの批判には腹も立ちますが媚びへつらう必要もないわけで受け流せばよいわけです。それよりも直接の原因となったのは、むしろ「孤独感」のほうかも知れません。

以前は何かサイトを改良したりすると参加者のみなさんからすぐに感想をもらえましたし、こんなことやってるよというツイートに誘われて今度参加してみますという会話がＴＬ上にあったり、「Statsのページはまだかな（チラッ」のようにさりげなく期待の声があがっていたり。 もともとは予想１つだったのを２つを予想するようになったこと。ポイントシステムを採用したこと。これらもすべて私ではなく参加者のみなさんで決定したことでした。私やサイト、公式アカウントが何かするのではなく、みんなで決めていた、その感覚が楽しかったのかも知れません。最近参加された方はもちろんご存知ないと思いますが、サイトや公式アカウントのロゴも私が作ったのではありません。

それに比べると今は「管理者」としての立場が強すぎるのか、私自身もひとりで黙々とミスなく作業するのが当たり前という感覚ですし、参加者のみなさんから頂戴する批判からもかなりのみなさんがそのような感覚でいるのだと思えます。それは果たして #f1yosou が求めてきた姿なのでしょうか。これ以上運営していて何か意味はあるのでしょうか。

いろいろな変化があるとは言え、 #f1yosou をはじめたころに参加していたメンバーの大半が参加していないかまたはほとんどツイートしなくなってしまっています。シーズン末の結果発表にわざわざ「皆勤賞」「準皆勤賞」を設定しているのは、ずっと参加して盛り上げてくださっているみなさんに少しでもお礼・お祝いをしたいという気持ちで設定していますが、逆にほとんどツイートしていないのに #f1yosou だけ参加してくださってる方もおられ、そのような方にはむしろ余計な義務感を与えてしまっているのかもとさえ思います。もともとの「ゆるく予想して楽しもう」のコンセプトからは完全に離れてしまったと感じています。

***

このような考えに至り、そろそろ #f1yosou は幕引きの時期を迎えたのだろうと判断しました。公式アカウントとしては特に感情抜きで作業するようにしていますが、やはり日本ＧＰは特別なものなので、発表は日本ＧＰのころにしようと決めていました。参加者のみなさまには突然のお知らせとなって恐縮ですが、決めたのはもっと前になります。

もちろん、ツイッターのハッシュタグの性質上、この #f1yosou というタグになんら縛りがあるわけではないので、来年以降これをつかって予想する方々がおられても楽しいですし、どこかで似たようなイベントを起こす方がおられてもいいですね。私もどこかで参加するかも知れません。

以上、長文失礼いたしました。残り５戦となりましたが、参加者のみなさまと #f1yosou を楽しめるよう努力しますので、最後までお付き合いいただけるとうれしいです。公式アカウント、サイトとも今年いっぱいは維持する予定です。

2014年9月30日

@f1yosou と中の人 @Sdk0815

アメリカ出張の話（完結編）～ Ready SIM 使ってみました

前回書いたとおり、アメリカに出張に行ってきました。その時通信手段として、今回は Ready SIM というプリペイド SIM を試してみました。その結果のお話です。

Ready SIM は文字通り買ったらすぐ使えるというところをポイントにしているプリペイドSIMです。アメリカ国内だと送料が無料なのですが、今回は出張が決まったのが出発の４日前、ホテルが取れたのが３日前というわけで、通常の発送では間に合わないと思われたので、仕方なくトラッキング付きの $8.99 での発送にしました。あて先は滞在先のホテルです。

当然出発前に発送されたので、そのメールにあるトラッキングの番号でUSPSのサイトに行くと、配送状況が見れました。出発前に既に目的地の州に到着していて、乗り継ぎの空港で見たらもう Delivered となっていてホテルについていたようでした。楽しみにしつつ飛行機を乗り継いで目的地へ到着。

さてチェックインの時に「私宛に package（荷物）が届いてない？」と聞いてみたところ、「いや、何も届いてないよ」との返事。ううむ。おかしいですね。トラッキングの画面を見せて説明しないとだめかな？と思ってフロントへ行ってみると、既に深夜だったため（０：３０）誰もおらず。しかしフロントの中をのぞいてみると、なにやら大きめな封筒が・・・。しかも USPS って書いてある。たぶんあれじゃないか？

と思って翌朝フロントで「私宛に USPS 経由で mail（手紙）が届いてない？」と聞いたところ、その置いてある封筒を見て、「名前は？」と聞かれ、答えると渡してもらえました！やったー。封筒で届いたやつだと package と言うと認識されないかもですね。なるほど。

届いたのはこんな封筒です。→
アメリカではよくみるやつですかね。

早速中をあけてみましょう。中には本体（？）とレシートが１枚入っているだけです。シンプルですがもちろんこれで十分。今回は現地たった４泊５日なのと、遊びに行く暇はなく会社との往復と夕食ぐらいしか移動することはないので、最低のデータ通信量（500MB/$15）のカードを買ってみました。そのように台紙にも書いてありますね。サイズの下に "Expires after 14 days"、つまり１４日しか使えない旨も明記されています。

その下にある"7850"という数字がミソでして、基本自動でアクティベートしてくれうのがウリではありますが、狙った地域の電話番号を取ることもできるようです。その際はSMSでこの7850に向かって郵便番号を送ればいいとのこと。ただ今回はデータ通信のみのカードなので特に気にしなくてもいいですがね。

さて早速使おう・・・と思ったとき実はあせりました。どう見ても SIM のサイズが大きいのです。あれー、Micro SIM って頼んだはずなのに、自分か向こうかが間違えたかな？SIM カッターなんて持ってないよ、と思ったのですが、よく見ると細い溝が入っていてちょっと押せばこのように Micro SIM のサイズで取れるのでした。よかった。


さあ実際 SIM フリーの iPhone 4S に入れてみましょう。ただこの SIM にはピンが付いているのか不明だったので、念のため日本から SIM を入れ替えるためのピンを用意しておきました。実際入っていなかったので持って行って正解でしたね。入れ替えて日本のやつをなくさないようにこの台紙に入れておきます。さあスイッチオン！

・・・つながらないですね。当たり前か。モバイルデータ通信のところで APN の設定がいります。まあそのぐらい楽なもんなのでさっさとやります。・・・まだつながらないです。

うーむ。やはりSMSで送らないとだめかな？でもiPhoneでの送り方知らない・・・。などとホテルの WiFi 経由でググったりしていたら

いつの間にかつながっていた

なんという拍子抜けｗ アクティベーションが自動だとは言え、数分はかかるみたいなので、単純に待っていればよかったようです。一応 SMS で郵便番号を送ってはおきましたが、開通してしまった後では意味があるのか不明でした。

一度つながると、このように T-Mobile の回線として認識されています。使い勝手は正直地域にもよると思うので何とも言えませんが、今回の滞在中では会社の地下の会議室ではかなり電波の入りが悪い感じでしたが、それ以外ではほとんどつっかかることもなく良好でしたね。

というわけで、この Ready SIM、プリペイド SIM としては非常に楽です。事前に手に入っていれば、恐らく差し替えて APN の設定さえすればすぐつながると思います。ホームページからアクティベーションをして、トップアップカードを買って、とやるよりは数段楽ですね。

というわけで総じて気に入ったので、早速次回用に日本に発送してみました。日本宛の送料は $9.90 でした。来月使うのはほぼ決定なので、今回は２枚注文しました。結果的に１枚当たり $15+$9.90/2 = $19.95 ですね。手軽さを考えれば十分安いです。

しかし、一度アクティベートしてしまうとそこからは14日とか決まっていますが、使わないで持っていたらいつまで有効なんでしょう？会社がつぶれるまで？ｗ 便利なのでつぶれないでもらいたいものです。

アメリカ出張に行くことになりました（アメリカでのSIMカードの話）

まあ話は出ていたのですがえらい人の折衝がなかなかはかどらず、昨晩ようやくいろんな承認ものがすべて完了し、本日から手配を開始したわけです。出発予定はなんと来週の月曜日。あと４日しかないｗ 労働日なんて明日１日だけ！ｗ

私はアメリカ出張は何度か経験があり（１年ちょっとの赴任も含む）、慣れてると思われがちなんですが、実はアメリカへの出張ではカリフォルニアのいわゆるシリコンバレー以外に行ったことがないのです。ですが今回はカリフォルニアのあるPST/PDT（太平洋標準時／夏時間）の時間帯ではなく、CST/CDT（中部標準時／夏時間）の時間帯にあたるテキサス州はオースティンに行くことになっています。なので飛行機の常識とかもよくわからず、微妙に戸惑っているのですね。

カリフォルニアだと大体日本の夕方出発、向こうの午前中に着。向こうの午前発、こちらの（翌日）午後着、が普通ですね。最近は羽田から深夜便とかもあって、それに乗ると深夜出発、向こうの夕方着、向こうの夕方発、翌日夜着になりますね。個人的には着いた当日、帰ってきた日はすぐ寝たいのでこの深夜便はかなりお気に入りです。ですが今回の場所はこの手の常識もないのでいまいち感覚がつかめず。どうなることやら。（なんて言ってられる時期かどうかは不明ですが・・・。まだ取れてないものは仕方がない。）

今回はこれまた初経験なのですが、３人での同一行程の出張です。しかも私より年上の方々が一緒なので、責任は少なくて楽かな？でも逆に一人での自由行動は取れない（レンタカーが１台なので）という難点があります。一人でうろうろ出来るなら観光しようと思ったけど・・・。聞いたらあまり観光スポットはないかもとのことで。まあ私ならここ一択ですけどね！まあ遊べる時間はほぼないと覚悟しています。

しかし、やはり無駄に金だしてSIMフリーiPhoneを買ったバカ技術者としては、アメリカ出張となると外でのネット接続に異様な執念を見せたくなるわけですｗ 前回のドイツのときは事情がわからなかったのでモバイルルーターを借りていきましたが、アメリカはSIM万歳の国ですよ。ええ。せっかくのSIMフリー端末を活用しない手はない！（←結局言ってるｗ）

前々回の出張はアメリカ・カリフォルニアだったのですが、その時はAT&TのSIMを買っていろいろ悪戦苦闘しながら接続しました。でもその価値はあって、レンタカーにはナビは着いておらず、現地の人たちと遠くのレストランに行く時に私と同行者（日本人）だけで車で行かなければいけなかったのを、無事ナビ代わりにしてつくことができました。今回はそんな役目はなさそうですが、別の大きな理由がありまして。

来月インディーカーの最終戦であるMAVTV 500＠フォンタナというレースがあるんですが、これを念願の現地観戦する予定になっています！飛行機はもう取ったので絶対いきます！その時には当然１人なので、ネット接続は非常に大事。何か試すなら今回の出張で試して、インディーカー観戦のときは万全の体制で臨みたいわけです。

では何を持っていくか。まず一番安心確実なのはやっぱりモバイルルーターなのです。 たとえばドイツ出張の時は US-RACING さんによく提供してくれているテレコムスクエアさんから借りたのですが非常に助かりましたね。設定はほとんどいらず、現地でオンにするだけ。電話も使える普通のスマホとかもあって、普通の旅行に行く方にはもちろんこれがお勧めです。アメリカだと 1,000円／日 ですかね。この金額がまず鍵になります。今回は日本不在期間（＝借りる日数）が６日なので、6,000円也。

さてではまず前回と同じAT&TのSIMを買ったらどうなるか。前回は恐らく日本では買えなかったという意味だと思うんですが、eBayで$10ぐらいで買って日本に送ってもらいました。いろいろググってもらえばわかるんですが、そこからが結構面倒なのです。まずアクティベーションという処理が必要になりますが、これ、ネットとかからもできるんですけど、最終的に現地でSMSを受け取らないといけないので、結局現地についてからしか処理ができない。今日会社で聞いたらそのへんやれるのかやってくれるサービスなのかで日本で全部できましたよと言ってた人がいたので、最近は変わってるのかも知れません。で、アクティベーションした後に通信するためのお金をチャージするんですが、これも日本のクレジットカードではできませんでした。なのでスーパーでトップアップカードというカードを買ってチャージするという方法でなんとか使えるようになりました。

ただこの方法、手続きも結構微妙な線をついていて、なぜかスペイン語に言語を変更しないと手続きできないとか、 IMEIをどっかからもってこなきゃいけなかったりとか、かなり面倒な印象。しかも有効期限のあるプリペイドで使い切りなので、アメリカから帰ってきて１年後に行くときに使いたいと思っても、別のSIMを買ってやりなおさないといけない。まあこれは前回の印象なので、最近はだいぶ改善したようではありますが、今回はせっかくなので他の手を探ってみます。250MB/７日で$15と。SIMは今なら日本のアマゾンでも買えますね。1,000円程度です。

いろいろググっていたら KDDI mobile x h2o なるサービスを発見しました。日本で買えるなら便利ではあります。・・・ってオンラインショップでは「日本での購入を希望」というボタンは押せないし、日本の販売店のリストを見てもいまいち微妙な感じ？あと、一度チャージしなくなった後再チャージした場合にどうなるのかがいまいちはっきりわからないのです。これができると AT&T のとはずいぶん楽さが違うんですが。で、もっと調べていて一番困るかも知れないと思ったのは、データ通信分を使いきると追加等ができないことですね。たぶん越えないとは思うんですが、いざ超えた時に何も対策が取れないのはキツイ。なのでこれはナシかなと。通話つきで 500MB/１ヶ月で $30。

最後にググっていてたどり着いたのは Ready SIM でした。これこそまさにプリペイドの使い捨てです。T-mobileの回線を使っているらしいですが。これのよさげなところは、アクティベーションが楽っぽいこと。入国したらSIMさしてほうっておけばいいだけっぽいです。プリペイドで最初から通信量がついているので、トップアップ等も必要ないようですね。おまけに日本にも（というか国際）発送してくれるようなので、今回は当然間に合わないんですが、事前に頼んでおけば、アメリカ着いてSIMさせば終わり？あと、データ量足りなさそうな場合は後で追加もできるっぽいです。国際発送してくれるぐらいだから、日本のクレジットカードでも大丈夫なんじゃないかと期待しています。AT&Tに比べるとカバレッジが低いんじゃないかと言われてるようですが、今回行くとこ、あとフォンタナもカバレッジを見る限りバッチリカバーされているようなので気にしなくていいかな。500MB/14日で$15（SIM代込み）なのでAT&Tよりも安いですね。これは試してみる価値ありそう。

そう思って問題になるのはどうやって手に入れるかです。空輸は間に合わないので、現地調達ですかね？でもよく見るとデータ通信専用（電話なしなので安いほう） はオンラインでしか買えないようです。これは困りました。しかも FREE standard shipping within the USA、つまり米国内なら送料無料じゃないですか。いいなー。

では日本で売ってくれる業者さんはいないのかと調べてみました。おお、日本のアマゾンとかでも売ってますね。どれどれ・・・。「通話とSNS、データ通信500MB ７日間」サイトで$25のやつですね。価格は・・・

\5,980

倍じゃきかない・・・。orz

それ以外もいくつか調べましたが、売り切れだったり似たような（$15 のやつを\4,000とか）価格設定だったので、正直買う気が失せました。日本までの送料があるとはいえ、本来$15や$25と知ってしまったのでそれが\4,000や\5,980になってしまうと手が出なくなってしまいます。我慢して現地のお店で買おうかと思ったらオースティンにはないようだし、そもそも３人同行なので（しかも年上の方に）「ちょっとSIM買いに行きたいんですけど」は言いにくい。そうなると残る手はただ一つ。

「アメリカのどこかに送るしかない」

同僚がよく「出張中にアメリカのアマゾンでしか買えないグッズをホテルに送ってるんです」とか言ってたことを思い出しました。聞いてみると問題なくホテルで受け取ってくれて、部屋に入るとおいてあったりしますよ、とのこと。ふむふむ。これはいいことを聞いた。失敗しても$15とかだし、まあ話のネタになったとあきらめもつく金額だからこれを試してみようと思います。そしてもしうまく行って使い勝手もよかったら、14日過ぎた後に2GB/１ヶ月 $40をチャージすると、フォンタナに行く期間がカバーできる。まあ2GBもいらないと思えば普通に500MBのを日本に輸入する実験をしてみてもいいですしね。

などと期待しつつ、まだホテルが決まってないので購入できないでおりますｗ 早く決めてほしいものですね。結果どうなるか、乞うご期待。