設計を中心に据えた AI コーディング開発プロセス（azukiazusa）— 設計セッション → worktree 並列実装 → 別セッション AI レビュー¶

作成日: 2026-07-19 出典 / きっかけ: azukiazusa「最近の AI コーディングで実践している、設計を中心とした開発の進め方」（著者: azukiazusa〈azukiazusa1〉、2026-07-18、tags: AI / 設計 / claude-code） https://azukiazusa.dev/blog/recent-ai-coding-development-process-centered-on-design/ 関連: dena_職種横断ai活用_sdd_と週次共有会_整理 / sign_off_layer_ai時代の承認とオーナーシップ_整理 / aiコーディング_依存性とバーンアウト_整理 / ai生産性パラドックス_メトリクス起点の改善ループ_整理 / smarthr_aiドリブン開発をチームに定着させた話 / agentic_ai_パフォーマンスエンジニアリング_整理

0. 要点（3行）¶

複数エージェントを並列に走らせる時代の個人開発プロセスの実践記。芯は「実装より設計セッションが最も時間のかかる工程」と割り切り、ゴール・制約・責務・インターフェース・検証内容を人間と AI で先に合意してから、実装は AI に並列で任せること。ファイル単位の編集手順や関数の中身は指定しない。
フローは3段: ①設計セッションでタスク分解 → ②Git worktree で分離した複数セッションが並列実装（Claude Desktop の複数スレッド＋ペイン分割）→ ③PR 作成後に“別セッション”で AI レビュー（実装履歴のバイアスを排除するため実装とレビューのセッションを分ける）。
効かせる土台はスキルや CLAUDE.md より“コードの設計そのもの”。責務境界が明確・依存方向が一貫・変更影響が局所化されたアーキテクチャなら、AI も人も理解・検証しやすい。レビューがボトルネック化する構造には、レビューの階層化・承認の最小化・サンドボックス化で対処する。

1. 全体フロー¶

【設計セッション】人間↔AI で共通理解を作る
   ├ なぜこの変更が必要か / 完成の条件 / ドメイン制約
   ├ コンポーネント間の責務分担 / 検証対象の振る舞い
   └ → タスク分解（設計書は Issue と Markdown に配置）
        │
        ▼
【並列実装】Git worktree で作業ディレクトリを分離
   ├ Claude Desktop の複数スレッド（ペイン分割で同時表示）
   ├ 各セッションがゴール・制約・責務を受け取り自律実装
   └ AI 自身が test / 型 / lint / dev server / ブラウザ / curl で検証
        │
        ▼
【AI レビュー】実装とは“別セッション”で実施（履歴バイアス排除）
   ├ AI: ロジック誤り・テスト不足・可読性
   └ 人間: 要件充足・責務境界・API/データモデル/権限（高リスク）
        │
        ▼
     PR は小さく分割（AI 自身に分割を指示）

設計を中心に置く理由: 複数のエージェントを並行実行すると、人間がすべての操作を監視できない。だから実装前に「何を・なぜ・どこまで」を合意しておくことが、後段の暴走・手戻りを防ぐ最大のレバレッジになる。実装の速さより、実装前の共通理解形成に投資する。

2. 設計セッションで固めること／プロンプト方針¶

設計セッションで言語化する項目: - なぜこの変更が必要か（背景） - 完成の条件（受け入れ条件） - ドメイン上の制約 - コンポーネント間の責務分担 - 検証対象となる振る舞い

AI へのプロンプト方針（重要）: ファイルごとの編集手順や関数内の実装方法は指定しない。ゴール・制約・責務・インターフェース・検証内容に焦点を当てる。「どう書くか」ではなく「何を満たすか」を渡す。→ dena_職種横断ai活用_sdd_と週次共有会_整理の「仕様を一次成果物にする」と同じ発想。

3. 設計書の置き場所 —「意思決定は残し、作業手順は捨てる」¶

