個人開発のモノレポを、プラットフォームエンジニアリング観点でスコアリングしながら育てている話

はじめに

これまで2本、AI（Claude Code）と一緒にモノレポを育てる話を書いてきました。仕様駆動開発で EC サイトを 1 日で作った話と、Vibe Coding で UI/UX を鍛え直した話です。どちらも「モノレポの中で何を作ったか」にフォーカスした内容でした。

今回は少し視点を変えて、そのモノレポ自体が土台としてどれだけ育っているかを書きます。
「プラットフォームエンジニアリング」は、たいてい複数チーム・複数プロダクトを抱える組織の文脈で語られます。Golden Path（黄金の小道）テンプレート、IDP（Internal Developer Platform）、セルフサービス性——どれも「大勢の開発者の生産性を底上げする」ための投資です。

では、開発者が実質 1 人（＋ AI エージェント）の個人開発リポジトリに、同じ観点を持ち込んだら何が起きるでしょうか。この記事は、backend（FastAPI）/ frontend（Vue 3）/ infra（Terraform）のモノレポを Claude Code と一緒に育てながら、プラットフォームエンジニアリングのスコアカードで定期的に自己診断している個人プロジェクトの記録です。

実はこの「プラットフォームエンジニアリング観点でスコアをつける」というやり方自体、origin-devcon が最初ではありません。もともとは別のテンプレートリポジトリ（Claude Code 用スキルを 17 個まとめた claude-fullstack-starter）を Claude Code に採点してもらったのが最初でした。

当時の評価: 開発テンプレートとして 7/10、IDP としては 2〜3/10。「舗装路（ゴールデンパス・ガードレール・DevEx）は揃っているが、IaC → CD → 可観測性 → カタログ → フリート運用というIDP 化の道のりはこれから」という、足りないものを順番で示すロードマップもこのときに得られました。

この経験から、「テンプレートとしての完成度」と「IDP としての完成度」を分けて10 点満点で自己診断する型ができました。origin-devcon では、この型をさらに10 軸（各 5 点満点）まで分解し、リリースのたびに定点観測する運用に発展させています。

対象リポジトリは JAWS-UG コミュニティ向けの学習用テンプレート（公開ミラー）。
開発は個人プライベートリポジトリで行い、リリースごとに公開用へ変換・配信しています。

9 日間の更新履歴 — スキャフォールドから今回のバグ修正まで

スコアの中身に入る前に、このモノレポの CHANGELOG.md を遡ってみます。初回リリースから今回の修正まで、実はまだ 9 日間 しか経っていません。

リリース	日付	主な出来事
v0.0.1	2026-06-27	モノレポの初期スキャフォールド（infra/backend/frontend + Dev Container）
v0.0.4 〜 v0.0.5	2026-06-27	DB 層 → 実 AWS 実行基盤（ECS Fargate + ALB + CloudFront）を追加
v0.0.6 〜 v0.1.4	2026-06-29 〜 07-01	AI 向けルール整備（`CLAUDE.md`/Copilot）・SDD 導入・カバレッジゲート
v0.2.0	2026-07-02	PWA 化・オートスケール・SSG/SEO 基盤
v0.2.1	2026-07-04	DORA メトリクス（デプロイ頻度・リードタイム）の自動計測
v0.2.2	2026-07-05	認証・認可（Cognito/JWT）・可観測性・負荷テストを一式追加
v0.2.3	2026-07-05	今回: 公開スクリプトの安全性バグ修正（#287）

インフラも認証も可観測性も一通り揃った、まさにその直後の CHANGELOG 整理作業中に見つかったのが、今回のバグでした。「積み上げてきたものを正しく公開できているか」を再点検する意味でも、良いタイミングでの発見だったと思います。

モノレポを 10 軸でスコアリングする

このリポジトリでは、「Golden Path テンプレートとしての完成度」と「IDP（組織展開したときの自己サービス性）としての完成度」を、それぞれ 10 点満点で自己評価しています。内訳は次の 10 軸（各 5 点満点）です。

