【GitHub Actions】シークレットを別のリポジトリに migrate するツールを作った

みなさん、GitHub Actions のシークレットの管理ってどうしてますか？
設定された内容をどこか別の管理場所で保存している場合もあると思いますが、設定するだけで何もしてない場合も多いのではないでしょうか。

登録されたシークレットの中身は基本的に閲覧することはできません。シークレットの操作は gh secret コマンドから行なうことも可能ですが、当然これらも delete / list / set サブコマンドしかなく、get はできません。
GitHub Actions に詳しい人なら、中身を確認する方法はわかるのではないかと思いますが、面倒ではあります。

ただ、シークレットの中身を閲覧できなくても、困ることはほとんどないでしょう。

https://github.com/srz-zumix/gh-secret-kit
今回「シークレットを別のリポジトリに migrate するツール」の紹介をするわけですが、なぜこれが必要になったのか、から説明します。

なぜこれが必要か

きっかけはとあるリポジトリのホスト移動が必要になったことです。
このようなケースは GitHub の公式ツールでサポートされており、 gh-gei を使うことで migrate することができます。
About migrations between GitHub products with GitHub Enterprise Importer - GitHub Docs

しかしながら、サポートされている移行対象のデータは限定的です。
プルリクエストなどは移行できますが、Rulesets や Teams など結構よく使う機能も移行対象外になっています。
当然、シークレットも移行できません。

Rulesets や Teams などは設定を閲覧することができますし、API で取得・設定することも可能なため、それらを移行するのは（手動でも自動でも）難しくはないでしょう。AI に依頼すれば直接やったり、スクリプトを書いたりしてくれる気がします。
しかし、シークレットは簡単には閲覧することができず、リポジトリや Organization に設定されたシークレットを1つ1つ手動で再設定するのは、とても面倒です。
Organization の移動が大量にある場合は考えたくないですね。

でも、シークレットの中身を知る方法がないわけではありません。GitHub Actions のジョブの中では中身を使っているわけですから。
シークレットの移行が自動でできる可能性は 0 ではない。ということで作成をしました。

使い方

使い方はドキュメントにまとめてあるので、そちらを参照してください。
また、Skills も用意してあります。
gh-secret-kit をインストールしたのち、gh secret-kit skills install することでインストールできます。

仕組み

さて、仕組みですが基本は単純です。
移行元で実行されたジョブの中から移行先にシークレットを設定します。

ジョブからはシークレットの内容を知ることができるわけですから、これは実現可能ですよね。

しかし、対象のシークレットはワークフローに静的に記載されている必要があります。
なので、シークレットをリストアップしてワークフローを生成し、その生成したワークフローを push してそれを実行します。

ワークフローを実行する方法はいくつかありますが、デフォルトブランチにワークフローが必要なものと、トピックブランチにあれば良いものので大きく分けられます。
今回 GitHub のリポジトリ移行という目的があるので、デフォルトブランチを書き換えるのは避けたいです。CLI からワークフローを実行するのであれば workflow_dispatch が都合が良いのですが、これはデフォルトブランチにワークフローが必要なため、今回は pull_request イベントの labeled アクティビティで発火させるようにしています。
なぜ labeled なのかというと、任意のタイミングでコミットに紐づかずに再実行可能にしたかったからです。
（ちなみに、デフォルトブランチを変更することなく、workflow_dispatch を実行する方法はあるのですが、実装当時に知らなかったのでこのやり方になっています）

これで CLI からシークレット移行ワークフローを実行させることができるようになります。

ここで問題になるのがアクセス権限です。
移行元のアクセス権限は問題ないと思いますが、移行元に「移行先のシークレット設定が可能なシークレット」が存在しているとは考えにくいです。
このために設定するという手段もあると思います。gh-secret-kit では、どのシークレットを使うか指定できるようになっているので、そのケースにも対応はしています。
しかし、そのシークレットも移行対象となり移行先で消す必要が出てきます。（まぁ、そのための除外オプションもあるのですが）

そうではなく、移行担当者は移行元・移行先どちらの admin 権限を持っているはずなので、担当者の環境でジョブを実行し、担当者の gh auth token を使えば、移行に必要な権限を確実に得ることができるわけです。

GitHub Actions は Self-hoted runner として、好きな環境でランナーを起動することが可能です。ScaleSet API を使って CLI 実行者のローカルマシンでランナーを立ち上げ、専用のランナーラベルを指定してワークフローを実行します。
これにより、既存のランナーを使うことなく移行が可能になるため、開発に影響を与えずに移行が可能になりました。

さいごに

