diff --git a/ER.pdf b/ER.pdf
new file mode 100644
index 0000000..e490f50
--- /dev/null
+++ b/ER.pdf
Binary files differ
diff --git a/mituyuki.pdf b/mituyuki.pdf
index 5a629b2..122b878 100644
--- a/mituyuki.pdf
+++ b/mituyuki.pdf
Binary files differ
diff --git a/mituyuki.tex b/mituyuki.tex
index 01a1f0f..18a83e4 100644
--- a/mituyuki.tex
+++ b/mituyuki.tex
@@ -16,7 +16,7 @@
   \date{平成30年1月15日}
   \maketitle
   \begin{center}
-%   \fontsize{11pt}{11pt}\selectfont
+%   \fontsize{11pt}{11pt}\selectfontd
    {\bfseries 概要}
   \end{center}
 
@@ -60,12 +60,12 @@
  利用者同士のコミュニケーションや情報共有は念頭に置かれていない場合が多
  いとされている\cite{oni, xEx}。また、位置情報を扱うため、Apple StoreやGoogle
  Playから配布されているアプリケーションであっても、位置情報を不正に取得
- している例
- が確認されている\cite{alert}。\par
- 更に、``いまどこ?位置検索''等をはじめとした無料のアプリケーションでは共
+ している例が確認されている\cite{alert}。\par
+ 更に、Google Playでnekonotesoftから配信されている情報共有ソフト``いまど
+ こ?位置検索''等をはじめとした無料のアプリケーションでは共
  有できる数に制限があったり全ての機能を利用するには有料であったりといっ
  たケースが存在する。例として上述の``いまどこ?位置検索''では14日間の試用
- 期間では「自動測位機能」および「見守り機能」が利用できなく、また14日目
+ 期間では「自動測位機能」および「見守り機能」を利用することができず、また14日目
  以降の利用にはライセンスの購入と月額料の支払いが必要になる\cite{imadoko}。\par
  そこで、特別な外部のアカウントや電話番号等の登録情報を必要としない、 参
  加者の状態を個人単位で制限なくリアルタイムで相互に把握することができる
@@ -81,10 +81,11 @@
 る\cite{smart}。ホームサーバ同士の通信により在宅情報から生き埋め
 等の被災者を特定し、
 救助要請マップを作成してシミュレーション実験を行い、研究の有効性
-を示している。しかし、ここではホームサーバごとに管理しているため、人数に
+を示した。しかし、ここではホームサーバごとに管理しているため、人数に
 誤差が出ることや使用する多数の機器に対し電力を供給し続けなければならない
 ことが問題となっている。\par
-また、宗森らは、PDA(携帯情報端末)とGPSと携帯電話を使用
+また、複数人の位置情報を用いた遠隔地での情報共有に関して、宗森らはPDA(携
+帯情報端末)とGPSと携帯電話を使用
 し、位置情報を用いて遠隔地間で行う鬼ごっこをはじめ複数種の電子鬼ごっこの
 実験を行っている\cite{oni}。位置情報を変換することで離れた場所でも問題なく
 電子鬼ごっこを行い、実験の結果では位置情報を柔軟に扱ったサービスが受け入
@@ -102,10 +103,12 @@
  とし、最短避難経路提示システムを開発した\cite{mobile}。そこでは、従来の
  災害時の伝言板等のシステムでは携帯電話とPCとの連携がとれず、避難者の立場
  が考慮されていないことが問題視されていた。そこで、避難所や交差点にIDと
- グループ番号付加することで、携帯電話を活用し最短の避難経路に誘導するシ
+ グループ番号を付加することで、携帯電話を活用し最短の避難経路に誘導するシ
  ステムを実現した。また、GPS内蔵型携帯電話が使用できない状況ではWi-Fi付
  きノートPCを用い、Google社からWi-FiのアクセスポイントとIPアドレスを基に
- 測位された現在地を利用することで実測値との誤差を5\%以下で実現した。
+ 測位された現在地を利用することで実測値との誤差を5\%以下で実現した。ここ
+ から、災害時であっても正確に位置情報を発信・共有可能であることが示され
+ ている。
 
 
 \subsection{避難後の安否確認}
@@ -122,35 +125,28 @@
  である``現在地を共有''等の位置情報の共有を目的としたアプリケーションが
  存在する。しかし、これらのアプリケーションは利用する度に共有相手の設定
  や時間の指定や設定の変更が必要になる。また、個人間の共有を目的にしてい
