📚 一覧 | 内見依頼書 | 物確bot(社員) | 物確bot(CLI) | カームFAX

業者間サイト照合ツール CLI運用マニュアル(管理者向け)

自分のMacのターミナルでゼロからセットアップして、CLIとして直接運用したい人向けの、めちゃくちゃ丁寧なマニュアル。ターミナルをほとんど触ったことがない人でも、このページの順番どおりに進めれば最後まで辿り着けるように書いてある。パソコン操作に慣れていない社員向けのもっと簡易なマニュアルは bukken-check-manual.htmlhttps://naiken.stand-up.tokyo/bukken-check-manual.html)。

所要時間の目安:全部で30〜45分ほど。パソコンの状態によって前後する。
安心してほしいこと:ここに書いてある操作でパソコンが壊れることはない。コマンドを打ち間違えても、消える・壊れるようなものではないので、焦らず一つずつ進めればよい。分からなくなったら一番下の「STEP 9 困ったときの対処」を見る。
目次
用語ミニ辞典

このマニュアルでよく出てくる言葉。分からなくなったらここに戻ってくればよい。

用語意味
リポジトリ(repository)プログラムのファイル一式を保存しておく「置き場」のこと。GitHub上に置いてある。
clone(クローン)リポジトリの中身をまるごと、自分のパソコンにコピーすること。
ターミナル文字を打ち込んでコマンド(命令)を実行するための画面。
コマンドターミナルに打ち込んで実行する命令文。1行が1つの命令。
ブランチ(branch)元のコードに影響を与えずに作業するための「作業用の複製」。
コミット(commit)ここまでの変更内容に区切りをつけて記録すること。
push(プッシュ)自分のパソコンで行った変更を、GitHub(インターネット上)に送ること。
pull(プル)GitHub上の最新の内容を、自分のパソコンに取り込むこと。
Pull Request(PR)「この変更を取り込んでください」とリポジトリの管理者に提案すること。
マージ(merge)Pull Requestの内容を、正式にリポジトリへ取り込むこと。
環境変数・.envID・パスワードなどの設定値を、プログラム本体とは別のファイル(.env)に置いておく仕組み。.envはGitHubには上げない。
CLI(シーエルアイ)Command Line Interfaceの略。画面のボタンではなく、文字のコマンドで操作するタイプのツールのこと。
STEP 1
1

事前準備(ターミナル・Python3・Homebrew・GitHub CLI)

1-1. ターミナルを開く

①これから使うコマンドはすべて「ターミナル」という画面に打ち込む。

  • ②操作:キーボードの⌘(コマンド)キーとスペースキーを同時に押す→画面上部に検索欄(Spotlight)が出る→「ターミナル」と入力してEnterキーを押す。
③黒っぽい(または白い)ウィンドウが開けば成功。これが「ターミナル」。以降のコマンドはすべてこの画面に打ち込む。

1-2. Python3が入っているか確認する

①このツールはPython3で書かれているため、Python3が使える状態か確認する。

python3 --version

③成功するとこう表示される

Python 3.11.6
「Python 3.」から始まるバージョンが何かしら表示されればOK。具体的な数字(3.9でも3.12でも)は環境によって違ってよい。
④よくあるエラー:zsh: command not found: python3 と出た場合はPython3が入っていない。STEP 1-3(Xcodeコマンドラインツール)を先に試すか、それでも入らない場合はSTEP 1-4のHomebrewを入れたあとにbrew install python3を実行する。

1-3. Xcodeコマンドラインツールを入れる(python3が無かった場合や、gitコマンドが無いと言われた場合)

①MacでPython3やgit等の開発ツールを使うための基本部品一式を入れる。

xcode-select --install

③実行すると起きること

