どうもー、おはようございます。マイクです。
「zenncast」金曜の朝のお時間がやってまいりました。
今日は2026年2月20日、金曜日の朝7時。みなさん、通勤・通学中の方も、これから一日スタートの方も、ゆるっとお付き合いください。
今日もこの時間は、技術系メディアZennで話題になっている記事をピックアップしてご紹介していきます。AIまわりのネタ多めでお届けしますので、「最近の動き追えてないな〜」という方は耳だけ貸してもらえればOKです。
さて今日は、全部で5本の記事をご紹介していきます。どれも今っぽいテーマばかりなので、ぜひ気になったキーワードをメモしながら聴いてみてくださいね。
まず1本目。
タイトルは「話題のmicrogptを早速試してみる」。
あのkarpathy氏がGistで公開した、約200行のPythonだけでGPTの仕組みを実装した「microgpt」。いわゆる「最小構成のGPT」の学習と推論のサンプルなんですが、これを実際にDocker環境で動かしてみた、というレポート記事です。著者の方は、自分で俳句を10句だけ用意して、それを学習データにしてみたんですね。で、学習させて生成してみたら、数分で推論は終わるんだけど、出てくる俳句が「ほぼ元の俳句のコピー」で、ぜんぜん多様性がないと。これは「データが少ないと、モデルはこうなるんだよ」という、ある意味すごく正直な結果なんですよね。ただ、コード自体は一般的な機械学習の知識があれば追いやすくて、層の数とか埋め込み次元、コンテキスト長、ヘッド数、temperatureなんかをいじりながら、「このパラメータ変えると挙動こう変わるんだ」というのを体感できる作りになっている、と。著者は最後に、「AI時代だからこそ、中身への興味を持って仕組みを理解することが、いいプロダクトを作る近道だ」というメッセージで締めていて、まさに“ブラックボックスをそのまま崇めない”スタンスがいいなと感じました。自分で小さいモデルをいじってみると、普段触ってる巨大モデルのありがたみもわかるんですよね。....
続いて2本目。
タイトルは「PRのレビューが追いつかない！もう人間がボトルネックなので、気合いではなく仕組みで少しずつなんとかしていく」。
ここしばらくで「わかる〜」ってうなずく人、多いんじゃないでしょうか。AIエージェントのおかげでPRを出すのはめちゃくちゃ簡単になった一方で、「レビューする人間の時間が足りない」という、別のボトルネックが出てきている、という話です。特に、typo修正とか依存ライブラリの更新みたいな、リスクは低いけど数が多いPRがキューを占拠しちゃって、本当に大事なPRのレビューが後回し…みたいな現場が増えていると。この記事では、その状況に対してGitHub ActionsとAIを組み合わせた仕組みで対処しています。具体的には、AIが「差分の行数」ではなく「影響範囲」を見て、size/XS〜XLのラベルを自動で付けてくれる。それからAIがコードの品質やバグ、セキュリティの観点でレビューして、問題なければその場でApprove。そして、`size/XS`かつAIがApprove済みで、CIも通っているPRだけは、自動でマージしちゃう。さらにブランチ保護ルールも、「コードオーナーが必ずレビュー」から「Approveが1件あればOK」に変えて、AI承認を正式な一票として扱っているんですね。ポイントは、いきなり全部を任せるんじゃなくて、XSみたいな小さい変更から信頼を積み上げていくことと、「行数じゃなく影響範囲」で判断させること。それから、レビュー基準をMarkdownで明文化していて、AIも人も同じルールを参照できるようにしているところ。このあたりが、AI前提の開発プロセスにアップデートしていくうえでの「現実的な一歩」だなと感じました。人間の脳みそは、でかいPRのために残しておこう、という発想ですね。....
3本目いきましょう。
タイトルは「個人開発のAIエージェントに『Bun + Hono + Drizzle + SQLite』が最強な理由」。
AIといえばPython、というイメージの人もまだ多いと思うんですが、この記事では「2026年のAI開発の本質は“LLMという巨大なAPIをどうオーケストレーションするか”であって、必ずしもPythonじゃなくていいよね」という立場から、TypeScriptのスタックを推しています。具体的には、Bun、Hono、Drizzle、SQLite。この4つを組み合わせると、個人開発のAIエージェント作りにはほぼ無敵なんじゃないか、という話です。Bunは、TypeScriptをほぼ設定なしで爆速実行できるので、プロンプトをいじったりロジックを微調整したりという試行錯誤がとにかく早く回せる。Honoは、いわゆるRPCモードによってバックエンドの型がそのままフロントエンドまで貫通するので、「LLMの出力はふわふわしてるけど、それ以外の入出力と通信は100％型安全に守ろう」という設計がしやすい。状態管理の部分はSQLiteで、サーバーの運用いらず、バックアップも簡単、最近はベクトル検索の拡張もあるので、RAG的なことも1ファイルDBで完結できちゃう。それをDrizzle ORMと組み合わせて、スキーマとTypeScriptの型をきっちり一致させることで、DB操作のミスをコンパイル時に潰す。PythonのFastAPIやLangChainのスタックと比べると、「起動と実行が速い」「型安全」「運用コストが低い」「エッジデプロイもしやすい」というところを強調していて、「特定のPythonライブラリを直叩きする必要がないなら、この構成が今のベストだ」と結論づけています。次回の記事では、このスタックで実際にAIエージェントを使ったプロダクトを半日で作ったプロセスを紹介するそうで、続きも気になりますね。フロント寄りの人がAIエージェント開発に入っていくための、いい入口にもなりそうです。....
さあ、4本目。
タイトルは「Codex 5.3 と Opus 4.6 どう使い分ける？実務で使って分かったこと」。
AnthropicのOpus 4.6と、OpenAIのCodex 5.3。この2つ、どっちがいいの？って「勝ち負け」で捉えがちなんですが、著者は「どちらかじゃなく役割を分けて両方使うのが正解」と言っています。実務でガッツリ試した結果としての使い分けですね。Opus 4.6は、「要件定義とか設計が得意な考える系」。Figmaのデザインなんかを見せると、そこからデザイン意図をきちんとくみ取ってくれたり、「ここ仕様抜けてますよ」と指摘してくれたり、日本語のドキュメントも自然で読みやすく書いてくれる。一方、Codex 5.3は「コードベースを理解して、堅実に実装してくれる実装系」。抜け漏れの少ないコードを書いてくれて、リポジトリ全体を頭に入れながら手を動かしてくれる感じですね。著者はCursorを使っていて、1つのスレッドの中でモデルを切り替えながら進めるワークフローを紹介しています。流れとしては、まずOpusでREADMEや仕様書を作ったり、要件を詰めきるフェーズを担当させる。そのあと、具体的な実装はCodexにバトンタッチ。そして仕上げに、両方のモデルでダブルチェックをかける。こうすることで、生産性も品質も一番高くなった、と。人間のチームでも「設計の得意な人」と「実装の速い人」がいるように、LLMのチーム編成を考える、という発想がとても面白いなと思いました。ひとつのIDEでモデルを切り替えられる環境がある人は、ぜひ「役割分担」という視点で試してみるといいかもしれません。....
そして最後、5本目。
タイトルは「階層的 RAG (Hierarchical RAG) の実装」。
RAG、つまりRetrieval-Augmented Generationの発展形として、「階層的RAG」を実装してみた、という記事です。題材にしているのはHHKBの取扱説明書。まず、このマニュアルをMarkdownの見出し構造ごとに分解します。大きな見出しごとにまとまったセクションを「親チャンク」、そこからさらに段落単位にわけたものを「子チャンク」として扱う、いわゆるSmall2Big戦略です。検索自体は、細かい「子チャンク」をベースに行うんですが、回答を生成するときには、より広い文脈を持った「親チャンク」をモデルに渡す、という構成になっています。さらに、ベクトル検索で取ってきた親チャンクを、そのまま信じるのではなく、日本語のCross-Encoderベースリランカーで再評価して、より関連性の高いものを選び直すことで、精度を上げています。使っているのは、hotchpotchの日本語リランカーの小さいモデルですね。また、チャンクの先頭にH1〜H5レベルの見出しをつないだパンくずリストを付けて、「この段落はマニュアルのどの位置の話なのか」という文脈をモデルに教える、Contextual Chunkingも合わせ技で採用しています。PDFからMarkdownへの変換にはPyMuPDF4LLMを使っていて、30文字以下の短すぎるチャンクはノイズとみなして除外。実装してみてわかった難所として、階層構造そのものを作ることよりも、「元ドキュメントの特性に合わせて、どういうルールでチャンキングするか」を設計するところが一番悩ましい、とまとめられています。実用的な日本語RAGをやりたい人には、かなり参考になる具体例になっていました。
というわけで、今日は5本の記事をご紹介しました。
おさらいすると、まずは200行のmicrogptでGPTの仕組みを自分の手でいじってみよう、というお話。それから、AI時代のPRレビュー地獄を「気合」ではなく「仕組み」でさばいていく話。3本目は、PythonにこだわらずBun + Hono + Drizzle + SQLiteでAIエージェントをオーケストレーションしていこう、というTypeScript推しのスタック紹介。4本目は、OpusとCodexを「どっちが上か」じゃなく「考える係と実装係」で役割分担して使う実務ノウハウ。そして最後が、マニュアルの階層構造を活かしたHierarchical RAGで、より賢く検索・回答させる実装例でした。
気になった記事があった方は、番組のショーノートに詳しい情報を載せておきますので、ぜひあとでチェックしてみてください。zenncastでは、みなさんからの番組の感想や、「こんなテーマを取り上げてほしい」というリクエストもお待ちしています。普段どんなふうにAIや開発ツールを使っているのか、現場の声もぜひ教えてください。
それでは、そろそろお時間です。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。
今日も良い一日をお過ごしください。