wan0ri Lab

Security Hub CSPMの是正対象を3つに分類して進める方法

Sun, 27 Sep 2026 21:00:00 +0900

TL;DR

Security Hub CSPM の Finding を洗い出した後は、すべてを同じ進め方で扱わず、横展開できるもの・顧客と合意が必要なもの・すぐ直せるものに分類すると計画を立てやすくなります。
3分類は排他的ではありません。1つの Finding が「横展開できる」かつ「顧客との合意が必要」に該当することもあります。
Severity だけで順番を決めず、変更影響、判断者、作業量、コスト、ロールバック方法まで含めて優先順位を決めることが重要です。

はじめに

前回の記事では、Security Hub CSPM の Finding から、どの Control ID がどのリソースに対して失敗しているかを特定する方法を整理しました。

https://wan0ri.com/posts/2026/08/30/which_control_is_failing_for_which_resource/

対象リソースを特定できれば、次はいよいよ是正です。

ただし、一覧に出てきた Finding を上から順番に直していけばよいとは限りません。実際には、同じコントロールでもリソースの用途や構成が異なり、変更による影響も変わります。

そこで私は、切り分けた Finding を次の3つの観点で整理すると進めやすいと考えています。

横展開できるもの
顧客と合意が必要なもの
すぐ直せるもの

この記事では、それぞれをどう判断し、実際の是正計画へ落とし込むかを整理します。

まず前提: 3つは排他的な分類ではない

最初に押さえておきたいのは、この3つが完全に別々の箱ではないことです。

たとえば、同じ Control ID が複数の S3 バケットで失敗していれば「横展開できるもの」に該当します。一方で、バケットポリシーの変更によって外部システムとの連携に影響するなら、「顧客と合意が必要なもの」にも該当します。

つまり、この3つは対象を一意に分けるラベルというより、是正方法を決めるための判断軸として使う方が分かりやすいです。

判断軸	確認したいこと
横展開できるもの	同じ原因・同じ手順で複数リソースを是正できるか
顧客と合意が必要なもの	技術担当者だけでは変更可否を判断できないか
すぐ直せるもの	影響が限定的で、手順とロールバックが明確か

1. 横展開できるもの

横展開できるものとは

横展開できるものは、同じ原因で失敗している複数リソースに対して、共通の調査方法や是正手順を適用できるものです。

代表的には、次のようなケースです。

同じ Control ID が複数リソースで FAILED になっている
同じ Terraform module や CloudFormation template から作られている
同じ命名規則や用途を持つリソースで設定差分が発生している
同じ AWS Organizations 配下の複数アカウントで同じ設定不備がある

判断するときに見る項目

横展開の可否を判断するときは、次の項目を並べて確認します。

Security Hub CSPMで、どのコントロールがどのリソースに対して失敗しているかを特定する方法

Sun, 30 Aug 2026 21:00:00 +0900

TL;DR

Security Hub CSPM の是正を進めるときは、まず どの Control ID が失敗していて、どのリソースに対する指摘なのか を切り分けるのが重要です。
コンソールでは Control ID、Compliance.Status、Resources、AwsAccountId、Region を見ると整理しやすいです。
AWS CLI では get-findings を使い、Compliance.SecurityControlId と Resources[].Id を軸に絞ると、対象リソースの洗い出しがしやすくなります。

はじめに

前回の記事では、Security Hub Finding の中に Security Hub CSPM 由来のものがあり、それは Control ID を起点に読むと整理しやすい、という話を書きました。

ただ、実際に是正を進める段階では、そこからさらに一歩進めて

どのコントロールが
どのリソースに対して
どのアカウント / リージョンで
どう失敗しているのか

を特定しないと、実作業に入れません。

この記事では、Security Hub CSPM の Finding を読むときに、どのコントロールがどのリソースに対して失敗しているかを特定する方法 を整理します。

まず前提: Finding 1件 = コントロール評価結果の1レコードとして見る

AWS 公式では、Security Hub CSPM はコントロールごとにセキュリティチェックを実行し、その結果として Finding を生成・更新すると説明されています。

Security Hub Findingの見方: どれがSecurity Hub CSPM由来なのか

Mon, 27 Jul 2026 21:00:00 +0900

TL;DR

Security Hub Finding は 1 種類ではなく、Security Hub CSPM、GuardDuty、Inspector など複数の由来があります。
Security Hub CSPM 由来の Finding は、コントロールベースで生成され、IAM.1 や S3.8 のような Control ID を起点に追いやすいです。
まずは「この Finding はどこから来たのか」を切り分けてから、優先順位を付ける方が整理しやすいです。

はじめに

Security Hub を見始めたときに、最初に少し混乱したのが

これは Security Hub の指摘なのか
それとも Security Hub CSPM の指摘なのか
GuardDuty や Inspector のものも混ざっているのか

という点でした。

実務でも、Finding が 1 画面にまとまって見えると便利な反面、どこ由来の情報なのかを意識しないと、是正の進め方を誤りやすい と感じます。

この記事では、

Security Hub Finding と Security Hub CSPM の関係
どれが Security Hub CSPM 由来なのか
どんな順番で見ればよいか

を整理します。

AWSリソースのコスト計算: 是正前後でどこを見るか

Sat, 20 Jun 2026 21:00:00 +0900

TL;DR

AWS の是正対応では、「直せるか」だけでなく「直した結果いくら増えるか」を事前に見積もる必要があります。
コスト計算は、サービス名ごとではなく 時間課金 / 容量課金 / リクエスト課金 / データ処理課金 に分解すると整理しやすいです。
2026-08-11 時点で、東京リージョンの最終見積もりは AWS Pricing Calculator と各料金ページで確認するのが前提ですが、KMS・Config・CloudTrail・NAT Gateway・Network Firewall のように“是正で増えやすい”箇所は先に押さえておくと差分を説明しやすいです。

はじめに

既存 AWS 環境の是正対応では、設定変更そのものより、

変更前後でいくら増減するか
継続課金か、一時的な課金か
新たに作るリソースに待機コストがあるか

を先に整理することが多いです。

特にセキュリティ是正では、

KMS を使う
AWS Config の記録やルール評価を増やす
CloudTrail の配信先や出力先を増やす
GuardDuty や Security Hub CSPM を有効化する
NAT Gateway や Network Firewall を追加する

といった変更が入りやすく、意外とコストの説明が必要になります。

この記事では、東京リージョン (ap-northeast-1) を前提に、是正前後のコスト計算でどこを見るべきか を整理します。

まず考え方: コストは4つに分ける

個別サービスの料金を丸暗記するより、まず課金軸を分けた方が分かりやすいです。

Security Hub CSPM入門: 公式リファレンスを用いた是正の進め方

Sun, 17 May 2026 21:00:00 +0900

TL;DR

Security Hub CSPM は、AWS 環境の設定不備を継続的にチェックして Findings として出してくれる CSPM サービスです。
是正を進めるときは、まず Control ID を起点に AWS 公式リファレンスを確認し、対象リソース、Severity、関連 AWS Config ルール、Remediation を読む流れが安定します。
Security Hub はより広い統合セキュリティ基盤で、Security Hub CSPM はその中でも「クラウド設定不備の検知」に寄った位置づけと理解すると整理しやすいです。

はじめに

既存 AWS 環境のセキュリティ是正を進める中で、かなり重要な入口になったのが Security Hub CSPM でした。

実際の作業では、

まず Security Hub CSPM の Findings を見る
そのまま感覚で直すのではなく、公式リファレンスを確認する
対象リソースと是正方針を整理してから対応する

という流れを取ることが多かったです。

この記事では、

Security Hub と Security Hub CSPM の違い
Security Hub CSPM を使った是正の進め方
公式リファレンスをどう読むか

を、実務寄りに整理します。

対象リソース洗い出しに向けたAWS CLIコマンドのテンプレート

Sun, 05 Apr 2026 21:00:00 +0900

TL;DR

既存 AWS 環境のセキュリティ是正では、まず「どのリソースが対象か」を早く洗い出すことが重要でした。
客先環境でブラウザ上のコピペがしづらいなら、AWS CLI で一覧化して --query / --output table を使う運用がかなり相性良いです。
この記事では、IAM / KMS / S3 / EC2 / EBS / CloudTrail / Security Hub / GuardDuty などの確認に使えるテンプレートをまとめます。

はじめに

2026年4月から、既存 AWS 環境のセキュリティ是正対応を進める案件に入っています。

この種の作業では、いきなり設定変更に入るより先に、

何が存在しているか
どこが対象か
どこまでが是正対象で、どこからが対象外か

を先に整理しないと作業全体が進みません。

今回、CLI コマンドを重点的にまとめようと思った理由は、客先の AWS 環境が仮想ブラウザ経由で、ポリシーや設定値を気軽にコピペしづらかったためです。

そのため、

まず AWS CLI で一覧化
--query で必要な項目に絞る
--output table や json で確認する

という流れに寄せた方が、現場で使いやすいと感じました。

この記事では、対象リソース洗い出しに使いやすい AWS CLI コマンドのテンプレート を用途別にまとめます。

AWSセキュリティ是正案件で、参画後にまず把握したかったこと

Tue, 24 Mar 2026 21:00:00 +0900

TL;DR

セキュリティ是正案件に途中参画したときは、最初から全体像が見えているとは限りません。
私がまず把握したかったのは、対象範囲、何をもって是正完了とするか、どのサービスが対象か、誰と何を合意すべきか の4点でした。
いきなり修正に入るより、最初に “判断材料” を集める方が後工程が安定します。

はじめに

2026年4月から、既存 AWS 環境のセキュリティ是正対応を進める案件に参画しました。

ただ、参画前の段階で案件の詳細がすべて分かっていたわけではありません。
そのため、最初から