「コマンドラインデベロッパツールがインストールされていません」というダイアログ(画面中央のポップアップ)が出る。「インストール」ボタンをクリックし、そのまま数分〜十数分待つ。インストールが終わったらダイアログが自動的に閉じる。
④よくあるエラー:「すでに最新のコマンドラインツールがインストールされています」と出た場合は、既に入っているのでこのステップは完了として次へ進んでよい。

1-4. Homebrewが入っているか確認する

①Homebrewは、Mac用の便利なインストールツール。次のSTEP 1-5で使うGitHub CLI(gh)を入れるのに使う。

brew --version

③成功するとこう表示される

Homebrew 4.3.0
zsh: command not found: brewと出た場合は、Homebrewをまだ入れていない。下のコマンドをコピーしてターミナルに貼り付け、Enterキーを押してインストールする(画面の指示に従ってパスワード入力やEnterキーを求められることがある)。
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
インストール完了後、ターミナルに表示される案内(「Next steps」)に沿ってPATHの設定コマンドを追加で求められることがある。表示されたコマンドをそのままコピペして実行し、その後もう一度ターミナルを開き直してからbrew --versionを試す。

1-5. GitHub CLI(gh)を入れる

ghはGitHubをターミナルから操作するための道具。STEP 2のログインや、STEP 8のPull Request作成で使う。

brew install gh

③成功するとこう表示される(末尾に近い部分)

==> Pouring gh--2.xx.x.sequoia.bottle.tar.gz
🍺  /opt/homebrew/Cellar/gh/2.xx.x: XXX files, XX.XMB
大量の文字がずらずらと流れるが、それは正常な動作。最後に🍺(ビールのマーク)と共にインストール完了の表示が出れば成功。
④よくあるエラー:ネットワークエラーで途中で止まった場合は、Wi-Fi接続を確認してからもう一度同じコマンドを実行する。
STEP 2
2

GitHubアカウントの準備

2-1. GitHubアカウントを作る(まだ持っていない人だけ)

  • ①ブラウザでhttps://github.com/を開く。
  • ②右上あたりの「Sign up」から、メールアドレス・パスワード・ユーザー名を決めて登録する(画面の案内に従う)。
  • ③登録できたら、自分のGitHubのユーザー名を鳥越に伝える。

2-2. 招待メールを承諾する

  • ①ユーザー名を伝えると、鳥越がGitHub上のdynasty420/bukken-checkリポジトリのSettings → Collaboratorsから自分をコラボレーター(共同作業者)として招待してくれる。
  • ②招待されると、登録したメールアドレス宛に「You've been invited to collaborate...」という件名のメールが届く。メールを開き、「Accept invitation」ボタンをクリックする。
これで自分のGitHubアカウントでdynasty420/bukken-checkにアクセスできるようになった。ここから先はdynasty420アカウントを使い回すのではなく、自分自身のアカウントで作業する。

2-3. ghでGitHubにログインする

①ターミナルから使うGitHub CLI(gh)を、自分のアカウントに認証させる。

gh auth login

③質問が1つずつ出るので、それぞれ選んでEnterキーを押す

画面の文言はghのバージョンによって多少違うことがあるが、だいたい次のような質問が順番に出る(矢印キーで選んでEnter)。
  1. 「Where do you use GitHub?」→ GitHub.com を選ぶ
  2. 「What is your preferred protocol for Git operations?」→ HTTPS を選ぶ
  3. 「Authenticate Git with your GitHub credentials?」→ Yes を選ぶ
  4. 「How would you like to authenticate GitHub CLI?」→ Login with a web browser を選ぶ

③そのあとに起きること

ターミナルに「First copy your one-time code: XXXX-XXXX」のような8桁のコードが表示され、「Press Enter to open github.com in your browser...」と出る。Enterキーを押すとブラウザが自動で開く。ブラウザに表示されたコード入力欄に、ターミナルに出ていたコードを貼り付け、「Authorize」ボタンを押す。ターミナルに戻ると自動的に続きが進む。

③最終的にこう表示されれば成功

