どうも、マイクです。おはようございます。
七月九日、木曜日の朝七時をまわりました。ここからの時間は「zenncast」、きょうもZennで話題になっているトレンドの記事を、ゆるっと楽しくご紹介していきます。通勤・通学のおともに、コーヒー片手に、最後までお付き合いください。

さて、きょうは全部で五本の記事をご紹介していきます。技術インフラのトラブルシュートから、AIエージェント、タスク管理術、研究自動化、そして開発環境の新しいスタイルまで、けっこう濃いラインナップになってますよ。

まず一つ目。
アプリを大幅リニューアルした直後に、「東京リージョンにAPIサーバーもデータベースも置いてるのに、データベースを触るほぼ全部のAPIが一律で遅い！」という、ちょっとイヤなトラブルに遭遇した話です。
最初はコードが悪いのか、CPUが詰まってるのか、といろいろ疑ったものの、調べていくと「DBと一往復するところだけが、異常に遅い」ということがわかってきた。そこでネットワークとDNSに疑いの目が向きます。

原因になっていたのが、PlanetScaleが推奨している optimized なホスト、いわゆる「おまかせで最寄りリージョンに飛ばしてくれるよ」という `aws.connect.psdb.cloud` のDNS解決でした。
本来なら「APIサーバーの場所」を見て、いちばん近いリージョンを選んでほしいところなんですが、Route 53 は「DNSリゾルバがどこにいるか」を基準に、最寄りを判断していたんですね。
その結果、Fly.ioの東京のマシンから名前解決すると、なぜかアメリカのオハイオ、つまりユーエス・イースト・ツーのIPアドレスが返ってきてしまっていた。
そうなるとどうなるかというと、クエリを投げるたびに太平洋を往復することになってしまって、シンプルな SELECT でさえ二百九十四ミリ秒、みたいな、かなり大きな遅延が出ていたわけです。

対応として筆者が取ったのは、この「レイテンシ自動最適化」をやめて、東京リージョンに固定された direct ホスト、`ap-northeast.connect.psdb.cloud` に切り替える、というもの。
これをやるだけで、SELECT が約三十五倍、コミットがなんと約五十三倍も速くなったそうです。そのおかげで、API全体のレイテンシも元どおり、サクサクに戻った。
筆者は、「同じような構成なら、PlanetScale以外のサービスでも同じことは起こりうる」としていて、「全体的に遅いな」と感じたときには、コードだけじゃなくて、データベースとの一往復のコスト、それからDNSの経路を、本番環境から必ず確認したほうがいい、と強くすすめています。
クラウドやマネージドサービスを信じきりすぎず、最後はちゃんとレイテンシを自分の目で見るのが大事、という教訓ですね。

。。，。

続いて二つ目。
AIエージェントの「スキル」、たとえば SKILL.md みたいな設定ファイルを、「書いて終わりのマニュアル」だと考えるんじゃなくて、深層学習でいうところの「重み」に相当するテキストパラメータとして、自動で更新していく対象だよ、という話です。
最近の研究ではですね、訓練データをエージェントの実行ログ、損失関数をいろいろな検証信号、勾配と学習率を「テキストをどの方向に、どれくらい修正するか」という制御に対応づけて、スキルを書き換えるループを構築しています。

Trace2Skill や MIND-Skill といった手法では、成功ログと失敗ログを集めて、その中から共通する修正だけを残すかたちでスキルを書き換えたり、LLMジャッジを使って「このスキルだけ読ませたときに、元の行動をどれくらい再現できるか」を評価したりしながら、行動の軌跡、いわゆるトラジェクトリからスキルを蒸留していきます。

一方で、CoEvoSkills や OpenSkill といった枠組みでは、正解データをループの外に置きつつ、代理の検証器とか、外部ドキュメント由来の「検証アンカー」と呼ばれるものを用意して、そこから評価信号を作り出します。
ただ、ここでおもしろいのが、「検証があいまいだったり不正確だったりすると、ループを回せば回すほど、むしろ性能が落ちてしまう」という結果も出ているところです。
筆者は、「汎用的で信頼できる評価設計をどう作るか、そこがいちばん難しい」と強調しています。