どのサービスがどれだけ使われているか
何が本当に是正対象か
何を直せば完了なのか

が明確だったわけではありませんでした。

むしろ実態としては、参画後に情報を集めながら、何を先に把握すべきかを整理していった という感覚に近いです。

この記事では、既存 AWS 環境のセキュリティ是正案件に入ったときに、私が最初に把握したかったことを整理します。

最初に感じたこと: いきなり是正はできない

セキュリティ是正案件という言葉だけを見ると、

Security Hub の指摘を潰す
設定不備を直す
ガバナンスを整える

といったイメージを持ちやすいです。

ただ実際には、参画直後の段階では

何が対象か
どこまで直すのか
何を優先するのか

が整理されていないことも多いと思います。

その状態で動くと、

対象外まで調べてしまう
業務要件上必要な設定まで潰してしまう
顧客との認識がズレる

といったことが起こりやすいです。

そのため、私にとって重要だったのは、最初に修正案を考えることではなく、判断材料を揃えること でした。

1. まず把握したかったのは「対象範囲」

最初に把握したかったのは、当然ですが対象範囲です。

ただ、この「対象範囲」は単にアカウント一覧やサービス一覧を指すだけではありません。

見たかったのは、たとえば以下です。

対象アカウントはどこか
対象リージョンはどこか
本番だけか、検証環境も含むのか
共通基盤も対象か
監査対象と是正対象は同じか

ここが曖昧だと、後から

そのリソースは今回対象外
その環境は今回見なくてよい
本番だけ先に進めたい

という話が出て、手戻りしやすくなります。

AWSのセキュリティについて入門してみた

Wed, 18 Feb 2026 21:00:00 +0900

TL;DR

AWS セキュリティに入門するなら、いきなり GuardDuty や Security Hub から入るより、まずは IAM / ネットワーク / 暗号化 / ログの4本柱を押さえた方が理解しやすいです。
学習順としては、IAM → VPC / Security Group → KMS → CloudTrail / CloudWatch → Security Hub / GuardDuty の順が入りやすいと感じました。
既存環境の是正対応では、「設定値を直す力」だけでなく、「なぜそれを直すのか」「本当に直すべきなのか」を説明する力も重要でした。

はじめに

2026年4月から、大手損保向けの AWS 上に構築されたデータ蓄積・分析システムの運用保守案件にアサインされています。
この案件では、経営統合に向けて既存 AWS 環境のセキュリティ是正を進める必要があり、私はその是正対応を 1 人で担当しています。
対象サービスはかなり広く、たとえば以下のような AWS サービスが含まれています。

GuardDuty
KMS
EKS
DynamoDB
Athena
SQS
EMR
S3
Glue
SNS
Lake Formation
Network Firewall
CloudTrail
EC2
EBS
ECR
ELB
IAM
Lambda
CloudWatch
VPC
Security Hub

正直、最初から全部を深く理解していたわけではありません。
むしろ、既存環境のセキュリティ是正を進める中で、何から理解すればよいかを後追いで整理していった という方が実態に近いです。

Neovim操作方法チートシート

Mon, 19 Jan 2026 21:00:00 +0900

はじめに

この記事は、VSCode から Neovim へ寄せるときに迷いやすい「操作の置き換え」をまとめたチートシートです。
マウス前提の操作をキーボード中心にどう置き換えるかを主眼に、必要に応じてマウス操作も併記します。

前提（本記事の設定）

Leader キー: <Space>（スペース）
エクスプローラ: neo-tree.nvim（<C-b> トグル、<leader>e フォーカス、<leader>er カレントへ移動）
検索: telescope.nvim（<C-p>、<leader>ff/fg/fb など）
ターミナル: toggleterm.nvim（<leader>tt/tv/tf）
補完/LSP/診断: nvim-cmp + lspconfig（gd/gr/K/<leader>rn/<leader>ca、[d/]d/<leader>e）
マルチカーソル: vim-visual-multi（Ctrl-n）
Git: lazygit（<leader>gg）、neogit.nvim（:Neogit）、diffview.nvim（:DiffviewOpen）

カーソル移動（VSCode → Neovim）

よく使う順に。まずはここを覚えると体感が一気に上がります。

基本: h 左 / j 下 / k 上 / l 右
単語単位: w 次の単語先頭 / e 単語末尾 / b 前の単語先頭（大文字版 W/E/B は記号無視で広めの単語）
行頭・行末: 0 行頭 / ^ 先頭の非空白 / $ 行末
画面スクロール: Ctrl-d 半ページ下 / Ctrl-u 半ページ上 / Ctrl-f 1ページ下 / Ctrl-b 1ページ上 / zz カーソル行を中央
段落: { 前の空行ブロック / } 次の空行ブロック
行ジャンプ: gg 先頭 / G 末尾 / :42 42行へ
1行内検索: f{文字} 右へ移動 / F{文字} 左へ移動 / t{文字} 直前まで / ; 反復 / , 逆反復
検索移動: /パターン → n 次 / N 前
戻る/進む（ジャンプリスト）: Ctrl-o 戻る / Ctrl-i 進む

マウスの補助（必要なら）

一時的にマウス有効: :set mouse=a（恒久化なら設定で vim.opt.mouse = "a"）
端末（WezTerm）で“端末ネイティブ選択”をしたい場合は Shift を押しながらドラッグ

選択と編集（VSCode のドラッグ選択 → Neovim での置き換え）

ビジュアルモード（選択開始）: v 文字 / V 行 / Ctrl-v 矩形（端末により Ctrl-q）
選択端の切替: o（選択中に押すと反対側へ） / 直前の選択を再選択: gv
テキストオブジェクト（論理単位で選ぶ）
- 単語: viw（内側の単語）/ vaw（単語＋周辺空白）
- 括弧/引用: vi", va", vi), va) ほか多数
- 段落: vip（内側）/ vap（空行含む）
検索語を順に選ぶ: gn（現在の検索語の次を選択）/ gN（前）
変換系のよく使うもの: ciw（単語を変更）, dw（単語削除）, xp（文字入替）, gU/gu（大文字/小文字）, >/<（インデント）
コピー/貼り付け: y（ヤンク）/ p（貼り付け）/ "+y（システムへ）/ "+p（システムから）

マルチカーソル（vim-visual-multi）

カーソル下の一致を選択・次追加: Ctrl-n（反復で複数） / 終了: Esc
矩形に複数カーソル: Ctrl-v → 縦に選んで I（先頭に挿入）/A（末尾に追記）

ファイル/フォルダ操作（エクスプローラ: neo-tree）

開く/移動

トグル: <C-b> / フォーカス: <leader>e / カレントへ: <leader>er
フォルダ展開/閉: Enter / Backspace

作成

a → 入力欄に名前を打って確定
ディレクトリ作成は末尾に / を付ける（例: docs/）。中間ディレクトリも作成可（例: docs/guides/）。

コピー/移動/リネーム/削除

コピー: c → 貼り付け先で p
カット（移動）: x → 貼り付け先で p
リネーム: r
削除: d
パスをコピー: y

プラグインを使わない作成も可

新規ファイル: :edit パス → :w
ディレクトリ: :!mkdir -p パス

検索とジャンプ（telescope + 標準）

ファイル: <C-p> または <leader>ff
全文grep: <leader>fg
バッファ: <leader>fb / コマンドパレット: <leader>sp
直前/次のファイルへはバッファ操作: :ls → :b 番号 / :bnext / :bprevious

画面分割・ウィンドウ操作（VSCode の複数エディタ）

分割: :vsplit（縦）/ :split（横）
移動: Ctrl-w を押してから h/j/k/l
サイズ調整: Ctrl-w >/<（幅）/ +/-（高さ）/ =（均等）
閉じる: :q（ウィンドウ）/ :bd（バッファ）

タブ（VSCode のタブ）

新規タブ: :tabnew / 次/前: gt / gT / タブ一覧: :tabs

ターミナル（ToggleTerm）と「横2分割」

基本

下パネル: <leader>tt
右パネル（縦分割）: <leader>tv
フロート: <leader>tf
Lazygit: <leader>gg
ターミナル内からノーマルへ: Esc または jk

横2分割で並べる（縦に2つ）

方法1（ToggleTerm だけで）
1. <leader>tv で縦ターミナルを開く
2. もう一度 <leader>tv（必要に応じて :ToggleTerm 2 direction=vertical のように番号指定）
方法2（標準の分割 + 端末）
1. :vsplit で画面を縦に分割
2. 片方で :terminal（もしくは <leader>tv）、もう片方でも :terminal

Neovim MCP サーバーの役割りやインストール手順

Sat, 17 Jan 2026 21:00:00 +0900

はじめに

この記事では、Neovim から Codex TUI（MCP クライアント）経由で使う「MCP サーバー」の導入手順をまとめます。
名称、入手先、必要トークン/キーの取得方法、servers.json と .env の具体例、検証方法までを一通り記載します。

導入した MCP サーバー（一覧）

context7（ドキュメント検索）

https://github.com/context7

playwright（ブラウザ自動操作）

https://github.com/microsoft/playwright

filesystem（ローカルファイル操作）

ルート制限付きでローカルを参照します。

https://github.com/github

必要: GITHUB_TOKEN

terraform（HashiCorp 公式 MCP Server）

https://github.com/hashicorp/terraform-mcp-server

イメージ: hashicorp/terraform-mcp-server:0.3.0
必要: TERRAFORM_CLOUD_TOKEN（Terraform Cloud のユーザ API トークン）

備考: 以降の手順では ~/.config/mcphub/servers.json と ~/.config/mcphub/.env を前提にします。Neovim 側は <leader>as で servers.json を開き、<leader>ar で .env を再読込できます。

