カテゴリー
経理

Stripe「残高からの入金を再開するにはご対応が必要です」の直し方|口座名義人名を確認

Stripeから「Stripe 残高からの入金を再開するにはご対応が必要です」というメールが届きました。ダッシュボードを確認すると入金は失敗。原因は、銀行口座設定にある「口座名義人名(カタカナまたはローマ字)」でした。

この項目は入力文字が薄く表示されるため、設定済みだと思い込んで見落としやすいポイントです。本記事では、実際の画面をもとに、Stripeの入金失敗を確認して口座情報を修正する手順を解説します。

結論:口座名義人名を銀行の登録どおりに入力する

今回のエラーは、Stripeに登録した口座名義と銀行側の名義が一致していなかったことが原因でした。次の3点を確認すると解決できます。

  • 「口座名義人名」欄をクリックし、薄く表示された文字も含めて内容を確認する
  • 通帳・銀行アプリ・銀行の登録情報と同じ名義を、カタカナまたはローマ字で入力する
  • 金融機関、支店、口座番号、口座種別もあわせて再確認して保存する

Stripe公式サポートでも、日本円(JPY)の入金用口座には「口座番号」「支店」「口座名義(カタカナまたはローマ字)」「口座の種類」が必要と案内されています。

届いたメールとStripeダッシュボードの状態

メールの件名は「Stripe 残高からの入金を再開するにはご対応が必要です」。メール内のリンクを慌てて開くのではなく、Stripe公式サイトを直接開いてダッシュボードから状況を確認するのが安全です。

入金詳細には「銀行口座名義人の名前に誤りがあるためです」と表示されました。

入金詳細を開くと、タイムラインに「銀行口座名義人の名前に誤りがあるためです。入金の受け取りを継続するには、『設定』で名前を更新してください」と表示されていました。「入金受け取り口座を更新」ボタンから銀行口座設定へ進めます。

Stripeの口座名義を修正する手順

1. Stripeダッシュボードを公式URLから開く

ブラウザからStripeへ直接ログインし、「残高」または「取引」から失敗した入金を開きます。画面構成はアカウントや更新時期によって変わる場合がありますが、失敗した入金の詳細には原因と対応ボタンが表示されます。

2. 「入金受け取り口座を更新」を選ぶ

入金のタイムラインに表示される「入金受け取り口座を更新」を選びます。メニューから進む場合は、入金設定にある銀行口座の編集画面を開きます。

3. 口座名義人名を見落とさず確認する

「口座名義人名(カタカナまたはローマ字)」は薄い表示でも必ずクリックして確認します。

今回もっとも気づきにくかったのが、この口座名義人名の入力欄です。文字が薄く見えるため、プレースホルダーなのか入力済みの値なのかを判断しづらく、確認を飛ばしてしまいました。

入力する名前は、Stripe上の呼び名ではなく、金融機関に登録されている正式な名義に合わせます。表記の違い、法人格の不足、個人名と屋号の取り違えにも注意してください。

4. 金融機関・支店・口座番号を再確認する

口座名義だけでなく、金融機関、支店、口座番号、普通・当座の選択も見直します。Stripe公式サポートによると、日本の銀行口座番号は7桁で入力し、7桁未満の場合は先頭に0を付けます。たとえば6桁の「123456」は「0123456」と入力します。

5. 保存して再試行を待つ

修正内容を保存すると、Stripeは通常、次の入金間隔で入金を再試行します。必ずしも保存直後に着金するわけではありません。入金詳細のタイムラインと登録メールを確認しながら待ちます。

口座名義を入力するときの注意点

個人・個人事業主・法人で名義要件が異なる

Stripeの案内では、個人はアカウント所有者名または屋号、個人事業主は法人名・屋号・代表者名など、法人は正式な法人名または屋号との一致が求められます。日本の法人では、会社名の前後に法人格を表すカタカナ(「カ」など)が必要です。

銀行ごとに登録表記が異なることがあるため、推測で入力せず、通帳や銀行アプリの口座情報を確認してください。

送金中の入金には新しい口座情報が反映されない

銀行口座情報を変更しても、すでに「送金中」または「支払い済み」の入金にはさかのぼって適用されません。変更は今後の入金に反映されます。進行中の入金が旧口座へ送られた場合は、旧口座側の金融機関へ確認が必要になることがあります。

失敗の通知には時間差がある

