勇往邁進

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 でした。 ...

全 HCP Vault Dedicated1 ユーザの皆さま、こんにちは。 ついに……ついに来ましたよ……。 HCP Vault Dedicated から Azure のプライベート DNS ゾーンを参照できる日が！！！ 正直どれだけの人が待っていたかは分かりませんが、この興奮をどうしても伝えたくて、今回のアップデートについて書いています。 「HCP Vault Dedicated から Azure のプライベート DNS ゾーンを参照できる」と言っても、具体的に何ができるようになったか？ 簡単に言うと「HashiCorp Vault の目玉機能である動的シークレット (Dynamic Secret) を Azure 環境で使えるようになった」ということです。 その他にも、VSO (Vault Secrets Operator) で Kubernetes 認証が使えるようになるなどの恩恵もあります。 いや、今までも使えたでしょ？という意見もあるかもですが、多くの場合では実質的に使えない状態でした。 それはどういうことで、どうして今回のアップデートでそこまで興奮しているのかを伝えていきます。 Azure サービスにプライベート アクセスしよう まずは Azure のプライベート アクセスについておさらいです。 Azure のほとんどのサービスにはパブリックなアクセスを拒否して、プライベート ネットワーク経由でのアクセスに制限する機能が備わっています。 プライベート ネットワーク経由でサービスにアクセスすることを実現するために、Azure では「プライベート エンドポイント」という仕組みが提供されています。 プライベート エンドポイントを作成すると、同時にプライベート DNS ゾーンが作られて対象リソースの DNS 名がプライベート DNS ゾーンに登録されます。 対象リソースにアクセスする際には、そのプライベート DNS ゾーンを参照することでパブリック アクセスが制限された Azure リソースにプライベート ネットワーク経由でアクセスできるようになります。 もちろん、クライアントはプライベート エンドポイントがある Azure VNet に繋がっている必要があります。 ...

前回に続いて Azure Database for MySQL の貯めてたネタの放出回。 Azure Database for MySQL のレプリケーションラグ Azure Database for MySQL では Azure Portal の “Replication” という画面で読み取りレプリカのレプリケーションラグを確認できる。 あるとき、レプリカを作ってこの画面を見ながらラグが無くなるのを待っていた。 だけど、いつまで経ってもラグの時間が変わらない。 詳しくラグを見るためメトリクスの ”Replication Lag in Seconds" を見ると、こちらはちゃんとラグが減っていた。 なんなら 0 秒になっているタイミングすらある。 なのに “Replication” の画面では相変わらず。 ドキュメントを調べたり、Microsoft Learn MCP Server を入れた Claude さんに聞いたりしてみたけど、理由は分からず。 とはいえ “Replication” 画面のラグは変化することもある。 そこで「一定期間の最大値とか平均値を表示してるのでは？」と思い、“Replication” 画面とメトリクスの “Replication Lag in Seconds” を並べてラグが変化するタイミングを待ってみると、すぐに判明した。 “Replication” 画面に表示されるラグは「過去 1 時間の “Replication Lag in Seconds” の最大値」を表示しているようだった。 検証 個人サブスクリプションの小さい環境で試したので大きなラグは出てないけど、1 時間以内の最大ラグが 1 秒のメトリクスの画面。 ...

久しぶりに Azure の話。 Azure Database for MySQL はインスタンスの SKU によって利用できる vCore 数やメモリサイズが異なる。 SKU は Standard_B1ms や Standard_D2ds_v4 などの名前。 それぞれの SKU に対して、どのような vCore 数やメモリサイズが利用できるか確認したい場面がある。 そんなときに Location Based Capabilities API が便利。 Location Based Capabilities - List - REST API (Azure MySQL) MySQL サービスの詳細 - 特定のサブスクリプション内の指定した場所にある機能を取得します。 learn.microsoft.com Location Based Capabilities API を使う Location Based Capabilities API は Azure CLI からも利用可能。 以下のコマンドで特定のリージョンに対して利用できる SKU の一覧を取得できる。 az mysql flexible-server list-skus --location japaneast このコマンドを実行すると「ゾーン → サービスレベル → バージョン → SKU」の順でネストされた配列が返ってくる。 大量に出てくるので、大幅に省略したものを載せておく。 ...

普段、仕事ではドキュメント管理に Confluence を使っている。 全社的には Google ドキュメントも使っているけど、見た目やドキュメントの検索のしやすさを考えると Confluence のほうが好み。 だけどあまり活用も整理もされてないのが悩み。 GitHub Copilot とかでなんとかできないかなぁと思っていたところ、Atlassian 公式の Confluence と Jira を GitHub Copilot Agent mode や Claude Desktop から扱えるリモート MCP サーバが公開されていることに気づいた。 アトラシアン、リモートMCPサーバーを発表 | Atlassian Japan 公式ブログ | アトラシアン株式会社 www.atlassian.com この発表記事から辿れるページを見てもやり方わからなかった。 そのせいでコメント欄には野良 MCP を使った方法がたくさん投稿される始末。 ドキュメント管理サービスを提供しているならドキュメントから用意してほしいところだけど、リモート MCP サーバの設定方法は他の記事に載っていた。 Atlassian Remote MCP Server beta now available for desktop applications Hi everyone, we’re thrilled by the excitement around the Atlassian Remote MCP Server beta that we launched recently. Many of you shared the feedback that it would be helpful to be able to use the MCP server from your IDEs or other desktop apps. Our team has been hard at work to address this, and to... community.atlassian.com ということで Atlassian 公式の MCP サーバがどんな風に使えるか試してみた。 ...

