GitHub Copilot Enhancer を使ったアプリケーション開発前半戦 (要件定義と設計書の作成)

Last updated at 2025-10-16Posted at 2025-10-16

はじめに

GitHub Copilot Enhancer は、GitHub Copilot の生成支援機能を拡張するために筆者が開発した AI エージェント群です。
各エージェントはソフトウェア開発の特定領域（アーキテクチャ設計、DB設計、テスト、ドキュメント作成など）に特化しており、ユーザーとの自然な対話を通じて成果物を段階的に生成します。

他のAI開発支援ツールとの違い

ツール	主な特徴	生成の仕組み	Copilot Enhancer との違い
Claude Code（Anthropic）	チャットベースでコード理解・編集が可能。長文コンテキストに強く、大規模コードベースを横断的に解析。	単一の大規模LLM（Claude 3.x）による自然言語→コード生成	Copilot Enhancer は VS Code 内で GitHub Copilot と連携し、複数の専門AIエージェントを使い分ける点が異なる。各エージェントが役割を分担し、設計〜テスト〜文書化を一貫して支援する。
Codex（OpenAI）	GitHub Copilot の基盤モデル。自然言語→コード補完を中心に、短文の命令に即時反応。	Transformerベースのコード生成特化モデル	Copilot Enhancer は Codex（Copilot）を拡張する層として機能。Codex が出力するコードを、構造化されたワークフローやテンプレートで統制・改善できる。
Gemini CLI（Google）	Google Gemini モデルをCLIから操作できる開発支援ツール。設計補助、ドキュメント要約、コード生成などに対応。	LLM APIをCLIから呼び出し、汎用プロンプト実行	Copilot Enhancer は「エディタ内で動作」し、チャット指向。Gemini CLI のような汎用CLIではなく、IDE統合型でリアルタイム生成支援を行う。
GitHub Copilot Enhancer（本プロジェクト）	GitHub Copilot に統合された 17 個の専門 AI エージェント。アーキ設計、DB、API、テスト、ドキュメントなど領域別支援。	Copilot の出力をオーケストレーションし、エージェントが連携して段階的に成果物を生成	「単一モデル依存」ではなく「マルチエージェント構成」。Orchestrator AI が全工程を管理し、開発プロセスを自動化・分業化するのが最大の特徴。

簡単にまとめると

Claude Code： LLMによる長文解析とコードリファクタリングに強い
Codex： Copilot の基盤となる「コード補完AI」
Gemini CLI： CLI上の汎用AIツールとして柔軟だがIDE統合が弱い
Copilot Enhancer： Copilotをマルチエージェント化し、プロジェクト全体の自動生成フローを構築できる

Copilot Enhancer の構成（Orchestrator + 16 AI Agents）

Copilot Enhancer は、1つの統括エージェント（Orchestrator AI）と、16の専門エージェントによって構成されています。
それぞれのエージェントはソフトウェア開発ライフサイクル（SDLC）の特定領域に特化しており、分業しながら協調動作するマルチエージェント構造を持ちます。

この構成により、設計から実装、テスト、デプロイ、ドキュメント作成までの一連の流れを Copilot の内部で自動化・連携実行できます。

Orchestrator AI（統括エージェント）

スラッグ：@orchestrator
役割：全エージェントを統括し、ワークフローを自動調整する中枢エージェント。
機能：
- ユーザーの要求（要件定義、開発計画など）を解析
- 適切な専門エージェントを自動選択して順次実行
- 各エージェントの成果物を統合（例：要件 → 設計 → 実装 → テスト → ドキュメント）

利用例：

@orchestrator 新しい学習管理システムを開発したい。
要件定義からデプロイまで自動で進めてください。

Orchestrator は、「Copilot Enhancer の司令塔」 として、開発プロジェクト全体のフェーズを統合的に制御します。

コア開発エージェント（開発基盤を構築）

