「手順(Manual)」を作ろう。「技術の言語化と言語の行動」

趣味の延長でも手順は必要

筆者はサーバ運用の、ほぼすべてを手順化しています。

「なぜ、趣味の一環なのにプロのような手順を設けているのか」を疑問に持った方もいるでしょう。

これに関しての理由付けを示します。

「未来の自分が慌てないため」

これに尽きます。私の性格上、一度躓いた作業は二度目以降も同じところで詰まります。

「この私なら絶対にやらかす」

という、自分の信頼のなさへの信頼感があるため、

  • 注意すべきポイント
  • 何を持って「完了」とするのか
  • “やらかした”場合のリカバリ方法は?

などのPoint of No Return (回帰不能点)を少しでも減らすための強力なアンカーとしてマニュアルを作成しています。

特に、障害というやつは「起きてほしくないタイミングで起きる」から障害なのですから。

歴史的意義。

そもそも「マニュアル(Manual)」とは、ラテン語の「manus(手)」という単語に由来しています。

元々は「手を使う」「主導の」と言った意味の形容詞でしたが、そこから派生して「手引き」や「取扱説明書」といった名詞の意味で使われるようになりました。

  • management
  • manufacture
  • manicure

なども、すべて同じ語源から来ており、「手」に関する言葉となっています。

古代ローマと「マニュアル」

古代ローマ軍が規格外の強さを誇った背景には、「行動が全てであり、一定の標準的機能の遂行が勝敗を決定する」という思想があったとされています。

  • 古代ローマ軍の強さは、厳格な軍規と徹底した訓練によって支えられていました。
  • 膨大な数の兵士と多岐にわたる任務を効率的かつ確実に遂行するためには、経験や感覚に頼るのではなく、手順や規範を統一し、共有することが不可欠でした。
  • この技術や行動の「言語化・共有化」は、現代でいう標準化やマニュアル化の考え方につながるものであり、古代ローマの軍事的な成功の重要な源泉の一つであったと言えます。

特に、古代ローマ軍の圧倒的な強さは「各人が優れた土木技術者であり、野営のみならず街を作ることすら可能だった」ことにも現れています。

各軍人が軍事技術だけではなく土木技術の手引き書も共有化されていたからでした。

つまり

マニュアル通りとは、漫画や小説で言う

  • 融通が利かない人
  • 堅物

という意味ではないと筆者は考えます。むしろ「想定外の出来事が起きたとしても標準以上の行動ができるための引き出し」として定義しています。

マニュアルを作る意義

技術の言語化

  • どの要素を組み込んだから上手くいったのか
  • 何が元で失敗したのか
  • これを「同じ轍を踏まないようにするためには?」

など、すべての人が生み出した技術は言語化される余地があります。この言語化というやつは「自分の意を伝える」「相手の意をくみ取る」の両方で必要であり、他者からのフィードバックをもらうための最高の機会となります。

詰まったところの確認

失敗した部分のロギングです。

「マニュアルのどこが行けなかったのか?」を確認することで、すっ飛ばしたところや、怠った事による裏目がすべて結果となって現れます。

では、具体的なものを。

以下、筆者が過去に行った「Ubuntuサーバにスワップを設定する」手順です。ここで、実際にどのような点に気をつけてマニュアルを作っていったかを解説します。

https://barrel.reisalin.com/books/linux/page/vpsswap
### 環境

- Ubuntu 24.04
- 4GBメモリ/80GBディスクのインスタンスを利用

### さっくりとした手順

1. 現在のメモリとディスク容量を確認します。
1. Swap領域を確保します。
1. 確保したSwap領域を有効化します。
1. Swap領域が増えたことを確認します。
1. fstabを修正します。
1. fstab修正後にシステムを再起動し、Swap領域有効化を確認します。
  1. ここで環境を定義するのは「スタート地点が明確でないと明後日の方向に行ってしまうから」です。既に設定されている場合は作業をする必要が無いという目安になります。
  2. さっくりとした手順を記すのも、「だいたいの時間の見積もり(Estimated Time of Arrival)」を取るためです。これにより、いつ行うべきか、どのぐらいの工数を取るべきかの目安となります。
#### 作業の前に

ディスク起動時のオプションなど、特に重要なシステム領域の設定ファイルを修正する作業です。
失敗時に復旧できるようシステム全体のバックアップを取ることを強く推奨します。

これは、先に挙げたPoint of No Return (回帰不能点)を「Point of Returnable (回帰可能点) 」とするためのおまじないです。最悪の事態を挙げておくことで、もしもの時に備えます。

#### 現在のメモリ情報を確認

- メモリ情報を確認


free -h

-hオプションは(human readable)の略だそうです

- 実行結果

               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       450Mi       2.9Gi       2.5Mi       688Mi       3.4Gi
Swap:             0B          0B          0B


Swapが全く作成されていません。

#### 現在のディスク容量の確認

- 要領確認


df -h


- ○実行結果


Filesystem      Size  Used Avail Use% Mounted on
/dev/root        78G  5.0G   73G   7% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           784M  980K  783M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/vda15      105M  6.1M   99M   6% /boot/efi
tmpfs           392M   12K  392M   1% /run/user/1001


容量は問題ありません。実メモリと同じ4GBの領域を作ります。

と、作業の前の確認を行います。Markdownの判定で省いていますが、

1コマンド1ブロック というルールを遵守するように筆者は心がけています。

それがたとえ、参照するための

free -h

であってもです。この、最初の一歩を確認できない場合は

