くわラジ - Details, episodes & analysis

Podcast details

Technical and general information from the podcast's RSS feed.

くわラジ

ミソラボ

Technology

Frequency: 1 episode/8d. Total Eps: 26

スーパーエンジニアであるkuniwakに一般エンジニアであるへんてこが技術的な質問をしながら深掘り噛み砕いていく、ゆるくてディープな技術雑談番組です。 https://kuwa-raji.henteko07.com/

Site

RSS

Apple

Data updated on 05/11/2026

Recent rankings

Latest chart positions across Apple Podcasts and Spotify rankings.

Apple Podcasts

🇫🇷 France - Technology
05/11/2026
#97

Spotify

No recent rankings available

Shared links between episodes and podcasts

Links found in episode descriptions and other podcasts that share them.

See all

https://kuwa-raji.henteko07.com/
20 shares
https://c4model.com/
2 shares
https://plantuml.com/ja/
2 shares

https://open.spotify.com/show/6uUjalUT94ugSgtLI5WF6a
6 shares

RSS feed quality and score

Technical evaluation of the podcast's RSS feed quality and structure.

See all

RSS feed quality

To improve

Score global : 48%

Publication history

Monthly episode publishing history over the past years.

Year

Latest published episodes

Recent episodes with titles, durations, and descriptions.

See all

#26 E2Eテストに全振りするな——AI時代こそ"テスト戦略"は人間の仕事

Season 1 · Episode 26

Friday, October 30, 2026 • Duration 39:14

「AIがコードを書くなら、テストはE2Eテストに全部寄せればいいのでは？」──Xで話題になったE2Eテスト全振り論に、kuniwak が真っ向から反論します。E2Eテストは単体テストの"上位互換"なのに、なぜ全部をE2Eにしてはいけないのか。テスト戦略とは何かを、AI時代の視点から掘り下げる回です。

E2Eテスト（エンドツーエンドテスト）が見つけられるバグ・見つけられないバグ、保守コストと実行コストが「100倍〜1000倍」になる理由、単体テストと組み合わせると同じコストでより多くのバグが見つかる仕組みを、FizzBuzzの例で噛み砕きます。へんてこが個人開発で書かせたE2Eテストが25分かかっている実体験も交えつつ、AIにテストを後から書かせると何が起きるのか、テストオラクルを誰が握るべきかまで話が広がります。

▼チャプター

00:00 オープニング

01:32 E2Eテストのコストと課題

15:26 E2Eテストシナリオの選定基準

19:13 AI時代におけるE2Eテスト

34:13 セキュリティ観点から考えるテスト戦略

37:27 エンディング

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

・E2Eテストとは？単体テスト・結合テストとの違いと「結合バグ」

・E2Eテストの保守コストと実行コストが高すぎる理由

・テストケースは結合するほど組み合わせ爆発する

・E2Eテストのシナリオはどう選ぶ？ユーザー価値と収益導線のハッピーパス

・AIにE2Eテストを書かせると「実装の追認」になる問題

・テストファーストでE2Eテストを先に書くのはアリか

・テストオラクルを実装にしてはいけない理由

・形式手法・オブザーバビリティも含めたテスト戦略は人間の仕事

▼こんな人におすすめ

・AIコーディングでE2Eテストに頼りきりになっている人

・テストピラミッドやテスト戦略の考え方を整理したいエンジニア

・CIのテストが遅くて開発が止まりがちなチーム

▼関連リンク

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

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

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

・Playwright: https://playwright.dev/

・Selenium WebDriver: https://www.selenium.dev/documentation/webdriver/

・Test oracle（Wikipedia）: https://en.wikipedia.org/wiki/Test_oracle

・djbdns: https://cr.yp.to/djbdns.html

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

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

YouTube: https://youtu.be/sn1MDn-TuLI

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

X: https://x.com/kuwa_raji

Read moreCollapse

#25 "わからないまま保留する"力——「わかってる」より「できる」で判断しよう

Season 1 · Episode 25

Friday, October 23, 2026 • Duration 27:09