エージェント名	スラッグ	主な役割
System Architect AI	`@architect`	システムアーキテクチャ設計、C4モデル、ADR作成
Database Schema Designer AI	`@db-schema`	ER図設計、DDL生成、マイグレーション計画
Code Reviewer AI	`@code-review`	コードレビュー、品質診断、ベストプラクティス検証
Test Engineer AI	`@test-engineer`	ユニット／統合テスト自動生成、カバレッジ分析
Bug Hunter AI	`@bug-hunter`	ログ解析、根本原因分析、修正提案
Performance Optimizer AI	`@performance`	パフォーマンス分析、アルゴリズム最適化

これらは「開発エンジン」として、コード品質・パフォーマンス・安定性の基盤を支えます。

📄 ドキュメント・仕様エージェント（要件と文書化）

エージェント名	スラッグ	主な役割
Technical Writer AI	`@tech-writer`	README、開発者ガイド、APIリファレンス生成
Requirements Analyst AI	`@requirements`	要件分析、ユーザーストーリー、仕様策定
UI/UX Designer AI	`@uiux`	ワイヤーフレーム作成、UX設計、アクセシビリティ評価

これらのエージェントは、「開発の前後工程（要件定義・文書化）」 を自動化し、ドキュメントと実装の一貫性を保ちます。

DevOps・インフラエージェント（運用と自動化）

エージェント名	スラッグ	主な役割
DevOps Engineer AI	`@devops`	CI/CD パイプライン構築（GitHub Actions など）
Cloud Architect AI	`@cloud`	クラウド設計（AWS / GCP / Azure）とコスト最適化
Observability Engineer AI	`@observability`	監視、ログ、メトリクス、SLO設計

これらは、運用自動化と信頼性確保（Reliability Engineering） の領域を担当します。

API・セキュリティエージェント（連携と保護）

エージェント名	スラッグ	主な役割
API Designer AI	`@api-design`	REST / GraphQL API設計、OpenAPI仕様書生成
Security Auditor AI	`@security`	脆弱性診断、セキュリティ監査、コンプライアンス確認

これらのエージェントは、外部連携・セキュリティ設計の品質を担保します。

プロジェクト管理・品質エージェント（計画と改善）

エージェント名	スラッグ	主な役割
Project Manager AI	`@pm`	スケジュール、WBS、リスク管理、進捗モニタリング
Agile Coach AI	`@agile`	スプリント設計、レトロスペクティブ分析、チーム改善
Quality Assurance AI	`@qa`	テスト戦略立案、品質指標、静的解析設定

これらは、開発プロセス全体の 品質・透明性・継続的改善 を担当します。

全体構造のイメージ

まとめ

Orchestrator AI：全工程を統括し、エージェントを動的に連携させる司令塔
16 の専門AIエージェント：開発の各フェーズを自動化・分業化
Copilot Enhancer の強み：
- 「単一モデルによる補完」から「協調するAIチーム」へ
- すべての工程を Copilot 内で完結可能

OneRoster Hub を開発してみる

本書では、OneRoster CSV をインポートして、OneRoster RestAPI を提供するOneRoster Hub を Copilot Enhancer でどのように開発していくかを紹介します。

OneRoster とは

OneRoster（ワンロスター） は、教育機関で使用されるさまざまなシステム間で 学習者情報・授業情報・成績情報などを標準化して交換するための国際仕様 です。
IMS Global Learning Consortium（現 1EdTech）によって策定され、世界中の学校・教育システムで利用されています。

提供形式

OneRoster は主に2つの方法でデータを提供・受け渡しします。

形式	概要
CSV Export / Import	教育システム間でファイルを介してデータ連携する最も一般的な方法。シンプルで導入しやすい。
REST API	データをリアルタイムで提供するWeb API仕様。外部システムが必要な情報をオンデマンドで取得可能。

Copilot Enhancer による要件定義

まずはじめに、Requirements Analyst AI (要件分析・仕様策定) を使用して、要件定義書を作成します。

Copilot Enhancer への入力

@requirments  OneRoster CSV をインポートし、OneRoster API を提供するOneRosterHubを開発するので要件定義書して

