eYACHO/GEMBA Noteで
アプリケーションを作る

～ 実践的なアプリ開発 ～

2025年10月23日
株式会社MetaMoJi

目次

1 はじめに

eYACO/GEMBA Noteは、今現在生じていることを手書き、テキスト、写真、音声、動画などで素早く記録することができるデジタルノートアプリである。また、複数の離れたメンバーと同じ図面や画像に手書きやテキストを書き込んだり、現場でレポートを共同で作成・更新するなど、チーム作業の支援や、さまざまな情報を一元管理して、「現場」での業務の生産性を向上することを目的とする。

単なるノートアプリではなく、目的に応じたビジネス帳票を柔軟に作成、蓄積された帳票から集計結果を導き出したりすることができるカスタマイズ性に富んだ「アプリケーション開発基盤」と見なすことができる。

1.1 目的

アプリケーション開発フレームワークの主な役割は、開発の効率化と品質の向上である。通常、ソフトウェア開発のために事前準備されたコンポーネントやテンプレートを利用することで実現する。しかしながら、eYACHO/GEMBA Noteの開発環境は、独自技術およびユニークなカスタマイズ手法に基づくため、著名なフレームワークと比べてまだまだ一般的とは言い難い。

本ドキュメントは、eYACHO/GEMBA Noteの「フレームワーク化」を目指して、よく使われるフォーム部品の細かな設定、ノートの検索や集約を実行するアグリゲーション検索条件をパターン化してアプリ開発の仕様を記述しやすくする。そこで用いる記述方法の一部を利用して、生成AIへ与える要求文に用い、SQL式を自動的に作成することも試みる。

また、バイナリデータの取り扱い方、外部システムとのデータ連携について実装例を示しながら解説する。さらにはアプリケーションの設計から、試験、再公開の工程までを網羅して、GEMBAアプリ開発全般についての1つのモデルケースを提起する。

1.2 想定するユーザー

本書を利用してeYACHO/GEMBA Noteアプリを本格的に開発してみようというユーザーは、すでに初級編と位置づける「eYACHO/GEMBA Noteでアプリケーションを作る ～ はじめてのアプリ制作 ～」に沿ってアプリ開発の基本知識をマスターしていることを前提とする。したがって次の知識をすでに有していると仮定する。

• フォーム部品を配置して帳票を作成する。
• 対象となる帳票のタグスキーマを設計・定義する。
• 帳票上のフォーム部品と設計したタグスキーマの関係を紐づける。
• 定義したタグスキーマを対象にシンプルなアグリゲーションを定義する。

リレーショナルデータベースシステムにおけるデータの操作や定義を行うための専用言語SQL（Structured Query Language）の知識、RESTサーバーを構築するスキルを持っていると、高度な機能をもつアプリケーションを実装方法の理解が早く進むと思われる。

1.3 各章の概要

本書は、全部で7章から構成される。それぞれの章の概要とその章で習得するポイントを説明する。

2章「アプリケーションの設計」

eYACHO/GEMBA Note上にアプリを開発するには、ページ上にフォーム部品を配置し、定義したタグスキーマと紐づけ、アグリゲーション検索条件を実装する。この一連の作業を確実に実行し、目標となる機能を実装し、その品質を保証するため、あらかじめアプリケーションを設計する。

3章「フォームの細かな設定」

eYACHO/GEMBA Noteでは、フォームやアイテムを構成するためのフォーム部品が揃っている。これらをノートや図形の上に配置して、定型的なフォームを作成する。ここでは部品の挙動をもっと豊かにする細かな設定について紹介する。

4章「アグリゲーションのパターン化」

アグリゲーションの実行処理と結果出力のパターンを分類し、設計の工程、仕様の記述方法や表現を詳しく解説する。その記述表現を生成AIに与えて、SQLを自動的に生成する要求文（プロンプト）の記述方法についてもふれる。

5章「バイナリデータの利用」

eYACHO/GEMBA Noteは、画像、PDF、動画、音声を取り扱うことができる。ここではそのようなバイナリデータを処理する手法についてサンプルを提示する。

6章「データの連携」

eYACHO/GEMBA Noteも単独ではなく他の製品やサービスの情報を必要とする場合がある。このような外部データ連携を必要とする場合、どのような形態でデータのやりとりが可能になるのかサンプルとともに解説する。ただし、外部システムとの認証については、本書ではふれない。

7章「アプリケーションの試験」

実装したアプリケーションが設計通りに動作するか、設定した品質に達しているか設計書から試験項目を抽出し、各項目をチェックできるようにする。

付録

各章で述べた内容への補足、具体的な例および参照するサイトなどを提示する。

1.4 動作確認サンプルについて

各章の中で説明のために用いたフォーム、タグスキーマ、アグリゲーション検索条件は、以下に示すバックアップファイルの中に含まれる。読者が実際に定義と動作を確認するため、ダウンロードして、開発パッケージを復元することを想定している。その他に共有リスト、インポート用のCSVファイル、テストケース生成ツールPICTに与えるサンプルのテストケースファイルなども配置している。

バックアップファイル

バックアップファイルから復元した開発パッケージの中のフォルダとノートを次のように提示する。サンプルを動作確認する場合、この表で示される所定のノートを開く。処理パターンと出力パターンについては4章で述べる。

共有リスト

図面関連

テスト関連

1.5 コード記述と操作コマンドについて

本書では、コード類の説明とコマンドの実行例を示すために数字、記号を使い分けている。それぞれの意味は以下の通りである。

コードの書式の例

SELECT * 
FROM P_TABLE  
WHERE name != '' -- コメント

SQLのような式やコードを提示したときは、着目する箇所に – を付与し、その後ろにコメントを記入する。

コマンド実行の書式の例

> sqlite3 property_management.db

コマンドを実行するときは、Windowsコマンドプロンプトを用いて行う。コマンドの先頭に > シンボルを配置し、その後ろにコマンドを記述する。

1.6 商標について

本文中に記載されている会社名、製品名等は、各社の登録商標または商標である。本文中ではTM、(R)マーク等は明記していない。

• ChatGPTはOpenAIの商標です。
• Excel、Visual Studio Code、VS Code、Windowsは、米国Microsoft Corporation の米国およびその他の国における登録商標である。
• FastAPIは。@tiangoloの米国およびその他の国における登録商標である。
• iPad、iPhone、macOSは、米国および他の国々で登録されたApple Inc.の商標である。
• Linuxは、Linus Torvalds氏の日本およびその他の国における登録商標または商標である。
• Node.jsは、Joyent, Inc.の登録商標または商標である。
• その他記載された会社名、製品名等は、各社の登録商標もしくは商標、または弊社の商標である。
• 本書は、株式会社MetaMoJiが作成したものであり、本書の著作権は、株式会社MetaMoJiに帰属する。

1.7 特記事項

本書は、eYACHOとGEMBA Noteの両方の製品におけるアプリケーション開発について述べるが、本章以降では、製品の呼称はGEMBA Noteのみとする。eYACHO/GEMBA Noteアプリケーションのことを「GENBA Noteアプリ」「GEMBAアプリ」あるいは単に「アプリ」と呼ぶ。

1.8 用語の説明

本ドキュメントに登場するよく使われる言葉や略語について説明する。

1.9 参考ドキュメント

アプリケーション開発に関連するドキュメントは次の通りである。

• eYACHO/GEMBA Noteでアプリケーションを作る ～ はじめてのアプリ制作 ～
• GEMBA Note for Businessマニュアル
• パッケージ開発ガイド 日本語 (zipファイル)
  • 次の3つのドキュメントが含まれる
    • アグリゲーション検索条件編集ガイド
    • カスタムUI設定ガイド
    • パッケージ開発ガイド
• フォーム作成ガイド 日本語
• 管理者ガイド 日本語

2 アプリケーションの設計

この章では、GEMBA Note上でアプリケーション開発を始めるにあたって、準備段階での設計の作業と手順および設計する対象物とその定義の記述方法について述べる。

2.1 設計の流れ

GEMBA Noteアプリの開発は、開発パッケージを準備し、そこにフォーム（帳票）、タグスキーマ、アグリゲーション検索条件を作成し、それらを細かく設定する作業になる。その手順を示したのが次の図である。

設計する箇所は図中の[3]から[7]の箇所になる。それらの作業を開始する前にまず要件のヒアリングから行う。

[1] 要件をヒアリングする

業務に適したGEMBA Noteアプリを実装するため、利用者から要望を聞き、アプリで何をどう解決していきたいかを詳細に把握する。

[2] 要件を定義する

ヒアリングした内容から業務要件、機能要件、非機能要件として明確化し、要件定義書を作成する。

[3] UIを設計する [3]

機能要件の一つである外部仕様として業務に適するユーザーインターフェースを定義する。

[4] タグスキーマを設計する [4] [5]

ユーザーインターフェースを構成するフォーム上に配置した各フォーム部品がどのタグプロパティに紐づくか関連付けする。

[5] アグリゲーションを設計する [6] [7]

アグリゲーションが処理する内容と制約を具体化する。

2.2 要件の定義

要件の定義はソフトウェアの開発にとって最も重要な工程の一つである。システムやアプリケーションで実現したい業務、機能、非機能等を「要件定義書」として記述する。要件は利用者しかわからないので、本来は利用者が作成すべきだが、慣例的に開発会社がヒアリングと確認を行いつつ作成することが一般的である。

企業ごとに要件定義の内容は異なるが、一般的には次のような構成になる。

• システム化（開発）の目的
• 業務要件
• 機能要件
  • 外部機能（目に見える機能：画面、帳票等）
  • 内部機能（目に見えない機能：データ、I/F、バッチ、外部連携等）
• 非機能要件
  • 可用性（信頼性）
  • 性能
  • セキュリティ
  • 移行性
  • 保守性
  • 留意事項

屋外で利用するケースが多いGEMBA Noteアプリの特徴を鑑みると、次の内容が記述されていることが望ましい。

表2-2-1 目的と業務要件

機能要件：機能一覧とその概要を記述する

表2-2-2 機能要件

非機能要件：

表2-2-3 非機能要件

2.3 UIの設計

要件定義書に基づき、実現する帳票ごとに、入力フィールド、出力フィールド、ボタンのページ上での配置を明確にする。
ページに張り付けるタイプの「アイテム」としてユーザーインターフェースを設計する場合もあるので区別する。

2.3.1 フォームの体裁

GEMBA Noteのフォーム（帳票）は、ページ上に業務に必要な情報を記録していく。そのためのページの形式を定義する。

表2-3-1 フォーム体裁の記述

表2-3-2 フォーム体裁の例

2.3.2 アイテムの体裁

ページ上に張り付けることができる共有化した部品をアイテムと呼ぶ。その形式を定義する。

表2-3-3 アイテム体裁の記述

表2-3-4 アイテム体裁の例

2.3.3 フォーム部品の定義

ページやアイテムに張り付けるフォーム部品（フィールド）を定義する。

表2-3-5 フォーム部品定義の記述

表2-3-6 フォーム部品定義の例

2.3.4 フォーム部品の配置位置

各フォーム部品をページやアイテム上にどのように配置するかは、おおよそのイメージが伝わるように、実際にGEMBA Noteを使ってフォームやアイテムのプロトタイプを作成してイメージ可能にする。

2.3.5 ボタンの定義

フォーム上にボタンが配置してあれば、その名称やアクションの内容を記述する。

表2-3-7 ボタン定義の記述

表2-3-8 ボタン定義の例

2.3.6 複数ページ間の関係

複数のページをもつアプリでは、ページ間でデータを転記したち、値を参照して計算・加工する場合がある。そのときにどの帳票のどのフィールドが、別の帳票のどのフィールドと関係しているか明確にする。

2.3.7 テンプレートの定義

よく利用するページは用紙テンプレートとして、ノートはノートテンプレートとして再利用することができる。どのページおよびノートを再利用できるようにさせるか決める。

ノートテンプレートの定義

表2-3-9 ノートテンプレート定義の記述

表2-3-10 ノートテンプレート定義の例

用紙テンプレートの定義

表2-3-11 用紙テンプレート定義の記述

表2-3-12 用紙テンプレート定義の例

2.3.8 カスタムUI設定

GEMBA Noteの編集画面は初期設定では、全ての利用できるメニューやコマンドが表示されている。ある特定の帳票は、数多くのコマンドやメニューはユーザーにとって不要なものも存在する。そこで「UI定義ファイル」を作成して、画面上の各領域に何を配置するのか定義する。

表2-3-13 カスタムUI設定の記述

コマンドは、参考ドキュメントの「カスタムUI設定ガイド」に記載されている名称を記入する。

表2-3-14 カスタムUI設定の例

2.4 タグスキーマの設計

GEMBA Noteでは、ページや図形と、その上に配置したフォーム部品の構造を定義するために「タグスキーマ」と呼ばれる属性（タグプロパティ）の集合体を用意している。構造を定義することによって情報の検索、集約、加工（計算）を行うことができる。

なお、ここで定義したタグスキーマとタグプロパティの構造は、4.4節にて述べる生成AIからSQL式の自動生成のプロンプトとして用いる。そのため、Markdownでの記述方法も示す。

2.4.1 タグスキーマの定義

