枕文：量子ビットは通常平面上の漁期に配置される。格子手術を用いるプログラムは、この領域の一部、通常は四角やブロックを組合わせたペントミノのような形の量子ビットを使用する。これを時間方向に伸ばして考えると、3次元の直方体の中に、ある時刻からある時刻まで、この領域を使う、という、立体ペントミノを配置するようなことになる。また、プログラムは一回使った領域を使い続けるわけではないので、時間軸方向にもでこぼこした、立体ペントミノ、ブロックを配置することになる。いくつものプログラム（タスク）をスケジュールすることは、この直方体の中に互いにオーバーラップしないように、プログラムに対応するペントミノブロックを配置することになる。

問題カタログ

格子手術を用いたプログラムのスケジューリング問題

量子ビットは通常平面上の漁期に配置される。格子手術を用いるプログラムは、この領域の一部、通常は四角やブロックを組合わせたペントミノのような形の量子ビットを使用する。これを時間方向に伸ばして考えると、3次元の直方体の中に、ある時刻からある時刻まで、この領域を使う、という、立体ペントミノを配置するようなことになる。また、プログラムは一回使った領域を使い続けるわけではないので、時間軸方向にもでこぼこした、立体ペントミノ、ブロックを配置することになる。いくつものプログラム（タスク）をスケジュールすることは、この直方体の中に互いにオーバーラップしないように、プログラムに対応するペントミノブロックを配置することになる。

（絵で解説したいなあ）

・立体の詰め込み問題が、そのままスケジューリング問題になる。このようなある種くせのあるペントミノだけを詰め込む問題として考えることで、優位性を作るような、最適化アルゴリズムの研究が考えられる

・プログラム、実行途中で、エラー訂正や、魔法状態の生成など、様々な計算コストの高い作業が発生する、つまり実行時間の遅れが発生する可能性がある。そのため、遅れたときの被害が最小になるようなスケジューリングを行うという目的意識はあると考える。

目的関数の設計としては、たとえば、各タスクxに対して、遅れるとxに遅れが発生する、つまりxと異存関係がある先行ジョブの個数を計算して、それを評価値とする方法が考えられる。全てのタスクに関する評価値の総和の最小化や、評価値の最大値の最小化が考えられる。

サブタイトル

・タスクに対応するペントミノブロックの形は変化させることができる。タスクの形が固定されていない。時間軸方向に対する連続性が保たれていれば、一部のブロックを平面上で移動させることができる。ただし、左右方向の移動はできるが、それを上下方向にすることはできない、などの制約がある場合もある。なので、「変形が可能な立体ブロックの詰め込み問題」になっており、これは最適化アルゴリズムの問題として新しい概念を含んでおり、面白そうである

サブタイトル

・タスクに対応するペントミノブロックの形は変化させることができる。タスクの形が固定されていない。時間軸方向に対する連続性が保たれていれば、一部のブロックを平面上で移動させることができる。ただし、左右方向の移動はできるが、それを上下方向にすることはできない、などの制約がある場合もある。なので、「変形が可能な立体ブロックの詰め込み問題」になっており、これは最適化アルゴリズムの問題として新しい概念を含んでおり、面白そうである

サブタイトル

・タスクに対応するペントミノブロックの形は変化させることができる。タスクの形が固定されていない。時間軸方向に対する連続性が保たれていれば、一部のブロックを平面上で移動させることができる。ただし、左右方向の移動はできるが、それを上下方向にすることはできない、などの制約がある場合もある。なので、「変形が可能な立体ブロックの詰め込み問題」になっており、これは最適化アルゴリズムの問題として新しい概念を含んでおり、面白そうである

サブタイトル

・ものづくりなどの工場の現場でのスケジューリング等、現実社会でのスケジューリング問題では、スループットを最大化することが最重要な価値軸ではないことが多い。急な依頼が来てもだいじょうぶなように、常にある程度空きを設けることや、新しい仕事の問い合わせに短時間で回答できるよう、再スケジューリングの高速化が重要課題であったりもする。

・その意味で、タスクのキャンセル、挿入、変化などに対応するようなメカニズムを設計する方が、現実的には機構のほうが重要かもしれない。リスケジューリングのやりやすさとか重要。 京も、けっこう使用割合がすかすかだったりする。あちらも、幾何的な状況があり、直方体のジョブだけが出てくるような状況。こちらのほうが難しいが、だいたい似たような状況だと思われる。

