月: 2026年10月 Page 1 of 3

BOSGAME E5 初期セットアップ記録 ――Ubuntu 26.04 LTS、four-mations出発準備

はじめに

シェイクスピアの悲劇を経て購入した、自宅サーバ用の小型PC、BOSGAME E5。

手元に届いた以上、いつまでも箱の中に置いておくわけにはいきません。

今回の目的地は、自室のローカルサーバ環境です。これまでLet's note CF-XZで運用していたNextcloudとAdGuard Homeを、より余裕のある環境へ移す。そのための第一歩として、まずはOSを入れ替え、SSHで管理できるところまで整えます。

導入するOSはUbuntu 26.04 LTS Desktop。

ホスト名は four-mations としました。

ここから先の作業は、まだ本番サービスの移行ではありません。まずは土台を作り、ネットワークを整え、手元の自宅NWから遠隔操作できる状態にします。

環境

項目設定内容
対象機器BOSGAME E5
CPUAMD Ryzen 3 5300U
メモリ16GB DDR4
ストレージ512GB NVMe SSD
導入OSUbuntu 26.04 LTS Desktop
ホスト名four-mations
有線インターフェースenp2s0
固定IPアドレス192.168.11.21/24
デフォルトゲートウェイ192.168.11.1
DNSサーバー192.168.11.1

さっくりとした手順

  1. Ubuntu 26.04 LTS Desktopをクリーンインストールします。
  2. システムパッケージを最新化します。
  3. OpenSSH Serverを導入し、リモート接続を確認します。
  4. 有線LANのIPアドレスを固定化します。
  5. IPアドレス、ルーティング、外部ネットワークへの疎通を検証します。

1. Windows 11 ProからUbuntuへ

1.1 ブートメディアから起動します

購入時のBOSGAME E5にはWindows 11 Proが導入されていました。

しかし、今回の用途は自室のローカルサーバです。Windows環境をそのまま使うのではなく、Ubuntuをクリーンインストールします。

Ubuntu 26.04 LTS DesktopのインストーラUSBを用意し、本体に接続します。

電源投入時に DEL を押してブートメニューを開き、USBメモリから起動します。キーは機器のファームウェア設定によって異なる場合があります。

1.2 既存のストレージを初期化します

インストーラの画面に従ってインストールを進め、インストールタイプでは「ディスクを削除してUbuntuをインストール」を選択します。

インストール先は、内蔵NVMe SSDの nvme0n1 です。

注意:この操作では既存のWindows環境と、対象ディスク上のデータが消去されます。 必要なデータが残っていないことを確認してから実行します。

1.3 ホスト名を設定します

初期アカウントの設定では、コンピュータ名を次のように指定しました。(本ブログのアイキャッチの顔になっている4パターン、5人のお姉さんたちのユニット名です)

four-mations

ユーザー名とパスワードを設定し、インストール完了後に再起動します。こうして、新しい自室サーバの土台ができました。

2. システムを最新化します

2.0 aptitudeを入れます。

これは完全に筆者の好みの問題。

sudo apt install aptitude

2.1 パッケージリストを更新します

初期起動後、ターミナルを開きます。

sudo aptitude update

2.2 インストール済みパッケージを更新します

sudo aptitude upgrade -y

OSを入れたら、まずはシステムを最新の状態に整えます。この先、SSHやネットワークの設定を行うにしても、最初に基本部分を整えておくのが順序というものです。

3. SSHで遠隔操作できるようにします

3.1 OpenSSH Serverを導入します

自室サーバとして運用する以上、毎回ディスプレイとキーボードを接続して操作するのは避けたいところです。

そこで、OpenSSH Serverを導入します。

sudo apt install -y openssh-server

3.2 SSHサービスを有効化します

sudo systemctl enable --now ssh

これで、システム起動時の自動起動と、現在のサービス起動を設定できます。

3.3 サービスの稼働状態を確認します

systemctl status ssh --no-pager

出力に Active: active (running) と表示されていれば、SSHサービスは稼働しています。

3.4 現在のIPアドレスを確認します

ip -br a

有線インターフェース enp2s0 に割り当てられているIPアドレスを確認します。

この段階ではDHCPによる自動割り当てです。実際に割り当てられたアドレスを確認し、クライアント端末から接続できる状態にします。

3.5 ローカルネットワークからSSH接続します

手元のPCなど、同じLANに接続したクライアント端末から実行します。

ssh <ユーザー名>@<現在のIPアドレス>

Windowsの場合はお好みのターミナルソフトを使ってください。

初回接続時にはホスト鍵の確認が表示される場合があります。接続先が正しいことを確認してから受け入れます。

ログインできれば、ひとまず本体にディスプレイやキーボードをつながなくても操作できるようになりました。

ここから先は、遠隔操作を基本に進められます。

4. 有線LANのIPアドレスを固定化します

4.1 固定IPを設定する前に

多くの企業や組織では、固定IPの競合や管理問題から、最初から固定IPを導入するパターンでしょうが、筆者は違います。「DHCPがリースしたIPは他のNW機器とIPが被りようがない」です。

なので、省力化を果たします。(省力化とは)ただし、ここは作業上の注意点があります。

SSH接続中にネットワーク設定を変更すると、接続が切れる可能性があります。 固定IPへの切り替え前に、現在の接続情報を控え、可能なら本体のローカルコンソールから復旧できる状態を確保しておきます。

4.2 アクティブな接続名を取得します

Ubuntu Desktopでは、NetworkManagerを利用してネットワーク接続を管理できます。

まず、有線インターフェース enp2s0 に対応するアクティブな接続名を取得します。

CON_NAME=$(nmcli -t -f DEVICE,NAME connection show --active | awk -F: '$1=="enp2s0"{print $2}')

取得した値を確認します。

echo "$CON_NAME"

Wired connection 1 や 有線接続 1 など、実際の接続名が表示されることを確認します。

何も表示されない場合は、設定を変更せず、インターフェースと接続状態を確認します。

4.3 固定IPアドレスを設定します

まず、IPアドレスを指定します。

sudo nmcli connection modify "$CON_NAME" ipv4.addresses 192.168.11.21/24

デフォルトゲートウェイを指定します。

sudo nmcli connection modify "$CON_NAME" ipv4.gateway 192.168.11.1

DNSサーバーを指定します。

sudo nmcli connection modify "$CON_NAME" ipv4.dns 192.168.11.1

IPアドレスの取得方式をDHCPから手動設定へ変更します。

sudo nmcli connection modify "$CON_NAME" ipv4.method manual

4.4 設定を反映します

接続設定を再適用します。

sudo nmcli connection up "$CON_NAME"

正常に反映されれば、Connection successfully activated などのメッセージが表示されます。

接続が切れた場合は、固定IPアドレスで再接続します。

ssh <ユーザー名>@192.168.11.21

接続できない場合は、本体のローカルコンソールからネットワーク設定を確認します。DHCPへ戻す場合は、対象の接続名を確認したうえで次の設定を適用します。

sudo nmcli connection modify "$CON_NAME" ipv4.method auto ipv4.addresses "" ipv4.gateway "" ipv4.dns ""
sudo nmcli connection up "$CON_NAME"

なお、これは対象接続のIPv4設定をDHCPへ戻す操作です。実行前に接続名が正しいことを確認します。

5. ネットワーク設定を検証します

5.1 IPアドレスとインターフェース状態を確認します

ip -br a

enp2s0 が UP となり、192.168.11.21/24 が割り当てられていることを確認します。

5.2 ルーティングテーブルを確認します

ip route

出力例は次のとおりです。

default via 192.168.11.1 dev enp2s0 proto static metric 100
192.168.11.0/24 dev enp2s0 proto kernel scope link src 192.168.11.21 metric 100

デフォルトルートが 192.168.11.1 を向き、送信元アドレスとして 192.168.11.21 が使われていることを確認します。

5.3 IPアドレスを指定して疎通を確認します

ping -c 3 1.1.1.1

応答が返れば、少なくとも指定した外部IPアドレスへの通信ができています。

ネットワーク環境によってはICMPが制限される場合もあるため、応答がない場合は、この結果だけでネットワーク全体の障害と判断しないようにします。

5.4 DNSによる名前解決を確認します

getent hosts google.com

IPアドレスが返れば、名前解決ができています。

続けて、必要に応じて次のコマンドでも確認します。

ping -c 3 google.com

こちらは名前解決に加え、相手からICMP応答が返ることも確認するものです。名前解決が成功しても、ICMPが制限されていれば応答が返らない場合があります。

おわりに

これで、BOSGAME E5の初期セットアップはひとまず完了です。

Ubuntu 26.04 LTS Desktopを導入し、ホスト名を four-mations に設定。SSHで遠隔操作できるようにし、有線LANのIPアドレスを固定化しました。

まだNextcloudもAdGuard Homeも移行していません。今回整えたのは、あくまでそのための土台です。

しかし、これで自室の新しいサーバを構築する準備が整いました。

次は、既存環境の設定やデータを確認しながら、サービスの移行と動作検証を進めていきます。