最近、個人的に Azure Developer CLI (azd) という超便利ツールが熱い。 azd up コマンドでインフラ含めて Azure Functions とかの実行環境をサクッと作れて、書いたコードをすぐに動かせる。 コードもテンプレートがあるのでゼロから書く必要がない。 たぶん azd だけでは自分に刺さらなかった。 Functions で Flex Consumption が使えるようになったり、生成 AI のおかげで自分でもそれっぽいコードを書けたり、色々条件が重なったからこそ今 azd の便利さの片鱗を味わえている。 そんな azd はアプリケーション実行環境の土台となる Azure リソースを Bicep を使ってプロビジョニングする。 そして、まだベータ版だが Terraform も使える。 Terraform を使うということはステート管理の話が出てくる。 当然 azd もステート管理を考慮していて、デフォルトのローカルステート（ローカル環境にステートファイルをそのまま置くやつ）に加えて、リモートステートとして Azure Storage にステートファイルを格納できる。 普段 HCP Terraform を使っている身としては「azd のステートファイルを HCP Terraform に格納できるのか」というのが気になるところ。 結論から言うと今はまだ azd で HCP Terraform にステートファイルを格納できなかった。 今回はそのことについて書く。 確認に使った各ツールのバージョンは次の通り。 azd v1.13.0 terraform v1.11.0 要約 azd で HCP Terraform を使えない理由は以下のとおり。 HCP Terraform は「VCS-driven」と「CLI-driven」という連携方法がある（「API-driven」は割愛） Plan ファイルを保存する azd では「VCS-driven」は使えない ステートロックが無効化されている azd では「CLI-driven」は使えない そもそも azd で Terraform を使うためにはいくつか設定が必要になるが、詳しくは Microsoft の公式ドキュメントを見てもらいたい。 ...

仕事柄、プロジェクトごとに複数アカウントを切り替えて HCP Terraform (旧称 Terraform Cloud) を使っている。 HCP Terraform ではローカル環境などで terraform plan する前に terraform login で Plan を実行するアカウントのトークンを取得しておく必要がある。 しかし、terraform login で取得したトークンは 1 アカウント分しか保存されないので、アカウント切り替え時に都度トークンを取得する手間が発生する。 そこで、HCP Terraform のアカウントを使い分ける方法を紹介する。 要約 環境変数 TF_CLI_CONFIG_FILE を使用して CLI 設定ファイルを切り替え プロジェクトごとに .terraformrc ファイルを用意 direnv で自動的に環境変数を切り替え オプションとして ghq + peco と組み合わせて効率化 HCP Terraform のトークン Terraform ではコマンド実行時に CLI 設定ファイルが読み込まれる。 デフォルトでは $HOME/.terraformrc と $HOME/.terraform.d/credentials.tfrc.json というファイルを読み込む。 これらのファイルに設定されているトークンが HCP Terraform の認証に使われるが、使われるトークンの優先順位は次のようになる。 $HOME/.terraform.d/credentials.tfrc.json $HOME/.terraformrc .terraform.d/credentials.tfrc.json .terraform.d/credentials.tfrc.json は HCP Terraform のトークンを格納するファイル。 terraform login で取得されたトークンがこのファイルへ自動的に登録される。 ファイルの中身は以下のようになっており、HCP Terraform のドメイン app.terraform.io または Terraform Enterprise (HCP Terraform のセルフホスト版) のドメインが設定される。 ...

「New Relic Kubernetes integration」というエージェントを使うことで Kubernetes のメトリクスを簡単に New Relic へ送ることができる。 Introduction to the Kubernetes integration | New Relic Documentation Kubernetes integration into New Relic: features, requirements, and getting started. docs.newrelic.com この Kubernetse integration は OpenShift にも対応しているが、kube-state-metrics には注意が必要。 何が起こるか：nrk8s-ksm で Warning が出続ける Kubernetes integration は Helm を使ってインストールでき、色々はリソースがデプロイされる。 そのうちの一つに nrk8s-ksm というコンポーネント (Deployment) があるが、デフォルト設定で Kubernetes integration をインストールすると、この nrk8s-ksm が次の Warning メッセージを出し続けてしまう。 Error populating KSM metrics: populate errors:, querying KSM: getting filtered metric families: error calling prometheus exposed metrics endpoint. Got status code: 400 どうすればよいか：参照する kube-state-metrics の namespace を指定する Kubernetes integration を Helm でインストールするとき、次の values.yaml が使われる。 ...

ふと思い立って、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)」を受賞されているらしい。 ...