では、人はいつ、何をするのか ― 生成が決定論的になったあとに残る仕事

この記事は生成AIとの対話をもとにまとめたものです。

第1回: 設計書を「データ」にして画面を自動生成する ― Spring Boot + Thymeleaf で人が HTML を書かない開発
第2回: [画面の次は Service ― 詳細設計 Excel から業務ロジックを組み立てる全体設計]（https://qiita.com/kumaboarder/items/43832e01015f9b108443）

第1回は「人が HTML を書かない」、第2回は「人が配線コードを書かない」という話でした。すると当然こう聞かれます。

じゃあ、人はいつ、何をするの？

答えを先に書きます。人の仕事はなくなりません。「書く」から「判断する」に移動します。 そして、判断した結果を書き込んでよい場所が決まっています。この記事は、その「いつ・何を・どこに」を時系列で整理します。

大前提：決定論的に作れるのは「配線」だけ

まず、このシリーズの方式が機械に保証させているのは、次の1点だけです。

IR に書いたとおりのコードと設計書が、必ず同じ形で出てくる。

保証して いない ことが2つあります。

IR に書いた内容が正しいこと — 仕様の正しさは機械には判定できない
業務判断の中身 — 定型化できない処理は manual step として最初から人間側に切り出してある

つまり「完全なコードを機械が作る」方式ではありません。正しさの判断は、最初から最後まで人の仕事として残っています。 残っていないのは、判断の結果を配線コードや HTML に手で書き写す作業です。

人の判断の着地先は4つだけ

判断の結果を書き込んでよい場所は、次の4つに固定します。

判断の種類	着地先
仕様そのものを変える・直す	IR（`specs/`）
出力のされ方・部品を変える	生成器・カタログ（`codegen/`, `ui-catalog/`, step type）
業務判断の中身を書く	manual step 実装クラス（`domain/`）
人向けの説明を残す	`docOnly`

生成物（HTML / Controller / Service 骨格）はこの表にありません。 どんなに急いでいても、人の手が生成物に触れる経路は存在しない。これがこの方式の背骨です。

タイムライン：人はいつ、何をするのか

プロジェクトの時間軸に沿って、人の仕事を並べます。

立ち上げ期（一度きり）   移行期（画面単位で一度きり）   日常（毎日）        例外時（CI 赤・指摘）
──────────────────────────────────────────────────────────────────────
お手本を作る            差分を承認する               IR を書く＝設計する   原因を分類する
カタログを決める        unknown を裁く               IR の diff をレビュー  上流を直す
撤退基準を決める        凍結を合意する               manual step を実装    例外手順を発動する

1. 立ち上げ期（一度きり）― 基準を作る

ここは人にしかできない仕事が集中します。方式全体の品質は、この時期の判断でほぼ決まります。

ゴールデン画面を3枚、手で作る。 これがプロジェクトで最後の手書き HTML です。以後すべての生成画面は、このお手本との一致で採点されます
カタログを抽出する。 ゴールデン画面から layout / widget をボトムアップで切り出す。「何を部品として認めるか」は設計判断そのもの
step type カタログを自社の Excel で埋める。 サンプルシートの1行1行に「これはどの type か」を割り当てる。ここで unknown だらけになるなら、方式を疑う材料（撤退基準）になる
DoD と撤退基準を先に決める。 「30画面の部品の8割がカタログに収まらなければやめる」を、始める前に文字にしておく

2. 移行期（画面単位で一度きり）― 承認する

既存 Excel を IR に変換する時期です。AI が変換しますが、正本の切り替えは必ず人が判断します。

逆翻訳差分を承認する。 IR から Excel を再生成し、元と比較して「意味が落ちていないか」を見る。差分ゼロなら機械承認、差分ありの画面だけ人が読む
unknown を裁く。 カタログにない行が出たら、「type を1つ増やす」か「manual step にする」かを決める。無理に AI に書かせない
凍結を組織に通す。 承認済み画面の元 Excel は編集禁止。「Excel への赤入れは変更依頼として受け、IR に反映する」というルールを、顧客・上位者と合意する。技術より根回しが仕事になる場面です

3. 日常（毎日）― IR を書くことが設計すること

移行が終わったあとの通常運転です。ここでの人の仕事は3つ。

IR を書く。 新しい画面・新しいフローは IR として書き起こします。これは事務作業ではなく、設計行為そのもの です。AI は補完・スキーマ検証・プレビューで支援する相棒であって、代筆者ではありません
IR の diff をレビューする。 300 画面のコードレビューは不可能ですが、IR の diff レビューなら現実的です。レビューの単位をコードから IR に引っ越すこと自体が、この方式の生産性の源泉です
manual step を実装し、@Disabled テストを緑にする。 設計書の備考から生成されたテスト骨子が TODO リストです。人と AI の実装力は、配線ではなくここに集中させます

4. CI が赤のとき ― 分類し、上流を直す

ゲート（コンパイル・テスト・ゴールデン比較）が落ちたときの人の仕事は、修正ではなく分類 から始まります。

分類	人がやること
仕様の不備	IR を直す
生成器の不備	生成器を修理する（AI に修理させ、人が差分を確認）
カタログ不足	部品追加を承認する（カタログは閉じた集合なので、追加は必ず人の承認）
業務の話	manual step 実装のループに回す

分類の大半はスクリプトで機械判定できます。人が判断するのは残りだけ。そして同じ原因の失敗が300画面で出ても、判断は1回、修正も1回 です。

