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 以外にもコントリビュートしていますが、マージまでやりきってるのはそこまでないかなと思います。

2025年も残りわずか！

みなさん。こんばんは。
2025年も残り4時間を切りました。私は今から 2026 年までにふりかえり記事を書き切ることを今年最後の目標としました。この投稿とは別で書きます。

さて、目標記事の方は個人の GitHub の活動をふりかえる記事にしたいと思いますので、こちらでは簡単にその他どんなことがあったのかふりかえります。
（さっさと目標の方を書くべきですが、他のことも今年のうちに書いておきたいので…）

CEDEC2025運営委員をやりました！

まず始めに 2025 年はなんといっても CEDEC ですね。
念願だった運営委員をやりました！CEDEC2025 のサイトにもちゃんと載ってますね。感無量。ちなみに、ふりかえりは社内向けに結構ちゃんと書いて、社内勉強会でも発表したんですが、ここでは簡単に（公開予定ありません）

やはり、運営委員側になって見えたもの、感じたものがあり、とてもたくさんのインプットを得られ、さらに自分自身の成長や変化に繋がったかなと思います。
自分が CEDEC に始めて参加したのは、たぶん 2011 か 2012 かな。
初登壇したのが 2015。最近も登壇しまして、トータルで5セッションになりました。いろんな意味で CEDEC は私を成長させてくれたなと思います。転職してからしばらく視線が社内に向いていたのですが、最近また外に向き始めていたので非常に良いタイミングだったと思います。

CEDEC2026 のサイトもオープンしてますね。公募も年明けから開始されるようなので、是非みなさんも応募していただければと思います。
自分も登壇者として、また新しいチャレンジができたらなーと思っています。

ブログの再開

次はこのブログの再開ですね。再開したと言っても以前のような週1更新ではなく、不定期ではありますが…
まぁ、ほぼ2年お休みしていた状態からなので良しとしましょう。
CEDEC 運営委員になったから再開したわけではなく、若手のやる気に感化されたんですよね。
あとは AI によってやる気になったおじさんの一人って感じですね。
まだまだオレも若いぞということです。

GitHub

最後に GitHub の活動を。これも AI パワーによって commit が増えた気がします。

（もっと増えたかな？と思ってたけどそれほどでもなかった…去年の自分エライ）
感覚としは、あまり詳しくないものでも取っ掛かりになるものをすぐに得られるようになったことで、こういうのあると便利かも！からとりあえずやってみるが増えた気がします。
今までもできなくもなかったとは思うんですが、詳しくないと調べ方もわからなかったり、言語やツールのセオリーとかもわからなかったりで、最初の一歩が重かった。
それが大分軽くなりましたね。

あと、今まで出勤時にはスマホでゲームだったのですが、今はスマホでコーディングエージェントに指示して OSS 開発をしています。（あ、基本リモートなので出社はほとんどしてないんですけどね）時間（スピードやタイミング）的にも OSS 開発がしやすいなったと感じますね。
どんな活動があったかは、このあと別の記事でふりかえろうと思います。

最後に

2026年は今年よりも記事書けたらなーと思ってます。
それでは、良いお年を。

【GitHub Actions】export-ignore でアクションのサイズを小さくする小技

こんにちは。皆さん GitHub Actions のアクション作ってますか？
では、${{ github.action_path }} はご存知でしょうか？ 
github.action_path は composite action の実行中に有効なプロパティで、アクションのリポジトリに含まれているファイルにアクセスするときに便利なやつです。

例えば、私が先日リリースした srz-zumix/labeler-action ではリポジトリにおいてある aqua の設定を使ってツールのインストールを行っています。
「ブログズミ: 【GitHub Actions】actions/labeler 互換で on.pull_request 以外でも使えるアクション srz-zumix/labeler-action を作りました」
ソースコード的にはこのあたりです。
https://github.com/srz-zumix/labeler-action/blob/main/action.yml#L43

実はこのアクションを作ったときに github.action_path に .git ディレクトリがないことに気づきました。てっきり checkout されていると思っていたのですが、実際には git archive されているようでした。

あまり使う機会はないかもしれませんが、git archive はリポジトリの内容だけを保存できる機能で、GitHub 上だと「Download ZIP」にあたります。

