正気を疑う技術 - bugのないvibe codingを目指して
Helpfeel
何を作っている会社なのか
人を、信じたい
登場人物
shokai.icon PdM
開発メンバー.icon 開発者
claude code.iconCodex.icon AIコーディングエージェント
AIが信じられない
これはまあまあ信じれる
shokai.icon ↔ Claude Code.icon
別の人を挟むと、だんだん信じられなくなってくる
shokai.icon ↔ 開発メンバー.icon ↔ Claude Code.icon
AIでコード書かれて、AIでプルリクの説明も書かれると、レビューがつらい
人やAIを信じたい
開発メンバー.icon ↔ Claude Code.icon
ここで何をやりとりしているかshokai.iconは知りたい
shokai.icon ↔ Claude Code.icon
Claude Code.iconが出力するコードの品質を上げたい
最終的に作られたコードをshokai.iconが正しく理解したい
開発メンバー.iconが正しく要件を理解しているか、shokai.iconは知りたい
shokai.iconがどういう観点でコードレビューしているか、開発メンバー.iconは知りたい
1人が出すpull requestの数は増えてない
ような気がする。少なくともshokai.iconはそう
かわりに1つのpull requestのサイズが大きくなった
例：MongoDBをバックエンドとしたベクトル検索機能
これまで数年間Elasticsearchで培った運用ノウハウを、リリース初日から全て実装できた
https://scrapbox.io/files/6a2570d2601c8b4efdcf1617.png
最近作ったAgent Skill
「協力して」という軽いトリガーで、AI同士に激しい仮説・反論・再検証をやらせるスキル
経緯
2025年冬ごろ
Claude Code.iconで実装した後、Codex.iconに確認させるとbugが見つかるなあshokai.icon
そして板挟みへ
Claude Code.icon ↔ shokai.icon ↔ Codex.icon
コピペが大変
事情説明も大変
特に、Claude Code.iconと話し合ったやらない事とその理由がCodex.iconに伝わっていないのがつらい shokai.icon ↔ Claude Code.icon ↔ Codex.icon という構成で普通に呼び出させてみた
Claude Code.iconがただの連絡係になる
Codex.iconが◯◯と言ってました、主張が正しいかは知らんけどClaude Code.icon
結局shokai.iconは2人分の報告を受け取るだけ、大変すぎる
Claude Code.iconへ
自分の見解を開示しつつ、Codex.iconに指示を出せ
指示された事はちゃんとやれ
指示されてない事もやれ
指示や前提そのものを疑って検証しろ
レポートの内容も疑え
指示してない事まで書かれたレポートを受け止め、それを一つずつ吟味して報告書を書け
網羅的で正確なレポートが出てくる
15分ぐらいかかるけど
これで発動する
Codexと相談して
こんなカロリーの高いコミュニケーション私はやりたくないんですけど、AIならやれるのですごいですねshokai.icon
賢いAI同士でやってもらう
Claude Code.icon ↔ Codex.iconを必要に応じて2往復までやる
shokai.iconにレポートするまで30分ぐらいかかる
おまけ
コードに残らない意思決定の引き継ぎスキル
経緯
AIと色々相談しながら開発していると勉強になる
突然AIで作ったコードだけ渡されてもレビューできないのは、この部分が共有できてないからなのでは？
2025年冬ごろまで
長すぎて読めなかった
チャットログを整理しよう
やった事はコード読めばわかる。AIにも解説してもらえるし
コードになってない部分
色々検討した結果、こうなりました開発メンバー.icon
「色々検討した」の部分を詳しく教えてくれshokai.icon
章立て
ブランチ名、更新日時、commit hash
目的
設計方針
却下した代替案
意図的に対応しないこと
発見された制約
新たに確認できた事実
注意が必要な難所
残作業
https://scrapbox.io/files/6a25a4d5601c8b4efdcf552d.png
長いセッションでも記憶が飛ばない
例：今回はPNGだけやる、JPEGは対応しない、スクリーンショット用の機能だから
Claude Code.icon ↔ Codex.iconで話しあって、shokai.iconに報告せずに解決したbugがまとまる
これで解決したbugが、対話コンテキストに残る
複数回exportしても壊れない
特に前任者が発見した事実は、再検証して覆るまで勝手に書き換えないように指示してある
作業結果だけでなくプロセスも確認するAgent Skill
経緯
開発者として
最終的に作られたコード（の仕様）をshokai.iconが誤って理解している可能性がある
顧客や社内に説明する必要がある
もう一回やってみたらできるのではないか？
まだbugがありそうで心配
レビュアーとして
開発メンバー.iconが正しく要件を理解しているか、shokai.iconは知りたい
自分がどういう観点でコードレビューしているか明らかにしておきたい
3点で確認する
何をなぜやってどうなったのか、を実装者は説明できているか
説明と実装が一致しているか
実装者はAIが作ったコードを読み解けているのか
bugや脆弱性が含まれていないか
実装者の考慮に漏れ・抜けはないか
調べた事、試した事、やらないと決めた事の記述に十分な厚みがあるか
章立て
AIとの対話コンテキスト
pull request概要欄
サマリー
品質評価
説明と実装の整合性
命名・設計パターンの一貫性
長期視点で命名・設計を考察する
バグ・脆弱性の調査
考慮漏れの確認
レビュー作業において発生した問題
結論
いくつかの章は、対話コンテキスト無しで使われたり、不十分なAI modelで実行されて発行されたレビュー報告書という名の免罪符になっていないかチェックするために必要shokai.icon
これらのツールを組み合わせるとこういう流れになります
最近社内で推奨している、AIを使った開発の流れ
書き出してみると、意外とややこしい事やってるなと思ったshokai.icon
環境
Claude Code (Opus)とCodex CLI (GPT5.5-high)を使っています
IMEの辞書によく使うプロンプトを入れておく
https://scrapbox.io/files/6a25b26b601c8b4efdcf609f.png
実装して
1. 説明して、AIに質問させる
2. planから実装したらすぐbug修正
3. 良い感じになるまで1と2を繰り返して実装していく
コードレビューに向けて準備
4. pull requestを作る
pull requestを作ってください。概要欄は箇条書きで簡単書けばいいです
pull requestの概要欄は、人間が自分なりに書き直す
5. AIレビュー (1)
開発sessionのCladue Codeを使う
6. 対話コンテキストをexportする
/conversation-context-export
新規sessionのClaude Codeを使う
(プルリクURL) を /sanity-review してください
レビュー報告書ができる
ここでもbugが見つかる事が多いので、修正する
レビューしてリリース
8 . 人間のレビュアーがpull requestの概要欄と、レビュー報告を読む
まだ不安がある時は
bugが無いかCodexと共に全力で確認してください
意外とまだ見つかるshokai.icon
9. リリースする
2, 5, 7でほぼ確実に毎回bugが見つかる
なんだかんだでAIが出すコードにはbugがある
疑問点・懸念事項が無くなったOpusがplan modeを経て出力したコードであっても
人間にもbugがある
AIが出したコードを人間が理解できていない事がわりとある
特に仕様
会場で写して大丈夫そうなpull requestを見繕う