登壇ネタの「一般化」って、具体的にどうやるの？ 前回「発表ネタで一番大事なのは一般化」と語った kuniwak に、へんてこ が自分の実ネタ「チームで人間のコードレビューを全廃して半年、大きな事故なし」を持ち込み、登壇できる形に一般化するまでを公開添削してもらいました。

AI コードレビュー＋テスト、実装前に「なぜ変えるのか」を GitHub Issue に言語化し、影響が大きいものだけ事前レビュー、実装後はギャップを洗い出す——そんなへんてこ のフローに対して、kuniwak は「金融や航空宇宙の人が聞いたらどう思う？」と想定聴衆を広げたり切り捨てたりしながら一般化を進めます。刺さってほしくない人に刺さると何が起きるのか、発表で本当に伝わるのは何割なのか、聴衆に何を持ち帰ってもらえば「大成功」なのか。後半はネタに合わせたイベントの選び方、カンファレンスのアンケート結果の読み方、そして勉強会主催者目線のプロモーション事情（X 広告の1クリック単価やインフルエンサー登壇の効果）まで話が広がります。

▼チャプター

00:00 オープニング

01:10 事例紹介：コードレビューの廃止

04:32 想定聴衆の絞り込みと一般化のプロセス

11:19 ネタに合わせた発表場所の選び方

19:28 イベントの規模とフィードバックの獲得

23:40 勉強会のプロモーションとコミュニティの活用

30:35 エンディング

▼この回で話していること

・人間のコードレビューをなくして AI コードレビューとテストに置き換えた開発チームの事例

・登壇ネタの一般化とは？ 想定聴衆を「足す」「切り捨てる」選択の連続

・タイトルで刺さる人を選ぶ理由——想定外の聴衆に刺さると炎上する

・発表は3割しか伝わらない：How は資料に任せ、次のアクションにつながる「取っ手」を残す

・説得力を上げる数字の出し方（リリース頻度×事故ゼロ）

・小さな勉強会と大きなカンファレンス、登壇経験を積むならどっち？ iOSDC のルーキーズLT枠も

・カンファレンスのアンケート結果の読み方：回答率と評価分布の見方

・勉強会の告知・集客方法：X 広告のフォロワーターゲティング、インフルエンサー登壇、Slack コミュニティ

▼こんな人におすすめ

・社内の取り組みを勉強会やカンファレンスの登壇ネタにしたいエンジニア

・AI 時代のコードレビューのあり方や、レビュー待ちの解消に悩んでいる開発チーム

・勉強会を主催していて、集客やプロモーションに悩んでいる人

▼関連リンク

・くわラジ 公式サイト: https://kuwa-raji.henteko07.com/

・くわラジ Spotify: https://open.spotify.com/show/6uUjalUT94ugSgtLI5WF6a

・くわラジ Apple Podcasts: https://podcasts.apple.com/jp/podcast/id1894147982

・Claude Code Code Review ドキュメント: https://code.claude.com/docs/ja/code-review

・iOSDC Japan 2026: https://iosdc.jp/2026/

・connpass: https://connpass.com/

・X 広告 フォロワーターゲティング: https://business.x.com/ja/advertising/targeting/follower

・vim-jp のチャットルーム（Slack）: https://vim-jp.org/docs/chat.html

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアの kuniwak に一般エンジニアの へんてこ が「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想は X でハッシュタグ #くわラジ をつけてつぶやいてください。

─────────────

YouTube: https://youtu.be/3PZdb--AJW4

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

勉強会やカンファレンスで登壇し続けるには、発表ネタをどう作ればいいのか？ 登壇回数50回超、年に4〜5回のペースで発表を続けるスーパーエンジニア kuniwak に、一般エンジニア へんてこ が「ネタの作り方」を根掘り葉掘り聞きました。答えの中心にあるのは「一番大事なのは一般化すること」という一言。自社固有の話が刺さらない理由から、一般化しすぎると逆に解けなくなるジレンマまで、登壇ネタの設計論を掘り下げます。

