勇往邁進

GitHub Copilot CLI が GA しましたね！ Claude Code と GitHub Copilot CLI の両刀使いユーザとしては、両者が切磋琢磨して機能追加してくれるのは嬉しい限りです。 そんな Claude Code と GitHub Copilot CLI の機能差としてのステータスラインの話です。 Claude Code ではステータスラインをカスタムできるので、モデル名や 5 時間セッションの使用率とかを表示してます。 Claude Pro なのでセッション上限を常に気にしながら Claude Code に作業をお願いしています。 早く富豪コーディングしたい。 一方、GitHub Copilot CLI のデフォルトはこんな表示です。 カレントディレクトリとブランチ名とモデル名、そして残り Premium requests の割合が表示されます。 GitHub Copilot CLI でも同じようにステータスラインをカスタムしたいんですが、GA した v0.0.418 でも正式にはできません。 「正式にはできない」ですが、Experimental な機能としてステータスラインのカスタマイズが提供されています。 GitHub Copilot CLI で /experimental コマンドを使って Experimental モードを有効にすれば、ステータスラインのカスタムができるようになります。 まずは /experimental show コマンドで Experimental モードで使える機能一覧を確認。 ❯ /experimental show ● 🧪 Experimental Features The following experimental features can be enabled with `/experimental on`: Feature Flags: PERSISTED_PERMISSIONS - Enable persisted tool permissions across sessions on a per-location basis SESSION_CLEANUP - Enable /session cleanup and /session prune commands for managing session storage SUBAGENT_COMPACTION - Enable compaction instead of truncation for subagents SESSION_STORE - Enable SQLite-based session store for cross-session history, file tracking, and search STATUS_LINE - Enable custom status line functionality that executes user-defined scripts SHOW_FILE - Enable a tool which allows the agent to show you code snippets within the timeline ⚠️ These features are not stable, may have bugs, and may be removed in the future. Usage: /experimental show - Show this help /experimental on - Enable experimental mode /experimental off - Disable experimental mode 色々 Experimental な機能がありますが、ステータスラインのカスタムは STATUS_LINE というフラグで提供されています。 ...

Claude Code が面白くて最近は週末バイブコーダーになってます。 今月末で Claude の年間サブスクが切れるので、Claude Max にするか Codex を併用するか絶賛悩み中です。 そんな中、今回は開発中の HCP Terraform 用の CLI ツール hcpt を使った「GitHub の PR に紐づく Terraform Plan を確認する方法」を紹介します。 GitHub - nnstt1/hcpt Contribute to nnstt1/hcpt development by creating an account on GitHub. github.com 使い方の簡単な説明 hcpt では hcpt run コマンドで HCP Terraform 内の Terraform 実行結果を確認できます。 hcpt run show Terraform 実行結果の詳細を表示 Run ID, Workspace 名, GitHub の PR を指定可能 hcpt run list --workspace/-w 指定したワークスペースの Terraform 実行結果を一覧表示 HCP Terraform と GitHub を連携していると、PR トリガーで Terraform Plan が実行されます。 hcpt run show --pr <PR 番号> --repo <owner/repo> で PR トリガーの Terraform Plan を確認できます。 ...

Terraform のステートとかドリフトとかを管理してくれる HCP Terraform （旧称 Terraform Cloud）というサービスがあるんですが、それをコマンドラインから操作するための CLI ツール hcpt を作っています。 GitHub - nnstt1/hcpt Contribute to nnstt1/hcpt development by creating an account on GitHub. github.com HCP Terraform の認証周りがちょっといけてなくて、ブラウザで操作していると頻繁にセッションが切れてしまうんですよね。 ワークスペースを確認するだけなのにログインの待ち時間のほうが長い。 なのでコマンドで確認したかった。 メンテされてそうな HCP Terraform 用の CLI ツールが見つからなかったので自作です。 今までは「いいツールないなぁ」で諦めてたんですが、今回は Claude Code と一緒に作っています（作ってもらってる？）。 hcpt を作るモチベーションは他にもあって、Raycast の拡張機能をストアに公開する前準備として CLI ツールを作っています。 HCP Terraform のワークスペース一覧などを出す Raycast の拡張機能も作っていってるんですが、拡張機能を Raycast のストアに公開しようとすると raycast/extensions リポジトリにコードを置かないといけなくなります。 今は拡張機能内で HCP Terraform の API を叩く実装にしているんですが、ストアで公開すると細かい修正をする度に raycast/extensions リポジトリにプルリクを送る必要があって面倒になりそう。 HCP Terraform とやりとりする部分は hcpt に切り出して、Raycast 拡張機能からは hcpt を呼び出す形にしようと思っています。 週末に Claude の Pro プランで回してみたけど、使用量がまったく足りなかったです。 今月末で年間サブスクが切れるので、来月から Max プランにしようかな。 週末だけ使用量が増えるプランが出たらいいなぁ。 ...

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 の公式ドキュメントを見てもらいたい。 ...