セッション間のデータ共有

第7版作成 2026/09/25 04:09最終更新 2026/10/05 00:46（日本時間）

確認バージョン1.5.8.1

/api/sessions の Sessions API を使うと、API 経由でセッションデータを読み書きできます。SavePerUser: true を指定すると、ブラウザのセッションではなくユーザー単位で保存されるため、別のセッション・別の端末・外部システムから同じ値を読み書きできます。

サーバースクリプトの context.UserData とは別物です

確認したソースでは、サーバースクリプトの context.UserData はリクエストごとに新しく作られるメモリ上のオブジェクトで（Context.cs）、Sessions テーブルとは結び付いていません。Sessions API で保存した値が読み込まれるのは Sessions API 自身のリクエストのときだけです（Context.cs L514-L517、L631-L633）。そのため、Sessions API で保存した値を context.UserData で読むことも、context.UserData に入れた値を Sessions API で読むこともできません。

エンドポイント

エンドポイント	メソッド	説明
/api/sessions/get	POST	セッション値を取得
/api/sessions/set	POST	セッション値を設定
/api/sessions/delete	POST	セッション値を削除

リクエストパラメータ

{
  "ApiKey": "your-api-key",
  "SessionKey": "キー名",
  "SessionValue": "値",
  "SavePerUser": true
}

パラメータ	型	必須	説明
ApiKey	string	Yes	API キー
SessionKey	string	Yes	セッションのキー名
SessionValue	string	Set のみ	保存する値
SavePerUser	bool	No	true: ユーザー単位で保存（デフォルト: false）

Set で SessionValue が空のときは 400 になります（SessionUtilities.cs）。

SavePerUser による保存先の違い

値	保存先	用途
false	ブラウザセッション（Cookie Pleasanter_SessionGuid の SessionGuid）	一時的なデータ
true	ユーザー単位（SessionGuid が @ユーザーID）	セッション間で共有するデータ

値は Sessions テーブルに、Key を User_{SessionKey} の形にして保存されます（SessionUtilities.cs、L365）。SavePerUser: true の行は、古いセッションを消す定期削除の対象外です（L441-L448）。SavePerUser: false は Cookie のセッションに結び付くため、Cookie を持たない API クライアントからはリクエストごとに別のセッションになり、後から取得できません。

保存期間

SavePerUser	消えるタイミング
false	最後に書いてから Session.json の RetentionPeriod（分、既定 1440 = 24 時間）を過ぎた行が、古いセッションの削除で消える
true	自動では消えない。/api/sessions/delete で消すまで残る

古いセッションの削除は、日付が変わってから最初の画面・API のリクエストの中で、Web サーバーのプロセスごとに 1 日 1 回だけ実行されます（SessionUtilities.cs#L434-L450）。期限を過ぎてもすぐには消えません。SavePerUser: true の値は使わなくなっても残り続けるので、不要になったキーは明示的に削除してください。RetentionPeriod は認証 Cookie の有効期限にも使われ、そちらは起動時に設定されるので、変えたときはアプリケーションを再起動します。

Redis をセッションストアにしている場合

Session.json の UseKeyValueStore が true のとき、Sessions API の Set は値を Sessions テーブルに書きますが、Get と Delete は Redis から読み込んだセッションデータを見るため、値が見つからず 404 になります（1.5.8.1 のソースで確認。詳しくは セッション管理の実装）。

context.UserData との違い

内部キーや保存範囲の全体像は Session に保存される情報と共有範囲 にまとめています。Sessions API の任意値は User_ 接頭辞を付けた領域で扱われ、認証チケットや編集中のサイト設定をそのまま取得する API ではありません。

項目	context.UserData（サーバースクリプト）	Sessions API（SavePerUser: true）
データの取得	context.UserData.Key	/api/sessions/get
データの設定	context.UserData.Key = value	/api/sessions/set
データの削除	delete context.UserData.Key	/api/sessions/delete
保存先	メモリ上（1 リクエストの間だけ）	Sessions テーブル（ユーザー単位で永続）
共有される範囲	同じリクエスト内で動くサーバースクリプトの間	同じユーザーの Sessions API 呼び出しの間
呼び出し元	サーバースクリプト内のみ	外部システム・ブラウザのスクリプト
データ型	任意	文字列（JSON 文字列で複合データ可）