ところで、.gitattributes の export-ignore はご存知でしょうか？ Git - Git の属性 (export-ignore)
これは archive に特定のパスを含めないようにできる属性です。例えば、成果物を提出する時なんかに便利な機能です。

さて、ここまで来たら想像がつきますよね？
そうです。アクションのリポジトリでも export-ignore を設定することで、アクションを使うときにダウンロードしてくるサイズをちょっと節約できます。

ちなみに、composite action 以外の action でも archive が展開されるのは同じです。
TypeScript でアクションを作ってる方は多いと思いますが、アクションが実際に使うのはコンパイル後の .js ファイルです。ソースである .ts ファイルやテストコードなどアクションの実行には不要なファイルがそこそこあります。
このようなアクション実行時に不要なファイルを export-ignore してみるのはどうでしょうか。試しに自作アクションで導入してみました。
srz-zumix/post-run-action

御覧頂いているように、不要なファイルを除外しつつ、問題なくアクション実行できています。

今回試した post-run-action はもともと小さなリポジトリなので、export-ignore の恩恵はほとんどないとは思います。ただ、ソースが大きかったり、テストデータが大きかったりする場合は多少変わってくるかもしれません。

今回はちょっとした小技の紹介でした。
（ちなみに export-ignore を確認したときに知ったのですが、export-subst でなんか面白い使い方できないかなぁと思った）

ではでは。

【GitHub Actions】actions/labeler 互換で on.pull_request 以外でも使えるアクション srz-zumix/labeler-action を作りました

actions/labeler 便利ですよね。
でもちょっと困ったことがありました。
過去の PR に対してルール適用をしようと思ったところ、ブランチ名ルールが pull_request イベント前提のコードになっていて、workflow_dispatch で PR 番号指定して実行したときに設定どおりにラベル付けできませんでした。

この問題の修正 PR を出してはいるんですが反応がないので、自分で作りました。

srz-zumix/labeler-action

使い方は actions/labeler とほぼ同じです。

labeler の設定ファイルと同じ設定ファイルが使えます。
labeler-action は `dot: false` には対応していないのですが、ラベルの色設定に対応しています。labeler はラベルがない場合にラベルを作成してくれはしますが、色がグレーになってしまうのでちょっと不便でした。

色指定は以下のようにします。

ci:
- any:
  - changed-files:
    - any-glob-to-any-file: '.github/*'
- color: '#7c0bb2'

aqua:
- changed-files:
  - any-glob-to-any-file: 'aqua.*.yaml'
- color: '#1E90FF'

documentation:
- changed-files:
  - any-glob-to-any-file:
    - 'docs/*'
    - README.md

都合が良いことに color の設定があっても actions/labeler では無視されてエラーにはなりません。

ちなみに labeler-action はツールを呼び出しているだけで処理の実体は srz-zumix/gh-label-kit にあります。こちらも私が作っているもので、GitHub のラベル関係の操作を行える gh-extension となっています。
この拡張機能の１機能として labeler コマンドを実装しています。
したがって、gh-label-kit を使っていただければ GitHub Actions を使わず、ローカル環境からでもラベル設定が可能になります。
その他にも gh 標準には（今のところまだ）ない機能が揃っているので是非使ってみてください。

また、今回は gh-extension を gh extension install するのではなく、aqua を使用してインストールしています。これは self-hosted runner のことをちょっと意識しています。
aqua はまだ使い始めて間もないので、もっと便利な使い方を実践していきたいです。


以上です。ではでは

【GitHub Actions】任意のスクリプトを Post 実行するアクションを作った

srz-zumix/post-run-action

リポジトリはこちちです。
機能としては run step と同等のことが Post タイミングで実行できるアクションです。

アクションには後片付けをするタイミングとして Post 処理が書けます。
よく使う actions/checkout も Post 処理で git config などを元に戻す処理がされています。
実行ログを見ていただくと、下図のように Post 処理が並んでいると思います。



このようにワークフローで手軽に Post 処理を記述ができようになる便利なアクションが post-run-action です。
もちろん post-run-action を使わずとも if: always() なステップを最後に追加すれば、後片付けをすることは可能です。

