Life

私は悩んでいます。 自称プラットフォームエンジニアとして、AI エージェント時代の Platform Engineering にどう向き合えばよいのか。 普段はプラットフォームを構築する仕事をしています。 自社にプラットフォームを作るでもなく、自社のプラットフォームを提供するでもなく、クライアント組織の課題を解決できるように、開発者が使いやすいように、あるプロダクトを中心としたプラットフォームの導入です。 「自称プラットフォームエンジニア」というのは、別にそんな正式な肩書やロールを持っているわけではないからです。 やっていることと気持ちが一番マッチしているのがこれなので自称してます。 所謂クライアントワークですが、関わっているプラットフォームにも愛着があるし、開発者の負担にならずクライアント組織の課題を解決するプラットフォームにしたいという気持ちで取り組んでいます。 その気持ちに応えるかのように、その環境では Platform Engineering の考えを取り入れています。 逆かもしれません。 Platform Engineering があるから開発者の負担にも意識が向くようになった可能性はあります。 プラットフォームの課題を見つけては解決に勤しむ日々の私にとって、Platform Engineering は仕事を進めるうえでの心の拠り所的なものにもなりつつあります。 そんな中、世間では AI エージェントの話題が絶えず、プラットフォームエンジニアという自分の働き方にも AI エージェントが身近になってきました。 いまではプラットフォーム構築に AI エージェントは手放せないくらいです。 ということは、プラットフォームを利用する開発者も AI エージェントを使って開発しているはずで、プラットフォームの使われ方が変わるのでは？今までの Platform Engineering の認識をアップデートしないといけないのでは？という不安に襲われます。 自分がどう AI エージェントを使いこなせるかは気にしつつ、その先のプラットフォームを利用する開発者も AI エージェントを使いこなす未来まで意識が向いてません。 このままでは「AI エージェント時代だから Platform Engineering やーめた」となると、じゃあ自分はどう生きれば……という状態に陥ってしまいます。 ここまで依存すると手段が目的化しつつあるのを否めませんが。 そんな AI エージェント時代において、プラットフォームエンジニアな自分は今何にどう向き合えばよいのか漠然と悩み、予測もできない未来に不安を感じています。 AI エージェント時代にこのままの Platform Engineering でいいのか。 Platform Engineering は無くなってしまわないのか。 この悩みについて AI と壁打ちしながら考察して自分なりの結論を出したので、内容と気持ちの整理のためにブログにしました。 Platform Engineering の本質 まずは心の拠り所にしている Platform Engineering について、自分がどう考えているかというところから。 オライリーのプラットフォームエンジニアリング本によると、Platform Engineering とは「プラットフォームを開発・運用する技術分野」であり、「システム全体の複雑さを管理してビジネスのレバレッジを実現すること」が目標とあります。 ここでいうレバレッジは、少数のプラットフォームエンジニアで組織全体の業務を削減できるという考え方です。 ...