前半は「ネタが先か、場が先か」。kuniwak はネタを先に作り、それに合う発表の場（JaSST・iOSDC・builderscon のようなカンファレンスから小さな勉強会まで）を選ぶスタイルで、へんてこ は「自分は逆だった」と気づきます。聴衆の層を読むコツとして「参加費が有料か無料か」で求められる内容が変わる話や、招待講演では空気を読むという裏話も。中盤はスライド作りのプロセス。伝えたいことを3行で書き出し、マインドマップでアウトラインを組み、テンプレートに流し込んで20分の発表を1〜2時間で仕上げる「職人技」を公開します。ブログ執筆で Gemini を使う理由や、AI が作ったスライドへの率直な評価も飛び出します。終盤は「日常のタスクを一般化して種を溜め、成功したものだけ発表する」というネタのストック術、AI 時代に自作ツールや OSS の発表はまだ価値があるのかという議論、そして CFP やイベントの探し方（なければ勉強会を自分で作る）へ。最後にたどり着く結論は「課題を探し続けろ」です。

▼チャプター

00:00 導入

04:17 発表ネタを作るための「一般化」

11:59 聴衆のニーズに応じた発表設計

17:21 スライド作成のプロセス

21:21 課題発見から始まるネタ作り

32:20 発表イベントの探し方

37:48 エンディング

▼この回で話していること

・勉強会・カンファレンスで登壇し続けるコツ：年4〜5回・累計50回登壇の kuniwak の場合

・登壇ネタの作り方で一番大事なのは「一般化」——自社固有の話が刺さらない理由

・一般化しすぎると「主語がでかい」問題：どこまで一般化するかのバランス

・ネタが先か、イベントが先か？ 発表テーマから登壇する場を選ぶ考え方

・聴衆の層の読み方：参加費の有料・無料で求められる発表内容はどう変わるか

・発表スライドの作り方：伝えたいことを3行に書き出し、マインドマップでアウトラインを作る

・20分の発表を1〜2時間で作るプロセスと、AI にスライドを作らせるより速い理由

・自作ツール・OSS の発表は AI 時代でも需要があるのか——AI は How を作り、What と課題発見は人間の仕事

・CFP・登壇イベントの探し方と、勉強会がなければ自分で作るという選択肢

▼こんな人におすすめ

・勉強会やカンファレンスで登壇したいけれど、発表ネタが思いつかないエンジニア

・CFP に応募しても採択されない、または一度登壇したあと続かなくなってしまった人

・技術ブログや OSS などのアウトプットを、登壇につなげたいと考えている人

▼関連リンク

・くわラジ 公式サイト: https://kuwa-raji.henteko07.com/

・くわラジ Spotify: https://open.spotify.com/show/6uUjalUT94ugSgtLI5WF6a

・くわラジ Apple Podcasts: https://podcasts.apple.com/jp/podcast/id1894147982

・Codex を使って障害対応の机上演習をやってみよう（Coincheck Tech Blog / kuniwak）: https://tech.coincheck.blog/entry/codex-ttx

・JaSST ソフトウェアテストシンポジウム: https://jasst.jp/

・Vint（kuniwak 作の Vim script Lint）: https://github.com/Vimjas/vint

・『イシューからはじめよ［改訂版］』（安宅和人・英治出版）: https://eijipress.co.jp/en/products/2356

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアの kuniwak に一般エンジニアの へんてこ が「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想は X でハッシュタグ #くわラジ をつけてつぶやいてください。

─────────────

YouTube: https://youtu.be/X8Wueh1G8Qc

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

ポッドキャストを続けるコツとは何か？ 「9割の番組は3話で止まり、残った番組の9割も20話までに止まる」と言われるほとんどのポッドキャストが21回目を迎えられない中、くわラジは今回で第21回。スーパーエンジニア kuniwak と一般エンジニア へんてこ が、約5か月・20エピソードを続けてこられた理由を「準備しすぎない」「気負わない」「間違えたら謝る」の3つで振り返ります。

前半は Spotify・Apple Podcasts・YouTube のアナリティクスを Claude Code に集計させた「数字で見るくわラジ」。累計再生数、1エピソードあたりの再生数、最後まで聞いてもらえた割合（完聴率）、リスナーの年齢層と男女比、そして人気回・不人気回の傾向まで、個人ポッドキャストの数字をそのまま公開します。なぜか YouTube だけで再生数が跳ねた #19 printfデバッグ回の謎も。中盤は印象に残っている回の振り返りです。kuniwak が挙げるのは「間違ったことを言ってしまった」と自覚している2つの回（#13・#20）で、そこから「アウトプットすると理解の甘さが浮き彫りになる」「ポッドキャストは生成AIで偽れない媒体」という話へ広がります。へんてこ の推し回は #07「正論は、出禁になる。」。終盤は今後話したいテーマとして、形式手法の入門、勉強会で発表する技術、そして vim-jp Slack からリクエストのあった「コーン茶」まで。終了すると聞いた「エンジニアの楽園 vim-jp ラジオ」への言及と、恐れ多い野望も飛び出します。

