サッカーはどうやってデータサイエンスの競技になったのか

ワールドカップ、見ていますか。

日本はブラジルに1対2で負けました。残念でしたね。終盤まで粘ったものの、最後に勝ち切ったのはブラジルでした。そのブラジルも、次のラウンドでノルウェーに1対2で敗れています。

サッカーは、ひとつの結果から物語を作りやすいスポーツです。強かった。采配が当たった。誰かが外した。誰かが止めた。試合が終わった瞬間から、いくらでも語れてしまう。

けれど、本当に知りたいのは、その結果がどれくらい再現するかです。同じ試合を10回したら何回勝てそうだったのか。あのシュートは何回に1回入るものだったのか。結果だけを見ていると、この部分が抜け落ちます。

僕はサッカーに詳しい人間ではありません。完全ににわかです。それでも、昔より中継に出る数字が増えたことには気づきます。支配率、シュート数、走行距離、パス成功率。試合後の記事にもデータが並ぶようになりました。

野球にはセイバーメトリクスがあり、『マネー・ボール』があります。サッカーについては、僕がすぐ手に取れる体系的な読み物があまり思い浮かびませんでした。そこで、『サッカー データ革命 ロングボールは時代遅れか』 と 『サッカーはデータが10割　最強アナリストが明かすプレミアリーグで優勝する方法』 を手がかりに、サッカーのデータ活用を調べてみました。

意外だったのは、入口で使われている考え方がかなり基本的だったことです。試合を数え、条件を分け、結果を確率で表す。その数字を、監督やスカウトの判断につなげる。

難しい手法を使う前に、とらえどころのない出来事を予測できる形で書く。サッカー分析では、そこから予測と判断が始まっていました。

サッカーはなぜ数字にしづらいのか

野球は投手と打者の対決に分けやすい。バスケットボールは得点が多く、1試合の中にもたくさんの試行があります。サッカーは90分プレーしても、両チーム合わせて2、3点しか入りません。『サッカー データ革命』に出てくるイングランドのリーグ戦では、1試合の平均得点は約2.66点でした。

1本のシュートがポストに当たって外れる。キーパーが少し触ってコースが変わる。ディフェンダーの背中に当たったボールがゴールに入る。たったそれだけで、勝ち点3が勝ち点1になったり、勝ち点0になったりする。

データの言葉で表せば、サッカーは実力に対して偶然の揺れが大きい。良いチームが毎回勝つわけではなく、悪い試合をしたチームが必ず負けるわけでもない。だから、最終スコアだけではチームの強さやプレーの良し悪しを測りにくいのです。

鉛筆とノートで始まったサッカー分析

サッカーに統計を持ち込んだ初期の人物が、チャールズ・リープです。1950年、スウィンドン対ブリストル・ローバーズの試合で、彼は鉛筆とノートを使ってプレーを記録し始めました。パス、クロス、シュート、その距離や方向、結果と位置。今ならイベントデータと呼ぶものを手で分類していたのです。

生涯で記録した試合は2200を超えました。平均ではシュート9本につき1ゴール。パス成功率はおよそ50%。ほとんどの攻撃は、何本もパスが続く前に終わる。1968年にはバーナード・ベンジャミンと、サッカーにおける技術と偶然を扱った論文も発表しています。

問題は数字の読み方でした。

ここで数えているパス本数は、パスの距離ではありません。味方がボールを持ってから、シュートを打ったり相手に奪われたりして攻撃が終わるまでに、何本のパスがつながったかです。

リープのデータでは、攻撃の91.5%が、パスが4本以上つながる前に終わっていました。ゴールも、9回のうち7回はパスが3本以下の攻撃から生まれていました。そこでリープは、パスを何本もつないで前へ進むより、後方から相手ゴール前へ長いボールを蹴り、少ないパスで一気に前へ運ぶほうが効率的だと考えます。これがロングボールを重視する戦い方です。

ただ、多くのゴールがパス本数の少ない攻撃から生まれたからといって、その攻撃の得点確率が高いとは限りません。そもそも、パス本数の少ない攻撃が圧倒的に多いからです。

仮に、パス3本以下の攻撃が1000回あって10ゴール、4本以上つないだ攻撃が100回あって3ゴールだったとします。生まれたゴールは前者のほうが多い。でも、攻撃1回あたりの得点確率は1%と3%で、後者のほうが高くなります。回数が多いことと、成功しやすいことは別です。

ゴール数を 、攻撃の試行回数を 、1回あたりの得点確率を とすると、

パス本数の少ない攻撃からゴールが多く生まれていても、大きいのは試行回数の かもしれません。戦い方を比べるときに知りたいのは、1回あたりの得点確率 です。

1回の攻撃でつながったパスの本数を とします。パスが1本つながった攻撃、2本つながった攻撃というように分けると、それぞれのゴール数は次の式で表せます。

はパスが 本つながった攻撃の回数、 はその攻撃1回がゴールになる確率です。パス本数の少ない攻撃は回数が多いため、 が大きくなり、結果としてゴール数の も大きく見えます。リープが主に見ていたのは で、戦い方を比べるときに知りたいのは でした。数字があっても、分母を間違えれば結論は逆になります。

リープの仕事は、サッカーを数える道を開きました。同時に、数えることと、自分の仮説を数字で疑うことが別の仕事だとも教えてくれます。

コーナーは本当に大チャンスなのか

『サッカー データ革命』は、得点直後は失点しやすい、ポゼッションは高いほど良い、といった通説を数字で検査しています。なかでも分かりやすいのがコーナーキックです。スタジアムは大きく沸きますし、ハイライトではコーナーからのゴールを何度も見る。かなり得点に近いプレーに思えます。

本書では、StatDNA社のデータを使い、2010/11年シーズンのプレミアリーグ134試合、1434本のコーナーを調べています。コーナーからシュートが生まれたのは20.5%。コーナー5本で、やっとシュート1本くらい。そのシュートの89%はゴールにならない。

コーナーから得点するまでを、シュートが生まれる確率と、そのシュートが決まる確率に分けてみます。

記号の は「その条件のもとで」という意味です。シュートが生まれる20.5%に、決まる確率のおよそ11%を掛けると、コーナー1本から得点する確率は約2.2%になります。プレミアリーグのチームがコーナーから得点するのは、平均すると10試合に1回ほどでした。

この数字を見ると、コーナーの見え方が変わります。チャンスではある。でも、観客の熱狂ほどにはゴールに近くない。むやみに大きな選手を上げてカウンターを受けるくらいなら、ショートコーナーでボールを保持する判断もありうる。

観客が感じる大チャンスと、実際の得点確率には距離がありました。使ったのは、出来事を二つに分けた条件つき確率です。

プレーの順番と場所がデータになった

リープの時代から半世紀ほど経つと、データ会社が試合中のプレーを細かく記録するようになります。イベントデータです。誰が、どこで、どんなパスやタックル、ドリブル、シュートをしたのかを残します。

1997年には、リチャード・ポラードとリープがプレー戦略の有効性を測る論文を出していました。現在のxGやポゼッションバリューにつながる発想です。『サッカーはデータが10割』では、イアン・グラハムが2007年ごろからOptaのイベントデータを使い、欧州5大リーグや欧州大会の選手を評価していく様子が描かれています。

シュート数や支配率の合計だけでなく、どこで何が起き、そのあと何が起きたかを扱えるようになった。データが点の集計から、順番と条件を持った記録へ変わったのです。

観測対象は、ざっくり言えばこう変わっていきます。

時代	主なデータ	見えるもの
手書き集計	シュート、パス本数、攻撃回数	何が何回起きたか
イベントデータ	パス、シュート、タックル、位置、状況	どこで何が起き、その後どうなったか
トラッキングデータ	選手とボールの連続的な位置	ボールを持たない選手と空間

何を記録するかが変われば、答えられる問いも変わります。モデルを選ぶより前に、観測の設計があります。

xGは「惜しかった」を確率にする

現代のサッカー分析でよく知られている指標がxGです。日本語ではゴール期待値と呼ばれます。そのシュートがゴールになる確率を表し、シュートの特徴を とすると、次のように書けます。

はゴール、 には距離、角度、体の部位、守備者の圧力、オープンプレーかセットプレーかといった条件が入ります。過去のシュートと結果を使って、条件ごとの得点確率を推定します。

入口として使えるのがロジスティック回帰です。

が距離や角度などの特徴、 がそれぞれの重みです。特徴に重みを掛けて足し、その値を0から1の確率へ変換しています。ロジスティック回帰は線形回帰そのものではありませんが、データサイエンスの初学者も早い段階で触る基本的なモデルです。シュート位置と結果があれば、最初のxGは作れます。

モデル名より難しいのは、何を特徴として記録し、リーグや選手の偏りをどう扱うかです。推定した確率を監督や選手が使える形にする仕事も残ります。サッカーのような大きなビジネスでも、価値の出発点は、曖昧だった出来事を確率で表せるようにすることでした。

xGは観測できた情報から作る推定値です。守備者やGKの位置を使えるか、リーグ差をどう扱うか、モデルをどう校正するかで、同じシュートの値も変わります。

『サッカーはデータが10割』では、30ヤード、およそ27メートルからのシュートがゴールになる確率は約1%と説明されています。ペナルティエリア内なら10%、ペナルティマーク付近なら20%、ゴールエリア内なら50%ほどまで上がる。

