プログラミング未経験者が、4か月で作った——ログインも決済もAIチャットも動く会員制サイトができるまで

プロフィール

• 氏名：池原 允大（いけはら まさひろ）
• 屋号：会計×バイブコーディングエンジニア（バイブコーディング＝自分でコードを書かず、AIに指示を出して作る進め方）
• 職種：金融機関に勤務
• 保有資格：日商簿記1級、全経簿記上級、証券アナリスト（CMA）1次合格
• 現在の活動：金融機関に勤めながら、証券アナリスト・簿記・会計×AI のオンライン講座を個人で制作・運営
• AI活用歴：約4か月（2026年4月〜）
• 使っているツール：Claude Code、Codex（どちらも、日本語で指示するとソフトを作ってくれるAI）、ChatGPT、Gemini

AIに触れる前は、何をしていましたか？

AIを本格的に使い始める前は、ChatGPTで人生相談をしていました。仕事のこと、これからのこと。作るための道具として使うという発想はありませんでした。

一方で、作りたいものはずっとありました。個人でやる資格予備校のサイトです。簿記1級と証券アナリストの1次に合格していて、そこで学んだことを教材にしたいと思っていました。

作れなかった理由は、情報でした。

お金がなかったわけではありません。時間も、削ろうと思えば削れました。ただ「何をどう調べれば、あれが作れるのか」が分かりませんでした。プログラミングを学ぶべきなのか、業者に頼むべきなのか、その判断すら付きません。入口が見つからないまま、頭の中にアイデアだけがある状態でした。

AIに触れたきっかけは何ですか？

きっかけはYouTubeでした。誰かに勧められたわけではなく、自分で見つけました。

日本語で「こういうものを作って」と頼むと、AIがその通りに動くものを組み立ててくれます。そういう話を見て、試してみました。最初に触ったのがClaude Codeです。

最初に試したのは、いきなり作りたかったサイトそのものでした。練習用の何かではなく、ずっと頭にあった資格講座のサイトを作らせてみました。

「これはいけるかもしれない」と思ったのは、初めてサイトが形になったときです。頭の中にしかなかったものが、画面に出ました。この瞬間に、止まっていた時間が一気に動いた感覚がありました。

最初に作ったものは何ですか？

作ったのは、証券アナリスト講座の受講生サイトです。ログインすると、購入した講座だけが開く会員制のサイトにしました。

自分が資格の勉強で苦労した部分を、教材として残したかったからです。2026年4月13日に着手し、7月には決済まで通る状態になりました。

使ったのは5つ。Claude Code（AIに指示を出して作る道具）、Vercel（作ったサイトを世の中に公開しておく場所）、Supabase（会員情報や購入履歴を預けておく場所）、Stripe（クレジットカード決済を代わりにやってくれる会社）、Claude API（サイトの中でAIに答えさせるための、AIへの接続口）です。

自分がやったことは、何を作るか決めること。画面の流れを考えること。教材の中身を作ること。動かして、おかしいところを見つけることです。

AIに任せたことは、コードを書く部分のほぼすべてです。自分でゼロから書いた行はほとんどありません。

いま入っているのは、9つの講座。講義を一時停止すると、その場面について質問できるAIチャットも動いています。

短期間で、何が変わりましたか？

以前なら必要だったものは、プログラミングの学習期間か、外注費です。どちらも、始める前に諦める理由になっていました。

AIによって省略されたものは、「まず勉強する」という段階です。作りながら覚える形に変わりました。

4か月で作ったものは、機能を並べるより、お客さんがたどる道で見たほうが早いと思います。紹介ページを開いてから、講義を見るまでが一本につながっています。

この1から4までの間に、自分の手は入っていません。

AIを使う前の自分には、この4つはどれも作れませんでした。カード決済を組み込むことも、買った人にだけ動画を届けることも、やり方の見当がつきませんでした。今回自分がやったのは「お客さんにどの順番で通ってもらうか」を決めることで、動く部分はAIが組んでいます。

教材づくりも同じです。スライドから読み上げ音声を作り、講義動画に組み立てるところまでが、ひと続きで流れます。AIが無ければ、1本ずつ手で作るしかない工程でした。

中身は、9つの講座に講義動画と記事をあわせて100本以上。手を動かす量は、4月は数えるほどだったのが、7月には日に10回以上サイトに手を入れる状態になっていました。作り方が分かるほど、手数が増えました。

作ったのは、講座のサイトだけではありません。ふだんの作業のうち、手で繰り返していたものも順に自動化しました。書きためたXの投稿を決まった時刻に出す仕組み、募集中の案件を集めて一覧にする仕組みなどです。公開されている決算資料から指標を集めて、自分の買い基準に合う銘柄の注文票（株数と指値）まで作る仕組みもあります。株を実際に買うところは、いまも手でやっています。どれも「毎回やるのが面倒だ」というところから始まっています。