銀行から資金が返され、Stripeへ失敗が通知されるまで、最大5営業日かかる場合があります。そのため、一度「支払い済み」と表示された入金が後から「失敗」に変わることもあります。

修正してもStripeの入金が再開しない場合

  1. 銀行口座が有効で、凍結や利用制限がないか金融機関に確認する
  2. 口座番号、金融機関コード、支店、口座種別、名義が銀行の記録と完全に一致しているか確認する
  3. Stripeダッシュボードのサポートから問い合わせる

口座所有権の確認を求められた場合は、口座名義と口座番号を確認できる銀行明細書などが必要になることがあります。提出書類の種類は国や事業形態によって異なるため、ダッシュボードに表示された要件を優先してください。

よくある質問

「口座名義人名」はカタカナとローマ字のどちらが正しいですか?

日本円の入金口座ではカタカナまたはローマ字を使用できます。ただし、重要なのは銀行に登録された正式な名義と一致していることです。銀行側の表記をそのまま確認してください。

修正後、失敗した入金は自動で再試行されますか?

Stripe公式ドキュメントでは、口座情報を正しく再入力した後、予定されている次の入金間隔で再試行すると案内されています。入金詳細のステータスで確認してください。

メールのリンクを開いても大丈夫ですか?

フィッシング対策として、メール内リンクからではなく、ブックマークや公式URLからStripeダッシュボードを直接開く方法が安心です。ダッシュボード内に同じ要対応通知があるか確認してから操作しましょう。

まとめ

Stripeの「残高からの入金を再開するにはご対応が必要です」という通知は、銀行口座情報の不一致で届くことがあります。今回は、薄く表示された「口座名義人名」を見落としていたことが原因でした。

口座名義は銀行の登録どおりに入力し、金融機関・支店・7桁の口座番号・口座種別も同時に確認するのが確実です。修正後は入金タイムラインを確認し、解決しない場合は金融機関とStripeサポートへ問い合わせてください。

参考:Stripe公式情報

カテゴリー
Xserver

Xserverのメール設定をmacで簡単に行う方法【.mobileconfigファイル活用】

Xserverからメールアカウントの案内とともに「20260813002603.mail.mobileconfig」のようなファイルを受け取り、どう扱えばよいか迷った方も多いのではないでしょうか。本記事では、このファイルの正体と、macでの具体的なインストール手順をわかりやすく解説します。

結論:これはmacOS用の「構成プロファイル」ファイル

拡張子が「.mobileconfig」のファイルは、macOSやiOSでメールアカウントなどの設定を自動登録するための構成プロファイルです。通常はダブルクリックするだけで「システム設定」からインストールでき、IMAP/SMTPサーバー情報やメールアドレスなどを手動入力する手間を省けます。

なぜXserverでこのファイルが配布されるのか

「.mail.mobileconfig」という名前からもわかる通り、これはメールアカウント専用の設定プロファイルです。理由は以下の通りです。

  • IMAP/SMTPのサーバー情報、ポート番号、暗号化方式などをまとめて登録できる
  • メールアドレスやアカウント名の入力ミスを防げる
  • Xserverメールだけでなく、会社支給のメールやキャリアメールでも同様の方式が使われることがある

つまり、Apple製デバイス向けに「設定を自動で流し込むためのファイル」と理解しておけば十分です。

macでのインストール手順

実際の設定手順は次の通りです。

  1. Finderで対象ファイル(例:20260813002603.mail.mobileconfig)をダブルクリックする
  2. 「プロファイルをダウンロード済み」という通知が表示されることを確認する
  3. macOSの「システム設定」を開く
  4. 「一般」を選択する
  5. 「デバイス管理」(環境によっては「プロファイル」と表記される場合あり)を開く
  6. 該当のメール用プロファイルを選択する
  7. 「インストール」ボタンを押す
  8. Macのログインパスワードを入力し、インストールを完了させる
  9. 標準の「メール」アプリを開き、アカウントが正しく追加されているか確認する

インストール後に確認しておきたいポイント

プロファイルのインストールが完了したら、以下の点をチェックしておくと安心です。

  • メールアプリでアカウントが表示され、送受信ができるか
  • IMAP/SMTPそれぞれの設定が正しく反映されているか(「システム設定」の「インターネットアカウント」からも確認可能)
  • もし正しく反映されない場合は、一度プロファイルを削除してから再インストールする

まとめ

