開発委託契約要件書

HackⅡ — 知的財産・ロックイン防止・委託条件の完全定義

文書区分: 開発委託用 / 契約締結前に委託先と合意必須
作成: Regalis Japan Group株式会社
作成日: 2026-05-25 | バージョン: 1.0
機密区分: 社外秘（委託先開示用）

0. 本書の目的

本書は「開発委託によって生じる知的財産リスク・技術的ロックインリスク」を契約段階で排除し、 Regalis Japan Groupがシステムの永続的な所有者として事業を展開できることを保証するための要件書です。

基本方針:

Regalis Japan Group = システムの所有者・意思決定者
委託先エンジニアチーム = 道具を作る職人（サービス提供者）

この立場は契約書・技術仕様・インフラ設計の全レイヤーで一貫させること。

1. 知的財産権（IP）要件

1-1. 著作権の帰属（最重要）

要件: 本開発で生成される全成果物の著作権は、完成と同時にRegalis Japan Group株式会社に帰属する。

契約書への必須記載文（例）：

「本契約に基づき受託者が作成した成果物（ソースコード・設計書・
テストコード・ドキュメントを含む一切の著作物）に関する著作権
（著作権法第27条および第28条の権利を含む）は、各成果物の完成
時点において受託者から委託者（Regalis Japan Group株式会社）に
移転し、委託者に帰属するものとする。」

チェックリスト:

1-2. 特許・ノウハウの扱い

技術要素 権利帰属 理由
AICS™スコアリングアルゴリズム Regalis Japan Group 特許出願中技術。設計はRegalisが行った
HackⅡ製品設計思想 Regalis Japan Group 事業ノウハウ
委託先が持ち込む汎用ライブラリ 各OSS/ライブラリの規約に従う 既存の公開技術
委託先独自フレームワーク 禁止（下記参照） ロックインリスク

1-3. 納品物の定義（ソースコード一式）

実行ファイル・URLのみの納品は不可。以下を全て納品物として契約に明記すること：

納品物 形式 確認方法
フロントエンドソースコード GitHubリポジトリ（Regalis所有） mainブランチにPush
バックエンドソースコード 同上 同上
インフラ定義コード（Terraform等） 同上 同上
テストコード（ユニット・E2E） 同上 カバレッジレポートも含む
OpenAPI仕様書（YAML） 同上 Swagger UIで確認可能なこと
DB マイグレーションファイル 同上 全履歴を含む
環境構築手順書（README） Markdown 別エンジニアがゼロから構築できること
運用・保守ドキュメント Markdown 障害対応・デプロイ手順を含む

2. 技術的ロックイン防止要件

2-1. 技術スタックの制約（委託先への指定）

禁止事項:

禁止する技術 禁止理由 代替案
委託先独自フレームワーク 委託先以外のエンジニアが対応不可 React / Next.js / FastAPI 等の汎用技術
特定ベンダーのクローズドSaaS（ETLツール等） データ移行・解約困難 オープンソース相当品
マジックナンバー・ハードコードした設定値 変更・移植が困難 環境変数・設定ファイルで管理
DBスキーマなしの直接クエリ スキーマ不在で移行不可 マイグレーションファイル必須

承認済み技術スタック:

フロントエンド:  Next.js 15 / React 19 / TypeScript
バックエンドAPI: Node.js (Fastify) / TypeScript  ※ または Python (FastAPI)
データ処理:      Python 3.12+
エッジ処理:      Cloudflare Workers (TypeScript)
メインDB:        PostgreSQL 16
キャッシュ:      Redis 7
キュー:          SQS or Cloudflare Queue
ストレージ:      Cloudflare R2 (S3互換)
インフラ:        Terraform (AWS or Cloudflare)
CI/CD:           GitHub Actions
コンテナ:        Docker / Docker Compose

変更時のルール: 上記以外の技術を採用する場合は事前にRegalisの書面承認が必要。

2-2. クラウドインフラの所有権

必須要件: 全クラウドアカウントはRegalis Japan Group名義で開設する。

✅ 正しい構造:
  AWSアカウント: Regalis Japan Group 名義で開設
  → 委託先には「開発者ロール（MFA必須）」として一時的なアクセス権を付与
  → 契約終了時にIAMロールを削除するだけでアクセスを完全遮断できる

❌ 禁止する構造:
  AWSアカウント: 委託先名義で開設
  → システムが委託先のインフラ上で動いている
  → 契約終了時にシステムごと人質になるリスク
インフラリソース 名義・所有 委託先への権限
AWSアカウント Regalis Japan Group 開発者ロール（本番書き込み禁止）
Cloudflareアカウント Regalis Japan Group メンバー権限（管理者権限は付与しない）
GitHubリポジトリ Regalis Japan Group所有のOrg Maintainerロール（Adminは付与しない）
ドメイン（hackii.jp 等） Regalis Japan Group DNS変更権限のみ
SSL証明書 Let’s Encrypt / Cloudflare（自動更新） 管理不要

2-3. 秘密情報・認証情報の管理

