AIが速くなったあと、何が開発を止めるのか

最初に考えやすい対策は、通知を整理することです。完了報告を一つの一覧へ集め、優先度を付ける。確かに探す時間は減ります。しかし「この完了は現在のコードと本番のどこまでを意味するか」という照合は残ります。

コード生成の次に詰まったのは、レビューだけではありません。仕様を選ぶ、衝突を解く、証拠を受け入れる、公開を許可する、現場へ渡す。種類の違う判断が一つの受信箱へ混ざり、人の注意を取り合っていました。

業務基盤を見た後にWebサイトへ移り、問い合わせ基盤の判断をしてから再び業務基盤へ戻る。数時間前まで理解していたはずの前提が、すぐには戻りません。担当者が一人でも、製品が増えれば引継ぎは毎日起きます。

ここでDeveloper Hubの発想が出てきました。AIをもっと賢くする道具より先に、人が「いま何を決めるべきか」「最後に何が変わったか」「どの証拠が古いか」を復元する場所が必要だったのです。

人がすることには、方針を決める、危険な実行を許可する、証拠を受け入れる、現場の結果を認める、という違いがあります。全部を承認ボタンにすると、何へ責任を持ったのか分かりません。

Developer Hubでは、Decision、Clearance、Acceptanceのように人の行為を分けて考えます。これは英語を増やすためではなく、仕様を選んだことと、本番書込を許可したことと、結果を受け入れたことを混ぜないためです。公開記事では、それぞれ「判断」「実行許可」「受入」として読める言葉に戻します。

AIが空いているから新しい仕事を渡す。これを続けると、完了報告の在庫が増えます。在庫は新しいContext切替を生み、古い証拠を増やし、判断の優先順位をさらに難しくします。

そこで、同時に進める数を「今日、人が統合し受け入れられる量」へ合わせます。AIの利用率は下がるかもしれません。しかし、作りかけの数ではなく、公開・受入まで流れた仕事は増える可能性があります。

AIへ依頼を渡すこと自体は短時間です。調査、実装、テスト案、文書の下書きが同時に返ってくると、着手できる仕事は増えます。しかし返ってきたものを、どの製品の、どの判断に結び付けるかは人に残ります。差分を読む、受入条件を決める、優先順位を変える、前回の判断を思い出す。仕事が減ったのではなく、遅い場所が移ったのです。

この状態で通知だけを増やすと、むしろ状況は悪くなります。完了報告、レビュー待ち、失敗したテスト、未回答の質問が同じ受信箱へ集まり、どれを先に判断すべきかが見えなくなるからです。重要なのは情報を集めることより、今日の自分が引き受ける判断を少数にすることです。

ピース・ビズ グループでDeveloper Hubを必要とした問題もここにあります。複数のリポジトリや実行を一覧にするだけでは足りません。誰が何を主張し、それを何が確認し、どこで人の判断が止まっているかを、後から復元できる必要がありました。

AIの空き時間を基準に次の仕事を入れると、後で人の確認待ちが雪だるま式に増えます。レビューできる量、判断を切り替えられる回数、翌日に文脈を戻せる時間を先に見積もる方が現実的です。着手を遅くすることは、遅さではありません。未統合の変更を増やさないための制御です。

ここは、開発者が一人しかいない小さな組織ほど見落としやすい点です。自分が作り、自分が確認し、自分が公開し、利用者の質問も受けるなら、技術的な作業と判断作業を同じ時間に積み上げられません。予定表に空きがあっても、頭の中の文脈が空いていないことがあります。

だから、作業の量ではなく、止まっている判断の年齢を見るようにします。数時間で決められることが数日止まるなら、次の実装を増やすより、その判断に必要な材料をそろえる方が先です。AI時代のボトルネックは、生成能力ではなく、人が意味を引き受ける能力になり得ます。

AIで変更が増えると、CIを速くするだけでは足りません。同じ作業環境に別の変更が残る、テスト結果が別の版に紐付く、公開時に誰が何を許可したか分からない、といった問題が増えるからです。速さの問題に見えて、実際には隔離、証拠、認可、戻し方の問題になります。

GitHubも、自前で増減させる実行環境には一つの仕事だけを処理する一時的なrunnerを勧めています。重要なのは一時的という名前ではなく、前の仕事の状態が次の仕事へ残らないことです。作業ディレクトリ、資格情報、生成物、実行権限を仕事単位で分け、公開する成果物には変更されない版の身元を持たせます。

ピース・ビズ グループの問い合わせ基盤では、自動化を成立させるために書込権限を増やす案を見直しました。動かすことだけを目的にすると、日常の便利さのために責任境界を広げてしまうからです。Planで確認できる範囲と、明示したApplyで初めて進める範囲を分ける方が、遅く見えても長く安全に運用できます。