Grwoi/Apacheリバースプロキシ、セキュリティ判断FからB+まで改善した記録

昨日の続き。

HTTP ObservatoryでRedmineサイトをB-→B+に改善しましたが、

筆者環境の

  • Apache 2.4によるリバースプロキシ
  • Growi v7.4.7

環境のHTTP診断もそのぐらいであろうと思ったらまさかのF判定を食らいました。

Fランクの内訳

最初の診断結果では、以下の項目で派手に減点を食らっていました。

  • CSP (Content Security Policy):
    • 未設定 (-25)
  • Cookies:
    • Secure属性なし (-20)
  • HSTS: 認識されず
    • (-20)
  • X-Frame-Options / X-Content-Type-Options:
    • 認識されず (-25)

特に謎だったのが、「Apache側でHeader設定を入れているはずなのに、認識されない(Failed)」という点でした。

アプリとApacheの二重出力。

原因を調査するため、curl -I コマンドで生のレスポンスヘッダーを確認しました。

curl -I https://growi-site
Strict-Transport-Security: max-age=63072000
Strict-Transport-Security: max-age=15552000; includeSubDomains  # <-- 2重に出ている
X-Content-Type-Options: nosniff
X-Content-Type-Options: nosniff # <-- 2重に出ている
Set-Cookie: connect.sid=...; Path=/; HttpOnly  # <-- Secure属性がない

原因の分析:

リバースプロキシ構成では、「バックエンド(アプリ側)が吐き出すヘッダー」と「Apacheが追加しようとするヘッダー」が両方ブラウザに届いてしまい、重複が発生。

診断ツール側が「どの設定を信頼すべきか判断できない」としてエラーになっていたのです。

これを回避するための手段が以下の通りです。

さっくりとした手順

  1. Apacheの設定ファイルを書き換えます。
  2. 設定を反映します。
  3. 設定反映を確認します。

Apacheの設定ファイルを書き換え

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

.confの名前やバックアップディレクトリは自分の環境に合わせます。

  • 設定ファイルのバックアップ確認
diff -u /path/to/backup/growi-site.conf.$(date +%Y%m%d) /etc/apache2/sites-available/growi-site.conf

エラーがないことを確認します。

/etc/apache2/sites-available/growi-site.confを以下のように修正していきます。(要管理者権限)

  • 修正前
    Header always set Strict-Transport-Security "max-age=63072000"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-XSS-Protection "1; mode=block"
  • 修正後
        # 重複を防ぐため、通常のレスポンスとProxyレスポンスの両方から一旦削除
        Header unset Strict-Transport-Security
        Header always unset Strict-Transport-Security
        Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

        Header unset X-Content-Type-Options
        Header always unset X-Content-Type-Options
        Header always set X-Content-Type-Options "nosniff"

        Header unset X-Frame-Options
        Header always unset X-Frame-Options
        Header always set X-Frame-Options "SAMEORIGIN"

        # 足りなかった重要ヘッダーを新規追加
        Header always set Referrer-Policy "strict-origin-when-cross-origin"

        # CSP: アプリの動作を維持しつつ、安全性を高める(object-src 'none' を追加)
        Header always unset Content-Security-Policy
        Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' ws: wss:; object-src 'none';"

        # CookieのSecure属性をApache側で強制付与
        Header edit Set-Cookie ^(.-)$ "$1; Secure; SameSite=Lax"

この「2重出力」を解消し、かつアプリ側で足りない属性を付与するために、Apacheの設定を「既存ヘッダーの完全掃除 + 強制セット」という戦略に変更しました。

  • 修正後の差分確認
diff -u /path/to/backup/growi-site.conf.$(date +%Y%m%d) /etc/apache2/sites-available/growi-site.conf

以下のような差分を確認します。

