ProjectTag 開発日記

New!AdSense合格への道 第1話

ProjectTagのサイトでAdSenseの審査を申請して、これまでに2回落ちました。理由はどちらも「価値の低いコンテンツ」。今回はその経緯と、今わかっている原因をまとめておきます。まだ合格したわけではないので、これは結果報告ではなく途中経過です。

何を申請していたか

申請していたのは、ProjectTagのトップページです。PlantTagとCollectionTagという2つのアプリへのリンクと、簡単な紹介を置いているだけのページでした。今振り返ると、これは「アプリの入り口」ではあっても「読み物」ではなかったと思います。中身のあるコラムはそれぞれのアプリ側のサブドメインに置いていて、トップページ自体には独自のコンテンツがほとんどありませんでした。

書いていて気づいた失敗

1回目に落ちてから、まず開発日記のページをトップページ側に作りました。noteに書き散らしていた開発の記録を1箇所にまとめる形にして、多少コンテンツは増えました。ただ、書いている途中で自分でもまずいと思う一文がありました。「AdSenseの審査に向けたコンテンツの充実という目的もあります」と、そのまま動機を書いてしまっていたところです。これは提出前に見直して直しました。読者のための記事なのか、審査を通すための記事なのかは、書いている当人が一番先に自覚できる部分だと思います。

ads.txtの「不明」騒動

もう一つ、ads.txtのステータスが管理画面上で「不明」になっていて焦った時期もありました。実際にファイルの中身を確認したところ記述自体は正しく、単にクロールの反映待ちでした。ここは慌てて何かをいじる前に、まず中身を直接見て確認するべきだったと思います。

今の状況

現状は、トップページの開発日記を厚くする作業と、CollectionTag側のコラムを増やす作業を並行して進めています。CollectionTag側は開発予告的な記事が1本あるだけで、正直ここが一番薄いです。

3回目の申請はまだしていません。落ちた理由が「価値の低いコンテンツ」だけで、他の技術的な指摘がなかったのは、逆に言えばやることがコンテンツの中身の勝負だけということでもあります。結果が出たら、また書きます。

第5話：【感動の瞬間】iPhoneのブラウザで動いた日。そして溢れ出す「次は何を作ろう？」という無限のアイデア

「プロデューサー型開発」のスタイルを確立し、AIとの上手な付き合い方を覚えてから、開発スピードは劇的に上がりました。
UIの崩壊を乗り越え、ビルドエラーを解消し、ついにその日がやってきました。

開発用のパソコンの画面を飛び出し、自分のiPhoneのブラウザ（SafariやChrome）で、Webアプリとして実際に動かす日です。

自分のスマホの画面で「自作のWebアプリ」が動く感動

テスト環境で問題ないことを確認し、コマンドプロンプトからデプロイを実行。
無事に公開が完了したURLを、iPhoneのブラウザに入力してカチッと開いた、あの瞬間……。

「うわっ……スマホの画面でも本当に綺麗に動いてる！！」

パソコンの大きな画面で見ていた時とは全く違う、手のひらに収まるその感動。
庭で育てているたくさんの花々や、最近始めたばかりの家庭菜園の野菜たち。合わせて30株以上にもなる愛しい植物たちの名前を、iPhoneの画面をタップして、自分のWebアプリへ実際に入力していく時の達成感は格別でした。

既存の既存のサービスではどうしても手が届かなかった「私だけのこだわり」が、ブラウザの中で完璧に機能している。プログラミング未経験の私が、自分の欲しかったものを、自分の力（とAIのサポート）でゼロから形にしたのです。

溢れ出す「作りたい！」というクリエイターの欲望

この「iPhoneのブラウザでサクサク動いた」という成功体験は、私の中で何か大きなスイッチを押してしまいました。

「AIをプログラマーとして雇い、自分がプロデューサーとして仕様を決める。そしてWebアプリとしてサクッと公開する」
この必勝パターンを使えば、植物管理だけでなく、世の中のあらゆる不便を自分の手で解決できるのではないか？という、とてつもない万能感に包まれたのです。

