2026年5月のメモ

AI, Agentic Coding

• 契約等の都合から、引き続き Claude Code, Opus 4.7~4.8 中心に利用
• 新規開発的なタスクが2つ同時に発生したので、なるべく長い時間、自律的に稼働させることを目指して試行錯誤していた
  • グローバルの CLAUDE.md でシェル芸等をブロックしたり、 permissions と Hook を組み合わせて、シンプルに安全なコマンドだけを使って稼働させることを目指した
  • それでもすぐに忘れて Read ツールではなくシェルで何とかしようとしてくるのでなかなか安定しない
• 引き続き、 cc-sdd v3.0 を利用して SDD を行っている
  • オーケストレーションツールを使っても、矛盾がなくなるまでレビューさせているとそんなに効率化された感じがないので難しい

DNS 関連

• 今月も DNSSEC を調査・検討した
• そんな矢先、 .de ドメインが不通になったというニュースを見て、改めて運用の難しさを知る

blog.cloudflare.com

• そもそも DNS キャッシュポイズニングを防ぐ唯一の手段というわけではなく（多層防御の一つの認識）、端的に見合わないことは理解

• DNSSec World Map ( ) によると、5月31日時点で、日本の普及率は僅か 14.45 %というのも納得

  DNSSEC World Map

• タイムリーに『DNSがよくわかる教科書 第2版』が発売されたところだったので、購入して読み進めた。とてもわかりやすい

  https://www.sbcr.jp/product/4815622657

• CAA レコードについては DNSSEC と併用がベターだが、コスパは良さそうなので対応して損はなさそうだった。

• その他、メール関連の定番の設定も見直した

  • これまではメールをちゃんと届けるための設定を気にすることが多かったが、送信しない場合の保護を行なった
    • 参考： Cloudflare 『メールを送信しないドメインを保護する方法』

  www.cloudflare.com

• Mythos の件もあってセキュリティの点検機運高まるなど、何かとセキュリティ関連に触れることが多い5月だった。

その他

• App Runner の新規が終わってしまったので、 ECS Express Mode を少し調べた
  • ポジションとしては置き換えで、やはりまだプロダクションワークロードなら Fargate かなという印象

• Fargate で運用する時、以前は CloudFront -> ALB -> Fargate の時にカスタムヘッダ検証とかの理解だった

• それが、CloudFront VPC Origins を使って ALB を Internal にしようね、というのがトレンドだと知った。早速この構成で使ってみようと思う

• VSCode の Extension のサプライチェーン攻撃の件が話題になったので、棚卸しをした

  • 自動更新を切ったり、もう使っていないものを消したり
  • ついでに nvim plugins も整理した。chezmoi ディレクトリで Claude に整理してもらった。良い時代。

• デスクでは2年前くらいに購入した HomePod を使っていたが、突然勝手に Apple Music ? から知らない音楽を流し始めた

  • 知らない音楽なだけならまだしも、音量がデカくなったり小さくなったり、帰宅すると勝手に流れていたり、かなり不安定な状況
  • 調べると、世界中で発生している不具合っぽく、再セットアップ等も試したがダメそうなので電源を抜いた
  • ほとんど Apple 製品を使っているくらい好きであるだけに、最近の品質低下が本当に残念

2026年4月のメモ

広く浅く触ることが多くなったため、触れたものや学んだことをメモしていく📝

AI, Agentic Coding

• ターミナルは cmux を使うようになった。 以前は WezTerm をカスタマイズしていたが、今年からは流行りの Ghostty を併用。13インチの MBA でも 40インチのウルトラワイドディスプレイでも、複数の窓を少しずつ重ねて複数プロジェクトを回していたが、再起動後の復元などが面倒だったので移行した。殆どカスタマイズはしてなかったとはいえ、 Ghostty の設定ファイルもそのまま使えて良い感じ
• Claude は Max plan 5x から Pro に Downgrade した。これは SRE 的な方面に関心が傾いているタイミングなので一時的な変更の予定
• Google Workspace の Business Plus は継続中。3ヶ月の割引期間が過ぎたので月額3,000円だけど、個人事業主としての諸々の維持と Gemini で便利に使っている

VPN