情報種別 管理場所 委託先の取り扱い
AWSアクセスキー AWS Secrets Manager 委託先は開発用の個別IAMユーザーのみ
DBパスワード AWS Secrets Manager / GitHub Secrets 本番DBパスワードは委託先に渡さない
APIキー（外部サービス） GitHub Secrets（環境変数） ステージング用のみ提供
Stripe秘密鍵等 AWS Secrets Manager 同上

ルール: 本番環境の認証情報はRegalis管理者のみがアクセスできること。委託先はステージング環境の認証情報のみを保持する。

3. 契約形態の推奨

3-1. 推奨: ラボ型開発（専属チーム契約）

概要: 特定のエンジニアチームを期間契約で専属として確保する方式。

【ラボ型の構造】
Regalis Japan Group
  └── 月次契約でエンジニアチームをアサイン
       ├── エンジニアA（フロントエンド）: XX万円/月
       ├── エンジニアB（バックエンド）: XX万円/月
       └── エンジニアC（インフラ）: XX万円/月

メリット:

デメリット・対策:

3-2. 代替: 請負型（一括委託）を選ぶ場合の追加要件

請負型を選ぶ場合、以下を契約に追加する：

追加要件 内容
中間納品義務 2週間ごとにGitHubへのコミット履歴を確認できること
仕様変更時の工数明示 変更依頼から3営業日以内に影響工数を書面で提示
瑕疵担保期間 納品後1年間（民法の任意規定を超える保証）
ソースコード中間確認権 クライアントはいつでもリポジトリを確認できる

4. 開発・保守の移管要件

「いつでも別のエンジニアに保守を任せられる状態」を常に維持する。

4-1. ドキュメント要件（移管可能性の担保）

ドキュメント 内容 更新タイミング
ローカル環境構築手順 git clone から localhost で動作するまでのステップをゼロから記述 環境変更時
アーキテクチャ決定記録（ADR） なぜその技術・設計を選んだかの理由 重要決定時
API仕様書（OpenAPI） 全エンドポイントの入出力・エラーコード API変更時
DB設計書 テーブル定義・インデックス設計・マイグレーション手順 スキーマ変更時
デプロイ手順書 ステージング・本番へのデプロイ手順（GitHub Actionsの補足説明） デプロイ方法変更時
障害対応ランブック よくある障害パターンと対処法 障害発生時

検証方法: 四半期に1回、「このドキュメントだけを渡した別のエンジニアが環境構築できるか」を実際にテストする。

4-2. 移管リハーサル要件

5. 委託先評価チェックリスト（選定前の確認）

5-1. 必須確認事項（NOがあれば委託先として不適）

質問 期待する回答 確認
「著作権は完成時点で自社（Regalis）に帰属しますか？」 「はい、契約書に明記します」 □
「ソースコード・テストコード・ドキュメント一式を納品してもらえますか？」 「はい、全て納品します」 □
「独自フレームワークを使わず汎用技術スタックで開発してもらえますか？」 「はい、指定のスタックで開発します」 □
「クラウドはRegalis名義のアカウントを使い、貴社には一時的な権限のみを付与する形で進められますか？」 「はい、問題ありません」 □
「契約終了後も別のエンジニアが保守できるドキュメントを残してもらえますか？」 「はい、その前提で開発します」 □

5-2. 加点評価項目（YES が多いほど信頼度が高い）

質問 YES評価 確認
過去にAI/LLM関連システムの開発実績があるか？ ある → +2点 □
テスト駆動開発（TDD）の経験があるか？ ある → +1点 □
TypeScriptのstrict modeでの開発経験があるか？ ある → +1点 □
Cloudflare Workersの実装経験があるか？ ある → +2点 □
セキュリティ診断・ペネトレーションテストの経験があるか？ ある → +2点 □
長期保守を前提にしたラボ型契約の経験があるか？ ある → +1点 □

評価基準: 必須確認5項目が全YES かつ 加点が5点以上 → 委託先候補として適格

6. 機能要件の補足（エンジニア向けブラッシュアップ）

ビジネス要件（BRD.md）を技術的に具体化した追記。

6-1. Hackall（計測）— 必須機能の明確化

エンジニアが「これを作れば完成」と判断できる粒度で記述する。

MVP（最低限必要な機能）:

1. 計測タグ（hackall.min.js）
   - HTMLの<head>に1行埋め込むだけで動作
   - バンドルサイズ: 10KB以下（gzip後）
   - 必須計測: ページビュー / AI経由リファラー判定 / コンバージョン（フォーム送信）
   - オプション計測: スクロール深度 / CTAクリック
   - Cookie不使用でも動作すること（フィンガープリントベース）

2. ログ収集API（POST /events）
   - SLA: 99.9% / レスポンス p95 < 100ms
   - IPハッシュ化: 書き込み前にSHA-256変換。生IPはいかなる媒体にも保存しない
   - 不正リクエスト（site_idなし・不正形式）は400で即座に拒否