置き場所	何を置くか	寿命
GitHub Issue	タスクの進行状況・タスク分解・作業手順	使い捨て（Issue コメント等）
リポジトリ内 Markdown	ADR・設計ドキュメント（AI が参照）	永続

分類原則: 「意思決定（decision）は残す／作業手順（procedure）は捨てる」。ADR や設計判断は残し、タスク分解や進行手順は使い捨てにする。
Issue に紐づけることで、タスクの進行状況と更新履歴を追跡できる。

4. 並列実行の具体 — Claude Desktop × Git worktree¶

Claude Desktop を優先（複数スレッド管理・図表描画）。別々のスレッドで実行し、ペイン分割で複数タスクを同時表示。
Git worktree で作業ディレクトリを物理分離し、並列セッションが互いに干渉しないようにする。
hooks で node_modules のシンボリックリンクを自動生成（worktree ごとの npm install を省く実務ハック）。

5. AI が自律検証できる環境を作る¶

「AI に任せる」を成立させる鍵は、AI 自身が正しさを確認できる手段を揃えること。test / 型チェック / lint に加えて:

開発サーバーを起動して動作確認
ブラウザ操作での確認（Claude Desktop のブラウザ機能）
curl で API レスポンスを検証

検証を速くするツール群（フィードバックループの高速化が並列実行の前提）:

用途	ツール
ビルド/dev server	Vite
テスト	Vitest
Lint	Oxlint（Rust 製・高速）
フォーマット	Oxfmt
型チェック	tsgo（TypeScript の Go ネイティブ移植版。いわゆる "TypeScript 7"）

なぜ速度が要るか: 並列エージェントは検証ループを何度も回す。lint/型/テストが遅いと律速になるので、Rust/Go 製の高速ツールで検証を数秒に縮める。

6. AI レビューは“別セッション”で¶

実装したセッションでそのままレビューさせると、実装履歴のバイアス（自分の書いたものを正当化する）が入る。だから別セッションでレビューする。
レビュー観点の分担:

担当	見る観点
AI	ロジック誤り、テスト不足、可読性
人間	要件充足、責務境界、API・データモデル・権限（高リスク項目）

PR は小さく分割する（AI 自身に「小さく分けて」と指示）。→ レビュー負荷を下げる。

7. CLAUDE.md とスキル体系¶

種類	中身
CLAUDE.md	リポジトリ構造、標準コマンド、プロジェクトの暗黙知、全作業共通の短い原則
プロジェクト固有スキル	検証手順・定型作業
個人スキル	grill-me、コードレビュー等（複数プロジェクトで再利用）

スキル作成のタイミング: セッション完了直後、コンテキストが残っているうちに「今の作業とフィードバックからスキル化して」と指示する（＝作業の“行間”が消える前に型に落とす）。→ smarthr_aiドリブン開発をチームに定着させた話の「暗黙知を配る」と同型。

8. スキル改善より“コードの設計”が効く（記事の核）¶

著者の主張の中心は「スキルや CLAUDE.md をいくら磨くより、コード自体の設計が良いことが最重要」。良い設計とは:

責務の境界が明確
依存方向が一貫している
変更の影響範囲が局所化されている
インターフェースから振る舞いが理解できる
テストが境界を検証している
命名・ディレクトリ構成から探索できる

→ これらは人間にとって読みやすい設計＝AI にとっても扱いやすい設計。AI 時代にこそ古典的な設計原則の価値が上がる、という論。cf. agentic_ai_パフォーマンスエンジニアリング_整理。

人間のスキルの変化（著者の観察）: - 失うもの: 特定構文の暗記、細かな実装パターン、局所的な美しさへの注意 - 得るもの: システム全体の俯瞰、責務・依存関係・統合整合性の考慮 - 留保: 過去の実装経験と失敗が、今の設計能力を支えている（＝下積みを飛ばして設計だけできるわけではない）

9. レビューのボトルネックと承認の最適化¶