ピボット旅行2026-18『神様お願い!』

この言葉にピンと来た方は、グループ・サウンズの大御所、ザ・テンプターズの曲、あるいはそれをカバーした桃姫BAND(尾崎亜美)のタイトルを思い出すかもしれません。

しかし、筆者にとってこの言葉は、アニメ『かみちゅ!』のサブタイトルになります。

はじめに

筆者がこの旅を決めてから、プレイリストにぶち込んだ曲があります。

このタイトルにある『神様お願い!』を筆頭として、

  • 青春のいじわる
  • 野性時代
  • 時の河を越えて
  • 君に決定

そう、アニメ『かみちゅ!』のサブタイトルに使われていた曲です。

これらのサブタイトルは、1980年代のアイドルソングなどから取られています。タイトルだけを並べれば、当時の音楽に詳しい方なら別の景色が浮かぶかもしれません。

筆者の場合は、これらをAmazon Musicのプレイリストに放り込むところから、今回の旅が始まりました。

尾道を歩き、作品の舞台となった場所を訪れる。そのための準備として、まずは音楽から作品の世界に入っていくわけです。

……我ながら、ずいぶんと回りくどい準備運動です。

筆者にとっての『かみちゅ!』

以前の断章でも触れたとおり、筆者にとって尾道は、単にアニメの舞台だから訪れたい町ではありません。

そもそも、筆者が尾道という町を知り、実際にその空気を感じた後で『かみちゅ!』に出会っています。

作中では、中学生の一橋ゆりえが突然神様になってしまいます。けれども、物語の中心にあるのは、神様になったことによる壮大な冒険ばかりではありません。学校に通い、友人と過ごし、町を歩く。そんな日常の中に、神様や不思議な出来事が自然に溶け込んでいます。

この世界観が、実際に歩いた尾道の町と重なりました。

筆者にとって『かみちゅ!』は、作品を見てから舞台を訪ねたというよりも、先に五感で記憶していた町が、作品を通じてもう一度つながったような存在です。

だからこそ、今回の旅行で自転車を置いていく判断をしたのは、断腸の思いでした。自転車で尾道を走ることも、もちろんやりたかったことです。

しかし、今回あらためて確かめたかったのは、自転車で走ることそのものではありません。尾道という町を歩き、以前訪れた場所にもう一度立つことでした。

そして、せっかく尾道に来たのですから、『かみちゅ!』の聖地も巡りたい。

今回の行程では、そんな筆者にとって外せない場所を3か所回ることにしました。

尾道で確実に行ける3つの聖地

福本渡船「神様御用達」のフェリー

まずは、福本渡船です。

『かみちゅ!』に登場する来福神社は、神様がいる神社として描かれています。その神様にゆかりのある場所を巡る旅で、渡船という存在を外すわけにはいきません。

尾道の町と向島を結ぶ渡船は、単に対岸へ移動するための交通手段ではありません。海を挟んで向かい合う町の景色と、そこを日常的に行き来する人々の暮らしをつなぐ存在です。

そして福本渡船は、多くの人々に惜しまれながら、その長い運航の歴史に幕を下ろしました。

今となっては、かつてのように船に乗ることはできません。それでも、尾道の風景と暮らしを形作ってきた渡船の記憶までなくなったわけではありません。

今回の聖地巡礼では、作品に描かれた世界と、現実の尾道の町が重なる場所として、この渡船を記録に残しておきたいと思いました。

御袖天満宮

続いて、御袖天満宮です。

『かみちゅ!』に登場する来福神社。その境内のモデルとなった場所です。

作中では、主人公の一橋ゆりえが神様となり、三枝祀(みこ)の実家でもある来福神社を中心に、さまざまな出来事が展開します。

その来福神社の境内に対応するのが、ここ御袖天満宮です。

そして、この場所にはもうひとつ、映画ファンにとってもおなじみの景色があります。映画『転校生』で、人格が入れ替わる場面に登場する石段です。

ひとつの場所に、異なる作品の記憶が重なっています。

『かみちゅ!』の舞台として見るなら、神様が暮らす神社の境内。『転校生』の舞台として見るなら、物語が大きく動く石段。

実際にその場に立つことで、作品の中で見ていた景色が、現実の町の中に存在していることを確かめられます。

艮神社

そして、艮神社です。

こちらは、来福神社の拝殿に対応する聖地です。

御袖天満宮が境内のモデルであるのに対し、艮神社は拝殿のモデル。この2か所を巡ることで、作中の来福神社が、現実の尾道にある複数の場所から形作られていることが分かります。

特に印象的なのは、『かみちゅ!』のオープニングです。艮神社の社殿は、タイトルロゴと重なる場所としても知られています。

作品を見ていたときには、ひとつの神社として目に入っていた景色。しかし、実際の場所を訪ねると、境内と拝殿という異なる要素が、それぞれ別の場所に対応していることに気づきます。

御袖天満宮と艮神社。どちらか一方だけではなく、両方を訪れることで、来福神社という架空の場所を立体的に捉えられるわけです。

神様にお願いした後は

こうして、福本渡船、御袖天満宮、艮神社と、今回訪れたかった3つの場所を巡ることができました。

作品の中でひとつの場所として描かれたものが、現実の尾道では複数の場所に分かれている。その違いを確かめながら歩くのも、聖地巡礼の楽しみです。

そして、今回の筆者には、もうひとつ大事な目的がありました。

先ほど、尾道焼きというメインイベントを完食したばかりです。

神様にお願いをした後は、歩いて腹ごなし。

……とはいえ、尾道の坂道と石段を巡れば、それだけで十分に運動になってしまうのですが。

こうして筆者は、作品の記憶をたどりながら、再び尾道の町を歩いていくのでした。

PHP「php2shell」脆弱性への恒久的対応:PHP8.3-FPMを更新した際のondrej/phpの一時的退避とロールバック

前項で書いた

「php2shell」(CVE-2026-109618、CVE-2026-109619)

への恒久的対応として、PPA提供の php8.3(バージョン 8.3.35)から、Ubuntu公式の修正版(8.3.6-0ubuntu0.24.04.13)へとロールバック・パッチ適用したときの作業メモです。

概要

Ubuntu 24.04 LTS(noble)環境において、php2shell 脆弱性への対応として Ubuntu 公式セキュリティリポジトリの PHP 修正版を適用しようとしたところ、サードパーティリポジトリのパッケージが優先され、通常のパッケージ更新では修正版へ切り替わらない事象が発生しました。

原因調査の結果、ppa:ondrej/php の PHP パッケージ(8.3.35)がインストール済みかつ更新候補として選択されていることを確認しました。APTの仕様上、バージョン番号が大きいPPA版が優先されていたため、PPAをパージして Ubuntu 公式パッケージへロールバックすることでパッチ適用を完了させました。

本記事では、発生した問題、原因調査、ロールバック手順、パッチ適用確認および復旧手順を記録します。

環境

  • OS:Ubuntu 24.04 LTS(noble)
  • 対象パッケージ:PHP 8.3
  • サードパーティリポジトリ:ppa:ondrej/php
  • ロールバック先:Ubuntu 公式セキュリティリポジトリ(noble-security)
  • PHP-FPM:php8.3-fpm
  • Webサーバー:Apache
  • 発生日時:2026年10月22日 02:54 JST
  • 関連事象:PHPパッケージ更新時にPPA側で503エラーが発生。PHP更新後にPHP-FPMおよびWebサイトの動作を検証。

さっくりとした手順

  1. PHPの脆弱性対応パッケージが更新されない事象を確認します。
  2. 一時的に Ubuntu 公式セキュリティリポジトリを直接参照する設定を追加して検証します。
  3. apt-cache policy で PHP のインストール済みバージョンと候補バージョンを確認します。
  4. ppa:ondrej/php のパッケージ(8.3.35)が更新を妨げていることを特定します。
  5. ppa-purge を導入し、PHP PPAをパージして公式パッケージへロールバックします。
  6. PHPのバージョンと関連パッケージを確認します。
  7. changelog から該当の CVE 修正パッチが含まれていることを確認します。
  8. PHP-FPMとWebサーバーを再起動します。
  9. PHP-FPMのソケット、拡張モジュール、Webサイトの応答を確認します。
  10. 一時的なAPT設定を整理し、必要に応じてPPAを再登録します。

特記事項

筆者の好みでaptitudeを用いています。必要に応じてaptに切り替えてください。

1. 発生した問題と初期事象

1.1. 脆弱性パッチが適用されない

php2shell 脆弱性への対応として、Ubuntu 公式セキュリティリポジトリ(noble-security)で配信される修正版パッケージを適用しようとしました。

しかし、以下のコマンドを実行しても、期待した PHP の更新が行われませんでした。

sudo aptitude update
sudo aptitude upgrade

一時的に security.ubuntu.com を直接参照する設定を追加して検証しましたが、更新対象として認識されない状態が続きました。

1.2. PPA側の応答遅延と503エラー

パッケージ更新を試みた際、ppa:ondrej/php 側の応答が一時的に滞り、リポジトリへのアクセスで 503 Service Unavailable が発生しました。

