ID:84371さん

## プロジェクト概要 愛知県の公共施設予約システム「ネットあいち」を対象に、テニスコートの抽選申込・予約情報の収集・空き状況の監視・参加者募集の掲載までを一気通貫で自動化したボットです。自分が運営するテニスの活動で、抽選申込と空き枠の確認を毎週手作業で繰り返していたのが開発の動機です。企画・設計・実装・テスト・本番運用・障害対応まで全工程を一人で担当し、現在も自宅PCのタスクスケジューラで毎時稼働しています。 - 言語・基盤：Python 3 / Poetry / SQLite / pytest - 外部連携：Google Sheets API、Discord Webhook、募集掲載サービス - 実行基盤：Windows タスクスケジューラ（毎時実行） ## チーム情報 個人開発（1名）。設計判断・実装・運用のすべてを自分が担当しました。レビューしてくれる相手がいないため、後述のとおり「誤りに自分で気づける／取り返せる」仕組みを意識的に作っています。 ## 開発・実装内容A：申込ルールのYAML外部化 【どのような機能の開発・実装か】 どのコートを、どの曜日・時間帯で、どの優先順位で抽選申込するかを宣言的に定義し、その通りに申込を自動実行する機能です。 【課題・問題点】 当初は申込条件をPythonコードに直書きしていました。しかし「今月は平日夜を優先する」「このコートは対象から外す」といった条件変更が毎月発生し、そのたびにロジックを編集してテストし直す必要がありました。条件を変えるだけでコードに触るのは、バグの混入経路としても運用の手間としても筋が悪いと判断しました。 【打ち手・使用した技術】 申込ルールを rules/lottery_rules.yaml に切り出し、グループ単位で条件を宣言する形に変更しました。コード側はYAMLを読んで解釈・実行するだけの責務に限定しています。同じ方針を空き状況チェック（availability_rules.yaml）と募集掲載（bear_rules.yaml）にも展開しました。 【成果】 運用中の条件変更が、コードを一切触らずYAMLの編集だけで完結するようになりました。ロジックとポリシーが分離され、条件変更に起因するデグレが発生しなくなりました。 ## 開発・実装内容B：不可逆な操作に対する安全弁（dry-run／確認モード） 【どのような機能の開発・実装か】 抽選申込・募集掲載といった「一度実行すると取り消せない操作」に対して、確定の直前まで実行して止める動作モードを各コマンドに用意しました。 【課題・問題点】 このボットが行うのは、公共施設への抽選申込と、他の人が参加する募集の公開掲載です。バグで誤った申込や誤った掲載をすると、自分だけでなく参加者にも影響が出るうえ、取り消しが効きません。個人開発でレビュー相手がいない以上、本番を汚さずに挙動を確認する手段が必要でした。 【打ち手・使用した技術】 --dry-run オプション（確認画面まで進むが確定ボタンを押さない）と、募集掲載側の submit: false 確認モード（フォーム入力まで実行して確定しない）を実装しました。ルールを変更したときは、まず確認モードで実行し、意図した対象・日時になっているかを目視してから本番実行する運用にしています。 【成果】 ルール変更のたびに安全に挙動を検証できるようになり、誤った申込・誤掲載を本番で発生させたことはありません。 ## 開発・実装内容C：本番運用で顕在化した障害への対処 【どのような機能の開発・実装か】 定期実行を長期間止めずに動かし続けるための、エラー耐性と多重実行防止の仕組みです。 【課題・問題点】 本番運用を始めてから、2つの障害が実際に起きました。ひとつは対象サイトが一時的に5xxを返し、その回の処理がまるごと失敗して抽選申込を取りこぼしたこと。もうひとつはスケジュール実行が遅延して日付をまたぎ、翌日分として同じ処理が二重に走ったことです。どちらもローカルで動かしている限り踏まない種類の不具合で、運用して初めて見えたものでした。 【打ち手・使用した技術】 前者には、外部リクエストに一時エラー限定のリトライ処理を実装しました（恒久的なエラーは握り潰さず即座に失敗させています）。後者には、実行日付を判定して日付をまたいだ場合は処理をスキップする制御を追加しました。あわせて掲載済みの枠を T_BearPost テーブルで管理し、二重掲載が構造的に起こらないようにしています。状態はSQLiteで永続化しています。 【成果】 以降、同種の障害は再発していません。「動くものを作る」ことと「動かし続ける」ことが別物だと、実際の障害と修正を通じて理解できました。 ## 開発・実装内容D：ドメイン制約の実装（予約枠の分割） 【どのような機能の開発・実装か】 確保した予約枠を、募集掲載サービス側の運用に合わせて自動変換して掲載する機能です。 【課題・問題点】 施設側では4時間連続でコートを確保できますが、募集は2時間単位のほうが実態に合います。手作業では毎回「4時間の予約を2枠に割り、それぞれ日時と申込期限を設定して掲載する」という、単純ですが間違えやすい作業が発生していました。 【打ち手・使用した技術】 4時間の予約を2時間×2枠のイベントへ自動分割して掲載する処理を実装しました。掲載には「過去イベントのコピー」機能を使い、同一コートの過去イベントを選んで日時（開始・終了・申込期限）だけを差し替える方式にしています。タイトル・説明・料金・キャンセル規定はコピー元から引き継がれるため、掲載内容に表記ゆれが生じません。 【成果】 掲載作業が自動化され、日時の設定ミスや記載内容のばらつきがなくなりました。