-    Header always set X-Content-Type-Options "nosniff"
-    Header always set X-Frame-Options "SAMEORIGIN"
-    Header always set X-XSS-Protection "1; mode=block"
+        # 重複を防ぐため、通常のレスポンスとProxyレスポンスの両方から一旦削除
+        Header unset Strict-Transport-Security
+        Header always unset Strict-Transport-Security
+        Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
+
+        Header unset X-Content-Type-Options
+        Header always unset X-Content-Type-Options
+        Header always set X-Content-Type-Options "nosniff"
+
+        Header unset X-Frame-Options
+        Header always unset X-Frame-Options
+        Header always set X-Frame-Options "SAMEORIGIN"
+
+        # 足りなかった重要ヘッダーを新規追加
+        Header always set Referrer-Policy "strict-origin-when-cross-origin"
+        
+        # CSP: アプリの動作を維持しつつ、安全性を高める(object-src 'none' を追加)
+        Header always unset Content-Security-Policy
+        Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' ws: wss:; object-src 'none';"
+
+        # CookieのSecure属性をApache側で強制付与
+        Header edit Set-Cookie ^(.-)$ "$1; Secure; SameSite=Lax"

設定反映を確認します。

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • サービス再起動
sudo systemctl restart apache2.service
  • サービス再起動確認
systemctl status apache2.service

active (running)を確認します。

設定反映の確認

curl -I https://growi-site
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' ws: wss:; object-src 'none';

など、ヘッダーのダブりがないことを確認します。

HTTP Observe に再度アクセスし、セキュリティ診断を行いました。

再スキャンの結果、主要な項目はすべて Passed となり、無事に B+ を獲得。

  • HSTS / XFO / NoSniff: 重複が解消され、正しく認識された。
  • Cookies: Secure/SameSite属性が付き、満点。
  • Referrer Policy: 合格。

なぜ「A+」ではないのか?

CSPにおける 'unsafe-inline''unsafe-eval' が「安全ではない」として減点対象になっています。しかし、これらを外すとモダンなWebアプリ(Wikiのエディタなど)は動かなくなることが多いため、利便性とのトレードオフとして 「B+」は現実的な落とし所と言えます。

まとめ

  1. 診断ツールで「Recognizedできない」と言われたら、まずは curl -I で重複を疑う。
  2. Apache側で Header always unset してから set することで、バックエンドとの競合を確実に排除できる。
  3. CookieのSecure化もApacheの Header edit で一発解決。

HTTP外部診断で公開用RedmineをB-からB+に向上させたときの記録。

HTTP Observe サイトのセキュリティ診断。

これで、筆者が公開しているRedmineのセキュリティを上げたときのメモです。

どう判断されたか

結果はB-。特に引っかかったのは

  • Content Security Policy(CSP)
    • Content Security Policy (CSP) header not implemented
  • Cookies
    • Session cookie set without the Secure flag, but transmission over HTTP prevented by HSTS.

何が問題なのか

クッキーの「剥き出し」状態(Secure Flag の欠如)

セッション情報(ログイン情報を保持する)が記録されたクッキーにSecureフラグが付与されていなかったため、たとえ常時httpsで通信していたとしても、ブラウザの設定や不慮の事故で通信が発生した差違に、クッキーがそのままNWに漏洩するリスクがあります。

これが漏洩し、奪われると、悪意ある第三者のなりすまし(セッションハイジャック)を可能にします。

CSPの未実装

Content-Security-Policy (CSP) ヘッダーが全く存在していなかったため、ブラウザに対して「どのスクリプトを実行していいか」が確認されていない状態。Redmineそのものや導入しているプラグインに脆弱性があった場合、攻撃者は外部から悪意あるスクリプトを注入し、閲覧者のブラウザ上で実行させるXSSに無防備となります。

個の2点を直していきます。

環境

  • Redmine 5.1
  • Apache 2.4
    • 常時SSL化設定済み。
  • Ruby 3.2.3

さっくりとした手順

  • 設定ファイルを作成します。
  • 設定を反映します。
  • セキュリティ診断でのランクアップを確認します。

設定ファイルの作成

cd /path/to/redmine/config && pwd

自分の環境のRedmineconfigディレクトリに合わせます。(筆者環境/home/www-data/redmine/config)

  • 設定ファイル作成前確認
ls -l ./initializers/additional_environment.rb

ファイルが無いことを確認します。

  • 設定ファイル作成
