アドカレでAWSの記事をたくさん書いたので、それらの技術的難易度を判定してみた

Posted at 2025-12-27

はじめに

突然ですが、私は将来的にJapan AWS Top Engineersを最年少で受賞したいと思っています。

クライテリアによると、技術的難易度が Level 300 以上の活動が必要なようです。技術的難易度とは、以下の基準で定められる難易度です。

Level 100 : AWS サービスの概要を解説するレベル

Level 200 : トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル

Level 300 : 対象のトピックの詳細を解説するレベル

Level 400 : 複数のサービス、アーキテクチャによる実装でテクノロジーがどのように機能するかを解説するレベル

今の自分の立ち位置を確認するために、今年のアドカレで投稿した全２６記事の技術的難易度を判定してみました。

なお、私が投稿したアドベントカレンダーはこちらになります。よければ見ていってください。

判定方法

ChatGPTで、次のようなプロンプトを使いました。

何度も記事を判定させていると、次第に以下プロンプトの内容をLLMが忘却してしまいます。
記事を判定させる前に、毎回以下のプロンプトを読ませることを推奨します。

技術的難易度　判定用プロンプト

これからお送りするブログ記事（AWS関連）の、技術難易度を判定してください。ただし、技術難易度は以下の4段階です。

Level 100 : AWS サービスの概要を解説するレベル
Level 200 : トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル
Level 300 : 対象のトピックの詳細を解説するレベル
Level 400 : 複数のサービス、アーキテクチャによる実装でテクノロジーがどのように機能するかを解説するレベル

各レベルの具体例となる記事も共有します。これらの情報も参考にしてください。

出力結果は以下のフォーマットに必ず従ってください。
判定結果： <4種類の技術レベル>
理由： <短文で端的に記載>

分析サマリ

全２６記事のうち、勉強用のメモやリンク集が１６件
⇒「技術記事」の体をなしている１０記事を対象に詳細分析した。
（メモやリンク集の判定は、かなり疑惑の結果だった）

各技術レベルの割合

	記事数
Level 100	2
Level 200	3
Level 300	3
Level 400	2
合計	10

技術レベルとエンゲージメントの関係

サンプル数が少ないため、参考程度に見てください。

「Viewあたりのいいね」、「Viewあたりのストック」は、 x100 でスケーリング。

	いいね	ストック	View	いいね／View	ストック／View
Level 100	11	6	2629	0.4184	0.2282
Level 200	0	3	453	0	0.663
Level 300	0	2	456	0	0.439
Level 400	2	1	746	0.268	0.134
合計	13	16	4284	-	-

いいね、ストック、閲覧数を最も稼げるのは Level 100
- 上級者向け（Level 400）の記事が、Level 100 に次いで「いいね」されやすい
初~中級者向け（Level 200~300）の記事は、ストックされやすい
- Level 100 よりも、ストックされる確率は高い

多くの人からいいねやストックされたい
⇒万人向け（Level 100）か上級者向け（Level 400）の記事

特定の人に刺さってほしい
⇒初心者~中級者向け（Level 200/300）の記事

判定結果

1日目

判定結果： Level 400
理由： 「単一サービス解説」を超え、複数コンポーネント＋アーキテクチャ設計＋セキュリティ・ガバナンス思想まで踏み込んでいるから

2日目

判定結果： Level 400
理由： AgentCore の内部概念（Memory / Gateway / Policy）を前提知識として要求し、責務分離・設計思想・試験トラップまで含めた高度な理解を問うため

3日目

判定結果： Level 200
理由： Fargate と CloudWatch Logs の基本仕様を前提に、ログ転送方式の選択とベストプラクティス（サイドカー vs awslogs）を具体例付きで解説しているため

4日目

判定結果：Level 300
理由：FireLens・ECS・Fargate の基本仕様を前提知識として要求し、タスクメモリ・コンテナメモリ・log-driver-buffer-limit の関係性や内部バッファ挙動を公式仕様に基づいて詳細に分解・説明しているため

5日目

判定結果：Level 200
理由：ECS におけるタスクレベル／コンテナレベルのリソース指定を整理し、memory と memoryReservation の違いを公式仕様ベースで分かりやすく解説しているが、内部挙動や運用上の落とし穴（例：Fargate での扱いの差異）まで踏み込む段階には至っていないため

6日目

判定結果：Level 100
理由：AWS Certified Security – Specialty（SCS-C02）の試験範囲を章立てで整理し、関連する自作記事へのリンク集としてまとめた内容であり、技術的な解説や考察そのものは各リンク先に委ねられているため

7日目

判定結果：Level 300
理由：AWS Security Incident Response Guide を軸に、People / Process / Technology・NIST 準拠の対応ライフサイクル・ASFF・Security Hub / EventBridge 連携まで踏み込み、SCS-C02 のタスクステートメント「インシデント対応計画を策定して実装する」を設計観点で体系的に整理しているため

8日目

判定結果： Level 300
理由：複数のセキュリティサービスの役割・連携・内部的な検出／相関の仕組みを前提知識ありで詳細に整理しており、概要紹介やベストプラクティス解説を超えているが、具体的なエンドツーエンド実装やアーキテクチャ設計の深掘りまでは踏み込んでいないため。

9日目

判定結果： Level 200
理由： Well-Architected Framework や Generative AI Lens といった前提知識を前提に、公式サービスやソリューションの目的・構成例を解説しているが、各サービスの詳細挙動や実装手順、設計上のトレードオフまで深掘りしていないため。

10日目

