ハクソク

世界を動かす技術を、日本語で。

AIバイブコーディングホラー物語

3日前原文(www.tobru.ch)

概要

  • AI活用による自作システムが医療現場で導入された事例
  • 重大なセキュリティ問題が発生し、患者データが無防備に公開
  • 法的リスクやプライバシー侵害の可能性
  • AIツールの無理解による危険性の指摘
  • AI時代の課題と今後への懸念

私が体験したAIコーディングホラー：医療現場での現実

  • 医療機関の受付での出来事

    • フレンドリーなスタッフによる案内
    • AIで誰でも簡単にソフトウェア開発ができるという動画を見たとの話

  • 自作患者管理システムの導入

    • コーディングエージェントを起動し、独自の患者管理アプリを作成
    • 既存の患者データを全てインポートし、インターネット上で公開
    • 診察中の会話録音機能を追加し、音声データを2つのAIサービスへ送信して自動要約
    • 手動での記録作業を廃止

  • セキュリティ問題の発覚

    • アプリを調査し、30分で全患者データへの読み書きアクセスが可能に
    • データは暗号化されず、インターネット上で完全に公開状態
    • すぐにスタッフへ通知
    • 返答はAI生成のテンプレートで、基本認証追加やアクセスキーのローテーションを報告

  • 根本的な問題点

    • スタッフは構築したシステムの内容やリスクを理解していない
    • データは米国サーバーに保存、データ処理契約なし
    • 音声記録は米国のAI企業へ送信、患者への事前説明なし
    • 医療データの扱いとして明確に不適切

  • 法的リスク

    • nDSG（新データ保護法）や職業上の守秘義務違反の可能性
    • 法律の専門家ではないが、明らかに複数の規定に抵触

技術的背景

  • アプリケーションは単一のHTMLファイル
    • JavaScript、CSS、構造が全てインライン記述
  • バックエンドは管理型データベースサービス
    • アクセス制御なし、行レベルのセキュリティなし
    • 全てのアクセス制御ロジックはクライアントサイドのJavaScript内
    • データは誰でもcurlコマンド一発で取得可能
  • 音声データは外部AI APIへ直接送信
    • 転送・要約処理を完全外部依存

今後への展望と懸念

  • 望ましいAIの未来像とはかけ離れた現状
  • AIコーディングエージェントの活用は有用だが、コードやアーキテクチャの理解が不可欠
  • 無知なままAIに依存する危険性の強調
  • 誰もが「ノリ」でAIを使う未来は、決して安全で幸せなものではない

Hackerたちの意見