トークン / API キーの取得手順

GitHub 用 `GITHUB_TOKEN`（個人アクセストークン）

GitHub にサインイン → 右上アイコン → Settings。
左メニュー最下部の Developer settings → Personal access tokens。
Fine-grained（推奨）または Classic を発行。最小権限で可。
- 参照のみで足りる場合は、対象リポジトリの「Contents: Read」など最小に絞る。
生成したトークンを控え、~/.config/mcphub/.env に保存（例は後述）。

Terraform Cloud 用 `TERRAFORM_CLOUD_TOKEN`

Terraform Cloud にサインイン（https://app.terraform.io）。
User Settings → Tokens → Create an API token。
生成されたトークンを控え、~/.config/mcphub/.env に保存。
- 互換のため TF_TOKEN_app_terraform_io へも同値を設定するとツール連携が楽です（例は後述）。

セキュリティ注意: トークンは Git 管理しないパス（~/.config/mcphub/.env）に置き、権限は最小に。公開リポジトリへコミットしないこと。

Neovimプラグインまとめ

Thu, 15 Jan 2026 21:00:00 +0900

はじめに

この記事では、現在の Neovim 構成で導入している主要プラグインを「用途別」に整理し、あわせて最小の操作方法（キーやコマンド）をまとめます。
各プラグインの GitHub リンクも併記します。

前提・環境

Plugin manager: lazy.nvim（ロックファイル運用）
Terminal: WezTerm（フォント MesloLGS NF、背景は不透明運用）
Leader キー: <Space>

お断り

この記事では、プラグインの機能の詳細説明などには触れません。
あくまで「導入しているプラグインの一覧と、主要な操作方法のまとめ」を目的としています。

Git / Diff（変更確認と操作）

lazygit（TUI クライアント）

brew install lazygit

gitsigns.nvim（行単位差分）

https://github.com/lewis6991/gitsigns.nvim

変更行のサイン表示、ステージやリセットなど。

neogit（Magit ライク UI）

https://github.com/NeogitOrg/neogit

:Neogit で起動。コミット/branch/merge を対話的に。

diffview.nvim（差分/履歴）

https://github.com/sindrets/diffview.nvim

代表コマンド: :DiffviewOpen / :DiffviewClose。

vim-fugitive（低レベル Git）

https://github.com/tpope/vim-fugitive

:G blame などのコマンドが使える。

補足（lazygit の格納先と日本語化）

Lazygit 自体は TUI（プラグインではなく外部ツール）。macOS 既定の設定パスは ~/Library/Application Support/lazygit。
運用しやすいように ~/.config/lazygit に設定を置き、App Support 側はシンボリックリンクで統一。
- コマンド例:

 mkdir -p ~/.config/lazygit
 ln -snf ~/.config/lazygit "~/Library/Application Support/lazygit"

日本語化は ~/.config/lazygit/config.yml に次を追記:

gui:
 language: "ja"

Neovim からの起動: <leader>gg（toggleterm 経由のフロート表示）。

Markdown（書く・整える・プレビュー）

vim-table-mode（表整形）

https://github.com/dhruvasagar/vim-table-mode

ECS×EFS: 片方向SGでコンテナが起動しない事象の再現と解消

Sun, 11 Jan 2026 16:00:00 +0900

TL;DR

EFS は各 AZ に「マウントターゲット（ENI ）」を持つ。
- 例: ap-northeast-1a/1c にそれぞれ固定プライベート IP を持つ ENI が存在。
ECS タスクは、配置された AZ に近い EFS マウントターゲットへ NFS で接続する。
- つまり、1a に居れば 1a の ENI、1c に居れば 1c の ENI へ向かうのが基本動作。
今回の原因は「コンテナ側 SG のアウトバウンドが片側の IP/CIDR のみ許可」だったこと。別 AZ の ENI への 2049/TCP がブロックされ、マウント失敗。
- デプロイ時に「許可されていない側の AZ/IP」への経路になり、NFS 接続不可 → タスク起動失敗。
対策は「SG のアウトバウンドに“抜けていた側のサブネット CIDR”を追加」し、両 AZ のマウントターゲット到達を許可。

概要

参画先で、ECS にデプロイしたコンテナが「EFS に接続できない」エラーで起動に失敗しました。
この記事では、

2026年の目標

Wed, 07 Jan 2026 21:00:00 +0900

はじめに

昨年末、身内に不幸がありましたので、新年のご挨拶は控えさせていただきます。
年始は厳しい寒さもあり、ゆっくり過ごしていました。

ありきたりですが、新年の目標を書いていきたいと思います。

2026 年の目標

今年の目標を、表にまとめました。

No.	目標	目標に関する説明
1	早起きする	学習時間を捻出するため、朝型に切り替える。
2	テックノート更新継続	これまでのキャリアで学んできたことや習得したいことをアウトプットし続けていく。
3	資格取得	3 月までに AWS SAA、あとは順次 AWS SOA と AWS DVA を取得する。
4	監視ツールのインプット	Datadog や New Relic など、市場で採用されている監視ツールのインプットを進めていきたい。
5	コードでのアウトプット	ブログ偏重を見直し、隔月 1 回はコードでのアウトプットを実施する。
6	転職する	2025 年は惨敗だったので、内定取れるよう自己研鑽を継続していく。

1. 早起き

これまでは、仕事から帰宅後に風呂や食事が終わった後に就寝するギリギリまで勉強をしていました。
しかし、日中に仕事をこなして帰宅するまでに体力を消耗した状態での勉強は、かなりの労力を必要としました。

2025 年の反省を活かして、今年からは早起きして学習時間を確保することにしました。

2026 年 1 月 5 日（月）の仕事始め以降、4:30〜5:00 に学習を開始しています。
まだ 3 日しか経過していませんが、このペースで継続していきたいと思います。

設定：平日 4:30 起床／5:00〜6:30 学習、土日は 6:00 起床で 1 時間。
測定：Streak とカレンダーで皆勤を可視化（週 5 日以上 ○）。
代替案：寝不足時は 30 分だけに短縮し、翌日に調整する。

https://www.youtube.com/watch?v=cKdJNgFrmM0

WezTerm 設定と VSCodeライクな Neovim 導入メモ

Mon, 29 Dec 2025 00:00:00 +0900

TL;DR

WezTerm へ移行。軽快でカスタムしやすい。
Cmd+Shift+F は「メニューを残した最大化」、Ctrl+Shift+F はネイティブ全画面。
Neovim を VSCode 風に整備（Dashboard/Dropbar/Context/Toggleterm/Copilot/Lazygit）。
インフラ用途（Terraform/YAML/Docker）重視。保存時フォーマットと LSP/診断まで最小構成。
「VSCode ならどう押す？」の対応表を掲載。

今回の設定リポジトリ

Neovim: https://github.com/wan0ri/neovim
WezTerm: https://github.com/wan0ri/wezterm

Neovim を使ってみたいと思った理由

元々Vimを使うことに抵抗感が合ったのですが、以下の理由で使ってみたくなりました。

もともとターミナルが iTerm2 だったが、セッションが増えると動作が重く感じることがあった。
GPU 描画で軽いという評判の WezTerm を試したかった。
- 公式: Wezterm: https://wezfurlong.org/wezterm
- 公式: GitHub: https://github.com/wez/wezterm
ターミナルと VSCode を行き来するコンテキストスイッチを減らしたい。
- CLI から “そのまま編集→コミット” まで完結させたい。
参考: WezTerm のカスタマイズ記事（配色・UI の考え方）
- https://zenn.dev/mozumasu/articles/mozumasu-wezterm-customization

備考: 端末エミュレータの性能はフォント・レンダリング設定・プラグイン状況で大きく変わるため、厳密なベンチは環境依存です。本記事では体感差と設定の工夫に主眼を置いています。

私自身がインフラクラウド領域の人間なので、VimであったりCLIだったりは、この先この領域を主戦場とするためには避けて通れないものであると思います。
ですので、今回はそれらのツールを使ってみて、あわよくば使いこなせたらいいかなと思い触れてみることにしました。

WezTerm の設定

今回のポイントは「VSCode/iTerm2 の癖を残しつつ、端末として軽快に」するために設定しました。
主要な調整点は次の通りです。

フォント/フォールバック
- MesloLGS NF → Monaco → "Courier New" → Menlo、CJK/絵文字に Hiragino Sans / Apple Color Emoji を追加
- フォントサイズ: 14pt、IME 有効化: use_ime = true
透明度/背景
- window_background_opacity = 0.65、macos_window_background_blur = 10
タブ/見た目
- タイトルバー簡素化（window_decorations = "RESIZE"）
- アクティブタブをシアン #00BCD4 に統一（format-tab-title で色付け）
- カーソル色もシアン（cursor_bg/cursor_border/compose_cursor = "#00BCD4"）
改行とウィンドウ最大化
- Option+Enter は「送信せず改行」: SendString("\n")
- ウィンドウ最大化（メニューバーは表示のまま）: Cmd+Shift+F
  - 独自イベント toggle-maximize で window:maximize()/restore() をトグル
- ネイティブ全画面（別スペース・メニュー非表示）: Ctrl+Shift+F
そのほか
- コピー/貼り付け: Cmd+c / Cmd+v、タブ操作（Cmd+t / Cmd+w / Ctrl+Tab）、リーダーキーは Ctrl+q
- 端末の分割/操作: LEADER+d（縦）/ LEADER+r（横）/ LEADER+h/j/k/l（移動）/ LEADER+s → h/j/k/l（サイズ調整）/ LEADER+z（ズーム）

設定例（keybinds の一部）

インフラ特化テックノートを GitHub Pages + MkDocs Material で立ち上げた話

Sun, 28 Dec 2025 00:00:00 +0900

