Cloud SQL for MySQL のよくある質問

MySQL | PostgreSQL | SQL Server

概要
スタートガイド
データストレージ、レプリケーション、認証
バックアップと復元
インスタンスの管理
Insights
- Insights でクエリプランのサンプルが見つからないのはなぜですか？
料金と課金
App Engine での Cloud SQL の使用

概要

Cloud SQL とは？

Cloud SQL は、クラウドでフルマネージドの SQL データベースを提供するサービスです。Cloud SQL では PostgreSQL、SQL Server、MySQL データベースを使用できます。

Cloud SQL を使用するとどのようなメリットがありますか？

Cloud SQL を使用すると、些末ではあっても必要であり時間がかかることが多いタスク（パッチの適用、アップデート、バックアップの管理、レプリケーションの構成など）を Google に任せることができ、ユーザーは優れたアプリケーションの開発に集中できます。さらに、標準のワイヤプロトコルを使用しているため、アプリケーションやロケーションを問わずに接続できます。

Cloud SQL ではどのデータベースバージョンを使用できますか？アップデートはどのように管理されますか？

Cloud SQL for MySQL は MySQL 8.4、8.0（デフォルト）、5.7、5.6 をサポートしています。

マイナーなバージョン更新は定期メンテナンスの一環としてデプロイされるため、ユーザー側で行う必要がある操作はありません。更新の詳細については、Cloud SQL インスタンスでのメンテナンスの概要をご覧ください。

インスタンスの現在のバージョンを確認するには、Google Cloud Console に移動し、インスタンス名をクリックして [インスタンスの詳細] ページを開きます。または、gcloud sql instances describe コマンドを使用することもできます。

Cloud SQL はすべてのデータベース機能をサポートしていますか？

Cloud SQL は MySQL の一般的な機能のほとんどをサポートしています。標準の MySQL と Cloud SQL が提供する機能の違いについては、Cloud SQL と標準 MySQL の機能の違いをご覧ください。

サイズや QPS に制限はありますか？

Cloud SQL インスタンスの秒間クエリ数（QPS）に上限はありません。接続数やサイズの上限と App Engine 固有の上限については、割り当てと上限をご覧ください。

Cloud SQL に変更があった場合、どのようにして通知を受け取ることができますか？

google-cloud-sql-announce フォーラムに登録し、そこに投稿された Cloud SQL に関するお知らせやニュースを受け取ることができます。

バグの報告、機能のリクエスト、質問がある場合はどうすればいいですか？

google-cloud-sql-discuss グループに対してバグの報告や機能のリクエストを行えます。質問は Stack Overflow で行うことができます。その他のサポートオプションについては、Cloud SQL のサポートのページをご覧ください。

トップへ戻る

スタートガイド

インスタンスを管理するのに最適な MySQL ツールは何ですか？

Cloud SQL ではさまざまな MySQL ツールが用意されています。個々のステートメントの実行には MySQL コマンドラインツールを使用できます。より複雑なタスクを行う場合や、より多機能なデータベース開発環境を使用する場合は、Toad for MySQL や MySQL Workbench をお試しください。詳細については、管理ツールとレポート作成ツールをご覧ください。

どのようなストレージエンジンを使用しますか？

MySQL インスタンスの場合、サポートされているストレージエンジンは InnoDB のみです。

すべてのテーブルが MyISAM 形式になっている mysqldump ファイルがある場合は、sed スクリプトでファイルをパイプ処理することにより、InnoDB 形式に変換できます。

mysqldump --databases [DATABASE_NAME] \
-h [INSTANCE_IP] -u [USERNAME] -p [PASSWORD] \
--hex-blob --default-character-set=utf8mb4 | sed 's/ENGINE=MyISAM/ENGINE=InnoDB/g' > [DATABASE_FILE].sql

警告: mysqldump ファイルに mysql スキーマが含まれている場合は、この変換を行わないでください。これらのファイルは、MyISAM のままにする必要があります。

データが存在しない新しいインスタンスに使用ディスク領域が表示されるのはなぜですか？

Cloud SQL とデータベースはどちらも、インスタンスの作成時にシステムファイル用とメタデータ用の領域を使用します。

トップへ戻る

データストレージ、レプリケーション、認証

データはどこに保存されますか？