一方、LinkedInでは… 技術的な理解がゼロの営業マンたちが、AIで全てを解決できるって大声で叫んでる。解雇や経済問題、何でもかんでも。ほんとに悪いことが起こるのは時間の問題だよ。
└
コーディングのヒンデンブルク。
└
悪いことが起こってるみたいだね。本当に悪いことは、命や生計に対する脅威と考えるとちょっと怖い。次世代のモデルがこの問題に何をもたらすか見てみよう。
スペインの地元企業に似たようなことをしたことがある。医療関係じゃなくて、小さな保険会社なんだけど。信じられないかもしれないけど、彼らはCRMを「バイブコーディング」してたんだ。メールを送ったら、訴えるって脅された。そんなバカな反応にちょっとショックだったけど、学ぶのが遅い人もいるから、まずはスペインのデータ保護機関（AEPD）に報告した。あそこは厳しいことで有名だからね。先週の金曜日には、彼らのシステムから私のデータを削除するようにバウロファックスも送ったよ。
└
一度手を火傷するのはいいけど、会社だと学ばないよね。
└
> [バウロファックスは] 配達証明と受取日確認の証明書付きで文書を送るサービスで、この確認には法的効力があります。
└
せめてチョコレートくらいくれてもいいよね。紙の文書があれば、すぐにでも安全になると思う :)
└
OWASPツールをエージェントと一緒にセットアップして、会社のツールをクローリングするのにどれくらいの労力がかかるのか、ちょっと興味あるな。これを考えたのは私だけじゃないと思うけど、地元のビジネスにとっては良い評判になるんじゃないかな。来年のテーマはセキュリティになる気がする。みんな、テクノロジーに関しては頭を使わなくなってるよね。
└
> AEPDは…残酷だって知られてるね。いいね。もっと多くの国がこんなのを持ってほしいな。こういう組織はだいたい無気力で、市民の努力やメディアによって行動を強いられないと動かないから。
└
このスレッドで進展を教えてくれる？
└
昔、Wi-Fiがまだ新しかった頃に似たようなことがあった。オープンネットワークに参加したら、法律事務所だったんだ。彼らのコンピュータは全てSambaネットワークでCドライブが共有されてた。問題について知らせるREADME.txtファイルをドライブに書いたけど、しばらくしても変わらなかった。それで、直接その場所に行って話をしようと思ったし、最初の仕事を得るチャンスかもって思ってたんだけど…彼らはすごく怒って、いい契約者がコンピュータやネットワークを管理してるって言って、私が侵入したみたいに言われた。急いでその場を離れたよ…
└
こういうアプリを作ってる人たちは、データプライバシーのルールについて全然知らないことが多いよね。私は小規模ビジネスのオーナーが集まるフォーラムに参加してるんだけど、あるオーナーが自分のビジネスアプリをvibeコーディングで作ったってすごく自慢してた。最初の反応は「すごいな！」だったけど、データプライバシーのルールの話が出てきたら、全然知らなかったんだよね。これは心配だった。彼のビジネスだけじゃなくて影響があるから。指摘したときの彼の反応は、法律を知らないことが彼を守るって言ってた。結局、vibeコーディングのRedditのサブに助けを求めに行ったんだけど、戻ってきたら怒ってた。Redditの開発者たちが「ちゃんとした開発者を雇え」って言ったから。彼は、そういう開発者たちは妄想に取り憑かれてるし、もうすぐ死に絶える種族だと思ってる。AIが進みすぎて、開発者は1年後にはいなくなるって。
└
あんた最高だね。
これ、ネット小説みたいに感じる。すごく曖昧で短い。
└
この件に関しては、会社の名前を明かすのは非常に倫理的に問題があると思う。ちゃんと修正されたことを確認するまでは、訴えられるのが怖いよ。
└
参考までに、トバイアスを知ってるけど、彼がこれをでっち上げるなんてありえないと思う。おそらく、犯人に関する情報が漏れないように意図的に曖昧にしてるんじゃないかな。それはまあ、妥当だと思う。
└
うん、まだオンラインなら場所を守るために曖昧にするのは理解できるけど、全体的にあまり意味がわからないよね？言及されているタイムラインも変だし、彼はそれを作る前に話したの？それとも後？はっきりしない。彼は動画を見たと言ってるし。 > 「アプリケーション全体は、すべてのJavaScript、CSS、構造がインラインで書かれた単一のHTMLファイルだった。」 これはエージェントが作るものとは全然違う経験だ。私はしばしば彼らにそうするように頼むけど、彼らはたくさんのファイルと構造を使う傾向がある。 > 「彼らは、アポイントメント中に会話を録音する機能を追加した。」 つまり、医者の部屋にフロントデスク用のノートパソコンがあるの？それとも、会話を録音していて、後でシステムにフィードするために使ってるの？ > 「すべての「アクセス制御」ロジックはクライアント側のJavaScriptに存在していて、データは見ようと思えば一コマンドでアクセスできる状態だった。」 これもエージェントが何かを作る普通のやり方じゃないよね。セキュリティの欠陥はあるけど、これはプログラミングを学び始めたばかりの人が作ったか、r/programmerhorrorで最もアップボートされた投稿みたいな感じで、AIとはあまり関係ない気がする。全体的に、この記事の主張にはもっと強い証拠が出てくるまで懐疑的だよ（医療システムにいい加減なものを使うのは支持してるわけじゃないけど）。
└
今、こういうことが起こってるって確信してるよ。
└
短い文章は良い文章だよね。それに、曖昧じゃなくて、ただ特定の情報を省いただけだよ。
└
そうじゃないと思うけど、これがAI生成のクリックベイトになったらめっちゃ面白いよね。
└
同意だね。明らかに事実を捏造する手前の、否定可能なところにあるよ。
└
ドイツだから、できるだけ一般的にした方がいいよ。名誉毀損やプライバシーに関する法律がかなり強いからね。
ソフトウェアエンジニアリングは、各国に専門機関が必要になってきてる気がする。認定や基準も必要だよね。つまり、他の工学分野と同じように成長しなきゃ。自分で学んだからって、「今はプロの環境でソフトウェアを設計できる」ってのは通用しなくなるべきだよ。ゲートキーピングを推奨してるわけじゃないけど、自分の庭の端に小さな橋を作りたいならそれでいい。でも、町の川に橋を架けたいなら、プロの認定が必要だよね。ソフトウェアエンジニアリングも同じことが言えるはず。
└
専門機関は、この手のことに関してはただの門番と金を求める存在に過ぎない。誰でもソフトウェアは書けるけど、セキュリティを考えたソフトウェアを書く人は限られてる。すでに法律や基準を守っているかどうかを理解するための認証もある。これらの有効性や価値について議論することはできるけど、インフラや法律、フレームワークはすでに存在してる。現状が守られていないのに、規制や官僚主義を増やしても意味がないよ。
└
兄弟が指摘したように、個人を特定できるデータの取り扱いに関する法律はすでにたくさんある。なぜか意識が欠けている気がするけど、高プロファイルな有罪判決がいくつか必要なのかも（それもそう遠くないと思う）。
└
ほとんどの国にはすでに法律や基準があるよ。この特定の例では、人々はプライバシーやデータ保護の法律を完全に無視してた。
└
規制は血で書かれていて、バイブコーディングが十分な問題を引き起こすまでには少し時間がかかるだろうね。
└
それに同意するし、この言葉を支持するよ。人々がこれをゲートキーピングと呼びたがるなら、それでもいい。プログラミング、ソフトウェアエンジニアリングは真剣な分野で、この狂乱は止めるべきだと思う。ソフトウェアの構築は、どんな真剣な活動と同じように規制され、適切に認定されるべきだ。
└
> ソフトウェアエンジニアリングは、各国に専門機関が必要になってきているように見えるし、認定や基準も必要だと思う。人々が価値があると思うルールを自主的に作ろうとするのはいいけど、それにはさらなる制限的な行動は必要ないと思う。
└
>> ソフトウェアエンジニアリングは、各国に専門機関が必要になってきてる気がするし、認定や基準も必要だよね。あんまり役に立たないけど、会計士も認定や基準が必要だけど、それでも競争は100人の会計士が1つの仕事に殺到するレベルだし。これを防ぐには、弁護士みたいに人数を制限するしかない。コネや縁故が重要になってくると、基本的に世襲の貴族階級ができちゃうよね。未来の資本主義がもたらすのは、飢えぎりぎりのクソみたいな仕事をする農民に戻ることだと思うよ。
└
問題は、その人が自分の専門的な立場でも何をしているのか全然わかってなかったことだと思う。患者データ管理について知識が必要だったのに、全く知らなかった。私の見解では、彼らがやっていることが間違っていると気づいていなかったら、認定が必要だとも思っていなかったはず。もちろん、無制限にツールにアクセスできるようにしなければの話だけど。AIが何で、何でないか、データプライバシーが何を意味するかがもっと議論されるうちに、時間が経てば自然と解決すると思う。認定については完全に外しておいた方がいいと思う。実際のベストプラクティスが何か、またそれが重要かどうかすら合意できてないから。
> 「すべての「アクセス制御」ロジックはクライアント側のJavaScriptに存在していて、データは見ようと思えば一コマンドでアクセスできる状態だった。」 これがトップだね！コーディングエージェントを使ってるのに開発者じゃない人の典型的な例だ。知らずにAIを使うのは、何をしてるか分からないと大きなリスクになる。プロの目的で使うAI（実験じゃなくて）は、いい加減に使うべきじゃない。これには重大な責任問題もある。開発者は責任から免れると考えがちだけど、ビジネスにとっては大きなリスクにつながるんだ。
└
問題はAIじゃなくて、この状況のどこかに賢い人がいないことだよ。AIが登場するずっと前に、ある医療会社がフロントエンドがバックエンドにSQLクエリを実行するように指示するサービスを作ってたのを見たことがある。
└
こういう作業には全然合ってないツールだよね。Claudeやopencodeとかは、実際にbashツールを使って、あとは漠然としたプロンプト（スキル、AGENT.md、MCPとか）を使って、望ましい行動に確率的に誘導するための力技のコーディングハーネスなんだ。ワークフローを制御して出力を検証するための専門的なハーネスを作らない限り、この問題は解決しないよ。今はLLMの使い方が西部開拓時代みたいなもので、そもそも存在しないはずの問題が出てきて、全然違うレイヤー（ハーネスの外）や全く間違ったツール（プロンプト）で解決しようとしてる。
知り合いを通じて、現在Lovableで自社のCRMを作っているブティック会計事務所が少なくとも一つあることを知ってる。彼らには技術スタッフがいない。どんな災害が待っているのか、想像もつかないよ。
└
一般的に、自分のCRMを作る理由って何？ERPや他のリソースプランニングシステムは、バックオフィスに合わせてカスタマイズできるからわかるけど、CRMには主に信頼性が必要だよね。
バイブコーディングはクールだと思うけど、すぐに限界が来ちゃう（少なくとも今はね）。数千行のコードを超えると、なんか崩れちゃうし…実際のシステムは大きいだけじゃなくて、めちゃくちゃなんだよね。たくさんのコンポーネント、サービス、エッジケース、変な方法で壊れることもあるし。それらを信頼性高く一緒に動かすのは全然別のゲームだよ。しかも、しっかりしたソフトウェアエンジニアリングの基礎も必要だし。アーキテクチャ、デバッグ、トレードオフ、失敗モードを理解しないと、生成されているものを導いたり評価したりするのは難しい。バイブコーディングはプロトタイプや趣味のプロジェクト、ちょっと遊ぶのにはいいけど、実際の生産システムにはちゃんとしたエンジニアリングが必要だよ。今のところ、何が作られているのか、どう作られているのかもわからないシステムにお金を払ったり、自分のデータを載せたりするのは100%ためらっちゃう。
└
それはほとんどの場合、うまくいかないよ。しかも、以前よりもさらに優れたエンジニアリングプラクティスが必要なんだ。人々が技術的負債を理解せずにコードの変更を受け入れてしまっているからね。これには同意する。ローカルで実行できるモデルもあるし、今朝は128GBのRAMでGemma 4をテストしたよ。すごく遅くて、何かをリファクタリングするのに20分かかったけど、20秒じゃなくてね。でも、高価なクラウドサブスクリプションで動いている有料モデルと同じくらいの能力があるみたい。しかも、データはアップロードされていない。
└
実際にClaudeのコードを使ってサンプルアプリを作ることをお勧めするよ。基本を知らなくてもアプリを作れるからね。私の経験では、最大20,000行のコードまで対応できると思う。フィードバックをくれる人間が必要だけど、ソフトウェアの原則を理解している必要はない。
└
いろんなメモリハックやコードをインデックスするツールがあるけど、私が見つけた中で一番効果的なのは、待っててね…Jiraなんだ。みんなJiraを嫌うけど、大規模プロジェクトを管理するには成熟したプラットフォームだよ。まず、JiraのRovo MCP（またはCLI、どっちでもいいけど）を使って、Claude Codeにアーキテクチャや機能を計画・文書化させるんだ。それから、これらの項目を手動でレビューして編集する。次に、クリーンなセッションで、実装させたり、コメントで決定事項を文書化させたりする。こうすると、大きめのプロジェクトでもすごく信頼性が高くなるんだ。最初にこれをソロプロジェクトでやり始めたときは、「ああ、そうだよね」って感じだった。人間の開発者に全プロジェクトを頭の中に入れろって言わないのに、コーディングエージェントにそれを求めるのはおかしいよね。このメンタルモデルがツールを正しく使うのに本当に役立った。追記：それからコンテキストウィンドウの管理もある。私はいつもOpus 4.6 1Mを使ってるけど、250kを超えると新しいセッションを始めるのが下手だったってことになる。自動圧縮状態には決して到達しない。LLMは与えられたコンテキストが多いほどバカになるっていうのは普遍的な真実だと思う。みんなもコンテキストステータスバーの設定を実装して、使用状況をチェックした方がいいよ。
数ヶ月前に似たようなことを見たよ。外科医がコーディングしたウェブアプリだった。動いてはいたけど、ルートウェブディレクトリにindex.htmlファイルがなくて、ソースコードを全てzipにしてバックアップをルートウェブディレクトリに置いていたんだ。そこにはデータベース接続文字列やAPIの認証情報、AWSの認証情報などが含まれていた。バックアップ用にデータベースもそのフォルダにダンプしてたから、https://example.com/にアクセスしたブラウザは全てのバックアップを見たりダウンロードしたりできた。簡単な修正は、空のindex.htmlファイルを作ること（またはapacheの設定で-Indexesオプションを設定すること）だった。でも、その外科医はそれが何を意味するのか、なぜ重要なのか全く分かっていなかった。そして、AIボットも同様だった。この件で奇妙だったのは、AIが良い選択をしていたこと（強力なパスワードハッシュ、合理的なDBスキーマなど）と、アプリ自体はうまく動いていたこと。正直、印象的だった。でも同時に、非常に基本的なデプロイメントやセキュリティのミスを犯していて、それは些細なことだった。経験豊富なDevOpsセキュリティの人から少しの指導があれば、インターネットに適したものになったはずなのに、誰もそれをしなかった。編集：ウェブアプリをウェブサーバー自体にバックアップすることはお勧めしないよ。それもまた基本的なミスだ。でも彼ら（またはAI）はそうすることに決めて、経験者に相談することはなかった。
└
修正方法は、ユーザーが認証情報をダウンロードできないようにすることだね。理想的には、ウェブサーバーは認証情報を含むファイルにアクセスできないようにして、静的コンテンツの提供とキャッシュを扱い、動的コンテンツのリクエストはウェブアプリのコードにオフロードするべきなんだ。自動インデックスを無効にすることは、問題を見つけにくくするだけだよ。（補足すると、原則として悪くはないアイデアだけど、_解決策_ ではない。）もしファイルがまだそこにあってダウンロードできるなら、それは最初から可能であってはいけないことだ。
└
エージェントネイティブのDevOpsツールはおそらく必要だね。手動でやる理由はないはずだ。私が考えるに、CCのようなエージェントはデプロイメントのためのスキルを内蔵していて、AWSや他のシンプルなプロバイダーのビルディングブロックを使うんだ。支払いはOAuthを通じて、シームレスなチェックアウトができる。これが標準化されるべきだね。
└
面白いね、AIは難しい部分をうまくやったんだ。パスワードハッシュやスキーマ設計は良かった。でも、実際の「コーディング」知識とは言えない部分でつまずいてる。運用の直感に近い感じかな？バックアップフォルダがウェブルートにあるのはセキュリティの問題じゃなくて、「過去に痛い目にあったことある？」って質問だし、外科医はそれを知らなかった。だから質問もしなかったし、モデルもそれをカバーしていなかった。私の意見では、これが実際のパターンだと思う。モデルは聞かれたことについてはしっかりとセキュリティを確保するけど、聞かなかったことについては全く分からない。経験豊富な開発者は、過去の失敗を全て持ち込むけど、雰囲気でコーディングする人はプロンプトを持ってくるだけなんだ。
他の分野では、高リスクの失敗モデルを理解した結果、最終的に同じ解決策に行き着いてる。つまり、詳細を理解している2人が確認すること。パイロットには副操縦士がいて、外科医はチェックリストを持ってるし、原子力発電所には独立した検証がある。ソフトウェアは常に例外だった。壊れたときは、ほとんど自分だけに影響があったから、バイブコーディングはその方程式を変えることはない。以前はあった「コードを書いた人が何が起こっているか理解している」というチェックがほとんどなくなっちゃった。
└
プルリクエストにはコードレビューがあるよ。でも、平均的にはかなりの自己満足があると思う。昔のちゃんとしたQAフェーズが一番の答えだったんじゃないかな。でも、それは高くて遅いんだよね。
もしそのAIが実装をできるだけ隠すように訓練されてたらどうなる？例えば、クライアントをできるだけ軽量にして、OAuthを使って認証して、しっかりしたテンプレートに従ったら、もっと良くなるかな？こういう簡単に手に入る災害を避けるのは可能だし、大手企業にはそれを修正するインセンティブがある。でも、目標は変わらないよね。すべてのソフトウェアエンジニアをDIYの甥っ子たちに置き換えること。もっと悪いのは、人々が難しいことを学ぶのが無理だと思い始めること。そうすると、速く動くことができなくなるから、ある領域から別の領域に移るのが難しくなる。私の専門分野は暗号学に近いんだけど、学生の中には、暗号学やセキュリティは行き止まりのスキルだと思ってる人が結構いる。なぜなら、この分野のすべての会社がAIに置き換わってるから。私は彼らに、できるだけシンプルにweb-bot-authを実装するように頼んだ。なぜなら、AIが仕様を読み取ってそれに従うことができるのを知ってるから。