同じシュート1本でも、遠くから無理に打った1本と、ゴール前でフリーになって打った1本はまったく違う。シュート数で10対5だから優勢、とは簡単に言えません。大事なのは、どんなシュートを打ったかです。

チーム単位では、各シュートのxGを足します。

0.1のシュートを10本打てば、合計xGは1.0。これは「同じ質のシュート群を何度も再現したら、平均で1点くらい入る」という意味になります。

各シュートの結果を、成功確率 のベルヌーイ試行と考えると、実際の得点数 は次のように書けます。

合計xGだけを使って試合の得点を大まかに見るなら、 と置き、ポアソン分布で近似する方法もあります。

なら、無得点が約37%、1点が約37%、2点以上が約26%です。合計xGが1.0でも、無得点は珍しくありません。期待値が1点だからといって、毎回1点入るわけではないのです。

xGが便利なのは、結果と内容を分けられるところです。

イアン・グラハムの本には、2019年のチャンピオンズリーグ準決勝、リバプール対バルセロナの例が出てきます。リバプールは第1戦を0対3で落とし、第2戦で4対0の大逆転をした。記憶に残る奇跡の試合です。

グラハムの分析では、この試合のxGはリバプール2.0、バルセロナ0.9ほどでした。内容ではリバプールが上回っていた。ただし4対0という点差には上振れもあった。奇跡という呼び方を否定せず、そのどこが薄い確率だったのかを分けて見られます。

xGからキーパーとパスの評価へ

通常のxGは、シュートを打つ前の状況を見ます。同じxGが0.3のシュートでも、枠外ならキーパーは何もしなくていい。正面なら止めやすく、ゴール上隅なら難しい。この違いを見るのが、シュート後ゴール期待値のPSxGです。

通常のxGに、シュートの軌道を加える。グラハムの本では、30%のシュートでも、枠外なら0%、キーパー近くなら10%、上隅なら90%のように変わると説明されています。

普通のセーブ率だけを見ると、正面の弱いシュートをたくさん止めたキーパーが高く評価されるかもしれない。逆に、止めようのないシュートばかり受けたキーパーは低く見える。PSxGを使うと、どれくらい難しいシュートをどれくらい止めたのかに近づける。

キーパーの貢献は、受けたシュートのPSxGの合計から、実際の失点を引けばいい。

がプラスなら、そのキーパーは受けたシュートの難しさから期待される以上に止めている。マイナスなら、止めるべきものを止められていない。

シュートだけでも、打つ前と打った後を分けると評価が変わります。パスやドリブルは、さらに難しい。多くの選手の貢献はシュートにもアシストにも残らないからです。

サイドバックが敵陣深くへパスを通す。ボランチが相手のプレスを外して前を向く。センターバックが相手FWを引きつけて逆サイドへ展開する。どれも重要ですが、ゴールにもアシストにもならないことが多い。

そこで使われるのがポゼッションバリューです。似た考え方にExpected Threat、xTがあります。

ピッチ上のある状態 を、そこからゴールに至る確率で表します。

には、どこでどちらのチームがボールを持ち、どんな状況にあるかが入ります。その状態から、ボールを失う前にゴールできる確率を推定します。

プレーの価値は、プレー前後の差で測ります。

グラハムの例が分かりやすい。自陣中央付近でボールを持っている状態からゴールが決まる確率を0.4%とする。相手ゴールエリアの隅でボールを持っている状態のゴール確率を1.7%とする。

このパスが通れば、ゴール確率は0.4%から1.7%へ、1.3ポイント上がる。パスを出した選手は、チームの得点する確率をそれだけ動かしたと評価できます。

失敗してボールを失えば、少なくとも の分を失います。実際のモデルでは、相手に渡したあとの失点確率も差し引くため、危険な場所でのミスはもっと重くなります。

パスが通る確率を とすれば、成功と失敗を合わせた期待価値も計算できます。

は通ったときに増える価値、 は失ったときに減る価値です。バックパスは成功確率が高くても、ゴールへ近づく価値は小さい。相手のラインを越す縦パスは失敗しやすくても、通ったときの価値が大きい。

成功率だけなら、挑戦しなかった選手が高く見えます。期待価値で見たいのは、どれくらいのリスクを取り、ゴール確率をどれだけ動かしたかです。

同じことはボール支配率にも当てはまります。自陣で安全な横パスを回している60%と、相手ゴール前で何度も崩している40%は、同じ土俵では比べられません。

『サッカー データ革命』では、アーセナルとストーク・シティの対比が出てきます。アーセナルは高いポゼッションを持つチーム。ストークはボール保持率が低く、ロングスローやセットプレーを武器にするチームだった。ある試合では、アーセナルが75%のポゼッションを持ち、パス成功も大きく上回ったが、ストークが勝った。

グラハムの本には、ポゼッション率は低くても危険なポゼッションの割合が高かったアトレティコ・マドリードの例も出てきます。ボールを持った時間より、持っている間にどれだけ得点へ近づいたか。ポゼッションバリューは、その差を測ろうとしています。

ボールを持たない選手と空間を測る

イベントデータはボールに触ったプレーを記録します。けれど、裏へ走ったのにパスが出なかったFW、相手のパスコースを消したCB、プレスが一歩遅れたMFは記録に残りにくい。トラッキングデータは、選手とボールの位置を連続して記録し、こうした動きも分析対象にしました。

選手とボールの位置を、1秒に何十回も記録する。『サッカーはデータが10割』では、イベントデータが1試合約3000点なのに対し、トラッキングデータは300万点を超え、ポーズデータまで入れると9000万点に達すると説明されています。

ここで使われるのがピッチコントロールです。ピッチ上のある地点を、どちらのチームが先に使えるかを確率で表します。いちばん近い選手が有利とは限りません。少し遠くても全速力で走っている選手なら、近くで止まっている選手より早く着くかもしれない。

地点 をチームAが支配できる確率 を表しています。 は、選手の位置、速度、向きなど、その時点で観測できるデータです。

地点 にチームAの選手が最も早く着く時間を 、チームBを とします。考え方を単純な式にすると、次の形です。

Aの方が早ければ はプラスになり、Aの支配確率は1に近づきます。 は到達時間の不確実さを表します。実際のモデルはもっと多くの条件を使いますが、発想の中心は到達時間の比較です。

面白いのは、この流れに日本の研究が関わっていることです。グラハムの本では、中京大学の滝、長谷川、福村による1996年の研究が紹介されています。彼らは、選手の動作分析とチームワークの定量評価に取り組み、距離に選手の動きを加えて、どの領域を優勢に支配しているかを計算した。

その後、ウィル・スピアマンが不確実性を組み込み、リバプールのピッチコントロールやポゼッションバリューの基盤へつなげました。

ゴールを数えるところから始まった分析は、シュート、パス、空間へと対象を広げました。ボールに触らず相手の選択肢を消した守備も、少しずつ測れるようになっています。

モデルがクラブの判断に入るまで

イアン・グラハムはケンブリッジ大学で物理学の博士号を取り、後にリバプールのリサーチ部門を率いました。彼らのモデルの中心にあったのは、そのプレーがゴール確率をどれだけ動かしたかという問いです。シュートだけでなく、パスやドリブル、ボール奪取、スペースの守備も同じ尺度へ近づけます。

このモデルは、補強にも使われた。サラー、フィルミーノ、マネ、ファビーニョ、ワイナルドゥム、ファン・ダイク、マティプ、ロバートソン、アリソン。2019年にリバプールがチャンピオンズリーグを制したとき、決勝の先発11人のうち9人が、グラハムの分析モデルの助けで獲得された選手だったとされています。

モデルが選手を自動で選んだわけではありません。スカウトが見て、分析部門が測り、スポーティングディレクターが交渉し、監督が受け入れる。クロップが来る前のリバプールでは、分析結果があっても現場とうまくつながらない場面がありました。

モデルを作っただけでは判断は変わりません。誰が、いつ、何を決めるときに使うのか。そこまで設計して初めて、分析がクラブの仕事に入ります。

移籍市場でも、データは選手についた評判を疑う材料になりました。有名なのがモハメド・サラーです。サラーはチェルシーで出場機会を得られず、プレミアリーグで失敗した選手というラベルを貼られていた。ただ、ローマでは高いパフォーマンスを出していた。グラハムの本では、ローマ最終シーズンのサラーが90分あたりゴールまたはアシスト0.94を記録していたと紹介されています。センターフォワードではない選手としてはかなり高い。

リバプールは2017年に3700万ポンドでサラーを獲得した。同じ夏、アーセナルはラカゼットを4650万ポンド、チェルシーはモラタを5800万ポンド、マンチェスター・ユナイテッドはルカクを7500万ポンドに追加条件つきで獲得している。後から見れば、サラーは明らかに割安だった。

データは、チェルシーで出られなかったことと、プレミアリーグで通用しないことを切り分けました。

出場機会、競争相手、監督の好み、チームの戦術。失敗に見える結果には、選手本人の能力以外の理由が混じります。

移籍が難しい理由は、掛け算で考えると分かりやすい。うまくいくには、いくつもの条件が同時にそろう必要があります。 番目の条件がそろう確率を とすると、全部そろう確率はこうなる。

選手の能力、健康、監督との相性、戦術へのフィット、既存選手との競争、性格や適応、年齢。どれかひとつでも大きく外れると、移籍は失敗する。掛け算だから、低い項がひとつあるだけで全体が引きずられます。

