Visual Studio 2022で.NET for Androidのレイアウトデザイナーが表示されない原因と対処法まとめ

Visual Studio 2022 で .NET for Android の開発をしていて、「いつの間にか activity_main.xml を開いてもレイアウトデザイナーが出なくなった…」という相談が急増しています。実はこれは環境トラブルではなく、Visual Studio 本体の仕様変更が原因です。本記事では、なぜデザイナーが消えたのか、その上で短期・中期・長期でどのように対応すべきか、そしてレイアウト XML を手書きでレスポンシブ画面を作るコツまで、現場でそのまま使えるレベルで整理します。

.NET for Android のレイアウトデザイナーが表示されない現象とは

具体的な症状

Visual Studio 2022 の .NET for Android プロジェクトで、次のような状態になっていないでしょうか。

activity_main.xml などレイアウト XML を開いても、「デザイン」タブやプレビュー画面が表示されない
右クリックの「デザイナーで表示」メニューがグレーアウト、あるいはクリックしても何も起きない
「スプリット表示」（コード＋デザイン）も利用できない
オプション画面にあった「Android UI Designer」に関する設定が見当たらない

「Windows を入れ直したから？」「.NET for Android のワークロードを入れ忘れた？」と疑いたくなりますが、多くの場合はインストールミスではありません。Visual Studio 2022 側の仕様変更が原因です。

原因：Visual Studio 2022 17.13 以降で Android レイアウトデザイナーが削除された

結論から言うと、Visual Studio 2022 のバージョン 17.13 以降では、.NET for Android のレイアウトデザイナー（Xamarin.Android Designer）が製品から削除されています。Microsoft Q&A でも、17.13 では Android Designer が削除され、レイアウト XML を開いてもデザイナーは表示されず、代わりにコードエディタ／IntelliSense／ツールボックス／プロパティウィンドウ／ドキュメントアウトラインが従来どおり利用できると明記されています。

同じく、Android UI Designer に関する設定項目もオプション画面から取り除かれています。つまり「設定を直せば戻る」タイプの問題ではなく、ビルドイン機能そのものが無くなっている状態です。

GitHub の .NET / Android リポジトリでも、「Android designer has been removed from Visual Studio（Android デザイナーは Visual Studio から削除された）」ことを前提に、関連する内部コードの削除が議論されています。 Reddit や Developer Community でも「VS 2022 17.13 に上げたら XML プレビューが消えた」という報告が相次いでおり、再現性の高い仕様変更であることがわかります。

どのバージョンから影響を受けるのか

ざっくり整理すると、Visual Studio 2022 と .NET for Android レイアウトデザイナーの関係は次のようになります。

Visual Studio 2022 のバージョン	.NET for Android レイアウトデザイナー	想定される運用
17.11.x / 17.12.x	従来どおり利用可能	レイアウトデザイナーが必須ならこの範囲で運用
17.13 以降	削除され、XML エディタのみ	Android Studio のレイアウトエディタ併用などで対応

つまり、「最近 Visual Studio をアップデートしたタイミングで急にデザイナーが消えた」のであれば、ほぼ確実に 17.13 以降に上がったことが原因です。

まずやるべき確認事項

自分の Visual Studio のバージョンを確認する

原因切り分けの第一歩は、Visual Studio のバージョン確認です。

Visual Studio 2022 を起動
メニューから ヘルプ > Visual Studio について を開く
バージョン番号（例：17.13.6, 17.11.22 など）を確認

もし 17.13 以上であれば、「Android デザイナーが出ない」のは不具合ではなく仕様です。逆に 17.11.x / 17.12.x なのにデザイナーが全く出ない場合は、個別のトラブル（インストール破損など）を疑う必要があります。

.NET for Android ワークロードが入っているか確認する

次に、Visual Studio インストーラで .NET for Android 関連のワークロードが入っているか確認しましょう。

スタートメニュー > Visual Studio Installer を起動
対象の Visual Studio 2022 インスタンスの変更をクリック
モバイル開発（.NET Multi-platform App UI） など、.NET for Android を含むワークロードがチェックされているか確認

