← 記事一覧に戻る
プロダクト

期待を超えるには、人間の時間がどれだけ必要か

Evanchen 著者 Evanchen

二つの典型的な例から始めたい。『アベンジャーズ/エンドゲーム』の最後のエンドロールと、PUBG の裏側にある制作工程だ。

この二つを手がかりに、なぜ agent の集団にはこうした仕事がまだ難しいのか、そして人間はどの工程に時間をかける必要があるのかを考えたい。

映画エンジニアリング:『エンドゲーム』のエンドロール

『アベンジャーズ/エンドゲーム』の制作スタッフ一覧。映画制作の各部門と担当者の分業が見える。

『エンドゲーム』のエンドロールの一部。撮影、編集、ポストプロダクションの調整、VFX の制作と編集といった工程が、具体的な職務と一人ひとりにまで分かれている。映画本編 © Marvel Studios / Disney。スクリーンショットは Credits Rolling による転載動画の約 01:30 より。各部門のクレジットは Marvel 公式の一覧 でも確認できる。

『エンドゲーム』の最後のエンドロールには、人類の芸術文明が生んだ壮大な結晶が、複雑な問題をどう分割統治して作られたのかが表れている。それぞれの構成要素に分けたあと、どこに必要な人間の align の時間をかけ、この水準の仕上がりにまで持っていったのか。

監督、脚本、撮影、美術、衣装、視覚効果、編集、音楽。名前は延々と流れていく。その一行一行の背後に、注ぎ込まれた人間の時間がある。

これを「映画エンジニアリング」と呼んでもいい。

これは the first one の、全体を編成し、リソースを集める力に大きく依存している。つまり、方向を決めてリソースを束ねる一人、あるいは中核チームだ。集められるリソースは異質なものばかりだからだ。文化的背景も、専門も、それまでの経験も違う人たちが、映画産業の制作工程を通って芸術を形にする。その間に、偶然の衝突が大量に起きる。

PUBG:ユーザーの目に触れる可能性がある、あらゆる細部

PUBG 公式の制作舞台裏。開発者が 3D ソフトで衣装モデルとチェック柄のテクスチャを確認している。

PUBG 公式 『The Making of Vikendi』05:43 より。雪の中でプレイヤーが身を隠すための迷彩服にも、キャラクターアセットのモデリングとテクスチャの確認という工程がある。スクリーンショット © PUBG Corporation / KRAFTON。

ゲームも同じだ。Bluehole は PUBG を運営・開発する過程で、膨大な役割や要素を切り分けてきた。しかも、ユーザーの目に触れる可能性がある細部の一つひとつまで分解しなければならない。

一枚のマップは、地形だけではない。家をどう配置するか、どこに隠れられるか、どこで危険を冒さなければならないか。足音はどちらから来るのか、銃声はどれくらい離れているのか。プレイヤーは見聞きしたものを、自分の判断に変えていく。

PUBG 公式の Vikendi 制作舞台裏で、チームが議論しているのは、雪をどうすれば「雪らしく感じさせられるか」、地表の素材によって車両の挙動をどう変えるかだ。迷彩服でさえ、雪原という環境に戻して考える必要がある。そして毎週金曜日の Playdayでは、オフィス全員で試遊し、それぞれの部分を一つの体験の中に戻して確かめる。

その下には、サーバー、アンチチート、アップデートの運用がある。プレイヤーには見えないものだが、ひとたびラグが起き、チートが蔓延すれば、その上にある目に見えるものも一緒に崩れてしまう。

clean context の agent は、まだ十分に different ではない

Agent は難しい数学ができる。たとえば OpenAI が示した数学的推論のように、推論や問題解決により多くの計算を使うことができる。ただ、映画やゲームのような作品を組み上げるには、さらに二つ考えることがある。