sudo -u www-data tee ./initializers/additional_environment.rb > /dev/null << 'EOF'
Rails.application.configure do
  # Cookie の Secure フラグを立てます
  config.session_store :cookie_store, key: '_redmine_session', secure: true

  # CSP の設定を追加します
  config.content_security_policy do |policy|
    policy.default_src :self, :https
    policy.font_src    :self, :https, :data
    policy.img_src     :self, :https, :data
    policy.object_src  :none
    # Redmine はインラインのスクリプトとスタイルを多用するため、これを許可します。
    policy.script_src  :self, :https, :unsafe_inline, :unsafe_eval
    policy.style_src   :self, :https, :unsafe_inline
  end

  # ブラウザが違反を報告するだけで、ブロックしないモードです。(デバッグ用)
  # config.content_security_policy_report_only = true
end
EOF

設定ファイル作成前確認

ls -l ./initializers/additional_environment.rb

ファイルがあることを確認します。

設定反映を確認します。

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • サービス再起動
sudo systemctl restart apache2.service
  • サービス再起動確認
systemctl status apache2.service

active (running)を確認します。

まとめ

HTTP Observe に再度アクセスし、セキュリティ診断を行いました。

結果はB+。

  • Contents Security Policy (CSP)
    • Content Security Policy (CSP) implemented unsafely. This includes 'unsafe-inline' or data: inside script-src, overly broad sources such as https: inside object-src or script-src, or not restricting the sources for object-src or script-src.
    • Remove unsafe-inline and data: from script-src, overly broad sources from object-src and script-src, and ensure object-src and script-src are set.

依然として課題は残るものの、ここを下手にいじると、外部プラグインとの連携などに支障を来します。

これらを狙った脆弱性はWAFで埋めて生きつつ、これらの改善案を図っていくのが今後の課題です。

NAS新調。TS-216G選定理由。

デジタルデータの保管庫として、自室で稼働し続けてきたNAS。気づけば導入から10年という月日が流れていました。

なぜ今、リプレースが必要だったのか。そして数ある選択肢からなぜ冒頭の機種を選んだのか。その経緯のメモです。

限界を超えたHDD。

きっかけは、現在のNAS(ASUSTOR AS-202T)のディスクチェックを確認したことでした。そこに並んでいた数値は、まさに「驚愕」の一言です。

  • 稼働時間:
    • 約45,000時間(設計寿命の目安30,000時間を大幅超過)
  • ヘッド退避回数:
    • 約340万回(公称耐用回数60万回の5倍以上)

NAS本体は2015年の導入。2021年にディスクの状況が怪しくなって2TB→4TBに交換。

そこから大きなトラブルもなく動いてくれたのは奇跡に近いと言えるでしょう。そして、筆者が利用していただけというのも相まって、奇跡的に長持ちをしました。

決断の理由

実は2022年頃から「そろそろ機器も限界だろう」とは感じていました。しかし、日々の忙しさやコスト(何より2022年はコロナに罹患、そこからVPSの運用やらクラウドストレージの失敗と出費)を前に、騙し騙し運用を続けてきたのが本音です。

今回、重い腰を上げた決定的な要因は「ストレージ市場の激変」です。2025ね12月よりSSDの価格暴騰が続き、その波がHDDに波及するのも時間の問題という状況。

「今この瞬間が、最も安く、安全に逃げ切れる最後のチャンスだ」という直感が、4年越しの迷いを断ち切らせました。

そして注文して届いたのがこちらです。

なぜ「QNAP TS-216G」を選んだのか

選定にあたっては、同一メーカーであるASUSTORは候補に挙がっていましたが、エントリーモデルは市場で手に入れづらく、ミドルモデルは逆に高い。そこで、選択肢として上がったのが

  • QNAP
  • UGREEN