gh-secret-kit は Organization / Repository / Environments のシークレットを移行することが可能ですが、Agents / Codespaces / Dependabot のシークレットには対応していません。
Agents と Codespaces は対応できなくもないかも？しれないですが、Dependabot は無理なような気がしています。もしアイディアあれば教えてください。

あと、このブログを書いてて実はもっと簡単な手順で対応も可能な気がしてきたので、試してみようかなと思います。

これを使う機会はそうそうない気がしますが、誰かの役に立てば幸いです。

gh-activity-report と NotebookLM で2025年の活動をふりかえる

さて、2025年もあとわずかですね。
今年の GitHub での活動を gh-activity-report と NotebookLM でふりかえります。
この組み合わせでのふりかえりは過去にもブログ投稿をしてますので、詳細はそちらへ
「GitHub Search と NotebookLM で自分の活動を振り返る」

今回は年間のふりかえりなので gh-activity-report と NotebookLM の使い方も若干やり方もアップデートされました。
まず、拡張機能には楽に期間が指定できるように --year オプションと --fy オプションを追加しています。
次に NotebookLM の「レポートを作成」から「ブログ投稿」を今回使ってみました。

出来上がったブログレポートは末尾にコピペしました。（ちょっと長いです）
ちょっと、いや、かなり盛りすぎかなと思いますが、ウソではないかなと思うのでそのまま掲載してます。
まぁ実際に自分のブログにはそのまま使えないですが、観点を得る目的だったらアリかも？と思いました。最近はブログでアウトプットをせず、GitHub で欲しいものを開発してるって感じなので、１リポジトリだけをソースにしてブログ書かせてみるのは、ブログ書くきっかけを作れるかも。

「ブログ投稿」はさておき、自分なりにもふりかえってみます。
NotebookLM の要約の最後のまとめだとこんな感じでした。

まとめとしてはあってるかなと思います。
最近よく使っているプログラミング言語は Go ですね。gh extension を書く場合の定番だからという理由で使い始めたんですが、コーディングエージェントとも相性が良いのかなと最近感じています。エージェントに依頼するとパッケージからドキュメントを読んだり、必要な機能を検索したりして、だいたいのことはやってくれます。自分は C++ で育ってきたのですが、それらだと難しそうだなと感じます。※最近（20以降）の C++ 事情を知らないですが

GitHub Actions のアクション開発を最近はよくやってたんですが、最近のテーマはローカルでも同じことができることとしています。Jenkins のときもジョブに直接書くな、スクリプトは別ファイルにしろと言われて来ましたが、GitHub Actions でも同じだと強く感じています。
GitHub Actions で GitHub に関することを扱うのであれば、gh extension として機能開発をしてアクションとしてはそれを呼び出すだけという構成が個人的な答えだと思っています。
そのへんの話は秋頃に勉強会でお話させてもらったのでよければ参考にしてください。
「gh-extension と aqua で作る GitHub Actions アクション」

開発体験向上としてこのへんに注力しているのは、AI とうまく付き合っていくためとも思っています。
（セキュリティに関しては aqua 任せなんで自分はほとんど何もしてないかな）
AI Ready という考えを意識してたりします。このへんは来年書けたら書きたい。

さて、いよいよ時間がなくなってきましたので、ここらへんでおわりたいと思います。
2025年もありがとうございました。2026年もよろしくお願いします！

---

ある開発者のGitHub年間活動全ログを分析して見えた、生産性を爆発させる5つの習慣

1. 導入：生産性の高い開発者の頭の中とは？

優れた開発者は、一体どのように1年間を過ごしているのでしょうか？その圧倒的なアウトプット、その生産性の源泉は何なのでしょうか？私たちはしばしば完成されたソフトウェアや華々しいリリースに目を奪われがちですが、その裏側にある日々の地道な活動こそが、真の価値を生み出すエンジンなのかもしれません。

本記事では、一人の多作な開発者（srz-zumix氏）の2025年におけるGitHubアクティビティログを徹底的に分析しました。すると、そこからは驚くほど一貫した、そして誰もが参考にできるであろう5つの「習慣」が浮かび上がってきました。

この分析が、あなたの開発プロセスを見つめ直し、改善するための具体的なヒントになることを願っています。さあ、生産性の高い開発者の頭の中を覗いてみましょう。

2. 習慣1：徹底的な自動化—特に自分自身のワークフローを狙い撃て

srz-zumix氏の活動ログを見て、まず目に飛び込んでくるのは、開発ツールや自動化に関連するリポジトリの多さです。これは単なる趣味のツール作りではありません。日々節約される数分が年間では数週間の生産的な時間に変わることを理解した、意識的な「投資判断」なのです。

彼が解決しようとしているのは、自分自身のワークフローに潜む「痛み」です。

