今日もデータで飯を食う。

今日もデータで飯を食う。

汎用人型決戦データ人材のメモ

世界最高峰の数学者は、AIをどう使うのか

数学者とAIが対話しながら一つの課題を検証するサムネイル

インターネットのみなさんこんにちは。汎用データ人材のnjunと申します。

今日は、テレンス・タオがAIをどう使っていたのか、という話です。

つい最近、AIを使ってヤコビアン予想の三次元反例が見つかったというニュースが話題になりました。ヤコビアン予想は1939年に提案され、二次元では今も未解決です。数学者のLevent Alpögeが発表した三次元の反例で、発見までの作業にはClaudeのFable5が使われたそうです。

ヤコビアン予想をかなりざっくり言うと、多項式のルールで座標を別の座標へ変換したとき、どの場所の近くでも元へ戻せるなら、全体でも元へ戻せるはずだ、という予想です。説明してみたものの、なんだかよくわかりませんね。ただ心配しないでください。数学の詳しい話には、ここでは踏み込みません。

この反例については、テレンス・タオが詳しい解説を書いています。タオは、数学界で最高峰とされる賞の一つ、フィールズ賞31歳で受賞した数学者です。

さてさて、面白いのはここからです。

タオは、反例の仕組みを理解するためにAIを使い、二日間の会話を公開しました。共有ページに含まれる会話を数えると、タオ側の発言は53件あります。順に読むと、最先端の問題にAIをどう使い、どこを自分で判断していたのかが見えてきます。

僕にとって参考になった使い方を、10個にまとめておきます。

以前の記事では、AIへ最初に何を問うかを書きました。今回見たいのは、その先です。返答を受け取ったあと、どこを疑い、どの方向へ進み、いつ戻って確かめるのか。タオのログには、その判断が残っています。

問いを絞る

1.解いてもらう前に、どこが分からないか決める

最初の問いから、タオは問題全体を解かせようとしていません。複雑な式の中で大量の打ち消し合いが起きているのはなぜか。そこに対称性や、もっと見通しのよい構造がないかと聞いています。

完成した答えを頼むのではなく、自分がまだ説明できない場所を選んで渡す。AIに何をしてほしいかより、自分はどこで分からなくなったのかを先に言葉にします。

2.一往復で確かめることは一つにする

タオの入力は短いものが多く、一回の発言で扱う疑問を絞っています。ある構造が分かったら、次はなぜ別の性質が成り立つのかを聞く。返答を読んでから、次に調べる場所を変えています。

一つ目が「どこから始めるか」の選択なら、こちらは会話を進める単位の話です。短いプロンプトをまねるのではなく、一つ聞いて返答を読み、次の疑問を決めます。

3.返答を自分の言葉で言い直す

タオはAIの説明を受けたあと、自分が理解した内容を何度も書き直しています。ここまでは分かった。でも、なぜ次の部分が成り立つのかは分からない。そんな形で、理解できた場所と次の疑問を分けています。

AIの文章を読んでいる間は、分かった気になれます。自分の言葉へ戻すと、まだ借り物のまま残っている部分が見えてくる。次の質問はそこから作れます。

4.自分の仮説を先に出す

タオはAIに「次は何をすればよいか」と聞き続けてはいません。自分で見つけた関係や、こういう形なら説明できるのではないかという仮説を先に出し、AIに続きを考えさせています。

仮説が合っている保証はありません。実際、タオ本人も、会話中には自分とAIの双方が行き止まりになる案をいくつも出したとブログのコメントで説明しています。それでも、自分の見立てを出せば、AIの返答を賛成意見として受け取らず、どこが違うかを調べる材料にできます。

探索を進める

5.別の資料や説明と比べる

会話の途中で、タオは別のアプローチを説明したPDFを渡しています。最初に見ていた構成と何が同じで、何が違うのか。新しい説明を使うと、元の構成が理解しやすくなるかを比べさせました。

一つの説明を深掘りし続けるより、別の資料を同じ会話に置くほうが分かることがあります。比べる対象があれば、AIが最初の説明に合わせて話を続けているだけなのかも見やすくなります。

