8
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

曖昧理解を整理する7ステップ 通勤電車×ChatGPTで「分かったつもり」が毎回ほぐれていった記録

8
Last updated at Posted at 2025-12-09

1. 導入(なぜこの記事を書くのか)

業務のキャッチアップを進める中で、技術用語は知っていても、その仕組みや動作を人に説明できない場面が多くありました。
特に Rails や Docker、Redis といった基盤技術は、触れる機会が多い一方で、
「なぜそう動くのか」「どの段階で何が起きているのか」を自分の言葉で説明できない状態が続いていました。

知識として断片的に覚えていても、それを業務で必要な判断や説明に落とし込めない。
初学者としての課題を、そのまま日々の作業の中で感じていました。

そこで私は、毎日の通勤時間を使い、ChatGPT と対話しながら理解を整理し直す学習を続けました。
1時間という限られた時間の中で曖昧な点を持ち越さず、その場で掘り下げることを繰り返すうちに、理解が「名前を知っている」レベルから「動作の流れを説明できる」レベルへと変わっていきました。

この記事では、通勤電車で取り組んだ学習サイクルをまとめています。
「概念としては知っているのに説明できない」という壁にぶつかっている方に、少しでも参考になれば幸いです。

2. なぜ通勤電車が最強の学習環境なのか

通退勤の電車は、自分の意思とは関係なく時間が始まり、気づけば終わっています。
途中でやめることもできず、ただ乗っているしかない。
この“ほどよい拘束”が、意外にも学習に向き合うきっかけになっていました。

1時間という限られた区間では、できることは多くありません。
調べ物を広げる余裕もなく、扱えるテーマはいつも一つだけでした。
だからこそ、その場で浮かんだ疑問をそのままにせず、ChatGPT との対話を通して整理しきる習慣が自然と身についていきました。

環境構築もできず、複雑な作業もできない。そういう制約があるからこそ、「自分は今どこまで理解できているのか」を言語化しながら片付けていく時間として、電車の1時間がちょうどよかったのだと思います。

制限の多い環境が、結果として思考の軸を一つに絞り、理解を深める場として機能していました。

3. 静止画理解という悪癖

私が特に苦労したのは、コードを「その場で完結する静止画」のように理解してしまう癖でした。
処理がどのタイミングで実行され、どこがまだ“準備段階”のままなのかを考えず、
書かれた行の順番どおりに結果が得られるものとして読んでしまうのです。

この癖が最も顕著に表れたのが、以下のようなごく一般的な Rails のコードでした。

def index
  @users = User.where(active: true)
end

当時の私は、これを次のように解釈していました。

User.where → この瞬間に SELECT が発行される  
@users     → データの配列が入っている

しかし実際には、User.where は まだ実行されていないクエリの構築 にすぎません。
@users に入っているのは、データではなく 「必要になったときに初めて評価される問い合わせそのもの」 です。

この認知のズレによって、私は何度も「実行されていない行」を疑い続け、
デバッグを完全に逆方向へ進めていました。
結果が得られていない段階で“結果が変だ”と判断してしまう、典型的な静止画理解の落とし穴です。

この経験から痛感したのは、
理解を妨げていたのは技術の難しさではなく、
「処理の時系列を想像しない読み方そのもの」 だったということです。

実務でコードを扱う際には、
どの行が“準備”で、どの行が“実行”なのかを見極めなければ、
いくら語句を覚えても正しく動作を把握することはできません。

4. ChatGPTが理解を破壊してくる3種類の質問

ChatGPT と通勤電車で壁打ち学習をしていると、
「自分は理解できているつもりだった部分」が急に崩れる瞬間があります。
そのきっかけになった質問には、共通するパターンがありました。

特に私は、次の 3 タイプの問いを投げられたときに、理解の矛盾が一気に露呈していました。

1. 時系列を要求する質問:ActiveRecord が“いつ動くのか”を問われた瞬間

最もダメージが大きかった質問がこれです。

「その SQL は“どの瞬間に”実行されてる?」

User.where を書いた瞬間に SQL が発行されると思い込んでいた私は、
この質問に答えようとした時点で完全に詰まりました。

自分の中には「構築段階」と「実行段階」の区別が存在せず、
ただコードを“見たままの順番に動くはずだ”と捉えていたことに気づきました。

2. 役割と境界を問う質問:Docker が“どこまで面倒を見るのか”を問われた瞬間

Docker の挙動を整理しようとした際、チャットの中でこう聞かれました。

「ローカルにイメージが無かったとき、Docker は最初にどこを探しに行く?」

私は咄嗟に「bash?」と答えてしまいました。
今思えば完全に筋違いですが、当時の私は Docker の責務や、どこからどこまでが分離されているのか を明確に理解していませんでした。