私のブログでは、自分で文章を書いたオーガニックな記事をお届けしていきます。 なにを急にこんな宣言しているんだろうという感じですが、これは私なりの決意表明であり、少なくともこの記事を書いている時点では「自分の考えは自分の言葉で書きたい」という気持ちなので、それを残しておくためです。 「オーガニック」という表現は X で見かけたので拝借しました。 生成 AI を使わずに自分の言葉だけの記事という意味です。 生成 AI の利用が一般的になってからというもの、ブログ投稿を含めたアウトプットが格段にやりやすくなりましたね。 かくいう私も所属企業の技術ブログを書くとき（最近はあまり書いてないけど）には生成 AI に文章をまかせたりサポートしてもらったりしており、シンギュラリティの恩恵にあずかっている身です。 VS Code で記事を書いているとサジェスト機能でそれっぽい文章が出てきて、Tab キーを押すだけで行が埋まります。 意図と違う文章であれば当然サジェストは却下して書き直しますが、出てきた文章の方向性が近かったら Tab キーを押して文章を補完してしまいます。 しかし、このサジェストされた文章が自分の考えと完全に一致しているかというと、そうではない場合が多いです。 文章を補完することで自分の考えを生成 AI のそれっぽい文章によって軌道修正してしまっている感が否めません。 でも便利なので使っちゃっていました。 それは企業の技術ブログだけでなく、この個人ブログの記事においても。 一度、技術ネタの記事を書くときに公式ドキュメントや検証した結果を元に生成 AI に丸投げしてみました。 過去の自分の記事から文体も寄せてもらいつつ、出来上がったものに不備がないかチェックして投稿しました。 結果、なんの思いも乗ってない記事になりました。 自分はいわゆる「やってみた」系の記事を書くことが多いです。 技術的に興味があることを発信してだれかの参考になれば、興味を持ってもらえればという気持ちだけでなく、自分の考えを発信することへの抵抗感から来ているとも思います。 企業技術ブログは広報的な観点でも使われているので、個人の思いとか別に関係ないかもしれません。 「認知を増やせ、バズらせろ」。 極端な表現ですが、工数というコストを掛けているのでこういったリターンを求められるのも理解できます。 やってみた系の記事では事実を書くことがメインなので、気持ち的に書きやすいですし、企業技術ブログとも利害関係がマッチしてそうで、生成 AI を使ってコストを抑えて記事を書くのも一見良さげに思えます。 そうだとしても、その事実をどう表現するかはその人の個性や考え、文章力によって大きく変わりますし、それがアウトプットすることの醍醐味なんだということを最近実感してきました。 たとえやってみた系の記事でも、自分の言葉で書くことが大事だと考えてます。 それはアウトプットを通して、その人となりを見る、という感じですかね。 とは言いつつも、もはやその人の文章なのか生成 AI の文章なのかは私には読み解けません。 分かるのは自分のアウトプットが自分の文章なのかそうでないか、思いが乗ってるか乗ってないか。 だからこそ、個人のブログでは生成 AI を使った文章ではなく、自分の考えを自分の言葉で書いて、私の人となりが分かるようなブログにしていきたいと思いました。 別に生成 AI で書いた記事を批判しているわけではありません。 自分のブログなんだから自分の言葉で紡ぎたい。 ただそれだけです。 冒頭で「オーガニック」という表現をしていますが、どこまで生成 AI に頼らなければオーガニックと言えるんでしょう。 人によって解釈が違いそうなところですが、私としては誤字脱字のチェックに生成 AI を使うのはまだオーガニックな領域だと思っています。 サジェストは違うなぁと思って VS Code のサジェスト機能はオフにしました。 いまやターミナル (cmux) がメインで VS Code はブログ記事を書く専用ですし、サジェスト機能をオフにしても支障はありません。 ...

2026 年 1 月 31 日に開催された SRE Kaigi 2026 に参加してきました。 SRE 関連のカンファレンス参加は初めてだったので、学んだことや感じたことを忘れないうちに記録しておきます。 SRE Kaigi 2026 SRE Kaigi 2026は「Challenge SRE!」をテーマに開催されるSREに関するカンファレンスです！ 2026.srekaigi.net はじめに どうして参加したのか SRE のプラクティスを学び、日頃の Platform Engineering に活かしたいと思ったのが今回の参加理由です。 現在は Platform Engineering の活動をメインでやっていて、カンファレンスのテーマである SRE という分野ではありません。 とはいえ、SRE Kaigi でも「Embedded SRE」と「Platform Engineer」というチーム構成を紹介されているセッションもあったように、SRE と Platform Engineering は密接に関わる領域だと考えています。 あと、裏の理由としては「現地イベントに参加したい！」というのがあります。 地方在住なので現地イベントに参加する機会が少なく、定期的に現地イベントに参加して熱量を持って帰ることが必要なのです。 さらに裏の裏の理由として、杉田智和さんのナレーションを聞いてみたかったというのもあります。 セッションの選び方 どのセッションを見るかはとても悩みましたが、その中でも今回は「開発チームとの関わり方」に関するセッションを中心に選びました。 SRE チームの目的である「システムの信頼性をあげたい、そのプラクティスを開発チームに Enabling したい」を実現するために、どのように開発チームと関わっているのかという点に興味があったからです。 Platform Engineering の活動をやる中でも「開発チームの生産性を上げる・認知負荷を下げるプラットフォームを用意して使ってもらう」ことは、ただ技術的に優れているプラットフォームを構築するだけでは達成できない、開発チームに寄り添うこと・協業することが大切です（最近痛感してきた）。 言わば「他人のやり方を変えることの難しさ」が見えてきている中で、SRE でも同じような課題があってそれにどうアプローチしているのか知ることは Platform Engineering の面でも学びがあるのでは、と考えて選びました。 学んだこと、感じたこと はじめは「学んだこと」と「感じたこと」を分けて書こうと思っていましたが、学んだことを書いていくうちにお気持ち表明的な内容が多くなってきたので 1 つのセクションにまとめちゃいました。 自分が特に学んだことにフォーカスして簡単にまとめます。 SRE チームと開発チームの分断 ワンキャリア 渡邉 美希パウラさんによる「SRE とプロダクトエンジニアは何故分断されてしまうのか」というセッションでは、SRE チームと開発チームの分断がなぜ起こるのか、その構造的要因と解決アプローチについて紹介されていました。 ...

