お名前ドットコムVPSへ移行への道13－バージョンアップ（ubuntu、Dockerイメージなど）

いろいろとバージョンアップしてみた。いつもVsコードでサーバーへ接続していたが、PowerShellで接続したら以下が出た。

58 updates can be applied immediately.（58個のアップデートがあります）
To see these additional updates run: apt list --upgradable

なのでアップデートすることにした。また、Dockerなどもアップデートしてなかったのでいろいろアップデートしてみました。その様子です。

基本的にAI（Gemini、Claude等）に聞いて書いていますが、AIは間違うし私も勘違いしてるかもしれないので、内容に関しては自己責任でご判断、実行してください。

お名前ドットコムVPS（KVM）はデフォルトではUbuntu 20.04サーバーだが、Ubuntu 22.04へアップグレードを去年2025に自分で実施した。以下は、その状況です。

お名前ドットコムVPS（KVM）Ubuntu 20.04サーバーを、Ubuntu 22.04へアップグレードした体験記

この本は、お名前ドットコムVPS（KVM）で運用しているUbuntu 20.04サーバーを、Ubuntu 22.04へアップグレードした実体験に基づいて書きました。結果から言うと、万全のバックアップを準備しましたが、バックアップを使うことな…

zenn.dev

私のサーバーの詳細は

お名前ドットコムVPSへ移行への道

2024/4お名前.comのレンタルサーバーからVPSへ移行したときの記録になります。

kikuichige.com

パッケージリストの更新とアップグレード

Ubuntuにおける sudo apt upgrade は、システムにインストールされている「パッケージ（ソフトウェア）」の更新版をインストールするコマンドです。

何が更新対象になるのか、Dockerとの関係を含めて整理しました。

---

主に何をアップグレードしているのか？

このコマンドは、システムの「パッケージリスト」を元に、現在インストールされているソフトに新しいバージョンがあれば、それをダウンロードして置き換えます。

• OSのコアコンポーネント: Linuxカーネル（システムの心臓部）や、システムライブラリ（libc など）。
• 標準ツール: ls, grep, bash などの基本コマンド。
• インストール済みのアプリ: Python、Git、Webブラウザ、サーバーソフト（Apache/Nginx）など。
• セキュリティパッチ: 脆弱性を修正するための重要なアップデート。

Dockerは含まれるか？

結論から言うと、「どのようにDockerをインストールしたか」によります。
Docker公式サイトの手順に従って、専用のリポジトリ（download.docker.com）をソースリストに追加してインストールした場合は、sudo apt upgrade の対象に含まれます。

sudo apt upgrade を実行すると、勝手に 22.04→24.04 になることはあるのか？

Ubuntuには「パッケージの更新（Upgrade）」と「OSバージョンの更新（Release Upgrade）」という明確な区別があるため勝手に24.04に変わることはありません。

sudo apt upgrade が行うのは、あくまで Ubuntu 22.04（Jammy Jellyfish）という枠組みの中での最新化 です。

• セキュリティパッチの適用: 22.04向けに配布された脆弱性対策。
• アプリの微修正: バグ修正やマイナーなバージョンアップ。
• カーネルの更新: 同じシリーズ内でのカーネルアップデート。

OSのバージョンを 22.04 から 24.04 へアップグレードするには、専用のコマンドsudo do-release-upgradeを実行する必要があります。

サーバーや開発環境として使われるOSにとって、勝手にバージョンが変わることは非常に危険だからです。

• 互換性: 22.04で動いていたソフトが、24.04で動かなくなるリスクがある。
• 設定の変更: システム設定の書き方が変わる可能性がある。

そのため、Ubuntuは「今のバージョンを安全に保つアップデート（apt）」と「次の世代へ進むアップデート（do-release-upgrade）」を厳格に分けています。

---

今回New release ‘24.04.4 LTS’ available.もでているが、22.04のままにする。
Gemini談：メジャーアップデートは、Dockerのネットワーク設定やストレージ周りで稀にトラブルが起きることがあります。今の 22.04 も 2027年までサポートされるので、急いで上げる必要はありません。

何かあってもいいように準備をする必要がありますが、私の場合、以下のメジャーアップ時に準備したので、その点は大丈夫です。以下、参考にしてください。

お名前ドットコムVPS（KVM）Ubuntu 20.04サーバーを、Ubuntu 22.04へアップグレードした体験記

