z-Tree2.1

Zurich

Toolbox For

Readymade

Economic

Experiments

z-TreeチュートリアルマニュアルUrs Fischbacher　著

飯田善郎　岩崎敦　西野成昭　訳

日本語版について

この日本語版マニュアルは z-Tree2.1 tutorial manual (http://www.iew.unizh.ch/ztree)を

もとに飯田善郎（京都産業大学経済学部）、岩崎敦（九州大学大学院システム情報科学研

究院）、西野成昭（東京大学人工物工学研究センター）が作成しました．翻訳に際しては

井寄幸平 (日本学術振興会特別研究員 PD,京都産業大学客員研究員）、米田紘康（京都産業

大学大学院経済学研究科博士後期課程），灰谷綾平（京都産業大学大学院経済学研究科博

士前期課程），小川一仁（広島市立大学国際学部）各氏の協力を頂くともに，文部科学省

私立大学学術研究高度化推進事業「オープン・リサーチ・センター」『実験経済学：経済

学教育の新しい方法と、それによる経済学教育の社会的効果の研究』および科学技術研究

費（基盤研究 B）「マーケットマイクロストラクチャー理論に基づくリサイクル市場への

戦略設計」（課題番号：13480115）の援助を受けました．ここに深く感謝いたします．

最後に，これら２つのプロジェクトの研究代表者をつとめ，我々に日本における実験経

済学研究を推進する大きな機会を与えてくださった小田宗兵衛教授（京都産業大学経済学

部）と，この素晴らしい経済実験用ソフトウェア z-Treeを開発し，我々とともに日本語化

の作業を快く引き受けてくれた Urs Fischbacher氏に改めて感謝します．

なお，この日本語版への質問，誤りなどの問い合わせは iida01@cc.kyoto-su.ac.jpにお

願いいたします．

飯田善郎

2005年 4月

目次

1 z-Treeについて 5

1.1 このマニュアルの中で使用されるスタイル . . . . . . . . . . . . . . . . . . 6

2 はじめに 7

2.1 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 公共財実験を例としたプログラミングガイド . . . . . . . . . . . . . . . . . 8

2.3 トリートメントのテスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 トリートメントの定義 19

3.1 相互作用のない単純な実験 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 データ構造および単純なプログラミング . . . . . . . . . . . . . . . . . . 19

3.1.2 コメント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

3.1.3 簡単な実験の流れ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.4 ステージツリー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

3.1.5 データの表示と入力 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.6 変数 Profitおよび TotalProfit . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.7 例 : 計算練習 (guesssin.ztt) . . . . . . . . . . . . . . . . . . . . . . . . .28

3.2 被験者間に相互作用のある実験：対称なゲーム . . . . . . . . . . . . . . . . 29

3.2.1 テーブル関数 (Table functions) . . . . . . . . . . . . . . . . . . . . . . .29

3.2.2 他のテーブルにおけるテーブル関数 . . . . . . . . . . . . . . . . . . . . . 30

3.2.3 スコープオペレータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.4 自分自身のグループメンバーへのテーブル関数の使用制限 . . . . . . . . 32

3.2.5 グループマッチングの基本 . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2.6 要約統計量 (summary statistics) . . . . . . . . . . . . . . . . . . . . . . .34

3.2.7 例：推測ゲーム (Guessing game) . . . . . . . . . . . . . . . . . . . . . .34

3.2.8 順位に依存して支払額が変動する例 (Rank dependent payment) . . . . . .36

3.3 非対称・同時手番ゲーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3.1 条件付き実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

3.3.2 被験者ごとに異なる値の計算 . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3.3 Parameter table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

1

3.3.4 パラメータのインポート . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3.5 グループマッチング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3.6 例：一般的な 2×2ゲーム (game222) . . . . . . . . . . . . . . . . . . . .44

3.3.7 例：プログラム内でのグループの定義 . . . . . . . . . . . . . . . . . . . 45

3.4 スクリーンレイアウト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4.1 小規模のレイアウト：アイテム . . . . . . . . . . . . . . . . . . . . . . . 47

3.4.2 大規模のレイアウト:スクリーン設計およびボックス . . . . . . . . . . . . 48

3.4.3 ボックスの配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

3.4.4 基本的なボックスのタイプ . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.4.5 ボタン配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55

3.4.6 Backgroundレイアウト . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.4.7 テキストの中への変数の挿入 . . . . . . . . . . . . . . . . . . . . . . . . 56

3.4.8 RTFを備えたテキストフォーマット . . . . . . . . . . . . . . . . . . . . 57

3.5 シーケンシャルゲーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.5.1 手番 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58

3.5.2 異なるステージでの同時性 . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.5.3 ステージの終了 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60

3.5.4 例:最後通牒ゲーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.6 連続的なオークション市場 . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.6.1 概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

3.6.2 契約テーブルにおけるダブルオークション . . . . . . . . . . . . . . . . . 65

3.6.3 オークションのためのレイアウトの準備 . . . . . . . . . . . . . . . . . . 66

3.6.4 オファーの実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67

3.6.5 オファーを見る . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68

3.6.6 doステートメント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.6.7 申し出の受理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69

3.6.8 被験者の入力のチェック . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.6.9 オークションステージの詳細 . . . . . . . . . . . . . . . . . . . . . . . . 72

3.6.10プログラム中の新しいレコードの形成 . . . . . . . . . . . . . . . . . . . 72

3.6.11質の要素の追加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73

3.7 ポスッテドオファーマーケット . . . . . . . . . . . . . . . . . . . . . . . . 73

3.8 クロックオークション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.8.1 ダッチオークション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

2

3.8.2 ステージの終了 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75

3.9 より進んだ概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76

3.9.1 前の結果に依存するゲーム . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3.9.2 新しいテーブルの定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3.9.3 ステートメントの条件付きの実行 . . . . . . . . . . . . . . . . . . . . . . 78

3.9.4 ループ–whileと repeat– . . . . . . . . . . . . . . . . . . . . . . . . . . .80

3.9.5 複雑な手番の構築 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

3.9.6 不定長のトリートメント . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.9.7 例–戦略方法 (行列を用いて)– . . . . . . . . . . . . . . . . . . . . . . . . 82

3.9.8 情報の表示・非表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

3.9.9 セッション・テーブルを用いてトリートメントからトリートメントに

データをコピーする方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4 アンケート (Questionnaire) 85

4.1 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

4.2 アンケートの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

4.2.1 アドレスフォーム (Address form) . . . . . . . . . . . . . . . . . . . . . .85

4.2.2 質問フォーム (Question form) . . . . . . . . . . . . . . . . . . . . . . . .86

4.2.3 質問 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86

4.2.4 Profitディスプレイ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.2.5 ルーラー (Ruler) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89

4.2.6 ボタン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89

4.3 アンケートの実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90

4.4 領収書の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90

5 セッションの実行 91

5.1 クイックガイド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91

5.2 トリートメントとアンケートの準備 . . . . . . . . . . . . . . . . . . . . . . 91

5.3 実験者 PCの起動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92

5.4 クライアントテーブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.5 クライアントのサーバーとの接続の確立 . . . . . . . . . . . . . . . . . . . 93

5.6 クライアントの名前を固定する方法 . . . . . . . . . . . . . . . . . . . . . . 93

5.7 セッション中 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93

3

5.8 セッションの終了 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94

5.9 クラッシュもしくはブロックされた被験者 PCの扱い . . . . . . . . . . . . 94

5.10 実験者 PCがクラッシュしたら . . . . . . . . . . . . . . . . . . . . . . . . 94

5.11 被験者が損失を出した場合の処理 . . . . . . . . . . . . . . . . . . . . . . . 95

5.12 サーバーによって作成されるファイル . . . . . . . . . . . . . . . . . . . . . 96

5.13 データ分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97

6 インストール 98

6.1 ファイルサーバを伴うシステムへのインストール . . . . . . . . . . . . . . 98

6.2 ファイルサーバのない時のインストール . . . . . . . . . . . . . . . . . . . 98

6.3 テスト環境のセット・アップ . . . . . . . . . . . . . . . . . . . . . . . . . . 98

6.4 実験を自国語で実行する . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

6.5 1つ以上の z-Treeを実行する . . . . . . . . . . . . . . . . . . . . . . . . . 99

6.6 インストールの例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99

4

1 z-Treeについて

z-Treeプログラムはチューリヒ大学で開発されました。z-Treeの目的は豊富な経験がな

くても経済実験を可能にすることです。z-Treeは、実験者用のプログラム z-Tree”Zurich

Toolbox for Readymade Experiments”と被験者用プログラム z-Leafで構成されています。

z-Treeでは実験を設計し、実行することができます。z-Treeは公共財ゲーム、交渉実

験、ポステッドオファーマーケット、ダブルオークションなど、さまざまな実験プログラ

ムを作成することができます。z-Treeのプログラミングにはある程度の経験が必要です。

しかしある程度の経験さえあれば実験を行なうために必要な努力はきわめて小さなものに

なります。経験のある実験者なら公共財ゲームは 1時間未満、ダブルオークションなら 1

日未満でプログラムすることができます。

チューリヒでは、コンピューター上で行なわれるほとんどすべての実験で z-Treeが用

いられます。26台の 486プロセッサーおよび 16MBの RAM を備えた PCがイーサネッ

ト上で接続されています。プログラムは常にこの構成で効率的に働きます。z-Treeを使う

ためにはマニュアル全部を読む必要はありませんが、2章は非常に重要です。2.1節およ

び 2.2節は特に重要です。さらに z-Treeを使用する研究所の少なくとも 1人が 2章の残

りに精通していれば有利です。トリートメントを設計したい人は 3.1節および 3.2節を読

む必要があります。画面上の見た目だけを設計したい人は、3.4.1節および 3.6節だけを

読めばよいでしょう。3.6節の中では、3.6.6節までの節をすべて読む必要があります。残

りは必要な時に調べれば良いでしょう。

3.4.1節、3.4.2節、3.4.3節、3.4.4節および 3.4.5節はプログラミングにとって不可欠

です。更に 3.5節は有益です。実験をプログラムしたい場合、3.8節はトリートメントの

コース上でさらに重要です。3.4.6節で説明される「スコープオペレーター」は困難な概

念ですが複雑な実験、特に市場実験のためには非常に重要です。

他の章はどれも必要な場合に調べるとよいでしょう。

z-Treeは非常にフレキシブルですが、それでもあなたが既存のプログラムでは実行でき

ないものを実現したい場合があるかもしれません。7章は、あなたのこの不測の事態に役

立つ Tipsやコツが記されています。更に、http://www.iew.unizh.ch/ztreeに z-Treeのウェ

ブサイトがあります。まだ何かが見当たらないと思う場合、あるいはプログラムにおける

エラーを見つけた場合は、ztree@iew.unizh.chに電子メールを送ってください。

プログラムを我慢強く利用し、プログラムの改善のための提案をしてくれた次のユー

ザー達に感謝します。:Vital Anderhub, Armin Falk, Ernst Fehr, Simon Gachter, Florian

5

Knust, Oliver Kirchkamp, Andreas Laschke, Martin Strobel, Jean Robert Tyran.また、マ

ニュアルを作成するのを手伝ってくれた Armin Falk, Christina Fong, Omar Solanki and

Beatrice Zanellaにも感謝します。Omar Solankiはもとはドイツ語の原マニュアルを英語

に翻訳してくれました。

1.1 このマニュアルの中で使用されるスタイル

スタイルの説明 例

通常のテキストは明朝体で書かれています。 通常のテキスト

プログラムはタイプライタ体で書かれています。 　 M = 0;

フィールドへの入力は Courierで書かれています。 0.1

変数テキストはイタリック体で書かれています。 if(condition){例で、「if」「else」、また、括弧は例の通りに statements

書かれなくてはならなりません。 else{「condition」は適切なテキストと置き換えられ statements

ます。 }メニューコマンドはボールド体で書かれています。 Save Client Order

メニュー名は、セパレーターとして「>」を File >

備えたメニュー・コマンドの前におかれます。 Save as ...

「>」文字は階層的メニューのために使用されます。

ステージツリーエレメントはサンセリフ体で書 A

かれています。

キーは角括弧に囲まれています。 [F5]

モデファイヤーキーは、当該キーが < >の <alt>-[Tab]

中に入ってキーの前につきます。

6

2 はじめに

2.1 用語

コンピュータを使用しない実験では、通常 1人以上の実験者（実験を実施する人）と多

くの被験者がいます。被験者は実験者を介してコミュニケーションをします。コンピュー

タ化された実験では、このコミュニケーションがコンピュータを通じて行なわれます。実

験者によって操作されるコンピュータは実験者 PCと呼ばれます。被験者によって操作さ

れるコンピュータは被験者 PCと呼ばれます。実験者が仕事をするプログラムは「z-Tree」

と呼ばれます;それはサーバプログラム、あるいは単にサーバと呼ばれます。被験者用の

プログラムは「z-Leaf」と呼ばれます。それはクライアントプログラムですが単にクライ

アントとも呼ばれます。

Figure 2.1 z-Treeのクライアント／サーバアーキテクチャ。

ファイルサーバとサーバプログラムを混同しないように注意してください。後者はプロ

グラム、データおよび実験の結果を保存するために使用されます。ファイルサーバは、実

験を行なうために絶対に必要というわけではありません。クライアントがサーバとのコン

タクトを確立すると、直ちにサーバとクライアントのコミュニケーションがファイルサー

7

バを介さずに直接確立します。しかしファイルサーバはスタートアップを容易にします。

ファイルサーバ上に格納される情報はどこからでも読めます。例えばクライアントにどの

コンピュータがサーバ役を果たしているか分かることを可能にします。これは、実験者

PCとして異なるコンピュータを使用することを容易に可能にします。

ここでは「セッション」とは被験者が実験会場に到着し、支払いを受け取るまでに生じ

る出来事を意味します。1セットのセッションは 1つの実験を構成します。トリートメン

トはファイルに格納されるセッションの一部です。トリートメントがどのように定義され

るかは、３章の「トリートメントの定義」の中で説明されます。各セッションは、1セッ

トのアンケートを伴う 1つ以上のトリートメントから成ります。アンケートも自由に作る

ことができます。これは 4章で説明されるでしょう。

2.2節および 2.3節では、トリートメントを作りながらガイド付きツアーをします。こ

れらの節の目的は z-Treeとプログラムする方法に関する初歩的な概観を提供すること

です。

2.2 公共財実験を例としたプログラミングガイド

本章では、単純な公共財実験のプログラミングを見ていきます。ここでは直観的なレベ

ルでのプログラミングを示し、次の章で詳細を説明します。この公共財トリートメントで

は、被験者は 4人からなる被験者のグループの 1員になります。被験者は「プロジェク

ト」と呼ばれる公共財にどれだけ手持ちの 20ポイントを寄付するかを決定します。被験

者の利益は、2つに分けられます:第 1の部分は彼らが手元に残す額で、20から寄付額を

引いたものです。第 2の部分は公共財からの収入です。グループ内の寄付はすべて合計さ

れ、1.6倍されます。その額はグループ内のすべての被験者に配分されます。

では、このトリートメントをプログラムしましょう。z-Treeを起動すると同時に、図

2.2のようにタイトルのない空のトリートメントを持つウィンドウが開かれます。そのト

リートメントは、ステージツリーと呼ばれるツリー構造によって表わされます。トリート

メントはステージの連なりとして構築されます。ステージを構築し始める前に、まず準備

として、トリートメント用のいくつかのパラメータをセットアップします。background

では、被験者の数、グループの数、ピリオドの数、得たポイントの換金レートを入力しま

す。ステージツリーの backgroundアイコンをダブルクリックするか、このラインを選択

(クリック)して次に Treatment メニューから Info... 選ぶことで図 2.3のようなダイアロ

グボックスが開きます。

ここでは Number of subjectsを 24にセットしましょう。Number of groupsを 4にし

8

Figure 2.2 z-Treeを起動するとタイトルのついていないトリートメントがまず作られる。

Figure 2.3 Backgroundのダイアログボックスでは、いくつかの一般的なパラメー

タを入力することができる。

たので 4人のグループが 6つ得られます。10回繰り返すので、私たちは支払いピリオド

(# paying periods)の数を 10にセットします。最後に Show up fee（参加報酬）を 10に

セットします。これは被験者が実験に参加するために来たことに対して与えられる金額で

す。それは現地通貨単位 (チューリヒでは SFR)で与えられます。チューリヒでは一般に

10スイスフランの料金を参加報酬として払います。Exch.rateは、実験内のポイントの現

地通貨単位への交換レートです。例では 100ポイントが 7スイスフランに交換されます。

9

トリートメントに特有のパラメータ (初期賦存量の 20や効率性要因の 1.6など) は、

プログラムで定義されます。プログラムを挿入するためにはステージツリーアイコンの

Bの中の A のすぐ上のステージツリーエレメントを選択 (クリック)

してください。次に、Treatment メニューから New Program... を選んでください。図

2.4のダイアログボックスが現われます:

Figure 2.4 プログラムはプログラムダイアログボックスに入力される。

Programのフィールドへ次のように入力してください:

　 EfficiencyFactor=1.6;

　 Endowment=20;

トリートメントの初めにすべてのパラメータを定義するとよいでしょう。トリートメン

トが理解しやすく、パラメータの変更が容易になります。

では第 1ステージを追加します。第 1ステージは被験者が公共財への寄付額を決定し

て入力する寄付入力ステージです。それを加えるために、ステージツリーエレメントの

Bを選択し、Treatment メニューから New Stage... を選びます。するとダイア

ログボックスが開きます。このダイアログボックスでは、いくつかのオプションを選ぶ

ことができます。このトリートメントでは、デフォルト・オプションを変更する必要はあ

りません。ステージの名前を単に Contribution entryに変更し、OK ボタンをクリックし

ます。ステージはどれも 2つのエレメントを含みます。(図 2.5参照):A および

W Sです。Active screenは「重要な」スクリーンです。このスクリーンにおい

ては、被験者は情報を得て、決定を入力します。被験者がステージを終えると、Waiting

screenが表示されます。被験者が次に進めるようになるまで、Waiting screenは表示され

10

つづけます。

Figure 2.5 Active screenおよびWaiting screenを備えたステージツリー上のステージ。

ここで、寄付入力ステージの A を定義します。スクリーンはボックスと呼ば

れる長方形の部品を使って構成します。ボックスにはさまざまな種類があり、Treatment

メニューのなかの階層メニュー New box からすべて作成することができます。最も一

般的なボックスは standard boxです。ボックスを作成するために、C ス

テージの A エレメントを選択し、New Box > Standard box... を選択します。

現われるダイアログボックスでは、オプションがすべて適切に設定されています。OKを

クリックしてこのダイアログボックスを終えます。このボックスへアイテムを置きます。

アイテムとは変数のことです。まず初期保有の変数を Endowmentとします。Treatment

メニューから standard box を選択し、New Item... を選びます。Label のフィールド中

へ Your endowment、Variableのフィールドの中へは Endowment、Layoutのフィールド

には１を入力します。これらは Endowmentの値が 1の倍数として扱われ (20.0ではなく

20)、「Your endowment」というラベルがつくことを意味します。

第 2のアイテムは寄付の入力に使います。ここでこの変数を Contributionと名づけ

ます。この変数は入力変数です。つまり被験者は Contribution の値を入力しなければ

なりません。入力するとその値が表示され、変数に代入されます。そのラベルは Your

contribution to the projectです。それは (Layoutフィールドに入力された)１の倍数で、そ

して (ダイアログボックス内の Minimumおよび Maximumに入力された)0と Endowment

の間の数値でなくてはなりません。

このステージは実際の実験ではボタンを押すことによって終了します。終了のためのボ

タンを、変数の入力アイテムの後に挿入します。Treatment メニューから New Button...

を選びます。現われるダイアログボックスで、被験者に表示されるボタンの名前を入力す

ることができます。入力が必要なステージでは、デフォルト (OK)がよい選択です。この

ダイアログボックスでの他のオプションは後に説明されます。オプションをデフォルトの

ままにしておくのは無難な選択です。

これで第 1ステージは完成です。

このトリートメントでは、もう 1 つのステージ (利益表示ステージ) があります:

11

Figure 2.6 アイテムダイアログボックス。　このダイアログボックスは変数の値を

表示する出力アイテム。

Figure 2.7 このダイアログボックスは変数の入力を扱う入力アイテム。

Contribution entryステージを選択（クリック）し、Treatment メニューから New Stage...

を選びます。ダイアログボックスではこの新しいステージを Profit Displayと名付けます。

この P Dステージでは被験者の利益を表示します。表示の前に、利益を計算

しなければなりません。このステージの初めにプログラムを挿入します。被験者がこのス

テージに入ると、そのプログラムが実行されます。プログラムを挿入するために、P

12

Figure 2.8 ボタンダイアログボックス。

D ステージを選択し、Treatment メニューから New Program... を選びます。プロ

グラムフィールドで次のように入力します。　 SumC = sum( same(Group ), Contribution);

　 N = count( same(Group ) );

　 Profit = Endowment -Contribution + EfficiencyFactor * SumC/N;

1行目では、被験者のグループ中の寄付の合計を計算します。Groupはデフォルトの変

数です。それは第 1グループでは１、第 2グループでは 2です。これについては、3.2.1

章で詳細に説明されます。2行目では、グループ中の被験者の数を数えます。もちろんこ

のトリートメントでは、あらかじめ 4人であるとわかっているので N=4と書くこともで

きます。しかし上記の式ならプログラムをどこも変更せずに、異なるグループ人数のト

リートメントを実行することができます。最後のラインでは、被験者用の支払いを計算し

ます。デフォルトの変数である Profitはこのために使用されます。各ピリオドの終わり

にこの変数が合計されるのでこの変数は特別です。セッションの終わりに、paymentファ

イルと呼ばれる各被験者が全体のセッションで得た利益の合計を書き出したファイルを生

成することができます。

では、利益表示スクリーンを定義します:最初に P Dステージの A

に Standard Boxを挿入します。このボックスに 3つのアイテムを挿入します。

・自分自身の寄付

・グループの寄付の合計

・このピリオドでの収入

自分自身の寄付とグループ寄付の合計のアイテムを挿入します。収入を表示するアイテ

13

ムでは、小数点 1位で Profit変数を表示したいので、Layoutフィールドへ.1を入力し

ます。利益表示スクリーンもボタンが必要です。このボタンは被験者が何かを確定する必

要がないので Continueと名前をつけます。ボタンは、被験者がデフォルトのタイムアウ

トより早く次のピリオドに進むことを可能にします。

これで完成です。トリートメントができました。下記の図は、今作った公共財トリート

メントのステージツリーを示します。トリートメントを保存しておきましょう。File メ

ニューから Save As... を選んでください。Save as...ダイアログボックスが現われます。

トリートメントに適当な名前をつけ、好きなディレクトリにそれを格納してください。

Figure 2.9 公共財実験のステージツリー。

2.3 トリートメントのテスト

このセクションでは、トリートメントをテストする方法を説明します。テストは、ト

リートメントが問題なく作動するかどうか確認することが目的です。ほとんどのエラーは

14

被験者数が少数でも見つけることができますので、最初は少ない被験者数でトリートメン

トを試みるのがよいでしょう。テストでは少数でも被験者の入力は自分で行なわなければ

なりません。一般に１ピリオド試みれば十分です。このトリートメントでは被験者を 2人

にして１ピリオドをテストしてみましょう。

トリートメントをテストするには、2つの方法があります。実験室でテストする時に

は、被験者当たり 1台のコンピュータを起動します。これを実行する最も容易な方法は

ファイルサーバ上のディレクトリから z-Treeを始めて、次に同じネットワークディレク

トリから z-Leafを始めます。z-Leafを起動するとコンピュータごとにスタートスクリー

ンが表示されます。実験室以外でトリートメントをテストしたい場合、単一のコンピュー

タ上でいくつかの z-Leafを実行することができます。そのためには異なる z-Leafに異な

る名前を与えなければなりません。zleaf.exeのショートカットの作成により (ファイルを

右クリック > ショートカットを作成する) これが可能です。各ショートカットについて

は、プロパティダイアログボックスを開き、ショートカットのタブをクリックし、「リン

ク先」のテキストに “/name Yourleafname” というように追加します。/nameの前と後に

はかならずスペースが必要ですがスラッシュ (/) の後にスペースを入れてはいけません。

Yourleafnameは任意の名前をつけてください。違うショートカットにはそれぞれ異なる

名前をつけなくてはいけません。ショートカットのアイコンをダブルクリックすることに

より z-Leafを始めることができます。<alt>-[Tab]で異なる複数のプログラムを切り替え

ることができます。

z-Treeが動作するコンピュータ上で z-Leafを始めても、実験室で別のコンピュータ

上で z-Leafを始めても、どれだけの z-Leafが現在実行していて z-Treeと繋がっている

かチェックすることができます。チェックは下記のように行います: z-Treeで、Run メ

ニューの中の Clients’ table を選びます。z-Leafが z-Treeに接続している時には、コン

ピュータの名前がこのウィンドウの第 1列に表示されます。

実験を実施するのに十分な数のクライアントが接続されれば、すぐにトリートメントを

始めることができます。トリートメントを始めるために、トリートメントウィンドウが前

面になければなりません。次に、Run メニューから Start Treatment を選ぶと開始されま

す。トリートメントが始まると、図 2.12のようなスクリーンが z-Leafが走るコンピュー

タに表示されます。

これは寄付入力ステージの Active screenで、2つのボックスからなります。上部のヘッ

ダーボックスはそのピリオドの残り時間とピリオド番号を示します。ヘッダーボックスは

backgroundの Active screenに含まれているので、各ステージの Active screen中で示され

ます。スタンダードボックスにはアイテム、およびステージツリーで定義したボタンが表

15

Figure 2.10 Windowsのショートカットダイアログ。この z-Leafは”first”と名づけられている。

Figure 2.11 「First」および「Second」と命名された 2人のクライアントが接続を

確立していることを示すクライアントテーブル。

16

Figure 2.12 公共財トリートメントのクライアントスクリーン。

示されます。「Your contribution to the project」の隣のフィールドへ 0から 20の間の値を

入力し、「OK」ボタンをクリックすることができます。25、-7あるいは 2.2など認められ

ない値を入力するとそのような入力ができないというメッセージが表示されます。

z-Treeの “Clients’ Table”で被験者の状態を確認することができます。各ステージにつ

いては、2つの状態があります:星印 (***) と共に示されるアクティブな状態は、Active

screenに相当します。また、ダッシュ (-)で示された待機状態は、Waiting screenに相当し

ます。これらから入力を行なわなければならない被験者がまだいるかどうかをチェックす

ることができます。被験者が入力を行なう場合、Subjects Table からそれらの決定を観

察することができます。このテーブルは Run メニューから開くことができます。

Figure 2.13 被験者 firstが入力を終え、被験者 secondがまだ入力していない状

態の Clientsテーブル。

被験者がすべての入力を行なうと、利益が計算され表示されます。

トリートメントのチェックではあなたが意図したとおりにすべて計算されるか、スク

17

リーンがちゃんとしているかを確認します。誤りがあればそれを修正し、トリートメン

トを再びテストしなければなりません。プログラムを修正する最も容易な方法はプログ

ラムのステージツリーエレメントをダブルクリックすることです。クリックしたエレメ

ントの内容を編集することができますのでエラーを修正します。エレメントをクリック

し、メニューコマンドから Treatment > Info... 選ぶことでも修正できます。さらに、ス

テージツリーエレメントを移動させることができます。エレメントを選択し、新しい位置

にドラッグします。そこにエレメントを移動することができない場合、beep音が鳴りま

す。Edit>Cut を選択することによりステージツリーエレメントを削除することができま

す。エレメントをコピーして貼り付けることもできます。その場合エレメントを選択して

Copy を選択します。それから貼り付ける場所を選択し、Paste を選びます。

ガイド付きツアーはもうすぐ終わりです。< alt > -[F4] で z-Leafを終了することがで

きます。z-Treeメニューコマンドの Quit で z-Treeが止まります。次の警告のダイアログ

ボックスが現われます: “The session is not finished with the writing of a payment file. Do

you nevertheless want to quit?”（「セッションは支払いファイルの書き出しをしていませ

ん。それでもやめますか。」）今このメッセージを気にする必要はありません。しかしあな

たが実際に被験者を使ったセッションを行う場合にはにこのメッセージは意味がありま

す。これは 3.9.5節の中で説明されます。

次の章では、トリートメントをプログラムする方法について詳細に説明します。

18

3 トリートメントの定義

「はじめに」で説明したように、トリートメントはファイルに格納されるセッションの

一部です。前章では、単純なトリートメントを構築しながらガイド付きツアーを提供しま

した。本章ではトリートメントを構築する方法について詳細に説明します。以後のセク

ションでは、より複雑な実験をどのように z-Treeで構築するかを示します。各セクショ

ンは、まず理論的な説明があり、次にその実例を示します。

3.1 相互作用のない単純な実験

本章では、z-Treeの最も重要な特徴を示します。はじめに、z-Treeにおいてデータがど

のように格納されるか、プログラムによってデータがどのように変更されるかを説明しま

す。次に情報が被験者にどのように表示されるか、また、被験者の入力がどのように処理

されるかを示します。最後に、一つのトリートメントにおける行動の流れがどのようにな

るかについて概観します。

3.1.1 データ構造および単純なプログラミング

セッションの状態に関する情報はデータベースに格納されます。このデータベースは

テーブル（表）から成ります。テーブルの行をレコード、列を変数と呼びます。各変数は、

固有の名前を持っています。テーブル中の個々のエントリー（項目）はセルと呼ばれます。

z-Treeでは、セルは数値のみでテキストは扱えません。図 3.14はある空のトリートメン

ト*1の globals テーブルと subjects テーブルのスクリーンショットです 。第 1列は、

変数の名前を示します。この例では、globals テーブルは 1つのレコードを (globals

テーブルのレコードは常に１つ)、subjectsテーブルは 3つのレコードを含んでいます。

変数の名前には任意の単語、正確には文字、数および下線 “ ” を使用することができま

す。ただし 1文字目は文字でなければなりません。符号、空白および句読点は使用できま

せん。大文字と小文字は区別されますので、hallo、Hallo および hAllo は 3つの異な

る変数とみなされます。変数に長い名前を与えることも可能で、そうすることによってプ

ログラムが理解しやすくなります。複数の単語からなる名前を変数に与えたければ、下

線 “ ” でつなげることで一つの変数としたり、各単語を大文字で始めたりすることができ

*1 トリートメントの実行中は、テーブルを見ることができます。Runメニュー中の任意のテーブルを選ぶとそのテーブルが表示されます。

19

Figure 3.1 globalsテーブルおよび subjectsテーブル：z-Treeデータベースで最

も重要なテーブル。

ます。使用できる変数名の例：

　 A

　 contribution23

　 v 2 13

　 Buyers offer

　 BuyersOffer

使用できない変数名の例：

　 12a 　数で始まる

　 v 2 13 　スペース（空白）を含んでいる

　 v.1.0 　ドット（読点）を含んでいる

　 Buyer’sOffer 　アポストロフィを含んでいる

z-Treeは被験者の利益を代入する Profitなど、どのトリートメントでも使用される幾つ

かの変数をデフォルトの変数としてあらかじめ持っています。他の変数はトリートメント

ごとに特有のもので、プログラム内において定義されます。プログラムはステージの初め

に、あるいは B内のテーブル定義（ファイルキャビネットの形のアイコン）と

Active screenの間に置かれます。プログラムは、常に特定のテーブル用に定義されます。

逆に言えば、あるプログラムは常に特定のテーブル内で実行されます。テーブルは、図

3.15で示されるようなプログラムダイアログボックスで宣言されます。このダイアログ

ボックスのポップダウンメニューにはトリートメントにおいて利用可能なテーブルがすべ

て含まれています。

globals テーブルは、レコードを一つだけ含む最も簡単なテーブルです。つまり

globalsテーブルでの変数は同時にセルも決定することになるので、この変数の値につい

20

Figure 3.2 プログラムダイアログボックスではプログラムがどのテーブルで実行さ

れるかを指定する。

て説明を進めます。さしあたっては globalsテーブル中のプログラムについて述べます。

プログラムで最も重要な要素は割り当て構文（assignment statement）です。割り当て構

文はある計算を行い、変数にこの計算の結果を返します。割り当ての文法は下記のとおり

です。

　 Name of variable= expression;

方程式の右側の expressionが計算され、左側の変数に割り当てられます。各割り当て構

文がセミコロン（;）で終わることに注意してください。この変数が値を既に持っている

場合、その値は上書きされます。変数がまだ存在しない場合には、この構文によって新た

に作成されます。式の中ではすべての基礎的な種類の計算が可能です。通常の計算と同

様、乗法と除法は加法と減法の前に計算されます。それ以外は左から順に計算されます。

したがって、2 + 3× 4は 20ではなく 14となり、10− 5− 2は 7ではなく 3となります。

また min、max、exp、random、roundなど一連の関数が利用可能です。(リファレンスマ

ニュアルに、割り当て構文が利用できる演算子（オペレータ）および関数の全リストがあ

ります。)式の中で使用されるすべての変数は前もって作成しておく必要があります。つ

まり、すべての変数はプログラムまたはステージツリー上で定義されている必要がありま

す。また、各変数にコメント文をつけることもできます（3.1.2節を参照）。コメントをつ

けることにより、他の実験者にもプログラムがより分かりやすくなります。

割り当て構文の例:

　 p = 20;

　 Q = q1 + q2;

　 Profit = Endowment -Contribution + EfficiencyFactor * SumC/N;

　 Cost = exp(Effort /k );

21

globals テーブルに含まれるレコードは 1つだけでしたが、他のテーブルは複数のレ

コードを含んでいることがあります。プログラムがそのような（複数のレコードを含む）

テーブル中で実行される場合、プログラムが実行されているレコードが常にひとつありま

す。このレコードはカレントレコード (current record)と呼ばれます。これにより、レコー

ド番号ごとに添字をつけることを省略できます。例として、定義済みの subjects テー

ブルを考えます。このテーブルは、1人の被験者当たり 1つのレコードを含んでいます。

subjectsテーブルのプログラムは被験者ごと、つまりレコードごとに別々に実行されま

す。したがってプログラムの実行中はテーブルおよびレコードは固定されており、プログ

ラム内の特定のセルは特定の変数によって決定されます。分かりやすく例を示します。3

人の被験者がいるトリートメントを考えます。変数 gの値は 5、12および 7です。下記

のプログラムを考えてみます:

　 M = 20;

　 x = M - g;

プログラムは subjectsテーブルの各行ごとに実行されます。まず最初に第 1行が実行

されます：変数 Mおよび xが定義され、第 1行における Mおよび xの値が決定されます。

　 g g M x

　 5 -> 5 20 15

　 　 　 12 12

　 　 　 7 7

次にプログラムは第２行目で実行されます。2行目の Mおよび xの値が得られます。

　 g M x g M x

　 5 20 15 5 20 15

　 12 -> 12 20 8

　 7 7

最後に、プログラムが第 3行で実行されると第 3行の Mおよび xの値が得られます:

　 g M x g M x

　 5 20 15 5 20 15

　 12 20 8 12 20 8

　 7 -> 7 20 13

22

この例において、空白のセルは未確定の値を示します。ユーザー自身は変数に未確定の

値を使用できません。プログラムがテーブルのすべてのレコードについて実行されると

(一般にはそうなります)、最後には未確定のセルは残りません。計算はレコードごとに実

行されるものであり、ステートメントごとに実行されるわけではないことに注意して下さ

い。したがって、最初の 2人の xの値を計算しているときには最後の被験者にとっての M

の値はまだ未確定となっています。

3.1.2 コメント

プログラムを容易に理解できるようにコメントを挿入することができます。/*と*/の

間、および//から行の最後までのテキストはコメントとして扱われ、プログラムの実行

には関係しません。つまり、プログラムが実行されるとき、この部分のテキストは無視さ

れます。次の例ではそれぞれの割り当て構文が特殊な形式を持っている理由について、コ

メントを用いて説明しています。

コメントの例：

　 a = 1; // initialize

　 b = sum( /*cos(x*x+) */ a);

　//there is an error in the expression in the second line;

　//therefore we put questionable parts into a comment to

　//localize the error

注 : /*と */を備えたコメントはネスト（入れ子）されません。/*の後に最初に現れる

*/によってコメントは終了します。下記プログラムはしたがってエラーとなります:

コメントの例：

　/* discard the following lines by putting them into a comment

　 a /* first variable */ =1;

　 b = 2;

　*/

また、エラーを見つけるためにコメントを使用することもできます。間違っているス

テートメントを見つけるために、エラー・メッセージが出なくなるまで、疑わしい行をコ

メントに変えることができます。エラー修正後、コメントを削除することもできます。

23

3.1.3 簡単な実験の流れ

1つのトリートメントは多くのピリオド (periods)で構成されます。トリートメントを

実行するときにはこのピリオドの数をあらかじめ決めておきます。それぞれのピリオドは

複数のステージ (stages)を含みます。各ステージは 2つの画面 (screen)を含んでおり、そ

のステージにいる被験者に表示されます。まず第 1の画面として active screenが表示さ

れます。active screenでは被験者が情報を見たり入力をすることができます。あるステー

ジの active screenが示されている場合、被験者がそのステージでアクティブな状態 (active

state)であると言います。データが入力された場合、または制限時間が過ぎた場合には被

験者はそのステージの待機状態 (waiting state)に移り、このステージの第 2番目の画面で

ある waiting screenが表示されます。被験者は待機状態から次のステージに移ることが

できます。通常、被験者がすべて待機状態に達した場合に次のステージへ移行します。各

ステージの初めにはプログラム (programs)で定義された計算が実行されます。

ステージツリーの Bエレメントは特定のステージだけのものではない情報を

含んでいます。B ダイアログボックスでは、例えばピリオドの数や被験者の数

などを設定します。そのため Bは、トリートメントの中で使用されるテーブル

のリストを含んでいます。B はテーブルの後に、プログラムを入れる事も可能

で、それらは各ピリオドの初めに実行されます。B の active screenに含まれて

いるエレメントは各ステージの active screenに挿入されます (レイアウトについては 3.4

章も参照のこと)。例えば現在のピリオド数や残り時間を示すヘッダはすべてのステージ

で表示される場合が多くなりますが、Bの active screenにこのヘッダを挿入す

れば、（各ステージの active screenすべてにヘッダを挿入しなくても）すべてのステージ

でこのヘッダが表示されます。また B の waiting screenに含まれているエレメ

ントは各ステージの waiting screenに挿入されます。大抵の場合 waiting screenは「しば

らくお待ち下さい」などのメッセージを表示するだけです。この場合このメッセージは

B で定義しておき、各ステージの waiting screenは空にしておくことができま

す。次の図 3.16では、2つのステージを備えた例を使って Bのエレメントとス

テージのエレメントの関係を示します。

3.1.4 ステージツリー

トリートメントのステージは、ステージツリー (stage tree)と呼ばれるツリー形式の図

で記述されます。前述の図 2.9は、公共財ゲームのステージツリーを示します。トリート

メントのエレメントはすべて、この図の中で階層的に表示されます : ステージはプログラ

24

Figure 3.3 各ステージは 0もしくは複数のプログラムから始まり、その後 active

screenおよび waiting screenが表示される。　 Bは、すべてのステージに

挿入されるテーブル、ピリオドの初めに実行されるプログラムおよびスクリーンエ

レメントのリストを含む。

ムとスクリーンを、スクリーンはボックス、ボックスはアイテムを含んでいます。トリー

トメントの概要を把握しやすくするために下の階層は表示/非表示が切り替えられます。

ダブルクリックによって、エレメントのパラメータを見たり変更したりすることができま

す。また、エレメントは移動やコピーが可能です。メニュー・コマンドで新しいエレメン

トを挿入することもできます。新しいエレメントは、選択されたエレメントと同階層の後

ろの位置、または選択されたエレメント内の最初の位置に置かれます。つまり新しいス

テージを挿入するためにはその前のステージを選択する必要があります。例えば W

エレメントを選択すると、スクリーンと同じあるいは低い階層にはステージを置く

ことができないので、新しいステージを挿入することができません。

ステージツリーの関係には 2種類の「中で」(in)の関係があります。ステージツリーエ

レメント xは他のエレメント yを含むことができます。つまり、エレメント yはエレメン

ト xの内に置かれます。一方、エレメント xをダブルクリックすると表示されるパラメー

25

タもまた xの内にあります。エレメントをダブルクリックするとそれらを見つけることが

できます。この違いをより明確にするために、「内」(within) という表現をエレメント間

の関係のみに使用し、パラメータには用いないことにします。つまり、「そのエレメント

yは xの内 (within)にあります。」のように表記します。パラメータについては、「の中で

(in)」の隠喩は使いません。使用するとしても「パラメータ xはダイアログボックス xの

内部 (within)で定義された。」というように使います。

3.1.5 データの表示と入力

スクリーン・レイアウト (screen layout)は、どのデータが画面に表示されるか、また被

験者がどのデータを入力するのかを決定します。スクリーンはボックスという長方形の

エリアによって構築されます。ボックスはいくつか種類がありますが、本章では スタン

ダードボックス（standard box）のみを説明します。スタンダードボックスは中にアイテ

ム (item)を置くことができるので、特に重要になります。アイテムはテーブルからの入

力の表示を可能にするステージツリーエレメントです。アイテムダイアログボックスは、

テキストを入力することができるラベルフィールド (label field)を含んでいます。変数

フィールド (variable field)へは変数の名前を入力します。スタンダードボックスがアイテ

ムを含んでいる場合、 (被験者のレコード中の) 変数の値が表示されます。この値にはラ

ベルフィールドのテキストがラベルとして付加されます。レイアウトフィールド（layout

field）では変数の表示方法を定義します。例えば、数 12は 12とも、12.00とも表示する

ことができます。レイアウトフィールドへは変数を表示する桁数を書きます。例えば、１

と入力すれば 12と、.01と入力すれば 12.00と表示されます。スタンダードボックスの

中でアイテムはリスト形式で表示されます。ラベルは右揃えで変数の値の左側に表示され

ます。また、空のアイテム (ラベルと変数のないアイテム)を挿入することで、縦方向のス

ペース（1行空白）を作ることができます。

被験者に数値や選択肢を入力をさせたい場合にもアイテムを作成します。入力が必要

であることを宣言するために、入力（Input）チェックボックスをチェックします。この

アイテムを入力アイテム (input item)と呼びます。他のアイテムは出力アイテム (output

item)と呼びます。変数フィールド (Variable field)に入力された名前は subjectsテーブ

ル中の変数の名前になります。入力アイテムは変数の定義も兼ねているため、この変数

をあらかじめ定義しておく必要はありません。入力チェックボックスをチェックすると、

追加のフィールドがアイテムダイアログボックスに現われます。最小（Minimum）と最

大 (Maximum)のフィールドで、被験者が入力する値の下限と上限を決定します。レイア

ウトフィールドで、数の桁数を入力します。被験者によって入力された数がレイアウト

26

フィールドに入力された値の倍数でない場合、あるいは値が上限と下限の間にない場合、

エラー・メッセージが被験者のスクリーンに表示されます。図 3.17は、入力アイテムの

ダイアログボックスを示します。このアイテムは、被験者のスクリーン上にフィールドを

表示します。このフィールドに被験者は数を入力することになります。入力値は 0と 12

の間で 0.1の倍数でなくてはなりません。例えば 4.8は入力できますが、−2、15あるいは

4.55を入力することはできません。

Figure 3.4 入力アイテムのダイアログボックス　被験者によって入力された値は、

0～12で.1の倍数でなくてはならない。

スタンダードボックスの最後に、ボタン (BUTTON)エレメントを置くことができます。

その場合、ボタンは被験者のスクリーンのスタンダードボックスに表示されます。被験者

がボタンを押すと、最初に入力アイテムに必要な条件がすべて満たされるかどうかチェッ

クされ、問題が無ければ、そのステージは終了します。

3.1.6 変数 Profitおよび TotalProfit

ほとんどの経済実験では被験者の実験中の意思決定にもとづいて報酬が支払われます。

z-Treeでは、被験者の所得の記録は自動で行われます。注意すべき点は、ピリオドの終了

時に変数 Profitにそのピリオドで稼いだポイントが入っているようにすることです (ポイ

ントは実験の通貨単位です)。ピリオドの開始時には、Profitは常に 0に設定されます。し

たがって、あなたが変数を変更しなければ、被験者は何も得られません。トリートメント

中に、Profitは変数 TotalProfitに加算されます。TotalProfitは、このトリートメントにお

27

けるすべてのピリオドの Profitの合計です。Profitと TotalProfitは subjectsテーブル中の

変数であり、それらの値を表示することもできます。ただし TotalProfitの値を変更しては

なりません。

トリートメントの終わりに、TotalProfit の値は現地通貨単位に変換されます。デフォ

ルトの交換レートは 1です。これは B ダイアログボックスで変更できます。

全利益の合計を格納したファイルへのアクセス方法は第 5 章の “セッションの実行

(Conducting a Session)”で説明します。

3.1.7 例 : 計算練習 (guess sin.ztt)

練習 : 被験者は、ランダムに決められた値の sin関数を計算します。報酬は計算の正確

さに応じて支払われます。

解法 : 図の中のステージツリーで、この実験の解法を示します。入力と利益表示の 2つ

のステージがあります : 入力ステージでは被験者が関数値の推定をおこない、利益表示ス

テージでは利益とその他の情報が表示されます。

値 Xは 0と 1/2πの間の数で、小数点以下 3位の値 (.001の倍数)です。関数 random()

は、0と 1の間の一様分布の数を返します。pi()は 3.14159…で、roundは小数点以下 3位

で値を四捨五入します。

28

入力変数 Yは 0と 1の間でなくてはなりません。また、被験者は小数点以下 3位まで

の数字を入力します。これらの情報は入力アイテム Y のアイテムダイアログボックスに

入力されなければなりません。

支払い計算は簡単です。まず sin関数を計算します。被験者が入力できるのは有限の桁

数なので、それと同じ桁数に数字を丸めます。その後、その値と入力された値の間の差の

絶対値を計算します。最後にこのピリオドでの利益を計算します。

　 SinX = round( sin(X ), .001);

　 Diff = abs (SinX -Y );

　 Profit = 100 - 100 * Diff;

この情報は利益表示ステージの active screenで被験者に表示されます。

3.2 被験者間に相互作用のある実験：対称なゲーム

前章では、個人の意思決定問題のためのトリートメントの作成を説明しました。本節で

は、被験者間に相互作用のある実験のトリートメントを作成する方法を説明します。個人

の意思決定問題と被験者間に相互作用のあるゲームは、利得が他の被験者の意思決定にも

依存する点が異なります。この違いは z-Treeにおいて現在計算している行から他の行の

中のセルにアクセスする手段が必要になることを意味します。テーブル関数はまさにその

ためにあります。

たいていの被験者実験は、２つ以上のグループで行われます。例えば公共財実験をする

ために 24人の被験者を 1グループ 4人に分けると 6つのグループになります。z-Treeで

は、このグループマッチング（誰と誰を 1つのグループに入れるか）の設定は簡単かつ柔

軟に設定できます。本節では、グループ分けプログラム作成の初歩を説明します。

3.2.1 テーブル関数 (Table functions)

公共財実験では、あるグループのメンバー全てによる寄付 (contribution)を合計する必

要があります。これまでの記述では現時点 (z-Treeが計算している被験者の) におけるレ

コード (record)のみを参照していました。しかし、グループメンバーの寄付を合計するに

は、テーブル全体に対して計算する必要があります。z-Treeではこうした計算をテーブル

関数 (table functions)と呼びます。例えば、gがあるメンバーの寄付を示す変数ならば、

S = sum( g );

29

が新しい変数 Sをメンバー全ての寄付の合計として定義します。ここで用いる変数 gは、

もはや Sと同じレコードに属しません（Sが現在のレコードであるのに対して、gは全レ

コード上の gを指します）。もし i を現在のレコードの数とすると、先の表現を数学的に

書くとSi =

∑

j

g j

となります。ただし、 j は全てのレコードに対してループします。もちろん、テーブル

関数の引数に expressionを使うこともできます。この expressionはテーブルの全てのレ

コードに対して計算され、結果がテーブル関数 sumに返されます。ですから、以下のプロ

グラム

x = sum( cos ( a*b ) );

は数学的にはxi =

∑

j

cos(a j ∗ b j)

を意味します。

全てのテーブル関数の第 1引数には条件文を挿入することができます。z-Treeは全て

のレコードに対して、この条件文を評価し、条件を満たすレコードのみにテーブル関数を

実行します。例えば、

z = average( x>0, y );

では、変数 xが正の値になっている被験者の変数 yの平均を計算します。

また find関数を使うことで、別のレコードにおけるセルの値を探すことができます。

v = find( b==12, c+e );

では、まず変数 bが 12の値となるレコードを探します。この条件を満たす最初のレコー

ドに対して、c+eの値を計算し、現在のレコード (current record)における変数 vに割り

当てます。

3.2.2 他のテーブルにおけるテーブル関数

テーブル関数は他のテーブルがもつ変数に対しても実行できます。テーブル関数の前に

単にテーブルの名前とドットをつけるだけで実行可能です。例えば、全ての被験者の利益

を平均して globalsテーブルに保存するなら、globalsテーブルのプログラム中に以下

のように書きます：

30

avProfit = subjects.average( Profit );

3.2.3 スコープオペレータ

次の式を計算するとします。

xi =∑

j

cos(ai ∗ b j).

これは第 3.2.1節にあった式と同じですが、b j のあるレコードの a でなく、xi のあるレ

コードの変数 a を使う点で異なります。これを表現するためには a の前にコロンをつけ

ます。このコロンはスコープオペレータ (scope operator)と呼ばれます。

x = sum( :a * b );

変数 aが 2, 4, 8で変数 bが 5, 12, 7である 3つのレコードを備えたテーブルを考えます。

次のプログラムの実行後に、テーブルには下に示す値をもちます。

c = sum( a * b );

d = sum( :a * b );

e = sum( :a * :b );

a b c=sum(a*b); d=sum(:a*b); c=sum(:a*:b);

2 5 10+48+56=114 10+24+14= 48 10+10+10=30

4 12 10+48+56=114 20+48+28= 96 48+48+ 48=144

8 7 10+48+56=114 40+96+56=192 56+56+ 56=168

スコープオペレータが直観的に意味するところは、テーブル関数を別のテーブルで実行

することです。テーブル Aおよび Bが変数 vをもつときのテーブル Aにおける B.sum(v)

を考えます。この表現における vは、テーブル Bがもつ変数 vになります。ここでテー

ブル Aがもつ変数 vにアクセスするときに、スコープオペレータが必要になります。テー

ブル Aと Bが異なるテーブルであるので、スコープオペレータは現在のレコードがどこを

指すかを明確にします。例えば、テーブル関数の外側からみると、テーブル Aにおける現

在のレコードを指します。また、関数 sumの内側からみると、合計を計算しているときの

現在のレコード、すなわちテーブル Bにおける現在のレコードを指します。にもかかわら

ず、スコープオペレータを使うことで sum 関数の内部からテーブル Aがもつ変数にアク

セス可能になります。

31

ここまでは、2つのテーブルに 1つのレコードしかもっていないかのようにテーブル関

数を説明してきました。しかし、当然テーブルが 1つ以上のレコードを含む場合も同じ考

え方が使えます。

ある式を計算するときは、z-Treeは現在のレコードを固定します。あるテーブル関数を

実行するときは、そのテーブルがもつ全てのレコードに対して、z-Treeは式を計算しま

す。ステップ毎に残りの他のレコードが現在のレコードになります。そしてスコープオペ

レータを使うことで、「古い」現在のレコードすなわちテーブル関数の外にあるレコード

がもつ変数を参照できます。このように、スコープオペレータはアクセス可能なセル範囲

を広げてくれます。

あるテーブル関数を別のテーブル関数内で実行するとき、このテーブル関数は、3つの

レコードにアクセス可能なテーブル関数の表現となります。では、3つのテーブル A、B

および C のそれぞれが変数 v をもつ場合を次の式で考えて見ましょう。この積表現の括

弧内の vはテーブル Cの現在のレコードがもつ変数です。「スコープされた (scoped)」変

数:vはテーブル Bがもつ変数となります。さらに、2つのスコープオペレータを重ねた

::vは、テーブル Aの現在のレコードにおける値に相当します。次の表現の下の行には、

どの vが使用されているかを明示しています。

x = v + B.sum( v * :v - C.product ( v－:v－::v) )

A B　 A　　　　 C 　 B　 A

この例ではすべてのテーブルが変数 vをもちます。しかし、変数が 1つのテーブルにしか

ない場合もあります。この場合はスコープオペレータを省略してかまいません。例えば、

テーブル Aのみが変数 aをもち、テーブル Bのみが変数 bをもち、テーブル Cのみが変

数 cをもつ場合、次の２つの表現は同じ結果になります：

x = a + B.sum( b * :a - C.product( c - :b - ::a ) )

x = a + B.sum( b * a - C.product( c - b - a ) )

しかし、スコープオペレータを使用しない場合注意してください。変数 a をテーブル

C上に定義すると、2番目の expressionにおける積はテーブル A がもつ変数 aではなく、

テーブル Cがもつ変数 aを使用します。

3.2.4 自分自身のグループメンバーへのテーブル関数の使用制限

スコープオペレータは一般的に、被験者が所属するグループのメンバーに限定してテー

ブル関数を実行するために使用します。変数 Group はそのグループを示す ID をもちま

32

す。例えば、第 1グループには 1、第 2グループには 2が割り当てられます。実際の実験

では、一般に被験者間の相互作用はグループ内に限定します。すなわち、テーブル関数の

実行をメンバーのグループ内に制限します。例えば、ある被験者自身のグループ変数 gを

合計するとしましょう。グループが最大で 4つ、つまりグループ 1, 2, 3および 4が存在

するならば、スコープオペレータを使わずに sを計算できます：

s = if( Group == 1, sum( Group == 1, g),

if( Group == 2, sum( Group == 2, g),

if( Group == 3, sum( Group == 3, g), sum(Group == 4, g))));

この表現は複雑で間違えやすく、かつ一般的でありません。さらにグループ数が 4を越

えると、この表現は使えません。スコープオペレータは、この種の計算を単純化してくれ

ます。次の表現は、その被験者が所属しているグループにおける gを全て合計します。

s = sum(Group == :Group, g);

このプログラムは以下の意味をもちます：「(私の)sは私と同じグループに属する被験者が

もつ gの合計です。」多くの場合、スコープオペレータは「私の」という意味に解釈でき

ます。しかし、正しい直観的な理解を述べると、スコープオペレータは sの前にある「私

の」を意味します。スコープオペレータは、現在計算している sを含むレコードを参照し

ます。このようにスコープオペレータが必要になるのは、テーブル関数にある gが属して

いるレコードがもつセルではなく、現在計算している sが属しているレコードがもつセル

にアクセスする場合です。

被験者自身が所属するグループに対するテーブル関数の実行は非常によく行われるた

め、その計算のために関数 sameを用意しています。same(x)は x==:xの省略表現です。

したがって、先ほどの表現は次のように書きかえることができます：

s = sum( same( Group ), g );

この関数を使うことで、スコープオペレータは見えなくなります。あなたがプログラム

を直観的に理解するためにスコープオペレータを詳細に理解する必要はありません。しか

し、あなたが自分でプログラムを書くときにはスコープオペレータに対する深い理解が重

要になります。

33

3.2.5 グループマッチングの基本

Treatment メニューには matching アイテムがあります。ここでグループマッチング

の形式をパートナーもしくはストレンジャーに設定できます。パートナーマッチングは固

定マッチングであり、最初のプレイヤはグループ 1、次のプレイヤはグループ 2...を構成

します。ストレンジャーマッチングはランダムマッチングであり、すべてのピリオドにお

いて、グループはコンピュータの乱数から決定します。Treatment メニューからグループ

マッチングを設定し、変数 Group を固定します。そして、被験者の数やグループの数を

変更するときはコマンドを必ずもう一度実行しなければなりません。第 3.3.3節で述べる

パラメータテーブル (parameter table)でもっと柔軟なグループマッチングを説明します。

3.2.6 要約統計量 (summary statistics)

ここまで説明してきたテーブルは、各ピリオドの終了後に再初期化されます (もちろん

データをディスクに保存した後で)。実験室の実験者から見ると、それらのデータはスク

リーンから消えます。一連の実験結果を把握するのには summaryテーブルを使用すると

よいでしょう。summaryテーブルは、1ピリオドに 1つのレコードを含みます。しかし、

1ピリオド終了時にそのレコードは再初期化されることはなく、トリートメントが終了す

るまで初期化されません。

あなたが summaryテーブルにおいてプログラムを実行する場合、そのプログラムは現

在のレコードのために実行されるだけです。*2次の例を見てみましょう：

AvProfit = subjects.average( Profit );

summary テーブルにおいてこのプログラムを実行すると、各ピリオドにおいて変数

AvProfitが計算され、summaryテーブルを開くと、そのトリートメントで計算された平

均利益を確認できます。

3.2.7 例：推測ゲーム (Guessing game)

実験：ピリオドの開始とともに被験者は 0と 100の間の数を入力しなければなりませ

ん。入力されたすべての数の平均の 2/3に一番近い値を入力した被験者が勝者となり、50

点を獲得します。引き分けのときは、勝者の間で点数を等分します。

*2 しかし、あなたがテーブル関数もしくは do 命令を用いる場合、そのプログラムは全てのレコードに対して実行されます。もしあなたがプログラムの実行範囲を現在のピリオドに限定したいなら、条件same(Period)を加える必要があります。

34

このトリートメントは以下のステージツリーで構成します：通常 Bに各種の

定数を定義します。第 1ステージでは、被験者が自身の推測を入力します。続いて第 2ス

テージでは、入力結果を計算します。では、計算の各ステップについて説明しましょう：

グループ平均を計算するにはテーブル関数 averageを使用します。

GroupAverage = average( same(Group), Guess );

推測するべき値 TargetValue は単に入力の平均に 2/3 (Factor) をかけた値となり

ます。

TargetValue = GroupAverage * Factor;

各被験者がもつ「差」は推測するべき値と推測との差の絶対値となります。

Diff = abs( Guess - TargetValue );

最も小さな「差」を BestDiffとします。これは「差」の最小値です。

BestDiff = minimum( same(Group), Diff );

このテーブル関数は新しいプログラム（スパナ型のアイコンで示されるステージツリー

上のエレメント）を先のプログラムの下に挿入してそこに配置しなくてはなりません。プ

ログラムは各列に対して実行されます。したがって Diffの計算プログラムと同じ場所に

BestDiffの計算を入れてしまうと、そのテーブルにおける残りのレコードの Diffの値が

分からないため BestDiffが正確に計算できなくなります。通常では、設定されない空の

35

値は 0になっています。このため、最後に計算される被験者以外の BestDiffは 0になっ

てしまいます。このような場合新しくプログラムを作成し（プログラムのエレメントをス

テージツリー上に新たに挿入し）、そこに BestDiff の計算を入れることでうまくいきま

す。まず、第 1のプログラムが全てのレコード (被験者のデータ)を計算します。その後、

第 2のプログラムも全てのレコードを計算します。この際全てのレコードの Diffが計算

されます。

次のステートメントで、勝利者 (達)を決定します。最も「推測すべき値」に近い被験者

がもつ変数 IsWinnerに 1を設定し、そうでなければ 0を設定します。

IsWinner = if( Diff == BestDiff, 1, 0 );

この if関数は 3つの引数をとります。第 1の引数は条件です：Diff==BestDiff。こ

の条件が満たされる場合、すなわち 1が結果として返るとき、第 2の引数が if 関数の結

果になります。一方で、条件が満たされない場合、すなわち 0が返るとき、第 3の引数が

if 関数の結果になります。次に、引き分けに対処するため勝利者の数を計算します。テー

ブル関数 sumでは、先のプログラムの中で計算する値を使用するため、新しいプログラム

に以下のステートメントを入れる必要があります。

NumWinners = sum( same(Group), IsWinner );

最後に利益を計算します。勝てなかった被験者 (IsWinner=0)の利益は 0になります。

いっぽう勝利した被験者 (IsWinner=1)の利益は Prize*1/NumWinnersです。

Profit = Prize * IsWinner / NumWinners;

3.2.8 順位に依存して支払額が変動する例 (Rank dependent payment)

実験：被験者は例 3.1.7と同様、数学的関数の値を推測しなければなりません。被験者

への支払いは、他の参加者と比べてどれだけ良くできたかで決定します。第 1位のプレ

イヤはグループメンバーの数から 1点を引いた点を獲得します。第 2位のプレイヤは第 1

位のプレイヤの得点からさらに 1点を引いた点を獲得します。同様に続けていくことで、

最後のプレイヤの得点は 0になります。最後にコスト中立引き分けルール (a cost neutral

tie rule)を適用します。例えば、第 2位に 2人のプレイヤがいる場合、2人の順位の平均

ランク 2.5にもとづいて 2人の得点を決定します。次のテーブルに例を示します。第 1ラ

インに順位の例を並べます。第 2ラインには同じ順位となるグループのプレイヤから最後

36

の順位を割り当て、コスト中立引き分けルールを適用したときの順位を示します。最後の

ラインは利益（得点）となります。

Rank 1 2 3 4 4 4 7 8 9 9

Bad Rank 1 3 3 6 6 6 7 8 10 10

Payment 9 7.5 7.5 5 5 5 3 2 .5 .5

利益表示ステージ (profit dislay stage)のみが例 3.1.7とは異なるので、このステージだ

けを次の図に示します。この第 2のプログラムはこのトリートメントで新しく登場したプ

ログラムです。変数 Diffを使用するテーブル関数を計算するため、このプログラム中の

ステートメントを前のプログラムに入れることができません (前節を参照してください)。

では、このプログラムを 1つずつ説明していきます。

Rank = count( same(Group) & Diff < :Diff ) + 1;

この行でランク (rank)を計算します。ランクは自分よりよい推測をしたプレイヤの数に

相当します。これは条件 Diff <: Diff で表現しています。テーブル関数 count は次

のように解釈します：「自分のグループ内で Diffが自分の Diffより小さいプレイヤの数

を数える。」どのプレイヤも自分より小さい Diff を持たなければ、自分が 1位になるの

で 1を加えています。

37

BadRank = count( same( Group ) & Diff <= :Diff);

このステートメントでは、自分と同じか自分よりよい成績のプレイヤの数を数えます。こ

れは「不親切な」引き分けルールによるランク付けに相当します。

N = count ( same(Group) );

このステートメントは、単にグループ中のプレイヤの数を数えています。

Profit = N - ( Rank + BadRank ) / 2;

上のように 2つのランクを計算すると、その平均が適切なランクになります。被験者への

支払いはこの中で計算した平均ランクから決まります。

3.3 非対称・同時手番ゲーム

前章で説明した実験では、すべての被験者は同じパラメータを持っていましたが、本

章では各被験者に異なるパラメータを与える方法を説明します。それには 2つの方法が

あり、1つ目は if 関数とステートメントを使って条件により代入する方法で、2つ目は

Parameter tableを使用する方法です。

3.3.1 条件付き実行

z-Treeではプログラム内のパラメータの値によって、条件分岐させることが可能です。

これは、条件（condition）によって実現できます。条件は数値ではなく論理値（TRUEか

FALSE）で判断されます。例えば、g>=hという条件を考えます。変数 gの値が変数 hの

値と等しい、もしくはそれより大きいならば、条件は TRUEとなります。また m==nとい

う条件では、変数 mと変数 nの値が等しい時、TRUEとなります。ただし、代入のステー

トメントでのイコール（=）と異なり、条件におけるイコールは ==のように 2つ続けて並

べる必要がありますので注意してください。

条件は変数に直接代入することはできませんが、式の中で使用することができます。つ

まり、

if( c, x, y )

という表現（expression）で、条件付きの計算が行われます。ここで、xと yは通常の表

現で、cが条件です。cが TRUE（真）であれば、この ifを使った表現は xの値を返し、

38

そうでなければ yの値を返します。さらに、xと yは任意の表現でありうるので、それら

に if関数を使うことができます。

この場合、if 関数が入れ子にされる (ネストされる) といいます (もちろんどんな種類

の関数も入れ子にできます)。　次の表現は両方のプレイヤが 1あるいは 2のいずれかを

選ぶことができる 2人ゲームのの利潤関数を計算するネストされた if 関数を示します。

Profit11、Profit12、Profit21および Profit22が、被験者の支払いマトリックスを

記述します。たとえば Profit21は被験者が 2を選び、対戦相手の被験者が 1を選ぶ場合

の被験者用の支払いの定数です。

Profit = if(Decision == 1,

if(OthersDecision == 1, Profit11, Profit12 ),

if(OthersDecision == 1, Profit21, Profit22 ));

条件を計算して、将来使用するためにそれを残しておきたければ、通常の変数にそれを

格納しなければなりません。この場合、TRUEが 1、FALSEが 0を意味します。

if関数の代わりに、同じ機能を持つ ifステートメントも利用できます。それは次の構

文になります。

if(condition ) {

statements1

}

あるいは

if(condition ) {

statements1

}

else {

statements2

}

です。

条件が TRUE の場合、1 つ目の括弧の中のステートメントがすべて実行されます

(statements1)。第 1のケースでは、条件が FALSEの場合何も起こりませんが、第 2のケー

スでは else の後の括弧の中のすべてのステートメント (statements2)が実行されます。

if関数を使った代入のステートメントは、ifステートメントを使って全く同じことを記

述できます。例えば、

39

z = if( c, x, y );

は

if (c) {

z=x;

}

else {

z=y;

}

と同じです。

この例において、if ステートメントを用いた後者の形式は、少し複雑です。しかし一

つの条件下でいくつかの式を実行する場合には適した形式です。例えば、完全に異なる支

払い関数を持つ異なるタイプのプレイヤがいる場合などがそれです。

3.3.2 被験者ごとに異なる値の計算

z-Treeが定義する Period および Subject と呼ばれる変数があります。Period は現

在のピリオドを表します。最初のピリオドでは 1です。変数 Periodはすべてのテーブル

(lifetimeピリオドで) に定義されます。変数 Subject は subjects tableで定義されます。

それは第 1のレコードには 1、第 2レコードには 2となります。つまり、変数 Subjectは

各被験者を識別することを可能にします。

これらの変数の使用により被験者特有あるいはピリオド特有の変数を定義することがで

きます:

if( Period== 1 &Subject ==1 ) {

p=11;

}

if( Period== 1 &Subject ==2 ) {

p=12;

}

...

被験者をこのように特定するやり方はやや面倒です。そこで Parameter tableという別

の方法が用意されています。

40

3.3.3 Parameter table

各トリートメントにはステージツリーに加えて、被験者固有の変数を簡単に管理でき

る Paremeter tableがあります。このテーブルでは、ピリオドは行、被験者は列で与えられ

ます。

Figure 3.5 Parameter table

被験者は S1などと命名されます。また、ピリオドには番号が打たれます。練習ピリオ

ドには「Trial」が前につきます。テーブルのセルをクリックすると、プログラムを入力で

きるダイアログボックスが開きます。

これらのプログラムは、対応しているピリオドと被験者に対して実行されます。例え

ば、セル S2の中のプログラムはいつでも（毎ピリオド）被験者 2に対して実行されます。

これは、サブジェクトテーブル中の第 2列に対し、どのピリオドでもこのプログラムが実

行されることを意味します。このセルでは、Role parametersを定義します。セル Fに含

まれていたプログラムも、被験者 2のために実行されますが、それは最初のピリオドでの

み実行されます。このセルでは、Specific parametersを定義します。一番左の列の中の

プログラムは globals table中で実行されます。それは、すべての被験者に対して同じであ

る (しかしピリオドによって異なる)パラメータを定義します。例えば１のラベル内のプ

ログラムは全ての被験者に対して最初のピリオドでのみ実行されます。つまりこのセルで

は、Period parametersを定義します。

Parameter table中のプログラムは、メニュー「Treatment」からコマンド「Info...」を選

択、あるいはテーブル中の該当するフィールドをダブルクリックすることで、確認したり

変更したりできます。セルはコピー/ペーストで、あるいはクリックで選択して別のフィー

ルドまでドラッグすることでコピーすることができます。

41

Specific parametersの各セルの上部の左隅に数字が表示されています。これはグループ

番号です。この数字は、セルのダイアログボックスで、あるいはメニュー中のマッチング

手続きの適用により修正することができます。

Parameter tableでは変数を定義することができず、変更することだけができます。これ

は、Parameter tableだけで定義された変数はステージツリーに認識されないことを意味し

ます。Parameter tableで変数を定義してそれをステージツリーのプログラムで利用しよう

とすると、その変数が未定義であることを知らせるエラーメッセージが出ます。ステージ

ツリーの Bの中のプログラム中でそれらを初期化しなければなりません。これ

によって、その変数が Parameter tableのすべてのセルに定義されていなくても、デフォ

ルト値を常に持つことが保証されます。ピリオドの初めに、データベースが以下のように

セットアップされるので、Bの中で割り当てられる値は Parameter tableでは無

視されます:

1. Period, Subject, Group等の標準の変数の設定

2. Bのプログラムの実行

3. subjects tableにおける (現在のピリオドでの) subjectプログラムの実行

4. subjects tableにおける Roleプログラムの実行

5. globals tableにおける Periodプログラムの実行

6. 最初のステージのプログラムの実行

例: 異なるタイプの被験者 1 および 2 がいると仮定しましょう。この場合、最初に

Bで変数に対するデフォルト値を定義します。例えば

Type=0;

とします。(すべてのセルの中で変数を再定義するのであれば、適切でない値をここで使

用してもかまいません。) その後、値を変更したいフィールドでダブルクリックします。

出てきたダイアログボックスでは、タイプを表わす名前をこのセルで定義し直します。つ

まり、下記のような値が変更されるプログラムを入力します。例えば:

Type=1;

ということを、Parameter tableの必要なセルに書き込みます。

注意: 数字でなく分かりやすい変数を可能な限り使うといいでしょう。公共財ゲームで

は、初期賦存の値として 20を代入した Endowment変数を定義しましたが、これにより

42

プログラムの理解や変更が容易になります。また、異なるタイプのプレイヤーを識別する

値が必要な場合、globals tableにタイプを表す名前が付いた変数を定義することが望まし

いでしょう。例えば、提案者と応答者がいる実験ならば、次のように定義することができ

ます:

PROPOSERTYPE=1;

RESPONDERTYPE=2;

とすると、提案者のタイプを（Parameter table内で）次のように定義することができます:

Type=PROPOSERTYPE;

3.3.4 パラメータのインポート

パラメータがすべてのピリオドおよび被験者で異なる場合、該当するフィールドをダ

ブルクリックし、Parameter tableのすべてのセルにプログラムを入力するのは非現実的で

す。代わりに、エディターなどを用いて tab区切りの表をセット・アップし、Treatment

メニューからコマンド Import Variable Table... でそれをインポートすることができま

す。このコマンドは Parameter tableがアクティブウインドウのときに利用可能です。こ

のコマンドを選ぶと、まずインポートしたい変数の名前を入力するダイアログボックスが

開きます。そこに変数名を入力します。ここではそれを MyVarとします。次に表を入力

したファイルを選ぶダイアログボックスが開きます。ファイルを選択すると読み込みが実

行されます。読み込んだデータは対応するセル内のプログラムとして追加されます。ただ

し読み込んだファイル内の対応する箇所が空である場合はセルも空のままです。たとえば

テーブル中の値が 45である場合、加えられるラインは次のとおりでしょう:

MyVar=45;

使用するのは数字に限定されません;インポートする表の中で変数名を使用してもかまい

ません (プログラムをインポートすることも可能です)。

3.3.5 グループマッチング

グループマッチングは変数 Groupによって決定されます。この変数はピリオドの始め

で他の標準の変数が初期化されるときに同時に初期化されます。その後それは Specific

parametersのセルの上部の左隅に値が表示されます。ダイアログボックスで、あるいはメ

ニューの Treatment ＞ Matching でこの値を修正することができます。例えば固定した

43

(パートナー) マッチングか入れ替え (ランダム) マッチングかを決められます。マッチン

グコマンドを適用する場合は常に、このコマンドは、Parameter table中の選択されたエリ

ア、あるいは何も選択されていない場合は全体の Parameter tableに適用されます。マッチ

ングコマンドは、直接 Parameter tableのセルの上部の左隅の数を修正します。トリート

メントで被験者やピリオドの数を変更しても、自動的にはマッチングに適用されません。

マッチングコマンドを再適用しなければなりません。

さらに、プログラム中で Group 変数を変更することができます。これは内生的なマッ

チングあるいは被験者の数に依存しないマッチングの定義を行なうことを可能にします。

3.3.6 例：一般的な 2×2ゲーム (game222)

この例題として、両性の戦いのゲームをプログラムします。ここでは任意の 2プレイヤ

の 2×2ゲームのために使用することができる形でプログラムします。

Figure 3.6 2×2ゲームのトリートメントの概要

この実験では、プレイヤはそれぞれ異なる役割を持っています。しかし、それらは単に

パラメータの違いによるものです。プレイヤは異なる支払い関数を持っています。これを

次のように実行します。まず利得のマトリックスを Bの中で、デフォルトとし

て定義します。変数 PiBCは当該プレイヤが Bの行動を選択して、相手プレイヤが Cの

行動を選択した場合の利得を表すとします。例えば Pi21は当該プレイヤが 2の行動を選

択、相手プレイヤが 1の行動を選択した時に得る利得となります。それぞれの被験者用の

実際のパラメータは、次の図の中で示されるように Parameter tableで定義します。

利得の計算をするためには、相手プレイヤの選択を知る必要があります。別のプレイ

44

Figure 3.7 各プレイヤの持つパラメータ

ヤの変数 Choiceが自分のレコードにないので、テーブル関数を適用しなければなりませ

ん。find関数はテーブルを通じて実行され、ある条件が満たされると直ちに入力を返し

ます。相手プレイヤのレコードでは、Group 変数は同じで、Subject 変数が異なるとい

う性質を持っています。相手の選択を知るには次のように記述します。

OthersChoice = find( same(Group ) & not( same( Subject)), Choice );

そして、得られる利得は次のようなネストされた if関数で計算されます。

Profit =

if (Choice == 1,

if (OthersChoice == 1, Pi11, Pi12),

if (OthersChoice == 1, Pi21, Pi22));

この支払い関数では、Parameter tableの中で定義された値が使用されます。

ここで生じた問題を解決する策は他にもあります。代替的な解法は次のようなもので

す:2つのタイプのプレイヤを表現するために、変数 Typeを定義します。その後、globals

tableに 2つの支払いマトリックスを定義します。Parameter tableでは、変数 Type の値

を設定します。2つのタイプを識別しなければならないので、利得計算はやや複雑になり

ます。

3.3.7 例：プログラム内でのグループの定義

3.3.5節の最後で少し述べましたが、マッチングもプログラムできます。固定マッチング

とランダムマッチングのためのサンプルプログラムをここで示します。変数 NumInGroup

45

を定義し、グループ 1つ当たりの被験者数が与えられているとします。Nを全体の被験者

数とすると、N=count();として人数を得ることができます。

パートナーマッチングに関しては、下記プログラムにより実現できます：

Group = rounddown( (Subject - 1) / NumInGroup, 1 ) + 1;

一方、ランダムマッチングは少し複雑です。まず、RandomOrderと呼ばれる「ランダ

ムの被験者変数」を作成します。各被験者はこの変数中の 1から Nの間の値のうちの 1つ

を任意に受け取ります。ここで下記のプログラムが必要になります:

RandomNumber = random();

RandomNumberは、0と 1の間の値が与えられます。非常に多くのランダム値を必要と

しない限り、それらはすべて異なると考えることができます。次のステートメントは新し

いプログラム（スパナアイコンの中）に置かなければなりません!

RandomOrder = count( RandomNumber >= :RandomNumber );

これは、被験者に割り当てられた乱数のランク（順位）を決定します。―この値がランダ

ムマッチングを行う際で重要となるのです。乱数は異なる値なので、タイ（引き分け）は

ありません。これで、次の式でマッチングを決定することができます:

Group = rounddown( (RandomOrder - 1) / NumInGroup, 1)+1;

したがって、Bに下図のようなプログラムを置くことで実現できます:

Figure 3.8 ランダムマッチングのプログラム

46

3.4 スクリーンレイアウト

ここまで、スタンダードボックスの中で入力アイテムを使ってできることや変数をどの

ように表示するかを説明してきました。本章では、もっと手の込んだレイアウトを可能に

する方法を説明します。たとえば「両性の戦い」ゲームで、プレイヤは「ボクシング」と

「オペラ」を選ぶことができます。上記の例では、被験者がそれらの選択に数値を入力し

なければなりませんでした。このセクションでは、どうすればテキスト入力、あるいはラ

ジオボタン、チェックボックス、スライダーのような形の入力が可能になるかを説明しま

す。さらに、スクリーンにどのように情報を表示し、表示をどのようにアレンジできるか

を示します。

3.4.1 小規模のレイアウト：アイテム

アイテムは変数を表示したり入力するために使用されます。アイテムは変数およびそれ

を表示する方法についての情報を含んでいます。チェックボックスで Inputがチェックさ

れている場合、アイテムを入力アイテムと呼びます。この場合、被験者は入力を行なわな

ければなりません。チェックボックス Inputがチェックされていない場合、アイテムを出

力アイテムを呼びます。この場合変数が表示されます。変数は常に数値を含んでいます。

数値は異なる形式で表示することができます。これらの形式は、アイテムダイアログボッ

クスのレイアウトフィールドに定義されます。数、変数あるいは式がここに入力されると

そのフィールドの値が表示される場合に変数がどのように丸められるかを定義します。例

えば、0.2がレイアウトに入力され、変数が値 52.31を含んでいる場合、52.4が 52.31に

最も近い.2の倍数であるので、52.4が表示されます。変数の値は、さらにテキストのため

のコードを含むことができます、例えば、上の例で、ボクシングが１、オペラが２を意味

するかもしれません。テキストレイアウトの使用により単語を表示することができます。

レイアウトフィールドで、次のようにテキストを入力します:

!text: 1 = "boxing" ; 2 = "opera" ;

感嘆符は、フィールドが単なる数 (あるいは数を表わす表現) を含まないことを示しま

す。textは出力の形式を表しています。それは変数の値に依存するテキスト「boxing」あ

るいは「opera」のうちの 1つを (”　”なしで)表示するように z-Leafに命じます。値が

1である場合「boxing」が表示され、値が 2である場合「opera」が表示されます (正確に

言えば、値が 2より１に近ければボクシングが、その逆ならオペラが表示されます)。text

47

とは別の方法もあります。radioオプションは、ラジオボタンを表示することを可能にし

ます。次のレイアウト

!radio: 1 = "boxing" ; 2 = "opera" ;

は「boxing」および「opera」のラベルが付いた 2つのラジオボタンを表示します。変

数の値によって、2つのラジオボタンのうちの 1つが選択されています。この種のレイ

アウトオプションも入力アイテムのために使用することができます。テキストレイアウ

トを備えた入力アイテムに対しては、テキスト形式でその入力をしなければなりません。

「boxing」が入力された場合、変数は 1の値を割り当てられます。「opera」が入力された

場合、変数は 2の値を割り当てられます。「わからない」や「BoXing」などが入力される

と、ある値だけが許容されるというエラーメッセージが現われます。radioオプションで

は、ボクシングおよびオペラのラベルがついた 2つのラジオボタンが表示されます。被験

者がボタンの選択をすると変数に対応する値が代入されます。

利用可能なオプションは次の通りです。:テキスト、ラジオボタン、ラジオボタンのライ

ン（横並びのラジオボタン）、チェックボックス、スライダー、水平のスクロールバーお

よび次表で示されるような押しボタン。押しボタンオプション以外のオプションはすべて

入力アイテムおよび出力アイテムとして使用することができます。(押しボタンオプショ

ンは選択されたか、されてないかのように異なった表示ができないので、入力アイテムと

してのみ利用できます。)　異なるオプションがどのようにプログラムされるかはリファ

レンスマニュアルの中で説明されます。

3.4.2 大規模のレイアウト:スクリーン設計およびボックス

実験では、被験者がコンピュータの前にいるのはせいぜい 1、2時間です。被験者はそ

の実験内容に不慣れなのが普通ですから、スクリーンはすばやく理解できるようわかりや

すくする必要があります。そのため、z-Treeのスクリーンレイアウトは比較的静的です。

スクリーンは、スクリーンに自由に置くことができるボックスと呼ばれる長方形のエリア

で構成されます。既出のスタンダードボックスに加えて、他のボックス (例えば説明用の

ヘルプボックス、当期および残りの決定時間に関する情報用のヘッダーボックス、以前の

ピリオドに関する情報を表示することができるヒストリボックス)があります。

このセクションでは、ボックスがスクリーンにどのように置かれるか最初に説明しま

す。その後、専門のボックスのうちのいくつかを説明します。

48

Figure 3.9 アイテムレイアウトの例

3.4.3 ボックスの配置

ボックスは、スクリーンに順番に置かれます。下の図に示されるように、サイズやマー

ジンへの距離によって、ボックスをどこにおくか決めることができます。サイズはスク

リーンピクセル (p)あるいはパーセントで与えることができます。

ボックスの配置は、常にいわゆる「残りボックス (remaining box)」との関係で決まり

ます。最初の状態では「残りボックス」はスクリーン全体です。その後、「残りボック

ス」はボックスの定義によって調節されます。したがって、例えばスクリーンの上にヘッ

ダーボックスを置き、このヘッダーボックスより下に他の残りボックスを置きたければ、

ヘッダーボックスと重ならないように残りボックスの上部分を切り取ることができます。

このためにはヘッダーボックスのダイアログボックスの Adjustment of the remaining box

49

フィールドのトップのチェックボックスをチェックします。これは、残りのボックスの上

端がヘッダーボックスの下端になることを意味します。

マージンへの幅、高さおよび距離はオプションです。どのフィールドに入力されたか

でそのボックスが残りボックスの中のどこにおかれるかが決まります。以下のグラフは、

幅 (W)、左のマージン (L) への距離および右のマージン (R)への距離のすべての場合の例

です。

ボックスの名前はドキュメンテーションだけのために使用されます。つまりプログラム

上の目印としてのみ機能し、プログラムの実行内容に影響しません。with Flameフィール

ドではボックスのまわりに線が引かれるかどうか定義します。別のボックスの上にフレー

ムのあるボックスをおくと、そのボックスは覆い隠されます。

次の図は 4つのボックスの定義および配置を示します。第 1のボックスはヘッダーボッ

クスです。トップのマージンからの距離は 0、高さ 10パーセントと定義しています。ボッ

クスの残りはこのボックスと交差してはなりません。したがって、remaining boxの top

にチェックします。すると画面上の上 10％を切り取った残りが「残りボックス」となり

ます。第 2のボックスは、残りボックスの上、左、下のマージンから 20ピクセルずつの

所に位置します。ここでは remaining boxにチェックしません。ですので remaining box

はまだ第 1のボックスで定義されたように、第 1のボックスより下の領域全部です。マー

ジンの設定が無ければボックスは remaining boxの中心に配置されるので、第 3のボック

スは第 1のボックスより下の領域の中心に置かれます。このボックスでは remaining box

の bottomにチェックを入れ、残りボックスの下を切り取ります。このとき残りボックス

は今ボックス 1とボックス 3の間の長方形のエリアです。第４のボックスは位置や大き

さを指定しません。するとそれは残りボックスいっぱいの大きさになります。それはボッ

50

クス 2と交差します。点線は説明のためにこの図では示されていますが、実際のスクリー

ンではボックス 4によって覆われるボックス 2の部分は見えません。

3.4.4 基本的なボックスのタイプ

このセクションでは、基本的なボックスタイプを示します:これらのボックスでは、

subjectsテーブルからのテキストおよびデータを表示します。

Standard Box

スタンダードボックスでは、subjectsテーブルの変数が表示・入力されます。アイテム

は上から下へ表示されます。ウィンドウは、ラベル列 (左)および変数列 (右)に分割され

ます。変数は、変数列で常に表示されます。変数が定義される場合、あるいはそれが下線

「 」からのみ成る場合、ラベルは常に左の列に現われます。変数が空の場合、ラベルはタ

イトルと見なされ、全体のウィンドウの中央に表示されます。ラベルが 1行を越えるライ

ンから成る場合は左寄せされます。アイテムが空の場合、それはウィンドウ上に縦方向の

51

スペースを形成します。次の例は定義およびその結果としてスタンダードボックスで生じ

るレイアウトを示します。

Grid Box

スタンダードボックスと同様に、グリッドボックスはアイテムを含むことができます。

スタンダードボックスと異なるのは、グリッドボックスの中のアイテムはテーブルに表示

されることです。各アイテムはテーブル中の 1個のセルに属します。アイテムが変数を含

んでいる場合、この変数が表示されます。アイテムのダイアログボックス内のラベルは、

スタンダードボックス内のアイテムでのラベルと違って表示されません。ダイアログボッ

クス内のラベルは、そのアイテムが入力アイテムであった場合に、そのフィールドで誤り

を犯した被験者に対するエラーメッセージのためだけに使用されます。（例：アイテム内

のラベルを”Input”としており、被験者の入力がアイテムダイアログボックス内で定義し

た最大値 10を超えているとき、「”Input”は 10以下を入力してください」というような

エラーメッセージが出ます。）アイテムが変数を含んでいない場合、アイテムのラベルが

表示されます。グリッドボックスのダイアログボックスでは、列と行の数を定義します。

そして、アイテムを書き込みます。次の例はアイテムが列ごとに記入される場合と行ごと

に記入される場合の例です。（列ごとへの記入か、行ごとの記入かもダイヤログボックス

で定義します。）

52

Header Box

ヘッダーボックスでは、次の図の中で示されるように、ピリオド番号および時間を表示

します。情報はすべてオプションで、ヘッダーボックスのダイアログボックスで定義する

ことができます。

Help Box

ヘルプボックスは、ボックスの内にテキストを表示します。テキストのサイズはボック

スのサイズに制限されません。ヘルプテキストが長すぎて、ヘルプボックス内に表示でき

ない場合、スクロールバーが現われます。ラベルをヘルプボックスに付けることができま

す。次の図は例を示します。

History Box

ヒストリーボックスは、過去のピリオドの結果を表示します。ラベル列はラベルを表示

します。表が長すぎる場合スクロールバーが現われます。当期は表の一番下に表示されま

す。スクロールバーは、このラインが最初に見えるように調節されます。

Container Box

スクリーン上に多くのボックスを置くと画面設計が混乱しやすくなります。混乱を回避

するために、スクリーンエレメントを組み立てるコンテナボックスを使用することができ

ます。コンテナボックスはフレームと異なり、被験者のスクリーン上には現れません。そ

53

れらは、スクリーンのエリアを定義するだけです。その中にボックスを置くことができ

ます。

コンテナはより少ない労力でスクリーンレイアウトの決定エレメントを定義する事を可

能にします。このため、レイアウトを変更しても手を入れるところは少なくて済みます。

下記の例で、１箇所で Box1および 2の幅を同時に定義したいとします。2つのコンテナ

ボックスを定義します。それぞれ Box12と Box34としましょう。コンテナ Box12の幅

を定義し、ボックスの左をカットします。（remaining boxで左をチェック）すると、コン

テナ Box34は、右側の領域いっぱいの大きさになります。Box１と３で高さを定義して、

上をカットします。(remaining boxで上をチェック)こうすることでサイズ定義を 1つず

つしか入力していないのに 4つのボックスの大きさを定義できます。また何かを変更する

ときでも、スクリーンの概観の構造は同じままです。

ボックスをステージツリーの内部のある場所から別の場所にドラッグして移動させると

き、ボックスはマウスボタンが放されたボックスの後に移動します。コンテナボックスの

アイコン上にボックスを移動させることによって、それはコンテナボックスへ移動し、そ

の始めに位置します。

Calculator Button Box

下に示されるようなボタンを定義して、クリックするとウィンドウズ NT電卓を呼び出

すことができます。被験者が電卓を忘れた場合代わりに使えます。

54

3.4.5 ボタン配置

入力を確認し、ステージを終えるためにボタンを使用します。それらはスタンダード

ボックスおよびグリッドボックスに入れることができます。デフォルトとしてそれらは

右下のコーナーに配置されます。別の場所がよければ、ダイアログボックスでボタン位

置のためのオプションを選ぶことができます。ボタンが 2個以上ある場合、ウィンドウ

の一番下の列に並べられます。必要があればボタンは 2行以上にわたって配列されます。

ダイアログボックスではボタン配列を修正することができる 2つのフィールドがありま

す。最初のボタンをどこに置くか (Button/Position)、また、次のボタンをどこに置くか

(Button/Arrangement)定義することができます。次の図では、5個のボタンが 3つの異な

るオプションコンビネーションでどのように置かれるか示します。

ボタンを表示せずに、ボタンのサイズの中にスペースをつくりたければ、ボタンの名前

として下線 ( )を使用します。

55

3.4.6 Backgroundレイアウト

すべてのスクリーンにおいて、Background内で定義されたボックスが自動的に最初に

置かれます。各スクリーンでこれらのバックグラウンドスクリーンを使用するかどうか決

めることができます。このオプション (Background screen is being used)はスクリーンダ

イアログボックスで利用可能です。このフィールドがチェックされると、バックグラウン

ドのウィンドウは引き継がれ、最初に配置されます。

3.4.7 テキストの中への変数の挿入

変数もラベルおよびアイテムのレイアウトフィールドに挿入することができます。ヘル

プとメッセージボックスも同様です。例えば値の代わりに式（の計算結果）を表示するこ

とができます、「income=23.5 point」というように表示したくて、23.5が変数である場合

を考えて見ましょう。変数がテキストに挟まれているので、変数をテキストへ統合する必

要があります。上記の例は次の方法でラベルフィールドに入力されます。

<>income = < Profit | 0.1 > points

ストリング「< >」は、変数がテキスト内にあるかもしれないことをテキストの初めに

示します。変数およびそのレイアウトは <　 >の中で、垂線によって分離されて記述さ

れます。この例において、0.1はレイアウトです。利益の値は小数点以下 1位まで表示さ

れます。

オプション!text:もレイアウトとして使えます。これは出力アイテムとまったく同じよ

うに機能します。

例:

<>Your income is < profit ｜!!text: 0="small"; 80 = "large";>.

これは profitが 0に近いか、あるいは 80に近いかに依存して「あなたの収入は小さい」

あるいは、「あなたの収入は大きい」と表示します。

変数も「text」オプションに挿入することができます。この場合別の「< >」で文字列を

始める必要はありません。マイナスの値ならテキストを表示し、正の値では数値を表示す

るレイアウトを定義したい場合、

<>!text: -1 = "negative"; 1 = "<Profit ｜ 0.01>";

56

とします。この形式は、レイアウトフィールドにも変数の名前を書き込む手間があると

いう難点がありますが、変数名は省略できます。この場合アイテムの変数が自動的に示さ

れます:

<>!text: -1 = "negative"; 1 = "< | 0.01>";

これは、さらにテキストに挿入された変数でも機能します。次のテキストでは、利益の

値が < |0.01>の場所に挿入されます。:

<>Your profit is < Profit |!text: -1 = "negative"; 1 = "< |0.01>">

シンボル「>」をテキストに挿入したい場合は、それが変数表現と混同されないように、

シンボルは「> >」のように反復しなくてはなりません。

注意: 値が変わるアイテムのためにこのオプションを使用するときは注意してくださ

い。アイテムの幅は最初に表示されるときに計算され、それ以降は変わりません。従って

値が 1から 20に変わると、2だけが表示されるかもしれません。それを回避するのはあ

なたの仕事です。

さらに、ラベルはステージの初めに一度だけ評価されることにも注意してください。ラ

ベル中の変数は更新されません。

3.4.8 RTFを備えたテキストフォーマット

アイテムのラベル、ヘルプボックスおよびメッセージボックスでは、RTFでフォーマッ

トされたテキストも入力することができます。RTFフォーマットは「{￥rtf 　」(直後にブ

ランクのスペースが必要)で始まり、「}」で終わります。中にテキストが入りますがそれにフォーマット定義を加えることもできます。フォーマット定義は「￥」から始まり、ブ

ランクのスペースで終わります。

フォーマットオプションをある範囲にのみ当てはめたい場合、カール状の括弧でこの範

囲を決めることができます。

例

normal font size,bold, no longer bold\ref \fs18 normal font size, \b bold,

\b0 no longer bold

Text italic no longer italic \rtf \fs18 Text {\i italic} no longer

new line italic \par new line

One word in ochre, the rest in black\rtf

57

\colortbl; \red0\green\blue0; \red255\green100\blue0;} \fs18 One word in

\cf2 ochre\cf0 , the rest in black.

より複雑なオペレーションについては、ワードプロセッサ中でテキストをフォーマット

し、次に、RTFとしてそれをエクスポートするといいでしょう。しかし自分で RTFコー

ドを作った方がより短く読みやすくなるでしょう。

変数の挿入は RTFの解釈の前に行なわれます。このため、ボールドの変数が 1である

場合「Hello」は太字で、そうでなければ通常のテキスト表示するといった、条件付きの

フォーマットが可能です：

<> {\rtf <BOLD |!text: 0="";1="\b ";>hallo}

3.5 シーケンシャルゲーム

シーケンシャルゲームではすべての被験者は同じ決定構造を持っているとは限りませ

ん。例えば最後通牒ゲームでは提案者だけが、何をオファーするかを決定します、また、

受取者だけが受理あるいは拒否をします。さらに異なる決定を同時に入力させたい場合も

あるでしょう。うまく戦略的手法を用いれば、提案者と受取者はスクリーンが異なってい

ても同時に入力を行なうことができるでしょう。

z-Treeでは、すべてのトリートメントはステージが連続して連なったものと定義され

ます。しかし被験者がすべてのステージを通る必要はありません。また、すべての被験者

が常に同じステージの中にいるとは限りません。これをどのように実現するかをこのセク

ションの中で説明します。

3.5.1 手番

z-Treeでは subjectテーブルの変数 Participateが、その被験者がそのステージに

入るかどうかを決めます。この変数の値が 1である場合、被験者はそのステージに入り、

active screenが被験者のスクリーンに表示されます。ステージのプログラムが実行さ

れる前に、この変数は 1にセットされます。あなたが何もしなければすべての被験者が

そのステージに入ります。しかし、変数が 0の場合被験者はステージに入りません。被

験者は自動的にそのステージの待機状態に移動します。しかしながら、このステージの

58

waiting screenは表示されません*3。Participateの値は subjectテーブルの通常の

変数です。条件に依存して 0または 1にセットすることができます。

最後通牒ゲームの例において、まず提案者が自分のオファーを決定します。この後に、

受取者は、彼らがこの申し出を受けたいかどうか決定します。そこで PROPOSER DE-

CISIONステージおよび RESPONDER DECISIONステージを定義します。提案者だけが

前者に入ります。また、受取者だけが後者に入ります。この目的のために、PROPOSER

DECISIONステージの subjectテーブルのプログラムの中で次の行を書きます:

Participate = if (Type == PROPOSERTYPE, 1, 0);

この行は変数 Participateを決定します。それが 0である場合、被験者はこのステージ

に入りません。表示は何も変わらずに、直接そのステージの待機状態に行きます。被験

者には、あたかもまだ前のステージにいるように見えます。RESPONDER DECISIONス

テージについては、次のプログラムを使用します。

Participate = if (Type == RESPONDERTYPE, 1, 0);

ステージの初めのプログラムが、実験に参加するすべての被験者のために実行されるこ

とに注意してください。プログラムが実行されると変数 Participateがチェックされま

す。変数 Participate はプログラムを実行するかどうかを決定するわけではありませ

ん。それはスクリーンを表示するかどうかだけを決定します。

Tip: if(ConditionForEntering、1、0)のように、if 形式で Participateステート

メントを書くようにしましょう。この約束に従わないと、if 関数の第 2、第 3の引数に絶

えず注意しなくてはいけなくなります。

3.5.2 異なるステージでの同時性

この節では異なるステージが同時に実行されるプログラムを説明します。戦略的手法を

備えた最後通牒ゲーム、あるいはどんなゲームでもいいのですが、異なるタイプのプレイ

ヤが存在して、異なるフィードバックを受け取る（例えば Profit display stageで）例を考

えてください。

各ピリオドで被験者はすべてのステージを通ります。各ステージでは最初にステージの

アクティブな状態に到着します。この状態で、被験者はこのステージのアクティブなスク

*3 1つを越えるステージを省略したい場合もあるため、こうなっています。こうすればある待機ステージから次の待機ステージへの移動は被験者の目に見えません。

59

リーンを見ます。クライアントウィンドウでステージのアクティブな状態は「*** ステー

ジ名*** 」として表示されます。active screen は OK ボタンあるいはタイムアウトに

よって次へ移行します。すると waiting screenが表示されます。これはクライアント

ウィンドウで「-ステージ名-」として表示されるそのステージの待機状態に被験者が到着

したということです。被験者が次のステージを始めることができるかどうかは、次のス

テージのダイアログボックスでどのようにオプションが決定されるかに依存します。これ

らのオプションの 1番めは Startオプションです。（Startオプションはステージアイコン

をダブルクリックすると出てくるダイアログボックスから変更できます。）それは、被験

者がステージに入るための前提条件を決定します。最初の 2つのオプションは最もよく

使用されるオプションです。Wait for allはデフォルトの設定です。これが Startオプショ

ンで選択されているとき、被験者は他の被験者全員が前のステージを終了するまで次のス

テージに入ることができません。Start if possibleとセットする場合、被験者は前の

ステージを終了したら直ちに次のステージに入ることができます。Start if…を選択す

ると条件の設定が可能になります。この選択肢は複雑な構造の実験を行なうために用意

されています。ほとんどの実験は最初の 2つのオプションでプログラムすることができ

ます。

ステージアイコンのダイアログボックス内にあるスタートオプションは、異なるステー

ジが同時に実行されるように定義することを可能にします。2ステージ連続ゲームを考え

ます。つまり、2番手の人は 1番手のあらゆる選択を考慮して決定しなければなりません。

この場合、2番手、1番手は同時に意思決定します。z-Tree では以下のようにこれを定

義します。2つのステージを一つは 1番手のためもう一つは 2番手のために定義します。

1番手だけが FIRST MOVER ステージに入り、2番手だけが SECOND MOVER ステー

ジに入るように、2つのステージの中で変数 Participateをセットします。そして第 2

ステージのスタートオプションを start if possibleにします。2番手は最初のステー

ジに参加しません。また、1番手が第 2ステージに入るのを待つ必要がないので、1番手

が第 1ステージに入るとともに彼らは第 2ステージに (実質的に)に同時に入ります。図

3.23はこの状況を示します。ステージツリーアイコンのステージ名の終わりに、スタート

オプションを示すシンボル（=|=、-=）があります。

3.5.3 ステージの終了

各ステージについては、1つのステージ当たり被験者に許される時間が Timeoutフィー

ルドに定義されます。入力された式は globalsテーブルの中で計算されます。異なるス

テージが同じタイムアウトである必要がある場合、（そしてそれを柔軟に変更できるよう

60

Figure 3.10 異なるステージを同時に決定する

にしたい場合）globalsテーブルに変数を定義して、タイムアウトフィールドにこの変数

の名前を入力してください。ステージのためにセットされた時間が尽きた後のゲームの継

続はステージの中でセットされたオプションに依存します。デフォルトでは、このステー

ジの中で入力しなければならないかに依存します。被験者がこのスクリーン上で入力する

必要がない場合ステージのための時間が過ぎるとステージは終了、つまり被験者はステー

ジの待機状態に到着し、そこから次に進むでしょう。入力しなければならない場合、表

示された時間は単なるガイドラインです。時間が尽きるとメッセージ「Please make your

decision now. (今すぐ決定してください)」が表示されますが入力されるまでゲームは進み

ません。タイムアウトが生じないようにするには負の数を入力します。そうすると、被

験者の持ち時間は無制限になります。タイムアウトを 0にセットすると、直ちに waiting

screenに行きます。

自動的にステージを移動したくなければ、Leave after timeoutのオプションで Noを選

択します。入力がなされていなくても、ステージを移動したければ、このオプションに

Yesを入力します。

警告:Leave after timeoutで Yesオプションを使用する場合、入力値を適切に初期化しな

ければなりません。

3.5.4 例:最後通牒ゲーム

プレイヤ 1(提案者) は 100をどう分けるかをを提案することができます。提案を

(share1, share2)とします。プレイヤ 2(そのオファーを受取った者：以下受取者)はこ

61

の分け方を受理するか拒否することができます。プレイヤ 2がこの提案を受理すると、両

方のプレイヤは自分のシェアを受け取ります。プレイヤ 2が拒否すれば 2人とも何も受

け取りません。

図 3.5.4で示されるようにこのトリートメント用の 4つのステージを定義します:提案者

の意思決定、受取者の意思決定、提案者の利益表示および受取者の利益表示です。以下で

はこの実験プログラムにおける主なステップを見ていきます。

最初に、定数 PROPOSERTYPEおよびRESPONDERTYPEを定義します。これらを定

数 1および 2の名前として使用します。次に変数 Typeを定義します。変数 Typeをここ

で許容されない値にセットし、パラメータテーブルで正確な値を定義します。（Treatment

＞ parameter table でパラメータテーブルを呼び出し、S1をクリックして Program に

Type=1; を、S2をクリックして Type=2; を入力。）トリートメントをより柔軟にするた

62

めに、パイのサイズを変数として定義します。この変数を M と呼びます。PROPOSER

OFFERステージでは、提案者だけがオファーできるように、変数 Participateをセッ

トします。

PESPONSERS ACCEPTANCEステージでは、受理者の subjectテーブルの列に提案

者の提案をコピーしなければなりません。新しい変数 Shareを定義することで、これを

行います。Shareは提案者によって提案される被験者のシェア（提案者が受け取るパイの

大きさ）を含んでいます。それは提案者にとってはパイのサイズ M から提案額 Offerを

引いた M-Offerですし、それは受取者にとっては提案者のオファーです。受取者が提案

者のオファーを得るためには、次の find関数を使用します。

find( same( Group) &Type == PROPOSERTYPE, Offer)

RESPONDER ACCEPTANCEステージでは、受取者が提案を受理するか拒否するかを決めま

す。ここでは入力のためにラジオボタンを使用します、つまり、Acceptアイテムのレイ

アウトフィールドで、以下のように書きます:

!radio: 1="accept"; 0="reject"

PROPOSER PROFIT ステージでは、利益を計算します。受取者から提案者に変数 Accept

をコピーする際には、次のプログラムを使用します。

Accept = find( same(Group ) &Type == RESPONDERTYPE, Accept);

このように変数 Acceptの値に上書きします。変数のデータを破壊するかもしれませんの

で、上書きには注意が必要です。しかしここではなにも破壊されません。受取者について

は変更しません。古い値で上書きします。

個別のプログラムに Participate変数の計算を入れます。私たちは 2ヶ所でこのプロ

グラムを使用しなければなりません。プログラムを２つにするには、単に全体のプログラ

ムをコピーし貼り付ければ済みます。それらが各々に異なる表示を行っているので、利益

表示は提案者と受取者で異なるステージが必要です。この 2つのステージでは提案者だけ

が提案者の利益表示ステージに入り、受取者だけが受取者の利益表示ステージに入るよう

に変数 Participateをセットします。最後に、受取者の利益表示ステージのスタートオ

プションを「individual start 」に変更します。これをしなければ提案者の利益表示の後で

ないと受取者の利益表示に進まず、不要な待機を発生させます。

63

3.6 連続的なオークション市場

3.6.1 概念

ここまでのトリートメントでは、基礎的構造が非常に単純なものでした。各ステージで

はプレイヤが彼らの決定を入力し、ボタンで決定を確認し、次に実験を進めることができ

るまで、つまり次のステージに移ることができるまで待ちます。このメカニズムでどんな

種類の標準型ゲームも展開型ゲームも実験が可能です。しかし、市場のふるまいを検証す

る経済実験も多く存在しますが、市場制度の多くがゲームとして実行することができませ

ん。例えばダブルオークションを考えてください。この市場制度では、売り手と買い手の

両方がオファーできます。両者のオファーはすべての市場参加者が見ることができます。

買い手は売り手の申し出を受けることができます。また、売り手は買い手の申し出を受け

ることもできます。この制度は、次の点で今までプログラムしたトリートメントと異なり

ます:

• オファーに参加する被験者を前もって決めておくことができません。どれだけのオファーがなされるか前もって知ることはできません。

• どんな順番でオファーされるかは前もって分かりません。つまり誰が次に決定するのか分かりません。

• たとえ被験者が入力を行なわなくても、彼らは他のプレーヤの決定を知らされます。つまりある被験者のオファーは他の被験者に示されます。

• オークションは、一定の時間が経つと自動的に終了します。

連続的なオークションへの対処については、次の概念が z-Treeの中で使用されます:

• ステージツリーダイアログボックスでは、時間が終了した場合にステージを自動的に終了するオプションがあります。これはボタンのデフォルトの振る舞いも変更し

ます。ボタンはもはやステージの終了をもたらしません。このため被験者は、無制

限に入力できます。

• contract table(　契約テーブル　) は無制限の列数を含んでいるテーブルです。

契約テーブルでは、被験者の入力を格納します。

• 新しいボックスタイプ、contract creation(　契約形成　)box、contract list

(　契約リスト　)box および contract grid(　契約グリッド　)box があります。

これらのボックスが、オファーの作成、選択、可視化、編集を可能にします。いく

つかのボックスの使用により、1つのスクリーン上 (かつ一つのステージで )で異

64

なる作業も可能です。つまり 1つのボックスの中でオファーをし、別のボックスの

中でオファーを受けることができます。

• placing programs into buttonsによって、被験者が同じデータに基づいて異

なる処理をすることができます。したがって、価格の入力はこの価格での売りを意

味し、またこの価格でも買いを意味することもあります。

次の節では、単純なダブルオークションを構築します。そこでは、ダブルオークション

の売り手が売り手にとって 0のコスト、買い手にとって 100の価値を持つ製品を売ること

ができます。各被験者は最大 1つのアイテムを取引することができます。被験者の入力が

どのように契約テーブルの中に格納されるかを最初に示します。その後、オファーのため

のボックス、オファーを表示するためのボックスおよびオファーを選択するためのボック

スをどのように作るかを説明します。

3.6.2 契約テーブルにおけるダブルオークション

オークションでは、売り手と買い手によって出されたオファーは契約テーブルのレコー

ドに格納されます。オファーが受け入れられると、対応するレコードが更新されます。

この情報は変数 Seller、Buyer、Creator および Price*4に格納されます:売り手がオ

ファーすると、変数 Seller にこの被験者固有の変数 Subject がセットされます (この

数が唯一であるので、これを被験者 IDと呼びます。)。変数 Buyerは-1にセットされま

す。これはオファーがオープンであること、すなわち受け入れられるのを待っている状態

であることを意味します。変数 Priceは売り手が自分のオファーとして入力する価格で

す。買い手が売り手のオファーを受諾する場合、変数 Buyerの中の-1は買い手の被験者

ID と取り替えられます。売り手が買い手のオファーを受ければ同様のことが起こります。

(Sellerの中の-1が売り手の被験者 IDと入れ替わる)このように契約テーブル中ではオ

ファーやオファーの受諾を容易に記すことができます。

しかしながら、申し出が受けいれられる場合、-1は受け入れられた申し出をマークす

るのには十分ではありません。オファー価格を徐々に下げる売り手について考えてくださ

い。徐々に下げていって最終的にそのオファーが受け入れられたとしましょう。このとき

この売り手の他のオープンなオファーがもはや有効ではないことは明らかです。この売り

手はもう品物を持っていないこともありえます。そこで用を成さないオファーを削除しな

ければなりません。もちろん、テーブル中のこれらのオファーを現実に削除するのではあ

*4 これはオークションをプログラムするただ一つの方法ではありませんが非常に便利です。同じセットの変数を常に使用することは非常によい方法です。それは、トリートメントの理解をはるかに容易にします。

65

りません。単に削除を意味するマークをつけるだけです。変数 Sellerの中の　-1を-2に

置き換えることで、これをおこないます。そうなると、このオファーはもはやオープンで

はなく、削除された扱いになります。このようにして何がオークション中に起こったかに

関する情報をすべて残します。

ダブルオークションを行うにはまだ問題があります。申し出が受けられると、変数

Sellerおよび変数 Buyerの両方が正の数になるので、どちらがオファーをしたのかわか

りません。申し出た被験者の被験者 ID を変数 Creator に入れることによりこの問題を

解決します。オファーが受け入れられたときに変数をセットすることもできますが、オ

ファーがなされたときにそれをセットする方がより自然です。次の表はダブルオークショ

ンで生じる様々な状況の要約です。変数の値をたどればオークション中に起こったことを

再現することが可能です。：

3.6.3 オークションのためのレイアウトの準備

ボックスを定義し始める前に、レイアウトについて説明しましょう。売り手と買い手の

レイアウトは非常に類似しているので、買い手のためのレイアウトだけについて説明しま

す。買い手は購入希望価格をオファーすることができますし、他の買い手のオファーを見

ることもできます。3番めのボックスでは買い手は売り手のオファーを見ることができ、

それらを受理することができます。次の図の中で示されるようなスクリーンを整えます：

買い手がオファーを行うためのボックスおよび買い手のオファー用ボックスは、並べて

配置します。

66

3.6.4 オファーの実行

この節では、オファーを実行するためのボックスを設計する方法を説明します。オ

ファーは契約形成ボックスで作られます。メニューからの他のボックスと同じように new

contract creation boxを挿入します。契約形成ボックスのダイアログボックスは、こ

のボックスに特有のいくつかのフィールドをもっています。これらのオプションは、リ

ファレンスで詳細に説明されています。この例では、オプションはすでに適切にセットさ

れています。ポジショニングだけは変更しなければなりません。

スタンダードボックスと同様に、契約形成ボックスは (入力) アイテムとボタンを入れ

ることができます。契約形成ボックスでは、オファーを入力しなければなりません。つ

まり、ボックスに変数 Price用の入力アイテムを入れます。オファーを確定するために

被験者はボタンを押さなければなりません。このボタンも契約形成ボックスに入れられ

ます。被験者がこのボタンを押すと contract tableで新しいレコードが作製されます。

入力アイテム中のデータ、つまり変数 Price中のデータはこのレコードに格納されます。

それ以外の情報をこのレコードに入れる必要がありますが、被験者にすべての情報を入

力させることはできません。たとえば一般に、被験者は自分の ID を知らないので売り手

に変数 Sellerを入力させることはできません。被験者に対して直接意味を持っていない

データは自動的に入力されるべきです。その問題の解決策は、ボタンに入れられるプログ

ラムです。ボタンが押されると、そのプログラムが実行されます。変数 Buyerに－１を

67

セットするプログラムを書くことは容易です：

Buyer = -1;

しかし、売り手変数をセットするにはどうすればよいでしょうか。まずボタンを押した被

験者本人の IDにどのようにアクセスできるのでしょうか。これはスコープオペレータを

使うことで解決します。ボタン中のプログラムは「scope environment」の中で実行さ

れます。プログラムが subjectsテーブル中で走る場合、契約形成ボックスのボタン中の

プログラムを実行すると、スコープオペレータで globalsテーブルにアクセスできます。

同様に契約形成ボックスのボタンの中のプログラムでスコープオペレータを用いること

でボタンを押した被験者のレコードにアクセスすることができます。(ですのでダブルス

コープオペレータはグローバルテーブルに到達します。)変数 Sellerおよび Creatorを

セットします。：

Seller = : Subject;

Creator = : Subject;

プログラムを実行するテーブルを定義しなければならないことに注意してください。ここ

では契約テーブルの新しく作成されたレコードでそれを実行したいのでプログラムダイヤ

ログで契約テーブル*5を選択します。

3.6.5 オファーを見る

オープンなオファーは契約リストボックス中で示されます。そのボックスは、契約テー

ブルの一部を示します。ボックスに含まれているアイテムは、契約テーブル中のどの列が

示されるか定義します。ダイヤログボックス内の Condition(条件) で、どのレコードが

表示されるか定義します。オープンなオファーすべてを表示したいので、条件は

Buyer == -1

です (これは expression なのでセミコロンはつけません)。オファーは価格によって

ソートされるべきです。売り手がオファーの価格を減少させるはずなので、小さい順に価

格を表示します。従って、ソートする表現は以下のようになります。

-Price

*5 ステージの初めのプログラムと違って、ボタン中のプログラムは、必ずしもそのデータ・ベースのすべてのレコードのためには実行されません。

68

マイナスの符号は降順であることを示します。昇順を使うときにプラスの符号を使う必

要はありません。というのは昇順はデフォルトの設定だからです。ところで、-Priceで

生成される順序は-Priceで並んだ昇順であると解釈することも出来ます。

3.6.6 doステートメント

次に進む前に、新しい概念である do ステートメントについて説明しなければなりま

せん。doステートメントで、テーブルのすべてのレコードで計算を実行することができ

ます。

do { statements }

プログラムステートメント (statements)は当該テーブル中のすべてのレコードのため

に実行されます。

テーブル関数と同様に、doステートメントの前にテーブル名をつけることができます。

こうすることで計算がそのテーブル中で実行されます。さらにテーブル関数と同様にス

コープオペレータを使用することもできます。

例:次のラインが 1人の被験者のために実行されると仮定します。

subjects.do{

Money=:InitialMoney;

:Done=Subjets;

}

doステートメントは被験者の全てのレコードにおいて変数 Moneyをグローバルテーブ

ルの中の変数 InitialMoney にセットします。さらに、グローバルテーブルの中にある

変数 Done を被験者テーブルの中にある Subject 変数の値にセットします。プログラム

は全ての被験者テーブルを通じて実行されるので、最終的には Done は最後の被験者の

Subject変数の値を格納することになります (これは被験者の数と等しくなります)。

3.6.7 申し出の受理

オープンな申し出を受けるために、契約リストボックスにボタンを加えなければなりま

せん。そして契約形成ボックスと同様、ボタンの中にプログラムを入れる必要がありま

す。プログラムでは買われた (そして売られた) オファーをマークします。契約形成ボッ

クスでは、スコープオペレータで自分自身のレコードにアクセスできます。そこで次のス

テートメントが必要です。

69

Buyer = : Subject;

この方法で、オファーはオープンなオファーのリストから消えます。買い手は-1でなく

なりますが、またやるべきことがあります。まず、有効でないオファーを削除しなければ

なりません。上記のステートメントの後に、次の一文を置きます。

contracts.do{

if ( Buyer == :Buyer & Seller==-1 ){

Seller = -2;

}

if ( Seller == :Seller & Buyer == -1 ){

Buyer = -2;

}

}

最初に、contracts.do で、契約テーブルに進みます。テーブルの中では、スコー

プオペレータが自分自身のレコードへのアクセスを認めます。条件 Buyer == :Buyer

&Seller == -1 を満たすのは、このまだ受け入れられていないオファーの買い手 (ボタ

ンを押した人)のレコードです。Sellerを-2にセットすることで、これらのオファーを

削除されたものとします。この操作で、これらはオープンなリストから消えます。

一般的に、受理ボタンのプログラムの中により多くのステートメントを組み込まねばな

りません。「買い」を反映するために、商品のストックおよびプレイヤの得点を更新しな

ければなりません。変数 Goodsおよび Moneyがプレイヤの手持ちの商品の数と所持金と

します。この場合、プログラムに次のステートメントを加えます。

subjects.do{

if ( Subject == :Buyer ) {

Goods = Goods +1;

Money = Money - :Price;

}

if (Subject == :Seller ) {

Goods = Goods -1;

Money = Money + :Price;

}

}

70

このプログラムは、買い手が商品を 1つ受け取り、売り手が金銭を受け取ったことを示

します。

3.6.8 被験者の入力のチェック

多くの場合、提出されたり受け入れられたりするオファーには制約があります。たい

ていの場合、空売りや赤字は許されません。更に、オファーを改定せねばならないこと

があります。買い手は現在のオファーより高くオファーしなければなりません。こう

した条件は、ボタンに組み込むことができます。ステージツリー上のボタンを選択し、

Treatment>checkerを選択してチェッカーをボタンにつけます。

最初に空売り防止条件を考えます。条件は単に次のとおりです:Goods>=1。これは、少

なくとも一つ商品をもっていることを意味します。この条件をチェッカーのダイアログ

ボックスの Condition欄に入力します。これが満たされないときは「売れる商品があり

ません」というメッセージを出す必要があります。これは同じくダイアログボックスの

Messageに入力します。メッセージボックスには「No」ボタンしかありませんので、被験

者がメッセージを無視することができないことを意味します。チェッカーはオファーを受

け入れる契約リストボックスと同様に契約形成ボックスにも付けられます。

Price > contracts.maximum(Seller == -1, Price )

contractsテーブルという名前で doコマンドをはじめにつける必要があることに注意

してください。契約形成ボックスでは、Condition と同様にプログラムも、契約テーブ

ル全体ではなく新しいレコードの中でだけ実行されます。

重要：選択されたオファーがまだ利用可能であることを保証する条件を受理ボタンの中

に入れなければなりません。複数の被験者がほとんど同時に申し出を受ける可能性があり

ます。しかしながら、そのうちの 1つが先に受理されるでしょう。2つ目のオファーが受

理されるのを防がなければなりません。これを達成する一般的な方法があります。表示さ

れているレコードが満たすべき条件をチェッカーに置いてください。例えば次のようなも

のになります。

Buyer == -1

テキストとして「誰それが先に買いました。」のメッセージを使います。

メッセージをどこに表示するか

一般にメッセージは新しいウィンドウに表示されます。被験者はウィンドウを閉じるた

めに OKをクリックしなければなりません。これは被験者の注意を集めるという利点があ

71

ります。しかしクライアントが衝突すると、すべてのメッセージが再び表示され、さらに

クリックして表示をさせないようにしなければなりません。別の手として、メッセージが

表示されるメッセージボックスを挿入することができます。この場合、被験者はメッセー

ジをクリックして消す必要がありません。しかし、多少メッセージを見落とす危険があり

ます。

3.6.9 オークションステージの詳細

自動タイムアウトを備えたステージをオークションステージと呼びます。「start if

possible」のスタートオプションを伴うすべてのオークションステージがひとつのオー

クションを形成します。ステージがスタートする前に、これらのステージのプログラムが

すべて実行されます。プログラムはどの被験者が、どのステージに参加するかを決めるた

めのものです。

例：ダブルオークションでは、買い手および売り手は同じオークションに参加します

が、スクリーンは異なります。こうするために、2つのステージを定義します。売り手の

ためのオークションステージと買い手のためのオークションステージです。これらの 2つ

のステージは同時に開始され、最初のステージは売り手、次のステージは買い手のための

ものです。それについては、2つのステージに下記プログラムラインを挿入します：

Participate = if(type == SELLER, 1, 0); //into first auction stage

Participate = if(type == BUYER, 1, 0);

//into second auction stage

　

一般的に、時間が尽きるとオークションステージは終了します。しかし例外が２つあり

ます：

• 変数 AuctionStop が globals テーブル中で 1にセットされる場合、オークショ

ンは直ちに終了します。これは取引がすべて終了している場合に便利です。

• 変数 AuctionNoStopが globalsテーブル中で 1に設定される場合、時間切れで

もオークションは終了しません。

3.6.10 プログラム中の新しいレコードの形成

契約テーブルに新しいレコードを「new」ステートメントで加えることができます。構

文は；

72

table.new{ 　 statements 　}

です。

新しいレコードは、契約テーブルとユーザーに定義されたテーブルにだけ入力すること

ができます。カール状の括弧中のステートメントは、レコードの初期化を含むことがで

きます。次の例は、あるステージの subjectsテーブルのプログラムからとっています。

ユーザーがこのステージに達すると、レコードが契約テーブルに加えられます。このレ

コードでは、変数 Seller、Buyerおよび Priceが固定します。( Buyerの値はプログラ

ムが実行される被験者の被験者 IDです。)

contracts.new {

Seller = -1;

Buyer = :Subject;

Price = 25;

}

3.6.11 質の要素の追加

被験者がダブルオークションの後に取引した商品のある要素–品質など–を特定しなくて

はいけないと仮定します。各被験者が既知の商品数だけを交換する場合、subjectsテー

ブルに情報のコピーができます。その後、被験者は例えば通常のスタンダードボックスか

ら subjects テーブルにこの情報を入力することができます。契約グリッドボックスの

中で契約テーブルの部品を表示することが簡単な方法です。契約リストボックスとは異な

り、変数を入力して各レコードに加えることができます。

従って Contractの被験者の取引と一致するレコードを表示する契約グリッドボックス

を作成することができます。変数 Qualityを備えた入力アイテムを加えることによって、

被験者は、個々の取引で質を入力することができます。

3.7 ポスッテドオファーマーケット

ポステッドオファーマーケットでは市場参加者の一方、たとえば売り手がオファーをし

ます。この場合他方の買い手はオファーのひとつをかわるがわる選択します。z-Treeでは

この売り手のステージは contract creation box（契約形成ボックス）の中で売り手が価格

をオファーする通常の（非オークション）のステージで容易に実行できます。

買い手は契約リストボックスの中の契約を選択します。ここで連続性のために、ステー

73

ジダイアログボックスでのステージオプションの中で Number of Subjects in stageを使

用します。それを At most one per group にセットすることで、各ステージの 1つのグ

ループ当たり、1人の被験者だけがステージに入ります。したがって、被験者は交代でス

テージに入ります。特に指定がない場合、入る順番はランダムです。変数 Priority が

セットされた場合、最低の (最良の)ランクを持つ被験者が、最初に入ります。

もし被験者が次の被験者がステージに入る前にいくつかのステージを通る必要がある場

合、次以降の必要なステージに...and in previous stage(s)オプションをセットする必要が

あります。

3.8 クロックオークション

3.8.1 ダッチオークション

ダッチオークションで品物を販売する場合には価格を示す時計があり、この価格は時間

とともに減少します。誰かが価格を受け入れると、その時点の価格で品物を落札します。

z-Treeの中でこれを実行するためには簡単に設計を変更できる時計が必要です。価格が

減少する時間間隔と同様に価格が減少する幅を定義することができなければなりません。

これは later構文で行うことができます。仮に 1000の価格で始めて、3秒ごとに 10ず

つ価格を減少させたければ、下記のプログラムを (例えば globalsテーブルの中へ) 書き

ます:

　 Price = 1000;

　 later ( 3 )repeat {　 Price = Price - 10;

　 }

laterステートメントは以下の一般的な形式を持っています:

　 later( expression ) repeat { statements }

1. expressionの値を求めます。いまそれが tだとします。

2. tが 0より小さい場合、何も起こりません。

3. tが 0以上である場合、t秒後にまず statementが実行され、１に戻ります。

構文を最大でも１回だけ実行したい場合、later構文の別の形式があります。以下のよ

うに記述します。

74

　 later( expression ) do { statements }

先ほどと同じように、まず expressionの値を求めます。値がマイナスの場合には何も

起こりません。値が 0以上である場合には、その秒数だけ待機した後に statementが実

行されます。

アプリケーション 1:オークション練習ピリオド

ダブルオークションの実験を計画します。ユーザーインターフェースがやや複雑になる

ことから、被験者は実験の手順を学ぶ必要があります。このために最も望ましいのは被験

者に練習ピリオドを何回か実行させることでしょう。練習ピリオドで問題となるのは、被

験者間の相互作用によって、実際の実験がスタートする前に実験者がコントロールできな

い被験者の学習が起こり得ることです。被験者の学習をコントロールするために、他の被

験者の入力をシミュレートすることができます。これは later構文のシーケンスで作成

することができます。

アプリケーション 2:外生ショックを備えたダブルオークション

ダブルオークション中に経済環境を変更したいとしましょう。パラメーター p を 1分

後に 100から 50に変更したいとすると、下記プログラムで実現できます:

　 P=100;

　 later ( 60 ) do {　 P=50;

　 }

3.8.2 ステージの終了

多数のグループでダッチオークションを行うと仮定します。財が売れると直ちにそのグ

ループが次のステージに移れるようにしたいときは、以下のようにすると実現できます:

最初に、subjectsテーブル中の変数 Acceptedを 0に初期化します。その後、later

コマンドを上記のように作成します。価格はスタンダードボックスの中で表示し、この

ボックスのボタンに下記プログラムを配置します。

75

　 if ( sum ( same (Group), Accepted ) == 0) {　 //no other player else was quicker

　 Accepted = 1;

　 subjects.do {　 if ( same (Group) ) {　 LeaveStage = 1;

　 }　 }　 }

変数 LeaveStage は強制的に被験者のステージを終了することを可能にします。上記

のプログラム中で、価格を受け入れた被験者と同じグループ中のすべての被験者が直ちに

そのステージを終了します。

3.9 より進んだ概念

3.9.1 前の結果に依存するゲーム

オークション市場をプログラムする場合は、実験実施者は、被験者が毎期毎期金銭とス

トックで財産を保持できるようにしたいと考えるでしょう。z-Treeでは、被験者データ

ベースが毎期新しくセットアップされますので、過去のピリオドに関する情報は直接利用

できません。しかし前のピリオドのテーブルは接頭辞 OLD でアクセスすることができま

す。したがって、前のピリオドからの変数 Stockをコピーしたい場合には、次のように

書きます。

if (Period >1 ) {

Stock = OLDsubjects.find( same( Subject ) , Stock );

}

それより前のピリオドのデータにアクセスする方法はありません。

3.9.2 新しいテーブルの定義

z-Tree2.0では、標準の subjects, globals, summary, contracts, sessionテーブル

以外のテーブルを定義することができ、様々な目的のためにこれを使用することができ

ます。

76

• 異なる市場用テーブルのような多数の契約。• ランダムのピリオド支払い。テーブルは、各ピリオドに得られた利益を含んでいます。この１つに限らないトリートメントをこのテーブルはカバーします。

• 不連続関数の格納。• 電卓およびオークションを同時に使用すること。

新しいテーブルを使用するには、はじめに background で Treatment メニューから

「New item」で定義しなければなりません。ダイアログボックスが開いてテーブルのプロ

パティを入力することができます。

Lifetime：テーブルの lifetimeが Periodである場合、ピリオドが終了するとテー

ブルはそれらが保存された後に必ずリセット、つまり、テーブルのレコードはすべて削除

されます。subjects、globalsおよび contractテーブルはピリオドでの lifetimeを

持っています。subjects、globalsおよび contractテーブルと同様に、前のピリオド

のテーブル x にあったデータは OLDx と呼ばれるテーブル中でアクセスすることができ

ます。

lifetime Treatment のテーブルはトリートメント終了後にリセットされます。それ

らはピリオドが終了しても変わりません。

lifetime Session のテーブルはリセットされません。しかし、それらは各トリート

メントの終わりに格納されます。以前に実行されたトリートメントや別のトリートメント

の中で定義された変数にアクセスするには、フィールド「Used Variables」で変数を宣

言しなければなりません。

77

Program execution:被験者がステージを同時に入らない場合、プログラムの実行のタ

イミングは、「被験者が一人ステージに入った時」、「最初の一人がステージに入った時」、

「最後の一人がステージに入った時」の 3つから選択します。データ・ベースに対するオ

プションを定義することができます。デフォルトでは globalsテーブル中のプログラム

は最初の被験者が入ると実行され、summary テーブルでは最後の被験者が入るとプログ

ラムが実行されます。subjectテーブルと sessionテーブルの中のプログラムはそのス

テージに入った被験者のために実行されます。*6

3.9.3 ステートメントの条件付きの実行

ある条件が満たされたときにだけ何かを実行したい時には、if-instructionを利用す

ることができます。

それは次の形式で利用されます。

if ( condition ) { true_statements }

if ( condition ) { true_statements } else { false_statements }

条件は最初に計算されます。計算結果が TRUE の時、true statements の中の指示が

行なわれます。条件が FALSE の時、最初のケースでは何もおきません。また、２つ目の

ケースでは、false statementsの中の指示が実行されます。

例:

*6 ユーザーに定義されたテーブル中で実行されるプログラムでは、契約テーブルのような owner変数が使用できます。

78

if ( type == FIRM ) {

Profit = v * e - w;

othersProfit = w - c;

}

else { //type == WORKER

Profit = w - c;

othersProfit = v * e - w;

}

さらに、if関数を使用することで条件付きの計算を実行することができます。しかし条

件が何度も反復する計算は非能率的で混乱を引き起こしやすくなるので注意が必要です。

注意:ifステートメントは、すべてのレコードでなく、あるレコードだけ変数を計算す

ることを可能にします。これは不確定のセルに帰着します。

4つのタイプのプレイヤがいて、異なるタイプについては、異なる利益を計算させる状

況を考えてください。これを、入れ子の if ステートメントで以下のようにプログラムす

ることができます。

if (type == 1 ) {

//first calculation

}

else {

if (type == 2 ) {

//second calculation

}

else {

if (type == 3 ) {

//third calculation

}

else {

//fourth calculation

}

}

}

79

必要な閉じ括弧を正しくつけるのは大変です。elseif で、上記のプログラムは次のよ

うにより容易に記述できます。

if (type == 1 ) {

//first calculation

}

elsif (type == 2 ) {

//second calculation

}

elsif (type == 3 ) {

//third calculation

}

else {

//fourth calculation

}

3.9.4 ループ–whileと repeat–

z-Tree2.0では、2種類のループがあります。

while( condition ) { statements }

条件が評価され、条件が TRUEの間のみ statementsが実行されます。また、条件は再

評価されます。

repeat { statements } while ( condition );

まずステートメントが実行されます。その後条件が評価され、条件が TRUE を返す間、

ステートメントは再実行されます。また、条件は再評価されます。repeatステートメン

トで、カール状の括弧 ()の間のステートメントは少なくとも一度は実行されます。

ループはしばしばプログラムバグを生みますので注意してください。ループ中の条件

が FALSEを返さない場合、このループは永久に繰り返されます。<Ctrl>-<alt>-[F5]で

ループから抜けることができます。しかしながら、これは不確かな結果を生みますのでト

リートメントをテストする場合にのみ使用されるべきです。

別のやりかたとして iterator を使用してループをプログラムすることができます。

iteratorは、1つの変数を含んでいる新しい小さなテーブルを作成します。テーブル関

80

数あるいは do-ステートメントがそのような iteratorに適用される場合、do-はテーブ

ルに含まれる値に関するループになります。

iteratorは以下の構文を持っています。

iterator( varname ) // runs from 1 to number of subjects

iterator( varname, n) // runs from 1 to n

iterator( varname, x, y) // runs from x to y

iterator( varname, x, y, d) // runs from x to y with steps of d.

この構文はテーブルを定義します。このテーブルは、変数 varnameとそれが満たされ

るレコードを持っています、たとえば最後の場合ｘ、x+d、...y.です。

例:

// two ways of calculating: squareSum = 1+4+9+16+25 = 55

squareSum = iterator( i, 1, 5).sum( i*i );

// or

squareSum = 0;

iterator(i,5).do {

:squareSum = :squareSum + i*i; // iterator has its own scope!

}

3.9.5 複雑な手番の構築

z-Treeではどんな手番構造も実行可能です。スタートオプションの Start if…はよ

り複雑な手番構造を実現する方法の一つです。以下の決定構造を伴うトリートメントの中

で、このオプションをどのように使用するかを解説します。3人のプレイヤ 1、２、３が

います。プレイヤ 1および 2がまず意思決定を行い、それからプレイヤ 3が意思決定をし

ます。しかしながら、プレイヤ 3はプレイヤ 1の動きだけを知っています。そこで１が決

定したら直ちに決定を許可させたいとします。もしプレイヤ３の決定がプレイヤ１の決定

よりより多くの時間を使うならば、これは特に合理的でしょう。

タイプを含んでいる変数を Typeとします。DecisionAをプレイヤ A(Type=1)の入力

する変数にします。DecisionBと DecisionCをプレイヤ Bおよび Cの入力する変数と

します。変数は正であると仮定します。したがって、-1に変数を初期化すれば、誰がエ

ントリーしたかがわかります。3つのステージ stageA、stageB、stageCを定義します。

stageAでは、全員を待ちます。stageBでは、直ちに開始します。stageCでは、以下の

81

条件で開始します。

count( Type == 1 & DecisionA > 0) == count( Type == 1 )

この条件だと、プレイヤ 3はプレイヤ 1が全員終了するとスタートします。

count( same ( Group ) & Type == 1 & DecisionA > 0 ) == 1

この条件の場合プレイヤ３は自分のグループのプレイヤ 1が終了するとスタートしま

す。(もちろん、さらに変数 Participateをセットしなければなりません。)

3.9.6 不定長のトリートメント

ランダムストップルールを適用したい場合、トリートメントは有限の長さを持っていま

せん。これは変数 RepeatTreatmentを持った z-Treeの中で実行することができます。

ある１ピリオド分のトリートメントを定義します。ピリオドの終わりに、トリートメン

トを継続するべきか止まるべきかを決定します。この決定は globalsテーブル中で変数

RepeatTreatmentに書かれています。変数が定義されない場合、トリートメントは終了

します。これは通常の場合です。変数 RepeatTreatmentを定義すれば、トリートメント

が終了するか、それがもう一度繰り返されるかは変数の値に左右されます。値が 0以下の

場合、トリートメントは止まります。値が 0より大きな場合、トリートメントが繰り返さ

れます。

トリートメントが繰り返される場合、あたかも 1つのトリートメントであるかのよう

に、ピリオドカウンターが増加します。これは (練習) ピリオドの数を修正することで実

行されます。3つのピリオドのトリートメントを繰り返せば、第 1のトリートメントは３

ピリオドを持ち、練習ピリオドはありません。第２回目のトリートメントでは、トリート

メントのピリオドの数が 6に修正されます。また、練習ピリオドの数は-3に変わります。

3.9.7 例–戦略方法 (行列を用いて)–

単純なゲーム用の戦略方法を使用するトリートメントを考えましょう。A と Bの 2つ

のタイプのプレイヤがいます。A プレイヤは 1と 10の間で、数ａをひとつ選択します。

B プレイヤは aの取りうるあらゆる可能性に対する数 bを選びます。つまり、b1、b2、

b3、...b10を選択します。利益を 2つの間の絶対的な差とします。利益の計算の式は次

のようになります。

a = find( type == A, a);

82

Profit = if( a == 1, abs(a-b1),

if( a == 2, abs(a-b2),

if( a == 3, abs(a-b3), ... )));

これは非常に冗長です。

そのような場合、行列変数 (つまりインデックスが付けられた変数)を定義するとよいで

しょう。インデックスのセットとしてすべての有限で等距離の部分集合の数が使えます。

インデックス・セットは使用の前に arrayインストラクションで定義する必要がありま

す。arrayインストラクションは次の形式を持っています。

array arrayvar[ ] ; // 1から被験者数までのインデックスを持つ行列変数を定義

array arrayvar[ n ]; // 1からｎまでのインデックスを持つ行列変数を定義

array arrayvar[ x, y ] ; // xから yまでのインデックスを持つ行列変数を定義

array arrayvar[ x, y, d];// xから yまでのｄごとのインデックスを持つ行列変数

を定義.

行列の要素へのアクセスは arrayvar[indexvalue]で実行されます。indexvalue内

の数値は最も近いインデックスに丸められ、配列中の対応する値が取って来られます。

例:

array p[ 10, 20, 5 ]; // the index set is {10,15,20}

p[ 10 ] = 1;

p[ 15 ] = 5;

p[ 20 ] = 2;

p[ 30 ] = 3; // sets p[20]to 3

x = p[ 10 ] + p[ 20 ]; // x is 4

本小節の初めで示された例は、以下のようになるでしょう。

array b[ 10 ]; //within a background program

// b[1], b[2], etc are entered by the subject

a = find ( type == A, a );

Profit = abs( a - b[ a ] );

83

3.9.8 情報の表示・非表示

ボックスは動的に表示したり隠したりできます。ボックスにオプションとして display

conditionがあります。条件が空の場合、あるいはそれが TRUEと等しい場合にボックス

が示されます。データが変わるとき、z-Leaf、ボックスが今表示されるべきか隠される

べきかをチェックします。情報へのアクセスをコントロールするためにこの機能を使用す

ることができます。

3.9.9 セッション・テーブルを用いてトリートメントからトリートメントにデータをコ

ピーする方法

次の実験を考えてください。最初に、公共財トリートメントを作ります。その後、この

公共財トリートメントでの稼得利益は市場ゲームで別のトリートメントの中で使用するこ

とができます。セッション・テーブルはトリートメントの終了から残存するので、上記の

問題をうまく解決することができます。第 1のトリートメントでは、セッション・テーブ

ル中の変数 Incomeに利益の合計を格納し、第 2のトリートメントでこの変数に再びアク

セスします。

どのようにセッション・テーブルにデータを格納するかを考えましょう。セッション・

テーブル中のプログラムでは、subjects テーブルの対応するレコードはスコープオペ

レーターでアクセスすることができます。そこで最初のトリートメントでセッション・

テーブルのプログラムへ次のラインを入力します。

Income = : Total Profit;

どのようにセッション・テーブルからデータを検索するかを説明します。他のどのテー

ブルでもセッション・テーブル中の変数にアクセスすることができます。しかし問題が

ひとつあります。z-Treeは、あらかじめ定義されていない変数を使用していないか常に

チェックします。トリートメントの中でセッション・テーブル中のどの変数を使用するか

宣言しなければなりません。これが変数の値を破壊するので、割り当てステートメントを

備えた変数を定義することができません。したがって、セッション・テーブル定義内にト

リートメントの初めの変数を定義しなければなりません。テーブルはすべてアイコンの形

で background の初めにリストされています。トリートメントの中で使用する必要のあ

る変数を定義するために、セッション・テーブルのアイコンをダブルクリックし、フィー

ルド「Used Variables」へ引き継ぐ変数名を入力します。

84

4 アンケート (Questionnaire)

4.1 概要

各セッションは、アンケートで終了します。アンケートでは paymentファイルを出力

できるように、名前と住所が最初に尋ねられます。paymentファイルは実験での報酬リス

トのファイルです。次に、アンケートが表示されます。その後、被験者の報酬額を表示し

たり、最後に実験の終了を告げる画面を表示させたりすることができます。

アンケートは一連の Question form（質問フォーム）から成ります。1つの質問フォー

ムは、スタンダードボックスの中のアイテムと同じ方法で個々の質問を表示します。しか

しその質問は、スタンダードボックスのように中央揃えで縦に並べられたり、スクリーン

の大きさにあわせて自動で調節されたりしません。そのため、質問フォームはスクリーン

より大きくなるかもしれません。その場合は、スクロールバーが表示されます。アンケー

トは実験自体とは別物ですので、アンケートの答えで被験者の得点が変わることはありま

せん。回答はテキストとして保存され、プログラムの中でも使用することができません。

質問フォームは、順々に並べられています。被験者がすべての質問フォームに答える

と、z-Tree上で被験者は “ready”状態になります。その後でさらなるトリートメントある

いはアンケートを始めることもできます。しかしこれは不必要に被験者を待たせる等の問

題が生じることもあるので、いくつかのアンケートを連続で行なうのは一般に非実用的で

す。1つのアンケートにすべてまとめてしまうのがよいでしょう（1つのアンケートには、

複数のアンケートフォームを含むことができます。）。

実験者が新しいトリートメントあるいは新しいアンケートを実行するまで、あるいはト

リートメントを継続するまで、またはコンピューターをシャットダウンするまで最後の質

問フォームはユーザーのスクリーンに残ります。ですので最後の質問フォームはボタンを

含んではいけません。

4.2 アンケートの作成

4.2.1 アドレスフォーム (Address form)

アドレスプロンプトは被験者の住所等の情報の入力が求められます。アドレスフォーム

上ではフィールド「姓」、「名」および「ボタン」は必須項目であり、他のフィールドはオ

プションです。オプションのフィールドでの質問テキストが空のままにした場合、質問

85

はクライアント側に表示されません。もしフィールド「姓」および「名」を空にすると、

フォームは何も表示されません。すべての被験者がアドレスフォームを入力し終えた時点

で、paymentファイルが書きだされます。

書き出された paymentファイルには、名前、コンピューター ID および実験での得点

（報酬）が書かれています（タブ区切りのテキストファイル）。このファイルは印刷するこ

とができ、被験者に対する報酬額はこのリストで計算されているので非常に便利です。

4.2.2 質問フォーム (Question form)

質問フォームは質問のリストから成ります。質問のレイアウトはルーラー（Ruler）で

調節されます。質問フォームは最後以外すべてボタンを含んでいる必要があります。

各被験者が異なる役割 をもつ実験を行なう場合（たとえば、提案者と反応者がいるよ

うな場合）役割ごとに異なるアンケートを用意したいと思うかもしれません。z-Treeの新

バージョンでは、質問フォームを省略することができます。よって、2つの異なるタイプ

の被験者に 2つの異なるアンケートをしたければ、一つのアンケート（Questionaireファ

イル）の中に両方のタイプのための質問フォームを入れて、質問フォームを選択的に省略

することで実現可能です。

質問フォームを省略する手続きは、トリートメントでのステージを省略する手続きに似

ています:被験者がその質問フォームを表示させたくない場合、変数 Participateを 0に

セットします。ただし、アンケートを実行する場合、利用可能な subjects tableは存在し

ないので、変数 Participateは Session table中で設定されなければなりません。これは

質問フォームダイアログボックスに入力したプログラムで可能になります。

重要: トリートメントで session tableにタイプ変数 (被験者が提案者あるいは反応者か

どうか決める変数)をコピーしなければなりません。

4.2.3 質問

アンケート中の質問はトリートメントでのアイテムに相当します。アイテムでは、ディ

スプレイオプションがフィールドレイアウトの中で定義されます。ラジオボタンをセット

することもできます。フィールドは以下のとおりです:

Label: ラベルは質問の名前ですがそのまま質問として被験者に表示されます。変数が

セットされない場合、ラベルはスクリーン幅全体にわたるテキストとして表示されます。

Variable: それが入力変数である場合、Variable はアンケート結果のデータ・ファイルで

回答のラベルとして使われます。入力がセットされない場合、それは単に「利益ディスプ

86

レイ」の節（4.2.4節）で説明される変数のうちの 1つかもしれません。

Type: 質問のレイアウト。

Text, Number:　テキスト・フィールドは入力される箇所に現われます。Numberオ

プションの場合には、入力されたのが数値どうか確かめるチェックがあります。さ

らに、入力された数が有効な範囲にあるかを定義できます。テキスト・フィールド

でオプション「Wide」が選択されると、入力フィールドはいくつかの行から成りま

す。行の数は選択することができます。

Buttons: ボタンはフィールド・オプション中のどのラインでも作成できます。ただ

し、ボタンは質問フォームに対して 1つだけしか許されていません。

Radio buttons: ラジオボタンはフィールド・オプションのどのラインでも作成でき

ます。ラジオボタンが複数ある場合、これらのボタンは自動的に垂直に整えられ

ます。

Slider, Scrollbar: スライダーおよびスクロールバーは近似的に連続的な入力を可能

にします。　Minimum, Maximumおよび Resolution (最小単位)の項目を入力する

必要があります。ワイド・レイアウトでは、ラベルはマージンに置くことができ

ます。これらのラベルはフィールド・オプションに入力されます。Maximumは常

に右端での値です。Minimumは常に左端での値です。なので Maximumの数値は

Minimumの数値より小さくして下さい。

Radioline: Minimum, Maximumおよび Resolutionによって決定された数だけラジ

オボタンが水平に並べられます。ワイド・レイアウトでは、ラベルはマージンに置

かれます。これらのラベルはフィールド・オプションに入力されます。中央のボタ

ンは、「distance of central button」に 0より大きな数の入力することで、他のものか

ら分けることができます。Maximumは常に右端のボタンの値です。Minimumは

左端のボタンの値です。なので Maximumの数値は Minimumの数値より小さいく

して下さい。

Radiolinelabel: Radiolineのためのライン上のラベルです。ラベルはボタン上の

マージンに置くことができます。このアクション用のテキストはオプションフィー

ルド内に入力します。

Checkbox: チェックボックスはオプションフィールドですべてのラインに対してそ

れぞれ作成されます。これらのチェックボックスは垂直に整えられます。ファイル

に書き出される内容はチェックされたすべてのオプションのリストです。

87

Wide: ワイド・レイアウトでは、質問用の入力領域がレベルの右ではなく、ラベルの下に

現われます。

Input : このフィールドは、被験者への質問なのか (入力部分が表示される)、単なる変数表

示なのか (入力部分が表示されない)どうかを決めます。

Empty allowed: 質問に答える必要がない場合、これをセットします。

Minimum, Maximum, Resolution : 数を入力しなければならない場合、これらの値は入力

範囲のチェックのために使用されます。Slider, Scrollbarおよび Radiolineでは、これらの

値は選択したポジションを数値に変換するために使用されます。

Num. rows: テキスト入力用のワイド・レイアウトで、入力することができる列の数。

Options: ラジオボタン、スライダー、スクロール・バーおよびラジオ・ラインのワイド・

レイアウトでのボタンのラベル。

Figure 4.1 質問のサンプル

88

4.2.4 Profitディスプレイ

質問フォーム内で session tableの変数を使用できるので、被験者にセッションで稼いだ

報酬を表示することもできます。使用できる変数は以下の通りです。

FinalProfit トリートメントで得た得点の合計

MoneyAdded 注入された金額（破産手続きの部分を参照）

ShowUpFee 参加報酬の金額

MoneyToPay ShowUpFee+ FinalProfit+ MondyAdded

MoneyEarned ShowUpFee+ FinalProfit

4.2.5 ルーラー (Ruler)

ルーラーはラベルと質問が配置される領域を設定するために使用されます。

Distance to left margin: 位置はポイントで、あるいはスクリーン幅のパーセンテージで与

えることができます。

Distance to the right margin: 位置はポイントで、あるいはスクリーン幅のパーセンテー

ジで与えることができます。

Distance between label and item: これはラベルと質問の間の水平の距離です。この距離

の半分が自動的に、左と右のマージン (上記のオプションによって定義されるマージンに

追加的に)に割り振られます。

Size of label: これはラベルの最大の幅です。ディスプレイがパーセンテージで与えられ

る場合、これは全体のスクリーンの幅ではなく左と右のマージン間の幅を参照します。

4.2.6 ボタン

質問フォームはボタンで終了します。1つのフォームに 1個を越えるボタンを定義する

ことができません。このボタンはフォームのいかなる場所にも位置することができます。

ボタンのラベルは任意に設定することができます。

89

4.3 アンケートの実行

セッションの終わりに、実験者はメニューにあるコマンド Start Questionnaire でアン

ケートをスタートします。このアンケートは、被験者のアドレス (アドレスフォーム) の

ためのプロンプトをかならず含んでいます。被験者がすべてそれらのアドレスに入力する

と、z-Treeは Paymentファイルを書き出します。さらに、セッションの別のポイントにア

ンケートを挿入してもかまいません。しかしアンケートが被験者の数に関する情報を含ん

でいないので、アンケートをスタートさせるには少なくとも 1つはトリートメントを実行

しなければなりません。アンケートがアドレスフォームを複数含んでいる場合、第 1のア

ンケートだけにアドレスを入力する必要があります。後のアンケートでは、paymentファ

イルだけが更新されます。

アンケート開始のコマンド Start Questionnaire は、メニュー中の Start treatment の

部分が Start Questionnaire に変わっているはずです。（トリートメントウィンドウがア

クティブである時は Start Treatment が、アンケートウィンドウがアクティブである時は

Start Questionnaire がメニューに出ます。）被験者がアンケートに答えている間、z-Tree

上ではクライアントの状態は “questionnaire”と表示されます。また、subjects tableのウィ

ンドウでは、どのアンケートが現在答えられているか示されています。

4.4 領収書の作成

原文で説明されている機能はうまく働かない（MS-WORD の機能を付加的に利用

する）ため、本節の「領収書の作成」は割愛させて頂きます。領収書は各実験室や

大学毎に異なると思いますので、各自作るのが理想的であると思います。ちなみ

に、京都産業大学の実験室 (KEEL) では専用の領収書を作成しています。

90

5 セッションの実行

5.1 クイックガイド

セッションの実行は次のように行われます:

1. トリートメントとアンケートの準備

2. 実験者 PCのスタートアップ

3. 被験者 PCのスタートアップ

4. 被験者の到着

5. セッションおよび第 1トリートメントのスタート

6. セッションのコースの監視

7. さらなるトリートメントの開始

8. アンケートによるセッションの終了

9. 支払い

10. マシンのスイッチングオフ

11. データ分析

実験を行なっている間、主としてメニュー「Run」で作業します。ラン・メニュー中の

コマンドの順序は、セッションのコースに大体一致します。

5.2 トリートメントとアンケートの準備

セッションが始まる前に、トリートメントとアンケートはすべて z-Treeの中でプログ

ラムされ、ファイル・サーバー上に保存されなくてはなりません。どのようにトリートメ

ントとアンケートを定義するかは 3章および 4章で説明されます。トリートメントは被験

者数が違えば違ってくるかもしれません。参加予定の被験者がすべて参加するかどうかわ

からない場合、あなたは実際に参加した被験者の数に合わせて実験の被験者の数を変えて

セッションを実行したいと考えるでしょう。実験が単純な場合なら被験者の数はセッショ

ンの初め、つまり第 1のトリートメントのスタートの前に変更することができます。被験

者の数の変更に伴ってパラメーターの変更が必要な場合、被験者数の変更に備えてトリー

トメントを準備するという手があります。つまり考えられるあらゆる被験者数に対応でき

るように複数のトリートメントファイルを用意しておくのです。あるいはトリートメント

そのものがプログラム内でどのようにして被験者数を調節することになっているかリスト

91

してもいいでしょう。

5.3 実験者 PCの起動

実験者 PCのスイッチを入れ、ログオンし、z-Treeを開始します。z-Treeはどのクライ

アントがスタートアップし、接続を確立したかどうかを表示するウィンドウを持っていま

す。この情報は、クライアントテーブル (リファレンスマニュアルにより詳細な説明があ

ります)に表示されます。

5.4 クライアントテーブル

クライアントテーブルは、どのクライアントがサーバーに接続されているか示します。

さらにそれはクライアントの状態についての情報も含んでいます。つまりクライアントに

どのステージのスクリーンが表示されているかを表示します。Runメニューからの最初の

コマンドでクライアントテーブルを開くことができます。

各行が各被験者に相当します。被験者は、クライアントソフト z-leafが起動している

(列「Client」)PCに着席します。トリートメントが開始されない限り、クライアントテー

ブル上のクライアントは移動させて順番を並べ替えることができます。トリートメントを

スタートさせるともうクライアントの順番は変えられません。ただし、そのセッションに

参加していないクライアントは移動させられます。これらのクライアントは表の最後に

リストされます。トリートメントがスタートしていない限り、クライアントはコマンド

「Sort Clients」でソートし「Shuffle Clients」混ぜることができます。またはクリックとド

ラッグでも移動させられます。Client Tableは以下の 3列を持っています:

• Client:クライアントの名前です。一般に、これは被験者 PCの名前です。クライア

ントが接続されていない場合、その名前は括弧に囲まれます。同じ名前を備えたク

ライアントが再度接続すると、それは前と同じ場所で継続することができます。ク

ライアントのテーブルのキャプションは、現在接続しているクライアントの数を表

します。

• State:被験者の状態を示します。例；被験者が、次のトリートメントあるいは次の

アンケートを待っている場合、「Ready」が表示されます

• Time:被験者に示されるのと同じ時間を表示します。

92

5.5 クライアントのサーバーとの接続の確立

実験者が実験者 PCの上のサーバープログラム z-Treeを始めると、セッションが始ま

ります。この後に、クライアントプログラム z-Leafが被験者 PCで開始されます。z-Leaf

は実験者 PCの上の z-Treeとの接続を確立します。

クライアントはどのようにしてサーバーのアドレスを知るのでしょうか。z-Leafは、コ

マンドラインオプション/server ipaddressでサーバーの TCP/IPアドレスを決定すること

ができます。例えば、z-Leafをコマンド Zleaf/server 100.20.10.233で始めた場合 z-Tree

は TCP/IPアドレス 100.20.10.233を備えた PCの上にある必要があります。ファイル

サーバーのない環境で実験を実行したい場合この方法は非常に有用です。しかし z-Tree

がファイルサーバー上にあれば、より快適な方法があります。z‐ Treeはカレント・ディ

レクトリ内のファイル「server.eec」内に自分の TCP/IPアドレスを自動的に書きこみま

す。z-Leafを同じディレクトリー (同じ PC、あるいは別の PC)から起動するとこのファ

イルを読みます。z-Leafがこのファイルを見つけられない場合、ディレクトリー「c:￥

expecon￥conf」中でそれを捜します。どちらも見つけることができない場合、ローカル

のマシンの TCP/IPアドレスを取得することができますのでこのアドレスでサーバーを探

します。サーバーがここでもまた見つからない場合、接続が不確立であるというメッセー

ジを表示し、もう一度試すか尋ねます。

5.6 クライアントの名前を固定する方法

z-Leafがコマンドライン上で nameオプションを伴って開始された場合 (例 z-Leaf/name

T1)、それがクライアントテーブル上に表示されるクライアントの名前 (T1)になります。

そうでない場合、名前はまずローカルディレクトリー内のファイル「name.eec」中に求め

られます。これを用いることで 1つの PC上でいくつかのクライアントを実行することが

できます。ファイル「name.eec」が存在しない場合、PCのホスト名が使用されます。ホ

スト名は、TCP/IPの下のネットワーク・コントロールパネルに入力されます。

5.7 セッション中

ウィンドウ「globals table」、「subjects table」、「contract table」そして「summary table」

中で適切なテーブルの内容が表示されます。これらのテーブルでは、行と列のサイズは変

更することができます。これらのテーブルは、xlsファイルに自動的に書き出されます。

93

5.8 セッションの終了

＊４章と重複するため省略

5.9 クラッシュもしくはブロックされた被験者 PCの扱い

すべてのデータは終了次第ファイルに格納されます。これに加えて、サーバーとクラ

イアントの間で交換されたメッセージはすべて、(非テキスト)ファイル、GameSafeに格

納されます。これらのファイルによって、コンピューターがクラッシュしても実験を継

続することは一応可能です。被験者 PCの上の問題である場合には、以下のように進みま

す:PCがまだ機能している場合、再開することができます。その後、PCは自動的に瞬時

に以前に受け取ったすべてのメッセージをもう一度受け取ります。その後はクラッシュが

なかったのと全く同じ状態になります。これはクラッシュ前より進んでいることを意味し

ます:クラッシュの間にステージのためにセットした時間が過ぎた場合、すべてのクライ

アントが接続さていなくても、トリートメントは次のステージに進みます。

被験者 PCが止まってしまった場合、考えられる可能性は複数あります。サーバーが非

常にビジーである場合もそうなります。この場合少し待つことで問題が解消されることが

あります。しかしサーバーがプログラムのエラーのせいで異常な状態である場合、サー

バーを再開しなければなりません。被験者 PCが故障している場合、新しい PCで始める

ことができます。ラン・メニューからコマンド「Discard Client」でクライアントテーブル

からのその PCを外してしてください。新しいクライアントを起動し、それがクライアン

トテーブルに表示されたら、手動で新しいクライアントのクライアントフィールドを選択

し古いクライアントのフィールド上にそれを移動させることにより、それをクラッシュし

たコンピューターで参加していた被験者に割り当てることができます。

5.10 実験者 PCがクラッシュしたら

z-Treeがクラッシュしたら下記の手順を行う必要があります:

• z-Treeを再開します。

• クライアントのテーブルを開きます。• メニュー「Run/Restart All Clients」でクライアントをすべて再開します

94

クライアントが接続しない場合は、クライアントの PCで再度手動でクライアントを接

続してください。手動でクライアントを接続するためには <alt―[F4]> で z-Leafを中止

し、また z-Leafを再開します。

クライアントが接続しない場合、方法が 4つあります:

• クライアントをすべて手動で再開します。• しばらく待った後 (4分までかかることがあります。)クライアントを再開します。

• 実験者 PCをシャットダウンします（それで不十分ならウィンドウズを出て再度ロ

グインします）

• 別のコンピューター上の z-Treeを始めます。

•「Run/Restore Client Order」メニューでクラッシュしたセッションと同じ順にクラ

イアントをソートします。

•「Run/Reload database」メニューでテーブルをすべて回復します。テーブルが各ピ

リオドの後に格納されるので、最後のピリオドが終了された時の状態を回復するこ

とができます。

• どれだけのピリオドがプレーされたかをチェックします。summaryテーブルある

いは subjectsテーブルにこの情報があります。

• 以前に実行していたトリートメントを開きます。nピリオドが実行済みの場合、練

習ピリオドの数を-nにセットする (マイナスの n)。

•「Run/Start treatment」で、トリートメントを再開する。

5.11 被験者が損失を出した場合の処理

被験者による損失は次のソースによって補填されます:

1. 前の実験の利益

2. 一時支払い

3. 参加報酬

4. セッション中に注入された金額

被験者が損失を出した場合、それを伝えるメッセージがスクリーンに現われます。この

メッセージのテキストはトリートメント (background中の)に定義されます。最初の 2つ

のソースが損失を補填できず、参加報酬で補填できる場合、参加報酬を使用するかあるい

はゲームから離脱するか、今本人が選ぶことができることを被験者に通知するメッセージ

95

を表示します。被験者が参加報酬を使用する場合、被験者は継続してプレーできます。被

験者がその人の損失を補填するのに参加報酬を使用しないことに決めた場合、被験者は

「BancruptShowupNo」状態になります。また、またその被験者はサーバーから外れます。

参加報酬が使用され、使い尽くされた場合、被験者のスクリーンに損失を出した旨を伝え

るメッセージが表示されます。

このメッセージは質問で終えることができます。被験者が「Yes」を備えたこの質問に

答える場合、彼または彼女は BancruptMoreYes状態に到着します。「No」と答えることに

よって、彼または彼女は BancruptMoreNo状態に到着します。この場合、さらに、実験者

はサーバーから被験者を外さなくてはなりません。ダイアログボックスは「state」フィー

ルドのダブルクリックにより現われます。

ここで 3つの選択肢があります:

1. 被験者が継続することを認めます。この場合、現在の損失より高い額をフィールド

「Amount injected」に入力する必要があります。あなたは被験者にこの額を払わせ

ることも、それをゲーム中の貸し付けであると考えさせることもできます。ゲーム

の結果この額を加味すると被験者の報酬がマイナスでありうる場合は注意が必要で

す。それは被験者の利益と一緒に示されませんしまた paymentファイル中で考慮

されません。つまり、あなたが paymentファイル中で示された額に入力された額

を加味する必要があります。paymentファイルはそのように計算されることでよう

やく被験者の純支払高を表示します。

2. 別の被験者が外された被験者の役割を引き受けます。この場合、利益はすべて 0に

リセットされます。またその PCで継続することができます。

3. 被験者が途中でゲームをやめます。それでグループ・サイズが変わるかもしれない

し、そのためにアクティブな被験者についての情報がもはや正確でないかもしれな

いので、注意する必要があります。

5.12 サーバーによって作成されるファイル

次のファイルは実験の間に作成されます。それらは拡張子によって識別されます。

• pay　 paymentファイル　被験者の名前と利得

• adr　被験者のアドレス

• sbj　アンケートの結果。被験者の名前なし。

96

• xls　セッションの間に示されるテーブルをすべて含んでいます。テーブルがピリ

オド順に格納されるので、それらを扱うために準備を必要とします。第 1の列はト

リートメント番号、第２の列はテーブルの名前、第３列はピリオドです。これらの

3列によって全体のファイルをソートするとよいでしょう。その後、テーブルは個

別のテーブルにコピーすることができます。

• gsf　バイナリフォームの GameSafeこれは判読可能なファイルへエクスポートす

ることができます。このファイルは非常に巨大になります。

セッションの開始時間はファイル名として使用されます。そのフォーマットは YYM-

MDDHM です。YY は年、MM は月、DDは日、Hは時間 M は分を意味します。このよ

うに、セッションのスタート時間は容易に確認することができます。時間は次の表に相当

します:

また分は次の表に相当します。

5.13 データ分析

xlsファイルはデータ分析に容易に利用できます。しかしツール・メニューには分析を

さらに簡単にするツールがあります。これらのコマンドは、異なるテーブルを個別のファ

イルに分けたり分析用の大きなファイルへ適切なファイルを統合することを可能にしま

す。ファイルの分割をする場合、最良の方法は新しいディレクトリーにデータ・ファイル

をすべてコピーし、次に、Separate Table をすべてのファイル (<Ctrl>を押しながらク

リックで 1つのダイアログボックス内のファイルをすべて選択することができます)に適

用することです。統合には MergeFiles を適用します。メニューから選択するとダイアロ

グボックスが現われます。このダイアログボックスにファイルを加えます。それらはすべ

て比較可能な構造である必要があります。例えばすべて subjectsテーブルを持っていなく

てはなりません。ただしテーブルすべてに同じ変数がある必要はありません。これで統合

されるテーブル内の変数をすべて含んでいるファイルが書き出されます。

97

6 インストール

6.1 ファイルサーバを伴うシステムへのインストール

z-Treeをインストールする最も容易な方法は、ファイルサーバの共通のディレクトリ

に z-Treeおよび z-Leafを入れることです。サーバーはディレクトリへ読み書きのアク

セスをし、クライアントは読込みだけのアクセスをおこないます。z-Treeがスタートす

ると、このディレクトリの中にあるファイル server.eecにサーバー PCの IPアドレス

を書き込みます。z-Leaf は、このファイルの中にあるサーバーのアドレスを読み、この

マシン上の z-Treeに接続します。

6.2 ファイルサーバのない時のインストール

z-Treeおよび z-Leafは、共通のファイルサーバにアクセスしない、異なるコンピュー

ター上で実行することができます。あなたがインターネットを通して実験を実施したけれ

ば、このオプションが必要です。ファイルサーバを利用する場合と違い、z-Leaf にとっ

て z-Tree が機能している場所を知る簡単な方法はありません。そこで z-Leaf は自分

のディレクトリか、c:\expeco\conf.に server.eecを持ってなくてはなりません。ク

ライアントを立ち上げたとき、z-Treeの IPアドレスはオプション/serverで設定でき

ます。

z-Tree および z-Leaf が共通のディレクトリから走らない場合、「Restarts all

clients」は働きません。問題がある場合、クライアントを手動で開始しなければなりま

せん。

6.3 テスト環境のセット・アップ

プログラムのテストには複数のコンピューターを必要としません。z-Tree と 1つ以

上の z-Leaf を 1台のコンピューター上で実行することができます。しかしそのときに

は z-Leafに異なる名前を与えなければなりません。そのために、コマンドライン・オプ

ション/nameを使用します。例えば「z-Leaf/name A」で一度、および「z-Leaf/name

B」でもう一度、と z-Leafを 2度実行することができます。

98

6.4 実験を自国語で実行する

z-Tree の中のコマンドはすべて英語です。被験者に対するほとんどのテキストは実

験者によって定義されますので任意の言語を使えます。しかしながら z-Leaf の中のエ

ラー・メッセージは無視できません。z-Tree の中のデフォルト言語はドイツ語です。

z-Treeのメニュー、あるいはコマンドライン・オプションをもちいて z-Treeの中の言語

を変えることができます。z-Leafの中のテキストを変更するためには、コマンドライン・

オプションを使用しなければなりません。それは/language lanという形式で行ないま

す。あなたの環境内でこれを変更したければ、あなたの言語の選択を設定する z-Treeの

ショートカットを作成することができます。

6.5 1つ以上の z-Treeを実行する

あなたが 1台のコンピューター上で 2つ以上の z-Tree を実行したい時には、互いを

区別するためにある識別を使用しなければなりません。この識別はチャンネルと呼ばれま

す。チャンネルはコマンドライン・オプション/channel chで設定されます。チャンネ

ルを通じて z-Leafが z-Treeへの接続を確立します。一度に機能するチャンネルは 700

以上あります。1つのセッションに属する z-Leaf と z-Treeは同じチャンネルを使用し

なくてはなりません。

Tips:あなたが複数の z-Treeを同時に実行するとき、次の z-Treeを始めるまで、最低

2分待ってください。そうすると、各インスタンスは別のセッション ID を持ちます。こ

れはデータ分析をより容易にします。

6.6 インストールの例

このセクションでは、チューリヒの実験室でどのようにインストールされているか述べ

ます。それはどこにファイルを格納するか z-Treeに指示するコマンドライン・オプショ

ンを使用します。これらのオプションは次のとおりです:

/xlsdir xlsファイルが格納されるディレクトリを設定します。

/sbjdir 被験者ファイルが格納されるディレクトリを設定します。

/datadir xlsおよび subjectsfileが格納されるディレクトリを設定します。

99

/adrdir アドレス・ファイルが格納されるディレクトリを設定します。

/paydir paymentファイルが格納されるディレクトリを設定します。

/privdir adressおよび paymentファイルが格納されるディレクトリを設定します。

/gsfdir GameSafeが格納されるディレクトリを設定します。

/tempdir 一時ファイル@lastclt.txt、@db.txt および@prevdb.txt が格納されるディレ

クトリを設定します。

/datadir トリートメントとアンケートのファイルが自動的に格納される (それらが走る前に)

ディレクトリを設定します。

/leafdir ファイル server.eecが格納されるディレクトリを設定します。

チューリヒのインストールは次のディレクトリ構造を持っています (図 6.25):

Figure 6.2 チューリヒにおける z-Treeのディレクトリ構造

「ztree experiments」はショートカットです:

z-Tree /datadir expdata /leafdir ..\setminus zleaf /privdir priv

/tempdir temp /gsfdir temp

また、「ztree test」はショートカットです:

z-Tree /dir testtrash /leafdir ..\setminus zleaf

実験者はすべてのディレクトリ中で読み書きを許可されています。被験者は、zleaf

ディレクトリ中の読みのみ許可されています。私たちは z-Tree と違うディレクトリに

100

z-Leaf を置きました。被験者はこのディレクトリにのみアクセスします。アクセスは読

み取り専用です。z-Treeが実行できるところならどこでも、z-Leafを自動的に実行する

ことができるように、z-Treeのオプション中に z-Leafのディレクトリを設定します。

101