✓ Authentication complete.
✓ Logged in as your-username

2-4. ログインできているか確認する

gh auth status
github.com
  ✓ Logged in to github.com as your-username (keyring)
  ✓ Git operations for github.com configured to use https protocol.
④よくあるエラー:「You are not logged into any GitHub hosts」と出た場合はログインできていない。もう一度gh auth loginからやり直す。
STEP 3
3

リポジトリを手元にコピーする(clone)〜必要なものを入れる

3-1. 作業する場所に移動する

①どこにコピーしてもよいが、迷ったら自分のホームフォルダ(/Users/自分のユーザー名)の直下にする。cdは「このフォルダに移動する」という意味のコマンド。

cd ~
~(チルダ)は自分のホームフォルダを表す記号。実行しても画面には何も表示されないが、それで正常(エラーが出なければ移動できている)。

3-2. リポジトリをコピーする(clone)

①プログラム一式を自分のパソコンにコピーする。

git clone https://github.com/dynasty420/bukken-check.git

③成功するとこう表示される(実際の数字は毎回変わる)

Cloning into 'bukken-check'...
remote: Enumerating objects: 250, done.
remote: Counting objects: 100% (250/250), done.
Receiving objects: 100% (250/250), 900.00 KiB | 2.50 MiB/s, done.
Resolving deltas: 100% (120/120), done.
④よくあるエラー:「remote: Repository not found.」と出た場合は、STEP 2のコラボレーター招待がまだ完了していないか、gh auth loginがうまくいっていない可能性がある。STEP 2に戻って確認する。

3-3. コピーしたフォルダに移動する

①これ以降のコマンドは、すべてこのbukken-checkフォルダの中で実行する。

cd bukken-check
⚠ 重要:ターミナルを開き直したとき、他の作業をしたあとにこのツールに戻ってきたときは、必ずcd ~/bukken-check(またはcloneした場所に応じたパス)をもう一度実行する。以降のSTEPのコマンドは、すべてこのあとに続けて実行する前提。

3-4. Playwright(プログラムが使う部品)を入れる

①このツールが実際にimportしている外部パッケージはplaywright(ブラウザを自動操作するための部品)のみ。requirements.txtは無いため直接インストールする。

pip3 install playwright

③実行すると起きること

大量の文字(ダウンロードの進捗)が流れるが正常。1〜2分ほどで「Successfully installed playwright-x.x.x」のような行が出て終わる(バージョン番号は毎回違ってよい)。
④よくあるエラー:「zsh: command not found: pip3」と出る場合はSTEP 1-2のPython3導入からやり直す。

3-5. ブラウザ本体(Chromium)を入れる

①検索・予約の自動操作は実際のブラウザ(Chromium=Google Chromeの元になっているブラウザ)を裏側で動かして行う。そのブラウザ本体をダウンロードする。

python3 -m playwright install chromium

③実行すると起きること

100MB前後のダウンロードが走るため、回線速度にもよるが数分かかることがある。進捗バーが表示されるのは正常。最後に「Chromium ... downloaded to ...」のような行が出れば完了。
④待っても全く進まない・エラーで止まる場合は、Wi-Fi接続を確認してからもう一度同じコマンドを実行する。

3-6. コードを変更するときの心構え(先出しの注意)

⚠ このあとSTEP 4以降で.envを設定したりツールを使ったりするが、プログラムのコード(.pyファイル)自体を直す場合は、STEP 8で説明する手順(作業ブランチ→Pull Request)を必ず使うこと。masterブランチへ直接pushしてはいけない。
STEP 4
4

.env を設定する(認証情報・担当者情報)

.envは、いえらぶBB・レインズのログイン情報や、内見予約時の担当者情報を書いておくファイル。プログラム本体とは別に管理する。

4-1. サンプルファイルをコピーする

cp .env.example .env
画面には何も表示されないが、それで正常。bukken-checkフォルダの中に.envという新しいファイルができている。

