開発の民主化とセキュリティの境界線 ── 生成AI時代のサービス選定論

生成AIの爆発的な進化は、ソフトウェア開発の民主化をもたらしました。要件さえ定義できれば、自然言語で指示を出すだけで簡易的なアプリケーションが立ち上がる時代です。かつてExcelや手作業で管理していた限定的な業務が、現場の主導によって、より最適化されたアプリへと置き換わっていく。この「エンジニア不要論」すら内包する潮流は、一見すると業務効率化の理想郷のように思えます。

実際、私自身の周囲でも生成AIを用いて業務ツールを「自分で作れたよ」と見せてくれる友人が何人もいます。それ自体は素晴らしい試みです。しかし、技術者としてその裏側に一歩踏み込んでシステムを観察すると、深刻なリスクが浮き彫りになります。見えているのは美麗なフロントエンド（表層）だけであり、エンタープライズの運用に不可欠なバックエンド（堅牢性やセキュリティ）がすっぽり抜け落ちているケースが散見されるのです。

ここで私たちは、一度立ち止まって本質を問い直す必要があります。生成AIによって「作れる」ようになったのは事実として、それはシステムのライフサイクルのどこまでを担してくれるのか。汎用LLMが提供する「内製」には、技術的にどのような限界線が存在するのか。そして、その限界を見極めた上で、私たちが選ぶべき真の「AI Nativeなアーキテクチャ」とは何か。本稿の論点は、「作れるか、作れないか」という二元論ではありません。問題は、生成AIによって構築したシステムを、企業の基幹業務や重要な意思決定のプロセスに乗せ、数年以上にわたって安全かつ持続的に「運用し続けられるか」にあります。契約マネジメントという、企業の最高機密を預かるプロダクトを統括する立場から、この「作れる」の限界線について、運用・ドメイン知識（視点）・そしてセキュリティという3つの多角的な視点から紐解いてみたいと思います。

「動く」と「運用できる」のあいだにある深い谷

一定のプログラミング知識があれば、LLMの支援を受けてアプリを開発し、クラウド環境にデプロイすることは容易になりました。デモ画面は動き、ログインでき、データも保存される。一見、完成されたシステムに見えます。

しかし、それを企業のインフラとして継続的に「運用」するフェーズに入った瞬間、目に見えない膨大な労力とコスト、技術的負債が顕在化します。サーバーリソースの継続的な監視、トラフィックの変動に応じたスケーリング設定、エラー発生時のインシデントハンドリング、そして新機能の追加に伴う回帰テスト（デグレードの防止）。これらは、自律的な運用知見を持つ専門家が介在し続けて初めて成り立つエコシステムです。

運用だけではありません。作った本人の異動や退職でメンテナンスが止まるリスク、利用者が増えたときのオンボーディング体制、問い合わせ対応。こうした「作った後にずっと続くこと」を勘定に入れると、目先の「できそうだ」という直感よりも、確実にプロ（外部の専門サービス）に任せるほうが、結果的に低コストになる場面は少なくありません。

この「初日は安く見える」という罠を、CLM（契約ライフサイクル管理）大手の米Ironcladは、システムの内製を検討する企業に向けて明確に言語化しています。

“初日には自前で作るほうが買うより安く見える、エンジニアがAIで開発を速められればなおさらだ、と。しかし、後からやってくる隠れたコスト——保守費用、コンプライアンス認証、連携の維持——があり、数年経つと自前のシステムのほうが既製品より高くつくことすらある。”
Building vs. Buying CLM in the AI Era

いま自社のデータはどれだけ構造化されているか。それをモデルが使える状態にするには、実際に何が必要か。そして継続的な保守のスポンサー（責任者）は誰で、その関与は組織再編を生き延びるほど強固なものか。

この最後の問いは、内製の最大の弱点を突いています。作った人間がいなくなれば、その仕組みごと宙に浮いてしまうのです。

「足元の課題」を解くことと、「本当の最適化」は違う

もう一つ、見落とされがちな評価軸があります。サービスを設計するときの「視点」です。自分で作るとき、人は往々にして「足元の課題」を解こうとします。日々の運用で感じているペイン——この入力が面倒、この転記が二度手間——を取り除く。それ自体は正しいことです。ですが、それはいま感じている痛みの解消であって、業務そのものの最適化ではありません。

サービスを提供する側は、視点の置き方が違います。数多くの顧客の状況を日々モニタリングし、最低でも数年単位の時間をかけて、「本当の意味での効率化とは何か」を問い続けています。一人のユーザーには見えない、業界全体の構造的な課題やベストプラクティスが、その蓄積の中に織り込まれていくのです。

リーガルAIのHarveyが「ChatGPTの皮かぶせではないか」という批判に返している論も、本質はここにあります。

