ひとことで言うと
「どのモデルを使うか」「どの機能を誰に見せるか」を、デプロイをやり直さずに切り替えるための設定配信サービスです。フィーチャーフラグと自由形式の設定の両方を扱い、検証・段階的ロールアウト・自動ロールバックまでを一体で持ちます。
要するに、配電盤です。コードは配線のまま変えず、AppConfigのスイッチだけを切り替えてモデルIDやプロンプトのバージョンを差し替えます。しかも配電盤自体に「変な設定を流したら自動で元に戻す」安全装置（Validators＋CloudWatchアラームによる自動ロールバック）が付いています。
なぜ生まれたか
GenAIアプリでは「使うモデルを変える」「新しいプロンプトを一部のユーザーだけに試す」といった変更が、コードのデプロイより頻繁に起きます。AppConfigはこの頻度差を吸収します。
| 摩擦 | AppConfig 側の受け皿 |
|---|---|
| モデルを切り替えるたびにLambdaを再デプロイしたくない | Lambda・API Gatewayと組み合わせ、モデルIDなどの設定値をコード変更なしで注入 |
| 新しい設定が壊れていたら本番に波及する前に止めたい | Validators（デプロイ前の構文・意味検証）とCloudWatch連携の自動ロールバック |
| 新機能を一部のユーザーだけに段階的に見せたい | デプロイ戦略（時間をかけた段階的ロールアウト） |
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| 動的なモデル切替 | Lambda・API GatewayとAppConfigを組み合わせ、コード変更なしでモデルIDを差し替え | D1 |
| プロンプトテンプレートのA/Bテスト・段階配信 | AppConfig experimentation（本番トラフィックでの実験） | D1, D2 |
| 障害時のキルスイッチ | 特定機能・特定モデルの呼び出しを即座に無効化 | D2, D5 |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| コード変更なしでFMを切り替えたい | Lambda・API Gateway＋AppConfigで設定値としてモデルIDを外出しする | 環境変数を書き換えてLambdaを再デプロイする案（コード変更を伴う） |
| 新しいプロンプト設定を全ユーザーに一気に出すのが不安 | AppConfigのデプロイ戦略で段階的ロールアウト＋CloudWatchアラームで自動ロールバック | フラグを2値のON/OFFだけで管理し、手動で監視する案 |
| 設定ミスが本番に波及するのを防ぎたい | Validatorsでデプロイ前に構文・意味を検証 | デプロイ後に目視で確認する運用 |
AppConfigは「設定を配る」サービスであって「推論の意思決定」はしません。試験のシナリオで「AppConfigがモデルの精度を評価して自動で切り替える」ように読める選択肢は誤りです。切替の判断（メトリクスを見て良し悪しを決める）はCloudWatchアラームやStep Functionsの側にあり、AppConfigは決まった設定を安全に配信・ロールバックするだけの層です。
実務でどう使うか
- 取得はAppConfig Agent経由が基本です。 アプリケーション（EC2・Lambda・ECS・EKS）がローカルのAgentエンドポイントにアクセスしてキャッシュ済みの設定を取得します。Agentを使わずAPI（
StartConfigurationSession／GetLatestConfiguration）を直接呼ぶ設計も可能ですが、取得はメーター課金の対象です - 設定プロファイルは「フィーチャーフラグ」と「自由形式の設定」の2種類です。 モデルIDやプロンプトのパラメータのような自由な値を配りたいなら自由形式プロファイルを選びます
- 既存のSSM Parameter Store・S3・Secrets Managerに置いた設定も配信元にできます。 ゼロから設定ストアを作り直す必要はなく、既存の格納場所を検証・段階配信の対象にできます
取得はメーター課金の対象です。AppConfig Agentはキャッシュを持ちますが、高頻度でモデル設定を読みに行く実装にすると呼び出し回数が積み上がります。設定の更新頻度に対してポーリング間隔が過剰でないか、実務では確認が要ります。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Systems Manager Parameter Store | Parameter Storeは値をただ格納・取得するだけ。AppConfigは段階的ロールアウト・検証・自動ロールバックといった「安全に配る」機能を付け足したレイヤー（Parameter Storeを配信元として使うこともできる） |
| Bedrock Prompt Management | AppConfigは汎用の設定配信（モデルID・機能フラグなど何でも）。Prompt Managementはプロンプトそのもののバージョン管理・パラメータ化・承認フローに特化 |
想起チェック
Q1. Lambda・API Gatewayと組み合わせて「コード変更なしでモデルを切り替える」ときに使うサービスは？
AWS AppConfigです。モデルIDなどの設定値を外出しし、デプロイをやり直さずに切り替えます。これは試験のスキル文に名指しで出てくる組み合わせです。
Q2. 新しいプロンプト設定を出す前に、壊れた設定が本番に波及しないようにする仕組みは？
Validators（デプロイ前の構文・意味検証）と、CloudWatchアラーム連携の自動ロールバックです。アラームが発火すると設定は自動的に元へ戻ります。