投稿者: manualmaton Page 3 of 260

update-motdでのメモリ監視。

UbuntuのWebサーバで、スワップの使いすぎによる再起動の判断を行うためのスクリプトを仕込みました。

スクリプト内容

#!/bin/bash
#
# メモリとSWAPの使用量を表示し、閾値を超えた場合に再起動を促す
#

# --- 設定 ---
# 再起動を促す警告を表示する閾値
# 両方の条件を満たした場合に警告が表示されます
readonly MEM_THRESHOLD=75  # 実メモリ使用率 (%)
readonly SWAP_THRESHOLD=10 # SWAP使用率 (%)

# --- 処理 ---

# freeコマンドの出力を取得 (-m オプションでMB単位)
free_output=$(free -m)

# メモリ情報を抽出・計算 (GB単位に変換して保持)
read mem_total_gb mem_used_gb mem_percent <<< $(echo "$free_output" | awk '
/^Mem:/ {
    total=$2;
    used=$3;
    if (total > 0) {
        percent=(used/total)*100;
    } else {
        percent=0;
    }
    printf "%.1f %.1f %.0f", total/1024, used/1024, percent;
}')

# SWAP情報を抽出・計算 (GB単位に変換して保持)
# SWAP領域が存在しない場合も考慮
if echo "$free_output" | grep -q '^Swap:'; then
    has_swap=true
    read swap_total_gb swap_used_gb swap_percent <<< $(echo "$free_output" | awk '
    /^Swap:/ {
        total=$2;
        used=$3;
        if (total > 0) {
            percent=(used/total)*100;
        } else {
            percent=0;
        }
        printf "%.1f %.1f %.0f", total/1024, used/1024, percent;
    }')
else
    has_swap=false
    swap_total_gb=0
    swap_used_gb=0
    swap_percent=0
fi


# --- 表示 ---

echo ""
# メモリとSWAPの使用率を整形して表示
# printfのフォーマットで表示幅を揃え、見やすくしています
printf "メモリ: %5.1f GB 中 %5.1f GB 使用 (%d%%)\n" "$mem_total_gb" "$mem_used_gb" "$mem_percent"

# SWAPの合計が0より大きい場合のみ表示
if (( $(echo "$swap_total_gb > 0" | bc -l) )); then
    printf "SWAP  : %5.1f GB 中 %5.1f GB 使用 (%d%%)\n" "$swap_total_gb" "$swap_used_gb" "$swap_percent"
fi

# 閾値を超えているかチェックし、条件を満たせば警告を表示
if [ "$has_swap" = true ] && [ "$mem_percent" -ge "$MEM_THRESHOLD" ] && [ "$swap_percent" -ge "$SWAP_THRESHOLD" ]; then
    echo ""
    echo "############################################################"
    echo "#  メモリ量の枯渇                                            #"
    echo "#  パフォーマンス低下を避けるため、再起動を検討してください。#"
    echo "############################################################"
fi

このスクリプトを

sudo chmod +x 

`/etc/update-motd.d/50-memory-check`

として仕込みます。

起動時にメモリ量やスワップ量を検査。

警告が出れば、再起動の検討やプロセスの見直しなどを行うことができます。

Redmine5.1.4→Redmine5.1.8へのアップデート手順。

公開用Redmine

https://atelier.reisalin.com

のバージョンを5.1.4→5.1.8にアップデートしたときのメモです。

環境

  • Ubuntu 24.04
  • 動かしていたRedmine:5.1.4
  • アップデートしたRedmie:5.1.8
  • Apache 2.4 / mod-passangerでRubyアプリを使用(Ruby 3.2系)
  • MySQL 8.0.3

作業に備えての前提

  • Webサービスを止めるため、ユーザアクセスができない状況が発生します。
  • 利害関係者への事前周知・作業時間の確保は十分に行ってください。(慣れれば20分程度で完了しますが、1時間は取っておいた方が無難です)
  • また、筆者環境はfiles配下をクラウドストレージにマウントしています。手順は自身の環境に合わせてください。

さっくりとはいかない手順

  1. (強く推奨)システム全体のバックアップ
  2. DBのバックアップ
  3. redmineのディレクトリを一度mvでリネームしてバックアップ。
  4. apache停止
  5. ディレクトリを再作成し、新しい空のRedmineを作る。
  6. themesとpluginを再配置。filesのシンボリックリンクを貼り替える。
  7. themesとpluginを再配置した状態でDBマイグレーション。
  8. apache再開
  9. バージョンアップ確認

システム全体のバックアップ(スナップショット)

  • AWS
  • 仮想サーバ

などで動かしている場合は、この段階でシステム全体のバックアップ(スナップショット)を取ることを強く推奨します。

mysqlによるDBバックアップ

  • バックアップディレクトリに移動
cd /hoge && pwd

任意のディレクトリを指定します。

  • mysqldump
mysqldump -h localhost -u redmine -p --no-tablespaces --single-transaction redmine > redmine_backup.$(date +%Y%m%d).sql

DB名やDBユーザは自分の環境に合わせます。

  • mysqldump確認
view redmine_backup.$(date +%Y%m%d).sql

DBが平文で読めることを確認します。

データ退避

  • ディレクトリ移動
cd /var/lib && pwd

Redmineが格納されているディレクトリの親ディレクトリに移動します。(筆者環境は/home/www-data)

  • Redmine全体ディレクトリ確認
ls -ld redmine

退避対象のディレクトリがあることを確認します。ディレクトリ名は自分の環境に合わせます。

  • Redmine待避
sudo mv redmine redmine_$(date +%Y%m%d)
  • Redmine待避確認
ls -ld redmine_$(date +%Y%m%d)

ディレクトリがあることを確認します。

apache停止

念のため、apacheを停止します。

  • apache停止前確認
systemctl status apache2.service

active(running)を確認します。

  • apache停止
sudo systemctl stop apache2.service
  • apache停止確認
systemctl status apache2.service

inactive(dead)を確認します。

Redmineプログラムの配置

  • Redmineのディレクトリ作成
sudo mkdir /var/lib/redmine
  • Redmineディレクトリの権限変更
sudo chown -R www-data:www-data /var/lib/redmine
  • Redmineディレクトリの作成確認
ls -ld redmine

ディレクトリがあることと、所有者がwww-dataであることを確認します。

  • ソースダウンロード
sudo -u www-data svn co https://svn.redmine.org/redmine/branches/5.1-stable /var/lib/redmine

5.1系の最新安定版をダウンロードします。

退避させたディレクトリからconfigファイルコピー

  • database.ymlコピー
sudo -u www-data cp -pi /var/lib/redmine_$(date +%Y%m%d)/config/database.yml /var/lib/redmine/config/database.yml
  • database.ymlコピー確認 
cat /var/lib/redmine/config/database.yml

待避したファイルの内容であることを確認します。

  • configuration.yml コピー
sudo -u www-data cp -pi /var/lib/redmine_$(date +%Y%m%d)/config/configuration.yml /var/lib/redmine/config/configuration.yml
  • configuration.ymlコピー確認
cat /var/lib/redmine/config/configuration.yml

待避したファイルの内容であることを確認します。

退避したディレクトリからデータを再配置

  • プラグイン一式のコピー
sudo -u www-data cp -pir  /var/lib/redmine_$(date +%Y%m%d)/plugins/* /var/lib/redmine/plugins/

移行元・移行先は自分の環境に合わせます。

  • テーマ一式のコピー
sudo -u www-data cp -pir /var/lib/redmine_$(date +%Y%m%d)/public/themes/* /var/lib/redmine/public/themes/

シンボリックリンク貼り替え

これは筆者の環境がlogディレクトリとfilesディレクトリを別の場所(wasabiクラウドストレージ)にリンクを張っているための措置です。
それ以外の場合は上述した /var/lib/redmine_$(date +%Y%m%d)からfilesやlogをコピーして下さい。

  • Redmineルートディレクトリに移動
cd /var/lib/redmine && pwd

自分の環境に合わせます。

  • filesディレクトリ削除
sudo rm -rf files
  • ログディレクトリ削除
sudo rm -rf log
  • filesディレクトリにシンボリックリンクを張る
sudo ln -sf /mnt/wasabi/redmine/files files

自分の環境に合わせます。

  • filesシンボリックリンクの所有者変更
sudo chown -h www-data:www-data files
  • filesシンボリックリンク確認
ls -l files
  1. filesがシンボリックリンクになっていること
  2. 所有者がwww-dataであること

を確認します。

  • logディレクトリにシンボリックリンクを張る
sudo ln -sf /var/log/redmine log
  • logシンボリックリンクの所有者変更
sudo chown -h www-data:www-data log
  • logシンボリックリンク確認
ls -l log
  1. logがシンボリックリンクになっていること
  2. 所有者がwww-dataであること

を確認します。

DBマイグレーション

  • Redmineルートディレクトリに移動
cd /var/lib/redmine

自分の環境に合わせます。

  • bundle インストール
sudo -u www-data bundle install --without development test --path vendor/bundle
  • シークレットトークン発行
sudo -u www-data bundle exec rake generate_secret_token
  • DBマイグレーション(本体)
sudo -u www-data RAILS_ENV=production bundle exec rake db:migrate
  • DBマイグレーション(プラグイン)
sudo -u www-data bundle exec rake redmine:plugins:migrate RAILS_ENV=production
  • キャッシュクリア
sudo -u www-data RAILS_ENV=production bundle exec rake tmp:cache:clear
  • セッションクリア
sudo -u www-data RAILS_ENV=production bundle exec rake tmp:sessions:clear

apache再起動

  • apache再起動前確認
systemctl status apache2.service

inactive(dead)を確認します。

  • apache再起動
sudo systemctl start apache2.service
  • apache再起動確認
systemctl status apache2.service

active(running)を確認します。

動作確認

この状態でRedmineに管理者権限でログインします。手順通りなら

  • テーマ
  • 添付ファイル
  • プラグイン
  • チケット一覧

などが有効に動いていて、正常に稼働します。

バージョンアップ後の作業

  • 待避したファイルの削除/バックアップ

/var/lib/redmine_$(date +%Y%m%d)一式を削除、または任意の方法でバックアップします。

トラブルシューティング

bundle install が終わらない

Installing... の表示で止まっているように見えても、実際にはCPUを消費して動作していることがある(ネイティブ拡張機能のコンパイル)。topコマンドでcc1plusなどのプロセスが動いていないか確認する。

"Something went wrong" エラー

Redmineのアプリケーション起動エラー。原因はログに記録されている。

  1. まず /var/lib/redmine/log/production.log を確認する。
  2. 上記にログがなければ、/var/log/apache2/error.log を確認する。

ログから見る主な原因の例

  • プラグインの非互換: Redmine本体の機能とプラグインが競合している場合がある (Overwriting existing method 警告など)。
  • gemのバージョン競合: Ruby本体に付属のgemと、プラグインが要求するgemのバージョンが異なると起動に失敗することがある (base64の競合など)。この場合は、Gemfileでバージョンを明示的に指定するなどの対策が必要。

Redmineにfavicon(サイトアイコン)を設定。

概要

こちらのように、サイトアイコン(favicon)をRedmineに設定するメモです。

環境

  • Ubuntu 24.04
  • Redmine 5.1
  • Apache 2.4
    • サービス実行ユーザはデフォルトのwww-data

で実施しています。(Redmine 6.xはディレクトリ構造が異なります)

準備

  1. ファイルfavicon.pngfavicon.icoを用意します。
  2. このファイルをRedmineサーバに転送します。
  3. ファイルの所有者をRedmine実行ユーザに変更します。sudo chown www-data:www-data favicon.png など

手順

faviconファイルの配置

  • faviconディレクトリの作成
cd /path/to/redmine/root/directory/public/theme/theme_name && pwd

ルートディレクトリやテーマディレクトリは自分の環境に合わせます。 (筆者環境/home/www-data/redmine/public/themes/redmine_theme_kodomo)

sudo -u www-data mkdir favicon && cd favicon && pwd

faviconディレクトリにいることを確認します。

  • 転送したファイルの配置
sudo -u cp -pi /hoge/favicon.png ./

上記、転送した際のディレクトリを指定します。

Redmineサイトの設定

  1. Redmineのサイトに管理者権限でログインします。
  2. 管理>設定>表示に移動します。
    3.「Gravatarのアイコンを使用する」にチェックを入れて保存します。

この後、ブラウザをリロードしてアイコンが変わっていることを確認できれば設定完了です。

アクセスログを圧迫するクローラーへの対処。(Apache 2.4と外部ファイル連携によるクローラーのアクセス遮断とログ軽減)

はじめに

Webサイトを外部に公開していると、非常に厄介なクローラーがアクセスログに蓄積。これらは

  • 超高速
  • 超高頻度

で行われるため、本当に必要なアクセスログ(どの検索サイトから来たか、攻撃の兆候となる不審な点はないか)がつかみにくくなっています。

これを解決するため、以下の措置を執りました。

  1. クローラーや悪質なボットのアクセス拒否
  2. それらをアクセスログにすら残さず、きちんとしたアクセスログを追いやすくする

(※こちらの記事を更に強力に推し進めたものです)

環境

  • Ubuntu 24.04
  • Apache 2.4
    • setenvifモジュール
    • authz_core モジュール
    • (特段の理由がない限り、上記2つは標準で組み込まれていることが多いです。)
    • ない場合はsudo a2enmod setenvif等とした後、sudo systemctl restart apache2.serviceとしてモジュールを組み込みます。
  • また、バーチャルサイトによる複数ドメインにも対応しています。

さっくりとした手順

  1. クローラーのリストファイルを作成します。
  2. Apacheバーチャルサイトの.confファイルを修正します。
  3. 設定を反映後、状況を確認します。

クローラーのリストファイルを作成

  • /etc/apache2/sites-enabled/il-vento-d-oro.txt

としてファイルを作成。(ファイル名や格納場所は自分の環境に合わせてください)

SetEnvIfNoCase User-Agent "facebookexternalhit/1\.1" bad_bot dontlog
SetEnvIfNoCase User-Agent "SemrushBot/7~bl" bad_bot dontlog
SetEnvIfNoCase User-Agent "AhrefsBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "MJ12bot" bad_bot dontlog
SetEnvIfNoCase User-Agent "DotBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "Baiduspider" bad_bot dontlog
SetEnvIfNoCase User-Agent "YandexBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "Sogou web spider" bad_bot dontlog
SetEnvIfNoCase User-Agent "Exabot" bad_bot dontlog
SetEnvIfNoCase User-Agent "MegaIndex\.ru" bad_bot dontlog
SetEnvIfNoCase User-Agent "SeznamBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "BLEXBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "Bytespider" bad_bot dontlog
SetEnvIfNoCase User-Agent "DataForSeoBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "serpstatbot" bad_bot dontlog
SetEnvIfNoCase User-Agent "SeekportBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "index\.community crawler" bad_bot dontlog
SetEnvIfNoCase User-Agent "PetalBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "BacklinksExtendedBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "meta-externalagent/1\.1" bad_bot dontlog
SetEnvIfNoCase User-Agent "ICC-Crawler" bad_bot dontlog
SetEnvIfNoCase User-Agent "bingbot" bad_bot dontlog
SetEnvIfNoCase User-Agent "msnbot" bad_bot dontlog
SetEnvIfNoCase User-Agent "Applebot" bad_bot dontlog
SetEnvIfNoCase User-Agent "DuckDuckBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "Majestic-SEO" bad_bot dontlog
SetEnvIfNoCase User-Agent "cognitiveSEO" bad_bot dontlog
SetEnvIfNoCase User-Agent "archive\.org_bot" bad_bot dontlog
SetEnvIfNoCase User-Agent "CCBot" bad_bot dontlog
SetEnvIfNoCase User-Agent "^$" bad_bot dontlog
SetEnvIfNoCase User-Agent "Custom-AsyncHttpClient" bad_bot dontlog
SetEnvIfNoCase User-Agent "ImagesiftBot" bad_bot dontlog

上記は、サイトを運営していく中で

  • robots.txtを無視し
  • あらゆるページにアクセスし
  • 下手をすれば帯域を阻害する

ものを集めています。"^$"は、エージェントを偽装するスクレイピングへの措置です。

この、

  • SetEnvIfNoCase User-Agent "エージェント名"
  • bad_bot
  • dontlog

と、続けて書くことで、厄介なボットへの対処とアクセスログへの無視を決めます。

もちろん、これらのbotが必要というのであれば省いていきます。

apacheの設定ファイルを編集

  • 設定ファイルのバックアップ
sudo cp -pi /etc/apache2/sites-available/hoge.conf /path/to/backup/directory/hoge.conf.$(date +%Y%m%d)

設定ファイルは自分の環境に合わせます。
任意のバックアップディレクトリを指定します。

  • diffによるバックアップ確認
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) etc/apache2/sites-available/hoge.conf

差分(エラー)が無いことを確認します。

  • ファイルの修正

以下のように修正していきます。(要管理者権限)

例)

<VirtualHost *:443>
    # ServerName、ErrorLogは自分の環境に合わせます
    ServerName hoge.example.com
    ErrorLog /var/log/apache2/hoge/error.log
    # 1)Robots.txtをすり抜ける悪質なbotのリスト(先ほど作成したリストファイルのパスをフルパスで指定) 
    Include /etc/apache2/sites-enabled/il-vento-d-oro.txt
    # dontlogを付与したエージェントはアクセスログに記録させません
    # CustomLogは自分の環境に合わせます
    CustomLog /var/log/apache2/hoge/access.log combined env=!dontlog

# DocumentRootは自分の環境に合わせます。
DocumentRoot /var/www/html/hoge

# Directoryディレクティブは自分の環境に合わせます。
    <Directory /var/www/html/hoge>
        Options -MultiViews
        AllowOverride All
     <RequireAll>
      # 上記リストに従い、"bad_bot"変数がセットされているクローラーのアクセスを拒否します
      Require not env bad_bot
      # それ以外は許可
      Require all granted
     </RequireAll>
    </Directory>

# Require notでForbiddenにすると、クローラーは「拒否されただけで本体はある」と判断し、Webアクセスを繰り返すパターンがあるため、403に404を返す設定を付け加えます
# Directory
ErrorDocument 403 "Not Found"
  • 差分確認
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) etc/apache2/sites-available/hoge.conf
  • 上記、加えた設定が+になっていること
  • ディレクティブの重複や閉じ忘れがないこと

を改めて確認します。

設定反映と確認

  • 別のセッションでアクセスログを確認
tail -f /var/log/apache2/hoge/access.log

※この段階ではクローラーからのアクセスが多々来ています

  • 構文確認
sudo apache2ctl configtest

Syntax Okを確認します

  • Apache再起動前確認
systemctl status apache2.service

active(running)を確認します

  • Apache再起動
sudo systemctl restart apache2.service
  • Apache再起動後確認
systemctl status apache2.service

active(running)を確認します

この段階で、上記、

tail -f /var/log/apache2/hoge/access.log

が止まっていれば設定は成功です。

  • 今までと同じようにアクセスができること
  • 既存のWebサイトに異常が無いこと
  • その場合のアクセスログが表示されること

を確認し、作業は成功です。

作業を切り戻す場合

何か不具合が起きた場合は、バックアップしていた.confを切り戻します。

  • 差分確認
sudo cp -pi /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) etc/apache2/sites-available/hoge.conf

作業時に指定したバックアップディレクトリです。

  • 差分確認
diff -u /path/to/backup/directory/hoge.conf.$(date +%Y%m%d) etc/apache2/sites-available/hoge.conf

差分が ない ことを確認します。

  • 構文確認
sudo apache2ctl configtest

Syntax Okを確認します

  • Apache再起動前確認
systemctl status apache2.service

active(running)を確認します

  • Apache再起動
sudo systemctl restart apache2.service
  • Apache再起動後確認
systemctl status apache2.service

active(running)を確認します

設定前になっていることを確認します。

『ユミアのアトリエ』ハウジングメモ-5-(快適度ボーナスのパラメータ上昇とアロマディフューザー)

『ユミアのアトリエ』マナ変換器を解放することで近くに出現するハウジングエリア。

ここの中には休憩後のステータスを上げてくれる機能があります。

そこで、「休憩前と休憩後、ハウジングエリアによってどのようボーナスがあるのか?」3つで試してみました。

前提:基本データ

休憩していない状態でのステータス。ステータスの上昇値が固定値か割合か不明なため、3人のデータを取りました。

キャラクターHP攻撃力防御力素早さ
ユミア2956431138863070
アイラ2920386435602900
ヴィクトル3367365637542830

全員のレベルは150、装備も可能な限り高品質です。

ハウジングエリアごとの検証

シバーシュ地方のメインシナリオ終盤で解禁されるハウジングエリアは快適度ボーナス200と600でボーナスがあります。

アウルーマ地方の最後のハウジングエリアは快適度800でパラメータが上昇します。

そこに、開拓地クエストで得られるアロマディフューザー(付近のベッドで休憩した際、得られる快適度のボーナス効果が強化される)があります。

それぞれ

  • どの程度パラメータ(ステータスがアップするのか?)
    • アップは上昇か、割合か?
  • アロマディフューザーあり/なしでは?

を、上記2つのエリアで確認しました。

キャラクターステータス① 休憩前(基本値)② シバーシュ地方(+30%)③ シバーシュ地方DFあり (+36%)④ アウルーマ地方&(+25%)⑤ アウルーマ地方DFあり (+30%)
ユミア攻撃力43115604586253885604
防御力38865051528448575051
素早さ30703991417538373991
アイラ攻撃力386450235255(データなし)(データなし)
防御力356046284841(データなし)(データなし)
素早さ290037703944(データなし)(データなし)
ヴィクトル攻撃力365647524972(データなし)(データなし)
防御力375448805105(データなし)(データなし)
素早さ283036793848(データなし)(データなし)

アウルーマ地方でアイラとヴィクトルのデータを取らなかったのが、アロマディフューザーの効果が本来の上昇値+12%上昇することが確定したからです。

上記から判断すると

  • 快適度のボーナスを見込みたければ、シバーシュ地方のヴィア・イデア近くがオススメ。
  • アロマディフューザーは必須。中盤以降のため、開拓任務はしっかりと。

特に、最大36%のバフは高難易度のボス戦で大きく役立つでしょう。

ボードゲーム『アイドルアライブ』「かのんワンショット」デッキ解説&対戦レポート

はじめに

ボードゲーム『アイドルアライブ』の第一弾拡張『Stellar Beats』環境において、最速・最強との呼び声が高い「かのんワンショット」デッキを試す機会がありましたので、ご紹介します。

今回は、オンラインで見かけたデッキレシピを元に構築しました。(というよりも完コピです)

デッキ構成

アイドル

  • センター: 天羽 かのん (橙)
    • 初期Vol: 20%
    • 初期手札: 4枚
    • スキル: あなたのメインフェーズ開始時、あなたは声援チップを1つ得る。
  • 小鳥遊 司 (ライム)
  • 愛澤 日和 (赤)

楽曲デッキ

■1人曲

  • 3『\カワイイ💗/の対価を要求しますっ!』 (かのん)
  • 3『Magic Time!』 (日和)
  • 3『僕は僕を誤解している』 (司)

■2人曲

  • 1『Travel Music ..zzZ』 (かのん)
  • 2『Goストレート!!』 (日和)
  • 3『Break Your Wolrd』 (司)

■3人曲

  • 3『QUEST DIVER』 (司)

■イベント

  • 『機転』(ノーコスト)
  • 『ココロ高鳴るステージ』(3かのん: 3任意)
  • 『テッペン目指して』(2司: 3任意)

デッキのコンセプトと強み

このデッキは、イベントカード 『ココロ高鳴るステージ』 と声援チップ6枚消費の 「アンコール」 を組み合わせることで、1ターンに20点以上のファンを一気に獲得し勝利することを目指す、いわゆる「ワンショットキル」デッキです。

最大の特徴は 「コンボ完成の速さと再現性の高さ」 で、理想的な状況では5ターン目にも決着がついてしまいます。

コンボの核となるのが、司の楽曲で得られるサポートカード 『エナドリ』 です。

『エナドリ』の効果:
次にあなたが使用するイベントカードのメモリー使用枚数は“あなたが選んだ任意の種類のメモリー”1枚分だけ少なくなる。

この「“あなたが選んだ任意の種類のメモリー”1枚分だけ少なくなる」というテキストがコンボの肝です。これは、コストとして指定されている 特定の色(今回の場合は橙)のメモリーを対象に選んで軽減できる ことを意味します。

『ココロ高鳴るステージ』の本来のコストは「 橙のメモリー3枚 」と「 任意のメモリー3枚 」の合計6枚です。しかし、『エナドリ』を3枚使い、軽減対象として3回とも「橙」を指定することで、 「橙のメモリー3枚」のコスト支払いが免除 されます。

結果として、コンボの要求値が劇的に下がっています。

基本的なデッキの動かし方

序盤〜中盤

コンボ始動に向けて、以下の準備を進めます。

  • 司の楽曲をプレイ : ボルテージを上げつつ、コンボのキーパーツである『エナドリ』を3枚集めます。
  • 声援チップ獲得を優先 : かのんのセンタースキルとファンサで声援チップを6枚(アンコール用)集めることを目標にします。
  • 観客の獲得 : 観客デッキの前列に『応援隊長』が見えたら優先的に獲得しましょう。
  • 手札の管理 : 声援チップの上限が近づいてきたら、効果でカードを引き、手札を充実させます。

コンボ始動

以下の条件が整ったら、コンボをスタートします。

  • ボルテージ: 80%~90%程度
  • リソース: 声援チップ6~7枚、『エナドリ』3枚以上
  • 手札: 1人曲が各色1枚以上(2色が2枚あると理想的)を含む、5~6枚程度の楽曲カード

【コンボ手順】

  1. 『エナドリ』を3枚消費。コスト軽減の対象をすべて「橙」に指定します。
  2. 好きな色のメモリー3枚を支払い、イベント 『ココロ高鳴るステージ』 を発動。
  3. 効果に従い、各アイドルの楽曲を合計3回プレイし、観客を6枚獲得します。
  4. 声援チップを6枚支払い 「アンコール」 を宣言。アイドル全員がバックステージに戻り、再度楽曲カードが使用可能になります。
  5. ここで獲得したファンを配置しつつ、日和の「FAN効果」(ボルテージ10%消費で獲得数+1)などを使い、点数を伸ばします。かのんのFAN効果は、やっかいなファンを同時に獲得した場合のデメリットを打ち消すために有効です。
  6. コアファンが十分に獲得できていれば、この時点で20点に到達します。もし届かなくても、司のイベント 『テッペン目指して』 でさらにファンチップ(勝利点)を増やして20点を目指せます。

対戦レポートと考察

対戦の様子

対戦相手は、四宮樹理をセンターに据えたビートダウン系のコントロールデッキ。イベントで捨て札の楽曲を再利用しつつ、『メタルファン』による妨害でこちらのペースを乱す戦略でした。

こちらは理想的な動きとはいきませんでしたが、6ターン目にコンボを始動。相手の『メタルファン』による妨害を受けながらも、1ターンで合計18点のファンを獲得しました。

相手もコアファンのまとめ取りや『ライブビューイング』による継続得点などで猛追し、最終得点は18点。しかし、こちらの点数には一歩及ばず、次のターンで残りの点数を獲得し、勝利を収めました。

このデッキの強みと弱点

実際に使用して感じたのは、以下の点です。

  • ■ 強み1:コンボに必要なボルテージの低さ
    • 3人曲はボルテージ上昇と『エナドリ』獲得を兼ねる3枚のみ。そのため、コンボ始動時の要求ボルテージが80%~90%程度で済み、準備期間が非常に短いのが強力です。
  • ■ 強み2:妨害をものともしない一撃の重さ
    • 瑛里のスナイプや涼子のファン送り、イベント『会場トラブル』といった一般的な妨害をある程度無視できます。一撃で勝負を決めるため、相手にターンを渡したとしても、逆転が非常に難しい状況を作り出せます。(ただし、ミラーマッチは別です)
  • ■ 見える弱点
    • もちろん、これだけ強力なデッキにも弱点はあります。再現性が高いとはいえ、手札事故などで必要なカードが揃わない「下振れ」は起こり得ます。今回の対戦でも、理想ムーブではなかったために相手に猛追される展開となりました。

まとめ

「かのんワンショット」は、

  • 「速さ」
  • 「妨害耐性」
  • 「再現性」

を兼ね備え、文字通り「無から20点を生み出す」ような、圧倒的な爆発力を持つコンボデッキでした。

その強さから、今後は何らかのルール調整が入る可能性も否定できません。(例えば、『エナドリ』の効果が「イベント1枚につき1回まで」と裁定されるだけでも、大きく環境は変わるでしょう)

現状の『Stellar Beats』環境を定義する、非常に強力なデッキタイプであることは間違いないでしょう。

ボードゲーム『アイドルアライブ』独立拡張『Vsinger』感想。

2025年上半期で遊んだボードゲームでも特に面白かった『アイドルアライブ』が、中国ボーカロイドVsingerとコラボレーション。

基本的なルールやゲームの流れはそのままに、単体でも本家との対決でも楽しめる作品として登場しました。

本レビューは、独立拡張のため、基本セットをある程度知っている方向けの記事になること、最初にお詫び申し上げます。

ゲームの概要

基本セット『アイドルアライブ』が持つ

  • プレイヤーはプロデューサーとなり
  • 3人組のアイドルユニットを編成し
  • 楽曲で場のボルテージを高め
  • ファンを獲得し
  • イベントなどを活用してライブを成功に導く

特徴はそのまま、「独立拡張」としてリリースされました。

後述する“ある一点”を除いては、入門者にも経験者にも楽しめる作品となっています。

基本セットとの共通点

以下の特徴はそのままです。(詳しくは拙稿をご確認ください)

  • TCGに慣れていない人でも直感的に理解しやすい楽曲カードの視認性
  • アイドル達による多様な戦略
  • 分かりやすい位相管理とターン進行
  • ファンを中心としたインタラクション(とデメリット持ちファンを巡る駆け引き)

これらの基本セットのルールや楽しさはそのままとなっています。

本作ならではの素晴らしい点

男性歌手によるキャラクターの幅の広さ

これが大きな特徴と言えるでしょう。戦略面のみならず、世界観の広がりという大きな魅力を与えてくれました。

「女性アイドル達のステージ」という基本セットのイメージに対し、『アイドルアライブ Vsinger』は「男女混合ユニットも可能な、より多様なパフォーマンス」を描いています。

女性アイドルも、より大人びたキャラクターという明確な差別化がある印象です。

各種カードの調整による収束性の向上

  • センタースキルによる妨害要素
  • 取り回しやすく、得点効率も高めやすいイベント

の2つが特に印象的であり、複数取るとデメリットとなってしまう「やっかいなファン」のやっかいさを抑えることと、終盤の緊張感に貢献しています。

カジュアル構築でも楽しめるカード群

基本セットのカジュアル構築(1つのセットを2人でシェア)で時折見られた、特定の組み合わせによる一方的なゲーム展開が起こりにくく、どのアイドルを選んでも接戦を楽しめるようになっている点も好感が持てます。

これもまた、本作のとっかかりを楽しみたい初心者向けの内容として機能していました。

拡張でありがら基本セットと混ぜられない制約

公式で

『アイドルアライブ』と混ぜてデッキを構築することは非推奨です。『アイドルアライブVsinger』の収録カードのみでデッキを構築してください。

と言われる理由が、本作を開封して納得。

「同一効果を持つカード」が非常に多いのです。(MtGプレイヤー向けの説明をすると《ラノワールのエルフ》と《エルフの神秘家》のような関係です)

そのため、混ぜてデッキを構築すると

  • カードドローに長けたデッキ
  • 妨害一筋のデッキ

を特化させてしまう事態が発生。とはいえ、基本セットとVsingerの対戦は、「特徴が似通っていながら軸をずらす」という対戦を楽しむことできます。

本作の問題点

アイドルたちの後ろ姿

個人的に残念と思う点がこちらです。「アイドル駒の後ろ姿が描かれていない」です。

プレイヤーはプロデューサーとして、ゲーム中、常にアイドルの「背中」を見つめながら采配を振るうことになります。その肝心の背中がただのイメージカラーのシルエットのみとなっています。

これは没入感という点で致命的といってよく、基本セット並びに拡張『Stellar Beats』で積み上げてきたゲーム体験の全てが「九仞の功を一簣に虧く」かのごとく、この一点によって色あせて感じられてしまいます

ライブの臨場感・ゲームの没入感という確かな手応えが、この、「アイドル達の背中を見つめる」ことだという点だと気づかされた皮肉な状況です。

まとめ

『アイドルアライブ Vsinger』は、基本セットを下敷きにした分かりやすいルールとファンを軸にしたインタラクションを基礎に置きながらも

  • Vsingerの特徴に合わせたスキルやイベント
  • カジュアルでもエキスパートでも楽しめる

作品です。それだけに、「ただ空白を見るかのごとし後ろ姿」が気になる作品でした。

これを気にしないという方は

  • コラボ先に興味がある
  • 基本セットとは違ったゲーム体験をしたい
  • 1セットでも本シリーズを楽しみたい
  • 2~30分で楽しめ、感想戦も盛り上がる2人用のボードゲーム

という点でオススメできる作品です。

毎年恒例:紫陽花。

今年もこの時期が来たので訪れました。

他、印象的だったのが

今年は気温が低めだったか、長持ちしている菖蒲。

柵にぽつんと置かれていた大きなマツボックリ。

情緒溢れる回廊など。

道中のサイクリングも含めていい気分転換でした。

Nextcloud、アップロードしたファイルを一定期間保持後に削除する方法。

ファイルサーバとしても使えるNextcloud。

しかし、サーバの容量によっては無制限にファイルを増やせるわけではありません。

今回、個人用に外部環境に構築したNextcloudは

「Talk機能によるスマートフォンからの高速メモ」

という尖った運用を行うために、ファイルサーバの利用は限定的として

  • アップロードしたファイルは猶予期間を設ける
  • 猶予期間を過ぎたら問答無用でファイルを削除する

設定を行いました。

環境

  • Ubuntu 24.04
  • Nextcloud 31.0.5
  • Apache 2.4
  • MySQL 8.3
  • PHP 8.3

構築については以下の通りです。

https://barrel.reisalin.com/books/nextcloud/page/ubuntu-2404nextcloud

準備

以下のプラグイン(アプリ)をそれぞれインストールします。Nextcloud 31.0.5で動くことを確認しています。

手順

Nextcloudに管理者権限でログインします。

付与するタグを作成します。

管理者設定>基本設定に進みます。

「タグの作成または編集」の項目があるので、

  • コラボレーションタグ
  • タグの名前:任意(30日で消去など、分かりやすい名前にします)
  • タグのレベル:不可視

にして、「作成」をクリックします。

ファイルアップロード時にタグを付与するようにします。

管理者設定>Flowに進みます。

上の方にある緑のボタン「自動タグ付け」の「新しいフローを追加」をクリックします。

以下のように設定します。

  • いつ
  • ファイルが変更されています(これは変更不可)
  • かつ
  • 「ファイルシステムタグ」
  • 「に次のタグがついていない」
  • 先ほど設定したタグ(30日で消去)

設定後、作成→アクティブ化。

一定期間が過ぎたらファイルが消去されるように設定します。

管理者設定>Flowの

「ファイル保持と自動削除」で以下のように設定します。

  • タグを選択
  • 先ほど設定した「30日で消去」を選択。
  • 保持期間(時間単位)
    • 30日
  • いつから
    • 作成日から

として作成。

タグ付け確認

Nextcloudのファイルアップロードで、任意のファイルをアップロードします。(要管理者権限)

ファイルの項目に、自動的に「30日で消去」が付与されていたら設定は完了です。

Nextcloudインストール時のロケールエラーに対処

エラー内容

Nextcloudインストール中、Webでのセットアップ時、

https://設定したドメイン

にアクセスすると

ロケールを en_US.UTF-8/fr_FR.UTF-8/es_ES.UTF-8/de_DE.UTF-8/ru_RU.UTF-8/pt_BR.UTF-8/it_IT.UTF-8/ja_JP.UTF-8/zh_CN.UTF-8 に設定できませんでした
これらのロケールのうちいずれかをシステムにインストールし、Webサーバーを再起動してください。

というエラーが出たので、これに対処します。

環境

  • Ubuntu 24.04
  • Apache 2.4
  • MySQL 8
  • Nextcloud 31.0.4

プログラムを配置し、Apacheのバーチャルサイトに記した直後の出来事です。

手順

ファイルのバックアップを行います。

  • 設定ファイルのバックアップ
sudo cp -pi /etc/apache2/envvars /path/to/backup/directory/envars.$(date +%Y%m%d) 

自分の環境に合わせ、任意のバックアップディレクトリを指定します。

  • バックアップの確認
diff -u /path/to/backup/directory/envars.$(date +%Y%m%d)  /etc/apache2/envvars

差分が無いことを確認します。

設定ファイルの編集を行います。

以下の差分になるように管理者権限で /etc/apache2/envvars ファイルを修正します。

  • 差分
@@ -23,7 +23,9 @@
 export APACHE_LOG_DIR=/var/log/apache2$SUFFIX

 ## The locale used by some modules like mod_dav
-export LANG=C
+#export LANG=C
+export LANG=ja_JP.UTF-8
+export LC_ALL=ja_JP.UTF-8
 ## Uncomment the following line to use the system default locale instead:
 #. /etc/default/locale
  • 差分確認
diff -u /path/to/backup/directory/envars.$(date +%Y%m%d)  /etc/apache2/envvars

で、上記の差分になっていればOKです。日本語環境以外に合わせたい方は、それに従ってください。

設定の反映を確認します。

  • 設定ファイルのコンフィグ確認
sudo apache2ctl configtest

Syntax OKを確認します

  • Apache再起動
sudo systemctl restart apache2.service

再びNextcloudの

https://設定したドメイン

にアクセスし、エラーがなくセットアップ画面が出てくればOKです。

Page 3 of 260

Powered by WordPress & Theme by Anders Norén