AIが組んできた「件数の多い順」の自動化戦略を、「ユーザー影響の大きい順」に書き換えた話

前回の記事で、リリース手順書を200件以上分析して「現状把握」のドキュメントを作った話を書きました。今回はその続きで、自動化戦略の検討に入った段階の記録です。

戦略文書の起案も、おおむねAIに任せて進めていました。そうしたら、AIが組んできた優先度マトリクスが「件数の多い順」になっていて、「これは違うな」と感じて書き換えた、という話です。

技術選定のログでもありますが、前回記事の続編として、「AIに任せる範囲と人間が判断する範囲の境界」を、戦略策定の文脈で確かめた記録、として読んでいただければと思います。

背景：戦略文書の起案もAIに任せた

前回記事までで、リリース手順書200件超を読んで、22個のデプロイパターンに分類するところまで終えていました。半年で40件強のペースで蓄積されている手順書を、種類別に整理した状態です。

前回記事の最後にも書いた通り、ここから「どこから自動化に着手するか」を決めて、戦略文書に落とし込む段階に入ります。AWS ECS、Lambda、Pulumi、Jenkinsといった既存資産を踏まえて、現実的に進められる順番を組みたい、という動機でした。

現状把握ドキュメントの作成では、AIに大量分析を任せて、分類の妥当性は人間が確認する、という分担でやっていました。今回の戦略文書も、同じノリで進められるだろうと考えていました。AIに「自動化戦略を組んでください」と振って、出てきたものをレビューしながら詰めていく、という形です。

前提条件

AIが組んできた優先度

戦略の前段で、AIにいったん優先度マトリクスを起案してもらいました。

出てきたものを要約すると、こういう優先度になっていました。

件数 × Pulumi適性 → 優先度
- 共通後処理: 246件(全件横断)、適性◎ → 最優先候補
- APIデプロイ: 数十件、適性◎ → 次点
- バッチ系: 数十件、適性◎ → 次点
- フロント系: 数十件、適性◎ → 次点
- DB系・外部API・緊急対応: 少件数 → 後回し

AIの説明としては、「件数最大の共通後処理パターンは工数削減の効果が広く効く」「ROIが高い」「Phase 2の最初に着手するべき」というロジックでした。

一見、筋が通っているように見えます。AIが大量データから引き出した提案には、それなりに権威性のような圧があります。「件数が多いものから自動化したほうが効率的」というロジックは、頭の片隅で「まあ、そうかも」と思いかける程度には、説得力がありました。

違和感：「ユーザー目線で見たときに、それは品質に関係するのか」

ただ、戦略文書を読み進めて、AIに「CTOになったつもりでレビューしてみて」と振って自己レビューさせてみたあたりで、強い違和感が出てきました。

AIのCTOレビューでは、「共通後処理を最優先にしない理由が文書に書かれていない」「ROI最大なのに、なぜ別パターンを最優先に置こうとしているのか」という指摘が、自分自身に対する論点として出てきました。AIが自分で立てたロジックを、自分で擁護する形で「最頻パターンを最優先にすべきだ」と言ってきた、という構図です。

ここで、ふと違和感が出てきました。

共通後処理って、自動化したらユーザーの体験が良くなるのか?

共通後処理パターンの中身は、デプロイ後に必ず実行される事務的なタスク（タグ付与、デプロイ表の更新、リリースノートの追記、関係者へのアナウンスなど）です。

これらをどんなに自動化しても、プロダクトの動作そのものは変わらない。エンジニアの工数は減りますが、ユーザーが触る画面・APIの動きには、まったく影響がない。

一方で、APIデプロイ系は、失敗するとユーザーの目に直接エラーが出るパターンです。件数は最頻パターンの何分の一かにしかなりませんが、1件あたりの「失敗時のユーザー影響」が桁違いに大きい。

AIに「共通後処理のROIが高い」と言わせていたのは、暗黙の前提として「ROI = 件数 × 工数削減」を採用していたから。「ユーザーへの影響度」という軸が、評価式からすっぽり抜け落ちていた。これがAIの提案に感じた違和感の正体でした。

なぜAIは「件数の多い順」に組んだのか

AIに、「共通後処理は件数が多いが、ユーザー目線で見たときにプロダクトの品質には影響しない作業ではないか」と返しました。

そうしたら、AIはすぐに評価軸の偏りを認めて、「頻度 × 工数削減」だけで評価していたこと、ユーザー影響軸を計上していなかったことを、明確に間違いとして認めました。

ここで、自分の中で言語化されたことがあります。

AIは、与えられたデータの中で「測りやすいもの」を評価軸に組む傾向がある。件数は数えればわかる、自動化適性は技術仕様から判断できる。一方で、「ユーザーがそれをどう体験するか」は、データの中に直接は含まれていない。だから、明示的に指示しないと、評価軸から漏れる。

「ROIで判断します」とAIに言わせると、何をROIに含めるかで結果がまったく変わるのに、AIは自分で何を含めて何を含めなかったかを、明示しないままに出してくる。これは、AIが悪意で何かを隠しているわけではなく、評価式の組み方そのものに、データ中心の偏りが入る、ということなのだと思いました。

評価軸を書き換える

そこで、優先度の評価軸そのものを書き換えました。

Before（AIの起案）:

優先度 = 件数 × 自動化適性

After（書き換え後）:

優先度 = 件数 × 失敗時のユーザー影響 × 自動化適性

書き換えてマトリクスを引き直すと、優先順位がきれいに入れ替わりました。

ここで二つの大きな変化が起きました。

ひとつめは、最頻パターン（共通後処理）が、最優先から外れたこと。工数削減のみが効果で、戦略全体の検証ケースとしての価値も薄い。残しはしますが、優先度は低に置く。

