AWS 技術ブログを書く時、投稿前に品質チェックしたいなって思ったことありませんか？ありますよね、、？
レベル判定（100/200/300/400）とか、不適切表現のチェックとかやるのめちゃくちゃ面倒ですよね。

そこでご使用いただきたいのが、今回作成した記事の品質を自動チェックするシステムです。自分では一切コードを書かずに、10 時間程度で作成しました。（セキュリティ面を考えて今回はスクリーンショットのみです。。）

この記事では、その開発プロセスと工夫したポイントを共有します。
コードは書いてませんが、いきなりボケを入れてくるので、勘所は必要かもですが、それでもコードを書かずに実装は魅力的でした。
※ 記事のレベルチェックは、みのるんさんの mcp-aws-level-checker パッケージを使用しています。

ちなみに、自分は今回が社外ブログ初です。

作成したアプリ

1. アプリのUI

2. 本記事のチェック結果

チェックすると、チェック結果が出力されます。チェックはLambdaそれぞれが並列に動作し、順次結果が反映されます。

開発の流れと工夫したポイント

1. 要件定義と仕様書作成

やったこと

対話形式で要件を整理
システム構成や AWS アーキテクチャを Markdown で洗い出し
仕様書の自動生成

工夫ポイント

全体像を可視化して意識をすり合わせ
Amazon Q との認識齟齬を防ぐため、最初に詳細な仕様を確定
曖昧な要件でも Amazon Q が質問してくれるので、対話しながら詳細化

2. インフラ構築（AWS CDK）

やったこと

1.で作った Markdown を投げて実装（レシピっぽいな）
5 つの Lambda 関数の実装
Step Functions での並列処理

工夫ポイント

.amazonq/rules/ でルール化
- 一般的なコーディング規約を定義し、一貫性のあるコード生成
- git の commit も Amazon Q に（git のコミットメッセージは日本語で、適切なサイズに分割して）
- なにかあったら、「ルール化しといて」で OK
pytest で単体テストを実行して、バグを可能な限りここで潰す（Python の仮想環境ももちろん AI 様が作成）
lint/formatter を追加し、定期的にnpm run buildをして、エラーを最小限に
全体を通してですが、定期的に「ディレクトリ構成は最適か？」って聞いてました。これでどんどん最適化される

4. フロントエンド開発（React）

やったこと

React + MUI での UI 実装

工夫ポイント

「ボタンの色を青にして」「説明を追加して」という自然言語で依頼
UI/UX もお願いした（UI/UX てきにどうよ？）
npm run dev で逐一 UI の変更をチェック

5. テスト・デバッグ

やったこと

結合動作確認

工夫ポイント

デバッグは動作確認してデバッグと全任せする。やり方や方向性は指示する
エラーが出たら、フロントの開発者ルーツのログをそのままぶん投げる
- Amazon Q が AWS CLI を実行して勝手にログを読み込んで直してくれる
自分でコードを読んで原因を探す必要なし

7. ドキュメント作成・更新

やったこと

README.md の作成・更新

工夫ポイント

逐一 README を更新させて、認識のすり合わせ（やっぱり大事）

作ったシステムの概要

AWS 技術ブログ自動チェックシステムです。Qiita 記事の URL を入力すると、以下のチェックを自動で実行してくれます。

レベル判定（100〜400）みのるんさんの Python パッケージ使いました！
NG ワードチェック
Bedrock Guardrails でコンテンツフィルタリング

CloudFront と S3 でホスティングされた Web UI から使えて、記事 URL を入力すると数秒で結果が返ってきます。
Step Functions で並列処理してるので、めちゃくちゃ速いです。

アーキテクチャ

ユーザー
  ↓
S3 + CloudFront (React)
  ↓
API Gateway
  ↓
Step Functions (並列実行)
  ├→ Lambda: QiitaFetcher (記事取得)
  ├→ Lambda: LevelChecker (レベル判定)
  ├→ Lambda: NgWordChecker (NGワード)
  └→ Lambda: GuardrailsChecker (Guardrails)
  ↓