• VPN 環境を整備した。接続先がホワイトリストなので IP を固定したい、コントロールプレーンも含めてセルフホストしたいが仮想サーバは NG、もちろんコスト最適化も図りたいというユースケース
• Twingate はコントロールプレーンがクラウドサービスらしいし、Headscale は独自ドメインが実質必須で、この用途のために準備するのは微妙だった
• 結局は定番らしい Client VPN + NAT Gateway （+ Elastic IP） の構成を取った。コストを見守りつつ、今後評価したい
• Entra ID で SAML 認証も行いたかったが、OpenVPN 側の制約でスマホや Apple Silicon 端末から利用できなくなってしまうということで、仕方なく証明書を管理するコマンド集を Claude に作ってもらって運用することにした

ドメイン

• Google Workspace を契約した後に購入していた独自ドメインを寝かせていたので、AWS の ACM で管理するようにした
• サブドメインを作って、そのホストゾーンを管理する必要があり調べていた。AI とセキュリティ面を確認していたら DNSSEC の話題が出てきて、そういえばネスペでは出てくるけど全然馴染みがないなと思ったら、運用負荷が高いので（国によっては異なるが）全然普及していないとのことだった。導入するかどうかは別として、自動化ツールやリスク軽減方法をについて調べているところ

特定のプロダクトに向き合ったり、一つの機能にじっくり取り組んだりということは少なくなってきた。 トイルの解消したり改善系を回したりできるのは楽しいのだけど、以前よりも疲れるのは早くなったように感じる。

2025年ふりかえり

仕事

2024年12月に転職したのだけれど、約1年ということで転職前後から振り返り。

前職はベンチャーだったし、前々職も前々前職も含めて7年くらいは Web 界隈にいたことになる。 一方で転職先は公共系のシステムを開発する組織。マインドセットも変えないといけないだろうな、とは考えていた。 キャリアの最初は典型的な SIer で PjM だったので、ある意味では事業会社でスキルを身につけ、モダンな開発を学んで、再び元の環境に戻ったような形となった。そのため、どれだけそれらを活かせるのだろうか、という期待と不安があった。

で、1年ほど経験してみた結論としては、それほど以前と変わっていなかったというのが正直なところ。 大規模 PJ ではウォーターフォールだったり、前後の工程からのフィードバックループは存在しないし、システムや技術にそれほど明るくない人間が上流を決め、下流で歪みが起こる状況は相変わらず避けられないように見える。 ただこれは予想できたこと。時間と共に少しずつ信頼貯金を重ねて、アプローチしていくしかないと考えている。

幸いにしてモダンでアジリティ高く、また裁量を持って進められる仕事もあるため、モチベーションは維持できている。 下半期からはチームで開発者が自分一人のような状況が続いたが、スクラムマスターのペルソナを与えた Copilot と共に日々開発を続けている。

キャリア観

給与面と社会貢献性は前提として、その上でどのようなエンジニアとしてやっていくか、というところは常に悩ましい。 第3次 AI ブームの時は自分で選択肢を広げられるほど知識も経験もなかったが、今回は AI 業界という選択肢もあった。 それでも今回、公共系を選択したのは、世の中の人を幸せにするサービスに関わりたいというキャリア観によるものが大きかった。

とはいえ、やはり昔の環境が懐かしくもなる。 PdM が描いた青写真のもと、職能横断の少人数チームでチームビルディングのプラクティスを経て、心理的安全性が確保された環境で建設的な議論を重ねてプロダクト開発を行い、素早い失敗から学び、北極星を眺めながら高速な仮説検証を繰り返す。

そしてそれが生成 AI に関するプロダクトだったら絶対楽しいだろう。隣の芝生はいつだって青い。

エンジニアリング

一人でできる幅を広げようと試みた1年だった。 自室の壁に貼ったホワイトボードシートにレーダーチャートを描いて、 Backend, Frontend, Network, Cloud, Security を項目として置いて、目盛りを5段階くらいに設定した。

Backend は小さなチームなら TechLead をやらせてもらえるくらいなのでひとまず4と置く（もちろん、常に学び続けないといけないし、慢心できるレベルではないのは承知の上で）。

Frontend は前職で Nuxt.js -> Next.js 移行に少し関わったことと、 ChatGPT がリリースされたタイミングで React を触って画面を作っていたおかげで理解が進んだ。自分の中で一度地図が出来上がれば、あとは調べながら、 AI と協働すればよかろう。ということで3とした。 そこで、次のターゲットを Network に定めた。

Network

自分はネットワークに詳しくない。学部生の頃にネットワーク基礎を取ったり、あとは『マスタリング TCP/IP』 を眺めたりしたことがあるくらい（部屋の本棚にはある）。 Web エンジニアとして基本的なことはわかるが、ネットワークを設計したりとか、 AWS における様々な接続パターンなども詳細は把握していなかった（事業会社にはインフラエンジニアがいるもので、お世話になってばかりだった）。