軸	見ているもの
開発環境の標準化	Dev Container で誰が開いても同じ環境になるか
CI/CD	lint/test/security が PR ごとに自動で回るか
品質ゲート	ローカル・pre-commit・CI の 3 層が同じ基準か
ドキュメント / ADR	意思決定の「なぜ」が記録され続けているか
セキュリティガードレール	長期 AWS キー不使用・IAM 最小権限などが徹底されているか
観測性 / メトリクス	ログ・トレース・ダッシュボード・DORA 計測があるか
セルフサービス性	`make dev` 一発で誰でも着手できるか
API 契約管理	フロント/バック間の型がスキーマから自動生成されるか
インフラ堅牢化	WAF・KMS・DR・秘密ローテーションなど
組織スケーラビリティ	スキャフォールドや共有モジュール配布の仕組みがあるか

これが今回の作業直前のスコア。Golden Path テンプレートとしては 8.5 / 10 まで育っている一方、IDP（組織展開）としては 3.5 / 10 ——「1 人で使う分には強いが、他チームへの展開はまだこれから」という、正直な現在地が数字に出ています。

事例: 見つかったバグが、スコアを動かすまで

このスコアカードを更新する少し前、CHANGELOG を整理する何気ない作業中に、公開ミラー変換用のBash スクリプトに次のような 1 行ルールがあることに気づきました。

修正前

# 公開しないドキュメントへの参照リンク行を、残る全 Markdown から除去する
sed -i -e '/release\.md/d' -e '/sandbox\.md/d' "$md"

「release.md か sandbox.md という文字列を含む行を、丸ごと削除する」——一見合理的ですが、行の中身を一切見ていません。CHANGELOG の1文の中でたまたま docs/sandbox.md という単語が括弧書きとして混じっているだけの行まで、まるごと消えてしまいます。実際に公開リポジトリの過去タグを遡って確認すると、直近 9 リリース分すべてで、この巻き込み削除により文章が途切れたまま公開されていたことが分かりました。

このリポジトリの運用ルールは「気づいたバグは、直す前にまず issue に記録する」。今回もまずissue（#287）を立てて事象を記録し、そのうえで、削除の基準を「文字列を含むか」から

箇条書き/テーブル行の"主題"が除外ファイル自身である行だけを丸ごと削除する
それ以外の場所にある実リンクは、飾りだけを外してラベルのプレーンテキスト化する
バッククォートだけの地の文言及（クリックできないリンク）はそのまま残す

という、位置と文脈を見る基準に直しました。あわせて dry-run に残存参照の一覧チェックを追加し、次に同じ種類の見落としが起きても機械的に気づけるようにしています。

修正後に更新したスコアカードの「今回の特筆点」には、こう書かれていました。

#287：作業中に見つけたバグ（公開スクリプトの誤削除）を直す前に記録・クローズ
「発見 → 記録 → 分割 → 検証 → クローズ」のループ自体がプロダクト化している

Golden Path スコアは 8.5 → 9.0、ドキュメント/ADR は 4 → 5、セキュリティガードレールは 2 → 4に上昇。バグ 1 件を直したことそのものより、「見つけた→記録した→直した→検証した」というプロセスが回った事実が、スコアに反映される設計になっています。

なぜこの厳密さが個人開発でも回るのか

「issue 起票 → ブランチ → 修正 → dry-run 検証 → 過去リリースへの影響調査 → CHANGELOG 反映 → CI green 確認 → PR」という一連の手順は、本来ならプラットフォームチームが専任で持つようなプロセスです。個人開発でここまで律儀にやると、普通は「割に合わない」。

これが成立している理由は単純で、記録・調査・検証にかかる手間のほとんどを AI エージェントに渡せるようになったからです。人間がやるのは「この基準で直す」という判断と、PR をマージする最終確認だけ。過去 9 リリース分のタグを 1 つずつ取得して壊れ方を確認する——といった地味な調査も、指示さえ出せば数分で終わります。

つまり AI エージェントは、これまで「投資対効果が合わない」とされてきたプラットフォームエンジニアリング的な厳密さを、個人開発・小規模チームのスケールにまで引き下げた、というのがこの取り組みを通じての実感です。

おわりに

スコアカードという定点観測の仕組みを持つと、「バグを直した」という一過性の作業が、「プロセスが機能した証拠」として積み上がっていきます。プラットフォームエンジニアリングの考え方は、大きな組織だけのものではなく、AI エージェントと組むことで個人開発にも十分持ち込める段階に来ているのではないでしょうか。

同じような自己診断の仕組みを試してみたい方は、Claude Codeのようなエージェントに、まず自分のリポジトリを「プラットフォームエンジニアリング観点で採点してみて」と頼んでみることから始めてみてください。

次回も、このモノレポでの発見を何か書く予定です。