第一に、よく使われるマルチ Agent 編成の一つでは、切り出された SubAgent に、比較的独立した clean context が渡される。その agent には、私が「最初の attention」と呼ぶものがある。まずはこの prompt に集中できる。その前に長い履歴が積み重なって注意を散らすこともなく、メインの long-term task の膨大なコンテキストからも切り離されている。

だから、効率を求める問題や、数学・材料・タンパク質研究の中でも、制約が明確で結果を検証できる部分問題を解かせるのには、大きな価値がある。こうした分野にも洞察と創造性は必要だ。ただ、試して検証できる問題なら、何をもって進展とするかは比較的判断しやすい。

そのときは、実際の仕事の進み具合が token の消費量、つまり積み上げた知的な token の総量についていくように感じる。もちろん、ツールからのフィードバックと検証も必要だ。それがなければ、ずっと空回りしているだけかもしれない。

第二に、clean context の agent は、コンテキストがきれいになっただけで「異化」を遂げたわけではない。まだ十分に different ではない可能性がある。

一群の agent に、「あなたは監督」「あなたは脚本家」「あなたは撮影監督」とそれぞれ書くことはできる。でも、その下にあるのが同じモデル、同じ事前知識なら、prompt に書かれた役割には、一人の人間が何十年もかけて得た文化的背景や専門、それまでの経験が勝手についてくるわけではない。

人間が役割の prompt を組むだけで、秩序だった different を作り出すのも難しい。「無限の猿」のようにランダムな different を作れたとしても、それだけでは意味がない。秩序があり、人間社会の期待に align していなければならない。

有効な逸脱と、二つの目的関数

もう一つ、非常に make sense だと思う理屈がある。根っこにある話というか、目的関数のことだ。

芸術、あるいは美意識は、多くの場合、ある種の小さな流派や、それほど大衆的ではないところから生まれる。もちろん、通にも大衆にも愛される芸術もある。ただ、芸術と呼ばれるものの多くは、平均からの何らかのずれ、あるいはばらつきの大きな分布の中にある外れ値だと考えてもいい。

映画やゲームを作るときに一番大切なのは、この外れ値を際限なく積み上げることではなく、うまく編成することだ。

こうした外れ値は、映画やゲームの制作の中に現れる。異なる役割の分担、協力、ワークフロー、偶然の衝突。休憩室での雑談から生まれる idea でさえそうだ。かなり混沌としたシステムの中で、こうした有効な逸脱が生まれる。そして、その有効な逸脱こそが、凡庸な作品を傑作、masterpiece に変える鍵になる。

一方、engineer にとっては、見えないところでの多くの decision や判断は、むしろ平均への回帰に近い。すでに検証された方法を優先し、それほど多くの外れ値を必要としない。

どちらかが極端な外れ値を積み上げるべきだ、と言っているわけではない。ただ、engineer が必要とするのは厳密さであり、たいていの状況で work して、stable で、ロバストであることだ。だから多くの agent はエンジニアリングの勘がいいし、そこではわざと外れ値になってもらう必要もない。

ここに difference がある。一方は効率、もう一方は emotion、感情だ。一方は芸術に寄り、もう一方は engineer が問題を figure out することに寄っている。同じ PUBG の中でも、サーバーやアンチチートが優先するのは信頼性であり、最終局面のあの緊張感は emotion だ。本質的に異なる二つの目的関数で、定量化も難しい。

「一言で生成する」とき、省かれている工程

話を戻すと、私は「一言で映画やゲームを生成する」ことが、優れた作品を安定して生み出す方法としては、まだ成立していないと思う。

映画では、脚本、絵コンテ、撮影、VFX、編集と進むたびに、あらためて記述し、加工し、編成する。その都度、人が align している。一言の指示と最終結果だけを見ていると、その間の工程をすべて隠してしまいやすい。

記述、加工、編成の工程が少なすぎると、こちらが何も言っていない大量の部分を、モデル自身が埋めることになる。私が気になるのは、そうした output が、統計的によくある、見慣れていて、特に問題もないけれど、それほど different でもない選択に落ち着きやすいことだ。