インスタンスデータは、そのインスタンスが存在するリージョンに保存されます。ストレージロケーションを指定しない場合、バックアップは Cloud SQL インスタンスのロケーションに最も近いマルチリージョンロケーションに保存されます。たとえば、Cloud SQL インスタンスが us-central1 にある場合、デフォルトでは us マルチリージョンにバックアップが保存されます。ただし、australia-southeast1 のようなデフォルトのロケーションはマルチリージョンのいずれにも該当しません。最も近いマルチリージョンは asia です。

ゾーンとは？

ゾーンは、リソースを実行できる、特定の地理的な場所にある独立したエンティティです。たとえば、us-central1-a という名前のゾーンは米国中部のロケーションを示します。

MySQL インスタンスの場合、ゾーン間のフォールトトレラントは、インスタンスの高可用性を構成することで実現できます。すべての本番環境インスタンスで高可用性構成を使用することを強くおすすめします。

ゾーンの詳細については、Compute Engine のドキュメントのゾーンリソースをご覧ください。

ストレージにはどのような制限がありますか？

ストレージの上限については、割り当てと上限をご覧ください。

どのようにデータをレプリケーションしますか？

MySQL インスタンス: MySQL インスタンスでは、高可用性構成と MySQL リードレプリカが提供されます。MySQL リードレプリカは、非同期レプリケーションを使用します。

どのような種類のリードレプリカを作成できますか？

リードレプリカの詳細については（各タイプの用途など）、レプリケーションのオプションをご覧ください。

Cloud SQL のフェイルオーバーはどのように動作しますか？

フェイルオーバーの詳細については、高可用性構成の概要をご覧ください。

データは暗号化されますか？

Cloud SQL 顧客データは、データベーステーブル、一時ファイル、バックアップに保存されるときに暗号化されます。外部接続は、SSL を使用するか、Cloud SQL Auth Proxy を使用して暗号化できます。

保存されているデータの暗号化はどのように管理されますか？

データの暗号化には、256 ビットの Advanced Encryption Standard（AES-256）以上の暗号化方式と対称鍵が使用されます。つまり、データ保存時の暗号化とデータ使用時の復号に同じ鍵が使用されます。これらのデータ鍵はそれ自体が、安全なキーストアに保存されている鍵を使用して暗号化され、定期的に変更されます。

詳しくは、Google Cloud での保存時の暗号化をご覧ください。

転送中のデータの暗号化はどのように管理されますか？

すべての転送中のデータは、Google が管理している物理的境界または Google のために管理されている物理的境界の外へ出るときに、1 つ以上のネットワークレイヤで暗号化され認証されます。これらの物理的境界の内部で転送されるデータについては、認証は通常行われますが、暗号化はデフォルトでは行われない場合があります。パブリック IP アドレスを使用してインスタンスに接続する場合は、SSL / TLS 証明書を使用して、転送中のデータを保護します。そのため、ユーザーの判断で、脅威モデルに基づいて追加のセキュリティ対策を適用できます。たとえば、Cloud SQL へのゾーン内接続に対して SSL を構成できます。

詳しくは、Google Cloud での転送データの暗号化をご覧ください。

インスタンスがリードレプリカであるかどうかはどうすればわかりますか？

Google Cloud コンソールを使用してすべての Cloud SQL インスタンスを表示し、インスタンスがプライマリインスタンスであるか、リードレプリカインスタンスであるかを確認できます。gcloud CLI を使用して、インスタンスがプライマリレプリカとリードレプリカかを確認することもできます。詳細については、レプリケーションステータスの確認をご覧ください。

Cloud SQL では、リードレプリカに対するリクエストのロードバランシングを行いますか？

Cloud SQL では、ロードバランシングの提供や構成を自動的には行いません。接続プールを使用すると、複数の接続エンドポイント間で切り替えを行うことによって、リードレプリカ間で読み取りリクエストを分散できます。

トップへ戻る

バックアップとリカバリ

どのようにすればインスタンスを復元できますか？

バックアップに復元するには、Google Cloud Console か gcloud コマンドラインツールを使用します。詳しくは、インスタンスを復元するをご覧ください。

インスタンスを特定の時点に復元するには、ポイントインタイムリカバリを使用します。詳細については、ポイントインタイムリカバリを使用するをご覧ください。

バックアップにはどのくらいの費用がかかりますか？

