7
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

M365 CopilotでAWS記事の“ドキュメントレベル判定”エージェントを作ってみた

7
Last updated at Posted at 2026-02-16

先日、2026 Japan AWS Top Engineers クライテリアが発表されました。

ここに毎年出てくるLevel 300。一体、どれくらい書けていればレベル300に達しているのかというのが気になっていました。
screenshot.3002.jpg

そこで、この記事では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/

上記入力が完了したら、右上の「作成」ボタンをクリックします。

image.png

エージェント作成が完了すると、「作成されました!」というポップアップが出るので、エージェントに移動して、動作確認を行います。

image.png

動作確認

試しにQiitaのURLを送ってみます。

image.png

すると、下図のように返ってきてしまい、Qiitaの中身が取得できないと怒られました。
後で検証をしましたが、他のブログ系は問題なく動いたので、Qiitaだけ取得できないようです。

image.png

Qiitaの記事はmarkdownでも提供されているので、それを取得し送ってみました。

動作確認する記事の中身は、先日投稿した「【小ネタ】Azure Functionsから“長期鍵なし”でAWSを操作する ~ OIDC+AssumeRoleWithWebIdentityでS3を触ってみた~」という記事で、コード等も織り交ぜながら手順について詳細に記載しているので、挙動としては最低でもレベル200以上が付いて欲しいところです。

image.png

結果の部分だけの切り取りですが、下図のように判定をしてくれました。
無事レベル300でした!

image.png

続いて、技術にまったく触れていない「re:Invent2025 抜け出せないシアトル迷宮、果たしてラスベガスに着けるのか・・・ [前編]」という記事を送ってみます。技術についてはまったく触れていないのでレベル100で判定して欲しいところです。

image.png

ちゃんとレベル100に判定してくれました!

image.png

変な動きはしてなさそうということで、2026年1月6日時点の最新AWSブログ60件をエージェントに渡して、エージェントの精度を図りました。その結果、60記事中48個はラベル通りの値を返したので、80%の正答率でした。

このAWSブログ自体は、どのようにラベル付けされているのか分かりませんが、読み手側でも度々「記事によってラベル付け基準が違くないか?」という議論が起こっていたと思います。そんな中、プロンプトとナレッジのみのM365 Copilotのエージェントとしては、なんとか実用できるレベルの正答率なのかなということで、これで執筆記事の判定を行っていきたいと思います。
※URLを渡す形だと正答率が60%位まで下がるので、記事の内容を渡してください

