AI開発したアプリが“使えない”……根本にあるセキュリティ／ガバナンス問題を解消する「一体設計」手法

バイブコーディングの普及で、ソフトウェアの欠陥が2,500％増加する見立ても

　OutSystemsは2001年、ポルトガルのリスボンで創業。2025年時点で87を超える国・地域、3,000社を超える企業に導入が進み、90万人以上が参加するコミュニティを抱える。当初はアプリケーションを簡単に、品質良く作るローコードプラットフォームを提供していたが、近年はAIアプリケーションの開発から運用までを一気通貫で支える方向へ軸足を移している。

　講演冒頭、同社でエンタープライズ企業のAIアプリケーション開発やレガシーモダナイゼーションを支援している佐藤伸彦氏は、企業のAI導入における現状を説明。生成AIを使えばパワフルに、速く、安くアプリケーションを開発できる。だが、「いざ本番環境で使っていくときには、さまざまな課題が生じ、なかなかおいそれとリリースできないのが現状だ」と佐藤氏は切り出した。

　昨今、AI開発自体は急拡大している。その証左として、同氏は以下3つの数字を提示した。

　このようにソフトウェア開発にAIが積極的に組み込まれはじめている一方で、AIエージェントが制御を外れ、データベースを破壊した事例など、AIにおける負の側面もある。要件を伝えればそれらしいアプリケーションが高速で組み上がるバイブコーディングの広がりも、品質への懸念と表裏一体だ。実際、ITリーダーの67％がAIガバナンスに自信をもてておらず、バイブコーディングの普及にともなって2028年までにソフトウェアの欠陥が2,500％増加するとの予測もある。

AIガバナンスの不在が引き起こす3つのリスク

　なぜ、多くの企業がAIの本番運用に踏み切れないのか。佐藤氏はその構造をセキュリティ・コンプライアンス・ガバナンスの3つで整理した。

　第一が、セキュリティリスクだ。生成AIは自然言語の指示で挙動をコントロールできてしまうため、プロンプト攻撃を受けやすい。また、ロジックを一つひとつ定義して作るものでもないため、「意図しない形で個人情報が使われる」「機密データが外部に流出する」といったリスクも生じる。

　第二が、コンプライアンスリスク。個人情報保護法やEU一般データ保護規則（GDPR）への準拠、金融・医療といった業界特有の規制との整合性が問われる。実行結果をすべてログとして残せるのか、その結果をどう説明するのか。監査証跡の欠如と説明責任の不在も課題となる。

　第三が、ガバナンスリスクである。AIは使いはじめやすいがゆえに、安全対策が個人に委ねられがちだ。処理の判断プロセスも見えにくく、変更時に予期せぬ品質後退（リグレッション）が起こっても気づけない。佐藤氏は、「組織横断で統制していくことが非常に難しい」と指摘した。

　その結果、理想と現実のギャップが生まれる。マネジメント層は、AIを業務にどう生かすかという青写真を掲げる。ところが現場はツールをいかに安全に、ガバナンスを効かせながら使うかを検討するフェーズで足踏みし、PoCから先に進まない、スケールへの道筋が見えないといった状態に陥る。

　このギャップを埋めるためにOutSystemsが掲げるのが、ガバナンス・セキュリティ・プラットフォームの一体設計だ。組織ポリシーの一元管理と監査ログの自動記録を担うガバナンス。実行時のリアルタイム制御と、PII（個人を特定できる情報）の自動検知やマスクを担うセキュリティ。開発時の品質・回帰テストと実行トレーサビリティの可視化を担うプラットフォーム。「この3つが合わさって初めて、本番運用に耐えうるAIアプリケーションを作れる」という。

では、一体設計を実現するにはどんな仕組みが必要なのか？

　一体設計を具体化する仕組みとして、佐藤氏はAgent Evaluations（エージェント評価）とAgent Guardrails（エージェントガードレール）の2軸で解説した。これらの仕組みが、同社が提供するプラットフォームに採用されている。

　同じ問いに毎回同じ答えを返せるか。この再現性を担保するのがAgent Evaluationsという仕組みだ。決まりきったテストケースと期待される結果のセットを用意し、プロンプトやツールを変更するたびに同じベンチマークを再実行して、合格・不合格を可視化する。

　評価対象がAIエージェント部分だけでない点も押さえておきたい。佐藤氏は「サービスアクションという処理全体をまとめてテストすることによって、本番と同じ環境・経路で検証できる点が特徴だ」と続けた。

