必ず事実から確認する — ルールを作って、随時直す

シリーズ4本目。ここまでの話を一言でまとめると、「AIは推測で動く。だから私が事実を要求する」です。この記事では、実際に運用しているルールと、それぞれが生まれた経緯を書きます。

ルールは事故から生まれた

最初からきれいなルールがあったわけではありません。全部、何かが壊れた後に足したものです。だから一つひとつに理由があります。

経緯: AIが「〜のはず」で作業を進め、実際のコードと食い違って手戻りが発生することが続いた。

ルール: 仕様・実装状況・PRの状態について何か言う前に、必ず実際のコードかGitHubのAPIで確認する。確認していないことは「未確認」と明記する。

経緯: 「調べて直して」と一度に頼んで1つのIssueにまとめさせると、AIが調査の途中で実装に走り、方針が固まる前にコードが変わってしまった。

ルール: 調査は調査で完結させ、結果を私が確認してから、別Issueで実装を指示する。

経緯: 表示がおかしい→表示を上書きして隠す、という修正が入り、後で別の場所で同じ原因が再発した。

ルール: バグを別のバグで隠さない。原因を特定してから直す。「とりあえず動く」修正は却下。

経緯: 直すたびに「あ、もう1つありました」が出てきて、何往復もした。

ルール: 最初のレビューで見つけた問題は全部一度に出す。小出しにしない。

経緯: ふわっとした相談のつもりが、AIが実装を始めていた。

ルール: 問題の共有 → 課題化 → 解決策の提案 → 実施指示（GO）。この順を飛ばさない。

経緯: 上と同じ。本番反映の判断は自分に残す。

ルール: AIはプレビューURLを提示して止まる。私が確認して「マージGO」と言ったら、AIがマージと本番デプロイを実行する。判断は私、操作はAI。

これらはリポジトリ直下の文書にまとめてあり、AIは作業開始時に必ず読みます。内容は「タスクの種類ごとに誰がやるか」「Issueのテンプレート」「トラブルシューティング」など。

大事なのは、この文書を「完成品」にしないことです。事故が起きたら、その場で一行足す。ルールが増えすぎたら統合する。文書が現実とズレた瞬間に、AIはズレたほうを信じます。

正直に言うと、ルールの半分は「自分が楽をしないため」のものです。AIに丸投げしたくなる気持ちは常にあります。でも、確認をサボった回はだいたい事故っている。AIとの開発で一番の変数は、AIではなく私の確認精度でした。