2026年11月2日月曜日

外部向けサービスをどう守るか

この記事は「正解」を示すものではなく、SREとして日々インフラに関わる中で感じた個人的な考えです。セキュリティを体系的に学びたい方は、専門の書籍や公式ドキュメントもあわせて参照してください。

最近、ソフトウェアの脆弱性をきっかけにしたセキュリティ事案が続いています。ニュースを見ながら「外部に公開しているサービスは、結局どう守ればいいのか」を改めて考えたので、2つの視点でまとめてみました。

2026年10月18日日曜日

前準備など

以前から「6歳になったら踊り子に乗りたい」と言っていたが、ここ最近はその話をしなくなっていた。おそらく、自分の中でブームが終わったのかな？と思っていたところだった。

ところが、なぜか最近になってまた言い始め、いきなり週末に行きたいと言い出した。

ちょうど日曜日に予定がなかったので、行ってみることにした。

踊り子は主に伊豆方面へ向かう電車だが、子どもと二人で伊豆に行く予定はないし、行ったとしても特にやることがない。

そこで発想を変えて、上り電車に乗って都会で遊んでくることにした。横浜なら何かしらやることがある。

私も踊り子に乗るのは初めてだったし、きっと子どもは運転席を見たがるだろうと思ったので、JRのえきねっとで座席を選んで予約した。

海側ではなく陸側の席だったが、ちょうど一番前の席が空いていた。しかも、隣の席も空いていたので、窓側を予約した。

当日の移動

子どもは朝からテンション高めで、早起き。何度も「お昼ごはんの頃に乗れるよ」と伝えたが、いまいち理解していない様子だった。

結局、乗車時間の2時間ほど前に小田原駅に到着。いつもの図書館と子育てサロンのコースに行った。

予想どおり、あまり時間をつぶせなかったので、結局、先に昼ごはんを食べることにした。

一応、妻におにぎりを作ってもらっていたが、それだけでは足りないと思うので、先に少し食べても問題ないはず。

いつも行っているハンバーガー屋で軽めの昼ごはんとアイスを食べたら、ちょうどいい時間になった。飲まずに持っていたコーラを持ち、駅に戻った。

列車は意外と混んでいた。予約したときには空いていた隣の席にも、おばさんが座っていて、すでに晩酌を始めていた。

仕方なく、子どもを膝の上に座らせた。

乗車時間はそれほど長くないので、移動中も子どもは喜んでいた。途中で運転席も見に行った。もちろん、抱っこで。

横浜

まずはNゲージ体験のため、ポポンデッタ横浜西口店（https://www.popondetta.com/yokohama/）へ移動した。

移転前は商業施設の中にあったのでアクセスが便利だったが、今回はだいぶ遠くなったように感じた。

それでも、子どもはテンション高めで、文句も言わずに歩いてくれた。

体験時間は20分。車両は一番安いものを選び、料金は800円だった。

鉄道クラブにあったコントローラーとは少し違っていたが、問題なく操縦できた。

最初は20分では足りないのではないかと心配していたが、意外にも15分ほどで満足したのか、自分から切り上げた。

もちろん、店内にはいろいろな電車関連の商品があるので、何か買いたいらしい。

意外とNゲージの車両もばら売りされていて、動力車は2,800円程度だった。どうやら欲しいらしい。

とはいえ、線路などもそろえる必要があるし、いきなり購入するのも大変なので、いったんママと相談することにした。

一応、何か買うつもりで来ていたので、お土産として電車の靴下を購入した。

おそらくまた来ることになりそうなので、会員証も作った。

次の場所へ移動しようとしたところ、問題発生。

トイレに行きたいらしいが、店員さんに聞いたところ、店内にはトイレがないとのこと。

来た道を戻り、コンビニでトイレを借りた。こういうことも何年ぶりだろう。

その後は、京急ミュージアムへ移動した。

本来は横浜駅まで戻って地下鉄を利用するつもりだったが、距離的に微妙だったので、歩いて行くことにした。

意外にも、子どもは文句を言わずに歩いてくれた。やっぱり楽しかったのかな。

京急ミュージアムは、週末ということもあってか、まあまあ混んでいた。

今まで何度も来ているし、シミュレーターも予約なしでは体験できないので、うちの子にとっては、もうあまりやることがないようだった。

結局、割と早めに切り上げて帰ることにした。

帰り道

帰ろうとしたところ、子どもから「相鉄線に乗って帰りたい」と意外な提案があった。

確かに相鉄線でも帰れるが、乗り換えが必要だし、東海道線よりも時間がかかる。

そのことを説明したが、それでもいいらしい。

私も相鉄線には乗ったことがなかったので、少し気になっていたところだった。

改札に入りながら時間を確認すると、ちょうど海老名行きの急行に間に合いそうだった。

電車に乗ると、子どもはさっそく運転席を探し始めた。

何とか一番端の車両まで行ったが、そこからは車掌さんの席が見えた。また反対方向へ移動し、ようやく運転席が見えたところで電車が出発した。

車内が空いていてよかった。

初めて乗る電車だし、運転席が見えるように抱っこしてあげたが、さすがに私も体力の限界だった。

幸い、座席が空いていたので、座って休みながら抱っこすることにした。

どうやら子どもも疲れてきたようで、「ママに秦野まで迎えに来てほしい」と言い出した。

最初はバスに乗って帰るつもりだったが、私も疲れていたので、妻に迎えに来てもらうことにした。

今回のお出かけで、子どもはみなとみらい線の電車が大変気に入ったらしい。

踊り子に乗ることが目的だったはずなのに、最後には別の電車がお気に入りになったようだ。

2026年10月12日月曜日

概要

10月は鉄道関連のイベントが多いので、色々と調べていたところ、昨年に続いて今年も大雄山駅で体験型イベントが開催されるらしいことが分かった。

終点まで行くことになるので、少し遠くはあるが、普段はあまり乗らない大雄山線に乗れるし、ちょっとしたお出かけにも良さそう。

子供も運転士体験ができるので、数日前から楽しみにしていた。

3連休の最終日で、連日のお出かけによる疲れも残っていたが、最後まで頑張る覚悟で出かけることにした。

当日

初めて参加するイベントだったので、どれくらい混雑するのか心配だった。

おそらく昼食後に行った方が空いている気もしたが、調べてみると大雄山駅周辺には子供と一緒に食事ができそうな場所が少なそうだった。そのため、どうしても小田原で昼食を取ってから向かうプランになる。

結局、頑張って早めに出発することにした。

小田原から大雄山線に乗り換えたところ、何人かの子供が目に入った。みんな手元にチケットのようなものを持っていて、「小田原駅で何か配っていたのかな？」と少し焦った。

ただ、事前の告知には特に案内がなかったので、とりあえずそのまま向かうことにした。

電車の運転席は子供にとってとても見やすい位置にあり、乗っている間、ずっと前方を眺めていた。

大雄山駅に着くと、降りる人の流れに乗って、そのまま洗車体験の電車に乗り込んだ。ちょうど始まる頃だったので、タイミングが良かったかもしれない。

洗車体験が終わり、次にどこへ行こうか考えていると、子供が「お土産を買いたい」と言い始めた。

これまでの経験から、並んでいるときなども、手元に好きなものがあれば飽きずに過ごしてくれるので、お土産を買うのも良いかもしれない。

お土産売り場には行列ができていて、なかなか商品を選べなかったが、予想どおり、ロマンスカーミュージアムでもよく買っている列車のバームクーヘンを選んでいた。

その後は敷地内で色々な体験を楽しみ、最後に運転士体験をしてから、帰りの電車に乗った。

帰りの電車には、行きの電車で仲良くなった子供とそのお母さんが偶然乗っていた。帰りは一緒に遊びながら、楽しく電車で過ごすことができた。

小田原に戻ってもまだ時間があったので、久しぶりに新幹線を見に行った。

2026年9月30日水曜日

きっかけはAWS Summitの「ついで」

始まりは、AWS Summitの終わりにふらっと立ち寄ったStripeのブースでした。

仕事で前から気になっていたことをいくつか聞いてみたのですが、返ってきたのは「担当者に聞かないと分からないですね」という答え。そして「Stripe Tour Tokyoに来ていただければ、担当者と直接話せますよ」と勧められました。

実は昨年も行こうとしていたのですが、時間が取れずに断念していました。今年こそは、と思って参加を決めました。

朝ごはんを目指して、電車を乗り間違える

早く行くと朝食がもらえる、という情報を事前に聞いていました。

ただ、自宅から会場までは距離があるので、早朝に着くのはなかなか大変です。それでも「時間ギリギリには間に合うかな」という電車で出発したところ……乗る電車を間違えました。

思いもよらないタイムロス。遠方から都心のイベントに行くたびに、乗り換えの難しさを感じます。

幸い、告知された時間を過ぎても、基調講演が始まるまで朝食は出し続けてくれていました。ありがたい。

コーヒーとお茶
トルティーヤ
おにぎり
フルーツ

トルティーヤとおにぎりが並んでいるのが、グローバル企業の日本開催らしくて面白かったです。

天井の高いホテルで、ほぼ通常業務

会場は天井の高い、いわゆる高級ホテル。こういう場所に来るのは久しぶりです。海外の会社のイベントなので、外国の方も多く、少し海外カンファレンスのような雰囲気がありました。

そして正直に書くと、セッションにはあまり参加せず、ほとんど普通に仕事をしていました。

平日開催なので仕事もMTGも普通に入っていますし、Wi-Fiは会場で提供されていて接続も安定していました。席にも余裕があり、作業場所には困りませんでした。

一方で、気になった点もあります。