この本は、お名前ドットコムVPS（KVM）で運用しているUbuntu 20.04サーバーを、Ubuntu 22.04へアップグレードした実体験に基づいて書きました。結果から言うと、万全のバックアップを準備しましたが、バックアップを使うことな…

zenn.dev

実際の作業

現時点のスナップショットだけはとっておきます。
お名前.comのサーバーコントロールパネルで
サーバーシャットダウン
ぐるぐる回転が止まるまで待つ→停止中
スナップショットをクイックするとスナップショットがとれました。
起動
シリアルコンソール（コピペはCTRL+shit+v）
login名、パスワード入力

メモリ使いすぎてたらsudo du -h -d 1 / | sort -hで減らせる。（もっと適切なコマンドがあるかもしれないが、私は、これが効く）

sudo docker psでコンテナ動いてるか確認
・waf-nginx（Nginxのコンテナ）は docker-compose.ymlでrestart: alwaysにしてるのに再スタートしない、他のコンテナはrestart: alwaysで立ち上がってる。

システムリスタートで自動で立ち上げるapache2は、Nginxのコンテナを使うので停止
sudo systemctl stop apache2.service
動いてないコンテナ（コンテナ名waf-nginx）を立ち上げる
sudo docker start waf-nginx

現在のカーネルバージョン確認
uname -r
5.15.0-138-generic

更新できるソフトのリストを最新にします。
sudo apt update
実際に実行する前に、以下のコマンドを打つと「何が新しくなるか」のリストを確認できます。（やらなくてもいい）
sudo apt list --upgradable
例えば、このリストの中に docker-ce や docker.io があれば、Dockerもアップグレード対象です。

apt update とapt upgradeの違い

• update: 「新しいバージョンがあるか？」という名簿を更新するだけ。
• upgrade: その名簿を元に、実際の中身を更新する。

apt upgradeとapt dist-upgradeの違い

コマンド	何をするか	特徴
sudo apt upgrade -y	既存パッケージを安全に更新	依存関係が変わる更新はスキップ
sudo apt dist-upgrade -y	依存関係の変更を含む更新を適用	パッケージの追加・削除が発生することがある

セキュリティアップデートを含む既存パッケージを安全に更新
sudo apt upgrade -y
-y は：すべての質問に自動で「Yes」する
変な画面が出たがEnterだけ2回押したら抜けた

依存関係の変更を含む更新を適用
sudo apt dist-upgrade -y

お名前.comサーバーコントロールパネルのシリアルコンソールで
以下の再起動コマンド実行
sudo reboot
途中で止まったように見えたがreturnでlogin待ちになった。

バージョン確認
uname -r
5.15.0-177-generic

このバージョンの情報を得る方法は

1. UbuntuUpdates.org にアクセスします。
2. 右上の検索窓（Search）に 「linux-image-5.15.0-177-generic」 と入力して検索します。
3. 検索結果のversionに5.15.0-177.187と表示されます。

UbuntuUpdates.org の検索結果の5.15.0-177.187をクリックするとさらに詳しく見れます。「Changelog」 という項目があるはずです。そこを読むと、この 「.187」 になる際にどのような脆弱性が修正されたのか（例：CVE-2024-xxxx など）を具体的に知ることができます。

不要なファイルの掃除（仕上げ）
アップデートで不要になった古いファイル（古いカーネルなど）がディスクに残っているので、最後にお掃除
sudo apt autoremove -y

docker-compose

インストールの仕方によってバージョンアップ方法が異なります。
私の場合、Docker Compose のインストールのLinux スタンドアロンライブラリタブでやりました。

# 現状確認
docker-compose –version
Docker Compose version v2.4.1

# 1. 最新バージョンを取得
COMPOSE_VERSION=$(curl -s https://api.github.com/repos/docker/compose/releases/latest \
  | grep '"tag_name"' | cut -d'"' -f4)
echo $COMPOSE_VERSION  # 確認用

# 2. バイナリを上書きダウンロード
sudo curl -SL "https://github.com/docker/compose/releases/download/${COMPOSE_VERSION}/docker-compose-linux-x86_64" \
  -o /usr/local/bin/docker-compose

# 3. 実行権限を付与
sudo chmod +x /usr/local/bin/docker-compose

