素の CLI コマンドから信頼できる AI エージェントワークフローへ¶
Quick Answer: 信頼性は、コマンド列の周囲に境界を置くことで生まれます。依頼を分類し、最小のルートを選び、編集を保護し、再開に価値がある作業だけを保存し、検証証拠で結果を確認します。Harness CLI はこの境界を提供しますが、読み取り専用の質問まで重い計画にはしません。
Shell alias は AI コーディングクライアントを起動できます。しかし、編集して安全か、前回の試行を再開すべきか、成功したコマンドが変更範囲を本当に検証したかは説明できません。素の CLI ラッパーと信頼できるワークフローの差は、実行を囲む契約にあります。
重要な 5 つの境界¶
1. 入力境界¶
依頼を明確な目標に変換し、質問、調査、小さな変更、複数ステップの目標を分けます。空入力や確認だけで作業項目を作りません。
2. ルート境界¶
クライアントや playbook を選ぶ前に noop、direct、guarded、planned を選びます。プロセスをリスクに比例させるためです。
3. 編集境界¶
ファイルを作成・変更する前に、影響範囲、依存関係、スタイル、テストカバレッジを確認する pre-edit-safety-gate を通します。コードグラフが使えない場合は、対象を絞った検索と既存テストを明示的なフォールバックとして使います。
4. 状態境界¶
継続する価値がある場合だけ計画を保存します。プロジェクト registry は利用可能なコンテキストを示しますが、すべての prompt に全履歴を自動注入するものではありません。再開時は選択した task と handoff だけを読みます。
5. 証拠境界¶
変更範囲に合ったチェックを実行し、何を証明するかを報告します。ビルド成功はビルドを証明するだけで、外部ブラウザ、モデル provider、人的承認の可用性までは証明しません。
具体的な移行パターン¶
古いフローが次のようなものだとします。
claude "update the docs"
git diff
これでは未回答の点が多すぎます。次の契約に置き換えます。
- 対象となる公開面と言語を明示する。
- コンテンツ、ナビゲーション、テストにまたがるなら
plannedに分類する。 - ファイルの所有範囲と受け入れチェックを含む計画を書く。
- 各編集バッチの前に
pre-edit-safety-gateを実行する。 - 生成ディレクトリをソース変更に含めない。
- コンテンツ契約、サイト同期、strict build を実行する。
- 正確な検証結果と未確認の外部依存を記録する。
具体的なコマンドはプロジェクトごとに違っても、順序は再利用できます。Codex CLI、Claude Code、Gemini CLI、OpenCode、Grok Build などへ移行しやすい理由です。
ブラウザ作業を明示する¶
ブラウザ自動化でも、同じように状態を隠さないことが重要です。
- 対象 profile で可視 CDP ブラウザを起動する。
- 接続する。
- semantic snapshot またはテキストを読む。
- 一つの可視アクションを実行する。
- 状態変化を待ち、ページを読み直す。
- 認証画面と機微な外部送信は人が管理する。
これによりブラウザ工程を監査でき、設定済み MCP と成功した live session を混同しません。
コンテンツ契約で公開ドキュメントを守る¶
公開プロダクトの一部である文書にもテストが必要です。例えば次を契約にできます。
- すべての P0 ページが対応言語に存在する;
- 多言語ナビゲーションが存在するファイルだけを指す;
- index がプロモート記事にリンクする前に記事が存在する;
- 古い主張は削除するか compatibility と明記する;
- docs と blog の strict MkDocs build が通る。
小さく高速なチェックは、文面が頻繁に変わる SEO/GEO 作業でクロール可能な構造を守ります。
FAQ¶
これは CLI にプロジェクト管理を足すだけですか？¶
いいえ。ルート分類、編集安全、コンテキスト選択、検証という実行可能なチェックと状態規則です。エージェントが不可逆な判断をする箇所の曖昧さを減らします。
すべての transcript を保存すべきですか？¶
いいえ。安定した事実、選択した作業項目、有用な handoff だけを保存し、必要なときに pull します。
最小の改善は何ですか？¶
ルート表、編集前チェック、検証チェックリストから始めます。復旧や独立した所有が必要になった場合だけ solo harness やチームを追加します。
アーキテクチャ、ContextDB、ワークフローポリシーも参照してください。