Charge Padで、Qi対応他製品の充電を試す

「Charge Pad」はPanasonicから発売されている無接点充電が可能な充電システムです。

Charge PadはQi規格に準拠しており、この規格へ準拠した充電パッドや充電池での相互接続が保証されています。そこで他社のQi対応製品も試してみました。

購入したのは、eneloopをQi対応充電パッドで充電するための、SANYO製充電機能付キャリングケース「N-WL01S」と、マクセル製iPhone4用充電カバーWP-SL10A.BK。

SANYOはPanasonicの完全子会社となったため、SANYO製のN-WL01SもCharge Pad製品群へ含まれてもおかしくありませんが、未だeneloopとEVOLTAが併売されていることもあり、Charge Padとは別カテゴリ、という扱いになっているようです。

パッケージの外観。

ChargePadの充電ケースQE-CV201-Kと非常に良く似ています。カラーバリエーションとして白黒の2種類が用意されている点も同じです。

QE-CV201-Kと一緒に充電パッドへ載せてみました。サイズも質感も同様。ケースへの電池セット方法も一緒。

N-WL01Sはeneloopの充電を保証しているQE-CV201だと言えるでしょう。ご自宅にEVOLTAをお持ちの方はQE-CV201を、eneloopをお持ちの方はN-WL01Sを選択すれば良いのだと思います。

マクセル製iPhone4用充電カバーWP-SL10A.BKは、ChargePadよりも先行し、今年の4月に発売された製品です。勿論、充電池と共に充電パッドも発売しています。マクセルによれば、Qi準拠の充電パッドの発売は「国内初」とのこと。

パッケージの様子。

ケースの表と裏。カメラ穴が空いています。

本体重量は45g。非常に軽く作られています。

iPhone4との大きさ比較。やや下に伸びる形状です。

iPhone4へ差し込んだ状態。非常にきっちりハマり、抜け落ちてしまう心配ありません。逆に言えば、頻繁に抜き差しを行う運用に適した製品ではありません。

 充電パッドへ置いてみました。結構大きめです。

iPhoneを保護するケースでありながらも、手軽に充電可能であるという点で、本製品は運用的に魅力のある製品だと言えるでしょう。

一方、最大の問題は、ケースにDockコネクタが存在しないことです。つまりiTunesとsyncするには、毎回ケースから外さなければなりません。しかし、ケースがきっちりとしたサイズで作られているため、気軽に抜き差しが出来ません。

幸いiOS5からはWirelessSyncが可能になります。このケースの真価が発揮されるのは、iOS5をインストール後なのかも知れません。

N-WL01S、WP-SL10A.BKとも問題無くCharge Padの充電パッドで充電が可能でした。標準規格へ準拠しているメリットが十分に生かされています。

無接点充電は、充電に伴うケーブル接続や、電池を充電器へセットする煩わしさから解放してくれる、大変に便利な仕組みです。今までこれらの面倒な作業を敬遠し、乾電池を利用していた人々が、これを機会に充電池へ目を向けてもらえれば、と思います。

Panasonic「Charge Pad」関連商品を購入しました

Panasonicから発売されている、無接点充電システム「Charge Pad」を購入しました。

無接点充電システムは、充電池を簡単に充電するための仕組みです。充電池を充電パッドの上に置きさえすれば、あとは自動的に充電してくれます。電池を充電器へセットしたり、ケーブルを差し込んだりする必要がありません。

現在無接点充電器として、Magic Mouse用のバッテリである「Mobee Magic Charger」や、Wiiリモコン充電器を利用していますが「置くだけ」という運用は予想以上に快適です。

今回Charge Pad製品群の中から、無接点充電パッド「QE-TM101-K」、USB対応モバイル電源パック「QE-PL201-K」、単3・単4形ニッケル水素電池専用充電機能付キャリングケース「QE-CV201-K」を購入しました。

ChargePad製品群は、白黒2種類のカラーバリエーションで展開されていますが、今回は充電機器としては珍しい黒で統一です。

無接点充電パッドQE-TM101-K。Qi対応充電池を置くことで充電することが出来ます。

同梱物のマニュアル類。丁寧な作りです。

QE-PL201-KはUSB対応モバイル電源パックです。iPhoneをはじめとするUSB充電可能な機器へ給電できます。サンヨーから発売されていたeneloop mobile booster KBC-L2ASのPanasonic版だと言えるでしょう。