# 4. バージョン確認
docker-compose version
Docker Compose version v5.1.3

Dockerイメージをアップデート（owasp/modsecurity-crs nginx-alpine）

Dockerイメージをアップデートします。

# 現状確認
sudo docker images --digests | grep modsecurity-crs
2026/5/3実行結果
owasp/modsecurity-crs   nginx-alpine        sha256:c8d794704a7774399835a6bcc480181d5d01e47320171cd36679687e39e6e453   42b87f614319   2 years ago     94.9MB

識別子	例	説明
Image ID	42b87f614319	ローカルでの短縮ID（12桁）。docker images で表示される
Digest	sha256:c8d794...（64桁）	レジストリ上のコンテンツハッシュ。pull元と完全一致を検証できる
Tag	nginx-alpine	人間が読める名前。同じタグでも中身が変わることがある

---

バージョンアップの流れ

1. Docker Hub で最新バージョン番号を確認
      ↓
2. GitHub の CHANGELOG で破壊的変更がないか確認
      ↓
3. docker-compose.yml の image タグを書き換えて pull・up

Docker Hub で確認

👉 https://hub.docker.com/r/owasp/modsecurity-crs/tags

タグ一覧が見られます。sortはnewest、Filter tags（検索ボックス）に nginx-alpine と入力するとフィルタできます。
その結果以下のように表示されます。

TAG 4.25.0-nginx-alpine-202604040104

Last pushed 29 days by fzipi

docker pull owasp/modsecurity-crs:4.25.0-nginx-alpine-202604040104

docker-compose.ymlに
image:owasp/modsecurity-crs:4.25.0-nginx-alpine-202604040104
と書いてpullすると、そのイメージがダウンロードされます。

タグの読み方（:の後ろの部分）
4.25.0-nginx-alpine ← 推奨：バージョン固定
4.25.0-nginx-alpine-202604040104 ← より厳密：月次ビルドまで固定
nginx-alpine ← 現在（常に最新、更新時に意図せず変わるリスクあり）

Digest	OS/ARCH	Compressed size
9eb65d81dee2	linux/386	34.5 MB
4b6626ec481f	linux/amd64	35.72 MB
014a43244067	linux/arm64	35.53 MB

Docker Hub 上の表示について

Docker Hub の Tags ページで表示されているDigest12桁のものをクリックすると
Index digestがみられます。

sha256:a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2
       ←−−−−−−−−−−−−−−−−−− 64文字（256bit） −−−−−−−−−−−−−−−−−−→

この値はsudo docker images –digests | grep modsecurity-crsをサーバーで実行したときに表示されます。
ただし、この値と12桁のDigestの値との関係は不明です。（Geminiに聞くとIndex digestの先頭12桁といいますが、実際は違ってます。）

---

なぜ「Digest」という値が存在するのか？

ここが一番重要なポイントですが、Digestは「中身が絶対に改ざんされていないこと」を証明するデジタル署名のようなものです。

• Tag (nginx-alpine): 誰でも後から付け替え可能な「ラベル」。中身が変わっても名前は同じにできてしまう。
• Digest (sha256:abcd...): 中身のデータから計算された「ハッシュ値」。1文字でも中身が変われば、Digestは全く別の値になります。

12桁のDigest値の利用方法として、同じ値であればタグが違っても同じものを指して思われます。
今回の場合、
owasp/modsecurity-crs:4-nginx-alpine-202604040104
owasp/modsecurity-crs:nginx-alpine
は同じDigest値12桁なのでdocker-compose.ymlに
image:owasp/modsecurity-crs:4-nginx-alpine-202604040104
image:owasp/modsecurity-crs:nginx-alpine 
と書いても同じものがダウンロードされるはず。

Digest番号とTAGや各Digestをクリックすると出る画面の意味は

お名前.com VPSの場合、該当するアーキテクチャ（OS/ARCH）は amd64 です。

---

お名前.com VPSを含む、一般的な日本のクラウド・レンタルサーバーサービスのほとんどは、IntelやAMDのCPU（x86_64規格）を採用した仮想サーバーを提供しています。

• amd64: 64ビットのIntel/AMD CPU用。現在の標準です。
• 386: 32ビットの古いPC用。最近のサーバーで使うことはまずありません。
• arm64: Appleシリコン（M1/M2など）のMacや、AWS Graviton、Raspberry Piなどで使われる規格です。