sudo rm -rf ./*

などの重要で致命的なコマンドも疎かにしてしまうからです。

#### Swap領域の確保

- Swap領域作成

sudo fallocate -l 4G /swap

- ファイル作成確認


ls -ldh /swap


指定ディレクトリに4GBのファイルがあることを確認します。

#### Swapの有効化

- /swapのパーミッション変更


sudo chmod 600 /swap


- パーミッション変更確認


ls -ldh /swap

rootのみが読み書き可能なことを確認します\

#### /swapの設定

- Swap領域作成


sudo mkswap /swap


- 実行結果


スワップ空間バージョン 1 を設定します。サイズ = 4 GiB (4294963200 バイト)
ラベルはありません, UUID=08cf06da-757e-4ab4-b049-e7da8ee73341


 ★/swapの有効化


sudo swapon /swap


#### Swap有効化確認

- メモリ情報確認

free -h

- ○実行結果


               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       446Mi       2.9Gi       2.5Mi       689Mi       3.4Gi
Swap:          4.0Gi          0B       4.0Gi


4GBのSwap領域が確保されました。

ここで、作業手順を一気に書きます。ここでも、一つ一つの確認を行うことで、「すっ飛ばしたときのリカバリー」を容易にしています。

#### fstab設定

- /etc/fstabのバックアップ


sudo cp -pi /etc/fstab /path/to/backup/directory/fstab.$(date +%Y%m%d)


- バックアップ作成確認


diff -u /path/to/backup/directory/fstab.$(date +%Y%m%d) /etc/fstab 


差分が無いことでバックアップが取れていることを確認します。

- /etc/fstab追記


cat <<- __EOF__ | sudo tee -a /etc/fstab
/swap none swap sw 0 0
__EOF__


- 差分確認


diff -u /path/to/backup/directory/fstab.$(date +%Y%m%d) /etc/fstab

- 差分


+/swap none swap sw 0 0

ここでは、「単にスワップを作成しただけでは終わらない」というLinuxのファイルシステムに言及しています。この/etc/fstabはディスク全体を司るテキスト群。そのため、

  • バックアップ
  • 実施時のオペレーションを確実に減らすためのteeによる追記
  • 追記後のdiffによる確認

と、「実際に作業を行ったか」を感覚では無くコマンドという冷静で絶対的な眼として確認します。

#### 再起動後の修正確認

- システム再起動


sudo reboot

- 再起動後の確認

以下が確認できれば作業完了です。

1. サーバにログインできること
1. Webサービスなど既存システムが設定前と同様に稼働すること
1. free -h を実行し、Swap領域が確保されていること

ここで、最終確認を行います。rebootを実施するのは、それだけシステム全体に関わる作業を行うからです。

ここまでやって

ようやく筆者の「標準」といえる手順書が作成されました。まぁ、最初にここまでやるというのは酷な話ではあると思いますが

  1. まずは非常に簡単な手順書を作る。それこそsystemctl status apache2.servicesudo systemctl restart apache2.service程度で構いません。
  2. そこから一つずつ発展させていく

と、ある程度の段階を積んでいくことが、より確実な手順と言えます。

最後にもう一つ

「自分で作った手順書が有効かどうか、第三者に実際に行ってもらう」手法は極めて有効です。

その手順書で失敗してしまったら → 確実に作成した自分自身の責任です。

この、言語化・共有化というのは「間違った手段も共有される可能性がある」からです。私もそうならないよう気をつけますが、

『超電磁マシーン ボルテスV』の

岡長官
 「そんな杓子定規な」
左近寺博士
「杓子結構、定規賛成」

という、割とガチめの引用で以て本稿を締めくくります。

PCにおけるメモリ量の観測。(低スペックのPCは使用に耐えられるのか?)

概要

2025年10月にサポート終了を迎えたWindows 10。

巷では

  • 入門用のWindows11搭載スペックは……
  • 古いPCでもLinuxであれば……

などの記事を見かけたと思います。

しかしながら

  • 入門用とされるWindows11のスペック( N100 / 8GB程度メモリ )のPCを買う
  • それよりもはるかに劣るスペックのPCをLinuxに換装する

程度ではビジネスユースはおろか日常の

  • オフィスソフト
  • ブラウザ

の同時利用には「とうてい耐えられない」と言い切れる根拠。

言い換えると「絶対に越えられない壁」という奴を「リソースの消費量」という形で証明します。

それも、巷にあるベンチマークソフトを使わずに。『アカギ』で言うところの「俺はもっと ストレートに行くよ……」です。

使うもの

  • Windows 11
  • テキストエディタ
  • PowerShell
  • Officeソフト(この例ではWord)
  • Chrome

のみです。

Word計測ツールの用意

テキストエディタを用いて、以下のパワーシェルスクリプトを作成します。

C:\batあたりにディレクトリを掘っておくといいでしょう。

  • benchmark_word.ps1
# --- ユーザー設定 ---
# ファイルサーバ上のWordファイル(UNCパス)
# サンプルとして、ファイルサーバー名、共有名、ディレクトリ名を一般的なものに変更しています。
# 実際の環境に合わせてパスを変更してください。
$FilePath = '\\YourFileServer\ShareName\SampleProject\TestDocument.docx'

# ログファイル(ローカル保存)
$LogPath = "C:\Temp\Log\word_benchmark_log.txt"
# ------------------

# --- ログ出力関数(リトライ付き) ---
function Write-Log {
    param (
        [string]$Message,
        [string]$Color = "White"
    )
    # コンソール出力
    Write-Host $Message -ForegroundColor $Color

    # ログファイル出力(リトライ付き)
    $maxRetries = 5
    $retryDelay = 500 # ミリ秒

    for ($i = 0; $i -lt $maxRetries; $i++) {
        try {
            # ログファイルのディレクトリが存在しない場合は作成
            $LogDir = Split-Path -Path $LogPath -Parent
            if (-not (Test-Path $LogDir)) {
                New-Item -Path $LogDir -ItemType Directory | Out-Null
            }

            Add-Content -Path $LogPath -Value ("[{0}] {1}" -f (Get-Date -Format "yyyy-MM-dd HH:mm:ss"), $Message)
            break
        } catch {
            Write-Host "WARN: ログ書き込みに失敗しました。リトライ中... ($i/$maxRetries)" -ForegroundColor "DarkYellow"
            Start-Sleep -Milliseconds $retryDelay
        }
    }
}

# --- 初期化 ---
# ログファイルをクリア
Clear-Content -Path $LogPath -ErrorAction SilentlyContinue
Write-Log -Message "--- Word(UNCパス指定)ベンチマークテスト ---" -Color "Yellow"

# --- ファイル存在確認 ---
if (-not (Test-Path $FilePath)) {
    Write-Log -Message "エラー: 指定されたファイルが見つかりません。パスを確認してください: $FilePath" -Color "Red"
    return
}

# --- 既存のWordプロセスを終了 ---
Write-Log -Message "INFO: 既存のWordプロセスをクリーンアップします..." -Color "White"
Get-Process winword -ErrorAction SilentlyContinue | Stop-Process -Force
Start-Sleep -Seconds 2

# --- 変数初期化 ---
$wordApp = $null
$document = $null
$TimeTaken = $null
$ProcInfo = $null
# COMメソッドの省略可能な引数に使用する値
$Missing = [System.Reflection.Missing]::Value

try {
    # 1. Word起動とファイルオープンの時間を計測
    Write-Log -Message "1. Wordの起動とファイルオープンを計測中..." -Color "White"
    $TimeTaken = Measure-Command {
        # Wordアプリケーションのインスタンスを作成
        $wordApp = New-Object -ComObject "Word.Application"

        # ファイルを開く (引数: FilePath, ConfirmConversions, ReadOnly, AddToRecentFiles, PasswordDocument, PasswordTemplate, Revert, WritePassword, Format, Encoding, Visible)
        $document = $wordApp.Documents.Open(
            $FilePath,
            $false,         # ConfirmConversions
            $false,         # ReadOnly
            $false,         # AddToRecentFiles
            $Missing,       # PasswordDocument
            $Missing,       # PasswordTemplate
            $false,         # Revert
            $Missing,       # WritePassword
            $Missing,       # Format
            $Missing,       # Encoding
            $false          # Visible (False: 開いた直後は非表示)
        )
    }

    # Wordを可視化し、プロセスが完全に立ち上がるのを待つ
    $wordApp.Visible = $true
    Start-Sleep -Seconds 2 

    $StartTimeSec = [math]::Round($TimeTaken.TotalSeconds, 2)
    Write-Log -Message "  [結果] 起動&ファイルオープン時間: $StartTimeSec 秒" -Color "Green"

    # 2. リソース使用量の計測
    Write-Log -Message "2. リソース使用量を計測中..." -Color "White"
    Start-Sleep -Seconds 3 # リソースが安定するのを待つ

    $ProcInfo = Get-Process winword -ErrorAction SilentlyContinue
    if ($ProcInfo) {
        # 複数のwinwordプロセスがある場合の合計を計測
        $TotalMemMB = [math]::Round( ($ProcInfo | Measure-Object -Property WS -Sum).Sum / 1MB, 2)
        $TotalCpuSec = ($ProcInfo | Measure-Object -Property CPU -Sum).Sum
        if ($TotalCpuSec -eq $null) { $TotalCpuSec = 0 }
        $TotalCpuSec = [math]::Round($TotalCpuSec, 2)

        Write-Log -Message "  [結果] メモリ使用量 (WS 合計): $TotalMemMB MB" -Color "Green"
        Write-Log -Message "  [結果] CPU使用時間 (Total 合計): $TotalCpuSec 秒" -Color "Green"
    } else {
        Write-Log -Message "  [警告] Wordプロセスが見つかりませんでした。" -Color "Yellow"
    }

} catch {
    Write-Log -Message "致命的なエラーが発生しました: $($_.Exception.Message)" -Color "Red"
    # エラーの詳細ログ
    Write-Log -Message "エラー詳細: $($_.ScriptStackTrace)" -Color "Red"
} finally {
    # 3. クリーンアップ
    Write-Log -Message "3. クリーンアップを実行します。" -Color "White"

    if ($document -ne $null) {
        # 変更を保存せずに閉じる
        try {
            $document.Close($false) 
            [System.Runtime.InteropServices.Marshal]::ReleaseComObject($document) | Out-Null
        } catch {
            Write-Log -Message "WARN: Document COMオブジェクトのクリーンアップ中にエラー: $($_.Exception.Message)" -Color "DarkYellow"
        }
    }

    if ($wordApp -ne $null) {
        try {
            $wordApp.Quit()
            [System.Runtime.InteropServices.Marshal]::ReleaseComObject($wordApp) | Out-Null
        } catch {
            Write-Log -Message "WARN: Application COMオブジェクトのクリーンアップ中にエラー: $($_.Exception.Message)" -Color "DarkYellow"
        }
    }

    # 変数の解放
    Remove-Variable wordApp, document, ProcInfo, TimeTaken -ErrorAction SilentlyContinue

    # 残っているWordプロセスを強制終了
    $remaining = Get-Process winword -ErrorAction SilentlyContinue
    if ($remaining) {
        Write-Log -Message "INFO: 残留Wordプロセスを強制終了しました。" -Color "White"
        $remaining | Stop-Process -Force
    }

    Write-Log -Message "--- テスト完了 ---" -Color "Yellow"
}

開きたいファイルを正確に指定し、文字コードをUTF-8(BOMつき)で保存します。

Powershellの実行

まず、Windows Powershellを開きます。(管理者権限である必要はありません)

次に、スクリプトに一時的な実行権を与えます。(デフォルトでは自作のスクリプトの実行権が与えられていないため)

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

そうした上で、

& "C:\script\benchmark_word.ps1"

を実行。

結果は以下の通りです。

--- Word(UNCパス指定)ベンチマークテスト ---
INFO: 既存のWordプロセスをクリーンアップします...
1. Wordの起動とファイルオープンを計測中...
  [結果] 起動&ファイルオープン時間: 1.36 秒
2. リソース使用量を計測中...
  [結果] メモリ使用量 (WS 合計): 289.7 MB
  [結果] CPU使用時間 (Total 合計): 4.44 秒
3. クリーンアップを実行します。
INFO: 残留Wordプロセスを強制終了しました。

と、300MB近くの使用量がありました。数MB程度の文書を開く際でも、ワードのようなモダンアプリケーションはメモリもCPUもそれなりに使うことが判明。

ブラウザの場合

続いて、ブラウザの場合はどうなるでしょうか? 先ほどのフォルダに

benchmark_chrome.ps1

を作成します。

# --- ユーザー設定 ---
# ログファイル(ローカル保存)
$LogPath = "C:\Temp\Log\chrome_benchmark_log.txt"
# Chromeの実行ファイルパス (通常はこのままでOK)
$ChromePath = "C:\Program Files\Google\Chrome\Application\chrome.exe"
# 検索するURLとクエリ
$InitialUrl = "https://www.google.com/search?q=wikipedia"
# ------------------

# --- ログ出力関数(リトライ付き) ---
# (前回のスクリプトから変更なし)
function Write-Log {
    param (
        [string]$Message,
        [string]$Color = "White"
    )
    Write-Host $Message -ForegroundColor $Color

    $maxRetries = 5
    $retryDelay = 500 # ミリ秒

    for ($i = 0; $i -lt $maxRetries; $i++) {
        try {
            $LogDir = Split-Path -Path $LogPath -Parent
            if (-not (Test-Path $LogDir)) {
                New-Item -Path $LogDir -ItemType Directory | Out-Null
            }

            Add-Content -Path $LogPath -Value ("[{0}] {1}" -f (Get-Date -Format "yyyy-MM-dd HH:mm:ss"), $Message)
            break
        } catch {
            Write-Host "WARN: ログ書き込みに失敗しました。リトライ中... ($i/$maxRetries)" -ForegroundColor "DarkYellow"
            Start-Sleep -Milliseconds $retryDelay
        }
    }
}

# --- 初期化 ---
Clear-Content -Path $LogPath -ErrorAction SilentlyContinue
Write-Log -Message "--- Chrome Webアクセス・ベンチマークテスト ---" -Color "Yellow"

# --- 実行ファイル存在確認 ---
if (-not (Test-Path $ChromePath)) {
    Write-Log -Message "エラー: Chrome実行ファイルが見つかりません。パスを確認してください: $ChromePath" -Color "Red"
    return
}

# --- 既存のChromeプロセスを終了 ---
Write-Log -Message "INFO: 既存のChromeプロセスをクリーンアップします..." -Color "White"
Get-Process chrome -ErrorAction SilentlyContinue | Stop-Process -Force
Start-Sleep -Seconds 2

# --- 変数初期化 ---
$TimeTaken = $null
$ProcInfo = $null

try {
    # 1. Chrome起動、Google検索、Wikipedia移動の時間を計測
    Write-Log -Message "1. Chrome起動からWikipedia表示までの時間を計測中..." -Color "White"

    # ストップウォッチを開始
    $Stopwatch = [System.Diagnostics.Stopwatch]::StartNew()

    # Chromeを起動し、Google検索URLへ移動
    # -Wait: プロセスが終了するまで待機(この場合はタブを閉じるまで待機してしまうため使用しない)
    $Proc = Start-Process -FilePath $ChromePath -ArgumentList $InitialUrl -PassThru

    # プロセスが完全に立ち上がり、ページがロードされるのを待機
    # ページの完全なロード完了を正確に捕捉するのは困難なため、ここでは固定の待機時間を使用します。
    Start-Sleep -Seconds 5

    # ストップウォッチを停止
    $Stopwatch.Stop()

    $TimeTaken = $Stopwatch.Elapsed
    $StartTimeSec = [math]::Round($TimeTaken.TotalSeconds, 2)
    Write-Log -Message "  [結果] 起動&Webアクセス時間: $StartTimeSec 秒" -Color "Green"

    # 2. リソース使用量の計測
    Write-Log -Message "2. リソース使用量を計測中..." -Color "White"
    Start-Sleep -Seconds 3 # リソースが安定するのを待つ

    # Chromeは複数プロセスで実行されるため、全てを対象とする
    $ProcInfo = Get-Process chrome -ErrorAction SilentlyContinue
    if ($ProcInfo) {
        # 複数のchromeプロセスの合計を計測
        $TotalMemMB = [math]::Round( ($ProcInfo | Measure-Object -Property WS -Sum).Sum / 1MB, 2)
        $TotalCpuSec = ($ProcInfo | Measure-Object -Property CPU -Sum).Sum
        if ($TotalCpuSec -eq $null) { $TotalCpuSec = 0 }
        $TotalCpuSec = [math]::Round($TotalCpuSec, 2)

        Write-Log -Message "  [結果] メモリ使用量 (WS 合計): $TotalMemMB MB" -Color "Green"
        Write-Log -Message "  [結果] CPU使用時間 (Total 合計): $TotalCpuSec 秒" -Color "Green"
    } else {
        Write-Log -Message "  [警告] Chromeプロセスが見つかりませんでした。" -Color "Yellow"
    }

} catch {
    Write-Log -Message "致命的なエラーが発生しました: $($_.Exception.Message)" -Color "Red"
    Write-Log -Message "エラー詳細: $($_.ScriptStackTrace)" -Color "Red"
} finally {
    # 3. クリーンアップ
    Write-Log -Message "3. クリーンアップを実行します。" -Color "White"

    # 確実にChromeプロセスを終了
    $remaining = Get-Process chrome -ErrorAction SilentlyContinue
    if ($remaining) {
        Write-Log -Message "INFO: 残留Chromeプロセスを強制終了しました。" -Color "White"
        $remaining | Stop-Process -Force
    }

    Write-Log -Message "--- テスト完了 ---" -Color "Yellow"
}

Powershellの実行

まず、Windows Powershellを開きます。(管理者権限である必要はありません)

次に、スクリプトに一時的な実行権を与えます。(デフォルトでは自作のスクリプトの実行権が与えられていないため)

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

そうした上で、

& "C:\script\benchmark_chrome.ps1"

を実行。以下の驚くべき結果が出ました。

--- Chrome Webアクセス・ベンチマークテスト ---
INFO: 既存のChromeプロセスをクリーンアップします...
1. Chrome起動からWikipedia表示までの時間を計測中...
  [結果] 起動&Webアクセス時間: 5.03 秒
2. リソース使用量を計測中...
  [結果] メモリ使用量 (WS 合計): 1413.37 MB
  [結果] CPU使用時間 (Total 合計): 17.97 秒
3. クリーンアップを実行します。
INFO: 残留Chromeプロセスを強制終了しました。
--- テスト完了 ---

なんと、メモリは1.4GB利用。単にWikipediaを計算しただけです。

補足しておくと、この検証に使用した筆者の環境は

  • Ryzen 5 4500 3.6GHz (6コア12スレッド)
  • GTX 1650 (4GB VRAM)
  • メモリ64GB

と、ビジネスユースにしては「化け物」なスペックであってもです。

PCの利用=ブラウザの利用

という現代の環境において、以下のポイントが、「ネット閲覧程度であれば云々」の神話を打ち破る主要な論拠となります。

マルチプロセスアーキテクチャによるメモリの膨張

Chrome(および他のモダンブラウザ)が採用しているマルチプロセスアーキテクチャが、メモリ消費量の最大の原因です。

  • 従来のアプリ (Word):
    • 1つのウィンドウやドキュメントにつき、通常はメインプロセス1つが主体となります。
  • モダンブラウザ (Chrome):
    • ブラウザ全体を制御するプロセスに加え、タブごと、拡張機能ごと、時にはWebサイト上の異なるフレームごとに独立したレンダリングプロセスを生成します。

結果として、たった1つのタブを開いているだけでも、タスクマネージャー上では10〜30個のchrome.exeプロセスが立ち上がり、ベンチマーク結果のように、それらの合計で1GBを優に超えるメモリを消費します。

Webコンテンツの「リッチ化」

そして、現在のWebサイトは、単純なテキストや画像で構成されていません。

  • JavaScriptの肥大化:
    • 多くのWebサイトが、高度なインタラクティブ機能やリアルタイム通信のために巨大なJavaScriptフレームワーク(React, Vue, Angularなど)を使用しています。これらのスクリプトエンジンと実行環境がメモリを大量に占有します。
  • 高解像度メディアと広告:
    • 高解像度の画像、埋め込み動画、そして追跡スクリプトや動的な広告は、ブラウザに多くの処理とメモリ負荷をかけます。

3. ベンチマーク結果の対比

アプリケーション目的メモリ消費量 (WS 合計例)
Word (COM操作/UNCファイル)文書作成(重量級ローカルアプリ)290 MB
Chrome (Google検索 → Wikipedia)ウェブ閲覧(単一タブ)1,413 MB

この対比から、現代の「ウェブ閲覧」が、伝統的なローカルの重量級アプリケーションよりも、起動直後で約5倍近いメモリリソースを要求することが明確に示されます。

ここに、

  • OSそのもののメモリ消費量
  • ウィルス対策ソフト
  • マルチタスク(ビジネスユースであればこれらを開いたと同時にSlackやTeamsを開くのが当然のはずです)

が加わるとなると、古い、低スペックのハードウェアをLinuxに変えた「程度」では、付け焼き刃にすらなりません。

したがって、「ネット閲覧程度」の利用を想定してPCのスペックを決める場合、最低でも16GBのメモリを搭載しないと、動作が非常に緩慢になるリスクが高いという結論になります。

なぜなら、2025年現在、通常のインターネット環境でのビジネスや学習というのは「ブラウザのタブ多重起動」を前提に作られているのですから。

ジェレミー・クラークソン(旧TopGearやGrandTour司会者)の

Power is EVERYTHING. More is better.
( パワーはすべてを解決する。気筒数は多ければ多いほどいい)

A horsepower, A horsepower!
Horsepower for my kingdom!
「馬力だ! 馬力の代わりに我が王国をやるぞ!」

は、こと、PCのリソース割当については「反論の余地がない真である」という結論で本稿を締めくくります。

「あなたにとっての“ナイフ”」とは?-3- (「私が量産品を選ぶ理由」)

前回、「万年筆」を

  • 格好良いから

という理由で使い始めました。その書き味や機能性に惹かれて言った結果、なぜLAMY Safari(AL-Star)を選択したかという部分について解説します。

自分の感覚という「Book」

『メリー・ポピンズ・リターンズ』の『本は表紙じゃ分からない/Cover is not the Book』に曰く

Cover is not the book / 心が目に見えないように本も
So open it up and take a look / 表紙の美しさに騙されちゃダメ
'Cause under the covers one discovers / 中身読んだらやさしい王様
That the king may be a crook / 詐欺師だとわかるかも

とあります。この、「きちんと中身を読んだ」結果として、今の自分はLAMY Safari(AL-Star)になったという形です。

LAMYを使って良かった点:重心

これが一番、自分が良かったと思うポイントです。LAMY万年筆最大の特徴と言えるクリップ付きのキャップ。筆記時、これを後ろにつけることで重心が後ろ寄りになります。これにより、必然的に重心は親指と人差し指の付け根にフィット。
軽く支えるだけでさらさらとした書き味を保証してくれます。

より重いアルミを用いたAL-Starはそれを更に補強。ひんやりとした金属の素材感と相まって「よりしっかりした書き味」を楽しめます。

LAMYを使って良かった点:フィット感

持ちやすさ、と言い換えてもいいでしょう。持ち手の上が自然にカット(三角形のカーブ)があることで、手になじむような形にフィット。

何よりも、この持ち手が明示されていることで万年筆にありがちな「どこがペン先の上か?」を一切気にする必要がありません。

LAMYを使って良かった点:速度

この場合の速度は

  1. 書こうとする
  2. ペンを取り出す
  3. キャップを取り外す
  4. 書き始める

のスタートです。多くの高級万年筆は(キャップレスでない場合は)ネジ式のキャップであるため「キャップを取り外す」がハードルになります。

ですが、LAMY万年筆はシンプルなキャップ式を採用。「取り外す」手間が秒単位で速くなります。

LAMYを使って良かった点:カラーバリエーション

『忍風戦隊ハリケンジャー』のカラーで揃えられるなどバリエーションは豊富

通常色、限定色、チャーム付きなど、多彩なカラーバリエーションがあります。

単に物欲を充たしてくれるのはもちろんのこと、ボディに沿った色のインクを詰めることで、インク補充時に「このライトグリーンには『翠玉』のインクを。黄色には『夕焼け』を選ぶ」と、直感に従ったインク補充が可能になります。

量産品であるという美徳

おおよそ道具というものは使ってなんぼ、壊れてなんぼという考えです。なので、「書く」という「思考を伝達する道具」の替えが効かないというのは、それ自体が単一障害点(SPOF: Single Point of Failure):その部分に障害が発生すると、システム全体が停止してしまうような、代替手段のない単一の要素になります。

しかし、LAMY Safariであれば

  • Amazon等のネットショップで2500円程度から買える(2025年11月現在)。
  • 大都市圏の文具店、量販店でも扱っている。

という、「替えが効く」理由としては十分です。紛失、破損などがあっても「ペンそのものを用意できる」という安心感は非常に有用です。

量産品のユーザーの多さ

これに落ち着く前、中華万年筆を使っていました。「安いに越したことはない」と。しかし、

  • インクの乾きが速く、キャップをしてもすぐにペン先が詰まる
  • ひどいのになるとインクがすべて飛び跳ねてしまった

という「安物買いの銭失い」を地で行く結果となりました。この「授業料」の結果、ある程度は出費を覚悟しても(それでも高級万年筆よりは安価です)それなりのものとして白羽の矢が立ったのがLAMY万年筆でした。

最初は「樹脂製のデザイン」等がハードルとなっていましたが

  • 古くからのデザインという普遍性は、それだけ使われる理由があるということ。
  • 工学的に優れたデザインのため飽きが来ないということ。
  • ファンが多いため世界各国のユーザーからの知見が山ほどあること。

という、量産品の強みが前面に打ち出されたのです。

まとめに代えて

以上、「格好良さ」から始めた万年筆は、

  • 合理的な機能
  • 量産品の強み

という筆者のプラグマティズムにより、これを求めたという結論。コレクションを手放すことになったとか、壊れたという話でない限り、他のブランドに手を出すのはまだまだ先となりそうです。何せ、前の記事でお話ししたとおり5年前のSafariが未だに現役なのですから。

ここで、「量産品の強み」を最も的確に表した『ガールズ&パンツァー』、サンダース大付属のアリサがM4シャーマン戦車を

「丈夫で壊れにくいし、おまけに居住性も高い!
  バカでも乗れるくらい操縦が簡単で、
 バカにも扱えるマニュアル付きよ!」

と評した言葉を以て、本稿を締めくくります。

「あなたにとっての“ナイフ”」とは?-2- (万年筆を選んだ理由)

基本的に筆者はプラグマティズムを以て道具を選びますが「それ以上の理由」。即ち

  • 伊達
  • 酔狂

の2つで使い始めた結果として、この万年筆というスタイルが確立されたという話です。

メインの万年筆一覧

まずこちらを。

LAMY Safari / AL-Starを中心に、一部は

  • Pilot ライティブ
  • カスタム ヘリテイジ

が一部混じっています。筆者が帰る範囲で諸々を試し、これに落ち着きました。これらは筆者のアナログの言葉通りの意味で屋台骨として支える道具。2025年現在、一番長く使って13年。短くても2年は愛用しています。

万年筆のデメリット

結論から言います。万年筆はデメリットが多い道具です。

値段の問題。

他の筆記具とベースの価格が違います。(全ての道具は天井知らずなので一般的に買えるものに絞ります)

これら3つは100均でも見かけるものでしょう。

  • シャープペンシル
    • 100円商品として1本は買える。替え芯を合わせても200円ほど。(+消費税)
  • 鉛筆:
    • 100円で4本程度。鉛筆削りを足しても200円。(+消費税)
  • ボールペン
    • これはもっと安く、100円で10本ほどセットで買えるでしょう。

ですが、万年筆は、入門用に限った上でも

おおよそ「500円台〜6,000円台」まで。(Copilot調べ)

価格帯特徴・用途例主なモデル例(参考)
〜500円超低価格帯。プラスチック製で軽量。試し書きや学生の練習用に最適。プラチナ プレピー、ダイソー製品など
1,000〜2,000円初心者向けの定番。カートリッジ式が多い。PILOT カクノ、セーラー ふでDEまんねん
2,000〜4,000円書き心地やデザイン性が向上。プラチナ プレジール PILOT ライティブ
4,000〜6,000円金属製や透明軸など、質感やインクの楽しみが広がる。長く使える1本に。ラミー サファリ、セーラー プロフィットJr.、パイロット コクーン
6,000円以上本格派の入門機。耐久性・筆記性能ともに高く、長期使用を前提とした設計。パイロット カスタム74(入門上級)

と、桁が違います。

消耗品の問題。

ここに「インク」が加わります。日本のボールペンの筆頭ブランドである『Jet Stream』シリーズとカートリッジ式、これら、一つでどこまで書けるのかを見てみます。

筆記具インク容量の目安書ける文字数(概算)原稿用紙(400字詰)換算備考
ジェットストリーム(0.5mm)約0.4〜0.5ml約20,000〜25,000字約50〜60枚油性・低粘度インクで長持ち
パイロット 万年筆カートリッジ約0.9ml約4,000〜5,000字約10〜12枚字幅や筆圧により変動
セーラー 万年筆カートリッジ約1.0ml約5,000〜6,000字約12〜15枚染料インクでやや多め
  • ジェットストリームのボールペンは約20,000〜25,000文字
  • パイロットやセーラーの万年筆カートリッジは約4,000〜6,000文字

この時点で、ボールペンのコストパフォーマンスは圧勝。

もっとわかりやすく言うと原稿用紙換算では

  • ボールペン:約50〜60枚
  • 万年筆:約10〜15枚分

というより、ボールペンのインク切れを体験するという方はかなり少ないのではないでしょうか。(書き味が怪しくなったら新しいボールペンを買うというのが基本的な運用だと思います)

また、カートリッジもインクも高額です。(インク沼という言葉を聞いたことがあるかと思います)

手間の問題。

万年筆のカートリッジ交換はボールペンとほぼ同じぐらいとは言え手間です。

インク補充式ともなると

  • インクがこぼれないように(倒れでもしたら大惨事です)
  • インクを間違えないように(複数本、色が違うものを用いている場合)
  • 吸入した後、確実に書けるかの確認

と、別次元の手間が加わります。

確実性の問題。

万年筆は、上記のシャープペンシルや鉛筆、ボールペンなどに比べて「誰でも使える」筆記具ではありません。断じて。

再掲しますが:

漫画『MASTERキートン』に以下のやりとりがあります。

「やめておけ」
「…………」
「拳銃の方が、ナイフよりも速いと思っているんだろう。
 だが、拳銃はデリケートな道具だ。
 弾が出ないかもしれないし、
思い通り的に当たるとは限らん。
おまけに拳銃は、
抜き、構え、引き金を引くまでに三動作(スリーアクション)……
その点ナイフは、一動作(ワンアクション)で終わる。
この距離なら、絶対に俺が勝つ!!
どうする? それでもやってみるかね?」

万年筆は

  • デリケートさ
  • 使うまでのアクション
  • 書き始めるまでの動作

全てが劣ります。特に、品質が悪いものともなると、使った瞬間にインクが漏れて服に付着するなんてこともあります。

この、一般的な筆記具ではなく万年筆を筆者が使い続ける理由を述べます。

使い始めた理由

「格好良いから」

これに尽きます。ハッキリ言って、これ以外の理由は全て『後付け』に過ぎません。

  • インクを補充する
  • あのペン先の格好良さ
  • ボールペンとも違う高級感

全てが「他の人と違う特別感」が、使い始めたきっかけでした。

インク補充の格好良さ

上記、述べたインク補充は、サーバのメンテナンスのごとき、手間をかけることで「自分のものである」という愛着を持つことができます。

自分で組み立てたものなど、自分の手で労力をかけたものに対して、本来の価値以上の価値を見出す心理的な傾向

いわゆる「イケア効果」の発露の表れです。

「書き味が違う」

これもまた別格でした。筆圧が強い方だったので、力を入れずにさらさらと書ける、滑るような書き心地は、一度慣れてしまうと他に戻れなくなった次第です。

それなりのものを使えば長持ちする。

上述した通り、手入れされた万年筆は圧倒的な強度を誇ります。

  • 未だに使えているヘリテイジ カスタムは2012年から愛用。
  • 限定版、丸の内Oazo10周年記念で買ったヘリテイジは2015年から愛用。
  • Lamy Safariも5年は使っているものがある。

「万年」の名は伊達ではありません。

まとめに代えて「合理性を超えるもの」

最終的に

  • この書き味があるならもっと試してみよう
  • これは自分のものだというもの
  • TCGプレイヤー特有のコレクション欲

が加わり、ちょっとした万年筆のコレクション群を持ち歩き、日々使い続けているという話でした。では、なぜLAMY Safariに落ち着いたかというのはまた次に機会を設けて記事を記します。

映画『Back to the Future』の

「If you're gonna build a time machine into a car, why not do it with some style?」
「タイムマシンを車にするなら、カッコよく作らなきゃだろ?」

という言葉を以て、本記事はひとまず区切りとします。

『My Favourite Things(私のお気に入り)』でのモチベーション維持。

はじめに

Rome was not built in a day.

の言葉を引き合いに出すまでもなく、「趣味での個人Webサーバの運用・管理」というやつは一筋縄ではいきません。

  • リソースの定期的な監視
  • 脆弱性対応
  • 脅威への対策

等など、続ければ続けるほど、そして知識を得れば得るほど課題が増えます。そんな中で、どうやってモチベーションを維持していくかという筆者なりの回答です。

「My Favourite Thints』 (※英国英語を用いるのは仕様です※)

『メリー・ポピンズ』と共に筆者が困ったときに立ち返る『サウンド・オブ・ミュージック』。

Raindrops on roses
And whiskers on kittens
Bright copper kettles

で始まる、自分の好きなものを並べた歌詞『My Favourite Things』は

When I’m feeling sad
I simply remember my favourite things
And then I don’t feel so bad

と、「お気に入りのもの」を思い浮かべることで実際軽減される。

ポジティブな注意の転換と感情の自己調整という心理的メカニズムが働くとかなんとか。

注意の転換

  • 人は悲しいとき、ネガティブな思考に囚われがちです。
  • 「お気に入りのもの」を思い出すことで、意識の焦点がポジティブな対象に移る。
  • これは「認知的再評価(Cognitive Reappraisal)」の一種で、感情の強度を下げる効果があります。

自己効力感の回復

  • 「悲しいときは、お気に入りを思い出す」という歌詞は、自分で感情を調整できるというメッセージを含んでいます。
  • これは「自分には対処する力がある」という感覚があります。

そんな自分のお気に入り

  • 「かんばん」
    • ドメインとして取得した reisalin.com / ryza.jp の2つは、これ自体が「お気に入り」を含んでいます。
  • 「道具」の数々
    • 以前紹介した万年筆や手帳は、「メモを取る」という思考の戦いにおいて優位に立てるような気合いを持たせられます。

ここまでは前にも紹介したもの。

ここに

  1. 「どこでもメンテナンスができる道具」
  2. 「集中できる場所」
  3. 「美味しいもの」

の3つを加えます。

ThinkPad

今年購入したThinkPad。中古とは言え

  • 基本性能
  • サイズ感
  • キーボードの打ちやすさ
  • 剛性と信頼性

を有していて、何よりもデザイン性もお気に入り。

重要なのは、ここを介してSSH接続を行える「自分のサーバへのアクセスゲートである」ことです。この、お気に入りの道具を介してサーバ制御を行うというのがモチベーションを維持していくことができます。

お気に入りの場所

写真にも示したのは『夢の島熱帯植物館』。

  • 休憩スペースは植物園に面した絶好のロケーション
  • 息抜きとして様々な植物や花という目に優しいものが揃っている

と、集中にはこれ以上無いほどの条件が揃っています。

そのため、先の歌詞に示した「悲しいとき」でも訪れることにしています。

実際問題として:この夢の島熱帯植物館を舞台に「WebArena → XServerへのWebサイト移行」を行うことができたほどです。

美味しいもの

これはあくまでも「自分にとっての」という意味です。美味しい食べ物がモチベーションを以下に高めるかは今更説明するまでもないでしょう。

こちらのコメダ珈琲の「重軽食」とも言えるようなボリュームある食事と糖分は、頭を使うサーバ管理になくてはならないものです。(これは一例ですが)

まとめとして

この『My Favourite Things』の私の学びは

「サーバ作業のような一瞬のミスですべてが持って行かれる作業に際しては、心身共に平衡を取るマインドセットが必要」

ということに尽きます。どっちかが崩れていれば、本当にアホみたいなミスを行ってしまうというのが筆者が様々な失敗という「授業料」での気づきなので。

余談「験を担ぐ」

徹底した金銭のリアリズムを描いた『ナニワ金融道』において以下のやりとりがあります。

「えらい早いやないか灰原君 君は金融屋に向いとるで!」
「いや まぐれですよ まぐれ」
「いやちがう これはあんたの宿命やで!
 この業界はのー 不渡りが不渡りを呼ぶんや
 だからワシ等はゲンを担ぐんや
 初日のしょっぱなで(融資の見込み客を)ひっかけたんや
 金融屋になるのはあんたの宿命やで!」

と、この、リアリズムに生きている世界ですら「ジンクス」とか「験を担ぐ」というマインドセットが必要という身も蓋もない結論を以て本稿を締めくくります。

『かんばん』を持とう! 個人サーバ運用でのドメイン取得と維持のコツ

はじめに

筆者が取得している

  • reisalin.com
  • ryza.jp

の2つ。この、「取れてしまった」ドメインと、そのドメインという『かんばん』を通して、何故、サーバ維持でドメインが大切かという問いかけからのお話と、それを取得するためのちょっとしたコツについてです。

『ドメイン』という『かんばん』とは?

街角の店舗が看板を掲げるように、インターネットの世界でも「ここに存在しています」と示すための名前がドメインです。

ドメインとは、

  • Web上の住所
  • ブランドの顔
  • 信頼の証

でもあります。

インターネット上で情報を発信したり、サービスを提供したり、世界に向けて何かを伝えたいなら、まずは「かんばん」を立てることから始まります。

『かんばん』という拠り所

ここに、もう一つ。筆者はこのやりとりを加えます。ダンディズムの規範としている池波正太郎の著作から。

「人間、落ちるところへ落ちてしまっても、なにかこう、この胸の中に、たよるものがほしいのだねえ」
「たよるもの、ねえ…」
「いえば看板みたいなものさ」
「かんばん、かね…?」
「人間、だれしも看板をかけていまさあね。旦那のお店にもかけてござんしょう」
――『にっぽん怪盗伝』

つまり、筆者は「サーバ維持の強烈な推進剤」として、このドメインを取得。「すべてはこの看板の名に恥じないような」ものとして

  • 詳細な『ライザのアトリエ3』の攻略情報
  • Linuxサーバの記事

を書いています。言うなれば「伊達」と「酔狂」の4文字2単語を元にサイトを運営しています。

そこで、次から「個人でサイトを運営してみたい」という方を対象としたドメイン選びのコツについて筆者の経験を交えながらご紹介です。

ドメインの取得基準

ドメインを取るにはそれなりのコツがあります。

「自分が」覚えやすいこと

これが一番です。

どんな平易で短い文字列でも、自分に馴染みがなければ無意味です。

逆に、どんなに長く難しい文字列でも、自分が覚えられれば自分にとってのドメインとなります。

Supercalifragilisticexpialidocious

など、知らない人に取ってみれば「何この長い単語」ですが、『メリー・ポピンズ』を知っている人にとっては歌を口ずさむことができる程度のリズムで言えるでしょう。

「自分のサイト」である以上、「自分のわがまま」を最優先としましょう。

その上でユニークなものを

とはいえ、インターネットのドメインとは絶対的なルールがあります。

  • 「先行取得者がすべてを得る」
  • 「本当に覚えやすいドメインは恐ろしく高い」

の2点。特に前者は重要です。

いくら自分にぴったりな、「自分の推しを体現する」ドメインを持っていたとしても、「既に登録されている」というメッセージが出たら、それに従うほかありません。その場合は

  • 他の概念に置き換える
  • 別のイメージを探す

等を行いましょう。後者の「恐ろしく高い」に関しては、それを出す価値があるという確固たる自信があり、それを発展させていくだけの継続力があるならば「身代を潰さない程度に」と言葉を濁します。

それ故に、筆者が

  • reisalin.com
  • ryza.jp

のドメインが空いており、かつ、定価で取得できると知ったときは

  • スペリングを50回ほど確認
  • 申込前に更に30回ほど確認
  • 申込確定できたほどは「マジか」「マジなのか」を12回ぐらい繰り返した

ほどです。

維持費は要注意

多くのドメイン取得サービス業者(レジストラ)は「今なら○○円が無料!」などと謳われていますが条件に注意しましょう。

まず、ドメインは「買って終わり」ではありません。その後、使い続ける以上は「維持費」が必要になってきます。以下に示すのは安いTLD/高いTLDです。

  • 維持費が安いTLD(年間1,000円〜2,000円程度)
TLD特徴・用途備考
.com最も一般的。企業・個人問わず人気更新料も比較的安定
.net技術系やインフラ系に多く使われる.comと同程度
.info情報提供サイト向け初期費用が安いことも
.xyz新興TLD。自由度が高く人気上昇中キャンペーン多め
  • 維持費が高いTLD(年間3,000円〜8,000円以上)
TLD特徴・用途備考
.jp日本国内向け。信頼性が高い年間約3,500円〜6,000円
.co.jp法人限定。企業向けの信頼性が高いTLD年間6,000円以上(後述するWhois情報公開代行は利用不可)
.tokyo地域性を強調。ブランド戦略向け年間3,000円〜5,000円
.shopECサイト向け。商用利用に最適年間4,000円〜6,500円

条件、隠れた維持費はもっと注意

例えば某ドットコムなどは

「レンタルサーバサービスの申込で無料」と但し書きがつきます。

そのレンタルサーバが(初年度は無料の代わりに)割高というパターンがあります。その罠に騙されないようにしましょう。

更に、「サービス維持調整費」と称して、更新費用とは別の手数料を取ってくるパターンもあります。

ただ、そのサービス維持調整費との合計を加味しても「他のレジストラと比べて妥当な金額」というケースもありますので、それは「隠れて金取りやがって某ドットコム許すまじ」という怒りはほどほどに。

ものすごく大事なWhois情報公開代行

ドメイン取得時や取得後に、Whois情報公開代行サービスを設定することで、登録者の個人情報の代わりに、ドメイン業者の代理情報が表示されるサービスです。

  • 住所
  • 氏名
  • 電話番号
  • メールアドレス

など、個人/匿名で活動したい人には極めて重要なサービスです。これにより、自宅凸といった物理的な障害から排除されます。

まとめ

そもそもドメイン(domnain)とは

  • 領域
  • 分野
  • 領土

と言った自分の間合い、領域、世界を表す言葉。それ故に、自分が趣味などで運用するドメインは

  • 自分にとって覚えやすく
  • サイト維持のモチベーションにしやすく
  • 更新の維持が明白な

ものを選ぶべきと言う、「自分勝手な中での合理性」を持ちましょうという話でした。

余談

巷で言われている「某ドットコム」のレジストラはホントに評判が悪いのか?

に際しては、以下の古くからのコピペを以て、締めの言葉に代えさせていただきます。

お前ら某ドットコムはクソとか言ってるけど実際に登録してドメイン管理をして言ってんの?
ろくにサイト運営すらもしないで某ドットコム批判してんじゃねーよ
インフルエンサーのお気持ち表明に影響されて某ドットコム批判かよ
俺はここでドメインを取得して某ドットコムが言うほど高くないのを知った
そして思ったんだけどやっぱり門倉ってクソだわ

免責事項:これは甲斐谷忍先生の作品『ONE OUTS』に敬意を表したシステム名/ファンアートであり、公式(集英社、製作委員会など)とは一切関係ありません。

『ONE OUTS』システム番外:ipsetによるUFWの効率化。

はじめに

筆者が用いているWebへの攻撃を防ぐ、MOD_SECURITYとApache設定、シェルスクリプトの連携「ONE OUTSシステム」。これは「実際にWebサイトにアクセスした者」への盾として機能していますが、「アクセス未満」での低レイヤーでの攻撃を仕掛ける者を防ぎきることができません。

例えば、SYNフラッド攻撃はWebサイトへの攻撃を仕掛けるわけではないのでログに残らず、じわじわとリソースを奪っていきます。

かといって、これらのSYNフラッド攻撃は極めて広範囲のIPレンジから仕掛けてくるので

sudo ufw insert 1 deny from xxx.xxx.xxx.xxx

とするには、ufwでのルールが広範になりすぎてメンテナンス性ならびにシステムパフォーマンスの低下を招きます。

これを解決するための手段を設けました。

環境

  • Ubuntu 24.04
  • ufw導入済み

行ったこと

  1. ipsetコマンドをインストールします。
  2. ブロックリストの設定を行います。
  3. ipsetコマンドでSYNフラッド攻撃を行う攻撃者をレンジごとブロックします。

事前注意

これは、カーネルメモリにufwのブロックリストを付与する、「破壊的アップデート」の可能性が発生します。

  • セキュリティポリシー
  • 明確な運用基準

組織単位 で行う必要があります。

手順

ipsetコマンドのインストール

※筆者の好みでaptitudeを用いています。環境に合わせてapt等に読み替えます。

  • パッケージアップデート
sudo aptitude update
  • ipsetインストール
sudo aptitude install ipset

※ 要注意 ※

ここでは、ipset-persistantコマンドを入れていません。なぜなら、ufwと競合する結果、パッケージ管理はufwを破壊する可能性があるからです。

  • ipsetインストール確認
ipset -v
ipset v7.19, protocol version: 7
ipset v7.19: Kernel error received: Operation not permitted

※この、not permittedは、root権限で実行していないため許可されていないというメッセージです。

ipsetのルール変更

  • ブロックしたいIPを格納するための「セット」をメモリ上に作成します。

これは再起動時に消えます

sudo ipset create ufw-blocklist hash:net

ufwにipsetを参照するルールを追加します。

  • ufwの前段ルールをバックアップ
sudo cp -pi /etc/ufw/before.rules /path/to/backup/before.rules.$(date +%Y%m%d)

→ バックアップ先は任意のものを指定します

  • バックアップ確認
sudo diff -u /path/to/backup/before.rules.$(date +%Y%m%d) /etc/ufw/before.rules 

※ここでsudoを付与します。なぜなら、これはroot権限でしか読み取りできないからです

  • ファイル修正

上記、/etc/ufw/before.rulesの内容を慎重に修正します。 *.filterのすぐ下の行です。

# ===================================================================
# "ufw-blocklist" セットに含まれるIPからの全パケットを破棄する
-A ufw-before-input -m set --match-set ufw-blocklist src -j DROP
# ===================================================================

# ok all existing rules
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
  • ファイル修正確認
sudo diff -u /path/to/backup/before.rules.$(date +%Y%m%d) /etc/ufw/before.rules 

以下の差分になっていることを確認します。

 *filter
+# ===================================================================
+# "ufw-blocklist" セットに含まれるIPからの全パケットを破棄する
+-A ufw-before-input -m set --match-set ufw-blocklist src -j DROP
+# ===================================================================
+
+# ok all existing rules

リロード前確認(最重要)

さて、ここまで手順通りに行えばufwのリロードは正常に完了します。しかし、ここで今一度

  • sudo ipset create ufw-blocklist hash:netを実行したか?
  • /etc/ufw/before.rulesを編集したか?
  • この編集は既存ファイルの内容を削除していない(追記のみ)か?

を確認しましょう。確認しなければ、この先に待ち構えているのは「失敗した場合の自分自身のロックアウト」にもつながります。

ufwリロード

よく深呼吸しましょう。実行前に何か飲み物を飲んでおいてもいいぐらいです。

sudo ufw reload

ファイアウォールを再読込しましたのメッセージが出れば成功です!

sudo ufw status

でも状態:アクティブを確認します。

ipset のリストを「永続化」する

ipset-persistent の代わりに、UFW自身の起動・停止スクリプトに、リストの保存・復元を組み込みます。

  • A. 保存用ファイルのパスを定義

まず、ipset のリストを保存するファイルを決めておきましょう。 ここではIPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"と定義します。

  • B. UFW起動時にリストを「復元」する設定

ufw が起動する前に、保存したリストを読み込むようにします。

sudo cp -pi /etc/ufw/before.init /path/to/backup/before.init.$(date +%Y%m%d)

でバックアップを取ります。(バックアップディレクトリを一括にしているならbefore.init.$(date +%Y%m%d)の前にbefore.rules.$(date +%Y%m%d)を作っているはず。「タブの補間はせず、確実にファイルのバックアップを取りましょう)

sudo diff -u /path/to/backup/before.init.$(date +%Y%m%d) /etc/ufw/before.init

で、バックアップが成功していることも確認します。※diffでもsudoを付与します。なぜなら、これはroot権限でしか読み取りできないからです

/etc/ufw/before.initを編集します。

ファイルの一番上(#!/bin/sh の直後)に、以下の行を追記します。

IPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"

# 起動時に ipset リストをファイルから復元する
if [ -f "$IPTABLES_IPSET_SAVE_FILE" ]; then
    ipset restore -f "$IPTABLES_IPSET_SAVE_FILE"
fi
sudo diff -u /path/to/backup/before.init.$(date +%Y%m%d) /etc/ufw/before.init
 #!/bin/sh
+IPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"
+
+# 起動時に ipset リストをファイルから復元する
+if [ -f "$IPTABLES_IPSET_SAVE_FILE" ]; then
+    ipset restore -f "$IPTABLES_IPSET_SAVE_FILE"
+fi

を確認。

  • UFW停止時にリストを「保存」する設定

ufw が停止(またはリロード、シャットダウン)する後に、現在のリストをファイルに保存するようにします。

sudo cp -pi /etc/ufw/after.init /etc/conf_backup/after.init.$(date +%Y%m%d)
sudo diff -u /etc/conf_backup/after.init.$(date +%Y%m%d) /etc/ufw/after.init 

※diffでもsudoを付与します。なぜなら、これはroot権限でしか読み取りできないからです

/etc/ufw/after.initを管理者権限で編集します。 ファイルの一番上(#!/bin/sh の直後)に、以下の行を追記します。

IPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"

# 停止時に現在の ipset リストをファイルに保存する
ipset save -f "$IPTABLES_IPSET_SAVE_FILE"

追記後、

sudo diff -u /etc/conf_backup/after.init.$(date +%Y%m%d) /etc/ufw/after.init 

で差分を確認します。

 #!/bin/sh
+IPTABLES_IPSET_SAVE_FILE="/etc/ufw/ipsets.save"
+
+# 停止時に現在の ipset リストをファイルに保存する
+ipset save -f "$IPTABLES_IPSET_SAVE_FILE"
  • コマンド実行権付与
sudo chmod +x /etc/ufw/before.init /etc/ufw/after.init

→ コマンドを追記しているので重要です!

再度のufwリロード前の確認

ここでも

  • /etc/ufw/before.initを編集し、差分通りか?
  • etc/ufw/before.initを編集し、差分通りか?
  • この編集は既存ファイルの内容を削除していない(追記のみ)か?
  • /etc/ufw/before.init /etc/ufw/after.initに実行権限が付与されているか?

を確認しましょう。確認しなければ、こちらも自分自身のロックアウトにつながります。

ufwリロード

よく深呼吸しましょう。今度は手元にあればお茶菓子を食べてもいいぐらいです。

sudo ufw reload

ファイアウォールを再読込しましたのメッセージが出れば成功です!

sudo ufw status

でも状態:アクティブを確認します。

ここまで来たら:SYNフラッド攻撃への対処

これは、対象のIPアドレスをシャットアウトする「慈悲なき王」です。

ブロック対象は慎重に慎重を期します。

  • メモリ上のリストに即時追加
sudo ipset add ufw-blocklist IPアドレス・NWアドレス

→ 実際のIPアドレスを半角で入力しましょう。

  • メモリ上のリストをファイルに「永続化」
sudo ipset save ufw-blocklist -f /etc/ufw/ipsets.save

(sudo ipset save ではない点に注意してください)

  • 永続化確認
cat /etc/ufw/ipsets.save 

として

create ufw-blocklist hash:net family inet hashsize 1024 maxelem 65536 bucketsize 12 initval 0xcce80b68
add ufw-blocklist IPアドレス・NWアドレス

等と表示されれば成功です。

※この作業はufwリロード不要です。※

まとめ

「相手が回りくどい攻撃をしてきたら、更に回りくどい方法をとらなければならない」という形。

正直、この作業は二度とやりたくない部類に入ります。ですが、一度設定してしまえば

sudo ipset add ufw-blocklist IPアドレス・NWアドレス

で永続的に執拗な攻撃を仕掛ける攻撃者に対処することが可能です。

「杖」に選ばれる買い物のために。(要件定義、してみましょう)

はじめに

ハリー・ポッターシリーズ。ハリーがダイアゴン横丁で杖を手に入れる際のオリバンダー翁の言葉。

The wand chooses the wizard, Mr. Potter. It's not always clear why
「杖が魔法使いを選ぶのです、Mr.ポッター。何故そうなるかは、はっきりとは分かりませんが」

この「何故」に焦点を当てつつ、システム開発における大事なフェイズ「要件定義」になぞらえ

  • 何故これが大切なのか?
  • そして、これが上手くいくとシステム開発が上手くいく(つまり、システムが魔法使いというユーザーを選ぶ)のか?
  • この要件定義を日常生活に落とし込むには?

の3ステップほどで話してみようと思います。

そもそも要件定義とは?

システム開発における要件定義とは、「何を作るか」「何を実現するか」を明確にする、プロジェクトの最も土台となる工程です。

具体的には、ユーザー(魔法使い)がシステム(杖)に何を求めているのか、どのような課題を解決したいのかを徹底的にヒアリングし、その要求を機能や性能の仕様として具体化していく作業を指します。

これは、システムの設計図や仕様書を作成するための「羅針盤」を決める作業であり、「ユーザーが本当に必要とするものは何か?」を深く掘り下げ、開発チームとユーザーの間で共通の認識を築くためのものです。

これが上手くいくと?

オリバンダー翁の言葉のように、「杖が魔法使いを選ぶ」という関係性がシステム開発にも当てはまります。要件定義が上手くいくと、システムはユーザーの真のニーズに応える「まさにその杖」となり、開発全体がスムーズに進みます。

The wand chooses the wizard, Mr. Potter.

この「選ばれた状態」とは、単に機能が揃っているというだけではありません。ユーザーの潜在的な要求や、言葉にはなっていない「不便さ」までを汲み取り、それを解決する最適な形(システム)が提供されることを意味します。

要件定義が成功することで、開発の途中で「思っていたものと違う」といった手戻りや、不要な機能の開発を防ぐことができ、結果として

  • 予算とスケジュールの遵守
  • 高品質なシステムの実現
  • ユーザー(魔法使い)の満足度向上

といった、すべての関係者にとって良い結果(システムが魔法使いというユーザーを選ぶ)に繋がるのです。

自分自身の例:スマートウォッチを選んだ理由と機種選定までの流れ

何故必要だったのか

健康診断で芳しくない数値が出たことからこの話は始まります。

加齢から来る体調不良は目に見えて明らかでしたし、「このままでは危険」と判断。一念発起して体調管理できる方法を考えました。

そのためには「今の自分がどういう状況にあるのか?」を客観的、絶対的な目線で確認する(自分自身のロギング)は必要不可欠だと結論づけます。

なぜなら、

  • 節食しているのに太るのはどうして?
  • 眠れないとき/眠れたときの状態でパフォーマンスの差

などを考慮しないと、どのようなトレーニングをしても非効率/或いは心身を痛めることになるのは目に見えて明らかだからです。

「どこに進むか(どのような健康を改善するか)を決めるためには自分自身の現在地(体調)を知る」

を前提として考えないと、どのような健康法/ダイエット方法を試したところで無意味。この、自分自身の体調を知るために最もシンプルな方法が

「スマートウォッチによる自分の体調の視覚化」

でした。

特に

  • 歩数(動きの)管理
  • 睡眠

に焦点を当てます。

逆算して必要だったスマートウォッチ

  • 自分の性格上、フィットネスジムや健康管理を診てもらうというのは性に合わないし、強制されるのはそもそも嫌い。
  • それなら、ウェアラブルデバイスによって自分のペースで確認する方が以下の三者にとっていい結果になる。
    • 自分自身
    • お金(ジムの入会費やサブスク)
    • サービス提供者

と定義したのが私の「最初の要件定義」。ここが定まれば

変な健康商法や怪しいダイエットなんぞで大金と時間、健康を失いたくない。その値段を考えたら、多少の出費は投資と考える

で、どんなモデルを選ぶかを考えていきます。

つまり、要件定義と軽々に言ったところで

  • 自分(顧客)にとって本当に必要な商品/サービスは何か
  • そのためのシンプルな/或いはハイテクな解決手段とは

を確認しないと、要件定義の失敗は必至。その後の商品選定も単なる衝動買いに終わります。

商品選定基準

肯定要素(Affirmative)と否定要素(Negative)の2軸を元に考えました。

○ 肯定要素(Affirmative)

  • 睡眠管理のためバッテリーが長持ちすること。
    • 眠る前に充電のために時計を外したり、眠っている間のバッテリー切れは論外です。
  • 視認性。
    • 時計本来の「現在地の把握」のため、液晶がオフのままというのは避けたい事象です。
    • “Watch”の名前を冠するなら、その本来機能「確実な時の刻み」は外せません。
  • タフネス。
    • 風雨に晒される / 水仕事による時計の故障は考えたくありません。

○否定要素(Negative)

  • タッチ操作
    • 多くのスマートウォッチが採用するタッチ操作は不要でした。
    • べたついた手で触る可能性が高いことや時計そのものの文字の細かさは少々辛くなった年齢にさしかかっています。
    • このタッチ操作による誤操作の可能性は極力ゼロに抑えたいです。
  • 大きな筐体
    • キーボードを使う職業であるため、大きな文字盤が手首と干渉する事態は避けたいです。
    • キーボードを使うときに時計を外すのは、大前提の条件である「健康管理」という目的から逸脱します。

この時点でApple Watch / Pixel Watchの2つは対象から外れます。必要なのは機能であってブランドではないのです。

そして選ばれたGarmin Instinct

この選定基準が定まったら、後は実店舗での確認です。これはとても重要です。どんなに上記の条件に充たしたとしても、最終的な、最後の一藁は

  • 「何かデザインが違う」
  • 「気に入らない」

にかかっているからです。幸いにも、この目的を伝えることができれば、(良心的な大型量販店であれば)いい物を提案してくれます。この「わがまま」といえる肯定要素と否定要素全てをクリアしたのがGarmin Instinctでした。

  • 下手したら3週間は持つ驚異的なスタミナ
  • アプリ連携による体調(特に睡眠)管理
  • タフネスさは多くのサイクリストやマラソンランナーなどの愛好者がいることで証明済み。
  • 物理ボタン5つという無骨なデザインで確実な操作
  • 常時表示され、直射日光でも確実に視認できる液晶
  • 筐体の小ささ。40mmの直径でもOK

そして、一番大切だったフィット感。この軽さ / フィット感は、まさに「杖が魔法使いを選んだ瞬間」でした。こうして迎えられたスマートウォッチは無事に購入手続きが終わり、

  • 時間
  • 歩数
  • 睡眠

を確実に記録し、健康改善のきっかけとなりました。

で、結局使い続けられているのか? / 効果はあったのか?

その両者ともに「肯定(Affirmative)」です。

2年半ほど使い続け、この記録を元に、食生活と睡眠習慣を改めます。それにより、特に運動を増やしたわけでもなく1年で5kgほどの自然な体重減と、翌年以降の健康診断でも数値は目に見えて改善されました。

そして、その2年半の記録を続けた2年半後。バッテリーの持ちが悪くなってきたため新たに後継モデル

Garmin Instinct E

という、新たなウェアラブルデバイスを求めたほど。こちらも「更なる軽さ」と「フィット感」により、確実な時の刻みと健康の管理に役立ってくれることでしょう。

まとめに変えて「デジタルの方がいい場合もある」

これは、「デジタルよりアナログに重きを置いている」という筆者の記事に対する突っ込みの反証となります。

睡眠を管理するというのはメモ帳などに頼るのは到底無理です。

  • 何時に寝て
  • 何時に起きたか

はある程度判別できるでしょう。しかし、

  • 完全に熟睡状態に入ったのはいつか
  • 何回ぐらい起きたのか
  • どのぐらい深い眠りがあったのか

を覚えているというのはどだい無理な話です。この「睡眠管理」並びに「寝付けたのか否か」を判断するのはできません。

「常に自分自身を記録する静かな目」

はデジタルのハイテク機器である必要があったのです。

以下、『マクベス』第二幕第2場の以下の言葉。

“Sleep no more! Macbeth does murder sleep”
— the innocent sleep,
Sleep that knits up the ravelled sleave of care,
The death of each day's life, sore labour's bath,
Balm of hurt minds, great nature's second course,
Chief nourisher in life's feast.

「もう眠れない!マクベスは眠りを殺した!」
— 汚れなき眠り、
心の糸のほつれを繕う眠り、
一日の命の死、疲れた労働を癒す湯、
傷ついた心に塗る軟膏、
大自然の第二の恵み、
生命の宴の主なる滋養。

私にとってのGarmin Instinctは、マクベスが殺した『心の糸のほつれを繕う眠り』を取り戻すための、デジタルな『軟膏(Balm of hurt minds)』だったという強引なオチで本稿を締めくくります。

ボードゲーム『ロストシティ タイルゲーム』感想。

オリジナルは未プレイ。再販と同時にタイルバージョンが出ていたのでプレイしました。正直、ここまで面白いとは思いませんでした。

冒険の本質である「行くか、行かざるか。それが問題だ(To Go, or Not to Go, that is the question)」に迫る

  • 進むか留まるかのジレンマ
  • リスク計算と駆け引き
  • 強烈なインタラクション

を極めてシンプルなコンポーネントに落とし込んだ2人専用の傑作です。

ゲームの概要とルール

プレイヤーは探検家となり、様々な遺跡を探検していきます。

ゲームのルールはシンプル。

  • 場に伏せられたタイルをめくって探検する(自分の場に配置)か、しないか(取り置く)を決める。
  • 既に公開されたタイルで探検を進める。
  • 取り置いたタイルで探検を進める。

の3つのみ。ここからルールに従ってタイルを配置。タイルがすべて公開されたらゲーム終了。

タイルの得点が高い方が勝者となります。

このゲームの素晴らしいところ

言語依存のないシンプルなコンポーネントとルール

なんと、数字(と記号)が描かれたタイルとログブック(一時置き場)のみ。スリーブもインサートも不要。

この数字がわかりやすくもジレンマ満載のルールに落とし込まれています。

一度置いたタイルは昇順でしか置くことができません。(黄色のタイルに2を置いて、7を置いたら3~6を置けない)このルールにより、「進むか、引くか」のチキンレース要素を加速させます。

盛大なマイナスとプラスの乗算

得点計算は自分が配置したすべての得点を足した後に「20を引いた数」。この、足きりどころではない減点要素により「栄光(勝利)のためには進むべき」という道を示します。

そして、事前調査「×2」のタイルの存在。このタイルを前もって置くことができれば、この合計得点(合計点数-20)の倍の数値を得ることができます。

この「減点要素」が加わると「破滅」もあり得るリスクがあります。

例を見てみましょう。

  • 黄色い列に「×2」タイルを置いた状態で2 , 5, 7, 8, 9を置きました。合計は31。ここから20を引くことで11。そして×2で22点を取得。
  • 茶色い列に「×2」タイルを置いた状態で4しかおけませんでした。ここから20を引くことで-16。そして×2は、-32。
  • 青い列には何も置きませんでした。この場合は0。得点は得られませんが失点も起きません。

つまり、中途半端な探検は身の破滅。完遂した探検は栄光の階という、非常にリアルな探検要素がシンプルなルールで研ぎ澄まされています。

明らかになるにつれ動きづらくなる逆説

先に挙げた昇順でしか置けないルールが加わると、「このタイルは置けないから公開したままにする」機会が増えます。この公開情報は相手を利する結果になります。(公開されたタイルを置くことができるので)

「後で使うかもしれないから」とログブックに留め置いたとしても、この上限はわずかに2。これによって、「相手の狙いと自分の欲望を秤にかける」インタラクションが産まれます。

この、探検には己の運も必要というリアルな点と機会損失/相手の利得の利用もまた、本作の醍醐味でした。

このゲームの少しの問題点

色合い

青と紫の判別が、会場によっては見えづらかったのが気になりました。

運ゲーに見えた実力ゲー

ランダムなタイルをめくるという運の要素がありながらも

  • 自分の意図
  • 相手の意図

を読んだ上で

  • 残りの枚数はどれぐらいかの確率計算
  • それを見越したディシジョンメイキング
  • 損切りと行動力
  • いつ終了トリガーを引くか
  • 「運の流れはどちらにあるか?」の直感

などが必要。実力が拮抗していないとワンサイドゲームになります。

まとめ

この『ロストシティ タイル』は冒険の本質である「進むか引くかの判断力」と「大胆さと慎重さの二面性」をシンプルなルールと深い読み合いにまとめた素晴らしい作品。

この深い読み合いが20分程度(慣れれば10分程度)で終わるというのも驚嘆すべきものです。性質上、リプレイ性も高いので長く遊べる作品ですので「比較的短いプレイ時間でひりつく勝負がしたい」方には文句なしにおすすめできる優等生的な作品です。

「あなたにとっての“ナイフ”」とは?-1- (『MASTERキートン』“プロフェッサー”に学ぶ道具のセレクト)

「信頼の置ける道具、持っていますか?」という問いかけと私の回答というお話。

はじめに

漫画『MASTERキートン』に以下のやりとりがあります。

「やめておけ」
「…………」
「拳銃の方が、ナイフよりも速いと思っているんだろう。
 だが、拳銃はデリケートな道具だ。
 弾が出ないかもしれないし、
思い通り的に当たるとは限らん。
おまけに拳銃は、
抜き、構え、引き金を引くまでに三動作(スリーアクション)……
 その点ナイフは、一動作(ワンアクション)で終わる。
この距離なら、絶対に俺が勝つ!!
どうする? それでもやってみるかね?」

これは「至近距離でのナイフの有用性」を示したものであり、実際にその通りだという説得力があるものです。

では、この言説は本当なのか? ということで、AIによる試算を行います。

ナイフ vs. 拳銃:速さの決定的な差

この原則は、「21フィート・ルール(タフ・テスト)」と呼ばれる、銃器を携行する際の安全距離を示す経験則で裏付けられます。

拳銃の「三動作」にかかる時間

拳銃で有効な射撃を行うには、

  1. 抜き(ドロー)
  2. 構え
  3. 引き金を引く

最低限の三動作が必要です。

動作所要時間(訓練された者)
ドローから有効射撃まで約 1.5 秒 ~ 2.0 秒

ナイフ攻撃の「一動作」にかかる時間

ナイフを持った人間が相手に致命的な一撃を加える動作は一動作で完了し、さらに相手に向かって距離を詰める速度が加わります。

動作所要時間(突進・刺突)
約 6.4メートル(21フィート)を詰める約 1.5秒

速さの結論(21フィート・ルール)

ナイフを持った人間は、約 6.4メートル(21フィート)の距離から突進してくる場合、銃を抜いて発砲するまでの時間とほぼ同等で相手に到達できます。

  • 漫画のシーンのように、21フィートよりも遥かに近い距離(数フィート)の場合、拳銃の三動作が完了する前に、ナイフの一動作による攻撃は確実に相手に到達し、致命傷を与えることが可能です。
  • プロフェッサーの「この距離なら、絶対に俺が勝つ!!」という言葉は、この時間と距離の絶対的な差に基づいた、極めて正確な戦術的宣言なのです。
  • (もちろん、拳銃に慣れていない/ナイフの熟達、生死のやりとりの覚悟ができていない/できているの差は一番大きいでしょう)

拳銃の「デリケートさ」がもたらすリスク

プロフェッサーが指摘する「拳銃はデリケートな道具だ」という点も、至近距離戦においてナイフの優位性を裏付けます。

  • 機能不全のリスク:
    • 弾が出ないかもしれない(ジャミング、装填不良)。機械的な構造を持つ拳銃は、至近距離でのもみ合いや、些細な不具合で機能不全を起こすリスクがゼロではありません。
  • 命中精度の問題:
    • 思い通り的に当たるとは限らん(照準の困難)。突発的な近接戦闘では、冷静に狙いを定める余裕がなく、また物理的な妨害により、有効な射撃が困難になります。

この「デリケートさ」と「動作の多さ」は、そのまま私の道具を選ぶポイントにも表れています。

「デジタル器具の逆説」

私は当ブログにおいて

  • Redmine
  • Growi
  • Nextcloud
  • BookStack
  • (Firefly等も)

といった、様々なOSSのWeb記録ツール、そしてそれらを扱うPCやスマートデバイスなどを紹介してきましたが、そもそもの問題として私は「デジタルな道具を完全に信じていません」。その証拠にこちらの道具群をご覧ください。

道具群

  • ペンケース
    • ほとんどがLAMY Safari万年筆
  • 手帳類
    • ほぼ日手帳
    • ジブン手帳
    • トラベラーズノート
    • 情報カード
      等。これらは全て普段から持ち歩いているものです。(当然、鞄はギッシリです)ですが、それなりに理由があります。

「アイディアの揮発性」

閃いたアイディア、特に「100文字程度の短いひらめき」は、掴まえようとしなければ水蒸気のようにたちまち消えてしまいます。この一瞬の勝負において、私はデジタルツールを信用していません。

プロフェッサーの言葉を借りるならば、アイディアを捕捉するこの至近距離の戦闘では、デジタルツール(拳銃)の「三動作」は、紙とペン(ナイフ)の「一動作」に敗北します。

アイデア記録における「動作」と「時間」の比較

以下は、100文字程度のアイディアを記録し終えるまでにかかる動作と時間の比較です。

道具道具の比喩記録までの動作所要時間(目安)思考の中断リスク
紙とペンナイフ1 動作約 20 秒極小
デジタルツール拳銃3 動作約 38 秒以上

紙とペン(ナイフ):確実な「一動作」

紙とペンは、「書く」という一動作で記録が完了します。この約 20 秒間、思考の流れを一切止めることなく、揮発性の高いアイディアを紙の上に瞬時に定着させることが可能です。これは、プロフェッサーが示した最短距離、最小動作で確実に仕留めるという原則そのものです。

デジタルツール(拳銃):遅延を生む「三動作」

スマートフォンやPCのアプリで記録する場合、必ず以下の「三動作」が介入します。

  1. 起動(抜き):スリープ解除、パスコード解除、アプリ起動。
  2. 新規作成(構え):新規メモ画面への遷移、ツール内のファイル選択。
  3. 入力(発射):タイピング。

この「抜き、構え」のプロセスで生じる約 20 秒弱のタイムラグこそが、拳銃がデリケートな道具である最大の理由です。アイディアは、ツールを起動し構えている間に、すでに空中に消え去っている可能性があるのです。

 → このアイディアの揮発性というのは非常に致命的なものであるというのは皆様も経験があると思います。

それ以上に大切な「デジタルメモのデリケートさ」

スマートデバイスの動作不良の確率は、メモやペンよりも高いことに異論は無いと思います。

それ以上に

  • NW不調によりログイン不可(Webサービスを用いている場合)
  • 同期の不安定
  • 何よりもサービス終了の恐怖

はつきまといます。

反面、紙とペンなら

  • ほぼ確実に書くことができます。
  • 忘れたとしても(都会であればなおさら)すぐに手に入ります。
  • 「自分さえ分かれば」どんな言語、記号、絵だろうと分かるという自由度があります。
  • 何よりも「ペンと紙が生産終了になる」というケースはかなりの世紀末の状況になると思われます。

まとめ

「ちょっとしたアイディアのメモ」という

  • 即時性
  • 確実性
  • 安定性

が求められる状況下においては、紙と筆記具がこそが、思考を守る最も信頼できる道具です。

なぜなら、思考の戦いにおいては以下のブチャラティの言葉に集約されます。

“ぶっ殺してやる”ってセリフは終わってから言うもんだぜ
俺たちギャングの世界ではな
――『ジョジョの奇妙な冒険 黄金の風 偉大なる死(ザ・グレイトフル・デッド)』

「思いついたときには書き終えている」。この「一動作(ワンアクション)の速さ」こそが、紙とペンの持つ最大の魅力であり、
アイディアを確実に仕留める「ナイフ」なのです。

  • それぞれの道具を選ぶ理由
  • もちろん、デジタルが優れている場面

等はまた後の話に(気が向いたときに)記します。

Page 2 of 274

Powered by WordPress & Theme by Anders Norén