以下のように機能要件書、非機能要件書、ソフトウェア要求仕様書が作成されます。作成されたドキュメントはVS Code で修正することができます。また、AIに追加依頼をすることで修正させることもできます。

requrements--onerosterhub--+--functional--+--functional-requirement-csv-import-20251016.md
                           |              +--functional-requirements-rest-api-20251016.md
                           |
                           +--non-functional----non-functional-requirements-20251016.md
                           |
                           +--src----srs-oneroster-hub-v1.0.md

機能要件書の抜粋

 OneRosterHub 機能要件書 - CSV インポート機能

**作成日**: 2025-10-16  
**カテゴリ**: CSV データインポート  
**優先度**: Must Have  

---

## FR-001: CSV ファイルアップロード

### 概要
OneRoster 標準形式の CSV ファイルセットをシステムにアップロードする機能。

### 優先度
**Must Have**

### ユーザーストーリー
```
As a システム管理者
I want OneRoster CSV ファイルをアップロードしたい
So that 学校の名簿データをシステムに取り込める
```

### 詳細要件

#### 1. 入力形式
- **ZIP ファイル**: 複数の CSV ファイルを含む ZIP アーカイブ
- **個別 CSV ファイル**: 必ず manifest.csv を含むこと
- **最大ファイルサイズ**: 500MB
- **ファイルエンコーディング**: UTF-8（BOM なし推奨）

#### 2. サポート CSV ファイル

| ファイル名 | 必須/オプション | 説明 |
|-----------|---------------|------|
| manifest.csv | **必須** | インポート対象ファイルの一覧 |
| orgs.csv | 必須 | 組織情報 |
| schools.csv | 条件付き必須 | 学校情報（学校のみの場合） |
| courses.csv | オプション | コース情報 |
| classes.csv | オプション | クラス情報 |
| users.csv | 必須 | ユーザー情報 |
| enrollments.csv | オプション | 在籍情報 |
| academicSessions.csv | オプション | 学期情報 |
| demographics.csv | オプション | 人口統計情報 |
| categories.csv | オプション | カテゴリ情報 |
| resources.csv | オプション | リソース情報 |
　　　：

非機能要件書の抜粋

# OneRosterHub 非機能要件書

**作成日**: 2025-10-16  
**バージョン**: 1.0  

---

## 1. パフォーマンス要件

### NFR-001: レスポンスタイム

#### 目標値

| 操作 | 目標レスポンスタイム | パーセンタイル | 測定条件 |
|------|------------------|-------------|---------|
| API リクエスト（単一リソース取得） | 200ms 以内 | 95%ile | 通常負荷時 |
| API リクエスト（リスト取得、100件） | 500ms 以内 | 95%ile | 通常負荷時 |
| API リクエスト（フィルタ適用） | 1秒以内 | 90%ile | 通常負荷時 |
| CSV インポート（10万レコード） | 5分以内 | 平均 | バックグラウンド処理 |
| CSV インポート（100万レコード） | 30分以内 | 平均 | バックグラウンド処理 |
| 管理画面表示 | 1秒以内 | 90%ile | 通常負荷時 |
| ダッシュボード表示 | 2秒以内 | 90%ile | 通常負荷時 |

#### 測定方法
- **ツール**: Apache JMeter, Gatling
- **監視**: Prometheus + Grafana, Application Performance Monitoring (APM)
- **ログ**: レスポンスタイムを全リクエストでログ記録

#### 受け入れ基準
- [ ] 上記の目標値を満たすこと
- [ ] 負荷テストで検証済み
- [ ] 本番環境でも同等のパフォーマンスを維持

---

### NFR-002: スループット

#### 目標値

| 項目 | 目標値 | 条件 |
|------|-------|------|
| API リクエスト処理能力 | 1,000 req/sec | ピーク時 |
| API リクエスト処理能力 | 500 req/sec | 通常時 |
| 同時 API クライアント | 100クライアント | 並行アクセス |
　　：

ソフトウェア要求仕様書の抜粋

# OneRosterHub ソフトウェア要求仕様書（SRS）

