メッセージストアをトラブルシューティングする

この節では、障害に備えてメッセージストアを保守する際のガイドラインについて説明します。また、メッセージストアが壊れたり、予期せずシャットダウンされた場合に使用する、その他のメッセージストアの回復手順についても説明します。メッセージストア回復の追加手順に関する節は、「メールボックスとメールボックスデータベースの修復」の続きになります。

この節を読む前に、この章のこれまでの部分と、『Sun Java System Messaging Server Administration Reference』のコマンド行ユーティリティーおよび configutil に関する章を再度読まれますよう、強くお勧めします。この節では、以下の項目について説明します。

• 「標準的なメッセージストアの監視手順」

• 「一般的な問題と解決策」

• 「メッセージストアの起動と回復」

• 「メールボックスとメールボックスデータベースの修復」

標準的なメッセージストアの監視手順

ここでは、メッセージストアの監視の標準的な手順の概要を説明します。ここで説明する手順は、メッセージストアの全般的なチェック、テスト、および標準的な保守を行う場合に役立つものです。

その他の情報については、「メッセージストアを監視する」を参照してください。

ハードウェアの容量のチェック

メッセージストアには、十分な追加のディスク容量とハードウェアリソースが必要です。メッセージストアがディスク容量とハードウェア容量の上限に近づくと、メッセージストアに問題が発生することがあります。

ディスクの空き容量の不足は、メールサーバーで発生する問題や故障のうち、特に頻繁におきる原因の 1 つです。メッセージストアへ書き込むとき、そのための容量が不足していると、メールサーバーにエラーが発生します。さらに、利用可能なディスク容量が一定のしきい値より少なくなると、メッセージ配信やログ記録などに関連する多数の問題が発生します。stored プロセスのクリーンアップ機能が失敗し、削除されたメッセージがメッセージストアから消去されていないと、ディスク容量が急激に不足することがあります。

ディスク容量の監視の詳細については、「ディスク容量を監視するには」および 「メッセージストアを監視する」を参照してください。

ログファイルのチェック

ログファイルをチェックして、メッセージストアプロセスが設定どおりに実行されていることを確認します。Messaging Server は、サポートしている主なプロトコルまたはサービス (SMTP、IMAP、POP、および HTTP) ごとに一連のログファイルを作成します。ログファイルはコンソールを使用して表示するか、msg_svr_base/log/ ディレクトリで表示できます。ログファイルは定期的に監視する必要があります。

ログ記録はサーバーパフォーマンスに影響することがあります。より詳細なログ記録を指定するほど、一定期間にログファイルが多くのディスク容量を占有することになります。効果的に定義する必要がありますが、現実的なログローテーション、有効期間、サーバーのバックアップポリシーなどを考慮する必要があります。サーバーのログポリシーの定義の詳細は、第 21 章「ログの管理」を参照してください。

テレメトリを使用してユーザーの IMAP/POP セッションをチェックする

Messaging Server では、テレメトリと呼ばれる機能が提供されており、ユーザーの IMAP、POP、または Web メールのセッション全体をファイルに取得できます。この機能は、クライアント問題をデバッグするのに便利です。たとえば、メッセージアクセスクライアントが期待どおりに機能しないとユーザーが訴えた場合、この機能を使用してアクセスクライアントと Messaging Server 間の対話を記録することができます。

セッションの記録をとるには、次のディレクトリを作成します。

msg_svr_base/data/telemetry/ pop_or_imap/userid

Messaging Server によって、セッションにつき 1 ファイルがそのディレクトリに作成されます。出力例を次に示します。

LOGIN redb 2003/11/26 13:03:21
>0.017>1 OK User logged in
<0.047<2 XSERVERINFO MANAGEACCOUNTURL MANAGELISTSURL MANAGEFILTERSURL
>0.003>* XSERVERINFO MANAGEACCOUNTURL {67}
http://redb@cuisine.blue.planet.com:800/bin/user/admin/bin/enduser 
MANAGELISTSURL NIL MANAGEFILTERSURL NIL
2 OK Completed
<0.046<3 select "INBOX"
>0.236>* FLAGS (\Answered flagged draft deleted \Seen $MDNSent Junk)
* OK [PERMANENTFLAGS (\Answered flag draft deleted \Seen $MDNSent Junk \*)]
* 1538 EXISTS
* 0 RECENT
* OK [UNSEEN 23]
* OK [UIDVALIDITY 1046219200]
* OK [UIDNEXT 1968]
3 OK [READ-WRITE] Completed
<0.045<4 UID fetch 1:* (FLAGS)
>0.117>* 1 FETCH (FLAGS (\Seen) UID 330)
* 2 FETCH (FLAGS (\Seen) UID 331)
* 3 FETCH (FLAGS (\Seen) UID 332)
* 4 FETCH (FLAGS (\Seen) UID 333)
* 5 FETCH (FLAGS (\Seen) UID 334)
<etc>