タグスキーマは、データベースにおけるテーブルのようにデータを格納する入れ物である。GEMBA Noteでは開発パッケージ内において、ユニークなIDで定義をする必要がある。

表2-4-1 タグスキーマ定義の記述

設定箇所 は、フォーム部品とタグプロパティをリンクづけするために必要とする。

表2-4-2 タグスキーマ定義の例：物件

上記タグスキーマの表は、次のMarkdown記述をHTMLに変換したものである。

| タグID | 日本語表示名 | 設定箇所 |
| --- | --- | --- |
| Property | 物件 | ページ |

タグスキーマを構成する要素がタグプロパティである。タグプロパティの定義を明確にする。

表2-4-3 タグプロパティ定義の記述

表2-4-4 タグプロパティ定義の例

Markdown記述例：

| プロパティID | 日本語表示名 | データの型 |
| --- | --- | --- |
| Name | 名称 | 文字列 |
| Type | 物件タイプ | 文字列 |
| Price | 価格 | 整数 |
| Address | 住所 | 文字列 |

2.4.2 フォーム部品とタグプロパティのリンク

フォーム部品に入力した値が対象タグスキーマのどのタグプロパティに割り当てられるのか関係を定義する。

表2-4-5 リンク定義の記述

表2-4-6 リンク定義の例

Markdown記述例：

| 見出し/プレースホルダ | タグプロパティID |
| --- | --- |
| 名称 | Name |
| 物件タイプ | Type |
| 価格 | Price |
| 住所 | Address |

2.5 アグリゲーションの設計

GEMBA Noteではタグスキーマにリンクしたフォーム入力データを「タグデータベース（タグDB）」として操作を行うことができる。それが「アグリゲーション」と呼ばれる集約機能である。ここではアグリゲーションを定義するときに必要な要素について表形式で表現する。

なお、ここでも定義したアグリゲーションの構造を、4.4節にて述べる生成AIからSQL式の自動生成のプロンプトとして用いる可能性があるため。Markdownでの記述例を一部だけ示す。

2.5.1 アグリゲーションの定義

アグリゲーションの挙動を規定する構成要素を次の表にまとめる。

表2-5-1 アグリゲーション定義の記述

表2-5-2 アグリゲーション定義の例

Markdown記述例：

