5.5コードレビューとシーケンス図の解釈

自動化は一度書いて終わりではなく、チームで安全に変更し続ける営みです。そのための2つの実践がこの節のテーマです。1つはコードレビュー——変更を本番に入れる前に第三者が読み、バグ・可読性・セキュリティを点検する仕組み。もう1つはシーケンス図の読解——複数のコンポーネント（クライアント・API・認証サーバ）がどの順で・何をやり取りするかを図から掴む力です。どちらも「暗記」ではなく、提示されたレビュー状況・図を解釈して次の一手を判断する題材として学びます。

5.5.1コードレビューの原則と利点

• レビューの狙いはバグの早期発見・可読性/保守性・セキュリティ・知識共有。変更を本番前に第三者が読むことで、平文パスワードのハードコードや危険な削除、境界条件の見落としをリリース前に捕まえられる。属人化を防ぎ、チームで設計意図を共有する効果も大きい。
• 良いレビューの実践：PRは小さく（差分が小さいほど見落としが減る）、正しさ・可読性・セキュリティに焦点を当て、人格でなくコードを対象に建設的に指摘する。指摘は具体的・根拠付きで、修正提案を伴うと良い。CIの自動チェック（lint/テスト）を通した上で人のレビューを重ねると効率的。

5.5.2シーケンス図を読む

• シーケンス図は、上部のアクター/オブジェクト（例：Client / Auth Server / API）から下へ伸びるライフライン（縦線）と、それらを結ぶメッセージの矢印で構成される。時間は上から下へ流れ、矢印の向きが呼び出し方向を表す。実線＝要求（呼び出し）、破線の戻り矢印＝応答、というのが一般的な表記。
• API連携の図を読む勘所は順序と依存：例えば「Client→Auth: トークン要求／Auth→Client: トークン（応答）／Client→API: GET（Bearerトークン付き）／API→Client: 200＋データ」なら、認証が先・データ取得が後という依存が読める。途中にAPI→Client: 429が現れればレート超過→待って再試行という制御の必要性が図から分かる。

あなたは同僚のPull Requestをレビューしています。差分は、Ciscoプラットフォームのトークン認証APIを呼ぶPythonスクリプトで、添付のシーケンス図は次の流れです：Client → Auth Server: 認証情報でトークン要求／Auth Server → Client: アクセストークン（応答）／Client → API: GET /devices（Authorization: Bearer <token>）／API → Client: 200 OK ＋ 機器一覧。まず図から読めるのは、トークン取得が先で、機器一覧の取得はそれに依存するという順序です。ところがコードを読むと、GET /devicesを先に呼び、その後でトークンを取得しており、図の依存関係（認証が先）と実装の順序が逆でした。これは「図と実装の不一致」で、実行すれば認証ヘッダ無しの要求が401 Unauthorizedで弾かれます——レビューで指摘すべき明確なバグです。さらに図の右側に、大量ループ時の分岐としてAPI → Client: 429 Too Many Requestsが描かれているのに、コードには429時の待機・再試行（バックオフ）が無く、レート超過で全体が失敗する作りでした。ここもシーケンス図が想定する制御に対する実装漏れです。レビューコメントは具体的・根拠付き・修正提案付きにします：「(1) 図の依存どおり、トークン取得をGET /devicesの前に移動（現状は401になる）。(2) 図の429分岐に合わせ、Retry-Afterを尊重した待機付き再試行を追加」。ここで避けるべきは、「このコードは雑だ」といった人格・印象への曖昧な非難で、レビューはコードの正しさ・可読性・セキュリティに焦点を当て、建設的に行うのが原則です。この一件が示すのは、シーケンス図は「あるべき順序と依存の仕様」として読め、実装がそれと一致しているかを照合することがレビューの具体的な武器になるということです。

5.5.3この節のまとめ

• コードレビューは本番前にバグ・可読性・セキュリティ・知識共有を確保する。PRは小さく、人でなくコードを具体的・根拠付きで指摘する
• シーケンス図はアクター＋ライフラインで時間は上→下、矢印の向き＝呼び出し方向（実線要求/破線応答）。順序と依存を読む
• 図は「あるべき順序・依存の仕様」として使い、実装との不一致（認証を後回しで401／429時の再試行漏れ）を照合して次の一手を判断する