小さな会社ほど、AI開発の「標準スタック」を決めた方がいい

こんにちは、大平です。

小さな会社ほど、案件やプロダクトごとに自由な技術選定をしたくなります。担当者の得意な技術を使った方が、最初のリリースだけは早く見えるからです。

しかし、AIを使って開発量を増やすなら、技術選定の自由度がそのまま事業上の速さになるとは限りません。認証、決済、メール、監視などを毎回選び直すと、設計、レビュー、障害対応、更新手順まで案件ごとに分かれます。

そこで先に決めたいのが、通常の案件で優先して使う標準スタックです。ここでいう標準は、適用範囲、構成、運用、セキュリティ要件、例外条件、更新責任までを含む「まず通る道」です。

毎回の技術選定は、開発以外の仕事も増やす

技術選定のコストは、比較検討の会議だけではありません。採用した技術ごとに、権限、監視、バックアップ、更新、障害対応、撤退方法も決める必要があります。

たとえば、三つの案件で担当者が別々の認証方式を選んだと仮定します。これは実在の顧客事例ではなく、標準化のコストを考えるための例です。三案件が動いた時点で、アカウント復旧、セッション失効、多要素認証、監査ログの手順も最大三系統になります。

標準があれば、毎回の問いは「どれを選ぶか」から「標準を外れるだけの制約があるか」へ変わります。

AIの出力を支えるのは、一貫性より明文化と検証

「AIは一貫した構成を好み、構成をそろえれば出力が安定する」と一般法則のようには断定できません。モデル、ツール、文脈、対象リポジトリによって結果は変わります。

実務上は、標準化によってAIコーディングエージェントが推測する範囲を狭める、と捉えるのが安全です。ディレクトリ構成、命名、認証の境界、テストコマンド、完了条件が明文化されていれば、人間もAIも同じ前提から作業を始められます。

標準には参照実装、開発規約、実行可能なテスト、レビュー項目を含め、AIの出力を検証するところまでを一つの仕組みにします。この考え方は、コード品質が事業競争力になる理由ともつながっています。

標準に含める十の領域

標準スタックは、言語とWebフレームワークを決めただけでは足りません。本番運用までに繰り返し判断する領域を並べると、少なくとも次の十項目があります。

フレームワーク：対応するアプリの種類、採用バージョン、ディレクトリ構成、API設計、データアクセス、入力検証、エラー処理、更新方針まで決めます。
認証と認可：認証基盤の責任範囲、SSOや多要素認証の要否、権限モデル、セッション失効、アカウント復旧、監査ログの残し方を決めます。
決済：カード情報を自社システムへ入れない構成を優先し、決済代行との責任分界、Webhookの署名検証、二重処理の防止、返金、照合を決めます。
メール：送信サービス、テンプレート管理、再送、バウンス処理、送信停止、SPF、DKIM、DMARC、開発環境からの誤送信防止を決めます。
ジョブ：非同期処理の基盤、再試行回数、重複実行への耐性、タイムアウト、失敗キュー、手動再実行、ジョブIDによる追跡を決めます。
ログ：構造化形式、時刻、環境名、リクエストID、利用者やテナントを識別する方法、機密情報の除外、保存期間、閲覧権限を決めます。
監視：死活、エラー率、遅延、キュー滞留、外部サービス失敗などの指標と、アラート条件、通知先、一次対応者、対応手順を決めます。
CI/CD：レビュー条件、テスト、静的解析、依存関係検査、成果物の作成、環境ごとの承認、ロールバック、デプロイ履歴を決めます。
IaC：ネットワーク、権限、秘密情報の参照、データベース、監視設定をコードで管理し、レビューと差分確認を通して反映する範囲を決めます。
テスト：単体、結合、E2E、セキュリティ、性能の役割を分け、変更の種類ごとに必須とする検証とテストデータの作り方を決めます。

製品名だけでなく、失敗時の戻し方、更新責任、残す証跡まで決めます。

認証と決済で独自実装を避ける範囲

認証では、パスワード保存、多要素認証、セッション管理、試行制限、アカウント復旧、メールアドレス変更、再認証、監査ログを一続きで設計します。 OWASP Authentication Cheat Sheetは、認証エラーの扱い、再認証、多要素認証、セッション管理などを別々の対策として整理しています。 OWASP Application Security Verification Standardも、認証、セッション管理、認可を分けて検証要件を示しています。

JWTを採用する場合も、「署名付きだから安全」で終わりません。 RFC 8725は、許可するアルゴリズムの検証、発行者と受信者の検証、異なる種類のJWTを取り違えないための明確なルールなどをBest Current Practiceとして示しています。標準には、鍵の保管と更新、有効期間、失効、Cookieの属性、ログへ残してよい情報まで含めます。

