自己紹介
はじめまして。Souken521と申します。
ソフトウェアエンジニアを目指してプログラミングを学習しています。
大学では機械工学を専攻していましたが、IT分野に興味を持ち、現在は支援機関に所属しながら、教材や個人開発を通して学習を続けています。
今回は、UdemyのFlask講座で作成したメモアプリをChatGPTとともに改良した経験から、「AI時代の個人学習」について感じたことをまとめます。
はじめに - 今回の学習について
きっかけ
支援機関の講師からFlaskの学習を勧められ、その教材としてUdemyの講座を紹介していただきました。
講座を終えて感じたこと
教材に沿ってアプリケーションを完成させることはできました。一方で、実際に使ってみると改善できそうな点が多くあると感じました。その段階で講師から「作ったアプリケーションを自分なりに改良してみてはどうか」という提言も受けたため個人で改良をすることにしました。
ただ、改良にあたって新たに触れる技術もあったため、「講座を完成した後の学習」も大事だと思いました。
今回の学習方針
大きく分けて以下の3点です。
- 完成したメモアプリを土台に、自分で機能を追加する
- ChatGPTは、最初から完成品のコードを出力してもらう目的ではなく、実装方針やエラー原因を考える「模擬コーチ」として使う
- できるだけ自分で実装してから相談する
なぜ「Claude CodeやCodexを使わず、ChatGPTのチャット機能だけを活用した」のか？
別の開発でClaude CodeやCodexを主として使って開発を行ったこともありました。
実際、コーディングエージェントは、複数ファイルを横断して実装・修正できるため、開発を効率化するうえでは非常に便利なのは理解しています。
一方、今回の目的は「アプリを完成させること」だけではなく、初めて開発する技術の理解を深めることでした。そのため、以下の観点よりあえてChatGPTのチャットを中心に利用しました。
- 生成されたコードを理解できないまま進むのを避けるため
- エラーの原因を自分で考える過程を残すため
- 自分で実装方針を考え、それを言語化する練習をするため
チャット形式の場合、「このような機能を実装したいが、どこから手を付ければいいか」「自分で実装してみたが、これで合っているのか」「このエラーはここからきていると思うが、合っているのか」等、自分から問いを作る必要があると思います。
もちろん、ある程度理解した技術を使って成果物を素早く作ることが目的なら、Claude CodeやCodexの方が適している場面も多いと思います。今回は「効率よく作る」より「自分が理解しながら作る」ことを優先しました。
学習サイクル
今回の学習では、ChatGPTに最初から完成したコードを生成してもらうのではなく、以下のようなサイクルで実装を進めました。
-
実装したい機能を決める
- まず、現在のアプリケーションの改善点を考え、次に実装する機能を決めます
-
実装方法を自分なりに考える
- どのような処理が必要なのか
- Python側とHTML・JavaScript側のどちらで実装するのか
- 既存のコードをどのように利用できるのか
などを、まず自分で考えます。
-
分からない部分をChatGPTに相談する
- 「この機能を実装するには、どのような方法があるか」
- 「この実装方針で問題ないか」
- 「どの機能やメソッドについて調べればよいか」
といった形で質問し、実装のヒントを得ます。
完成したコードがすぐに提示されないよう、ChatGPTにはあらかじめ以下の指示を設定しました。コードそのものはこちらから指示されるまで出力せず、まずは実装のヒントを回答してください。
-
自分で実装する
- ChatGPTから得たヒントをもとに、自分のコードに合わせて実装します
-
実装方針や処理に問題がないか確認する
- 実装したコードに意図しない動作をするものがないか、再度ヒントを求めます
-
エラーが発生したら、原因を考えてから再度相談する
- エラーメッセージを確認する
- 直前に変更した箇所を確認する
- 自分なりに原因を予想する
といったことを行ったうえで、必要であればChatGPTにコードやエラー内容、自分の予想を提示して相談します。
このように、
「考える → 相談する → 実装する → 試す → 原因を考える → 再度相談する」
という流れを繰り返しました。
特に意識したのは、エラーが発生した際に、すぐに「直してください」と依頼しないことです。
まずエラーメッセージや直前の変更から自分なりに原因を考え、
「この部分が原因だと思うが、認識は合っているか？」
という形で質問するようにしました。
これによって、単にエラーを解消するだけではなく、「なぜそのエラーが発生したのか」まで考えながら実装を進めることができました。
実際にAIとの学習で起きたこと
SQLAlchemyへの移行で、エラーを一つずつ理解した
講座のアプリケーションでは、データベース操作をSQLiteに対してSQLを直接記述する形で行っていました。
アプリケーションを改良していく中で、データベース操作についても新しい方法を学びたいと考え、SQLAlchemyを使ったORMへ移行することとしました。
移行作業では、単純にSQLを書き換えるだけではなく、データの取得方法や扱い方そのものが変わったことで、いくつかのエラーに遭遇しました。
RowとORMオブジェクトの違いでつまずいた
まず遭遇したのが、以下のエラーです。
Row object has no attribute 'created_at'
SQLを直接実行していたときのデータの扱い方と、SQLAlchemyのORMで取得したモデルオブジェクトの扱い方が混在していたことが原因でした。
このエラーを調べる中で、「現在この変数には何が入っているのか」「SQLAlchemyからどのような形式でデータが返されているのか」を意識するようになりました。
datetimeの扱い方が変わった
次に、以下のエラーにも遭遇しました。
TypeError: 'datetime.datetime' object is not subscriptable
ORMへの移行後、日時データはdatetimeオブジェクトとして扱われていましたが、以前のコードのように添字を使って値を取得しようとしていたことが原因でした。
この経験から、コードを書き換える際には記述方法だけを見るのではなく、その変数がどのような型になっているのかを確認することが重要だと感じました。
クエリを確定するタイミングを理解した
並び替え処理をORM化した際には、以下のエラーも発生しました。
AttributeError: 'list' object has no attribute 'order_by'
今回使用していた書き方では、.all()などでデータを取得した後はPythonのリストとなるため、その後にorder_by()を追加することはできませんでした。
このエラーを通して、
- SQLAlchemyでクエリを組み立てている段階
- 実際にデータを取得した後のPythonオブジェクト
は別のものとして考える必要があることを理解しました。
これらのエラーは、それぞれ単体で見れば小さなものです。
しかし、ChatGPTと原因を確認しながら一つずつ修正したことで、単に「SQLAlchemyで動くコードに書き換える」だけではなく、ORMではデータがどのように取得され、Python側でどのように扱われるのかを意識するきっかけになりました。
一つの不具合から、周辺技術まで学習が広がった
メモの登録機能を使用している中で、同じ内容のメモが複数登録されてしまうことがありました。
この問題を調べる中で、サーバー側のPythonだけを見るのではなく、フォームが短時間に複数回送信されることも考える必要があると分かりました。
そこで、JavaScriptを使ってフォーム送信後にボタンを無効化し、二重送信を防止する処理を実装しました。
この実装では、これまであまり触れていなかった以下のような内容について調べることになりました。
- フォームの
submitイベント - どの送信ボタンが押されたかの取得
- ボタンの
disabled属性 - 処理中のボタン表示の変更
最初は「同じメモが複数登録される」という一つの問題を解決することが目的でした。
しかし、問題を解決していく過程でJavaScript側のフォーム制御まで学習範囲が広がり、最終的には登録画面だけではなく、編集など他のフォームにも同じ考え方を応用できるようになりました。
教材ではあらかじめ学ぶ内容や順番が決められていますが、今回のような学習では、一つの問題を起点として必要な技術をその都度調べていくことになります。
この点は、完成済みのアプリケーションを自分で改良したからこそ得られた経験だと感じています。
「値がどこから来ているか」を考えるようになった
Flask-Loginを使ったログイン処理をSQLAlchemyに合わせて変更した際にも、いくつかつまずく場面がありました。
特に意識するようになったのが、
-
get_id()では何を返しているのか -
user_loaderにはどの値が渡されるのか - データベースの主キーとログインに使用するユーザーIDは同じものなのか
- セッションに保存された情報から、どのようにユーザーを取得しているのか
といった、値の流れを追うことです。
最初はエラーが発生した箇所だけを見て、「この部分を変更すれば動くのではないか」と考えることもありました。
しかし、ChatGPTとのやり取りを続ける中で、その値が
どこで作られ、どこから渡され、最終的にどこで使われるのか
まで追わなければ、根本的な原因を理解できないケースがあると気づきました。
これはFlask-Loginだけではなく、その後ほかの処理を調べる際にも役立つ考え方になりました。
AIに聞けばすぐ解決する、とは限らなかった
ChatGPTを使えば、エラーを入力するだけですぐに正解が得られる、というわけではありませんでした。
例えば、一部のコードやエラーメッセージだけを提示した場合、ChatGPTが実際のコード構成とは異なる前提で回答することもありました。
また、提案された修正を行った結果、別のエラーが発生することもありました。
そのため、次第に質問する際には、
- 発生しているエラー
- エラーが発生しているコード
- 直前に変更した内容
- 自分では何が原因だと考えているのか
をできるだけセットで伝えるようになりました。
例えば、
このエラーは、この部分で取得するデータの型が変わったことが原因だと思うのですが、認識は合っていますか？
といった形です。
このように質問すると、単に修正コードを提示してもらうだけではなく、自分の考え方そのものが合っているかを確認できます。
今回の学習を通して、AIを「正解を返してくれる存在」として使うよりも、自分で立てた仮説や実装方針を確認する相手として使う方が、学習目的には合っていると感じました。
今回感じた「AI時代の個人学習」
今回の学習を通して、AIは単にコードを生成するための道具ではなく、学習の進め方そのものを変える存在だと感じました。
特に、以下の点が印象に残りました。
教材を終えることがゴールではなくなった
これまでの教材では、教材に沿ってアプリケーションを完成させることが一つの区切りになっていました。
しかし今回、完成したメモアプリを土台にして自分で改善点を考え、ChatGPTに相談しながら機能追加や内部実装の変更を行いました。
その結果、教材で作った成果物は「完成品」ではなく、その後の学習に使える土台にもなると感じました。
教材で基礎を学び、その成果物に対して「ここを変えたい」「この仕組みはどうなっているのか」と考えることで、教材の範囲を越えた学習につなげることができました。
自分のコードについて、その場で質問できる
書籍や動画教材では、基本的にあらかじめ用意された内容を順番に学習します。
一方、ChatGPTとの学習では、
- 今書いているコード
- 発生しているエラー
- 自分が追加したい機能
- 自分なりに考えた実装方法
について、その場で質問できます。
特に今回のような既存アプリケーションの改良では、「一般的にはどう実装するか」だけではなく、**「今の自分のコードではどう考えればよいか」**を相談できることが大きなメリットだと感じました。
AIを使うほど、自分で問題を言語化する必要があった
AIを使えば考える必要がなくなるのではなく、今回の学習ではむしろ逆でした。
適切な回答を得るためには、
- 何を実現したいのか
- 現在どのような状態なのか
- どのようなエラーが発生しているのか
- 自分は何が原因だと考えているのか
を整理して伝える必要があります。
「動きません」とだけ質問するよりも、
この処理をORM化した後からこのエラーが発生しています。取得するデータの型が変わったことが原因だと考えていますが、認識は合っていますか？
のように質問する方が、自分自身の理解も整理できます。
このように、AIとの対話そのものが、自分の考えを言葉にする練習にもなりました。
AIにどこまで任せるかも、学習方法の一部になる
Claude CodeやCodexのようなコーディングエージェントを使えば、今回行った改良の多くは、より短時間で実装できた可能性があります。
しかし、学習を目的とする場合には、「どこまでAIに任せるか」を自分で決めることも重要だと感じました。
今回私は、完成したコードを最初から生成してもらうのではなく、
自分で考える → ChatGPTに相談する → 自分で実装する → 動作を確認する
という流れを意識しました。
もちろん、すでに理解している技術を使って成果物を素早く作る場合には、コーディングエージェントを活用する方が適している場面もあると思います。
一方で、新しい技術を学ぶ場合には、あえて自動化しすぎず、自分で試行錯誤する余地を残すことも一つの方法だと感じました。
まとめ
オンライン講座などの教材で基礎を学び、完成した成果物をAIとの対話を通して自分なりに改良していく。
今回の経験から、教材とAIは競合せず、「教材で基礎を得て、AIとその先を探索する」という組み合わせが、個人学習の新しい形の一つになるのではないかと感じました。
また、AIにどこまで任せるかを自分で決めることも、AI時代の学習では重要だと感じています。完成までの速さだけを求めるのではなく、必要に応じてあえて自分で考える余地を残すことで、AIを学習のための「模擬コーチ」として活用できるのではないでしょうか。
改良アプリケーションのリポジトリはこちらです。
最後までご覧頂き、ありがとうございました。