hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

トップ > バイブス静的解析というお題でYAPC::Fukuoka 2025で発表した

バイブス静的解析というお題でYAPC::Fukuoka 2025で発表した

8月くらいに、コードベースから、使ってないコードを探すツールをAIに作ってもらっていたら、突然「バイブス静的解析」という言葉が降ってきて、これだ！とプロポーザルを出したら採択してもらえたので、喋ってきた。
スライド3枚くらいでダイジェストするとこんなかんじ。

資料はこちら

speakerdeck.com

感想はこちら

いろいろつぶやいてもらえた。
「これくらいみんな今どきはやってて、常識でしょ、わざわざ発表するほどのことはない、内容が薄すぎ」という反応が想定する反応だったので、おもしろがってもらえてよかった。


これはたしかに。最初の実装ではプロンプトにスクリプトを入れてなかったのですが、汎用化するときに無理してmarkdown内に入れた。セットアップとその後で別のコマンドにするといいのかも。
Claude Codeのスキルなら.plと.mdを両方梱包できるはずだけど、明示的に呼び出すというのがうまく行かなくて、サブコマンドなら間違いなく呼べるので、サブコマンドにした、という経緯もある。

Q&Aコーナー

きのう夜に練習してた、なぜか持ち時間を20分じゃなくて発表15分質疑5分だと勘違いして、圧縮して喋る練習をしており、当日の午後に、あれっやっぱり20分でいいのか？と調整していたものの、喋ってみたら早く終わってしまった。
想定質問スライドをたくさん用意していたので、そのあたりを喋ったり、みなさんからいただいた質問を読んだりしていて、インタラクティブな時間になってよかったと思う。

本コーナー

当日紹介した本。バイブコーディングの立ち位置や、良い使い方などが載っている。
この本の用語にのっとると、バイブス静的解析じゃなくて、「AI・アシスト・静的解析」と呼んだほうがよさそう。
www.oreilly.com

バイブコーディングを超えて ―AI時代を生き抜く開発者の未来

バイブコーディングを超えて ―AI時代を生き抜く開発者の未来

Amazon

AIを活用したプレゼンづくり

プレゼンづくりにあたっては、いろんなAIを活用した。

  1. こんな感じの話、というのを紙に書いて、キーワードとか話の順番とかを組み立てる
  2. 紙のメモを見ながら、Google Docsの音声入力モードで、ひたすらしゃべっていき、文字起こしする
  3. 喋ったテキストをAIに渡して、アジェンダとして組み立ててもらう
  4. 「序盤にこういう話を追加」とか依頼しながらアジェンダを調整していく
  5. 過去のプレゼン資料も渡して、「普段こんなトーンで喋ってるので踏襲して」とかお願いする
    • いろんなツールに渡すといろんなアドバイスをもらえておもしろい
    • ChatGPTはTeD的なものをよしとしているのか、話が大げさになっていく

ChatGPTによるアドバイス

★★★★★ タイトル再構成：「バイブス静的解析 〜AIと勢いで暗黙の依存を暴く〜」 技術的正当性＋インパクトの両立
★★★★★ 問題設定の再定義：「静的解析がカバーできない“プロジェクト固有の闇”」を1枚のスライドに 聴衆の共感を初手でつかむ
★★★★☆ AIとの協働パートを独立セクション化（「AIに正規表現を書かせて勝った日」） 会場ウケ・SNS拡散を狙える
★★★★☆ 3幕構成に再編：「過去（汎用）→現在（AI混乱）→未来（バイブス解析）」 ストーリーの明快化
★★★☆☆ デモ＋スニペット追加：4秒→120秒の比較＋正規表現例 記憶に残る瞬間を作る
★★★☆☆ 表とグラフで対比：汎用ツール vs バイブス解析 論理の説得力強化
★★☆☆☆ 行動提案で締める：「#vibes解析チャレンジ」呼びかけ 聴衆の行動喚起・余韻
★★☆☆☆ ネスト構造の失敗事例を「切り捨てる勇気」として昇華 バイブス哲学の一貫性

Geminiによるアドバイス

高 プレゼンタイトルに技術的な正当性を示すサブタイトル（例：「勢いとAIで暗黙の依存を暴く」）を追加する。
高 Abstractの課題設定を「実行時間」から**「プロジェクト固有の暗黙的依存（JobQueue, DSLなど）の可視化の難しさ」**に修正し、本質的なニーズを強調する。
高 「デッドコードを消す理由」の最重要項目を「CI短縮」ではなく**「開発者の認知負荷（Cognitive Load）の軽減」**に置換する。
高 汎用AIが依存関係を正確に判断できない理由として、**「暗黙的依存（文字列リテラルやDSL）をAIが知らない」**ことを技術的に説明する。
高 正規表現版（バイブスツール）のデッドコード検出スクリプトの核となるスニペット（数行）を準備し、スライドに組み込む（デモ/具体例）。
高 PPI版と正規表現版の実行速度比較ベンチマーク結果（4秒 vs 120秒など）をグラフ で作成し、視覚的に訴える。
中 「さまざまな依存」セクションに、**汎用ツールが対応できない依存形式（JobQueue, DSLなど）**と、**バイブスツールの検出手法（正規表現）**を対比させた表を作成する。
中 「プロジェクト専用ツール」のセクションに、バイブス解析は**「正規表現で90%をカバー、残りは人間」**と、割り切りの正当性を数値で明記する。
中 失敗事例の分析を深掘りし、「ネストした構造は切り捨てる」という教訓から、バイブス解析は「プロジェクトのコーディングイディオム（慣用句）」に特化するという設計思想を導く。
低 「デッドコードの探し方」プロセス（人間が介入する部分）をフローチャート で示し、フィードバックループの重要性を明確にする。
低 まとめ・展望のメッセージを強化し、**「バイブス解析レシピの共有」**という新たな行動を聴衆に促す提案で締めくくる。


Claude Codeによる、hitode909スタイルの分析

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【まとめ：hitode909プレゼンスタイルの本質】
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. シンプル・フラット
深い論理構造より、流れで見せる

2. 短文・箇条書き
1項目1-2行程度

3. 具体例重視
コード、スクリーンショット、数字

4. 親しみやすさ
語りかけ調、会話調を適度に混ぜる

5. 行動喚起
締めで次のアクションを示す

→ 「バイブス」という言葉とも相性が良い
→ 完璧を目指さず、勢い重視の姿勢と一貫

ここまでガチャガチャやって話の流れを決めてから、Keynoteで作る、ということをやってみたのだけど、喋ってみたら変だな、と思ってKeynote上でもスライドを入れ替えたりした。
同僚のレビューも「こんなフィードバックが来たから、ここにこういう変更を入れようと思う」とかAIに渡してみて、反応を見てから組み替えていった。とにかく壁打ちとして活用してもらっている。
こういう壁打ちのときは会話を消さずに、1セッションで延々とやりとりしている。

謝辞コーナー

今日、子が体調悪くて保育園お休みになっていて、家から中継を見てくれていたようだった。
妻が家で面倒を見てくれていてありがたい。