ジュニアに設計を任せる前に、自分で説明できるかを見る
AIでコードがすぐ出るようになると、設計らしい案もすぐ出てくる。そうであれば、ジュニアにも早い段階から設計を任せてよい時代だ、と読みたくなる。
先に結論をずらしておく。任せたくなるのは、成長が早まったからではないことがある。実装を書いて慣れるより先に、設計を任されている。本稿は、ジュニアは自分で設計せよ、という推奨ではない。支援があれば頑張れる、という励ましでもない。任せることと、自分で説明できることを分けて見る、という仮説の整理である。
素材にするのは、ニューヨーク・タイムズのエンジニアリングマネージャによる観察である（Thanabalan, 2026）。比較研究ではなく、現場のメモである。一般化はしない。
速くなるのは生成であり、判断ではない
AIの生成が速いと、チケットは前に進む。それらしい修正も、それらしい構成案も出る。本稿では、そのぶん、手で書き、壊し、戻りながら仕組みに慣れる機会が薄くなりうる、と読む。
人間の側に残るのは、出てきたものを読み、どこから疑うかを決め、障害のときに自分の判断を説明する仕事である。先に書いた「AIを使うことは、「読みさえできれば何とかなる」に似ている」で扱った問題でもある。AI に書かせても、提案を採るか退けるかを決める仕事は消えない。チームでは、生成が速くなったあとほど、設計を理解しないまま案を通していないかを確かめる必要がある。
Thanabalan は、判断が育ったかが表れる場面として大きな障害を挙げる。仕組みを自分で辿って最初に調べる場所を決めるか、AI ツールが示した警告だけを追うか、という対比である。記事中では、若手が AI の提案をすぐ実行し、後からシニアが仕組みの理解に基づいて方針を修正する。本稿は、この場面を、任せることと説明できることのずれとして読む。
任されるのが先になると、見るものが変わる
対応は、次のように整理できる。
| 出力だけを見る場合 | 判断まで見る場合 | |
|---|---|---|
| 作業 | 生成、提案の取り込み | 提案を採るか退けるか、説明、どこから疑うか、どちらを取るか |
| 指標 | 出したコードの量、差分の大きさ | 学習、理解、判断 |
| 確認するもの | 通ったコード | そのコードを説明できるか、障害のときに調べ始められるか |
支援を緩めてよいのは、自分で答えられる範囲が増えたあとである。
出したコードが増えたことと、システムを引き受けられるようになったことは、同じではない。「AIを「増幅器」と呼ぶ前に、何を増幅するかを見る」と同じで、増えているのが速度なのか、検証済みの判断なのかを分けないと、増幅は常に良い話になる。ジュニアが大変なのは、作業量が増えたからだけではない。実装で慣れる前に、設計判断を求められるからである。
Thanabalan は AI の使い方を、学ぶ段階（tutor）、設計判断を自分で持ちながら複雑な作業に使う段階（copilot）、経験を積んだ人が AI を速いジュニアのように扱う段階（accelerator）の三つに分ける。学ぶ段階では、説明を求め、分かっていない箇所を記録する。メンターや同僚には、プロンプトではなく仕組みを尋ねる。次の段階では、複雑な生成を使いながら、設計の判断と例外の扱いは自分で引き受ける。経験を積んだ段階では、要件と方針を渡し、AI の提案のうち、とくに構成と長期の影響に危うい点がないかを疑う。これは人を役職や固定した段階に閉じ込める手順書ではない。判断が育つにつれて支援を緩め、成功の指標を、出した量から学習・理解・判断へ移すための目安である。
効く範囲と、効かない範囲
この読みが効くのは、任せることと、自分で説明できることを分ける、という一点である。設計を任されることと、設計について答えられることは、同じではない。支援を緩めるのは、レビューで問いに答え、自分が触った範囲を説明し、障害のときにどこから疑うかを自分で持てるときである。出した量が増えたときではない。
効かない範囲もある。
第一に、すべての現場でジュニアに早く設計を任せる、とは言えない。本稿が扱うのは、生成が日常になり、若手に早い段階から設計判断を求めるチームである。
第二に、設計判断を早く任せること自体を、そのジュニアが未熟だから、と決めつけてはいけない。シニアが教える時間や、出した量だけでなく学習・理解・判断を見る評価も、チーム側の条件である。これらが欠ければ、任せることと説明できることのずれは広がりうる。人のせいだけにすると、チームの作り方は見えなくなる。
第三に、本稿はソフトウェア教育の実証ではない。一編のマネージャ観察と、既存の語彙を重ねた整理である。三つの段階を導入手順として推奨しない。
支援を誰が持つかは、論文と現場でずれる
『AIによる認知スキャフォールディングとアイデア発散傾向の構造化』が足場と呼ぶものは、一時的な支援である。成人と AI の対話が、考えを整理する負担をしばらく引き受ける。元になった Wood らの指導研究では、人の指導者が、一人では難しい部分を一時的に支え、自分でできるようになれば支援を外す。論文はこの考え方を成人と AI の対話へ広げ、考えの整理や下書きを AI に任せても、どこまで強く言うか、提案を採るか退けるかは人間が決める、と整理した。
Thanabalan の記事では、人間のメンターがペア作業やレビューの枠を持ち、AI ツールは学習を助ける役に置かれる。一方、論文では成人と AI の対話そのものを、その一時的な支援として扱う。近いのは、AI に出力させること自体を、理解や成長とみなさない点である。AI に生成を任せても、その提案を理解し、採るか退けるかを決める仕事まで消えるわけではない。決める仕事を人の側に置かないまま出力だけ増やせば、増えるのは、まだ引き受けられない提案である。
『地頭至上主義の系譜と認知資源の多元主義』の語彙で言えば、AI を使った事実だけで仕事の良し悪しは決まらない。問うべきなのは、その出力を検証し、仕事へ組み込み、結果を引き受けられるかである。慣れる前に設計を任せたことを、その人の能力の問題に読み替えると、教える時間や評価の仕方というチーム側の条件が見えなくなる。
『答え責任と外部化の線引き：AI協働における認知作業の委譲原理』の語彙も、ここで使える。「外部化」は、ここでは作業を AI に任せることを指す。AI に任せてよいのは、その結果について人間が根拠を示し、誤りを見つけて直し、提案を採るか退けるかを決められる範囲だけである。根拠は頭の中だけにある必要はない。変更履歴や対話の記録を辿って示せれば足りる、というのが論文の条件である。Thanabalan が障害で見る「最初に調べる場所を自分で決めるか、警告だけを追うか」は、その試験の一つの場面である。記録を辿っても方針を説明できず、警告だけを追うなら、その範囲の設計判断まで任せられる状態ではない。調べ始めを暗記していることが条件なのではない。
先の「AIがコードを書く時代に、なぜ「お気に入りの言語」を持つのか」で扱ったように、個人には、AI の提案を判断する基準が要る。チームでは、その基準を学ぶ機会の整備が、設計判断を任せる時期に追いつかないことがある。
任せてから、支援を外してよいわけではない
ジュニアが設計する時代だ、と読むと、先に任せれば育つ、になりやすい。だが本稿が記事から引くのは、任せただけでは、答えられる範囲は自動で増えない、という読みである。
支援は、読めて、検証できて、提案を採るか退けるか自分で決められるようになるまで残す枠である。先に任せただけでは、支援にはならない。出す速さが上がったときでもない。支援を緩めるのは、自分で答えられる範囲が増えたあとである。その前に外すと、残るのは設計の担当と、警告だけを追う手である。