Harveyの強みは、AIが自社の成果物・先例・テンプレートを参照し、汎用アシスタントを「自社の実務を知っているAI」へと変える点にあります。一方、汎用のChatGPTは毎回ゼロから会話を始めます。興味深いのは、Harvey自身が汎用AIの有用性を否定していないことです。日常的なリーガルAIタスクの大半は汎用ツールでもこなせると認めたうえで、専用基盤が上乗せで提供するのは、ドメインに特化した深い知見と、ワークフロー全体の自動化、そしてエンタープライズのセキュリティだと位置づけています。

汎用LLMで作れるのは「その場で動くもの」です。ですが、業務の本当の最適化は、ドメインへの長期的な理解の上にしか積み上がりません。

私たちHubbleが契約という領域で目指してきたのも、まさにこれです。日々の契約プロセス——作成・編集・承認・締結・更新——を通じて、「誰が・いつ・どんな理由で」その判断をしたかを自然に構造化して蓄積していく。現場の入力負荷を増やさず、いつものWordで作業するだけで、裏側で組織の意思決定の足跡が資産に変わっていきます。この設計思想は、一度の開発では決して再現できません。

AI時代だからこそ、セキュリティの重みが変わった

そして、最も見過ごせないのがセキュリティの障壁です。「作れる」時代の裏側で、2026年に入ってから、AIで作られたサービスの情報漏洩が立て続けに発生しています。象徴的なのが、新興サービスである『Moltbook』の事例です。創業者が「自分は一行もコードを書いていない」と公言したこのサービスは、ローンチからわずか3日で、150万件の認証トークンと3万5千件のメールアドレスがインターネット上に完全露出していることが発覚しました。原因は、決して高度なハッキングなどではありません。AIが開発中に作ったデータベース設定が、本番でも公開状態のまま放置され、誰もインフラ部分を見直さずにデプロイした——ただそれだけでした。

これは特殊な事故ではなく、構造的なパターンです。AIエージェントは「アプリが動くこと」を最優先に最適化しますが、「アプリが安全であること」は最適化してくれないからです。

研究データもこの危うさを客観的に裏づけています。複数の調査によれば、AIが生成したコードの40〜62%が何らかのセキュリティ脆弱性を含んでいます。2026年第1四半期に200以上のAI製アプリを調べた評価では、実におよそ91.5%がAIのハルシネーションに起因する脆弱性を少なくとも一つ抱えており、60%以上が公開リポジトリにAPIキーやデータベースの認証情報を露出させていました。

Vibe Coding Security Risks: Enterprise Guide 2026
https://securetom.com/blog/vibe-coding-security-risks-enterprise

「GitHubから環境変数が抜かれてサービスごと乗っ取られる」というリスクも、まさに現実のものになっています。AIが書いたコードは人間が書いたコードの約2倍の頻度で機密情報を露出させており、2025年には公開GitHub上で2,865万件ものハードコードされた秘密情報が検出されました。さらに2026年4月には、開発支援ツール経由で大手プラットフォームが侵入された事例や、Claude・Cursor・Codexといったツールの認証情報を狙い撃ちにするサプライチェーン攻撃まで報告されています。AIツールそのものが、いまや新しい攻撃対象になっているのです。

私たちが扱っているのは、顧客にとってかけがえのない契約データです。だからこそ、セキュリティには一層敏感であり、必要なことを徹底してやり抜く責任があると考えています。「開発できること」と「その安全性の責任を負えること」は、明確に分けて考えなければなりません。これは経営として、避けて通れない論点です。

「作る」から「託す」へ——AI Nativeを導入するという選定

ここまで運用・視点・セキュリティの3つの角度から見てきましたが、共通しているのは一つの事実です。汎用LLMで「作れる」領域というのは、サービスのライフサイクルにおける最初の入り口に過ぎない、ということです。

本当に企業へ価値をもたらすのは、その後の背景に続く継続的なインフラの運用維持、長期的なドメインへの深い理解、そして責任を持って顧客のアセットを守り抜く体制のほうにあります。これこそが、「作れる」ことの技術的な限界線です。

Ironcladのある顧客が語った言葉が、これを的確に言い当てています。

“生成AIは毎回、何かを生成してくれる。しかし、それが常に同じ品質であるという信頼の保証はない。私が欲しいのは一貫性と信頼性だ。AIはあくまでボーナスであって、土台となる構造化されたワークフローこそが本体なのだ。”
A New Era of Contract Intelligence

AI Nativeな外部サービスを導入するという意思決定は、単に便利なソフトウェアを購入することと同義ではありません。「構築した後にずっと続く、見えない膨大な仕事」を、それを専門とするプロに託すという、経営合理性に基づいた選択です。

目先の「できそうだ」の先にある景色まで見据えたとき、その判断こそが、結果的にもっとも合理的な費用対効果につながっていきます。

私たちHubbleは、契約という領域で、その「ずっと続く仕事」を引き受ける覚悟を持ち、日々プロダクトのアーキテクチャを磨き続けています。今回は「作る」という観点から論考をお届けしましたが、Hubbleの導入メリットやサービスに対する思想については、弊社メンバーでも様々な視点から発信しておりますので、ぜひご一読いただけますと幸いです。