電源がない：15時ごろにはノートPCのバッテリーが18%に。冷や汗ものでした
BGMがうるさい：これが一番つらかった。もともと音には敏感なほうなので、長時間いると正直しんどかったです

次回はモバイルバッテリーと、できればノイズキャンセリングイヤホンを持っていこうと思います。

お昼はすき焼き弁当

昼食はお弁当が配られました。何種類かある中から、迷わずすき焼き弁当を選びました。イベントのお弁当としてはかなり満足度が高かったです。

エンジニアと直接話せる価値

今回の一番の目的は、エンジニアブースでした。

とりあえずサブスクリプション関連のブースに行ったところ、「それならこちらへ」とAPI（開発者）ブースに案内してもらえました。対応してくれたのは、海外出身らしいエンジニアの方と日本人エンジニアの方の2人。

APIのアップグレードや、Webhookを処理するときのレートリミットなど、ずっとモヤモヤしていたことを直接聞けました。「結局こちらで工夫するしかないのか」という答えもありましたが、公式の人から直接聞いて納得できることにはやはり価値があります。

あと、英語にはなりますが、StripeにはDiscordのコミュニティがあって、リアルタイムで質問できるそうです。これは知らなかった。

👉 https://discord.com/invite/stripe

会場から「チームの質問」を集めてみた

せっかく担当者がいるので、会場から社内のチャットで「Stripeに聞きたいことはありませんか？」と呼びかけてみました。

すると、以前Stripeを使ったプロジェクトのメンバーから、こんな悩みが返ってきました。

決済審査の状況をメールで問い合わせても、返事が来るまで数週間かかった
「投げ銭」のような、物を売り買いしないサービスは審査に通りにくいのでは？

最初は質問が抽象的だったので、「なぜその質問をしようと思ったのか（何に困ったのか）」を聞き直してから、サポート担当のブースへ持っていきました。具体的な背景が分かると、相手も答えやすくなるのを改めて実感しました。

担当の方から聞けた話をまとめると、こんな感じです。

審査について

投げ銭のようにリスクが高いと見なされるサービスは、社内審査に時間がかかりやすい
ただ、数年前までは却下していたものも、最近は「できるだけ検討して通す」方針に変わってきている

問い合わせの返事が遅い件について

Stripe社内のやり取りは基本的に英語なので、日本語の問い合わせは意思疎通に時間がかかることがある
窓口は複数の担当者で対応しているので、メールではなく、ダッシュボードのサポート画面から「サポートケース」を作って、その上でやり取りするのがおすすめ
状況をできるだけ詳しく書いておくと、審査もスムーズに進みやすい

「メールよりサポートケース」という話は、Stripeを使っている人にはかなり役立つ情報だと思います。

ちなみに、別件の相談でも担当の方と長く話し込んだので、すっかり顔見知りになりました。こういう関係ができるのも、オフラインイベントの良さですね。

お土産はもちろんタオル

帰り際にはお土産が配られていて、Tシャツかタオルを選べました。

もちろんタオルを選びました。Tシャツはもう家に十分あるので、実用性で選ぶとタオル一択です。

感想：「仕事環境が充実したカンファレンス」という価値

振り返ると、平日参加ということもあって、内容は「いつもの仕事を場所を変えてやった」に近い一日でした。

でも、それが逆に良かったと思います。

仕事を止めずに参加できる
合間にStripeの中の人と直接話せる
その場でチームの質問を集めて、すぐに答えを持ち帰れる
気になるセッションだけ覗ける

「仕事環境が充実している」こと自体が、このイベントの大きな魅力だと感じました。人混みや長時間のイベントが苦手な自分でも、自分のペースで過ごせたのは大きいです。

来年もまた行きたいと思います。次は電車を間違えずに、朝食の時間に間に合うように。

2026年9月26日土曜日

Platform Engineering Kaigi 2026

2026年9月26日（土）に中野で開催された Platform Engineering Kaigi 2026 に参加してきました。全体の感想と、聴講したセッションのまとめです。

概要

今年も参加しました。昨年と同じく Early Bird チケット（2,000円）を購入。
今年は「Platform City」という企画があり、自己紹介のホームページ作成から CI/CD までをやってくれるプラットフォームが用意されていました。AI で開発のハードルがだいぶ下がったこともあり、面白い試みだったと思います。
https://citymap.core.paas.jp/?_gl=1*1vgtjjf*_ga*MTE2MDY0NTUzNC4xNzkwMjMwNjcw*_ga_HNMDVRJB0L*czE3OTA4MTc1MDUkbzExJGcwJHQxNzkwODE3NTA1JGo2MCRsMCRoMA..
会場は中野。久しぶりだったので、駅の出口を間違えました。

全体の感想

Wi-Fi：会場の Wi-Fi はありましたが、Room を移動すると切れてしまいます。モバイル Wi-Fi を持っていって正解でした。
記録方法：発表は PC でリアルタイムに録音し、Claude で要約しました。今回は土曜日で仕事をする必要もなかったので、次回からは PC を持っていかなくてもよさそうです。
楽しみ1. 屋台：たこ焼きとクレープでした。以前はお酒もありましたが、今回は Red Bull に。Red Bull の大型コンテナ（？）は初めて見ました。
楽しみ2. マッサージ：「エンジニアは手をよく使うから」ということで、今回は手（手首？）をほぐしてもらいました。今までにない刺激でした。

聴講セッション

1. 基調講演：Architecting Agentic Development Platforms

登壇：Kaspar von Grünberg 氏（『Thinking in Platforms』著者）｜セッションページ

要点：モデルの競争ではなく、プラットフォームの競争

モデルはコモディティ化した。AI 導入後の生産性の差を生むのは、モデルを生産的に動かすプラットフォーム。今後はエージェントも「新しいユーザー」として迎える必要がある。
エージェント主導開発には 0〜4 の段階がある。レベル3（人間がオーケストレーター）が最大の転換点。レベル2以下が 72% を占め、「Copilot を入れたから十分」は危険。
エージェントは制御ループとして設計する（豊田佐吉の自働化が原点）。ハルシネーションは「最初のイテレーション」と捉え、決定論ゲート（CI など）と確率論ゲート（評価）を通ったものだけを人に渡す。
Agentic Development Platform は Tooling（既存の IDP）／Paths（ゴールデンパス）／Agent infrastructure（推論基盤・ハーネス・ガバナンス）の 3 レイヤー。
始め方は /pr-review（読み取り専用でリスクがほぼない）→ /validate-change（ハイブリッド）の順に、2〜3人の小チームで磨く。
質疑応答では「全社展開を急ぐと失敗する（あえて減速する）」「モデルアグノスティックに設計すべき」という話が印象的でした。

2. プラットフォームの複雑性はどこに住むべきか

12:15-12:45 Room A｜登壇：小野大器氏（enechain）｜セッションページ

要点：認知負荷は消えず、プラットフォームへ移る。それでも引き受ける価値がある

PR ごとに環境を複製するプレビュー基盤「prothea」（GKE 上の Kubernetes Controller）の設計事例。
マニフェスト生成方式ではなく、クラスター内で複製する Controller 方式を採用。ベースマニフェストは変更しない。
設定は段階的なインターフェースにする。普段は紐付け情報だけを書き、導出結果は困ったときに見る窓口にする。
Preview ID と Istio（GAMMA）を使ったヘッダーベースのルーティングで、プロダクトをまたいだプレビューも可能。
学び：必要な複雑さを引き受けられる技術を選ぶ／境界は引き直してよい／既存の概念を混ぜない／インターフェースに力を入れる。

3. AI Slopを生まないPlatform Service設計：価値仮説と効果測定ってどうやるの？

13:00-13:30 Hall｜登壇：木嶋幸子氏（レッドハット）｜セッションページ

要点：AI Slop は「低品質」ではなく、受け手の期待値とのずれ

受け手の 42% は、AI Slop を渡してきた相手を信用しなくなる。Platform に置き換えるとアダプションが下がる。
AI を使っても渡す側の責任は変わらない。リレーのバトンパス（ハンドオフ）が大事。
4象限（目的への貢献度 × 受け手の負荷）で緑ゾーンを目指す。まず貢献度を上げ、次に負荷を下げる。

成果物の4象限マトリクス

目的への貢献度＼受け手の負荷	負荷：低	負荷：高
貢献度：高	緑ゾーン（目標）目的に効き、受け手も楽	グレー良いものでも期待値がずれると AI Slop 扱いされる
貢献度：低	グレー楽だが目的に効かない	グレー効かないうえに負荷も高い

いきなり緑に入ることはほぼない。まず貢献度を確保して（上へ）、それから負荷を下げる（左へ）。
貢献度が低い状態から上げるのは難しい。戦略の誤りは取り返しがつきにくいので、リリース前に検証する。
グレーに入っても即中止にはせず、まず原因を分析する。

価値仮説（因果チェーン）を立て、VSM でハンドオフを観測する。正常系（効果）と異常系（副作用）をビジネスのテストケースとして測る。
検討記録が GitHub で公開されています。

感想

「成果物の4象限マトリクス」がとても良かった。もやもやしていたことが可視化・具体化できました。
Value Stream Management も良かった。今後の問題解決にぜひ適用したいです。

4. そのTerraform、マージした後も本当に安全か分かっていますか

13:45-14:15 Room A｜登壇：ハオ氏（テナブルネットワークセキュリティジャパン）｜セッションページ

要点：静的スキャンの緑チェック ≠ 安全

