AIレビューの指摘を資産化する — 追記専用ログと予防DoDで作る自己学習ループ

Last updated at 2026-07-24Posted at 2026-07-24

本記事はシリーズ「自己学習する開発環境」の第3回です。

用語メモ

スキル: 手順書・参照資料をまとめた .claude/skills/ 配下の定義。エージェントは指示されたスキルのファイルを読んで従う（reference はスキルに同梱する参照ドキュメント）
サブエージェント: メインの会話とは別コンテキストで動く作業者。.claude/agents/ に Markdown で定義し、実装用・レビュー用など役割別に複数用意できる（作り方は前回参照）
orchestrate: 前回紹介した、設計書1枚から実装 → レビュー → PR 準備までを回す開発フロー（の操作名）
retrospective（レトロスペクティブ）: タスク後の振り返り。学んだことを環境に反映するステップ
予防DoD: 実装エージェントが提出前に自分でチェックする項目リスト（DoD = Definition of Done、「完了と言うための条件」）
worklog: タスクごとの作業記録ファイル（.claude/workspace/<タスク>/worklog.md）
P0 / P1 / P2: レビュー指摘の重要度ラベル（P0=必ず直す / P1=直すべき / P2=改善提案）
最終ゲート: マージ前に必ず通す機械チェック（typecheck・テスト）
ハーネスエンジニアリング: エージェントがミスするたび、同じミスが起きないよう環境側へ恒久修正を入れる考え方（系譜は第1回参照）

AIレビューを開発フローに組み込んだ直後、筆者のチームはある徒労感に気づきました。毎回、同じ種類の指摘が出るのです。 RORO 違反¹、カラートークン（色に名前を付けて一元管理する仕組み）を無視したハードコードhex、送信ボタンの二重送信防止漏れ、非同期エラーの握り潰し……。モデルは賢いのに、チームの過去の失敗を知りません。だから、実装を担当するサブエージェントは同じミスを繰り返し、レビューを担当するサブエージェントは同じ指摘を繰り返します。

人間のチームなら、こういうときレトロスペクティブ（振り返り）をやります。ならば AIの開発フローにもレトロスペクティブを組み込めばいい — これが本記事で紹介する仕組みの出発点です。「AIにも振り返りを」という着想自体は珍しくありませんが、本記事の主題はその先、振り返りを人の心がけではなく、マージしても壊れないデータ構造と決まったフローに落とすことにあります。

やることはシンプルです。タスクが終わるたびに、レビュー指摘のうち再発しそうなものを追記専用ログに貯めます。ログを集計してレビューエージェントの頻出違反ランキングを更新します。実装前に防げた指摘は予防DoD（提出前セルフチェック）に書き戻します。そして、効いているかを将来判定できるように実測メトリクスで現在地を記録します。この記事では、そのデータ構造から実測値まで、実物の抜粋を交えて実装レベルで見せます。

1. 全体像 — 学習が回る3つの経路

まず1枚絵です。前回紹介した開発フロー（orchestrate）の最終フェーズに「retrospective」という省略不可のステップがあり、そこから学びが3つの経路で環境に書き戻されます。

（色と枠線で役割分け: 紫・破線=学習の仕組み（retrospective・ログ・ランキング・DoD・reference反映） / 青緑・実線=エージェントの作業 / 黄・点線=計測（枠も計測の矢印も点線） / 青・太実線=開発フロー。①②③は本文の経路番号）

経路①「チェックを賢くする」: 指摘ログ → 頻出違反ランキング → レビューエージェントがよく出るミスを重点的にチェック（3章）
経路②「そもそも出させない」: 予防DoD → 実装エージェントの提出前自己チェック（4章）
経路③（補助）「環境の罠を潰す」: ビルド手順の罠などは該当スキルの reference（スキルに同梱する参照ドキュメント）へ反映。ハーネスエンジニアリングの基本動作そのもので、本記事では詳述しません

