どうも、zenncastパーソナリティのマイクです。
時刻は朝7時をちょっと回ったところ、2026年4月23日、木曜日の朝ですね。みなさんおはようございます。
この番組では、Zennに上がっている今ホットなトレンド記事を、ラジオ感覚でゆるっと紹介していきます。通勤・通学のおともに、作業のおともに、耳だけ貸してもらえればうれしいです。
今日はリスナーのみなさんからのお便りはお休みということで、そのぶんガッツリ記事を紹介していきますね。
さて、今日紹介する記事はぜんぶで5本。
AIまわりの実践ネタから、テストの育て方、iOSクラッシュの闇、AWSのセキュリティ運用、そして最後は“ながーーーーい地番”を探す面白データ分析まで、かなりバラエティ豊かです。それではさっそくいきましょう。
まず1本目。
タイトルは「CLAUDE.md の肥大化を 3 層構造で 83% 軽くした — 実測と試行錯誤の記録」。
Claude Code、使ってる方も増えてきましたが、その設定ファイル `CLAUDE.md` が気づいたら2000行まで膨れ上がっていた、というところから始まるお話です。毎セッションごとに、この巨大ファイルをまるごと読ませるので、コンテキストをめちゃくちゃ食ってしまう。しかも、SuperClaude Framework のモジュールを12個も無選別で取り込んだり、似たようなスキルが乱立していたり、rulesをホームディレクトリに直置きしていたりと、「とりあえず足してきた結果カオス」な状態になっていた、と。
そこで著者が2ヶ月かけてやったのが、「本当にClaudeに教えなきゃいけないことは何か」を徹底的に棚卸しする作業です。SOLIDみたいにClaudeがもともと知っている原則は削除、冗長な例や重複したスキルも統合。構成も見直して、`CLAUDE.md` には“最重要ルールだけ”、恒常的なルールは `rules/` ディレクトリ、明示的に呼び出すワークフローは `skills/` という3層構造に再設計しました。さらにchezmoiを使って、ホストごとに読み込むrulesやskillsを出し分けることで、起動時に読むファイルを最小限に。結果として、全ファイルを一括で読んだ場合は11万4千トークン以上だったものが、起動時は約1万9千トークンまで、実測で83%削減できたそうです。
面白いのは、「新しいルールをどこに置くか」の運用フローまで決めているところ。
“全作業に共通する前提なのか”“日常的に効くルールなのか”“特定の作業のときだけ起動するワークフローなのか”を判断して、できるだけskillsに逃がしていく。これによって、重くならないまま拡張できるようにしているわけですね。一方で、rulesの肥大化や、skillsが自動で発火してしまう挙動など、まだ課題も残っていると率直に書かれていて、実践的な知見がぎっしり詰まった記事でした。Claude周りを本格運用してる方は、構成の見直しの参考になると思います。....
続いて2本目。
タイトルは「テストがないコードへのテストの育て方」。
これ、刺さる人多いんじゃないでしょうか。すでに動いているけどテストが一切ない、でかいバッチやレガシーな業務コード。いきなりきれいにリファクタリングしようとすると怖いし、どこから手を付けていいかわからない。そんな状況で「テストを“育てる”」ためのステップが整理されています。
最初のステップ1では、いきなりテストを書かずに、関数やDBアクセスの前後にデバッグプリントを入れて、実運用に近い呼び出しログを集めます。まずは現状のふるまいを“観察”するところから。次のステップ2で、そのログをもとに「実際の操作を再現するテスト」をまとめて作る。ログの入力と出力をテストに落とし込んで、環境やデータもできる限り合わせていくイメージです。
ステップ3では、運用ログから漏れているパス、たとえば例外系とかイレギュラーな経路を探して、テストケースを足していくことでカバレッジを高めていく。そしてある程度カバレッジが上がったら、ステップ4で、今度はテストコード自体をリファクタリング。巨大な共有フィクスチャをやめて、データファクトリを導入したり、テストを分割して名前を整理したりして、読んでメンテしやすいテストに育てていきます。
最後のステップ5では、本丸である本体コードのリファクタリング。巨大な関数から責務ごとに処理を抜き出して、それぞれに直接テストを書いていくことで、元の関数のテストをシンプルにしつつ、安心してリファクタリングできるようにする。いきなり「100点のテスト」を目指すんじゃなくて、観察→再現→拡充→テストの整理→本体の分割、という流れでじわじわ攻めていく発想が、とても現場的だなと感じました。いまレガシーコードと格闘している方は、勇気をもらえる内容だと思います。....
3本目いきましょう。
タイトルは「App Store に配布したアプリのみクラッシュした」。
これ、iOS開発者には悪夢のようなシチュエーションですよね。ローカルビルドもTestFlightも問題ないのに、App Store版だけ起動直後にクラッシュする。手元で再現しないのでデバッグも難しい。その原因をどう特定したか、という事例です。
著者はまず、ユーザー端末から取得した .ips ファイル、つまりクラッシュログを持ってきて、symbolicateしてスタックトレースを読める形にします。そして、そのスタックトレースをAIに解析させたところ、「Swift Concurrencyのランタイムが async let の lifetime 違反を検出してabortしている」というところまでわかった。しかも、その問題が起きている場所がFirebase Functions SDKの中、FunctionsContext.swiftだと特定されるんですね。
さらに調べていくと、App Store配布時のarm64e向け最適化と、Xcode 26.4 / Swift 6.3のReleaseビルドの組み合わせで、async letのデアロケーション順序がおかしくなるコンパイラバグが顕在化していた模様。同様の事例がFirebaseとSwift、両方のGitHub Issueに上がっていて、Firebase側ではasync letをTaskに置き換える修正PRがすでにマージ済み。最新版のFirebase iOS SDK 12.12.0に上げたところ、無事クラッシュが解消した、という流れです。
ポイントは、クラッシュログをsymbolicateしたうえでAIに読ませることで、「スタックトレースを自分一人で完全に読み解けなくても」「関連しそうなIssueやコンパイラバグの候補まで一気に辿りつけた」っていうところ。App Storeだけで起こるクラッシュって本当に厄介なんですけど、AIをうまく使うことで、原因特定をだいぶショートカットできるんだなという、実践的なケーススタディになっています。iOSアプリ運用してる方にはぜひ読んでほしい記事でした。....
4本目。
タイトルは「AWS DevOps Agent と GuardDuty を連携してみたら想像していたセキュリティインシデント調査が行われていて感動した話」。
名前からしてめちゃくちゃ楽しそうなんですが、内容もかなりワクワクします。AWS DevOps AgentというAIエージェントを、GuardDutyとWebhook連携させて、GuardDutyのFindingが出たら、自動的にAIがインシデント調査を始めてくれる、という仕組みを検証したレポートになっています。
構成としては、VPCフローログや各種ログをCloudWatchに集約した環境で、GuardDutyが検知しそうなイベント、たとえばコインマイニングやC2ドメインへのDNSクエリをわざと発生させる。すると数分でDevOps Agentが動き出して、まずTriage Agentが複数のFindingを関連づけてLINKEDとして集約してくれる。それをもとに、VPCフローログを分析して、不審なIPアドレスや通信パターンを洗い出し、攻撃のキルチェーンを推定。最後には、日本語で「こういう対応をするといいですよ」という推奨アクションまで出してくれる、という流れです。
面白いのは、クロスアカウント調査ができたり、Skillsという仕組みで、自動学習されたスキルや自社独自の手順を取り込める点。これによって、自社環境の“クセ”まで理解して、より的確に調査してくれる可能性がある。ただし、実際の修復アクション──セキュリティグループを閉じるとか、インスタンスを隔離するとか──は人間が実行する前提で、あくまでAIは調査と提案まで。完全自動じゃない、っていうバランス感覚もいいですよね。GuardDutyとの“ネイティブ統合”がない点は課題として挙げつつも、「ノイズを減らして24時間365日の一次調査を自動化する」という意味では、かなり実用的な手応えがあったようです。セキュリティ運用しているチームには夢のある話でした。....
そして最後、5本目。
タイトルは「ながーーーーい地番を探せ！ 登記所備付地図を覗いてみよう」。
これは一気に空気が変わって、データ好き・地図好きにはたまらないネタです。法務省が公開している「登記所備付地図データ」を全国分API経由で取得して、日本一“文字列としてながーーーーい地番”を探そう、という試みです。
やっていることはかなり本格的で、まずG空間情報センターAPIから都道府県別の組織情報を取得し、そこから市区町村や登記所ごとのデータセットをたどっていく。さらに最新ZIPに入っている `search-list.csv` を使って、地番の一覧を抽出・分析していきます。その結果、「日本一文字数が長い地番」は埼玉県北本市の「1955-3・1956-3・1957-3・1958-3・1959-3・1960-2合併」で、なんと43文字。長い。さらに、「一番たくさんの土地を合併した地番」は、愛知県刈谷市・田原市、それから京都府亀岡市の“11筆合併”がトップクラス。ハイフンの数が一番多い地番は、岐阜県土岐市の「11-3-1-1-1-1-1-1-3」で、支号が8個もついているという、すごい記録が出てきます。
普段の業務ではまずお目にかからないような極端な地番を、全国を網羅するオープンデータから機械的に探し当てていくプロセスが、とにかく面白い。こういう「真面目なデータを、ちょっとふざけた問いで覗いてみる」ことで、データの構造や限界も見えてくるんですよね。著者も、オープンデータを網羅的に活用する重要性を強調していて、技術的なお作法だけじゃなく、データと遊ぶ視点も学べる記事になっていました。
というわけで、今日のzenncastは、
1本目「CLAUDE.mdを3層構造にしてコンテキストを83%削減した話」、
2本目「テストがない既存コードに、段階的にテストを育てていく方法」、
3本目「App Store版だけクラッシュしたiOSアプリを、クラッシュログとAI解析で原因特定した事例」、
4本目「AWS DevOps AgentとGuardDutyを連携して、AIが自律的にインシデント調査してくれた話」、
5本目「登記所備付地図データから、日本一“ながーーーーい地番”を探したデータ遊び」、
この5本を駆け足でご紹介しました。
気になった記事があれば、ぜひショーノートから元記事に飛んで、じっくり読んでみてください。今日触れたのは、どれも表面だけなので、本編にはもっとディープなノウハウや、細かい手順、著者の試行錯誤が詰まっています。
番組の感想や、「こういうテーマの記事を紹介してほしい」「この技術の回、やってほしい」といったリクエストも、いつでもお待ちしています。あなたの一言が、次回のzenncastのネタになるかもしれません。
それでは、そろそろお別れの時間です。
ここまでのお相手は、マイクでした。
次回のzenncastでまたお会いしましょう。それでは、いってらっしゃい。