- るため、複数人のグループ等で共有をする際は図\ref{kizon}のようにグループ
- 内の全員がお互いに個人間の設定をする必要がある。\par
- また、これらのアプリケーションではお互いに固有のアカウントを把握してい
+ るため、複数人のグループ等で共有をする際はグループ内の全員がお互いに個
+ 人間の設定をする必要がある。そのため、表\ref{system}のように人数が増えるほ
+ ど必要な設定数が増えていくことになる。\par
+ また、これらのアプリケーションではお互いにiCloudやGoogleアカウント等の
+ 固有のアカウントを把握してい
  る利用者の情報しか得ることができないため、災害時に被災者全体の避難状況
  を把握することは不可能である。
 
- \begin{figure}[h]
-   \begin{center}
-    \includegraphics[bb=32 19 829 565,scale=0.3]{kizon.pdf}
-    \caption{既存のアプリケーション}
-    \label{kizon}
-   \end{center}
-  \end{figure}
-    \subsection{JSON形式}
-  JavaScript Object Notation(JSON)とは、データを表現するための記法である。
-  表形式では記述が困難な構造のデータを、人間に対しての可読性を残しつつ計
-  算機に対して伝達出来るような記法である。
-  \subsection{CGI}
-  Common Gateway Interface(CGI)とは、 Webサーバとプログラム間のデータの
-  送受信の規格で、ブラウザからの要求に応じてプログラムを起動し、その
-  結果をブラウザに返すためのインターフェイスである。
-
+ % \begin{figure}[h]
+ %   \begin{center}
+ %    \includegraphics[bb=32 19 829 565,scale=0.3]{kizon.pdf}
+ %    \caption{既存のアプリケーション}
+ %    \label{kizon}
+ %   \end{center}
+ %  \end{figure}
 
  \section{提案するシステム}
 そこで、本研究では以下のような機能を導入したシステムを提案する。
   \begin{enumerate}
    \item システム利用者の位置情報を把握できる機能\par
 	 利用者がシステムに送信した位置情報のデータを、ブラウザ上のマッ
-	 プにリアルタイムで表示する。
+	 プにユーザの設定する分単位で更新して表示する。
    \item 一定範囲の地域内の分布を表示するマップ作成アプリケーション\par
 	 災害時に利用者の避難状況を把握できるようにするため、設定した地
 	 域内の利用者の分布をブラウザ上のマップに表示する。ここでは個人
@@ -162,29 +158,44 @@
 	 \par
 	 上記の少人数グループ内で、個人を判別した上で位置情報を相互にリ
 	 アルタイムで管理できるマップをブラウザ上で実現する。
-
   \end{enumerate}
 
+
+ \begin{table}[h]
+  \begin{center}
+   \begin{tabular}{|c|c|c|}\hline
+    利用人数&既存のシステム &本システム \\\hline
+    2 & 2回 & 2回 \\\hline
+    3 & 6回 & 3回 \\\hline
+    4 & 12回 & 4回 \\\hline
+    n & n(n-1)回 & n回 \\\hline
+   \end{tabular}
+   \caption{システム利用時に必要な設定数の差}
+   \label{system}
+  \end{center}
+ \end{table}
+
 \chapter{システムの構築環境}
 本研究で開発するシステムの内容について記述する。
   \section{用語解説}
   システムを提案する上で必要となる用語の解説を記述する。
 
-  \subsection{JSON形式}
-  JavaScript Object Notation(JSON) とは、データを表現するための記法であ
-  る。表形式では記述が困難な構造のデータを、人間に対しての可読性を残しつつ計
-  算機に対して伝達出来るような記法である。
+  % \subsection{JSON形式}
+  % JavaScript Object Notation(JSON) とは、データを表現するための記法であ
+  % る。表形式では記述が困難な構造のデータを、人間に対しての可読性を残しつつ計
+  % 算機に対して伝達出来るような記法である。
   
-  \subsection{CGI}
-  Common Gateway Interface(CGI)とは、 Webサーバとプログラム間のデータの
-  送受信の規格で、ブラウザからの要求に応じてプログラムを起動し、その
-  結果をブラウザに返すためのインターフェイスである。
+  % \subsection{CGI}
+  % Common Gateway Interface(CGI)とは、 Webサーバとプログラム間のデータの
+  % 送受信の規格で、ブラウザからの要求に応じてプログラムを起動し、その
+  % 結果をブラウザに返すためのインターフェイスである。
   
   \subsection{データの正規化}
   今回は関係データベース(DBMS)でデータを管理するため、データを正規化する必
   要がある。正規化と
   は、データを効率良く扱うために特定のルールにしたがって整理することであ