retrospective を実施するのは、フロー全体を指揮しているメインセッション（指揮者）です。orchestrate の終盤（PR 前）の手順として「省略不可」と定義してあります。実物のフロー定義から抜粋するとこうです（要約）。

6. retrospective（学習の反映・省略不可。commit/PR 前に行い、学習を同じPRに含める）:
   今回のレビュー指摘・ハマりどころのうち「次回のタスクでも起きうるもの」を選び、
   worklog に書くだけで終わらせず、反映先を判断して更新する:
   - 頻出違反 → review-findings-log.md に1指摘=1行を末尾追記
     （レビューagent定義のランキング表を直接 +1 編集してはいけない）
   - 実装前に自己チェックで防げたもの → 予防DoD へ追記
   - 環境・手順の罠 → 該当スキルの reference へ反映
   反映した内容（または「反映対象なし」の判断）を worklog に1行残す

重要なのは、retrospective が「任意の良い習慣」ではなくフローの必須ステップであることです。そして PR の切り方には対比があります: 学習内容（ログへの追記・DoD の更新）は機能実装と同じ PR に含め、逆にランキングの再集計だけは機能PRに混ぜず、main から切った単独のメンテPRで行います。理由は、再集計側は2章で、「同じPR」側は6章の失敗パターン5で説明します。

なお前提として、エージェント定義・ログ・DoD はすべてアプリのコードと同じリポジトリで Git 管理しています。だから「学習の差分が PR に乗る」「並行ブランチのマージで壊れうる」という話がこの後ずっと出てきます。

2. データ構造の設計 — なぜ「追記専用ログ」なのか

個人的に、この仕組みの中で一番話したいのがこの章です。学習データの持ち方というのは実は AI というより普通のデータ設計の問題で、並行開発と Git のマージまで考えて決める必要があります。

素朴な実装は並行ブランチで壊れる

最初は、レビューエージェントの定義ファイルにランキング表を持たせて、指摘が出るたびに回数を直接「+1」すればいいと考えていました。これが、並行開発で静かに壊れます。

ブランチAとブランチBが同時に走っていて、両方が「RORO違反: 4回」を「5回」に更新したとします。3-way マージ（共通の祖先と双方の変更を突き合わせる、Git などが使う統合方式）はどちらの変更も「4→5」なので、統合結果は「5」。2件あったはずの増分が1件に消えます。 コンフリクトすら起きないので、誰も気づきません（増分が異なる値ならコンフリクトにはなりますが、今度は手作業マージのたびに誤集計のリスクを抱えます）。

解決: 1指摘=1行の追記専用ログ

そこで、カウンタではなくイベントを記録します。

# Review Findings Log（レビュー指摘の追記専用ログ）

- **1指摘 = 1行を末尾に追記する。行の編集・削除は禁止**
  （追記専用。並行ブランチ間の3-wayマージで増分が消えないための設計）

## ログ（末尾に追記のみ）

- 2026-07-07 TICKET-123 be-review-security 認可・所有者検証漏れ — 削除APIに所有者チェックなし(IDOR)
- 2026-07-07 TICKET-123 fe-review-quality 失敗握り潰し/無限スピナー — 非同期statusを未消費で成功画面を無条件描画
- 2026-07-07 TICKET-123 fe-review-ux 二重送信防止欠如 — 保存ボタンにisMutating未配線・連打で二重送信
- 2026-07-09 TICKET-124 fe-review-convention 引数型の命名規則違反 — hook/util引数型が...Args(規約は...Params)

書式は「日付チケット番号指摘したエージェント名カテゴリ — 一言」の1行固定です。実体は .claude/skills/workspace-plan/reference/review-findings-log.md という1ファイルで、開発フローを回すスキルの参照ドキュメントとして、アプリのコードと同じリポジトリに置いています。

