ソロ開発

この記事で得られること Claude Code Agent Teamの仕組みと使いどころ ソロ開発者がAgent Teamを使う具体的なユースケース 実際のタスクリスト・チーム構成の実例 通常のサブエージェントとの違いと使い分け 前提：1人開発の「壁」 第6回で、Claude Codeを使って22万行のSaaSを1人で開発している話を書いた。AIが「10人分の手」として機能し、仕様策定から実装、テストまでを高速にこなしてくれる。 しかし、Claude Codeを使い込むほど、1つの限界が見えてきた。 Claude Codeは1つのセッションで1つのことしかできない。 人間のチーム開発なら、AさんがAPIを実装している間にBさんがテストを書き、Cさんがコードレビューをする。しかしClaude Codeは1つのセッションで逐次的にしか動かない。PRを5件マージする作業も、1件ずつ順番に処理するしかなかった。 Agent Teamは、この制約を壊す機能だ。 Agent Teamとは何か Agent Teamは、複数のClaude Codeインスタンスを1つのチームとして協調動作させる機能だ。2026年2月にResearch Previewとしてリリースされた。 通常のClaude Code: 1セッション ──→ 逐次処理 Agent Team: Team Lead ──→ Teammate A ──→ 並列処理 ├→ Teammate B ──→ 並列処理 └→ Teammate C ──→ 並列処理 通常のサブエージェント（Taskツール）との違いは明確だ： 特徴 サブエージェント（Task） Agent Team コミュニケーション 親に報告するだけ メンバー間で直接会話できる コンテキスト 親のコンテキストを共有 各自が独立したコンテキストを持つ タスク管理 なし 共有タスクリスト（依存関係付き） 人間の介入 親経由のみ 各メンバーに直接指示可能 用途 調査、単発の作業委任 複数トラックの並行作業 サブエージェントが「部下に仕事を投げて結果を受け取る」なら、Agent Teamは「チームを編成してプロジェクトを回す」感覚に近い。 ...

この記事で得られること セルフホストランナー環境で起きる問題と対策パターン 共有Docker daemonでのリソース競合の防ぎ方 誕生日のパラドックスに殺されるポート割り当ての話 「動いていたCIが突然壊れる」原因の調査手法 はじめに 第2回で、WebAuthnやMailpitを使ったE2Eテスト自動化について書いた。テスト自体は問題なく動く。問題はCIインフラの方だった。 Saruは4つのフロントエンド × 4つのバックエンドAPIを持つ。E2Eテストは各ポータルごとに独立して実行し、さらにクロスポータルテスト（ポータル間の連携テスト）もある。これらを並列実行すると、7つ以上のジョブが同時に走る。 当初はGitHub-hostedランナーを使っていたが、E2Eテストにはデータベース、Keycloak、メールサーバーが必要で、Dockerコンテナを大量に起動する。GitHub-hostedでは毎回のセットアップに時間がかかり、並列実行のコスト効率も悪い。 そこでセルフホストランナーに移行した。その判断は正しかったが、新しい種類の問題が大量に発生した。 本記事では、セルフホストCI環境で遭遇した問題と、その解決策を時系列で記録する。同じ構成を採用する人の参考になれば幸いだ。 1. Docker Desktop/WSL2が不安定すぎた 最初の構成 最初はWindows上のDocker Desktop（WSL2バックエンド）でランナーを動かしていた。構成はシンプルだ： Windows Host └─ WSL2 └─ Docker Desktop └─ GitHub Actions Runner × N 問題は「コンテナがランダムに死ぬ」こと。E2Eテスト中にPostgreSQLコンテナが突然消えたり、Keycloakが応答しなくなったりする。docker inspectするとExit Code: 137（SIGKILL）で殺されている。 原因を追うと、Docker Desktop/WSL2の仮想化レイヤーが問題だった： コンテナ → Docker Engine → WSL2 → Hyper-V → Windows WSL2自体がHyper-Vの軽量VMとして動いており、そこにさらにDockerが乗る。メモリプレッシャーが高まるとWSL2がOOM Killerを発動し、Dockerコンテナが無差別に殺される。 Hyper-V VMへの移行 解決策として、WSL2を経由せず直接Hyper-V上にUbuntu VMを立てた： コンテナ → Docker Engine → Ubuntu VM → Hyper-V → Windows 項目 値 VM名 saru-ci-runner OS Ubuntu 24.04 vCPU 16 メモリ 64GB ディスク 200GB ネットワーク External Switch（ブリッジ） Hyper-V VMの方が仮想化レイヤーが少なく、メモリ管理もWSL2より安定している。WSL2は動的メモリ割り当てで「ホストと共有」する（デフォルトでホストRAMの50%または8GBまで）が、Hyper-V VMは固定メモリを割り当てるため、OOM Killerに殺されるリスクが低い。 ...

