ソフトウェアファクトリーがここ数週間で大流行しています。そこで、私も一つ作ってみました。学んだこと、その仕組み、そして午後一つで作る方法をご紹介します。
私の目標
非常にシンプルで、手間をかけずに動作するものである必要がありました。理想的には、既存の Claude サブスクリプションだけで完全に動作することです。
素朴に聞こえるかもしれませんが、基本的に既存のワークフローに簡単に統合できなければ、長続きするものにはなりません。この新しいシステムを使うために、既存の習慣をすべて変えなければならないのは避けたいです。経験上、そうなると長期的には機能せず、結局使わなくなってしまいます。
そこで、一気に取り組むのではなく、2 つの明確なフェーズに分けました。
- 事前トリアージ - やるべきことを整理する
- 実装 - 実際にやる
中心となるのは Linear で、やるべき作業の真実の情報源です。すべてのソフトウェアファクトリーには、GitHub Issues、Linear、またはその他の手段による、作業の集中リポジトリが必要です。既に使っているものであるべきで、エージェントや人間が後で拾って完了できるように、どのシステムでも簡単に作業を追加できるように拡張可能である必要があります。
System Health Check ループを介して自動生成された Issue を表示する Linear
パイプラインには意図的に境界が定義されており、ソフトウェアファクトリーの構築プロセスを実際に管理しやすくしています。
- 作業の作成（MCP を使ったループ）
- 作業の保存（Linear）
- 作業の完了（SDLC エージェント）
分割することで、事前トリアージと実装の両方を同時に構築する必要はありません（実際、過剰設計を避けるために私は同時にやらないことをお勧めします）。Linear は「やるべきこと」と「現在やっていること」の間のインターフェースを明確に定義し、拡張しやすくしています。
事前トリアージステップ
上記の図では、作業は左から右に進みます。左側は作業が作成される場所で、人間、エージェント、API などのさまざまなシステムが、やるべきことを追加していきます。この事前トリアージステップで作成されたすべての出力は、私たちの Linear に入力されます。
Claude クラウド環境で動作するいくつかのループ
このステップでは、3 つの主要なループがあります。
- System Health Check ループ（バグファインダー）- このループは毎日午前 5 時に実行され、いくつかの MCP サーバーに接続されています：エラー追跡用の Posthog、システム診断用の Vercel、Issue 作成用の Linear。
- UX 改善とカスタマーフィードバックループ - このループは毎週月曜日の午前 9 時に実行され、新しいフィードバック、Intercom/Fin からのカスタマーサポートチャット、すべての Posthog セッションリプレイをスキャンします。セッションリプレイは宝の山です。どこで怒りのクリックが発生しているか、ユーザーがどこで苦労したり混乱しているかがわかります。
- チャーン分析ループ - このループは毎日午前 6 時に実行され、過去 24 時間以内にキャンセルをクリックしたすべての顧客を調査します。Stripe から支払い情報とユーザーデータ（メール、場所を含む）を取得し、その顧客の Posthog セッションリプレイを調べて、キャンセル前に何をしていたかを確認します。Supabase から使用状況を取得し、ICP が間違っていたのか、あの「すごい」瞬間を経験しなかったのか、バグに遭遇したのかを判断します。レポートは Slack に送信され、エージェントは顧客の解約に関連する Issue を作成（またはコメント）して優先順位を引き上げます。
これらのエージェントを一貫して実行するために、私はシンプルに Claude Code Cloud Routines を使いました。Hetzner VPS やカフェイン漬けの Mac mini などで過剰設計する必要はありません。既存の Claude Code サブスクリプションを活用し、スケジュールや Webhook イベントでトリガーできる常時稼働エージェントを作成する方法としては、これが断然最も簡単な方法です。「ベンダーロックインはどうなんだ！」と言う人もいますが、これはただのテキストに過ぎません。プロンプトを好きな場所にコピーしてください。私はとにかく最も簡単で安価で、信頼性の高いものをセットアップしたかっただけです。
もう一つの理由は、Anthropic のクラウド環境がローカルで実行する Claude とほぼ同等であることです。
クラウド Claude ルーチン
当然、環境変数は含まれていません（必要に応じてクラウド環境のセットアップに追加できます）が、Desktop App のコネクタ経由で MCP 接続を設定すれば、Codex とは異なり、ローカルの Claude CLI とリモートの Claude の両方でそれらを使用できます。これが私にとってのキラーフィーチャーであり、これらの事前トリアージエージェントループが非常にうまく機能する理由です。また、ラップトップのメモリを気にせずに複数のセッションを並行して実行するのも簡単です。
この事前トリアージステップだけを実装しても、作業を完了する次のステップを構築しなくても、大きな効果が得られます。まずは単一のループから始め、試して、改良し、さらに追加してください。今日作成できるルーチンを見つけて、既存の Issue トラッカーに新しく質の高い作業を投入し、実装は今まで通りの方法で行ってください。
実装ステップ
ステップ 2 の最も基本的なバージョンは、エージェントに Issue ID を与えて「これを完了して」と指示することです。これは多くの人がエージェントと作業する際にすでに行っていることですが、これを読んでいるあなたが求めるものではないでしょう。なぜなら、あなた自身がループのボトルネックとなり、セッション内で直接エージェントを起動することになるからです。
代わりに私が行ったのは、Linear から直接リモートの Claude Code セッションをトリガーする方法を構築することです。
Linear Issue から Claude へ
仕組みは次の通りです。
- まず、新しい Claude セッションをトリガーする方法を決めます。私たちの場合、新しいタスクを開始するために Linear Issue に 'auto' ラベルを追加します。
- 次に、Linear が内部 Webhook API サービス（新しく作成した内部 Hono アプリ）に Webhook イベントを送信し、イベントを解析して正しい情報を Claude Routine に転送します。
- 最後に、この軽量 API サービスが Anthropic に POST リクエストを行い、初期プロンプトで Claude Routine をトリガーします。
'auto' ラベルをトリガーとして使用することで、新しい Claude セッションの自動実行を制御できます。デフォルトでは、事前トリアージステップにこれらの 'auto' ラベルは含まれず、人間がラベルを追加してエージェントが作業を開始するようにトリガーする必要があります（人間がループに残るように）。そのため、ステップ 1 を事前トリアージステップと呼んでいます。実際に何に取り組むべきかを、人間の関与またはエージェントが新しい Issue の追加を監視して新しい実装セッションを開始するかのいずれかで判断しているからです。
ただし、ラベルの追加はエージェントでも簡単にできるため、事前トリアージループがデフォルトで 'auto' ラベルを付けた新しい Issue を作成し、新しい Claude セッションを開始することも可能です。ラベルを使用することは、エージェントによる自動、または人間による手動のいずれでも新しい実装作業を開始できる非常に柔軟な方法です。
Claude セッションを開始する軽量ルーティングサービス
Linear が Webhook をサポートしているため、「ラベルが追加されたらプッシュする」という仕組みが機能します。唯一の欠点は、これらの Webhook を受け入れ、イベントとペイロードデータをフォーマットして Claude Code をトリガーする公開 API が必要なことです。この新しいサービスは正しい認証ヘッダーも追加するため、Linear がルーチンを直接トリガーすることはできません。
別の方法として、定期的に開始され、進行中でない 'auto' ラベルの新しい Issue を実装しようとするスケジュールルーチンを持つこともできます。
実際のルーチンプロンプトについては、SDLC 全体をカバーする再利用可能なスキルを構築することをお勧めします。名前は /implement や /do などで、"/do ISSUE-NNN" と簡単に言えるようにします。このスキルは、Issue のコンテキストの取得、作業の実装、ブラウザでの検証、PR の作成、コメントの監視といった手順を正しく実行する方法を文書化します。
そして、Linear イベントによってトリガーされる Claude ルーチンのプロンプトは、非常にシンプルなものにできます。以下が私の例です。
提供された Issue を取得し、/do スキルを使用して要求された変更を実装し、プルリクエストを作成してください。指定された Issue のみを取得してください。すでに完了しているか進行中の場合は停止してください。
Issue の参照はこのメッセージには含まれていません。これは、同じセッション内でこのメッセージの直後に送信される、\
<routine-fire-payload>\タグで囲まれた別のフォローアップメッセージとして届きます。Issue が提供されたかどうかを判断する前に、そのメッセージを待ってください。\<routine-fire-payload>\メッセージを確認し、参照された Issue が実際に存在しないことを確認した後でのみ、Issue が存在しない、または提供されなかったと結論付けてください。作業を開始する際は、Issue にコメントを付け、ステータスを「In Progress」に設定し、進行に応じて意味のある内容で Issue を更新してください。Linear の Issue コメントには常に先頭に [Claude] を付けてください。
これで、API を介してトリガーされた並列の Claude Remotion セッションが、Issue を実装し、PR を作成し（できれば Playwright や Agent Browser で作業を検証しながら）、稼働していることになります。これは本質的に、完全に監視可能で、眠っている間も実行され、すべて Claude Code サブスクリプションで動作する、完全なソフトウェアファクトリーです。