1行目の IDOR² のように、指摘の要点が「1指摘=1行」に圧縮されて溜まっていきます。追記専用でも、並行ブランチが同じ末尾に行を足せばコンフリクト自体は起きます。しかし解決方針は「両方の行を残す」一択なので、マージする人（またはエージェント）は迷わず機械的に処理できます。カウンタ更新のようにサイレントに増分が消えることはありません（履歴を書き換えず、起きたことを1件ずつ追記していく「イベントソーシング」というデータ設計の発想です）。

ランキング表のほうはログから作った集計表と位置づけ、直接編集を禁止します。貯めた記録から集計表を作り直す、という一方通行の関係にしておくわけです。

再集計の手順とトリガーも仕組みにする

「では、いつ・どうやって集計し直すのか」。ここも人間の記憶に頼りません。まず手順書は、ログファイル自身の冒頭に書いてあります。要約するとこの3ステップです。

ログの全エントリをエージェント別・カテゴリ別に集計する。カテゴリ名は原則、既存ランキング行の名前に寄せて名寄せし（例: ログ上の「二重送信防止欠如」と「二重送信防止なし」は同一カテゴリに数える）、新カテゴリを立てるのは既存に収まらない新種だけ
各レビューエージェント定義の「頻出違反ランキング」表を回数降順で作り直す
ログ内のマーカー last-aggregated-count を現在の総エントリ数に更新する

集計を自動化するスクリプトはまだなく、メンテPRを立てた人（か、依頼を受けたエージェント）がこの手順書どおりに実施する運用です。トリガー側は機械化してあり、ログの中に HTML コメントでマーカーを埋めてあります。

<!-- regen-threshold: 20 -->
<!-- last-aggregated-count: 0 -->

集計の進捗状態をログ本体と同じファイルで持つのは、追記とマーカー更新が常に一緒に運ばれるようにするためです。このマーカーを読むのは、スキル群の健全性をチェックする自作の lint スクリプトです（必須セクションの欠落などスキル定義の壊れを検査するもので、orchestrate のフローに「skill や agent の定義を編集したら実行して green を確認する」という手動ステップとして組み込んであります。ログもスキル配下のファイルなので、retrospective で追記するたびに実行対象になります）。lint は実行のたびに未集計行数を表示し、しきい値の20行を超えると「★再集計メンテPRを推奨」と通知します。なお20という値は経験的な初期値で、根拠のある数字ではありません。

ポイントは通知だけで lint は fail させないこと（集計遅れは事故ではないため）と、再集計を機能PRに混ぜず、main から切った単独のメンテPRで行うことです。エージェント定義の差分を機能PRに混ぜると、レビューのノイズになるうえ、進行中の他ブランチの追記と競合します。

ちなみに、この「未集計行数のカウント」を担当する lint 側の実装は、シェルスクリプト十数行です（実物から抜粋。pass は結果を1行表示する自作の関数です）。

# review-findings-log.md から2つのマーカーを読む
threshold="$(sed -n 's/.*regen-threshold:[[:space:]]*\([0-9]\{1,\}\).*/\1/p' "$log" | head -1)"
last="$(sed -n 's/.*last-aggregated-count:[[:space:]]*\([0-9]\{1,\}\).*/\1/p' "$log" | head -1)"

# 「## ログ（末尾に追記のみ）」見出しより後のエントリ行（- YYYY-MM-DD ...）だけを数える
current="$(awk '/末尾に追記のみ/{f=1; next} f' "$log" | grep -cE '^- [0-9]{4}-[0-9]{2}-[0-9]{2} ')"

backlog=$((current - last))
if [ "$backlog" -gt "$threshold" ]; then
  pass "check7: review-findings-log 未集計 ${backlog} 行（閾値 ${threshold} 超過 ★ランキング再集計メンテPRを推奨）"
else
  pass "check7: review-findings-log 未集計 ${backlog} 行（閾値 ${threshold} 以内）"
fi