こういう状況だと、スループットを極めるよりも（こちらのほうが価値の提示はしやすいと思うが）、いろいろな概念、価値軸に対応できるような、様々な方向性の研究ができるほうが、世のため人のためかもしれない。

問題を発見する議論

この議論のモチベーション

• コンパイラの定義を広げることで、コンパイラが扱える領域を広げてみたい
• コンパイラってそもそも何なのか？をChatGPTの存在から揺り動かしたい
• 翻訳にコンパイラの技術ってはいるんじゃないか？

場所とシチュエーション

• NIIの准教授で、計算機言語の研究やコンパイラの研究をしている関山さんが神田ラボに遊びに来てくれた。
• 宇野さんと関山さんは、お互いに分野同士の違いなどを情報交換している関係。
• 宇野さんはChatGPTについて関心があり、関山さんがやっている人間が作ったものや抽象的なものを機械可読なものに変換する、計算言語とコンパイラの研究は、ChatGPTとどう違うのかに興味を持って、関山さんに質問を始めた。

コンパイラとは何か？

• 言語を他の言語に変換し、その言語のプログラムを計算機上で実行させるもの。 狭い意味でコンパイラは、言語を機械語に変換し、実行するものであるが、他の言語、あるいは仮想機械コードに変換するものもコンパイラと呼ぶ。他の言語に変換するときには、特に translatorと呼ぶ場合もある。
• コンパイラは人間が作ったものを機械可読の形に変換するというもの。コンピュータのCPUの命令セットはすごく初等的な演算が多いが、対して人間が作ってるコンピュータ言語といわれているPythonなどは抽象的に書かれている。人間にとっては抽象的であることが機械的なのだが、それを機械が読める形にある種のルールに従って変換し、なるべく効率が良く、途中でエラーがあったらちゃんと自動的に検出できるようにするという研究分野。参考

場所とシチュエーション

関山さんが神田ラボにやってくる前に、宇野さんは「関山さんと話したいこと」や「関山さんと話す前の自分の考え」を以下のような事前メモにまとめていた。

ChatGPTとコンパイラ

最近、ChatGPTやAI翻訳ツールが出てきたおかげで、機械が意味を扱えるようになってきた。このことで、生成AIや機械翻訳とコンパイラの世界が近づいてきたような印象がある。もしかしたら、機械学習にコンパイラのこれまでの研究成果や考え方が活かせるようになるのではないか？ 例えばAI翻訳を例にとると、自動翻訳では機能や使用が定義されていない。意味が正しく伝わることが目的であり、意味が近い方がいいですよね、というある種の最適化が行われ、変換されている。

しかし、世の中には意味が全く同じになるように保存される必要がないものも結構ある。機能または仕様が満たされていれば良いというもの。例えば特許文書などの執筆では、意味が同じである必要はなく、機能と仕様にズレがなければ良いという場合もある。「こういうものを作りました、こういうところに有用性があります」と伝えると、弁理士さんが書き直して特許文書の形式に変換する。このような変換は、ひょっとしたらコンパイラなんじゃないのか？

これをいい感じのメールに描き直してください、とChatGPTに指示して書き直させるのは意味を保存して機能を変えている。これはコンパイラなのか？ChatGPTが登場したおかげで、翻訳と添削、およびコンパイラの定義が連続的に繋がっているかあやふやになっているのでは？ まとめると、

・ChatGPTが、文章の添削や、丁寧な文章にすることや、プログラムの整形とか、いろんなことをしてくれるようになった。

・今までの文章（線形な文字列で意味や機能を持つモノ）の変換と言えば、コンパイラ、翻訳、添削など。chatGPTはこれらの操作をなめらかにつないでしまった。

・すると、翻訳とはなんなのか、コンパイルとはなんなのか、境目がわからなくなってくる。言語を変換するとか、機能や意味を保っているとか、なんか性能や上品さをよくしているとか、そういうレベルで考えると、違いが見えないように思える。 というのが元々持っていた問題意識。