Addy Osmani の指摘（著者が引用）: 「コードレビューが機能してきたのは、相対スピードの偶然にすぎない。ベテランはジュニアより速く読めるからペースに追従でき、システム理解も進んだ。だがそれは意図した設計ではなく、『コードを書くのは高コスト・読むのは低コスト』という事実から生まれた副産物だった」。AI が書く量を激増させると、この前提が崩れてレビューが律速になる。

対策: - コードレビューを階層化する（すべてを同じ粒度で見ない） - 人間は設計・高リスク項目に集中、個別実装は AI＋自動検証に任せる - PR を小分割する

承認メカニズムの最適化: - サンドボックス環境で被害を最小化（危険な操作をしても壊れない箱の中で動かす） - Claude Code の Auto mode、Codex の「代理承認」機能 - AI 自身に承認の要否を判断させる - 注意: 承認対象が増えると承認疲れで精度が落ちる → 「何に承認を出すか」を絞る。cf. sign_off_layer_ai時代の承認とオーナーシップ_整理。

モデル選択: 現状は高性能モデルで統一（設計誤りがカスケードすると高くつくため）。選択軸はトークン単価ではなく「変更が完成するまでの総コスト」。将来は従量課金・並列時のコスト最適化・effort level の組み合わせが課題。

10. 「AI 中毒」への警告¶

著者は生産性論の裏で、依存の兆候にも触れる: - サブスクの時間リミットを使い切らないことへの罪悪感 - AI が動いていない時間を「生産性が落ちている」と感じる観念 - 非決定的な結果へのギャンブル的快感（ドーパミン報酬） - 稼働率の向上そのものが目的化するリスク

対策は「何をさせるか」と同時に「何をさせないか」を判断すること。→ aiコーディング_依存性とバーンアウト_整理と同じ問題意識。

11. まとめ — 状況 → この記事の打ち手（早見表）¶

局面	この記事の答え
何に時間を使うか	実装ではなく設計セッション（ゴール・制約・責務・検証を合意）
AI への指示の粒度	手順ではなくゴールと制約を渡す（どう書くかは任せる）
設計書をどこに	意思決定は Markdown（永続）／手順は Issue（使い捨て）
並列で回すには	Git worktree ＋ Claude Desktop 複数スレッド、hooks で環境準備を自動化
AI に任せきるには	AI が自律検証できる環境（test/型/lint＋dev server/ブラウザ/curl、高速ツール）
レビューが詰まる	別セッションで AI レビュー、階層化、PR 小分割、人間は高リスクに集中
承認が重い	サンドボックス＋承認の最小化、AI に要否判断させる、承認疲れを避ける
何より効くのは	スキルより“コードの設計”（責務境界・依存方向・局所性・テスト）

一言で: AI 時代の開発は「書く速さ」ではなく「設計と検証の設計」の勝負。人間は設計セッションと高リスクの承認に集中し、実装・個別検証・一次レビューは AI に並列で回させ、その全体を良いアーキテクチャが支える。

注意・留保¶

本記事は azukiazusa 個人の実践エッセイ（一次体験）。定量的な効果測定は示されておらず、プロセスの提案である。
ツール（tsgo/Oxlint/Oxfmt/Claude Desktop の Auto mode・ブラウザ機能、Codex の代理承認）はいずれも実在するが、バージョン・正式名称・利用可否は各自の環境で要確認。「tsgo＝TypeScript 7」は通称。
Addy Osmani の引用は著者経由の要約。原文のニュアンスは原典で確認するのが望ましい。

参考リンク¶

azukiazusa: 最近の AI コーディングで実践している、設計を中心とした開発の進め方（2026-07-18） — https://azukiazusa.dev/blog/recent-ai-coding-development-process-centered-on-design/
github/spec-kit（Spec-Driven Development の公開ツールキット・関連参照） — https://github.com/github/spec-kit
METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（設計・検証の重要性の裏付けとして） — https://arxiv.org/abs/2507.09089

作成: 2026-07-19 ／最終更新: 2026-07-19