判定結果： Level 400
理由：複数の AWS サービス（Lambda、API Gateway、AppConfig、DynamoDB、Step Functions、Amazon Bedrock、SageMaker など）を組み合わせたアーキテクチャパターン、耐障害設計、クロスリージョン推論、モデルのライフサイクル管理まで踏み込み、システム全体として生成AIソリューションがどのように機能・運用されるかを解説しているため。

11日目

判定結果： Level 300
理由： AWS Glue Data Quality や SageMaker Data Wrangler、Amazon Bedrock、Comprehend など複数サービスの機能や制約、使い分けを前提知識ありで詳細に解説しており、データ検証・前処理の内部的な考え方まで踏み込んでいるが、エンドツーエンドの実装アーキテクチャや統合パイプライン設計の具体例までは示していないため。

12日目

判定結果： Level 400
理由： OpenSearch のシャーディング戦略やマルチインデックス設計、UltraWarm、Serverless Vector Search に加え、Amazon Bedrock との連携や増分更新・同期パイプラインまで含めて、複数サービスとアーキテクチャ全体で高性能なベクトル検索基盤をどのように設計・運用するかを解説しているため。

13日目

判定結果： Level 400
理由： Amazon Bedrock Prompt Flows を中心に、順次プロンプトチェーン、条件分岐、再利用可能コンポーネント、前後処理の統合、キャッシング設計まで含めて、複数サービスとワークフロー全体で高度なプロンプトシステムがどのように機能・設計されるかを解説しているため。

14日目

判定結果： Level 400
理由： Amazon Bedrock Agents、Strands Agents、MCP を中心に、マルチエージェント構成、メモリ／ステート管理、エージェント間通信、ツール統合、オーケストレーションまで含めて、複数サービス・プロトコルを横断したエージェンティック AI アーキテクチャ全体の設計と動作原理を解説しているため。

15日目

判定結果： Level 300
理由： AWS Security Incident Response User Guide や Forensics on AWS を軸に、侵害対応・封じ込め・フォレンジック・自動化・証跡保全といった SCS タスク 1.3 の対象領域を網羅的に整理しており、実務前提の知識レベルは高いものの、具体的な自動化プレイブック（Runbook の JSON や Step Functions 定義、Lambda 実装例など）やエンドツーエンドの対応アーキテクチャ設計までは踏み込んでいないため。

16日目

判定結果： Level 100
理由：本記事は「学習メモ一覧（リンク集・進捗共有）」としての性質が強く、各タスクやサービスの技術的背景・設計判断・実装上の論点には踏み込んでいないため。

判定結果： Level 100
理由： 合格体験記・学習方法の共有が主目的であり、AWS サービスや生成 AI アーキテクチャの技術的詳細・内部挙動・実装設計には踏み込んでいないため。

17日目

判定結果： Level 300
理由： CloudWatch・EventBridge・Security Hub・SNS・Lambda など複数サービスを前提に、セキュリティモニタリングとアラート設計の考え方や連携パターンを体系的に解説しているが、具体的な実装コードや内部挙動・詳細なチューニングまでは踏み込んでいないため。

18日目

判定結果： Level 300
理由： CloudWatch・EventBridge・Security Hub など複数サービスを前提に、イベント欠落やアラート不発時の原因切り分け・設定確認ポイントを体系的に整理しており、トピックの詳細理解を要するが、実装コードや内部挙動レベルの深掘りまでは行っていないため。

19日目

判定結果： Level 300
理由： CloudTrail・CloudWatch Logs・VPC Flow Logs など各ログサービスの詳細仕様や設計ポイントを整理し、中央集約やライフサイクル管理まで踏み込んで解説しているが、具体的なアーキテクチャ実装の深掘りや内部動作レベルまでは踏み込んでいないため。

20日目

判定結果： Level 300
理由： VPC Flow Logs・CloudTrail・CloudWatch Logs それぞれのログ欠落や配信失敗について、IAM・S3 ポリシー・イベントタイプ設定など具体的な原因切り分けと修正手順を体系的に解説しており、単なる概要やベストプラクティスを超えたトラブルシューティング詳細に踏み込んでいるため。

21日目

判定結果： Level 300
理由： CloudWatch Logs Insights・Athena・CloudTrail Insights・Well-Architected など複数の公式サービスと設計観点を横断的に整理し、ログ分析ソリューションの設計判断や使い分けを体系的に解説している一方で、具体的なクエリ実装例の深掘りや内部アルゴリズム、性能・コスト最適化の詳細設計までは踏み込んでいないため。

22日目

判定結果： Level 100
理由：本記事は AWS Skill Builder サブスクリプションに対する体験レビュー・改善提案が主目的であり、AWS サービスの技術的仕組み、アーキテクチャ設計、実装・設定・内部動作といった技術深度には踏み込んでいないためです。

23日目

判定結果： Level 200
理由：ECS on Fargate と CloudWatch の基本概念を前提に、標準メトリクス・Container Insights・Logs Insights という複数の公式機能を使い分ける実践的な方法と手順を解説しており、入門を超えたサービス機能・ベストプラクティス解説のレベルに該当するためです。

24日目

判定結果： Level 300
理由：AWS CloudShell の基本説明に留まらず、ネットワークアーキテクチャ（VPC 統合・NAT 必須理由・ENI 作成）や IAM 権限モデル／条件キーまで踏み込み、公式仕様を前提に設計者視点で詳細解説しているためです。

25日目

判定結果： Level 300
理由：Exponential Backoff + Jitter のアルゴリズムを数式レベルで分類・比較し、AWS SDK の公式実装仕様や注意点、具体的なコード例まで踏み込んで詳細解説しているためです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up