一言では伝えきれなかった膨大な decision は、結局、制作の途中で補わなければならない。そのうえで、編成し、選別し、フィードバックを受ける必要がある。

だから、狙いを持ってこの水準に届くには、工程を分け、要所に必要な人間の労働時間をかけ、その判断を最終的にユーザーが感じ取れるものにしていく必要がある。

では、画像は?

ここには一見、矛盾がある。画像や絵画も同じ芸術の領域なのに、なぜごく短い人間の労働時間だけで、うまく人間に align できるのか。

そこに至るまでにも過程はあった。初期の「ウィル・スミスがスパゲティを食べる動画」を思い出せばいい。動画生成は、さらに面白い発展をたどるだろう。動画の情報量は途方もなく大きいからだ。人物は前後で一貫していなければならず、カメラは動き、動作には因果関係があり、前の一秒と次の一秒がつながらなければならない。数式を一つ書くなら、わずかな記号で済むかもしれない。でも、ある具体的な動画を正確に describe するのは非常に難しい。画面、動き、リズム、前後の関係を同時にはっきり伝えるのが難しいのだ。たとえば参考画像を一枚渡すだけでも、すでに膨大な情報ビットを補っている。

few-shot example を渡すのも、一言では伝えにくいこうした情報を補うためだ。言語モデルでも、Stable Diffusion のような画像生成モデルでも、アーキテクチャ、学習、パラメータ、条件として与える入力はすべて、参考例からどれだけの情報を利用できるかに影響する。

構造の異なるモデルがすべて「圧縮こそ知能」という考え方に当てはまるのか、私には分からない。ただ、入力の中に、目標と関係がありモデルが利用できる情報が豊富にあるほど、人間の期待に align した output が得られる可能性は高くなる。

違いは「隠れた部分」をどこまで許容できるか

画像生成、動画生成と、ゲームや映画のような、もっと長い long-term task の制作との違いを考えるとき、核心にあるのは、領域によって「隠れた部分」への許容度がまったく違うことだ。

一枚の画像の中で、はっきり伝えなかった部分はモデルが埋めてくれる。それなりに仕上がっていれば受け入れ、不満なら一目見て別の一枚に替える。人間がかける時間がこれほど短いのは、モデルがすでに多くのことを理解しているからでもあるし、私たちが多くの判断を任せているからでもある。

長い時間にわたる作品では、これほど多くのことを隠したままにはできない。コンセプトアートの中のドアは、ドアらしく見えればいいかもしれない。ゲームの中のドアなら、開くのか、衝突判定はどうなるのか、視線を遮れるのかにも答えなければならない。映画の中の一つの動作も、後の展開の中に位置づけられていなければならない。局所的にはお任せで埋められる選択も、長い作品の中に置けば、互いに影響し合う。

動画はすでにこの問題にぶつかり始めている。前の一秒でお任せで埋められたものを、次の一秒が引き継がなければならない。映画やゲームになると、このつながりが数秒から数時間へ、あるいはマップ全体へと広がる。

もっと厄介なのは、隠れた部分が、人間自身にも最初はよく見えていないことだ。

たとえば engineer が複雑なソフトウェア開発の仕事を説明するとき、すでに完璧な spec を持っていて、それを agent に実行させるだけということは少ない。むしろ、考えながら作っている。最初は POC も必要だし、細部の多くはまだ曖昧だ。これまでの経験、個人の intelligence、世の中にある参考例を頼りに、その霧を 40% から 50% ほど晴らせるくらいではないか。これは私の体感だ。

タスク全体の情報をどう正確に入力して、人間の期待に沿うものにするか。そのとき、repo や example を直接参考として渡せれば、話はずっと簡単になる。attention をうまく導く大量の入力 token を補えるからだ。

映画でいう参考作品や絵コンテ、ゲームでいうプレイ可能なプロトタイプも、同じことをしている。ただ、参考例で晴らせるのは霧の一部だけだ。残りは作りながら、少しずつ分解し、少しずつ align していかなければならない。