• gh-activity-report: 四半期や年次のコントリビューション概要をまとめるという、退屈で手作業になりがちなプロセスを自動化します。
• labeler-action: 新規に作成されたプルリクエストを手動で確認し、タグ付けするというトリアージ作業を不要にします。
• post-run-action: GitHub Actionsのジョブ完了後に行うべき後処理やクリーンアップ作業を自動化します。
• aqua-installer-cache: ツールインストーラーのキャッシュを賢く管理し、CI/CDの実行時間を短縮します。

ここから得られる教訓は明確です。「最も身近な課題、つまり自分自身の非効率な作業を解決するツールを作ることが、結果的に大きな生産性の向上に繋がる」ということです。他人のための壮大なツールを作る前に、まずは自分の足元にある非効率を解消する。その投資は、複利効果で将来の自分に大きなリターンをもたらすのです。

3. 習慣2：再利用可能な「キット」を作り、開発を加速させよ

srz-zumix氏の活動は、単に個別のツールを場当たり的に作っているわけではありません。そこには明確なアーキテクチャ戦略が見て取れます。その戦略の証拠は、go-gh-extensionというリポジトリを中心としたエコシステムにあります。

このリポジトリは、GitHub CLI拡張機能を作成するための共通ライブラリとして機能しており、他の多くのツールがこの基盤の上に構築されています。

• gh-label-kit: ラベル管理ツール
• gh-team-kit: チーム管理ツール
• gh-rule-kit: リポジトリのルールセット管理ツール

これが単なる主張ではなく、体系的な戦略であることは、ログを見れば明らかです。2025年12月初旬の活動は、その見事な証拠を示しています。

1. 12月02日: まず基盤となるgo-gh-extensionに「Guardrails」という機能が追加されます（PR #67）。
2. 12月03日: 翌日、その機能を活用する形でgh-team-kitに「Guardrail」が実装されます（PR #85）。
3. 12月04日: さらにその翌日、gh-rule-kitにも同様の「guardrail」機能が実装されました（PR #17）。

この一連の流れは、共通基盤に加えた一つの改善が、システム全体に効率的に波及していく様子を完璧に示しています。まず汎用的な土台を作り込み、その上に目的に特化した「キット」を組み立てるアプローチは、一貫性の担保、開発速度の向上、メンテナンス性の劇的な改善という、計り知れない利益をもたらします。「車輪の再発明」を避け、再利用可能なコンポーネントを意識的に作る。この「キット化」の発想は、あらゆるプロジェクトに応用できる強力な武器となるでしょう。

4. 習慣3：貢献のループを回せ—エコシステムへの還元が自身を成長させる

srz-zumix氏の活動は、彼自身のプロジェクトだけに留まりません。ログには、著名なオープンソースプロジェクトへの具体的で価値ある貢献が数多く記録されています。

• rhysd/actionlint: 無数の開発者が利用するこの静的解析ツールに対し、パーサーでYAMLのアンカーとエイリアスをサポートする機能を追加しました（PR #568）。
• DeNA/setup-job-workspace-action: ワークスペース設定をより柔軟にするため、repository-nameオプションを追加しました（PR #251）。
• actions/labeler: GitHub公式のラベラーに対し、プルリクエストのレスポンスからブランチ名を取得する機能改善を提案しました（PR #873）。

自分が日々使っているツールを、単なる消費者として利用するだけでなく、改善点を見つけては自らコードを書き、コミュニティに還元していく。しかし、これは単なる利他的な行為ではありません。多くの開発者が利用する外部プロジェクトに貢献することで、自分とは異なる設計思想やコーディングスタイルに触れ、新たな知見を獲得できます。これは、より広い視点を得て自身の技術力を高めるための、極めて効果的な自己投資と言えるでしょう。

ツールを作る→使う→改善して貢献する→新たな知見を得て、また次のツール作りに活かす。

この貢献のループこそが、開発者を継続的に成長させるのです。

5. 習慣4：小さな改善を即座に反映させる、高速なイテレーション

活動ログを時系列で追っていくと、あるリポジトリでの変更が、間髪入れずに別のリポジトリで利用されるという、極めて短いフィードバックループが繰り返し現れます。これは一度きりの偶然ではなく、彼の開発スタイルに組み込まれた意図的なパターンです。

例えば、2025年11月24日の活動を見てみましょう。

1. 16:04: gh-label-kitリポジトリで、バージョンを0.12.0から0.12.1に上げるプルリクエスト（#76）がマージされます。
2. 16:13: そのわずか9分後、labeler-actionリポジトリで、たった今リリースされたばかりのgh-label-kit v0.12.1を利用するためのプルリクエスト（#30）がマージされています。

