人間が事前に定義する範囲は、70年でどこまで縮んだか
はじめに
配送計画のモデルを組む仕事では、最初にやることが昔から変わっていません。何を最小にしたいのかを一本の式にして、守るべき条件を並べます。ここは自動化されていません。一方で、その式をどう解くかは誰も書きません。ソルバーに渡せば、どの変数から分枝するかも、どこで緩和を打ち切るかも向こうが決めます。
同じ対比は、計算機の歴史のあちこちにあります。1957年にFORTRANが実用に入ったとき、人の手から離れたのはメモリ番地とレジスタの割り当てでした。1970年代に関係データベースが広まったとき、離れたのはデータへの到達経路でした。どちらも、それまで人が先に書いていたものです。
FORTRANからおよそ70年が経ちました。その間に「人間が先に書かなければならなかったもの」がどう変わってきたかを追います。
対象読者:
- AIや自動化の適用範囲を決める立場で、機械にどこまで任せられるかの線を引きたい方
- 機械学習や最適化のプロジェクトで、人間側にどれだけの作業が残るかを見積もりたい方
- 計算機の歴史を、技術年表としてではなく設計判断の変遷として読みたい方
記事のポイント:
- 番地の割り当て、データへの到達経路、規則の記述という順に、人が書く範囲が機械へ移っていった経緯を、それぞれの出来事に即して追います
- 機械に任せられた仕事には、正しさを機械が自分で検算できるという共通点があることを示します
- 目的の記述と正しさの基準が、70年のあいだ一度も機械側に移っていない理由を説明します
番地とレジスタを人が割り当てていた頃
1957年4月にIBMのジョン・バッカスらがFORTRANを納めるまで、科学計算のプログラムは番地の管理そのものでした。どの値をどのレジスタに置くか、ループを抜けた先はどの命令か。すべて書く側が決めていました。
その割り当てを機械に任せるという構想は、発表された当時ほとんど信用されていませんでした。計算機のメモリが小さく実行時間が高価だった時代に、機械が生成したコードが熟練者の手書きに並ぶとは考えられなかったからです。実際、FORTRAN以前の高水準の道具が出すコードは、手書きに比べて5倍から10倍遅いのが普通でした。反発は技術的な見立てにとどまらず、機械語で性能を引き出す技能そのものへの自負からも来ていたと記録されています。
だからバッカスの側は、最優先の設計目標を効率に置きました。最適化を組み込んだコンパイラが手書きに近い速度を出したところで、この議論は決着しています。
このとき機械に渡ったのは、どう計算させるかの一部です。レジスタの割り当て、ループの扱い、命令の並べ替えが向こう側に行きました。人に残ったのは、何を計算するかの記述です。
渡せた理由もはっきりしています。レジスタ割り当ての正しさは形式的に定義できます。式の値が変わらなければ正しい、という基準がプログラムの意味そのものに含まれています。基準が問題の側にあるので、コンパイラは自由に探索してよいことになります。
ポインタをたどる順番を、誰が決めるか
次に機械側へ渡ったのは、データへの到達経路でした。
1973年のチューリング賞講演で、チャールズ・バックマンが選んだ題は「The Programmer as Navigator（航海者としてのプログラマ）」です。当時のデータベースはレコード間のポインタをたどって目的の値に届く方式で、どの関係をどの順にたどるかはプログラムを書く人が決めていました。講演の題は比喩というより、職務内容の説明に近いものです。
その3年前、E. F. コッドは関係モデルの論文で、アプリケーションがデータの物理的な表現や到達経路に依存している状態を問題として挙げていました。コッドが求めたのはデータ独立性（data independence）で、格納の仕方が変わってもプログラムを書き直さずに済むことです。そのために、データへのアクセスは手続きを書かない言語で行うべきだと主張しました。
1974年、IBMサンノゼ研究所のドナルド・チェンバリンとレイモンド・ボイスがSEQUELを発表します。書くのは欲しい集合の条件だけで、どのインデックスを使い、どの順で結合するかは最適化器が実行時に決めます。この設計は現在のSQLにそのまま残っています。
ここで機械が引き受けたのは、探索そのものです。しかも、候補となる実行計画を列挙して、コストの見積もりで一つを選ぶという形になりました。これが可能だったのも、正しさが独立に定義できたからです。どの計画で走らせても返る行の集合は同じでなければならない、という基準が問い合わせの意味の側にあります。
ただし、人の作業が消えたわけではありません。統計情報が古ければ最適化器は誤った計画を選びますし、実行計画を読んで直す仕事は今も残っています。書く仕事が、読んで診断する仕事に置き換わったと言うほうが正確です。
規則を書き足し続ける方式が止まったところ
ここまでの2つは、計算をどう進めるかの話でした。次に人が手放そうとしたのは、判断の中身です。
初期の例として分かりやすいのがELIZAです。ジョセフ・ワイゼンバウムが1966年にCACMで発表したこのプログラムは、入力を左から走査してキーワードを拾い、そのキーワードに紐づく分解規則で文を切り、再構成のひな型に当てはめて応答を作ります。DOCTORスクリプトの中身はその規則の並びで、全体でも数百行に収まります。書いた規則に噛み合う入力には応答できますが、外側には何もありません。
1970年代のスタンフォードで作られたMYCINは、血液の細菌感染症を診断して抗菌薬を推奨するシステムで、感染症の専門医から聞き取った規則をおよそ600本持っていました。産業側の代表例はXCONです。1978年からDECの委託でカーネギーメロン大学のジョン・マクダーモットらが開発し、1980年にニューハンプシャー州セイラムの工場で稼働しました。納入時点で750本ほどの規則を持ち、最終的には2,500本程度まで増えています。
苦しかったのは本数ではなく、規則どうしの絡み合いでした。1本を直す前に、それが全体に及ぼす影響を理解している必要があります。理解している人は限られ、変更には時間がかかります。エドワード・ファイゲンバウムは1977年の論文で、専門家の知識を取り出して形にする工程こそが律速になると指摘しました。知識獲得のボトルネック（knowledge acquisition bottleneck）と呼ばれるものです。
1980年代の終わりから1990年代にかけて、この工程を人手で回すのをやめる動きが出ます。IBMのCANDIDEは機械翻訳に統計的手法を持ち込み、文法規則を人手で書く代わりに対訳コーパスからパラメータを推定しました（Brown et al., 1990）。カナダ議会の議事録という大量の対訳が手に入る条件が揃っていました。同じ発想は音声認識でも先行して動いていて、規則を書く方式は10年ほどのあいだに主流から外れました。
2010年代の深層学習で、さらに特徴量の設計が向こう側に行きます。画像で何をエッジとして拾うか、音声でどの帯域を取るかを人が決めていた部分が、表現の学習に置き換わりました。
規則を書く負担は確かに消えました。代わりに現れたのが、データを集める作業と、何を正解とみなすかを決める作業です。この入れ替わりで、それまでの2回とは性質が変わりました。コンパイラも問い合わせ最適化器も、正しさの基準を機械の側に持てました。統計モデルの正しさは、人が用意した正解と突き合わせないと測れません。基準の側が人間に降りてきたのが、この時点です。
手順を書かずに走らせる、いまの形
直近で機械へ渡ったのは、実行の順番です。どの道具を呼ぶか、どの順で呼ぶか、返ってきた結果を見て次に何をするかを、実行時にモデルが決めます。人が書くのは、目的を述べた指示文と、使ってよい道具の一覧です。想定される入力の型を先に列挙する必要も、対応表を網羅する必要もなくなりました。
見かけ上、事前に書く量は大きく減っています。ただし、減ったのか見えなくなったのかは分けて考える必要があります。
規則を書いていた頃は、書いた分量が目に見えていました。XCONの2,500本は数えられます。いまは指示文が数百行、道具の定義が十数本で済むように見えます。しかし実際に挙動を決めている前提は、そこだけにありません。評価用のデータとして何を集めたか、どの操作に自動実行の権限を与えたか、どこで人の承認を挟むか、失敗をどう検知するか。これらは指示文の外にあって、書いた分量として数えられません。指示文が短いことと、事前に決めたことが少ないことは、別の話です。
70年のあいだ人間側に残ったもの
ここまでを並べると、機械に渡ったのは番地の割り当て、制御構造、データへの到達経路、規則、特徴量、実行の順番です。では、渡らなかったものは何かを見ていきます。
目的を式にする仕事は、途中から生まれて残った
最適化の側から見ると、目的関数を書く仕事は縮んでいないどころか、歴史の途中で新しく発生しています。
ジョージ・ダンツィークが1947年に線形計画のモデルを立てるまで、軍の計画立案は権限を持つ側が出す多数の個別の決まりごと（ground rules）で回っていました。良い計画を選ぶための明示的な目的が、そもそも置かれていません。ダンツィークがやったのは、その決まりごとを一つずつ検討して線形計画の形に置き直し、選択の基準を一本の目的関数にまとめることでした。1947年の時点では、目的関数という考え方自体が新しいものでした。
それから、何を最小化するかを決める工程は一度も機械に渡っていません。ソルバーは与えられた式を解きますが、その式が解きたい問題を表しているかどうかは判定しません。LLMに定式化を書かせられるようになっても、この構図は変わりません。
実務でもこの工程がいちばん時間を食います。相談は「配送コストを下げたい」という形で来ます。訊いていくと、下げたいのは燃料費なのか、ドライバーの拘束時間なのか、遅配の件数なのかが分かれてきます。3つは同時には最小化できず、どこに重みを置くかで出てくる解が変わります。この選択は計算の外にある判断で、たいていは社内でも意見が割れています。重みが決まれば、あとは式に落として解かせるだけです。決めるところまでが人の担当で、そこは70年前から動いていません。
信用リスクのモデリングでも同じでした。判別性能の指標を上げること自体が目的だったことはありません。貸し倒れの損失と、断ってしまった優良先の逸失を、どの比で見るか。この比を決めるのは事業側であって、モデルの側からは出てきません。
何を正しいとするかは、機械の側に置けない
機械に渡せた仕事を並べ直すと、共通点があります。いずれも、正しさを機械が自分で検算できました。レジスタ割り当ては式の値が変わらなければ正しく、実行計画は返る行が同じなら正しく、ソルバーの探索結果は制約を満たしていれば実行可能です。正しさの定義が問題の記述そのものに入っているので、そこから先の探索は任せられます。
統計的学習から先は、これが成り立ちません。正しさは人が用意した正解との一致でしか測れず、その正解を誰がどう作るかは計算の外にあります。評価データを何件、どういう分布で集めるかを決めるのは人の仕事で、しかもその決め方が結論の精度を左右します。何件あれば差が見えるかを計算で詰められるようになっても、何を測るかを決める部分は残ります。
生成の評価まで来ると、さらに込み入ります。良い要約とは何かを式にした時点で、測りたかったものから外れます。そこで人手の評価や、別のモデルによる審判を挟むことになりますが、その審判の基準もまた人が書きます。負担は規則から正解の定義へ、さらに評価の設計へと動きました。位置が変わっただけで、量が減ったとは言い切れません。
結果を引き受ける先も動いていません。コンパイラが誤ったコードを吐けば処理系の欠陥として扱えました。正しさの基準が形式的なので、誰の責任かも形式的に決まります。モデルの出力にはこれがありません。規制のある領域では出力の根拠を示せることが要件になり、要件を満たしているかを判定するのは監督当局と自社であって、モデルではありません。
統計にも同じ配分の問題がある
事前に何を決めるかという問題は、統計の内側にもあります。頻度主義とベイズの違いは、事前の決めごとをどこに置くかの違いとしても読めます。ベイズは事前分布という形で明示的に置き、頻度主義は有意水準や検定の設計に織り込みます。どちらも事前の決めごとから自由なわけではなく、置き場所と見えやすさが違います。
この違いは実務にそのまま響きます。明示的に置いたものは、後から議論の対象にできます。事前分布の選択がおかしいという指摘は成立しますが、暗黙のうちに置かれた前提には指摘のしようがありません。事前定義を減らすことより、どこに置いたかを見える形で残すことのほうが、運用では大きな意味を持ちます。
まとめ
70年で機械に渡ったものを並べると、番地の割り当て、制御構造、データへの到達経路、規則、特徴量、実行の順番でした。渡せたのは、正しさの基準が問題の記述の側にあって、機械が自分で検算できたものです。基準そのものを人が決めなければならない領域は、一度も渡っていません。
目的を式にする工程は、線形計画が生まれた時点で新しく人の仕事になり、そのまま残りました。正解と評価の設計は、統計的学習が広まったときに人の側へ回ってきて、いまも増え続けています。総量が減ったというより、置き場所が動いて、数えにくいところに寄ったと見るほうが実態に近いと思います。
いま動かしているシステムがあるなら、指示文と道具の定義の外側で、暗黙のうちに事前定義しているものを書き出してみてください。どの操作を自動で通してよいことにしたか、何をもって成功とみなしたか、失敗したときに誰がどうやって気づくか。指示文の行数より、この一覧の長さのほうが運用の重さをよく表します。
