Posts

私は悩んでいます。 自称プラットフォームエンジニアとして、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 はブログ記事を書く専用ですし、サジェスト機能をオフにしても支障はありません。 ...

はじめに 仕事ではもっぱら GitHub Copilot CLI を使っていて、最近個人でも GitHub Copilot Pro を契約してしまいました。 個人環境では Claude Code メインだったんですが、利用する時間が多いのはやっぱり仕事で使っている GitHub Copilot CLI で、Claude Code がリミットで使えないときに Copilot CLI 使おうかなと思ってます。 「Claude Code がなければ Copilot CLI を使えばいいのよ」精神です。 いずれメインも Copilot CLI になっていきそうな予感。 とはいえ細かい機能は Claude Code のほうがいいなと思う部分もあり（/copy コマンドとかね）、しばらくは二刀流でやっていきます。 「OpenClaw 用に ChatGPT Plus も契約して Codex CLI もあるじゃん」だって？うん、そうだね。 というわけで、そんなプライベートにも侵食してきた GitHub Copilot CLI にリモートアクセス機能が追加されました！ 今回は GitHub Copilot CLI の布教記事です。 リモートアクセスとは Remote control CLI sessions on web and mobile in public preview - GitHub Changelog The Copilot CLI is no longer a purely local experience. Today we’re launching copilot --remote: With remote capabilities, you can now monitor and steer a running CLI session directly from… github.blog 2026年4月13日、GitHub Copilot CLI にリモートアクセス機能が Public Preview として追加されました。 copilot --remote で起動すると CLI セッションの状態がリアルタイムで GitHub にストリーミングされて、ブラウザや GitHub Mobile アプリから操作できるようになります。 ...

はじめに GitHub Copilot CLI の /research コマンドはほんと便利。 /research と pptx スキルを組み合わせると、うまくいけば 1 Premium request でかなり情報がまとまったパワポを作れます。 /research は調査した内容を Markdown 形式のレポートとして出力して、pptx スキルはこのレポートを使ってパワポにします。 パワポ生成は一例で、/research はこのレポートに価値があります。 GitHub Copilot CLI の機能でレポートをエディタで開いたり、Gist やファイルに保存したりは可能です。 Researching with GitHub Copilot CLI - GitHub Docs The /research slash command turns Copilot into your research assistant, gathering in-depth information and insights on a topic. docs.github.com 話は変わって、ターミナルで GitHub Copilot CLI を使い始めてから VS Code を使う頻度が下がって、ターミナルがメインの生活になってきました。 VS Code を使っていたときは Markdown ビューアとしても使っていたので、代わりにターミナルでも使える Markdown を見る方法を考えていたところ k1LoW/mo というツールを知りました。 ...

はじめに 最近はターミナルに住んで GitHub Copilot CLI とお話しするだけの日々を過ごしていますが、GitHub Copilot Cloud Agent (旧 GitHub Copilot Coding Agent) も便利ですよね。 正式名が地味に長いので Cloud Agent と呼びますが、自分の中で Cloud Agent には「Terraform を知らなくてもいい人たちが Terraform 経由でプラットフォームを扱えるようになる」ことを期待しています。 Cloud Agent に「Terraform のコード書いて」と依頼すればいい感じに Terraform のコードを書いてくれるし、カスタムインストラクションやスキルを用意しておけば更に精度の高いコードを書いてくれます。 これは GitHub Copilot に限った話じゃないですね。 Cloud Agent に Terraform コードを書かせるだけならまっさらな環境でも綺麗に書いてくれますが、hook を使って「 .tf ファイルを修正したら terraform fmt を実行する」みたいなことをやろうとすると、Cloud Agent の実行環境に terraform コマンドが必要になります。 今回は Cloud Agent の実行環境を整える方法の話です。 Cloud Agent 実行環境のカスタマイズ Cloud Agent はリポジトリに .github/workflows/copilot-setup-steps.yml というワークフローファイルを置くことで実行環境をカスタマイズできます。 terraform を例にすると、このワークフローファイルに terraform コマンドをインストールするステップを追加すればいいんですが、どのバージョンをインストールするか、という管理の手間が出てきます。 tenv とかの terraform 用管理ツールもあるので terraform を例に出したのが良くなかったなと思いつつ、Cloud Agent の実行環境にツールをインストールする方法はいくつかあります。 ...

HCP Vault Dedicated を利用しているときに required index state not present というエラーメッセージが出たので、原因と対策をまとめます。 何が起きたか HCP Vault Dedicated では KV シークレットエンジンなどのシークレット管理サービスや Transit シークレットエンジンを使った暗号化サービスを提供しています。 クライアントアプリケーションから HCP Vault Dedicated の暗号化サービスに対して復号リクエストしたときに、まれに required index state not present というエラーが返ってくることがありました。 原因 HCP Vault Dedicated のノード間のインデックス同期よりもクライアント側の Write リクエストと Read リクエストの間隔が短いことが原因でした。 少し踏み込んでみます。 HCP Vault Dedicated は内部的に Active ノードと Performance Standby ノードを持っていて、Vault クラスタに対する Write/Read リクエストは各ノードに振り分けられます。 リクエストが Active ノードに送られた場合は特に影響ないため割愛。 Write リクエストが Performance Standby ノードに送られると Active ノードに転送されます。 ドキュメントを読むと、厳密には認証や動的シークレットのリクエストのときには RPC を使って Active ノードにトークンなどの情報を書き込み、それ以外の Write リクエストは Active ノードに転送するようです。 Write リクエストが処理されると Vault の内部でインデックスが更新されます。 ...

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 チームと開発チームの分断がなぜ起こるのか、その構造的要因と解決アプローチについて紹介されていました。 ...