どうもー、おはようございます。マイクです。
今朝も「zenncast」お付き合いありがとうございます。
今日は2026年5月29日、金曜日の朝7時。
この時間は、テック好きのみなさんと一緒に、Zennで話題のトレンド記事をゆるっと追いかけていく時間です。
コーヒー片手に聞いてる方も、通勤・通学のおともにしてくれている方も、最後までよろしくお願いします。
さて今日は、Zennのトレンドから、全部で5本の記事をご紹介していきます。
AIモデルの細かい「性格」の違いから、開発補助ツールの賢い使い分け、Copilotの新機能、そして自走するClaude Codeの話、最後はPlantUMLを安全に快適に使うためのツールまで、かなり濃いラインナップです。
ということで、さっそく1本目いってみましょう。
……。 。
最初にご紹介するのは
「Opus 4.7 と GPT-5.5 のレビュー特性を統計的に明らかにした（オトナの自由研究 #19）」という記事です。
これね、タイトルからしてすでに“ガチ研究”なんですけど、中身もかなり本気です。
Raspberry Pi 5 の上で、4つのPythonタスクを180試行、それをOpus 4.7とGPT-5.5にレビューさせて、合計720ケースを統計比較してるんですね。評価軸はReliability、Security、Maintainability、Safetyの4つ。まずおもしろいのが「全体の平均点はほぼ同じ」っていう結論。つまり、総合点だけ見ると「どっちが圧勝」という感じではない。
じゃあどこで差が出るかというと、軸ごとの“性格”です。
Maintainability、保守性のところではOpus 4.7がかなり辛口で、「コメント少なすぎ」「説明薄い」みたいな、読み手の負担に効いてくるポイントを細かく減点していく。まさに「読みやすさ警察」みたいな採点者。一方でSafety、安全性のところはGPT-5.5がすごく厳しくて、タスクに書かれてない`conftest.py`とか`pytest.ini`を勝手に追加してると、「スコープ外だよね？」ってことで、内容が正しくてもがっつり減点したり、0点にしたりする。「明示されたルールは絶対守るマン」なんですよね。
スコアの付け方も違っていて、Opusは5点刻み中心の離散的なスコア、GPT-5.5は中間点や低スコアも幅広く使う連続的なスコア。なので、実務で使うなら「読みやすさ・保守性重視ならOpus」「仕様・制約順守をガチガチに見たいならGPT-5.5」、もしくは両方にレビューさせて差分を人間が見る、なんて運用が良さそうだよ、という話でした。
得点の平均値より、「どんな観点で減点するか」がモデルごとに全然違う、というのが伝わる面白い自由研究でした。
……。 。
続いて2本目。
タイトルは「Claude CodeとCodexを2ヶ月使い比べて分かった選び方 — settings.jsonを育てた側が速い」。
これはNext.js 16とReact 19の実プロジェクトで、Claude CodeとCodexを2ヶ月ガチ比較した話です。
結論がすごく刺さるんですが、「どっちが速いかはツールのスペックより“設定にどれだけ投資したか”で決まる」というもの。特にClaude Code側のsettings.jsonですね。permissionsやSkillsをしっかり作り込んであげると、既存コードのコンテキストを長く掴みつつ、「このプロジェクトっぽい」命名やファイル構成に自然に沿ったコードをサッと出してくれる。だから、日常的なちょっとした修正とか、機能追加みたいな仕事は、Claude Codeに寄せたほうが最速になるよ、と。
一方でCodexは、大規模変更とか、多ファイルの一括修正に強い。
クラウドで並列実行できたり、GitHubとがっつり統合されていてPRの自動レビューもすぐ使えるので、「でかい改修」「レビューの自動化」みたいなところで真価を発揮する。
コードの傾向も違っていて、Claude Codeは「今あるコードとの一貫性重視」、Codexは「一般的なベストプラクティス寄り」。なので、プロジェクト立ち上げ期はCodex、運用に入ったらClaude Code、みたいな役割分担が合っているんじゃないか、という提案になっています。
コストは2つ合わせて月220ドルぐらいなんですが、「開発時間が浮きまくるので初日で回収した感覚」とのことで、日常開発はClaude Code、大きめの変更とPRレビューはCodex、という棲み分け。
「どっちがいい？」じゃなくて「どの作業にどっちを使う？」という視点、大事だなぁと思わされる記事でした。
……。 。
3本目は、GitHub Copilotユーザー必見の内容です。
タイトルは「GitHub Copilot CLIの/chronicleで課金体系の変更に備えよう」。
Copilot CLIに`/chronicle`という、ちょっと実験的なコマンドがあるんですね。これは、ローカルに溜まっているセッション履歴、`session-state`とかSQLiteの`session-store.db`を分析して、「どんな使い方してきたか」をレポートしてくれる機能です。
使うには`/experimental on`などが必要なんですけど、そこから`/chronicle standup`で前日の作業要約を出したり、`search`で履歴を検索したり、`tips`で使い方の改善ポイントをもらったりできる。なかでも注目されているのが`cost-tips`というサブコマンドです。
2026年6月からCopilotがトークン課金に移行する、という文脈があって、`cost-tips`を使うと「あなた、この指示の出し方はトークン的にもったいないですよ」とか、「@指定で対象ファイルを絞りましょう」「/compactを活用しましょう」「長期タスクを分割しましょう」「スキル指定をちゃんと明示しましょう」みたいな、コスト削減の観点からのアドバイスがもらえる。
つまり、ただAIに頼るんじゃなくて、「過去の会話ログを振り返って、プロンプトの出し方そのものを改善していく」ツールなんですね。
さらに`improve`というサブコマンドでは、この履歴を元に`.github/copilot-instructions.md`の改善案も出してくれるので、個人だけじゃなくて、チームや組織全体としてのCopilotの使い方をチューニングしていける。
「AIの使い方をAIに分析させて、次の使い方を良くしていく」というメタ的なアプローチがすごく面白い記事でした。
……。 。
4本目は、タイトルからしてワクワクします。
「1 行渡すと Claude Code が 1 時間自走する ─ E2E テスト駆動で新機能を作らせた話」。
これは社内のSlack上で動くAIエージェントに、ツールをどんどん追加していく現場での話なんですが、「Claude Code が『実装しました！』って言うのに、Slack上では動かない」という、開発あるあるな問題が頻発していた。
ユニットテストだけではカバーしきれない「本当にSlackで動くか」という層まで含めて検証したい、ということで、`/e2e-dev`というSlackスラッシュコマンドを作ったんですね。
やることはシンプルで、「<Slackでの発話> → <期待する応答>」を1行のE2Eテストケースとして渡すだけ。
そこから先は、Claude Codeが最大5ループ、約1時間ぐらい自走します。ベースライン計測から始まって、ギャップ分析をして、必要なAPIやLambdaの実装・修正、テスト実行、dev環境へのデプロイ、さらにSlack上でのE2E検証、最後に結果レポートまで。一連の流れを自動で回してくれるんですね。
肝になっているのが「完了条件」をはっきりさせたこと。
「E2EテストがPASSしていること」と「人間が実際の動作を目で見てOKを出すこと」の2つを条件にして、「実装した」と「実際に動く」の境界を明確にしました。
また、テストケースの書き方も重要で、「なんとなく成功してそう」ではなく、機械が判定できるレベルまで期待結果を具体的に書く必要がある。ここが曖昧だと、アウトプットの品質もブレる、という学びがあったそうです。
さらにAPI側の変更を含むサブフローや、実装前にベースラインを測っておく設計も効いていて、人間は途中経過を逐一チェックせず、他の作業を並行できるようになった。
最終的には、Slack Bot用のLambdaで「この発話にこの応答が返る」というところまで観測しながら、新機能を安心して任せられる仕組みになっている、という事例でした。
「1行のE2Eケースで、AIが1時間ちゃんと働いてくれる」世界、いいですよね。
……。 。
そして今日最後、5本目の記事です。
タイトルは「Javaなしで安全に使えるPlantUMLビューア『pumlv』」。
PlantUMLを使う方なら、一度は悩んだことがあると思うんですが、ローカルで快適にプレビューしようとすると、Javaランタイムが必要なツールが多かったり、VSCodeやNeovim用の拡張に引きずられたりするんですよね。
オンラインエディタはお手軽なんだけど、機密情報とか社外秘の設計図を外部サービスに送るのはちょっと…という問題もある。そこで著者が開発したのが、この「pumlv」です。
pumlvはGo製の単一バイナリで動くビューアで、組み込みのフロントエンド（React + plantuml.js）をローカルHTTPサーバで配信します。ファイルの変更検知にはfsnotify、ブラウザへの通知にはSSEを使っていて、保存するとすぐブラウザ上の図が更新される。
ポイントは、レンダリングがブラウザの中だけで完結していて、サーバは127.0.0.1にしかバインドしていないので、外部にデータが飛んでいかないという点です。つまり、「Javaいらない」「外部送信なし」「特定エディタにも縛られない」という三拍子揃ったPlantUMLビューアになっている。
macOSとLinuxで動作し、ディレクトリ単位・単一ファイル・複数パスの監視ができるので、普段使っているエディタはそのままに、ブラウザだけ横に置いておけばOK。拡張子やポートの指定もできて、2000行クラスのER図でも実用的に動くということで、かなり本格的なツールです。
「Java入れたくないけど、ローカルで安全にPlantUML使いたい」というニーズに、きれいにハマる解決策だなぁと感じました。
……。 。
というわけで、今日のzenncastは、Zennのトレンド記事を5本ご紹介してきました。
ざっとおさらいすると、
まずはOpus 4.7とGPT-5.5を720ケースで比較して、それぞれの「採点者としての性格」を明らかにした自由研究。
次に、Claude CodeとCodexを2ヶ月使い比べて、「設定を育てたツールが最速になる」「作業内容で使い分けよう」という話。
3本目は、Copilot CLIの`/chronicle`で自分たちの使い方を分析して、トークン課金時代に備えよう、というメタな改善の話。
4本目は、1行のE2EテストケースからClaude Codeを1時間自走させて、「実装した」と「ちゃんと動く」をつなぐ仕組みを作った事例。
そして最後は、Javaなし・外部送信なしでPlantUMLを快適にプレビューできるビューア「pumlv」の紹介でした。
気になる記事があった方は、詳しい内容や元の記事へのリンクはショーノートにまとめてありますので、そちらからぜひチェックしてみてください。
この番組「zenncast」では、みなさんからの感想や、「こんな記事を取り上げてほしい」「こういうテーマで話してほしい」といったリクエストもお待ちしています。
ラジオネームを添えて送っていただけると、番組の中でご紹介させていただくかもしれません。
それでは、そろそろお別れの時間です。
今日も聞いてくれてありがとうございました。マイクでした。
次回のzenncastで、またお会いしましょう。ではでは、いってらっしゃい。