TL;DR

インフラ領域の学習・業務で得た知見を素早く引ける「自分用の決定版カンペ」を作りました。
公開先: https://wan0ri.github.io/note （ソースは GitHub、デプロイは GitHub Pages）

採用の背景

当初は Google Cloud 上で Wiki.js をコンテナ化して運用する構成を検討しておりました。
理由としては、Terraform にもっと触れてスキルを上げたかったこと、また触れたことのない Google Cloud を扱ってみたかったことが大きな理由です。

しかし、個人用途では次が重くなりがちであることで開発自体に負担がかかっていました。

毎月のクラウドコスト（常時稼働ストレージ、監視などの積み上げ）
セキュリティ/パッチ適用、バックアップ、アップグレードなどの保守運用
アプリケーションのライフサイクルに自分が束縛される

一方で GitHub Pages + MkDocs は

0 円〜低コスト（Pages + Actions の範囲で完結）
変更は Git 管理 → PR ベースで安全に運用
書く → プレビュー → 公開までが速い（Docs-as-Code）

で構成できます。

結論として、 コスト/保守性/スピードのバランス から GitHub Pages + MkDocs Material を採用することにしました。

サイト構成（インフラ特化＋将来の言語枠）

インフラ特化のセクションを主軸に設計しました。

2025年を振り返る

Wed, 24 Dec 2025 23:00:00 +0900

はじめに

本日仕事納めでした。
本当は常駐先は 29 日（月）まで仕事なのですが、明日 25 日は通院するため、そして 1 日飛ばして金曜日に出社は流石にしんどいので、連休を取ることにしました。

はい、余談が過ぎたので、表題通り 2025 年の振り返りをしていきたいと思います。

読んでいて気落ちする内容や、表現が直球すぎて不快に感じる部分もあると思いますが、自分の正直な気持ちを綴って今年の活動を締めくくりたいと思います。

転職活動

今年を振り返るうえで、一番大きなトピックは転職活動だったと思います。
以前書いた全敗記録の振り返りは以下になります。

https://wan0ri.com/posts/2025/11/15/job-hunting-completely-halted/

過去に書いた転職活動の記事には書いていなかったのですが、

そもそもなぜ転職をしようと思ったのか

というきっかけを書いていきたいと思います。

SES から自社開発企業への転職を考えた理由

SES という働き方そのものを否定するつもりはありません。
実際、これまでインフラエンジニアとして経験を積めたのは、SES という環境で複数の現場に関わることができたからだと感じています。

一方で、この働き方を続ける中で、「このままで良いのだろうか」という違和感が、徐々に大きくなっていきました。

特に大きかったのは、自分の意思とは関係のない契約都合に、キャリアや働き方が左右され続ける点です。

気に入った現場や、信頼できるメンバー、腰を据えて改善していきたいシステムに出会えても、「契約満了」という理由だけで離任せざるを得ないことが何度もありました。
成果や意欲とは無関係に環境が変わることに、強いストレスを感じていました。

また、自分の仕事が誰のために、どのように役立っているのかを実感しづらい点も理由の一つです。

インフラとしてシステムは動いており、障害対応や改善も行っています。
しかし、見えているのは常駐先の SIer までで、その先にいるエンドユーザーの存在を感じる機会はほとんどありませんでした。

自分の仕事が社会にどう貢献しているのかを実感できないまま、タスクだけが消化されていく日々に、正直なところ虚しさを感じていました。

作ったものが実際に使われ、改善され、その結果として次の価値につながっていく。
そうした一連の流れを、自分の目で確認できる環境で働きたいと考えるようになりました。

SES が悪いから転職したい、という単純な理由ではありません。
自分がこの先エンジニアとしてどこに責任を持ち、何に価値を感じて働きたいのかを考えた結果、自社サービスを持つ企業で働くという選択肢に行き着きました。

自己研鑽の推進

インフラエンジニアとして今後のキャリアを考えたとき、オンプレミス中心の経験よりも、AWS をはじめとしたパブリッククラウドを軸にしたキャリアを歩んでいきたいと考えるようになりました。

その考えから、2024 年以降は AWS の構築・保守案件を中心に参画してきました。
なお、IT 業界へキャリアチェンジした当初は運用保守案件が中心でしたが、その中でも AWS の監視・運用業務に携わった経験があります。

実際に転職活動を始める前に、各企業の技術スタックを調査してみたところ、構築には Terraform、監視には Datadog や New Relic、AWS の基盤としては ECS/EKS ＋ Fargate といったサーバーレス構成を採用している企業が多数を占めていることが分かりました。

『SREの知識地図』の著者を招いてお送りするSREの旅〜 Road3 システムの状態を観測するを視聴して【イベント感想】

Wed, 24 Dec 2025 21:00:00 +0900

TL;DR

観測の目的は「ユーザー体験の保護」と「変更速度の維持」の両立。
会話の中心は SLI /SLO と Error Budget 。症状ベース監視へ寄せる。
メトリクス/ログ/トレースの役割分担と、cardinality 管理・サンプリング・PII 対策。
アラートは SLO 由来＋ Runbook 紐付け。ノイズは抑制/集約/遅延で削減。
ダッシュボードは監視盤と探索盤を分離し、リリースと観測を結合（Release Health) 。

参加イベント

2025 年 12 月 22 日（月）に開催された連続講義『SRE の知識地図』の著者を招いてお送りする SRE の旅〜 Road3 システムの状態を観測するを視聴しました。
視聴メモと、実務に転用できそうなポイントを残します。

【AWS社協力】ECS最新アップデートと導入事例セッション〜私たちはこう使っている〜参加メモ【イベント感想】

Sun, 21 Dec 2025 00:00:00 +0900

TL;DR

2025 年 12 月 18 日（木）開催「【AWS 社協力】ECS 最新アップデートと導入事例セッション〜私たちはこう使っている〜」に参加。
個人的ハイライト：
- Service Connect の段階導入（名前解決/通信分離/ロールバック設計）。
- Capacity Providers での Fargate/EC2 混在運用とコスト・可用性のバランス取り。
- CodeDeploy Blue/Green + 観測性（CloudWatch/OTel）で“安全に速く”を両立。
本記事は私的メモ。参加者限定資料は非公開につき、引用・画像・添付は一切なし。

参加イベント

以下の connpass ページのイベントに参加しました。

https://asiaquest.connpass.com/event/376288/

主催：アジアクエスト（AWS 社協力）
開催日時：2025 年 12 月 18 日（木）

免責と公開ポリシー

本記事は当日の視聴と自分の理解に基づく要点メモです。
参加者限定で配布された資料は公開されていないため、スクリーンショットやスライド抜粋、配布ファイルのアップロード等は一切行いません。
議事の正確性は主催・登壇者の公式発表を優先します。

当日のトピック（公開情報に影響しない範囲の要約）

ECS の最近のアップデート動向と活用パターン
事例に基づく運用・移行・コスト最適化の勘所
デプロイ戦略（ローリング/Blue-Green）と観測性の標準化

視聴メモ（非機密・一般化した学び）

1) 設計と運用の接点（ECS 文脈）

まず“テンプレと観測性”を標準化：タスク定義の logConfiguration、リソース制限、タグ、暗号化、ALB/SG 命名などを共通化。
レビューはテンプレ差分で行う：taskdef/servicedef とデプロイ設定（最小/最大ヘルシー、失敗時ロールバック）を PR で確認。
小さく検証：単一サービスで Service Connect を試し、名前解決/通信分離/段階導入のクセを掴む。

2) 自動化まわり（CI/CD と IaC）

IaC に観測性を同梱：Container Insights/OTel Collector/ダッシュボードを最初から一式で配布。
Blue/Green の標準化：CodeDeploy（またはデプロイメント回りの既定）を IaC で強制し、ヘルスチェックと自動ロールバックを有効化。
変更頻度で境界を切る：サービス定義とネットワーク/ALB/共有リソースは分離し、影響半径を限定。

3) 品質・セキュリティのガードレール

タスク実行ロール/タスクロールの最小権限化、シークレットは Secrets Manager/SSM を参照で注入。
ECR スキャン/署名、イメージタグ戦略（イミュータブル）を徹底し、展開ミスを抑止。
Drift 検知（GUI 変更の監査）と差分の PR 化で“単一の真実”を IaC に戻す。

4) GUI と IaC のすり合わせ

コンソール検証 →IaC への取り戻しを前提設計。監査ログで変更検知 → 差分抽出 →PR 作成の自動化を検討。
命名/タグ/環境変数/ポート命名などの“人が触る部分”を標準化して、すれ違いを最小化。

後に試してみたいこと（自分向け）

（コピペ可）

[ ] Service Connect をステージングの 1 サービスで段階導入（名前解決/通信分離/ロールバック検証）

[ ] Capacity Providers の標準方針を策定（Fargate/Fargate Spot/EC2 の使い分け指針 + コスト試算）

[ ] Blue/Green を IaC で強制（失敗時自動ロールバック/ヘルスチェック既定/監視連携）

[ ] GUI 変更 → IaC 反映のミニ PoC（監査イベント検知 → 差分抽出 → GitHub PR 作成）

[ ] 観測性の既定（FireLens/OTel/ダッシュボード）をテンプレ化し、全サービスへ段階適用

まとめ（現時点の所感）

“人と運用を含めた設計”と“コードへ戻す運用”が鍵。スライドのテクニックに寄り過ぎず、現場の運用フローから逆算して IaC を位置付ける。
まずは小さな自動化と検査を導入し、テンプレート差分をレビュー対象に。GUI の便利さは活かしつつ、最終的な資産はコードで一元管理する。
参加者限定資料は非公開のため、本記事では引用・添付なし。必要に応じて公開情報に合わせてタイトル/日時などのみ後日更新する。

