私は開発をAIと組んでやっています。外注ゼロ、社員ゼロで、クライアントの本番環境を触る仕事をしています。
この体制で一番難しいのは、コードを書かせることではありません。AIが「分かったつもり」で断定するのを止めることです。
止められなかったとき、間違った修正が本番に入ります。止められれば、人間ひとりより速い。その分岐点がどこにあるかを書きます。
何が起きるか
AIは、調べていないことを調べたように書きます。悪意ではなく、文章として自然に埋めてしまう。
実際に起きた例を挙げます。
例1: 「該当のカラムは全件空です」
ある集計で「このデータは全件が空だ」と報告されました。実際は半数以上に値が入っていました。
原因は、SQLのSELECT句にそのカラムを入れていなかったことです。取得していないので、参照すると undefined になる。それを「空」と数えていました。
JavaScriptは存在しないプロパティを参照しても落ちません。だから「取得していない」と「値が空」が区別できない。
例2: 「実測で誤検出ゼロです」
ある検査ロジックについて「1,368件で誤検出ゼロ」と報告されました。数字は正しい。しかし検査が成立する対象が2件しかありませんでした。
「1,368件中0件」は「2件中0件」と同じ意味だったのに、前者として報告されていました。分母を確かめていなかった。
例3: 「審査に落ちました」
案件の記録に「異議申し立て提出済み → 回答待ち」とだけ書いてありました。それを読んで「審査に落ちた」と書きました。記録にない結論を補完していた。
実際は、クライアントが事業自体を取りやめたという別の顛末でした。
共通しているもの
3つとも、推測を事実として書いています。 そして3つとも、指摘されるまで気づいていません。
パターンは決まっています。
- 一部を見て全体を語る（SELECTした範囲＝全体だと思う）
- 分母を確かめない（率だけ見て母数を見ない）
- 記録の空白を埋める（「回答待ち」→「落ちた」）
人間もやります。違うのは、AIはそれを流暢な断定文で出すことです。自信のなさが文面に出ないので、読む側が疑いにくい。
止め方
1. 「確認済み」と「推測」を分けさせる
出力の中で、実際にツールで確認したことと、そう思うことを分けて書かせます。
確認済み（コマンドと結果を示せるもの）:
- wp_ptogo_multi_products に14行、うち9行が active
→ wp db query の結果
推測（未確認）:
- product_status を inactive にすれば一覧から消えるはず
→ コードを読んでいない
こう書かせると、推測の量が可視化されます。 推測ばかりなら、まだ実装に入る段階ではありません。
2. 「見つからない」を「存在しない」と言わせない
grep して出てこなかったから存在しない、は成立しません。検索語が違う、対象ディレクトリが違う、除外設定に引っかかっている、いずれもあります。
「ローカルには見つからなかった」と「存在しない」は別のことです。後者を言うなら、GitHub、サーバー、アーカイブまで当たってからにする。
3. 数字には必ず分母を付けさせる
「誤検出ゼロ」ではなく「評価できた2件のうち0件」。
「98%が未消化」ではなく「1,417件中1,400件が未消化」。
分母を書かせるだけで、無意味な数字が自分で消えます。 分母がゼロなら、その指標は成立していません。
4. 完了報告の前に、確認の経路を全部挙げさせる
「直りました」の前に、「症状が起きうる経路」を列挙させます。画面、API、非同期ジョブ、cron、データ投入。1経路の成功を全体の成功にしない。
実例として、ある修正を「本番反映を確認しました」と報告した直後に、キャッシュ層を見ていなかったことが分かったことがあります。
5. 別のAIにレビューさせる
これが最も効きます。同じモデルに聞き直しても、同じ思考なので同じ見落としをします。別系統のモデルに、こちらの結論を見せずに独立して判断させる。
実際、ある検証ロジックについて、私が「完成した」と判断したものを別モデルにレビューさせたところ、5ラウンドにわたって欠陥が出続けました。 うち2件は、私が「誤検出を減らそう」として自分で作り込んだ退行でした。
- 1回目: 正しい文を誤検出する
- 2回目: それを直そうとして、検査そのものを無効化していた
- 3回目: 直したつもりが、別の入力形式で破綻していた
誤りを消そうとして、検出能力を壊す。 これは一人では気づけませんでした。
止められなかった場合のコスト
止め損ねると、誤った前提の上に作業が積み上がります。
先の「全件空です」の例では、その誤ったデータを使ってA/B比較まで実施していました。数字1つの誤りが、それを使った検証結果を全部無効にしました。
やり直しのコストより、誤った結論を信じたまま次の判断をするリスクのほうが大きい。
それでもAIと組む理由
ここまで書くと使わないほうがいいように見えますが、逆です。
止め方さえ決まっていれば、圧倒的に速い。 1日で、3つのサイトの表記誤りを実測で見つけて直し、リポジトリに混入していた秘密鍵を全履歴から除去し、本番DBの状態を数え、放置されていたサイトを作り直す——これを一人でやるのは無理です。
重要なのは、AIに判断させないことではなく、判断の根拠を必ず示させることです。根拠が示せないなら、それは判断ではなく推測です。
そして人間の側は、「速く出てきた答え」を、速いという理由で信じないこと。
チェックリスト
実務で使っているものを置いておきます。
AIの出力を受け取ったとき
- 断定している箇所に、確認の根拠（コマンド・出力）があるか
- 数字に分母があるか
- 「見つからない」を「存在しない」と書いていないか
- 記録にないことを補完していないか
修正を本番に入れる前
- 症状が起きうる経路を全部挙げたか
- 全経路で確認したか、していない経路を明示したか
- 元に戻す手順があるか
- 別系統のレビューを通したか
完了報告の前
- 「たぶん」「はず」で書いている箇所がないか
- 未確認の項目を未確認と書いたか
まとめ
AIと組んだ開発で守るべきは、速度ではなく根拠の追跡可能性です。
出てきた答えが正しいかは、答えを見ても分かりません。どうやってその答えに至ったかを見れば分かります。
「速いから」「自信があるから」は、確認を省略する理由になりません。
AIを使った開発体制に関心のある方へ
Web戦略30年、現在は1人+AIで自社プロダクトとクライアントワークを回しています。実装のご相談、体制についてのご相談どちらも承っています。
販売実績58件・評価5.0・出品者ランク プラチナ（2026-09時点）