▼チャプター

00:00 オープニング

03:45 数字で振り返るくわラジ

11:07 印象に残っているエピソード

20:21 今後話したいテーマ

25:42 エンディング

▼この回で話していること

・ポッドキャストが続かない理由と、21回目まで到達する番組が少ないという統計

・くわラジが継続できている理由：準備しすぎない・気負いすぎない・間違えたら謝る

・Claude Code でポッドキャストのアナリティクス（Spotify / Apple Podcasts / YouTube）を集計してみた

・個人ポッドキャストの再生数・完聴率・リスナー属性はどれくらい？

・YouTube で再生数が伸びた回・伸びなかった回から見えるアルゴリズムの傾向

・kuniwak が「間違えた」と振り返る回と、アウトプット（言語化）で理解の穴が浮き彫りになる話

・ポッドキャストは生成AIで偽れない媒体か？ライブ感と人間がやる意味

・へんてこ の推し回 #07「正論は、出禁になる。」

・今後話したいテーマ：形式手法入門・勉強会での発表術・コーン茶

▼こんな人におすすめ

・ポッドキャストや技術ブログなどの情報発信を始めたい、または続かずに止まってしまったエンジニア

・個人ポッドキャストの再生数・完聴率・リスナー層のリアルな数字を知りたい人

・くわラジを最近聞き始めて、どの過去回から聞けばいいか知りたい人

▼関連リンク

・くわラジ 公式サイト: https://kuwa-raji.henteko07.com/

・くわラジ Spotify: https://open.spotify.com/show/6uUjalUT94ugSgtLI5WF6a

・くわラジ Apple Podcasts: https://podcasts.apple.com/jp/podcast/id1894147982

・Podnews「How to outlast 99% of podcasts: four simple rules」: https://podnews.net/article/four-rules-to-outlast-almost-every-other-podcast

・形式手法とは？（ディペンダブル・システムのための形式手法の実践ポータル）: https://formal.mri.co.jp/outline/

・エンジニアの楽園 vim-jp ラジオ: https://vim-jp-radio.com/

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアの kuniwak に一般エンジニアの へんてこ が「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想は X でハッシュタグ #くわラジ をつけてつぶやいてください。

─────────────

YouTube: https://youtu.be/gk4vZoDe5ss

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

ライフプランシミュレーターを自作すると何がわかるのか？ スーパーエンジニア kuniwak が、Googleスプレッドシート製の家計シミュレーションを Go + Makefile + TSV のパイプラインに作り直し、AI（Claude Code）と一緒に約3万通りの人生シナリオを計算した話です。持ち家 vs 賃貸、老後資金、インフレ率、金融危機……「自分の場合はどうなるのか」を検算し続けた結果、行き着いたのは「大きく勝つより負けない」という結論でした。

きっかけは家を買うかどうかの決断。賃貸を続けて長生きした場合に資金が尽きるという試算が、持ち家の後押しになったそうです。スプレッドシートではバージョン管理もA案・B案の比較もつらい、という へんてこ にも刺さる悩みから、Makefile で差分ビルドできる純粋関数的なパイプラインへ移行。さらに確定申告書（e-Tax）と突き合わせて税金計算を1円単位で一致させたところ、AIが確定申告のミスまで指摘してくる「AIファイナンシャルプランナー兼税理士」状態に。約8個のパラメーターを掛け合わせて資産推移を量産すると、最も効くのはインフレ率という外部環境だった、という発見も語られます。後半は、マネーフォワード ME の「計算対象外」フラグの落とし穴や、銀行明細・クレジットカード・Eco通帳で家計データを信頼できる形に集める実践術、そして SQLite ではなく TSV と関係代数を選んだエンジニアリング上の判断まで。作ったツールは OSS として公開予定とのことです。

▼この回で話していること

・ライフプランシミュレーターとは？収入・支出から将来の資産推移を試算する仕組み

・持ち家 vs 賃貸を自分の条件で検算したら何がわかったか

