「思考過程をモデル化する」

東京工業大学資源化学研究所 教授
仲勇治

１． 背 景「ケミカル エンジニアリング」が始まり 100 年以上、「化学工学」が始まって 60
年、その間には、やはりベースボールと野球の違いがあるようです。この違いは「ささら」的思考によるもので、日本の文化形成にあるといえます。あまりにも独立性や主体性（identity には帰属意識という意味も含まれています。
）を意識し過ぎるために、僅かな違いをことさら大きな違いに言い立てる傾向があります。どの土俵の上に立つかは、その人の生まれにも似たもので他の人にとっては意味のない話です。他の人にとって重要なことは、目的を達成するためにどのような役割を担って協力できるかが重要です。実際に社会で起こる問題は、分野に依存した形態で起こってくるわけではありません。これからお話を展開するのは、現実に起こる様々な問題を、可能な限り大きな視野から評価しながら解決していく仕組みをお話ししたいと思っています。その逆もあり得ます。すばらしい技術を開発しても、全体としてその良さが認識できなければ、それは無視されるかもしれません。
「何が起こるか分からない」から、「出たとこ勝負だ」という意見もあるでしょう。しかし、技術が絡む多くの経済活動は、かなりの部分予測できるものです。予測できなくとも、意外な方向に仮に進んでも１から対応を考えるのではなく自らで備えてきたポテンシャルを発揮する方が得策になることが往々にしてあります。この考え方のベースになる（と思って）統合学［1］のお話を始めたいと思います。

２． モデル化の意味
化学工学、特に、日本の大学で「古い」「苔むしている」などとクソミソに言われている大学でユニットオペレーションは、今も通用するモデル化の仕組みを持っています。ケミカルエンジニアリングの「ユニットオペレーション」は、プロセス設計を合理的に進める方法論として、英国に端を発して、その後米国でまとめ上げられたものです。この考え方は、ここで解説するまでもありませんが、そこに含まれている単位操作名は今でも使われていますし、そこで行われている研究もまだまだ沢山あります。しかし、多くの大学では単位操作の名称が古く、ユニットオペレーションの種類が不足して、多様なプロセスを組み立てられないという理由から、生物化学工学、環境化学工学、など様々な形態を取りながら展開し、内容の詳細化が行われてきました。
しかし、そこで行ってきたことは、所詮、ユニットオペレーションの概念を踏襲したものであり、フレームワークとしての形はユニットオペレーションの範疇に入っているものといえます。
ここで言うモデル化は、後でも触れますが、現象を数式表現するという意味だけのモデル化ではありません。人間の思考をモデル化するという意味です。何やら哲学めいてきましたが、技術に関わる問題を論理的に、マネジメントとしっかりと結びつく仕組みを考えたい、広く言うと社会科学と結びつけられるようなモデルまで考えられるのかと思っています。ちなみに、環境・安全の法規制や税金のモデルなども科学的な根拠や生活のモデルをベースにしてルールを作っている。これが正しいかというよりも論理的に承諾できるかということが重要です。ただし、全ての仮定が正しいと証明されなければ承諾できないというのも変な場合が往々にしてあります。これは、フィードバックが掛かるか、掛かってもどれぐらいの遅れがあるのか、に依存すると言えます。地球環境問題はまさしく、状況証拠をベースに対策を考えている典型的な例ですが、生態系の変異が気候変動の速さについていけないことは明らかですし、資源枯渇は一方の側面として厳然たる事実でしょう。従って、結論が出るまでに相当の時間が掛かるでしょうし、分かったときには幾つもの地域がダメージを受けていることでしょう。