バックアップはインスタンスストレージの料金に基づいて課金されます。

インスタンスストレージとインスタンスの料金については、料金をご覧ください。

7 日以上前の自動バックアップにアクセスできますか？

自動バックアップは毎日行われ、デフォルトでは 7 日間保持されます。バックアップ保持期間の値は、1～365 に構成できます。保持期間が終了すると、最も古いバックアップは削除されます。自動バックアップは増分バックアップです。このバックアップには、前回のバックアップの作成後に変更されたデータのみが含まれます。最も古いバックアップはデータベースと同程度のサイズです。最も古いバックアップが削除されると、完全なバックアップを維持するため、その次に古いバックアップのサイズが増加します。

オンデマンドバックアップは手動で削除するまで削除されないことに注意してください。

ポイントインタイムリカバリによってパフォーマンスにはどのような影響がありますか？

Cloud SQL for MySQL でポイントインタイムリカバリを使用するには、バイナリロギングを有効にする必要があります。これはデータベースへのすべての更新が独立したログに書き込まれることを意味し、これによって書き込みパフォーマンスがわずかに低下します。バイナリログファイルのサイズに関係なく、読み取りオペレーションのパフォーマンスはバイナリロギングの影響を受けません。

リージョンの障害保護に対して、外部レプリケーションとクロスリージョンレプリケーションは、それぞれどのような場合に適していますか？

外部レプリケーション	クロスリージョンレプリケーション
お客様による自己管理	Cloud SQL マネージドクロスリージョンレプリカ
Google Cloud 以外のインスタンスと Google Cloud インスタンスの間で複製可能	Cloud SQL インスタンス間でのみ複製可能
Google Cloud に対する移行を行うことで、ダウンタイムの最小化や、ハイブリッド / マルチクラウドデータ保護を行う	Google Cloud のリージョン間でデータを移行してダウンタイムを最小限に抑える
メジャーバージョン間レプリケーションがサポートされている	メジャーバージョン間レプリケーションはサポートされていない

トップへ戻る

インスタンスの管理

Cloud SQL インスタンスを再起動する原因となるアクションはどれですか？

Cloud SQL で次の操作を行うと、Cloud SQL インスタンスが再起動される場合があります。

更新
作成
レプリカのプロモート
メンテナンス
レプリカの再作成
フェイルオーバー
再起動
バックアップからのインスタンスの復元
既存のインスタンスでの高可用性の有効化（インスタンスへの更新）
再起動が必要なデータベースフラグの追加

インスタンスを再起動しても、インスタンスのパブリック IP アドレスやプライベート IP アドレスは変更されません。

再起動時のインスタンスのシャットダウン時間はどの程度ですか？をご覧ください。

再起動時のインスタンスのシャットダウン時間はどの程度ですか？

インスタンスが再起動されると、インスタンスの大部分は 1～2 分間シャットダウンされます。インスタンスがシャットダウンされる前に、すべての接続が終了し、現在の作業はディスクからフラッシュされます。

負荷が大きいインスタンスの場合、このプロセスには時間がかかり、インスタンスが停止しているように見えることがあります。このような場合、インスタンスがシャットダウンして再起動するまで 1 時間ほどかかることがあります。書き込みトランザクションが多数存在する場合や、トランザクションが長時間実行されている場合は、インスタンスのシャットダウンと再起動に時間がかかります。

データベースを拡大または縮小することはできますか？

MySQL インスタンス: ダウンタイムを発生させることなく、いつでもインスタンスで使用できるストレージ容量を増やすことができます。インスタンスのストレージサイズを減らすことはできません。

また、インスタンスの空き容量が残り少ないときに自動的にストレージ容量を増やすように構成することもできます。詳細

vCPU をアップグレードしてダウングレードできますか？

はい。インスタンスで使用する vCPU の数を変更できます。使用するコアの数は必要に応じて増減できます。通常、vCPU 数の変更には 5 分もかかりません。Cloud SQL Enterprise Plus エディションのプライマリインスタンスの vCPU の数を増やす場合は、ダウンタイムはほぼゼロでこの変更が有効になります。

Cloud SQL の管理には Google Cloud コンソールを使用する必要がありますか？

いいえ。Console を使用して実行できるすべての管理タスクは、Cloud SQL Admin API を使用してプログラムで行うことや、gcloud コマンドラインツールを使用したスクリプト化が可能です。

