生成AIとの付き合い方を模索する中で、一つの問いにたどり着いた。
「AIが作れる時代に、開発者は何をすればいいんだろう？」
自分自身、AIのコードをひたすらコミットするだけの作業者になった時期があった。成果物は立派なのに、自分が何をしたのかわからない。逆に、AIを使いこなそうと力みすぎて、手段と目的が入れ替わった時期もあった。
その試行錯誤を通じて、少しずつ見えてきた形がある。それを若手開発者の育成研修として言語化してみた。まだコンセプトの段階だけど、考えていることを書いてみる。
「AIオーケストレーター」という像
研修の北極星として置いたのが「AIオーケストレーター」という像だ。
指揮者は自分では楽器を弾かない。でも、演奏の責任は指揮者にある。最初の一振りで曲を始め、最後の一振りで曲を締め、全体を通じて各楽器のバランスを調整する。
これを開発者に翻訳するとこうなる。
始める ── 何を作るべきかを宣言する。仕様を自分の言葉で語る。 引き受ける ── AIが書いたコードを読み、動かし、納得した上で自分の名前でコミットする。 整える ── CI/CD、テスト基盤、コーディングルール。AIが安全に動ける環境を育て続ける。
AIは「作る」を担えるようになった。でも、何を作るかを決めること、できたものに責任を持つこと、AIが動ける場を整え続けること。これは人間の仕事だと思っている。
歩幅の話
AIとの協働で一番大事だと感じているのは、歩幅の調節だ。
自分の理解が追いついていない領域では、AIと一緒に一歩ずつ進む。これを「伴走（Pair）」と呼んでいる。理解が十分な領域では、ゴールと制約を渡してまとめて任せる。これが「委託（Delegate）」。
どちらを選ぶかは、AIの能力ではなく、人間側の理解度で決まる。ここがポイントで、「AIがどこまでできるか」ではなく「自分がどこまでわかっているか」で歩幅が決まる。わかっていないのに大きく任せると、できたものの良し悪しが判断できない。第2夜の「すごい。でも楽しくない」はまさにそれだった。
1つのタスクの中でも、調査は伴走で丁寧に、実装は委託で一気に、引き受けは伴走で確認、と行き来する。「今どちらのモードか」を意識するだけで、だいぶ変わる。
5つの能力
オーケストレーターに必要な能力を5つに整理してみた。
探究（Discovery） ── 速く作る前に、何を作るべきかを問い続ける力。顧客の言葉の裏にある本当の課題を探り当てる。第9夜で「お客さんは何がほしいの？」と言われたのは、これが抜け落ちていたからだ。
対話（Dialogue） ── 文脈を渡し、AIからの反応をフィードバックとして受け取る力。AIの回答にはエラーや違和感も含まれるが、それは「自分の思考の鏡」だと思っている。ぼんやりした質問にはぼんやりした回答が返ってくる。
技術的卓越（Excellence） ── ソフトウェアエンジニアリングの知見でAIを導き、成果を見極める目利き力。デザインパターンやテスト技法の名前を知っているだけで、AIへの指示の精度が変わる。「Stateパターンで」の一言が、精密な指示になる。自分で完璧に実装できなくても、語彙があればAIに意図を伝えられる。これは技術的卓越への入口を軽くしてくれる。
規律（Discipline） ── 型に沿った思考のループを守り、小さな歩幅を維持する統率力。自分の理解度に応じて伴走と委託を切り替える判断もここに含まれる。
自由（Freedom） ── 制約に流されず、最善を選択する主体性。「時間が十分にあればどうするか？」を常に問う心のゆとり。AIに任せるか、自分で書くか、捨てるかを主体的に決める力。
規律は「型を守る力」で、自由は「型を超える判断力」。矛盾するようだけど、この2つが両方ないと、規律だけならAIの指示係になるし、自由だけなら再現性がなくなる。
3つの帽子と1つの型
日々の実践では、3つの帽子を使い分ける。
実験（Spike） ── 捨てる前提で広げる。失敗コストを下げて選択肢を探る。 実装（Implement） ── 確実な一歩を積む。Spec → Test → Code の順序を守る。 掃除（Clean） ── リファクタリングして、理解を深め、次に備える。
そして基本の流れは4ステップ。調査して、計画して（ここが「始める」）、AIに実装させて、引き受ける（ここが「引き受ける」）。この全体を下から支えるのが「整える」── テスト基盤やCI/CDを育て続ける営みだ。
人間が始め、AIが作り、人間が締める。この構造は、盆栽に似ているかもしれない。AIが伸ばすものを見ながら、必要のないところだけ手を入れる。育つ環境を整える。
まだコンセプトの段階で
このコンセプトは、自分自身がAIとの協働で転んだ経験から生まれている。正解を出させようとして発見を失い、AIに任せすぎて楽しさを失い、力みすぎてたしなめられた。
そして、自分一人の頭から出てきたものではない。いろんな人の知見を借りている。鍋に何を入れたかを書いておきたい。
参考文献・影響源
直接の影響源
和田卓人氏（@t_wada） ── このコンセプトに最も大きな影響を与えている。「伴走と委託」の2つのモードは、和田氏のAgile Japan 2025キーノート「AI時代のソフトウェア開発を考える」から。「歩幅」の概念もTDD（テスト駆動開発）の解説を通じて和田氏から学んだ。「AIは増幅器であり鏡」という視点も同キーノートより。
Kent Beck ── 歩幅の調節は『テスト駆動開発』から。「時間が十分にあればどうするか？」という問いは『XPエクストリームプログラミング』から。「帽子をかぶり分ける」（機能追加とリファクタリングを区分する）考え方はMartin Fowler『リファクタリング』で紹介されているKent Beckの概念。コンセプトではこれをSpike / Implement / Cleanの3つに拡張した。
アジャイルソフトウェア開発宣言（2001） ── 技術的卓越（Technical Excellence）は、12の原則の第9原則「技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます」から。
Barry Boehm & Richard Turner ── 規律の考え方は『アジャイルと規律：ソフトウエア開発を成功させる2つの鍵のバランス』（日経BP社、2004年）から。
「顧客が本当に欲しかったもの」 ── IT業界で広く知られるブランコの風刺画。コンセプトにおける探究（Discovery）の核にある考え方は、アジャイルコーチとの対話から言語化された。
基本の型（調査→計画→実装→引き受け） ── 調査・計画・実装の3ステップはアジャイルコーチから学んだもの。引き受け（Own）は、その後の生成AIとの対話の中で加わった。
AIオーケストレーターという比喩 ── 生成AIとの対話の中で生まれた。2025年1月頃、AI時代の開発者像のトレンドとして聞いたことがきっかけ。
盆栽の比喩 ── Claude.aiとの対話の中で生まれた。AIが伸ばすものを見ながら必要のないところだけ手を入れる、育つ環境を整えるという協働のイメージ。
間接の影響源
和田氏のキーノートが参照していたものを含め、背景にあるもの。
- 『Googleのソフトウェアエンジニアリング』（O'Reilly）── 「ソフトウェアエンジニアリングは時間で積分したプログラミング」
- Eric Evans『ドメイン駆動設計』── ドメインエキスパートとの対話と共通の語彙
- Melissa Perri『プロダクトマネジメント』（O'Reilly）── OutputよりOutcome
- Kent Beck『Tidy First?』── Behavior ChangeとStructure Changeの分離
- TOC（制約理論）── ボトルネック解消、フロー効率
- DORA Report 2025 ── AIは増幅器
自分自身の20年の蓄積からは、立川談志（業の肯定）、当事者研究・べてるの家（弱さの情報公開）、熊谷晋一郎氏（自立とは依存先を増やすこと）、みうらじゅん氏（自分洗脳、一人電通）、根本敬（でもやるんだよ）、枡野俊明氏のAsianPLoP 2013キーノート（アジャイル→フラジャイル）なども、直接コンセプトに書かれてはいないが底に流れている。
このコンセプトは、上記の影響源を設計図に落としたものではない。20年分のいろんな人の言葉を鍋に入れて煮込んだ結果、こういう形になった。抜け漏れや誤りがあれば、ぜひ教えてほしい。
実際の研修として動かすのはこれからだし、形にしていく過程で変わっていく部分も多いと思う。考えや感想があれば、ぜひ聞かせてほしい。