３． エンジニアリングの流れ本論に戻って、製造システムの問題を考えてみることにします。ここで考える製造システムは化学プラントが主なものです。基本的な考え方は、プロセス システム エンジニアリングの基本をなすものであり、他の製造システムにも応用が可能です。
３－１ ライフサイクルエンジニアリング
化学製品は極めて多岐に利用されており、物質の流れ全体を鳥瞰してエンジニアリングを組み立てるのは極めて困難といえます。物質が流れなければ、リサイクル問題や安全問題は起こりません。流れている物質があるからこそ様々なエンジニアリング問題が発生するといえます。しかし、それらをベースに物事を考えるのであれば、天文学的な数の問題を考えなくては行けません。これは不可能です。そこで、敢えてエンジニアリングの流れに沿って、いわゆる「物作りの立場」からどのような問題を予め考えておくべきかを見てみると、エンジニアリングの対象を次のように分類することができるでしょう。
① プロダクトライフサイクルエンジニアリング（Product-LCE）② プロセスライフサイクルエンジニアリング（Process-LCE）③ プラントライフサイクルエンジニアリング（Plant-LCE）の３つのライフサイクルエンジニアリング（LCE）があります。何故 LCE かというと、一度製品やプラントを作れば全て終わりというわけではなく、市場や環境・安全など社会的な要求に答えるために、操業開始しても製品の追加を行ったり、プロセスやプラント等に様々な変更がなされていくからです。最近では、地球環境問題からも変更が加えられるようになってきました。Product-LCE は、原料から製品が作られた後、市場に流れ、使用され、その後に最終処分されるまでに起きるエンジニアリング問題を考えるものです。この間に、如何に環境や資源利用への影響を減らすか、とか利用者の安全性を確保するのかが重要になっています。Process-LCE は製品を作り出す「変換過程」に関わる LCE です。エンジニアリング観点から見ると、競争力のある反応経路を選択することから始まります。原料から製品に至る反応経路は、多くの場合複数あります。目的の物質を生み出す反応を中心に選ぶことになりますが、副反応の作用が活用できるかとか、関連特許問題がないかどうかなどを検討しながら、荒っぽいコストで選別していくことになります。最近では、地球環境問題（持続的発展問題）や製造の安全問題も、この段階で検討されています。
Plant-LCE は Process-LCE と密接に関係しながら、プラントを具現化して、運用していくエンジニアリングです。このエンジニアリングには、更に２つに分けて、プロセスエンジニアリングとプラントエンジニアリングとに分けて考えることになります。
前者が後者の要求仕様を決めるという流れなので、ここでは、主に後者を取り上げて議論していくことにします。つまり、プロセスエンジニアリングは、目的の製品を作り出すために、「化学プロセスを設計して、建設し、そして運用する」ためのエンジニアリングと言われています。プラントエンジニアリングは、プラントを構成する個々の装置を詳細に決めていくエンジニアリングといえます。

ここで LCE を解説しようと思っていません。それぞれの LCE におけるエンジニアリングの思考過程が極めて似ているのではないかと考えて、その類似性を見る試みをしてみたいのです。このような仮定は、極めて大胆、かつ、無謀な試みかもしれません。
「そんな試みは意味がない」と言われるかもしれません。しかし、仮に思考過程が一定とすると、情報基盤が統一的な思想で構築できる可能性があるからです。勿論、それぞれ違った目的を持った LCE ですから、部分的にしろ異なったエンジニアリングタスクがあることは、百も承知です。でも、基本形にその業務を支援する仕組みを用意すればいいことではないでしょうか。人間の思考、ここではエンジニアリング流れ

を整理しておくと、共有すべき情報や新たな知見の意味、その活用が評価できるかもしれません。社会要求が複雑になればなるほど、この種の整理は次第に重要な意味を持ちはじめると考えているからです。つまり、製造業において、作るべき製品仕様が決まったとして、如何に作り込むかは、Process-LCE や Plant-LCE に関係するはずです
し、地球環境を考慮した製品仕様を決めるためには、製品の最終処分に至るまでの流れを予測して、その流れの中にある他業種の変換技術（その業においては製造技術ですが）との兼ね合いで、また、利用中の条件等を考慮して決めていくことが必要となるでしょう。
３－２ プラントライフサイクルエンジニアリング
プラントライフサイクルエンジニアリングは、製品の仕様が決まり、製品を作るプロセスがある程度見えたところから始まります。プロセスエンジニアリングは、ProcessLCE で選ばれた変換工程の繋がりを基にして、プロセス化学やプラント要求仕様を守りながら、工程の繋がりを実現化するために、必要な各工程の機能を詳細化し、そのときに出てくる制約を明確にしていくものです。つまり、プロセス設計は、概念設計基本設計詳細設計へと流れることになります。ここで設計手順を解説するつもりはありませんが、言いたいことは、基本設計以降の設計の作業では、様々な操作を想定しながら設計を行っていることです。定常操作は勿論のこと、スタートアップやシャットダウンの操作、緊急時の操作、メンテナンスやサンプリングなどの間欠的な操作など、様々な運転モードや作業を設定しながら、それらの操作が可能なように装置に組み込んでいくことになります。バッチプロセス設計でも基本的には同じであるといえます。このときに想定された操作群は、一般に SOP（運転標準書）にまとめられることになります。この正常時運転に関わる操作、制御システムに組み込まれた手順、それらが作用するプラント要素が関係している筈ですが、必ずしも対応関係がよく見えないことも多い。特に、非定常操作になるともっと分からない状況が良くあります。つまり、オペレータにとって、操作や監視に対する要求の出所がもっと分かり難くなっており、何故なのかが理解しにくくなっています。オペレータにも上手、下手があるようですが、その違いは操作の意味を理解できるとか、操作によりプラントの状態がどのように変わるのかが予測できる能力に依存するといわれています。緊
急時操作すべきという判断やそれに対応する操作に顕著に出てくるといわれています。