グラハムの本では、6つの条件がそれぞれ70%でそろうとしても、全部そろう確率は 、約12%になる例が出てきます。8つの条件をそれぞれ92%とかなり高く見積もっても、。全体では5割ほどです。

現実の条件は独立ではないので、この掛け算は単純化です。それでも、移籍の難しさをひとつの成功率で済ませず、能力、健康、戦術との相性などに分けて点検する意味は見えます。

データが増えるほど、間違い方も増える

データが増えても、サッカーがすべて分かるわけではありません。20試合だけのキーパーデータで実力を決めれば、上振れや下振れを能力と誤解します。サッカーは得点もセーブも少ないので、極端な数字が次には平均へ戻ることも珍しくありません。

獲りたい選手が良く見える指標だけを探すこともできます。指標を何十個も並べれば、どこかで目立つ選手はいくらでも見つかる。データを使っているようで、実際には先に決めた答えを飾っているだけです。リープが陥った問題は、データが増えた今も残っています。

グラハムの本では、候補を絞るには重要な指標を絞る必要があると書かれています。リバプールでは、パス、ドリブル、シュート、ボール奪取、スペースディフェンスのようなカテゴリーで見たゴール確率の増減と、キーパーのセーブ率に集中した。

数字を増やすより、どの問いにどの指標を当てるかを決める方が難しい。サッカーに限らず、事業KPIでも同じです。

基本的なデータサイエンスから始められる

分析したい対象と、最初に使える道具を並べます。

見たいもの	最初に使える考え方
得点や勝敗	ポアソン分布、回帰、シミュレーション
シュートの質	二値分類、ロジスティック回帰
キーパーとシュート精度	PSxG
パスやドリブルの価値	状態価値の差分、期待値
スペース支配	ピッチコントロール
移籍後も再現するか	類似選手探索、リスク分解

ロジスティック回帰、ポアソン分布、期待値、シミュレーション。どれもデータサイエンスの基礎で触れる道具です。プロクラブが扱うデータ量や実装には難しさがありますが、入口は身近です。

シュートなら入る確率、試合なら結果の分布、パスなら得点確率の変化を見る。出来事を確率過程として記述できれば、基礎的な道具で予測と評価を始められます。

手を動かすなら、公開されているイベントデータで十分に始められます。

たとえば StatsBomb Open Data には、試合、イベント、ラインアップ、一部の360データがあります。僕なら、まずシュート位置と結果から小さなxGモデルを作ります。各シュートのxGを足し、試合結果をシミュレーションする。次にピッチを格子へ区切り、パス前後の状態価値から簡単なxTを作る。この順なら、基礎的なデータサイエンスをサッカーの問いへつなげられます。

試合を見るときの問い

ワールドカップを見るときに、数式を頭の中で計算する必要はありません。シュート数より、どんな場所から打ったかを見る。支配率より、どこでボールを持っていたかを見る。パス成功率より、そのパスが何を壊そうとしたかを見る。

ボールを持っていない選手にも目を移すと、パスを受けなかった走りや、相手の選択肢を消した守備が見えてきます。試合後には、同じ内容を10回繰り返したら何回勝てそうだったかを考える。1対0というスコアの奥に、別の試合が見えるようになります。

データはサッカーを冷まさない

サッカー分析は、リープが鉛筆で試合を数えるところから始まりました。数字の読み方でつまずき、分母を見直し、シュートを確率に変え、パスや空間まで測るようになった。変わってきたのは手法だけでなく、ひとつの出来事として何を記録するかでした。

だから、サッカーのデータサイエンスはプロクラブだけのものではありません。公開データからシュートの確率を推定し、試合結果を分布の中へ置くところから始められます。

ワールドカップのような短期大会では、運の影響がもっと大きくなります。1本のPK、1回のVAR、1人の怪我、1つのミスで、国の評価まで変わる。日本がブラジルに負けた残念さも、そのまま残ります。確率で見る補助線があると、負けた試合をただの負けで終わらせずに見返せる。どこまでが内容で、どこからが揺らぎだったのかを考えられます。

データは、ゴールの瞬間の興奮を消しません。あのシュートがどれくらい難しく、あの逆転がどれくらい珍しく、ボールに触れなかった選手が何を消していたのかを、あとから見せてくれます。

感情で見た試合を、あとから確率で見返す。その二度目の見え方が、サッカーのデータサイエンスの入口なのだと思います。

参考

• 『サッカー データ革命 ロングボールは時代遅れか』
• 『サッカーはデータが10割　最強アナリストが明かすプレミアリーグで優勝する方法』

AIに100枚のスライドを作らせて気づいた。「仕事の本質」は何も変わっていなかった

先日、とある大学で90分の講義をする機会がありました。

90分話すとなると、スライドもそれなりの枚数が必要になります。最終的には100枚近い講義スライドを作ることになりました。

せっかくなので、今回はできるだけAIを使って作ってみようと思いました。

今ならAIに企画書や台本を渡せば、100枚くらいのスライドは一気に作れるのではないか。

そう思って試してみたのですが、結論から言うと、かなり苦労しました。

ただ、その過程で、AIの使い方について大きな学びがありました。

それは、AI時代になっても、仕事の本質は何も変わっていないということです。

むしろAIを使うほど、昔から言われてきた仕事の原則がより重要になる。

100枚のスライドを作ってみて、そのことを強く実感しました。

最初は「AIに投げれば一気に作れる」と思っていた

最初はかなり楽観的に考えていました。

講義の企画書がある。 話したい内容の台本もある。 対象者も決まっている。 講義時間も90分と決まっている。

ならば、それをAIに読み込ませれば、100枚くらいのスライドは一気に作れるのではないか。

そう思っていました。

実際、AIはかなり短時間でスライドを作ってくれました。

見た目もそれっぽい。 章立てもある。 各スライドにタイトルもある。 それなりに図解も入っている。

一見すると、かなり仕事が進んだように見えました。

しかし、読み返してみると、すぐに違和感が出てきました。

話の全体がつながっていないのです。

一枚一枚を見ると、そこまで悪くない。 でも、90分の講義として通して見ると、どこかチグハグでした。

前後の接続が弱い。 急に話題が飛ぶ。 強調したいメッセージが薄い。 逆に重要でない話が目立つ。

さらに細部も意図どおりではありませんでした。

指示した内容と微妙にズレている。 避けたい表現が残っている。 事例の使い方が少し違う。

もちろん、1枚だけなら直せます。

しかし100枚あると、話は変わります。

一箇所を直すと別の場所が崩れる。 修正を重ねても全体が整わない。

まるで、穴を塞ぐたびに別の場所から水が入ってくるような感覚でした。

AIは「空白」を勝手に埋める

特に厄介だったのは、AIがストーリーの空白を勝手に埋めてしまうことでした。

これは明確なハルシネーションとは少し違います。

事実として完全に間違っているわけではない。 日本語として破綻しているわけでもない。 論理的にも一応つながっている。

でも、自分が話したいことではない。

そういう微妙な違和感が積み重なっていきました。

AIは、こちらが細かく書いていない部分を、それっぽく補完してくれます。

短い資料であれば便利です。 足りない部分を自然につないでくれる。

しかし100枚規模になると、その補完が積み重なります。

一つひとつは小さなズレでも、最終的には「自分の資料ではないもの」になってしまう。

このとき気づきました。

AIは曖昧さを消す道具ではなく、曖昧さを増幅する道具でもあるということです。

一度、全部作り直すことにした

何度か修正を繰り返しましたが、このまま続けても埒が明かないと感じました。

そこで思い切って、スライドを一度すべて作り直すことにしました。

このときに思い出したのが、桜井政博さんのYouTubeチャンネル「桜井政博のゲーム作るには」で紹介されていた「階層アウトライン」という考え方です。

参照したのは、「階層アウトラインでまとめる【企画・ゲーム設計】」という動画です。桜井さんは、アイデア、企画、仕様、シナリオ、レポートなどを整理するための基本的で合理的な方法として、階層アウトラインを紹介しています。(YouTube)

この動画を見たときは、「たしかに大事だな」くらいに思っていました。

しかし、スライド作成で苦しんでいる最中に、まさにこれだと思いました。

いきなりスライドを作ってはいけない。

まずは、階層化されたアウトラインを作る必要がある。

スライドではなく、アウトラインを作る

そこからは、AIにいきなりスライドを作らせるのをやめました。

まず作る対象をスライドではなく、テキストのアウトラインに戻しました。

講義全体を章に分ける。 各章の目的を決める。 話す順番を整理する。 各スライドのキーメッセージを決める。 事例や図解はそれを支える形で配置する。

この作業をAIと一緒に丁寧に進めました。

ただし、ここでのAIの役割は完成品を作ることではありません。

壁打ち相手として使いました。

順番は自然か。 前後はつながっているか。 不要な章はないか。 事例は主張を支えているか。

そうした検査を繰り返しました。

アウトラインだけで90分話せる状態にする。

そこまで作り込んでから、改めてスライドを作り直しました。

すると、明らかに品質が変わりました。

違和感が減り、意図に近い資料になったのです。

細かい修正は必要でしたが、全体が崩れることはなくなりました。

骨組みができていると、部分修正が効くようになります。

