副業・受託開発での活用ガイド
このガイドは、個人開発者や副業開発者が、ai-auditを企業案件の提案・開発・納品・保守へ組み込む方法を説明します。
営業先へそのまま見せる資料が必要な場合は、企業向け「セキュリティ・監査付き納品」の説明資料を使用してください。提案から納品先レビュー、第三者機関への引継ぎ、指摘対応後の再納品までを図解し、印刷・PDF保存にも対応しています。
1. 売るものは「安全宣言」ではなく「説明できる工程」
弱い提案は「AIで早く作れます」です。企業側が気にするのは、速さだけでなく次の点です。
- 要求漏れはないか
- 顧客情報や秘密情報を漏らさないか
- 外部送信、課金、削除を勝手に行わないか
- 問題が起きたときに原因を追えるか
- 担当者が変わっても保守できるか
- どこまで確認し、何が未確認か
ai-auditは、これらへの回答を成果物として残す工程です。
2. 提案書での説明例
短い説明
納品前に、要求事項とテスト・証拠を対応付けた技術監査を実施します。検査できなかった領域も未検証事項として開示し、対象ソースをハッシュで封印します。
セキュリティ担当向け
参照基準の名称・版・適用範囲を品質プロファイルに記録し、要求IDごとに試験方法、期待値、実測値、証拠、判定、残余リスクを提出します。AIレビューは第三者監査とは表現せず、必要に応じて外部診断へ引き継げる調書を作成します。
禁止する説明
- 「AI監査済みなので安全です」
- 「ISO準拠です」
- 「第三者監査済みです」
- 「脆弱性はありません」
- 「App Store審査に必ず通ります」
- 「本番利用を保証します」
3. 案件メニューの作り方
価格は地域、責任範囲、規模、必要な専門性で変わります。固定金額を先に決めず、対象範囲と成果物から見積もります。
| メニュー | 対象 | 成果物 | 対象外の例 |
|---|---|---|---|
| 事前ギャップ確認 | 提案・見積もり前 | 主要リスク、必要資料、未確定事項 | 合否判定、修正 |
| 納品前技術監査 | 小規模アプリ | 標準6成果物、修正提案 | 外部侵入診断、法的判断 |
| 修正・再検証 | 初回監査後 | 修正差分、再試験、指摘状態 | 承認外の機能追加 |
| 外部診断引継ぎ | 専門会社へ依頼前 | 未検証面台帳、調書、対象ハッシュ | 診断会社の業務そのもの |
| 保守再監査 | 更新・依存変更後 | 差分監査、更新版成果物 | 未変更領域の無期限保証 |
4. 見積もり前に確認すること
- コード量とリポジトリ数
- iOS、Android、Web、API、AI搭載等の対象種別
- 個人情報、決済、健康、位置情報等のデータ
- 外部サービスと本番接続の有無
- 仕様書、テスト、ビルド環境、実機の有無
- 修正を含むか、監査だけか
- 外部専門家・顧客セキュリティ担当とのレビュー有無
- 納品期限と再監査回数
- 公開可能な証拠と非公開にすべき証拠
不明点が多い案件は、最初から「合格報告書」を約束せず、事前ギャップ確認を別工程にします。
5. 契約・提案に含める境界
- 本作業は限定範囲の技術的検証である
- 認証、法的保証、第三者保証、契約検収を意味しない
- 検査対象のコミット、環境、データ、端末を特定する
- 未提供資料と未実施試験を未検証として扱う
- 本番・共有環境の能動試験は別承認とする
- 監査後の変更で結論が失効する
- 外部診断や専門家レビューが必要な条件を定義する
- 顧客情報と秘密情報の保管・廃棄方法を決める
6. 実務フロー
提案前
quality-requirements-template.mdで要求と禁止事項を確認- 対象種別とリスクを仮分類
- 必要資料と対象外を見積書へ記載
受注後
- 対象コミットと変更権限を固定
- 顧客データを使わず、架空データまたは匿名化データを準備
- 監査成果物の保存先と共有方法を合意
開発中
- 要求IDと受入テストを先に作る
- 外部副作用に人間の承認を置く
- 依存関係と生成記録を残す
納品前
- 読み取り専用監査
- 修正範囲の承認
- 修正と全体再検証
- 成果物スキャンと封印検証
- 顧客担当者による意味レビュー
納品時
- 経営要約だけでなく未検証面台帳も説明
- 結論の意味と限界を口頭で確認
- 再監査条件と保守窓口を提示
7. 納品時の説明順
- このシステムが何をするか
- 監査したコミットと範囲
- 採用した基準と版
- 重要指摘と修正状態
- 未検証事項と残余リスク
- 利用条件と禁止事項
- 変更時の再監査
- 外部専門家へ依頼すべき範囲
技術的な詳細から始めず、業務影響と利用条件を先に説明します。
8. 営業上のメリット
- 提案の差別化：開発速度ではなく品質工程を示せる
- 検収の摩擦低減：合否条件と証拠を事前に共有できる
- セキュリティ担当への引継ぎ：共通語彙と再実行手順がある
- 継続契約：更新時の差分監査を保守メニューにできる
- 信頼維持：不明事項を隠さず、誇張表現を避けられる
ただし、監査書類を付けるだけでは受注できません。実際の成果物、返信速度、要件理解、修正対応、継続支援が必要です。
9. ポートフォリオで公開する場合
- 架空プロジェクトまたは公開サンプルを使う
- 顧客名、担当者名、実データ、内部URL、端末パスを削除
- 脆弱性の再現手順は悪用可能性を確認
- サンプルであることを明記
- 「認証」「第三者保証」「完全」を使わない
- 実際に検証器とテストを通す
公開前プライバシーチェックを必ず実施してください。
10. 最初の利用者を得る方法
- 自分の公開サンプルを1つ監査する
- 「問題がゼロ」ではなく、見つかった問題と改善前後を示す
- READMEに5分で再現できるコマンドを置く
- iOS、Web、AI agent等、最初の対象を1つに絞って紹介する
- 利用者の質問をFAQとテストへ反映する
- 守秘義務に触れない一般化した知見だけを公開する
GitHubでの継続的な公開方法はGitHub成長ガイドを参照してください。