午前I問題

新機能をリリースする際のデプロイ手法に関する記述のうち、最も適切なものはどれか。

ア）ブルーグリーンデプロイは、新旧2つの環境を用意し切り替える方式であり、問題発生時には旧環境への切り戻し（ロールバック）を迅速に行える利点がある。

イ）カナリアリリースは、全ユーザに対して新機能を同時に一括公開する方式であり、段階的な展開は行わない。

ウ）フィーチャーフラグは実装が完了した機能をリリースする際にのみ使用でき、開発中の未完成な機能に対しては使用できない。

エ）ローリングアップデートでは、常にすべてのサーバが同一バージョンのソフトウェアで稼働することが保証されるため、新旧バージョン混在によるリスクは考慮不要である。

午前I の解答・解説を見る

正解： ア）

解説：

  • ア）正解。ブルーグリーンデプロイは新環境（グリーン）と旧環境（ブルー）を並行して用意し、ルーティングを切り替えることでリリースを行う手法。問題が発生した場合はルーティングを旧環境に戻すだけで迅速なロールバックが可能という利点がある。
  • イ）不正解。カナリアリリースは、まず一部のユーザやサーバにのみ新バージョンを展開し、問題がないことを確認しながら段階的に展開範囲を拡大していく手法である。一括公開ではなく段階的展開が本質的な特徴である。
  • ウ）不正解。フィーチャーフラグは未完成の機能をコードとして本番環境にマージ・デプロイしつつ、フラグをオフにすることでユーザには見えない状態にしておくという用途でも広く使われる。これによりトランクベース開発と長期間のフィーチャーブランチ回避を両立できる。
  • エ）不正解。ローリングアップデートはサーバを順次入れ替えていく方式のため、更新中は新旧バージョンが混在する期間が必ず発生する。この間のAPI互換性やデータスキーマの互換性を考慮した設計が必要であり、リスクを無視することはできない。

午前II問題

フィーチャーフラグを用いた段階的リリースにおけるセキュリティ上の注意点に関する記述のうち、最も適切なものはどれか。

ア）フィーチャーフラグはあくまでUI表示の切り替えに使われる仕組みであり、サーバサイドのAPIエンドポイントやビジネスロジックの実行可否の制御には利用できない。

イ）フラグの状態（オン・オフ）を判定するロジックをクライアントサイドのJavaScriptのみに実装した場合、攻撃者がブラウザの開発者ツール等でフラグを操作し、本来アクセスできない未公開機能や管理者機能に到達できてしまう可能性がある。

ウ）本番リリース後、恒久的に使われなくなった古いフィーチャーフラグの条件分岐コードは、可読性以外の観点では特に問題とならないため、削除を急ぐ必要はない。

エ）フィーチャーフラグの管理システム（Flag管理基盤）自体は機密性の高い情報を扱わないため、アクセス制御や変更履歴の記録は不要である。

午前II の解答・解説を見る

正解： イ）

解説：

  • ア）不正解。フィーチャーフラグはUI表示だけでなく、サーバサイドのAPIエンドポイントの有効化・無効化やビジネスロジックの実行分岐にも広く使われる。むしろセキュリティ上重要なのはサーバサイドでの制御であり、クライアント側だけの制御は不十分である。
  • イ）正解。フラグ判定をクライアントサイドのJavaScriptのみで行うと、攻撃者はブラウザの開発者ツールでJavaScriptを書き換えたり、直接APIエンドポイントを呼び出したりすることでフラグの制御を回避し、本来非公開の機能やAPIに到達できてしまう。サーバサイドでの認可チェックと組み合わせることが必須である。
  • ウ）不正解。使われなくなった古いフラグとその条件分岐コード（デッドコード）は可読性の低下だけでなく、テストされていない古いコードパスが偶発的に有効化されるリスクや、意図しない権限制御の抜け穴（フラグの誤操作による機能の意図しない公開）につながる可能性があり、定期的な整理・削除（フラグの技術的負債の解消）が推奨される。
  • エ）不正解。フラグ管理基盤は「どの機能が誰に対して有効か」という機密性の高い運用情報を扱う。誤って本番環境の重要フラグを第三者が操作できると、未完成機能の意図しない公開やセキュリティ機能の無効化につながるため、アクセス制御と変更履歴（監査ログ）の記録が必要である。

午後問題

