Dev Step Research Case Study

見出しについて

見出し（背景・課題、アプローチ、構成 など）は固定ではありません。記事の内容に応じて、最も自然に情報が伝わる見出しを選んでください。

よく使われる見出しの例：

• 背景・課題
• 観点（進めるうえで重視したポイント）
• アプローチ
• 技術選定
• 構成
• 移行戦略
• 成果
• 組織面

文体について

• 体言止め・短文ベースで書く
• 説明的な接続詞や冗長な修飾は省く
• ただし、短くしすぎて意味が伝わらなくなるのは避ける

フォーマットのルール

技術要素は「それが何をするか・なぜ使うか」とセットで書く

技術名やツール名を単語として列挙するのではなく、それが全体の中で果たす役割や選定理由を文脈として伝えます。読者がその技術名を知らなくても、何のためのものかが分かるようにしてください。

• 悪い例

  - 技術選定
    - AWS: MediaLive, MediaPackage, CloudFront, S3
    - 認証: 署名付きCookie、社内IdP
  

• 良い例

  - アプローチ
    - ライブ配信にはMediaLiveで映像をリアルタイムにエンコードし、MediaPackageで配信パッケージを生成する構成を採用
    - オンデマンド配信はS3に保存した録画をCloudFront経由で配信
    - 認証は社内IdPと連携した署名付きCookieで制御し、社外からのアクセスを遮断
      - Cookieのドメイン設定は社内ドメインのサブドメインに限定する必要がある
  

構成要素はデータや処理の流れとして繋げて書く

個々の構成要素を独立して説明するのではなく、「AがBにCを渡し、BがDを行い…」のように因果・順序で繋ぎます。読者がシステム全体の動きを一本の流れとして追えるようにしてください。

• 悪い例

  - 構成
    - OBSからRTMPでMediaLiveにプッシュ
    - MediaLiveでHLSエンコード
    - MediaPackageでオリジン配信
    - CloudFrontでエッジ配信
    - Railsで配信管理と認証
  

• 良い例

  - 構成
    - 配信者がOBSからRTMPでMediaLiveにプッシュ
    - MediaLiveがHLS形式にエンコードし、MediaPackageがオリジンとして配信
    - CloudFrontがMediaPackageをオリジンとしてエッジ配信
    - 配信終了後、MediaLiveの出力をS3にアーカイブし、オンデマンド用のCloudFrontディストリビューションから配信
    - Railsアプリが配信スケジュール管理と署名付きCookie生成を担当
  

補足・注意点はそれが関係する箇所の直下に置く

補足や注意点を「注意点」のような独立した見出しにまとめるのではなく、それが関係する箇所の1段下に配置します。読者がその情報を必要とするタイミングで目に入るようにしてください。

• 悪い例

  - アプローチ
    - 認証は社内IdPと連携した署名付きCookieで制御
  - 構成
    - CloudFrontがMediaPackageをオリジンとしてエッジ配信
  - 注意点
    - Cookieのドメイン設定は社内ドメインのサブドメインに限定する必要がある
    - MediaPackageのオリジンエンドポイントにはアクセス制御ポリシーの設定が必要
  

• 良い例

  - アプローチ
    - 認証は社内IdPと連携した署名付きCookieで制御し、社外からのアクセスを遮断
      - Cookieのドメイン設定は社内ドメインのサブドメインに限定する必要がある
  - 構成
    - CloudFrontがMediaPackageをオリジンとしてエッジ配信
      - MediaPackageのオリジンエンドポイントにはアクセス制御ポリシーの設定が必要
  

出力例

「社内イベント配信基盤の構築」というテーマに対する出力例です。記事・企業・URLはすべて架空のものです。

## 調査結果: 社内イベント配信基盤の構築

- (AWSを活用した社内向けライブ配信基盤の構築)[https://example.com/tech-blog/live-streaming-platform]
  - 背景・課題
    - 全社イベントの配信を外部SaaSに依存しており、同時接続数の上限やコスト増が課題になっていた
    - 録画コンテンツの社内共有にも対応したかったが、既存の仕組みではオンデマンド配信に非対応
  - 観点
    - ライブとオンデマンドの両方を単一基盤で扱えること
    - 社内限定のアクセス制御を確実に行えること
  - アプローチ
    - ライブ配信にはMediaLiveで映像をリアルタイムにエンコードし、MediaPackageで配信パッケージを生成する構成を採用
    - オンデマンド配信はS3に保存した録画をCloudFront経由で配信
    - 認証は社内IdPと連携した署名付きCookieで制御し、社外からのアクセスを遮断
      - Cookieのドメイン設定は社内ドメインのサブドメインに限定する必要がある
  - 構成
    - 配信者がOBSからRTMPでMediaLiveにプッシュ
    - MediaLiveがHLS形式にエンコードし、MediaPackageがオリジンとして配信
    - CloudFrontがMediaPackageをオリジンとしてエッジ配信
    - 配信終了後、MediaLiveの出力をS3にアーカイブし、オンデマンド用のCloudFrontディストリビューションから配信
    - Railsアプリが配信スケジュール管理と署名付きCookie生成を担当

- (動画エンコードパイプラインの内製化)[https://example.com/tech-blog/video-encoding-pipeline]
  - 背景・課題
    - ユーザー投稿動画の増加に伴い、外部エンコードサービスのコストが月額数百万円規模に膨らんでいた
    - エンコード設定の細かなチューニングができず、画質とファイルサイズのバランスに不満があった
  - 観点
    - コスト削減と画質チューニングの自由度を両立すること
    - 動画数の増減に応じてスケールする仕組みであること
  - アプローチ
    - FFmpegをDockerコンテナに内包し、ECS Fargateでオンデマンドにスケールするエンコードパイプラインを構築
    - 複数ビットレート（360p / 720p / 1080p）のHLS出力を生成し、ABR（Adaptive Bitrate）配信に対応
  - 構成
    - S3への動画アップロードをEventBridgeが検知し、Step Functionsワークフローを起動
    - Step FunctionsがFargateタスクを起動し、FFmpegでHLSエンコードを実行
    - エンコード済みファイルを出力用S3バケットに格納し、CloudFront経由で配信
    - ワークフローの各ステップの成否をCloudWatch Metricsで監視し、失敗時はSlackに通知
  - 成果
    - エンコードコストを月額約70%削減
    - コーデック設定の自由度が上がり、同画質でファイルサイズを約30%圧縮