stored プロセスのチェック

stored 機能は、存続期間決定ポリシーを実行したり、ディスクに保存されているメッセージを消去して、メッセージデータベースのデッドロック操作やトランザクション操作などの、さまざまな重要なタスクを実行します。stored が実行を停止すると、最終的には Messaging Server に問題が発生します。start-msg が実行されているときに stored が起動していないと、ほかのプロセスも起動しません。

• stored プロセスが実行中かどうかをチェックします。stored -t -v を実行します。

• store_root/mboxlist 内に作成されたログファイルをチェックします。

• デフォルトログファイルの msg_svr_base/log/default/default 内の stored メッセージをチェックします。

• stored プロセスによって以下の機能のいずれかが試行された場合は、必ず次のファイル (msg_svr_base/config/ ディレクトリ内) のタイムスタンプが更新されることを確認します。

stored プロセスの詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の 「stored ユーティリティーを使用する」の章を参照してください。

stored 機能の監視の詳細については、「メッセージストアを監視する」を参照してください。

データベースログファイルをチェックする

データベースログファイルは、sleepycat トランザクションのチェックポイントログファイル(store_root/mboxlist ディレクトリ内) を指します。ログファイルが蓄積されると、データベースのチェックポイント設定は行われません。通常は、単一の期間内に、2 つまたは 3 つのデータベースログファイルがあります。ログファイルがそれ以上ある場合は、問題がある可能性があります。

ユーザーフォルダのチェック

ユーザーフォルダをチェックする場合は、以下のコマンドを実行します。reconstruct -r -n (recursive no fix)。これにより、ユーザーフォルダおよびレポートのエラーを確認します。reconstruct コマンドの詳細については、「メールボックスとメールボックスデータベースの修復」を参照してください。

コアファイルのチェック

コアファイルは、プロセスが予期せず終了したときにのみ存在します。コアファイルを確認することは、メッセージストアに問題がありそうなときは特に重要です。Solaris の場合は、coreadm を使用して core ファイルの場所を設定します。

メッセージストアの起動と回復

メッセージストアのデータはメッセージ、インデックスデータ、およびメッセージストアデータベースで構成されています。このデータは堅固ですが、ごくまれにメッセージストアのデータに関する問題がシステムに存在することがあります。このような問題はデフォルトのログファイルに示され、ほとんどの場合は透過的に修正されます。ただし、reconstruct ユーティリティーを実行する必要があることを示すエラーメッセージがログファイルに表示される場合がまれにあります。また、最終手段として、メッセージは 「メッセージストアのバックアップと復元を行う」で説明されているバックアップと復元のプロセスによって保護されます。この節では、stored の自動起動および回復プロセスについて説明します。

メッセージストアでは、以前は管理者の職責であった多くの回復処理が自動化されています。これらの処理はメッセージストアデーモンの stored によって起動時に実行され、必要に応じてデータベーススナップショットおよび自動高速復元が含まれます。stored によってメッセージストアのデータベースが徹底的にチェックされ、問題が検出された場合は自動的に修復されます。

また、stored は、デフォルトのログにステータスメッセージを出力することで、データベースのステータスの総合的な分析を提供し、メッセージストアに行われた修復およびメッセージストアを回復するために行われた自動試行について報告します。

自動起動と自動回復 - 動作方式

stored デーモンは、ほかのメッセージストアプロセスが起動する前に起動します。このデーモンによってメッセージストアデータベースは初期化され、必要に応じて回復処理が行われます。メッセージストアデータベースは、フォルダ、容量制限、購読、およびメッセージフラグの情報を保持します。データベースはログ用とトランザクション用であるので、回復はすでに組み込まれています。また、一部のデータベース情報は、各フォルダのインデックス領域に予備でコピーされています。