「その権限が実際に使われているか」はコードの中にない情報なので、静的スキャンでは判断できない。
検証例：どこにもアタッチしない IAM ロールは PR 時の IaC スキャンを通過し、apply 後の継続スキャンで「Inactive IAM Role」として検出された。
静的スキャン（車検）と継続スキャン（ドライブレコーダー）の両方が必要。
見つけたリスクはコンソールで直さず、コードに戻して直す（Cloud to Code）ことでドリフトを防ぐ。
AWS 標準機能なら、IAM Access Analyzer（未使用アクセス）や RoleLastUsed で検出し、Claude でコード修正の PR を作る形でも実現できそうです。

感想

どちらかと言えば製品の宣伝がメインでした。
少なくとも今の仕事では代わりの手段（IAM Access Analyzer＋Claude）があります。
セッションのタイトルに釣られた感じがしました。

5. Agentic Platform Engineering on AWS

15:15-15:45 Hall｜登壇：松岡雄地氏、小西杏典氏（AWS ジャパン）｜セッションページ

要点：AI エージェントに専門知識を持たせて、ゴールデンパスをスケールさせる

課題：ゴールデンパスを作っても使い方が伝わらず、プラットフォームチームに問い合わせが集中する。
AWS が OSS の APEX（Agentic Platform Engineering eXperience）を公開。ECS／EKS 構築のノウハウを Skills・Steering・Rules として持ち、既存のコーディングエージェントに追加して使える。
デモ：ECS Architect → ECS Build で要件から ECS Managed Instances を推奨し、検証が通る Terraform を生成。ECS Operation Review では既存環境を 8 つの観点で診断（サーキットブレーカーの無効などを検出）。
ガードレールは、人とエージェントの両方に SCP / Permission Boundary / Config / CloudTrail で同じように適用する。
リポジトリ：aws-samples/sample-apex-skills

感想

仕事でぜひ活用してみたいです。次のコマンドで導入できるらしいです。

npx apex-skills

6. セルフサービスのオブザーバビリティ基盤をOpenTelemetryで作る

16:45-17:15 Hall｜登壇：山口能迪氏（Grafana Labs）｜セッションページ

要点：「人の判断から仕組みへ」

計装漏れ（Propagator の設定漏れでトレースが切れる）や属性値のばらつき（production / prod / PRD）は、チームの怠慢ではなく仕組みの問題。
プラットフォームチームは 3 本柱でセルフサービスを作る。
1. SDK ディストリビューション：デフォルト値を持たせて配布する
2. Collector 層：Agent と Gateway の 2 層。PII・サンプリングの方針、OpAMP によるフリート管理
3. セマンティック規約のレジストリ：OpenTelemetry Weaver で許可する値を定義する
どの柱も「配布して終わりにせず、CI で検査する」。
生成 AI による障害調査でも、属性がそろっていることが調査時間とトークンの削減につながる。
解説資料：OpenTelemetryで作るセルフサービステレメトリー基盤（Zenn Book・無料）

感想

冒頭の「メトリクスなどの量が多すぎてコストを圧迫する」という話にとても共感しました。
今の仕事ですぐに使う機会はないかもしれませんが、勉強として OpenTelemetry を実際に使ってみたいです。
登壇者が翻訳した『入門 OpenTelemetry』も調べてみましたが、翻訳の評判はあまり良くないようです。ほかに参考になる本も探してみようと思います。

7. インフラとアプリの境界線と委譲の設計

登壇：鈴木勝史氏（スリーシェイク）｜セッションページ

要点：境界は「機能」と「役割」の2つ。両者は連動するので継続的に引き直す

機能の境界（プロビジョニング / デプロイ）：値が変わるタイミングで管理する側を決め、値の受け渡し方（インターフェース）まで設計する。
- 事故例：Terraform で apply したら Cloud Run のイメージが初期値に戻り、アプリが停止した。直接の原因は ignore_changes の漏れ、本当の原因は「イメージを誰が管理するか」を決めていなかったこと。
- 受け渡し方式：手で転記 → 名前で引く → tfstate を参照（ecspresso / tfstate-lookup）→ ストアに書き出し。
役割の境界（プラットフォームチーム / 開発チーム）：委譲には 5 段階あり、唯一の正解はない。ゴールデンパスは強制せず、標準から外れる逃げ道を用意する。
委譲で渡すものは「書く権限」「適用する権限」「結果への責任」。AI で書くのは楽になったが、結果への責任は人が持つ。

感想

前から気になっていた論点でした。
話はどちらかというと、アプリ開発者へ渡していく方向の内容でした。
一方、今の仕事ではインフラ側でアプリケーションのコードも書いています。

まとめ

今年は「AI エージェントをプラットフォームのユーザーとしてどう迎えるか」というテーマが全体を通して目立ちました。
共通していたキーワード：ゴールデンパス、認知負荷、ガードレール（決定論的な検査）、境界とインターフェースの設計。
すぐに試したいのは、APEX Skills の導入と、IAM Access Analyzer による未使用 IAM ロールの棚卸しです。
買いたい本：実践プラットフォームエンジニアリング　開発者体験を加速するセルフサービス基盤の設計と構築

※ 各セッションの内容は、当日の録音を文字起こし・要約したものです。聞き取りの誤りや解釈を含む場合があります。

2026年9月15日火曜日

本人にしか見せない画像を、CDN 越しに届ける

モバイルアプリのアイテム登録機能に、CloudFront Signed Cookie を使った画像配信基盤を導入した話。設計と実装、そして途中で踏んだ3つの地雷について書きます。

Rails / AWS S3 / CloudFront Backend & Platform 読了時間目安 8分

モバイルアプリでは、アイテムを写真つきで登録すると、ポイントや保証の管理に使えるようになっている。今回、この「アイテム写真」と「購入証明書の写真」を、これまでのような単純な公開URLではなく、本人だけがアクセスできる形で配信する基盤を作り直しました。この記事では、その設計と、実装中に遭遇した細かいけれど厄介な問題についてまとめます。

01背景と要件

これまで、アイテム画像はクライアントが用意した URL 文字列をそのまま DB に保存するだけの、ごく単純な仕組みでした。しかしアプリの機能拡張にともない、次の要件が持ち上がりました。

Requirements

→ 画像はサーバー経由でアップロードするクライアントから直接ストレージを叩くのではなく、アプリサーバーが受け取って保存する形にしたい（バリデーションと保存先を一元管理するため）。
→ ユーザー自身の画像しか見えないアイテム写真・購入証明書は個人情報に近い。URLを知っていれば誰でも見られる状態は避けたい。
→ 配信はCDN経由にするS3から直接返すのではなく、CloudFrontでキャッシュ・配信したい。ただし「認証つきCDN配信」と「本人限定」を両立させる必要がある。
→ モバイル側の実装コストを抑えるリクエストのたびに署名付きURLを都度発行するのではなく、ログインしてしまえばあとは普通に画像を読み込めるようにしたい。

「本人限定」と「CDN配信」を両立させる方法として選んだのが、CloudFront の Signed Cookie です。署名付きURLだと画像1枚ごとに個別の署名が要りますが、Signed Cookie ならログイン時に一度発行しておけば、あとはブラウザ（アプリ）が自動的にCookieを送ってくれるので、モバイル側の実装がシンプルになります。

02アーキテクチャ

全体は「アップロード」と「配信」の2つの流れに分かれます。どちらも同じ非公開S3バケットとRailsアプリサーバーを経由しますが、認証の仕組みが異なります。

図: アップロード（レーン1）と配信（レーン2）は同じS3バケットを共有するが、認証の仕組みは別。配信側の検証はCloudFrontのエッジで行われ、アプリのコードは一切関与しない。

ポイントは、Signed Cookie の検証ロジックはアプリケーションコードのどこにも存在しないということです。Railsが担うのはCookieを「正しく発行する」ことだけで、検証はすべてCloudFrontのエッジ側で完結します。裏を返すと、発行時にちょっとでも間違った値を作ってしまうと、それを検出できるのは実際にCloudFrontにリクエストが飛んだ瞬間だけ、ということでもあります。これが後述するハマりどころに直結します。

Cookieはいつ発行するか

Signed Cookie は次の2つのタイミングで発行・再発行します。

ログイン時 — 毎回無条件に新規発行する
認証つきAPI呼び出し時 — リクエストに3種類のCookieが揃っていない場合だけ、その場で再発行する（アプリの再インストールでCookieだけ消えた場合の保険）

有効期限は10年という、一見雑に見える値を設定しています。アプリ側のログイントークン自体に有効期限の概念が無いため、それに合わせて「実質失効しない」十分に長い値にした、という判断です。

03実装したこと

アップロードAPIは、これまでの「クライアントがURL文字列を送る」方式から、「クライアントが画像バイナリそのものを multipart で送る」方式に変更しました。サーバー側は受け取った画像を検証してS3に保存し、DBには完全なURLではなくS3キーだけを保持します。レスポンスを組み立てる際に、このS3キーをCloudFront配信URLへ変換します。

users/{user_id}/items/{item_id}/case/{timestamp}-{random}.jpg
users/{user_id}/items/{item_id}/purchase_certificate/{timestamp}-{random}.jpg

DBに完全なURLではなくキーだけを持たせたのは、配信ドメインを後から変更しやすくするためです。実際、開発環境と本番環境で配信ドメインが異なるため、この一段のクッションが効いています。

04ハマったところ

設計自体は素直でしたが、実装の過程で3つ、地味に厄介な問題にぶつかりました。いずれも「ローカル開発環境には本物のCloudFrontが無い」ことが発見を遅らせた共通点です。

全画像 403

ワイルドカードは「カスタムポリシー」でないと効かない