コンパイラの拡大と再定義による新領域の可能性 コンパイラはそもそも計算機のためにデザインされている概念で、これまで言語や意味などは扱ってこなかった。しかし、ChatGPTや機械翻訳など「意味を変換する機械」が登場したことで、意味までを扱うものとして再定義することができるのではないだろうか？ ならば、意味を扱えるコンパイラを再定義する上で、コンパイラとはそもそもなんなのか？を検討した。

辞書では、「ものを集めて合成するアセンブリング」のような意味合いも入っているが、それはちょっと違うように思う。コンパイラでは、意味自体を扱わず、記号列を別の記号列に変換するだけで、記号列以外のなにか違うものを保存するということは考えていない。

一方でChatGPTではメール文を別の書き方に変換してくださいというとき、何かの意味ベクトル的なものに一旦置き換えられ、特定のルールにおいて違う形に変換されてくる。学習結果によって、このベクトル空間のようなものが変化してくるので、機械的にルールが記述されていない。 コンパイラ側でも最近では一意にルールが決まっているわけではなくて、効率をよくするために順番を入れ替えたり、こういう場合はこうしたいという変換をしたりと色々行っているが、基本的には元々やろうとしていたことと結果的に出てきたコードが同じであればOK、という考え方。 そういう意味では、コンパイラではやってることと意味が同じならOK、ということになるが、「意味が同じ」は判定ができないのでよくわからない。意味を保存するのは難しいが、わかりやすいのは例えば、以下のようなデータのフォーマットの変換。

・データフォーマットの変換（住所の書き方、番地の書き方、単位を30cmから0.3mに変える、表記揺れの修正、セブンイレブンを7-11に、座標の変換、日付、電話番号、金額、名前と苗字の連結など）

・事務文書の作成（定型の所を埋める） こういう変換は、意外としんどい作業としてある。これもある種コンパイラ的な話かもしれない。そう考えると、コンパイラのところには変換するためのノウハウや知見がいろいろすでにある。わざわざ人間が指示をださなくてもコンパイラが認識して自動でやるべきことかもしれない。

北海道に出張に行く時の要件や、事務文書の作成なども、何らかの骨格があり、要件があり、あらかじめデータも存在するので、ある種のコンパイラと言えるのではないか。今はコンパイラというと、計算でしか考えていない。しかしコンパイラを広く考えてみると、機械に変換しますというだけじゃない定義で、違う考え方があるんじゃないか。

コンパイラを広く再定義することで、「新しい定義ではこういうことができるといいですよね」というコンパイラの新しい研究領域が生まれるかもしれない。例えば、「一貫性を保つのがコンパイラである」、「要件をつけていって、もののシークエンスを変換すのがコンパイラである」と別の定義でコンパイラを捉えてみると、ならばその要件とは何か？という話になり研究が広がるのではないだろうか？

関山さんと宇野さんの対話

上記の宇野さんの問題意識をもとに、関山さんとの議論が始まった。 自然言語をコンパイルする、とプログラムをコンパイルする、を比べながら考えてみよう。何がコンパイラっぽくて、何がコンパイラっぽくないのか？

・考えて、観察してみると、自然言語をコンパイルすることと、プログラムをコンパイルすることは、文字や単語のシークエンスを変換してるという意味では両者は似ている。

・ただし、専門的には機能が同じならいいというわけではない。たとえば、Pythonのfor loopとは同じシークエンスのループを繰り返すものだが、最近ではsubroutineという呼び出し機能を使って書くこともできる。これをコンパイラで書き換えてしまってもいいのかもしれないが、本来はやってほしくない。途中でメモリがなくなってパフォーマンスが落ちたりするため。

・同様に、機能がおなじでも違うアルゴリズムを使って欲しくないという要件がある。例えば、これを主語にしないでほしい、盲導犬を主語にしないでほしいなど。

・何もないところから、指定した機能が達成されるように作ってしまえるなら、それはプログラム生成、とよぶべき。これはプロンプトエンジニアリングに近いものであり、コンパイラではない。こういう機能を作ってください、とお願いして作ってもらうものは、コンパイラとはちょっと違うって感じ。

ではコンパイラっぽいものってどういうものか？

・コンパイラは、1対１対応がある感じの変換をする。これがこういうふう変換されて、逆に元に戻すことができる、という感じの変換をするのがコンパイラだと思う。

