コードを書いてないのに、3日でLPと“カルチャーOS”が出来てしまった話 ~非エンジニアがAIと“違和感レビュー”しながら作った実体験~
最近、
「AIでアプリが作れる」
「AIでサイトが作れる」
みたいな話をかなり聞くようになりました。
正直、最初はかなり半信半疑でした。
私はエンジニアではありません。
Reactも分からないし、
DB設計もできない。
HTMLやCSSもほぼ分かりません。
でも、約3日で実際に、
イベントLP
社内向けカルチャーアプリ
を、AIと一緒に作って公開するところまで行きました。
しかも面白かったのは、
実際にやっていたことが、
“コーディング”
ではなく、
“違和感レビュー”
だったことです。
この記事では、
実際に何を作ったのか
どうAIへ指示したのか
どこでうまくいったのか
逆に何が難しかったのか
を、盛らずにそのまま書きます。
同じように、
「非エンジニアだけど、AI時代に何か作ってみたい」
と思っている人には、
かなりリアルな話になると思います。
※この記事は5〜7分くらいで読めます。
最初に作ったのは、イベントLPだった
最初に試したのは、イベントLPです。
しかも構成はかなりシンプルでした。
役割仕様・サービスデザイン・コーディング:ChatGPT
サイト公開:GitHub
申込管理:Googleフォーム
費用:0円
制作会社なし。
デザイナーなし。
エンジニアなし。
でも実際に、
公開して
申込フォームを動かして
イベント運営に使う
ところまで行けました。
正直、自分でも驚きました。
「あ、もうここまで個人で出来る時代なんだ」と。

実際に出来たサイト
実際のページはこちらです。
https://kyushu-startup.github.io/kyushu-accelerator-2026/
※ 完璧ではないですが、実際に公開して運営に使っています。
個人的に驚いたのは、
普通にLPっぽい
スマホでも崩れない
CTAもそれっぽい
世界観が統一されてる
ことでした。
昔だったら、
HTML
CSS
レスポンシブ
OGP
フォーム導線
を全部勉強しないと厳しかったと思います。
でも今回は、
「こういう感じにしたい」
を伝え続けたら、実際に公開できるレベルまで行けました。
しかも一番驚いたのは、
初版自体はかなり早く出来たことでした。
もちろん細かい修正や、
スマホ調整、
画像差し替えなどはありました。
ただ、
「公開できる状態」
までは、実質1日くらいでした。
最初にChatGPTへ渡したのは、“コード”ではなく“世界観”
いきなりHTMLを書いたわけではありません。
というか、書けません。
最初にChatGPTへ渡したのは、かなり雑なイメージでした。
実際はこんな感じです。
九州のスタートアップイベントLPを作りたい。
黒ベース。
ゴールド系。
宇宙っぽい未来感。
高級感。
スタートアップ感。
Appleっぽい余白感。
スマホ対応。
CTAを強く。これくらいです。
でも、これでかなり形になりました。
ここで面白かったのは、
“デザインを説明する”
というより、
“世界観を説明する”
方が、AIには伝わりやすかったことです。
あと、途中でかなり重要だと感じたのが、
「まずAIに、自分たちが何者なのかを説明すること」
でした。
例えば今回は、
九州スタートアップ界隈向け
高級感は欲しい
でも怪しくしたくない
テック感は欲しい
ただ、意識高い系には寄せたくない
みたいな、
“立ち位置”
を最初にかなり説明しました。
これはLPでも、カルチャーOSでもかなり重要でした。
逆に、ここを曖昧にすると、
AIはすぐ“よくある量産UI”へ寄っていきます。
だから実際には、
「何を作るか」
より、
「誰として作るか」
を最初に定義する時間の方が重要だった気がしています。
AIに「全部作って」は結構失敗する
これはかなり重要でした。
最初から、
「イベントLP全部作って」
だと、結構崩れます。
なので私は、
まずファーストビュー
次にイベント概要
次に登壇者
次にスマホ対応
みたいに、小さく分けました。
AIは、
「小さく作って修正」
の方が強いです。
最初はかなり“AIっぽいLP”だった
実際、最初はかなり“AI感”が強かったです。
光りすぎ
情報量多すぎ
演出過多
で、正直ちょっと怪しいLPみたいになっていました。
なので途中から、
余白を増やす
情報を減らす
CTAを目立たせる
読みやすさ優先
をかなり意識しました。
実際に出していた修正指示は、こんな感じです。
光りすぎて読みにくい
スマホで文字が大きすぎる
余白もっと欲しい
申し込みボタンを目立たせたい
高級感は残したい
情報量を減らしたいこの辺から、かなり“LPっぽさ”が出てきました。
実際にやっていたのは、“コーディング”ではなく“ディレクション”だった
ここで、かなり感覚が変わりました。
私はコードを書いていません。
その代わり、ずっとやっていたのは、
“違和感レビュー”
でした。
例えば、
「なんかSNS広告っぽい」
「演出が強すぎる」
「情報量が重い」
「CTAが弱い」
「スマホで読みにくい」
みたいなことを、ずっとレビューしていました。
つまり実際には、
“コーディング”
というより、
“ディレクション”
に近かった。
これはかなり時代が変わった感覚がありました。