　評価の流れは5段階。入力と期待値をセットにしたデータセットをアップロードし、サービスアクションとして本番同等の経路で処理を実行する。その際、どのツールが呼び出され、どれだけトークンが使われ、どんな出力が返ったかを記録する。その結果をLLMジャッジが採点し、合格・不合格とスコア比較を含むレポートを出力する。採点基準は正確性、安全性、ガイドライン、ツール軌跡、クエリとの関連性の5項目だ。

　実際の例を通して考えてみよう。たとえば、メール対応のAIエージェントを作成するとする。まず、50件のメール文面と、このパターンならエスカレーション、このパターンなら返金処理といった期待値をセットで用意する。実行して47件が成功、3件が不合格なら、その3件はリグレッションしている。修正して再評価し、50件すべてが合格した段階でリリースするといった流れだ。

AIガードレールは、ステージごとに統制の強さを変える

　Agent Guardrailsは、本番に移行したアプリケーションが正しく制御されて動くことを保証する。エージェントとAIモデルの間に介在する安全・ガバナンス層として、ユーザー入力とモデル出力の双方を監視・強制する仕組みだ。主な機能は以下のとおり。

　ただし、エンドユーザーや業務の都合を考えずに、ただ制御を強力にするだけでは、開発現場に不都合が生じる場合がある。そこでOutSystemsは、ステージごとに制御の強さを変えられる設計を採っている。

　具体的には、開発ステージではプロンプト攻撃保護もPII露出フィルターも有害コンテンツフィルタリングも、ログを記録したうえで処理を継続する。検証ステージではプロンプト攻撃保護のみブロックし、PIIはマスクとログ記録、有害コンテンツはログ記録で継続。そして本番ステージでは、3種すべてをブロックし、エラーとして処理を止める。

　評価で品質を作り込み、ガードレールで安全を守る。佐藤氏は「この2つを取り揃えることで、本番運用レベルのエージェントが完成する」と強調した。

AIを組み込んだ開発モデルで工数が半減　北米最大級企業の変革

　続いて佐藤氏は、北米最大級の建材流通企業SRS Distributionの事例を紹介。同社は、OutSystemsの開発支援とAI関連ツールを採り入れた開発モデルへ移行している。

　変化は明確だった。従来は1プロジェクトあたり開発者3名にテックリード、BA、QAを加えた6名体制。それが1開発者＋共有テックリードの3名体制となり、6名分の成果を出せるようになった。2週間を要していたスプリント0の設計期間は、毎日のプロトタイピングスパイクとAI支援による即日検証へ。複雑度次第で1〜3ヵ月かかっていた開発期間は、4〜6週間の定常デリバリーエンジンへと短縮された。

　続いて、業界別のユースケースも見ていこう。たとえば金融業界では、Guardrailsの機能で全取引のPIIを自動マスクし、Evaluationsの機能で与信審査や不正検知の判定精度を継続監視できる。医療業界では、患者情報の流出をGuardrailsが事前に防ぎ、製造業では設備予知保全や品質検査のシステム変更にEvaluationsで回帰テストを走らせることが可能だ。

　では、これらの変革を実現するために、企業は何から着手すべきか。佐藤氏は「一足飛びに完全なガバナンスや安全性を担保しようとすると難しい」とし、段階的なロードマップを示しながら説明した。

　具体的には、1ヵ月でAIエージェントの棚卸しと利用実態の可視化から始め、Guardrailsをまず開発ステージで有効化する。3ヵ月以内には本番環境へGuardrailsをブロックモードで完全適用し、評価を継続的インテグレーション／継続的デリバリー（CI/CD）に組み込んで自動化する。そして、6ヵ月以内に全プロジェクトへ展開し、AIガバナンスKPIのモニタリングへ進むといった具合だ。

　まとめとして佐藤氏が挙げたポイントは4点。1点目が、ガードレールを後付けから組み込み式にすること。2点目が、評価を標準工程にすること。「感覚に頼ってしまうと、どうしても品質に対する取り組みが甘くなってしまう」と同氏は付け加える。再現性のあるテストデータと自動採点をCI/CDに組み込めば、客観的・定量的な品質保証が可能になるという。

　3点目が、プラットフォームによるガバナンスの民主化だ。「個々人のリテラシーに依存するのではなく、ガバナンスとしてプラットフォームを作ることで、AIの品質を担保していく」という考え方を示した。4点目は、開発体制のAIネイティブな再設計。人の配置を最適化し、柔軟で効率のよいチームを組めるかが競争優位を左右する。

　「AI時代の競争優位は、速さではなく、安全に速く動ける基盤をもつことにあります。AIは非常にパワフルで、開発そのものにもスピードを与えてくれるものですが、優位性を保つうえでは、速さを生かすために『どのように安全性を担保するのか』にこだわることが重要です」（佐藤氏）