KBC-L2ASとの比較。ほぼ同じサイズですが、充電容量は400mAh増加しています。

 KBC-L2ASで用意されていた充電用ACアダプタ端子は省かれmicro USB端子のみになりました。これに伴い付属のACアダプタもmicro USB出力可能なものに。とはいえ、充電パッドが利用できる環境では、ACアダプタを利用することはそれほど無いでしょう。充電時間は、無接点充電の場合も、ACアダプタ経由も共に公称値7時間で、差はありません。

QE-CV201-KはPanasonic製の充電池であるEVOLTAを2本充電する為のケースです。EVOLTAが2本付属しています。

充電パッドへ通電すると、パッド上で青く丸いリングが点灯します。

このリングは充電可能領域を示すものです。但しリングの上に充電池を置く必要はありません。パッド上へ充電池を置くことで、電池の置かれた場所が自動的に認識されます。その際、リングも充電池の下へ移動し、充電が自動的に開始されます。

QE-PL201-Kを充電している様子。

QE-CV201-Kに格納されたEVOLTAを充電している様子。

では、複数の充電池を同時にパッド上へ置いた場合、どうなるのでしょう?

この場合、まずどちらかの充電を集中して行います。片方の充電完了後は、自動的に充電領域が移動し、残りの充電池へ充電を開始します。非常に賢い仕組みです。

実際の使い心地ですが、QE-PL201-Kのような「USB対応モバイル電源パック」の場合には、文句なく便利です。帰宅後、そのままパッドの上へ放置し、外出時にカバンへ収納するだけの簡単運用が実現できます。

QE-CV201-Kのような電池ケースの場合、電池を充電ケースへ収める作業が必要な点で、旧来の充電器を用いる運用と差がないように思えますが、充電器をコンセントへ差す手間が省かれる点や、充電器にコンセントを塞がれないなどの点で使い勝手が向上します。

また、複数種の充電池を使用している場合、個々の充電器やACアダプタを管理する必要がありますが、Qi対応機器であれば、充電パッドをただ一つ用意するだけで、これらの機器を管理する必要からも解放されます。

「環境へ配慮など点から、乾電池では無く充電池を使いたい、でも充電という運用は面倒だ」と感じている方々へ、是非利用していただきたい製品だと思いました。

OS X LionからReadyNASをAFP経由で利用する場合の注意点

OS X LionからNETGEAR ReadyNASをAFP(Apple Filing Protocol)利用する場合、ファームウェアであるRAIDiatorをバージョンアップする必要があります。

UltraやProなどのx86 CPUを積んだReadyNASの場合、正式版ファームとしてRAIDiator 4.2.18が、一方DuoやNV+などのSparc CPUを積んだReadyNASの場合、ベータ版ファームとしてRAIDiator 4.1.18-T5が、それぞれリリースされています。

これらのRAIDiatorを利用することで、Lionを動作させているMacからも、ReadyNASをTimeMachine用デバイスとして活用したり、AFP経由で接続できるようになります。

但し、AFPでの接続時にユーザ認証を利用している場合には注意が必要です。

もしLion上のアカウントとReadyNASで認証用に利用しているアカウントのUIDが同一の場合、Lionから接続できない、またはファイルを書き込めない/更新できない、などの問題が発生する可能性があります。

例えばMacOS X上で初めてユーザを作成した場合、特に明示的な変更を行わない場合には、UIDとして501が利用されます。この状態で、ReadyNASに認証用ユーザを作成し、そのUIDへ501を割り当てた場合、問題が生じてしまう可能性があります。

問題を回避する簡単な方法は、ReadyNAS上のUIDを変更してしまうことです。Webの管理コンソールから、「セキュリティ」「アカウント管理」と辿り、「ユーザ」タブにある当該ユーザのUIDを変更しましょう。

なおReadyNASは、既存ファイルのUIDも変更してくれますが、処理の完了に時間がかかりますので、暫く待つ必要があります。また、ReadyNASへNFSなどで接続している場合には、UIDの変更により、既存ファイルへアクセス出来なくなる可能性があります。この場合にはLion側のUID変更を検討したほうが良いかもしれません。

ReadyNASのフォーラムへkraneyさんが投稿してくださった書き込みによれば、問題はReadyNASがAFP接続に利用しているnetatalkに於けるユーザ認証の実装にあるようです。

この情報をご提供くださったkraneyさんへ感謝致します。

Google+ を使っている場合には、Google Contactsの削除に注意すべき

Google+では、Google Profileが活用されており、各種機能と連動しています。

例えばGoogle+へは「サークル」と呼ばれるグルーピング機能が備わっています。グルーピングの単位は「家族」や「同じ趣味を持っている人々」など、自由に設定可能です。メンバへは、Google+アカウントを持っている人は勿論、アカウントを持っていない人も登録できます。

