# 最近の AI コーディングで実践している、設計を中心とした開発の進め方 以前「[AI と本音トーク：エンジニアの仕事、これからどうなる？](https://azukiazusa.dev/blog/ai-talk-what-will-happen-to-engineers/)」という記事で、AI コーディングエージェントを利用するようになったことで、コードを書く時間が減り、設計について考える時間が増えたと書きました。その後、AI モデル自身の性能やエージェントを動かすハーネスがさらに改善され、複数のエージェントを並行して動かすことが日常になりました。この傾向は以前よりもさらに強くなっていると感じています。 現在では、自分でコードを書くことはほとんどありません。だからといって、ソフトウェア開発に使う時間が減ったわけではありません。むしろ、AI と設計について議論したり、タスクを独立して実行できる単位に分割したりすることに多くの時間を使うようになりました。実装そのものよりも、実装前の設計セッションが開発の中で最も時間のかかる工程になっています。 この記事では、最近の私が AI を使った開発でどのように設計と実装を進めているのかを紹介します。また、この変化によってコードレビューの方法やエンジニアに求められる能力をどのように捉えるようになったのかについても考えます。 ## 最近の AI コーディングの流れ 現在の開発の流れを図にすると、以下のようになります。 ![設計セッションでタスクを分解し、Git worktree で分離した複数のセッションが並列に実装と検証を行い、PR ごとに AI レビューを実施する開発フローの全体図](https://images.ctfassets.net/in6v9lxmm5c8/1UDHWTaX30T71Tvi7RCa5p/c17c836b89fb7a59ac87dcc0e24dcfc7/Git_Worktree_Issue_Lint_Flow-2026-07-17-123656.svg) 重要なのは、最初に全体を見据えた設計を行い、タスクを独立して実行できる単位に分解することです。はじめに設計セッションを行い AI と共通理解を形成することにより、AI を並行して動かしたとしても、それぞれのタスクが設計上の意図を保ったまま実装されることを期待できます。 並列実行のために、人間がすべての操作を逐一承認するのではなく、AI がこのフィードバックループを自律的に回せるようにすることが重要です。その分、人間は実装前の設計や、データモデル・責務の境界といった影響の大きな判断に多くの時間を使うようになりました。AI が自律的にタスクを完了できるようになるほど、設計の重要性が増していると感じています。 ## 詳細な手順ではなくゴールを共有する AI にタスクを依頼するとき、最初のプロンプトではファイルごとの編集手順や関数内部の実装方法まで細かく指定しないようにしています。詳細な手順を渡しすぎると、AI はその手順を正確に実行することへ集中し、人間が思いつかなかったより良い方法を提案する機会が失われてしまうためです。 一方で、何も指定せずに「いい感じに実装して」と依頼するわけでもありません。後述する [grill-me](https://github.com/mattpocock/skills/blob/733d312884b3878a9a9cff693c5886943753a741/skills/productivity/grill-me/SKILL.md) スキルなどを使用して、AI と設計やデザインについて共通理解を得られるまで徹底的にインタビューを実施するという手順を踏みます。特に以下のような点について議論すべきです。 - なぜこの変更が必要なのか - 何を満たせば完成なのか - ドメイン上、壊してはいけない制約は何か - コンポーネント間の責務をどのように分けるか - どのような振る舞いを検証できれば正しいと判断できるか ここで区別したいのは、設計を詳細にすることと、作業手順を詳細に指示することです。ゴール、制約、責務の境界、インターフェース、検証すべき振る舞いについては、実装を始める前に十分に議論します。しかし、どのファイルから編集するか、関数の内部でどの構文を使うかといった局所的な実現方法は AI に委ねます。 例えば TypeScript で `interface` と `type` のどちらを使うかや、`let` を避けるために三項演算子を使うかといった選択は、以前ほど気にしなくなりました。それよりも、その型をどのレイヤーが所有するのか、変更による影響をどこまで局所化できるのかといった、全体の整合性を重視しています。 ## 実装前の設計セッションに時間を使う AI が自律的にタスクを完了できるようになるほど、実装前に人間と AI の間で共通理解を形成することが重要になります。複数のタスクを並行して実行していると、人間がそれぞれのエージェントの動きを監視し続けることはできません。認識のずれが残ったまま実装を始めると、ずれに気づくのはすべての作業が終わった後になってしまいます。 そこで、実装前には「[実装前に設計を徹底的にインタビューし、要件を明確にするためのスキル `/grill-me`](https://azukiazusa.dev/blog/before-implementation-interview-design-requirements-grill-me/)」などを使い、AI との設計セッションを行っています。AI から設計に関する質問を 1 つずつ受け、設計ツリーの分岐を順番に解決していきます。 設計セッションでは、AI の提案に対して受け身にならないことが重要です。AI が提示した推奨案に毎回「OK」と答えるだけでは、設計を AI に任せていることと変わりません。自分の中にあるドメイン上の制約や、既存のアーキテクチャを選んだ理由、提案に対して感じた違和感を言語化して伝える必要があります。 この工程では、従来のソフトウェアエンジニアリングで身につけた能力がそのまま使われます。責務をどのように分けるべきか、依存関係をどちらへ向けるべきか、将来の変更に対してどこまで拡張性を持たせるべきかといった問いに、AI の提案を材料にしながら人間が判断します。何も考えていない状態から、AI が魔法のように設計を作ってくれるわけではありません。 ### 設計書をどこに置くか 設計セッションには多くの設計判断が含まれており、複数の実装セッションから参照できる価値の高いコンテキストになります。そのため、設計の結果をチャットの履歴だけに残さず、別のドキュメントとして整理することが良いのではないかと考えています。この設計書をどこに配置するかについては、まだ試行錯誤しているところです。現時点では GitHub の Issue チケットのコメント欄に設計書を置くことが多いです。Issue チケットはタスクの進行状況と紐づいており、設計書の更新履歴も残るため、設計判断の経緯を追いやすいという利点があります。一方で AI が参照しやすいように、設計書を Markdown ファイルとしてリポジトリに置くという方法もまた魅力的です。 一方で、実装時にだけ必要な作業手順まですべて永続的なドキュメントとして残すと、更新されない設計書が増えてしまいます。現時点では、設計書を以下の 2 種類に分けて考えるのがよいのではないかと考えています。「意思決定は残し、作業手順は使い終わったら捨てる」という考え方です。 - 長く残る設計判断は、ADR や設計ドキュメントとして永続的に残す - 今回の実装だけに必要なタスク分解や進行手順は、Issue のコメントなど使い捨てられる場所に置き、実装が終わったら捨てる ## 設計書をもとに複数のタスクを並列実行する 設計が完了したら、独立して実行できる単位にタスクを分解します。私は CLI よりも Claude Desktop を好んで使っています。複数のスレッドの状態を一覧しやすく、設計と実装のセッションを分離したり、バックグラウンドで実行しているタスクの状態を確認したりしやすいためです。また、こうしたデスクトップアプリの多くは図表を描画する機能を持っており、設計の議論を視覚的に確認できる点も CLI より優位に感じています。 ![](https://images.ctfassets.net/in6v9lxmm5c8/GdRi2PbJy6MToh5nUPsPC/cdee0b9be97fb2276b8f41057b232318/image.png) それぞれのタスクは Git worktree を使って作業ディレクトリを分離し、Claude Desktop の別々のスレッドで実行します。デスクトップではペインを分割して複数のスレッドを同時に表示できるため、タスクの進行状況を一覧しやすくなります。安全に独立させられるタスクの境界を見つけること自体が、設計の一部です。責務が適切に分割され、変更の影響範囲が局所化されているコードベースほど、複数のエージェントへタスクを分配しやすくなります。 Git worktree をうまく AI が使える環境を整えることが、並行作業の効率向上にもつながります。例えばよくあるのは、チェックアウトした worktree に `node_modules` が存在せず、AI が依存関係を解決できないという状況です。AI は依存関係の解決に失敗すると、エラーの原因を特定するために複数回の試行を繰り返すことになります。これを避けるために、worktree を作成した時点で依存関係が解決されるようにしておくことが重要です。具体的には、Claude Code では hooks で worktree 作成時に処理を挟めるので、ここで `node_modules` のシンボリックリンクを作成するようにしています。 個別にセッションを開始するのが手間であると感じるなら AI 自身にタスクを分割させて実行させるのも良いでしょう。「設計書を元に実行可能なタスクに分割し、タスクごとにサブエージェントを起動して並行して実行してください」といった指示を与えると、AI 自身がサブエージェントを管理監督し、実装からレビューまでを自律的に行ってくれます。このような自律的なタスクの分割ができるのも、設計セッションでゴールや制約を明確にしているからです。 ### モノレポと AI コーディング AI との設計では、フロントエンド、API、インフラストラクチャの設定など、複数の領域を横断して調査することが多くあります。この点では、必要なコードが同じリポジトリに置かれているモノレポに利点があると感じています。AI が依存関係や既存の実装パターンを一度に探索でき、複数の実装セッションが同じ設計書や検証コマンドを参照できます。横断的な変更の影響範囲を調査したうえで、どの境界でタスクを分割するか考えやすいことも利点です。 普段の開発ではポリレポ（複数のリポジトリに分かれている構成）で運用しているのですが、別のリポジトリへの相対パスをプロンプトで示しながらセッションを開始するという小技をよく使用しています。例えば、フロントエンドの実装を行うセッションでは、API リポジトリへの相対パスとその中にある設計書の場所を示すといった具合です。最近は複数のリポジトリを横断するセッションを行うことが多くなりすぎて、リポジトリを間違えてセッションを開始しても AI が「恐らく別のリポジトリの話をしているな」と解釈してくれてよしなにやってくれることが多い、という笑い話もあります。 ## AI が自律的に検証できる環境を整える AI に自律的に実装を任せるためには、AI が自分の変更に対してフィードバックを得られる環境が必要です。期待する振る舞いを満たしていることを AI 自身が確認し、フィードバックを得られる環境を整えることが重要です。 私の普段の開発ではテスト・型チェック・Lint といった静的チェックに加えて、開発サーバーを起動した状態での実動作の確認までを自律的に行えるようにしています。例えば、フロントエンドの変更であればブラウザを操作し、API の変更であれば `curl` でリクエストを送信してレスポンスを確認します。期待する振る舞いは設計段階で決めておき、開発サーバーの起動方法やブラウザ・API を使った確認の基本手順は、プロジェクト固有のスキルとして手順化します。AI は設計書をもとに何を確認する必要があるかを判断し、スキルに従って実際に検証します。 言語モデル単体ではブラウザを操作できないため、操作ツールを接続する必要があります。私は普段 Claude Desktop のブラウザ操作機能を使っています。あらかじめブラウザ操作のために必要なツールが一式揃っており、デスクトップアプリでブラウザが動作するので、今何が行われているのか確認しやすいところが気に入っています。 AI が変更してから成否を判断できるまでの時間を短くすることが重要です。例えば開発サーバーの起動やテストの実行に時間がかかれば、それだけフィードバックループが遅くなります。ローカルでの検証や CI 環境の速度向上といったタスクには、今まで以上に本気になって取り組むと良いでしょう。最近 TypeScript プロジェクトではいわゆる [Vite+](https://viteplus.dev/) スタックと呼ばれるツールチェインが高速化に貢献しており、私も積極的に採用しています。 - Vite - Vitest - Oxlint - Oxfmt - tsgo（TypeScript 7） 開発サーバーの起動、テスト、ブラウザ操作といったフィードバックループは、AI が使うモデルやプロンプトと同じくらい重点的に改善すべき対象だと考えています。 ## PR を作成したら別のセッションで AI レビューを行う 実装が完了して PR を作成したら、必ず `review` や `code-review` といったコマンドを使い、AI にコードレビューを依頼しています。このとき、実装を担当したセッションにそのままレビューさせるのではなく、別のセッションで実行します。実装を行ったセッションは自分の変更を正当化する方向にバイアスがかかりやすいため、実装の経緯を知らないまっさらなコンテキストでレビューさせる方が、問題を見つけやすいと感じているためです。最近では PR をトリガーとして動くレビュー AI を何かしら用意しているプロジェクトが多いのではないでしょうか。 AI によるレビューは、論理的なロジックの誤りやテストカバレッジの不足、局所的な可読性の低さなどを探す一次チェックとして役立つことがあります。AI がレビューするとしても、人間がコードをまったく確認しないわけではありません。また、AI に任せるレビューの範囲は変更の影響度によって変わります。認証、決済、個人情報、データ移行など、誤りが大きな影響を及ぼす変更では人間による重点的な確認が必要です。ただし、すべての行を同じ注意力で読むことはしなくなりました。人間と AI でレビューの観点をどのように分担するかについては、後述の「実装の次にレビューがボトルネックになる」で詳しく述べます。 ## `CLAUDE.md` やスキルの整備 AI がプロジェクト固有の知識を参照できるように、`CLAUDE.md` や Agent Skills を整備することも重要です。私はそれぞれの役割をおおむね以下のように分けています。 - `CLAUDE.md` にはリポジトリ構造、標準コマンド、プロジェクトの暗黙知、すべての作業で参照する短い原則を記載する - プロジェクト固有のスキルには、検証手順や定型作業など、複数のタスクで再利用できる作業パターンを記載する - 個人のスキルには、`grill-me` やコードレビューなど、複数のプロジェクトで再利用できる作業パターンを記載する 同じ指示をプロンプトで何度も繰り返しているのであれば、`CLAUDE.md` やスキルへ移すことで作業を安定させられます。私がよくやっているのは、ハーネスが整備されるまでエージェントの動作をよく観察することです。会話、ツール呼び出し、参照したファイル、実行結果がログに残るので、どの箇所を実装しようとした時に迷いがあったのかを確認できます。この迷いが生じた箇所が、`CLAUDE.md` やスキルに追記すべき箇所です。 スキルを作るときはそのセッションの中で「今行った作業と私からのフィードバックを元に次回から実行できるスキルとしてまとめてください」といった指示を出すと便利です。AI 自身にある程度スキルを作成する能力が備わっていますし、タスクの完了直後ならコンテキストが残っているので、スキルの作成に必要な一次情報が揃っている状態です。 ある程度 `CLAUDE.md` やスキルが整備されてくると、AI に自律的にタスクを任せるようにします。これは結構人間のマネジメントに似ていて面白いです。新入社員が入ったら最初は細かく指示していますが、ある程度仕事の進め方を理解したら、あとは自律的に任せるようになります。 しかし、指示文を改善し続ければ、コードベースの問題をすべて解決できるわけではありません。 例えば「この依存方向を守る」と `CLAUDE.md` に書き続けるよりも、パッケージの境界をコード上で明確にしたり、Lint ルールによって違反できないようにしたりする方が確実です。責務が絡み合い、1 つの変更が多くのファイルへ波及するコードは、スキルだけでは AI にとって扱いやすくなりません。AI は基本的に既にあるコードを探索して、既存のパターンに従って変更を加えることが得意です。コードベースのアーキテクチャが不明瞭であったり責務が絡み合っていたりすると、AI はどこから手をつけるべきか迷います。その結果、変更の影響範囲を正しく把握できず、不整合な変更を行う可能性があります。ガベージインガベージアウトではないですが、良くないアーキテクチャでは良くないコードが再生産されやすくなります。 AI にとって扱いやすいアーキテクチャに、まったく新しい原則が必要なわけではないと考えています。 - 責務の境界が明確である - 依存方向が一貫している - 変更の影響範囲を局所化できる - インターフェースから振る舞いを理解できる - テストによって境界の振る舞いを確認できる - 命名やディレクトリ構成から必要なコードを探索できる これらは以前から、保守しやすいソフトウェアのために重要だと言われてきた性質です。そして同じ性質が、AI がコードベースを探索し、独立したタスクへ分解し、自律的に検証するうえでも役立ちます。`CLAUDE.md` やスキルの改善は有効ですが、結局のところコード自身のアーキテクチャが最も重要であることは、以前から変わっていません。 ## コードを書く能力と全体を見る能力 AI コーディングを使い始めた初期の段階から、たとえ自分の方が良いコードを書ける場合でも、コードを書く役割を AI に渡す必要があると感じていました。人間は AI のタイピング速度に勝てないためです。人間が自分で書いた方が早いと考えて毎回コードを書いていては、AI に実装を任せるための設計や検証環境を改善する機会も得られません。 現在では、実際に自分の手でコードを書くことはほとんどなくなりました。その結果として、コードを書く能力の一部が衰えている感覚はあります。特定の構文や細かな実装パターンを思い出す機会は減りましたし、局所的なコードの美しさへ注意を向けることも少なくなりました。 一方で、システム全体を俯瞰し、責務の境界や依存関係、複数の変更を統合したときの整合性について考える機会は増えました。能力が単純に向上したというより、どこに注意力を配分するかが変化したと捉えています。 ただし、現在使っている設計能力も、過去に自分でコードを書き、失敗してきた経験に支えられています。最初から細かな実装をすべて AI に委ねた場合に、同じような設計判断の能力を身につけられるのかはわかりません。若手の育成や学習方法については、別の大きな問題として考える必要がありそうです。 ## 実装の次にレビューがボトルネックになる 既に散々言われていることですが、AI が自律的に実装できるようになると、コードレビューがボトルネックになります。 AI が複数の PR を同時に作成しても、人間が 1 つずつ従来と同じ粒度でレビューするのであれば、そこで待ち行列が発生します。Addy Osmani 氏の記事「[Agentic Code Review](https://addyosmani.com/blog/agentic-code-review/)」に出てくる以下の一節が現状をよく表していると感じます（引用は日本語に意訳しています）。 > コードレビューがうまく機能していたのは、相対的なスピードという偶然の産物だった。ベテランエンジニアはジュニアエンジニアよりも速くコードを読むことができたため、レビューは意図せずともペースに追いつき、チームは互いの差分を読むことでシステムの仕組みを自然と理解していった。その多くは意図的なものではなく、コードを書くのは時間がかかりコストもかかる作業であり、それを読むのは安価で速い作業であるという、たった一つの事実から生まれたものだった。 産業革命が起これば、当然に、人間の仕事のやり方は変わります。従来のコードレビューの方法も限界を迎えているのではないかと多くの人が思い始めているのではないでしょうか。一方で人間がまったくコードを確認しなくてもよくなるほど AI に信頼を置くことはできません。責任を取るのは人間です。1 つの解決の道筋は、コードレビューを階層化して考え、人間は高リスクな変更や全体の設計をレビューし、個々の実装は AI レビューと自動検証を中心に通す方法です。 前述の通り、AI によるレビューは論理的なロジックの誤りやテストカバレッジの不足、局所的な可読性の低さなどを探す一次チェックとして役立つことがあります。人間はこのような局所的なレビューに時間を使うのではなく、要件を満たしているか、責務の境界が設計と一致しているか、API・データモデル・権限など高リスクな変更に問題がないかに重点的に注意を払うようにします。さらに一歩進めて、実装前の全体設計を人間どうしで相互にレビューしておくという方法も考えられます。合意が取れた設計を元に AI が個別の実装を行い、個々の実装は AI レビューと自動検証を中心に通します。この手法であれば、人間は設計の整合性や高リスクな変更に集中でき、AI は局所的な実装の品質確認を補助できます。設計という参照元があれば実装の逸脱を検出しやすくなりますが、明文化されていない要件や設計自体の誤りは別途確認する必要があります。 PR を小さく分割することも、レビューによるボトルネックを減らすための有効な手段です。PR の差分が大きくなればなるほど、レビューを行う人間の負担も増え、注意力も散漫になるというのは AI が登場する以前からよく指摘されていた事実です。AI エージェントは一気に大きな変更を加えることができるため、何も意識しなければ、PR の差分が大きくなりがちです。おすすめの方法は AI 自身に PR を小さく分割するように指示することです。どういう観点で PR を分割すればよいか相談しながら進められますし、少々複雑な git 操作も任せられます。 最後に、PR の変更はあなた自身が説明できるようにしてください！レビュワーに説明のコストを押し付けるようなことがあってはいけません。AI が作った PR であっても、あなた自身が設計の意図や変更の理由を説明できるようにしておくことが重要です。 ## 承認を最小限に設計する エージェントがコマンドを実行したり、コードを編集したりするたびに人間の承認を求める設定では、自律的なフィードバックループを回せません。また承認を要求する操作を増やせば増やすほど、AI による操作が安全になるわけではないという点に注意を払う必要があります。人間が承認すべき対象が増えれば増えるほど、いわゆる「承認疲れ」が起こり、承認の精度が下がります。人間はだんだんと無意識に承認するようになり、本当に承認が必要な操作を見逃す可能性が高くなります。 承認を最小限にするためにサンドボックス環境を整えることが重要です。AI が動作する環境をサンドボックスに隔離することにより、万が一 AI が誤った操作をして重要なファイルを削除してしまったとしても、被害を最小限に抑えられます。また最近では [Claude Code の Auto モード](https://code.claude.com/docs/en/permission-modes)や [Codex の「代理で承認」](https://openai.com/index/running-codex-safely/)のように、AI 自身に承認が必要な操作かどうか判断させる機能も出てきています。これはすべての承認をスキップするのではなく、機密データの漏洩や重要なファイルの削除・悪意のあるコードの実行などの操作を分類器が検出した場合のみ、ブロックを試み、それでも操作を続けようとした場合に人間の承認を要求するという仕組みです。AI が自律的に判断できる範囲を広げることは、承認疲れを防ぐためにも重要です。 [『我ら、プログラマー Ada から AI まで、コーダーたちの年代記』](https://www.hanmoto.com/bd/isbn/9784049012026)では、プログラミングの初期には、現在ならループや条件分岐として記述する処理にも人間が随時介入していてプログラムを実行し直す必要があったという話が紹介されています。人間が AI のコード生成を逐一監視する状態から、一定の範囲を自律的に実行させる状態への移行には、これと似たところがあるように感じます。 ## モデルのコストと性能の選択 現在は、ほぼ常にその時点で利用できる高性能なモデルを使っています。どのタスクを安価なモデルへ任せられるかを人間が分類する手間や、能力が不足したモデルによって手戻りが発生する可能性を考えると、今のところは高性能なモデルへ統一する方が扱いやすいためです。特に設計を誤ると、その後に並列実行するすべてのタスクが間違った方向へ進むため、設計セッションでモデルの能力を節約することは避けています。 しかし、この方法を今後も続けられるかはわかりません。現在はサブスクリプションでモデルを潤沢に使えるボーナス期間中であり、従量課金制に移行する可能性は否定できません。このボーナスが終了したり、並列実行するタスクがさらに増えたりすれば、モデルを使い分ける必要が出てくるかもしれません。 その場合には、単純なトークン単価ではなく、変更を完成させるまでの総コストで比較する必要があります。安価なモデルを使った結果、実装のやり直しやレビューの回数が増えるのであれば、最初から高性能なモデルを使う方が安くなる可能性もあります。また最近ではモデルの選択という軸だけではなく effort level という軸も出てきています。effort level は、モデルの思考の深さを調整するパラメータであり、同じモデルでも思考の深さを変えることで、より複雑なタスクをこなせるようになります。モデルの選択と effort level の組み合わせによって、コストと能力のバランスを最適化することが今後の課題になるでしょう。 一般的に設計のような複雑で深い思考を必要とするタスクは高性能なモデルに任せ、単純な作業や既存のパターンに従った変更は安価なモデルに任せるといった使い分けがよく行われていますが、多くの場合この選択は人間の勘に頼っているのが現状です。モデルの能力を正確に把握し、どのタスクをどのモデルに任せるかを判断するためには、モデルの能力を定量的に評価する方法が重要になってくる可能性もあるでしょう。 ## AI 中毒？ 常に何らかの AI をバックグラウンドで動かしていなければならないという、一種の中毒のような感覚もあります。多くのサブスクリプションでは時間単位でのリミットがあり、そのリミットを使い切れなければ損をしたように感じてしまうのです。AI が動いていない時間があればあるほどその分生産性が落ちているように感じる強迫的な観念もあるでしょう。また AI は毎回非決定的な結果を返すため、ある種のギャンブル的な快感もあるのかもしれません。報酬が得られる確率が不確実な状況では、報酬を待つ間のドーパミンニューロンの活動が高まることを示した[動物実験](https://doi.org/10.1126/science.1077349)があります。この知見を AI の利用へそのまま当てはめることはできませんが、非決定的な結果を待つ感覚には、ガチャに似た魅力があるのかもしれません。AI を動かしていること自体が目的化してしまわないよう注意が必要です。 しかし、AI が常に稼働していることと、価値のある仕事が進んでいることは同じではありません。並列数を増やすほど、レビューや統合の負担も増えます。必要のないタスクを作り、AI の稼働率を上げること自体が目的になっていないか注意する必要があります。AI に何をさせるかだけでなく、何をさせないかを判断することも、これからの設計対象になるのかもしれません。 ## まとめ - AI コーディングでは、実装そのものよりも、実装前の設計セッションに多くの時間を使うようになった - 毎回のプロンプトでは詳細な作業手順ではなく、ゴール、背景、制約を共有する - 設計書には期待する振る舞いを記録し、再利用可能な検証手順はプロジェクト固有のスキルとして定義する - 設計書をもとにタスクを分解し、Git worktree と Claude Desktop の複数スレッドを使って並列に実行する - テスト、型チェック、Lint に加えて、ブラウザや `curl` を使った実動作まで AI 自身に検証させる - PR は実装を担当したセッションとは別のセッションで AI レビューする - 人間はすべてのコードを同じ粒度で確認するのではなく、全体の設計や高リスクな変更に注意を集中する - `CLAUDE.md` やスキルを改善することも重要だが、責務と依存関係が整理されたコードのアーキテクチャが最も重要であることは以前から変わらない