AIで増えるのは「実装速度」ではなく「設計試行回数」だった

以前、自分は「AIに判断させない」を中心に、「どこで人間が判断を終わらせるか」から考える Junie の使い方を書きました。

この続編（？）として、最近思っていることを書いておこうと思います。 (事業会社側のITエンジニアとして働いてますが、SIerにも10年くらいいたので、そっちの気持ちも多少わかるつもりです。もう8-9年前であり、今の実態は分からないので何か言う気もないけど)

AIは「設計能力」を持たないが、「設計の試行回数」を爆増させる

AIコーディングの“速さ”は、タイピング速度でも「AIが勝手にいい感じに構造化してくれる」でもないです。本質は以下だと思っています。

設計の案出しを大量に行ってくれる
構造の切り方を何案も試せる
「境界をここに置いたらどうなる？」を短時間で比較できる

つまり強化されるのは実装力というより "設計探索能力"。

ただしAIは、未来の運用や変更耐性を見越して“内部品質を守る判断”はまだできないと感じています。なので、ここは人間がやるしかないという認識です。

外部品質だけで満足すると、内部品質は静かに死ぬ

最近自分のxのタイムラインにもAIが書いたコードはレビューすべきかといった内容が流れてきますが、品質だったり責任のコンテキストが違うからすれ違いが起きているように見えています。議論がすれ違うのは、外部品質（動く/速い/要求満たす）と内部品質（変更しやすい/壊れにくい/読みやすい）を分けずに話してるからなんじゃないかというのを思っています。（なので、これ書いてみようかなと思ったわけではありますが。）

また、商流によっても重視するモノ自体が違いそうという感覚があり、一生噛み合わなさそう・・・と思いながら眺めています・・・。

自分の認識だと外部品質はAIと相性が良いです。動かすだけなら短期で満たせます。コードを書くこと自体が速いためです、ここに異論がある人はいないんじゃないかなと思います。

対して内部品質は、放置した瞬間に崩れていくんじゃないかなという認識です。 AIの書いたコードを見てそのままアプルーブする気には、これを書いている今時点だとなれません。（もう1.5年はAIだけにコード書かせてはいるけどここの認識はずっとこれ）

内部品質を疎かにすると割とすぐにボロが出るというのは経験上起きています。

パターン網羅、異常系が甘くて障害起こす
ロールバックやホットフィックスが増える
障害の調査・レポーティング・説明が増える

プレイヤー本人は「PRを出すまでの時間」が短くなったことで、速くなったと感じています。でもチーム全体から見ると、レビュー負荷、不具合対応、レポーティングなどが増え、トータルでマイナスになることは普通に起こります。

「AIで生産性が上がった」の定義がズレている

よくあるズレ：

PR数が増えた
実装が速くなった
リリース頻度が上がった

自分の身の回りでは、これらを指して生産性と言っているメンバーが多かったかなという認識をしています。

本来見るべきは別だと自分は思っていて、

リリースに伴う失敗率はどうか
障害対応/復旧時間はどうか
同じ領域の再発はどうか
変更コストは増えてないか
レビューが形骸化してないか

ここまで見ないと生産性が本当に上がったかは分からないです。もちろん、どの品質をどこまで求めるかは、契約形態や責任範囲にも依存します。

例えば短期的な要求充足や瑕疵担保期間を重視する場合と、長期運用を前提に内部品質を維持したい場合では、最適化されるポイント自体が異なるはずです。

AIは既存構造を増幅する

AIは「平均より上のコードを書く」というより、既存コードベースの構造と文化を増幅しやすいと感じています。

つまり、

良い構造には良いコードを高速に増やす
悪い構造には悪いコードを高速に増やす

という性質の方が近い認識です。

そのため、自分は「現状構造をなぞる」プロンプトではなく、「責務分離や境界そのものを見直させる」方向のプロンプトを投げて、構造ごと改善するようにしています。レビューや改善用のプロンプト自体もAIに作らせていますが、「今その変更をやるべきか」「リスクに見合うか」みたいな判断は、まだ人間側でやっています。

ただ、最近はそのフィルタリング自体にも疲れてきました。そのため、過去の自分のレビューコメントをAIに拾わせてルールファイルへ落とし込み、レビュー観点そのものを外部化する、みたいなことも試しています。

シニアがAIで強化される理由

自分の肌感ではこうです。（あんまりジュニア、シニアという言葉自体が好きではないですが・・・）

ジュニア：試行回数は増えるが内部品質を判定できず、悪い案も採用してしまう
シニア：内部品質の良し悪しが判定できるので、試行回数増加を品質向上に変換できる

「AIが人を置き換える」というより、評価能力がある人のレバレッジが上がっているという認識です。

AI導入後に、チーム内の実装差以上に、構造品質差が急に広がる理由でもあります。

じゃあ、実務で人間は何をやるべきか

雑に言えば人間の役割はこれなんじゃないかと思っています（もちろん今時点のAIの性能だとという枕詞はつく）。

問題設定：何を作るか/作らないか、境界をどこに置くか
構造設計：責務分離、依存方向、抽象の寿命、変更耐性を決める
制御：AIが壊しやすい部分にガードレールを作り、守らせる
計測：速さだけじゃなく、失敗と復旧も見える化する

AIは万能ではなく強力な増幅器。任せる場所を間違えると、壊れる速度も増幅されます（多分、が付く。自分は全部任せるを怖くて試せないので誰か試して）。

おまけ：固定エージェントにこだわらなくていい

自分は「これ一本」という固定エージェントに執着していない。作業内容ごとに求める性質が違うためです。

構造探索用
テスト補助用
リファクタリング補助用
ドキュメント生成用
生成物の内部品質チェック用（機能要件満たしてるかは自分でやる）

これは色々なエージェントを使うことになるので、用途ごとに最適化しやすいという良さがあります。

ただ、使い分け自体にも認知負荷があります。「この作業はどのエージェントが向いてるか」を毎回考える必要があるため、自分の行動を変えるコストも普通に高いです。

そのため、「もっと良いワークフローがありそう」と思いつつも、今のワークフローでそれなりに回っていると、改善への腰は重くなりがちです。

まとめ

AIで増えるのは「実装速度」ではなく「設計試行回数」
内部品質を判定できる人だけが、試行回数増加を品質向上に変換できる
外部品質だけ満たすと、障害・調査・修正で総コストは普通に増える
AIは既存構造を増幅するので、コードベースの構造品質が上限
人間は問題設定・構造設計・制御・計測をやる

開発速度が上がるのは事実。でもそれを“全体の生産性”に変換できるかは、内部品質を守る仕組みがあるかどうかで決まると思っています。