最近、プライベートだけでなく仕事でも Mac を使い始め、ランチャーとして Raycast を導入したら Raycast はいいぞおじさんになってきました。 今回はそんな Raycast の拡張機能を活用した “Working Out Loud” について紹介します。 Working Out Loud と分報 Working Out Loud に出会う Working Out Loud という考え方はご存知ですか？ Working Out Loud で調べると辿り着くのが以下の記事かと思います。 Working Out Loud 大声作業（しなさい）、チームメンバー同士でのトレーニング文化の醸成 - スタディサプリ Product Team Blog ソフトウェアエンジニアリングと一見関わりはなさそうで、しかしチームで成果を出す過程においてとても重要だと[筆者][ohbarye]が考えているコンセプト、 "Working Out Loud" について書いてみます。 日本語の記事がほとんど見当たらないのであまり知られている言葉ではないかもしれません。 対象読者 以下に興味や関心を持つ方を対象読者として想定しています。 チーム開発におけるコラボレーション手法 チーム開発者としての振る舞い方 テックリードやスペシャリストの育成 が、本心ではチーム開発する全ての方に届いてほしいです。 blog.studysapuri.jp こちらの記事の言葉を引用すると、Working Out Loud とは以下のような働き方です。 作業が途中であってもチームメンバーの目の触れる場所にガンガンアウトプットする 作業で詰まったらとにかく尋ねる 今回紹介するのは前者の「チームメンバーの目の触れる場所にガンガンアウトプットする」にフォーカスした取り組みです。 私が Working Out Loud という考え方に出会ったのは社内の LT 大会です。 その LT は Working Out Loud を実践することで業務を効率よく進められた、という内容だったかと思います。 漠然と「こうした方が良さそうだなぁ」と思っていたことに名前がついていることを知れて、記憶に残っている LT でした。 ...

