本記事は、BIPROGY / ユニアデックス社内AWSコミュニティ「BIPROGY AWS SPARK」の定期投稿企画第8回目の記事です。他の定期投稿企画の記事は、インデックスページをご覧ください。
はじめに
「このバージョン、いつまで使える？」をサービスごとに調べ、表へ転記する作業から抜け出したい。本記事では、Kiro と MCP に AWS 公式情報の調査手順をスキルとして与え、EOL までの残り日数と対応優先度を一覧化する方法を紹介する。RDS for PostgreSQL を使った実行結果とともに、公式情報への限定、判定基準、出力形式の設計ポイントを解説する。
課題: AWS の通知が来てからでは遅い
AWS マネージドサービスを使っていれば、バージョンのサポート終了（EOL）は避けて通れない。RDS のエンジンバージョン、EKS の Kubernetes バージョン、Lambda のランタイム — どれもいずれサポートが切れる。
本記事では、メジャー／マイナーバージョンの標準サポート終了、ランタイムの非推奨化、延長サポート終了などを、便宜上「EOL」と総称する。実際のライフサイクルや終了後の扱いはサービスごとに異なるため、最終的には各サービスの公式ドキュメントを確認する必要がある。
まず押さえておきたい前提がある。EOL の日付そのものは公開情報だ。 RDS のように、数年先までのリリースカレンダーが公式ドキュメントに載っているサービスもある。個別のアナウンスを待たなくても、調べれば分かる。
それでも EOL 対応が後手に回るのは、「情報の入手」ではなく「棚卸しの運用」がボトルネックになっているからだ。具体的には次の 3 点である。
-
横断比較できない: サービスごとに公式ドキュメントの場所も記載項目も違う。RDS は「コミュニティ EOL / 標準サポート終了 / 延長サポート終了」と多段だが、Lambda ランタイムは非推奨化フェーズの考え方が別。同じ形式に揃えるには個別に確認して正規化する手間がかかる
-
自環境との突合が手作業: カレンダーは「バージョンの一覧」であって「自分たちの環境の一覧」ではない。どのアカウントのどのリソースがどのバージョンで動いているかを集め、突き合わせる工程が残る
-
転記した時点から鮮度が劣化する: スプレッドシートに写した日付は、AWS 側の更新に追従しない
EOL の日付は固定ではない。AWS がサポート期限を後ろ倒しするケースがあるためだ。猶予が増える方向なので一見困らないが、実務では「古い日付のまま不要に急ぐ」か「延長を期待して後回しにする」のどちらかに転ぶ。
そして、この状態で個別アナウンスを待つと間に合わない。DB エンジンのメジャーバージョンアップは、アプリ側の互換性確認、性能検証、切り戻し手順の準備まで含めて影響範囲が広い。加えて組織の変更管理プロセスも通す必要がある。「通知が来てから動く」ではリードタイムが足りない。
「アナウンスを待つ」のではなく、公開されている情報を自分たちの環境に対して定期的に当てにいく仕組みが欲しい。 これが今回のスキルを作った動機だ。
解決アプローチ: AI エージェントに「調べ方」を教える
EOL チェックを機械化する手段は複数ある。「サービス横断で、自環境に対して、定期的に、同じ形式で棚卸しする」という目的で並べると、こうなる。
| 手段 | サービス横断性 | 備考 |
|---|---|---|
| 自前実装（スクリプト / Lambda）+ EOL マスタ | 実装した範囲のみ | 結果は毎回同じになる。ただし新バージョンが出るたびに、マスタの日付を自分で更新し続ける必要がある |
aws rds describe-db-engine-versions |
RDS / Aurora 限定 | サポート終了日を API から直接取得できるため、マスタを持たずに済む |
| AWS Health API（予定変更イベント） | 通知が出るものに限る | アナウンス起点なので受動的 |
| AI エージェント + MCP（本記事） | 広い | マスタ維持が不要。実行時点の公式情報を参照できるが、出力が揺れる |
今回は AI エージェント（Kiro）にスキルとして調査手順を渡す方法を選んだ。まず横断で棚卸しできる状態を最短で作ることを優先し、EOL マスタを継続的に更新する負担を避けたかったからだ。エージェントが実行時点で取得できる AWS 公式情報を参照するため、日付を自分で保持しなくて済む。
EOLチェックスキルの設計
.kiro/skills/eol-check.md として配置し、チャットで #eol-check を付けて呼び出す。以下が設計の骨格。
2つの調査モード
手動指定モード — サービスとバージョンを直接指定する。
RDS PostgreSQL 14, 15, 16 のEOLを調べて
実環境スキャンモード — AWS 環境に接続してリソースを自動検出する。
実環境のRDSとEKSのバージョンを確認してEOLを調べて
手動モードは「気になるバージョンをピンポイントで確認したい」とき。環境スキャンモードは「今動いているもの全部まとめて棚卸ししたい」ときに使う。
情報ソースの制約
スキル内で明示的にルールを設けている:
**情報ソースはAWS公式ドキュメントに限る。** ブログや第三者サイトの情報は使用しない。
LLM は古い情報や不正確なブログ記事を参照してしまうことがある。EOL は「正確さ」が命なので、AWS 公式ドキュメント以外の情報は使わないよう制約をかけている。
ステータス判定テーブル
残り日数に応じて 4 段階のステータスを付与する:
| 残り日数 | ステータス | 意味 |
|---|---|---|
| 期限切れ or 90日以内 | 🔴 要対応 | 即時対応が必要 |
| 91〜180日 | 🟡 計画必要 | 移行計画の策定が必要 |
| 181〜365日 | 🟢 余裕あり | 計画的に対応 |
| 366日以上 | ⚪ 当面OK | 中長期で意識 |
閾値は「組織の変更管理にかかる典型的なリードタイム」を意識して設定した。DB のメジャーバージョンアップであれば検証込みで 3〜6 ヶ月かかることが多い。90 日を切ったら本当に「赤」だ。
出力テンプレート
スキルにはレポートの出力形式をテンプレートとして埋め込んでいる:
# AWS バージョンサポート期限一覧 ({{基準日}} 時点)
## サマリ
| ステータス | 件数 |
|-----------|------|
| 🔴 要対応 | {{件数}} |
| 🟡 計画必要 | {{件数}} |
| 🟢 余裕あり | {{件数}} |
| ⚪ 当面OK | {{件数}} |
## {{サービス名}}
| バージョン | 標準サポートEOL | 延長サポート | 延長EOL | 残り日数 | ステータス |
|-----------|----------------|-------------|---------|---------|-----------|
| {{バージョン}} | {{YYYY-MM-DD}} | {{あり / なし}} | {{YYYY-MM-DD}} | {{日数}} | {{🔴 / 🟡 / 🟢 / ⚪}} |
**延長サポート備考**: {{延長サポートの適用条件と課金の扱い。公式ドキュメントの記述に沿って記載し、根拠 URL を併記する}}
**情報ソース**: {{参照した公式ドキュメントの URL}}
## 推奨アクション
### 即時対応（🔴）
- {{サービス / バージョン}}: {{推奨する対応}}
テンプレートを指定しておくことで、毎回同じ構造のレポートが出る。人によって出力がブレない。
実行デモ
入力
#eol-check
RDS for PostgreSQL 14 と 15 の標準サポート終了日、延長サポート終了日を調べて
出力（例）
以下は、手動指定モードでスキルが生成した出力を無編集で掲載したものである。ステータスは本スキル独自の判定基準であり、推奨移行先も AWS 公式の推奨ではないものもある。日付、料金、推奨移行先などは変更されたり、利用環境によって異なったりする可能性があるため、実際の対応時にはリンク先の公式情報を確認してほしい。
# AWS バージョンサポート期限一覧 (2026-07-27 時点)
## サマリ
| ステータス | 件数 |
|-----------|------|
| 🟢 余裕あり | 1件 |
| ⚪ 当面OK | 1件 |
---
## Amazon RDS for PostgreSQL
| バージョン | 標準サポートEOL | 延長サポート | 延長EOL | 残り日数(標準) | ステータス |
|-----------|----------------|-------------|---------|--------------|-----------|
| 14 | 2027-02-28 | あり | 2030-02-28 | 216日 | 🟢 余裕あり |
| 15 | 2028-02-29 | あり | 2031-02-28 | 582日 | ⚪ 当面OK |
### 詳細情報
#### PostgreSQL 14
| 項目 | 日付 |
|------|------|
| コミュニティリリース日 | 2021-09-30 |
| RDS リリース日 | 2022-02-03 |
| コミュニティ EOL | 2026-11-12 |
| RDS 標準サポート終了日 | **2027-02-28** |
| Extended Support Year 1 料金開始 | 2027-03-01 |
| Extended Support Year 3 料金開始 | 2029-03-01 |
| Extended Support 終了日 | **2030-02-28** |
#### PostgreSQL 15
| 項目 | 日付 |
|------|------|
| コミュニティリリース日 | 2022-10-13 |
| RDS リリース日 | 2023-02-27 |
| コミュニティ EOL | 2027年11月 (予定) |
| RDS 標準サポート終了日 | **2028-02-29** |
| Extended Support Year 1 料金開始 | 2028-03-01 |
| Extended Support Year 3 料金開始 | 2030-03-01 |
| Extended Support 終了日 | **2031-02-28** |
### 延長サポート料金
| 期間 | 料金 (vCPU あたり) |
|------|-------------------|
| Year 1 - Year 2 (標準サポート終了後 1〜2年目) | $0.120 / vCPU-hour |
| Year 3 (標準サポート終了後 3年目) | $0.240 / vCPU-hour |
> 💡 延長サポート料金は **アジアパシフィック (東京) (ap-northeast-1)** の価格です。リージョンにより料金が異なる場合があります。
### 延長サポート備考
- 延長サポートは標準サポート終了日を過ぎると自動的に適用される（オプトアウト不可）
- 通常のインスタンス利用料に追加で課金される（上記は追加分のみ）
- Reserved Instance の割引は延長サポート料金には適用されない
- 延長サポート期間中もセキュリティパッチ・重要なバグ修正は提供される
**情報ソース**:
- [Release calendars for Amazon RDS for PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-release-calendar.html)
- [Amazon RDS Extended Support charges](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/extended-support-charges.html)
- [Amazon RDS for PostgreSQL Pricing](https://aws.amazon.com/rds/postgresql/pricing/)
- 延長サポート料金: AWS Price List API (2026-07-27 時点取得)
---
## 推奨アクション
### 余裕あり（🟢）
- **RDS PostgreSQL 14**: 標準サポート終了まで約7ヶ月。計画的に移行を進める
- 推奨移行先: PostgreSQL 16 (標準サポート 2029-02-28 まで) または PostgreSQL 17 (標準サポート 2030-02-28 まで)
- 14→16 のスキップアップグレード (メジャーバージョン2つ飛ばし) も RDS では可能
- 移行前にパラメータグループの互換性、拡張機能の対応状況、アプリケーション側のSQL互換性を確認すること
### 当面OK（⚪）
- **RDS PostgreSQL 15**: 標準サポート終了まで約1年7ヶ月。中長期計画に組み込む
- 2027年後半〜2028年初頭までにアップグレード計画を策定
---
## 注意事項
- 本情報はAWS公式ドキュメントに基づく2026-07-27時点の情報です
- AWSは予告なくスケジュールを変更する場合があります
- 最新情報は各ソースURLを直接確認してください
- 延長サポート料金は **アジアパシフィック (東京)** リージョンの価格です。他リージョンでは料金が異なる場合があります
- Extended Support の料金は概算であり、正確な金額は [AWS RDS Pricing](https://aws.amazon.com/rds/pricing/) を参照してください
手動で各ドキュメントを巡回していたら 20〜30 分かかる作業が、1 回のチャットで完了する。
実環境スキャンモードの場合
#eol-check
実環境のRDS、EKS、Lambdaのバージョンを確認してEOL一覧を出して
この場合、エージェントは AWS API を MCP 経由で呼び出し、RDS/Aurora では DescribeDBInstances や DescribeDBClusters 、EKSでは ListClusters と DescribeCluster、Lambdaでは ListFunctions などを利用して、対象リソースとバージョンを取得する。出力にはリソース名の列が追加される。
手作業だった自環境との突合が、ここで解消される。バージョン一覧を眺めるのではなく、自分たちの環境に紐づいた形で期限が出てくる。
実環境スキャンでは、対象 APIの読み取り権限だけを付与した専用IAMロールを使用し、管理者権限は付与しない。
設計のポイント
1. 公式ドキュメント限定 — ハルシネーション対策
EOL は 1 日でもズレたら判断を誤る。「たぶんこの日」は許容できない。
スキル内で「情報ソースは AWS 公式ドキュメントに限る」と明記し、さらに調査ステップで AWS Knowledge MCP（ドキュメント検索ツール）を使うよう指示している。エージェントが一般検索や第三者情報に依存する可能性を抑える狙いだ。
それでも公式ドキュメントに情報がない場合は「未発表」「公式未公開」と正直に記載させる。推測で埋めないことが重要。
とはいえ、ハルシネーションは制約だけでは防ぎ切れないので、最後は人的レビューが必要になる。スキル側でできるのは、そのレビューのコストを下げることまでだ。
2. テンプレート駆動 — 出力品質の安定化
LLM に自由に書かせると、実行ごとにフォーマットが変わる。あるときは箇条書き、あるときはテーブル、あるときは長文の説明。
スキルに出力テンプレートをそのまま埋め込むことで、毎回同じ構造で出力される。チームメンバーが読むレポートとして品質が安定する。棚卸し結果を過去分と比較する際にもフォーマットが揃っていると楽だ。
3. MCP 連携 — ツール呼び出しで「調べるだけ」を超える
このスキルが単なるプロンプトテンプレートと異なるのは、MCP（Model Context Protocol）ツールを呼び出す点にある。
- AWS Knowledge MCP: AWS 公式ドキュメントの検索・取得
-
AWS MCP: 実環境のリソーススキャン（
DescribeDBInstancesなど）
エージェントが「知識を答える」のではなく「ツールを使って調べる」動きをする。これにより、実行時点で取得できる AWS 公式情報に基づいたレポートが生成される。
応用と展望
定期実行への組み込み
現状は手動でチャットから呼び出しているが、将来的には:
- 月次で自動実行し、結果を Slack / Teams に通知する
- 前回との差分を出して「新たに 🟡 になったバージョン」をアラートする
といった運用フローに組み込める。
他のチェックスキルとの連携
EOL チェックは「検知」のフェーズ。検知の先には「移行計画の策定」がある。
- EOL チェックで 🔴 を検出 → 移行手順スキルに引き渡す
- バージョンアップの互換性チェックスキルを作り、影響調査まで一気通貫で行う
スキル同士を組み合わせることで、「検知 → 分析 → 計画」のパイプラインが構築できる。
チーム共有
.kiro/skills/eol-check.md をリポジトリで管理すれば、チーム全員が同じ調査手順を利用できる。属人化しやすい確認観点や出力形式を、ファイルとして共有できる点もスキル化の利点だ。
まとめ
- AWS の EOL 通知を待つのは受動的すぎる。先回りして定期的に確認する仕組みが必要
- AI エージェントに「調べ方」をスキルとして教えることで、静的な EOL マスタを持たず、実行時点で取得できる AWS 公式情報を参照できる
- 公式ドキュメント限定の制約、ステータス判定テーブル、出力テンプレートを設計に組み込むことで、レポートの一貫性を高め、誤りを抑制する
- スキルは Markdown ファイル 1 つ。Git 管理してチームで共有できる
「調査手順を構造化して AI に渡す」パターンは、EOL チェックに限らず応用が利く。セキュリティチェック、コスト棚卸し、構成ドリフト検出 — 定期的に行う調査業務があれば、同じ発想でスキル化できる。そのとき「どこまでをエージェントに任せ、どこから決定的な処理に渡すか」の線引きが、そのまま運用の耐久性を決める。
なお、本記事では Kiro のスキル機能を使って紹介したが、調査手順の実体は Markdown ファイルであり、他の AI エージェント（Claude Code、Codex など）でも再利用しやすい。ただし、スキルの配置場所や呼び出し方法、利用可能な MCP ツールはエージェントごとに異なるため、移植時には調整が必要となる。それでも、「調査手順を構造化した Markdown」は、特定のツールに強く依存しないポータブルな資産として活用できる。
BIPROGYグループの技術への取り組み
We Are Hiring!