ワークロードが入っていないと、そもそも Android 開発に必要なツールが足りず、デザイナー以前の問題になります。ただし 17.13 以降では、ワークロードが揃っていてもレイアウトデザイナーは出ません。

短期対応：どうしてもデザイナーを使いたい場合はダウングレード

既存アプリの保守や、チームの開発フローが「レイアウトはデザイナーで作る」前提になっている場合、いきなり「今日から XML 手書きで」と言われても現場は回りません。その場合の現実的な短期対応は、Visual Studio 2022 を 17.12.x / 17.11.x へ戻す（ダウングレードする）ことです。

ダウングレード前に必ずやるべきバックアップ

ダウングレードは IDE 自体の再インストールに近い作業であり、元に戻すのはそこそこ手間です。必ず次のようなバックアップを取っておきましょう。

現在の Visual Studio バージョン番号（スクリーンショット推奨）
インストール済みワークロード構成
- インストーラの画面をキャプチャしておく
- あるいは ワークロードの .vsconfig エクスポート を行う
ユーザー設定（エディタ配色、キーボードショートカットなど）のエクスポート

こうしておけば、「やっぱり最新バージョンに戻す」となったときにも、以前のワークロード構成を再現しやすくなります。

Fixed version bootstrappers から 17.12.x / 17.11.x を入手する

Visual Studio 2022 Professional / Enterprise の場合、Microsoft が提供している「Fixed version bootstrappers」から特定バージョン（17.12.x / 17.11.x など）のインストーラをダウンロードできます。Microsoft Q&A でも、Android デザイナーを使いたい場合の一時的な回避策として、17.12.x または 17.11.x の利用が公式に案内されています。

ダウンロードしたブートストラッパーを実行し、「変更」ではなく対象バージョンへのインストールを選択すると、指定したバージョンに合わせて Visual Studio が再構成されます。

Community 版の場合も、Visual Studio のダウンロードアーカイブから同様に特定バージョンのインストーラを取得できます。運用ポリシー上、企業環境では管理者と相談のうえで実施してください。

インストール後に .NET for Android ワークロードを再確認

ダウングレード後は、もう一度 Visual Studio インストーラを開き、以下を確認します。

.NET for Android を含むワークロードにチェックが入っているか
必要な個別コンポーネント（Android SDK、ビルドツールなど）がインストールされているか

旧バージョンの Visual Studio と新しめの Android SDK / ビルドツールの組み合わせによっては、ビルドエラーや警告が出る場合があります。SDK Manager で使用中の Android API レベルとビルドツールバージョンを確認し、必要に応じて調整しましょう。

ダウングレード運用のメリット・デメリット

観点	メリット	デメリット / リスク
生産性	慣れたレイアウトデザイナーで開発できるため、画面調整のスピードが落ちにくい	VS 自体の新機能（最新のデバッグ、Git 連携など）が使えない
品質・安全性	既存プロジェクトの動作が変わりにくく、移行リスクを避けられる	最新のセキュリティ修正やバグフィックスを取りこぼす可能性がある
チーム運用	全員が同じ旧バージョンを使えば、環境差分トラブルを避けられる	新しく入ってきたメンバーが最新 VS を使えないなど、教育・展開の手間が増える

「今すぐレスポンシブ対応に着手したい」「期限が迫っている」など短期的な事情が強ければ、まずはダウングレードで火消しをしておき、その間に中期的な対応方針（後述）を検討する、という二段構えが現実的です。

中期対応：最新の Visual Studio 17.13 以降で運用する場合

長い目で見れば、Visual Studio を常に古いバージョンに止め続けるのは現実的ではありません。そこで、「IDE の最新バージョンは維持しつつ、レイアウト周りは別ツールで補う」という運用が必要になります。

Android Studio のレイアウトエディタを併用する

もっとも有力な選択肢は、Android Studio のレイアウトエディタを併用する方法です。レイアウト XML のフォーマットは .NET for Android でも基本的に同じため、

Android Studio 側でレイアウト XML をプレビュー＆編集
完成した XML を Visual Studio の .NET for Android プロジェクトへコピー（または共通ディレクトリを経由して同期）

という運用が可能です。