ふと思い立って、2024 年の 1 年間にどれくらい四国の Azure 導入事例などが出ているか調べてみた。 調べたと言っても Google で「2024/01/01-2024/12/31」の期間で検索しただけなので漏れがあるかもしれない。 事例の詳しい内容はリンク先の記事を見てもらいたい。 今治造船株式会社（愛媛県） 愛媛が誇る造船会社「今治造船（いまぞう）」の Azure 導入事例。 2024年3月14日に公開された。 オンプレミスの基幹系システムを Azure に移行、オーバースペック回避で TCO を大幅に削減し、バックアップ/バッチ処理時間の短縮も実現 | Microsoft Customer Stories グループ全体で 10 か所の建造拠点を保有し、新造船建造量が国内トップとなっている今治造船株式会社。ここではオンプレミスの仮想化基盤上で運用されてきた基幹系システムが、Microsoft Azure ネイティブの IaaS へと「リフト」されています。これにより、オンプレミス システムにありがちな「オーバースペック」を回避し、TCO を大幅に削減。データ バックアップやバッチの処理時間短縮も実現しています。またこの移行にあたっては、Azure Migrate による必要リソースのアセスメントや、Azure Migrate ＆ Modernize による各種支援、Azure への移行でさらに 3 年間無償でセキュリティ更新プログラムを受けられる Windows Server 2012 の拡張セキュリティ更新プログラムなども活用。FastTrack for Azure もプロジェクトに参画し、テスト フェーズで発生した問題のスピーディな解決などで、大きな貢献を果たしています。 www.microsoft.com 事例記事によると、VMware で構築されたオンプレの基盤を Azure にリフトして IaaS を使っているらしい。 ぜひ苦労話をコミュニティでお話ししてもらいたいものだ。 なお、今治造船には「いまぞう君」というゆるキャラが存在する。 株式会社 石垣（香川県） 「株式会社 石垣」は香川県坂出市に工場や開発センターを持つ水インフラ関連の企業（本社は東京）。 2024年5月17日に Azure Machine Learning の導入事例が公開された。 環境機器の IoT データ プラットフォーム「miyoru」、Azure ML による予測モデルの実装で新たなフェーズへ | Microsoft Customer Stories IoT で収集したデータの可視化や分析をサービスとして提供する「ISHIGAKI Cyber Platform “miyoru”」を Microsoft Azure 上で実現し、2022 年 8 月にリリースした株式会社 石垣。現在はこの miyoru に AI 機能を搭載する取り組みが進められています。その AI エンジンとして採用されているのが、Microsoft Azure Machine Learning です。既に Azure 上で構築されていた IoT 基盤と、AI エンジンをダイレクトに連携させることで、学習のためのデータ パイプラインを完全に自動化。これによってスピーディかつ人手に頼らない学習を可能にしたのです。2023 年 8 月には、AI を搭載した miyoru のコンセプト展示も実施。今後は Microsoft Azure OpenAI Service とも連携させ、プラットフォームとしての強みをさらに強化していく計画です。 www.microsoft.com パートナーは株式会社ナレッジコミュニケーションズ。 同社会社情報によると、いくつかの「Specialization」や「Microsoft Mixed Reality パートナー プログラム認定パートナー」を取得されており、かつ「Microsoft Japan Partner of the Year 2023 (AI Partner Award)」を受賞されているらしい。 ...

2024 年の振り返りと 2025 年の抱負を掲げます。 今回の振り返りの項目はこちらの記事を参考にしました。 「2024年の振り返り」と「2025年の抱負」 - Security Akademeia【セキュリティアカデメイア】 目標は達成できませんでしたが、少しは減少できたので、前向きに捉えています。 健康診断の結果も、現在のところ問題 akademeia.info ちなみに 2024 年の初詣で引いたおみくじはこんな感じでした。 今年はがんばり pic.twitter.com/NX0WTS21pH — ののし (@nnstt1) January 2, 2024 ２０２４ 年の目標を達成できたか 2024 年の目標は 2 つでした。 Azure 資格全冠 コミュニティ活動に取り組む Azure 資格全冠 ⇒ 未達成 2023 年末の時点では Azure の資格を 9 個所得していて全冠まで折り返し地点でしたが、残念ながら 2024 年は Azure の資格試験を 1 つも受けることなく終わってしまいました。 それどころか、数日前に取得済みの AZ-204 の更新を怠って失効してしまい、全冠が遠のいてしまいました。 コミュニティ活動に取り組む ⇒ 達成 2024 年はコミュニティの勉強会などで 6 回登壇する機会がありました。 特筆すべき点としては「初めてオフライン登壇した」ことです。 オンラインでの登壇はコロナ禍前からやっていましたが、コロナ禍が明けてやっと現地参加できるようになってオフラインでの登壇が叶いました。 一方、2023 年末はこんなことも書いていました。 より登壇回数を増やしたり、運営サイドの行動ができたらと。 できれば近場の方々と Azure などの勉強会などを開けるようになにかした行動を起こしたいです。 コミュニティの運営寄りの活動としては、HashiTalks: Japan で MC をやったことや、四国の Azure コミュニティ「しこあず」を立ち上げたことが 2024 年の成果かと思います。 ...