「あれ、このデータ管理の仕組みを応用すれば、毎日の『お薬トラッカー』のWeb版だってすぐに作れるんじゃないか？」
「いや、自分好みにカスタマイズした『家計簿アプリ』だって、このやり方ならブラウザでいつでも使える形で作れるぞ」

一度仕組みを理解してしまうと、日常のあらゆるものが「アプリのアイデア」に変換されていきます。メモ帳には、次に作りたいもののアイデアが次々と書き込まれていきました。

そして次のステージへ

さらに夢は膨らみます。自分が作ったWebアプリが誰かの役に立つのであれば、サイト内に広告を入れたり、便利なプレミアム機能を追加したりといった「マネタイズ（収益化）」の戦略だって描けるはずです。

ただの「趣味の園芸の記録用」として作り始めたWebアプリは、いつの間にか私を「開発者」という新しい世界へ導いてくれました。

無限ループのバグに頭を抱えた夜もありましたが、諦めずにデプロイまで漕ぎ着けて本当に良かったです。
私の「AIプロデューサー」としての挑戦は、まだ始まったばかり。さて、次なるアイデアを形にするため、今日も最強の相棒（Gemini Pro）に新しい指示を出すとしましょう！

【編集後記】

ここまで「植物管理アプリ開発記」をお読みいただきありがとうございました！
このブログでは、引き続き新しいアプリの開発状況や、AIを使った最新の開発ノウハウ、そして時々（今回のような）リアルな失敗談などを発信していきます。お楽しみに！

第4話：【UI崩壊】「頼むから余計なアレンジはしないでくれ。」AIとデザインの致命的なすれ違い

「プロデューサー型開発」のコツを掴み、コードを書かない開発スタイルに手応えを感じ始めていた私。しかし、アプリの画面を作り込んでいく中で、またしてもAIの「困った習性」に直面することになりました。

それが、AI特有の「謎のデザインセンス」によるUI崩壊です。

「シンプルでいい」が伝わらない

裏側の複雑なデータ処理やロジックに関しては、Gemini Proは本当に優秀です。しかし、こと「画面の見た目（UI）」に関しては、時々彼らのセンスを疑いたくなる瞬間があります。

たとえば、新しい植物を追加するための登録画面を作っていた時のこと。
「ここに名前を入力するフォームと、シンプルな『保存』ボタンを配置して」と指示を出しました。

出力されたコードを意図通りにコピペして、いざビルド。画面に表示されたのは……。
なぜかド派手な緑色のグラデーションがかかり、無駄に丸みを帯びた、自己主張の激しすぎる巨大なボタンでした。

「いや、そんなこと頼んでない……！」

さらに悪いことに、AIは良かれと思ってテキストのサイズを勝手に大きくしたり、謎の余白（Padding）を大量に追加したりします。結果として、スマートフォンの小さな画面に要素が入りきらず、Flutter開発者なら誰もがトラウマになる「あの黄色と黒のシマシマのエラー（Overflow）」が画面の右端に出現することになります。

AIは「気を利かせすぎる」

なぜこんなことが起きるのか。それは、AIが「より良いものを作ろう」と気を利かせすぎてしまうからです。

指示がシンプルすぎると、AIは「きっとユーザーの目を引くデザインが良いだろう」と勝手に解釈し、独自のアレンジを加えてコードを出力してしまいます。人間であれば「普通でいいよ」のニュアンスを察してくれますが、AIにとっての「普通」は、時として過剰な装飾を意味するのです。

解決策：デザインの主導権は渡さない

このUI崩壊を防ぐため、私はプロンプト（指示の出し方）に一つのルールを追加しました。
それは、「デザインの主導権をAIから完全に奪うこと」です。

具体的には、画面を作ってもらう時は必ず以下の一文を添えるようにしました。

• 「色は指定しないでください。テーマのデフォルト色を使います」

• 「余計な装飾（影、角丸、グラデーションなど）は一切不要です」

• 「Flutterの標準的なMaterial Designの基本ウィジェットだけで構成してください」