6.全体像と手元の計算を行き来する

タオは、式を使わない幾何的な説明を探したあと、自分から「そろそろ座標で考えたほうがよさそうだ」と切り替えています。その後も全体の構造へ戻り、最後はまた個別の計算に降りています。

全体像だけでは確信できず、計算だけでは何をしているのか分からなくなる。AIの説明が抽象的になったら、数字や例に落として確かめる。細部に埋もれたら、そもそも何を知りたかったのかへ戻ります。

7.条件を変えて、どこまで通じるか試す

三次元の問題を見ていたタオは、同じ構造を四次元や五次元へ広げられないか試しています。一般化そのものが目的というより、何がこの構成を成り立たせているのかを調べているように読めます。

条件を変えても説明できるなら、考え方の中心が見えてきます。どこで崩れるかを見れば、その説明が成り立つ範囲も分かります。

8.話が続いても、必要がなければ戻る

四次元、五次元へ進めたあと、タオは思ったより複雑になったと判断します。そして会話の中ではっきり三次元の問題へ戻っています。

七つ目が考え方の通用範囲を調べる動きなら、こちらは探索を止める判断です。AIは話を続けられます。けれど、その方向に調べる価値があるとは限りません。前より分かりにくくなったら、最後に理解できた場所へ戻ります。

確かめて採用する

9.採用前の確認は小さく分ける

終盤になると、タオの問いはかなり細かくなります。変数の変換が合っているか、逆向きの変換も書けるかと、判定できる大きさまで分けて順番に確認させています。

「全体として正しいか」と聞いて終えると、間違った場所が分かりません。結論を支える前提や途中の計算を一つずつ確かめる。二つ目が探索中の一往復を小さくする話なのに対し、ここでは最後に採用できるかを見ています。

10.AIとは別の根拠で確認する

最後の一つは、公開ログだけから取り出した話ではありません。タオ本人が確認したAI利用方針では、自分で筋道立てて説明できず、AIなしで質問に答えられない出力は仕事へ入れないという基準が示されています。AIの出力は、従来の信頼できる方法でも確かめる必要があるとしています。

公開ログの終盤では、ChatGPTに記号計算を確認させています。ただ、同じAIへもう一度聞くだけでは独立した検証になりません。一次資料や別の計算へ戻る。最後に採用を決めるところは、人間の仕事として残ります。

天才から学ぶこと

タオの使い方は、数学の研究に限ったテクニックではないと思います。答えが決まっていない課題をAIと進める場面なら、自分がどこで分からなくなったかを言葉にし、返答を読んで次の問いを決める。見込みがなければ戻り、最後は自分で確かめる。この流れは、ほかの仕事にも使えそうです。

正直、こうした進め方を知っているかどうかは、これから大きな差になると思います。「AIは使えない」「まだまだだ」と感じたとき、モデルを評価する前に、自分が何を頼み、返答をどう扱ったのかも見直したほうがよさそうです。

こういうニュースでは、何ができたのかに目が向きます。今回、僕が参考になったのは、タオがどこで疑い、どこで戻ったかまで読めたことでした。AIを具体的にどう使ったかというログは、完成品からは分からない判断を残す重要な資料になっていく気がします。次に似たニュースを見たら、結果だけで終わらず、その過程が公開されていないかまで探してみようと思います。

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

医学はなぜ知識を積み上げられるのか。AI時代のデータドリブン組織に必要な仕組み

夜の診察室で、机の上の一枚のカルテから医学書の棚へ記録が流れていく様子

インターネットのみなさんこんにちは。汎用データ人材のnjunと申します。

はてさて今日は、医学では一件の異変を どうやって知識に変えているのかを調べてみた話です。

きっかけは、知り合いの医師にこんなことを聞いたことでした。

未知の症状や病気、まだ確立していない治療効果は、医学ではどうやって見つけ、確かめていくのか。

データの仕事をしているので、ランダム化比較試験や因果推論の話が中心になると思っていました。返ってきたのは、その前後の話でした。