この質問によって、
「技術の境界を曖昧に理解したまま扱っていた」という自分の根本的な問題を突きつけられました。

3. 観察 → 因果を問う質問:Redis が“なぜ壊れないのか”を問われた瞬間

Redis の動作を説明しようとしたとき、こう聞かれました。

「複数サーバーから同時に INCR を叩いたら普通は競合するよね。Redisではどうやってそれが防がれている?」

私は「全部キューに溜めるからでは?」と答えました。
実際には Redis の単一スレッドモデルや Atomic 操作によって整合性が保たれているにも関わらず、
私は“現象として壊れていない”ことだけを根拠に、雰囲気で因果を補完していたのです。

この質問で、「観察」と「仕組み」を切り分けられていなかったことを痛感しました。

5. 「理解サルベージサイクル」7ステップ

Gemini_Generated_Image_60wz3260wz3260wz.png

STEP1:曖昧な理解のまま進む

私(当時の認識)「where を呼んだら SQL が実行されるんだよね?」

この段階では、
“言葉としての理解” を “仕組みの理解” と混同している状態です。
まだ自分の理解に穴があることすら気づいていません。

STEP2:違和感を無視

どこかで薄く “あれ?” と感じています。

「この行でほんとにデータ取得されてるんだっけ?」
「Relationって結局何なんだ?」

しかし私は、その違和感を放置しました。
業務も進めなければならず、疑問は脇に置いて進んでしまう。

STEP3:雰囲気でパテ埋め

私「controller のこの行でレコード取れてるはず…ですよね?」

“雰囲気でそれっぽい理解” がここで完成します。

  • where で即実行
  • 変数には配列が入っているはず
  • Rails が裏でよしなにやってくれてる

確認せず、都合のいい理解で空白を埋めてしまう。

STEP4:AIの質問で破綻

ChatGPT「どの瞬間に SQL が実行されていると思っていますか?」

私「えっと…この行…で…?」

ChatGPT「where を呼んだだけでは SQL は走っていません。」

この一撃で、
理解の根本前提が完全に崩壊しました。

静止画のようにコードを読む癖が破れ、
「実際には何も起きていない行を“実行済み扱い”していた」
という事実を突きつけられます。

STEP5:因果・時系列までバックトラック

私はここで初めて、

  • クエリ構築(意図の準備)
  • 遅延実行(必要な瞬間に初めて評価)
    という2段階が存在することを学び直しました。

“理解したつもり” の表面を剥がれ、
処理の因果と時系列をゼロから組み直す時間が発生します。

STEP6:説明可能な理解へ

理解が線でつながると、
自分の言葉で説明できるようになります。

私(再構築後)「where は SQL を実行せず、クエリオブジェクトを返すだけ。
実行されるのは view で each を回した瞬間。」

この段階で初めて、
“使える理解” に到達します。

STEP7:忘れる→再学習→層が深くなる

数日後には細部を忘れます。
しかし通勤電車で壁打ちを続けると、
前より深いところで理解が再構築されていきます。

これは“定着”ではなく“深度化”です。
何度も崩れ、何度も組み直すことで理解が層を成していく。

この7ステップが私の学習を変えた

ChatGPT との壁打ちは、
私に 「理解は何度も崩れていい」 という感覚を与えてくれました。

曖昧さは放置すると腐るが、
崩れた瞬間こそが一番の成長ポイント だということを知ったのは、
この 7 ステップを通じてでした。

6. まとめ

通勤電車での壁打ち学習は、曖昧な理解を確実に回収するうえで非常に効果的でした。
特に、ChatGPT から投げられる「時系列」「因果」「責務の境界」を問う質問によって、
自分では気づけなかった理解の穴が何度も明確になりました。
その結果、コードを“静止画”として読む癖をやめ、
処理の流れや意図を踏まえて読み解く姿勢が身についたと感じています。

一方で、AI と壁打ちしながら学習するうえで注意すべき点もあります。
AI が返す説明は文脈に依存しやすく、
自分の理解が曖昧なままだと、こちらが誤解したまま納得してしまう可能性があります。
私自身、誤った前提で質問したことで、
“もっともらしい答え” を受け取り誤解を深めてしまった場面もありました。

大切なのは、AI を正解の提供者として扱わず、
「自分の理解を説明し、整理するための相手」 として使うことだと思います。
ChatGPT との対話は、自分の認知の癖を映し出す“鏡”のような存在であり、
その気づきをどう実務に落とし込むかは、最終的には利用者自身の姿勢に依存します。

この記事が、私と同じように曖昧な理解で悩む方や、
学習の進め方を試行錯誤している方の参考になれば幸いです。

8
2
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
8
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?