このやり方かなり気に入っています。
これをポークソテーでもやってみました。

小麦粉で均して焼き始め。

ひっくり返してもう片面。

焼き終えてアルミホイルで包んでいるところ。

ご飯の上に載せてソースをかけた状態。
- 柔らかく焼けた
- 肉汁が流出しにくい
- パラレルで作っているので焼き上がりと同時に食べられる
等は気に入っています。
このやり方かなり気に入っています。
これをポークソテーでもやってみました。

小麦粉で均して焼き始め。

ひっくり返してもう片面。

焼き終えてアルミホイルで包んでいるところ。

ご飯の上に載せてソースをかけた状態。
等は気に入っています。
新規プレイアブルキャラクター、キロのキャラクタークエスト。
と盛りだくさん。それらの発生タイミングについて紹介です。
と、数も多め。本作のファンには刺さる内容でした。
2025/11/15にプレイを着手して諸々放置していた『ライザのアトリエ3DX』一念発起して片付けました。

プレイ時間は57時間程度。オリジナルのトロコンが70数時間だったことを考えると
の2つが極めて大きいです。
そんな中、オリジナルとの差分をいくつかメモしておきます。
オリジナルの9,999→20,000ぐらいと倍加。
一番つらかった「素材の一括処分」の手間がなくなりました。(高難易度でさっくり倒すほどコンテナは膨れ上がるので)
これもプレイ時間の短縮に一役買いました。
が終盤になるほど効きます。
プレイアブルと明言されていた
の3人のうち、ストーリーにがっつり絡むのは一人だけ。残り2人はいるだけ参戦状態だったがやや残念。
とはいえ、戦闘中の掛け合いはしっかり新録は高ポイント。それ以上に、一人はキャラクタークエストが完全新録で、オリジナルで消化不良だった部分が保管されています。
これが維持されていたので、バグではなかった仕様だったと判明。
クラウディアのキャラクタークエストで必要になっていた隠者の軟膏作りの品質縛り。
という条件が、プレイ改善パッチ適用後の
になったので、終盤で慌てることはなかったです。
他、気づいたことは逐一報告します。
こちらのクルーガークローク、その他ハイエンド装備品を作る上で欠かせない(というよりもすごく苦労する)「英雄の心得」(アタッカーレベルを上昇させる超特性)
これの入手確率を上げる方法をクリア3年目にして確立できました。
「採取レベルが上がってしまっているから」に尽きます。
この超特性、採取レベルが低いゲーム序盤ほど手に入れやすく、(スキルツリーで上がった採取レベルが高い)ゲーム終盤はファストトラベルを繰り返してもなかなか出ないものになっています。
この、「超特性の採取レベルに応じて手に入りやすい/手に入りにくい」というシステム上の仕様を今までは「回数で突破する」力技で行っていたのですが……
もっと効率的な手法を見つけました。
これが必要でした。