思い立った時には年が明けて少し経っていたので、ギリギリで春のネットワークスペシャリストに申し込んだ。受かるとは思っていないが、試験駆動で多少は勉強するだろうという目論見。結果は普通にまだまだ頑張りましょうという感じだったが、世界観が掴めたのは大きかった。IPA の試験は CBT になるようだし、ちゃんと準備をしてまた挑みたい。

その後、気になっていた YAMAHA の業務用ルーターである RTX シリーズの新製品、 RTX 840 が発売されたので購入。 Raspberry Pi と繋げたり、 ISP の固定グローバル IP サービスを契約して VPN を設定してみたり、若干高すぎる遊びをしている。

yamaha_rtx840

PoE (Power over Ethernet) を試してみたい、という動機8割で無駄に導入された L2 スイッチ。 VLAN には活かせそうか。

Cloud

これは少し毛色が違っていて、春頃に AWS の構成図を描いて提出する機会があった。その際、上級資格を保持しているか、相当の経験があること、のような注釈が書かれていた。それなのにどういうわけか周辺に資格保有者がいなかったため、負けず嫌い？を発揮して、いっちょ取ってやるか、となった。

すぐに本屋では見かけたことのある AWS SAA の黒本を買ってきて学習を始めた。 Web に関するところは簡単、と思いきや、クラウドネイティブになってから AWS を使い始めた弊害。ECS や Lambda, Aurora などは余裕でわかるものの、 EC2 や EBS などの一般的にはボリュームゾーンのサービスの詳細や使い分けがわからない。分析や機械学習周りも詳しくない、ということで意外に勉強に時間を要して、取得は8月頃になった。

途中で少し飽きたり、自宅で受験するのは逆に辛いらしいという情報を得てリスケするなどした結果だった。 機械翻訳の日本語が意味不明という定番の問題にも遭遇しつつも800点だった。すぐに SAP の書籍も購入したものの、年内には取れそうもないために少しモチベが下がってイマココ。

生成 AI

一応振り返っておく。 年明けに Cursor を1年契約して、春頃には Claude Code に移ってただの高級エディタにするというあるあるを経て、Composer により復帰というところまでテンプレ。 業務では Copilot (主に Sonnet 4.5)を利用している。何も特徴的なこともない。

あるときプロンプトエンジニアリングについて説明をしたところ、おまえ詳しいならちょっと依頼できないかとお話をいただき、ある会社の開発チームに対して、「エンジニアのための生成 AI 活用」というお題でセミナー講師をさせていただいた。 2時間ほどの限られた時間ではあったが、生成 AI, LLM の仕組みから Agentic Coding, MCP 活用あたりまでを説明して質疑応答。何より資料作成の過程で改めて調べたり裏どりしたりといったことが自分にとっても良い学習機会となった。

副業

前職を辞めたタイミングで業務委託として契約していただいた。 Rust でリライトしてみる PoC というとても楽しいやつだったのだが、実装コストが大幅に下がった昨今、検証はすぐにできてしまった。あとは社員でも AI を使えばいけるよね、というところもあり、半年程度で終わってしまった。 単発を除くと本格的に副業を始めた1年だったが、良くも悪くも生成 AI の存在感を感じた1年だった。 自分の経験にもなる案件があれば、また何かやりたいと考えている。

個人事業主

副業開始のタイミングで税務署に開業届を出した。 知人の話などから青色申告するべきだろうと早々にわかっていたため準備をした。 また、屋号のドメインを取得して、Google Workspace の Business Plus プランを契約した。 Gemini や NotebookLM は学習されることを気にせずフル活用できるし、管理コンソールを触れるのも地味に楽しい。

google_workspace_admin

何かのキャンペーンで3ヶ月割引されている

来年はポートフォリオをちゃんと作ったり、個人の名刺やプレーリーカードを作ったりして、活動を広げていきたい。

良い睡眠のためにやっていること

最近、 @kuluna と話しているときに、なぜそんなにポケスリのスコアが良いのか、と聞かれた。 見返してみると、確かに大体80点代〜90点くらいを推移しており、💯の時もあった。

新卒でSEになった頃は22時23時の残業は当たり前で、眠りに着くのは午前2時頃だった。 始業が8時半だったので7時起きだとギリギリで、いつもリポDを片手に駅まで走っていたと記憶がある。 その頃は睡眠トラッキングなどなかったのでスコアも何もないが、きっと酷い数字だったのだろうと思う😇