-  る。以下に正規化の手順について記述する。
+  る。以下に正規化の手順について本システムで利用したデータの一部を用いて
+  記述する。
   
    \subsubsection{非正規形}
    整理されていない生の状態のデータのことを非正規形と言う。データベースで
@@ -194,8 +205,10 @@
    \begin{table}[h]
     \begin{center}
      \begin{tabular}{|c|c|c|c|}\hline
-      00100 & 大根 & 酒田30円30個 & 鶴岡40円40個\\\hline
-      00101 & サツマイモ & 三川40円20個 & 鶴岡50円10個\\\hline
+      太朗 & hogehoge & 鶴岡 & Aグループ38.4, 138.5 12:00 Bグループ38.6,
+		  138.1 13:00\\\hline
+      花子 & gehogeho & 酒田 & Aグループ38,1, 138.1 13:05\\\hline
+      鈴木 & pasuwa-do & 鶴岡 & Bグループ38.5, 138.5 14:30\\\hline
      \end{tabular}
      \caption{生のデータ}
     \end{center}
@@ -206,112 +219,129 @@
    ていたりするデータを別の行(レコード)に分離し、繰り返しを排除する。\par
    \begin{table}[h]
     \begin{center}
-     \begin{tabular}{|c|c|c|c|c|}\hline
-      cord & items & place & price &  quant\\\hline
-      00100 & 大根 & 酒田 & 30円 & 30個 \\\hline
-      00100 & サツマイモ & 三川 & 40円 & 20個 \\\hline
-      00101 & 大根 & 鶴岡 & 40円 & 40個 \\\hline
-      00101 & サツマイモ & 鶴岡 & 50円 & 10個 \\\hline
-      %  \label{kuri}
+     \begin{tabular}{|c|c|c|c|c|c|c|}\hline
+      name & pass & group & local &  lat & lng & time\\\hline
+      太朗 & hogehoge & Aグループ & 鶴岡 & 38.4 & 138.5 & 12:00\\\hline
+      太朗 & hogehoge & Bグループ & 鶴岡 & 38.6 & 138.1 & 13:00\\\hline
+      花子 & gehogeho & Bグループ & 酒田 & 38.1 & 138.1 & 13:05\\\hline
+      鈴木 & pasuwa-do & Bグループ & 鶴岡 & 38.5 & 138.5 & 14:30\\\hline
      \end{tabular}
+     \label{uri}
      \caption{繰り返しを排除した形}
     \end{center}
    \end{table}
    更に、テーブルごとにデータを一意に識別するための項目を設定する。このよ
    うなコードのことを主キーという。主キーは複数カラムから構成されることも
    あり、その場合は複合主キーと言う。\par
-   \begin{table}[h]
-    \begin{center}
-     \begin{tabular}{|c|c|c|c|c|c|}\hline
-      cord & icord & items & place & price & quant\\\hline
-      00100 & 0001 & 大根 & 酒田 & 30円 & 30個 \\\hline
-      00100 & 0002 & サツマイモ & 三川  & 40円 & 20個 \\\hline
-      00101 & 0001 & 大根 & 鶴岡 & 40円 & 40個 \\\hline
-      00101 & 0002 & サツマイモ & 鶴岡 & 50円 & 10個 \\\hline
-     \end{tabular}
-     \caption{第1正規形}
-     \label{daiiti}
-    \end{center}
-   \end{table}
-   
    
    \subsubsection{第2正規化}
-   表\ref{daiiti}の第1正規形から部分関数従属性を排除する。関数従属とは、あ
+   表\ref{uri}の第1正規形から部分関数従属性を排除する。関数従属とは、あ
    る属性Xを決めると他の属性Yが一意に決まるような状態のことである。この時、
    Xを決定項、Yを被決定項呼ぶ。部分関数従属とは、このときの被決定項が複数