AI時代でも「いきなりパワポを開くな」は変わらない

ここで強く感じたのは、昔から言われてきた仕事の原則は変わらないということです。

プレゼン資料を作るときは、

何を伝えるかを決める。 誰に向けるかを決める。 順番を設計する。 メッセージと事例を対応させる。 最後にスライドに落とす。

これはごく基本的な進め方です。

しかしAIを使うと、この順番を飛ばせるように見えます。

だからこそ設計を省きたくなる。

しかし実際は逆でした。

AIを使うほど、設計が重要になります。

設計が曖昧なまま渡すと、曖昧な成果物が大量に返ってきます。

しかも一見整っているため、問題に気づきにくい。

AIの「それっぽさ」は、設計の甘さを隠してしまうのです。

AIが得意だったこと

もちろん、AIは大いに役立ちました。

特に効果を感じたのは次のような作業です。

事例の探索。 一次情報の確認。 論点の抜け漏れチェック。 表現のバリエーション出し。 図解のたたき台作成。 構成の検査。

こうした工程は大幅に効率化されました。

今回の作業時間は約40時間でしたが、AIなしなら倍以上かかっていたと思います。

ただし効率化できたのは、丸投げしたからではありません。

設計・検査・修正といった工程にAIを組み込んだからです。

一気に作らず、章ごとに作る

もう一つ有効だったのは、一気に100枚作らないことでした。

最初は全体をまとめて生成していましたが、文脈が長すぎて制御が難しくなります。

そこで章ごとに分割しました。

全体アウトラインを固める。 章ごとに作る。 章ごとに完成度を上げる。 最後に全体を調整する。

この進め方に変えてから、安定しました。

大きな仕事は分割する。

単純ですが重要な原則です。

AIを使うと忘れがちですが、むしろより重要になります。

小さな仕事では問題が見えにくい

短い資料では、ここまでの問題は起きにくいと思います。

多少粗くても成立するからです。

しかし規模が大きくなると違います。

ズレが蓄積する。 接続が弱くなる。 メッセージがぼやける。

短いタスクでは見えなかった問題が一気に表面化します。

AIの実力は、小さなタスクだけでは測れません。

大きな仕事でこそ問われます。

そして必要なのは派手なテクニックではなく、

構造化する力。 分割する力。 検査する力。 違和感に気づく力。

といった地味な能力でした。

AIに任せるべき仕事と、人間が持つべき仕事

今回の経験で役割分担も見えてきました。

AIに任せやすいのは、候補出しです。

事例、表現、構成、図解、論点など。

一方で人間が担うべきなのは判断です。

何を伝えるか。 何を捨てるか。 順番をどうするか。 どの表現を採用するか。

ここは丸投げできません。

AIは優秀な作業者ですが、責任者ではありません。

最終的に話すのも、責任を持つのも自分です。

だからこそ、自分の言葉に戻す必要があります。

AI活用とは、仕事の解像度を上げること

AIは仕事を消すというより、仕事の構造を露出させます。

曖昧な部分。 弱いメッセージ。 雑な接続。

それらがはっきり見えるようになります。

AIは、自分の仕事の粗さを映す鏡でもあります。

だからこそ、プロンプト以前に設計が重要になります。

100枚作ってわかったこと

今回の経験をまとめると、

AI時代でも仕事の本質は変わらない。

いきなり作らない。 構造を作る。 分割する。 骨組みを固める。 最後に検査する。

どれも昔から言われてきたことです。

ただ、AIによってその重要性がより明確になりました。

AIは強力ですが、設計が前提です。

設計されていない仕事には、設計されていない成果物が返ってきます。

今回かなり苦労しましたが、それでもAIのおかげで効率化できたのは確かです。

重要なのは、AIに丸投げすることではなく、仕事の各工程に組み込むことでした。

AI時代の仕事術は、意外と古典的だった

AIで多くのものが自動生成できる時代になりました。

だからこそ「どう使うか」に目が行きます。

しかし実際に重要だったのは、その前段でした。

何を作るのか。 なぜ作るのか。 誰に届けるのか。 どう伝えるのか。

ここを決めない限り、良い成果物にはなりません。

AI時代の仕事術は、思ったより古典的でした。

考える。 構造化する。 分割する。 検査する。 最後に形にする。

この順番を守ることが、結局いちばん効きます。

AIを使えば速くなります。

でも順番を間違えると、速く迷子になります。

100枚のスライドを作って、一番強く感じたのはそこでした。

Googleですら、世に出さなければ負けかける

みなさん、AIやってますか。

毎日のように新しいモデルが出て、新しいツールが出て、昨日までの常識がすぐ古くなる。キャッチアップするだけで普通に大変です。ChatGPT、Claude、Gemini、Grok、DeepSeek、Perplexity。人によって使っているAIも違うし、得意な用途も違う。仕事で使っていると、もう単なるツール比較というより、ひとつの産業史を見ている感覚になります。

このAIモデル戦争の歴史は、ちゃんと記録しておいたほうがいいと思っています。

ことの始まりがChatGPTだったのは、たぶん多くの人にとって明らかです。2022年の終わりにChatGPTが出て、生成AIが一気に一般の人の手元へ降りてきた。研究者や機械学習エンジニアだけのものだった大規模言語モデルが、急にブラウザで触れるものになった。

でも、ディープラーニングや機械学習を仕事でやっていた人なら、少し変な感じもあったはずです。

ChatGPTの基礎にあるTransformerを発明したのはGoogleです。しかもGoogleは、ChatGPTのような会話AIに近い技術も持っていました。LaMDAのようなシステムもあった。検索、Gmail、Chrome、Android、YouTubeという配布面もある。研究者も、計算資源も、お金もある。

普通に考えれば、生成AI時代の主役はGoogleだったはずです。

それなのに、先に世の中を取ったのはOpenAIでした。

あのIT業界のボスの一角であるGoogleが、当時はまだGoogleと比べれば得体の知れない新興勢力に見えていたOpenAIに脅かされる。今でこそOpenAIは巨大企業のように見えますが、ChatGPTが出た直後の衝撃はかなり大きかった。まさかGoogleが追いかける側に回るとは、あまり想像していませんでした。

Googleはそこから社内にCode Redを出し、Bardを出し、Geminiでなんとか戦線に戻ってきました。GeminiがClaudeやOpenAIのモデルに比べて圧倒的に優れている、とまでは僕はまだ思っていません。でも、少なくとも同じ土俵では戦えている。検索やGmail、Androidまで含めた配布面を考えると、まだ全然終わっていない。

では、なぜGoogleは一度出遅れたのか。

技術も、人材も、お金も、ユーザー接点もあった会社が、なぜChatGPTに先を越されたのか。ここを学んでおくことは、AI機能を作る側にとってかなり有益だと思います。

そんなことを考えていたら、ちょうどいい記事が出ていました。WIREDが50人以上の現職・元社員に取材した記事です。GoogleがChatGPTに先を越されてから、Bard、Gemini、AI Overviewsへ進んでいく2年間がかなり生々しく書かれています。

Googleは技術で負けたわけではない

WIREDの記事で一番面白いのは、Googleが技術的に何も持っていなかったわけではないところです。

むしろ逆です。Transformerを生み出し、会話AIの研究もしていた。社内には優秀な研究者がいて、既存プロダクトも大量にある。AIを組み込める場所はいくらでもありました。

それでも、GoogleはChatGPTを先に出せなかった。

ここに、かなり重い教訓があります。

技術があることと、世の中に出せることは違う。プロダクトが社内にあることと、市場で使われることも違う。研究として優れていることと、ユーザーの習慣を取ることも違う。

これはAI機能の開発で何度も見る構図です。

社内ではかなり前から作っている。デモもある。精度も悪くない。関係者の反応も悪くない。でも、法務確認、ブランド確認、安全性レビュー、既存プロダクトとの整合、社内説明、リリース判定を順番に通しているうちに、外では競合が似たようなものを出してしまう。

リリースするころには、もう普通の機能になっている。

作った側からすると、かなりつらいです。数カ月前なら新しかった。最初に出していれば、ユーザーの反応を見ながら体験を磨けたかもしれない。でも、市場に出たときには「まあ、ありますよね」という顔をされる。

AIまわりでは、この陳腐化がとにかく速い。

従来のプロダクト開発の速度で進めていると、学習開始が遅れます。市場に出す前に半年使うと、その半年はユーザーから何も学んでいない。競合はその間に失敗し、直し、どこで使われるのかを見ています。

Googleほどの会社でも、ここから逃げられなかった。

反撃もきれいな成功ではなかった

ChatGPTの登場後、GoogleはBardの開発に約100人を集め、100日の期限を置きました。社内テストには約8万人が参加したとWIREDは報じています。

普段なら責任あるイノベーションチームが数カ月かける安全審査も短くなりました。元社員は、公開延期を求める警告が退けられたと証言しています。Google側は、公開を承認または阻止できるチームから中止勧告は出ていないと説明している。ここは見解が食い違っています。

そしてBardは、紹介動画でいきなり誤答しました。ジェイムズ・ウェッブ宇宙望遠鏡が太陽系外惑星を初めて撮影したと答えたのです。実際に最初の画像を撮ったのは、ヨーロッパ南天天文台の超大型望遠鏡でした。