事業会社に転職して慢性的な長時間残業がなくなり、始業も10時になった。 『スタンフォード式 最高の睡眠』を何気なく手に取り、睡眠のために色々気を使うようになった。 そして、コロナ禍リモートワークにより通勤がなくなった。 そんな3段階の変化があったように思う。

現在気をつけているのは、

• コーヒーは遅くても18時まで
• 退勤したらジョギング or 散歩
• 睡眠の90分前の入浴を意識
• 22時以降は固形物を食べない
• 0時を過ぎたら寝室へ向かう
• ポケモンGOプラスプラスのボタンを押したらそのまま布団に入る
• スマホはデスクの充電器に置き、寝室に持ち込まない
• 起きたらスマホを取りに行き、そのまま起きる（サイクルを固定する）

あとは、ブレインスリープのマットレス、枕、布団を一式揃えた。 プラシーボかも知れないが、寝起きは良くなったように感じている。

元々睡眠時間が長い方で、朝活をしていた時もあったが続かなかった。 子どもができたらこんなに眠れないのはわかっているので、今はできるだけ健康を維持したい。

npx で command not found になるとき

適当な Nuxt.js のプロジェクトを作ろうとしたら何故か command not found に。 キャッシュを消すことで解消した。

$ npx create-nuxt-app hello
sh: create-nuxt-app: command not found

$ which npx
/opt/homebrew/bin/npx

$ npx -v
9.4.0

$ npx clear-npx-cache
Need to install the following packages:
  clear-npx-cache@1.0.1
Ok to proceed? (y) y

$ npx create-nuxt-app hello
Need to install the following packages:
  create-nuxt-app@5.0.0
Ok to proceed? (y)

macのメニューバーに今日の残り分数を表示する

少し前に、『1440分の使い方』という本を読んで感銘を受けた。

www.amazon.co.jp

そこでふと思いつきで、Macbook のメニューバーに1日の残り分数を出してみた。

xbar

メニューバーのカスタマイズというと SwiftBar というのがあったのだけど、開発が止まったらしい。 後継として xbar というのがあったので、それを使ってみることにした。

github.com

最近仕事でよく使っているGo言語もサポートしているので、ここでも使ってみることにした。

Code

unixtimeで差分を計算して表示するコードを書いた。 さっと適当に書いたものなので厳密ではないかもしれないが、ここでは許容した。

package main

import (
    "fmt"
    "time"
)

func main() {
    // 今日 23:59:59 の unixtime を取得する
    t := time.Now()
    loc, _ := time.LoadLocation("Asia/Tokyo")
    // NOTE: 常に今日の 23:59:59 にすることで閏年を考慮しなくて済む
    dt := time.Date(t.Year(), t.Month(), t.Day(), 23, 59, 59, 0, loc)
    lastUnixTimeToday := dt.Unix()

    // 現在の unixtime を取得する
    currentUnixTime := time.Now().Unix()

    // 差分を計算
    diff := lastUnixTimeToday - currentUnixTime

    // 残り分数として表示
    fmt.Println(diff/60)
}

設定

$ go build main.go
$ mv ./main ~/Library/Application\ Support/xbar/plugins/file.1s.cgo

完成

countdown

初めてのドメインモデリングから得た学び

この記事は、ドメイン駆動設計（ＤＤＤ） Advent Calendar 2021  22日目の記事です。

こんにちは、 @suzushin54 です。 Showcase Gig という会社で、O:der Table というモバイルオーダーのプロダクトを開発しています。

プロダクトや会社の紹介については、以下の記事をご覧いただければと思います。

note.com

現在の仕事で幸運にもドメインモデリングをする機会に恵まれました。これまで書籍を読んだりイベントに参加するなどして学習はしていたもの、初めての経験でした。

今回は会社のブログではないので、用語などを一般化した上で個人的な感想や反省、工夫を残していこうと思います。

環境

メンバー

6~7名の比較的よくあるプロダクトチームです。

ドメインエキスパートの招聘

PdMとManager, そしてカスタマーサポートの方にも参加してもらいました。この3名は日頃、同じチームとして活動しているわけではないのですが、スクラムのセレモニーなどには適宜参加してもらっています。業界やプロダクトに対する造詣が深く、まさにドメインエキスパートと言える存在です。

事前準備

はじめに、チーム内での認識を合わせることを目指しました。

