こんにちは。Sqripts編集部のハチワレです。
最近は生成AIに携わることが多く、日々の進化を驚きと喜びを感じながら眺めています。そして、「コードを書く」ことの垣根がどんどん低くなっていることも、「AIってすごいな～」ぐらいの気持ちでただただ感心して眺めておりました。
今回は、そんな私が実際に遭遇した「ちょっとヒヤッとした話」をもとに、生成AI時代の実装リスクについて書いてみたいと思います。
あくまで「とあるDX現場の物語」として読んでいただければ幸いです。
※本記事は、実際に現場で起きた出来事をもとに構成しています。登場人物・インシデントの内容は一部変更しています。
ある日、フォームが動かなくなった
「フォームが表示されません」
こんな連絡が届いたのは、ごく普通の業務日のことでした。
確認してみると、たしかに挙動がおかしい。コードに少し修正を加えるように伝えると、今度はこう返ってきました。
「フォームは動きましたが、フォーム送信完了ページ（サンクスページ）が404です！」
……サンクスページが、ない！？（404は「ページが見つかりません」のエラーコードです）
調査を進めてみると、MA（マーケティング・オートメーション※）側の設定を、あるマーケティング担当者が生成AIと対話しながら変更していたことがわかりました。
※マーケティング・オートメーション（MA）とは、フォームの発行、ユーザー管理、メール配信など、マーケティング活動に関わる様々な機能を持つツールのことです。
「動いた」と「大丈夫」は、まったく別の話
その担当者に、開発の経験はありません。
それでも、生成AIに「やりたいこと」を自然言語で説明してJavaScriptのコードを生成してもらい、MAに実装することができました。
コードは動き、担当者は大きな成功体験を得ました。
問題は、誰もその「先」を確認していなかったことです。
—
ここで少し、「影響範囲」という概念についてお話しさせてください。
システムやWebサイトを構成するコードは、それぞれが独立しているようで、実はさまざまな形でつながっています。あるページの挙動を変えるコードが、別の処理の前提条件になっていることも珍しくありません。
今回のフォームと送信完了ページがまさにそれでした。
表から見ると、「フォームを送信する。送信後に『ありがとうございました』のようなページが表示される」というシンプルな存在です。しかし裏側では、いくつかの処理が連鎖していました。
- フォーム送信の完了を検知して計測する処理
- 送信者の情報をほかのツールに連携する処理
- 担当者への通知やスコアリングに関わる処理
など、このフォームから送信完了ページへの遷移は、「ユーザーが正常にフォームを送信した」というシグナルでもあったわけです。そのシグナルを受けて、複数のシステムが動いていました。
変更されたコードは、この一連の流れに割り込みました。結果、送信完了ページは404エラーを返し、連携データは正常に記録されなくなっていました。フォームそのものは見た目上は「動いて」いましたが、その裏側で起きるべきことが、静かに止まっていたのです。
フォームが「動いた」のは確かです。でもそれは、「大丈夫」ではありませんでした。
影響範囲とは、「自分が触れたコードが、どこまでの処理に関係しているか」という見取り図のようなものです。この見取り図を持っているかどうかが、「動かせる」と「安全に実装できる」の分かれ目になります。
悪意があった人は、誰もいない
誤解のないようにお伝えしておくと、今回の件で悪意があった人は一人もいません。
担当者は業務を効率化しようとしていましたし、生成AIを活用しようとしていました。その姿勢は、むしろ前向きです。
Webサイト側の担当者も、相談は受けていました。ただ、コードの中身をレビューできる知識はなく、「何かを変えるらしい」とは知っていても、何がどう変わってどんな影響が出るかまでは判断できませんでした。
そして、もうひとつ大事なことがあります。
実装した担当者は、そもそも「フォームや送信完了ページに『他の働きをする何か』が仕込まれている」という知識を持っていませんでした。表から見ればただの入力フォームと送信完了ページ。まさか、その裏側でツール連携や計測が動いているとは、思いもよらなかったのです。
「確認しなかった」のではなく、「確認すべきものがあると知らなかった」。これは責める話ではありませんが、だからこそ厄介です。本人の注意や意識だけでは、防ぎようがない。
誰も手を抜いていないのに、システムは壊れた。
これが今回、私が一番伝えたいことです。
「コードが書けない」という壁が、なくなった
少し前まで、「コードが書けない人」はコードを書きませんでした。当たり前のことですが。
やりたいことがあっても、実装する手段がない。だから、担当範囲を超えた変更は物理的に起きにくかったのです。
「この機能を変えたい」と思っても、コードが書けなければエンジニアに依頼するしかない。依頼するということは、必然的に「何をどう変えたいのか」を説明し、確認してもらうプロセスが発生する。面倒に感じることもあったでしょうが、このプロセスが「影響範囲の確認」を担っていたと言えます。
生成AIは、その壁を取り払いました。
プログラミングの知識がなくても、やりたいことを言葉で説明すれば、動くコードが出てきます。エンジニアへの依頼も、確認のプロセスも、必要なくなりました。
これ自体は、すごいことです。間違いなく。
ただ、壁が取り払われたとき、同時に「ゲート」も消えてしまいました。
エンジニアが影響範囲を判断するタイミング、このプロセスが、いわば「実装前のゲート」として機能していたのです。生成AIによって誰もが一人で完結できるようになったことで、そのゲートもなくなってしまいました。
「書けるようになった」と「わかるようになった」は、まったく別の話です。
生成AIはコードを書いてくれます。でも「このコードが既存のシステムと干渉しないか」「影響を受けるのはどの処理か」「変更前に誰に相談すべきか」という問いを立てられるのは、影響範囲の見取り図を持っている人、つまりシステム全体を俯瞰して把握している人だけです。
もちろん、生成AIにその見取り図を渡すことができれば影響範囲の判定もしてくれます。
ですが、見取り図を持たない人に、その「問いを立てる力」は、生成AIは与えてくれません。（今のところ）
だからこそ、「人間が介在する」設計が必要になる
ここで、AIの世界でよく使われる概念をひとつご紹介したいと思います。
HITL（Human-in-the-Loop） という考え方です。
AIによる自動化されたプロセスに、意図的に人間が介在する仕組みのことを指します。AIが得意な「大量処理・高速生成」と、人間が得意な「判断・文脈の理解・倫理的な配慮」を組み合わせることで、より質の高い結果を目指す、という発想です。
私はこの概念がとても好きで、AIの活用を考えるときの基本的な視点として大切にしています。
今回の件は、まさにHITLが機能していなかったケースです。
生成AIがコードを生成する→人間がそのまま実装する、という流れに、「影響範囲を判断できる人間」が介在していなかった。AIの出力を人間がレビューし、「これは既存のシステムに影響しないか」「担当者に確認が必要ではないか」と判断するステップが、すっぽり抜けていました。
AIを使うこと自体が問題なのではありません。AIの出力をそのまま「正解」として扱い、人間の判断を挟まなかったことが、問題だったのです。
「これ、大丈夫なやつ？」という感覚
私はこれを、「大丈夫チェック」と呼んでいます。
コードを実装する前に一瞬立ち止まって、「これ、大丈夫なやつ？」と自問する。シンプルな問いですが、これができるかどうかが、今の時代に大きな差を生むのではないかと思っています。
具体的には、こんな確認です。
- 全体のシステムのどの部分に触れる変更か
- 既存のコードや設定と干渉する可能性はないか
- 担当者への事前確認は完了しているか
こうした確認を、属人的な「声かけ」に頼るだけではなく、チームの手順として持っておくこと。それが「動いた」と「大丈夫」のギャップを埋める方法だと、今回の経験から強く感じました。
そして、この「大丈夫かどうか」を仕組みとして担保するのが、「テスト」という考え方です。
変更後に期待通りに動くかを確認するだけでなく、「既存の動作が壊れていないか」を検証するテスト（リグレッションテストと呼ばれます）は、まさに今回のようなケースの再発を防ぐための安全網になります。
生成AIが実装の入口を広げたことで、テストの重要性もまた、以前より増していると感じています。
まとめ
今回お伝えしたかったことを整理すると、こうなります。
- 「動いた」≠「大丈夫」：生成AIが生成したコードが動作することと、既存システムに悪影響を与えないことは別の話
- 壁がなくなった時代のリスク：誰でも実装できるようになったからこそ、「影響範囲を測る」プロセスの重要性が増している
- 悪意より怖い「善意のインシデント」：誰も悪くないのに壊れる、というケースへの備えが必要
- 「問いを立てる力」は人間が持つ：生成AIはコードを書いてくれるが、「これ大丈夫？」と問えるのは、構造を知っている人間だけ
- HITLの視点を持つ：AI任せにするのではなく、判断できる人間がプロセスに介在する設計を意識する
- 「テスト」は「大丈夫」を仕組みにする手段：変更が既存の動作を壊していないかを確認するテストが、善意のインシデントを防ぐ安全網になる
生成AIの登場で、ソフトウェアに関わる実装のハードルは確実に下がっています。だからこそ、「実装してよいかを判断する人・仕組み」の価値は、むしろ上がっているのではないでしょうか。
この記事が、どなたかの現場での一助になれば幸いです。
最後までお読みいただき、ありがとうございました。
本記事は、実際にとあるDX現場で起きた出来事をもとに構成しています。登場人物・インシデントの内容は一部変更しています。
▼非エンジニアにもおすすめの関連記事
