AIコーディングはエンジニアリングの最も痛くない部分に最適化されている

エンジニアリングにおいて、ほとんどのAIツールは新しいコードを書いているときに登場するが、午前3時にプロダクションを救おうとしているときには姿を消す。このギャップは偶然ではなく、エンジニアリング組織にとって最も高くつくものになりつつある。

午前3時14分、ダニエル（仮名）の電話が異常な音を立てた。Slackの丁寧な通知ではなく、すでに一度未確認のページャーの絶え間ないアラームだ。彼は今週のオンコール担当のシニアエンジニアで、毎月1週間その役を務めている。

チェックアウトのレイテンシが急上昇し、エラー率も上昇している。彼は目を覚まし、ラップトップを開く。重要な時計——返金された注文や月曜朝のVPとの会話につながる時計——はすでに動き始めている。

次の90分が実際にどのようなものかを紹介しよう。美化されたレトロなバージョンではなく、リアルなものだ。

彼は誰もが始める方法で始める：「何が変わったのか？」この質問は単純に聞こえるが、そうではない。答えは互いに連携しない6つのツールに散らばっている。デプロイダッシュボードを確認すると、過去数時間に3つのサービスがリリースされている。チームのSlackをスクロールし、200件のメッセージの中から誰かが支払いパスに触れたことに言及していないか探す。会社の内部検索（良いものにお金を払っている）を開き、「checkout retry timeout」と入力すると、2023年のランブック、2つの設計書、未完成のConfluenceページが山のように返ってくる。検索は技術的には成功したが、質問には答えなかった。彼はそれらを一つずつ開き、ざっと目を通し、最新かどうかを判断し、次へ進む。午前3時に、約3時間の睡眠で手作業でシステムの全体像を合成している。

30分経っても、まだ何も修正できていない。彼は自分のシステムの絵を組み立てているところだ。

彼が遅いわけではない。これが仕事の本質だ。インシデント対応の分析によると、時間の40%から60%がツール間でのコンテキスト再構築に費やされ、エンジニアは調査を始める前に15〜25分かけて散らばった情報を収集している。典型的な障害では、Slackに5分、最近のコミットを確認するのに10分、ダッシュボードのレビューに5分を費やし、それからようやく——25分後——特定のデプロイがスパイクを引き起こしたと理解する。何をすべきかがわかれば、技術的な修正はしばしば簡単だ。何をすべきかを知る地点に到達することが、夜を費やすところなのだ。

最終的にダニエルは時系列の形状で絞り込む——レイテンシがのこぎり波状に増加し、リトライが積み重なっているように見える。今度はそれを確認するためのデータが必要だが、これは単に別のツールを使うというだけでなく、まったく異なる作業モードになる。メトリクスバックエンドに対してアドホックなクエリを書き、時間ウィンドウを調整し、必要な数字を取得するための使い捨てスクリプトを作成する。事前に誰も構築しなかったダッシュボードは存在しないからだ。ターミナル、ブラウザ、メトリクスツール、そしてまたターミナル。ツールを切り替えるたびにフローが途切れ、強制的に方向転換を強いられる。

彼は原因を見つけた。誰かが午後のデプロイの一つでリトライ上限を引き上げていた。上限が設定されていたのには理由があった——常に理由はある——しかしその理由は8カ月前のコードレビューのコメントと、今は幸運にも眠っているスタッフエンジニアの頭の中に存在する。ダニエルは判断を下し、修正をプッシュし、グラフが正常化するのを確認し、チャンネルに全快を投稿する。

そして彼が最も嫌う部分がやってくる。

彼はすべてを書き留めなければならない。タイムライン、根本原因、自分が下した決定、フォローアップを含むポストモーテム——次の人が同じ夜を繰り返さなくて済むように。午前5時、彼は疲れ果てて薄っぺらで味気ないバージョンを書くことになるとわかっている。そして3カ月後、誰かが類似の問題に直面し、自分の午前3時をゼロから始めなければならないだろう。そもそもこの文書をどうやって見つけるのだろうか？

ここで注目すべき点がある。

その夜の間、会社が投資していたAIツールはどこにも彼に何も提供しなかった。

