スレッドベースのエンジニアリング

AIを活用したエンジニアリングで本当に上達しているかどうか、どうやって確かめればいい?

「生産性が上がった気がする」ではなく。数えること。測定すること。今週が先週より良かったと、数字で示すこと。

スレッドベースのエンジニアリングは、それを可能にするフレームだ。AIを使ったすべての作業が、スレッドと呼ばれる個別の単位になる。作業がスレッドとして見えるようになれば、チューニングできる。

スレッドとは、あなたとエージェントが一緒に進める、時間軸上に伸びた1つの作業単位だ。

すべてのスレッドには、人間が必要なノードが2つある:

1. 始まり。あなたがプロンプトを書くか計画を立てる。
2. 終わり。あなたがレビューするか検証する。

中間は? エージェントがツール呼び出しを通じて処理する。

これがベーススレッドだ。Claude Code を起動してプロンプトを実行するたびに、1つのスレッドが始まる。エージェントはツール呼び出し(ファイルの読み込み、コードの書き込み、コマンドの実行)を実行し、停止したらあなたが結果を確認する。

シンプルなアイデア。大きな意味を持つ。

核心的な洞察: ツール呼び出しはほぼインパクトに等しい(プロンプト自体が価値あるものであれば)。

2023年以前、ツール呼び出しはあなた自身がやっていた。コードを編集し、ファイルを開き、コマンドを実行する。チェーン全体が手作業だった。

今日、あなたは最初(プロンプト)と最後(レビュー)に現れるだけでいい。中間は自動で動く。

より多くの有用なツール呼び出しをこなした人が、少ない人より勝る。それが新しいスコアボードだ。

ベーススレッドが理解できれば、スケールアップも自然についてくる。6つのパターンが、AIを使ったほぼすべてのワークフローをカバーする。

1. ベーススレッド

基礎。1つのプロンプト、エージェントの作業、1つのレビュー。

以下のすべてのパターンはこれを土台にしている。ベーススレッドが不安定なら、その上の何も機能しない。

用途。単純なタスク、素早い修正、単一ファイルの変更。

2. Pスレッド（並列実行）

複数のスレッドを同時に動かす。

Claude Code を作った Boris Cherny は、ターミナルに1から5番まで番号のついた5つの Claude Code インスタンスを常時開いている。さらに Claude Code のウェブインターフェースで5〜10個追加で動かしている。

合計10〜15の並列スレッドだ。1つのエージェントが認証を作り、別のエージェントがAPIエンドポイントに取り組み、もう1つがテストを書く。プロンプトを送って、タブを切り替えて、プロンプトを送って、タブを切り替えて、プロンプトを送る。それからレビューのために戻ってくる。

用途。独立したタスク、コードレビュー、フィーチャーブランチ、リサーチ。

改善方法。ターミナルウィンドウを増やす。バックグラウンドエージェントを Claude Code のウェブインターフェースに移す。カスタムツールでターミナルを分岐させる。

3. Cスレッド（チェーン型ワークロード）

フェーズ間に人間のチェックポイントを置いた多段階の作業。

1つのコンテキストウィンドウに収まらない作業もある。あるいは、次のステップに進む前に全工程を目視確認したいほどリスクが高い場合もある。

Cスレッドは作業をフェーズに分割する:

• フェーズ1: データベースマイグレーション
• フェーズ2: APIのアップデート
• フェーズ3: フロントエンドの変更

フェーズ間でレビューを行う。問題があれば早期に発見でき、大規模なロールバックになる前に対処できる。

用途。本番デプロイ、大規模なリファクタリング、慎重を要するマイグレーション、多段階ワークフロー。

トレードオフ。あなたの注意力。Cスレッドは人間の時間をより多く消費する。リスクに見合う場合に使う。

Claude Code の ask user question ツールはCスレッドをそのままサポートする。エージェントはワークフローの途中で一時停止し、次のフェーズに進む前に質問できる。

4. Fスレッド（フュージョン）

1つのプロンプト、複数のエージェント、そして最良の結果をマージする。

ワークフロー全体にわたる「N個のうちのベスト」を考えよう。同じプロンプトを4つのエージェントに送る。4つの出力をすべて見る。勝者を選ぶ。または複数の出力から最も優れた部分を組み合わせて、単独の出力より良いものを作る。

