---
title: JAWS SONIC サブイベント 動体監視マラソンの裏側
tags:  #jaws-ug  
author: [Akifumi Niida](https://www.docswell.com/user/nid)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/G75Z5Z1PJ4.jpg?width=480
description: JAWS FESTA 2026 個サポLT 登壇資料
published: November 07, 26
canonical: https://www.docswell.com/s/nid/ZWRQ7D-2026-11-07-161850
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/G75Z5Z1PJ4.jpg)

サブイベント 動体
監視マラソンの裏側
マラソニ
JAWS SONIC
#


# Page. 2

![Page Image](https://bcdn.docswell.com/page/9J2RNR1Z7R.jpg)

自己紹介
新居田 晃史（にいだ あきふみ）
JBCC株式会社
カスタマーイノベーションラボ - Technical Expert
X @nid777 ・ Facebook Akifumi Niida
日本最速ITエンジニア — フルマラソン
2:29:56 2010-2020（※週刊BCN編集部調べ）
コミュニティ活動
JAWS DAYS 2025 実行委員長
AWS Samurai 2024
AWS Community Builder（Container）
AIコーディング道場
AWS認定
JAWS-UG 横浜支部
Cloudflare Meetup
ChatGPT Meetup Tokyo


# Page. 3

![Page Image](https://bcdn.docswell.com/page/DEYDPDZNEM.jpg)

開催のきっかけ
「テーマがマラソンだから、本当に走る企画をサブイベントでやりた
い。マラソンといえば新居田さんなので」
発端は、企画ができたときに実行委員長の加藤さんからSlackで受けた声かけ。真っ先に名前を挙げてもらえたことへの感謝と、その信頼
に応えたい気持ちが原動力。指名されたからには、走る側にも責任 — ここから裏側の話の始まり。


# Page. 4

![Page Image](https://bcdn.docswell.com/page/VJN6563VJ8.jpg)

本番は、9月の土曜14時スタート・約4時間の生配
信
1
ランナー5名、コースは非固定
2
ポイントを集めながら走る形式
3
最初の議論は、時間の決め方
4
あえて、一番暑い14時スタート
横浜・都内のチェックポイントを自由に選んで回る形式。みなとみらい経由は個人のコースの一例。
集めたポイントは、5人の合計制。
SONICは24時間のイベント。論点は、何時間走るか、何時に走るか。時期は9月初旬、35度も予想される暑さ。
一番暑い時間から始め、徐々に涼しくなる流れという意図的な選択。同時に、熱中症リスクが最も高い時間帯という前提で、ガードレー
ルを組み直す起点。


# Page. 5

![Page Image](https://bcdn.docswell.com/page/YE9LYL9V73.jpg)

本番の様子 — ゴールと、配信の裏側


# Page. 6

![Page Image](https://bcdn.docswell.com/page/GE8X6X94JD.jpg)

準備その1 — 6月、AWS Summit で実機テスト
本番に近い環境での事前テスト。動かして初めて見える
使いにくさの発見
汗をかき、ポーチに入れて走り、トイレに寄っても、位
置が取れるかの確認
カタログ通りにはいかないものも存在。実際に触れたこ
とによる、使う／使わないの判断
受け渡しの調整が最大の負担。大規模な本番環境の合間
を縫うこと自体、準備の一部
事前に潰した分、本番の不安は軽減。


# Page. 7

![Page Image](https://bcdn.docswell.com/page/LEL898WV7R.jpg)

準備その2 — 8月、皇居で耐久テスト
暑さの中での長時間走行と、ポイントの確認
停止時の暑さは一層の厳しさ
本番は14時スタート。条件の厳しさはさらに増大
感覚ではなく、閾値で止める方針の決定。


# Page. 8

![Page Image](https://bcdn.docswell.com/page/4JM6Z69NEW.jpg)

ポストモーテム→ガードレール設計
1
目的 — 何を守るかの決定
2
観測 — 守るものの状態把握
3
判断 — 閾値と判断者の事前決定
4
対処 — 止め方と逃げ道の用意
ランナーにSLAはなし。SLOは安全だけ。
対象は速さではなく、異常の兆候。
判断材料は暑さの閾値、判断者はマネージャー。
縮退運転とフェイルオーバーの、本番前の決定。
この判断と見守りを担うのが、マネージャー — 次のページで紹介


# Page. 9

![Page Image](https://bcdn.docswell.com/page/PJRP6PG4E9.jpg)

マネージャー — アクセルとブレーキ
マネージャー3名 — よしださん、MAXさん、ひろみさん
安全に倒しすぎれば、面白さの喪失。ブレーキだけでは
不十分
アクセル — 盛り上げ役という大きな役割。配信と現場の
熱量づくり
ブレーキ — 見守りと、止める判断の保持
走る人には兼務不可能なアクセルとブレーキを、一手に
担当
両役の両立こそ、思い切って走るための支え


# Page. 10

![Page Image](https://bcdn.docswell.com/page/PEX3M3XZJX.jpg)

ランナーにSLAはなし
唯一のSLOは、安全だけ
そもそも個人や速さを競わない企画。ポイントは5人の合計制、個人
に無理をして稼がせる構造なし。目標は「全員、無事に帰ること」
のみ。
守るものの決定が、監視設計の起点
見るのは記録ではなく、異常の兆候。
SLOが先、監視は後。逆の順序では、監視は「速く走らせるため」のものに変質。


# Page. 11

![Page Image](https://bcdn.docswell.com/page/3EKYGYWVJD.jpg)

監視設計 — 決めるべき軸と、この企画の答え
観測対象（何を見るか）
観測点（どこで見るか）
サンプリング間隔（どのくらいの頻度か）
欠測の扱い（止まったらどうするか）
本部は位置と暑さ。本人は時計で心拍・距離・ペースと体調の兆
候。
GPSは1分更新。WBGTは前日18時・当日10時・13時と、当日朝の作
戦会議で判定。
エスカレーション（誰が見て、誰に上げるか）
見るのは本部とマネージャー。連絡は電話番号交換による直接連
絡。緊急連絡先はスプレッドシートに集約。
本部はGPSの位置情報のみ。デバイスは各ランナー2台携行 — 冗長
構成。本人の時計は本人だけの確認用、本部への送信なし。
GPSの停止は異常扱い。
観測の副作用（何を見せないか）
ヘルスチェックの点呼は廃止。配信に乗る前提自体が、率直な申告
の妨げ。
電池は遠隔監視の対象外。持続可否は実機テストで確認し、電池切れはリタイア扱い。


# Page. 12

![Page Image](https://bcdn.docswell.com/page/L739N9WQ75.jpg)

止め方と逃げ道の事前決定
縮退運転 — 閾値による段階制
暑さに応じて、開始時刻の後ろ倒し、走行時間の短縮、中止を使い
分け。短縮は、終了時刻を固定してスタートを遅らせる方式。事前
決定により、現場で迷う余地なし。
「止まれる」という前提こそ、思い切って走る力の源泉。
フェイルオーバーも、正規の手段
ランナー個人の退避は、電車で戻る選択。企画全体では、代替コン
テンツへの切替。どちらも失敗ではなく想定内の対処で、連絡は電
話で直接。


# Page. 13

![Page Image](https://bcdn.docswell.com/page/87DGWGKW7G.jpg)

挑戦を可能にしたガードレ
ール
ガードレールは、挑戦を縛るものではなく、挑戦を可能にするも
の。安心して思い切って参加できたのも、ITで思い切ったチャレ
ンジができるのも、このガードレールのおかげ。
誘ってくださった加藤さんをはじめ、支えてくださった皆さんへ
の、心からの感謝。