年100記事更新を支えるAIエージェント等

JAWS-UG 大阪 年100記事更新を支える AIエージェント等 hideokamoto | Senior Field Engineer @ CircleCI AWS Community Builder | wp-kyoto.net

自己紹介 Hidetaka Okamoto (岡本秀高 ) ● CircleCI Senior Field Engineer ● http://wp-kyoto.net ● AWS Startup Community Osaka ● AWS Community Builder ( Serverless | 3年目 ) 2

• http://wp-kyoto.net

10年間で1,000本( Qiita / Zenn 除外 )以上記事を書いています 年 100 記事 = 週2記事ペース

自分のブログで記事を書くことに対する「大変さ」 SEO分析 どの記事が読まれているか把握しきれない SNS拡散 どの過去記事を同紹介すればいい・・・？ コンテンツ最適化 要約やタグづけなどがだんだん手間に サーバーとCMS管理 WP本体/プラグインの更新・監視が手間 「記事を書く」以外の作業に 追われると、 書きたいときに 書きたいことが 書けなくなる

執筆に関連した AIエージェント & エージェントを整備 記事公開パイプライン WordPress (EC2) 記事 pub/upd/del ▶ EventBridge Bus: wp-kyoto content-enrichment Lambda +α ▶ 境界線① 記事の後処理 ▶ SNS Topic post-to-x x-post-bot Lambda ▶ + Secrets Manager 境界線② Xへの投稿実施 blog-marketing automation EventBridge日次 → SNS pub ga-reporter 定期分析 GA4+GSC → Claude Sonnet → Slack 自己完結型 aws-wp-manager インフラ管理 Bedrock Agent + SSM Runbook → Slack 自己完結型

境界線① EventBridge — WordPress → バックエンドの疎結合 event-publisher-on-aws (PHP WP Plugin) content-enrichment PostExcerptTask Bedrock Claude → 要約→ WP書き戻し post.published post.updated ▶ EventBridge Bus: wp-kyoto PostIndexingTask Nova Embeddings → S3 Vectors post.deleted post.scheduled PutEvents (PHP直接・AWS SDK不要) AWSにワークロードをオフロード アプリをシンプルに保つことで、管理コストを抑止 ▶ PostTagTask Bedrock Claude → タグ抽出→ WP書き戻し detail-type フィルタリング PostSnsPublishTask → SNS Topic post-to-x に発行

SNS 自動拡散 — 毎朝 9 時に過去記事をランダム抽出して投稿 過去記事を ランダム選択 EventBridge スケジュール ▶ 毎日 9:00 JST Claude で 投稿文生成 ▶ 3サイト横断 WP API X(Twitter) スレッド投稿 ▶ 280文字以内 絵文字禁止 SNS→SQS→Bot 3サイト対応 バリデーション付き 過去記事の掘り起こし wp-kyoto / revtrona / hidetaka.dev の 記事を横断選択 AI臭い表現を排除。3回リトライ+指数 バックオフ(1s→2s→4s) 埋没した良質コンテンツを毎日自動 で再拡散

境界線② SNS Topic post-to-x — Fan-out による疎結合 content-enrichment (Publisher) x-post-bot (Subscriber) ▶ 記事公開トリガー ・単発ツイート投稿 SNS Topic post-to-x blog-marketing automation (Publisher) ・スレッド投稿対応 ・OAuth2 自動トークン更新 ▶ 毎日 9:00 JST スケジュール ▶ ・DLQ (SQS) フォールバック

パフォーマンス分析 — GA4 × Search Console × Claude GA4 Search Console WP API ▼ Claude → 週次レポート + 投稿別分析 週次サマリー 投稿別分析 全体パフォーマンス Markdown → S3保存 30日前の記事 個別スコアリング Slack通知 ダッシュボード レポートURL 自動投稿 Cloudflare Workers Hono.js 閲覧UI

AI Agent インフラ管理 — Bedrock Agent + Strands SDK で5ツール自律実行 get_inventory_summary() get_php_eol_status() WP/Plugin/Theme バージョン・更新状況 PHP EOL確認 endoflife.date API連携 get_disk_usage() ディスク使用量 90%超でSlack通知 Bedrock Agent Amazon Nova Pro + Strands SDK (Python) send_report() SNS→Slack レポート送信 get_patch_status() OSパッチ 適用状況確認 EC2内のコマンド実行は SSM Run Command、インベントリは SSM Inventory

EC2の中身は全部 SSM でインベントリし、 AIが参照できる形に

WPの更新なども SSM RunCommandでAIが実行できるように

AI系サービスもいいけど、 Systems Managerもいいぞ EC2 の SSH port、そろそろ閉じませんか？

リポジトリ間の依存関係 — 直接的なコード依存は一切ない EventBridge pub EventBridge sub SNS pub SNS sub 直接依存 pub → — — — — content-enrichment — ← sub pub → — — x-post-bot — — — ← sub — blog-marketing — — pub → — — ga-reporter 独立 (Sched) — — — — aws-wp-manager 独立 (Sched) — — — — event-publisher 設計原則： 全リポジトリは独立してデプロイ・テスト可能。EventBridge / SNS のメッセージ形式（JSON スキーマ）だけが暗黙の 契約（Contract）。

Kiro で Spec 駆動開発 requirements.md ▶ ユーザーストーリー 受け入れ基準 design.md アーキテクチャ 正当性プロパティ ▶ ▶ tasks.md 実装タスク分解 チェックリスト 実装 +検証 AWS CLIを使った ログ調査など （たまにCursor） Steering Docs — AIへのコーディング規約 cdk-infrastructure.md lambda-development.md testing-patterns.md type-definitions.md git-commit-on-task-completion.md 人力で書いていたモノレポの マイクロサービス分割作業も Kiroのワークスペースで SDDにて実現

まとめ ● やらないことを決めたら、あとは AWS で自動化する ● 多少手動でやってから設計した方が、「コレジャナイ感」は減る ○ わからないなら Vibe Codingでとりあえずプロトタイピング ● AI が利用可能な形でデータや API を整備するのが鍵 ● なんだかんだアーキテクチャはほとんど自分で考えている ● ○ 元はドデカいモノリスな Lambda 関数 → AI でモダン化した ○ やりたいことを追求すると、結果的に EDA へ行き着いた やってみてわかることばかりなので、まずは手を動かそう （ AWS CB のクレジットはこのためにある ）