なぜ機能するのか。試行回数が多いほど成功の確率が上がる。1つのエージェントが苦戦している間に、別のエージェントがうまくこなすかもしれない。4つの視点は1つより優れる。

用途。素早いプロトタイピング、リサーチの問い、アーキテクチャの意思決定、信頼性が重要なコードレビュー。

プロトタイピングの未来。Fスレッドが素早いプロトタイピングを担うようになる。複数のエージェントを起動し、同じ問題を渡して、出力を融合する。計算リソースを増やすほど信頼性が上がる。

5. Bスレッド（ビッグ/メタ）

他のスレッドを内包する1つのスレッド。

ここからメタになる。プロンプトが別のプロンプトを起動する。サブエージェントがさらにサブエージェントを生成する。オーケストレーターエージェントがプランナーを動かし、次にビルダーを、次にレビュアーを動かす。

エンジニアの席からは、最初にプロンプトを送って最後にレビューするだけだ。その裏で複数のスレッドが自動で動いている。

最も分かりやすい例。サブエージェント。Claude Code に「サブエージェントを使ってこれら3つのタスクを処理して」と伝えると、内部で3つのスレッドが生成される。あなたからの1つのプロンプトで、3つのスレッドが動く。

用途。複雑な複数ファイルの変更、エージェントチームのワークフロー、オーケストレーションビルド。

パターン。エージェントがあなたの代わりにプロンプトを書く。オーケストレーターがワーカーエージェント用のプロンプトを書く。労力が10倍にならずに、アウトプットが10倍になる。

6. Lスレッド（長期持続）

人間を介在させない、長時間の自律的実行。

ベーススレッドを限界まで引き伸ばしたもの。10回のツール呼び出しではなく、100回。5分ではなく、5時間。Boris は26時間を超えるスレッドを動かしたことがある。

Lスレッドに必要なもの:

• 強力なプロンプト(優れた計画は優れたプロンプトに等しい)
• 確実な検証(エージェントが完了を判断できるように)
• チェックポイントの状態(コンテキスト制限を超えても作業を継続できるように)

Ralphとのつながり。Ralph Wiggum テクニックはLスレッドを中心に構築されている。ストップフックがエージェントを実際に作業が完了するまでループさせ続ける。早期終了なし。手取り足取りのサポートなし。

用途。一晩かけたフィーチャービルド、大規模なコードベース、バックログの消化。

もう1つのスレッドタイプが、エンジニアリングの向かう先を示している。

Zスレッド。ゼロタッチスレッド。エージェントへの完全な信頼。レビューノードがまったくない。

これはバイブコーディングではない。検証とガードレールが十分に積み重なって、アウトプットのレビューが本当に任意になるアジェンティックエンジニアリングだ。

エージェントが本番にデプロイする。アナリティクスを監視する。変更が機能したかどうかを判断する。反復する。

ほとんどのエンジニアはまだそこに達していない。しかし、すべてがその方向を向いている。目標は、レビューが不要になるほど信頼できるシステムだ。

すべてのスレッドパターンは4つの基本に帰結する:

1. コンテキスト。エージェントが何を知っているか
2. モデル。どのモデルが動いているか
3. プロンプト。何を求めているか
4. ツール。エージェントが触れるもの

この4つを正しく整えればエージェントが機能する。あらゆるスレッドの最適化はこのどれかに行き着く。

• より良いプロンプトはより長いスレッドを生む
• より良いコンテキストはより精度の高い作業を生む
• より良いツールはより多くの能力を生む
• より良いモデルはより高い信頼性を生む

特にLスレッドにおいて、ストップフックが重要な役割を担う。

エージェントが停止しようとすると、ストップフックが割り込む:

1. エージェントが完了しようとする
2. ストップフックが検証コードを実行する
3. 判断: タスクは本当に完了したか?
4. いいえの場合: 停止をブロックして反復を続ける
5. はいの場合: 完了を許可する

それがRalphループの技術的核心だ。ストップフックは、エージェントが完了したと思っているときには終了させず、作業が検証されたときにのみ終了させる。

スレッドベースのエンジニアリングは、実際に測定できるものを提供する。

1. より多くのスレッドを実行する（Pスレッド）