・スプレッドシートの限界：バージョン管理・ブランチ（A案/B案/C案の比較）ができない

・Go + Makefile + TSV パイプラインで AI にライフプランを量産させる方法

・e-Tax の確定申告書と突合して税金計算を1円単位で検算、AIファイナンシャルプランナーの実力

・約3万通りのシナリオ分析でわかった、資産に一番効くパラメーター（インフレ率・金融危機・年金受給時期）

・リスク選好とポートフォリオ：S&P500 一本か、債券を混ぜて利回り3%で守るか

・マネーフォワード ME の「計算対象外」の落とし穴と、銀行明細・クレカ・Eco通帳で家計データを集めるコツ

・SQLite ではなく TSV + 関係代数を選んだ理由と、状態を持たない純粋関数コマンドの設計

・未来が予測できることで失われる幸せ、そして OSS 公開予定

▼こんな人におすすめ

・老後資金や持ち家 vs 賃貸を、一般論ではなく自分の数字でシミュレーションしたいエンジニア

・Claude Code などの AI を家計管理・確定申告の検算・FP相談に使ってみたい人

・スプレッドシート管理に限界を感じていて、Makefile や TSV パイプラインでの再現可能な計算に興味がある人

▼関連リンク

・金融庁 ライフプランシミュレーター: https://www.fsa.go.jp/policy/nisa2/lifeplan-simulator/

・FP-UNIV ライフプランシミュレーション: https://fp-univ.net/

・マネーフォワード ME サポート「計算対象のチェックを外すとどうなりますか」: https://support.me.moneyforward.com/hc/ja/articles/900003501566

・三菱UFJ銀行 Eco通帳（インターネット通帳）: https://www.bk.mufg.jp/tsukau/eco_tsuchou/index.html

・OECD 対日経済審査 2026（日本語概要）: https://www.oecd.org/content/dam/oecd/en/topics/policy-sub-issues/economic-surveys/Japan-economic-survey-2026-brochure-JP.pdf

・関係代数（関係モデル） - Wikipedia: https://ja.wikipedia.org/wiki/関係代数_(関係モデル)

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアの kuniwak に一般エンジニアの へんてこ が「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想は X でハッシュタグ #くわラジ をつけてつぶやいてください。

─────────────

YouTube: https://youtu.be/5EEq54rQOI8

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

printfデバッグやステップ実行に頼るデバッグは「負け」——その心は、デバッグのしやすさ（デバッガビリティ）はデバッグ手法ではなく設計で決まるから。今回はスーパーエンジニアのkuniwakに、一般エンジニアのへんてこが「熟練者と初学者で差が出るデバッグのやり方」を聞きました。

printfを仕込んで消すその場しのぎの確認ではなく、まず再現テストを書く。バグが出るのはアルゴリズムとドメイン知識が混ざった「もやっとした場所」だから、ソート関数と大小比較のように分離してプロパティベーステストで固める。

iOSアプリなど状態を持つクライアントサイドでは、状態遷移をログに残す設計にしておけばAppleの審査で指摘された課金バグも一瞬で特定できる——という実話も登場します。

さらにRedux/TCAのシングルデータストアが本当にテストしやすいのかへの異論、「仮説を立てる」より「切り分け」で二分探索的に原因を追い詰める考え方まで、デバッグ観がひっくり返る回です。

▼この回で話していること

・printfデバッグ・ステップ実行が「負け」な理由と、ログ出力（debug/traceレベル）との違い

・デバッグの代わりに再現テストを書くという考え方

・バグはテスト不足のサイン——デバッガビリティの高い設計とは

・アルゴリズムとドメイン知識の分離（ソート関数と比較関数の例）とプロパティベーステスト

・ステップ実行が正当化される例外：パフォーマンス優先のホットスポット

・クライアントサイド（iOS）のデバッグ：状態機械（ステートマシン）と状態遷移ログ

・Flux/Redux/TCAのシングルデータストアはテストしやすいのか？——インターフェース分離原則から考える

・「仮説を立てる」より「切り分け」——二分探索で原因を特定するデバッグ手順

▼こんな人におすすめ

・printfデバッグから抜け出したい、デバッグのやり方を体系的に知りたいエンジニア

・テストが書きにくいコードに悩んでいて、テストしやすい設計を学びたい人

・Redux/TCAなどの状態管理アーキテクチャの採用を検討している人

▼関連リンク