単純に既存 .NET for Android プロジェクトのフォルダを Android Studio で直接開いても、Gradle プロジェクトとして認識されない場合があります。安定運用のためには、「プレビュー専用の Android Studio プロジェクト」を別途作り、その中で共通のレイアウト XML を管理する形が扱いやすいです。

tools: 名前空間でプレビュー専用設定を付ける

Android Studio のレイアウトプレビューを最大限活用するには、tools: 名前空間を覚えておくと便利です。たとえば次のようなレイアウトを考えてみます。

&lt;androidx.constraintlayout.widget.ConstraintLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity"&gt;

    &lt;TextView
        android:id="@+id/titleText"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:textSize="20sp"
        android:textStyle="bold"
        tools:text="サンプルタイトル（プレビュー用）"
        app:layout_constraintTop_toTopOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintHorizontal_bias="0"/&gt;

&lt;/androidx.constraintlayout.widget.ConstraintLayout&gt;

ここでポイントになるのが xmlns:tools と tools:text です。

tools: 名前空間で指定した属性は、実行時には無視され、プレビュー時だけ反映される
tools:text を使えば、実行時にはコードから設定されるテキストの「仮の値」をプレビュー用に指定できる

このようにプレビュー専用の情報をつけておくと、「実際のデータバインディングやロジックがまだ書けていない段階でも、画面のレイアウトをある程度確定させる」ことができます。Android Studio での UI 設計を .NET for Android プロジェクトへ持ち込む際にも、このテクニックは有効です。

Layout Inspector で実行中の画面構造を確認する

見た目を調整したいだけならプレビューで十分ですが、「実行時にどの View がどういう階層になっているか」を分析したい場面もあります。その場合は Android Studio の Layout Inspector（レイアウトインスペクタ）を使うと、アプリ実行中の UI ツリーを 3D 表示で確認できます。

手順の一例は次のとおりです。

.NET for Android アプリを実機またはエミュレータで起動
Android Studio を開き、メニューから View > Tool Windows > Layout Inspector を起動
接続されているデバイスとアプリプロセスを選択

これにより、「ConstraintLayout のどの制約が効いているのか」「重なってタップできなくなっている View はないか」といった問題を視覚的に解析できます。Visual Studio から Android デザイナーがなくなっても、このレベルの UI 解析は Android Studio 側で十分補えます。

ビルド＆デプロイ時間を短縮して「実機確認」を高速化する

レイアウトデザイナーがない環境では、「XML を編集 → ビルド → 実機 / エミュレータで確認」のサイクルをいかに高速に回すかが生産性の鍵になります。次のような対策を検討してみてください。

デバッグビルドから不要な AOT・リンカ設定を外す
- ネイティブ AOT、ProGuard など時間のかかる最適化はリリースビルドだけに限定
可能なら x86_64 / ハードウェアアクセラレーション付きの高速エミュレータを利用
- CPU 仮想化支援（Intel VT-x / AMD-V）を BIOS で有効にする
変更の少ないライブラリを別ソリューションに切り出してビルド対象を減らす
ホットリロード機能を併用しつつ、レイアウト XML の変更を最小限に刻んで確認

デザイナーによる即時プレビューは失われましたが、「ビルドとデプロイのコストを徹底的に下げる」ことで、トータルの開発体験はある程度取り戻せます。

長期的な視点：機能復活を望むならフィードバックを届ける

Android レイアウトデザイナーの削除は、多くの開発者にとってインパクトの大きい変更でした。Microsoft Q&A でも、この件に関する提案スレッド（「Xamarin.Android Designer を残してほしい」という要望）への投票・フォローが案内されています。

長期的には、次のようなアクションを取っておくとよいでしょう。

Visual Studio Developer Community の該当チケットにサインインして Vote する
コメント欄で具体的な影響（プロジェクト規模、チーム人数、開発フローの変化など）を共有する
社内でも「Android デザイナー廃止の影響と現状のワークアラウンド」をまとめ、意思決定層へ共有する

もちろん「投票したからすぐ復活」という話ではありませんが、公式に掲載されている提案・フィードバックは、今後の製品ロードマップを考えるうえで重要なインプットになります。

レスポンシブな Android 画面を XML 手書きで実装するコツ