並列エージェントを増やせるか? Boris は10〜15だ。5に達せるか? 3に達せるか?

測定値。同時に動いているスレッドの数。

2. より長いスレッドを実行する（Lスレッド）

スレッドは、あなたが介入する前により多くのツール呼び出しをこなせるか?

測定値。介入前のスレッドあたりの平均ツール呼び出し数。

3. より太いスレッドを実行する（Bスレッド）

スレッドの中にスレッドを持てるか? 1つのプロンプトが5つのサブエージェントに展開できるか?

測定値。あなたが書く1つのプロンプトあたりの作業量。

4. チェックポイントを減らす

人間によるレビューの回数を減らせるか? あなたの検証は、レビューをスキップするのに十分な信頼を生むか?

測定値。手動確認前に実行されるフェーズ数。

これら4つの軸のどれかで改善できれば、アジェンティックエンジニアとして本物の進歩をしている。それが指標だ。上達しているかどうかを知る方法はそれだ。

実際の1日でどう見えるかはこうなる:

月曜の朝。5つのフィーチャーをリリースする必要がある。

古い方法。フィーチャー1。完了。フィーチャー2。完了。繰り返す。5つの逐次セッション。

スレッドベースの方法:

1. 5つのフィーチャー全ての仕様を書く（計画フェーズ）
2. 5つの Claude Code インスタンスを並列起動する（Pスレッド）
3. それぞれのインスタンスにフィーチャーを渡す
4. 最初に完了したものをレビューしながら残りを動かし続ける
5. いくつかのフィーチャーは段階的なフェーズが必要になる（Cスレッド）
6. 最も難しいものがサブエージェントを生成する（Bスレッド）
7. 一晩かかるタスクをRalphループのLスレッドとして動かす

同じ5つのフィーチャー。ただし今は、より多くのスレッド、より太いスレッド、より長いスレッドを動かしている。

スレッドベースのエンジニアリングとRalphループはうまく組み合わさる。

Ralph が答える問い: エージェントを本当に完了するまで確実に動かし続けるには?

スレッドベースのエンジニアリング が答える問い: エージェントの使用をスケールし、上達を測定するには?

RalphはLスレッドを実現する。スレッドベースのエンジニアリングは、LスレッドがPスレッドに勝るとき、そしてBスレッドが正しい選択のときを教えてくれる。

Ralphの裏にあるストップフックは、Lスレッドを生かし続けるのと同じストップフックだ。検証ファーストな開発が、どちらのパターンも機能させる。

先に進んでいるエンジニアたちは「AIを使っている」だけではない。スレッドで考えている。

すべてのタスクは1つの問いから始まる: これはどんなスレッドか? 並列化するか? チェーンするか? 内部にサブスレッドを持つか?

ボトルネックが移動した。かつては「どれだけ速くコードを書けるか?」だった。今は「どれだけ多くの有用なスレッドを動かせるか?」だ。

計算リソースをスケールする。インパクトをスケールする。

小さく始めよう:

1. 作業を振り返る。今いくつのスレッドを動かしているか? (ほとんどのエンジニアにとって: 1つ。)

2. Pスレッドを1つ追加する。2つ目のターミナルを開く。最初のエージェントがまだ動いている間に、並列タスクを実行する。

3. スレッドを計測する。介入する前のツール呼び出し数を数える。その数を追跡する。

4. Cスレッドを試す。大きなタスクを明示的なフェーズに分割する。フェーズ間でレビューする。

5. Lスレッドを目指す。検証を整備する。30分間エージェントを無人で動かす。

目標は明日15の並列Zスレッドに達することではない。目標は着実で測定可能な進歩だ。より多くのスレッド。より長いスレッド。より太いスレッド。より少ないチェックポイント。

それが上達していることを知る唯一の本物の方法だ。感覚ではなく。数えること。

• Lスレッドの自律性のためにRalph Wiggumループを追加する
• 並列エージェント実行のための非同期ワークフローを身につける
• Bスレッドアーキテクチャのためのサブエージェント設計を学ぶ
• 検証パターンのためのフィードバックループを構築する

スレッドベースのエンジニアリングは、AIコーディングを職人技から測定可能な実践へと変える。追跡できる。改善できる。スケールできる。

スレッドを数え始めよう。