参加したイベントをただ聞いているだけでは意味が無い【学びを業務に導入した話】

Wed, 17 Dec 2025 00:00:00 +0900

TL;DR

これまで参加したイベントのまとめ。
学びから、「ただ聞いているだけでは何の意味もない」と思い、実際に業務にて実践した話。
客先常駐という制約もあり導入出来ないものも多々あったが、その中でも導入を推進したものを記録として残す。

はじめに

今まで個人学習を継続的に推進していきましたが、レベルの高いエンジニアの方や企業がどの様に業務を推進しているのかを知りたくなりました。
そこで、2025 年 11 月から本格的に connpass で開催しているイベントに参加することにしました。

当ブログのイベントをまとめたものは以下になります。

https://wan0ri.com/category/#event

イベントに参加するごとにブログへまとめを進めてきましたが、 ただブログに書いているだけでは何の意味も無い と感じたため、実際に常駐先にどのような形で導入したのかをまとめていきたいと思います。

推進したものリスト

以下、これまで書いてきた記事から、実際に導入・推進してきたものになります。
客先のエンドユーザー様の意向や常駐先での導入が諸々の理由で実現不可能となったものもあり、実現不可能になったものは導入できませんでした。

どろんこ AI 話〜綺麗じゃない AI の苦労話〜を視聴して【イベント感想】

https://wan0ri.com/posts/2025/11/27/forkwell-doronko-ai-impressions/

2025 年 12 月時点での常駐先には Microsoft Copilot（以降、Copilot）が用意されておりました。
作業時にエラーや不明点がでてきた際に各々で Copilot を利用して問題解決していくのですが、各自での Copilot の使い方が統一されていないこともあり 出力された回答にばらつきが生じてしまいました。
そこで、以下の利用方法に絞って Copilot に対するテンプレートを作成することで問題解決に対する回答精度を向上させることを導入することにしました。

1. AWS 関連エラー/警告の解説・原因分析・解消法テンプレ

以下は AWS に関する問題です。 
再現環境・ログ・条件を整理して説明して、「原因の可能性」「すぐ試せる切り分け手順」「根本原因対応」を返してください。 
出力は Markdown 形式で構成してください。

---

### 1. 問題の概要

- サービス/リソース: <例: ECS Fargate サービス>
- リージョン: <例: ap-northeast-1>
- 権限/ロール: <IAM Role info>
- 発生タイミング: <Deploy/Update/Scale>

### 2. 入力した操作とレスポンス

- 実行したコマンド/操作: 
 <aws CLI or console 操作>
- 得られたエラーメッセージ:
 <Error log snippet, up to 10 lines>

### 3. 現在までに試したこと

- <例: タスク定義コンテナ再ビルド, セキュリティグループ確認など>

---

**要求される出力**

1. **推定原因（根拠付き）**
2. **試すべき切り分け手順（ステップ）**
3. **最終的な解決手順例**
4. **関連ドキュメントや CLI 例**

2. コンテナデプロイ用シェル生成テンプレ

私は以下の AWS 環境でコンテナをデプロイしたいです。 
指定した要件に応じた **bash シェルスクリプト（CLI）** を生成してください。 
生成するシェルには必ずエラー処理・ログ出力・必要な前提条件チェックを含めてください。

---

## デプロイ要件

1. 対象サービス: <ECS>
2. クラスター/サービス名: <名前>
3. イメージリポジトリ: <ECR URI>
4. タスク定義/Pod spec の要点:
 - CPU/Mem
 - ポート
 - Env vars
5. IAM Role / Policies: <Role 名>

## 必須要件

- 成功/失敗時の exit code を返す
- 実行ログを適切に CloudWatch Logs へ送る
- 既存タスクが存在する場合は確認と警告表示

---

**期待出力**

- 実行可能な `deploy.sh` コード
- 実行例（引数付き）
- 必要な前提条件チェック一覧

3. CI/CD（デプロイ時）エラー解析テンプレ

以下は CI/CD のビルド/デプロイエラーに関する情報です。 
GitHub Actions などの YAML、ログ、失敗したステップ名を提示します。 
原因の可能性と修正案を **可能な限りステップごとに整理して Markdown で返してください**。

---

### 1. 環境

- CI/CD ツール: <GitHub Actions / CodePipeline / Jenkins …>
- AWS リソース: <サービス名/リージョン>

### 2. 失敗ステップ

- ステップ名: <例: Build/Deploy>
- 関連 YAML/Workflow:
 <該当部分の 20 ～ 40 行以内の抜粋>

### 3. エラーログ

<エラーのログ（最大 15 行）>

導入したことによる効果

テンプレ化することにより、問題箇所のみを抽出できるので AI への問い合わせのハードルが下がった。
テンプレ化することにより回答精度のばらつきが減った。

freee 技術の日 2025 参加メモ【イベント感想】

https://wan0ri.com/posts/2025/12/03/freee-technology-day-2025/

Cloud Monitoringでエラーログを感知してSlack通知させる機能をTerraformで管理する

Sun, 07 Dec 2025 15:00:00 +0900

TL;DR

個人学習として、Cloud Monitoring でエラー検知時に Slack 通知する仕組みを Terraform で構築
知見のメモとして公開
AWS や Azure でも概ね同様の流れで構築可能だが未検証

Terraform での実装

まずは、以下の Terraform リソース構成を用意します。
なお、記述内容については Slack の設定に関するものだけを掲載します。

❯ tree
.
├── main.tf
├── modules
│ └── monitoring
│ ├── main.tf
│ ├── outputs.tf
│ └── variables.tf
├── outputs.tf
├── providers.tf
├── terraform.tfvars
├── variables.tf
└── versions.tf

./modules/monitoring の実装

modules 配下の実装は以下のようにしました。

./modules/monitoring/main.tf

###########################################################
# Cloud Monitoring
###########################################################

# Cloud Monitoring API 有効化
resource "google_project_service" "monitoring" {
 project = var.project_id
 service = "monitoring.googleapis.com"
}

# HTTPSアップタイム監視と通知
resource "google_monitoring_uptime_check_config" "https" {
 display_name = "Wiki HTTPS 稼働時間チェック"
 timeout = "10s"
 period = "300s"

 # HTTPチェックの設定
 http_check {
 path = "/"
 port = 443
 use_ssl = true
 validate_ssl = true
 }

 # 監視対象のリソース設定
 monitored_resource {
 type = "uptime_url"
 labels = { host = var.host }
 }

 # 依存関係の設定
 depends_on = [google_project_service.monitoring]
}

# Slack通知チャネルの作成
resource "google_monitoring_notification_channel" "slack" {
 display_name = "Slack - Wiki Alerts"
 type = "slack"
 # Slack通知チャネルの設定
 labels = {
 channel_name = var.slack_channel
 }
 # Slack通知チャネルの認証トークン
 sensitive_labels {
 auth_token = var.slack_token
 }
 # 依存関係の設定
 depends_on = [google_project_service.monitoring]
}

# アラートポリシーの作成
resource "google_monitoring_alert_policy" "uptime_down" {
 display_name = "Wiki HTTPS Uptime Down Alert"
 # どれか1つでも condition が true ならアラート発火
 combiner = "OR"
 # 通知チャネルの設定
 notification_channels = [google_monitoring_notification_channel.slack.id]

 # アラート条件の定義
 conditions {
 display_name = "Uptime Check Failed"
 # Uptimeチェックが失敗した場合にアラートを発火
 condition_threshold {
 # フィルターの設定(メトリックタイプとチェックID)
 filter = "resource.type=\"uptime_url\" AND metric.type=\"monitoring.googleapis.com/uptime_check/check_passed\" AND metric.label.\"check_id\"=\"${google_monitoring_uptime_check_config.https.uptime_check_id}\""
 # 比較演算子の設定
 comparison = "COMPARISON_LT"
 # 閾値の設定
 threshold_value = 1
 # 評価期間の設定
 duration = "300s"
 # トリガー条件の設定
 trigger {
 count = 1
 }
 # アラート発火のトリガー条件を設定
 aggregations {
 # 集計期間の設定
 alignment_period = "60s"
 # シリーズごとのアライナーの設定
 per_series_aligner = "ALIGN_NEXT_OLDER"
 }
 }
 }
 # 依存関係の設定
 depends_on = [google_monitoring_uptime_check_config.https]
}

# Scheduler 失敗アラートポリシーの作成
resource "google_monitoring_alert_policy" "scheduler_failed" {
 display_name = "Scheduler Job Failed Alert"
 combiner = "OR"
 notification_channels = [google_monitoring_notification_channel.slack.id]

 # 通知のレート制限設定
 alert_strategy {
 notification_rate_limit {
 period = "300s"
 }
 }

 # アラート条件の定義
 conditions {
 display_name = "Cloud Scheduler error logs"
 # ログベースの条件を使用して、Cloud Schedulerのエラーログを監視
 condition_matched_log {
 filter = "resource.type=\"cloud_scheduler_job\" AND resource.labels.job_id=~\"gce-(stop-nightly|start-morning)\" AND severity>=ERROR"
 }
 }
 # 依存関係の設定
 depends_on = [google_project_service.monitoring]
}

./modules/monitoring/variables.tf

##################################
# 入力変数
##################################
# Google Cloud プロジェクトID
variable "project_id" {
 description = "Google Cloud プロジェクトID"
 type = string
}

# Uptime監視対象のホスト名またはIP
variable "host" {
 description = "Uptime監視対象のホスト名またはIP"
 type = string
}

# Uptime監視対象のDNS名またはIPアドレス
variable "dns_name" {
 description = "監視対象のDNS名またはIPアドレス"
 type = string
}