「生き物が採れる・優」で発現を止めた捕獲網。こちらを調合して
ランドマーク:「[参道の小洞穴](https://atelier.reisalin.com/issues/233)」へとファストトラベル。
ここでは、素材「エリキシル」を持つ黒泥が、「採取ランク2」で採ることが可能です。(ついでに、『神秘の力』を持つスピリット・モルグも採取可能

ここで採取道具を捕獲網に切り替えて採取。

今まで数十回のファストトラベルでも得られなかった「英雄の心得」が十数回で達成と大きく改善しました。

おかげでハーナルリングなどもアタッカーレベルを上昇させた上で「アルケミスト」のレベルを統一。

おかげで、ライザ3DXでも無事に1000万ダメージを再現できました。
「最上の道具が最良の道具とは限らない」というある種の鉄則を理解した形です。
「時代はIPv6」と呼ばれてから四半世紀。未だにIPv4が幅をきかせているという状態。
等の問題を抱えている運用者(つまり私)のため、「カーネルレベルでIPv4のみにする」手順のメモです。
そろそろUbuntu 26.04が出るタイミングではありますが、おそらく大幅な変化はないでしょう。
sysctlでIPv6を無効化するファイルを作成します。構築作業であれば好きなタイミングでサーバ再起動ができる環境を祝いましょう。
本番運用であればタイミングを調整する政治交渉が必要な環境を呪いましょう。
ip -6 addr
アドレスが返ってくればIPv6アドレスは有効化されています。何も表示されていなければ、ここからの作業は不要です。
cat <<- __EOF__ | sudo tee -a /etc/sysctl.d/99-disable-ipv6.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
__EOF__
元々存在しないファイルなのでコマンドで流し込みます。
sudo sysctl --system
エラーがなければOKです。
ip -6 addr
IPv6アドレスが無いことを確認します。
sudo reboot
サーバ再起動を行います。
ip -6 addr
link-local IPv6のみが見えていればOKです。(NICの中でのみ使えるv6アドレスです)
※この作業はufwをいじります。ufwを有効化しているという方は、下手にいじると自分自身がロックアウトされる怖さを知っていると思います。
慎重に、深呼吸をするなり飲み物を飲むなどして落ち着かせてから作業を行いましょう。もっと具体的に言うと
の作業を推奨します。(この場合の推奨は義務という意味です
sudo cp -pi /etc/default/ufw /path/to/backup/directory/ufw.$(date +%Y%m%d)
任意のバックアップディレクトリを指定します。
diff -u /path/to/backup/directory/ufw.$(date +%Y%m%d) /etc/default/ufw
差分が無いことを確認します。
以下のような形で修正します。
IPV6=yes
これを
#IPV6=yes
#yyyy/mm/dd IPv6無効
IPV6=no
という形です。
日付管理をしないと「万が一のことがあったときにどっからおかしくなったか」を管理しやすくなります。同様に、コメントin/outとすることで切磋の対応をしやすくします。
diff -u /path/to/backup/directory/ufw.$(date +%Y%m%d) /etc/default/ufw
-IPV6=yes
+#IPV6=yes
+#yyyy/mm/dd IPv6無効
+IPV6=no
三回ぐらい深呼吸をしましょう。
sudo ufw reload
ip -6 addr
link-local IPv6のみが見えていればOKです。
ss -lntup | grep :::
v6 のLISTENがないことを確認します。
sudo ufw status verbose
IPv6に関わるルールが無いことを確認します。
以上、「IPv6無効」と簡単に言うけれど、言うほど簡単では無いという作業でした。
筆者は『ガイアプロジェクト』では
を使っていますが、4番手でそれらが塞がれているときに時々使うのがグリーン人。
という、「ハマれば強いが簡単に潰される」という、ホームランか三振かみたいな種族。
特にQICが使えないため、目に見えるところで妨害されやすくなっています。
とはいえ、AIの難易度が低いため、なんとかしてみようと動いてみました。

勢力ボードはこちら。
鉱山は全て建てることができました。(暗黒惑星も入っています)
自力同盟は2つ。

研究はわかりやすく航法とガイアのみ。

受動パワーのマイナス点が8点程度ではありましたが、要所で強力なパワーアクション(2鉱石など)取れたこと、
そして、圧倒的な素点を稼げたことでしょうか。

最終ターン、空いている宙域に鉱山を置けなかったこと。そのせいで宙域のマジョリティを取ることができませんでした。
密集地帯でしっかり稼げる「ガイアの第三勢力」とも言えるグリーン人、癖があるけど
ラウンド中盤~終盤のラウンド行動にガイア入植があると俄然輝く勢力です。
インターネットの通信は、単にIPアドレスだけで動いているわけではありません。
その裏側には ASN(Autonomous System Number) という仕組みがあり、これが世界中のネットワークをつないでいます。
本記事では、
を順番に解説します。
ASNは:
インターネット上の「組織単位の番号」
です。
もう少し正確に言うと:
独立したネットワークを運用する組織に割り当てられる識別番号
です。
例えば:
| 組織 | ASN |
|---|---|
| Amazon AWS | AS14618 |
| AS15169 | |
| Microsoft | AS8075 |
| NTT | AS2914 |
IPアドレスが「端末の住所」だとすると、ASNは「プロバイダや企業の名前札」
のようなものです。
インターネットは巨大なネットワークですが、実態は無数のネットワーク同士の集合体です。
各プロバイダ、クラウド事業者、大学、企業はそれぞれ独立したネットワークを持っています。
この独立した単位をAutonomous System(AS)
と呼びます。そしてその識別番号が ASNです。
と考えていただくと分かりやすいでしょう。
郵便物はまず「市区町村」に届き、そこから各家庭へ配送されます。
インターネットでも:
という仕組みになっています。
ASNが本領を発揮するのは:
というルーティングプロトコルです。
BGPは「どのネットワークがどのIPを持っているか」
を世界中で共有する仕組みです。
例えば:
このIPレンジはAS14618(Amazon)が持っています
という情報を各AS同士が交換しています。
これによって世界中のルータが最適な経路を選べる
ようになります。言い換えるなら、ASNとBGPがなければ、現在の規模のインターネットは成立しません。
サーバーログを見ると攻撃IPがどこから来ているかを知りたくなりました。
そこで、ASN単位でみることにしました。
筆者が運用しているVPSはONE OUTSという独自防御システムを敷いていますが、ここでの防御は
なぜなら、多くの攻撃者は海外の規制が緩いプロバイダ/組織を隠れ蓑にしています。
(『鬼平犯科帳』で言うなら「盗人宿」の概念です。
では、そういったASNをどのように調べるのか?
Linuxでは使いやすいコマンドが存在します。
whois -h whois.cymru.com " -v 8.8.8.8"
と打ってみます。(言わずと知れたGoogleのDNSです
AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name
15169 | 8.8.8.8 | 8.8.8.0/24 | US | arin | 2023-12-28 | GOOGLE - Google LLC, US
が見えてきたという次第。これをサーバのログから調べるのはかなり困難なので、以下のようなワンライナーを組んでみました。
エラーログからIPを抽出し、一意にソートしてWHOIS情報(AS番号、国、事業者名)を取得します。
grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' /var/log/apache2/web_server_error.log \
| sort -u \
| while read ip; do
whois -h whois.cymru.com " -v $ip" | tail -n1
done
以下、無害化した解析結果テーブルです。(無害化に関してはAIの力を借りています
AS | IP | BGP Prefix | CC | Registry | Allocated | Info (Sanitized)
--------|------------------|---------------------|----|----------|------------|-------------------------------------------
58466 | 106.75.x.x | 106.75.144.0/20 | CN | apnic | 2011-03-23 | Major ISP / IDC Network (CN)
4837 | 123.139.x.x | 123.138.0.0/15 | CN | apnic | 2007-02-28 | China Network Backbone
8075 | 13.86.x.x | 13.64.0.0/11 | US | arin | 2015-03-26 | Global Cloud Service Provider (MS)
14061 | 144.126.x.x | 144.126.208.0/20 | US | arin | 2020-01-09 | Cloud Hosting / VPS Provider (DO)
212238 | 149.40.x.x | 149.40.50.0/24 | US | arin | 1992-01-28 | International Content Delivery Network
396982 | 162.216.x.x | 162.216.150.0/24 | US | arin | 2013-07-02 | Global Cloud Infrastructure (G)
51167 | 173.212.x.x | 173.212.224.0/20 | DE | ripencc | 2009-10-26 | European VPS/Dedicated Server Provider
211298 | 185.247.x.x | 185.247.137.0/24 | GB | ripencc | 2018-03-01 | Cyber Security Research Entity
213412 | 195.184.x.x | 195.184.76.0/24 | FR | ripencc | 2022-11-09 | Internet Scanning & Security Platform
398324 | 206.168.x.x | 206.168.34.0/24 | US | arin | 2022-10-26 | Global Threat Intelligence Scanner
14618 | 34.224.x.x | 34.224.0.0/12 | US | arin | 2016-09-12 | Global Cloud Services (AWS)
132203 | 43.153.x.x | 43.153.0.0/18 | SG | apnic | 1989-02-21 | Asia-Pacific Cloud Network (T)
6939 | 65.49.x.x | 65.49.0.0/17 | US | arin | 2007-10-04 | International Internet Backbone Provider
200593 | 91.202.x.x | 91.202.233.0/24 | RU | ripencc | 2008-03-03 | Eastern European Network Services
ログが数万行に及ぶ環境ではこの解析は膨大なものになります
head -50 /var/log/apache2/web_server_error.log | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' \
| sort -u \
| while read ip; do
whois -h whois.cymru.com " -v $ip" | tail -n1
done
とした方が良いでしょう。
こうして、ASNを調べることができれば、先に示した「悪辣な攻撃を行うクローラー/攻撃者が潜む盗人宿」的な事業体/ASNという、「盗人宿」ごとの対策が容易に行えます。
悪を知らぬものが悪を取り締まれるか
という「鬼平」の言葉を元にログを調べていく手法について紹介しました。
を利用中、Matomoの管理画面で
安全な SSL 接続のみで Matomo を使用することをお勧めします。 Http で安全でないアクセスを防ぐには、Matomo config / config.ini.php ファイルの General セクションに force_ssl = 1 を追加します。
と警告があったので、これに対処したときのメモです。
HTTP(暗号化されていない接続)を利用している場合、ブラウザとサーバー間の通信内容はすべてプレーンテキスト(平文)で流れます。
Matomoは管理者のログイン状態を保持するためにCookieを使用します。
近年のWebブラウザ(Chrome, Firefox, Safariなど)は、セキュリティを重視しており、HTTP接続に対して厳格な制限を設けています。
SameSite=None 属性を利用する場合、Secure 属性(=HTTPS)が必須となっています。SSLを強制しないと、Matomoのトラッキングコードが正しく動作しなかったり、ログインが維持できなかったりする不具合の原因になります。Webサイトの計測において重要な「どこから来たか」という情報(リファラ)は、「HTTPSのページからHTTPのページへ移動する際」にはセキュリティ上の理由でブラウザによって削除されることが一般的です。
もしMatomoのサーバーがHTTPで動作していると、HTTPS化されたサイトからの流入元データが取得できず、解析精度が著しく低下します。
筆者のサイトでは既に、apacheのバーチャルホスト設定で
<VirtualHost _default_:80>
ServerName hoge.example.com
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
としていますが、念には念を入れます。
「ドメインに即した証明書を取得していること」
が必要です。(設定メモ)
sudo cp -pi /path/to/matomo/config/config.ini.php /path/to/backup/directory/conf_backup/config.ini.php.$(date +%Y%m%d)
`
.confの格納場所は自分の環境に合わせます。(筆者環境/home/www-data/matomo)
diff -u /path/to/backup/directory/conf_backup/config.ini.php.$(date +%Y%m%d) /path/to/matomo/config/config.ini.php
差分が無ければバックアップ成功です。
「バックアップとオリジナルの両方があることが一発で分かるから」です。
cp -pi として、 ls -lを行うよりも確実です。
そして、この時点で差分があった場合は「これから修正するファイルを間違えた」というまたとない確認手段になります。(もしくはリアルタイムで改竄を受けているか、不思議なことが起こっているか)
/path/to/matomo/config/config.ini.phpを、任意の方法で(教義・信仰に沿ったエディタで)編集します。
[General]
セクションの下、trusted hostsあたりの直下に
force_ssl = 1
を追記して保存します。
diff -u /path/to/backup/directory/conf_backup/config.ini.php.$(date +%Y%m%d) /path/to/matomo/config/config.ini.php
以下のような結果が得られれば成功です。
[General]
salt = "UUID"
trusted_hosts[] = "Your Domain"
+force_ssl = 1
このように、diffの元と先をcpの逆にすることは、編集したところが+で表示される視覚的な安心感を生みます。
sudo apache2ctl configtest
SyntaxOKを確認します。それ以外のエラーが起きていたら、編集時に誤りがあるので確認しましょう。
systemctl status apache2.service
active(running)を確認します
sudo systemctl restart apache2.service
systemctl status apache2.service
active(runnning)を確認します
systemctl status php8.3-fpm.service
active(running)を確認します
sudo systemctl restart php8.3-fpm.service
systemctl status php8.3-fpm.service
active(runnning)を確認します
強制 SSL 接続にチェックが入っていれば設定完了です。
セルフホストでMatomoを用いている場合のcron処理を行ったときのメモです。
Matomoには、データを処理する2つの方法があります。
sudo crontab -u www-data -e
Matomoを実行しているユーザー(通常は www-data)として編集します。
ファイルの末尾に以下の1行を追加します(パスはご自身の環境に合わせて調整してください)。
5 * * * * /usr/bin/php /var/www/html/matomo/console core:archive --url=https://your-matomo-domain.com/ > /dev/null
解説: >
5: 毎時5分に実行するという意味。/usr/bin/php: PHP 8.3の実行パス。core:archive: これが「溜まったデータを集計しろ」というMatomo専用の命令です。
cronを設定しただけでは不十分です。Matomo側に「自分で集計するから、画面を開いたときに集計しなくていいよ」と教える必要があります。
php.ini で memory_limit を多めに(512Mや1Gなど)設定しておくと安心です。> /dev/null を書かずに実行して、エラーが出ないか確認することをおすすめします。その他の設定に関しては改めて述べます。
aptitude(apt)で捕まったときのメモです。
Ubuntu 24.04 で sudo aptitude update を実行した際、Phusion Passenger リポジトリに対して以下のエラーおよび警告が発生しました。
公開鍵を利用できないため、以下の署名は検証できませんでした: NO_PUBKEY D870AB033FB45BD1Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.システムが Passenger リポジトリのパッケージが真正なものであるかを確認するための公開鍵を持っていませんでした。
以前の Ubuntu で一般的だった apt-key による鍵登録を行っていましたが、Ubuntu 24.04 ではその管理方式がセキュリティ上の理由で非推奨(Deprecated)となっていたためです。
以下の手順で、鍵を新しい推奨形式(個別のキーリング管理)へ移行させました。
sudo gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --export D870AB033FB45BD1 | sudo tee /usr/share/keyrings/phusion-passenger.gpg > /dev/null
sudo apt-key del D870AB033FB45BD1
/etc/apt/sources.list.d/passenger.list 内の記述に [signed-by=/usr/share/keyrings/phusion-passenger.gpg] を追記し、特定のリポジトリと鍵を紐付けました。
→ 筆者にしては珍しく.listのバックアップを取っていませんが(切り戻しを取れるようにしていません)、これは「切り戻したところで古い鍵形式だから」です。
sudo aptitude update
でエラーがないことを確認します。
Ubuntu 22.04 以降、OSのセキュリティ設計が強化され、
「すべてのリポジトリで共通の鍵束を使う方式」から「リポジトリごとに専用の鍵を個別に指定する方式」
への完全移行が推奨されているためです。これにより、以下のメリットがあります。
Powered by WordPress & Theme by Anders Norén