Anthorpicが世に送り出した「Claude Code」に、脳内を震度７でかき回されました。
Devinが出始めた頃は、「お！ええやん！これから楽しみだな！」ぐらいのテンションでした。無邪気ですよね。でも、Claude Codeは「マジかよ・・・（言葉にできない感情)」になりました。人間がコードを書く時代は終わったと頭では思っていても、どこかで「ふーん」ってシニカルでいた自分が、「・・・はい！」と向き合うことができた。
僕のまわりのベテランが腕まくりしてる
40代の友人知人が、Claude Codeでプログラミングに脳汁が出まくっている様子がSNSやリアルで散見されます。自分が今まで手を付けなかった部分の学習をしたり、今まで書いたコードを書き直してもらって「おっほ〜」をキメたり、並行で走らせてペアプロやIssue潰しをやってるようです。
僕が試しているのは以下のちょっとしたトライです。こんな感じ。結果には満足しています。
- 「この指示でどこまで行けんの？」
- 「これとそれのサンプルコードとテスト書いて」
- 「このコードを純粋関数でリファクタリングして欲しい。」
- 「ここにあるコード読み解いて、サマリをまとめて、型の設計について教えて」
僕の能力を超えたAIがコミュニケーションを取ってくれるので、乾いたスポンジに水がグングン染み込んでる感覚を、45になった自分が得られるのが嬉しい。自分の能力の限界を超えてコードを読み解いてくれるので、刺激になります。
適切に設計されていれば実装スキルは新卒程度でよい
この指摘は正しいです。僕も賛同します。
触ってみて感じたのは、「適切に設計されていれば必要な実装スキルは新卒程度でよい」「規模が大きくなると実装の手数が線形以上に増えるので短期間で手数を多く打てる体力が生産性にめっちゃ効く」ということであり、逆に言うと「実装スキルなんてものは人間が思ってるほど重要じゃない」ってこと https://t.co/MyTns0c2BR
— まんじまる (@_manji0) 2025年6月18日
自分はFlutterを1から覚えリードを経て足掛け3年ほどやりましたが、上記の通りです。
簡単に言うと、UIを構築するコード自体に、大きな差は出ません。Text("hello world") レベルのコードに差はありません。何かを表示する「だけ」のコードに、ベテランの匠の技は必須ではありません。いくつかのお作法と、プロジェクトのルールが有るぐらい。
差が出るのは、Flutterがどういう課題感を持ってアプリ開発をしたいと考えているのか、設計思想、状態の管理、ScreenとComponentの分割、エラーハンドリング、APIクライアント、ルーティング、デザインのテーマ / コンポーネント化などです。アーキテクチャで大きな差は出ない。
これらの設計（決め事）によって各々のUIを実装するコードは均一化され、単純化されます。コンテキストが煮詰まって、ノウハウに結実します。ノウハウが結実したら、単純な作業になって然るべき。クラスとオブジェクトの違いがわかり、無名関数でイベントハンドラが書けるぐらいで、受入可能でした。
上記の設計も踏まえて実装ではありますけど、誰が書いても変わらない部分と、誰かが手を入れて決め事を用意しないと破綻する部分があるはずです。前者の領域が生成AIによって拡大します。ここは、疑う余地を感じなかったです。後者の領域は、個別最適なのでまだまだ残ります。
あと、生成AI時代でコードが捨てやすくなったと思う！これが大きいんじゃないかな。コードはどんどん捨てるべき。リファクタリングはコードを捨てて作り直すことで新陳代謝を促す行いだと思っていて、形式的な置換をするのはあんまり意味がない。どうせAIで作り直す前提に立てば、すべきことはテスタビリティの確保・改善だと思います。常識が生成AI側でアップデートされるので、人類はそれに乗るだけになっちゃうかも。
そうは問屋が卸さないぞ！
待ってました、この種のご指摘。
この話、何十年か前に同じことを言ってたんですよ。「適切に設計がされていればプログラマは外注や下請けでもいい」とかそういうやつ。
— Yuta SAWA (@sawawww) 2025年6月18日
その結果どうなったかと言うと、という。 https://t.co/reOKVua6Ci
僕も下請けに出した立場も下請けも両方SIer時代に経験しました。テンプレ設計書で記載できる内容が弱すぎて、コードを書くまでに人間が様々な補完をしなければなりません。実装未経験のざっくり仕様書を出される、など。この種の工程の分断があっては、どうしようもない。
だけど、Claude Codeを初めとした生成AIには、工程の分断が起こりません。ヒトが介在する余地がないから。指示するのと作るのが同じ人間（チーム）のはずです。ざっくり仕様書からコードへの行間は存在しますが、行間を埋める能力は愚かな人類の比ではない。まだ黎明期。上がる一方で、下がる理由がありません。生成AIは工程の分断を殺すキラーアプリケーションになり得ますが、そこまで踏み切る決断ができるかは、別問題。
AIに指示を出すところを丸投げする多重下請け構造を生み出しちゃうかもしれなくて、それが令和の怪談になったらどうしよう。
AIによって普通のハードルが上がってしまう
これは「教育用途で渡すべきタスクをAIに投げたら秒で仕上げてきちゃうんで、若手の育成どうするの」と問題と、「生成AIが強くても、指示を出す自分が最大のボトルネックになり、試行錯誤の楽しみも薄れる / 逃げ場がない」問題の2つがあると思います。
後者は自分なりの立ち位置を掴むしか無い個人的な問題ですけど、前者は根が深い。生成AIが当たり前のプログラミング教育 is 何を、議論し始めないといけないと思います。
若手の育成機会のみならず、フリーランスエンジニアの副業も、減ります。副業のアウトプットがボトルネックで本業に支障が出るように座組を組む組織はないですから、調査・分析・リファクタ系のタスクを投げるケースが多いと思うんですけど、それらは生成AI(Claude Code)の大得意分野です。はじめの一歩の腰が重い優先度ちょい低め系のやつ、持っていかれます。
IaCは最もテンプレ化しやすい領域だと思いますが、そのIaC自体が正しいかは別物だろうし、監視も含めるとそんなに単純な気はしない。コードで運用が自動化できるわけじゃないし、複数の異なるサービスが絡むと思うので。IaC/SRE領域のニーズは生成AI時代も極めて堅調に僕には映る。見当違いだったらすいません。
Claude Codeのようなものが、文章・レポート・音楽・画像・動画・音声の領域に食い込んでくることは明白です。これは間違いないと思う！
月並みだけど、推進力がモノを言いそう
自分が一番得意なのは、↑に書いたようなあるお題を多面的に見て、言語化することです。僕のブログが少なからず読まれているの、コレしか無いと思うので・・・。
考えてもらうことは生成AIで行けるけど、考える意味は自分が言語化するしか無いっす。言語化して、その構造を整理してテーブルに乗せれば議論できる余地が生まれて、メリデメが整った選択肢が作れる。そこから判断と決断が生まれる。そういう目に見えない推進力を、自分は大事にしたい。事実と理想の狭間には、相当深い谷がありますから。
月並みだけど、ソフトスキルもハードスキルも、磨いていくしかないですね。AIと壁打ちしながら、自分で一歩ずつ考えて、進みましょう。乗るしか無いんだから！このビックウェーブ！