**バージョン**: 1.0  
**作成日**: 2025-10-16  
**プロジェクト名**: OneRosterHub  
**ステータス**: ドラフト

---

## 1. はじめに

### 1.1 目的
本文書は、OneRoster CSV インポート機能と OneRoster API を提供する「OneRosterHub」のソフトウェア要求仕様を定義する。

### 1.2 スコープ

#### 対象範囲
- OneRoster CSV 1.1/1.2 形式のデータインポート機能
- OneRoster REST API v1.1/v1.2 の提供
- データの検証・変換・保存機能
- API認証・認可機能
- データ同期・更新機能

#### 範囲外
- SIS（学生情報システム）の完全な実装
- 成績管理機能の詳細実装
- LMS（学習管理システム）との統合
- カスタムレポート生成機能

### 1.3 定義・略語

| 用語 | 説明 |
|-----|------|
| **OneRoster** | IMS Global Learning Consortium が策定する教育データ交換標準規格 |
| **CSV** | Comma-Separated Values（カンマ区切り形式） |
| **SIS** | Student Information System（学生情報システム） |
| **LMS** | Learning Management System（学習管理システム） |
| **GUID** | Globally Unique Identifier（グローバル一意識別子） |
| **sourcedId** | OneRosterにおける一意識別子 |
| **OAuth 2.0** | 認可フレームワーク |
| **REST API** | REpresentational State Transfer API |
| **Rostering** | 名簿・在籍管理 |
| **Gradebook** | 成績管理 |

### 1.4 参照文書
- IMS OneRoster v1.1 Implementation Guide
- IMS OneRoster v1.2 REST/CSV Binding Specification
- IMS OneRoster CSV Tables Reference
　　：

システムアーキテクチャ設計

System Architect AI を使用して、システムアーキテクチャ設計を行います。

Copilot Enhancer への命令

@architect

System Architect AI は対話型のエージェントで、アーキテクチャ作成に必要な情報をユーザーと対話しながら取得していきます。

Copilot Enhancer の応答例

システムアーキテクト AI として、OneRosterHub の詳細なシステムアーキテクチャを設計いたします。まず、システムアーキテクト用のプロンプトを確認します。

system-architect.md の読み取り

システムアーキテクトAI へようこそ！🏗️

OneRosterHub のアーキテクチャ設計を担当させていただきます。既に詳細な要件定義書（SRS）を確認しましたので、これを基に包括的なシステムアーキテクチャを設計いたします。

要件定義書から以下の重要情報を把握しました：

📋 プロジェクト概要（把握済み）
プロジェクト名: OneRosterHub
目的: OneRoster CSV インポート + OneRoster REST API 提供
規模: 中〜大規模（想定500万ユーザー、5,000校）
主要機能: CSV インポート、REST API（OAuth 2.0）、管理画面
🎯 重視する品質属性（要件定義から）
セキュリティ: OAuth 2.0、TLS 1.2+、FERPA準拠
スケーラビリティ: 水平スケーリング、データ成長対応
可用性: 99.5%稼働率
パフォーマンス: API 200ms以内、大量データインポート対応
それでは、設計を進める前に、いくつか確認させてください：

【質問1/3】デプロイ環境の優先順位
要件定義では複数のクラウド対応が記載されていますが、初期デプロイ環境の優先順位を教えてください。

a) AWS を第一優先（ECS/EKS、RDS、S3）
b) Azure を第一優先（AKS、Azure Database、Blob Storage）
c) GCP を第一優先（GKE、Cloud SQL、Cloud Storage）
d) オンプレミス Kubernetes
e) マルチクラウド対応（最初から複数クラウド対応）

※ これにより、具体的なサービス選定とIaC（Terraform/Bicep）の記述を最適化します。

> b と入力

了解しました！Azure を第一優先として設計を進めます。

【質問2/3】アーキテクチャパターンの選択
OneRosterHub の特性（CSV インポート + REST API）を考慮すると、いくつかのパターンが考えられます。

推奨: モジュラーモノリス → 将来的なマイクロサービス化に備えた設計

