Anthropic
Claude
アーキテクチャ、企画、ウェーブ3のレディネスゲートのための深い推論 — パイプラインが最初に設計された基準モデル。
複数のモデル、ひとつの完成されたプロダクトチーム
チームはモデルに依存しません。同じ17のロール、7ウェーブのパイプライン、堅牢なゲートが、あなたの選んだフロンティアモデル — 6つのプロバイダー — の上でそのまま動作します。書き換えもロックインもなく、ロールとウェーブごとに最適なモデルを割り当てられます。
OpenAI
Codex
実装とリファクタリングに強い。別プロセスへの委譲として動くため、どのランタイムとも同じウェーブに並べます。
Zhipu · Z.ai
GLM
このリポジトリでライブ接続が実証されている、唯一の差し替え型バックエンド。大量のロールに有能で、コスト効率もよい選択肢です。
Moonshot AI
Kimi
100万トークンのフラッグシップと、コーディング専用のティアを、Moonshot の Anthropic 互換エンドポイント経由で。
DeepSeek
DeepSeek
低コストのフラッグシップと高速ティア。エンドポイントが黙って無視するフィールドまで、カタログに書き残してあります。
Alibaba Cloud
Qwen
フラッグシップ・バランス・フラッシュの各ティアを Model Studio 経由で。エンドポイントが固定URLではなくワークスペースごとである点まで反映しています。
ロールごとに、ウェーブごとに選んでも、まったく手を付けなくても構いません — 決定論的なRustエンジン、ゲート、監査チェーンはそのまま変わりません。ライブAPI接続は Claude・Codex・GLM で確認済みです。Kimi・DeepSeek・Qwen は各プロバイダー公式の仕様を根拠に配線・文書化してありますが、実際のキーでの実証はまだです。
インストール
プラットフォームに合わせて Rust エンジンをビルドし、BATHOS_BIN で参照させてから、対応する6つのプロバイダーのうち選んだモデルで Claude Code からパイプラインを実行します。
1 — コードを取得してエンジンをビルド
2 — プロジェクトに BATHOS を連携
プロジェクトで βάθος を使えるようにする
ステップ1で選んだプラットフォームに合わせて変わります。このリポジトリを作業ディレクトリとして使うか、βάθος を自分のプロジェクトに連携します。
# Option A — use this repo as your working directory
# .claude/ (commands, agents, hooks) is already wired — just open Claude Code here.
# Option B — adopt βάθος into your own project:
./install.sh --into /path/to/your/project # --force overwrites an existing .claude/
export BATHOS_BIN="/path/to/bathos/core/target/release/bathos"3 — パイプラインを実行
選んだプロバイダーでウェーブを実行
プロジェクトで Claude Code を開き、/model-config でモデルを選んでからウェーブコマンドを順に実行します。
/team-kickoff
/route /abs/path/to/project
/wave1-discovery /abs/path
/wave2-design /abs/path
/wave3-story-gate /abs/path
/wave5-implement /abs/path
/wave6-verify-report /abs/path
/team-confirmAgent Teams を有効にした Claude Code v2.1.32 以降（対応する6つのプロバイダーのいずれでも動作）、加えて Rust ツールチェーン（bash フックには jq）が必要です。
チャットにはない構造を
長い一本のLLM会話は漂流します。設計と実装の間で文脈が失われ、チェックは飛ばされ、同じモデルが自らの成果を書きながら承認する。BATHOSはそれを構造に置き換えます。
素のLLMチャット
BATHOS
一本の会話、増していく文脈のドリフト
7ウェーブのパイプラインにまたがる17の専門ロール
設計と実装の間で文脈が失われる
文脈損失ゼロの、自己完結したストーリーファイル(ウェーブ3)
暗黙的で、一律の労力配分
Lv0〜4を明示するスケール適応型ルーター
実装がいつでも始まってしまう
FAIL時にビルドを物理的に阻止する堅牢なレディネスゲート
作成者が自らの成果を「検証」もする
独立したレビュアーと、改ざん検知可能な監査チェーン
いつの間にかあなたを上書きする助言
ユーザー主権：AIは提案し、決めるのはあなた
2つのプレーン、1つのランタイム
あなたが打つのは主にスラッシュコマンド。その裏側でコマンドが呼び出す決定論的なコアが、単一のRustバイナリです。
.claude/ 配下のMarkdown
オーケストレーション
ウェーブを回し、チームメンバーをスポーン・レビュー・退場させるスラッシュコマンド、ロール、フック。そのウェーブに選んだプロバイダーで動く、あなたのメインセッションであるリードが駆動します。
単一の静的Rustバイナリ
エンジン
状態、ゲート、ウェーブ遷移、ルーティング、ストーリーの鮮度、プラグインを算出し強制します。フックとコマンドから自動的に呼び出されます。
7ウェーブのデリバリーパイプライン
作業はディスカバリーから検証済みリリースへと、明示的なウェーブを通じて進みます。本流はW0 → W1 → W2 → W3 → W5 → W6。IP・研究(W4)はクリティカルパス外のオプションのプラグインです。
W0
分析
Caleb
任意の事前ブリーフ：ブレインストーム、アイデアの鍛造、プロダクトブリーフ。
W1
ディスカバリー・市場
John · Caleb
リバースエンジニアリングと市場調査でUSPを研ぎ澄ます。
W2
企画・アーキテクチャ・デザイン
Joshua → James · Jonnathan
企画がウェーブをゲートし、続いてアーキテクチャとUXを並行で。
W3
ストーリーエンジニアリング
Matthew + Thomas · Matthias
自己完結したストーリーファイルへ凝縮。実装レディネスゲート。
W4
IP・研究
Mark · Nathanael
クリティカルパス外のオプションのプラグイン：特許と論文。
W5
実装
Phillip · Andrew · Stephen
バックエンド、フロントエンド、MLをストーリーファイルに沿って構築。
W6
検証・ドキュメント・レポート
Thomas · Michael · Hananiah · Martin
レビュー、セキュリティ監査、動作を保つリファクタリング、そしてリリースレポート。
ウェーブ3：心臓部
ウェーブ3は、設計から実装への断絶を埋めます。ストーリーエンジニアが上流の成果を自己完結したストーリーファイルへと凝縮し、あらゆる技術的主張を出典に紐づけ、独立したレビュアーが承認します。FAIL時にはフックが実装への進入を物理的に阻止します。
ウェーブごとに、その仕事に合うモデルを
ディスカバリーとアーキテクチャと実装は、同じ仕事ではありません。だから同じモデルで回す必要も、もうありません。ウェーブごとに使いたいプロバイダーを指定しておけば、エンジンがその宣言を最後まで守らせます。
- Claudenative
- Codexsubprocess
- GLMenv-swap
- Kimienv-swap
- DeepSeekenv-swap
- Qwenenv-swap
- ウェーブ単位で、ロール単位で
- bathos model set --wave W5 --runtime kimi が、そのウェーブの選択を model-plan.json に記録します。ロール指定はウェーブ指定に優先し、解決はロール → ウェーブ → 既定値 → エージェントの frontmatter → ランタイム既定という5段階を降りていきます。どの値がどの段階から来たのかも、すべて併記されます。
- 6つのプロバイダー、1つのインターフェース
- Claude はネイティブに、Codex は別プロセスへの委譲として、GLM・Kimi・DeepSeek・Qwen はそれぞれの Anthropic 互換エンドポイント経由で接続します。どのランタイム同士が同じバッチに並べるかは、たった一つの述語が判定します。だから7つ目のプロバイダーを増やすことは、その述語一つに教えることであって、ルールを書き直すことではありません。
- 約束ではなく、ゲート
- 環境変数はプロセス全体で共有されるため、差し替え型のプロバイダー2つを1つのセッションで同時に動かすことはできません。bathos model validate --wave がその組み合わせを exit 2 で止め、切り替え手順を表示します。モデルが裏で勝手に入れ替わるふりはしません。
- カタログはメニューであって、柵ではありません
- 6つのプロバイダーにまたがる30のモデルを整理し、項目ごとにプロバイダー公式のドキュメントで直接確認できたかを示し、廃止されたIDは分けて残してあります。モデルIDは自由記述なので、古いモデルや安価なモデルもそのまま動きます。新しいモデルが出ても JSON の編集だけで済み、エンジンを作り直す必要はありません。
$ bathos model set --wave W2 --runtime claude
$ bathos model set --wave W5 --runtime kimi
$ bathos model set phillip --runtime codex
# a role assignment beats its wave
$ bathos model validate --wave W5
→ exit 2 · session is claude, W5 wants kimi
save → set env → restart → /cold-startウェーブごとにプロバイダーを宣言しておけば、間違ったバックエンドでウェーブが始まる前に validate が止めます。
トークン上限に当たったら、計画ではなくモデルを替える
たいていのエージェント作業は使用量の上限で死にます。チームメイトが黙り込み、その頭の中にあったものも一緒に消える。ここではそれが一時停止で済みます。引き継ぎはすべてディスクにあるので、まだ余裕のあるプロバイダーへコマンドラインでつなぎ直すだけで、ウェーブは止まったところから続きます。
1 · 気づく
黙ったチームメイトは、たいてい quota です
出力が止まったチームメイトは、ほとんどの場合クラッシュではありません。十中八九はアカウントのセッション上限で、本人のトランスクリプトにそう書かれています。安易に kill しないでください。bathos model show はヘッダーに現在のセッションバックエンドを表示するので、どのプロバイダーが尽きて、どのロールがそこに立っていたかがすぐ分かります。
2 · 付け替える
ウェーブ単位でもロール単位でも、コマンド一行
bathos model set --wave W5 --runtime glm --model glm-5.3 が、そのウェーブの新しいプロバイダーを model-plan.json に記録します。ロールを指定すればそのロールだけを上書きし、bathos model unset はフォールバックへ戻します。書き換わるのは変更した項目だけで、残りの計画には触れません。
3 · 再開する
一度だけ再起動し、失うものはない
GLM・Kimi・DeepSeek・Qwen は ANTHROPIC_BASE_URL を差し替えて接続します。この環境変数はプロセス全体で共有されるため、切り替えには保存と env の交換と新しいセッションが要ります。知らないうちに裏で入れ替わることはありません。別プロセスに委譲される Codex は、そのどちらも要りません。/cold-start でセッションを復元すれば、ウェーブはディスクに残った成果物から回り直します。
# 1 — which backend am I on, and what just ran dry?
$ bathos model detect # ANTHROPIC_BASE_URL → claude|glm|kimi|deepseek|qwen
$ bathos model show # effective runtime/model per role, and its source
# 2 — re-point the wave (or one role) at a provider that still has budget
$ bathos model set --wave W5 --runtime glm --model glm-5.3
$ bathos model set stephen-ml-engineer --runtime codex
# a role assignment beats its wave · unset returns it to the fallback
$ bathos model validate --wave W5
→ exit 2 · session is claude, W5 wants glm
1) take the whole batch to glm 2) move the role to claude / codex
3) split the wave: finish this batch, shut down, restart on glm
# 3 — env-swap runtimes only: save, swap, restart, resume
/save
$ export ANTHROPIC_BASE_URL=https://api.z.ai/api/anthropic
$ export ANTHROPIC_AUTH_TOKEN=… # DeepSeek reads ANTHROPIC_API_KEY instead
# restart Claude Code → /cold-start → re-run /wave5-implement間違ったバックエンドでウェーブが始まることを validate が止め、スタックトレースではなく抜け道を3つ表示します。
プロバイダーを替えても、ほかは何も変わりません。同じ17ロール、同じ PASS / CONCERNS / FAIL、同じ監査チェーン、同じウェーブ順。モデルIDは allowlist ではなく自由記述なので、同じアカウントのより安いモデルや古いモデルもそのまま動きます。上限を越える最短ルートは、別のベンダーへ渡ることではなく、一段下のティアへ降りることであることも多いのです。
スケール適応型ルーティング
BATHOSはタスクに必要なウェーブだけを起動します。ルーターは4つのステークス軸からレベルを推奨し、あなたが確定します。
| レベル | 作業タイプ | 起動ウェーブ |
|---|---|---|
| Lv0 | バグ修正 / 些細な変更 | W5(+最小限のW6) |
| Lv1 | 小機能 / 局所的リファクタリング | 軽量W2 + W3(縮約) + W5 + 軽量W6 |
| Lv2 | 標準機能 / モジュール | W1 + W2 + W3 + W5 + W6 |
| Lv3 | 新規プロダクト / 大規模 | W0–W6(W4は任意) |
| Lv4 | エンタープライズ / ディープテック / 規制対象 | W0–W6フル + W4 |
17人の専門家、1人のリード
リードはあなたのメインセッションであり、スポーンされることはありません。専門家はウェーブごとにスポーンされ、同時実行数は3に制限されます。
00Paulリード / 最終承認all
01Johnリバース専門家W1
02Caleb市場分析 / USPW1
03Joshuaサービス企画W2
04JamesSW / クラウドアーキテクトW2
05MarkIP専門家(特許)W4
06NathanaelリサーチライターW4
07Jonnathanチーフデザイナー(UX/UI)W2
08Phillipバックエンド・データリードW5
09Andrewフロントエンド・モバイルリードW5
10StephenAI / MLリードW5
11Timothy開発定義ドキュメントW6
12ThomasコードレビュアーW6
13Michaelセキュリティ専門家W6
14Hananiahリファクタリング専門家W6
15MatthiasQA / 検証W6
16Martinモニタリング / レポートW6
17Matthewスクラムマスター / ストーリーエンジニアW3
本当にゲートするゲート
すべてのウェーブゲートは一つの語彙で語り、要となるゲートはコードで強制されます。根拠のない自動PASSはありません。
PASS
基準を満たし、ブロッカーなし
次のウェーブへ進む
CONCERNS
条件付き通過、非ブロッキングのリスク
リスクを記録し、進む
FAIL
ブロッキングの欠陥
進入を阻止。是正して再ゲート
設計段階から改ざん検知可能
あらゆる状態変更は鍵付きの監査ハッシュチェーン(HMAC-SHA256)に書き込まれます。たった一つのコマンド（bathos audit verify）で、証跡が改変されていないことを証明できます。
デモのようにではなく、よく訓練されたエンジニアのように作ります
放っておけば、AIはどんな課題にも新しいコードで答えます。新しい抽象、新しい依存、もう一つのファイル。ウェーブ5の実装者には、その代わりに明示的な規律が渡されます。何かを書き始める前に7段のはしごを登り、最初に引っかかった段で止まる。解法には怠けても、読むことには決して怠けない。
これは本当に存在する必要がありますか？
推測で必要そうなものは作らず、作らなかったことを一行で明言します。YAGNI。
このコードベースにもうありますか？
すでにここに住んでいるヘルパー・型・パターンがあれば、それを使います。数ファイル隣にあるものを作り直すのが、最もよくある無駄です。
標準ライブラリがやってくれますか？
ならば標準ライブラリがやります。
プラットフォームに元からありますか？
ピッカーライブラリより日付入力、JSよりCSS、アプリケーションコードよりDBの制約。
すでに入っている依存で賄えますか？
それを使います。数行で済むことのために新しい依存を追加しません。
一行で済みますか？
ならば一行です。
そこで初めて、動く最小限。
最も短い差分が勝ちます。ただし、その変更がどこまで触る必要があるのかを実際に理解した後で。
ここは削りません
- 信頼境界での入力検証
- データ損失を防ぐエラー処理
- セキュリティ対策
- アクセシビリティの基本
- 明示的に依頼されたこと
- 問題の理解 — はしごは解法を短くしますが、読むことは短くしません
はしごが支配するのは「何を作るか」です。決まったスコープをどこまで完全に作り切るかは別の軸で、そちらは Boil the Ocean の担当です。この二つを引き換えにすることはありません。
// ponytail: single global lock, split per-wave
// if profiling shows contention
# ponytail: fixed backoff, go exponential once
# the API starts rate-limiting
$ /bathos-debt # CONCERNS: docs + ponytail: src
→ 2 open · 1 no-trigger意図的に切り詰めたところは、その上限と見直しのトリガーをコードに残し、/bathos-debt がそれを一つの台帳にまとめます。トリガーを書いていないマーカーには印が付きます。静かに腐っていくのは、まさにそれだからです。
強度はスイッチ一つで決まります：/bathos intensity lite · full · ultra · off。
エンジニアリング原則は Dietrich Gebert 氏の ponytail (MIT) から取り入れました。ペルソナとブランディングは取り入れていません — BATHOS はキャラクターではなく、オーケストレーションのプロダクトです。
雰囲気ではなく、決定論的なコアを
要となる不変条件（状態、ゲート、ルーティング、ストーリーの鮮度）は単一の静的Rustバイナリに収められ、毎回同じやり方で算出され強制されます。
- 単一の静的バイナリ
- コンパクトなbathos実行ファイル一つ、ランタイム依存なし。
- スキーマ検証されたSSOT
- manifest.jsonが唯一の真実の源。スキーマ検証済みで、書き込みはアトミック。
- 改ざん検知可能な監査
- 鍵付きHMACハッシュチェーンと、ワンコマンドの検証。
- 実証済み
- 510件のRustテスト + 86件のフック決定論チェック、すべてグリーン。clippyもクリーン。
$ echo '{"scope":"feature","novelty":true}' \
| bathos --state-dir _state route decide
→ {"recommended_level":2,"requires_confirmation":true}ステークスからレベルを推奨。エンジンが提案し、あなたが確定します。
セッションごとに残る作業レポート
すべての作業セッションは、自己完結型のHTMLレポートで終わります — セッション終了時に自動で書き出され、あるいは /taskreport で必要なときに生成します。ディスクとgitの事実だけで組み立て、でっち上げはしません。
- 自動生成
- SessionEndフックが終了時にレポートを残し、/taskreport はセッション途中でも同じファイルを生成します。
- 固定の6項目
- 開始・終了・合計所要時間、そのセッションの主要な作業、重要な課題、そして git commit・push・PR・merge の全履歴。
- 捏造ではなく事実
- 叙述はセッションの状態から、gitの履歴はリポジトリから取得します。記録がない値は「（未記入）」と表示します。
- 自己完結・連番付き
- 外部リソースなしのHTML一つ。生成時刻と自動で増えるセッション連番で名付けます。
result_report/
├─ task_report_20260716_104150_session_no12.html
└─ … # one file per session, auto-numbered
# on /exit → SessionEnd hook · or run /taskreportセッションごとに一つ、連番で — ビルド全体の紙の記録。
役割ごとに選び、実行をライブで
ウェーブの前に役割ごとにモデルとランタイムを割り当て、実行の様子をライブパネルで追います — リードからキーボードを奪うことなく。
- 役割別モデルプラン
- bathos model set / show / validate が役割 → ランタイム/モデルの割り当てを model-plan.json に記録します。すべてのウェーブがこのSSOTを基準に解決し、プランが無ければ各役割は自身の既定値にフォールバックするため、この機能を一度も使わないプロジェクトはそのままです。
- 六つのランタイム、一つのプラン
- 役割ごとに Claude・Codex・GLM・Kimi・DeepSeek・Qwen を割り当てられます。混在バッチガードが、スポーン前に互換性のない組み合わせを遮断します。
- ライブなWaveパネル
- bathos panes が同じ inspect データの上に、読み取り専用の tmux または内蔵TUIパネルを開きます — 制御・状態・受信箱を横並びに。
- 指示ではなく提案
- パネルの confirm とフィードバックは受信箱にファイルとして溜まります。最終ゲートは依然としてリードのもの — User Sovereignty が保たれます。
$ bathos model set james --runtime claude --model opus
$ bathos model set phillip --runtime codex
$ bathos model validate --wave W5 # mixed-batch guard
→ PASS
$ bathos panes --mode tui --wave W5 # live · read-onlyウェーブの前にモデルを割り当て、実行を見守ります — 読み取り専用、あなたの提案のための受信箱とともに。