さらに、SkillOpt や SkillGrad という手法では、モデル本体は固定したまま、SKILL.md やスキルフォルダ全体を、学習率とかモメンタムまで意識したテキスト最適化ループでどんどん更新していきます。
ここでは、ちゃんとしたベンチマークの正解ラベルがあることが前提になっていて、「ラベル付きで評価できるって、やっぱり強いよね」という一方で、現実のタスクではそう簡単じゃないよね、という示唆も込められています。

そして締めとして紹介されているのが、「多くの既存スキルは、実タスクの性能をほとんど改善していない」というベンチマーク結果です。本当に効いているスキルは、かなり少数しかない。
なので、きちんと評価が組み込まれたループを回せていないと、「効いていないスキル」を量産しがちになるぞ、というわりと手厳しいまとめになっています。
SKILL.md を「ドキュメント」じゃなくて「学習されるパラメータ」だと見なす視点、エージェント構築をしている人にはかなり刺さる内容だと思います。

。。，。

三つ目。
タスク管理をLLMに丸投げしてみたり、逆に人間だけでMarkdown管理をがんばってみたりした結果、どちらも「整合性の維持」と「文脈を踏まえた判断」がボロボロに崩壊した、という経験談からスタートする記事です。
著者はそこから発想を切り替えて、「判断は人間、更新はエージェント、計算はスクリプト」という役割分担で、タスク管理の仕組みを組み直しています。

具体的には、「一つのタスクにつき一つのMarkdownファイル」を唯一の正として扱って、ガントチャートとか、依存関係の図とか、そういったビューはぜんぶスクリプトで自動生成する方式にしています。
タスクの内容を書き換える役割は、かなり厳密な仕様を与えた専用のサブエージェント、一本に限定。
そして、期限の集計とか、親子タスクのステータスをどう反映するか、みたいな「計算で決まる処理」は、決定論的なPythonスクリプトとフックの仕組みにぜんぶ任せてしまう。

おもしろいのは、エージェントには「優先度判断」みたいな、文脈依存の賢い判断をさせないようにしている点です。
人間がきちんと状況を踏まえて決めた方針を、「どのファイルをどう編集するか」という具体的なファイル操作に翻訳させるだけに役割を絞る。
こうすることで、モデルがどれだけ賢くなっても壊れないかたちで、信頼性とコストを両立できる、といいます。

同じ考え方を、チームで使っている Notion の連携や、日々の運用にも広げていて、「ツールをあちこち渡り歩く」のではなく、「人間とエージェントとスクリプト、それぞれが何を担当するか」を再設計することが、長く続くタスク管理のカギだとまとめています。
「全部LLMに任せればいい」でもなく、「ぜんぶ人力でがんばる」でもない、その中間の実践的な設計論ですね。

。。，。

四つ目。
AIエージェントを使って論文を書いてみた体験から、「研究と執筆のどこまでを自動化できるのか？」を検証した話です。
LLMの学習、評価、分析というループは、CLIベースのエージェント、いわゆる CLI Agent を使うことで大きく高速化できて、七週間で従来の二倍以上の成果を出せた、と報告されています。
一方で、その結果から「意味のある示唆」を取り出して、論文全体の骨格を組み立てる部分、ここは依然として、人間の判断が不可欠だ、とも述べています。

著者は、実験コード、結果のログや図表、それから先行研究、原稿までを、一つのリポジトリに全部まとめて管理しています。
そのうえで、複数のエージェントを協調させる「Claude Code Orchestra」という仕組みで、研究のサイクルを回していったそうです。
ただし、主張と証拠をどう対応づけるかとか、論文の構造を最終的にどう確定するか、というところでは、かなりの試行錯誤が必要だった、と振り返っています。

