生成AIで激変した“野良システム”問題 ヒヤリハットが起きたRelicはどう対策したか：どの企業でも起こりうる？ 非エンジニアがAIで作ったシステムとの向き合い方

非エンジニアでもAIを活用することで業務効率化に役立つシステムを構築できるようになる今、組織で管理されていない「野良システム」のリスクが高まっている。この問題にどう向き合えばよいのか？　新規事業開発を手掛けるRelicが野良システムを巡るヒヤリハット事例を機に整備した「開発ガイドライン」と、Claudeを活用した効率的なレビューの仕組みとは。

[大庭 亮（Relic）, 編集：石川俊明，＠IT]

　生成AIによって、数時間でWebサービスや業務システム、スマートフォンアプリケーション、botを作成できる時代になりました。こうしたシステムの作り手は、もはやITエンジニアにとどまりません。AIでWebアプリケーションを生成できるサービス「Lovable」では、新規プロジェクトの作成数が2025年に入って数カ月で1日10万件超へと伸び、その多くを、プロダクトマネジャーやマーケター、現場の業務担当者といった非エンジニアが生み出しています。

　同じく自然言語でアプリケーションを開発・公開できるプラットフォーム「Replit」も、ユーザー5000万人のうち75％は一行もコードを書いていないといいます。

　ビジネス・テクノロジー・クリエイティブを併せ持つBTC組織として大企業やスタートアップの新規事業開発の伴走支援を手掛けるRelicでも、社内外の事業検証のためのLP（ランディングページ）や業務ツール、デジタルプロダクトを非エンジニアの従業員が自ら内製するケースが増えています。

　エンジニアではない当事者（起業家・事業家、企画者、営業、バックオフィスなど）が、温めてきたアイデアをスピーディーに実現できるのはとても魅力的で、弊社のような新規事業開発をしている企業にとっては特に強力なツールとなり得ます。

　一方で、「専門家の目を通さないまま世に出るシステム」という新たな火種が生まれます。本稿は、Relicで発生したヒヤリハット事例と、それを機に整備した「非エンジニア向けシステム開発ガイドライン」の全体像、そして整備後の運用とレビューを支える「Claude Skills」の取り組みを紹介します。

危うく起きかけた「レビューなし」の野良システム公開

　あるシステムが、レビューを通さないまま公開直前まで進んでいたことがありました。イベント運営に使う進行管理ツールで、作ったのはエンジニアではない従業員です。既存ツールがサービス終了予定で、代替手段を急いで用意する必要に迫られていました。

　「AIを使えば短期間で動くものが作れる」――UI（ユーザーインタフェース）も立派な見栄えで、ログイン機能はもちろん一通りの機能を取りそろえた、一見するとしっかり動くシステムが出来上がっていました。

　問題はその中身でした。ファイルの保存先であるストレージの設定が不十分だったり、メール送信が不適切な方式で実装されていたりしました。一部のデータは正規化されておらず、継続利用が困難な状態でした。

　幸いにも偶然のやりとりからそのシステムの存在が判明し、すぐ公開前に差し止め、実害は出ていません。

　とはいえ、システムが世に公開されていたらさまざまなリスクが生じかねない状態でした。このヒヤリハットをきっかけに、社内で振り返りを実施しました。担当者にはもちろん悪意や意図的にレビューを省略した認識はなく、エンジニアが前提としているプラクティスや手続きを認識できていなかっただけでした。

　このようなヒヤリハットは特別な失敗ではなく、AI時代、誰にでも、どの企業でも起こりうる話として受け止める必要があると考えています。

質的に変わったAI時代の「野良システム」リスク　Relicはどう向き合ったか

　野良システム（シャドーIT）自体は新しい話ではありません。しかしAIによって、質的に変わりました。従来はシステムを作れる人はおおむねエンジニアに限られ、非エンジニアによる内製といっても「Excelマクロ」のように影響範囲が限定的でした。

　ところが2026年現在は、AIに指示出しさえすれば誰でもデータベース付き・ログイン機能付き・外部公開用ドメインありのシステムを短時間で作成できます。しかもAIが書いたコードの中身を、作者自身が読めない・説明できないまま本番環境に投入できるのです。