S3 + CloudFront (React)

技術スタック

インフラ: AWS CDK (TypeScript)
バックエンド: Lambda (Python 3.12) × 5 関数
フロントエンド: React + TypeScript + Vite
AI: Amazon Bedrock (Claude 3.5 Sonnet v2)
オーケストレーション: Step Functions
ホスティング: S3 + CloudFront

開発プロセス - 本当にコードを書かなかった話

要件定義フェーズ

最初は「AWS 技術ブログのチェックシステムを作りたい」って Amazon Q Developer に伝えただけです。そしたら、対話形式で要件を整理してくれて、最終的に仕様書まで自動生成してくれました。

実際の対話はこんな感じでした。

自分: 「AWS技術ブログのチェックシステムを作りたい。レベル判定、NGワード、不適切表現のチェック等を実装したい。」
Amazon Q: 「仕様書を作成しました。」

最初は曖昧な要件でも、Amazon Q が質問してくれるので、対話しながら詳細化できます。
Markdown での確認になるので、分からないところは質問をすることで全体像の把握にも役立ちます。

インフラ構築（AWS CDK）

Markdown の仕様書を基に CDK のコードを作ってくれます。
最初は一つのファイルにスタックとかすべてまとめてあったんですが、やはり見にくかったので、
ファイルを分割させると、以下のようなファイルが作成されました。

lib/qiitaCheckerStack.ts: メインスタック
lib/constructs/: 各リソースの Construct
- bedrockGuardrail.ts: Guardrails 設定
- lambdaFunctions.ts: Lambda 関数定義
- lambdaLayer.ts: 共通ライブラリ
- stateMachine.ts: Step Functions 定義
- apiGateway.ts: API Gateway 設定
- frontendHosting.ts: S3 + CloudFront 設定

ただ、Lambda 250MB 制限に引っかかりました。
相談したら、改善案を３つほど提示してくれて、問題解決。

バックエンド開発（Lambda 関数）

ここも自動作成。pytest を実行させて、早期にバグを潰しました。
もちろん pytest のコードも作成させてます。

functions/qiita_fetcher/: Qiita API 呼び出し
functions/level_checker/: レベル判定（Container Image）
functions/ng_word_checker/: NG ワードチェック
functions/guardrails_checker/: Guardrails チェック
functions/api_handler/: API Gateway 統合

フロントエンド開発（React）

ここも自動作成。npm run devで UI をチェックしつつ、Amazon Q に UX 部分を考えさせる。
UX がどんどん良くなるので、一番おもしろい部分かも。合言葉は、「UI/UX てきにどう？」

Git コミット

コミットメッセージも Amazon Q が自動生成してくれました。.amazonq/rules/git-commit-rules.md でルールを定義してるので、
日本語で統一されたフォーマットのコミットメッセージが自動で作られます。

「変更をコミットして」って言うだけで、変更内容を理解して適切なコミットメッセージを生成してくれるので、コミットメッセージを考える時間もゼロです。
gitignore は勝手にはやってくれなかったので、事前に追加するように依頼。

Amazon Q Developer の活用ポイント

.amazonq/rules/ でプロジェクト固有ルールを管理

これが最大の工夫点です。

Amazon Q Developer は .amazonq/rules/ ディレクトリ内の Markdown ファイルを自動的に読み込んで、プロジェクト固有のルールとして適用してくれます。

実装したルールはこんな感じです。

コミットメッセージルール
Typescript・Python・Markdown のコーディング規則
その他こだわりポイント

実際の開発体験

良かった点

コードを書かない
高速開発
一貫性
.amazonq/rules/でルール化
学習効果
生成されたコードを読むことで学べるし、ベストプラクティスを自然に習得できました。
Git コミットも自動化
デバッグも全自動

まとめ

ルール化して、保守性をある程度高めながら、自分も勉強しつつ爆速で開発できた。
つまり、神ってこと。