Posts on sonohen's tech blog

Cachixを使用する

Fri, 30 Oct 2026 00:00:00 +0000

課題と目的

私の環境では emacs-unstable-pgtk と openlogi は、更新が入る度にビルドが走る。それはそれで構わないのだが、一方で日常作業をしている裏でリソースを取られるのも少し違う気がした。

そこで、以下のような構成を実装した。

プレーンテキスト
GitHub(master) <--[checkout]-- GitHub Actions(毎週金曜日4:30起動 / Ubuntu) --[push]--> Cachix
 ^ |
 `--------[git pull]-------- ThinkPad E14 Gen 3 <--------[nixos-rebuild switch]--------/

この構成により、最も時間を要している emacs-unstable-pgtk と openlogi はGitHub Hosted Runnerでビルドされるので、 ThinkPadで nixos-rebuild switch --flake ./nixos#thinkpad を実行したときに、ローカルビルド時間を大幅に短縮できるというのが目論見である。 (ローカルビルドを完全に無くすとは言っていない)

日常の運用

以下の通りになる。

毎週金曜日4:30 GitHub Actionsが起動する。
- flake.lock の更新
- emacs-unstable-pgtk のビルドとCachixへの転送
- openlogi のビルドとCachixへの転送
- flake.lock のコミットとリポジトリへのプッシュ
毎週土曜日に、ThinkPadで git pull, sudo nixos-rebuild switch --flake ./nixos#thinkpad を実行。
- このタイミングで、 emacs-unstable-pgtk や openlogi はビルドされず、Cachixからダウンロードされる。

実装

`configuration.nix`

cachix.org からnixバイナリキャッシュを取得するように設定する。

nix
extra-substituters = [
 "https://<キャッシュ名>.cachix.org"
];

extra-trusted-public-keys = [
 "<キャッシュ名>.cachix.org-1:<公開鍵>"
];

`flake.nix`

ストアパスが一致するように設定する。

nix
...
outputs = { self, nixpkgs, home-manager, nixvim, openlogi, beancount-mode, emacs-overlay, ... }: {
 packages.x86_64-linux = {
 emacs = self.nixosConfigurations.thinkpad.pkgs.emacs-unstable-pgtk;
 openlogi = self.nixosConfigurations.thinkpad.config.programs.openlogi.package;
 };

 nixosConfigurations = {
 thinkpad = nixpkgs.lib.nixosSystem {
 system = "x86_64-linux";

 modules = [
 ./common/configuration.nix
 ./thinkpad/configuration.nix
 home-manager.nixosModules.home-manager
 openlogi.nixosModules.default

 {
 nixpkgs.overlays = [
 emacs-overlay.overlays.emacs
 ];
 }

 {
 home-manager.sharedModules = [
 nixvim.homeModules.nixvim
 ];

 home-manager.extraSpecialArgs = {
 inherit beancount-mode;
 };
 }

 {
 home-manager.useGlobalPkgs = true;
 home-manager.useUserPackages = true;
 home-manager.users.sonohen = import ./common/home.nix;
 }
 ];
 };

`.github/workflows/nixos-parts-build.yml`

これが毎週金曜日4:30に起動する。

YAML
name: Update and Build NixOS Packages

on:
 schedule:
 - cron: "30 4 * * 5"
 timezone: "Asia/Tokyo"
 workflow_dispatch:

permissions:
 contents: write

concurrency:
 group: nixos-update-build
 cancel-in-progress: false

jobs:
 build:
 runs-on: ubuntu-24.04
 timeout-minutes: 360

 steps:
 - name: Checkout
 uses: actions/checkout@d23441a48e516b6c34aea4fa41551a30e30af803 # v6.1.0
 with:
 ref: master
 persist-credentials: false

 - name: Install Nix
 uses: cachix/install-nix-action@8aa03977d8d733052d78f4e008a241fd1dbf36b3 # v31.10.6
 with:
 extra_nix_config: |
 max-jobs = 1
 cores = 2

 - name: Setup Cachix
 uses: cachix/cachix-action@38b082610b782e7e93e209c35fd730d399dee866 # v17
 with:
 name: sonohen-cachix
 authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'

 - name: Update flake.lock
 working-directory: nixos
 run: nix flake update

 - name: Build Emacs
 run: |
 nix build ./nixos#emacs \
 --no-link \
 --print-build-logs

 - name: Build OpenLogi
 run: |
 nix build ./nixos#openlogi \
 --no-link \
 --print-build-logs

 - name: Commit and push flake.lock
 run: |
 if git diff --quiet -- nixos/flake.lock; then
 echo "No updates"
 exit 0
 fi

 git config user.name "github-actions[bot]"
 git config user.email "41898282+github-actions[bot]@users.noreply.github.com"

 git add nixos/flake.lock
 git commit -m "chore(nix): update flake.lock"

 git -c http.extraheader="AUTHORIZATION: basic $(printf 'x-access-token:%s' "$GH_TOKEN" | base64 -w0)" \
 push origin HEAD:master
 env:
 GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

結果

ビルドの所要時間と容量

emacs-unstable-pgtk のビルド時間は、2026-10-30現在の emacs-unstable-pgtk-31.1 で35分35秒。
openlogi のビルド時間は、2026-10-30現在の 0.8.19 で27分20秒。
Cachixの利用容量は642.6 MiB。
- 無料で利用できる容量が5.0GiBなので、5~6世代持たせておけばよいかな。

今後の課題

neovimをこの構成のなかに入れておくかどうするかを検討する必要がある。次の更新のタイミングで検討することにしたい。

NixOSでZFSからデータを救出する

Mon, 26 Oct 2026 00:00:00 +0000

概要

Ubuntu Linuxを使用していたが、自分のLinux環境をファイルで定義できるNixOSに興味を持ち、この週末に移行した。 Ubuntu LinuxではLUKSで暗号化したZFSパーティションを使用していたため、NixOSからZFSなパーティションをマウントしてデータ移行する必要があった。その対応の記録をしたので、ブログにまとめることにする。

環境

NixOS 26.05
ThinkPad E14 Gen 3
- /dev/nvme0n1: KBG40ZNT256G(Toshiba) - NixOSインストール済
- /dev/nvme1n1: Samsung SSD 980 500GB - Ubuntu Linuxインストール済

目的

以下を実現することを目的とする。

/dev/nvme1n1 から /dev/nvme0n1 に /home のデータを移行する
/dev/nvme1n1 を消去し、新たにext4のパーティションを作成し、それをNixOSの /home にマウントする

データ移行の流れ

大きくは以下の4つの手順を踏む。

現状の把握
LUKS鍵の取り出し
ZFSパーティションのマウントとデータの移行
ディスクのフォーマットと /home ヘのマウント

現状の把握

ディスクの状況

Shell
lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS,MODEL

プレーンテキスト
NAME PATH SIZE TYPE FSTYPE UUID MOUNTPOINTS MODEL
nvme0n1 /dev/nvme0n1 238.5G disk KBG40ZNT256G TOSHIBA MEMORY
├─nvme0n1p1 /dev/nvme0n1p1 2G part vfat E29B-9551 /boot
├─nvme0n1p2 /dev/nvme0n1p2 24G part swap 15f27874-dfbd-4afb-92cb-56bd089cea04 [SWAP]
└─nvme0n1p3 /dev/nvme0n1p3 212.5G part ext4 ad329431-4846-495f-b312-67d24b2a005c /nix/store
 /
nvme1n1 /dev/nvme1n1 465.8G disk Samsung SSD 980 500GB
├─nvme1n1p1 /dev/nvme1n1p1 1G part vfat FACF-1404
├─nvme1n1p2 /dev/nvme1n1p2 2G part zfs_member 12601984913637652299
├─nvme1n1p3 /dev/nvme1n1p3 8G part
└─nvme1n1p4 /dev/nvme1n1p4 454.7G part zfs_member 14549146316260236921

`ZFS` の状態

あらかじめ configuration.nix に以下の記述を入れたうえでビルドしておく必要がある。

nix
networking.hostId = "1aeba738";
boot.supportedFilesystems = [ "zfs" ];
boot.zfs.forceImportRoot = false;

なお networking.hostId には、以下を実行して取得した値を設定する。

Shell
head -c 8 /etc/machine-id

以下のように nix shell nixpkgs#zfs を実行すれば環境を汚すこともないので便利である。

Shell
sudo nix shell nixpkgs#zfs -c zpool import

無事に認識されていることがわかる。

プレーンテキスト
 pool: bpool
 id: 12601984913637652299
 state: ONLINE
status: The pool was last accessed by another system.
action: The pool can be imported using its name or numeric identifier and
	the '-f' flag.
 see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-EY
config:

	bpool ONLINE
	 nvme-eui.002538db11c4531d-part2 ONLINE

 pool: rpool
 id: 14549146316260236921
 state: ONLINE
status: The pool was last accessed by another system.
action: The pool can be imported using its name or numeric identifier and
	the '-f' flag.
 see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-EY
config:

	rpool ONLINE
	 nvme-eui.002538db11c4531d-part4 ONLINE

ちなみに rpool がUbuntu Linuxで言うところの / である。

LUKS鍵の取り出し

Ubuntu Linuxの / をマウントするためのディレクトリとして /mnt/zfs-recovery/ を作成する。マウントし rpool の状態を確認する。

Shell
sudo nix shell nixpkgs#zfs -c zpool import -f -o readonly=on -N -R /mnt/zfs-recovery rpool
sudo nix shell nixpkgs#zfs -c zfs list -r -o name,mountpoint,canmount,encryption,keystatus rpool

プレーンテキスト
NAME MOUNTPOINT CANMOUNT ENCRYPTION KEYSTATUS
rpool /mnt/zfs-recovery off aes-256-gcm unavailable
rpool/ROOT none off aes-256-gcm unavailable
rpool/ROOT/ubuntu_094mo3 /mnt/zfs-recovery on aes-256-gcm unavailable
rpool/ROOT/ubuntu_094mo3/srv /mnt/zfs-recovery/srv on aes-256-gcm unavailable
rpool/ROOT/ubuntu_094mo3/usr /mnt/zfs-recovery/usr off aes-256-gcm unavailable
rpool/ROOT/ubuntu_094mo3/usr/local /mnt/zfs-recovery/usr/local on aes-256-gcm unavailable
rpool/ROOT/ubuntu_094mo3/var /mnt/zfs-recovery/var off aes-256-gcm unavailable
rpool/ROOT/ubuntu_094mo3/var/games /mnt/zfs-recovery/var/games on aes-256-gcm unavailable
rpool/ROOT/ubuntu_094mo3/var/lib /mnt/zfs-recovery/var/lib on aes-256-gcm unavailable
rpool/ROOT/ubuntu_094mo3/var/lib/AccountsService /mnt/zfs-recovery/var/lib/AccountsService on aes-256-gcm unavailable
rpool/ROOT/ubuntu_094mo3/var/lib/NetworkManager /mnt/zfs-recovery/var/lib/NetworkManager on aes-256-gcm unavailable
rpool/ROOT/ubuntu_094mo3/var/lib/apt /mnt/zfs-recovery/var/lib/apt on aes-256-gcm unavailable
rpool/ROOT/ubuntu_094mo3/var/lib/dpkg /mnt/zfs-recovery/var/lib/dpkg on aes-256-gcm unavailable
rpool/ROOT/ubuntu_094mo3/var/log /mnt/zfs-recovery/var/log on aes-256-gcm unavailable
rpool/ROOT/ubuntu_094mo3/var/mail /mnt/zfs-recovery/var/mail on aes-256-gcm unavailable
rpool/ROOT/ubuntu_094mo3/var/snap /mnt/zfs-recovery/var/snap on aes-256-gcm unavailable
rpool/ROOT/ubuntu_094mo3/var/spool /mnt/zfs-recovery/var/spool on aes-256-gcm unavailable
rpool/ROOT/ubuntu_094mo3/var/www /mnt/zfs-recovery/var/www on aes-256-gcm unavailable
rpool/USERDATA none off aes-256-gcm unavailable
rpool/USERDATA/home_lqdl5w /mnt/zfs-recovery/home on aes-256-gcm unavailable
rpool/USERDATA/root_lqdl5w /mnt/zfs-recovery/root on aes-256-gcm unavailable
rpool/keystore - - off -

rpool/USERDATA/home_lqdl5w が /home のデータセットであることがわかる。 KEYSTATUS が unavailable になっているので、 encryptionroot を確認する。

Shell
sudo nix shell nixpkgs#zfs -c zfs get -o property,value encryptionroot,keylocation,keyformat,keystatus,mountpoint,canmount rpool

プレーンテキスト
PROPERTY VALUE
encryptionroot rpool
keylocation file:///run/keystore/rpool/system.key
keyformat raw
keystatus unavailable
mountpoint /mnt/zfs-recovery
canmount off

Ubuntu Linux では rpool/keystore/system.key が存在し、起動時に /run/keystore/rpool にマウントされる。

Shell
sudo nix shell nixpkgs#cryptsetup -c cryptsetup open --readonly /dev/zvol/rpool/keystore keystore-rpool

以下のコマンドを実行し、確認する。

Shell
lsblk -f /dev/mapper/keystore-rpool

プレーンテキスト
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
keystore-rpool ext4 1.0 keystore-rpool d18e3c3c-d0fb-4507-94bc-61327e95edc4

期待される場所(keylocation file:///run/keystore/rpool/system.key)で参照できるようにマウントする。

Shell
sudo mkdir -p /run/keystore/rpool
sudo mount -o ro,noload /dev/mapper/keystore-rpool /run/keystore/rpool
sudo test -s /run/keystore/rpool
sudo nix shell nixpkgs#zfs -c zfs load-key rpool

ZFSパーティションのマウントとデータの移行

ここまでで rpool を読み込むための鍵を入手できたので rpool/USERDATA/home_lqdl5w をマウントする。

Shell
sudo nix shell nixpkgs#zfs -c zpool get altroot rpool
sudo nix shell nixpkgs#zfs -c zfs get mountpoint,canmount,keystatus rpool/USERDATA/home_lqdl5w

keystatus = available, canmount = on であることが確認できる。

プレーンテキスト
NAME PROPERTY VALUE SOURCE
rpool altroot /mnt/zfs-recovery local
NAME PROPERTY VALUE SOURCE
rpool/USERDATA/home_lqdl5w mountpoint /mnt/zfs-recovery/home local
rpool/USERDATA/home_lqdl5w canmount on local
rpool/USERDATA/home_lqdl5w keystatus available -

マウントし、内容を確認する。

Shell
sudo mkdir -p /mnt/zfs-recovery/home
sudo nix shell nixpkgs#zfs -c zfs mount rpool/USERDATA/home_lqdl5w
sudo findmnt -S rpool/USERDATA/home_lqdl5w
ls -la /mnt/zfs-recovery/home

プレーンテキスト
TARGET SOURCE FSTYPE OPTIONS
/mnt/zfs-recovery/home
 rpool/USERDATA/home_lqdl5w
 zfs ro,nodev,relatime,xattr,posixac
total 22
drwxr-xr-x 3 root root 3 Oct 4 09:43 .
drwxr-xr-x 3 root root 4096 Oct 25 14:33 ..
drwxr-x---+ 32 sonohen 1000 59 Oct 24 23:07 sonohen

ここまできたら、あとは rsync を使用してデータを救出すればよい。 /dev/nvme1n1p1 を /mnt/new-home にマウントし、 /home の全データを rsync で移行する。

Shell
sudo mkdir -p /mnt/new-home
sudo mount /dev/nvme1n1p1 /mnt/new-home
sudo nix shell nixpkgs#rsync -c rsync -aHAXx --numeric-ids /home/ /mnt/new-home/
blkid -s UUID -o value /dev/nvme1n1p1

ディスクのフォーマットと /home へのマウント

`rpool` の切り離し

Shell
sudo nix shell nixpkgs#zfs -c zfs unmount rpool/USERDATA/home_lqdl5w
sudo umount /run/keystore/rpool
sudo nix shell nixpkgs#cryptsetup -c cryptsetup close keystore-rpool
sudo nix shell nixpkgs#zfs -c zpool export rpool

切り離し後の確認を行う。nvme1n1がマウントされていないことを確認する。

Shell
sudo findmnt -T /
sudo findmnt -T /boot
sudo findmnt -T /home
lsblk -o NAME,SIZE,MODEL,FSTYPE,MOUNTPOINTS /dev/nvme1n1

プレーンテキスト
TARGET SOURCE FSTYPE OPTIONS
/ /dev/nvme0n1p3 ext4 rw,relatime
TARGET SOURCE FSTYPE OPTIONS
/boot /dev/nvme0n1p1
 vfat rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=is
TARGET SOURCE FSTYPE OPTIONS
/ /dev/nvme0n1p3 ext4 rw,relatime
NAME SIZE MODEL FSTYPE MOUNTPOINTS
nvme1n1 465.8G Samsung SSD 980 500GB
├─nvme1n1p1 1G vfat
├─nvme1n1p2 2G zfs_member
├─nvme1n1p3 8G
└─nvme1n1p4 454.7G zfs_member

パーティションを作成する

この作業は破壊的であるため、データのバックアップが完了していることを再確認してから実行する。

Shell
sudo nix shell nixpkgs#gptfdisk -c sgdisk --clear --new=1:0:0 --typecode=1:8300 -change-name=1:home /dev/nvme1n1
sudo nix shell nixpkgs#parted -c partprobe /dev/nvme1n1
sudo udevadm settle
sudo wipefs -a /dev/nvme1n1p1
sudo mkfs.ext4 -L home /dev/nvme1n1p1

Shell
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS /dev/nvme1n1

プレーンテキスト
NAME SIZE TYPE FSTYPE MOUNTPOINTS
nvme1n1 465.8G disk
└─nvme1n1p1 465.8G part ext4

`configuration.nix` の修正

以下を追記し、リビルドして再起動する。再起動後 /dev/nvme1n1p1 が /home にマウントされていることを確認する。なお、=/dev/nvme1n1p1= (ext4ファイルシステム) のUUIDは blkid -s UUID -o value /dev/nvme1n1p1 で取得できる。

nix
fileSystems."/home" = {
 device = "/dev/disk/by-uuid/66cbb556-4c8b-4480-8ec5-b40484996a4b";
 fsType = "ext4";
};

後始末

冒頭で configuration.nix に追記した以下の記述は不要なので消す。

nix
networking.hostId = "1aeba738";
boot.supportedFilesystems = [ "zfs" ];
boot.zfs.forceImportRoot = false;

感想

順を追って対応すればなんら難しくはないのだが、面倒臭い作業ではある。当面対応したくはないのだが、また機会がありそうなので、記録しておく。

Ubuntu 26.04 LTSでScanSnap S1100を使う

Sat, 17 Oct 2026 00:00:00 +0000

ScanSnap S1100をUbuntu 26.04 LTSで使えるようにした。ファームウェアを配置し、SANEの設定を変更したところ、スキャナーとして認識された。gscan2pdfからのスキャンもできたので、当面はこの構成で使うことにした。

ファームウェアを配置する

まず、今回使用したファームウェア1100_0A00.nalをダウンロードした。取得元はGitHubのstevleibelt/scansnap-firmwareだ。

Shell
cd ~/Downloads/
wget https://github.com/stevleibelt/scansnap-firmware/raw/refs/heads/master/1100_0A00.nal
ls -alh 1100_0A00.nal
file 1100_0A00.nal

lsでは約65KBのファイルとして表示され、fileの結果は次のとおりだった。

プレーンテキスト
1100_0A00.nal: data

続いて、ファームウェアを/usr/share/sane/epjitsu/に配置した。以下は管理者権限で行った操作を、sudo付きのコマンドで示している。

Shell
sudo mkdir -p /usr/share/sane/epjitsu/
sudo cp ~/Downloads/1100_0A00.nal /usr/share/sane/epjitsu/
ls -alh /usr/share/sane/epjitsu/1100_0A00.nal

配置後は、所有者がroot、パーミッションが-rw-r--r--になっていることを確認した。

epjitsu.confのファームウェア指定を変更する

設定を編集する前に、/etc/sane.d/epjitsu.confをバックアップした。

Shell
sudo cp /etc/sane.d/epjitsu.conf /etc/sane.d/epjitsu.conf.20261017

その後、設定ファイルのファームウェア指定を、配置したファイルのパスへ変更した。今回の記録で、変更前に指定されていたのは次のパスだった。

プレーンテキスト
firmware /usr/share/sane/epjitsu/1100_0B00.nal

変更後の有効な指定は次のとおりだ。

プレーンテキスト
firmware /usr/share/sane/epjitsu/1100_0A00.nal

firmwareの指定が対応するusbの指定より前にあることも確認した。変更内容はバックアップとの差分で確認できる。

Shell
diff /etc/sane.d/epjitsu.conf /etc/sane.d/epjitsu.conf.20261017

今回の差分は次のとおりだった。<が編集後の設定、>がバックアップの内容になる。

diff
73,74c73
< # firmware /usr/share/sane/epjitsu/1101_0B00.nal
< firmware /usr/share/sane/epjitsu/1100_0A00.nal
---
> firmware /usr/share/sane/epjitsu/1100_0B00.nal

ScanSnap S1100の認識を確認する

設定後にScanSnap S1100をUbuntuのマシンへ接続し、次のコマンドを実行した。

Shell
scanimage -L

結果は次のとおりだった。

プレーンテキスト
device `v4l:/dev/video0' is a Noname Integrated Camera: Integrated C virtual device
device `epjitsu:libusb:001:011' is a FUJITSU ScanSnap S1100 scanner

2行目にFUJITSU ScanSnap S1100 scannerと表示され、ScanSnapが認識されていることを確認できた。

gscan2pdfでスキャンする

gscan2pdfを起動し、次の設定でスキャンを試した。

項目	設定値
ページ数	全て
スキャンプロファイル	Default
Postprocessingの認識する言語	日本語

この状態でスキャンできた。ただし、日本語の文字認識精度までは今回の記録では評価していない。

Windowsでは、実際のドキュメントのサイズに合わせて自動で切り抜く機能を使えていた。今回のLinux環境では、それに相当する設定項目を見つけられなかった。自動切り抜きの方法は確認できていないが、スキャン自体はできるようになったので、まずはこの設定で使ってみる。

Blenderの2回目の起動でウィンドウが透明になる：XWayland経由で回避する

Fri, 16 Oct 2026 00:00:00 +0000

UbuntuでBlenderを使っていたところ、1回目は起動するのに、終了して2回目を開くと画面が表示されなくなった。よく見ると、ウィンドウが透明になっているようだった。

今回の環境では、WAYLAND_DISPLAYを空にしてXWayland経由で起動すると回避できた。毎回端末から起動するのは不便なので、ユーザー用のランチャーにも同じ指定を追加した。変更後はアイコンからの起動も確認できた。

調査とランチャーの変更はCodexに依頼し、端末とアイコンからの起動確認は自分で行った。Wayland側の表示経路に問題を絞れたが、Blender、GPUドライバー、コンポジターのどこに不具合があるかまでは特定していない。

発生環境と症状

項目	確認した環境
OS	Ubuntu 26.04.1 LTS
Linux Kernel	7.0.0-38-generic
Blender	Snap版 5.2.2 LTS、revision 7803
デスクトップセッション	Wayland
GPU	AMD Lucienne

最初は起動していないと思ったが、画面が表示されない状態でもプロセスは残っていた。ホストの端末で確認した結果は次のとおりだった。

Shell
pgrep -a -f 'blender|snap-confine'

プレーンテキスト
14617 /snap/blender/7803/blender

終了ログには1回目のBlender quitがあり、その直後に次の起動要求も記録されていた。起動要求が届いていないという状態ではなかった。

初期設定でも再現し、ログは描画処理まで進んでいた

まず--debugで起動したが、画面が使えない状態は変わらなかった。続いて、初期設定で詳細ログを取った。

Shell
blender --factory-startup --debug-all > ~/blender-factory-debug.log 2>&1

この条件でも透明なウィンドウになる症状は再現した。ログには、次のようにスプラッシュやメニューの描画処理が記録されていた。関係する行を抜粋する。

プレーンテキスト
menutype_draw: opening menu "WM_MT_splash"
ghost_event_proc: ghost redraw decor 1
screen_refresh_if_needed: set screen
menutype_draw: opening menu "TOPBAR_MT_editor_menus"

描画処理まで進んでいたため、起動前に停止しているという見立てを改めた。初期設定でも再現することから、保存済みの設定だけが原因である可能性も下がった。ただし、ログに描画処理があっても、画面に正常に表示されたことまでは意味しない。

Waylandを無効にすると、2回とも起動できた

次に、初期設定の条件を保ったまま、Waylandを無効にして起動した。以下のコマンドは、Blenderを使っているホストの端末で実行する。

Shell
WAYLAND_DISPLAY="" blender --factory-startup

この起動では画面が表示された。一度終了し、同じコマンドで再び起動しても表示できた。

WAYLAND_DISPLAYを空にしてX11を使わせる方法は、Blender公式マニュアルのLinux Windowing Environmentにも記載されている。Waylandセッション内では、X11アプリを動かすXWayland経由での起動になる。デスクトップ全体をX11セッションに切り替える必要はない。

起動条件	結果
通常の起動	1回目は表示され、2回目は透明になる
`--factory-startup --debug-all`	透明になる症状が再現した
`WAYLAND_DISPLAY=""`と`--factory-startup`	終了後の再起動を含め、2回とも表示された

この比較から、今回の問題はWayland側の表示経路にある可能性が高いと判断した。具体的な不具合箇所を直したわけではなく、XWaylandを使う回避策だ。

アイコンからもXWayland経由で起動する

毎回コマンドを入力せずに済むよう、Snap版のランチャーをユーザー側にコピーし、起動コマンドを変更した。ここからのパスとファイル名は、今回使っていたSnap版のものだ。

コピー先は~/.local/share/applications/blender_blender.desktopとする。以下はXDG_DATA_HOMEを変更していない環境向けの手順で、既存ファイルがある場合は上書きせず内容を確認する。

Shell
mkdir -p ~/.local/share/applications
cp -i /var/lib/snapd/desktop/applications/blender_blender.desktop \
 ~/.local/share/applications/blender_blender.desktop

コピーしたファイルをエディターで開き、元のExec行を変更する。

変更前：

ini
Exec=/snap/bin/blender %f

変更後：

ini
Exec=/usr/bin/env WAYLAND_DISPLAY= /snap/bin/blender %f

Execではenvを実行し、その引数として環境変数を渡す。ファイルを開くための%fや、アイコンなどの他の項目はそのまま残す。普段の設定を読み込むため、切り分け用の--factory-startupは付けない。

ユーザー側にも同名のファイルを置くのは、元のランチャーと同じdesktop file IDで優先させるためだ。この仕組みはDesktop Entry SpecificationとXDG Base Directory Specificationに基づく。システム側のランチャーは変更しない。

今回の変更後は、次のコマンドで構文検証とデータベース更新を行い、どちらも成功した。

Shell
desktop-file-validate ~/.local/share/applications/blender_blender.desktop
update-desktop-database ~/.local/share/applications

その後、自分でアイコンから起動し、画面が表示されることも確認できた。端末で検証した回避策を、普段の起動にも適用できた。

元に戻す場合は、今回作成したユーザー用のblender_blender.desktopを削除する。コピーしたランチャーには、Snap側の将来の変更が自動では反映されないため、Blenderの更新後に起動方法やアイコンが変わった場合は元ファイルと比較する。

DockerのAppArmor適用失敗：プロファイルの読み込みとreadby権限で対処

Mon, 12 Oct 2026 00:00:00 +0000

UbuntuでCodex用のDockerコンテナを起動したところ、AppArmorプロファイルの適用に失敗した。原因は、起動時に指定したカスタムプロファイルがホストに読み込まれていなかったことだった。読み込むとコンテナは起動したが、続いてコンテナ内のbubblewrapで権限不足が見つかり、プロファイルの修正も必要になった。

この記事では、Dockerを使う技術者に向けて、拒否ログによる切り分けと対処を説明する。今回確認した問題は次の2段階だった。

発生段階	ログの手掛かり	対処
コンテナの起動時	`label not found`	指定したプロファイルをホストに読み込む
起動後のbubblewrap実行時	`denied_mask="readby"`	同じプロファイルのプロセス間に`readby`を許可する

調査はCodexに依頼し、ホストの設定変更とコマンド実行は自分で行った。修正後はコンテナへのプロファイル適用を確認し、提示した直近5分のログに拒否はなかった。その後、ホストの再起動後も自分で確認し、問題なかった。

この環境でのAppArmorとbubblewrapの役割

AppArmorは、プロセスが実行できる操作をプロファイルで制限するLinuxのセキュリティ機構だ。今回の環境では、Dockerコンテナにcodex-bwrapというカスタムプロファイルを適用していた。これは自分の環境で用意した名前で、Docker標準のプロファイル名ではない。

コンテナ内では、Codexのコマンド実行を制限するためにbubblewrap（実行ファイル名はbwrap）も使っている。コンテナが起動した後も、その中のプロセスはAppArmorの制約を受けるため、bubblewrapの動作に必要な操作をプロファイルで許可する必要がある。

また、プロファイルには次の3つの状態がある。設定ファイルがあるだけでは、コンテナに適用できない。

状態	今回の対象・確認方法
設定ファイルが存在する	`~/work/codex-docker/codex-bwrap.apparmor`
ホストのLinux Kernelに読み込まれている	`apparmor_parser`で読み込み、`aa-status`で確認
コンテナに適用されている	`docker inspect`の`AppArmorProfile`で確認

以下のコマンドは、Dockerデーモンが動いているUbuntuホストの通常のユーザー端末で実行する。パスとプロファイル名は自分の環境に合わせて読み替える必要がある。掲載するルールは既存プロファイルの変更箇所であり、プロファイル全体ではない。

発生したエラーと環境

実行したのは、自作のCodex用Docker起動スクリプトだ。このスクリプトは、コンテナの起動時にcodex-bwrapを指定する。

Shell
~/work/codex-docker/run-codex.sh

出力は次のとおりだった。末尾のヘルプ案内は省略している。

プレーンテキスト
Docker AppArmor setting: codex-bwrap
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: unable to apply apparmor profile: apparmor failed to apply profile: write fsmount:fscontext:proc/thread-self/attr/apparmor/exec: no such file or directory

unable to apply apparmor profileから、コンテナを準備するOCIランタイムがAppArmorを適用する段階で失敗したと分かる。コンテナ内のCodexは、まだ動き始めていなかった。調査時に確認した環境は次のとおり。

項目	バージョン・状態
Ubuntu	26.04.1 LTS
Linux Kernel	7.0.0-38-generic
Docker Client / Server	29.9.0 / 29.9.0
Docker context	default
containerd	v2.4.1
runc	1.5.2
AppArmor parser	5.0.2
AppArmor	有効、`codex-bwrap`を指定

起動時の拒否ログから、プロファイル未読み込みを確認する

エラー末尾はno such file or directoryだが、Codexが確認すると、ホストの/proc/thread-self/attr/apparmor/execは存在していた。

原因を判断する手掛かりになったのは、Linux Kernelのログだった。

Shell
sudo aa-status | rg 'codex-bwrap'
sudo journalctl -k -b --no-pager --grep='codex-bwrap|label not found' -n 30

aa-statusの抽出結果にcodex-bwrapの行はなく、ログには次の拒否が記録されていた。時刻やホスト名などを省略し、メッセージ部分を抜粋している。

プレーンテキスト
apparmor="DENIED" operation="change_onexec" class="file" info="label not found" error=-2 profile="runc" name="codex-bwrap" pid=8853 comm="runc:[2:INIT]"

ここでいうラベルは、AppArmorがプロファイルを識別するための名前だ。name="codex-bwrap"とinfo="label not found"から、起動時に指定したプロファイルを見つけられなかったと分かる。runc 1.5.2の実装では、exec属性への書き込みでプロファイルを指定する。今回の書き込みエラーは、パス自体が存在しないという意味には限定できなかった。

Codexが起動スクリプトを調べたところ、AppArmorを自動選択するCODEX_APPARMOR=auto設定は、DockerのAppArmor対応だけを確認していた。カスタムプロファイルの登録確認や読み込みは行っていなかった。Dockerの公式資料でも、カスタムプロファイルは先に読み込み、その後でコンテナに指定する手順になっている。

今回のaa-statusと拒否ログを合わせると、指定したプロファイルをホストに読み込む必要があった。ただし、以前の登録が再起動などで失われたのか、別の理由で未読み込みだったのかは特定できていない。

プロファイルを読み込んで起動エラーを解消した

Codexがプロファイルの実ファイルを確認し、自分で次のコマンドを実行した。apparmor_parserは設定ファイルを解析してホストに読み込むコマンドで、-rは既存のプロファイルがあれば置き換える指定だ。

ここではファイルの場所が明確になるよう、絶対パスを使っている。管理者権限の実行環境では、$HOMEが通常ユーザーのホームを指すとは限らない。

Shell
sudo apparmor_parser -r -W /home/sonohen/work/codex-docker/codex-bwrap.apparmor
sudo aa-status | rg 'codex-bwrap'

実行した結果、apparmor_parserの終了コードは0となり、aa-statusにもcodex-bwrapが表示された。コンテナのdocker inspectでも同じプロファイル名を確認でき、元のOCI起動エラーは解消した。

起動後の拒否ログから、readby権限を追加する

コンテナへの適用を確認した後、Linux Kernelのログに別の拒否が出ていた。comm="bwrap"はbubblewrapのプロセスを示す。最初の起動エラーが解消しても、プロファイルの内容が実行時の操作に足りるとは限らなかった。

プレーンテキスト
apparmor="DENIED" operation="ptrace" class="ptrace" profile="codex-bwrap" pid=11588 comm="bwrap" requested_mask="readby" denied_mask="readby" peer="codex-bwrap"

当時のプロファイルには、次のルールがあった。

プレーンテキスト
ptrace (read, trace) peer=codex-bwrap,

このログでは、profileとpeerがともにcodex-bwrapで、拒否された権限はreadbyだ。同じプロファイルが適用されたプロセス同士のアクセスで、読まれる側の許可が不足していた。

AppArmorのptraceルールは、デバッガによる操作に加え、一部の/proc経由のプロセス情報へのアクセスも制御する。readは相手の情報を読む側、readbyは相手に読まれる側の許可を表す。Ubuntu 26.04のAppArmorマニュアルでも、アクセスする側と受ける側の双方に許可が必要とされる。同じプロファイルのプロセス間でも、readだけでは足りなかった。

Codexの提案に従い、元ファイル/home/sonohen/work/codex-docker/codex-bwrap.apparmorの該当ルールを次のように変更した。

プレーンテキスト
ptrace (read, readby, trace) peer=codex-bwrap,

許可対象はpeer=codex-bwrapのままにした。今回の拒否ログではtracedbyは要求されていないため、追加していない。

修正版をホストへ配置し、再起動後も読み込めるようにする

apparmor_parserによる読み込みは、現在動いているLinux Kernelに対する操作だ。再起動後も読み込めるよう、修正版のファイルをホストのAppArmor設定ディレクトリ/etc/apparmor.d/codex-bwrapへ配置した。

作業時には、初回の配置で宛先ファイルが存在しないことを確認していた。その後のreadby追加では、配置済みのファイルをバックアップしてから更新した。以下の掲載例は、既存ファイルがある場合だけバックアップする形にまとめている。

バックアップは/var/backupsに置く。元の作業手順では/etc/apparmor.d内に置いていたが、AppArmor 5.0.2の実装では、.bak-日時は読み込みの除外対象にならない。古いファイルも読み込み対象になり得るため、掲載例では配置先を変更した。

Shell
sudo install -d -m 0700 /var/backups/codex-apparmor
if [ -f /etc/apparmor.d/codex-bwrap ]; then
 sudo cp -a /etc/apparmor.d/codex-bwrap \
 /var/backups/codex-apparmor/codex-bwrap.bak-$(date +%Y%m%d-%H%M%S)
fi
sudo install -m 0644 /home/sonohen/work/codex-docker/codex-bwrap.apparmor \
 /etc/apparmor.d/codex-bwrap
sudo apparmor_parser -r -W /etc/apparmor.d/codex-bwrap
sudo aa-status | rg 'codex-bwrap'

ホストのポリシー変更、配置、再読み込みは自分で実施した。Codexは元ファイルのreadby追加と、配置済みファイルとの一致を読み取りで確認した。

適用結果と再起動後の確認

配置と再読み込みが終わったら、コンテナを起動して適用結果を確認する。自作スクリプトのCODEX_APPARMOR=requiredは、AppArmorを必須にする設定だ。作業対象のディレクトリで次を実行する。

Shell
CODEX_APPARMOR=required ~/work/codex-docker/run-codex.sh

起動後、別の端末から対象コンテナと拒否ログを確認する。

Shell
docker ps
docker inspect --type container --format '{{.AppArmorProfile}}' CONTAINER_ID
sudo journalctl -k --since '5 minutes ago' --no-pager \
 --grep='codex-bwrap|apparmor="DENIED"'

CONTAINER_IDには、docker psで確認した実際のIDを指定する。期待する結果は、コンテナが起動し、AppArmorProfileがcodex-bwrapとなり、対象の操作時に新しい拒否ログが出ないことだ。確認に5分以上かかる場合は、--sinceの範囲を起動時刻まで広げる。

自分が提示した修正後の結果では、docker inspectの出力はcodex-bwrapだった。直近5分のログには次の更新通知だけがあり、DENIEDはなかった。メッセージ部分を抜粋する。

プレーンテキスト
apparmor="STATUS" operation="profile_replace" profile="unconfined" name="codex-bwrap" pid=12838 comm="apparmor_parser"

ここにあるprofile="unconfined"は、更新を行ったプロセス側の表示だ。コンテナに適用されたプロファイルはdocker inspectの結果で確認した。

ここまでの適用結果とログは調査記録に残っている。再起動後の自動読み込みは、その記録をまとめた時点では未確認だったが、その後、自分でホストを再起動して確認し、問題なかった。

ただし、当初行おうとしていたCodexの具体的な操作の成否は、調査記録には残っていない。コンテナ起動とAppArmor適用の確認だけで、Codexの全機能が動作したとは判断していない。また、修正後に拒否がなかったという判断は、提示したログの時間範囲に基づく。

同じ症状を調べるときの確認順序

今回の調査では、エラー末尾のno such file or directoryだけでは原因を判断できなかった。Linux Kernelのログでラベル解決失敗を確認し、読み込み後には別の権限不足を切り分けた。同じ症状を調べる場合は、次の順序で確認すると、今回の2つの問題を区別できる。

aa-statusと起動時の拒否ログで、指定したプロファイルが読み込まれているか確認する。
起動できたら、docker inspectでコンテナへの適用を確認する。
対象の操作を実行し、新しい拒否ログのprofile、peer、denied_maskから不足している許可を調べる。

CodexでレシートPDFからBeancountへの仕訳登録を自動化した

Sun, 11 Oct 2026 00:00:00 +0000

PDFで保存したレシートを、Beancountの帳簿へ転記する作業をCodexに任せることにした。既存の勘定科目を使って仕訳案を作り、人間が確認したら帳簿へ書き込む。登録するたびにbean-checkを実行し、成功するまで次の取引へ進まない運用にした。

自動化したのは読取り、仕訳案の作成、証跡の整理、帳簿への転記と検証である。仕訳案の最終確認は人間が行う。ファイル監視で無人処理する仕組みにはしていない。

全体の流れは次のとおりである。

人間がレシートをPDFで保存し、ファイル名に支払方法を付ける。
Codexが全ページを読み、既存科目と支払方法から仕訳案を作る。
人間が仕訳案と証跡の組合せを確認する。
補助ツールが証跡を保存し、1取引ずつ帳簿へ登録する。
各登録の直後にbean-checkを実行し、成功したら次へ進む。

Codexが判断し、Pythonが書き込む

帳簿は次の構成で管理している。

ファイル	役割
`account.beancount`	勘定科目と日本語の名称
`year/2026.beancount`	2026年の仕訳
`main.beancount`	科目、各年の仕訳などを読み込む入口

Codexには、レシートの内容に加えてaccount.beancountと既存の仕訳を読ませる。店舗名だけで費用科目を決めず、酒類、書籍、レジ袋などを品目に応じて分ける。消費税も既存の記帳方法に合わせて別科目へ計上する。

読取りと判断はCodex、金額の検証とファイル操作はPythonの補助ツールに分担した。補助ツール自体にはOCRやAI APIの呼出しを組み込んでいない。

実装環境はPython 3、Beancount 3.2.0、Popplerである。手順はリポジトリのAGENTS.mdに記載し、補助ツールをscripts/receipt.pyとして作成した。

抽出テキストだけで転記しない

スキャンしたPDFには抽出可能なテキストが入っていても、数字や店舗名に誤読があった。そこで、pdftotextで抽出した内容を、pdftoppmで画像化した全ページと照合する。取引日、合計、税額、割引は画像でも確認する。

実際に、ファイル名の日付と取引日が違うレシートがあった。ファイル名が2026-10-11で始まるPDFに、10月8日の給油が記載されていた。別のPDFも、ファイル名は2026-10-11で始まるが取引日は10月9日だった。

帳簿の日付にはレシートの取引日を使う。読めない数字や証跡間の矛盾があれば、推測して登録せず人間に質問させる。

支払方法はファイル名に書く

最初は、レシートを読むたびに支払方法を質問させていた。カード払いと分かっても、どのカードかは帳簿の科目へ対応させる必要があるためだ。

毎回回答する手間を減らすため、自分でPDF名の末尾に支払方法を付けることにした。次のような形式である。

プレーンテキスト
日付.店舗名.支払方法.pdf

次の表は対応の一例で、今回使った支払方法を示している。

ファイル名の支払方法	支払科目
現金	`Assets:Cash:Purse`
モバイルSuica	`Assets:ICCard:MobileSuica`
ビックカメラVIEW	`Liabilities:CreditCard:BiccameraVIEWSuicaCard`

補助ツールは.pdfの直前の要素を対応表で変換する。店舗名の一部から支払方法を推測することはない。

ファイル名から判別できれば、支払方法の質問は省略する。未記載、未知の表記、PDFの内容との明確な不一致がある場合は質問する。仕訳案の最終確認は、支払方法が分かっていても省略しない。

PDFの数と取引の数を分ける

領収書とカードの利用票は、同じ購入を示す別の証跡である。これらを別取引として登録すると、費用を二重計上してしまう。

同じPDFの再取込みは、ファイルごとのSHA-256で検出する。ハッシュをdocumentのメタデータへ保存し、取込み済みの証跡と照合する。別のPDFが同じ購入を示している場合は、取引情報でも確認する。

注文番号や伝票番号を優先し、店舗、日付、金額も使って同じ取引の証跡をまとめる。複数PDFの組合せはCodexが候補を提示し、人間が確認する。1つのPDFに領収書と利用票の2ページがある場合も、1取引として扱う。

仕訳と証跡はBeancountのリンクで紐づける。次は今回登録した給油の例で、店舗名とPDF名は説明用に置き換えている。

beancount

2026-10-08 * "ガソリンスタンド" "ハイオク給油" ^receipt-example
 Expenses:Car:Gasoline 2696 JPY
 Expenses:Tax:Consumption-Tax 270 JPY
 Liabilities:CreditCard:BiccameraVIEWSuicaCard -2966 JPY

2026-10-08 document Expenses:Car:Gasoline "../Expenses/Car/Gasoline/receipt.pdf" ^receipt-example

既存取引と日付、店舗、費用総額が一致した場合も確認を求める。後から別の証跡を受け取った場合は、既存取引に証跡だけを追加できる。

PDFは費用科目に応じたフォルダへ移動する。複数科目がある場合は、税を除いて費用額が最大の科目を保管先にする。複数取引で共有するPDFは1回だけ保存し、関連する全取引の登録が終わるまで元ファイルを残す。

1取引ずつbean-checkを通す

補助ツールは、Codexが作ったJSON形式の仕訳案を受け取り、次の順序で処理する。

既存の帳簿にエラーがないことを確認する。
今回の1取引を一時帳簿で検証する。
PDFを保管先へコピーし、ハッシュを確認する。
その取引だけを本帳簿へ書き込む。
bean-check main.beancountを実行する。
成功したら処理済みとし、不要になった元PDFを削除する。

通常のコピー、書込み、検証に失敗した場合は、今回の帳簿変更を戻して元PDFを残す。失敗した取引を飛ばして後続の処理を進めない。

専用ツールのcheckは事前検証、commitは1取引の登録を行う。ここでのcommitはGitのコミットではない。

Shell
python3 scripts/receipt.py check proposal.json --transaction receipt-example
python3 scripts/receipt.py commit proposal.json --transaction receipt-example

今回作成したツール専用のコマンドなので、Beancountをインストールするだけでは使えない。この記事は実装と運用の記録であり、ツールの配布手順は扱っていない。

最初にPDFを1件登録し、続いて5件を登録した。後者では領収書と利用票を含む全8ページを確認し、各取引の登録直後に検証が成功した。証跡の移動後はハッシュの一致も確認できた。

補助ツールの13件のテストも通った。対象には、複数証跡、重複候補、未確認の仕訳、ファイル名の支払方法、コピー失敗、検証失敗後の停止と再開が含まれる。

残高照合で未記帳のチャージを見つけた

レシートのない鉄道、飲料、Suicaチャージも、日付、金額、支払方法を伝えて登録した。その後、自分が確認したモバイルSuicaの実残高を帳簿に追記した。

beancount

2026-10-11 balance Assets:ICCard:MobileSuica 11362 JPY

この時点でbean-checkは失敗した。識別に必要なメッセージを抜粋すると、次の内容だった。

プレーンテキスト
Balance failed for 'Assets:ICCard:MobileSuica': expected 11362 JPY != accumulated 1362 JPY (10000 too little)

帳簿が実残高より10,000円少なかった。自分が10月5日のチャージを思い出して伝えると、Codexがその日の帳簿にチャージがないことを確認した。ビックカメラVIEW Suicaカードからの10,000円チャージを追加したところ、残高照合を含めて検証が成功した。

仕訳の検証が通っていても、取引の漏れまでは見つからない。実残高をbalanceで照合したことで、未記帳を発見できた。

現状の対象は2026年の日本円による通常の購入で、外貨や返品は扱っていない。また、突然のプロセス終了や電源断に対して、帳簿とPDFの更新を完全に一体化する保証はない。今回確認できたのは、通常の失敗時の巻き戻しと、対話で確認した仕訳を順番に登録する運用である。

サスペンド復帰後にNextDNSが応答しなくなる問題を調べ、自動再起動を設定した

Sun, 11 Oct 2026 00:00:00 +0000

Ubuntuの端末をサスペンドから復帰させると、NextDNSから応答を得られなくなることがあった。そのたびに自分でNextDNSを手動再起動していた。毎回操作するのは面倒なので、Codexに症状の調査と自動再起動の実装を依頼した。

NetworkManagerの接続イベントを受け、約5秒後に稼働中のNextDNSを再起動する仕組みを設定した。内部原因は未特定で、自動再起動による復旧効果は今後確認する。

調査した環境

項目	バージョン
Ubuntu	26.04.1 LTS
Linux Kernel	7.0.0-38-generic
NextDNS CLI	1.47.3
NetworkManager	1.54.3-2ubuntu3.1
systemd	259.5-0ubuntu3.4

以下の実装は、NetworkManagerで接続を管理し、NextDNS CLIがsystemdのnextdns.serviceとして動作する環境を前提とする。

Wi-Fiが戻ってもDNS問い合わせは失敗していた

Codexにログ調査を依頼した。10月11日のホストのjournalでは、次の時系列を確認できた。

Shell
journalctl -b -u nextdns -u systemd-suspend -u NetworkManager \
 --since '2026-10-11 09:05:00' --until '2026-10-11 09:35:00' --no-pager

時刻	ログで確認した内容
09:17:40	サスペンドを開始し、Wi-Fiを切断
09:31:19	サスペンドから復帰
09:31:25	NetworkManagerが`CONNECTED_GLOBAL`を報告
09:32:24以降	NextDNSのエンドポイント取得がタイムアウト
09:34:04	DNS問い合わせのタイムアウトが多数発生
09:34:13	自分でNextDNSを再起動
09:34:18	新しいプロセスがDoH接続を再確立

名前解決のエラーには、次の文字列が含まれていた。ログ全文ではなく、識別に必要なメッセージ部分を抜粋している。

プレーンテキスト
doh resolve: context deadline exceeded

エンドポイント取得でも、次のエラーが出ていた。

プレーンテキスト
exchange: roundtrip: context deadline exceeded

Wi-Fiの接続復旧が報告された後も、同じNextDNSプロセスでDNS問い合わせの失敗が続いていた。この事例では、サービスが落ちたというより、動いたまま上流への通信を回復できていないように見える。

内部原因は未特定で、NetworkManagerの接続状態だけでは外部との通信が正常とは言い切れない。手動再起動後のログではDoH接続の再確立が記録されており、自分でもDNSの実応答を確認した。

NextDNSの公式リポジトリにあるIssue #699にも、サスペンド復帰後のDNS問い合わせのタイムアウトが報告されている。こちらはNextDNS 1.37.11とUbuntu 22.04の事例だ。今回と同じ原因とは限らない。

接続イベントから再起動する

プロセスが生きたまま応答できなくなる症状には、終了時の再起動を設定するだけでは対応できない。Codexはこの症状に対応するため、NetworkManagerの接続イベントからNextDNSを再起動する構成を実装した。

NetworkManagerのdispatcher仕様では、upはインターフェースの接続完了、vpn-upはVPNの接続完了を表す。Codexの実装では、この2つを対象にしている。

処理は次の順序で進む。

dispatcherがupまたはvpn-upを受け取る。
NextDNSが稼働中なら、systemd timerを再始動する。
timerが約5秒後にサービスを呼び出す。
稼働中のNextDNSを再起動する。

実装には、接続直後の状態が落ち着くまでの猶予として5秒の待ち時間を設けている。外部との通信が復旧したことを確認する処理ではない。

タイマーの待ち時間中に別の接続イベントを受け取ると、待ち時間を設定し直す。そのため、接続イベントが短時間に続いても、最後のイベントから約5秒後にNextDNSを1回だけ再起動する。通常のWi-Fi再接続やVPN接続でも動作するため、サスペンド復帰だけに限定した仕組みではない。再起動時には短時間DNSが途切れる。

dispatcher、timer、serviceの内容

接続イベントを受け取るスクリプト

/etc/NetworkManager/dispatcher.d/90-nextdns-reconnectに配置する。

Shell
#!/bin/sh
# NetworkManager dispatcher: coalesce connection activation events.
PATH=/usr/sbin:/usr/bin:/sbin:/bin
export PATH
case "${2:-}" in
 up|vpn-up) ;;
 *) exit 0 ;;
esac
# Do not undo an intentional stop of NextDNS.
systemctl is-active --quiet nextdns.service || exit 0
exec systemctl --no-block restart nextdns-reconnect.timer

--no-blockでタイマーの再始動を依頼し、dispatcher内では待たない。dns-changeには反応しないため、NextDNSの再起動に伴うDNS設定変更が次の再起動を誘発するループを避けられる。

5秒後に処理するタイマー

/etc/systemd/system/nextdns-reconnect.timerに配置する。

ini
[Unit]
Description=Delay NextDNS restart after network activation

[Timer]
OnActiveSec=5s
AccuracySec=1s
Unit=nextdns-reconnect.service

NextDNSを再起動するサービス

/etc/systemd/system/nextdns-reconnect.serviceに配置する。

ini
[Unit]
Description=Restart running NextDNS after network activation

[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl try-restart nextdns.service
TimeoutStartSec=45s

Codexはtry-restartを使い、管理者が停止しているNextDNSを勝手に起動しないようにした。

実機へのインストール

Codexはインストール用のinstall.shも作成した。既存の同名ファイルがあれば停止し、ユニットの検証後に設定を配置する。

同じディレクトリに次の5つを保存すると、インストール・アンインストールのスクリプトを利用できる。

保存したディレクトリで、ホストの端末から実行する。

Shell
sudo sh ./install.sh

dispatcherはroot所有で実行可能にし、グループやほかのユーザーから書き込めない権限にする。インストールスクリプトでは0755、ユニットファイルは0644に設定している。

NetworkManager自体の再起動やタイマーのenableは不要だ。インストール直後にNextDNSを再起動せず、次の接続イベントから動作する。

Codex環境からはsudo認証できなかったため、自分でホストの別ターミナルからインストールした。

検証状況と復帰後の確認

Codexはsh -nでシェルの構文を確認し、イベント分岐をモックで検証した。upとvpn-upでは稼働中の場合だけタイマーを操作し、停止中や対象外のイベントでは操作しないことを確認した。

Codexの隔離環境ではsystem busへの接続やソケット設定が制限され、現在のサービス状態の取得とsystemd-analyze verifyは失敗した。モック検証は、実際のsystemdやサスペンド復帰を使った検証ではない。実機へのインストールは済んだ。手動再起動後のDNSの実応答は自分で確認したが、接続イベントによる自動再起動と、その後の名前解決の回復は未確認だ。

次回のサスペンド復帰後には、自分で次のコマンドを実行し、ログと名前解決を確認する。

Shell
journalctl -b -u nextdns-reconnect.service -u nextdns.service --since '-10 min' --no-pager
dig @127.0.0.1 example.org +time=3 +tries=1
getent ahosts example.org

digの例は、NextDNSが127.0.0.1:53で待ち受ける場合の直接問い合わせだ。待受先が異なる場合は、アドレスとポートを設定に合わせる。getentではOSの通常の名前解決を確認する。

確認したいのは、接続後に自動再起動したログが残り、名前解決も成功することだ。サービスがactiveというだけでは、今回の症状が解消したとは判断しない。

アンインストール

仕組みをアンインストールするときは、ファイルを保存したディレクトリから次を実行する。

Shell
sudo sh ./uninstall.sh

アンインストールスクリプトは配置済みファイルと元の実装を比較し、変更されている場合は削除しない。NextDNS本体の設定は変更しない。

EmacsでCodexを使う環境を整え、関連書籍を買った日

Sat, 10 Oct 2026 00:00:00 +0000

今日は、EmacsからCodexを使うための環境を整えていた。CLIのインストールから始めたのだが、ターミナルと日本語入力、Docker、権限の設定まで、思ったより作業が増えた。

Codexをインストールする

まず、Codexをコマンドラインから使えるようにした。今日の環境では、次のコマンドでインストールしている。

Shell
sudo npm install -g @openai/codex
which codex

which codexの結果は/usr/local/bin/codexだった。

Emacsではvtermを使うことにした

Codexをインストールしたものの、Emacsのシェルではうまく動かなかった。そこで、vtermを使うためのパッケージを入れた。

Shell
sudo apt install -y cmake libvterm-dev libtool-bin

ところが、今回の環境ではvterm上でDDSKKによる日本語入力ができなかった。別のターミナルならどうかと思い、Eatも試してみた。

NonGNU ELPAをパッケージの取得先に追加し、leafで次のように設定した。

Emacs Lisp
(leaf eat
 :ensure t
 :bind ("C-c v" . eat-project-other-window))

Eatでも日本語入力ができず、動作も安定しなかったため、今回はvtermを使うことにした。DDSKKで入力するという当初の希望は、ひとまず保留にした。これは今日の自分の環境での結果であり、ほかの環境でも同じとは限らない。

Codex用のDocker環境を作る

次に、CodexをDockerで動かすための環境を作った。Dockerの導入は公式のUbuntu向けインストール手順を参考にした。

インストール後、次のコマンドで確認した。

Shell
sudo docker run hello-world

Hello from Docker!と表示されたので、続いてCodex用のDockerfileと起動スクリプトを用意した。

当日の作業メモに残した初期構成では、イメージのベースにnode:22-bookworm-slimを使い、Git、ripgrep、PythonなどとCodex CLIをインストールする。コンテナ内では一般ユーザーのnodeで実行し、作業ディレクトリを/workspaceにした。

起動スクリプトでは、ホスト側の共有ディレクトリを/workspaceにマウントし、Codexのホームには名前付きボリュームを使った。当日のメモに残した初期のスクリプトを以下に示す。Dockerfileと起動スクリプトはその後も変更しているため、以下は初期構成の記録として読む。

Shell
#!/bin/sh
set -eu

shared_dir=/home/sonohen/dockershared
mkdir -p "$shared_dir"

exec docker run --rm -it --init \
 -e TERM \
 -v codex-home:/home/node/.codex \
 --mount "type=bind,src=$shared_dir,dst=/workspace" \
 codex-cli "$@"

shared_dirは自分の環境のパスなので、別の環境で使う場合は変更する。コンテナから共有ディレクトリ内のファイルは変更できるため、何を共有するかは意識しておきたい。

イメージの作成と起動には、次のコマンドを使った。

Shell
docker build -t codex-cli -f Dockerfile .
./run-codex.sh

bubblewrapとAppArmorの設定で悩む

環境を整える途中で、bubblewrapが新しいnamespaceを作成できないというメッセージにも遭遇した。作業メモに残した原文は次のとおりだ。単語間の空白も記録どおりに示す。

プレーンテキスト
bwrap:No permissions tocreate a new namespace,likely because the kerneldoes not allow non-privileged user namespaces.

メッセージには、非特権ユーザーによるnamespaceの作成がカーネルで許可されていない可能性が示されていた。そこで、UbuntuのAppArmor設定を調べた。

まず、次の設定値を確認した。

Shell
sysctl kernel.apparmor_restrict_unprivileged_userns

結果は次のとおりだった。

プレーンテキスト
kernel.apparmor_restrict_unprivileged_userns = 1

この値を確認したうえで、/usr/bin/bwrapにusernsを許可するAppArmorプロファイルを作った。管理者権限で次のコマンドを実行し、apparmor_parserで読み込んだ。

Shell
sudo install -m 644 /dev/stdin /etc/apparmor.d/bwrap <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
 userns,

 include if exists <local/bwrap>
}
EOF

sudo apparmor_parser -r /etc/apparmor.d/bwrap

この設定後、私が使っている範囲ではbubblewrap関連のエラーは出なくなった。すべての実行条件を検証したわけではないため、今回確認できた範囲での結果として記録しておく。

また、Codexのconfig.tomlには次の設定を追加した。これは今回の環境で追加した内容の記録なので、末尾のパスはインストール先に合わせる必要がある。

TOML
default_permissions = "project-edit"

[permissions.project-edit.filesystem]
":minimal" = "read"
"/usr/local/lib/node_modules/@openai/codex" = "read"

OpenAIのサンドボックスの説明にも、Linuxで必要になるbubblewrapと、UbuntuでのAppArmor設定について記載がある。Ubuntuのバージョンによって扱いが異なるため、同じメッセージが出た場合も、自分の環境に合う手順を確認したい。

Ubuntuで行ったほかの作業

aptの段階的な更新を知った

sudo apt upgradeを実行したところ、Not upgrading yet due to phasingと表示され、20個のパッケージが更新されなかった。

作業メモから、表示の冒頭と更新件数を抜粋する。途中のパッケージ一覧は省略した。

プレーンテキスト
Not upgrading yet due to phasing:
（パッケージ一覧を省略）

Summary:
Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 20

調べると、Ubuntuには更新を一度に全員へ配布せず、対象を段階的に広げる仕組みがある。Phased updatesの公式説明によると、不具合が見つかった際の影響を小さくするためのものだ。今回の表示は、その段階的な配布に関係していた。

localsearchを一時的に止めた

localsearch-extractor-3の動作が気になったので、ひとまず次のコマンドでサービスを停止し、起動を抑止した。原因はまだ分かっていない。

Shell
systemctl --user mask --now localsearch-3.service

実行すると、すぐにプロセスが停止した。元に戻すときのコマンドも記録しておく。

Shell
systemctl --user unmask localsearch-3.service
systemctl --user start localsearch-3.service

ibus-skkを入れた

vtermではDDSKKによる日本語入力ができなかったので、ibus-skkと辞書もインストールした。

Shell
sudo apt install ibus-skk skkdic

ところが、vtermとの組み合わせでは変換した文字が消えてしまうなどの問題があり、ibus-skkは使わないことにした。今回の環境では、vterm上の日本語入力はUbuntuのMozcに頼るしかなさそうだ。

Codexの本を買った

本屋で『Codexではじめるエージェンティックコーディング』を見かけ、タイトルが気になったので購入した。

初版ということもあり、少し誤植が気になる。今後の修正に期待しつつ、読書メモを残しているところだ。

指示に目標と完了条件を書く

読書メモには、Mini Codexテンプレートとして、指示に含める4つの項目を整理した。

Goal：達成したい目標を書く。
Context Pointers：既存の実装や仕様など、参照してほしい情報の場所を示す。
Constraints：変更してはいけない仕様や、守るべき規約を書く。
Done When：作業が完了したと判断する条件を書く。

AIに必要な情報を渡さなければ、推論や一般的な情報で補われてしまう。自分の作業に必要な文脈を、指示の中に具体的に含めることが大切だと受け取った。

特に完了条件は、実行や確認によって判定できる形にしたい。「きれいなコードにする」よりも、「lintエラーが0件」「既存テストがすべてpassする」のように書く。

Plan modeを使う場面を考える

Plan modeについては、方向性は決まっていても、詳細を相談しないと完成形が決まらない作業に向いているとメモした。タイプミスの修正や、単一ファイルの文言変更なら、計画を作る手間との釣り合いを考えたい。

計画を確認するときは、目標、参照情報、制約、完了条件に加え、変更の範囲と順序も見る。変更が広がりすぎていないか、戻しやすい単位になっているかを確認する。

また、調査やテスト、小さな変更を先に置き、影響の大きい変更を後にできるかも考える。タスクの分け方を判断するときには、複数の観点で検証できるかを確認したい。

今日はCodexをEmacsから使う準備に多くの時間を使った。vtermを使う方針が決まり、使っている範囲ではbubblewrapのエラーも出なくなった。日本語入力はDDSKKとibus-skkを試したものの、Mozcに頼る方向で考えている。次は、用意した環境で実際の作業を続けながら使い勝手を見ていきたい。

オクトパスエナジーに切り替えた

Mon, 05 Oct 2026 00:00:00 +0000

契約切り替えの経緯

オクトパスエナジーという新興電力会社に切り替えた。

その前はidemitsuでんきと契約していた。車に乗っていること、近くのガソリンスタンドが出光であること、単価が東京電力よりも若干割安であること、の3つの理由から契約していたのだが、わたしの使い方(日中の在宅が多く、割安な深夜時間帯にはエコキュートくらいしか稼動していない)では、割高な時間帯に電気を使うという矛盾した構図になるのだった。

そんな折、日中(9:00-15:00)に割安になるオクトパスエナジーを知り、idemitsuでんきのウェブサイトから確認できる電力使用量を元にシミュレーションをし、若干割安になる可能性があることから、契約した。

現在までの感想

つい先日切り替わったばかりなので電気代については何とも言えないが、今のところの感想としては次の通りである。

比較的、割安な時間帯に寄せやすい

きちんとシミュレーションをしていたので当然といえば当然であるが、日常で使う電力を割安な時間帯(9:00-15:00)に寄せやすい。普通に生活をしていれば自然と寄っていくし、エコキュートも8時間、時間設定をずらした。

どういうことかというと、元々、我が家のエコキュートは、電力会社が設定する割安な時間帯(1:00-6:00)に湯沸しをするように設定していた。オクトパスエナジーの割安な時間帯とは8時間の時差があることから、エコキュートの日時設定を-8時間して調整したのである。

いままでは深夜に沸かしていたのが日中になったのだから違和感があったが、そんなのは最初の2日もすれば慣れるものである。

どの程度の差があるのかは分からないが、深夜よりも日中のほうが外気温が高いのだから、沸かすのにかかるエネルギーも多少は少なくて済むのではないかと思っている。

APIが便利

オクトパスエナジーは外向けにAPIを公開している。実際に、LINE Messaging APIで電力使用量を通知している開発者の方がいらっしゃる。

例にもれず、私もこのAPIを使い、電力使用量と、当月の電力使用状況から月末時点での電気代をシミュレーションするPebbleのアプリケーションを開発し、今、試験しているところである。

idemitsuでんきも過去の電力使用量を表示する契約者専用ページがあるが、APIは公開されていない。オクトパスエナジーは、電力使用量をもとにプログラムを作ることができる点で、開発者にとっては便利である。

今、冷静に考えてみると、何もスマートウォッチで電気代のシミュレーションを見ることもないだろうとは思うものの、せっかくあるわけですし…。

まとめ

電気代が安くなるかは正直微妙なところではあるが、最後に書いたAPIは結構遊びがいがありそうなので、しばらく様子を見たいと思う。

ちなみに、オクトパスエナジーの契約を考えている人に向けて、電気代が8,000円割引になる紹介URLをお伝えします。

Ubuntuの通信がNextDNSを経由せずにハマった話

Sun, 04 Oct 2026 00:00:00 +0000

NextDNSの接続チェックサイトを参照したところ、以下のようなレスポンスが返ってきました。

JavaScript
{
 "status": "unconfigured",
 "resolver": "14.0.9.43",
 "srcIP": "xxx",
 "server": "zepto-tyo-1"
}

NextDNSの起動状況等を確認するも、正常に起動している模様。

Shell
% nextdns status

プレーンテキスト
running

Shell
% nextdns config

プレーンテキスト
mdns all
bogus-priv true
setup-router false
auto-activate true
listen localhost:53
max-inflight-requests 256
profile 5d5e67
cache-size 10MB
max-ttl 5s
hardened-privacy false
debug false
control /var/run/nextdns.sock
log-queries false
cache-metrics false
cache-max-age 0s
detect-captive-portals false
use-hosts true
timeout 5s
report-client-info true
discovery-dns

Shell
% systemctl status nextdns

プレーンテキスト
● nextdns.service - NextDNS DNS53 to DoH proxy.
 Loaded: loaded (/etc/systemd/system/nextdns.service; enabled; preset: enabled)
 Active: active (running) since Sun 2026-10-04 20:13:02 JST; 12min ago
 Invocation: 4981df20fedf4c4da23cb644af1c17ca
 Main PID: 57539 (nextdns)
 Tasks: 16 (limit: 22939)
 Memory: 6.8M (peak: 9M)
 CPU: 227ms
 CGroup: /system.slice/nextdns.service
 └─57539 /usr/bin/nextdns run

10月 04 20:13:02 thinkpad-e14-g3 systemd[1]: Started nextdns.service - NextDNS DNS53 to DoH proxy..
10月 04 20:13:02 thinkpad-e14-g3 nextdns[57539]: Starting NextDNS 1.47.3/linux on localhost:53
10月 04 20:13:02 thinkpad-e14-g3 nextdns[57539]: Listening on TCP/127.0.0.1:53
10月 04 20:13:02 thinkpad-e14-g3 nextdns[57539]: Listening on UDP/127.0.0.1:53
10月 04 20:13:07 thinkpad-e14-g3 nextdns[57539]: Activating
10月 04 20:13:07 thinkpad-e14-g3 nextdns[57539]: Connected [2a07:a8c1::]:443 (con=7ms tls=27ms, TCP, TLS13)
10月 04 20:13:07 thinkpad-e14-g3 nextdns[57539]: Connected [2a0b:4341:b02:166:5054:ff:fe53:ab1]:443 (con=9ms tls=23ms, TCP, TLS13)
10月 04 20:13:07 thinkpad-e14-g3 nextdns[57539]: Switching endpoint: https://dns.nextdns.io#167.179.109.118,103.170.232.254,2001:19f0:7001:5e19:5400:2ff:fec8:7b5a,2a0b:4341:b02:166:5054:ff:fe53:ab1

/etc/resolv.conf は以下の通り。ローカルに向いている…。

Shell
% cat /etc/resolv.conf

プレーンテキスト
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .

これはもう間違いなくネットワークインタフェースにバインドされているDNSサーバ設定の問題だよなぁと思って調べたところビンゴで、 192.168.10.1 (デフォルトゲートウェイ)に向いていました。

Shell
% resolvctl status

プレーンテキスト
Global
 Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 resolv.conf mode: stub
 DNS Servers: 127.0.0.1

Link 2 (enp2s0)
 Current Scopes: none
 Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 DNS Servers: 127.0.0.1
 Default Route: no

Link 3 (wlp3s0)
 Current Scopes: DNS
 Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 DNS Servers: 192.168.10.1 2409:11:4680:100:8222:a7ff:feb8:e34a
 Default Route: yes

ということで、以下のコマンドを実行してDNS設定を変更しました。

Shell
% sudo nmcli connection modify "<SSID>" ipv4.ignore-auto-dns yes ipv6.ignore-auto-dns yes
% sudo resolvectl dns wlp3s0 127.0.0.1
% sudo resolvectl domain wlp3s0 '~.'

これで無事、NextDNSに向いてくれました。

Pebbleで「あと何歩？」を確認する、Let's Walkingというアプリを開発しました

Sat, 03 Oct 2026 00:00:00 +0000

目標までの残り歩数と、折り返しまでの残り歩数を同じ画面に表示する、シンプルなウォーキングアプリです。

Figure 1: Let’s Walkingのウォーキング画面。GOAL LEFTとTURN INを同時に表示

今日の目標に足りない分を歩く

設定する目標は、その日の累積歩数です。今回の散歩だけで歩く数ではありません。

例えば、今日すでに3,000歩歩いていて、目標を8,000歩にすると、開始時の残りは5,000歩。その半分の2,500歩を、折り返しの目安にします。半分が端数になる場合は切り上げます。

画面の GOAL LEFT は目標まで、 TURN IN は折り返しまでの残り歩数です。この例で1,000歩歩くと、表示はそれぞれ4,000歩と1,500歩になります。折り返し地点は開始時に決まるため、TURN INは、現在のGOAL LEFTを半分にした値ではありません。

折り返しに達すると、一度だけ3回振動し、表示が TURN NOW に変わります。歩数に基づく目安なので、経路や帰り道を案内する機能はありません。

目標を設定して、上ボタンで出発

アプリを起動したら、右側中央の選択ボタンで目標設定を開きます。

上ボタン：100歩増やす
下ボタン：100歩減らす
選択ボタン：保存する
左側の戻るボタン：変更を取り消す

上下のボタンは、押し続けると連続で変更できます。離すと止まり、設定範囲の100〜100,000歩を超えることはありません。初回の目標は8,000歩で、次回からは前回保存した値を使います。

設定を終えたら、開始前の画面で上ボタンを押してウォーキングを開始します。すでに本日の目標を達成している場合は開始せず、 ALREADY MET と表示します。さらに歩きたいときは、目標を上げてください。

休憩は選択ボタン、終了は下ボタン

歩いている途中で選択ボタンを押すと、中断して PAUSED を表示します。もう一度押すと再開します。中断中に増えた歩数は、このウォーキングの進捗から除外します。

目標までの残りが0になると、 GOAL MET に変わり、折り返しとは別に、一度だけ3回振動します。自動では終了しないので、歩き終えたら下ボタンを押してください。その時点の残り歩数で達成を判定し、結果画面に歩いた歩数と残り歩数を表示します。結果画面で選択ボタンを押すと、次のウォーキングの準備に戻れます。戻るボタンでアプリを閉じます。

日付をまたいでも、開始時を基準にウォーキングは継続します。

利用にあたって

Pebble Healthから歩数を取得できる端末が対象で、初代PebbleとPebble Steelは対象外です。画面は英語表示ですが、主な操作は右側のアイコンでも確認できます。

歩数の反映には遅延があり、表示や振動が歩いた瞬間と一致するとは限りません。歩数を取得できない場合は NO DATA 、そのまま終了した結果は UNKNOWN （判定不明）と表示します。また、進行中のウォーキングは、アプリの強制終了や端末の再起動後には復元しません。

まずは一日の目標を決めて、残り歩数を見ながら、いつもの散歩に使ってみてください。

ソースコード

MITライセンスで公開しています。

pebble-lets-walking

PebbleOS v4.38.2が公開されました

Mon, 28 Sep 2026 00:00:00 +0000

Pebble OS v4.38.3が2026年9月24日に公開されました。ChangeLogから変更点を確認することができます。

Figure 1: アップデート中の様子

個人的に気になる点は次の3点です。

Initial support for blood oxygen (SpO2) monitoring. Not enabled in Pebble mobile app yet.
Larger timeline cards. Sports scores and calendar events make better use of the larger displayes.
Translations are now managed in a community project, making it easier to contribute and keep laguages up to date. Additional languages are delivered as language packs through the mobile app.

Emacs 31にしてからの設定見直し

Wed, 23 Sep 2026 00:00:00 +0000

環境

brew install emacs-app --casks でインストールした emacs を使用している。自分でコンパイルはしていない。

Shell
emacs --version

プレーンテキスト
GNU Emacs 31.1
Development version fac653279dcb on HEAD branch; build date 2026-08-24.
Copyright (C) 2026 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

過去の .emacs を引っ張り出してきて使おうとしたところ、久し振り過ぎて色々なところで躓いたので、そのときの記録を残すことにした。

`libgccjit.so` が見つからない

警告内容

プレーンテキスト
⛔ Warning (native-compiler): libgccjit.so: error: error invoking gcc driver

原因

macOSの gcc を参照しているため。ネイティブコードにコンパイルするときに gcc が libgccjit を参照できずにエラーになっている模様。

対処

brew で gcc と libgccjit をインストールした。

Shell
% brew install gcc libgccjit

その上で ~/.emacs に以下の記述を追加し brew でインストールした gcc を呼び出すようにした。

Emacs Lisp
(when (eq system-type 'darwin)
 (setenv "MACOSX_DEPLOYMENT_TARGET" "27.0")
 (let ((brew-prefix "/opt/homebrew"))
 (setenv "PATH" (concat brew-prefix "/bin:" (getenv "PATH")))
 (setq native-comp-compiler-path (concat brew-prefix "/bin/gcc-16"))
 (setenv "LIBRARY_PATH"
 (concat brew-prefix "/lib/gcc/16:"
 (getenv "LIBRARY_PATH")))))

`Missing 'lexical-binding' cookie` という警告が出力される

警告内容

プレーンテキスト
⛔ Warning (files): Missing ‘lexical-binding’ cookie in "~/.emacs.d/elpa/ddskk-20260329.1317/skk-cursor.el".
You can add one with ‘M-x elisp-enable-lexical-binding RET’.
See ‘(elisp)Selecting Lisp Dialect’ and ‘(elisp)Converting to Lexical Binding’
for more information.

原因

実装による。

対処

暫定対処となるが、以下の記述を ~/.emacs に追記する。

Emacs Lisp
(when (require 'warnings nil t)
 (add-to-list 'warning-suppress-log-types '(files missing-lexbind-cookie)))

Pebbleの輸送追跡結果と、最初に開発したアプリケーション

Tue, 22 Sep 2026 00:00:00 +0900

液晶に差し込む光が強ければ強いほど視認性が高まり、バッテリーは1ヶ月近く持つPebble Time 2*。前々から気にはなっていたのだが、途中で消えたこともあり、その後はあまり探していなかった。

先日、何かをきっかけに検索したPebble Time 2*が在庫あり・2営業日以内に出荷すると書かれていたので、この円安の最中、注文した。

到着前にPebbleのアプリ開発のチュートリアルを実施した時の記録はこちらから参照ください。

購入価格

合計: 269.52 USD (1 USD = 160.59 JPY計算で、43,281 JPY)

本体 (Pebble Time 2 - Silver/Grey): 225.00 USD
輸送費 (DHL EXPRESS WORLDWIDE): 18.00 USD
諸税: 26.52 USD

追跡

特に記載がない限り日本標準時(UTC +09:00)。

9/12（土）

11:44 注文
11:47 注文確認（色など）完了

9/14（月） - 1営業日目

16:42 発送した旨の連絡がPebbleから来る。この時に、DHLの追跡番号も送られてきた。
16:47 Pebbleから、「A shipment from order #PBL-XXXXXXX is on the way」というメールが届く。

9/15（火） - 2営業日目

17:13 (UTC +08:00) 荷物集荷@香港

9/16（水） - 3営業日目

00:25 (UTC +08:00) DHL仕分け施設に到着@香港
03:23 (UTC +08:00) 輸送手配中@香港
03:36 (UTC +08:00) DHL施設を出発@香港
05:44 通関情報の更新(荷受国到着前に通関手続きを開始する可能性)@成田
09:01 次のDHL施設に輸送中@成田
09:20 通関情報の更新(荷受国到着前に通関手続きを開始する可能性)@東京(おそらく新木場)
10:37 DHL仕分け施設に到着@東京(おそらく新木場)
10:55 通関手続き完了@東京(おそらく新木場)
11:14 DHL施設にて輸送手配中@東京
11:15 DHL施設を出発@東京

以降、最寄りのDHL配送施設に到着し、9/16（水）に荷物を受け取った。

香港→成田間は、時間を考えると恐らくLD208便（3:25香港発・8:40成田着のAir Hong Kongによる運行便）で輸送されたものと思われる。ちなみにこの日は、3:36発・8:21着であった。

到着後

色々な方が写真を載せられているので、私が特に気になった箇所だけ写真を載せたいと思う。

紙マーク

外国製品なのに、嬉しいものです。

充電器は極めて小さい

充電時には、充電器にUSB-Cケーブルを差し込み、Pebble Time 2*本体には磁石で取り付ける。この充電器は極めて小さく、また、先に述べた通り充電はひと月に一回か二回程度であるから、よくよく気をつけて保管しておかないと、充電したい時に充電器を紛失している恐れがある。幸い、磁石がついているので、私は机の脚につけている。

最初に開発したアプリケーション

Swarmにチェックインするアプリケーション「Pebblewarm」を開発した。Pebble向けにSwarmの公式アプリケーションが登録されていたのだが、10年以上前に更新が途絶えておりうまく動かなかったためである。

Apple WatchでもSwarmアプリを使っていたのだが、Pebbleにしてからチェックインまでの時間がより短くなったし、Timeline Pinにも登録するようにしているので、何時にどこにチェックインしたのかも分かりやすくなっている。

ちなみに、私はこのようなフローで動かしている。

下ボタンの長押しに、Pebblewarmを割り当て
場所が表示されたら、選択ボタン長押しでチェックイン

仕様、ソースコードはMITライセンスで公開している。Foursquare Developer Consoleでプロジェクトを作成してClient ID、Client Secretを入手し、Callback用のページをどこかに配置すれば、それらを使って動かすことができる。興味があればコンパイルして、インストールして動かしてみてほしい。詳細は、src/README.mdを参照いただきたい。

Pebble Time 2*自体の性能が高くないので、アプリケーションを開発するにあたっても、Pebble本体とスマートフォンそれぞれの役割を考えなければならないなど、制約の中で設計するのはなかなか面白い。いくつか作ってみたいアプリケーションのアイデアがあるので、どんどん設計して実装していきたいと思っている。

Pebbleのアプリケーション作成のチュートリアルを実施してみた

Sun, 13 Sep 2026 00:00:00 +0900

Pebble Time 2*を購入した。結構前に職場の上司から「自分でスマートウォッチのアプリケーションを開発できるから面白い」と紹介を受け気にはなっていたのだが、その後名前を消していたのであまり調べてもいなかった。とあるサイトを見ていたところPebbleが再度発売されているというのを知り、在庫もありそうだったので購入した。

発送から到着までのタイムラインと、到着後に作ったアプリケーションについてはこちらを参照ください。

Pebble Time 2*: $225.00
Shipping: $18.00
Taxes: $26.52
Total: $269.52 USD

これをビューカードで支払ったところ、日本円でおよそ43,281円（1USD = 160.59 JPY）という金額になった。随分と高い。

Pebbleといえば、Cloud Pebbleを使うことで、コンピュータに色々なものをインストールしなくてもJavaScriptさえ書ければアプリケーションを作って配布することができる。それくらいの手軽さということもあり、コミュニティでは多くのアプリケーションやウォッチフェイスが配布されている。

どんな感じで作るのか商品が届く前に知りたいと思い、チュートリアルを実施した。

最初はCloud Pebbleを使って試していたのだが、エディタの使い勝手があまり良くなく、結局MacBook上で開発環境を構築した。

感想は以下のような形になる。

開発環境の構築が非常に簡単にできる。やろうと思ってから15分もかからないのは大きなメリットと言える。
ドット単位で画面デザインを決めていくのは、非常にわかりやすい。CSSで1px単位でズレないように作ったりしていた経験がある人にはわかると思う。
（チュートリアルレベルではあるが）比較的、理解しやすい。どういう仕組みで動くのか、1日もあれば分かる気がする。（ま、多分「完全に理解した」レベルではあるとは思うが）
今作ろうと思っているアプリケーション（電力会社のAPIを叩いて利用状況をグラフにするのと、料金計算するのと）は、チュートリアルに少し毛が生えた程度で実装できそうなので、Pebble向けにアプリケーションを作ろうと思えている。つまり、チュートリアルが非常に実践的（私にとって）であると言える。

参考

市場はあなたを特別扱いしない

Sun, 12 Jul 2026 00:00:00 +0900

出資 = 相手にとっては資金調達。7%という資金コストを負担してまで資金調達する必要性はどこにあるのだろうか。

あなたとっての「出資」とは、相手にとっての「資金調達」なのである。あなたが7%の利回りを得るということは、相手は7%の資金調達コストを支払うことに他ならない。

日本の信用力の高い企業であれば、まず7%の金利で資金調達をするケースは無い。銀行からの資金調達で1%台の金利、株式市場からの調達で2-3%の資金調達コストで調達できるからである。米国であっても、投資適格企業は5%台だが、7%はジャンク債（投機的格付け）の金利である。つまり、それだけ安価に調達できる資金をわざわざ7%の資金調達コストを支払ってでも得ようとする企業は、市場ではその程度のリスクが織り込まれている企業の可能性があるということだ。

分かりやすい他の例も出すとするなら、住宅ローンである。契約者一人ひとりの信用によって借りられる金額、金利、期間は変わる。信用が高ければ金利は低く、信用がなければ金利は高くなる。

金利の高低は、借り手の信用に依存する。7%という利回りということは、それだけのリスクを織り込んでいるということであり、やはり市場はあなたを特別扱いしない。

7%という利回りはどういうことか

全世界株式に分散するインデックス投資では過去30年で均した利回りが5-6%。S&P500では過去100年で均した利回りが7%（いずれもインフレ調整後）。世界が戦争・リーマンショックなどの恐慌を経て、でっこみ引っ込みありながら、リスクを取った場合の歴史的な利回りの上限値であるといえる。

不動産投資の場合、都内・新築で2-3%、郊外・築古で8-12%（いずれも実質利回りで幅があるが全てを網羅することはできない）。

これらを見ると、7%という利回りがどれだけリスクを織り込んでいる数値かが分かる。

インバウンド需要は増えているが、成田に限った話ではない

まず、近隣の空港と比べてみる。（数字は2024年度のもの）

総旅客数は、羽田が約8,800万人、成田が3,980万人。国内線でみれば羽田は約6,400万人、成田はほぼ無し。つまり、成田はインバウンドの玄関口になっている。

次に年間発着枠であるが、羽田が約45万回、成田が約30万回である。インバウンドの旅行客数は、コロナを経て、また円安になっていることから増加傾向にあり、羽田も成田の年間発着枠は不足気味にあると言われている。そのため、両者とも増強計画がなされている状況にある。

つまり、インバウンド需要が高まっているのは成田に限らない話である。

成田空港周辺が発展するイメージが沸かない

空港周辺にあるのは、利用客向けのホテルか、あるいはゴルフ場、物流施設などが中心である。

また、東京都心まで出るためにかかる時間（ここでは東京駅としよう）を考えると、成田は約1時間（成田エクスプレス利用）、羽田は約31分（京急利用）。

また、成田周辺の地価は羽田周辺に比べ1/10、周辺に存在する主な事業者は物流・倉庫業等。人口規模も違う。それらを見れば、インバウンド観光客が楽しめるところがどれくらいあり、今後もどれくらいの需要が見込まれるか、十分な収益が生まれる具体的なイメージを持つことができなかった。つまり、私にとって7%の想定利回りというのは、市場の高い成長性を反映したものというより、事業者が負担する資金調達コストとして理解するほうが自然に思えたのである。

まとめると

資金調達としては高い金利（利回り）であり、インバウンド需要が膨らんでいるのは成田に限った話でもなく、成田周辺が発展する好材料も無い中、このプロジェクトに出資する判断材料が揃わず、ゆえに当時の判断は慎重であるべきであったと考えている。

資金調達コストというのは、市場がその案件に対してどれだけのリスクを見込んでいるかの一つのシグナルである。高い利回りには、それに見合う理由がある。市場は誰か一人だけを特別扱いしてくれるわけではない。そう考えることが、投資判断では重要なのだと思う。まあ、市場というのが一体何なのかという話ではあるが。

オンライン診療は、既往歴があったり、症状を定量的に説明できる場合には便利だが、そうでない場合はイマイチかもしれない

Sun, 05 Jul 2026 00:00:00 +0900

7月5日（日）朝、足に違和感が出た。痛風の既往歴がある私は「これは発作が来るかも？」と思い、日曜日でもあったことからオンライン診療を試してみた。

既往歴があったり、症状を定量的に説明できたりする場合にはオンライン診療は使いやすいと思うが、そうでない場合には使いづらい仕組みだなと思う。これは事業者や医師の責任というよりも「オンライン」という特性によるものかなと思う。対面診療であれば血液検査・X線検査・MRI検査などができるが、オンラインの場合は物理的にできないから、患者による説明スキルが対面診療よりも求められる。

今回、オンライン診療を選択した理由

既往歴と、直近の血液検査の結果があったため、オンライン診療を選択した。

約1か月前に血液検査を実施しており、その時に尿酸値が基準値を超えていた。
約1年前にも痛風発作の前兆があり、近所の医師からコルヒチンを処方してもらっていた。
- 普段なら領収書と薬の情報をスキャンしているのだが、今回は残っていなかった。
- マイナンバーカードを使って診察・処方を受けているので、マイナポータルから記録を辿った。

今回出た症状が初めてで、直近の血液検査の結果もなければ、整形外科なのか内科なのかすら判断がつかなかった可能性がある。

予約から診察までの時系列

着替えて、病院に歩いて行って、待って、終わって、薬局で薬をもらって、歩いて家に帰って、とかやっているよりかは時間は掛かっていないので、便利ではある。

痛風発作が出ているときには歩くのもままならず、薬を受け取りにいけない可能性もあるので使いにくいケースがあるかもしれない。その場合に取れる選択肢は3つで、代理人に受け取りを依頼するか、2日程度待って宅配される薬を受け取るか、タクシーを使うなりなんなりして自力で取りに行くかである。

7月5日（日）
- 08:05　オンライン診療の予約完了。
- 08:41　おくすり手帳の登録のお願いがSMSで届く→持っていない旨を回答
- 08:53　ファストドクターより架電も出れず
- 09:05　一度目の折り返し電話（自動音声）
- 09:14　二度目の折り返し電話（自動音声）
- 09:22　ファストドクターより架電。おくすり手帳の有無を確認
- 09:43　診察開始
- 09:47　診察終了
- 10:24　処方箋を薬局へ送付した旨、SMSで連絡
- 10:52　薬局より電話。医師へ確認事項があり、時間がかかっているとのこと
- 11:56　薬局より電話。調剤が完了したとのこと

反省点

おくすり手帳は持っておいたほうがよい。マイナンバーカードで過去の診療情報を辿れるはずなのだが、どうにも浸透していなさそうであり、こういう場合に必要になる。
電話やSMSでちょくちょく連絡が来るので、Apple Watch（Pixel Watch等でもいいが）に通知が来るようにしておいたほうがいい。今回の場合、1回電話に出れずに30分ロスしているし、ファストドクターに折り返すと自動音声対応しかない（と思われる）ので、本当に手続きが進んでいるのか不安になる。

改善をお願いしたいところ

to　ファストドクター

診察画面のステータスに「電話の折り返しを待ってるからはよ電話してこいや」とか、「折り返しの電話を準備してるから待っとれ」とか、なんかしら分かるようにしておいてほしい。初めてだと、何がどうなってるのかさっぱり分からん。
マイナンバーカードを「写真としてスキャンして送る」のではなく、「チップをスキャンして送る」方式に変えてほしい。住所変更があると、印字されている新住所が小さく、写真にすると見えにくくなるケースがあるため。
画面共有をできるようにしてほしい。過去の血液検査の結果や処方歴などを画面共有しながら医師に見せることで、説明しやすくなるため。

to　デジタル庁

「医療保険の資格情報」が、マイナポータルからファストドクターに自動接続されるようになると便利なんだけれども、できないもんでしょうか。これは事業者の実装次第なのかな？

次に向けて

24時間対応の看護師・医師への相談窓口（私が入っている医療保険に付いている）に相談し、そこで得た情報をもとにオンライン診療か対面診療かどちらがよいのかを判断するのも手かもしれない。

いずれにせよ、選択肢が増えるというのはよいことであるので、今後はオンライン診療とうまく付き合っていきたいと思う。

医療費

今回の自己負担は、合計で2,810円でした。

ファストドクターからの請求　2,330円
薬代　480円

その後

処方されたコルヒチンを2日ほど飲み、足の違和感は消え、痛風発作には至らなかった。よかったよかった。

旅行荷物、行きは宿泊先、帰りは自宅に送ってしまったほうがよい

Sun, 05 Jul 2026 00:00:00 +0900

最近、旅行の荷物を宿泊先に予め送り、帰りも送るということをやっている。そのメリットが3つほどあるかなと整理がついたのでブログに書くことにした。

移動時間を身軽に過ごせるので、あちこちに立ち寄ることができる
「いつもの道具」を使うことができる
そもそも、荷物棚を使えない場合への対策が必要である

移動時間を身軽に過ごせるので、あちこちに立ち寄ることができる

荷物が大きかったり、嵩張ったりすると、人は移動が億劫になる。例えば、昼食を摂り終え、新幹線まであと30分あるという場合、荷物が多いと待合室かホームに移動し、座って待っていようとなりがちである。そして、往々にして待合室は満席、ホームに椅子が少ないといった状況に見舞われるのがオチである。一方で荷物が軽ければ、店を見て回るとか、少し外に出てみるといった選択肢が広がるのである。私は荷物を軽くした分で、いろいろな店を見て回り、土産を買ったり、電車内での酒やつまみを入手したりするのが好きである。

「いつもの道具」を使うことができる

旅行に必要な荷物は、必ず必要なものと、あればよいと思うものに分けられると思われる。荷物の選別とは、これらのバランスをどのように取るかということになるのだが、必ずしも必要なものは減らしにくい。なぜなら減らすには、現地で調達するか、あるいはコインランドリーを利用するか等という選択肢を取る必要があり、前者の場合には帰着時に荷物の総量が増えるので論外、後者はコインランドリーが空いていなかったら元も子もない。そうなるとどうしても、あればよいと思うものを減らさざるを得ない。

私にとってあればよいものとは「いつもの道具」である。それは、寝間着、歯磨きセット、ボディタオル、ドライヤーである。宿泊先のアメニティを使うのが王道なのだろうが、今までの経験からこうした類を持ち込むか持ち込まないかでは、宿泊先での快適さが違うのである。ただ、これらを移動中に持ち歩きたくない。だから私は宿泊先に送ってしまう。これにより、移動中の身軽さと、宿泊中の快適さを両立させることができる。

そもそも、荷物棚を使えない場合への対策が必要である

最近は、航空機にせよ新幹線にせよ、荷物棚に荷物が入り切らないケースがある。航空機の場合には、手荷物として入れてしまったからには座席下に入れるか、他の場所の空いている荷物棚に入れるしかない。前者は一向に構わない（特にさっさと出たい場合には、入口近くの通路側座席で荷物を座席下に入れるのが常套手段）のだが、後者は悲惨である。

また、新幹線も旅行客で荷物棚がいっぱいになっているケースも珍しくは無く、サイズによっては座席に置くこともできず扱いに困る。

こうしたことを考えると、やはり荷物というものは少なければ少ないに越したことはなく、こんなことを考えるくらいなら送ってしまったほうが楽である。

荷物の配送料をどう見るか

荷物の発送元・到着先、重さやサイズにもよるだろうが、私の場合は高くとも片道分で3,000円を超えたことは無い。つまり往復で6,000円以下になる場合が多いのだが、これを高いとみるか安いとみるかは、時と場合によるだろう。私の場合は以下のように決めている。

公共交通機関を使う場合、または出張の場合には荷物を送る。
自家用車を使う場合には荷物は送らない。

つまり基本は送ることを前提に考えるようにしている。

そうするとどうなるか

こうして基本を送ることを前提にすると、旅行中の持ち物は最小限で済む。私の場合は、スマホ + Apple Watch + 現金 + 鍵 + ハンカチを持ち運べばよいことになるので、サコッシュ程度の荷物で十分間に合うのである。特に勝手を知っている旅行先であれば、現金すら不要かもしれない。

（補足）旅が終わってからも旅ができる

荷物にAirTagを入れておくことで、荷物の現在地の目安が分かる。いつ、どのように荷物が送られるのかを見ることで、旅が終わったあとにも旅が続いているような感覚を持つことができるので、おすすめである。

Apple Fitness+はジム、オンラインレッスンのデメリットを動画配信で潰してきた

Sat, 27 Jun 2026 21:32:50 +0900

最近、スマホを2台持ちしている。1台がGoogle Pixelで、もう1台がiPhoneである。

ということで遅ればせながらApple Fitness+が日本でも使えるようになったということを知り、ここ2週間ほどお試しをしているのだが、どうしてこれがなかなかよいのである。

始めるまでのハードルが低い

ある程度の空間があればできるので取り組みやすく、Fitnessアプリを起動すればすぐにできるので、運動することに対するハードルが低い。出張先でヨガを試してみて失敗したと思ったのは、道具（ヨガの場合ヨガマット）が必要なものは出先ではやりづらい。しかし、どうしてもヨガをやりたければヨガマットを持ち歩けばよいし、そうでなければ道具を使わないワークアウトを選べばどこでもできるのが便利である。

「同じ」ワークアウトを何度でもできる

Fitness+のワークアウトは動画で配信されているので、同じ内容を何回も繰り返しできる。ジムのレッスン配信とは異なり毎回同じであるので、2回目、3回目と慣れるに従って負荷を上げていくことができる。逆に言えば手の抜きどころが分かるという話ではある。

バッジがもらえる

例えば、初めてHIITに取り組むともらえる「初めてのFitness+のHIITワークアウト」や、Fitness+のワークアウトを10回行うともらえる「Fitness+セッション10回」などがある。ワークアウト自体は最短で5分のものを選べるので、回数を稼ぎやすくバッジも取りやすいのかなと思う。

費用は、月額払いで980円/月、年額払いで7,800円/年（650円/月）。iCloudファミリーでサブスクリプションを共有できるので、使う家族の人数によってはお手頃感があるのではないかと思う。

以前、住友生命のVitalityプログラムに登録していたときはルネサンスのオンラインレッスンに参加しており、確かに費用は安かった（220円/月で受け放題）のであるが、レッスンは時間指定があるのでどうにも使いづらかった。1週間、1日に何回もあるレッスンは都合をつけやすいのだが、週に1度しかないようなレッスンの場合、都合が合わなかったらまた来週になってしまう。それに比べればFitness+は費用は若干高く、またレッスンの数もルネサンスほど多くはないものの、動画でワークアウトができるという点はメリットと言えそうである。

ちょうど運動不足が続いていたところでもあるので、しばらくFitness+を試してみようと思う。

Google Pixelのデスクトップモードでブログを書いてみるテスト

Sun, 12 Apr 2026 00:00:00 +0900

私のスマートフォンは、Google Pixel 10 Pro Foldです。USB-C HDMIケーブルで外部モニタに接続すると、あたかもパソコンかのように使うことができます。今はこの機能を使い、かつ外部キーボード（MOBO Keyboard 2）とマウス（Logicool MX Vertical）を使用してこの記事を執筆しています。

また、このブログはHugoで作成されており、その元ネタはすべてGitHubに保存されています。つまり、ブラウザでGitHub Codespacesにアクセスして記事を書きコミットすれば、自動的に公開されるのです。

執筆中の画面はこんな感じです。

この仕組みをうまく使えば、外出先からでも気軽にブログ記事を書くことができるので便利です。

Claude CodeでオウンドメディアのAI編集部を立ち上げてみた

Mon, 23 Feb 2026 00:00:00 +0900

※ この記事は、誤字脱字、表現の冗長さ・曖昧さのチェックのためにClaude Codeを利用しています。

TL;DR

Claude Codeの SKILL と AGENTS を使い「マネーブログ　AI編集部」（オウンドメディアの編集部、うまくいけばアフィリエイトでお金儲けしようとした）を構築した。人間が事業計画・役割・ワークフローを定義し、Claude Codeがそれを実装するという役割分担で立ち上げた。
編集長AIに課した承認条件が厳しすぎ、編集者AIが指摘を受けては記事を修正するループが止まらず、コンテキストを食い潰した。これは承認条件を緩和し、完走できるようになった。
しかし、執筆された記事はいかにもAIが書いたような文体になってしまった。どのような文体で表現して欲しいのかを明確に定義しておく必要があったと考えている。
「事業計画を定義し、その評価基準でAIの成果物を評価する」という構造設計は成立した。ただし、今回はコンテキストの消費量が多く、セッションの中で何度もフィードバックループを回すと言うことができなかった。

なぜAI編集部を作ろうとしたのか

オウンドメディアで記事を継続的に発信するのは、手間がかかる。テーマ選定、調査、執筆、校正、ペルソナによるレビューなどを一人でやり続けることには限界がある。Claude Codeを日常的に使っていると、「この一連のワークフローをAIに任せられないか」と考えるのは自然な流れだった。

ただし、やみくもにAIに任せるだけでは成果物の品質が担保できない。AIに何かを評価させるためには、事前に評価基準を定義しておく必要がある。これは前回の『ローカルLLMでSpec Driven Developmentは、まだ難しかった』での経験とも重なる。人間が最初にゴールを定義し、AIがそれに基づいて実装する というSpec Drivenな構造がなければ、AIの出力物を評価し、修正を行うと言う一連のフィードバックループが成立しない。

`.claude`の構成

今回の .claude のディレクトリ構造は次のとおりである。

プレーンテキスト
.claude
├── agents # 編集長・編集部員・ペルソナ等のエージェント定義
├── docs # オウンドメディアの設計ドキュメント
│ ├── 01_Business-Model
│ │ ├── 01_Concepts
│ │ ├── 02_Design
│ │ ├── 03_Personas
│ │ ├── 04_Value-Proposition-Canvas
│ │ ├── 05_Market-Analysis
│ │ ├── 06_Business-Model-Canvas
│ │ └── 07_RoadMap
│ └── 02_Roles-and-Workflow # 組織構造・編集ルール等
└── skills
 └── article-workflow # 記事作成〜品質保証〜最終承認のワークフロー定義

docs には、人間が定義した事業計画を置く。agents と skills には、その事業計画を元にAIが実装した編集部の構成要素を置く。

人間が定義するもの

まず、Claudeと議論しながら事業計画を立案・策定した。具体的には以下である。

ビジネスモデルの定義: エレベーターピッチを起点に、ペルソナ、バリュープロポジションキャンバス、市場分析などを一通り整備した。
ロールと役割の定義: チーム構成、各メンバーの役割と責任、ワークフロー、編集ルール、ペルソナを定義した。

これらがAIの成果物（今回でいうとオウンドメディアの記事）を評価する拠り所になる。評価基準が曖昧なままエージェントを動かしても、その成果物を正しく評価することはできない。

AIが実装したもの

Claude Codeに対して事業計画等の資料一式を渡したところ、Claude Codeは SKILL と AGENTS を自力で設計・実装した。

SKILLの決定: 記事作成から品質保証・最終承認までの一連のワークフローを article-workflow として定義した。実は、事業計画の中で記事の承認基準や差し戻し基準を明示的に定義していなかったが、私が渡した情報をもとにClaudeが適切に補完した。
AGENTSの決定: 編集長、編集部員、ペルソナ（4名）を定義した。エージェントが達成すべき役割だけでなく、エージェント間でどのような情報を受け渡しするかというインターフェースも、ここで定義されている。

実装自体はMarkdownを書くだけなので、手間は大きくない。ただし今回は、SKILL や AGENTS の分割や、どのように書いた方が効果的なのかはClaudeの方が理解しているだろうと判断し、すべてClaudeに任せた。

問題は、Claudeの成果物のレビューである。「編集部の作業内容」と言う一次情報を持ち合わせていなかったため、Claudeの成果物にハルシネーションが含まれているかどうかの判断が難しかった。今回は常識的な範囲で荒いレビューを行った。未知の分野でAIを使った場合、ハルシネーションを見抜くのは非常に難しいため、AI時代においても一次情報の重要性は変わらないか、より増すものと考えられる。

実際のところ、どうだったか

問題1: 編集長の承認条件が厳しすぎてコンテキストを食い潰した

最初に設定した承認条件はこうだった。

markdown
- [ ] ペルソナAI（4名中3名）が「推奨」している
- [ ] 編集長AIの「重要な」指摘事項が0件である
- [ ] ビジネスモデルとの整合性が星4つ以上
- [ ] 読者に与える価値が星4つ以上

良かれと思ってペルソナの属性や性格が被らないように設計した結果、3名全員の「推奨」を取り付けることはほぼ不可能だった。編集長AIの重要指摘事項0件もほとんど達成できない水準だった。これにより、編集者AIが修正 → 編集長AIとペルソナAI4名がレビュー → 指摘に基づいて編集者AIが修正 → …となってコンテキストを食い潰し、article-workflow がセッション内で完走できないケースが続いた。

そこで、承認条件を緩和した。

markdown
- [ ] ペルソナAI（4名中2名）が「推奨」している
- [ ] 編集長AIの「重要な」指摘事項が1件以下である
- [ ] ビジネスモデルとの整合性が星4つ以上
- [ ] 読者に与える価値が星4つ以上

ペルソナAIの推奨人数を4名中3名から4名中2名に下げ、また、編集長AIの重要な指摘事項を0件まで落としたことでワークフローが通せるようになった。ローカルLLMであれば seed や temperature 等のパラメータを設定できるので修正指示も一貫する可能性があるが、Claudeの場合はユーザが制御できないようになっており「発散する可能性」を制御できず、修正指示が収束しない可能性を考慮した結果である。つまり、AIの決定性・非決定性は、ワークフロー設計の前提条件になると言うことである。

また、星4つ以上の条件は据え置いた。オウンドメディアと事業戦略の整合性を維持しなければ、記事と記事の間に矛盾が生じるため、ここは緩めなかった。結果として、セッション内で3記事程度は作れるようになった。

エージェントを利用する際、チェックの基準を厳しくしすぎると修正ループが発生し、コンテキストを消耗する。実際の挙動を見ながら調整していく必要がある。

問題2: 執筆された記事が似非マーケターが書いたような内容になった

出力された記事は、如何にもAIが書いたような文体になってしまった。原因は明確だ。編集者AIがどのような文体で執筆すべきかを、最初に定義しなかったからだ。コンテキストの消費量を改善しても依然として大量のコンテキストを使うため、そのうちに面倒になり、この改善には手をつけなかった。

実際に出力された記事

「貯蓄分はないもの」を本気で実感するには、時間差が必要だった

「給料が入ったら、先に貯蓄分を別の口座に移しておく」

これは先取り貯蓄の基本として、よく言われることです。私も何度か試しました。けれど、正直に言うと、しばらくすると元に戻してしまうことが多かったんです。

なぜかというと、銀行口座から別の口座に振り込んでも、どちらも「自分の口座」であることに変わりはなく、心のどこかで「いざとなれば戻せる」と感じていたからだと思います。貯蓄口座に移したはずのお金が、結局「予備財布」のような感覚になっていました。

そんな私が、1年間で50万円を貯められるようになったのは、**自動引き落としの「時間差」**を使うようになってからです。

この記事では、なぜ手動の振込より自動引き落としの方が続きやすかったのか、その心理的な仕組みと、私が実際にやっている方法をお伝えします。あなたにとっての「続く仕組み」を考えるヒントになれば嬉しいです。

学んだこと

構造設計としての有効性: 「事業計画を定義し、その評価基準でAIがAIの成果物を評価する」という構造そのものは成立した。ルールとして明確に定義するものと、その範囲内で目的達成方法をAIに考えさせるという分業は機能した。
一次情報の重要性: 人間とAIの関係を構造設計する際、一次情報をどれだけ知っているかが重要になる。今回の場合、実際の編集部がどのように機能しているかを知らなければ、AIの成果物を厳密にレビューすることは難しい。「知らないことをAIに尋ねるのはよいが、それを評価するのは至難の業」という問題は今回も残った。未知の分野でAIを使った場合、ハルシネーションを見抜くのは非常に難しいため、AI時代においても一次情報の重要性は変わらないか、より増すものと考えられる。
コンテキスト管理の設計: コンテキストの消費量が多いと、改善のフィードバックループが回しにくくなる。今回は CLAUDE.md を活用せずに進めたが、コンテキストの使用効率を高める手段を積極的に取り入れるべきだった。
インデックスの必要性: ZettelkastenにおけるStructured Noteのようなインデックスが、AIのコンテキスト展開を段階的に制御するために重要だと気づいた。AIに何をどこまで読み込ませるかを決めるには、インデックス情報が必要になる。これは前回の『ZettelkastenをRAGの情報源として有効活用するには、ノート間のリンクに「意味ラベル」をつけ、型付きのエッジを持たなければならない』での考察とも合致する。今回利用した SKILL や AGENTS では、このインデックス情報はうまく活用しきれていない。そのため、CLAUDE.md を使うことはこの文脈において有効な手段であると考えている。

次にAIエージェントを立ち上げるときに考えておきたいこと

CLAUDE.md のように、コンテキストの使用効率を高める方法を最初から組み込む。
コンテキスト消費量とフィードバックループの速度はトレードオフになる。いかに効率を高めながらループを回すかが設計の肝になる。
文体や表現スタイルは、事業計画と同じタイミングで定義しておく。後からでは手遅れになる可能性が高い。

まとめ

Claude Codeの SKILL と AGENTS を使ったAI編集部は、形として動かすことはできた。人間が事業計画・役割・ワークフローを定義し、AIが実装するという構造設計は機能した。また、その定義が「AIエージェント間」での拠り所にもなっている様子が見てとれた。
承認条件の設計ミス（?）によるコンテキスト枯渇と、文体定義をしなかったことによる記事の品質低下という、二つの失敗が発生した。いずれも設計段階での考慮不足が原因であり、実装後に気づいても取り返しにくい。
コンテキストの消費量を管理しながらフィードバックループを回す設計が、AIエージェント活用の中心的な課題になる。

ZettelkastenをRAGの情報源として有効活用するには、ノート間のリンクに型付きエッジを持たなければならない

Sun, 22 Feb 2026 00:00:00 +0900

※ この記事は、誤字脱字、表現の冗長さ・曖昧さのチェックのためにClaude Codeを利用している。

TL;DR

本記事で提案する「手動による型付きエッジの付与による運用」は、GraphRAGやNeo4j RAGとは異なり、型付きエッジを手動で付与する。これにより、Zettelkastenの探索を人間の手によって制御し、かつインフラの運用コストを抑えることができる点に差別化要素がある。
ZettelkastenをRAGの情報源として使う場合、ノート間のリンクに型付きエッジを付与しなければ、AIはグラフを無限に辿ってコンテキストが膨張する 。
人間はリンクの意味をノートの文脈から推測できるが、AIにはその判断ができない。これは「人間にとってわかりやすいリンクはAIにとって分からない」という構造的な非対称性である。
データの意味付けを軽視してきた歴史（セマンティックウェブ、ビッグデータ、企業RAG）は、同じ失敗パターンの繰り返しだと解釈できる。
付与する型付きエッジとして supports → / contradicts → / refines → / depends_on → の4種を提案する。
コンテキストが膨張するとOOMによるクラッシュ（MLX）や推論崩壊（llama.cpp）が起きる。これは設計の問題であり、パラメーター調整で解決できるものではない。
実際に計測したところ、型付きエッジによる制約付きグラフ探索（constrained graph traversal）でトークン使用量を約70%削減（556,006 → 163,782トークン）しながら、回答品質をほぼ維持できることを確認した。
ただし、リンクに対する型付きエッジの付与だけが解決策ではない。どこを意味付けし、どこをしないかという全体設計が必要である。

なぜ、ノート間（リンク）の関係を自動抽出ではなく手動で行うのか（はじめに）

GraphRAG¹ や、Neo4j RAGのような手法では、異なる2つのエンティティ間の関係を自動抽出し、型付きエッジを持つグラフを構築する。本記事の提案は、これらと同じくグラフのトラバーサルを意味的に制御するものであるが、設計の前提が異なる。

第一に、ZettelkastenのAI（Claude）による自動操作はすでに試みており、失敗している。AIにノートの作成・メタデータ付与・構造操作を任せた結果、ノイズが混入し、知的生産の基盤としての機能を失った（詳細は『Zettelkastenを機能させ、また形骸化させないために、何でもかんでも入れるべきではない』を参照）。Zettelkastenは自分の思考の蓄積であり、AIによる自動操作とは相容れない。

第二に、インフラコストの問題がある。GraphRAG/Neo4j RAGはグラフDBや埋め込みモデルの常時稼働を前提とし、個人が複数台の端末間で使い回すには重すぎる。本記事の設計は、ObsidianのMarkdownファイルとClaude(MCP)のみで完結し、端末を問わず持ち運べることを条件としている。

つまり、手動による型付きエッジの付与を選んだのは、自動化の限界を実体験した結果と、軽量・ポータブルであるという制約条件の両方によるものである。この選択におけるGraphRAGとの差分は「自動か手動か」だけでなく、「運用環境の重さ」と「Zettelkastenの思想との整合性」にある。

きっかけ

『ローカルLLMでSpec Driven Developmentは、まだ難しかった』という記事を書きながら、「自分のZettelkastenをRAGの情報源として接続すれば、自分の思考を元にした回答が得られるのではないか」という考えが浮かんだ。

ただし、この設計を考えるにあたって、1つの前提がある。過去にAIにノート操作を任せた結果、Zettelkastenがノイズだらけになるという失敗を経験している（『Zettelkastenで管理する情報は何で、どう管理すべきなのか』、『Zettelkastenを機能させ、また形骸化させないために、何でもかんでも入れるべきではない。』）。その経験から、「AIはZettelkastenを読むことはできるが書いてはいけない」という原則をすでに確立している。今回の設計はその原則の上に成り立っている。

しかし、実際に試そうとした瞬間、問題が見えてきた。Zettelkastenのノートはネットワーク型の構造になっており、ノート間には無数のリンクが張り巡らされている。RAGとして使うということは、AIがそのネットワークを辿ってコンテキストを組み立てることになるが、「どのリンクをどこまで辿るか」という制御をどうするかが難しい。

そこで少し考えてみると、問題の本質は「ノート間に型付きエッジが付与されていない」ことだということに気がついた。

ZettelkastenとRAGの相性問題

そもそもRAGとは何かを整理しておく。RAGは、LLMが一般的な訓練データから回答を生成するのではなく、特定のドキュメント群（情報源）を参照しながら回答する仕組みだ。ハルシネーションの影響範囲を限定し、特定ドメインに閉じた回答を得るための構造設計の方法論として使われる。具体的には、Zettelkastenとの組み合わせで期待できるのは、「自分の思考・知識を格納したナレッジベースを、AIが参照しながら回答できるようになること」だ。

ところが、ZettelkastenをそのままRAGとして活用すると問題が起きる。Zettelkastenのノートはそれぞれが他のノートへのリンクを持っており、関連するノートをどんどん参照する構造になっている。AIがネットワークを辿り始めると、関連ノートをすべて読み込もうとしてしまい、コンテキストが際限なく膨張する。

これは設計の問題だ。RAGという文脈においては、どのリンクをどこまで辿るかを制御する「制約付きグラフ探索」がなければ、Zettelkastenは有用な情報源にならない のである。

リンクの「意味」は、人間は理解でき、AIには理解できない

リンクの制約付きグラフ探索の問題は、「このリンクは辿るべきか、辿らなくてよいか」をどう判断するか、である。

人間はノートを読みながら、リンクの意味を文脈から推測できる。「このリンクは根拠として貼ったもの」「このリンクは反論の候補として貼ったもの」「このリンクは前提知識として必要なもの」といった区別を、リンクを貼った瞬間に理解している。

しかし、AIにはそれが分からない。リンクはただの接続であり、その接続が「支持」なのか「反論」なのか「依存」なのかを、ただのリンクから読み解くことはできないのである。

プレーンテキスト
[人間の場合]
ノートA ──リンク──> ノートB
 ↑
 「これは根拠ノートだ」と文脈から判断できる

[AIの場合]
ノートA ──リンク──> ノートB
 ↑
 意味が分からない。全部辿るしかない。

これは「人間にとってわかりやすいリンクはAIにとって分からない」という構造的な非対称性だ。この非対称性を放置したまま「ZettelkastenをRAGに使う」という設計は、機能しない。本質的には『「顧客はわかっていない」を構造的に再解釈する』で議論した内容と同じである。

データの意味付けを後回しにしてきた歴史

この問題は、実は繰り返されてきた「うまくいかない」パターンと同じ構造を持っている。

(1) セマンティックウェブ

Web 2.0の台頭で、膨大な個人メディアがウェブに溢れたとき、ティム・バーナーズ・リーは、RDFやOWLといったメタデータ技術によって情報に意味を付与する「セマンティックウェブ」を提唱した。機械が情報の意味を解釈し、より賢い検索・統合ができるようにするというビジョンだった。

しかし、広くは普及しなかった。既存の膨大なデータにメタデータを付与するコストが、得られるメリットに見合わなかったからだ。現在はベクトル検索との共存という形で、その理念が部分的に受け継がれている。

(2) ビッグデータ

Hadoopなどのデータ分析基盤が「大量のデータに価値がある」という前提で作られた時代、データの意味付けはないがしろにされた。データが何を意味しているのかが分からない状態で分析を行い、期待通りの洞察は得られなかった。

(3) 企業におけるRAG活用

現在も同じパターンが繰り返されている。企業内に存在するExcelやPowerPointといった非定型データをRAGに登録しても、望む回答精度が得られないという課題がある。原因は単純で、ドキュメント内の要素がどのような文脈でどのような意味を持つのかを、AIが理解できないからだ。意味付けのない情報をいくら積み上げても、AIはそれを有効に活用できない。

情報の蓄積に価値があるという幻想と、意味付けのコストを軽視してきた結果が、この繰り返しである と私は考えている。この課題を解決しようとしている企業が多く存在していることからも、今回は同じ繰り返しをしないようにしていると考えられる。

型付きエッジを付与したリンクの提案

この構造的な非対称性を解消するために、リンクに「型付きエッジを付与する」設計を考えた。リンクの種類を以下の4つに分類し、リンクを貼る際に明示的に意味付けを行う。

型	意味	用途
`supports →`	このノートの根拠	主張の根拠を支えるノートへのリンク
`contradicts →`	このノートへの反論	反論・対立する視点へのリンク
`refines →`	このノートの洗練・具体化	上位・下位概念の関係、より詳細な説明へのリンク
`depends_on →`	このノートの前提条件	読む前に理解すべき前提知識へのリンク

実際の記述例はこうなる。

markdown
## 主張

ZettelkastenをRAGの情報源として有効活用するには、ノート間のリンクには型付きエッジを付与する必要がある。

- supports → [[人間にとってわかりやすいリンクは、AIにとっては分からない]]
 - context: 人間はリンクの意味を文脈から推測できるが、AIはできない。

- depends_on → [[Zettelkastenのノート間のリンクは型付きエッジによって意味づけしておくことが重要]]
 - context: 型付きエッジがなければ、AIはグラフを無限に探索してしまう。

この設計をすることで、制約付きグラフ探索が可能になる。たとえば「supportsリンクだけを辿る」「depends_onは1ホップまで」といったルールをクエリ時に適用できるようになる。

なお、contradictsリンクが多いノートは、未解決の領域あるいは思考の臨界点を示していることになる。これはAIへの指示の文脈だけでなく、ノートを管理する人間にとっても有用な情報になる。

ただし、この方法には、型付きエッジを後から付与するためのコストが爆発的に増えるという課題がある。

制約付きグラフ探索の効果を計測する

提案している設計の効果を確認するために、実際にトークン使用量を計測した。170ノート・41,370文字・207リンクで構成されたZettelkastenを対象に、「生成AIにおけるRAGの現状と課題」を調査するタスクをClaude Codeに依頼し、制約付きグラフ探索によってどれほど差が出るかを比較した。

条件	サブエージェント実行数	トークン使用量
制約付きグラフ探索なし	12回	556,006トークン
制約付きグラフ探索あり	4回（約67%削減）	163,782トークン（約70%削減）

なしの場合、AIはすべてのリンクを辿るために12のサブエージェントを起動し、55万トークン超を消費した。ありの場合は、型付きエッジをもとに必要なノードに絞り込み、4エージェント・16万トークン強で完了した。

回答品質についても比較した。

回答事項	制約付きグラフ探索あり	制約付きグラフ探索なし
1. RAGの本質的な役割（Vaultが示す再定義）	回答あり	回答あり
2. 実装アーキテクチャの変遷（実体験ベース）	回答あり	回答あり
3. AI Engineer ／ Application Developer の責任境界	回答あり	回答あり
4. ベクトル検索とメタデータの共存	回答なし ²	回答あり
課題1：データ意味付けの困難さ（最重要課題）	回答あり	回答あり
課題2：コンテキスト長の膨張と推論エンジンへの影響	回答あり	回答あり
課題3：リンク意味の不透明性	回答あり	回答あり
課題4：AI／人間の判断境界設計	回答あり	回答あり
課題5：データ更新・削除の複雑性	回答あり	回答あり
課題6：机上設計と実装の乖離	回答あり	回答あり
課題7：歴史的失敗の反復リスク	回答なし ²	回答あり

ありで「ベクトル検索とメタデータの共存」「歴史的失敗の反復リスク」の2項目が未回答となったが、これは型付きエッジによって選ばれたノード群が中心的な問いに絞り込まれた結果であり、カバレッジの欠落ではなく焦点化の結果と解釈している。

トークン使用量を約70%削減しながら回答品質をほぼ維持できたことは、制約付きグラフ探索の有効性を裏付けている。また、データを絞ることでAIが中心的な問いにフォーカスするという副作用も確認できた。コンテキストの膨張は「情報量が多ければ回答の質が上がる」という直感に反し、むしろ回答品質を下げる可能性があることを示唆している。

コンテキスト膨張は実害を生む

これは概念的な話ではなく、『ローカルLLMでSpec Driven Developmentは、まだ難しかった』で身をもって経験した実害でもある。コンテキストが膨張すると、推論エンジンはOOM（Out of Memory）に陥る。その挙動はエンジンによって異なる。

MLX（mlx_lm）: OOMが発生した時点でクラッシュする。これ以降の推論崩壊を防ぐための設計だが、処理が中断される。
llama.cpp: OOM後も ctx_pos / n_past が進み続け、初期化が保証されていないKV Cacheを参照しながら推論を続けてしまう。結果として推論崩壊が起きる。

どちらが良い悪いではなく、設計思想のトレードオフだ。しかし、いずれにしてもコンテキストを膨張させないことが根本的な解決策であり、制約付きグラフ探索はその手段の1つになる。

課題

制約付きグラフ探索は1つの解だが、リンクだけを整備すれば十分というわけではない。ノート内のどの部分がAIにとって「文脈」として有効なのか、何をZettelkastenにおけるメタデータに含めるべきか、ノート自体にどのようなメタデータを持たせるかといった設計の問いは、リンクに対して型付きエッジを付与した後にも残る。型付きエッジの付与は「設計行為」であり、どこを付与し、どこをしないかという全体像を先に決めなければ、部分最適に終わる という考えである。

また、既存の大量のノートに型付きエッジを後から付与するコストも現実的な障壁だ。セマンティックウェブが普及しなかった理由の1つが「既存データへのメタデータ付与コスト」だったこと、GraphRAGが自動で検出を試みていることの2つを考えると、新規ノートから型付きエッジを付け始めて様子を見るスモールスタートが現実的だろうと考えている。

まとめ

ZettelkastenをRAGの情報源として接続するには、ノート間のリンクに型付きエッジが必要である。型付きエッジがなければ、AIがグラフを無限にトラバースしてコンテキストが膨張する。実際の計測では、型付きエッジをもとにした制約付きグラフ探索なしで556,006トークン・12エージェントだったのに対し、ありでは163,782トークン・4エージェントに抑制できた（それぞれ約70%・約67%の削減）。
これはデータに対する型付きエッジの付与を軽視してきた歴史（セマンティックウェブ、ビッグデータ、企業RAG）と同じ構造である。情報の蓄積には価値があるが、意味付けなき蓄積は、AIがそれを有効活用できないという点で、「何を蓄積するか」以上に重要な論点になる。
Zettelkastenのノート間のリンクに意味付けを行うという点においては、supports → / contradicts → / refines → / depends_on → の4種の型付きエッジを提案する。これにより制約付きグラフ探索が可能になると考えている。
コンテキスト膨張はOOMクラッシュや推論崩壊という実害を生む。これはパラメーター調整ではなく、設計で解決すべき問題である。
リンクの型付きエッジは解決策の一部であり、全体の意味付け設計と合わせて考える必要がある。
- リンクの型付きエッジは、双方向リンクに対しては爆発的にコストが大きくなる。片方向だけで十分かどうかも含めて検討する必要がある。

Edge, Darren, Ha Trinh, Newman Cheng, ほか. 「From Local to Global: A Graph RAG Approach to Query-Focused Summarization」. arXiv:2404.16130. 査読前原稿, arXiv, 2025年2月19日. https://doi.org/10.48550/arXiv.2404.16130. ↩︎
制約付きグラフ探索ありで「回答なし」となった項目は、型付きエッジによって選ばれたノート群が中心的な問いに絞り込まれた結果、AIが回答対象として設定しなかったものである。カバレッジの欠落ではなく、焦点化の結果と解釈している。 ↩︎ ↩︎

「顧客はわかっていない」を構造的に再解釈する

Sun, 15 Feb 2026 00:00:00 +0900

TL;DR

「顧客はわかっていない」という感覚は お互いの思考限界がズレている ことを示しているに過ぎない。
顧客は技術的制約を思考限界の外に置き、技術者はビジネス文脈を思考限界の外に置く。この非対称性が衝突を生む。
優れたアーキテクトは、思考限界を動的にずらしながら、顧客・技術者・システムの三者間をコーディネートする。この能力を 構造設計能力 と呼ぶ。
AIとの協働においても、まったく同じ構造が成立する。「AIに何をさせ、何をさせないか」の設計と、「顧客と何を共有し、何を委ねるか」の設計は、同じ問いの別バージョンである。
「顧客はわかっていない」という思考は未熟である。問うべきは「どの思考限界をどこへずらすか」である。

きっかけ

顧客との打ち合わせのあと、「あの人は技術的なことが全くわかっていないから、好き勝手なことを言う」と感じることがある。おそらく多くのエンジニアが、一度はそう思ったことがあるはずだ。

一方で、最近AIを使った開発を進める中で、ある気づきがあった。AIに対して「なんでこんなことをするんだ」「指示通りにやってくれない」と感じる場面が増えてきた。これは、顧客に対して感じることと、構造的にとても似ている。

では、「顧客はわかっていない」という感覚は、本当に正しいのか。逆に顧客の立場から見たらどうなのか。AIとの対比を通じて、この問題を構造的に整理してみたい。

思考限界というフレームワーク

まず、「思考限界」という概念を導入する。

人は誰でも、自分が認識できる範囲に「限界」を持っている。業務を知り尽くしている顧客は、システムがどう実装されているかを必ずしも知らない。逆に、技術者はシステムを構築できるが、その業務がなぜ今の形になっているのか、歴史的・組織的な文脈を把握していないことが多い。

プレーンテキスト
[顧客の思考]
思考限界の内側: 業務知識・経営判断・ユーザー体験
思考限界の外側: 技術的制約・実装コスト・インフラ構造 ← まだ見えていない

[技術者の思考]
思考限界の内側: 技術スタック・実装難易度・パフォーマンス特性
思考限界の外側: 業務フロー・組織の意思決定構造・顧客の顧客の要求 ← まだ見えていない

「顧客はわかっていない」という発言は、技術者の思考限界の内側にある情報を、顧客が持っていないことへの苛立ちである。しかし同時に、顧客の思考限界の内側にある情報を、技術者も持っていない。この非対称性は、どちらかが「わかっていない」という話ではなく、 互いに相手の思考限界の外側に重要な情報を持っている という構造の問題だ。

アーキテクトの役割：思考限界をずらす

では、どうすればよいのか。ここで登場するのが「思考限界を動的にずらす」という設計行為だ。

たとえば、顧客が「膨大なデータを、リアルタイムで全件表示したい」と要求してきたとする。技術者は「100万件を毎秒描画するのは不可能だ」と思う。この時点で衝突が生まれる。しかし、ここで優れたアーキテクトが行うのは、「それは無理です」というのではなく、自身が持つ技術知識をもとに、顧客の思考を分解して考え、思考限界を技術的制約の側に一歩ずらすことである。

プレーンテキスト
[初期状態]
顧客の思考限界の内側: 「全件リアルタイム表示」

↓ アーキテクトが制約を可視化

[目的達成可能な状態]
顧客の思考限界の内側: 「集計ビュー + 閾値超過時のアラート」← 移動させる
顧客の思考限界の外側: 描画コストの詳細（もはや意識不要）

顧客が本当に欲しかったのは「全件表示」ではなく、「意思決定に必要な情報をタイムリーに得ること」だったかもしれない。このように、思考限界をずらすことで、本来の目的に辿り着ける。これが構造設計能力の本質だと考えている。このとき、制約は「できないことの証明」ではなく、 目的へ向かうための設計上の道具 として機能する。制約を設けることでトレードオフが生まれ、そのトレードオフを顧客と共有することで、はじめて合意形成ができる。

AIとの協働に見る、同じ構造

最近、AIを使った開発を進める中でまったく同じ構造を感じるようになった。AIに対して自由さを与えると、出力が発散する。逆に、過度に細かい制約を与えると、AIは制約の範囲でしか動けず、本来解けるはずの問題も解けなくなる。

AIに「思考させる範囲」と「人間が判断すべき範囲」を設計することは、顧客の思考限界と技術者の思考限界の境界を設計することと、構造が同じだ。

Vibe-Codingが崩壊するのも、この制約の設計が欠如しているからだと理解している。RAG、Spec Driven Development、エージェント設計といった手法は、すべてAIの思考限界を設計的に制御する試みであり、「AIに何をわからせ、何は人間が持つか」を明示化するアプローチだ。

対顧客も対AIも、 思考限界の境界を設計することが、問題解決の核心 にあると考えている。

思考限界を動的にずらすことに成功した例

OpenShift：「強制」という制約が自由をもたらす

以前調べたRed Hat OpenShiftが良い事例だと感じた。OpenShiftはGit・OCI・Kubernetesという業界標準を強制することで、開発者の思考限界を「何を使うか」から「どう使うか」にずらしている。

AWS（サービスの集合体）は設計の自由度が高い反面、「何を選ぶか」という判断コストが利用者に集中する。OpenShiftは、その選択の余地をあえて削ることで、350人規模の開発チームでもオンボーディングコストを下げることに成功した。

「強制」という制約が、実は「自由に動ける範囲」を明確にしていた。これはまさに思考限界をずらす設計の実例だ。

Porsche Informatik：「枠」が組織のしがらみを溶かす

Porsche InformatikがプライベートクラウドからOpenShiftに移行した際、6週間で移行を完了し、350人超の開発者が常時利用する環境を実現した。「枠」という制約を設けることで、オープンソースの自由さと、組織の標準化要求という相反する要件を両立している。

これは、顧客（経営層・開発チーム）の思考限界に「標準化された開発プラットフォーム」という概念を移植した結果だと言える。

「構造設計能力」という自己研鑽の方向性

ここまでを整理すると、技術者に求められる能力は次のように言い換えられる。

「自分の思考限界がどこにあるかを把握し、顧客や技術者の思考限界を動的にずらしながら、目的達成へコーディネートする能力」

これを構造設計能力と呼ぶことにしている。技術者の自己研鑽とは、何かの技術を追い続けることによって、「自分の思考限界がどこにあるかを探究し続けること」だと思っている。技術書を読む、新しいフレームワークを触る、顧客の業務フローを深く学ぶ、これらはすべて「自分の思考限界を広げる」行為だ。

ただし、もうひとつ重要なことがある。思考限界を広げるだけでなく、どこに境界を置くかを設計する能力 も同時に必要だということだ。自分が何でも知っていようとすることは、「何でもできるノートパソコン」と同じで、帯に短し、襷に長しになりかねない。何を知っていて、何を知らないのかを具体化し続けることが重要なのではないだろうか（難しい話だが）。

構造設計能力とは、知識の総量ではなく、知識の境界を設計する力 だと今は考えている。

まとめ

「顧客はわかっていない」は、思考限界の非対称性を正確に言い表した言葉ではあるが、それ止まりでは未熟な認識である。
問うべきは「どの思考限界を、どこへ、どうずらすか」であり、この設計行為がアーキテクトの核心的な仕事だと考えている。
AIとの協働においても、この構造はまったく同じだ。「AIに何をわからせるか」の設計と、「顧客に何を共有するか」の設計は、同じ問いの異なる文脈での現れである。
思考限界の自己研鑽は終わりのない旅だが、その方向性は「限界を広げること」と「限界の境界を設計すること」の両輪で成り立つ。

Red Hat OpenShiftのDeveloper SandboxをAWSと比較しながら触ってみた

Sun, 15 Feb 2026 00:00:00 +0900

TL;DR

AWS は多数のサービスを組み合わせて使う Service の集合体であり、自由度が高い反面、設計・統合の責任は利用者側にある。
Red Hat OpenShift は業界標準（Git / OCI / Kubernetes）を強制する Platform as a Product として設計されており、最初から統合された開発・運用体験を提供することを目的としている。
Developer Sandboxでは以下の点から、迷わず進める体験が強く印象に残った。
- Gitリポジトリ指定だけでビルド〜デプロイまで完結する。
- Podログ・ターミナル・リソース使用量が1画面で確認可能である。
- AIアシスタント Lightspeed により学習コストが低減している。
Developer Sandboxの基盤はAWS EC2上で動作しているが、実体はROSA(Redhat OpenShift Service on AWS) 上のOpenShiftであり、マルチクラウドで動作することをログレベルで体感した。
閉域網要件やオンプレ併用が求められる企業システムでは、OpenShiftのマルチクラウド設計が大きな強みになる。また、上記の理由から組織の習熟度やスキルに応じて、選択肢の幅を広げていることにもつながる。
結論として、AWSは“自由を最大化するプラットフォーム”、OpenShiftは“標準化で速度と再現性を出すプロダクト”であり、優劣ではなく設計思想の違いが現れているのだと実感した。

きっかけ

普段の仕事では、AWSを使う機会が多い。ECS/Fargate、CodeBuild、Lambdaなど、サービスを組み合わせて作ること、その考え方には慣れてきたが、一方でその「組み合わせる責任」を、常にアーキテクトが負っていることは感じていた。「追いかけ続けるのは大変だ」と思う今日この頃です。

そこで、とあることがきっかけとなりRed Hat OpenShiftが Platform as a Product という考え方で設計されていると知り、それがAWSとどう違うのかを自分の手で確かめてみたくなり、無料で使える Developer Sandbox があると知り、週末を使って触ってみた。

Platform as a Service vs Platform as a Product

AWSを一言で表すとすれば サービスの集合体 だろう。EC2、RDS、Lambda、ECSなど、数百に及ぶサービスが並んでおり、利用者はその中から自分のユースケースに合ったものを選び、組み合わせて使う。自由度は極めて高い。

しかし裏を返せば、どのサービスをどう組み合わせるかの設計責任はすべて利用者にある ということだ。CI/CDパイプラインを1本作るにも、CodeCommit → CodeBuild → Amazon ECR → Amazon ECSという工程を整え、IAMロール、セキュリティグループなど、自分で判断、設計しなければならない。熟練者には自由だが、習熟の浅いエンジニアには高い壁になる。

それに対して、OpenShiftのアプローチは対照的だ。Git、OCI（ Open Container Initiative、コンテナ規格）、Kubernetesといった業界標準を強制することで、開発者が最初からある一定の土台の上に立てる設計になっている。何でもできる、のではなく、標準という枠に沿ってできる、というわけだ。

この「強制」はベンダーロックインの回避にも繋がっている。OpenShiftはAWS/Azure/オンプレミス等で動作する。アプリケーションコードはどの環境でも同じように動く。AWSのマネージドサービスに依存した設計と違い、インフラの切り替えコストが低い。

Developer Sandboxで試したこと

Lightspeedとの統合

OpenShiftはコンソールにAIアシスタント Lightspeed が統合されている。試したのは、Podが起動していない状態でどうアクセスすればよいかを尋ねる場面だ。

私: The pods are not running so I cannot connect via ssh. If the pods are running, I can connect to these pods via console from anywhere?

Lightspeed: Yes, if the pods are running, you can connect to them using the OpenShift console or CLI from anywhere, provided you have network access to the cluster and the necessary permissions. Here’s how you can do it:

OpenShift Console: Access the OpenShift web console using your browser. Navigate to the specific project and pod, and use the terminal feature to open a shell inside the pod.

OpenShift CLI: Use the oc command-line tool to interact with the pods. You can start a remote shell session with the following command: …

KubernetesやOpenShiftの概念を前提とした回答が返ってくるため、独自ドキュメントを読み漁る前に「なぜこうなっているのか」の文脈を掴める。経験の浅いエンジニアでも自己解決までの距離が縮まる、という点でこの統合は意味が大きいと思う。

Gitからのデプロイ

まず試したのが、Gitリポジトリからのデプロイである。Developer Sandboxの画面からGitリポジトリのURLを指定するだけで、コンテナのビルドからPod・Serviceの生成まで自動で行われる。

GitHubのリポジトリに限らず、自前のGitサーバ、CodeCommitなど、名前解決できる場所にあれば何でも使える。

AWSで同じことをしようとすると、CodeCommit（またはGitHubとの連携）→ CodeBuild（ビルド設定・buildspec.yml）→ Amazon ECR（イメージ登録）→ Amazon ECS（タスク定義・サービス設定）という順を踏まなければならない。それぞれのサービスの設定と試行錯誤で1日潰れることも珍しくない。

パイプラインは難しい と感じる習熟レベルの人でも、OpenShiftなら最初のデプロイまで数分で到達できる。この体験の差は大きい。

ログとターミナルの統合

デプロイ後、ログをコンソールから確認してみた。PodのログはOpenShift ConsoleからPod単位でリアルタイムにストリーミングされる。

ログを眺めていると、気になる行が目に入った。

プレーンテキスト
Successfully assigned ***-dev/code-with-quarkus-665467cf97-9rcdb to ip-10-0-86-229.ec2.internal

ec2.internal が示すように、Developer Sandbox自体のバックエンドはAWS EC2上で動いている。実際には、Red HatがAWS上でマネージド提供するROSA（Red Hat OpenShift Service on AWS）を基盤としており、その上にOpenShiftクラスタが構成されている。このログを通じて、OpenShiftが特定のインフラに依存しないプラットフォームであることを実感した。

AWSでアプリケーションのログを確認しようとすると、CloudWatch Logs → ロググループ → ログストリームという階層を辿らなければならず、慣れていないとどこを見れば良いか迷う。OpenShiftはPodを選べばそのままログが見える。この一体感は確かに違う。

Podへの接続は、コンソールから直接できる。また、OpenShift CLI（oc）を使えば、普段使っているターミナルから一時認証情報を使ってPodにアクセスできる。

リソースの可視化

CPU・メモリ・ファイルシステムの使用状況が時系列グラフでコンソールに表示される。CloudWatchでこれを実現しようとすると、CloudWatch Agentをインストールする必要がある。OpenShiftはデプロイ直後からリソースの状況が一画面で見える。

AWSとの比較: 閉域網要件

企業システムでよく要件に上がるのが「インターネットに通信を出したくない」という閉域網の要求だ。

AWSで閉域運用を実現しようとすると、VPC Endpoint（各サービスごとに作成が必要）、Route53 Private Hosted Zone（DNS解決の制御）などを組み合わせる必要がある。設定が複雑になるうえ、VPC Endpointによって課金ポイントも増える。予算の制約とのバランスをとることも難しい。

OpenShiftはインフラを抽象化しているため、完全閉域が必要ならオンプレミス、柔軟性が必要ならクラウドという配置場所の変更が、アプリケーションの変更なしに実現できる。組織のクラウド習熟度や用途に応じて、オンプレとクラウドを使い分ける選択肢があり、さらにそれらの移動が比較的容易であると言える。

セキュリティ要件の厳しい業界（金融・公共）への提案を考えると、この柔軟性は大きな差別化点になる。

導入事例から読み解く

Porsche Informatik：6週間でのレガシー移行

市場への投入スピードを競うPorsche Informatikは、プライベートクラウドで動作していたアプリケーションをOpenShiftへ移行した。所要期間は6週間。現在は350人を超える開発者が常時利用しており、Market-inまでの時間を90%向上させたという。

スピードで語られることの多い事例だが、「350人が常時利用」という点も注目に値する。OpenShiftが「強制」する標準的な作法が、大規模な開発組織でのオンボーディングコストを下げていると考えられる。

参考: Porsche Informatik、Red Hat OpenShift でユーザーエクスペリエンスを促進

JRA（日本中央競馬会）：5000万PVの動的スケーリング

JRAは土日に1日に5,000万PV、平日はそれ以下という極端なトラフィックの波を抱えている。従来のプライベートクラウド基盤で静的にリソースを確保するのではなく、OpenShiftへ移行してHPA（Horizontal Pod Autoscaler）によるPod数の動的な増減で対応しているようだ。

成果として以下のようなものが得られているようである。

脆弱性対応の頻度が6ヶ月→2ヶ月に短縮
本番リリース作業が5時間→1時間に短縮

脆弱性対応の短縮はローリングアップデートによるOpenShiftコントロールプレーンの更新速度と、DevOpsによるアプリケーション側の対応高速化の両方が効いていると考えられる。本番リリース作業の短縮はBlue/Greenデプロイメントが機能していると思われる。現場の開発者/運用者にとっては非常に大きな改善であると言える。

なお、スケーリング戦略としてHPAを使っているのは合理的だと感じた。もしVPA（Vertical Pod Autoscaler）を使うとPodの再起動が必要になり、複雑さが増す。リクエスト数の波に対してはPod数で柔軟に対応するHPAの方が向いている。

参考: 日本中央競馬会が公式ウェブサイトのプラットフォームにRed Hat OpenShiftを採用

まとめ

Developer Sandboxを触って感じたのは、自由度と使いやすさのトレードオフに対するRed Hatなりの答えだ。

AWSは設計の自由度が高い反面、その自由を使いこなすための学習コストと、組み合わせの責任を利用者が負う。対するOpenShiftは、標準を強制することで、誰が使っても一定の品質と速度でデプロイ・運用できる土台を提供している。

Gitからのデプロイ、ログとターミナルの一体化、Lightspeedとの統合など、これらはどれも「開発者がやりたいことに集中できる環境」を実現するための設計であり、サービスを繋ぎ合わせて仕組みを作らせようとするAWSとは出発点が違う。（念のため、どちらが良い悪いではなく、思想の違いということです）

閉域網要件や既存のオンプレ資産との共存が求められる企業システムにこそ、このプロダクトの価値が発揮される場面がありそうだと感じた。

ローカルLLMのtemperatureとseedを比較：FizzBuzzと俳句を各条件3回生成してみた

Sun, 15 Feb 2026 00:00:00 +0900

先に結果

LM Studioで seed = 42 とし、temperature を0・0.3・1.2に変えて、FizzBuzzと俳句を各条件3回生成した。
temperature = 0 では、各タスクで3回とも同じ結果になった。最大スコアのトークンを選ぶ設定で、出力の再現性を確認できた。
FizzBuzzでは、0で仕様に合う関数が得られた一方、0.3と1.2では不具合を含む回答もあった。少数の試行なので、不具合の発生率までは判断できない。
俳句では、季節に合わない季語の説明や、指定した句数との不一致が見られた。プロンプト自体にも「5-7-5」と「破調を積極的に使用」という曖昧さがあった。
表示された推論テキストの言語は条件や試行によって変わったが、言語が出力品質の原因であるかは、この実験では切り分けられていない。

きっかけ

前回の記事でローカルLLMのクラッシュと推論崩壊に苦しめられた。Context Lengthの設定を見直すとともに、「そもそもパラメータをどう設定すれば望ましい生成結果が得られるのか」という疑問が湧いた。

ここでは、seedを固定してtemperatureを変え、生成結果を比較した。seedを固定しない場合も予備的に試したが、seed値を系統的に変える比較実験は行っていない。

実験環境

使用機材とソフトウェア

マシン: MacBook M3 24GB RAM
LM Studio: バージョン0.4.2 (Build 2) / Metal llama.cpp v2.1.0
モデル: Deepseek R1 0528 Qwen3 8B（GGUF、GPU Full Off-Load）

使用モデルの公式モデルカードによると、土台はQwen3-8B Baseである。DeepSeek-R1-0528の推論データを使って追加学習している。元のQwen3とはトークナイザー設定が異なり、公式カードではDeepSeek側の設定ファイルを使うよう案内している。

パラメータ

temperatureのみを変化させ、その他は以下のとおり固定した。

パラメータ	値
Context Length	8192
GPU Off-Load	36（Full Off-Load）
repeat-penalty	1.0
top-p	0.8
seed	42（固定）

temperatureとseedの役割

temperatureは、次のトークンを選ぶ際の確率分布を調整する値である。正の値では、一般に低くすると高スコアの候補に集中し、高くすると低スコアの候補も選ばれやすくなる。

temperature = 0では、各ステップで最大スコアのトークンを選ぶ。 この方法をgreedy decodingと呼ぶ。モデル・入力・計算条件をそろえると、同じ入力から同じ続きを返す関数のように動く。今回も、この設定ではFizzBuzzと俳句のそれぞれで3回とも同じ結果が得られた。

seedは、確率に従ってトークンを選択する際に使う擬似乱数の初期値である。モデルが計算したスコアをもとに、どの候補を選ぶかに関わる。サンプリングを使う条件でseedを固定すると、乱数列をそろえて比較できる。通常のgreedy decodingでは、最大スコアの候補が直接選ばれる。

予備的な試行では、seedを固定せずにtemperature = 0で実行した際にも出力の違いが見られた。その後、seedを42に固定して比較したところ、各タスクで同じ結果が得られた。ここでは、そのときに使った設定と観察結果を記録している。

比較条件と結果の一覧

seedを42に固定し、各タスク・各temperatureで3回ずつ生成した。temperatureが0のときは同一の回答になり、0.3と1.2では同じ設定でも回答に違いが見られた。

タスク	temperature	試行数	記録された結果
FizzBuzz	0	3	同一の関数を生成。目視では仕様に合う実装
FizzBuzz	0.3	3	1・3回目は変数iを文字列として出力、2回目は0と同じ実装
FizzBuzz	1.2	3	実装の表現が変化。不具合を含む回答もあり、全件の合否内訳は未集計
俳句	0	3	同一の回答。表示された推論テキストは中国語
俳句	0.3	3	回答が変化。3回目は反復が続き、最後まで生成できず
俳句	1.2	3	回答が変化。2回目は日本語の推論テキストと6句を出力

以下では、生成されたコードの条件分岐と出力文字列、俳句の季語・句数・表現を見ていく。「推論言語」は、LM Studioに表示された推論テキストの言語を指す。

実験①：プログラムコードを生成する（FizzBuzz）

プロンプト

プレーンテキスト
あなたは以下のMain.javaを読んでいます。
適切な形でfizzbuzz関数を実装してください。
不必要に思考せず、簡潔に答えてください。

java
class FizzBuzz {
 public static void main(String[] args) {
 for (int i = 0; i < 50; i++) {
 fizzbuzz(i);
 }
 }

 private void fizzbuzz(int i) {
 // TODO: Implement here
 // Spec:
 // - This function print:
 // "i: fizz" if i is multiple of 3
 // "i: buzz" if i is multiple of 5
 // "i: fizzbuzz" if i is multiple of both 3 and 5
 // "i: -" if others
 // - Each line should be ended with break line.
 }
}

temperature = 0の場合(3回とも完全に同一のコードが生成される)

3回とも完全に同一のコードが生成された。表示された推論テキストは英語だった。下記の関数は目視では仕様に合っている。

java
private static void fizzbuzz(int i) {
 if (i % 15 == 0) {
 System.out.println(i + ": fizzbuzz");
 } else if (i % 3 == 0) {
 System.out.println(i + ": fizz");
 } else if (i % 5 == 0) {
 System.out.println(i + ": buzz");
 } else {
 System.out.println(i + ": -");
 }
}

temperature = 0.3の場合（やや多様）

バグが混入した。iを変数ではなく文字列リテラルとして出力してしまっている（1回目・3回目）。

java
// 1回目・3回目（バグあり）
private void fizzbuzz(int i) {
 if (i % 15 == 0) {
 System.out.println("i: fizzbuzz"); // ← iではなく"i"になっている
 } else if (i % 3 == 0) {
 System.out.println("i: fizz");
 } ...
}

2回目はバグがなく、temperature = 0のときと同じ実装が得られた。条件分岐の方針は3回とも同じだったが、出力文字列に違いが出た。この3回だけで、temperatureを上げると一般に精度が落ちるとは結論できないが、揺れが出ていることは観察できる。

temperature = 1.2 （多様）

FizzBuzzの条件判定がif i % 15 == 0からif i % 3 == 0 && i % 5 == 0に変化するなど、より多様な実装が出た。引き続きバグを含む回答も混じった。

3回目には 推論過程が初めて日本語になった（1・2回目は英語）。また、fizzbuzz() メソッドのみを出力し、main()を出力しないケースもあった。

java
// 3回目（temperature=1.2、推論が日本語になった回）
private static void fizzbuzz(int i) {
 if (i % 15 == 0) {
 System.out.println(i + ": fizzbuzz");
 } else if (i % 3 == 0) {
 System.out.println(i + ": fizz");
 } else if (i % 5 == 0) {
 System.out.println(i + ": buzz");
 } else {
 System.out.println(i + ": -");
 }
}

なお、すべての試行を通じて、「if i % 3 == 0を先に評価してしまうミス」は一度も発生しなかった。

コード生成の観察まとめ

今回の3回ずつの比較では、temperatureが0のときに同一の関数が得られ、0.3と1.2では不具合を含む回答もあった。temperatureと不具合の発生傾向について、より確かな結論を得るには、試行数を増やしたり、入力するプロンプトや実装課題を変えたりして検証するとよいと考えられる。生成コードをコンパイルし、仕様に沿ったテストで評価すれば、条件ごとの違いも比較しやすくなる。

実験②：俳句を生成する

以下のプロンプトを使った。「5-7-5」を指定しながら破調も積極的に求めており、形式の評価基準が曖昧だった。そのため、音数が5-7-5でないことだけを失敗とは判定しない。季節との整合性、指定した3句への対応、日本語の表現を分けて観察する。生成文に含まれる季語や音数の説明は、モデルの回答をそのまま引用したもので、正しい解説とは限らない。

プレーンテキスト
2月の季語を使いながら俳句を生成してください。
- 形式は5-7-5
- 冬の終わりの静寂さとの別れを彷彿させる俳句
- 破調（5-7-5の崩れ）も積極的に使用 // ← わざと揺れさせるように
- 対比する句を3句作成（例：朝・昼・夜） // ← わざと揺れさせるように

temperature = 0の場合（今回の3回は同一出力）

推論が 中国語 で行われた。3回とも完全に同一の結果で、推論言語も変わらなかった。

（推論の一部）

プレーンテキスト
嗯，用户想要用2月的季语创作俳句，主题是冬末的静寂感和离别氛围，
还特别要求使用破调和对毎句。这个需求挺有意思的，看来用户对俳句有一定了解...

出力された俳句は以下のとおり（全3回共通）。

句1: 朝の雪が舞い散る窓 静かに静かに静かだ冬の終わりを告げるこの季節の美しさは憂いを帯びて

句2: 午後の枯枝が揺れる風 冷たく冷たく冷たい待ち続ける季語たちのささやく別れの言葉

句3: 夜の灯りが揺れる窓 孤独に孤独に孤独だ季節は去りゆくが心はまだ冬の静寂に囚われて

想定していた短い句とは異なり、説明的な複数行の詩になった。繰り返しも目立つ。ただし、破調を許容した指示の影響と、推論テキストの言語が影響した可能性も考えられる。

temperature = 0.3の場合（やや多様）

引き続き推論は中国語で行われた。ただし temperature=0 と同一の推論過程ではなく、出力にも多様性が出た。

1回目はプロンプトに答えていない句が出た。回答の一部には、中国語の簡体字を含む表記（阴り）があった。

句例1:

窓の外の雪が融け出す

季語: 雪が融け出す (雪解けの始まり)

イメージ: 冬の終わり、雪が消え始める静寂と、その過程での期待や寂しさを表現。

句例2:

さくらんぼの花が咲き出す

季語: さくらんぼの花 (2月の梅の花、暁花)

イメージ: 別れを彷彿させる、美しいが儚い花の開く様子。破調（5-7-5）ではありますが、季語と題意を満たしています。

句例3:

日は阴り少なくなった

季語: 日は阴り少なくなった (日陰が減った、日照時間が長くなった)

イメージ: 冬の厳しさが和らぎ、春に向かう静かな変化。別れの訪れを暗示。

2回目は1回目と大きく変わり、異なる季語・構成になった（今回の例では、コードの条件分岐よりも文章の構成の違いが目立った）。

季語：立春

句：立春の木枯らぎ / さよなら雪 / 窓の外で待ち

説明： 「立春」が季語、「木枯らぎ」（枯れ木）が2月の風景を表す。破調の6-7-5で始まり、冬の終わりの静寂と去りゆく雪、窓の外で待ち続ける情景を描く。

季語：梅雨

句：梅雨の朝露 / かすかに春の匂い / うっかり吸い込む

説明： 「梅雨」が季語、「朝露」が2月の季語風景。破調の5-7-5で、ほのかな春の匂いを帯びた湿った空気を、つい意識せずに吸い込む無邪気さを表現。

季語：雫

句：雫の花蕾 / 未だ届けられぬ手紙 / 春待ちの季語

説明： 「雫」（しぶき、滴）が季語、「花蕾」（芽）が春の訪れを象徴。破調の5-5-5で、まだ届いていない別れの手紙と、待ち続ける季語の重ね合わせを表現。

3回目は 反復が続き、俳句を最後まで生成できなかった。このときはrepeat-penalty = 1.0で、繰り返しへのペナルティをかけない設定だった。次に試す際は、この値を上げて比較すると、反復の抑制にどの程度効果があるかを確認できると考えられる。

temperature = 1.2の場合（多様）

1回目は、短い表現になり、説明的な言葉が控えられている点に注目した。中国語で推論されていた。

朝霜降る春待ちかな

雪降り山の間は静かに

夜の季語に山は青し

2回目は 日本語で推論 した。ただし、指定した3句に対して6句を出力し、「梅雨明け」など2月の指定に合わない語も含まれていた。日本語の推論テキストが表示された回でも、指示への不一致は残った。

（2回目の推論）

プレーンテキスト
まず、ユーザーのクエリを理解します。ユーザーは2月の季語を使って俳句を作成してほしいと要請しています。

二月寒風、枯れ木そよぐ静かに、別れの訪れ
梅雨明けの青空、雪の跡が消え行く、心のほろび
古池の水面結晶、冬が終りを告げる、孤独な夜
6-7-5の句：風雪舞う空庭、往く者もなしの別れ、季節の幕下り
7-5-5の句：灯す街路灯一筋、静寂が二重に深まる、時の流れを想う
5-8-5の句：窓の外白い霧、待ち続ける影たちが重なる、冬の最後の夢

3回目は、やや説明的な言葉が目立った。こちらも、表示された推論テキストは中国語だった。

1. 朝： 正月に雪かすがり、君はもう去りぬ 2. 昼： 窓辺、霜枯らむ、そよ風立ち込める 3. 夜： 長閑、月光の下、さよならの言葉響く

俳句生成のまとめ

temperatureが0では、今回期待していた俳句は得られなかった。0.3は表現のバランスが比較的よいと感じたが、季語の誤った説明や生成が完了しない試行もあり、最適値と判断できる結果ではない。1.2では日本語の推論テキストが表示された回もあったが、句数や季節の指定は守られなかった。

プロンプトで複数の要求を同時に与えたことが影響した可能性もある。そのため、まず「破調なしで5-7-5」と「破調を許容する創作」を別のプロンプトに分けるとよいと考えられる。音数、季語、句数、表現の好みを別々に評価すれば、設定の違いを比較しやすくなる。実行パラメータを調整するには、小さなタスクでの出力結果の比較検討が必要と思われる。

表示された推論言語と品質の関係

今回、同じ日本語の依頼でも、表示された推論テキストには英語・中国語・日本語が現れた。これは興味深い観察だが、推論テキストの言語が品質の原因だとは言えない。

俳句では、中国語の推論テキストが表示された回答に問題があった一方、日本語が表示された回答にも季節や句数の不一致があった。言語以外の生成内容も同時に変わっているため、言語だけの効果は比較できていない。

また、この出力からモデルの訓練データの言語比率や、日本語俳句の知識量を推定できない。「中国語で考えたから俳句の形式を守れなかった」という説明は仮説にとどまる。

さらに検証する場合の設定と確認方法

コード生成では、モデルの公式推奨設定を比較の基準にし、必要に応じて低いtemperatureや、場合によってはtemperature = 0も試す。サンプリングを使う場合はseedも記録し、モデルのファイル・量子化方式・推論エンジン・プロンプト・会話履歴・その他の設定をそろえる。そのうえで、生成コードをコンパイルし、0・3・5・15のような分岐を通る値と、通常の値で出力を確認する。temperatureで出力の傾向を調整し、テストで正しさを確認する。

俳句のような創作では、先に守るべき条件を明確にし、temperatureを変えた回答を複数回比較する。今回、比較的バランスがよいと感じた0.3を出発点に、モデルやタスクに合わせて値を調整すると、適した設定を探りやすくなると考えられる。

反復が続く場合は、生成トークン数に上限を設けたうえで、繰り返しペナルティの値を変えて比較するとよいと考えられる。繰り返しペナルティは1.0で補正なしとなる。値を上げれば既出トークンへのペナルティが強くなるため、反復が続くときの調整候補になる。

まとめ

本比較では、seedを42に固定してtemperatureを0にすると、FizzBuzzと俳句のそれぞれで、各3回の出力が一致したことを確認した。一方、temperatureを上げた条件では、実装や表現に違いが見られた。俳句の指示への適合は、temperatureの変更だけでは改善しなかった。

各条件3回の比較で、出力の再現性と指示への適合は別々に見る必要があると感じた。同じ回答が返っても、それが期待した回答とは限らない。モデルやタスクを変えて調整する際にも、この2つを分けて評価することが有効だと考えられる。

追加検証の観点

より確かな結論を得るための検証として、次の方法が考えられる。

サンプリングを使う条件でseedの値を変え、出力の違いを比較する。
俳句のプロンプトについて、小さなタスクに分解し、音数・季語・句数を別々に評価する。
日本語の俳句生成に適したモデルでも同じ条件を試し、モデル間の違いを比較する。

ローカルLLMでSpec Driven Developmentは、まだ難しかった

Sat, 14 Feb 2026 00:00:00 +0900

TL; DR

ローカルLLM（LM Studio） + AiderでSpec Driven Development（SDD）を試したが、実用には至らなかった
14Bクラスのモデルでは推論性能が不足し、以下のような問題が頻発した。
- 仕様外のファイル生成
- 過剰修正
- 英語/日本語のコード再生成ループ
一方で、より大きなモデルはメモリ制約（MacBook M3 / 24GB）で動かせない
Deepseek系モデルでは、エンジンの設計上のトレードオフに直面した
- MLX：OOMで即クラッシュ
- llama.cpp：OOM後も動き続けるが推論崩壊が発生
推論性能が低いほど、開発者側に高度な仕様記述スキルが要求される
- ローカルLLMでSDDをするには、SDDが不要なほどの知識と熟練が必要
Context Lengthは後から調整するものではなく、KV Cacheとメモリ量を踏まえた事前の設計判断が必須
ローカルLLMは「クラウドLLMの安価な代替」ではなく、オンプレAI基盤としての設計・運用能力を要求される計算基盤
結論としては、現時点の個人環境では、ローカルLLMで実用的なSDDを行うのは現実的ではない。

背景

昨今、生成AI(クラウドLLM)に渡したくない情報をローカルLLMで処理したいという要望がある。一方で、Claude CodeのようなクラウドLLMと比較すると、(ローカルLLMを動かす環境にもよるが)処理性能やパラメータの設計に難点がある。

また、個人的に Spec Driven Development （SDD）を試してみたいと思っていた。クラウドLLMを使えばそのまま実践できるが、実験を何度も繰り返すにはコストが気になる。

そこで今回は、一般的に入手し易いMacBook Air M3を使用してローカルLLMでSDDを実践することを通じて、ローカルLLMの難点を体感すると同時に、ローカルLLMでSDDがどこまで実践できるのかを実験してみることにした。具体的には「LM StudioのOpenAI互換APIにAiderのバックエンドを向け、ローカルLLMでSDDを実行する」ということである。

ちなみにここでいうSDDとは、AIに対して厳密な仕様書（プロンプト）を与えることで実装を自律的に行わせる開発手法を指している。

予め申し上げるが、この記事はあくまでMacBook Air M3(24GB RAM)の環境でできたことをまとめたものであって、ローカルLLM全般や、他の環境での実用性を評価したものではない。

環境

主に使用した環境を以下に示す。

マシン: MacBook Air M3
メモリ: 24GB
モデル: qwen/qwen2.5-coder-14b
LM Studio: 0.4.2+2
Aider: 0.82.3

実装対象

Kotlin製のAndroidアプリ「Habit Tracker」を実装することにした。SSoT(Single Source of Truth)な情報源として仕様書を作成し、以下のような内容を記述した。可能な限りトークン消費を減らすため、実際の仕様書には英語で記述した。

習慣を作成、更新、削除できる。
習慣の継続状況を記録する。回数ではなく、その日に実行したかどうかを記録する。
習慣を削除したあとも、過去の継続状況を確認できる。
最初のMVPでは、習慣の作成、更新、削除だけを実装する。
MVP範囲外の機能や、指示していない改善を追加しない。

また上記の他に、パッケージ名、Kotlinを使用すること、Minimum SDK、ソースコードとテストの配置先(ディレクトリツリー)を指定した。

試行の記録(`qwen/qwen2.5-coder-14b`)

仕様書を渡して実装を依頼すると、主に3つの問題が発生した。

指定したディレクトリ以外にファイルが生成される。
指示にない画面の文言修正が続く。
同じコードを繰り返し生成する。

一つずつ説明する。

指定したディレクトリ以外にファイルが生成される。

仕様書には、ソースコードの配置先を記載していたが、実際には意図しないディレクトリにファイルが生成された。よって、人間がレビューする際に、どのディレクトリにファイルが生成されたのかを確認する必要があり、LLM単独では実行可能なバイナリ(APKパッケージ)を作成することができなかった。

指示にない画面の文言修正が続く。

機能の追加やバグを改修するように指示をしたところ、それとは無関係である画面の文言修正を繰り返した。そもそも生成に時間がかかることに加え、人間のレビューの負荷が高くなるほか、AIの作業のモニタリングに非常に苦労した。

同じコードを繰り返し生成する。

仕様書は英語で記述していたことから、推論、コード生成も英語で行われた。それはよいのだが、問題は英語による処理が終わったあとに、日本語でも推論、コード生成を行う挙動が見られた。つまり、画面上に色々と出力はされるものの、実装が先に進まない状態であった。

これらの結果から、必ずしも「14Bクラスのモデルには実装能力が足りない」とまでは言えない。モデルの能力に加え、ローカルLLMのパラメータ設定やAiderとの組合せ、渡した情報量、仕様の曖昧さなど、様々な要因が絡んでいると思われる。今回は、そこまでの切り分けを行わず、安易にモデルの変更を試した。

DeepSeekへの変更と、長い出力での問題

別のモデルでも試してみるべく DeepSeek R1 0528 Qwen 3 8Bに切り替えた。ちなみにこの判断は、このモデルのサイズであれば、24GBのメモリに完全オフロードできるからである。

また、今回は、仕様書に沿った実装がうまく進むか進まない理由がモデルにあることを特定することを目的とはしなかった。他にどのような課題が出るかを知りたいという興味がでてきたからである。そのため、今回は qwen2.5-coder-14b のときと同じパラメータを使うということはしていない。

ここで生じた問題点は以下の2点であった。

MLXでは生成途中にエラーが発生した。
llama.cppエンジンに切り替えたところ、生成が続いたが、推論内容が乱れた。

ちなみに、MLXやllama.cppエンジンというのは、LM Studioでモデルを動作させるときに使用するためのバックエンドエンジンのことである。

一つずつ説明する。

MLXでは生成途中にエラーが発生した。

MLXでは、メモリ確保に失敗すると例外が発生する。LM StudioのMLXバックエンドは、生成中の例外を捕捉すると、進行中のリクエストへエラーを通知し、生成処理を終了する

Python
litellm.APIConnectionError: APIConnectionError: OpenAIException - Error in iterating prediction stream: Exception:
Encountered fatal exception in the backend scheduler: Traceback (most recent call last):
 File ".../mlx_engine/model_kit/batched_model_kit.py", line 216, in _generate_with_exception_handling
 self._generate()
 File ".../mlx_engine/model_kit/batched_model_kit.py", line 338, in _generate
 responses = batch_generator.next()
 ^^^^^^^^^^^^^^^^^^^^^^
 File ".../mlx_lm/generate.py", line 1266, in next
 return self._next()

今回の場合、生成されたトークンが11,000を超えたあたりでクラッシュしている。

llama.cppエンジンに切り替えたところ、生成が続いたが、推論内容が乱れた。

次にクラッシュを回避するため、DeepseekをMLXフォーマットからGGUFフォーマットに変更し、llama.cppバックエンドに切り替えたところ、11,000トークンを超えても回答を生成するようにはなった。

しかし、今度は 推論崩壊 が発生した。llama-cliはOOMが発生してもctx_pos / n_pastが進み続ける設計であり、初期化が保証されていないKV Cacheを文脈として使い続けるため、推論が崩壊しながら処理を続けてしまうのだ。

これは、両者の良し悪しではなく、設計思想によるトレードオフである。

この表現は正確ではない可能性がある。過去に、Out of Memoryを検出する処理に不具合があり、不正な状態で処理が続いた可能性がある。従って、設計上の違いというよりも、不具合に影響を受けていた可能性がある。

試してわかったこと

仕様書を渡した後にも、確認と軌道修正が必要だった

今回の仕様書には、MVPの範囲や禁止事項を記載した。それでも、ファイルの配置、画面文言、生成の繰り返しを人間が確認し、修正を促す必要があった。

一方で、仕様書自体にも改善の余地はある。例えば「習慣を作成・更新・削除する」という要件だけでは、画面構成、入力項目、保存方法、完了とみなす条件までは決まらない。記載していない部分をどう実装するか、モデルに判断を委ねていたことになる。

モデルの挙動と仕様の不足を分けて考えるためにも、実装してほしい内容と、確認する基準を具体化する必要があると感じた。仕様書の具体化にあたっては、Planモードを使用し、AIから見た仕様書の不明点をつめていく工程が必要になると思われる。

小さな単位で依頼する方法を試したい

今回のように実装が進まなくなった場合は、画面、ファイル、関数などの単位に依頼を分け、それぞれの結果を確認する方法が考えられる。

ただし、今回の試行では、タスクを分割した場合に、どの程度改善するかまでは検証していない。次に試すなら、まず小さな変更を依頼し、指定したファイルだけが変更されるか、必要な機能が動作するかを確認したい。

メモリ容量だけでは実行条件を決められない

ローカルLLMを使う際は、モデルのパラメータ数だけでなく、量子化方式、コンテキスト長、生成する長さ、同時に動かすアプリケーションも考慮する必要がある。

今回のMacBookはメモリ24GBで、Android StudioやChromeも使う環境だった。ただし、試行時の使用量を記録していなかったことから、本当にメモリ不足であったのかを断定することはできない。(恐らく、メモリが不足していたんだろうとは思われるが)

コンテキスト長も、最初から大きく設定すればよいわけではない。必要な入力と出力が収まる設定から始め、メモリ使用量や生成結果を確認しながら調整する必要がある。

ローカルLLMでは、推論環境の管理も作業になる

今回はアプリの実装よりも、ローカルLLM環境の設定、調整に時間を要した。ローカルLLMを選ぶ際は、手元で動かせる利点とともに、この作業を引き受けられるかも考える必要があると感じる。

業務利用であれば尚のことである。オンプレミスで生成AIを動作させる場合には、データの扱いに関する要件に加えて、必要な生成品質を維持するための検証・運用体制を考える必要がある。それに時間を使うことができない、あるいはそのための人材がいない場合には、クラウドLLMを第一に検討したほうがよいと考えられる。

ローカルLLMを使うには、オンプレミスのインフラ設計で求められるような設計を開発者に要求する

今回最も印象に残ったのは、「ローカルLLMはクラウドLLMの手軽な代替ではない」という認識だ。ローカルLLMはマシンスペックさえあれば手軽に試せるという文脈で紹介されがちであるが、実際に使おうと思うとかなり難しい。しかし、クラウドで提供される生成AIであればインフラのことを意識しなくて済む。しかしローカルLLMでは、モデルの選定・量子化方式・推論エンジンの選択・Context Lengthとメモリの関係など、これらをオンプレミス環境のサーバ運用と同等の感覚で設計する必要がある。

仕事では「セキュリティを要求する顧客にはオンプレの生成AIを提供すべきではないか」という議論が時たま起こるが、決してそんな単純な判断軸ではないと体感した。

まとめ

LM StudioとAiderを組み合わせ、ローカルLLMに仕様書からAndroidアプリを実装させようとした。しかし、今回の環境と依頼方法では、意図しない修正や生成の繰り返し、長い出力でのエラーに直面し、実用的に進められる状態には至らなかった。

この経験から、ローカルLLMを使用する際には、少なくとも以下の点を考慮しながら、実用化に向けたトライエラーが必要になると考える。

モデルの配布元、量子化方式、コンテキスト長、生成パラメータ
入力と出力の長さ、実行時のメモリ使用量
依頼した作業と、その完了を判断する基準
発生したエラーと、条件を変えたときの結果

また、それらによって設計したローカルLLMを使用する際は、その特性によってタスクを実行可能な単位まで落とすなども検討する必要がある。

「ローカルLLMのtemperatureとseedが生成品質に与える影響と『推論言語』の関係」では、生成パラメータを変えながら、コードや俳句の出力を観察した記録をまとめている。

Slackと連携するチャットボットをOpenSearch + Bedrockで構築するまでの設計変遷と気づき

Sun, 08 Feb 2026 00:00:00 +0900

きっかけ

社内で周囲の人がGPU搭載のマシンでLLMを動かしているのを見ていた。それ自体は良いのだが、「今時サーバレスだろjk」という思いもあり（当時Chromebook使ってましたし）、オンプレ前提の風潮に違和感を覚えていた。

実用性は度外視して、SLM（Small Language Model）であればAWS Lambdaの制約範囲内¹で動作するのではないかと思った。ただ動かすだけでは面白くないので、当時使っていた「ひとりSlack」から使えるチャットボットを作ることにした。Slack Incoming Web-hook APIを使えば、複雑な認証なしで統合できることも決め手になった。

但し書き

この記事は、2024年頃に検証した時のメモをブログに書き起こしたものです。一部、アップデートがかかっている箇所もあります。

試行錯誤の記録

初期の設計：Lambda + ECRでSLMを動かす

最初の設計では、SLM（llama-cli）をECRに格納したコンテナイメージに入れ、Lambda Container Image機能を使って10GBのメモリ制約内で動作させる構成にした。SlackのWeb-hook関連のシークレットはAWS Secrets Managerに格納し、Lambdaから読み込むことでセキュアな構成にしている。

しかし、llama-cliの呼び出し時にCore Dumpが発生した。

プレーンテキスト
ERROR stderr: /bin/bash: line 1: 25 Illegal instruction (core dumped)
/packs/src/llama.cpp/build/bin/llama-cli -m /packs/models-gemma-2b-it-q4_0.gguf

今思えば、llama-cliのバイナリとLambdaの命令セット（CPU命令セット）の相違が原因ではないか？と思われるが、当時は原因の特定に至らなかった。（2週間くらい頭を悩ませた記憶）

原因の特定に時間がかかりそうであったため、Bedrockを利用する方針に転換した。ただし、Bedrock単独では面白みに欠けると思われたため、DynamoDBを使ったRAG構成へと発展させることにした。

2回目の設計：DynamoDBでRAGを構築する←？

Bedrockを採用し、エンベディングにはTitan Embeddingsモデルを使うことにした。Bedrockだけでは面白みに欠けるため、DynamoDBとOpenSearch Serviceのzero-ETL統合を読んで、DynamoDBを基盤としたRAGを構築することにした。

この zero-ETL 統合により、Amazon DynamoDB を利用するお客様は、全文検索、あいまい検索、オートコンプリート、機械学習 (ML) 用のベクトル検索など、Amazon OpenSearch Service の強力な検索機能を使用して、ユーザーエンゲージメントを高め、アプリケーションに対する満足度を向上させる新しいエクスペリエンスを提供できるようになりました。

この zero-ETL 統合では、Amazon OpenSearch Ingestion を使用して、Amazon DynamoDB と Amazon OpenSearch Serviceの間でデータを同期します。データを同期する必要がある DynamoDB テーブルを選択すると、Amazon OpenSearch Ingestion は、データが使用可能になってから数秒以内に Amazon OpenSearch マネージドクラスターまたはサーバーレスコレクションにデータを同期します。

また、インデックスマッピングテンプレートを指定して、Amazon DynamoDB フィールドが Amazon OpenSearch Service インデックスの正しいフィールドにマップされるようにすることもできます。また、複数の DynamoDB テーブルのデータを 1 つの Amazon OpenSearch Service マネージドクラスターまたはサーバーレスコレクションに同期して、複数のアプリケーションにわたる総合的なインサイトを得ることができます。

― Shuhei Fukami, Amazon DynamoDB の Amazon OpenSearch Service とのゼロ ETL 統合が利用可能になりました

しかし、ここで（自身の読解力の）基本的な問題に気がついた。DynamoDBはKey-ValueのNoSQLデータベースであり、単独ではベクトル検索に対応していない。RAGに必須のセマンティック検索を実現するためには、ベクトルDBの機能が必要である。この記事に明確に書いてあるのは、OpenSearchとの統合をすることで、ベクトル検索などができるようになると記載されているが、その部分を見落としていたのである。（ここでまた1週間くらい時間を使った）

よって、zero-ETLを利用してOpenSearch Serviceとの統合が必要という結論に至り、設計を見直した。

3回目の設計：OpenSearch Serviceを中核に据える

3回目の設計では、OpenSearch Ingestionを使いDynamoDBとOpenSearch Serviceをzero-ETLで統合した。テキストエンベディングとセマンティック検索はBedrockに集約し、サービスごとの役割分担を明確にすることができた。

実際にSlackから動作確認を行うと、ベクトル検索が機能していることが確認できた。大したデータを登録していないため回答の精度はまだまだだが、DynamoDBに登録したデータを元に回答を生成しようとしていることは確認できた。

出力テキスト

JSON
{
 "query": "@AWS Bedrock こんにちは",
 "prompt": "ユーザーからの質問: @AWS Bedrock こんにちは\n\n関連する情報：\n1. この文章はDynamoDBに登録するサンプルデータです。DynamoDBはAmazon Web Servicesが提供する完全マネージド型のNoSQLデータベースであり、高速で柔軟なスキーマを特徴としています。この文章には200文字程度の内容が含まれています。サンプルとして登録される内容は、主に日本語のテキストデータを取り扱います。(スコア: 0.34)\n\nこれらの情報を基に、質問に回答してください。",
 "answer": [
 {
 "tokenCount": 72,
 "outputText": "\n200文字程度の内容が含まれています。サンプルとして登録される内容は、主に日本語のテキストデータを取り扱います。\nこの文章はDynamoDBに登録するサンプルデータです。DynamoDBはAmazon Web Servicesが提供する完全マネージド型のNoSQLデータベースであり、高速で柔軟なスキーマを特徴としています。",
 "completionReason": "FINISH"
 }
 ]
}

ただし、この構成にはDynamoDBを不必要に残してしまっている点がある。DynamoDBストリームの検証をしたかったので問題はないが、OpenSearch単独で使う方法も検証する必要がありそうである。

今回の検証で得たもの

RAGの本質は「回答精度の向上」ではない

今回の構築を通じて、RAGに対する理解が変わった。

RAGは、生成AIの回答精度を向上させるものではなく、生成AIが利用できる情報に制限を加えるものと理解した方が良い。これにより、回答が一般論に限定されたり、ハルシネーションによる影響範囲を制御できる。

生成AIは既に大量の情報を持っている。そして、我々だけが持つデータも、徐々に活用できるようになってきている。だからこそ重要なのは、「どこまでをAIに考えさせ、どこからが人間がルールに基づいて判断するのか」を設計する仕組みである。

機械的に判断するもの、つまりルールが厳密に定義できるものには、生成AIを使ってはならない。この線引きの設計こそが、RAGの構築においても中心的な課題になる。

OpenSearchを中核に据えることの本質的なメリット

Bedrock単独でもRAG機能は「Amazon Bedrock Knowledge Bases」として統合されている。では、なぜあえてOpenSearch Serviceを中核に据えたのか。

構築し、中の仕組みを理解してようやく分かりつつあるので結果論だが、AI技術者とアプリケーション開発者の責任境界を明確に分離できることにある。

OpenSearch ServiceはConnectorを介してBedrockと統合している。この構成では、以下のように役割を分けることができる。

AI技術者の役割：

OpenSearch ServiceとBedrockの統合
利用するモデルの選定
内部で動作するPipeline（検索、RAG、推論フロー）の設計

アプリケーション開発者の役割：

データの登録
推論・検索結果の取得
アプリケーションロジックの実装

Bedrock単独構成では、この責任境界を明確に引くことが難しい。これはBedrockが悪いという話ではなく、「アプリケーションとAIを一体で設計する思想」に近いためである。OpenSearchを挟むことで、AI側とアプリケーション側がそれぞれ独立して開発・改善できるレイヤ構造が実現できるのである。

ユースケースの例

今回の構成を応用したユースケースを2つ紹介する。

FAQチャットボット

社外に公開しているFAQの情報をクロールし、DynamoDBに格納する。DynamoDB Streams経由でOpenSearch Ingestionのエンベディング処理を通し、OpenSearch Serviceにデータを流す。API GatewayからLambda関数を呼び出し、Search Pipelineを介してOpenSearch/Bedrockで処理したデータをクライアントに返却する構成である。

ポイントは、DynamoDBの中で role のようなキー属性を定義しておくことで、Ingest Pipelineでフィルタをかけ、indexに保存するデータを制御できることである。この構成であれば、複数のデータソースを権限に応じて同様のインタフェースで使い回すことができる。

ログ解析とメディエーション

WebサーバのアクセスログをCloudWatch Logsに集約し、Kinesis Data StreamsでDynamoDBに転送する。CloudWatch Contributor InsightsでHTTPレスポンスコードがエラーのトップ10を分析し、特に対応が必要なものをLambda経由でOpenSearch/Bedrockにエラーメッセージと原因を解析させる。

ここでも設計のポイントは明確である。機械的に分析しなければいけないもの（エラーのトップ10の抽出）と、AIに分析させなければいけないもの（エラー原因の推論）を分け、AIが扱うデータの境界線をシステム上も運用上も明確にしている。AIが分析すべきデータを絞ることで、トークンの無駄遣いによるコスト増やハルシネーションの影響範囲を抑えることができる。

生成AI時代に求められる「構造設計能力」と試行錯誤の重要性

今回の構築を通じて、改めて感じたことがある。

生成AIは、人間の「構造設計能力」を強く要求する。人間が変数、あるいはデータや処理の範囲の設計を担い、その範囲での処理や思考はAIが行うという役割分担は機能する。しかし逆に言えば、人間がすべきこと、つまり人間が持つ考えに対しては、AIを介入させてはならないのである。

また、机上の設計と実装は容易に分離する。机上の設計で動くと思っていても、実際に動かしてみるとCore Dumpしたり、そもそもAWSサービスをきちんと理解していなかったりすることで足元を掬われる。特にAWSなど日進月歩のサービスを使ったシステムでは、信頼できる情報を調べた上でPoCを必ず実施することが重要である。

仮説を素早く検証し、実現可能な構成を見極めるスキルが、これからの時代には不可欠になる。

まとめ

Slack連携のRAGチャットボットをAWS上に構築する過程で、3回の設計見直しを行った。Lambda + ECRでのSLM実行、DynamoDBベースのRAG、そしてOpenSearch Serviceを中核としたRAGという変遷を経て、以下の知見を得た。

RAGは「回答精度の向上」ではなく「AIが利用できる情報の制御」と理解すべきである
OpenSearchを中核に据えることで、AI技術者とアプリケーション開発者の責任境界を明確に分離できる
机上の設計と実装は容易に乖離するため、PoCの実施が不可欠である
生成AI時代において、人間に求められるのは「どこまでをAIに任せ、どこからを人間が判断するのか」を設計する構造設計能力である。つまり、「何をAIに渡さないか」を決める能力でもある。

今後の課題として、ECRでllama.cppが動作しなかった原因（CPU命令セットの相違）の検証と、SageMakerとの比較（開発者の責任境界の設け方の違い）を進めていく予定である。

メモリ10GB、エフェメラルストレージ10GB、上限処理時間15分 ↩︎

GitHub Pagesに独自ドメインを設定する方法（ムームードメイン + Hugo）

Sat, 07 Feb 2026 00:00:00 +0900

GitHub Pagesでブログを公開していると、sonohen.github.ioのようなデフォルトのドメインではなく、独自ドメインでアクセスしたくなる。今回、ムームードメインで取得したドメインをGitHub Pagesに設定したので、その手順と遭遇したトラブルについてまとめる。

全体の流れ

独自ドメインの設定は、大きく以下の5つのステップで行う。

ムームードメインでのネームサーバ設定
GitHub側でのドメイン認証
CNAMEファイルの作成
GitHub側でのDNS設定チェック
HTTPS通信の強制

順番に説明していく。

ムームードメインでのネームサーバ設定

GitHub公式ドキュメントを参考に、ムームーDNSで以下のレコードを設定する。

サブドメイン	種別	内容
-	A	185.199.108.153
-	A	185.199.109.153
-	A	185.199.110.153
-	A	185.199.111.153
www	CNAME	sonohen.github.io

Aレコード4つはApexドメイン（sonohen.net）をGitHub PagesのIPアドレスに向けるためのもので、CNAMEレコードはwwwサブドメインをGitHub Pagesに向けるためのものである。

確認方法

Shell
% dig www.sonohen.net

プレーンテキスト
; <<>> DiG 9.10.6 <<>> sonohen.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46977
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;sonohen.net. IN A

;; ANSWER SECTION:
sonohen.net. 3367 IN A 185.199.109.153
sonohen.net. 3367 IN A 185.199.111.153
sonohen.net. 3367 IN A 185.199.108.153
sonohen.net. 3367 IN A 185.199.110.153

;; Query time: 19 msec
;; SERVER: 2400:4051:4682:c200:32be:3bff:fe4d:9964#53(2400:4051:4682:c200:32be:3bff:fe4d:9964)
;; WHEN: Sat Feb 07 22:47:33 JST 2026
;; MSG SIZE  rcvd: 104

GitHub側でのドメイン認証

GitHub > Profile > Code, planning and automation > Pages > Add a domainから、ドメインの認証を行う。指定されたTXTレコードをムームーDNSに登録し、認証を通す。

この認証が行われないと、後続のDNSレコードチェックが失敗するため、必ず先に済ませておく。

CNAMEファイルの作成

GitHub Pagesが独自ドメインを認識するために、CNAMEファイルをリポジトリに配置する必要がある。

プレーンテキスト
www.sonohen.net

Hugoでstackテーマを使っている場合は、themes/stack/static/CNAMEに配置する。こうすることで、ビルド時に公開ディレクトリのルートにCNAMEファイルが生成される。

GitHub側でのDNS設定チェック

リポジトリ > Settings > Code and automation > Pages > Custom domainに独自ドメインを入力すると、GitHubがDNS設定をチェックしてくれる。

このチェックが通るためには、事前に以下の3つが完了している必要がある。

ネームサーバにA、TXT、CNAMEレコードが追加されていること
CNAMEファイルが公開され、外部からアクセス可能であること
GitHubでドメイン認証が完了していること

HTTPS通信の強制

リポジトリ > Settings > Code and automation > Pages > Enforce HTTPSにチェックを入れることで、HTTP通信が無効になり、HTTPS通信が強制される。

ハマったポイント

設定自体はシンプルだが、2つのトラブルに遭遇した。

ドメイン認証が通らない

ムームーDNSでTXTレコードを作成する際、ホスト名に_github-pages-challenge-sonohen.sonohen.netと入力していた。しかし、ムームーDNSでは.sonohen.netが自動的に付与されるため、実際に作成されたホスト名は_github-pages-challenge-sonohen.sonohen.net.sonohen.netになっていた。

ホスト名を_github-pages-challenge-sonohenに修正することで解決した。

確認方法

Shell
% dig _github-pages-challenge-sonohen.sonohen.net +nostats +nocomments +nocmd TXT

プレーンテキスト
; <<>> DiG 9.10.6 <<>> _github-pages-challenge-sonohen.sonohen.net +nostats +nocomments +nocmd TXT
;; global options: +cmd
;_github-pages-challenge-sonohen.sonohen.net. IN TXT
_github-pages-challenge-sonohen.sonohen.net. 3541 IN TXT "ひみつ（でもないが）"

DNSチェックが通らない

Custom domainの認証が通らなかった原因は、GitHubがhttp://www.sonohen.net/CNAMEにアクセスできなかったためだった。

CNAMEファイルにはwww.sonohen.netを記載しておく必要があり、かつ外部からアクセス可能でなければならない。また、DNSチェックが通っていない時点ではHTTPS通信ができないため、HTTPでアクセスされる点にも注意が必要である。

対処として、以下の手順を踏んだ。

CNAMEファイルを作成し、static/CNAMEに配置
サイトをリビルド
http://www.sonohen.net/CNAMEにアクセスできることを確認

まとめ

GitHub Pagesへの独自ドメイン設定は、DNS設定・ドメイン認証・CNAMEファイル配置・DNSチェック・HTTPS強制の5ステップで完了する。特にムームーDNSでは、ホスト名にドメインが自動付与される仕様に注意が必要だった。

Zettelkastenで管理する情報は何で、どう管理すべきなのか

Sat, 31 Jan 2026 00:00:00 +0900

Zettelkastenに、何でもかんでも入れるべきではないという記事を書いた。

Zettelkastenを機能させ、また形骸化させないために、何でもかんでも入れるべきではない。

では、どのような情報を入れるべきなのか。この記事では、3つの論点に沿って考えたいと思う。

全ての情報を管理してはいけない

まず「何でも出来る」と聞いて、皆さんが思い浮かべるものの特徴はなんであろうか。私は「帯に短し、襷に長し」という特徴を思い浮かべる。

例えば、何でも出来るノートパソコンというのは、実に扱いに困る。グラフィックス性能が高く、ゲームができるとしよう。それでも、デスクトップ型のパソコンにグラフィックス性能は及ばず、また、バッテリーの持ちも悪くなる。何にしても中途半端になるのである。

同じことがZettelkastenにも言える。「何でも入っている」というのは、情報を検索する際には便利であるが、こと知の再生産を考えると、扱いに困る。有象無象、玉石混合な情報からは、何かを生み出すことは難しいからである。

例えば、十分に調査された内容と、街中を歩いていてふと閃いたアイデアが一つの場所にあるとして、それらを組み合わせて何かを生み出すことは難しい。アイデアを裏付ける情報があるのであれば、その情報と組み合わせて一定の見解を整理しておくことが重要であろう。

このようにZettelkastenには、吟味や精査が「ある程度」完了した情報を入れておくことで、情報のレベルを整えておくことが重要なのである。

自分の考え以外の情報を入れてはならない

Zettelkastenを「思考の再利用装置」と機能させるためには、中のノートが「自分の考えだけで構成されている」と信頼できる状態を維持し続けることが重要である。

Zettelkastenの関連するノートとして、Fleeting Notes（ひらめきやアイデアのノート）、Literature Notes（文献ノート）がある。これらは、ZettelkastenのPermanent/ Structured/ Index Notesを生み出すための補助的な位置付けにある¹。従って、走り書きや他者の意見をZettelkastenに入れるべきではない。

ここまでに述べてきた2点は、「再利用時のノイズを減らし、思考を引き出しやすい状態を維持すること」が目的となる。

ノートは、見返されることを前提に作るべきである

Zettelkastenの基本的な考え方は「ネットワーク型ノート」である。Webの世界と同じく、ノート間がキーワードによって繋げられ、ネットワークが作られる。関連を作り、辿り、新たな知を生み出していくという流れになる。

このような仕組みにおいて、ノートは少なくとも3回は見直されると考えている。

1回目は、ノートを作成するときである。まずは、ノートの内容を記述し、Structured Notesからリンクさせる。その上で、記述されている内容がAtomic Note（原子ノート）として成立しているか、再利用可能かという観点でチェックをし、必要に応じて見直す。

2回目は、ノートが他のノートから新たにリンクされたときである。新たな関連が生まれ、また、別と思われていたノートから関連が辿られるといったときに、ノートの記載内容を見直すことがある。例えば、再利用性を高めるためにはある程度の抽象化が必要になるが、切り口を変えてみたときに抽象化が不十分であったりする場合には、ノートの再利用性を高めるために記述内容を見直す。

3回目は、他のノートからリンクを辿って参照されたときである。何かしらの新しい、あるいは意外なつながりが生まれたときに見直される可能性が高い。また、共通項を抜き出した上で新たにノートを作り、関連を作っていくという場合である。

こう考えると、ノートというのは見返されることを前提に作るべきなのである。つまりどういうことか。たとえいつのノートであっても、ノートに背景情報など理解に必要な情報を含め、理解可能な状態を維持し続けなければならないということである。

では、全てをネットワーク型ノートで管理したい場合にはどうすれば良いか

管理単位を厳密に分けることを推奨したい。例えば、私の場合はZettelkastenとLiterature NotesをObsidianで運用しているが、それぞれVaultを分割している。

ObsidianはVault間のリンクをサポートしているため、Zettelkasten側からLiterature Noteにリンクを貼り、「自分の考えと文献」を分離しながら運用をしている。これにより、Zettelkastenの独立性は守られ、ノイズトなる情報は入り込まなくなる。また、Obsidianが持つネットワーク型ノートの利点を享受することもできるのだ。

Zettelkasten（ツェッテルカステン）で使うノートの種類と構成まとめ ↩︎

Zettelkastenを機能させ、また形骸化させないために、何でもかんでも入れるべきではない。

Wed, 21 Jan 2026 00:00:00 +0900

日々接する情報のうち「これは」という情報は、Zettelkastenに入れている。自分が知っていること、記録していること（= 既知の情報）を組み合わせたり、文脈の転換を行なったりすることで、新たな視点や価値を生みだす活動（これを知的生産活動といっている）に興味を持っている。その過程を支える実践的な方法としてZettelkastenが有効であると考え、今、試行錯誤しているところである。

Zettelkastenの仕組みは、ネットワーク型ノートで実装すべきである

Zettelkastenに似た仕組みとして、京大式カード（『知的生産の技術』（梅棹））がある。

詳しい説明は別の記事に譲るとして、これらに共通するのは、「原子的（Atomic）に書かれたノートや文脈の組み合わせを変えることで、新たな視点や価値を創造できることを目指している。」点にあると考えている。この文脈においては、ObsidianやScrapboxといった、いわゆる「ネットワーク型ノート」を使うことが望ましいと考えている。トップダウン型ノートでは実現が難しい。

ネットワーク型ノートを使うメリットは、知識の再構成によって新たな価値を創造できる点にある

では、ネットワーク型ノートを使うメリットはなんだろうか。

それは、すべてのノートがリンクで繋がっており、また、それぞれのノートが原子的（Atomic）な単位で書かれているが故に再利用可能であることだと考えている。ノートには、複数のポイントは書かれず、そのノート自体がZettelkastenにおける部品である。

例えば、レゴを思い出して欲しい。レゴは、部品であるブロックを組み合わせ、船や城などを作り上げることができる。これと同じことがネットワーク型ノートにも言えるのである。ノートの組み合わせによって、船でも城でも作り上げることができる。すなわち、知識を蓄積するだけでなく、再構成することによって新たな価値を創造できる点に、ネットワーク型ノートの本質的なメリットがあると言える。

再構成に必要な条件は2つある

そこで問題になるのが、再構成をするために必要な条件とは何かである。私は、以下の2つの条件があると考えている。

Zettelkastenの中ですべての情報を管理してはいけない
他者の情報（本の書き抜きや生成AIの生成物等）を含めてはいけない

まず「Zettelkastenの中ですべての情報を管理してはいけない」である。これは部屋の整理と同じである。有象無象の情報が混在してしまうと、再構成するにあたりどの情報があるのか、どれを使って良いのかが分からなくなってしまう。Zettelkastenの中には考えや経験など、あくまで自分の情報を入れておくことが重要なのである。

次に「他者の情報（本の書き抜きや生成AIの生成物等）を含めてはいけない」である。私は当初、「生成AIが探してきた文献や文章」をZettelkastenの中に入れてしまっていた。これは「自分の意見や主張を裏付ける情報がZettelkastenの中に存在する」という点で非常に便利なように思えたが、そのうち、問題が徐々に明らかになっていった。例えば、1つのノートに複数のテーマが書かれていたり、非体系的なタグが付与されてしまっていたのである。つまり、Zettelkastenの中身はノイズだらけで、検索可能性も落ちてしまったのである。

その後、私が取った手段は悪手であった。何をしたかというと、（その時に使っていたClaude Codeの）精度を高めようとしたのである。

例えば、スキルを使ってガチガチに固めたルールでノートを作成させたり、サブエージェントを使ってノートの中身をレビューさせるなど、本来論的にはすべきではないところに時間と労力を割いた。その結果、何が起こったかというと、Claude Codeの利用量制限には引っかかり、出来上がったノートは多少マシになったものの、結果的に「他者の意見が入っている」という点は何ら改善できなかった。

今は考えを改め、Zettelkastenには自分の考えしか入れておらず、心の平穏は保たれている。

情報の出所と活用方法は、厳密に管理すべきである

こうして考えてみると、何か特定のテーマの論点を整理したり、文献の検索までをAIにやってもらうのは結構なことだとは思う。また、Zettelkastenの中身を検索して、思いもつかないようなインサイトを提示してもらうのも良いだろう。

しかし、AIにノートを作成・校正させたり、メタデータ（タグなど）や構造を操作させてはならないと強く実感した。これをしてしまうと、それらのノートがノイズになってしまい、知的生産活動ができなくなってしまう。

SNSを見ていると、個人の知的ノートと生成AI（Claude CodeやAntigravityがホットな話題のようだ）を組み合わせてコンテンツを量産するという記事、あるいは情報商材が出回っており、カオスな状態になっていると感じる。

私も、こうした仕組みを試した結果をnoteに書いたのだが、実際にはその仕組みは機能しないと思っている。なぜなら、これを本当の意味で実現しようと思うと、相応の設計能力、それに沿った運用が求められるからである。それができる人が、果たしてどれだけいるだろうか。できなければ、何もない状態からAIにコンテンツを作らせるのと何ら変わらない結果となってしまうのは火を見るよりも明らかである。

すなわち、例え生成AIが自由に使えるようになったとはいえ、それを使った知的生産活動には、AIの使い方だけではない「知識」の高度な運用能力が引き続き求められている点に留意する必要がある。

参考記事

この3ヶ月で得た、仕事におけるAI活用と、人間の役割に関する重要な気づき

読み放題よりも、Kindle Unlimitedの本当の価値は別にあった

Wed, 21 Jan 2026 00:00:00 +0900

正直に言うと、Kindle Unlimitedにはあまり期待していなかった。

「月額980円で読み放題」と言われても、読みたい本なんてそんなにないだろうと思っていた。

ところが、しばらく使ってみて気づいた。

Kindle Unlimitedの本当の価値は、「読み放題」ではない。それは、自分の中にあった学びの心理的ハードルを壊してくれたことだった。

同じテーマを複数の視点で学ぶことの重要性

あるテーマについて深く理解しようとする時、1冊の本だけでは不十分だと感じたことはないだろうか？

例えば、行動経済学について学びたいとする。その時、以下のような異なる視点の本を読むと理解が深まる。

NewsPicksのような実務寄りの本
アマチュアが書いた入門書
プロが書いた専門書

こうした異なる水準や視点の3〜4冊を一気に読むことで、個別の事実ではなく、なんとなくの知識体系が頭の中に形成される。単一の本よりも、複数の視点を組み合わせることで、より堅牢で応用可能な理解が得られるのだ。

でも、複数冊買うのは心理的ハードルが高い

ここで問題がある。同じテーマの本を複数冊購入するのは、意外と心理的・経済的な障壁が高い。

「もう1冊買っても本当に読むかな？」
「さっき買った本で十分かもしれない」
「3冊も買ったら数千円になる…」

こうした躊躇が、学びの深さを制限してしまう。

Kindle Unlimitedが下げる「学びの障壁」

ここでKindle Unlimitedの真価が発揮される。定額制なので、同じテーマの本を何冊読んでも追加コストがゼロだ。

この「追加コストゼロ」という安心感が、複数の視点から学ぶという行動を後押ししてくれる。経済的な障壁がなくなることで、心理的な障壁も下がるのだ。

「気になるテーマがあれば、関連する本を3〜4冊まとめて読んでみよう」という発想が自然と生まれる。これこそが、Kindle Unlimitedの本当の価値だ。

さらに効率を上げる：要約サービスとの組み合わせ

学びの効率をさらに高める方法がある。それは要約サービスを読書前の準備段階として活用することだ。

具体的には以下の流れとなる。

気になるテーマについて、Flierなどの要約サービスで概要を把握する
基礎的な枠組みができた状態で、Kindle Unlimitedで本を読む

この段階的なアプローチにより、本を読む際に既に基礎的な枠組みが形成されているため、知識の定着に大きく活かせる。要約で全体像を把握してから詳細を読むことで、情報がより効果的に統合されるのだ。

まとめ：Kindle Unlimitedは「学びの実験場」

Kindle Unlimitedの価値を「何冊読めるか」で測るのはもったいない。本当の価値は、同じ情報に角度を変えて何度も触れることの心理的障壁を下げていることにある。

要約サービスと組み合わせれば、さらに効率的な学習サイクルが回せる。

あなたはKindle Unlimitedをどう活用している？「読み放題」ではなく「学びの実験場」として使ってみると、新しい発見があるかもしれない。

画面を分けるだけで「学び」が変わる。Pixel 10 Pro Foldで実現する新しい読書術

Sun, 11 Jan 2026 00:00:00 +0900

これまでは、ノートパソコンを広げて読書をするのが私のスタイルでした。左側に電子書籍のKindle、右側にメモ用のアプリを開き、気づいたことを音声で入力していく。この「読み」ながら記録する流れが、知識を身につける一番の近道だったからです。

しかし、自宅、あるいは外出先でパソコンを取り出すのは、どうしても手間がかかります。もっと手軽に、それでいて本格的に学びたい。そんな悩みを解決してくれたのが、画面を大きく広げられるスマートフォン「Google Pixel 10 Pro Fold」でした。

このデバイスの最大の特徴は、一つの画面を二つに分割して、別々のアプリを同時に動かせることです。電子書籍で本を読みながら、もう片方でGoogle Keepを開く。パソコンで行っていた効率的な学習環境が、手のひらの上で完全に再現されました。

驚くほどスムーズな「声のメモ」が、思考を止めない

特に驚いたのが、Gboardの音声入力の精度です。読み進める中で心に残ったフレーズを口に出すと、魔法のようにスラスラと文字に変わります。反応が非常に速いため、せっかく思い浮かんだアイデアを忘れる前に、確実に記録に残せるようになりました。

以前は「スマホでメモをするのは面倒」という先入観がありましたが、今ではパソコンよりも快適に感じています。場所を選ばず、思い立った瞬間にアウトプットを開始できる。このスピード感こそが、忙しい日々の中で学びを継続する鍵になると実感しています。

さらにこの仕組みは、本だけでなく動画での学習にも応用できます。画面の左側にYouTubeやオンライン講座を流しながら、大事なポイントを右側のGoogle Keepに音声入力で書き留める。ツールが連携して動く様子は、まるで自分専用の学習室を持ち歩いているような感覚です。

Androidユーザーなら、今すぐその恩恵を受けられる

とはいえ、Google Pixel 10 Pro Foldは決して安い買い物ではありません。その価格に、導入をためらってしまう方も多いでしょう。ですが、今回お伝えした「効率的な学習体験」の本質は、実は多くのAndroid端末で今すぐ体験できるものです。

画面分割機能や、高精度な音声入力は、Androidが共通して持っている強みです。まずは手持ちのスマートフォンで、読書アプリとメモアプリを並べてみてください。そしてキーボードで打つ代わりに、マイクに向かって自分の考えを話してみてください。

たとえ画面が少し小さくても、声でアウトプットする爽快感とスピードは十分に実感できるはずです。道具の良さを引き出す工夫一つで、いつものスマートフォンが強力な学習ツールへと進化します。これは試してみない手はありません。

スマートフォン一台で、未来の自分への投資を加速させる

これからの時代、スマートフォンは単に情報を眺めるだけの道具ではなく、自分を成長させるための「相棒」になっていくでしょう。高性能な機能が手元に凝縮されたことで、隙間時間はすべて、価値あるアウトプットの時間へと姿を変えます。

「スマホだけで本当に勉強ができるのか」と疑問に思う方もいるかもしれません。しかし、道具を賢く組み合わせることで、私たちは場所や時間の制約から解放されます。まずは一歩、手元のデバイスで「読みながら話す」習慣を始めてみませんか。

日々の小さなアウトプットの積み重ねが、いつか大きな成果となって自分を助けてくれるはずです。新しい道具を味方につけて、自分なりの学びのスタイルをアップデートしていく。そんな前向きな挑戦を、これからも楽しんでいきたいと思います。

Emacs + DDSKK on kittyな環境で日本語変換がバグる

Tue, 02 Dec 2025 00:00:00 +0000

環境

Arch Linux
tmux 3.6
GNU Emacs 30.2 + DDSKK
kitty 0.44.0

事象

以下のように入力すると、不正な文字列が入力される。

KiGasuru -> 気gがする

解消方法

以下のようにすることで、完全な解消は難しいものの軽減はできた。

~/.config/kitty/kitty.conf

cfg
kitty_keyboard_protocol no

~/.local/bin/emacs-noime

Shell
#!/bin/sh -e

unset GTK_IM_MODULE
unset QT_IM_MODULE
unset XMODIFIERS
unset DefaultImModule
unset GLFW_IM_MODULE

export NO_AT_BRIDGE=1

exec emacs -nw "$@"

今後は、 ~/.local/bin/emacs-noime を kitty から呼びだすことで、不正な文字が極力残らないようにして作業を実施できるものと思われる(完全解消するためには、 emacs -nw を止めるしかない)。

その後の検証の結果

結局、上記は効果がなかったとは言えないが、もっとも効果がありそうなのは以下の対策であった。

~/.config/kitty/kitty.conf

cfg
programs.kitty.keybindings = {
 "ctrl+j" = "discard_event";
}

その後の検証の結果(2)

結局、劇的な効果が見込まれず emacs -nw をtmuxの中で動かすことは止めにした。

qutebrowserがウェブサイトを描画しない

Sun, 23 Nov 2025 00:00:00 +0000

かつてよりLinux環境ではFirefoxを愛用していたのですが、最近ではもっぱらqutebrowserを愛用しています。vimの操作方法を使えるのが便利で、マウスを使わずともほとんどの操作をキーボード主体でできることから、i3-wmとも非常に相性が良いです。

しかし、そのqutebrowserをArchLinuxにインストールしたところ、どうにもまともに動かない状況で、2-3日ハマりました。結論は、Xorgのドライバーをきちんとインストールしていなかったことでした。解決に至るまでの状況と教訓をまとめておきます。

起こっていたこと

スタートアップに指定しているDuckDuckGoのページが表示されない。ロードが終わっていることはステータスバーから分かるものの、画面は真っ白の状態。まれに画面がちらつき、アヒルのロゴが表示される状況。
操作がまともに出来ない。コマンドを受け付けない。

調査(1) qutebrowser/qtwebkitのバージョンによる不具合の有無

まず最初に疑ったのが、ArchLinuxにインストールされている qutebrowser と、それが利用している QtWebEngine のバージョンによる不具合の有無です。私の環境では、2025年11月21日現在で以下のバージョンがインストールされていました。

qutebrowser v3.6.1
PyQt 6.10.0
PyQt6.QtWebEngineCore 6.10.0

これらのバージョンは、正常に動作しているSlackware -current on ThinkPadと同じであったので、インストールされているバージョンに不具合があるというわけではなさそうだ、という結論に到達しました。(一応、ChatGPTにも調査させ、不具合がでていないことは調べました。)

調査(2) ドライバの問題

次に疑ったのがグラフィックドライバの問題です。疑った根拠は以下の2つです。

Xorgの設定をまともにしていなかったと思い出したこと
qutebrowser --version の出力結果を眺めていたところ、qutebrowserの内部ではChromiumをベースとしたQtWebEngineが動作していることに気が付いたこと

利用している端末はHP EliteBook 630 (G9)で、これには12世代のIntel CPU(12th Gen Intel(R) Core(TM) i5-1235U)が搭載されています。使用しているグラフィックボードはオンボード(統合チップセット)で、Intel Iris Xe Graphicsです。Xorg - ArchWikiによると、この世代のチップには xf86-video-intel を使うのではなく、代わりに mesa を使うように記載があります。

なるほどと思い /var/log/pacman.log を調べると、 extra/mesa がインストールされていないことが判明しました。 extra/x86-video-intel を削除したのち、 extra/mesa をインストールして端末を再起動したころ、qutebrowserが正常に動作するようになりました。

教訓

当たり前のことですが、ソフトウェアの動作環境はきちんと確認するようにすべきでした。今回の場合、 qutebrowser --verion を実行すれば、どのバージョンのソフトウェアが動作しており、かつqutebrowserに認識されているのかを確認することができます。その中で、OpenGLがどのドライバーによって動作するのかも知ることができるので、最初から丹念に確認しておけば今回の調査期間を短縮できたはずです。今回気が付いたのは3日目でした。

また、Slackwareでqutebrowserを特に何も気にすることなく使えていたのは、あらかじめ必要なドライバーがインストールされており、それが自動検出によって使われていたお陰であろうと思います。ArchLinuxはカスタマイズ性が高いのですが、それはすなわち全てを自分で管理しなければいけないということにあるので、まずはきちんと設定をする、というところを怠るべきではありませんでした。(最近のLinuxの自動検出/自動設定に甘えていました)

今回のこの件を機に、自分のスキルはまだまだだなと思いつつ、利用者の目線からするとある意味ではシンプルに動作している点がさすがLinuxだと思ったので、今後も精進していこうと思います。

SlackwareでThinkPadの液晶の明るさを変える

Sun, 02 Nov 2025 00:00:00 +0000

X.comでもいくつかポストしていますが、先日からSlackwareでi3を使用しています。環境構築作業のなかで最も優先度が低かったのが液晶の明るさを変更するための仕組みであったのですが、今日、ようやく実装しました。

何かツールを入れるのもなぁと思っていたところ、 /sys/class/backlight/amdgpu_bl0/brightness を書き換えればよいということがわかり、以下のようなスクリプトを作っておきました。

Shell
#!/bin/sh -e

#
# Usage:
# brightness.sh 1000 (for Brighter)
# brightness.sh -1000 (for Darker)
#

FILE=/sys/class/backlight/amdgpu_bl0/brightness
CURRENT_BRIGHTNESS=`cat $FILE`

TARGET_BRIGHTNESS=$(( $CURRENT_BRIGHTNESS + $1 ))
echo $TARGET_BRIGHTNESS > $FILE

これを、以下のように設定することでキーボードから呼び出すようにしました。

プレーンテキスト
bindsym XF86MonBrightnessUp exec --no-startup-id sudo ~/.local/bin/brightness.sh 4000
bindsym XF86MonBrightnessDown exec --no-startup-id sudo ~/.local/bin/brightness.sh -4000

私だけしか使っていないシステムなので、 sudo は NOPASSWD で実行できるようにしています。

これで、設定を再読み込みすれば、キーボードから液晶の明るさを調整することができるようになります。

Slackware -currentでHEIC対応のdigiKamを動かす

Mon, 20 Oct 2025 00:00:00 +0000

TL;DR

Slackware -currentのImageMagick (7.1.2-7)は --with-heic=yes でコンパイルされていないため、それを使っているdigiKamでもHEIC/HEIFフォーマットの画像を扱うことができない。同じ理由で、Gwenviewでも扱うことができない。

そもそもの発端

つい最近までDebian GNU/Linuxを使っていたのですが、思うところがありここ数日でSlackware -currentに環境を移行しました。kernel/gcc/emacsを自前でコンパイルし、色々な試行錯誤を繰り返しながら、なんとか必要な作業ができるようになってきたことから、本格的にデータを移行することにしました。

これといった理由は特に無いのですが、趣味の写真をさっさと再開できるようにということで、まずは写真のデータをSlackwareに移行することにしました。

HEICフォーマットの画像がdigiKamに表示されない

HEICフォーマットはiPhone等で使われる形式で、同程度の視覚品質を得るためにはJPEGの50-60%程度のファイルサイズで済むといわれています。つまり、容量に制約のあるスマートフォンや、クラウドサービスの容量を節約したい場合にHEICを使うことが良いのではないかと思われます。私も、iPhoneでHEICが使われるようになってからというもの、iPhoneで撮る写真はすべてHEIC形式になりました。

それらの写真をdigiKamに取り込もうとした時に、サムネイルもプレビューも表示されないので「どうなってんだ？」と思い調査したところ、まず判ったのは libheif がシステムにインストールされていないことでした。

`libheif` をインストールする

libheif は libaom と libde265 に依存している。まずはそれらをシステムにインストールする必要があるので、準備する。 libaom はdarkskygit / libaomから入手することができる。また libde265 はstructurag / libde265から入手できるので、それぞれREADMEを参考にコンパイルしてパッケージを作り installpkg でインストールしておく。

次に libheif をインストールする。 libheif はstructurag / libheifから入手できるので、こちらもREADMEを参考にコンパイルしてパッケージを作り installpkg でインストールしておく。途中 /usr/lib64/libaom.a が見付からないというエラーが出るので ln -s /usr/lib64/libaom.a /usr/local/lib64/libaom.a としてsymlinkを張っておく。

ここまで実施してdigiKamを起動しても状況は変わらなかった。なぜだと考え、調べているうちに、どうやらdigiKamはバックエンドにImageMagickを使っていそうだということがわかり、では、ImageMagickでHEIC/HEIFは有効になっているのだろうかと調べたところ有効になっていなかったのであった。

Shell
$ magick -list format | grep HEIC # 結果は何も表示されなかった => 無効
$ magick -list format | grep HEIF # 結果は何も表示されなかった => 無効

ImageMagickを `--with-heic=yes` つきでインストールする

ImageMagicは、currentのソースコードをもとにコンパイルする。 imagemagic.SlackBuild の中に記載されている ./configure に対し --with-heic=yes を指定したうえでパッケージを作成し、インストールする。

ここまで実施した上でdigiKamを開くと、HEICフォーマットの画像が表示されるようになっているはずである。

DolphinとGwenviewでもHEICを扱いたい場合は、KImageFormatsをHEICサポートつきでコンパイルし、インストールする必要がある

ここまで実施しても、まだDolphinやGwenviewでHEICを表示することはできない。それらでHEICを扱うためには、KImageFormatsをHEICサポートつきでコンパイルし、インストールする必要がある。 cmake の引数に -DKIMAGEFORMATS_HEIF=on を指定してコンパイルし、パッケージを作成、インストールする。

こうして無事、私の写真ライブラリはSlackwareマシンに移行されたのでした。

まとめ

こうしてまとめてしまうと何てことのない作業なのですが、実際にはログを見たり、インターネットで調査したり、横道に逸れたりしながら調査して、結構時間を喰ったように思います。が、まずはHEICがきちんと取り扱える環境になってめでたし、めでたし。

こういう調査は知識を身に付けるよい機会であるので、きちんと記録を取りながら対応し、知識を整理していきたい。今回は、作業ログをChangeLogのフォーマットで記録しておいたので、それを参考にしながらこの記事を書きました。

Debian GNU/Linux 13 (trixie)の4K出力が安定しない件を解決する

Mon, 13 Oct 2025 00:00:00 +0000

私は普段、Debian GNU/Linux 13 (trixie)をThinkPad E14 (Gen 3)で運用しており、外付けモニターとしてJapanNextの4Kモニターを使用しています。4K出力に対応しておりながら安価である点が気に入っています。

さて、その環境も、HDMI出力が安定せず、画面が表示されたりされなかったりで作業にならない状況が続いていました。どうもXがEDIDをモニターから取得するまでのタイムラグが原因のように思えましたので、環境決め打ちになってしまうのが気にはなりますが、以下のように対処をしました。

ここに記述している内容はX向けの設定ですが、結果的にXWayland経由で設定が反映されていることになります。

問題の切り分け

まずは物理的な問題を除外しました。

モニター自体は正常か？: 手元にあるMacBookを使ったところ正常に4K出力できたので、問題は無いと判断した。
HDMIケーブル自体は正常か？: 手元にあるMacBookに接続してみたところ正常に4K出力できたので、問題は無いと判断した。
ThinkPadのHDMIポートに問題は無いか？: 手元にある他のモニター(FullHD)に接続してみたところ正常に出力できたので、問題は無いと判断した。

この結果、物理的なハードウェアの問題ではなく、モニターとThinkPadの間の通信(ネゴシエーション)がうまくいかない場合がある、という仮説にいたりました。

ネゴシエーションの肝となる `EDID (Extended Display Identification Data: 拡張ディスプレイ識別データ)`

EDIDは、モニターが自分自身の仕様をコンピュータに伝えるデータです。具体的には以下の情報を含みます。

対応解像度(例：1920x1080、3840x2160)
リフレッシュレート(例：60hz)
色深度やカラーフォーマット
製造情報
タイミング情報(垂直/水平同期)

通常、コンピュータはEDIDを参照して自動的に最適な解像度やリフレッシュレートを設定します。EDIDのやり取りが失敗すると、画面が表示されなかったり、 xrandr が BadMatch エラーを返したりします(追記：これは、Waylandで実行すると出るエラーです)。

モニターから取得したEDID情報をXWayland経由で読み込む

つまり、モニターとやり取りをして解像度等を決定するのではなく、あらかじめEDIDを取得しておき、それをXから読み取るようにしておけば、ネゴシエーションに失敗する可能性は低いわけです。ただ問題は、EDIDを取得するためにはきちんと画面出力されている必要があるということで、そこまではなんとかする必要があるということです。全く表示されない場合には、この手段は使えないと思います。

EDIDを取得する

/sys/class/drm/card0-HDMI-A-1/edid からダンプしておきます。ここは環境に依存しますので、どのパスからダンプすればよいのかは xrandr の情報を参考にして決めてください。

Shell
$ sudo mkdir -p /etc/X11/edid/
$ sudo cat /sys/class/drm/card0-HDMI-A-1/edid > /etc/X11/edid/JAPANNEXT_JN-280IPS4KR.bin

Xの設定

/etc/X11/xorg.conf.d/10-monitor.conf を編集します。

プレーンテキスト
Section "Monitor"
 Identifier "HDMI-1"
 Option "CustomEDID" "HDMI-1:/etc/X11/edid/JAPANNEXT_JN-280IPS4KR.bin"
EndSection

ゴミデータの削除

~/.config/monitors.xml が悪さをする可能性があるので、消しておきます。

Waylandを再起動

sudo systemctl restart display-manager によりWaylandを再起動し、正常に画面出力されることを確認します。また、HDMIケーブルを何回か抜き差ししても、毎回、安定して画面出力されるかを確認します。

制約

この方法を使うと、HDMI接続時に毎回、JapanNextのEDIDを参照することになるので、他のモニターによっては出力できなくなる可能性があります。環境がある程度固定的であればこの方法は有効ですが、そうでない場合(持ち歩き用途など)では使えない可能性もあります。
画面が全く表示されない場合にはEDIDが取得できないため、この方法は使えません。
サスペンドからの復旧時には、HDMIケーブルを抜線後にログインし、HDMIケーブルを差し込んだあと display-manager を再起動する必要があります。 sudo systemctl restart display-manager

Debian GNU/Linux 13 (trixie)でSwiftを動かす

Sun, 12 Oct 2025 00:00:00 +0000

Swift は、Apple社が開発をしているプログラミング言語で、主にApple製品で動作させるソフトウェアを開発するために使用されるものですが、オープンソース化されてからというもの、Linuxなどサーバサイドで動作するソフトウェアの開発にも使われているようです。

今回は、たまたま目新しいということで、インストールしてみました。

Swiftをインストールする

Install Swiftを参考にすればインストール自体は簡単にできます。

Shell
$ cd
$ mkdir swiftly
$ cd swiftly
$ curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz
$ tar xvzf swiftly-$(uname -m).tar.gz
$ sudo ./swiftly init --quiet-shell-followup
$ sudo apt install libstdc++-12-dev # Swiftlyからインストールを求められた場合のみ
$ . "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh"
$ hash -r

~/.bashrc にも、以下を追記しておきます。

Shell
# Swift
. "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh"
hash -r

`Hello World` してみる

swift にパスが通っていることを前提に、以下のコマンドを実行します。

Shell
$ mkdir helloworld
$ cd helloworld
$ swift package init --name HelloWorld --type executable
$ swift run HelloWorld

すると、以下のように実行されます。初回はとにかく遅く、Hello Worldだけにも関わらず約5秒の処理時間が掛っていました。

プレーンテキスト
Building for debugging...
[8/8] Linking HelloWorld
Build of product 'HelloWorld' complete! (4.99s)
Hello, world!

2回目は以下のようにキャッシュが効いているのか、速くはなってはいますが、それにしても遅いですね。

プレーンテキスト
[1/1] Planning build
Building for debugging...
[1/1] Write swift-version-3F9C5CDD8FC5382D.txt
Build of product 'HelloWorld' complete! (0.20s)
Hello, world!

EmacsでSwiftを使ってみる

当然、EmacsでもSwiftを使うことができます。私の場合、現時点でSwiftで本格的にプログラムを書く予定はなく、 org-babel で少し勉強したいと思っている程度なので、 ob-swift と swift-mode を導入することにしました。

PATHを通す

以下のような設定を ~/.emacs に入れることにより、Emacsを起動した際にShellの設定ファイルを読んでパスを通してくれます。事前に、 M-x package-install で exec-path-from-shell をインストールしておく必要があります。

Emacs Lisp
(when (memq window-system '(mac ns x))
 (exec-path-from-shell-initialize))

`ob-swift` と `swift-mode` をインストールする

M-x package-install から ob-swift と swift-mode をインストールしておきます。前者は org-babel でSwiftを実行するために必要、後者はシンタックスハイライトをするために必要となります。

`org-babel` でSwiftを有効化する

以下のような設定を ~/.emacs に入れることにより org-babel でSwiftが実行できるようになる。

Emacs Lisp
(org-babel-do-load-languages
 'org-babel-load-languages
 '((swift . t)
 (emacs-lisp . t)))

この例では、SwiftとEmacs Lispを有効化しています。Emacs Lispについては、あえて記述しなくとも最初から有効になっているため、書く必要はありません。

`org-babel` でSwiftを実行する

ここまでの設定を終えていれば、以下のように書くことで org-babel でSwiftを実行できます。

プレーンテキスト
#+begin_src swift
let a: Int = 1
print(a)
#+end_src

#+RESULTS:
: 1

まとめ

実際にiPhone等で動作するアプリケーションを開発するためにはMacbookが必要になりますが、Swiftの基本的な文法は、Linux上でも十分に試すことができますし、 org-babel で気軽に試しながら勉強できるというのは大きなメリットになる人もいると思います。

少なくとも、私の場合には org-babel が使えるということと、Xcode Playgroundsよりも気軽に試すことができるということはメリットでありますので、しばらくこの環境で勉強しつつ、軌道に乗ってきたらMacbookで実際の開発作業に取り掛かってみようかと思います。

Git Submoduleを使っている環境で、 upload-pack: not our refエラーが発生した場合の修復方法

Wed, 08 Oct 2025 13:39:47 +0900

概要

このブログは、Hugoで構築している。ブログを構成する資材は全てGitHubに保存しており、以下のような構成になっていた。

プレーンテキスト
blog <--- Hugoの親リポジトリ(非公開)
 `--- public <--- 公開用資材のリポジトリ(公開、サブモジュール)

この構成により、通常の運用の流れは以下になるはずであった。

blogで記事を書き、チェック
publicに公開用資材を作成
public、blogの両方に対して git commit 、git push を実行

ところが、前回、別のマシンで作業したときに、3.でpublicに対する git commit は実行したものの、git pushの実行を忘れた状態で、blogに対しても git commit 、git push したのである。そのため、以下のような状態になってしまっていた。

プレーンテキスト
blog public(submodule)のCommit Hashは BBB であると認識
`--- public(旧マシン) Commit Hash: BBBをCommit済、未push
`--- public(リモート) Commit Hash: AAAまでしか存在しない

blogは、publicがcommitされた状態(= Commit Hash: BBB)でGitHubのリポジトリに登録されている。一方で、publicについて、リモート(GitHub)のリポジトリにはCommit Hash: BBBが反映されていない。つまり、リモートでは、親リポジトリとサブモジュールで一世代分、ずれていたのである。

そのため今回、新マシンで git submodule update をしようとしたときに、Commit Hash: BBBのpublicが見付からないということで、fatal: remote error: upload-pack: not our refエラーが発生した。

再現手順

サブモジュール(public)に変更を加え、git commitする(git pushはしない)。
親リポジトリ(blog)に戻り、サブモジュールを追加(git add public)する。
親リポジトリで、git commit、git pushする。
その後、別マシンにクローンしてから、以下のコマンドを実行する。

Bash
git submodule update --init

すると、以下のようなエラーが出力される。

プレーンテキスト
Cloning into '/home/sonohen/work/blog/blog/public'...
fatal: remote error: upload-pack: not our ref 35b4c8b0165369c2f92485e2b384bfc78827c75f
fatal: Fetched in submodule path './', but it did not contain 35b4c8b0165369c2f92485e2b384bfc78827c75f. Direct fetching of that commit failed.

対処方法

一世代分の変更を失うことになるが、参照可能なpublicのCommit Hashに戻すことで対応した。

Shell
$ cd public
$ git fetch
$ git checkout 696fc9d1917dbab6789042c72e0b9b904aeb5e6a # GitHubに存在する最後のCommit Hashを指定

$ cd ../
$ git add public
$ git commit -m "Update submodule ref to valid commit"
$ git push

今後に向けて

以下のような deploy.sh を書いておくことで、サブモジュール側での commit、push し忘れを防止するようにした。

Shell
#!/bin/bash
set -e

# build site
hugo

# commit using git
cd public
msg="Rebuilding site `date`"
git add -A
git commit -m "$msg"
git push origin master
cd ../

# upload all site settings
git add -A
git commit -m "$msg"
git push origin master

クレカで貯金体質に！賢い利用で未来を変える３つの秘訣

Sun, 28 Sep 2025 00:00:00 +0900

この記事の背景と目的

前回、キャッシュレス決済を賢く使い、資産を増やす方法について私が実践している内容を記載しました。まだの方は、この記事よりも前に、こちらを読んでみてください。

その中で、以下に示すような費用は、クレジットカードで支払いをしているということを記載しました。

水道光熱費
自動車税
NHK受信料
火災・地震保険
ガソリン（※現在は近隣のガソリンスタンドがSuica支払いに対応したため、都度払いに移行）
高速（ETCカード）
高額決済（おおむね2万円以上）

この記事では、これらの支払いにクレジットカードを使っても、「支払いの都度、残高が減るという現金払いと同じメリットと、利便性というキャッシュレスのメリット」を適用するために、私が実践している内容をご紹介します。

使ったら、その日のうちに現金を取り分ける

使ったら、その日のうちに現金を取り分けておきます。つまり、使えるお金の中から、クレジットカードで支払った分だけを別にしておくということです。

ここで活用したいのが、「クレジットカードの利用通知」と、住信SBIネット銀行の「目的別口座」の2つです。

まず、クレジットカードの利用通知ですが、支払い先と金額がメールで送られてくるので、これは必ず使いましょう。不正利用の早期発見にもつながります。

カードご利用通知｜クレジットカードなら、JCBカード

次に「目的別口座」です。これは、クレジットカードで支払った分を、別の口座に取り分けておくために使います。私の場合は、普段使うお金は普通口座に入れておき、クレジットカードで使ったお金は、その日のうちに目的別口座（クレジットカード支出分口座）に移しています。その際、いくら移せば良いのかを決めるのに見ているのが、「クレジットカードの利用通知」です。

目的別口座 | 商品・サービス | NEOBANK 住信SBIネット銀行

私が参考にさせていただいている方の中には、封筒で取り分けているという方もいらっしゃいますので、お好きな方法を使えば良いのではないかと思います。

いずれにせよ、「使った分は、その日のうちに取り分けておく」というルールにより、現金払いのように使えるお金が減りつつ、キャッシュレスの利便性を享受することができます。

1週間に1回、確定した残高を繰上げ返済する

クレジットカードによっては、確定した明細を繰上げ返済することができるサービスがあります。私が知る限り、JCBカードと三井住友カードは、繰上げ返済の手続きをインターネットで実施できます。

これを活用し、1週間に1回、確定した明細分の支払いを、先ほど述べた「目的別口座」から繰上げ返済してしまいます。

私がこのようにしている理由は2つあります。

普通口座と目的別口座は、容易に資金の移動ができてしまう。つまり、普通残高が苦しくなってきた時に、目的別口座のお金を使い込んでしまう可能性が高くなる。1週間に1回でもカード会社にお金を支払ってしまえば、目的別口座の残高は少なくなるはずなので、使い込む金額は少なくて済む。
クレジットカードの残高が多いのは、プレッシャーになる可能性がある。クレジットカードの残高 = 借金であり、残高が少ければ少ないほど良いと考えているため、1週間に1回、前払いすることで残高を減らしたい（気分の問題）。

まとめ

クレジットカードでも、現金払いの良さとキャッシュレスの利便性を両立させることができます。その際に使うのは、「クレジットカードの利用通知」、「目的別口座を使った現金の取り分け」、「繰上げ返済」の3つです。

2回にわたって、キャッシュレスの利便性を求めながら、現金払いの良さも両立させることで資産を増やす方法として、私が実践していることを記事にしました。

基本は、デビットカードを基軸にした支払い方法を使いつつ、高額な支払いなどはクレジットカードを使って定期的に繰上げ返済するということで、私は賢く、キャッシュレス社会を生き抜こうとしています。

日々、よりよい方法を考えているところではあるので、今後もアップデートがあれば記事にしていきたいと思います。ご覧いただいてありがとうございました。

キャッシュレス決済の賢い使い方～支出管理と資産形成のコツ～

Sat, 06 Sep 2025 00:00:00 +0900

要約

キャッシュレス決済は便利ですが、使い方を間違えるとつい無駄遣いし、資産が増えにくくなることもあります。以下のポイントを参考にすると、利便性を享受しつつ資産を守ることができます。

主なキャッシュレス決済の種類

クレジットカード（後払い型）:　支払は月単位でまとまり、後日まとめて銀行口座から引き落とされます。便利ですが、使いすぎやすい面があります。
デビットカード（即時払い型）:　使った直後に銀行口座から即時引き落とし。支出管理がしやすく、現金感覚に近いのが特徴です。
チャージ式電子マネー:　あらかじめチャージした金額内での利用なので、使いすぎの心配がありません。

賢い使い分けの実例

高額決済や生活インフラの支払いには、クレジットカード
日常的な買い物や交通費、サブスクなどは、デビットカードや電子マネー

こうすることで、無駄遣いの抑制・日々の資産把握・家計の見える化を実現できます。

キャッシュレスをめぐる日本の最新動向

2024年のキャッシュレス決済比率は42.8%。デビットカードは3.1％と伸びていますが、全体ではまだ少数派です。
補償面ではクレジットカードの方が手厚い傾向がありますが、デビットカードもセキュリティや銀行ごとの工夫が広がっています。

私はキャッシュレス決済の使い分けにより、増えも減りもしなかった資産を、1年間で190万円近く増やすことに成功しました。この記事では、そのことを記載したいと思います。

キャッシュレス決済の種類

主なキャッシュレス決済には、以下の4つの種類があります。

後払い（例：クレジットカード）:　ある期間に使った金額を、決められた日にクレジットカード会社に支払う方法。請求をまとめられるメリットがあるものの、使いすぎる傾向にある。
都度払い③（例：デビットカード）:　支払いの都度、デビットカードに紐づけられている銀行口座から即時引き落としされる支払い方法。（即時引き落としされない場合もありますが、話が複雑になるため割愛）
都度払い④（例：モバイルSuica）:　支払いの都度、電子マネーの残高から即時引き落としされる支払い方法。クレジットカードやデビットカード、銀行口座、ATMや券売機などで電子マネーの残高にお金を入れ、その範囲内で使用できる。
後払い②（例：ペイディ）:　ある期間に使った金額を、決められた日に金融会社に支払う方法。クレジットカードと違う点は、与信審査が簡易であったり、利用限度額が一般にクレジットカードよりも低額に抑えられている点などです。「即買って、支払いは後日（Buy Now, Pay Later）」と表現されることもあり、別名、BNPLとも言われます。

この記事では、1〜3を「キャッシュレス決済」と扱います。

参考情報として、キャッシュレスの場合、現金に比べて支出が1.7倍程度増えるという調査結果があります。

キャッシュレスは、「お金を使いすぎてしまう」って本当？キャッシュレスは、「お金を使いすぎてしまう」って本当？｜ベネッセ教育情報サイト【ベネッセ｜教育費】消費税増税をきっかけに、キャッシュレス決済への流れが大きく加速しています。政府は2025年の大阪・関西 benesse.jp

日本クレジットカード協会の調査(2017年度)によると、支払いをクレジットカードで行う人は現金で行う人より1.7倍多く使うという結果でした。

使ってしまいがちな場面は、「衣料品専門店」「雑貨・文具」「タクシー」の支払いで、現金の２倍以上と高くなっています。共通するのは少し特別感のある消費場面です。

― ベネッセ, キャッシュレスは、「お金を使いすぎてしまう」って本当？

Before - 何でもかんでも、後払い

水道光熱費やサブスクリプションなどの固定費、食料品や飲食の立替などの変動費。全ての支払いを後払いで支払っていました。後払いでは支払った実感のない私は、常にクレジットカードの請求額が大きな金額になっており、給与や副業収入のほとんどがクレジットカードの支払いに回っている状態でした。何に金を使っているのかもよく分からない状態で、資産が増えることはありませんでした。

今思えば、クレジットカード会社の思う壺というか、いいカモだったと思います。便利で、ポイントも貯まるということで、わずかなポイントのために、大きな金額を浪費していたのです。

After - 後払いと都度払いをうまく使い分ける

今はどうしているかというと、以下のようにキャッシュレス決済の方法を使い分けています。ほぼ、現金主義と同じです。

水道光熱費、自動車税、NHK受信料、火災・地震保険、ガソリン、高速（ETCカード）、高額決済（おおむね2万円以上）は、後払い（クレジットカード；JCBカード）。
通勤や日常の移動に使っているモバイルSuicaは、都度払い（デビットカード；住信SBIネット銀行プラチナデビットカード）からチャージして利用。
サブスクリプションや、その他の日常的な決済は、都度払い（デビットカード、またはiD；住信SBIネット銀行プラチナデビットカード）。

こうすることのメリットはいくつもあります。要するに、「支払いの都度、残高が減るという現金払いのメリットと、利便性というキャッシュレスのメリットを両立できる」ということです。

常に現金が手元に残る:　私の場合、後払いの金額が（高額になったとしても）月に10万円を超えることはなく、クレジットカードの引き落としが終わっても、常に手元に現金が残る。
無駄遣いをしなくなる:　支払いのたびに銀行口座の残高がリアルタイムに減っていくため、その範囲内で支払いを考えるようになって無駄遣いをしなくなる。
資産の増減を日々確認できる:　支払いの大半を都度払いで行うことで、家計簿に使っているMoneyForwardというアプリで、ほぼリアルタイムに家計簿が作られる。後払い（クレジットカード）の場合には、利用から明細が上がるまでのタイムラグがあり、リアルタイムというわけにはいかない。これにより、資産の増減を毎日見ることになるので、無駄遣いをやめようという気持ちがより強くなる。

キャッシュレスの利点を損なうことはない

キャッシュレス決済のメリットの1つである迅速な支払いは保たれたまま、資産は増えていく。ポイント還元も、私が使っている住信SBIネット銀行のプラチナデビットカードであれば1.25%と、そこまで低くはありません。また、同カードは、ポイントが大体翌月の15日前後に付与され、設定次第では決済時にポイントが自動で充当されます。

まとめ

日本におけるキャッシュレス決済額のシェアは42.8%、そのうちデビットカードのシェアは2024年時点で3.1%（約4.4兆円）で、キャッシュレス決済額に占める割合としては少ないです。周りでも、不正利用があった場合の補償に不安があったり、そもそもデビットカードを認知していないケースがあったりします。

クレジットカードでうまく家計ができている人にとって、デビットカードを使うメリットはあまり多くないかもしれませんが、私のように「使った感覚が薄く、つい無駄遣いしがち」という人にとっては、デビットカードも含めたキャッシュレス決済方法の使い分けは、資産を増やす上で重要な考え方になるかもしれません。

クレジットカードとの上手な付き合い方もご紹介しています。ぜひ、本記事と合わせてご覧ください。

Apple Watch Ultra 2の先入観に惑わされながら、バンドの最適解がスポーツバンドであることを見落としていた日々

Fri, 05 Sep 2025 00:00:00 +0900

Apple Storeでは、3種類のバンドがApple Watch Ultra 2用として販売されている

私の「変な先入観」は、ここから始まったーー。

Apple Watch Ultra 2 Apple Watchのバンドを購入

Apple Watch Ultra 2を購入した際に付属していたのはブルーオーシャンバンド。その後、服装に合わせナチュラルチタニウムミナレーゼループ（長い……）を追加で購入しました。

バンドの質はいいんだけど、どこか着けづらい

あくまで「冒険する人のためのウォッチ」なので、バンドもそれに合わせて、外れにくいように、頑丈に作られているのです。ま、要は着けづらいということです。

オーシャンバンドは留め具がキツく作られているし、ミナレーゼループは幅広でジャキジャキする。買ったこともつけたこともないですが、アルパインループも着けづらいというレビューを見たことがあります（慣れ次第とも言われてました）。

「普段遣い」には、どうも適さないように思えていたのですが、先の先入観から別のバンドを試そうともあまり思わなかったのです。

スポーツバンドはどうだろう？

Apple Watch Journalのこちらの動画。Apple Watch Ultra 2にスポーツバンドをつけているのです。

この動画を見たときに、「あれ、Ultra 2にスポーツバンドいけるんじゃない？」と思い、ナチュラルチタニウムミナレーゼループを、自宅にあるApple Watch 10のスポーツバンドに換装したところ、

これは着けやすく、着け心地も快適だぞ！

となったのです。

割とこういうことは多いのではないか

変な先入観ってあると思います。色々な人がどのように使われているのかを見聞きすることで、それがきっかけで自分の考え方や行動が変わるのかもなあと思った経験でした。

私はITエンジニアですが、この出来事から色々な勉強会に出て見識を広げるのも重要だなと考えました。

NIFTY Tech Day 2025で思ったことと職場への持ち帰り

Fitbit Charge 6から、結局Apple Watch Ultra 2に戻った話

Sun, 24 Aug 2025 00:00:00 +0900

前回、Apple Watch Ultra 2を使うのをやめて、Fitbit Charge 6に移行した話を書きました。

それから2ヶ月経ち、今、腕に巻いているのはApple Watch Ultra 2なのでした。

戻った理由① スマホ無しで持ち出せるセルラーモデルは、なんだかんだで便利

ウォーキングが趣味で、多い時には週7日、少ない時でも週3日は時間をとって歩くようにしています。

その時に、スマホや家の鍵を持ち出すのは面倒だな、と思っています。

そこで活躍するのが、Apple Watchの中でも通信機能を持つセルラーモデルです。それなら、外にいても通信できます。音楽を聴くのも、家族に位置情報を知らせるのも、家の鍵を開け閉めするのもApple Watch単体でできるので、スマホも家の鍵も持ち出す必要はありません。

ウォーキング中におすすめなのが、Audible、Radiko、Apple Musicです。時間が溶けますよ。

戻った理由② アプリによるカスタマイズが便利

先に挙げたAudibleやRadikoもですが、Apple Watchはアプリによって自分好みにすることができます。

例えば、外出先でポイントカードを求められた時を思い浮かべます。財布を持っていなければ、ポイントを取り損ねます。

ですが、Apple WatchにMembership Widgetというアプリを入れ、事前に設定しておけば、財布がなくてもポイントを貯めることができるのです。

Membership widget

私は他にも、天気系（Yahooの天気、防災速報アプリ）、楽天Pay、日経、StepsApp（歩数をわかりやすく見せるアプリ）を入れています。

特に楽天Payは、楽天ポイントカードとQRコード決済の両方をApple Watchでできるようになったので便利です。

楽天ペイ

また数ヶ月後、Fitbitに戻ってたり、はたまた違うスマートウォッチに変えていたりするかもしれませんが、その時はその時でまた理由づけをしようと思います（笑）。

Apple Watch Ultra 2をやめて、Fitbit Charge 6にした話（前編 - 背景編）

Sun, 25 May 2025 00:00:00 +0900

先日、Apple Watch Ultra 2を秘書がわりに使っているということを記事にしました。

Apple Watch Ultra 2は快適に使っていましたが、先日困ったことがありました。ゴルフの練習中に、グローブとボタンが干渉してしまい、意図せず大量のスクリーンショットが撮影されてしまったのです。設定でスクリーンショットの生成を止められることは分かっていますが、場合によっては誤動作を引き起こす可能性もあり、少し不安を感じ始めました。

この経験から、Apple Watch Ultra 2の完成度について疑問を持つようになりました。Appleは開発者向けに、ゴルフコンパニオンとしてのApple Watchの機能を開発するためのAPIを公開（iPhone Mania）しています。にもかかわらず、グローブを装着して手首を曲げた際にボタンが干渉してしまうのは、Apple Watch Ultra 2自体の完成度としてどうなのかと疑問に思いました。（期待しすぎだったのかもしれません。）

Apple Watch Ultra 2の挙動とプロダクトの完成度に少し残念な思いをしたことで、以前のような熱量が冷めてしまったというのが正直なところです。

そもそも、Apple Watch Ultra 2が必要だったのか？問題

ガジェットは、必要性ももちろん大事ですが、ロマンはもっと大事だと思っていますので、買うときに必要性だけを考えないようにしている、というのが前提にあります。

その上で少し冷静になって、本当にApple Watch Ultra 2が必要だったのかを考えてみました。

私の主な用途は、以下の4つです。

予定とメッセージの通知
音声メモの収集
健康状態の収集
決済（モバイルSuicaとデビットカード（住信SBIデビットプラチナカード））

これらのために本当にApple Watch Ultra 2が必要なのか？と考えると、結構疑問なところがあります。音声メモの収集を除いて、他のスマートウォッチあるいはアクティビティトラッカーでできるからです。

また、Apple Watch Ultra 2は単独で4G通信ができます。iPhoneを持ち歩かなくても通信ができるので、極端な話、Apple Watch Ultra 2だけで外出してもなんとかなりそうな気さえします。が、実際に私が出歩く限りはiPhoneを持ち歩かないということはほとんどない（近所のコンビニに行く時くらい）なので、あってもなくてもどちらでもいいや、というくらいの価値です。

…さすがにApple Watch Ultra 2は高いのでは？と思い始めました。

音声メモをどうするか？

私が音声メモを取りたいと思うのは、手が離せない状況ではなく、思いつきをそのまま言葉として記録しておきたい場面です。つまり、言語化がうまくできるかどうかは分からないが、そのもどかしさも含めて記録しておきたい場面、です。

Apple Watch Ultra 2は、ほぼ24時間装着できた（充電の時間は除く）ので、ほぼ全てのそうした場面をカバーできていました。ゆえに、Apple Watch Ultra 2がなくなると困る場面は多々出てきます。

トイレ
風呂

といっても2つか……。これらの場面をどうやってカバーするかは、今後考えていかなければなりませんが、その他の場面においてはApple Watch Ultra 2が無くなっても問題はなさそうです。

他のApple製品との連携をどう考えるか？

Apple Watch Ultra 2と他のApple製品との連携で使われる（と思われる）のは、Handoff、AirPlayそしてiCloud連携です。そして、私が使っているのはAirPlay（AirPodsとの連携）と、iCloud連携（主にDrafts）です。

前者（AirPlay）は、Apple Watch Ultra 2にダウンロードしたAudibleやApple Musicのデータを、Apple Watch単独で、iPhoneを持ち歩かずに視聴するために使っています。iPhoneを持ち歩かない場面は少ないため、Apple Watch Ultra 2単独でAirPlayが使えなくなる影響はほとんどないと考えています。

後者（iCloud連携）は、Google Keepに移行すれば良いかなと思っています。Draftsをハブにしていろいろなアプリケーションにメモを飛ばす、というのがDraftsの目玉機能なのですが、私の場合は情報の一次収集場所くらいにしか使っていないので、Google Keepでも問題ないのです。

ですので、この辺りも特に問題にはならなそうです。

前編のまとめ

ゴルフの練習で感じたプロダクトとしての違和感で熱が冷め、冷静に用途を考えると、他のスマートウォッチ、アクティビティトラッカーでも十分代替できることがわかりました。

次の記事では、Apple Watch Ultra 2の後任として、なぜFitbit Charge 6を選んだのかを執筆したいと思います。

2025年8月24日追記

結局、Apple Watch Ultra 2に戻りました。

2025年9月6日追記

Apple Watch Ultra 2のバンドはスポーツバンドがいいよねという結論に至りました。

勉強会が仕事を変えてくれたという経験談

Tue, 29 Apr 2025 00:00:00 +0900

今年の2月に、ニフティ社の勉強会に参加したことを記事にしました。

この勉強会をきっかけに、社内勉強会への登壇回数を増やしました。その結果、予想以上の効果を実感したので共有します。

なお、私はシステムエンジニアの端くれのため、テーマはIT関連（特にAIやクラウド設計）が多いです。

効果1 アクティブラーニングによる理解促進・定着

「テーマを決め、資料を作り、理解が足りない部分は補足し、他者へ教授する」という一連の過程で、理解が進み、定着する効果は大きいものがありました。

例えば、「トランスフォーマーモデルの概要」をテーマにし、資料を作っている際に「自己注意機構（Self-attention mechanism）」というキーワードをきちんと説明できない自分がいました。一言で言えば、「文章における要素間の関係を捉えて文脈を理解するための仕組み」なのですが、これをわかるように平易に説明するのは難しいと感じています。

なんとか形にして迎えた勉強会当日、説明した内容を全ての聴講者が理解したかは不明ですが、少なくとも自分で資料にして説明するという過程で、自分なりの理解が進み、定着したのではと思います。

効果2 社内での認知度向上

普段はプロジェクトに閉じた範囲で物事が完結することが多かった私ですが、プロジェクト外の活動である勉強会を通じて、社内での認知度が上がった（社内での交流関係の幅と深さが増した）ように思います。

今まで接点のなかった人から「AI関連のプロジェクトで、AIも去ることながらクラウド設計の部分でも協力して欲しいことがあるんだけど」と声をかけていただいた（これをきっかけに仕事になりました）

以前、同じプロジェクトを担当していた先輩から「当時は技術力があるなぁという印象はなかったけど、かなり深いところまでやってるんだね」と声をかけていただいた

興味や腕に覚えのあることを自分から発信することで、社内での認知度が上がり、その結果として新しい仕事にチャレンジすることができていることを考えると、やはり自分から発信し、いろいろなチャンスを掴んでいくことが重要だなと認識しました。

効果3 仕事の幅の広がり

これはコツなのですが、勉強会では絶対に完璧を目指さない方が良いと思います。例えば、以下のような要素を残しておき、それを発表してしまう、ということです。

ここまでは理解できたけど、ここから先はよくわからなかった
この実装の課題はこうで、その解決策は思いついていない
実装中にトラブってこんなエラーが出たけど、実は解決できなかった
そもそも、自分に足りないところはこういうことだとわかった

そうすると、わかる人が教えてくれたり、たまたま参加していた人が他の部署の人に繋いでくれたり、研修の機会を提供してくれたりします。そして、そこで得た知識やノウハウは、また別の機会の勉強会で発表をしたり、他部署と連名で発表したりするのです。

私の場合は、当時の業務でできていないことを明確にしたことで、管理職が別部署に繋いでくれ、その部署の方にメンター役を担ってもらい業務をやり切っただけではなく、これから、その方と一緒に新しい仕事を始めようとしているところです。

勉強会において、「わからない」「できていない」を残すことは、強力な武器になり得ることを理解して取り組むことが重要だなと、私は思います。

まとめ

勉強会に登壇するようになって仕事の幅も人脈も広がり、「会社って意外と面白いもんだな」と思うようになりました。余計忙しくなった気もしますが、その分充実しているということで、結果オーライだと思っています。

そういう意味では、きっかけを与えてくださったニフティ社の方には感謝しています。

今は社内での発表に閉じていますが、今後は社外への発表もしてみたいと思っているので、まずは社外の勉強会に今以上に積極的に出てみて、どんな雰囲気なのかを知り、どういうことができるのかを知りたいと思います。

もし、私と同じような境遇を経た方で、今は社外に向けていろいろ発表してるよ、という方がいれば、どんなふうにして社外向け発表の最初の壁を乗り越えたのかなど、経験談を教えていただけると嬉しいです。

この3ヶ月で得た、仕事におけるAI活用と、人間の役割に関する重要な気づき

Mon, 24 Mar 2025 00:00:00 +0900

この記事の内容は、あくまで私個人の見解であると同時に、仕事内容の詳細までを書くことはできないので、抽象的かつ意味不明な記載があると思いますが、悪しからずご了承ください。ただの仕事の感想文です。

職業柄、数多のシステム開発プロジェクトに関わってきたが、それでも過去に扱ったことのない技術領域で、短期間でやり遂げなければならない仕事をやっていたのである。

今回はシステム開発ではなく調査業務であり、キャッチアップ、課題設定、仮説設定・検証などを経て、成果をどうにか納めることができた。

これができた理由は、以下の3つがあると考えている。

ピンポイントの技術の詳細は把握していないが、周辺に対する問題意識を常日頃から持っていた。
色々な局面で使えるフレームワークを持っていた。
AIエージェント（Perplexity.ai）が使える環境にあった。特に、初期のリサーチで大活躍した。

こう考えた時に、1.と2.は人間だけができる仕事なのかなと思ったので整理しておくことにした。

人間の役割

常日頃から問題意識を持つ

自分の周りの事柄に対して、「どうしてこういう仕組みになっているのだろうか？」、「なぜ、こうしたのか？」、「自分ならこうするのに」といった問題意識を持つ。そして、その事柄に対して興味を持ち、調べる。

こうしたことの積み重ねが、「詳しくは知らないけれども、なんとなくわかる」ことの引き出しを増やすことに繋がっていく。引き出しは、いつの間にか他の引き出しと繋がり、これが独自性につながっていく。

これにより、キャッチアップにかかる時間が短くなり、また、課題設定もどことなく的を射るようになってくる。要するに、仕事の成功率が高くなるのである。

考えてAIエージェントを導く

ただ考えるのではない。ある程度の縛り（枠）がないと考えることは難しい。例えば、「渋谷についてあなたの意見を述べてください」と言われても、ただただ困惑するのみではなかろうか。

今までに、多くの頭の良い人たちが考えるための縛り（枠）を考えてきており、それらをフレームワークという。

フレームワークのメリットには3つあると考えている。

考える前段階で、考えるための枠をゼロから考える必要がない
考え忘れが減る
フレームワークを用途に合わせて組み合わせることで、より思考がクリアになる

まず、適当にAIエージェントに質問を投げる。そうすると、ディープリサーチを行い、回答を作ってくる。もっともらしい回答を作ってくるのだが、そこに偏りや検討漏れがないかを、フレームワークに当てはめて考えていく。

偏りを補正しつつ、検討漏れの部分をさらに問うていく。この繰り返しで、生成された回答の質を高めていくのである。

まとめ

「生成AIを活用するには？」という言葉が散見されるように思う（私の周りだけ？）。やれ、動画作成にはXXだ、プレゼンテーション作成にはXXだ、といった具合である。

今や色々なツールにAIが組み込まれており、適材適所で使えた方が良いということに反対するつもりはないのだが、ツールを使いこなすために必要な土台に考えを巡らせなければいけないのではないかと思ったので、この記事を書いた。

AWS SysOps Administrator - Associate合格記

Sun, 16 Feb 2025 00:00:00 +0900

先月、AWS Certified Solutions Architect - Professionalに合格しました。こういうものは、連続して受験してしまうのが、記憶が新鮮なうちに対策ができるので有利なわけです。また、Solutions Architect - Professionalも余裕（844点）で合格していたので、Associate資格で残っているSysOps Administrator - Associate（以下SOA）は、それほど手こずらずに取得できると思ったのです。

ところがどっこい、正直、過去一難しかったです。Solutions Architect - Professionalの時よりも感触が悪く、マジで落ちたと思った。

受験前の状態

CLF, SAA, DVA, SAPPro取得済み（SAProは844点）
AWSが出しているサンプル問題は、SAPPro合格後、対策を始めた時点で100%正解。

試験中の感想

一問目から分からねぇ・・・。

試験結果

789点。以下の分野は「改善が必要」でした。

第一分野：モニタリング、ロギング、および修復
第四分野：セキュリティとコンプライアンス

何が良くなかったのか

最初から自信過剰になっていた

AWSが出しているサンプル問題で、対策前に全問正解した時点で、正直「何もしなくても受かるかも」と自信過剰になっていました。SOAは特に難しいと聞いたことがあるので、その認識をきちんと持った対策をすべきでした。

ハンズオンをしなかった

今回、問題集を使っていて分からないサービスがあった時には、ブラックベルトも読まず、ハンズオンもしませんでした。結果、理解があやふやなまま試験に突入しました。

次、どうしようか

Solutions Architect - Professionalまでは、自分なりに「AWSの裏側ってこんな感じになっているのかな」とかを調べながら勉強していたので理解が深まったように思えますし、それが点数にも繋がったのだと思います。

SOAは、試験に合格するための勉強をしてしまいました。悪いことではないのですが、AWSを生業にしている人間としては、試験に合格することよりも試験勉強を通じてAWSを理解することを目的とすべきであって、その点においては同じ時間を使うにしてもだいぶ勿体無かった気がしていますし、点数もギリギリになってしまいました。

次はDeveloper - Professionalを受験しようと思っていますが、少し時間を長めにとって、ハンズオンやブラックベルトを通してAWSの仕組みをもう少しきちんと理解するようにしてから試験に臨みたいと思いました。

終わりに

今回、半額になるバウチャーを使ったとはいえ、受験費用は11,000円でした。安くはない試験ですので、きちんと自信を持って取り組むことができるように準備はしたいものです。

これで、以下の資格を取り終えました。

AWS Certified Cloud Practitioner
AWS Certified Solutions Architect - Associate
AWS Certified Developer - Associate
AWS Certified SysOps Administrator - Associate
AWS Certified Solutions Architect - Professional

参加者として勉強会の定着率（学習効果）を最大化する方法を考えてみた

Tue, 11 Feb 2025 00:00:00 +0900

先日、NIFTY Tech Day 2025に参加しました。

その中で、学習方法によって定着率が変わるという「ラーニングピラミッド」の概念を知りました。せっかく参加した勉強会、定着率を上げたいと思いますよね？

あまり時間をかけず、定着率を上げるための方法を検討してみたので、共有させてください。

きっかけ

私は手書きでメモを取る派でした。いろいろな意見があると思いますが、私が考える手書きメモの最大のメリットは自由であることです。前後左右、自由に構造化できますし、関連を線で表現することもできます。

その一方で、分からない言葉が出てくると、スマホや辞書などを使って調べて、調べた結果をメモに書くことになります。この方法では、分からない言葉が多発してくる場合に、いささか不便です。

ふと思い浮かんだのは「マインドマップを使ってメモを取れば良いのでは？」というありきたりな考えです。手書きメモに近しい自由度で書くことができますし、分からない言葉はその場でAIに聞き、回答をマインドマップに反映することができます。

今回、勉強会中のメモは手書き、勉強会後のまとめにはNotionを使いました。分からない言葉は手書きメモに印をつけておき、NotionでまとめるときにNotion AIに聞きながら整理しました。AIを勉強会中に使えばもっと効率的、効果的だったのでは、と思いましたが、手書きメモ、およびマインドマップとAIの組み合わせでは、どちらの方が定着率が高まるのかが分からない状況でした。

定着率を高めるには（ラーニングピラミッドによる「他者への教授」）

そこで出てくるのがラーニングピラミッドです。学習方法によって定着率が変わるということを示すもので、定着率が低いもの、高いものにはそれぞれ以下があります（括弧内は定着率）。

定着率が低いもの　講義（5%）、読書（10%）、視聴覚（20%）
定着率が高いもの　グループ討論（70%）、実践・体験（75%）、他者への教授（90%）

勉強会は「講義」でしたので、これを「他者に教える」ところまで持っていくことが定着率を高める上で有効であると考えました。

とはいえとはいえ、時間がなければ機会もそう恵まれるものではない

とはいえとはいえ、の元ネタ。

勉強会に出るところまでが精一杯で、その後、内容を整理して、その上、人に教えている時間まではない、というのがほとんどではないでしょうか。私は、過去に何回も勉強会に参加したことはありますが、その場でメモを取る程度で、勉強会の後に整理し、さらに人に教える、ということはやったことがありませんでした。そのメモも、どこへ行ったかわかりません。

とはいえ、ラーニングピラミッドが示すように、人に教えるということの効果は無視できるものではありません。

まず考えたのは、人に教えるということです。会社の勉強会はあるにはありますが、スケジュールが微妙な時があります。それに、そもそも適した勉強会がなかったりします。そこで、「noteでもどこでも良いので、勉強会の内容をシェアするということをやってみてはどうだろうか？」ということです。インターネットであれば、時間の制約なくいつでも見てもらえるので、「人に教える」ことの代替手段になるのではないかと考えました。

ここでポイントになるのは、内容を整理するところにかかる時間をいかに短縮できるか、です。

まず、人に教えるためには自分が理解していなければいけません。勉強会終了時点で、自分の頭の中が構造化されており、不明な言葉がない状態になっていることが理想です。そのために最も重要なのは「勉強会中に分からないことを解消しておく」ことです。常にAIに触れるようにしておき、分からない言葉が出てきたらAIに調べてもらうのです。それでも分からないことは質問してみましょう。勉強会が終わるまでに内容を理解しておくことが大切です。

次に、すぐに共有できる状態にしておくということです。先ほど「noteでもどこでも良いので」と書きましたが、共有先はインターネットです。その際、扱いやすいデータは共有に使うプラットフォーム次第ではありますが、私の場合はnoteを使っているので、Markdown形式が最も扱いやすい形式です。note以外にも、NotionやGammaもMarkdownをサポートしています。

人に教えられるように理解したトピックを、Markdownのように自分が扱いやすいデータにしておく。これが時短しながら内容を整理するために必要なことだと考えます。

実例と改善点

メモをメモ帳で取る @ 勉強会中

今回

今回は、勉強会のメモを手書きで取りました。いくつか分からない言葉がありましたが、その言葉には後で調べられるように印をつけておきました。

今後

このプロセスは必要ありません。手書きでメモを取るということは、それをデジタル形式に変換する必要があるということで、その手間がかかります。今後は、はじめからマインドマップにメモを取ろうと考えています。これも後で整理する必要がある点で手書きメモと変わりませんが、コピペができる分、手間は省けます。

整理しながらNotionに転記する @ 勉強会後

今回

勉強会が終わった後、メモ帳に書いたメモをNotionに転記しました。後から見返してもわかるように記述すること、先に印をつけた言葉を調べました。この時に、Notion AIが大活躍しました。時間にして約1時間程度はかかりました。

復習にもなるので良いプロセスだとは思いますが、本質的には不要なプロセスです。なぜなら、メモを整形するという過程において定着率は上がらないからです。分かっているものを読んでも学習効果がないのと同じです。

今後

Miroのマインドマップでメモをとり、その裏で言葉をすぐに調べられるようにperplexity.aiでも動かすことにして、今後はこのプロセスは廃止したいと考えています。

Notionからnoteに転記する @ 勉強会後

今回

勉強会の情報は、タイトル、開催日時、場所、そして先にまとめた勉強会の内容をNotionに集約しています。今後も、この取り組みは続けていきたいと思っています。

今後

今後は、勉強会ごとに作ったマインドマップをNotionに取り込んでおくことにしたいと思います。

そして、マインドマップをもとにnoteに掲載する記事を執筆します。このプロセスは、自分用のメモから、人に教えるための記事を起こすことになるので、読みやすく、わかりやすく記載する必要があります。このプロセスは脳を活性化しますので、定着率の向上に貢献します。しかし、マインドマップであらかじめ視覚的に構造化していますので、まっさらな状態から記事を起こすよりも時間はかかりません。

ここで書いた記事は、noteに掲載します。Notionにまとめている勉強会の情報には、noteのURLも記載しておきます。こうすることで、自分用のメモと、人への共有に使った記事の両方が勉強会の情報から参照できるようになります。

NotionからGammaに転記する @ 勉強会後

今回

noteの記事をGammaにコピペすれば、ある程度の形になってプレゼンテーション用の資料が作られました。適当に手直しをし、保存しておきます。Gammaの共有リンクを、Notionに記録している勉強会の情報に追記しておきます。

終わりに

今回書いていて思いましたが、マインドマップでメモをとるということは、マインドマップの外にある情報（過去のマインドマップ）とリンクを直接的に取る方法がない、ということになります。この点、メモはトピックを超えて相互参照しやすいというメリットはありそうです。この点をどう運用するかは今後考えなくてはと思いました。

そもそも思いましたが、勉強会中にパソコンを立ち上げていると、後ろの人から覗き見されて「そんなことメモしてるのかよ」と思われそうだなと思いました。

参考

手書きメモの一部。これをMarkdownに変換するのは結構めんどい。

この記事のマインドマップ。このように構造化し、関連を線で表現すれば手書きメモ並の自由度は得られそう。

手書きメモをMarkdownに変換し、それをGammaでスライドに変換したもの

NIFTY Tech Day 2025で思ったことと職場への持ち帰り

Sun, 09 Feb 2025 00:00:00 +0900

2025年が始まってもう1ヶ月が経過しましたが、皆さんはもう勉強会やセミナーには参加していますか？

私は年初に「個人として毎月1回以上、勉強会に参加する」という目標を立てました。そして、NIFTY Tech Day 2025が今年初めての参加でした。参加によって刺激を受け、インターネットに学んだことをアウトプットすることも目標に加わりました。

ここでは私の感想と、職場への持ち帰りと実践をどう考えているかを記述したいと思います。

勉強会の学習効果を高めるにはどうしたらよいかを考えてみました。こちらも参考にしていただけると嬉しいです。

この勉強会を機に、自身も勉強会に登壇するようになりました。その結果、仕事が大きく変わったので、その経験談を書いてみました。こちらも参考にしていただけると嬉しいです。

AIと協働する次世代開発スタイル - 求められる新たなスキルと役割の変化

AIと人間が協働するステージには3段階がありますが、現在最も高度とされるのは「エージェント型AIとの協働」です。エディタに生成AIが組み込まれるようになったことで、以下の3つの形態で進化してきました。

文脈を理解し、適切なプログラムコードを補完する「自動補完型」
プロンプトを通じて対話形式でコードを生成する「対話型」
目的達成のために必要な作業を実行する「エージェント型」

一部（社内）では「生成AIによってシステムエンジニアの仕事が減少する」という意見もありますが、私はむしろ「やるべきことが増え、専門性が一層求められるようになった」と考えています。その理由は、生成AIの性能向上に伴い、人間がAIの生成物をレビュー・承認する作業の難易度が高まっているからです。このプロセスでは、必ず人間がボトルネックになります。

生成AIを効果的に活用するためには、レビューしやすい出力を得られるようAIをコントロールするスキルが求められます。また、レビューには知識が必要であり、そのためにカバーすべき領域が広がることや、チームで協力して対応する重要性も増しています。

こうした状況を踏まえると、「オープンソースの知識を深く持つ優秀な人材がチームに加わり、その生成能力で他メンバーに影響を与えている」という現実を、いかにコントロールして良い方向へ導くかが課題になると感じており、対応が必要だと認識しています。

さらに、「インナーソース」という概念は初めて知りました。これは企業内でオープンソース活動を展開する取り組みです。生成AIがプロプライエタリなソースコードではなく、オープンソースコミュニティの成果物から学習しているという事実に基づくと、オープンソースコミュニティの流儀やスタンダードを組織内に取り入れるかどうかが、生産性向上の鍵となる可能性があります。

エンジニアの殻を破る：インナーソースと社外活動がもたらした成長

「インナーソース」をニフティ社内で展開した功労者の方による講演でした。この取り組みはエンジニアだけでなく、ビジネス部門も巻き込み、ビジネス部門のメンバーがシステム設定ファイルの一部をプルリクエストで更新できる仕組みも構築したとのことです。また、次のトピックでも触れられていましたが、「将来的にメリットが学習コストを上回るなら、学習してもらう」という姿勢は非常に参考になると感じました。

特に印象的だったのは、「社外活動は話を聞くところから始めよう。社外の勉強会に参加し、アウトプットしていこう」というメッセージです。講演者自身も、インナーソースについては勉強会への参加からスタートし、人脈を広げていったと語っていました。この姿勢を見習い、自分も積極的に行動しなければと感じました。

自社製CMSからの脱却：10件のWebサイト再構築に学ぶ運用重視の技術選定

レガシーシステムの更新を組織課題として捉え、将来を見据えたアーキテクチャ設計と必要な教育を実施した結果、過去に何度も失敗してきた切り替えに成功したとのことです。プロトタイプを作成しながら設計を改善し、最終的には運用面も含めて高評価を得る設計に仕上げたそうです。

また、更新前のシステムと比較してリードタイムが短縮され、新規サイトの投入スピードも向上したため、IT部門とビジネス部門の双方にメリットがあったようです。

さらに、コンポーネント名の統一によって、生成AIが設計意図を正確に理解し対応できるようになった点も興味深いポイントです。特に詳細設計では、明確な目的意識を持った設計が重要であることが改めて示されました。

スクラムマスター入門者のための学習マップ効果的な学びと実践

スクラム開発を経験したと口にしながらも、「複雑なものへの対応」の仕組みについては知らなかったことに改めて気づきました。私が経験したのは、仕様が明確に定まらないためにウォーターフォールではなくスクラムを採用したというケースでした。

実際、スクラムには「技術・実装」「プロダクトとビジネス」「人と組織」「改善」の4つの象限が存在し、これらは独立しているのではなく互いに重なり合っています。それぞれ、開発者、スクラムマスター、プロダクトオーナーといった各役割が注目すべきポイントも異なります。

これまで自分が抱いていたスクラムマスター像とは異なる面があり、より深く学ぶほどにその役割の奥深さと面白さに気付かされました。

SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップに書いてありますが「組織改革に立ち向かうあなたに知恵と勇気を与えます」とあるとおり、開発自体の話ではなく、もっと広い範囲の話であると認識しました。無知は恐ろしいと改めて思い、また興味があるのでもっと調べてみようと思います。と思っていたら、野中先生も本を書いていらっしゃる。アジャイル開発とスクラム第2版顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

学びを文化に変える〜ニフティの内製研修と継続的成長の仕組み〜

ラーニングピラミッドの中でも、学習定着率が高いとされるアクティブラーニング（「グループ討論」「実践・体験」「他者に教える」）を、ニフティ社内の内製研修で実践しているとのことです。特に興味深かったのは、研修の参加方式として「オプトアウト方式」を採用した点です。これは、研修を基本的に「参加」とし、「欠席」の場合のみ事務局に連絡する仕組みで、この変更により参加率が1割から7割にまで向上したそうです。

私自身もアクティブラーニングを社内勉強会で活用してみたいと感じました。また、社内勉強会を高度化させることに抵抗がある人に向けては、社内ブログのようなプラットフォームを構築するのも面白いアイデアだと思いました。これにより、後から情報を検索しやすくなるだけでなく、講師役を避けたい人にも知識共有の選択肢を提供できるのではないかと考えています。

社内SEとしての進化：AIツールを活かすネットワークエンジニアの新たな挑戦

エンジニア不足の話は私もよく耳にしますが、セシール社でも同様に人手が足りない中で、業務効率の低下やコミュニケーションの課題、セキュリティリスクの増加といった問題を抱えているとのことです。これらの課題に対して、情シス部門の規模に適した形で解決策を模索していく必要があると感じました。

具体的には、ナレッジマネジメントを活用して「人に聞く頻度」を減らす効率化や、紙運用を削減するためのAI-OCR導入、さらにセキュリティログ監視へのAI活用などが挙げられていました。事業会社のIT部門にはこうした多岐にわたる取り組みが求められ、大きなやりがいがあると感じながらお話を拝聴しました。

終わりに

大変貴重なお話をお伺いさせていただいたと思っています。また来年も、ぜひ参加させていただければと思いました。

後日追記

勉強会での学習効果を最大化する方法を考えました。

Apple Watch Ultra 2で思考と行動が整理できた話

Sun, 26 Jan 2025 00:00:00 +0900

ある程度、Apple Watchの使い方に慣れている方を対象にしています。

思考と行動の関係と本記事の結論

前提である「思考と行動の関係」を整理したいと思います。人それぞれ色々な考え方があると思いますが、私が考える思考と行動の理想的な関係は以下の図に示すものです。

このように「思考と行動の間に2つの袋を置くことで、思考と行動はスムーズに連係する」というのが私の考え方です。それぞれの袋をわかりやすく表現すると以下のようになります。

忘れないための袋:　メモアプリ（Draftsなど）
行動するための袋:　カレンダーアプリ、リマインダーアプリなど

本記事が最も言いたいことは、以下の3点です。

2つの袋は、完全にデジタル化する。
「忘れないための袋」はDraftで管理し、取りこぼしなく集約するために、Apple Watch Ultra 2から音声入力で情報を記録する。
「行動するための袋」は、情報の種類に応じてカレンダー/リマインダー/Notion/今日の支出で管理し、「忘れない袋」を定期的に確認してそれらに移す。

以下で詳細を示します。

2つの袋は整理されていなかった

まず、2つの袋は管理されていませんでした。具体的には以下の状態でした。

忘れないための袋　Moleskine、Onenote、Notion、付箋紙、iPhoneのメモ
行動するための袋　Google Calendar、iCloud Calendar、紙のカレンダー、付箋紙、iPhoneのリマインダー、Todoist、Omni Focusなど

こうした状況でも、仕事や日常生活に支障は出ていませんでした。散らばっていても、その様は本人が一番よくわかっているということです。一番の問題は、「やりたいことができなくなっていた」ことです。情報が散らばっていると、情報の格納と検索で脳が疲労状態になります。そうすると、何をすれば良いのかが段々とわからなくなってきます。夢やビジョン、趣味に向かって計画し、実行できている実感が薄れてきます。

今まで、何度かこうした管理を徹底してきましたが、少し油断すると上記のような状態になってしまうのが常でした。改善しなければと考えていた時、Apple Watch Ultra 2のアクションボタンのことを思い出しました。「うまく活用できれば、思考と行動の理想形を実現できるのではないか」と考え、Apple Watch Ultra 2を購入し、改善に取り組みました。

改善後

それぞれ、以下のように整理をしました。

忘れないための袋:　Draftsに音声入力する。
行動するための袋:　Draftsに登録されたメモを識別・分類し、予定はGoogle Calendar、タスクはリマインダー、メモはNotion、支出は今日の予算に登録する。

実現できた理由はApple Watch Ultra 2によるものが大きかった

これが実現できた理由には、大きく直接的な理由と間接的な理由の2つがあります。

まず、直接的な理由はApple Watch Ultra 2を購入したことです。画面サイズが大きく、処理性能が高いので、ショートカットやアプリを画面上に多く配置できたり、音声入力の精度やアプリの起動速度に不足はありません。

次に、間接的な理由で、これには2つあります。

1つがリモートワーク環境になったことです。これにより、仕事中でも音声入力ができるようになりました。同僚から予定が送られてきても、Draftsに音声で予定の情報を入れておけば良いのです。

もう1つが、Siriやアプリを活用しやすくなったことです。これはApple Watch Ultra 2の画面サイズや処理性能の高さに関連するものですが、音声認識が速くなったことでSiriが使いやすくなっていますし、アプリに関しては文字が見やすくなったり、起動速度も申し分ありません。

そして、Apple Watch Ultra 2のアクションボタンです。物理的なボタンが具備されており、それを押下すると、あらかじめ設定したアプリが起動します。私はこれにDraftsを起動するショートカットを割り当てています。起動する敷居が高いもの（ネガティブ感のあるもの：お金や体重管理など）をアクションボタンに割り当てると、そうしたものも管理しやすくなるかもしれません。私は、Apple Watch 10も所有していますが、物理ボタンの利便性は極めて高いです。

ワークフロー

ここでは、私が試し、改良しているワークフローを紹介します。

思考で得た情報は、まず1つの袋に入れる

2つの重要なこと

1つは、自分に降りかかってくる情報に対して、反応的な行動をしないことです。スマホを見ていると、通知が多く送られてきます。それに反応しているうちに1日が終わってしまった、ということもあるのではないかと思います。通知を受けて即、行動しなければならないものはほとんどなく、いちいち反応していては時間がいくらあっても足りません。まずは、情報を「忘れないための袋」に入れ、対応は後で考えるということを原則にした方が良いと考えています。

もう1つは、分類しないことです。ここでの目的は、とにかく全ての情報を1つの袋に入れることです。情報の分類は脳の負担が大きい行為です。これをしてしまうと、1つの袋に情報を入れることが面倒になり、やらなくなります。そうして待っているのは、管理不能な状態で、日常に追われる毎日です。

「忘れないための袋」に情報を格納する

ここでは、Draftsというアプリを使います。このアプリのコンプリケーションをApple Watchのフェイス画面に設定します。そして、これをタップすると、すぐに音声入力ができる状態になります。

使い方は以下のサイトに詳しく書いてありますので、ご参考になさってください。

すべてのメモの入り口を「Drafts」にすれば迷いがなくなる

「忘れないための袋」に入っている情報は、定期的に識別・分類し、別の袋に移すか捨てる

この時点で、「忘れないための袋」に入っている情報は玉石混合です。これらの情報が何なのかを識別し、適切な場所に移します。例えば、「2月25日17:00　山田さんと打ち合わせ」という情報が入っていたとすると、これは予定に分類できます。このほかに、私は以下の4つに分類しています。

予定
タスク
残しておくべき価値のあるメモ
支出

個人的な感覚として、これ以上増えると利用するツールが増えてしまうので、5つくらいまでに押さえておいた方が良いのではないかと思います。

そして、分類ごとにツールを選びます。私の場合は、予定は「Google Calendar」、タスクの場合は「リマインダー」、残しておくべき価値のあるメモは「Notion」、支出は「今日の予算」で管理していますので、Draftsからそれぞれのツールに転記していきます。

このように、全ての情報は「忘れないための袋」（Drafts）に格納した後、識別・分類し、予定/タスク/残しておくべき価値のあるメモ/支出は、「実行するための袋」（Google Calendar/リマインダー/Notion/今日の予算）に格納され、維持していくことが重要です。

さらに、タスクについては、リマインダーの中にinboxという、何も整理されていないタスクを入れる場所を作っています。それらのタスクは、GTD（Getting Things Done）というメソッドを使って管理しています。詳細を知りたい方は以下のサイトを参考にするとわかりやすいと思います。

コツ

「忘れないための袋」から「実行するための袋」に移す敷居を下げる　タスクの場合は「インボックス」など、何でも受け入れる袋を作っておくと、まずはそこに移せば良いことになるのでおすすめ。

面倒でも毎日、袋分けをする　量が増えると手がつけにくくなり、管理不能になる。

同時に複数のツールを使わない　例えば、カレンダーにGoogle Calendarを使うと決めたら、しばらくはそれを使い、他のカレンダーツールは使わない。どっちに書いたかわからなくなり、情報が分散してしまうため。完全に移行する場合なら大丈夫ですが、同種のツールを並行して使うのは絶対にやめた方が良いです。

体系的に整理されたものを学ぶ　GTDは、結構前から整理されたタスクの管理手法なので、それを学ぶことで自分のやり方にカスタマイズしていくと運用がうまく回るようになる。

後から検索できる、そしてApple Watchなどに通知されるツールを使う　可能な限りデジタル化することが望ましい。アナログの場合は、検索や通知の面でデジタルに劣るため。

この結果、2025年にどのような成果を得たか

2025年1月から2月23日までの成果です。

以下の資格を取得しました。
- AWS Solutions Architect Professional - Professional（2025年1月）※2024年12月頃から勉強してました。2025年1月の勉強計画は、この記事の方法で対応したということで記載しています。
- AWS SysOps Administrator - Associate（2025年2月）
18冊の本を読みました。
縁あって、4月から念願だった大学院（MBA）に単科生として通うことになりました。

これらは、日常のごちゃごちゃしたものを整理し、やりたいと思っていたことにリソースを使うことができるようになったからに他なりません。

よかった点

2つあります。

1つは仕組み化ができたことにあります。これによって、情報の取りこぼしがなくなり、情報がどこに格納されているのかも把握された状態になるため、自信につながりました。また、物事を忘れなくなりました。厳密にいうと、自身の脳ではなく外部の脳が記憶し、後から探すことができる状態になっている、あるいは必要な時に通知される状態になっています。

もう1つは、やらないことが増えた点です。思考は、「忘れないための袋」と「実行するための袋」を経て、実行されることになります。その過程で、意味不明なタスクやメモなどを消すようにしたため、残ったものは確実に実行できるもの、そして価値があるものになります。その結果として、1つのことに投下できる資源が増え、質が上がり、短時間でも大きな成果を出すことができたと考えています。

改善したい点

3つあります。

1つは、袋間の移動を手動にしている点を省力化したいと考えています。手作業で行うと、作業ステップが増えるため、間違えたり、そもそもが面倒になったりします。Draftsのプレミアムプランに申し込めば「アクション」というものが使えるため、それを使って省力化できないかと考えています。

次に、音声入力できない場面での対応です。音声で入力できない局面はどうしてもあります（電車や職場など）。そうした場面で、効率よく、取りこぼしなくメモが取得できないかを考えたいと思っています。

最後に、アナログとの統合です。以下の記事でも書きましたが、マインドマップを使う方法によっても、なおアナログの利点には敵わないと考えています。アナログメモをどう扱うかはよくよく検討する必要があります。

AWS Solutions Architect - Professional合格記

Sun, 26 Jan 2025 00:00:00 +0900

対象としている読者の方

受験対策中のITエンジニアの方で，私と同じく「何をどこまでやればよいのかが分からない状態」で，不安に思っている。
自分が合格水準にあるのか，受験日を決めるために目安を知りたいと思っている。

執筆者の経歴

システムインテグレータ所属のSEです。AWS関連の認定は以下の通り受けています。

AWS Certified Cloud Practitioner, 799点（2021年）
AWS Certified Solutions Architect - Associate, 822点（2022年）
AWS Certified Developer - Associate, 834点（2023年）
AWS Certified Solutions Architect - Professional, 844点（2025年）

実務ではAWSを検証に使用しており，また，個人プロジェクトでもAWSを使っています。

好きなAWSサービスはAWS CDKです。

免責事項

この記事は，無償/有償部分問わず，私の経験や理解を記載したものであり，合格や正確性を保証するものではありません。最終的には，AWS公式ドキュメント等をご確認いただき，ご自身でご判断いただくようにお願いいたします。

勉強の順番

私は以下の順番で教材を勉強しました。どの教材も，受験にあたっては必須だと思いました。今回，Blackbeltは参照しませんでした（Associate試験のときにだいぶ読み込んだので、大丈夫だろうという驕りがありました）。

『AWS認定ソリューションアーキテクト－プロフェッショナル　試験特性から導き出した演習問題と詳細解説』
AWS Certified Solutions Architect - Professional (SAP-C02) 試験問題サンプル
AWS公式模擬試験
問題集①「2024年版！最新のソリューションアーキテクトプロフェッショナル試験に対応した模擬問題集です。同じ出題形式の本番レベルの問題と，参考URLを含む詳細な解説で構成されており，効率的に確実合格を目指すことのできる問題集です」(Clouds Starterさま)
問題集②「AWS認定ソリューションアーキテクト - プロフェッショナル(SAP-C02)試験対策の決定版！」(Maruchin Techさま）

勉強方法

事前に

『科学的根拠に基づく最高の勉強法』（安川康介著，KADOKAWA）を読み，効率的な勉強方法を学ぶことをおすすめします。私の場合，この本の方法で暗記物は時短できました。

本を2周し，必要な知識をたたき込む

『AWS認定ソリューションアーキテクト－プロフェッショナル　試験特性から導き出した演習問題と詳細解説』を読み，章末問題，および模擬問題を解きます。章末問題，模擬問題は最低，2周は解きます（1周目は誤答の洗い出し，2周目は1周目の復習効果の確認）。

現在の実力を知る

現在の実力を把握しておきます。

試験問題サンプル（5割を越えたら2週間後に試験日を設定）
公式模擬試験（8割を越えたら1週間後に試験日を設定）

勉強期間中に，定期的にこれらに取り組みます。私の場合は，1週間に1回取り組み，試験問題サンプルが5割を越えたら2週間後に，公式模擬試験で8割を越えたら1週間後に試験日を設定することにしました。

演習と知識獲得

ここからは，演習と知識獲得を繰り返します。

問題集①を1周する。間違えた問題を中心に復習する。
問題集①を試験分野ごとに全問解き直す。この段階では，誤答が多いと思います。1問に時間がかかるので，1回あたりの負荷を減らすために試験分野ごとの解き直しをしました。

試験分野ごとの正答率が7-8割に達したら，次に進みます。

問題集②Practice Test No.1とNo.2を2周する。間違えた問題を中心に復習する。復習後，間違えた問題のみ回答する。Udemyには間違えた問題のみを解答する機能は無いので，Excelで管理します。
問題集②Practice Test No.3～No.5を1周する。間違えた問題を中心に復習する。復習後，間違えた問題のみ回答します。

間違えた問題のなかで正答率が8割に達したら，次に進みます。

試験問題サンプルを解く。

公式模擬試験を解く。両者とも8割に達していれば，合格を狙うことができる水準に達していると思います。

重点的に学習した方がよいと思われるポイント

特に重要なサービスについて，押さえておいたほうがいい部分やユースケースなどを考えながら覚えた箇所について，私の覚え方をご紹介します。

ここまでの対策を行っていれば自ずと導き出されるポイントです。ご参考までに。

★★★★★（超重要）

Solutions Architect - Professionalで頻出のサービスのため超重要であると考えています。

PrivateLinkの構成サービス提供側の構成（リソース - NLB - エンドポイントサービス）と，それに接続する側の構成（リソース - インタフェース型VPCエンドポイント），および接続承認の方法（自動か手動）を把握しておきます。
Transfer Familyの種類，接続方法，ストレージの種類オンプレミスで構築，運用しているSFTPサーバを，AWS Transfer Familyを使って移行する場合に，接続元の機器や運用に変更を与えないようにするためにはどのように構築したらよいかを考えます。AWSに自社のIPアドレス範囲を持ち込み（BYOIP），BYOIPプールからElastic IPを作るという方法を考える必要があります。
Direct Connectの接続ルートと，仮想インタフェースの使い分けオンプレミスに設置するCustomer Gatewayから，Direct Connect LocationのCustomer Router，Direct Connect Routerを経てAWSに接続するルート，およびDirect Connect Routerから先のPrivate VIF(Virtual Interface)，Public VIF，Transit VIFのそれぞれの向き先を把握しておきます。関連して，Site-to-Site VPNでTransit GatewayやVPCに直接接続する方法も覚えておきます。これらは必ず絵に描けるようにしておくようにします。
また，地味ですがオンプレミスからS3等にアクセスする際に，ゲートウェイ型VPCエンドポイントは利用できず，インタフェース型VPCエンドポイントが利用できるのはなぜだか確認しておいたほうがよいです。前者はトラフィックをルートテーブルで制御，後者はENIで制御しており，VPC内部の名前解決を利用しています。ですので，インタフェース型VPCエンドポイントのみ，オンプレミスからアクセスできるのです。また，オンプレミスからインタフェース型VPCエンドポイントを経由してS3等にアクセスする場合，VPCのEnableDNSHostNamesとEnableDNSSupportの有効化が必要です。実態はPrivate Linkなので，Private Linkを使う場合にもそれらのオプションを有効化しておく必要があります。
VPC内のリソースからオンプレミスサーバの名前解決を行う方法，またその逆Route 53 ResolverによるDNSリクエストのフォワーディングルール，アウトバウンドエンドポイントの設置などを把握しておきます。これも絵を描けるようにしておきます。
Active DirectoryまわりSimple AD，AD Connector，AWS Managed Microsoft ADのユースケースを押さえておきます。対応しているサービス，MFAの要否，シングル vs マルチドメイン，フォレスト構築の要否によって使い分けを行います。また，AD Connectorはサブネットに配置するので，冗長化構成を取る必要があるのかないのかをよく考える必要があります。
移行系ツールの使い分けMigration Hub，Migration Evaluator，Application Discovery Serviceなど。

AWS Organizations周りについて、以下をよく把握しておきます。

SCPの目的と割り当て，タグポリシーの有効化，および必須タグをつけていないインスタンスをSCPで起動させないようにする方法
OUを分割し，元々のOUにいたメンバを新しいOUに持って行く際のオペレーションの方法
3つのガードレール（予防的・検知的・プロアクティブ）と実現方法（SCP・Config・CloudFormation Hooks）
Reserved Instanceの共有をオフにする方法（各OUに購入を許可していても，共有設定は組織の管理アカウントで行う必要がある）
AWS Resource Access Manager(RAM)で共有できるリソースには何があるか。

★★★（重要）

Solutions Architect - Associateでも問われる内容ですが，もう少し深い理解が求められます。

Route 53のルーティングポリシー混乱せずに覚える必要があります。特に3つのルーティング方式（位置情報ルーティング/地理的近接性ルーティング/レイテンシルーティング）は，特性を覚え，使い分けができるようにしておくことが重要です。
トラフィック課金の範囲リージョン間，AZ間，AWS内から外への通信は課金されますが，PrivateLinkとTransit Gatewayを使った同一リージョン内のAZ間通信の場合は，それぞれ時間単位料金とデータ処理料金の課金が行われます。
CloudFrontを媒介してオリジンにアクセスする経路でLamdbaを使うパターンとCloudFront Functionsを使うパターンではどう違うかビューワーリクエスト，オリジンリクエスト，オリジンレスポンス，ビューワーレスポンス。CloudFront FunctionsではHTTPヘッダの書き換えが可能。Lambdaは，ユーザが送信した画像をリサイズしてS3に格納する場合などに使います。
CloudFrontのフィールドレベル暗号化が必要になるユースケースと，RSA公開鍵・秘密鍵の紐付け先EKS等で，特定のPodのみがユーザから送信されたデータを参照できるようにするユースケースが想定されます。RSA公開鍵をCloudFrontに紐付け，公開鍵で暗号化。復号するオリジン側に秘密鍵を紐付けます。
ELBのターゲットグループとしてのIPアドレスタイプのユースケースus-west-1にアプリケーションをデプロイしている。日本にサービスを展開するにあたって，ap-northeast-1に同じアプリケーションをデプロイせず，コストを削減したいとします。このような場合に，ELBへの着信トラフィックの向き先をus-west-1のELBに向けるのがIPアドレスタイプのユースケースの1つです。
VPCまたはサブネットのCIDRが重複している場合の対応方法再設計，Private Linkを使って接続，NAT変換によって接続，セカンダリVPCを通す方法の4つがあります。
フェイルオーバーの方式の違いCloudFrontのオリジンフェイルオーバー，Route53のフェイルオーバールーティング，ELBのフェイルオーバーのユースケースの違いを押さえておく必要があります。関連して，Elastic IPのスワップ，4つのDR戦略（バックアップ・リストア，パイロットライト，ウォームスタンバイ，マルチサイト）の違いも押さえたほうがよいです。

★（そこそこ重要）

覚えればよいだけのものをここにまとめました。

クロスアカウントの実装方法
EC2/Lambda/Fargate/SageMakerの割引プラン。Reserved InstanceとSavings Planの違い
AppStream2.0のフリートの種類，インスタンスタイプ，スケーリングポリシー
VPCプレフィックスのユースケース
FSx for LustreとS3を組み合わせた遅延ローディングのユースケース
API Gateway REST APIで連携可能なAWSサービス

Grand Seikoを買った

Sun, 14 May 2023 14:43:18 +0000

セイコー社を信頼している

思えば、セイコー社との付き合いは長い。成人のときに購入してもらったセイコー5（7S26）、就職祝いに購入してもらったクロノグラフ（7T62）。いずれも10年以上使っている。

さすがに調整もかねて修理に出さねばと思っていたが、どこに依頼するかとは思案のしどころであった。近所に時計店は無いうえ、節目節目での大事な時計であるがゆえ、大手家電量販店の時計修理に出すのも気が引ける。なぜなら、彼らは時計専門では無いからであり、結局取次だろう。どこに取り次がれるのか分からないあたり、聞けば教えてくれるのだろうが不安ではある。しからば、セイコー社に修理してもらおうと思った次第である。

さすがに10年を過ぎた時計なので、修理ができないか、できるにしても高額になるだろうと予想していたが、それはいい意味で裏切られた。クロノグラフは全体的な修理・調整を依頼して約2万円。セイコー5は今、オーバーホールに出しているがバンドを新品に交換して約1万円。さすがにオーバーホールには時間がかかり、またバンドの手配に時間を要していることから2か月程度時間がかかっているが、クロノグラフのクォーツは2週間程度で修理・調整してくれた。10年を超えても、普通に修理してくれるあたりさすがだと思う。

サンプル数2であるが、こういう経緯があって、私はセイコー社のアフターサービスを信頼している。ほかのメーカーも同じなのかも知れないが、私は修理までしてもらったことはないのでよくわからない。

そしてGrand Seikoへ

いずれ、「きちんとした」腕時計が欲しいと思っていた。「きちんとした」というのの私なりの定義はこんなところである。

3針であること。
駆動方式は機械式であること。理想は、自動巻きではなく手巻きで、ノンデイトであること。
煌びやかでなく、目立たないこと。
製造工程が可視化されていること（工場を見ようと思えば見学できること）。
修理の体制が整っていて、長く使えること。
大きくとも直径40mm以内であること。
国産であること。

日本にはセイコー社のほかに、シチズン時計社やオリエント時計社といった時計メーカーがあるが、あいにくそれらのメーカーの時計を購入し、修理までを受けた経験はなかった。シチズン時計社のザ・シチズンや、オリエント時計社のメカニカルムーンフェイズ等は実に興味深いところであったが、上記の経験から、自分にとってはセイコー社しかなかった。なお、国産であることの理由は、単純に検討の選択肢を増やすのが面倒くさいということである。

結局、購入したのは「SBGR315」というモデルである。私にとっての「きちんとした」を、手巻き・ノンデイトを除いて満たしている。妥協した理由は、店員から秒針加工技術の話を伺ったことと、金属バンドの装着感が良かったことである。革バンドのモデルもあったが、ちょうどこれから暑くなっていく時期でもあったので、外した。

購入してから

「この腕時計の何が良いのか？」と聞かれたときに、いろいろな答えが出るんだろうと思ったが、実際には答えられないというのが実感である。自分にとって「きちんとした」時計である、というのが答えになるかと思ったが、実際にオーナーになると、この時計に特筆すべき良さは無いと思う。だが、これが左腕に付いていないと、しっくりこないというか、違和感を感じてしまう。そういう意味で、自分にとっては時間に関するパートナーを得たようなものであるからして、パートナーの良し悪しを尋ねるのもナンセンスというものだし、そんなものに答えることは難しいことであるがゆえ、先の質問に答えが出ないのだろうと納得している。

AWS Certified Developer - Associate (DVA-C01)に合格した

Mon, 13 Feb 2023 12:26:36 +0000

AWS Certified Developer - Associate (DVA-C01)に合格しましたので、その記録を書いておきます。

好きなサービス

とりあえず書いておきます。好きなサービスはAmazon S3です。

遍歴

2021年11月 AWS Certified Cloud Practitioner（CLF-C01）取得（799点）
2022年04月 AWS Certified Solutions Architect - Associate（SAA-C02）取得（822点）

そして今回、AWS Certified Developer - Associate (DVA-C01)に合格しました（834点）。これでAWS資格3冠、アソシエイト資格2冠ということになります。

勉強方法

使った資料

ポケットスタディ AWS認定デベロッパーアソシエイト
AWS 認定デベロッパーアソシエイト模擬試験問題集（5回分325問）
Black Belt (X-Ray, KMS, Cognito, CodeStar & CodePipeline, CodeCommit & CodeArtifact, CodeBuild, CodeDeploy. Lambdaは見たかったけど量が多すぎてやめた)
AWS公式ドキュメント
AWS Certified Developer - Associate サンプル問題
AWS Certified Developer - Associate 公式練習問題集

流れ

ポケットスタディを一周する
Udemyの演習テスト1～5までを解いて、解説を読む。最初の2セットは4割くらいの正答率だが、ちゃんと解説を理解すればこのタイミングで残りの3セットは6割くらいはとれるはず。
弱点となったサービスを洗い出す
Black BeltとAWS公式ドキュメントを使って重要なところを整理する
Udemyの325問をもう一回解く（正答率は8割前後を目指す）
サンプル問題と公式練習問題集を一通り解いておく

ポケットスタディ自体は2023年1月13日に購入しましたが、実際に勉強を始めたのは1月22日からなので、概ね3週間くらいで準備したような感じです。

Udemyの問題集の難易度

本番試験では、Udemyの問題集ほど複雑な問題は出てきませんが、それに回答するための要素1つ1つを聞いてくるような印象はありました。BlackBeltなどを使って、要素1つ1つをきちんと整理しておかないと合格は厳しいかなと思います。あと、解説が間違っている、あるいは雑な箇所がいくつかあります。解説を読んでいて「いやいやそうじゃないっしょ」と思いつつAWSの公式ドキュメントを読んで、自分の考え方のほうが正しいということを確認しながら進められるようになれば合格できると思います。そういう意味では、ただ解いて解説を読むことを繰り返すよりも、講師と問題集を通してコミュニケーションをするために知識武装するくらいのつもりでやったほうが面白いと思います。CLF、SAAとも同じですが、問題集を解いて、解説を読んで、だけだと合格は不安かなと。

目安として、Udemyで6割だと合格ラインぎりぎり、7～8割だと余裕をもって合格できるかなという印象です。9割とれるようになるまでやる必要はないと思います。

次のステップ

AWS Certified SysOps Administrator – Associate(SOA-C02)を3月に取得します。

7月末までにSolutions Architect - Professional、9月末までにDevOps Engineer - Professionalを取得し、その後何か専門知識を取りたいというのが当面の目標です。

追伸

aws certifiedのステッカーをもらってきました。Foundamentals、Associateは取得したのでノートパソコンの天板にステッカーを貼っておきました。ProfessionalとSpecialityは、まだ取得していないので自粛しています。

微妙にアピっていきます。では、また明日から頑張りましょう。

SAMを使ってみる

Mon, 23 Jan 2023 10:50:30 +0000

SAMの使い方

大きな流れは以下の通りです。

サーバレスアプリケーションの雛形作成（sam init）
コーディング
ビルド（sam build）
ローカル環境でのテスト（sam local start-api）
デプロイ（sam deploy）

サーバレスアプリケーションの雛形作成

プレーンテキスト
sam init

今回は、以下のような構成を取りました。

テンプレートの種類: AWS Quick Start Templates
使用するテンプレート: Serverless API
ランタイム: Node.js 16.x
X-Rayの使用有無: No X-Ray
アプリケーション名: sam-app

Bash
sam init

以下のとおり選択していきます。

プレーンテキスト
You can preselect a particular runtime or package type when using the `sam init` experience.
Call `sam init --help` to learn more.

Which template source would you like to use?
 1 - AWS Quick Start Templates
 2 - Custom Template Location
Choice: 1

Choose an AWS Quick Start application template
 1 - Hello World Example
 2 - Multi-step workflow
 3 - Serverless API
 4 - Scheduled task
 5 - Standalone function
 6 - Data processing
 7 - Infrastructure event management
 8 - Lambda EFS example
 9 - Machine Learning
Template: 3

Which runtime would you like to use?
 1 - dotnet6
 2 - dotnetcore3.1
 3 - nodejs16.x
 4 - nodejs14.x
 5 - nodejs12.x
Runtime: 3

Based on your selections, the only Package type available is Zip.
We will proceed to selecting the Package type as Zip.

Based on your selections, the only dependency manager available is npm.
We will proceed copying the template using npm.

Would you like to enable X-Ray tracing on the function(s) in your application? [y/N]: N

Project name [sam-app]: sam-app

Cloning from https://github.com/aws/aws-sam-cli-app-templates (process may take a moment)

 -----------------------
 Generating application:
 -----------------------
 Name: sam-app
 Runtime: nodejs16.x
 Architectures: x86_64
 Dependency Manager: npm
 Application Template: quick-start-web
 Output Directory: .

 Next steps can be found in the README file at ./sam-app/README.md


 Commands you can use next
 =========================
 [*] Create pipeline: cd sam-app && sam pipeline init --bootstrap
 [*] Validate SAM template: sam validate
 [*] Test Function in the Cloud: sam sync --stack-name {stack-name} --watch


SAM CLI update available (1.70.0); (1.57.0 installed)
To download: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html

コーディング

ディレクトリ構成を確認しておきます。

プレーンテキスト
.
├── buildspec.yml
├── env.json
├── events
│   ├── event-get-all-items.json
│   ├── event-get-by-id.json
│   └── event-post-item.json
├── package.json
├── README.md
├── src
│   └── handlers
│   ├── get-all-items.js
│   ├── get-by-id.js
│   └── put-item.js
├── template.yaml
└── __tests__
 └── unit
 └── handlers
 ├── get-all-items.test.js
 ├── get-by-id.test.js
 └── put-item.test.js

buildspec.yml: CodeBuildの動作を決めるための定義ファイルです。アーティファクトはS3にZIP形式で置かれるようです。
src/handlers/*.js: ソースコードの実体です。CFnのtemplate.yamlから参照されているとおり、このソースコードがLambda関数の実体になります。
__tests__/unit/handlers/*.js: テストコードです。buildspec.ymlで、pre_buildフェーズで実行されるようになっています。
events/*.json: Lambda関数を起動するときに使う起動イベントの定義です。Invocation events that you can use to invoke the function.
env.json: sam local invoke --env-vars env.jsonとすることで、template.yamlに記載されている内容をオーバーライドできる仕組みのためのもののようです（ローカルでの Lambda 関数の呼び出し）。

ビルド

cd sam-app; sam buildで実行できます。

Bash
cd sam-app
sam build

以下のように出力されます。

アーティファクト: .aws-sam/build
ビルドに使用したテンプレート: .aws-sam/build/template.yaml

プレーンテキスト
Building codeuri: /home/ec2-user/environment/sam-app runtime: nodejs16.x metadata: {} architecture: x86_64 functions: getAllItemsFunction, getByIdFunction, putItemFunction
Running NodejsNpmBuilder:NpmPack
Running NodejsNpmBuilder:CopyNpmrcAndLockfile
Running NodejsNpmBuilder:CopySource
Running NodejsNpmBuilder:NpmInstall
Running NodejsNpmBuilder:CleanUpNpmrc
Running NodejsNpmBuilder:LockfileCleanUp

Build Succeeded

Built Artifacts : .aws-sam/build
Built Template : .aws-sam/build/template.yaml

Commands you can use next
=========================
[*] Validate SAM template: sam validate
[*] Invoke Function: sam local invoke
[*] Test Function in the Cloud: sam sync --stack-name {stack-name} --watch
[*] Deploy: sam deploy --guided

ローカル環境でのテスト

以下のコマンドにより、ローカル環境でテストできるエンドポイントが提供されます。

Bash
sam local start-api

template.yamlで定義された3つのハンドラーに対し、それぞれエンドポイントが提供されていることが分かります。

プレーンテキスト
Mounting getAllItemsFunction at http://127.0.0.1:3000/ [GET]
Mounting getByIdFunction at http://127.0.0.1:3000/{id} [GET]
Mounting putItemFunction at http://127.0.0.1:3000/ [POST]
You can now browse to the above endpoints to invoke your functions. You do not need to restart/reload SAM CLI while working on your functions, changes will be reflected instantly/automatically. You only need to restart SAM CLI if you update your AWS SAM template
2023-01-23 12:12:43 * Running on http://127.0.0.1:3000/ (Press CTRL+C to quit)

ここで、Cloud9で別のターミナルを開き、getAllItemsFunctionを呼び出してみます。

Bash
curl http://localhost:3000/

当然ですが、DynamoDBが適切にセットアップされていないのでエラーが返ってきます。また、一番最初にgetAllItemsFunctionを呼び出すときには、Dockerコンテナイメージのダウンロードが行われるため、ややレスポンスが悪いです。

プレーンテキスト
Invoking src/handlers/get-all-items.getAllItemsHandler (nodejs16.x)
Image was not found.
Removing rapid images for repo public.ecr.aws/sam/emulation-nodejs16.x
Building image..............................................................................................................................
Skip pulling image and use local one: public.ecr.aws/sam/emulation-nodejs16.x:rapid-1.57.0-x86_64.

Mounting /home/ec2-user/environment/sam-app/.aws-sam/build/getAllItemsFunction as /var/task:ro,delegated inside runtime container
START RequestId: b38fd596-3599-4c48-bb0b-c4fe0906b982 Version: $LATEST
} version: '1.0': null,',4475962,12:42 +0000',e9808e',b-c4fe0906b982 INFO received: {
2023-01-23T12:15:21.803Z b38fd596-3599-4c48-bb0b-c4fe0906b982 INFO response from: / statusCode: 404 body: Unable to call DynamoDB. Table resource not found.
END RequestId: b38fd596-3599-4c48-bb0b-c4fe0906b982
REPORT RequestId: b38fd596-3599-4c48-bb0b-c4fe0906b982 Init Duration: 1.49 ms Duration: 508.13 ms Billed Duration: 509 ms Memory Size: 128 MB Max Memory Used: 128 MB
No Content-Type given. Defaulting to 'application/json'.
2023-01-23 12:15:21 127.0.0.1 - - [23/Jan/2023 12:15:21] "GET / HTTP/1.1" 404 -

デプロイ

なんとなく動いたことの確認ができたので、デプロイしてみます。

Bash
sam deploy --guided

少々ログが長いので、sam-deploy.logに置いておきました。

--guidedをつけてsam deployを起動すると、スタック名やリージョン等が聞かれます。聞かれた内容はsamconfig.tomlに記載され、今後はsam deployを実行するだけで自動的にデプロイされます。

TOML
version = 0.1
[default]
[default.deploy]
[default.deploy.parameters]
stack_name = "sam-app"
s3_bucket = "aws-sam-cli-managed-default-samclisourcebucket-1ae5e5y3ql961"
s3_prefix = "sam-app"
region = "ap-northeast-1"
confirm_changeset = true
capabilities = "CAPABILITY_IAM"
disable_rollback = true
image_repositories = []

APIを叩いてみる

POST

実行コマンド

Bash
curl -X POST -H "Content-Type: application/json" -d '{"id":"1", "name":"sonohen"}' https://su7cqge7o3.execute-api.ap-northeast-1.amazonaws.com/Prod/
curl -X POST -H "Content-Type: application/json" -d '{"id":"2", "name":"sonohen2"}' https://su7cqge7o3.execute-api.ap-northeast-1.amazonaws.com/Prod/

戻り値

JSON
{"id":"1","name":"sonohen"}
{"id":"2","name":"sonohen2"}

GET (All Items)

実行コマンド

Bash
curl https://su7cqge7o3.execute-api.ap-northeast-1.amazonaws.com/Prod/

戻り値

JSON
[
 { "id": "2", "name": "sonohen2" },
 { "id": "1", "name": "sonohen" }
]

Get (By-Id)

実行コマンド

Bash
curl https://su7cqge7o3.execute-api.ap-northeast-1.amazonaws.com/Prod/1 # {"id":"1","name":"sonohen"} should be returned

戻り値

JSON
{ "id": "1", "name": "sonohen" }

環境の削除

Bash
sam delete

出力例

プレーンテキスト
 Are you sure you want to delete the stack sam-app in the region ap-northeast-1 ? [y/N]: y
 Are you sure you want to delete the folder sam-app in S3 which contains the artifacts? [y/N]: y
 - Deleting S3 object with key sam-app/11e6ad52d95b7ff61f7c5edee5989cc5
 - Could not find and delete the S3 object with the key sam-app/11e6ad52d95b7ff61f7c5edee5989cc5
 - Could not find and delete the S3 object with the key sam-app/11e6ad52d95b7ff61f7c5edee5989cc5
 - Deleting S3 object with key sam-app/a4776539efacb8d6b52ef4f5bcf5a08e.template
 - Deleting Cloudformation stack sam-app

Deleted successfully

感想

正直、SAMのハンズオンをやるかは、ものすごく悩んだ。DVAの教科書を見れば、コマンドの実行例とともにSAMの紹介がなされており、それを読めば十分だろうと思っていたからです。ただ実際にやってみると、SAMでHello Worldレベルのことをやるのに、このブログでメモを取りながらでも1時間くらいだし、最後、環境をきれいに削除してしまうのもCFnならではだなと思いました。実際に時間を使ってやってみると、自分の過去の似たような案件と比較してしまう…いや、してしまうという残念な感じよりも、このプロセスそのものが次の案件に向けては重要なんだろうなと思いました。

Elastic Beanstalkを試してみる

Sun, 22 Jan 2023 03:26:59 +0000

目標

Elastic Beanstalkを使って"Congratulations"してみる。
Blue/Greenデプロイにより、サンプルプログラムの"Congratulations"を"Hello World"に変えてみる。

今回の構成

※相変わらず分かりにくい図で申し訳ないです。

Elastic Beanstalkで"Congratulations"してみる。

アプリケーションの作成

Elastic Beanstalkは初めて使うため（AWS研修では使った経験あり）、AWS Management Consoleから作成しました。

Amazon Correttoとは、Amazonによる無料の長期サポートが提供されている、Java SE標準と互換性があると認定されているOpen JDKディストリビューションのことです。

作成を開始すると、CloudFormationテンプレートによりスタックが作成されていきます。

ハマリポイント1　スタック作成でエラーが発生

エラー内容

次に、CloudFormation > スタック > awseb-e-e7d8kvxdpq-stackを開き、イベントタブを開いたところ、以下のようなエラーが発生し、スタックのステータスはCREATE_FAILEDになっていました。この時、ElasticBeanstalk > 環境 > Beanstalktrial-env-2の環境のヘルスは保留中になっていました。

The following resource(s) failed to create: [AWSEBV2LoadBalancer, AWSEBAutoScalingGroup].

You must use a valid fully-formed launch template. No default subnet for availability zone: ‘ap-northeast-1c’. (Service: AmazonAutoScaling; Status Code: 400; Error Code: ValidationError; Request ID: 7d99081a-1554-487c-b265-38b01661aa2e; Proxy: null)

このエラーの原因は、デフォルトサブネットが存在しないことです。過去にデフォルトVPCを削除した時に、一緒に削除されたのだと思います。そして、現在はデフォルトVPCのみ作成されている状況です。本来、デフォルトVPCは以下のような構成になっているのが正しいようです。

そこで、以下の手順でデフォルトVPC、デフォルトサブネットを構成し直します。

Elastic Beanstalkの環境を削除し、アプリケーションを終了する
デフォルトVPCの記載を参考に、AWS CloudShellから以下のコマンドでデフォルトVPCとデフォルトサブネットを作成する¹

対応1　Elastic Beanstalkの環境を削除し、アプリケーションを終了する

Elastic Beanstalk > 環境から、環境を選択し、右にあるアクションから環境の終了を選択し、環境を終了します。これにより、アプリケーションの公開も停止されます。

対応2　デフォルトVPCを作成する

AWS Cloud Shellから以下のコマンドを実行します。実行しているコマンドの詳細は、AWS CLI Command Referenceを参照してください。

プレーンテキスト
aws ec2 create-default-vpc

出力例は以下です。

プレーンテキスト
An error occurred (DefaultVpcAlreadyExists) when calling the CreateDefaultVpc operation: A Default VPC already exists for this account in this region.

既にデフォルトVPCが存在すると言われます。そこで、デフォルトVPCのVpcIdを調べます。

プレーンテキスト
aws ec2 describe-vpcs --filter Name=is-default,Values=true --query 'Vpcs[].[VpcId]' --output text

出力例は以下です。

プレーンテキスト
vpc-0f48a5ddd72f1781f

既に存在するサブネットの削除

今回は、既にデフォルトVPCが存在していました。その配下にあるサブネットがデフォルトサブネットか判断がつかなかった上、他で使っていなかったことから、デフォルトVPCにあるサブネットを削除しておきます。

Shell
for target_subnet in `aws ec2 describe-subnets --filters Name=vpc-id,Values=vpc-0f48a5ddd72f1781f --query 'Subnets[].[SubnetId]' --output text`
do
 aws ec2 delete-subnet --subnet-id $target_subnet
done

以下のコマンドを実行し、出力結果が無いことを以てサブネットが削除されたことを確認します。

プレーンテキスト
aws ec2 describe-subnets \
 --filters Name=vpc-id,Values=vpc-0f48a5ddd72f1781f \
 --query 'Subnets[].[SubnetId]' \
 --output text

デフォルトサブネットの作成

以下のコマンドで、各AZにデフォルトサブネットを作成します。

Shell
availabilityzones=(ap-northeast-1a ap-northeast-1c ap-northeast-1d)

for az in ${availabilityzones[@]}
do
 aws ec2 create-default-subnet --availability-zone $az
done

unset availabilityzones

作成されたことを確認します。

プレーンテキスト
aws ec2 describe-subnets \
 --filters Name=vpc-id,Values=vpc-0f48a5ddd72f1781f \
 --filters Name=state,Values=available \
 --query 'Subnets[].[SubnetId,AvailabilityZone,CidrBlock]'

出力例は以下です。

JSON
[
 ["subnet-090132d78642c5909", "ap-northeast-1d", "172.31.32.0/20"],
 ["subnet-0a941d6e7b4ae578c", "ap-northeast-1c", "172.31.0.0/20"],
 ["subnet-0374fa703f83f7ae1", "ap-northeast-1a", "172.31.16.0/20"]
]

ドキュメントによると、デフォルトサブネットのCIDRは172.31.0.0/20, 172.31.16.0/20, 172.31.32.0/20の3つであるということなので、きちんと作成されたようです。

インターネットゲートウェイの状況の確認

まず、デフォルトVPCにアタッチされているインターネットゲートウェイのInternetGatewayIdを調べます。

プレーンテキスト
aws ec2 describe-internet-gateways \
 --filter Name=attachment.vpc-id,Values=vpc-0f48a5ddd72f1781f \
 --filter Name=attachment.state,Values=available \
 --query 'InternetGateways[].[InternetGatewayId]' \
 --output text

出力例は以下です。

プレーンテキスト
igw-0adc27eae43d8714d

0.0.0.0/0宛の通信が上記のInternetGatewayを通るように設定されているか、ルートテーブルを確認します。

Shell
aws ec2 describe-route-tables \
 --filter Name=vpc-id,Values=vpc-0f48a5ddd72f1781f \
 --filter Name=route.destination-cidr-block,Values=0.0.0.0/0 \
 --filter Name=route.gateway-id,Values=igw-0adc27eae43d8714d \
 --output text

出力例は以下です。

JSON


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


{
 "RouteTables": [
 {
 "Associations": [],
 "PropagatingVgws": [],
 "RouteTableId": "rtb-0ef8c99720a501497",
 "Routes": [
 {
 "DestinationCidrBlock": "172.31.0.0/16",
 "GatewayId": "local",
 "Origin": "CreateRouteTable",
 "State": "active"
 },
 {
 "DestinationCidrBlock": "0.0.0.0/0",
 "GatewayId": "igw-0adc27eae43d8714d",
 "Origin": "CreateRoute",
 "State": "active"
 }
 ],
 "Tags": [
 {
 "Key": "Name",
 "Value": "default-public-rtb"
 }
 ],
 "VpcId": "vpc-0f48a5ddd72f1781f",
 "OwnerId": "436589084651"
 }
 ]
}

0.0.0.0/0宛の通信がigw-0adc27eae43d8714dを通るように設定されていることが確認できました。²

ここまでで、以下の構成が作成されたことが確認できました（以下図は再掲）。

ElasticBeanstalkでアプリケーションを再作成する

再度、ElasticBeanstalkのアプリケーションを作成します。アプリケーションの作成に成功すると、Elastic Beanstalk > 環境にURLが表示されるので、それにアクセスします。すると、以下のように"Congratulations"と表示されるはずです。

ハマりポイント2

私の場合、以前にデフォルトVPCを作成した時に、プライベートサブネット用のルートテーブル、およびパブリックサブネット用のルートテーブルの2つを作っており、デフォルトのルートテーブルは「プライベートサブネット用のルートテーブル」でした。その結果、Beanstalkのアプリケーションを作成した際に、EC2インスタンスは「プライベートサブネット」に配置されており、それが原因でヘルスチェックに失敗する、必要な情報がELB側で取得できない等の問題が発生しました。解決するため、Beanstalkが作ったEC2インスタンスが配置されているサブネットのルートテーブルを「パブリックサブネット用のルートテーブル」に関連付けし直し、環境を再構築しました。

Hello Worldの作成

Cloud9環境の構築

サクッと作っておきます。今回は、ap-northeast-1dに配置しました。

Hello Worldの作成

Elastic Beanstalk resourcesにcorretto.zipがあるので、Cloud9のターミナルを使ってダウンロードし、展開しておきます。

Shell
wget https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/samples/corretto.zip
unzip corretto.zip -d sample/

続いて、sample/src/main/resources/index.htmlを開き、以下のように編集します。

HTML


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


<html>
 <head>
 <title>Hello World</title>
 </head>
 <body>
 <h1>Hello World</h1>
 <p>
 This is a end of the Web as there are no links in this page. Hello World.
 </p>
 </body>
</html>

アップロードできるよう、cd sample; zip corretto-2.0.zip -r .で圧縮しておきます。

Blue/Greenデプロイの実行

環境のクローン

現在動作している環境をクローンします。Elastic Beanstalk > 環境を開き、ラジオボタンにチェックを入れ、アクションから環境のクローンを作成を選択します。ひとまずはデフォルト設定のままクローンします。新しい環境の名前は「beanstalktrial-env-1」になりました。現時点で環境は2つあり、それぞれURLは以下の通りになっています。

1つ目、2つ目のURLにアクセスし、「Congratulations」が表示されていることを確認します。

ZIPファイルのアップロードとデプロイ

先ほど作成したcorretto-2.0.zipを、Green環境（Beanstalktrial-env-1）にアップロードし、デプロイします。Elastic Beanstalk > 環境 > beanstalktrial-env-1を開き、アップロードとデプロイを選択します。ZIPファイルをアップロードし、デプロイが完了するのを待ちます。

デプロイが完了した後、先ほどの2つ目のURLにアクセスし、「Hello World」が表示されていることを確認します。1つ目のURLは引き続き「Congratulations」になっていることを確認しておきます。

Blue環境とGreen環境の切り替え

Elastic Beanstalk > 環境を開き、Green環境（Beanstalktrial-env-1）を選択し、アクションから環境URLのスワップを選択します。次の画面で、スワップする環境の選択で、環境名に「Beanstalktrial-env」を選択し、スワップを押下します。最近のイベントを確認すると、Swapping CNAMEs for environments 'Beanstalktrial-env-1' and 'Beanstalktrial-env'.と記載がある通り、スワップはRoute 53のCNAMEレコードの変更によって実現されています。

ここで、Elastic Beanstalk > 環境を開き、2つの環境のURLがスワップされていることを確認します。

これでBlue/Greenデプロイが完了しました。

まとめ

非常に単純な操作によって、Blue/Greenデプロイが出来ることが分かりました（小並感）。

Elastic Beanstalk自体は、AWS研修でもハンズオンを実施したことがありましたが、やはりそこは研修環境、トラブルなんて起こりません。今回は、自分のAWS環境を使って実行したので、デフォルトVPCやデフォルトサブネットが壊れていたこと、デフォルトルートテーブルがプライベート用になっていたことなど、ここに書いていないことも含めてハマりポイントがありました。過去xx年の経験によって、こういうハマりポイントを経て人は強くなっていくということを身を持って理解していますので、今後も用意された環境ではなく、自分の環境で色々と操作を試していきたいと思います。

起動する際、選択しているリージョンに注意してください。今回は、Elastic Beanstalkをap-northeast-1（東京リージョン）で起動したいので、それを指定した後、AWS CloudShellを起動しました。 ↩︎
もう少し読み進めて頂くと分かりますが、この確認だけでは不十分です。このルートテーブルがデフォルトルートテーブルになっていることを確認するか、あるいはサブネットのルートテーブルの付け替えをしないといけません。 ↩︎

Twitterをやめた

Mon, 09 Jan 2023 12:15:31 +0000

もともと、Twitterは情報収集を目的に始めたものだった。その中で、自分が得た情報を発信し、何らかの反応が得られることを知ると、目的が人から反応を得ること、に徐々にすり替わった。つまり、反応を得るための情報収集、情報発信になっていったのだ。インフルエンサーでもなし、見ず知らずの人からリアクションが得られたところで何になるだろう？　そんなことを思うと、急にTwitterがくだらないと思ってしまったのだ。しかし、ふと第三者視点からTwitterに書き込む自分の姿を観察すると、承認欲求というものは厄介なもんだと思う。

辞めるにあたって、ツイートしたものは全て自分の手で削除し、いいねしたものを全て自分の手で外し、フォロワーにも感謝しつつ外した。いいねを外しながら、当時の自分は何を思ってこの人のツイートにいいねをしたのかさっぱり思い出せなかった。「どうでもいいね」だったのかもしれない。

面白いと思ってやっていたときもあるし、今この瞬間にも面白いと思って使っている人がいるんだろうから悪く言うつもりも無いが、思ってしまったことは思ってしまったことだし、過去にも何回か同じような理由で始めてはやめてきた経緯もあることから、とりあえずここに書いておくことにした。

Pixel Watchを買った

Fri, 06 Jan 2023 08:10:00 +0000

買い方

アメリカン・エキスプレス・カード + メンバーシップ・リワード・プラスで購入したので、100円につき3ポイント（3%）の還元があり、実際に1,194ポイントの還元があった。このポイントを1ポイント1円として使うかどうかは自分次第ではあるが。

写真

購入後にやったこと。

バンドの装着順を交換した。普段は左手に装着するが、手首を曲げたときにリュウズが左手の甲に当たるため。
Google KeepのアプリをPixel Watchに入れた。音声でメモが取れるのはやはり良い。

よく分からないこと。

AnkerのSoundCore Libertyを使っているわけだが、これとPixel Watchのペアリングが必要なのか否か。どうもPixel Watchから、ペアリングしているスマートフォンを通して電話が掛けられるのだが、その音声をPixel Watchのスピーカーやマイクから垂れ流すというのはちょっとできない。
Pixel Watch自体に何かファイルを入れたりはできないのか？というよりその辺の思想がよくわからない。Pixel Watchはスマホのインタフェースの1つに当たるのか、それともそれ単独で何かできるようになっているのか。
Chromebook、Pixelスマホ、Pixel Watch、他Google製品との連携エコシステムはまだ良くわからないことが多い。このあたりはAppleがよくできていると思う。

事前に気になっていたことと現在

事前に調べていて気になった「バッテリーの持ち」は、「常時点灯」と「傾けて点灯」をOFFにしておけば、活動量計＋たまの通知確認程度の自分の用途では少なくとも日中は問題なく持つ。時間を確認するのに、いちいち画面タップが必要なのが面倒ではあるが。「傷の付きやすさ」については分からないが精密機器として丁重に扱っていればつきにくいとは思うがまだ良くわからない。

最後に

こんなことを思いながら使っていると、Apple Watchの第2世代を使っていたときのことを思い出す。処理は遅い、バッテリーは持たない、傷は付きやすい。それに比べれば、初代としては完成度は高いのではないか。

GitHub Codespacesを試しつつ、Hugoへ移行する

Wed, 04 Jan 2023 09:07:32 +0000

試す上での縛り

Chromebookで全ての作業（このブログの執筆も含む）を完結させる
ブラウザ（Chrome）だけで全ての作業（このブログの執筆も含む）を完結させる

試す手順

リポジトリの準備

GitHub上で、プライベートなリポジトリ（ここでは「hugo-blog」とする）を作成しておく。あわせて「draft」という名前でブランチを作っておく。以降、全ての作業はこのdraftブランチを軸に行っていく。

Codespacesの起動

「hugo-blog」リポジトリ、「draft」ブランチを選択してCodespacesを起動する。

メニューバーの「Codespaces」を選択して起動する方法もある。[Codespaces] > [New codespace]の順に操作し、起動パラメータを以下の通り設定してもよい。

起動後の画面はWeb版VS Codeなり。

hugoの最低限の設定

初期状態で、hugoはインストールされている（パス：/usr/local/hugo/bin/hugo）。hugoのQuick Startに沿って作業を進める。

Shell
/workspaces/hugo-blog (draft) $ hugo new site . –force
/workspaces/hugo-blog (draft) $ git submodule add https://github.com/theNewDynamic/gohugo-theme-ananke themes/ananke
/workspaces/hugo-blog (draft) $ echo "theme = 'ananke'" >> config.toml
/workspaces/hugo-blog (draft) $ hugo server

そうすると、Codespaceの中で動作しているhugoのポートと、外部からアクセスできるアドレス（ローカルアドレス）のバインドが行われ、「ポート」タブに表示される。ローカルアドレスにアクセスすれば、Codespaceの中で動作しているhugoのサーバにアクセスできる。

アクセスすると、以下の通りhugoで作成したサイトが表示される。

一旦、ここまでの変更をコミットしておく。

hexoからhugoへの移行

ここから先は、hexoからhugoへの移行の記録である。

submoduleの削除

themes/anankeは使わないので削除しておく。

Shell
/workspaces/hugo-blog (draft) $ git submodule deinit -f themes/ananke
/workspaces/hugo-blog (draft) $ rm -rf themes/ananke

テーマの選定

今回はsimplenessというものにした。シンプルでヨシ。

Shell
/workspaces/hugo-blog (draft) $ git submodule add https://github.com/RainerChiang/simpleness.git themes/simpleness

config.tomlの変更

config.tomlを変更する。とりあえずはデフォルトで記載されている以下のパラメータを変更しておく。動けばヨシ。

TOML
baseURL = 'https://sonohen.github.io/'
languageCode = 'ja-jp'
title = 'とあるエンジニアの備忘録'
theme = 'simpleness'

.gitignoreの作成

以下を追加しておく。

プレーンテキスト
/public/
/resources/_gen/
.hugo_build.lock

動作確認

ここまでで動作するかを確認しておく。

Shell
/workspaces/hugo-blog (draft) $ hugo server -D

theme/simplenessは、各種リソースをlocalhost:1313から取得しようとしてしまうのでこれだと正しく動作しない。その場合は、以下のコマンドで対処する。

Shell
/workspaces/hugo-blog (draft) $ hugo server -D --baseUrl="https://sonohen-scaling-space-pancake-j4wxjgjq9r2qxxj-1313.preview.app.github.dev/" --appendPort=false

もう少し良いやり方があると思うが、とりあえずはこれで動いたのでヨシ。

ここで一旦、コミットしておく。

記事・静的ファイルの移行

hugoの場合、/contentに記事本体（*.md）、/staticに静的ファイル（*.jpg等）を入れておけば良いらしい。また、hexoで書いていた記事は「hexo」という名前のリポジトリに保存してあるので、スマートではないがとりあえず以下の方法で移行する。

Shell
# 鍵の作成
/workspaces/hugo-blog (draft) $ ssh-keygen -t rsa
/workspaces/hugo-blog (draft) $ cat ~/.ssh/id_rsa.pub # 公開鍵をGitHubに登録する

# 接続テスト
/workspaces/hugo-blog (draft) $ ssh -T git@github.com
Hi sonohen! You\'ve successfully authenticated, but GitHub does not provide shell access.

# 移行作業
/workspaces/hugo-blog (draft) $ mkdir content
/workspaces/hugo-blog (draft) $ cd ../
/workspaces/ $ git clone git@github.com:sonohen/hexo.git
/workspaces/hexo/source (master) $ cp -Rp ./_posts/ /workspaces/hugo-blog/content/
/workspaces/hexo/source (master) $ cp -Rp ./images/ /workspaces/hugo-blog/static/
/workspaces/hexo/source (master) $ cd /workspaces/hugo-blog

# 動作確認
/workspaces/hugo-blog (draft) $ hugo server -D --baseUrl="https://sonohen-scaling-space-pancake-j4wxjgjq9r2qxxj-1313.preview.app.github.dev/" --appendPort=false

ここで以下のように表示されればうまく移行できたと思われる。

GitHub Actionsを利用した自動デプロイ

/content/_posts/にMarkdownファイルを作成し、コミットしたらsonohen.github.ioに表示されるようにしたい。。

そのためにはリポジトリを開き、[Settings] > [Build and deployment] > [Source]からGitHub Actionsを選択し、[Hugo] > [Configure]を選択し、次の画面でCommitすればよい。次のコミット分からGitHub Actionsで自動デプロイされる。

Amazon WorkSpacesの検証をやってみた

Tue, 03 Jan 2023 09:37:30 +0000

Amazon WorkSpacesとは

VDI（Virtual Desktop Infrastructure：仮想デスクトップ基盤）の1つで、シンクライアントとも言われます。皆さんがお勤めの企業でも導入されているかもしれません。Windows等のOSがAWSのデータセンター上で動いており、そこにアクセスして作業します。

個人の場合（例えば私の場合）、以下のユースケースがあるかなと思います。

日常的な作業の大半はChromebookで出来るが、一部の作業でWindowsが必要、だけどWindows端末は持ちたくない、という場合にスポットで利用
特定の国からしかアクセスできないサイトにアクセスする場合に、その国に設置されているリージョンにAmazon WorkSpacesを設定し、アクセス（良く分からないVPNを経由してアクセスするよりもAmazon WorkSpacesのほうがセキュアな可能性があります）

背景

Amazon WorkSpacesを試してみようと思ったときに、以下の前提条件で最も費用が安くなるのが米国東部（バージニア北部：us-east-1）です。時間料金を選択すると、1ヶ月あたりの固定費用が9.75 USD/月（約1,227円/月）、利用時間ごとの変動費用が0.30 USD/時間（約40円/時間）です。例えば、月に40時間だけ使うという場合にAmazon WorkSpacesにかかる費用は、9.75 USD + 0.30 USD * 40h = 21.75 USD (約2,845円)です。

前提条件

リージョンは米国東部（us-east）
Windowsバンドルオプション
スタンダード（2 vCPU、4GBメモリ）
ルートボリューム80GB、ユーザーボリューム50GB

ただし、この場合にネックになるのがパフォーマンスです。Amazon WorkSpacesの管理ドキュメントによると以下のような記載があります。

PCoIP のパフォーマンスを最大限に高めるには、クライアントネットワークからWorkSpaces があるリージョンまでのラウンドトリップ時間 (RTT) が 100ms 未満でなければなりません。RTT が 100 ミリ秒から 200 ミリ秒の間にある場合、ユーザーはWorkSpace にアクセスできますが、パフォーマンスに影響します。RTT が 200 ミリ秒～375 ミリ秒の間にある場合、パフォーマンスは低下します。RTT が 375 ミリ秒を超えると、WorkSpacesクライアント接続は終了します。

WorkSpaces Streaming Protocol (WSP) の最高のパフォーマンスのためには、クライアントのネットワークから WorkSpaces があるリージョンまでの RTT が 250 ミリ秒未満でなければなりません。RTT が 250 ミリ秒から 400 ミリ秒の間にある場合、ユーザーはWorkSpace にアクセスできますが、パフォーマンスは低下します。

― AWS, Amazon WorkSpaces クライアントネットワークの要件

Amazon WorkSpacesのConnection Health Checkを見ると、日本国内からアクセスしたときの米国東部までのラウンドトリップ時間（以下RTT）は380msと表示されており、上記の記載に照らし合わせるとWorkSpaceにアクセスできないことになります。しかし、実際にはアクセスし、操作できます。ここで確認できるRTTと、実際にWorkSpacesのクライアント（Android版）から確認できるRTTは大きく乖離している場合があるためで、クライアントから確認できるRTTは186msでした。よって、RTTを確認する際には、実機にクライアントを入れて確認するのが一番良いと思います。

目的

以下の操作を行い、体感性能がどの程度であるのかを把握します。

WorkSpacesにログインする
ソフトウェア（Google Chrome）をインストールする
Google Chromeで速度測定（speed.cloudflare.com）を行う
タスクマネージャや設定画面を開く

環境

見て分かる通り、private-subnet-(1a|1b)は不要です。なぜ作ったかというと、もともとSimple ADとAmazon WorkSpacesはprivate-subnet-(1a|1b)に配置する計画でしたが、その場合、public-subnetにNATゲートウェイを設置する必要があり、そのコストが勿体ないと気がついたのが、public-subnetの作成後だったからです。

結果

作業をしている時に撮影した動画をYouTubeにアップロードしました。

ポイントは以下のとおりです。

RTTは178ms（2023年1月2日20:00〜20:02に撮影）であったが、軽い作業であればレスポンスが気になることは少ないと思われる
Google Chromeをインストールし、Chromeで速度測定を行う程度であれば体感上、遅いと感じることはない。ただ、CloudFlareを開いたときの引っかかりはややあるかという程度（Intel Celeron N4020を搭載したChromebook HP 14aでCloudFlareを開いたときよりはマシという程度）
OSはWindows Server 2016 Datacenter (1607)
WorkSpaceとインターネット（CloudFlare）の間のダウンロード速度は1.10Gbps、アップロード速度は926Mbps。Ping値は低いがJitter値がやや高い
何も作業していない状態で、メモリは51%が使用されており、CPU使用率は5%前後位を推移。割り当てられているCPUは「Intel Xeon Platinum 8259CL CPU 2.5Ghz (2vCPU)」、メモリは4GB

今後について

メインマシンをChromebookに置き換えたので、年賀状印刷（特に宛名印刷）だけのためにWindows端末が必要な状況です。WorkSpaceに筆王をインストールし、自宅にVPNで接続後、自宅に据え付けているネットワークプリンタ（DCP-J4140N）を使って宛名印刷が出来るようにしてみたいと思います。今どき、宛名印刷はネットで注文できるのでこのような手間をかける意味は無いですが。

ITエンジニアに求められる姿勢、または能力に関する私見

Sun, 01 Jan 2023 09:51:59 +0000

はじめに

「ITエンジニア」にも色々いますが、特に大手企業から受託してシステム・インテグレーションを行っている人々のことを想定しています。あまり関係ないかもしれません。

私が思うITエンジニアに求められる姿勢、または能力には3つのものがあると思います。

自社の課題と、顧客企業の課題を捉え、または捉えようとし、それを解決し、または解決しようとする姿勢、能力
常に身の回りに疑問を持ち続け、それを解決し、または解決しようとする姿勢、能力
言語を正しく運用する能力

ここでは、個々に対して私見を整理したいと思います。

自社の課題と、顧客企業の課題を捉え、または捉えようとし、それを解決し、または解決しようとする姿勢、能力

顧客がIT投資の意思決定を行う背景には、大なり小なり課題があります。何の課題もないところに投資を行う必要はないということです。そして顧客は、課題を解決してくれる（と期待する）ベンダーにシステム開発を委託します。委託された側は、顧客の課題を、自らが持つアセットを使って解決しようとします¹。これらの流れが途中で断ち切られると、IT投資は必ず失敗に終わります。

ここで、以下のような疑問が出てきます。

顧客はベンダーに課題を正確に伝えてくるでしょうか。
ベンダーは、「他社」のビジネスと課題を正確に理解できるでしょうか。
自社が持つアセットと自社の課題（不十分なところ）を正確に理解しているでしょうか。
顧客と自社のそれぞれが持つ課題は、現場とマネジメントで一致しているでしょうか。

まず、顧客がベンダーに課題を正確に伝えてくることは稀だと思います。それは、顧客自身が正確に認識していないこともあれば、ベンダーからすれば他社のビジネスにおける課題なわけで、言葉の使い方、ニュアンスや温度感などを取り違えるなんていうことはザラでもあるからです。ゆえに、顧客とベンダーは、様々な技法を用いて、ビジネスと課題を共通認識のもとに捉えていくことが求められます。技法には「ドメイン駆動設計」のようなものがあれば、「デザイン思考」といったものもあるかもしれません。いずれにしても、双方向の取り組みが必要になるということです。

そして、ビジネスと課題を共通認識のものにできたら、ベンダーは課題を解決、または整理しなければなりません。ここでは解決すると決めた課題について書きます。業界には課題を解決するための技術が多くあり、その技術は更に「基本」と「応用」に分解できます。応用部分に対して、各社が持ち合わせているアセットやその深度は多種多様で、強みもあれば、弱みもあります。そして多くの場合、顧客の課題を解決するのは「応用の技術」です。したがって、自社の何が強みで、何が弱みなのか。それに対してどのように対応しようとしているのか。これが自社の課題であり、顧客と対峙するときには、常に正しく認識しておくことが重要です²。これは何も強みを活かして対応しましょうということではありません。強みを活かすことも大事ですが、顧客からの求めによっては、弱みを課題として認識して対処する必要があるということです。

常に身の回りに疑問を持ち続け、いくつかを課題と捉え、それを解決し、または解決しようとする姿勢、能力

1つ目の話は、いわばトップダウンの考え方です。ビジネスを理解し、課題を抽出し、自社の課題を踏まえて顧客課題の解決を目指す、という3段階の流れです。ここでは、ボトムアップの考え方を書きたいと思います。

先に「基本」と「応用」という言葉を使いました。「基本」とは、長きにわたって変わらないもので、常に立ち戻ることができる地点のことを意図して書いています。これに対して「応用」とは、基本を土台と捉え、その土台の上に成り立つ概念を意図して書いています。あるいは、応用が土台となり、その土台の上に成り立つ概念でもあります。例えば、何かをしようとした時に、ある方法よりも正確に行える方法、効率が良い方法、安全性が高い方法などを意図しています。

まず、何においても「基本と応用の技術」を習得・研鑽することが肝要で、どちらかといえば基本に注力することが大事です。この理由は2つあります。まず、基本に注力すべき理由ですが、基本は応用の土台であり、不安定な土台のうえに物は載らない、あるいは載ったとしても不安定であり、もっと言えば載った状態の再現性が低いからです。次に、技術の習得と研鑽が肝要であるとする理由ですが、人は知らないことに対して疑問を持つことができないからです。人が疑問を持つのは、自分が知っている道理に沿って物事が進まないときです。人は何かを知り、そこから外れたものに対して疑問を持ち、その疑問の一部は、自分に不足している基本や応用の技術で塗り替えられ、そうでないものはやがて課題に置き換わっていきます。課題とは何かを達成するための障壁です。だから、「基本と応用の技術」の習得・研鑽は重要なのです。

私の仕事はチームで仕事をするので、ここで「チーム」という言葉を考えたいと思います。そもそもチームとは個人の集団であって、チームを組む理由（意味）は（1）個人ではなし得ないことをやり遂げること、または、（2）そのやり遂げる結果が、個々の成果の総和を超えること、にあると考えます。特に（2）を目指すなら、そこに集まる個人によってチームとしての「基本と応用の技術」の幅が広げられ、かつ深くなっている状態でなければなりません³。さらに、その多様性を発信し、また個々人が受け入れることができる土壌も必要です。”Diversity and Inclusion”（多様性の受け入れ）の意味の1つはこれにあるのではないでしょうか。

その中で、個人が持つ「基本と応用の技術」の範囲で、常に身の回りに疑問を持ち続けることが大切です。具体的には、「自分と周りが正しい⁴ことをしているか」を問い続けることです。断面はいくつかあるでしょう。ビジネス理解、課題抽出、設計、実装、テスト。アーキテクチャ。マネジメント。もっと広くは組織。それぞれに対し、「基本と応用の技術」を当てはめたときに、個人が疑問を生み出すことができ、その一部を個人またはチームの課題と捉えられるかどうかが、チームとしての成果を生み出せるか否かに関わり、ひいては顧客の課題を解決できるかどうかにも関わるのだと思います。

言語を正しく運用する能力

最後は、「言語」の話です。

私の仕事の成果は、すべて「言語」で成り立っています。言葉には2つあり、1つは日本語や英語といった人間同士が使う言語（これを便宜上、会話言語とします）、もう1つはサーバやネットワーク等のインフラ、およびそれらの上で動作する各種ソフトウェアを開発または統合し、動作させるために必要な言語（あるいはパラメータ類）です。

それを生産するプロセスは大きく3つに分けられると思います。1つ目は顧客のビジネスや課題を、会話言語を用いて言語化して共通認識の下に置くこと、2つ目は、その課題を解決するための方法を「基本と応用の技術」を用いて考えること、３つ目は、考えた解決策をコンピュータ等が理解できる形に変換することです。これらのすべてで言語が使われ、そして最終的に変換するということは、変換元となるものの解釈を誤ってはならないですし、変換も正確に行われなければなりません。それぞれの対象に適した言語を適切に運用しなければならないのです。

よりよい（より伝わり易い）言い回しがないか、よりよい実装の仕方はないかを常に自分に問いながら、言語を正しく運用していきたいものです。

まとめ

勘違いしないで頂きたいのは、あくまで上記は私見であり、また、自分が出来ていると思っているものでもないということです。また、人によって置かれた状況が異なるため、ITエンジニアに求められるものも人それぞれ、またはその時々によって変わるものと思います。

ただ、現時点でITエンジニアに求められるものは、ここに書いた3つのことに帰結するのではと私は思っていますし、少なくとも2023年においても私とチームの課題でもあると思っていますので、ここに書いたことを念頭に置きながら仕事をしていきたいと考えています。

では、よいお年を。

実際には、QCD等に代表される「制約」の範囲において、です。 ↩︎
一方で顧客は、そのベンダーの強みと弱みを理解し、課題を解決する道筋を立てられるか、その道筋に適合するかを自分たち、またはコンサルティングファームのコンサルタントと一緒に考え、自分たちの解を持っておくことが重要です。 ↩︎
マネジメントの要素もありますが、ここでは話を単純にするために書かないことにします。 ↩︎
「正しい」とは、あらゆるレベルで共有された目標・目的に向かって、まっすぐの方向へ推し進めようとする力のことです。 ↩︎

ブログ環境をGitHubからAWSに移行しました

Tue, 06 Dec 2022 11:24:12 +0000

今までの構成

今までは、静的CMSであるHexoを使ってローカル環境で各ページを生成し、生成されたページをGitHub Pagesで公開する、という構成を取っていました。

この構成を取っていた理由は以下の2つです。

ブログ記事をMarkdown形式で書くことができ、HTMLを作るために必要なテンプレートや設定ファイルをgitで管理できるため
GitHub Pagesは、リポジトリにgit pushさえすればページが公開され、かつ無料で気軽に使うことができるため

しかし思うところがあり、今回、この構成をAWSに移行することにしました。

新たに構築した構成

新たに構築した構成のイメージは以下の通りです。

ポイントは以下のとおりです。

Chromebookで執筆した記事をCodeCommitにgit pushすると、CloudWatch EventsがCodePipelineを起動する
CodeBuildが、/buildspec.ymlに記載された内容に基づき、hexo generateを実行する。そして、生成されたHTML（./public/配下）をS3バケットとaws s3 syncで同期する

これにより、（1）source/_pages/にMarkdown形式で記事を書いた記事を保存する、（2）git commitとgit pushを実行する、だけで、自動的にブログ記事が公開されるわけです。

ハマったポイント

`git clone ssh://git-codecommit.ap-northeast1-amazonaws.com/v1/repos/...`で、`Permission denied (publickey).`が発生し、cloneに失敗する

確認したポイントは以下です。

~/.ssh/id_rsa（秘密鍵）のパーミッションが400になっていること
Management ConsoleのIAM > ユーザー > 認証情報 > AWS CodeCommit の SSH キーに、~/.ssh/id_rsa.pubの内容が正しく登録されていること

これでもエラーが解消しなかったため、Troubleshooting SSH connections to AWS CodeCommitを参考に、git clone ssh://[my-key-id]@git-codecommit.ap-northeast1-amazonaws.com/v1/repos/...を実行したところ、git cloneできるようになりました。my-key-idは、IAMから確認できます。

`buildspec.yml`に記載した`aws s3 sync [src] [dest]`の実行が、`ListObjectsV2`のAccess Deniedエラーで失敗する

Amazon S3 バケットで sync コマンドを実行すると、ListObjectsV2 で Access Denied (アクセス拒否) エラーが表示されるのはなぜですか?によると、ListObjectsV2の実行を許可するためには、IAMでs3:ListBucketsの実行を許可する必要があります。

と、ここまでは良いのですが、何を血迷ったのか、私は以下のように記載し、CodePipelineのサービスロールにアタッチして3時間ほど悩んでいました。

YAML
{
 "Effect": "Allow",
 "Action":
 ["s3:ListBuckets", "s3:PutObject", "s3:GetObject", "s3:DeleteObject"],
 "Resource": ["arn:aws:s3:::.../*"],
}

これをアタッチしてから何回もCodePipelineを実行しましたが、毎回毎回ListObjectsV2起因のエラーでパイプラインが止まりました。深夜になっていたこともあり、一旦そこで作業を中断しましたが、翌日、CodePipelineではなく、CodeBuildのサービスロールにアタッチしなければ意味が無いことに気が付きました。（aws s3 syncを呼び出すのはCodePipelineではなくCodeBuildのため）

なぜAWSに移行したのか

昨年、Chromebook hp 14aを購入したのをきっかけに、日常作業のほぼ全てをクラウド環境に移行しました。Windows環境が必要なScanSnapを使った書類のスキャンと、開発作業のためにWindows端末を残しています。

ただ、よくよく考えて見ると、Windows端末での作業もChromebookに移行できそうです。

ScanSnapをWiFi対応のものに買い換えることで、クラウドストレージに直接スキャンデータを保存できるようになりそう
Windowsで実施している開発も、AWSのサービスをうまく組み合わせればWindows環境なしでもいけそう。Cloud9 + なにか、で出来そう。

特に最近、開発に使っているPCのスペックが時代遅れになりつつあり、必要な時に必要なリソースが取れるクラウド環境での開発に興味が出始めています。開発環境をAWSに移行する際には、Codeシリーズの使い方を少しは知っておく必要があるので、研究を兼ねてAWSに移行しました。

今後の構想

以下の5点を年内目処くらいでやっておきたいなと思っています。

Slackからコマンドを投げると、自動的にPipelineが動作するようにする。
CloudFrontを使った配信
S3の非公開化
独自ドメインを使ったアクセス
開発環境の移行。色々やり方はありそう。EC2/ CodeCatalyst/ Cloud9/ WorkSpacesなど。WorkSpacesを使うなら、Wyseの端末を買ってシンクライアント化するのも面白そうではある

ちなみに、

この記事は、富士通のChromebook(14F)で、下書きはDynalistを使って、最終的な整形とgit pushはCloud9を使って書いています。また、構成イメージはdiagrams.netで書きました。

2023/01/09追記

結局、GitHub Pagesに戻しました。

AWS Certified Cloud Practitioner合格記

Thu, 16 Dec 2021 00:24:12 +0000

AWS認定資格の登竜門である「AWS Cloud Practitioner」を受験し、合格したので記録として残します。

バックグラウンド

SIerで、DCの物理配線〜アプリ開発、PMまで幅広く。オンプレも仮想基盤（プライベートクラウド）は利用した経験あり
その後、コンサルファームに移籍
プライベートでは広く浅く勉強するも、パブリッククラウドに対する疑心暗鬼は絶えず

とは言っても、今や猫も杓子もパブリッククラウド（また？）、内製！ローコード！の再燃（何回目や……）もあり、いよいよ勉強しなければと思いつつ、仕事でクラウドを使うこともなかったので、体系的に勉強するために勉強・受験しました。

勉強方法

私は以下で勉強をしました。特にAWS Cloud Practitioner Essentialsは、AWSが何たるかを手っ取り早く掴むのに非常に分かりやすいリソースです。

AWS Skill Builder - AWS Cloud Practitioner Essentials (Japanese)(日本語実写版)
AWS認定資格試験テキスト AWS認定クラウドプラクティショナー
【2022年版】この問題だけで合格可能！AWS 認定クラウドプラクティショナー模擬試験問題集（7回分455問）

合格率は不明ですが（※公表されていない）、ネットの情報を見ていると簡単な資格と錯覚するケースがあるようです。ですが、勉強しないと普通に落ちます。ただし、勉強しても落ちます。何が問われるのかは、模擬試験問題などを見るとわかります。

点数

799点 / 1,000点（※ビミョー）

今後

以下を取得して、次の仕事を探したい。

AWS Certified Solutions Architect - Associate
AWS Certified DevOps Engineer - Associate
AWS Certified SysOps Administrator - Associate

dnfでRepository is listed more than once in the configurationが表示された場合の対応

Sat, 08 May 2021 20:45:53 +0000

結論としては、/etc/yum.repos.d/の配下に別名で、中身が（ほぼ同じ）ファイルが2つ存在したための警告メッセージであったため、重複しているものを無効にすることでメッセージの出力を抑制した。

Shell
$ ls -alh /etc/yum.repos.d/
合計 60K
drwxr-xr-x. 1 root root 664 5月 8 19:48 .
drwxr-xr-x. 1 root root 5.3K 5月 8 19:51 ..
-rw-r--r--. 1 root root 190 4月 28 21:29 1password-beta.repo
-rw-r--r--. 1 root root 210 5月 7 01:01 1password.repo
-rw-r--r--. 1 root root 311 1月 26 14:48 _copr_phracek-PyCharm.repo
-rw-r--r--. 1 root root 728 4月 29 02:31 fedora-cisco-openh264.repo
-rw-r--r--. 1 root root 1.3K 4月 29 02:31 fedora-modular.repo
-rw-r--r--. 1 root root 1.4K 4月 29 02:31 fedora-updates-modular.repo
-rw-r--r--. 1 root root 1.4K 4月 29 02:31 fedora-updates-testing-modular.repo
-rw-r--r--. 1 root root 1.4K 4月 29 02:31 fedora-updates-testing.repo
-rw-r--r--. 1 root root 1.3K 4月 29 02:31 fedora-updates.repo
-rw-r--r--. 1 root root 1.3K 4月 29 02:31 fedora.repo
-rw-r--r--. 1 root root 173 5月 8 19:48 google-chrome.repo
-rw-r--r--. 1 root root 1.5K 1月 26 14:48 rpmfusion-nonfree-nvidia-driver.repo
-rw-r--r--. 1 root root 1.4K 1月 26 14:48 rpmfusion-nonfree-steam.repo
-rw-r--r--. 1 root root 148 5月 1 21:00 skype-stable.repo
-rw-r--r--. 1 root root 154 5月 1 21:02 teams.

なぜか1passwordのrepoが2つ存在している。ので、これのうち一つをどこかに移してしまえば良さそう。というわけで、どちらを残すのか中身を確認してみる。

diff
$ diff 1password.repo 1password-beta.repo
2,3c2,3
< name="1Password Beta Channel"
< baseurl=https://downloads.1password.com/linux/rpm/beta/$basearch
---
> name=1Password
> baseurl=https://downloads.1password.com/linux/rpm/beta/x86_64
7c7
< gpgkey="https://downloads.1password.com/linux/keys/1password.asc"
---
> gpgkey=https://downloads.1password.com/linux/keys/1password.asc

細かい差分はさておき、注目すべき差分は 1password.repo の $basearch である。ここで、 $basearch には x86_64 が入る（see 6.3.3 Yum 変数の使用) ということなので、つまり2つのファイルに差分は見受けられない。

ゆえに、1password for Linux はbeta版であるので、/etc/yum.repos.d/1password-beta.repoを残す方針とする。

Bash
$ sudo mv 1password.repo 1password.repo.old
$ sudo dnf update
メタデータの期限切れの最終確認: 1:56:41 時間前の 2021年05月08日 18時22分17秒 に実施しました。
依存関係が解決しました。
行うべきことはありません。
完了しました!

ついでに、/etc/yum.repos.d/google-chrome.repoも削除しておいた（Firefoxに移行したため）。

Rcloneの使い方

Wed, 05 May 2021 21:56:43 +0000

Rcloneとは

Rclone is a command line program to manage files on cloud storage. It is a feature rich alternative to cloud vendors’ web storage interfaces. Over 40 cloud storage products support rclone including S3 object stores, business & consumer file storage services, as well as standard transfer protocols.
― Rclone, Rclone

つまるところ、Rcloneはクラウドストレージを操作するためのコマンドライン・インタフェースであり、40を超えるクラウドサービスに加え、標準的な転送プロトコル（SFTP等）もサポートしているというものです。

使い方

使用する前に、設定を行う必要があります。ここでは、onedriveを例に記載します。

**に囲まれている箇所が入力する箇所です。

Shell
$ rclone config
2021/05/05 21:34:53 NOTICE: Config file "/home/sonohen/.config/rclone/rclone.conf" not found - using defaults
No remotes found - make a new one
n) New remote
s) Set configuration password
q) Quit config
n/s/q> n
name> **onedrive**
Type of storage to configure.
Enter a string value. Press Enter for the default ("").
Choose a number from below, or type in your own value
 1 / 1Fichier
 \ "fichier"
 2 / Alias for an existing remote
 \ "alias"
 3 / Amazon Drive
 \ "amazon cloud drive"
 4 / Amazon S3 Compliant Storage Providers including AWS, Alibaba, Ceph, Digital Ocean, Dreamhost, IBM COS, Minio, and Tencent COS
 \ "s3"
 5 / Backblaze B2
 \ "b2"
 6 / Box
 \ "box"
 7 / Cache a remote
 \ "cache"
 8 / Citrix Sharefile
 \ "sharefile"
 9 / Compress a remote
 \ "compress"
10 / Dropbox
 \ "dropbox"
11 / Encrypt/Decrypt a remote
 \ "crypt"
12 / Enterprise File Fabric
 \ "filefabric"
13 / FTP Connection
 \ "ftp"
14 / Google Cloud Storage (this is not Google Drive)
 \ "google cloud storage"
15 / Google Drive
 \ "drive"
16 / Google Photos
 \ "google photos"
17 / Hadoop distributed file system
 \ "hdfs"
18 / Hubic
 \ "hubic"
19 / In memory object storage system.
 \ "memory"
20 / Jottacloud
 \ "jottacloud"
21 / Koofr
 \ "koofr"
22 / Local Disk
 \ "local"
23 / Mail.ru Cloud
 \ "mailru"
24 / Mega
 \ "mega"
25 / Microsoft Azure Blob Storage
 \ "azureblob"
26 / Microsoft OneDrive
 \ "onedrive"
27 / OpenDrive
 \ "opendrive"
28 / OpenStack Swift (Rackspace Cloud Files, Memset Memstore, OVH)
 \ "swift"
29 / Pcloud
 \ "pcloud"
30 / Put.io
 \ "putio"
31 / QingCloud Object Storage
 \ "qingstor"
32 / SSH/SFTP Connection
 \ "sftp"
33 / Sugarsync
 \ "sugarsync"
34 / Tardigrade Decentralized Cloud Storage
 \ "tardigrade"
35 / Transparently chunk/split large files
 \ "chunker"
36 / Union merges the contents of several upstream fs
 \ "union"
37 / Webdav
 \ "webdav"
38 / Yandex Disk
 \ "yandex"
39 / Zoho
 \ "zoho"
40 / http Connection
 \ "http"
41 / premiumize.me
 \ "premiumizeme"
42 / seafile
 \ "seafile"
Storage> **26**

*See help for onedrive backend at: https://rclone.org/onedrive/*

OAuth Client Id
Leave blank normally.
Enter a string value. Press Enter for the default ("").
client_id>**[Blank]**
OAuth Client Secret
Leave blank normally.
Enter a string value. Press Enter for the default ("").
client_secret>**[Blank]**
Choose national cloud region for OneDrive.
Enter a string value. Press Enter for the default ("global").
Choose a number from below, or type in your own value
 1 / Microsoft Cloud Global
 \ "global"
 2 / Microsoft Cloud for US Government
 \ "us"
 3 / Microsoft Cloud Germany
 \ "de"
 4 / Azure and Office 365 operated by 21Vianet in China
 \ "cn"
region> **1**
Edit advanced config? (y/n)
y) Yes
n) No (default)
y/n> **n**
Remote config
Use auto config?
 * Say Y if not sure
 * Say N if you are working on a remote or headless machine
y) Yes (default)
n) No
y/n> **y**
If your browser doesn't open automatically go to the following link: http://127.0.0.1:53682/auth?state=xxx
Log in and authorize rclone for access
Waiting for code...
**ここでブラウザが開くので、Microsoftアカウントでログインし、画面の指示に従う。**
Got code
Choose a number from below, or type in an existing value
 1 / OneDrive Personal or Business
 \ "onedrive"
 2 / Root Sharepoint site
 \ "sharepoint"
 3 / Sharepoint site name or URL (e.g. mysite or https://contoso.sharepoint.com/sites/mysite)
 \ "url"
 4 / Search for a Sharepoint site
 \ "search"
 5 / Type in driveID (advanced)
 \ "driveid"
 6 / Type in SiteID (advanced)
 \ "siteid"
 7 / Sharepoint server-relative path (advanced, e.g. /teams/hr)
 \ "path"
Your choice> **1**
Found 1 drives, please select the one you want to use:
0: (personal) id=xxx
Chose drive to use:> **0**
Found drive 'root' of type 'personal', URL: https://onedrive.live.com/?cid=xxx
Is that okay?
y) Yes (default)
n) No
y/n> **y**
--------------------
[onedrive]
type = onedrive
region = global
token = {"access_token":"","token_type":"Bearer","refresh_token":"","expiry":"2021-05-05T22:36:16.565429024+09:00"}
drive_id = xxx
drive_type = personal
--------------------
y) Yes this is OK (default)
e) Edit this remote
d) Delete this remote
y/e/d> **y**
Current remotes:

Name Type
==== ====
onedrive onedrive

e) Edit existing remote
n) New remote
d) Delete remote
r) Rename remote
c) Copy remote
s) Set configuration password
q) Quit config
e/n/d/r/c/s/q> **q**

使い方

リモート側のファイルを確認する

Shell
$ rclone ls onedrive:

リモートからファイルをダウンロードする

Shell
$ rclone copy -P onedrive: /path/to/download

他のコマンドは、詳細を参照。

2021年のGWを振り返る

Wed, 05 May 2021 20:27:56 +0000

2021年のGWの目標

以下の目標を立てていました。

自宅のレッツノートのFedora 33からFedora 34へのアップグレード¹
レッツノート²のスクロールをまともに動かすようにする
OneDriveからの脱却のため、NAS（LANDISK）にファイルを移管する
Emacsでeasy-hugo, wanderlust, org-agenda, org-capture, org-roamの設定
GnuCashで使っているMySQLのバックアップ自動化
「TCP/IPの絵本」の読了
「ネットワークはなぜつながるのか」の読了
「マスタリングTCP/IP」の読了

実績

アップデート完了。不具合として認識しているのは、(1)Virt Managerを使った場合のUSB Redirectionの動作不良（詳細）、(2) Pipewireがレッツノート上で機能しない（音が出ない）、の2点。
systemdを使用し、サスペンドからレジュームした際にi2c_hidをmodproveするようにした。これが実に快適。
Personal Valutのほかは、LANDISKに移行完了。同時に、自宅のネットワークに接続している場合、自動でmountするように自動化した。
いずれも設定完了。
今週末対応予定。
読了。
途中まで読んだ（10%程度）。
未着手。

今後実施したいこと

1passwordに月会費を支払っているので、bitwarden等に移行したい。
低レベルプログラミングへの着手。

毎年支払っているOffice 365の年間サブスクリプション（年額約1万3千円程度）を節約するため、徐々にMicrosoftから離れつつあります。 ↩︎
CF-SV9を使用中。サスペンドからレジュームした際に、タッチパッドの動作が非常に遅くなり、操作不能になります。 ↩︎

VS CodeからDebian on WSL2.0にアクセスできずに焦った話

Mon, 12 Apr 2021 19:29:25 +0000

発生した問題

VS Codeが出力したエラーメッセージは次の通りでした。VS Code Server for WSL closed unexpectedly.と表記されている通り、WSL向けのVS Code Serverへの接続が予期しない理由により切断された、ということです。

プレーンテキスト
[2021-04-12 10:24:41.224] Resolving wsl+debian, resolveAttempt: 1
[2021-04-12 10:24:41.302] Starting VS Code Server inside WSL (Debian)
[2021-04-12 10:24:41.302] Extension version: 0.54.6, Windows build: 19042. Multi distro support: available. WSL path support: enabled
[2021-04-12 10:24:41.302] No shell environment set or found for current distro.
[2021-04-12 10:24:41.510] Probing if server is already installed: C:\Windows\System32\wsl.exe -d Debian -e sh -c "[ -d ~/.vscode-server/bin/08a217c4d27a02a5bcde898fd7981bda5b49391b ] && printf found || ([ -f /etc/alpine-release ] && printf alpine-; uname -m)"
[2021-04-12 10:24:41.775] Probing result: found
[2021-04-12 10:24:41.775] Server install found in WSL
[2021-04-12 10:24:41.777] Launching C:\Windows\System32\wsl.exe -d Debian sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" 08a217c4d27a02a5bcde898fd7981bda5b49391b stable .vscode-server 0 '}
[2021-04-12 10:24:41.968] sh: 1: /mnt/c/Users/sonohen/.vscode/extensions/ms-vscode-remote.remote-wsl-0.54.6/scripts/wslServer.sh: Input/output error
[2021-04-12 10:24:41.969] VS Code Server for WSL closed unexpectedly.
[2021-04-12 10:24:41.969] For help with startup problems, go to
[2021-04-12 10:24:41.969] https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips
[2021-04-12 10:24:41.981] WSL Daemon exited with code 0

原因

不明。この事象が発生している時に、Windows TerminalからDebian on WSL2.0にアクセスし、以下のコマンドを発行したところ、エラーが発生した。cdの後にlsが発行されているのは環境によるものである。¹

Shell
% cd /mnt
ls: 'c' にアクセスできません: 入力/出力エラーです

解決方法

VS Codeを閉じた後、コマンドプロンプトで以下のコマンドを実行し、その後、再度VS Codeを起動する。

PowerShell
wsl --shutdown

参考にしたサイト

WSL2 cannot access ‘c’: Input/output error

~/.zshrcに、chpwd() { ls -ltr --color=auto }を登録しているため、cd直後にlsコマンドが発行されている。 ↩︎

WSL2で使っているソフトウェア

Tue, 02 Jun 2020 01:08:36 +0000

今のところ使っているアプリケーションは以下の通り。
- GNU Emacs
- tmux
- tig: gitのクライアント
dotfilesの管理も始めた。
Windows Terminalは，Alt+Enterでフルスクリーンになる。
- 上記の環境だと，もはやWindowsなのかLinuxなのか分からないですね。

放送大学大学院の通信指導課題提出結果と今後の作戦について

Sun, 24 May 2020 14:58:21 +0900

履修している科目は以下の通り。

人的資源管理（‘18）
社会的協力論（‘20）

結果は，どちらも満点。人的資源管理については，一部（というか半分）の回答は，テキストを見ながら実施したので当然といえば当然ではある。

社会的協力論は引き続き真面目に受講するとして，人的資源管理については理解が不十分な箇所（特に人的資源管理の歴史や，人事等級・考課制度とモチベーションの関連）があるので，今後，復習を実施していく必要があると認識。復習だからそんなに時間はかからないと思うが，最後にまとめてやろうとすると大変なので，通常の講義の予復習や研究課題レポートの執筆と並行して計画的に進めていくことにしたい。早速，org-modeで管理しているtodo管理表に，「人的資源管理の復習計画を立てること」というタスクを追加した。

終わり。

Windows Subsystem for Linux (WSL) 2への変換

Wed, 20 May 2020 14:37:27 +0900

バージョンの確認

PowerShell
PS C:\Users\sonohen> wsl -l -v

プレーンテキスト
 NAME STATE VERSION
* Debian Stopped 1

変換を試みる

PowerShell
PS C:\Users\sonohen> wsl --set-version Debian 2

プレーンテキスト
変換中です。この処理には数分かかることがあります...
WSL 2 を実行するには、カーネル コンポーネントの更新が必要です。詳細については https://aka.ms/wsl2kernel を参照してください

以下のURLにアクセスして、wsl-update_x64.msiをダウンロードする。

手順 4 - Linux カーネル更新プログラムパッケージをダウンロードする

セットアップが終わったら，再度チャレンジする。

PowerShell
PS C:\Users\sonohen> wsl --set-version Debian 2

プレーンテキスト
変換中です。この処理には数分かかることがあります...
WSL 2 との主な違いについては、https://aka.ms/wsl2 を参照してください
Windows の仮想マシン プラットフォーム機能を有効にして、BIOS で仮想化が有効になっていることを確認してください。
詳細については、https://aka.ms/wsl2-install を参照してください

そもそもの手順を実施していなかったので実施する。

仮想バーチャルマシンサービスのインストール

管理者としてPowerShellを実行する。

PowerShell
PS C:\WINDOWS\system32> dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

プレーンテキスト
展開イメージのサービスと管理ツール
バージョン: 10.0.19041.1

イメージのバージョン: 10.0.19041.264

機能を有効にしています
[==========================100.0%==========================]
操作は正常に完了しました。

WSL2を既定のバージョンとして設定する

PowerShell
PS C:\WINDOWS\system32> wsl --set-default-version 2

プレーンテキスト
WSL 2 との主な違いについては、https://aka.ms/wsl2 を参照してください

これで今後インストールされるWSLはバージョン2となる。

変換する

PowerShell
PS C:\WINDOWS\system32> wsl --set-version Debian 2
PS C:\WINDOWS\system32> wsl -l -v

プレーンテキスト
	NAME STATE VERSION
* Debian Stopped 2

Hugoをインストールする

Wed, 06 May 2020 11:36:53 +0900

Hugoを導入する

Bash
$ hugo new site shared/site
$ cd site
$ code config.toml
baseURL = "http://sonohen.github.io/"
languageCode = "ja-JP"
title = "sonohen's tech log"
$ hugo

ここの時点で，publicディレクトリーが作られていることを確認する。

テーマの導入

Hugo Themeにすぐに使えるテーマが掲載されている。

今回は，Hugo Theme Minosを利用する。

Bash
$ cd themes/
$ git clone --depth 1 https://github.com/carsonip/hugo-theme-minos
$ code ../../config.toml
theme = "hugo-theme-minos"
paginate = 10
[params]
 smartToc = true
$ hugo

GitHub Pageの設定

blogレポジトリを作る
1. これはprivateレポジトリで良い
sonohen.github.ioレポジトリを作る

Gitの設定

public/は，サブモジュールとして管理する。レポジトリが別なため。

Bash
git submodule add -b master git@github.com:sonohen/sonohen.github.io.git public

以下のエラーではまったでござる。

Bash
$ git submodule add -b master git@github.com:sonohen/sonohen.github.io.git public
A git directory for 'public' is found locally with remote(s):
origin https://github.com/sonohen/sonohen.github.io.git
If you want to reuse this local git directory instead of cloning again from
git@github.com:sonohen/sonohen.github.io.git
use the '--force' option. If the local git directory is not the correct repo
or you are unsure what this means choose another name with the '--name' option.

この場合，古いsubmodule情報が".git/“以下に残っていることが原因なので，以下のディレクトリとファイルの中身を確認して，古いファイルを削除してやる必要がある。

.git/modules/
.git/config

こうならないためには，以下のようにsubmoduleを削除しましょう。

Bash
git submodule deinit <消したいsubmodueへのパス>
git rm <消したいsubmoduleへのパス>

Visual Studio Codeを設定して記事を書く

Hugofy（akmittal.hugofy）をインストールする。
Hugofy: New Postを選択する。
記事を書く。
Hugofy: Buildを選択する。
siteとpublicをcommit&pushする。

参考

[git]git submodule addでエラー「A git directory for ‘[指定モジュール]‘ is found locally with remote(s):」

Posts on sonohen's tech blog

Cachixを使用する

課題と目的

日常の運用

実装

configuration.nix

flake.nix

.github/workflows/nixos-parts-build.yml

結果

ビルドの所要時間と容量

今後の課題

NixOSでZFSからデータを救出する

概要

環境

目的

データ移行の流れ

現状の把握

ディスクの状況

ZFS の状態

LUKS鍵の取り出し

ZFSパーティションのマウントとデータの移行

ディスクのフォーマットと /home へのマウント

rpool の切り離し

パーティションを作成する

configuration.nix の修正

後始末

感想

Ubuntu 26.04 LTSでScanSnap S1100を使う

ファームウェアを配置する

epjitsu.confのファームウェア指定を変更する

ScanSnap S1100の認識を確認する

gscan2pdfでスキャンする

Blenderの2回目の起動でウィンドウが透明になる：XWayland経由で回避する

発生環境と症状

初期設定でも再現し、ログは描画処理まで進んでいた

Waylandを無効にすると、2回とも起動できた

アイコンからもXWayland経由で起動する

DockerのAppArmor適用失敗：プロファイルの読み込みとreadby権限で対処

この環境でのAppArmorとbubblewrapの役割

発生したエラーと環境

起動時の拒否ログから、プロファイル未読み込みを確認する

プロファイルを読み込んで起動エラーを解消した

起動後の拒否ログから、readby権限を追加する

修正版をホストへ配置し、再起動後も読み込めるようにする

適用結果と再起動後の確認

同じ症状を調べるときの確認順序

CodexでレシートPDFからBeancountへの仕訳登録を自動化した

Codexが判断し、Pythonが書き込む

抽出テキストだけで転記しない

支払方法はファイル名に書く

PDFの数と取引の数を分ける

1取引ずつbean-checkを通す

残高照合で未記帳のチャージを見つけた

サスペンド復帰後にNextDNSが応答しなくなる問題を調べ、自動再起動を設定した

調査した環境

Wi-Fiが戻ってもDNS問い合わせは失敗していた

接続イベントから再起動する

dispatcher、timer、serviceの内容

接続イベントを受け取るスクリプト

5秒後に処理するタイマー

NextDNSを再起動するサービス

実機へのインストール

検証状況と復帰後の確認

アンインストール

EmacsでCodexを使う環境を整え、関連書籍を買った日

Codexをインストールする

Emacsではvtermを使うことにした

Codex用のDocker環境を作る

bubblewrapとAppArmorの設定で悩む

Ubuntuで行ったほかの作業

aptの段階的な更新を知った

localsearchを一時的に止めた

ibus-skkを入れた

Codexの本を買った

指示に目標と完了条件を書く

Plan modeを使う場面を考える

オクトパスエナジーに切り替えた

契約切り替えの経緯

現在までの感想

比較的、割安な時間帯に寄せやすい

`configuration.nix`

`flake.nix`

`.github/workflows/nixos-parts-build.yml`

`ZFS` の状態

`rpool` の切り離し

`configuration.nix` の修正

`libgccjit.so` が見つからない

`Missing 'lexical-binding' cookie` という警告が出力される

to　ファストドクター

to　デジタル庁

`.claude`の構成