どうもー、おはようございます。マイクでーす。
FMラジオ風テック番組「zenncast」、本日も元気にお届けしていきます。
今日は2026年1月26日、月曜日の朝7時。
通勤・通学中のあなたも、自宅でまったりのあなたも、これから数分間、Zennのトレンド記事を一緒にチェックしていきましょう。
今日は全部で5本、ピリッと濃いめな技術記事を紹介していきます。
AI開発、LLMアーキテクチャ、CLI高速化、自動コードレビュー、ゲーム開発と幅広いラインナップなので、「あ、ここ気になるな」というところだけ拾い聞きしてもらってもOKです。
それでは、さっそく1本目からいきましょう。
。。。。
1本目。タイトルは
「GitHub Copilot CLIは、gpt-5.2-codex xhighに複雑なレビューを依頼しても1回4円」
GitHub Copilotって「高性能モデルをガンガン使ったら、とんでもない請求が来るんじゃないの…？」って不安になりますよね。
この記事によると、Copilotはトークン課金じゃなくて「プレミアムリクエスト（PR）」単位の課金なんです。で、Pro+プランだと、なんと高性能な「GPT-5.2-Codex xhigh」による複雑なPR全体レビューを1回投げても、だいたい4円程度。しかも、1回の指示がどれだけ長くて複雑でも、それは1PR扱い。さらに、その中でどれだけサブエージェントを呼び出しても、追加のPRは消費されない設計になっていると。
コスパよく使うコツとして、Copilot CLI側でReasoning Effortをちゃんと指定して「ここはしっかり考えて」「ここはライトにでいいよ」とメリハリをつけること、それから、Agent Skillsを使って全体のコントロールをしつつ、単一ファイル単位の作業をサブエージェントに振り分ける、という運用が紹介されています。
Coding Agentを使う場合は「1セッション=1PR」で、長時間自律実行してもコストは増えないけれど、そのぶんGitHub ActionsのCPU時間を食う、といったトレードオフにも触れています。
要するに、「高性能モデルは高いからなぁ」とビビりがちなんだけど、Copilotの課金設計をちゃんと理解して工夫すれば、かなり安く、むしろ積極的に使ったほうが得だよ、という内容ですね。PRレビューに時間かけてる人には刺さる記事だと思います。
。。。。
2本目。タイトルは
「Transformerアーキテクチャの変遷 ~Attention is All You Needからgpt-ossまで~」
AI界隈ど真ん中の記事です。
Transformerって、もう毎年新しいモデル名が増えすぎて、「結局なにがどう進化してるの？」ってなりがちですよね。この記事では、2017年の「Attention is All You Need」から、最近のgpt-oss、Llama4あたりまでの変遷を、どこが本質的に変わったのか、どこが“部品の改善”レベルなのかを整理してくれています。
大きなターニングポイントは3つ。
Encoder-Decoder型の初代Transformer、Decoderだけで構成されるGPT、EncoderだけのBERT。この3つが出そろったところで、実はアーキテクチャ的な「枠組み」はほぼ完成していて、その後は「でかくする」「賢く指示に従わせる」「MoEで効率よくする」といった改良がメインだ、という立場なんですね。
細かいところでは、活性化関数がReLUからGELU、そしてGLU系へ変わっていったり、位置エンコーディングが絶対位置からRoPE/iRoPEみたいな相対位置系になったり、正規化もLayerNormからRMSNorm、post-normからpre-normへ、などなど。
さらに、GQAでKVキャッシュを減らしてメモリ節約したり、Banded/Chunked attentionで計算量を削ったり、QK Normや線形層のバイアス削除など、地味だけど効く工夫も丁寧にまとめられています。
「Attentionそのもののアイデアは最初の時点でほぼ完成していて、その上に積み重ねている」という視点が面白い記事です。モデル名だけ追って疲れてきた人に、全体像をリセットするのにちょうどいい読み物ですね。
。。。。
3本目。タイトルは
「Google Gemini CLIをGoで再実装したら60倍以上速くなった」
これは“分かる人にはめちゃくちゃ分かるストレス”の解消記事です。
公式のGoogle Gemini CLI、自体はすごく良くできてるんですけど、Node.jsランタイムの起動に約1秒かかる。その1秒が、シェルスクリプトに組み込んでガシガシ回すときに、すごく気になるんですよね。そこで筆者は、コア機能だけをGoで書き直した「gmn」というCLIを自作しています。
結果、起動時間は0.01秒。公式CLIと比べて約68倍速い。バイナリサイズも5.6MBと、公式の約35分の1で、ランタイムも不要。
面白いのは、認証やMCPの設定は、公式CLIが作ってくれる `~/.gemini/` の中身をそのまま再利用している点です。つまり、公式CLIで設定した無料枠やWorkspaceのCode Assist枠が、そのままgmnからも使える。
その代わり、OAuthフローやTUIといったインタラクティブ機能はあえて入れず、「非インタラクティブでサクッと叩くこと」に全振りしている設計。HomebrewやGo installで入れられて、プロンプト投げ、ファイル添付、パイプ入力、JSON出力、モデル指定、MCPツール呼び出しまで、必要なところだけ高速にこなす、いわば“痒いところ専用の軽量クライアント”という感じです。
公式CLIへのリスペクトもきちんと書かれていて、「好きだからこそ、別の用途に最適化したツールを作りました」という気持ちが伝わる記事でした。普段からGeminiをシェルから叩いてる人は、要チェックだと思います。
。。。。
4本目。タイトルは
「Claude Code Skillsで実装からレビューまで全部自動化してみた」
こちらは、コードレビュー自動化の実践録。
Claude Code Skillsと、GitHub Actions版のClaude Code Action、それにローカルで使う/reviewコマンド。この3つを組み合わせて、「実装 → PR作成 → レビュー → 修正」までを、ほぼ自動で回す仕組みを作った手順が紹介されています。
キーになっているのが、`.claude/skills/code-review/SKILL.md`。ここに、セキュリティ、パフォーマンス、可読性、テストといった観点や、レビュー結果の出力フォーマットを定義しておきます。特におもしろいのが、descriptionに「レビューして」「このコード見て」みたいな、“トリガーワード”を具体的に書くのが重要という話。これを書いておくことで、Claudeが「これはレビューの文脈だ」とちゃんと理解して動いてくれるわけですね。
GitHub Appを導入して、ANTHROPIC_API_KEYを設定しておくと、PRを作ったタイミングで自動レビューが走り、@claudeがコメントや修正提案をしてくれる。さらに、自動修正コミットまでしてくれるフローも構築できます。ローカルでは `/review` コマンドを叩いて、即座に確認できるので、「人間レビューの前にAIでセルフチェック」みたいな運用もやりやすい。
一方でハマりどころも正直に書かれていて、descriptionの文言調整に地味に手間がかかったり、GitHub認証がループしちゃうケースがあったり、レビューに3〜4分かかること、有料プラン前提なのでコスト面の意識も必要だったりします。
それでも、レビュー待ち時間が減る、一貫した品質になる、自動修正とセルフレビューがしやすい、というメリットが大きくて、一人開発とか小規模チームには特に相性がいいと結論づけています。Skillsは「小さく作って育てる」「SKILL.mdは短く保つ」といった、運用のコツも参考になりますね。
。。。。
5本目。タイトルは
「なぜUnity(C#)は遅いといわれるのか」
ゲーム開発界隈でよく聞く「C#は遅い」「Unityは重い」問題に、ちゃんとメスを入れてくれている記事です。
結論からいうと、「言語そのものが根本的に遅いから」ではなくて、ガーベジコレクション、つまりGCを前提としたメモリ管理と、ゲームのリアルタイム性の相性が悪い、という話なんですね。
Unityでは、ヒープへのメモリ確保量、いわゆるGC Allocが一定量を超えるとGCが走ります。GCが走ると、そのフレームが一瞬止まってしまって、いわゆる「カクッ」としたスパイクになる。特に、毎フレーム呼ばれるUpdate内で、毎回newしてオブジェクトを作りまくると、GC Allocが増えまくってフレームレートが不安定になっちゃう。
この記事では、classを毎フレームnewする悪い例と、structやオブジェクトプールで再利用する良い例の対比が紹介されていて、「同じC#でも書き方次第でここまで変わる」というのを具体的に見せてくれます。適切に再利用すればGC Allocがほぼ0になって、FPSも安定する。
じゃあC++はなぜ速いと言われるのか。これは「GCがないから魔法のように速い」というより、メモリ配置や実行モデルを開発者側でかなり細かく制御できるので、フレームの安定性を突き詰めやすい、という特徴の話。ただ、そのぶん安全性や保守性のコストは高くつきます。
Unity(C#)は開発速度と安全性が高くて、中小規模のゲームやインディー開発にすごく向いている。一方で、超大規模・超高負荷のタイトルでは、C++でガチガチに作るほうが向いているケースも多い。どっちが“絶対に優れている”ではなくて、「用途に応じたトレードオフ」だよ、という結論で締めくくっているのが、すごく誠実だなと思いました。「Unityは遅い」って一言で片付けてしまう前に、一度読んでおきたい記事ですね。
。。。。
というわけで、今日は5本の記事を紹介してきました。
おさらいしておきます。
まずは、GitHub Copilot CLIの課金モデルをちゃんと理解すれば、高性能モデルでも1回4円程度で複雑なPRレビューを回せるという話。
次に、Transformerアーキテクチャの歴史を、Attention is All You Needからgpt-ossまで俯瞰して、「枠組みは早い段階で完成していた」という視点をくれる記事。
3本目は、Google Gemini CLIをGoで再実装して、60倍以上高速な「gmn」を作った、CLI高速化の実践例。
4本目は、Claude Code SkillsとGitHub Actions、/reviewコマンドを組み合わせて、実装からレビューまでほぼ自動化しちゃったワークフロー。
そして最後は、「なぜUnity(C#)は遅いと言われるのか」をGCとリアルタイム性の観点から分解し、C#とC++の使い分けを整理した記事でした。
気になった記事があれば、このあとゆっくり本文を読んでみてください。詳しい情報や元記事へのリンクは、番組のショーノートにまとめてあります。
「zenncast」では、番組の感想や、「こんなテーマを取り上げてほしい」「この技術で悩んでます」といったメッセージも募集しています。
ラジオネームを添えて、ぜひ気軽に送ってください。技術の沼トーク、一緒に深めていきましょう。
それでは、そろそろお別れの時間です。
今日も聞いてくれて、ありがとうございました。
次回の「zenncast」で、またお会いしましょう。
お相手はマイクでした。それでは、いってらっしゃい。