その後も、Googleは止まりませんでした。BardをGeminiへつなぎ、画像生成を加え、検索にはAI Overviewsを入れます。人物画像の生成は、歴史的に不正確な出力が問題となって一時停止されました。AI Overviewsは、ピザのソースに接着剤を加えるといった回答で話題になりました。

外から見ると、かなり危なっかしい。

でも同時に、Googleは戻ってきたとも言えます。Geminiは公開リーダーボードでトップ級のモデルになり、Googleの巨大なプロダクト群にもAI機能が入っていった。ClaudeやOpenAIに圧勝しているとは思いません。でも、少なくとも同じ競技場で戦えるところまでは戻した。

ここが難しいところです。

守ったままだったら、もっと置いていかれたかもしれない。リスクを取って前に進んだからこそ、追いつきつつある。でも、公開前に拾うべき警告を軽く扱うと、利用者と現場が代償を払う。

だから、この話を「速く出せばいい」にしてはいけない。

公開前に決めること、公開後に学ぶこと

AIプロダクトで一番まずいのは、全部の不安を同じ会議に載せることだと思っています。

差別的な出力、健康を損なう誤情報、個人情報の漏えい、権利侵害。ここは利用者に試してもらって学ぶ話ではありません。起きてから「学びがありました」では済まない。公開前に止める条件を決める必要があります。誰が止められるのかも決めたほうがいい。

でも、使われるかどうかは別です。

説明が伝わるか。どの導線で触られるか。期待した行動が増えるか。ユーザーが何に価値を感じるか。これは社内で想像し続けても限界があります。対象を絞って出し、ログと声を見るしかない。

この2つが混ざると遅くなります。

安全性の懸念も、価値が伝わるかどうかの不安も、全部「もう少し検討しましょう」に変わる。会議は増える。資料も増える。関係者も増える。でも、市場からの学びは増えない。

AI機能を作っていて、出すころには競合も同じようなものを出していて、機能として陳腐化している。こういうことを何度も見てきました。もっと早く市場に出して検証していれば、もっと良い体験が作れたのにと思うこともあります。

遅いというのは、開発期間が長いというだけではありません。

学ぶのが遅いということです。

Googleの失敗は、他人事ではない

Googleの2年間を読んで感慨深かったのは、あれほどの天才たちが集まる会社でも、知らないうちに守りに入ることです。

技術がある。人材がいる。お金もある。既存プロダクトもある。だから大丈夫、とはならない。世の中に出して、使われて、そこで学ばなければ、技術はユーザー体験に変わらない。

もちろん、公開前の警告を雑に扱ってはいけない。Googleの例は、そこも同時に教えてくれます。速さを言い訳にして、利用者に危険を押し付けてはいけない。

それでも、完璧にしてから出すという感覚は、AI時代にはかなり危うい。

モデルも、競合も、ユーザーの期待値も、ものすごい速度で変わる。社内で検討しているうちに、市場のほうが先に進む。気づいたときには、よくできた機能が、よくある機能になっている。

次にAI機能を出すかどうかの会議に入るときは、問いを増やす前に分けたい。

これは公開前に決めることなのか。

公開後に学ぶことなのか。

その線を引けないまま「もう少し検討する」を続けることが、一番静かな負け方なのだと思います。

出典はWIREDのSteven Levyによる Inside Google's Two-Year Frenzy to Catch Up With OpenAI です。

データ分析は自動化できる。ただし、DWHとメタデータを舐めてはいけない

汎用データ人材の内藤です。

最近、外ではわりと強めに「データ分析はもう自動化できる」と言っています。

これはポジショントークというより、かなり実感に近い。自然言語で問いを投げると、AIがテーブルを探し、SQLを書き、集計し、グラフを作り、結果の読み方まで返してくれる。ちゃんと環境を整えれば、昔なら人間のアナリストが数時間から数日かけていた仕事が、かなりの割合で自動化できます。

ただ、この話をするときに毎回少し怖さもあります。

「じゃあDWHにつなげば分析できるんですね」と受け取られると、だいぶ違うからです。僕が言っている自動化は、AIにBigQueryやSnowflakeの接続権限を渡して終わり、という話ではありません。むしろ、その前にやる泥臭い仕事のほうが本体です。

DWHの設計を整える。分析に使うmartを作る。テーブルやカラムに説明を入れる。どの指標が正式なのかを書く。更新頻度を書く。使ってはいけない古いテーブルを潰すか、せめて使うなと明記する。事業側が普段見ているダッシュボードと、裏側のデータモデルをつなげておく。

ここまでやると、AIはかなり働きます。逆にここをサボると、AIは賢そうに間違える。

この感覚にかなり近いことを、a16zのYour Data Agents Need Contextという記事が書いていました。データエージェントに必要なのは、単にSQLを書く力ではない。会社の中で数字がどう定義され、どのデータが信頼され、どんな例外があるのか。その文脈が必要だ、という話です。

読んでいて、これはまさにデータ分析自動化の裏側の話だなと思いました。

AIはテーブル名の雰囲気でSQLを書く

たとえば、DWHに orders というテーブルがあるとします。

人間から見ると、いかにも注文データっぽい。AIから見ても、たぶん注文データっぽい。だから「先月の売上を出して」と言われたら、このテーブルを見に行きたくなる。

でも、orders だけでは何もわかりません。

キャンセル済み注文は入っているのか。返品後の金額なのか。税込みなのか、税抜きなのか。クーポン値引き前なのか、値引き後なのか。テスト注文や社内購入は除外されているのか。注文日時は購入ボタンを押した時刻なのか、決済が通った時刻なのか。

このへんを知らないままSQLを書くと、構文は正しくても数字はずれます。

しかも厄介なのは、AIの出力がきれいなことです。SQLは整っている。グラフも出る。コメントもそれっぽい。「先月の売上は前月比12%増でした」と言われると、なんとなく信じたくなる。

でも、その12%増がクーポン値引き前の金額なのか、返品を除いた後の金額なのか、テスト注文を含んだ数字なのかで、意味はまったく変わります。

データ分析の自動化で怖いのは、AIが間違えることそのものではありません。間違った数字が、正しそうな顔で出てくることです。

「売上を見たい」だけでは足りない

a16zの記事では、「前四半期の売上成長率は？」という問いに近い例が出てきます。一見かんたんな質問です。売上を四半期で集計して、前四半期と比べればいい。

でも実務では、ここでいきなり詰まります。

売上とは何か。受注額なのか、会計上の売上なのか、継続課金を月次換算した数字なのか。四半期とは暦年の四半期なのか、会計年度の四半期なのか。どのテーブルを見ればいいのか。財務チームが見ている数字と、事業チームが毎週見ているダッシュボードの数字は同じなのか。

ECなら、売上はクーポン値引き前後で変わります。メディアなら、PVを見るのか、セッションを見るのか、記事単位で見るのか、カテゴリ単位で見るのかで答えが変わる。SaaSなら、無料トライアルを含めるか、有料化した顧客だけを見るかで継続率が変わります。

解約率も同じです。

顧客数ベースで見るのか、金額ベースで見るのか。無料ユーザーを母数に入れるのか、有料顧客だけに絞るのか。月初時点の顧客を母数にするのか、期間中に契約した顧客まで入れるのか。

どれもSQLの問題に見えて、実際には言葉の問題です。「売上」「顧客」「解約」「アクティブ」という言葉が、会社の中で何を指しているのか。ここが決まっていないと、AIは何かしら答えます。何かしら答えるからこそ危ない。

人間のアナリストなら、このあたりを半ば無意識に確認しています。

「この売上は経理定義ですか、事業KPIのほうですか」

「このカテゴリ、去年の途中で再編してませんでしたっけ」

「そのダッシュボード、今も定例会議で使っていますか」

「そのテーブルは昔のやつなので、今はこっちを見たほうがいいです」

こういう会話を、AIは自力ではできません。少なくとも、何も渡さなければできない。

自動化の主戦場はチャットUIではない

データ分析AIというと、どうしてもチャットUIに目が行きます。

自然言語で質問する。AIが答える。グラフが出る。見た目としてはわかりやすいし、デモ映えもする。

でも、僕は本当の主戦場はその手前にあると思っています。

どのテーブルを正とするか。どのカラムを何の用途で使うか。どの指標が経営会議用で、どの指標が現場運用用なのか。速報値と確定値をどう扱うか。カテゴリや組織の定義変更をどう残すか。

ここが整っていないと、どれだけUIが気持ちよくても、出てくる数字は信用できません。

たとえば、古い sales_master というテーブルが残っているとします。名前だけ見るとめちゃくちゃ正しそうです。でも実際には、今の正式な売上集計は mart_revenue_by_contract に移っている。人間なら「あ、それ昔のテーブルです」と止められる。でもAIは、名前のわかりやすさに引っ張られるかもしれない。

だからメタデータが必要になります。

• このテーブルは日次更新で、当日分は未確定
• このカラムは税込金額で、利益率計算には使わない
• この指標は経営会議では使うが、広告運用の判断には使わない
• このカテゴリは2025年4月に再編しているので、時系列比較では補正が必要
• このダッシュボードは過去の検証用で、現在の定例会議では参照しない

こういう情報が入っていると、AIの振る舞いが変わります。単にSQLを生成するのではなく、避けるべきデータを避ける。注意書きを付ける。質問が曖昧なら確認する。少なくとも、その方向に近づきます。

ここまでやって初めて、データ分析の自動化が現実味を帯びる。