の2択。特に、圧倒的なスペックの新興勢力であるUGREENなども検討対象に挙がりました。しかし、最終的に老舗のQNAPを選んだ理由は、単なるスペック比較では測れない「データの重み」にありました。

  • ソフトウェアの信頼性:
    • 単なるファイル置き場ではなく、PCまるごとのバックアップや復旧(ベアメタル復旧)まで備えた信頼性の高く守備の広いソフトウェア群
  • 静音・排熱設計:
    • ホームNASにも一日の長があるメーカーです。リビングに置くことを前提とした、10年先を見据えたハードウェアの造り込み。
  • アップデートの継続性:
    • 長期間、最新のセキュリティパッチを供給し続けるエンタープライズ向けメーカーという信頼。
  • セキュリティと地政学的リスク:
    • これが一番の問題かもしれません。「かの国の法律は仕込もうと思えばバックドアを仕掛けられる」という懸念がありました。

特に、「自分だけの記録」という、失えば二度と手に入らない単一障害点を守るため、新興勢力への不安を捨て、実績あるQNAPを選びました。

HDDとしてこれを選んだ理由

NASの筐体が決まったら、次に決めるべきは最も重要な心臓部、HDDの選定です。今回、私は迷わずWestern Digitalの「WD Red Plus (8TB)」を2台選択しました。

これまで使用していたWD Blueも、10年・45,000時間という驚異的な耐久性を見せてくれましたが、「NAS専用品」を載せるべき明確な根拠がありました。

24時間365日の「常時稼働」を前提とした設計

現行のWD Blueが「PCを使っている間だけ動く」ことを想定しているのに対し、WD Red Plusは「1年365日、1秒も休まず動き続ける」ことを前提に設計されています。

今後、PCパーツの値上がりが予想されているので、逆にケチらない方が安上がりという判断。

「CMR方式」へのこだわり

近年のHDDには、安価ですが書き込み速度にムラが出やすい「SMR方式」が増えています。しかし、NASのRAID構成において書き込み遅延は致命的なエラーに繋がりかねません。
WD Red Plusは、安定した記録が可能な「CMR(従来型磁気記録)方式」を堅持しています。データの整合性を最優先するNASにおいて、この信頼性は譲れない一線でした。

NAS特有の「振動」への対策

2台、3台とドライブを並べて動かすNASでは、お互いの回転振動がエラーの原因になります。WD Red Plusには、この振動を検知し補正する仕様。
静音性に優れたQNAPの筐体と、振動に強いWD Redを選んだわけです。

今後の流れ

  1. セットアップ
  2. 基礎設計
  3. 運用方針決め
  4. データ移行の計画
  5. 移行と同時に実運用

先は長いのですが、HDDの寿命待ったなし。そこはFestina Lenteの精神で行きます。

バーガーの休日。

連休最終日に開拓したお店が自分好みでした。

和牛100%、夕方までお腹いっぱいというボリューミーなハンバーガー。

非常に丁寧に造られたパティに、みずみずしいサラダ(タマネギ、トマト、レタス)が合いました。

そして、これだけの素材を挟みながらも型崩れしないバンズ。程よい堅さはハンバーグとしっかり調和。かみ切れるからこそ、途中で潰れたりソースでふやけるということもありません。

チップスも一級品。カリカリの表面にサクッとした芋の風味。

こう、新たな見せを発掘するというのもまた休日の収穫です。

『ライザのアトリエ2(及び2DX)』アークナイトの採取。

スタルチウム調合に必要な素材、アークナイト。レシピ調合で必要なのに属性値が1と序盤の難所となっています。

斧での採取

シルム湿原

ヴィントミューレ渓谷にファストトラベルして湿原に戻った先、

乳白色の水晶で採れます。
序盤はここで採取することになるでしょう。

霊獣での採取

遺跡「戦乙女の地下墓所」マップ2:鐘鳴り路

確率は低めですが、属性値2のアークナイトを霊獣で掘り当てることができます。

  1. マップ入り口から右側に沿って霊獣で移動する。
  2. 掘り当てる場所が3箇所ぐらい固まっていますので掘ります。
  3. 2DXであれば、『手向けの花々』にファストトラベルできるので更に便利です。

※効果「掘り当てる:大」以上は必要です。

上記2箇所で採取。それ以降は種やショップ開発でより高品質なアークナイトを入手します。

種での採取

石の種で良質なものが採れます。(効果を解放すれば)