以下から選択してください：

a) モジュラーモノリス（推奨）

単一デプロイで運用・開発がシンプル
内部はモジュール分離（API / Import / Auth）
将来のマイクロサービス化が容易
適している理由: 初期は中規模、チーム数も限定的
b) マイクロサービス（最初から分離）

API Service / Import Service / Auth Service を独立デプロイ
より高いスケーラビリティ
複雑性が高い、初期の開発コスト大
c) サーバーレス（イベント駆動）

Azure Functions + API Management
CSV インポートは Functions、API は API Management
コスト効率が高いが、コールドスタート対策必要
d) お任せ（最適なパターンを提案）

どれを選びますか？

必要な情報を Copilot Enchancer がすべて取得したらアーキテクチャ設計ドキュメントを作成します。

アーキテクチャ設計ドキュメントの抜粋

 OneRosterHub システムアーキテクチャ設計書

**バージョン**: 1.0  
**作成日**: 2025-10-16  
**プロジェクト名**: OneRosterHub  
**ステータス**: 設計中  
**アーキテクト**: System Architect AI

---

## エグゼクティブサマリー

### プロジェクト概要
OneRosterHubは、教育機関向けのOneRoster標準準拠データハブシステムです。SISからのCSVデータインポート機能とOneRoster REST API提供機能を中核として、教育データの標準化と相互運用性を実現します。

### アーキテクチャ戦略
- **アーキテクチャパターン**: モジュラーモノリス
- **クラウドプラットフォーム**: Microsoft Azure
- **セキュリティレベル**: 標準的セキュリティ実装（FERPA準拠）
- **デプロイメント**: コンテナベース（Azure Kubernetes Service）

### 主要決定事項
1. **モジュラーモノリス採用**: 開発効率と将来の分割可能性のバランスを重視
2. **Azure優先**: 統合された管理体験とエンタープライズ機能を活用
3. **標準セキュリティ**: コストと要件のバランスを取った堅実な実装

---

## 1. ビジネスドライバー

### 1.1 ビジネス目標

#### 主要目標
- **相互運用性の向上**: OneRoster標準による教育システム間の連携強化
- **データ品質の向上**: 統一された検証・変換プロセスの実装
- **運用効率の改善**: 手動データ処理の自動化と標準化
- **コンプライアンス遵守**: FERPA等の教育データプライバシー規制への対応

#### 成功指標（KPI）
- API レスポンス時間: 95%ile で 200ms以下
- システム稼働率: 99.5%以上
- データインポート成功率: 99%以上
- API エラー率: 0.5%以下

### 1.2 ビジネス制約

#### 技術制約
- OneRoster v1.1/v1.2 標準への完全準拠
- FERPA コンプライアンス要件
- 既存SISとの互換性維持
  :

システムアーキテクチャ設計ドキュメントが完成したら、技術アーキテクチャーの詳細設計を開始します。

🔄 次に作成する予定
次は技術アーキテクチャの詳細設計を作成していきます：

データアーキテクチャ設計 - PostgreSQLスキーマ、OneRoster準拠設計
セキュリティアーキテクチャ設計 - 暗号化、認証フロー、脅威対策
インフラストラクチャ設計 - Azure AKS、監視、CI/CD
どの設計書から作成していきましょうか？データアーキテクチャから始めるのがおすすめです。

データアーキテクチャ設計書の抜粋

# OneRosterHub データアーキテクチャ設計書

**バージョン**: 1.0  
**作成日**: 2025-10-16  
**プロジェクト名**: OneRosterHub  
**ステータス**: 設計中  
**データアーキテクト**: System Architect AI

---

## エグゼクティブサマリー

OneRosterHubのデータアーキテクチャは、IMS OneRoster v1.1/v1.2標準に完全準拠したPostgreSQLベースの設計です。教育データの整合性、性能、セキュリティ、監査可能性を重視し、500万ユーザー、5,000校規模への拡張に対応します。

