どうも、こんばんは。zenncastパーソナリティのマイクです。
今日は2026年6月18日、木曜日の朝7時。みなさん、そろそろお仕事・学校に向かう準備してる時間でしょうか。
この番組では、Zennで話題になっているトレンド記事を紹介しながら、テック界隈のホットな話題をゆるっとお届けしていきます。

今日はですね、Zennで今盛り上がっている記事を、全部で5本ご紹介していきます。
AIの自己改善から、テストの話、スライドづくり、そしてClaude Codeの安全な使い方、最後はTDDまで、なかなか濃いラインナップです。コーヒー片手に、耳だけ貸してもらえたらうれしいです。

今日はお便りコーナーはお休みで、そのぶん記事紹介をじっくりめにやっていきたいと思います。

ということで、まず1本目。
タイトルは「自己改善エージェントはなぜ前提を覆せないのか ― 局所最適とハーネスでの脱出」。
AIのWorkflowを、自分で自分を改善していくエージェントに任せてみたものの、「90％くらいまではよくなるんだけど、そこから先が伸びない」という、実務でもかなり“あるある”な話を深掘りしている記事です。
要するに、プロンプトの微修正とか出力の正規化みたいな“細かいお化粧直し”は上手なんだけど、「そもそもこの設計でいいんだっけ？」「処理の順番から変えようよ」みたいな“前提をひっくり返す提案”がほぼ出てこない、と。で、その背景にあるのが、最初の要件に縛られちゃうアンカリング、自己反省がだんだん雑になっていくDegeneration-of-Thought、そして「ひとつの案だけをひたすら磨き続ける」探索構造。研究界隈ではContext PollutionとかInitialization Bias、Mode Collapseなんて言われている問題とつながってきます。
じゃあ何が大事かというと、「エージェントをもっと賢くする」というより、“ハーネスの設計”がカギだと。具体的には、まず複数のワークフロー候補を並行して改善して、そのトレースとスコアマトリクスをちゃんと残すこと。それから、いい候補をアーカイブしておいて、親選択やバックトラックに使うこと。そして、精度だけじゃなくて「設計の多様性」を軸に評価して、まだ試してない設計パターンを積極的に探索する、いわばMAP-Elites的なアプローチ。
とはいえ、フィードバックをLLMが全部取り込みきれない「Feedback Friction」とか、計算コスト、評価の改ざんリスクなんかは残るよね、という冷静な指摘もあって、夢物語じゃなく実務目線でまとめてくれているのが読みどころです。筆者は、実際のWF改善プロジェクトで、候補WFと実行ログを木構造で保存したり、入力タイプ別にスコアマトリクスを持ったりしながら、この知見を現場に落とし込んでいく、という方針を語っています。AIエージェントを「とりあえず回して様子見る」から一歩進めたい人にはすごく刺さる内容ですね。

。。。。

続いて2本目。
タイトルは「テスト観点を軸にした品質サイクルのすすめ」。
テストがいつまで経っても終わらない…っていう、開発現場でよく聞く悩みの根っこに、「テストをやること自体」が目的化しちゃってる問題があるよね、というところから始まる記事です。とりあえずテストケースを増やしてカバレッジを上げよう、みたいな発想で、見積もりも形だけ…これ、心当たりある人、多いんじゃないでしょうか。
筆者が21万件以上のテストを分析したところ、正常系ばかり、内容が重複、リスク低いところを手動で延々と…といった非効率が山ほど見つかって、観点ベースで整理して自動化に回せば、なんと75％削減できる余地があると。そこでキーワードになってくるのが「テストケース」じゃなくて、その上位概念である「テスト観点」を管理する、という考え方です。
テスト観点カタログという共通言語をチームで持っておいて、テストの実行ループ、つまり設計・実行・記録と、品質管理のQCループ、分析・評価・改善・更新を、この観点を軸にぐるぐる回していく。そうすると、次のスプリント計画も、更新された観点リストからスタートできて、品質がらせん階段みたいにじわじわ上がっていくと。
さらに、NGの原因分析をちゃんとやって、「どの観点が足りなかったのか」「観点の書き方がおかしかったのか」を観点カタログにフィードバックすることで、プロダクトの品質と同時に、テスターの思考力も鍛えられていく。最終的には、観点をベースにリスクごとにテスト密度を調整しながら、「テストの終わり」を科学的に定義していこう、という提案になっています。なんとなく“網羅した気分”になるためのテストから、戦略的なテストに切り替えたいチームには、かなり実用的なフレームワークになりそうです。

。。。。