HashiConf 2024 に現地参加するため海外出張という形でボストンに行ってきました。 日程は 2024/10/12(土)〜18(金) の一週間。 HashiConf 参加レポートは会社のブログに投稿したので、ここでは HashiConf 以外の部分をメインに、初の海外遠征の内容を記録します。 X.com にも #nnstt1_hashiconf というタグで投稿してます。 持ち物 まずはボストンに持っていった持ち物。 機内持ち込み手荷物は普段使っている無印の肩の負担を軽くするリュックサック、預け入れ手荷物は10数年前に買ったスーツケース（容量不明）。 リュックサックには長時間フライトを快適に過ごすためのグッズを入れた。 今回を機に用意したものもチラホラ。 用途毎に袋にまとめてリュックへ収納。 パスポートケース パスポートや現金（日本円、米ドル）のほか、フライトやホテルの予約のコピーを入れてた。 ホテルの部屋にいるとき以外は肌身離さず持ってた。 Anker の紛失防止トラッカーを装着。 水筒 機内でいつでも水分補給できるようにと持っていった。機内だけじゃなくボストン観光やホテル滞在時にも大活躍した。 個人ノートパソコン Macbook Air M3。 HashiConf 中は主に会社のぶログを書くのと SNS 用に使っていた。 今回の遠征のために買い替えたと言っても過言ではない。 業務用ノートパソコン 仕事せざるを得ない状況だったので持っていった。 業務用スマホ 同上。 Kindle Paperwhite 機内の映像コンテンツに飽きたときのために、と持っていったけど全く使わなかった。 名刺入れ 念の為に名刺を持っていったけどほとんど使わなかった。 プレーリーカードも忍ばせてて、無理やり読み取ってもらったことも。 技術書典の袋（画像左上） 機内持ち込みの液体、薬、お菓子、マスク、蒸気マスクといった機内で使うケア用品を収納。 ガジェットポーチ（画像左下） モバイルバッテリー もともと持っていた 20,100mh のやつ。 買い替えようかと考えていたけど、Macbook Air のバッテリー持ちを信じてそのままに。 イベント会場と宿泊先が同じホテルだったこともあり、結果的にこのモバイルバッテリーで十分だった。 AC アダプタ Anker Nano II 45W 一つだけ。 これだけでスマホも Macbook Air も業務用ノートパソコンも充電できる優れモノ。 自撮り棒 自撮りには使わなかったけど、知人の登壇風景を録画するときに一脚として使えて便利だった。 ELECOM の Bluetoothオーディオトランスミッター/レシーバー LBT-ATR01BK と φ3.5mm プラグ延長ケーブル。 自撮り棒の左隣のやつ。 機内のオーディオが Bluetooth に対応してなかったときに備えて、手持ちのワイヤレスイヤホンで機内映画の音声を聞けるようにするためのもの。遠征直前に購入したものの往復の便で大活躍した。 Microsoft Copilot ロゴのついた白いもの マルチ端子ケーブル(?)とかいう USB Type-A を USB Type-C、Micro USB、Lightning と繋げられるもの。9月の Microsoft イベントでノベルティとしてもらった。念の為持って行ったけど使わなかった。 ベージュのポーチ 無印の吊るして使える着脱ポーチ付ケース。衛生用品などを入れていて常に持ち歩いてた。 機内快適グッズ（画像右） 長時間フライトを快適に過ごすためのグッズをネットに入れてまとめて持ち運んだ。 フライトソックス 今回はじめて使ってみたけど効果あった、と思う……。このソックスはふくらはぎまで履くんだけど、ボストンついたときにはくるぶしまでずり下がっていたので怪しいが、帰りはちゃんと装着できていてむくみも無かった。 ヨックション（フライトソックス右のやつ） お尻を守ってくれるクッション。 お尻だけでなく腰も守ってくれた、神アイテム。 普段使いもできそう。 ネックピロー ポンプがついてて手で空気を入れられるタイプのやつ。 ユニクロのウルトラライトダウン ド定番のやつ、だけど今回はじめて買った。 機内の寒さ対策でもって行ったけど、ボストンは日本より 10℃ ほど気温が低くて結構着てた。 アイマスク アマゾンで買ったシルク 100% のやつ 今までアイマスク使ったことなかったけど周りの明るさを遮って寝られるのはよかった。 耳栓 ノイキャンイヤホンのバッテリーがなくなったときに使った。 スマホスタンド iFLEX ってメーカーのシリコン製スタンド。座席モニターの隙間に差し込んで使うやつ。 スマホを目線の高さに置いて動画見れると思って買ってみたけど、飛行機の揺れがダイレクトにスマホに伝わってほとんど使わなかった。 使い捨てスリッパ 機内では靴を脱いで過ごしたかったので、ビジネスホテルのアメニティだったスリッパを持参。 ホテルの部屋でも使ってた。 微妙にサイズが合わなかったので事前に確認しておくべきだった。 預け入れ手荷物も写真撮って記録しているけど下着が写ってるので割愛。 ...