Google+アカウントを持っている人をサークルへ登録した場合、Google Contactsへ、そのユーザのエントリが作成されます。このエントリはProfileというフィールドを持ち、そのユーザを指し示すGoogle ProfileへのURLが格納されます(既にそのユーザと結びついたGoogle Contactsのエントリが存在する場合には、そのエントリへProfilebフィールドが追加されます)。登録されたエントリは、Google Contactsへアクセスし「すべての連絡先」を参照することで確認できます。

では、登録された人のエントリを削除した場合、どうなるのでしょうか?

なんと、削除した人はGoogle+のサークルからも消えてしまいました!

これがGoogle+の恒久的な仕様なのか、暫定仕様なのかはわかりませんが、当面Google Contacts内にある、Google+ユーザのエントリを削除する場合には、十分注意したほうが良いでしょう。

MacOS XのAddress BookとGoogle Contacts同期の姓名逆転問題を検証する

MacOS X 10.6(Snow Leopard)へ付属のAddress BookにはGoogle Cotactsと自動同期させる仕組みが備わっています(Address Bookによる自動同期の仕組みは以前のMacOS Xから備わっており、10.6からの追加機能ではありません)。

Google ContactsはGmailをはじめとする様々なGoogleのサービスで利用されているため、各種アドレス帳アプリケーションと同期ができると便利です。

Address Bookで自動同期の設定を行うには、Address BookのPreferencesからAccountsを選択し、「Synchronize with Google」を有効にします。Google Accountを入力すれば設定完了です。

同期は一定間隔で自動的に行われます。または、Menu BarにあるSyncアイコンから明示的に同期させることも出来ます。

しかしこのAddress Bookに備わった自動同期を用いて同期を行った場合、Address BookとGoogle Contactsとで姓名の表記が入れ替わってしまいます。正確に言えば、姓名の入れ替わった別アドレスデータが作られてしまうため、アドレス帳の項目が2倍に増えてしまいます。

Address BookとGoogle Contactsの同期情報を調べてみたところ、以下のことが分かりました(なお、Address Book、Google Contactsとも利用言語環境で動作が異なる場合が考えられますので、ご注意ください)。

• データフォーマットはAtomベース
• 姓名データは「title」フィールドへ納められる(e.g. <title>太郎 山田</title>)
• 但しAddress BookとGoogle Contactsでは、titleフィールドの構築や解釈の方法が異なっている

Address BookがGoogle Contactsへデータを送出する際、「名」「スペース」「姓」形式でデータを格納します(e.g. <title>太郎 山田</title>)。

姓名何れか一方にデータが入力されている場合は、スペースを挿入することなく、そのデータだけを格納します(e.g. <title>山田</title>)。

一方Address BookがGoogle Contactsからデータを受け取る際には、やや複雑な処理が行われます。

<title>フィールドへスペースが含まれていない場合、全てのデータを「名」として解釈します。この場合「姓」は空白のままです(e.g. <title>太郎山田</title>は「太郎山田」という名になる)。

<title>フィールドへスペースが含まれている場合、基本的にはスペースの前側を「名」として、残りを「姓」として解釈します(e.g. <title>太郎 山田</title>は「山田」が姓、「太郎」が名になる)。

ただし、スペースで区切られた何れかの単位へ「,」が含まれている場合、その「,」が含まれた単位を姓として解釈します。「,」自体は姓へ含まれません(e.g. <title>太郎, 山田</title>の場合「太郎」が姓に、「山田」が名になる。一方<title>太郎 山田,</title>の場合「山田」が姓に、「太郎」が名になる)。

一方Google Contacts は、送り出し時にやや複雑な規則が適用されます。

姓、名ともに「,」が含まれていない場合には、「姓」「名」の順にスペースを挟むこと無く格納されます(e.g. <title>山田太郎</title>)。

姓名何れかに「,」が含まれている場合、「名」「スペース」「姓」の順で格納されます。ただしAddress Bookと異なり、「,」の含まれているフィールドを特別扱いすることはありません(e.g. <title>太郎, 山田</title>や<title>太郎 山田,</title>)。

但し、これらの規則が適用されるのは、「姓」「名」のフィールドをGoogle Contacts側で入力している、または、変更している場合に限られるようです。Address Bookから送り込まれた姓名は、Google Contactsで変更を行わない限りそのまま利用され、「名」「スペース」「姓」の形式が保持されたまま格納されます。

