どうも、マイクです。おはようございます。
九月十四日、月曜日の朝七時を少し回ったところです。ここからの時間は「zenncast」、きょうも最新のテック系トピックを、Zennのトレンド記事からピックアップしてゆるっとご紹介していきます。通勤・通学のおともに、コーヒー片手に、最後までお付き合いください。
きょうはお便りコーナーはお休みで、そのぶんガッツリと記事を紹介していきます。
きょうご紹介する記事は、全部で五本です。脳科学とAIの話から、開発環境ハック、ローカルLLM活用、AWSの新しい開発スタイル、そして強化学習の入門まで、かなり盛りだくさんなラインナップになっています。
まず一本目。
最初は「ハエの脳の配線図」のお話です。これ、インパクトすごいです。
ハエ一匹ぶんの脳の「配線図」、つまり、どの神経細胞がどこにつながっているかという完全な地図が、なんとおよそ四十年かけて整備されてきて、ついに感覚から運動まで一匹ぶんそろった、という内容なんですね。しかも、それをもとに、個人レベルでもシミュレーションして“動かせる”段階にまできている、と。
最新の全脳モデルでは、だいたい千五百万個くらいあるシナプスの強さを、「学習で調整する」というよりは、電子顕微鏡で観察して数えたシナプスの数から、ほぼそのまま決めてしまう、というアプローチを取っています。人間側でチューニングしたパラメータは、ほぼ一つだけ、という割り切り。その状態にもかかわらず、摂食行動とか、毛づくろいの回路に関する予測の、およそ九割が実験結果と一致した、というのがすごいところです。
一方で、別の研究からは、「配線図だけあっても、脳のふるまいは一意には決まらない」ということも示されていて、細胞ごとの性質とか、ほんの少しの活動データを足してあげないと、現実に近い挙動にはならない、という話も紹介されています。よくある「ハエの脳でゲームをプレイさせてみた」みたいなデモも、実は“脳”と“体”をどう対応づけるかの部分を、人間のほうでかなり設計しているのが実情ですよ、という冷静な指摘も入っています。
ここからAIへの話につながっていきます。動物の脳って、進化の過程で作られてきた配線構造そのものに、ものすごくたくさんの情報を持っていて、その上に必要最小限の「学習」が乗る、という構造になっている。一方で、いまのディープラーニングのAIは、ほとんど全部を「学習した重み」に頼っていて、生まれつきの構造、いわばハードウェアに近い部分に、そこまで情報を持たせていない。
ハエの研究は、「じゃあAIは、どこまでを“生まれつきの構造”としてあらかじめ組み込んで、どこから先を学習に任せたらいいのか？」という、新しい設計の問いを突きつけているんじゃないか、という論点に到達します。
今後はマウスの脳でも、配線図と活動データを組み合わせながら研究が進んでいくだろう、という見通しも語られていて、脳科学とAIがいよいよ本格的に交差し始めたな、というワクワク感のある一本でした。
。.。.。.
続いて二本目。
ここからは開発環境ハック系のお話です。
テーマは、git worktree、それからターミナルマルチプレクサの「Herdr」、そしてClaude Code、この三つを組み合わせて、「複数のAIエージェントを並列で動かしつつ、ブランチごとの作業をちゃんと整理して進める」ための開発環境作りのコツを紹介している記事です。
ざっくりいうと、git worktreeを使って、ブランチごとに作業ディレクトリを分けておきます。そのうえで、Herdrがそれぞれのディレクトリを、ターミナルのペインとしてきれいに並べてくれる役。さらにClaude Codeが、Agent Skillという仕組みを経由して、gitやHerdrのコマンドを叩きます。これによって、worktreeの作成や削除から、ターミナルペインの分割、配置までを自動でやってしまう、という構成です。
もう一歩踏み込んでいるのが、Claude Codeの「SessionStart hook」とシェルスクリプトを組み合わせているところです。これで、「ひとつのリポジトリは一画面にまとめる」というポリシーに寄せて構成していて、同じリポジトリのworktreeを、ひとつのSpaceの中に横三列まで並べる、というレイアウトにしています。
それぞれのペインには、「どのブランチなのか」が色付きのラベルで表示されていて、さらにそこに紐づいたエージェント名も付けておく。こうすることで、「このペインはこのブランチで、このAIエージェントが作業中」っていうのが、一目で分かるようになっているんですね。
結果として、ブランチごとにバラバラに作業していると、ごちゃつきがちな状態を避けつつ、「AIにこっちのブランチを任せているあいだに、自分は別ブランチを触る」といった並列開発がかなりやりやすくなる。AIエージェントを複数走らせる前提のワークフローを、gitの機能とターミナル、そしてClaude Codeでうまく支えている実践例として、とても参考になる内容でした。
。.。.。.
三本目は、ちょっとオピニオン寄りの記事です。
テーマは「クラウドLLMのコスト問題にどう向き合うか」。
筆者の方は、Claudeのようなクラウド上の大規模言語モデルを使ってコードを生成しつつ、十七万行規模のプロダクトのコードレビューまで同じLLMにお願いしようとすると、トークン代がかなりシャレにならない、という問題に直面しています。
そこで取ったアプローチが、「自分のPCに載っているGPUを活かして、ローカルで動くレビュー専用モデルを用意する」というものです。具体的には、Ollama上で「qwenにーてんごハイフンコーダー、じゅうよんビー」というモデルをベースにして、「git diffを食わせると、重大な不具合候補だけをJSONで返す」という、かなり用途を絞ったレビュー用プロンプトを自作して運用しています。
検出対象も、かなりピンポイントです。「データ損失につながりそうな変更」「クラッシュの原因になりそうなところ」「セキュリティ上の問題」「非同期処理まわりのバグ」など、本当にクリティカルなものに限定。逆に、「コーディングスタイルがどう」「命名がイマイチ」といった指摘は、ルールとして禁止する、というのが面白いポイントです。
ローカルのモデルなので、賢さそのものはクラウドLLMに比べるとどうしても劣る。ただ、用途を「重大なバグの検出専用」にギュッと絞り込むことで、十分に実用レベルに持っていけるし、なによりトークンコストを気にせずに回せる。結果として、一人で開発していても、AIが生成したコードを安心して取り込めるワークフローが作れた、というのがこの記事の結論になっています。
「ぜんぶを一番強いクラウドLLMに任せる」のではなく、「何をクラウドに、何をローカルに分担させるか」を設計する視点が伝わってくる内容でした。
。.。.。.
四本目。
ここからはAWSとモノレポ開発の話題です。
テーマは「エヌエックス・プラグイン・フォー・エーダブリューエス」、Nx Plugin for AWSの紹介と、それを実際に触ってみた上でのオピニオンに近い記事です。
このプラグインは、「自然言語で指示すると、Reactのフロントエンド、API、データベース、認証、そしてCDKによるインフラのコードまで、いい感じに組み合わせてくれる」と説明されることが多い仕組みです。筆者の方は、これを実際に使って、フィードバック管理アプリを作ってみることで検証しています。
ここで強調されているのは、「プロンプトを一発投げるだけで完成アプリが魔法のように出てくる」という話ではない、という点です。本質は、レビュー済みのジェネレーター群があらかじめ用意されていて、それがフロントエンド、API、データベース、認証、そしてCDKによるインフラの共通の土台を作ってくれること。そして、その複数プロジェクトにまたがる構成を、Nxのグラフで一元管理できる、というところにあります。
記事では、「コーディング・エージェント」、つまりAIが何をどこまで自動化するのか。逆に、Nx本体は、生成が終わったあとのプロジェクト群を、どう管理していく役割なのか。そして「コネクション」ジェネレーターと呼ばれるものが、どの部分を自動でつないで、どの部分は人間がちゃんと書く必要があるのか。こうした境界を、かなり丁寧に分解して説明しています。
もうひとつ重要なのが、生成される構成が、かなり「厚い」本番寄りである、という指摘です。Webアプリケーションファイアウォール、WAFだったり、鍵管理のKMS、認証のCognitoなど、AWSのいろんなマネージドサービスを含んだ、ちゃんとした本番運用を想定したスタックが出てくる。だからこそ、「料金どうなるんだろう」とか、「運用の手間は」「削除保護どうする」といったポイントまで理解したうえで使わないといけないよ、という警鐘も鳴らしています。
似た存在として、Amplify Genツーや、AWS Blocksのような仕組みとどう違うのか、という比較もされています。これらはどちらかというと、実行時のクラウド機能の体験とか、フロントとバックエンドが一体になった開発体験そのものにフォーカスしているのに対して、Nx Plugin for AWSは、「複数のアプリやインフラコードが混在するひとつのリポジトリ全体を、共通の作法とグラフ構造で整理して、ビルドやデプロイを実行するための開発基盤だ」と位置づけているわけですね。
「AIがコードを生成してくれる時代」においても、結局はリポジトリ全体の設計や依存関係の管理が、すごく大事なんだな、ということを改めて考えさせてくれる記事でした。
。.。.。.
そして五本目。
最後は強化学習の入門書を読んだメモをベースに、Q学習から深層強化学習までの流れを整理している記事です。
まず強化学習の基本として、「報酬の合計を最大にするような方策、ポリシーを探す」という目的が説明されています。場合によっては、将来の報酬に割引率をかけて、「近い将来の報酬をちょっと重めに見る」という考え方も使います。
Q学習では、「ある状態で、ある行動をとったとき、将来どれくらいの報酬が期待できるか」を表すQ値を学習していきます。そのときに重要なのが「ベルマン方程式」です。これを更新則として使うことで、「全部の行動パターンを全探索しなくても、少しずつQ値を推定していける」という仕組みになっている、という解説がされています。
そこから一段進んで、このQテーブルをそのまま持つ代わりに、ニューラルネットワークに置き換えた「ネットQ」、経験をためておいてからランダムに取り出して学習に使う「リプレイQ」、ターゲット用ネットワークの重みをしばらく固定しておく「ターゲットQ」など、学習を安定させるための工夫が順番に紹介されています。これらはいわゆる「ディープQネットワーク、DQN」系の枝分かれですね。
さらに、「ダブルディーキューエヌ」、Double DQNで、行動価値の過大評価を抑えるテクニックにも触れています。また、現実世界の問題だと、全部の状態が完全には見えない「部分観測」のケースも多いので、そういうときには、過去の観測履歴をうまく使ったり、LSTMみたいな再帰型のネットワークを組み合わせて扱う、といった話題も出てきます。
最後は、「モデルベース」と「モデルフリー」の違いを、「環境のルールを、明示的に使うかどうか」というシンプルな観点でまとめています。環境の遷移確率などを知っていて、それを計算に組み込むのがモデルベース。逆に、そういったルールはブラックボックスとして、観測と報酬だけから方策を学ぶのがモデルフリー、という整理ですね。
この記事は、強化学習まわりの用語がバラバラ出てきて混乱しがちなところを、Q学習から深層強化学習までの「流れ」と「安定化の工夫」をひとつの線でつないでくれていて、これから学び始めたい方にも、復習したい方にも読みやすい内容になっていました。
。.。.。.
というわけで、きょうの「zenncast」、駆け足でおさらいしておきます。
まずは、ハエ一匹ぶんの脳の配線図が四十年かけて完成しつつあって、進化が作った「生まれつきの構造」とAIの関係に新しい問いを投げかけている、という話。
二本目は、git worktreeとHerdr、Claude Codeを組み合わせて、複数のAIエージェントとブランチをきれいに整理して並列開発するための環境づくり。
三本目は、クラウドLLMのトークン代を抑えるために、ローカルGPUでqwen二ーてんごコーダーを回して、「重大バグ検出専用」のレビューモデルを作ったというワークフローのお話。
四本目は、Nx Plugin for AWSを実際に使って、ReactやAPI、DB、認証、CDKまでを共通の土台とグラフで管理する「開発基盤」としての位置づけを整理した記事。
そして最後は、Q学習からDQN系のバリエーション、モデルベースとモデルフリーの違いまでを、一気に整理した強化学習入門メモでした。
気になった記事があった方は、詳しい内容はショーノートにまとめてありますので、あとでゆっくりチェックしてみてください。番組の感想や、「こんなテーマ取り上げてほしい」といったリクエストも、ぜひぜひお待ちしています。
それでは、きょうも良い一日をお過ごしください。
「zenncast」、お相手はマイクでした。また次回お会いしましょう。