この記事で得られること Claude Codeを使った大規模開発のリアル AIに任せていいこと、人間が判断すべきこと 20万行のコードベースでの実際のワークフロー 数字で見るプロジェクト 項目 数値 コード行数 約20万行（Go 84k + TypeScript 113k） 開発期間 約3ヶ月（2025年10月〜） コミット数 311 開発者 1人 ポータル 4つ（System / Provider / Reseller / Consumer） API 4つ（各ポータル専用） 1人で、3ヶ月で、20万行。 正直に言うと、このコードの大半はClaude Codeが書いた。私がやっているのは、方向性を決めて、レビューして、判断すること。 Claude Codeとは Anthropicが提供するCLIベースのAIコーディングエージェント。ChatGPTやCopilotとの違いは： 自律的に動く: 「この機能を実装して」と言えば、ファイルを読み、コードを書き、テストを実行する コンテキストが広い: 20万トークン（約15万行相当）を一度に理解できる CLIネイティブ: VSCodeに依存せず、ターミナルで完結 実際のワークフロー 1日の流れ 朝: Issueを1つ選ぶ ↓ Claude Code: 「この機能を実装して」 ↓ Claude Code: 仕様書（spec.md）を生成 ↓ 私: レビュー、修正指示 ↓ Claude Code: 設計書（plan.md）を生成 ↓ 私: レビュー、承認 ↓ Claude Code: 実装 ↓ 私: 動作確認、コードレビュー ↓ Claude Code: テスト作成 ↓ 私: マージ 私の作業時間は1日2-3時間。残りはClaude Codeが動いている間に別のことをしている。 ...

この記事で得られること WebAuthn（パスキー）認証をCI環境でテストする方法 OTPメール取得の自動化（Mailpit API連携） 並列E2Eテストでのメール競合を防ぐテクニック 日本語UIを直接テストするlocale-specific testing はじめに 第1回では、マルチテナントSaaS「Saru」の全体像と自動化戦略を紹介した。今回は、その自動化の核となるE2Eテストの実装詳細を掘り下げる。 特に難しいのが認証フローのテストだ。Saruでは2種類の認証方式を採用している： ポータル 認証方式 難しさ System / Provider OTP + パスキー メール取得、WebAuthn Reseller / Consumer Keycloak OAuth 外部IdP連携 これらをすべてCIで自動テストする方法を解説する。 1. WebAuthn仮想認証器：パスキーをCIでテスト パスキー認証の課題 WebAuthn（パスキー）は物理的なセキュリティキーや生体認証を使う。普通に考えると、CI環境でテストするのは不可能に思える。 解決策：Chrome DevTools Protocol (CDP) の仮想認証器 Playwrightでは、CDPを通じて仮想的な認証器を作成できる。これにより、物理デバイスなしでWebAuthnのフルフローをテストできる。 注意: CDP仮想認証器はChromium系ブラウザ限定の機能。Safari（WebKit）やFirefoxでは使用できない。クロスブラウザ対応が必要な場合、WebAuthnテストはChromiumでのみ実行し、他ブラウザでは認証済み状態をモックする等の対策が必要になる。 実装コード 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 import { test, expect, type BrowserContext } from '@playwright/test'; test('should complete signup with Passkey registration', async ({ page, context }) => { // 仮想認証器を有効化 const cdpSession = await context.newCDPSession(page); await cdpSession.send('WebAuthn.enable'); // 仮想認証器を追加 await cdpSession.send('WebAuthn.addVirtualAuthenticator', { options: { protocol: 'ctap2', // CTAP2プロトコル transport: 'usb', // USB接続をエミュレート hasResidentKey: true, // パスキー対応 hasUserVerification: true, // 生体認証をエミュレート isUserVerified: true, // 常に認証成功 automaticPresenceSimulation: true, // 自動応答 }, }); // ... サインアップフローを実行 ... // Passkey登録ボタンをクリック await page.getByRole('button', { name: 'Passkey' }).click(); // 仮想認証器が自動的に応答し、登録が完了する await expect(page.getByText('Passkey registered')).toBeVisible(); // クリーンアップ await cdpSession.send('WebAuthn.disable'); }); transport設定とサーバー設定の整合性 WebAuthn仮想認証器を設定する際、サーバー側の設定との整合性が重要になる。 ...

この記事で得られること 「1人で作れる規模」を超えたシステムに挑む際の考え方 複雑なマルチテナントシステムの設計概要 手動テストゼロを実現する自動化戦略 はじめに 「1人で保守できないものは作るな」 ソロ開発の鉄則だと思う。でも、あえてその限界に挑戦してみたくなった。 AIコーディングエージェント（Claude Code、GitHub Copilot等）を数カ月実務で使ってきて、「これなら1人でも複雑なものを作れるかもしれない」と思い始めた。ただし条件がある。徹底的な自動化だ。 このブログでは、マルチテナント型サブスクリプション管理システム「Saru」の開発記録を残していく。複雑なシステムを1人で作り切るために、何を自動化し、どう設計したかを共有する。 なぜ「保守できない複雑さ」に挑むのか AIコーディングエージェントで「ちょっとしたもの」ではなく「本格的なもの」を作ってみたい 1人では普通作れない規模のシステムに、自動化でどこまで対抗できるか試したい 失敗しても学びになる。成功すれば再現可能なノウハウになる Saruの複雑さ 4階層のアカウント構造 一般的なSaaSは「管理者 → ユーザー」の2階層。Saruは4階層ある。 階層 役割 説明 System プラットフォーム管理 全体を統括 Provider サービス提供 SaaSや商品を提供 Reseller 販売代理 Providerのサービスを販売 Consumer 購入・利用 サブスクリプションを購入 さらに： ResellerがPROVIDE権限を持つと独自サービスも提供可能 ConsumerがPROVIDE権限を持つとCreator（個人事業者）になれる この柔軟性が複雑さの源泉であり、差別化ポイントでもある。 4ポータル × 4API 各階層に専用のフロントエンドとAPIがある。 ポータル API ポート System Portal system-api 3001 / 8080 Provider Portal provider-api 3002 / 8081 Reseller Portal reseller-api 3003 / 8082 Customer Portal customer-api 3004 / 8083 ポータルは動的サブドメインで分離（例: provider-xxx.example.com） ...