ざっくり言うと、一人の患者に起きたことを症例報告として残す。似た事例が増えたら並べて見る。そこで生まれた仮説を観察研究で調べ、必要ならランダム化比較試験へ進む。研究が蓄積したら、複数の結果をまとめて検討する。

正直、症例集積やメタアナリシスという言葉も、当時は人に説明できるほど理解していませんでした。話を聞いたあと、公開されている資料をいくつか読んで、自分の仕事に置き換えて考えてみました。

調べてみて面白かったのは、個々の分析手法より、その前後の運用です。何を記録するのか。どこへ蓄積するのか。誰が読み返し、どの段階で次の研究へ送るのか。医学では、観察を次の検証へ渡すところまで細かく決められていました。

※医学は専門外です。この記事は、医師との会話をきっかけに公開資料を読み、自分なりに整理したものです。誤りがあればご指摘ください。

5人の症例報告が、次の調査につながった

調べていて特に印象に残ったのが、HIV/AIDSの最初期の報告です。

1981年6月、アメリカ疾病対策センターの週報に、ロサンゼルスの5人の若い男性が、健康な人にはほとんど見られない肺炎を発症したと報告されました。当時は原因も分かっていません。

これは大規模な調査ではなく、医師が通常とは違う症例を記録し、共有した短い報告でした。この一報だけで病気の原因が分かったわけではありません。それでも別の症例やその後の研究と結びつき、HIV/AIDSを認識していく初期の手がかりになりました。

原報告を読んでみて、症例報告の役割が少し分かりました。一件から結論を出すためではなく、まだ説明できない異常を、次に調べられる形で残すためのものです。

エビデンスの段階は、研究手法の順位表ではなかった

エビデンスの段階については、Oxford Centre for Evidence-Based Medicineによる整理を参考にしました。医学では、症例報告、観察研究、ランダム化試験、システマティックレビューなど、証拠の種類をいくつかの段階に分けて扱います。

症例報告から症例集積、観察研究、ランダム化比較試験、メタアナリシスへ積み上がるエビデンスヒエラルキーの図。上へ行くほど一般化と因果推論に強く、下の証拠が次の問いを生む

僕は最初、上にある手法ほど偉いという順位表だと思っていました。調べてみると、そういう話ではありませんでした。

症例報告は、異常を記録して問いを作る。症例集積では、似た事例を並べて共通点を探す。観察研究では、より大きなデータで関連や仮説を調べる。ランダム化比較試験では介入の効果を検証し、メタアナリシスでは複数の研究結果を統合します。

下の段階は新しい問いを見つけるために必要で、上の段階は一般化や因果判断の確度を上げるために使われる。倫理上ランダム化試験ができない問いもあり、実際の研究がいつもこの順番で進むわけでもありません。

この役割分担があるから、一件の症例を最終結論と取り違えずに済む。同時に、N=1だからという理由で異常を捨てずにも済みます。

ビジネスのエビデンス生成は、医学よりかなり未成熟だ

自分の仕事に置き換えると、症例報告に近い活動はすでにあります。ユーザーインタビュー、障害対応後のレトロスペクティブ、CSへの問い合わせ、特定顧客の成功事例などです。

ただ、これらは個別に残るだけで、似た事例を体系的に束ねるところまで進むことはほとんどありません。僕が見てきた範囲では、多くの組織が行っているのはログ分析やセグメント分析といった観察研究相当まで。進んだ組織でA/Bテストが運用され、その結果が管理されている程度です。複数の施策や実験を横断して結論を更新する仕組みは、見たことがありません。

メモが床の亀裂に消えていく組織と、記録が棚まで運ばれていく組織を対比したイラスト

医学とビジネスを対応させると、次のようになります。

医学 ビジネス
メタアナリシス 組織横断の知見統合
RCT A/Bテスト
観察研究 ログ分析・因果推論
症例集積 類似事例レビュー
症例報告 N=1(インタビュー・障害・成功例)

