同じ作業を2回やったら負けをAIDD標準化に落とす

AI駆動開発を始めると、最初は個人の工夫が増えていきます。

Claude Codeにどう依頼すると設計が崩れにくいか。Codexにどこまで任せるとレビューしやすいか。Jiraの情報をどう貼るとタスク分解が安定するか。差分レビューでは、どの観点を先に見せると抜け漏れが減るか。

こうした工夫は大事です。ただ、個人のプロンプトや手順のまま残しておくと、チームの開発プロセスにはなかなか変わりません。便利な使い方を知っている人は速くなる一方で、使い方を知らない人は毎回ゼロから試行錯誤します。結果として、AI活用は進んでいるのに、組織としての再現性は上がりにくくなります。

個人的には、AIDDで一番もったいないのは、同じAI作業を何度も手作業で繰り返すことです。一度うまくいったプロンプトを、次回も思い出しながら書く。毎回同じレビュー観点を口頭で伝える。毎回同じ形式の設計メモをAIに作らせる。この状態は、便利ではありますが、標準化までは届いていません。

個人のAI活用はすぐ属人化する

AIツールは、個人利用から始めると非常に速く馴染みます。自分の文脈、自分の癖、自分の作業対象に合わせて、自然にプロンプトが育っていくからです。

一方で、この育ち方には弱点があります。

プロンプトがチャット履歴に埋もれる。成功した依頼の形が他の人に伝わらない。レビュー観点が個人の頭の中に残る。AIへ渡す情報の粒度が人によって違う。こうなると、AIを使っているのに、開発プロセスはむしろ属人化します。

これは、AI活用が悪いという話ではありません。むしろ自然な初期状態です。まず個人が試し、便利な使い方を見つける段階は必要です。ただし、そのまま放置すると、強い個人の生産性は上がっても、チームの最低水準は上がりません。

組織でAIDDを使うなら、次の問いに向き合う必要があります。

• うまくいった依頼を、次回も同じ品質で再現できるか
• 他の人が同じ入口から使えるか
• AIが作った成果物を、同じ観点でレビューできるか
• 作業途中で中断しても、別の日に再開できるか
• チャット履歴ではなく、Git管理できる形で状態が残るか

この問いに答えられないと、AI活用は便利な個人技に留まります。

プロンプトを共有しても標準化には足りない

よくある第一歩は、良いプロンプトを共有することです。これは有効です。何もない状態よりはずっと良いですし、AIに何を渡すべきかの感覚も揃いやすくなります。

ただ、プロンプト共有だけでは限界があります。

プロンプトは、単体では実行文脈を持ちません。どのファイルを読むのか、どの成果物を更新するのか、どこまでをAIに任せるのか、失敗したときに何を見るのか、作業後にどの状態を残すのか。こうした周辺の約束がないと、同じプロンプトでも結果は揺れます。

たとえば「このJiraをもとに設計書を作ってください」というプロンプトを共有しても、人によって渡すJira情報の粒度が違えば、成果物の品質は変わります。設計書の置き場所や粒度が決まっていなければ、後から再開するときにAIが参照すべき状態も分かりません。

標準化したいのは、プロンプトそのものではなく、作業の入口です。

どの情報を渡すか。どのファイルを作るか。どの観点を確認するか。作業後に何がGit上に残るか。ここまで含めて初めて、AI活用はチームの開発プロセスになります。

同じ作業を2回やったら入口を作る

自分の中では、「同じ作業を2回やったら負け」という感覚があります。

もちろん、すべてを自動化する必要はありません。1回限りの小さな作業まで仕組みにすると、仕組みの方が重くなります。ただ、同じ形式の依頼、同じ成果物、同じレビュー観点が繰り返し出てくるなら、それはプロンプトではなく入口にした方がよいです。

入口にするとは、たとえば次のようなことです。

• コマンドとして呼び出せるようにする
• 必要な入力情報を決める
• 生成する成果物の置き場所を決める
• レビュー観点をテンプレート化する
• 中断後に再開できる状態を残す

ここで重要なのは、AIに任せる範囲を広げることではありません。むしろ、AIがやることと人間が判断することを分けるために入口を作ります。

AIが得意なのは、与えられた文脈から成果物を作ることです。一方で、どの課題を解くのか、どのリスクを許容しないのか、どのタイミングで人間が確認するのかは、入口側で明示しておく必要があります。

初回作成と再開は同じではない