「わかっている」とはどういう状態なのか？自分の理解度はどう測ればいいのか？今回は「わからない」という感覚をテーマに、理解の基準、わからないと認められない心理、そして答えを急がず"わからないまま保留する"力について、へんてこが kuniwak に聞いてみました。

kuniwak が理解度の物差しとして使っているのは「構成要素に分解できるか」。形式手法やECサイトの在庫・配送を例に、わかったつもりの知識を分解すると「わからない部分」が見えてくる話から、知識の裾野の広さ、AI が"どの分野も平均点以上"の専門家として隣の領域を補ってくれる話、ポアンカレ予想のように別分野の視点が突破口になる話へ。後半は、見栄や白黒つけたい心理が「わからない」を認めにくくしていること、コードレビューで「わかってました」と言われたときの向き合い方、ジュニアエンジニアの学習計画や採用面接で「わかっているか」ではなく「できるか」で判断する理由、そして AI 時代に人間が"理解を手放す"ことと意思決定の関係まで掘り下げます。

▼チャプター

00:00 オープニング

00:48 「わかっている」基準としての構成要素への分解

06:21 知識の広がりとAIによる専門性の補完

09:33 「わからない」を認められない心理と保留する力

16:10 「わかっているか」ではなく「できるか」で判断する

19:55 理解を手放すことと意思決定

25:24 エンディング

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

・「わかっている」の基準とは？構成要素に分解できるかで理解度を測る

・わかったつもりを防ぐ：分解・例示で「わからない部分」を自覚する

・AI は"全分野で平均点以上の専門家"：隣の分野の知識がブレイクスルーを生む

・「わからない」を認められない心理：見栄と、白黒つけたくなる二分法

・わからないまま保留する力（ネガティブ・ケイパビリティ）と知的誠実さ

・コードレビューで「わかってました」と言われたら：ADR のように不採用案と理由を書く

・学習計画・採用面接は「わかるか」ではなく「できるか」で判断する

・AI 時代に人は理解を手放すのか？わからなくても失敗しない意思決定のしかた

▼こんな人におすすめ

・自分が本当に理解できているのか不安になるエンジニア

・メンバーの理解度の見極めや育成・採用に悩むテックリード・マネージャー

・AI に頼るほど「自分はわかっていないのでは」とモヤモヤしている人

#24 "AIに書けない"コーン茶レビュー——vim-jp Slackで届いたリクエストに答えてみた

Season 1 · Episode 24

Thursday, October 8, 2026 • Duration 36:01

コーン茶（とうもろこし茶）って、なぜコーヒーの代わりになるの？ vim-jp の Slack で「AI に書けないようなことをぜひ語ってほしい」とリクエストをもらった kuniwak のコーン茶レビューを入り口に、エンジニアの「プログラミングのお供」をへんてこが根掘り葉掘り聞いてみました。

コーヒー好きの kuniwak がカフェインを減らすためにたどり着いたのが、ノンカフェインのコーン茶。無印良品とルピシアの飲み比べ、焼肉チェーンのドリンクバーのコーン茶との違いを「コーンらしさ」と「香ばしさ」の軸で語ります。話はそのままコーヒーへ。産地と焙煎度（ロースト）での豆の選び方、自家焙煎が難しい理由、コーヒーミルの大敵「微粉」、ハンドドリップをやめてマキネッタ（直火式エスプレッソメーカー）に落ち着いた理由まで。後半は仕事中の集中力を支えるサプリ「クレアチン」の個人的な体験談から、薬の説明書（添付文書）を"取説"として読み込む習慣、半減期の考え方、そして自分で併用禁忌に気づいた話へ。「飲み合わせのチェックこそ AI でやってほしい」という薬局 DX の話題まで、技術の話をしていないのに性格と仕事の流儀がにじみ出る回です。

※ サプリメントや薬に関する話は、あくまで一個人の体験談です。体質や持病、服用中の薬によって合う・合わないがあるので、試す前に医師・薬剤師に相談してください。

▼チャプター