この表を自分の仕事に重ねると、活動そのものはあるのに、前後が切れていることに気づきます。インタビュー、ログ分析、A/Bテストがそれぞれ別の場所で管理され、どの観察から次の検証へ進んだのかが残らない。足りないのは高度な分析手法というより、個別の観察を集めて次へ送る流れです。

ビジネスでは、間違いをやり直しやすかった

なぜここまで差がついたのか。僕は、間違いのコストが大きいと思っています。

医療では、誤った因果関係を信じて治療を選べば、患者の生命や健康を損ねます。どの証拠から何を言えるのかを区別し、記録と検証を制度化する必要がありました。

一般的なWebサービスでは、検索順位、レコメンド、UIの選択を外しても、多くの場合は元に戻せます。事業機会やユーザー体験を損なうことはあっても、通常は人命には直結しません。やり直せる前提が高速な試行錯誤を支えた反面、仮説の発見から検証までを厳密に保存しなくても事業を回せました。

もちろん、プライバシー、差別、安全、金融など、ITでも間違いが重大な害につながる領域はあります。ここで比べているのは、日常的なプロダクト改善で求められてきた厳密さの差です。

「データを大切にする」を、作業手順まで落とす

データドリブンについて語られるとき、「文化を作ろう」という話はよく出てきます。数字で議論する、失敗を責めない、仮説を検証する。どれも必要ですが、それだけでは、誰が何を記録し、いつ見直すのかまでは決まりません。

調べていて意外だったのは、医学ではこの部分もかなり手順化されていることでした。症例報告には記載形式と共有先があり、臨床試験には開始前に計画を登録する仕組みがあります。複数の研究をまとめるときにも、報告項目をそろえるための指針が用意されている。こうした制度は、僕も今回調べるまで知りませんでした。

ここまで調べると、ビジネス側で決めるべきことも見えてきます。何を報告するのか。どこに残すのか。誰が見直すのか。どの条件で分析へ送るのか。結果をどこへ戻すのか。

現場で気づいた事例には、観察した事実、発生条件、別の説明候補、元情報へのリンクを残す。定期的に類似事例を並べ、繰り返しが見えたものを分析や実験のバックログへ送る。検証が終わったら、結果を元の事例へ書き戻します。

旗を掲げるだけの組織と、記録が受け付けから分類、分析、知識の棚まで流れる組織を対比したイラスト

道具はNotionでもスプレッドシートでも、Slackのワークフローでも構いません。保存場所を作ることより、誰が読み、次の調査へどう送るのかを決めるほうが重要です。

AIで分析が速くなるほど、収集と蓄積が差になる

AIとの関係でも、同じ話だと思っています。

集計、可視化、セグメント探索、分析コードの作成にかかる時間は短くなり、定型的な分析を実行するコストも下がっていくはずです。

でも、記録されていない違和感は分析できません。CS担当者の頭の中にだけある問い合わせの変化も、障害対応中に気づいた偏りも、AIに渡せる形で残っていなければ対象にならない。

データ人材の仕事も、依頼された数字を出すことだけではなくなります。各職種から上がる観察を整理し、過去の事例と結びつけ、どの強さの検証が必要かを判断する。分析の前後を設計する仕事の比重が増えていくと思います。

N=1を大事にすることは、N=1を信じることではない

ここは誤解したくないところです。一人の顧客の声だけでロードマップを変えたり、一件の要望を市場全体の需要とみなしたりするのは、N=1を重視することとは違います。

N=1は仮説を作るには強く、一般化には弱い。だから、似た事例を集め、観察データで調べ、必要なら実験へ進む。医学の段階分けは、この役割を混ぜないためにも機能していると理解しました。

プロダクト開発でも、すぐ戻せるUI変更なら一件の観察をきっかけに小さく試せます。価格改定や大規模な組織変更のように戻しにくい判断には、より強い証拠が要ります。

医学に学ぶ知識を更新する仕組み

医師に質問したとき、僕は因果推論の方法を聞くつもりでいました。調べてみて、より印象に残ったのは、観察を拾い、蓄積し、検証へ送り、その結果を元の記録へ戻す運用でした。

