コワーキングスペース 代表 鶴田 賢太 AI時代はコードをAIに任せ、人間は「何を作るか」「どう改善するか」を設計する力を設けるべき。プログラミング言語の深い理解は不要で、課題発見とAIへの的確な指示・誘導、UXの気づきが核心。Room8の実例と「作りながら改善」する開発サイクルを通じ、最重要は設計力と対話力。
- AIはコードを作れるが、何を作るかを決めるのは人間。設計力が鍵
- 動くか・使いやすさを見極める気づきと、AIへ的確に指示・誘導する対話力が核心
- 作りながら改善する開発サイクルで、プロトタイプ→評価→改善を回す
こんにちは、Room8オーナーの鶴田です!
最近、CursorっていうAIエディタでコワーキングスペースの管理アプリを作ってるんですよ。会議室の予約システムとか、チェックイン機能とか。で、これがまあ面白くてですね。
「AIでコーディングできる時代になった!」って聞くじゃないですか。それで始める人めちゃくちゃ多いんですよね。でもね、みんな何やってるかっていうと、プログラミング言語の勉強を始めてるんですよ。Pythonの文法とか、JavaScriptの書き方とか。
いや、それ学ぶのそこじゃないよ！って思うわけです。
実際に87.5%の人がプログラミング学習で挫折してるっていうデータがあるんですけど、これ2019年の調査なんですよ。今2025年。AI使える時代に、同じ轍を踏む必要ないじゃないですか。
この記事では、僕が実際にRoom8アプリを開発して分かった「AIでアプリ作る時代に本当に学ぶべきこと」を、具体例つきで解説します。結論を先に言うと、コーディングはAIに任せて、人間は「何を作るか」「どう改善するか」を考える力を磨くべき、って話です。
みんな何を学ぼうとしてる?
「AI使えばコーディングできる!」の落とし穴
Twitterとか見てると「ChatGPTでコード書けた!」「Cursor最高!」って投稿、たくさんあるじゃないですか。で、そういうの見て「俺もやろう」って始める人が増えてる。これ自体は良いことなんですよ。
でもね、次の瞬間からプログラミング言語の学習を始めちゃうんですよね。「まずはPythonの基礎から」とか「JavaScriptの文法を覚えよう」とか。
ちょっと待てよ、と。
2025年のガートナーの調査によると、コード生成・補完でのAI利用率は49%に達してて、前年比で約2.5倍に増えてるんですよ。つまり開発者の半分はもうAIにコード書かせてるわけです。この状況で、プログラミング言語の文法を必死に覚える意味って、正直あります？
AIができること・できないこと
ここで整理しておきたいんですけど、AIができることとできないこと、分けて考えないといけないんですよね。
AIができること:
- コードを書く
- エラーを修正する
- リファクタリングする
- ドキュメントを書く
AIができないこと:
- 何を作るか決める
- 使いづらさに気づく
- どう改善すべきか考える
- ビジネス要件を理解する
MicrosoftとかAccentureとかでの大規模実験（4,867人参加）で、AIツール使うとタスク完了数が26%増えるって結果が出てます。でもこれ、「AIに何を作らせるか」を人間が決められる前提の話なんですよね。
逆に言うと、AIに指示できなきゃ意味ないわけです。
「コードを理解しなきゃ」という思い込み
AIが書いたコード、読んでない？
これ、めちゃくちゃあるあるなんですけど。
AIにコード書かせるじゃないですか。で、出てきたコードをじーっと眺めて「これ何してるんだろう…」って考え始める人、多いんですよ。それでStack Overflowで調べたり、プログラミングの入門書読み始めたり。
気づいたら結局プログラミングの勉強してるんですよね。
侍エンジニアの調査だと、プログラミング学習の挫折理由の31%が「わからないことが多すぎる」、25%が「エラーの解決に時間がかかる」なんですよ。でも待って。AIいるじゃん。
でもそれ、必要ない
ここで衝撃の事実なんですけど、コードの中身を理解する必要、実はないんですよ。
車の運転で考えてみてください。エンジンの仕組み知らなくても運転できるじゃないですか。ブレーキ踏んだら止まる、アクセル踏んだら進む。それだけ分かってれば運転できる。
プログラミングも同じで、大事なのは：
- 動くかどうか
- 意図した通りに動くかどうか
- バグがないかどうか
これが確認できればいいんですよ。中のロジックがどうなってるかなんて、正直どうでもいい。
エラーが出たらどうする？
「でもエラー出たらどうするんですか？」って思いますよね。
簡単です。エラーメッセージをそのままAIに投げる。
こんなエラー出たんだけど:
[エラーメッセージをコピペ]これだけ。AIが直してくれます。
実際、GitHub Copilot使ってる開発者の60%が日常的に使ってるんですけど、彼らがやってるのもこれなんですよ。エラー出る → AIに聞く → 直してもらう。このループ。
プログラミング言語の深い理解なんて、後からでいい。必要になったら学べばいい。最初から完璧に理解しようとするから挫折するんですよね。
実例で解説 – Room8アプリ開発で分かったこと
Room8アプリって何?
さて、ここからは僕が実際に作ってるアプリの話をしましょう。
Room8っていうのは、僕が春日井市で運営してるコワーキングスペースなんですけど、その管理システムを今Cursorで作ってるんですよ。機能としては：
- 会議室の予約システム
- チェックイン/チェックアウト機能
- 会員管理
- 決済処理
こういう感じのやつ。まだ完成してないんですけどね（笑）
で、このアプリを作ってて痛感したのが、「人間がやるべき仕事」と「AIに任せる仕事」の違いなんですよ。
開発中に気づいた「人間がやるべき仕事」
実際に開発してると、こういう流れになるんですよね：
- 課題の発見 ← これが人間の仕事
- AIに「なぜ？」と聞く ← AIから情報を引き出す
- 原因を理解する ← AIの回答を理解する
- 「じゃあこうすれば」と方向性を示す ← AIを誘導する力
- AIに実装させる ← AIの仕事
ここで重要なのが、1番の「課題の発見」と4番の「誘導する力」なんですよね。
なぜかっていうと、1番はユーザビリティの問題だから、実際に使って「遅い！」って感じるのは人間にしかできない。
そして4番が意外と重要で。AIに「どうすればいい？」ってだけ聞いても、イマイチな提案が返ってくることが多いんですよ。でも「こういう方向でどう？」って示してあげると、AIはそれを実現するコードを書いてくれる。
つまり、AIとの対話を通じて、正しい方向に誘導する力。これがAI時代に必要なスキルなんですよね。
次のセクションで、具体的な例を2つ出して説明します。
【実例1】Googleカレンダー連携の高速化
課題: 予約画面が遅い
会議室の予約画面作ったんですよ。で、動かしてみたら、画面開くたびにめちゃくちゃタイムラグがあるんですよね。2〜3秒くらい。
これ、実際に使ってみて気づいたんですよ。コード書いてる時は気にならなかったんですけど、実際にスマホで「予約しよう」って開いたら「遅っ！」って。
ここが重要で、実際に使ってみないと気づかない問題ってあるんですよね。
分析: なぜ遅いのか?
で、ここからが重要なんですけど。
「遅い」って気づいたのは僕。でもなぜ遅いのかは、正直よく分からないんですよ。だってコード書いたのAIだから。
だからAIに聞くわけです。
なぜ遅いと思う？そしたらAIが教えてくれるんですよね：
- 「毎回Googleカレンダーにアクセスしてる」
- 「1週間分の予定を取得するのに90回くらいAPIアクセスしてる」
- 「ページ開くたびにこれやってる」
あー、そういう仕組みだったのか、と。
ここがポイントで、AIから情報を引き出して、理解するって作業なんですよ。自分でコード読んで理解する必要はない。AIに聞けばいい。
設計: どう解決するか?
で、原因が分かったら、解決策を考えるわけです。
毎回90回もAPIアクセスしてたら遅いに決まってるじゃん。じゃあどうする？
ここで僕が思ったのが、「DBと同期させればいいんじゃない？」ってこと。
DBにキャッシュしとけば、ページ開くときはDBにアクセスするだけ。APIアクセスしなくていいから速い。でもGoogleカレンダーとの同期はどうする？Webhookでリアルタイム同期させて、念のため深夜3時に定時同期も入れとこう。
こういう方向性を示すんですよ。
ここが重要で、AIに「どうすればいい？」ってだけ聞いても、イマイチな提案が返ってくることが多いんですよね。でも「こういう方向でどう？」って示してあげると、AIはそれを実現するコードを書いてくれる。
つまり、AIを正しい方向に誘導する力なんですよ。
AIから「なぜ遅いか」の情報を引き出す → 理解する → 「じゃあこうすれば」と方向性を示す → AIに実装させる。
この対話プロセス。これがAI時代の「設計力」なんですよね。
Cursorへの指示
で、設計ができたら、Cursorに指示するわけです。
今毎回Googleカレンダーから全予定を引っ張ってきてるから遅い。
DBにキャッシュして、Webhookでリアルタイム同期させて。
念のため深夜3時に定時同期も入れて。これだけ。
あとはCursorが勝手にコード書いてくれます。Webhook設定のコードも、DB設計も、定時処理のcronも、全部。
AIはこの指示をコードに落とすだけなんですよ。
重要なのは、「課題を見つけて、分析して、解決策を考える」という1〜3のプロセス。ここができれば、あとはAIが仕事してくれる。
【実例2】タイムピッカーUI改善
最初はクルクル回すUI（タイムピッカー）
会議室の予約で、時間選択するUIがあるじゃないですか。最初、iPhoneでよく見るタイムピッカー（時間をクルクル回して選ぶやつ）にしてたんですよ。
時間をクルクル回して選んで、分をクルクル回して選んで。
で、実際に使ってみたら、めちゃくちゃストレスなんですよね。
10時13分とか、要らんやろ！って。会議室予約で13分スタートとかないじゃないですか。せいぜい10時か10時30分。
これも、実際に使ってみて気づく問題なんですよね。
どう改善したか
じゃあどうしたかっていうと：
- カレンダーの○（19時の枠）をクリックしたら
- 開始時間に「19時」と「19時30分」だけ表示
- 利用時間も「1時間」「1.5時間」「2時間」で選択
こういうUIに変えたんですよ。
これ、ユーザー視点での設計判断ですよね。「どうしたら便利か」を考える。プログラミングの知識じゃなくて、UX設計の話。
AIに指示するだけで即実装
で、設計が決まったら、Cursorに：
タイムピッカーやめて、カレンダーの○クリックしたら開始時間を30分刻みで表示して。
利用時間は1時間、1.5時間、2時間の選択式にして。これだけ。
あとは勝手に実装してくれる。UIコンポーネント変えて、状態管理変えて、バリデーション追加して。全部やってくれるわけです。
動作で言うとこんな感じ
従来との違い
ここで重要なのが、従来との違いなんですよ。
従来の開発:
- 作り直し面倒だから諦める
- 「まあこれでいっか」で妥協
- 使いづらくても運用でカバー
AI時代の開発:
- 気に入らなければ即変更
- 指示するだけで実装される
- 作り直しコストが激減
だから、「最初から完璧に設計しなきゃ」っていうプレッシャーがないんですよね。とりあえず作って、使って、気づいて、直す。このサイクルが回せる。
AI時代の開発スタイル: 「作りながら改善」が最強
従来の開発
従来の開発って、こういう流れだったんですよね：
- 完璧な設計を目指す
- 作り始める
- 途中で「あれ？これ使いづらくない？」って気づく
- でも作り直すの面倒だから妥協
- 結局使いづらいまま運用
なぜこうなるかっていうと、作り直しコストが高いから。コード書き直すの大変じゃないですか。だから最初から完璧を目指そうとする。
でもそれ、無理なんですよね。実際に使ってみないと分からないことって、絶対あるから。
AI時代の開発
AI時代は違うんですよ：
- とりあえず作る（完璧じゃなくていい）
- 実際に使ってみる
- 「これストレスだな」って気づく
- AIに指示して即改善
- また使って、また改善
このサイクル。
作り直しコストが激減したから、「とりあえず動くもの作って、使いながら改善していく」ってスタイルが取れるんですよね。
実際、経験の浅い開発者でもタスク完了数が39%増えるっていうデータがあって、これまさにAIの恩恵なんですよ。
これがAI時代の開発の本質
ここが一番重要なんですけど、AI時代の本質は「作り直しコストの激減」なんですよね。
だから：
- 最初から完璧目指さなくていい
- プロトタイプをすぐ作れる
- 使いながら改善できる
- 失敗してもやり直せる
こういう開発スタイルになる。
逆に言うと、学ぶべきは「プロトタイプを作って、評価して、改善する」っていうサイクルを回す力なんですよ。コーディング能力じゃない。
じゃあ何を学べばいいの?
学ぶべきは「AIとの対話力」
ここまで読んでくれた人は分かると思うんですけど、学ぶべきは：
最重要：
- 使いづらさに気づく力（ユーザー視点）← これだけは人間にしかできない
AIとの対話力：
- AIから情報を引き出す力（「なぜ？」と聞く）
- AIの回答を理解する力（技術的な説明を咀嚼する）
- 方向性を示して誘導する力（「じゃあこうすれば」と導く）
- 最終的な判断をする力（ビジネス要件を考慮）
この中で、一番重要なのが1番目の「気づく力」と3番目の「誘導する力」なんですよね。
プログラミング言語の文法とか、アルゴリズムの実装方法とか、そういうのじゃない。「あれ？これ使いづらくない？」って気づいて、AIとの対話を通じて解決に導く力。
AIに「どうすればいい？」って丸投げするんじゃなくて、「なぜ？」を聞いて、理解して、「じゃあこういう方向でどう？」って示す。この対話プロセスが、AI時代の「設計力」なんですよ。
実際、Gartnerの調査でも要件定義でのAI利用率が前年の14.4%から39.8%に急増してて、これ「要件定義が重要になってる」ってことの裏返しなんですよね。つまり、「何を作るか」「何が問題か」を決めて、AIを正しい方向に導く。これが人間の仕事になってる。
プログラミング言語は学ばなくていい
極端な言い方しますけど、プログラミング言語は学ばなくていいです。
コードの書き方はAIに任せる。人間がやるのは「何をどうしたいか」を構造的に理解して、AIに指示すること。
もちろん、ある程度の基礎知識はあった方がいいですよ。でも、87.5%の人が挫折するような「プログラミング言語の完全習得」を目指す必要はない。
それよりも：
- ビジネス要件を理解する
- ユーザーの課題を発見する
- システムの全体像を設計する
- 改善のサイクルを回す
こっちの能力を磨くべきなんですよね。
まとめ
要点整理
さて、長々と書いてきましたけど、まとめましょう。
1. AIはコードを書いてくれる。でも「何を作るか」は決めてくれない
これが全ての前提。AIは優秀なアシスタントだけど、あなたの代わりに考えてはくれない。
2. コードを理解する必要はない。動くか確認できればいい
車の運転と同じ。エンジンの仕組み知らなくても運転できる。
3. 学ぶべきは「AIとの対話力」
使いづらさに気づく → AIに「なぜ？」と聞く → 理解する → 「こうすれば」と誘導する。この対話プロセス。
4. AI時代は「作りながら改善」が最強
作り直しコストが下がったから、完璧目指さなくていい。とりあえず作って、使って、気づいて、直す。
5. プログラミング言語の深い理解は後回しでいい
必要になったら学べばいい。最初から完璧に理解しようとするから挫折する。
次のアクション
じゃあ明日から何するか、ですよね。
ステップ1: まず作ってみる
CursorでもChatGPTでも何でもいいから、何か作ってみてください。「ToDoリスト」とか「簡単な計算機」とか、何でもいい。
ステップ2: 使ってみる
作ったものを実際に使ってみる。「ここ使いづらいな」って気づく。
ステップ3: 気づいたら直す
AIに「ここをこう変えて」って指示する。即改善。
ステップ4: このサイクルを回す
これを繰り返す。これがAI時代の開発スタイル。
結論
最後に、僕が一番言いたいこと。
プログラミング言語を学ぶな、じゃなくて、プログラミング言語「だけ」を学ぶな、って話なんですよ。
コードの書き方覚えたって、何作るか分からなきゃ意味ないじゃないですか。料理で例えるなら、包丁の使い方だけ完璧に覚えても、何を作るか決まってなきゃ料理できないのと同じ。
AI時代は、「何を作るか」「どう改善するか」を考える力が価値になる。コードはAIが書く。人間は考える。
これが新しい開発スタイルなんですよね。
Room8アプリもまだまだ開発中ですけど、この「作って、使って、改善する」サイクルを回しながら作ってます。完璧じゃないけど、それでいいんですよ。完璧目指してたら、いつまでも完成しないから。
じゃあ、あなたも今日から「AI時代の開発者」になりましょう。プログラミング言語の勉強は後回し。まずは「何を作るか」を考えるところから始めてみてください。
それでは！