この「引き算の指示」を徹底することで、AIは余計なアレンジをやめ、骨組みだけを綺麗に作ってくれるようになりました。色やサイズといった最終的なお化粧（スタイリング）は、コードが通ったあとにプロデューサーである私が手動で微調整する。これが一番安全で確実な方法だと気づいたのです。

AIにすべてを任せるのではなく、「どこまで任せて、どこから人間が引き受けるか」の境界線を引くこと。それが、このプロデューサー型開発を成功させる最大の鍵でした。

第3話：コードは書かない。AIを「凄腕エンジニア」として雇うプロデューサー型開発スタイル

前回、Geminiのモデルが「Pro」から「Lite」に切り替わっていたことに気づかず、深夜に地獄の無限修正ループを彷徨ったお話をしました。

あのトラウマ級の失敗を経て、私はAIとの付き合い方を根本から見直すことにしました。AIは決して「なんでも察してくれる魔法の杖」ではありません。適切に指示を出さなければ、平気で見当違いの方向に走り出してしまう暴れ馬です。

そこで私が辿り着いたのが、自分自身は一切コードを書かず、AIをコントロールすることに徹する「プロデューサー型開発スタイル」です。

「優秀だが、指示待ちのエンジニア」をどう動かすか

AI（Gemini Pro）を擬人化するなら、「タイピング速度は音速、知識量は世界一だけど、言われたことしかやらない（たまに勘違いする）凄腕エンジニア」です。

「いい感じの植物管理アプリを作って」と丸投げしても、彼らは困惑するか、私が全く望んでいない的外れなコードを量産してしまいます。特に、私が今回採用しているFlutterというフレームワークは、画面の見た目（UI）と裏側の処理（ロジック）が複雑に絡み合うため、曖昧な指示は命取りになります。

だからこそ、私は「プログラマー」としての役割を完全に捨て、「プロデューサー（あるいはディレクター）」になることに決めました。

プロデューサーとしての3つの仕事

私がアプリ開発においてやっているのは、主に以下の3つだけです。

• 1. 要件定義と仕様決め（何をどう作るか）
  まずは完成形を明確にします。「植物の一覧画面が必要」「タップしたら詳細画面に飛ぶ」「水やりの記録ボタンを置く」など、アプリに必要な機能を人間の言葉で整理します。

• 2. 的確な発注（プロンプトの作成）
  整理した仕様を、AIが迷わないように具体的に指示します。
  例えば、「水やりボタンを作って」ではなく、
  「画面の右下に丸いフローティングアクションボタン（FAB）を配置し、アイコンは水滴（Icons.water_drop）にして。押した時は『水やり完了』というスナックバーを下部に表示するFlutterのコードを書いて」
  というように、レイアウトや動作を細かく指定して”発注”します。

• 3. コードの審査とテスト（QA）
  納品された（生成された）コードをエディタに貼り付け、実際に動かしてみます。エラーが出たり、想定と違う動きをした場合は、前回のように感情的に「直して！」と言うのではなく、「〇〇行目で〇〇というエラーが出た。この変数が初期化されていないのが原因だと思うから修正して」と、冷静にフィードバックを返します。

「作ること」ではなく「考えること」に集中できる

このスタイルの最大のメリットは、構文のエラー探しやタイピングの手間から解放されることです。

「どうやってコードを書くか」は凄腕エンジニアのGemini Proに任せ、私自身は「どんなアプリなら使いやすいか」「次はどんな機能を追加しようか」という、アプリの根幹となるアイデア出しに100%の脳のリソースを注ぐことができます。

プログラミング未経験の私が、こうして形あるアプリを少しずつ組み上げられているのは、間違いなくこの「プロデューサー型開発」のおかげです。

第2話：Proの制限と、深夜に潜む「Lite」の罠

開発中のルーチンとして、私は基本的に「Gemini Pro」を軸にコードを書いています。しかし、利用頻度が高いとどうしても上限に達してしまい、気づかないうちに自動で「Lite」に切り替わっていることがよくあります。

普段なら「あ、制限か」と気づいて、上限がリセットされるまで待つのが私のスタイルなのですが、先日、深夜の作業で完全にそのタイミングを見失いました。

