Tech

はじめに 仕事ではもっぱら 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 プランにしようかな。 週末だけ使用量が増えるプランが出たらいいなぁ。

全 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」の順でネストされた配列が返ってくる。 大量に出てくるので、大幅に省略したものを載せておく。 ...