# 法務案件チェックポイント
> 「作る機能」「売る商材」から疑うべき法令を逆引きする、エンジニアのための法務・経理リファレンス
# 法務案件チェックポイント
Source: https://h-kono-it.github.io/legal-check-helper
「これ、法務案件では？」に気づくための逆引きリファレンスです。
条文から学ぶのではなく、**いま作ろうとしている機能**や**売ろうとしている商材**を起点に、疑うべき法令と確認事項を引けます。エンジニアに求められるのは法律の専門知識ではなく、「これは法務に相談すべき案件だ」と気づいてエスカレーションできることです。
ポイント発行、DM機能、サブスクの解約UI……実装しようとしている機能から、疑うべき法令へ。
酒類、中古品、チケット……売ろうとしている商材から、必要な許認可・法令へ。
企画 → 設計 → 実装 → リリース → 運用。いまいる工程で確認すべき項目の一覧。
アラートに気づいたら。専門家への相談を1回で済ませるための準備リスト。
## 使い方
1. 新しい機能の仕様が出たら、まず[機能から引く](/features)で該当する機能を探す
2. ECや予約サービスで何かを「売る」なら、[商材から引く](/products)も確認する
3. 該当したら、その機能ページの「なにが問題になるか」を読み、確認事項をチェックする
4. 開発フェーズの節目では[フェーズ別チェックリスト](/checklist)で漏れを確認する
5. アラートに気づいたら、[法務相談の準備リスト](/checklist/consulting)を使って専門家に相談する
> **利用にあたって** — 本サイトの目的は「アラート検知」であり、法務的な判断を代替するものではありません。法律の解釈には揺らぎがあり、実際の判断は必ず専門家に相談してください。詳しくは[免責事項](/disclaimer)をお読みください。
{/*
このページ内の拡張子付きパスへのリンク（llms.txt / llms-full.txt / index.md /
changelog/rss.xml）だけ、他と違って base（/legal-check-helper）を直接書いている。
Blume は拡張子付きのパスを「public/ 配下の静的アセット」とみなして base を
付けない仕様のため（markdown/base-links.ts の ASSET_PATH）。これらは public/ の
ファイルではなく base 配下に生成されるので、書かないと 404 になる。
deployment.base を変えるときはここも直すこと。
*/}
## AI・エージェントから使う
このサイトは、AIアシスタントやコーディングエージェントから読ませることを想定した形式でも配信しています。仕様書をレビューさせるとき、リポジトリのコンテキストに一緒に渡しておくといった使い方ができます。
- **[llms.txt](/legal-check-helper/llms.txt)** — サイト全体の目次。どのページに何があるかの一覧
- **[llms-full.txt](/legal-check-helper/llms-full.txt)** — 全ページの本文を1ファイルにまとめたもの（約140KB）
- **各ページの Markdown** — 個別ページは URL の末尾に `.md` を付けると元テキストが得られます（`/features/money/point-issuance` なら `/features/money/point-issuance.md`）。このトップページだけは [/index.md](/legal-check-helper/index.md) です。ページ右上の「Copy as Markdown」からも同じものをコピーできます
ただし、AIに読ませた結果もまた「アラート検知」の域を出ません。上の免責事項がそのまま当てはまります。
## このサイトについて
このサイトは、管理者が執筆した技術同人誌『Webエンジニアのための法務確認ガイド 〜「これ、法務案件では？」とアラートを出せるようになる本〜』の**エッセンシャル版**という立ち位置です。現場で引くのに必要な要点だけを抜き出し、逆引きしやすい形に組み直しています。
そのぶん、なぜその法律がそうなっているのか、条文の背景にある考え方、実際の事例といった読み物としての厚みは書籍にあります。腰を据えて理解したいときは、ぜひこちらもお手にとってみてください。
[書籍頒布ページ](https://yomaigotolab.booth.pm/items/8344898)
サイトの更新は[更新履歴](/changelog)に記録しています（[RSS](/legal-check-helper/changelog/rss.xml)）。各ページの末尾には、そのページの最終更新日を表示しています。
---
# 「開発費・資産系」カテゴリを新設（資産計上・減損・除却）
Source: https://h-kono-it.github.io/legal-check-helper/changelog/assets-category
機能から引くに6つ目のカテゴリ「[開発費・資産系](/features/assets)」を追加しました。書籍にはない、サイト独自の追加コンテンツです。
他のカテゴリと違い、トリガーは「実装する機能」ではなく「開発プロジェクトそのもの」。判定は経理の仕事、作る側の仕事は現場でしか検知できない兆候を伝えること、という整理で、各ページに経理への連絡テンプレを置いています。
- [自社開発ソフトの資産計上](/features/assets/capitalization)：着手前の「この開発、資産計上前提？」。工数集計の開始時点と、キャッチアップ・調査など資産に乗せない作業の区分
- [資産計上した開発の減損](/features/assets/impairment)：凍結後の大幅な方針転換・作り直し・計画未達は減損の兆候になりうる。フェーズ分割開発で後続フェーズが凍結された場合、先行フェーズの資産（ソフトウェア仮勘定含む）の前提が崩れる点も注記
- [使わなくなったソフトの除却](/features/assets/retirement)：廃止・リプレースの「日付のある記録」を残して帳簿から落とす
- [フェーズ1：企画・要件定義](/checklist/phase-1-planning)と[フェーズ5：運用](/checklist/phase-5-operation)のチェックリストにも対応する項目を追加
---
# 景品表示法の記載を追加（ステマ規制・二重価格表示）
Source: https://h-kono-it.github.io/legal-check-helper/changelog/keihyoho-stealth-marketing-double-price
コンテンツ・画面系の2ページに、景品表示法の確認事項を追加しました。
- [UGCの広告・プロモーション利用](/features/content/ugc-promotion)：ステマ規制（2023年10月施行）。対価を渡した投稿の「広告」「PR」表記、特典付きレビューキャンペーン、埋め込みUIでPR表記が見切れる問題など
- [通販・EC購入フローの実装](/features/content/ec-purchase-flow)：二重価格表示。比較対照価格の販売実績（8週間ルール）、「通常価格」を自由入力にする設計の危険、カウントダウンタイマーの偽装リスクなど
- [懸賞・ガチャ・キャンペーン](/products/prize-gacha)との相互リンク、[フェーズ2：設計時](/checklist/phase-2-design)のUI設計チェック項目も更新
---
# 各ページにシェアメニューを追加
Source: https://h-kono-it.github.io/legal-check-helper/changelog/share-menu
各ページにシェアメニューを追加しました。タイトル直上（「このページだ」と確認してすぐ共有する逆引き動線用）と、本文末尾（読了後用）の2箇所にあります。
- リンクのコピー／タイトル付きコピー（Slack などにそのまま貼る用）
- X でシェア／はてなブックマークに追加
「これ、うちのチームでも確認したほうがよさそう」と思ったページを、そのまま共有できます。
---
# サイト公開
Source: https://h-kono-it.github.io/legal-check-helper/changelog/site-launch
「法務案件チェックポイント」を公開しました。
- [機能から引く](/features)：22機能を5カテゴリ（お金・決済／通信・プライバシー／人・組織／コンテンツ・画面／DB・経理）に整理
- [商材から引く](/products)：14商材の許認可・法令早見
- [フェーズ別チェックリスト](/checklist)：企画〜運用の5フェーズ + 法務相談の準備リスト
---
# フェーズ別チェックリスト
Source: https://h-kono-it.github.io/legal-check-helper/checklist
「今自分がどの段階にいるか」に合わせてチェックリストを参照してください。**チェックが入らない項目は、法務・経理に確認すべきサインです。**
機能単位の逆引きは[機能タイプ別クイックリファレンス](/features)を、商材単位の確認は[販売商材別・法令早見表](/products)をあわせて使ってください。
## フェーズ一覧
1. [フェーズ1：機能企画・要件定義時](/checklist/phase-1-planning)
2. [フェーズ2：設計時（DB・API・UI設計）](/checklist/phase-2-design)
3. [フェーズ3：実装時](/checklist/phase-3-implementation)
4. [フェーズ4：リリース前](/checklist/phase-4-release)
5. [フェーズ5：運用継続中（定期確認）](/checklist/phase-5-operation)
アラートに気づいたら → [法務に相談するときの準備リスト](/checklist/consulting)
## 担当者の目安
| チェック範囲 | 主な担当 |
|---|---|
| フェーズ1（機能企画）の項目 | PM・リードエンジニア |
| フェーズ2〜3の「DB設計」 | バックエンドエンジニア |
| フェーズ2〜3の「UI設計」 | フロントエンドエンジニア |
| 「発注・契約管理」 | PMまたはチームリーダー |
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# 法務に相談するときの準備リスト
Source: https://h-kono-it.github.io/legal-check-helper/checklist/consulting
法務担当者や弁護士に相談するとき、「なんかリスクがありそうです」という相談は、専門家の時間を無駄にします。次の情報を事前にまとめることで、1回の相談で必要な回答を得られる確率が上がります。
## 相談前に整理する情報
### 機能の概要（エンジニア目線で）
- 何を実装しようとしているか（機能の概要）
- お金の動きはあるか（あれば金額・流れ・換金性の有無）
- ユーザーデータをどこに送るか（外部サービス連携の有無）
- 誰が誰に指示を出す構造か（発注・受託の関係）
### 現在の状況
- 実装の進捗（設計段階か、実装済みか）
- リリース予定日はいつか
- 類似する機能が既にサービス内に存在するか
### 疑っている法令・リスク
[機能タイプ別クイックリファレンス](/features)や[販売商材別・法令早見表](/products)で「このアラートが関係しそう」と思った内容を箇条書きにしておきます。「わからないので教えてほしい」ではなく「〇〇法の当該条文に該当しないか確認したい」と伝えると、回答の精度が上がります。
> **コラム：エンジニアの言葉を法務の言葉に翻訳する**
>
> 法務に相談する際は、実装の詳細（「DBの正規化が〜」「トランザクション処理が〜」）ではなく、「目的と影響」にフォーカスした伝え方を心がけてください。たとえば「このポイントはユーザーが先払いして後で使う仕組みで、残高が1,000万円を超えそうです」のように、法的判断に必要な事実関係を整理して伝えると会話がスムーズになります。
## 相談で確認すべきこと
- [ ] 実装しようとしている機能は対象の法令に該当するか
- [ ] 該当する場合、届出・登録・承認など行政手続きが必要か。必要な場合のスケジュールはどれくらいか
- [ ] 利用規約・プライバシーポリシーへの追記が必要か。必要な場合の記載内容の確認
- [ ] 「対応不要」と判断した場合、その根拠を確認しておく（後で判断が変わったときに備えて記録に残す）
---
法律は「知らなかった」では免責されません。しかし、「全部知っていないといけない」わけでもありません。**「これは法務案件では？」と気づいてエスカレーションできること**が、エンジニアに求められる現実的なゴールです。
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# フェーズ1：機能企画・要件定義時
Source: https://h-kono-it.github.io/legal-check-helper/checklist/phase-1-planning
新しい機能の仕様が出た段階で確認します。この段階でアラートを出せれば、後工程での手戻りを最小化できます。
## お金・決済系
- [ ] 「ポイント」の性質を確認した（付与型の購入特典か、先払いのチャージ型か）
- [ ] ポイントの有効期限を6ヶ月以内にするか6ヶ月超にするかを明示した（6ヶ月超は資金決済法の対象）
- [ ] ユーザー間の送金・換金機能の有無を確認した（あれば資金移動業のアラートを出した）
- [ ] 他社加盟店でのポイント利用を計画している場合、事前に法務へ確認した（登録が必要）
- [ ] チャージ型残高の現金払い戻しフローを設計していないか確認した（原則禁止）
関連：[ポイント発行](/features/money/point-issuance)・[チャージ型電子マネー](/features/money/prepaid-emoney)・[送金・投げ銭](/features/money/p2p-transfer)・[他社で使えるポイント](/features/money/third-party-points)・[残高の返金](/features/money/point-refund)
## 通信・プライバシー系
- [ ] DM・チャット機能を追加する場合、主機能か付随機能かの判断を法務に相談した
- [ ] 外部サービス（分析ツール・CRM・メール配信）へのデータ連携方針を確認した
- [ ] 退会機能の設計方針（消すデータ・残すデータ）を確認した
関連：[DM・チャット](/features/privacy/dm-chat)・[外部データ連携](/features/privacy/external-data-sync)・[退会機能](/features/privacy/account-deletion)
## 人・組織系
- [ ] SES・業務委託エンジニアが参画する場合、指揮命令の経路（発注者→受託会社の責任者→エンジニア）を設計した
- [ ] フリーランス・外注先への発注フローで、書面交付のタイミングを確認した（作業開始前が必須。2024年11月施行のフリーランス保護新法により、個人への発注も対象）
関連：[SES・業務委託への指示](/features/people/ses-instruction)・[フリーランス・外注への発注](/features/people/freelance-order)
## 開発費・資産系
- [ ] 自社サービスの新規開発・大規模改修の場合、資産計上の対象になるかを着手前に経理へ確認した
- [ ] 資産計上する場合、工数集計の開始時点と、集計から除外する作業（調査・PoC・キャッチアップ・保守）の区分を確認した
関連：[自社開発ソフトの資産計上](/features/assets/capitalization)
次のフェーズ → [フェーズ2：設計時](/checklist/phase-2-design)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# フェーズ2：設計時（DB・API・UI設計）
Source: https://h-kono-it.github.io/legal-check-helper/checklist/phase-2-design
実装前の段階で、設計レベルでの法的・経理的な要件を確認します。
## DB設計
- [ ] ポイント・電子マネーの残高変化をイベント履歴テーブルで記録する設計になっている
- [ ] `event_type`の分類が経理処理に対応している（`charge` / `earn` / `use` / `refund` / `expire`）
- [ ] 履歴テーブルはAppend Only（追記専用）で運用する設計になっている（UPDATE・DELETE禁止）
- [ ] `balance_after`（事後残高）カラムを持ち、整合性チェックバッチを設計している
- [ ] 複合払いの返金処理に冪等性キー（`idempotency_key`）を設計している
- [ ] `idempotency_key`カラムにUNIQUE制約を設け、バグや通信リトライによる二重計上をDB側でも防いでいる
- [ ] 退会時に消すべきデータ（識別子）と残すべきデータ（法律上の保存義務がある取引記録）を別テーブルまたは別ストレージで設計している
- [ ] 外注費テーブルに受領日（`received_at`）と支払い日（`paid_at`）を設計している
- [ ] 未使用ポイント残高の総量を集計できるクエリまたはサマリーテーブルを設計している（供託義務の判定用）
関連：[残高DB設計](/features/accounting/balance-db)・[複合払いの返金処理](/features/accounting/mixed-payment-refund)・[退会機能](/features/privacy/account-deletion)・[外注費の支払い管理](/features/accounting/outsourcing-payment)
## UI設計
- [ ] 通販・EC購入フローの最終確認画面で必須項目を確認した（商品内容・価格・支払い条件・解約方法）
- [ ] 定期購入の場合、継続金額・解約条件を最終確認画面へ明示する設計になっている
- [ ] セール・割引の価格表示で、比較対照する「通常価格」に実際の販売実績があるか確認した（二重価格表示）
- [ ] 解約フローのUI設計を確認した（解約ボタンの視認性・誘導ステップの数）
- [ ] 管理者によるDM閲覧機能のアクセス制御を設計した（閲覧は原則不可・例外手続きの明示）
関連：[EC購入フロー](/features/content/ec-purchase-flow)・[定期購入・サブスク](/features/content/subscription)・[解約フローのUI設計](/features/content/cancellation-ui)・[管理者のDM閲覧](/features/privacy/admin-dm-viewing)
次のフェーズ → [フェーズ3：実装時](/checklist/phase-3-implementation)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# フェーズ3：実装時
Source: https://h-kono-it.github.io/legal-check-helper/checklist/phase-3-implementation
日常の実装作業の中で見落としやすいポイントです。
## フロントエンド
- [ ] 新しいサードパーティスクリプト（アナリティクス・広告・SDK）を追加する際、プライバシーポリシーへの反映を確認した
- [ ] フリー素材・有料素材のライセンスを確認した（CC BY等はクレジット表記が必要）
- [ ] OSSライブラリのライセンスを確認した（GPL・AGPL系のコピーレフトに注意）
- [ ] Webフォントの利用ライセンスを確認した（配信・PDF埋め込み・アプリ同梱はそれぞれ別ライセンスを要することがある）
- [ ] 特商法に基づく表記ページが存在し、最新情報に更新されているか確認した
関連：[タグ・SDK埋め込み](/features/privacy/analytics-sdk)・[フリー素材・OSS利用](/features/content/assets-oss)・[Webフォント](/features/content/webfont)
## バックエンド・インフラ
- [ ] スクレイピング処理にリクエスト間隔（sleep/wait）を設定した
- [ ] スクレイピング処理のUser-Agentに自社名・連絡先を記載した
- [ ] スクレイピング処理のループ・並列数が過剰にならないよう、コードレビューで確認した（悪意がなくても相手サーバーへの過負荷は業務妨害のリスク）
- [ ] ログインが必要なページへの自動アクセスについて、利用規約と不正アクセス禁止法の観点から確認した
- [ ] 外部APIへ送信しているデータが個人情報を含む場合、プライバシーポリシーに反映されているか確認した
関連：[スクレイピング](/features/content/scraping)・[外部データ連携](/features/privacy/external-data-sync)
## 発注・契約管理
- [ ] 外注先・フリーランスへの発注書を作業開始前に交付した（メール・チャットの文面でも可）
- [ ] 報酬額と支払い期日を発注時に明示した
- [ ] 仕様変更が発生した場合、追加発注（追加報酬が発生する）として処理するかを確認した
関連：[フリーランス・外注への発注](/features/people/freelance-order)
次のフェーズ → [フェーズ4：リリース前](/checklist/phase-4-release)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# フェーズ4：リリース前
Source: https://h-kono-it.github.io/legal-check-helper/checklist/phase-4-release
リリースの直前に、見落としがちな表示義務と設定を最終確認します。
- [ ] 特商法に基づく表記ページが存在し、事業者名・所在地・電話番号・返品・解約条件が記載されている
- [ ] 定期購入の最終確認画面に、定期購入の旨・継続金額・解約方法が明示されている
- [ ] 利用規約・プライバシーポリシーに外部送信先と目的が記載されている（外部送信規律）
- [ ] CI/CDまたはリリース前確認として、OSSライブラリのライセンス一覧を確認した
- [ ] AI生成コンテンツを素材として使用している場合、生成サービスの利用規約を確認した
関連：[EC購入フロー](/features/content/ec-purchase-flow)・[定期購入・サブスク](/features/content/subscription)・[タグ・SDK埋め込み](/features/privacy/analytics-sdk)・[フリー素材・OSS利用](/features/content/assets-oss)
次のフェーズ → [フェーズ5：運用継続中](/checklist/phase-5-operation)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# フェーズ5：運用継続中（定期確認）
Source: https://h-kono-it.github.io/legal-check-helper/checklist/phase-5-operation
リリース後も、残高の増減や制度変化によって法的状況は変わります。
## 月次・四半期確認
- [ ] ユーザーの未使用ポイント残高の総量を確認した（基準日の3月末・9月末に1,000万円超で供託義務）
- [ ] `balance_after`の整合性チェックバッチが正常に実行されているか確認した
- [ ] 外注費の支払い期日アラートが正常に機能しているか確認した
関連：[チャージ型電子マネー](/features/money/prepaid-emoney)・[残高DB設計](/features/accounting/balance-db)・[外注費の支払い管理](/features/accounting/outsourcing-payment)
## 随時（仕様変更時）
- [ ] ポイントの有効期限が仕様変更で6ヶ月を超えるようになっていないか確認した
- [ ] ポイントが他社でも使えるようになる仕様変更の場合、事前登録の要否を確認した
- [ ] 特商法に基づく表記ページの情報が最新であるか確認した（事業者名・所在地・電話番号等）
- [ ] 退会機能の識別子マスキングと、法定保存データの保持が正しく機能しているか確認した
- [ ] 資産計上済みの機能の作り直し・大幅な方針転換が企画された場合、経理に共有した（減損の検討対象になりうる）
- [ ] 機能・旧システムを廃止した場合、日付のある記録（稟議・停止作業のログ）を残して経理に共有した（除却の検討対象）
関連：[他社で使えるポイント](/features/money/third-party-points)・[退会機能](/features/privacy/account-deletion)・[資産計上した開発の減損](/features/assets/impairment)・[使わなくなったソフトの除却](/features/assets/retirement)
アラートに気づいたら → [法務に相談するときの準備リスト](/checklist/consulting)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# 免責事項
Source: https://h-kono-it.github.io/legal-check-helper/disclaimer
本サイトをご利用いただく前に、必ず以下をお読みください。
## 本サイトは法務判断を代替しません
本サイトの内容は情報提供のみを目的としており、法的アドバイスを構成するものではありません。本サイトの目的は、エンジニアが「これは法務案件かもしれない」と**気づく**ための手がかりを提供することであり、法令への該当性や対応方針を**判断**することではありません。
## 必ず専門家に相談し、その指示に従ってください
個別の事案については、必ず弁護士・税理士・行政書士・社会保険労務士などの専門家に相談してください。本サイトの記載と専門家の見解が異なる場合は、**常に専門家の指示に従ってください**。
## 法律の解釈には揺らぎがあります
法令の適用や解釈は、事案の具体的な事実関係・行政のガイドライン・裁判例・時代の変化によって異なりえます。本サイトに記載された解釈が唯一の解釈とは限らず、同じ機能でもサービスの構造や運用によって結論が変わることがあります。
また、法令は改正されます。本サイトの内容は参照元書籍の執筆時点（2026年）の法令に基づいており、最新の情報は各省庁の公式資料で確認してください。
## 責任を負いません
本サイトに記載された内容に基づいて行動した結果、または行動しなかった結果として生じたいかなる損害についても、本サイトの運営者・著者は一切の責任を負いません。
---
会社名・商品名・サービス名は、各社の登録商標または商標です。本サイトでは ™・® 表記を省略しています。
---
# 機能から引く
Source: https://h-kono-it.github.io/legal-check-helper/features
新機能の仕様が出たら、まず「その機能がどのカテゴリの地雷を踏みうるか」を確認してください。カテゴリを開くと、機能ごとの確認事項が並びます。
ポイント発行 / チャージ型電子マネー / 他社で使えるポイント / 送金・投げ銭 / 残高の返金
DM・チャット / 管理者のDM閲覧 / タグ・SDK埋め込み / 退会機能 / 外部データ連携
SES・業務委託への指示 / フリーランス・外注への発注
素材・OSSの利用 / フォントの利用 / UGCの広告利用 / EC購入フロー / サブスク購入フロー / 解約フローUI / スクレイピング
残高DB設計 / 複合払いの返金 / 外注費の支払い
自社開発ソフトの資産計上 / 減損 / 除却
## 迷ったときの入口
- **お金を扱う** → [お金・決済系](/features/money)。「ポイント」という言葉が仕様に出た時点で確認対象です
- **ユーザーのデータが動く** → [通信・プライバシー系](/features/privacy)。外部にデータが出るなら、タグ1行でも対象になります
- **社外の人が開発に関わる** → [人・組織系](/features/people)。指示の出し方そのものが論点です
- **画面・素材・購入フローを作る** → [コンテンツ・画面系](/features/content)
- **テーブルを設計する** → [DB・経理系](/features/accounting)。あとから直すのが最も高くつく領域です
- **自社サービスの開発を始める・やめる** → [開発費・資産系](/features/assets)。開発プロジェクトそのものが会計イベントになります
> 何かを「販売」する機能なら、[商材から引く](/products)もあわせて確認してください。商材によっては、機能とは別に許認可が必要になります。
---
# DB・経理系
Source: https://h-kono-it.github.io/legal-check-helper/features/accounting
「月末に経理から『DBの残高と帳簿が合わない』と指摘された」「返品処理でポイントとカード返金のつじつまが合わなくなった」「経営企画から失効ポイントの集計を求められたが答えられなかった」「外注先への支払い期日を見落としていた」。こうしたトラブルの多くは、**設計段階で経理・会計の視点が欠けていた**ことに起因します。このカテゴリは他と性質が違い、法令アラートというより設計指針が中心です（同じく経理とつながる領域として[開発費・資産系](/features/assets)があります）。
そして、**このカテゴリはあとから直すのが最も高くつきます。** 他の領域なら仕様変更で対応できても、記録していなかった過去のデータは遡って作れません。「先月の付与総額は？」と聞かれた時点でイベントを記録していなければ、答えは永遠に出ませんし、監査でも「この期間に何が起きたか」を証明できません。ただし外注費の支払いだけは例外で、下請法・フリーランス保護新法による「受領から60日以内」という明確な法的期限があります。
## こんな設計・状況になっていたら
- `point_balance` のような単一カラムを直接 UPDATE して残高を管理している
- 残高の変化履歴（イベント種別・日時・金額）を記録していない
- 月次の経理集計に、毎回その場しのぎのクエリを書いている
- 複合払い（ポイント＋カード）の返金ルールが未定義のまま実装に入ろうとしている
- 返金の計算式がコードの中にしかない
- 外注費の受領日を記録していない / 支払い期日の管理がスプレッドシートや担当者の記憶に依存している
## 機能別の確認事項
| 実装しようとしている機能 | 主な確認事項 |
|---|---|
| [ポイント・電子マネーの残高DB設計](/features/accounting/balance-db) | **「残高」ではなく「残高が変化したイベント」を記録する**。`event_type`（`charge` / `earn` / `use` / `refund` / `expire`）が経理処理と対応しているか。履歴は **Append Only**（UPDATE・DELETE禁止）。`balance_after` を持ち、`SUM(amount)` の理論残高との突き合わせを日次バッチで検証する。未使用残高の総量を集計できる設計は、資金決済法の**1,000万円超**の供託判定にも直結する |
| [複合払い（ポイント＋カード）の返金処理](/features/accounting/mixed-payment-refund) | **返金ルール（ポイント先返還か比例按分か）は経理・税務の方針で決まる**。エンジニアが独自に決めず、実装前に確認する。決まったルールはハードコーディングせず明文化する。二重返金を防ぐ **`idempotency_key` に UNIQUE 制約**を設け、通信リトライや重複操作をDB側でも止める |
| [外注費の支払い管理](/features/accounting/outsourcing-payment) | 下請法・フリーランス保護新法による、**「受領から60日以内に支払う」義務**。デッドラインは検収ではなく**受領（`received_at`）の時点**で発生する。「検収後翌々月末払い」は60日を超えうる。**50日経過時点でアラート**を出す仕組みを自動化する |
## このカテゴリの勘所
**記録していなかった過去は、あとから作れません。** 単一カラムの差分更新は「現在の残高はわかるが、なぜその値になったのかを追えない」状態を生みます。経理から「先月のポイント付与総額は？」「失効処理はいつ走ったか？」と聞かれても、イベントを記録していなければ答えようがありません。「残高そのもの」ではなく「残高が変化したイベント」を記録する。これがこのカテゴリすべての出発点です。
**履歴テーブルは会計でいう「仕訳帳」に相当します。** 一度記録したデータの物理削除やUPDATEは禁止（Append Only）です。誤って付与したポイントの修正も、誤レコードの削除ではなくマイナスの `amount` を持つ新しいイベント（会計の逆仕訳に相当）として発行します。削除・更新を許すとイベントの連続性が崩れ、監査に耐えられなくなります。同じ理由で、返金ルールのような判断の根拠もコードの中に埋めず、設定テーブルかドキュメントに明文化してください。「なぜこの計算式なのかコードを読んでも不明」な状態は、それ自体が監査上のリスクです。
**法的な期限は、運用ではなくシステムで担保します。** 「受領から60日以内」の義務があるのに、支払い管理をスプレッドシートや担当者の記憶に依存していると、技術的な監視ができません。うっかりの期日超過が、そのまま法令違反になります。受領日を正確に記録し、期限前に自動でアラートが飛ぶようにしておけば、この種の事故は設計で防げます。
## あわせて確認
- 供託義務・前払式支払手段の前提は → [お金・決済系](/features/money)
- 開発プロジェクト自体の資産計上・減損・除却は → [開発費・資産系](/features/assets)
- 発注時の書面交付・禁止行為そのものは → [フリーランス・外注先への発注](/features/people/freelance-order)
- 設計段階の確認漏れは → [フェーズ2：設計時（DB・API・UI設計）](/checklist/phase-2-design)
- 運用中の定期確認は → [フェーズ5：運用継続中](/checklist/phase-5-operation)（整合性チェック・支払い期日アラート）
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# ポイント・電子マネーの残高DB設計
Source: https://h-kono-it.github.io/legal-check-helper/features/accounting/balance-db
| 項目 | 内容 |
|---|---|
| **疑うべき法令・基準** | 会計基準（＋資金決済法の供託判定） |
| **確認タイミング** | DB・API設計時 |
## なにが問題になるか
ユーザーテーブルに `point_balance` カラムを持ち増減のたびに直接更新する設計は、シンプルですが「現在の残高はわかるが、なぜその値になったのかを追えない」状態を生みます。経理から「先月のポイント付与総額は？」「失効処理はいつ走ったか？」と聞かれても答えられません。
基本は「残高そのもの」ではなく、**「残高が変化したイベント」を記録する**ことです。
```sql
CREATE TABLE point_transactions (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
user_id BIGINT NOT NULL,
event_type ENUM('earn','use','refund','expire','charge') NOT NULL,
amount INT NOT NULL, -- 正: 増加、負: 減少
balance_after INT NOT NULL, -- 事後残高（照合・デバッグ用）
ref_id BIGINT, -- 関連するorder_idなど
expires_at TIMESTAMP, -- 有効期限付き残高のみ
created_at TIMESTAMP NOT NULL
);
```
`event_type` の分類は経理処理と対応しています。
| event_type | 内容 | 経理上の処理 |
|---|---|---|
| `charge` | 先払いチャージ | 前受金（負債）の増加 |
| `earn` | 購入特典の付与 | ポイント引当金の計上 |
| `use` | 決済への充当 | 前受金の消込・売上認識 |
| `refund` | 返品時の復元 | 前受金の復活または現金返金 |
| `expire` | 有効期限切れ | 雑収入または前受金消込 |
このテーブルは会計でいう「仕訳帳」に相当し、**一度記録したデータの物理削除やUPDATEは禁止**（Append Only）です。誤って付与したポイントの修正も、誤レコードの削除ではなく「付与取消」をマイナスの `amount` の新イベントとして発行します（会計の逆仕訳に相当）。削除・更新を許すとイベントの連続性が崩れ、監査で「この期間に何が起きたか」を証明できなくなります。
`balance_after`（事後残高）は冗長に見えますが、`SUM(amount)` の理論残高と突き合わせることで「トランザクションの記録漏れ」「並列更新によるデータ不整合」を自前で検知できます。日次バッチで検証し、不一致でアラートを発火する設計が推奨されます。
未使用残高の総量を集計できる設計は、資金決済法の供託義務（1,000万円超判定）にも直結します。
## 経営層の問いに答えられるか（管理会計）
経営企画やCFOが定期的に確認したい数字が3つあります。設計段階でこれらの集計クエリに答えられるかを確認してください。
- **未使用残高（負債残高）**：ユーザーが保有するチャージ残高と未使用ポイントの総量。供託判断（1,000万円超）に直結し、BS上の負債として把握が必要。`balance_after` のユーザーごと最新値の集計、またはサマリーテーブルの定期更新で対応
- **失効予測**：今後3ヶ月・6ヶ月以内に有効期限が切れるポイントの総量。`expires_at` へのインデックスが必要。失効前リマインドなどマーケ施策にも使える
- **ポイント利用率**：付与されたポイントのうち実際に使われた割合。`earn` と `use` のコホート分析で算出。付与型ポイントが購買インセンティブとして機能しているかの判断材料
イベントがBS（貸借対照表）とPL（損益計算書）のどちらに効くかの対応も押さえておくと、経営層との数字の議論がスムーズになります。
| event_type | 財務上の位置づけ | 科目例 |
|---|---|---|
| `charge` | BS負債の増加 | 前受金 |
| `earn` | BS負債の増加（引当） | ポイント引当金 |
| `use` | BS負債の減少＋PL収益 | 前受金消込・売上高 |
| `expire` | BS負債の減少＋PL収益 | 雑収入 |
| `refund` | BS負債の復活 | 前受金（再計上） |
全イベントの毎回集計はデータ量が増えると現実的でないため、日次・月次バッチでサマリーテーブルに書き出す設計が有効です。ただし「バッチが走っていない間のリアルタイム集計は信頼できない」という前提を経営層と共有しておいてください。
## 確認すべきこと
- [ ] ポイント・電子マネーの残高変化をイベント履歴テーブルで記録する設計になっている
- [ ] `event_type` の分類が経理処理に対応している（`charge` / `earn` / `use` / `refund` / `expire`）
- [ ] 履歴テーブルはAppend Only（追記専用）で運用する設計になっている（UPDATE・DELETE禁止）
- [ ] `balance_after`（事後残高）カラムを持ち、整合性チェックバッチを設計している
- [ ] 未使用ポイント残高の総量を集計できるクエリまたはサマリーテーブルを設計している（供託義務の判定用）
- [ ] 失効（`expire`）イベントを正確に記録し、失効直前のポイント総量を把握できる
- [ ] 未使用残高・失効予測・利用率の集計に答えられる（インデックス・サマリーテーブルの設計）
## こんな仕様が出たらアラート
- ポイント・チャージ残高を単一カラムの差分更新で管理している
- 残高の変化履歴（イベント種別・日時・金額）を記録していない
- 月次の経理集計に特殊なクエリが都度必要になっている
## あわせて確認
- 供託義務・届出の前提 → [チャージ型電子マネー](/features/money/prepaid-emoney)
- 返金処理の設計 → [複合払い（ポイント＋カード）の返金処理](/features/accounting/mixed-payment-refund)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# 複合払い（ポイント＋カード）の返金処理
Source: https://h-kono-it.github.io/legal-check-helper/features/accounting/mixed-payment-refund
| 項目 | 内容 |
|---|---|
| **疑うべき法令・基準** | 会計基準 |
| **確認タイミング** | DB・API設計時（実装前） |
## なにが問題になるか
「ポイント500円分＋クレジットカード1,000円で合計1,500円の商品を購入」した後のキャンセルで、どう返金するかのルールが決まっていないと経理上のトラブルに直結します。返金ルールは一般的に2パターンです。
- **ポイント先返還**：チャージ型ポイントを500円分復元し、カード返金を1,000円とする。前受金の復活もあわせて処理する。
- **比例按分**：支払い比率に応じてポイントとカードを按分して返金。端数処理のルールが別途必要。
どちらを採用するかは**経理・税務の方針で決まります**。エンジニアが独自に決めるものではなく、実装前に確認が必要です。ルールが決まったら**コードにハードコーディングせず、設定テーブルかドキュメントに明文化**してください。「なぜこの計算式なのかコードを読んでも不明」という状態は、監査に耐えられないコードを生みます。
もう1つの落とし穴が**二重返金**です。ネットワークの再試行やユーザーの重複操作により、同じ返金リクエストを複数回受信することがあります。
```sql
ALTER TABLE point_transactions
ADD COLUMN idempotency_key VARCHAR(64) UNIQUE;
```
`idempotency_key` には「注文ID＋返金種別」など同一リクエストを一意に識別できる値をセットします。UNIQUE制約により二重実行時にDBがエラーを返すため、アプリ側で冪等性を保証できます。返金処理は金額に直結するため、この設計を省略すると二重返金が発生し、経理上の不整合につながります。
## 確認すべきこと
- [ ] 複合払いの返金ルール（ポイント先返還か比例按分か）を経理・税務と確認してから実装に入った
- [ ] 返金ルールを設定テーブルまたはドキュメントに明文化した（ハードコーディングしていない）
- [ ] 複合払いの返金処理に冪等性キー（`idempotency_key`）を設計している
- [ ] `idempotency_key` カラムにUNIQUE制約を設け、バグや通信リトライによる二重計上をDB側でも防いでいる
- [ ] 返金時の前受金の復活（`refund` イベント）が記録される設計になっている
## こんな仕様が出たらアラート
- 複合払い（ポイント＋カード）の返金ルールが未定義のまま実装に入る
- 返金処理のルールがコードにハードコーディングされている
- 返金APIにリトライ・重複リクエスト対策がない
## あわせて確認
- 前提となる履歴テーブル設計 → [ポイント・電子マネーの残高DB設計](/features/accounting/balance-db)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# 外注費の支払い管理
Source: https://h-kono-it.github.io/legal-check-helper/features/accounting/outsourcing-payment
| 項目 | 内容 |
|---|---|
| **疑うべき法令** | 下請法・フリーランス保護新法 |
| **確認タイミング** | DB設計〜運用時 |
## なにが問題になるか
下請法・フリーランス保護新法には、**「受領から60日以内に支払う」義務**があります。支払い管理をスプレッドシートや担当者の記憶に依存していると、技術的な監視ができず「うっかり遅払い」がそのまま法令違反になります。
外注費の支払い管理をシステム化するときは、次の状態遷移を記録できる設計が必要です。
**発注 → 納品（受領）→ 検収 → 支払い**
法的なデッドラインが発生するのは、**「受領」のタイミング**です。「検収が終わってから翌々月末払い」のような条件は、受領から支払いまでが60日を超えることがあります。受領日を正確に記録し、期限前に自動アラートを出す仕組みがあれば、うっかりの期日超過を防げます。
```sql
SELECT
order_id,
contractor_name,
received_at,
DATE_ADD(received_at, INTERVAL 60 DAY) AS payment_deadline,
paid_at,
CASE
WHEN paid_at IS NULL
AND NOW() > DATE_ADD(received_at, INTERVAL 50 DAY)
THEN 'ALERT'
ELSE 'OK'
END AS status
FROM outsourcing_orders
WHERE paid_at IS NULL;
```
50日経過時点（10日前）にアラートを出すことで、支払い処理の時間的余裕を確保できます。このクエリを週次バッチで実行してSlackやメールに通知する仕組みは、法的リスクの削減に直結します。
## 確認すべきこと
- [ ] 外注費テーブルに受領日（`received_at`）と支払い日（`paid_at`）を設計している
- [ ] 外注費の納品日（受領日）を記録している・あいまいにしていない
- [ ] 「60日以内支払い」を確認する自動化された仕組みがある（50日時点のアラートなど）
- [ ] 支払い期日の管理がスプレッドシートや担当者の記憶に依存していない
- [ ] 運用中、支払い期日アラートが正常に機能しているか定期確認している
## こんな仕様が出たらアラート
- 外注費の納品日（受領日）を記録していない・あいまいにしている
- 支払い期日の管理がスプレッドシートや担当者の記憶に依存している
- 「検収後翌々月末払い」など受領から60日を超えうる支払い条件
## あわせて確認
- 発注時の書面交付・禁止行為 → [フリーランス・外注先への発注](/features/people/freelance-order)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# 開発費・資産系
Source: https://h-kono-it.github.io/legal-check-helper/features/assets
「開発に着手したら、経理から『このプロジェクトは資産計上します』と言われた」「作り直しプロジェクトの途中で、監査から減損の話が出てきた」「とっくに止めた旧システムが、帳簿にはまだ載っていた」。このカテゴリは他のカテゴリと入口が違います。トリガーになるのは「実装する機能」ではなく、**開発プロジェクトそのもの**です。自社で使うソフトウェアを作る行為は、会計上は「資産を作る行為」になることがあります。
そして、資産計上・減損・除却の判定材料は、**現場にしかありません。** いつ要件が固まったか、誰がどの作業に工数を使ったか、あの機能の作り直しが始まったこと、旧システムを止めたこと——経理はこれらを自動的には知りえません。判定するのは経理ですが、**兆候を検知して伝えられるのは作る側だけ**です。このカテゴリの各ページは「何を検知したら、経理に何を投げるか」の形で書いています。
なお、このカテゴリの根拠は法令ではなく会計基準・実務指針（と税務上の取り扱い）が中心で、上場か非上場か、会計基準ベースか税務基準ベースかで扱いの温度差があります。細かい判定はせず、「自社ではどう扱っているか」をまず経理に確認するところから始めてください。
## こんな状況になっていたら
- 自社サービスの新規開発・リプレースが始まるのに、資産計上するかどうかを誰も経理に確認していない
- 工数の集計に、開発作業と、調査・PoC・新メンバーのキャッチアップ期間が区別なく混ざっている
- 資産計上して作った機能の「作り直し」「フルリニューアル」が始まろうとしている
- 「効果が出るのは後続フェーズの完成後」という構成の開発で、後続フェーズの凍結が先行フェーズの資産（仮勘定）に響くことを誰も意識していない
- もう使っていない機能・旧システムが、止めた記録もないまま帳簿に載り続けている
## 開発の状況別の確認事項
| 開発の状況 | 主な確認事項 |
|---|---|
| [自社開発ソフトの資産計上](/features/assets/capitalization)（新規開発・大規模改修に着手する） | **「この開発、資産計上前提？」を着手前に経理に確認する**。資産計上するなら、工数集計の開始時点（要件確定・稟議）と、資産に乗せない作業（調査・PoC・キャッチアップ・保守）の区分を最初に決める。工数管理の設計がそのまま会計記録の元データになる |
| [資産計上した開発の減損](/features/assets/impairment)（方針転換・計画未達・遊休化） | 凍結したはずの仕様の大幅変更、資産計上済み機能の作り直し、事業ピボット、後続フェーズの凍結、収益計画の大幅未達は**減損の兆候になりうる**。決算で経理が気づくのでは遅い。現場で起きた時点で経理に共有する |
| [使わなくなったソフトの除却](/features/assets/retirement)（機能・システムの廃止、リプレース） | 使わなくなったことが明らかなら、物理的な廃棄がなくても帳簿から落とせる扱いがある。**「今後使わない」ことを示す日付のある記録**（廃止の稟議・停止作業の記録・リポジトリのアーカイブ）を残し、経理に共有する |
## このカテゴリの勘所
**経理は現場を見ていません。** 残高DBや支払い期日と違って、資産計上・減損・除却のトリガーは開発現場のできごと（着手・方針転換・停止）です。経理が決算作業で気づいたときには、工数は区分できない形で集計済み、停止の記録は残っていない、ということが起きます。逆に言えば、作る側が「これは経理に伝えるやつだ」と気づけさえすれば、あとは定型の連絡ひとつで済みます。各ページに経理への連絡テンプレを置いているので、そのまま使ってください。
**判定はしない。検知して伝える。** 資産計上の要否も、減損損失の要否・金額も、除却のタイミングも、決めるのは経理・会計士です。作る側の仕事は、判定に必要な現場の事実（日付・工数・意思決定の記録）を、判定できる形で残しておくことです。
## あわせて確認
- 企画・着手前のチェックは → [フェーズ1：機能企画・要件定義時](/checklist/phase-1-planning)
- 運用中・廃止時のチェックは → [フェーズ5：運用継続中](/checklist/phase-5-operation)
- 外注で開発する場合の支払い期日は → [外注費の支払い管理](/features/accounting/outsourcing-payment)（外注制作費も取得価額に関わります）
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# 自社開発ソフトの資産計上
Source: https://h-kono-it.github.io/legal-check-helper/features/assets/capitalization
| 項目 | 内容 |
|---|---|
| **疑うべきルール** | 研究開発費・ソフトウェアに関する会計基準／実務指針、法人税法上の耐用年数 |
| **確認タイミング** | 企画・要件定義時（着手前） |
## なにが問題になるか
自社で利用するソフトウェアは、その利用により**将来の収益獲得または費用削減が確実**と認められる場合、制作にかかった費用を無形固定資産「ソフトウェア」として計上する扱いになっています（研究開発費及びソフトウェアの会計処理に関する実務指針）。資産計上されると、開発費は「発生した期の費用」ではなく「完成後に数年かけて償却される資産」になります。税務上の耐用年数は、自社利用のソフトウェアなら**5年**です（複写して販売するための原本や研究開発用のものは3年）。
エンジニア・ディレクターに直接効いてくるのは、この判定そのものではなく、**「どこからどこまでを資産に乗せるか」の材料が現場の記録だけ**という点です。
- **開始時点**: 資産計上の対象になるのは「収益獲得・費用削減が確実と認められる状況になった時点」以降の費用で、その時点は稟議書や制作番号を付けた管理台帳などの**証憑で立証**します。企画・調査段階の費用や、研究開発に該当する部分は費用処理です。つまり「いつ要件が固まり、いつ作ることが決まったか」が日付のある記録で残っている必要があります
- **工数の区分**: 開発メンバーの人件費は工数ベースで取得価額に集計されるのが一般的です。工数管理ツールの設計がそのまま会計記録の元データになるため、**最初に区分を作っていないと、あとから仕分けできません**
- **キャッチアップ・教育の工数**: 新規参画メンバーの学習期間・トレーニングに相当する費用は、ソフトウェアの取得価額に含めない扱いが一般的です（税務上も、導入にあたっての研修費用などは取得価額に算入しないことができるとされています）。「プロジェクトに紐づく工数」を全部同じバケツで集計していると、資産に乗せるべきでない費用が混ざります
- **完成の時点**: 償却は事業の用に供した時点（リリース・稼働）から始まります。リリースしたことが経理に伝わっていないと、償却の開始も遅れます
なお、完成までの間の制作費は「**ソフトウェア仮勘定**」という勘定にいったん集計され、完成して稼働した時点でソフトウェア勘定に振り替えられて償却が始まります。仮勘定に乗せられる条件も本勘定と同じで、収益獲得・費用削減の確実性を**具体的な計画**（何を・いつまでに完成させ・どう使うか）で立証できることが前提です。
ここで特に気をつけたいのが**フェーズ分割された開発**です。「フェーズ1は基盤づくりで、収益・費用削減の効果はフェーズ2以降が完成してはじめて出る」という構成の場合、フェーズ1の制作費（仮勘定）の資産性は、**後続フェーズまで含めた計画**を根拠に成立しています。つまり後続フェーズの計画が崩れると、完成済み・制作中を問わず、先行フェーズ分の会計上の前提も一緒に崩れます。後続フェーズが凍結・中止になったときの話は[減損](/features/assets/impairment)を見てください。着手前にできることは、フェーズ間の依存関係（どのフェーズの完成で効果が出るのか）を経理に伝えておくことと、後続フェーズの凍結・中止が決まったら経理に報告する、をプロジェクトの決めごとにしておくことです。
もうひとつ、着手前に押さえたいのが**仕様凍結との関係**です。資産計上は「この仕様のものを作れば収益・費用削減に確実に貢献する」という前提で始まります。「作りながら仕様を固める」タイプの開発と資産計上前提のプロジェクト管理は相性が悪く、凍結後の大幅な方針転換は[減損](/features/assets/impairment)の話につながります。
## 確認すべきこと
- [ ] この開発が資産計上の対象になるか、**着手前に**経理に確認した
- [ ] 資産計上する場合、工数集計の開始時点と、その根拠になる記録（稟議・キックオフの議事録など）を確認した
- [ ] 工数管理で、資産計上対象の開発作業と、対象外の作業（調査・PoC・キャッチアップ・保守/バグ修正）を区別できるようにした
- [ ] 仕様凍結（要件確定）のマイルストーンがプロジェクト計画にある
- [ ] リリース（事業の用に供した時点）を経理に共有するフローがある
- [ ] フェーズ分割した開発で、先行フェーズの効果が後続フェーズの完成に依存する場合、その依存関係を経理に伝えた
- [ ] 後続フェーズの凍結・延期・中止が決まったら経理へ報告することを、プロジェクトの決めごとにした
## こんな状況が出たらアラート
- 自社サービスの新規開発・大規模改修なのに、資産計上するかどうかを誰も経理に確認していない
- 新メンバーのキャッチアップ期間や事前調査の工数が、開発工数と同じバケツで集計されている
- 保守・バグ修正と機能追加が、工数上区別されていない
- 「作りながら仕様を固める」方針なのに、資産計上前提でプロジェクトが始まっている
- 「効果が出るのは後続フェーズの完成後」という構成なのに、後続フェーズの計画が固まらないまま先行フェーズの仮勘定への集計が始まっている
## 経理への連絡テンプレ
判定は経理の仕事です。着手前に、次の形で投げれば十分です。
```text
新規開発の資産計上について確認させてください。
・プロジェクト名／目的：（自社サービスの新規開発 or 既存機能の大規模改修）
・体制と想定期間：
・フェーズ構成：（フェーズ分割する場合、効果が出るのはどのフェーズの完成時か）
・確認したいこと：
1. この開発は資産計上の対象になりますか
2. 対象の場合、工数集計はいつから始めますか（根拠にする記録も指定してください）
3. 工数から除外すべき作業（調査・キャッチアップ・保守など）の区分を指定してください
```
## あわせて確認
- 凍結後の方針転換・計画未達 → [資産計上した開発の減損](/features/assets/impairment)
- 外注で開発する場合の支払い期日 → [外注費の支払い管理](/features/accounting/outsourcing-payment)
- 着手前のチェックリスト → [フェーズ1：機能企画・要件定義時](/checklist/phase-1-planning)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# 資産計上した開発の減損
Source: https://h-kono-it.github.io/legal-check-helper/features/assets/impairment
| 項目 | 内容 |
|---|---|
| **疑うべきルール** | 固定資産の減損に係る会計基準 |
| **確認タイミング** | 運用時・大規模改修や方針転換の企画時 |
## なにが問題になるか
[資産計上](/features/assets/capitalization)されたソフトウェアは、償却が終わるまで帳簿に残ります。その資産が「投資額を回収できる見込みがなくなった」状態になると、**減損**——帳簿価額を切り下げて損失を計上する処理——の検討対象になります。減損の兆候として会計基準が挙げているのは、たとえば次のようなものです。
- その資産を使う事業の損益が継続してマイナス
- 資産の**使用範囲・方法の著しい変化**（事業の廃止・再編、遊休状態になった、用途変更）
- 経営環境の著しい悪化
これをソフトウェア開発の現場のことばに翻訳すると、こうなります。
- 資産計上して作った機能を、**ほぼ捨てて作り直す**ことになった（凍結したはずの仕様の大幅変更、フルリニューアル）
- 事業のピボットで、初期に作った主要機能が実質使われていない
- 資産計上の前提だった収益・費用削減の計画に対して、実績が大きく未達
- フェーズ分割した開発で、**後続フェーズが凍結・中止になった**
最後のケースは見落とされがちなので補足します。「フェーズ1は基盤で、効果はフェーズ2以降の完成で出る」という構成では、フェーズ1の[資産計上・仮勘定計上](/features/assets/capitalization)は後続フェーズ込みの計画を根拠に成立しています。フェーズ2の凍結は、現場では「一旦保留」で済む話でも、帳簿の上では**フェーズ1分の資産が計画という根拠を失うイベント**です。これは制作途中でも同じで、ソフトウェア仮勘定も減損会計の対象とされており、完成しないまま長期滞留した仮勘定は監査でも注目されます。後続フェーズの凍結・中止が決まったら、その時点で経理に報告することを勧めます。
問題は、これらが全部**現場で先に起きる**ことです。経理が資産の状態を見直すのは決算のタイミングですが、そのときに現場の状況が伝わっていなければ、兆候の検知そのものが遅れます。減損すべきものを計上しないまま決算を出すことは、会計監査や上場審査で問題になりえます。逆に、作り直しの企画が立った時点で一報が入っていれば、経理は検討を始められます。
なお、減損の要否や金額の判定は将来キャッシュ・フローの見積りを伴う専門的な領域で、作る側が判断することは一切ありません。やることは**兆候の共有だけ**です。
## 確認すべきこと
- [ ] 自分たちのプロダクトのうち、どれが資産計上されて帳簿に載っているかを把握している（経理に一覧をもらう）
- [ ] 資産計上済みの機能の作り直し・大幅改修が企画されたら、経理に共有するフローがある
- [ ] 事業のピボット・機能の廃止方針が、経理にも届いている
- [ ] 後続フェーズの凍結・中止が決まったら、先行フェーズの資産計上分（仮勘定含む）とあわせて経理に報告するフローがある
- [ ] 主要機能の利用状況（使われているかどうか）を把握できる状態にある
## こんな状況が出たらアラート
- 資産計上して作った機能の「フルリニューアル」「作り直し」が始まろうとしている
- 仕様凍結後に、前提を覆すレベルの方針転換が起きた
- ピボットの結果、初期の主要機能がほぼ使われていないのに帳簿には載ったまま
- 資産計上時の事業計画と実績の乖離が大きいことを、現場は知っているが経理は知らない
- 後続フェーズの凍結が決まったのに、先行フェーズで資産計上・仮勘定計上した分の話を誰もしていない
## 経理への連絡テンプレ
```text
資産計上されている開発について、状況を共有します（減損の要否のご判断用です）。
・対象：（プロジェクト名／機能名）
・起きたこと：（作り直しの企画が開始／後続フェーズの凍結・中止／ピボットで利用が大幅減／計画未達 など）
・時期：（意思決定日・関連する稟議や議事録）
・補足：（利用状況のデータなど、あれば）
```
## あわせて確認
- そもそもの資産計上の前提 → [自社開発ソフトの資産計上](/features/assets/capitalization)
- 使うのを完全にやめた場合 → [使わなくなったソフトの除却](/features/assets/retirement)
- 運用中の定期確認 → [フェーズ5：運用継続中](/checklist/phase-5-operation)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# 使わなくなったソフトの除却
Source: https://h-kono-it.github.io/legal-check-helper/features/assets/retirement
| 項目 | 内容 |
|---|---|
| **疑うべきルール** | 法人税基本通達（ソフトウエアの除却）、固定資産の会計処理 |
| **確認タイミング** | 機能・システムの廃止時、リプレース時 |
## なにが問題になるか
[資産計上](/features/assets/capitalization)されたソフトウェアを使わなくなったのに帳簿に残したままだと、実態のない資産の償却費を計上し続けることになります。一方で、ソフトウェアには物理的な「廃棄」がありません。そこで税務上は、物理的な除却・廃棄がなくても、**そのソフトウェアを今後事業の用に供しないことが明らかな事実があるとき**は、帳簿価額を除却損として損金算入できる扱いがあります（法人税基本通達）。自社利用ソフトなら「対象業務が廃止された」「ハードウェアやOSの変更で別のソフトに乗り換え、従来のものを利用しなくなったことが明らか」といったケースが典型です。
エンジニア視点でのポイントは2つあります。
**1つ目: 現場の「終わり」と会計の「終わり」はタイミングが違う。** 現場ではリプレース完了・最終デプロイ・リポジトリのアーカイブで一件落着ですが、会計上はそこからがイベントです。旧システムを止めたことが経理に伝わらなければ、帳簿では動き続けていることになります。リプレース案件では、旧システムをいつ帳簿から落とすかまで含めて経理と話しておくのが安全です。
なお、**完成前に開発計画そのものを中止した場合**も話は同じです。制作途中の費用が集計されている[ソフトウェア仮勘定](/features/assets/capitalization)をどう処理するか（費用化・除却）は経理の判断事項なので、中止の意思決定の記録を残して共有してください。後続フェーズだけを凍結して先行フェーズは残る、というケースは[減損](/features/assets/impairment)の話になります。
**2つ目: 「使っていない」ことは記録で示す必要がある。** 「今後使用しないことが明らか」かどうかは、税務調査でも客観的な資料で確認されます。廃止の意思決定（稟議・議事録）や停止作業の事実（最終デプロイ日、サーバ停止日、DNS切り替え、リポジトリのアーカイブ日）が**日付のある記録**として残っていることが効きます。普段の開発で自然に残るログや ADR が、そのまま証憑の材料になります。逆に「いつか使うかもしれないから」とサーバだけ止めて塩漬けにしていると、使わないことが「明らか」とは言えず、除却できない状態が続きます。
## 確認すべきこと
- [ ] 機能・システムの廃止が決まったら経理に共有するフローがある
- [ ] 廃止の意思決定が、日付のある記録（稟議・議事録・ADR など）で残っている
- [ ] 停止作業の事実（最終デプロイ、サーバ停止、DNS 切り替え、リポジトリのアーカイブ）を日付つきで記録した
- [ ] リプレース案件で、旧システムの除却タイミングを経理と確認した
- [ ] 完成前に開発を中止した場合、仮勘定に集計済みの制作費の扱いを経理に確認した
- [ ] 「念のため残す」場合、それが会計上どういう状態になるかを経理に確認した
## こんな状況が出たらアラート
- 旧システムを止めたことを、経理が誰も知らない
- サービス終了の社内アナウンスはあったが、日付のある記録が何も残っていない
- 廃止済みの機能が「念のため」でホスティングされ続けている（会計上は宙ぶらりん、インフラコストも垂れ流し）
- リプレース計画に、旧システムの停止と記録のタスクが入っていない
## 経理への連絡テンプレ
```text
ソフトウェアの利用停止について共有します（除却のご判断用です）。
・対象：（システム名／機能名）
・停止の理由：（リプレース完了／対象業務の廃止／サービス終了 など）
・意思決定の記録：（稟議・議事録の日付とリンク）
・停止の事実：（最終デプロイ日、サーバ停止日、リポジトリのアーカイブ日 など）
```
## あわせて確認
- 完全にやめる前の「大幅に作り直す」段階 → [資産計上した開発の減損](/features/assets/impairment)
- そもそもの資産計上の前提 → [自社開発ソフトの資産計上](/features/assets/capitalization)
- 運用中の定期確認 → [フェーズ5：運用継続中](/checklist/phase-5-operation)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# コンテンツ・画面系
Source: https://h-kono-it.github.io/legal-check-helper/features/content
「フリー素材のクレジット表記はどこに書けばいいか」「ユーザーの投稿画像をバナー広告に使っていいか」「サブスクの購入画面には何を書けばいいか」「競合サイトのデータをスクレイピングして分析に使っていいか」。**画面を作り、素材を使い、データを取ってくる作業は、そのすべてが誰かの権利に触れています。**
このカテゴリは扱う法律の幅が広く、**素材・コードの権利**（著作権法）、**購入画面・広告の表示**（特定商取引法・景品表示法）、**データの自動収集**（不正アクセス禁止法・不正競争防止法・刑法）の3領域に分かれます。共通するのは、いずれも実装そのものに直結すること。そして「デザイナーやPMの指示通りに作った」「悪意はなかった」が、いずれの領域でも免責にならないことです。
## こんな言葉が仕様に出たら
- **フリー素材** / OSS / ライブラリ / ライセンス / クレジット表記
- フォント / Webフォント / PDF出力 / アプリ同梱
- ユーザー投稿 / UGC / バナー / キャンペーン素材 / インフルエンサー / PR表記 / レビュー施策
- 購入画面 / 最終確認画面 / カート / 定期購入 / サブスク / 初回無料
- セール / 通常価格 / 取り消し線 / 割引率 / カウントダウン
- 解約 / 休止プラン / 解約率
- スクレイピング / クローラー / 自動収集 / 競合調査
## 機能別の確認事項
### 素材・権利まわり
| 実装しようとしている機能 | 主な確認事項 |
|---|---|
| [フリー素材・OSSライブラリの利用](/features/content/assets-oss) | **「無料＝自由に使える」ではない**。`CC BY`（クレジット表記必須）と `CC0`（表記不要）は別物。**`GPL`・`AGPL` はコピーレフト**で、プロダクト全体を同じライセンスで公開する義務を負う可能性がある。依存ライブラリは `license-checker-rseidelsohn` 等でCI/CD上に自動検知を組む。AI生成物も「著作権フリー」ではない |
| [Webフォント・フォントの埋め込み](/features/content/webfont) | **用途ごとに別ライセンス**。デスクトップ用途／Webフォントとしての配信／PDFへの埋め込み／アプリへの同梱はそれぞれ別枠。「デスクトップ用途は購入済み」でも**配信ライセンスは別途必要**なことが多い。PDF出力機能やフォント同梱アプリは特に注意 |
| [UGCの広告・プロモーション利用](/features/content/ugc-promotion) | **著作権は投稿者に帰属**。「サービスに投稿された」だけでは事業者が自由に使えるわけではない。利用規約の非独占的ライセンス条項が前提になるが、**「想定外の利用」は許諾範囲を超える**（他社への素材提供など）。加えて2023年施行の**ステマ規制**：対価を渡した投稿に「広告」「PR」表記がない、事業者が関与した投稿を一般投稿のように見せる、は不当表示になる |
### 購入・解約フロー
| 実装しようとしている機能 | 主な確認事項 |
|---|---|
| [通販・EC購入フローの実装](/features/content/ec-purchase-flow) | **単品購入でも最終確認画面の表示義務がある**。商品・サービスの内容／**販売価格（送料含む総額）**／支払い時期・支払い方法／申込みの撤回・解約に関する事項の4点。加えて、**「特商法に基づく表記」ページの設置義務**（事業者名・所在地・電話番号・返品・解約条件）。セール価格の見せ方も規制対象：販売実績のない「通常価格」との比較（**二重価格表示**）は有利誤認のリスク |
| [定期購入・サブスクの購入フロー](/features/content/subscription) | 2022年改正で強化。上記4点に加え、**定期購入である旨／支払い総額（初回だけでなく継続回分も含む）／解約方法・解約条件**が必須。**「初回980円」を大きく、「2回目以降は毎月5,980円」を小さく**は不当表示にあたる。消費者庁は2023年以降、ダークパターンに業務停止命令を出している |
| [解約フローのUI設計](/features/content/cancellation-ui) | **解約を不当に困難にするUIは違法**。解約申請後の複数ページにわたるアンケート、背景色と同化した解約ボタン、休止プランへの繰り返し誘導が該当する。**「解約完了までのUIフロー全体」をデザインレビューの法的チェック対象**に含める |
### データ取得
| 実装しようとしている機能 | 主な確認事項 |
|---|---|
| [外部サービスのデータ自動収集（スクレイピング）](/features/content/scraping) | **`robots.txt` に法的拘束力はない**が、無視してよいという意味でもない。**ログインの要否が第一の分岐**（認証回避・他人のアカウントを使ったアクセスは不正アクセス禁止法違反＝3年以下の懲役または100万円以下の罰金）。体系的な大量取得は不正競争防止法の問題になりうる。**リクエスト間隔の設定は法的防御策**。User-Agentに自社名・連絡先を記載する |
## このカテゴリの勘所
**ライセンスは「使っていいよ」の条件書きです。** 著作権法上は、権利者の許諾がない限り著作物を利用できません。「無料で使えるなら何でもOK」ではなく、クレジット表記が条件のものもあれば、コピーレフトでプロダクト全体の公開義務を負うものもあります。パッケージマネージャ経由の依存を手動で追うのは現実的でないので、ライセンス確認はCI/CDに組み込んで自動で落ちるようにするのが理想です。
**特商法の義務は、フロントエンドの実装そのものです。** 最終確認画面に何を表示するか、文字サイズをどうするか、解約ボタンをどこに置くか。これらはすべて実装者が書くコードの話であり、「法務やマーケティングの問題」ではありません。行政処分の対象はシステムを運営する事業者ですが、実装者は「この画面は法的要件を満たせているか」を確認できる立場にあります。
**景品表示法は「見せ方」の法律です。** 特商法が「表示すべきものが揃っているか」なら、景表法は「その表示が実際より良く見せる嘘になっていないか」を問います。販売実績のない「通常価格」との比較（二重価格表示）、広告と分からない宣伝投稿（ステマ規制）が代表例で、どちらも文言・UIそのものが規制対象です。取り消し線の価格UIやレビューキャンペーンの仕様が出たら、実装前にアラートを出してください。
**スクレイピングは「規約違反」と「犯罪」を区別してください。** 利用規約違反は民事上の問題（アカウント停止・損害賠償請求）で刑事罰はありません。一方、不正アクセス禁止法・不正競争防止法の違反は刑事上の犯罪で、逮捕・起訴の対象です。そして悪意がなくても、ループのバグや過度な並列処理でサービスを止めれば業務妨害罪（刑法第234条の2）になりえます。2010年の岡崎市立中央図書館事件では、デフォルト設定のままのクロールプログラムが障害を起こし、開発者が逮捕されました。
## あわせて確認
- 何かを「販売」するなら → [商材から引く](/products)（商材によっては別の許認可が必要）
- 収集・連携するデータに個人情報が含まれるなら → [外部CRM・メール配信サービスへのデータ連携](/features/privacy/external-data-sync)
- 埋め込むタグ・SDKがあるなら → [アナリティクスタグ・SDKの埋め込み](/features/privacy/analytics-sdk)
- UI設計段階の確認漏れは → [フェーズ2：設計時](/checklist/phase-2-design)
- 実装中の確認は → [フェーズ3：実装時](/checklist/phase-3-implementation)
- 表示義務の最終確認は → [フェーズ4：リリース前](/checklist/phase-4-release)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# フリー素材・OSSライブラリの利用
Source: https://h-kono-it.github.io/legal-check-helper/features/content/assets-oss
| 項目 | 内容 |
|---|---|
| **疑うべき法令** | 著作権法 |
| **確認タイミング** | 実装時（素材・ライブラリを新たに使うたび） |
## なにが問題になるか
著作権法上は、**権利者の許諾がない限り著作物を利用できません**。フリー素材・OSSライブラリの「ライセンス」とは「一定の条件を守れば使っていい」という使用許諾の条件書きであり、「無料で使えるなら何でもOK」は誤解です。
**素材のライセンス**：Creative Commonsライセンスには複数の種類があり、`CC BY`（クレジット表記必須）と `CC0`（パブリックドメイン・表記不要）は全く別物です。`CC BY` の画像をWebサービスに使うなら制作者のクレジットをページ上に明示することが条件で、省略すると著作権侵害になります。
**OSSのライセンス**：`MIT`・`Apache 2.0`・`BSD` など表記義務の緩いライセンスが多い一方、`GPL` や `AGPL` は要注意です。GPLライセンスのコードをプロダクトに組み込むと、**プロダクト全体を同じGPLライセンスで公開する義務**（コピーレフト）を負う可能性があります。商用サービスへの組み込みは特に慎重な確認が必要です。
パッケージマネージャ経由の依存ライブラリを手動で確認するのは困難なので、`license-checker-rseidelsohn`（Node.js）や `pip-licenses`（Python）のようなツールで一覧化し、**CI/CDパイプラインでライセンス確認を自動化**してGPL系など許可されていないライセンスの混入を検知する体制が理想です。
**AI生成コンテンツも「著作権フリー」ではありません**。生成物の著作権帰属は法的に未確定で、特定のアーティストのスタイルを再現するよう指示して生成した画像は元の著作物に依拠しているとみなされる可能性があります。「AIが生成した」という事実は免責理由にならず、権利状態を確認する責任は利用者側にあります。
## 確認すべきこと
- [ ] フリー素材・有料素材のライセンスを確認した（CC BY等はクレジット表記が必要）
- [ ] OSSライブラリのライセンスを確認した（GPL・AGPL系のコピーレフトに注意）
- [ ] CI/CDまたはリリース前確認として、OSSライブラリのライセンス一覧を確認した
- [ ] AI生成コンテンツを素材として使用している場合、生成サービスの利用規約を確認した
## こんな仕様が出たらアラート
- フリー素材・有料素材・OSSライブラリを新たに使う（ライセンス種別の確認）
- GPLやAGPLライセンスのライブラリをプロダクトコードに組み込む
- AI生成コンテンツを素材として使う（特定スタイル模倣・学習データ由来のリスク）
- 他サービスのデザイン・UIをそのまま再現する
## あわせて確認
- フォント固有の落とし穴 → [Webフォント・フォントの埋め込み](/features/content/webfont)
- ユーザー投稿コンテンツの利用 → [UGCの広告・プロモーション利用](/features/content/ugc-promotion)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# 解約フローのUI設計
Source: https://h-kono-it.github.io/legal-check-helper/features/content/cancellation-ui
| 項目 | 内容 |
|---|---|
| **疑うべき法令** | 特定商取引法 |
| **確認タイミング** | UI設計〜デザインレビュー時 |
## なにが問題になるか
2022年改正以降、消費者庁は**解約を不当に困難にするUI**も取り締まりの対象にしています。「解約させない工夫」は特商法上の違法なダークパターンです。具体的には次のようなUIが該当します。
- 解約申請後にアンケートを複数ページにわたって表示する
- 「解約」ボタンだけ背景色と同化させて視認しにくくする
- 「休止プラン」への誘導を繰り返す
こうした設計は「デザイナーやPMの指示通りに作った」という状況であっても、違反が発覚すれば開発チーム全体への影響は避けられません。行政処分の対象はシステムを運営する事業者ですが、実装者は「この画面の法的要件を満たせているか」を確認できる立場にあります。
**「解約完了までのUIフロー全体」をデザインレビューの法的チェック対象に含めてください。**
## 確認すべきこと
- [ ] 解約ボタンの視認性を確認した（背景色との同化・極端に小さい配置になっていない）
- [ ] 解約完了までの誘導ステップの数を確認した（不当に多段になっていない）
- [ ] 解約前のアンケートが複数ページにわたって挟まっていない
- [ ] 休止プラン等への誘導が繰り返し表示される設計になっていない
- [ ] 解約完了までのUIフロー全体をデザインレビューの法的チェック対象に含めた
## こんな仕様が出たらアラート
- 解約フローのステップ数が多い・解約ボタンを視認しにくい配色にしている
- 解約の前に休止プランへの誘導やアンケートが何度も挟まる
- 「解約率を下げるためにフローを工夫したい」という要望
## あわせて確認
- 購入側の最終確認画面の義務 → [定期購入・サブスクの購入フロー](/features/content/subscription)
- 単品購入の表示義務 → [通販・EC購入フローの実装](/features/content/ec-purchase-flow)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# 通販・EC購入フローの実装
Source: https://h-kono-it.github.io/legal-check-helper/features/content/ec-purchase-flow
| 項目 | 内容 |
|---|---|
| **疑うべき法令** | 特定商取引法・景品表示法 |
| **確認タイミング** | UI設計時・リリース前 |
## なにが問題になるか
### 表示すべきものが揃っているか — 最終確認画面（特商法）
特定商取引法（特商法）でエンジニアに特に関係するのが、**「最終確認画面」の規制**です。通信販売のすべての取引で、購入ボタンを押す直前の画面に次の事項を**明確に表示する義務**があります。
- 商品・サービスの内容
- 販売価格（送料含む総額）
- 支払い時期・支払い方法
- 申込みの撤回・解約に関する事項
**単品購入のECサイトでも対象**です。価格や支払い条件が最終確認画面に正しく表示されていなければ特商法違反になります。
この法的義務は「法務やマーケティングの問題」ではなく、**フロントエンドの実装に直結します**。最終確認画面の表示内容・文字サイズ・ボタンの配置はすべてフロントエンドエンジニアが実装するものです。「デザイナーやPMの指示通りに作った」としても、開発チーム全体への影響は避けられません。実装者は「この画面は法的要件を満たせているか」を確認できる立場にあります。
さらに、通信販売を行うサイトには、**「特商法に基づく表記」ページの設置義務**があります。事業者名・所在地・電話番号・メールアドレス・代表者名・販売価格・支払い方法・返品・解約条件などの表記が必要で、このページがないサービスはそれだけで違反になります。フッターにリンクが存在するか、情報が最新かも確認ポイントです。
### 価格の「見せ方」が嘘になっていないか — 二重価格表示（景表法）
特商法が「何を表示しなければならないか」の法律だとすると、景品表示法は「その表示が実際より良く見せる嘘になっていないか」の法律です。購入フローの実装で代表的な地雷が**二重価格表示**です。
「通常価格9,800円 → セール価格4,900円」のような取り消し線付きの価格表示は、比較対照している「通常価格」で**実際に販売していた実績**がなければ、実際より著しく有利だと誤認させる**有利誤認表示**として景表法違反になりえます。消費者庁の価格表示ガイドラインでは、過去の販売価格を比較対照に使えるのは「最近相当期間にわたって販売されていた価格」とされ、目安として**セール開始前8週間のうち過半**（おおむね4週間以上）その価格で販売された実績が求められるとされています（いわゆる「8週間ルール」）。有利誤認と判断されると、措置命令や課徴金の対象になります。
エンジニア視点で危ないのは、**「通常価格」「参考価格」を管理画面の自由入力にする設計**です。販売実績と無関係な数字が入力できてしまうと、運用側の入力ひとつで不当表示が完成します。価格の変更履歴をデータとして持つ、比較対照価格に根拠の入力を必須にするなど、実装側で事故を防げる余地があります。また、「セール終了まで残り◯時間」のカウントダウンが終了後にリセットされて回り続けるような実装も、期間限定と見せかける不当表示のリスクがあります。「この見せ方はセーフか」の判断は個別性が高いので、セールUIは企画段階で法務・専門家に確認してください。
## 確認すべきこと
- [ ] 最終確認画面で必須項目を確認した（商品内容・価格・支払い条件・解約方法）
- [ ] 販売価格が送料を含む総額で表示されている
- [ ] 特商法に基づく表記ページが存在し、事業者名・所在地・電話番号・返品・解約条件が記載されている
- [ ] 特商法に基づく表記ページが最新情報に更新されている
- [ ] フッター等からの表記ページへの導線が存在する
- [ ] 取り消し線・「通常価格」等の比較対照価格に、実際の販売実績があるか確認した（目安：セール前8週間のうち過半の期間）
- [ ] 比較対照価格を管理画面で自由入力できる場合、根拠を確認する運用フローや入力ガードがあるか確認した
- [ ] セール終了カウントダウン等の期間表示が、実際のセール期間と一致しているか確認した
## こんな仕様が出たらアラート
- 通販サイト・ECサイトの購入フローを実装する（単品購入も対象）
- 最終確認画面のリニューアル・A/Bテスト（必須表示が消えていないか）
- 特商法に基づく表記ページがない・更新されていない
- 「通常価格 → セール価格」の取り消し線UI・割引率バッジを実装する
- 管理画面に「通常価格」「参考価格」の自由入力フィールドを追加する
- セール終了までのカウントダウンタイマーを実装する
## あわせて確認
- 定期購入なら追加の表示義務 → [定期購入・サブスクの購入フロー](/features/content/subscription)
- 解約導線の設計 → [解約フローのUI設計](/features/content/cancellation-ui)
- キャンペーンの景品上限・確率表示 → [懸賞・ガチャ・キャンペーン](/products/prize-gacha)
- 投稿・レビューを宣伝に使うなら（ステマ規制） → [UGCの広告・プロモーション利用](/features/content/ugc-promotion)
- 売る商材によっては別の許認可も → [商材から引く](/products)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# 外部サービスのデータ自動収集（スクレイピング）
Source: https://h-kono-it.github.io/legal-check-helper/features/content/scraping
| 項目 | 内容 |
|---|---|
| **疑うべき法令** | 不正アクセス禁止法・不正競争防止法・刑法（業務妨害） |
| **確認タイミング** | 機能企画〜実装時 |
## なにが問題になるか
最も誤解されているのが `robots.txt` の扱いです。`robots.txt` は慣習的なファイルであり、**法的拘束力はありません**。無視することが「即違法」になるわけではありませんが、無視して大量アクセスしたり、利用規約で禁止されているスクレイピングを行ったりした場合は、民事上の損害賠償請求の対象になりえます。「法律違反ではないからOK」と「問題がない」は別の話です。
リスクは大きく3層あります。
- **不正アクセス禁止法**：認証で制限されたシステムに認証を回避してアクセスする行為は禁止。他人のアカウントの認証情報を使ったアクセスは同法違反（3年以下の懲役または100万円以下の罰金）です。自分のアカウントでも、利用規約でボットが禁止されていれば規約違反になります。
- **不正競争防止法**：データベースの内容を体系的に大量取得し同様のサービスを構築する行為は、データ不正取得等（同法第2条第1項第11号・第12号）の問題になることがあります。
- **業務妨害罪（刑法第234条の2）**：悪意がなくても、ループのバグや過度な並列処理で相手サーバーを過負荷にしサービスを停止させると、電子計算機損壊等業務妨害として刑事責任を問われる可能性があります。2010年の**岡崎市立中央図書館事件**では、デフォルト設定のままのクロールプログラムが障害を起こし、開発者が逮捕されました。
なお、「利用規約違反」は民事上の問題（アカウント停止・損害賠償）、不正アクセス禁止法や不正競争防止法の違反は刑事上の犯罪（逮捕・起訴の対象）です。この2つを混同しないことが重要です。
**リクエスト間隔（スリープ）を適切に設けることは、マナーではなく自分を守るための法的防御策です。**
## 確認すべきこと
- [ ] ログインが必要なページへの自動アクセスについて、利用規約と不正アクセス禁止法の観点から確認した
- [ ] 対象サービスの利用規約でスクレイピング・ボットが禁止されていないか確認した
- [ ] スクレイピング処理にリクエスト間隔（sleep/wait）を設定した
- [ ] スクレイピング処理のループ・並列数が過剰にならないよう、コードレビューで確認した
- [ ] スクレイピング処理のUser-Agentに自社名・連絡先を記載した
- [ ] 体系的な大量取得・ビジネス化にあたる場合、不正競争防止法の観点を法務に確認した
## こんな仕様が出たらアラート
- 外部サービスのデータを自動収集して自社サービスに取り込む
- ログインが必要なページへのアクセスを自動化する
- 競合サービスの商品情報・価格情報を定期的に収集する
- 短時間に大量リクエストを送る処理を実装する（リクエスト間隔の設定は必須）
## あわせて確認
- 収集データに個人情報が含まれるなら → [外部CRM・メール配信サービスへのデータ連携](/features/privacy/external-data-sync)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# 定期購入・サブスクの購入フロー
Source: https://h-kono-it.github.io/legal-check-helper/features/content/subscription
| 項目 | 内容 |
|---|---|
| **疑うべき法令** | 特定商取引法（2022年改正） |
| **確認タイミング** | UI設計〜リリース前 |
## なにが問題になるか
通信販売のすべての取引で、購入ボタンを押す直前の画面（**最終確認画面**）には、商品・サービスの内容、販売価格（送料含む総額）、支払い時期・支払い方法、申込みの撤回・解約に関する事項を明確に表示する義務があります。
2022年（令和4年）改正で、**定期購入・サブスクリプション商品の規制が強化**され、定期購入の場合は追加で次の事項も必須になりました。
- **定期購入である旨**
- **支払い総額**（初回だけでなく継続回分も含む）
- **解約方法・解約条件**
「初回無料」「初回980円」を大きく目立つフォントで表示し、「2回目以降は毎月5,980円」を小さな文字や別ページに追いやるUIは、改正後の特商法が禁止する「**不当な表示**」に該当します。消費者庁は2023年以降、こうしたダークパターンに対して行政処分（業務停止命令）を出しています。
この義務は「法務やマーケティングの問題」ではなく、最終確認画面の表示内容・文字サイズ・ボタン配置という**フロントエンドの実装に直結**します。実装者は「この画面の法的要件を満たせているか」を確認できる立場にあります。
## 確認すべきこと
- [ ] 最終確認画面に商品内容・価格（送料含む総額）・支払い時期・支払い方法を明示した
- [ ] 定期購入である旨を最終確認画面に明示した
- [ ] 支払い総額（継続回分含む）・継続金額を最終確認画面に明示した
- [ ] 解約方法・解約条件を最終確認画面に明示した
- [ ] 「初回◯◯円」の表示と継続金額の表示に不当な大小差をつけていない
- [ ] リリース前に、定期購入の旨・継続金額・解約方法の明示を最終確認した
## こんな仕様が出たらアラート
- 定期購入・サブスクリプションの購入フローを実装する
- 「初回◯◯円」のキャンペーン表示を実装する
- 継続金額・解約条件を別ページや小さな文字に追いやるデザイン指示
## あわせて確認
- 単品購入でも最終確認画面の義務はある → [通販・EC購入フローの実装](/features/content/ec-purchase-flow)
- 解約側のUIも規制対象 → [解約フローのUI設計](/features/content/cancellation-ui)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# UGCの広告・プロモーション利用
Source: https://h-kono-it.github.io/legal-check-helper/features/content/ugc-promotion
| 項目 | 内容 |
|---|---|
| **疑うべき法令** | 著作権法・景品表示法（ステマ規制） |
| **確認タイミング** | 機能企画時・マーケティング施策の実施時 |
## なにが問題になるか
### 権利の問題 — 著作権は投稿者のもの
「ユーザーが投稿した写真を広告バナーやキャンペーン画像に使いたい」という要件が出たら、著作権のアラートです。**ユーザーが投稿した写真・テキスト・動画の著作権は、投稿者に帰属します**。「サービスに投稿された」からといって、事業者側が自由に使えるわけではありません。
広告やプロモーション目的での利用には、投稿者からの個別の許諾が必要です。これを避けるため、多くのサービスでは利用規約に「投稿コンテンツについて、サービスの運営・宣伝・改善のために利用する非独占的ライセンスを付与する」という条項を設けています。
ただし、この規約があっても、「想定外の利用」は**許諾の範囲を超えるとみなされるリスク**があります。たとえばアルバム投稿サービスの写真を他社への広告素材として提供するようなケースです。規約の条項が存在すること自体をゴールにせず、「今回の利用は規約で許諾された範囲か」を都度確認してください。
### 見せ方の問題 — 広告なのに広告と分からない（ステマ規制）
権利処理が済んでいても、もうひとつ別のアラートがあります。2023年10月1日に施行された景品表示法の告示、いわゆる**ステマ規制**です。**広告であるにもかかわらず、広告であることを隠す表示**が不当表示になりました。規制の対象になるのは投稿者個人ではなく、**商品・サービスを供給する事業者（広告主）側**です。違反すると措置命令の対象になり、事業者名が公表されます。
UGC・投稿を宣伝に使う文脈では、たとえば次のようなケースが問題になりえます。
- インフルエンサーに対価を渡して投稿を依頼したのに、「広告」「PR」等の表記がない
- レビュー投稿の見返りにポイントやクーポンを渡しているのに、その旨が消費者に分からない
- 従業員・関係者が立場を明かさずに口コミやレビューを書く
- 事業者側が用意・依頼した投稿を、一般ユーザーの自主的な投稿と区別が付かない形で表示する
ユーザーが自発的に書いた純粋な感想は対象外です。分かれ目は**事業者が表示内容の決定に関与したと言えるか**で、この判断は個別性が高く揺らぎます。特典付きの投稿キャンペーンやインフルエンサー施策は、企画段階で法務・専門家に確認してください。
実装起因でステマ状態になることもあります。たとえばSNS投稿の埋め込みUIで「#PR」タグの部分が見切れる・省略される表示になっていると、広告表記が消えた状態で配信されます。表示コンポーネントを作る側でも気づける論点です。
## 確認すべきこと
- [ ] 利用規約に投稿コンテンツの利用（運営・宣伝・改善目的の非独占的ライセンス）条項があるか確認した
- [ ] 今回の利用目的（広告・プロモーション）が規約の許諾範囲に収まっているか法務に確認した
- [ ] 規約の範囲を超える利用（他社への素材提供など）には投稿者から個別の許諾を得た
- [ ] 対価・特典を渡して依頼した投稿に「広告」「PR」等の表記があるか確認した
- [ ] 特典付きのレビュー・投稿キャンペーンがステマ規制に該当しないか、企画段階で法務に確認した
- [ ] 投稿の埋め込み・転載UIで「PR」等の表記が欠落しない実装になっているか確認した
## こんな仕様が出たらアラート
- ユーザーが投稿したコンテンツを広告・マーケティングに使う
- 投稿写真をキャンペーンページ・SNS公式アカウントで紹介する
- 投稿コンテンツを他社に素材として提供する
- インフルエンサーやユーザーに、特典付きで投稿・レビューを依頼するキャンペーンを実施する
- SNS投稿の埋め込み表示を実装する（PR表記が見切れないか）
## あわせて確認
- 素材全般のライセンス → [フリー素材・OSSライブラリの利用](/features/content/assets-oss)
- セール価格の見せ方（二重価格表示） → [通販・EC購入フローの実装](/features/content/ec-purchase-flow)
- キャンペーンの景品上限・確率表示 → [懸賞・ガチャ・キャンペーン](/products/prize-gacha)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# Webフォント・フォントの埋め込み
Source: https://h-kono-it.github.io/legal-check-helper/features/content/webfont
| 項目 | 内容 |
|---|---|
| **疑うべき法令** | 著作権法 |
| **確認タイミング** | 実装時（フォントの配信・同梱を行うとき） |
## なにが問題になるか
**フォントのライセンス**は、エンジニアが見落としやすい落とし穴です。Google Fontsのように商用Webフォントとしての利用が明示されているものは問題ありません。しかし、自前でフォントファイルをサーバーにホストする場合や、アプリにフォントを同梱（エンベッド）する場合は、フォントごとのライセンス確認が必要です。
多くの商用フォントは、用途ごとにライセンスを分けて制御しています。
- デスクトップ用途
- Webフォントとしての配信
- PDFへの埋め込み
- アプリへの同梱
「デスクトップ用途の利用は購入済み」でも「Webサイトでの配信ライセンスは別途必要」というケースはよくあります。**PDF出力機能を持つWebサービス**や、**フォントを同梱するネイティブアプリ**を実装するときは特に注意が必要です。
## 確認すべきこと
- [ ] Webフォントの利用ライセンスを確認した（配信・PDF埋め込み・アプリ同梱はそれぞれ別ライセンスを要することがある）
- [ ] フォントファイルを自前でホストする場合、配信ライセンスを保有しているか確認した
- [ ] PDF出力機能で使うフォントに、PDF埋め込みのライセンスがあるか確認した
- [ ] アプリに同梱するフォントに、同梱（エンベッド）のライセンスがあるか確認した
## こんな仕様が出たらアラート
- Webフォントをサーバーにホストする
- PDF出力機能にフォントを埋め込む
- ネイティブアプリにフォントを同梱する
- 「デスクトップで買ったフォントだからWebでも使える」と判断している
## あわせて確認
- 素材・OSS全般のライセンス → [フリー素材・OSSライブラリの利用](/features/content/assets-oss)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# お金・決済系
Source: https://h-kono-it.github.io/legal-check-helper/features/money
「貯まったポイントに有効期限を設けたい」「ユーザー同士でお金を送り合えるようにしたい」「投げ銭でクリエイターを応援できるようにしたい」。どれも技術的には難しくありません。**お金が絡む機能は、実装の難易度よりも法的なリスクが問題になります。**
しかもこの領域は、後戻りのコストが極端に高いのが特徴です。「他社でも使えるようにする」という一見シンプルな仕様変更が事前登録（審査に数ヶ月）を必要としたり、実装済みの退会フローが払い戻し禁止規定に抵触して作り直しになったりします。仕様が固まった段階でアラートを出せれば、いずれも回避できます。
## こんな言葉が仕様に出たら
- **ポイント** / マイル / コイン / チケット（呼び方は何であれ）
- チャージ / 前払い / 残高
- 送金 / 投げ銭 / ギフト / 換金 / 出金
- 有効期限 / 失効
- 退会時の返金
## 機能別の確認事項
| 実装しようとしている機能 | 主な確認事項 |
|---|---|
| [ポイント発行（購入特典・おまけ含む）](/features/money/point-issuance) | **付与型（購入特典）か、先払いのチャージ型か**を最初に確認。対価性の有無。有効期限を6ヶ月以内にするか6ヶ月超にするか（6ヶ月超は資金決済法の対象）。キャンペーンのおまけ分もチャージと一体で扱われうる |
| [チャージ型電子マネー](/features/money/prepaid-emoney) | **有効期限6ヶ月超なら財務局への届出義務**。基準日（3月末・9月末）の未使用残高が**1,000万円超で供託義務**。未使用残高の総量を集計できるDB設計になっているか |
| [他社でもポイントを使えるようにする](/features/money/third-party-points) | **サービス開始前の事前登録が必要**（自家型は事後届出だが、第三者型は事前登録）。審査に数ヶ月かかるため、仕様変更の段階でリリース計画に織り込む |
| [ユーザー間送金・投げ銭機能](/features/money/p2p-transfer) | **換金・出金できるかが分岐点**。できるなら金融庁への資金移動業登録が必要。「サービス内ポイントだから」は通じない。対価スキームにするなら「対価は何か」を明確にする |
| [退会時のポイント残高返金](/features/money/point-refund) | **現金での払い戻しは原則禁止**（資金決済法第20条）。退会フローに返金ロジックを入れる前に確認する |
## このカテゴリの勘所
**「ポイント」という日本語は2つの別物を指します。** 購入後に付与される特典（付与型）と、ユーザーが先に払い込んだ残高（チャージ型）です。前者と後者では、法的な扱いも経理処理も根本的に違います。仕様を受け取ったら、まずどちらなのかを確認してください。これがこのカテゴリすべての出発点です。
**有効期限6ヶ月が境界線です。** 6ヶ月以内なら資金決済法の適用対象外（供託義務も届出義務もなし）、1日でも超えると適用対象になります。供託のキャッシュフロー負担を避けるか、ユーザーの利便性を取るかはビジネス判断なので、法務・経営層を含めて決める話です。
**換金できるかどうかが、もう一つの境界線です。** ユーザー間でやりとりできるだけなら送金にはあたらなくても、それを現金やギフト券に換えられるなら実質的な送金とみなされうる。「将来的に換金できるようにしたい」という要件が出た段階で法務に相談してください。
## あわせて確認
- DB設計に入るなら → [残高DB設計](/features/accounting/balance-db)（経理と照合できる設計になっているか）
- 企画段階の確認漏れは → [フェーズ1：機能企画・要件定義時](/checklist/phase-1-planning)
- 運用中の定期確認は → [フェーズ5：運用継続中](/checklist/phase-5-operation)（供託判定・失効処理）
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# ユーザー間送金・投げ銭機能
Source: https://h-kono-it.github.io/legal-check-helper/features/money/p2p-transfer
| 項目 | 内容 |
|---|---|
| **疑うべき法令** | 資金決済法（資金移動業） |
| **確認タイミング** | 機能企画・要件定義時 |
## なにが問題になるか
「お金を預かって他人に送る」行為は本来は銀行免許が必要な業務であり、銀行以外が行うには**資金移動業の登録**（金融庁）が必要です。登録なしで資金移動業を行うことは違法です。
分岐点は**換金・出金できるかどうか**です。ユーザーAがユーザーBにポイントを送り、Bがそれを現金やギフト券に換えられるなら、実質的な送金とみなされる可能性があります。「お金ではなくサービス内ポイントだから大丈夫」は通じません。
資金移動業は送金上限額で3区分されます。
| 区分 | 上限 | 備考 |
|---|---|---|
| 第一種 | 100万円超 | 最も規制が厳しい |
| 第二種 | 1回100万円以下 | 一般的な送金サービス |
| 第三種 | 1回1万円以下 | 少額特化。参入しやすい区分 |
なお、世の中の投げ銭風サービスの多くは「ユーザー→プラットフォームへの対価性ある購入」（例：メッセージを目立たせる機能の購入、限定コンテンツへのアクセス権）に組み替えることで送金に該当しない構造をとっています。ただしこの対価スキームも万能ではなく、対価の実態が薄いと実質的な資金移動とみなされるリスクがあります。
## 確認すべきこと
- [ ] ユーザー間の送金・換金機能の有無を確認した（あれば資金移動業のアラートを出した）
- [ ] ポイント・残高を現金・ギフト券・暗号資産などに換金できるかを確認した
- [ ] 「将来的に換金できるようにしたい」という要件の段階で法務・弁護士に相談した
- [ ] 投げ銭を対価スキームにする場合、「対価は何か」を明確にして法務に確認した
## こんな仕様が出たらアラート
- ユーザー間でポイントや金額を送り合える
- クリエイターへの投げ銭機能
- ポイントを現金・ギフト券・仮想通貨などに換金できる
## あわせて確認
- 退会時の返金要件 → [退会時のポイント残高返金](/features/money/point-refund)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# ポイント発行（購入特典・おまけ含む）
Source: https://h-kono-it.github.io/legal-check-helper/features/money/point-issuance
| 項目 | 内容 |
|---|---|
| **疑うべき法令** | 資金決済法（前払式支払手段） |
| **確認タイミング** | 機能企画・要件定義時 |
## なにが問題になるか
エンジニアから見ればユーザーテーブルに `point_balance` カラムを足すだけの機能ですが、ポイントの性質によっては**資金決済法の「前払式支払手段」に該当**します。次の3要件（資金決済法第3条）を満たすと該当する可能性が高くなります。
1. 金額または数量が記載・記録されている
2. **対価を得て発行**されている
3. 商品・サービスの代価の弁済に使用できる
「購入金額に応じて付与され、次の購入時に使える」ポイントはこの3要件を満たしえます。一方、会員登録やレビュー投稿への報酬ポイントは対価性が薄く、該当しないケースもあります。ただし両方の付与パターンが混在する設計は判断が難しくなります。
**「おまけポイント」も油断できません。**「1万円チャージで1,000ポイントおまけ」の場合、おまけ分も「対価を得て発行されたもの」に含まれると解釈されるのが一般的です。「無料で配るから法律は関係ない」は危険です。
また、有効期限を**6ヶ月以内**に設定すると資金決済法の適用対象外になります（第4条第2号）。供託コストとユーザー体験のトレードオフはビジネス判断なので、法務・経営層を巻き込んで決めるべき話です。
経理面では、付与型ポイントの扱いに2つのアプローチがあります。**利用時に販促費として計上する**方法（付与時点の仕訳が不要で実装はシンプルだが、将来の費用発生を予測しにくい）と、**付与時に負債として計上する**方法（会計的な正確さは高いが、付与済み・未使用のポイント総量を常に正確に把握できるDB設計が必要）です。どちらを採用するかで**DBに必要なログが変わる**ため、実装前に経理方針の確認が必要です。さらに、ポイントを代金充当に使えるようにする場合は「値引き」扱いか「決済手段」扱いかで税処理が変わります。エンジニアが単独で決める話ではなく、仕様が出た段階で経理・税務の担当者を巻き込んでください。
## 確認すべきこと
- [ ] ポイントの性質を確認した（付与型の購入特典か、先払いのチャージ型か）
- [ ] 対価性の有無を確認した（購入・チャージに紐づくか、無償の報酬か）
- [ ] おまけ・キャンペーンポイントがチャージと一体で扱われる可能性を確認した
- [ ] 有効期限を6ヶ月以内にするか6ヶ月超にするかを明示した（6ヶ月超は資金決済法の対象）
- [ ] 経理方針を確認した（付与時に負債計上か、利用時に販促費計上か）
## こんな仕様が出たらアラート
- ポイントを発行する（購入や行動への報酬として）
- キャンペーンでおまけポイントを付与する
- ポイントを商品・サービスの代金に充当できる
- 有効期限を6ヶ月超に設定する
## あわせて確認
- チャージ機能があるなら → [チャージ型電子マネー](/features/money/prepaid-emoney)
- DB設計は → [残高DB設計](/features/accounting/balance-db)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# 退会時のポイント残高返金
Source: https://h-kono-it.github.io/legal-check-helper/features/money/point-refund
| 項目 | 内容 |
|---|---|
| **疑うべき法令** | 資金決済法第20条（払い戻しの原則禁止） |
| **確認タイミング** | 機能企画・要件定義時 |
## なにが問題になるか
見落とされがちですが、前払式支払手段には**現金での払い戻しを原則禁止する規定**があります（資金決済法第20条第1項）。ユーザーが「退会するので残りのポイントを銀行口座に返金してほしい」と言っても、法律上は安易に応じられません。
例外として認められるのは、サービス終了時のような特別な事情がある場合などに限られます。
これはシステム設計上の問題に直結します。「退会フローに残高返金ロジックを入れる」という仕様を実装してしまってから「それは法律違反です」となると、**退会フローそのものの作り直し**が必要になります。
## 確認すべきこと
- [ ] チャージ型残高の現金払い戻しフローを設計していないか確認した（原則禁止）
- [ ] 退会時の残高の扱い（失効・据え置き等）を法務と確認した
- [ ] サービス終了時の払い戻し手続き（例外ケース）を把握している
## こんな仕様が出たらアラート
- 退会時に残高を現金で返金する
- ポイントを銀行口座に出金できるようにする（→ [資金移動業](/features/money/p2p-transfer)の論点にもなる）
## あわせて確認
- 退会機能そのものの設計 → [退会機能の実装](/features/privacy/account-deletion)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# チャージ型電子マネー
Source: https://h-kono-it.github.io/legal-check-helper/features/money/prepaid-emoney
| 項目 | 内容 |
|---|---|
| **疑うべき法令** | 資金決済法（前払式支払手段） |
| **確認タイミング** | 機能企画・要件定義時 |
## なにが問題になるか
ユーザーが先に金銭を払い込み、その残高をサービス内で使う仕組みは、資金決済法の**前払式支払手段**の典型例です。有効期限の設定によって義務の重さが大きく変わります。
| 有効期限の設定 | 法的分類 | 供託義務 | 財務局への届出 |
|---|---|---|---|
| 6ヶ月以内 | 適用除外 | なし | 不要 |
| 6ヶ月超 | 適用対象 | あり（残高1,000万円超で） | 必要 |
適用対象になった場合、毎年**3月末と9月末**の基準日時点で未使用残高が**1,000万円を超えると、その半額以上を法務局に供託**する義務が発生します（資金決済法第14条）。無料配布したポイントが積み上がり、気づかないうちに基準を超えていたというケースは、スタートアップでも現実に起こります。
注意点として、**1日でも6ヶ月を超えると適用対象**になります。「半年と少し」に設定したつもりが意図せず規制対象になっていた、が起こりえます。
経理面では、チャージ時点のお金は会社の収益ではなく**前受金**（負債）であり、使われた時点で売上認識します。決済手段の扱いなので、1,000円の商品を電子マネーで払っても売上は1,000円です。
## 確認すべきこと
- [ ] 有効期限を6ヶ月以内にするか6ヶ月超にするかを明示した
- [ ] 6ヶ月超の場合、財務局への届出スケジュールを法務と確認した
- [ ] 未使用残高の総量を集計できるクエリまたはサマリーテーブルを設計した（供託義務の判定用）
- [ ] 残高の変化をイベント履歴テーブルで記録する設計になっている
- [ ] チャージを前受金として扱う経理処理を経理担当と確認した
## こんな仕様が出たらアラート
- プリペイドチャージ機能を実装する
- 有効期限を6ヶ月超に設定する（適用対象になる）
- キャンペーンでチャージ額におまけを付与する（おまけ分も一体で扱われうる）
## あわせて確認
- 他社でも使えるようにするなら → [他社でも使えるポイント](/features/money/third-party-points)（事前登録が必要）
- 残高の返金要件が出たら → [退会時のポイント残高返金](/features/money/point-refund)（原則禁止）
- DB設計は → [残高DB設計](/features/accounting/balance-db)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# 他社でもポイントを使えるようにする
Source: https://h-kono-it.github.io/legal-check-helper/features/money/third-party-points
| 項目 | 内容 |
|---|---|
| **疑うべき法令** | 資金決済法（第三者型前払式支払手段） |
| **確認タイミング** | 機能企画・要件定義時（**仕様変更時も**） |
## なにが問題になるか
前払式支払手段は、自社サービスでのみ使える**自家型**と、他社の加盟店でも使える**第三者型**に分類され、義務の重さが大きく違います。
- **自家型**：未使用残高が1,000万円を超えてから**事後的に届け出る**
- **第三者型**：**サービス開始前の事前登録**が必要。登録には審査があり、**数ヶ月かかることもある**
危険なのは、最初は自家型で設計したポイントに、あとから「提携先の店舗でも使えるようにしよう」という要件が加わるケースです。一見シンプルな仕様変更が、手続きのタイミングを「事後届出」から「事前登録」へ根本的に変え、**リリース日程を根底から覆す**可能性があります。
## 確認すべきこと
- [ ] ポイント・残高が使える範囲を確認した（自社のみか、他社加盟店でも使えるか）
- [ ] 他社利用を計画している場合、**実装に入る前に**法務へ確認した（事前登録が必要）
- [ ] 登録審査の所要期間（数ヶ月）をリリース計画に織り込んだ
- [ ] 仕様変更で「他社でも使える」に変わるとき、法務相談を挟むフローがある
## こんな仕様が出たらアラート
- 「提携先・加盟店でもポイントを使えるようにしたい」
- グループ会社間でポイントを共通化したい
- 既存の自家型ポイントの利用範囲を広げる仕様変更
## あわせて確認
- 前提となる前払式支払手段の話 → [チャージ型電子マネー](/features/money/prepaid-emoney)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# 人・組織系
Source: https://h-kono-it.github.io/legal-check-helper/features/people
「SlackでA社のエンジニアに直接タスクを振ってもいいですか？」「外注先のGitHubにコードレビューのコメントを入れても大丈夫ですか？」「フリーランスに頼んでいるので書面は省略していいですか？」。技術的な話ではないため「そういうのは人事や法務が考えること」と思われがちです。**しかしこのカテゴリで問われるのは、エンジニア自身の日々のふるまいそのものです。**
そして厄介なのは、**証拠が自動的に残り続ける**ことです。Slackのメッセージ、GitHubのコメント、Jiraのチケットアサイン履歴は、「誰が誰にどんな指示を出していたか」を日付つきで記録しています。「口頭で指示していただけです」が通じた時代とは違い、偽装請負の調査や訴訟では、これらのログがそのまま有力な証拠になります。しかも他のカテゴリと違って、リリース前に気づいて直せるものではありません。問題のある運用を続けた履歴は、後から消せません。
## こんな状況が現場で起きていたら
- 発注者側の社員が、業務委託エンジニアに**直接**Slack・メールで作業指示を出している
- 発注者側のPMが、Jira・GitHubで業務委託エンジニアにタスクを直接アサインしている
- スクラムのデイリーで、発注者側が「誰が何をやるか」を個別に割り振っている
- コードレビューで、命名規則や実装スタイルを逐一指定している
- 常駐先の勤怠管理・就業規則に、業務委託のエンジニアが従っている
- 朝礼・勉強会・清掃など、業務と無関係な活動への参加を求めている
- 「まず手を動かして」と、発注書なしで作業を開始させている
- 検収から支払いまでが60日を超えている／仕様変更を無償でやらせようとしている
## 機能別の確認事項
| 実装しようとしている機能 | 主な確認事項 |
|---|---|
| [SES・業務委託エンジニアへの指示](/features/people/ses-instruction) | **「何を作るか」の合意はよく、「どう作るか・いつ作業するか」の細かい管理が指揮命令になりうる**。指揮命令の経路（発注者→受託会社の責任者→エンジニア）を設計したか。Slackのチャンネル設計もその経路に沿っているか。**コードレビューは成果物の品質・仕様適合の指摘なら許容**、実装スタイルへの逐一指示は問題。スクラムのタスクアサインは受託側の責任者が行う運用か |
| [フリーランス・外注先への発注](/features/people/freelance-order) | **作業開始前に書面（メール・チャットの文面でも可）を交付**したか。報酬額と支払期日を発注時に明示したか。**受領から60日以内**に支払うフローになっているか。仕様変更を追加発注（追加報酬）として処理するか。**個人への発注ならフリーランス保護新法が資本金不問で適用**される |
## このカテゴリの勘所
**「何を作るか」と「どう作るか」の間に線があります。** 成果物・仕様・納期の合意（「このAPIを今月末までに実装してください」）は業務委託として自然な範囲です。一方、「どのように作るか」「いつ・どこで作業するか」の細かい管理は指揮命令に該当するリスクが高まります。コードレビューで言えば、「セキュリティ要件を満たしていない」「計算量が仕様の上限を超えている」は成果物の受け入れ判断として許容されますが、「この変数名は命名規則に従え」「今すぐこの行をこう書き換えろ」は作業プロセスへの介入です。スクラムも同じで、バックログの優先順位を伝えるところまでが「何を作るか」、「誰がどのタスクをいつやるか」の決定は受託側の責任者の仕事です。
**「フリーランスだから問題ない」は誤りです。** 偽装請負のリスクは、法人のSES会社との契約に限りません。個人のフリーランスへの業務委託でも同様で、発注者が作業方法・作業時間・優先順位を細かく指示している状態は、実質的な雇用関係に近いとみなされる可能性があります。契約の相手が会社か個人かは、この論点では関係ありません。
**適用範囲は下請法とフリーランス保護新法で違います。** 下請法は発注者・受注者双方の資本金規模の組み合わせで適用が決まりますが、2024年11月施行のフリーランス保護新法は、**個人（従業員を持たない事業者）への発注であれば資本金に関係なく全員が対象**です。「うちは小さい会社だから下請法の対象外」だとしても、個人に発注するならフリーランス保護新法からは逃れられません。書面交付・60日以内の支払い・代金の事後削減の禁止は、どちらの法律でも共通して求められます。
## あわせて確認
- 支払い期日管理のシステム化は → [外注費の支払い管理](/features/accounting/outsourcing-payment)（受領日の記録と60日アラートの自動化）
- 体制を決める段階の確認漏れは → [フェーズ1：機能企画・要件定義時](/checklist/phase-1-planning)
- 日々の発注・契約管理は → [フェーズ3：実装時](/checklist/phase-3-implementation)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# フリーランス・外注先への発注
Source: https://h-kono-it.github.io/legal-check-helper/features/people/freelance-order
| 項目 | 内容 |
|---|---|
| **疑うべき法令** | 下請法・フリーランス保護新法（2024年11月施行） |
| **確認タイミング** | 発注時・支払いフロー設計時 |
## なにが問題になるか
購買部門を通さず「とりあえずSlackで進めておいてください」と伝える**口頭発注**は、下請法と2024年11月施行のフリーランス保護新法により、法的に明確なアウトになっています。
適用範囲に注意してください。下請法は発注者・受注者双方の資本金規模の組み合わせで適用が決まりますが、フリーランス保護新法は**個人（従業員を持たない事業者）への発注であれば資本金に関係なく全員が対象**です。「個人に頼んでいるから書面は省略でいい」はどちらの法律でも通用しません。
守るべきは次の**3大鉄則**です。
1. **発注時に「書面」を渡す（後出し厳禁）**：作業開始前（発注時）に、業務内容・報酬額・支払期日を記した書面（メールやチャットの文面でも可）を渡す義務があります。「仕様が固まってから発注書を出す」運用は違法です。「とりあえず動いて」はその瞬間にアラート対象です。
2. **報酬は「受領から60日以内」に払う**：「検収が終わってから翌々月末払い」という条件は、受け取りから支払いまでが60日を超えることがあり、明確な違反です。
3. **勝手に「値引き・やり直し」をさせない**：「予算が削られたから10％引いて」「仕様変更したけど追加料金なし」は、買いたたきや不当な代金減額として禁止されています。仕様変更は「追加発注（＝追加報酬が発生する）」になるかを常に意識してください。
フリーランス保護新法ではさらに義務が広がっています。
- **募集広告のルール**：XやWantedlyで「一緒に開発してくれるエンジニア募集」と投稿するときも対象。虚偽の記載をしてはならず、内容を最新の状態に保つ義務があります（同法第12条）
- **育児・介護への配慮義務**：6ヶ月以上の継続的な契約関係にあるフリーランスから申し出があった場合、育児や介護と両立できるよう配慮する義務があります
## 確認すべきこと
- [ ] 外注先・フリーランスへの発注書を作業開始前に交付した（メール・チャットの文面でも可）
- [ ] 報酬額と支払い期日を発注時に明示した
- [ ] 検収から支払いまでの期間が受領から60日以内に収まる支払いフローになっている
- [ ] 仕様変更が発生した場合、追加発注（追加報酬が発生する）として処理するかを確認した
- [ ] 下請法の資本金区分と、フリーランス保護新法の適用（個人への発注は規模不問）を確認した
- [ ] X・Wantedlyなどの募集投稿の内容が最新の状態に保たれている
## こんな仕様が出たらアラート
- 「まず手を動かして」と発注書なしで作業を開始させている
- 「金額は後で相談しましょう」と報酬を決めずに発注している
- 検収から支払いまでの期間が60日を超えている
- 仕様変更による追加作業を無償でやらせようとしている
- XやWantedlyの募集投稿の内容が古いまま放置されている
## あわせて確認
- 発注後の指示の出し方 → [SES・業務委託エンジニアへの指示](/features/people/ses-instruction)
- 支払い期日管理のシステム化 → [外注費の支払い管理](/features/accounting/outsourcing-payment)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# SES・業務委託エンジニアへの指示
Source: https://h-kono-it.github.io/legal-check-helper/features/people/ses-instruction
| 項目 | 内容 |
|---|---|
| **疑うべき法令** | 労働者派遣法（偽装請負） |
| **確認タイミング** | 機能企画・要件定義時（体制設計時）・日々の運用 |
## なにが問題になるか
SESは「業務の成果や役務の提供に対して報酬を払う」業務委託契約であり、**エンジニア個人の労働力を時間単位で買う契約ではありません**。契約上は業務委託なのに、実態として発注者がエンジニアに直接指揮命令を行っている状態が**偽装請負**です。偽装請負と認定されると、発注者側は無許可の派遣受け入れとして、受注者側は無許可の派遣業として、**双方が行政指導・罰則の対象**になりえます。
線引きの基本は「**何を作るか**」と「**どう作るか**」の区別です。
- 許容される範囲：成果物・仕様・納期など「何を作るか」の合意（「このAPIを今月末までに実装してください」「仕様書はこちらです」）
- リスクが高まる範囲：「どのように作るか」「いつ・どこで作業するか」の細かい管理
**コードレビューの線引き**：「セキュリティ要件を満たしていないため修正が必要」「計算量が仕様の上限を超えている」といった成果物の品質・仕様への適合を確認する指摘は許容されます（成果物の受け入れ判断）。問題になるのは「この変数名はこの命名規則に従え」「今すぐこの行をこう書き換えろ」といった作業プロセスや実装スタイルへの逐一指示です。
**スクラムは構造的に偽装請負になりやすい**：デイリースクラムで発注者側のスクラムマスタが「AさんはこのIssue、BさんはそのIssue」と個別にタスクをアサインすると指揮命令に該当します。許容されるのは「バックログの優先順位を伝える（何を作るか）」まで。「誰がどのタスクをいつやるか」の決定は受託側の責任者が行うべきです。
そして現代の開発現場では、Slackのメッセージ・GitHubのコメント・Jiraのチケットアサイン履歴がすべてログとして残り、**「誰が誰にどんな指示を出していたか」の有力な証拠**になります。「口頭で指示していただけです」が通じた時代とは違います。
なお、これは法人のSES会社に限らず、**個人のフリーランスへの業務委託でも同様**です。「フリーランスだから問題ない」という理解は誤りです。
## 確認すべきこと
- [ ] SES・業務委託エンジニアが参画する場合、指揮命令の経路（発注者→受託会社の責任者→エンジニア）を設計した
- [ ] Slackのチャンネル設計が「発注者↔受託会社の責任者」「受託会社の責任者↔エンジニア」の経路を意識した構成になっている
- [ ] 成果物・仕様を契約・仕様書レベルで明確に合意し、日々の作業方法には発注者側が立ち入らない運用になっている
- [ ] コードレビューの指摘が「成果物の品質・仕様への適合確認」の範囲に収まっている
- [ ] スクラムのタスクアサインを受託側の責任者が行う運用になっている
## こんな仕様が出たらアラート
- 発注者側の社員が業務委託エンジニアに直接Slack・メールで作業指示を出している
- 発注者側のPMがJira・GitHub・Backlogなどで業務委託エンジニアにタスクを直接アサインしている
- スクラムのデイリーで発注者側が「誰が何をやるか」を個別に割り振っている
- GitHubのコードレビューで実装スタイル・命名規則など作業プロセスを細かく指定している
- 常駐先の就業規則・勤怠管理に業務委託のエンジニアが従っている
- 社内勉強会・朝礼・清掃など業務と無関係な活動への参加を求めている
## あわせて確認
- 発注書・支払いのルール → [フリーランス・外注先への発注](/features/people/freelance-order)
{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}
---
# 通信・プライバシー系
Source: https://h-kono-it.github.io/legal-check-helper/features/privacy
「ユーザー同士がメッセージを送り合えるようにしたい」「サポートチームが問い合わせ内容を確認できるようにしたい」「退会したユーザーのデータを後から参照できるよう論理削除にしておきたい」。いずれも開発現場でよく出てくる要件です。しかしこれらはすべて、**「通信の秘密」や「個人情報の取り扱い」に関わる法的なリスクを持っています。**
この領域は、実装が完了してから問題が発覚すると、機能そのものの作り直しが必要になります。管理画面のアクセス制御も、退会時に何を消して何を残すかも、テーブルをどう分けるかという設計判断に食い込むからです。**通信とプライバシーは、設計段階で決まります。**
## こんな言葉が仕様に出たら
- DM / チャット / メッセージ / 非公開グループ
- 管理画面から閲覧 / 監視 / 通報対応
- タグ / SDK / 計測 / アナリティクス（**1行足すだけでも対象**）
- 退会 / 論理削除 / `deleted_at` / データ保持
- 外部連携 / CRM / メール配信 / 海外サーバー
## 機能別の確認事項
| 実装しようとしている機能 | 主な確認事項 |
|---|---|
| [DM・チャット機能](/features/privacy/dm-chat) | **サービスの主機能か、付随機能か**で届出の要否が変わる（2023年6月施行の改正電気通信事業法）。メッセージが中心なら届出が必要な可能性が高く、問い合わせチャット等の付随機能なら不要とされるケースもある。**付随機能として始まってもSNS的な比重が増えると途中から必要な状態に変わる**ため、再判定するフローを持つ |
| [管理者によるDM閲覧機能](/features/privacy/admin-dm-viewing) | 業務上の理由があっても、**同意なき閲覧は通信の秘密（第4条）の侵害になりうる**。規約末尾の包括同意だけでは不十分とする見解が有力。**「原則閲覧不可・例外的に閲覧可能な手続きを設ける」構造をシステムで強制する**。閲覧操作の監査ログを残す |
| [アナリティクスタグ・SDKの埋め込み](/features/privacy/analytics-sdk) | 2023年改正の**外部送信規律**により、**「どこの誰に何を送っているか」の通知・公表義務**がある。プライバシーポリシーやCookieポリシーに送信先のサービス名・提供情報・目的を記載する。**タグマネージャー経由の追加は把握漏れが起きやすい** |
| [退会機能の実装](/features/privacy/account-deletion) | **論理削除は「削除」にならない**。2022年改正で「保有の必要がなくなった場合」も消去請求（第35条）の対象に。**消すデータ（識別子）と残すデータ（法定保存義務のある取引記録）を別テーブル・別ストレージに分離**し、退会時に識別子を `NULL` でマスキングする |
| [外部CRM・メール配信サービスへのデータ連携](/features/privacy/external-data-sync) | **第三者提供（第27条）に該当しうる**。**「同意取得」か「委託」かを連携ごとに整理**する（委託なら管理・監督義務が生じる）。**デバッグログやテストで本番データを外部に渡す経路が見落としやすい**。海外サーバーなら移転先の国名等の公表が必要 |
## このカテゴリの勘所
**論理削除は「削除」ではありません。** `deleted_at` にフラグを立てるだけの設計は、参照整合性の維持や誤削除からの復元という点で実務上は合理的です。しかし個人情報保護法の観点では、データはまだそこに残っています。退会したユーザーから「私のデータが残っているのでは？」と指摘されたとき、法的な根拠を持って説明できるかが問われます。
**求められているのは物理削除ではなく、「特定の個人を識別できなくなること」です。** ここを取り違えると「全部消すしかない」という極論になりますが、そうではありません。識別子カラム（メールアドレス・氏名・住所など）をマスキングし、法的な保存義務があるデータ（電子帳簿保存法による取引記録の7年保存など）は別テーブルに分けておく。これが現実的な落としどころです。個人を識別できない形に加工すれば、それはもはや個人情報ではないため、分析目的での保持もできます。
**「タグを1行入れるだけ」に法的な意味があります。** フロントエンドエンジニアが `