認証を外部サービスへ委ねる場合でも、認可まで自動的に解決するわけではありません。誰がどのテナントの何を操作できるかは、自社の業務ルールとして実装し、すべての入口で検証します。外部サービスを使う目的は、パスワード保管や多要素認証のような専門領域を、継続的に保守される基盤へ寄せることです。

決済では、カード情報が自社の画面、サーバ、ログ、分析基盤を通る範囲を小さくします。 PCI DSSは、アカウントデータを保護するための技術要件と運用要件を定めているため、取り扱う範囲が広いほど確認すべきシステムと運用も増えます。決済代行のホスト型画面やトークン化を使っても自社側の確認が不要になるとは限りませんが、カード情報そのものを自社で保持する設計より責任範囲を限定しやすくなります。

自社側の標準には、Webhookの署名検証、同じ通知が複数回来ても二重計上しない設計、金額と通貨の照合、返金権限、障害時の再処理を残します。

メール、ジョブ、ログ、監視は一つの運用として設計する

メール送信と非同期ジョブは、本番で失敗してから設計不足が見えやすい領域です。

メールの標準では、送信処理を業務トランザクションから分離し、再送してよい通知と一度だけ送る通知を区別します。ドメイン認証では、SPF（RFC 7208）、DKIM（RFC 6376）、DMARC（RFC 7489）の設定責任者と、DNS変更時の確認手順を決めます。機密情報を入れないこと、配信停止とバウンスを処理すること、開発環境では実在宛先へ送らないことも既定値にします。

ジョブには、同じ処理が複数回実行されても結果が壊れない性質を求めます。再試行の間隔と上限、外部サービスのタイムアウト、失敗キュー、手動再実行の権限を決め、業務IDとジョブIDをログで結びます。恒久的な入力不備は再試行で直らないため、止める条件と人へ通知する条件を分けます。

ログは保存するだけでは役に立ちません。 OWASP Logging Cheat Sheetが挙げる認証の成功と失敗、認可失敗、入力検証失敗、管理操作などを参考に、検知や調査に必要なイベントを選びます。一方で、パスワード、アクセストークン、カード情報、必要以上の個人情報は記録対象から外します。

監視では、メトリクスの一覧と同時に「誰が、どの状態になったら、何をするか」を決めます。ログ、メトリクス、トレースに共通のリクエストIDやジョブIDを持たせ、顧客からの問い合わせを一つの処理経路へたどれる状態を目標にします。

CI/CD、IaC、テストで再現可能な変更経路を作る

AI開発では、コードを書く速度より、変更が安全かを確かめて本番へ届ける速度が上限になりやすいです。 CI/CD、IaC、テストは、同じ変更を同じ条件で検証する経路として標準化します。

CIでは、フォーマット、静的解析、単体テスト、結合テスト、依存関係の検査を、ローカルと同じコマンドで実行できるようにします。 CDでは、誰がどの環境へ反映できるか、データベース変更をどの順序で行うか、失敗時にアプリとデータをどう戻すかを決めます。テスト基盤を含めて考える理由は、「動けばいい」運用は半年もたないで詳しく書いています。

IaCでは、再現性だけでなく、変更前に権限や公開範囲の差分をレビューできることを重視します。設定不備を減らす考え方は、セキュリティミスコンフィグの対策にもつながります。

依存関係とCI/CD自体も攻撃対象です。 NIST Secure Software Development Frameworkは、開発環境の保護、ソフトウェアの完全性確認、脆弱性への対応を安全な開発の実践として整理しています。標準には、依存関係の固定と更新、秘密情報の管理、CI権限の最小化、成果物の来歴、緊急更新の経路を含めます。 npmのサプライチェーン攻撃対策で扱っているように、アプリのコードが正しくても、取り込む部品が安全とは限りません。

製品名より先に決める選定基準

候補を同じ尺度で評価するため、製品比較の前に選定基準を決めます。

適合性：想定するサービス規模、可用性、データ保管場所、顧客契約、法令や業界要件を満たせるか。
保守性：更新頻度、サポート期間、脆弱性情報、移行ガイド、障害情報が継続的に提供されているか。
運用性：ログ、メトリクス、バックアップ、権限分離、監査証跡、障害時のデータ取り出しを実装できるか。
検証性：ローカルとCIで自動テストでき、失敗条件や外部連携の代替環境を用意できるか。
習得と採用：現在のメンバーが保守でき、採用時の要件を過度に狭めず、引き継ぎ資料を作れるか。
総コスト：利用料だけでなく、導入、教育、監視、更新、障害対応、監査、移行に使う人件費を含めて比較できるか。
可逆性：契約終了、値上げ、提供終了、要件変更が起きたときに、データと業務を移せるか。