サブスクリプション型のオンライン学習サービスを提供するI社は、新しい有料プレミアム機能をフィーチャーフラグで段階的にリリースする計画を立てている。開発チームは次の設計でリリースを進めようとしている。

  • プレミアム機能の表示・非表示はフロントエンドのJavaScriptでフラグの値を判定し、UIコンポーネントの出し分けのみで制御する
  • プレミアム機能に対応するAPIエンドポイント自体は、フラグの状態にかかわらず常に有効化されており、リクエストがあれば処理される
  • フラグの設定変更は、Flag管理基盤の管理画面から誰でも（開発者全員が）変更可能な状態になっている
  • 過去のリリースで有効化した実験的機能のフラグが10個以上残存しており、どれが現在使用されているか把握できていない状態である

設問1

この設計のまま新しいプレミアム機能をリリースした場合に想定されるセキュリティ上の問題点を具体的に指摘し、改善策を述べよ。

設問1の解答・解説を見る

正解例： 問題点は、プレミアム機能のフラグ制御がフロントエンドのUI出し分けのみで行われており、対応するAPIエンドポイント自体はフラグの状態に関わらず常に有効であるため、無料プランのユーザであってもAPIエンドポイントを直接呼び出すことでプレミアム機能を不正に利用できてしまう（アクセス制御の回避）。改善策として、サーバサイドのAPI側でもリクエストごとにユーザのプラン（契約状態）とフラグの状態を確認し、条件を満たさないリクエストは拒否する認可チェックを実装する。UIでの出し分けはあくまでユーザ体験の向上のためであり、実効的なアクセス制御はサーバサイドで行うべきである。

解説・採点基準（計15点）：

採点項目キーワード配点
クライアント側制御のみでは回避可能である点を具体的に指摘API直接呼び出し・回避可能性6点
サーバサイドでの認可チェック実装を改善策として提示サーバサイド認可6点
クライアント側制御はUX目的、サーバ側が実効的制御という役割分担への言及制御の役割分担3点

設問2

Flag管理基盤の運用体制と、残存する古いフラグの管理について、それぞれ改善すべき点を述べよ。

設問2の解答・解説を見る

正解例：

Flag管理基盤の運用体制：フラグの変更（特に本番環境の重要フラグ）を誰でも変更可能な状態は、意図しない機能公開や、悪意ある変更のリスクを高める。変更権限を必要な担当者・役割に限定するアクセス制御を導入し、変更履歴（誰が・いつ・どのフラグを・どう変更したか）を監査ログとして記録する仕組みを整備する。重要度の高いフラグについては変更時の承認フロー（レビュー・承認者の設定）も検討する。

古いフラグの管理：使用中のフラグと不要になったフラグを棚卸しし、恒久化された機能または完全にロールバックされた機能に対応するフラグとその条件分岐コードを削除する。フラグのライフサイクル管理ルール（作成時に用途・撤去予定時期を記録し、定期的に棚卸しを行う）を運用に組み込み、デッドコード化・管理不能化を防止する。

解説・採点基準（計15点）：

採点項目キーワード配点
フラグ変更のアクセス制御・権限限定に言及変更権限の限定4点
変更履歴・監査ログの記録に言及監査ログ・変更履歴3点
不要フラグの棚卸し・削除に言及フラグの棚卸し・削除4点
フラグのライフサイクル管理ルールの整備に言及ライフサイクル管理4点

重要キーワード

用語説明
フィーチャーフラグ機能の有効・無効をコード変更なしに切り替える仕組み。段階的リリースやA/Bテスト、緊急時の機能無効化に用いられる
カナリアリリース新バージョンを一部のユーザ・サーバにのみ先行展開し、問題がないことを確認しながら段階的に拡大するリリース手法
ブルーグリーンデプロイ新旧2つの環境を並行稼働させ、ルーティング切り替えでリリース・迅速なロールバックを可能にする手法
クライアントサイド制御の回避ブラウザ開発者ツールや直接APIコールにより、フロントエンドのみで実装されたアクセス制御を迂回される脅威
フラグの技術的負債不要になったフィーチャーフラグとその条件分岐コードが整理されず残存し、可読性低下や意図しない挙動のリスクを生む状態
認可チェック認証された主体に対し、要求された操作・リソースへのアクセスが許可されているかをサーバサイドで検証する処理

まとめ

  • 午前I視点： ブルーグリーンデプロイ・カナリアリリース・ローリングアップデート・フィーチャーフラグはそれぞれ目的と特徴が異なるリリース手法であり、混同しないことが基礎となる。
  • 午前II視点： フィーチャーフラグはサーバサイドのAPI制御にも活用でき、クライアントサイドのみの制御は攻撃者に容易に回避されるリスクがある点、および放置されたフラグの技術的負債が頻出論点。
  • 午後視点： 実務対策は「サーバサイドでの実効的な認可チェック」「フラグ管理基盤自体のアクセス制御と監査ログ」「不要フラグの棚卸しとライフサイクル管理」の3点が段階的リリースの核心となる。