#
613
2026/1/25
今日のトレンド

GitHub Copilot課金やTransformerの進化

どうも、マイクでーす。おはようございます!
2026年1月26日、月曜日の朝7時になりました。今週も「zenncast」始まりましたよー。通勤・通学中のあなたも、お家で準備しながらのあなたも、一緒にZennのトレンド記事をチェックしていきましょう。今日は、AI開発まわりからゲーム開発まで、かなり濃い技術ネタが揃ってます。

今日は全部で5本、記事を紹介していきます。CLI、Transformer、Gemini、Claude、Unityと、ちょっとした技術カンファレンス状態になってますので、コーヒー片手にゆるっと聞いてください。

まず1本目。
タイトルは「GitHub Copilot CLIは、gpt-5.2-codex xhighに複雑なレビューを依頼しても1回4円」。
いやー、ついにここまで来たか、っていう「お金の話」です。GitHub Copilotって、トークン課金じゃなくて「プレミアムリクエスト」、PR単位で課金されてるんですね。で、Copilot Pro+だと、1PRあたりざっくり4.2円くらい。ここが面白くて、「1PRでどこまでやれるか」が勝負なんですよ。
例えば、gpt-5.2-codex xhighに「このリポジトリまるっとレビューして」「このPR全体の設計チェックして」とか、かなり重めのことを頼んでも、基本は1PRで済む。サブエージェントを呼びまくっても、追加PRは消費しないという太っ腹仕様。
記事では、コスパを最大化するテクニックも紹介されていて、ポイントは「Copilot CLIを使え」というところ。VS Code拡張だとReasoning Effortが指定できないけど、CLIなら細かく指定できる。さらに、Agent Skillsで「全体を制御するスキル」を1個用意して、そこから単一ファイル作業をサブエージェントに振る形でコンテキストを分離する、っていう設計が推奨されています。
Coding Agentを使う場合も面白くて、1セッション丸ごと1PR扱い。長時間自律実行させても、同じ1PR。ただ、その代わりGitHub ActionsのCPU時間は別で食うので、そこは注意。
このあたりを踏まえると、「PR丸ごとの重いレビューでも、やり方次第で1回数円」という、かなり夢のある話になってます。生成AIの「頭の良さ」と「お財布事情」をどう両立するか、気になっている人は、感覚がだいぶ変わる記事だと思います。

。。。。

続いて2本目。
タイトル「Transformerアーキテクチャの変遷 ~Attention is All You Needからgpt-ossまで~」。
これは、AIモデル好きにはたまらないやつですね。あの有名な「Attention is All You Need」のTransformerが、その後どう進化していったのかを、ガッと俯瞰してくれている記事です。
筆者の整理がすごくきれいで、「本質的に大事な転換点は3つしかない」と言い切ってるんですね。1つ目がオリジナルのEncoder-Decoder型、2つ目がGPTのDecoder単体モデル、3つ目がBERTのEncoder単体モデル。それ以降は、ざっくり言うと「中身のパーツ交換」と「使い方の工夫」が中心、という視点です。
パーツ交換の代表例としては、活性化関数がReLUからGELU、さらにGLU系へ進化していった話。それから位置エンコーディングが、絶対位置から相対位置、そしてRoPE・iRoPEへ。長文対応には、このRoPEと、あとSparse AttentionとかBanded/Chunked Attentionが効いてくる、と。
正規化も、LayerNormからRMSNorm、Post-LNからPre-LNへと変わっていって、安定性と学習効率を良くしていく流れが解説されています。GQA(Grouped Query Attention)でKVキャッシュを減らしたり、Mixture of ExpertsでFFN部を差し替えて計算効率を上げたり、とにかく「ちょっとずつ全部盛りアップデート」して今のLLMがあるんだなぁ、というのがよくわかります。
「最近のモデル、名前だけ多くて何が違うのか分からん!」という人にも、どこを見れば違いが分かるのか、チェックポイントを教えてくれる記事でした。

。。。。

3本目はこちら。
タイトル「Google Gemini CLIをGoで再実装したら60倍以上速くなった」。
これはCLI好き、スクリプト職人には刺さりますね。公式のGoogle Gemini CLIはとてもよく出来てるんだけど、Node.jsランタイムの起動オーバーヘッドがあって、「コマンド打ってから始まるまで1秒くらい待たされる」という問題があると。
そこで筆者は、「じゃあ自分で作るか」と、コア機能をGoで再実装しちゃったんですね。それが「gmn」というCLI。結果どうなったかというと、起動時間が約0.01秒、なんと68倍高速。しかもバイナリサイズは約5.6MBで、公式の約200MBの35分の1。もうこれは別物。
面白いのは、認証まわりはあえて自前で持たずに、公式CLIで一度ログインして作られる `~/.gemini/` 以下のOAuth情報とMCP設定を、そのまま再利用する設計になっているところ。なので、無料枠やWorkspaceのCode Assist枠も、そのまま使える。
機能面はかなり割り切っていて、インタラクティブUIやOAuthフロー、APIキーやVertex AIの認証なんかは対象外。その代わり、非インタラクティブ用途、つまりスクリプトや自動化の中で「サッと1回だけ呼びたい」っていうケースに全振りしています。シンプルなプロンプト、ファイルやパイプ入力、JSON出力、モデル指定、MCPツール呼び出しなど、必要十分な機能をサクッと最速で叩ける感じ。
公式CLIへのリスペクトも忘れずに、「公式があってこその高速版」というスタンスなのが良くて、CLI周りの設計哲学としても読んでいて気持ちいい記事でした。