後片付けしたい処理と、後片付け処理を近くに書いておけるのがメリットでしょうか。
例えば、長いワークフローだと Post step が遠くて分かりづらいかもしれません。

      steps:
      - name: Checkout
        id: checkout
        uses: actions/checkout@v4
      - name: Do
        run: |
          echo "TODO"
      - name: Post Action
        uses: srz-zumix/post-run-action@v2
        with:
          post-run: |
            echo "Post run step"

      # ...

      - name: Post
        if: always()
        run: |
          echo "Post run step"

そのような場合には、アクション化してしまうことも1つ手段かと思います。
しかし、残念なことに現状 composite action で Post 処理が書けません！
JavaScript action なら Post 処理を書けますが、複数のステップをまとめてアクション化する場合、composite が書きやすくそれを選択しがちです。

そこで post-run-action を使います！
実は composite で Post 処理が書けないことをなんとかしたくて作ったのがこのアクションなのです。

post-run-action を使うことで好きなタイミングで後片付け処理をセットできるようになります。私が作成したアクションの中でも業務でよく使っているアクションの1つになります。
ぜひ使ってみてください。

では。

GitHub Search と NotebookLM で自分の活動を振り返る

GitHub Search で昨日何してたっけ？を簡単に

gh-activity-report という gh 拡張機能をちょうど2年前くらいに作っていました。
こちらは GitHub の検索APIを gh search コマンドをつかって簡単に呼び出し、結果をレポートとして使いやすいように加工して出力する gh 拡張機能です。
gh search 使えばできることなので、わざわざ拡張機能を作る必要もないのですが期間の指定を「XX日前以降」とか「今月」とかがめんどくさかったのでこれを作りました。

例えば、昨日以降に更新した PR および Issue を検索する場合はこのようになります。

gh activity-report -d 1

これを gh search で書くとこのようになります。

gh search issues --include-prs --sort updated --author @me --updated ">=2025-04-21"

今日の日付に合わせて、コマンドを実行する必要があるのでちょっと面倒くさいですよね。
自分は下記コマンドで gh ar -d 1 で呼び出せるようにエイリアス設定をしています。
昨日何してたっけ？先週何してたっけ？と良くなるのでとても便利です。

gh alias set ar activity-report

GitHub Search の結果を定時報告に使う

さて、この gh-activity-report ですが gh search の出力フォーマット以外にも対応しています。gh コマンドをよく使っている人は --jq や --template オプションで出力加工ができることをご存知かと思います。 gh ar でやる場合は -- を使います。

gh ar -d 1 -- --json url --jq ".[].url"

単純な加工であればこれで十分ですが、ちょっと凝った出力にするのはやや面倒です。
--format オプションでいくつかパターンを用意してます。下記は一例です。

gh ar -d 1 --format markdown

gh ar -d 1 --format list

自分用に用意したものなので、お好きなフォーマットにする場合は前述のオプションか、json format で出力して結果をテンプレートエンジンなどで加工するとかもできると思います。
（私は kamidana を使った自作の kamidana-action をよく使っています）
gh の --json オプションは欲しいキーを指定しないといけなく、全部が面倒くさいのですが --format json なら簡単に全部出力できます。

gh ar -d --format json

私はこれらを組み合わせて、週報を自動で書かせています。

定期的なふりかえり

もともとこの拡張機能は活動の報告やふりかえりを目的として作成しましたが、これらは評価のためでもありました。

年に1回や半年に1回のタイミングだとどうしても記憶が曖昧になっていたり、直近の記憶が強くなりがちです。何やってたんだっけ？と毎回なります。
拡張機能で半年間の活動を出力させることもできますが、量がすごく多いのでそれで振り返るのもまた大変です。なので、月ごとにふりかえりをして記録をするという手段を取っています。これを自分リリースノートという名前でやっています。

（個人活動の方でも昔やってましたが、今は止まってます・・・）

自分リリースノートは自身の成長を観点としています。記録にはその観点フィルターを通した要約結果が記載されています。
今回、たまたま別の観点でふりかえりをしたいというきっかけがあり、もう一度 PR などの活動を見返す必要があったので、 NotebookLM に手伝ってもらいました。

NotebookLM で自分の活動をふりかえる

