2024年のエンジニア活動の振り返り
去年も知っている方たちが2024年の振り返りを書いているのを見て、もう2025年になってしまいましたが自分も2024年を振り返ってみようと思いました。
登壇・執筆
今年はカンファレンスにCfPを出す機会はなかったですが、勉強会で3回発表したのに加えて、会社の生産性向上チームとしてSoftware DesignのGitHub Actionsの特集を執筆をさせていただく機会がありました。
TechBrewとCI/CD TestNight、SDへの寄稿はGitHub Actions関連、4月のProductivity MeetupではOSSのリリース自動化について発表しました。個人・チームともにここ数年はGitHub Actionsに注力していたので、それについて発表できる機会が頂けて良かったです。
生成AI
今年自分の中でもっとも影響を受けたのは生成AI（特にLLM分野）でした。去年までのGPT-3.5 Turboの頃までは全然興味がなかったのですが、GPT-4oが登場して画像認識できたりJSONで出力が可能になったことでOCRの代替になり得る能力を既に備えていることが分かり、興味が湧いてきました。
自分は以前から github.blog/changelog を毎朝見続けているのですが、今年あたりからGitHub Copilotの関連機能のアップデートや機能解説の記事が明らかに増えました。2024年の前半頃はLLMに興味がなかったので「RAG」などLLMに関する用語を理解しておらず、内容に付いていけないので面白くないアップデートが増えたなぁと思っていました。
同じ頃、社内でもLLMに関する話題が増えてきたのでですが、やはり用語の意味が分からないので話についていけないことが増えました。さすがに面白くなかったのでLLMの仕組みや当時流行っていたRAGなどの周辺技術についてちょっと学んでみたところ、GitHub Copilot関連のアップデートも理解できるようになってLLM自体にがぜん興味が出てきました。
自分のPCでLLMを動かす方法（ローカルLLM）と、それを使ってGitHub CopilotのようなことができるContinueというVSCode Extensionについて調べていたときのスクラップです。記事にしようかなと思っていましたが結局スクラップで満足しちゃってますね。
自分が所属しているサイボウズでは「大人の体験入部」という最長で三ヶ月の間まで別のチームに短期異動できる制度があるので、これを使わせてもらい社内でLLMの活用に取り組んでいるチームで10月から仕事をしています。自分は今のところLLMの仕組みやモデルの学習などには興味はあまりなく、ChatGPTのようにLLMに色々な仕事を投げられるツールであったり、既存のサービスやアプリにLLMを組み込む方法の方に興味があります。
思い返すと自分がここ数年CI/CDに興味を持っていた理由は、CI/CDを活用することでソフトウェア開発をより効率的にできると信じていたからでした。一方LLMもGitHub Copilotがコーディング向け用途として開拓したことで既に多くのエンジニアはこれを利用しており、エンジニア以外の職種の仕事もLLMを活用することで今後大きく効率化されていくでしょう。ソフトウェア開発全体として見るとCI/CDよりも大きく効率化に寄与すると信じています。
CI/CDからLLMへの興味の移り変わりは同僚からも結構驚かれたのですが、自分としてはソフトウェア開発の効率化への興味という点においてLLMへのシフトは一貫性のある移り変わりだったと思っています。
別の理由として、2024年のGitHubのアップデート全体を振り返ってみても今年はGitHub Copilotとセキュリティ関連のアップデートばかりで、GitHub ActionsはもうGitHubから注力されていない感じで退屈でした[1]。GitHubのファンボーイとして注力されている機能に興味を持つという点でも、実は昔から自分のスタンスは変わっていなかったのかなと思います。
寄付
去年に引き続き、今年もOSSへの寄付を続けています。寄付に関してのスタンスは去年の振り返り記事を参照してください。
今年もjs/ts界隈で活躍されている方々やお世話になっているツールを中心にいくばくかの寄付をしました。
新しく寄付を開始したツールとしてはBiomeがあります。ESLint v9騒動からBiomeを試してみたのですが、Linter, Formatterはこれでいいじゃん感がありとても便利に使っています。
OSS活動
今年は結構草がまばらになってしまいました。7月までの前半は後述のgh-actions-scannerという新しいツールをプライベートリポジトリで仕込んでいたのでまあまあ草が生えていますが、7月以降はコードを書く代わりにLLMの勉強やツールを色々試していたのと、10月からFactorioのDLCが発売されて夜な夜なそればかり遊んでいたので荒廃しちゃってますね。
（youtubeで見ていたFactorio配信者の視聴者参加型マルチプレイに参加するのが面白すぎた）
10月頃からCopilot Workspaceが使えるようになったことをきっかけに、LLMでOSS開発をどれだけブーストできるかを色々と試してます。この手のツールのやってみた系記事はTODOアプリかLPを0→1で作成する例ばかりですが、既にそこそこのコードベースが存在する状況でCopilot Workspaceがどの程度やってくれるのかを記録の意味も含めてスクラップに残してます。これもいつか記事にしたいところですが、LLM界隈は進化が早すぎて数ヶ月もしたら状況が一変しているのですぐに陳腐化しちゃいそうなのですよね。
Kesin11/gh-actions-scanner
今年新規に作っていたツールで、今年前半に結構頑張っていたけど結局作り切れずに中途半端で止まってしまってます。やりたかったのはGitHub Actionsのパフォーマンス版のtrivyという感じで、スキャンすることでGitHub Actionsの実行時間の観点から最適化できるポイントを見つけるツールです。
GitHub Actionsに関してはチョットワカルので仕事で他チームのGitHub Actionsの改善のお手伝いをすることがあるのですが、色々なリポジトリを見てきたことで見るべき改善ポイントが結構分かってきました。それをドキュメントにまとめてもよいのですが、ツールに落とし込めればもっとスケールできると思って開発を始めました。
GitHub Actionsのパフォーマンスに問題がある場合、キャッシュが上限の10GBに到達していないかや、アーティファクトのサイズが大きいとアップロードに時間がかかる古い actions/upload-artifact@v3[2] を使っていないかなどが真っ先に見るポイントとなります。
gh-actions-scannerはAPIから得られたデータとワークフローのyamlを付き合わせることでこれらの問題点を自動的に検出します。これらの主要な問題点は現時点でも既に検出可能で、READMEにサンプルの実行結果を載せてあります。
という具合でPOCレベルは超えたのですが、半年ぐらいでモチベが続かなくなってしまって最近は完全にストップしてしまいました。というのも、会社の中で特にGitHub Actionsの利用が多いリポジトリについてはgh-actions-scannerの開発中に検出できる項目が社内の優秀な方々によってほとんど改善されてしまったため、完成まで持っていくモチベがなくなってしまいました。単純に開発に時間をかけすぎてしまったというのもあります。
良かったこととしては、GitHub ActionsのAPIの結果の解析とワークフローのyamlを組み合わせることで静的解析だけでは分からない情報を得ることが可能であると分かりました。今後actions-timelineやCIAnalyzerなどにこのノウハウを活かすことができると思っています。
Kesin11/gha-utils
gh-actions-scannerでのコアロジックの1つであったGitHub ActionsのAPI解析とワークフローyamlのパース処理を独立させたパッケージです。これもとりあえず別パッケージに分離したぐらいでREADMEすら書けていないのですが、一応jsr.ioにpublish済みです。
GitHub ActionsのAPIクライアントなんかは毎回似たようなコードを書いているので、gha-utilsにまとめることでgh-actions-scannerとactions-timelineで共有することにしました。
Kesin11/actions-timeline
去年リリースした後にTechBrewの登壇で発表した効果なのか、おかげさまでGitHubのStarがじわ伸びし続けています。
社内でもGitHub Actionsを大規模に利用しているリポジトリで使われていたり、最近は勉強会の懇親会でもactions-timelineを使っていますと声をかけて頂く機会も増えてきたりと、自分を代表するOSSになってきました。
今年は2月にリリースしたv2.1.0でローカル実行可能なCLIを追加した以降は特に開発できていないのですが、依存関係のアップデートなどのメンテは継続しています。
今年はgh-actions-scannerの方で時間をかけられなかったのですが、先述したようにそっちで得たノウハウを活かしたいですね。具体的には社内で利用してくれているチームからもComposite Action内での内訳が表示されないのは不便というフィードバックをもらっているので、何とかしてこのissueを解決できないかなと思っています。
Kesin11/CIAnalyzer
CIAnalyzerはactions-timelineよりも前のプロダクトで、最低でもBigQueryのセットアップの手間がかかることから今となってはあまり利用する人はいないだろうと思っていたのですが、意外にもそこそこ使ってくれているところもあることが分かりました。
actions-timelineやCIAnalyzerみたいなタイプのプロダクトはOSSよりも社内のプライベートなリポジトリで使われるケースが多いため、実際にどれだけ使われているか実は自分もあまり把握できていないのですよね。なのでこういうブログを書いて頂けるとすごい嬉しいです。
CIAnalyzerもactions-timelineと同様に今年はほぼメンテが中心で、CJSからESMに移行したりBiomeを導入したりなど内部的な更新が主でした。実際に使って頂けている事例を見させてもらってモチベが少し上がったので、来年はAIによるコーディングツールの実験がてらS3対応あたりをやろうかなと思っています。
v6.2.0でエクスポート先として初めてBigQuery以外のGCSに対応させたのですが、これはGitHub Copilot Workspaceの実験台としてちょうどよいタスクでした。CIAnalyzerは既にそこそこのコードベースとテストが存在するので、0->1ではなくて1->10の段階において昨今のAIコーディングツールがどの程度使い物になるのかを見るのに丁度よいです。
それ以外
GitHub Actionsのワークフローのyamlの中でReusable WorkflowやComposite Actionsを多用していると、実際にどういうステップが実行されるのか追うのが大変なのでそれらを全て展開してどういうステップが実行されるのかを表示してくれるCLIツールです。これも2024年にリリースしてました。
自分も会社でGitHub Actionsの最適化のお手伝いをする際にちょっと使ったぐらいなのですが、 deno compile で生成した実行バイナリをgh extensionとして配布するというちょっと面白い試みをしています。この手のツールは配布しやすい実行バイナリを作成できるGoやRustが一般的ですが、Denoでもできるぞという例でした（ただし80-90MBぐらいのサイズになるので優位性があるとは言えない）。
ts-junit2jsonはコードベースが小さくもう完成しきってるので今年も新機能は追加していませんが、npmのprovenance対応やjsr.ioへの公開などエコシステムの新機能に対応する実験場として今年も活躍してくれました。後はNode.js v22対応や node:test がスナップショットテストに対応してくれたのでJestを外したりなんかもしてます。
Node.jsの標準機能だけでできることが増えているので依存パッケージを減らすことができて、ts-junit2jsonは年々スリムになっていってます。
-
特にactions-runner-controllerが使っている新しいself-hosted runner用のAPIの公開はいつなんですかね？ARCのソースコードからあれがpreview版のAPIを使っていることは知ってるんだぞ。 ↩︎
-
ちなみにこの記事を書いている actions/upload-artifact@v3 は非推奨で2025/01/30に@3は利用できなくなるという告知が出ています ↩︎
Discussion