４． 統合技術の重要性
LCE に内在する人間の様々な思考を何らかの方法で助けようとするならば、その思考の流れ（思考過程）をある程度知っておく必要があるでしょう。芸術と違ってエンジニアリングにおける思考過程はある程度一定しているだろうと推測できます。思考過程には、「定石」といえる流れと部分的ではありますが進歩的な流れとがあります。
一般的にいえば、製造に関わるエンジニアリングでは、前者の方が圧倒的に多いと考えられます。
「思考過程がある程度整理できる」という可能性は、エンジニアリングの支援環境に深い意味を持つことになります。この定石を標準（Reference）と考えると、社会や市場からの様々な要求は「必要条件」として捉えて、その中で「製造システムを計画する」ことは、「可能性のある製造システムの候補群を見つける」、「実現性を勘案して選別する」の繰り返しが思考過程を形成しており、選別するための評価は、環境・安全性やコストは定番ですが、それらに企業の方針が加わります。したがって、評価ですら普遍的な定義があるわけでなく、ある程度の試行錯誤はやむを得ないことになります。定番の評価項目を見てみても、1960 年頃は、固定費、変動費が中心であり、1970 年に入って局所的な環境評価が加わり、その後、エネルギーコストや安全性、操作性が加わりました。2000 年に入って環境影響（CO2 排出量）などが更に加わりましたが、これらの評価項目は今や共通となっています。更に、環境会計のようなものも取り込まれようとしています。少なくとも、評価に関わる項目群が技術情報基盤で推定できないと問題でしょう。

