検証の門を通った、その後の話
前回のJ-06では、信頼境界という門で入力を検査し、検証済みのデータだけを内側へ通す仕組みを学びました。この講義は、その門を通った後の話です。検証が「形が正しいか」を見る仕事だとすると、業務ロジックは「そのうえで、会社のルールに照らしてどう扱うか」を判断する層です。サーバーの5責務、J-01で挙げた5つのうち、二番目にあたる中心的な仕事を、ここで具体的に見ていきます。
このスライドのポイント
- 前回J-06: 信頼境界という門で入力を検査し、検証済みのデータだけを内側へ通した
- この講義: その門を通った後、データをどう扱うかを判断する層
- サーバーの5責務（J-01）の二番目「業務ルールの適用」にあたる中心的な仕事
定義: 会社固有の判断規則のコード化
業務ロジックとは、そのサービスや会社に固有の判断規則をコードにしたものです。たとえば「1万円以上の経費は上長の承認が必要」「月締めのあとは修正できない」といった規則が、これにあたります。作る・読む・変える・消す、というデータの出し入れ、いわゆるCRUDだけのアプリと、実際の業務アプリを分けるのが、この層です。E-05で学んだ条件分岐が、いよいよ会社の言葉で書かれる場所だと考えてください。
このスライドのポイント
- 業務ロジック = そのサービス・会社に固有の判断規則をコードにしたもの
- 例: 「1万円以上の経費は上長の承認が必要」「月締めのあとは修正できない」
- 作る・読む・変える・消す（CRUD）だけのアプリと、実際の業務アプリを分けるのがこの層
- E-05で学んだ条件分岐が、会社の言葉で書かれる場所
なぜ必要か——ルールは人間しか知らない
この層を意識しないと、どうなるでしょうか。AIに「経費アプリを作って」とだけ頼むと、多くの場合、入力を保存して一覧を表示するだけの、ルールのないアプリができあがります。承認の要否も、締め後の扱いも、そこには入っていません。会社ごとのルールは、人間しか知りません。だからこそ、A-07で見た「AIに渡す情報」のなかで、最も重要な部類に入るのです。渡さなければ、AIには決して作れません。
このスライドのポイント
- 「経費アプリを作って」とだけ頼むと、保存して一覧表示するだけのルールなしアプリになりがち
- 承認の要否も、締め後の扱いも、そこには入っていない
- 会社ごとのルールは人間しか知らない = A-07で渡すべき情報のうち最重要の部類
- 渡さなければ、AIには決して作れない
構造: 3層に分けて置く
業務アプリのサーバーは、3つの層に分けて考えると見通しがよくなります。ひとつめは検証、J-06で学んだ信頼境界で、データの形が正しいかを見ます。ふたつめが業務ロジックで、会社のルールに照らして判断します。みっつめが保存で、データを永続化しますが、その仕組みの詳細はカテゴリLで扱います。この3つを混ぜずに分けておくほど、ルールが変わったときに直す場所が一箇所で済み、変更に強くなります。
このスライドのポイント
- 検証（J-06）: データの形が正しいか
- 業務ロジック（この層）: 会社のルールに照らして判断する
- 保存（カテゴリL）: データを永続化する。仕組みの詳細はカテゴリLで扱う
- 3つを混ぜず分けておくほど、ルール変更時に直す場所が一箇所で済み、変更に強い
具体例: ひとつのルールが一本につながる
「1万円以上は上長承認へ」という、ひとつのルールを追いかけてみましょう。このルールは、A-08で「生成の前に決めること」として決め、E-05で条件分岐の書き方として学び、H-03の遷移図では申請から承認への流れとして描きました。そして、いまこのJ-07で、ついにサーバーのコードになります。講座のあちこちで別々に見えていた話が、この業務ロジックの層で一本につながる瞬間です。
このスライドのポイント
- 追いかけるルール: 「1万円以上は上長承認へ」
- A-08: 生成の前に決めること、として決めた
- E-05: 条件分岐の書き方として学んだ
- H-03: 遷移図で、申請から承認への流れとして描いた
- J-07: いま、サーバーのコードになる——縦串が一本につながる瞬間
技術サンプル: ルールを1つの関数に隔離する
サンプルを見てみましょう。種別はコード、目的は、承認が必要かどうかを判断する業務ロジックを、1つの関数に隔離することです。読み方の要点は2つです。ひとつは、判断の規則がneedsApprovalという1つの関数の中だけに書かれていること。もうひとつは、だからルールが変わっても、直すのはこの関数だけで済むということです。AIへの質問例は、コードから業務ルールを逆算して日本語にしてもらい、自分の認識と合っているか確かめる問いです。
このスライドのポイント
- 種別: code
- 目的: 承認が必要かどうかの判断（業務ロジック）を、1つの関数に隔離する
- サンプル本体:
混同しやすい: 検証と業務ロジック
検証と業務ロジックは、どちらもハンドラーの中で行われるため、混同しやすい2つです。違いはこうです。マイナスの金額を弾くのは検証です。データの形として、そもそもありえないからです。一方、1万円を境に承認の要否を分けるのは業務ロジックです。形は正しいけれど、会社の判断が必要だからです。この線引きができると、AIが書いたコードのどこを直すべきかも、はっきりします。
このスライドのポイント
- どちらもハンドラーの中で行われるため混同しやすい
- マイナスの金額を弾く = 検証（データの形としてありえない）
- 1万円を境に承認の要否を分ける = 業務ロジック（形は正しいが、会社の判断が必要）
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIが作った業務ロジックは、会社の本当のルールとずれていることがあります。そこで、「このアプリの業務ルールを、コードから逆算して日本語の箇条書きにしてください」とAIに定期的に頼み、自分の認識と突き合わせます。これはA-06で学んだ、もっともらしい間違いを未然に防ぐ習慣でもあります。ルールは目に見えにくいからこそ、言葉にして確かめることが大切です。
このスライドのポイント
- AIが作った業務ロジックは、会社の本当のルールとずれていることがある
- 定期的に「業務ルールをコードから逆算して日本語の箇条書きに」とAIへ依頼し、自分の認識と突き合わせる
- これはA-06で学んだ、もっともらしい間違いを未然に防ぐ習慣
- AIへの質問例: 「このコードが実行している業務ルールを箇条書きにしてください。抜けや思い違いはありませんか」
一問一答とまとめ
最後に一問一答です。「1万円以上は上長承認、という規則をコード化した層を何と呼ぶでしょうか」。……答えは、業務ロジックです。30秒でまとめます。業務ロジックは会社固有の判断規則のコード化であり、検証や保存とは分けて置くほど変更に強くなります。そのルールは人間しか知らないため、AIに渡し、逆算で確かめ続けることが要点でした。次回のJ-08では、処理が失敗したときの振る舞い、例外処理とエラー応答へ進みます。関連資料は「業務整理質問集100」「AIアプリ要件定義シート」です。
このスライドのポイント
- 一問一答: 「1万円以上は上長承認、という規則をコード化した層は？」→ 業務ロジック
- 30秒まとめ: 業務ロジック = 会社固有の判断規則のコード化。検証・保存とは分けて置くほど変更に強い。ルールは人間しか知らないので、渡し、逆算で確かめ続ける
- 次回: J-08 例外処理とエラー応答
- 関連資料: 「業務整理質問集100」「AIアプリ要件定義シート」