-   の決定項を持っている状態のことである。表\ref{daiiti}の場合、icordが決ま
-   ればitemsが決まるが、他の項目が決定しない。そこで、icordを主キーとする
-   itemsだけをまとめたテーブルを新規に作成する。第2正規化をすることでテー
-   ブルごとの列の数を減らし、データの管理をより単純化する。
+   の決定項を持っている状態のことである。表\ref{uri}の場合、nameが決ま
+   ればpassが決まるが、他の項目が必ずしも決定しない。そこで、例えばname
+   を主キーとする passだけをまとめたテーブルを新規に作成する。このように
+   第2正規化をする
+   ことでテーブルごとの列の数を減らし、データの管理をより単純化する。
    
    \begin{table}[h]
     \begin{center}
      \begin{tabular}{|c|c|}\hline
-      icord & items \\\hline
-      0001 & 大根  \\\hline
-      0002 & サツマイモ \\\hline
+      name & pass \\\hline
+      太朗 & hogehoge  \\\hline
+      花子 & gehogeho \\\hline
+      鈴木 & pasuwa-do \\\hline
      \end{tabular}
-     \caption{商品テーブル}
+     \caption{パスワードテーブル}
     \end{center}
    \end{table}
    
    \begin{table}[h]
     \begin{center}
+     \begin{tabular}{|c|c|}\hline
+      name & local \\\hline
+      太朗 & 鶴岡  \\\hline
+      花子 & 酒田 \\\hline
+      鈴木 & 鶴岡 \\\hline
+     \end{tabular}
+     \caption{地方テーブル}
+    \end{center}
+   \end{table}
+
+   \begin{table}[h]
+    \begin{center}
      \begin{tabular}{|c|c|c|c|c|}\hline
-      cord & icord &  place & price & quant\\\hline
-      00100 & 0001 & 酒田 & 30円  & 30個 \\\hline
-      00100 & 0002 & 三川 & 40円 & 20個\\\hline
-      00101 & 0001 & 鶴岡 & 40円  & 40個 \\\hline
-      00101 & 0002 & 鶴岡 & 50円 & 10個 \\\hline
+      name & group  & lat & lng & time\\\hline
+      太朗 & Aグループ  & 38.4 & 138.5 & 12:00\\\hline
+      太朗 & Bグループ & 38.6 & 138.1 & 13:00\\\hline
+      花子& Bグループ & 38.1 & 138.1 & 13:05\\\hline
+      鈴木 & Aグループ & 38.5 & 138.5 & 14:30\\\hline
      \end{tabular}
       \label{daini}
-      \caption{注文テーブル}
+      \caption{ユーザ情報テーブル}
     \end{center}
    \end{table}
   
    \subsubsection{第3正規化}
    第2正規形から推移的関数従属性を排除する。推移的関数従属性とは、被決定
    項または決定項と被決定項の組み合わせによって他の被決定項が一意に決ま
-   ることを指す。今回の場合、表\ref{daini}において、icordとplaceが決まれ
-   ばpriceも決まるため、別のテーブルを新たに作成する。最終的には表3.6,
-   3.7, 3.8の状態になる。
+   ることを指す。今回の場合、表\ref{daini}において、nameとgroupが決まれ
+   ばその他のデータが決まるため、別のテーブルを新たに作成する。検索の効
+   率を考慮して部分的に正規化の程度を敢えて落とした状態のままにする場合
+   もある。最終的には表3.6~3.9の状態になる。
     \begin{table}[p]
      \begin{center}
       \begin{tabular}{|c|c|}\hline
-       icord & items \\\hline
-       0001 & 大根  \\\hline
-       0002 & サツマイモ \\\hline
+       name & pass \\\hline
+       太朗 & hogehoge  \\\hline
+       花子 & gehogeho \\\hline
+       鈴木 & pasuwa-do\\ \hline
       \end{tabular}
-      \caption{商品テーブル}
+      \caption{パスワードテーブル}
      \end{center}
     \end{table}
 
-    \begin{table}
-     \begin{center}
-      \begin{tabular}{|c|c|c|}\hline
-       cord & icord & quant\\\hline
-       00100 & 0001 & 30個 \\\hline
-       00100 & 0002 & 20個 \\\hline
-      00101 & 0001 & 40個 \\\hline
-       00101 & 0002 & 10個 \\\hline
-      \end{tabular} 
-      \caption{注文テーブル}
-     \end{center}
-    \end{table}
-    
-    \begin{table}
-     \begin{center}
-      \begin{tabular}{|c|c|c|}\hline
-       icord & place & price\\\hline
-       0001 & 酒田 & 30円 \\\hline
-       0002 & 三川 & 40円 \\\hline
-       0001 & 鶴岡 & 40円 \\\hline
-       0002 & 鶴岡 & 50円 \\\hline
-      \end{tabular}
-      \caption{価格テーブル} 
-     \end{center}
-    \end{table}
+   \begin{table}[h]
+    \begin{center}
+     \begin{tabular}{|c|c|}\hline
+      name & local \\\hline
+      太朗 & 鶴岡  \\\hline
+      花子 & 酒田 \\\hline
+      鈴木 & 鶴岡 \\\hline
+     \end{tabular}
+     \caption{地方テーブル}
+    \end{center}
+   \end{table}
 