５． 情報技術はライフサイクルエンジニアリングの要「評価する」ためには、各評価項目に対する評価の論理的な手続きが重要になります。
「どんぶり勘定」では個人差が出てきますし、勘違いもあるかもしれません。これを避けるためには、評価手順を論理的に整備して、「必要な情報」「処理操作」「評価指標」の流れを作る必要があります。これもモデルの１つです。１つの評価が複数の要素からなる場合にはサブの評価を設定して、それらを集約して全体の評価が可能になることもあります。安全性評価などはまさしくこのケースといえます。
「必要な情報（プラント構造、物質、操作条件など）」「サブ項目について、「処理手順」の繰り返し（ズレの設定、ズレの伝播、リスク評価）」「評価指標（各リスク評価の総合評価）」を行うのが安全性評価です。もう「評価する」ということは選ぶということに繋がりますが、多くの場合、次の改良と繋がっていなくてはなりません。一つ重要なことは、評価改良へと流れる仕組みが見える形を保つことが、分かりやすい評価、改良に繋がることです。
既に述べたように、プラント設備に関わる様々な機能は、「プラント構造情報」、「プロセス挙動情報」、「マネジメント・制御情報」の３つから表現できると考えています。
プラント構造は、PFD や P&ID のように２次元でプラントトポロジーを表現するもの、アイソメ図のように立体的に表現されるもの、構成機器の詳細を表しているものなど様々な形を取っています。操作手順を考えるときには、ライン設定といわれる枝管とメイン配管との間にあるバルブの開閉状態を管理しなくてはなりません。手順は、マネジメント・制御情報に属するとしても、バルブの開閉状態はプラント構造情報の情報といえるでしょう。プロセス挙動情報もまた様々な種類の情報から構成されています。純粋物質や混合物質の物性、それらの熱力学特性、反応メカニズム、異常反応、・・・など様々です。これに加えて、ユニット内のプロセス挙動モデルがあり、しかも、定常／非定常、集中系／分布系など様々な表現形式があります。例えば、配管の挙動モデルも遅れを考慮するときもあれば、そうでないときもある。
「マネジメント・制御情報」は、唯一、人間系の判断・命令を伝える情報です。これとて、マクロな視点もあれば、ミクロな視点もあるのです。
「生産設備を設計する」というとき、経営の意図から、製品品質や生産量を与えて、どのようなプロセス挙動を期待するかを基本にしながらプロセス設計を行います。運転では、与えられた生産設備を使いながら、「製造指示」と「操作手順」という「マネジメント・制御情報」が与えられますから、それに従って「プラント構造情報」のバルブやポンプなどを起動することになります。この操作により、プロセスの「挙動情報」が所定のプラント構成要素で発現されることになります。所定の原料が用意されており、かつ、手順が論理的に正しければ、期待する挙動が発現するし、そうでなければ予期しない挙動が発現することになります。
品質問題では、もっと込み入ってきます。特に、精密化学製品の製造では、集中系で取り扱える構造体と分布系で取り扱うべき構造体の２つの見方が出てきます。後者の見方でプラント全系を取り扱うことは不可能ではありませんが、あまりにも非効率な場合も多いので、通常はそのような処理をしません。人間の感覚は、分布系と集中系が入り交じった見方でプラントを見ていることも多いのです。つまり、反応器のような変換プロセスの核となるユニットは詳しく分布系のイメージで、配管など他の単純な変換を伴うユニットは集中系として単純なモデルを頭の中で想定しています。このように混合したモデルを同時に取り扱えるシミュレータは殆どありません。人間の感覚や見方を素直に、愚直といった方がいいかもしれませんが、表現する方法がこれから必要になってくると思います。
設計で使ったモデルを運用時に使うことも、本格的に始まっています。これは、設計時に適当に仮定したプロセスパラメータを実体に合うように修正しながら、プラントのパフォーマンスを最適にしようとする意図がそこにあります。さらに、プロセスパラメータの変化を見ながら、メンテナンスを適切に行うような仕組みも組み込まれています。
このようにプロセスの設計から運転・保全に至るあらゆるところで、部分的にしろ様々なモデルを共有しながら生産活動を行うようになってきています。しかし、モデル構築やモデル切り替えの方法論は未だ不十分であり、経験に頼っているところがたくさんあります。たくさんのモデルがあっても、定石としてそれらの使い方にはおおよその使い方があるのです。そこからはみ出るのは、利用者の意図がハッキリしているということもできるので、その意図をくみ上げる仕組みを用意しておけばいいことなのです。言い換えれば、モデル化はモデルを準備する前から始まっており、そこにはシナリオがあるはずです。それらのシナリオはエンジニアリングのアクティビティモデルの中に登場してくるものです。どのようなシナリオが登場するかは、このエンジニアリングアクティビティモデルのどのタスクの関わるものかによって違ってきます。シナリオが決まれば、必要なモデルは、相当限定されることになります。
例えば、概念設計から基本設計の前半であれば、「プロセスの理想状態をモデル化する」というシナリオが主流であり、プロセス状態（FTPCL）をベースに「パフォーマンスを達成するために、プラント内で実現すべきプロセス状態」を定義するシナリオでしょう。
これを過ぎると、「状態変化のズレをモデル化する」という段階に入ります。
「ズレ」を考えたモデルは、プロセスパラメータや計測値等の不確定性を考慮した制御系やそれらを修正するメカニズムの整備問題に利用されます。もっと大きな「ズレ」は、HAZOP 等の安全性評価に利用されます。
言いたいことは、数式を作るのはモデル化の一部であり、シナリオがモデルの枠組みを決めているということです。
今までの化学工学におけるモデル化のターゲットは、プロセスの挙動モデルが大半ですが、エンジニアリングの流れから見ると、プラント構造体やマネジメント・制御の情報をハッキリと区別してモデル化を進める方が遙かに情報の変更管理は楽になるし、利用可能性は広がるのです。この思想を基にして開発してきたのが、MDOOM/MDF［2］であり、欧米で高い評価を受けています。