3. ダッシュボード
   MVP:
     - 過去7日間のAIクロール数（モデル別グラフ）
     - 今週クロールされたページ Top 10
     - AI経由ユーザーのコンバージョン数
   Phase 2追加:
     - 時系列タイムライン（時間/日/週の粒度切り替え）
     - ページ別ヒートマップ
     - AI流入からコンバージョンまでのファネル

スコープ外（MVP段階では作らない）:

6-2. Tsukull（制御）— 必須機能の明確化

1. ポリシー管理API
   - CRUD: GET/POST/PUT/DELETE /sites/{site_id}/policies
   - ポリシーはRedisにキャッシュ（TTL: 60秒）。DBは正規ストア
   - 変更から30秒以内にCloudflare Workersに反映されること

2. 識別テーブル（設定ファイルで管理）
   - crawler-ids.json として独立ファイルで管理
   - APIサーバー起動時・定期更新（1時間毎）でWorkersに配布
   - Regalisが新モデルを追加する際、コードデプロイ不要で反映できること

3. ダッシュボードUI
   - クイック設定（3タップ以内で完了）
   - モデル別テーブル（アクセス数・設定・変更ボタン）
   - 設定変更後に「この変更が30秒以内に反映されます」の確認表示

4. robots.txt 自動生成
   - ポリシー変更をトリガーにrobots.txtを再生成
   - GitHub Actions 経由でリポジトリにコミット or CDNに直接反映

6-3. Misell/AIパッチ（生成）— 必須機能の明確化

1. コンテンツ入力インターフェース
   MVP対応形式:
     - Markdownファイル（フロントマター付き）→ Git Webhook
     - 直接テキスト送信（POST /patches/generate のbodyにMarkdown）
   Phase 2追加:
     - WordPress REST API連携
     - HTML URL指定（ページをクロールしてパース）

2. AICS™スコアリングエンジン（コアロジック）
   - 入力: Markdownテキスト（フロントマター + 本文）
   - 出力: 6次元スコア（D1〜D6）+ グレード + ボトルネック次元
   - 処理時間: 1記事 < 3秒
   - アルゴリズムの詳細: docs/01_features/feature_04_ai_patch/data_format_spec.md 参照
   - 注意: このアルゴリズムはRegalis特許出願中技術。コードは秘密保持必須

3. ファイル生成
   MVP:
     - 個別記事パッチJSON（ai-patch/articles/{slug}-ai-patch.json）
     - llms.txt 更新（最新15記事リストを自動反映）
   Phase 2:
     - モデル別最適化ファイル（llms-chatgpt.txt 等）の自動生成

4. 配布パイプライン
   - 生成完了から15分以内にCDNに反映
   - GitHub Actions ワークフロー（YAML）をサンプルとして提供
   - IndexNow API自動送信（Bing即時通知）

6-4. Pay per Crawl（課金）— Phase 3の要件（参考）

Phase 3 開発時の注意事項:
  - 各AI事業者（OpenAI等）の利用規約を再確認してから実装
  - 課金ロジックは設定ファイルで管理（単価変更時にコード改修不要）
  - 冪等性テスト必須（同一request_idで絶対に二重課金しない）
  - 課金計算ロジックの単体テスト100%カバレッジを必須とする

Phase 3 MVP機能:
  - AIクローラーのAPIキー認証（Workersで処理）
  - 無料枠管理（Redis counter）
  - 月次課金集計（バッチ処理）
  - コンテンツ提供者向け収益レポート（ダッシュボード）

7. 委託先との合意が必要な未決定事項

以下はキックオフMTGで委託先と協議して決定すること：

項目 選択肢 決定者 状態
バックエンド言語 Node.js(Fastify) or Python(FastAPI) Regalis + 委託先合意 未決定
インフラプロバイダ AWS or Cloudflare（またはハイブリッド） Regalis 未決定
フロントエンドホスティング Vercel or Cloudflare Pages Regalis 未決定
ラボ型 or 請負型 ラボ型推奨 Regalis 未決定
月次予算 フェーズ別 Regalis 未決定
Phase 1 開始日 2026-07〜2026-08目標 Regalis 未決定

8. 本書の位置づけと他ドキュメントとの関係

docs/00_master/
├── BRD.md                  ← 「何を・なぜ作るか」（事業目的）
├── architecture.md         ← 「どう作るか」（技術設計）
├── stakeholders.md         ← 「誰のために作るか」（ユースケース）
├── non_functional_req.md   ← 「どの品質で作るか」（性能・セキュリティ）
├── legal_compliance.md     ← 「何を守りながら作るか」（法規制）
├── kickoff_checklist.md    ← 「どう合意するか」（契約・プロセス）
└── contract_requirements.md ← 「どんな権利構造で作るか」（本書）★
                              ↑
                    本書はすべてのドキュメントの「土台」
                    契約を正しく結ばないと、他の全要件が無意味になる

本書はRegalis Japan Group株式会社の機密資料です。
委託先との契約締結前に弁護士による最終確認を推奨します。
文書バージョン: 1.0 / 作成日: 2026-05-25