　CodeRabbitが470件のオープンソースのプルリクエスト（PR）を分析した調査（「State of the AI vs. Human Code Generation Report」）によれば、AIが関与したコードは人間のみが書いたコードに比べて検出された問題がおよそ1.7倍に上り、中でもセキュリティ上の問題は最大2.7倍、エラーハンドリングの不備も約2倍多いという結果が報告されています。

　AIは「動くコード」を素早く生み出す一方で、その裏側には人間が書いた場合より多くの欠陥が潜みやすいです。このような欠陥を放置した場合のリスクは、おおよそ次の4つに整理できます。

結果を放置した場合の4つのリスク

　そしてもう一つ見落とせないのが、こうした事故が一度起きると「非エンジニアのAI活用そのものを過度に規制する」方向へ揺り戻しが起きかねないことです。

　非エンジニアによるシステム開発に懐疑的な見方もある中で、今回のようなヒヤリハットが生じたことに対して、「ほら見たことか」という反応は少ないながらもあり、全面的な禁止を望む声もありました。

　「全面禁止」は非常にシンプルかつ強力な対策です。しかし、AIを存分に利活用できることは今後の競争力にもなるはずです。何よりも志の高い挑戦者が誰でも事業を創造できる「イノベーションの民主化」を推し進めるRelicとしては、アイデアを持つ者が実装まで遂行し、プロダクトを世に送り出すことができることは非常に意義深いものでした。

　そのように考え、「全面禁止」は避けて、リスクに応じた非エンジニア向けガイドラインを置く対策を進めることにしました。

非エンジニア向けシステム開発ガイドラインの全体像

　ガイドラインの対象は、エンジニア実務経験がない人がシステム（Webアプリ・API・bot／エージェント・スクリプトなど、作成手段を問わない）を作成・提供する場合です。判定はシンプルに「システム種別」と「提供先」の2つの軸に基づいています。専門家でない者が判断するわけですから、判定基準は簡潔で、誰でも分かるものでなければなりません。

ガイドラインの運用基準

システム種別

1. データベースやログイン機能を伴わないシステム
2. データベースやログイン機能を伴うシステム
3. 個人情報／機密情報や金銭・商取引を扱うシステム

提供先

• 個人のみ
• 社内グループ（5人以下）
• 全社
• クライアント・協業先
• 一般公開

　この交点でレベル0〜4が決まり、上位のレベルほど実施すべき事項や順守すべきものが増えます。「判断に迷ったら上位レベルに」「レベルが昇格したら再申告する」といった運用ルールも定めています。

• レベル0：会社管理のGitHubへ移管（資産の所在を確保）
• レベル1：公開前レビュー
• レベル2：実装前レビュー（設計・実現方法のレビュー）
• レベル3：運用へのエンジニア参画
• レベル4：開発へのエンジニア参画（フル関与）

　社内限定の検証用LPは、データベースやログイン機能を伴わないシステムで全社向けになるためレベル0、氏名を含む事前申込を受け付ける一般公開のティーザーサイトはデータベースやログイン機能を伴うシステムで一般公開になるためレベル2というような形で判定しています。

ガイドライン整備後、現場はどう動いているか

　ガイドラインは「読んで終わり」では意味がありません。Relicでは、判定から公開・運用までを一連のフローとして回しています。

1．資産を会社管理下に置く（GitHub移管）

　非エンジニアでも、まず会社のGitHubの組織にアカウントを招待し、リポジトリを作成します。作成したリポジトリは社内の管理台帳に、通知先のSlackチャンネルや責任者とともに登録。「Claude Code」や「Claude Cowork」での作業手順（コマンドラインツールの導入など）もドキュメント化し、エンジニアでなくても移管できるよう整えています。

2．脆弱性を放置しない（自動監視）

　各リポジトリでGitHubのDependabotを有効化し、社内のSlackチャンネルにDependabotを招待します。依存パッケージに脆弱（ぜいじゃく）性が見つかると、台帳で指定したチャンネルへ自動で通知が飛ぶ仕組みです。「誰も気付かないまま放置」を構造的に防ぎます。

3．レビュー依頼の窓口を一本化

　レベルに応じて、エンジニアチーム宛にSlackでレビューを依頼します。実装前（設計）レビューが必要な場合は、設計ドキュメントを載せたブランチを作ってPRを出し、その単位でレビューを受ける。公開前レビューでは、後述のAIが生成したセキュリティ指摘を基に修正し、再レビューを受けて完了とします。

