AIはこれらの問題を生み出したわけではない。単に迂回するのをやめただけだ

筆者はここ数年、仕事でAIを多用してきた中で、興味深い観察を得た。AIを軌道に乗せ、生産性を高め、予測可能にし、リスクを減らすために設定してきたすべてのガードレールは、実は最初からやっておくべきことだったのだ。テスト、ドキュメント、明確な所有権、最新のドキュメント、決定論的検証——どれも新しいものではなく、特に議論を呼ぶものでもないが、AIに主導権を握らせた瞬間、それらがどれだけ欠けていたかが明らかになる。

AIは目的を達成するための最短経路を見つけるのが非常に得意で、しばしば花壇を横切って野菜の上を通る。人間には明らかでも、AIには全くそうではない。開発者の経験が増えるにつれ、多くの問題は背景ノイズとなり、無意識に迂回するようになる。例えば、3〜5年前のコールバックフックで、子モデルの順序を検証するもの。一度に30レコード以上更新すると遅くなる。それは文書化されておらず、コメントもなく、リンターも捕捉できず、誰が書いたかもわからない。人間のチームでは経験則で避けられるが、AIにはその記憶がなく、そのまま突っ込んでデッドロックを引き起こし、午前3時にページャーが鳴る。

人間であれば、システムの失敗を問うが、AIにも同じ考え方を適用すべきだ。AIはカオスエンジニアリングのように機能する。NetflixのChaos Monkeyがサーバーをランダムに破壊するように、AIはあなたが考えもしなかったギャップや穴を見つけ出す。AIはコードの書き方、ドキュメントの必要性、システムの堅牢性に関する前提をストレステストしている。

問題は、ツールがAIを想定して設計されていないことだ。RSpecを例にとると、AIはテストスイートを実行し、失敗を取得して、何が間違っているかを把握する必要がある。しかし、それは人間向けの出力であり、AIは複数回試行錯誤する必要がある。必要なのは構造化された出力、つまりJSON形式の失敗リストだ。同様に、Rubocop、Minitestなど、人間が解釈することを前提としたツールは、エージェント向けではない。筆者はすべてのAIツールにJSONを出力させ、それを再解析するようにし、生のコマンドを禁止して構造化出力を保証するラッパーを使用している。これにより、AIが問題を診断する効率が大幅に向上した。

ツール開発において、筆者は80/20ルールを提唱する。80%は決定論的なコード（型チェック、lint、テスト、機能フラグ、段階的ロールアウト）で、20%はAIの柔軟性（要約、ルーティング、分類）に任せる。人間が100%AIに依存しようとすると、データ漏洩やトークンのコミット、銀行口座の空っぽ化などの壊滅的な障害が発生する。

AIは長年のシステム問題を修正するよう強制する。ドキュメントはエージェントのために書かれ、テストは意味を持ち、所有権は明確になる。AIのために修正したギャップは、人間も同様に陥る可能性がある——新人、異動してきたシニア、納期に追われる契約社員。これらの問題は常に存在したが、AIは無視することを難しくした。筆者はSquareで新メンバーに製品を使わせ、「WTFドキュメント」を作成させていた。AIはまさに集団的なWTFドキュメントであり、システムのギャップを前例のない速度と規模で直視させる。

チームが失敗を個人的な問題ではなくシステムの問題と捉えるときに成功するように、AIシステムも同様である。「何が欠けていたのか？」と問うチームは、「AIは悪い」と問うチームよりも良い結果を得る。すべての問題にきれいな答えがあるわけではないが、システムを正直に見つめる実践は良いエンジニアリングであり、AIによって変わるものではない。むしろ、障害に耐性を持つ運用上優れたシステムを作る必要性は今やかつてないほど高まっている。その必要性は常にあったが、AIがそれを無視できない問題にしたのだ。