## プロジェクト概要 業務自動化の実務で繰り返し書いていた処理を、再利用可能なPython共通ライブラリとして設計・パッケージ化したものです。CSV・Excel・Salesforce連携・認証情報管理・ブラウザ操作などを一貫したインターフェースで提供します。単なるスニペット集にせず、コーディング規約・テスト・CI・ドキュメント・エラー対応手順まで含めた「配布して他人に使ってもらえる状態」を目標に整備しました。 - 言語・基盤：Python 3 / pytest / GitHub Actions（CI）/ Ruff / パッケージ化 - 主なモジュール：Config・Logger・credentials・CSV・Excel・Windows・Browser・Salesforce・PDF・utils ## チーム情報 個人開発（1名）。設計・実装・規約策定・ドキュメント作成をすべて自分が担当しました。利用者として自分以外の非エンジニアが使う場面を想定しており、以下の設計判断はその前提から出ています。 ## 開発・実装内容A：Excel操作におけるバックエンドの自動切り替え 【どのような機能の開発・実装か】 Excelファイルの読み書きを、ファイルの中身に応じて適切な実装で処理する抽象化レイヤです。 【課題・問題点】 Excel操作の定番であるopenpyxlは高速で扱いやすい一方、数式の再計算やマクロを含むファイルを正しく扱えません。かといって全ファイルをwin32com（Excel COM）で処理すると、Excelプロセスの起動が必要になり著しく遅く、環境依存も増えます。「このファイルはどちらで開くべきか」を利用者に判断させるのは現実的ではありませんでした。 【打ち手・使用した技術】 呼び出し側は ExcelFile という単一のインターフェースだけを使い、数式・マクロを含む場合はライブラリ内部で自動的にwin32comへ切り替える実装にしました。利用者はバックエンドの存在を意識しません。 【成果】 利用側のコードから条件分岐が消え、「速いが制約のある実装」と「遅いが万能な実装」の使い分けをライブラリ内部に閉じ込めることができました。 ## 開発・実装内容B：認証情報の安全な取り扱い 【どのような機能の開発・実装か】 業務ツールが使うパスワード・APIキー等を、平文でコードや設定ファイルに残さずに保存・取得する仕組みです。 【課題・問題点】 業務自動化ツールは外部システムへのログインを伴うため、認証情報の置き場所が必ず問題になります。実運用では設定ファイルに平文で書かれがちで、そのまま共有フォルダに置かれるリスクがありました。 【打ち手・使用した技術】 Windows DPAPI を用いた暗号化保存（credentials モジュール）を実装しました。復号は保存したユーザーアカウント上でのみ可能なため、ファイルが流出しても他の環境では復号できません。 【成果】 ツール側のコードに認証情報が一切現れない形に統一できました。 ## 開発・実装内容C：他人が使い続けられるための規約・ドキュメント整備 【どのような機能の開発・実装か】 ライブラリ本体ではなく、それを「自分以外が使い続けられる」状態にするための周辺整備です。 【課題・問題点】 自分だけが使うなら不要ですが、業務で他の担当者に渡すことを想定すると、エラーが出たときに自力で対処できなければ運用が止まります。また、選択肢を生の文字列で渡す設計はtypoに気づけず、非エンジニアには特に事故りやすいと考えました。 【打ち手・使用した技術】 - 選択肢を渡す引数には定数クラス（Color / SortBy / Encoding）を用意し、生の文字列を渡さない設計に統一 - エラーメッセージと対処法を対応させた ERRORS.md を作成し、各プロジェクトに配る雛形とした - コーディング規約（CONVENTIONS.md）を策定し、ライブラリ開発規約とプロジェクト規約を分けて整備 - そのまま動く examples（CSV→Excelレポート、突合転記、差分レポート、新規ツールの雛形）を同梱 - コードを読む人向けに、全体地図と読む順番を示すコードリーディングガイドを作成 - pytestによるテストとGitHub ActionsでのCIを整備 【成果】 新規ツールを作る際、examplesの雛形から着手して規約に沿って書けば動く状態になり、立ち上げの時間が短くなりました。テストとCIによって、ライブラリ本体に手を入れたときの影響範囲を検知できる状態を維持しています。 ## 開発・実装内容D：モジュール分割とインターフェースの統一 【どのような機能の開発・実装か】 Config・Logger・CSV・Excel・Windows・Browser・Salesforce・PDF・utils という単位でモジュールを分割し、それぞれの責務と使い方を揃えました。 【課題・問題点】 業務ツールは「CSVを読んでExcelに書く」「Salesforceから取得して突合する」といった組み合わせで成り立ちますが、都度書いていた頃はツールごとに書き方も例外処理もログ出力もバラバラで、他のツールに転用できませんでした。 【打ち手・使用した技術】 用途別にモジュールを切り、命名・例外設計・ログ出力の方針を統一しました。ログは日別ファイルとコンソールの両方に出す初期化をLoggerに集約し、設定はINIファイルからConfigで読む形に揃えています。 【成果】 複数の自作ツールから同じライブラリを再利用できるようになり、ツールごとに書き分けていた定型処理がなくなりました。