4-2. .envをエディタで開く

open -e .env
③実行するとMac標準の「テキストエディット」アプリが開き、.envの中身(キー名だけで値が空の状態)が表示される。

4-3. 各キーに値を入力する

開いたテキストエディットの中で、キー名=の右側に値を入力していく。以下は意味と記入例(記入例はダミーの値。実際の自分のID・パスワード・情報に置き換える)。

キー意味記入例(ダミー)
IELOVE_IDいえらぶBBのログインIDielove_user01
IELOVE_PASSWORDいえらぶBBのログインパスワードEx@mplePass123
REINS_IDレインズのユーザーIDreins_user01
REINS_PASSWORDレインズのパスワードEx@mplePass456
NAIKEN_AGENT_NAME内見予約(book.py)で使う案内担当者の名前鳥越雄太郎
NAIKEN_AGENT_TEL案内担当者の電話番号03-1234-5678
NAIKEN_AGENT_MAIL案内担当者のメールアドレスinfo@example.com
NAIKEN_CUSTOMER_TYPE顧客属性:個人 または 法人個人
NAIKEN_CUSTOMER_SEX顧客属性:男性 または 女性男性
NAIKEN_CUSTOMER_AGE顧客属性:年齢(数値)30
NAIKEN_CUSTOMER_NATIONALITY顧客属性:日本 または 外国籍日本
NAIKEN_CUSTOMER_JOB顧客属性:職種会社員
NAIKEN_NUMBER_OF_VISITOR内見の来場人数のデフォルト(--visitorsで上書き可)2
  • ITANDI BB・いい生活(es)はこのファイルを使わない。代わりにSTEP 5のlogin.pyでログインセッションを保存する。
  • いえらぶBB・レインズはログインセッションを保存できない仕組みのため、check.pyを実行するたびにここに書いたID/PASSWORDで自動ログインする。未入力・空のままだとlogin_required(要ログイン)という結果になる。
  • NAIKEN_*book.py(内見予約自動送信)専用。NAIKEN_AGENT_NAME/NAIKEN_AGENT_TEL/NAIKEN_AGENT_MAILのいずれかが空だと、book.pyはエラーで止まる。

4-4. 保存する

  • ①キーボードの⌘(コマンド)キーとSキーを同時に押す(上書き保存)。
  • ②テキストエディットのウィンドウを閉じる(左上の赤い丸ボタン)。

4-5. .envは絶対にGitHubに上げないことを確認する

.envには認証情報そのものが書かれている。絶対にcommit/pushしないこと。とはいえ、このリポジトリでは.gitignoreという仕組みで.envが最初から除外設定されているため、git add .のように一括で追加しようとしても.envは含まれない(誤って上げてしまう心配は基本的にない)。

③確認したい場合は、次のコマンドで.envが候補に出てこないことを見ておくと安心できる。

git status
出てくるファイル一覧に.envが含まれていなければ正常(含まれていたら、.gitignoreの設定を疑って作業を止め、鳥越に相談する)。
STEP 5
5

初回ログイン(login.py)

①ITANDI BB・いい生活(es)は、ログインした状態を「プロファイル」というフォルダに保存して使い回す方式。まず1回だけ、手動でログインしておく必要がある。

5-1. ITANDI BBにログインする

python3 login.py itandi

③実行すると起きること(時系列)

  1. Chromeベースのブラウザウィンドウが自動で開く(勝手に開くので驚かなくてよい)。
  2. ITANDI BBのログインページが表示される(表示されない場合はアドレスバーに手動で正しいURLを入力してよい)。
  3. いつも通り、自分のID・パスワードを入力してログインする(この入力はすべて自分の手で行う。自動では入力されない)。
  4. ログインできたことを画面で確認したら、そのブラウザウィンドウを✕(閉じるボタン)で閉じる。それだけでログイン状態がprofiles/itandi/というフォルダに自動保存され、ターミナルの表示が終了する。

