エージェントが1日に生成するコード量は、もう人間が全行読める量を超えた。Addy Osmaniの「Agentic Code Quality」は、その前提の上で「品質はレビューでなく、エージェントの周りに置いた制約で決まる」と言い切る。この記事の骨格を、自分の副業運用（承認ゲート・検品・在庫監視）に当てはめ直して読む。
原文の「ソフトウェア工場ループ」（意図→実装→検証→本番→監視）を、事前制約・進行中フィードバック・本番境界・運用監視という4つの"効かせどころ"に組み替えて読む視点と、自分の運用の実例（承認ゲート・検品文化・番犬設計）をどこに当てはめたかの具体例。
Addy Osmaniのブログ記事「Agentic Code Quality」の出発点はシンプルだ。「Software quality now depends on the constraints you set around your agents.（ソフトウェアの品質は、いまやエージェントの周りに設定した制約に依存する）」。人間が生成物を1行ずつ読んで判定する、という従来のレビュー文化が、エージェントの生成速度に対してスケールしなくなったことが前提になっている。
記事はこれを「ソフトウェア工場ループ」という図で説明する。意図（intent）→実装（implementation）→検証（verification）→本番（production）→監視（monitoring）という一連の流れの中に、いくつもの品質ゲート（ユニットテスト・ミューテーションテスト・コード品質メトリクス・セキュリティスキャン・パフォーマンス検証）を差し込んでいく、という考え方だ。
原文は「意図→実装→検証→本番→監視」という5段階の図で品質ゲートの置き場所を示しているだけで、"4層モデル"というような名前付きのフレームワークを明示しているわけではない。ここでは読み手として、その図を制約を効かせるタイミングの違いに沿って4つに組み替えて整理し直す。
意図（何を作るか）の段階で、仕様やルールを先に明確にしておく制約。原文が挙げるアーキテクチャルール（ESLintのようなlintツールで強制できる規約）は、エージェントが書き始める前から選択肢を狭めておくタイプの制約にあたる。
実装・検証の段階で動くテスト失敗検知やCIチェック。「壊れたら人間かエージェントを呼び戻すフック（built-in hooks that can be used to pull in agents, or humans, when things break）」が、ここに含まれる。
本番へ進む直前の最終ゲート。ここを通過するかどうかは、変更のリスク・実績・裏付けの強さに応じて、高自律性／ゲート付き自律性／人間判断のいずれかに振り分けるという「trust model」の図で示されている（ただし原文に具体的な閾値の記述はない）。
工場ループの最後に置かれる"monitoring"。本番投入して終わりではなく、動き続けているものを継続的に観察する段階として、図のキャプションに含まれている。
原文の締めくくりはこうだ。「Quality is in the constraints that we place around our agents.（品質は、エージェントの周りに置いた制約の中にある）」。そして"自分のアプリの品質について考えるときは、この問題設定を持ち帰って、自分なりの制約駆動プランを組み立ててほしい"と読者に投げ返して終わる。以下は、その"持ち帰り"を副業運用でやってみた記録。
大がかりな新設計をしなくても、この副業ポートフォリオの既存ルールは、ほぼそのまま4つの効かせどころのどれかに対応する。
| 効かせどころ | 原文の例 | 自分の運用での実例 |
|---|---|---|
| 事前制約 | ESLintのアーキテクチャルール | 自己完結な委任プロンプトの型（絶対パス・背景・制約・ログ回収先を先に固定する） |
| 進行中フィードバック | テスト失敗を検知するCI | 本番反映前のcheck_article_accessibility.pyによるPASS確認 |
| 本番境界 | リスク別の自律性トリアージ | SNS投稿・課金・アカウント設定変更を事前承認制にするCLAUDE.md/AGENTS.mdの承認ゲート |
| 運用監視 | ソフトウェア工場ループ末尾の"monitoring" | 自動化同士に見張らせる番犬設計（月曜Claude／木曜Codexの相互監視） |
ここで気づくのは、「本番境界」だけを強くしても品質は保てないという点だ。FTP公開そのものは2026年に包括承認済みで都度確認は不要だが、そのぶん公開後の外部HTTPでの検品（AIの「できました」を信じない検品文化）と、公開中記事を安全に一括修正するマーカーコメント方式という"進行中フィードバック"と"運用監視"側の仕組みが効いて、初めて事故に気づける設計になっている。ゲートを1箇所だけ固く作っても、他の3箇所が空いていれば意味がない。
個人開発でエージェントに実装や記事執筆を任せている場合も、この4分類はそのまま棚卸しの型として使える。
4つのどれか1つだけを強くしても事故は防げない、というのが原文と自分の運用の両方から出てきた結論だった。AIコードレビューの受理率が実測4割弱にとどまるという調査も踏まえると、「進行中フィードバック」を全部人間のレビューだけに頼る設計は、そもそも最初から無理があったのかもしれない。