AI 時代に「人間が PR を読む」が限界に達した時、どこへ行くか
ai-desk 方法論 — 沖井広行 · 2026-05
この疑問は正しい。「人間がコードを読む」前提のままだと AI 並列開発はスケールしない。
では前提を変えるとどうなるか。
AI の生成速度と人間の読解速度の差が、毎年広がる。
「PR を真面目に読む」を維持しようとした瞬間、開発の総スループットは 人間の読解能力で律速 される。チーム拡張しても複数人が同じ PR を読むだけで本質改善しない。
人間がレビューしたコードでも脆弱性は出る。
「人間がレビューする」は 必要条件にも十分条件にもなっていない。安心感の根拠が弱い。
レビューは「やったほうがいい」けど、「やれば安全」ではない。AI が書こうが人間が書こうが、レビューだけで保証されるものは少ない。
人間が手放すのは「コード行を目で追う作業」、保つのは「何を作りたいか・何が動けば成功か」の判断。
人間の介入点は 最初と最後の 2 箇所だけ。間の 3 つは全て AI / 機械。
ai-desk 上の道具:
ai-desk.js (コード操作) ・ ai-eyes.js (画面観測 / 入力流し込み / 動画記録) ・ eyes-e2e.js (状態 → text 変換)。
人間の負荷が 意図の数 に比例し、コード量に依存しなくなる。
これが「個人開発でフルタイム並列実行」を成立させる構造。
読まずに作ったコード、半年後に直せないだろう?
直すのも AI。意図 (元の宣言) と E2E テストが残っている限り、AI が読み直してパッチを当てられる。
ai-desk の Emblem 単位の編集 (skeleton / focus / apply) がこのための道具。
10 万行のファイルでも該当 emblem だけ AI が読めば修正できる。
前提: AI が止まらないこと。これは API の問題ではなく、複数 AI ベンダー競合 + ローカルモデル普及で構造的に保証されつつある。
新メンバーが入った時、コード読めないと参加できないだろう?
引継ぎ資料 = 意図宣言 + 動く E2E テスト + スクショ + 動画。
新メンバーは「コード」ではなく「このサービスは何をするか」を読み、AI に修正を依頼する。
従来の「コード読んで内部仕様を察する」より、意図と実際の挙動が直接見える方が引継ぎは早い。
これは「個人開発が成立するなら、複数人開発も同じ方法で成立する」という主張。チームスケールは別問題に見えるが、実は同じ問題。
読まないと、AI が何か変なことしても気付けない
「読む」は 主観的検査。気付くこともあれば気付かないこともある (Heartbleed 2 年潜伏)。
ai-desk が頼るのは 客観的検査:
・網羅 E2E (1920 世界全部試す)
・Twin による複式数学検算 (GPU 出力を CPU 純粋関数で再計算)
・イベントソーシング + ハッシュ連鎖 (改ざん検知)
これらは「人間が読む」より 確実な信頼根拠。
アクションゲームのキャンセル・コンボ判定を 1920 世界全部 網羅テスト。
人間がレビューする規模 = 「1920 世界が全部 OK だった」という結果だけ。
個別の世界の中身は読まない。機械的に「全部試した」が保証されている方が、人間が一部読むより強い保証。
「コードを読む」を諦めるのではなく、
機械的に保証できるものに置き換える。
これは「テクニックの改善」ではなく「役割分担の再設計」。
AI が書く時代に合わせて、人間の責任範囲を意図と検証に絞る。
その瞬間、コード量がいくら増えても、人間の負荷は意図の数しか増えない。
github.com/AoyamaRito/ai-desk
沖井広行 · 蒼山りと