ショップ開発

「エーテルコア」売却で解放されます。周回プレイを見据えるのであれば売却しておきましょう。

ケーブル兼ストラップ。

いざというときに仕えるし、実用性もあるという品を入手です。

この、充電ケーブルそのものがストラップになっているという仕様。

スマートフォンケースにアタッチメントを取り付けるだけ。

これで、ショルダーストラップ完成。

保護カバーを取り外せば充電もできます。しっかりと落ちないようにストラップつきでした。

Nextcloudで大容量ファイルを安定して扱うためのApacheチューニング:RequestReadTimeoutの調整

スマートフォンからの画像を自分のPCに転用する形で用いているNextcloud。

アップロードが途中で失敗したり、特定の条件下で接続が切れたりすることがあります。Apacheビルトインのmod_reqtimeout設定を最適化し、サーバーの安定性と利便性を両立させるためのチューニングを行いました。

環境

  • Nextcloud 32
  • Apache 2.4
  • PHP-FPM8.3
  • Ubuntu 24.04

そもそもmod_reqtimeoutとは?

Slowloris(スローロリス)攻撃への対策

このモジュールがビルトインされたのは、Slowlorisという、非常に低コストで強力な攻撃手法への対抗があります。

通常のDoS攻撃は大量の通信を送りますが、Slowlorisは逆に「極めてゆっくり」通信します。

  1. サーバーに接続を開始する。
  2. リクエスト(ヘッダーやボディ)を、タイムアウトにならないギリギリの遅さで、1バイトずつ小出しに送る。
  3. サーバー側は「まだデータが来るはずだ」と判断し、その接続(スレッドやプロセス)を維持し続ける。

結果 サーバーの同時接続数の上限が攻撃者の「待ち」状態で埋まってしまい、正規のユーザーがアクセスできなくなります。

mod_reqtimeout は、この「嫌がらせ」を許さないための防衛線です。

サーバーリソースの適正管理

Apacheサーバーが1つの接続を維持するには、メモリやCPUリソースを消費します。
もしタイムアウト設定がない、あるいは極端に長い場合、以下のような問題が発生します。

  • ゾンビ接続の蓄積: ネットワークが切れたのにクローズ処理が終わっていない接続が残り続ける。
  • リソースの浪費: 応答の遅いクライアント(意図的か否かに関わらず)のために、サーバーの貴重な作業枠をいつまでも空けておくことになります。

なぜこれがNextcloudで徒になるのか

Nextcloudのデータの性質と通信の仕組みにあります。

巨大なファイルを細切れにする

Nextcloudは、数MBから数GBあるような大きなファイルを送る際、一気に送らずにファイルを分割して、「チャンク(塊)」に分割して送信します。

  • 動作の流れ:
    • チャンクAを送信 → サーバーが処理 → チャンクBを送信……
  • 問題点:
    • チャンクとチャンクの間に、クライアント側でのファイル読み込みやハッシュ計算などで一瞬「無通信」の時間が流れます。
  • 結果:
    • Apacheのmod_reqtimeoutは、この無通信を先のSlowlorisと誤認して、接続をバッサリ切ってしまいます。

モバイル回線の不安定さ

Nextcloudは外出先のスマートフォンから使うことを想定しています。

  • 電波の瞬断:
    • 移動中にWi-Fiから4G/5G回線に切り替わったりする。
  • 上り速度の制限:
    • モバイル回線は「下り」は速くても「上り」が極端に遅いことが多い。

これも、先のSlowloris攻撃と見做されてしまいます。

チューニングの必要性

だからといって、このmod_reqtimeoutを無効にすると、それらの攻撃への備えがなくなります。

Nextcloudの利便性を高めつつ不審な攻撃を守るというのは

「任務」は遂行する「部下」も守る
お前ごときに「両方」やるというのはそう難しいことじゃあないな

ぐらいの精神でやっていきましょう。

さっくりとした手順

  • mod_reatimeoutの設定ファイルのバックアップを取る。
  • mod_reatimeoutの設定ファイルを修正する。
  • サービス再起動を行う。