NotebookLM のソースとして gh-activity-report の出力を与えてみましたが、既存のフォーマットでは微妙だったので今回それを目的としたフォーマット（lens-with-body）を追加しています。私がブログを休んでいた期間の情報を出力すると以下のようなオプションになります。

gh ar --since 2023-04-01 -l 1000 --format lens-with-body --visibility public

どのようなフォーマットかというと「repository,number,url,state,title,createdAt,closedAt,updatedAt,author,body

」キーの情報を平文でただただ出力しているだけです。（長いので結果は省略）
既存のフォーマットは GitHub にそのまま書きやすい、人が読みやすいものが多かったのですが、今回のフォーマットは情報をダンプしている感じで人が読みやすいとは言い難いです。

出力した結果をソースとしていれて、どのような活動があったかまとめてもらいました。

なんかいい感じです。
AI の登場で情報をまとめて要約することが手軽になりましたね。

最初は全期間の１ソースだけ用意していたのですが、いまいち認識が甘かったので期間を分割して複数のソースとしました。単純にファイルサイズ（トークン数）というわけでもなさそうで、自分の PR の body がほとんど空っぽだったせいもあるような気もしています。
また、期間中の PR が月ごとに何件あったか調べてもらったら、微妙に一致しなかったりしました。

ちなみに、クセで目的とは関係なく挙動の実験をしてたら、このブログを書くのが２ヶ月遅れましたw　いろいろ調べてみるのは楽しいのですが、現時点での AI に合わせてもしょうもないのでキリにします。

AI 関連の変化は目まぐるしいので、上手に向き合っていけたらいいなと思ってますね。

私は AI 自体に詳しいわけでもなく、利用者としても初心者レベルなので、どちらも触れていって、自分の引き出しを増やせればと思います。

Gemini ではどうか？

Gemini でも同じことができます。
NotebookLM は json ファイルに対応しておらず、平文化する必要がありましたが Gemini だとそのまま json をソースにできるので楽でした。
目的にあわせて使いやすものを使うのが良いんじゃないかなと思います。

最後に

久しぶりブログ書いたけど、感想文みたいになっちゃいましたね。
最近は gh 拡張とか GitHub Actions のアクションを作ってることが多いので、そのへんも紹介できたらいいなと思ってます。では。

おひさ！

どうも久しぶりです。いつぶりの投稿でしょうか。約2年ぶりみたいですね。。
ここ数年は仕事が楽しくて社内での活動ばかりでした。
…というのも言い訳でして、一度途絶えた習慣を元に戻すのは大変だなと感じてます。
リモートワークになり通勤がなくなったのが一番の影響でしょうか。
出勤途中のスタバで記事を書くというのが習慣だったんですよね。
私物 PC を毎日リュックに入れて通勤してました。たまに会社の PC も持ち帰ることがあったので2台背負って電車に揺られる日もありました。信じられません。

最近は公式ドキュメント読めば OK だったり、 Zenn や Qiita などの記事を見ることや、
AI に聞くことが増え、個人ブログで情報を得る機会がかなり減ってしまいました。
（消しゴムの跡）
このへんはいろいろと思うところもあるんですよね。自分がこのブログを書く意味ってなんだろう、とか。

（テキトーなこと言ってます）

あと、これまでインターネット上の自分は本名の自分と別として活動してました。
まぁ隠してたわけではないですし、それなりの人に = あの人と認知されていることは知ってはいましたが、ここ数年でこの = 認知の範囲が広がったんじゃないかなと思ってます。
今までのように仕事成分抜いて投稿するってのもやりづらいなぁと勝手に感じております。

と、ネガティブな理由を書きましたが、それを書くために再び筆を執ったわけではないです。
最近、若手の活躍や意欲の高さにあてられて、自分も何かやりたくなったからですね
この2年間なにもしてなかったわけではなく、OSS活動はずっとやってきてましたし、公にやったことの話なら問題ないので、また書くことにしました。

書くペースはどうでしょうね？以前のように週一回更新はできないかもしれないですが、2年分の貯金でしばらく頑張ってみましょうかね。こういう形での不定期連載もありだろうか？
まぁまだしばらくこのブログで個人活動を続けようかと思います。今後ともよろしくお願いします。