AI一人会社のBuilding in Public — 開業準備から初月までの全記録
はじめに
「Building in Public」— プロダクトやビジネスを作る過程をリアルタイムで公開するスタイルです。
一人会社を立ち上げ、AIを活用しながら4つのプロジェクトを同時に回し始めました。この記事では、開業準備から初月までの意思決定と実際の作業を、できる限りそのまま記録します。
うまくいったことだけでなく、失敗や想定外の出来事も含めて書きます。同じように一人で何かを始めようとしている人の参考になれば幸いです。
なぜ Building in Public を選んだか
理由 1: 透明性が信頼を生む
FX自動売買Botの運用実績を公開するプロジェクトを計画していました。バックテストの結果だけを見せるのではなく、リアルタイムの損益を公開することで信頼性を確保したい。であれば、サイト全体の運営方針も透明にするのが一貫性のある姿勢だと考えました。
理由 2: 自分へのプレッシャー
一人で作業していると、サボっても誰にも気づかれません。公開で進捗を記録すれば、良い意味でのプレッシャーになります。
理由 3: コンテンツになる
Building in Publicの記録は、そのままブログのコンテンツになります。一石二鳥です。
立ち上げた 4 プロジェクト
一人会社で同時に立ち上げたプロジェクトは以下の4つです。
| プロジェクト | 内容 | 技術スタック |
|---|---|---|
| FX 自動売買 Bot | GMOコインで24時間自動取引 | Python / Docker / Oracle Cloud |
| ブログ (uselect.jp) | アフィリエイト + コンテンツサイト | Astro 6 / Tailwind CSS v4 / Cloudflare Pages |
| SNS 自動運用 | X投稿 + note記事の配信 | FastAPI / Cloud Run / Firestore |
| 投資分析ダッシュボード | 市場データの可視化 | Python / GCS |
「4つは多すぎないか?」と思うかもしれません。正直、多いです。ただし、AIコーディングアシスタント(Claude Code)を活用することで、一人でも複数プロジェクトを並行して進められるという仮説を検証したかったのです。
ドメイン取得とサーバー構築の選択
ドメイン: uselect.jp
ドメインは お名前.com で取得しました。
選んだ理由:
.jpは日本語コンテンツとの相性が良い- 短くて覚えやすい
- 「u + select」= 自分の選択を記録する、というコンセプトに合致
ホスティング: Cloudflare Pages
ブログのホスティングは Cloudflare Pages を選びました。
| 比較項目 | Cloudflare Pages | Vercel | Netlify |
|---|---|---|---|
| 無料枠 | 500ビルド/月 | 100GBデータ転送/月 | 300分ビルド/月 |
| 帯域 | 無制限 | 100GB/月 | 100GB/月 |
| エッジ配信 | 全世界200+拠点 | 全世界 | CDN |
| カスタムドメイン | 無料 | 無料 | 無料 |
決め手は 帯域無制限 と 無料枠の広さ です。個人ブログなら当面は無料枠を超えることはないですが、将来的にアクセスが増えても安心できる余裕があります。
Bot サーバー: Oracle Cloud Always Free
FX Botを24時間動かすサーバーは Oracle Cloud の Always Free を選びました。ARM 4 OCPU / 24 GB メモリが永久無料という破格のスペックです。
月額コスト: 0円
VPSを借りると月額1,000〜3,000円かかるところを、完全無料で運用できています。
詳しい構築手順は Oracle Cloud無料枠を最大限活用する方法 にまとめています。
レンタルサーバーを選ばなかった理由
一般的なブログならレンタルサーバー + WordPress が定番ですが、エンジニアとして以下の理由で静的サイト生成を選びました。
- 表示速度: 静的HTMLはサーバーサイド処理がないので圧倒的に速い
- コスト: Cloudflare Pages は無料、レンタルサーバーは月額1,000円前後
- セキュリティ: 動的なサーバーがないので攻撃面が極めて小さい
- 自由度: Astroなら好きなデザインをコンポーネントで組める
ただし、これはエンジニアだから選べる選択肢です。プログラミングの知識がない場合は、レンタルサーバー + WordPress のほうが圧倒的に始めやすいです。
レンタルサーバーを選ぶ場合は、エックスサーバーが安定性と速度のバランスが良く、WordPress との相性も抜群です。
技術選定の記録
フレームワーク: Astro 6
静的サイト生成のフレームワークとして Astro を選びました。
| 評価軸 | Astro | Next.js | Hugo |
|---|---|---|---|
| JS バンドルサイズ | 0 KB(デフォルト) | React ランタイム必須 | 0 KB |
| コンテンツ管理 | Content Collections | 自前実装 | 組み込み |
| 学習コスト | 低 | 中〜高 | 低 |
| コンポーネント | .astro + React/Vue 併用可 | React 必須 | Go テンプレート |
ブログはインタラクティブ性が低いので、クライアントにJSを送る必要がありません。Astroの「デフォルトでJS 0KB」は、パフォーマンス重視のブログに最適です。
スタイリング: Tailwind CSS v4
CSS フレームワークは Tailwind CSS v4 を採用。v4 からは @theme ディレクティブでデザイントークンを定義できるようになり、CSS Custom Properties との統合がスムーズです。
CI/CD: GitHub Actions
デプロイは GitHub Actions で自動化しています。main ブランチにマージすると、自動でビルド → Cloudflare Pages にデプロイされます。
AIツール: Claude Code
全プロジェクトの開発に Claude Code を活用しています。各プロジェクトのルートに CLAUDE.md を置くことで、プロジェクト固有のルールやコンテキストを Claude Code に伝えています。
Claude Code の活用法は Claude Code活用術 — 一人会社の全プロジェクトをAIで回す方法 にまとめました。
4プロジェクト同時立ち上げの実態
何を同時進行したか
初月の作業は大きく分けて以下の通りです。
インフラ構築(全プロジェクト共通):
- Oracle Cloud インスタンスの作成と初期設定
- Docker環境の構築
- Cloudflare Pages のセットアップ
- ドメインの DNS 設定
- GitHub リポジトリの作成と CI/CD 構築
FX Bot:
- Bot本体の開発(Python)
- GMOコイン API との接続
- Docker Compose による運用環境構築
- 死活監視の実装
ブログ (uselect.jp):
- Astro プロジェクトの初期構築
- デザインシステムの設計(トークン定義、コンポーネント設計)
- 初期記事の執筆
- サムネイル自動生成スクリプトの作成
- SEO 対策(メタタグ、サイトマップ、構造化データ)
- Google Search Console / Analytics の設定
SNS運用:
- X アカウントの設計
- コンテンツ配信の自動化
投資分析:
- 市場データの収集パイプライン構築
時間配分の推移
初月の時間配分は以下のように推移しました。
第1週: インフラ重視
- インフラ構築: 60%
- Bot開発: 30%
- ブログ: 10%
第2-3週: ブログ + Bot
- ブログ記事執筆: 40%
- Bot調整: 30%
- SNS設定: 20%
- その他: 10%
第4週: コンテンツ拡充
- ブログ記事執筆: 60%
- SNS運用: 20%
- Bot監視: 10%
- 分析: 10%
初月の KPI 設定
なぜ KPI を設定するか
目標がないと「何となく忙しいけど進んでいない」状態に陥ります。小さくても定量的な目標を設定し、毎週確認することが重要です。
設定した KPI
| 指標 | 目標 | 意図 |
|---|---|---|
| 公開記事数 | 10本 | 検索流入の基盤を作る |
| Google Search Console 登録 | 完了 | インデックスの前提 |
| Bot 24時間稼働 | 達成 | 自動売買の基盤 |
| X フォロワー | 計測開始 | SNS チャネルの起点 |
初月は収益をKPIにしませんでした。ブログもBotも、成果が出るまでに時間がかかるため、初月は 「基盤構築を完了する」 ことに集中しました。
直面した失敗と学び
失敗 1: 記事の品質管理
初期に書いた記事の一部で、AIが生成した内容のファクトチェックが不十分だったことが発覚しました。
学び: AIはツールであり、最終的なファクトチェックは人間が行う必要がある。特に数値や期間に関する表現は、必ずデータソースと照合するルールを導入しました。
この経験から、全記事の公開前にCEOがファクトチェックを行うプロセスを確立しました。
失敗 2: 完璧主義に時間を取られた
デザインシステムの構築に想定以上の時間を費やしました。色のトークン定義、スペーシングルール、コンポーネントの設計 — 一つ一つは正しい判断でしたが、初期段階ではもう少し簡素でも良かったかもしれません。
学び: 「最初から完璧」を目指すと、いつまでも公開できない。80%の品質でリリースして、フィードバックを受けて改善するほうが結果的に速い。
失敗 3: 4プロジェクトのコンテキストスイッチ
4つのプロジェクトを同日に切り替えると、コンテキストスイッチのコストが大きいことがわかりました。
学び: 「今日はBotの日」「今日はブログの日」と、日単位でフォーカスするプロジェクトを固定するほうが効率的です。
コスト構造
初月の月額コスト
| 項目 | コスト | 備考 |
|---|---|---|
| ドメイン (uselect.jp) | 約125円/月 | 年額を月割 |
| Cloudflare Pages | 0円 | 無料枠内 |
| Oracle Cloud | 0円 | Always Free |
| GitHub | 0円 | 無料プラン |
| Claude Code | 利用料 | AI開発ツール |
| GCP | 0円 | 無料トライアル期間 |
インフラコストはドメイン代のみという構造です。エンジニアが自分で構築する前提ですが、無料ツールと無料枠を最大限活用すれば、驚くほど低コストでビジネスの基盤を作れます。
これから
初月は「基盤構築」がメインでした。2ヶ月目以降は以下にフォーカスしていきます。
- 記事数の拡充: SEOで検索流入を増やすために、柱記事と周辺記事を計画的に増やす
- Bot運用データの蓄積: リアルタイムの運用実績を公開し、信頼性を積み上げる
- SNSでの発信強化: X と note を組み合わせたファネル型の情報発信
- KPI の進捗報告: 月次で振り返り記事を公開
Building in Public は続けてこそ意味があります。良い数字も悪い数字も、包み隠さず記録していきます。
まとめ
| ポイント | 内容 |
|---|---|
| プロジェクト数 | 4つ同時(Bot / ブログ / SNS / 分析) |
| 技術選定 | Astro + Cloudflare + Oracle Cloud + Claude Code |
| 初月の主な作業 | インフラ構築 → コンテンツ制作 |
| 月額コスト | ドメイン代のみ(約125円/月) |
| 最大の学び | ファクトチェック体制の重要性 |
一人会社でもAIを活用すれば、複数プロジェクトを同時に進めることは可能です。ただし、AIに任せきりにはできません。品質管理と意思決定は人間の仕事です。
この記録が、同じように一人で何かを始めようとしている方の参考になれば幸いです。