ここからは、レイアウトデザイナーが使えない前提で、XML 手書きでレスポンシブな画面を作る際の実践的なコツをまとめます。Android Studio を併用する場合にも、基本の考え方は同じです。

ConstraintLayout を前提に設計する

Android のモダンなレイアウトでは、ConstraintLayout をベースにするのが定石です。画面上の各 View に対して、

親や他の View との相対的な位置（Top/Bottom/Start/End）
比率（縦横比、幅と高さの比）
ガイドライン（画面の 30% 位置に線を引いて揃える、など）

を制約として与えることで、異なる解像度や縦横の切り替えに強い UI を構築できます。

Guideline / Barrier / Flow で複雑なレイアウトを整理

Guideline
- 画面の特定位置（例：左から 16dp、幅の 50% など）に仮想的な線を引き、その線に他の View を揃える
- レイアウト XML でマージン値を何度も繰り返さずに済む
Barrier
- 複数の View の端をまとめて「障壁」として扱い、その外側に別の View を配置する
- 可変長テキストの右端に合わせてボタンを配置する…といったケースに便利
Flow
- 複数の View を一列に並べたり折り返したりする「流し込み」コンテナ
- タグの一覧やレスポンシブなボタン群の配置に向いている

これらを組み合わせることで、「画面サイズごとに XML を分けなくてもいい」ケースを増やせます。結果として、保守性が大きく向上します。

画面サイズごとにレイアウトを分ける：リソースクオリファイア

それでもスマホとタブレット、縦画面と横画面では UI 要件が大きく変わることがあります。その場合は、Android のリソースクオリファイアを使ってレイアウト XML 自体を切り替えます。

ディレクトリ名	用途	例
`layout`	デフォルトレイアウト（スマホ縦向きなど）	`res/layout/activity_main.xml`
`layout-land`	横向き用レイアウト	`res/layout-land/activity_main.xml`
`layout-sw600dp`	幅 600dp 以上（主にタブレット）用	`res/layout-sw600dp/activity_main.xml`
`layout-sw720dp-land`	大型タブレット横向き用	`res/layout-sw720dp-land/activity_main.xml`

同じファイル名のレイアウト XML を複数ディレクトリに置くことで、Android が実行時に最適なものを自動選択してくれます。ロジック側は同じ SetContentView(Resource.Layout.activity_main) を呼び出すだけで済むので、コードの分岐は最小限で済みます。

dp / sp / density 別画像を徹底する

レスポンシブ対応というと「ConstraintLayout の制約調整」に意識が行きがちですが、意外と見落とされやすいのが単位の使い方です。

dp（density-independent pixel）：レイアウトの幅・高さ・マージンなど
sp（scale-independent pixel）：テキストサイズ（ユーザーのフォント拡大設定を尊重）

上記を守らず px を直接指定してしまうと、解像度の違うデバイスで表示バランスが大きく崩れます。また画像リソースは、mipmap-xxxhdpi など density 別のディレクトリに分けて配置することで、OS が最適な解像度のものを選択してくれます。

Android Studio プレビューを前提に XML を組む

デザイナーが無くなった環境でも、「Android Studio ではプレビューできる XML」を意識して書くことで、設計と検証の速度を上げられます。具体的には、次のようなポイントを押さえるとよいでしょう。

tools:layout_editor_absoluteX/Y など、プレビュー時だけ必要な属性は tools: 名前空間に閉じ込める
tools:visibility="gone" で、実行時には表示されるがプレビューでは邪魔な View を非表示にする
tools:listitem を使って RecyclerView のプレビュー用行レイアウトを指定する
tools:showIn でフラグメントのプレビュー先アクティビティを指定する

これらはすべて実行時には無視されるため、.NET for Android での実行結果には影響を与えません。一方で、Android Studio 側では UI デザイナーの視点で画面構造を把握しやすくなります。

チェックリスト：いま取るべきアクションを整理

ここまでの内容を、すぐに実践できるチェックリストとしてまとめます。

