BARAIRO LIFEをAIとCodexでゼロから再構築する

BARAIRO LIFEは、AIの情報を集めるだけのサイトではありません。AIとCodexを使い、会社以外の収益システムを実際に作り、かかった時間や費用、失敗、改善まで記録する実践メディアです。

働く時間を増やすための副業ではなく、働く時間を減らすための副業へ。

この記事は、最初の実験「LAB001：BARAIRO LIFEをAIとCodexでゼロから再構築する」の途中経過です。完成や収益化を装わず、2026年9月時点で実際に行ったことと残っている課題を整理します。

なぜBARAIRO LIFEを再構築したのか

旧サイトには投稿や固定ページがありましたが、検索流入や被リンクなどのSEO資産は限定的でした。古い構造を引き継ぐことより、誰のどんな課題を解決するかを決め直すほうが重要だと判断しました。

対象は、会社をすぐ辞めたいわけではないものの、会社だけに収入や人生を依存したくない45〜59歳前後の会社員です。副業でさらに忙しくなるのではなく、将来の拘束時間を減らせる仕組みを作ることを目標にしました。

• 旧記事本文は原則として再利用しない
• 記事本数やPVだけを成果にしない
• 利益、AI/API費用、人間の作業時間、自動化率を記録する
• 一般論ではなく、BARAIRO LABの実験結果を一次情報にする

AIとCodexをどう使ったか

最初に作ったのはWebページではなく、事業戦略、ペルソナ、サイト構造、コンテンツ計画、実験条件、計測、WordPress実装方針をまとめる設計リポジトリでした。判断の根拠をMarkdownとGitに残し、後からAIが読み直して同じ前提で作業できるようにしています。

工程	AI・Codexの役割	人間の役割
戦略・設計	情報整理、文書化、矛盾確認	対象読者、ブランド、優先順位の判断
WordPress実装	REST API、SSH、WP-CLIを使った調査と限定実装	認証情報の準備、購入・契約、変更範囲の承認
表示確認	stagingでPC・スマホ撮影、表示レビュー	公開可否とブランド表現の最終判断
計測	GA4イベント実装、通信確認、記録	必要イベントと達成条件の判断

実際に構築・確認したもの

WordPressとSWELL

WordPressテーマはSWELLを採用し、子テーマを有効化しました。トップページと「Start Here」を作成し、BARAIRO LIFEの考え方、5段階ロードマップ、BARAIRO LABへの入口を整理しました。

stagingとPlaywright

本番を直接試行錯誤の場にしないため、シンレンタルサーバーのサイトコピー機能でstaging環境を作りました。Basic認証で保護し、PlaywrightからPC幅1440pxとスマートフォン幅390pxの実画面を撮影して、崩れや導線を確認しています。

実際に使ったサーバー

BARAIRO LIFEの本番サイトとstaging環境には、シンレンタルサーバーを使用しています。今回の再構築では、SSH・WP-CLIによる診断、WordPressサイトコピー、stagingのBasic認証、WordPressとサイトマップの動作確認まで実際に行いました。

PR：以下はシンクラウドアフィリエイトの紹介リンクです。リンク経由の申込みが所定の条件を満たすと運営者に報酬が発生し、申込者に初回利用料金の割引が適用される場合があります。最新の料金・特典・適用条件は公式サイトで確認してください。

GA4とSearch Console

GA4では、HeroのCTA、BARAIRO LABへの導線、ページ末尾の次の一歩を区別する3イベントを実装しました。PC・スマートフォンでHTTP 204の送信を確認し、基本のpage_viewやタグが二重になっていないことも確認しています。Search Consoleでは既存の検索データを取得できる状態まで確認しました。

人間が行った作業とAIが行った作業

AIへ任せたのは、情報の整理、設計書の下書き、コード作成、WordPressへの限定的な反映、通信や表示の検証、差分の記録です。一方、事業の目的、誰に届けるか、どこまで自動化するか、費用をかけるか、本番へ反映するかは人間が判断しました。

認証情報やサーバー設定など、取り扱いを誤ると影響が大きいものも、人間が準備・承認する領域です。AIが作業を進めても、経営判断まで自動化したわけではありません。

失敗と修正の例

• REST API認証が401になった：Authorizationヘッダーの到達、Application Passwordの登録状態、保存値との一致を順に切り分け、正しい組み合わせで認証できることを確認しました。
• 下書きの実画面を自動確認できなかった：ブラウザー間でWordPressのログインCookieを共有できず、一時ページ方式ではナビに露出する問題も出ました。最終的にBasic認証付きstagingを作り、繰り返し撮影できる形にしました。
• ページ離脱時のGA4通信をPlaywrightで捕捉できなかった：通常の通信監視だけでは見えない送信をChromeの低レベル通信記録で確認し、実装を不必要に変更せずに済みました。
• サイトマップが正常なXMLなのに404になった：SWELL設定に加え、WordPress 7.1の既知不具合を切り分けました。7.1.1への更新後、コアサイトマップをHTTP 200へ復旧しました。

現時点で自動化できた範囲

• 設計文書とGit差分の作成・確認
• WordPress REST APIを使った下書き作成や本文更新
• SSHとWP-CLIを使った読み取り診断と限定的な設定反映
• 既存画像のアップロード・配置
• stagingでのPC・スマートフォン撮影
• GA4イベントの実装・重複確認・通信確認

ただし、記事企画から収益判断までが無人で回っているわけではありません。現段階は、AIが作業を担当し、人間が判断と承認を担う段階です。

残っている課題

• CONT013を本番公開し、正式なAffiliate導線が実環境で機能することを確認する
• Human Build TimeとHuman Maintenance Timeを継続記録する
• AI/API費用と追加費用を記録し、利益との関係を見られるようにする
• 初期コンテンツを公開し、記事からStart HereやBARAIRO LABへの導線を検証する
• 週次データからOwner Reportを生成し、継続・改善・中止を判断する

LAB001の次の実験

次は、この実践記録を本番公開候補として人間が確認し、シンレンタルサーバーの正式な紹介リンクを含む収益導線が実環境で機能するかを検証します。公開後もクリックと成果を分け、売上が発生していない段階で収益化に成功したとは判断しません。

---

実験ID：LAB001 ／ コンテンツID：CONT013。記事内のシンレンタルサーバーリンクは、実際に利用したサービスの正式なAffiliate導線です。利用事実と広告であることを分けて表示しています。