全工程を扱うガイド
規制のある企業でソフトウェアを開発する方法
人々がAIでプロトタイプを作れるようにします。本番データやAPIアクセスを与える前にセキュリティを検証し、企業の要件に従ってソフトウェアを提供・運用します。
短い答え
時間、ツールの選択肢、合成データ、有用なプロトタイプを保守されるサービスにする経路を提供します。本番APIへのアクセスや機密情報を与える前に、アプリケーション、プラットフォーム、データフローを検証します。社内プラットフォームやソフトウェアファクトリーを使い、安全なデリバリー、コンプライアンスの証拠、運用をつなげます。ライフサイクル全体で、責任者の説明責任を保ちます。
より多くの人がアイデアをソフトウェアにできるようにする
CTOは、組織の各部門の人に、AIでプロトタイプを作るよう働きかけることができます。財務チームは承認業務の問題を知っています。運用チームは繰り返す手作業を知っています。よりよいワークフローを示せるように、時間とツールを提供してください。
インストール、アカウント、許可する入力について明確なルールを設け、その範囲で異なるツールを使った探索を認めます。合成データセット、sandbox API、実務的な支援を提供します。本番システムに接続しなくても価値を示せる、明確な経路が必要です。
次の判断を定義します。アプリが機密情報、本番APIの権限、本番トラフィックを受け取る前に、何を検証する必要があるでしょうか。プロトタイプを作った人が理解できる経路にしてください。
プロトタイプに実際のアクセスが必要になると、何が変わるか
動作する機能は、サービスの一部です。組織は、誰が使えるか、データをどう扱うか、どのように復旧するかも説明する必要があります。これらの責任は、リリース後も続きます。
適用される要件は、サービス、業界、法域、契約、データによって異なります。担当する法務、プライバシー、セキュリティの専門家に、要件の特定を依頼してください。開発フレームワークやベンダーの認証だけでは、個別のサービスのコンプライアンスは成立しません。
以下の手順は、エンジニアリングのワークフローです。要件を判断と証拠に結び付けるために使ってください。NIST SSDFは、既存のSDLCを支援できるセキュア開発の実践を提供します。適用される義務を特定する作業に代わるものではありません。
1. 有用なプロトタイプをサービスの概要にまとめる
作成者に、問題を説明し、ワークフローを示し、ユーザーが学んだことを記録してもらいます。作成者には、業務分野の専門家として関与を続けてもらいます。技術評価と継続的な運用は、それらの責任を持つチームに割り当てます。
ユーザーのタスク、意図する成果、失敗した場合の影響を書きます。Product責任者、サービス責任者、セキュリティ窓口、残余リスクを受け入れられる人を指名します。誰がリリースを停止できるかを合意します。
例えば、顧客データのエクスポートには、ダウンロードボタン以上のものが必要です。誰が、どのレコードを、何の目的で、どの保持期間でエクスポートできるかを定義します。権限のないエクスポートを誰が調査するかを特定します。これは架空の例です。
残す証拠： サービスの概要、責任分担表、承認済みの受け入れ基準。
続いて、要件とトレーサビリティとサービスの責任を学んでください。
2. データやAPIへのアクセスを与える前に境界を検証する
機密情報、個人データ、認証情報、その他の制限対象を特定します。プロンプト、取得したコンテキスト、ログ、生成した出力がどこへ渡るかを図にします。選択したサービスの、保持、学習への利用、アクセス、処理地域に関する条件を確認します。
アイデアを試す間は、合成データか承認済みのテストデータを使います。プロトタイプの成功は、提供者が本番データを処理できる証拠ではありません。各提供者とデプロイ構成を確認します。
火曜日に作った架空の銀行ダッシュボードは、架空のトランザクションではうまく動くかもしれません。口座への読み取り専用アクセスでも、機密のレコードが露出するおそれがあります。支払い権限は、金銭的な影響を加える可能性があります。接続を有効にする前に、実際の範囲、認証情報の扱い、認可、障害時の振る舞いを検証します。銀行のプロトタイプの例をたどってください。
このレビューは、最初の機密入力や本番接続の前に行う必要があります。アプリをプロトタイプと呼んでも、すでに持っている権限は小さくなりません。
エージェントには、タスクに必要なツールと権限だけを与えます。リポジトリのファイルと取得した文書は、信頼できない入力として扱います。シークレットをプロンプトに入れないでください。
残す証拠： データフロー図、提供者の評価、権限ポリシー。
3. 本番に進むための支援体制のある経路を提供する
サービスを、組織のID、ネットワーク、ログ、デプロイの管理策の中に配置します。対応する環境とinfrastructure as codeを定義します。コンテナーとデータベースだけでは、運用環境全体は成立しません。
ポリシーで自社インフラが求められる場合は、自社のクラウドアカウントやネットワークへのデプロイを検証します。実行時の管理策と、開発時およびモデルへのデータフローを別々に確認します。自社アカウントでホストしても、コンプライアンスが成立したり、すべてのAIリクエストがそのアカウント内にとどまったりするわけではありません。
その経路には、社内プラットフォーム、ソフトウェアファクトリー、または両方を使えます。検証、デプロイ、脆弱性修正、運用について、それぞれが何を提供するかを定義します。プロトタイプは、その経路を使う前に、変更やコードの置き換えが必要になる場合があります。
許容できる停止時間とデータ損失、つまりRTOとRPOを合意します。その目標に照らして、可用性と復旧の仕組みを選びます。Multi-AZ、multi-region、バックアップは、異なる障害シナリオを解決します。依存先と復元したデータを含め、復旧プロセス全体をテストします。
残す証拠： アーキテクチャの意思決定記録、環境の定義、測定した復旧結果。
企業のインフラとRTOおよびRPOを学んでください。その後、復旧の演習を使います。
4. 検証できる要件に基づいて小さな変更を作る
開発者またはエージェントに、明確なタスクと受け入れ基準を渡します。要件を、実装、テスト、レビューに結び付けます。確認できる大きさに変更を保ちます。
テストの前に、セキュリティ要件を定義します。OWASP ASVSは、アプリケーションのセキュリティ検証の要件を提供します。関連する要件を選び、範囲を記録します。スキャナーの結果だけでは、アプリケーションの振る舞いは検証できません。
成功する操作だけでなく、拒否する操作もテストします。エクスポートの例では、権限のないユーザーが別の顧客のレコードを要求できないことを検証します。
残す証拠： 要件、変更のdiff、テスト結果、レビューの判断。
続いて、証拠としてのテストとAI生成コードのレビューを学んでください。
5. リリース判断を再現可能にする
レビュー済みのリビジョンから、識別可能な成果物をビルドします。対象環境、設定、必須チェック、残るリスク、リリースの判断を記録します。必要になる前に、ロールバックまたは復旧の方法をテストします。
人の許可が必要なタイミングを決めます。例外の責任者、理由、範囲、有効期限を残します。承認された例外を、ポリシーへの恒久的な変更とみなさないでください。
残す証拠： 成果物の識別情報、リリース記録、承認またはポリシーに基づく判断、ロールバック手順。
リリースの判断とコンプライアンスの証拠を読んでください。
6. デプロイ後もソフトウェアを保守する
依存物とデプロイ済みコンポーネントをスキャンし、新たに公表された脆弱性を探します。新しいコードのコミットがなくても、サービスが脆弱になる場合があります。各指摘に、担当者と是正の判断を割り当てます。
修正を検証し、デプロイし、稼働中のバージョンを確認します。受け入れたリスクを記録し、条件が変わったら再評価します。プロトタイプを完成品として扱うと、この継続的な作業が抜けることがよくあります。
残す証拠： コンポーネントの一覧、スキャン日、トリアージの判断、是正変更、デプロイの検証。
継続的な脆弱性管理のワークフローに従ってください。
7. 運用し、対応し、改善する
有用なサービスの成果、障害、セキュリティのシグナルを監視します。インシデントの役割、エスカレーション経路、SOCとSIRTの責任を合意します。それらの取り決めに沿って対応を訓練します。
NIST Cybersecurity Frameworkは、リスク管理を、governance、保護、検出、対応、復旧に結び付けます。運用モデルを定義するときは、このライフサイクルの視点を使います。
インシデントと繰り返す問題を、レビューされた変更につなげます。Self-healingは、検証と停止条件を備えた、許可された操作に限定します。自動再起動は、元の不具合が修正された証拠ではありません。
残す証拠： サービスの測定値、インシデント記録、復旧結果、検証された改善変更。
インシデント管理と範囲を限定したself-healingを学んでください。
8. どの責任を自社で担い、どの責任を外部サービスに委ねるか決める
社内プラットフォーム、コーディングアシスタント、AIソフトウェアファクトリーを、同じ要件で比較します。各タスクを誰が行い、どの証拠が利用でき、何が自社の責任に残るかを尋ねます。保守、復旧、連携、サービスからの移行の費用を含めます。
組織が本番への共通経路を維持しながら、人々は好みの探索用ツールを使い続けられます。どのコード、仕様、テストをツール間で移せるかを確認します。必要なインフラへのデプロイと、保守プロセス全体の実証を求めます。
Taigaは、governance情報と責任共有の説明を公開しています。一つのサプライヤーの資料として、自社の要件に照らして評価してください。この学習サイトの発行元はTaigaです。これらのリンクは、独立した第三者による推奨ではありません。
責任の比較から始めてください。その後、Taigaの学習パスで、これらの問いが具体的な製品ワークフローにどう関係するかを示します。
よくある質問
規制のある企業でもvibe codingを使えますか？
はい。組織の明確な境界内で、合成データ、sandbox API、ツールの選択肢を提供してください。アイデアを試し、有用なプロトタイプを、支援体制のあるデリバリー経路に持ち込めるようにします。正式な本番利用の前であっても、機密データや本番の権限を与える前に管理策を検証します。Vibe codingの用途と限界を参照してください。
AI生成コードには、異なる受け入れ基準が必要ですか？
必要な振る舞いとリスク管理策は、引き続き適用されます。AIによって、コンテキスト、データの扱い、権限、出力の信頼性に関する追加の問いが生じます。誰が、または何が作ったかに関係なく、実際の変更とその証拠をレビューしてください。
最初に何を準備すべきですか？
合成データを使う探索環境と、次の段階の連絡担当者を準備します。有用なプロトタイプについて、目的、予定するデータ、責任者、要件、復旧目標を文書化します。アクセスを広げる前に、ソフトウェアライフサイクルの演習で、不足する判断を特定してください。