大げさな基盤は何も要りません。ファイル内のマーカー2つと grep だけで、学習ループのトリガーは作れます。

lint-skill.sh の実行結果。check7 が未集計ログの行数を数え、しきい値を超えると「★再集計メンテPRを推奨」を出す（通知のみで fail はさせない）

スクリーンショットの「未集計 142 行」が示すとおり、ログには学びが着実に貯まり続けています（執筆時点で146行）。この貯金は、次の再集計メンテPRでまとめてランキングに反映されます。ログが貯まるほど、再集計1回あたりにレビューへ流れ込む学習量は増える — この仕組みは、ループが進むにつれてレビューが賢くなっていく成長型の設計です。次の一手としては、集計自体をエージェントに任せて人間は承認だけにする自動化を考えており、そうなれば再集計の頻度そのものも上げられます。

3. 経路① — 頻出違反ランキングで注意の配分を変える

集計結果は、各レビューエージェントの定義ファイルの冒頭に、こんな表として埋め込みます。初期版はこの仕組みの導入時に、それまでのレビュー指摘の記録から作成しました（2章の追記専用ログはこの時点から空で始めているため、マーカーの last-aggregated-count: 0 は初期値のままです）。以後の更新は2章の再集計メンテで行い、表の直下には「これは集計ビュー。回数を直接編集しない」という注記を埋めてあります。

## 頻出違反ランキング（過去の実指摘。回数が多い観点から先に・細かく見る）

| カテゴリ | 回数 |
|---|---|
| 非推奨配置・技術の使用 | 4 |
| データ取得ロジックのフック集約違反 | 2 |
| カラートークン無視のハードコードhex | 2 |
| Props/引数型の命名規則違反 | 2 |
| RORO違反 | 1 |

この表は集計ビュー。回数を直接編集せず、必ずログを再集計して再生成する。

（表は実物からの抜粋です。実際は8カテゴリあります）

そしてエージェントへの指示はこうです。

まず上の頻出違反ランキングの上位カテゴリから優先的に・細かく検査し、その後に残りの観点を網羅する。

これはチェックの手間（注意力）の配分替えです。チェックリストが長くなるほど1項目あたりの注意が薄まる、というのが筆者たちの体感で（人間の流し読みと同じです）、全項目を均等に見せるのではなく「実際に起きやすいミス」から順に注意を割かせる狙いです。ランキングは、その優先順位をチームの実績データで決めるための仕組みです。

この表は育ち始めの段階です。回数はまだ最大4回と小さく、現時点の順位は「実際に起きたことがある項目を上に置く」程度の意味ですが、2章のログには次の反映を待つ学びが百数十行分貯まっています。再集計が回るたびに、この表はチームの実績を反映した優先順位へ育っていきます。配分替えで検出率がどう変わるかの前後比較は、これからの計測テーマです。

4. 経路② — 予防DoD で指摘される前に潰す

レビューで検出できても、検出→修正の往復には1周分のコストがかかります。もっと良いのは、最初から出させないことです。retrospective では「この指摘、実装前の自己チェックで防げたか?」を仕分けし、防げたものは予防DoDに追記します。

予防DoD は、実装エージェントが提出前に1項目ずつ自分に当てはめる採点表です。すべて YES/NO で判定できる形に統一しています。実物はバックエンド用・フロントエンド用の2ファイル（.claude/skills/backend/reference/ と .claude/skills/frontend/reference/ に配置）で、実装エージェント定義の「自己検証（返す前に必須）」セクションからパスで参照させています。数項目抜粋します。

- [ ] 非同期処理フックが返す status（loading/success/failed）を UI で必ず消費し、
      成功画面を無条件描画しない（無限スピナー/失敗握り潰しを作らない）。出典: TICKET-123
- [ ] 送信ボタンの disabled/loading に mutation の isMutating/isPending を配線する
      （disabled を !isValid だけにしない＝連打で二重送信）。出典: TICKET-123
