コマンド一覧

プロジェクトで利用するコマンドを一覧にまとめています。ツールの概要・設定は ツール概要・設定 を参照してください。

このページは ローカル実行コマンドの正本 です。CI をいつ走らせるかは CI 運用方針、各テストツールの使い方は テスト・品質確認ガイド、PHPCS / PHPStan などの設定理由は 品質設定ドキュメント を参照してください。

CI 運用の重要ルール

• CI Quality Gate は PR 作成時などに 1 回実行します。
• 追加 push 後は自動起動しません。
• マージ前の最新コミット検証は Actions → CI Quality Gate → Run workflow（pr_number または PR ブランチ）を使います。
• Re-run all jobs は旧 SHA の再実行であり、追加 push 後の検証には使いません。

CI ワークフローとローカルコマンド対応

ワークフロー名	内容	ローカルで再現するコマンド
PHPCS Check	WordPress Coding Standards・未使用use文・PHPCS	composer lint / composer lint-fix
PHPStan Check	静的解析	composer phpstan-ci
Deptrac Architecture Check	アーキテクチャ依存関係チェック	composer deptrac
PSR-4 Compliance Check	PSR-4 準拠チェック	composer psr4
Format Check	Prettier フォーマットチェック	npm run format:check / npm run format
JavaScript Lint	ESLint	npm run lint:js
TypeScript Type Check	TypeScript 型チェック（tsc --noEmit）	npm run typecheck

CI の起動条件、手動実行の入力、レビュー時に避けるべき提案は CI 運用方針 と CI Quality Gate を参照してください。

複数チェックをまとめて実行する例:

• PHPStan + Deptrac: composer ci-static-check
• 品質一括（PHPCS + PHPStan + PHPUnit）: composer quality

PHP 系ワークフローでは、core_src で composer install によりオートロードが生成されます。背景は Composer Autoload 運用ガイド を参照してください。

PHPCS（コーディング規約）

composer lint / lint-fix は connector.php・core_src・config のみを対象とします。リポジトリ全体を走査すると CI で OOM になるためです。tests/ は composer lint-tests / lint-tests-fix、その他（scripts/・myTemplate/ 等）は composer run lint-path -- <パス> で個別に実行してください。

用途	コマンド
チェック（サマリ）	composer lint
テストコードのみ	composer lint-tests
テストコード自動修正	composer lint-tests-fix
チェック（詳細）	composer lint-verbose
特定パスのみチェック	composer run lint-path -- <パス>
詳細レポート	composer lint-full
ソース表示レポート	composer lint-source
自動修正	composer lint-fix
特定パスのみ自動修正	composer run lint-fix-path -- <パス>
Checkstyle 出力	composer lint-report
進捗確認	composer lint-progress

PHPStan（静的解析）

用途	コマンド
解析（推奨）	composer analyse
CI 同等（core_src）	composer phpstan-ci
メモリ増量時	composer analyse -- --memory-limit=2G

Deptrac（アーキテクチャ）

用途	コマンド
解析	composer deptrac
CI 同等	composer deptrac-ci

PSR-4 準拠

用途	コマンド
チェック	composer psr4
CI 同等	composer psr4-ci

フォーマット（Prettier）

用途	コマンド
全ファイル整形	npm run format
チェックのみ	npm run format:check
特定ファイル	npx prettier --write <パス>

JavaScript Lint（ESLint）

用途	コマンド
全体チェック	npm run lint:js
自動修正つき	npx eslint "**/*.{js,jsx,mjs,cjs}" --fix

eslint.config.cjs を正本とし、@wordpress/scripts 経由で ESLint を実行する。pre-commit の lint-staged ではステージされた JS ファイルに eslint --fix と Prettier を適用し、CI Quality Gate でも npm run lint:js を実行する。TypeScript は tsconfig.json を正本に npm run typecheck で検査する。

TypeScript（型チェック）

用途	コマンド
型チェックのみ（ビルドなし）	npm run typecheck

tsconfig.json を正本とし、core_src/**/*.ts(x)・tests/**/*.ts(x)・vitest.config.ts を対象に tsc --noEmit を実行する。型エラーはゼロを維持する方針で、CI Quality Gate にも組み込まれている（mockups/・docs/.vitepress/ は対象外）。

Vitest（フロントエンド）

用途	コマンド
Vitest のみ	npx vitest run
通し（build + Vitest + DBML）	npm test

コロケートの *.test.{ts,tsx,js} を対象にする。詳細は Vitest 実行ガイド。CI Quality Gate の Run Vitest ステップでも npm run test が実行される。

PHPUnit（テスト）