・Redux 公式サイト: https://redux.js.org/

・The Composable Architecture (TCA): https://github.com/pointfreeco/swift-composable-architecture

・StoreKit（Apple Developer Documentation）: https://developer.apple.com/documentation/storekit

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアのkuniwakに一般エンジニアのへんてこが「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想はハッシュタグ #くわラジ でお寄せください。

─────────────

YouTube: https://youtu.be/D4bOru9qBEY

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

仕事しない同僚や部下にイライラしてモチベーションが下がる——そんなとき、どう対処すればいいのか？今回のくわラジは、エンジニアの職場あるあるでもある「働かない人へのフラストレーション」との向き合い方を深掘りします。

「他人の仕事は他人の仕事と割り切る」というkuniwakに、へんてこが「でもサボりを見逃してない？」と食い下がるところから、話は性善説と性悪説の使い分け、採用の失敗と人事評価の構造、そして「人はコントロールできない」という核心のメンタルモデルへ。

後半は上司との1on1で「期待に添えてますか？」と役割を確認する習慣や、オープンクエスチョンではなく案を持って提案するコミュニケーション術など、明日から使える実践的な話が続きます。イライラの正体が「見積もりの甘さ」と「情報の非対称性」にあるという分析は必聴です。

▼この回で話していること

・仕事しない同僚にイライラするのはなぜ？モチベーションが下がる構造

・自分の実力とチームの実力を切り離す考え方

・フラストレーションの正体は「見積もりの甘さ」と「情報の非対称性」

・性善説と性悪説の使い分け——現場は性善説、評価・採用制度は性悪説

・「人はコントロールできない」——選択肢を提示して相手に委ねるメンタルモデル

・上司との1on1で「期待に添えてますか？」と役割を確認する習慣

・オープンクエスチョンで聞かない——A案B案C案を持って提案する

・「信頼はするが期待はしない」——リーダーの心の守り方

▼こんな人におすすめ

・仕事しない同僚・部下へのイライラで消耗しているエンジニア

・チームの成果と自分のモチベーションの折り合いに悩んでいる人

・1on1やマネジメントでの役割・期待のすり合わせ方を知りたい人

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアのkuniwakに一般エンジニアのへんてこが「もっと詳しく教えてください」と質問しながら技術やエンジニアの仕事を深掘りする、ゆるくてディープな技術雑談番組です。

─────────────

YouTube: https://youtu.be/m04Ly5IYq-o

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

AIコーディングエージェント全盛のいま、なぜあえてVimに戻るのか？Claude Codeを使い込んだ先に待っていたのは、まさかのVim回帰とCLI/TUI時代の到来でした。スーパーエンジニアkuniwakの約15年にわたる開発環境の変遷を一気にたどります。

Perlの会社で素朴にVimを使っていた新人時代、クラッシュ多発のXcodeからJetBrains AppCodeに逃げ込んだiOS開発時代、「どの言語でもIDEがある」JetBrains教の時代。

そして定理証明支援系Isabelleで数学の証明に朝活で挑んだ日々を経て、Claude Code・Codex・Geminiを使い比べるAI時代へ。

へんてこの「もっと詳しく教えてください」に答えながら、「1+1=2はどう証明するのか」から「AI時代にエンジニアはどう生き残るか」まで、ゆるく深く語ります。

▼この回で話していること

・Vim→Xcode→JetBrains（AppCode/Rider/CLion）—エンジニア15年の開発環境遍歴

・定理証明支援系とは？Isabelleで「1+1=2」を証明する仕組み（ペアノの公理）

・SledgehammerとSMT/SATソルバー、定理証明ライブラリのセキュリティリスク

・Claude Code vs Codex vs Gemini—AIコーディングエージェントの使い分けと乗り換えの理由

・AIの日本語を自然にするjapanese-tech-writingスキル×Geminiという最強の組み合わせ

・「モデルよりワークフロー」説—サブエージェントによるコードレビューとフォーカスのさせ方

・Claude CodeのCtrl+GでVimが開く—Vim回帰とプラグイン断捨離、それでも手放せないvim-surround

・全部70点のAIに人間は「偏愛」で勝つ—AI時代のエンジニア生存戦略とエネルギー効率の話

▼こんな人におすすめ

・Claude Code・Codex・GeminiなどAIコーディングエージェントの使い分けに悩むエンジニア

