どうもー、おはようございます。マイクです。
朝7時をちょっと回ったところ、2026年6月11日、木曜日の「zenncast」お届けしていきます。
この番組では、Zennで話題になっているトレンドの記事を、朝いちばんにサクッとチェックしていく番組です。通勤・通学のお供に、耳だけ貸してもらえたらうれしいです。
さて今日は、お便りの紹介はお休みで、そのぶんたっぷり記事を紹介していきたいと思います。
今日ピックアップする記事は、全部で5本。技術の話からAI、法律を関西弁で読んじゃう！？っていうユニークなネタまで、バラエティ豊かに揃ってます。
まず1本目。
タイトルは「難解な条文すら関西弁なら理解できる説。試せるサイト『おおさかけんぽう』を作った話」。
これね、アイデア勝ちというか、「そう来たか！」って感じの記事です。
筆者の方が、「法律の中身が難しいんじゃなくて、日本語の文体が固すぎるから読めないんちゃう？」という発想から、日本国憲法とか民法とか、なんと17個の法律、合計5,669条を、大阪弁で読めるWebアプリにしてしまった、というお話です。
ポイントは、単なる語尾変換じゃないところ。「公共の福祉」みたいな、聞いただけだと「うーん？」ってなる抽象的な概念を、身近な例え話でちゃんと説明してくれているところが心臓部なんですね。
これを作る過程で、「法律がとっつきにくいのは中身というより“書き方”の問題なんちゃう？」っていう気づきがあったそうで、ドキュメント文化の話にもつながっていきます。「理解してもらえるように書くのは、読み手じゃなくて書き手の責任やで」というスタンスを、法律の世界にも持ち込みたい、というチャレンジですね。
技術的にはNext.jsとCloudflareを使っていて、条文ごとに「ええやん」ボタンがあったり、ローカルに保存できたり、シェア用の画像生成ができたりと、プロダクトとしてもちゃんと作り込まれてます。今後は全文横断検索や対象法律を増やしていく構想もあって、「ネタだけじゃなく、ちゃんと使えるプロダクト」に育てていこうという意志も感じられる内容でした。法律に苦手意識のある人ほど、一回触ってみたくなる記事ですよね。
。。。。
続いて2本目。
タイトルは「新規事業を牽引する技術選定 〜フルスタックTypeScript開発の実践事例〜」。
これは、スタートアップとか新規プロダクトを作っている人には刺さる内容じゃないかなと思います。
筆者の方が、新規事業の現場で培ってきた「フルスタックTypeScript」の技術選定と運用の知見を、ぎゅっとまとめた記事です。
TypeScriptをバックエンドからフロントまで貫通させることで、型の安全性を担保しつつ、言語を統一してコンテキストスイッチを減らす。その結果として、「方向転換のしやすさ」が上がる、というのが主張の軸ですね。新規事業って、要件がコロコロ変わるじゃないですか。そのときに、型がしっかりしていると大規模なリファクタも怖くないと。
一方で、Railsみたいな「決まりきったレール」がないのが、TypeScript界隈のつらさでもあると。Webサーバー、ORM、UIライブラリ、どれも選択肢が多すぎる。そこで「世の中のスタンダードに乗る」「退屈な技術を選ぶ」という方針を掲げて、Hono＋zod-openapi、GraphQL、Next.js Server Actions、tRPC、DBはPrisma中心…といった具合に、現場目線での選択肢整理をしてくれています。
組織面の話もおもしろくて、TypeScriptで統一することで、フロント出身のエンジニアがバックエンドも巻き取って、1人で1機能まるっと担当しやすくなる。そのぶんオンボーディングは重いけど、そのコストを払う価値があるのか、という話が丁寧に書かれてます。
さらにAIとの相性の話もあって、「ここ2年でAIは新卒レベルから爆速なベテラン級まで進化した」と感じていると。人間は要件や設計に集中して、実装はAIに大きく任せる。そのとき、TypeScriptの型は、生成されたコードをチェック・修正するときの強力なガードレールになる、とまとめています。
最終的には、「フルスタックTypeScript＋AIで、変化し続けられること自体を競争力にする」という締めで、技術選定と事業戦略がちゃんとつながった、読み応えのある内容でした。
。。。。
さあ、3本目いきましょう。
タイトルは「そのテスト、本当にバグを検出できますか？——Mutation Testingでテストの質を測る」。
テスト書いてるエンジニアの方、多いと思うんですけど、「カバレッジ90％です！」って言われても、本当に安心していいの？っていうテーマです。
この記事では、「テストが通っている＝バグを見つけられる」とは限らない、という問題提起から始まります。特にAIで自動生成したテストなんかは、「とりあえずコードを実行してるだけで、結果をちゃんと検証してない」ってパターンが多い。そこで出てくるのがMutation Testing、ミューテーションテストですね。
やってることはシンプルで、ソースコードをちょっとだけ意図的に壊してみるんです。例えば、比較演算子をひっくり返すとか、条件分岐を逆にするとか。そうやって作られた“壊れたコード”をミュータントと呼んで、それをテストにかける。テストがちゃんと失敗してくれれば「KILLED」、通っちゃったら「SURVIVED」。この比率からミューテーションスコアを出して、テストの「質」を測ろう、というアプローチです。
実装にはASTを使って安全に書き換えるツールがいろいろあって、Goならgo-mutesting、JavaScript系ならStryker、Pythonならmutmut…といった具合に紹介されています。ただ、全部に適用するとめちゃくちゃ時間がかかるので、変更差分だけに絞ったり、重要なコンポーネントにだけ適用したりと、現実的な運用が必要だよと。
さらに、「等価ミュータント」といって、壊したつもりが実質的には挙動変わってないケースもあって、スコア100％は現実的ではない、という割り切りも大事だと書かれてます。
AI時代、テストの“量”を示すカバレッジだけじゃなく、“質”を示す指標としてMutation Testingを取り入れるのが重要になってくる、という締めでした。
。。。。
4本目。
タイトルは「Maestro MCPとClaude Code Skillsによる自律的なE2Eテスト作成」。
モバイルアプリのE2Eテストを触ったことある人は、「あーこれ分かるわ…」ってなる記事です。シナリオ作るのも大変だし、仕様変わるたびにメンテも地獄、っていう悩みに対して、「AIエージェントとMaestroを組み合わせて、かなり自動化してみたよ」という内容ですね。
Maestroっていうのは、モバイルアプリのE2EテストをYAMLで書けるフレームワークなんですけど、これをMCPサーバー経由でClaude Codeから操作できるようにして、テストの生成、実行、失敗したときの原因調査から修正までを、ひとつのSkillとしてワークフロー化しているのがポイントです。
特にFlutterアプリをターゲットにしていて、まずソースコードを解析してUIの構造を理解し、その情報をもとにテストフローを組み立ててくれる。UI要素を指定するときは、`Semantics(identifier)`みたいな安定したセレクタを優先的に使うようにして、足りない場合は「ここにidentifier付けませんか？」って提案までしてくれる。
デモでは、ボトムタブを切り替えるだけのテストフローを自動生成しておいて、途中で仕様変更が入ってモーダルが追加され、テストが落ちるケースを再現しています。そこでエージェントが、実際にフローを再実行してスクリーンショットを取り、画面上の要素を解析して、「あ、モーダルが邪魔してるな」と判断。モーダルを閉じるステップをFlowに自動で追記して、もう一度実行してテストを復旧させる、というところまでやってくれる。
Flutter以外でも、React Nativeなら`testID`をちゃんと付けておけば同じようなアプローチが取れるよ、っていう話もあって、「テストを書きやすいUI設計」と「AIエージェント」をセットで設計する未来が見えてくる内容でした。チームごとにSkillを拡張して、自分たちの開発ルールに合ったE2E運用を作っていこう、という提案も含まれてます。
。。。。
そしてラスト、5本目。
タイトルは「メモリが潤沢ではないPCでローカルLLMにコーディング質問した結果」。
これは、手元のマシンでローカルLLMを動かしてみたい人、かなり参考になる実験記事ですね。
環境は、メモリ18GBのMacBook Pro。ここでRubyとGoの「ちょっと意地悪な落とし穴」系の質問をいくつか用意して、ローカルLLMたちに答えてもらう、という形です。
メモリ的に実用ラインに乗るのは、だいたい9〜10GB以下のモデル。今回試されたのは、Gemma 4、Qwen 3.5、Qwen 2.5 Coderの3つで、どれも動作としては快適だったそうです。
結果としては、Ruby・Goどちらも「バグの場所を特定する」能力はわりと高いものの、「じゃあどう直すの？」という修正コードの部分とか、言語仕様の細かいところになると差が出てくる。RubyのProcとlambdaのreturnの違いとか、文字列がミュータブルかどうかの挙動、Goのdeferが実行されるタイミングなんかは、誤答も目立ったと。
モデルごとの傾向としては、RubyならQwen 2.5 Coderが比較的よく、GoならGemma 4が安定、という印象だったそうですが、クラウド側で試したKimi K2.6は、両方の言語で全問正解と、やっぱり雲の上には勝てないね…という結果になっています。
そこからの結論として、「ローカルLLMを実務で使うなら、言語ごとにモデルを使い分けつつ、プロンプトも工夫してあげる必要がある。ただし、最終判断は必ず経験のある人間がレビューする体制が前提だよね」と。プライバシーやオフライン性を取る代わりに、精度面でどう折り合いをつけるか、リアルなバランス感覚が語られていました。
。。。。
というわけで、今日のzenncastは、
・関西弁で法律を読み解く「おおさかけんぽう」のお話
・新規事業を支えるフルスタックTypeScriptとAIの実践知
・Mutation Testingでテストの“質”を測るというアプローチ
・MaestroとClaude Code Skillsで自律的なE2Eテストを回す仕組み
・メモリ控えめPCでローカルLLMにコーディング質問してみた検証レポート
この5本を駆け足でお届けしてきました。
気になった記事があったら、詳しくはショーノートから元の記事をぜひチェックしてみてください。今日のトークで触れきれなかった細かいノウハウやコードの話も、そちらでじっくり読めるようになっています。
番組の感想や、「このテーマもっと深掘りしてほしい！」みたいなリクエストも、いつでもお待ちしています。あなたの一通が、次回のzenncastのネタになるかもしれません。
それでは、そろそろお別れの時間です。
ここまでのお相手はマイクでした。
また次回のzenncastでお会いしましょう。いってらっしゃい！