数秒でサービスをスキャフォールディングできるコーディングエージェント？沈黙。PRDを起草し、ミーティングを要約する同僚エージェント？どこにもいない。

「AIはソフトウェア開発を変革している」という約束は、ダニエルの仕事が最も困難で、リスクが最も高く、会社が積極的に損失を出していた90分間には完全に欠如していた。エージェントはハッピーパスコードを書く楽しい部分には存在するが、シニアエンジニアが人生の大半を過ごす運用の現実には存在しない。

それは、あなたが思っている以上に気になるべきだ。

これは決してコーディングの問題ではなかった

ダニエルの夜を再生し、各ステップで「実際に何が欠けていたのか？」と問いかけよう。

コードを書く能力ではなかった。彼はほとんど眠っていてもコードを書ける。毎回欠けていたのは、組織のどこかに存在するが、必要な時に必要な場所にない知識だった。

過去4時間に何が変わったか？それはデプロイログとPRに存在した。リトライ上限が何に設定され、なぜか？それはレビュースレッドに存在した。以前に誰かがこの形状を見たことがあるか？それは表面化できなかった過去のインシデントに存在した。修正は、彼が十分なコンテキストを再構築した瞬間に現れた。

インシデントの各ステップは、インシデントの衣をまとった知識問題だった。検索ツールが失敗したのは、それが悪かったからではなく、読むべき文書の山を見つけることが質問に答えることと同じではないからだ。午前3時、合成税は最も高価な通貨で支払われる：ストレス下で、時計と向き合うシニアエンジニアの注意力だ。

これは、どの組織図も示さないシニアエンジニアに関する静かな真実だ：最も経験豊富な人々は、会社の生きた知識層として機能している。チームが「ダニエルに聞く」理由は、ダニエルが頭の中に、システムが実際にどのように機能し、なぜそうなのかのマッピングされた、調整された、最新の、ソース付きの理解を持っているからだ。これは会議で決定され、レビューで議論され、以前の障害で苦労して学び、機械や新人がアクセスできる場所には決して書き留められなかったものだ。彼は知識ベースだ。それは彼が眠っている間、休暇中、または会社を去って唯一のコピーを持ち去るまでは素晴らしい。

これは小さな、または珍しい問題ではなく、単なる平均的なエンジニアリングの日だ。複数の研究が、開発者がアプリケーションコードを書くのに実際に費やす時間は約16%だけで、残りは運用とサポート作業——監視、メンテナンス、調整、そして終わりのないコンテキストの追跡——に費やされていることを一致して発見している。約64%が、1日に30分以上を単に何かを検索することに費やしていると報告し、3分の1は1時間以上費やしている。真のボトルネックは決してコードを書くことではなく、知ることだった。

AIは16%の部分で劇的に向上したが、残りの84%はほとんど動かなかった

これが、「AIがエンジニアリングの速度を改善する」というロードマップに賭ける誰にとっても複雑になる点だ。

コーディングハーネスは非常に速く非常に良くなったが、時折のスタブや幻覚APIは別だ。管理された試験では、よく知っているコードベースで作業する経験豊富な開発者は、AIツールを使用すると測定可能なほど遅くなり、さらに顕著なことに、自分は速くなったと信じていた。研究を実施した人々と開発者自身の両方がスピードアップを予測していた。現実は逆で、参加者はそれを感じることができなかった。

その発見を正直に、ただし注意点を付けて受け止めるべきだ——成熟したコードベースで2025年初頭のツールを用いた小規模な研究。モデル、コーディングハーネス、ワークフローが成熟するにつれて、ギャップはおそらく狭まっている。重要なのは認識のギャップだ：エンジニアは実際に速くなっているかどうかに関わらず、自分は速くなったと感じる。つまり、その感覚はエンジニアリング組織を運営するための指標にはならない。

コーディングから一歩引いて、より大きなパターンが見えてくる。エージェント支援作業が失敗する理由のエンタープライズ分析は、常に同じ犯人に行き着く：生のモデル能力ではなく、欠落したコンテキストと計画——エージェントが制約、組織の機能方法、または明示的に書き留められていないものを知らなかったこと。能力曲線は垂直に成長したが、チーム固有の運用知識の曲線はまったく動かなかった。リトライの根拠、一緒にデプロイしなければならないコンポーネント、運用上の落とし穴——それらは依然としてダニエルの頭の中だけに存在する。人々の頭の中に閉じ込められ、ツールに散らばっている。