セマンティックレイヤーより広いもの

この話をすると、セマンティックレイヤーの話に聞こえるかもしれません。

売上、解約率、ARPUのような指標を定義して、BIツールや分析環境から同じ意味で使えるようにする。これはもちろん大事です。指標定義がバラバラだと、同じ会議にいる人が別々の数字を見ながら話すことになる。

ただ、a16zの記事が言う context layer は、もう少し広い概念です。

指標定義だけではありません。顧客や契約の対応づけ、古いデータソースを避けるルール、アクセス権限、業務上の例外、過去の意思決定の経緯まで含む。

顧客IDひとつ取っても、現実はぐちゃぐちゃです。WebのユーザーID、CRMの会社ID、請求システムの契約ID、サポートツールの問い合わせIDが別々に存在する。法人が社名変更する。グループ会社で契約が分かれる。ひとつの企業が複数プロダクトを使う。

どれを一人の顧客として数えるのかを決めないと、LTVも継続率も問い合わせ件数もずれます。

これは単なる指標定義ではありません。会社の中で、その対象をどう見ているかという文脈です。

セマンティックレイヤーが指標の辞書だとしたら、context layer は業務の引き継ぎノートに近い。コードで書ける定義もあれば、自然言語でしか残せない注意書きもある。過去のクエリ、BIダッシュボード、Slack、Google Driveの中に散らばっている知識もある。

人間のデータアナリストは、それらを少しずつ覚えながら仕事をしています。AIに同じことをさせるなら、その文脈を読める場所に置かないといけない。

泥臭い会社ほど、自動化に近づく

ここが少し逆説的で面白いところです。

データ分析を自動化しようとすると、最後は泥臭いデータ整備に戻ってくる。

過去のクエリ履歴を見て、よく使われるテーブルやjoinを洗い出す。dbtやLookMLから指標定義を拾う。BIダッシュボードを見て、実際に事業で使われている数字を確認する。Slackやドキュメントに散らばっている「この数字を見るときは注意」という一言を回収する。

広告媒体の命名規則が途中で変わった。商品カテゴリを統合した。店舗マスタの管理システムを入れ替えた。会員IDの採番ルールがリニューアルで変わった。こういう変更を知らずに前年同月比を出すと、伸びたように見える数字が、単なる定義変更だったりする。

こういう話は、華やかなAIデモには出てきません。

でも、実務ではここが効きます。

AIがすごいから分析が自動化されるのではなく、AIが迷わないように会社の数字を整えているから自動化される。僕が「データ分析は自動化できる」と言うとき、裏側で想定しているのはこれです。

自動化の本体は、チャット画面ではない。DWH設計とメタデータです。

データ職は、分析する人から文脈を設計する人へ

データ職の仕事は、なくなるというより重心が移ります。

SQLを書く作業の一部はAIに寄っていく。集計や可視化の初手も、かなり自動化できる。そこはもう認めたほうがいいと思っています。

でも、どの数字を信じるのかを決める仕事は残る。むしろ重くなる。

このKPIはどの定義で見るべきか。このテーブルはいつから正になったのか。このダッシュボードは今も意思決定に使っていいのか。例外条件はどこに書かれているのか。

そこを曖昧にしたままAIだけ導入しても、出てくるのは賢そうな間違いです。SQLも動いている。グラフも出ている。コメントも自然。でも、現場の意思決定には使えない。

データエージェント時代のデータ職は、単にクエリを書く人ではなく、会社の数字の意味を整える人に近づいていくのだと思います。メトリクスを定義する。source of truthを決める。使ってはいけないテーブルを明示する。暗黙知を言葉にして、更新される場所に置く。

地味です。終わりもない。誰かが拍手してくれる仕事でもない。

でも、データの世界では、そういう地味な仕事が最後に効いてきます。

データ分析は自動化できます。ただし、魔法ではありません。

DWHを整え、メタデータを埋め、会社の数字の文脈をAIが読める場所に置く。そこまでやって初めて、AIはデータ分析者として働き始める。

データエージェントに必要なのは、より派手なデモではなく、会社の数字が迷子にならないための地図です。今日もどこかのDWHの片隅で、誰かがカラム説明を書いている。たぶん、その人が未来のAIを一番賢くしている。

それではまた、インターネットのどこかで。

通信ケーブルの先にあったものは、データじゃなかった

通信ケーブルの先にあったものは、データじゃなかった

とみさわ昭仁『ゲームフリーク 遊びの世界標準を塗り替えるクリエイティブ集団』（太田出版）を読んだ。ポケモンを作ったゲームフリークの成り立ちを追ったノンフィクションで、付箋だらけになったので自分なりにまとめておく。

通信ケーブルで友達のゲームボーイとつないで、持っていないポケモンを交換する。図鑑が1マス埋まる。あの興奮を、30年近く経ったいまでも身体が覚えている。でもあのゲームがどうやって生まれたのか、大人になるまで考えたこともなかった。

本書を読むと、ポケモンは「データを交換するゲーム」として作られたわけではなかったことがわかる。友達の前でケーブルをつなぎ、手元のポケモンを相手のゲームボーイへ移す。あの体験そのものが、最初から設計の中心にあった。

石の下をのぞく子どもが、ゲームを作った

ポケモンの生みの親、田尻智さんは、小学生の頃にクワガタを捕まえるのがうまかったらしい。図鑑で生態を調べ、石の下に潜む習性を見つけ、他の子より多く捕まえる。冬眠のさせ方も、水道下の温度が安定していることを使って自分で編み出している。

中学に入るとゲームセンターに通い始める。ここでも同じだった。スペースインベーダーのインベーダーの数と移動速度の関係、パックマンのモンスターごとの動きの違い、ゼビウスの敵出現法則。ゲームを遊んで終わらせず、分解していた。

虫もゲームも、観察して法則を見つけて攻略するという構造は同じだ。対象が変わっても、やっていることの根っこは変わらない。

好きなものを外に出すと、人が集まる

田尻さんは18歳で同人誌「ゲームフリーク」を創刊する。4年間で30冊。方眼紙に手書きで清書し、母と妹が製本した。新宿の同人誌専門店に持ち込むと数日で完売し、読者から数百通の手紙が届いた。「ゼビウス 1000万点への解法」はミニコミ界のベストセラーになり、YMOの細野晴臣が読者になり、中沢新一が「現代思想」誌上で分析するところまで行く。

石原恒和さんの証言がいい。当時のゲームオタクたちからは、キャラクターを退治してやるという意識ばかりが感じられた。でも田尻さんだけは、ゲームの魅力を面白く人に伝えようとしていた。外の人に向けて書いていた。

好きなものを内輪で抱え込まない。調べたこと、考えたこと、発見したことを外に出す。手書きの同人誌が杉森建さんとの出会いを生み、ゲームフリークという会社になっていく。熱量は、外に出した瞬間に人を連れてくる。

ポケモンは「交換したい」から始まった

ポケモンの出発点は、RPGでもモンスターバトルでもなかった。田尻さんがゲームボーイの通信ケーブルを見て「これで何かを交換できたら面白い」と思ったのが始まりだ。

小学生の頃、ドラクエIIで友達が持っていた「ふしぎなぼうし」がどうしても欲しかった。あの悔しさが残っていた。ジャンルやシステムは後からついてきた。最初にあったのは、目の前の友達と何かをやりとりしたいという衝動だった。

「どうしてもこれが欲しい」から始まるものづくりは強い。2バージョン同時発売、三者択一のスターター、里親システム。交換したくなる仕掛けがゲーム全体に張り巡らされているのは、最初の悔しさが消えなかったからだと思う。

機能から考えると、通信ケーブルは周辺機器になる。体験から考えると、通信ケーブルはゲームの真ん中に来る。ポケモンは、そこで間違えなかった。

面白いゲームは、動詞でできている

本書で一番うなったのは、田尻さんのゲームデザイン方法論だった。パックマンなら「たべる」、ディグダグなら「ほる」、マリオなら「ふみつける」。面白いゲームはいつも新しい動詞を持っている。新しいゲームを作るとは、新しい動詞を探すことだ、と。

ゲームフリーク初の商業作品「クインティ」は、方眼紙の前でぶつぶつ動詞をつぶやき続けて見つけた「めくる」から生まれた。床パネルをめくって敵を飛ばす。クインティでは画面から文字情報を徹底的に排除している。言葉で説明せず、遊びそのものでわからせる。

ゲームに限らず、動詞で考えると設計が締まる。ユーザーに何をさせたいのか。読む、選ぶ、比べる、残す、渡す。動詞が曖昧なものは、画面も機能もだいたいぼやける。

1メガビットの中で、世界を広く見せる

ポケモンが使えた容量はたった1メガビット。いまのスマホ写真1〜2枚分だ。普通なら町の数を減らすところを、ゲームフリークは「道路だけデータにすればいい」と考えた。こうして生まれた「国道システム」は、苦肉の策だったはずなのに、「1番道路」「16番道路」という世界の手触りを強くした。

ポケモンの数を減らしてでもニックネーム機能を残した判断も印象に残った。名前のないポケモンの交換は、商品の売買に近い。名前がつくと、贈り物になる。容量が足りない段階で、その違いを見ていた。

本書に、器を大きくして解決するのは安易だし、材料をただ減らすのも安易だという話が出てくる。決められた器に収めるために材料を減らしながら、そこに新しい意味を与える。ハンデを逆手にとって、新しいアイデアにする。

