Interview
会社員をしながら、AIで実案件を獲得する——田中崚雅さんが9か月で掴んだWeb開発の手応え
会社員として働きながら、2026年1月にAI活用開発を始めた田中崚雅さん。Claude Codeを使ってポートフォリオサイトから予約管理システム、複数人格のAIが会話するコミュニティボットまで、実案件レベルのアプリを複数構築してきました。クラウドソーシング経由で評価を得るまでの9か月を聞きます。
会社員として働きながら、個人でAI活用型のWeb開発を手がけている。ポートフォリオサイトの運営、クラウドソーシング経由の開発案件対応、noteやブログでの情報発信。屋号はまだ「個人事業として準備中」だが、すでに実案件レベルのアプリを複数形にしている。
プログラミングもWeb開発も未経験だった。新しいことに挑戦したいという思いはあったが、それが具体的な形になることはなかった。
2026年1月、AIに触れた。それから約9か月で、ポートフォリオサイトから予約管理システム、複数人格のAIが会話するコミュニティボットまで、実案件レベルのアプリを複数構築している。
プロフィール
- 氏名：田中 崚雅（たなか りょうが）
- 屋号：AI活用型Web開発（個人事業として準備中）
- 職種：会社員（本業）／個人でAI活用したWeb開発を展開中
- 現在の活動：ポートフォリオサイトの運営、クラウドソーシング経由でのAI活用開発案件対応、note・ブログでの情報発信
- AI活用歴：約9か月（2026年1月〜）
- 使っているツール：Claude Code、ChatGPT、Notion API、GitHub、Vercel、Supabase
AIに触れる前は、何をしていましたか？
会社員として働くこと自体に、不満があったわけではありません。ただ、自分だけの力で何かを形にしたことがない、という感覚がずっとありました。
新しいことに挑戦したい、とは思っていました。ただ、何から手をつければいいのか、その入口が見えませんでした。
AIに触れたきっかけは何ですか？
きっかけは、クラウドソーシングサイトでした。
何ができるか分からないまま、色々な案件のページを見て回っていた時期があります。その中で、何件か企業の方との面談の機会をいただきました。
ある面談で、「これからの先行者利益は、AIを使いこなせるかどうかで決まる」と教えていただきました。
それが2026年1月のことです。その日から、少しずつAIツールを触り始めました。
最初に作ったものは何ですか？
最初に作ったのは、自分自身のポートフォリオサイトでした。
Next.jsという言葉も、その時はまだよく分かっていませんでした。それでも、AIに聞きながら一行ずつ進めていけば、画面に自分のページが表示される。その瞬間は、今でも覚えています。
短期間で、何が変わりましたか？
数ヶ月の間に、作れるものの幅が大きく変わりました。
2026年1月にNext.jsという言葉も知らない状態から始めて、9月には予約管理システム、4種類の人格を持つAIが投稿・返信・いいねを自動化するコミュニティボット、部署ごとに役割分担されたAIエージェントが連携するダッシュボードなど、実案件を想定したプロダクトを5つ以上、実際に動く形で作れるようになっていました。
「作れるかどうか分からない」という不安は、いつの間にか消えていました。
ただし、この5つのうち、実際の収益につながったものはまだ0件です。作れることと、稼げることの間には、まだ距離があります。
うまくいかなかったのは、どんなときですか？
うまくいかなかったことの多くは、外部サービスとの連携でした。
特にNotionのデータベース連携では、同じ失敗を3回繰り返しました。ページのURLをそのままIDとして使っていたのですが、それは実はページのIDであって、データベースのIDではありませんでした。見た目には違いが分からず、原因不明のエラーで何時間も止まることもありました。
気づいたきっかけは、エラーメッセージを読み流さず、「これはページIDなのか、データベースIDなのか」とAIに直接確認したことでした。
動かないとき、大抵は自分の理解が足りていない。
それに気づくまでに、時間がかかりました。
AIを使っても、難しかったのはどこですか？
技術的な部分は、多くをAIが助けてくれます。ただ、それでもつまずいた場面はありました。Vercelのサーバーレス環境はファイルシステムが読み取り専用で、AIの提案通りに実装したコードがそのまま動かず、原因を自分で調べてようやく気づいたこともあります。
本当に難しかったのは、その先です。
どの案件に応募すべきか。どのプラットフォームで勝負すべきか。何に時間を使うべきか。
18件応募して、不採用が続いたこともあります。1件は応募者が151人という案件で、正直「自分のスキルの問題ではない」と分かってはいても、落ち込みました。
判断を鍛える部分は、AIではなく自分自身の仕事でした。
今も解決しきれていないこともあります。一人で開発しているため、コードレビューをしてくれる相手がいません。動いているように見えても、それが本当に正しい実装なのか、判断できる基準は自分の中にしかありません。
ご自身には、どんな変化がありましたか？
「エンジニアではないから」という思い込みが、少しずつ崩れていきました。
不採用が続いた時期、正直「自分には向いていないのかもしれない」と思うこともありました。それでも改善を重ね、ようやく評価という形の反応をいただけたとき、「積み上げれば、ちゃんと届く」という実感に変わりました。
肩書きよりも、実際に手を動かして形にできるかどうかで見てもらえる。そのことが、これからのキャリアの考え方そのものを変えました。
次に作りたいものは何ですか？
継続して収益が発生する仕組みを作りたいと思っています。
具体的には、1年以内に実績を10件積み上げること。クラウドソーシングでの案件対応だけでなく、地域の企業に直接AI活用を提案していくような、まだ競合の少ない領域にも挑戦していきたいです。
これから始める人には、何を伝えたいですか？
とにかく早く、手を動かしてほしいです。
自分は「エンジニアではないから」で長い間止まっていました。実際に止めていたのは、知識ではなく、最初の一歩でした。
勉強してから始めるべきか、と聞かれたら、やりながら学ぶ方が早いと答えます。作りたいものを先に決めて、分からないことをその都度AIに聞きながら埋めていく。順番が逆だと、たぶん今も何も作れていなかったと思います。
最初のポートフォリオサイトも、Next.jsが何かも分からないまま、エラーを一つずつ潰しながら作りました。分かってから始めていたら、たぶん今も手をつけられていません。
完璧な準備は、いつまでも終わらない。動きながら埋めていくしかない。
会社員をしながらでも、最初の一行から始めることはできます。
Shift Forward's View
ここからは、取材した私たち Shift Forward の見方です。
まず一歩踏み出して、動きながら直している
この取材でいちばん大事だと感じたのは、田中さんが「勉強してから」ではなく「作りながら」始めた点です。Next.jsが何かも分からないままポートフォリオサイトに手をつけ、エラーを一つずつ潰し、NotionのIDの違いで3回止まり、それでも自分で原因にたどり着いた。まず動かして、つまずいたところから直していくという進め方を、独学で身につけています。
これは私たちの考え方とも重なります。AIが手元にある今、何をどう作るかを机上で決め切るより、動くものを先に出して、その反応から次を決めたほうが早い場面は確実に増えています。この進め方は、これからの開発の手法の一つとして、私たちも必要だと考えているものです。
実務を想定して、とにかく量を作っている
もう一つは、作った量です。9か月で予約管理システム、複数人格のコミュニティボット、AIエージェントのダッシュボードと、実案件を想定したものを5つ以上、動く形にしている。練習問題ではなく、誰かが使う前提のものを繰り返し作っているところに意味があります。
外部サービスとの連携、Vercelの読み取り専用のファイルシステム、動いているように見えて正しいか分からない不安。田中さんがつまずいたところは、どれも実際の案件で必ず出てくるものです。量を作ったからこそ、その一つひとつに先に当たっています。
作ること以外にも、目が向いている
そして、開発以外のところに目が向いているのが印象的でした。どの案件に応募するか、どのプラットフォームで勝負するか、競合の少ない地域の企業にどう届けるか。18件応募して不採用が続いた経験を、スキルの話ではなく仕事をとるための判断の話として捉えています。
作れることと稼げることの間にはまだ距離がある、と本人が言い切っている通り、この距離を埋めるのは技術ではありません。ここに早い段階で気づいているのは、大きな強みです。
次に身につけるのは、決めてから作る進め方
一方で、ここから先に必要になるものもはっきりしています。動きながら決める進め方は、一人で作っているうちは最も速い方法です。ただ、案件として受けるものには、要件を決めて、設計をしてから作るという進め方も求められます。発注する側が何がいつできるかを先に知りたい、という理由もありますが、それだけではありません。データが増えたときに耐えられるか、外部サービスが止まったときにどうなるか、誰にどこまで触らせてよいか。作り始めてから気づくと手戻りが大きい懸念は、動かす前に考えておく必要があります。
大事なのは、どちらか一方に寄せることではありません。どこまでを進めながら決めてよくて、どこは最初に確定しておくべきか。データの持ち方、外部サービスとの境界、誰が何をできるかの権限。ここは後から変えると全体に響くため、先に決めておく必要があります。逆に、画面の細かい動きは、動かしてから直したほうが早い。この線引きができるようになると、作り方の幅が一段広がります。
もう一つは、拡張性と保守性です。一人で作って一人で使うものなら、動けばよい。ただ、納品したものは、半年後に機能が増え、別の人が触ります。あとから足せるか、あとから読めるかを考えて作れるようになると、動くものが、任せられるものに変わります。田中さんが「コードレビューをしてくれる相手がいない」と話していた課題は、まさにここにつながっています。
私たちがやること
田中さんに足りないのは、動く力でも、続ける力でもありません。決めてから作る型と、それを見てくれる相手です。何を最初に固めるか、どこを後回しにしてよいか、この設計で先々困らないか。私たちがやっているのは、動き始めた人の横に立って、この判断を一緒にやることです。
まず動いてみて、量を作って、仕事をとるところまで考えている。ここまで自分で来た人は、そう多くありません。私たちが Forward Deployed Engineer（FDE）と呼んでいる役割は、こういう人が設計の型を身につけたところに生まれます。その手を止めずに、次の段階へ進めるようにするのが、私たちの仕事です。