ふたつめは、「件数が少ないから後回し」とAIが暗黙に扱っていたパターンが、いくつか格上げになったこと。DBのバージョンアップ、テーブル削除のような「年に数回しかないけれど、失敗するとデータが消える」系のパターンは、件数だけで見ると後回しに見えますが、ユーザー影響で見ると最優先級です。

ただし、これらは「Pulumi適性」では低いものが多い。自動化ではなく「手順品質保証」で取り込む、という別軸の戦略として組むのが筋だな、と気づきました。

結果：APIデプロイ系を最優先に置き直す

最終的に、最初の自動化対象としてはAPIデプロイ系を選びました。理由は次の3点です。

最頻パターン（共通後処理）は、件数最大ではありますが、上記3条件のいずれも満たしません。戦略全体の検証ケースとしても、ユーザー価値の早期実現としても、適していなかった。

AIに任せる範囲と、人間が判断する範囲

前回の記事で、AIに大量の手順書分析を任せた経験を書きました。そのときの境界は、こうでした。

今回の作業で、戦略策定の文脈での境界も、輪郭が見えてきました。

AIに「優先度をつけてください」と振ると、AIはデータの中で「測りやすいもの」を組み合わせて評価式を作ります。これは早くて正確ですが、評価軸そのものの妥当性は、AIが自分で問い直すことができない。「私はこの式で評価しています」という宣言と、出てきた結果はセットで提示されますが、「この式で本当にいいんでしたっけ?」を問えるのは、人間側の責任になります。

今回、AIの起案を半分通りそうになったのは、AIが「最頻パターンを最優先にすべきだ」と説得力のある形で言い切ってきたからでした。AIは「ROIで判断します」と言っていたので、ロジックとしては筋が通っているように見えた。

でも、ROIの中身を見直したら、ユーザー側の影響度がすっぽり抜けていた。「測りやすいもの」だけで組まれた評価式が、AIから出てくる時の典型的な歪みだな、と感じました。

ここを止められたのは、たぶん前回の記事を書いていたからだと思います。「AIに任せる範囲と人間が判断する範囲の境界がある」という認識を持っていたので、AIの起案を一度疑う癖が少しだけ働いた。それがなければ、件数ベースの優先度をそのまま通していた可能性が、それなりにある気がします。

副次的な気づき：費用対効果の見積もりも、AIに任せると同じ歪みが出た

評価軸を書き換えたあと、戦略文書の中に費用対効果の見積もりも入れました。これもAIに起案させました。

最初の試算では、ペイバック期間が約6年と出てしまって、「これ、感覚と合わないな」と引っかかりました。実務でこの規模の自動化を進めて、6年で回収というのは、明らかに保守的すぎる感覚があった。

「感覚と乖離している」と返したら、AIが計上漏れを認めて見積もりを修正しました。

これらを正しく入れ直したら、ペイバックが半年程度に。感覚との乖離が解消しました。

ここでも、優先度評価と同じ構造が効いていました。AIは「直接計上できるもの」しか計上に入れない。間接効果や、定性的な価値、業務外で発生する波及効果は、明示的に指示しないと入らない。

「ペイバックは何年ですか?」と聞くと、AIは数字を返してきます。でも、その数字を構成する計算式に何が入っているかは、人間が能動的に確認しないと見えてこない。これも今回の作業を通じて、体感として残りました。

ここまでの考察

今回の作業を通じて、自分の中で言葉になったことを残しておきます。

AIに戦略文書を起案させると、データから測れるものを軸に評価式が組まれます。これは便利ですが、評価軸そのものの妥当性は、AIの自己レビューでは原理的に検出できない。「件数 × 工数削減 = ROI」とAIが言い切るとき、その式の中に何が含まれていないかは、人間が能動的に問わないと見えない。

戦略文書をAIに任せること自体は、たぶんこれからも続くと思います。整理・集計・文書化の速度は、人間が手作業でやるレベルとは比較になりません。ただ、「評価軸として何を入れるか」「主語を何に置くか」については、最後まで人間が手放してはいけない部分なのだろう、と感じました。

前回記事で「AIに任せる範囲と人間が判断する範囲の境界」を意識して書いていたのが、今回の場面で結果として活きました。境界を意識する習慣は、新しい場面で何度も問い直されるのだと思います。

次に試すこと

戦略文書として、ここまでで「何を最優先で自動化するか」と「失敗が許されないパターンは別戦略で取り込む」までは整理できました。

次は、実際にAPIデプロイ系の自動化に着手するフェーズに入ります。既存のAWSリソース（共有のALB、ECSクラスタ）の制約下でどう構築するかが、検証ケースの最大の論点になりそうです。具体的にやってみてどうだったか、別の記事として残せればと思います。

戦略文書をAIと作る側としては、AIに起案させた評価式を、「この式で本当にいいんでしたっけ?」と必ず一度問い直す癖を持っておきたい、というのが今回の一番の学びでした。

書きながら気づいたことですが、前回も今回も、「AIに任せる範囲と人間が判断する範囲」というテーマを、別の場面でやり直していました。前回は「分類の妥当性」、今回は「評価軸の妥当性」。どちらも、AIが出してきた結果そのものではなく、その手前にある前提を人間が確認する、という構造です。

たぶん、AIと一緒に仕事をするときに繰り返し問われ続けるのは、この「結果ではなく前提の方」を見にいく習慣なのだろうな、と思っています。

関連書籍

今回のような AI を活用した戦略策定・デプロイ自動化・AWS 環境での運用について、さらに学びたい方におすすめの書籍です。