ピンポジ+（ピンポジプラス）は紙・FAX運用と属人化が課題となっているゴルフ場のピン位置決定業務を、 配置ルールに基づく自動提案・PDF出力・メール送信で一貫してデジタル化する業務用Webアプリケーションです。
私は現在ゴルフ場でコース管理の仕事をしています。コース管理とは、ゴルフプレーヤーが快適にプレーできる環境を維持する仕事です。具体的には芝刈り、散水、施肥、剪定など多岐にわたります。その中にピン位置決定という業務があります。
ピン位置を決めるには、外周から4ヤード以上離す、過去2日間の位置から7ヤード以上離す、急傾斜や芝の傷みを避ける、9ホール全体のバランスを取る——といった複数のルールを頭の中で同時に処理する必要があります。
日々この業務をやりながら、「これってプログラムにやらせた方が正確で速いんじゃないか」「この時間を他の作業に回せるんじゃないか」と感じていました。
さらに現場では以下の課題も抱えていました。
- 判断基準が人によってバラバラ（属人化）
- 手書き → 清書 → FAX → 印刷という非効率なフロー（紙媒体）
- ピンの履歴や雨天禁止エリアなどの紙データが散在しており、一度に参照できない（データ散在）
- 芝の傷み箇所の認識が上司とスタッフ間で共有できていない（情報共有不足）
既存のツールも調べましたが、海外製で日本の現場には合わないものばかりでした。「無いなら自分で作ろう」と思い、独学でこのアプリの開発を始めました。
ゴルフ場のコース管理は、芝刈り・散水・施肥・カップ切り・バンカー均し・配管工事など多岐にわたります。 パッティンググリーンはコースの中で最も重要なエリアであり、その日のカップ位置（ピン位置）を毎朝決定する業務があります。
ピン位置を決めるには、複数のルールを同時に満たす必要があります。
- 外周から4yd以上離す
- 過去2日間のピン位置から7yd以上離す
- 急傾斜エリアを避ける
- 芝が傷んでいる箇所を避ける
- 9ホール全体で上段・中段・下段、左・中央・右のバランスを取る
これらを毎朝、頭の中で同時に処理しながら決めています。最終判断は人が行うべきですが、そこに至るまでの工程はプログラムの方が精度が高いと考えています。
| 課題 | 内容 |
|---|---|
| 属人化 | 人によって判断ロジックがバラバラ |
| 紙媒体 | 手書き → 清書 → FAXという運用 |
| データ散在 | 過去ピン・禁止エリア等がまとまっていない |
| 情報共有不足 | 傷み箇所の認識が上司とスタッフ間で共有できていない |
勤務していたゴルフ場の平均年齢は50歳（上は75歳）で、30代は自分一人でした。人手不足・高齢化が進む中、少ない人数でよりよい運用ができるようにしたいと考え、このアプリを開発しました。
- 属人化 → ルールをシステム化し、誰でも同じ判断ができる
- 紙媒体 → 手書き・FAXを廃止し、デジタルで完結
- データ散在 → 過去ピン・禁止エリア・傷み情報を一元管理
| 利用者 | デバイス | 利用場所 |
|---|---|---|
| 管理者（グリーンキーパー） | PC | コース管理事務所 |
| 作業スタッフ | タブレット | 現場（グリーン上） |
| マスター室 | PC | マスター室 |
- グリーン上でピン位置をメモ
- 事務所に帰って本番用紙に清書
- 上司が確認・紙の切り貼りによる修正
- FAXでマスター室へ送信
- マスター室の人が印刷
- プレイヤーやキャディーに配布
- 管理者が事務所のPCでピン位置を自動提案 → 確認・調整 → スタッフに公開
- スタッフがタブレットで確認・グリーンの状態に応じて微調整 → 管理者に完了報告
- 管理者が最終確認、再調整 → マスター室に自動メール送信
- マスター室の人がPDFで確認、印刷
- プレイヤーやキャディーに配布
入力から共有まで同一データで行い、再入力・伝達作業を削減します。
条件（雨天・難易度）を設定し、18ホール分のピン位置を一括自動提案します。提案後は個別に手動調整が可能です。
グリーン上のセルをタップして傷みエリア・禁止エリア・雨天禁止エリアを登録します。自動提案時にこれらのエリアを回避します。
ピン位置をPDFで確認し、マスター室にPDFのリンクを添えて自動メール送信します。
スタッフはタブレットを使い、グリーン上でピン位置（管理者が自動提案したもの）を確認・修正します。ホールごとのピン位置調整と、管理者への完了報告が可能です。
季節や大会などで早朝4時頃から暗い中で作業する場合があるため、ダークモードに対応しています。
| カテゴリ | 技術 |
|---|---|
| フロントエンド | Next.js 16 / TypeScript / React 19 |
| バックエンド | Supabase（BaaS）/ Next.js Route Handler |
| UI | Tailwind CSS v4 / shadcn/ui |
| グリーン描画 | react-konva |
| データベース | Supabase Postgres（RLS） |
| 認証 | Supabase Auth |
| ストレージ | Supabase Storage |
| メール送信 | Resend |
| テスト | Vitest |
| ホスティング | Vercel |
| CI/CD | GitHub Actions |
| PDF生成 | @react-pdf/renderer |
認証・データベース・ストレージを単一のサービスに集約し、フロントエンドと最小構成のサーバー処理だけで運用できる点を評価して採用しました。認可はアプリケーション層ではなくデータベース層のRLS（行レベルセキュリティ）に寄せ、設計をシンプルに保っています。
ユーザー作成（service_roleキーの利用）やメール送信など、秘密鍵を扱うためフロントエンドに置けない処理だけを薄いサーバー関数として実装しました。BaaS中心の構成でも、サーバー側でしか行えない処理を切り分けています。
グリーン形状・セル・制限エリアなどをレイヤーとして重ねて描画する必要があり、DOM/SVGよりもパフォーマンスと制御性に優れるCanvasベースのライブラリとして採用しました。
グリーン外周からの距離制限や禁止エリア生成において、ポリゴンのオフセット処理が必要となるため採用しました。
既存の紙フォーマットを再現する必要があり、Reactコンポーネントベースでレイアウトを構築できる点を評価して採用しました。
画面遷移なしで操作が完結する二画面構成を採用しました。コース全体を俯瞰しながらピン位置を検討できる、紙運用に近い操作感を実現しています。
精密な測量データに依存せず、傾斜情報を現場の作業者が手動入力できる設計とし、定期的な測量が必要となる導入障壁を解消しました。
広範囲の情報は曲線、局所的な情報はセルで表現するなど、情報の性質に応じて描画方法を使い分け、レイヤー重畳時の視認性を確保しました。
複数条件（過去の配置履歴・芝の傷み・傾斜など）で候補を絞る第1段階と、コース全体のバランス（難易度配分・奥行き分散）を考慮する第2段階に分けて実装しました。
開発中に使用した外部ライブラリ（clipper-lib）の型定義不足を発見し、TypeScript型定義の公開リポジトリ「DefinitelyTyped」へPull Requestを提出し、マージされました。
- PDFフォーマット複数対応（ゴルフ場ごとの差分吸収）
- キャディー携行用ポケットサイズ印刷フォーマット作成（現場での携帯性・視認性を考慮したレイアウト最適化）
- ピン・セル入力画面のズーム機能（操作性向上）
- 難易度パラメータ調整機能（既存ロジックの調整機能）
- 複数ゴルフ場対応（コースごとの設定切り替え）
- 9ホール / 27ホール / 36ホール対応（ホール構成の可変化）
- ツーグリーン対応（1ホール2グリーンの切り替え管理）
- 練習場パッティンググリーン対応
- MVP版は勤務しているゴルフ場の実際のマップを使用して作成しました。セキュリティのため、本リポジトリに含まれるマップデータはすべて架空のサンプルデータです。