③ターミナルの最後にこう表示される

[ITANDI BB] ログインセッションを保存しました: /Users/自分のユーザー名/bukken-check/profiles/itandi

5-2. いい生活(es)にログインする

python3 login.py es
5-1と同じ流れ。ブラウザが開く→自分でログイン→ウィンドウを閉じる、で完了。
いえらぶBB(ielove)・レインズ(reins)はlogin.pyを使わない。ログイン状態を保存できない仕組みのため、STEP 4で設定した.envの情報を使って、check.pyを実行するたびに自動でログインする。
④よくあるエラー:一度ログインしたのにcheck.py実行時にno_loginlogin_requiredと出続ける場合は、セッションが切れている可能性がある。もう一度このSTEPのlogin.pyを実行し直す(STEP 9も参照)。
STEP 6
6

物件を調べる(check.py)

6-1. まず1件だけ試してみる

①物件名を指定して、4サイト(ITANDI BB/いえらぶBB/いい生活/レインズ)+準備中のATBBまとめて掲載を調べる。

python3 check.py "グランドメゾン新宿"

③成功するとこう表示される(イメージ例)

物件名: グランドメゾン新宿
  [ITANDI BB] 掲載あり -
    - グランドメゾン新宿 305号室 | 12.0万円 | ○○不動産 | FAX 03-1234-5678
  [いえらぶBB] 掲載なし -
  [いい生活(いい生活Square)] 未ログイン - ログインセッションがありません。先に python3 login.py es を実行してください
  [レインズ] ⚠ 要再ログイン - .envにREINS_ID/REINS_PASSWORDを設定してください(README参照)
サイトごとに1行ずつ結果が出る。「掲載あり」の行には、建物名・部屋番号・賃料・元付/管理会社(分かればFAXも)が追加で表示される。
④よくあるエラー:未ログインと出たらSTEP 5のログインをやり直す。要再ログイン.envに...を設定してください)と出たらSTEP 4の.envの値を見直す。

6-2. 号室まで指定する

python3 check.py "グランドメゾン新宿" --room 201
--roomのあとに号室を書くと、その部屋だけに絞って調べる。

6-3. 特定のサイトだけ調べる

python3 check.py "グランドメゾン新宿" --site itandi,ielove
サイト名はitandi / ielove / es(いい生活) / reins(レインズ) / atbb(ATBB・準備中)から、カンマ区切りで必要な分だけ指定する。--siteを省略すると4サイト+ATBBすべてを調べる。

6-4. レインズで都道府県を指定する

python3 check.py "グランドメゾン新宿" --site reins --pref 神奈川県
--prefを省略すると「東京都」で検索される。レインズ以外のサイトでは無視される。

6-5. 結果をJSON形式で受け取る(他のプログラムに読み込ませたいときなど)

python3 check.py "グランドメゾン新宿" --json
機械可読な{"bukken": ..., "room": ..., "results": [...]}形式のJSONが出力される。

6-6. 複数の物件をまとめて調べる(バッチモード・その1:直接並べる)

python3 check.py "物件A" "物件B" "物件C"
物件名をスペース区切りで並べるだけで、まとめて調べられる(1件だけの場合と表示形式は変わらない。2件以上を指定すると自動的にバッチモードになる)。

6-7. 複数の物件をまとめて調べる(バッチモード・その2:ファイルで渡す)

①物件名を1行1件で書いたテキストファイル(例:list.txt)を用意する。行の先頭に「1.」「2.」「③」のような番号が付いていても自動で取り除かれるので、そのままでよい。

1.レインボーハイツ
2. サンシャイン新宿
③ グリーンヒルズ渋谷
このファイルをlist.txtという名前でbukken-checkフォルダに保存する(open -e list.txtで新規作成・編集できる)。list.txt.gitignore対象なので、実際の物件名を書いてもGitHubには上がらない。
python3 check.py --file list.txt