用途	コマンド
全テスト実行	composer test
特定テスト	vendor/bin/phpunit tests/Unit/ path/To/Test.php
カバレッジレポート	composer test-coverage

まとめて実行

用途	コマンド
PHPStan + Deptrac（CI 同等）	composer ci-static-check
PHPCS + PHPStan + PHPUnit	composer quality
ローカル品質チェック（PHPCS + PHPStan + Deptrac、PHPUnit なし）	composer quality-check または ./bin/run_local_quality_check.sh

ビルド・デプロイ・ドキュメント

用途	コマンド
古いローカルビルド削除	./bin/clean-old-builds.sh
古いリモートビルド削除（本番）	./bin/clean-remote-builds.sh
古いリモートビルド削除（ステージング）	./bin/clean-remote-builds-staging.sh
本番ビルド	./bin/build.sh
本番デプロイ（一括）	./bin/deploy-all.sh
本番アップロードのみ	./bin/deploy.sh [version]
本番 VERSION 切り替え＋キャッシュ削除	./bin/activate.sh <version>
本番キャッシュ削除のみ	./bin/clear-cache.sh
ステージングデプロイ（一括）	./bin/deploy-all-staging.sh
ステージングアップロードのみ	./bin/deploy-staging.sh [version]
ステージング VERSION 切り替え＋キャッシュ削除	./bin/activate-staging.sh <version>
ステージングキャッシュ削除のみ	./bin/clear-staging-cache.sh
管理画面でビルド一覧/削除	WordPress 管理画面 → ツール → ビルド管理
ドキュメント開発	npm run docs:dev
ドキュメントビルド	npm run docs:build
ドキュメントプレビュー	npm run docs:preview
管理画面 UI ビルド（日報ブロック・P-WORLD 画像キャプチャ・公開 Chart.js バンドル）	npm run build

npm run build は webpack.config.js のエントリを core_src/PostType/daily_article/Admin/assets/build/ へ出力します。公開ショートコード向け Chart.js バンドル（period-kishu-samai-ranking.js / period-kishu-samai-ranking-snapshot.js / hall-samai-graph.js 等）も .gitignore 対象のため、デプロイ前にローカルでビルドしないと本番でグラフが描画されません。./bin/build.sh / ./bin/deploy-all.sh は内部で npm run build を実行します。

本番デプロイ前バックアップ（DB + サイトファイル）

ConoHa のファイルマネージャーで一式 zip を取ると 504 になりやすいため、サイト一式は SSH / rsync で取得します（デフォルト）。backups/ は .gitignore 対象です。

用途	コマンド
デプロイ前に DB ダンプ + WP ルートのミラー + 復旧メモ	./scripts/backup-before-deploy.sh
DB とメモのみ（ファイル rsync なし）	./scripts/backup-before-deploy.sh --no-files
wp-content/uploads/ も含める（時間・容量増）	./scripts/backup-before-deploy.sh --with-uploads
バックアップした DB を本番へ復元	./scripts/restore-db-to-production.sh backups/<日時>/db.sql.gz

デフォルトのファイル取得では wp-content/uploads/ やキャッシュ等を .backup-rsync-excludes で除外します。

設定は config/local.env（DEPLOY_* / PROD_DB_* / DEPLOY_REMOTE_PATH）。WordPress ルートを固定で指定したい場合は任意で DEPLOY_REMOTE_WP_ROOT を設定します。復旧手順は各バックアップ内の ROLLBACK.md を参照。

デプロイと myTemplate / scripts: ./bin/deploy.sh / ./bin/deploy-staging.sh（内部で bin/_deploy-core.sh を実行）は _build/core_* に加え、次をリモートの DEPLOY_REMOTE_PATH 配下へ同期します。

• myTemplate/single-daily-article-template.php … リポジトリルートにファイルがあるときのみ myTemplate/ へアップロード。無い場合は警告のみ（core_* の転送は完了）。
• scripts/ … リポジトリ直下の scripts/ を rsync で DEPLOY_REMOTE_PATH/scripts/ に同期（wp eval-file 用の PHP 等。.DS_Store と *.bak は除外）。
• 前提条件 … scripts/ の同期は rsync に依存します。ローカル環境・リモート環境の双方に rsync がインストールされている必要があり、どちらか一方でも未導入の場合はデプロイがエラー終了します。

--delete の挙動（運用注意）: rsync --delete により、除外されていない同期対象ファイルでローカルの scripts/ に存在しないものは、リモートからも削除されます。バックフィルなど一時スクリプトをリモートで実行した後にローカルから削除した場合、次の deploy.sh 実行でリモートからも消えることを意識してください。スクリプトが不要になったことを確認してからローカルで削除し、その後デプロイするのが安全な手順です。