どうすれば削除したテーブルのスペースを再利用できますか？

データベースからテーブルを削除した後に Google Cloud Console で確認したとき、テーブルを削除したことで解放されたはずのスペースが、インスタンスの [ストレージの使用量] に反映されていないことがあります。MySQL 5.5 を実行するインスタンスでは、innodb_file_per_table フラグがデフォルトで OFF に設定されています。このため、InnoDB によってデフォルトのテーブルスペースが縮小されることはありません。この構成でスペースを再利用するには、より小さなデータベースから新しいインスタンスを作成するか、または innodb_file_per_table フラグの値を ON に変更します。データベースフラグの変更については、データベースフラグを構成するをご覧ください。

一時ファイルによって使用されるスペースを再利用するにはどうすればよいですか？

SQL クエリで多数の一時テーブルが作成されると、一時ファイルが大きくなる可能性があります。一時テーブルによって使用されるスペースを再利用するには、データベースを再起動する必要があります。データベースを再起動して一時ファイルが増えても、プロビジョニングされるディスク容量は減少しません。

インスタンスからバイナリログを手動で削除できますか？

バイナリログは保存容量を使用します。バイナリログは、関連する自動バックアップによって自動的に削除されます。これは通常、約 7 日後に発生します。バイナリログを手動で削除することはできません。

バイナリログのサイズが原因でインスタンスに問題が発生した場合は、ストレージサイズを増やすことができます。バイナリロギングを無効にしてから再度有効にして、バイナリログを削除することもできます。ただし、インスタンス用にプロビジョニングされるストレージのサイズは縮小されません。

カスタムバイナリログ保持ポリシーを構成できますか？

バイナリログは、関連する自動バックアップによって自動的に削除されます。これは通常、約 7 日後に発生します。この 7 日間の期間は変更できません。

どうすればデータの変更を追跡できますか？

データの変更を追跡するには、インスタンスのバイナリロギングを有効にします。データの変更を追跡しておくと、誤ってデータが失われたときに元に戻すことができます。DROP DATABASE コマンドによるものなど、偶発的なデータの損失が発生した場合は、データ損失が発生した直前のバイナリログの時点まで復元できます。詳しくは、ポイントインタイムリカバリをご覧ください。

特定のデータベースをインポートまたはエクスポートできますか？

はい。インスタンスの特定のデータベースまたはすべてのデータベースをインポートまたはエクスポートできます。詳細については、データのインポートまたはデータのエクスポートをご覧ください。

CSV ファイルをインポートまたはエクスポートできますか？

MySQL または PostgreSQL の CSV ファイルをインポートまたはエクスポートできます。詳細については、CSV ファイルの作成をご覧ください。

現在、Cloud SQL for SQL Server で CSV はサポートされていません。

インスタンスのデータのインポートまたはエクスポートには Cloud Storage アカウントが必要ですか？

Cloud SQL は、Cloud Storage バケットを使用したデータベース（圧縮または非圧縮の SQL ダンプファイル）および CSV ファイルのインポートとエクスポートをサポートしています。Cloud Storage バケットを使用してインポートまたはエクスポートするには、Google Cloud アカウントを登録してバケットを作成するか、別のアカウントの Cloud Storage バケットにアクセスできる必要があります。詳細については、SQL ダンプファイルを使用したエクスポートとインポートまたは CSV ファイルを使用したエクスポートとインポートをご覧ください。

インポートオペレーションでの ERROR_RDBMS は何を意味しますか？

このエラーは、データインポートのオペレーション中に MySQL がエラーを返した場合に発生します。一般的な原因は、無効な構文、定義されていないデータベースやテーブルの使用、SUPER 権限を必要とする MySQL ステートメントの実行などです。

削除したインスタンスのインスタンス名を再使用できますか？

はい。

cloudsqladmin データベースユーザーとは何ですか？

すべての Cloud SQL インスタンスには cloudsqladmin というデータベースユーザーが存在します。SHOW GRANTS FOR cloudsqladmin@localhost を指定すると、このユーザーに気付くことがあります。一部のインスタンスでは、システムユーザーテーブルにもこのユーザーが表示されます。このユーザーアカウントは、インスタンスのデータにアクセスする必要のある自動プロセス（インスタンスのバックアップや、インポートまたはエクスポートなど）によって使用されます。

