0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

コーディングができない自分でも、Notion連携日記アプリをAIで公開までやり切れた話

Posted at

この記事で伝えたい結論:課題を感じた本人が、そのまま解決者になれる時代になった。技術自慢ではなく、**非エンジニア寄りでも完遂できた「進め方の型」**を共有する。

0. 前提

  • 初期的な完成までに使った時間:約20時間(平日夜1h×2週間+休日4h×2週)
    ※細かい設計の見直し・試行錯誤を含めると、実際はもう少しかかっています
  • スキル:Pythonの基本的な制御(if/for等)と関数が読める程度。自分で何か作れるレベルではない。ほかの言語もほぼ未経験
  • 到達点:LP公開+Notionと接続して実際に保存できるWebアプリの公開

1. はじめに(結論)

自分はエンジニアではなく、コーディングも得意ではありません。Pythonは「なんとなく読める」程度で、何かを自力で作れるレベルではありません。

それでも今回、Notion連携のWebアプリ(Quicknote)を、LP公開+Notion連携(保存できる)ところまで持っていけました。

この記事で書くのは、技術スタック云々といった話ではなく、「分からない状態」でも完遂できた進め方です。
そのため、読者層もQiitaのハイスペックエンジニアの皆様ではなく、バイブコーディングなどに興味がある私と同じレベル感の方々を想定しています。

2. 出発点:Notion日記が続かなかった(課題感)

自分は「日々の振り返りをきちんとしたい」と思っていた中で、ジャーナリングが大事だという話をよく目にしました。そこで「データが蓄積され、かつ後々引き出せるNotionで日記をちゃんと付けていこう」と思い立ちました。

でも、実際に始めてみると早々に挫折しました。原因はシンプルで、書くこと自体より、書き始めるまでの手順が面倒だったからです。

特にスマホでは、

  • Notionアプリを起動する
  • 入力すべきページ/DBの画面まで移動する
  • (体感)重めのエディタを開いて入力する

…という一連のプロセスが地味にストレスで、「よし書こう」と思った勢いがそのまま削られていきました。つまり、文字入力に至るまでの“障壁”が積み重なって、続かない最大要因になっていたんだと思います。

3. 方針:課題を感じた本人が解決者になれる時代になった

自分は以前から、いわゆる「バイブコーディング」的にAIを使って何か作れないかを試していました。その延長で、この課題感(Notion日記の“書くまでの摩擦”)も自力で解消できるかもしれない、と思うようになりました。

もしAIがなかったら、まずは言語やフレームワークの基礎を一から積み上げて、さらにNotion連携のような外部サービスとの接続まで辿り着く必要があります。それは学習コストも試行錯誤も膨大で、今回のようなスピード感では到底やれなかったと思います。

一方で、AI頼りであることは弱みにもなります。AIがそれっぽいことを言っても、こちらに指摘できるだけの能力がないと間違いに気づけずに迷子になるからです。思ったとおりにはならないが、何がいけないのか分からない。これは基礎がなっていないから当たり前ではありますが、多々苦しめられたポイントですね。

そこで自分が意識したのは「AIに丸投げしない」ことでした。具体的には、

  • 先に目的を言語化して、ロジック(やりたいことの手順)を固める
  • その上でAIに実装を依頼する

という順番にすると、実装がスムーズに進む印象でした。

要するに、AIは魔法ではなく、課題を感じた本人が“前に進むための補助輪”として使うと強い——今回の開発ではそれを強く実感しました。

4. できたもの:Quicknote を1分で説明

  • 何をする:Notionを開かずに入力→Notion DBへ保存
  • どんな人向け:Notion日記が続かない(特にスマホ)
  • 体験の要点:"Notionの面倒くささ" を消す
ちなみにフロントはSvelte、バックはPythonで作成し、Conoha VPS上にデプロイしています。

5. 20時間で完遂するために効いた「進め方の型」

今回主に使っていたのは、OpenAI の Codex 5.1 です(バイブコーディング的に相談しながら進めました)。
補助的にChatGPTも壁打ちに使っていました。特に要件定義っぽい部分はChatGPTのほうが的を射たことをいう気がしました。

型1:MVPを「1画面・1機能」に固定する

最初にAIとも相談しつつ、MVPをかなり小さく定義しました。

  • MVP:ブラウザで入力した文字が、自分のNotionデータベースに保存される
  • やらないこと:保存した内容の閲覧機能(Notion側で確認すれば十分なので、アプリ側には持たせない)

一方で、当初は「自分のNotionに日記が入ればOK」でしたが、公開して他の人にも使ってもらうには、ユーザーごとに認証や連携が必要になります。

  • ログイン(Googleアカウントを使ったSSO)
  • ユーザーそれぞれのNotionデータベースと連携するためのOAuth認証

…のように、MVPを守りつつも「公開に必要な最小限」は後から足す、という順番にしました。

型2:最短で“保存”まで通す