今年は2度目の転職をするなど人生の転機にもなった年でした。 そんな 2023 年の振り返りと 2024 年の抱負を掲げてみます。 2022 年振り返りと 2023 年の抱負 今年の年末は大きな仕事があって丸一日休みという日がなく慌ただしい日々です。 とはいえ、スポットで対応する感じでスキマ時間があるので、昨年掲げた抱負を確認しつつ1年を振り返ります。 昨年は ↓ の抱負を掲げていたようです。 家族との時間を大切にする 転職の目処をつける 2022 年の振り返り 育休取得 今年の4月に双子（第2、3子）が生まれました。 長男出生時は特別休暇をもらったので、その日数（3日？5日？既に覚えてない）休んだだけでした。 その休み中は書類関係の手続きしたり、退院準備をしたり、と育児以外のミッションをしていたらあっという間に休みが終わりました。 次の子も同じ感じになるかなぁと朧気ながら思っていましたが、昨年に双子妊娠がわかって、更には妻が早期に入院する可能性が出てきた（結果的にそうなった）ため、育休を取ることにしました。 結果的には 3～4 月に長男分、5～7 月に次男三男の育休を取得して、計5ヶ月お休みしました。 5ヶ月は職場への負担が大きいかと思ったのですが、現職では男性の育休がボチボチ出てきたところだったので、相談はしやすかったです。 そういうことで、今年1年の約半分は家族メインの生活ができたので「家族との時間を大切にする」という抱負は達成できました。 育休中の振り返りは Note に投稿しました。 育休が終わったので振り返ってみた 転職活動 昨年から転職活動をしていましたが、子供が生まれることもあって中断していました。 まだ具体的な内容は言及できませんが「転職の目処をつける」という抱負は達成できたと思います。 アウトプット 今年は本ブログに 17 本投稿しました。 ラズパイ Ceph を Zabbix で監視する Cephadm のアラートを消す PG の修復 Ceph ホストのメンテナンス Red Hat Developer Subscription の有効期限が切れたので再登録した AMD CPU 使っていて RHEL 9 にアップグレードできなかった話 Fedora ラズパイの PoE+ HAT ファンをコントロールする 仮想化基盤の Proxmox VE への移行 Proxmox VE を管理するため Terraform に入門した Terraform で Proxmox VE の VM パラメータ設定 ansible.cfg を作成する ansible-config init コマンド AWS SAA に合格したので振り返る Rook v1.10 へアップグレード Terraform で AGIC を使おうとしてハマった K8s@home で LT したので振り返る Terraform で AKS と AGW をデプロイする Podman Desktop がリリースされたのでインストールする Google Analytics で年間のアクセス数を見ると、以下のような感じでした。 Proxmox VE の記事が多く見ていただけたようです。 Twitter でも Proxmox のワードを見かける頻度が増えた気がします。 昨年は ↓ の抱負を掲げていました。 ...