00:00 オープニング：vim-jp の Slack で届いたリクエスト「コーン茶について語ってほしい」

01:20 コーン茶を飲み始めた理由：コーヒーのカフェインを減らしたい

03:15 コーン茶レビュー：無印良品とルピシア、「コーンらしさ」と「香ばしさ」

08:48 コーヒー豆の選び方：産地と焙煎度

12:17 自家焙煎はなぜ難しいのか

14:36 好きな豆とコーヒーミル：大敵は「微粉」

17:43 ハンドドリップよりマキネッタを選んだ理由

20:22 仕事中のサプリ：クレアチンを飲み始めたきっかけ

26:18 薬の説明書を読む：半減期と併用禁忌

31:08 飲み合わせチェックは AI に任せたい：薬局 DX とデータ化

34:11 エンディング

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

・コーン茶（とうもろこし茶）はノンカフェイン：コーヒーの飲みすぎを減らす代わりの飲み物として

・コーン茶の選び方とおすすめ：無印良品とルピシアの違い、ティーバッグとペットボトルの風味の差

・コーヒー豆の選び方：産地（エチオピアなど）と焙煎度、どちらから好みを探すか

・自家焙煎が難しい理由と、コーヒーミルで味を左右する「微粉」とは

・ハンドドリップとマキネッタの違い：味を安定させたい人の淹れ方

#23 発表は"3割"しか伝わらない——コードレビュー廃止ネタを一般化してみた

Season 1 · Episode 23

Thursday, October 1, 2026 • Duration 33:22

登壇ネタの「一般化」って、具体的にどうやるの？前回「発表ネタで一番大事なのは一般化」と語った 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 時代のコードレビューのあり方や、レビュー待ちの解消に悩んでいる開発チーム

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

#22 一番大事なのは"一般化"——登壇50回で分かった発表ネタの作り方

Season 1 · Episode 22

Thursday, September 17, 2026 • Duration 40:27

勉強会やカンファレンスで登壇し続けるには、発表ネタをどう作ればいいのか？登壇回数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・登壇イベントの探し方と、勉強会がなければ自分で作るという選択肢

#21 気負わない・準備しすぎない——21回続いたポッドキャストの裏側

Season 1 · Episode 21

Thursday, September 10, 2026 • Duration 28:17

ポッドキャストを続けるコツとは何か？「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「正論は、出禁になる。」

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

▼こんな人におすすめ

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

#20 大きく勝つより"負けない"——リスク嫌いエンジニアのライフプラン自作

Season 1 · Episode 20

Thursday, September 3, 2026 • Duration 45:50

ライフプランシミュレーターを自作すると何がわかるのか？スーパーエンジニア 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 パイプラインでの再現可能な計算に興味がある人

▼関連リンク

#19 printfデバッグしたら"負け"——デバッグは設計で決まる

Season 1 · Episode 19

Thursday, August 27, 2026 • Duration 41:18

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

#18 「仕事しない同僚」にイライラしたら——他人はコントロールできない

Season 1 · Episode 18

Thursday, August 20, 2026 • Duration 36:08

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

「他人の仕事は他人の仕事と割り切る」という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

#17 AI時代にまさかのVim回帰—-CLI/TUIの時代へ

Season 1 · Episode 17

Thursday, August 13, 2026 • Duration 48:15

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

くわラジ - Details, episodes & analysis

Podcast details

Recent rankings

Apple Podcasts

Spotify

Shared links between episodes and podcasts

RSS feed quality and score

Publication history

Latest published episodes

Related Shows Based on Content Similarities

Apple Podcasts

Spotify

Related Shows Based on Content Similarities

くわラジ - Details, episodes & analysis

Podcast details

Recent rankings

Apple Podcasts

Spotify

Shared links between episodes and podcasts

Other40

YouTube13

Spotify1

RSS feed quality and score

Publication history

Latest published episodes

Similar podcasts and content

Related Shows Based on Content Similarities

Apple Podcasts

Spotify

Related Shows Based on Content Similarities

Other40

YouTube13

Spotify1