※この事象は、運用中のWebサイトで発生したエラーではなく、PHPパッケージの取得元である外部PPAサーバー側の応答遅延に関するものです。

PPA側の修正パッケージ配信を待たずに即時保護を図るため、Ubuntu公式セキュリティリポジトリの修正版へ切り替えるべく、PPAのパージによるロールバックを実施しました。

※これは緊急的な安全確保のための対処です。記事の後半に再び ppa:ondrej/php に戻す手順も記載しています※

2. 原因調査:APTの候補バージョンを確認

2.1. apt-cache policyを実行

apt-cache policy php8.3

実際の出力結果:

php8.3:
  インストールされているバージョン: 8.3.35-1+ubuntu24.04.1+deb.sury.org+1
  候補:               8.3.35-1+ubuntu24.04.1+deb.sury.org+1
  バージョンテーブル:
 *** 8.3.35-1+ubuntu24.04.1+deb.sury.org+1 500
        500 [https://ppa.launchpadcontent.net/ondrej/php/ubuntu](https://ppa.launchpadcontent.net/ondrej/php/ubuntu) noble/main amd64 Packages
        100 /var/lib/dpkg/status
     8.3.6-0ubuntu0.24.04.13 500
        500 [http://security.ubuntu.com/ubuntu](http://security.ubuntu.com/ubuntu) noble-security/main amd64 Packages
        500 [http://archive.ubuntu.com/ubuntu](http://archive.ubuntu.com/ubuntu) noble-updates/main amd64 Packages
     8.3.6-0ubuntu0.24.04.12 500
        500 [http://security.ubuntu.com/ubuntu](http://security.ubuntu.com/ubuntu) noble-security/main amd64 Packages
        500 [http://archive.ubuntu.com/ubuntu](http://archive.ubuntu.com/ubuntu) noble-updates/main amd64 Packages
     8.3.6-0maysync1 500
        500 [http://archive.ubuntu.com/ubuntu](http://archive.ubuntu.com/ubuntu) noble/main amd64 Packages

2.2. 原因を特定

実測結果から、以下の状態を確認しました。

  • インストール済みバージョン:8.3.35-1+ubuntu24.04.1+deb.sury.org+1
  • APTの候補バージョン:同じく 8.3.35-1+ubuntu24.04.1+deb.sury.org+1
  • Ubuntu公式セキュリティ版:8.3.6-0ubuntu0.24.04.13
  • PPA版と公式版のAPT優先度:いずれも 500

PPA版と公式版のAPT優先度は同じ(500)ですが、バージョン番号の比較(8.3.35 > 8.3.6)により、APTはPPA版を「より新しい最新版」と判定し、候補として固定していました。

その結果、Ubuntu公式セキュリティリポジトリに修正版が存在していても、APTからは「古いバージョンへのダウングレード」とみなされ、通常の更新では公式版への切り替えが行われない状態になっていました。

3. PPAのパージと公式パッケージへのロールバック

3.1. ppa-purgeをインストール

sudo aptitude install -y ppa-purge

3.2. PHP PPAをパージ

sudo ppa-purge ppa:ondrej/php

PPAを無効化し、関連パッケージを一括でUbuntu公式リポジトリのバージョン(8.3.6系列)へロールバックします。
※途中でパッケージの置き換えに関する確認([Y/n])が表示されたら、Y を入力して続行します。

3.3. 公式パッケージのインストール・整合性確保

ppa-purge の依存関係解決によって本体や FPM が外れてしまうケースを防ぐため、公式リポジトリから必要な主要パッケージが揃っていることを確実にします。

sudo aptitude install -y php8.3 php8.3-cli php8.3-fpm

→ ただし、実際に必要な PHP 拡張モジュールも別途確認してください。

php -v

実行結果:

PHP 8.3.6 (cli) (built: Oct 19 2026 15:16:58) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.6, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.6, Copyright (c), by Zend Technologies

3.4. PHP関連パッケージの状態を確認

dpkg -l | grep php8.3

PHP本体、PHP-FPM、必要な拡張モジュールがすべて 8.3.6-0ubuntu0.24.04.13 に揃っていることを確認します。

3.5. 脆弱性に対応したパッチであることを確認

外部サーバーへの通信を行わず、ローカルに解凍された変更履歴から該当の CVE 修正を確認します。

zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep -C 10 "CVE-2026-109618"

確認結果:

php8.3 (8.3.6-0ubuntu0.24.04.13) noble-security; urgency=medium

  * SECURITY UPDATE: Remote RCE via state corruption issue
    - debian/patches/CVE-2026-109618_109619.patch: Avoid state corruption via
      bailout in Zend/tests/bug40770.phpt, Zend/tests/bug54268.phpt,
      Zend/tests/bug76846.phpt,
...
      tests/basic/oom_rfc1867_upload_progress.phpt,
      tests/output/oom_in_internal_output_handler.phpt.
    - CVE-2026-109618
    - CVE-2026-109619

 -- Marc Deslauriers <marc.deslauriers@ubuntu.com>  Mon, 19 Oct 2026 11:16:58 -0400

パッチ(CVE-2026-109618_109619.patch)が確実に組み込まれていることを確認できました。

4. PHP-FPMとWebサーバーの復旧

4.1. PHP-FPMを再起動

sudo systemctl restart php8.3-fpm

4.2. PHP-FPMの稼働状態を確認

sudo systemctl status php8.3-fpm --no-pager

Active: active (running) となっていることを確認します。

4.3. Apacheを再起動

sudo systemctl restart apache2

Apacheが正常に稼働していることを確認します。

5. 動作検証

5.1. PHP-FPMのソケットを確認

ls -la /run/php/php8.3-fpm.sock

ソケットファイルが存在し、WebサーバーとPHP-FPM間の通信路が正常であることを確認します。

5.2. PHPの拡張モジュールを確認

php -m

アプリケーションで必要な拡張モジュールがロードされていることを確認します(mbstring, mysqli, xml, curl 等)。

※PPA削除時に外れたモジュールがある場合は、公式リポジトリから個別に追加します。

sudo aptitude install php8.3-<module_name>

5.3. Webサイトへのアクセスを確認

curl -I [https://example.com/](https://example.com/)

HTTPレスポンスを確認し、503 Service Unavailable や 502 Bad Gateway が発生せず正常(200 OK など)に応答することを確認します。ブラウザからも主要機能の動作を検証します。

6. PPAの再有効化

6.1. PPAを継続利用する場合の再登録

将来的にPPA側の修正パッケージが配信され、PPA環境へ復帰させる場合は以下の手順で再有効化します。

sudo add-apt-repository ppa:ondrej/php
sudo aptitude update

6.2. 再登録後の候補バージョン確認

apt-cache policy php8.3

PPA側で修正版(CVE対応済みビルド)が提供されていることを確認した上でアップグレードを実施します。

apt list --upgradable 2>/dev/null | grep php8.3
sudo aptitude upgrade

まとめ

今回の事象は、Ubuntu公式セキュリティリポジトリにパッチが配信されていたにもかかわらず、ppa:ondrej/php のパッケージ(8.3.35)がバージョン数値の優先度によってAPTの更新候補を占有していたことが原因でした。

apt-cache policy で優先度と候補を正確に把握し、緊急度に応じて ppa-purge による公式版への一時ロールバックを選択したことで、即座に脆弱性を塞ぎつつサービスの正常稼働を維持することができました。

PHP「php2shell」脆弱性への緊急暫定対応:PHP-FPMのSession Upload Progress無効化(追記に恒久的対応策を記載)

更に追記 2026/10/22 4:02

修正版にアップデートしました。

追記2026/10/21 18:25

2026/10/21 18:25現在、筆者vpsでは念には念を入れてphp-fpmを暫定停止しています。

これは付け焼き刃では対処できないと判断。

sudo systemctl stop php8.3-fpm

で止めています。

概要

2026年10月21日、PHPの重大な脆弱性として報じられた「php2shell」(CVE-2026-109618、CVE-2026-109619)への暫定対応として、PHP-FPMのSession Upload Progress機能を無効化します。

本対応では、session.upload_progress.enabled を Off に設定し、PHP-FPMへ反映しますが、これは本当に緩和策でしかないようです。

2026/10/21 20:27 追記

以下、Geminiによる要約

1. 一体どういう攻撃なのか?

「細工したHTTPリクエストをWebサイトに送るだけで、外部からサーバーのOSコマンドを実行されてしまう」攻撃です。

  • 攻撃の手口:
    攻撃者がWebブラウザやツール経由で特殊なパラメータ(セッション管理やマルチパートフォームの処理に関わるリクエスト)を送信します。
  • 発生する問題:
    PHPコア(C言語で書かれたエンジン部分)内部でメモリ破壊が発生し、Webサーバーの権限で任意のプログラム(シェルなど)を遠隔実行されます。
  • 結果:
    サーバーが丸ごと乗っ取られ、ランサムウェアの設置、データ漏洩、他サイトへの踏み台攻撃などに悪用されます。

2. 大騒ぎしている理由

主に以下の4つの理由から、世界中のエンジニアやセキュリティ企業(watchTowr、各国のCERT等)が大騒ぎしています。

  1. 深刻度スコアが最大級(CVSS 9.2 〜 10.0)
    認証(ログイン)不要、事前の権限不要で、外部ネットワークから直接狙えるため、危険度が最高レベルに設定されています。
  2. 影響範囲が広すぎる
    PHP 5系から8系に至るまで非常に幅広いバージョンが影響を受け、WordPress、Laravel、EC-CUBEなど、Web上の膨大なシステムが標的になり得ます。
  3. アプリ側の改修や設定変更では防ぎきれない
    PHPスクリプト(WordPressやPHPコード自体)の書き方で防げる問題ではなく、PHPエンジンそのもののバグです。php.ini で session.upload_progress.enabled を無効化するなどの緩和策も議論されましたが、完全な遮断には至らず「パッチ適用以外に根本解決がない」と判明したためです。
  4. PoC(実証コード)がパッチ前に出回り始めた
    公式パッチの公開直前(ゼロデイ/準ゼロデイ状態)の段階で、すでに悪用を試みる検証コードや解析情報がネット上に出回り始め、攻撃の自動ボット化が危惧されたためです。

上記理由により、本設定変更は暫定的な緩和策であり、脆弱性そのものの修正を保証するものではありません。正式な修正版PHPが提供されたら、対象バージョンと修正状況を確認したうえで更新します。

また、今回の対応前にApacheのModSecurity CRSが不審なリクエストをHTTP 403で遮断したことを確認しています。WAFによる防御とPHP実行環境の対策を重ね、複数の防御層を維持します。

環境

  • OS:Ubuntu 24.04 LTS
  • Webサーバー:Apache
  • PHP:8.3
  • PHP実行方式:PHP-FPM
  • PHP-FPM設定ファイル:/etc/php/8.3/fpm/php.ini
  • 対象設定:session.upload_progress.enabled
  • 対応目的:脆弱性に対する暫定的なリスク低減

14:00の時点で実施した、さっくりとした手順

  1. PHP-FPMの現在の設定値を確認します。
  2. PHP-FPMの設定ファイルをバックアップします。
  3. session.upload_progress.enabled を Off に変更します。
  4. PHP-FPMの設定を検査します。
  5. PHP-FPMを再読み込みします。
  6. 設定値とサービスの状態を確認します。
  7. Web経由での設定反映とアップロード機能を確認します。
  8. 正式な修正版PHPの公開状況を確認し、更新します。

詳細手順

1. 現在の設定値を確認します

PHP-FPMの設定値を確認します。

sudo php-fpm8.3 -i | grep -i 'session.upload_progress.enabled'

今回の確認結果は以下のとおりでした。

session.upload_progress.enabled => On => On

設定ファイル上では該当行がコメントアウトされていました。

;session.upload_progress.enabled = On

先頭の ; はコメントを示すため、この行自体は設定として適用されません。PHPのデフォルト値が On であるため、コメントアウトされていても機能が無効化されているとは限りません。

実際の設定値を確認し、無効化が必要であることを判断します。

2. 設定ファイルをバックアップします

変更前に、PHP-FPMの設定ファイルをバックアップします。

sudo cp -a /etc/php/8.3/fpm/php.ini /etc/php/8.3/fpm/php.ini.bak-20261021

バックアップファイルが作成されたことを確認します。

ls -l /etc/php/8.3/fpm/php.ini.bak-20261021

設定変更により問題が発生した場合は、このバックアップから元の設定へ切り戻します。

3. Session Upload Progressを無効化します

設定ファイルを編集します。

sudoedit /etc/php/8.3/fpm/php.ini

以下の設定項目を探します。

;session.upload_progress.enabled = On

コメントアウトを解除するだけではなく、値を Off に変更します。

session.upload_progress.enabled = Off

同じ設定項目を重複して追加しないようにします。

変更後、差分を確認します。

sudo diff -u /etc/php/8.3/fpm/php.ini.bak-20261021 /etc/php/8.3/fpm/php.ini

意図した設定項目だけが変更されていることを確認します。

4. PHP-FPMの設定を検査します

設定ファイルの構文を検査します。

sudo php-fpm8.3 -t

正常な場合は、設定ファイルのテストに成功した旨が表示されます。

エラーが表示された場合は、PHP-FPMを再読み込みせず、設定ファイルを修正します。

5. PHP-FPMへ設定を反映します

設定検査に成功したら、PHP-FPMを再読み込みします。

sudo systemctl reload php8.3-fpm

続いてサービスの状態を確認します。

systemctl status php8.3-fpm --no-pager

サービスが正常に稼働していることを確認します。

6. 設定値を再確認します

PHP-FPMの設定値を再確認します。

sudo php-fpm8.3 -i | grep -i 'session.upload_progress.enabled'

期待する結果は以下のとおりです。

session.upload_progress.enabled => Off => Off

ただし、このコマンドは新しく起動したPHP-FPMプロセスの設定を確認するものであり、稼働中のWebリクエストが使用する設定値を直接保証するものではありません。

必要に応じて、Web経由でPHPの設定値を確認します。確認用スクリプトを公開する場合は、外部からアクセスできないように制限し、確認後は必ず削除します。

7. Webアプリケーションの動作を確認します

設定反映後、対象のWebアプリケーションが正常に動作することを確認します。

  • Webサイトの表示
  • ログインとセッション維持
  • ファイルアップロード
  • アップロード後のファイル処理
  • ApacheとPHP-FPMのエラーログ

通常のファイルアップロード自体は、この設定変更によって原則として無効になりません。ただし、PHPのSession Upload Progress機能に依存した進捗表示などには影響する可能性があります。

作業上の注意

影響範囲

session.upload_progress.enabled = Off にすると、PHPがセッションにアップロード進捗情報を記録する機能が無効になります。

通常のファイルアップロード、ログイン、セッション管理などは、この設定変更だけで通常は影響を受けません。ただし、進捗情報を利用するアプリケーションについては動作確認が必要です。

切り戻し

変更後にアプリケーションの動作不良などが発生した場合は、バックアップから設定を復元します。

sudo cp -a /etc/php/8.3/fpm/php.ini.bak-20261021 /etc/php/8.3/fpm/php.ini

復元後、設定を検査します。

sudo php-fpm8.3 -t

検査に成功したら、PHP-FPMを再読み込みします。

sudo systemctl reload php8.3-fpm

最後にサービスの状態とWebアプリケーションの動作を確認します。

なお、切り戻しによって設定値が On に戻る場合、暫定緩和策も解除されます。切り戻しは必要な場合に限り、影響とリスクを確認して実施します。

根本対策

本対応は暫定的な緩和策です。正式な修正版PHPが公開されたら、PHP公式およびUbuntuのセキュリティ情報を確認します。

Ubuntuでは修正がバックポートされる場合があるため、バージョン番号だけで判断せず、使用中のリリースに対する修正状況を確認します。

修正版が提供されたら、実際にWebアプリケーションが使用しているPHP実行環境を更新し、動作確認を実施します。

まとめ

PHPの設定ファイルで該当項目がコメントアウトされていても、機能が無効になっているとは限りません。PHPのデフォルト値が On であれば、コメントアウトされた状態でも機能は有効です。

今回の対応では、設定ファイルの記述だけで判断せず、実際の設定値を確認したうえで Off を明示し、PHP-FPMへの反映と動作確認を行います。

WAFによるリクエスト遮断、PHP実行環境の暫定対策、修正版への更新を組み合わせ、単一の防御機構に依存しない構成を維持します。

To Buy, or Not to Buy ――シェイクスピアの悲劇を経て、自宅サーバ用の小型PCを買った話

はじめに

人間は、なぜ決断に苦しむのでしょうか。

シェイクスピアの『ハムレット』と『マクベス』には、決断を前にして葛藤する二人の人物が描かれています。

考え続けることで行動できなくなるハムレット。行動の代償を理解しながらも、野心に突き動かされるマクベス。

この二人の独白を思い返していた私は、電車の中でひとつの決断を迫られていました。

自宅サーバ用の小型PCを買うか、買わざるか。

という、前置きは壮大なのに結論がしょぼい、いつもの筆者の与太話が始まります。

1. ハムレットとマクベスに学ぶ、決断のコスト

To be, or not to be

『ハムレット』第3幕第1場。あまりにも有名な独白は、こう始まります。

To be, or not to be: that is the question.

「生きるべきか、死ぬべきか。それが問題だ。」

ハムレットが考えているのは、生き続ける苦痛と、すべてを終わらせることの間にある葛藤です。

何かを選ぶことは、別の可能性を捨てることでもあります。しかも、選択した先に何があるのか、必ずしもわかっているわけではありません。

ハムレットは、苦難に耐えることと、苦難に立ち向かうことを比較します。

Whether ’tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles

「不条理な運命の投げる石や矢に耐えることが気高いのか。それとも、苦難の海に武器を取って立ち向かうことなのか。」

ここで重要なのは、行動することにも、行動しないことにも、それぞれ代償があるという点です。

何もしなければ現状が続く。行動すれば、今まで存在しなかった問題まで引き受けることになる。

これは心理学でいう接近・回避葛藤に通じます。ある選択肢に望ましい結果と望ましくない結果が同居していると、人はその選択に引き寄せられながら、同時にそこから逃れようともします。

さらにハムレットは、死後の世界について考えます。

The undiscover’d country, from whose bourn
No traveller returns

「誰ひとり帰ってきたことのない、未知の国。」

未知の国へ踏み出せば、元の場所には戻れないかもしれない。そもそも、その先に何があるのかさえわからない。

ここには、決断の不可逆性と不確実性が凝縮されています。そして独白は、思考が行動を妨げるという結論へ向かいます。

Thus conscience does make cowards of us all

「こうして思慮は、われわれを皆臆病者にしてしまう。」

考えること自体が悪いのではありません。問題は、考えるほど不安が増え、検討すべき可能性が際限なく広がり、いつまでも行動に移れなくなることです。

いわゆる分析麻痺。判断材料を集めるための思考が、判断そのものを先送りするための思考へと変わってしまうのです。

If it were done when ’tis done

一方、『マクベス』第1幕第7場の独白は、別の方向から決断の苦しみを描きます。

If it were done when ’tis done, then ’twere well
It were done quickly.

「もし、事を成し遂げた瞬間にすべてが終わるのなら、さっさとやってしまうのがよい。」

マクベスが考えているのは、ダンカン王の暗殺です。

王を殺害すれば、王位を手に入れられるかもしれない。しかし、殺害という行為が終わったからといって、その結果まで終わるわけではありません。

マクベスは、暴力が自分自身に返ってくる可能性を認識しています。

Bloody instructions, which, being taught, return
To plague th’inventor

「血塗られた教訓は、それを世に教えた者自身を苦しめるために戻ってくる。」

自ら暴力を行使すれば、その暴力が自分を脅かす世界を作り出すことにもなる。決断の結果は、実行した瞬間だけでなく、その後の人間関係や社会のあり方にまで及びます。

さらにマクベスは、自分を行動へ駆り立てるものの正体を理解しています。

I have no spur
To prick the sides of my intent, but only
Vaulting ambition

「私の決意を駆り立てる拍車はない。ただ、身の程を越えて跳ね上がる野心があるだけだ。」

彼には、王を殺さなければならない正当な理由がありません。それでも王になりたいという欲求を捨てられない。

ハムレットは、考え続けることで行動できなくなります。一方のマクベスは、行動の代償を理解しながらも、欲望によって一線を越えようとします。

両者に共通するのは、決断が単なる選択ではないという認識です。

何かを選べば、別の可能性を手放す。そして、選択によって変わった世界を完全に元へ戻せるとは限らない。

だからこそ、決断は苦しいのです。

2. それでも、私は小型PCを買うか悩んでいた

さて、ここからが本題です。

今まで自宅サーバとして使っていたのは、Let's note CF-XZ。

  • CPU:Core i5-7300
  • メモリ:8GB
  • SSD:256GB

これを使って、自室のサーバ環境を構築していました。

試しにNextcloudとAdGuard Homeを導入してみたところ、思いのほか快適だったのです。

何しろローカル運用。外部公開するサーバと比べれば、外部からの攻撃に備えるためのセキュリティ対策や運用上の手間は段違いに少なくなります。もちろん、ローカルだからといってセキュリティ対策が不要になるわけではありませんが、用途を絞った自室の環境としては、かなり具合がよかった。

ところが、使い続けるうちに、ひとつの問題が気になり始めました。

「いや、いい加減古い」

そして、もうひとつ。

「自室の単一障害点になりつつある」

Nextcloudが止まれば、ファイルへのアクセスが不便になる。AdGuard Homeが止まれば、DNSの名前解決に影響が出る。

つまり、DNSが死んだら自室環境が死ぬという恐怖。

便利な環境を作ったつもりが、その環境を支える機器が、今度は自分にとっての弱点になっていたのです。

もちろん、CF-XZはまだ動きます。使えるものをわざわざ買い替える必要があるのか。サーバ用途なら、今の性能でも十分なのではないか。

「それでもまだ動くし」

この言葉が、頭の中で繰り返されます。

一方で、古い機器を使い続けることにもリスクがあります。故障してから慌てて移行するより、余裕があるうちに次の環境を用意しておいた方がよい。

つまり、買い替えないことにもコストがある。

ハムレットなら、ここからさらに数幕分は悩んでくれそうです。

3. そして、セールがやってきた

そんな折、タイミングよく開催されたAmazonプライム感謝セール。

そこで見つけてしまったのです。

ほぼ4万円という、お手頃価格の小型PCを。

今回購入したのはこちら。

BOSGAME E5

項目仕様
OSWindows 11 Pro
CPUAMD Ryzen 3 5300U
メモリ16GB DDR4 RAM
ストレージ512GB M.2 NVMe PCIe 4.0 SSD
購入価格ほぼ4万円

CF-XZと比較すれば、メモリ容量は8GBから16GBへ、SSDは256GBから512GBへと増加。自室のサーバ用途として使うには、なかなか手頃な構成です。

もちろん、購入しただけで単一障害点の問題が解決するわけではありません。移行方法を考え、サービスを構築し、必要なら切り戻せるようにしておく必要があります。

それでも、約4万円で新しい環境を用意できるのであれば、検討する価値は十分にあります。

しかし、ここで再び、あの二人が頭の中に現れました。

ハムレットが問いかけます。

「To buy, or not to buy. 買うべきか、買わざるべきか」

マクベスが答えます。

「If it were done when ’tis done, then ’twere well it were done quickly. やってしまえば片がつくのなら、さっさとやってしまえばよい」

……いや、マクベスの場合は王を殺す話なので、PCの購入と同列に並べるのはさすがに問題がありますが。

それでも、両者の独白は頭の中で続きます。

まだ使える。けれど、古い。買い替えれば費用がかかる。買い替えなければ、故障時のリスクが残る。

買うか、買わざるか。

4. 決断を下したのは、時間だった

そんな逡巡を続けていたのは、電車の中でした。

ThinkPadを広げ、Amazonをブラウザで開き、小型PCを物色し、価格を確認し、仕様を比較する。

そして、ふと気づきました。

あと少しで、自宅の最寄り駅に着く。

このまま悩み続けるのか。それとも、もう決めてしまうのか。

ここで、ひとつの事実に思い至りました。

「こんな逡巡を繰り返すんだったら、サパッと決めるべき」

価格も、用途も、必要なスペックも、おおよその条件はそろっています。今ここでさらに悩んだところで、劇的に判断材料が増えるわけではありません。

  • ハムレットは、なおも考え続けるでしょう。
  • マクベスは、やってしまえば片がつくと言うでしょう。

そして私は、電車が最寄り駅に到着する前に決断しました。

購入。

かくして、注文を終えた私は、いつもの自宅へと帰っていったのでした。

おわりに

そして、現物が届きました。

BOSGAME E5。自宅サーバ用の小型PCです。

シェイクスピアの悲劇から、決断の不確実性、機会損失、不可逆性について考察し、最後に得られた結論は、ほぼ4万円の買い物でした。

しかし、今回の決断には、それなりの理由があります。古くなった機器を使い続けるリスクがあり、ローカル環境の利便性を実感しており、手頃な価格で次の環境を用意できる機会があった。

あとは、実際に移行して、安定して動く環境を作るだけです。

考え続けて何も始められないのも困る。勢いだけで進んで後始末に追われるのも困る。

必要な条件を確認し、許容できるコストを見積もり、決断する。そして、決断した後の問題に備える。

これが、今回の小型PC購入から得られた教訓です。

もっとも、シェイクスピアの悲劇を経て自宅サーバを増強するという結論が、果たして文学的に正しいのかはわかりません。

少なくとも、私の自宅サーバ環境は、またひとつ拡張されることになりました。

To buy, or not to buy.

今回は、買いました。しかも、こんな写真と共に

「買っちった」

ええ、決断の重さと得られたリターンなんて、しょせんはこの程度という、いつもの前置きは壮大、結論は単純というお話でした。

ピボット旅行2026-17『かならず腹はへる』

はじめに

先の章でも触れた『かならず朝は来る』。そして、それに呼応する『かならず腹はへる』。

この言葉を、今回の尾道旅行で使わない手はありませんでした。

NHKの朝ドラ『てっぱん』は、尾道と大阪を舞台にした作品です。そのテーマ曲「ひまわり」も、物語を彩る大切な一曲。そして、作品のキャッチコピーは「かならず、朝は来る かならず、腹は減る」。

先の章では「かならず、朝は来る」という言葉を取り上げました。ならば、こちらの言葉が出番を迎える場所は、もちろん食事です。

しかも、ただの食事ではありません。尾道に来たからには、どうしても食べたかったものがあります。

お好み焼き、そして尾道焼きです。

では、スタートです。

再訪の尾道焼き

今回の旅で、尾道に行く最大の目標が「この店でお好み焼き(尾道焼き)を食べる」ことでした。

これは、自転車で巡る予定を立てていた段階から変わりません。昼食、あるいは夕食はここで食べる。そのために行程を組むほどの目的地でした。

観光地を巡ることも、写真を撮ることも、もちろん旅の楽しみです。しかし、何を食べるかもまた、旅の軸になり得ます。

今回は、その軸が最初からはっきりしていました。

そもそも尾道焼きとは?

尾道焼きの大きな特徴は、砂ずり(砂肝)が入っていることです。

一般的なお好み焼きでおなじみの豚肉とは、ひと味違うパンチがあります。砂ずり特有の歯ごたえと味わいが、全体の印象をしっかり引っ張ってくれるのです。

この個性の強い具材を、ほかのトッピングとどう組み合わせるか。そこもまた、尾道焼きの楽しみです。

トッピングのマシマシ

今回選んだトッピングは、お餅と生だこ。

注文の際、女将さんからひとつご意見をいただきました。

「砂ずりの味が勝ちすぎるから、海老やアサリは尾道焼きに向かない」

なるほど、具材を足せば足すほどよいというものでもありません。主役の砂ずりを生かしつつ、どう組み合わせるかが大切なのです。

そう考えると、今回の選択は正解でした。いや、実際に食べた後の感想まで含めれば、大正解です。

焼き上げというエンターテインメント

注文が通った後、脳内のリングアナが高らかに宣言しました。

Following contest is scheduled for one meal, and is for main event of this Travel...

From Onomichi, Hiroshima, weighing 500g. "The Teppan", Onomichi Yaki!

……と。

旅のメインイベント、尾道焼きの登場です。

まず、小麦粉の生地を鉄板にのばす。そこに、これでもかとキャベツを載せ、中華麺を載せる。

そして、主役を迎える準備が整ったところで、具材が次々と投入されます。

  • イカ天
  • レンコン(このお店の特徴です)
  • 生だこ
  • 切り餅
  • そして、砂ずり

これらが鉄板の上に並び、焼き上がりを待つ。

注文してから食べるまでの時間も、ただ待っているだけではありません。目の前で少しずつ完成していく様子そのものが、ひとつのエンターテインメントなのです。

食べる前から、すでにメインイベントは始まっていました。

そして、この焼き上げの過程は、今でも目の前に浮かぶほど鮮明に思い出せます。

Here is your winner!!

夢にまで見た尾道焼き。しかも、今回の旅のメインイベントです。

このために、この時のために、食事を調整していたまであります。いよいよ実食。最高でした。

  • 砂ずりのパンチ力
  • 定番のイカ天がもたらす、脂のうまみと香ばしさ
  • 薄切りレンコンという、心憎い演出

それぞれが個性を発揮しながら、ひとつのお好み焼きとしてまとまっています。

そして、トッピングも大当たりでした。

生だこのコリコリした歯触りが、実に絶妙です。確かに、砂ずりと海老では、歯触りも味も砂ずりの存在感が勝ってしまいそうです。しかし、生だこなら歯ごたえがぶつかり合わず、違った方向から食感を加えてくれます。

何より、お餅がいい仕事をしています。ソースも、肉も、中華麺も、まとめて受け止めてくれる。具材それぞれの個性をつなぐ、頼もしい存在でした。

切り分ける。食べる。ソースやこしょう(尾道焼きならではのトッピング)を足す。そして、また食べる。

最後の一口を食べ終えたところで、「Cover!」からの3カウントフォールがしっかり決まりました。

今回の旅のメインイベント、決着です。

伝えられたお礼

会計の際、女将さんに「2年前にも伺いましたが、美味しくて感動しました」と伝えることができました。

前回の訪問で感じた感動を、今回もきちんと伝えられた。これもまた、再訪したからこその満足です。

旅先で食事をすることは、その土地のものを味わうだけではありません。もう一度来たいと思った場所に戻り、以前の体験を確かめ、そこで感じたことを伝える。そうした時間も、旅の一部なのだと思います。

そして、食事を終えた筆者には、ひとつ大きな問題が残されていました。

この食事のインパクトが激しすぎて、「次の目的地、どうしようか?」と思ったのです。

……それは、また別のお話です。

ピボット旅行2026-16『季節の逆算』

はじめに

前の投稿では、時間の逆算についてお話ししました。

残された時間を把握し、その中で何を見せるかを決める。状況が変われば、進行を調整する。

筆者が旅行中に行っていることも、構造としてはこれに近いのです。

午前11時20分という帰還時刻は固定する。その一方で、そこまでの経路や、現地でどれぐらい時間を使うかは調整できる。

しかし、今回逆算していたのは時間だけではありません。

「季節」もしっかり逆算していた、というお話です。

10:30の仮説

尾道、千光寺公園。

ここで筆者は、ブロンプトンを断念した(これは擦り続けます)長雨に、一種の希望を抱いていました。

長雨。そして、気温の低下。

この二つの条件から、ある仮説が浮かびます。

これなら、彼岸花が見つかるかもしれない。

彼岸花は、筆者の好きな花の一つです。開花の時期は気温や天候にも左右されますが、今回の長雨と気温の低下は、花を探すうえで期待できる条件でした。

もちろん、咲いているかどうかは現地に行かなければ分かりません。季節を逆算したところで、花の開花まで思いどおりになるわけではないのです。

それでも、探す理由はありました。

10:35の発見

きちんと見つけました。

場所は、天寧寺のすぐ近く。

ここで重要なのは、彼岸花を見つけたことそのものだけではありません。

今回の発見は、完全な偶然というわけではなかったのです。

  • 筆者の知っている距離感
  • 何千枚と撮ってきた彼岸花の写真
  • 経験を重ねたレンズ

これらがそろっていました。

どこまで歩けば何がありそうかという感覚があり、彼岸花をどう撮ればよいかという経験もある。そこに、季節と天候の条件が加わりました。

狙った一枚を撮るのは得意です。

特に、雨露との取り合わせは筆者の得意とするところです。

花が咲いているかどうかは、こちらでは決められません。しかし、咲いている可能性を考えて探し、見つけた花をどう撮るかについては、自分の経験を活かせます。

前回の記事で紹介した「向こう10年は撮れないであろう写真」とは、また違う話です。

あちらが予測しきれない出会いだったとすれば、こちらは、条件を読み、経験を使って狙いにいった一枚。

旅先で写真を撮るという行為にも、こうした違いがあるのです。

推し寺:天寧寺

彼岸花を見つけたあと、筆者が向かったのは天寧寺でした。

ここは尾道を訪れるたびに、確実に立ち寄っているお寺です。

特に好きなのが、釈迦堂の畳の空間。雨の中を歩いてきた身体を休めるには、ちょうどよい場所です。今回は、ここで時間を過ごす算段もつけていました。

午前11時20分には商店街へ戻りたい。千光寺公園からの移動時間を考えれば、どこかで休憩する時間も必要になります。

そこで、何度も訪れている天寧寺を組み込む。

初めて訪れる場所であれば、どれぐらい時間を使うことになるか分かりません。しかし、勝手を知っている場所なら、滞在時間も見積もりやすくなります。

時間を埋めるために、適当な場所へ立ち寄ったわけではありません。

好きな場所で休みながら、帰還時刻も守る。

これもまた、筆者なりの時間配分です。

「ワークか、ケーフェイか」

ここで、釈迦堂の写真についても触れておきましょう。

筆者がこの場所で撮る写真には、もう一つの役割があります。

それは、レンズキャップ代わりに使う写真であること。

2024年の尾道旅行でも、同じ構図で撮影しています。今回も、そこで撮った写真をしっかりと再現しました。

もちろん、まったく同じ場所で撮れば、まったく同じ写真になるわけではありません。光の入り方も、天候も、そのときの空間の雰囲気も異なります。

それでも、同じ構図を再現できるということは、撮影する場所やカメラの向き、画面に何を収めるかを把握しているということです。

そして、ここで思い出すのが、プロレスにおける「ケーフェイ」という概念です。

ケーフェイとは、プロレスの演出や舞台裏に関わる事柄を、観客に対してどのように扱うかという慣習や考え方を指します。プロレスを楽しむうえでは、見せるものと見せないもの、その境界もまた重要な要素になります。

では、筆者が同じ構図を再現していることは、ワークなのか、ケーフェイなのか。

……という話を始めると、また長くなりそうなので、ここでは写真の話に戻りましょう。

今回の写真は、偶然そこにカメラを向けた結果ではありません。以前に撮った構図を覚えていて、今回も同じように撮影できる。つまり、意図して再現できる写真なのです。

一方で、写真に写る雨の日の空気や、その場で過ごした時間まで、完全に再現できるわけではありません。

同じ場所、同じ構図でも、そこに至るまでのストーリーは毎回違います。

雨音での休憩

釈迦堂で過ごす時間は、単に雨を避けるためだけのものではありませんでした。

降り続ける雨の音を聞きながら、ここまでの道のりを思い返す。

そして、思い出ノートに記帳する。

旅先で見たもの、歩いた場所、そのときに考えたこと。そうした記録を残す時間も、筆者にとっては旅の一部です。

外を歩き続けていれば、次々と新しい景色に出会えます。しかし、立ち止まって振り返ることで、歩いてきた時間そのものを記録に変えることもできます。

今回は、雨がそのための時間を作ってくれました。

もちろん、最初から「ここで雨音を聞きながらノートを書こう」と決めていたわけではありません。

それでも、休憩できる場所を知っていて、戻る時刻から逆算して行動していたからこそ、こうした時間を確保できたのです。

11:15、再び商店街へ

そして、再び商店街へ。

時計を見ると、午前11時15分。

お昼を食べるために戻ってくる予定だった時刻は、午前11時20分です。

午前9時に始まり、午前11時20分に終える。

その時間計算は、極めてちょうどよく収まりました。

彼岸花を見つけ、推し寺で休憩し、写真を撮り、思い出ノートに記帳する。これだけのことをしながら、予定していた時刻に戻ってこられたのです。

もちろん、すべてが計算どおりだったわけではありません。彼岸花が咲いていたことも、雨の中でどんな景色に出会うかも、完全には予測できません。

しかし、時間の枠を決め、知っている場所を活用し、季節と天候から可能性を考えることはできました。

時間を逆算し、季節を読み、経験を使って動く。

今回の尾道で筆者がやっていたのは、そういうことだったのです。

さて、ようやくお昼ご飯です。

ここから先にも、まだ尾道での出来事が続きます。

GROWI 8.0のAI AgentにGeminiを組み込む:月10ドルの特典を活用してみる(初回課金あり。結果は要観察)

Google One AI Proに付帯する、月10ドル相当のGoogle Cloudクレジット。

これを何かに使えないかと考えていたところ、自前でホスティングしているWiki「GROWI」のAI Agentと組み合わせることを思いつきました。

GROWIのAI Agentは、Wiki内の複数ページを横断して検索し、得られた情報をもとに回答を生成してくれる機能です。これが実用になるなら、過去に蓄積したナレッジを探し出す手間を減らせます。

そして、手元には毎月付与されるGoogle Cloudクレジットがある。

ならば、これを活用しない手はありません。

実際に設定してみたところ、GROWIからGemini APIを呼び出し、Wiki内の情報を横断検索して回答を生成するところまでは確認できました。

ただし、ここで一つ注意点があります。

AI Agentが動いたことと、月10ドルの特典だけで運用できていることは、別の話です。

今回は、そこに至るまでの設定手順と、実際に課金される金額について、今後も確認していく必要がある点をまとめます。

例によって前置きは長いです。

1. 取り組もうとしたきっかけ:WikiのナレッジをAIから引き出したい

GROWIのAI Agentは、Wikiに蓄積された情報を横断して調べる用途に向いています。

例えば、過去の旅行記や技術メモを複数ページにわたって検索し、その内容をまとめさせる、といった使い方です。

人間がページ名を思い出し、検索語を考え、一つずつ開いていく手間を考えると、かなり魅力的な機能です。

一方、Gemini APIを無料枠のまま利用しようとすると、レート制限に引っかかることがあります。

特に、複数ページの検索や要約など、一つの質問に対して複数回のAPI呼び出しが発生する処理では、無料枠の制限がボトルネックになる可能性があります。

そこで、従量課金側の利用設定を行い、Google Cloudのクレジットを活用できないか試してみることにしました。

月10ドル相当のクレジットが利用でき、実際のAPI利用料がその範囲に収まるのであれば、個人運用のWikiとしては十分に魅力的です。

ただし、これはあくまで期待値の話。

利用料が月10ドル以内に収まることと、その利用料に特典クレジットが適用されることは、それぞれ確認しなければなりません。

この二つを一緒にしてしまうと、後から請求額を見て慌てることになります。

2. 最初の関門:APIは呼び出せるのに、前払い残高がない

Google Cloud側で請求先アカウントを用意し、Google AI StudioでAPIキーを発行。GROWI側にも設定を入れて、いざ動作確認。

ところが、次のエラーが返ってきました。

Your prepayment credits are depleted. Please go to AI Studio at ... to manage your project and billing.

メッセージの内容は、事前入金したクレジットが枯渇している、というものです。

ここで問題になったのが、Google Cloud側にクレジットがあることと、Google AI Studio側でGemini APIを利用できる状態になっていることが、必ずしも同じではないという点でした。

今回の環境では、AI Studio側で前払い残高を購入する操作が必要になりました。

ただし、ここで注意したいのは、前払い残高を購入すれば、その金額がそのまま保証金として残り、APIの利用料は必ずGoogle Cloudの特典から優先的に引き落とされる、とまでは確認できていないことです。

請求先アカウントにクレジットが表示されていることだけでは、実際のAPI利用料にどのクレジットが適用されるかまでは判断できません。

このあたりは、設定画面の表示だけで安心せず、実際の利用明細と残高の推移を追う必要があります。

3. 作業前に確認しておくこと

今回の作業では、次の点に注意しました。

  • Google Cloudの請求先アカウントと、支払い方法の設定が必要になる。
  • Google AI Studio側で、前払い残高の購入を求められる場合がある。
  • Google Cloudのプロモーションクレジットと、AI Studio側の前払い残高は、同じものとして扱わない。
  • クレジットが付与されていることと、そのクレジットが実際のAPI利用料に適用されることは別途確認する。
  • Google側の料金体系、クレジットの適用条件、画面表示は変更される可能性がある。

なお、今回の手順は、筆者の環境で動作確認できた構成をもとにしたものです。

APIが正常に動くところまでは確認していますが、最終的な請求額とクレジットの消費順序については、引き続き経過観察が必要です。

「月10ドルの特典があるから大丈夫」と考えて作業を進めるのではなく、課金の仕組みを確認しながら利用することを前提にしています。

4. 今回の環境

項目設定
WikiGROWI v8.0.7
実行環境Node.js 24 / pnpm / Docker不使用
AI基盤Google AI Studio / Gemini API
クレジットGoogle Developer Programの月10ドル相当の特典
モデルGemini APIで利用可能なFlash系モデル

モデル名については、実際にAI Studioのモデル一覧に表示され、利用可能なものを選択してください。モデルの提供状況や名称は変更されるため、特定のモデル名を固定して手順を進めるのは避けたほうがよさそうです。

5. さっくりとしているがすんなりはいかない設定手順

Step 1. Google Cloudの請求先アカウントを用意する

まず、Google Cloud側の請求先アカウントを用意します。

  1. Google Cloud Console にアクセスする。
  2. 「お支払い」から請求先アカウントを作成、または既存のアカウントを確認する。
  3. 必要に応じて支払い方法を登録する。
  4. Google Developer Programの特典ページ にアクセスする。
  5. 月10ドル相当の生成AI・Cloudクレジットの特典が利用可能であれば、案内に従って請求先アカウントに適用する。
  6. Google Cloud Consoleのクレジット画面で、特典の適用状況と有効期限を確認する。

ここで確認したいのは、単に特典の申し込みが完了していることではありません。

実際にどの請求先アカウントに、どの種類のクレジットが、いつまで有効なものとして付与されているかです。

後から利用明細を確認するときにも必要になるため、この時点で記録しておくとよいでしょう。

Step 2. Google AI StudioでAPIキーを発行する

続いて、Gemini APIを利用するためのAPIキーを用意します。

  1. Google AI StudioのAPIキー管理画面 を開く。
  2. 必要に応じてプロジェクトを作成する。
  3. APIキーを発行する。
  4. 対象プロジェクトの請求設定と利用可能な課金階層を確認する。
  5. APIキーを安全な場所に保管する。

課金設定については、画面上の案内に従ってください。

なお、APIキーを発行できたことだけでは、課金設定が完了していることや、特典クレジットが利用料に適用されることまでは確認できません。

Step 3. AI Studio側の前払い設定を確認する

今回、実際にエラーの解消に関係したのがこの部分です。

Google AI StudioのBilling画面を開き、前払い残高と購入に関する表示を確認します。

Google AI Studio Billing

今回の環境では、前払い残高の購入が必要でした。

ただし、購入金額や購入が必要となる条件は、画面上の案内と利用環境に従ってください。最低購入額を含め、すべての環境で同じ条件になるとは限りません。

そして、ここが今回の重要なポイントです。

前払い残高を購入した場合は、その金額がどのように扱われるのかを確認してから利用を続けてください。

前払い残高が表示されていることだけを根拠に、追加の持ち出しが発生しないとは判断できません。

Google Cloud側の特典残高、AI Studio側の前払い残高、APIの利用明細をそれぞれ確認し、実際の利用料がどこに計上されるのかを追う必要があります。

Step 4. GROWIのAI設定を行う

ここからはGROWI側の設定です。

  1. GROWIに管理者アカウントでログインする。
  2. /admin/ai を開く。
  3. AI機能を有効にする。
  4. プロバイダーとしてGoogleを選択する。
  5. 発行したGemini APIキーを設定して保存する。
  6. モデルカタログを更新する。
  7. 利用可能なモデルから、使用するFlash系モデルを選択して保存する。

画面の項目名や利用できるモデルは、GROWIのバージョンやGemini API側の変更によって異なる場合があります。

モデル一覧が更新できない場合は、APIキーや課金設定、利用可能なモデルを順番に確認してください。

Step 5. AI AgentからWiki内の情報を検索する

設定が完了したら、GROWIの通常画面に戻り、AI Agentに質問してみます。

例えば、次のような質問です。

「ピボット旅行」と名付けられた記事一覧から、
なぜそう名づけたのかを要約してください。

今回の環境では、AI AgentがWiki内の複数ページを参照し、それらの内容を踏まえた回答を生成するところまで確認できました。

これは、今回の設定で得られた成果です。

単にGemini APIに接続できただけではなく、GROWIに蓄積された情報を検索し、その結果を使って回答を生成するという、本来やりたかった動作が成立しました。

一方で、この動作確認によって分かるのは、あくまでAI Agentが機能しているということです。

利用料が特典クレジットから差し引かれているのか、前払い残高がどのように消費されるのか、最終的な請求額がいくらになるのかは、別途確認する必要があります。

6. ここからが本当の経過観察

今回の設定で、GROWI AI AgentとGemini APIの連携自体は成立しました。

しかし、これで「月10ドルの特典を使って、実質無料で運用できる環境が完成した」と結論づけるのは、まだ早いと考えています。

今後、確認したいのは次の点です。

  • Google Cloud側の特典クレジットが、実際のAPI利用料に適用されているか。
  • AI Studio側の前払い残高が、どのタイミングで、どのように変化するか。
  • API利用料がどの請求項目に計上されるか。
  • 一定期間利用した後、実際に追加の支払いが発生していないか。
  • 月10ドル相当の特典の有効期限や適用条件に変更がないか。

特に重要なのは、設定直後の残高表示だけで判断しないことです。

利用直後には明細への反映に時間がかかる場合もあるため、利用記録と請求情報を継続して確認する必要があります。

また、今回のように前払い残高を購入する仕組みでは、購入した金額と、最終的に消費された金額を分けて考えなければなりません。

「残高がある」「特典が付与されている」「APIが動いている」。

この三つがそろっていても、最終的な支払いがゼロになるとは限りません。

実際にいくら課金されるかは、別問題です。

ここは、しばらく利用実績を追ってから判断することにします。

7. まとめ:便利な環境はできた。あとは請求を確認する

今回、GROWI 8.0.7のAI AgentにGemini APIを組み込み、Wiki内の複数ページを横断検索して回答を生成するところまで確認できました。

蓄積したナレッジを、ページ名や検索語を思い出すことなく引き出せるようになるのは、個人運用のWikiとしても大きな利点です。

毎月付与されるGoogle Cloudクレジットを活用できるなら、なおさら魅力的な構成になります。

ただし、現時点で確認できているのは、連携と動作の成功までです。

月10ドル相当の特典が実際の利用料にどのように適用されるのか、前払い残高がどう扱われるのか、最終的に追加の請求が発生するのか。

このあたりは、実際の利用明細を見ながら確認していく必要があります。

便利だからといって、課金の仕組みまで都合よく解釈してはいけません。

ひとまず、GROWI AI Agentを使える環境は整いました。

あとは、実際に使いながら請求の推移を観察していきます。

ピボット旅行2026-15『かならず朝は来る』

はじめに

「かならず朝は来る」

この言葉は、朝ドラ『てっぱん』のキャッチフレーズであり、総集編でも語られていた言葉です。

そして、もうひとつ。

「かならず腹はへる」

このふたつの言葉を、筆者は「どんなことがあっても、生きている限り時は進むし、生命活動は続く」という意味で受け取っています。

何があっても朝は来る。お腹もすく。昨日と同じように見える日常も、少しずつ先へ進んでいく。

今回の旅行を待つ間も、朝が来るたびに「旅行がまた近づいた」と思っていました。

そして、ようやく、またこの地を踏む日がやって来ました。

千光寺と千光寺公園

尾道になぜ惹かれるのかについては、先述したとおりです。

その中でも別格と言えるのが、千光寺と千光寺公園からの眺望。筆者の好きな景色を、これでもかというほど詰め込んだような場所です。

ここは、筆者にとっての尾道の原風景とも言える場所です。

瀬戸内の海と島々、街並み、山の斜面に連なる家々。そうした景色をひとつの眺望として見渡せることが、何度訪れても心に残ります。

そして今回は、前項で触れた雨の気配も連れて、この景色を見に来ました。

やって来た朝

では、写真のご紹介と行きましょう。

朝ドラ『てっぱん』でも出てきたポンポン石。

空が灰色でもしっかりと分かる島々。そして造船ドッグの工業美。

尾道のロープウェイ。

そして、千光寺後援を後にします。

ピボット旅行-断章『That’s not a Prediction, that’s a SPOILER!』

はじめに

「That's not a Prediction, that's a SPOILER!」
「それは予測ではない。ネタバレだ!」

この言葉を聞いて、プロレスファン、とりわけWWEを見ている方なら、ポール・ヘイマンの顔を思い浮かべるでしょう。

ポール・ヘイマン。1990年代にECWを率いてWWF(現WWE)、WCWと熾烈な視聴率争いを演じ、現WWEではブロック・レスナーをはじめとする数々の大物レスラーのマネージャーを務めてきた人物です。

彼の武器は、リング上での格闘技術ではなく、マイク一本で状況を支配する話術にあります。

自分の担当するレスラーがいかに強いのか。対戦相手がいかに無謀なことをしようとしているのか。そして、これから何が起きるのか。ヘイマンは、試合が始まる前からそれを観客に叩き込みます。

「うちの選手が勝つでしょう」などという、曖昧な予想ではありません。勝つことは決まっている。あとは、現実がその結末に追いつくのを待つだけ。

だから、これは予測ではありません。ネタバレなのです。

私は、この食えない言い回しが好きです。

もちろん、人格者として尊敬しているとか、人生の師にしたいとか、そういう話ではありません。言葉巧みに相手を追い込み、逃げ道を塞ぎ、最後には「だから言ったでしょう?」とでも言いたげな顔をする。あの悪徳参謀じみた立ち回りがギミックとして最高に好きです。

プロレスは、リングの上だけで完結するものではありません。試合前の宣言も、選手同士の対立も、勝敗が決した後の反応も含めて、一つの物語を形作っています。

ヘイマンは、その物語を語るだけでなく、ときには結末を先に宣言することで、観客にその瞬間を見届けさせるのです。

さて。

そんな言葉が、今回の旅で私の脳内に響くことになりました。場所は尾道、千光寺です。

千光寺にて

千光寺を参詣の折、風鈴の音が聞こえました。音のする方に目を向けると、そこには色とりどりの風鈴が並んでいました。

片手には傘。もう片方の手には、iPhone Air。

特別に写真を撮るつもりで構えていたわけではありません。風鈴の音が聞こえたので、スマートフォンを掲げ、シャッターを切りました。

それだけです。

画面を見て構図を吟味したわけでも、露出を調整したわけでもありません。片手は傘で塞がっていますから、両手でしっかりと構えることもできません。

いわば、ノールック撮影です。そのシャッターを切った途端、この言葉が響き渡りました。プレビューを見る前から、です。

「That's not a Prediction, that's a SPOILER!」
「それは予測ではない。ネタバレだ!」

一枚だけ

今回、掲載する写真は一枚だけです。

※個人情報につながる部分のみAIで消去しています

風鈴のガラスに映る光。色とりどりの短冊。奥へと続く風鈴の列。そして、手前に大きく写り込んだ風鈴。

きっちりと構図を整えた写真ではありません。むしろ、手前の風鈴が視界を遮り、短冊が重なり合い、画面の中には少々雑然とした印象すらあります。

風鈴を一つずつきれいに見せるのではなく、風鈴が並ぶ場所そのものを切り取ったような一枚になっています。写真を撮るために立ち止まったというより、風鈴の音に気づいたときの景色が、そのまま残っているような形で撮れました。

もちろん、毎回こんな写真が撮れるわけではありません。狙って再現できるものでもありません。

ネトフリのドキュメンタリー『WWE:UNREAL』でスーパースター、チェルシー・グリーンがペンタとのインタージェンダー・マッチを行ったときの言葉の方がより適切です。

「もう一度やれって言われてもムリ。完璧なものは再現できない」

まさにそんな形です。シャッターを切った後に、向こう10年は撮れないであろう写真が、そこにありました。

更にお気づきの通り、弊ブログの新たなヘッダーがこの画像です。

「よし、ヘッダーゲット!」と言うより先に脳内の悪徳参謀は、早くも勝利を宣言していたのです。

なので、改めて宣言します。

Ladies and Gentlemen! This picture is the Banner of My WordPress!

Page 1 of 3

次

Powered by WordPress & Theme by Anders Norén