なお、--exclude='.DS_Store' / --exclude='*.bak' を付けているため、これらの除外パターンに一致するファイルは --delete だけではリモートから削除されません。除外対象も含めて完全に揃えたい場合は、リモートで手動削除するか、実装側で --delete-excluded の採用を検討してください。

Web 直接アクセス対策: scripts/ には scripts/.htaccess（Require all denied）を同梱しており、Apache 経由のブラウザアクセスをブロックします。ただし nginx 等の場合は Web サーバー設定側で scripts/ への直接アクセスを遮断してください。

SSH が使えない緊急時や zip 転送で高速化したい場合は、本番では ./bin/deploy-all-ftps-zip.sh または ./bin/deploy-ftps-zip.sh <version>、ステージングでは ./bin/deploy-all-ftps-zip-staging.sh または ./bin/deploy-ftps-zip-staging.sh <version> を使用できます。config/local.env / config/staging.env の DEPLOY_FTPS_URL / DEPLOY_FTPS_USER / DEPLOY_FTPS_PASS / DEPLOY_FTPS_PUBLIC_URL を使い、FTPS で zip と一時 PHP レシーバーをアップロードして、HTTPS 経由でサーバー側展開と VERSION 切り替えを行います。scripts/ は削除同期され、古い core_* と前回失敗時の一時ファイルも成功時に掃除されます。詳細は 本番環境デプロイ と ステージング環境デプロイ を参照してください。

日別記事が環境で表示されないとき（確認手順）

ローカルでは表示できるがステージング等で一般ユーザー向けに本文がほぼ出ない場合の切り分け。該当環境の DB・ファイル・HTML を確認します。

post meta（レイヤー A）

• 対象の daily_article 投稿 ID を決める。
• wp_postmeta の kousatsu_date / halls が 非空の文字列か確認する（配列として保存されている・空文字のみ等だとテンプレート側で一般ユーザーには出力されない）。
• テーブルプレフィックスは環境に合わせて読み替える。

SELECT meta_key, meta_value
FROM wp_postmeta
WHERE post_id = ? /* 投稿ID */
  AND meta_key IN ('kousatsu_date', 'halls');

HTML とログ

• ログアウト状態で記事 URL を開き、HTML ソースに DailyArticleTemplate 関連のコメントやバリデーション文言がないか確認する。
• WP_DEBUG / WP_DEBUG_LOG を有効にできる環境では debug.log の [ERROR] DailyArticleTemplate や TemplateHooks のデバッグログを確認する。

DOM と台データ（レイヤー B）

• 開発者ツールで、日別結果ショートコード由来のマークアップ（ランキング・ヒートマップ等）が DOM に存在するか確認する。本文枠がまったく無い場合はレイヤー A やテンプレート未配置を先に疑う。
• 台データなどアプリ用テーブルに、該当する考察日・ホールのデータが揃っているか（DB インポート範囲・バッチの有無）。

テンプレートと VERSION

• リモートの子テーマに myCustom/myTemplate/single-daily-article-template.php があるか（上記デプロイで myCustom/myTemplate/ に同期するか、手動で配置）。
• リモートの connector.php の VERSION と、実際に存在する core_YYYYMMDD_HHMMSS ディレクトリが一致しているか。

Transient

• 必要に応じ daily_article_template_ プレフィックスの transient を削除し、表示が変わるか確認する（DailyArticleTemplateDataService 経由のキャッシュ）。

古いビルドの削除

_build/ 内に蓄積した古いビルドディレクトリ（core_YYYYMMDD_HHMMSS）を削除します。

用途	コマンド
一覧表示	./bin/clean-old-builds.sh --list
最新1件を残して削除（デフォルト）	./bin/clean-old-builds.sh
最新 N 件を残して削除	./bin/clean-old-builds.sh --keep N
指定バージョンを削除	./bin/clean-old-builds.sh --version YYYYMMDD_HHMMSS
ドライラン（削除対象の確認のみ）	./bin/clean-old-builds.sh --dry-run
ドライラン（最新2件残す場合）	./bin/clean-old-builds.sh --keep 2 --dry-run