周囲の反応も変わりました。会社で資料を作ったとき、「仕事が早すぎる」と言われました。自分の手が速くなったわけではありません。作り方が変わっただけです。

生活への影響でいうと、平日の夜と休日が、そのまま制作の時間になりました。以前は「いつか作りたい」と思っているだけの時間でした。いまは、作りたいと思ったものが形になります。止まっていた時間が動き出して、そこから一気に加速しました。

うまくいかなかったのは、どんなときですか？

うまくいかなかったことの原因は、AIよりも自分の側にありました。指示があいまいだと、違うものができます。

「いい感じにしておいて」くらいの粗い頼み方をすると、AIは足りないところを自分で埋めて、とにかく動くものを出してきます。画面は動きます。エラーも出ません。ただ、こちらが頭に描いていたものとは違います。

これが一番やっかいでした。壊れていれば気づける。動いてしまうから気づけない。後から見直して「ここ、意図した通りに動いていない」と分かった箇所が、いくつも出てきました。

直し方も、最初は分かりませんでした。どこがどう違うのかを言葉にできないと、AIにも直せません。「何がどうなっていてほしいのか」を自分の言葉で書けるようになってから、ようやく直せるようになりました。

動くことと、正しいことは違う。

そこを自分で疑えるようになるまでに、時間がかかりました。

AIを使っても、難しかったのはどこですか？

難しかったのは、コードではなかった

先にお伝えすると、コードを書く部分では苦労していません。そこはAIがやってくれます。

ログインの仕組みも、決済の処理も、どの情報をどこにしまっておくかも、頼めば動くものが出てきます。技術的に難しいと言われる部分ほど、実は自分の負担ではありませんでした。

大変だったのは、作り始める前に決めることと、コードの外側にあるものでした。

一番大変だったのは「何を作るか決めること」

何を、どういう順番で、どう作るのかを決めることです。開発では要件定義と呼ぶらしいのですが、ここが一番きつかったです。

AIは、指示した通りに作ります。逆に言えば、指示が決まらなければ何も進みません。「こういうサイトが欲しい」だけでは足りず、誰がどの画面から入って、何をして、どこで料金を払って、その後どうなるのか。それを自分で決める必要があります。

これが自分の仕事だと気づくのが、遅かったです。

サイトが動く仕組みが、まるごと分からなかった

そもそもサイトがどうやって世の中に公開されるのかを知りませんでした。

データはどこに置かれるのか。なぜログインできるのか。自分のパソコンの中のファイルが、どうして他の人から見えるようになるのか。全体像がまったくありませんでした。

だから、一つ一つAIに確認しながら覚えていきました。「これは何をしているのか」「なぜこれが必要なのか」を聞いて、答えをまた別の場面で確かめて。この繰り返しが、一番時間のかかった作業でした。

ツールの操作でつまずいた

Vercel（サイトを公開する場所）、Supabase（ログインとデータを預ける場所）、GitHub（コードを保管する場所）。

AIがコードを書いてくれても、これらの画面で自分が何をすればいいのかが分かりません。用語も知りませんでした。「デプロイ」「リポジトリ」「環境変数」。今なら「公開すること」「コードの保管場所」「鍵をコードとは別の場所に隠しておく仕組み」と一言で言えますが、当時は言葉の意味からひとつずつ調べました。

AIに何を頼めるのかが分からなかった

AIでできることの幅が分からなかった、というのもあります。

今思えばAIに任せられた作業を、「ここは自分でやるものだ」と勝手に線を引いて手作業でやっていた場面がかなりあります。頼めると知らなかっただけでした。

AIの能力ではなく、自分の側の想像力が制約になっていました。

セキュリティは自分で勉強するしかなかった

外部サービスの鍵（APIキー）の取り扱いには苦労しました。

決済やAIなど、外部のサービスを使うには「鍵」を渡されます。家の鍵と同じで、持っている人は誰でも入れてしまいます。だからコードの中に直接書いてはいけません。書いたまま公開すると、他人がその鍵で自分のアカウントを使ってしまいます。請求だけこちらに来る。

最初はこの意味自体が分かりませんでしたし、間違えると何が起きるのかも分かりませんでした。

ここは自分で調べて勉強しました。仕組みを理解しないまま真似だけしていたら、いつか事故を起こしていたと思います。

作れることと、正しく作れていることは違う

そこが、一番の壁でした。

作るのは苦労しません。正しく作れているかを、自分で判断できないのです。

画面の上では問題なく動いているのに、裏側では意図した通りに動いていなかった、ということが実際に起きました。しかも、気づくまでに数か月かかりました。AIは「できました」としか言いませんし、実際に画面は動いてしまいます。

エンジニアに相談したいと思った瞬間は、まさにここです。自分のコードが安全かどうか、自分では分からないと気づいたときでした。

いま必要だと感じているのは、要件を一緒に整理してくれる人と、公開前に安全性を見てくれる人です。作ること自体はAIとできるようになりました。残っているのは、判断の部分だと思っています。