AWSブログのテスト結果
No. 日付 記事名 実際の記事ラベル 判定結果 正誤
1 2025-09-03 Amazon Managed Service for Apache Flink アプリケーションライフサイクルの詳細 – パート 1 400 400
2 2025-09-05 Amazon DocumentDB 3.6 を 5.0 にニアゼロダウンタイムでアップグレードする 300 300
3 2025-09-05 Amazon DocumentDB (with MongoDB compatibility) バージョン 3.6 の延長サポートの発表 100 100
4 2025-09-09 レジリエンス by デザイン: 効果的なランサムウェアからの復旧戦略の策定 100 100
5 2025-09-11 Amazon RDS for OracleとAmazon RDS Custom for Oracle向けのAmazon EC2ベアメタルインスタンスの開始方法 200 300 ×
6 2025-09-17 ロシアの APT29 による水飲み場型攻撃キャンペーンを Amazon が阻止 200 200
7 2025-09-19 Amazon ECR の利用状況とセキュリティレポートを実装する 200 300 ×
8 2025-09-22 Oracle Database@AWS ネットワーク接続パターンの実装 400 400
9 2025-09-24 Amazon Bedrock における Anthropic の Claude 3.5 Sonnet から Claude 4 Sonnet に移行する 200 300 ×
10 2025-09-26 コンタクトセンター運用を最適化する Amazon Connect の予測、キャパシティプランニング、スケジューリング機能 200 200
11 2025-10-03 Amazon Connect Cost Insight Dashboard によるコストの可視化と最適化 200 200
12 2025-10-03 AWS DMS データの再同期によるデータ一貫性 300 300
13 2025-10-08 AWS Common Runtime で Amazon S3 のスループットを高速化 300 300
14 2025-10-08 AWS でのデジタル資産決済の処理 400 400
15 2025-10-20 Amazon MWAA における Apache Airflow 3 の紹介:新機能と機能拡張 300 300
16 2025-10-20 Amazon MWAA における Apache Airflow 2.x から Apache Airflow 3.x への移行のベストプラクティス 300 300
17 2025-10-21 PostgreSQL のアップグレード中に AWS DMS タスクを処理するためのベストプラクティス 300 300
18 2025-10-21 AWS DMS 3.5.4 におけるデータマスキングとパフォーマンス向上 200 300 ×
19 2025-10-24 AWS Backup マルチパーティ承認を使用して信頼性を高める方法 300 300
20 2025-10-27 Amazon Connect を提供する AWS が 2025 Gartner Magic Quadrant for Contact Center as a Service のリーダーに選出 100 100
21 2025-10-30 AWS DMS 実装ガイド:テスト、モニタリング、SOP による耐障害性のあるデータベース移行の構築 300 300
22 2025-10-30 AWS DMS 拡張モニタリングを使用したリソース配分とパフォーマンス分析を理解する 200 200
23 2025-11-05 Amazon RDS for PostgreSQL および Amazon Aurora PostgreSQL データベース向け AI 搭載チューニングツール: PI Reporter 300 300
24 2025-11-07 Amazon RDS for SQL Server のプロアクティブ監視をリアルタイム Slack 通知で実現 300 300
25 2025-11-10 Amazon MSK Express ブローカーが Intelligent Rebalancing をサポートし、操作パフォーマンスが 180 倍高速に 200 200
26 2025-11-13 AgentCore Gateway の MCP サーバー統合による MCP アーキテクチャの変革 200 300 ×
27 2025-11-19 AWS DMS によるリアルタイムでの Iceberg の取り込み 300 400 ×
28 2025-11-19 AWS DMS Schema Conversion CLI を使用したデータベースの評価と移行 300 300
29 2025-11-19 AWS DMS データ検証:カスタムサーバーレスアーキテクチャ 300 300
30 2025-11-19 AWS re:Invent 2025: 4つの変革的テーマで学ぶセキュリティセッションガイド 100 100
31 2025-11-20 都市規模のイベントを守る:AWS re:Invent における物理セキュリティと論理セキュリティの統合アプローチ 200 200
32 2025-11-21 Amazon Connect の通話録音の保存期間をカスタマイズする方法 300 300
33 2025-11-21 Amazon MWAA Serverless の紹介 200 300 ×
34 2025-11-26 Octus が Amazon OpenSearch Service へのゼロダウンタイム移行でインフラストラクチャコストを 85% 削減した方法 200 200
35 2025-11-28 Cisco と Citrix のゼロデイ脆弱性を悪用する APT を Amazon が発見 100 100
36 2025-12-01 Amazon API Gateway TLS セキュリティポリシーによる API セキュリティの強化 200 300 ×
37 2025-12-02 大容量テーブルの継続的レプリケーションを、AWS DMS の列フィルターによる並列化でパフォーマンス向上 400 400
38 2025-12-02 AWS Database Migration Service で PostgreSQL のテーブルをグループ毎にタスク化 400 300 ×
39 2025-12-03 新しい Amazon API Gateway Portal で API の発見性を向上させる 200 200
40 2025-12-03 Amazon Kinesis Data Streams で 10 倍大きなレコードサイズをサポート: リアルタイムデータ処理の簡素化 200 200
41 2025-12-03 AWS Well-Architected レビューの進め方 100 100
42 2025-12-03 Cluster Insights のご紹介: Amazon OpenSearch Service クラスター向け統合モニタリングダッシュボード 200 200
43 2025-12-04 Amazon DynamoDB Data Model Validation Tool でデータモデリング精度の向上させる 300 300
44 2025-12-04 Amazon DynamoDB のグローバルセカンダリインデックスにおけるマルチキーサポート 200 300 ×
45 2025-12-04 Amazon API Gateway レスポンスストリーミングによる応答性の高い API の構築 300 300
46 2025-12-05 Amazon Aurora MySQLのストレージ使用量を理解する 300 300
47 2025-12-08 Amazon OpenSearch Service の GPU アクセラレーションで 10 億規模のベクトルデータベースを 1 時間以内に構築 300 200 ×
48 2025-12-08 Amazon OpenSearch Service ベクトルデータベースを自動最適化する 300 300
49 2025-12-09 AWS Glue Data Catalog での Apache Iceberg テーブルのカタログフェデレーションの紹介 300 300
50 2025-12-10 Amazon Aurora DSQL の裏側:知っておくとおもしろい技術解説 Part 1 – 背景説明 100 100
51 2025-12-10 Amazon Aurora DSQL の裏側:知っておくとおもしろい技術解説 Part 2 – 概要 200 200
52 2025-12-10 Amazon Aurora DSQL の裏側:知っておくとおもしろい技術解説 Part 3 トランザクション処理 400 400
53 2025-12-10 AWS CloudShell を使用して Amazon RDS for Db2 に接続する 300 300
54 2025-12-10 Amazon Aurora DSQL の裏側:知っておくとおもしろい技術解説 Part 4 – DSQL のコンポーネント 400 400
55 2025-12-10 Amazon Aurora DSQL の裏側:知っておくとおもしろい技術解説 Part 5 – DSQL でのクロック使用 300 400 ×
56 2025-12-19 ブロックストレージとしての Amazon FSx for NetApp ONTAP 300 300
57 2025-12-21 AWS Glue Data Catalog における Apache Iceberg マテリアライズドビューの紹介 300 300
58 2025-12-23 Amazon RDS for MySQL と Amazon Aurora MySQL で高速な InnoDB パージを実現する 400 400
59 2025-12-24 コンタクトセンター運用をシンプルにする Amazon Connect Data Tables 300 300
60 2025-12-24 Amazon Connect のフローモジュールを強化する 3 つの強力な新機能 200 200