GitHubが想像以上に良かった
最初は、
「GitHub=エンジニアのもの」
というイメージでした。
でも実際に使ってみると、
無料
サーバー契約不要
HTMLを置くだけで公開できる
静的サイトなので軽い
という特徴がありました。
しかも今回のサイトは、
ログインなし
DBなし
管理画面なし
です。
つまり、
“表示専用サイト”
なんです。
これは、小規模イベントLPとしてかなり相性が良かったです。

個人情報はGoogleフォーム側へ分離した
ここはかなり意識しました。
イベントサイトは、名前やメールアドレスを扱います。
もし自分でフォームを実装すると、
DB
メール送信
セキュリティ
スパム対策
まで必要になります。
これは普通に怖い。
なので今回は、
LP → 表示だけ
Googleフォーム → 個人情報管理
に分離しました。
実際、LP側はこれくらいシンプルです。
<a href="GoogleフォームURL" class="cta-button">
申し込む
</a>つまり、
「個人情報をLP側に持たせない」
構成にしました。
結果として、
「無料だけど雑な構成」
ではなく、
「責務分離したシンプル構成」
になったのはかなり良かったと思っています。
そんな中で、次に試したのが「カルチャーOS」だった
LPを作った後、
「もっと複雑なものって作れるんだろうか?」
と思いました。
そこで触り始めたのがbase44です。
base44は、自然言語でフルスタックWebアプリを生成できるAIアプリビルダーです。
UIだけではなく、
DB
管理画面
認証
CRUD
デプロイ
までかなり自動で生成されます。
最初は、
「簡単な投稿アプリくらいかな」
と思っていました。
でも、気づいたらかなり違う方向へ進んでいました。

作りたかったのは、“称賛SNS”ではなかった
実際、かなり参考にしたのはUnipos(ユニポス)でした。
良い行動が可視化される
部署横断で称賛が流通する
「ありがとう」が残る
という体験は、かなり良いと思っていました。
ただ今回やりたかったのは、少し方向が違いました。
例えば、
“盛り上がり”を強くしすぎない
ランキング感を出しすぎない
「人」ではなく“行動”を主役にする
SNS依存設計にしない
「静かな文化循環」に寄せる
などです。
なので今回は、
「称賛SNS」
というより、
“カルチャーアーカイブ”
みたいな方向へかなり寄せていきました。

