どうも、マイクです。おはようございます。
2026年6月17日、水曜日の朝7時をまわりました。ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事を、ラジオ感覚でゆるっと紹介していきます。通勤・通学中のあなたも、おうちで支度中のあなたも、最後までお付き合いください。

さてさて、きょう紹介する記事は全部で5本です。技術寄りのネタから、AIとの付き合い方、開発フローの話まで、かなりバラエティ豊かです。それぞれざっくり内容がイメージできるようにお話ししていきますね。

まず1本目。「`cp`はディスク上ではデータをコピーしないことがある」という記事です。
Linux触ってるとおなじみの `cp` コマンド、「コピーって言ってるんだから、ちゃんと別の場所にデータをコピーしてるんでしょ？」って思いがちなんですが、実は最近の環境だと、そう単純でもないよ…というお話です。
ポイントは「reflink」っていう仕組み。XFSとかBtrfsみたいな、reflink対応のファイルシステムだと、同じデータブロックを複数のファイルで“共有”できるようになっていて、GNU coreutils v9.0以降の `cp` は、デフォルトで「もしreflink使えそうなら使う」動きをします。つまり `cp foo bar` した瞬間は、fooとbarが実は同じ領域を指していて、まだ本当の意味では“別物”になっていない。書き込みが発生したタイミングで、変わるところだけコピーされる「コピーオンライト」です。
これのおかげで、コピーがめちゃくちゃ速くなったり、ディスク節約になったりする一方で、同じファイルシステム内でのバックアップ用途だとちょっと怖い。片方がビット化けすると、共有している部分はもう片方にも影響しうる、といったリスクがあります。
記事では、`--reflink=auto / always / never` をちゃんと意識して使い分けよう、というメッセージになっていて、「普段なんとなく使っているコマンドの裏で、ファイルシステムがこんな賢いことしてるんだ」というのを教えてくれます。バックアップスクリプト書いてる方は、これを機にオプションの見直しをしてみるとよさそうです。

。。。。

続いて2本目。「Hono で API バックエンドを作るときの個人的ベストプラクティス」という記事です。
HonoでバックエンドAPIを作るとき、ディレクトリ構成どうしよう、型はどこまで厳密にやる、ルーティングの分割は…みたいな悩み、ありますよね。この記事は、筆者の「いまのところのベストプラクティス」をかなり具体的に落とし込んでくれています。
構成としては、`src/features/<ドメイン>/` ごとに切り分けて、その中を `index.ts`（ルート）、`service.ts`（ビジネスロジック）、`repository.ts`（DBアクセス）、`schema.ts`（zodスキーマ）という3層＋スキーマ構成。依存の向きも「index → service → repository」に限定して、ぐちゃっとならないようにしているのがポイントです。
DB には Drizzle、入出力のバリデーションと型定義には zod を使って、zod から infer した型をそのまま service の入力にも使う。これで「型とスキーマが二重管理になってズレる」問題を減らしているのがうまいところですね。
ルーティングは feature ごとに Hono の sub app として切り出して、`app.route('/users', users)` みたいにマウント。method chaining 前提で書いて型推論を壊さないようにする、というあたりも、実際の開発でハマりやすいポイントを押さえています。
さらに、RPCクライアント用の型もsub app単位でexportして分割生成することで、IDEが重くなりすぎないようにする工夫とか、認証ミドルウェアを「publicなエンドポイントがあるかどうか」で sub app 先頭か root かに分ける方針なんかも紹介されています。HonoでAPIつくってる人には、そのままテンプレにしたくなるような実践的な記事になってます。

。。。。

3本目。「2026年6月現在の Claude Code 開発フロー」という記事です。
これは、Claude Desktop と周辺ツールをがっつり組み合わせて、「AIと一緒に開発するフロー」をかなり作り込んでいる事例ですね。エディタはNeovimとZedを使い分けつつ、WezTerm＋gtrでブランチごとにworktreeを作る、という時点でだいぶ職人感があります。
Claude Code 側では、まずデフォルトをPlanモードにして、Backlogのチケットを読んで、計画を書いて、さらにその計画をCodexモードでレビューさせる。その上で実装に入って、最後は「dev-flow-gate」というStop Hookが、計画ファイルの検証、チェックリストとの同期、コードの簡素化、Codexレビュー、そして Draft PR 作成まで自動でやってくれる、という流れ。かなり「計画と実装がズレないようにする」ことにこだわった設計になっています。
また、/browser-check で Playwright を使ったローカル・ステージング環境のブラウザ確認を回したり、/commit・/pr といった自作スキルと skill-guard、terraform-guard を組み合わせて、「AIが直接危険なコマンド叩いたり、インフラを勝手に変えたりしないように」ガードをかけているのも特徴的です。
この記事の面白いところは、「AIに全部やらせる」というより、「AIにきちんとした手順を守らせて、なるべく自律的に進めつつ、人間はガードレールとレビューに注力する」という思想が貫かれている点ですね。単なるツール紹介ではなく、開発プロセスのデザイン事例として読むと学びが多い内容になっています。