GRANT ALL を使用するにはどうすればよいですか？

Cloud SQL は SUPER 権限をサポートしないため、GRANT ALL PRIVILEGES ステートメントは機能しません。代わりの方法として、GRANT ALL ON `%`.* を使用できます。

どうすればインスタンスのトランザクションログにアクセスできますか？

MySQL インスタンスでは、インスタンスのバイナリログを有効にしていて（バイナリロギングを有効にするを参照）、インスタンスの IP アドレスを構成している場合（IP 接続のためのアクセスを構成するを参照）、MySQL の標準の mysqlbinlog ユーティリティを使用してインスタンスのトランザクションログを調べることができます。

Cloud SQL ではどの程度のトランザクション分離が可能ですか？

MySQL インスタンス: Cloud SQL では REPEATABLE READ トランザクション分離が可能です。現行のセッションに対してトランザクションの分離レベルを変更することはできますが、通常はデフォルト値の使用が推奨されます。詳細については、MySQL ドキュメントでトランザクション分離レベルをご覧ください。

インスタンスを誤って削除しないようにするにはどうすればよいですか？

削除保護は、インスタンスの作成時または後で有効にできます。この設定が有効になっている場合は、インスタンスを削除する前に無効にする必要があります。インスタンスの削除を防止するをご覧ください。

トップへ戻る

Insights

Insights でクエリプランのサンプルが見つからないのはなぜですか？: クエリに対するパフォーマンスへの影響があるため、クエリプランを取得するためのサンプルクエリのみを用意しています。その結果、クエリプランのサンプルが表示されない場合があります。

トップへ戻る

料金と課金

Cloud SQL を試すにはどうすればよいですか？: 最小インスタンスは db-f1-micro です。このインスタンスを使用してサービスを試すことができます。共有コアインスタンスは SLA の対象外であるので注意してください。
プロジェクトではインスタンスをいくつ作成できますか？: インスタンスの上限については、割り当てと上限をご覧ください。
どれくらいのサイズのデータベースインスタンスが必要ですか？RAM はどれくらい必要ですか？: 一般に、RAM と CPU が多い大きなインスタンスを選択すると、データベースのパフォーマンスが向上します。これにより、結合、ORDER BY、GROUP などを含む計算量の多い多数のクエリのパフォーマンスが向上します。ただし、単一の行が影響を受ける更新のパフォーマンスはそれほど変わりません。ただし、インスタンスのサイズが大きいほど、処理のレイテンシは大きくなります。インスタンスのサイズと料金の詳細については、料金をご覧ください。
インスタンスの使用時間はどのようにして算出されますか？: MySQL インスタンス: インスタンスがアクティブになっている間（アクティベーションポリシーが ALWAYS に設定されている間）、1 分単位で課金されます。
ストレージはどのようにして算出されますか？: ストレージは、インスタンスに対してプロビジョニングされたストレージの量を基に算出されます。バックアップ用のストレージは、バックアップが使用しているスペースの量によって課金されます。ストレージはインスタンスがアクティブであってもなくても課金されます。
請求額はどこで確認できますか？: Google Cloud Console の [お支払い] タブに、前回の請求書の発行後に発生したインスタンスの課金額が表示されます。
インスタンスが上限サイズに達したらどうなりますか？: プロビジョニングされているストレージサイズにインスタンスが達し、ストレージの自動増量が有効にされていないかまたは構成されている上限に達した場合、ユーザーがストレージサイズを増やすまで、データベースへのそれ以上の書き込みは許可されません。ストレージサイズを増やすためにインスタンスを再起動する必要はなく、ダウンタイムも発生しません。
インスタンスが一時停止しているのはなぜですか？: おそらく Google Cloud アカウントに関する問題が原因です。請求サポートリクエストを提出することで、課金のステータスを確認できます。請求に関する問題を解決してから数時間以内に、インスタンスは実行可能なステータスに戻ります。一時停止された MySQL インスタンスは 90 日後に削除されることに注意してください。
インスタンスが削除されたのはなぜですか？: 90 日間停止されている MySQL インスタンスは削除されます。これは SUSPENDED 状態のインスタンスに適用されます。RUNNABLE 状態で停止しているインスタンスは削除されません。
Cloud SQL アカウントをキャンセルするにはどうすればよいですか？: プロジェクトで Cloud SQL を無効にするには、Google Cloud Console に移動し、プロジェクトを選択してから、[API] サービスを選択して API ダッシュボードを開きます。Cloud SQL API を探し、その API の [無効にする] をクリックします。
課金を無効にするにはどうすればよいですか？: [課金と設定] ペインで、Google Cloud コンソールの [課金を無効にする] をクリックすると、課金を無効にできます。課金を無効にすると、Cloud SQL サービスも無効になります。課金を無効にする前に、Cloud SQL サービスを無効にしてもよいことを確認してください。
課金を無効にすると、課金サイクルの初日からキャンセルした時点までに発生した料金に関する最後の請求が届きます。