データベースは非常に堅固ですが、まれに壊れたとしても、ほとんどの場合は stored によって透過的に回復および修復されます。ただし、stored が再起動された場合は毎回、デフォルトのログファイルをチェックして、ほかに管理操作が必要ないことを確認してください。データベースをさらに修復する必要がある場合は、ログファイルのステータスメッセージで reconstruct を実行するように示されます。

メッセージストアデータベースを開く前に、stored はデータベースの完全性を分析し、ステータスメッセージを warning のカテゴリの下にあるデフォルトログに出力します。メッセージには管理者にとって有用なものも、内部分析に使用されるコード化されたデータで構成されるものもあります。stored によって問題が検出された場合は、データベースの修復が試行され、再起動が試行されます。

データベースが開くと、stored は、ほかのサービスが起動することを合図します。自動修復が失敗した場合、デフォルトログのメッセージで実行するべきアクションが示されます。詳細については、「reconstruct -m が必要であることを示すエラーメッセージ」を参照してください。

以前のリリースでは、stored は非常に長い時間がかかる回復プロセスを開始することがあり、stored が「スタック」したかのように見えることがありました。このタイプの長い回復プロセスは取り除かれ、stored は最終的な状態を 1 分以内に判断するようになりました。ただし、stored がスナップショットからの回復などの回復手段を採用する必要がある場合、プロセスは数分かかる場合があります。

ほとんどの回復プロセスでは通常、終了後のデータベースは最新の状態になっていて、ほかに必要な操作はありません。ただし、一部の回復プロセスでは、reconstruct -m を実行してメッセージストアの冗長データを同期させる必要がある場合もあります。これもデフォルトログに示されます。したがって、起動後にデフォルトログを監視することは重要です。メッセージストアが通常どおり起動し、機能しているように見える場合でも、reconstruct など、要求されている操作がある場合は実行することが重要です。

ログファイルを読むもう 1 つの理由は、データベースに障害を引き起こした原因を確認することです。stored は、システムでの問題の種類にかかわらずメッセージストアを回復するように設計されていますが、データベース障害はより大きな問題が潜んでいることの徴候である可能性があるので、原因を解明することをお勧めします。

reconstruct -m が必要であることを示すエラーメッセージ

ここでは、reconstruct -m の実行が必要なエラーメッセージのタイプについて説明します。

エラーメッセージでメールボックスエラーが示された場合は、reconstruct <mailbox> を実行します。次に例を示します。

"Invalid cache data for msg 102 in mailbox user/joe/INBOX. Needs reconstruct"

"Mailbox corrupted, missing fixed headers: user/joe/INBOX"

"Mailbox corrupted, start_offset beyond EOF: user/joe/INBOX"

エラーメッセージでデータベースエラーが示された場合は、reconstruct -m を実行します。次に例を示します。

"Removing extra database logs. Run reconstruct -m soon after startup to resync redundant data"

"Recovering database from snapshot. Run reconstruct -m soon after startup to resync redundant data"

データベーススナップショット

スナップショットは、データベースのホットバックアップであり、壊れたデータベースを数分で透過的に回復するために stored で使用されます。これは、ほかの領域に保存された冗長情報に依存する reconstruct を使用するよりもはるかに速い方法です。

メッセージストアのデータベーススナップショット - 動作方式

データベースのスナップショット (mboxlist ディレクトリ内) は自動的に作成されます。デフォルトでは、24 時間ごとに作成されます。デフォルトでは、スナップショットは store ディレクトリのサブディレクトリにコピーされます。デフォルトでは、常時 5 つのスナップショットが保存されています。ライブデータベースが 1 つ、スナップショットが 3 つ、データベース / 削除済みコピーが 1 つです。データベース / 削除済みコピーはより新しいものであり、mboxlist データベースディレクトリの removed サブディレクトリに入れられたデータベースの非常時用のコピーです。

現在のデータベースに障害があるために回復プロセスで削除することが決定されると、stored がデータベースを removed ディレクトリに移動します (可能な場合)。したがって、必要に応じてそのデータベースを分析できるようになっています。