最初に書いたのは、“機能”ではなく“思想”だった
ここがかなり重要でした。
多分、AIでアプリを作ろうとすると、最初にやりがちなのは、
投稿機能
コメント
タグ
管理画面
みたいな“機能説明”だと思います。
でも今回、最初にかなり長く書いたのはむしろ逆でした。
実際、最初にAIへ渡した内容はこんな感じです。
評価制度にはしたくありません。
ポイント競争は禁止。
MVP制度にしたくない。
盛り上がるSNSではなく、
静かに文化が流通する場所にしたい。
人ではなく、
良い行動を主役にしたい。
Slackで流れてしまう良い行動を残したい。
見るだけでも学べる状態にしたい。つまり、
「どんな機能を作るか」
より、
「どんな空気感にしたいか」
をかなり細かく言語化しました。
するとbase44は、
タイムライン
タグ機能
コメント
リアクション
管理画面
ピックアップ
マイページ
まで一気に生成してきました。
この時点でかなり驚きました。
AIは、放っておくと“普通のSNS”を作ろうとする
ここが今回かなり面白かった部分でした。
最初に生成されたUIは、かなり“社内SNS”っぽかったんです。
つまりAIは、放っておくと、
「エンゲージメントが高そうなUI」
を作ろうとする。
でも今回やりたかったのは、そういうものではありませんでした。
なので、ここから延々レビューが始まります。
実際、かなり何度も出した指示はこんな感じでした。
SNSっぽくしない
ランキング感を弱めたい
数字を主役にしない
投稿者より“行動”を主役に
静かな空気感にしたい
投稿が少ない日でも成立する空気感に
見るだけでも学べる状態にしたい例えば、
Before:
人気の投稿↓
After:
共感が集まった投稿これだけでも、空気感がかなり変わりました。
逆に言うと、
AIは放っておくと、かなり“普通のSNS”を作ろうとします。
だから重要だったのは、
「何を作りたいか」
より、
「何にしたくないか」
をかなり具体的に言葉にすることでした。
気づけば、“文化OS”みたいになっていた
途中から、かなり面白いことになります。
例えば管理画面では、
const TABS = [
{ key: "map", label: "分布図", icon: "🗺" },
{ key: "posts", label: "投稿管理", icon: "📄" },
{ key: "pickup", label: "ピックアップ", icon: "⭐" },
{ key: "tags", label: "タグ管理", icon: "🏷" },
];みたいなコードが生成され、さらに、
CultureMap
AI Culture Analysis
PDFレポート
CSV出力
通知設定
まで実装されていました。
この辺から、
“文化OS”
みたいになってきた。
これはかなり驚きました。
しかもこれは、
数ヶ月開発したというより、
最初の原型自体は、
かなり短期間で立ち上がりました。
細かいレビューや調整は続けていましたが、
「動くものがある状態」
までは、2日くらいでした。
ここで気づいた。LP制作もカルチャーOS制作も、やっていたことはかなり似ていた
LP制作と、カルチャーOS制作。
一見かなり違うことをやっているように見えます。
でも実際にやっていたことは、かなり似ていました。
どちらも、
「AIに全部任せる」
ではなく、
「違和感をレビューする」
だったんです。
例えば、
光りすぎ
SNSっぽい
情報量が重い
投稿者が目立ちすぎる
CTAが弱い
空気感が違う
みたいなことを、ずっとレビューしていました。
つまり、
“コードを書く”
より、
“違和感を言語化する”
時間の方が圧倒的に長かった。
一番驚いたのは、「人間側の役割」が変わってきていることだった
正直、
「コードを書ける人が強い時代」
から、
「AIへ適切に依頼できる人が強い時代」
にかなり変わってきていると思いました。
もちろん、本職エンジニアやデザイナーの価値は全然あります。
ただ、小規模LPや社内ツールレベルなら、
ChatGPT
GitHub Pages
Googleフォーム
base44
だけでも、かなり具体化できる時代になってきています。
ただ、「AIで作れる」と「安全に運用できる」は別
ここはかなり重要でした。
特に社内ツール系では、
権限
公開範囲
投稿データ
個人情報
匿名性
はちゃんと考えた方がいいです。
実際、最低限でも、
誰が見れるのか
投稿は匿名か
データはどこに保存されるのか
公開URLが漏れないか
権限設定は適切か
は確認した方がいいと思いました。
AIはかなり強いです。
でも、
“AIが全部安全にしてくれる”
わけではありません。
ここは普通に重要だと思いました。
最後に
今回かなり感じたのは、
“アプリを作れる”
こと自体は、もうそこまで特別ではなくなっていく、ということでした。
実際、LPも、社内向けアプリも、以前なら
制作会社
エンジニア
デザイナー
開発期間
が必要だったと思います。
でも今は、
「こういう空気感にしたい」
を言語化できれば、AIと一緒にかなり具体化できる。
ただ逆に、AIは放っておくと、
盛り上がるSNS
派手なUI
情報過多
エンゲージメント重視
みたいな、“よくある最適解”へ寄っていく感覚もありました。
だから重要だったのは、
「何を作りたいか」
より、
「何にしたくないか」
を説明することでした。
多分これからは、
“コードを書く前に、違和感を説明できる人”
の価値が上がっていくんだと思います。
