こんにちは！代表取締役 兼 AIサービス開発室の鈴木生雄です。
私は、 Claude Codeを用いたSDD開発の実践 に記したように、1月に入ってから毎日のようにClaude Codeを使っています。そこで実感したことは以下の二つです。
- AI×プログラミング、相性が実は最高（文書やコード等のまとまったコンテキストを渡しやすいため）
- コーディングエージェントは凄まじい速度で性能向上している（毎日のようにバージョンアップがある）
このことから私は、当社が身を置く「企業向け業務アプリケーション開発」の業界においても、早晩コーディングエージェントが当たり前に使われるようになると考えています。
しかしそうなってくると、AIが圧倒的なスピードでコードを生成するため、レビューをする人間がボトルネックになるのは必至。コーディングをAIに任せつつ、技術力をいかにして身に着けるかはとても重要な論点です。
そういうふうに考えていた最中の2026年1月28日、Anthropicのアラインメントチームが最新の研究レポート「How AI Impacts Skill Formation」（AIがスキル形成に与える影響）を発表しました。
How AI assistance impacts the formation of coding skills – Anthropic Research News
Paper : How AI Impacts Skill Formation – Arxiv
今回、全文を読んでみたので、その概要と私の目に留まったところをご紹介します。
論文の概要
本論文では、AI支援が「作業の速さ」だけでなく「学習（スキル形成）」にどう影響するかを確かめるために、開発者を対象とした理解度確認テストを行っています。
参加者（Python経験はあるが、対象ライブラリ Trio は未経験）を AI支援あり と AI支援なし の2群にランダムに割り付け、まず全員がAIなしでウォームアップ課題を実施。その後、Trioを使う2つの非同期プログラミング課題に最大35分取り組ませました（AI群のみチャット型AIが利用可能）。課題終了後は両群ともAI使用を禁止した状態で、Trioの理解度を測る確認テスト（概念理解・コードリーディング・デバッグ中心）を受験させ、「タスク完了時間」と「理解度確認テストのスコア」を主要指標として比較しました。
さらに、参加者の画面録画とAIへの問い合わせログをもとに、AIの使い方を複数のパターンに分類し、学習成果を保ちやすい使い方／損ないやすい使い方の違いも質的に分析しています。
目に留まったところ
ここでは、論文の中で私の目に留まった箇所を挙げて解説しつつ、感想を述べたいと思います。
「AI支援あり」よりも「AI支援なし」の方がテストの結果がよい
以下は、AI支援あり と AI支援なし のグループそれぞれが、課題に実施の所要時間（左）、理解度確認テストのスコア（中央）、AI支援の有無による影響度を表す標準偏差（右）のエラーバー付きプロット（エラーバーは95%信頼区間、プロットは平均値）です。
左図と中央図にあるp(probability)値とは、帰無仮説（差や関係がないという仮説）が正しいとして、今回観測された結果と同じくらい（またはそれ以上に）極端な結果が、偶然だけで起きる確率のことです。一般にp ＜ 0.05で有意差あり、p ≧ 0.05で有意差なしと判断するようです…。ややこしいですが、つまり、課題実施の所要時間の差は有意差なしだが、理解度確認テストのスコアの差は有意差があるということを表しています。
また、右図のAI支援の有無による影響度については、コーエンの基準という統計的効果量（Effect Size）の大きさ（小・中・大）を示す基準では、0.2 で小、0.5 で中、0.8 で大とみるらしいので、AI支援の有無が理解度確認テストの差に与える影響は中～大と言えそうです。
課題実施の所要時間に有意な差が認められなかったのは意外でしたが、今回の検証ではAIチャットを使っていたためではないかと思いました。使うAIがコーディングエージェントだったら有意な差が出ていたかもしれません。理解度確認テストのスコアについては、影響はあると予想はしていたものの思った以上に大きな差が出ていました。この結果を見る限り、同じ時間をかけても、AIを使ってコーディングをすると自力でコーディングするよりも理解が深まらないことになります。
デバッグに関する問題で特に差が顕著
以下は、理解度確認テストの出題区分（タスク（課題の一つ目または二つ目）および問題タイプ（概念、デバッグ、またはコードリーディング））ごとのスコア獲得率のエラーバー付きプロット（エラーバーは95%信頼区間、プロットは平均値）です。注目すべきはデバッグに関する問題において、AI支援あり と AI支援なし の平均スコアの差が最も大きかった点です。
デバッグに関するスコアの差は次に示すAIに対するクエリーの内容（言い換えると、AIの使い方）を合わせてみると、実践に役立つ洞察が得られると思いました。
デバッグクエリーの割合が高いユーザーはテストの結果が悪い
以下は、AIへのクエリー回数と理解度確認テストのスコア（左）、デバッグに関するクエリの割合と理解度確認テストのスコア（右）の散布図です。なお、両方の図にあるr値は相関係数（2変数間の直線的な関係の強さと向き（-1〜1））を表します。p値は前述のとおりです。この二つを組み合わせて両図を読み解くと、クエリー回数と理解度確認テストのスコアは負の相関があるが有意差(p ≧ 0.05)なし、デバッグに関するクエリの割合と理解度確認テストスコアは負の相関があって有意差あり(p ＜ 0.05)ということになります。
これは直感的にも分かる気がするんですよね。AIにエラーメッセージを打ち込むと「xxxxというコマンドを打ち込んでください。」とか、「調査のためにログ中のxxxxのメッセージを貼り付けてください。」という感じにユーザーに手順を案内してくれる場面をよく見ます。本当は手順を実施する理由も回答内に含まれているのですが、デバッグ中は結果を焦る気持ちも相まって、ひたすらに手順を貼り付けて終わるということになりがちです。当然ながらこれだと理解は深まりません。私は、デバッグやトラブルシューティングが発生した時に、紆余曲折しながら時間をかけてそれに向き合うことで技術力が高めてきた口なので、技術力を高めるせっかくの機会が、AIに頼りきりになることによって無駄になってしまうのはもったいないと思います。これはAIの使い方の典型的なアンチパターンと言えると思いました。
では、デバッグにはAIは使わない方がよいのかというと、私は使った方がよいと思います。ただし、AIが示す手順だけを追うのではなく手順の裏にある理由を読み取って、その中に知らないキーワードや概念が出てきたらその都度AIに更問をして理解しながら進めるべきだと思います。しかし、これ言うのは簡単ですが、デバッグに必要な知識体系全体を俯瞰した上で自分の現在地を把握するメタ認知力と幅広い知識体系を探索し続ける体力が必要なので、上手くやるのは結構難しいです。
まず、メタ認知力について、何か質問した際の回答に自分の知らないキーワードが含まれていることはよくあることだと思います。そういう時はそのキーワードとは何かを更問する。すると、その回答にまた知らないキーワードが含まれているので更問する（以降、その繰り返し）。そういうふうに質問を展開していきながら、周辺知識を含めてツリー構造状に知識を獲得していくことが大切だと思います。そしてこの際、自分がツリーのどこにいるかを把握できる力こそが、ここで言うメタ認知力です。要は迷子にならずに元の道を引き返せるかという問題なのですが、これができると、知識を体系的にインプットできるので定着しやすくなります。何より迷子になって元々のデバッグ作業に戻れないと困ってしまいますよね…。ちなみに、更問を重ねていくとAIのコンテキストに余計な情報が載ることになりますが、それを避けるためのバックトラックしたり分岐したりする機能が大抵のAIには搭載されていますので、ぜひ使っていきましょう。例えば、Claude Codeでいうと、/rewind や /forkがそれにあたります。（以下のZenn記事がわかりやすいので参照してください。）
Claude CodeのPlanモードで実装した後、そのまま質問しまくってるやついる？いねえよな！ – Zenn
続いて、体力について、ここでは、考え続ける力というか、わからない状態を許容しつつ探索し続ける力というか（言語化が稚拙ですみません。）が重要だということを言いたいです。デバッグをしていると、思い通りに動作しない、いわゆるハマることがよくあります。そういう時は誰しもが、仮説を立てては検証を繰り返すと思いますが、人によってはこの上手くいくかどうかがわからない状態に、強いストレスを感じるかもしれません。私は、そういう場面では、自分の技術力を高める”大チャンス”ととらえるとよいと思います。なぜなら、そうするとゲームみたいな感じがして面白くなってくるからです。仕事ではとにかく結果を要求される現実的な側面もありますが、これを乗り越えたら自分がレベルアップする（RPGだったらファンファーレが鳴っているくらいの）イメージを持てると考え続ける活力につながるのでおすすめです。ただ、それだけで深く考え続けられるかというと、そんなに簡単ではありません。フィジカルな体力とか、深く思考できる特性とか先天的な要素も必要だと思いますし、5W1Hとかクリティカルシンキングとか思考フレームを知っているという後天的な要素も必要だと思います。しかし、やはり一番簡単に実践できるのは「デバッグは自分の技術力を高める”大チャンス”」ととらえて立ち向かうことですね。
理解度に影響を与えるAIの使い方には類型がある
以下は、AIへのクエリーの類型、クエリーの数、タスクあたりのクエリー数、アクティブ時間（AIとのやりとりではなくコーディング使った時間）という四つの要素に基づいて、AIとのやり取りの仕方を下記の六つに類型し、タスクの完了時間（横軸）と理解度確認テストの結果（縦軸）にマッピングした図です。
【AIとのやり取りの仕方類型】
- AIへの委譲（AI Delegation）（n=4）：完全にAIに頼る
- 段階的なAI依存（Progressive AI Reliance）（n=4）：一つ二つの質問から始めるが最終的にはすべてをAIに頼る。
- 反復的なAIデバッグ（Iterative AI Debugging）（n=4）：コードのデバッグ検証をAIに頼る。※本ブログで前述した使い方。
- 生成後の理解（Generation-Then-Comprehension）（n=2）：自分の理解を深めるためのフォローアップ質問をAIにする。
- コード・説明ハイブリッド（Hybrid Code-Explanation）（n=3）：コード生成とともにコードの説明をAIに求める。
- 概念的な問いかけ（Conceptual Inquiry）（n=7）：概念的な質問のみをAIに行い、向上した理解に基づいてタスクを完了させる。
この図からは、先の類型のうち上三つ（AIへの委譲、段階的なAI依存、反復的なAIデバッグ）は理解度が低く、下三つ（生成後の理解、コード・説明ハイブリッド、概念的な問いかけ）は理解度が高いという主張が見てとれます。私は、実験結果を踏まえた、とても合理的な主張だと思います。また、”概念的な問いかけ”の有効性が示されたことは注目すべき点だと思います。結局のところ、大元にある本質的な考え方を理解することが大事ということではないでしょうか。論文内の実験で例えると、trioというPythonの非同期並行処理のライブラリの設計思想を把握すれば、機能やその使い方を理解しやすくなるということだと思います。
まとめ
今回はAnthropicがAnthropicのアラインメントチームが発表した論文「How AI Impacts Skill Formation」（AIがスキル形成に与える影響）の解説をしました。私自身、AIを使う功罪のうち、罪の部分に問題意識はあったのですが、これまでは上手く他者に伝えることができませんでした。Anthropicがこのような論文を出してくれたおかげで、おぼろげに考えていたことを一定の説得力を持って説明できるようになったことが一番の収穫です。
なお、今回は特に、エモーショナルな個人的主張が多く混じっていた点、ご容赦ください。社長が自分の言葉で考えていることを発信する点に価値があると信じていますので、今後もこのスタンスでブログを書いていきます。引き続きお付き合いいただければ幸いです。