チェック項目	目的 / コメント
Visual Studio のバージョンを「ヘルプ > バージョン情報」で確認した	17.13 以上ならレイアウトデザイナー削除は仕様と判断できる
レイアウトデザイナーが必須かどうか、チームで合意した	必須なら短期的に 17.12.x / 17.11.x へダウングレードする方針を検討
ダウングレードする場合のバックアップ項目（バージョン、ワークロード構成、ユーザー設定）を洗い出した	再び最新版に戻す可能性も見据えた準備
最新 VS 維持案として、Android Studio のレイアウトエディタ併用運用を試してみた	tools: 名前空間や Layout Inspector の使い方も合わせて検証
ビルド・デプロイ時間短縮のためのデバッグ設定を見直した	AOT、リンカ設定、エミュレータ構成などを最適化
Visual Studio Developer Community の関連チケットに投票・ウォッチした	将来的な機能復活や代替手段の情報を追うため

よくある疑問と現場でのワークフロー例

Q. 既存プロジェクトだけ 17.12.x に残し、新規は 17.13 以降で作るのはアリ？

A. 技術的には可能ですが、同じチーム内で複数バージョンの Visual Studio を併用する運用コストを軽く見積もるべきではありません。特に、

一部メンバーだけ旧バージョンを使う
CI 環境の VS バージョンをどちらに合わせるか
教育資料や社内 Wiki がバージョンごとに分断される

といった問題が起こりやすくなります。どうしても必要な場合は、「プロジェクト単位で VS バージョンを固定する」「CI は安定版のバージョンに統一する」といったルールを明文化しましょう。

Q. XML を全部手書きするのは辛い。最低限のテンプレートはどう作る？

A. おすすめは、「お気に入りレイアウトパターン」を 3〜5 個だけ厳選してテンプレート化する方法です。例としては、

リスト＋詳細画面（マスタ詳細）
ツールバー＋スクロールコンテンツ
フォーム入力画面（バリデーション付き）
1 カラム・2 カラムのレスポンシブ画面（sw600dp 以上で 2 カラム）

これらを XML とスクリーンショット付きで社内 Wiki 化しておくと、「新画面は必ずどれかのテンプレートからスタートする」という文化を作りやすくなります。Android Studio を併用してテンプレートの見た目を微調整しつつ、最終的な XML は .NET for Android プロジェクトで使い回す、という形が現実的です。

Q. 将来的にまたレイアウトデザイナーが復活する可能性は？

A. 現時点では、「削除された機能がそのままの形で復活する」とは言い切れません。ただし、Developer Community や GitHub Issue での議論、そして公式のアナウンスにより、Android UI の設計・プレビュー体験をどう提供していくかは継続的に検討されていると考えられます。

そのため、「いま使えるワークアラウンドを確立しておきつつ、将来のアップデートでより良い UI 設計手段が提供されることを期待する」というスタンスが現実的です。

まとめ：いま取れる現実的な選択肢

最後に、本記事のポイントを整理します。

Visual Studio 2022 17.13 以降では、.NET for Android のレイアウトデザイナーは製品から削除されており、activity_main.xml などを開いてもデザインビューは表示されない
代わりに、コードエディタ／IntelliSense／ツールボックス／プロパティ／ドキュメントアウトラインは従来どおり利用できるが、視覚的なレイアウト編集機能はない
どうしてもデザイナーが必要なら、
- 短期的には Visual Studio 2022 を 17.12.x / 17.11.x へダウングレードする
- ダウングレード前にバージョン・ワークロード構成・ユーザー設定をバックアップしておく
最新バージョンで運用する場合は、
- Android Studio のレイアウトエディタと Layout Inspector を併用し、プレビューや UI 解析を行う
- tools: 名前空間などプレビュー専用属性を活用して設計・検証を効率化する
- ビルド＆デプロイ時間の短縮によって、実機確認のサイクルを高速化する
レスポンシブ実装では、
- ConstraintLayout＋Guideline / Barrier / Flow をベースに、「1 ファイルで対応できる範囲」を広げる
- 画面サイズごとのレイアウトは リソースクオリファイア（layout-sw600dp など）で切り替える
- dp / sp / density 別画像といった基本ルールを徹底する
長期的には、Developer Community の提案や GitHub Issue へフィードバックし、今後のツール改善に期待する