６． 技術情報基盤の必要性
エンジニアリング アクティビティ モデル（エンジニアリングの流れ）が整備されてくると、［マネジメント要求エンジニアリングタスク情報モデルシミュレーション＆最適化技術の選択・決定マネジメントとの整合性チェック］という一連の流れを支援できる仕組みが見えてきます。これが、技術情報基盤とよんでいるものです。詳細は［1］に譲るとして、簡単に説明しましょう。

Level 5: 戦略情報基盤(Advanced Management)

利用者の個別環境

Level 4: 定型管理技術基盤(Management Module)
Level 3: 定型技術基盤(Engineering Module)

共通環境

Level 2: シミュレーション基盤（技術情報基盤）

Level 1: 知識データベース
ファクトデータベース

図 技術情報基盤のイメージ
レベル１には、既にお話しした情報モデルやファクトデータベースが整理されて入ることになります。定番の熱力学特性のデータベースは従来の通りですが、ユニット系のデータベースは独立した情報として価値を持つようにも、シミュレーションのモデルに利用できるようにもできます。
従来の作業は、パッケージソフトを担当者が使いやすいように大なり小なり工夫して使っていましたが、担当者が変わると誰もメンテナンスできないので、それまでの努力は没になり、次の人がまた１から整備し始めることが多く見受けられました。酷いときには、パッケージソフトそのものが違うものに取り替えられてしまうこともしばしばありました。今やプロセスシミュレーションのパッケージソフトが違っていても、モデルを交換できる仕組みも開発されています。これらを使えば、開発段階で作られたモデルが、設計や運転段階で容易に使えるようになります。どんなにコストセービングになることか。このときに、モデルの性質を論理的に整備しておくメタモデルの仕組みを持っていれば、もっと活用できることになります。
オペレーションの記述も同様に考えることができます。バッチプロセスの操作は連続プロセスの操作と類似性が高いと言いながら、操作の表現が一般化されていませんでした。欧州で生まれて米国で纏められた ISA S88［3］は、バッチ操作の表現を標準化しようとするものです。しかし、操作とプラント構造の対応が見えるようになっていません。この問題を解決しようとしているのが、CGU（Control Group Unit）の概念です［4］。元々、この考え方は、連続プラントのスタートアップ操作を表現するためのものでしたが、10 年を経て、バッチプロセスへの展開が可能になってきました［5］。
この概念を利用すると、操作の形がプラント構造とプロセス化学と対応付けるようになるので、バルブやポンプの起動のタイミング等の開始と終点を定義づけるという意
味から、「操作の枠組み」が論理的に導き出され、その枠の中で詳細な操作を定義することができるようになります。緊急時の操作の定義も同様に表現可能になります。つまり、操作が論理的に導き出せると言うことニなり、経験への依存性は極端に減ることになります。経験に依存するのは最終調整ノブ分になるので、もし詳細な挙動モデルが準備されるならば、実験的に確認しながら操作パターンを決めていく手順が整備できることになります。

