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!

ピボット旅行2026-14『なぜ筆者はゴリラルームと相性がよかったのか?』

今回、尾道での行動がうまく組み上がったのには、もう一つ理由があります。

筆者には、昔から妙な特技があります。

タイムコントロールが異様に得意なのです。

目的地までどうやって時間を過ごすか。そこまで歩くのに何分かかり、現地でどれぐらい滞在できるのか。そうした見積もりと実際の所要時間が、妙によく合います。

そのため、電車の待ち時間を単に過ごすだけではなく「ここまで楽しめる」も成立します。

もちろん、時計を見ずに何でも正確に当てられるという話ではありません。移動経路や目的地でやりたいことを把握したうえで、必要な時間を割り振り、実際の行動に合わせて調整する。これが、筆者はどうも得意らしいのです。

そして、この能力がゴリラルームの考え方と非常に相性がよかったというお話しです。

残された時間から逆算する

今回の尾道では、『パン屋行路』で買ったパンを商店街のベンチで食べ終えた時点で午前9時。そして、お昼のために午前11時20分には、もう一度この場所へ戻ってきたい。

つまり、使える時間は約2時間20分です。では、その時間で何をするか。

ここで筆者が選んだのは、千光寺公園まで徒歩で向かうことでした。

ロープウェイを利用すれば、山頂まで一気に移動できます。いわば垂直方向のショートカットです。しかし、駅から乗り場まで移動し、乗車を待ち、山頂から目的地へ歩くことまで考えると、必ずしも水平移動を含めた全体の時間が短くなるとは限りません。

垂直方向のショートカットは、必ずしも水平移動のショートカットではない。

これが今回の判断です。

徒歩であれば、自分のペースで進みながら、尾道の街を歩く時間そのものも楽しめます。目的地に着くためだけの移動ではなく、その過程も旅行の一部にできるわけです。

体調と体力も、計算に入れる

筆者が移動時間を見積もるとき、考慮するのは地図上の距離だけではありません。

その日の体調と体力で、どれぐらい動けるのか。

これも判断材料になります。ただし、ここには条件があります。初めて訪れる場所ではなく、何度も歩いたことのある場所であること。

既知のコースであれば、どこに坂があり、どこで足を止めたくなり、どれぐらい歩けば目的地に着くのか、おおよその感覚が身についています。そこに、その日の体調や体力を加味すれば、実行可能な移動時間を見積もりやすくなります。

さらに、逆算して「どこまで歩けるか」を考えることもできます。

午前11時20分には戻りたい。ならば、往復の移動時間を確保する。途中で見る場所や写真を撮る時間も必要になる。そうすると、どこまで進めるのか、どこで折り返すべきなのかが見えてきます。

単に「行けるところまで行く」のではなく、帰ってくる時刻から逆算して、行動できる範囲を決めるのです。

もちろん、これは何度も歩いた場所だからこそ成立する見積もりです。知らない道や、予想外の勾配、足元の状況まで正確に計算できるわけではありません。

今回は、何度も歩いている千光寺公園までのコースが頭に入っていました。あとは、そこに新しい変数を加えればよかったのです。

それが「雨の歩きづらさ」でした。

既知のコースに「雨」という変数を加える

晴天時なら、この道を歩くのにどれぐらい時間がかかるか。雨天なら、足元に注意するぶん、どの程度余裕を見込むべきか。現地で何を見て、どこまで回れば、午前11時20分に戻ってこられるか。

頭の中で、そうした条件を加えながら行動をシミュレーションしていきます。

もちろん、雨の影響を秒単位で計算できるわけではありません。しかし、コースそのものを知っているからこそ、普段との違いを考慮して、現実的な時間配分を組み立てられます。

知らない道を手探りで進むのと、知っている道に新しい条件を加えて歩くのとでは、必要な判断の量が違います。

そして、ここまで組み立ててしまえば、あとは現場で状況を見ながら進めばいい。

ゴリラルームがやっていること

WWEのゴリラルームも、決められた放映時間の中で番組を成立させなければなりません。

試合を盛り上げたい。選手の見せ場も作りたい。しかし、CMや次の番組進行や思わぬアクシデントの兼ね合いがあるため、好きなだけ時間を使うわけにはいきません。

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

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

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

「『時間』は守る 時間の『中身を充実させる』 『両方』やらなくっちゃあならないってのが旅人の辛いところだな……」

という感じです。その覚悟を決めるために脳内ゴリラルームが機能したのだと思います。

そもそも筆者は、旅行中に時間を見積もり、体調と体力を加味し、配分し、必要に応じて組み直すことを普段から行っていました。ゴリラルームという概念は、まったく新しい能力を授けてくれたのではありません。

すでに使っていた能力に、判断を組み立てるための名前と場所を与えてくれた。

雨で自転車を諦めたことも、朝食を買いそびれたことも、単なる予定変更では終わりません。(もちろん、前者に関しては大いなる苦渋の決断がありました)