+   \begin{table}[h]
+    \begin{center}
+     \begin{tabular}{|c|c|c|c|}\hline
+      name & group  & lat & lng \\\hline
+      太朗 &  Aグループ  & 38.4 & 138.5 \\\hline
+      太朗 & Bグループ & 38.6 & 138.1 \\\hline
+      花子& Bグループ & 38.1 & 138.1 \\\hline
+      鈴木 & Aグループ & 38.5 & 138.5 \\\hline
+     \end{tabular}
+      \caption{位置情報テーブル}
+    \end{center}
+   \end{table}
+
+
+   \begin{table}[h]
+    \begin{center}
+     \begin{tabular}{|c|c|c|}\hline
+      name & group  & time\\\hline
+      太朗 &  Aグループ  & 12:00\\\hline
+      太朗 & Bグループ & 13:00\\\hline
+      花子& Bグループ & 13:05\\\hline
+      鈴木 & Aグループ & 14:30\\\hline
+     \end{tabular}
+      \label{daini}
+      \caption{利用時刻テーブル}
+    \end{center}
+   \end{table}
+
+  
  \section{作業環境}
   開発は以下の環境で行う。
   \begin{itemize}
@@ -335,35 +365,61 @@
   %  \item local(ユーザ名, 設定した地域)
   % \end{itemize}
     
+
+\chapter{システムの設計}
+本システムの設計について記述する。
+
+ \section{RDBMSによる管理}
+ 前章で延べた通り本システムではRDBMSで各データを管理する。そこからRubyプ
+ ログラムやCGIからSQL文を実行することで必要なデータを取り出す形式である。
+ 本システムで扱うデータのER図は図\ref{ER}の通りである。
+ 
+  \begin{figure}[h]
+   \begin{center}
+    \includegraphics[bb=0 0 398 436,scale=0.3]{ER.pdf}
+    \caption{本システムで扱うデータのER図}
+    \label{ER}
+   \end{center}
+  \end{figure}
+  
+  
+ \section{JavaScriptを用いた動的なWebの作成}
+  本システムでは主にJavaScriptを用いて動的なWebページを作成する。
+  \subsection{LeafLet.jsを用いたマップ作成}
+  
+
+  \subsection{Ajaxによる非同期通信}
+  
+  
 \chapter{システムの概観と実行}
 実際に構築したシステムの概観と実行する行程について記述する。
  \section{本システムの概観}
  本システムを利用する際の流れは以下の通りである。
-\begin{enumerate}
- \item アカウントの作成・ログイン\par
-       本システムを利用するための情報を入力しアカウントを作成し、ログイ
-       ンする。
- \item グループの作成・加入・選択\par
-       指定したユーザ同士で構成されるグループ周辺の設定をする。
- \item 利用端末から情報を送信・取得\par
-       ユーザ自身の位置情報・利用時間等の情報をDBMSに送信すると同時に最
-       新の情報を取得する。
- \item 取得したデータが反映されたマップの閲覧\par
-       取得したデータを元に目的に応じて作成されたマップを閲覧する。
-\end{enumerate}
-
-なお、目的がユーザ自身の情報の更新に限る場合グループを選択する必要はなく、自身
-の情報のみを更新する機能を利用することができる。利用時の概念図は図
-\ref{sys}のようになる。各行程の詳細な手順は次章以降に記述する。
-
-\begin{figure}[h]
- \includegraphics[bb=30 69 561 795,scale=0.5]{system.pdf}
- \caption{システム利用時の概念図}
-\label{sys}
-\end{figure}
-
-                 
-
+ \begin{enumerate}
+  \item アカウントの作成・ログイン\par
+	本システムを利用するための情報を入力しアカウントを作成し、ログイ
+	ンする。
+  \item グループの作成・加入・選択\par
+	指定したユーザ同士で構成されるグループ周辺の設定をする。
+  \item 利用端末から情報を送信・取得\par
+	ユーザ自身の位置情報・利用時間等の情報をDBMSに送信すると同時に最
+	新の情報を取得する。
+  \item 取得したデータが反映されたマップの閲覧\par
+	取得したデータを元に目的に応じて作成されたマップを閲覧する。
+ \end{enumerate}
+ 
+ なお、目的がユーザ自身の情報の更新に限る場合グループを選択する必要はなく、自身
+ の情報のみを更新する機能を利用することができる。利用時の概念図は図
+ \ref{sys}のようになる。各行程の詳細な手順は次章以降に記述する。
+ 
+ \begin{figure}[h]
+  \begin{center} 
+   \includegraphics[bb=30 69 561 795,scale=0.5]{system.pdf}
+   \caption{システム利用時の概念図}
+   \label{sys}
+  \end{center}
+ \end{figure}
+ 
  \section{個人アカウントの管理}
  本システムを利用する際、利用者を特定するための個人アカウント周辺
  の機能に関して記述する。