ご自身には、どんな変化がありましたか？

自分に対する可能性が広がって、自信がつきました。

作りたいものを作れる、という状態は、思っていたより大きいです。頭の中にあるものを外に出せるようになると、次に何を作るかを考えるようになります。止まっている時間が減りました。

キャリアの見え方も変わりました。金融と会計の知識に、AIが合わさったら強いんじゃないかと思うようになりました。

会計が分かる人はいます。作れる人もいます。でも「会計の話が通じたうえで、動くものを作れる」人は、あまり多くありません。今までは資格を持っているだけだったものが、掛け算になった感覚があります。

次に作りたいものは何ですか？

• 簿記1級の学習を伴走するサービス。自分が一番苦労した領域なので、教材にしたいと思っています
• 受託の仕事。会計まわりの業務を自動化したい会社の手伝いができるのではないかと思っています

これから始める人には、何を伝えたいですか？

とにかく早く、Claude CodeやCodexを触ってほしいです。

自分は「情報がない」で止まっていました。でも実際に触ってみたら、止まっていた理由のほとんどが、触っていないだけでした。

勉強してから始めるべきかと聞かれたら、やりながら覚えてくださいと答えます。

自分は勉強してから始めていません。作りたいものを決めて、作りながら分からないことを潰していきました。順番が逆だと、たぶん今も何も作れていないと思います。

失敗したときは、原因が分かるまで戻ればいいです。自分の場合、動いていると思っていたものが実は動いていなかった、ということが起きました。落ち込みましたが、原因を突き止めて直したら、その部分は前より確実に理解できていました。壊れたところが、一番よく分かるようになります。

ただし、

動いた＝正しい、ではない。

これだけは、早めに知っておいたほうがいいです。自分はそこで痛い目を見ました。

Shift Forward's View

ここからは、取材した私たち Shift Forward の見方です。

業務を知っている人が、そのまま作り手になる

この取材でいちばん大事だと感じたのは、池原さんが作ったものが「会計を知っている人にしか作れないもの」だった点です。講義動画を一時停止すると、その場面について質問できる。受講生がどこでつまずくかを、自分が受験生として通ってきたから分かる。この設計は、仕様書に書き起こしにくい種類の知識から出ています。

これまで業務システムは、業務を知っている人が要望を出し、受け取ったエンジニアが作る、という分業で生まれてきました。受け渡しのたびに、細かいニュアンスは少しずつ落ちます。AIは、この受け渡しを一段飛ばします。業務を一番よく知っている人が、そのまま作り手になれるということです。

だから私たちは、ここからこれまで以上に業務にフィットした改善が出てくると考えています。現場の人が我慢している小さな不便は、投資対効果の計算に乗らないため、いつも後回しにされてきました。困っている本人が作れるなら、その順番待ちがなくなります。

挑戦はどんどん。ただし、危ないところは知っておく

AIを使ったチャレンジは、迷っているならやってみたほうがいいと思っています。池原さんが「止まっていた理由のほとんどが、触っていないだけだった」と話している通りです。触る前に、できる・できないの線を自分で引いてしまうのが、いちばんもったいない。

そのうえで、池原さんが正直に話してくれた部分——外部サービスの鍵の扱いと、画面は動いているのに裏側では意図した通りに動いていなかったという話——は、私たちが企業の現場で見ている失敗とそのまま重なります。壊れていれば気づける。動いてしまうから気づけない。ここが、AIで作るときの一番危ないところです。

個人で作っているうちは、影響が自分に返ってくるだけで済みます。会社の業務で同じことが起きると、行き先が顧客の情報や取引先になります。ですから「危ないからやめる」ではなく、どこが危ないかを知ったうえで走るのが正しい、というのが私たちの立場です。池原さんも独学でそこへたどり着きましたが、気づくまでに数か月かかったと話しています。会社でやるなら、その数か月は横に人がいれば短くできます。

私たちがやること

池原さんは、いま必要なものとして要件を一緒に整理してくれる人と公開前に安全性を見てくれる人を挙げました。これは、私たちがエンジニアとして担っている役割そのものです。作ること自体は、もう本人とAIでできます。残っているのは、決めることと、確かめることです。

そして私たちは、これを一人の助っ人で終わらせないことを目標にしています。鍵をどう管理するか、公開する前に何を確認するか、誰がレビューを通すか。この社内の型を一緒に作るところまでやって初めて、会社としてAIを使い、自分たちで作れる状態になります。やる気のある人の手を止めずに、その人が安全に速く走れるようにするのが、私たちの仕事だと思っています。

業務を深く知っていて、自分で動くものを作れて、危ないところが分かっている。私たちが Forward Deployed Engineer（FDE）と呼んでいるのは、まさにこういう人です。社内にこの役割を担う人が現れたら、そこがその会社のAI活用の起点になります。そういう方と一緒に仕事ができるのを、楽しみにしています。