---

確実を期すために、VPSにログインして以下のコマンドを打ってみてください。

uname -m
結果
x86_64

• 出力が x86_64 と出れば、Docker Hub上の amd64 に対応しています。
  • 注：x86_64 と amd64 は呼び方が違うだけで、実質的に同じものを指します。

実は、docker-compose pull や docker pull を実行する際、あなたが手動で amd64 を選んで指定する必要はありません。

Dockerには「マルチアーキテクチャ・イメージ」という仕組みがあり、コマンドを打ったマシンのOSとCPUを自動で判別して、適切なイメージ（今回なら amd64 版）を勝手にダウンロードしてくれます。

---

• お名前.com VPSなら amd64。
• 設定ファイル（docker-compose.yml）には、今まで通り owasp/modsecurity-crs:nginx-alpine と書くだけでOKです。Dockerが裏側で自動的に VPSに合う amd64 版を拾ってきてくれます。

GitHub Releases で確認

👉 https://github.com/coreruleset/modsecurity-crs-docker/releases

各リリースの変更内容（CHANGELOG）も確認できるので、破壊的変更がないか確認するのにこちらも必須です。

Docker HubのタグとGitHubのRelease情報を結びつけるための「鍵」は 「CRSのバージョン番号」 と 「日付（ビルド日）」 の2つです。

---

1. バージョン番号で結びつける

GitHubのReleaseページ（coreruleset/modsecurity-crs-docker）に
Dependency updates

chore(deps): update dependency coreruleset/coreruleset to v4.25.0 といった表記は、CRS（ルールセット）自体のバージョンを指します。

• GitHub: v4.25.0 というリリースがある
• Docker Hub: タグ名に 4.25.0-nginx-alpine... と含まれている

これが一致していれば、そのリリースのコードを元に作られたイメージである証拠です。

2. 日付（タイムスタンプ）で結びつける

Docker Hubのタグの末尾にある 202604040104 のような数字は、「いつビルドされたか（YYYYMMDDHHMM）」 を表しています。

• GitHubのRelease: 各リリースのタイトルにreleae/20260404といった記載がある。
• Docker Hub: リリース直後にビルドされたイメージには、その日付が刻印されます。

docker-compose.yml の書き換え

今までdocker-compose.ymlに以下のように書いてあるので最新で使ってると思っていたが
image: owasp/modsecurity-crs:nginx-alpine
down して up するだけでは新しいバージョンに更新されないようです。

Dockerの仕組み上、ローカルに一度ダウンロード（Pull）されたイメージがある場合、タグが同じ（この場合はタグなし＝latest扱い）だと、わざわざネット上の最新版を確認しに行かないためです。
# 変更案（バージョン固定）
image: owasp/modsecurity-crs:4.7.0-nginx-alpine

最新バージョンを上記のように調べて書くことを推奨されましたが、今回は、:nginx-alpineのまま変更せず、pullすると最新になるか確認したいと思います。

実際の作業に移る前にClaudeにymlと現在、運用しているimage:を前述のsudo docker images –digests | grep modsecurity-crsで調べ添付して、アドバイスをもらった。

Claudeのアドバイス

環境変数 MODSEC_RULE_ENGINE=on

2年間でこの環境変数名・値が変わっていないか要確認です。

👉 現在の有効な環境変数一覧：ModSecurity ENV Variables
→MODSEC_RULE_ENGINEが、まだ存在することを確認した。

カスタムルール z-custom-rules.conf

CRSのルール体系が変わると、カスタムルール内で参照しているルールIDや変数が競合する可能性があります。→実際のものを添付してClaudeに判断してもらったら問題なしとのこと。

nginx設定 jikken1.conf

nginx本体のバージョンも上がるため、廃止されたディレクティブが使われていると起動失敗します。
→実際のものを添付してClaudeに判断してもらったら、ルールid:777 が重複してた。現状でも問題になるはずのバグだが、ついでに見つかった、777と778に変更した。

---

更新前チェックリスト

# 1. カスタムルールの内容を確認・バックアップ
cat ./modsecurity/z-custom-rules.conf
cp ./modsecurity/z-custom-rules.conf ./modsecurity/z-custom-rules.conf.bak

# 2. nginx設定のバックアップ
cp ./modsecurity/jikken1.conf ./modsecurity/jikken1.conf.bak