データの移動は、1 週間に 1 度だけ実行されます。データベースのコピーがすでに移動先に存在する場合、stored はストアが起動するたびごとにはコピーを置き換えません。removed ディレクトリのデータが 1 週間よりも古い場合にのみ置き換えます。これは、元のデータベースが一連の起動によってあまりにも早く置き換えられないようにするためです。

メッセージストアのデータベーススナップショットの間隔と場所を指定するには

データベースとスナップショットを組み合わせるには、5 倍の容量が必要です。スナップショットが別のディスク上で実行されるように再設定し、システムの要件に合わせることを強くお勧めします。

stored によって起動時にデータベースに関する問題が検出された場合は、最善のスナップショットが自動的に回復します。3 つのスナップショット変数を使用して設定できるパラメータは、次のとおりです。スナップショットファイルの場所、スナップショットの作成間隔、保存されるスナップショットの数。表 18–15 に、これらの configutil パラメータを示します。

スナップショットの間隔が短すぎると、システムに頻繁に負荷がかかるとともに、データベースの問題がスナップショットとしてコピーされる可能性が高くなります。スナップショットの間隔が長すぎると、データベースはスナップショットが作成された過去の時点の状態を維持することになります。

スナップショット間隔は 1 日にすることをお勧めします。1 週間またはそれより長い間隔のスナップショットは、システムで問題が数日間解消されない場合に、問題が存在する前の状態に戻すのに便利です。

stored はデータベースの監視を実行し、データベースが完全でない可能性がある場合は最新のスナップショットを拒否する高度な機能があります。代わりに最新のもっとも信頼性の高いスナップショットを取り出します。1 日前のスナップショットが取り出される可能性があることにもかかわらず、システムはより新しい冗長データがある場合はそのデータを使用して古いスナップショットデータを無効にします。

つまり、スナップショットの根本的な役割は、システムを最新の状態に近づけることと、進行中のデータを再構築しようとするシステムのほかの部分の負担を軽減することです。

メールボックスとメールボックスデータベースの修復

1 つまたは複数のメールボックスが破損した場合、reconstruct ユーティリティーを使用してメールボックスまたはメールボックスデータベースを再構築し、すべての矛盾を修復することができます。

reconstruct ユーティリティーは、1 つまたは複数のメールボックスまたはマスターメールボックスファイルを再構築し、すべての矛盾を修復します。このユーティリティーを使うと、メールストアにおけるほとんどすべてのデータ破損を回復することができます。詳細については、「reconstruct -m が必要であることを示すエラーメッセージ」を参照してください。

表 18–16 に、reconstruct オプションの一覧を示します。構文や使用要件の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「reconstruct」を参照してください。

メールボックスを再構築するには

メールボックスを再構築するには -r オプションを使用します。このオプションは以下の場合に使用します。

• メールボックスにアクセスしたら、「システムI/O エラーが発生しました」または「メールボックスのフォーマットが不正です」のどちらかのエラーが返された場合。

• メールボックスにアクセスしたらサーバーがクラッシュした場合。

• ファイルがスプールディレクトリに追加されたか、スプールディレクトリから削除された場合。

reconstruct -r は、最初に整合性チェックを行います。問題が検出された場合にのみ、すべての整合性を報告し、再構築を行います。したがって、このリリースでは reconstruct ユーティリティーのパフォーマンスが向上しています。

reconstruct は、次の例で説明するように使用することができます。

ユーザー daphne に属するメールボックスのスプール領域を再構築するには、次のコマンドを使用します。

reconstruct -r user/daphne

メールボックスデータベースに一覧表示されたすべてのメールボックスのスプール領域を再構築するには、次のように入力します。

reconstruct -r

ただし、このオプションは注意して使用してください。メールボックスデータベースに一覧表示されたすべてのメールボックスのスプール領域を再構築する場合、メッセージストアが大規模なため非常に長い時間を要する可能性があるからです。(「reconstruct のパフォーマンス」を参照。)これよりも優れた障害復旧に対する手段は、ストア用に複数のディスクを使用することでしょう。ディスクが 1 つダウンしてもストア全体がダウンすることはないからです。ディスクが破損した場合、次のように -p オプションを使用してストアの一部分を再構築するだけですみます。

reconstruct -r -p subpartition