再掲すると午前9時。お昼まで約2時間20分。目的地までの道は知っている。自分の体力も、おおよそ分かっている。ただし、今日は雨。

この条件から千光寺公園までの徒歩移動を選んだ時点で、筆者の脳内では、すでに次のストーリーラインが走り始めていたのでした。

尾道、こんなに歩きやすかったんだ

千光寺公園まで続く急な石段を登っている最中、筆者は妙なことを思いました。

「尾道、こんなに歩きやすかったんだ」

尾道には何度も来ています。千光寺周辺も歩いています。しかし、これまでの記憶を振り返ると、夏の盛りや残暑の厳しい時期に歩いていたことが多かったのです。

暑さそのものが体力を奪い、坂や石段を登るだけでも一苦労。しまなみ海道を自転車で走ったあとに尾道へ到着していたこともありました。町歩きの前に、すでに相応の疲労を抱えていたわけです。

ところが、今回は違いました。

  • 暑さによるデバフがない。
  • しまなみ海道を走ったあとの疲弊もない。
  • 雨には注意が必要ですが、気温の面では歩きやすい。

同じ町、同じ坂、同じ石段なのに、体の感じ方がまるで違うのです。

これまでの筆者は、尾道という町そのものを歩きにくい場所だと考えていたわけではありません。それでも、過去に歩いたときの体験が積み重なれば、その印象が基準になります。

しかし、その印象には、夏の暑さや自転車で走ったあとの疲労という条件が混ざっていました。

その条件が取り除かれたことで、初めて気づくことがあったのです。

尾道は、こんなにも歩くこと自体が気持ちいい町だったのか。

時間を逆算し、体力を見積もり、既知のコースを進んでいたはずが、そこで得たのは予定表には書き込めない発見でした。

そして、千光寺で待っていたのは、さらに別の出来事です。

向こう10年は撮れないであろう写真に出くわした。

時間を管理していたからこそ、そこまで歩いてくることができた。しかし、その時間を使って何に出会うかまでは、事前に決められません。

この、特別な一枚については次のエントリーで紹介できるでしょう。

ピボット旅行2026-13『脳内ゴリラルームのストーリー構築:パン屋行路』

はじめに

過日の投稿にて「脳内ゴリラルーム」を設置していると書きました。急ごしらえではありますが、今回の旅行、この概念を手に入れてから正解の目が多くなりました。

これを知ったのはNetflixのドキュメンタリー『WWE:UNREAL』から。

概要

そもそもゴリラルームとは? サクッとこんな感じです。

WWEにおける「ゴリラルーム(ゴリラ・ポジション / Gorilla Position)」とは、選手が入場ステージ(カーテン裏)へ向かう直前にある、試合・番組全体の指揮を執るバックステージの司令部(副調整室)のことです。

主な役割と特徴

  1. 番組進行のコントロール(司令塔)

モニター群やヘッドセットマイクが配置されており、最高責任者(長年指揮をとったビンス・マクマホンや、現在のトリプルHなど)やプロデューサー(ブッカー)陣が座り、番組の進行状況をリアルタイムで監視・指示します。

レフェリーのイヤホンへ指示を出したり、実況陣へコメントを指示したり、試合時間や展開の調整を行っています。

  1. 選手の最終準備と出撃の場

選手たちがリングに入場する直前に待機し、気持ちを整えたり、出番直前にプロデューサーから最終確認を受ける場所です。

  1. 試合直後のフィードバック

試合を終えてステージ奥へと戻ってきた選手を責任者や同僚が出迎え、パフォーマンスの評価や労いの言葉をかける場所でもあります。

これの面白い点として

  • RAW
  • SmackDown

の毎週の興行だけでなく

  • WrestleMania
  • SummerSlum
  • RoyalRumble

を含めた全てで「同じ広さ、同じ調度品、同じ色彩」で統一されているためバックステージとリング(花道)のレスラー達のスイッチのオフオンの場としても役立っているという点です。

なぜこれが必要だったのか?

予定外の出来事に直面したとき、毎回ゼロから考え直すのは大変です。

そこで、脳内にゴリラルームという概念を設けることで、潜在意識が判断のための場所を持てるようになりました。

予定が崩れたとき、意識的に考えるより先に「こう動けばいいのでは?」という選択肢が浮かんでくる。もちろん、必要に応じて意識的に考え直すこともできます。

今回の旅行で、その働きを実感しました。予定外の出来事を単なる失敗で終わらせず、次の展開へつなげる。脳内ゴリラルームは、そんな判断を助けてくれました。

ということで、今回の前置きからの旅行記、スタートです。

非情なる雨

筆者は旅における天候の運勢には自負があります。なので、「晴れてよかった」という心境ではなく

「この場にいる皆様は運がいい。この私の天候運に与れるのだから」

ぐらいの勢い。今回の旅も本来は「特急いしづちで今治まで輪行し、高速船を利用してしまなみ海道をある程度ショートカットしてサイクリングする」が予定でした。