今回、ドメイン駆動設計の経験者はいませんでしたが、DDD本を読んだことがあり知識はある人、増田さんの現場で役立つシステム設計の原則の社内輪読会に参加していた人、なんとなく聞いたことがある人、まったく知らない人、などなど、認識のレベルもバラバラでした。

とはいえ、これまた諸般の事情により、あまり時間がありません。今回はみんなで、松岡さんのドメイン駆動設計 モデリング/実装ガイドの輪読を行い、ドメインモデリングに入る最低限として以下の認識を合わせました。

• そもそも DDD とは何か
• なぜ今回採用したのか
• どのようなメリットがある手法で、今後何を期待しているのか
• ドメインモデルとは、ドメインモデリングとは

booth.pm

※ 話としては前後しますが、プロジェクトの見積の都合でユースケースは既に一覧化していました。

ドメインモデリングの実施

ドメインモデリングはオンラインホワイトボードツールの miro で行いました。日頃からレトロスペクティブなどで使い慣れていたので、ここでの戸惑いはありませんでした。

一方で、実際にやってみてから気づくことが多々ありました。

やっぱりデータモデリングと混同する

これはあるあるかと思います。事前に違いとして、以下を確認していました。

• ドメインモデルはデータモデルとは異なる
• ドメインモデリングにおいて永続化は関心事ではない
• データモデルは永続化のためのものでありアプリケーションの都合である
• ドメインモデルはドメインの問題を解決するためのもの

しかし実際にクラス図のような図を前にすると、こういう属性があって、こういうデータができて...ということをエンジニアは考えがちなのだと実感しました。

従来のソフトウェア開発の経験から来る副作用のようなものですが、注意していれば気づくこともできるので、その都度修正していきました。

ドメインモデルの種類？

ここはまだあまり考えが纏まっていないのですが、モデルを洗い出していると静的なモデルと、そうではないモデルがあるように感じました。例えば、店舗モデルや商品モデルなど、実体があるものは前者のイメージで、注文モデルや会計モデルは後者です。前者の種類のモデルが状態を保つと若干の違和感があります（有効/無効などは当然あるのですが）。

また、元となるデータがあって、それが一時的に有効になっているようなモデルも表現に悩みました。例えば、焼肉が食べ放題のお店にいろんな料理の掲載された「メニュー」があるとします。この「メニュー」を元に120分間の食べ放題がスタートすると、「有効となったメニュー」のようなモデルが生まれたりするのですが、こういったところはまだ洗練されていない感覚があります。

貧血不可避なモデル

ひととおりモデルが出揃ったタイミングで振る舞いを書き出そうとしたのですが、結果としてここでは不要だったかもしれません。というのも、実際に書いてみた振る舞いも実装の段階になると「なんか違う」ということが多かったです。振る舞いとして書いたけどドメインイベントなのではないか。このモデルが振る舞いとして持つには集約を見直さなければならない、などなど。

また、これまで私たちが触っていたシステムはトランザクションスクリプトになっていることが多かったので、ドメインモデルの振る舞いをイメージするのは想像以上に難しかったです。実際に実装フェーズに入ってから出てきた振る舞いも多く、ある程度で切り上げて試行錯誤のサイクルを回す方が効率的でした。

Tips的なもの

付箋や吹き出しのルールを決めないと無秩序になる

意外にこれは大事だなと思いました。

あれこれ書き込んでもらうことは議論を促進させるためにも歓迎すべきことですが、各々が好きな色で「（単なる）メモ」、「疑問点」、「ドメインエキスパートの見解」、「現行システムの仕様」などを書き出すと、あとで整理するときに消して良いのか残すべきなのか、はたまた既に解決した疑問なのかなどがわかりづらくなりました。

あらかじめ凡例と雛形を用意しておくと書き込む心理的な障壁も下げられて良さそうです。

早めにドメインモデルを実装する

環境にも寄りますが、基本的にドメインモデル（ Entity, Value Object ) の実装はそれだけで完結できます。画面やEndpointを用意する必要がなく他の開発作業とは切り離して実行できるので、試行錯誤のサイクルを回しやすいと感じました。

おわりに

初めての経験でしたが、当たり前のことながら、やってみてわかることがたくさんありました。また実装に入った時に結構詰まってしまう感覚があったので、次回からはロバストネス図を描いてみることにしました。新しい学びがあったら、こちらも記録していきます。

これからも試行錯誤を繰り返し、良いドメインモデリングができるように励んでいこうと思います！