すべての基準を最高水準で満たす製品はありません。一般的な業務Webアプリと、金融情報を扱う高可用性サービスを一つの標準へ押し込めると、前者には過剰で、後者には不足する可能性があります。

標準を一つに絞れない場合は、「通常構成」と「高いセキュリティや可用性が必要な構成」のように、用途を明確に分けた少数の標準を持ちます。選択肢を増やす場合も、誰がどの条件で使い分けるかを一文で判定できる状態にします。

例外承認は軽くし、判断記録を残す

標準スタックは、例外を禁止する規則ではありません。顧客指定、既存資産との接続、性能、データ保管場所、ライセンス、採用市場など、標準を外れる合理的な制約はあります。

一方で、「担当者が使いたい」「新しいから試したい」だけでは、会社が将来負担する運用コストを説明できません。例外の申請では、少なくとも次の情報を一枚に収めます。

標準では満たせない要件と、その根拠を記録します。
標準のまま解決する案を含め、比較した選択肢を書きます。
セキュリティ、運用、採用、費用、移行への影響を整理します。
例外技術の保守責任者と、問題が起きた場合の撤退条件を決めます。
承認者、承認日、見直しの契機を短い意思決定記録に残します。

承認者は、通常は技術責任者とします。個人情報、認証、決済、インフラ権限へ影響する場合だけ、セキュリティや運用の責任者を追加します。すべての例外を経営会議へ上げると判断が滞るため、費用上限、データ分類、顧客影響の基準を超えた案件だけを経営判断へ送ります。

例外が繰り返されるなら、現場が規則を守っていないと決めつける前に、標準が実態に合っているかを確認します。同じ理由の例外が複数出た時点で、標準へ新しい構成を加えるか、適用範囲を狭める候補にします。

標準の陳腐化を前提に更新する

標準は、決めた瞬間から保守対象になります。フレームワークのサポート終了、重大な脆弱性、料金体系の変更、サービス終了、法令や顧客要件の変更が起きれば、定例日を待たずに見直します。

定例の見直しでは、流行の技術を探すのではなく、現行標準の運用実績を確認します。例外申請の数、更新に要した作業、障害で困った点、テストできない領域、採用や教育の負担、解約や移行の難しさを材料にします。問題が観測されていない標準を、新しさだけで置き換える必要はありません。

変更を決めるときは、「今後の新規案件から切り替える」のか、「既存案件も移行する」のかを分けます。既存案件の一斉移行は、顧客価値を生まない大きな作業になり得るため、サポート終了やリスク低減などの根拠が必要です。旧標準の終了条件、移行手順、移行しない案件の保守期限を決め、標準の版と変更理由を記録します。

更新責任者を一人に集中させると、その人が不在のときに標準も止まります。領域ごとに主担当と確認者を置き、認証、決済、CI/CDなどの変更を同じ人だけで承認しない形にします。

標準を定着させる打ち手の順序

標準化は、全製品を先に選んでから現場へ配る仕事ではありません。既存の運用実績を起点に、代表的な案件で一度使い切り、不足を直してから適用範囲を広げます。

既存案件のフレームワーク、認証、決済、メール、ジョブ、ログ、監視、CI/CD、IaC、テストを棚卸しします。
案件数、運用実績、障害対応、保守できる人数を見て、標準化する対象と、当面対象外にする領域を決めます。
通常案件を代表する一つの構成を選び、選定理由、適用範囲、例外条件、責任者を短い文書にします。
小さな新規開発か既存サービスの限定機能で、開発、テスト、デプロイ、監視、障害対応まで通して使います。
途中で迷った判断と不足した手順を参照実装、テンプレート、CI、運用手順へ反映します。
例外承認と更新の流れを決め、次の案件から標準を既定の選択肢として運用します。

この順序なら、カレンダー上の区切りを守ることより、標準が本番運用まで機能したかを確認できます。完了条件は文書の公開ではなく、別の担当者が標準を使い、同じ検証経路でリリースできることです。

標準は、例外を速く判断するためにある

毎回の選定を減らす：通常案件では標準から始め、顧客固有の制約がある部分だけを判断します。
本番運用までを型にする：フレームワークだけでなく、認証、決済、メール、ジョブ、ログ、監視、CI/CD、IaC、テストを一続きで決めます。
安全性を製品任せにしない：外部サービスを使う領域でも、自社に残る認可、設定、監視、障害対応の責任を明文化します。
例外と更新を標準の一部にする：外れる条件、承認者、撤退条件、見直しの契機を残し、陳腐化に対応します。

小さな会社に必要なのは、すべての案件を同じ技術へ固定することではありません。限られた人数で支えられる通常の道を作り、その道を外れる投資だけを意識的に決めることです。