。。。。

4本目。「AI が大量にアウトプットしてくるので認知負荷を下げる Skill を作った」という記事です。
最近のAIって、コードも設計書もPRも、とにかく“量”は出してくれるんですけど、「読む側の脳みそがもたない問題」ありますよね。この記事では、その認知負荷を下げるために、Claude Code のスキルとして `yaml-to-html` という仕組みを自作した話が紹介されています。
アイデアとしては、対象を「意味」と「見せ方」に完全に分離する、というもの。`core.yaml` には概念やその関係性、重要度、リスクといった「UIに依存しない意味構造」だけを書いておく。一方、`view.yaml` には、読者ロール（エンジニア、PdMなど）や、どこを強調したいか、マインドマップ・シーケンス図・テーブルといった好みの表現スタイルを指定します。
この2つのYAMLから、複数のビューを持つHTMLバンドルを生成してやることで、「同じ意味」から、読み手にあわせたマインドマップ版、シーケンス図版、役割別ビューなどをタブで切り替えて読めるようにする、というアプローチです。
おもしろいのは、ビューが「破壊的変更」じゃなくて、あとからどんどん追加していけるところ。意味構造は固定で、見せ方だけ増やしていくので、再生成のたびにAIが読むのも core.yaml と view.yaml の2ファイルで済んで、コンテキストも小さく保てる。
「AI要約はAIっぽくて頭に入ってこないな…」とか「自分は図で見たいのに、文章でダラダラ出てくる…」みたいなモヤモヤを、構造的に解決しようとしているのが印象的でした。読み手側の認知特性を前提にしたドキュメント設計として、これからいろんな応用が出てきそうなアイデアです。

。。。。

そしてラスト5本目。「ローカルLLMをいつ使うべきか？」という記事です。
「APIだとお金かかるし、ローカルでモデル動かせば安いんじゃない？」って、一度は考えたことある人、多いと思います。この記事は、その直感にわりとはっきり「それは違う」と言っていて、数字ベースで冷静に整理してくれています。
まずコスト面。ローカルLLMって、GPUを借りたり買ったり、運用したりするコストがかかるので、かなり高い稼働率、ざっくり月に数十億〜百億トークンぐらい捌く規模じゃないと、APIより安くなりにくい。なので「なんとなく自前で回したほうが得でしょ」は危ない考え方だよ、と。
じゃあ、どこでローカルLLMが光るのかというと、記事では3つ挙げています。ひとつは規制やガバナンスの要件で、そもそもデータを外に出せないケース。もうひとつは、狭く定義したタスクに特化させて精度を上げるケース。最後が、レイテンシの安定性です。
具体例として、RAGチャットボットの「トピックドリフト検知」と「追加検索が必要かどうかの判定」を、Gemma 4 E2B＋LoRA でローカルに特化学習させた話が紹介されています。大規模モデルで合成＆ジャッジした高品質データを使って学習した結果、ドリフト検知率を61％から97％まで上げて、フロンティアモデルと同等以上の性能を達成。vLLM＋単一L4 GPUでデプロイしたところ、p90とp95の差が0.02秒、エラー率0％と、レイテンシ分布もかなりきれいになったそうです。
結論としては、「巨大モデルを丸ごとローカルで回す」のは現実的じゃなくて、7〜13Bクラスの小さめのモデルを、特定タスクにローカルで特化させつつ、汎用対話や重い推論はフロンティアAPIに任せるハイブリッド構成がよい、という提案になっています。ローカルであること自体が価値なんじゃなくて、「限られた用途に高品質データでフィットさせられる」のが本当の価値なんだ、という視点は、インフラ選定するエンジニアにとってかなり刺さる内容だと思います。

。。。。

そろそろお別れの時間です。
きょうのzenncastでは、
・`cp`コマンドがreflink対応ファイルシステム上では“本当にコピーしていない”ことがある、というファイルシステム視点の話。
・HonoでAPIバックエンドを作る際の、ディレクトリ構成やzod／Drizzle活用を含めたベストプラクティス。
・Claude Codeと各種ツールを組み合わせた、計画駆動＆ガードレール付きの開発フロー事例。
・AIが大量に出してくる情報を、「意味」と「見せ方」を分けて整理する `yaml-to-html` スキルの取り組み。
・ローカルLLMを本当に使うべき場面と、フロンティアAPIとのハイブリッド構成の考え方。
この5本を駆け足でご紹介しました。

気になった記事があれば、詳しい内容はこの番組のショーノートに書いておきますので、あとでじっくりチェックしてみてください。
番組の感想や、「こんなテーマ取り上げてほしい！」といったリクエストも、いつでもお待ちしています。あなたの一言が、次回のzenncastのネタになるかもしれません。

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