ブログ

ryuzeeによるブログ記事。不定期更新

生成AIの練習をするなら自分が欲しいアプリを作れという話

みなさんこんにちは。@ryuzeeです。

猫も杓子も生成AIの話(とセキュリティの話)ばっかりの今日この頃ですが、いかがお過ごしでしょうか。生成AIを仕事で使うのは当たり前として、うまいこと使うにはどうしたらいいか試行錯誤している人が多いのではないかと思います。

そこでお勧めなのが、「自分が使うアプリを作ること」です。作ってすぐに放置するようなものではなく、毎日のように自分が使うやつです。

ToDoアプリとかチュートリアルじゃなぜダメなの?

生成AIの練習というと、ToDoアプリとかチュートリアルに載ってる何かを作りがちですが、作って終わりで使わないなら、あんまり意味がないです。

理由は説明するまでもないんですが……

  • 使わないので、開発を続ける動機が弱い
  • 使わないので、使い勝手や、本当に自分の役に立つのかを評価できない。評価できないので改善もしない
  • 自分が知っている知識の範囲で終わってしまう

生成AIにコードを書かせる練習にはなっても、プロダクトを良くしていく練習にはならないし知識もさして増えないってことです。

ちなみに僕はToDo管理はしないです。なんでもとっとと終わらせる主義なので、頭で覚えられるくらいのタスクしか抱えてないからね(笑)。

自分が欲しいものを作ると何が起きるか?

自分がユーザーなので、触った瞬間に「これは違う」っていうのがわかります。少なくとも自分で使う分には、ユーザーインタビューもユーザビリティテストも不要で、自分自身から超高速なフィードバックが手に入ります。

毎日使うので、不満がそのまま次のバックログになります(バックログアイテムを作っている暇があったら開発してしまうかも)。

毎日使うから「なんか微妙」に気づける

生成AIに「いい感じの画面を作って」と頼むと、それっぽい画面がすぐできます。でもなんか微妙なことが多いんですよねぇ。感覚的には60点くらいで、なんかしっくりこない。

で、こういうのは作って終わりのアプリでは気づけません。毎日使って、毎日「なんか微妙」と思うから気づけるわけです。

気づいても、知識がないと直せない

じゃあ残り40点を埋めるのは何かというと、それが人間の持つ知識や経験なのではないかなと思います。キーボードだけで操作できるとか、ダークモードがあるとか、桁が大きく違う値のグラフは対数軸にするとか、横長のテーブルは見出し行と先頭のカラムを固定したほうがいいとか……、まぁいろんな知識をみんな持っているわけで、そういうのをインプットできるかどうかで、アウトプットの質はかなり変わります。

知っていれば「見出し行を固定して」と一言で直せますが、知らなければ「なんか見にくい」としか言えないし、それだとAIにも伝わりません。AIに「使いにくいところを指摘して」と頼んでもいいんですが、出てきた案が良いのか悪いのかを判断するのにも、結局同じ知識が必要です。

つまり、知識や経験があると、何が問題なのかを具体的な言葉で説明できるし、AIの提案が妥当なのかも判断できるわけです。そして、その知識をAIに伝えるための語彙も大事です(語彙があればトークンの量も減らせます)。

語彙を増やすには、他のアプリを触るのがいちばん

じゃあその語彙はどこで身につくのかというと、他のアプリを触りまくるのがいちばんです。なんとなく使うんじゃなくて「なんでこうなってるんだろう?」と考えながら触るのが理想です。ベンチマークといってもいいかも。そうすれば、自分のアプリに足りないものがわかるし、AIへの指示もどんどん具体的になります。

他の人に使ってもらうと、さらに学びがある

それから、プロダクトが自分の役に立つことがわかると他の人にも使ってもらいたくなるというのが人情です。

そうなると、アプリに署名したり、インストーラーを作ったり、マニュアルを書いたり、自動更新の仕組みを作ったり、データの保存場所を考えたり……といった地味なところもやらなければいけません。

こういうのは、チュートリアルのアプリだと絶対に通らない道ですが、いちばん学びの多い場所だったりします(昔は署名なんてしなくてもアプリ公開できて、牧歌的な時代だったなー)。

ちなみにぼくも最近、RSSリーダーを作りました。記事の本文を抜き出して、LLMで要約や翻訳ができるやつで、WindowsとmacOSで動きます。フリーソフトなので興味があれば使ってみてください(宣伝)。

RSSリーダーなんて、昔なら自分1人のために作るのは割に合わなかったけど、今ならすぐ作れちゃうし、気に入らなければ捨てて作り直せばいい。作るのも捨てるのもくっそ安くなったので、自分1人のために作っても十分割に合います。

ということで、生成AIの練習をするなら、自分が欲しいものを作りましょう。生成AIにコードを書かせることより、できたものを使って、気になるところを見つけてどんどん直す。その繰り返しのほうが、よっぽどいい練習になるんじゃないかと思います。

それでは。

前の記事 ← 【資料公開】生成AIでスクラムによる開発はどう変わるか(2026年9月版)

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World