2体のClaudeでLexioを構築する：実際に機能するワークフロー

Lexio—個人的な語彙学習ツール—の構築を始めたとき、私は意図的な選択をしました。Claudeを2つのまったく異なる方法で使い、決して混ぜないことです。

考えるためのClaudeと、コーディングのためのClaude。

これは単なるワークフローの癖ではありません。開発プロセスを健全に保つための分離です。

「Claudeに全部任せればいい」という問題

AIを開発に使う最もわかりやすい方法は、すべてをClaude Codeに投げることです。機能を説明し、コードを生成させ、それを繰り返す。そして、それはある程度機能します。

しかし、私はすぐに摩擦点を見つけました。コードを書いているとき、レビューアルゴリズムにSM-2を使うべきかLeitnerを使うべきかで立ち止まって議論したくないのです。その意思決定ループと実装ループは、認知的に異なるタスクです。それらを1つのClaude Codeセッションで混ぜると、散漫で焦点の定まらない結果になります。

そこで、私はそれらを分離しました。

2体のClaude、2つの役割

Claude Project：思考のパートナー

私はLexio専用のClaude Projectを作成しました。ここで、コードを1行も書く前に、すべてのアーキテクチャと製品に関する思考が行われます。

このProjectには完全なコンテキストがあります。技術スタック（Rails、Inertia.js、React、shadcn/ui）、データモデル、機能ロードマップ、私の好みと制約。次のステップを考えたいときは、ここに来ます。

典型的な会話はこんな感じです：

• 「レビューセッション機能を追加したい。語彙ごとのスケジューリングでSM-2に適したデータモデルは？」
• 「このユースケースでは、Telegram Botはwebhooksとlong pollingのどちらを使うべき？」
• 「監査ログを追加しようと考えています。ユーザーが語彙とどう関わるかを考えると、どのカラムが理にかなっていますか？」

このProjectは推奨事項をくれます—選択肢のリストではなく、理由付きの実際の決定です。方向性に同意したら、もう1つだけお願いします。

重要なステップ：プロンプトの生成

ここがワークフローが機能する核心です。Claude Projectに、Claude Codeで使うプロンプトを書いてもらいます。

「何を構築すべきか」ではなく、Claude Codeが曖昧さなく実行できる、正確で範囲を絞ったプロンプトです。例えばこんな感じ：

「review_sessions テーブルに以下のカラムを追加してください：[...]。ReviewSession モデルを belongs_to :user と started_at/completed_at ライフサイクルで作成してください。サービスオブジェクト ReviewSession::Creator は、既存の vocabularies テーブルに基づいてSM-2スケジューリングを実装する必要があります。」

そのプロンプトをそのままClaude Codeに貼り付けます。言い換えも書き直しもしません。

Claude Code：実行役

Claude Codeは明確で範囲が定まったタスクを受け取り、それを実行します。マイグレーション、モデル、サービスオブジェクト、スペックを書きます。私は出力をレビューしてコミットします。

意思決定はすでに済んでいるので、コードをレビューしながらアーキテクチャを評価する必要はありません。実装が意図と一致しているかを確認するだけです。

実際の運用例

LexioのOCR機能を構築したのが良い例です。この機能は、ユーザーがテキストを撮影し、ClaudeのビジョンAPIを使ってそこから語彙を抽出できるようにするものです。

プロジェクト内で、統合アプローチについて議論しました：OCRは同期のRailsコントローラーアクションにするべきか、それとも非同期ジョブにするべきか？MVPでは同期に落ち着きました—シンプルで、個人用ツールとしてはレイテンシーも許容範囲です。プロジェクトはまた、適切な抽象化も提案しました：VocabularyExtractor サービスがClaude API呼び出しをラップし、コントローラーを薄く保つというものです。

Claude Code内で、生成されたプロンプトを貼り付けました：VocabularyExtractor を特定のインターフェースで構築し、PhotosController#create アクションに統合し、APIエラーを適切に処理する。Claude Codeは初回で動作するコードを生成しました。

コードを読んでいる間、アーキテクチャについて考える必要はありませんでした。アーキテクチャの作業はすでに完了していたからです。

正直なトレードオフ

このワークフローは摩擦がないわけではありません。知っておくべきことがいくつかあります：

コードスタイルはあなたのものにはならない。 Claude Codeはクリーンで機能的なコードを書きますが、独自のスタイルがあります。変数命名、サービスオブジェクトの構造、バリデーションロジックの配置場所。私の好みと一致することもあれば、そうでないこともあります。私はこれを受け入れ、長期的に重要になることだけを修正することを学びました。

見た目よりも遅い。 「プロジェクト → プロンプト → コード → レビュー」のループは、自分でコードを書くよりもステップが多いです。スピードの利点は、行き詰まらないことから来ており、生のコーディング速度からではありません。時間が限られた個人開発者にとって、そのトレードオフは価値があります。

それでも、自分が何を作っているのかを理解している必要があります。 Claude Codeはエンジニアリングの判断の代わりにはなりません。プロジェクト内での思考ステップは任意ではありません。実装に時間を費やす前にアプローチを検証する場所なのです。これを省略してClaude Codeにアーキテクチャまで考えさせると、一貫性のない、つぎはぎだらけのコードになってしまいます。

なぜわざわざ分けるのか？

合理的な疑問として、すべてをClaude Codeに任せればいいのでは？と思う方もいるでしょう。アーキテクチャについても話し合えるのですから。

正直な答えは、コンテキストが混ざると品質が下がると感じるからです。Claude Codeがマイグレーションを書いている最中に、データモデルを再考してほしくはありません。製品の完全なコンテキストを持つ別のプロジェクトを用意することで、「考える」Claudeは、機能の履歴、設計上の制約、私の好みなど、しっかり考えるために必要なすべてを手に入れられます。「コーディングする」Claudeには、狭くて正確なタスクが与えられます。

優れたエンジニアリングチームが計画と実行を分けるのと同じ理由です。同じ人が両方できないからではなく、タスクの途中でモードを切り替えるのはコストがかかるからです。

これから始める人へのアドバイス

AIの支援を受けながら個人プロジェクトを構築しているなら：

まずプロジェクトを設定しましょう。スタック、データモデル、好みについてのコンテキストを与えてください。一緒に考えを声に出せる技術的な共同創業者として扱いましょう。

何かを作る準備ができたら、Claude Codeに直接行かないでください。プロジェクトで10分過ごしましょう。何を作るのか、なぜか、そして適切な形は何か。それからプロジェクトにプロンプトを書いてもらいましょう。

そのプロンプトをClaude Codeにコピーします。出力は直感ではなく、仕様に対して確認しましょう。

この分割は手間に聞こえるかもしれません。実際には、一貫性のあるコードと、何週間も解きほぐすのに費やすことになるコンテキスト切り替えのつぎはぎとの違いです。

---

*Lexioは、Rails、Inertia.js、Reactで構築している個人向け語彙学習ツールです。この投稿は、AI支援によるソロプロジェクト構築に関する連載の一部です。*