UI→保存までを最短で通すために、最初は「入力→送信→Notionに1件保存」だけが成立する流れを作りました。

  • まず、入力項目をAIと相談して最小化(本文/気分/タグ/日付
  • その項目を入れるためのUIをポン出ししてもらい、まずは形にする
  • ボタン配置など細部は気になってしまうので、共通化・統一感が出るようにこちらから修正指示(ただし大枠のデザインは初期案のまま今も使っています)
  • 送信ボタン→APIに投げる→Notion DBに保存、のルートを先に通す

この段階は想像以上にスムーズで、細かい修正込みでも最初の5時間かからないくらいで「とりあえず保存できる」状態まで持っていけた感覚があります。

型3:AIに渡す前提を固定する(目的・制約・出力形式)

AIに任せるとしても、前提がブレると一気に迷子になります。特に外部サービス連携は、こちらが能動的に情報を集めないといけない場面が多かったです。

  • Notion API は直近で破壊的変更があり、古い情報で実装されるとハマる
  • なので「新しいAPIドキュメントを明示的に指定して、それに沿って実装してもらう」ことを意識した

ここはAIが勝手に最新情報を“発見してくれる”わけではないので、ユーザー側が資料を提示して前提を揃える必要がある——というのを強く実感しました。

型4:エラーはそのまま貼る(解釈しない)

後半(認証や外部サービス連携)では、想像以上に手こずりました。

  • Firebase連携
  • Notionの認証(OAuth)

このあたりは、こちらがドキュメントを提示しながら、AIに直してもらう→エラーを潰す、を何回も何回も繰り返す感じでした。

このとき効いたのが「自分の解釈を挟まず、エラーやログをそのまま渡す」ことです。AIに説明するために要約すると、ズレた方向に進むことがあるので、まずは一次情報(エラー文・スタックトレース・リクエスト/レスポンス)を渡す方がうまくいきました。

型5:綺麗さを捨てる基準を持つ(公開を優先)

本当は、練習も兼ねてやりたいことがたくさんありました。たとえば、課金システムやユーザーへの通知などです。

ただ、そのあたりは自分の知識がまだ薄いことに加えて、Webアプリでしっかり実装しようとすると設計・実装・運用まで一気に難易度が上がります。ここで欲張ると、完成より先に燃え尽きる予感がありました。

そこで自分は、次の判断基準で捨てることにしました。

  • 公開(LP+Notionに保存できる)を最優先し、それ以外は後回し
  • 課金・通知のように「実装だけでなく運用まで含めて難しくなるもの」は、最初からスコープ外に置く
  • 迷ったら「自分の課題(書くまでの摩擦)を減らすのに直結するか?」で採用可否を決める

結果的に、完璧なプロダクトを目指すよりも、まずは“動くもの”を公開する方が前に進めました。

6. 公開してよかったこと(&公開して初めて分かった現実)

「作る」だけならローカルでもできますが、公開すると一気に景色が変わりました。今回いちばん大きかった学びは、技術そのものというより「公開して初めて起きること」でした。

6-1. 公開してよかったこと(具体例)

  • 自分のブラウザから、公開されたプロダクトとして触れる達成感

    • 「作ったつもり」ではなく、URLがあって、いつでも開けて、動く。ここが自分にとって大きかったです。
  • (見つけてもらえれば)自分以外の人も使える状態になったこと

    • まだ流入はほぼありませんが、それでも「自分のためのツール」から「他人にも使ってもらえる可能性があるツール」になった瞬間は達成感がありました。
  • “人に使ってもらうために必要な技術”への理解が進んだ

    • 認証(ログイン)やOAuthなど、公開前はぼんやりしていた要素が、「人に使ってもらうなら避けて通れないもの」として腹落ちしました。
    • なお、実装の多くはAI(Codex)に書いてもらっています。自分は主に、目的を言語化して、前提を揃えて、エラーやログをもとに直していく——という“進行役”に近い立ち回りでした。

6-2. 公開して初めて分かった現実

  • 露出がめちゃくちゃ難しい

    • 正直このQiita記事自体も、露出の一手段として書いています。
    • 「作る」までは辿り着けても、「見つけてもらう」で止まる人がほとんどなんじゃないか、という実感があります。
  • プロダクトアウトの自己満足で終わる危険がある

    • マーケットイン/プロダクトアウトみたいな話にも繋がりますが、見てもらえないと、結局は自己満足の範囲で改善し続けるだけになってしまう。
    • 自分も「どうやったら人に届くのか」はまだ分かっていません。現状は、試行回数を増やす(数撃ちゃ当たる)しかできていないのが正直なところです。

6-3. これからやりたいこと

  • プロダクトの磨き込みもやるが、まずは露出・導線を学んで回したい
  • 「作る」だけで終わらず、ちゃんと人に届く状態を作れるようになりたい

7. リンク(=宣伝)

上記で取り組んだプロダクトはこちらです。
使い心地や、そもそも課題感ズレていない?といったご意見等あれば、お寄せいただけますと嬉しいです😢
Quicknote LP:https://quicknote.stock-stu.com

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?