~/notes - Dev

ghtknを開発フローに組み込んでみて

2026-07-26T00:00:00+00:00

はじめに</h2>
ghtkn</a>という素晴らしいツールがある。これは、GitHub Appにより発行できるUser Access TokenをCLIで取得できるようにしてくれるツールだ。何がうれしいかというと、特定のGitHub Orgやリポジトリのみにアクセスを絞れて、必要な権限のみに限定して、有効期限が8時間以内のアクセストークンを払い出せることだ。</p>
昨年、作者のsuzuki-shunsukeさんの記事</a>を見て存在は認識していたのだが、当時はそのメリットにあまりピンときていなかった。昨今世間を騒がせているセキュリティインシデント事例の中には侵害された端末上のGitHubアクセストークンを窃取する例もあることを知ってはじめて、ghtknの有用性に気がついた。</p>
それ以来、ここ3ヶ月ほど開発フローにghtknを取り入れて利用してきた。これに関していろいろと思うことがあるので、それを書き留めておきたい。</p>

ghtknの活用シーン</h2>
前おきとして、筆者がghtknをどのように利用しているかも紹介しておく。 ghtknを利用しはじめて以来、GitHubに対するCLI上のアクセス(`gh</code> cliや git</code> コマンドによるリポジトリへのアクセス)全てにghtknを利用している。 ghtknで払い出したトークンを環境変数 GH_TOKEN</code> に指定して gh</code> を利用し、ghtknをGit credential helperに設定して git</code> を利用している。</p>`
私用・社用トークンの使い分け</h3> 筆者が最も効果を感じているのが、私用・社用トークンの使い分けだ。筆者の所属する組織では、GitHub Enterprise Cloudを利用しており、GitHubアカウントは私用・社用で同じものを使用している。(GitHubの規約では1人1アカウントが原則だったと思うので、当然そうなるが)</p> よって、私用端末から組織のリポジトリにアクセスできてしまうし、会社の貸与端末からも私用のリポジトリにアクセスできてしまう。私用端末からの情報漏洩が怖いのもともかく、社用端末からトークンが漏洩し、私用のリポジトリやOSSリポジトリが侵害されるのも避けたい。なんならこちらのほうが個人としての信用に直接関わってくるまである。</p> ghtknを使えば、組織のOrgにアクセスを限定したトークンや、個人リポジトリにアクセスを限定したトークンを発行することができる。これにより、少なくともターミナル上の作業では私用と社用の完全な分離が実現できる。</p> 読み取り専用トークン</h3> ghtknでは、トークン発行に利用するGitHub Appの持つ権限範囲により、発行される権限スコープが絞られる。つまり、読み取り権限しか持たないAppを利用すれば、発行されるトークンもまた読み取り権限しか持たない。</p> これが何の役に立つかというと、Claude CodeなどのAIエージェントに調査タスクなどをやらせるときに、リポジトリに対する意図しない変更を防ぐために役立つ。 --permission-mode auto</code> を指定してClaudeに調査タスクやらせると、気をきかせて調査結果をIssueのコメントに書き込んだり、修正のためのPull Requestを作ったりすることがある。正直これらはありがた迷惑なので、そもそも書き込み権限なしの権限だけ渡しておけばよいだろうという考えだ。 AIに対して適切な指示を与えれば防げることだろうという指摘もあるかもしれないが、個人的には権限範囲を絞るというのが、この問題への対策として最もしっくりくる。</p>
`組織への導入と課題</h2>`
組織への導入</h3>
さて、前述のように利用するため、組織のOrgにGitHub Appを導入する必要があった。筆者は組織内ではOrgを管理する立場ではなかったため、関係部署への提案や説得を行った。その際に意識したのは次のようなポイントだった。</p>

セキュリティ的懸念の少ない権限設計</li>
具体的ユースケースを交えた説明</li>
利用者向けドキュメントの整備</li> </ul>
セキュリティ的懸念の少ない権限設計</h4>
組織への導入という意味では、個別のリポジトリではなく、Org全体に対するアクセス権を持つGitHub Appを作成できると話が早い。そのような広いアクセス権を持つAppを用意するとなると、当然だが必要最小限の権限のみをつけるようにしたい。そのため、提案の際には、 `gh</code> や git</code> から具体的に利用が想定される権限の一覧を用意した。具体的には次のようにした。</p>`
リポジトリに関する権限は、一般的な gh</code>, git</code> 利用に関連するもののみ付与する。セキュリティ的懸念が考えられるものは付与しない Administration, Secrets, Variablesなどの権限は与えない</li> Secret scanning alert, Dependabot alertなども、AIが誤ってアラートを閉じることがないように権限を与えない</li> </ul> </li> Organizationに関する権限は、よく利用されるMembers, Projectsのみ付与する</li> </ul> 特にクリティカルになりそうな権限をそもそも付与しないことで、万が一アクセストークンが漏れた際にも被害範囲を小さくとどめられるようにした。</p> 具体的ユースケースを交えた説明</h4> この仕組みを導入することで何がうれしいのか、どのようなメリットが得られるのかを、組織視点と利用者視点から説明した。私の所属する組織では、過去にOrg外のリポジトリに業務コードを誤ってプッシュしてしまうインシデントがあったようなので、そのようなインシデントも防げることを訴えた。</p> 利用者向けドキュメントの整備</h4> 組織として誤プッシュを防ぐという目的のためには、誤プッシュをしてしまいかねない人たちにもこの仕組みを利用してもらう必要がある。 ghtkn公式のドキュメントも決してわかりづらいことはないのだが、この層の人たちでもハードルを感じずに利用できるよう、さらに噛み砕いた内容の利用ドキュメントを用意した。</p> 利用は個人の裁量に任されてしまう</h3> 以上のように、組織に導入するにあたっては広くいろいろな人に使ってもらえるように足回りを固めたのだが、実際に利用されるかどうかは別問題だ。 ghtknはGitHubの公式のツールではないため、Orgのポリシーなどで利用を強制することはできない。一部のセキュリティ意識の高い人たちにはすぐに利用が広まったのだが、本当に利用してもらいたい層に働きかけていくのはこれからだ。結局このあたりは地道な草の根活動をしていくしかないとは思うが、こういうところこそうまくAIなんかを活用して効率的に広められたら良いなと思う。</p> また、私の所属する組織には業務委託などで参画してくれている人も多く、トークン管理をghtknに統一することが難しい場合があるのも課題だ。その人がGitHub上で関わる全てのOrgでghtkn利用への対応が行われないと導入の意味は薄く、利用者の負担も大きくなってしまう。</p> 結局のところは、サードパーティツールではなくGitHub公式からこのあたりの問題を解決する術が提供されるのが最善だと思う。関連Issueなどを見る限りはGitHub側はやる気はなさそうだが。</p> GitHubのプライベート利用をやめるという選択</h2> 極端な話、筆者個人の事情に限って言えば、GitHubは仕事専用に割り切って利用すれば全ての問題は解決する。最近では度々著名なOSSがGitHub以外のGitホスティングサービスに引っ越す例もあるわけだし、わざわざGitHubを利用し続ける理由もそこまではない。 dotfiles</a>なんかはGitHub Actionsにがっちりロックインされてしまっているが、これから作るリポジトリはtangled.orgかSourceHutに籍を置くのがよさそうだと思っている。</p> おわりに</h2> ここまで書いたように、ghtknは既に私の日々の開発フローの中では、なくてはならないツールの1つとなっている。もしここに書いたような課題を感じている方は、ぜひghtknを試してみてほしい。このツールを活用してセキュリティ的な懸念を1つなくすことで、これまでよりも開発に集中できる環境を得ることができると思う。</p>



nixos-limaを開発環境として使う
2026-07-13T00:00:00+00:00
はじめに</h2>
2年ほど前からプライベートでも業務でも、開発環境の構築にはNixを利用してきた。</p>
昨年秋ごろ、突如降ってきたやんごとなき事情により、業務用MacBookでのNix利用が禁止されてしまった。
それまでは何の問題もなく使えていたし、社内にもflake.nixを配置したリポジトリが多数あったにも関わらず、である。
一時期はこのあたりの決定権を持つ人たちを説得するため、いろいろと働きかけてはみたが、議論が進む気配はなく、こんなことに時間や労力を割くのもばかばかしいと思うに至るまでそう時間はかからなかった。</p>
とはいえ、使い慣れたツールを使えない環境で成果を出せと言われても無理な話だ。どうにかして業務端末上でNixを利用して開発環境を用意する方法はないかと考えてみた。
まず思いついたのはDockerコンテナ内で開発を完結させる方法だ。コンテナの中でならNixを使っても問題ないだろう。
ただ、MacBook、それも私の貸与されているMacBook Airはあまりメモリに余力はない。Docker Desktopを常時走らせてその上で開発用のコンテナを動かすのは若干心細い。
であれば、そもそもコンテナではなく仮想マシンならどうか。ということで考えたのが、LimaでNixOSのVMを立て、その中で開発をするという方法である。</p>
NixOS on Lima</h2>
Lima上にNixOSのVMを立てる試みは、既に前例がたくさんあったので参考にさせてもらった。</p>

NixOS Dev Environment on Mac</a></li>
limaでNixOSを導入する</a></li>
NixOS on Lima</a></li>
</ul>
これらの記事でも参照されている nixos-lima</a> の成果物を利用した。</p>
構築にあたってつまづいたポイントは多々あったが、最終的にはLima用の次のようなYAMLファイルを用意して起動するようにした。
https://github.com/rinx/dotfiles/blob/8d77fc6628d4455db77394dedf9e24618e64cb57/macos/lima/nixos.yaml</a></p>
limactl start</code> コマンドを次のように実行すればLima VMが起動する。</p>
❯</span> limactl start github:rinx/dotfiles</span></span></code></pre>
開発環境としてこのLima VMを利用するにあたって、要点は次のとおり。</p>

SSH Agent Forwardingを設定</a></li>
GPG Agent Forwardingを設定</a></li>
VM内からxdg-openを利用できるようにするUnix Domain SocketをForwarding</a></li>
VM起動後の初期設定のためのスクリプトを案内するmessage</a></li>
</ol>
1や2はよくある設定なので、見た通り設定すれば良い。</p>
3はVM内で xdg-open</code> コマンドに見せかけたスクリプトを実行すると、Unix Domain Socket経由でホスト側の open</code> コマンドを叩く仕組みのために用意してある。
これは、VM内のNeovimから何かしらのURLをホスト側のブラウザで開きたいことが多々あったため自作した。(https://tangled.org/rinx.tngl.sh/xsr</a>)
同じ仕組みは割とよくあるものなので、 Using open, pbcopy and pbpaste over SSH</a> などを参考にすると良い。</p>
4は limactl start</code> 実行時に表示されるメッセージを定義している。
GPG pubkeyやownertrustのimportなど、必ず実行しておくべきもろもろのスクリプトをここに書いておくと、実際に開発作業をするときに設定不備で時間を奪われることがないので助かる。</p>
NixOSイメージのCI上でのビルド</h2>
Lima用のYAML上で参照するVM用イメージは、自分のリポジトリのGitHub Actions上でビルドし、Release AssetsとしてPublishしている。</p>
例: https://github.com/rinx/dotfiles/releases/tag/2026.06.20</a></p>
自動ビルドの仕組み自体はほとんどnixos-limaのものを流用して構築している。</p>
とはいえ、私も実際に導入しているカスタム部分はそう多くはない。主要なところは次の2点くらいだ。</p>

dockerd</code> をサービスとして起動する</li>
Kitty用のterminfoを事前に導入しておく</li>
</ul>
実際利用してみて</h2>
この開発環境を実際に利用しはじめたのは今年の4月ごろからで、おおよそ3ヶ月間運用してきたわけだが、個人的な感触としてはかなり良い。
まず、ホストOS上に余計なソフトウェアを導入する必要がない。Limaだけ入れておけば開発環境をVMイメージとしてダウンロードして起動ができるので、とても衛生的に感じる。
もし利用しているうちにVM上に何か問題が生じたとしても、VMを消して起動し直せば良い、という前提があるのは気持ちの面でも非常に楽だ。</p>
また、同様の仕組みでsandbox.yaml</a>というLima用のYAMLも用意してある。
これは、Claude CodeなどのAIエージェントに自由に触らせる用のVMを立てるために利用している。自分が触るのとほぼ同じ環境をAIが自由に触れるようにして(最悪壊してもいいように)提供することで、開発効率を高めようという試みだ。
こちらも今のところうまく活用できているのではないかと感じている。</p>
一方で、唯一懸念される点としては、nixos-limaはLima公式からサポートされているイメージではない点だ。そのため、Lima側に破壊的変更があると稀にイメージが起動できなくなる可能性がある。
実際、Limaがv2.1.0で導入した変更により、それまで起動できていたものが起動できなくなった。このときはnixos-limaにパッチを当てて</a>問題を解決した。</p>
ちなみに「VM上でNixOSを開発環境として利用する」というのは mitchellh/nixos-config</a> でも紹介されているように、それなりに歴史と実績のある方法と言える。
万人に受ける方法ではないが、ハマるところにはハマるタイプの手法なのではないかと思う。</p>