① 前提：個人とチームの違い

観点	個人	チーム
管理	自分だけ	複数人
セキュリティ	ゆるくなりがち	厳格必須
保守	その場対応	設計必須
共有	しない	必須

---

🎯 結論（最重要）

👉 チームでは「変数」だけで設計してはいけない

---

② チーム設計の基本ルール

🚫 NG（よくある事故）

• APIキー直書き
• Composeに秘密情報
• 日本語ぐちゃぐちゃ命名
• フロー単体で完結

---

✅ OK（正しい設計）

種類	使い方
環境変数	設定値
Key Vault	秘密情報
Compose	固定値
変数	処理中データ

---

③ 役割分担（これが超重要）

🧩 ① 環境変数（設定）

👉 フロー外に持たせる

例：

• API URL
• statsDataId
• フラグ

---

🔐 ② Key Vault（秘密）

👉 APIキーなど

---

🧱 ③ Compose（定数）

👉 フロー内の固定値

---

🔄 ④ 変数（状態）

👉 途中で変わる値

---

④ チーム用ベスト構成（これが正解）

🔥 構成イメージ

[環境変数]
   ↓
[Compose(config)]
   ↓
[HTTP]
   ↓
[処理]

---

例（実務）

■ 環境変数

• EV_API_BASE_URL
• EV_STATSDATAID
• EV_APPID（KeyVault）

---

■ Compose（config化）

{
  "api": {
    "baseUrl": "<環境変数>",
    "appId": "<環境変数>",
    "statsDataId": "<環境変数>"
  }
}

---

■ HTTP

baseUrl → outputs('config')?['api']?['baseUrl']
appId → outputs('config')?['api']?['appId']

---

⑤ なぜこの構成が必要か

理由①：流出防止

👉 フロー共有時に

• APIキーが見えない
• JSONにも残らない

---

理由②：環境切替

👉 開発 → 本番

• URL差し替え
• キー差し替え

👉 フロー修正不要

---

理由③：保守性

👉 修正箇所が1箇所

---

⑥ 命名ルール（超重要）

❌ NG

• 変数初期値
• 作成1
• データ

---

✅ OK

種類	例
環境変数	EV_API_URL
Compose	config
変数	var_response

---

👉 英語で統一が鉄則

---

⑦ セキュリティ強化（必須）

✔ Secure Inputs / Outputs

👉 ONにする対象

• HTTP
• APIレスポンス

---

✔ ログ対策

👉 機密が履歴に出ない

---

⑧ よくある失敗（現場あるある）

❌ ComposeにAPIキー

👉 共有で即漏洩

---

❌ 変数でキー管理

👉 ログに残る

---

❌ フローごとに設定

👉 カオス化

---

⑨ チーム開発ルール（そのまま使える）

👉 社内ルール例

---

■ 禁止事項

• APIキーの直書き
• 個人環境のみで作成
• 命名ルール違反

---

■ 必須

• ソリューション使用
• 環境変数使用
• Key Vault使用

---

■ 推奨

• config集約
• 英語命名
• Secure設定

---

🏆 研修で使える一言

👉
「変数は個人、環境変数はチーム、Key Vaultは本番」