Xserverから配布される「.mail.mobileconfig」ファイルは、macOS向けのメール設定を自動化するための構成プロファイルです。ダブルクリックしてダウンロードした後、システム設定の「一般」→「デバイス管理(プロファイル)」からインストールするだけで、複雑なサーバー設定を手入力せずにメールアカウントを利用開始できます。手順に沿って進めれば数分で設定が完了するので、Xserverメールをmacで使い始める際にはぜひ活用してみてください。

カテゴリー
Claude

Claude Codeでよく使うターミナルコマンド一覧|Git・Linuxコマンドもまとめて解説

Claude Codeを使って開発していると、
「Claude Codeを起動するコマンドは何だった?」
「前回のセッションを続けたい」
「Gitの状態だけ自分で確認したい」
「今いるディレクトリを確認したい」
といった場面が頻繁にあります。
Claude Codeでは、日本語で「現在のGitの状態を確認して」と指示するだけでも操作できます。
ただし、簡単な処理であれば、ターミナルから直接コマンドを入力した方が早い場合もあります。
この記事では、Claude Codeを使った開発で使用頻度の高いコマンドを、以下のカテゴリに分けてまとめます。
Claude CodeのCLIコマンド
Claude Code起動中の「/」コマンド
Gitコマンド
ターミナル・Linux/macOSコマンド
PHP・Composerコマンド
Node.js・npmコマンド
※内容は2026年8月12日時点のClaude Code公式ドキュメントを基準にしています。

Claude Codeのコマンドには大きく2種類ある

最初に覚えておきたいのが、Claude Codeには大きく分けて2種類のコマンドがあることです。

1. ターミナルから実行するコマンド

Bash
claude
Bash
claude -c

Claude Codeを起動したり、前回のセッションを再開したりするときに使用します。

2. Claude Code起動後に入力するコマンド

Bash
/compact
Bash
/status
Bash
/plan

こちらは、Claude Codeを起動した後の画面で使用します。

Claude Codeで特によく使うCLIコマンド

Bash
claude

Claude Codeを起動する基本コマンドです。

Bash
claude

プロジェクトディレクトリへ移動してから実行します。

Bash
cd ~/project/link claude

claude "指示"

Bash
claude "このプロジェクトの構成を確認して"

claude -c

Bash
claude -c

claude -r

Bash
claude -r "セッション名"

claude update

Bash
claude update

claude doctor

Bash
claude doctor

claude --help

Bash
claude --help

Claude Code起動後によく使う「/」コマンド

Bash
/
Bash
/help
Bash
/status
Bash
usage
Bash
compact
Bash
/compact 認証機能の実装内容と残タスクを中心にまとめて
Bash
/context
Bash
/plan
Bash
/plan ログイン機能をPasskey対応するための実装方針を作成して
Bash
/permissions
Bash
/model
Bash
/init

Claude Codeでは全部のコマンドを覚える必要はない

Claude Codeでは自然言語でGit操作や確認を依頼できます。
単純な確認はターミナルから直接実行
調査・設計・実装・テストなど複雑な作業はClaude Codeへ指示
という使い分けが効率的です。

最低限覚えておきたいClaude Codeコマンド

Claude Code

Bash
claude
claude -c
claude --help
claude doctor

Claude Code起動後

Bash
/status
/compact
/context
/plan
/permissions
/model

まとめ

Claude Codeを使う場合、大量のLinuxコマンドやGitコマンドをすべて暗記する必要はありません。
一方、git status、git diff、pwd、claude -cのような簡単なコマンドは、直接実行した方が早いケースがあります。
特にClaude Code独自の/plan、/compact、/context、/permissionsあたりは、覚えておくと開発効率が上がります。
簡単な確認は自分で行い、調査・設計・実装・テストなど複雑な作業はClaude Codeへ任せる。
この使い分けが、Claude Codeを効率良く利用するポイントです。

カテゴリー
生成AI

AIでプログラムを作るときのプロンプト術:削除させない・壊させないコツ

AIにプログラムを書かせると、こちらが頼んでいないのに「整理しました!」「最適化しました!」と、既存コードを大胆に置き換えられることがあります。

結果、互換性が壊れたり、既存メソッドが消えたり、レビューが地獄になったり……。

そこで私は、“壊さない改修” を引き出すための指示を毎回ほぼ同じ型で入れるようにしています。

このメモでは、特に効いた3つのポイントをまとめます。


まず前提:AIは「善意で整理」して壊しがち

AIは、指示が曖昧だと「読みやすい形に整える」方向へ寄りがちです。