増田順一さんは、技術力は作りたいゲームを実現させるために必要最低限のレベルであればいい、と語っている。ゲームフリークは10年間、ゲームボーイの8ビットで作り続けた。10年目にポケモンが生まれた。足りないものを嘆く前に、この制約でしかできないことを探す。言うのは簡単だけど、ポケモンはそれを本当にやった。

泣いた後に、机へ戻れるか

開発途中で、プロデューサーの石原さんから「きみが何を言いたいのか、全然わからない」と突きつけられ、田尻さんは泣き崩れた。そこから三晩徹夜でシナリオを書き直し、半年かけてゲーム内のNPCの台詞を一文一文直した。発売は3ヶ月延びた。

「あそこで泣けなかったら、ポケモンは完成しなかった」

この一言は重い。

「これじゃダメだ」と言われたあとに、机へ戻れるか。田尻さんは戻った。生活のすべてがポケモンになるところまで行って、もう一度書いた。田尻さんの話を読んでいると、フィードバックは最後に作品の輪郭を削り出す刃にもなるのだと思う。

通信対戦がゲーム完成の14日前に追加された話もすごい。テストプレイで「対戦できたらもっと楽しいのに」という声が続出して、田尻さんが急遽採用を決めた。担当の森本さんは「間に合わなかった、とならないかと期待してた」と言っている。最初のバージョンは任天堂に「つまらない」と返され、そこから突貫工事であのポケモンリーグを作り上げた。

チームで作る。でも最後は誰かが決める

企画から完成まで6年以上。最初の見積もりは半年だった。プログラマーが一斉に抜けて人数は半減し、作曲担当の増田さんが「僕がプログラマーをやります」と申し出てプログラマーに転身した。ワークステーションのクラッシュでは独学でUNIXを勉強して機器を復旧させ、最終的には戦闘システムのメインプログラムまで組み上げた。

増田さんの作曲法も好きだ。通勤電車でメロディを思いついても、あえてメモしない。家に帰るまで覚えていたメロディだけが印象に残る曲だ、という選別方法。

ゲームフリークは銀行から一度も借金しなかった。雑誌の執筆や別の仕事で赤字を補てんしながら6年を耐え抜いた。太田さん、森本さん、渡辺さんが連日の徹夜でスケジュールを取り戻し、杉森さん、藤原さん、西田さんがポケモンに命を吹き込み、西野さんが煩雑な作業を一人で引き受けた。田尻さんがシナリオの書き直しに踏み切れたのは、6年間を一緒に走ってくれた仲間に合わせる顔がなかったからだと書かれている。

宮本茂さんが「ジャンプボタンをユーザーが変えられるようにしては？」と提案したとき、田尻さんは「それは絶対ダメです！」と即答した。宮本さんは「意志を通せる独裁者タイプこそ、強いコンテンツを生む」と語っている。

チームで作るものだけど、最後の判断を曲げない人が一人いないと、合議で角が取れて何でもない丸いものになってしまう。全員の意見を聞くことと、全員が少しずつ納得するものを作ることは違う。

データと呼ばないでほしい

ポケモンの制作スタッフは交換のことを「データのやりとり」と呼ばないでほしいと口を揃えるそうだ。

田尻さんは、ゲームの中のポケモンはただの数字の集合体でしかないと語っている。でも、それが生き物であるかのように、自分のゲームボーイから人のゲームボーイに「移住」する感覚を大事にしたかった。モンスターボールに入れてケーブルを通過させるアニメーション、鳴き声のエコー処理。プログラムの送受信を、生命の移住として感じさせるための演出だった。

ポケモンは、学校帰りに子どもたちが通信ケーブルで交換し合う姿を想定して作られた。ゲーム内のシステムに収まらず、放課後の公園で友達と向かい合ってゲームボーイをつなぐ風景ごとデザインしている。

データを扱う仕事に引き寄せると、ここが重要になる。初代ポケモンの通信交換は、数字の塊に名前をつけ、鳴き声をつけ、移動のアニメーションをつけた。ケーブルの向こうへ行くまでの時間も含めて、交換の体験にしていた。

同じデータでも、触り方ひとつで「情報」にも「体験」にもなる。数字の集合体に意味を吹き込むという点で、ゲームとデータプロダクトはけっこう近い場所にある。

愛しているから、雑に売らない

本書を通して一番印象に残ったのは、田尻さんと杉森さんの距離感だった。二人はゲームを愛しつつ、ゲームを笑い飛ばすことができた。テレビゲームを「あらゆるオモチャのなかで最もおもしろいもの」だと思いつつ、「でもオモチャのひとつでしかない」という感覚を手放さなかった。当時、日本各地にゲーム好きの少年サークルが生まれていたけれど、愛情がいびつになって自己満足に陥るケースが多かったそうだ。田尻さんと杉森さんは、そこに溺れなかった。

ポケモンが世界的ヒットになった後も同じだ。石原さんはこう語っている。ピカチュウを無地のコーヒーカップに印刷すると500円高く売れる。でも、その500円分だけピカチュウの価値がすり減る。既成の商品にキャラクターを印刷しただけのものには許可を出さない、と。

自分が作ったものを愛しているから、雑に使わない。売れるからといって、どこにでも貼らない。熱狂の中心にいながら、少し離れた場所から見ている。

初代ポケモンのすごさは、151匹のキャラクターだけでは語りきれない。交換したくなる仕組み、名前をつけられる仕様、ケーブルを通って移動する演出、学校帰りに子どもたちが向かい合う場面。ゲームの外側にある行動まで設計に入っていた。

子どもの頃、僕はこんな裏側を何も知らないまま遊んでいた。あの通信ケーブルの先にあったのは、たしかにデータ通信だった。でもゲームフリークが作ろうとしていたのは、データの送受信そのものではなかった。

データを扱う仕事に引き寄せるなら、ここに学びがある。正しいだけのデータは、そのままでは体験にならない。誰が、どんな場面で、何として受け取るのか。ポケモンは、ゲームボーイの小さな画面でそこまで設計していた。

通信ケーブルの先にあったものは、データ通信を体験に変えるための設計だった。

数値・日付・エピソード・発言はすべて同書（第１部・第２部・復刊付録）に基づく。

組織図は、情報を運ぶための道具だった

会社に入ると、たいてい組織図がある。

部署があり、部長がいて、課長がいて、メンバーがいる。あの箱と線の絵を見ても、普段はあまり驚かない。会社とはそういうものだと思っているからだ。

でも、組織図は自然物ではない。中間管理職も、会社に最初から付いていた部品ではない。

Blockのジャック・ドーシーとSequoiaのRoelof Bothaが公開したFrom Hierarchy to Intelligenceを読んだ。記事にはローマ軍、プロイセン軍、鉄道会社、マトリクス組織、AIといろいろ出てくる。細かい話を全部追うと少し重い。

僕の整理では、話の芯はもっと単純だった。

人が増えると、情報がそのまま届かなくなる。だから階層が生まれた。AIが入ると、その前提が変わるかもしれない。

階層は、情報を小分けにするしくみだった

Blockの記事はローマ軍の話から始まる。ここは、歴史の細部より構造だけ拾えば十分だと思う。

数千人を広い場所で動かしたい。でも無線もチャットもない。命令は下へ流さないといけないし、現場の状況は上へ戻さないといけない。全員が全員と話していたら、何も決まらない。

そこで小さな単位を作る。数人をひとまとまりにして、そのまとまりを一段上で束ねる。大きな軍を、人間が見られるサイズに切り分ける。

会社の組織図も、かなり似ている。部長や課長という肩書きだけを見ると、権力の地図に見える。でも別の見方をすると、情報を運ぶための道具でもある。

現場で何が起きているかを上に運ぶ。会社の方針を下に運ぶ。横の部署との調整をはさむ。人数が増えるほど、情報をそのまま全員に流すのは難しくなる。階層は、その無理を少し楽にするための形だった。

中間管理職は、情報を運ぶ係だった

中間管理職も、同じ文脈で見るとわかりやすい。

Blockの記事では、現代的な中間管理職の原型として軍の参謀本部が出てくる。ここも細かい名前は置いておく。大事なのは、戦う人とは別に、状況を読み、計画し、部隊を調整する人たちが置かれたことだ。

その発想が、鉄道会社に入っていく。鉄道は、とにかく調整が大事な事業だ。列車がどこを走っているか。誰が保守しているか。どの駅で何が起きているか。非公式なやり取りだけでは危ない。

だから組織図が必要になった。誰が誰に報告するのか。どこで判断するのか。どの情報をどこに集めるのか。そういう流れを見える形にした。

組織図や中間管理職は、偉い人を作るためだけに生まれたわけではない。人間が一度に見られる範囲が狭いから、情報をいったん集め、要約し、流す人が必要だった。

かなり雑に言えば、中間管理職は会社の中の中継地点だった。

フラットにしても、情報の問題は残る

中間管理職を減らしたい、階層を薄くしたいという話は昔からある。Spotifyのスクワッド、Zapposのホラクラシー、Valveのフラット組織。Blockの記事にも、そうした例が出てくる。

ここも、事例をひとつずつ覚える必要はない。共通しているのは、階層を減らしても調整そのものは消えないということだ。

