anchor
Macが壊れた！〜その時何をする？とかノウハウものに飛びつく前にそもそものトラシューの考え方をまず理解しよう〜以下トラブルシューティング十訓（１）
Macを使っていて快調に動いているうちはいいのだが、長く使っていると必ずトラブルには遭遇する。
そういうものには遇わないのがいいのだが、これは確率というか歩留まりの問題なのでトラブルシューティングをするというのはパソコンユーザの誰にとっても他人事ではない。
かくいう弊サイト「MacOSXの新着アプリテスト記録とトラブルシューティング」は、本来そのタイトルの通りトラブルシューティングの事例紹介サイトとしてスタートしている。
残念ながら（？）OS XになってからMacはトラブルが少なくなったために、トラブルシューティングサイトという看板では頻繁な更新は困難になってきた。
それでアプリ紹介サイトのようなことをやっていた。
でも、トラブルシューティングこそ普段からの積み重ねが物言うし、トラブルが起きてから途方に暮れてもどうにもならない…そしてうまくいった時に醍醐味を感じられるのもトラブルシューティングの時なのだ。
そのトラブルシューティングだが、むやみやたらと知ってる方法を試してみるというだけではまずうまくいかない。
掲示板のMacのスレッドなどでよく見かけるやり取りだが
「Macの調子が悪くなりました。どうしたらいいでしょうか？」
「fsckをやりなさい」
というのがある。
相談する方も「調子が悪くなりました」じゃ何がおかしいのか全く伝えられないし、答える方も何もわからないのに機械的に「fsckをやりなさい」と答えて聞く努力を放棄している。
答える側は真面目に答える気がないし、質問する方はカッカしていて誰かが助けてくれるだろうとトラブルを自分で直すという発想がない。
これでは何もトラブルシューティングになっていないし、治るものも治らない。
そこでトラブルが起きた時にどういうツールを使うとか、コマンドを使うとかいうノウハウものではなく、まずどういう考え方をするべきかをまとめてみた。
この考え方を理解して、手順を踏んでいけば解決するトラブルが大部分なのだ。
考え方を理解すれば、どういうツールが必要になるかも自ずとわかってくる。
いきなり葛根湯医者のように「fsckをやりなさい」ではなく、何をするべきか、その考え方をまとめてみた。
１）頭を冷やせ
まずトラブルシューティングの時に一番大事なことは、これだと思う。
トラブルというのは大体起きてほしくない時に起きるように思えてしまう。
口をぽかんと開いてYouTubeの動画を眺めている時にはトラブルは起きない。
締め切り迫ったレポートを書き上げる直前フリーズとか、急ぎのメールを飛ばさなきゃいけない時にネットワークトラブルとか、９時間かけてエンコードしたビデオがようやくあと５分で完了という時に虹色ボールが回り始めて操作できなくなるとか…
トラブルというのは、大体そういうタイミングで起きるように感じられる。
こういう時に一番してはいけない考え方が、以下の通り。
「かああああ、なんで こんな時によりによってオレだけが問題に遇うのか？
今日はMacが機嫌悪いのか？
このMacは不良品なのか？」
「だいたい買った時から何となく調子悪いんだよな、このMac。
勝手に壊れるなんて、本当に信頼できないんだよなMacって。」
「これを買った時の電気店の店員の態度も気に食わなかったし、Appleなんてお高く止まっているけど所詮この程度の技術力じゃん。」
「ネットの質問コーナーで質問しても、回答者が「機種は何ですか？OSのバージョンは何ですか？」とかいちいち聞いてきてエラそうで、めんどくさいんだよな、あの手の連中とやり取りするのって。」
「ネットでOnyXとかお勧めされてたから、適当に全部の項目にチェック入れてかけたら治るかな？
やってみよう」
「それか、昔からの黄金律だな。
とりあえず再起動してみよう。
それで症状は治るだろう。ファイルは諦めになるが…」
何が問題か分かるだろうか？
それぞれの内容はこのあとの項目とも関連してくるのだが、まず大前提はこの項目のお題の通り
「頭冷やせ」
ということに尽きる。
順番に見ていくと
「こんな時」ってどんな時だよということだ。
パソコンは別にあなたの都合なんか見てやしないし、トラブルは時を選ばずに起きる。
のんびり休日のYouTube鑑賞の時のトラブルなんて印象にも残っていないだろう。
しかし実はトラブルが起きる確率は、よだれ流してネット動画見ている時も切羽詰まった仕事してる時も同じ。
それは切羽詰まった時に食らったトラブルがやはり印象に残るからそう思うのだ。
こういうパソコンあるあるは印象に過ぎない。
そしてそれがオオゴトになるのはまさにあなたの都合。
「こんな時」というのはまさにあなたの都合なのだ。
でもMacなどのパソコンは誰の都合も知ったこっちゃない。
ただの機械だ。
相手が機械なら、機械にふさわしい対応をすればいい。
こんな時もどんな時もないし「よりによってオレ様」も誰様も関係ないということだ。
それに「よりによってこんな時に」「よりによってオレのMacが」というのは、自分では冷静なつもりでもトラブルに会っている俺カワイソウ…という自己憐憫にとらわれている。
「俺は不幸だ。オレのMacは不良だ」
これも冷静な態度ではない。
もしあなたのMacが本当に不良品ならAppleの「交換プログラムの告知」ページに自分のMacのロットナンバーが掲載されている筈だ。
そういうことも調べないで「不良だ」とか決めつけても何も改善しない。
そしてこういうユーザは基本的にパソコンを擬人化する傾向がある。
「今日は機嫌が悪い。」
「すねてる、仕事したくないらしい」
「パソコンのくせに職場放棄とか生意気な」
繰り返すが、相手はただの機械なのだ。
ただの機械にはただの機械にふさわしい対応がある。
パソコンには機嫌なんて存在しないし、大体あなたを嫌ったりもしない。
パソコンを擬人化するユーザは大体トラブルに遭遇するとこじらすタイプが多い。
コーヒーミルが壊れたら「生意気な、コーヒーミルの分際で」とか言う人はいないと思う。
部品構成が多少コーヒーミルより複雑なだけでパソコンはコーヒーミルと同じ。
コーヒーミルに機嫌なんかない。
まずは自己憐憫とか、擬人化、八つ当たりとかはやめて冷静になること。
これがすべての始まりだと思う。
２）症状を観察せよ
また
「何となく調子が悪い」
というトラブルは存在しない。
トラブルには必ず原因があって、その原因の種類、発生部位によって特徴的な症状というものが必ずある。
ならばその症状を観察してトラブルの原因を突き止めることができる。
まずは、「何が、どんなふうに、いつから」調子悪いかを自分の中で整理してみること。
頭が整理できるなら紙に箇条書きするのも有効だ。
動作が遅いのはどういう時に、つまりファイルを保存する時に遅くなるとか、特定のアプリを起動している時に遅くなるとか、遅い時に虹色ボールは出るのかとか、マウスポインタは正常に動くのか、ボタンクリックは正常に反応するのか、その症状は何日前から始まっているのか、その時にインストールしたアプリは何か、遅くなる時に画面が乱れるなどの他の症状は併発しないのか…
という調子で「何となく動きが遅い」というだけでもざっと考えてもいくらでもチェック項目が浮かんでくる。
そしてこれらの質問は、実はそれぞれ問題のある箇所を想定した具体的な質問なのだ。
わかっただろうか？
だからあなたが「Macの調子が何となく悪いんですけど」と相談した相手が、もし「fsckを実行しなさい」とかいきなり言う類いのエスパーではなく、それなりに経験とスキルのある先輩なら
「Macの機種は何か？」「OSのバージョンは？」「電源ランプはどうなっている？」「何かのポップアップを見なかったか？」「ポインタはどうなっている？」
と次々と質問をすることになると思う。
それを「うざい」とか「エラそう」とか「詰問されてる気分になって嫌」とか思ってはいけない。
これは実際にあった話だが、昔トラシュー系のBBSで
「Macの調子が悪いんですけど誰か直せませんか？」
という質問があった。
「調子が悪い」じゃあまりにもざっくりしているので、どこがどうおかしいのか、機種は何か？バージョンは何か？と常連が質問していたら
「結局あんた達にもわからないんでしょ？
わからないならわからないと素直にいえばいいのに、エラそうに質問してごまかして。
故障なのにバージョンなんか関係ないじゃないですか。
気分悪い人たちだな」
とキレてしまった。
当然親切心で質問していた常連さん達は鼻白んで
「いや、別にバージョンなんかどうでも良いんでfsckやれば治るんじゃない？」
でスルーされてしまった。
当然、そういうトラブルではないことは私にもわかったので、この人物のトラブルは解決しなかったに違いない。
このあとカッカしてこの人物は、お店にMacを持ち込んだかもしれないけど、あの態度じゃまともに修理なんかできないだろうなぁ。
なんせ症状を正確に表現できないんだから。
そしてこういう人物が
「Macなんて大したことないじゃん、すぐ壊れるし壊れたら誰も直せないし、
修理も利かないし。
だからWindowsにするべきなんだよな」
なんて自分のせいではなくMacのせいにしたりするのかもしれない。
しかしこの調子では今度はWindowsパソコンが壊れた時に
「マイクロソフトなんて大したことないじゃん、パソコン壊れても直せないし…」
となるんだろうなあ。
こういうのは本当に損な人だと思う。
症状は冷静に観察すべし。
そしてもうひとつの教訓は
調子が悪い時には
先輩の言は素直に聞くべし
なんだよな。
３）切り分けせよ
もうひとつ、問題を解決するプロセスに進む前にやるべきことがある。
それはこの切り分けとなる。
切り分け（isotation）とは何か。
アポロ13という映画がある。
この映画は史実に基づいた、大部分が実話で実際に月着陸を目指した有人飛行で起こった事故を描いた映画だ。
この映画はスペクタクルとして観ても、史実劇として観ても面白いのだが、トラブルシューティングの実践例の教科書として観ても大変面白い映画だと思う。
少し長くなるがストーリーを紹介する。
月着陸有人飛行の３番手として打ち上げられたアポロ１３号は順調に地球周回軌道を離れ、月遷移軌道に乗った。
静かに進行するミッションが月軌道まで３分の１のところに進んだ時に、アポロ司令船が信じられないデータを突然送ってきた。
「酸素タンク２番圧力喪失、１番も圧力が降下中
燃料電池１番から３番電力低下
主配電盤Bは電圧喪失、主配電盤Aも電圧低下」
と同時に飛行士達から
「爆発音と激しい振動が起きている。
計器盤には何十もの『緊急事態』を示す警報ランプが点灯している」
という無線連絡も入ってきた。
宇宙船というのは電気で動いている。
地球と通信するテレメトリーデータ通信も、軌道の計算をするコンピュータも、室内の明かりや温度管理する空調も、噴射をコントロールする自動操縦も、生命維持装置も全部電気で動いている。
そして電気を供給しているのが、液体酸素と液体水素を触媒反応させて電気を作る燃料電池だ。
燃料電池は宇宙船の生命線だからリダンダンシーを確保するために全部の系統が複数、つまり予備系統が設置されている。
酸素タンクはふたつあるし、燃料反応炉は３系統ある。
その電気を集めて船内のあらゆる装置に電気を渡す配電盤も２系統ある。
全部の段階で一系統ずつ同時に故障しても、宇宙船は安全に飛行することができるように考えられている。
ところが突然送られてきたデータを信じるなら、酸素タンク、燃料反応炉、配電盤の全部の段階の予備系を含む全部の系統で異常が起きているとなっている。
当然データを見ている技術者達は
「予備系も全部、しかも同時に故障するなんてあり得ない、計器の故障ではないだろうか？」
と報告した。
しかし飛行主任は納得しない。
「飛行士達は『爆発音がして激しい振動が起こっている』と言っているぞ。計器の故障なら爆発音や振動は起きない筈だ」
しかしいくらデータを洗っても、一向に何が起こっているのかわからない。
その混乱の中さらに飛行士から信じられない通信が舞い込んでくる。
「窓から目視で確認しているが何かが洩れているのが見える。
あれは多分酸素だ」
ここで船内環境全体をコントロールする責任者に飛行主任が問いかける
「事態を好転させる手段はないか？」
責任者はこう答えた。
「燃料反応炉の１番と３番の酸素弁を閉じよう」
「その効果は？」
「酸素タンクの酸素漏れがどこで起きているかを切り分け（isolate）ることができるよ」
「しかし、酸素弁を閉じると月着陸は諦めざるをえないが？」
「今は生死の問題だよ、月着陸を論じている時ではない」
ここで重要なのは、問題のありそうな部位を切り離すことで問題が起きている場所を特定することができるという考え方だ。
宇宙船はすでに地上から数万キロの彼方まで飛んで行ってしまっている。
誰も故障の部位を肉眼で見ることはできない。
宇宙服を積んでいるんだから飛行士に修理させたらどうかという素人考えがあるが、船外活動に回せる酸素の量は数十時間分、しかも船内の圧力を下げるたびに大量の空気を捨てることになる。
被害の状況がわからない時点で、飛行士に船外活動をさせるなんてあり得ない選択ということになる。
地上からも見えない、飛行士からも見えない、しかも計器盤は訳が分からないデータを吐き続けている…こういう状況ですべきことは、まずどこが故障しているのかを特定すること。
これはトラシューの教科書にしたいくらいの模範解答だ。
もちろんなんとかしないと飛行士の生命が危険な事態であることは、彼らもこの時点で薄々分かっているのだが、いきなり「なんとかしなきゃ！」とでたらめな対策を無意味に連発しても却って事態を悪くするだけだ。
このあとどうなったかというと、切り分け実施後も酸素タンクの圧力下降が止まらなかった。
つまり酸素漏れは燃料電池の酸素弁で起きているのではなく、タンクそのものから洩れていることが判明した。
予想した最悪の事態ということだ。
ここでこの飛行主任のジーン・クランツの有名な台詞が流れる。
「さぁ、みんな冷静になって問題を解決しよう。
当て推量で事態を却って悪くするな。」
トラシュー的にはこの映画から学ぶことができる教訓は多い。
１）冷静になれ（既述）
２）当て推量で何かやる前に切り分けをしろ
他にも
３）数値の読みがはっきりわからない時は、最悪の方を想定しろ
４）何か思いついたら実機を使って実際にやって検証しろ
５）経験則に頼り過ぎずに柔軟に考えろ
ということになるか。
６）最後に本当に施す術が無くなった時は、問題を切り捨てて祈れ
というのもあるのだが…
クルーが撮影した１３号の支援船の写真（Wikipediaより）
トラブルというのは想定外のところで起きるという実例
支援船の燃料電池は酸素タンクも反応炉も配電盤も複数の系統が
用意されていてあらゆる故障に耐えるように設計されていたが
酸素タンクが爆発して支援船の片側が吹っ飛んでしまい
すべての系統が機能しなくなるほどの事故は想定されていなかった
このストーリーにはトラブルシューティングのヒントがたくさん詰まっている
問題が起きた時に何をするか…
やはり原因の特定ということになるのは酸素を消失した宇宙船も、動きがおかしいパソコンも同じだ。
切り分けをしないでいきなり再起動という手も勿論無いわけではない。
多くのパソコンと同じくMacの場合もたいていのトラブルは再起動で治る。
だから「調子が悪くなったらとりあえず再起動」というのはあながち間違ってはいない。
でも、いつもこれでやっていると問題が起きてくる。
ひとつは再起動してしまうと問題の所在がわからなくなってしまうという点。
原因が分からないので、改善されていない。
改善されていないから再発することは当然あり得る。
さらにこういう習慣をつけていると、再起動しても同じ問題が起こった時にパニックになる。
これは実際にあったケース。
「パソコンがフリーズしたようだ」
という。
どこもクリックできない。マウスポインタも動かない。
ポインタが動かない場合は、多くはOSレベルでフリーズが起こっているので、まず再起動ということになる。
ポインタが動かないので、当然電源ボタン長押しで再起動する。
そして起動したら普通は治っている筈だ。
ところがやはりフリーズしている。
普通どのOSでも起動直後はメモリもCPUもリフレッシュされているので、その時点でフリーズが起きるというのはあまり考えられない。
これはロジックボードがやられたか…と騒ぎになった。
ところがマウスを他のものにつなぎ替えたら、あっさり治った。
ここで切り分けのために問題のマウスを他のパソコンに挿してみた。
すると今度はそのパソコンがフリーズしたように操作できなくなった。
これでマウスの故障と特定できたわけだが、もう一段進めて考えるなら、再起動する前にキーボードには反応しているかどうかを確かめるべきだった。
そうすればマウスの単体の故障とまで切り分けができたのに…
切り分けせずにいきなり再起動すると問題がこじれるという一例だった。
さらにこれはひとつの経験則なのだが、
「操作できなくなった」
というトラブルの時のマウス故障、マウス抜けは意外に多いので、心に留めておいた方がよい。
「起動できなくなった」
という時の電源ケーブル抜けも同じように多い。
これも実話。
サポートには
「パソコンが起動できない」
という問い合わせは結構多い。
その時に「電源ケーブルは刺さっていますか？」というチェック項目を伝えるそうだ。
たいてい相手は「素人だと思って馬鹿にするな」という反応をする。
昨日まで動いていたんだから、電源ケーブルなわけないだろ。
すぐに修理にきてくれ…
電源ケーブルはがっちり刺さっていると思う人も多いのだが、ちょっと本体を動かしただけで緩むとか実は多いケースなのだ。
だからサポートもまず「電源ケーブルをお確かめください」というところから入らないといけない。
教訓
動かない時は
マウス故障、電源抜けは常に疑え
こういう事があるから、切り分けは大事。
マウスケーブル、電源ケーブルはチェックする…画面が動かない時はフリーズを疑うだけじゃなく、ハード故障も疑う…マウスの抜き差し、予備マウスのテストなど小さなトラブルで切り分けは大事なのだ。
これはITパスポートとかの試験によく出てくる応用問題の例
このネットワークで端末Aから端末Dまでつながらない
直接AとDをつなぐとつながった場合どういう手順で切り分けをするべきか
答えCはバイパスしているので故障原因に関与している可能性は低い
なのでBを飛ばしてACDとつないでテスト、接続を確認したら
次にABDとつないでテストでBの故障を特定できる
このように切り分けとは故障箇所を想定して
そこを切り離してテストするという手順で行われる
（自慢させてください、一応資格者なもんでw）
４）予感・予兆を軽視するな
トラブルというのは何の予兆もなしに突然起こるということは実は少ない。
「後から考えたらあの時から調子がおかしかったんだなぁ」
という予兆のようなものに気がつくことが多い。
後から考えたら気がつくというのがこの予兆の残念なところで、もし予兆についての経験則が豊富にあればトラブルが発生する前に事前に予防することができる筈だ。
いや、できる筈であってほしい…
実際には相当な熟練者でも予兆にはなかなか事前に気がつかない。
しかし予兆に気がついたら、事が発生したあとに原因の特定・切り分けの判断材料としては大いに役に立つ。
そして予兆というものは実は経験豊富な熟練者でなくても、「後から」ならば経験が浅い人でも気がつくものだ。
例えばこれも非常によくいうジョークなのだが、何かトラブルが発生した時にユーザーに事情を聞くと、
「何もしてないのに壊れた」
ということをいう。
そこでユーザーを責めても仕方が無いから直接本人には言わないが、サポート仲間で
「何もしていないなら壊れない、何かしたから壊れたんだろ？」
というジョークはほぼ共通語のように通じる。
それくらいこの言い訳は世界中のどこでも、少なくとも４７都道府県の津々浦々でされている。
そして、こういう「何もしてないのに壊れた」という本人は、実は何をしたから壊れたのかよく分かっている。
分かっているから「何もしていないのに…」とこちらが聞いてもいないのに一言付け加えたくなるのだ。
本当はトラブルシューティングをスムーズに進めるためには「何もしていないのに…」とか言うんではなく何をしたのかをフランクに話してほしいという時がある。
問題が発生した直前に何をやったかを知っていれば、原因に到達する時間を短縮できる。
ところがこちらが「何をしましたか？」と聞くと
「まるで使い方が悪いと決めつけるような質問をする」
と感じる人もいるようだ。
「こちらが悪いような言い方をするが、余計な事を言っていないでさっさと直せばいいんだ」
というキレ方をする人もいるが、これも１番目の「冷静であれ」という話に通じるのだが、トラブルシューティングをしている方は、ユーザーを責めるために調査しているのではなく原因を特定するために調査しているのだ。
思い当たる節があるのならフランクに話した方が結局お互いにメリットがある筈なのに
「責められている」
という不快感から質問を拒絶する人がいる。
しかし言わせてもらえば「何もしてないのに壊れた」と言う人は
「実は私は原因を知っているかもしれない」と白状しているようなものだ。
そういう人が感じている「故障の予兆」は、実は結構当たっている。
予兆だの予感だの迷信みたいなことを言うな…というのではなく、そういうものを感じたら「後から思えば」というような予兆でもかまわないから思い返すといいと思う。
意外にそういうものが役に立つ。
５）思い込みを排除すべし
トラブルシューティングをする上で経験は大事だ。
やはり場数を踏んでいる人は強い。
過去の経験に照らして、こういう症状はここが原因になっている事が多いという知識が豊富ならばやはり原因の特定は早いし、切り分けの方針も立てやすい。
経験があれば似た事象の特定はスムーズなのだが、経験則に頼り過ぎるとツボにハマることがある。
経験は強い味方なのだが、時に思い込みになって厄介な敵になることもある。
例えばこんなことがあった。
FTPの転送に失敗するケース。
失敗の原因を調べていると
120sec time out
というFTPログが見つかった。
相手はWindowsServerでMicrosoftのIISの設定はデフォルトで１２０秒になっている。
IISを有効にして何も設定を触らないと、普通はタイムアウト値は１２０秒になる。
どういうことかというと転送中の後処理のファイルのリネームとか何かの作業が手間取ったら、１２０秒で
「転送失敗」
とFTPサービスが判断してしまうという設定値だ。
実際には転送に成功していても１２０秒を超えたらその時点で失敗とみなす。
ところが動画ファイルなどの大きめのファイルの転送の場合１２０秒のデフォルト設定は短すぎるのだ。
９００秒の設定を推奨しているサイトも見かけた。
これは非常によくあるトラブルでFTP転送失敗の原因の半分はこれかもしれない。
ところが、これが固定観念になってFTP転送に失敗するとタイムアウト値をのばすというケースがあった。
そしてついにタイムアウト値は８６４００秒までのばされた。
２４時間ということだ。
この場合の問題点はもし本当にFTPのセッションに問題があって転送に失敗している場合でも、２４時間はずっと「転送中」の表示が続いて、転送失敗の表示に変わらないということになる。
これでは逆に実用上問題が出てくる。
このケースの教訓は「経験則に頼り過ぎるな」ということだ。
FTP転送失敗の原因が毎回タイムアウトだから、今回もそうに違いないと決めつけてタイムアウトを６００秒、９００秒、１２００秒…とだんだんのばしていって最後には２４時間になってしまったという笑い話のような、でも笑えない実話だ。
本当は１２００秒あたりまでのばしても転送失敗が続く時点で、他の原因にも思い至らないといけない。
WindowsのFTPdaemonであるIISはデフォルトでは
タイムアウト値は１２０秒にセットされている
いろいろな見解があると思うがこの設定は短すぎると私は思っている
それでコントロールセッション値を９００秒に変更する設定を施している
しかし転送失敗のたびにタイムアウトをのばして
２４時間…まで行く前におかしいと考えないといけない
コンピュータの、少なくとも今のノイマン型コンピュータの基本動作の要件には
「同じ入力に対しては同じ出力を得られる」
というのがある。
つまり平たくいうと、同じ事を何回やっても結果は同じというこだ。
コンピュータに限っていうなら、何回かやって失敗したけど今度はうまくいくかもしれない…というのは普通はあり得ない。
一度失敗したら何度やっても失敗する。
だから失敗したらその要因を探って何らかの条件を変えてやらないと、同じ事を何度やっても事態は好転しない。
ところがFTP転送というのはパソコンが扱うプロトコルの中でも結構いい加減な部分が多く、また外部要因が絡んでくるケースも多いので、一度失敗しても何度かやっているうちに成功するケースもある。
これが経験則になって、サルのようにFTP転送を繰り返したりタイムアウトをのばしたりを繰り返す羽目になる。
コンピュータの動作はしかし、こういうケースを除けばやはり結構確定的で、
ないものはない／あるものはある
一度失敗したものは何度やっても失敗する
という原則で動いている。
よくトラブルシューティングの時に、
「これでできないはずはない、前はこれでうまくいったんだからできる筈だ」
といって顔を真っ赤にしてEnterキーを連打している人を見かけるが、これも「前はうまくいった」という経験則が邪魔している。
失敗したなら失敗する原因がある筈で、その原因を取り除かない限り何度Enterキーを叩いても問題は解決しない。
（除くFTP転送のケースw）
とりあえず、トラブルシューティング十訓のうち前半の５つをまとめた。
後半はまた次回。
2013年8月5日
OS10.8Mountain Lion対応
OS10.6SnowLeopard対応
OS10.7Lion対応
OS10.5Leopard対応