③成功するとこう表示される(末尾のサマリー表、README記載の例)

=== サマリー ===
物件名              ITANDI BB  いえらぶBB  いい生活(いい生活Square)  レインズ
------------------  ---------  ----------  --------------------------  --------
レインボーハイツ    ○          ×           ○                          要ログイン
サンシャイン新宿    ×          ×           ×                          ×
物件ごとの結果が1件ずつ表示されたあと、最後にこのサマリー表がまとめて出る。=掲載あり、×=掲載なし、「要ログイン」=ログインし直しが必要、「エラー」=失敗。
⚠ まとめて調べられるからといって、何十件も一度に流し込まないこと。サイトに負荷をかけたり、アカウントが止められたりするおそれがあるため、数件〜十数件程度の常識的な範囲にとどめる。

結果ステータスの読み方(早見表)

表示意味
掲載あり(found掲載あり。建物名・部屋番号・賃料・元付/管理会社などが表示される。
掲載なし(not_found掲載なし。
未ログイン(no_loginITANDI BB・いい生活で、まだlogin.pyを実行していない状態。STEP 5を行う。
要再ログイン(login_requiredセッション切れ、または.env未設定。STEP 4・5を見直す。
準備中(preparingATBBのみ。アダプタ未実装のための正常表示。
エラー(error失敗。もう一度同じコマンドを実行してみて、それでも直らなければSTEP 9へ。
実行のたびにlogs/checks.jsonlへ自動で記録が残るので、自分でメモを取る必要はない。
STEP 7
7

内見予約を自動送信する(book.py)

①ITANDI BB/いえらぶBBのオンライン内見予約フォームへの入力・送信を自動化できる。いい生活(es)・レインズはオンライン内見予約の仕組みが無いため対象外(従来どおりviewing-faxでのFAX送付ルートを使う)。

⚠⚠ 最重要の注意 ⚠⚠
  • 実際の送信(--dry-run無しでの実行)は、まだ動作未検証。これまで確認できているのは、確認画面まで到達する--dry-runの動作のみ。
  • --dry-runを付けない場合、デフォルトでユーザー確認なしに送信まで完全自動実行される(途中で止まらない)。
  • 動作確認・練習は必ず--dry-run付きで行うこと。本番で実送信するときは、事前に鳥越に確認を取ってから行うこと。自己判断で実送信しないこと。

7-1. まずはお試し(dry-run)で確認する

--room--datetimeは必須。日時は"YYYY-MM-DD HH:MM"の形式。

python3 book.py "グランドメゾン新宿" --room 201 --datetime "2026-07-20 14:00" --dry-run

③成功するとこう表示される(イメージ例)

物件名: グランドメゾン新宿 / 部屋: 201 / 日時: 2026-07-20 14:00
  [ITANDI BB] 確認画面まで到達(未送信・dry-run) -
    確認画面スクショ: /Users/自分のユーザー名/bukken-check/logs/naiken_book_20260717_143000_itandi_before.png
--dry-run付きなら、確認画面まで進んだところで止まり、実際の送信はされない。確認画面のスクリーンショットが自動で保存される。
④よくあるエラー:「物件が見つかりません」「物件を一意に特定できません」と出た場合は、物件名・号室の表記がサイト側の表記と違っている可能性がある。check.py(STEP 6)で正確な建物名を確認してから試す。

7-2. 主なオプション

オプション意味
--site itandi特定のサイトだけ試す(省略時はITANDI BB→いえらぶBBの順に試し、最初に到達できたサイトで止まる=二重予約防止)。
--duration 60内見時間(分)。30/60/90から選択(ITANDI BBのみ有効、デフォルト30)。
--json結果をJSON形式で出力する。
--visitors 2来場人数(省略時は.envNAIKEN_NUMBER_OF_VISITOR)。
--customer-type / --customer-sex / --customer-age / --customer-nationality / --customer-job顧客属性を案件ごとに上書き(省略時は.envNAIKEN_*)。

7-3. 実際に送信する(鳥越の確認後のみ)

python3 book.py "グランドメゾン新宿" --room 201 --datetime "2026-07-20 14:00"
--dry-runを付けずに実行すると、ユーザーへの確認なしでそのまま送信まで自動実行される。物件名・号室・日時に打ち間違いがないか、実行前によく見直すこと。

7-4. 送信結果とログの確認

表示意味
確認画面まで到達(未送信・dry-run)--dry-run時。まだ送信されていない。
予約送信完了送信が完了したと画面から判定できた。
送信失敗送信できなかったと画面から判定できた。
要手動確認成功・失敗を自動判定できなかった。下記スクショを目視で確認する。
予約不可(ボタン無効)そのサイトでは予約ボタンが押せない状態。次のサイトへ自動的に切り替わる。
  • 送信直前・直後のスクリーンショットがlogs/naiken_book_<日時>_<site>_before.png / _after.pngに保存される(--dry-run時は_beforeのみ)。
  • すべての実行結果はlogs/naiken_book.jsonlに自動で記録される。自分でメモを取る必要はない。
  • 「要手動確認」が出たら、上記フォルダのスクリーンショットを開いて、実際に送信できていたかを目で確認する。判断に迷ったら鳥越に相談する。

既知の制約

  • ITANDI BBの内見予約フォームは、フォーム読み込み時点から概ね1週間先までの日時しかカレンダーに表示されない。それより先の日時を指定すると「指定日時の内見枠が見つかりませんでした」エラーになる。
  • ITANDI BBの案内担当者選択は名前で検索して最初の候補をクリックする方式のため、同姓同名の担当者が複数登録されていると誤選択の可能性がある。
  • いえらぶBBの職種(NAIKEN_CUSTOMER_JOB)は選択肢に「会社員」が無いため、最も近い「正社員」に自動的に読み替えられる。
STEP 8
8

コードを変更するとき(Pull Requestを送る)

masterブランチへの直接pushは禁止。コードを直す・機能を追加するときは、必ず作業ブランチ(=作業用の複製)を切ってPull Request(=変更の提案)を送る。ここではブラウザ(GUI)中心の手順を説明する。

8-1. 作業ブランチを作る

fix-xxxxxx部分は、内容が分かる名前に変える(例:fix-reins-selector)。

git checkout -b fix-xxx
Switched to a new branch 'fix-xxx'

8-2. コードを直す

①自分の使い慣れたエディタ(VSCodeなど)やopen -eで、直したいファイル(例:sites/reins.pyなどsites/フォルダ内の該当ファイル)を開いて編集し、保存する。

8-3. 変更内容を確認する

git status
③赤字で変更したファイル名が一覧表示される。これから記録するのがどのファイルか確認する。

8-4. 変更をステージする(記録の準備)

<ファイル名>の部分は、実際に変更したファイル名に置き換える(例:sites/reins.py)。

git add <ファイル名>

8-5. コミットする(変更内容を記録する)

git commit -m "変更内容が分かる一言"
[fix-xxx 1a2b3c4] 変更内容が分かる一言
 1 file changed, 3 insertions(+), 1 deletion(-)

8-6. 自分のブランチをGitHubに送る(push)

git push -u origin fix-xxx

③成功するとこう表示される(イメージ例)

...
remote: Create a pull request for 'fix-xxx' on GitHub by visiting:
remote:      https://github.com/dynasty420/bukken-check/pull/new/fix-xxx
...
 * [new branch]      fix-xxx -> fix-xxx

8-7. GitHub上でPull Requestを作る(ブラウザ操作)

  • ①ブラウザでhttps://github.com/dynasty420/bukken-checkを開く。
  • ②ページ上部に黄色い帯が出て、「fix-xxx had recent pushes」のような文言と一緒に「Compare & pull request」というボタンが表示されるのでクリックする(表示されない場合は、上記8-6の出力に表示されたURLを直接開いてもよい)。

③タイトル・説明を書く

タイトル欄には変更内容が分かる一言を書く(例:「レインズの検索結果セレクタを修正」)。説明欄には、何を・なぜ変えたかを簡単に書く。書けたら緑色の「Create pull request」ボタンをクリックする。
これでPull Requestが送られた状態になる。あとは鳥越のレビュー・マージを待つ。

8-8. マージされたら、自分の手元を最新化する

git checkout master
git pull
これで自分のmasterブランチにも、マージされた最新の変更が反映される。

(慣れた人向け)ghコマンドでPull Requestを作る方法

GUIでの操作(8-7)の代わりに、ターミナルから直接PRを作ることもできる。

gh pr create
タイトル・説明を対話形式で聞かれるので入力する。作成されるとPRのURLが表示される。

補足:秘密情報はPRに含まれない

.envprofiles/logs/dumps/list.txt.gitignore対象のため、通常のcommit・PRには含まれない。認証情報や実際の物件名がPRを通じて外部に見えてしまう心配はない。
STEP 9
9

困ったときの対処

症状対処
赤い英語がいっぱい出た(エラーが出た) あわてなくて大丈夫。もう一度、同じコマンドを打ち直してみる。それでも同じ症状が出るなら、下の「最終手段」を試す。
何も起きない・反応がない 少しの間(数十秒〜1分程度)そのまま待ってみる。特にいい生活(es)は仕組み上、最大60秒ほど待つことがあり、それは正常な動作。それでも変わらなければEnterキーをもう一度押してみる。
itandi / esでno_login / login_required STEP 5のpython3 login.py itandi(またはes)でログインし直す。profiles/<site>/のプロファイルが壊れている疑いがあれば、そのフォルダの中身を削除してから再ログインする。
ielove / reinsでlogin_required STEP 4の.envを開き直し、IELOVE_ID/IELOVE_PASSWORDREINS_ID/REINS_PASSWORDが正しく入力されているか確認する(値が空・キー名の打ち間違いがあると常にこの状態になる)。
サイト側の画面変更でセレクタが壊れた(errorで「セレクタ要再調査」と出る)

調査用コマンドを実行する。

python3 inspect_site.py reins

headedブラウザが開くので、目的の検索ページまで手動で操作し、ターミナルに戻ってEnterキーを押す。その時点のHTML・スクリーンショットがdumps/フォルダに保存される。ここから先はコードの修正(sites/<サイト名>.py)が必要になるため、STEP 8の手順でPull Requestを作るか、鳥越に相談する。

book.pyで要手動確認と表示される 自動では成功・失敗を判定できなかったという意味。logsフォルダのスクリーンショット(送信直前・直後)を確認する。判断に迷ったら自分で決めず鳥越に相談する。
結果がおかしい・いつもと様子が違う 自分で無理に直そうとせず、下の「最終手段」を試す。
最終手段:ターミナルに表示された赤いエラー文を、そのままコピー(マウスでドラッグして選択し⌘+C)して、鳥越(またはClaude)に貼り付けて聞く。エラー文をそのまま貼るだけで、大体の場合は解決できる。自分で無理に推測して直そうとしなくてよい。
⚠ レインズは指定流通機構の会員専用システムのため、利用規約上の制約が特に厳しい。あくまで自分の会員資格の範囲内での「手動操作の代行」にとどめ、低頻度・少件数での利用を徹底すること。規約に抵触する可能性がないか、利用前に必ず自分でレインズの利用規約を確認すること。
各業者間サイトの利用規約上、自動アクセスは自己責任で行うこと。UA偽装や検出回避の類は一切行わない方針。プログラム内のページ遷移の間のwait(time.sleep())を勝手に削除しないこと。