見えること

「見えること」は、世論や人々の感情に寄り添い、マーケティングをするうえで非常に重要だ。人々の期待を超えていなければならない。体感として、1.1 倍、1.2 倍よいという程度ではなく、3 倍、5 倍、場合によっては 10 倍だ。

たとえば、人々が 3 日から 5 日かけたと理解しているのに、出来上がったものは 30 日かけた水準だった。その、集団の期待を超える落差が、誰かに見せたくなる気持ちを生む。映画やゲームのような優れた芸術作品が満たすのは、効率を超えた、もっと高い次元の精神的な楽しみだ。

ここで、必要な人間の労働時間を二つに分けてみる。見えるものと、見えないもの。PUBG のあのドアや足音、『エンドゲーム』の一つひとつのカットは、見える側にある。

人間の時間を表す定規。半分は見え、もう半分はカーテンに隠れている。

必要な人間の労働時間のうち、見える部分と見えない部分。

複雑なソフトウェア開発には、見えない労働がたくさんある。ソフトウェア開発も以前から、フロントエンド、バックエンドなどの分業に分かれ、それぞれの工程に必要な労働時間をかけてきた。この点は映画エンジニアリングと変わらない。ただ、一般の人には理解しにくいので、広まりにくい。データ移行で何も失わなかったこと、障害を耐障害性の仕組みで受け止めたこと、システムが長いあいだ問題なく動いていること。どれも大切だが、一目見て分かってもらうのは難しい。

こうした労働は、コストを下げ、障害を減らすことで、大きな経済効果を生みうる。ただ、それを一般の人が直接感じ取るのは難しく、だから広まりにくい。

エンジニアリングの知能が十分に高まると、人間は邪魔をしているのかもしれない

もちろん、こう言い切るのは少し乱暴かもしれない。これは領域による違いであり、二種類の問題は異なる目的関数に仕えている。そしてエンジニアリングの側では、話はさらに先へ進む。

効率を重視する分野やエンジニアリングの領域で、intelligence が発展していくとする。一人の総監督が数百の agent を動かしている。構造としては、映画エンジニアリングとほとんど同じだ。それでも agent がさまざまな human-in-the-loop の工程で人間と align しなければならないとしたら、人間はただ邪魔をしているのではないか。実際、見分けるのは難しい。

human-in-the-loop の工程のたびに、コンテキストを人間に分かる形に翻訳し、人間の決断を待たなければならない。しかも、その決断が agent 自身の判断よりよいとは限らない。

intelligence が十分に高まったとき、つまり具体的なタスクでの agent の判断がすでに大半の人を上回り、必要な情報を手に入れられ、成果物をテストし検証できるようになったときは、全工程を agent 同士のより効率的なコミュニケーションに任せたくなるだろう。

この前提で、Astra や Opus 5.5 より先の時代について私が想像するのは、P95 以下の人間の関与は、すべて邪魔をして平均を下げている可能性がある、ということだ。多くの実装は、agent 自身のエンジニアリングの勘にさえ及ばないかもしれない。ここでいう P95 は、将来のエンジニアリング能力の分布についての私の見立てにすぎず、対応する実測はまだない。

人間がするのは、必要なときに現実社会の本当のニーズを補ったり、prompt、reference、フィードバックを通じてモデルの attention を導き直したりすることが中心になる。率直に言えば、見るべきところへ注意を戻すことだ。実行がすでに十分信頼できる部分では、人間がまだ提供できる align はごくわずかかもしれない。エンジニアリングに投入される知能の全体を見れば、人間と agent の間には非常に大きな差があるかもしれない。

でも、ゲームや映画のように、これまで studio が作ってきた芸術作品では、人間と agent の比率はもう少し穏やかで、調和したものになる。そこでは、人間の感覚、経験、選択そのものが、目的関数の一部だからだ。


← ほかの記事 詳しく見る →