ビジネス取引のステートマシンの構築
―CPN モデルを用いて
堀 内 恵
＊＊清 水 智
＊＊1 ．はじめに
2 ．カタログ販売におけるビジネス取引のステートマシン
3 ．カタログ販売における新たな
CPN
モデルによるステートマシン 4 ．考 察5 ．むすびにかえて
1 ．はじめに
これまでの企業は，特定の主宰企業の価値基準や収益基準のもとに，供給・製造業者，顧客等で 構成される
Value Network
（VN）に参加し，自らの維持発展を模索してきた．近年のVN
間競争 の活発化や新規ビジネス展開の多様化に伴い，自らの価値・収益基準のもとで企業規模，国内外，業種を問わずビジネス機会に照らして俊敏かつ状況適応的な新たな
VN
の構築および主体的参加 を可能にすることが求められている．状況適応型
VN
では，構成員は常に特定のメンバーに固定されるものではなく適宜変化可能で なければならない．そのためには，業種，規模，企業グループの枠を超え，いつでも，誰でも，何 処からでも利用可能な予め定義された標準的取引モデルの利用が不可欠である．さらに国際的に受 容可能なデジュール標準とすることによって，新たな取引相手と取引を開始するたびに取引内容を「 1 対 1 」かつ「ゼロベース」で調整・決定する必要がなくなる．
このような観点からビジネス取引の概念を規定した標準規格に
ISO/IEC15944―4
（2007）1）があ る．この規格は，ビジネス取引にかかわる標準的な語彙（ビジネス事象，コミットメント，コラボ1 ） ISO/IEC15944―4（2007）は，「情報技術 -BOV-Part4：ビジネス取引のシナリオ―会計と経済のオン トロジー」というタイトルの標準規格である．この規格の目的は，1997年に制定された
ISO/IEC14662
（1997）のタイトル「Open-ediReferenceModel（JISX7001（1999））」や
ISO/IEC15944―1（2002）の
タイトル「情報技術 -BOV-Part1：実装に向けてのOpen-edi
の運用側面」の中で説明されるビジネス 取引の概念規定をREAontology（Geerts&McCarthy,2002）に基づいて行うことである（p.v）．
レーションスペース，取引シナリオ等）を，VNにおける様々な組織間において “人間” および “機 械” の間で誤解なくかつ共有できるレベルの仕様として規定するものであり，その中で “ビジネス 取引のステートマシン（Businesstransactionstatemachine）” について取り上げられている．この ビジネス取引のステートマシンの構築研究として
Horiuchi and McCarthy
（2011）や堀内・清水（2016）は，それまで概念的にその意義が示されるだけであったこのステートマシンを，特定の情 報環境に依存しない
PIM
（PlatformIndependentModel）として構築および評価する．すなわち，この
ISO/IEC
の中で取り上げられているカタログ販売を対象として，ビジネス取引のステートマ シンをJava
プログラミングで構築したり，カラード・ペトリ・ネット（CPN:Colored Petri
Nets）
2）と呼ばれるプロセスモデルを構築したりしている．これらの既存研究では，ISO/IEC15944―4（2007）で取り上げるカタログ販売を対象として，売 手と買手にとって想定外の事態が生じることがない厳格に定義されたビジネス取引のステートマシ ンを人間と機械が理解できるレベルで成功裏に完了するプロトタイプを構築しつつその意義を議論 している．しかしながら，その構築対象は，取引開始から完了に至る 5 つの取引局面（計画・認 識・交渉・実現・事後実現）の中の一部の局面（計画と認識）に限定したり，ビジネス事象は事前定 義された順序に従って線形的に発生することを前提としたりしている．加えて，交渉局面における 買手と売手との間の交渉内容（出荷数量，支払条件，配送条件）を踏まえて双方が満足するまで繰 り返すことができる交渉を考察していない．そのために，既存研究では，様々に展開可能な取引展 開の 1 つの展開を人間と機械が理解できるレベルで具体化しているに過ぎないという問題を抱えて いる．
本稿では，このような問題を克服すべく
ISO/IEC15944―4
（2007）で取り上げるカタログ販売 を対象とするビジネス取引の計画から実現局面までの 4 局面を対象として，特に交渉局面における 買手と売手の交渉を，このISO/IEC
が提示している線形的なプロセスを超えて，各当事者にとっ て満足が得られるまで反復的に取引条件を交渉できるCPN
モデルをデザイン・サイエンス（Hevner&Chatterjee,2010）のデザイン・サイクルに従い構築，評価する．
2 ） ペトリ・ネット（PetriNet）は，1962年に
CarlAdamPetri
が考案したプロセスモデルであり，ビジ ネスプロセスをはじめとする，様々なシステムの振る舞いを記述したり，その状態を変化させる方法を 規定したりするモデルである（Aalst&Stahl,2011）．しかしながら，ペトリ・ネットは，ビジネス・プ ロセスを記述するために必要となるデータと時間という要素を扱えないために，大規模で複雑なプロセ スの記述ができないという限界を抱えている．この限界を克服するために，カラー（acolor）と呼ばれ るデータ（ないし値）と時間という要素を扱えるように拡張されるペトリ・ネットがCPN
である．2 ．カタログ販売におけるビジネス取引のステートマシン
2 ― 1 ISO におけるビジネス取引のステートマシンの基本的理解
ビジネス取引のステートマシンとは何かについては，ISO/IEC15944―4（2007）の第 6 章「OeB-
TO
の手続き的構成要素―ビジネス取引のステートマシン」の中で，宣言的構成要素，手続き的構 成要素，制約的構成要素から構成されることが説明される．ただし，その説明の中では引用可能な 簡潔な定義は見つからない．ステートマシンを構成する 3 つの構成要素の関係については，この
ISO
の中で次のように説明 されている．すなわち，手続き的構成要素は，「結論（補：取引完了を意味していると想定される）を導く中でそのデータ（補：そのデータはビジネス取引において当事者間で交換されるコラボレーショ ンデータ，つまり取引を規定する宣言的な構成要素に関するデータ）がどのように利用されるのかを 規定する」（p.25）と説明される．この説明から，手続き的構成要素における手続きの対象とは，
宣言的な構成要素であることがわかる．加えて，「制約的な構成要素は，データ（補：宣言的な構成 要素）と手続き（補：手続き的構成要素）の両方に対するビジネスルールを規定する」とされるこ とから，制約的な構成要素は宣言的な構成要素と手続き的構成要素を規定する要素であることがわ かる．以上より，手続き的構成要素としてのビジネス取引のステートマシンは， 3 つの構成要素が 整合的に関連付けられて構成および規定される仕組みであることがわかる．
一方，ビジネス取引は，「情報交換とコミットメント交換の両方を必要とし，……情報交換はさ まざまな経済現象を表象するビジネス取引実体（補：宣言的な構成要素）の状態遷移を管理するビ ジネス事象を介して捕捉される」（p. ⅵ）こと，およびビジネス事象が「ビジネス取引を通じて
（補：取引完了に至る）その進展を伝達するために取引当事者が用いる活動やメッセージである」
（p.27）と説明される．
以上より，ビジネス取引のステートマシンは， 3 つの構成要素から成り立つという構成的な観点 からの説明とは異なり，「情報交換」および「ビジネス事象」を踏まえて説明する場合には，“ビジ ネス事象の発生を介して” 取引完了に至るその取引の進展（ビジネス取引実体の状態遷移）を取引 当事者へ伝えるという機能面から説明できる．本稿では，このようなステートマシンの機能面に着 目しつつ，ビジネス取引のステートマシンを次のように定義する．すなわち，「ビジネス取引のス テートマシンは，ビジネス取引として宣言されるビジネス取引実体（宣言的・制約的な構成要素）
の状態が，取引完了に至る一連のビジネス事象（手続き的・制約的な構成要素）の発生を介してど のように遷移するかを取引当事者に伝える仕組みである」と定義する．
2 ― 2 ビジネス取引のステートマシン構築の既存研究
Horiuchi&McCarthy
（2011）や堀内・清水（2016）では，ビジネス取引を完了するために必要 となるビジネス事象を事前定義しつつ，その事象に従って取引が展開される際に，ビジネス取引の 開始から現在の状態に至る経過と現在の状態，および現在の状態から取引完了に向けての進展情報 を取引の当事者に伝達できる機能を「ビジネス取引のGPS
（GlobalPositioningSystem）
機能」と 呼びつつ，そのステートマシンの意義を評価する．そして，特定の情報環境に依存しないPIM
（PlatformIndependentModel）として，この
ISO/IEC
の中で取り上げられているカタログ販売を 対象とするビジネス取引のステートマシンの構築を行っている．すなわち，Horiuchi&McCarthy（2011）では，Javaプログラミング環境で稼働するプロトタ イプを構築している．一方，堀内・清水（2016）では，厳格なプロセスモデルである
CPN
を用い てビジネス取引の計画および認識局面までのステートマシンのモデルを構築しつつ，取引完了まで に必要となるビジネス事象の網羅性や取引完了までの到達可能性を検討している．加えて，堀内・清水・安積（2016）では，このステートマシンをブロックチェーンなどの分散環境下における取引 の安全性を高めることの意義や可能性について議論している．さらに，既存の構築研究には取引の 依頼者と実行者の間で行われる行為（通常の取引の展開（ハッピーパス）に加えて，必要に応じて 例外的な行為（要求，約束，宣言，受理の取り消し）が起こる可能性を明示的に捉える
Dietz
（2006）の
DEMO
（DesignandEngineeringMethodologyforOrganizations）のモデル化の方法論に基づく ビジネス取引のステートマシンの構築研究（Hunka&Zacek,2015）がある．しかしながら，既存研究には次のような問題がある．Horiuchi&McCarthy（2011）は，カタロ グ販売の取引の完了に必要となるビジネス事象が12個であるという前提に基づいて，ビジネス取引 の宣言的な構成要素と手続き的構成要素との静的な関係（PIM）の考察にとどまっている．そのた めに，取引完了に至るビジネス事象の発生順序，発生条件や，さらには想定外のビジネス事象が発 生する可能性は考察していないという問題がある．この問題に対して，堀内・清水（2016）は
CPN
モデルを用いてビジネス事象の網羅性やその発生条件等を考察しているとはいえ，その考察 はビジネス取引の計画と認識局面に限定したものであるという問題がある．一方，Hunka &Zacek
（2015）は，DEMOのモデル化方法論に基づき例外的に発生し得るビジネス事象の発生可 能性（調整的行為の側面）について考察するものの，その考察はビジネス取引の一部の局面に限定 したものであるという問題がある．3 ．カタログ販売における新たな CPN モデルによるステートマシン 3 ― 1 構築の目的と前提
本稿は，上記の既存研究の問題の中で指摘したビジネス取引の計画と認識局面を対象に限定的な
モデルしか提示できていない既存研究（堀内・清水，2016）の問題への対処を考察の対象とする．
すなわち，カタログ販売のビジネス取引の 4 局面（計画，認識，交渉，実現）を対象にし，かつ交 渉局面において買手と売手の取引条件の提案と承認の過程で，相手の取引条件を承認することがで きるまで繰り返すことができる（人間と機械が理解できる厳格な仕様レベルの）モデルとして
CPN
によるステートマシンのモデルを構築する．なお，Hunka&Zacek（2015）の問題については別 の機会に譲りたい．一般に
CPN
のモデルを構築するためには，プレース，トランジション，アーク，トークン，アーク・インスクリプション，ガードなどの要素を定義する必要がある（Aalst&Stahl,2011）．宣 言構成要素はプレースおよびトークン3）として，手続き的構成要素はトランジションとして，制約 的構成要素はアーク，アーク・インスクリプション，ガードなどによって定義できることから，
CPN
を用いるステートマシンのモデルでは，ビジネス取引が完了するまでの時間的な経過の中 で，ビジネス取引を構成する 3 要素である宣言的構成要素，手続き的構成要素，制約的構成要素を 同一モデルとして定義できる（堀内・清水，2016）．ただし，CPNを用いてモデルを構築する場合，同一モデルの中で 3 つの構成要素を同時に定義 できるとしても，モデルの構築にあたっては何らかの前提がないとその構築はできない．以下で は，ビジネス取引のステートマシンの構成要素となる宣言的構成要素，手続き的構成要素，制約的 構成要素をいかに
CPN
モデルの要素として定義するのかにおける本稿の前提（構築指針）を示 す．なお，この前提の説明においてはCPN
を理解するために必要となる事項の説明を適宜行う．第 1 に，モデル化の対象はカタログ販売の事例における取引局面の 4 局面（計画，認識，交渉，
実現）である．
第 2 に，宣言的な構成要素は，ビジネス取引実体を表す
REA
オントロジーの 9 つのクラス「Re-source」，「Resource Type」，「Economic Event」，「Economic Event Type」，「Business Process Phase」，「Agent」，「Agent Type」，「Commitment」，「Claim」を対象とする．これらのクラス
は，堀内・清水（2016）の632頁に示されるクラス図とCPN
との関係図に基づいて，CPNモデル の要素であるプレースとしてそれぞれ定義する．ただし，クラス図として定義されるクラス間の関 係（親子関係，継承関係など）は，CPNモデルではプレース間の関係としては直接的には定義でき ない．したがって，本稿では， 2 つのクラス間の親子関係をCPN
モデルの中で定義する場合， 2 つのクラスを統合したものを 1 つのプレースとして定義する．例えば，親子関係があるクラス「Resource
Type」とその状態に関するクラス「Resource Type State」は，CPN
モデルの中では 1 つのプレース「GTS」として定義する．以下に，本稿での宣言的構成要素であるクラスとCPN
モデルの要素となるプレースとの対応表を示す．3 ） トークンは，プレースを遷移するオブジェクトである．
なお，表 1 のプレースの欄のカッコの中は，省略されたプレースの正式名称である．例えば，プ レース
GTS
は，GoodsTypeStateの略称でありカッコの中でその正式名称が示される．第 3 に，表 2 のとおり手続き的構成要素であるビジネス事象は
ISO/IEC15944―4
（2007）のカ タログ販売に基づく12個のビジネス事象を対象とする．それらはCPN
の要素であるトランジショ ンとして定義する4）．なお，この表のビジネス事象の例の欄にある（）内は，CPNの要素である表 1 宣言的構成要素としてのクラスと
CPN
モデルのプレースの対応クラス 状態クラス プレース（プレースの正式名）
Resource ResourceState GS（GoodState）
ResourceType ResourceTypeState GTS（GoodsTypeState）
CashTS（CashTypeState）
EconomicEvent EconomicEventState EEDS（EconomicEventDeliveryState）
EEPS（EconomicEventPaymentState）
BusinessProcessPhase BusinessProcessPhaseState BPPS（BusinessProcessPhaseState）
Agent AgentState B-AS（BuyerAgentState）
S-AS（SellerAgentState）
AgentType AgentTypeState P-Buyer（ProspectiveBuyer）
Commitment CommitmentState CommitDS（CommitmentDeliveryState）
CommitPS（CommitmentPaymentState）
Claim ClaimState ClaimS（ClaimState）
表 2 カタログ販売における取引局面とビジネス事象
取引局面 ビジネス事象の例
計画
①売手によるカタログ出版（publishCatalog）
②買手の売手に対するカタログ請求（sendCatalogRequest）
③売手の見込みのある買手に対するカタログ送付（sendCatalog）
認識
④買手の売手に対する入手可能性と価格の問合せ（sendAvailabilityandPriceRequest）
⑤売手の買手に対するその入手可能性と価格の問合せの回答（returnAvailabilityandPriceReq-
uest）
交渉
⑥買手の売手に対する申し込みの送付（sendOffer）
⑦売手の買手に対する修正申し込みの送付（sendCounterOffer）
⑧買手あるいは売手の申し込みの受入れ（acceptOffer）
実現
⑨売手の買手に対する商品の発送準備と事前出荷明細書の送付（sendAdvanceShippingNotice）
⑩買手の売手に対する点検済商品の受入れと受取報告書の送付（sendReceivingReport）
⑪売手の買手に対する出荷後の請求書の送付（sendInvoice）
⑫買手の売手に対する請求書の支払情報の送金通知書の送付（sendRemittanceAdvice）
出所：ISO/IEC15944―4,p.30
4 ） ISO/IEC15944―4（2007）の
p.30には，カタログ販売のビジネス取引の完了のために必要となる事象
トランジションの名称である．
第 4 に，トランジションの発火に伴う状態遷移の記録は， 1 つ以上のプレース上において各プ レースで定義される 1 つ以上のデータ項目（プレースの型であるカラー集合5））から構成されるデー タを持つトークンとして記録する．例えば，トランジション⑥
sendOffer
が発火する時，プレー スEEDS
のトークンは，状態のID，現在の状態名称，現在の取引局面の名称，売手，買手，商品
名，数量，配送手段，関連するトランジション発火時のタイムスタンプを記録する．なお，交渉局面における買手と売手の交渉内容は，出荷数量，配送手段，支払手段を対象とす る．買手と売手の取引条件の提案と承認の過程においては，相手の交渉内容を承認することができ るまで，双方の提案を履歴として記録する6）．すなわち，トランジション⑥
sendOffer
または⑦sendCounterOffer
の提案が，買手または売手のいずれかに受入れられるまで，相手の提案を棄却 した事実と自身が新たに提案した事実を履歴として参照できるようにトークンのデータ項目に記録 する．第 5 に，ビジネス取引を正常に完了させる新たなビジネス取引実体としてのクラスが必要になる 場合には，そのクラスをプレースとして追加定義する．
第 6 に，ビジネス取引を正常に完了させる新たなビジネス事象が必要になる場合には，その事象 をトランジションとして追加定義する．
第 7 に，制約的構成要素は，ビジネス取引を正常に完了するために必要となる宣言的構成要素と 手続き的構成要素の間を交互に繫ぐアーク，および宣言的構成要素と手続き的構成要素の中でビジ ネス事象の発生条件を示すアーク・インスクリプションやガードを定義する．なお，アークは入力 プレースからトランジションへ，およびそのトランジションから出力プレースへのトークンの流れ を特定するものである．アーク・インスクリプションは，そのアークで流れるトークンが持つデー タ内容を特定するものであり，トランジションの発火条件としても利用できる．ガードはトランジ ションが発火する条件式である7）．
として，14個のビジネス事象が例示されている．本稿では，そのうち「売手は買手に対して，注文書を 送る．」という事象は，カタログに注文書が添付されているものと想定して，このビジネス事象を除外す る．また，本稿は事後実現の局面である「買手は売手に対して，保証の嘆願を送る．」を対象としないの でこの事象を除外する．加えて，「買手は修正申し込みを受入れる（受入れない場合は，取引の一時停 止，または中止する可能性がある）．」は，（）内の受入れの中止や一時停止の事象は除外する．
5 ） カラー集合は，トークンが持つ 1 つ以上のデータ項目の内容を規定するものである．ただし，データ 項目には 1 つ以上の別のカラー集合が含まれる場合もある（Aalst&Stahl（2011,pp.171―174））．例え ば，商品プレースのカラー集合
GoodType
はCPNTools
を用いれば，次のように定義できる．colsetID＝int;colsetName＝string;colsetPrice＝real;colsetGoodType＝productID*Name*Price;
6 ） 本モデルでは， 1 回の取引において 1 種類の商品が売買されるケースを想定している．加えて，この 商品の特定は交渉局面の前段階となる認識局面において特定され，また商品の出荷可能数量は在庫切れ が起きないような状況を仮定している．
なお，現実世界においては買手と売手の交渉内容である商品の種類，出荷数量，配送手段，支払 手段の決定は，交渉をする前の段階においては特定できるものではない．すなわち，相手の案を受 入れるか，あるいは棄却して新たな案を提示するというように，取引の進展状況の中で新たに提案 をするつどその内容を決定しなければならない事項である．しかしながら，シミュレーションモデ ルにおいては，事前にモデルを定義しておかなければそのシミュレーションを実行・展開すること ができない．したがって，シミュレーション過程の進展状況を踏まえて交渉内容をそのつど選択で きるように，事前定義された交渉内容の候補の中から特定の項目を選ぶことができるようにするた めに乱数関数を用いる．
また，相手の案を棄却して新たな案を提示するトランジション，あるいはその案を受入れるトラ ンジションというような発火可能な複数トランジションがある状況においては
CPN
モデルの基本 的な特性（非決定性選択：non-deterministicchoice
8））に従えば，いずれのトランジションが発火 するのかを一意に特定することができない．本稿では，そのような場合にはCPN
のツールが提供 するトランジションの自動選択機能およびガードに定義するトランジションの発火条件を組み合わ せて，相手の案を受入れるのかあるいは自ら再提案するのかのトランジションが特定される．第 8 に，第 1 から第 7 に基づく
CPN
モデルの作成にはビジネス取引の進展に伴うプロセスの状 態変化や振る舞いを正確にかつ厳密に定義し，取引完了までの展開のシミュレーションや検証が可 能となるコンピュータで動作するCPN
のツール（CPNTools9））を使用する10）．以上の前提に基づいて，本稿ではカタログ販売の 4 つの取引局面の
CPN
モデルの構築を行う．以下，そのモデル化においては，（紙面の制限の都合もあり）特に交渉局面のモデル化に要点を絞 る．なお，カタログ販売の計画局面・認識局面の
CPN
モデル構築の説明については堀内・清水（2016）を参照されたい．
7 ） ガードの条件式の有無にかかわらず，ペトリ・ネットのトランジションの基本的な発火条件は，すべ ての入力プレースに 1 つ以上のトークンを持つことである．
8 ） Aalst&
Stahl（2011）, p.75.非決定性選択の状況とは，いくつかのトランジションが同時に発火可能
になる場合，どのトランジションが発火するのかを特定できない状況である．この状況においては，CPN
ツールの管理機能によってどのトランジションが発火するかが無作為に選択される．9 ） コンピュータで動作する
CPN
ツールは数多くのものがある．ドイツのハンブルク大学のHaustermann, M.,Wagner, T., Moldt, D. によって運営されている Web
サイト「PetriNetsWorld」の「Tools and Software」には数多くの CPN
ツールが紹介されている．その 1 つであるCPNTools
は，Aarhus大学 のKurt Jensen
によって開発されたCPN
のモデルをコンピュータ上で展開するアプリケーションであ り，関数型言語SML（StandardML）に基づいている（Aalst&Stahl,2011,ch
.6）．10） CPNの基本的な動作（処理の流れ）と
CPN Tools
用いたCPN
の表記については，堀内・清水（2016）pp.636―638を参照せよ．
3 ― 2 交 渉 局 面
3
―
2―
1 双方の合意が得られるまで繰り返される交渉ISO/IEC15944―4
（2007）で説明されているカタログ販売の事例は，具体的には表 2 に見られる ように，取引の開始から完了までの流れを取引の局面とその局面で必要となるビジネス事象の例と して説明されている．本節での考察対象は交渉局面であるが，交渉局面が開始するまでに，取引当 事者となる買手と売手が特定され，買手と売手の間で取引対象となる商品種類ごとの出荷可能数量 や価格の問い合わせなどの確認作業が完了する．これに続く交渉局面は，取引相手（買手あるいは 売手）のいずれかが提案した取引に関する一連の交渉内容（商品の出荷数量，配送手段，支払手段）について双方が合意に至る局面である11）．
買手と売手とが提案された交渉内容に満足し合意するまでの過程は，多様な展開が想定できる．
最もシンプルな展開は，買手が提案をし（⑥
sendOffer）
，売手がその提案を直ちに受入れる（⑧acceptOffer）
という線形的な展開である．ISO/IEC15944―4（2007）の中で説明される展開も，線 形的な展開を想定している．すなわち，買手の提案（⑥sendOffer）
に対して，売手が修正した提 案（⑦sendCounterOffer）
を行い，この修正提案を買手が満足して受入れる（⑧acceptOffer）
とい う展開である．既存研究のHoriuchi& McCarhty
（2011）は，このような線形的な展開を前提と する考察にとどまっている．一方で，本稿のモデルは，買手の提案を売手が直ちに受入れる線形的な展開に加えて，買手ある いは売手が 2 回以上の自らの提案を繰り返す中で，結果として相手の案を満足して受入れる（⑧
acceptOffer）
という展開にも対応できるモデルを構築する．すなわち，例えば，⑥→⑦→⑥→売手の受入れとなる⑧，あるいは⑥→⑦→⑥→⑦→買手の受入れとなる⑧の展開などにも対応できる モデルを構築する．
3
―
2―
2 ビジネス取引のステートマシンの展開のイメージ図本節では，取引相手の提案を直ちに受入れるという線形的な展開に加えて，取引相手の双方が満 足するまで交渉を繰り返すことができるビジネス取引のステートマシンを構築するにあたっては，
まずこのステートマシンを構成する要素（宣言，手続き，制約） 間の関係性を明確にする．図 1 は，これらの構成要素を用いつつ，交渉過程において買手あるいは売手による提案（⑥あるいは
⑦）を結果として相手側が満足して受入れる（⑧）までの過程を対象として，ビジネス事象の発生 を介して 1 つ以上の宣言的な構成要素の状態情報を，そのつど取引の当事者に伝えることができる 我々のビジネス取引のステートマシンの展開イメージ（交渉局面の一部）である．
11） ISO/IEC15944―4（2007）p.36に交渉局面はじめ各局面の概要が説明されている．注 6 ）で指摘した とおり，本稿でのモデルにおいては， 1 回の取引において 1 種類の商品が売買されるケースを想定して いる．
この図では， 1 つの交渉局面の展開過程が⑥→⑦→⑥→⑧の順序で展開すると想定している．現 時点では，買手が売手の提案を棄却して自ら再提案をして（⑥），それを売手が受入れるビジネス 事象⑧が発生する際に，⑧のビジネス事象の内部に，宣言的な構成要素の状態情報が現在の状態情
売手が満足する かどうか？
cascadeChange
cascadeChange
⑥sendOffer
EEDS
EEDS
1stEEDSproposed expired specified in-service complete
2ndEEDS
1stEEDS 2ndEEDS 3rdEEDS 取引の交渉局面
⑦sendCounterOffer
⑧acceptOffer
proposed expired specified in-service complete
proposed expired specified in-service complete
proposed expired specified in-service complete
EEPS
1stEEPS 2ndEEPSproposed expired specified in-service complete
proposed expired specified in-service complete proposed
expired specified in-service complete
EEDS 1stEEDS
proposed expired specified in-service complete
2ndEEDS 3rdEEDS proposed
expired specified in-service complete
proposed expired specified in-service complete
EEPS BPPS
1stBPPS 1stEEPS
proposed expired specified in-service complete
2ndEEPS 3rdEEPS proposed
expired specified in-service complete
proposed expired specified in-service complete
yes no
yes no
identification negotiation
⑥sendOffer
⑦counterOffer
⑧acceptOffer
1stBPPS
BPPS
･
･
･ ･
･
･ ･
･
･･･ ･ ･･･
･･･
･･･ ･･･
･･･
･････
･････
･････
･････
･････
･････
･････
･････
･････
identification negotiation
⑥sendOffer
⑦counterOffer
⑧acceptOffer 1stBPPS
BPPS
identification negotiation
⑥sendOffer
⑦counterOffer
⑧acceptOffer
EEPS 1stEEPS
proposed expired specified in-service complete
2ndEEPS 3rdEEPS proposed
expired specified in-service complete
proposed expired specified in-service complete 買手が満足する
かどうか？
図 1 ビジネス取引のステーマシンの展開イメージ
（⑥→⑦→⑥→⑧を経て売手が買手の提案を受入れるケース）
報として示されている．この展開を可能にする宣言的構成要素，手続き的構成要素，および制約的 構成要素（一部）の関係性を
CPN
モデルの構成要素（プレース，トークン，トランジション等）を 用いて説明する．すなわち，CPNモデルにおいては，交渉局面における手続き的構成要素となるビジネス事象
⑥～⑧がトランジションとなる．トランジション⑥～⑧のいずれかのトランジションが発火するこ とによって状態遷移する対象が宣言的な構成要素であるクラス
EEDS，EEPS
およびBPPS
がそ れぞれプレースとなる．制約的な構成要素は，発火可能なトランジションの中からいずれのトラン ジションが発火するかを特定する際の条件として定義する．図中では，プレース
EEDS，EEPS
およびBPPS
は，それぞれ各丸四角形で示されており，ま たその各丸四角形のプレースの中に 1 つ以上のトークンがそれぞれ四角形として示されている．例 えば，プレースEEDS
のトークンとして，トークン1stEEDSや2ndEEDS等が示され，その中で トークンの現在の状態となり得る状態候補名12）（［proposed］，［expired］，［specified］，［in-ser-vice］，［complete］）
が示されている．次に，手続き的構成要素として 3 つのトランジション（⑥sendOffer，⑦ sendCounterOffer，⑧ acceptOffer）
は，長方形として示されている．各トランジ ションが発火すると，その発火に伴う宣言的構成要素の現在の状態は，そのトランジションの中に 配置された 1 つ以上のプレースのトークンが持つレ点がふられた状態候補名によって特定され る13）．制約的な構成要素は，上述のとおり，発火可能なトランジションの中からいずれか 1 つのト ランジションが発火するかを選択する際に， 1 つ以上のトークンの現在の状態に応じた手続き的構 成要素の発火条件である．ただし，図 1 ではこれらの制約的構成要素の定義は示されていない14）． 図 1 を用いて交渉局面の展開過程が⑥→⑦→⑥→⑧の順序で展開する流れを説明する．第 1 に認 識局面の取引が完了して交渉局面の最初のトランジションである⑥が発火可能な状態になった時に⑥は発火できる．⑥が発火すると，宣言的な構成要素の現在の状態として，⑥の長方形の内部に配 置された買手の提案であるトークン1stEEDSと1stEEPSの状態が［proposed］の状態になり，
1stBPPSの現在の状態が［⑥
sendOffer］の状態となる．
第 2 に，買手の提案を売手が満足するかどうかの判断がひし形（上部）で示されている．その判 断においてここでは
no
が選択されることによって，売手の提案であるトランジション⑦が発火す る．その結果，⑦の内部に配置された買手の提案であるトークン1stEEDSと1stEEPSの現在の状 態が［expired］になり，また売手の提案であるトークン2ndEEDSと2ndEEPSの現在の状態がい12） 本稿では，状態候補名には［ ］をつけた表現とする．
13） あるプレースの現在の状態情報を赤色のレ点で表すとともに，その情報を更新する方法については堀 内・清水（2016）623―624頁を参照されたい．
14） 交渉局面における制約的な構成要素は，以下の 3―2―3 と 3―2―4 の中で
CPN
モデルの制約的構成要 素としてのアーク，アーク・インスクリプション，およびガードを用いて定義している．ずれも［proposed］となり，1stBPPSの現在の状態が［⑦
counterOffer］の状態になる．
第 3 に，売手の提案を買手が満足するかどうかの判断（下部のひし形）において
no
が選択され ることによって，再度買手の提案であるトランジション⑥が発火する．その結果，⑥の内部に配置 された売手の提案であるトークン2ndEEDSと2ndEEPSの現在の状態がいずれも［expired］にな り，買手の再提案であるトークン3rdEEDSと3rdEEPSの現在の状態がいずれも［proposed］と なり，1stBPPSの現在の状態が［⑦counterOffer］から再度［⑥ sendOffer］の状態となる．
第 4 に，買手の再提案を売手が満足するかどうかの判断（上部のひし形）において
yes
が選択さ れることによって，トランジション⑧acceptOffer
が発火する．その結果，⑧の内部に配置された 買手の再提案であるトークン3rdEEDSと3rdEEPSの現在の状態がいずれも［specified］とな り，1stBPPSの現在の状態が［⑧acceptOffer］の状態になる．なお，図中の上部と下部において
示されるトランジションcascadeChange
とは，本モデルにおいては，ある局面から次の局面に進 展させるために必要となるトランジションである15）．以上より，交渉局面が⑥→⑦→⑥→⑧の順序で展開すると想定する図 1 を用いてビジネス取引の ステートマシンにおいていかに取引状態が記録されるのかを説明してきた．しかしながら，この機 能を
CPN
のモデルの中で実現するためには，（ 1 ）交渉局面における交渉内容（出荷数量，配送手 段，支払手段）の選択方法，（ 2 ）発火可能な 2 つのトランジションのうちいずれが発火するのか の選択方法，（ 3 ）相手の提案を棄却した際に，棄却した提案と自らの新提案を履歴として記録す る方法をCPN
のモデル化の要素や仕様を用いて適宜定義しなければならない．これらの事項は，CPN
では制約的構成要素としてのアーク，アーク・インスクリプション，およびガードを用いて 定義する．3
―
2―
3 CPNにおける反復的な交渉を可能にする仕組みの定義（ 1 ）交渉局面における交渉内容（出荷数量，配送手段，支払手段）の選択方法
本モデルでは，上記のとおり買手と売手と間の交渉内容は出荷数量，支払手段，配送手段の 3 つ を対象にしている16）．買手あるいは売手の提案におけるこれら交渉内容の選択については，第 7 の 制約的な構成要素の前提に従い，事前に定義されたデータの中からランダムに 1 つの項目を選択す る以下の乱数関数を用いて定義する．
【商品の数量を選択する乱数関数】
RndFunc
（1..100）RndFunc
関数は，カッコ内の引数の整数範囲（例では 1 から100までの整数）から 1 つの整数を 買手あるいは売手の商品の提案数量としてランダムに選択する関数である．15） トランジション
cascadeChange
の必要性については堀内・清水（2016）p.644を参照されたい．16） 注 6 ）を参照のこと．
【配送手段を選択する乱数関数と引数
DeliveryDataList】
RndFunc2
（DeliveryDataList）DeliveryDataList＝［“USPS”,“UPS”,“FedEx”,“DHL”］
RndFunc2関数は，引数のデータリスト
（例では配送手段となる “USPS”, “UPS”, “FedEx”,
“DHL”）から 1 つのデータを配送手段としてランダムに選択する関数である．
【支払手段を選択する乱数関数と引数
PaymentDataList】
RndFunc2
（PaymentDataList）PaymentDataList＝［“CreditCard”,“DebitCard”,“PayPal”,“Check”］
RndFunc2は引数のデータリスト
（例では支払手段となる “CreditCard”,“DebitCard”,“PayPal”,
“Check”）から 1 つのデータを支払手段としてランダムに選択する関数である．
これらの関数は買手あるいは売手の提案内容を特定するために用いる．具体的には，買手が提案 するトランジション⑥（sendOffer）と売手が提案するトランジション⑦（sendCounterOffer）の発 火後に乱数関数によって選択された自分の交渉内容（出荷数量，配送手段，支払手段）を特定する．
なお，図 2 はトランジション⑥が発火する時に，乱数関数によって買手の提案内容が特定されて プレース
EEDS
のトークンのデータとして記録されるまでの流れを示している．ここで，CPNモ デルにおいてはトランジションとプレースとの有向矢印をアークと呼び，そのアークが持つデータ 内容を決める式をアーク・インスクリプションと呼ぶ．図中では，トランジション⑥からプレースEEDS
へ接続されるアークの中で定義される買手の提案内容を意味するアーク・インスクリプ ションとして（...State＝proposed,Quantity＝RndFunc（1..100）,Delivery＝RndFunc2（DeliveryDa- taList）,...）
の式が定義される．乱数関数（RndFunc，RndFunc2）は，このアークで提案内容を特 定するために利用されている．（ 2 ）交渉過程におけるトランジションとその選択方法
発火可能な 2 つのトランジションのいずれが発火するのかの選択は，第 7 の制約的な構成要素の
⑥sendOffer
EEDS
❶（...State=proposed, ..., Quantity＝RndFunc （1..100）
, Delivery＝RndFunc2 （DeliveryDataList） , ...）
（..., proposed, ..., 30, USPS, ...）
図 2 乱数を利用した提案内容を決定するアーク・インスクリプション
前提に従い，発火可能な複数トランジション競合時の非決定性選択の状況においてトランジション を自動的に選択する
CPN
ツールの管理機能および発火条件を定義するガードの条件式を利用して 定義する．本モデルでは，第 1 に買手が（再）提案するトランジション⑥あるいは売手が買手その提案を受 入れるトランジション⑧のいずれが発火するのかを⑥と⑧のガードの条件式として次のように定義 する17）．
【買手が（再）提案するトランジション⑥のガード式】
［bp.ID＝⑦anded.State＝proposedandep.State＝proposed］
すなわち，トランジション⑥の発火条件は，プレース
BPPS
のトークンの持つデータ項目ID
が［⑦］である（売手が提案するトランジション⑦が発火している）こと，かつプレース
EEDS
とEEPS
のトークンの持つデータ項目State
の現在の状態がいずれも［proposed］である場合にト ランジション⑥が発火できるという条件である．【売手が買手の提案を受入れるトランジション⑧のガード式】
［（bp.ID＝⑥orbp.ID＝⑦）anded.State＝proposedandep.State＝proposed］
すなわち，トランジション⑧の発火条件は，プレース
BPPS
のトークンの持つデータ項目ID
が［⑥］あるいは［⑦］である（トランジション⑥あるいは⑦が発火している）こと，かつプレース
EEDS
とEEPS
のトークンの持つデータ項目State
の現在の状態がいずれも［proposed］である 場合にトランジション⑥が発火できるという条件である．第 2 に，売手が（再）提案するトランジション⑦あるいは買手が売手その提案を受入れるトラン ジション⑧のいずれかが発火するのかを⑦と⑧のガードの条件式として次のように定義する
【売手が（再）提案するトランジション⑦のガード式】
［bp.ID＝⑥anded.State＝proposedandep.State＝proposed］
すなわち，トランジション⑦の発火条件は，プレース
BPPS
のトークンの持つデータ項目ID
が［⑥］である（買手が提案するトランジション⑥が発火している）こと，かつプレース
EEDS
とEEPS
のトークンの持つデータ項目State
の現在の状態がいずれも［proposed］である場合にト ランジション⑥が発火できるという条件である．【買手が売手の提案を受入れるトランジション⑧のガード式】
［（bp.ID＝⑥orbp.ID＝⑦）anded.State＝proposedandep.State＝proposed）］
この条件は，上記の売手が買手の提案を受入れるトランジション⑧のガード式の条件と同じであ
17） なお，この条件式の
or
の前には，トランジション⑥が最初に発火するときの条件式が必要になるの で，本モデルのトランジション⑥の完全な条件式は次のようになる．［（bp.ID＝⑤and ed.State＝de-
faultandep.State＝default） or（bp.ID＝⑦anded.State＝proposedandep.State＝proposed）］
る．
（ 3 ）交渉過程における棄却案と新提案の記録方法
買手と売手の交渉過程においては，相手の提案を棄却することおよび自らの再提案をするタイミ ングは必ずしも同時に発生するとはいえない．しかしながら，本モデルにおいては競合するトラン ジション（非決定性選択）の状況において，いずれか（⑥あるいは⑧，⑦あるいは⑧）を自動的に選 択する
CPN
ツールの管理機能を利用するために，棄却と（再）提案の発生するタイミングが同時 であると想定する．そして，第 4 のトランジションの発火に伴う状態遷移の記録の前提に従い，相 手の提案の棄却と自分の再提案をトークンが持つデータとして記録する．すなわち，本モデルでは，第 1 にトランジション⑥あるいは⑧のいずれかが発火する可能性があ る時，⑥が発火する時には，まず棄却案の記録として売手の提案内容を棄却した事実を意味する棄 却状態［expired］の値および売手の提案内容を持つプレース
EEDS
とEEPS
のトークンとして 記録する．そのうえで再提案の記録として買手の新提案の事実を意味する提案状態［proposed］の値および買手の提案内容を持つプレース
EEDS
とEEPS
のトークンとして記録する．また，⑧ が発火する時には，売手の案を買手が受入れた特定状態［specified］の値および売手の提案内容 を持つプレースEEDS
とEEPS
のトークンとして記録する．第 2 にトランジション⑦あるいは⑧のいずれかが発火する可能性がある時，⑦が発火する時に は，まず棄却案の記録として買手の提案内容を棄却した事実を意味する棄却状態［expired］の値 および買手の提案内容を持つプレース
EEDS
とEEPS
のトークンとして記録する．そのうえで新 提案の記録として，売手の新提案の事実を意味する提案状態［proposed］の値および売手の提案 内容を持つプレースEEDS
とEEPS
のトークンとして記録する．また，⑧が発火する時には，買 手の案を売手が受け入れた特定状態［specified］の値および買手の提案内容を持つプレースEEDS
とEEPS
のトークンとして記録する．3
―
2―
4 本CPN
モデルの構成図 3 は，上記の反復的な交渉を可能にする仕組みを実現する
CPN
モデルの基本構成図である．交渉局面を対象とする本モデルにおいては，宣言的構成要素18）としてのプレース
EEDS，EEPS，
BPPS，手続き的構成要素としてのトランジション⑥～⑧および，制約的構成要素としてのアー
ク，アーク・インスクリプション，ガードである．以下では，CPNを用いて 3―
2―
3 での反復的 な交渉を可能にする仕組みをいかにモデル化できるのかを説明する．まず，発火可能な 2 つのトランジションのうちいずれが発火するのかの選択とは，買手の提案が なされた際に買手の提案を受入れるか（⑧）あるいは売手が再提案をするか（⑦）のいずれかを発
18） 実際の交渉局面での
CPN
モデルでは宣言的構成要素としてのプレース（GTS,CashTS, BAS, SAS,
EETS,EEDS,EEPS,ComittDS,ComittPS,BPPS）を定義・利用している．
火するかの選択，および売手の提案がなされた際に売手の提案を受入れるか（⑧）あるいは買手が 再提案をするか（⑥）のいずれかを発火するかの選択である．ここで，⑥～⑧のトランジションは すべての入力プレースに 1 つ以上のトークンがある場合にそのトランジションが発火可能になるこ とから，図 3 のトランジション⑥～⑧は発火可能な競合状態にある．このような状態においては，
ペトリネットモデルは競合するトランジションのいずれが発火するのかを決定できない「非決定性 選択」があることから，トランジション⑥～⑧はガード式を定義しない限り， 3 つのトランジショ ンのいずれが発火するのかを制御できない．そこで，買手の提案がなされた際に⑧あるいは⑦のい ずれか，および売手の提案がなされた際に⑧あるいは⑥のいずれかが発火できるように，各トラン ジションにガード式を用いて定義する．
すなわち，ガード式では，現在の提案が誰の提案であるのかを示す 3 つのプレース
BPPS
の トークンが持つ状態情報である［番号付きトランジション名］，およびプレースEEDS
とEEPS
のトークンが持つ提案中であることを意味する状態情報である［proposed］の 2 つの項目を発火 条件として用いて定義する．これらのプレースにあるトークンの状態情報に基づいてトランジショ ンの発火条件をガード式として定義するためには，各プレースから各トランジションに向かうアー クとトークンの状態情報をトランジションに伝えるアーク・インスクリプションを変数（ed,ep,
bp）
19）として定義する．加えて，ガード式には取引完了までに必要となるトランジションの中でいずれのトランジション の発火が現時点において終了しているのかに基づいて，すなわちプレース
BPPS
のトークンの状 態に基づいて，次に発火できるトランジションの発火条件を定義している．この発火条件を定義す るために， 3 つのトランジション⑥～⑧のそれぞれからプレースBPPS
に向けたアークを接続す る．それぞれのアーク・インスクリプションには，発火が終了したトランジションを判断するため の条件式であるID＝⑥，ID＝⑦，ID＝⑧をそれぞれ定義する．
また，反復的な交渉を可能にする仕組みである 3
―
2―
3 の（ 1 ）交渉局面における交渉内容（出 荷数量，配送手段，支払手段）の選択方法，および 3―
2―
3 の（ 3 ）相手の提案を棄却した際に，棄却した相手の提案と自らの再提案を履歴として記録する方法の機能は，相手の棄却した提案と自 らの再提案の両方を履歴として記録することを可能にする．これらは買手が（再）提案するトラン ジション⑥，あるいは売手が（再）提案するトランジション⑦の発火に伴い，棄却した場合と新た に提案した場合の 2 つの記録をプレース
EEDS，EEPS
のトークンのデータとして記録する．第 1 に，EEDSのトークンの記録については，図 3 のとおりトランジション⑥および⑦からプ
19） 変数
ed
はプレースEEDS
のトークンのデータを受け取る変数である．変数ep
はプレースEEPS
の トークンのデータを受け取る変数である．変数bp
はプレースBPPS
のトークンのデータを受け取る変 数である．⑥buyerSendOfferToSeller ⑦sellerSendCounterofferToBuyer⑧AcceptOffer
ep ep ep
ed ed ed
bp bp
bp
（...State＝proposed,..., Quantity＝RndFunc（1..100）, Delivery＝RndFunc2（DeliveryDataList）, ...） （...State＝proposed,..., Quantity＝RndFunc（1..100）, Delivery＝RndFunc2（DeliveryDataList）, ...）
（...State＝proposed,..., Amount＝RndFunc（1..100）*ep.Price, Payment＝RndFunc2（PaymentDataList）, …） （...State＝proposed,..., Amount＝RndFunc（1..100）*ep.Price, Payment＝RndFunc2（PaymentDataList）, ...）
（...State＝expired,..., Quantity＝ed.Quantity, Delivery＝ed.Delivery,...）
（...State＝expired,..., Amount＝ep.Amount, Payment＝ep.Payment, ...） （...State＝expired,..., Quantity＝ed.Quantity, Delivery＝ed.Delivery, ...） （...State＝expired,..., Amount＝ep.Amount, Payment＝ep.Payment, ...）
1stEEDSEEDS proposed expired specified in-service complete Quantity＝30 Delivery＝USPS
BPPS BPPS identification negotiation ⑥sendOffer ⑦ounterOffer ⑧acceptOffer
･･････････ ････････････････････
2ndEEDS proposed expired specified in-service complete Quantity＝20 Delivery＝FedEx 1stEEPSEEPS proposed expired specified in-service complete Amount＝45 Payment＝PayPal
2ndEEPS proposed expired specified in-service complete （...State＝specified,..., Amount＝ep.Amount, Payment＝ep.Payment, ...） （...State＝specified,..., Quantity＝ed.Quantity, Delivery＝ed.Delivery, ...）
［...bp.ID＝⑦and ed.State＝proposed and ep.State＝proposed］ （...,ID＝⑥, ...） （...,ID=⑦, ...） （...‚ID=⑧, ...） ［（bp.ID＝⑥or bp.ID＝⑦） and ed.State＝proposed and ep.State＝proposed］［bp.ID＝⑥and ed.State ＝ proposed and ep.State ＝ proposed］
Amount＝30 Payment＝Check
図3 交渉局面における本CPNモデルの基本構成（売手が買手の提案を棄却し，売手が新たな提案をしたケース）
レース
EEDS
に向けて棄却案と新提案の記録に要する 2 本のアークを接続する．すなわち，トラ ンジション⑥あるいは⑦のいずれが発火するにせよ，相手の提案を棄却案としてプレースEEDS
に向かうアーク・インスクリプションとして定義する．【棄却案を
EEDS
のトークンに記録するアーク・インスクリプションの定義】（...State＝expired,...,Quantity＝ed.Quantity（変数
ed
で受け取った相手が提案した出荷数量）,De-livery＝ed.Delivery（変数 ed
で受け取った相手が提案した配送手段）,...）同時に，自らの再提案をプレース
EEDS
に向かうアーク・インスクリプションとして定義する．【（再）提案を
EEDS
のトークンに記録するアーク・インスクリプションの定義】（...State＝proposed,...,Quantity＝RndFunc（1..100）,Delivery＝RndFunc2（DeliveryDataList）,...）
第 2 に，同様に
EEPS
のトークンの記録については，トランジション⑥，および⑦からプレー スEEPS
に向けて棄却案と再提案の記録に要する 2 本のアークを接続する．各トランジションか らの 2 本のアーク・インスクリプションには相手の提案内容の棄却を記録する（...State＝expired,Amount＝ep.Amount（変数 ep
で受け取った相手が提案した支払金額），Payment＝ep.Payment（変数ep
で受け取った相手が提案した支払手段）,...），および自分の新たな提案内容を記録する（...State＝proposed,Amount＝RndFunc（1.
.100）*ep.Price,Payment＝RndFunc2（PaymentDataList）,...）の式 を，それぞれ定義する．加えて図 3 では，提案内容を受入れるトランジション⑧が発火した時に，提案内容が特定された 状態［specified］および合意した提案内容などをプレース
EEDS
とEEPS
のトークンのデータと して記録する．そのために，トランジション⑧からプレースEEDS
およびEEPS
に向けたアーク を接続する．各アーク・インスクリプションには（...State＝specified,Quantity＝ed.Quantity,De- livery＝ed.Delivery,...）
および（...State＝specified,Amount＝ep.Amount,Payment＝ep.Payment,...）の式をそれぞれ定義する．以上が反復的な交渉を可能にする仕組みを実現する本稿での
CPN
モデ ルの説明である．3
―
2―
5 CPNToolsを用いた交渉局面のシミュレーション例（⑥→⑦→⑥の順による展開）図 4 は，CPN
Tools
を用いて構築したビジネス取引のステートマシンのモデルの一部であり，そのモデルに基づいて交渉局面において買手と売手の交渉過程をシミュレーションした図である．
このシミュレーションにおける提案の繰返しは，次のとおりである．
第 1 に，買手の提案のトランジション⑥が発火する．その状態は，例えばプレース
EEDS
の トークンは，［1`（1,EEDS_proposed,EEDS_NP,“Akira”,“Elmo”,（1,“Hershy’s”,1.0）,68,“FedEx”,“2020―02―2608:52:28”,“null”,...）］状態として記録される．
第 2 に，売手が買手の提案を棄却して自らの提案をするトランジション⑦が発火する．その状態 は，例えばプレース
EEDS
のトークンに買手の棄却案が［1`（1,EEDS_expired,EEDS_NP,“Akira”,“Elmo”,（1,“Hershy’s”,1.0）,68,“FedEx”,2020―02―2608:52:28”,“null”,...）］状態として記録される．同
時にプレース
EEDS
のトークンに売手の新提案が［1`（2,EEDS_proposed, EEDS_NP, “Akira”,
“Elmo”,（1,“Hershy’s”,1.0）,64,“DHL”,“2020―02―2608:52:28”,“2020-02-2608:52:35”,...）］状態として記 録される．
第 3 に，買手が売手の提案を棄却して自らの再提案をするトランジション⑥が発火する．その状 態は，例えば，プレース
EEDS
のトークンに売手の棄却案が［1`（2,EEDS_expired, EEDS_NP,
“Akira”,“Elmo”,（1,“Hershy’s”,1.0）,64,“DHL”,“2020―02―2608:52:28,“2020-02-2608:52:35”,...）］状態と 図 4 CPNToolsを用いた交渉局面のシミュレーション例（⑥→⑦→⑥）
して記録される．同時にプレース
EEDS
のトークンに買手の再提案が，［1`（1,EEDS_proposed, EEDS_NP, “Akira”, “Elmo”,（1, “Hershy’s”, 1
.0）, 52, “FedEx”, “2020―02―26 08:52:39”, “2020-02-26 08:52:35”,...）］状態として記録される．4 ．考 察
本稿では
ISO/IEC15944―4
（2007）で取り上げるカタログ販売を対象とするビジネス取引の計 画局面から実現局面までの 4 局面を対象として，特に交渉局面における買手と売手の交渉過程を，この
ISO/IEC
が提示している線形的なプロセスを超えて各当事者にとって満足が得られるレベル まで反復的に取引条件の交渉を再現できるCPN
モデルを構築した．以下，本モデルにおける問題 点とその問題の解決案を議論する．4 ― 1 CPN の非決定性選択を用いる交渉のモデル化
本稿のモデルにおいて，交渉局面におけるトランジション発火の選択は，買手の提案がなされた
（⑥）際に買手の提案を受入れるか（⑧），あるいは売手が再提案をするか（⑦）のいずれかを発火 するかの選択，および売手の提案がなされた（⑦）際に売手の提案を受入れるか（⑧），あるいは 買手が再提案をするか（⑥）のいずれかを発火するかの選択である．いずれのトランジションの発 火の選択に関する条件の定義は，ペトリネットモデルの競合するトランジションのいずれが発火す るのかを決定できない状況（「非決定性選択」）において，買手の提案がなされた（⑥）際に，⑧あ るいは⑦のいずれか，および売手の提案がなされた（⑦）際に，⑧あるいは⑥のいずかが発火する のかについての条件（ 3―2―3 （ 2 ）で説明）を各トランジションのガードに定義する． 2 つのト ランジション（⑥あるいは⑧，⑦あるいは⑧）のいずれが選択されるのかは，上記のとおり
CPN
ツールの管理機能に基づいて自動的に 1 つのトランジションが選択される．そのため，双方にとっ ての満足解となる⑧が選択されるまで⑥と⑦が繰り返され，かつ再提案があるときには相手の棄却 案と自らの再提案を記録することができるハッピーパスのモデルとなっている．しかしながら，現実の交渉にはハッピーパスの場合に加えて，双方が満足できずに交渉が決裂し てしまう場合も含まれる．本モデルでは，そうした決裂する場合を想定したモデルとなっていな い．
ただし，この決裂という事態を追加的なトランジション⑨として位置付けて，買手の提案がなさ れた（⑥）際に買手の提案を受入れるか（⑧）あるいは売手が再提案をするか（⑦），あるいは買 手との交渉を決裂するのか（⑨）のいずれかを発火するかの選択，および売手の提案がなされた
（⑦）際に売手の提案を受入れるか（⑧）あるいは買手が再提案をするか（⑥）あるいは売手との 交渉を決裂するのか（⑨）のいずれかを発火するかの発火条件をガード式で定義することによって
決裂の事態を想定したモデルに修正することができる．
4 ― 2 乱数関数を用いた交渉内容の選択
本モデルは，相手の提案に不満足である場合，相手の提案を棄却して自らの提案をするモデルで ある．交渉内容は，出荷数量，配送手段，支払手段であり，これらは乱数関数によって特定してい る．
一般的な交渉においては，相手の提案を棄却して自らの提案をする場合， 2 つの提案内容は異な るものである．しかしながら，単純な乱数関数によって提案内容を選択する場合には，相手の棄却 案と自らの提案における交渉内容が同一になってしまう可能性があるという問題が残る．ただし，
この問題については，重複しないランダムな選択をするプログラム技術的な改善によって解決する ことができる．
4 ― 3 1 種類の商品を対象とする交渉
本モデルでは，反復的な交渉を可能にする仕組みを明らかにし，それを
CPN
によってモデル化 することに焦点を置いている．そのため，交渉対象となる商品の種類を 1 種類に限定している．一般的な交渉においては，交渉対象となる商品の種類は常に 1 種類であるとはいえない．した がって，本モデルは複数商品を対象とする交渉を扱えるように拡張する必要がある．ただし，複数 の商品を対象とする交渉の場合であっても，本モデルで明らかにしてきた反復的な交渉を可能にす る仕組みは基本的にはそのまま利用できる．
5 ．むすびにかえて
本稿では，ISO/IEC15944―4（2007）で取り上げるカタログ販売を対象とするビジネス取引の計 画局面から実現局面までの 4 局面を対象として，特に交渉局面における買手と売手の交渉過程を，
この
ISO
が提示している線形的なプロセスを超えて，各当事者にとって満足が得られるレベルま で反復的に取引内容を交渉できるCPN
モデルをデザイン・サイエンス（Hevner &Chatterjee,
2010）のデザイン・サイクルに従い構築，評価してきた．学術的な貢献としては，第 1 に，ビジネス取引のステートマシンとは何かについて，これまでの
ISO/IEC15944―4
（2007）に見られる 3 つの構成要素から成り立つという構成的な観点からの説明 とは異なり，“ビジネス事象の発生を介して” 取引完了に至るその取引の進展（ビジネス取引実体の 状態遷移）を取引当事者へ伝えるという機能面に着目して 1 つの明確な定義を示したことである．第 2 に，ビジネス取引のステートマシンの構築に関する既存研究（堀内・清水，2016）が，取引 局面の計画と認識局面までを対象とするものであったのに対して，本稿は取引局面の計画，認識，
交渉，実現までの 4 局面を対象としている．加えて，交渉局面においては，既存研究（Horiuchi&
McCarhty,2011;Hunka&Zacek,2015）
やISO/IEC15944―4
（2007）において想定されていた線形 的な取引過程を超えて，双方の合意が得られるまで交渉を繰り返すことを可能にする仕組み（交渉 内容の選択方法，いずれのトランジションが発火するのかの決定方法，新提案をする際に棄却案と新提 案の両方の記録方法）とは何かを議論しつつその内容や仕組みを明確に定義した．第 3 に，CPNを用いるこの内容や仕組みの定義は， 1 つの取引展開例であるとはいえ想定外の トランジションが発火しないことを保証する人間と機械のいずれであったとしても理解可能なレベ ルでの定義となっている．
第 4 に，本モデルの限界として，交渉が決裂してしまうケースを踏まえていないこと，および乱 数を用いて提案内容である出荷数量，配送手段，支払手段を選択する場合には棄却案と再提案の提 案内容が一致してしまう可能性があるという問題を指摘するとともに，これらの問題の解決案を示 しつつ議論した．
実務的な貢献としては，第 1 に，人間と機械のいずれであったとしても理解できるビジネス取引 のステートマシンを構築して，それを構築するうえでの前提および双方の合意が得られるまで交渉 を繰り返すことを可能にする仕組みを
PIM
として明らかにしている．そのため，このPIM
に基 づいて特定の情報環境下で稼働するPSM
（PlatformSpecificModel）として，例えばビジュアルシ ミュレーションとの連携システムを構築したり，分散環境下における取引の進展状況を伝える装置 を構築したりすることが期待できる（堀内・清水・安積，2016）．最後に，今後の研究課題について述べる．現実の取引においては，交渉局面に限らず，取引の一 時停止や中止などが発生することは，ごく一般的な取引においても見て取ることができる．本
CPN
のモデルにおいても，その展開ができるように改善・拡張をする必要がある．その拡張は，例えば，交渉過程の繰り返しに限らず取引の実現後に，取引の当事者がその結果に満足するかどう かの調整過程も同時に考慮する
Dietz
（2006）のDEMO
のトランザクションモデルの考えや，ビ ジネス取引のステートマシンの構築研究（Hunka&Zacek,2015）の考えをヒントに行うことが考 えらえる．謝辞：本研究は，JSPS科研費17K03897および
ASEM-DUOFellowship
の助成を受けている．参 考 文 献
日本規格協会（1999）JISX7001:1999「標準電子取引参照モデル」．
堀内恵（2012）「ビジネス取引のステートマシン構築に向けて」『日本情報経営学会 第64回全国大会予稿 集』，73―76頁．
堀内恵・清水智・安積淳（2016）「ビジネス・プロセスの自律分散的革新：REAステートマシンとブロッ クチェーン技術の補完的利用による接近」『日本情報経営学会 第73回全国大会予稿集』，13―16頁．