Google ContactsがAddress Bookのデータを解釈する場合の規則は単純です。

もし<title>フィールドへスペースが含まれていない場合、Address Book同様、全てのデータを「名」として解釈します。この場合「姓」は空白のままです(e.g. <title>太郎山田</title>は「太郎山田」という名になる)。

スペースが含まれている場合には、スペースで区切った前側を「姓」、後半を「名」として解釈します。「,」の有無などは考慮されません(e.g. <title>太郎 山田</title>の場合、「太郎」が姓、「山田」が名になる)。

概略をまとめたものを次に示します。ABはAddress Book、GCはGoogle Contactsです。また、<title></title>は<t></t>に省略しています。空白は「␣」で示します。Google Contactsの表記に於ける姓名の情報は、GmailのContactsで確認できる「詳細」を用いて確認しています。

アドレス帳に於ける表記から生成される伝送上の形式

• 姓: (空) / 名: 山田太郎
• AB: <t>山田太郎</t>
• GC: <t>山田太郎</t>
• 姓: 山田 / 名: 太郎
• AB: <t>太郎␣山田</t>
• GC: <t>山田太郎</t>
• 姓: 山田, / 名: 太郎
• AB: <t>太郎␣山田,</t>
• GC: <t>太郎␣山田,</t>
• 姓: 山田 / 名: 太郎,
• AB: <t>太郎,␣山田</t>
• GC: <t>太郎,␣山田</t>

伝送上の形式から生成されるアドレス帳に於ける表記

• <t>山田太郎</t>
• AB: 姓: (空) / 名: 山田太郎
• GC: 姓: (空) / 名: 山田太郎
• <t>太郎␣山田</t>
• AB: 姓: 山田 / 名: 太郎
• GC: 姓: 太郎 / 名: 山田
• <t>太郎␣山田,</t>
• AB: 姓: 山田 / 名: 太郎
• GC: 姓: 太郎 / 名: 山田,
• <t>太郎,␣山田</t>
• AB: 姓: 太郎 / 名: 山田
• GC: 姓: 太郎, / 名: 山田

Address BookとGoogle Contactsの同期は、厳密な整合性が確立出来ていないように思えます。

この両者の複雑な関係を元に運用案を考えてみましょう。

分かることは、Address Bookで姓名を分離して入力されたデータは、Google Contacts側では必ず姓名が逆転してしまう、ということです。つまり、Address Book側での姓名分離を諦めるか、入力はGoogle Contacts側に限るか、のいずれかを選択しなければなりません。

Address Book側での姓名分離を諦める場合、名に「山田 太郎」と入力してしまう方法が考えられます。この場合Address Bookから送出されるデータは<title>山田 太郎</title>となることから、Google Contacts側では、「山田」が姓に、「太郎」が名に解釈されることになります。結果、Google Contacts側では姓名が期待通りに分離表示されます。また、Google Contacts側でデータを改変した場合でも、Google Cotacts側から送出されるデータは、<title>山田太郎</title>となることから、Address Book側では名に「山田太郎」が格納され、元の状態と一致します。

次案としてはGoogle Contacts側でのみデータを入力し、且つ、姓に「,」を付加する、という方法です。例えば、姓に「山田,」、名へ「太郎」と入力する、という運用になります。この場合、Google Contactsからは<title>太郎 山田,</title>と送出されることになりますが、Address Book側は、「,」付きのフィールドを姓と扱うため、姓に「山田」、名に「太郎」が表示されます。但し、Address Bookでデータを変更してしまうと、Google Contactsへは、姓が「太郎」名が「山田」のデータが新規に作られてしまうでしょう。

結局、どちらの方法も一長一短があり、今ひとつすっきりした解法は難しいようです。

なお、自動処理を諦め、データの同期だけを実現したい場合には、Address Book、Google ContactsともにvCard形式でのデータインポート、エクスポートが最も確実でしょう。この場合、姓名の逆転現象は発生せず、また姓名のふりがなフィールドなど、自動同期では無視されていたデータも維持されます。

一点残念な点としては、Address Bookで「Make as a Company」と指定したデータも個人データとして扱われてしまうことが挙げられます。この為、Google ContactsからvCard形式でデータをエクスポートし、それをAddress Bookでインポートすると、「Make as a Company」と指定されたデータが重複してしまうことになります。

ソーシャルサービスの拡大により、アドレス帳データの相互運用は、より重要度を増して来ていると思います。OS X Lionに搭載されるAddress BookとiCloudが、これらの問題へどのような解を示してくれるか、楽しみにしています。