指摘を受けたとき ― ゲートで検出できない「動くけど間違い」

ここがこの記事の中心です。上のタイムラインはすべて「機械ゲートが赤になる」ことを起点にしていました。しかし現場で多いのは、こういう指摘です。

生成された画面は動くが、業務的におかしい
使いにくい、項目の並びが実務に合わない
そもそも IR に書いた仕様が間違っていた（レビューアや顧客の指摘）

これらは テストでは検出できません。 人の目だけが見つけられる不良です。だから「人がレビューして指摘し、直す」フローは、この方式でも必要です。ただし、指摘の 着地点 を冒頭の4つに交通整理します。

人のレビュー・指摘
（画面プレビュー / 生成設計書 / 動作確認）
        │
        ▼
   指摘を分類する（人）
        │
        ├─ 仕様が違う ──────→ IR を修正
        ├─ 出方・見た目が悪い ─→ 生成器・カタログを修正
        ├─ 業務判断の中身 ────→ manual step 実装を修正
        └─ 説明が足りないだけ ─→ docOnly に追記
        │
        ▼
      再生成
        │
        ▼
   機械ゲート（コンパイル・テスト・ゴールデン比較）
        │
        ▼
   再レビュー（指摘した人が確認）

ポイントは2つです。

人の指摘も、CI の失敗と同じ振り分けに乗せる。 起点が「テストが赤」か「人の目」かが違うだけで、直す場所の選択肢は同じです。生成物への直接パッチだけは、経路として存在しません
レビュー対象を生成物ではなく IR とプレビューに寄せる。 指摘する側も「この画面のこの項目」ではなく「IR のこの行」を指せるように、IR プレビュー環境（保存即ブラウザ反映）を早期に整備します。指摘と修正箇所が1対1になり、往復が減ります

誰が判断するのか ― チーム別の持ち場

第2回のチーム分業に、「判断」の観点を足して整理します。

チーム	書くもの	判断すること
画面	画面 IR	レイアウト・項目・遷移が業務に合っているか
配線・骨格	フロー IR、生成器	step type 追加の要否、生成器修理の差分
業務	manual step 実装	備考の業務ルールをコードに昇格してよいか
カタログ管理（兼任可）	UI カタログ、step type カタログ	部品追加の承認。カタログを閉じたまま保つ番人
レビュア・顧客	変更依頼	生成設計書・プレビューへの指摘（Excel への赤入れは変更依頼として受理）

役割の名前より大事なのは、どの判断も最終的に4つの着地先のどれかに書き込まれる ことです。誰が判断しても、出口は同じです。

締め切り前の悪魔のささやき

この方式が実運用で崩れるとしたら、ほぼ確実にここです。

「リリース前日だから、生成された Controller にちょっとだけパッチを当てよう。IR は後で直すから」

「後で」は来ません。次の再生成でパッチは消え、型紙のバグは残り、生成物と正本がずれた瞬間に 方式全体の信用が死にます。 対策は精神論ではなく、仕組みで用意します。

再生成を速く保つ。 「IR を直して再生成」が「生成物に直接パッチ」より速ければ、誰も破りません。生成→テストのパイプラインが遅いことが、方式の最大の敵です
生成物編集を機械的に拒否する。 CI・フックで生成物ディレクトリへの手編集を落とす。人の善意に頼らない
緊急時の例外手順を事前に決めておく。 それでも本番障害などで生成物に触らざるを得ない場合、「触ってよい条件」「触ったら24時間以内に IR へ反映し、再生成で同じ状態になることを確認する」までをセットで文書化しておく。例外を認めないのではなく、例外を 管理する

人のスキルはどう変わるか

最後に、個人の目線で。この方式で価値が下がる仕事と、上がる仕事があります。

下がる	上がる
HTML / 配線コードを速く正確に書く	IR で仕様を過不足なく表現する（＝設計を言語化する）
設計書とコードの目視突き合わせ	カタログ・step type を「閉じた集合」として管理する
大量画面の単純実装	備考の自然言語から「昇格できる業務ルール」を見抜く
—	失敗を分類し、直すべき上流を特定する

一言でいえば、翻訳者から設計者・審査者への移動 です。AI はどの持ち場でも相棒として使えますが、承認の判子はすべて人が持ちます。

まとめ

機械が保証するのは「IR どおりに出る」ことだけ。正しさの判断はすべて人に残る
人の判断の着地先は IR / 生成器・カタログ / manual step 実装 / docOnly の4つ。生成物は含まれない
立ち上げ期は 基準を作る、移行期は 承認する、日常は IR を書き・レビューし・manual step を実装する、例外時は 分類して上流を直す
ゲートで検出できない「動くけど間違い」は、人のレビュー → 分類 → 上流修正 → 再生成 のループで受ける。指摘の入口は人、出口は必ず上流
方式を殺すのは技術ではなく 締め切り前の生成物パッチ。速い再生成・機械的な編集拒否・管理された例外手順で守る

「人が書かない」開発とは、人が要らなくなる開発ではありません。人の時間を、機械に代われない判断だけに使う開発 です。

次に書く予定の話題（シリーズ案）

自社 Excel サンプル1画面からフロー IR を起こす実例
step type カタログの埋め方（行番号・表記ゆれの扱い）
IR プレビュー環境の最小構成 ― 指摘を「IR の行」で受けるために

フィードバックや、「うちの現場ではこの判断は誰がやるのか」といった疑問があれば、コメントで教えてください。運用ルールの実例編を書く材料にします。