注意: 課金を無効にすると、そのプロジェクト内のすべてのサービスの課金が無効になります。個々のサービスや API の課金は無効にできません。詳細については、Google Cloud コンソールのヘルプガイドで [請求の無効化] セクションをご覧ください。

トップへ戻る

App Engine での Cloud SQL の使用

App Engine から MySQL インスタンスに接続できますか？

App Engine アプリケーションがスタンダード環境とフレキシブル環境のどちらで実行されているかにかかわらず、App Engine アプリケーションから MySQL インスタンスに接続できます。詳細については、App Engine スタンダード環境からの接続または App Engine フレキシブル環境からの接続をご覧ください。

米国の App Engine アプリケーションから EU の Cloud SQL インスタンスにアクセスできますか（またはその逆は可能ですか）？

MySQL インスタンスに接続する場合、App Engine アプリケーションは同じリージョンにある必要はなく、スタンダード環境とフレキシブル環境のどちらで実行されていてもかまいません。ただし、Cloud SQL インスタンスと App Engine アプリケーションの距離が大きく離れていると、データベース接続のレイテンシが高くなります。

どの Google Cloud データベースサービスが適していますか？

これはアプリケーションの要件によって異なります。Google Cloud には、データを保存、管理、取得するためのさまざまなオプションが用意されています。詳細については、Google Cloud データベースをご覧ください。

App Engine 開発用サーバーを使用するためにローカルのデータベースサーバーをインストールする必要はありますか？

いいえ。開発用サーバーで実行するときは、App Engine から Cloud SQL とローカルにインストールされたデータベースサーバーのどちらを使用するかを構成できます。

インスタンスにアクセスするにはどの言語を使用する必要がありますか？

App Engine スタンダード環境では、インスタンスへの接続に使用できる複数の言語がサポートされています。詳細については、App Engine スタンダード環境からの接続または App Engine フレキシブル環境からの接続をご覧ください。

App Engine を使用しない場合は、対応するコネクタまたは API が用意されている任意の言語を使用できます。サポートされている言語の一覧については、MySQL リファレンスマニュアルのコネクタと API の章をご覧ください。

Django を Cloud SQL で使用できますか？

はい。Cloud SQL は Django に対応しています。Django スタートガイドをご覧ください。

Python クエリ文字列ではどのプレースホルダを使用できますか？

Python の場合、パラメータの置換に使用できるのは %s 形式のコードだけです。このため、次のステートメントは無効です。cursor.execute('INSERT INTO entries (guestAge) VALUES (%d)', (age))

接続を管理するにはどうすればよいですか？

データベース接続を効果的に管理することは、データベースアプリケーション開発の重要な側面です。効果的な接続管理には、接続プールや指数バックオフの使用が含まれます。これらの手法をさまざまな言語とフレームワークで使用する例については、データベース接続を管理するをご覧ください。

インスタンス接続制限の詳細については、割り当てと制限をご覧ください。

「無効な接続 ID」というメッセージの SQLException の意味は何ですか。

接続がサーバーでオープンではなくなり、クライアントで破棄されることを意味しています。このような接続はすでにクローズされているため、「close」を呼び出す必要はありません。

App Engine の外部からプログラムで Cloud SQL インスタンスにアクセスすることはできますか？

はい。サポートされている任意の言語を使用して、外部アプリケーションからプログラムで Cloud SQL インスタンスにアクセスできます。また、Cloud SQL Java コネクタを使用して接続することもできます（Cloud SQL データベースにアクセスする Apps Script スクリプトを作成することもできます）。接続の概要をご覧ください。

トップへ戻る