2025年度に執筆した自分の記事の判定

動作確認も済んだということで、2025年度に執筆した記事について判定を行っていきます。

期待結果

この記事執筆次点で私が2025年度に執筆した記事は10本でした。
内、4本はre:Invent関連の技術に関係のないものなので、4本はレベル100。
残りの6本はレベル200以上を予想します。

※なお、M365 Copilotは直接プロンプトに入力できる文字数が16000字までなので、それを越える記事はファイル化して渡しています

判定結果

それでは、判定結果です。

  • 1本目:マネジメントコンソールでAWSリソースを構築して、terraformコードを作ってからインポートしたら想像以上に辛かった話

    レベル300

image.png

  • 2本目:GuardDuty Malware Protection for S3のバケット数25というハードリミットがきつい

    レベル300

image.png

  • 3本目:S3 静的WebサイトホスティングのHTTPS化/プライベート化 + PrivateLinkのResorceGW対応をTerraformでやってみた

    レベル300

image.png

  • 4本目:FISによるAZ障害テストで遭遇したグレー障害とその対策

    レベル300

image.png

  • 5本目:【小ネタ】Auroraをスナップショットからリストアしたら「Secrets Manager 管理のマスターユーザー設定」が消えた話

    レベル300

image.png

  • 6本目:【小ネタ】Azure Functionsから“長期鍵なし”でAWSを操作する ~ OIDC+AssumeRoleWithWebIdentityでS3を触ってみた~

    レベル300

image.png

  • 7本目:re:Invent2025 抜け出せないシアトル迷宮、果たしてラスベガスに着けるのか・・・ [前編]

    レベル100

image.png

  • 8本目:re:Invent2025 抜け出せないシアトル迷宮、果たしてラスベガスに着けるのか・・・ [後編]

    レベル100

image.png

  • 9本目:re:Invent 2025 参加レポート : エンジニアは進化し続けなければならない

    レベル100

image.png

  • 10本目:re:Invent 2025 : 2回目の参加でUpdateした「あると便利な物リスト」 + オススメの場所

    レベル100

image.png

結果

上記で記載した期待結果は以下の通りです。

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!

7
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?