コマンド行の引数にリストされたメールボックスが primary パーティションに存在する場合のみそれらを再構築するには、次のように入力します。

reconstruct -p primary mbox1 mbox2 mbox3

primary パーティションに存在するすべてのメールボックスを再構築する必要がある場合は、以下のようになります。

reconstruct -r -p primary

整合性チェックを実行せずにフォルダを再構築する場合は、-f オプションを使用します。たとえば、次のコマンドはユーザーフォルダ daphne の再構築を実行します。

reconstruct -f -r user/daphne

すべてのメールボックスを修正せずにチェックする場合は、以下のように -n オプションを使用します。

reconstruct -r -n

メールボックスのチェックと修復

高レベルの整合性チェックを行い、メールボックスデータベースを修復するには、次のように入力します。

reconstruct -m

整合性チェックを行い、プライマリパーティションを修復するには次のように入力します。

reconstruct -p primary -m

-p および -m フラグを指定して reconstruct を実行しても、lright.db は修復されません。これは lright.db を修復すると、メッセージストア内のすべてのユーザーに対して ACL のスキャンを実行する必要があるためです。これをすべてのパーティションに対して実行するのは効率的でありません。lright.db を修復するには、reconstruct -l を実行します。

整合性チェックを行い、john という名前のユーザーのメールボックスを修復するには次のように入力します。

reconstruct -p primary -u john -m

-m オプションは以下の場合に使用します。

• 1 つまたは複数のディレクトリがストアスプール領域から削除されたため、メールボックスデータベースのエントリも削除する必要が生じた場合。

• 1 つまたは複数のディレクトリがストアスプール領域に復元されたため、メールボックスデータベースのエントリも追加する必要が生じた場合。

• stored -d オプションによってデータベースの整合性を保つことができない場合。

  stored -d オプションによってデータベースの整合性を保つことができない場合、次の手順を順番に実行します。

  • すべてのサーバーを停止します。

  • store_root/mboxlist 内のすべてのファイルを削除します。

  • サーバープロセスを再起動します。

  • reconstruct -m を実行して、スプール領域の内容から新しいメールボックスデータベースを構築します。

reconstruct のパフォーマンス

reconstruct が処理を実行するのにかかる時間は、次に示すいくつかの要素によって異なります。

• 実行される処理と選択したオプションの種類

• ディスクパフォーマンス

• reconstruct -m 実行時のフォルダの数

• reconstruct -r 実行時のメッセージの数

• メッセージストアの全体サイズ

• システムが実行するほかのプロセスとシステムのビジー状態

• 実行中の POP、IMAP、HTTP、または SMTP アクティビティーが存在するかどうか

reconstruct -r オプションにより、最初の整合性チェックが実行されます。このチェックでは、再構築の必要なフォルダの数に応じて reconstruct のパフォーマンスが向上します。

ユーザー数が約 2400、メッセージストアが 85G バイトで、POP、IMAP、または SMTP アクティビティーが同時にサーバーで実行されているシステムでは、次のパフォーマンスが得られました。

• reconstruct -m に要した時間は約 1 時間

• reconstruct -r -f に要した時間は約 18 時間

reconstruct の操作にかかる時間は、サーバーで POP、IMAP、HTTP、または SMTP アクティビティーが実行されていない場合、大幅に減少します。

一般的な問題と解決策

この節では、以下のようなメッセージストアの一般的な問題と解決策の一覧を示します。

• 「Messenger Express または Communications Express がメールページを読み込まない」

• 「ワイルドカードパターンを使用したコマンドが機能しない」

• 「不明または無効なパーティション」

• 「ユーザーメールボックスディレクトリに関する問題」

Messenger Express または Communications Express がメールページを読み込まない

ユーザーが Messenger Express ページまたは Communications Express メールページを読み込めない場合は、圧縮後にデータが破損している可能性があります。これは、古いプロキシサーバーがシステムに配備されている場合に発生することがあります。この問題を解決するには、local.service.http.gzip.static および local.service.http.gzip.dynamic を 0 に設定して、データ圧縮を無効にしてください。これで問題が解決したら、プロキシサーバーを更新することができます。

ワイルドカードパターンを使用したコマンドが機能しない