@@ -373,7 +429,7 @@
   地域の3項目を入力する。ユーザ名を個人を判別するためのデータ
   とするため、ユーザが既存のアカウントと重複していた際にはエラーを表示す
   る。
-
+  
   \begin{figure}[h]
    \begin{center}
     \includegraphics[bb=0 0 477 229,scale=0.9]{make.pdf}
@@ -410,15 +466,15 @@
   置情報を相互に把握したい状況で利用することも目的とする。この機能を利用
   する際に利用者が送信したデータも\ref{bunpu}章のマップ作成に使用する。
   \par
-  この際、既存のアプリケーションでは複数人で情報を相互に把握する際、図\ref{kizon}の矢印の数だけ登録が必要になるが、本システムでは図\ref{my}のようになる。
+  % この際、既存のアプリケーションでは複数人で情報を相互に把握する際、図\ref{kizon}の矢印の数だけ登録が必要になるが、本システムでは図\ref{my}のようになる。
   
- \begin{figure}[h]
-   \begin{center}
-    \includegraphics[bb=32 19 829 565,scale=0.3]{my.pdf}
-    \caption{本システム利用時}
-    \label{my}
-   \end{center}
-  \end{figure}
+ % \begin{figure}[h]
+ %   \begin{center}
+ %    \includegraphics[bb=32 19 829 565,scale=0.3]{my.pdf}
+ %    \caption{本システム利用時}
+ %    \label{my}
+ %   \end{center}
+ %  \end{figure}
 
   \begin{figure}[h]
    \begin{center}
@@ -475,8 +531,9 @@
 ムを構築することができた。また、それにともない複数人のグループ単位で情報
 を共有できるシステムを構築した。
 
-
-  \section{有事の際の情報リセット}
+ \section{システムへの評価と展望}
+ 本システムへの評価と展望について記述する。
+  \subsection{有事の際の情報リセット}
   本システムは災害時のみならず、平常時からの利用も考慮している。それに伴
   い、地震等が発生する以前のデータが残っていると地震後に全てのユーザが情
   報を更新しなければ正確な避難情報を得ることができなくなるという事態に陥
@@ -487,18 +544,18 @@
   災害時に対応可能にする必要がある\cite{screape}。
   
   
- \section{グループ参加の有無と個人の特定}
+ \subsection{グループ参加の有無と個人の特定}
  本システムを個人でのみ利用しているユーザに関して、個人を特定する方法が完
  全にない状態になっている。匿名性の保持と言う点では問題はないが、災害時
  を考えた際に個人の特定の必要性に関して懸念される。
 
- \section{グループ管理のセキュリティ観点}
+ \subsection{グループ管理のセキュリティ観点}
  現段階の本システムは、ユーザであれば誰でも存在する全てのグループに自由
  に出入りできるようになっている。グループにIDを割り振る、特定のメンバー
  に承認周りの権限を付与する等してグループ管理周辺のセキュリティについて
  整えていく必要がある。
  
- \section{同時利用時のキャパシティ}
+ \subsection{同時利用時のキャパシティ}
  \ref{bunpu}章から、個人の特定を
   目的としない場合の避難所から離れている利用者のばらつき等の視認性においては
   問題なく見えるが、災害時に多くの利用者が同時に利用した場合、またより人口