。。。。

4本目。
タイトル「Claude Code Skillsで実装からレビューまで全部自動化してみた」。
これは開発フロー自動化の実践レポートですね。Claude Code SkillsとGitHub Actions、それから `/review` コマンドを組み合わせて、実装からPR作成、レビュー、修正までをほぼ自動化してしまった、という内容になっています。
やっていることとしては、まず `.claude/skills/` 配下にcode-reviewスキルを定義して、「セキュリティ」「パフォーマンス」「可読性」「テスト」といった観点を明示。それに加えて、出力フォーマットも決め打ちしておくことで、毎回ブレないレビューをさせるようにしています。ここで重要なのが、descriptionに「レビューして」「このコード見て」みたいな“トリガーワード”を書いておくこと。これを書いておかないと、Skillsがうまく呼ばれない、というハマりどころが紹介されています。
GitHub Appをインストールして、Actionsのworkflowを組んでおくと、PRが作られたタイミングで自動レビューが走り、`@claude` へのコメントで修正コミットまで作ってくれる。さらにローカルから `/review` を叩いて、PR前のセルフレビューとして使うこともできる。
もちろん課題もあって、GitHub認証のループにハマったり、Actionが3〜4分待ちになってしまうこと、ClaudeはPro以上のプランが必要でAPI従量課金もあることなど、リアルな「痛み」もちゃんと書かれています。それでも、レビュー待ち時間が減る、一貫した品質が保てる、少人数や一人開発でも“相棒レビュアー”を持てる、というメリットは大きいと。
Tipsとしては、Skillsは小さく始めること、SKILL.mdを長くし過ぎないことなども紹介されていて、「完全自動化」よりも「人間の作業をいい感じに圧縮する」方向で使うのが良さそうだな、という印象でした。

。。。。

最後、5本目。
タイトル「なぜUnity(C#)は遅いといわれるのか」。
ゲーム開発界隈でよく聞く「C#は遅い」「Unityは重い」問題に、ちゃんと科学的に向き合ってくれる記事です。結論から言うと、「C#そのものが遅いわけじゃない。GCとリアルタイム性の相性の問題だよ」という話。
Unityでは、ヒープ確保量、いわゆるGC Allocが一定を超えるとGCが走って、そのフレームがガツンと止まる。これがFPS低下やカクつきの正体なんですね。特に、毎フレーム呼ばれるUpdateの中でnewしまくると、一気にGC Allocが増えて、定期的にGCが発生、結果としてゲームがプチフリーズする。
記事では、悪い例として「毎フレームclassを大量newするパターン」と、良い例として「structを使って事前確保した配列を更新する」「object poolで参照型を使い回す」といった設計が対比されています。後者だと実行時のGC Allocが0になって、フレームがものすごく安定するんですね。
C++との比較も丁寧で、C++はGCが無いぶんメモリ配置や実行モデルを完全にコントロールできて、高いフレーム安定性を得やすい。ただし、その代わりにメモリ解放の責任は全部開発者にあるので、設計難度もリスクも高い。一方Unity(C#)は、開発速度、安全性、人材面での有利さがあって、中小規模や2D、モバイルなどではとても強い。
本当に大事なのは「C#だから遅い」じゃなくて、「GCとメモリモデルを理解したコードを書いているかどうか」。UnityとC++、どっちが優れているかではなく、「どの用途にどっちを選ぶか」が大事だよ、という締めくくりになっています。これからゲームエンジン選ぶ人にも、今Unityで悩んでる人にも、かなり腹落ちする内容でした。

。。。。

そろそろお時間です。
今日は、GitHub CopilotのPR課金で高コスパなレビューをする話から、Transformerアーキテクチャの進化のまとめ、Google Gemini CLIをGoで再実装して爆速にした事例、Claude Code Skillsで実装〜レビューをほぼ自動化するワークフロー、そして「Unityは本当に遅いのか?」というメモリモデルの話まで、5本を駆け足でご紹介しました。
気になった記事があれば、番組のショーノートに詳しい情報を載せておきますので、ぜひチェックしてみてください。

「zenncast」では、番組の感想や、Zennで「こんな記事紹介してほしい!」というリクエストも大募集しています。あなたの開発環境の工夫や、AIツールの使い方なんかも教えてもらえると嬉しいです。

それでは、そろそろお別れの時間です。
今日も良い一日をお過ごしください。お相手はマイクでした。次回の「zenncast」でまたお会いしましょう。バイバーイ。

Related episodes

内容の近いエピソードを推薦しています