| 定義項目 | 記述内容 |
| --- | --- |
| 設定ID | propertyListWithType |
| 日本語表記 | タイプ別 物件一覧 |
| 結果タグスキーマ | Property（物件） |
| 検索パラメータ | TYPE |
| コネクタ | M-N節で定義する（別途、別に定義する） |
| SQL | {#物件タグスキーマ}の{#物件タグプロパティ}から全てのタグプロパティの値を取得するSQLiteのSQLを生成してください。<br>ただし、検索パラメータ{TYPE}は、物件タイプを意味する。この変数をつかって絞り込む。価格が高いものから順番に表示する |

2.5.2 検索パラメータの定義

アグリゲーションの検索条件を定義するとき、外部からの変数的な値を参照して利用するためには検索パラメータを用いる。

表2-5-3 検索パラメータ定義の記述

表2-5-4 検索パラメータ定義の例

Markdown記述例：

| 定義項目 | 記述内容 |
| --- | --- |
| パラメータID | TYPE |
| 日本語表記 | 物件タイプ |
| パラメータ型 | 文字列 |
| 初期値 | アパート |
| 選択肢 | なし |
| UIタイプ | 指定しない |

2.5.3 コネクタの定義

コネクタは、どこのデータリソースから検索するかを定義する。そのタイプごとに設定する項目は異なる。

表2-5-5 コネクタ定義の記述

表2-5-6 コネクタ定義の例

2.5.4 実行処理

アグリゲーションの実行は、どこから行うのか（ナビゲーションメニュー、ボタン、入力フィールド）、実行結果の表示を想定した図を準備する。

表2-5-7 実行処理の記述

表2-5-8 実行処理の記述例

2.6 運用の設計

GEMBA Note上で開発したアプリを安定して運用するために、運用ルール、障害対応の方法などの情報をまとめておく。 基本的に、運用を設計するには、アプリケーションを、Who（誰が）・When（いつ）・Where（どこで）・How（どのように）使用するか、またどうすれば安定してサービスを提供できるかを設計する。これにGEMBA Note独自の運用方法や手順を考慮する。

表2-6-1 運用設計項目と記述例

フォルダ構成例

チームフォルダ
|-- 南関東営業
|    |-- 東京営業
|    |   |-- 東東京営業
|    |   |-- 西東京営業
|    |-- 神奈川営業
|    |-- 千葉営業
|    |-- 埼玉営業
|    
|-- 北関東営業
|    |-- 茨城営業
|    |-- 栃木営業
|    |-- 群馬営業
|
|-- 甲信越営業
|   |-- 山梨営業
|   |-- 長野営業
|   |-- 新潟営業

開発パッケージ管理項目例

表2-6-2 開発パッケージ定義の記述

表2-6-3 開発パッケージ定義の記述例

もしアグリゲーションの中でパッケージパラメータを利用するものがあれば、記載する。

表2-6-4 パッケージパラメータ定義の記述

表2-6-5 パッケージパラメータ定義の記述例

2.7 Markdown形式の仕様書を作成する

ここまで述べてきた設計項目をMarkdown形式のファイルにして仕様書（設計書）を作成する。仕様書の作成は、一般的にはOffice文書を利用する場合が多いが、Markdownを用いると次のようなメリットがある。

• プレーンテキストで記述が可能。そのため Git での自動マージに対応できる。
• Excel ほど多機能でないが、テーブル作成や段落表示・リストなど最低限の構造体が作成でき、VS Code や GitHub などでプレビュー表示が可能である。
• テキスト量や列数が多くなく、かつ高頻度で修正される設計書に最適と思われる。
• GitHub を用いると、プレビューによる差分確認がわかりやすい。
• 表（テーブル）を簡易的に表現できるので、生成AIのプロンプトに与える構造体として利用できる。
• スクリプト言語によって文書からの情報が抽出・加工がしやすい。

ちなみに本ドキュメントもソースファイルは複数のMarkdown形式ファイルから構成されている。複数のMarkdownファイルを1つに統合し、HTML形式ファイルへ変換している。

2.7.1 Markdown記法の基本

本書やGEMBAアプリの設計に用いている主なMarkdown記法をまとめておく。

見出し

見出しの先頭部分に#をつける。#が増えることにより、小さな見出しになる。

# 大見出し
## 中見出し
###　小見出し

リスト

項目や文章を箇条書きにするときに用いる。通常の見出しと番号付き見出しがある。

通常見出し：

# 会社組織の例

- ビル事業本部
  - 国内法人営業部
  - 海外法人営業部
  - 事業推進部
- 住宅分譲事業本部
  - 営業部
  - 事業企画部
  - 事業推進部
- 都市開発事業本部
  - 営業部
  - 事業企画推進部

通常見出しの表示例：

番号付き見出し：

# カレーの作り方

1. 野菜を切る
   1. 玉ねぎは皮をむき、たて半分に切る。
   1. にんじん、じゃがいもは皮をむき、食べやすい大きさの乱切りにする。
1. 炒める
   1. 鍋にサラダ油大さじ1を入れ、中火～強火で表面にしっかり焼き色がつくように肉を炒める。
   1. 玉ねぎを弱火～中火でよく炒める。
   1. 玉ねぎが茶色くなってきたら、にんじん、じゃがいもを入れてさらによく炒める。
1. 煮る
   1. 水とローレルを入れて煮込む。
   1. よく沸騰したら火を弱め、アクをとり、材料がやわらかくなるまで弱火～中火で煮込む。
1. ルウを入れる
   1. いったん火を止めて、ルウを割り入れ、よく溶かす。
   1. 再び、弱火でとろみが出るまで 煮込む。
1. 仕上げる
   1. 最後にガラムマサラを適量ふり、味を調える。
   1. お皿にごはんをよそい、カレーをかける。

番号付き見出しの表示例：

強調

文章の一部など、強調したい箇所を「**」で囲むと強調された文字になる。

**ここ**が、重要です。

表

表（テーブル）は パイプ「｜」を使って表現する。

| TH | TH |
| --- | --- |
| TD | TD |
| TD | TD |

表の表示例：

表の2行目にコロン「：」を付与して、右寄せ・中央寄せ・左寄せを表現する。コロンを入れない場合は左寄せになる。

• 左寄せの場合 :–
• 中央寄せの場合 :–:
• 右寄せの場合 –:

2.7.2 Markdown向けエディタ

Markdown形式の文書を作成するためのおすすめのエディタを紹介する。

• ATOM
  • GitHubが開発したエディタであり、Mac、Windowsなど多くの環境で使用することができる。
• Visual Studio Code
  • Microsoft製のエディタであり、「Open Preview」を選択することで、プレビューを確認することができる。

2.7.3 Markdown仕様書の例

付録1：不動産管理アプリケーション仕様書にGEMBAアプリ開発教則本で試用した不動産管理アプリ開発の仕様書を例示しているので、参考にする。

この仕様書には、試験項目を自動的に取得できるように、抽出を開始する箇所（見出し）には、拡張記法 {.testitems} を付与している。詳しくは第7章で述べる。

### 見出し {.testitems}

3 フォームの細かな設定

この章では、GEMBA Noteで帳票を制作する上で、フォーム部品のよく利用されるであろう便利な設定について述べる。

フォーム部品の設定を変更するには、対象となる部品を長押し/右クリックし、コンテキストメニューの フォーム を選択し、<対象部品名>の設定 を選択する。下の例は、1行テキストフィールドの場合を示している。

ここから後ろの節では、この操作の後からの手順を説明する。

3.1 編集できるユーザーを設定

ユーザーによってフォーム部品を編集できるかどうかを仕分けるには、高度な設定 > 操作可能な人 から設定する。下図のようなユーザーを検索するダイアログを通して編集可能なユーザーを設定する。

3.2 編集できる条件

ノートのタイトルのような属性情報からもフォーム部品を編集できるかどうかを仕分けることができる。次の手順で、編集可能とするルールを設定する。

1. 「高度な設定」ダイアログ上の 編集条件の設定 を選択する
2. ルールの追加 ボタンをクリックする
3. ルールとなる対象は、ノートのタイトル、名前、チーム名、フォルダ名、ノートのタグ、タグプロパティの中から選ぶ
4. ルールの条件を満たすオペレータとその値を指定する
5. ルールが満たされない時の文言を記入する

3.3 条件付き書式

フォーム部品は、ある条件を満たすと書式を変更することができる。ここでは1行テキストフィールドを用いて説明する。

条件付き書式は以下の手順で設定する。

1. フィールド設定 > 条件付き書式 を選択する
2. ルールを追加ボタンをクリックする
3. ルールの条件を満たすオペレータとその値を指定する
4. ルールを満たした場合のスタイルに対するアクションを設定する

以下の例では、「赤」と1行テキストフィールドに入力すると、背景色が赤色になるルールを定義している。

3.4 順序入力

複数のフォーム部品を連続して自動的に入力を促す機能である。入力漏れを軽減し、入力作業の省力化につながる。

利用するには、ページに配置した対象となるフォーム部品を投げ縄で選択し、コンテキストメニューの中から フォーム > 続けて入力させる を選択する。部品の配置位置により、左から右、上から下の優先順で矢印が部品間にふられる。始点となる部品をクリックすると、矢印の順序で入力が促される。

順序入力を解除させるときは、対象となるフォーム部品を投げ縄で選択し、コンテキストメニューのフォーム > 続けて入力を解除 を選択する。

3.5 アイテムの作成と利用

「アイテム」とは、ページ上に複数張り付けることのできるUI部品である。GEMBA Note製品に組み込まれているTODO、日付スタンプ、付箋などがその例である。フォームと同じようにタグスキーマを設定し、構成される部品フォームに紐づけすることができ、アグリゲーション検索条件によって集約が可能となる。

3.5.1 アイテムの定義例

下に示した例は、顧客の訪問者カードの例であり、四角い図形の上に日時入力フィールド、1行テキストフィールド、電話番号フィールドが配置してある。それぞれのフィールドは、タグスキーマVistorのタグプロパティvisitedDate、customerName、phoneにリンク付けしている。

アイテムの体裁

表3-1 訪問者カードの体裁

フォーム部品の定義

表3-2 訪問者カードのフォーム部品

タグスキーマの定義

表3-3 訪問者カードのタグスキーマ

タグプロパティの定義

表3-4 訪問者カードのタグプロパティ

リンクするフォーム部品とタグプロパティID

表3-5 訪問者カードのリンク

3.5.2 アイテムの登録

複数の部品から構成されるアイテムは、通常は全体をグループ化して、1つの部品のようにする。これを再利用可能にするために、コンテキストメニューの 操作 > アイテムを登録 を選択して登録する。登録したアイテムは、アイテム一覧メニュー（＋ > アイテムを追加）から利用する。

3.6 緯度と経度の取得

フォーム部品のボタンには、現在位置での緯度と経度を計測するコマンド「現在位置をタグに反映」が備わっている。図面ユニットと組み合わせて、現在地を地図用にプロットするとき利用される。

利用するには緯度と経度を入力させる数値フィールドをページ上に配置する。これらの値をタグプロパティとして構成するタグスキーマを準備する。それぞれの数値フィールドを対象するタグプロパティにリンクさせておくと、ボタンを押したときに現在位置の緯度と経度が計測されて入力される。

フォーム部品の定義

表3-6 緯度・経度を取得するのフォーム部品

タグスキーマの定義

表3-7 緯度・経度を表現するタグスキーマ

フォーム部品とタグプロパティIDのリンク

表3-8 フォーム部品とタグプロパティのリンク

3.7 初期値を設定

フォーム部品およびタグプロパティには、ユーザーが操作によって値を与える前に初期値を自動的に設定する機能が備わっている。その方法は2通り存在し、用途によって使い分ける。 なお、初期値の自動設定は、該当するフォーム部品やタグスキーマを含むアイテムやテンプレートを張り付けたときに実行される。

3.7.1 フォーム部品に設定

フォーム部品の1行テキストフィールドおよび日時入力フィールドには、その属性としてアイテム/テンプレート利用設定 が存在し、初期値の値を設定することができる。

1行テキストフィールドの初期値設定オプション（利用時の初期値）

日時入力フィールドの初期値設定オプション（日付）

3.7.2 タグプロパティに関数を設定

タグスキーマを構成するタグプロパティには初期設定として値や関数を設定することができる。 タグスキーマ編集画面からタグプロパティ設定画面上の 式 を選択して、プロパティ初期値 に利用する関数を設定する。

初期値に利用できる関数

初期値に関数を利用するときの注意

ページやアイテムにタグスキーマを設定するとき、コンテキストメニューの タグ > 設定 で対象となるタグスキーマを選択する。関数を初期値として利用する場合は、設定しようとしているタグスキーマのタグプロパティの一覧を表示し、以下のようにチェックが入っていることを確認する。チェックされていないと、ページやアイテムを複製した時に初期値が反映されない。

3.7.3 どちらの方法を利用するか？

初期値の自動設定には2つの方法があることを述べたが、どちらを利用すればよいか、その違いを示す。

開発オプションを購入していない場合は、そもそもタグスキーマを定義できないので、フォーム部品の初期値設定を用いるしかない。 タグプロパティの初期値として関数を設定した場合、フォーム部品へのタグプロパティをリンクせずとも、「隠しフィールド」のごとく、アグリゲーションに用いることができることが利点となる。

3.8 集計結果をフォーム形式として出力

アグリゲーション検索条件の実行結果は、ナビゲーションメニューの ＋ > アグリゲーション > 結果を表にして追加 から「表」として出力する方法は、アプリ開発教則本 で学んだ。

実行結果を横（あるいは縦）に並べたフォーム部品それぞれに出力する形式が「フォーム表形式出力」あるいは「フォーム形式出力」と呼ぶ表示形態である。 次の画像は不動産管理アプリの検索条件をフォーム形式で出力した例である。

フォーム形式として出力するには、1行（あるいは1列）に並べたフォーム部品が1つのタグインスタンスの内容となるようにタグスキーマとそのプロパティをフォーム部品群に設定する。対象となるタグスキーマを1行（あるいは1列）のどこかに設定し、各フォーム部品とタグプロパティをリンク付けしていく作業を行う。この1行を「縦に複製」あるいは「横に複製」することによって、アグリゲーション検索条件が返す複数のタグインスタンスを「行ごと」あるいは「列ごと」に出力する仕組みである。

表形式とフォーム形式の出力方法の違いは次の通りである。

表3-9 表形式とフォーム形式の出力方法の違い

出力結果を再集約する例として、出力結果を他のページに転記する機能があげられる。

3.9 様々なメニュー

フォーム部品の1行テキストフィールド、数値フィールド、および選択フィールドは、選択できる項目をリストとして与えるとプルダウンメニューのように振舞う。カスケードリスト（カスケードメニュー）は、前のリストの選択値によって次のリストの選択候補が切り替わり、多層的に値を決定していく仕組みである。利用例として、企業の部門や部署、住所などがあげられる。

3.9.1 多言語対応の選択メニュー

多言語の選択メニューを実現するには、値を共通にして表示を言語ごとに切り替える。 以下は日英に対応した物件タイプを選択させるメニューを実現する共有リストファイルである。

ファイルの第1行は見出し、2行目以降に選択項目を定義している。 それぞれのファイルを1行テキストのリストに設定するときに、ダイアログ上で表示名と値の順序を選択する。

3.9.2 カスケードリスト

あるフォーム部品で選択した値が別のフォーム部品の選択候補を動的に切り替える場合はよくある。これを一般的には「カスケードメニュー」と呼び、とくにリストボックス形式で表現する場合を「カスケードリスト」という。 例えば会社組織における「本部」「部」「課」、住所を構成する「都道府県」「市区町村」「町名・番地」をUIで選択するときに用いる。GEMBA Noteで、このような多段階のカスケードリストを実現するにはアグリゲーションを利用する。

カスケードリストの仕組み

カスケーディングは、まず前のフォーム部品の選択値が次のフォーム部品に設定されたアグリゲーションの「検索パラメータ」として渡される。データリソースの中からそのパラメータ値と合致する項目を収集して選択項目一覧を提示する仕組みである。

リストの設定から検索パラメータの設定

アグリゲーションは、該当するフォーム部品の設定画面を開き、リストの設定 から アグリゲーション にチェックを入れて、ここに指定する。

アグリゲーション検索条件を指定するときは、その条件が有する検索パラメータをどのタグプロパティから取得するのか指定する。

サンプル3-1 フォーム部品の様々な設定

次のノートを開く。

• 確認項目
  • 編集条件
  • 条件付き書式
  • 順序入力
  • アイテム
  • 緯度と経度を取得
  • 初期値を設定
    • フォーム部品に設定
    • タグプロパティに関数を設定

サンプル3-2 集約結果を表形式からフォーム形式へ

不動産管理アプリのアグリゲーション結果を「表形式」ではなく「フォーム表形式」として出力するサンプルを確認する。次のノートの中に、フォーム部品列を利用した集約結果表示方法を実現する手順を見ることができる。

サンプル3-3 様々なカスケードリスト

次のノートを開く。

• 確認項目
  • 本部、部、課で構成されるカスケードリスト（1行テキストフィールド）
  • カスケードリストを実現するリソースデータ
  • 本部、部、課で構成されるカスケードリスト（選択フィールド）

4 アグリゲーションのパターン化

GEMBA Noteではタグスキーマにリンクしたフォーム入力データをタグデータベース（タグDB）として操作を行うことができる。それが「アグリゲーション」と呼ばれる集約機能である。アグリゲーション検索システムは、各種DBコネクタによって収集したデータの中から検索条件に合ったデータを抽出し、表示、加工するしくみを提供する。

この章は、アプリ開発教則本と本ドキュメントで例示したアグリゲーション検索条件を詳細に解説し、アグリゲーション開発における設計方法と実装手順を学ぶ。

4.1 アグリゲーションの処理パターン

GEMBAアプリ開発を行う上で、アグリゲーション検索条件を設計する際には、アプリの要件に応じて下記の2点を考慮して設計することが重要となる。

1. 実現するべき処理は何か？
2. 処理した結果をどのように出力するか？

つまり処理を司る部分と処理結果をどう表現するかは切り離して設計する。ここでは、「実現するべき処理は何か」について、アグリゲーションを実行処理するときによく見られるパターンを大きく3つに分類し、設計内容を構成する要素とする。

表4-1-1 アグリゲーションの処理パターンの種別

ここからは、それぞれの処理パターンについて特徴をを説明する。

4.1.1 集約パターンとは

GEMBA Noteの各ノート・各ページからタグインスタンスを検索し、結果タグスキーマの構造としてひとつに集約する処理パターンである。

集約パターンの特徴

• このパターンを採用する代表的なアプリ開発要件には以下が挙げられる。
  • 日次ごとに、部署別になど、日々作成される帳票のそれぞれの記入内容をひとつに集約し、一覧表示する。
  • 上記と同様に記入内容を集約し、CSV形式でファイルにエクスポートする。
• この処理パターンではSQLでの検索条件 (およびコネクタの設定) で定めるタグインスタンスの取得範囲は比較的広範囲に設定することが多い。
  • その結果として、多くの場合複数のノート・複数のページから該当のタグインスタンスが取得される。

集約パターンの例

集約パターンに該当するサンプルは次の箇所（節）に提示している。

4.1.2 転記パターンとは

GEMBA Noteのあるノート・あるページから特定のタグインスタンスを検索し、結果タグスキーマの構造でデータを取得する処理パターンである。 言い換えると、あるデータを出力パターンに応じて出力するために、対象のデータをコピーしておく処理パターンである。

転記パターンの特徴

• この処理パターンを採用する代表的な要件の例には以下が挙げられる。
  • ある帳票に記入されている内容を、他の帳票にそのままコピーする (同じ内容を記入しない)
  • あらかじめノートに集約され一覧化されている内容を、CSV形式でファイルとしてエクスポートする。
• この処理パターンではSQLでの検索条件、およびコネクタの設定で定めるタグインスタンスの取得範囲は比較的狭い範囲
  • 多くの場合、特定のノートの特定の1ページに設定することが多い。
• 前節の集約パターンは、GEMBA Noteの各ノート・各ページのタグインスタンスを取得し、結果タグスキーマの構造でタグインスタンスの集約を行う処理パターンであった。転記パターンは集約パターンの中で、タグインスタンスの取得範囲が狭い特殊な処理パターンといえる。
  • ほとんどの場合、1ノート・1ページに存在するタグインスタンスを取得対象とする。

転記パターンの例

転記パターンに該当するサンプルは次の箇所（節）に提示している。

4.1.3 計算パターンとは

GEMBA Noteのあるノート・あるページから特定のタグインスタンスを検索し、その値に対しSQLのSELECT文にて行える数値計算を行い、その結果を結果タグスキーマの構造で出力する処理パターンである。計算を広い意味で捉え、値の変換処理もここに含める。

計算パターンの特徴

• このパターンを採用する代表的な要件には以下の例が挙げられる。
  • ある帳票に記入されている2つの数値データの差分を、同じ帳票上に表示する。
  • 日誌に記載されている各協力会社の工数実績の月単位の合計を表示する。
• この処理パターンは要件によってSQLでの検索条件およびコネクタの設定で定めるタグインスタンスの取得範囲は異なる。
  • 集約パターンと同様に、タグインスタンスの取得範囲を広範囲に設定し、それらの値を基に数値計算を行うこともある。
  • 転記パターンと同様に、タグインスタンスの取得範囲をあるノートのある1つのページに設定することもある。
    • この場合、同ページ内にて計算を行うことが多い。

計算パターンの例

計算パターンに該当するサンプルは次の箇所（節）に提示している。

4.2 アグリゲーションの出力パターン

GEMBAアプリ開発を行う上で、アグリゲーション検索条件を設計する際には、アプリの要件に応じて下記の2点を考慮して設計することが重要であることは前に述べた。

1. 実現するべき処理は何か？
2. 処理した結果をどのように出力するか？

処理を司る部分と処理結果をどう表現するかは切り離して設計することが可能である。ここでは、「処理した結果をどのように出力するか？」について、5つのパターンに分類して解説する。

表4-2-1 アグリゲーションの出力パターンの種別

4.2.1 表パターンとは

アグリゲーション処理で得られた値を、GEMBA Noteの特定のノート・ページに表形式（表ユニットと呼ぶ）で出力する。

表パターンの特徴

得られた値を単にノートに表示するために使用され、表示した値を他のアグリゲーションで活用しない場合に使用される。

コネクタタイプとして Unit が存在するが、表ユニットの値をタグインスタンスとして別のアグリゲーションから取得することもできる。ただし、これを実現するためにはGEMBA Noteがあらかじめ用意しているシステムタグ（ベーシックタグ: ExtractDefinition〈抽出定義〉、SpreadExtractParameter 〈表計算抽出パラメータ〉）を該当の表に設定する必要がある。取得する表の範囲は絶対値で設定するのであるが、表の編集によって行と列の位置は変動しやすく、継続的なメンテナンスが簡単ではないという理由で、本書では扱わない。

表パターンの設定・起動方法

1. ノート編集中のナビゲーションメニュー上の ＋ > アグリゲーション > 結果を表にして追加 でアグリゲーション検索条件を指定する。表示される表の構造は結果タグスキーマのプロパティ構造に従う。
2. 実行コマンドの アグリゲーションの更新 を設定したボタン配置し、ボタンを押すたびに最新のアグリゲーション結果に更新する。 実行時に外部からの変数を参照するときは「検索パラメータ」を用いる。

表パターンの例

表パターンに該当するサンプルは次の箇所（節）に提示している。

4.2.2 フォームパターン

アグリゲーション処理で得られた値を、GEMBA Noteの特定のノート・ページに張り付けたフォーム部品に出力する。

フォームパターンの特徴

前節の表パターンは単に値をノートに表示するために使用するが、この出力パターンは値をノートに表示するだけでなく、さらに他のアグリゲーションにて再利用できるデータとして出力するために使用する。そのため、出力したデータを他のアグリゲーションでさらに集約したり転記したりする場合にこのパターンを選択する。

このパターンを選択する場合には、アグリゲーションの処理を行う前に出力対象のフォームと結果タグスキーマの各プロパティをリンクする必要がある。

フォームパターンの設定・起動方法

• 実行コマンドの アグリゲーション結果をタグに反映 を設定したボタン配置し、ボタンを押すたびに最新のアグリゲーション結果に更新する。
• 実行時に外部からの変数を参照するときは「検索パラメータ」を用いる。

フォームパターンの例

フォームパターンに該当するサンプルは次の箇所（節）に提示している。

4.2.3 CSVパターン

アグリゲーション処理で得られた値を、CSV形式でファイルとして出力する。

CSVパターンの特徴

このパターンは、GEMBA Noteアプリの外部にデータを連携する際に使用される。

CSVパターンの設定・起動方法

ボタン実行コマンドの以下のオプションには、アグリゲーション実行結果をCSVファイルとして出力する機能が備わっている。

• ストレージに送る
• メールで送信する
• アプリケーションに送る

CSVパターンの例

CSVパターンに該当するサンプルは次の箇所に提示している。

4.2.4 リストパターン

アグリゲーション処理で得られた値を、表やフォーム部品の選択肢として出力する。

リストパターンの特徴

このパターンは前節までに紹介した出力パターンとは異なり、結果タグスキーマの選択とSQLの書き方に留意する必要がある。

結果タグスキーマの設定

結果タグスキーマは、「ベーシックタグスキーマ」としてGEMBA Noteアプリにあらかじめ用意されているタグスキーマのどちらかを要件に応じて選択する。

表4-2-2 リストパターンで結果タグスキーマに選択するタグスキーマ

SQLの書き方

集約パターンあるいは計算パターンで処理された結果をリストとして用いる。その場合、下記4点を考慮しSQLを記述する。

1. 結果タグスキーマの構造に合わせた列を選択する
   • SELECT句でリストの選択肢の値がある列 (以後、リスト選択肢列) を選択する。またロケールも考慮でき、必要に応じて日本語、および英語での表示に対応した列 (以後、日本語表示列および英語表示列)を選択する。
   • 日本語表示列、英語表示列の選択は任意。
2. リストの選択肢とする列に別名を付ける
   • リスト選択肢列に別名として v を付ける。また、必要に応じて日本語表示列に別名として ja、英語表示列に別名として en を付ける。
   • 別名は AS句 を使う。
3. リストとの選択肢とする列の値を一意にする
   • 多くの場合、リストの選択肢は一意で表示されることが望ましい。そこで DISTINCT句 を使用して値のリストを一意にすることが多い。
   • 日本語表示列、英語表示列を設ける場合には、DISTINCTを効かせるためにリスト選択肢列と一意性の対応関係を同じにする必要がある。例えば、リスト選択肢列が同じ値の行が2つある場合、その2行でそれぞれ日本語表示列、英語表示列も同じ値であることが必要である。

   SELECT
     DISTINCT col1 AS v -- リスト選択肢列
     , col1_ja AS ja -- 日本語表記列
     , col1_en AS en -- 英語表記列
   FROM
     LIST_TBL -- リストの選択肢の値などが格納されているテーブル
   ;

4. カスケードリストを作成する場合、検索パラメータでSQLの結果を絞り込む
   • 他の入力値に依存するカスケードリストの場合、リストを表示するページ上のフォームの値を検索パラメータとして設定し、この検索パラメータを条件としてSQLの結果を絞り込む。
   • 下記のSQLの例の場合、:col2 の値はリスト選択肢列があるテーブルに存在している列であることが必要となる。

   SELECT
     DISTINCT col1 AS v
     , col1_ja AS ja
     , col1_en AS en
   FROM
     LIST_TBL
   WHERE
     col2 = :col2 -- ページ上のフォームの値である検索パラメータを条件として結果を絞り込む
   ;

リストパターンの適用

フォーム部品への設定方法

1. 1行テキスト、数値フィールド、および選択フィールドの 編集設定 > リストの設定 > アグリゲーション を選択する。
2. 対象の処理を行うアグリゲーション検索条件を選択する。
3. (カスケードリストを作成する場合) 検索パラメータを設定する。

表のセルへの設定方法

1. 任意のセルを選択し、入力規則 > 規則の設定 > 種類で共有リスト を選択する。
2. 規則の設定 > 共有リスト でアグリゲーションを選択する。
3. 対象の処理を行うアグリゲーション検索条件を選択する。

リストパターンの例

リストパターンに該当するサンプルは次の箇所（節）に提示している。

4.2.5 図面パターン

アグリゲーション処理で得られた値を、図面ユニット上にピンマークとして張り付ける。

図面パターンの特徴

• 画像ファイルやPDFファイル上に対象物をピンマークとして表現する。
• 各対象物の意味は、ピンマークの属性（形状、色、サイズなど）によって分類することができる。
  • そのためアグリゲーション処理は単純な集計ではなく、計算・変換のパターンが伴う。

図面パターンの設定・起動方法

他の出力パターンより図面ファイルの設定など、手順および起動方法が複雑なため、5.3節「図面ユニットを利用」を参照する。

図面パターンの例

図面パターンに該当するサンプルは次の箇所（節）に提示している。

4.3 アグリゲーション処理の設計

ここまで述べてきたアグリゲーションの「処理のパターン」と「出力のパターン」を踏まえ、アグリゲーション全体を設計するために必要な5つの工程についてそれぞれ説明する。

4.3.1 コネクタタイプを選択する

GEMBA Noteからの検索対象は、現在開いているノート、ローカル保存されている別のノート、サーバーに格納されているノート、外部のデータ（データベースやサーバー）になる。検索対象物を明らかにして、どのコネクタ（接続先）を用いるか選別する。

ただし、Unitコネクタについては、取得する表の範囲を絶対値で設定するのであるが、編集によって表の行と列の位置は変動しやすいため、継続的なメンテナンスが簡単ではないという理由で、本書では扱わない。またMMJCloudコネクタはMetaMoJiクラウドのサービスと連携するためのコネクタであるが、当社から顧客個別の案件で提供しているため、ここでは除外する。

シェアノートを運用するときの注意事項

シェアノートを対象にLocalTagDBコネクタを用いてアグリゲーションを実行するときには注意が必要である。シェアノートの変更は、対象のノートを開いている全てのユーザーがそのノートを閉じなければ反映できない。変更が反映されていなければ、アグリゲーション処理の結果に漏れが生じる。

4.3.2 検索するタグスキーマを決める

コネクタタイプが決まると、アグリゲーション検索対象とするタグスキーマを決定する。

検索対象タグスキーマの定義

2章でも述べたが、タグスキーマは、データベースにおけるテーブルのようにデータを格納する入れ物である。タグスキーマを構成する要素がタグプロパティである。

表4-3-1 タグスキーマ定義の記述

表4-3-2 タグプロパティ定義の記述

検索対象タグスキーマの記述例

表4-3-3 物件タグスキーマ

表4-3-4 物件タグプロパティ

4.3.3 検索諸条件を設定する

コネクタタイプと検索対象タグスキーマを設定すると、コネクタの種別によってさらに条件を設定することができる。ただし、Unit、Salesforce、およびMMJCloudコネクタタイプについては言及しない。

NoteTagDBコネクタの検索条件

現在開いているノート内を検索するコネクタを選択すると、以下の検索条件を設定することができる。

表4-3-5 NoteTagDBの検索条件

LocalTagDBコネクタの検索条件

ローカルに保存された他のノートを含めて検索するコネクタを選択すると、以下の検索条件を設定することができる。

表4-3-6 LocalTagDBの検索条件

表4-3-7 検索対象のパス

ServerTagDBコネクタの検索条件

サーバーに格納されたノートを検索するコネクタを選択すると、LocalTagDBと同じ検索条件に加えて、つぎの項目を設定することができる。

表4-3-8 ServerTagDBの検索条件（LocalTagDB検索条件への追加）

※注意：この値を1,000より大きく設定するときは、MetaMoJiのクラウドサーバーへの負荷を考慮する。特に5,000以上にするときは、MetaMoJi営業担当者に相談すること。

RESTコネクタの検索条件

RESTサーバーにアクセスして検索するコネクタを選択すると、以下の検索条件を設定することができる。

表4-3-9 RESTの検索条件

4.3.4 結果出力するタグスキーマを決める

アグリゲーション検索条件の実行結果を出力するタグスキーマを決定する。結果タグスキーマは、検索結果の中に入っているデータを解釈するために用いるタグスキーマである。検索対象となるタグスキーマの全てのプロパティではなくその一部のプロパティを表示したり、表示順序を変更したり、加工や計算した結果を求める時に利用する。

結果タグスキーマの記述例

前節の物件タグスキーマをもとに生成されるタグインスタンスに対して、いくつかの価格を計算した結果を出力するためのタグスキーマを示す。

表4-3-10 物件統計情報タグスキーマ

表4-3-11 物件統計情報タグプロパティ

4.3.5 検索パラメータを設定する

検索パラメータは、初期値やフォーム部品など外部から値を与えてSQL式の中で、処理を切り替えたり、検索結果を絞り込むために用いる。

検索パラメータの適用箇所

設定した検索パラメータを利用できる箇所は主に次の場所である。

• アグリゲーション検索条件
  • コネクタ（前節で述べた諸条件）
• ボタン実行コマンド
  • アグリゲーションの更新
  • アグリゲーション結果をタグに反映

検索パラメータとフォーム部品の連動

アグリゲーションに設定した検索パラメータをフォーム部品を関連付けるには、次の手順で行う。

1. 検索パラメータに関わるタグスキーマとタグプロパティを作成する。

2. 作成したタグスキーマをページ上のどこかに（例えば、見出しの文字列）設定する。

3. フォーム部品を張り付ける。

4. 張り付けたフォーム部品から関連付けるタグプロパティにリンクする。

   

5. ボタン部品を長押しor右クリックして編集状態にして、設定の変更 を選択する。

   • 実行するコマンドとして アグリゲーションの更新 を選択したとする。

6. 検索パラメータを更新する をオンにすると、検索条件一覧が現れる。

7. 対象とする検索条件を選択する。

8. 検索パラメータにリンクするタグ を1で作成したタグスキーマの該当するタグプロパティに設定する。

   

検索パラメータの定義例

表4-3-12 物件検索向けパラメータ「TYPE」の定義

このパラメータの場合、$TYPE あるいは :TYPE と使ってSQL式を構成する。

SELECT * 
FROM P_TABLE 
WHERE Type = :TYPE AND Name != ''
ORDER BY Price DESC

4.3.6 SQLを定義する

SQL（Structured Query Language）は、リレーショナルデータベースを操作するための言語で、データベースに命令を送ってデータの検索や追加、更新、削除などを実行する。 GEMBA Noteでは、各種コネクタからのデータ抽出方法を表現するために用い、SELECT文のみを提供する。

4.3.7 SELECT文の意味

一般的なSQLにおけるSELECTは散らばっているデータ群に対して、大きく3つの操作を実行する命令文である。

• 選ぶ
  • 検索するテーブルを選択、WHERE句による絞り込み
  • 例：港区の物件を選ぶ。
• 分ける
  • グループ化する
  • 例：物件タイプごとに分類する。
• 数える
  • グループ化した集合から集計する。
  • 例：港区の物件数を数える。
  • 例：一番高い物件価格を求める。

GEMBA Noteの場合は、これらに加えて次の操作ができることが特殊である。これは検索対象となるタグスキーマと結果タグスキーマが分離していること、ボタン実行コマンド「アグリゲーション結果をタグに反映」が存在することに起因する。

• 書き換える
  • 結果タグスキーマのタグプロパティに値を代入する。
  • 例：タグプロパティnumPropertiesに港区の物件数を代入する。
  • 例：タグプロパティcountに1を足した値をcountに代入する。

よく用いる基本的なSELECT文の構文をGEMBA Noteの言葉を補足して表現すると次のようになる。

SELECT カラム列（結果タグスキーマを構成するタグプロパティ名）
FROM コネクタの抽出テーブル名
WHERE カラム1 比較演算子 条件値 AND/OR カラム2 比較演算子 条件値 ...
GROUP BY グループ化を行うカラム名
ORDER BY 並び順の基準となるカラム名 ASC/DESC;

4.3.8 システムカラムと組み込みパラメータの存在

GEMBA NoteのSQL実行における特殊性は、アグリゲーションのSQLに用いることができるカラム名はタグスキーマだけではなく、システムが提供するカラムやパラメータの存在にある。

システムカラム（インデックス情報カラム）は、タグスキーマを設定した対象物、あるいはその対象物を含んだノートやページの識別情報を値として取得する。SELECT文のカラムとして記述しておくと、NoteTagDB、LocalTagDB、およびServerTagDBコネクタの場合は、結果としてサムネイル表示や該当ページへのジャンプなどができる。 また、通常ノートとシェアノートにおけるページを特定するための一意性の検査に用いることができる。一意性は、RESTコネクタのように外部システムからデータを受け取るときに重要となる。

表4-3-13 システムカラム一覧

システムが提供するパラメータは、現在開いているページや日付を利用した条件絞り込みに用いる。

表4-3-14 主な組み込みパラメータ

4.3.9 各処理パターンの特徴

アグリゲーションを実行処理するときによく見られるパターンを大きく3つに分類することは前に述べた。ここでは各パターンでのSQL記述の特徴についてふれる。

集約パターンSQL式の特徴

集約パターンには、シンプルなSELECT文でのSQL記述が多い。入力フィールドからの値を検索パラメータとして受け取り、それをWHERE句の中に定義して絞り込むケースがよく見られる。

SELECT カラム列（結果タグスキーマを構成するタグプロパティ名）
FROM コネクタの抽出テーブル名
WHERE カラム1 比較演算子 検索パラメータ1 AND カラム2 比較演算子 検索パラメータ2, ...

転記パターンSQL式の特徴

転記パターンは、コピーする場所を指定するため、同じページである・ではないことを条件とする場合が多い。

SELECT カラム列（結果タグスキーマを構成するタグプロパティ名）
FROM コネクタの抽出テーブル名
WHERE _pageId 比較演算子 _PAGE_ID（同じページであるか、ないかを検査する場合）

また他のノートから転記する場合は（LocalTagDBやServerTagDBコネクタ）、IDや日付で絞り込むこともある。

SELECT カラム列（結果タグスキーマを構成するタグプロパティ名）
FROM コネクタの抽出テーブル名
WHERE 日付カラム 比較演算子 _PAGE_DATE AND/OR ...
LIMIT 1 -- 複数存在したときに最初に現れたものにする

計算パターンSQL式の特徴

計算パターンは、検索対象タグスキーマのカラムの値を四則演算したり、集合関数（MIN, MAX, SUM, COUNTなど）を適用して結果を集計する。計算結果は、AS句 を使って別のカラムに出力する。

SELECT 検索カラム1 四則演算 検索カラム2 AS 出力カラム1、集合関数(検索カラム2) AS 出力カラム2（結果タグスキーマを構成するタグプロパティ名）
FROM コネクタの抽出テーブル名
WHERE ...

4.4 生成AIの利用

生成AIとは、深層学習や機械学習の手法を駆使して、人が作り出すようなテキスト、画像、音楽、ビデオなどのデジタルコンテンツを自動で生成する技術である。ここでは生成AIの一つである ChatGPT を用いてアグリゲーション実行処理の根幹となるSQL式を設計情報から生成する手順について解説する。

4.4.1 ChatGPTへのプロンプトの書き方

プロンプト（prompt）は、ChatGPTに対する命令や質問のことを指す。たとえば、「不動産物件のデータを10件作成してください」と命令すれば、物件名、住所、間取り、面積、築年数、賃料など、架空の不動産データを10件提示してくれる。情報が不足している場合は、「物件タイプも追加して」と命令を追加すると、それに見合ったデータを生成する。

4.4.2 ChatGPTへタグスキーマ情報を与える

ChatGPTにアグリゲーション検索条件であるSQLを生成するためには、まず対象となるタグスキーマとタグプロパティを与える必要がある。 このようなまとまりがある記述は、ハッシュタグ（#）の後ろに適当な見出しを記入し、その下にこのドキュメントで提案したタグスキーマとタグプロパティのMarkdown形式テキストを書く。

ハッシュタグは、プロンプト内でのタグ付けや分類、数値や数量を示すために使用される。

タグスキーマとタグプロパティのプロンプト記述例

#物件タグスキーマ
| タグID | 日本語表示名 | 設定箇所 |
| --- | --- | --- |
| Property | 物件 | ページ |

#物件タグプロパティ
| プロパティID | 日本語表示名 | データの型 |
| --- | --- | --- |
| Name | 名称 | 文字列 |
| Type | 物件タイプ | 文字列 |
| Price | 価格 | 整数 |
| Address | 住所 | 文字列 |

4.4.3 ChatGPTへ要件を伝える

中括弧（{}）の中に前述したハッシュタグを受けこみ、どのタグスキーマを対象に、どのSQLシステムの形式で、どのような条件でSQL式を作成してほしいか伝える。

中括弧は、選択肢を示したり、プロパティや属性を定義するために使用される。

SQL作成要求のプロンプト記述例（全体）

{#物件タグスキーマ}の{#物件タグプロパティ}から、最小価格、最大価格、平均価格を算出するSQLiteのSQLを生成してください。

#物件タグスキーマ
| タグID | 日本語表示名 | 設定箇所 |
| --- | --- | --- |
| Property | 物件 | ページ |

#物件タグプロパティ
| プロパティID | 日本語表示名 | データの型 |
| --- | --- | --- |
| Name | 名称 | 文字列 |
| Type | 物件タイプ | 文字列 |
| Price | 価格 | 整数 |
| Address | 住所 | 文字列 |

生成されたSQL

SELECT 
    MIN(Price) AS MinPrice, 
    MAX(Price) AS MaxPrice, 
    AVG(Price) AS AvgPrice
FROM Property;

4.4.4 追加質問によるチューニング

何か不足している、過剰に反応している場合は、その旨を何度も伝えて最終形態にもっていく。

追加質問その1

検索パラメータ{propertyTYPE}は、物件タイプを意味します。この変数をつかって絞り込みを付け加えてください。

※{propertyTYPE}とせずともpropertyTYPEでも問題ないかもしれない。

生成されたSQL

SELECT 
    MIN(Price) AS MinPrice, 
    MAX(Price) AS MaxPrice, 
    AVG(Price) AS AvgPrice
FROM Property
WHERE Type = :propertyTYPE;

追加質問その2

MinPriceはmin、MaxPriceはmax、AvgPriceはaverageに置き換えてください。

生成されたSQL

SELECT 
    MIN(Price) AS min, 
    MAX(Price) AS max, 
    AVG(Price) AS average
FROM Property
WHERE Type = :propertyTYPE;

サンプル4-1 生成AIからSQL生成（単体テーブル）

前節で生成した物件の最小価格、最大価格、平均価格を計算するサンプルを確認するため、次のノートを開く。

「物件タイプごとに統計情報を算出する」と書かれたページへ移動し、「物件タイプ」をメニューから選択しなおして、算出 ボタンをクリックして出力結果をみる。

サンプル4-2 生成AIからSQL生成（複数テーブル）

ChatGPTに次のプロンプトを与えて生成したアグリゲーションの実行を確認する。このサンプルでは2つの異なるタグスキーマからSQL式を作成する。 なお、ChatGPTは日々学習を重ねているので、これと全く同じSQL式を生成するとは限らないことに留意する。

質問の意図：各不動産物件への訪問者数を数える。

{#物件タグスキーマ}は{#物件タグプロパティ}から構成されます。
{#訪問者カードのタグスキーマ}は{#訪問者カードのタグプロパティ}から構成されます。
物件の名称ごとに、物件ページと同じページにある訪問者カードの数を集計するSQLiteのSQLを作成してください。

#物件タグスキーマ
| タグID | 日本語表示名 | 設定箇所 |
| --- | --- | --- |
| Property | 物件 | ページ |

#物件タグプロパティ
| プロパティID | 日本語表示名 | データの型 |
| --- | --- | --- |
| Name | 名称 | 文字列 |
| Type | 物件タイプ | 文字列 |
| Price | 価格 | 整数 |
| Address | 住所 | 文字列 |

#訪問者カードのタグスキーマ
| タグID | 日本語表示名 | 設定箇所 |
| --- | --- | --- |
| Visitor | 訪問者 | 図形（長方形、線は灰色） |

#訪問者カードのタグプロパティ
| プロパティID | 日本語表示名 | データの型 |
| --- | --- | --- |
| visitedDate | 訪問日| 日付型 |
| customerName  | 顧客名 | 文字列型 |
| phone  | 電話番号 | 文字列型 |

生成されたSQL：

WITH PropertyPages AS (
    SELECT 
        p.Name AS PropertyName, 
        p.PageID
    FROM Property p
),
VisitorCounts AS (
    SELECT 
        v.PageID, 
        COUNT(v.VisitorID) AS VisitorCount
    FROM Visitor v
    GROUP BY v.PageID
)
SELECT 
    pp.PropertyName, 
    COALESCE(vc.VisitorCount, 0) AS VisitorCount
FROM PropertyPages pp
LEFT JOIN VisitorCounts vc ON pp.PageID = vc.PageID;

着目点：

• JOIN を使って複数のテーブルを結合している。
• 「同じページ」を表現するため、PageID というカラムを生成している。
• そのカラムでグループ化を行っている。
• 訪問者数をカウントするため、訪問者IDを意味する VisitorID を生成している。
• NULL値を考慮して、COALESCE関数を用いている。

追加質問：

追加の条件でSQLを更新してください。
・「同じページ」は_pageIdカラムを利用する。
・訪問者数はcustomerNameカラムでカウントする。
・集約結果は、{#訪問者数カウントのタグスキーマ}の{#訪問者数カウントのタグプロパティ}のプロパティIDに出力する。

#訪問者数カウントのタグスキーマ
| タグID | 日本語表示名 | 設定箇所 |
| --- | --- | --- |
| visitorCount | 訪問者数カウント | - |

#訪問者数カウントのタグプロパティ
| プロパティID | 日本語表示名 | データの型 |
| --- | --- | --- |
| propertyName | 物件名称| 文字型 |
| numVisitors  | 訪問者数 | 整数型 |

更新されたSQL：

WITH VisitorCounts AS (
    SELECT 
        v._pageId, 
        COUNT(v.customerName) AS numVisitors
    FROM Visitor v
    WHERE v.customerName IS NOT NULL
    GROUP BY v._pageId
)
SELECT 
    p.Name AS propertyName, 
    COALESCE(vc.numVisitors, 0) AS numVisitors
FROM Property p
LEFT JOIN VisitorCounts vc ON p._pageId = vc._pageId;

実際にアグリゲーションの動作を確認するため、次のノートを開く。

「各物件の訪問者数をカウントする」と書かれたページへ移動し、最新に更新 ボタンをクリックしてみる。

• 「物件訪問者データ」ノートを開き、物件価格を変更したり、新たな訪問者カードを追加してみる。
• 再び「生成AIの利用」ノートに戻り、「各物件の訪問者数をカウントする」と書かれたページへ移動し、最新に更新 ボタンをクリックして変更が反映されているか確認する。

5 バイナリデータの利用

この章では、GEMBA Noteが画像データやPDFファイルのようなバイナリデータをどのように処理することができるかサンプルを提示しながら解説する。音声と動画はフォーム部品としてまだ提供されていないので、ここではふれない。

5.1 参照型プロパティ

GEMBA Noteが取り扱うことができるバイナリデータは、動画データ、画像データ、音声データ、そしてPDFファイルである。この中のうちGEMBA Noteアプリとしてデータの入出力をタグスキーマを介して連携できるものは、画像とPDFである。これら2つのデータタイプは、「参照型」のタグプロパティからイメージフィールドとPDFフィールドにリンクして利用する。

5.2 画像とPDFの転記

あるフォームに配置したイメージフィールドに張り付けた画像、およびPDFフィールドに読み込まれたPDF文書を別のフォームから取得するサンプルを実装する。このサンプルを実現するフォーム、タグスキーマ、アグリゲーションを第2章「アプリケーションの設計」で述べた手法で設計する。

5.2.1 物件画像フォームの定義

不動産物件情報として画像とPDF形式の詳細情報を1つ登録するための帳票を定義する。

フォームの体裁

表5-1 物件画像フォームの体裁

フォーム部品の仕様

表5-2 物件画像フォーム上のフォーム部品

フォーム部品の配置

物件画像フォーム上の見出しと部品の配置は次の図のようにする。

5.2.2 物件写真タグスキーマの仕様

タグスキーマの定義

表5-3 物件写真タグスキーマとタグプロパティ

フォーム部品とタグプロパティのリンク

表5-4 物件写真タグプロパティとのリンク

5.2.3 物件画像転記アグリゲーションの仕様

表5-5 物件画像コピーの定義

検索パラメータ「name」の仕様

表5-6 物件名称パラメータの定義

コネクタの仕様

表5-7 物件写真タグスキーマを取得するコネクタの定義

画像・PDFのインポート設定

表5-8 物件写真タグスキーマのインポート設定

実行結果

「取得」ボタンを押すとアグリゲーションが実行し、物件名称に部分一致したpropertyPhotoタグインスタンスの写真と画像をそれぞれのフォーム部品に挿入する。

5.3 図面ユニットを利用

図面ユニットとは、対象物を水平面上から見た投影図のことである。GEMBA Noteでは、図面ユニットを使用して、画像ファイルやPDFファイル上にプロットされた対象物を表現する。各対象物の意味は、ピンマークの属性（形状、色、サイズなど）によって分類することができる。例えば、地図画像上に不動産物件をプロットする場合、タイプや価格帯などによってピンマークの形状を変化させることによって、一目で区別することが可能である。

ここでは不動産物件の位置を図面ユニット上に配置する手順について例を用いて解説する。利用する図面は再利用できるように開発パッケージに登録する。

5.3.1 図面ユニット関連アプリに必要なコンポーネント

建設現場での機材や設備の場所、不動産物件の位置など2次元上の情報を画像やPDFへプロットするようなアプリケーションを開発するには、次のコンポーネントが必要となる。

表5-9 図面に関わるアプリに必要なコンポーネント

5.3.2 パッケージに図面を追加する

開発パッケージを長押しor右クリックし、コンテキストメニューの 操作 > 図面一覧 を選択する。

1. 「図面一覧」ダイアログ上の ＋ アイコンを選択する。
2. 「新規画面」ダイアログ上のインポート ボタンをクリックして、対象となる画像ファイルあるいはPDFファイルを読み込む。
   • サンプル画像ファイル： map_open.png
3. この図面に適当なタイトルを設定する（初期値はファイル名）。

5.3.3 縮尺を設定する

取り込んだ画像へ縮尺情報を設定する手順を示す。

1. 「新規図面」ダイアログ上で、縮尺 を選択する。
2. 基準点を表現するアイコン（初期設定では左上に存在する）を動かし位置を決め、その地点の緯度と経度を指定する。
3. 画面上で長さが判明している箇所へスケールバー（初期設定では図面下に位置する）を設置する。
   1. 縮尺スケールが地図上にあれば、そこへスケールバーを配置する。
   2. 建物、橋、川の幅などへスケールバーを配置して、長さを設定する。
4. スケールバーの距離と単位を設定する。
5. 完了 ボタンをクリックして、縮尺設定からぬける。

5.3.4 変換表を作成する

上記図の「変換表」をクリックすると、ピンマークの属性値とタグプロパティの値との関係を定義するダイアログが現れる。下の表はピンマークの属性とその値が取りうる値を示す。

表5-10 変換表

例えば、形状 を選択して、不動産物件に関わるピンマークの形と物件タイプの関連について連想配列を用いて定義する。

表5-11 変換表の例

ピンの形が円形であれば「アパート」、星であれば「一戸建て」という意味をもつことになる。

5.3.5 アグリゲーション結果を設定する

ピンマークの属性とアグリゲーション結果、つまり結果タグスキーマとの関係を定義する。

下の設定は、結果タグスキーマのタグプロパティxとyはピンマークの緯度と経度、Typeは形状、Nameはラベルに反映されることを意味する。

ここまで作業を終えると、完了 や 閉じる ボタンをクリックして、新規図面を保存し、図面一覧から抜ける。

5.3.6 フォームとタグスキーマを定義する

図面ユニット上に対象物を配置するには、入力UIとなるフォームとそのタグスキーマを定義する必要がある。次の例は、不動産物件フォームを拡張して、写真、PDF、位置情報を追加したフォームとそのタグスキーマの例である。

フォームから入力したデータから図面上にピンマークをプロットするには、最低XY座標（緯度と経度）がタグスキーマに存在する必要がある。前で定義した「変換表」とここで定義するタグスキーマの関係を示す。

5.3.7 検索条件を定義する

あるタグスキーマから生成されるタグインスタンスを収集し、図面ユニット上に位置などを配置するにはアグリゲーション検索条件を定義する。ここは上記物件詳細向けタグスキーマを用いたアグリゲーションの定義例である。同じノート内に検索対象となる物件詳細フォームが含まれていると仮定する。

表5-12 アグリゲーションの定義例

表5-13 コネクタの定義例

ここまでで図面ユニットの設定は終了である。図面上で検索条件を実行する手順は、動作確認も兼て次節で述べる。

サンプル5-1 画像とPDFを転記する

次のノートを開く。

• 確認手順
  • 物件名称の1行テキストフィールドに不動産物件名の一部を入力する
    • 例えば、「オラ」と記入する
  • 取得 ボタンをクリックする
  • 「オラシオン四ツ木」という物件の画像とPDFが現れる
    • 同じフォルダに存在する「物件画像」ノートから転写される

サンプル5-2 図面上に検索結果をプロットする

次のノートを開く。

1. 新規ページ（種類は何でもよい）を作成する。
2. ノート編集状態で、＋ > 図面を追加 > 図面ユニットを追加 を選択する。
3. 「図面ユニットを追加」ダイアログで利用するタグスキーマを選択する。
4. 図面ユニットがページ上に追加されたら、タップして パッケージから選択 を選ぶ。
5. パッケージに登録した図面を選択する。
   • ユニット内に指定した図面画像が表示される。
   • ページのサイズに合わせて、図面ユニットの大きさを変更する。
6. ユニットを長押しor右クリックしてコンテキストメニューから アグリゲーション > 設定を変更 をクリックする。
7. 検索条件としてアグリゲーション（getPropertyLocations「物件位置を取得」）を選択する。
8. 図面上にピンマークが表示される。

6 データの連携

この章では、GEMBA Noteが外部システムとどのように情報をやりとりするのかサンプルを動作させながら学習する。

6.1 CSVデータを出力する

GEMBA Noteのノートやページからフォーム部品や表の内容をCSVファイルとして出力することができる。

6.1.1 CSV出力の準備

1. CSVデータの構造を表現するタグスキーマを定義する。
2. そのタグスキーマをタグ検索条件として開発パッケージに登録する。その手順は次の通り。
   • 対象の開発パッケージを長押し/右クリックでコンテキストメニューを表示する。
   • 操作 の中から タグ検索条件一覧 を選択する。
   • 「タグ検索条件」ダイアログ上の インポート ボタンをクリックする。
   • 「タグ検索条件のインポート」ダイアログの 検索条件の追加 をクリックする。
   • 「検索条件の登録」ダイアログ上の 検索条件名 を記入し、検索対象とするタグスキーマを選択する。
   • 完了 ボタンを押して条件を保存する。

6.1.2 CSV出力対象と操作

ノートを開かない状態

表6-1 ノートを開かないでCSVファイル保存

「CSV出力設定」ダイアログが現れ、出力対象の「タグ検索条件」を選択、出力オプションを設定し、完了 ボタンを押してファイルを保存する。

ノートを開いた状態

表6-2 ノートを開いてCSVファイル保存

#	対象	操作
3	ページ	ナビゲーションメニュー上の をクリックし、送る を選択する。その後の流れは下図の通り。あるいはボタン部品からファイルを保存する。
4	表	表の上を長押し/右クリックしてコンテキストメニューから 送る を選択、アプリケーションにCSVを送る あるいは CSVをファイルに保存する を選択する。

6.1.3 ボタンからCSVファイルを出力

ページ上にボタン部品を配置して、以下のような設定にすればナビゲーションメニューからの操作を短縮することができる。

表6-3 CSVファイル保存するボタンの定義例

6.1.4 CSV出力結果

出力対象物（#1～6）とその出力結果は次の通り。

表6-4 CSV出力の形式

画像はBase64形式（DataURL宣言付き）の文字列として出力される。

画像出力例：

data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2w...

6.2 CSVファイルからデータを取り込む

GEMBA Noteに表計算ソフトや外部システムからのCSVファイルをインポートして、フォームを生成する手順について説明する。

6.2.1 CSVファイルの形式

取り込むCSVファイルの形式は次の表の通りである。

表6-5 CSVファイル形式

6.2.2 CSVファイルを取り込むの準備

1. CSVデータの構造を表現するタグスキーマを定義する。
2. CSVを取り込むフォームを作成する。
3. 作成したタグスキーマとフォーム部品をリンクする。
4. フォームを用紙テンプレートとして登録する。

6.2.3 CSVファイルを取り込む操作

1. ノート編集状態で、＋ メニューの中から ページを追加 > CSVから追加 を選択する。
2. インポートするCSVファイルが聞かれるので、対象のCSVファイルを選択する。
3. 「ページ追加の設定」ダイアログ上で、用紙テンプレート に対象となる用紙テンプレートを設定する。
4. 完了 ボタンをクリックすると、CSVファイルの読み込みが開始される。レコード件数の数だけページが作成される。

6.3 カスタムURLスキームによる連携

カスタムURLスキームは、myapp://… のように独自のURLスキームを利用してアプリを直接起動させるURLである。

GEMBA Noteも製品ごとに独自のスキームを介して外部システムから製品を起動し、指定したテンプレートからノートを作成、あるいは指定した帳票を開いてデータを受送信する仕組みである。

6.3.1 カスタムURLからの起動

カスタムURL起動は、外部システムから下記形式のURLを発行することにより実行する。

[スキーム名]:///[エンドポイント]?[パラメータ...]

表6-6 MetaMoJi製品とバージョン別スキーム名

表6-7 エンドポイントとアクション

カスタムURL起動の例

eyachoch6:///nsk/new?...　// eYACHO for Business 6 を起動してノートを作成
gembanotech6s:///nsk/open?... // GEMBA Note Viewer 6を起動してノートを開く

eyachoch7s:///nsk/new?...　// eYACHO Viewer 7 を起動してノートを作成
gembanotech7:///nsk/open?... // GEMBA Note for Business 7を起動してノートを開く

6.3.2 カスタムURLのパラメータ

カスタムURLに指定するパラメータはエンドポイントごとに異なる。

表6-8 カスタムURLのパラメータ

6.3.3 ノートテンプレートIDを取得する

新規に作成するノートのひな型になるテンプレートは、template_id パラメータに指定する。 そのIDは次の手順で取得する。

• 新規ノート作成ボタンをクリックする。
• ノートテンプレートタブに切り替える。
• 対象テンプレート上で右クリックあるいは長押しする。
• テンプレート情報を選択する。
• URLが見つかるのでコピーして記録しておく。

6.3.4 ページテンプレートIDを取得する

作成するノートに追加するページのひな型となるテンプレートは、page_template_id パラメータに指定する。そのIDは次の手順で取得する。

• 新規ノート作成ボタンをクリックする。
• 用紙テンプレートタブに切り替える。
• 対象テンプレート上で右クリックあるいは長押しする
• テンプレート情報を選択する。
• URLが見つかるのでコピーして記録しておく。

6.3.5 ノートを保存するフォルダを取得する

作成したノートを保存するフォルダを folder_uri パラメータに指定する。 このURIを取得するため、対象フォルダを右クリックあるいは長押しし、コンテキストメニューの中から URL を選択する。

6.3.6 タグスキーマの名前空間を取得する

ページ生成時に対象となるタグスキーマの名前空間は、tag_namespace パラメータに指定する。 それを取得手順は次の通りである。

• 対象の開発パッケージ上で右クリックあるいは長押しする。
• コンテキストメニューの中から操作 > タグスキーマ一覧を選択する。
• 「タグスキーマ一覧」ダイアログ上で対象のタグスキーマを選択する。
• 「タグスキーマの編集」ダイアログ上でタグIDを右クリックあるいは長押しする。
• クリップボードにコピーを選択し、コピーした内容を記録しておく。

重要事項

• URLの長さの上限は2046文字である。
• セットするパラメータが多い場合は、supply_info_uri を利用する。

6.4 RESTサーバーとの連携

REST APIは、Webアプリケーションやサービスが、インターネットを介して情報を共有したり操作したりするための手続きである。

REST APIが提供する機能を利用するには、フォーム部品であるボタンからボタンコマンド「サーバーに送信」、あるいはアグリゲーション検索条件でRESTコネクタからアクセスする2つの方法がある。

6.4.1 サーバーに送信するボタンの定義

RESTサーバーにデータを送信する場合、ボタンコマンド「サーバーに送信」を用いて、アクセスするサーバーのエンドポイント（URL）、出力対象（PDF、タグ、タグ検索結果、アグリゲーション結果）を指定する。

出力対象を「タグ」に指定した場合、出力内容に画像やPDFの参照型のタグプロパティがある場合は、「参照先をデータとして出力する」を有効化する。

6.4.2 アグリゲーション検索条件の定義

RESTサーバーにアクセスして、外部システムからデータを取得する場合は、アグリゲーション検索条件を定義する。コネクタのタイプは「REST」を用いる。

コネクタ定義例 (サンプル6-4に用いられている例)

METHODへはRESTサーバーが提供するAPIに合わせてGET または POST を指定する。パラメータも設定可能であり、形式はtext/plainやapplication/jsonをリクエストBODYに指定することができる。

6.4.3 リクエストの処理

ボタンコマンド「サーバーに送信」やRESTコネクタから送信されるパラメータはRESTサーバーのGETメソッド、POSTメソッドにて受け取る。

次はPython FastAPI（https://fastapi.tiangolo.com/）、Node.jsのExpress（https://expressjs.com/）というフレームワークを用いてRESTサーバーを実装するときに定義するGETとPOST関数を抽象的に定義した例である。

Python GETメソッド

@app.get(<エンドポイント>)
def <関数名(request: Request): 
  # 変数requestの中にGEMBA Noteから送信されたキーとその値が含まれる
  <パラメータ値> = request.query_params.get(<パラメータ>)

Node.js GETメソッド

import express from 'express';
const router = express.Router();

router.get(<エンドポイント>, function(req, res) {
  // 変数reqの中にGEMBA Noteから送信されたキーとその値が含まれる
  let <パラメータ値> = req.query.<パラメータ>;

Python POSTメソッド

@app.post(<エンドポイント>)
def <関数名>(jsonData: dict):
  # 変数jsonDataの中にGEMBA Noteから送信されたキーとその値が含まれる
  <パラメータ値> = jsonData[<パラメータ>]

Node.js POSTメソッド

import express from 'express';
const router = express.Router();

router.post(<エンドポイント>, function(req, res) {
  // 変数reqの中にGEMBA Noteから送信されたキーとその値が含まれる
  let <パラメータ値> = req.body.<パラメータ>;

6.4.4 レスポンスの構造

RESTサーバーが提供するREST APIエンドポイントは、ボタンコマンド「サーバーに送信」やRESTコネクタが受け取ることのできる定型的なJSON構造を返却しなければならない。

「サーバーに送信」への出力構造

「サーバーに送信」の処理結果は、GEMBA Noteが処理結果のメッセージをダイアログ上で提示するため、次のシンプルなJSONデータを返却する。

{
   'message': <メッセージ>
}

RESTコネクタへの出力構造

{
   'keys': ['key1', 'key2', ... 'keyN'], # recordsの中で用いるキーの一覧
   'records': [
       {'key1': value-11, 'key2': value-21, ... 'keyN': value-N1}, 
       {'key1': value-12, 'key2': value-22, ... 'keyN': value-N2}, 
       ...,
       {'key1': value-1m, 'key2': value-2m, ... 'keyN': value-Nm}, 
   ],
   'message': エラーメッセージ or null(success)
}

6.4.5 Windowsで開発する際の注意点

eYACHO および GEMBA NoteのWindows Storeアプリは、初期設定ではlocalhostに接続できない。localhostへの接続を許可するには、対象製品ごとにループバックを有効化する。

有効化は、管理者モード で起動したコマンドプロンプトを用いて実行する。

eYACHO for Business の場合

Version 6

> CheckNetIsolation.exe LoopbackExempt -a -n=MetaMoJiCorporation.eYACHOforBusiness6_dprdgbsyk6pqc

Version 7

> CheckNetIsolation.exe LoopbackExempt -a -n=MetaMoJiCorporation.eYACHOforBusiness7_dprdgbsyk6pqc

eYACHO Viewer の場合

Version 6

> CheckNetIsolation.exe LoopbackExempt -a -n=MetaMoJiCorporation.eYACHOViewer6_dprdgbsyk6pqc

Version 7

> CheckNetIsolation.exe LoopbackExempt -a -n=MetaMoJiCorporation.eYACHOViewer7_dprdgbsyk6pqc

GEMBA Note for Business の場合

Version 6

> CheckNetIsolation.exe LoopbackExempt -a -n=MetaMoJiCorporation.GEMBANoteforBusiness6_dprdgbsyk6pqc

Version 7

> CheckNetIsolation.exe LoopbackExempt -a -n=MetaMoJiCorporation.GEMBANoteforBusiness7_dprdgbsyk6pqc

GEMBA Note Viewer の場合

Version 6

> CheckNetIsolation.exe LoopbackExempt -a -n=MetaMoJiCorporation.GEMBANoteViewer6_dprdgbsyk6pqc

Version 7

> CheckNetIsolation.exe LoopbackExempt -a -n=MetaMoJiCorporation.GEMBANoteViewer7_dprdgbsyk6pqc

※Windowsの設定で開発者用モードをONにしている場合など、環境によってはコマンドの実行が必要ない場合がある。

サンプル6-1 CSVファイルを保存する

次のノートを開く。

• 確認手順

  • フォーム部品・表からCSV保存 ボタンをクリックする

  • 保存先をファイラーで聞かれるので、適当な場所を指定してCSVファイルを保存する。

  • アグリゲーション結果をCSV保存 ボタンをクリックする。

  • 保存先をファイラーで聞かれるので、適当な場所を指定してCSVファイルを保存する。

  • 保存したCSVファイルをテキストエディタあるいは表計算ソフトで開き、内容を確認する。

    

サンプル6-2 CSVファイルを取り込む

次のノートを開く。

• CSVファイル：propertyDetailList.csv
  • 画像とPDFデータを含んだ物件詳細データ
• 確認手順
  1. ノート編集状態で、＋ メニューの中から ページを追加 > CSVから追加 を選択する。
  2. インポートするCSVファイルが聞かれるので、対象のCSVファイルを選択する。
  3. 「ページ追加の設定」ダイアログ上で、用紙テンプレート に対象となる用紙テンプレートを設定する。
  4. 完了 ボタンをクリックすると、CSVファイルの読み込みが開始される。
  5. レコード件数の数だけページが作成され、それぞれに物件名、タイプ、価格、住所、物件画像、PDF、XY座標が与えられていることを確認する。

サンプル6-3 カスタムURL連携でノートを生成する

不動産管理アプリで教材として用いた物件フォームをカスタムURLスキーマから作成するWebサーバーのサンプルプログラム（python）はGitHub上に公開している。

GitHub URL: https://github.com/mmj-ajiki/cuscheme-property-manager

サーバーを起動して、該当するURLにWebブラウザからアクセスするとトップページが現れる。

それぞれのリンクをクリックすると、eYACHOあるいはGEMBA Noteを起動するように促され（起動する製品はスキーム名に依存する）、ノートとフォーム（ページ）が生成される。

サンプル6-4 RESTサーバーへアクセスする

動作を確認するRESTサーバーは、GEMBA Noteから送信されてきたJSONデータ、画像データ、PDFデータをファイルとして保存するAPIを提供する。READMEファイルを確認してサーバーを起動する。

GitHub URL: https://github.com/mmj-ajiki/rest-file-transfer-py

送信テストを行った後で、受信テストを行う。

注意事項

• サーバーのポート番号を変更した場合やリモートサーバーで運用可能にした時は、関連するボタンコマンドやアグリゲーション検索条件（RESTコネクタ）の URL を変更する。
• このサンプルのサーバーはマルチユーザーでの利用を想定していない。

送信テスト

次のノートを開く。

JSONファイルをアップロードする

• 物件情報フォームに物件名称が設定されていることを確認する。
  • タイプ、価格、住所なども適当に入力する。なくてもよい。
• ページ上の アップロード ボタンをクリックする。
  • 「アップロードが完了しました」とダイアログが現れると成功。
  • 物件名称が設定されていないと、「物件名称が設定されていません」と表示される。
  • ファイル保存が失敗すると「JSONファイルが保存されませんでした」と表示される。
• 環境変数LOCAL_FOLDERに設定してあるフォルダにJSONファイルが格納されていることを確認する。
  • ファイルをテキストエディタで開き、内容を確認する。

画像・PDFファイルをアップロードする

• 物件名称、物件画像、PDFファイルが設定されていることを確認する。
• ページ上の アップロード ボタンをクリックする。
  • 「アップロードが完了しました」とダイアログが現れると成功。
  • 物件名称、物件画像、PDFファイルが設定されていないと、「…が設定されていません」と表示される。
  • ファイル保存が失敗すると「…ファイルが保存されませんでした」と表示される。
• 環境変数LOCAL_FOLDERに設定してあるフォルダに画像とPDFファイルが格納されていることを確認する。
  • ファイルをクリックして画像やPDFの内容が表示されるか確かめる。

受信テスト

次のノートを開く。

保存されたJSONファイルの内容を取得する（その1）

• 環境変数LOCAL_FOLDERに設定してあるフォルダにJSONファイルが保存されていることを確認する。
• ページ上の 最新に更新 ボタンをクリックする。
  • 「最新に更新を実行します…」というダイアログが現れるので、はい を選択する。
  • 各JSONファイルのName、Type、Price、Addressの値が表形式として出力される。

保存されたJSONファイルの内容を取得する（その2）

1. ノート編集状態で、＋ メニューの中から ページを追加 > アグリゲーションの結果から追加 を選択する。
2. 検索条件が聞かれるので、物件詳細取得 [REST連携] を選択し、完了 ボタンをクリックする。
3. 「ページ追加の設定」ダイアログ上で、用紙テンプレート に対象となる用紙テンプレートを設定する。
4. 完了 ボタンをクリックすると、CSVファイルの読み込みが開始される。
5. レコード件数の数だけページが作成され、それぞれに物件名、タイプ、価格、住所、物件画像、PDF、XY座標が与えられていることを確認する。

7 アプリケーションの試験

ソフトウェアのテストとは、開発したソフトウェアが想定どおりに動作するかを評価・検証することである。開発したソフトウェアが、仕様書で求められている仕様どおりに機能するかどうかをチェックする。

この章では、GEMBA Note上で開発したアプリケーションに対する試験の1つの手法について述べる。

7.1 試験の流れ

ソフトウェアの試験は、一般的に、単体テスト、結合テスト、システムテスト、そして受け入れテストのフェーズで実施する。開発したGEMBA Noteアプリもこの流れで試験を実施するが、受け入れテストは本番稼働直前の最終テストであり、納入先で試験することと捉え、ここでは述べない。

7.1.1 単体テスト

単体テストとは、モジュール単位でプログラムが正しく動作するか検証するテストである。GEMBA Noteでは、実装したフォーム、アイテムごとに構成されるフォーム部品の入力を試みる。入力形式や条件が仕様と合致しているか、ボタンアクションは正しく挙動しているか、カスケードメニューの項目は正しいか、また極限値の入力や設定をしてみる。開発パッケージ内でテストを行う。

通常ノートではなくシェアノートとしてフォームを運用する場合、次の項目をチェックする。

• 複数人数で試験対象となるフォームへの同時書き込み・編集を確認する
• GEMBA Talkをオプション購入している場合、通話テスト

現時点では、Android版には開発オプションがないので、Android上でのテストは割愛する。

7.1.2 結合テスト

結合テストとは、モジュールを結合させた状態で正しく動作するか検証するテストである。GEMBA Noteでは、フォームが他のフォームやアイテムと連動している場合（例えば、他ページや別ノートからの転記）、正しくデータの受け渡しが行われているか、データが存在しない場合、極限値が入っている時どうなるか組み合わせて動作を確認する。開発パッケージ内でテストを行う。

シェアノートとしてフォームを運用する場合、開いたシェアノートが存在すると集計漏れが発生するため、シェアノートを全て閉じた後、アグリゲーション検索実行が期待通りの結果を提示するか確認する。

現時点では、Android版には開発オプションがないので、Android上でのテストは割愛する。

7.1.3 システムテスト

開発パッケージ内での単体テストと結合テストが終わったのち、テスト用チームフォルダとテストユーザーを準備して、開発パッケージを配置する。そのチームフォルダ内でパッケージが利用できるように設定して、動作を確認する。

全社利用が必要であれば、全社配信を試み、個人フォルダ上でも動作するか確認する。もし社外ユーザーにも公開するのであれば、一般ユーザーアカウントに加えて社外ユーザーアカウントでも試験を実施する。

確認は単体テストと結合テストで行った試験項目を対象とする。ここでの重要事項は、アプリの機能としてユーザー属性、チーム属性に関係する条件がフォームあるいはアイテムに設定されている場合の挙動を確かめる。

7.2 試験項目の取得

単体テスト、結合テストで確認する試験項目は、まずフォームやアイテムを設計したときの入力部品を列挙する。例えば、不動産管理アプリの場合、フォームを構成するページの体裁とフォーム部品は次のように仕様設計されている（「付録1：不動産管理アプリ仕様書」を参照のこと）。

表7-1 フォームの体裁

表7-2 フォーム部品の仕様

試験では「詳細設定」を期待値と見なし、実際に正しく設定されているか、アプリケーションを動作して確認する。

試験項目の自動抽出

Markdown形式で記述された仕様書ファイルからテスト項目となる箇所を抽出して、テスト仕様書を生成する。

このツールは。以下のGitHubリポジトリから取得する。

https://github.com/mmj-ajiki/md2testspec

起動方法は次の通り。

Windowsの場合

> md2testspec.bat <仕様書ファイル名>.md

Linux/macOSの場合

> ./md2testspec.sh <仕様書ファイル名>.md

出力は、<仕様書ファイル名>_testspec.md という名前で出力される。

試験項目箇所の指定

試験項目の抽出を開始する箇所（見出し）には、Markdownの拡張記法{.testitems}を付与する。

###見出し {.testitems}

試験項目取得の終了は、次の見出しまでとする。取得する内容に表が含まれている場合、仕様定義と見なし、項目番号、テスト結果、そしてメモの列を自動的に追加する。

表7-3 元の表の例

表7-4 抽出後の表の例

7.3 試験項目の組み合わせ

試験項目を組み合わせて試験を実施するとき、項目数が多くなればなるほど組み合わせの数が増大する。組み合わせの数を合理的に削減するため、「ペアワイズ法」を用いる。

7.3.1 ペアワイズ法

ペアワイズ法は、ソフトウェアのバグの多くが1つまたは2つの因子の組み合わせによって発生している、という事実に基づいて、実験計画法を用いてテストケースを生成する方法である。

テストケースの組み合わせを表現する際に以下のような用語を用いる。

• 因子: テスト対象の項目（判定または条件）
• 水準: 因子の取り得る値
• 強さ: 因子の組み合わせ数

例えば、1因子当たり2個（例えば、TRUE/FALSE）の水準があるとき、因子が10個あれば、すべての水準の組み合わせは、2^10 ＝ 1024個になる。

ペアワイズ法は、すべての因子の組み合わせでなく、 2組の因子（強さ2） における水準の組み合わせをすべて網羅することによってテストケースを削減する手法である。

7.3.2 テストケース生成ツールPICT

PICTは、Microsoftが公開しているペアワイズ法によってテストケースを生成するためのオープンソース・ソフトウェアである。そのインストール方法と使い方を説明する。

PICTのインストール

Windowsの場合：

pict.exeを https://github.com/microsoft/pict/releases/からダウンロードし、コマンドプロンプトから実行できる適当なフォルダに配置する。

Linux/macOSの場合：

makeとg++がインストールされていることを前提とする。Pictのソースコードからmakeを使ってビルドを行う。

> git clone https://github.com/Microsoft/pict.git
> cd pict/
> make
> sudo install -m 0755 pict /usr/local/bin/pict

PICT実行ファイルの記述

PICTを実行するには、因子となる試験項目と取りうる値をテキストファイルに記述する。

因子a: 値a1, 値a2, 値a3, ... 値aN
因子b: 値b1, 値b2, 値b3, ... 値bN
...
因子z: 値z1, 値z2, 値z3, ... 値zN

PICTの実行例

contents/pictフォルダに置いてある testCase.txt を用いてPICTを実行してみる。

全ての組み合わせを抽出：

> pict testCase.txt /s /o:4
Combinations:   136
Generated tests:136
Generation time:0:00:00

テストケースは136通りである。 ※因子の数が3以下であると、エラーが発生する。

ペアワイズ法で抽出：

> pict testCase.txt /s /o:2
Combinations:   114
Generated tests:34
Generation time:0:00:00

テストケース数は34と削減される。

テストケースを出力：

> pict testCase.txt /o:2

因子（試験項目）とそれが取りうる値の組み合わせを提示する。この組み合わせに従って試験を実施する。この出力内容は、付録2：PICT出力例を参照のこと。

7.4 試験の実施と報告

ここではGEMBA Noteアプリの試験を実施して、結果を報告するまでの手順について述べる。

7.4.1 テスト仕様書の作成

7-2節で説明した試験項目抽出ツールは、生成したMarkdown形式の試験項目ファイルの前に序論、目的、テスト環境など、後ろにテスト判定とコメントの見出しを追加して1つのテスト仕様書を生成する。内容を記入してテスト仕様書を完成させる。試験因子の組み合わせごとに、仕様書のコピーを準備する。

テスト仕様書のヘッダの内容

# 〇〇テスト仕様書

## 序論（はじめに）

### 目的

### テスト期間

### 注意事項など

## テスト環境について

### 試験対象機材とOSバージョン

### テスト用アカウント

### テストデータの準備・作成方法など

テスト仕様書のフッタの内容

## テスト判定

### テスト結果

| 試験日 | 試験担当者 | OK | NG | Attn |
| --- | --- | --- | --- | --- |
| YYYY-MM-DD | - | - | - | - |

### 判定結果

合格/不合格

### コメント

7.4.2 テスト環境の準備

テストを開始するにあたって必要なユーザーアカウント、機材（iPad, iPhone, Androidデバイス、Windows PCやタブレット）、テストに用いるデータの内容を明確にする。

7.4.3 試験の実施

テスト仕様書のテスト項目を1つ1つ確認する。期待値通りの設定あるいは動作であれば、テスト結果にOK、動作しなければNG、何かしら疑問や懸念があれば、Attn (Attention)と記述し、メモ欄にその内容用を記述する。

7.4.4 試験結果の報告

テスト仕様書の最後にテスト判定の結果とコメントを記入する。

表7-5 テストの判定記入事項

表7-6 テストの判定記入例

付録1：不動産管理アプリケーション仕様書

1. はじめに

1-1 目的

このドキュメントは、不動産物件を取り扱うアプリケーションの機能と実現するための構成要素とその定義を詳細に記述する。なお本書はMarkdown形式で作成する文書の例でもあり、そのソースファイルはこちらからダウンロードできる。

Markdownファイルをダウンロード

1-2 スコープ

実現するアプリケーションは「不動産物件アプリケーション」と呼ぶ。これ以降は「物件アプリ」と呼ぶ。eYACHOあるいはGEMBA Note上で動作する。物件アプリは不動産物件を管理するための簡易的な機能を2つ提供する。

1. 物件フォームから物件情報を登録する
2. 蓄積された物件情報から物件種別で絞り込んで一覧表示させる

eYACHOあるいはGEMBA Noteの開発パッケージ（不動産管理パッケージ）として運用可能とし、ユーザーに配信する。

1-3 各章の説明

第2章では物件アプリのシステム構成と機能概要を述べ、第3章でそれぞれの機能を詳細に説明し、実装するための構成要素の定義を行う。

2. 仕様概要

2-1 システム構成

物件アプリの構成図を示す。

ローカル環境の説明：

• ローカル環境（デバイス内部）には不動産管理パッケージが搭載されている
• 不動産管理パッケージには物件に関わるフォーム、タグスキーマ、アグリゲーションが含まれる
• 物件フォーム使って、物件タグインスタンスを保存・編集する
• 蓄積した物件タグインスタンスを参照して、物件一覧をアグリゲーションが表示する

サーバー環境の説明：

• 各ユーザーのローカル環境には不動産管理パッケージが搭載されている
• 各ユーザーが物件フォームを使って、物件タグインスタンスを保存・編集する
• 物件タグインスタンスは、MetaMoJiクラウドにアップロードされる
• アップロードされたタグインスタンスは、各ユーザーのローカル環境にダウンロードされる

2-2 機能概要

2-3 利用するユーザー

将来的に、不動産物件を所有し、利用する不動産関係者が利用できるようにする。そのため、価格、住所だけではなく、地図上の位置、間取り、設備などを情報として追加していく必要がある。

2-4 制約事項と依存関係

• 物件情報すべてを網羅するわけではなく、そのプロトタイプとして最低限の物件属性を定義する。
• アグリゲーションの実行結果件数は、1ページに収まるぐらいとする。
  • 数が多くなりすぎてもページングは組み込まない。
• 同じ物件フォームを他のユーザーと同時書き込みをしない。
  • シェア機能は使わない。

3. 仕様詳細

3-1 物件情報登録（物件フォームの定義）

不動産物件情報を1つ登録するための帳票の仕様を定義する。

3-1-1 フォームの体裁 {.testitems}

定義項目	記述内容
フォーム名称	物件フォーム
種類	横向き
サイズ	はがき
背景	薄緑
縮尺	設定なし

3-1-2 フォーム部品の仕様 {.testitems}

3-1-3 フォーム部品の配置 {.testitems}

物件フォーム上の見出しと部品の配置は次の図のようにする。

3-1-4 テンプレートの定義 {.testitems}

ノートテンプレートの定義：

用紙テンプレートの定義：

3-1-5 カスタムUI設定 {.testitems}

3-1-6 タグスキーマの仕様

タグスキーマの定義：

フォーム部品とタグプロパティのリンク：

3-2 物件情報表示（物件一覧アグリゲーションの定義）

登録した物件情報を一覧表示する。表示する項目は機能1の入力項目すべてである。 さらにタイプで絞り込んで表示する。

3-2-1 アグリゲーションの仕様

3-2-2 検索パラメータ「TYPE」の仕様

3-2-3 コネクタの仕様

3-2-4 実行処理 {.testitems}

アグリゲーションはページ上に配置したフォーム部品2つから実行する。そのイメージは次の通り。

3-3 パフォーマンス仕様

物件データ数が1,000をこえても1秒以内に一覧表示がされる（仮）。

3-4 セキュリティ仕様

• 特定のチームが利用できるように、開発パッケージは全社へは配置しない。
• 同じフォームを他のユーザーと同時書き込みをさせない（フォームをシェアノートにしない）。

3-5 運用の仕様

フォルダ構成

チームフォルダ
|-- ビル事業本部
|    |-- 法人営業1部
|    |-- 法人営業2部
|    |-- 法人営業3部
|    |-- 海外事務所統括部
|    |-- 事業推進部
|    
|-- 住宅分譲事業本部
|    |-- 営業部
|    |-- 事業企画部
|    |-- 事業推進部
|    |-- マンション管理部
|
|-- 都市開発事業本部
|   |-- 営業部
|   |-- 事業企画推進部

開発パッケージ管理項目

参考資料

本アプリケーションを開発するにあたって、参考にしたドキュメントは次の通りである。

1. パッケージ開発ガイド 日本語 (zipファイル)
2. フォーム作成ガイド 日本語

付録2：PICT出力例

7.3節で用いたサンプルのテストケースファイルをPICTに与えた時に出力された内容である。

対象Pictテストケースファイル

出力内容

OS 製品 配置フォルダ ユーザー
iOS 14 eYACHO 個人 社外ユーザー
iOS 12 GEMBA Note チーム 社外ユーザー
iOS 18 eYACHO チーム 社員
Android 13 GEMBA Note 個人 社外ユーザー
Windows 11 eYACHO 個人 社員
Android 14 GEMBA Note 個人 社員
Android 10 GEMBA Note チーム 社外ユーザー
Windows 11 GEMBA Note チーム 社外ユーザー
Windows 10 eYACHO 個人 社外ユーザー
Android 15 GEMBA Note 個人 社外ユーザー
iOS 14 GEMBA Note チーム 社員
Android 11 eYACHO チーム 社外ユーザー
iOS 15 eYACHO 個人 社外ユーザー
iOS 18 GEMBA Note 個人 社外ユーザー
Android 12 eYACHO 個人 社員
iOS 10 eYACHO チーム 社員
Android 15 eYACHO チーム 社員
Android 13 eYACHO チーム 社員
iOS 11 GEMBA Note チーム 社員
iOS 16 eYACHO チーム 社員
iOS 16 GEMBA Note 個人 社外ユーザー
iOS 13 eYACHO チーム 社員
iOS 17 GEMBA Note 個人 社員
Android 12 GEMBA Note チーム 社外ユーザー
Android 14 eYACHO チーム 社外ユーザー
Android 11 GEMBA Note 個人 社員
iOS 11 eYACHO 個人 社外ユーザー
Windows 10 GEMBA Note チーム 社員
iOS 17 eYACHO チーム 社外ユーザー
Android 10 eYACHO 個人 社員
iOS 13 GEMBA Note 個人 社外ユーザー
iOS 10 GEMBA Note 個人 社外ユーザー
iOS 15 GEMBA Note チーム 社員
iOS 12 eYACHO 個人 社員

付録3：GitHub公開リポジトリ

6.4節で利用するサンプルRESTサーバーのソースファイルを公開している場所である。

付録4：生成AIの利用事例

4.4節で述べた生成AIへの要求文についてさらなる例を示す。

質問の意図：日付ごとに物件の名前と訪問者の名前を集計する。

{#物件タグスキーマ}は{#物件タグプロパティ}から構成されます。
{#訪問者カードのタグスキーマ}は{#訪問者カードのタグプロパティ}から構成されます。
物件ページと同じページにある訪問者カードの訪問日ごとに、物件の名称、顧客名を集計するSQLiteのSQLを作成してください。ただし、次の{#条件}に従います。

#条件
・「同じページ」は_pageIdカラムを利用する。
・集約結果は、{#訪問者履歴のタグスキーマ}の{#訪問者履歴のタグプロパティ}のプロパティIDに出力する。
・訪問日の順序でソートする。

#物件タグスキーマ
| タグID | 日本語表示名 | 設定箇所 |
| --- | --- | --- |
| Property | 物件 | ページ |

#物件タグプロパティ
| プロパティID | 日本語表示名 | データの型 |
| --- | --- | --- |
| Name | 名称 | 文字列 |
| Type | 物件タイプ | 文字列 |
| Price | 価格 | 整数 |
| Address | 住所 | 文字列 |

#訪問者カードのタグスキーマ
| タグID | 日本語表示名 | 設定箇所 |
| --- | --- | --- |
| Visitor | 訪問者 | 図形（長方形、線は灰色） |

#訪問者カードのタグプロパティ
| プロパティID | 日本語表示名 | データの型 |
| --- | --- | --- |
| visitedDate | 訪問日| 日時型 |
| customerName  | 顧客名 | 文字列型 |
| phone  | 電話番号 | 文字列型 |

#訪問者履歴のタグスキーマ
| タグID | 日本語表示名 | 設定箇所 |
| --- | --- | --- |
| visitorHistory | 訪問者履歴 | - |

#訪問者履歴のタグプロパティ
| プロパティID | 日本語表示名 | データの型 |
| --- | --- | --- |
| visitedDate | 日付 | 日時型 |
| propertyName | 物件名称 | 文字列型 |
| visitorName  | 訪問者名 | 文字列型 |

生成されたSQL：

SELECT 
    v.visitedDate AS visitedDate, 
    p.Name AS propertyName, 
    v.customerName AS visitorName
FROM Visitor v
JOIN Property p ON v._pageId = p._pageId
ORDER BY v.visitedDate;

着目点：

• Visitor テーブル（訪問者カード）から visitedDate（訪問日）と customerName（顧客名）を取得。
• Property テーブル（物件）と _pageId で結合し、Name（物件名称）を取得。
• visitedDate の昇順でソート。

実際にアグリゲーションの動作を確認するため、次のノートを開く。

「訪問者履歴一覧」と書かれたページへ移動し、最新に更新 ボタンをクリックしてみる。

• 「物件訪問者データ」ノートを開き、新たな訪問者カードを追加してみる。
• 再び「生成AIの利用」ノートに戻り、「訪問者履歴一覧」と書かれたページへ移動し、最新に更新 ボタンをクリックして変更が反映されているか確認する。

更新履歴