労働こそが最高の学習だった
あなたは最近、「成長している」と感じているだろうか。
かつて、プログラマーにとって、労働こそが最高の学習の場だった。なぜか。労働には「摩擦」があったからだ。エラーが出る。原因がわからない。仮説を立てる。試す。失敗する。また試す。この摩擦の中で、経験が意味に変わっていた。労働は、経験を意味に変換する装置だった。
以前の開発を思い出す。新しいフレームワークを覚えなければならない。エラーと格闘して、ドキュメントを読み漁って、やっと動いたとき。あの達成感は、単なる満足ではなかった。「なぜ動かなかったか」「どう直したか」「次に同じ問題が起きたらどうするか」——この因果の記憶が、脳に刻み込まれていた。困難を乗り越えた記録が、自分の中に残っていた。
Claude Codeで開発している今、コードは書ける。動く。レビューも通る。Claude CodeはAnthropicが提供するAIエージェント型の開発ツールで、ターミナル上で動作し、コードの生成・編集・実行・デバッグまでを自然言語で指示できる。従来の「コード補完」とは次元が違う。プロジェクト全体を理解し、ファイルを横断して作業し、テストまで書いてくれる。開発のあり方が、根本から変わった。
しかし、その便利さの裏で、何かがおかしくなっていた。コードは書ける。動く。レビューも通る。でも、後から「なぜそう書いたの？」と聞かれても、答えに淀む。自分が責任を持って出力したコードのはずなのに、説明しようとすると言葉が出てこない。因果を辿れない。「なぜこの実装なのか」「他の選択肢は何だったか」「どこで判断したか」——この記憶がない。このままでは「実装ガチャ」を回し続けるだけの存在になってしまう。
先日、それを痛感する出来事があった。本番環境で障害が起きた。自分が2週間前に実装した機能だ。ログを見る。エラーメッセージを読む。でも、原因の見当がつかない。「この処理、どういう順序で動くんだっけ」と考える。思い出せない。自分で書いたコードなのに、頭の中でトレースできない。因果がわからない。結局、AIにコードを貼り付けて「このエラーの原因は？」と聞いた。答えは返ってきた。直った。しかし、自分では何も解決していない。2週間前の自分が書いたコードを、今日の自分が理解できていなかった。
もしかして、あなたも同じ感覚を持っていないだろうか。
最初は自分を責めた。集中力が落ちたのか。学習能力が衰えたのか。でも違った。労働と学習が、分離した。摩擦が消えた。経験が意味に変わる機会が消えた。
厄介だったのは、見せかけ上の生産性は上がっていたことだ。タスクは消化されている。アウトプットも出ている。しかし、3ヶ月前にやった案件の技術スタックを聞かれても、ほとんど思い出せない。生産性は上がった。成長は止まった。労働から学習が抜け落ちていた。
「成長していない」と感じるとき、私たちは何を失っているのか。
成果と経験と理解は、同じものだろうか。違う。成果は外に出たもの。経験は時間の中で起きたこと。理解は内側に残ったもの。成果が出ても、経験を積んでも、理解が残らなければ成長は感じられない。
失われているのは「苦労」ではない。「プロセスの記憶」だ。自分が何を考え、どこで躓き、どう乗り越えたか。この記憶が消えている。AIが生成したコードは動く。でも、そこに至るまでに自分が何を試し、何を捨て、何を選んだか——その記憶がない。
なぜ過去の仕事を説明できないと不安になるのか。説明できないということは、プロセスの記憶がないということだ。記憶がないということは、自分の中で何も変化が起きていないということだ。成長実感とは、能力の増加ではない。自分の内部で変化が起きたと確認できる手応えだ。
では、記憶に残らない仕事は価値がないのか。そうではない。成果としての価値はある。でも、自分を成長させる価値はない。成果は外に残る。成長は内に残る。両者は別物だ。
これは集中力の問題ではなかった。前回の記事「2025年版 私がAIエージェントと協働しながら集中する方法」で書いた微観法は、集中の持ち方を変えてくれた。でも、学習の問題は別だった。集中できても、学べていなかったのだ。
『信長の野望』をやっているのに『戦国無双』のような強さを求めるのは違う、と言われるかもしれない。地道な内政と、爽快なアクション。求めているものが違う。でも正直なところ、私たちはいつだってエンジニアなのでエンジニア領域で無双したいのです。
AI時代の3つの非対称性
ここまで、私個人の経験として「労働と学習の分離」を語ってきた。でも、ここまで読んで、「これは自分だけの問題かもしれない。単に自分の学び方が下手なだけでは？」と思った人もいるだろう。
そうではない。これは個人の問題ではない。構造の問題だ。
なぜ労働と学習が分離してしまったのか。その構造を理解するには、AIがもたらした3つの非対称性を見る必要がある。詳しくは別の記事で書いたが、ここでも簡単に触れておきたい。
第一の非対称性：生産と理解の乖離。AIでコードを書く速度は上がった。でも、そのコードを修正しようとすると、予想以上に時間がかかる。システム内にコードが流入する速度と、人間がそれを理解する速度の間に、決定的なギャップが生まれている。
第二の非対称性：生産量と成長の乖離。AIを使えば、経験1年目でも大量のコードを生産できる。PRの数も増える。でも半年後、1年後、エンジニアとしての地力はどうなっているだろうか。問題を自分で分析し、設計を考え、トレードオフを検討するプロセス。これがエンジニアの地力を育てる。AIに頼りすぎると、この思考プロセスそのものを外部化してしまう。
第三の非対称性：経験の量と学びの質の乖離。毎日AIを使って100行のコードを書く経験を1年積んでも、そこから「AIへの依存」しか学ばなければ、地力にはつながらない。「何を経験したか」ではなく、「そこから何を学んだか」が重要なのだ。
この3つの非対称性は、1つのシステムとして機能している。速く書けることを追求すれば、理解が追いつかなくなる。理解しないまま大量に生産すれば、思考力が育たない。経験を積んでも、そこから学ばなければ、成長は起きない。根底にあるメンタルモデル—「速さが価値」「量が成果」「経験が成長」—を変えない限り、どんな対症療法も一時的な効果しか生まない。
ここまでで、外部から見た構造——AIと人間の関係性——は理解できた。しかし、これだけでは「なぜ学べないのか」の本当の理由は見えてこない。構造は外側の話だ。学習が起きるのは、私たちの脳の内側だ。
では、この構造が私たちの脳に何をしているのか。もう少し掘り下げてみよう。
脳が「処理」していない
構造の問題は、最終的に脳の問題に帰着する。なぜ知識が残らないのか。しばらく自分を観察してみた。気づいたのは、AIエージェントと働いていると、認知的負荷が下がりすぎるということだ。
認知的負荷とは、頭を使う度合いのことだ。問題を解くとき、脳は情報を処理し、比較し、判断する。この「頭を使う」プロセスが、認知的負荷を生む。
負荷が下がること自体は、一見良いことに思える。楽に仕事ができる。疲れにくい。でも、学習の観点からは最悪だった。脳は適度な負荷がかからないと、情報を長期記憶に格納しない。「苦労せずに得た情報」は、脳にとって重要度が低いと判断される。楽に得た知識は、楽に消える。
では、認知的負荷はどこからが「害」になるのか。
問題は量ではない。質だ。認知的負荷には種類がある。タイピングの負荷。構文を思い出す負荷。そして、比較・判断・仮説といった意味処理の負荷。AIが減らしてくれるのは、すべての負荷だ。だが、害になるのは意味処理の負荷が消えたときだ。
なぜ脳は負荷がないと学ばないのか。脳は「重要でない」と判断した情報を捨てる。重要かどうかの判断基準は、処理にかかった負荷だ。苦労して得た情報は重要。楽に得た情報は重要でない。意味処理の負荷が消えた瞬間、脳は「これは覚えなくていい」と判断する。記憶も学習も、起こらなくなる。
「ちょうどよい負荷」は誰が決めるのか。AIではない。あなただ。負荷をAIに外注すると、脳は怠ける。怠けた脳は弱くなる。認知的負荷は削減対象ではない。設計対象だ。どの負荷を残し、どの負荷を外注するか。その設計を自分でしなければ、学習は起こらない。
楽になることと、考えなくなることは同じか。違う。作業が楽になるのはいい。思考が楽になるのは危険だ。手を動かす負荷は減らしていい。意味を処理する負荷は、意図的に残せ。
以前のプログラミングを思い出す。エラーが出る。ググる。ブログや公式ドキュメントを読む。試す。またエラー。別の方法を試す。やっと動く。このプロセス全体が、学習だった。途中で「わからない」状態に耐える必要があった。その「耐える時間」が、脳を鍛えていた。記憶を定着させていた。
今はどうか。エラーが出る。AIに投げる。答えが返ってくる。動く。終わり。プロセスが消えた。プロセスが死ぬと、学習も死ぬ。
考えてみてほしい。あなたが最後に「わからない」と感じたのは、いつだろうか。私は本当に思い出せなかった。AI時代において、「わからない」が絶滅したのだ。
聞けば答えが返ってくる。どんな質問にも、それらしい回答が生成される。以前は「わからない」状態で立ち止まり、悩み、調べ、試行錯誤した。その時間が学習だった。今は「わからない」と感じる前に、答えが手に入る。
「わからない状態」に耐える力こそ、学習に不可欠だ。
わからない状態は不快だ。不確実性は脳にストレスを与える。だから、答えを求める。AIはその欲求を即座に満たしてくれる。だが、「わからない」は単なる欠如ではない。意味を構築するための空白だ。
以前の学習を思い出してほしい。エラーが出て、原因がわからない。ドキュメントを読んでも、ピンとこない。仮説を立てて、試して、また失敗する。その空白の中で、脳は問題を構造化していた。何がわかっていて、何がわかっていないか。どこまでは正しくて、どこからが怪しいか。仮説を立て、壊し、更新する。このプロセスを通じて、人は「思考の型」と「判断の軸」を獲得してきた。
わからない経験がなくなると、思考の型が育たない。問題をどう分解するか。仮説をどう立てるか。どの順番で検証するか。これは、わからない状態を何度も経験することでしか身につかない。答えが即座に与えられる世界では、この「思考の筋トレ」そのものが消える。
AIはわからないと言わない。常に何かを返す。それが正しいかどうかは別として。人間だけが「わからない」を経験できる。その経験を捨てるのは、思考力を捨てることだ。
でも、その「すぐわかる」が、実は思考力を奪っていた。自分一人で「じっくり」考える時間が消えた。わからないまま考え続ける能力。不確実性の中にとどまる能力。それが失われていく。「わからない」を経験しないまま、「わかった」に到達してしまう。
ここまでは「わからない状態」の話だった。つまり、問題に直面したとき、AIがすぐに答えを出してしまうから、自分で考える時間がなくなるという話だ。
でも、認知的負荷が下がる問題は、これだけではない。AIの答えを受け取って「わかった」と思った後にも、別の問題がある。コードへの解像度が下がるのだ。
以前、自分で書いたコードは、補完もありながらちゃんと打ち込んでいた。変数名を決めるときに悩んだ。ループの終了条件を頭の中でシミュレートした。このif文の分岐は、こういうケースでtrueになる。この変数には、この時点でこの値が入っている。コードは指先から脳へ流れ込んでいた。
AIが生成したコードは、目で見ているだけだ。なんとなく動く気がするから動かす。動く。テストも通る。でも、変数の1つに至るまで把握しているかと言われると、怪しい。コードが「通過」していく感覚。身体に染み込んでいない。見ているのに、触れていない。
この違和感の正体は何か。
自分で書いたコードと、AIが書いたコードは何が違うのか。結果は同じだろう。動作も同じだろう。でも、因果関係を自分で通ったかどうかが違う。
自分で書いたコードには、因果の記憶がある。「この変数名、最初はdataにしようと思った。でも、後から読んだときに意味がわからなくなると思って、userResponseに変えた」。「このループ、最初はforで書いた。でも、副作用がないからmapの方がきれいだと思って書き直した」。迷い、選択し、決断した記憶。その因果を自分で通った記憶が、コードを「理解している」という感覚を生む。
AIが生成したコードには、この因果がない。結果だけがある。「なぜこの変数名なのか」「なぜこの書き方なのか」。AIには理由があるのだろう。でも、その理由を自分で通っていない。書く・迷う・選ぶという行為を経ていないコードは、頭の中で「実行」されていない。
なぜ説明できないと不安になるのか。説明できないということは、因果を再構成できないということだ。因果がわからないコードは、壊れたとき直せない。変更したとき、何が起きるか予測できない。「動くこと」と「わかること」は別だ。動くことは確認できる。わかることは、因果を辿れるかどうかで決まる。
理解とは知識量ではない。因果を身体でトレースできるかどうかだ。「見ているが触っていない」とは、この状態だ。視覚的には認識している。でも、因果を身体で通過していない。だから、記憶に残らない。応用が利かない。自分のものにならない。
解像度が低い理解は、何を引き起こすのか。判断ができなくなる。「この実装でいいのか」「この変更は安全か」。判断には、因果の理解が必要だ。因果がわからなければ、判断できない。判断できない人間は、AIの出力を受け入れるしかない。
私は自分で書いたコードは、書く過程で何度も頭の中で実行している。「この変数がnullだったらどうなる」「このループは何回まわる」「この関数の戻り値は何型か」。無意識に検証している。AIが生成したコードには、この検証プロセスがない。
結果、コードの「解像度」が違う。自分で書いたコードは、ズームインしてもくっきり見える。AIが生成したコードは、全体像はわかるが、細部がぼやけている。動くことは知っている。なぜ動くかは、よくわからない。
解像度が低いと、記憶にも残りにくい。ぼんやりした情報は、脳に定着しない。
そしてもう1つ、記憶を弱くする要因がある。解像度の問題とは別に、「思い出す」作業をしていないのだ。
記憶を定着させるには、能動的に思い出す作業が必要だ。一度覚えたことを、何も見ずに思い出す。その「引き出す」作業が、記憶を強化する。でもAIと働いていると、思い出す必要がない。わからないときは聞けばいい。脳が「引き出す」練習をしなくなった。
筋トレと同じだ。重いものを持ち上げないと筋肉はつかない。代わりに機械が持ち上げてくれたら、楽だけど、筋肉は衰える。AIは脳の代行業者だ。頼りすぎると、依頼主が衰える。
何をしたか覚えていない、だから自分を過小評価する
ここまで、認知的負荷が下がることで起きる3つの問題を見てきた。「わからない」状態を経験しなくなること。コードへの解像度が下がること。そして、「思い出す」作業をしなくなること。
これらは脳の内側で起きている問題だった。しかし、認知的負荷が下がることには、もう1つ厄介な副作用がある。脳の外側、つまり自分自身の認識に関わる問題だ。自分が何をしたのか覚えていないのだ。
1日の終わりに「今日、何やったっけ？」と振り返る。AIと働いていると、驚くほど思い出せない。タスクは消化した。PRはマージされた。でも、何をどう解決したのか、記憶がぼんやりしている。
なぜか。苦労しなかったからだ。痛みを伴わない経験は、砂に書いた文字だ。苦労は記憶のアンカーになる。あのエラーで3時間ハマった。あの設計で悩んで何度も書き直した。そういう「苦労の記憶」が、「自分がやった」という実感を生む。AIが苦労を肩代わりすると、このアンカーがなくなる。
アンカーがないと、何が起きるか。自分を過小評価するようになる。
「今日、大したことやってないな」と感じる。でも実際には、かなりの量のコードがマージされている。客観的には生産性が上がっているのに、主観的には「何もやっていない」気がする。成果と実感が乖離する。
これは私だけの感覚ではない。知り合いのエンジニアと話していても、同じことを言う人が多い。「なんか最近、成長している実感がない」「仕事はこなせているけど、自分が何をやったか説明できない」。みんな同じ違和感を抱えている。感覚と現実が、乖離しているのだ。
なぜ「何をしたか」を覚えていないと不安になるのか。自己評価はどこから生まれているのか。
自己評価は、成果から生まれるのではない。「自分が困難にどう向き合ったか」という記憶から生まれる。
あのバグを3時間かけて潰した。あの設計を何度も書き直した。あの障害対応で深夜まで粘った。こうした記憶が、「自分はやれる」という感覚を作る。苦労は自己評価の原材料だ。
AIが苦労を肩代わりすると、何が起きるか。成果はある。でも、「自分がやった」という実感が残らない。困難と向き合った記憶がないから、自分を評価する材料がない。結果、成果が出ているのに自分を信じられなくなる。
成果と達成感はなぜズレるのか。達成感は「困難を乗り越えた」という認識から生まれる。困難がなければ、達成感も生まれない。AIが困難を消してくれると、成果だけが残り、達成感は消える。成果と達成感の乖離。これがAI時代の新しい病だ。
このズレは長期的に何を壊すのか。
まず、挑戦を避けるようになる。「どうせAIがやってくれる」と思う。自分で考えることを放棄する。次に、自分を信じられなくなる。難しい問題に直面したとき、「自分にはできない」と感じる。かつて乗り越えた経験がないから、乗り越えられるイメージが湧かない。そして最後に、エンジニアとしてのアイデンティティが揺らぐ。「自分は何ができる人間なのか」がわからなくなる。成果は出ている。でも、それは自分の力なのか、AIの力なのか。区別がつかなくなる。
達成の記憶がないなら、何かで補うしかない。では、何で補うのか。
答えを先に言う。記録だ。
達成の記憶がないなら、記録で作ればいい。苦労の記憶がないなら、躓きを記録で残せばいい。AIが消してしまう「プロセスの記憶」を、意図的に書き留める。それが私の出した答えだった。
日報が労働と学習をつなぎ直した
ここまで読んで、「わかる、でもどうすればいいの？」と思っただろうか。私も同じだった。
記録が大事だとわかっても、何をどう記録すればいいかわからなかった。行き詰まっていたとき、藁にもすがる思いで、ある習慣を始めた。日報だ。
正直、日報は嫌いだった。面倒くさい。忙しい。後で書こうと思って忘れる。3日分まとめて書いて、何をやったか思い出せない。典型的なサボりパターンだった。何度も挫折した。でも、このままでは本当にまずいと思った。自分が書いたコードを説明できない。障害が起きても自分で解決できない。エンジニアとして、このまま衰えていくのか。その恐怖が、嫌いな日報を続けさせた。
でも、日報の目的を変えてみた。上司への報告のためではなく、労働の中で生まれた曖昧さを捕まえるために書く。自分が何をわかっていて、何をわかっていないか。その現状を記録する仕組みだ。
日報を続けて、衝撃的な事実に気づいた。その話は後で詳しく書く。
でもその前に、一度立ち止まって考えたい。日報を書いて躓きを記録する。それは「学習」につながるはずだ。しかし、そもそも「学習する」とは何なのだろうか。この根本的な問いを考えないと、日報を書く意味も見えてこない。
では、「学習する」とは、そもそも何なのでしょうか。
この問いを考えるとき、私は為末大さんの『熟達論——人はいつまでも学び、成長できる』（新潮社、2023年）に大きな影響を受けました。400mハードルで日本記録を持つ「走る哲学者」が、様々な分野の達人たちとの対話を重ねて到達した方法論です。
為末さんは、人が何かを学び、熟達していくプロセスには、分野を超えた普遍的な構造があると言います。陸上であれプログラミングであれ、学習のプロセスは同じです。技能と自分のどちらかだけを高めても成長できないと説きます。技能と自分は、切り離すことのできない「ひとつのもの」——つまり人間という総体として捉えるべきだと。この人間総体を高めていくことが、学習なのです。
この考え方は、ソフトウェアエンジニアとしても腑に落ちます。プログラミングスキルだけを磨いても、良いエンジニアにはなれません。問題を分解する力、チームで働く力、技術を選ぶ判断力。技能と自分の総体が、エンジニアとしての実力です。
為末さんによれば、学習には5つの段階があります。この5段階は「学習がどう進むか」を示す地図です。まず、その地図を見てみましょう。
「遊（ゆう）」——学習の入口です。新しい技術に触れて、面白いから触る。効率は求めません。目的もありません。遊びとは主体的であり、面白さを伴い、不規則なもの。このモチベーションの源泉が、学習の入口になります。
エンジニアなら、新しいフレームワークを触ってみる。ドキュメントを読む前に動かしてみる。「これ何ができるんだろう」と試す。壊してみる。変なパラメータを渡してみる。遊びが好奇心を育て、好奇心が学習を駆動します。
「型（かた）」——基礎を身につける段階です。お手本を真似る。ドキュメント通りに書く。型とは「基盤となる最も基本的なもの」であり、個人差を超えて最も安定している普遍的なものです。型は丸呑みするもの。なぜそうするかはわからなくても、まず形から入ります。
エンジニアなら、公式チュートリアルを写経する。ベストプラクティスをそのまま真似る。「なぜこう書くのか」は後回し。まず手が覚えるまで繰り返します。型が身体に入ると、考えなくても書けるようになります。
「観（かん）」——構造を理解する段階です。「なぜこの書き方なのか」と問う。「見る」とは「分ける」こと。動作を分けて見ることで、技術を構造化します。ある技能は別の技能に支えられている。その関係性が見えてきます。
エンジニアなら、コードの設計意図を読み取る。「この抽象化は何のためか」「このパターンはどこで使えるか」と問う。部分（関数）と全体（システム）の関係が見えます。観ができると、他人のコードから学べるようになります。また、コードを「意味の塊」として捉えられるようになります。初心者が「if文があって、関数呼び出しがあって...」と一行ずつ追う場面で、「これはトークン検証の処理だ」と全体を1つの塊として認識できる。塊で捉えるから、複雑なコードも把握できるのです。
「心（しん）」——本質を掴む段階です。見極めた本質を軸に、自分なりに自由に動ける状態。いつでもニュートラルポジションに戻れるから、応用的な技術も試せます。中心を柔らかくつかむと、冒険できるようになります。
エンジニアなら、技術の本質を掴んでいる状態です。「認証の本質は信頼の証明だ」とわかれば、JWT でも OAuth でも Session でも、状況に応じて選べます。心を掴むと、新しい技術もすぐ理解できます。また、具体的な事例から抽象的なパターンを抽出できます。「このエラーはnullチェック漏れ」という具体から「外部データは信頼しない」という原則へ昇華する。この抽象化ができると、問題を絞り込む力も育ちます。「Invalid token」というエラーを見て、「トークン生成か検証のどちらかが問題」と可能性を狭められる。原理原則を理解していれば、推論で問題にたどり着けるのです。
「空（くう）」——学習の到達点です。制約から解き放たれて、技能が自然な形で表現できる状態。いわゆる「ゾーン」です。論理よりも勘が働く。そしてまた「遊」に戻る。学習は循環します。
エンジニアなら、コードが自然に流れ出る状態です。設計を考えなくても、手が正しい方向に動く。深夜のデバッグで「なぜかここが怪しい」と直感が働く。空に達した技能は、意識せずに発揮されます。
重要なのは、部分の学習が全体を高めるという構造です。「認証処理」という部分を学ぶと、「Webアプリケーション開発」という全体の質が上がります。そして全体の質が上がると、今度は別の部分——たとえば「データベース設計」——を学ぶ意欲が湧いてきます。部分と全体が相互に作用しながら、エンジニアとしての総体が高まっていく。この循環こそが、成長を楽しめる理由です。
ここまでが、学習の地図です。
でも、抽象的な説明だけでは実感が湧かないかもしれません。私自身の経験に当てはめてみましょう。以前、新しい技術を学ぶとき、何が起きていたでしょうか。
ドキュメントを読む。知らない概念が出てくる。調べる。言葉の意味はわかった。でも、まだ腑に落ちない。実際にコードを書いてみる。動かない。なぜ動かないか考える。仮説を立てる。試す。また動かない。別の仮説を立てる。3時間が経つ。ようやく動いた。「ああ、こういうことか」。次からは同じ間違いをしなくなる。
この過程で、学習の段階を登っていました。最初は遊びから入った。動かしてみる。壊してみる。次に型を学んだ。ドキュメントを読み、お手本通りに書いた。型を繰り返すうちに、「なぜ」が見えてきた。観の段階です。より深まると、パターンが見える。心の段階です。そして最後に、考えなくても手が動くようになる。
摩擦が、学習を生んでいました。繰り返しが、成長を生んでいました。
今は違います。
AIに聞く。完璧なコードが返ってくる。動く。終わり。
私は遊んでいません。型も知りません。観ることもありません。心を掴めません。当然、空には程遠い。結果は出ました。でも、自分の中に何も残っていません。成果だけが先に行き、自分は置き去りにされました。
これがAI時代の問題の核心です。摩擦がないから、学べない。繰り返す機会がないから、成長しない。
問題の核心は見えました。では、もう少し細かく見てみましょう。学習の5段階で、AIはどこを加速し、どこを壊しているのでしょうか。
AIはどの段階を代替しやすいでしょうか。「型」です。正しい書き方、ベストプラクティス、パターンの適用。AIはこれらを高速に提供してくれます。初心者がいきなり熟練者と同じ「型」を使えるようになる。これ自体は悪くありません。
では、AIが壊すのはどこでしょうか。「遊」と「観」です。特に「遊」のダメージは深刻です。
「遊」が消えると何が起きるのでしょうか。遊びとは、目的なく触ること。壊してみること。限界を探ること。正解がすぐ手に入る環境では、不規則さ・寄り道・失敗が排除されます。効率を求めると、遊びは最初に切り捨てられます。
しかし、遊びは単なる入口ではありません。型や観に進むためのエネルギー源でもあります。
なぜでしょうか。「型」を学ぶのは退屈です。ドキュメント通りに書く。お手本を真似る。地味な作業です。この退屈に耐えられるのは、「遊」の段階で「面白い」という感覚を得ているからです。「この技術、面白い。だから、ちゃんと学びたい」。このモチベーションがなければ、「型」の段階で挫折します。
「観」も同様です。「なぜこうするのか」と問うのは、好奇心がなければできません。好奇心は「遊」で育ちます。遊びがないと、「なぜ」を問う動機がない。「動くからいい」で終わります。
遊びがないと、「面白いから学ぶ」がなくなります。「必要だから学ぶ」だけになる。必要性で駆動される学習は、必要がなくなった瞬間に止まります。遊びが失われると、学習への意欲そのものが枯れるのです。
「観」も壊れやすい段階です。「なぜこうするのか」と問う前に、AIが答えを出してしまう。構造を自分で見出すプロセスがスキップされます。答えは知っている。でも、答えに至る道筋が見えない。観る力はどこで育つのでしょうか。自分で構造を発見する経験の中です。AIがその経験を奪います。
型を飛ばすと、なぜ応用できないのでしょうか。型は「基盤となる最も基本的なもの」です。基盤がないと、その上に何も建てられません。AIが型を代替してくれると、基盤が自分の中にない。だから、少し変わった状況に対応できないのです。
学習はなぜ循環構造なのでしょうか。「空」に達しても、また「遊」に戻ります。新しい領域を学ぶとき、再び遊びから始まる。この循環が止まらない限り、人は成長し続けます。AIが「遊」を奪うと、循環そのものが止まります。
「心」と「空」は、そもそも到達しにくくなります。基盤となる「遊」と「観」が欠けているからです。本質を掴むには、周辺を十分に探索している必要があります。無意識に動けるようになるには、意識的に何度も繰り返した経験が必要です。AIは上層を加速しますが、基盤を掘り崩します。
思い返せば、私が一番成長したのは「遊んでいた」時期でした。学生時代、深夜にLinuxをいじっていました。「このコマンドに変なオプションを渡したらどうなるんだろう」と試した。システムが壊れた。復旧に3時間かかった。でも、その3時間でファイルシステムの構造を理解しました。教科書を読むより、壊して直す方がずっと早く学べました。
社会人になってからも、余裕があるときは遊んでいました。「この機能、公式ドキュメントにはこう書いてあるけど、本当にそうなのか」と検証した。ドキュメントが間違っていることもありました。公式が想定していないパターンを見つけることもありました。遊びは、ドキュメントの外側を教えてくれました。
今はどうでしょうか。遊ぶ暇があったら、次のタスクをAIに投げています。効率的です。生産的です。でも、技術との「雑談」がなくなりました。目的のない探索がなくなりました。効率を追求した結果、学習の肥沃な土壌を捨てていたのです。
遊びがないと、表面的な理解で終わります。ドキュメントに書いてあることは知っている。でも、書いていないことは知らない。想定外の状況に遭遇したとき、対処できません。遊んでいないから、技術の「手触り」がわからないのです。
ここまで、学習の5段階と、AIがそれをどう壊すかを説明しました。問題は見えました。では、どうすればいいのでしょうか。
答えは単純です。何がわかっていないのかを、見えるようにする。何が欠けているのか。どこで躓いているのか。それを捕まえる。見えれば、対策が打てます。
学習の段階で言えば、自分が「遊」で止まっているのか、「型」が足りないのか、「観」ができていないのか。それを知る必要がある。しかし、AIと効率的に働いていると、自分がどこで止まっているかすら見えない。見えないものは改善できない。
だから、見えるようにする仕組みが必要だ。そこで私は、先に触れた日報を本格的に活用することにしました。
1週間続けて、衝撃を受けました。自分がこんなにも理解していなかったのか。
金曜の夜、その週の日報を見返した。「わからない」と書いた項目を数えてみようと思った。月曜の分から順番に。1、2、3... 10を超えたあたりで、手が止まった。まだ火曜だった。水曜、木曜、金曜と続く。「なぜ」がわからないもの、「本質」が見えないもの。多すぎた。画面を見つめながら、胃のあたりがざわついた。正直、途中で数えるのをやめた。自分は理解の入口にすら立っていなかった。
しばらく、椅子に座ったまま動けなかった。これが自分の実力なのか。毎日コードを書いて、PRをマージして、それなりにやっているつもりだった。でも、蓋を開けてみれば、理解の穴だらけだった。恥ずかしさ、情けなさ、少しの怒り。それらの混ざった感情が胸に込み上げてきた。
でも、その夜、不思議と眠れた。これは希望でもあったからだ。自分の現状を捕まえさえすれば、次に進める。見えない敵は怖いが、見える敵は対策できる。何より、問題が見えた。見えないまま衰えていくより、ずっといい。
だから、日報について詳しく説明したい。なぜ日報が効くのか。どう書けばいいのか。
日報がなぜ「記録」以上の意味を持つのか。それを理解するには、日報が何を可視化しているかを知る必要がある。
日報は単なるログではない。曖昧さを捕まえるためのセンサーだ。
書くことは、なぜ理解を深めるのか。AIと働いていると、違和感は一瞬で消える。「なんかわからないな」と思った次の瞬間、AIに聞いている。違和感を感じている時間がない。日報に「なぜ:」と書こうとすると、その違和感を言語化しなければならない。「何がわからないのか」を言葉にする。この言語化のプロセスで、曖昧だった問題が明確になる。書くことは、理解を深める。なぜなら、書けないことは理解していないことだからだ。
その場で書くことに意味はあるのか。ある。学習の起点は「わからなかった点」にある。しかし、「わからなかった」という感覚は、時間とともに薄れる。翌日には忘れている。1週間後には、何がわからなかったかすら思い出せない。日報は、躓きを時間差で消えない形に固定する。その場で書かないと、学習の種が消える。
日報は何を可視化しているのか。自分が何をわかっていて、何をわかっていないか。どこで繰り返し躓いているか。どのパターンが苦手か。可視化されて初めて、対策が可能になる。見えないものは改善できない。日報は、見えないものを見えるようにする。
なぜ「躓き」が重要なのか。躓きは、成長の種だ。スムーズにできたことからは、何も学べない。躓いたところに、学びがある。日報は、躓きを収集するシステムだ。躓きを記録し、パターンを見つけ、対策を打つ。このサイクルが学習を生む。
日報がないと何が起きるのか。躓きが流れていく。同じところで何度も躓く。でも、躓いていることに気づかない。気づかないから、対策も打てない。日報がない状態は、センサーのない飛行だ。どこに向かっているかわからない。何が起きているかわからない。墜落してから、問題に気づく。
では、日報には何を書けばいいのか。私がよく使うのは「なぜ:」と「試した:」だ。
「なぜ:」——理由がわからなかったことを記録する。「なぜ: この実装パターンを選んだ理由」。表面的な理解で終わらせない。
「試した:」——目的のない探索を記録する。「試した: このライブラリ、何ができるんだろう。ドキュメントを読まずに動かしてみた」。好奇心が動いた瞬間を残す。
キーワードは自分で決めればいい。「写経:」「本質:」「ハマった:」など、必要に応じて増やせばいい。大事なのは、何がわからなかったかを捕まえること。記録することで、自分の躓きパターンが見えてくる。
以前は、労働の中で自然と学んでいた。困難にぶつかり、格闘し、乗り越える。そのプロセスが、理解を深めてくれた。
今は違う。AIが困難を消してくれるから、格闘する機会がない。だから、意識的に躓きを記録し、学習の種類を分類する必要がある。日報は、そのための道具だ。
ここまでは日報の「考え方」を説明した。では、具体的にどう実装するのか。
私はClaude Codeのカスタムslash commandsで日報システムを作った。詳しい実装は以前の記事に書いた。
Claude Codeには強力なカスタマイズ機能がある。CLAUDE.mdというMarkdownファイルをプロジェクトルートや~/.claude/に置くと、AIがそれを読み込んで動作を調整する。コーディング規約、プロジェクト固有のルール、よく使うパターンなどを書いておけば、AIがそれを参照しながら作業してくれる。
また、~/.claude/commands/にMarkdownファイルを置くと、カスタムslash commandsとして使える。/nippo-addと打てば、日報追加用のプロンプトが実行される。AIを「自分専用の道具」に育てる仕組みだ。
私の日報システムは3つのコマンドで構成される。
/nippo-add - 作業中にその場で記録する。Issue番号や感情も一緒に書く。後から検索しやすくなる。
/nippo-finalize - 1日の終わりに実行。散らばった記録をAIが整理して、読みやすい日報に仕上げる。
/nippo-show - 日次・週次のサマリーを表示。繰り返し躓いているパターンを可視化する。
コマンドファイルは ~/.claude/commands/ に置く。プロジェクトをまたいで使える。CLAUDE.mdにはプロジェクトの文脈を、commands/には繰り返し使う操作を。この2つで、AIは「汎用ツール」から「自分の相棒」に変わる。
/nippo-add #456 JWTの検証ロジック実装開始 /nippo-add #456 AIが書いたコード動いた。でもなぜRS256なのかわからない /nippo-add なぜ: RS256とHS256の違い /nippo-add 試した: JWTのペイロードに変なデータを入れたらどうなるか
ポイントは作業中に記録すること。1日の終わりにまとめて書こうとすると、何をやったか思い出せない。その場で書けば、摩擦がない。「なぜ:」「試した:」などのキーワードを入れておけば、後から抽出しやすい。自分がどこで躓いているか、一目でわかる。
キーワードは何でもいい。「ハマった:」「理由:」でも、英語で「why:」でも構わない。大事なのは、自分が後から検索しやすく、学習のパターンを把握できること。正解はない。自分にしっくりくる言葉を見つければいい。
日報を見返すと、同じ技術で同じ種類の躓きが繰り返されている。非同期処理では「なぜ」がわからない。エラーハンドリングでは「本質」が見えない。新しいライブラリでは「試した」が足りない。繰り返し出てくるということは、その部分で理解が止まっているということだ。弱点が見える。弱点が見えれば、対策が打てる。日報は、学習のガイドになった。
日報のキーワードが学習のトリガー
ここまで、日報を使って躓きを「記録する」方法を説明した。しかし、記録しただけでは学習は起きない。記録は入口に過ぎない。
日報に「なぜ:」「試した:」と書いたら、それは学習のトリガーだ。記録して終わりではない。そのまま次に進まない。徹底的にAIと対話する。
なぜ「対話する」なのか。ここが重要だ。
キーワードで記録した躓きは、「わかっていない」ということだ。わかっていないことを、わかるようにするには、どうすればいいか。自分で調べてもいい。でも、AIがいる。AIは、わからないことを説明してくれる。問題は、AIの説明を受動的に聞くか、能動的に引き出すか、だ。
私のルールは単純だ。これらのキーワードを書いたら、その場で最低10分はAIと対話する。10分で理解できなければ、20分かける。理解できるまでやる。次のタスクには進まない。
ただ、ここで重要な反論がある。「10分で理解できるわけがない」という反論だ。確かにそうだ。複雑な概念を10分で完全に理解するのは無理がある。でも、重要なのは「10分という制約を設けること」自体にある。制約があるから、「本当にわからないこと」だけに集中できる。制約がなければ、際限なく調べ続けて、結局何も身につかない。
では、具体的にどう「徹底的に対話する」のか。ここが最も重要なところだ。「AIと対話する」と言っても、やり方次第で効果は天と地ほど違う。
徹底的に対話する技術
「AIと対話する」とは具体的にどういうことか。まず、よくある間違いから見てみよう。
AIに「答えをもらう」ことと、AIと「徹底的に対話する」ことは、本質的に違う。
答えは受動。対話は能動だ。
答えをもらう：「このエラーを直して」→ 直るコードが返ってくる → 動く → 終わり。人間側の思考は、ほぼゼロだ。問題を投げて、解決策を受け取る。コピペする。動く。何も考えていない。
徹底的に対話する：「このエラーの原因は何？」→「なぜそうなる？」→「他にも同じパターンはある？」→「どう防げる？」。人間側に思考が発生する。質問を組み立てる段階で、自分が何をわかっていないか考える。答えを聞いて、次の質問を考える。このサイクル全体で、脳が動いている。
なぜ「教えて」では足りないのか。「教えて」は丸投げだ。AIは何かを返す。でも、それがあなたに必要な説明かどうかわからない。あなたが何を知っていて、何を知らないか、AIには見えない。だから、的外れな説明が返ってくることもある。
説明を引き出す側に何が求められるか。自分の理解の輪郭を先に差し出すことだ。「私はここまでわかっている。でも、ここからがわからない」。この輪郭を示すことで、AIは適切な説明を返せる。そして、輪郭を示す行為自体が、すでに学習だ。自分が何をわかっていないか言語化する。これは思考を整理する作業だ。
説明を引き出す行為は、どの段階で人間側の思考を必要とするか。最初から最後までだ。何を聞くか考える。聞いた答えを解釈する。次に何を聞くか決める。答えを自分の文脈に当てはめる。このすべてが、能動的な思考だ。答えをもらうだけなら、受動的でいい。説明を引き出すには、能動的でなければならない。
なぜ「自分の言葉で書き直す」ことが理解の判定基準になるのか。AIの言葉をそのまま使えるなら、理解していなくてもコピペできる。自分の言葉に置き換えるには、一度、頭の中で「翻訳」する必要がある。翻訳には理解が必要だ。書き直せない説明は、理解ではない。
説明できるとはどういう状態か。因果を辿れる状態だ。「なぜこうなるか」を自分の言葉で説明できる。別の人に質問されても、答えられる。説明できるようになって初めて、その知識は「使える」ようになる。
この違いは学習速度にどう影響するか。答えをもらい続けると、学習速度はゼロに近づく。説明を引き出し続けると、学習速度は加速する。同じAIを使っても、使い方で学習効果は天と地ほど違う。
最初は恥ずかしかった。「こんな基本的なことも知らないのか」と思われるのが怖かった。でも、AIは笑わない。何度聞いても呆れない。AIは、最高の学習パートナーだ。この発見が、学び方を変えた。
ステップ1: 自分の理解を言語化する
いきなり「教えて」と聞かない。まず自分が何をわかっていて、何がわからないかを言語化する。
RS256とHS256について、私の現在の理解を確認させて。 私の理解： - 両方ともJWTの署名アルゴリズム - HS256は「対称鍵」を使う（たぶん） - RS256は「非対称鍵」を使う（たぶん） わからないこと： - なぜRS256の方が「セキュア」と言われるのか - どういう場面でどちらを選ぶべきか この理解は合ってる？
こうすることで、AIは私の理解レベルに合わせた説明をしてくれる。輪郭を示す行為自体が、すでに学習だ。
ステップ2: 「なぜ」を3回以上繰り返す
表面的な理解で終わらせない。本質に到達するまで「なぜ」を繰り返す。
なぜJWTの署名にRS256を使うの？
→ 「秘密鍵と公開鍵を分離できるから」
なぜ分離する必要があるの？
→ 「検証側に秘密鍵を渡さなくて済むから」
なぜ検証側に秘密鍵を渡すとまずいの？
→ 「サービスが増えると秘密鍵を知る場所が増える。1箇所でも漏洩したら全体が危険になる」
3回目の「なぜ」あたりから、本質的な理解が始まる。ここで「逆に、HS256を使うべきケースは？」「RS256のデメリットは？」と逆のケースも聞く。正解だけでなく不正解を知ることで、判断基準が明確になる。
ステップ3: 自分の言葉で要約する
ここまで理解したら、AIの説明をコピペせず、自分の言葉で要約する。
/nippo-add 振り返り: RS256 vs HS256 を理解した 【本質】 - HS256 = 共通鍵。署名も検証も同じ秘密を使う - RS256 = 公開鍵暗号。検証側に秘密を渡さなくて済む 【使い分け】 - モノリス → HS256で十分 - マイクロサービス → RS256一択
書き直せなかったら、まだ理解していない。もう一度ステップ1から繰り返す。
復習のサイクル
ここまでで、2つのことを説明した。日報で躓きを記録すること。そして、その躓きについてAIと徹底的に対話すること。記録と対話。この2つで、学習は起きるはずだ。
でも、実際にやってみると、これだけでは足りなかった。理解しても、忘れる。日報を書いた。AIと対話した。その場では理解した。「ああ、そういうことか」と納得した。でも1週間後、同じことでまた躓いている。「あれ、これ前にも調べなかったか？」。書いただけでは、脳に定着しない。
同じ内容を間隔をあけて復習すると、記憶に残りやすい。だから復習のサイクルを作った。
翌朝（5分）：前日の日報を見返す。見返すだけでいい。「ああ、これ昨日引っかかったやつだ」と思い出す。思い出す行為自体が、記憶を強化する。
実際にやってみると、面白いことが起きた。朝、コーヒーを淹れながら昨日の日報を開く。「RS256とHS256の違い」という項目を見る。「えーと、RS256は公開鍵暗号で...」と頭の中で再生しようとする。すると、昨日は理解したはずなのに、もう曖昧になっている部分がある。忘れかけているタイミングで思い出すことが、記憶を強化する。これを毎朝やるだけで、定着率が全然違う。
週末（30分）：その週の日報をまとめて確認。2回以上出てきた項目は、その場でAIと対話して理解を深める。理解できたらチェックを入れる。
ある週末、日報を見返していて気づいた。「非同期処理」という項目が、月曜、水曜、金曜と3回出てきている。3回も「なぜ」がわからないと書いているのに、そのたびに次のタスクに進んでいた。繰り返し出てくるということは、その部分の理解が止まっているということだ。その週末、2時間かけてPromiseとasync/awaitを徹底的に理解した。翌週から、非同期処理で詰まることがなくなった。
月末（1時間）：月間の傾向分析。3回以上出てきた項目は、根本的な知識の穴だ。書籍を買って体系的に学ぶ。
月末の分析で、自分の弱点のパターンが見えてきた。私の場合、「認証・認可」「データベースの最適化」「インフラ周り」が繰り返し出てくる。これは断片的な理解では対応できない。体系的に学ぶ必要がある。だから、月末に1冊ずつ関連書籍を買うことにした。日報は、次に買うべき本を教えてくれる。
学んだことは、忘れる。これは避けられない。忘却は敵ではない。思い出せないことが敵だ。日報は「思い出すためのフック」を作る作業だ。完璧に覚えようとしなくていい。戻れる仕組みを作ればいい。
人間は意志を保てない。「毎日復習しよう」と決めても、忙しくなれば忘れる。だから仕組みを作る。日報システムは、学習の意志を外部化したものだ。意志に頼らず、習慣に組み込む。
学習時間の設計
ここまで、日報の書き方、AIとの対話の仕方、復習のサイクルを説明した。方法論は揃った。
しかし、ここで当然の疑問が浮かぶ。「いつやるのか？」だ。日報を書く。復習する。わからないことはAIと対話する。週末にまとめて振り返る。どれも時間がかかる。全部やるのは大変そうだ。正直、私もそう思った。
会社によっては、学習時間を労働時間としてカウントしてくれるところもある。成果を出すタイミングと学習するタイミングが違っても、それを認めてくれる環境もある。もしそういう会社にいるなら、堂々と労働時間内で学習すればいい。
ただ、認めなければならない現実がある。成果を出す時間と、学習する時間は、同時には起きにくくなった。かつて労働は最高の学習だった。しかし今は違う。AIと協働する効率化されたプロセスの中では、学習に必要な「摩擦」が発生しない。タスクは完了する。成果物は出る。それでも、脳には何も残らない。効率の代償は、成長だった。これは構造的な問題だ。
だから私は、一度分けることにした。成果を出す時間と学習する時間を、意識的に。成果を出す時間は、AIと一緒に効率よくタスクを消化する。学習する時間は、AIなしで、あるいはAIと徹底的に対話しながら、理解を深める。分けた上で、日報で再接続する。
私の1週間はこうなっている。
月曜 6:00-6:30：先週の日報を見返す。躓いている項目の中で、今週取り組むべきものを3つ選ぶ。カレンダーに学習時間をブロックする。「今週はこの3つを理解すれば、来週の開発が楽になるはず」。仮説を立て、検証し、修正する。学習も開発と同じだ。
水曜 12:00-12:30：昼休みを使って、月曜に選んだ項目を深掘りする。わからないことをAIに問いかけ、徹底的に対話する時間だ。
金曜 6:30-8:30：「素手の時間」。AIなしでコードを書く。「AIがあるのに使わないのは非効率だ」という反論があるだろう。確かに、短期的には非効率だ。でも、AIと働き続けていると、基礎力が衰える。使わない筋肉は、静かに萎える。基礎がわかっていれば、AIの出力を評価できる。基礎が怪しければ、動くまでガチャを回すだけになる。この時間にやることは3つある。日報で見つけた躓きをAIなしで調べる。小さなユーティリティ関数を手書きする。エラーメッセージを自力で読み解く。AIに聞けば5分で済むことを、30分かけてやる。この30分が、理解の深さを変える。
最初の金曜日、2時間が永遠に感じた。簡単なはずの処理が書けない。「こんなことも自分でできないのか」と、情けなくなった。でも、2時間が終わったとき、達成感があった。自分の手で書いた。久しぶりの感覚だった。AIなしで書いてみると、「本当にわかっていること」と「AIに頼っていたこと」の境界が明確になる。自分の実力が、残酷なほど見える。見えるからこそ、対策が打てる。
土曜 朝30分：週の振り返り。3つの項目は理解できたか。理解できなかったものは、来週に持ち越す。完璧を求めない。7割理解できれば、次に進む。
最初は週3時間も取れないと思った。でも、試してみると、この3時間で週の残り37時間の労働効率が上がった。学習は消費ではない。複利で回収できる投資だ。理解が深まると、AIへの指示が的確になる。学習への投資は、労働の効率で回収できる。
私の場合、成果を出すことと学ぶことが自然には重ならなくなった。だから意識的に交差点を作っている。
日報が教えてくれる「次に学ぶべきこと」
ここまで、学習の「方法」を説明した。日報で記録する。わからないことはAIと対話して理解を深める。復習する。学習時間を確保する。これで「どう学ぶか」は揃った。
しかし、「何を学ぶか」は、まだ説明していない。時間は限られている。何を優先すべきか。闇雲に学んでも、効率が悪い。
答えは、日報の中にある。
日報を続けていると、躓きのパターンが見えてくる。同じ項目が繰り返し出てくる。認証。非同期処理。データベース。繰り返し出てくるということは、断片的な理解では足りないということだ。
そこで、日報をインプットのガイドにする。月末に日報を見返して、3回以上出てきた項目を特定する。それに関連する学習リソースを選ぶ。日報は「次に何を学ぶべきか」を教えてくれる。
私の場合、月に技術書を10冊、非技術書を10冊、合わせて20冊前後読んでいる。しかし、これは極端な例だ。最初は月1冊でも十分効果がある。大事なのは冊数ではなく、日報で見つけた躓きに関連する本を選ぶことだ。書籍の良いところは、最低限のクオリティが担保されていることだ。最高のブログは刺さる。でも、最低のブログを引くこともある。書籍は編集者の目を通っている。時間は有限だから、ハズレを引きたくない。日報で繰り返し出てくる躓きを見て、関連する技術書を選ぶ。
書籍だけではない。公式ドキュメントやRFC、OSSのソースコードも読む。二次情報で満足せず、一次情報に戻る習慣。これが理解の深さを決める。使っているライブラリの実装を見ると、設計判断の理由がわかる。上級者向けだが、他社の障害報告書も参考になる。
ポッドキャストも意外と効く。特にリモートワーカーにおすすめしたい。ちゃんと聞かなくていい。BGMのように流しておくだけでいい。リモートワークを続けていると、雑談が絶望的に下手になる。下手になると、雑談をしたくなくなる。したくなくなると、技術的なことを気軽に話す機会が減る。機会が減ると、間違った理解を指摘してもらえなくなる。悪循環だ。技術系ポッドキャストを聞いていると、エンジニア同士の会話のリズムが耳に残る。話題の引き出しも増える。Xで信用できるアカウントをフォローしておくのもいい。タイムラインを眺めているだけで、今何が話題になっているかがわかる。しかし、Xは使い方が難しい。今やアテンション・エコノミーのど真ん中で、みんなが揉めている。情報収集のつもりが、気づいたら論争を眺めて時間を溶かしていることがある。意識的に距離を取る必要がある。
AIに聞けば答えは返ってくる。でも、体系的な理解は書籍や公式ドキュメントでないと得られない。AIは「この問題の解決策」を教えてくれる。書籍は「なぜその解決策が正しいか」を教えてくれる。AIとの協働で生まれた躓きを、AIの外で埋める。
あなたの現在地を見つけるために
ここまで、私がやってきたことを説明した。日報で躓きを記録する。AIと徹底的に対話する。復習のサイクルを回す。学習時間を確保する。日報から次に学ぶべきことを見つける。インプットを選ぶ。
たくさんあるように見えるかもしれない。全部やる必要はない。でも、何かを始める必要はある。
ここまで読んでくれたあなたに、問いかけたい。この1週間を振り返ってみてほしい。AIに聞いて解決したけど、なぜその解決策が正しいのか説明できない問題はなかっただろうか。同じ種類の問題に、何度も遭遇していないだろうか。コードは動いた。でも「なぜ動くのか」を同僚に説明できるだろうか。
もし1つでも「怪しい」と感じるものがあれば、それがあなたの躓きだ。今日から日報に書き始めてほしい。
日報を1週間続けたら、見返してみてほしい。何が繰り返し出てくるか。認証なのか、非同期処理なのか、データベースなのか。繰り返し出てくるものが、次に学ぶべきことだ。そのとき、インプットを意識的に選んでほしい。体系的に理解したいなら書籍。正確な仕様や実装の判断基準を知りたいなら公式ドキュメントやOSSのソースコード。リモートワーカーならポッドキャストもいい。Xで信用できるアカウントをフォローしておくのも悪くない。日報が「次に何を学ぶべきか」を教えてくれる。インプットは、日報を見て選ぶ。
AIに聞けば答えは返ってくる。でも、「なぜその答えが正しいか」を理解するのは、AIの外でやる仕事だ。日報は、その仕事を始める場所を教えてくれる。
おわりに
ここまで、私がやってきたことをすべて説明した。日報、AIとの対話の技術、復習のサイクル、学習時間の設計、インプットの選び方。これらは、私がAI時代に「学ぶ」ために見つけた方法だ。
最後に、1つだけ伝えたいことがある。この記事で一番大事なことだ。
ここまで読んで、気づいた人もいるだろう。私はCLAUDE.mdに学びを書き込んでいる。プロジェクトの文脈、コーディング規約、過去に得た知見。では、AIは賢くなっているのか。答えはNoだ。
AIは何も学んでいない。CLAUDE.mdに書かれた内容は、セッションの最初に読み込まれる。でも、それは「学習」ではない。ただの「入力」だ。AIは前回の会話を覚えていない。経験を蓄積しない。「わからない」を経験しない。AIは、このブログが警告している「学ばない労働者」そのものだ。
CLAUDE.mdを充実させれば、AIの出力は変わる。使い込むほど手に馴染む道具にはなる。でも、設定を書いたのは誰か。あなただ。試行錯誤したのは誰か。あなただ。AIが賢くなったように見えるのは、あなたが賢くなったからだ。
学習とは、経験を意味に変換する行為だ。これが、この記事を通じて私がたどり着いた核心だ。AIは情報を処理できる。でも、AIにとってそれは「意味」を持たない。人間は違う。経験が意味になる。「あのバグを直した」という経験が、「自分はできる」という自信になる。経験を意味に変換できるのは、人間だけだ。
AIと協働しながらも、熟達する主体であり続けるために必要な設計がある。遊びの時間を確保すること。目的のない探索がないと、好奇心が死ぬ。「わからない」状態を意図的に作ること。AIに聞けばすぐわかる。でも、あえて聞かない時間が思考力を維持する。記録を習慣にすること。書かないと忘れる。説明を練習すること。説明できなければ、理解していない。「素手」で戦う時間を持つこと。AIなしでコードを書く時間が、基礎力を維持する。
これらに共通するのは、摩擦・記録・言語化だ。摩擦が経験を生む。記録が経験を残す。言語化が経験を意味に変える。AIはこの3つを肩代わりしてくれる。だから楽になる。でも、肩代わりさせると、人間は主体でなくなる。
最後に、もう一度聞かせてほしい。あなたは最近、「成長している」と感じているだろうか。
もし少しでも不安があるなら、今日から日報を開いてみてほしい。「なぜ:」「試した:」と書いてみてほしい。たった1行、それだけでいい。完璧な日報を書く必要はない。その不完全な1行が、次の1行を呼ぶ。そして、その積み重ねがあなたの脳を取り戻す。
3日で挫折するだろう。私自身、何度も挫折した。でも、4日目にまた始めればいい。何度でもやり直せる。完璧に続けることより、何度でも再開できることの方が大事だ。
1ヶ月後、あなたは変わっている。同僚に「この実装、どうしてこうしたの？」と聞かれたとき、淀みなく答えられる自分がいる。障害が起きたとき、自分のコードを頭の中でトレースできる自分がいる。日報を見返すと、「なぜ:」で埋まっていた項目が、少しずつ減っている。それが、成長の証だ。
あなたの脳は、取り戻せる。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。