・Vim・Neovim・ターミナル環境が好きな人、エディタ遍歴に一家言ある人

・AI時代のエンジニアのキャリア・生存戦略を考えたい人

▼関連リンク

・Vim: https://www.vim.org/

・vim-surround: https://github.com/tpope/vim-surround

・Claude Code: https://claude.com/claude-code

・Isabelle: https://isabelle.in.tum.de/

・Lean: https://lean-lang.org/

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアのkuniwakに一般エンジニアのへんてこが「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。感想はハッシュタグ #くわラジ でお寄せください。

─────────────

YouTube: https://youtu.be/h6I-_B9dpa4

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

巨大な仕様書を全員に「読ませる」運用は、もう負けかもしれません。今回のテーマはSSoT（Single Source of Truth＝信頼できる唯一の情報源）。信頼できる唯一の仕様書を一つだけ管理し、そこからCS担当者向け・パートナー企業向けなど、読む人ごとに最適化された「専用ビュー」を自動生成するという仕様書運用の考え方を深掘りします。

スーパーエンジニアのkuniwakが、巨大なシーケンス図・状態遷移図から必要な部分だけを畳んで見せる仕組みや、GitHub Actionsで日本語の仕様書から英語版を自動翻訳するパイプラインなど、実際の現場で運用している実例を紹介。

「ドキュメントが腐る」あるあるを、コミットごとの自動生成と生成AIでどう解決するのかが具体的にわかります。後半は仕様記述の理論的バックグラウンドへ。

契約による設計（Design by Contract）の事前条件・事後条件、「アサートを書けばいいんでしょ」というよくある誤解、ホーア論理からBDDまで、へんてこの質問でゆるく噛み砕いていきます。

▼この回で話していること

・SSoT（信頼できる唯一の情報源）とは？仕様書運用への応用

・巨大なシーケンス図・状態遷移図から「読む人専用ビュー」を自動生成する仕組み

・ドキュメントが腐る問題を防ぐ、コミットごとの自動生成と自動英訳パイプライン

・C4モデルのコンテキスト図とシーケンス図の整合性をツールで検証する実例

・仕様記述の専門家「マニピュレーター」という役割と、AI・スキル化による代替

・契約による設計（Design by Contract / DbC）とは？事前条件・事後条件とアサートの正しい理解

・RESTful APIの404は事前条件違反ではない？契約による設計でAPI仕様を読み解く

・巨大ドキュメントをLLMにそのまま読ませる vs 読む人ごとにビューを分ける

▼こんな人におすすめ

・仕様書や社内ドキュメントが「腐る」問題に悩んでいるエンジニア・PM

・契約による設計（DbC）を名前だけ知っていて、正しい理解を手に入れたい人

・生成AI時代の仕様書・ドキュメント運用の実践例を知りたい人

▼関連リンク

・信頼できる唯一の情報源（Wikipedia）: https://ja.wikipedia.org/wiki/信頼できる唯一の情報源

・C4 model: https://c4model.com/

・PlantUML: https://plantuml.com/ja/

・契約プログラミング（Wikipedia）: https://ja.wikipedia.org/wiki/契約プログラミング

・ホーア論理（Wikipedia）: https://ja.wikipedia.org/wiki/ホーア論理

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアのkuniwakに一般エンジニアのへんてこが「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。

─────────────

YouTube: https://youtu.be/pLIjwXXqGW4

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

LLM（AI）にシーケンス図や設計のレビューを任せたら、なぜ見逃しだらけになるのか？答えは「漠然と探させている」から。ルールベースの検査ツールで怪しい箇所を列挙し、LLMの注意を「意味の構造」にフォーカスさせると、検出精度がほぼ100%まで上がる——そんな検査ツールの作り方を深掘りする回です。

スーパーエンジニアのkuniwakが開発中の、仕様と実装設計を検査するツールの裏側を一般エンジニアのへんてこが根掘り葉掘り聞いていきます。

PlantUMLで書いたシーケンス図の「矢印の連続性」をGo製ツールで解析してLLMにジャッジさせる仕組み、C4モデル（コンテキスト図・コンテナ図）との整合性チェック、そして「誤警告してもいい」というlintツールとの決定的な違いまで。

後半は、LLMに良い設計をさせる鍵としてのテスト駆動開発（TDD）とロードマップ、プライベート関数という抜け道の塞ぎ方、さらにLLMが得意なプログラミング言語と型検査の「税金」の話へと展開します。