使用例

設定（Set）

curl -X POST "https://your-pleasanter/api/sessions/set" \
  -H "Content-Type: application/json" \
  -d '{
    "ApiKey": "your-api-key",
    "SessionKey": "LastAccessTime",
    "SessionValue": "2026-02-24T10:30:00",
    "SavePerUser": true
  }'

レスポンス:

{
  "StatusCode": 200,
  "Response": {
    "UserId": 1,
    "Key": "LastAccessTime"
  }
}

取得（Get）

curl -X POST "https://your-pleasanter/api/sessions/get" \
  -H "Content-Type: application/json" \
  -d '{
    "ApiKey": "your-api-key",
    "SessionKey": "LastAccessTime",
    "SavePerUser": true
  }'

レスポンス:

{
  "StatusCode": 200,
  "Response": {
    "UserId": 1,
    "Key": "LastAccessTime",
    "Value": "2026-02-24T10:30:00"
  }
}

削除（Delete）

curl -X POST "https://your-pleasanter/api/sessions/delete" \
  -H "Content-Type: application/json" \
  -d '{
    "ApiKey": "your-api-key",
    "SessionKey": "LastAccessTime",
    "SavePerUser": true
  }'

レスポンス:

{
  "StatusCode": 200,
  "Response": {
    "UserId": 1,
    "Key": "LastAccessTime"
  }
}

サーバースクリプトとの連携

1.5.8.1 のソースには、API で設定した値をサーバースクリプトの context.UserData で参照する連携はありません（上の「context.UserData とは別物です」を参照）。サーバースクリプトには Sessions テーブルを読み書きする API もありません。

外部システムとサーバースクリプトの間で値を受け渡したい場合は、次のような方法を使います。

• 受け渡し用のテーブル（またはレコードの項目）に値を書き、サーバースクリプトからは items.Get などで読む
• どうしても Sessions API の値をサーバースクリプトで使う場合は、Sessions テーブル（SessionGuid が @ユーザーID、Key が User_キー名）を読む拡張 SQL を用意して extendedSql から呼ぶ（テーブル構造に依存するため、バージョンアップ時は確認が必要です）

活用シナリオ

SessionValue は文字列なので、複合データは JSON 文字列にして保存します。

シナリオ	SessionKey の例	SessionValue の例
外部システムから承認状態を設定し、ブラウザのスクリプトで参照	ApprovalStatus	{"approved": true, "approvedAt": "2026-02-24"}
バッチ処理の進捗を保存	BatchProgress	{"total": 100, "processed": 45}
ユーザーのカスタム設定を外部で管理	UserPreferences	{"theme": "dark", "pageSize": 50}

# 外部システムから承認状態を設定
curl -X POST "https://your-pleasanter/api/sessions/set" \
  -H "Content-Type: application/json" \
  -d '{
    "ApiKey": "...",
    "SessionKey": "ApprovalStatus",
    "SessionValue": "{\"approved\": true, \"approvedAt\": \"2026-02-24\"}",
    "SavePerUser": true
  }'

ステータスコード

本体実装（SessionsController / SessionUtilities）を確認すると、404 はエンドポイントが存在しない場合以外にも返されます。

API	条件	ステータス	備考
Get	指定キーが存在しない	404	未登録キー。初回アクセス時に発生しうる
Delete	指定キーが存在しない	404	すでに削除済みを含む
Get/Set/Delete	Content-Type が API 要件外	400	Security.json の MimeTypeCheckOnApi が true のとき（既定は false）。application/json で送る
Get/Set/Delete	JSON 不正 / SessionKey 欠落（Set は SessionValue 欠落も）	400	必須パラメータ不足
Get/Set/Delete	認証失敗（ApiKey 不正など）	401	リクエスト自体は到達している
Get/Set/Delete	IP 制限に抵触	403	AllowIpAddresses / 契約 IP 制限

WARNING

Get の 404 は「データ未登録」を意味することがあります。クライアント側では例外ではなく「未保存の初期状態」として扱うのが安全です。

関連ページ

• 同時アクセスが遅くなる理由（セッション・Redis）
• セッション管理の実装（Sessions テーブルと Redis）