# 3. 現在の動作ログを保存（比較用）
sudo docker compose logs waf > waf-before-update.log

---

更新・確認手順

# pull のみ実行（まだ起動しない）
sudo docker compose pull

# 起動
sudo docker compose up -d

# 起動直後のログを即確認（設定エラーはここに出る）
sudo docker compose logs -f サービス名

ログで注意するメッセージ

# 危険：設定ファイルエラー
[error] ... unknown directive ...
nginx: configuration file test failed

# 危険：ModSecurityルールエラー  
ModSecurity: Rules error

# 正常
ModSecurity: status engine is currently enabled
これは出なかったがlibmodsecurity3 version 3.0.14でた。
これはModSecurity本体のバージョンが表示されています。
Docker HubのDigest値をクリックした画面のImage LayersにARG MODSEC3_VERSION=3.0.14という表記があり、そのバージョンと同じであることが確認できる。
よって正常に起動しています。

---

問題が起きた場合のロールバック

sudo docker compose down

# docker-compose.yml を編集
# image: owasp/modsecurity-crs@sha256:c8d794704a7774399835a6bcc480181d5d01e47320171cd36679687e39e6e453

sudo docker compose up -d

---

状況の最終確認

sudo docker images --digests | grep modsecurity-crs
owasp/modsecurity-crs   nginx-alpine ←　新イメージ   sha256:f7ebbff3739ad03cff3062537543129598f94ab304ed19b895e20ddf14e1e1da   28350bddc8ae   4 weeks ago     108MB
owasp/modsecurity-crs   <none>  ←　旧イメージ            sha256:c8d794704a7774399835a6bcc480181d5d01e47320171cd36679687e39e6e453   42b87f614319   2 years ago     94.9MB

旧イメージがタグなし（<none>）になっているのは正常です。新しいイメージが nginx-alpine タグを引き継いだためです。

上の赤線部分がdockerhubのIndex digestと同じであれば成功。
具体的には
dockerhubのhttps://hub.docker.com/r/owasp/modsecurity-crs/tags?name=nginx-alpineの

TAG

nginx-alpine

Last pushed 29 days by fzipi

docker pull owasp/modsecurity-crs:nginx-alpine

Digest	OS/ARCH	Compressed size
9eb65d81dee2	linux/386	34.5 MB
4b6626ec481f	linux/amd64	35.72 MB
014a43244067	linux/arm64	35.53 MB

4b6626ec481f　←　これをクリックして

linux/amd64

開いたページのIndex digest
sha256:f7ebbff3739ad03cff3062537543129598f94ab304ed19b895e20ddf14e1e1da
と同じになります。
更新は正常に完了しています ✅

	旧イメージ	新イメージ
Tag	nginx-alpine	nginx-alpine
Digest	sha256:c8d794...	sha256:f7ebbf...
Image ID	42b87f614319	28350bddc8ae
作成日	2年前	4週間前
サイズ	94.9MB	108MB

---

旧イメージの削除（任意）

動作確認が取れたら削除しても構いません。

# Image IDで削除
sudo docker rmi 42b87f614319

# または一括削除（タグなしイメージをまとめて）
sudo docker image prune -f

---

今後の運用メモ

ロールバックが必要になった場合、旧イメージはすでに削除されるので digest を手元に控えておくと安心です。

# 旧イメージ（2024-02-27）
sha256:c8d794704a7774399835a6bcc480181d5d01e47320171cd36679687e39e6e453

# 現行イメージ（2026年4月頃）
sha256:f7ebbff3739ad03cff3062537543129598f94ab304ed19b895e20ddf14e1e1da

WordPress

WordPressの管理画面での更新とは別にDocker imageの更新が必要です。

現状確認
sudo docker images --digests | grep wordpress
wordpress               php8.3-fpm-alpine   sha256:d55b8e80422970c2df4a7dbef9acddfc4b70ffa249687c448214ecef962ccb6d   4f0121924931   3 months ago    291MB

ローカルにあるそのイメージに対応する Docker Hub 上の最新を確認します。

具体的には、以下の URL で確認できます：

• URL: https://hub.docker.com/_/wordpress/tags
• 対象タグ: php8.3-fpm-alpine

---

最新バージョンを確認

Docker Hub でこのイメージの最新を特定するには、以下の手順が確実です。