最近よく聞く「バイブコーディング」、振動するように人間とAIがやりとりしながらコードを書くスタイルに対応して、「バイブライティング」、論文執筆版のやり方は、まだ定まっていないといいます。
骨子をどこまで人間側で先に固定しておくのか、人間とエージェントの共同執筆ルールを事前にどう決めておくのか、そういった仕組みづくりを、これから職場や研究室ごとに開拓していく段階だ、という位置づけです。

研究のボトルネックも、かつては「実験を回す速さ」だったのが、いまは「良い問いや示唆を生み出す速さ」のほうに移りつつある。
オートリサーチ、研究の自動化が進んでいく世界では、「人間がどこで、どう介入するのか」という、認知のプロトコル設計が重要になる、と結論づけています。
実験はエージェントがガンガン回してくれるけれど、「そもそも何を問うのか？」は人間の仕事のまま、という未来像が見える記事でした。

。。，。

そして五つ目、最後の記事です。
LLMエージェントと一緒に開発するのが当たり前になってきたなかで、筆者が VS Code と DevContainer を中心にした「一プロジェクト一コンテナ」スタイルから離れて、「長生きする一台の開発マシンとしてコンテナをSSHで使う」というスタイルに移行した、という話です。

これまでは、プロジェクトごとにDevContainerを立てて、その中でだけ開発する、というやり方が多かったと思うんですが、筆者はそこから方針転換。
コンテナは、組織ごととか顧客ごとの単位で分けて、その中に複数のプロジェクトや git worktree を置いていく設計にしています。
自分自身は Orca という Agent Development Environment からそのコンテナにSSH接続して、リモートの worktree、エージェント専用のターミナル、ポートフォワードなんかを駆使しながら、LLMエージェントに複数タスクを並列実行させる、という運用です。

機密情報の扱いも工夫していて、secret はコンテナの中にファイルとして残さず、ワンパスワードの `op` コマンドラインツールから環境変数として注入するようにしています。
さらに、自分用のベースイメージやワークスペース定義は、プロジェクトのリポジトリとは切り離しておいて、「個人の開発環境」と「チームで共有する設定」をちゃんと分離することが大事だ、と述べています。

もちろん、この構成には、再現性とかセキュリティ、それからコンテナの掃除の手間などについて、いくつか割り切りも必要になります。
それでも、VS Code 前提のワークフローから離れて、git worktree とエージェントを多用するような個人開発にとっては、いまのところこれがいちばんフィットしている、というのが筆者の結論です。
「一コンテナ一プロジェクト」から、「一コンテナ一ワークスペース」の発想に切り替えているのが、おもしろいポイントですね。

ということで、きょうは全部で五本の記事をご紹介してきました。ざっとおさらいすると、
東京リージョンなのにDBが激遅になってしまった原因が、DNSの経路とレイテンシ自動最適化にあった話。
SKILL.md を「学習される重み」と見なして、ログと評価で自動更新していく、エージェントスキル最適化の最前線。
判断は人間、更新はエージェント、計算はスクリプト、という役割分担でタスク管理を設計し直す試み。
AIエージェントで研究のループを高速化しつつ、「良い問いと示唆」は人間が生み出すしかない、という論文執筆の現場レポート。
そして最後は、LLMエージェントと並走するための、新しいコンテナ運用と開発環境のスタイル。
こんなラインナップでした。

気になった記事があった方は、このあとショーノートからぜひ本編もチェックしてみてください。ここでは触れきれなかった図やコード、細かいノウハウがたくさん詰まっています。
「zenncast」では、番組の感想や、取り上げてほしいテーマ、最近の開発の悩みなんかも、どしどし募集しています。あなたの現場の話、ぜひ聞かせてください。

それでは、きょうも良い一日をお過ごしください。
お相手はマイクでした。次回の「zenncast」でまたお会いしましょう。