AIBR プレミアム
拓海先生、最近部下から「合成（synthesis）ってやつでプログラムを自動生成できる」と聞いたのですが、うちの工場の制御に応用できると聞いておりまして。ただ、出来上がったコードがよく分からない、という話もあると聞きました。要するに導入すると現場で困ることはありますか。
素晴らしい着眼点ですね！大丈夫、一緒に整理できますよ。端的に言うと、反応型合成（Reactive synthesis）（反応型システムを仕様から自動生成する技術）は「正しいもの」を作るが、なぜその実装が選ばれたかが見えにくい、という問題があります。今日は要点を三つに分けて説明しますね：仕様を書く難しさ、実装のわかりにくさ、説明責任のための手掛かりです。
なるほど。ですが、具体的には現場でどんな失敗が起きやすいか、イメージが湧きません。例えば想定していない動作をすることがあるという話ですか。
素晴らしい着眼点ですね！はい、二種類あります。一つは過剰に仕様を書きすぎて実現不能になる「過剰指定」、もう一つは指定が足りず結果として合成物が設計者の意図と異なる振る舞いをする「過小指定」です。たとえばライン停止の条件を書き漏らすと、正常動作でも不必要に装置を停止させる実装が合成されることがあるんです。
これって要するに、仕様が不十分だと合成は「約束を守る最低限のやり方」を選んでしまい、現場の期待とズレるということですか。
その通りです！素晴らしい理解ですね。ここで重要なのは三点です。第一に、仕様（specification）（システムがどう振る舞うべきかを記述する文書）を設計者と開発者で共通理解すること。第二に、合成結果のどの決定が重要かを示す「証拠」や「トレース」を出すこと。第三に、その証拠を元に仕様を直し、再合成するループを回す運用です。
証拠やトレースというのは現場で使える形になるのでしょうか。デジタルに弱い私でも現場の責任者に示せるレベルのものでしょうか。
大丈夫、できますよ！ここでも三点を意識してください。まず、合成ツールが出す反例（counterexample）（仕様違反を示す具体的な入力列）や証明トレースを、人が追える「事例」に変換すること。次に、その事例を使って仕様のどの記述が不十分だったかを示すテンプレートを用意すること。最後に、運用ルールとして仕様修正と再合成のワークフローを決めることです。
なるほど、要するに合成そのものだけでなく「合成を使いこなす仕組み」を作る必要があるわけですね。最後に私の言葉でまとめますと、合成は正しく動くコードを作れるが、期待通りの振る舞いにするには仕様の書き方と説明責任を整備する必要がある、ということで間違いありませんか。
その通りです！素晴らしい着眼点ですね。大丈夫、一緒にやれば必ずできますよ。まずは小さなライン制御などから仕様と証拠のテンプレートを運用に落とし込みましょう。