UNIX シェルには、ワイルドカードパターンを引用符で囲む必要があるものとその必要のないものがあります。たとえば、C シェルはワイルドカード (*、?) を含む引数をファイルとして展開しようとするため、一致するものがない場合は失敗します。これらのパターンマッチング引数は、mboxutil のようなコマンドに渡すためには引用符で囲む必要があります。

次に例を示します。

mboxutil -l -p user/usr44*

これは Bourne シェルで機能しますが、tsch や C シェルでは失敗します。これらのシェルには次のコマンドが必要です。

mboxutil -l -p "user/usr44*"

ワイルドカードパターンを使用したコマンドが機能しない場合は、そのシェルではワイルドカードを引用符で囲む必要があるかどうかを確認してください。

不明または無効なパーティション

ユーザーのメールボックスが作成したばかりの新しいパーティションに移動され、Messaging Server が更新または再起動されていない場合、Messenger Express で「パーティションが不明または無効です」というメッセージが表示されることがあります。この問題は新しいパーティションでのみ発生します。この新しいパーティションにユーザーメールボックスを新しく追加する場合、Messaging Server の更新または再起動を行う必要はありません。

ユーザーメールボックスディレクトリに関する問題

ユーザーメールボックスに関する問題が発生するのは、メッセージストアの損傷が少数のユーザーに限られていて、システム全体に対する損傷がないときです。ユーザーメールボックスのディレクトリに関する問題を識別、分析、および解決する際は、次のガイドラインを参考にしてください。

1. ログファイル、エラーメッセージ、またはユーザーが見た異常な動作を確認します。

2. デバッグ情報と履歴を保存しておくには、store_root/mboxlist/ ユーザーディレクトリ全体を、メッセージストア外部の別の場所にコピーします。

3. 問題の原因になっている可能性のあるユーザーフォルダを見つけるには、reconstruct -r -n コマンドを実行します。reconstruct を使用しても問題のあるフォルダが見つからない場合は、該当のフォルダが folder.db 内にない可能性があります。

   reconstruct -r -n コマンドを使用してもフォルダが見つからない場合は、hashdir コマンドを使用して場所を確認します。hashdir の詳細については、「hashdir ユーティリティー」および、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の Messaging Server コマンド行ユーティリティーの章の hashdir ユーティリティーを参照してください。

4. ファイルが見つかったら、ファイルを調べ、権限をチェックし、適切なファイルのサイズを確認します。

5. reconstruct -r (-n オプションは付けない) を使用して、メールボックスを再構築します。

6. reconstruct で問題が検出されない場合は、reconstruct -r -f コマンドを使用して、メールフォルダを強制的に再構築することができます。

7. フォルダが mboxlist ディレクトリ (store_root/mboxlist) 内にはなく、partition ディレクトリ (store_root/partition) にある場合は、全体的な矛盾がある可能性があります。この場合は、reconstruct -m コマンドを実行する必要があります。

8. 上記の手順が機能しない場合は、store.idx ファイルを削除してから、再度 reconstruct コマンドを実行してください。

   ---

   注意 –

   問題のあるファイルが reconstruct では見つからないファイルであることがわかっている場合は、store.idx ファイルだけを削除してください。

   ---

9. 原因が問題を起こすメッセージに限られている場合は、メッセージファイルをメッセージストアの外側の別の場所にコピーしてから、mailbox/ ディレクトリ上で reconstruct -r コマンドを実行する必要があります。

10. フォルダがディスク (store_root/partition/ ディレクトリ) 上にあっても、明らかにデータベース (store_root/mboxlist/ ディレクトリ) 内にはないことがわかった場合は、reconstruct -m コマンドを実行してメッセージストアの整合性をチェックします。

reconstruct コマンドの詳細については、「メールボックスとメールボックスデータベースの修復」を参照してください。

store デーモンが起動しない

stored が起動せずに次のエラーメッセージが表示される場合があります。

# msg_svr_base/sbin/start-msg

msg_svr_base: Starting STORE daemon ...Fatal error: Cannot
find group in name service

上記のメッセージは、local.servergid に設定された UNIX グループが見つからないことを示しています。Stored などは、gid をグループに設定する必要があります。local.servergid によって定義されたグループが誤って削除されることがあります。この場合は、削除されたグループを作成し、inetuser をグループに追加し、instance_root の所有権とそのファイルを inetuser とグループに変更します。