### 主要設計原則
- **OneRoster準拠**: IMS Global標準への厳密な準拠
- **データ整合性**: 外部キー制約とトランザクション保証
- **パフォーマンス**: 適切なインデックス戦略と正規化
- **監査性**: 全変更の追跡とログ記録
- **拡張性**: 水平・垂直スケーリング対応

---

## 1. データモデル概要

### 1.1 OneRosterエンティティ関係

```mermaid
erDiagram
    orgs {
        string sourced_id PK
        string status
        timestamp date_last_modified
        string name
        string type
        string identifier
        string parent_sourced_id FK
    }
    
    schools {
        string sourced_id PK
        string status
        timestamp date_last_modified
        string name
        string type
        string identifier
        string parent_sourced_id FK
    }
    :

mermaid書式でエンティティ関係が示されているので図化すると以下のようになります。

セキュリティアーキテクチャ設計書の抜粋

# OneRosterHub セキュリティアーキテクチャ設計書

**バージョン**: 1.0  
**作成日**: 2025-10-16  
**プロジェクト名**: OneRosterHub  
**ステータス**: 設計中  
**セキュリティアーキテクト**: System Architect AI

---

## エグゼクティブサマリー

OneRosterHubのセキュリティアーキテクチャは、教育データの機密性、完全性、可用性を保護するための多層防御戦略です。FERPA（Family Educational Rights and Privacy Act）準拠を中核とし、OAuth 2.0認証、エンドツーエンド暗号化、包括的な監査により、教育機関の信頼に応えるセキュリティを実現します。

### セキュリティ目標
- **機密性**: 学生・教職員の個人情報保護
- **完全性**: データの正確性・改ざん防止  
- **可用性**: 99.5%稼働率とサービス継続性
- **監査性**: 完全なアクセス履歴・変更追跡
- **準拠性**: FERPA・SOC 2 Type II準拠

---

## 1. 脅威モデリング

### 1.1 資産の特定

#### 高価値資産
```mermaid
graph TD
    A[学生個人情報<br/>PII] --> B[氏名・生年月日<br/>住所・SSN]
    A --> C[学習記録<br/>成績・出席]
    A --> D[家族情報<br/>保護者・緊急連絡先]
    
    E[システム資産] --> F[OAuth認証情報<br/>Client Secret・JWT]
    E --> G[管理者アカウント<br/>システム設定]
    E --> H[API エンドポイント<br/>データベース接続]
    
    I[運用資産] --> J[暗号化キー<br/>証明書]
    I --> K[バックアップデータ<br/>ログファイル]
    I --> L[インフラ設定<br/>ネットワーク構成]