この記事は エーピーコミュニケーションズ Advent Calendar 2023 の1日目の投稿です。 今年の 4 月に株式会社エーピーコミュニケーションズ (以降、APC) に入社して半年経ちました。 今はがっつり Azure をやっている感じですが、前職では Azure だけでなく色々なことにチャレンジさせてもらいました。 その中でも一番最初にチャレンジ（通常業務とは別で取り組んだ業務改善）したのは Ansible の導入でした。 そもそも Ansible とはなんぞや？って状態だったので Ansible を実際に触ってみようと、まずは Ansible もくもく会に参加しました。 当時はまだコロナ禍前の世界ということもあり Ansible コミュニティが開催していたもくもく会は数少ないオンライン参加が可能な勉強会で、これが自分にとって初めての技術コミュニティへの接触でした。 それから度々 Ansible コミュニティのイベントに参加していき、その中で某金魚の方を始めとした APC 所属の方をよくお見かけして APC という会社を知りました。 自分の興味が Ansible に加えて Kubernetes や Azure に広がっていった際も APC の名前を見ることが多く、Ansible に限らずアウトプット活動が盛んでとても楽しそうな会社という印象を持っていました。 アドベントカレンダーもその楽しそうな活動一つで、APC のアドカレ（組織のアドカレと言ったほうが正しいかも）に参加することは一種の憧れでもありました。 そんな APC に入社できたのも、自宅で自由に検証ができる環境「自宅ラボ」を導入してスキルアップできたのが大きいです。 というわけで、アドカレの初日にポエムっぽい投稿になってしまいますが「自宅ラボ ジャーニー 2023」と銘打って自分の過去ツイートを引用しながら自宅ラボの遍歴を紹介します。 ちなみに見出しは有名どころのサブタイトルを引用していますが特に意味はないです。 【序章】自宅ラボは出ているか? はじめに自宅ラボを導入するに至った動機ですが、理由は単純で「自由に使える環境が欲しい」と思ったからです。 冒頭で話したとおり、前職で自動化やサーバ管理を推進するために Ansible を触り始めたのですが、検証環境を用意するのもなかなか難しいものがありました。 特にプロキシに阻まれまくった。 最初の頃は Ansible もくもく会で使える環境で十分満足していたのですが、そのうちもっと色々な検証をしたくなって自由に使える プロキシに阻まれない 自宅ラボを導入することにしました。 おそらく自宅ラボを構築している方の多くが同じ動機なんではないでしょうか。 あと、ロマンとか探究心みたいな気持ちも少しはありましたね。 クラウドサービスを利用するのもよかったんですが、インフラの勉強をするにあたってやっぱり物理で触れるものが欲しいという理由でクラウドは除外しました。 とは言っても一部のサービスは自宅ラボと連携する形で利用しています。 そういうわけで自宅ラボを導入することを決意したのですが、この時期に Ansible と並行して OpenShift にも興味を持ち始めていて、まずは OpenShift の導入を目標に自宅ラボを構築していきました（そもそも最初に自宅ラボとして OpenShift を選択することの無謀さをまだ知らなかった）。 ...

はじめに SPY×FAMILY 28 話、最高でしたね。 ヨルさん（CV: はやみん）の「お仕事お疲れさま」というセリフは全勤労者を救ってくれました。 さて、話は変わって今回は個人用 Chrome 拡張機能を作ったのでその備忘録です。 どんな拡張機能かというと、「ブラウザで表示したページの特定のボタンを押したら指定の音声ファイルを再生する」という単純なものです。 この特定のボタンというのは一日に一度しか押すことがなく、「あー今日も仕事がんばったなー、今日はここらへんにしとくかー」ってときに押すボタンです。 拡張機能によって流れるヒーリングサウンドが疲弊しきった心身に染み渡ります。 すんなり作成できるかと思ったのですが、思いの外つまづいてしまいました。 そのまま音声を流せない 現在 Chrome 拡張機能は Manifest v3 がメインバージョンとなっていますが、Chrome 拡張機能を作るためにググってみると v2 の情報が多くヒットします。 音声を再生する方法も v2 では new Audio(url) とするだけで良かったようですが、v3 の情報があまり見つかりませんでした。 見つかった StackOverflow によると offscreen という機能を使うことで Chrome 拡張機能 v3 でも音声再生できるとうことで、試してみたところうまくいきました。 iframe で読み込んだ別ドメインのボタンを指定する 今回 Chrome 拡張機能の対象としているページは画面の一部を iframe で読み込んでいました。 そして押したときに音声を流したい特定のボタンも iframe の読み込み先で描画されていたのですが、この読み込み先が対象ページとは異なるドメインで管理されていました。 所謂クロスドメインです。 クロスドメインの iframe の場合、Chrome 拡張機能の content_scripts でスクリプトを挿入する際に all_frames: true と指定する必要がありました。 また、matches で指定する URL はブラウザでアクセスするものではなく、iframe で読み込む URL を指定することでピンポイントにスクリプトを挿入することができました。 作成した Chrome 拡張機能 というわけで上記の対応をしたものが以下になります。 Javascript は平均以下なので書き方に問題があっても見逃してください。 ...