これまで、生産性、開発の流れ、コードベース、記録の残し方を書いてきました。
今回は、AI と協業する「ワークフロー」── 日々の仕事の進め方を、考えてみます。
AI との関係性のスタイル
まず、AI を、どう位置づけるか。いくつかのスタイルがあります。
道具として: ツールとして使う。指示して、結果を得る。電卓やエディタの延長。
外注先として: 仕事を切り出して、任せる。成果物を受け取って、レビューする。
同僚として: 一緒に考え、対話しながら進める。壁打ち相手。
以前、「地頭が良く自信過剰な新人」と書いてきたのは、同僚に近い捉え方です。一緒に働く相手。でも、実際には、場面で使い分けている気がします。
定型的な作業は、道具として(さっと指示して、結果を得る)。まとまったタスクは、外注先として(任せて、レビューする)。設計を考えるときは、同僚として(対話しながら、壁打ち)。一つの関係性に固定するより、タスクに応じて、関係性を選ぶ。これが、現実的だと思います。
「自分のコード」か「AIのコード」か
AI が書いたコードを、どう扱うか。これも、スタンスが分かれます。
「自分のコード」として扱う: AI が書いても、自分が責任を持つ。隅々まで理解し、自分の手で書いたのと同じ品質に仕上げる。
「AIのコード」として承認する: AI が書いたものを、レビューして、承認する。外注先の成果物をチェックするように。
どちらが正しい、ではなく、これも場面によります。重要なロジック、データ処理、認証まわりは、「自分のコード」として、隅々まで理解する。定型的な部分は、「AIのコード」として、動作を確認して承認する。
ただ、前に「捨てて作り直す(Cattle not Pets)」と書いたように、AI で書くコストが下がると、コードへの執着は、減ってきました。「自分が手で書いた、大事なコード」という感覚は、薄れる。表層的なこだわり(この書き方が好き、など)は減らして、本質的な品質(正しく動くか、保守できるか)に、集中する。表層は AI に任せ、深層を磨く。
チームレビューか、自分でマージか
AI で大量に PR が出るようになると、レビューの負荷が問題になります(前に書いた「レビューがボトルネック」)。
ここで、判断があります。どの変更を、チームでレビューし、どの変更を、自分でレビューしてマージするか。
経緯を知らないメンバーが、大量の PR をレビューするのは、認知負荷が高い。だから、すべてをチームレビューに回すのは、現実的ではありません。
一つの目安は、変更の性質です。
- 動作確認で判断できる変更(見た目の調整、定型的な修正)→ 自分でレビューしてマージ
- ロジック、データ処理、認証、非同期処理(影響が読みにくい)→ チームレビュー
見た目の変更や、動作確認で「正しい」と判断できるものは、自分でマージしても、リスクが低い。でも、ロジックやデータ、影響が読みにくいものは、複数の目で見た方がいい。
ただし、これには、トレードオフもあります。自分でマージを増やすと、チームの教育機会、ナレッジ共有が、減る。レビューは、コードを良くするだけでなく、チームで知識を共有し、若手が学ぶ場でもある。自分でマージばかりだと、その機会が失われる。
だから、「コード(変更の性質)」「個人(自分の判断で十分か)」「チーム(教育・共有の価値)」── この3つの軸で、考えることになります。効率だけでなく、チームへの影響も。
AI が使えない時がある
ワークフローの現実として、AI が使えない時があることも、頭に置いておきたいところです。
AI のサービスは、障害で、ちょくちょく止まります。「GitHub が止まったとき」と、近い感覚です。たいてい短時間で復旧するので、「落ちてるね」と言いながら、待つ。
ただ、GitHub と AI では、少し違うところがあります。GitHub が止まっても、ローカルでは開発できる。止まるのは、push やレビュー、リリースといった、共有の部分です。でも、AI が止まると、AI を使った開発そのものが、止まる。
対処は、いくつかあります。短時間なら、待つ。あるいは、別のモデルに切り替える── Claude が止まれば、別の AI に。一つのモデルに固定していなければ、片方が止まっても、続けられる。それも難しければ、自分で書く。AI なしでも、従来通り、開発は進められる。
ただ、切り替えにも、自分で書くにも、備えが要ります。普段から一つのモデルだけに頼っていると、いざ切り替えても、スムーズにいかない。AI に任せきりで、自分で書く力が衰えていると、つらい。だから、一つのサービスに依存しすぎず、自分で書ける力も保っておく。今は短時間で復旧するので、待てば済みますが、長時間や、いざというときに、選択肢があると、強い。
AI も、止まることもあるインフラの一つ。過剰に恐れる必要はないけれど、依存しすぎないようには、しておきたいところです。
ジュニアの成長機会と、業界の現状
従来、ジュニアは、簡単なタスク(定型的なコード、小さな修正)から始めて、経験を積みました。でも、その「簡単なタスク」は、まさに AI が得意な領域。AI がやってしまうと、ジュニアが経験を積む機会が、減る。
米国では、これが、数字に表れています。エントリーレベルの求人が大きく落ち込み、22〜25歳の開発者の雇用が、2022年のピークから約2割減ったというデータがあります。2026年第1四半期だけで、5万件を超えるテック業界のレイオフがあり、AI を理由に挙げる企業も出てきました。
ただ、これには、長期的なリスクが指摘されています。ジュニアを雇わなければ、いずれシニアがいなくなる。不況でジュニア採用を凍結すると、数年後に中堅エンジニアが不足する。2008年の金融危機後にも、同じパターンが起きた。エンジニアのピラミッドは、ジュニアが入って、育って、シニアになる、という循環で成り立っている。その入り口を閉じると、循環が止まる。
実際、逆張りの動きもあります。IBM は、2026年に米国でのエントリーレベル採用を3倍にすると発表しました。AI が定型的なコーディングを担えるので、ジュニアは、顧客のニーズの理解や、AI 出力の検証に、より多くの時間を使うという再設計です。「3〜5年後に最も成功するのは、この環境でエントリーレベル採用に賭けた企業だ」という見方もある。
AI支援アプレンティスシップ
ジュニアの育て方も、変わってきています。
従来の「ジュニアに簡単なタスクを割り当てて、学ばせる」が機能しにくくなった代わりに、AI 出力をレビューし、検証し、判断する力を、最初から育てるというアプローチが出てきました。AI 出力を監査し、プロンプトを書き、検証することを、初日から中核スキルとして学ぶ。
これは、面白い転換です。仕事の認知的な重心が、「作ること」から「検証すること」に移った。そして、検証は、本来シニアのスキル。だから、ジュニアにも、最初から「検証する力」を育てる。
AI を使えば、ジュニアでも大量のコードを生み出せるが、デバッグや検証の経験がないと、システムに脆さを持ち込むリスクがある。だから、「なぜ、そのコードなのか」を理解させる。AI に答えを出させるだけでなく、その答えを吟味する力を、育てる。
ここで、注意したいのは、これは米国の状況だということです。米国は人件費が高く、AI との比較で、ジュニアの位置づけが、特に厳しく問われている。日本では、人件費や雇用の慣行が違う。米国の議論を、そのまま日本に当てはめるのは、慎重であるべきだと思います。自分の現場の文脈で、考える。
まとめ
AI 時代のワークフローを、考えてみました。
- AI との関係性は、道具・外注先・同僚を、タスクに応じて使い分ける
- AI のコードは、重要なものは「自分のコード」として理解し、定型は「AIのコード」として承認する
- 表層のこだわりは減らし、本質的な品質に集中する
- チームレビューか自分でマージかは、変更の性質で(動作確認で判断できるか、影響が読みにくいか)
- ただし、自分でマージは、チームの教育・共有の機会を減らすトレードオフがある
- AI が使えない時がある。待つ・別のモデルに切り替える・自分で書く。一つに依存せず、自分で書ける力も保つ
- ジュニアの成長機会が、AI で減っている(米国の現状)。でも、ジュニアを育てないと、いずれシニアがいなくなる
- AI 出力を検証する力を、最初から育てるアプレンティスシップが出てきた
- 米国の議論を、そのまま日本に当てはめず、自分の現場の文脈で考える
ワークフローに、唯一の正解はありません。タスクの性質、チームの状況、自分の現場で、選ぶ。これも、いつものエンジニアリングの延長です。AI で選択肢が増えたぶん、「どう進めるか」を、自分で選ぶことが、より大事になります。
