指示出しの手間という新たな技術負債
深夜の障害対応や複雑なタスクの真っ最中、我々エンジニアを最も疲弊させるのはコードを書く作業そのものではなく、作業と作業の間に発生する文脈の分断（コンテキストスイッチ）である。近年のGenerative AIの進化により、コード生成のスピードは劇的に向上した。しかし、開発の現場で我々が直面しているのは、「AIに指示を出すためのコピペと文脈説明の手間」という新たなボトルネックだ。GitHubのIssueを開き、要件をコピーしてAIチャットに貼り付け、生成されたコードを手動でブランチに反映し、別のAIに「レビューしてくれ」とプロンプトを投げる――この一連の反復作業は、まるで人間が手動でメモリスワップを行っているかのような無駄とストレスを生み出している。
単なる便利ツールとしてAIを使う段階はすでに終わったと私は考える。今求められているのは、1日の開発フロー全体を単一の指示から自律的に実行可能な「構造化されたワークフロー（スキル）」へと昇華させることだ。特定の単一リポジトリに依存せず、ユーザーローカルのディレクトリスペース（~/.claude/skills/）に汎用的なスキルを配置するアプローチは、複数プロダクトを並行して抱えるシニアエンジニアにとって極めて実践的な処方箋となる。タスクの起票からブランチ作成、実装、動作確認、コードレビュー、PR作成に渡る泥臭いプロセスをAIにオーケストレーションさせることで、エンジニアは「作業の実行者」から「技術審判」へとポジションを移行できるのだ。
自律駆動を支えるパイプライン設計
1日の開発フローを自動化するスキル todays-work の内部構造は、極めて堅牢に設計されている。主タスクの実行と外部連携（GitHub/Codex/人間）を担う主エージェントに「Claude Code」を据え、コードレビューに特化した従エージェントとして「Codex」を配置するマルチエージェント構造が採用されている。このスキルの核となるのは、作業途中の状態をリポジトリ内に汚染させず、ローカルの ~/.claude/todays-work/<repo名>/issue-<番号>/ に一時保存するサンドボックス思考だ。作業完了時にはこれらが綺麗に破棄（クリーンアップ）されるため、リポジトリの履歴を無駄に汚すデッドロックを防ぐことができる。
本スキルにおける主要な管理ファイルと役割の対応は以下の通りだ。
| ファイル名 | 格納データと役割 |
|---|---|
issue.json / parent-issue.json |
gh issue view や GraphQL API で取得した Issue の生データ。Codex への文脈投入用データとして活用。 |
verification.md |
Claude Code 自らが実行した動作確認の具体的な内容と検証結果のログ。 |
codex-prompt.md / codex.log / codex-review.md |
Codex に送る先入観を排した依頼文、実行時のシステムログ、返還されたレビュー本文。 |
review-decisions.md |
指摘ごとの対応結果（修正コミットのハッシュ、または見送った理由）の論理的記録。 |
パイプラインの冒頭では、作業ツリーに未コミットの変更が存在する場合、git stash push -u -m "todays-work: ..." によって未追跡ファイルを含めて自動退避が行われる。さらに、GitHub GraphQL API を通じて子 Issue や親 Issue の依存関係（P1a, P4 といった接頭辞に基づく作業順序）を解析し、ベースとなるブランチ（develop や先続 PR の headRefName）を自動決定する仕組みは、大規模開発の複雑な依存関係を解きほぐす上で極めて秀逸なロジックと言える。
クロスレビューが生む非バイアスな品質
AIにコードを書かせた際、最も危険なのは「実装を行ったAI自身にレビューを行わせる」ことである。モデル自身の思考の偏りや過学習によって、スパゲッティコードや潜在的バグが見過ごされる自己正当化のリスクが高まるからだ。この課題を破砕するために導入されているのが、Claude Code（実装）と Codex（レビュー）による「非バイアスなクロスレビュー」のメカニズムである。
Codex へのレビュー依頼では、Claude Code が自ら考えた実装理由や言い訳、懸念点をプロンプトから完全に排除し、純粋な git diff <分岐点>..HEAD と raw な Issue 情報（issue.json）のみをテンプレート（codex-prompt.md）経由で渡す。これにより、Codex は一切の先入観を持たずにコードを検証できる。さらに、人間に向けたインタラクティブなレビューツールである crit と Codex の CLI（codex exec -s read-only）を同時にバックグラウンド（run_in_background: true）で起動することで、レビューの並行処理を実現している。
この構成を実際に運用してみると、AIの振る舞いに驚くべき変化が現れる。人間が crit 上でコードをレビューしている間に、バックグラウンドで動くエージェントが「先んじて Pull Request の素案を作成しておきます」と自発的に先回りして作業を進めるのだ。単一の指示に対して全体工程（コンテキスト）を把握しているからこそ可能になるこの自律性は、開発者がこれまで感じていたAIへの指示ストレスを根本から覆す体験となる。
コードを書くエンジニアから統括者へ
近年、テレビ局のITエンジニアや多様な内製化組織のように、限られたリソースで広大なシステム群を運用・開発しなければならない現場が増加している。こうした現場で求められるのは、泥臭く1行ずつコードを打つ職人技以上に、AIエージェントに的確な作業手順（プロトコル）を与え、安全かつ高速に開発を完遂させる「オーケストレーション能力」だ。自らの日常的な開発フローを言語化し、~/.claude/skills/todays-work のような形式でコード化する営みは、まさにAI時代の新たな「メタプログラミング」に他ならない。
我々エンジニアは今、大きな分岐点に立たされている。単にAIチャットにプロンプトを打ち込み、生成されたコードのコピペに追われる「作業者」にとどまるのか。それとも、AI同士を戦わせる品質担保の仕組みや、自律的に動くワークフローを構築する「統括者（アーキテクト）」へと踏み出すのか。明日からの実務に向けて我々が取るべき実践的な処方箋は明快だ。まず自分が今日行った定型作業のログを書き出し、最小単位のスキルとして定義してみることである。貴方はまだ、手動でAIに指示を出し続けるという無限ループの中に留まり続けるつもりだろうか？
コメント