爆速の回答、深まるエラー

その時もProのつもりでエラーログを投げ続けました。
いつもより回答が速いな、とは感じていたんです。ただ、深夜のテンションもあって「お、今日は調子がいいな」とポジティブに捉えてしまい、そのままAIの提案コードをコピペし続けました。

しかし、現実は甘くありませんでした。
AIは「直しました」と自信満々にコードを返すのですが、ビルドするとエラーが消えるどころか、別の箇所でエラーが出る。指摘すると別のコードに書き換わり、それがまた最初のエラーを呼び戻す……という、典型的な無限ループに陥ってしまったのです。

罠の正体

「おかしい。いつもならProがこんなに外すはずがない」

そう思いながら改めて画面の端を確認して、ようやく事の重大さに気づきました。
表示されていたのは「Lite」。
制限がかかり、モデルが切り替わっていたことに気づかず、私はLiteに対してProレベルの複雑なデバッグを要求し続けていたのです。

そりゃあ、話が噛み合うはずがありません。LiteにProの性能を求めていたこと自体が、今思えば「道具の特性を理解していなかった」私のミスでした。

教訓：モデルのステータスには気を配る

結果として、あの無限ループに費やした時間は完全に無駄足でした。
深夜の集中力が削がれた上に、結局、上限解除を待ってからProに聞き直すという二度手間になっただけでした。

AI開発において「どのモデルを相手にしているか」は、もっとも意識すべきメタ情報かもしれません。これからは、回答が妙に早かったり、コードの精度が落ちたと感じたら、まず「モデルの切り替わり」を疑うようにします。

もし同じように深夜の無限ループで頭を抱えている人がいたら、一度だけ画面の隅を確認してみてください。もしかしたら、あなたも「Liteの罠」にはまっているかもしれませんよ。

第1話：自分が欲しいアプリがないなら、AIと一緒に作ればいい

自分が本当に欲しいと思った機能がすべて詰まったアプリに、出会ったことはありますか？私はありませんでした。だから、自分で作ることにしました。

庭の花々に加えて家庭菜園も始め、育てる植物の数が30株を超えたあたりから、日々の水やりや肥料のタイミングを頭の中だけで記憶しておくのは限界を迎えました。市販の管理アプリもいくつか試してみましたが、「ここはもっとこうしたいのに」「この機能はいらないのに」と、どうしても自分の理想とは少しずつズレてしまいます。

プログラミングの知識はゼロ。それでも、優秀なAIを「専属エンジニア」として徹底的に活用し、自分は「監督」に徹することで、今まさに理想の植物管理アプリが完成しつつあります。

このコラムでは、知識ゼロの私がどのようにしてアプリ自作を決意し、AIと二人三脚でシステムを形にしているのか、そのリアルな開発の裏側をお届けします。

30株の壁。市販アプリが抱える「記録のめんどくささ」

私が「自分専用のアプリを作ろう」と決意した最大のキッカケは、家族が以前使っていた植物管理アプリでの挫折でした。横でその様子を見ていると、いくつかの決定的な「使いにくさ」が存在することに気づいたのです。

• 一気に「水やり完了」にできない
  植物が数鉢なら問題ありませんが、30株を超えてくると話は別です。庭全体に水を撒いた後、アプリを開いて1つ1つボタンを押していく作業は現実的ではありませんでした。
• 自由な並べ替えができない
  庭の花壇、プランター、家庭菜園など、場所や種類ごとにリストを直感的に整理したくても、思い通りに並べ替えられないもどかしさがありました。
• 登録個数の上限（無料の壁）
  多くのアプリには「〇株まで」という登録制限があり、次々と植物を育てたくなるガーデナーの熱量にブレーキをかけてしまいます。
• 初心者ゆえの「別アプリ頼み」
  園芸初心者にとって、「この葉の変色は病気？」「肥料はいつ？」といった疑問は日常茶飯事です。しかしアプリ内に相談機能がないため、結局アプリを閉じて、毎回別のブラウザを開いてAIに助言を求めていました。