mod_reatimeoutの設定ファイルのバックアップ

  • 念のためのモジュール確認
sudo apache2ctl -M |grep req

reqtimeout_module (shared)を確認します。(apacheをapt等で入れていれば、まず入っています)

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

/path/to/backup/directoryは自分の環境に合わせます。

  • ファイルバックアップ確認
diff -u /path/to/backup/directory/reqtimeout.conf.$(date +%Y%m%d) /etc/apache2/mods-available/reqtimeout.conf 

エラーがないことを確認します。

mod_reatimeoutの設定ファイルを修正

/etc/apache2/mods-available/reqtimeout.confを管理者権限で修正します。

筆者は以下のように行いました。

-RequestReadTimeout body=10,minrate=500
+RequestReadTimeout body=20,minrate=500

具体的には、リクエストボディ(データの送信本体)の読み取り開始を待機する時間を10秒から20秒へ延長しています。

  • body=20:
  • リクエストボディの最初の1バイトを待つ時間を20秒に設定。
  • minrate=500:
  • データが送り始められた後、最低でも秒間500バイトの転送速度を要求する。これより遅い状態が続くとタイムアウトします。
  • ファイルの差分確認
diff -u /path/to/backup/directory/reqtimeout.conf.$(date +%Y%m%d) /etc/apache2/mods-available/reqtimeout.conf 

以下のような差分を確認します。

-RequestReadTimeout body=10,minrate=500
+RequestReadTimeout body=20,minrate=500

設定反映

  • 構文チェック
sudo apache2ctl configtest

Syntax OKとなることを必ず確認してください。でないと、apacheサービスが停止したままとなってしまい、サービス断が発生します。

  • Apache サービス再起動
sudo systemctl reload apache2.service
  • Apacheサービス再起動確認
systemctl status apache2.service

active(running)を確認します。

まとめ

Nextcloudサーバーにおいて、RequestReadTimeout のbody待ち時間を延長することは、「モバイル環境や大容量ファイル送信時の安定性」を向上させるために非常に有効な手段です。

もし、ログ(Apacheのerror_log)に The timeout specified has expiredrequest body read timeout といった記録が残っている場合は、この値を調整してみることをお勧めします。

  • 参考コマンド
sudo grep "request body read timeout" /var/log/apache2/error.log

2026年3月の外食記録-2-

昨日の続き、メインディッシュと言える食事群です。

鰯塩焼き

本当に鰯なのかと言うぐらいの大きさ。骨離れも良好。ワタもみっちり詰まって濃厚。身の脂ののりも言うまでもないです。

鱈の唐揚げ

フィッシュアンドチップスの定番、鱈がこうなるという例。白身がふわふわで、英国時代のものとは次元が違いました。

ポテトコロッケ

自家製という気合いの入れよう。ジャガイモを皮ごと潰した野趣あふれる風味が最高でした。

食事:手巻き

ブリの漬けを手巻きにするという技巧。のりがふやけないうちにすぐに食べる必要があったものの、これもおいしかったです。

いずれも、いい食事で心が満たされました。

2026年3月の外食記録-1-

週末、お世話になっているお店でのおいしい食事をいただきました。

刺身から始まり。この切付の時点で鮮度と腕がうかがえます。

蒸したジャガバターの上にウニをのせるという背徳的な食べ方をしたり

旬のホタルイカの酢味噌和え、

店の自作という牡蠣のオイル漬け。

この時点でも感動は極上でしたが、まだ続きがあります。

2026年3月の差しボードゲーム記録。

友人と卓を囲みました。

ロストシティ タイルズ

色を絞れたこともあり、40点差をつけての勝利。(上のタイルは計算のため順番を変えています)

真打

納涼落語会での『牡丹灯籠』に年末落語会の『芝浜』をかけることができました。

宝石の煌めき デュエル

一色10点で勝利。発展カードの偏りを読み取れたのが功を奏しました。

天下鳴動

計略カードと援軍が勝敗を形づけるゲーム。運と戦略が絡むゲームではありましたが敗北。

いい気分転換でした。

Page 1 of 286

Powered by WordPress & Theme by Anders Norén