したがって、利益は知識が誰かの頭の中にある特定の場所で停滞する。それはまさにダニエルが午前3時14分に立っていた場所だ。

さらにエージェントを導入すると状況は悪化する

本能的な反応は、「じゃあ、エージェントを運用作業にも向けよう」というものだ。良い本能だ。しかし、エージェントを追加すると知識ギャップに何が起こるかに注目してほしい。

すべてのエージェントは、記憶のない真新しい新入社員だ。アーキテクチャレビューに参加したことがなく、支払いと在庫を一緒にデプロイしなければならないこと、または昨年春の「一時的な」レートリミッターが今や構造的なものになっていることを知らない。したがって、すべてのエージェントは毎回、新しいエンジニアが尋ねるのと同じ質問を再び尋ねる——そして答えは依然としてシニアの頭の中に生きている。あなたはダニエルのコンテキスト負荷を減らしていない。むしろ、彼にコンテキストを尋ねるものの数を掛け算し、それらすべてを同じ文書化されていないボトルネックに向けている。

一方で、基盤の劣化は続く。部族の理解は、去る人や再編のたびに侵食される。新しいエンジニア——人間もエージェントも——はゆっくりと立ち上がる。なぜなら、オンボーディングはまさにこの文書化されていない知識の転送であり、その転送はより多くの人を雇ったり、より多くのエージェントを立ち上げたりすることでスケールしないからだ。運用負荷が5年ぶりに30%増加する中、負荷は増加し、それを処理する知識はより薄く、より薄く広がっている。

エンジニアリング組織がよりエージェント化すればするほど、文書化されず、調整されず、人に閉じ込められた知識がすべてのボトルネックになる。より多くの能力を購入することはできても、チームが決して書き留めなかったコンテキストを買い戻すことはできない。

優れたチームがそれに対して始めていること

先を行くチームは、作業知識を真のインフラ層として扱っている——人々の頭の中に偶然蓄積される副産物としてではなく。以下はそのいくつかの動きだ：

理由を捉え、内容だけでなく。マージされたPRは何が変わったかを記録する。なぜリトライ上限が2でなければならないかの推論は、通常、レビュースレッドに消え、その後人間の記憶に消える。インシデントを引き起こす決定は、その根拠が次の人が見る場所に決して書かれなかったものだ。

制約を作業が行われる場所に置く。インシデント中に誰も開かないConfluenceページにあるルールは、存在しないのと同じだ。知識は行動の瞬間——差分が書かれているとき、変更がレビューされているとき、ページが発火しているとき——に表面化しなければならない。参照することを覚えておく必要があるWikiの中にあってはならない。

コンテキストを第一級の成果物として扱う。シニアが提供するのと同じ調整された答え——現在の、ソース付きの、システムに固有の——を、チームは意図的に構築し維持する必要がある。

インシデントから知識へのフィードバックループを閉じる。ダニエルが午前5時に書くのを嫌うポストモーテムは、まさにこの層を養うために存在する。悲劇は、それが疲れた人間による手動の税金であり、キャプチャする必要があるもののほとんど——タイムライン、デプロイ、決定、スレッド——はすでにそれが起こるのを見守ったシステムに存在していることだ。

最後の点が重要だ。オンコールが知識問題である理由は、それが解決可能である理由でもある——次の対応者が必要とするすべてのものは、すでにどこかで生成され記録されている。それを、重要だった瞬間に一つの現在の答えに調整するだけでよかったのだ。

修正の形

ダニエルの夜が一つのことで変わったところを想像してほしい。

ページが発火する。ダニエルがラップトップを開く前に、エージェントが問い合わせる：「過去4時間にチェックアウトで何が変わったか？」そして「チェックアウトのハード制約は何か？」彼が6つのツールを開く前に、調整された答えが彼を待っている：3つのデプロイ、その作者、そして本当に重要なコードレビューのコメント。彼はもはや合成する必要はなく、直接行動できる。チームは知識を応答に組み込んでおり、午前3時の手動合成に任せていない。