こうした小さなストレスが積み重なった結果、行き着く先は「記録すること自体がめんどくさくなって使わなくなる」という本末転倒な結末でした。

「だったら、登録上限なしで、一括で水やり記録ができて、しかもアプリの中から直接AIに園芸相談ができるツールを作ればいいじゃないか！」
これが、私が理想のアプリ開発へと足を踏み入れた最大の理由です。

「AIに書かせる」葛藤と、二人三脚の開発スタイル

「プログラミング未経験なら、AIに全部コードを書かせればいい」。言葉にするのは簡単ですが、いざこの手法でアプリを作り始めようとしたとき、私の中に一つの葛藤が生まれました。それは、「AIに書かせたものを、果たして『自分が作った』と言っていいのだろうか？」という疑問です。

しかし、実際に開発をスタートしてみると、その葛藤はすぐに消え去りました。なぜなら、AIによる開発は決して「ボタン一つで全自動完成」する魔法ではなかったからです。

AIは圧倒的に便利ですが、決して完璧ではありません。たとえ高性能なモデル（Gemini Pro）を使っていたとしても、昨日まで完璧に理解していた前提条件を、翌日にはケロッと忘れていることが多々あります。そのため、「前回のやり方はこうだったから、今日もこの方向で頼むよ」と根気よく方向修正をしたり、AIが提示する新旧混ざった情報を自分でも調べ直したりする、「監督」としての作業が絶対に不可欠なのです。

足りない部分を人間が補い、的確な指示を出し、軌道修正をしながら理想のシステムへと少しずつ形作っていく。それは一人でパソコンと向き合う孤独な作業ではなく、優秀だけれど少し抜けている相棒と相談しながら進めているような不思議な感覚です。

単に自分一人で悩み続けるよりも挫けることは少なく、日々のAIの利用上限枠と戦いながら二人三脚でアプリを組み上げていくこの過程は、控えめに言って最高にエキサイティングで楽しい体験です。

迷走の数ヶ月！ノーコードの罠と「Gemini Pro上限待ち」で進めたアプリ開発

理想の園芸管理アプリ「PlantTag」を作ろうと決意した当初、私は「初心者におすすめの開発環境は？」とGPTに相談し、提案されるがままにノーコードツール（FlutterFlow）での開発をスタートさせました。しかし、ここから数ヶ月に及ぶ過酷な戦いが幕を開けます。

画面のスクリーンショットを送って操作を相談しても、AIからは「3番目の〇〇ボタンを押してください」という指示。しかし、画面のどこをどう探してもそんなボタンは存在しないのです。AI特有の「幻覚（もっともらしい嘘）」に振り回され、お互いに話が通じないまま時間だけが過ぎていきました。

途方に暮れ、たまたまGeminiに「このツールを使っているのに全然進まない……」と相談したのが大きな転機になりました。そこで「コードを直接書く手法（Flutter）もありますよ」と教えられ、思い切って直書きへ移行！すると、あんなに苦労していた意思疎通がコードベースになり、嘘のようにサクサクと開発が進むようになったんです。

とはいえ、順風満帆とはいきません。複雑なロジックの構築には高性能な「Gemini Pro」の力が必須で、通常モデルでは太刀打ちできませんでした。そのため、「Gemini Proの利用上限が来るまでコードを書き、上限に達したらスタミナ（制限）回復を待つ……」という、まるでソシャゲのようなスタイルで開発を進めることに。

そんな泥臭いスタミナ待ち期間を経て、少しずつ形になってきたPlantTag。次回は、実際にアプリ内でこだわったUI設計や機能について書いてみたいと思います！

開発日記ページを新設しました！

これまでnoteに書いていた開発の記録を、ProjectTagの公式サイト内に統合することにしました。あちこちに記録が分散しているとどこに何を書いたか忘れてしまうので、一箇所にまとめておきたかったんです。何より自分のサイト内に記事が蓄積されていくのはモチベーションが上がりますね。

今後はFlutterでのアプリ開発の知見や、苦労したUI設計の話、マイクラサーバーの構築備忘録などもこちらにまとめていく予定です。