AIDDの標準化を考えるとき、個人的に大きかったのは「初回作成」と「再開」を分けることでした。

初回作成では、AIが参照する状態がまだありません。Jiraや要求メモから、設計書、詳細設計、進捗管理表、必要に応じてテスト観点を作る必要があります。この段階では、AIに現在位置を読ませるための地図そのものを作っています。

一方で、再開時には状況が違います。すでに設計書や進捗管理表があり、Git diffもあり、未完了タスクもあります。AIはそれらを読めば、今どこにいて、次に何をすべきかを推定できます。

この2つを同じ入口に押し込むと、初回は情報が足りず、再開時は余計な作成処理が混ざります。だから、初回作成と再開は分けた方が扱いやすいです。

/setup-dev
  Jiraや要求メモから、設計書、進捗管理表、テスト観点を作る

/continue-work
  既存の設計書、進捗管理表、Git状態を読み、現在位置から作業を再開する

この分け方は、機能を細かく分けたいからではありません。むしろ入口は少ない方がよいです。ただし、AIが参照できる状態がまだない初回と、状態が残っている再開では、必要な処理が根本的に違います。

Git管理できる状態に残す

チャット履歴にだけ作業状態が残ると、AIDDは再開しづらくなります。

昨日の会話では何を決めたのか。どのタスクが終わったのか。どのファイルを触る予定だったのか。何がブロッカーだったのか。これらがチャット履歴の中にしかないと、次回のAIも人間も文脈を復元しづらくなります。

そのため、標準化では、AIの出力をGit管理できる成果物に落とすことが重要です。

設計書、進捗管理表、レビュー観点、未完了タスク、残課題。こうした情報がリポジトリ内に残っていれば、次回のAIはそれを読んで再開できます。人間も差分として確認できます。チャット履歴に依存しないため、別のツールや別のメンバーでも引き継ぎやすくなります。

これは地味ですが、かなり効きます。AI活用を「その場の会話」から「開発プロセス」に変えるには、状態をリポジトリに残す必要があります。

標準化しても判断までAIに渡すわけではない

標準化というと、AIに任せる範囲を広げる話に見えるかもしれません。しかし、実際には逆の側面もあります。

標準化することで、AIに任せる部分と人間が判断する部分を分けやすくなります。

たとえば、AIにはJiraから設計書の叩き台を作らせる。ただし、要求の優先順位や業務影響の判断は人間が見る。AIには差分からレビュー観点を出させる。ただし、リリース可否やリスク許容は人間が決める。AIには進捗管理表を読んで次の作業を提案させる。ただし、スコープを変える判断は人間が行う。

この線引きがないままAIを使うと、便利さに引っ張られて、判断まで曖昧にAIへ渡してしまいます。標準コマンドやテンプレートは、AIを自由に動かすためではなく、AIを決められた責務の中で働かせるためにあります。

標準化の単位は小さくてよい

最初から完璧な開発基盤を作る必要はありません。

むしろ、最初は小さい単位で十分です。

• いつも使うレビュー観点を1つのテンプレートにする
• Jiraから設計メモを作る手順を固定する
• 実装再開時に読むファイルを決める
• 作業後に残す進捗メモの形式を決める
• AIに渡す禁止事項や制約を短くまとめる

このくらいの粒度でも、繰り返し作業はかなり減ります。重要なのは、便利だったプロンプトをチャット履歴に埋めたままにしないことです。2回使ったら、入口、テンプレート、チェックリスト、コマンドのどれかに変換する。これだけでも、AI活用の再現性は上がります。

まとめ

AIDDの標準化は、派手なエージェント基盤を作ることから始める必要はありません。

まず見るべきなのは、同じAI作業を何度も繰り返していないかです。毎回似たプロンプトを書いている。毎回同じレビュー観点を伝えている。毎回チャット履歴から文脈を掘り起こしている。そこに標準化の入口があります。

個人のAI活用は、最初は属人化していて構いません。むしろ、個人が試さないと有効な使い方は見つかりません。ただし、2回目以降も同じ作業が出てくるなら、プロンプトの共有だけで終わらせず、入口として残した方がよいです。

AI駆動開発で本当に効くのは、AIに何でも任せることではありません。AIが得意な変換作業を再利用可能な入口にまとめ、人間が判断すべき部分を残すことです。その積み重ねが、個人技だったAI活用を、チームで使える開発プロセスに変えていきます。