先日、2026 Japan AWS Top Engineers クライテリアが発表されました。
ここに毎年出てくるLevel 300。一体、どれくらい書けていればレベル300に達しているのかというのが気になっていました。

そこで、この記事ではAWSのドキュメントレベルを判定するM365 Copilot Agentを作成して、私の2025年度執筆記事のレベルを判定してみたので、その内容について記載致します!
AWSのドキュメントレベルについて
AWSとして定義している各レベルは以下の通りです。
- Level 100 : AWS サービスの概要を解説するレベル
- Level 200 : トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル
- Level 300 : 対象のトピックの詳細を解説するレベル
- Level 400 : 複数のサービス、アーキテクチャによる実装でテクノロジーがどのように機能するかを解説するレベル
以下のリンクから、AWSブログのレベル300や、レベル400のブログを抽出することも可能です。
これだけ、情報が整っていれば判断付くだろうと言われそうですが、どうしても自分の書いたドキュメントだと、客観的に見れず、レベル300位になってるんじゃないか?と思ってしまいます。そこで、色々調べてみるとドキュメントレベルチェックツールを作ってくれてる人が居る!
これを参考に自分でもドキュメントレベルを判定してくれるツールを作ってみようと思い、M365 Copilot Agentで作成してみました。
Agentの作成
M365 Copilotのアプリを立ち上げ、左側のエージェント作成からエージェント作成画面に行き、以下の内容で設定を行いました。
- アイコン
好きなアイコン
- 名前
AWSドキュメントレベル判定エージェント
(好きな名前)
- 説明
提供されたAWSドキュメントの内容をチェックして、提供されたドキュメントがAWSの定めるドキュメントレベルでいくつになるのか判定します。
(好きな説明)
- 指示
■ 役割
あなたはAWSのシニアソリューションアーキテクトです。AWSブログの内容を解析し、以下の「厳格な」判定基準に従ってレベル(100-400)を判定してください。
※公式のラベルが記事内にあっても、それは無視して以下の基準を優先してください。
■ 厳格な判定基準
・ Level 100: サービスの存在意義、メリットの紹介。エンジニアでなくても理解できる内容。
・ Level 200: 基本的な機能紹介や「Shallow View(浅い概説)」。コンソールのボタン操作。
・ Level 300: 実装、設定、CLI操作、SDK。特定の課題を解決するための具体的な手順(How-to)。
・ Level 400: 内部動作、パフォーマンスチューニング(InnoDB Purge等)、複雑な分散システムの設計思想、大規模環境での最適化。
■ 判定の重要サンプル(Few-shot)
判定に迷った際は、以下の過去事例との類似性を考慮してください:
・ Level 200: Amazon Connectの新機能紹介、Aurora DSQLの概要(Part 2)
・ Level 300: AWS GlueのMaterialized Views実装、FSx for ONTAPのブロックストレージ利用、CloudShellからの接続手順
・ Level 400: Amazon RDS/AuroraのInnoDB Purge最適化、Aurora DSQLのトランザクション処理/コンポーネント詳細
■ 思考プロセス
1. 記事の中に「性能の最適化(Purge等)」や「内部アルゴリズム」の話があるか? → YESなら400
2. 記事の中に「実装手順(コード/コマンド/具体的な設定)」があるか? → YESなら300
3. 記事の中に「概要やコンソール操作」しかないか? → YESなら200
4. 最終的なレベルを決定し、理由を述べる。
(もっと良い指示があればそれで)
- ナレッジ
https://aws.amazon.com/jp/blogs/
上記入力が完了したら、右上の「作成」ボタンをクリックします。
エージェント作成が完了すると、「作成されました!」というポップアップが出るので、エージェントに移動して、動作確認を行います。
動作確認
試しにQiitaのURLを送ってみます。
すると、下図のように返ってきてしまい、Qiitaの中身が取得できないと怒られました。
後で検証をしましたが、他のブログ系は問題なく動いたので、Qiitaだけ取得できないようです。
Qiitaの記事はmarkdownでも提供されているので、それを取得し送ってみました。
動作確認する記事の中身は、先日投稿した「【小ネタ】Azure Functionsから“長期鍵なし”でAWSを操作する ~ OIDC+AssumeRoleWithWebIdentityでS3を触ってみた~」という記事で、コード等も織り交ぜながら手順について詳細に記載しているので、挙動としては最低でもレベル200以上が付いて欲しいところです。
結果の部分だけの切り取りですが、下図のように判定をしてくれました。
無事レベル300でした!
続いて、技術にまったく触れていない「re:Invent2025 抜け出せないシアトル迷宮、果たしてラスベガスに着けるのか・・・ [前編]」という記事を送ってみます。技術についてはまったく触れていないのでレベル100で判定して欲しいところです。
ちゃんとレベル100に判定してくれました!
変な動きはしてなさそうということで、2026年1月6日時点の最新AWSブログ60件をエージェントに渡して、エージェントの精度を図りました。その結果、60記事中48個はラベル通りの値を返したので、80%の正答率でした。
このAWSブログ自体は、どのようにラベル付けされているのか分かりませんが、読み手側でも度々「記事によってラベル付け基準が違くないか?」という議論が起こっていたと思います。そんな中、プロンプトとナレッジのみのM365 Copilotのエージェントとしては、なんとか実用できるレベルの正答率なのかなということで、これで執筆記事の判定を行っていきたいと思います。
※URLを渡す形だと正答率が60%位まで下がるので、記事の内容を渡してください
AWSブログのテスト結果
2025年度に執筆した自分の記事の判定
動作確認も済んだということで、2025年度に執筆した記事について判定を行っていきます。
期待結果
この記事執筆次点で私が2025年度に執筆した記事は10本でした。
内、4本はre:Invent関連の技術に関係のないものなので、4本はレベル100。
残りの6本はレベル200以上を予想します。
※なお、M365 Copilotは直接プロンプトに入力できる文字数が16000字までなので、それを越える記事はファイル化して渡しています
判定結果
それでは、判定結果です。
-
1本目:マネジメントコンソールでAWSリソースを構築して、terraformコードを作ってからインポートしたら想像以上に辛かった話
レベル300
-
2本目:GuardDuty Malware Protection for S3のバケット数25というハードリミットがきつい
レベル300
-
3本目:S3 静的WebサイトホスティングのHTTPS化/プライベート化 + PrivateLinkのResorceGW対応をTerraformでやってみた
レベル300
-
4本目:FISによるAZ障害テストで遭遇したグレー障害とその対策
レベル300
-
5本目:【小ネタ】Auroraをスナップショットからリストアしたら「Secrets Manager 管理のマスターユーザー設定」が消えた話
レベル300
-
6本目:【小ネタ】Azure Functionsから“長期鍵なし”でAWSを操作する ~ OIDC+AssumeRoleWithWebIdentityでS3を触ってみた~
レベル300
-
7本目:re:Invent2025 抜け出せないシアトル迷宮、果たしてラスベガスに着けるのか・・・ [前編]
レベル100
-
8本目:re:Invent2025 抜け出せないシアトル迷宮、果たしてラスベガスに着けるのか・・・ [後編]
レベル100
-
9本目:re:Invent 2025 参加レポート : エンジニアは進化し続けなければならない
レベル100
-
10本目:re:Invent 2025 : 2回目の参加でUpdateした「あると便利な物リスト」 + オススメの場所
レベル100
結果
上記で記載した期待結果は以下の通りです。
4本はre:Invent関連の技術に関係のないものなので、4本はレベル100。
残りの6本はレベル200以上を予想します。
その上で、この記事執筆時点で2025年度に執筆した記事10本の判定結果は以下の通りで、期待どおりの結果となりました。
- レベル300:6本
- レベル100:4本
さいごに
結果としては、期待通りに動作をしてくれました。
一方で、re:Invent2025の記事以外全てがレベル300かと言われると、疑問が残る部分があり、小ネタのものなんかはレベル200なのではないか?という印象です。
動作確認でもAWSの記事60件に対して、8割の精度でしたので、この辺は今後の改善点として、プロンプトを調整していきたいと思います。
2026 Japan AWS Top Engineersを目指される方は、参考程度ではありますが是非試して頂ければと思います。
We Are Hiring!

