```

#### 資産分類・重要度
| 資産カテゴリ | 重要度 | FERPA適用 | 暗号化要件 | アクセス制御 |
|-------------|-------|----------|-----------|-------------|
| 学生PII | Critical | Yes | AES-256 | 最小権限 |
| 成績・評価データ | High | Yes | AES-256 | ロールベース |
| 認証情報 | Critical | No | bcrypt/JWT | 多要素認証 |
| システム設定 | Medium | No | TLS 1.3 | 管理者のみ |
| 監査ログ | High | Yes | AES-256 | 読み取り専用 |

### 1.2 脅威分析（STRIDE）

#### Spoofing（なりすまし）
- **脅威**: 不正なAPIクライアントによる認証突破
- **影響**: 学生データの不正取得
- **対策**: OAuth 2.0 + JWT署名検証、Client Certificate
  :

インフラストラクチャアーキテクチャ設計書の抜粋


**バージョン**: 1.0  
**作成日**: 2025-10-16  
**プロジェクト名**: OneRosterHub  
**ステータス**: 設計中  
**インフラアーキテクト**: System Architect AI

---

## エグゼクティブサマリー

OneRosterHubのインフラストラクチャアーキテクチャは、Microsoft Azure上で99.5%の可用性と高いセキュリティを実現する教育データプラットフォームです。Azure Kubernetes Service (AKS)を中核とし、マネージドサービスを積極的に活用することで、運用負荷を最小化しながら5,000校・500万ユーザーの規模に対応します。

### インフラ設計原則
- **スケーラビリティ**: 水平・垂直スケーリング対応
- **可用性**: 99.5% SLA達成のマルチリージョン構成
- **セキュリティ**: 多層防御とゼロトラスト原則
- **運用性**: 自動化とObservabilityによる効率運用
- **コスト最適化**: リソース最適化とスポットインスタンス活用

### 主要コンポーネント
- **コンピューティング**: Azure Kubernetes Service (AKS)
- **データストレージ**: Azure Database for PostgreSQL Flexible Server
- **キャッシュ**: Azure Cache for Redis Premium
- **ストレージ**: Azure Blob Storage（Hot/Cool階層）
- **ネットワーク**: Azure Application Gateway + Azure Front Door
- **セキュリティ**: Azure Key Vault + Azure Active Directory
- **監視**: Azure Monitor + Application Insights

---

## 1. Azure基盤アーキテクチャ

### 1.1 リージョン・ゾーン設計
　　：

インフラストラクチャアーキテクチャ設計書完成後のメッセージ

インフラストラクチャアーキテクチャ設計書の最終部（第3部）を完成させました！

📋 完成した設計書の構成
✅ 完了したセクション
第1部: Azure基盤・AKS設計

Azure リージョン配置とVNet設計
AKS クラスター構成（マルチゾーン）
Ingress Controller（NGINX + Application Gateway）
ワークロード配置（詳細なKubernetes YAML）
第2部: データ・監視設計

PostgreSQL Flexible Server設計
Redis Cache Premium構成
Azure Blob Storage階層管理
Prometheus/Grafana監視スタック
カスタムメトリクス実装
第3部: セキュリティ・運用設計

Azure Key Vault統合（CSI Secret Store Driver）
ネットワークセキュリティ（Private Endpoint、Network Policy）
災害復旧・バックアップ戦略（Multi-Region DR）
CI/CD パイプライン（GitHub Actions + ArgoCD）
オートスケーリング・コスト最適化
定期メンテナンス自動化
🎯 設計のハイライト
🔒 セキュリティ重点設計
FERPA準拠: 教育データ保護に特化したセキュリティ
Private Endpoint: 全データベース・ストレージのプライベート接続
Key Vault統合: シークレット管理の完全自動化
Network Policy: Pod間通信の厳格制御
🚀 高可用性・スケーラビリティ
99.5% SLA: マルチAZ配置とAzure Premium Services
Auto Scaling: HPA・VPA・Cluster Autoscaler連携
Blue-Green Deploy: ゼロダウンタイム導入
Multi-Region DR: 4時間RTO・1時間RPO
💰 コスト最適化
Spot Instance: 夜間・週末の自動活用
ストレージ階層: アクセス頻度による自動移行
リソース最適化: VPAによる自動サイジング
予約インスタンス: 使用量分析による推奨
🔄 DevOps・GitOps
完全自動化: GitHub Actions → ArgoCD連携
セキュリティスキャン: Snyk・Trivy・CodeQL統合
Infrastructure as Code: Helm・Kustomize活用
運用自動化: 定期メンテナンス・バックアップ
📊 実現する技術仕様
対象規模: 5,000校・500万ユーザー・500 API クライアント
パフォーマンス: レスポンス時間 < 200ms、スループット > 10,000 req/min
可用性: 99.5% SLA、計画停止 < 4時間/年
セキュリティ: OAuth 2.0・TLS 1.2+・FERPA準拠
バックアップ: 7年保存・35日PITR・Multi-Region
この包括的なインフラストラクチャ設計により、OneRosterHubの本格運用を安全かつ効率的に実現できます

ドキュメント作成の最後に　Project Manager AI　にプロジェクト計画書を作成してもらいます。

Copilot Enhancer への依頼

@pm プロジェクト計画書を作成して

前半線はここまでとします。後半戦は、実際のコーディングについて解説します。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

GitHub Copilot Enhancer を使ったアプリケーション開発 前半戦 (要件定義と設計書の作成)