電子契約システム：次のステップ～利用者ごとに異なる契約内容の実装その2

電子契約アプリを開発する過程で、気になった方法を今回もAIに尋ねてみることにしました。以下はそのプロンプトです。

ワタクシ

ちなみに、各ライブラリーを再度アップロードする必要があると思いますが、共有レンタルサーバーで利用者ごとにサブディレクトリを作り、例えば、keiyaku.com/ito とかkeiyaku.com/suzuki とか keiyaku.com/tanaka とかにして、利用者にURLを送って電子契約してもらうといった方法は考えられますが？　その場合、各ライブラリは絶対パスで require を指定することは可能ですか？

AIエージェントさん

ご質問ありがとうございます。共有レンタルサーバーで利用者ごとにサブディレクトリを作成し、それぞれのディレクトリに電子契約システムを配置するアプローチは技術的には可能ですが、運用面で大きな問題と非効率性が生じます。また、ライブラリの require を絶対パスで指定することは可能ですが、推奨されません。以下に、このアプローチの評価と、より良い代替案を説明します。

❌ 利用者ごとのサブディレクトリ構成の評価
1. 1. 運用・保守の非効率性（致命的な問題）
2. 2. ライブラリの絶対パス指定について
💡 推奨される代替案：一つのシステム、データで分岐
1. 1. 静的リソースの共通化（必須）
2. 2. 個別化されたURLの利用（データ認証）
  1. 仕組み
  2. メリット

❌ 利用者ごとのサブディレクトリ構成の評価

この方法（/ito/, /suzuki/, /tanaka/）は、絶対におすすめできません。

1. 運用・保守の非効率性（致命的な問題）

項目	詳細
ファイルの重複	利用者が100人いると、`index.php`, `send.php`, `main.js`, `style.css`、そして全てのライブラリ（PHPMailer, TCPDF）を含むフォルダが100個作成されます。
更新の手間	契約書の内容やシステムにバグが見つかり、`send.php` や `main.js` を修正する場合、100個すべてのサブディレクトリに対して手動でアップロードし直す必要があります。
ディスク容量	冗長なライブラリファイルが大量にサーバーの容量を圧迫します。

2. ライブラリの絶対パス指定について

項目	詳細
技術的な可否	はい、可能です。PHPの `require` 関数内で、サーバー上のルートからの絶対パス（例: `/home/user_id/public_html/vendor/phpmailer/PHPMailer.php`）を指定できます。
推奨されない理由	環境依存性が高すぎます。サーバーのユーザーIDやファイルパスが変わるとすべて壊れます。また、ライブラリを共有するなら、シンボリックリンク（`ln -s`）などを使って共通ライブラリを参照させる方が、各ディレクトリにコピーするよりはマシですが、それでも管理が複雑です。

💡 推奨される代替案：一つのシステム、データで分岐

利用者ごとにURLを分けたいという要求は理解できますが、それはシステムレベルではなくデータと認証のレベルで実現すべきです。

これは、前回提案した『案2（データ駆動型アプローチ）』を導入することで解決します。

1. 静的リソースの共通化（必須）

すべてのユーザーが、同じ場所にあるファイルを参照するようにします。

契約システムURL: keiyaku.com/index.php
ライブラリパス: すべて keiyaku.com/vendor/ を参照。

2. 個別化されたURLの利用（データ認証）

利用者ごとに異なるURLを提供したい場合は、サブディレクトリではなくURLパラメータを使います。

仕組み

データベースに利用者レコードを作成し、それぞれに一意なトークン（Token）を付与します。
- 例: ユーザー鈴木 -> ?token=XYZ123
- 例: ユーザー田中 -> ?token=ABC789
利用者に送るURL:
- https://keiyaku.com/index.php?token=XYZ123
index.php の動作:
- PHPが $_GET['token'] (例: XYZ123) を受け取ります。
- サーバー側のPHP処理（認証/データ取得用）がデータベースに接続し、「トークン XYZ123 に紐づく利用者は鈴木様であり、プランはBで、料金は25,000円である」という情報を取得します。
- この情報を使って、契約書別紙の内容をその場で動的に生成し、HTMLに出力します。