- [ ] カラーは design token を使用。bg-[#xxxxxx] 等の生 hex 直書きをしない
      （必要なら先にトークン追加）。

チェック結果は、実装エージェントが指揮者へ返すサマリの固定フィールドとして報告させます（「予防DoD自己チェック: NO だった項目と対処のみ列挙。全項目 YES ならその旨1行」）。専用の記録ファイルは作らず、サマリと worklog に残る形です。

追記される項目には「出典」が付く

retrospective で追記される項目には、1・2項目目のように出典のチケット番号を付けます。ルールが「誰かの好み」ではなく「実際に起きた事故」であることの保証です。あとから「このルール本当に要る?」と疑問が出ても、出典までさかのぼって判断できます。ルールの根拠をいつでもたどれるようにしておくことは、ルールが増え続ける仕組みでは特に重要です（3項目目のような初期整備分には出典がないものもあり、実物で出典付きは約3分の2です）。

自己申告の罠

運用してみて分かった重要な教訓があります。自己チェックは自己申告にすると機能しません。 実際にあった事故では、「非同期エラーを catch しているか」という項目に実装エージェントが「YES」と申告したのに、grep してみると catch のない箇所が2つ残っていて、レビューで P0 として検出されました。

対策は、チェック項目自体に検証方法を書くことです。

- ⚠️ このチェックは「grep して実際に catch があるか」で確認すること。
  （「YES」の自己申告だけで通過させない）

前回のレビュー収束ルールで「『概ね対応済み』への言い換え禁止」を紹介しましたが、思想は同じです。LLM 相手のルールは性善説で書かない。 判定を宣言ではなく検証（grep・lint・実行）に紐づけます。

とはいえ、「grep を実行したか」自体もまた自己申告です。ここを完全には縛れないので、経路②は単体で信用せず、予防DoD で漏れても経路①のレビュー（別コンテキストのエージェント）が同じ観点を独立に検査するという多層で受けています。予防は往復コストを減らすための第1層であって、最後の砦ではありません。

5. 効果測定 — metrics 行で「予防が効いたか」を数える

仕組みを作ると、それだけで満足してしまいがちです。ただ、効いているかどうかは別の話です。そこで orchestrate 実行時には、worklog に grep 可能な定型行を必ず記録するルールにしています（書式は worklog のテンプレートに「唯一の正」（single source of truth）として定義してあります）。

- metrics: 初回レビュー BE P0=n P1=n / FE P0=n P1=n（変更ファイルm件）
- metrics: 周回数 BE=n FE=n 打ち切り=none|上限|停滞|振動
- metrics: 最終ゲートfail n件（typecheck=n unitテスト=n e2e=n）
- metrics: 予防可能違反 n/初回のP0・P1指摘m

（3行目の e2e はコントローラー変更時のみの追加チェックで、通常の最終ゲートは typecheck とユニットテストです。2行目の打ち切り「上限・停滞・振動」は前回定義した強制打ち切り条件です — 上限=3周、停滞=前周から P0/P1 の残数が減っていない、振動=同一指摘が2周連続で残る・修正が往復する）

設計意図をいくつか挙げます。

分母を必ず付ける。 「P1 が16件」だけでは多いのか少ないのか分かりません。変更ファイル数を分母に添えて、タスクの規模をそろえて比べられるようにします。
「予防可能違反」を一番大事な指標にする。 初回の P0/P1 指摘のうち、既存の予防DoD やランキング掲載項目に該当した件数です。つまり「既知のミスの再発」です。新種の指摘は出て構いません（既知に縛られずチェックが働いている証拠と考えています）。減らしたいのは既知のミスだけであり、この数字の減少が予防の仕組みの直接の効果です。
判定の根拠を残す。 「既知に該当するか」の判定は指揮者（メインセッション）が、初回指摘のリストを既存の予防DoD・ランキング項目と突き合わせて行い、どの項目に該当したかを worklog に列挙して残します。判定者が LLM である以上この分類にも揺れは入り得ますが、根拠が残っていれば、あとから人間が検算できます。
その場で記録する。 初回レビューの統合直後に記録し、あとでまとめて書くのは禁止です。記憶に頼った記録は、抜けるか盛られるかのどちらかです。

- metrics: プレフィックスを固定しているので、集計はワンライナーで済みます。

grep -rh "- metrics:" .claude/workspace/*/worklog.md

実測値

実際のタスクからいくつか抜粋します（チケット番号はマスキングしています）。

タスク	変更規模	初回レビュー指摘（P0 / P1）	うち予防可能違反	修正周回	打ち切り
A（BE+FE 中規模）	16ファイル（BE8+FE8）	BE: 0 / 3、FE: 0 / 4	7件中4件	BE=1, FE=1	なし
B（大規模）	95ファイル	BE: 2 / 6、FE: 4 / 10	22件中8件	BE=1, FE=1	なし
C（FEのみ大規模）	110ファイル	FE: 2 / 16	18件中5件	FE=1	なし
D（FE 中規模）※	27ファイル	FE: 2 / 4	6件中5件	FE=2	なし
E（BE 小規模）※	9ファイル	BE: 0 / 0	0件（P0/P1なし）	BE=1	なし

※ 表は5行ですが、D と E は同一タスクを FE / BE のトラック別に記録したものなので、独立したタスクとしては4件です。E は P0/P1 がゼロで P2 のみ6件あり、修正周回1はその P2 指摘への対応によるものです。

データはまだ少なく、これは効果測定の出発点です。この表の値が基準線となり、ここからの推移で「予防が効いてきたか」を数字で判定していきます。出発点の計測だけでも、既に分かったことがあります。

初回の P0/P1 指摘の約4割（合算 22/53件）が「既知ミスの再発」だった。 タスク単位では約28%（C: 18件中5件）から約83%（D+E 合算: 6件中5件）までばらつきは大きく、合算値は最大タスクB（22件）に強く引っ張られている点には注意が要ります。この4割は、予防の仕組みで削れる余地がそれだけ大きいということです。既知のミスはレビューと修正のループが検出して直せていますが、提出前に消せればその往復コストごと消えます。ループが回ってログと DoD が育つほどこの数字は下がっていくはずで、それを確認できる状態を作れたのがこの計測の価値です。
修正ループは1〜2周で収束している。 P0/P1 が出たタスクはいずれも1〜2周で解消しており、上限3周・停滞・振動による打ち切りは計測開始以降ゼロです。正確に言えば、これは「安全装置が発火する場面がまだ来ていない」ということでもあり、打ち切りルールが実戦で正しく働くかは今後の検証事項です。
測っていなければ、どちらも「感覚」のままだった。 仕組みの効果を語るときに「体感で良くなった」しか言えないのは、検証の仕組み（Verifier）を作る側として説得力がありません。

数字の見栄えより、数字が取れる状態を先に作ること。これがこの章で一番言いたいことです。

ループを賢くしていく次の一手

この仕組みはここで完成ではなく、回しながら育てていく前提です。伸びしろとして考えている次の一手を挙げておきます。

レビュー指摘の妥当率の計測。 「迷ったら指摘する」方針のため指摘には一定のノイズが混ざります。妥当率が測れれば「指摘が減った＝良くなった」をより強く言えるようになります
運用コストの計測。 retrospective とメトリクス記録がタスクあたり何分・何トークン増やすのかを定量化し、リターンと突き合わせられるようにします
フロー実施の機械化。 retrospective や記録の実施は現在スキル記述の規範で担保していますが、metrics 行の存在を lint で検査するといった機械化で、「性善説で書かない」を仕組み自体にも適用していきます
予防DoD の新陳代謝。 追加の運用（1項目ずつ・binary な表現）は確立済みなので、次は効かなくなった項目を退役させる基準を整え、リストを筋肉質に保ちます

6. 失敗パターン・アンチパターン集

実運用で踏んだもの、設計段階で回避したものをまとめます（本文の要点の再掲を含みます）。

ランキング表の直接編集 — 並行ブランチのマージで増分が消えます（2章参照）。対策: カウンタではなくイベントを記録し、表は再生成する。
「あとでまとめて記録」 — 記憶頼みの worklog は現実からずれます。対策: 「作業完了 = ドキュメント更新まで」をフローの定義に含める。
チェックリストの無限肥大 — ミスのたびに項目を足すと、リストが長くなって全項目が流し読みされ、1項目あたりの注意が薄まります。対策: 既存カテゴリへの計上を優先し（ログ行の追記と名寄せで数える。表の直接+1ではない）、新項目は既存カテゴリに収まらない新種だけに絞る。頻度順に並べて注意を上位へ寄せる。
自己チェックの自己申告 — 「YES」と言わせるだけでは機能しません。対策: 検証コマンド（grep・lint）まで項目に書く（4章参照）。
学習の反映を「任意」にする — 任意の振り返りは必ずスキップされます。対策: retrospective をフローの必須ステップ（PR前・省略不可）に組み込み、学習内容を同じPRに含める。こうすると、機能が main に届くときには学習も一緒に届いています。
重要度の勝手な降格 — P1→P2 への降格を AI の独断で許すと、指摘の握り潰しに使われます。対策: 降格は理由付きで台帳（worklog 内に作る、連番ID・観点・重要度・状態の指摘一覧表。前回の収束ルール参照）に記録し、ユーザー承認事項にする。

まとめ — 「環境が学習する」ための最小構成

ここまで書いた仕組みは、一度にできたわけではなく、運用しながら少しずつ足していったものです。今日から始めるなら、最小セットはこのあたりだと思います。

指摘・失敗を記録する追記専用の場所を1ファイル作る（1指摘=1行なら形式は何でもいい）
レビュー用プロンプト（agent 定義）に「過去の頻出ミス」セクションを設け、最初は手動でよいのでログから反映する
指摘を「実装前に防げたか?」で仕分け、防げたものは提出前チェックリスト（予防DoD）へ。出典を必ず付ける
反映のタイミングをフローに固定する（PR 前など。「気が向いたら」にしない）
効果を1つの数字で測る（おすすめは「既知ミスの再発数」）

第1回で紹介したとおり、ハーネスエンジニアリングという用語を定着させた Mitchell Hashimoto³ は、これを「エージェントがミスするたび、同じミスが起きないよう環境側に恒久修正を入れる」考え方だと定義しています。本記事の仕組みは、それを人の心がけ頼みから、データ構造と決まったフローに作り替えたものです。狙いは、モデルの進化を待たなくても、今のモデルのまま環境の学習で成績が上がる状態を作ることにあります。

実測が示す現在地は「既知ミスの再発が約4割」。ここからループが回るたびに、ログが貯まり、ランキングと DoD が更新され、環境は少しずつ賢くなっていきます。シリーズタイトルの「同じミスを二度としない」へ、数字で近づいていくのを確認できる状態 — そこまでの土台が整いました。

次回は最終回。この「閉じる・測る・学びを書き戻す」という型を見た目のチェックに広げた、Figma to Code の測定ファースト実装を紹介します。

参考リンク

RORO = Receive an Object, Return an Object。関数の引数・戻り値をオブジェクトに統一する設計規約。 ↩
IDOR = Insecure Direct Object Reference。ID を書き換えるだけで他人のデータへアクセスできてしまう認可漏れの脆弱性。 ↩
Mitchell Hashimoto「My AI Adoption Journey」（2026年2月、https://mitchellh.com/writing/my-ai-adoption-journey）。本人は「業界に定着した用語があるかは分からないが」という断りつきで名付けています（経緯は第1回参照）。 ↩

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