でも現実の開発では、読みやすさよりも先に大事なことが多いですよね。

  • 既存の公開APIを壊さない
  • 差分を小さくしてレビュー可能にする
  • 周辺影響を最小化する

この前提を踏まえて、以下の3点を“最初に”固めます。


「削除禁止・互換性維持」を明示する

毎回これを最初に付けるのが効きます。

ポイントは「雰囲気」ではなく、禁止事項を明文化することです。

禁止事項を箇条書きで固定する

例えばこんな感じで、最初に釘を刺します。

  • 既存のメソッド名/シグネチャは削除・変更禁止
  • 必要なら deprecated 扱いで残す
  • 既存ロジックは差分最小(置換ではなく追記・局所修正)

ここまで言うと、AIの“全体最適化欲”をだいぶ抑えられます。

deprecated で残す発想が効く

「消さない」の代わりに「deprecatedで残す」を許可すると、AIは逃げ道を得ます。

逃げ道がないと、勝手に置換したり、別案を出すために削ったりしがちです。

  • 残す(互換維持)
  • ただし将来の削除予定としてマークする(設計意図も守る)

この折衷案が、現場ではかなり実用的です。


出力形式を「diff」か「編集指示」に固定する

次に大事なのが、全文貼り替えをさせないことです。

これができるだけで、事故率が一気に下がります。

全文貼り替えを防ぐのが最重要

AIは気を抜くと、ファイル全体を「完成版」として出してきます。

それをコピペ運用すると、意図しない変更が混ざりやすいです。

そこで出力形式を固定します。

  • 「unified diff で返して」
  • もしくは「変更箇所と追加コードだけ。全文は出さない」

レビューや差分確認の導線ができるので、こちらの精神衛生も守れます。

diff指定が難しい場合の代替

diffが苦手なケース(複数ファイル、口頭ベースの改修など)では、こう言うと安定します。

  • 「変更点の一覧(ファイル名/行/理由)→追加コード→置換対象の最小ブロック、の順で」
  • 「新規関数は丸ごとOK、既存関数は“追記だけ”」

要は、AIに“全文出力の許可”を与えないのがコツです。


“契約(インターフェース)” を先に固定する

互換性を壊す最大の原因は、AIが「どこが外部契約か」を知らないことです。

移行ライブラリや共通モジュールほど、ここが命取りになります。

公開API・例外・ログ・整合性方針を渡す

最低限、これを明文化して渡すと削除が起きにくいです。

  • 公開API一覧(関数/メソッド名、引数、戻り値)
  • 例外仕様(何を投げるか)
  • ログ仕様
  • リトライ/整合性方針(アップロード再開、ETag確認など)

AIは「仕様が書かれていない部分」を勝手に簡略化しやすいので、契約部分だけは先に固定します。

移行・互換系タスクほど先に決める

移行・互換対応は、実装よりも“守るべき約束”が重要です。

この契約を先に渡すと、AIが「触ってはいけない領域」を理解しやすくなります。


そのまま使えるプロンプト雛形(コピペ用)

最後に、上の3点をまとめたコピペ用です。必要に応じて調整して使えます。

  • 前提/制約
    • 既存のメソッド名/シグネチャは削除・変更禁止
    • 変更が必要なら deprecated 扱いで残す
    • 既存ロジックは差分最小(置換ではなく追記・局所修正)
  • 出力形式
    • unified diff で返して(全文貼り替えは禁止)
    • 変更箇所と追加コードだけを提示すること
  • 契約(インターフェース)
    • 公開API:{ここに一覧}
    • 例外仕様:{ここに仕様}
    • ログ仕様:{ここに仕様}
    • リトライ/整合性方針:{ここに方針}
  • 依頼内容
    • {やりたい改修内容を1〜3行で}
    • {受け入れ条件(テスト、互換、パフォーマンスなど)}

まとめ

  • 削除禁止・互換性維持を最初に明示すると事故が減る
  • 出力をdiffか編集指示に固定して全文貼り替えを防ぐ
  • “契約(インターフェース)” を先に固定すると互換が守られやすい
  • 最後はコピペ雛形にして毎回同じ型で投げるのがラク

壊さない改修は、AIの能力というより「こちらの指示の型」で決まることが多いです。

この3点だけでも、かなり安定するはずです。

カテゴリー
WSL システム開発技術

WSL環境をエクスポート・インポートする方法(外付けSSD対応)

この記事で説明すること