# TechSnapのSlackチャンネル
variable "slack_channel" {
 description = "TechSnap Alert Management Slack channel"
 type = string
}

# TechSnapのSlackトークン
variable "slack_token" {
 description = "通知を監視するためのTechSnap Slackトークン"
 type = string
}

./modules/monitoring/outputs.tf

##################################
# 監視モジュールの出力
##################################

# Cloud プロジェクトID（参照用）
output "project_id" {
 value = var.project_id
}

# 監視対象のDNS名またはIPアドレス（参照用）
output "dns_name" {
 value = var.dns_name
}

infra ルート配下での実装

infra ルート配下での実装は以下のようにしました。
（Slack の定義に関わる箇所のみ）

AWS IaCナレッジ共有LT会参加メモ【イベント感想】

Sat, 06 Dec 2025 11:00:00 +0900

TL;DR

2025 年 12 月 5 日（金）開催の「【アジアクエスト × シスラボ】現場で活きる！AWS IaC ナレッジ共有 LT 会」を視聴。
個人的ハイライトは「③IaC Analyzer」「④Amazon Connect × GUI と IaC の両立」。現場での“人と運用を巻き込む IaC”の解像度が上がった。
①CDK は開発体験の良さと組織スケールのバランス設計が肝。② サーバレスは境界設計（責務分割）と観測性の IaC 化が要点。
直近アクション：既存 Terraform/CFN へ静的検査を組み込み、GUI 変更 →IaC 反映の小さな実験を回す。

参加イベント

2025 年 12 月 5 日（金）開催の「【アジアクエスト × シスラボ】現場で活きる！AWS IaC ナレッジ共有 LT 会」を視聴しました。
以下のページで案内されています。

https://asiaquest.connpass.com/event/376064/

免責

本記事は当時のイベント視聴に基づく私的メモであり、登壇資料の直接引用・転載は行っていません。

当日のアジェンダ

①LT1 使って感じた CDK のリアル
②LT2 AWS サーバレスにおける IaC の活用
③LT3 IaC Analyzer で始める Well-Architected なインフラづくり
④LT4 Amazon Connect で考える GUI と IaC の両立

視聴メモ

①LT1 使って感じた CDK のリアル

良かった点：型安全（TypeScript）とコンストラクト再利用で“実装 → 標準化”の循環を回しやすい。小さく始めて段階的に抽象化できる。
つまずきがちな点：
- bootstrap 周りの権限とアセット公開（S3/ECR）を正しく設計しないと多環境で詰まりがち。
- 命令的ロジックを詰め込みすぎるとテンプレートの可読性が低下（CloudFormation の diff が追いづらい）。
- チーム内でコンストラクトの抽象度が揃わないと、拡張しづらい“島”ができる。
運用のコツ：
- cdk synth の成果物（CFN）をレビュー対象に入れる。CI で cdk diff を必ず回す。
- 共有コンストラクトに既定（タグ/暗号化/ログ保持）を強制するラッパーを用意。
- 併用前提の判断基準を明文化（例：ガバナンス強い基盤は Terraform、アプリチームは CDK）。
所感：個人/小規模では “速さ” が圧倒的メリット。組織スケールでは“テンプレートの見える化”とガードレール設計が先に必要。

②LT2 AWS サーバレスにおける IaC の活用

PDF で掲載されていたサーバーレスのサービス（Lambda， DynamoDB， Step Functions）を、実務扱ったことが無かったため新鮮な気持ちで臨めることが出来た
本項では CloudFormation で半自動化する手法を紹介されていたが、Terraform でさらなる自動化を推進できるのではと感じた。
境界設計が最重要（関数の責務、Step Functions での“オーケストレーション vs コレオグラフィ”）。
観測性は最初から IaC に同梱（ログ保持期間、分散トレーシング、メトリクス/ダッシュボード）。後付けは高コストになりやすい。
権限は最小化をテンプレ化（Lambda 毎の IAM ポリシー、DynamoDB の条件付き権限、S3 バケット暗号化/ブロック Public）。
デプロイ単位は“変更頻度”基準で分割（テーブルと関数のライフサイクルを切り離す）。
ツール選定の指針：CloudFormation/SAM（ネイティブ連携）、CDK（開発速度/抽象化）、Terraform（マルチアカウント一元管理）。
所感：まずは PoC で“1 フロー + 1 DB + 監視”の最小構成を IaC 化し、運用の痛みを早めに洗い出すのが良さそう。

③LT3 IaC Analyzer で始める Well-Architected なインフラづくり

AWS Well-Architected フレームワークに関する紹介（AWS SAA でも出題される）
- 1. セキュリティ
- 1. 信頼性
- 1. パフォーマンス効率
- 1. コスト最適化
- 1. 運用上の優秀性
- 1. サステナビリティ（持続可能性）
私も存じ上げなかった IaC Analyzer の説明があった
- 対応コードは Terraform, CloudFormation, CDK
参考になりそうな資料を探してみたところ、以下がヒットした

https://github.com/aws-samples/well-architected-iac-analyzer?utm_source=chatgpt.com

freee 技術の日 2025 参加メモ【イベント感想】

Wed, 03 Dec 2025 00:00:00 +0900

TL;DR

2025 年 11 月 30 日（日）開催の「freee 技術の日 2025」を視聴（インフラ/ SRE 関連セッションのみ）。
SLO / エラーバジェット を“止める規則”ではなく 意思決定のものさし として運用する姿勢が腑に落ちた。
認知負荷を下げる仕組み（押すだけダッシュボード、最小アラート、例外運用の雛形）が継続の鍵。
設計は 「前提 → 概算 → 手筋 → 検証」 の反復。観測可能性と段階的リリースを最初から設計に入れる。

参加イベント

2025 年 11 月 30 日（日）に開催された「freee 技術の日 2025」を視聴しました。
以下のページで案内されています。

大規模システム設計の基礎を視聴して【イベント感想】

Mon, 01 Dec 2025 00:00:00 +0900

TL;DR

システム設計は「要件・制約 → 規模見積もり → ボトルネック仮説 → 対策/検証」の反復。言語化した前提を常に更新するのが肝。
規模感は“目分量”ではなく、概算（QPS / スループット / ストレージ容量 / 帯域）で会話する。数字があると優先順位とトレードオフが立つ。
スケール戦略は段階的に（垂直 → 水平 → 分割）。キャッシュ、非同期化、キュー、シャーディング、冪等性 で詰まりを逃がす。
可用性・一貫性 ・コスト・複雑性はトレードオフ。SLO を置き、過不足を検証で詰める。

参加イベント

2025 年 11 月 29 日（土）に開催された Recursion 主催の『大規模システム設計の基礎』を視聴しました。

『SREの知識地図』の著者を招いてお送りするSREの旅〜 Road2: 信頼性を定義して組織で運用するを視聴して【イベント感想】

Sat, 29 Nov 2025 14:00:00 +0900

TL;DR

SLO /エラーバジェット は“止める/止めない”の絶対規則ではなく、現実的な意思決定のためのものさし。
導入は小さく（パイロット → 可視化 → 会話）から。いきなりバーンレート 等の上級運用に飛ばない。
認知負荷を下げる仕組みづくり（押すだけのダッシュボード/アラート/手順）が継続のカギ。
四半期〜年次で見直し。サポートチケットや NPS と併置して SLO の厳しさ/緩さを調整。

参加イベント

2025 年 11 月 27 日（木）に開催された連続講義『SRE の旅』の Road2「信頼性を定義して組織で運用する」を視聴しました。
視聴メモと、実務に転用できそうなポイントを残します。

どろんこAI話〜綺麗じゃないAIの苦労話〜を視聴して【イベント感想】

Thu, 27 Nov 2025 09:00:00 +0900

TL;DR

「綺麗じゃない」実践知が山盛り。課題定義・責任境界・計測を先に決めることが成否を分けると再確認。
生成 AI は“使いどころ”の設計が命。UX 起点で仮説 → プロトタイプ → 学習ループを高速に回す文化が要。
モデル/外部 API への依存は前提。互換レイヤ・フェイルセーフ・コスト監視をプロダクション設計に埋め込む。
「学びの KPI」を置くと探索が楽になる。小さく泥臭く試し、ユーザー接点で早めに擦るのが結局近道。

参加イベント

2025 年 11 月 25 日（火）に Forkwell 社より主催された、『どろんこ AI 話〜綺麗じゃない AI の苦労話〜』を視聴しました。

https://jobs.forkwell.com/events/dsa0_8s94bl

視聴した感想や、自身に置き換えて役に立てそうだと思ったことを書いていきたいと思います。

印象に残ったこと

1. 前提を揃える

まず、登壇全体を通じて強く感じたのは、AI プロジェクトほど「前提を揃えること」が効くという点でした。
解くべき課題を丁寧に言葉にし、PoC を卒業したと見なす基準を最初に置いておく。ここには精度やコストだけでなく、説明可能性、運用に必要な手間、組織としての責任の持ち方まで含めるべきだという示唆がありました。
意思決定の単位『 誰が何をいつ承認するのか 』を明文化しておくと、試行錯誤が迷走せず、泥臭い実験を健全な速度で続けられるのだと理解しました。

2. LLM の応答はアプリケーションのいち機能として扱うべき

フロントエンドと生成 AI の接点についても多くの学びがありました。
LLM の応答は“そのまま見せるテキスト”ではなく、アプリケーションのいち機能として扱うべきです。
ストリーミング表示は待ち時間の心理的負担を軽くし、キャンセルや再実行は失敗を前提にした健全な操作感を生みます。
さらに、要約や根拠の提示を UI に組み込むことで、幻覚や遅延がユーザー体験を損なうリスクを和らげられると感じました。

3. 抗わない設計