## プロジェクト概要 自分が運営するテニス事業のサイト（tennis-core.com）を、レンタルサーバー上のWordPressから Next.js の静的サイトへ全面移行し、本番のドメインを切り替えて運用まで持っていったプロジェクトです。企画・技術選定・実装・移行作業・DNS切り替え・旧環境の解約まで、一人で完了させました。現在も本番稼働しています。 - 技術：Next.js 16（App Router・静的エクスポート）/ Tailwind CSS v4 / framer-motion / TypeScript - インフラ：Vercel（本番ホスティング・独自ドメイン）、お名前.com（ドメイン管理） - 移行元：さくらインターネットのレンタルサーバー上のWordPress ## チーム情報 個人開発（1名）。技術選定から本番切り替えの判断まですべて自分が担当しました。稼働中の実サイトが対象なので、ダウンタイムとリンク切れを出さないことを最優先に進めました。 ## 開発・実装内容A：WordPressを廃止する技術選定 【どのような機能の開発・実装か】 既存のWordPressサイトを、ビルド済みHTMLを配信する静的サイトへ置き換えました。 【課題・問題点】 元のサイトはWordPressでしたが、更新するのは自分だけで更新頻度も低く、動的CMSである必要がありませんでした。それにもかかわらず、レンタルサーバーの月額費用、WordPress本体とプラグインの更新、それに伴う脆弱性対応といった保守コストが恒常的に発生していました。機能に対して運用コストが見合っていない状態でした。 【打ち手・使用した技術】 Next.js の App Router を静的エクスポート構成で採用し、Vercelの無料枠にホスティングする形へ移行しました。CMSは持たず、コンテンツはリポジトリ内で管理してGitの履歴で追える形にしています。 【成果】 レンタルサーバーを解約でき、ランニングコストとWordPressの保守作業をゼロにできました。表示速度も静的配信により改善しています。 ## 開発・実装内容B：既存URL構造の維持による移行 【どのような機能の開発・実装か】 旧サイトのURL構造を新サイトでも踏襲し、外部からのリンクと検索エンジンの評価を落とさずに移行しました。 【課題・問題点】 稼働中のサイトを別基盤へ移す場合、URLが変わると外部リンクが切れ、検索流入も失われます。一方で旧サイトには `/page-23/` のような、WordPressの自動採番に由来する意味のないURLも混在していました。 【打ち手・使用した技術】 `/singles/` `/junior/` `/private/` `/contact/` `/topics/` `/privacy-policy/` といった既存URLはそのまま維持し、意味のないURLだった特商法ページのみ `/legal/` へ変更する、という切り分けをしました。移行前に旧サイトの投稿を棚卸しし、記事が0件であることを確認したうえで、移行対象をページのみに確定させています。 【成果】 リンク切れを発生させずに移行を完了しました。旧構造をそのまま引き継ぐのではなく、残すURLと直すURLを判断して移行できました。 ## 開発・実装内容C：外部依存の断ち切り（問い合わせ導線の再構築） 【どのような機能の開発・実装か】 問い合わせ導線を、解約済みの外部サービス経由から公式LINEの直リンクへ差し替えました。 【課題・問題点】 旧サイトの問い合わせボタンは、当時利用していた外部の配信サービス（エルメ）経由のリンクでした。そのサービスを解約したため、放置すれば問い合わせ導線がそのまま死ぬ状態でした。移行時に必ず潰さなければならない不具合として扱いました。 【打ち手・使用した技術】 公式LINEへの直リンクに置き換え、外部サービスへの依存をなくしました。あわせて、流入元を計測できるパラメータ付きURLへの差し替えも検討課題として管理しています。 【成果】 サービス解約による導線の断絶を回避しました。移行作業を、単なる技術の置き換えではなく事業の導線を保つ作業として進められました。 ## 開発・実装内容D：DNS切り替えと旧環境の撤去 【どのような機能の開発・実装か】 本番ドメインをVercelへ向け、動作確認のうえで旧レンタルサーバーを解約しました。 【課題・問題点】 ドメインはお名前.comの管理、サイトはさくらのレンタルサーバー、移行先はVercelと、権限が3か所に分かれていました。切り替えの順序を間違えると本番サイトが落ちます。またサーバー解約はメール（MXレコード）にも影響するため、影響範囲の確認が必要でした。 【打ち手・使用した技術】 先にVercelへデプロイして apex（tennis-core.com）と www の両方をプロジェクトに登録し、その後お名前.com側でネームサーバーを Vercel のもの（ns1/ns2.vercel-dns.com）へ変更しました。切り替え後に本番URLの稼働を確認し、メールアドレスが実質未使用でMX消失の影響がないことを確認したうえで、最後にレンタルサーバーを解約しています。 【成果】 ダウンタイムなしで本番移行を完了し、旧環境を安全に撤去できました。作業順序と影響範囲を自分で設計して、後戻りできない切り替えを実行した経験です。