WSL(Ubuntu)環境を別ユーザーや別PCへ引き継ぐ場合、

ディストリビューションのエクスポート/インポートが必要になります。

本記事では、以下の作業を順番に解説します。

  • WSLディストリビューションのエクスポート
  • 外付けSSDなどへの保存
  • 別環境へのインポート
  • インポート後のWSL起動確認

WSL環境をインポートした後は、
ユーザー名やホームディレクトリを自分用に変更する必要があります。

その手順については、以下の記事で詳しく解説しています。

👉 WSLでユーザー名・ホームディレクトリを変更する方法


事前準備

外付けSSDについて

WSL環境を保存する外付けSSDは、

NTFS形式でフォーマットしておくことをおすすめします。

理由は以下の通りです。

  • Windowsとの互換性が高い
  • 大容量ファイル(.tar)を扱える
  • 権限トラブルが起きにくい

使用するShell

本記事のコマンドは、Windows標準の PowerShell を使用します。

WSL(Bash)ではありませんので注意してください。


WSLディストリビューションをエクスポートする

まずは、現在のWSL環境を .tar ファイルとしてエクスポートします。

以下は、

  • エクスポート先ディレクトリが存在しなければ作成
  • Ubuntuディストリビューションをエクスポート

を 一括で実行する PowerShell コマンドです。

PowerShell
$exportDir = "D:\wsl"

if (!(Test-Path $exportDir)) {
    New-Item -ItemType Directory -Path $exportDir
}

wsl --export Ubuntu "$exportDir\ubuntu.tar"
  • Ubuntu:ディストリビューション名
  • D:\wsl\ubuntu.tar:エクスポート先ファイル

ディストリビューション名は、環境によって

Ubuntu-20.04 などになっている場合があります。


WSLディストリビューションをインポートする

次に、エクスポートした .tar ファイルを別環境へインポートします。

PowerShell
wsl --import Ubuntu "D:\wsl\ubuntu" "D:\wsl\ubuntu.tar"
  • 第1引数:新しく登録するディストリビューション名
  • 第2引数:WSLのインストール先ディレクトリ
  • 第3引数:エクスポートした .tar ファイル

これにより、指定した場所にWSL環境が展開されます。


インポートしたWSLへログインする

インポートが完了したら、以下のコマンドでWSLを起動します。

PowerShell
wsl -d Ubuntu

Ubuntuのターミナル(Bash)が起動すれば成功です。


作業時の注意点

  • エクスポート中は対象のWSLを起動しない
  • .tar ファイルはサイズが大きくなる場合がある
  • 同名のディストリビューションが既に存在する場合は注意

既存のWSLを削除する場合は、事前にバックアップを取っておくと安心です。


WSL環境をインポートした後は、
ユーザー名やホームディレクトリを自分用に変更する必要があります。

その手順については、以下の記事で詳しく解説しています。

👉 WSLでユーザー名・ホームディレクトリを変更する方法


まとめ

  • WSL環境は wsl –export でバックアップできる
  • 外付けSSDを使えば環境の受け渡しが簡単
  • wsl –import で別環境へそのまま復元可能
  • ユーザー変更などの作業は、インポート後に行う

WSL環境を作り直す手間を省きたい場合に、

とても便利な方法です。

カテゴリー
WSL システム開発技術

別ユーザーのWSL環境を流用してローカル開発環境を構築する手順

事前準備:WSL環境のエクスポート・インポートについて

本記事では、すでにWSL(Ubuntu)環境をローカルに取り込んでいる前提で説明しています。

別ユーザーの環境を引き継ぐ場合は、事前に以下の作業が必要です。

・WSLディストリビューションのエクスポート
・別環境へのインポート(外付けSSDなど)

これらの手順については、以下の記事で詳しく解説しています。

👉 WSL環境をエクスポート・インポートする方法(外付けSSD対応)

今回やりたかったこと

別ユーザーが使用していた WSL(Ubuntu)環境のファイルをもとに、

自分のローカル開発環境を作成する必要がありました。

新しく作り直すのではなく、

  • 既存のWSL環境を流用したい
  • ユーザー名とホームディレクトリを自分用に変更したい

というケースです。

その際に行った手順を、備忘録としてまとめています。

以降の bash コマンドは、WSL上のUbuntu(Bash)内で実行します。

PowerShellでは実行できないため注意してください。


rootユーザーで一時的にログインする

まずは rootユーザーでWSLにログインできるようにします。

これはユーザー情報を変更するために必要です。