レイアウトデザイナーが突然消えると、最初は戸惑いが大きいですが、「どのバージョンから仕様が変わったのか」「いま自分たちがどの選択肢を取るのか」を整理しておけば、開発自体を止める必要はありません。本記事をたたき台に、自チームに合った運用と UI 設計フローをぜひ検討してみてください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Visual Studio 2022で.NET for Androidのレイアウトデザイナーが表示されない原因と対処法まとめ

.NET for Android のレイアウトデザイナーが表示されない現象とは

具体的な症状

原因：Visual Studio 2022 17.13 以降で Android レイアウトデザイナーが削除された

どのバージョンから影響を受けるのか

まずやるべき確認事項

自分の Visual Studio のバージョンを確認する

.NET for Android ワークロードが入っているか確認する

短期対応：どうしてもデザイナーを使いたい場合はダウングレード

ダウングレード前に必ずやるべきバックアップ

Fixed version bootstrappers から 17.12.x / 17.11.x を入手する

インストール後に .NET for Android ワークロードを再確認

ダウングレード運用のメリット・デメリット

中期対応：最新の Visual Studio 17.13 以降で運用する場合

Android Studio のレイアウトエディタを併用する

おすすめの運用例

tools: 名前空間でプレビュー専用設定を付ける

Layout Inspector で実行中の画面構造を確認する

ビルド＆デプロイ時間を短縮して「実機確認」を高速化する

長期的な視点：機能復活を望むならフィードバックを届ける

レスポンシブな Android 画面を XML 手書きで実装するコツ

ConstraintLayout を前提に設計する

Guideline / Barrier / Flow で複雑なレイアウトを整理

画面サイズごとにレイアウトを分ける：リソースクオリファイア

dp / sp / density 別画像を徹底する

Android Studio プレビューを前提に XML を組む

チェックリスト：いま取るべきアクションを整理

よくある疑問と現場でのワークフロー例

Q. 既存プロジェクトだけ 17.12.x に残し、新規は 17.13 以降で作るのはアリ？

Q. XML を全部手書きするのは辛い。最低限のテンプレートはどう作る？

Q. 将来的にまたレイアウトデザイナーが復活する可能性は？

まとめ：いま取れる現実的な選択肢

この記事を書いた人

コメント

コメントするコメントをキャンセル

Visual Studio 2022で.NET for Androidのレイアウトデザイナーが表示されない原因と対処法まとめ

.NET for Android のレイアウトデザイナーが表示されない現象とは

具体的な症状

原因：Visual Studio 2022 17.13 以降で Android レイアウトデザイナーが削除された

どのバージョンから影響を受けるのか

まずやるべき確認事項

自分の Visual Studio のバージョンを確認する

.NET for Android ワークロードが入っているか確認する

短期対応：どうしてもデザイナーを使いたい場合はダウングレード

ダウングレード前に必ずやるべきバックアップ

Fixed version bootstrappers から 17.12.x / 17.11.x を入手する

インストール後に .NET for Android ワークロードを再確認

ダウングレード運用のメリット・デメリット

中期対応：最新の Visual Studio 17.13 以降で運用する場合

Android Studio のレイアウトエディタを併用する

おすすめの運用例

tools: 名前空間でプレビュー専用設定を付ける

Layout Inspector で実行中の画面構造を確認する

ビルド＆デプロイ時間を短縮して「実機確認」を高速化する

長期的な視点：機能復活を望むならフィードバックを届ける

レスポンシブな Android 画面を XML 手書きで実装するコツ

ConstraintLayout を前提に設計する

Guideline / Barrier / Flow で複雑なレイアウトを整理

画面サイズごとにレイアウトを分ける：リソースクオリファイア

dp / sp / density 別画像を徹底する

Android Studio プレビューを前提に XML を組む

チェックリスト：いま取るべきアクションを整理

よくある疑問と現場でのワークフロー例

Q. 既存プロジェクトだけ 17.12.x に残し、新規は 17.13 以降で作るのはアリ？

Q. XML を全部手書きするのは辛い。最低限のテンプレートはどう作る？

Q. 将来的にまたレイアウトデザイナーが復活する可能性は？

まとめ：いま取れる現実的な選択肢

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル