AIコーディングの現実｜6日で内製したツールを公開前に疑ったら、重大バグが8件出た

この記事は、AIコーディングの話です。ただし「こんなに速く作れました」という話ではありません。速く作れたことの代償を、自分たちの記録で書きます。

題材は、社内で使うために内製したメールマガジン管理ツールです。実質6日で作りました。かつてなら専任チームで数ヶ月かかった規模です。そして開発5日目の夜、公開前に自分たちのコードをレビューしたところ、重大なバグが8件出ました。

先に断っておきます。事故は起きていません。8件はすべて、本番の一斉配信を1通も行う前に見つかったものです。被害報告ではなく、「もう少しで踏み抜くところだった床板」の記録です。

そして、その最たるものがこれでした。

「リハーサル配信」のつもりでボタンを押すと、購読者リスト全員に本配信が始まる。

ただし、この話をいきなり始めても意味がありません。このツールが何のために生まれたのかを説明しないと、なぜそのバグが致命的なのかも、なぜ8件を出せたのかも伝わらないからです。だから、発端から書きます。

発端は「コストが高い、使い勝手が悪い、件数制限がある」

GrowGroupは以前から、既存のメール配信サービスでメールマガジンを運用していました。動いてはいました。ただ、不満が3つありました。

• コストが高い。機能のわりに月額が重い
• 使い勝手が悪い。自分たちの運用と画面が噛み合わない
• 登録件数に制限がある。上限に当たるたびに、プランを上げるか運用を歪めるかの二択になる

この3つが、このツールの存在理由のすべてです。以降に出てくる設計判断は、全部ここから逆算されています。もう1つ、条件がありました。顧客管理システムに取引先と連絡先の情報が揃っているので、そこから購読者リストを吸い上げたい。既製サービスに合わせている限り、この接続はいつまでも半端なままでした。

読者の会社にも、たぶん同じ構図のものがあると思います。「そこそこ困っているが、乗り換えるほどでもない」ツールです。厄介なのは、不満が3つ揃っているのに、どれも単独では乗り換えの決め手にならないことです。1つひとつは我慢できる。比較検討に何日もかける理由にはならない。だから何年も使い続ける——そして毎月、少しずつ払い続ける。

AIコーディングが変えたのは、まさにこの膠着です。「自作する」が現実的な第三の選択肢になった。実際、不満を洗い出してから作るものの輪郭が決まるまでに、検討会議は要りませんでした。同じ日の午前のうちに、欲しいものは並び終えています。毎月1万件規模の配信、ステップメール、そして送った後に届いたか・開封されたか・リンクが押されたかを取れること。

ただし、その整理と同時に、もう1つ決めたことがあります。「明示的に指示するまで、実装を始めるな」。輪郭が見えた時点でAIは書き始められる状態にありましたが、そこで手綱を引いた。AIコーディングの話は、実はもうこの時点から始まっています。放っておくとAIは書き始めるので、明示的に止める——この判断は、記事の最後まで響き合います。

目的は「作る・送る・測る・止める」── とくに「止める」

このツールの核は、4語で決まっていました。「作る・送る・測る・止める」。実装が1行も存在しない段階から、この4つだけを軸に据えています。

前の3つは、メール配信ツールなら当たり前です。特徴的なのは4つ目の「止める」が、機能一覧の端ではなく核の位置に置かれていることです。

理由は、メール配信という業務の性質にあります。取り返しがつかないのです。画面の表示がおかしいなら直せばいい。データが壊れたら復元すればいい。しかし送ってしまったメールは、二度と戻せません。しかも相手は、自分たちを信頼して登録してくださった数千人規模の方々です。

だから設計の出発点が「たくさん送れること」ではなく、「間違えたときに止まること」になっている。ここを押さえないと、このあとの話が「ただのバグ自慢」に見えてしまいます。8件のうち5件は、この『止める』が効かない穴でした。核に据えたものが、最初の実装では効いていなかったわけです。

意図的にやらなかったこと

設計の輪郭は、やったことよりやらなかったことのほうに出ます。記録に残っているものを挙げます。

• AI自身に実送信をさせない。下書きも校正もAIにやらせますが、「送る」だけは人間のボタンからしか起動しません
• チャットツールへの連携コネクタを、作った後に削除した。通知先を増やすほど、どこかで誰かが「見たつもり」になるためです
• ファイル共有サービスとの個別連携を撤去した。配信ツールが抱えるべき責務ではないと判断しました

逆に、いったん決めた設計を自分で覆したものもあります。当初は「メール本文をこちら側に保存しない」方針でしたが、途中で保存する設計に変えました。保存しないほうが情報管理としては安全に見えますが、それでは「何を送ったか」を後から検証できない。「止める」を核に据えた以上、検証できないほうが危ないという判断です。

やらなかったことは、機能だけではありません。「まだ決めない」と決めたことも含まれます。

開発の初日、要件をひととおり並べた段階で、AIはもう動かす場所まで先に確定させようとしていました。どのサービスに載せるか、どこにデータを置くか。合意した覚えのない構成が、すでに前提として組み上がりかけていた。そこで手を止めています。インフラを確定した覚えはない。もっと煮詰めてからだ——判断としては、それだけです。

AIコーディングで最も頻繁に起きるのは、実はバグではありません。合意していないことが、勝手に確定していくことです。AIは聞かれていないことまで決めて、決めたことを前提に次を書きます。しかも書かれたコードは動くので、「決めた覚えのないもの」が既成事実として積み上がっていく。土台の選択は、後から覆すほど高くつきます。

だから、議論して、合意して、それから反映する。この順序を守るために手綱を引く場面が、6日のあいだに何度もありました。そして後述しますが、この「止める側の仕事」こそが、AIが速くしてくれない領域そのものでした。

6日で141コミット ── 速さは本物です

ここからが、AIコーディングの話です。まず、速さが誇張でないことを実データで示します。

7日間で141コミット。1日休んでいるので、実稼働は6日です。しかも初回コミットの1発で、基盤が丸ごと成立しています。この6日で出来上がったのは、こういうものでした。

• メールの作成・配信・予約と、確認用のプレビュー画面
• 購読者の管理、セグメント、テンプレート、ステップメール
• 開封・クリック・エラーの計測（＝発端の不満のうち「使い勝手」の中身）
• 登録・配信停止・配信設定の変更（公開ページ）
• 顧客管理システムとの日次同期、購読者リストの品質改善（＝発端の「API連携したい」）
• 記事ネタの収集、AIによる下書き生成と校正

3つの不満から6日でここまで来る。これがAIコーディングの現実で、この部分に誇張はありません。「既製品に業務を合わせる」から「業務に合わせて作る」へ、選択肢が実際に変わりました。

問題は、ここからです。

開発5日目の夜、自分たちのコードを疑った

5日目の夜、本番の配信基盤に切り替える手前で、送信の経路だけを狙って診断しました。核が「止める」である以上、そこが効いていない状態で本番に触るわけにいかないからです。

結果、3件出ました。そして「3件も出るということは、まだあるはずだ」と考え、今度は範囲を広げて自分たちの書いたコードをレビューし直したところ、さらに5件。合計8件です。

ここで、この記事でいちばん重要な事実を書きます。

この8件は、実装フェーズでは1件も出ていません。レビューフェーズで、全件出ました。使ったAIは同じです。読ませたコードも同じです。違ったのは、「作れ」と言ったか「疑え」と言ったか、それだけでした。

これは後で結論として戻ってきます。先に、何が出たかを見てください。

バグ①：リハーサルのつもりが、本配信になる

いちばん危なかったものから書きます。

このツールには「テストモード」と「本番モード」があります。テストモード中は、決められた宛先（自分たち）にしか送りません。安全です。そして「リハーサル配信」という機能があります。本番の文面を、まず自分たちだけに送って確認するためのものです。

問題は、宛先を制限する条件の書き方でした。「テストモードのとき、かつリハーサルなら、宛先を制限する」と書いてあったのです。

お気づきでしょうか。本番モードに切り替えた瞬間、「リハーサル」という指定が無視されます。テストモードでないので、条件が成立しない。宛先の制限が、外れる。つまり——本番切替後に「リハーサル配信」を押すと、購読者全員に本配信が始まる。

そして、ここが本当に怖いところです。

テストモードで何度試しても、この不具合は絶対に再現しません。テスト中は宛先が制限されるので、完璧に正常に見える。本番に切り替えた、まさにその瞬間に初めて牙を剥く——そういう構造でした。

修正はこうしました。モードが何であろうと、リハーサルなら必ず宛先を制限する。「テストモードのとき、かつ」という条件そのものを消しました。

ついでに、その修正が生む二次被害も潰しました。宛先の許可リストが空だったら、どうなるか。「制限する対象が無い」＝「制限なし」と解釈されて、また全員に飛びます。許可リストが空のリハーサルは、エラーにして拒否するようにしました。安全装置を直すときは、その安全装置が空振りする場合まで考える——1つ目の穴を塞いだ勢いで、2つ目を作らないためです。

残る7件 ── どれも「動いているように見えた」

この8件のほかに、同じ性質の穴がもう1つありました。宛先の許可リストが空のとき、内部処理が「制限なし」として扱うというものです。バグ①の二次被害と、まったく同じ形をしています。

並べて気づくことがあります。8件すべてに共通しているのは、「画面上は正常に見える」ことです。クラッシュしない。エラーも出ない。それらしく動く。だから、動作確認では見つかりません。#4の9時間ズレなど、表示までズレているので、何度確認しても「合っている」ように見えます。

AIコーディングの失敗は、4つの型に分かれる

8件を並べ直したところ、きれいに4つの型に分かれました。これは私たち自身の解釈ですが、この記事で読者にいちばん持ち帰ってほしい部分です。

この4類型から、私たちが取り出した一般則は3つです。

一般則1：AIコーディングの成果物は、「動く」ことでは検証できない

#1・#2・#4は、テストモードで動かす限り、永久に正常に見えます。「切り替えた瞬間」にだけ発火する。これは注意力の問題ではなく、構造の問題です。テスト環境と本番環境で振る舞いが変わる箇所は、原理的にテストでは守れません。

そして厄介なのは、AIコーディングではこの不発弾の埋設速度も上がるということです。6日で141コミット書けるということは、6日ぶんの地雷を埋められるということでもあります。速さは、良いものだけを増やしてはくれません。

一般則2：危険なのは、AIが書いたコードではなく、AIが書かなかったコード

#2は、書き間違いではありません。書き漏らしです。予約配信の処理にモード確認が「無い」。そして——無いものは、差分レビューに映りません。

AIが書いたコードを1行ずつ確認する運用は、多くの会社が始めています。ですがそれは、書かれたものしか見ていない。書かれなかったものを見つけるには、「ここには何があるべきか」を先に知っている必要があります。

だから「何が無いか」を問える設計が、前提として要ります。これが後述する「単一チョークポイント」「単一述語」の話です。安全弁が1箇所にしかなければ、「そこに無い」は見えます。5箇所に散らばっていたら、4箇所目の欠落は誰にも見えません。

★一般則3：速く作ることと正しく作ることは、能力の差ではなく工程の差

これが、この記事の結論です。

先ほど書いたとおり、8件は実装フェーズでは1件も出ず、レビューフェーズで全件出ました。同じモデルが、同じコードから、指示の枠を変えただけで8件見つけたのです。

この事実の含意は、決定的だと思っています。

• AIには、これらを見つける能力があった。能力の不足ではありません
• にもかかわらず「作れ」と言われている間は、1件も報告しませんでした
• つまり足りなかったのは能力ではなく、「疑え」と言う工程だった

「AIはまだ品質が…」という議論は、たぶん的を外しています。モデルが賢くなっても、「作れ」としか言われなければ結果は同じです。AIは指示された枠の中で最善を尽くすので、枠に「疑う」が入っていなければ、疑いません。

かつて開発が遅かった時代、その遅さは意図せぬ検査として機能していました。実装に3日かかれば、その3日のあいだに「あれ、これ本番だとまずくないか」と気づくチャンスがあった。速くなると、そのチャンスごと消えます。だから失われた検査を、工程として設計し直すしかありません。

私たちが8件を見つけられたのは、AIが優秀だったからではありません。公開前に立ち止まり、「疑え」と言い直したからです。

目的から逆算した設計 ── 安全弁を1箇所に、判定を1つに

8件を直したあと、設計そのものを見直しました。個別のバグを潰すだけでは、また同じことが起きるからです。そして一般則2のとおり、「何が無いか」を問える形にしておかないと、次の書き漏らしも見えません。

安全弁を、単一のチョークポイントに置く

入れたのは「全部の送信が、必ず1箇所を通る」という構造です。テスト送信も、一斉配信も、ステップメールも、監視も、再送も——すべて同じ安全弁を通ります。そこで「本番モードでなければ、許可リスト以外へは1通も出さない」と判定する。全送信経路の単一チョークポイント——この一点を抜けずにメールが外へ出る道は、1本もありません。

バグ①・②が起きた原因は、まさに「送信経路ごとに判定が書かれていた」ことでした。経路が5本あれば、5箇所で間違える機会があります。1箇所に集約すれば、間違える機会も1箇所になる。そして何より、1箇所なら「そこに無い」が見える。

判定を、単一の述語に統一する

同じ発想を、「そもそも送れるかどうか」の判定にも適用しました。画面も、送信の処理も、予約の定期処理も、まったく同じ判定を参照します。判定を1箇所に集約しないと、画面が「送信できます」と言っているのに処理側が弾く——あるいはその逆——という状態が必ず生まれるからです。

これはバグ#5そのものです。画面は「予約できました」と言い、定期処理は「条件未達なので送らない」と判断する。両方それぞれの理屈では正しく、噛み合っていないだけ。AIは、片方の画面を見ながら片方のコードを書きます。だから契約は、コードの外側で1つにしておくしかありません。

核である「止める」を、実際に作る

「止める」に対応する実装も入れました。

• 配信中の進捗バーと、一時停止・中止。それ以前は誤送信に気づいても止める手段がありませんでした。核に「止める」と書いてあるのに、止まらなかったわけです
• 自動停止。配信中に受信拒否や苦情の割合が基準を超えたら、人の判断を待たずに配信を止めます
• 先行配信。いきなり全員に送らず、まず一部にだけ送って様子を見ます
• 本文を編集すると、送信前チェックとテスト送信が自動的に「やり直し」に戻る。古い本文で得たOKが、新しい本文に引き継がれる事故を防ぐためです
• 1時間以上前に予定されていた予約は、発火させない。本番へ切り替えた瞬間に過去の予約が暴発する（＝バグ#2）のを防ぐためです

これらは全部、AIが速く作ってくれる部分ではありません。手を動かす部分は数十分で終わります。時間がかかるのは「何が起きたら止めるべきか」を決めることで、それは人間の仕事です。

ちなみに、バグ①も②も「本番に切り替えた、その瞬間にだけ牙を剥く」という同じ構造でした。偶然ではないと思っています。レビューすべき場所は、実は絞り込めます——「モードによって挙動が変わるところ」と「取り返しがつかない操作」の交差点です。全部を等しくレビューしようとすると、時間が足りずに全部が浅くなります。

内部用語を、製品から追放する

設計思想として最初から決めていたことが、もう1つあります。作った側の言葉を、画面から追放することです。

「カナリア」は開発者には一発で伝わりますが、使う人には何のことか分かりません。分からない言葉のボタンは、押されないか、意味を誤解して押されます。メール配信で誤解して押されるのは、致命的です。

送信の入口も絞りました。押せるボタンは常に1つだけ。押せないときは、理由を平文で表示します。「条件を満たしていません」ではなく、何がどう足りないかを日本語で書く。一覧画面の「…」メニューからは、送信に関わるものを全部消しました。取り返しのつかない操作への入口は、少ないほどいいからです。

この点は、AIコーディングでむしろ悪化しやすいと感じています。AIは、開発者向けの語彙で書くのが自然だからです。「カナリアリリース」「フィーチャーフラグ」「べき等性」——放っておくと、そういう言葉がそのまま画面に出ます。技術的には正しい。だが、使う人には意味が分からない。

「実装は正しいが、使えない」は、内製ツールが静かに死ぬ典型的な理由です。誰も文句を言わないまま、ただ使われなくなる。そして発端を思い出してください。このツールは「使い勝手も悪く」という不満から生まれています。使い勝手が悪いものを、使い勝手が悪いまま作り直したら、何のために6日を使ったのか分かりません。

これはAIには任せられない仕事です。誰が使うかを知っているのは、人間だけだからです。

AIに、何を渡さないかを決める

このツールもAIを使っています。下書きの生成、文章の校正、記事ネタの要約、日本語の氏名の姓と名の分割——地味に効く用途ばかりです。ただし、渡してよいものの範囲は先に線を引いてあります。個人情報は渡さない。文面の生成に渡すのは、書きたいことの要旨と参照元だけ。分析に渡すのは、集計した数字だけ。そしてAI自身には、実送信をさせない。

メール配信は、購読者の情報を扱います。便利だからといって全部AIに投げれば、お客様の連絡先が外部に流れかねない。「AIに何をさせるか」より先に、「AIに何を渡さないか」「AIに何をさせないか」を決めるのが順番です。

成果 ── 測れているもの、まだ測れていないもの

成果の章です。ここは、言えることと言えないことを厳密に分けます。測っていないものを成果と呼ぶのは、8件のバグと同じ「動いているように見える」の一種だと考えているからです。

まずこのツールは、この記事の時点でまだ本番の一斉配信をしていません。テストモードのまま、許可した宛先以外には1通も出ない状態で止まっています。理由は配信基盤の審査待ちで、外部サービス側の手続きです。こちらが速く作っても短縮できません。

したがって「バグ8件」は、被害の記録ではありません。1通も誤送信していない段階で見つかったものです。ここを混同すると事実に反するので、はっきり書いておきます。

そして、これもAIコーディングの現実の一部だと思っています。コードは6日で書けても、外部の審査は6日では終わらない。「作る速さ」がボトルネックでなくなると、別のものがボトルネックとして現れます。

皮肉なことに、この待ち時間があったから8件を見つけられました。すぐ本番に出せていたら、「リハーサル配信で本配信が始まる」は本番で発見していたはずです。ここに教訓が1つあります。「すぐ出せない」を、待ち時間ではなく検査の時間に変えられるかどうか。私たちはたまたまそうなりましたが、本来は意識的に設計すべきものです。速く作れるようになった今こそ、「出す前に一晩置く」というルールには価値があります。

現時点で報告できる成果は、これだけです。

発端の3つの不満——コスト・使い勝手・件数制限——のうち、「解消した」と言い切れるものはまだありません。件数制限は構造上なくなり、使い勝手は自分たちの運用に合わせて作り直しました。ですがそれは、実際に送って初めて成果と呼べるものです。数字が出るまでは、数字を出しません。

その代わり、この6日で確実に手に入ったものがあります。自分たちの業務が、どこで壊れるかを知っている状態です。既製サービスを使っていた頃、私たちは「送信がどう制御されているか」を1つも知りませんでした。いまは、止まる場所と止まらない場所を、全部言えます。これは、内製が本当に残す資産のほうです。

御社の業務にも移せること

ここまでの話を、読者の会社に移せる形に畳みます。

• 「そこそこ困っているが乗り換えるほどでもない」ツールを、棚卸しする。私たちの発端は、コスト・使い勝手・件数制限の3つでした。AIコーディングは、この膠着に第三の選択肢を入れます
• 速さは本物。ただし不発弾の埋設速度も上がる。6日で141コミット書けるということは、6日ぶんの地雷を埋められるということです
• 「動く」で検証しない。危険なバグは全部「画面上は正常に見える」タイプです。動作確認では出ません
• 「AIが書かなかったコード」を疑う。書き漏らしは差分レビューに映りません。だから安全弁は1箇所に集約する——1箇所なら「そこに無い」が見えます
• 「疑え」と言う工程を、カレンダーに入れる。8件は実装フェーズでは0件、レビューフェーズで8件でした。能力の差ではなく、工程の差です
• 「何が起きたら止めるか」を決めるのは、人間の仕事。実装は数十分、判断は何日もかかります
• 内部用語を画面から追放する。放っておくとAIは開発者の語彙で書きます。「実装は正しいが使えない」で、内製ツールは静かに死にます
• AIに何を渡さないか、何をさせないかを先に決める

このメールマガジン管理ツールは、GrowGroupが自社の課題を解くために内製した9本のツールの1つです。会議・採用・提案・育成・問い合わせ・アクセス解析——社内の業務を、ひとつずつ自分たちの手でDXしてきました。

これは特別な技術の話ではありません。「業務の課題を見つけて、動く仕組みに変える。そして、それが壊れる場所を見極める」——それだけです。そしてこの力は、Web制作という本業と地続きです。

よくある質問

AIコーディングは、結局のところ使えますか？

使えます。3つの不満から6日でツールが立ち上がったのは事実で、以前なら不可能でした。ただし「速く作れる」と「安全に動かせる」は別です。私たちの結論は、浮いた時間の一部を、確かめる工程に再投資すること。全部を機能追加に使うと、いずれ事故ります。

なぜAIはそのバグを書いたのですか？

AIのせいではありません。AIは「テストモードかつリハーサルなら制限する」というコードを、指示どおり正確に書きました。間違っていたのは指示のほうで、しかもテスト中は完璧に動いてしまう。AIは「いま動いている状態」で正しいコードを書き、「将来切り替わった状態」を想定しません。そこを考えるのは、いまも人間の仕事です。

テストすれば防げたのでは？

このバグは、テストでは絶対に再現しません。テストモード中は宛先が制限されるので、完璧に正常に見えるからです。本番に切り替えた瞬間にだけ牙を剥く構造でした。必要だったのは動作確認ではなく、「この条件式は、モードが変わったらどうなるか」を読むことです。

AIが書いたコードを、AIにレビューさせても意味がないのでは？

それが、この記事でいちばん意外だった点です。同じモデルが、同じコードから、8件見つけました。違ったのは指示の枠だけ——「作れ」ではなく「疑え」と言った。実装フェーズでは0件、レビューフェーズで8件です。能力の問題ではなく、工程の問題でした。もちろん最後に「本番で何が起きるか」を判断するのは人間ですが、レビューを1工程として明示的に立てるだけで、拾えるものは大きく変わります。

レビューは、何を見ればいいですか？

私たちが8件を見つけた観点は、「取り返しがつかないのはどこか」×「モードで挙動が変わるのはどこか」でした。メール送信、データの削除、外部への公開——戻せない操作の周辺だけを、集中的に読む。全部を等しくレビューしようとすると、時間が足りずに全部が浅くなります。

内製とパッケージ、どちらがいいですか？

曲げたくない運用があるかどうかです。メール配信そのものは、優れた既製サービスがたくさんあります。私たちが作ったのは、コスト・使い勝手・件数制限という具体的な不満が3つ揃っていて、なおかつ自社の顧客管理や社内のネタ収集と繋ぎたかったから。「作れるから作る」は失敗します。

まとめ：速く作れる時代だから、「疑う工程」を設計に入れる

発端は、既存のメール配信サービスへの3つの不満でした。コストが高い、使い勝手が悪い、件数制限がある。そこから6日、141コミットで、ツールは立ち上がりました。AIコーディングの速さは本物です。

ですが、5日目の夜に自分たちのコードを疑ったら、重大なバグが8件出ました。すべて「画面上は正常に見える」タイプで、動作確認では出ないものです。とくに「リハーサル配信で本配信が始まる」は、本番に切り替えた瞬間にだけ牙を剥く構造でした。1通も送る前に見つけられたのは、幸運でした。

そして、いちばん学びが大きかったのはここです。8件は実装フェーズでは1件も出ず、レビューフェーズで全件出た。同じモデルが、同じコードから、指示の枠を変えただけで見つけました。速く作ることと正しく作ることは、能力の差ではなく工程の差です。

開発が遅かった時代、その遅さは意図せぬ検査でした。速さを手に入れたなら、失われた検査を設計で取り戻す必要があります。

「AIで業務ツールを内製したい」「でも事故が怖い」「何から手をつければいいか分からない」——そうした課題があれば、ぜひ一度ご相談ください。ツールを売る立場ではなく、実際に自分たちで作って、転んで、公開前に踏みとどまった立場から、御社の業務に合わせた進め方をご提案します。現状をお聞きしたうえで、無料でご提案します。ご相談・お見積りはこちら

無料ダウンロード資料

GrowGroup株式会社の制作事例・料金がわかる資料を配布中

会社概要・制作実績・料金の目安をまとめた資料です ／ PDF

資料をダウンロード