前回の続き——正常な流れの、その先へ
前回のJ-07では、会社固有の判断規則をコード化する業務ロジックを扱いました。検証を通り、業務ルールで判断し、保存へ進む、という正常な流れをここまで追ってきました。しかし実際のサーバーでは、通信が切れる、保存先が応答しない、想定外の値が届く、といった失敗が必ず起きます。この講義は、その失敗が起きたときにサーバーがどう振る舞うべきかを決める回です。
このスライドのポイント
- J-07: 会社固有の判断規則をコード化する「業務ロジック」を学んだ
- 検証（J-06）→業務ルール（J-07）→保存、という正常な流れを追ってきた
- 実際のサーバーでは、通信断・保存先の無応答・想定外の値など、失敗が必ず起きる
- この講義: 失敗が起きたときの振る舞いを決める
例外処理とエラー応答の定義
まず言葉を定義します。例外処理とは、処理の途中で起きた失敗を受け止める仕組みのことです。F-06で学んだtry・catchの、サーバー側での使い方だと考えてください。そしてエラー応答とは、その失敗をD-06のステータスコードで呼び出し側へ返すことです。400番台は依頼側の誤り、500番台はこちら側の失敗を表します。ここで最も大切な原則は、内部にはログで詳しく記録し、外部へはコードと簡潔な説明だけを返す、という向きの使い分けです。
このスライドのポイント
- 例外処理＝処理中の失敗を受け止める仕組み（F-06のtry・catchのサーバー版）
- エラー応答＝失敗をD-06のステータスコードで返すこと（400系=依頼側／500系=こちら側）
- 原則: 内部にはログで詳細を記録、外部へはコードと簡潔な説明のみ
- 内部構造・失敗の詳細・データベースへの問い合わせ内容などは外へ出さない
なぜ必要か——2つの事故を防ぐ
この原則を知らないと、AIが生成しがちな危険なコードを見抜けません。よくあるのは、失敗の詳細をそのまま応答に含めてしまうコードです。これでは、内部の構造やデータの置き場所を、外部の相手に教えてしまうことになります。逆に、失敗を受け止めたまま何もしない、いわゆる握りつぶしも危険です。この場合は記録が残らず、後から原因を調べることが不可能になります。防ぐべき事故は、この漏えいと調査不能の2つです。
このスライドのポイント
- AIは「失敗の詳細をそのまま応答に含める」コードを生成しがち
- それを通すと、内部構造や置き場所を外部の相手へ教えてしまう（情報漏えい）
- 逆に「握りつぶし」（受け止めて何もしない）は、記録が残らず原因調査が不可能に
- どちらも、詳しさの向きを設計していないことが原因
構造——詳しさを二方向に分ける
構造は、失敗が起きた一点から情報が二方向へ分かれる図で捉えます。内側、つまり運営側へは、原因を調べるための詳しいログを流します。外側、つまり利用者へは、500というコードと「処理に失敗しました」といった簡潔な文だけを返します。同じ失敗から出発しても、詳しさの向きを内と外で逆にする、これが設計の核心です。詳しさの向きを間違えると、そのまま情報漏えいか、調査不能かのどちらかに落ちてしまいます。
このスライドのポイント
- 失敗が起きた一点から、情報を二方向へ分ける
- 内側（運営側）へ: 原因を調べるための詳細なログ
- 外側（利用者）へ: 500＋「処理に失敗しました」だけ
- 核心: 同じ失敗でも、詳しさの向きを内と外で逆にする
処理の流れ——データベース接続失敗の例
具体例で見てみます。データベースへの接続に失敗した場面を考えます。このときログには、接続先やエラーの原文を、A-07で学んだとおり原文のまま記録します。一方で利用者へ返す応答は、500と一般的なメッセージだけにとどめます。ここで気をつけたいのは、D-04で触れた、失敗しているのに200を返すような曖昧な応答も避けることです。失敗は失敗として、正しいステータスコードで伝えます。
このスライドのポイント
- 場面: データベースへの接続に失敗した
- ログには: 接続先・エラーの原文を、A-07で学んだとおり原文のまま記録
- 応答には: 500と一般的なメッセージだけ
- あわせて避ける: D-04で触れた「失敗なのに200」のような曖昧な応答
技術サンプル——try/catchで出力先を2つに分ける
スライドのサンプルは、ハンドラーをtryとcatchで囲んだ擬似コードです。tryの中には、検証、業務ルール、保存という正常な処理を並べます。失敗が起きるとcatchへ移り、ここに出力先が2つあることに注目してください。1つはログへの詳細な記録、もう1つは利用者への500と汎用的な文の応答です。応答の側には、内部情報が一切含まれていません。なお、この書き方は枠組みによって変わりますので、形そのものではなく、出力先を2つに分ける考え方を覚えてください。
混同しやすい点——同じ情報でも出す先で逆転する
混同しやすいのは、詳しいエラーをどこへ出すかです。詳しいエラーをログへ出すのは正しい設計です。しかし、まったく同じ詳しいエラーを応答へ出すと、それは情報漏えいになります。注目すべきは、同じ情報でも、出す先によって安全性が正反対になるということです。中では詳しく記録し、外へは最小限に。この一言を、この講義で最も強く持ち帰ってください。
バイブコーディングでの確認点——catchを2点で監査
バイブコーディングでの確認点です。AIが書いたコードのcatchの部分を、2つの観点で監査します。1つ目は、握りつぶしていないか、つまりログが残っているかです。2つ目は、応答に内部情報が含まれていないかです。AIへの質問例としては、「このサーバーのエラー応答に、構成やパスやデータベースへの問い合わせ内容といった内部情報が漏れている箇所はありませんか」と聞くとよいでしょう。この2点を、生成のたびに定型で確認します。
このスライドのポイント
- AIが書いたコードの全catchを2つの観点で監査する
- ①握りつぶしていないか（ログは残っているか）
- ②応答に内部情報が含まれていないか
- 定型の質問で、生成のたびに機械的に確認する
まとめと一問一答
最後に一問一答です。エラーの詳細を出してよいのは、ログと応答のどちらでしょうか。（間）答えは、ログです。応答へは最小限にとどめます。30秒でまとめます。例外処理は失敗を受け止める仕組み、エラー応答は正しいステータスコードで失敗を返すこと。そして原則は、中では詳しく記録し、外へは最小限、でした。次回のJ-09では、画像やPDFといったファイルをどこへ置くか、ファイルストレージを扱います。関連資料は「エラー文の読み方」「ログ設計入門」「AIアプリのセキュリティ超入門」です。
このスライドのポイント
- 一問一答: エラーの詳細を出してよいのは、ログと応答のどちら？
- 答え: ログ（応答は最小限）
- 30秒まとめ: 例外処理＝失敗を受け止める／エラー応答＝コードで返す／原則＝中は詳しく・外は最小限
- 次回: J-09 ファイルストレージ（画像やPDFの置き場）
- 関連資料: 「エラー文の読み方」「ログ設計入門」「AIアプリのセキュリティ超入門」