注意: ./bin/build.sh は実行のたびに _build/* を全削除してから新規ビルドするため、通常は core_* が1件のみ残ります。複数ビルドが存在する場合（手動コピーなど）に本コマンドを利用してください。

リモート（本番・ステージング）の古いビルド削除

デプロイ先サーバーの DEPLOY_REMOTE_PATH 配下にある core_YYYYMMDD_HHMMSS を削除します。

用途	本番コマンド	ステージングコマンド
一覧表示	./bin/clean-remote-builds.sh --list	./bin/clean-remote-builds-staging.sh --list
最新1件を残して削除（デフォルト）	./bin/clean-remote-builds.sh	./bin/clean-remote-builds-staging.sh
最新 N 件を残して削除	./bin/clean-remote-builds.sh --keep N	./bin/clean-remote-builds-staging.sh --keep N
指定バージョンを削除	./bin/clean-remote-builds.sh --version VER	./bin/clean-remote-builds-staging.sh --version VER
ドライラン（削除対象の確認のみ）	./bin/clean-remote-builds.sh --dry-run	./bin/clean-remote-builds-staging.sh --dry-run
ドライラン（最新2件残す場合）	./bin/clean-remote-builds.sh --keep 2 --dry-run	./bin/clean-remote-builds-staging.sh --keep 2 --dry-run

注意: アクティブに利用中の core_* を削除するとサイトが動作しなくなる可能性があります。削除前に、リモート環境の connector.php などで VERSION 定数を参照し、現在参照中のバージョンを必ず特定してください。

管理画面でのビルド管理

WordPress 管理画面の ツール > ビルド管理 から、サーバー上の core_YYYYMMDD_HHMMSS を一覧表示・削除できます。

• 稼働中のバージョン（VERSION が参照中の core_*）は削除不可
• チェックボックスで選択したビルドを一括削除可能

min-repo ローカルデータの本番反映（Issue #2356）

サーバー IP では min-repo.com からマイナス差枚が取得できないため、ローカルで取得したデータを本番/ステージングへ反映する方法です。管理画面: サイドバー → min-repo データ取得。

案	手順
案A（REST + ヘルパー）	ローカル WP で Cookie 設定 → 管理画面「転送先設定」を1回保存 → transfer コマンドまたは「本番へ転送」
案B（CSV）	管理画面「CSV エクスポート」→ 本番の CSV インポート
案C（HTML）	ブラウザで min-repo の ?kishu=all ページ HTML をコピー → 管理画面「HTML インポート」

本番で HTML インポート時に Forbidden が出る場合（ConoHa WAF）

本番（ConoHa WING）で「HTML からインポート」押下後に 閲覧できません (Forbidden access) が出る場合、SiteGuard WAF が POST 本文を XSS 等と誤検知している可能性が高いです（WordPress 未到達）。

1. 管理画面の自動整形（テーマ実装）: 送信前にブラウザが差枚テーブル周辺の最小 HTML に整形します。ページ全体をそのまま貼り付けて問題ありません。
2. WAF ログ確認: ConoHa コントロールパネル → サイト管理 → サイトセキュリティ → WAF → 該当時刻のログ（多くはクロスサイトスクリプティング検知）。必要なら「除外」（作業後も WAF は ON に戻す）。
3. フォールバック: 案A（transfer / 「本番へ転送」）または案B（CSV エクスポート → 本番 CSV インポート）。

ローカルヘルパー（案A）

cd scripts/min-repo-cookie-helper
npm install

# Cookie をローカル WP に送信
export WP_URL="https://local.example.com"
export WP_USER="admin"
export WP_APP_PASSWORD="xxxx xxxx xxxx xxxx xxxx xxxx"
node index.js cookie

# 差枚データを本番へ転送（パスワードは環境変数推奨）
export TARGET_WP_URL="https://production.example.com"
export TARGET_WP_USER="admin"
export TARGET_WP_APP_PASSWORD="xxxx xxxx xxxx xxxx xxxx xxxx"
node index.js transfer --date=20260614 --hall=island \
  --target-url="$TARGET_WP_URL" --target-user="$TARGET_WP_USER"

# 引数でパスワードを渡す場合（シェル履歴・プロセス一覧に残るため非推奨）
# node index.js transfer ... --target-password="xxxx xxxx xxxx xxxx xxxx xxxx"

REST エンドポイント:

• Cookie: POST /wp-json/slot-kouryaku/v1/min-repo-cookie
• 差枚データ: POST /wp-json/slot-kouryaku/v1/min-repo-data（Body: {"rows": [...], "delete_existing": false}）

詳細は scripts/min-repo-cookie-helper/README.md を参照してください。

関連ドキュメント

• ツール概要・設定 — 各ツールの概要・設定・セットアップ
• CI/CD ワークフロー概要 — 各ワークフローの詳細
• 機種別サマリバックフィル CLI — 普段使わない保守用再計算 CLI