AIでサイトを作る話は、成功談ばかりが流れてくる。壊れた話を、壊れた本人が書いたものは少ない。
書ける立場なので書く。私はAIとこのメディアを運営する中で、SNSに貼っても画像が出ない・キャラ画像だけ表示されない・トップページが別物になるといった事故を一通り食らってきた。原因の系統と、再発を止めた方法までセットで公開する。
この記事の要点
- 事故は4系統に分かれる。設定・実装・参照・越権
- どれも症状をAIに渡せば調査は進む。確認と検証が人間の仕事だ
- 事故ゼロは狙わない。10分で戻れる状態を狙う
- 全事故は検査項目に変換して、同じ事故の2回目を止める
事故の全体像。4系統に分けると見通しが立つ
以下、系統ごとに実物の事故を書く。
系統1。設定の事故。1行のミスで、SNSの画像が全滅した
ある時期、このサイトのURLをSNSに貼っても、プレビュー画像が一切表示されない状態が続いていた。
原因は、検索エンジン向けの設定ファイルの1行だった。クロール制御の記述が広く効きすぎて、画像を生成する仕組みへのアクセスまでブロックしていた。記事は正常、サイトも正常、でもSNSでは画像が出ない。目に見える場所が全部無事だから、気づくのが遅れた。
対処はAIに症状を渡して調査させ、原因の行を特定して修正した。教訓は2つある。
- 設定ファイルの変更は、影響範囲を必ず質問してから通す。｢この変更で何が変わるか、副作用は何か｣を先に説明させる
- 公開後の確認は、サイトの中だけでなく外からもやる。SNSに貼ってみる、検索結果を見る。外側の確認を怠ると、この系統は見逃す
ここまでのまとめ
・事故は4系統に分かれる。設定・実装・参照・越権
・どれも症状をAIに渡せば調査は進む。確認と検証が人間の仕事だ
・事故ゼロは狙わない。10分で戻れる状態を狙う
系統2。実装の事故。キャラ画像だけが表示されない
サムネイル用のキャラクター画像が、特定の条件でだけ表示されない事故もあった。原因は画像生成の実装での属性の型エラー。要は、AIが書いたコードの細部に、特定条件で失敗する書き方が残っていた。
この系統の怖さは、全滅しないことだ。大半のページは正常に見えるから、｢たまに変｣という曖昧な症状になる。曖昧な症状は放置されやすい。
対処で学んだのは、｢たまに起きる｣を報告する時こそ、条件を具体的に渡すことだ。どのページで、どの環境で、何が出ないか。再現条件が絞れれば、AIの調査は一気に進む。逆に｢なんか変｣のままでは、AIも人間のエンジニアと同じで動きようがない。
系統3。参照の事故。存在しない記事へのリンク
週次の検査で、存在しない記事へのリンクが3箇所見つかったことがある。AIが記事を書く際、｢ありそうな記事｣への内部リンクを作ってしまっていた。
これは経歴の捏造事故と同じ根を持つ。AIは、もっともらしさを優先して、存在しない参照を作る。リンク切れは読者の信頼と検索評価の両方を削るから、量産運用では必ず踏む地雷だと思っていい。
対処は仕組み化の一択だ。全記事のリンク先の実在を自動検査するスクリプトを作らせ、週次で回す。人間が目視で400記事のリンクを追うのは不可能で、この系統は最初から機械の担当にする。検査の項目リストはAI記事の検品リスト10項目にまとめた。
系統4。越権の事故。朝、トップページが別物になっていた
一番肝が冷えた事故だ。ある朝サイトを開くと、トップページが見覚えのない別のページに置き換わっていた。
原因は指示の出し方にあった。別のページの制作を任せた際、触ってよいファイルの範囲を指定していなかった。AIは善意で、関係のないトップページまで作り替えていた。
復旧は、過去の保存地点からの復元で済んだ。作業のたびに保存する運用にしていたことが、ここで効いた。保存の習慣がなければ、トップページを作り直す羽目になっていたはずだ。
再発防止として、担当範囲の線引きをルールファイルに明文化した。このフォルダは触ってよい、このフォルダは禁止。以来、越権は起きていない。範囲指定の考え方は夜間バッチ運用の指示文の型にも組み込んである。
事故ゼロではなく、10分で戻れる状態を目指す
4系統を並べて、伝えたい結論は1つだ。事故は起きる。だから、起きた時に小さく済む型を先に作る。
- 作業のたびに保存する。戻れる地点があれば、最悪の事故も復元で済む
- 触ってよい範囲を、指示に毎回書く。越権は指示で防げる
- 公開前に検査、公開後に実機確認。発見が速ければ、被害は読者に届く前に止まる
正直に言えば、事故のたびに｢AIに任せるのが怖い｣と思う瞬間はあった。それでも続けているのは、同じ事故の2回目が起きていないからだ。事故を検査項目とルールに変換する限り、運用は事故のたびに硬くなる。壊れない運用ではなく、壊れても立ち直りが速い運用。個人がAIと組む現実解はこちらだと思うんよ。
これから立ち上げる人は、個人メディアの立ち上げ手順に書いた順番で、検査の仕組みを量産より先に作ってほしい。私の事故のいくつかは、その順番を守っていれば起きていない。
あわせて検索される疑問に、先に答えておく
トラブルが怖くて一歩目が踏み出せません
怖さの正体を分解すると、たぶん｢壊したら取り返しがつかない｣という想像になる。だから最初にやるべきは、取り返しがつく環境を作ることだ。本物のデータではなく複製で試す、作業のたびに保存する、この2つだけで、失敗の被害は｢やり直し｣のサイズに縮む。私の事故一覧を見て分かる通り、どれも復旧できている。壊れない運用は存在しないが、壊れても戻れる運用は最初から作れる。怖さは、準備で潰せる種類の感情なんよ。
AIに全部任せているのに、なぜ人間がトラブル対応を学ぶ必要があるのですか
問題に気づくのが人間の仕事だからだ。この記事の事故を見返してほしい。SNSで画像が出ない、特定の画像だけ消える、トップページが変わった。どれも、異変に気づいたのは私で、原因を調べて直したのはAIだ。この分担は変わらない。AIは指摘された問題を直すのは速いが、誰も指摘しない問題には存在しないのと同じ扱いをする。人間が学ぶべきはコードの読み方ではなく、自分のサイトの正常な状態を知っておくことだ。正常を知っている人だけが、異常に気づける。
バックアップはどのくらいの頻度で取ればいいですか
作業の節目ごと、が答えになる。時間で区切るより、意味のまとまりで区切る方が実用的だ。記事を10本足したら保存、機能を1つ変えたら保存。私の運用では、1日に数回の保存が自然に発生する。この習慣の価値は、戻りたい地点が細かく刻まれることにある。1週間分をまとめて保存していた場合、事故ったら1週間分やり直しになる。保存の粒度が、事故の被害の最大値を決める。そして保存の実行自体はAIに指示すれば数秒で終わる。コストはほぼゼロで、保険としての価値は大きい。
3分で診断：副業・独立タイプ診断——あなたに合う副業の入口を8問で判定する。無料・登録不要。
よくある質問
非エンジニアがトラブルに遭ったらどう対処すればいいですか？
症状を具体的にAIに渡して調査させる。人間の仕事は実機での確認と、事故を検査項目に変換することの2つだ。
AIが作ったサイトは壊れやすいのですか？
壊れやすさは大差ない。速度が速い分、確認が追いつかないと壊れたまま量産される点だけが違う。気づく仕組みが本体だ。
トラブルを未然に防ぐ方法はありますか？
完全な予防は無理だ。保存の習慣・範囲の明記・公開前検査の3つで、事故から10分で戻れる状態を作る方が現実的になる。
この副業クラスタの全体の順路は会社の外で稼ぐ人の順路に、入口の全体像はAI副業は何から始めるかにまとめてある。自分の段階に合う記事から読んでほしい。
事故対応の型はLINEでも配っている
AI運用のトラブル対処チェックリストを、LINEで無料配布している。事故は避けられない。だが2回目は避けられるんだわ。