医学の仕組みを、そのままビジネスへコピーできるとは思いません。それでも、ユーザーインタビューや障害報告を個別のメモで終わらせず、次の分析に使える形で残すことはできます。

AIで分析の実行コストが下がるほど、何を分析対象として残しているかが効いてきます。AIで分析自動化!みたいな突飛なことをせずにこういった地道でいぶし銀なデータのお仕事をしていきたいものです。

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

サッカーとデータサイエンスの挿絵

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

日本はブラジルに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%で、後者のほうが高くなります。回数が多いことと、成功しやすいことは別です。

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

\displaystyle G = N \times p

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

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

\displaystyle G(L) = N(L) \times p(L)

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

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

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

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

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

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

\displaystyle P(\mathrm{goal} \mid \mathrm{CK}) = P(\mathrm{shot} \mid \mathrm{CK}) \times P(\mathrm{goal} \mid \mathrm{shot}) \approx 0.205 \times 0.11 \approx 0.022

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

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

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

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

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

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

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

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

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

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

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

シュート位置とxGの挿絵

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

\displaystyle \mathrm{xG} = P(Y = 1 \mid x)

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

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

\displaystyle \eta = \beta_0 + \sum_{j=1}^{k}\beta_j x_j, \qquad P(Y = 1 \mid x) = \frac{1}{1 + e^{-\eta}}

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

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

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

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

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

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

\displaystyle \mathrm{xG}_{\mathrm{team}} = \sum_{i=1}^{n} p_i

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

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

\displaystyle G = \sum_{i=1}^{n} Y_i, \qquad Y_i \sim \mathrm{Bernoulli}(p_i)

合計xGだけを使って試合の得点を大まかに見るなら、 \lambda = \sum_{i=1}^{n}p_i と置き、ポアソン分布で近似する方法もあります。

\displaystyle P(K = k) = \frac{\lambda^{k} e^{-\lambda}}{k!}

 \lambda=1.0 なら、無得点が約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です。

\displaystyle \mathrm{PSxG} = P(Y = 1 \mid x, \mathrm{trajectory})

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

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

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

\displaystyle S = \sum_{i=1}^{n}\mathrm{PSxG}_i - G_{\mathrm{conceded}}

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

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

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

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

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

\displaystyle V(s) = P(\mathrm{goal\ before\ turnover} \mid s)

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

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

\displaystyle \Delta V = V(s_{\mathrm{after}}) - V(s_{\mathrm{before}})

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

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

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

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

\displaystyle \mathrm{EV} = p\,\Delta V_{\mathrm{success}} + (1-p)\,\Delta V_{\mathrm{failure}}

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

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

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

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

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

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

トラッキングデータとピッチコントロールの挿絵

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

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

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

\displaystyle \mathrm{PC}_A(z) = P(T_A(z) \lt T_B(z) \mid \mathcal{D})

地点  z をチームAが支配できる確率  \mathrm{PC}_A(z) を表しています。 \mathcal{D} は、選手の位置、速度、向きなど、その時点で観測できるデータです。

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

\displaystyle \mathrm{PC}_A(z) = \frac{1}{1 + \exp\left\lbrack -\frac{T_B(z)-T_A(z)}{\sigma}\right\rbrack }

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

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

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

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

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

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

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

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

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

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

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

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

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

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

\displaystyle P(\mathrm{success}) = \prod_{i=1}^{n} p_i

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

試合を見るときの問い

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

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

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

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

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

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

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

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

参考

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

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年間がかなり生々しく書かれています。

檻の中にあるTransformerモデル

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とメタデータを舐めてはいけない

メタデータが整ったDWHをAIが読み解くイラスト

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

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

これはポジショントークというより、かなり実感に近い。自然言語で問いを投げると、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匹のキャラクターだけでは語りきれない。交換したくなる仕組み、名前をつけられる仕様、ケーブルを通って移動する演出、学校帰りに子どもたちが向かい合う場面。ゲームの外側にある行動まで設計に入っていた。

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

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

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

数値・日付・エピソード・発言はすべて同書(第1部・第2部・復刊付録)に基づく。