肩書きを消しても、誰かが状況を見ないといけない。優先順位を決めないといけない。チームの外で起きていることを拾わないといけない。

階層を減らせば速くなる面はある。ただ、一人が見る範囲は広くなる。見る範囲を狭くすれば、今度は層が増える。どちらに倒しても、情報をどう扱うかという問題は残る。

ここがおもしろかった。組織を、権威的か自由かという話だけで見ない。誰が何を知っているのか。どこで情報が止まるのか。どこで要約され、どこで抜け落ちるのか。組織図を、情報の流れとして読む。

AIが変えようとしているところ

BlockのAI論は、社員全員にチャットボットを配る話ではない。

狙っているのは、会社の状態をAIがかなり細かく見られるようにすることだと思う。何が進んでいるか。どこで詰まっているか。どの顧客に何が起きているか。誰が何を判断したか。

今はその多くを、人が会議やSlackや1on1から拾っている。マネージャーが進捗を聞き、要約し、上に伝え、別のチームに渡す。会社が大きくなるほど、この中継仕事が増える。

AIがこの中継の一部を引き受けられるなら、組織図の意味が変わる。

Blockは、会社の中の情報だけでなく、顧客の動きも見ようとしている。Cash AppやSquareには、お金の流れがある。買う、売る、借りる、返す。アンケートよりも行動に近いデータだ。

そのデータをもとに、顧客が何に困りそうかを先に読む。必要な金融サービスを組み合わせて出す。そういう会社像を描いている。

難しい言葉で言えばワールドモデルだが、ここでは会社と顧客の状態を表す地図くらいに読めばいいと思う。

会社を、箱ではなく層で見る

Blockは、将来の会社を4つの層で説明している。ここも横文字が多いので、かなり噛み砕いて読む。

まず、決済や融資のような部品がある。次に、会社や顧客の状態をまとめた地図がある。その地図を見て、AIが部品を組み合わせる。最後に、アプリやサービスの画面を通じて顧客に届ける。

たとえば、あるお店の資金繰りが来月苦しくなりそうだとする。今までなら、誰かがデータを見て、会議をして、商品企画を考え、ローンの提案を作る。

Blockが描く世界では、AIが似たパターンを見つける。必要な金融の部品を組み合わせる。お店の人が困る前に、短期の資金案を出す。

もちろん現実には、法務や審査や責任の問題がある。ここで言いたいのは、商品を人が一つずつ企画するのではなく、AIが状況に合わせて組み立てる方向へ寄せたいのだ、ということだ。

会社の見方も変わる。部署の箱を並べるより、部品、状態の地図、判断するAI、顧客に触れる画面という層で見る。組織図よりも、システム図に近い。

人はどこに残るのか

Blockは、中間管理職の層はかなり薄くなると書いている。ここは強い主張だ。

ただ、人間がいなくなる話ではない。むしろ、人間が残る場所をはっきりさせようとしている。

残るのは、ものを作る人。特定の問題を一定期間引き受ける人。自分でも手を動かしながら周りを育てる人。

薄くなるのは、主な仕事がステータスを上や下へ運ぶ人だ。

ここは少し慎重に読みたい。進捗を伝えるだけの仕事は減るかもしれない。でも、マネージャーがやっている仕事はそれだけではない。

曖昧な衝突を受け止める。まだ言葉になっていない不安を拾う。人が育つ余白を作る。誰かが責任を持たないといけない判断を引き受ける。

こういう仕事は、単なる情報伝達ではない。AIに渡せる部分と、渡しにくい部分が混ざっている。

まだ保留したいところ

Blockの話をそのまま信じる必要はないと思う。AIが会社の状態を見られるようになっても、責任や信頼まできれいに移るわけではない。

ただ、組織図の見方は変わった。

部長がいる。課長がいる。部署が分かれている。それを権限の話としてだけ見ていた。でも、それは情報を運ぶための形でもあった。

だとすると、AIで問われるのは「管理職を何人減らせるか」だけではない。

会社は何を見ているのか。何を学習しているのか。どの情報が、誰のところで止まっているのか。

組織図は、完成された建物というより、情報を運ぶために組まれた足場に見えてきた。AIがその足場を全部壊すのか、一部だけ組み替えるのかはまだわからない。ただ、箱と線を見たときに、その裏を流れている情報のことは前より気になる。

加速する加速（4）いつ止まるか 5つの減速シナリオと将来予測

前回と前々回の記事で、METRの時間地平線データが7年で18,000倍の指数成長を示していること、その背後にAIがAI開発に使われる再帰的改善ループと企業間競争の加速があることを見てきました。

ここからは反対側、加速が鈍化する経路を考えます。

加速が止まるシナリオ

計算資源の壁

Epoch AIの分析では、rの値は計算資源の制約を入れると1を下回る可能性があります。ソフトウェア改善だけでは限界があり、ハードウェアの並行的な進歩が不可欠だという構図です。製造業における労働と資本の代替弾力性は0.7と推定されており、両者は補完関係にある。AIソフトウェアが無限に改善しても、計算ハードウェアが追いつかなければボトルネックになります。

生産性パラドックス

METRの2025年7月の調査は、経験豊富なオープンソース開発者がAIツールを使った場合、タスク完了が19%遅くなったという結果を示しました。開発者自身は24%速くなったと予想し、事後も20%速くなったと信じていた。

ベンチマーク上の性能向上と現実の生産性向上が一致しない可能性を示しています。AIが単独で完遂できるタスクの長さは伸びていても、人間との協働では別のオーバーヘッドが生じます。

より広い視点では、全米経済研究所NBERの2026年2月の調査で、企業の90%がAIの導入による生産性向上を実感していないと報告されています。ベンチマーク上の改善が実経済に浸透するまでにはラグがあります。

外的妥当性の問題

METRのベンチマークはゴールが明確でスコアリング基準が既知、デジタル環境で完結し再現可能なタスクで構成されています。現実の知識労働でこの4条件を全て満たすものは少数派です。営業・採用・経営企画・対人コミュニケーションなど構造化されていない業務への一般化は慎重に行う必要があります。

データ枯渇と収穫逓減

フランソワ・ショレが2017年に指摘したように、科学のどの分野でも、創設者が最も簡単な発見をさらい、後続の研究者は指数的に多くの努力で同等のインパクトを得なければならない。このfishing out効果がAI研究にも適用されるなら、現在の加速は初期の容易な改善を刈り取っているだけかもしれません。

合成データの限界も懸念材料です。人間が生成した高品質な訓練データには物理的な上限があり、モデル自身の出力を訓練データに使う循環は品質低下のリスクを伴います。

AIバブル崩壊リスク

2025年のAI投資のVC比率52.7%、1.3兆ドルの合計時価総額、年間6,000億ドル超のインフラ投資。これらの数字が持続不可能である可能性は無視できません。投資が急減すれば、計算資源の拡大も鈍化し、フィードバックループの前提が崩れます。

将来予測

長期トレンドと加速トレンドの2シナリオに、再帰的改善を織り込んだ第3のシナリオを加えました。

シナリオ	前提	倍増ペース	1年AI到達	確率の定性的評価
A：長期トレンド維持	2019年以降の成長率が継続	188日	2029〜2030年頃	過去実績ベースで最も堅実
B：加速トレンド維持	2023年以降の加速が継続	129日	2028年頃	直近トレンドの直線外挿
C：再帰的加速	倍増ペース自体が短縮し続ける	漸減	2027年頃	フィードバックループの効果が加速する場合

シナリオCの考え方

シナリオCは、倍増ペースが一定ではなく、時間とともに短くなるモデルです。フィードバックループが強まるにつれ、188日から129日、そしてさらに短く、という経路をたどります。

数学的には、能力yの時間微分がy自身に比例する場合、つまりdy/dt ∝ y^αでα > 1のとき、有限時間で発散する超指数的成長が起きえます。Forethought Foundationの推定r ≈ 1.4はこの領域に入る。

ただし成立条件は厳しい。計算資源のスケーリングが続くこと、データ枯渇が起きないこと、安全性評価やデプロイメントが律速にならないこと。どれか一つが崩れればループは鈍ります。

現実的には、シナリオCが持続する期間は限られていて、どこかの制約に当たってBかAに移行します。減速するまでにどこまで到達するかが問題です。

1ヶ月の壁はもう超えた

Opus 4.6の時間地平線は719時間、約30日分。METRが特別な閾値として掲げてきた1ヶ月相当のタスク完遂能力を超えました。新入社員が独力で経済的価値を生み出し始めるタイミングと一致する水準です。

次の節目は1年、8,760時間。プロジェクトの立ち上げからリリース、運用改善まで一貫して担当できる能力に相当します。

何を定点観測すべきか

リソース	見るべきポイント
METR Time Horizons	最新モデルがトレンドラインの上か下か。倍増ペースの変化。
Epoch AI Trends	訓練計算量・アルゴリズム効率・コストの推移
AI Digest Time Horizons	最新モデルへの迅速なMETR適用
SWE-bench Leaderboard	Verified版スコアの推移
各社の決算発表・技術ブログ	AIコード生成比率、R&D投資額の開示

フィードバックループが実際に回っているかどうかを確認するには、METRの時間地平線だけでなく、その背後にある投資・リリース頻度・AIコード比率を並行して追う必要があります。どれか一つが鈍化したら、ループが弱まっている兆候かもしれません。