この「作って、すぐに使う（ドッグフーディング）」という高速なイテレーションは、srz-zumix氏の開発スタイルの核心の一つです。このパターンはログ全体で散見され、例えばgh-label-kit v0.9.0への更新（PR #58）が即座にlabeler-actionで利用される（PR #23）といった例も確認できます。

ライブラリに加えた改善が、実際のアプリケーションでどのように機能するかを即座に検証することで、ツールの品質は急速に向上し、机上の空論ではない、実践的な改善が促されるのです。

6. 習慣5：継続こそが最強の機能である

最後に、そして最も重要な習慣は「継続」です。srz-zumix氏の活動は、年間を通じてほぼ途切れることがありません。その象徴的なコミットが、2025年の大晦日、12月31日に行われています。

• [srz-zumix/gh-activity-report]: 91 - add --year option (2025-12-31T13:23:22Z)

年の瀬も押し迫ったこの日に、自身の活動レポートツールに新しいオプションを追加しているのです。この一つの事実が、彼の開発に対する一貫性と情熱を何よりも雄弁に物語っています。

また、活動内容も派手な新機能開発だけではありません。「Bump version」「update packages」「Fix typo」「Update README.md」といったプルリクエストが数多く見られます。これは、バージョンアップ、パッケージ更新、リファクタリング、ドキュメント修正といった地道なメンテナンス作業が、活動の大部分を占めていることを示しています。

イノベーションは、ある日突然のひらめきから生まれるのではなく、日々の地道な積み重ねと、絶え間ない改善活動の中から生まれる。このログは、開発者にとっての普遍的な真理を改めて教えてくれます。

7. 結論：あなたの次の「自動化」は？

今回、一人の開発者の年間活動ログから、生産性を飛躍させる5つの習慣を抽出しました。これらは独立した習慣ではなく、相互に連携する一つのシステムとして機能しています。

1. 自動化は日々の手間をなくし、深い思考のための時間を捻出します。
2. その時間で、開発を加速させる再利用可能な「キット」を戦略的に構築します。
3. 高速なイテレーションでキットを実戦投入し、即座に品質を向上させます。
4. 得られた知見をエコシステムへの貢献に繋げ、自身を成長させるループを回します。
5. そして、これら全てを支えるのが、日々の地道な継続という最強のエンジンです。

これらの習慣は、決して特別な才能を必要とするものではありません。意識とアプローチ次第で、誰でも今日から取り入れることができるはずです。

さて、この開発者の活動ログから、あなたが次に取り組むべき「自分だけの小さな自動化ツール」のアイデアは浮かびましたか？

---

※ 習慣3：たしかに自分の OSS 以外にもコントリビュートしていますが、マージまでやりきってるのはそこまでないかなと思います。

gh と peco でリポジトリ一覧から選択して clone する

はじめに、雑な説明

gh は GitHub 関連の操作がとっても楽になる便利な CLI です。
peco は CUI 上でインタラクティブに候補から出力を選択できるツールです。

各種インストール

gh: https://github.com/cli/cli#installation

peco: https://github.com/peco/peco#installation

エイリアス

.giconfig ファイルに下記を追加します

[alias]
	peco = "!f(){ git peco-$1 ${@:2:($#-1)}; };f"
	peco-clone = "!f(){ gh repo list -L 100 $1 --json nameWithOwner --jq '.[].nameWithOwner' | peco | xargs -I % gh repo clone -u up % ${@:2:($#-1)};};f"

-u up オプションを付けているのは fork リポジトリの場合にデフォルトで upstream が remote に追加されますが、この名前だと gh pr create したときに push する remote を選択するときに upstream が第一候補になってミスりやすいからです

使い方

git peco clone srz-zumix

最後に

今まで git clone するときにいちいち GitHub をブラウザで開いて URL コピペしたりして clone してましたが、gh の登場でかなり簡単に clone できるようになりました。

gh repo clone owner/repo

こうですね。

ただ、新しい PC に引っ越ししたときに環境構築をしていて、↑の方法で clone してたのですが、リポジトリ名なんだっけ？となることがあって（１つの org にいっぱい repo あったりするので・・）、その度にブラウザ開くか、「gh repo list owner」コマンドでリスト出してたんですが、 peco でワンオペにしたらええやんということで生まれました。

この方法であれば owner/organization 名さえ覚えておけば簡単に clone できます。
peco の機能で検索フィルタも書けられるので目当ての repo も探しやすい！

ちなみに GitHub Enterprise の場合は GH_HOST 環境変数でホストを指定すれば対応できますが、私はめんどくさいしつけ忘れてしまうことが多いので gh-do もインストールして下記のエイリアスを登録して使ってます。

alias ghe-do="gh do --hostname=github.hoge.jp --"

e.g.

ghe-do git peco clone xxx

今回は以上です。