1. タグの検索:Docker Hub の WordPress ページ（公式イメージ）にアクセスし、Tags タブを開きます。検索窓に php8.3-fpm-alpine と入力してください。
2. Digest（ダイジェスト）の照合:お手元のターミナルに表示されている sha256:d55b8e80... は、イメージの「指紋」のようなものです。linux/amd64のDigest値をクリックすると、Index digestが確認できます。このダイジェスト値が一致していれば、それが全く同じイメージである証拠になります。

現状確認で「3 months ago」とあり、現在 Docker Hub 上で同じ php8.3-fpm-alpine というタグ名が付いているイメージは、18日前になっている。また、ダイジェスト値も違うので更新が必要なことがわかる。

ダイジェスト値が異なっているということは、Docker Hub側でセキュリティパッチの適用やベースOS（Alpine）の更新が行われ、新しいビルドが公開されていることを意味します。

混乱しやすい「WordPress管理画面での更新」と「Dockerイメージの更新」の違いについて整理します。

---

イメージを更新すべきか？

結論から言うと、定期的な更新を推奨します。

• 理由: 管理画面で更新できるのは「WordPress本体（PHPファイル等）」だけです。しかし、DockerイメージにはPHPエンジン自体や、OS（Alpine）のライブラリが含まれています。
• リスク: ダイジェストが古いまま放置すると、OSやPHPのレイヤーに存在する脆弱性が修正されないまま残ってしまいます。

---

WordPress管理画面での更新と Dockerイメージの関係

これらは「更新している場所」が異なります。

項目	管理画面での更新 (Web UI)	Dockerイメージの更新 (docker pull)
対象	WordPress本体、プラグイン、テーマ	OS(Alpine)、PHP、Webサーバ(fpm)
反映先	Dockerの「ボリューム（永続データ）」	Dockerの「実行環境（レイヤー）」
メリット	手軽に最新機能が使える	脆弱性対策（セキュリティ）と安定性

なぜイメージを更新してもデータが消えないのか

通常、WordPressのDocker運用では、画像や設定ファイル（wp-contentなど）をボリューム（Volumes）としてホスト側に保存しています。

イメージを更新してコンテナを作り直しても、この「データが入った箱」を新しい環境に繋ぎ直すだけなので、中身は維持されます。

---

推奨される手順

管理画面で最新にしている場合でも、以下の流れで実行環境を新しくするのが理想的です。

1. バックアップ: データベースと wp-content をバックアップ。
2. プル: docker compose pull （または docker pull）で最新のイメージを取得。
3. 再起動: docker compose up -d を実行。これで最新の OS/PHP 環境で WordPress が動き出します。

私のシステムの場合
Nginxのコンテナ（コンテナ名waf-nginx）を再起動しないとエラーなる
sudo docker start waf-nginx

確認
sudo docker images --digests | grep wordpress
wordpress               php8.3-fpm-alpine   sha256:5a728781720c2a9e97f38eee10e9fe6ceaae332115ea369684ef6dd7fe5b7792   dfea0abdbbdc   2 weeks ago     291MB
wordpress               <none>              sha256:d55b8e80422970c2df4a7dbef9acddfc4b70ffa249687c448214ecef962ccb6d   4f0121924931   3 months ago    291MB
Digest値（赤文字部分）がDockerHubの最新と同じになりました。

古いイメージを削除する方法
以下のコマンドで、名前のない不要なイメージを一括削除できます。
sudo docker image prune

所感

サーバーで運用している各パーツのバージョンアップ方法をまとめた。まとめて管理できないため、自分で何が更新必要なのか探し出さなければならなかった。バージョンアップはしたほうがいいと思うが、そのせいで動作に不具合が出ないか気を遣うので大変だ。さらに最近はnpmなどのサプライチェーン攻撃の話もよく耳にするし、DockerHubから最新のイメージを落としたとして、それがゼロデイ攻撃を受けたものだったらどうしようと不安になる。セキュリティ対策は大変である。
また、個人的に、この辺をAIエージェント丸投げで本当にまともに動くのか疑問である。結局、うまくいかず余計手間がかかりそうな気はする。無料版のチャットで聞きながらやるのが私は好きです。

イチゲをOFUSEで応援する(御質問でもOKです）Vプリカでのお支払いがおすすめです。
MENTAやってます（ichige）