PowerShellを 管理者権限で起動し、以下を実行します。

PowerShell
wsl -d Ubuntu -u root

※ Ubuntu の部分は、利用しているディストリビューション名に合わせてください。

rootでログインできたら、usermod コマンドが使用可能か確認します。

Bash
/usr/sbin/usermod --help

ヘルプが表示されれば問題ありません。


ユーザー名とホームディレクトリを変更する

ここからは WSL(Bash)側での作業になります。

ユーザー名(ログイン名)の変更

既存ユーザー名を、新しいユーザー名に変更します。

Bash
/usr/sbin/usermod -l new_user old_user
  • old_user:変更前のユーザー名
  • new_user:変更後のユーザー名

ホームディレクトリの変更とデータ移動

次に、ホームディレクトリを変更します。

-m オプションを付けることで、既存データも一緒に移動されます。

Bash
/usr/sbin/usermod -d /home/new_user -m new_user

グループ名の変更

通常、ユーザー名と同じ名前のグループが作成されています。

ユーザー名変更後は、グループ名も合わせて変更します。

Bash
/usr/sbin/groupmod -n new_user old_user

デフォルトユーザーを新しいユーザーに戻す

最後に、WSL起動時の デフォルトユーザーを新しいユーザーに設定します。

再び PowerShell で実行します。

PowerShell
<ディストリビューション名> config --default-user new_user


例:Ubuntu の場合

PowerShell
ubuntu config --default-user tarou

これで、通常起動時に新しいユーザーでログインされるようになります。


Git を利用している場合の注意点

WSL環境に Git が設定されている場合は、

ユーザー名を変更しただけでは不十分で、

Git のユーザー情報も合わせて変更する必要があります。

Git は以下の情報を ~/.gitconfig に保持しているためです。

  • ユーザー名(user.name)
  • メールアドレス(user.email)

これらが以前のユーザー情報のままだと、

  • コミットの作成者が旧ユーザー名のままになる
  • 別アカウントとして履歴が残る

といった問題が起こります。

Git のユーザー名・メールアドレスを変更する

WSL(Ubuntu / Bash)上で、以下を実行します。

Bash
git config --global user.name "新しいユーザー名"
git config --global user.email "new-email@example.com"

環境再構築の手間を減らしたいときに便利な手順です。
設定内容は、次のコマンドで確認できます。

Bash
git config --global --list

補足

  • プロジェクトごとに設定している場合は –global を外して、リポジトリ単位で確認してください
  • SSHキーやGPG署名を使っている場合は、 それらの設定も併せて確認すると安心です

作業時の注意点

  • ユーザー名変更中は 対象ユーザーでログインしない
  • 念のため、事前にWSLディレクトリのバックアップを取っておく
  • ディストリビューション名(Ubuntu / Ubuntu-20.04 など)に注意する

まとめ

  • rootログインでユーザー情報を変更する
  • usermod でユーザー名・ホームディレクトリを調整
  • groupmod でグループ名も忘れずに変更
  • 最後にデフォルトユーザーを設定し直す

既存のWSL環境をそのまま活かせるので、

カテゴリー
Docker

【Docker】よく使うコマンド

Dockerを使っていると、「毎回どのコマンドを打つんだっけ?」となることはよくあります。
特に開発環境では、起動・停止・確認といった基本操作を何度も繰り返します。

また、コンテナやDocker Desktopがフリーズしてしまい、どう対処すればいいか分からなくなる場面も少なくありません。

この記事では、
Dockerでよく使う基本コマンドと、
フリーズ時に使える強制終了コマンド、
さらに Mac / Windows(PowerShell・cmd)での実行環境の違い をまとめて整理します。

Dockerでよく使われる基本コマンド

まずは、日常的によく使うDockerコマンドからです。

サービス起動

Bash
sudo systemctl start docker
Bash
sudo systemctl stop docker

コンテナの起動・停止・確認

Bash
docker ps

起動中のコンテナ一覧を表示します

-a を付けると停止中も含めて表示できます

Bash
docker ps -a

Dockerコンテナ一覧を指定した項目だけ、表形式で表示します

Bash
docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Status}}\t{{.Ports}}"

停止中のコンテナを起動します

Bash
docker start コンテナ名(またはID)

実行中のコンテナを停止します

Bash
docker stop コンテナ名(またはID)

コンテナを再起動したいときに使います

Bash
docker restart コンテナ名

コンテナのログを確認できます

