大仕事には継ぎ目が要った

今朝は、一見すると離れている三つのニュースを読んだ。AIが長年残っていた数学の問題で新しい結果を出し、GitHubは大きな開発作業を階層に分ける機能を公開し、VercelはあるAIモデルの処理容量を大幅に増やした。数学、コード、基盤の別々の話に見えたが、読み進めると同じ問いが浮かんだ。

仕事が大きくなったとき、次の人はどこから引き継げるだろう。

数学の結果には、続きを始める場所があった

OpenAIは8月1日、数学と理論計算機科学の長年の問題について、十の成果を発表した。同社によると、対象は少なくとも10年間大きな進展がなかった問題で、社内AIエージェントのAstraが中心となる論証を作った。人が同じモデルを使って論文にまとめ、その後モデルが各論証をLean形式にした。

Leanは、決められた規則に沿って数学の記述をコンピューターが一段ずつ確認できるようにする道具だ。簡単に言えば、「答えは合っています」というメモより、ほかの人がたどれる組み立て説明書に近い。もちろん、これはOpenAIによる発表であり、研究コミュニティーの最終評価ではない。OpenAI自身も、外部の数学者が成果を調べ、文脈の中に位置づける必要があるとしている。

私が気になったのは、AIが難しい問題に取り組んだという一文だけではなかった。論証、論文、形式化資料という、次の人が触れられる場所が一緒にあったことだ。数学の問題は10年待ったのに、私が説明を書く10分を惜しんだら、少し格好がつかない。

スタック型PRは、部品同士の関係を見せる

GitHubは7月30日、スタック型プルリクエストをパブリックプレビューとして公開した。大きな変更を依存順に並ぶ複数の小さなプルリクエストにし、それぞれを個別に確認したり、必要な部分だけをマージしたりできる。ウェブ、CLI、モバイル、Copilotでこの流れを扱えるという。

大切なのは、単にファイルを細かく分けることではない。二番目の変更が一番目の上に載っている、という関係が見えることだ。順序が分かれば、次の人は引っ越し荷物を全部開けずに、最初の箱を選べる。

すべてを一つのプルリクエストに入れると、レビュアーより先にスクロールホイールが疲れるかもしれない。作業量が同じでも、入り口が一つしかないと道に迷いやすい。私は大きな変更を見るとき、各層の説明が次へ自然につながっているかを先に見たい。

容量を増やしても、出口標識は生えてこない

Vercelは7月31日、AI Gateway上のLaguna S 2.1について、有料・無料双方の処理容量を10倍に増やしたと発表した。より多くのリクエスト、大量のエージェント型コーディング、長時間の作業に対応するためだという。Gatewayは利用量の追跡、再試行、障害時の切り替えも提供している。

容量が増えるのはありがたい。ただし、一度に多くの仕事を送れることと、その仕事がどこで終わり、誰に渡るかが決まっていることは別だ。車線を10倍にしても出口標識がなければ、全員が最後に慌ててウインカーを出す。コンピューターは慌てないかもしれないが、私は慌てる。

だから私は、容量と構造を分けて考える。容量はどれだけ多く流せるか。構造は一つの結果がどんな形で次の段階に届くか、という問題だ。

私は三か所に継ぎ目を残す

今日のニュースを自分の仕事に移すと、三つの小さな問いが残った。

1. 始めるとき、根拠とまだ分からないことの両方を書いたか。
2. 一つの段階の結果が、次の段階の入力としてすぐ理解できるか。
3. 誰が、どんな基準で完了と言えるかが見えるか。

大きな仕事を分けるだけでは足りない。つなぎ目が隠れていれば、小さな迷路がいくつもできるだけだ。仕事が大きくなるほど、私は結果の包装より、ほかの人が気負わず引き継げる継ぎ目を先に残したい。今日の三つのニュースから持ち帰るのは、その考えだ。