技術選定の観点では、モデルや外部 API の進化速度に抗わない設計が重要だと再確認しました。
プロバイダ適配のレイヤを用意し、プロンプト資産はバージョンを明確に管理する。
コスト・品質・レイテンシの三点を儀式化してダッシュボードで見える化し、劣化や偏りを早期に捕捉できるようにしておく。
これらは “差し替えが常態” である時代の基本動作だと感じます。

学習の一環で個人開発していたら請求額が凄いことになってアゴが外れかけた

Sun, 23 Nov 2025 10:00:00 +0900

TL;DR

学習目的の個人アプリを Google Cloud で運用していたところ、月額が 1 万円を超えていることに気付きました。
緊急対応として DNS 以外の GCP リソースを停止・削除し、以後は Cloudflare を中心に再構築する方針に切り替えました。
代替は Cloudflare と Netlify を比較し、Next.js との相性と固定費の低さから Cloudflare を選定しました。

背景（なぜ Google Cloud で始めたか）

ポートフォリオ作成と学習を目的に、インフラから CI/CD、監視まで一通りを触ることを狙って始めた個人開発を行っていました。
採用技術は Google Cloud を中心に、Cloud Run、Artifact Registry、Cloud Scheduler、Logging/Monitoring を Terraform で管理していました。
アプリは Next.js ベースで、将来的な SSR やバッチ実行も見据えていました。
Google Cloud を採用した理由は、今まで触ったことがなかったので学習をきっかけに触ってみたかったのと、ドキュメントを読んでいて機能がシンプルで理解しやすく感じたからです。

何が起きたか（請求が 1 万円超）

ある日、何気なく請求ダッシュボードを確認したところ、当月見込みが 1 万円を超えていました。
個人開発としては継続が重い水準だと判断し、即座にコスト抑制に舵を切りました。
参考までに、JST 2025-11-19 20:35 時点のスナップショットは以下のとおりです。

2025年の転職活動が散々たる結果で終えたインフラエンジニアの棚卸し記録【完全敗北】

Sat, 15 Nov 2025 10:00:00 +0900

はじめに

2025 年、私は SES 企業で働くインフラエンジニアとして、自社開発企業への転職を目指しました。
結果として、選考に進んだ企業すべてに落ちました。

1. 活動背景と技術スタック

まず、2025 年時点での私のスタックは以下の通りです。

AWS（実務 4 年）
- VPC / EC2 / S3 / RDS / Aurora
- ECS / Lambda / Route53
- CloudWatch / IAM / KMS
- ElastiCache / Secrets Manager
インフラ・運用
- Linux / Windows Server
- VMware / Docker
- Zabbix / JP1
- Shell / Ansible / Jenkins
ネットワーク
- L2〜L3 / VLAN / QoS
- 障害対応 / 設計・運用

スタックだけを見ると、インフラ周りの運用・構築を幅広く経験しているように見えると思います。
ただし、このあと触れる「敗因」の部分に繋がりますが、深さより広さのキャリア であることが課題でした。

サイトポリシー

Sat, 15 Nov 2025 00:00:00 +0900

本サイトのコンテンツ利用方針は以下のとおりです。

引用は出典明記のうえ適切な範囲でご利用ください。
画像・図表・ソースコードの無断転載はお控えください。
掲載情報の正確性には努めていますが、内容を保証するものではありません。
予告なく内容の変更・削除を行うことがあります。

免責事項については「免責事項」をご参照ください。

プライバシーポリシー

Sat, 15 Nov 2025 00:00:00 +0900

当サイト（以下「本サイト」）では、ユーザーの個人情報および行動情報を以下の方針に基づき適切に取り扱います。

取得する情報

アクセス解析（Google Analytics 4）による匿名のトラフィックデータ
広告配信（Google AdSense）に伴う Cookie 等の識別子

利用目的

サイトの利便性向上、コンテンツ改善のための統計分析
広告の最適化と不正防止

Google Analytics 4 について

本サイトは Google 提供の GA4 を用いて匿名のトラフィックデータを収集します。
取得データは Google のプライバシーポリシーに基づいて管理されます。
詳細: https://policies.google.com/privacy

Google AdSense について

第三者配信事業者の広告を掲載し、Cookie 等によりユーザーに応じた広告を表示する場合があります。
パーソナライズ広告の無効化: https://adssettings.google.com/
事業者のポリシー: https://policies.google.com/technologies/ads

Cookie の管理

ブラウザ設定から Cookie の保存を拒否できます。拒否時は一部機能が制限される場合があります。

外部リンク

外部サイトでの個人情報の取り扱いについて、本サイトは責任を負いません。

改定

本ポリシーは予告なく改定される場合があります。改定後は本ページにて公表します。

免責事項

Sat, 15 Nov 2025 00:00:00 +0900

本サイトに掲載する情報は、執筆時点の知見に基づくものであり、完全性・正確性・最新性を保証するものではありません。内容の利用により生じたいかなる損害についても、当方は一切の責任を負いかねます。必ず公式ドキュメントや一次情報をご確認のうえ、ご自身の判断と責任にてご利用ください。

広告について

Sat, 15 Nov 2025 00:00:00 +0900

本サイトでは、運営継続のため Google AdSense 等の広告を掲載しています。広告配信事業者は、Cookie 等を使用してユーザーの興味に応じた広告を表示する場合があります。パーソナライズ広告を無効化する設定は以下を参照してください。

パーソナライズ広告: https://adssettings.google.com/
事業者のポリシー: https://policies.google.com/technologies/ads

アフィリエイトリンクを含む場合は、リンクに「sponsored」「nofollow」を付与しています。

巷で噂の CodeX CLIに触れてセッティング諸々トライしてみた

Sun, 21 Sep 2025 10:00:00 +0900

はじめに

以前書いた記事で ChatLLM の API を使ってバイブコーディングの環境を構築しました。

https://wan0ri.com/posts/2025/09/06/vscode-vibecoding/

使い始めた当初は AI に壁打ちしながらコーディングできていたのですが、以下の問題点が出てきました。

チャットを入力してレスポンスまでかなりの時間がかかった
拡張機能の Continue がかなりの頻度でエラーになってしまいチャットでの壁打ちが困難

他のサービスに切り替えることを検討するなかで Claude Code を視野に入れましたが、ここ最近精度があまりよろしくないと他のユーザーからの声が挙がっていたので、早々に候補から外しました。

Qiita や Zenn などを眺めていたところ、ChatGPT を提供している OpenAI から CodeX という AI エージェントがかなりいいという記事を多数見かけましたので、遅ればせながら試してみました。

https://developers.openai.com/codex/cloud

以降、私が設定した内容になります。
以前 Cursor を使用していて、その中で AI と壁打ちでチャットできるようルールを作ったことがあるので、そのルールを踏襲して CodeX にもルールの定義付けをしようと思います。

説明しないこと

CodeX の概要説明やインストール、導入までの手順
CodeX に対しての詳細説明※あくまで CodeX のルールなどの設定内容と実行手順にフォーカス

設定（AGENTS.md）

ユーザー配下に.codex があることを確認し、その中に AGENTS.md を作成する。
これは現在のプロジェクト内を解析する説明書のようなものになります。

AGENTS.md

# AGENTS

最終更新: 2025-10-03 00:00:00

## 基本指示

- CodeX CLI エージェントは初回応答から日本語で返答し、ユーザーが別の言語を明示した場合のみ切り替える。
- 説明は平易な日本語で、必要な識別子やコードは英語で表記する。

## 運用スタイル

- 基本は `codex` コマンド単体で起動し、用途に応じて都度 `-p <profile>` や `--prompt` を指定する。
- プロファイル切替ラッパー（`codex-infra` など）は廃止し、`codex` コマンドに集約する。
- 設定変更後は Codex CLI を再起動するか、TUI で `:config reload` を実行して反映させる。

## プロファイル一覧

### infra-tf (profile: `infra`)

- **目的** : Terraform / Kubernetes / Docker / CI レビューに特化。
- **呼び出し例** : `codex -p infra --prompt "@tf:rules"`。
- **備考** : インフラ構成レビューは「目的 → 差分 → 影響 → ロールバック → 検証」で整理する。

### docs-scribe (profile: `docs`)

- **目的** : ADR / 設計資料 / 要件定義の骨子生成。
- **呼び出し例** : `codex -p docs --prompt "@docs:adr title=\"...\""`。
- **備考** : Markdown 構造化と簡潔な要約を優先する。

### full-stack-rev (profile: `full`)

- **目的** : BE / FE / DB / CI を横断したレビュー。
- **呼び出し例** : `codex -p full --prompt "@fe:rules"`。
- **備考** : アプリとインフラの相互影響を棚卸ししてから提案する。

### quality-ops (profile: `quality`)

- **目的** : コマンド安全性・セキュリティ・テスト生成のスポットチェック。
- **呼び出し例** : `codex -p quality --prompt "@review:commands"`。
- **備考** : 機微情報と再現性、重大リスクを最優先で精査する。

## プロンプトプリセット

- プリセット本文は `config.toml` の `[prompt_presets]` に定義される。
- 追加・更新時は diff を確認しつつ `:config reload` で反映する。
- よく使うプリセットは `codex --prompt "@name"` 形式で直接呼び出す。

## MCP サーバー

- context7: Context7 ドキュメント参照。
- playwright: Playwright ブラウザ操作。
- filesystem: ローカルファイル参照。
- github: GitHub リポジトリ参照（`GITHUB_TOKEN` を環境変数で渡す）。
- terraform: HashiCorp 公式 Terraform MCP Server。`docker run --rm -i hashicorp/terraform-mcp-server:0.3.0` で起動し、Terraform Registry からプロバイダ情報を取得できる。Terraform Cloud / Enterprise を使う場合は `TERRAFORM_CLOUD_TOKEN` などを `env` で明示すること。ローカル開発環境での利用を前提とし、外部公開時はアクセス制御を追加する。

