コードレビューをClaudeに頼みながら、ふと手が止まった。「これは本当に自分のコードなのか」という問いが頭をよぎったのだ。
そのとき気づいた。私が感じているのは、便利さへの感謝でも、効率への満足でもない。どこか奥底に沈んでいた**「委ねることへの罪悪感」**だった。
個人開発を続けて10年以上になる。アプリを一人で設計し、コードを書き、ストアに並べる作業を繰り返してきた。その過程で培ってきた「全部自分でやる」という感覚は、誇りでもあり、アイデンティティでもあった。
Claudeを使い始めて約1年。その感覚が静かに、しかし確実に変わった。
最初は「任せたら負け」だと思っていた
使い始めた頃の私は、Claudeをあくまで「補助輪」として位置づけていた。行き詰まったときだけ使う。アイデアが浮かばないときに候補を出してもらう。そういう使い方だ。
その根底には、はっきりした不安があった。「AIに依存したらスキルが落ちるのでは」という感覚だ。エラーをClaudeに投げるたびに、自力でデバッグする力が落ちていくのではないか。
この不安は多くの開発者が感じていると思う。でも今から振り返ると、この考えは問いの立て方がそもそも間違っていた。
スキルが落ちるかどうかより、問うべきは「どんな種類の思考に時間をかけるべきか」だった。
転換点：「なぜ」を問うことをやめていた自分に気づいた
変化のきっかけは、些細な出来事だった。
SwiftUIのアニメーション実装でClaudeに相談したとき、返ってきたコードを何も考えずに貼り付けた。動いた。でも翌週、別の画面で似た実装が必要になったとき、また同じ問いをClaudeに投げていた。
// 使っていたのにパラメータの意味を理解していなかったコード
withAnimation(.spring(response: 0.4, dampingFraction: 0.7)) {
isExpanded.toggle()
}response と dampingFraction が何を意味するのか、まったく理解していなかった。コードを受け取っただけで、吸収していなかった。
これは依存の問題ではなく、使い方の問題だった。
「委ねる」と「丸投げする」の間にある溝
私が学んだのは、Claudeに何かを依頼するときの「問いの質」を変えることだった。
以前の問い方：
「このSwiftUIアニメーションのコードを書いて」
変えた後の問い方：
「springアニメーションのresponseとdampingFractionが実際の動きにどう影響するか教えて。その上で、ボタンを押したときに自然に見える展開アニメーションを実装したい」
この違いは、表面的には小さく見える。でも返ってくる回答の質と、自分の理解の深まり方がまるで違う。
前者はコードを受け取って終わり。後者は原理を理解した上で実装を選択できる状態になる。
「委ねる」とは、判断を手放すことではない。判断に必要な情報の収集を効率化することだ。
この区別が腑に落ちたとき、Claudeとの向き合い方が変わった。
Claudeが不得意なことを知って、自分の強みが見えた
Claudeと深く使っていると、明確に「これは苦手だな」と感じる場面が出てくる。
たとえばユーザーの感情的な体験設計だ。「このボタンを押したとき、ユーザーにどんな気持ちになってほしいか」という問いに対して、Claudeは確かに答えを出す。でもその答えは、どこかテンプレート的で、私が何年もかけてアプリを触り続けてきたユーザーへの解像度には及ばない。
あるいは、自分のアプリのブランドトーン。なぜこのアプリがこの色使いで、このコピーなのか。その背景にある感覚的な積み重ねを、Claudeはゼロから再現できない。
この「不得意な領域」を観察することで、逆説的に自分が大切にしてきたものの輪郭がはっきりした。
私にとって個人開発は、機能を作ることではなく、使う人が「このアプリ、好きだな」と思う瞬間を作ることだ。その核心部分は、Claudeに委ねられない。だからこそ、それ以外の部分を積極的に任せることへの罪悪感が薄れていった。
変わったのは速度ではなく「思考の密度」だった
よく「AIを使うと10倍速くなる」という言い方をする人がいる。実感として、それは半分正しく、半分違う。
確かに実装速度は上がった。でもそれより体感として大きいのは、同じ時間でできる思考の量が増えたことだ。
以前は1時間のうち半分をコードの構文エラーやドキュメント検索に使っていた。今はその時間を「このアーキテクチャで本当にいいのか」「この機能はユーザーに必要か」という問いに使える。
実装の細部をClaudeに任せることで、自分が設計と判断に集中できる。それは単なる効率化ではなく、自分がどこに知的エネルギーを使うかの再配分だった。
実際に変わったワークフロー
具体的にどう変わったか、一例を挙げる。
以前の私は、新機能の実装を始めるとき、まず「どう書くか」から考えていた。構文、API、ライブラリの選択——実装レイヤーから入るのが習慣だった。
今は順番が逆になった。まず「なぜこの機能が必要か」「誰のどんな問題を解くか」を言語化する。そのあとClaudeに「この問題を解くために、iOSで使える主なアプローチをそれぞれのトレードオフと一緒に整理してくれ」と投げる。
選択肢の整理はClaudeが圧倒的に速い。私はその整理された選択肢を見ながら「自分のアプリとユーザーにとってどれが最善か」を判断する。この順番になって初めて、自分が本当に意思決定をしていると感じられるようになった。
今感じている「協働」の形
1年を経て、私のClaudeとの向き合い方はこうなった。
Claudeに任せること：実装の起草、エラーの初期診断、ドキュメントの要約、テストコードのひな形、定型的なリファクタリング、選択肢の列挙とトレードオフの整理。
自分が判断すること：アーキテクチャの選択、ユーザー体験の核心、ブランドトーン、技術的トレードオフの最終判断、「作るべきかどうか」という問い。
このリストを見ると、後者のすべてが「答えが一つではない問い」であることに気づく。Claudeが得意なのは、正解がある（または探せる）問いへの回答だ。正解が存在しない問いに対する判断は、依然として人間の仕事だ。
「委ねる」ことへの最初の抵抗感は、この区別が見えていないことから来ていたのだと思う。
もし今「AIに任せすぎると自分のスキルが落ちるのでは」と感じているなら、一度こう問い直してほしい。
「自分が磨きたいスキルは、何の問いに答える力なのか」
その問いへの答えが明確になれば、Claudeに任せるべきことと、絶対に自分でやるべきことの境界線が見えてくる。委ねることは、諦めることではない。自分が本当に集中すべき場所を守るための、一つの選択だ。