M Hideki

スクレイピングや業務自動化の初期段階では、 「そもそもこのサイトをどう扱うべきか」という判断が曖昧なまま、 調査や実装が進んでしまうことが多くあります。 その判断を早い段階で行えるようにするため、 URLを入力するだけで ・サイトのステータス ・静的／動的の判定 ・主要DOMセレクタ を一括で取得・可視化するツールを設計・実装しました。 事前調査にかかる時間を数秒レベルに圧縮することで、 実装に入る前に 「このサイトは自動化対象にすべきか」 「どの手法を選ぶべきか」 といった設計判断を前倒しできるようにしています。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーー 技術選定を固定せず、運用前提で判断するスクレイピング設計 ーーーーーーーーーーーーーーーーーーーーーーーーーーーー スクレイピングや自動化案件では、 特定の言語やライブラリに寄せるのではなく、 対象サイトの構造や制約条件に応じて設計判断を行ってきました。 Python / Node.js の両軸で環境を構築し、 BeautifulSoup / Playwright / Puppeteer などを併用することで、 「取れるかどうか」ではなく 「運用し続けられるか」を基準に手法を選択しています。 この判断軸により、 短期的に動くだけの実装ではなく、 変更や障害を前提とした自動化設計を行ってきました。 ーーーーーーーーーーーーーーーーーーーーーーーーーー 仕様未確定でも進めるためのテスト・品質判断の仕組み化 ーーーーーーーーーーーーーーーーーーーーーーーーーー 仕様が固まりきっていない段階では、 品質判断が後回しになり、 結果として後戻りコストが膨らむケースが多くあります。 その状況を避けるため、 E2Eテスト・pytest・簡易的な負荷試験を 30〜60分単位で立ち上げる運用を確立しました。 完璧なテストを書くことよりも、 「どこまで壊してよいか」「どこから先は危険か」を 早い段階で可視化することを重視し、 判断材料としてのテストを活用してきました。 ーーーーーーーーーーーーーーーーーーーーーーーーー ChatGPTを前提にしつつ、判断を手放さない開発フロー ーーーーーーーーーーーーーーーーーーーーーーーーー ChatGPTは単なるコード生成ツールとしてではなく、 設計案の壁打ちや判断検証のパートナーとして活用しています。 一方で、AIの出力をそのまま採用することはせず、 誤りや前提のズレを指摘・修正しながら、 求める品質に揃える運用を徹底しています。 未知の言語やフレームワークであっても、 「何を信じ、何を疑うか」を判断しながら進めることで、 短期間で動くものを、判断付きで仕上げてきました。