## 運用ルール

1. 日常作業は `codex` コマンドで開始し、必要に応じて `-p` でプロファイルを切り替える。
2. プロファイルの使い分けが煩雑になった場合はプリセット側で段階的に吸収する。
3. 有用だった会話はプロファイル紐付けのメモとして本ファイルに追記し、再利用できる形に整理する。

設定(config.toml)

次に config.toml の設定を行います。
これは、CodeX の設定ファイルになります。

ChatLLM APIとVSCode拡張機能Continueを組み合わせてVibe Coding環境を構築した話

Sat, 06 Sep 2025 10:00:00 +0900

概要

本記事では、ABACUS.AI が提供する ChatLLM の API を VSCode 拡張機能「Continue」に連携させ、バイブコーディング環境を整備した一連の流れをまとめます。
当初は Cursor ルール用に作成した .mdc ファイルを参照する方式を考えましたが、最終的には 全ルールを config.yaml に直書きし、API キーもローカルの config.yaml に直接埋め込む 方式に落ち着きました。

経緯

Cursor の Pro プランを利用していたが、毎月の上限を使い切ることが多かった。
既に契約していた Abacus.AI の ChatLLM API を活用できないか検討。
ChatLLM にはエディタ連携機能がないため、VSCode 拡張「Continue」 をフロントエンドに利用。
最初は .mdc にルールを分割し参照する構成を考えたが、将来的に不要になるため廃止。
また、環境変数経由で API キーを渡す方式は GUI 環境の VSCode でうまく読み込まれない ことが判明。
結果として、個人利用では config.yaml に API キーを直書き する方法が最も安定することが分かった。

対応

1. ChatLLM API キー発行

Abacus.AI 管理画面から RouteLLM API キーを発行。
GUI 経由の VSCode では ~/.zshrc などから環境変数が引き継がれなかったため、今回は config.yaml に直書き する運用とした。

2. Continue の設定ファイル

VSCode 拡張 Continue は、ユーザーごとに ~/.continue/config.yaml を参照する。
今回はここに AI モデル定義とルールを直書き。

設定例（抜粋）:

CloudWatchのメトリクスフィルターを論理演算で組み立てるまでの記録

Fri, 05 Sep 2025 10:00:00 +0900

前置き

参画案件の情報を伏せる意味合いもあり、アプリケーション名や文字列については実際のものとは違うものになります。

背景とやらかし

現在参画している「AIX から AWS への全面リプレイス案件」で、CloudWatch Logs のメトリクスフィルターを設定する作業がありました。
現行 AIX 環境では、オンラインアプリケーション ABC 系のエラー検知に以下の 2 つのルールが設定されています。

ABC[0-9]{4}E
CV[0-9]{4}E

さらに例外として CV9006E と CV9007E が出力された場合は検知から除外する必要があります。
この条件をそのまま CloudWatch に写経しようとして、フィルターは「正規表現を連結するもの」だと勘違いしたまま構築を進めたのが今回のやらかしの発端でした。

CloudWatch フィルターパターンの素朴なルール整理

CloudWatch Logs のフィルターパターンは、まず「文字列の出現有無を論理演算で組み合わせる」仕組みになっています。
スペースで区切った語句は AND、語句の前に - を置くと NOT、語句の前に ? を置くと OR（いずれかが含まれていればマッチ）という扱いになります。
これらはプレーンテキストにも JSON ログにも共通で、JSON の場合は { $.field = “value” } のようにフィールドを指定できるのが追加要素です。
正規表現はあくまで補助的に %…% で囲んだ部分として書けますが、1 パターンにつき最大 2 つまでという制限がありますし、使わなくても目的を満たせるなら論理演算だけで完結させた方が運用は楽です。

今回のケースでは「ABC または CV で始まり、4 桁の数字と E が続く」という条件をどうしても 1 つの正規表現で書きたいので %((ABC|CV)[0-9]{4}E)% までは許容するとしても、除外条件にまで正規表現を使ってしまうとクォータを超えてしまいます。
このルールを理解しないまま以下のように 4 本の正規表現を含んだパターンを書いた結果、テスト画面で

About

Mon, 01 Jan 0001 00:00:00 +0000

Profile

Name: wan0ri
Job: インフラクラウドエンジニア, SRE
Favorite: キャンプ, 野球観戦

Introduction

自動車製造業の設備配管の施工管理からIT業界へキャリアチェンジし、現在はクラウドインフラ構築・保守・運用を専門にしています。
金融・保険業界の高セキュリティ要件対応、データセンター運用、クラウドネイティブ環境まで、幅広い領域で実務経験を積んできました。

Cases I’ve experienced

AIXからAWSへの大規模移行プロジェクトや、銀行システムの新規・追加構築、保守運用、SRE業務に従事し、複雑な技術課題の調査・改善を担当。
可用性向上、運用工数削減、デプロイの安定化など、信頼性向上に直結する改善を継続してきました。

Contribution

製造業で培った「ムリ・ムダ・ムラ削減」の視点をIT運用に応用し、運用設計・標準化・自動化を推進し、現場に根付く改善を積み重ね、安定した技術基盤づくりに貢献しています。

Strengths

強みは傾聴力・協調性・実行力で、関係者と協力しながら改善を前に進めることができます。
これらを活かし、社会的意義のあるプロダクトをSREとして支えていきたいです。

Ambition

医療・福祉や教育など、社会課題が残る領域で、人々の生活を支えるプロダクトの信頼性向上に貢献したいと考えています。
私のビジョンは「誰もが前向きに人生を満喫できる社会」を実現すること。
そのためには、根幹を支える技術基盤の安定性が不可欠であり、SREとしてその役割を果たしたいと考えています。

Caution

本ブログの内容・発言は個人の見解であり、所属組織の見解ではありません。

Info

Mon, 01 Jan 0001 00:00:00 +0000

wan0ri Lab

Security Hub CSPMの是正対象を3つに分類して進める方法

TL;DR

はじめに

まず前提: 3つは排他的な分類ではない

1. 横展開できるもの

横展開できるものとは

判断するときに見る項目

Security Hub CSPMで、どのコントロールがどのリソースに対して失敗しているかを特定する方法

TL;DR

はじめに

まず前提: Finding 1件 = コントロール評価結果の1レコードとして見る

Security Hub Findingの見方: どれがSecurity Hub CSPM由来なのか

TL;DR

はじめに

AWSリソースのコスト計算: 是正前後でどこを見るか

TL;DR

はじめに

まず考え方: コストは4つに分ける

Security Hub CSPM入門: 公式リファレンスを用いた是正の進め方

TL;DR

はじめに

対象リソース洗い出しに向けたAWS CLIコマンドのテンプレート

TL;DR

はじめに

AWSセキュリティ是正案件で、参画後にまず把握したかったこと

TL;DR

はじめに

最初に感じたこと: いきなり是正はできない

1. まず把握したかったのは「対象範囲」

AWSのセキュリティについて入門してみた

TL;DR

はじめに

Neovim操作方法チートシート

はじめに

前提（本記事の設定）

カーソル移動（VSCode → Neovim）

マウスの補助（必要なら）

選択と編集（VSCode のドラッグ選択 → Neovim での置き換え）

マルチカーソル（vim-visual-multi）

ファイル/フォルダ操作（エクスプローラ: neo-tree）

開く/移動

作成

コピー/移動/リネーム/削除

プラグインを使わない作成も可

検索とジャンプ（telescope + 標準）

画面分割・ウィンドウ操作（VSCode の複数エディタ）

タブ（VSCode のタブ）

ターミナル（ToggleTerm）と「横2分割」

基本

横2分割で並べる（縦に2つ）

Neovim MCP サーバーの役割りやインストール手順

はじめに

導入した MCP サーバー（一覧）

context7（ドキュメント検索）

playwright（ブラウザ自動操作）

filesystem（ローカルファイル操作）

terraform（HashiCorp 公式 MCP Server）

トークン / API キーの取得手順

GitHub 用 GITHUB_TOKEN（個人アクセストークン）

Terraform Cloud 用 TERRAFORM_CLOUD_TOKEN

Neovimプラグインまとめ

はじめに

前提・環境

お断り

Git / Diff（変更確認と操作）

lazygit（TUI クライアント）

gitsigns.nvim（行単位差分）

neogit（Magit ライク UI）

diffview.nvim（差分/履歴）

vim-fugitive（低レベル Git）

補足（lazygit の格納先と日本語化）

Markdown（書く・整える・プレビュー）

vim-table-mode（表整形）

ECS×EFS: 片方向SGでコンテナが起動しない事象の再現と解消

TL;DR

概要

2026年の目標

はじめに

2026 年の目標

GitHub 用 `GITHUB_TOKEN`（個人アクセストークン）

Terraform Cloud 用 `TERRAFORM_CLOUD_TOKEN`

『SREの知識地図』の著者を招いてお送りするSREの旅〜 Road3 システムの状態を観測するを視聴して【イベント感想】

【AWS社協力】ECS最新アップデートと導入事例セッション〜私たちはこう使っている〜参加メモ【イベント感想】

どろんこ AI 話〜綺麗じゃない AI の苦労話〜を視聴して【イベント感想】

AWS IaCナレッジ共有LT会参加メモ【イベント感想】

大規模システム設計の基礎を視聴して【イベント感想】

『SREの知識地図』の著者を招いてお送りするSREの旅〜 Road2: 信頼性を定義して組織で運用するを視聴して【イベント感想】

どろんこAI話〜綺麗じゃないAIの苦労話〜を視聴して【イベント感想】