Bash
docker logs コンテナ名

トラブルシュート時によく使います

イメージ関連のコマンド

Bash
docker images

ローカルに存在するDockerイメージ一覧を表示します

Bash
docker pull イメージ名

Docker Hubなどからイメージを取得します

Bash
docker rmi イメージ名
  • 不要になったイメージを削除します

docker-composeでよく使うコマンド

複数コンテナを扱う場合は、docker-compose を使うことが多いです。

Bash
docker-compose up

コンテナを起動します

-d を付けるとバックグラウンド実行になります

Bash
docker-compose up -d
Bash
docker-compose down

コンテナ・ネットワークを停止・削除します

Bash
docker-compose ps
  • composeで管理しているコンテナの状態を確認します

Dockerがフリーズした時に使う強制終了コマンド

Dockerを使っていると、稀にコンテナが停止できなくなることがあります。

コンテナ単体を強制停止する

Bash
docker kill コンテナ名

通常の docker stop が効かない場合に使います
即座にコンテナを停止します

Bash
docker rm -f コンテナ名
  • コンテナを強制的に削除します
  • 停止+削除を一気に行いたいときに便利です

Docker自体が応答しない場合の対処

  • Docker Desktopを再起動
  • それでもダメな場合はPC自体を再起動

Docker Desktopが固まっている場合、コマンドが一切通らないこともあります。
その場合は無理に操作せず、アプリ側の再起動が安全です。

  • コンテナを強制的に削除します
  • 停止+削除を一気に行いたいときに便利です

WindowsのPowerShellで実行するDockerコマンド

Windowsでは、PowerShell からDockerコマンドを実行するのが一般的です。

Bash
docker ps
docker-compose down
  • Macと同じコマンドが使えます
  • PowerShellでも特に違和感はありません

cmd(コマンドプロンプト)でも使える?

結論から言うと、cmdでもDockerコマンドは使えます。

Bash
docker ps

ただし、

  • PowerShellの方が表示が見やすい
  • スクリプトやパイプ処理がしやすい

といった理由から、現在は PowerShell推奨 で使われることが多いです。

特別な理由がなければ、PowerShellを使っておくのが無難です。

カテゴリー
WSL

WSL2・Dockerで容量が逼迫したときのクリーンアップ方法【VHDX最適化】

SSD256GB環境で発生した深刻な容量不足

今回のトラブルが深刻だった理由は、
SSD256GBという比較的容量の小さい環境でWSL2+Dockerを運用していた点です。

ディスクが逼迫した結果、

  • WSLが頻繁にクラッシュする
  • 開発用コンテナが起動しない
  • Windows Updateが容量不足で失敗する
  • セキュリティソフトの定義ファイル更新すら行えない

という、Windows全体の運用に支障が出る状態に陥っていました。


今回のWSLクラッシュの原因

原因は複合的でした。

  • メモリ16GB環境でのメモリ不足
  • WSL2・Dockerが使用するVHDXファイルの肥大化
  • EC-CUBEエンタープライズ版特有の環境設定による負荷増大の可能性

特にVHDXの肥大化は気づきにくく、
SSD256GB環境では致命的になりやすいと感じました。


VHDX肥大化を解消する全体の流れ

今回行ったクリーンアップは、次の3ステップです。

  1. Windows側の一時ファイル削除
  2. WSL/Docker内部の不要データ削除
  3. WSLを完全停止し、VHDXを物理的に最適化(圧縮)

手順① 一時ファイル(Temp)の削除

対象パス

PowerShell
C:\Users\[USER_NAME]\AppData\Local\Temp

DockerやWSL関連アプリを終了した状態で、
Windowsの「記憶域」設定から削除します。


手順② 仮想ディスク内部のクリーンアップ

Dockerを起動

Bash
sudo systemctl start docker

ゾンビファイルの削除

空き領域を「e」で埋め尽くす一時ファイルを作成:不要データが大きいと数十分かかります。メモリも圧迫されるので実行タイミングは業務終了前などご検討ください。

Bash
sudo dd if=/dev/zero of=/var/tmp/zero.fill bs=1M status=progress

作成した一時ファイルを削除

Bash
sudo rm /var/tmp/zero.fill

Docker(docker_data.vhdx)

Bash
docker system prune -a --volumes

未使用のコンテナ・イメージ・ボリュームを削除します。


WSL2(ext4.vhdx)

Bash
sudo apt autoremove -y && sudo apt Clean