７． 「統合学」が期待するところ2006 年 9 月に「統合学入門」を化学工学会 SIS 部会統合化工学分科会で出版しました。この本の目的は、製造システムなどをそのライフサイクルを通じて起こる問題を様々な次元から検討しながら解決していくための仕組みを支援する情報基盤の構築と運用について解説し、広く理解を得ることでした。
それでは、何故、統合学を化学工学から提案できるのでしょうか[6]？説明してきたように、化学工学の根幹であるユニットオペレーションの概念は、今では当たり前の言葉になった「モジュール」の概念を含んでいます。モジュール化の考えは、以外と他分野にない概念であって、あったとしてもあまりにも理念的で定義が曖昧な場合が多かったように思います。どうも日本では、化学工学の歴史が浅いために、モジュール化の概念が発展的に活用できるようなシステムアプローチが、十分に社会に浸透していかなかったのではないと思えるぐらいです。さらに、化学技術に関わる実業の世界で、化学・物理化学的な情報、プラント等の機械的情報、装置材料や腐食情報、制御情報など有りとあらゆる情報を利用しているのも珍しく、ましてやライフサイクルエンジニアリング（LCE）に関わる問題は、重要であると分かっていても攻めあぐねていたように思います。最も複雑な情報を縦横無尽に使わざるを得ない分野といえるでしょう。ましてや他産業ではそのような状況は未ださほど顕著にはなっていないのかもしれません。逆に、この複雑な仕組みで動いている分野で、情報を獲得し、活用し、LCE 全体を旨く運営していく仕組みができれば、その仕組みは他分野でもっと活用できる可能性を持っているといえます。
統合化を進める技術的なキーワードは、① 異質と思えるような「多次元情報モデル」構築② ライフサイクルエンジニアリングための「情報共有」③ アクティビティに沿った PDCA サイクル支援しながらの「的確な判断」でしょう。米国 NIII（National Industrial Information Infrastructure）は、1990 年に入って、異なる産業間での情報を共有して活性化を図る仕組みを作る目的で、2、3 のプロジェクトを始めました。それらの基幹プロジェクトとして、基盤構築の問題（NIIIP: National
Industrial Information Infrastructure Protocol）［7］を取り上げたものがありましたが、まさしくそのターゲットがここで言う技術情報基盤ではないかと思っています。そのプロジェクトがその後どうなったか定かではありませんが、世界を見れば同じような問題意識を持つグループが居るようです。EU においても、ESPRIT を中心にして同じような動きが幾つも見られます。最近になって、統合学と同じような概念として、MSI（Manufacturing Science Informatics）として分野を形成しようという動きが出ています。
統合学の期待するところは、技術的な論理を取り込んだ仕組みが、少なくとも製造業だけでなく、リサイクル問題と関係する社会技術システムにも入っていくことです。
今、現存する法規制も、それらができた当時の状況と変わっしまっているのに未だにあちらこちらに残っているようです。これでは次の世代が疲弊してしまったり、新しいアイディアを育てる環境ができないでしょう。
一旦決めれば破綻するまで守り通す、無作為が続いている状況といえます。技術との関わりが深い法規制の仕組みでも問題が山積みになっています。例えば、安全管理に置いても、石化プラントや石油精製プラントは監督官庁が３省庁にまたがっており、しかも管理の多くが、安全管理全体の仕組みを見るよりも、詳細な設備の管理保全を詳細にチェックする方法をとっているために、いまだに自主管理の考え方や仕組み作りがしにくくなったままです。それらへの提出文書だけでも、１プラント１億円の経費がかかると言われています。管理技術の発展を妨げるだけでなく、余分な費用を法規制の対応に費やすならば、もっと世界標準になるような技術を作ることも可能であると思います。

８． おわりに「統合する」ことの重要性について話を進めてきました。少しでも、オープンな技術論を広範囲に議論しながら社会のためになる仕組みを提案しようとするのが、統合学の原点にある思想です。何回もでてきましたが、統合化の重要なところは、対象のライフサイクルに生じるエンジニアリング問題を戦略的に処理する仕組みを分かっている範囲でできる限り体系化しておいて、計画、運用、改良を繰り返し行う仕組み（技術情報基盤）を用意することです。将来新しい技術ができてくれば、それを導入すればどれほどのメリットがあるかを評価しながら活用すればいいことになります。
「当たり前のことを当たり前にする」ことが基本です。日本でもこのような行動が評価できるようになることを願っています。

参考文献
1) 仲 勇治編著、「統合学入門」、工業調査会、東京(2006)
2) Naka, Y., R. Batres and T. Fuchino,「Operational Design and its Benefits in Real-Time Use」、
AIChE Symposium Series No. 320, Proceedings of the Third International Conference onFoundations of Computer-Aided Process Operations, ISBN 0-8169-0776-5、pp.
397-403(1998)
3) ANSI/ISA-S88.01-1995 Batch Control Part 1: Models and Terminology.
4) Naka, Y., R. Batres, and T. Fuchino, 1998, Operational Design and its Benefits in Real-Time
Use, AIChE Symposium Series No. 320, Proceedings of the Third International Conference
on Foundations of Computer-Aided Process Operations, ISBN 0-8169-0776-5, pp. 397-403.
5) 青山 敦、仲 勇治、ラファエル バトレス、「バッチプロセス操作管理のための技術情報基盤」、化学工学論文集、Vol.29(1)、39-46(2003)
6) 仲勇治、「技術情報基盤構築へ向けて」、化学工学、178-181(1998)
7) National Industrial Information Infrastructure Protocols Consortium, ‘Introduction to NIIIP
Concepts’, (1998)