3本目はガラッと変わって、クリエイティブ寄りの話題。
タイトルは「Claude Designでスライドを作成する」。
AnthropicのClaude Designという新しいツールを使って、テキストで指示するだけでスライドやワイヤーフレームをサクッと作っちゃおう、という内容です。デザイナーじゃなくても、アイデアをすぐ“見える形”にできるのがポイントですね。
インターフェースはチャットとキャンバスの2ペイン構成で、「配色をもっとシンプルにして」「ナビゲーションを上に移動して」みたいな自然文でやり取りしながら、プロトタイプをグリグリ修正していけます。UI/UXのワイヤー、ピッチデッキ、ダッシュボード、LPなど、わりと何でも作れて、Canva形式とかPDF、PPTX、HTMLでエクスポート可能。さらにClaude Codeへのハンドオフもできるので、デザインから実装への橋渡しもスムーズに。
記事では、AI AgentやMCPの解説用スライドをClaude Designで作る手順が紹介されています。まず既存資料のスクリーンショットを素材としてアップロードして、いくつかの質問に答えると、それをもとに新しいスライドを自動生成してくれる。で、そのままPPTXとして出力できるんですが、「Editable - universal fonts」だとフォント置き換えの関係でデザインがちょっと崩れがち。一方「screenshot-based PPTX」は中身は画像で編集できないけど、見た目はかなりきれい、という具体的なメリデメも教えてくれています。
面白いのが、生成済みスライドに対しても、「このページの構成をもっとシンプルに」「ここに最新のニュースも追加して」と自然言語で追い指示できるところ。Web検索機能を使って、最新の情報を拾ってきて、それをそのままスライドに反映してくれるので、「資料を最新化する作業」がかなり楽になりそうです。資料づくりにいつも時間を取られている方は、一度試してみる価値ありそうですね。

。。。。

4本目は、Claude Codeを使っている人には刺さりまくるであろう記事。
タイトルは「『とりあえず許可』を卒業する：Claude Codeの実行前に行動説明を表示するHookを作ってみた」。
Claude Codeでコマンド実行やファイル編集のダイアログが出てきたときに、「よく分からんけど、まあ大丈夫っしょ」と、とりあえずAllowを押しちゃう問題。これ、あるあるですよね。この記事では、その“無意識な許可”から卒業するための仕組みを、CLAUDE.mdとPreToolUse Hookを組み合わせて作ってみた、という内容です。
まずCLAUDE.md側で、「Bash」「Edit」「Write」「MultiEdit」みたいな危険度のあるツールを実行する前には、目的と影響、この2つの観点を日本語で説明しなさい、というルールを定義しておきます。で、PreToolUse Hookのほうでは、実際に呼び出されようとしているtool_nameとtool_input、つまりBashならコマンドの中身、Edit系ならどのファイルをどう変えるつもりなのか、という情報をきれいに整形して表示。
ユーザーは、Claudeが書いた「これからこういう目的で、こういう影響があります」という説明と、実際のコマンド内容や編集対象を見比べながら、「本当に許可していいか」を判断できるようになります。設定手順としては、CLAUDE.mdにルールを追記して、NodeでHookのスクリプトを書いて、settings.jsonに登録する…という流れを記事では丁寧に解説。
最後には、もっと発展させて、危険そうなコマンドを検知して警告を出したり、操作ログを残したり、説明がちゃんと書かれているかチェックしたり、応用例もいくつか挙げられています。「LLMに権限は与えたいけど、勝手に危ないことはしてほしくない」という人には、めちゃくちゃ実用的なアイデアになっています。

。。。。

そしてラスト5本目。
タイトルは「テスト駆動開発（TDD）をやってみた」。
TDDについて「テストから書くと手戻り減るんでしょ？」くらいのふわっとした理解だった筆者が、「AI開発と相性がいいらしい」という話を聞いて、本腰入れて学び直してみた、その実践レポートです。題材として選んだのはボウリングのスコア計算。ルールがややこしいので、TDDの練習にはちょうどいいやつですね。
記事ではまず、TDDの価値として、インクリメンタルに設計を育てていけること、チームに一定のリズムが生まれること、そして開発への自信が得られることを整理したうえで、Red→Green→Refactorの流れを説明。実際の手順として、RubyとRSpecを使って、全部ガターのケースから始めて、スペア、ストライク、複雑な組み合わせ…とテストをひとつずつ追加しながら実装を育てていきます。
途中、ストライクの処理を実装したあたりで、コードの「臭い」を感じて、フレームごとの責務をFrameクラスに切り出すリファクタリングを実施。これによって設計がかなりすっきりして、「あ、こうやって設計と実装がテストに導かれていくのか」という実感が得られたと語っています。一方で、自分の手順を振り返って、「本来TDDでは最初にやるべき“テストリスト”を作るのをサボってたな」とも反省。ボウリングの振る舞いを先に一覧化してから、一個ずつRed→Green→Refactorを回すべきだった、と。
最後は、AI時代だからこそ、コーディングをAI任せにしがちだけど、TDDが提供してくれるのは「大きな問題を分割して、小さなフィードバックサイクルで前に進む」という考え方そのものだ、というメッセージで締めくくられています。これはソフトウェア以外の分野にも応用できるよね、ということで、読者にもぜひ手を動かして試してみてほしい、と背中を押してくれています。

。。。。

ということで、今日のzenncastは、
自己改善エージェントが前提を覆せない理由とハーネス設計の話、
テスト観点を軸にした品質サイクル、
Claude Designでのスライド自動生成、
Claude Codeを安全に使うための「とりあえず許可」卒業Hook、
そしてボウリングを題材にしたTDD実践記、
この5本を駆け足でご紹介しました。

気になった記事があれば、詳しい内容は番組のショーノートに載せておきますので、ぜひ元の記事をじっくり読んでみてください。
この番組では、感想や「こんなテーマも取り上げてほしい！」といったリクエストも大歓迎です。zenncast宛てに、ラジオネームを添えて送ってもらえると、番組の中でご紹介させていただくかもしれません。

それでは、そろそろお別れの時間です。
ここまでのお相手は、zenncastのマイクでした。
次回また、この時間にお会いしましょう。いってらっしゃい！