不要なパッケージとキャッシュを削除し、
VHDX内部に空き領域を作ります。

Docker停止

Bash
sudo systemctl stop docker

手順③ DockerとWSL完全停止とVHDXの最適化

管理者権限のPowerShellで以下を実行します。

PowerShell
# Docker Desktopの主要プロセスを強制終了
Stop-Process -Name "Docker Desktop" -Force -ErrorAction SilentlyContinue
Stop-Process -Name "com.docker.backend" -Force -ErrorAction SilentlyContinue
Stop-Process -Name "com.docker.service" -Force -ErrorAction SilentlyContinue
PowerShell
wsl --shutdown

停止確認:

PowerShell
wsl --list --running

注意点
wsl --shutdown を実行する際、VS Code などで WSL 内のディレクトリを開いたままにしていると、WSL が自動的に再起動されてしまいます。

VHDX の最適化を確実に行うためには、

  • VS Code(Remote – WSL 接続)
  • WSL を参照しているターミナルやエクスプローラー

これらをすべて閉じた状態で wsl --shutdown を実行する必要があります。VScodeなどでWLS内のディレクトリを開いている場合は、wslが再起動されるので閉じる必要がある。

DockerのVHDXを圧縮する場合

PowerShell
Optimize-VHD -Path "C:\Users\[USER_NAME]\AppData\Local\Docker\wsl\disk\docker_data.vhdx" -Mode Full

WSL2のVHDXを圧縮する場合

PowerShell
Optimize-VHD -Path "C:\Users\[USER_NAME]\AppData\Local\Packages\<ディストリ名>\LocalState\ext4.vhdx" -Mode Full

大容量ファイルの洗い出し

以下のディレクトリへ移動します。

PowerShell
cd C:\Users\[USER_NAME]\AppData\

5GB以上のファイルを一覧表示します。

PowerShell
Get-ChildItem -Recurse -File |
Where-Object { $_.Length -gt 5GB } |
Select-Object FullName, LastWriteTime,
@{N='Size(GB)';E={[math]::Round($_.Length / 1GB, 2)}} |
Sort-Object 'Size(GB)' -Descending |
Format-Table -AutoSize

定期メンテナンスの重要性

今回の対応で、
SSD256GB環境でも実用レベルまで復旧できました。

ただし、DockerとWSLを使い続ける限り、
VHDXは再び肥大化します。

  • 月1回のDockerクリーン
  • WSL完全停止+VHDX最適化

この2点は、
SSD容量が小さい環境ほど必須だと感じました。


まとめ

  • ゾンビファイルの削除が一番有用かもしれません。
  • WSL2のVHDXは117GBまで肥大化していた
  • Optimize-VHDにより約88GB削減できた
  • SSD256GB環境では放置するとWindows全体に影響する
  • クラッシュ後ではなく、定期的な最適化が重要

WSLが重くなったと感じた時点で対応することが、
結果的に一番楽だと思います。

カテゴリー
生成AI

保護中: プログラミング関連のプロンプト

このコンテンツはパスワードで保護されています。閲覧するには以下にパスワードを入力してください。

カテゴリー
AWS システム開発技術

AWS CLI よく使うコマンド集(S3編)

バケット内の一覧表示

Bash
aws s3 ls s3://バケット名/オブジェクト名/

サブフォルダごとに一覧表示(再帰)

Bash
aws s3 ls s3://バケット名/オブジェクト名/ --recursive

ファイルをダウンロード

Bash
aws s3 cp s3://バケット名/オブジェクト名/backup.sql.gz ./backup.sql.gz

フォルダごとダウンロード

Bash
aws s3 cp s3://バケット名/オブジェクト名/ ./オブジェクト名/ --recursive

ファイルをアップロード

Bash
aws s3 cp ./backup.sql.gz s3://バケット名/オブジェクト名/backup.sql.gz

フォルダごとアップロード

Bash
aws s3 cp ./オブジェクト名/ s3://バケット名/オブジェクト名/ --recursive

同期(ローカル → S3)

Bash
aws s3 sync ./オブジェクト名/ s3://バケット名/オブジェクト名/

同期(S3 → ローカル)

Bash
aws s3 sync s3://バケット名/オブジェクト名/ ./オブジェクト名/

ファイル削除

Bash
aws s3 rm s3://バケット名/オブジェクト名/backup.sql.gz

フォルダごと削除(再帰)

Bash
aws s3 rm s3://バケット名/オブジェクト名/ --recursive