AIコーディングエージェントのレビュー精度に悩んでいる人ほど刺さる実践知が詰まっています。

▼この回で話していること

・シーケンス図の落とし穴とは？矢印の連続性に隠れた「暗黙のシステム」

・LLMが図の検査で見逃しを連発する理由——漠然とした探索と計算が苦手

・ルールベースの検査ツール×LLMのジャッジで検出率ほぼ100%にする方法

・C4モデル（C4ダイアグラム）とシーケンス図の整合性チェック

・lintツールとの違い：LLMが最終判断するから誤警告に寛容でいい

・LLMに良い設計をさせる鍵：未来の情報（ロードマップ）とテスト駆動開発（TDD）

・プライベート関数という抜け道をAST解析で塞ぐ、roles.tsvでモジュールの役割を先に定義する

・LLMが得意なプログラミング言語は？動的型付け言語の速さと型検査という「税金」

▼こんな人におすすめ

・Claude CodeなどのAIコーディングエージェントのレビュー精度・設計品質を上げたいエンジニア

・シーケンス図やC4モデルなど設計ドキュメントのチェックをAIに任せたい人

・TDDやlintとLLMをどう組み合わせるべきか、考え方の軸がほしい人

▼関連リンク

・PlantUML 公式サイト: https://plantuml.com/ja/

・C4 model 公式サイト: https://c4model.com/

・DeepWiki: https://deepwiki.com/

・Claude Code: https://www.anthropic.com/claude-code

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアのkuniwakに一般エンジニアのへんてこが「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。

─────────────

YouTube: https://youtu.be/qK9uNFp9RjY

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji

ソフトウェアの検証には「正当性検証（Verification）＝正しく作っているか」と「妥当性検証（Validation）＝正しいものを作っているか」の2種類があります。

単体テストやE2Eテスト、CIで確かめられるのはどっち？ユーザビリティや性能要件のような白黒つかない品質はどう検証する？今回はプロダクト検証の全体像を、スーパーエンジニアのkuniwakがへんてこの質問に答えながら解きほぐします。

仕様どおり完璧に実装しても「解きたい課題」とズレていたら意味がない——そのことを象徴する「ポテトチップスが出てくるSNS」のたとえ話から始まり、踏切を例にした安全性（safety）と活性（liveness）の分類、アジャイル・スクラムが妥当性検証を重視する流派である理由、プロダクトオーナーとスクラムマスターとエンジニアの役割分担まで、検証の考え方を体系的に整理。

終盤は、AIが正当性検証の担い手になりつつある今、人間に残る仕事は何かという話や、Figmaのモックアップとタップ数を使ってAIにUIデザインを探索・採点させるkuniwak流の最新アイデアも飛び出します。

▼この回で話していること

・正当性検証（Verification）とは？仕様と実装の間の検証

・妥当性検証（Validation）とは？要求・課題と仕様の間の検証

・単体テスト

・E2Eテスト・QAはどちらの検証にあたるのか

・性能要件やユーザビリティなど白黒つかない非機能要求の扱い

・正当性検証の細分化——安全性（safety）と活性（liveness）

・アジャイル・スクラムはなぜ妥当性検証を重視するのか（PO・スクラムマスターの役割）

・AI時代の検証——AIは正当性検証の担い手になり、妥当性検証はどこまでできるか

・Figmaモックアップとタップ数でAIにデザイン探索させるアイデア

▼こんな人におすすめ

・テストやQAをやっているが、VerificationとValidationの違いを説明できるようになりたいエンジニア

・スクラムのPOやスクラムマスターが何を担う役割なのか腹落ちさせたい人

・AIにコード生成やレビューを任せる時代に、人間がやるべき検証は何か気になる人

▼関連リンク

・アジャイルソフトウェア開発宣言: https://agilemanifesto.org/iso/ja/manifesto.html

・スクラムガイド: https://scrumguides.org/

くわラジ（もっと詳しく教えてくださいラジオ）は、スーパーエンジニアのkuniwakに一般エンジニアのへんてこが「もっと詳しく教えてください」と質問しながら技術を深掘りする、ゆるくてディープな技術雑談番組です。

─────────────

YouTube: https://youtu.be/Y6qt5YThwpE

Web: https://kuwa-raji.henteko07.com/

X: https://x.com/kuwa_raji