4．役目を終えたら撤収

　検証を終えたシステムは、運用コストと脆弱性リスクを抱え続けないよう、データをエクスポートし、必要ファイルを保管したうえで運用を終了します。“作りっぱなし”にしない出口も運用に含めています。

　ここで現実的な壁になるのが、統制を強めるほどエンジニアのレビュー負荷が増えることです。これを抑える鍵がレビュー観点のSkill化です。Relicでは、リポジトリをClaudeに読み込ませ、セキュリティチェックの概要や修正手引きをマークダウンファイル（.md）として生成。依存パッケージのCVE（Common Vulnerabilities and Exposures：共通脆弱性識別子）解消、認証周りの実装是正、セキュリティヘッダ追加といった定型的な指摘をAIに洗い出させ、CLAUDE.mdをリポジトリ直下に置いてコンテキストも共有します。

　さらに、レビューの「型」そのものをClaude Skillsとして整備しています。「STRIDE脅威モデリング」（信頼境界をまたぐデータフロー単位でなりすまし・改ざん・情報漏えい・権限昇格などを洗い出し、残存リスクを高／中／低で評価）、「EARS+」（不変条件ファーストで仕様を構造化し設計・実装前レビューを効率化）、納品前クリーンアップ（クライアント納品前にAIエージェント関連ファイルや社内向けリンクを除去）などです。

　観点が標準化されることで一次レビューをAIが担い、人間のエンジニアは設計の妥当性やリスク受容の最終判断という、コンテキストが必要な部分に集中できます。

STRIDE脅威モデリング Skillのイメージ

AIエージェント時代に、エンジニアは何をする人になるのか

　非エンジニアがAIでプロダクトを作る流れは、もう止まりません。だとすれば、その流れにあらがうのではなく、エンジニアの役割も変えていく必要があります。

　鍵になるのは、機能要件と非機能要件の違いです。「ちゃんと動く」という機能要件は、AIでかなり実現しやすくなりました。動くかどうかは目で見て確かめられることが多いためです。難しいのはその先で、情報を漏らさないか、想定外の使われ方に耐えるか、運用が始まってからも安全に、長く、柔軟に変化に適応しながら使い続けられるか。こうした非機能要件は画面を眺めるだけでは確認できず、見極めには経験が欠かせません。今回のヒヤリハット事例で抜け落ちていたのも、まさにここでした。

　だからこそ、エンジニアの価値はこの確認しづらい領域を担える点に移っていきます。守るべき判断基準をSkillsや自動化に仕組みとして落とし込み、人の注意力は本当に危ういところへ集中させる。

　このような仕組み化にこだわるのは、Relicがイノベーションを起こす力は一部の専門家だけに宿るものではないと考えているためです。アイデアを持つ人間が自ら手を動かせる環境は、事業をスピーディーに、力強く前に進めます。

　本稿で紹介したヒヤリハットは、危うくインシデントになりかけた、未然に防げた一件でした。こうした事象をきっかけに過度な規制に走るのではなく、起きかけたことを仕組みに変えていけるかどうかが、AIを味方にできる組織と、振り回される組織の分かれ目になると考えています。

執筆者プロフィール

大庭 亮（おおば・りょう）

代表取締役CTO | Co-Founder

奈良先端科学技術大学院大学 情報科学研究科に在学中、産業技術総合研究所の技術研修生としてロボット工学の研究やロボット開発に従事した後、DeNAに入社。エンジニアとして主にEC事業領域の新規事業・新規サービスや大手小売業との協働事業であるECサイトやショッピングモールの開発・運用の責任者としてリード。その後、100万人以上のユーザーが利用するスマートフォンアプリの開発や新規事業の開発リーダーを経験。インフラを含め、全体のアーキテクチャの設計〜実装まで、幅広い領域を得意とする。2015年より複数のスタートアップのサービス開発や運用支援、及び技術アドバイザリーに従事した後、2016年、株式会社Relicに参画し、取締役CTOに就任。創業からRelicのテクノロジー領域を牽引しつつ、国内最大規模の新規事業に特化した開発組織を創り上げる。一般社団法人日本CTO協会正会員。多数の企業の技術アドバイザリーや講演・執筆なども手掛ける。

X：https://x.com/ryooob

note：https://note.com/ryooob