開発ライフサイクル全体を通して純粋な評価エンジンとしてClaude Codeを実行する

r/ClaudeAIのある開発者が、ソフトウェア開発ライフサイクル全体（チケット、クロスリポジトリ実装、コードレビュー、MR、永続的なナレッジレイヤー）にわたって、Claude Code（ツール使用とマルチターンループを備えたランタイム）を使用する数ヶ月にわたるセットアップを詳しく説明しました。

主要なアーキテクチャ上の決定: Claude Codeをオーケストレーションから外すこと。プレーンなPythonがすべての機械的な作業（Jira APIコール、git操作、テスト実行、lint、ファイル移動）を処理します。Claude Codeは判断が必要な場合のみ呼び出されます。コードの記述、レビュー結果の評価、アーキテクチャオプションの選択などです。著者は、これらを混在させると（エージェントにツール使用でオーケストレーションさせる）、最初のバージョンが遅く、高コストで、非決定的になると述べています。

1つのチケットの具体的なライフサイクル:

• Pythonオーケストレーター: Jiraチケットを取得し、ローカルWikiで関連するアーキテクチャ決定を検索し、新しいブランチにワークツリーをセットアップし、30〜50行の実装概要（受け入れ基準、対象ファイル、変更された共有関数の呼び出し元、関連する標準）を組み立てます。JSONバンドルを出力します。
• Claude Code: 概要を読み、コードを作成します。これが唯一トークン消費が大きいステップです。
• Python + レビューサブエージェント: テスト、lint、フォーマットを実行します。失敗した場合、実装エージェントに戻します（最大3回の再試行）。次に、編集または書き込み権限なしで設定されたコードレビューサブエージェントを起動します。読み取りと結果の報告のみ可能です。
• Python: ダッシュボードにプロポーザルを作成します。手動承認後、オーケストレーターがプッシュし、MRを作成します。

重要だったClaude Codeの具体的なテクニック:

• サブエージェントの分離。 レビューエージェントは独自のコンテキストウィンドウで実行され、拒否リスト（編集、書き込み）を持ちます。レビューと実装を分割することで、実装エージェントが見逃していた共有コードの動作変更を捕捉できました。
• 事前に組み立てられた概要は動的な探索より優れている。 初期には、Claude Codeに実装前にコードベースを探索させると、Python（Jira取得、Wiki検索、依存関係分析）で組み立てた焦点を絞った概要を与えるよりも明らかに多くのトークンを消費しました。
• スキル/コマンドルーティングをエージェントの判断ではなくYAMLで行う。 /ticket、/review、/standupなどからオーケストレーターへのマッピングは明示的であり、ケイパビリティが創発的ではなく検査可能です。
• フックでコミットをゲートする。 プリコミットフックは、Claude Codeがコミットを試みる前にlintとフォーマットを実行します。違反があるとコミットをブロックし、エージェントが修正する必要があります。

Wikiレイヤー: 3つの信頼度レベル（検証済み、推測、人間提供）とフィールドレベルの陳腐化しきい値を持つMarkdownページ。この階層化がないと、エージェントは自身の過去の推測を真実として扱い、幻覚を増幅して権威ある知識のように見せてしまいます。

まだ取り組んでいる課題:

• クロスリポジトリ機能: 構造化された変更セット追跡があっても、機能が複数のサービスにまたがるとエージェントの一貫性が失われる。
• 曖昧なチケット: エージェントは曖昧な仕様から妥当だがしばしば間違った実装を生成する。著者は現在、曖昧なチケットをブロッカーとしてフラグ付けしている。
• スコープクリープ: 過剰エンジニアリングの傾向には、標準とレビューエージェントによる継続的な調整が必要。
• 長いセッション: 過去のコンテキストが効果的な注意範囲から外れる。セッション開始時の再初期化で緩和されるが、完全には解消されない。