・そう考えると翻訳はコンパイラっぽくないかもしれない。翻訳は一度意味に落とし込み、それを他のものにしてもよい。つまり生成をしてもいいし、表現が大きく変わっても、センテンスの構造が変わってもある程度良い。1つの文を2つに分けてもいい。一方で、コンパイラは1文を2文に分けたりしちゃだめ。何となく、翻訳とコンパイラが遠くなってきた気がする。

・ 添削も翻訳と同じだが、表現を大きく変えないようにするときもある。たとえば学術抄訳のようなものは、センテンスを正確に保存する。このような、意訳ではなく、本来の意味を変えない翻訳はコンパイルっぽい。文章も、センテンスとか段落とかの構造はあり、これはだいたい保たれることが多い。メールとかでも構造は結構保っているものはある。

・コンパイラは、そのプログラムの基本構造を変えずに変換しているように思える。つまり、保つべき構造があるかどうか、それは何か、どの程度保つのか、みたいなものが、コンパイラにはあると思う。

・一方で、コンパイラでは、定数回のfor loopは開いてもいい。これは同じものと見なされるらしい。ループの場合は、同じものが繰り返す場合書き換えちゃうこともあるけど、業界的にやっていいやつはある。つまり、必ずしも「書き換えたからコンパイラ的ではない」とは言えない。

・非常に局所的な変更は、機能が保たれれば変形して良いのだろう。ローカルでマイクロスコピックなものは変形していい、など特有のルールがあってOKとされているものもある。プログラムの動作が同じ、あるいは冗長なもの（必ず成り立つ判定文とか）は取り除く、というような、縮約ルールによる変化は認めているのかも知れない

（いつもお世話になっております、は残して、えーとは削っていい、みたいな） ・ソースとターゲットの抽象度が同じ、という要件もあるかもしれない。つまり、仕様、という抽象度のものをプログラム、という抽象度のものに変換するのは、コンパイルではない。片方は要求で片方は実行する手順なので、概念として異なるため。

・しかし、制約式をたくさん与えると、他の形に変換してプログラムにしてしまうものもあるので、この辺りもよくわからない。

・結論、何か要求があって、それが機械的に変換されるものであり、かつ１対１対応であればコンパイラ的と呼べると思う。

・例えば、道案内をつくらせる場合は、ここを出てから、玄関を出てから見回って左に曲がって握った先にあるコンビニまでの行き方を教える文書を作ってくださいみたい、という指示には、まず見回って、次に左に曲がりましょう…みたいなこと書いてある一対一対応のレスポンスになる。これはコンパイラ的。

・一方で、何か面白い話作ってください、という指示に勇者が冒険する話を作ってくれるケースは、指定したものと作ったものは全然一対一に対応してないので生成的。

・ その意味では、翻訳はその条件を満たしているのでコンパイラ的と言えると思う。

・ある種の変換規則に則って行われるのがコンパイラということか。でも、コンパイラでは必ずしも変換規則に則っているとは限らないコード最適化もしている。最適になるべく早く効率よく処理しましょうというときには、ルールを無視して頑張ってしまう側面もある。そういう意味で、コード最適化（規則を超えた変換）はコンパイラの定義に含めるべきではないのか。

まとめと今後の議論の発展

この議論では、コンパイラが近年、抽象化していっていることが背景にあった。コンパイラが単なる言語を別の言語に変換するだけでなく、意味を扱い、最適化を含んだより抽象的なものになっていっている。その傾向が発展していった先に、隣に似たようなものとして生成AIと翻訳があった。この議論では、近づいてきた2つの世界がどのように関連するのかを探ることで、コンパイラ研究の新しい展開の可能性を模索している。

関山さんと宇野さんの議論から、以下の「新しい問い」が話し合われた。 ・生成AI（ChatGPT)の存在から、コンパイラを再定義するとしたら？ ・生成AIとコンパイラの比較：どこまでがコンパイラ的で、どこからが生成的なのか？ ・翻訳はコンパイラか？ ・最適化は、コンパイラに含まれるのか？ ・意味の生合成を、コンパイラと翻訳ではそれぞれどう捉えるか？

意味の整合性のチェックは、ノウハウとして蓄積されているわけではないが、人間の翻訳技術的には行われている。コンパイラ研究側には、構造とか、矛盾がないことを調べる、型の違い、この変数はこういうものという違うことをするとエラーが出る、などが行われている。

問題カタログ一覧へ 問い立ての世界観一覧へ