なので、秋雨前線が停滞するという天気予報についても

「いや…… そんなはずはない」

でしたし、輪行を諦めたときも本当に涙を呑んだので。なので、2026年9月26日が雨という予報は確実だったとしても「雨雲が逸れるのでは」は朝、起きるまで確信していましたが……

「雨音で目が覚める」

時点で完全にお察し案件でした。そこで、本旅行記のテーマでもある「ピボット」が役に立ちます。雨天決行は本意ではありません。

「じゃあ、雨ならではの尾道の魅力を確かめろ」

と、早速、脳内のゴリラルームの面々がシナリオを練り始め、寝ぼけ眼で行動開始です。

「近さ故の難点」

不幸中の幸い、この雨を救ってくれたのは宿の立地。「高松駅までほぼ濡れずに行ける」という点です。

なので、その交通手段は心配していません。そしてルートも分かっています。瀬戸内海を突っ切り、岡山と広島の海岸線を真西に進みます。今回の尾道でやりたいことを鑑みても、朝6時頃に出立する必要がありました。

で、ここに一つ油断が生まれます。「実質的な駅ビルのホテルなのだから、駅に向かうのはギリギリでOK」という油断です。なまじっか出発できる時間を知っていたために「ホームにマリンライナーが入線する」というタイミングまで粘り、出立。

その結果「高松駅近くで朝食を買う」オプションが消えました。更に、乗り換えの岡山駅から尾道に接続する路線への乗り換え時間も短い。

脳内シナリオライターの指示

電車は8時台には尾道に到着します。お昼の予定を11時30分に取ると見積もったとしても結構なお時間です。何を食べようか? 思っていたときに件のシナリオライターが指示を出します。

「2024年の尾道、パン屋に寄ったよな? そこは朝からやっているのでは?」

そう、ネーミングの時点で勝利と言える『パン屋行路』の存在。志賀直哉の代表作であり、尾道滞在の折りに構想を練ったという文脈も完璧です。

朝7時からやってるし、雨の中でも飲食できる場所は商店街にあります。であればGoです。

2010年ぶりの「陸路での尾道到着」

海が見える 海が見えた

は林芙美子の一説。

尾道に到着するというタイミングでこれが脳裏に浮かぶ肩はそれなりに多いと思いますが、「輪行」を知って依頼、尾道に到着するときは常に「向島/生口島から尾道水道を渡って」の尾道到着だった次第。なので、電車での尾道というのは逆に新鮮。

そして、雨の中、その林芙美子像を横目に見つつその店『パン屋行路』へと向かいます。

セレクト&オープン

このお店、独自ルールがあります。2人もすれ違うことができない店舗のため、一度に客が入れません。しばらく待って入店し、「これは……!」と思うものをチョイスして会計。早速、近くのベンチで開封です。

「見た目からして勝利」

でした。

グリーンカレーパン

カレーパンはそれこそ食べ慣れていますが、タイの名物料理「グリーンカレー」は話が別です。そもそもあれ、パンにできるのか…… 思いつつ口にしたら、しっかりグリーンカレーでした。

青唐辛子の鮮烈な辛味、レモングラスの香り、ココナツミルクのコク、そこに鶏肉やエノキ、茄子がベストマッチ。そもそもこれらの濃厚なフィリングを受け止めるだけのパンがなければこれを野郎とは思いません。実にいい意味で“INSANIA”と叫びたくなるものでした。

ベーグル

このお店の看板商品。多様なベーグルが並んでいて、どれもおいしそうなものでしたが:脳内シナリオライターが商品セレクトの際に的確に指示を出していました。「カレーの辛味に合うものはこれだ」と。

ずんだ豆を練り込んだ生地とクリームチーズ入りのベーグル。

この辺りの、食べたもの/食べるものからの組み合わせをしっかりと選んでくれたのは感謝です。ずんだ豆の甘味、もちもち生地のベーグル。そして「これでもか」と円筒に入ったクリームチーズ。

いずれも、予め持っておいたお茶とぴったりの味わい。

何より大事な「情報と一緒に食べた」

移動の疲れや昨日の空腹を満たし、胃袋を満足させるご飯。それ以上に「尾道ご当地の名店の焼きたてを、尾道で食べている。それも雨の中」という情報は「単においしいパンを食べた」だけでは終わりません。

未だにその香りや歯ごたえ、そして空気感すら記憶として思い出せる味。

そうして、高松で朝ご飯を買い忘れたというアクシデントが「最高のドラマ」となったのは、ピボット大成功と言うべきでしょう。

ここでのゴリラルームの働きは、単なる「臨機応変に考えよう」という精神論ではありません。過去の旅行記録を材料に、潜在意識が次の行動候補を組み立てているというのが、今回の発見なのだと思います。

Page 1 of 308

次

Powered by WordPress & Theme by Anders Norén