問題Signed Cookieには「既定ポリシー（canned policy）」と「カスタムポリシー（custom policy）」の2種類があります。既定ポリシーはCookieに有効期限しか含まず、CloudFront側が実際にリクエストされたURLからポリシーを再構築して検証します。今回のように users/{user_id}/* というワイルドカードを含むリソースを許可したい場合、既定ポリシーでは検証時に組み立て直したURLと署名対象が一致せず、問答無用で403になります。

気づいたきっかけローカル開発環境には実物のCloudFrontが存在しないため、この不具合はテストでは一切表面化しませんでした。実際にAWS SDKのCookie発行ロジックを手元で動かし、生成された署名を実際に検証してみて初めて気づく類の問題です。

解決ポリシーJSONを自前で組み立てて明示的に渡す、カスタムポリシー方式に切り替えました。発行されるCookie名も変わる（CloudFront-Expires → CloudFront-Policy）ため、関連するテストやドキュメントもあわせて追随させています。

署名が壊れる

フレームワークがCookieの値を勝手にURLエンコードしていた

問題CloudFrontの署名付きの値は、通常のBase64ではなく+ = / をそれぞれ - _ ~ に置き換えた独自形式です。ところがRailsのCookie機構は、値をSet-Cookieヘッダーに書き出す際、内部でURLエンコード処理を通しており、この~が%7Eに変換されてしまっていました。

送出された値

Signature=abc~def~ghi

実際にブラウザが保持する値

Signature=abc%7Edef%7Eghi

ブラウザ（アプリ）はSet-Cookieの値をそのままのバイト列として保存・送信するだけなので、%7Eは~には戻りません。CloudFront側はこの3文字を「1文字の~」として解釈できず、署名データの一部を読み違えて検証に失敗します。

気づいたきっかけログインもアイテム登録も普通に成功し、返ってくる画像URLも一見正しく見えるため、切り分けが非常に難しい壊れ方でした。実際にレスポンスの生ヘッダーを見て、値の中に%7Eが複数含まれていることに気づいたのがきっかけです。

解決RailsのCookie機構（フレームワークによる自動エスケープ）を経由せず、Set-Cookieヘッダーの文字列を自前で組み立てて直接レスポンスに載せるように変更しました。値自体はエスケープが不要な文字種（英数字と- _ ~のみ）だったため、素通しで問題ありません。

型が壊れる

multipartはネストしたJSONを運べない

問題購入証明書登録APIでは、画像とあわせてAI判定結果（金額や店舗名などを含むJSONオブジェクト）も送る必要があります。しかし multipart/form-data は「名前＝文字列」しか運べないため、ネストしたオブジェクトを送ろうとすると、数値が文字列になり、nullが空文字になり、空配列がキーごと消える、という劣化が起こります。

ブラケット記法（NG）

ai_result[price]=1200
ai_result[dates][]=

JSON文字列化（OK）

ai_judgment_result=
{"price":1200,"dates":[]}

解決ネストしたオブジェクトをブラケット記法に分解するのではなく、JSON文字列化した1つのフィールドとして送ってもらい、サーバー側でパースする方式に統一しました。型情報を保ったまま運べるうえ、クライアント側の実装もシンプルになります。

05まとめ

今回いちばん学びが大きかったのは、「検証ロジックがアプリの外（CDNのエッジ）にある」仕組みは、ローカル環境だけでは正しさを保証できないということです。3つのハマりどころのうち2つは、実際にAWSのSDKを手元で動かして署名やヘッダーを1バイトずつ確認するまで発覚しませんでした。テストが通っていても、境界の外側で何が起きているかは別の話だと痛感しました。

一方で、Signed Cookieという仕組み自体は、いったん正しく発行できてしまえばアプリ側の実装は驚くほどシンプルです。画像1枚ごとに署名付きURLを発行する必要も、モバイル側で特別なヘッダーを付け回す必要もありません。ログインという1点さえ正しく作り込めば、あとは普段どおりの画像読み込みで「本人限定配信」が実現できる。地味ですが、良い設計だったと思っています。

この基盤は現在、社内のモバイルアプリチームと連携しながら実際のクライアント実装を進めているところです。実機での検証がまとまり次第、続報を書きたいと思います。

Rails AWS CloudFront Signed Cookie S3 アーキテクチャ

2026年9月3日木曜日

Amazfit HELIO STRAP購入

■発端

加齢のせいか、最近、眠りが浅くなってきた気がする。

色々調べてみたところ、世の中には睡眠の質を計測するアプリがあることを知った。

それで、良さそうなものを入れてみたのだが、以下のような難点があった。

・寝る前にアプリを起動する必要がある
・家族と一緒に寝ているせいか、自分には身に覚えのない「いびき」や「咳」が記録されていた
・一応、録音もされていたが、確認するためには課金が必要だった

ちょうどAmazonセールでポイントも貯まっていたので、何かしら睡眠を計測できる装置を買うのも良いかと思うようになった。

調べてみると、睡眠計測専用の装置もあるらしいが、数万円台のものが多く、かなり高い。

一般的なのはスマートウォッチで、安いものなら1万円未満のものもあった。

ただ、別に画面を見ながら操作をしたいわけでもないし、中国製の端末を身につけて、自分の個人データを計測することには少し抵抗がある。

そこで、最終的にたどり着いたのが「スマートバンド」というものだった。

■購入

初めはスマートリングも考慮した。

ただ、これもまあまあ高かったし、そもそも普段から指輪を使う習慣がない。

あまり指輪をつけたくないし、個人的には見栄えもあまり好みではない。

スマートバンドで調べると、GoogleとAmazfitあたりに絞られた。

サイズ感などはGoogleのものが良さそうだったのだが、最近発売されたばかりということもあってか、どこも品薄で売り切れ状態。

しかも、計測自体はできるものの、計測値を評価するためには課金が必要になるようだった。

一方、AmazfitはちょうどAmazonセールで10％ほど安くなっていた。

しかも、今まで貯めていたAmazonポイントで全額支払える。

ということで、Amazfit HELIO STRAPを購入した。

■Amazfit HELIO STRAP しばらく使ってみての感想

注文してからは、結構早めに発送された。

・今まで使っていた睡眠測定アプリと並行して使ってみた。寝る前にアプリを立ち上げなくても済むのは助かる。ただし、周りの音を拾う機能がないため、以前記録されていた咳・いびきについては、結局謎のままになってしまっている

・腕に何かを付けて寝たことがないので、これを付けたまま寝られるかが心配だったが、意外と普通に寝られた。ただし、ある程度しっかり手首につけておかないと、起きたときに緩くなっていた。今度、余裕があったら大きめのバンドを買って、足に付けても良いかもしれない

・HYBRIDCHARGEで総合的な「元気度」のようなものが分かるのは助かる。数値をどこまで信頼して良いのかは分からないが、自分が客観的にどのくらい疲れているのかが見えるのは面白い

・モデル名に「FIT」がついていることもあり、運動項目が充実している。普段、あまり運動していない自分でも、これを見ていると運動をして数値化したい気持ちにさせられる。運動する前に何の運動をするか選ぶようになっているが、残念ながら弓道はなかった。代わりにアーチェリーを選択している

・運動項目にスイミングもあるので、おそらく防水性能もあるのだと思う。ただ、高い機器を水の中に入れるのはやはり怖い。一応、旅行中にプールで使ってみたが、今のところは大丈夫そう

・一応、課金メニューは存在するが、確かに使わなくても特に支障はなさそう。睡眠健康評価は少し気になるので、どこかで一度、有効化してみるかもしれない

ちなみに、買ったタイミングで一番最初に気づいたのは子どもだった。

その後は旅行だったこともあり、ずっと付けていたが、誰も特に気づかなかった。

そういえば、着替えるときに妻が気づいていたような……。

2026年9月1日火曜日

「開発環境は止まっているはずなのに」— AWS Configコスト急増の犯人を追いつめた話

TL;DR

コスト削減のため夜間・週末に自動で止めているはずの開発環境で、AWS Configの利用料金だけが跳ね上がった
「起動・停止の瞬間にコストが増える」という自然な仮説は、調査したら半分正解・半分不正解だった
本当の犯人は、環境の停止処理がECSサービスの Application Auto Scaling を止めていなかったことによる、丸4日間ぶっ通しのタスク起動失敗ループだった
最初の修正案もレビューで「まだ不十分」と指摘され、AWSの正式な「Auto Scalingの一時停止」機能に作り直すことになった

以下、調査の一部始終と、そこから得た教訓をまとめる。

背景

とあるWebサービスのdevelop/staging環境は、コスト削減のために夜間・週末は自動で止まるようになっている。具体的には、Lambda + EventBridge Schedulerで組んだ仕組みで、

ECS Fargateサービスを desiredCount = 0 にスケールダウン
RDS Auroraクラスタを停止
NAT用・踏み台用のEC2インスタンスを停止

という3点セットを実行し、平日朝に元へ戻す。よくある構成だと思う。

このスケジュールをしばらく無効化していた期間があり、再度有効化したところ、AWS Configの利用料金（Configuration Item記録件数に応じた課金）が急増した。「起動・停止イベントが増えたから、その分Configの記録も増えたのだろう」と考えるのが自然だし、実際そういう外部の事例もいくつか見つかる。

というわけで、原因を確定させ、直すことにした。

第一の仮説：起動・停止のたびにENIが作り直される

ECS Fargateをawsvpcネットワークモードで使っていると、タスクが再作成されるたびに新しいENI（Elastic Network Interface）が払い出される。これ自体はAWS::EC2::NetworkInterfaceというリソースタイプとしてAWS Configに記録される対象で、実際にいくつかのブログ記事でも「ECSタスクの頻繁な入れ替わりでConfigコストが跳ね上がった」という事例が紹介されている。

これを検証するために、調査専用の一時的なCloudTrail（管理イベントのみ、単一リージョン）を新しく作り、既存の設定には一切手を触れずに構築した。ついでにAWS Configのselect-resource-config（Advanced Query）やget-discovered-resource-counts、CloudWatchメトリクス（AWS/Config名前空間のConfigurationItemsRecorded）も使って、実際に何が記録されているかを定量的に追いかけた。

起動イベントの瞬間（数十分のウィンドウ）を見てみると、確かに記録の内訳はこうなっていた。

リソースタイプ	件数	比率
EC2::NetworkInterface	最多	約3割
EC2::SecurityGroup	次点	約2割弱
ECS::Service		約1割強
EC2::Instance（NAT/踏み台）		1割弱
その他（RouteTable/EIP/RDS等）		残り

想定通り、ENI（と、それに付随するSecurityGroupやRouteTableなどの周辺リソース）が最多だった。「やっぱりこれが原因か」と一瞬納得しかけた。

ここで、地味に役立った教訓が一つ。select-resource-config（Advanced Query）は「各リソースの最新の状態」しか返さない。過去のある時点で何が記録されたかを調べようとしても、そのリソースがその後さらに変化していれば、古いタイムスタンプでの記録はヒットしない。「昨日の停止イベントを調べようとしたら0件だった」と一瞬焦ったが、原因はこれだった。過去の特定時点の記録を追うには、リソースIDを指定して履歴を直接取得できるAPI（get-resource-config-history）や、Config配信チャネル先のS3にある設定履歴ファイルを使う必要がある。

しかし、これでは説明がつかない

起動・停止イベント単体の影響は数十件程度で、確かに存在はする。しかし、Cost Explorerでコスト推移を見ると、環境が完全に停止しているはずの期間（週末含む、丸4日間）もコストが下がるどころか上がり続けていた。

もし原因が「起動・停止イベントに伴う一過性のENI churn」なら、停止直後にスパイクしてすぐ収まるはずだ。しかし実際は、停止期間中ずっと高止まりし、日を追うごとにむしろ微増していた。これは「一過性のイベント」の説明では無理がある。「別の何かが継続的に発生している」と考えるべきだった。

寄り道：見当違いの仮説を検証して捨てる

真っ先に疑ったのは、「現在Configが管理しているリソースの総数」を見たときに突出して多かった、あるレガシーなリソースタイプ（過去に別件のコスト急増の原因になったことがあるもの）だった。しかし、そのリソースタイプ単体のCloudWatchメトリクスを見ると、直近ではほとんど動きがなかった。「総数が多い」ことと「直近の変化率が高い」ことは別物だと、指摘されて初めて気づいた。仮説は却下。

次に、「Config全体の記録件数」と「ENI（EC2::NetworkInterface）単体の記録件数」を日次で比較してみると、両者はほぼ同じ形（ベースラインの約15〜18倍に跳ね上がり、その後も高止まり）をしていた。しかも比率がずっと一定（全体のうち常に2〜3割程度）。ここでようやく「ENIが本命で間違いない、ただし発生源は起動・停止イベントとは別」という当たりがついた。

犯人探し：CloudTrailで「誰が」ENIを作っているかを追う

CloudTrailでCreateNetworkInterfaceイベントのdescriptionフィールドを見ると、完全に停止しているはずの1日分の記録が、すべてECSタスクのアタッチメントを示す形式（arn:aws:ecs:...:attachment/<uuid>）だった。しかもユニークなIDが数百件並んでいて、「同じ理由で1回だけ大量発生した」のではなく「何かが延々とタスクを再作成し続けている」ことを示していた。

不思議なことに、明示的なRunTask呼び出しは1日たった数件（既知の定期実行ジョブ分だけ）しかなかった。ここで学んだのが、ECSサービスがスケジューラ経由で内部的にタスクを再配置する場合、RunTaskではなくTaskCreatedという別の管理イベントとして記録されるということ。実際にTaskCreatedイベントの件数を見ると、RunTaskの数十倍あった。

ここから、作成されたENIの「サブネットID」と「セキュリティグループID」の組み合わせを集計し、既知のリソース（AZごとに2つのサブネットに分散配置されるのが通例）と突き合わせることで、犯人サービスを絞り込んだ。最終的にaws ec2 describe-security-groupsでセキュリティグループ名を引いて、内部向けAPIサービスであることが判明した。

根本原因：Auto Scalingが停止と綱引きしていた

該当サービスのdescribe-servicesのイベントログを見て、ようやく全貌が見えた。

(service ...) was unable to place a task. Reason: ResourceInitializationError:
unable to pull secrets or registry auth: unable to retrieve secret from asm:
There is a connection issue between the task and AWS Secrets Manager.
... context deadline exceeded.

タスクが起動すらできず、コンテナ定義に紐づいたSecrets Managerのシークレット取得でタイムアウトしていた。原因はシンプルで、環境停止時にNAT用EC2インスタンスも一緒に止めているため、プライベートサブネットからインターネット（Secrets Managerのパブリックエンドポイント）へ抜ける経路が失われていたからだ。

ではなぜタスクを起動しようとしていたのか。該当サービスにはApplication Auto ScalingがMinCapacity=1で登録されており、環境停止処理がこのAuto Scalingの設定に一切触れていなかった。停止処理はUpdateService(desiredCount=0)でサービスを一旦0にするが、Auto Scalingは自分の管理範囲（Min1〜Max2など）を守ろうとして、定期的にdesiredCountを1へ戻そうとする。

Auto Scalingがタスクを1つ起動しようとする
NATが止まっているのでSecrets Manager取得に失敗し、約13分でタイムアウト
ECSが即座に次のタスクを試みる
以下、環境停止期間中（今回のケースでは最大4日弱）ずっと、13〜27分間隔で繰り返し

サービスのイベントログのタイムスタンプを丹念に追うと、この失敗ループは環境の起動処理でNATが復旧した直後にピタリと止まっていた。ここまで来ると、もう疑いようがない。

一度目の修正：レビューで「まだ足りない」と言われる

最初に考えた修正は素直なものだった。停止時にAuto ScalingのMinCapacityを0にし、起動時に元へ戻す。IAM権限もDescribeScalableTargets/RegisterScalableTargetの2つだけで済むし、実装もシンプル。コードレビューに出した。

すると、こういう指摘が返ってきた。

MinCapacityを0にするだけでは、Auto Scalingに登録済みの「スケジュールドアクション（毎日決まった時刻にMin/Maxを書き換えるアクション）」に上書きされてしまうのでは？

確認してみると、まさにその通りだった。当該サービスには「毎朝の営業開始前にスケールアウトする」「毎晩の営業終了後にスケールインする」という、Auto Scaling自体のスケジュールドアクションが別途設定されていた。これは環境の起動停止スケジュールとは完全に独立して毎日動く。つまり：

環境を停止した直後の夜、Auto Scaling側の「スケールイン」アクションがMinCapacityを1に戻す
環境の起動処理より前に、Auto Scaling側の「スケールアウト」アクションがMinCapacityを1に戻す（NAT起動よりも先に）

MinCapacityを直接書き換える方式では、この2つの独立したスケジュールに対して常に後出しじゃんけんで負ける構造だった。しかも、TerraformでこのMinCapacityを管理している場合、Lambdaが書き換えた値は次回のterraform applyで元に戻されてしまう（driftの元）という副作用まで指摘された。

二度目の修正：AWS標準の「一時停止」機能を使う

Application Auto Scalingには、まさにこの用途のための機能がある。RegisterScalableTargetAPIのSuspendedStateだ。MinCapacity/MaxCapacityの値には一切触れず、「動的スケーリング」と「スケジュールドアクション」の両方を丸ごと一時停止・再開できる。

# 停止時
autoscaling.register_scalable_target(
    ServiceNamespace="ecs",
    ResourceId=resource_id,
    ScalableDimension="ecs:service:DesiredCount",
    SuspendedState={
        "DynamicScalingInSuspended": True,
        "DynamicScalingOutSuspended": True,
        "ScheduledScalingSuspended": True,
    },
)

# 起動時（すべてFalseに戻すだけ）
autoscaling.register_scalable_target(
    ServiceNamespace="ecs",
    ResourceId=resource_id,
    ScalableDimension="ecs:service:DesiredCount",
    SuspendedState={
        "DynamicScalingInSuspended": False,
        "DynamicScalingOutSuspended": False,
        "ScheduledScalingSuspended": False,
    },
)

これなら、Auto Scaling側のスケジュールドアクションも含めて確実に止まるし、Min/MaxCapacityの値そのものは触らないのでTerraformとのdriftも起きない。IAM権限も変わらず同じ2つで済んだ。

あわせて、「環境起動後のサービス安定化待ちがタイムアウトした場合でも、Auto Scalingを止めたまま放置しない」ようにtry/finallyでresume処理を保証するようにした。一時停止したまま忘れられると、今度は逆に「業務時間中の正常なオートスケールが働かない」という別の障害になりかねないからだ。

教訓

「怪しいものが大量にある」と「直近悪化した原因である」は別物。総数のスナップショットだけで判断せず、時系列のレート（メトリクス）で裏を取る。
AWS Configの「今のリソース状態」を返すAPIと、「過去の履歴」を返すAPIは別物。過去のある時点を調べたいなら履歴系のAPI（あるいは配信されたログファイル）を使う。
CloudTrailの「明示的なAPI呼び出し」と「サービス内部の自動処理」は別のイベント名で記録されることがある。RunTaskが少ないからといって、タスクがあまり起動していないとは限らない。
「止める」処理を書くときは、それを上書きしうる自動化（Auto Scaling、他のスケジュール、外部の監視ツールによる自動修復など）が他にないか、必ず洗い出す。今回は「環境の起動停止スケジュール」と「Auto Scaling自身のスケジュール」という、独立に育った2つの自動化が噛み合っていなかったことが根本原因だった。
コードレビューは通す。一度目の修正で「動くはず」と思っていたが、実際にはterraformの中身まで確認しないと見抜けない落とし穴があった。一人で完結させず、指摘をもらえる体制は大事。

似たような「開発環境の自動停止」を運用している人の参考になれば幸いです。

2026年8月16日日曜日

子どもの誕生日プレゼント

準備など

子どもの誕生日が近くなると、何が欲しいのか聞いているが、その日の気分によって欲しいものが変わることが多い。

最終的に、最近ブームになっているマインクラフトのおもちゃの剣が欲しいと言った。

ちなみに、その前は友達が持っていたトミカの連結バスが欲しかったらしい。また、妻は勉強にもなる遊びができるレゴが良いらしい。

まずは本命である剣をネットで探してみたら、まあまあ高かった。

そんな中、Yahoo!ショッピングのある店がAmazonより3分の2くらいの値段で販売していたので、購入することにした。Amazonではないので発送期間が少し心配ではあったが、誕生日の6日前だったので、まあ大丈夫だろうと思っていた。

妻があげたかったレゴは、イオンで安く売っていたので別途購入。

ついでに、マインクラフトのアイスクリームケーキも欲しかったらしく、こちらも注文した。

トミカ購入

だいぶ前に小田原図書館で子ども向けイベントのチラシを見つけ、8/9（日）だったので申し込んでいた。

参加費は200円で、場所は小田原駅から近い公民館だった。

初めは市外からの申し込みだったので、あまり期待していなかったが、受付済みの連絡をもらった。前日になるとSMSで改めて案内が来るなど、意外としっかりしている感じだった。

子どもは最初、あまり行く気がなさそうだったが、「トミカを買ってあげる」ことで、何とか行くことができた。

最近はあまり外に出かけたくないらしく、物で釣るしかなくなってきた感じがする。

公民館は駅から近かったが、結構年季の入った建物だった。

参加者は全部で10組くらいで、比較的小さな子どもが多かった。

それでも、うちの子としては工作もできて、まあまあ満足だったらしい。

ちなみに、小田原市の何かしらの取り組みらしく、ゲストの人たちが後ろで大勢見学していた。

そのあとは、いつもの子育てサロンと図書館、バーガーキングに行って、最後に約束していたトミカを買った。

配送遅延

誕生日が間近になっても、プレゼントの発送連絡が来ない。

店に連絡してみると、その途端にステータスが「発送済み」になっていた。なんだか怪しい。

どうやら海外からの発送だったらしい。確かに購入する際に、発送目安の案内をちゃんと読んでいなかった。こちらの確認不足でもあるが、商品ページのどこにも海外からの発送とは書かれていなかった。

幸い、子どもは今回いろいろ買ってもらったこともあってか、多少遅れても問題ないらしい。

結局、プレゼントが届いたのは誕生日を過ぎた8/16だった。

購入してから一週間以上かかっている。海外発送としては早い方なのかもしれないが、誕生日プレゼントだったことを考えると、あまりすっきりしない感じだった。

2026年8月12日水曜日

「このメンバーで大丈夫か？」と言われたときに、何をどう動かしたか

背景

あるとき、上層部の会議で新しいプロジェクトの担当割りについて「大丈夫か？」という懸念が出た。特定のメンバーが新しいプロジェクトを主導することになったタイミングで、である。

現場ではすでに、社内ルールの整備・1on1・報告書の提出依頼といった対応が進められていた。しかし、それらを重ねても上層部の不安はなかなか払拭されなかった。

この経験を通じて考えたこと、実際に取った対応を、一般化した形で残しておく。

気づいたこと：「人を信じてもらう」では不安は消えない

1on1・報告書・ルール整備は、いずれも「本人の行動を改善する／可視化する」ためのアプローチだった。しかし振り返ると、上層部が求めていたのはそれとは少し違う種類の安心感だったのではないかと思う。

1on1は主観的なやり取りで、外部には見えない
本人が書く報告書は、恣意性が入りやすく信頼の証明にはなりにくい
ルール整備は属人化リスクを下げる仕組みだが、「この人で大丈夫か」への直接的な回答にはならない

つまり、「本人を信じてほしい」という路線だけでは、組織が求める「仕組みとして担保されている」という安心材料にならないということだった。

そこで、アプローチの重心を「人への信頼」から「仕組みへの信頼」に移すことを考えた。

具体的に取ったアプローチ

1. 懸念の正体を具体化する

「大丈夫か？」という発言は抽象的だった。技術力なのか、コミュニケーションなのか、過去の経緯なのか。まずは懸念の中身を関係者間で言語化することから始めた。曖昧なままだと、何をやっても「まだ不安」と言われ続けてしまう。

2. 「合意形成」を先に固める

技術的な対応内容そのものよりも、「その対応レベルで良い」ということについて、関係する事業側の担当者が納得・合意しているかどうかの方が本質的だと考えた。

対応が完了していても、その基準について事業側の合意が取れていない状態で報告だけが出ると、一方的な連絡で終わってしまい、報告後も同じ構造の懸念が再燃しかねない。そのため、正式な報告の前に、関係者との間で「このリスク許容レベルで進める」という合意を明示的に取ることを優先した。

口頭だけでなく、誰が・何に合意したかが後から分かる形で残すようにした。

3. コミュニケーションの実態を、本人を介さずに確認する

本人が頑張っていても、周囲とのコミュニケーションの取り方によって、些細な話でも上位者へのエスカレーションが起きやすい状態になっている可能性を考えた。

これは本人の能力の問題ではなく、関係者との情報のやり取りの構造の問題として捉えた。そこで、調整が可能な立場の人に、関係者側が実際どう感じているかをヒアリングしてもらう、という動きを提案した。自分から直接動くと、本人の頭越しに評判を探るような形になりかねないため、権限のある人に依頼する形を取った。

4. 人選・役割の見直しは、別の文脈で、タイミングを分けて考える

対応を進める中で、そもそも本人の得意な仕事のスタイルと、今回のタスクの性質が噛み合っていない可能性も見えてきた。これは技術的な問題とは次元の違う話であり、扱いを一段慎重にする必要があると考えた。

直近の懸念対応（合意形成・報告）と同時に進めない。混ぜると「指摘を機に外された」という見え方になりやすい
「向いていない」ではなく「本人の強みをより活かせる場がある」というプラスの文脈で伝えられるかを重視する
決定権のない自分が直接本人に伝えるのではなく、権限を持つ人に判断してもらう

5. 提案は「選択肢」として渡す

関係者に何かを依頼するときは、「やってください」ではなく「一つの案として、採用するかどうかも含めてお任せします」という伝え方を意識した。

理由は、進め方や本人への伝え方について、自分より状況を把握している人がいる場合、その人の判断を尊重した方が結果的にうまく進むことが多いためである。指示ではなく選択肢を渡すことで、相手も動きやすくなる。

まとめ

「大丈夫か？」という不安に対して、本人の頑張りをアピールするだけでは効果が薄い場面がある。そのときに有効だったのは、次の3つの視点だった。

人への信頼ではなく、仕組みへの信頼に置き換える（合意形成、段階的な権限拡大、レビュー体制など）
懸念の背景にある構造（コミュニケーションの取り方など）を、本人を介さずに確認する
技術的な対応と、人選・役割の見直しは、時間軸を分けて別々に進める

組織の中で「この人は大丈夫か」という空気が生まれたとき、個人の弁明や努力だけで払拭しようとすると長期化しやすい。仕組みとして「何かあっても組織は対応できる」という状態を作ることの方が、結果的に速く、かつ本人にとってもフェアな解決に近づくと感じている。

2026年7月23日木曜日

AWS Certified Data Engineer - Associate 合格

背景

前回の受験で申し込んでいたCloud Licenseの期限がまだ残っていたので、有効活用するために何か簡単そうな試験に挑戦しようと思った。

残っている試験はAssociateかSpecialtyのどちらかだが、Specialtyはまだ難しそうだった。

Data Engineerは今の仕事とはあまり縁がなさそうではあるが、一応AWS Glueを使ったことがあり、全く経験がないわけでもない。

「これも落ちたら仕方ない」という気持ちで挑戦することにした。

勉強した書籍・サービス

Cloud Licenseのみを利用し、分からないところはインターネットで記事を検索して学習した。
RedshiftやEMR関連はほぼゼロから勉強するような感じだったが、これまでのAWSの経験があるからか、それ以外は比較的スムーズに理解できた。間違えた問題の復習も2周目まで終えることができた。
Cloud Licenseの有料オプションが切れたタイミングで試験日を決定。もともとは金曜日に受験する予定だったが、午前中に空きがなかったため、仕方なく木曜日にした。
ネット上でData Engineer試験の内容をよくまとめた記事を見つけたので、最後はそれを使って復習した。しかし、読んでいると分からない内容が次々と出てきて、試験直前まで焦っていた。

受験日

朝早めに家を出て、いつもの喫茶店で試験対策のまとめ記事を読みながら最後の勉強をした。
試験会場で席に座ると、左斜め前の人がCCNAらしき試験を受けていた。最初は気にならなかったが、その人が考えるたびに頭に手を乗せる動作を繰り返していて、視界に入るたびに気が散ってしまった。仕方なく見えないように姿勢を変えていたが、それでも時々視界に入ってしまった。
十数問を見直し対象としてチェックし、ちょうど制限時間いっぱいで試験を終えた。

結果

少し自信はあったものの、点数はこれまでと同じように合格ラインを少し上回る程度だった。とりあえず合格できたので良しとしよう。

次はどうするか

Cloud Licenseも期限切れになったので、今度こそAWS認定試験はしばらく休もうと思う。
本も読みたいが、以前から周りに「簡単だから取れる」と勧められている簿記の勉強にも挑戦してみたい。

Bitcoinでスマホ購入など

Korbitが使えるようになった

前回の帰省で、ようやくSMS認証ができるようになった。

ただ、以前から利用していた韓国の暗号資産取引所は、電話番号の変更申請ができず、そのまま時間だけが過ぎていた。

何度か試行錯誤した結果、何とか電話番号の変更と銀行口座の連携まで完了した。

AQUOS Sense4 Liteの限界

今の楽天モバイルを使い始めたときに購入した端末で、おそらく5年半ぐらい使っている。

最近は、いろいろなアプリのサイズが大きくなってしまい、なるべくこまめにキャッシュを削除したり、使っていないアプリをアンインストールしたりしていたが、それもそろそろ限界という感じがしてきた。

ゲームをするために何とか空き容量を作ってインストールしてみても、動作が重い。
たまに子どもと出かけたときに写真を撮ることがあるが、妻のiPhoneと比べると、その差は明らかだった。子どもの写真は、とっさに撮ることが多いので、手ぶれ補正が欲しい。
写真は後から何度も見返すものなので、今しかない瞬間はきちんと残しておきたい。
低確率ではあるが、たまに写真を撮るときに本体がフリーズしてしまう。おそらくSDカードに写真を保存しているせいだと思うが、出かけた先でそうなると、本体を再起動する時間がもったいない。
指紋認証でロックを解除できるのは便利だが、たまに意図せず楽天アプリが起動してしまうことがある。
セキュリティサポートも終了しているし、そろそろアプリがAndroid 12にいつまで対応するのかという不安もあった。

購入候補

まず、中国製は除外することにした。そもそも「日本製」といっても、中身は中国製だったり、名前だけ日本企業になっていたりするケースもあるが、国籍が違うというだけでも何となく安心感がある。
プリインストールアプリが多いものも避けたい。キャリアで購入すると、デフォルトで入っているアプリが多すぎる。以前使っていたAQUOSも楽天関連のアプリがたくさん入っていた。楽天はそれなりに使っているし、削除もできるのだが、何かしらデフォルト設定になっているのを見ると、あまり気分が良くない。
そう考えると、SIMフリーのGoogle Pixel系になるかと思った。
ただし、実際に店に行ってみると、SIMフリーの端末はかなり限られていた。
大半を占める中国製を除くと、AQUOSかXperiaの二択になってしまった。
同じ価格で性能だけを考えるとAQUOSのほうが優位だったが、以下の理由からXperiaを選択した。

1. デザインの問題

AQUOSは背面のカメラ部分が大きな丸になっていて、かなり主張している感じがした。

スマホは普段持ち歩くものなので、外見が気に入らないと、見るたびにストレスになりそうだった。

何より、最近は「おじさんが首から掛けて歩いているスマホ」というイメージがあるのも嫌だった。

2. カメラボタンの存在

子どもの写真を撮ることが多いが、今まではロックを解除してからカメラアプリを起動するのが、確かに少し手間だった。

今回のXperiaには専用のカメラ起動ボタンがあるのが良かった。

3. 指紋認証の場所

AQUOSは指紋認証センサーが端末の下に配置されているが、今までホームボタンを押す際に触ってしまうことがたまにあった。

Xperiaは側面にあるので、その心配はなさそうだった。

決済方法の調査

初めは、メルカリの売上金がそこそこ貯まっていたので、その範囲で買えるものを選ぼうと考えていた。
ただ、思ったより安くないし、中古だと当たり外れがあるので少し怖い。
そんな中、Bitcoinのことを思い出した。ついでに以前から使っていたBitcoinのウォレットを開いてみたところ、スマホを買えるくらいの資産が残っていた。
昔なら売却して銀行に振り込んでいたが、最近は所得税がかかるようになったらしい。すぐに申告が必要になるような金額を使うつもりはないが、銀行口座に何か言われそうな痕跡は残したくない。
調べてみると、ビックカメラではBitcoin決済ができるらしい。面白そうだし、この機会に利用してみることにした。
ただし、ビックカメラではbitFlyer経由の決済しか対応していないらしく、bitFlyerのアプリをインストールし、ウォレットにあるBitcoinのうち、使う分だけbitFlyerに移す必要があった。
Bitcoin決済をするためには、店側にも専用の端末が必要らしく、それを持ってきてもらうのに少し待った。
bitFlyerアプリにはビックカメラ決済の専用メニューがあったが、少し分かりにくい場所に隠れていて、決済時に苦労した。それ以外の操作には特に問題はなかった。

Xperia 10 VIIの簡単な感想

5年半ぶりの買い替えだからかもしれないが、全体的に問題なく使えている。特に写真、パフォーマンス、容量には満足している。
最初に電源を入れると、いくつかアプリがプリインストールされていたので削除した。TikTokなどは使わないので、最初から入っていてほしくない。
レビューにも書かれていたが、長時間使っていると発熱が少し気になる。

その他

ケースはAmazonで購入。

以前から気になっていた磁石付きのタイプにしたので、何となく購入したまま放置していたカード入れを使えるようになったのが嬉しい。

2026年6月25日木曜日

AWS summit 2026

申し込み

5/21に社内のSlackから以下の連絡があって、「あ、今年もやるんだな」と思い、申し込みをした。

定員がいっぱいとなっておりましたExecutive Forumに関して、追加で200名分のご登録が解放となりました。
ご参加をご検討いただいていたエグゼクティブの方は、ぜひお早めに下記コードを用いてご登録ください。（おそらく今後は枠の拡大はないかと思います。）

Executive Forumが何なのか、あまりよくわからなかったが、なんとなく「一般参加よりは良いだろう」と思い、招待コードで申し込みをした。招待コードで申し込んだものの、一般参加との違いをあまり意識していなかった。

準備

前もって会社からWi-Fiルーターを借りた。昨年は電波が干渉していたのか、Wi-Fi認識が悪かったので。
USBケーブルを持参した。行く途中でテストしてみたが、そもそもUSB 2.0でないと認識しないし、それもできるときとできないときがあった。スピードもイマイチだったが、ないよりはマシだった。
今年からは専用アプリでチェックインするようになっていた。直前に慌ててログインする手間がなくなったのは良かったものの、AIに聞いても答えられないことが何回かあったり、キーノートしかライブ配信に対応していないなど、イマイチな点もあった。

当日

昨年も雨だったので、「いつもなぜこの時期にやっているのか」「そもそもなぜこんなに遠い幕張でやるのか」と考えながら移動した。幸い、思ったより雨は降っていなかった。

最近は寝不足気味でよく眠れず、移動しながらリリース作業をしていた。

開会まで15分ほどあり、歩いていけば十分間に合う想定だったが、しばらく歩いていたらすごい行列ができていた。結局、会場に入るまでちょうど1時間かかった。

やることもなかったので、無料漫画でお気に入りに入れていた「龍と苺」を読んでいたら面白くて、待ちながらずっと読んでいた。

その際、入口近くでスタッフが「Executive Forum参加の方はこちらへ」と呼びかける声が聞こえていたが、自分には関係ないと思い、一般の列に並んで入場した。

受付

受付では事前にインストールしたアプリからチェックインしようとしたが、なぜか「チェックインできない」と表示された。スタッフも最初につけていたストラップを外して違う色に変えたりと、慌ただしい様子だった。当時はなぜそうなっているのかわからなかったが、後から何となく理由がわかった気がした。

もらったもの

ストラップとイヤフォン、ギフト券をもらった。ギフト券には「帰る際にお土産を配布する」と書かれていた。ストラップはプラスチック製のICカード型に変わっており、出入りやブースでの認証が少し楽になった感じだった。

今回の目的のひとつであるクッションとシールをもらいに行ったが、クッションはすでに終わっている様子だった。前回もらったものがあるし、今回は諦めることにした。シールは昨年途中で品切れになったものもあったので長蛇の列ができていたが、とりあえず並んでゲットした。

この時点ですでに12時を過ぎていた。

お弁当をもらいに行こうとしたが、よく見るとお弁当のチケットをもらっていなかった。諦めて外で食べようと出たが、せっかくなのでお土産のことが気になり、案内された場所へ行ってみた。

行ってみると、空港のラウンジのような場所で、黒いスーツの人が警備をしており、誰も入れない雰囲気だった。しかし、なぜか私は入場OKだった。

中にお土産を配る係がいたので事情を聞いてみると、私がつけている灰色のストラップがExecutive Forum参加者の証明となっており、入れるエリアだったらしい。つまり、入口でスタッフに呼びかけられていたのは、まさに自分のことだったのだ。

ちょうど近くでお弁当も配っており、一般の方が食べているものとは段違いのお弁当が提供されていた。何より良かったのは、電源とWi-Fiが整った広々とした空間で仕事もできることだった。

参加したセッション

実践！Amazon RDS と Amazon Aurora のコスト最適化とパフォーマンス向上 [DAT318]

ラウンジが閉まるタイミングと重なり、慌ただしく移動したが、すでに満席で間に合わなかった。仕方なく、周辺にいたAWS担当者と色々と話をしていた。会社ではあまり話せる人が少ないこともあり、こうして話すのも久しぶりで楽しかった。

AWS DevOps Agent による自律的インシデント対応 ―その能力を引き出す設計のベストプラクティス― [CNS319]

こちらはしっかり時間を確認して座って視聴した。

障害対応を楽にできないか、という観点から「調査はAI、判断は人が行う」という発想が印象的だった。GitHubのコードも参照できるらしく、Kiro用の仕様書も作成してくれるとのこと。ぜひ試してみたいと思った。

Agent Spaceという単位で調査が可能
複数のAWSアカウントを含めることができる

後半

その後はラウンジに戻り、MTGや仕事をこなしていた。おそらく半分以上は仕事をしていた。

時間になったので、最後の懇親会の雰囲気だけ見ようと思って入ってみた。みんなが話に盛り上がっているなか、お酒と少し高級な軽食もあったのでつまんでいると、前の職場の知り合いに会った。想定外の再会で話が盛り上がり、そのまま帰ることにした。

企業ブースはほとんど見ていなかったが、前から気になっていたので、ついでにStripeのブースだけ寄ってから帰った。もらったお土産は高級そうなお菓子だった。

感想

とにかくExecutive Forumのラウンジが良かった。来年もぜひ参加したい。
クッションはもらえなかったし、セッションもほとんど見られなかった。できれば2日目も参加したいが、仕事と体力がついていけない。

2026年6月7日日曜日

歯の健康フェなど

妻の調子があまり良くなさそうだったので、この前東京へ行った時にもらっていたコナンのスタンプラリーの続きをしに、小田原へ行こうとしていた。

当日になって子どもに「小田原へ行こう」と声をかけたら、行きたくないらしい。

困っていたところ、妻から町の広報に「歯の健康フェス」と書かれていたことを教えてもらい、連れて行くことにした。

https://www.town.ninomiya.kanagawa.jp/0000003434.html

単純に口の検査をして終わりかと思ったら、最初にいろいろなチラシや野菜の引換券などを渡され、スタンプラリー形式で回ることになっていた。

意外と子どもが、ちょっとした遊びのような感覚で参加できて楽しんでいた。虫歯治療のときに歯を削ったあと型を取る、ピンク色のパテみたいなもの？で指の型も取ってくれて、石膏で作ってくれた。

別の部屋ではスタンプラリーの続きもやっていて、移動した。クイズもあったが、とりあえず参加賞のおもちゃをもらえる感じで、選ぶのにずいぶん時間がかかっていた。

なんとなく空いていそうなところへ行ったら、終わってもいないのにスタンプラリーの紙を回収され、プレゼントと交換してくれた。何が起きたのかよく分からず少し戸惑ったが、とりあえず野菜コーナーで引換券を交換したり、磁石の釣りをしたりして楽しんでいた。

帰ろうとしたら、小ぶりではあるが雨が降っていた。どのみち遠出は難しそうな感じだったかもしれない。

昼は前回に続いてマックで食べた。残念ながら、ハッピーセットのちいかわマスコットはまた被りだった。

夕方になって、何かやることはないか考えたところ、実写ではあるが『マインクラフト』の映画を見ないか聞いてみた。

自分としてはあまり好みではないが、昨年かなり話題になっていたし、少し気になっていた。本来は無料で見られるまで待つつもりだったが、いつになるか分からないし、ちょうど楽しんでいる時期に見た方がいい気もした。

トレーラー映像を見せたら結構興味を持っていたので、レンタルしようと思ったが、視聴期限が二日しかない。妻から「買った方が良いのでは？」と言われ、ちょうどポイントもあったので購入することにした。

たまにストーリーが大人向けなところもあったが、マインクラフト好きな人なら楽しめる感じだった。

2026年5月24日日曜日

最後のガンダム見学など

お台場のガンダムが今年8月になくなるというニュース記事を見た。
ユニコーンガンダムはそこまで好きではないが、

記事と同じタイミングで上がってきた、以下の動画を見たら、

少年とガンダム

子どもには、なくなる前に一回ぐらいは見せたい気分になった。

多分、それだけだとついて来ないと思ったので、名目としては「グリーン車に乗る」「ゆりかもめに乗る」ことで説得した。
ゆりかもめはフジテレビのバラエティ番組で見ていたので、ちょうどよかったかもしれない。

最近はあまり電車に乗ろうとしなくなったが、グリーン車は喜んでいる。こちらはお金が掛かるけど、来年になると小学生料金になるので、今のうちに電車に乗るのも良いかも。

新橋駅でゆりかもめに乗り換えた。
ユニコーンガンダムは11時にイベントがあるので、それに合わせて行く感じだった。
日曜日だからか、人はまあまあいる感じ。前の車両に乗るために一本見送り、次の電車に乗った。
予想通り、喜んでいた。

台場駅で降りて、ダイバーシティまで歩いた。隣にフジテレビが見えたので、「行きたいー」と言っていたが、なんとか説得して間に合わせた。
ガンダムはちょうど何かお祭りなのか、周辺にフードトラックと人が多くて、少し行きたくない感じだった。なんとか変形イベントを見せて、写真も撮れた。

また、前から気になっていた「うんちミュージアム」に行ってみた。
いつも通りネットで予約しようとしていたが、時間指定になっていて、普通に並んでチケットを買った方が早そうだった。

ミュージアムというより、ちょっとした遊び場と写真スポットという感じだった。
子どもは楽しんでいたし、私も今まで気になっていたので、まあまあよかったと思った。

ただし、週末は混んでいるので、また行くとしたら平日で空いている時が良さそう。

その後、フジテレビに行こうとしたら、台場駅で見たゆりかもめのガチャガチャをやりたいと言い始めた。
ただ、一回買って忘れるものを買うよりは、ちゃんとしたものを買ってあげたい。
調べてみたら、テレコムセンターの展望台にゆりかもめのお土産店があるらしい。
2駅ぐらい離れていたが、私もテレコムセンターには入ったことがなかったし、行ってみることにした。

テレコムセンターの中は典型的なオフィスビルという感じで、週末だからか、人の気配がなかった。
展望台の前に小さな売店があって、展望台の切符売り場？で「これをくださいー」と言ったら買える感じだった。
ゆりかもめの貯金箱を買ってあげた。

せっかくなので、展望台にも入ってみた。
特に何もなかったが、人もいないし、周辺がよく見えて、意外と良い感じの場所だった。
もし今度来ることがあったら、お弁当でも買ってきて良いかも。

新橋に戻ってマックを食べた。せっかくなので、東京メトロの銀座線の駅に行って、電車も見学した。

帰りは東京駅で電車を見て、帰宅。

2026年5月10日日曜日

HG 1/144 リゼル（ディフェンサーｂユニット）

購入した経緯

前からメタス系の変形MSが少し気になっていたところ、ちょうど送料無料クーポンがあったので何となく購入した。
プレミアムバンダイで2023/11/30購入。2024年4月発送分。2,860円。

模型について

リゼル本体だけならそれほど大きくないが、ディフェンサーを装着するとかなり大きくなる。
立ちポーズは何とか取れるが、変形するとバランスが悪くなり、前に倒れてしまうことがあった。
意外にも股下の突起部分が持ち手として活躍した。これはかなり使いやすかった。

今回やったこと

公式写真ではセンサー部が赤になっているが、ノーマルのリゼルは緑になっている。本来であれば色を揃えるべきなのかもしれないが、個人的には四角いセンサーと丸いセンサーでは役割が違うのではないかと思ったため、少し手間ではあったものの、赤と緑で塗り分けた。
ベースカラーは青緑を使用。意外と気に入ったので、今後ほかの模型でも使うかもしれない。
元々白い部分があり、一部は白パーツで色分けされているものの、多くはシールでの再現となっていた。また、個人的に「ここも白でいいのでは」と思う箇所もあったため、大部分を塗装で色分けした。
全体的に暗めの配色だったので、余っていた白いデカールを多く使うことができた。
変形後、試しにジェガンを乗せてみたところ、意外と違和感なく乗せることができた。

反省点

白の色分け塗装自体は良かったが、角になる部分が多く、擦れると簡単に塗装が剥がれてしまった。後から気付き、数か所は再塗装することになった。
背中のブースターの白い部分が少し物足りなく感じたため、周囲を赤で塗装した。しかし、完成後に見返してみると、余計だったような気もする。
今回も頭部にLEDを仕込もうとしたが、バイザー内部が予想以上に透けて見えてしまうため、断念した。
できれば変形したZガンダムと並べて比較してみたかったが、かなり前に製作したものなので、今さら触るのが少し怖い。ウェイブライダー形態用として、もう一体作るべきかもしれない。

2026年5月8日金曜日

AWS Certified AI Practitioner合格

## 背景
会社の福利厚生で年2万円分、書籍または資格費用を請求できるが、
最近は資格費用を部署でも請求できるようになったため、微妙な金額が余ってしまった。

すでに前回SAPに合格していたので、AWSの試験はしばらく休もうかとも思ったが、
安めのAWS受験費とCloud Licenseの課金でちょうど使い切れそう。
しかも有休も余っていたので、受験に行くのに何も問題はなかった。

問題は勉強する時間があまりないことだったが、自分のお金でもないし、
ちょうどAI試験も気になっていたので受験してみることにした。
Practitionerだし、運が良ければなんとかなるのではないか、というノリ。

## 勉強した書籍・サービス
上記の通り請求できる範囲も決まっているし、時間もなかったので、Cloud Licenseのみで勉強した。
時間がなかったため、掲載されていた問題のうち2/3ぐらいしか見られなかった。もちろん、いつもやっている見直しもなし。

一応、試験に落ちた場合に勉強をし直すため、Amazonの欲しいものリストに関連書籍を入れていたが、今は削除済み。

## 受験日
前回のSAPとは異なり試験時間も短めだったので、特にトイレ対策はしていなかった。
むしろ、途中で我慢できなくなったら棄権することも考慮していた。

問題はCloud Licenseのものも出ていた気がするが、それよりも問題を解いて仕組みを理解したことが大きかった気もする。

## 結果
21:44にバッジの連絡が来たが、20分ぐらい前にAWSに反映されていた。ギリギリな感じではあったが、合格。