AI開発の構造的リスク

AI時代のアプリ開発を、
壊れない構造で。

AIがコードを書く時代、最大の問題は「誰が書くか」ではない。セキュリティと保守性を、どう構造的に担保するかだ。Guild 42は、Ruby on Rails + モジュラーモノリスでこの課題を解決する。

Warning

AI駆動開発の
2つの構造的リスク

AIがすべてのコードを書く今、開発者本人すらセキュリティを担保できない。しかも何を作ったか誰もわからなくなる。この2つは技術的課題ではなく、構造的課題だ。

01

セキュリティを担保できない

AIが生成したコードのセキュリティを、開発者が網羅的に検証することは事実上不可能。特にサードパーティパッケージの「つなぎ目」から脆弱性が発生する。

02

認知負債で制御不能になる

AIが書いたコードを次々と投入するうちに、何がどこにあるか誰も把握できなくなる。修正すれば別の箇所が壊れ、やがてアップデート不能に陥る。

Risk 01 — Security

なぜ技術スタックの選択が
セキュリティを決めるのか

同じAIが書いたコードでも、フレームワークの構造によってセキュリティレベルは根本的に異なる。

React / Next.js の構造
パッケージの「つなぎ目」問題
NextAuth
Prisma
Stripe
...
各自で統合するコード
ここに脆弱性が発生
  • セキュリティ対策は後付け
  • パッケージ間の歪みから穴が生まれる
  • 個別にアップデート管理が必要
  • 組み合わせの網羅的検証は不可能
Ruby on Rails の構造
フレームワーク統合型セキュリティ
Rails Framework — 統合スタック
CSRF保護
Strong Parameters
bcrypt暗号化
DB暗号化
Brakeman解析
セッション管理
外さない限り防御は常に有効
  • セキュリティはデフォルトで強制
  • つなぎ目がなく隙間が生まれない
  • フレームワーク一括アップデート
  • ジュニアが作っても構造的に安全
Risk 02 — Cognitive Debt

認知負債は
どのように蓄積するか

AIが大量のコードを生成し続けると、プロジェクトの複雑さは加速度的に増大する。これはエンジニアの能力の問題ではなく、AI開発の構造的帰結だ。

1
月1

初期開発 — まだ把握できている

3〜5機能程度。全体像を開発者が把握しており、AIへの指示も的確。見通しの良い状態。

開発者 → 的確な指示 → AI → 高品質なコード ┌─────┐ ┌─────┐ ┌─────┐ │機能A │ │機能B │ │機能C │ ← 見通し良好 └─────┘ └─────┘ └─────┘
2
月3

機能追加 — 依存関係が見えなくなる

10機能を超えると、機能間の暗黙の依存が増殖。「たぶんこの辺に書いてある…」「この関数、何のためだっけ?」が頻発。

機能A ←──依存──→ 機能D 機能B ←──依存──→ 機能E ──→ 機能G 機能C ←──依存──→ 機能F ↑ ↑ └──── ??? ────────┘ ← 追いきれない
3
月6

制御不能 — 修正の無限ループ

全てが絡み合い、一箇所の修正が予測不能な連鎖崩壊を引き起こす。AIへの指示も不正確になり、出力品質が急激に低下する。

「機能Eを修正して」 → AI修正 → 機能B,G,Hが壊れる 「B,G,Hを直して」 → AI修正 → 機能A,Dが壊れる 「A,Dを直して」 → AI修正 → 機能E,Fが壊れる ↑ ██ これ以上アップデートできない ██

認知負債の悪循環

AIが大量のコードを生成
開発者の理解が追いつかない
AIへの指示が不正確になる
AIの出力品質が低下する
さらに理解不能なコードが増える
プロジェクトは事実上「凍結」する — 事業継続のリスク
Solution

Rails × モジュラーモノリス
Engine構造で解決する

Rails Engineを使い、アプリケーションの各機能を独立したプラグイン(モジュール)として設計・管理する。認証は隔離され、ドメインは分割される。

Guild 42 モジュラーモノリス構造
基盤層
Core Engine
共通基盤・イベント管理
Auth Engine
認証・権限・セッション
シニアエンジニアのみ管理
↑ 依存方向(上位のみ参照可能)
共通層
CMS Engine
コンテンツ管理・管理画面
Agent Hub
AIエージェント管理
↑ 依存方向
業務層
予約管理
クライアント固有
在庫管理
クライアント固有
+ 追加
認証モジュールは完全隔離 — コードレベルで「壊せない」構造

セキュリティリスクの解決

認証・権限管理をAuth Engineとして完全隔離。ジュニアエンジニアやAIがこの領域に触れることを構造的に防ぐ。

  • 認証モジュールはシニアが専任管理
  • 名前空間分離で相互干渉を排除
  • 統一インターフェースで全モジュール制御
  • Railsのデフォルト防御が常に有効

認知負債の解決

ドメイン駆動開発により、クライアントの業務ドメインごとにEngineを分割。開発者の責任範囲を1プラグインに限定する。

  • 責任範囲が担当プラグイン1つに限定
  • 他のアプリケーション領域には触れない
  • コードレビュー対象が明確
  • AIへの指示コンテキストが小さく保てる
Additional Benefits

さらなる構造的メリット

セキュリティと保守性の担保に加え、開発効率とスピードを大幅に向上させる。

モジュールの継続的アップデート

Engineはgemとして独立。認証モジュールも各プラグインも持続的にアップデートし、全クライアントに展開可能。開発資産が蓄積されるほど速くなる。

Web = モバイル同時開発

RailsはPWAをデフォルトで同時実装。さらにHotwire NativeでiOS・Androidアプリとしてアプリストアに公開可能。別チーム・別コードベースが不要。

AIとの圧倒的な相性

Railsの「設定より規約」はLLMの予測精度を最大化する。フォルダ構造・命名規則が標準化されており、ハルシネーションによるバグを大幅に抑制。

Summary

Guild 42 の開発構造が
約束すること

AI駆動開発の課題 Guild 42 の解決策
セキュリティを担保できない Railsのデフォルトセキュリティ + Auth Engineの完全隔離
認知負債が蓄積する ドメイン駆動 × モジュラーモノリスによる責任範囲の限定
モバイル対応に別途コストがかかる PWA + Hotwire NativeによるWeb/モバイル同時開発
開発資産が使い捨てになる Engineの再利用・共有による開発資産の蓄積
AIの出力品質が安定しない Railsの「設定より規約」がAIの精度を最大化
Get Started

AIで開発する「構造」を、
一緒に設計しませんか?

AI駆動開発は避けられない。問題は、AIで開発する「構造」をどう設計するかだ。Guild 42は、AIの力を最大限に活用しながら、セキュリティと保守性を構造的に担保するアプリケーション開発を提供します。

ご相談は無料です。現在のシステム構成やご要件をお聞かせください。