この記事は、AIコーディングエージェントを実際の機能開発に使っている人向けです。
次のような問題を感じたことはないでしょうか。
- 要件が固まる前にエージェントが実装を始める
- 要件がチャット履歴の中に埋もれる
- 実装したセッションが、そのまま自分の実装をレビューする
- 複数の変更とターミナルを人間が覚えて管理する
- プロセスは終了したが、本当に検証まで完了したのか分からない
ithynoは、OpenSpecに基づく変更を可視化し、実装・レビュー・検証をロール別のAIセッションへ割り当てるOSSです。
デスクトップアプリまたはVS Code拡張と、OpenSpec Skills・ithyno Skillsで構成されています。
まず、実装前に変更内容を決める
ithynoのワークフローはOpenSpecを土台にしています。
OpenSpecは、AIコーディングアシスタント向けの軽量な仕様駆動開発フレームワークです。
チャットの指示だけを要件にせず、実装前に「何を変更するか」をリポジトリへ記録します。
プロンプト → 実装 → 意図どおりか後から確認
ではなく、次の順序で進めます。
期待する動作を合意 → 変更を計画 → 実装 → レビュー → 検証
OpenSpecでは、現在合意されている動作と、これから行う変更を分けて管理します。
-
openspec/specs/：現在合意されているシステムの動作 -
openspec/changes/<change-id>/：提案中または実装中の変更 -
proposal.md：変更する理由と内容 -
tasks.md：実装するタスク -
specs/：追加・変更する要件 -
design.md：必要に応じた設計上の判断
openspec/changes/<change-id>/
├── proposal.md
├── design.md
├── tasks.md
└── specs/
完了したChangeは、現在の仕様へアーカイブできます。
1つのChangeをロール別に割り当てる
OpenSpecは変更内容を定義します。
ithynoは、そのChangeを別々のロールへ渡します。
OpenSpec Change
│
├── code → タスクを実装する
├── review → 実装と仕様を比較する
└── verify → プロジェクトの検証を実行する
各ロールは同じChangeを読みます。
ただし、担当する判断は異なります。
code
proposal、要件、tasksを読み、要求された変更を実装します。
review
実装を続けるのではなく、差分がproposalと要件を満たしているか確認します。
verify
そのプロジェクトで利用できるテストやビルドを実行し、結果を記録します。
この分離により、実装時の思い込みをそのままレビューへ持ち込みにくくなります。
複数エージェントを指定する
ロールを分けるために、ClaudeとCodexを混在させる必要はありません。
例えば、次の構成が可能です。
- Claude Sonnetをcode、Claude Fableをreviewへ割り当てる
- Codex GPT-3.5-miniをcode、GPT-5.6-Terraをreviewへ割り当てる
- AGYからClaude Sonnet 4.6をcode、Gemini 3.1 Proをreviewとして呼び出す
- Claude Sonnetをcode、Codex GPT-5.6-Terraをreviewへ割り当てる
同じモデルを使う場合も、codeとreviewを別のセッションとして起動できます。
モデル名や利用可否は、各CLIの更新によって変わることがあります。
重要なのはベンダーの数ではありません。
役割とセッションを分離することです。
ithynoで設定する
基本的な流れは次のとおりです。
- 使用するAIエージェントCLIをインストールし、認証する
- ithynoの Settings → Prerequisites でCLIを確認する
- 各CLIへOpenSpec Skillsとithyno Skillsをインストールする
- Agents画面でManagerとWorkerを登録する
- Workerへ
code、review、verifyのロールを割り当てる
ManagerはChange全体を進行します。
Workerは必要なステージで起動されます。
設定はプロジェクトルートのagents.yamlへ保存されます。
CLIの組み合わせや設定項目は、複数エージェントを設定してDispatchするで確認できます。
ChangeをDispatchする
ダッシュボードでChangeを作成した後、StartからDispatchできます。
ithynoは、起動したManagerターミナルへdispatchコマンドを自動入力できます。
表示されたChange IDやコマンドをコピーして、自分で貼り付けることもできます。
Manager CLIは、インストール済みのithyno dispatch Skillを呼び出します。
クライアントによって、コマンド形式が異なります。
/ithy-opsx:dispatch add-session-timeout
または次の形式です。
ithy-opsx-dispatch add-session-timeout
1つのChangeでは、ステージを順番に実行します。
proposed → code → review → verify → merge / archive
別々のChangeは、Git worktreeへ分離して並行実行できます。
終了コードではなく成果物で判断する
AIエージェントCLIの終了コードが0でも、要求された作業が完了しているとは限りません。
そのためithynoは、標準出力だけで成功を判断しません。
reviewとverifyは、Change内へ構造化されたreview.mdを書きます。
---
verdict: needs-rework
summary: "必須のエッジケースが未実装です。"
findings:
- severity: high
file: src/auth.ts
line: 42
message: "トークンの有効期限検証がありません。"
---
Managerはこの成果物を読みます。
passなら次のステージへ進みます。
needs-reworkなら、指摘をcode Workerへ戻します。
これにより、次の証拠がリポジトリに残ります。
仕様 → 実装差分 → レビュー結果 → 検証結果
ithynoが担当する範囲
ithynoはOpenSpec、Git、AIエージェントCLIを置き換えるものではありません。
- OpenSpecが変更内容を定義する
- AIセッションがロール別の作業を行う
- Git branchとworktreeが実装を分離する
-
review.mdがレビューと検証の結果を残す - ithynoが全体を可視化して進行をつなぐ
デスクトップアプリとVS Code拡張は、どちらも同じリポジトリ内のファイルを使用します。
現在の状態と試し方
ithynoは現在alpha版です。日本語対応予定
AIエージェントCLIの引数、権限、子エージェント機能は変化が速いため、対応状況はドキュメントで更新しています。
試す場合は、次の順に進めてください。
最初から複数ベンダーを用意する必要はありません。
まず1つのOpenSpec Changeを作ります。
次に、実装とレビューを別のセッションへ分けるところから始められます。
不具合や対応してほしいCLI構成があれば、GitHub Issuesへお知らせください。